Claude Code 高效工作流實戰：Claude Code 的創建者Boris Cherny 的 12 個開發技巧

2026 年新年第三天，Claude Code 的創建者與負責人 Boris Cherny 進行了一場「線上示範教學」，公開他自己日常使用 Claude Code 的實戰工作流。最讓人意外的是：他的設定其實非常「素」——因為 Claude Code 開箱即用就已經很強，他更在意的是把工作流流程化、把回饋閉環做扎實，而不是花大量時間做酷炫客製化。

以下整理成一篇面向專業開發者／工程主管／技術 PM 的實務筆記：你可以把它當成一套可直接套用的「AI 程式開發作業系統」。

1) 五線並行：同時跑 5 個 Claude 視窗，提升吞吐量

Boris 會在終端機同時開 5 個 Claude 視窗（分頁標上 1～5），並開啟系統通知。當某個任務需要他補充指令或做決策時，他能立刻被提醒，不會讓工作流卡住。

為什麼這招有效（給專業人士的觀點）

• AI 寫碼常見瓶頸不是「產出速度」，而是「等待你回覆」或「等待驗證結果」。多視窗等於把等待時間攤平，提升整體 throughput。
• 特別適合：多個 feature/bug 同時推進、同時跑測試或查資料的情境。

---

2) 多端無縫衔接：終端 + 網頁 + 手機，讓任務隨時續跑

除了本地終端，他也會在網頁端同時跑 5～10 個任務，並在不同端之間切換：

• 在終端寫碼時，會用 & 把會話丟到背景跑
• 或直接在 Chrome 開新會話
• 有時用 --teleport 在終端與網頁端之間「傳送」進度
• 甚至每天早上用手機（iOS Claude App）先開幾個會話，回到電腦再看成果

實務建議

• 把「需要長時間生成 / 搜集資訊 / 進行多步推理」的任務，放到你不在電腦前也能跑的地方。
• 把「需要你頻繁介入」的任務留在終端主工作區，降低切換成本。

---

3) 全力投入 Opus 4.5：寧可大一點，也要少引導、少返工

他會把所有任務都開 Opus 4.5（含 Thinking 模式），原因是：雖然它比 Sonnet 更大、更慢，但更聰明、更會用工具，不需要你費力「教它怎麼想」，最終反而更快完成任務（因為少走彎路、少重做）。

給技術管理者的判斷框架

• 如果你的工作型態是「需求模糊、整合多工具、需要端到端驗證」，大模型常常更划算。
• 如果是「明確需求、可拆很細、測試很完整」，小模型可能就足夠且更省成本。

---

4) 共享知識庫 CLAUDE.md：把錯誤變成規則，讓團隊越用越順

他們團隊共用一份 CLAUDE.md 放在 Git repo 裡，大家每週會更新多次。只要發現 Claude 哪裡做錯，就把規則寫進 CLAUDE.md，避免下次再犯。

這其實是把「個人提示技巧」升級為「團隊制度」

• 不靠每個人私藏 prompt，而是把最佳實務變成版本化文件
• 新人加入也能快速對齊風格、規範與踩雷點

---

5) 持續複利：Code Review 時把規範沉澱回 CLAUDE.md

在 PR code review 時，他會常用 @.claude 讓 Claude 把同事 PR 中出現的規範、慣例或踩雷點，整理沉澱回 CLAUDE.md。他們也透過 /install-github-action 裝了 Claude Code 的 GitHub Action——這就是他們版本的「複利工程（Compounding Engineering）」。

專業價值

• Code review 不只是「抓錯」，更是「更新組織記憶」
• 你每修一次，就等於把未來 N 次重複錯誤的成本砍掉

---

6) 先謀定而後動：Plan 模式把方案打磨到可一波完成

大多數任務都從 Plan 模式開始（連按兩次 Shift+Tab）。如果目標是做一個 PR，他會先在 Plan 模式跟 Claude 反覆確認方案，直到覺得可行、可落地，再切換到 auto-accept edits 讓 Claude 直接「一波帶走」。

重點：不是「讓 AI 寫碼」，而是「讓 AI 先設計好」

• 設計品質決定實作品質
• 方案越清晰，後面越少來回、越少不必要的 patch

---

7) 自製 Slash Commands：把高頻內環流程封裝成命令

他會把每天重複多次的「內環工作流」封裝成 slash commands，放在 .claude/commands/ 並提交到 Git。這能減少重複輸入 prompt，也讓 Claude 直接呼叫固定流程。

