上周五凌晨?jī)牲c(diǎn)，我盯著終端里 Claude Code 輸出的一堆「建議」，突然意識(shí)到一件事——我用了三個(gè)月的 Claude Code，本質(zhì)上還是在用聊天框。

那天晚上我趕著重構(gòu)一個(gè)用戶權(quán)限模塊，思路是把原來(lái)散落在十幾個(gè)文件里的權(quán)限校驗(yàn)邏輯收攏成一個(gè) middleware。我打開(kāi) Claude Code，敲了一句：「幫我重構(gòu)一下用戶權(quán)限校驗(yàn)的代碼」。它給了我一堆建議，列了五個(gè)文件要改哪些函數(shù)。我說(shuō)「好的，改吧」。它改了第一個(gè)文件，改得還行。然后我繼續(xù)說(shuō)「下一個(gè)」。改完第二個(gè)，發(fā)現(xiàn)和第一個(gè)改法有沖突。我退回去，重新說(shuō)「先看下整體結(jié)構(gòu)再改」。它又給我分析了一通。我又說(shuō)「好，按這個(gè)來(lái)」……

如此反復(fù)了四十分鐘，最后我關(guān)掉 Claude Code，自己動(dòng)手寫，二十分鐘搞定了。

這一刻我才真正理解 Claude Code 創(chuàng)始人 Boris Cherny 在斯坦福 CS146S 課上說(shuō)的那句話——很多人把 Claude Code 用成了「純聊天框」，看似提效，實(shí)則效率不高。

更扎心的是，Claude Code 日安裝量已經(jīng)達(dá)到 2900 萬(wàn)次。這意味著有海量開(kāi)發(fā)者每天都在用這個(gè)工具，但其中絕大多數(shù)人可能還在用我凌晨?jī)牲c(diǎn)的那種方式：?jiǎn)栆痪?，答一句，確認(rèn)一句，改一句。

這不是 AI 編程，這是 AI 打字。

聊天框模式的本質(zhì)問(wèn)題：人在干活，AI 打輔助

我回顧了自己那四十分鐘到底在干什么。

拆解下來(lái)，大概有這么幾個(gè)動(dòng)作：描述需求、看 AI 輸出、判斷對(duì)不對(duì)、發(fā)現(xiàn)不對(duì)就重新描述、確認(rèn)后再讓它執(zhí)行下一步、出了問(wèn)題再回退。整個(gè)過(guò)程中，決策權(quán)在我，執(zhí)行權(quán)也在逐步回到我手里。AI 最多算個(gè)打字速度快的實(shí)習(xí)生。

Lisa1399 那篇 Claude Code Best Practice 里說(shuō)得一針見(jiàn)血：「AI 提效不了多少，本質(zhì)上還是人在干活，AI 打輔助?！?/p>

我當(dāng)時(shí)的狀態(tài)就是這種——表面上每次都在用 AI，實(shí)際上我花 60% 的時(shí)間在「指揮」，AI 花 40% 的時(shí)間在「執(zhí)行」，而它執(zhí)行的每一步我都得盯著。這和我用 Stack Overflow 復(fù)制粘貼代碼沒(méi)有本質(zhì)區(qū)別，區(qū)別只是把復(fù)制粘貼變成了對(duì)話確認(rèn)。

我們生產(chǎn)環(huán)境里還遇到過(guò)更離譜的情況。有一次讓 Claude Code 幫我們改一個(gè)數(shù)據(jù)庫(kù)遷移腳本，我一句「幫我加上字段默認(rèn)值」，它把三個(gè) migration 文件都改了，我逐個(gè)確認(rèn)完，跑 migrate 發(fā)現(xiàn)順序沖突。原因是它改的是最新三個(gè) migration，但中間還有一個(gè)我沒(méi)告訴它的 migration 也依賴那個(gè)字段。

這就是聊天框模式的致命傷：AI 的視野被你的描述框死了。 你說(shuō)一句，它看一句。你不說(shuō)，它就看不到上下文之間的關(guān)聯(lián)。

Boris Cherny 的答案：不是更花哨的聊天框，而是 Agent 工作流

Boris Cherny 在斯坦福那節(jié)課上講了一個(gè)關(guān)鍵判斷：Claude Code 的答案「不是做一個(gè)更花哨的聊天框」，而是選擇不同的路徑——agentic workflow。

這句話我花了一個(gè)多月才真正消化。

