委派而非配對（Delegation, not Pair Programming）
Boris Cherny：用 Claude Code 的正確心態不是當 pair programmer 一起寫，而是當成你委派任務的工程師——一次把完整 context 給足，然後退後一步讓它自己做。
Pair Programming vs 委派 — 思維對照
| 維度 | Pair Programming（錯） | 委派（對） |
|---|---|---|
| 節奏 | 來回對話、邊想邊寫 | 一次給足、放手讓它做 |
| Context | 邊做邊補 | 開工前一次寫清 |
| 介入頻率 | 每幾分鐘確認一次 | 等 Claude 完成才看 |
| 權限模式 | Ask-everything | /permissions 預先白名單 |
| 產出形態 | 一段一段 | 整個 PR 一次到位 |
| 適用模型 | 快速回饋的人類關係 | 委派任務給有能力的初級工程師 |
→ 把 Claude 當 pair programmer 就白白浪費了它的並行能力與長上下文。委派模式才能跑出 並行 Claude 實例 5+5+phone = 10–15 個 session 的工作量。
一次給足 Context — 四要素
每次委派時提供：
1. 目標（用白話講成功長什麼樣）
❌ 「修一下 auth 那個 bug」
✅ 「修 auth bug——重現步驟：登入 → 等 60 秒 → 任何操作都跳回登入頁。期望：60 秒內無操作不該登出，60 秒以上才該。」
2. 限制（不要動什麼、效能要求、API 合約）
❌ 不寫
✅ 「不要動 RefreshTokenService，公司已凍結。延遲不能超過 200ms。回應 schema 跟現有 /api/auth/me 一致。」
3. 驗收標準（怎麼知道做完了）
❌ 「跑得起來就好」
✅ 「tests/auth.test.ts 全綠 + 手動測 5 個場景：登入後 30 秒、60 秒、90 秒、5 分鐘、24 小時。每個場景都要符合預期。」
4. 背景知識（相關 code path 或設計決策）
❌ 不附路徑、靠 Claude 摸索
✅ 「src/auth/middleware.ts 是入口、src/auth/storage.ts 是 token 存取、相關設計決策在 docs/auth-design.md。歷史上踩過：CLAUDE.md（專案手冊） 第 X 條提的 tokenExpiry 跟實際不一致。」
→ 一次講清，減少來回修正次數。
三個壓榨更好結果的 Prompt 技巧
Boris Cherny 在 X 上分享：
技巧 1：「Grill me」(逆向審查)
“Grill me on these changes and don’t make a PR until I pass your test.”
繁中：「對我這些修改提出嚴格質詢，在我通過你的測試之前，不要提交 PR。」
讓 Claude 反過來考你，確認你真的理解了改動內容。常常會 expose 你以為理解但其實不理解的部分。
技巧 2：「Prove to me this works」(自我證明)
“Prove to me this works.”
繁中：「向我證明這真的能動。」
讓 Claude 自己跑測試、產出 diff、比對 main vs feature branch 的行為差異——不靠你的肉眼判斷。
技巧 3：「Scrap this, do it elegantly」(重做請求)
“Knowing everything you know now, scrap this and implement the elegant solution.”
繁中：「以你現在所知的一切來看，把這個方案擱置，改採優雅的解決方案。」
Claude 第一個方案常常是「能動就好」的版本。這句話強迫它用累積的 context 重做——通常會出現結構更乾淨的版本。
Boris 的關鍵洞見：
“Don’t accept the first solution. Push Claude to do better — it usually can.”
繁中：「不要接受第一個方案。逼 Claude 做得更好——通常它做得到。」
不適用的場景
委派模式不是萬能。不要用在：
- 純對話 / 問答 / 諮詢（沒「任務」可委派）
- 你自己也不知道想要什麼的探索階段（先用 Plan 模式 釐清）
- 高度需要創意 brainstorm 的設計階段（pair 反而比委派好）
- 一行指令的明確小任務（直接執行就好，委派儀式反而冗餘）
跟 Plan 模式 的關係
不確定 → Plan 模式釐清 → 鎖定計畫 → 切到委派模式（Auto-accept） → Claude 1-shots it
↓
不滿意？「Scrap this」重做
想驗證？「Prove to me」
Plan 模式 + 委派模式是配套——前者把模糊變具體，後者把具體變產出。
對 PAM 的應用
範例 1：委派處理一個 bug 票
@claude
目標：修「主管離職時 ReviewerAccountService 沒清空被代理人」的 bug
限制：
- 不動 GradingService
- 等第計算依賴鏈不能中斷
驗收：
- 寫 3 個 xUnit 測試覆蓋三種離職情境
- 跑 `dotnet test` 全綠
- 手動跑一次 ReviewerTransferService 流程確認
背景：
- 主檔：src/Services/ReviewerAccountService.cs
- 相關設計：[[ReviewerTransferService]]
- 歷史踩過：CLAUDE.md L2 第 8 條「主管異動必同步 Approver flag」
範例 2：壓榨更好的 SQL
[Claude 給了個普通版的查詢]
> Prove to me this works on 50 萬筆資料。跑 EXPLAIN 給我看。
[Claude 跑完 → query plan 顯示 full scan]
> Knowing everything you know now, scrap this and implement
> the elegant solution. 用索引 + CTE 重寫。
[Claude 重做 → 從 8 秒降到 200ms]
反模式
- ❌ 每改一行就確認 → 退回 pair programming，浪費並行能力
- ❌ 不寫驗收標準 → Claude 自己界定「做完」 = 你會收到不符合預期的產出
- ❌ 第一個方案就接受 → 跳過 Boris 的「Scrap this」技巧 = 收到平庸 code
- ❌ 委派完就走人 → 沒 反饋循環，Claude 只能寫完就交差
相關概念
強連結（原文明確提及）
- Boris Cherny — 概念推廣者
- Boris Cherny 13 條心法 — 跨多條心法的底層哲學
- Plan 模式 — 模糊→具體的前置步驟
- 反饋循環 — 「Prove to me this works」的具體機制
- 並行 Claude 實例 — 委派模式才能撐起的並行能力
- Slash Commands —
/permissions是委派的權限基礎
推斷連結（LLM 認為相關，待確認）
- CLAUDE.md（專案手冊） ?? — 「背景知識」的儲存層
- Sub-agent ?? — 委派的疊乘版（你委派 Claude，Claude 委派 sub-agent）
- AskUserQuestion 工作流 ?? — Plan 階段釐清需求的工具
深入閱讀
- 原文：Claude Code 之父怎麼用？Boris Cherny 的 10 個進階技巧
- howborisusesclaudecode.com Part 2 Tab 6（Boris 的 prompting tips）
← 回到 wiki