例如他們每天用數十次 /commit-push-pr：用內聯 Bash 預先計算 Git 狀態等資訊，跑得很快，避免反覆對話成本。

你可以立刻照做的方向

• 把「固定步驟」交給命令：建立分支、跑格式化、跑測試、寫 commit message、推 PR、生成 changelog
• 讓 prompt 變成「工具化」而不是「口語化」

---

8) 善用子智能體 Subagents：把常見流程模組化

他常用特定 subagents：

• code-simplifier：在完成後簡化程式碼
• verify-app：端到端測試

本質上就是把 PR 中最常見的流程模組化、自動化，避免每次從零描述。

專業觀點

• Subagent 是「角色 + 任務邊界」：讓 AI 知道自己要做的是簡化、驗證、重構或安全檢查，而不是「什麼都做一點」。
• 對團隊來說也更容易對齊：每個 subagent 就是一套可被 code review 的流程。

---

9) 自動程式碼美化：用 PostToolUse Hook 補最後 10%

他們用 PostToolUse hook 做格式化。即使 Claude 寫的程式碼格式已經不錯，hook 仍能補齊最後 10% 細節，降低 CI 因格式或 lint 失敗而紅燈的機率。

---

10) 權限管理：不跳過提示，而是預先授權安全指令

他不使用 --dangerously-skip-permissions（危險跳過權限提示）。相反會用 /permissions 先授權在當前環境下安全、常用的 Bash 指令，並把設定存進 .claude/settings.json 供團隊共享。

對企業/資安更友善的做法

• 把「可執行指令範圍」明確化、版本化
• 降低意外執行破壞性操作的風險，也更容易審計

---

11) 工具全家桶：讓 Claude 真的『在幫你做事』而不是只給建議

Claude Code 會幫他操作各種工具：透過 MCP 伺服器搜尋並發 Slack 訊息、跑 bq CLI 做 BigQuery 查詢、從 Sentry 抓錯誤日誌等。Slack 的 MCP 設定放在 .mcp.json，團隊共用。

專業重點

• 真正能提升生產力的不是「AI 會寫程式」，而是「AI 會把資訊與工具串起來，減少人肉搬運」。
• 這會直接影響 MTTR（平均修復時間）、交付速度、跨部門溝通成本。

---

12) 長時間任務：驗證智能體、Stop Hook、以及降低打斷的權限策略

對耗時任務，他會：

• 完成後啟動背景智能體做驗證
• 使用 Stop hook 做確定性檢查
• 使用 ralph-wiggum 插件
  並在需要長時間不中斷輸出時，視情況使用 --permission-mode=dontAsk，或在沙盒環境使用跳過權限模式，避免被權限彈窗卡住節奏。

---

最關鍵：建立回饋閉環，品質可提升 2～3 倍

Boris 強調：要拿到高品質結果，關鍵是讓 Claude 有辦法驗證自己的工作。一旦有回饋閉環，品質能提升 2～3 倍。

例如：Claude 更新網頁端程式碼時，會透過 Chrome 插件實測每次改動——自動開瀏覽器、測 UI、迭代直到跑通且互動順暢。

驗證方式因領域而異：

• 可能是跑 Bash 腳本
• 跑測試套件
• 在模擬器跑 App
  請務必把「驗證流程」打造得足夠堅固，因為這會直接決定你能不能放心把修改交給自動化。

---

未來趨勢／實務建議（給專業人士）

1. AI 工程會從「提示技巧」走向「可版本化的流程資產」
   像 CLAUDE.md、slash commands、subagents、hooks、permissions 白名單，這些會逐漸變成新一代工程團隊的「流程基礎建設」。建議你把它們當成 repo 的一級公民：可 review、可追溯、可迭代。
2. 驗證（Testing/Observation）會成為 AI 開發效率的第一優化點
   當 AI 參與程度越高，你越需要把測試、lint、E2E、可觀測性（Sentry/Logs/Tracing）串成一條穩定的回饋管線。想提升交付速度，不要只盯模型與 prompt，優先投資在「更快、更可靠的驗證」。

---

參考資料

• 建議參考：Anthropic 官方文件（Claude、Claude Code、MCP 相關）
• 建議參考：GitHub Actions 官方文件（CI/CD 與自動化工作流）
• 建議參考：Sentry 官方文件（錯誤追蹤與可觀測性）
• 建議參考：Google BigQuery CLI（bq）官方文件（資料查詢與指令操作）
• 建議參考：端到端測試框架官方文件（例如 Playwright / Cypress，用於建立 UI 驗證閉環）