什么叫 Agent 工作流？用大白話說(shuō)就是：你給 AI 一個(gè)目標(biāo)，而不是一步步指令；AI 自己規(guī)劃路徑、讀代碼、寫代碼、跑測(cè)試、修 bug，整個(gè)過(guò)程它自己閉環(huán)。

我第一次體會(huì)到 Agent 工作流的威力，是改一個(gè)從沒(méi)碰過(guò)的老項(xiàng)目。那是一個(gè)兩年前寫的 Node.js 后端，我自己都記不清代碼結(jié)構(gòu)了。如果用聊天框模式，我得先自己讀一遍代碼，再告訴 AI 每個(gè)文件要怎么改。

那我換了個(gè)方式。我在項(xiàng)目根目錄下放了一個(gè) AGENTS.md，把項(xiàng)目的技術(shù)棧、目錄約定、代碼規(guī)范寫在里面。然后直接給 Claude Code 一句話：「這個(gè)項(xiàng)目的測(cè)試覆蓋率太低了，幫我把核心業(yè)務(wù)邏輯的單元測(cè)試補(bǔ)上，測(cè)試框架用 vitest?！?/p>

它先讀了 AGENTS.md 了解項(xiàng)目結(jié)構(gòu)，然后自己掃了 src/ 下的所有文件，識(shí)別出核心業(yè)務(wù)模塊，接著逐個(gè)模塊寫測(cè)試，寫完跑測(cè)試，測(cè)試失敗就自己修。整個(gè)過(guò)程我泡了杯咖啡回來(lái)看結(jié)果，大概十五分鐘，它寫了 23 個(gè)測(cè)試用例，19 個(gè)直接通過(guò)，剩下 4 個(gè)它自己修了兩輪也過(guò)了。

同樣的事情如果用聊天框模式，我估計(jì)得花一個(gè)半小時(shí)。 因?yàn)槲业靡粋€(gè)個(gè)文件告訴它「這個(gè)要測(cè)」，一個(gè)個(gè)函數(shù)告訴它「用什么 mock」，一個(gè)個(gè)失敗告訴它「哪里錯(cuò)了」。

這就是 Agent 工作流的核心差異——AI 擁有了執(zhí)行鏈路的自主 權(quán)，而不是每一步都等你拍板。

從聊天框到 Agent 的三步進(jìn)化

我把自己這段時(shí)間的進(jìn)化路徑總結(jié)成了三步。不是什么高深理論，就是實(shí)打?qū)嵉牟瓤咏?jīng)驗(yàn)。

第一步：學(xué)會(huì)給上下文，而不是給指令

聊天框模式最典型的特征就是一句一句下指令：「幫我改這個(gè)函數(shù)」「把這個(gè)變量名改一下」「加上錯(cuò)誤處理」。

Agent 工作流的第一步，是把上下文給足，讓 AI 自己判斷該做什么。

我在項(xiàng)目里標(biāo)配一個(gè) CLAUDE.md（或者 AGENTS.md），里面寫三樣?xùn)|西：

# 項(xiàng)目上下文

## 技術(shù)棧
- Runtime: Node.js 20 + TypeScript
- 框架: Fastify
- 數(shù)據(jù)庫(kù): PostgreSQL + Drizzle ORM
- 測(cè)試: vitest

## 目錄約定
- `src/modules/` 下按業(yè)務(wù)模塊分目錄
- 每個(gè)模塊必須有獨(dú)立的 router、service、repository
- 錯(cuò)誤處理統(tǒng)一走 `src/utils/errors.ts`

## 當(dāng)前優(yōu)先級(jí)
- 提高核心模塊測(cè)試覆蓋率到 80%
- 修復(fù)已知的 3 個(gè)內(nèi)存泄漏問(wèn)題

有了這個(gè)文件，我每次只需要說(shuō)「幫我把 users 模塊的測(cè)試補(bǔ)上」，它就知道該讀哪些文件、用什么框架、遵循什么規(guī)范。

這一步的價(jià)值在于：你從「每一步的指揮官」變成了「初始條件的設(shè)定者」。 AI 不再需要你手把手告訴它每一步怎么做，它自己能從上下文推斷出合理的工作路徑。

