Claude Code 創始人實際上是怎麼用 Claude Code 的

Claude Code 的創始人 Boris Cherny 公開分享了他的開發工作流 - 兩小時內就突破了 5,000 個讚。當打造工具的人親自揭露他實際怎麼使用這個工具時，大家自然會想看。

最讓我意外的是它的簡單。沒有花俏的客製化，沒有什麼秘密配置。他的做法核心就是把 Claude Code 的內建功能用有紀律、有意識的方式組合起來。

如果你讀過 Andrej Karpathy 最近分析的「開發者在 AI 程式代理中需要理解的抽象層」，Boris 的指南就是它的實戰配套篇。

並行處理 - 同時跑 15 個 Claude 工作階段

Boris 在終端機裡同時跑五個 Claude 實例，再透過瀏覽器在 claude.ai/code 上另外開五到十個。他甚至早上用手機啟動工作階段，之後再回來查看進度。

他的設定方式：

• 終端機分頁編號 1 到 5，靠系統通知來得知何時需要介入。
• 用 & 指令在本地和網頁工作階段之間切換。
• 用 --teleport 在不同工作階段之間跳轉。
• 每個終端機分頁都有獨立的 git checkout，所以每個工作階段都在獨立分支上執行獨立計畫。

這不是為了同時做很多事而做的多工。每個工作階段處理的是一個明確、範圍清楚的任務。並行之所以成立，靠的是清晰的計畫，而不是在任務間切來切去。

留言區裡有個值得注意的細節：Boris 用的是每個終端機分頁各一個 git checkout，而不是 git worktree。他覺得在同時操控多個工作階段時，這種比較單純的模型更容易掌握。

Opus 4.5 搭配思考模式 - 更大的模型反而更快

Boris 每個任務都用最大的模型。這聽起來有點反直覺 - Opus 每個 token 的速度更慢、成本更高。但他的理由很務實：更大的模型需要的修正更少，工具使用更精準，第一次就能產出更好的結果。

整體效果是，用 Opus 完成任務的總時間比用小模型更短，因為你花在修錯和重新提示上的時間少了。

• 他測試過的所有模型中，程式撰寫表現最佳。
• 執行過程中需要的人工介入更少。
• 雖然每個 token 的延遲較高，但實際掛鐘時間反而縮短。

CLAUDE.md - 團隊層級的上下文工程

整個團隊把一份 CLAUDE.md 檔案簽入 Git。每次 Claude 犯了一個錯誤，就有人在這份檔案裡加上一筆紀錄，確保同樣的錯不會再犯。

這是實踐中的複利工程：

• 多位團隊成員每週貢獻更新。
• 在程式碼審查中，團隊用 @.claude 標籤來要求新增 CLAUDE.md 條目。
• 每個團隊維護自己的 CLAUDE.md。
• 這份檔案逐漸成為一個不斷成長的機構知識庫，每個 Claude 工作階段都會繼承它。

概念本身很直白，但真正讓它發揮威力的是持續維護的紀律。

計畫模式 - 好的規劃就是九成的成功

Boris 大部分工作階段都從計畫模式開始（shift+tab 按兩次）。如果目標是發一個 pull request，他會跟 Claude 討論計畫直到滿意為止，然後切換到自動接受模式，讓 Claude 不中斷地執行整個計畫。

工作流程：

1. 前期在規劃階段充分投入時間。
2. 反覆疊代計畫，直到涵蓋邊界情境和潛在問題。
3. 計畫定案後，切換到自動化執行。
4. 在實作過程中盡量減少來回修正。

這個模式消除了最常見的失敗原因：還沒想清楚就開始寫程式。規劃的成本很低，返工的代價很高。

斜線指令與子代理 - 把重複性工作自動化

Boris 任何一天用超過幾次的工作流，都會變成一個斜線指令，存在 .claude/commands/ 裡。像 /commit-push-pr 這樣的指令不只是開發者能用，Claude 本身也能呼叫。

• 徹底消除重複性的提示操作。
• 用內嵌的 bash 預先計算上下文，讓指令跑得更快。
• code-simplifier 和 verify-app 等子代理處理常見的驗證工作流。
• PostToolUse hook 在每次編輯後自動格式化程式碼。

Boris 也把 Skills 理解為斜線指令的一種形式 - 可重複使用、可分享的工作流定義，用來標準化 Claude 處理特定任務的方式。

權限管理與工具整合

Boris 不用 --dangerously-skip-permissions，而是透過 /permissions 來預先核准安全的指令。團隊共享 MCP 伺服器配置，讓 Claude 能直接存取 Slack、BigQuery、Sentry 和其他工具。

• 透過 .claude/settings.json 共享權限設定。
• 透過 .mcp.json 共享工具整合。
• 在不犧牲安全性的前提下，把不必要的權限提示降到最低。

這是完全封鎖與無限制存取之間的務實中間路線。團隊先達成共識哪些操作是安全的，寫成規則，然後就不用再操心。

驗證迴圈 - 品質提升 2 到 3 倍的關鍵

Boris 工作流中最重要的一項做法：讓 Claude 有辦法自行驗證產出。

在 claude.ai/code 上，他讓 Claude 透過一個 Chrome 擴充套件對實際應用程式進行每次變更的測試。驗證迴圈包括：

• 完成工作後由背景代理進行檢查。
• Agent Stop hook 執行確定性驗證。
• ralph-wiggum 外掛提供額外的驗證。
• 沙箱環境搭配調整過的權限模式，避免被阻擋。
• 在瀏覽器和模擬器中進行真實的使用者體驗測試。

這不是可有可無的收尾工作。Boris 認為驗證迴圈就是產出品質在 1 倍和 2 到 3 倍之間的分水嶺。

這些做法背後的共通模式

拿掉具體的工具和配置，浮現出四個原則：

• 積極並行化。 同時跑多個工作階段，每個都有清楚的範圍和獨立的分支。
• 先規劃再動手。 計畫模式是 Claude Code 中槓桿效益最高的功能。
• 團隊共享上下文。 CLAUDE.md 把個人的經驗教訓轉化為集體知識。
• 閉合驗證迴圈。 在你審查之前，先讓 Claude 自己檢查產出。

Boris 的設定中最讓人印象深刻的，不是某個單一技巧 - 而是整套系統的零件之少。這個工具的創始人並不依賴什麼奇特的配置。他依賴的是基本功，持續且有紀律地執行。