Claude Code之父揭秘：如何把Claude變成你的「虛擬開發小隊」？

null

原文：Boris Cherny，Claude Code開發者

編譯&整理：小互AI

你可能聽過 Claude Code，甚至用過它來寫點代碼、改點文檔。 但你有沒有想過：如果 AI 不是「臨時用一下的工具」，而是你開發流程中的正式成員，甚至是一個自動化協作系統——它會怎樣改變你的工作方式？

Boris Cherny 作為 Claude Code 之父，他寫了一篇非常詳細的推文，分享了自己如何高效使用這款工具，以及他和團隊在實際工作中如何將 Claude 深度集成進整個工程流程。

這篇文章將對他的經驗做一次系統的整理和通俗的解讀。

Boris 是怎麼讓 AI 成為他工作流中的自動化夥伴的？

核心要點：

他介紹了自己的工作流程，包括：

怎麼用 Claude：

開很多個 Claude 一起跑：在終端和網頁上開 5~10 個會話並行處理任務，還用手機 Claude。

不瞎改預設設置：Claude 開箱即用，沒必要複雜配置。

用最強的模型（Opus 4.5）：雖然慢一點，但更聰明，用起來更省事。

寫代碼前先規劃（Plan 模式）：讓 Claude 幫你想清楚再寫，成功率高。

生成代碼後用工具檢查格式，避免出錯。

怎麼讓 Claude 越用越聰明：

團隊維護一個「知識庫」：每當 Claude 寫錯東西，就把經驗加進去，下次就不會再犯。

寫 PR 時自動訓練 Claude：讓 Claude 看 PR，學會新的用法或規範。

自己常用的命令變成 slash 命令，Claude 可以自動調用，節省重複勞動。

用「子代理」處理一些固定任務，比如代碼簡化、功能驗證等。

權限怎麼管：

不隨便跳過許可權，而是設置安全的指令自動通過。

多設備（網頁、終端、手機）同步 Claude 工作流程。

最重要的一點：

一定要給 Claude 提供“驗證機制”，讓它可以確認自己寫的東西是不是對的。

比如 Claude 自動跑測試、打開瀏覽器測試網頁、檢查功能是否生效。

Claude Code 是“搭子”，不是“工具”

Boris 首先傳達了一個核心理念：Claude Code 不是一個靜態工具，而是一個可以與你配合、不斷學習、共同成長的智能搭檔。

它不需要太多複雜配置，開箱即用就很強。 但如果你願意投入時間去構建更好的使用方式，它能帶來的效率提升是成倍的。

模型選擇：選最聰明的，不選最快的

Boris 使用 Claude 的旗艦模型 Opus 4.5 + 思維模式（“with thinking”）進行所有開發任務。

雖然這個模型比 Sonnet 更大更慢，但：

它理解能力更強

用工具能力更好

不需要反覆引導，少來回交流

總體上比用快模型還更節省時間

啟示：真正的生產效率，不在於執行速度，而在於“少出錯、少返工、少重複解釋”。

1.Plan 模式：用 AI 寫代碼，先別急著讓它“寫”

當我們打開 Claude，很多人會直覺地輸入「幫我寫個介面」、「重構下這段代碼」… Claude 通常也會“寫一些”，但往往偏了方向、遺漏邏輯，甚至理解錯了需求。

而 Boris 的第一步從不讓 Claude 寫代碼。 他用的是Plan 模式—— 先和 Claude 一起制定實現思路，再進入執行階段。

他是怎麼做的？

在開啟一個 PR 時，Boris 先不讓 Claude 直接寫代碼，而是使用 Plan 模式：

1.描述目標

2.和 Claude 一起制定計劃

3.確認每個步驟

4.才讓 Claude 動手寫

每當需要實現一個新功能，比如「為某個 API 添加限流」，他會和 Claude 一步步確認：

是用中間件實現，還是邏輯內嵌？

限流配置是否需要支持動態修改？

