「幫我把登入功能修好。」如果直接讓 AI 動手，它可能一次改五個檔案、重構整個驗證流程，甚至順便換掉你沒打算碰的套件。

Day 10 說動手前先讓 AI 把不清楚的地方問完，那解決的是「我沒說清楚」。這篇解決的是另一件事：就算需求百分之百清楚，你還是不知道它打算動哪裡。

所以在它開始改之前，先讓它回答四件事：

• 準備做哪些修改？
• 會影響哪些檔案？
• 有哪些是不會碰的？
• 修改後要怎麼驗證？

第三個問題最容易被漏掉，卻最能擋災。列出要動的範圍，不等於劃出不動的範圍——「不會碰 auth 資料夾和資料庫 schema」這種話，你不問它不會主動講。

第四個問題其實就是 Day 07 的驗收標準。計畫和規格，是同一件事的兩端。

這就像房子漏水，師傅進門不會直接拿鐵鎚敲牆。他會先說：「我懷疑是這條管線，會拆這一小塊，最後再做漏水測試。」

計畫是自然語言，誰都讀得懂

這是 Plan-first 最值錢的地方。

你不一定看得懂每一行程式，但你看得懂「準備重寫整個元件」。你只想改按鈕文字，它卻列了六個檔案；你的需求明明是修前端，它卻打算動資料庫——這些在計畫階段都一眼可見。

Day 04 問過：AI 爬到第四、第五階之後，一次跨十個檔案修改，你還驗得動嗎？計畫就是其中一個答案。不管它改幾個檔案，計畫永遠是一段你讀得懂的話。

計畫是拿來砍的

看完計畫，你不必只在「同意」和「重來」之間選。

計畫可以談：「只做第 2 項，第 1 和第 3 先不要」「不要碰 auth 資料夾」「先別重構，這次只修 bug」。改一份計畫的成本是幾句話，改一份已經動完的程式碼是另一回事。

Day 06 說過先要架構再要程式，是因為便宜的東西才好否決。這次是同一個道理，用在既有的程式碼上。

多數 coding 工具現在都有 plan mode 或唯讀模式，不必每次自己打提示詞。

先聽完師傅要拆哪面牆，再決定要不要把鐵鎚遞過去。

延伸閱讀

Wang, L. et al. (2023). Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. ACL 2023, pp. 2609–2634（arXiv:2305.04091）。研究指出，讓模型先擬定計畫、再依計畫逐步執行，可以明顯減少「遺漏步驟」這類錯誤——論文在抽樣測試中發現約 12% 的題目原本會漏掉中間步驟。不過那談的是模型用計畫改善自己的輸出；在寫程式的場景，計畫還多了一個用途：它讓你有機會在動手前喊停。