我們團(tuán)隊(duì)有一個(gè)后端同事，剛開(kāi)始用 Claude Code 的時(shí)候，每次對(duì)話都是從零開(kāi)始——新開(kāi)一個(gè)對(duì)話，重新描述一遍項(xiàng)目背景。后來(lái)我讓他寫了 CLAUDE.md，同樣的任務(wù)，對(duì)話輪次從平均 12 輪降到了 3 輪。對(duì)話輪次越少，說(shuō)明 AI 的自主性越高。

第二步：用 TodoWrite 規(guī)劃任務(wù)，而不是即興指揮

這個(gè)是我踩坑最深的一個(gè)點(diǎn)。

以前我讓 Claude Code 做一個(gè)復(fù)雜任務(wù)，比如「重構(gòu)認(rèn)證模塊」，它上來(lái)就開(kāi)始改代碼。改到一半發(fā)現(xiàn)不對(duì)，退回去重新來(lái)。改到后面發(fā)現(xiàn)前面改的有問(wèn)題，又退回去。這種來(lái)回折騰，本質(zhì)上是因?yàn)?strong>它沒(méi)有一個(gè)清晰的任務(wù)規(guī)劃。

后來(lái)我學(xué)了一招：先讓 Claude Code 制定計(jì)劃，再執(zhí)行。

# 在 Claude Code 中輸入
幫我重構(gòu)認(rèn)證模塊。先列出具體步驟讓我確認(rèn)，確認(rèn)后再逐步執(zhí)行。

它會(huì)給你一個(gè)類似這樣的計(jì)劃：

1. 分析現(xiàn)有認(rèn)證相關(guān)文件，列出所有涉及的模塊
2. 設(shè)計(jì)新的認(rèn)證中間件接口
3. 創(chuàng)建新文件 src/modules/auth/middleware.ts
4. 遷移現(xiàn)有路由中的認(rèn)證邏輯到中間件
5. 更新測(cè)試
6. 運(yùn)行全量測(cè)試確認(rèn)無(wú)回歸

你確認(rèn)了計(jì)劃，它就按步驟執(zhí)行。執(zhí)行過(guò)程中它會(huì)自己標(biāo)記完成狀態(tài)，遇到問(wèn)題也會(huì)按計(jì)劃的邏輯去處理，而不是隨機(jī)應(yīng)變。

這一步的價(jià)值在于：把 AI 從「即興發(fā)揮」變成了「按計(jì)劃執(zhí)行」。 你不需要在每一步都做決策，只需要在計(jì)劃階段做一次審核。

我們生產(chǎn)環(huán)境有一次重構(gòu)支付模塊，用的就是這個(gè)方式。Claude Code 列了 8 個(gè)步驟，我審了一遍發(fā)現(xiàn)第 3 步和第 5 步有依賴關(guān)系沖突，調(diào)整后讓它執(zhí)行。最終整個(gè)重構(gòu)用了 25 分鐘，零回歸。如果用聊天框模式一步步來(lái)，保守估計(jì)得兩個(gè)小時(shí)。

第三步：讓 AI 自己閉環(huán)，而不是等你驗(yàn)收

聊天框模式的最后一個(gè)習(xí)慣是：AI 做完了你來(lái)看，你看了發(fā)現(xiàn)問(wèn)題再讓它改。這個(gè)過(guò)程本質(zhì)上還是人在做驗(yàn)收，效率瓶頸在你。

Agent 工作流的終極形態(tài)是：AI 自己寫、自己測(cè)、自己修，直到通過(guò)為止。

具體操作很簡(jiǎn)單：

# 關(guān)鍵是加上測(cè)試閉環(huán)的指令
幫我修復(fù) src/modules/orders/ 里的 3 個(gè)已知 bug。
修完后跑測(cè)試，如果有失敗就自己修復(fù)，全部通過(guò)后再通知我。

這時(shí)候 Claude Code 的工作模式就變成了：

1. 讀代碼，定位 bug
2. 寫修復(fù)
3. 跑測(cè)試
4. 測(cè)試失??？分析原因，改代碼
5. 再跑測(cè)試
6. 全部通過(guò) → 輸出結(jié)果摘要給你

你從「每一步的審核員」變成了「最終結(jié)果的查看者」。

這一步有一個(gè)關(guān)鍵前提：你的項(xiàng)目得有完善的測(cè)試。如果沒(méi)有測(cè)試，AI 寫完代碼你根本不知道對(duì)不對(duì)，最后還是得自己驗(yàn)收。所以我一直跟團(tuán)隊(duì)說(shuō)，測(cè)試覆蓋率是 Agent 工作流的地基。 沒(méi)有測(cè)試，Agent 就是一輛沒(méi)有剎車的車。