是否需要日誌？ 失敗時返回什麼？

這個“計劃協商”過程，類似兩個人一起畫出“施工圖紙”。

一旦 Claude 理解清楚目標，Boris 就會打開“自動接受編輯”模式，Claude 可以直接修改代碼、提交 PR，有時甚至不再需要人工確認。

“Claude 的代碼品質，取決於你們是否在寫代碼前就達成一致。” —— Boris

啟示：與其反覆修補 Claude 的錯誤，不如一開始就一起把路線圖畫清楚。

小結

Plan 模式不是浪費時間，而是用前置協商換穩定執行。 AI 再強，也需要“你說清楚”。

2. 多 Claude 並行：不是一個 AI，而是一支虛擬開發小隊

Boris 並不只用一個 Claude。 他的日常是這樣的：

終端里開 5 個本地 Claude，工作階段分配給不同任務（比如重構、寫測試、調 bug）

瀏覽器中再開 5–10 個 Claude，與本地並行

手機上用 Claude iOS app，隨時發起任務

每個 Claude 實例，就像是一個「專屬助手」：有的負責寫代碼，有的負責文檔補全，有的長期掛後台執行測試任務。

他甚至設置了系統通知，當 Claude 等待輸入時，他能第一時間被提醒。

為什麼這麼做？

Claude 的上下文是局部的，不適合“一個視窗做所有事”。 Boris 把 Claude 拆分為多個角色並行處理，一方面減少等待時間，一方面減少“干擾記憶”。

他還通過系統通知提醒自己：「Claude 4 在等你回復」、「Claude 1 完成測試了」，像管理一個多線程系統一樣管理這些 AI。

類比理解

你可以想像自己身邊坐著五個聰明實習生，每人負責一個任務。 你不用每件事做到底，只要在關鍵時刻“切一下人”，保持任務流暢推進。

啟示：將 Claude 當作多個“虛擬助手”，分別承擔不同任務，可以顯著減少等待時間和上下文切換成本。

3. Slash 命令：把你每天做的事變成 Claude 的快捷指令

有些工作流，我們每天會做幾十次：

修改代碼 → commit → push → 建立 PR

檢查構建狀態 → 通知團隊 → 更新 issue

把改動同步到 Web 和本地多個工作階段

Boris不希望每次都提示 Claude：“請你先 commit，再 push，然後再建 PR…”

他把這些操作封裝成 Slash 命令，比如：

/commit-push-pr

這些命令背後是Bash腳本邏輯，存放在 .claude/commands/ 資料夾，加入 Git 管理，團隊成員都可以使用。

Claude 怎麼用這些命令？

當 Claude 遇到這個命令，它不只是“執行指令”，而是知道這個命令代表的工作流，並能自動執行中間步驟、預填參數、避免反復溝通。

理解重點

Slash 命令就像你給 Claude 安裝的「自動按鈕」。 你訓練它理解一個任務流程，之後它就能一鍵執行。

“不只是我能用命令節省時間，Claude 也能。” —— Boris

啟示：不要每次都重複輸入提示，將高頻任務抽象成命令，你和 Claude 的配合才能“自動化”。

4. 團隊知識庫：Claude 不靠 Prompt 學習，而靠團隊維護的知識基因

Boris 的團隊維護了一個 .claude 知識庫，並加入 Git 管理。

它就像是給 Claude 用的「內部維琪百科」，記錄了：

什麼寫法是對的

什麼是團隊約定的最佳實踐

遇到哪些問題時，該怎麼修正

Claude 會自動參考這個知識庫來理解上下文、判斷代碼風格。

當 Claude 做錯事時怎麼辦？

每當 Claude 出現誤解或寫錯邏輯，就將教訓添加進去。

每個團隊維護自己的版本。

所有人協同編輯，Claude 會實時參考這份知識庫做判斷。

舉個例子：

