用四個提示詞對抗 Claude Code 的迎合

Claude Code 中的 AI 迎合是什麼？#

心理學界早就有個詞可以形容這種現象：諂媚。諂媚者為了讓對話繼續，會說你想聽的話。大型語言模型出現後，這個詞也進入了 AI 研究領域；Anthropic 在一項官方分析中坦承，模型經常為了迅速附和而犧牲準確性。

寫程式時，情況會像這樣。你對 Claude Code 說：「修好 authMiddleware 的錯誤；magic links 不能用了。」迎合型模型不會提出釐清問題，不會要求你提供記錄，也不會詢問你使用的函式庫版本。它會立刻提出解決方案，因為它受訓要快速提供幫助。這個解決方案看起來會很正確：有匯入、有錯誤處理、有註解。但它解決的是別人的問題，是 Claude 根據拼湊的片段脈絡自行編造出來的方案。

問題不在 Claude，而在於你如何措辭。當你問「要怎麼修？」時，就已經先假設問題能修好了。迎合型模型會順著這個框架提出「修正方案」，即使真正的問題出在架構、函式庫版本，或你描述的症狀其實只是完全不同根本錯誤所造成的結果。

判斷請求是否會引發迎合，有個簡單方法：如果我無法用 3 句話回答「到底哪裡壞了？」，就還沒準備好開始解決。我需要先診斷。修正是下一步。4 步驟循環正是從這裡開始。

案例研究：一小時內還原 8 個提交#

這是 2026 年 4 月發生的具體案例。我當時正在處理 src/lib/auth/ 中的 magic-link 驗證。症狀是 token 已完成驗證，但工作階段沒有儲存。使用者點擊電子郵件中的連結進入網站，5 秒後卻又被送回 /login。

我開啟 Claude Code，輸入：「magic-link 後工作階段沒有儲存；查看 src/lib/auth/ 並修好。」Claude 提出 3 個釐清問題，接著立刻產出計畫。它說：「我會更新 callback handler、重寫 JWT serializer、加入明確的 Redis 儲存，並修正 middleware 中的競態條件。」聽起來很合理。我批准了計畫。

18 分鐘後，我手上有一份涵蓋 14 個檔案的差異。magic link 還是不能用。但現在 refresh token 也不能用、密碼登入壞了，付款路由還出現奇怪的 500 錯誤。測試也失敗了。我開始還原變更。

我用 git reset --hard origin/main 還原了 8 個提交。一小時的工作全白費了。如果你想了解如何正確還原而不丟失有用內容，我在Claude Code 還原變更指南中另有說明。

我坐下來好好調查。我開啟 src/lib/auth/magic-link.ts:42 親自閱讀，查看記錄，也檢查 Redis。20 分鐘後，我找到了原因。問題只有一行：set-cookie 標頭缺少 SameSite=lax 屬性，Safari 在從電子郵件網域重新導向回網站時拒絕了 Cookie。跟 JWT、Redis、middleware 都無關。就一行。

我請 Claude 修復問題時，它完全沒查看瀏覽器記錄，也不知道 Safari 相關情況。它根據「工作階段沒有儲存 = 序列化問題」這種模式建立假設，因為這是訓練資料中最常見的答案。迎合型模型產出的解決方案在統計上看似合理，卻和我的任務毫無關係。

我把教訓寫成一條規則：永遠不要問「要怎麼修？」而要問「先確認事實。」接下來只需要把這條規則整理成可實際使用的循環。

迎合的來源：Opus 4.8 上線時與 2026 年 5 月的情況#

4 月時，Anthropic 另在一份工程事後檢討中，調查了 Claude Code 的快取錯誤如何使模型在不同回合之間「忘記」自己的推理。

模型忘記推理過程後，就更容易根據模式「猜」答案；換句話說，也更容易變得迎合。

面對 4.8 版發布該怎麼做？不要選「比較容易應付」的模型，也不要退回 4.7。根據事實調整提示詞：模型更容易附和，因此要更明確要求它「先確認事實」。如果你還不清楚 Opus 4.8 內部究竟有哪些變化，我在Claude Code 中 Opus 4.8 的評測中做了詳細比較。

什麼時候需要這 4 個步驟，什麼時候只是浪費時間#

具體例子：修改歡迎郵件文案，直接做。替網站新增 CTA 按鈕，不用循環，使用 Plan Mode。將專案從 MySQL 遷移至 Postgres，必須使用 4 步驟循環。正式環境出現奇怪的 500 錯誤，但無法在本機重現，則要使用 4 步驟循環，並額外加入「零」步驟：「我們先建立一個最小可重現範例。」

