AI程式設計工具中計畫模式的衰落

從線性規劃到迭代執行的轉變

傳統的「計畫模式」在AI程式設計工具中——即模型在撰寫任何程式碼之前，先產生一份結構化的規格供人類審核——正逐漸過時。這種轉變是由模型能力的顯著提升，以及一個根本性的認知所驅動：軟體開發是一種發現性的迭代過程，而非線性的步驟序列。

對許多開發者而言，Chat → 規格 → 審查 → 實作 的僵化工作流程已被證明具有破壞性。現實世界的工程通常遵循更自然的循環：理解 → 行動 → 檢視 → 澄清 → 調整 → 再次行動。在此模式中，實際建構的行為才會揭示下一組問題，因此預先定義的「計畫」是一種人工的限制，迫使使用者過早完成思考。

為何傳統計畫模式失敗

幾個技術與心理因素導致了明確計畫文件的衰落：

1. 模型能力與介面設計的落差

隨著模型在擴展上下文視窗與更好的記憶能力下，能更有效地探索程式碼庫並做出合理的架構假設，人類必須透過詳細計畫來引導模型的需求已大幅減少。模型能自行可靠地做出的每一個決策，都是無需在計畫文件中浮現的決策。

2. 「AI生成文字」的摩擦

閱讀長篇AI生成的規格會帶來顯著的認知負擔。LLM生成的散文過於結構化且重複，常導致「視線遊移」，使人類審查者因文本過於枯燥而忽略關鍵錯誤。當規格長到無法實用時，該文件的價值便蕩然無存。

3. 將規劃與計畫混淆

在規劃（推理問題的認知過程）與計畫（此過程產生的靜態文件）之間，存在關鍵差異。雖然規劃過程仍然至關重要，但產生的文件往往是一種低價值的產物，一旦開始實作，便立刻過時。

對規劃的不同觀點

儘管趨勢傾向於迭代執行，但開發者社群中仍有一部分人認為，明確的規劃對特定用例依然至關重要：

支持保留計畫模式的論點

風險控管： 對於高風險的架構變更或耗時的計算任務，「暫停並確認」的門檻可防止 costly 的錯誤。
上下文收集： 有些開發者主要使用計畫模式，以迫使模型在開始撰碼前讀取更多程式碼庫，降低「幻覺式」實作的機率。
人類導向： 規劃有助於人類維持對系統的內在模型，特別是在多個代理同時進行變更時。
複雜協調： 對於極大型功能，將主計畫拆分成較小、可平行處理的子計畫，可提升模型的「視野」，並避免上下文壓縮問題。

支持迭代方法的論點

更快的反饋迴圈： 在代理產生具體結果後進行修正，通常比試圖在文字文件中預測所有邊界情況更快。
降低認知負荷： 消除「這個任務是否足夠大，值得進行正式計畫？」的「元問題」，可減少摩擦。
以執行為基礎的發現： 如一位社群成員所言：「執行就是答案」，因為在變更實際發生前，你無法知道編譯器或遠端系統會如何反應。

AI輔助理解的未來

計畫模式的消亡並不代表規劃的消亡；相反，這標誌著需要新的介面，以支援人類理解，而不依賴於文字密集的文件。持續的挑戰在於：人類如何在機器改變系統的速度遠超過人類檢視變更的速度時，仍能維持對軟體系統的連貫內在模型。

傳統計畫模式的新兴替代方案包括：

互動式「質詢」： 使用特殊提示（例如 Matt Pocock 的「grill-me」技能），強制AI在實作前向使用者提出 exhaustive 的澄清問題。
確定性視覺化： 在 README 中生成資料模型或 RBAC 表格的 SVG，提供易於解析的視覺化、可驗證的真實來源，比文字規格更清晰。
代理審查： 使用第二個代理，在主代理執行程式碼前，根據專案規則審查建議的方案。