如果 Claude 老是把分頁邏輯寫錯，只需要團隊將正確的分頁標準寫進知識庫，後續每個消費者都能自動受益。

Boris 的做法：不罵它、不關掉，而是「訓練一次」：

這段代碼我們不這樣寫，加進知識庫

下次 Claude 就不會再犯這個錯誤。

更重要的是，這套機制不是 Boris 一人維護，而是整個團隊每周都貢獻、修改。

啟示：用 AI，不是每個人單打獨鬥，而是構建一支「集體記憶」的系統。

5. 自動學習機制：PR 本身就是 Claude 的“訓練數據”

Boris 在做代碼審查時，常常在 PR 上 @Claude，比如：

@.claude 將這個函數寫法加進知識庫

配合 GitHub Action，Claude 會自動學習這段改動背後的意圖，並更新內部知識。

這類似於「持續訓練 Claude」，每次評審不僅合代碼，也提升了 AI 能力。

這不再是“後期維護”，而是將 AI 的學習機制融合進日常協作中。

團隊用 PR 提升代碼品質，Claude 同步提升知識水準。

啟示：PR 不只是代碼審查流程，也是 AI 工具自我進化的機會。

6. 子代理（Subagents）：讓 Claude 模組化執行複雜任務

除了主任務流程，Boris 還定義了一些子代理（Subagents）處理常見輔助任務。

Subagents 是一些自動運行的模組，比如：

code-simplifier：在 Claude 寫完代碼後自動精簡結構

verify-app：跑完整測試，驗證新代碼是否可用

log-analyzer：分析錯誤日誌，快速定位問題

這些子代理像外掛程式一樣，自動接入 Claude 的工作流，自動協作運行，不需要重複提示。

啟示：子代理就是 Claude 的“團隊成員”，把 Claude 從一個助手升級為“項目指揮官”。

Claude 不只是一個人，而是你可以帶團隊的小總管。

7. 補充段落一：PostToolUse Hook —— 代碼格式的最後守門員

在一個團隊里，讓每個人寫出統一風格的代碼並不容易。 Claude 雖然生成能力強，但難免會有縮進差一點、空行多一點這類細節瑕疵。

Boris 的做法是設置一個PostToolUse Hook——

簡單理解，這就是 Claude 在“完成任務”之後自動調用的“後處理鉤子”。

它的作用包括：

自動修復代碼格式

補充遺漏註釋

處理lint錯誤，避免 CI 掛掉

這一步通常不複雜，但很關鍵。 就像文章寫完后再跑一遍 Grammarly，這樣交出去的作品才穩定、整潔。

對 AI 工具來說，好用的關鍵往往不在生成力，而在收尾能力。

8. 許可權管理：預授權而非跳過

Boris 明確表示他不使用 --dangerously-skip-permissions —— 這是 Claude Code 的一個參數，可以跳過所有執行命令時的許可權提示。

聽起來方便，但也可能危險，比如誤刪檔、跑錯腳本等。

他的替代方案是：

1.使用 /permissions 命令來顯式聲明哪些命令是可信的

2.將這些許可權配置寫入 .claude/settings.json

3.讓整個團隊共用這些安全設定

這就像是為 Claude 預先開了一批「白名單」操作，比如：

“preApprovedCommands”: [

“git commit”,

“npm run build”,

“pytest”

]

Claude 遇到這些操作就直接執行，無需每次打斷。

這套許可權機制設計得更像一個團隊操作系統，而不是單機工具。 他用 /permissions 命令將常用、安全的bash命令預先授權，這些配置保存在 .claude/settings.json 中，團隊共用。

啟示：AI 自動化並不意味著失控。 將安全策略納入自動化流程本身，才是真正的工程化。

9. 多工具聯動：Claude = 多能機器人

Boris 不是只讓 Claude 在本地寫代碼。 他配置了 Claude 能通過 MCP（一個中控服務模組）訪問多個核心平臺：

自動發 Slack 通知（比如建譯結果 ）

