1. 先說(shuō)結(jié)論我為什么離不開(kāi)這個(gè)終端 Agent真正讓我下決心把 Claude Code 放進(jìn)常用工具箱的不是某次驚艷的演示而是一個(gè)很普通的下午。當(dāng)時(shí)我要把一個(gè)老模塊里的接口字段從下劃線風(fēng)格改成駝峰風(fēng)格牽扯到調(diào)用方、Mock 數(shù)據(jù)和十幾條測(cè)試用例。原本預(yù)估要忙到下班結(jié)果我給它寫清楚目標(biāo)和邊界它自己列文件、改代碼、跑測(cè)試最后把失敗的用例一條條修完。我坐在旁邊主要是確認(rèn)哪些文件可以動(dòng)順帶 review diff。那之后我意識(shí)到它不是一個(gè)“更聰明的聊天窗口”而是一個(gè)真正會(huì)動(dòng)手干活的終端 Agent。它能讀項(xiàng)目里的文件、改代碼、執(zhí)行命令、看報(bào)錯(cuò)日志然后基于執(zhí)行結(jié)果繼續(xù)調(diào)整。換句話說(shuō)它給的不只是“建議”而是已經(jīng)落地的改動(dòng)。這篇內(nèi)容不是什么廣告也不打算復(fù)述官方文檔。我想從使用者的角度把“為什么它值得進(jìn)入常用工具箱”“怎么配置才不翻車”“哪些工作流真正讓效率翻倍”以及“我踩過(guò)哪些坑”講清楚。如果你已經(jīng)會(huì)基本命令行操作也愿意接受“AI 寫代碼、人類做 review”的協(xié)作方式大概率能找到一點(diǎn)能直接抄作業(yè)的東西。1.1 它和普通對(duì)話式 AI 的根本區(qū)別很多同類工具給我的體驗(yàn)是“你說(shuō)一句它答一段然后你復(fù)制粘貼”。遇到復(fù)雜點(diǎn)的需求還得自己把代碼貼進(jìn)去、把報(bào)錯(cuò)貼出來(lái)來(lái)來(lái)回回像在搬磚。Claude Code 不太一樣它生活在終端里天然能接觸整個(gè)項(xiàng)目上下文。描述一個(gè)任務(wù)后它會(huì)自己去看代碼結(jié)構(gòu)、定位相關(guān)文件甚至直接執(zhí)行測(cè)試命令。這個(gè)過(guò)程最值錢的地方在于閉環(huán)它改完代碼會(huì)跑一遍驗(yàn)證看到報(bào)錯(cuò)會(huì)繼續(xù)回退或修復(fù)而不是停在“我建議你這樣做”的層面。這種能力上的差異決定了它能承擔(dān)“結(jié)對(duì)編程搭子”的角色而不只是個(gè)陪聊助手。我把這種差異理解為“手”和“嘴”的區(qū)別。普通對(duì)話式 AI 只有嘴它能告訴你方法但操作還得自己做Claude Code 多了一雙手它可以翻文件、跑命令、檢查結(jié)果。哪怕只負(fù)責(zé)一些重復(fù)性勞動(dòng)比如改字段名、補(bǔ)測(cè)試、修 lint就已經(jīng)能省下大量時(shí)間。1.2 三個(gè)真實(shí)場(chǎng)景里我明確感覺(jué)到“效率翻倍”第一個(gè)場(chǎng)景是跨文件重構(gòu)。以前做 API 參數(shù)改名最怕的就是漏掉幾個(gè)調(diào)用點(diǎn)?，F(xiàn)在我會(huì)把目標(biāo)、影響范圍和驗(yàn)收方式寫清楚讓它先掃一遍所有引用位置再動(dòng)手改。最后我再人肉掃一遍 diff負(fù)擔(dān)小了很多。第二個(gè)場(chǎng)景是“根據(jù)報(bào)錯(cuò)自動(dòng)修”。本地跑測(cè)試掛了我把失敗日志貼給它它會(huì)沿著調(diào)用鏈找原因、改代碼、重新跑。尤其是那種“測(cè)試全紅但人眼一時(shí)半會(huì)看不出問(wèn)題”的情況它即使不能一次修好也能把排查方向壓縮到很小范圍。第三個(gè)場(chǎng)景是給老代碼補(bǔ)上下文。不是每個(gè)項(xiàng)目都有完整注釋很多歷史邏輯全靠人肉考古。我會(huì)讓它讀取某個(gè)函數(shù)的所有調(diào)用方反推這個(gè)函數(shù)到底被誰(shuí)依賴、行為變化會(huì)波及哪一層。這個(gè)動(dòng)作單獨(dú)靠讀代碼也能做但速度完全不一樣。1.3 適合誰(shuí)不適合誰(shuí)我自己的體會(huì)是Claude Code 最適合那種“已經(jīng)有常識(shí)性工程基礎(chǔ)”的人。至少你得看得懂git diff知道測(cè)試為什么會(huì)失敗并且愿意在 AI 給出改動(dòng)后做 review。如果你完全不懂命令行也不了解自己代碼倉(cāng)庫(kù)的結(jié)構(gòu)那它反而會(huì)放大混亂。反過(guò)來(lái)如果你的項(xiàng)目沒(méi)有任何測(cè)試、也沒(méi)有 Git 歷史我建議先把它當(dāng)作“代碼閱讀助手”用別一上來(lái)讓它自動(dòng)化改東西。沒(méi)有驗(yàn)證手段就很容易出現(xiàn)“代碼看起來(lái)合理實(shí)際已經(jīng)壞了”的情況。2. 從安裝到第一次跑通先建立“最小可信鏈路”很多人拿到這類工具的第一步就是跑個(gè) Demo問(wèn)一些網(wǎng)上隨便就能搜到的入門問(wèn)題然后就沒(méi)有然后了。我的建議相反第一次使用應(yīng)該從一個(gè)能立刻在真實(shí)項(xiàng)目里落地的小任務(wù)開(kāi)始哪怕它只是修一個(gè)明顯的 bug。2.1 安裝、登錄和模型選擇先跑通最基礎(chǔ)的鏈路我當(dāng)時(shí)的步驟不算復(fù)雜開(kāi)發(fā)機(jī)是 macOSGit 和 Node.js 環(huán)境都是現(xiàn)成的按官方文檔把安裝命令執(zhí)行完然后在終端輸入claude進(jìn)入交互式會(huì)話。首次使用會(huì)有一個(gè)登錄授權(quán)流程完成之后它會(huì)生成配置文件記錄授權(quán)信息和默認(rèn)參數(shù)。這里有一個(gè)容易被忽略的點(diǎn)首次運(yùn)行最好確認(rèn)一下它使用的模型版本。不同版本的能力差異不小尤其是“上下文長(zhǎng)度”和“工具調(diào)用的穩(wěn)定度”。如果你的會(huì)話里經(jīng)常需要讀大量文件選一個(gè)上下文窗口更大的配置會(huì)更從容。這些信息通常在會(huì)話啟動(dòng)時(shí)能看到也可以在配置文件里改。我不建議一上來(lái)就花很多時(shí)間研究所有參數(shù)。先跑通最小鏈路再慢慢調(diào)優(yōu)化項(xiàng)。工具是拿來(lái)用的不是拿來(lái)研究配置的。2.2 第一次任務(wù)不要直接讓它“全權(quán)執(zhí)行”很多人第一次上手就喜歡說(shuō)“幫我優(yōu)化整個(gè)項(xiàng)目的性能”。這種任務(wù)顆粒度太大AI 大概率會(huì)順著自己的理解亂發(fā)揮。比較穩(wěn)妥的做法是給它一個(gè)小而明確的 bug比如“修改src/utils/formatDate.ts里對(duì)非法日期處理不當(dāng)?shù)膯?wèn)題”。給它任務(wù)時(shí)最好明確說(shuō)“先不要改先給我方案”。等它列出要改哪個(gè)文件、怎么改、影響哪些調(diào)用方你確認(rèn)沒(méi)問(wèn)題后再讓它執(zhí)行。這個(gè)習(xí)慣能讓你在它真正動(dòng)手前就建立信任感。第一次任務(wù)不建議直接開(kāi)“完全自動(dòng)執(zhí)行”哪怕它彈權(quán)限確認(rèn)很頻繁也比事后后悔強(qiáng)。2.3 CLAUDE.md一份給 Agent 看的項(xiàng)目說(shuō)明書我后來(lái)才發(fā)現(xiàn)真正影響長(zhǎng)期體驗(yàn)的不是某個(gè) prompt 技巧而是有沒(méi)有寫一份項(xiàng)目說(shuō)明書。這個(gè)文件通常叫CLAUDE.md可以放在項(xiàng)目根目錄啟動(dòng)會(huì)話的時(shí)候它會(huì)讀到這里面的項(xiàng)目背景和約定。我給自己某個(gè)內(nèi)部項(xiàng)目寫過(guò)一份很精簡(jiǎn)的版本內(nèi)容大致是這樣項(xiàng)目某內(nèi)部訂單查詢平臺(tái) 技術(shù)棧TypeScript React Python FastAPI 架構(gòu)約定 - API 層統(tǒng)一走 src/api/request.ts 的封裝 - 組件內(nèi)禁止直接發(fā) HTTP 請(qǐng)求 - 數(shù)據(jù)庫(kù)查詢不允許寫在業(yè)務(wù)組件里 - 所有接口變更需要同步更新 OpenAPI 描述 - 測(cè)試命令pnpm test:unit - 構(gòu)建命令pnpm build別小看這幾行字。沒(méi)有它的時(shí)候Claude Code 只能靠猜有了它它在動(dòng)手前就大概知道項(xiàng)目長(zhǎng)什么樣、命令怎么跑、邊界在哪里。對(duì)效率的影響幾乎是決定性的尤其當(dāng)你隔幾天再回到某個(gè)項(xiàng)目時(shí)這份文件能幫它快速恢復(fù)“記憶”。2.4 環(huán)境里最常見(jiàn)的三個(gè)坑第一個(gè)坑是 Node.js 版本太舊。有些依賴對(duì)版本有要求安裝或初始化階段報(bào)錯(cuò)看起來(lái)像工具問(wèn)題實(shí)際是環(huán)境問(wèn)題。建議先檢查基礎(chǔ)環(huán)境版本再排查其他問(wèn)題。第二個(gè)坑是項(xiàng)目目錄沒(méi)有初始化 Git。這個(gè)工具很多操作依賴 Git 來(lái)做 diff 和回退沒(méi)有版本管理兜底它自己也會(huì)變得更保守甚至拒絕執(zhí)行一些有風(fēng)險(xiǎn)的修改。所以我的個(gè)人準(zhǔn)則是只有已經(jīng)納入 Git 管理的項(xiàng)目才適合讓它自動(dòng)改代碼。第三個(gè)坑是權(quán)限確認(rèn)時(shí)看不清路徑。默認(rèn)情況下它執(zhí)行命令前會(huì)彈權(quán)限確認(rèn)但如果你沒(méi)有仔細(xì)看命令的全貌很容易誤放行。后面會(huì)專門講這個(gè)這里先提一句睜大眼睛看路徑永遠(yuǎn)是第一道防線。3. 把“效率翻倍”坐實(shí)的工作流安裝只是開(kāi)始真正讓效率翻倍的不是工具本身而是你使用它的方式。我嘗試過(guò)幾種不同的協(xié)作模式最后形成的套路可以總結(jié)成一句話目標(biāo)寫清楚邊界寫清楚驗(yàn)收方式寫清楚。3.1 按“目標(biāo)-邊界-驗(yàn)收方式”三段式寫任務(wù)不要只說(shuō)“幫我優(yōu)化訂單查詢”這種話連人類同事聽(tīng)了都頭痛。更好的寫法是像驗(yàn)收單一樣把需求拆成三個(gè)部分。舉個(gè)例子目標(biāo)把訂單管理頁(yè)的列表查詢改成服務(wù)端分頁(yè)。 約束不要?jiǎng)佑唵卧斍榻涌诓灰略龅谌揭蕾嚒?驗(yàn)收pnpm test:unit 通過(guò)pnpm build 通過(guò)。給邊界比給方案重要。很多人以為自己需要描述“怎么改”其實(shí) AI 最需要的恰恰是“哪些地方不許碰”。有了邊界它不會(huì)順手把無(wú)關(guān)代碼也重構(gòu)一遍有了驗(yàn)收方式它改完就知道怎么證明自己改對(duì)了。這個(gè)習(xí)慣看起來(lái)只是寫 prompt 的方式變了實(shí)際影響非常大。我遇到的大部分“AI 亂改代碼”都不是模型本身能力不夠而是我給的指令太模糊。把任務(wù)拆成可驗(yàn)收的小塊哪怕完全不用 AI自己寫代碼也會(huì)更清晰。3.2 讓它先讀關(guān)鍵文件再?zèng)Q定下一步不要指望它靠“猜”知道代碼在哪。效率最高的做法是主動(dòng)把相關(guān)文件路徑丟給它。你可以說(shuō)“先讀一下src/api/order.ts和src/pages/order/list.tsx我需要確認(rèn)分頁(yè)參數(shù)是怎么傳入的”它會(huì)先讀這些文件再給出結(jié)論。這一步對(duì)效率的影響特別大。它每次盲搜文件都要消耗上下文資源路徑給得越準(zhǔn)它越能把精力集中在真正的問(wèn)題上。時(shí)間長(zhǎng)了你會(huì)發(fā)現(xiàn)寫完一份清晰任務(wù)描述不亞于你提前完成了一半的設(shè)計(jì)工作。3.3 把“驗(yàn)證”變成任務(wù)的一等公民很多人在 prompt 里只寫“改代碼”不寫“怎么證明改對(duì)了”。結(jié)果它改完你還要自己手動(dòng)跑測(cè)試、看結(jié)果、再讓它繼續(xù)改。這個(gè)來(lái)回是非常浪費(fèi)時(shí)間的。我的習(xí)慣是直接把驗(yàn)證動(dòng)作寫進(jìn)任務(wù)里。比如讓它改完代碼后執(zhí)行對(duì)應(yīng)測(cè)試文件的用例再跑一次構(gòu)建。對(duì)于沒(méi)有測(cè)試覆蓋的代碼我會(huì)要求它先寫一個(gè)最小復(fù)現(xiàn)腳本或者至少列出它可以執(zhí)行哪些檢查命令。這樣它就不是“盲改”而是帶著驗(yàn)證目標(biāo)去改。3.4 把高頻操作固化成自定義命令有一段時(shí)間我發(fā)現(xiàn)自己在重復(fù)輸入差不多的指令比如“看看當(dāng)前 git diff檢查有沒(méi)有調(diào)試代碼只報(bào)告問(wèn)題不要改代碼”。后來(lái)我把這類操作做成了自定義命令然后在會(huì)話里直接觸發(fā)。以我接觸的版本為例自定義命令文件通?？梢苑旁陧?xiàng)目的.claude/commands/目錄下文件名就是命令名。我建了一個(gè)review.md內(nèi)容大概是請(qǐng)按以下順序執(zhí)行 1. 查看當(dāng)前 git diff 2. 檢查是否有調(diào)試代碼、console.log、臨時(shí)寫死的邏輯 3. 檢查測(cè)試斷言是否被無(wú)故刪改 4. 輸出風(fēng)險(xiǎn)點(diǎn)清單不要直接修改代碼這樣我在會(huì)話里輸入/review它就會(huì)按這個(gè)流程執(zhí)行。效果相當(dāng)于把“團(tuán)隊(duì) review 習(xí)慣”沉淀成了自動(dòng)化模板每次使用都穩(wěn)定一致。這類自定義命令非常適合團(tuán)隊(duì)統(tǒng)一協(xié)作口徑。4. 權(quán)限和安全效率翻倍的前提是“翻車可控”把 AI 放進(jìn)工具箱最大的心理障礙其實(shí)是“它亂動(dòng)了我的代碼怎么辦”。我也經(jīng)歷過(guò)這個(gè)階段后來(lái)發(fā)現(xiàn)只要權(quán)限策略設(shè)置合理失控風(fēng)險(xiǎn)是可以控制的。核心原則是效率翻倍的前提是翻車可控。4.1 我實(shí)際采用的權(quán)限策略最開(kāi)始我會(huì)用逐次確認(rèn)模式每個(gè)命令都彈出來(lái)問(wèn)一下。這個(gè)模式雖然煩但能幫我建立對(duì)它的信任感。用久了以后我開(kāi)始對(duì)一部分明確安全的命令開(kāi)放自動(dòng)執(zhí)行比如讀文件、搜索代碼、跑測(cè)試、跑 lint。但我?guī)缀醪挥媚欠N“跳過(guò)全部權(quán)限確認(rèn)”的模式尤其是在項(xiàng)目里還掛著數(shù)據(jù)庫(kù)配置、部署腳本和線上環(huán)境的時(shí)候。完全自動(dòng)執(zhí)行看似方便實(shí)際上等于把整個(gè)倉(cāng)庫(kù)的控制權(quán)交給了一個(gè)可能產(chǎn)生誤判的 Agent。省下的十分鐘可能要用好幾個(gè)小時(shí)去救倉(cāng)庫(kù)。4.2 哪些命令該放行哪些該攔截我自己總結(jié)過(guò)一份簡(jiǎn)單的判斷表傾向于放行的命令類型是只讀和驗(yàn)證類的需要謹(jǐn)慎的是會(huì)修改狀態(tài)的操作而涉及不可逆行為的則直接攔截。命令類型我的默認(rèn)策略原因讀文件、grep 搜索、查看 git diff放行不會(huì)產(chǎn)生副作用能幫助它理解上下文跑測(cè)試、lint、build放行驗(yàn)證動(dòng)作失敗了也能快速定位安裝依賴、修改 package.json每次確認(rèn)依賴變更影響面很大需要看 diff批量重命名、刪除文件、強(qiáng)制 push人工 review不可逆或影響面大必須人確認(rèn)涉及生產(chǎn)環(huán)境、數(shù)據(jù)庫(kù)變更的命令直接拒絕超出代碼范圍風(fēng)險(xiǎn)不可控這張表不是死的每個(gè)項(xiàng)目風(fēng)險(xiǎn)不一樣。但它能幫你在“效率”和“安全”之間找到一個(gè)適合自己的平衡點(diǎn)。我自己的體會(huì)是允許它多跑測(cè)試一定不會(huì)虧但涉及文件刪除和遠(yuǎn)程分支操作時(shí)再麻煩也要人工過(guò)一遍。4.3 成本與長(zhǎng)任務(wù)控制用這類工具還有一個(gè)現(xiàn)實(shí)問(wèn)題成本。長(zhǎng)任務(wù)看起來(lái)很爽但上下文越長(zhǎng)消耗的資源也越多。尤其當(dāng)它反復(fù)讀取同一批大文件時(shí)我心里會(huì)默默計(jì)算“這次重構(gòu)花掉了多少 token”。我現(xiàn)在的做法是大任務(wù)一定拆成小階段。先讓它讀文件、列方案我確認(rèn)后再執(zhí)行執(zhí)行過(guò)程中如果連續(xù)多輪沒(méi)有明顯進(jìn)展我會(huì)主動(dòng)讓它停下來(lái)匯報(bào)現(xiàn)狀。不要不好意思打斷它把它看成實(shí)習(xí)生就好。實(shí)習(xí)生一頭鉆進(jìn)錯(cuò)誤的方案里及時(shí)喊停是對(duì)雙方都負(fù)責(zé)。5. 踩坑實(shí)錄三個(gè)我反復(fù)遇到的真實(shí)問(wèn)題再順手的工具用多了也會(huì)踩坑。這里我不想講那些“網(wǎng)上常見(jiàn)的怪問(wèn)題”只挑三個(gè)我實(shí)際遇到過(guò)、并且在團(tuán)隊(duì)里也反復(fù)出現(xiàn)的場(chǎng)景。5.1 它改了不在任務(wù)范圍內(nèi)的文件有一次我讓它修復(fù)某個(gè)接口的超時(shí)問(wèn)題它確實(shí)找到了問(wèn)題也把配置改了。但我后來(lái)看 git diff 時(shí)發(fā)現(xiàn)它還順手改了一個(gè)日志級(jí)別文件把 INFO 調(diào)成了 DEBUG。當(dāng)時(shí)測(cè)試通過(guò)了權(quán)限確認(rèn)也放了行問(wèn)題是在上線后才暴露的——日志量暴增磁盤差點(diǎn)被撐爆。這個(gè)坑的根因其實(shí)在我自己任務(wù)邊界寫得太窄但權(quán)限確認(rèn)時(shí)我只看了路徑前綴沒(méi)有看完整命令內(nèi)容。后來(lái)我的規(guī)則很嚴(yán)格所有涉及配置文件、依賴文件、CI/CD 文件的修改都必須展開(kāi)看完整 diff任務(wù)里也會(huì)明確加一句“只允許修改指定目錄下的文件”。5.2 會(huì)話越長(zhǎng)改錯(cuò)的概率越高有一段時(shí)間我喜歡把一整個(gè)上午的開(kāi)發(fā)任務(wù)都放在同一個(gè)會(huì)話里讓它連續(xù)改十幾個(gè)文件。前期很順后期慢慢變味它開(kāi)始把前一個(gè)文件的變量名套到后一個(gè)文件里出現(xiàn)“看起來(lái)合理但編譯不過(guò)”的代碼。原因并不復(fù)雜上下文越長(zhǎng)互相干擾的信息越多它就越容易“記串”。我現(xiàn)在會(huì)在任務(wù)進(jìn)行到某個(gè)階段后主動(dòng)壓縮上下文或者直接開(kāi)一個(gè)新會(huì)話把已經(jīng)確認(rèn)的結(jié)論粘貼過(guò)去繼續(xù)。開(kāi)新會(huì)話不是浪費(fèi)而是給 Agent 一次“清醒”的機(jī)會(huì)。5.3 和團(tuán)隊(duì)協(xié)作時(shí)的風(fēng)格摩擦工具生成代碼效率高但它默認(rèn)的輸出風(fēng)格不一定是團(tuán)隊(duì)想要的。最常見(jiàn)的問(wèn)題是 commit message:它寫得很完整甚至有幾分像論文摘要但團(tuán)隊(duì)已有的 commit 規(guī)范是“動(dòng)詞開(kāi)頭 一句話點(diǎn)明改動(dòng)”。我的解決辦法是把風(fēng)格要求寫進(jìn)項(xiàng)目說(shuō)明書和自定義命令里。比如在 CLAUDE.md 中加上“commit message 遵循 xxx 格式”或者做一個(gè)/commit命令讓它按團(tuán)隊(duì)模板生成提交信息。這類摩擦不解決AI 生成的代碼越多團(tuán)隊(duì) review 的成本反而越高。6. 進(jìn)階習(xí)慣從“會(huì)用”到“真正融入工具箱”如果你已經(jīng)能穩(wěn)定地讓它改小 bug、跑測(cè)試、寫提交說(shuō)明那我可以分享幾個(gè)讓我使用體驗(yàn)明顯上升的習(xí)慣。這些不是花哨技巧而是長(zhǎng)期用下來(lái)的沉淀。6.1 重構(gòu)前先讓它輸出“受影響面清單”現(xiàn)在我做跨文件重構(gòu)一定會(huì)先讓它進(jìn)入“只讀模式”。我會(huì)寫類似這樣的話先不要改任何代碼。請(qǐng)根據(jù)我的需求列出 1. 需要修改的文件清單 2. 每個(gè)文件涉及的函數(shù)與調(diào)用鏈 3. 潛在風(fēng)險(xiǎn)點(diǎn) 4. 建議的修改順序它列完清單后我會(huì)對(duì)照自己的判斷把不合理的地方挑出來(lái)明確了再讓它動(dòng)手。這個(gè)習(xí)慣看起來(lái)多花了幾分鐘實(shí)際上能避免大量返工。因?yàn)?AI 對(duì)“改動(dòng)波及范圍”的判斷未必準(zhǔn)但經(jīng)過(guò)一次顯式確認(rèn)后后續(xù)執(zhí)行會(huì)穩(wěn)很多。6.2 測(cè)試先行把驗(yàn)收標(biāo)準(zhǔn)前置如果一個(gè)任務(wù)需要新增邏輯我通常會(huì)讓它先補(bǔ)一個(gè)失敗測(cè)試再實(shí)現(xiàn)再跑綠。這個(gè)順序能強(qiáng)迫它對(duì)需求本身有更清晰的理解。如果測(cè)試都寫不明白說(shuō)明任務(wù)定義本身有問(wèn)題。對(duì)于已有代碼的修改我會(huì)讓它先指出當(dāng)前哪些測(cè)試覆蓋了這塊邏輯然后決定是否需要新增用例。測(cè)試不是負(fù)擔(dān)而是給 AI 一個(gè)可驗(yàn)證的反饋回路。有了這個(gè)回路它才不會(huì)在一個(gè)看似合理但錯(cuò)誤的方向上越走越遠(yuǎn)。6.3 用 alias 給高頻任務(wù)做一層“外殼”除了自定義命令我還會(huì)在自己的 shell 配置里加一些 alias。比如經(jīng)常做的 code review我會(huì)把一個(gè)固定的 prompt 壓縮成一條短命令alias reviewclaude 請(qǐng)基于當(dāng)前 git diff 做 code review只列問(wèn)題和風(fēng)險(xiǎn)點(diǎn)不要修改代碼這樣做的好處是不用每次都重復(fù)輸入那么長(zhǎng)一段說(shuō)明而且團(tuán)隊(duì)里其他成員也能共用這套習(xí)慣逐漸形成統(tǒng)一的工作流。工具越順手堅(jiān)持用下去的動(dòng)力就越大。6.4 什么時(shí)候我會(huì)刻意不用它我并不是每個(gè)任務(wù)都交給它。一個(gè)項(xiàng)目如果完全沒(méi)有測(cè)試、沒(méi)有 Git 歷史、連基本的代碼結(jié)構(gòu)都混亂不堪我不會(huì)讓 AI 動(dòng)手改而是先自己把基礎(chǔ)設(shè)施補(bǔ)起來(lái)。一個(gè)需求如果只有一句話、連我自己都說(shuō)不清楚要什么我更不會(huì)丟給 AI而是先拆解到自己能寫驗(yàn)收標(biāo)準(zhǔn)的程度。另外在保密要求比較高的環(huán)境里我也會(huì)謹(jǐn)慎評(píng)估是否適合使用外部 AI 服務(wù)。這是每個(gè)團(tuán)隊(duì)都要結(jié)合自身情況做的判斷不能只看“效率翻倍”這四個(gè)字。我現(xiàn)在的日常已經(jīng)離不了 Claude Code但它在我工作流里的定位始終很明確它是一個(gè)手腳麻利、但需要盯著的搭檔。我會(huì)把目標(biāo)和邊界講清楚盯住每一次 diff在它跑偏時(shí)及時(shí)喊停。這種協(xié)作方式一旦跑順效率提升不是多敲幾行代碼能比的而是整個(gè)節(jié)奏都變了。