使用這個循環時常犯的錯誤，是把它套用在瑣碎任務上。這會拖慢速度，也會讓人很快對這套方法失去興趣。只有在錯誤造成的代價高於 15 分鐘規劃成本時，才需要這個循環。

開始使用這套循環前，請記住，4 個提示詞都在同一個 Plan Mode 工作階段中使用。如果你還沒用過這個模式，請先閱讀Claude Code 的 Plan Mode 指南，再回來繼續。

步驟 1：禁止提供解決方案，要求 Claude 先確認事實#

這是最重要的一步。它會阻止「解決方案如下」這個第一反應。提示詞如下：

我遇到以下情況：[症狀]。

你現在的任務是釐清事實。禁止提出任何解決方案、想法或建議。只能整理：
- 我觀察到的情況（症狀的確切描述）
- 可重現步驟（最小情境）
- 有哪些資料可用（記錄、版本、環境）
- 缺少哪些資料（需要蒐集什麼）

嚴格停止條件：不要提出解決方案，只記錄診斷結果。如果你想提出建議，請改為向我提問。

這麼做的效果是什麼？明確禁止提出解決方案後，Claude 就不能走捷徑。它必須填寫 4 個欄位：我看到了什麼、如何重現、我知道什麼，以及我不知道什麼。最後一欄最有價值。最後往往會發現：「我不知道函式庫版本、記錄裡有什麼，或這個症狀是否只在正式環境出現。」這就是下一步的著力點。

步驟 1 的陷阱：如果症狀描述太模糊（「驗證不能用」），Claude 還是可能開始猜測。解決方法就在提示詞本身：用一句話精確描述症狀，並提供最精簡的 3 步驟情境。如果做不到，就表示你還不了解究竟哪裡壞了；不管怎樣，Claude 的回答都不會有用。

步驟 2：從網路找先例，避免憑記憶產生幻覺#

這能阻止第二個反應：「憑記憶編造解決方案。」提示詞如下：

現在已經確認診斷，請在網路上尋找
解決類似問題的先例。

至少列出 3 種不同做法。每種做法都要提供：
- 第一手來源連結（issue、文章或文件）
- 簡短的做法說明
- 對我們的情況而言的優點與缺點
- 已知的陷阱

禁止提供未經連結確認、僅根據你自身知識提出的說法。如果找不到先例，請明確說明。

實際效果：Claude 會到外部尋找資訊，帶回可驗證的做法。你會看到 GitHub issues 和文件的連結。如果 Claude 找不到先例，這表示任務可能很特殊，或症狀描述有誤。請回到步驟 1。

這個做法也有失靈的情況。Claude 可能引用不存在的連結，例如聲稱「這裡有 repository X 的 issue 4291」，但 issue 4291 實際上談的是別的事情。可以在 CLAUDE.md 中加入明確規則：「引用連結前，務必使用 WebFetch 開啟連結。」詳情請見正確設定 CLAUDE.md 的指南。

步驟 3：在 plans/ 中撰寫詳細計畫，預先考量風險#

此時 Plan Mode 就開始發揮應有的作用。提示詞如下：

採用步驟 2 中最好的選項，並在以下檔案中撰寫詳細計畫：plans/YYYY-MM-DD-fix-[name].md：

- 我們要修改的具體檔案（完整路徑和行號）
- 要新增和移除的內容
- 要撰寫哪些測試，以及哪些現有測試必須通過
- 預先考量後續 2 到 3 步的風險（可能對使用者造成什麼影響）
- 發生問題時的回復計畫

每個步驟都加上核取方塊 [ ]。檔案必須能在一個畫面內看完。
如果計畫超過 200 行，請拆分為多個階段。

結果：計畫會成為成果檔案，而不是聊天中的臨時筆記。兩週後你可以重新閱讀、交給另一個代理，或將它作為 /goal 指令的條件。計畫檔案會比 Claude Code 的對話留得更久。

關鍵在於預想後續 2 到 3 步的風險。這能阻止另一種迎合模式：只看好處、不考慮副作用的樂觀計畫。要求 Claude 明確列出風險時，它會找出一般計畫中可能悄悄略過的事情。

步驟 4：自我檢查計畫，抓出迎合式假設#

最後一道把關。提示詞如下：

現在請務必進行自我檢查。誠實地重新閱讀你的計畫。

