概述
Superpowers v6.4.2（2026-09-25 發布）只有一個主軸：writing-plans 產出的計畫變精簡了。計畫只記錄實作需要的決策，不再把程式碼抄進去（#2333）。
這個改動來自一個具體回報：部分前沿模型（frontier model），包括 Opus 5.5，寫計畫時會「過度熱心」（overzealous）——在設計計畫的階段就試圖把整個專案實作出來，產生一堆與計畫無關的 scratch build。修正後重現原始回報，那些 scratch build 消失了，而計畫撰寫時間降為約四分之一、token 用量約三分之一。
問題：計畫變成程式碼逐字稿
計畫（plan）存在的理由是讓人在實作前先審查、先修改。但如果模型把計畫寫成一份「已經寫好的程式碼」，計畫就失去意義：
- 審查者要讀的是決策（這個函式長什麼樣、測試要斷言什麼），不是幾百行沒有執行過的程式碼。
- 計畫裡的程式碼沒有被編譯、沒有被測試，卻占了最多篇幅——它只是逐字稿（transcript）。
- 當模型有能力直接寫出實作，它就會忍不住在規劃階段把整包做完；這正是回報中 scratch build 的來源。
什麼是「決策」
v6.4.2 把計畫的內容規格收斂到三種決策：
| 步驟類型 | 計畫要寫的內容 |
|---|---|
| 測試步驟 | 測試名稱 + 它的斷言（assertions） |
| 程式碼步驟 | 精確的函式簽名（signature）、所在檔案、規格給定的值 |
| 驗證步驟 | 要跑的指令 + 通過時應看到的輸出 |
只有當演算法無法由簽名與測試決定時，才附上 body。要引用另一個任務的產出，走那個任務的 Interfaces 區塊，而不是把程式碼複製過來。
這些是「規格給定的值」（the spec’s values）——來自規格、決定實作對錯的常數與介面，而不是模型自由發揮的細節。
新舊寫法對照
反例（舊：把程式碼抄進計畫）：
### 第 2 步：實作 percent 函式
function percent(n, total) {
if (total === 0) return 0;
return Math.round((n / total) * 100);
}正例（新：只記錄決策）：
### 第 2 步：實作 percent 函式
- 簽名：percent(n: number, total: number): number
- 檔案：src/format.ts
- 規格值：total 為 0 時回傳 0；其餘四捨五入到整數百分比
- 測試：percent(1, 4) === 25、percent(1, 0) === 0正例沒有寫出 body——因為簽名、規格值與斷言已經唯一決定了這個小函式的行為，實作者照著寫就會寫對。
取代「No Placeholders」：What a Step Contains
舊版 skill 用「No Placeholders」告誡：不要寫 TODO: 在這裡處理錯誤 這類佔位符。v6.4.2 改用新章節 「What a Step Contains」 取而代之，直接規定每一步應該包含什麼（上一節的三種決策）。
佔位符仍然被點名——只是它現在是「相反的失敗」：計畫不該是空話，也不該是逐字稿。
自我審查：計畫不該比規格長好幾倍
新版 skill 會拿計畫自己的長度與規格（spec）比較：
- 計畫若比規格長好幾倍，就是逐字稿，不是計畫。
- 當程式碼區塊主導了篇幅，就把它們換回簽名與測試斷言。
步驟大小與讀者描述也改了
兩個容易忽略但重要的調整：
- 步驟大小：從「2–5 分鐘」改為「一個動作 + 一個可檢查的結果」（one action with a checkable result）。時間估算不再是計畫的單位。
- 讀者描述：從「zero context、questionable taste」改為「一位知道精確介面與測試後，就能寫出道地程式碼的工程師」。計畫假設讀者有能力，所以只需要把介面與驗收講清楚，其餘留給實作。
這樣改，品質有掉嗎？
沒有。上游用 planted-defect probes（預埋缺陷的探針任務）測試：新 skill 寫出的每一份計畫在 Sonnet 5 上都通過 9/9，與「全程式碼計畫」的結果相同。少了逐字稿，實作正確率不變。
其他變更
- 移除
plan-document-reviewer-prompt.md：已經沒有任何地方引用它。 - 移除
CLAUDE.md：Claude Code 現在直接讀AGENTS.md，但只在沒有CLAUDE.md時才讀——保留一行指標反而會遮住真正的指引。
對使用 writing-plans 的實務影響
- 計畫會明顯變短：你審查計畫的時間縮短，焦點回到「介面與驗收對不對」。
- 實作者拿到的是決策：簽名、斷言與規格值足以讓有能力的 agent 寫出實作；如果你的計畫以前靠抄程式碼來「說清楚」，現在請改用簽名與測試斷言。
- 估時不再是重點：舊計畫的「預估 30 分鐘」不是新格式的要求；步驟只要做到「一個動作 + 一個可檢查的結果」。
- 模型越強越需要這道護欄：能力強的模型最容易在規劃階段偷跑實作，這正是這個修正由 Opus 5.5 案例催生的原因。
學習重點
- 計畫與實作的職責邊界：計畫的產物是決策，實作的產物才是程式碼。把兩者混在一起，計畫就失去「可先審查、可先修改」的價值。
- 用比例自我審查是便宜的護欄：「計畫不該比規格長幾倍」不需要額外工具或模型，只是一個長度比較，就能偵測 agent 越界。
來源：v6.4.2