我們團(tuán)隊(duì)實(shí)際跑通的 Agent 工作流

說(shuō)了這么多，放一個(gè)我們團(tuán)隊(duì)實(shí)際在用的工作流。

場(chǎng)景是每周的需求迭代——產(chǎn)品經(jīng)理提需求，我們用 Claude Code 來(lái)實(shí)現(xiàn)核心代碼。

# 1. 需求轉(zhuǎn)技術(shù)方案（人審核）
"根據(jù)下面的需求描述，生成技術(shù)方案。關(guān)注：涉及哪些文件要改、新增哪些接口、數(shù)據(jù)模型是否需要變更。
需求：xxx
參考 CLAUDE.md 中的項(xiàng)目規(guī)范。"

# 2. 技術(shù)方案確認(rèn)后，進(jìn)入執(zhí)行
"按上面的技術(shù)方案執(zhí)行，每完成一個(gè)步驟標(biāo)記 [done]。
完成后運(yùn)行全量測(cè)試，修復(fù)所有失敗用例。
最后輸出變更文件清單和測(cè)試結(jié)果。"

# 3. 結(jié)果審查
Claude Code 輸出后，我花 5 分鐘看變更文件清單和測(cè)試結(jié)果。
如果有問(wèn)題，針對(duì)性地指出讓它修。
如果沒(méi)問(wèn)題，直接 git commit。

平均下來(lái)，一個(gè)中等復(fù)雜度的需求（涉及 5-8 個(gè)文件），從方案到代碼完成大約 20-30 分鐘。 同樣的工作，純手寫大概 2-3 小時(shí)，聊天框模式大概 1-1.5 小時(shí)。

這不是什么魔法，就是把 AI 當(dāng) Agent 用，而不是當(dāng)聊天機(jī)器人用。

一個(gè)容易踩的坑：不要過(guò)度信任 Agent

講到這里必須潑一盆冷水。

Agent 工作流不是萬(wàn)能的，我在生產(chǎn)環(huán)境里踩過(guò)一個(gè)大坑。

有一次讓 Claude Code 自己閉環(huán)修復(fù)一批 lint 報(bào)錯(cuò)。它確實(shí)把所有報(bào)錯(cuò)都修了，但其中有幾個(gè)地方它的修法是加了 // eslint-disable 注釋。技術(shù)上報(bào)錯(cuò)消失了，但實(shí)際上問(wèn)題被掩蓋了。

從那以后我加了一條規(guī)矩：Agent 可以自己閉環(huán)執(zhí)行，但最終的 diff 必須人工 review。

# 我現(xiàn)在的標(biāo)準(zhǔn)流程
Agent 執(zhí)行 → 輸出 diff → 人工 review → 確認(rèn)后 commit

Agent 的價(jià)值不是替代你的判斷力，而是替代你的重復(fù)勞動(dòng)。 你不需要自己一行行寫代碼，但你需要判斷代碼寫得對(duì)不對(duì)。這個(gè)定位很重要，搞錯(cuò)了就會(huì)出事。

我們生產(chǎn)環(huán)境還遇到過(guò) Agent 把測(cè)試用例改得更容易通過(guò)的情況——不是修 bug，而是降低了測(cè)試標(biāo)準(zhǔn)。這在沒(méi)有人工 review 的情況下很容易漏過(guò)去。

Claude Code 日裝 2900 萬(wàn)，但深度使用率可能不到 10%

Claude Code 日安裝量 2900 萬(wàn)這個(gè)數(shù)字很嚇人，但你仔細(xì)想想——這 2900 萬(wàn)里有多少人是裝完之后用了兩天就回到手動(dòng)寫代碼的？

我身邊至少有五六個(gè)同事，裝了 Claude Code，試了幾次，覺(jué)得「也就那樣」，然后棄了。問(wèn)他們?cè)趺从玫模径际橇奶炜蚰Ｊ剑簡(jiǎn)栆痪?，答一句，覺(jué)得答得不好就不問(wèn)了。

這不是工具的問(wèn)題，是用法的問(wèn)題。

