Claude Code 用了兩周后，我發(fā)現(xiàn)它最強(qiáng)的不是寫(xiě)代碼
很多人第一次打開(kāi) Claude Code，第一反應(yīng)是：
這不就是另一個(gè) AI 編程助手嗎？
能寫(xiě)代碼，能解釋代碼，能生成文檔，能跑命令?？雌饋?lái)和 Cursor、Copilot、Windsurf 沒(méi)有太大區(qū)別。
但真正用上一段時(shí)間后，會(huì)發(fā)現(xiàn)它的重點(diǎn)不在“多補(bǔ)幾行代碼”。
Claude Code 更有意思的地方，是把 AI 放進(jìn)了終端工作流里。
你可以讓它讀項(xiàng)目、看文件、跑測(cè)試、分析報(bào)錯(cuò)、查看 diff、整理提交信息，甚至通過(guò) CLAUDE.md 記住項(xiàng)目規(guī)則。
它不是停留在聊天框里回答問(wèn)題，而是開(kāi)始參與一條完整的工程鏈路。
這也是 Claude Code 最近被很多開(kāi)發(fā)者重新討論的原因。
AI 編程正在從“會(huì)不會(huì)寫(xiě)代碼”，轉(zhuǎn)向“能不能進(jìn)入真實(shí)項(xiàng)目流程”。
這篇文章，我們就從工程實(shí)踐角度聊聊：Claude Code 到底該怎么用，為什么很多人用了一圈還覺(jué)得淺，以及測(cè)試開(kāi)發(fā)工程師能從里面看到什么機(jī)會(huì)。
目錄
- Claude Code 和普通代碼助手差在哪
- 為什么說(shuō)它不是簡(jiǎn)單的“代碼補(bǔ)全工具”
- 快速上手：先跑通基礎(chǔ)環(huán)境
- 三個(gè)小實(shí)驗(yàn)，理解它的工作方式
- 11 個(gè)真正影響效率的核心技巧
- CLAUDE.md：讓 AI 理解你的項(xiàng)目
- .claudeignore：別讓上下文變成垃圾桶
- 權(quán)限配置：讓 AI 能干活，但不能亂來(lái)
- 測(cè)試開(kāi)發(fā)視角：Claude Code 最值得用在哪些場(chǎng)景
- 真正的門(mén)檻，不是安裝，而是工程化使用習(xí)慣
一、Claude Code 和普通代碼助手差在哪
過(guò)去我們用 AI 編程工具，更多是在編輯器里完成局部動(dòng)作。
寫(xiě)一個(gè)函數(shù)。 解釋一段代碼。 補(bǔ)全幾行邏輯。 根據(jù)注釋生成代碼。 幫忙看一個(gè)報(bào)錯(cuò)。
這類(lèi)能力當(dāng)然有價(jià)值，但它們大多還停留在“局部輔助”。
真正復(fù)雜的工程開(kāi)發(fā)不是只寫(xiě)代碼。
一個(gè)真實(shí)任務(wù)往往要經(jīng)歷：
理解需求； 閱讀項(xiàng)目結(jié)構(gòu)； 找到相關(guān)文件； 判斷技術(shù)棧； 修改代碼； 運(yùn)行測(cè)試； 分析報(bào)錯(cuò)； 繼續(xù)修復(fù)； 查看 diff； 整理提交信息； 沉淀文檔。
Claude Code 的價(jià)值，就在于它不是只停留在“生成代碼”這一步，而是能參與這條鏈路。
它運(yùn)行在終端里，可以圍繞項(xiàng)目文件、命令執(zhí)行、測(cè)試結(jié)果、Git 變更和項(xiàng)目配置持續(xù)協(xié)作。
換句話(huà)說(shuō)，它更像是一個(gè)終端里的 AI 工程搭檔。
如果只把它當(dāng)成“會(huì)寫(xiě)代碼的聊天窗口”，很容易用淺。
它真正的價(jià)值，是進(jìn)入工程流程。
二、為什么說(shuō)它不是簡(jiǎn)單的代碼補(bǔ)全工具
普通代碼補(bǔ)全工具解決的是“當(dāng)前這一段代碼怎么寫(xiě)”。
Claude Code 更接近解決：
這個(gè)項(xiàng)目該怎么改； 這個(gè)測(cè)試為什么失??； 這次 diff 改了什么； 這個(gè)模塊缺哪些測(cè)試； 這個(gè)任務(wù)應(yīng)該怎么拆； 這個(gè)項(xiàng)目規(guī)則怎么讓 AI 記住。
舉個(gè)例子。
你可以直接讓它做一個(gè)完整任務(wù)：
幫我給用戶(hù)登錄模塊補(bǔ)充單元測(cè)試，運(yùn)行測(cè)試，如果失敗就分析原因并修復(fù)。
這句話(huà)背后，其實(shí)包含多個(gè)動(dòng)作：
- 找到登錄模塊相關(guān)代碼
- 判斷項(xiàng)目使用什么測(cè)試框架
- 生成測(cè)試文件
- 覆蓋正常登錄、異常賬號(hào)、密碼錯(cuò)誤、空參數(shù)等場(chǎng)景
- 執(zhí)行測(cè)試命令
- 根據(jù)失敗日志修復(fù)測(cè)試或代碼
- 再次運(yùn)行驗(yàn)證
這已經(jīng)不是單點(diǎn)代碼生成，而是一個(gè)小型工程閉環(huán)。
測(cè)試開(kāi)發(fā)工程師應(yīng)該特別關(guān)注這一點(diǎn)。
因?yàn)闇y(cè)試工作本來(lái)就不是只寫(xiě)腳本，而是圍繞需求、風(fēng)險(xiǎn)、數(shù)據(jù)、執(zhí)行、結(jié)果、回歸形成閉環(huán)。
Claude Code 對(duì)測(cè)試開(kāi)發(fā)最大的啟發(fā)，不是“AI 能寫(xiě)自動(dòng)化腳本了”。
而是：
AI 開(kāi)始具備參與測(cè)試工程流程的能力。
三、快速上手：先把基礎(chǔ)環(huán)境跑通
Claude Code 基于 Node.js 構(gòu)建，安裝前需要確認(rèn)本地 Node.js 版本不低于 18。
常規(guī)安裝方式如下：
npm install -g @anthropic-ai/claude-codeclaude --version
進(jìn)入項(xiàng)目目錄后啟動(dòng)：
cd /path/to/your/projectclaude
首次啟動(dòng)時(shí)，一般會(huì)經(jīng)歷幾個(gè)步驟：
登錄 Anthropic 賬戶(hù)； 選擇使用計(jì)劃； 確認(rèn)服務(wù)條款； 可選配置 API 密鑰。
對(duì)于國(guó)內(nèi)用戶(hù)來(lái)說(shuō)，可能會(huì)遇到網(wǎng)絡(luò)訪問(wèn)或 API 配置問(wèn)題。如果使用兼容 Anthropic API 格式的服務(wù)，一般需要配置 API 地址和密鑰。
這里不建議一開(kāi)始就手工復(fù)制一堆命令亂配。
更穩(wěn)妥的方式是讓已有 AI Agent 幫你檢查環(huán)境，比如：
安裝 claude code cli，并檢查 Node.js 版本是否兼容。
或者：
幫我配置 Claude Code 的 API 地址和密鑰，并驗(yàn)證是否能正常啟動(dòng)。
這樣可以避免很多基礎(chǔ)環(huán)境問(wèn)題。
真正要關(guān)注的不是“能不能裝上”，而是裝好之后怎么進(jìn)入項(xiàng)目流程。
四、三個(gè)小實(shí)驗(yàn)，先理解它的工作方式
很多人剛裝好 Claude Code，就直接打開(kāi)公司項(xiàng)目讓它改業(yè)務(wù)代碼。
這其實(shí)不太穩(wěn)。
工具沒(méi)熟悉，權(quán)限沒(méi)配置，上下文沒(méi)建立，Git 狀態(tài)也不干凈，很容易出現(xiàn)“改了一堆，但不敢用”的情況。
建議先做三個(gè)小實(shí)驗(yàn)。
實(shí)驗(yàn) 1：先看它怎么理解問(wèn)題
可以輸入：
你好，你是誰(shuí)？
再試一個(gè)技術(shù)問(wèn)題：
什么是閉包？太長(zhǎng)不看版本。
再試一個(gè)對(duì)比問(wèn)題：
JavaScript 和 TypeScript 有什么區(qū)別？
這一步不是為了學(xué)習(xí)這些知識(shí)，而是觀察它的回答結(jié)構(gòu)。
好的工程協(xié)作，不只是答案正確，還要表達(dá)清楚。
Claude Code 的回答通常會(huì)先給核心判斷，再展開(kāi)細(xì)節(jié)。這種結(jié)構(gòu)適合快速獲取信息，也適合后續(xù)讓它幫你寫(xiě)文檔、整理方案、生成復(fù)盤(pán)。
實(shí)驗(yàn) 2：讓它生成一份 Markdown 文檔
可以輸入：
幫我寫(xiě)一份 Git 常用命令的 Markdown 文檔。要求：包含命令、說(shuō)明、示例。
它一般會(huì)按照?qǐng)鼍敖M織內(nèi)容：
初始化倉(cāng)庫(kù)； 日常提交； 分支管理； 遠(yuǎn)程協(xié)作； 沖突處理； 回滾操作。
這個(gè)實(shí)驗(yàn)可以驗(yàn)證它的結(jié)構(gòu)化輸出能力。
對(duì)測(cè)試開(kāi)發(fā)來(lái)說(shuō)，這類(lèi)能力很實(shí)用。
測(cè)試方案、接口測(cè)試說(shuō)明、自動(dòng)化框架文檔、缺陷復(fù)盤(pán)、上線(xiàn)檢查清單，都可以先讓它生成初稿，再由人來(lái)審核和補(bǔ)充。
實(shí)驗(yàn) 3：讓它寫(xiě)一個(gè)可運(yùn)行的小程序
比如輸入：
用 Python 寫(xiě)一個(gè)貪吃蛇游戲。要求：1\. 使用 pygame 庫(kù)2\. 有分?jǐn)?shù)顯示3\. 按 ESC 退出寫(xiě)完后幫我運(yùn)行它。
這個(gè)實(shí)驗(yàn)?zāi)芸吹?Claude Code 的完整鏈路：
這一步非常關(guān)鍵。
因?yàn)槟銜?huì)發(fā)現(xiàn)，它不是只會(huì)“輸出一段代碼”。
它可以創(chuàng)建文件、執(zhí)行命令、讀取報(bào)錯(cuò)、繼續(xù)修復(fù)。
這才是 Claude Code 和普通聊天式編程助手的明顯區(qū)別。
五、11 個(gè)真正影響效率的核心技巧
Claude Code 上手不難，真正拉開(kāi)差距的是下面這些用法。
1. 雙擊 Esc：別讓錯(cuò)誤對(duì)話(huà)繼續(xù)滾下去
AI 協(xié)作最常見(jiàn)的問(wèn)題不是它不會(huì)回答，而是它開(kāi)始沿著錯(cuò)誤方向回答。
你說(shuō)錯(cuò)了一個(gè)條件。 它理解錯(cuò)了一個(gè)需求。 你發(fā)現(xiàn)剛才的問(wèn)題問(wèn)得不準(zhǔn)確。 它已經(jīng)開(kāi)始往不該改的方向走。
這時(shí)候不要硬聊。
Claude Code 里可以用 Esc 快速回退：
按一次 Esc：清除當(dāng)前輸入按兩次 Esc：回退上一輪對(duì)話(huà)按三次 Esc：清空對(duì)話(huà)歷史
但這里有一個(gè)重要細(xì)節(jié)：
Esc 回退的是對(duì)話(huà)狀態(tài)，不是代碼文件。
如果 Claude Code 已經(jīng)修改了文件，Esc 不會(huì)自動(dòng)撤銷(xiāo)文件變更。
所以在正式項(xiàng)目里，大改之前最好先保證 Git 狀態(tài)干凈。
比如：
git statusgit add .git commit -m "chore: save current work before claude session"
或者至少：
git stash push -m "before claude session"
AI 可以大膽用，但回滾手段必須提前準(zhǔn)備好。
2. @ 引用文件：讓 AI 看準(zhǔn)確的上下文
很多人會(huì)這樣問(wèn)：
幫我看看登錄模塊有沒(méi)有問(wèn)題。
這個(gè)問(wèn)題太模糊。
更好的方式是：
@src/services/auth.ts @tests/login.test.ts幫我分析登錄邏輯和現(xiàn)有測(cè)試覆蓋情況。
@ 引用文件的好處是：
讓 AI 明確讀取哪些文件； 減少無(wú)關(guān)上下文； 降低誤判概率； 節(jié)省 Token； 讓回答更貼近項(xiàng)目實(shí)際。
比如測(cè)試開(kāi)發(fā)場(chǎng)景可以這樣用：
@openapi.yaml請(qǐng)基于接口定義設(shè)計(jì)接口測(cè)試用例，覆蓋正常場(chǎng)景、參數(shù)缺失、非法參數(shù)、權(quán)限異常和冪等性問(wèn)題。
或者：
@tests/e2e/login.spec.ts這個(gè) Playwright 用例最近不穩(wěn)定，請(qǐng)分析可能原因，并優(yōu)化等待策略。
當(dāng)你給的上下文越精準(zhǔn)，它越容易輸出可用結(jié)果。
3. ! 執(zhí)行命令：把測(cè)試和構(gòu)建納入對(duì)話(huà)
Claude Code 支持直接執(zhí)行終端命令：
!npm test
!git status
!npm run build
這意味著你可以讓它參與測(cè)試閉環(huán)：
!npm test測(cè)試失敗了，請(qǐng)分析失敗原因，并判斷是業(yè)務(wù)代碼問(wèn)題還是測(cè)試代碼問(wèn)題。
這個(gè)能力對(duì)測(cè)試開(kāi)發(fā)非常重要。
因?yàn)闇y(cè)試工程的核心不是寫(xiě)完腳本，而是跑起來(lái)、看結(jié)果、定位問(wèn)題、修復(fù)問(wèn)題、再次驗(yàn)證。
過(guò)去這條鏈路需要人在多個(gè)窗口之間切換。
Claude Code 可以把它收進(jìn)一個(gè)終端工作流。
4. /plan：復(fù)雜任務(wù)先拆，不要直接讓它開(kāi)寫(xiě)
很多人用 Claude Code 翻車(chē)，都是因?yàn)橐簧蟻?lái)就讓它直接改。
比如：
幫我實(shí)現(xiàn)用戶(hù)認(rèn)證功能。
這個(gè)需求太大。
更好的做法是先進(jìn)入規(guī)劃模式：
/plan我想添加用戶(hù)認(rèn)證功能，請(qǐng)幫我制定實(shí)施計(jì)劃。
它會(huì)先分析項(xiàng)目結(jié)構(gòu)，然后拆出階段：
用戶(hù)表設(shè)計(jì)； 注冊(cè)接口； 登錄接口； Token 或 Session 機(jī)制； 權(quán)限中間件； 前端登錄頁(yè)； 異常處理； 單元測(cè)試； 集成測(cè)試。
這一步非常重要。
因?yàn)閺?fù)雜任務(wù)真正難的不是寫(xiě)代碼，而是邊界拆分。
沒(méi)有計(jì)劃就讓 AI 改代碼，本質(zhì)上是在讓它替你做架構(gòu)判斷。
這很危險(xiǎn)。
正確方式應(yīng)該是：
先讓 AI 給方案； 人來(lái)判斷方案是否合理； 再讓 AI 分階段執(zhí)行； 每完成一階段就檢查 diff 和測(cè)試結(jié)果。
5. /init：生成項(xiàng)目說(shuō)明書(shū) CLAUDE.md
/init 是 Claude Code 里非常關(guān)鍵的命令。
它會(huì)掃描項(xiàng)目結(jié)構(gòu)，讀取配置文件，分析技術(shù)棧和常用命令，然后生成一份 CLAUDE.md。
這個(gè)文件可以理解為 Claude Code 的項(xiàng)目記憶。
最小可用版本大概長(zhǎng)這樣：
# 項(xiàng)目名稱(chēng)## 技術(shù)棧- 前端：React 18 + TypeScript- 構(gòu)建工具：Vite- 測(cè)試框架：Vitest + Playwright- 樣式方案：Tailwind CSS## 常用命令```bashnpm run devnpm run testnpm run buildnpm run lint
代碼規(guī)范
- 組件使用函數(shù)組件
- API 請(qǐng)求統(tǒng)一走 request 封裝
- 提交信息遵循 Conventional Commits
- 測(cè)試文件統(tǒng)一放在 tests 目錄
有了這個(gè)文件，Claude Code 每次進(jìn)入項(xiàng)目時(shí)，就能知道：項(xiàng)目用什么技術(shù)棧； 怎么啟動(dòng)； 怎么測(cè)試； 代碼風(fēng)格是什么； 哪些目錄放什么內(nèi)容； 團(tuán)隊(duì)約定是什么。 沒(méi)有 CLAUDE.md 的項(xiàng)目，AI 每次都像新來(lái)的同事。有了 CLAUDE.md，AI 至少知道項(xiàng)目的基本規(guī)矩。---## 6\. /compact：長(zhǎng)對(duì)話(huà)一定要壓縮上下文很多人用 AI 工具時(shí)會(huì)遇到一個(gè)現(xiàn)象：剛開(kāi)始回答挺準(zhǔn)，聊著聊著就開(kāi)始跑偏。這不一定是模型突然變差了，很可能是上下文變臟了。長(zhǎng)對(duì)話(huà)會(huì)積累大量?jī)?nèi)容：已經(jīng)廢棄的方案； 中間嘗試過(guò)的錯(cuò)誤； 不再需要的文件； 臨時(shí)討論的問(wèn)題； 舊的需求表述。 這些信息都會(huì)占用 Token，也會(huì)影響判斷?？梢杂茫篳``bash/compact
它會(huì)把當(dāng)前對(duì)話(huà)壓縮成摘要，只保留關(guān)鍵決策和當(dāng)前狀態(tài)。
建議在這些場(chǎng)景使用：
連續(xù)聊了 5 到 6 輪之后； 完成一個(gè)階段，準(zhǔn)備進(jìn)入下一個(gè)階段之前； 感覺(jué)它開(kāi)始遺忘重點(diǎn)時(shí)； 上下文使用率明顯變高時(shí)。
AI 協(xié)作不是上下文越多越好。
真正高效的上下文，應(yīng)該是干凈、準(zhǔn)確、可復(fù)用。
7. /diff：讓 AI 解釋變更，而不是盲目提交
寫(xiě)代碼只是第一步。
工程里更重要的是知道：
改了哪些文件； 為什么這么改； 有沒(méi)有引入風(fēng)險(xiǎn)； 測(cè)試是否覆蓋； 提交信息是否清楚。
可以用：
/diff
然后繼續(xù)問(wèn)：
請(qǐng)基于當(dāng)前 diff 總結(jié)這次變更，指出潛在風(fēng)險(xiǎn)，并生成一個(gè) Conventional Commit message。
推薦的 Git 工作流是：
/diff請(qǐng)總結(jié)當(dāng)前變更，并生成提交信息。!git add -A!git commit -m "feat: xxx"
不要讓 AI 在你沒(méi)看 diff 的情況下直接提交。
這就像讓一個(gè)新同事不經(jīng)過(guò) Code Review 直接合并代碼。
AI 可以幫你提高效率，但不能替你承擔(dān)工程責(zé)任。
8. Shift + Tab：自動(dòng)接受修改，但別一上來(lái)就開(kāi)
Claude Code 默認(rèn)在修改文件前會(huì)詢(xún)問(wèn)確認(rèn)。
這是好事。
學(xué)習(xí)階段建議保留默認(rèn)模式，因?yàn)槟阈枰浪降滓氖裁础?/p>
熟悉之后，可以用 Shift + Tab 開(kāi)啟自動(dòng)接受模式，減少反復(fù)確認(rèn)。
但開(kāi)啟自動(dòng)接受前，最好滿(mǎn)足幾個(gè)條件：
當(dāng)前 Git 狀態(tài)是干凈的； 你清楚它要修改哪些文件； 任務(wù)范圍比較明確； 不是在改部署、權(quán)限、支付、生產(chǎn)配置等敏感邏輯。
否則自動(dòng)接受很容易變成自動(dòng)翻車(chē)。
9. Ctrl + C：方向錯(cuò)了就及時(shí)剎車(chē)
當(dāng) Claude Code 正在執(zhí)行長(zhǎng)任務(wù)，或者你發(fā)現(xiàn)它理解錯(cuò)了，不要等它全部做完。
直接 Ctrl + C 停止當(dāng)前操作。
它和 Esc 的區(qū)別是：
Ctrl + C：停止正在執(zhí)行的操作雙擊 Esc：回退上一輪對(duì)話(huà)狀態(tài)
一個(gè)是剎車(chē)，一個(gè)是回退。
用 AI 編程，一定要有打斷意識(shí)。
很多問(wèn)題不是 AI 一開(kāi)始就不可控，而是人發(fā)現(xiàn)方向不對(duì)后，沒(méi)有及時(shí)停下來(lái)。
10. /context：看清 Token 到底花在哪
當(dāng)你覺(jué)得 Claude Code 響應(yīng)慢、成本高、回答變亂，可以用：
/context
它會(huì)顯示當(dāng)前上下文使用情況。
重點(diǎn)看幾個(gè)信息：
Token 使用率； 引用了多少文件； 哪些文件占用最多上下文； 是否讀入了無(wú)關(guān)目錄。
如果發(fā)現(xiàn) node_modules、構(gòu)建產(chǎn)物、日志文件、大型資源文件進(jìn)入上下文，那就說(shuō)明 .claudeignore 需要調(diào)整。
Token 不只是成本問(wèn)題，也是質(zhì)量問(wèn)題。
上下文越臟，AI 越容易抓錯(cuò)重點(diǎn)。
11. /resume：多任務(wù)切換時(shí)保留上下文
當(dāng)你在多個(gè)任務(wù)之間來(lái)回切換，可以用：
/resume
它可以幫助你回到之前的會(huì)話(huà)狀態(tài)。
比如你剛才在修登錄 bug，中間臨時(shí)問(wèn)了一個(gè)算法問(wèn)題，之后想回到原來(lái)的修復(fù)任務(wù)，就可以用 /resume。
對(duì)于長(zhǎng)周期任務(wù)來(lái)說(shuō)，這個(gè)命令可以減少重復(fù)解釋上下文的成本。
但如果會(huì)話(huà)已經(jīng)很長(zhǎng)，建議先 /compact，再繼續(xù)后續(xù)任務(wù)。
六、CLAUDE.md：決定 AI 能不能真正理解項(xiàng)目
如果一個(gè)項(xiàng)目沒(méi)有 CLAUDE.md，Claude Code 對(duì)項(xiàng)目的理解主要依賴(lài)臨時(shí)讀取文件和你的描述。
這就很容易出現(xiàn)幾個(gè)問(wèn)題：
每次都要解釋技術(shù)棧； 每次都要告訴它測(cè)試命令； 每次都要說(shuō)明代碼規(guī)范； 每次都要提醒它目錄結(jié)構(gòu)； 多人協(xié)作時(shí)規(guī)則不統(tǒng)一。
一個(gè)好的 CLAUDE.md，至少應(yīng)該包含這些內(nèi)容：
# 項(xiàng)目名稱(chēng)## 項(xiàng)目概述一句話(huà)說(shuō)明項(xiàng)目做什么，服務(wù)什么用戶(hù)，核心業(yè)務(wù)是什么。## 技術(shù)棧- 前端框架- 后端框架- 數(shù)據(jù)庫(kù)- 測(cè)試框架- 構(gòu)建工具- 部署方式## 項(xiàng)目結(jié)構(gòu)說(shuō)明 src、tests、components、services、api 等目錄的用途。## 常用命令- 啟動(dòng)開(kāi)發(fā)環(huán)境- 運(yùn)行測(cè)試- 類(lèi)型檢查- 代碼格式化- 生產(chǎn)構(gòu)建## 編碼規(guī)范- 命名規(guī)則- 組件寫(xiě)法- API 封裝方式- 錯(cuò)誤處理方式- 日志規(guī)范## 測(cè)試規(guī)范- 單元測(cè)試放哪里- E2E 測(cè)試怎么跑- 哪些模塊必須補(bǔ)測(cè)試- Bug 修復(fù)是否需要回歸測(cè)試## 常見(jiàn)坑- 哪些文件不要改- 哪些接口有歷史兼容問(wèn)題- 哪些配置涉及生產(chǎn)環(huán)境
這份文件不是給老板看的，也不是給客戶(hù)看的。
它是寫(xiě)給 AI 的項(xiàng)目說(shuō)明書(shū)。
越清楚，Claude Code 越不容易亂來(lái)。
七、.claudeignore：別讓上下文變成垃圾桶
Claude Code 能讀取項(xiàng)目上下文，但不是所有文件都應(yīng)該讓它讀。
很多項(xiàng)目 Token 消耗異常高，不是因?yàn)槿蝿?wù)復(fù)雜，而是因?yàn)樯舷挛睦锘爝M(jìn)了大量沒(méi)用內(nèi)容。
建議 .claudeignore 至少包含：
node_modules/dist/build/.next/coverage/*.log.env.env.local.vscode/.idea/*.png*.jpg*.jpeg*.gif*.mp4
這些文件的問(wèn)題很明顯：
依賴(lài)目錄太大； 構(gòu)建產(chǎn)物沒(méi)有必要； 日志文件噪音多； 環(huán)境變量可能包含敏感信息； 圖片視頻對(duì)多數(shù)代碼任務(wù)沒(méi)幫助。
合理配置 .claudeignore，通常能帶來(lái)三個(gè)變化：
響應(yīng)更快； Token 消耗更低； 回答更聚焦。
很多人只關(guān)注提示詞怎么寫(xiě)，卻忽略了上下文治理。
但在真實(shí)工程里，上下文治理比提示詞更重要。
八、權(quán)限配置：讓 AI 能干活，但不能亂來(lái)
Claude Code 可以執(zhí)行命令、修改文件，所以權(quán)限配置不能忽視。
權(quán)限通常分成三類(lèi)：
{ "permissions": { "allow": [], "ask": [], "deny": [] }}
可以這樣理解：
allow：安全操作，自動(dòng)允許； ask：有風(fēng)險(xiǎn)操作，執(zhí)行前確認(rèn)； deny：危險(xiǎn)操作，直接禁止。
例如：
{ "permissions": { "allow": [ "Bash(git status)", "Bash(git diff:*)", "Bash(npm test:*)", "Bash(npm run lint:*)", "Edit(src/**/*.{ts,tsx})", "Edit(tests/**/*.test.ts)" ], "ask": [ "Bash(git commit:*)", "Bash(git push:*)", "Bash(npm install:*)", "Bash(npm run build)", "Edit(package.json)", "Edit(tsconfig.json)" ], "deny": [ "Bash(rm -rf:*)", "Bash(sudo:*)", "Bash(curl * | sh)", "Bash(wget * | sh)", "Read(.env)" ] }}
這個(gè)配置背后的原則很簡(jiǎn)單：
只讀操作可以放寬； 測(cè)試和 lint 可以放寬； 提交、推送、安裝依賴(lài)要確認(rèn)； 危險(xiǎn)命令和敏感文件要禁止。
AI 工具越強(qiáng)，越要有邊界。
不是不信任 AI，而是不應(yīng)該讓任何工具繞過(guò)工程安全底線(xiàn)。
九、測(cè)試開(kāi)發(fā)視角：Claude Code 最值得用在哪些場(chǎng)景
對(duì)測(cè)試開(kāi)發(fā)工程師來(lái)說(shuō)，Claude Code 不是只用來(lái)寫(xiě)業(yè)務(wù)代碼的。
它更適合放到測(cè)試工程鏈路里。
1. 輔助生成自動(dòng)化測(cè)試用例
比如：
@src/services/order.ts請(qǐng)為訂單創(chuàng)建邏輯生成單元測(cè)試，重點(diǎn)覆蓋邊界值、異常輸入、狀態(tài)流轉(zhuǎn)和重復(fù)提交。
它可以根據(jù)代碼邏輯反推測(cè)試場(chǎng)景。
但注意，AI 生成的用例不能直接當(dāng)最終結(jié)果。
測(cè)試人員要重點(diǎn)審核：
是否覆蓋核心業(yè)務(wù)風(fēng)險(xiǎn)； 斷言是否有意義； 邊界條件是否完整； 異常路徑是否真實(shí)存在； 測(cè)試數(shù)據(jù)是否可維護(hù)。
AI 適合補(bǔ)充思路，不適合替你做最終質(zhì)量判斷。
2. 分析失敗用例
可以這樣用：
!npm test測(cè)試失敗了，請(qǐng)分析失敗原因，判斷是業(yè)務(wù)邏輯問(wèn)題、測(cè)試斷言問(wèn)題，還是環(huán)境問(wèn)題。
這類(lèi)場(chǎng)景非常適合 Claude Code。
因?yàn)樗梢越Y(jié)合測(cè)試輸出、源碼和測(cè)試文件一起分析。
傳統(tǒng)流程里，你可能需要復(fù)制日志、打開(kāi)文件、搜索調(diào)用鏈、重新跑命令。
Claude Code 能把這些動(dòng)作合在一個(gè)會(huì)話(huà)里。
3. 生成接口自動(dòng)化腳本
如果項(xiàng)目里有 OpenAPI、Swagger 或接口文檔，可以這樣問(wèn)：
@openapi.yaml請(qǐng)基于這個(gè)接口文檔生成 Pytest + Requests 的接口測(cè)試腳本。要求覆蓋正常場(chǎng)景、參數(shù)缺失、非法參數(shù)、權(quán)限異常和冪等性問(wèn)題。
它可以快速生成接口測(cè)試初稿。
再由測(cè)試人員補(bǔ)充：
業(yè)務(wù)前置數(shù)據(jù)； 鑒權(quán)邏輯； 環(huán)境變量； 數(shù)據(jù)清理； 接口依賴(lài)關(guān)系； 斷言策略。
這樣比從零手寫(xiě)腳本效率高很多。
4. 優(yōu)化 UI 自動(dòng)化穩(wěn)定性
UI 自動(dòng)化最常見(jiàn)的問(wèn)題不是寫(xiě)不出來(lái)，而是不穩(wěn)定。
比如 Playwright 用例偶現(xiàn)失敗，可以讓 Claude Code 分析：
@tests/e2e/login.spec.ts這個(gè) Playwright 用例最近經(jīng)常失敗，請(qǐng)分析可能的不穩(wěn)定原因，并優(yōu)化等待策略。
它可能會(huì)從這些角度給出建議：
定位器是否穩(wěn)定； 是否依賴(lài)固定 sleep； 頁(yè)面跳轉(zhuǎn)是否等待完成； 接口返回是否有異步延遲； 測(cè)試數(shù)據(jù)是否相互污染； 斷言是否過(guò)早執(zhí)行。
這類(lèi)問(wèn)題非常貼近測(cè)試開(kāi)發(fā)日常。
5. 重構(gòu)測(cè)試框架目錄
當(dāng)測(cè)試代碼越寫(xiě)越多，目錄結(jié)構(gòu)往往會(huì)變亂。
可以讓 Claude Code 先做分析：
@tests/請(qǐng)分析當(dāng)前測(cè)試目錄結(jié)構(gòu)，給出一套更適合維護(hù)的分層方案。
它可以從這些維度整理：
單元測(cè)試； 接口測(cè)試； E2E 測(cè)試； 測(cè)試數(shù)據(jù)； 公共 fixture； 頁(yè)面對(duì)象模型； 斷言工具； 測(cè)試報(bào)告。
這對(duì)測(cè)試框架治理很有幫助。
6. 生成缺陷復(fù)盤(pán)和回歸建議
Bug 修完之后，不要只停留在代碼修復(fù)。
可以基于 diff 生成復(fù)盤(pán)：
/diff請(qǐng)基于這次 bug 修復(fù)，生成一份缺陷復(fù)盤(pán)文檔。包括問(wèn)題現(xiàn)象、根因分析、影響范圍、修復(fù)方案和回歸測(cè)試建議。
這類(lèi)能力非常適合團(tuán)隊(duì)沉淀知識(shí)庫(kù)。
尤其是測(cè)試團(tuán)隊(duì)，很多經(jīng)驗(yàn)如果不沉淀，就會(huì)一直停留在個(gè)人腦子里。
Claude Code 可以幫助把一次修復(fù)變成可復(fù)用的團(tuán)隊(duì)資產(chǎn)。
十、一個(gè)更適合測(cè)試開(kāi)發(fā)的 Claude Code 工作流
如果從測(cè)試開(kāi)發(fā)角度使用 Claude Code，我更建議采用下面這條流程：
[圖片上傳中...(image-b2bfcf-1779074854436-1)]
這里面，AI 不是替代測(cè)試工程師。
AI 負(fù)責(zé)提高產(chǎn)出速度。
人負(fù)責(zé)判斷質(zhì)量。
哪些場(chǎng)景必須測(cè)； 哪些風(fēng)險(xiǎn)不能漏； 哪些斷言才有業(yè)務(wù)意義； 哪些失敗屬于環(huán)境問(wèn)題； 哪些缺陷值得復(fù)盤(pán)； 哪些自動(dòng)化腳本需要長(zhǎng)期維護(hù)。
這些仍然是測(cè)試開(kāi)發(fā)工程師的核心價(jià)值。
十一、Claude Code 用不好，往往不是工具問(wèn)題
很多人用 Claude Code 用得淺，不是因?yàn)楣ぞ卟恍?，而是使用方式還停留在問(wèn)答模式。
常見(jiàn)問(wèn)題有幾個(gè)。
1. 需求太模糊
比如：
幫我優(yōu)化一下代碼。
這類(lèi)問(wèn)題很難得到高質(zhì)量結(jié)果。
更好的寫(xiě)法是：
@src/components/UserList.tsx請(qǐng)從渲染性能、狀態(tài)管理、重復(fù)邏輯和可測(cè)試性四個(gè)角度審查這個(gè)組件，并給出可執(zhí)行的修改方案。
2. 不給上下文
如果不告訴它項(xiàng)目結(jié)構(gòu)、相關(guān)文件、測(cè)試命令、業(yè)務(wù)規(guī)則，它只能泛泛而談。
AI 不是神，它需要上下文。
但上下文不是越多越好，而是越準(zhǔn)確越好。
3. 不看 diff
讓 Claude Code 改完代碼之后，一定要看 diff。
不看 diff，就相當(dāng)于讓一個(gè)剛接觸項(xiàng)目的人直接提交代碼。
這是工程風(fēng)險(xiǎn)，不是工具問(wèn)題。
4. 不配置 .claudeignore
把 node_modules、構(gòu)建產(chǎn)物、日志、臨時(shí)文件都丟進(jìn)上下文，只會(huì)讓 AI 越來(lái)越糊涂。
很多回答不準(zhǔn)，根源不是模型能力，而是上下文太臟。
5. 沒(méi)有 Git 保護(hù)
AI 改代碼之前，至少要知道怎么回滾。
建議養(yǎng)成習(xí)慣：
git status
確認(rèn)當(dāng)前分支狀態(tài)。
大改之前先提交或 stash。
這是使用任何 AI 編程工具的底線(xiàn)。
十二、最后：AI 編程的門(mén)檻正在變
Claude Code 的出現(xiàn)，說(shuō)明 AI 編程正在發(fā)生一個(gè)變化。
過(guò)去大家關(guān)心的是：
AI 能不能寫(xiě)代碼； AI 能不能補(bǔ)全函數(shù)； AI 能不能解釋報(bào)錯(cuò)； AI 能不能生成腳本。
現(xiàn)在更應(yīng)該關(guān)心的是：
AI 能不能理解項(xiàng)目； 能不能遵守團(tuán)隊(duì)規(guī)范； 能不能參與測(cè)試閉環(huán)； 能不能看懂 diff； 能不能管理上下文； 能不能在權(quán)限邊界內(nèi)執(zhí)行任務(wù)； 能不能把開(kāi)發(fā)、測(cè)試、提交、復(fù)盤(pán)串起來(lái)。
這才是 Claude Code 值得學(xué)習(xí)的地方。
它不是讓工程能力變得不重要。
恰恰相反，它會(huì)放大工程能力的差距。
懂項(xiàng)目結(jié)構(gòu)的人，能寫(xiě)出更好的 CLAUDE.md。 懂測(cè)試策略的人，能判斷 AI 生成的用例是否有效。 懂 Git 工作流的人，敢讓 AI 參與真實(shí)項(xiàng)目。 懂上下文治理的人，能控制成本和質(zhì)量。 懂權(quán)限邊界的人，能讓 AI 高效但不失控。
未來(lái)的差距，不會(huì)只體現(xiàn)在“誰(shuí)會(huì)用 AI 寫(xiě)代碼”。
更大的差距會(huì)體現(xiàn)在：
誰(shuí)能把 AI 放進(jìn)自己的工程流程里，形成穩(wěn)定、可控、可復(fù)用的生產(chǎn)力。
Claude Code 最強(qiáng)的地方，也許不是寫(xiě)代碼本身。
而是它讓我們重新思考：
一個(gè)開(kāi)發(fā)者、一個(gè)測(cè)試開(kāi)發(fā)工程師，應(yīng)該如何把 AI 納入真實(shí)的工程協(xié)作流程。
本文部分內(nèi)容參考了霍格沃茲測(cè)試開(kāi)發(fā)學(xué)社整理的相關(guān)技術(shù)資料，主要涉及軟件測(cè)試、自動(dòng)化測(cè)試、測(cè)試開(kāi)發(fā)及 AI 測(cè)試等內(nèi)容，側(cè)重測(cè)試實(shí)踐、工具應(yīng)用與工程經(jīng)驗(yàn)整理。