計畫中是否有任何內容是憑空想出來，而且沒有透過以下資料確認？
- 你讀過的程式碼
- 你在步驟 2 引用的文件
- 步驟 2 中的先例

如果有，請明確標示並修正或移除。

也請檢查：
- 是否提到了尚未安裝、package.json 中沒有的函式庫
- 是否提到了我未指定的環境變數
- 計畫步驟是否只用概括的方式描述，而沒有具體細節

這麼做的效果是什麼？Claude 必須重新檢查自己的推理。在作者約 50 次循環的樣本中，至少有 2 到 3 個計畫項目在步驟 4 特別修正。這些是迎合型模型在步驟 3 試圖混過去的內容，步驟 4 會把它們抓出來。

完成 4 個步驟後，計畫就可以送交批准。你可以開始實作，不必再擔心「要是我得還原 8 個提交怎麼辦？」

為什麼正好是 4 步驟，而不是 2 步或 7 步？#

以下依據 Anthropic 在官方文件中指引 Claude 所用的方法，說明其中的道理。

文件建議採用四階段工作流程：Explore、Plan、Implement、Commit。

我的 4 步驟循環，是為了對抗迎合而專門調整 Plan 階段的做法。在 Anthropic 的 4 個階段中，我把其中一個擴展為 4 個微步驟：禁止解決方案、尋找先例、撰寫計畫，以及自我檢查。之後再將這份詳細計畫交給 Implement 和 Commit 階段。

如果省略 4 個步驟中的任何一步，會發生什麼事？

表格清楚說明，每一步都會阻止特定類型的錯誤。4 步驟缺一不可，因為每一步會抓出不同類別的問題。如果任務看起來小到只需要兩步，那它真的很小，根本不需要 Plan Mode。

plans/、/goal 指令與後續步驟如何配合#

這個循環在包含以下內容的系統中運作：

1. 已啟用 Plan Mode（在 Claude Code 中按兩次 Shift+Tab）。
2. Repository 中有 plans/ 資料夾，用來儲存計畫。
3. 可選擇使用 /goal 指令，自動執行較長計畫中的工作。

先說 plans/ 資料夾。完成步驟 3 後，你會得到一個包含階段和核取方塊的 plans/2026-05-27-fix-magic-link.md 檔案。這是一份成果檔案。一週後開啟它，就會想起當初為什麼選擇那個做法。三個月後，你會遇到類似任務並重用它。六個月後，你可以把它交給同事，幫對方省下兩週熟悉工作的時間。plans/ 資料夾是Claude Code 中「第二大腦」概念的一部分。

再說 /goal。完成 4 個步驟並批准計畫後，離開 Plan Mode，輸入：

/goal 執行 plans/2026-05-27-fix-magic-link.md 中的所有階段，直到 test/auth 中的所有測試都通過，或在 30 個回合後停止

本機 Claude Code 工作階段應保持終端機執行、電腦喚醒與網路可用；除非明確安排支援的保持喚醒設定，否則不要闔上筆電。回來時請查工作階段歷史，可能是完成、回合上限、權限請求或錯誤。主機睡眠時，goal 不保證仍有進度。沒有 4 步驟循環時，/goal 會把 token 浪費在無用的反覆嘗試上。有了循環，/goal 就能依據完成的計畫執行，直到測試通過。

接下來該怎麼做？如果你剛開始使用 Claude Code，就在下一個非瑣碎任務上試試這個循環。不要選拼字錯誤；選擇會動到 3 個以上檔案，或是涉及你不完全了解的行為的任務。複製上面的提示詞，填入自己的細節。你會注意到回復變更的頻率有所變化。

如果你已經在使用 Plan Mode，請在 repository 中新增 plans/ 資料夾。替自己決定一種檔名格式：YYYY-MM-DD-feature-name.md。一個月後會有 20–30 個檔案；六個月後則會超過 100 個。這就是組成專案第二大腦的方式：一段持續累積的決策歷史。如果你想深入了解提示詞之前的上下文管理，我另外把Claude Code 的 context engineering當成一門獨立領域介紹。

如果你已經同時使用 Plan Mode 和 plans/，就挑一個自動化任務試用 /goal。選一件平常會花 30–40 分鐘手動完成的事。先跑完 4 個步驟、儲存計畫、啟動 /goal，並保持本機終端機與電腦喚醒。若要在這台電腦關機時繼續，先使用明確設定的遠端或雲端執行路徑，確認任務確實在那裡運作。