試完Superpowers、OpenSpec、Kiro、GStack，SDD五個常識全錯了
整理版優先睇
SDD 工具選型五大誤區：Spec 唔係 Truth，精確度係倒 U 曲線，輕量先係趨勢
作者親身踩坑半年，試勻 Plan Mode、Superpowers、OpenSpec、Kiro、GStack 五款 SDD 工具，發現五條社區常見「常識」其實全部錯曬。文章首先指出 SDD 圈最流行的五個錯誤信念：Spec 當真理、No Spec No Code、Spec 越精確越好、Spec 要完整同步歸檔、工具流程越重越好。作者用工程角度逐一拆解，解釋點解 Spec 冇編譯器做裁判、精確度同代碼質量成倒 U 曲線關係、同步維護成本遠大於價值，同埋工具融合只會疊加協調負債。
然後作者逐一評測五款工具：Plan Mode 夠用就最好，Superpowers 用 token 換紀律，OpenSpec 理想卻工程唔現實，Kiro 體驗流暢但鎖死 AWS 生態，GStack 只適合一人團隊。最後提出決策路徑：漸進式加層，唔好並聯縫合。整體結論係：選最輕嘅工具等於賭模型變強，選最重嘅等於賭模型停滯；團隊應該按實際痛點逐層疊加，唔好迷信全流程覆蓋。
- Spec 冇編譯器做裁判，唔可以當 Truth；測試先係可執行嘅 Spec，pass/fail 無歧義。
- 「先寫 Spec 再寫 Code」係瀑布思維翻版；正確流向係 AI 出方案 → 人審關鍵決策 → AI 執行。
- Spec 精確度同代碼質量係倒 U 曲線：鎖 What 層（邊界、不變量），唔鎖 How 層（實現路徑），否則壓低模型能力上限。
- Spec 同步維護成本係代碼嘅 3-4 倍，重疊部分冇沉澱價值；代碼外知識應抽到 CLAUDE.md 同知識庫。
- 工具融合嘅協調成本高，1+1<1；正確路徑係漸進式加層，每次只加一層解決當前真痛點。
內容片段
代碼質量 ▲ │ ╭──╮ │ ╭╯ ╰╮ │ ╭╯ ╰╮ │ ╭╯ 最優區 ╰──── 過度約束區 │╭╯ ├╯ │ 信息不足區 └──────────────────────► Spec 精確度 邊界/不變量/AC 技術選型/實現路徑/代碼結構 （該鎖的） （不該鎖的）五大常見錯誤
SDD 圈子有五條被當成常識嘅講法，作者全部否定：Spec 係 Truth、No Spec No Code、Spec 越精確越好、Spec 要完整同步歸檔、工具流程越重越好。佢逐條拆解，發現每條都同工程現實脱節。
Spec 係一份冇編譯器嘅源代碼，冇 type check、冇 pass/fail、冇 CI 強制執行。代碼同測試唔一致 CI 會紅，Spec 同代碼唔一致冇人報錯——直到有人翻出 spec.md 話「當初唔係咁定」。
「先寫完整 Spec → 再生成代碼」= 喺不確定性最高嘅時候做最完整嘅承諾，係 waterfall 換咗個馬甲。正確流向係 AI 出方案 → 人審關鍵決策 → AI 執行。
How 層係模型最強嘅決策空間，你插一條樁，模型會忠實執行一個次優方案，而且唔會話俾你聽有更好嘅選擇。
Spec 同代碼重疊部分冇沉澱價值——代碼就係最好嘅文檔。保留精確嗰份就夠，唔需要兩份。
同步維護成本係 3-4 倍，換來一份冇人睇嘅文檔。兩個用不同語言描述同一事物嘅產物，冇編譯器強制一致性，漂移唔係例外，係必然。
五款工具設計哲學評估
帶住五條新認知去睇工具，作者用一句話總結每個工具嘅設計哲學同判斷。Plan Mode：夠用就係最優解；Superpowers：用 token 換紀律；OpenSpec：理想豐滿但工程骨感；Kiro：Spec 即 IDE，代價係鎖死 AWS；GStack：一個人等於一個團隊，對團隊協作冇用。
Plan Mode 係 SDD 嘅最小構件——「人審意圖」呢一個控制點，80% 日常迭代到呢度就應該停。
Superpowers 嘅真正創新唔係 TDD 本身，而係測試食咗 Spec 文檔：Brainstorm 階段直接將 AC 翻譯成測試，Spec 冇裁判同維護成本兩個問題從根消失。
OpenSpec 嘅活基線理念本質係為 IDD 做預演，但 2026 年自然語言冇裁判機制，維護成本線性增長，模型變強嘅速度可能快過 Spec 基建成熟。
Kiro 嘅 EARS 句式係真正有工程價值嘅創新——結構化需求天然可轉測試。但成個工作流焊入 IDE，開發流程同 Amazon 路線圖綁定，離開 Kiro 就帶唔走 Spec 產物。
GStack 解決嘅唔係 SDD 問題，係「一個人點樣當一個團隊」嘅問題。角色模擬質量完全取決於底層模型，對團隊協作幾乎冇用。
- Plan Mode：夠用就係最優解，唔使其他工具。
- Superpowers：用 token 換紀律，質量下限 locked。
- OpenSpec：遠見值得尊重，但工程現實未能支撐。
- Kiro：體驗最絲滑，但代價係生態綁定。
- GStack：個人武器，團隊唔適用。
縫合怪方案（如 OpenSpec + Superpowers）哲學不自洽，Spec 派信文檔、TDD 派信測試、IDE 派信內置流程，三套世界觀靠膠水粘埋一齊，協調成本高到要再造工具管理融合本身。一律唔碰。
我哋嘅選擇：Plan Mode 打底 + Superpowers 兜底
作者團隊嘅選擇係：Plan Mode 打底，Superpowers 兜關鍵模塊，Plan 產物持久化到文檔。輕量需求（前端頁面、配置變更、CRUD）就 Plan Mode——AI 出方案，人審批准後執行，將計劃持久化到文檔，唔依賴 session 存活。
前端 TDD 收益有限，UI 狀態多，視覺迴歸靠 snapshot 唔靠單元測試，審批門夠用。
後端複雜需求（資金鍊路、權限模型、核心業務規則）加 Superpowers——唔係為流程，係為質量下限。呢啲模塊出 bug 嘅代價係生產事故，測試鎖住驗收標準比任何文檔都可靠。
冇用 OpenSpec，因為團隊唔需要審計追溯，維護活基線嘅成本唔肯俾。
冇用 Kiro，唔想被 IDE 綁定。GStack 淨係個人項目偶爾用嚟做產品思考，唔算正式工具鏈。
作者強調呢個選擇係基於「模型夠強、團隊 10 人以內、ToB 產品」嘅上下文，唔係標準答案。
未來趨勢：Spec 會變成 AI 嘅中間表示
作者三個判斷收束：真正值得投資嘅唔係 Spec 工具，係 Context + Eval。知識庫令 AI 知道你個系統一直信啲乜，測試唔俾考生批改自己試卷。Spec 工具喺中間，呢一層正在變薄。
Spec 會變成 AI 嘅中間表示，好似彙編語言——重要，但人唔會直接寫。SDD 贏咗 2025-2027 嘅戰役，但「人寫 Spec」唔係終局。
選最輕嘅工具 = 賭模型變強，選最重嘅 = 賭模型停滯。你賭邊邊？
作者最後拋出問題，邀請讀者分享自己團隊嘅工具組合同遇到嘅衝突。
踩咗半年坑，我發覺 SDD 圈子入面有五條「常識」，全部都係錯嘅：
1. Spec 係 Truth —— Spec 連編譯器都冇，憑咩叫 Truth？ 2. No Spec, No Code —— 呢個係瀑布思維嘅復闢，人寫 Spec 係上一代嘅做法 3. Spec 越精確效果越好 —— 精確度同代碼質量係倒 U 曲線，過咗拐點就係負收益 4. Spec 必須完整、同步、歸檔沉澱 —— 同代碼重疊嘅部分冇沉澱價值，維護成本遠大過收益 5. 工具強強聯合，流程越嚴格越好 —— 哲學唔自洽嘅嘢縫唔出自洽，模型喺變強流程應該變輕
帶住呢五條認知去揀工具，你一定揀到最重嗰個，然後效率不升反降。
❶ Spec 係 Truth？——Spec 連編譯器都冇
SDD 理論話：Spec 係真相源，代碼係 Spec 嘅投影。先改 Spec 再改代碼，活基線永遠保持最新。
但工程上有個致命問題：Spec 係一份冇編譯器嘅源代碼。 冇 type check，冇 pass/fail，冇 CI 強制執行。代碼同測試唔一致，CI 會紅；Spec 同代碼唔一致，冇人報錯——直到有人摷返 spec.md 話「當初唔係咁定嘅」。
可以當 Truth 嘅嘢一定要有裁判機制。測試有 runtime 做裁判，代碼有編譯器做裁判。Spec 嘅裁判係邊個？係人讀一次然後話「好似啱」。
呢個唔係 Truth，呢個係 opinion。
❷ No Spec, No Code？——瀑布思維嘅復闢
SDD 嘅紀律要求：代碼一定要由 Spec 驅動生成，冇 Spec 就唔寫代碼。
但「先寫完整 Spec → 再生成代碼」= 喺不確定性最高嘅時候做最完整嘅承諾。呢個就係 waterfall 換咗個馬甲。
流向反咗。 「人寫 Spec → AI 執行」將最貴嘅人力放喺信息密度最低嘅環節——由零起草。正確流向係 AI 出方案 → 人審關鍵決策 → AI 執行。「人寫 Spec」係 2024 年模型弱陣時嘅產物，2026 年仲堅持由零手寫，係用最貴嘅資源做最便宜嘅事。
大部分需求唔需要預先 Spec。 50% 嘅需求被過度 Spec。改配置項行完整流程 40 分鐘，直接改 5 分鐘。分級比紀律重要——硬要 No Spec No Code，係用流程感代替判斷力。
❸ Spec 越精確效果越好？——你喺模型最強嘅地方加鎖
直覺上，Spec 越詳細、約束越多，AI 產出越可控。實際相反。精確度同代碼質量係倒 U 曲線——過咗拐點，每多寫一行 Spec，產出質量反而下降。
代碼質量
▲
│ ╭──╮
│ ╭╯ ╰╮
│ ╭╯ ╰╮
│ ╭╯ 最優區 ╰──── 過度約束區
│╭╯
├╯
│ 信息不足區
└──────────────────────► Spec 精確度
邊界/不變量/AC 技術選型/實現路徑/代碼結構
（該鎖的） （不該鎖的）應該鎖嘅（What 層）： 邊界（唔做咩）、不變量（扣費後唔退款）、驗收標準（餘額不足返回 40003）。
唔應該鎖嘅（How 層）： 技術選型、實現路徑、代碼結構、數據結構設計。
How 層係模型最強嘅決策空間。你插一條樁，模型會忠實執行一個次優方案，而且唔會話畀你聽有更好嘅選擇。
Spec 寫死 Redis SET NX, TTL 5s，AI 照做。只寫「同一用戶同一房間嘅請求必須串行」，模型會根據架構上下文自選方案——大概率比你指定嘅更合理。
鎖行為，唔鎖實現。More context, less control——畀信息，唔畀指令。 你越信任模型嘅決策能力，產出上限越高；你越用約束替代信任，產出越被壓喺你自己嘅認知天花板上面。
造模型嘅人最清楚呢一點。Anthropic 揀咗 CLAUDE.md + Plan Mode，OpenAI 揀咗 AGENTS.md + delegation。兩間頂尖模型公司，都押注咗「輕」。 如果模型需要重型 Spec 先至寫得好代碼，佢哋會第一個做。佢哋冇做。
❹ Spec 必須完整、同步、歸檔沉澱？——維護成本遠大過價值
好多團隊將 Spec 當長期資產經營：寫完之後同代碼保持同步，歸檔之後作為知識沉澱同審計憑據。
計一條數就知唔划算。Spec 同代碼重疊嘅部分冇沉澱價值——代碼本身就係最好嘅文檔。代碼以外嘅知識有價值，但應該提取到知識庫，唔係維護喺 Spec 文檔裏面。
重疊部分——唔需要沉澱。 代碼可執行、可測試、100% 精確；Spec 係自然語言近似描述。一致就冗餘，唔一致就危險。保留精確嗰份就夠。
代碼外知識——提取到知識庫。 業務規則、決策原因、領域邊界有長期價值，但正確歸宿係 CLAUDE.md 同知識庫——系統級知識，放喺 Spec 裏面下個需求嘅 AI 睇唔到；放喺知識庫裏面所有後續開發都受惠。
同步維護——成本 3-4 倍，換嚟一份冇人睇嘅文檔。 兩個用唔同語言描述同一事物嘅產物，冇編譯器強制一致性，漂移唔係例外——係必然。
❺ 工具強強聯合，流程越嚴格效果越好？——退潮沙灘上嘅城堡
社區常見思路：OpenSpec 管 What，Superpowers 管 How，Kiro 管形式化——三個疊埋就全覆蓋。哲學唔自洽嘅嘢縫唔出自洽。
世界觀衝突。 OpenSpec 信 Spec 係 truth，Superpowers 信測試係 truth。Spec 同測試衝突時聽邊個？冇融合方案回答過呢個問題——佢哋只係用自動化跳過咗呢個判斷。跳過唔等於解決。
方向反咗。 模型喺變強，流程應該變輕。每一次融合都喺加重——多一層同步、多一筆 token 税、多一套膠水。呢啲協調機制喺模型下一次能力跳躍之後就係要拆嘅負債。你喺加固一座建喺退潮沙灘上嘅城堡。
1 + 1 < 1。 社區為融合方案構建咗 15+ 字段狀態機同 SHA256 追蹤——融合嘅協調成本高到需要再造一個工具嚟管理。你可以清楚講出融合後失去咗啲咩嗎？講唔出——你唔係喺集成，係喺堆疊。
選型：五個工具，五種賭注
帶住呢五條認知睇工具。先上結論：
| Plan Mode | 夠用就係最優解，大部分人都唔信 | |
| Superpowers | 用 token 換紀律，220K+ Star 嘅工程信仰 | |
| OpenSpec | 理想好豐滿，工程好骨感 | |
| Kiro | 體驗最絲滑，代價係將 IDE 交畀 Amazon | |
| GStack | YC 掌門人嘅個人武器，唔係團隊方案 | |
| 縫合怪 | 退潮沙灘上嘅城堡，一律唔掂 |
下面拆開嚟睇。
Plan Mode — 夠用就係最優解
設計哲學： Spec 係實時嘅、一次性嘅、AI 生成嘅。Claude Code Shift+Tab、Cursor Cmd+Shift+P、Copilot 等價操作——AI 分析代碼庫出計劃，你審批之後先鬱代碼，用完即棄。幾乎所有主流 AI 編輯器已經內置。
短板： session 斷就冇、不可審計、多人無法對齊。
判斷： SDD 嘅最小構件係「人審意圖」呢一個控制點——Plan Mode 啱好做咗呢件事，亦只係做咗呢件事。唔多唔少。80% 日常迭代，到呢度就應該停。
Superpowers — 用 token 換紀律
設計哲學： 紀律即產品。七階段流水線（Brainstorm → Worktree → Plan → TDD → Subagent → Review → Finalize），核心鐵律係「冇失敗測試就冇代碼」——寫咗代碼冇寫測試？Superpowers 直接刪咗你嘅代碼，由測試重新嚟過。GitHub 220K+ Star，已經入咗 Anthropic 官方插件市場，支持 Claude Code、Cursor、Gemini CLI 等 8 個平台。
真正嘅創新唔係喺 TDD 本身——在於測試食咗 Spec 文檔。 Brainstorm 階段逼你將 AC 諗清楚，直接翻譯成測試。測試就係可執行嘅 Spec：pass/fail 冇歧義，唔會腐化，唔需要同代碼同步。兩個產物坍縮成一個——「Spec 冇裁判」同「維護成本」呢兩個問題從根度消失。
短板： 嘥 token，簡單改動 overhead 明顯。七階段流水線對改配置呢啲嘢係殺雞用牛刀。
判斷： 你買嘅唔係速度，係質量下限。如果你嘅核心痛點唔係代碼質量——唔需要。
OpenSpec — 理想好豐滿，工程好骨感
設計哲學： Spec 係真相源，代碼係投影。Fission AI（YC W26）嘅核心概念係「活基線」——改動以 Delta 形式提案（ADDED / MODIFIED / REMOVED），實現後歸檔合入主 Spec，系統規格永遠最新。專為存量系統（1→n）設計。
理念本質上係為 IDD（意圖驅動開發）做預演——如果未來有咗業務語義編譯器，活基線就係佢嘅輸入。遠見值得尊重。
但 2026 年嘅工程現實：
• 自然語言冇裁判機制，「Spec 係 Truth」呢個核心假設唔成立 • 活基線維護成本隨需求線性增長，同步靠手工 • 更大嘅風險係時間差：模型變強嘅速度，可能比你嘅 Spec 基建成熟更快。 等活基線建完，模型可能已經唔需要佢喇
判斷： 適合受監管行業嘅審計需求、超大系統嘅規格漂移治理。大部分團隊唔喺呢兩個條件裏面。
Kiro — Amazon 嘅豪賭：Spec 即 IDE
設計哲學： 將 SDD 全流程焊入 IDE。2025.7 公測 → 2025.11 GA → 2026.5 全球，正式取代 Amazon Q Developer（IDE 插件版 2027.4 停服）。底層 Claude Sonnet + Nova（Bedrock），自然語言自動轉 EARS 句式（WHEN [條件] THE SYSTEM SHALL [行為]）——Rolls-Royce 嘅需求工程格式，天然可測試。
三種工作流：Requirements-First（從需求推設計）、Design-First（從架構推需求）、Quick Plan（跳過審批門直接出任務列表）。每個任務 spawn 獨立 Subagent 並行執行，Hooks 機制喺文件保存時觸發自動化。從需求到代碼嘅體驗確實最流暢——代價係 IDE 鎖定同 AWS 生態綁定。
短板： Code OSS 魔改版，你嘅編輯器、插件、快捷鍵全部要遷移。Spec 產物鎖喺 Kiro 項目結構裏面，離開 Kiro 就帶唔走。模型只能用 Bedrock 上面嘅，冇得換。
判斷： EARS 句式係真正有工程價值嘅創新——結構化需求天然可轉測試。但將成個工作流焊入一個 IDE，意味着你嘅開發流程同 Amazon 嘅產品路線圖綁定咗。
GStack — YC 掌門人嘅個人武器
設計哲學： 角色即約束。YC 掌門人 Garry Tan 開源，96K+ Star。23 個 slash command 覆蓋 CEO、產品經理、架構師、QA、安全官等角色——唔係模擬 23 個人，而係 23 個專項技能。Tan 本人聲稱用呢個方案周均 10K 行代碼、100 個 PR。
GStack 解決嘅唔係 SDD 問題，係「一個人點樣做一個團隊」嘅問題。 佢唔關心 Spec 係唔係 Truth——佢關心嘅係一個人可唔可以同時扮演 CEO 同 QA，而且唔精神分裂。
短板： Prompt 驅動，冇持久化嘅 Spec 或測試約束——本質上係結構化嘅 Vibe Coding。角色模擬嘅質量完全取決於底層模型，換個弱啲嘅模型，23 人團隊就變成 23 個實習生。
判斷： 如果你係獨立開發者或一人公司，GStack 提供嘅角色切換腳手架確實有價值。但佢對團隊協作幾乎冇用——團隊唔需要一個人模擬 23 個角色，團隊本身就係角色。
縫合怪 — 退潮沙灘上嘅城堡
唔只係 OpenSpec + Superpowers，社區裏面各種縫合方案都有同一個病：每個工具有自己嘅真相源，縫埋一齊時冇人回答「衝突聽邊個嘅」。 Spec 派信文檔，TDD 派信測試，IDE 派信內置流程——三套世界觀靠膠水黐埋一齊，協調成本高到需要再造一個工具嚟管理融合本身。模型每變強一次，呢啲膠水就多一層要拆嘅負債。一律唔掂。
決策路徑
正確路徑係漸進式加層，唔係並聯縫合：
每次只加一層。每層解決一個你當前真正痛嘅問題。
三條選型原則
1. 可執行嘅 > 要人讀嘅。 測試可執行，Spec 要人讀。呢一條淘汰大部分重型方案。 2. 輕嘅 > 重嘅。 今日加嘅每一層流程，模型下次能力跳躍之後仲有冇存在價值？ 3. 一個 > 多個。 兩個工具之間嘅膠水，就係你唔應該畀嘅成本。
例外： 金融合規、醫療審計、多團隊大型系統——呢啲場景嘅審計追溯需求係真實嘅，Spec 持久化唔係形式主義而係法律要求。如果你喺呢類行業，由 OpenSpec 或 Kiro 開始，唔好由 Plan Mode 開始。上面嘅原則適用於絕大多數產品團隊。
我哋嘅選擇
揭底牌：Plan Mode 打底 + Superpowers 包底關鍵模塊，Plan 產物持久化到文檔。
輕量需求（前端頁面、配置變更、CRUD）行 Plan Mode——AI 出方案，人審批准後執行。分別係我哋將計劃持久化到文檔，唔依賴 session 存活。前端 TDD 收益有限（UI 狀態多、視覺迴歸靠 snapshot 唔靠單元測試），審批門夠用。
後端複雜需求（資金鍊路、權限模型、核心業務規則）加 Superpowers——唔係為咗流程，係為咗質量下限。呢啲模塊出 bug 嘅代價係生產事故，測試鎖住驗收標準比任何文檔都可靠。
冇用 OpenSpec——團隊唔需要審計追溯，維護活基線嘅成本我唔願意畀。冇用 Kiro——唔想被 IDE 綁定。GStack 我喺個人項目裏面間唔中用嚟做產品思考，唔算正式工具鏈。
一個趨勢： 模型每強一代，基礎嘅測試編寫能力會逐步內化——簡單場景唔再需要外部工具強制「先寫測試」。但呢個唔代表 Superpowers 會過時。啱啱相反，模型越強，Superpowers 嘅價值越往上層遷移：從基礎 TDD 紀律，到 Brainstorm 嘅對抗性需求澄清、Worktree 嘅隔離保障、Review 嘅多階段門禁。模型內化嘅係能力，工具守住嘅係紀律——兩件事。
呢個唔係標準答案——係「模型足夠強、團隊 10 人以內、ToB 產品」上下文下嘅選擇。你嘅上下文唔同，答案可能完全唔同。
未來：Spec 會變成 AI 嘅中間表示
三個判斷收束：
❶ 真正值得投資嘅唔係 Spec 工具，係 Context + Eval。 知識庫讓 AI 知道你嘅系統一直相信啲咩，測試唔畀考生改自己試卷。Spec 工具喺中間——呢一層正在變薄。
❷ Spec 會變成 AI 嘅中間表示。 好似彙編語言：重要，但人唔直接寫。SDD 贏咗 2025-2027 嘅戰役，但「人寫 Spec」唔係終局。
❸ 揀最輕嘅工具 = 賭模型變強，揀最重嘅 = 賭模型停滯。 你賭邊邊？
五條你中咗幾條？你哋團隊用咩工具組合？或者——你見過真正跑得通嘅融合方案嗎？Spec 同測試衝突時，聽邊個？評論區見。
半年踩完坑，我發現 SDD 圈子裏有五條「常識」，全是錯的：
1. Spec 是 Truth —— Spec 連編譯器都沒有，憑什麼叫 Truth？ 2. No Spec, No Code —— 這是瀑布思維的復辟，人寫 Spec 是上一代的做法 3. Spec 越精確效果越好 —— 精確度和代碼質量是倒 U 曲線，過了拐點是負收益 4. Spec 必須完整、同步、歸檔沉澱 —— 和代碼重疊的部分沒有沉澱價值，維護成本遠大於收益 5. 工具強強聯合，流程越嚴格越好 —— 哲學不自洽的東西縫不出自洽，模型在變強流程應該變輕
帶着這五條認知去選工具，你一定選到最重的那個，然後效率不升反降。
❶ Spec 是 Truth？——Spec 連編譯器都沒有
SDD 理論說：Spec 是真相源，代碼是 Spec 的投影。先改 Spec 再改代碼，活基線永遠保持最新。
但工程上有個致命問題：Spec 是一份沒有編譯器的源代碼。 沒有 type check，沒有 pass/fail，沒有 CI 強制執行。代碼和測試不一致，CI 會紅；Spec 和代碼不一致，沒人報錯——直到有人翻出 spec.md 說「當初不是這麼定的」。
能當 Truth 的東西必須有裁判機制。測試有 runtime 當裁判，代碼有編譯器當裁判。Spec 的裁判是誰？是人讀一遍然後說「好像對」。
這不是 Truth，這是 opinion。
❷ No Spec, No Code？——瀑布思維的復辟
SDD 的紀律要求：代碼必須由 Spec 驅動生成，沒有 Spec 就不寫代碼。
但「先寫完整 Spec → 再生成代碼」= 在不確定性最高的時候做最完整的承諾。這就是 waterfall 換了個馬甲。
流向反了。 「人寫 Spec → AI 執行」把最貴的人力放在信息密度最低的環節——從零起草。正確流向是 AI 出方案 → 人審關鍵決策 → AI 執行。「人寫 Spec」是 2024 年模型弱時的產物，2026 年還堅持從零手寫，是用最貴的資源做最便宜的事。
大部分需求不需要預先 Spec。 50% 的需求被過度 Spec。改配置項走完整流程 40 分鐘，直接改 5 分鐘。分級比紀律重要——硬要 No Spec No Code，是用流程感代替判斷力。
❸ Spec 越精確效果越好？——你在模型最強的地方加鎖
直覺上，Spec 越詳細、約束越多，AI 產出越可控。實際相反。精確度和代碼質量是倒 U 曲線——過了拐點，每多寫一行 Spec，產出質量反而下降。
代碼質量
▲
│ ╭──╮
│ ╭╯ ╰╮
│ ╭╯ ╰╮
│ ╭╯ 最優區 ╰──── 過度約束區
│╭╯
├╯
│ 信息不足區
└──────────────────────► Spec 精確度
邊界/不變量/AC 技術選型/實現路徑/代碼結構
（該鎖的） （不該鎖的）該鎖的（What 層）： 邊界（不做什麼）、不變量（扣費後不退款）、驗收標準（餘額不足返回 40003）。
不該鎖的（How 層）： 技術選型、實現路徑、代碼結構、數據結構設計。
How 層是模型最強的決策空間。你插一根樁子，模型會忠實執行一個次優方案，而且不會告訴你有更好的選擇。
Spec 寫死 Redis SET NX, TTL 5s，AI 照做。只寫「同一用戶同一房間的請求必須串行」，模型會根據架構上下文自選方案——大概率比你指定的更合理。
鎖行為，不鎖實現。More context, less control——給信息，不給指令。 你越信任模型的決策能力，產出上限越高；你越用約束替代信任，產出越被壓在你自己的認知天花板上。
造模型的人最清楚這一點。Anthropic 選了 CLAUDE.md + Plan Mode，OpenAI 選了 AGENTS.md + delegation。兩家頂尖模型公司，都投了「輕」。 如果模型需要重型 Spec 才能寫好代碼，他們會第一個做。他們沒做。
❹ Spec 必須完整、同步、歸檔沉澱？——維護成本遠大於價值
很多團隊把 Spec 當長期資產經營：寫完後和代碼保持同步，歸檔後作為知識沉澱和審計憑據。
算一筆賬就知道不划算。Spec 和代碼重疊的部分沒有沉澱價值——代碼本身就是最好的文檔。代碼外的知識有價值，但應該提取到知識庫，不是維護在 Spec 文檔裏。
重疊部分——無需沉澱。 代碼可執行、可測試、100% 精確；Spec 是自然語言近似描述。一致則冗餘，不一致則危險。保留精確的那份就夠了。
代碼外知識——提取到知識庫。 業務規則、決策原因、領域邊界有長期價值，但正確歸宿是 CLAUDE.md 和知識庫——系統級知識，放在 Spec 裏下個需求的 AI 看不到；放在知識庫裏所有後續開發都受益。
同步維護——成本 3-4 倍，換來一份沒人看的文檔。 兩個用不同語言描述同一事物的產物，沒有編譯器強制一致性，漂移不是例外——是必然。
❺ 工具強強聯合，流程越嚴格效果越好？——退潮沙灘上的城堡
社區常見思路：OpenSpec 管 What，Superpowers 管 How，Kiro 管形式化——三個疊起來全覆蓋。哲學不自洽的東西縫不出自洽。
世界觀衝突。 OpenSpec 信 Spec 是 truth，Superpowers 信測試是 truth。Spec 和測試衝突時聽誰的？沒有融合方案回答過這個問題——它們只是用自動化跳過了這個判斷。跳過不等於解決。
方向反了。 模型在變強，流程應該變輕。每一次融合都在加重——多一層同步、多一筆 token 税、多一套膠水。這些協調機制在模型下一次能力跳躍後就是要拆掉的負債。你在加固一座建在退潮沙灘上的城堡。
1 + 1 < 1。 社區為融合方案構建了 15+ 字段狀態機和 SHA256 追蹤——融合的協調成本高到需要再造一個工具來管理。你能清楚說出融合後失去了什麼嗎？說不出——你不是在集成，是在堆疊。
選型：五個工具，五種賭注
帶着這五條認知看工具。先上結論：
| Plan Mode | 夠用就是最優解，大部分人不信 | |
| Superpowers | 用 token 換紀律，220K+ Star 的工程信仰 | |
| OpenSpec | 理想很豐滿，工程很骨感 | |
| Kiro | 體驗最絲滑，代價是把 IDE 交給 Amazon | |
| GStack | YC 掌門人的個人武器，不是團隊方案 | |
| 縫合怪 | 退潮沙灘上的城堡，一律不碰 |
下面拆開看。
Plan Mode — 夠用就是最優解
設計哲學： Spec 是實時的、一次性的、AI 生成的。Claude Code Shift+Tab、Cursor Cmd+Shift+P、Copilot 等價操作——AI 分析代碼庫出計劃，你審批後才動代碼，用完即棄。幾乎所有主流 AI 編輯器已內置。
短板： session 斷就沒、不可審計、多人無法對齊。
判斷： SDD 的最小構件是「人審意圖」這一個控制點——Plan Mode 恰好做了這件事，也只做了這件事。不多不少。80% 日常迭代，到這裏就該停了。
Superpowers — 用 token 換紀律
設計哲學： 紀律即產品。七階段流水線（Brainstorm → Worktree → Plan → TDD → Subagent → Review → Finalize），核心鐵律是「沒有失敗測試就沒有代碼」——寫了代碼沒寫測試？Superpowers 直接刪掉你的代碼，從測試重來。GitHub 220K+ Star，已進入 Anthropic 官方插件市場，支持 Claude Code、Cursor、Gemini CLI 等 8 個平台。
真正的創新不在 TDD 本身——在於測試吃掉了 Spec 文檔。 Brainstorm 階段逼你把 AC 想清楚，直接翻譯成測試。測試就是可執行的 Spec：pass/fail 無歧義，不腐化，不需要和代碼同步。兩個產物坍縮成一個——「Spec 沒有裁判」和「維護成本」這兩個問題從根上消失。
短板： 費 token，簡單改動 overhead 明顯。七階段流水線對改配置這種事是殺雞用牛刀。
判斷： 你買的不是速度，是質量下限。如果你的核心痛點不是代碼質量——不需要。
OpenSpec — 理想很豐滿，工程很骨感
設計哲學： Spec 是真相源，代碼是投影。Fission AI（YC W26）的核心概念是「活基線」——改動以 Delta 形式提案（ADDED / MODIFIED / REMOVED），實現後歸檔合入主 Spec，系統規格永遠最新。專為存量系統（1→n）設計。
理念本質上在為 IDD（意圖驅動開發）做預演——如果未來有了業務語義編譯器，活基線就是它的輸入。遠見值得尊重。
但 2026 年的工程現實：
• 自然語言沒有裁判機制，「Spec 是 Truth」這個核心假設不成立 • 活基線維護成本隨需求線性增長，同步靠手工 • 更大的風險是時間差：模型變強的速度，可能比你的 Spec 基建成熟更快。 等活基線建完，模型可能已經不需要它了
判斷： 適合受監管行業的審計需求、超大系統的規格漂移治理。大部分團隊不在這兩個條件裏。
Kiro — Amazon 的豪賭：Spec 即 IDE
設計哲學： 把 SDD 全流程焊進 IDE。2025.7 公測 → 2025.11 GA → 2026.5 全球，正式替代 Amazon Q Developer（IDE 插件版 2027.4 停服）。底層 Claude Sonnet + Nova（Bedrock），自然語言自動轉 EARS 句式（WHEN [條件] THE SYSTEM SHALL [行為]）——Rolls-Royce 的需求工程格式，天然可測試。
三種工作流：Requirements-First（從需求推設計）、Design-First（從架構推需求）、Quick Plan（跳過審批門直出任務列表）。每個任務 spawn 獨立 Subagent 並行執行，Hooks 機制在文件保存時觸發自動化。從需求到代碼的體驗確實最流暢——代價是 IDE 鎖定和 AWS 生態綁定。
短板： Code OSS 魔改版，你的編輯器、插件、快捷鍵全要遷移。Spec 產物鎖在 Kiro 項目結構裏，離開 Kiro 就帶不走。模型只能用 Bedrock 上的，不能換。
判斷： EARS 句式是真正有工程價值的創新——結構化需求天然可轉測試。但把整個工作流焊進一個 IDE，意味着你的開發流程和 Amazon 的產品路線圖綁定了。
GStack — YC 掌門人的個人武器
設計哲學： 角色即約束。YC 掌門人 Garry Tan 開源，96K+ Star。23 個 slash command 覆蓋 CEO、產品經理、架構師、QA、安全官等角色——不是模擬 23 個人，而是 23 個專項技能。Tan 本人聲稱用此方案周均 10K 行代碼、100 個 PR。
GStack 解決的不是 SDD 問題，是「一個人怎麼當一個團隊」的問題。 它不關心 Spec 是不是 Truth——它關心的是一個人能不能同時扮演 CEO 和 QA，且不精神分裂。
短板： Prompt 驅動，沒有持久化的 Spec 或測試約束——本質上是結構化的 Vibe Coding。角色模擬的質量完全取決於底層模型，換個弱一點的模型，23 人團隊就變成 23 個實習生。
判斷： 如果你是獨立開發者或一人公司，GStack 提供的角色切換腳手架確實有價值。但它對團隊協作幾乎沒用——團隊不需要一個人模擬 23 個角色，團隊本身就是角色。
縫合怪 — 退潮沙灘上的城堡
不只是 OpenSpec + Superpowers，社區裏各種縫合方案都有同一個病：每個工具有自己的真相源，縫到一起時沒人回答「衝突聽誰的」。 Spec 派信文檔，TDD 派信測試，IDE 派信內置流程——三套世界觀靠膠水粘在一起，協調成本高到需要再造一個工具來管理融合本身。模型每變強一次，這些膠水就多一層要拆的負債。一律不碰。
決策路徑
正確路徑是漸進式加層，不是並聯縫合：
每次只加一層。每層解決一個你當前真正痛的問題。
三條選型原則
1. 可執行的 > 要人讀的。 測試可執行，Spec 要人讀。這一條淘汰大部分重型方案。 2. 輕的 > 重的。 今天加的每一層流程，模型下次能力跳躍後還有存在價值嗎？ 3. 一個 > 多個。 兩個工具之間的膠水，就是你不該付的成本。
例外： 金融合規、醫療審計、多團隊大型系統——這些場景的審計追溯需求是真實的，Spec 持久化不是形式主義而是法律要求。如果你在這類行業，從 OpenSpec 或 Kiro 起步，不要從 Plan Mode 起步。上面的原則適用於絕大多數產品團隊。
我們的選擇
亮底牌：Plan Mode 打底 + Superpowers 兜關鍵模塊，Plan 產物持久化到文檔。
輕量需求（前端頁面、配置變更、CRUD）走 Plan Mode——AI 出方案，人審批准後執行。區別是我們把計劃持久化到文檔，不依賴 session 存活。前端 TDD 收益有限（UI 狀態多、視覺迴歸靠 snapshot 不靠單元測試），審批門夠用。
後端複雜需求（資金鍊路、權限模型、核心業務規則）加 Superpowers——不是為了流程，是為了質量下限。這些模塊出 bug 的代價是生產事故，測試鎖住驗收標準比任何文檔都可靠。
沒有用 OpenSpec——團隊不需要審計追溯，維護活基線的成本我不願意付。沒有用 Kiro——不想被 IDE 綁定。GStack 我在個人項目裏偶爾用來做產品思考，不算正式工具鏈。
一個趨勢： 模型每強一代，基礎的測試編寫能力會逐步內化——簡單場景不再需要外部工具強制「先寫測試」。但這不代表 Superpowers 會過時。恰恰相反，模型越強，Superpowers 的價值越往上層遷移：從基礎 TDD 紀律，到 Brainstorm 的對抗性需求澄清、Worktree 的隔離保障、Review 的多階段門禁。模型內化的是能力，工具守住的是紀律——兩件事。
這不是標準答案——是「模型足夠強、團隊 10 人以內、ToB 產品」上下文下的選擇。你的上下文不同，答案可能完全不同。
未來：Spec 會變成 AI 的中間表示
三個判斷收束：
❶ 真正值得投資的不是 Spec 工具，是 Context + Eval。 知識庫讓 AI 知道你的系統一直相信什麼，測試不讓考生批改自己試卷。Spec 工具在中間——這一層正在變薄。
❷ Spec 會變成 AI 的中間表示。 像彙編語言：重要，但人不直接寫。SDD 贏了 2025-2027 的戰役，但「人寫 Spec」不是終局。
❸ 選最輕的工具 = 賭模型變強，選最重的 = 賭模型停滯。 你賭哪邊？
五條你中了幾條？你們團隊用的什麼工具組合？或者——你見過真正跑通的融合方案嗎？Spec 和測試衝突時，聽誰的？評論區見。