我如何阻止我的程式碼代理在看到計畫前就寫入檔案
事先揭露：我開發了本文所介紹的工具。它是
免費且採用 Apache-2.0 授權，所以我的興趣是「讓人們覺得這個工具有用」勝過
「讓人們付費給我」。
讓我走上這條路的失敗經驗應該很多人都有過。我給代理一個
多步驟的目標：重構這個模組、更新 README、加入測試。一切
都進行順利，直到第 4 步——我才發現它在一開始就誤讀了第 1 步。
那時檔案已經被寫入了。沒有計畫可以修正，因為計畫只存在於
模型的腦海中。只剩下需要復原的東西。
這就是核心問題：計畫是工作階段的副作用，而不是你可以檢查和編輯的成品。這篇文章要談的是我最終採用的設計決定——讓計畫成為你先核准的東西，而不是你只能期待的東西。
計畫是一個有型別的成品
這個工具以唯讀方式讀取你的程式庫，然後回傳一個有序的任務清單。
每個任務都帶有四項後設資料：執行器（Claude Code、Codex 或
OpenCode）、模型、思考強度，以及模式。這不是裝飾——
這四項才是任務實際執行的方式。你可以改寫任何提示、增加
或刪除任務、重新連接依賴關係（task 4 depends on task 2），或是更改
單一任務所使用的模型。已完成的作業會保持完成狀態。你在編輯時不會有任何東西需要反覆呼叫
AI。
為什麼要使用獨立的規劃器
很自然的問題是「為什麼不直接使用計畫模式？」有兩個原因。
第一，計畫模式是在之後會執行的工作階段內進行規劃——計畫只是建議，模型有可能偏離它。而在這裡，計畫是由一個
獨立的過程產生，這個過程在物理上無法寫入你的程式庫。它的探索
是嚴格唯讀的；任何會寫入的指令會在核准提示出現前就被拒絕，所以不存在「允許一次」可以點擊通過。變更
屬於執行器，而非規劃器。
第二，逐任務分配。一個安全性重構和一個 README 更新不應該
使用相同的模型。規劃器會在整個計畫中公開地做出這個組合決策，在你花費任何執行 token 之前——而且你可以
覆蓋其中任何部分。
判斷來自證據，而非意見
我最在意的部分發生在後續。代理不擅長為自己評分
——更糟的是，它們會在無法編譯的建置上宣布成功。因此在這裡
只有當獨特的完成標記出現在
執行器的輸出中，並且旁邊保留了結束代碼作為獨立證據時，任務才會被標記為完成。
模型永遠不是決定因素。如果工作階段結束並聲稱工作已完成
卻沒有出現標記，它就會大聲失敗。
如果你看過代理說「完成了」然後打開一個仍然有問題的檔案，
那就是整個動機。
誠實的限制
規劃器仍然是 LLM，有時候會寫出不好的計畫。這裡的論點不是
它永遠正確——而是一個你能看到並編輯的壞計畫只花一分鐘，而一個你看不到的壞計畫會花掉一個下午。完成標記只證明
工作階段已結束並聲稱工作完成，而非程式碼是正確的。
另外：TUI 在每個平台都需要 tmux（在 Windows 上，這代表需要 WSL）。CLI
和 VS Code 擴充功能則可以原生執行，不需要它。
試試看
npm install -g ordewell && ordewell
Enter fullscreen mode
Exit fullscreen mode
把它指向一個你很熟悉的程式庫，然後閱讀它回傳的計畫。那第一個
計畫就是整個論點。
- GitHub: github.com/ordewell/ordewell
- Apache-2.0，免費，沒有付費方案。
很樂意回答任何問題，包括「為什麼不直接做 X」。