--- schemaVersion: 1 slug: mp-305-20260604-trq212-claude-stay-in-loop ticketId: MP-305 lang: zh-tw title: Claude Code 真正的方向盤不是 prompt，是讓人聽得懂它剛剛幹了什麼 summary: Thariq 分享了一段 Anthropic 內部使用者蘇珊的 Claude prompt：不要只讓 agent 做完事，而是讓 agent 一步一步確認人真的理解問題、解法、邊界情境和影響。這不是教學癖，而是 agentic coding 時代的人類控制權問題。 originalDate: 2026-06-02 translatedDate: 2026-06-04 source: "@trq212 on X" sourceUrl: https://x.com/trq212/status/2061545633560010826 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-305-20260604-trq212-claude-stay-in-loop status: published replacementTicketId: null replacementUrl: null --- # Claude Code 真正的方向盤不是 prompt，是讓人聽得懂它剛剛幹了什麼 > **來源:** [@trq212 on X](https://x.com/trq212/status/2061545633560010826) [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 越能幹，開發者越容易失去一種很基本的東西：知道剛剛到底發生了什麼。 [Thariq](https://gu-log.vercel.app/glossary#thariq) 在 X 上分享了一段來自 Anthropic 內部使用者蘇珊的 prompt。表面上，它是在叫 Claude 當一個有效率的老師；實際上，它講的是 agentic coding 最容易被低估的控制問題：工作可以交給 agent，但理解不能一起外包。 這段 prompt 的核心不是「請解釋一下」。它要求 Claude 在工作階段中持續維護一份理解清單，逐步確認人已經掌握三件事：問題為什麼存在、解法為什麼這樣設計、這次改動會影響什麼。 > **Mogu 忍不住說：** > > 這個 prompt 有趣的地方不是文筆，而是姿勢。很多人用 AI agent 的方式像叫外送：「幫忙送到門口，謝謝。」蘇珊這段比較像請廚師邊煮邊講：這道菜為什麼這樣下鍋、火候錯會怎樣、下次換材料要注意什麼。前者會吃飽，後者才會變強。 (￣▽￣) --- ## 留在狀況裡，不是盯著紀錄看 很多人以為留在狀況裡就是盯著 Claude 的終端機輸出，看它改了哪些檔案、跑了哪些測試、產生哪些差異。這當然有用，但那只是最低階的同步。 真正的問題是：當 agent 跑了半小時、改了十幾個地方、修了三個中途冒出來的錯，開發者最後拿到的經常只是一句「done」。這句話很危險，因為它讓人以為事情結束了，其實理解才剛開始破洞。 蘇珊的 prompt 把同步目標從「知道 agent 做了什麼」提高到「能重建 agent 為什麼這樣做」。這兩件事差很多。 知道做了什麼，是 commit log。知道為什麼這樣做，才是控制權。 --- ## 這段 prompt 真正在驗收三層理解 蘇珊要 Claude 維護的清單可以分成三層。 第一層是 **問題**：問題是什麼、為什麼它會存在、有哪些不同分支。這一步很關鍵，因為除錯最常見的災難不是修錯 code，而是從一開始就相信錯的問題敘事。 第二層是 **解法**：解法是什麼、為什麼選這個解法、設計決策和邊界情境是什麼。[Agent](https://gu-log.vercel.app/glossary#agent) 寫出可以跑的 code 不代表架構合理，也不代表下一次需求變動時不會崩掉。 第三層是 **更大的脈絡**：這件事為什麼重要、改動會影響什麼。沒有這一層，開發者會變成只知道眼前 bug 修好了，卻不知道產品、維運、測試或後續開發哪裡被動到。 這其實是一套很實用的 agent 事後驗收標準：不要只問「測試有沒有過」，還要問「人有沒有跟上」。 > **Mogu murmur：** > > Agentic coding 最可怕的不是 AI 寫錯，而是 AI 寫對了，但人類不知道為什麼對。因為下一次它寫錯時，操作者也會用同樣的信任感按下去。這就像副駕很會開車，但每次轉彎都不說原因；坐久了，人會忘記自己其實也該看路。 --- ## 讓人講回來，比摘要更重要 這段 prompt 最有價值的一句，是要求 Claude 先讓人重述理解：先用自己的話說出目前理解，再由 Claude 補缺口。 這比摘要強很多。摘要是 agent 把事情整理給人；講回來是讓人把理解重新組裝一次。前者像收到會議記錄，後者像被要求真的講清楚這場會議在決定什麼。 在 coding 工作階段裡，讓人講回來可以抓到幾種常見漏洞： - 只知道症狀，不知道根因 - 只知道修法，不知道取捨 - 只知道順利路徑，不知道失敗模式 - 只知道這次過了，不知道下次怎麼辨認同類問題 這些漏洞如果不補，agent 完成的工作越多，人反而越像專案的外包驗收窗口。 --- ## 小測驗不是考試，是防止假懂 [Prompt](https://gu-log.vercel.app/glossary#prompt) 後半段要求 Claude 用開放題或選擇題確認理解，必要時看 code 或使用除錯器。這聽起來有點像補習班，但放在 agent 工作流程裡很合理。 因為「看懂」是一個很會騙人的狀態。尤其 agent 給出的解釋通常很順，順到讀者會把流暢感誤認成理解感。真正的測試是能不能回答一個小問題：如果同一個 bug 換一種形式出現，還認不認得出來？ 這也是為什麼這段 prompt 不只是 prompt 設計，而是流程設計。它把 Claude 從「代工者」改造成「代工者 + 教練 + 驗收官」。 當然，這套流程不能每次都重跑完整版。小改動只需要一兩句確認；架構改動、排障、跨檔案 refactor，才值得完整走一輪。重點不是把工作變慢，而是避免快到人跟不上。 --- ## gu-log 讀者可以怎麼用 這段 prompt 最適合用在三種情境。 第一種是 **agent 做完一段複雜工作後**。不要只收「done」，要求它用問題、解法、邊界情境、影響四格回報，並讓操作者用自己的話補一次。 第二種是 **除錯工作階段中途轉向時**。只要 agent 改變假設，就要同步說明：原本假設為什麼不成立、新假設憑什麼成立、還有哪些分支沒排除。 第三種是 **PR review 前**。讓 agent 不只列改動清單，而是解釋這個 PR 的設計取捨和風險。檔案清單可以之後再看，先確認人有沒有抓到高層意思。 這樣用 Claude，不是把人類放回每一行 code 的苦工位置，而是把人放回決策位置。 --- ## 結語 這段 prompt 之所以紅，不是因為它發明了什麼神奇咒語，而是它講中了一個很日常的恐懼：agent 越強，人越容易變成坐在旁邊點頭的專案經理。 真正成熟的 agent 工作流程不只是讓 AI 多做一點，而是讓人少失去一點。少失去脈絡、少失去判斷、少失去下一次自己辨認問題的能力。 Claude 可以開車，但方向盤不該變成裝飾品。