查詢 BigQuery 數據（比如使用者行為指標）

抓取 Sentry 紀錄（比如線上異常追蹤）

如何實現？

MCP 的配置保存在 .mcp.json

Claude 在運行時會讀取配置，自主執行跨平台任務

整個團隊共用一套配置

所有這些都是通過 MCP（Claude 的中控系統）與 Claude 集成完成的，配置保存在 .mcp.json 中。

Claude 就像一個機器人助手，能幫你：

“寫完代碼 → 提交 PR → 查看效果 → 通知 QA → 報告日誌”。

這已經不是傳統意義上的 AI 工具，而是工程系統的神經中樞。

啟示：不要讓 AI 只在「編輯器里」工作，

它可以成為你整個系統生態中的調度者。

10. 長任務異步處理：後台 agent + 外掛程式 + hook

在真實專案中，Claude 有時要處理長任務，比如：

構建 + 測試 + 部署

生成報告 + 發郵件

數據遷移腳本運行中

Boris 的處理方式非常工程化：

三種方式處理長任務：

1.Claude 在完成後，用後台 Agent 驗證結果

2.使用 Stop Hook，任務結束時自動觸發後續動作

3.使用 ralph-wiggum 外掛程式（由 @GeoffreyHuntley 提出）來管理長流程狀態

在這些場景中，Boris 會使用：

–permission-mode=dontAsk

或者將任務放入沙箱中運行，避免因為許可權提示而打斷整個流程。

Claude 不是“時時盯著”，而是你可以放心託管的協作者。

啟示：AI 工具不僅適合短平快的操作，也適合長週期、複雜流程 —— 前提是你要為它構建好“託管機制”。

11. 自動驗證機制：Claude 的輸出值不值錢，關鍵看它能不能驗證自己

Boris 的經驗中最重要的一條是：

Claude 輸出的任何結果，必須有“驗證機制”來檢查其正確性。

他會給 Claude 加一個驗證腳本或 hook：

寫完代碼后，Claude 自動運行測試用例驗證代碼是否正確

在瀏覽器中模擬使用者交互，驗證前端體驗

自動比較運行前後的日誌、指標

如果沒有通過，Claude 會自動修改、重新執行。 直到通過為止。

這就像 Claude 自己帶了一個「閉環反饋系統」。

這不僅提升品質，更減輕了人的認知負擔。

啟示：真正決定 AI 成果品質的，不是模型的參數量，而是你有沒有為它設計好“結果檢查機制”。

總結：不是讓 AI 替代人，而是讓 AI 像人一樣合作

Boris 的方法並沒有依賴什麼「隱藏功能」或黑科技，而是工程化地使用 Claude，把它從「聊天工具」升級為一個高效的工作系統組成部分。

他的 Claude 使用法有幾個核心特點：

多會話並行：任務分工更清晰，效率更高

規劃優先：Plan 模式提升 Claude 的目標對齊度

知識系統支撐：團隊共同維護 AI 的知識庫，持續反覆運算

任務自動化：Slash 命令 + 子代理，讓 Claude 像流程引擎一樣工作

閉環反饋機制：Claude 的每個輸出都有驗證邏輯，確保產出穩定可靠

其實Boris 的方法展示了一種新的使用 AI 的方式：

將 Claude 從“對話助手”升級為“自動化程式設計系統”

將知識積累從人腦變成 AI 的知識庫

將流程從重複手動操作轉化為腳本化、模組化、協同化的自動工作流

這套做法不依賴黑魔法，而是工程化能力的體現。 你也可以從中借鑒思路，把 Claude 或其他 AI 工具用得更高效、更智慧。

如果你在使用 Claude 時常常覺得“它懂一點，但不靠譜”、“寫的代碼總要我修”，也許問題不在 Claude，而在你還沒給它一個成熟的協作機制。

Claude 可以是一個合格的實習生，也可以是一個穩定可靠的工程搭檔，取決於你怎麼用它。