5G運(yùn)營(yíng)助手那篇文章對(duì)比了 Claude Code 和 Codex 的 8 種實(shí)戰(zhàn)模式，其中終端 Agent 模式和編輯器補(bǔ)全模式的核心差異就在于：一個(gè)是「你告訴它做什么」，另一個(gè)是「你看著它做」。

從聊天框模式到 Agent 工作流，不是一個(gè)功能開(kāi)關(guān)的切換，而是一個(gè)思維模式的轉(zhuǎn)變。 你需要從「我是操作者」轉(zhuǎn)變?yōu)椤肝沂且?guī)劃者」，從「我寫代碼，AI 輔助」轉(zhuǎn)變?yōu)椤窤I 寫代碼，我審核」。

這個(gè)轉(zhuǎn)變不難，但需要刻意練習(xí)。就像從 SVN 切到 Git 一樣，剛開(kāi)始你總覺(jué)得不放心，總想手動(dòng)管理每一個(gè)文件。但一旦你適應(yīng)了分支工作流，你就再也回不去了。

常見(jiàn)問(wèn)題解答

Q1：Agent 工作流對(duì)項(xiàng)目有什么硬性要求？

最核心的要求是測(cè)試覆蓋率。沒(méi)有測(cè)試的項(xiàng)目，AI 改完代碼你無(wú)法自動(dòng)驗(yàn)證對(duì)不對(duì)，Agent 自閉環(huán)就跑不起來(lái)。建議先把核心業(yè)務(wù)邏輯的測(cè)試覆蓋率提到 60% 以上，再開(kāi)始用 Agent 工作流。其次是一個(gè)清晰的 CLAUDE.md 項(xiàng)目說(shuō)明文件，這相當(dāng)于給 AI 的入職手冊(cè)。

Q2：聊天框模式是不是完全沒(méi)用？

不是。對(duì)于一次性的小任務(wù)——比如寫一個(gè)正則、解釋一段代碼、生成一個(gè) shell 腳本——聊天框模式完全夠用，甚至更高效。Agent 工作流的優(yōu)勢(shì)在復(fù)雜、多文件、需要上下文關(guān)聯(lián)的任務(wù)上。分清楚任務(wù)復(fù)雜度，選擇合適的模式，才是真正的高手。

Q3：CLAUDE.md 要寫多詳細(xì)？

不需要寫成文檔。我的經(jīng)驗(yàn)是控制在 50 行以內(nèi)，寫三樣?xùn)|西就夠了：技術(shù)棧和框架版本、目錄結(jié)構(gòu)約定、當(dāng)前階段的優(yōu)先級(jí)任務(wù)。太詳細(xì)反而會(huì)讓 AI 抓不住重點(diǎn)。可以參考 OpenAI 的 Codex 和 Claude Code 官方文檔里的 AGENTS.md 模板。

Q4：用 Agent 工作流會(huì)不會(huì)寫出很多意料之外的代碼？

會(huì)的。所以前面強(qiáng)調(diào)了 diff review 這個(gè)環(huán)節(jié)。我現(xiàn)在的習(xí)慣是讓 Agent 執(zhí)行完之后，跑 git diff --stat 先看變更文件清單，確認(rèn)都是預(yù)期要改的文件，再看具體 diff。如果 Agent 改了你不期望的文件，說(shuō)明任務(wù)描述不夠精確，下次拆分得更細(xì)就行。

Q5：團(tuán)隊(duì)里其他人還在用聊天框模式，怎么推動(dòng)轉(zhuǎn)變？

最有效的方式是做一次對(duì)比演示。拿同一個(gè)需求，A 同事用聊天框模式做，B 同事用 Agent 工作流做，計(jì)時(shí)對(duì)比。我們團(tuán)隊(duì)試過(guò)一次，同一個(gè)中等需求，A 用了一小時(shí)四十分鐘，B 用了二十二分鐘。結(jié)果一出來(lái)，不用你推，大家自己就切換了。

工具就擺在那里，2900 萬(wàn)人已經(jīng)裝了。但安裝不等于會(huì)用，會(huì)用不等于用好。從聊天框到 Agent 工作流，差的不是技術(shù)門檻，是思維模式。你愿意多花十分鐘寫一個(gè) CLAUDE.md，后面每次開(kāi)發(fā)能省一個(gè)小時(shí)。這筆賬，算得過(guò)來(lái)。

以上就是從聊天框到Agent分享Claude Code真正的提效方式的詳細(xì)內(nèi)容，更多關(guān)于Claude Code提效方式的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論