## 摘要 3/22 到 5/4，我試了四種開發流：純 OpenSpec → 加 brainstorming → 魔改 OpenSpec → superpowers 全家桶。 最後的結論顛覆我自己：**規格文件其實是搞笑的，CodeBase 才是真實**。 如果你也在做 SDD、也在猶豫要不要花時間維護一堆 spec，這篇可能會省你幾週。 --- ## 為什麼要寫這篇 我從 3 月開始用 SDD（Spec-Driven Development）做開發，中間踩了不少坑，每個階段都覺得「這次找到正解了」，下一週又被自己打臉。 寫這篇不是要推銷某個工具，而是想分享一件事： > 所有一切自己的假設，必須先當作是錯的，用實戰去驗證他是對的。 這句話聽起來像幹話，但它是我這 6 週最大的收穫。下面四個階段，就是我被現實打臉四次的過程。 --- ## 第一階段：純 OpenSpec（3 月） **工具流程**：`/opsx:new` → `/opsx:ff` → `/opsx:apply` → `/opsx:archive` 我自己也在優化 OpenSpec 的用法，例如規定： - 一個 change 只做一個功能 - 整份 task 不能太多（≤ 15） 跑了 10 個工作天，封存了一堆需求，看起來很有產出。 ### 然後我問了自己一個問題 **這些 spec，到底是寫給誰看的？** | 對象 | 會讀嗎？ | |------|---------| | 人類同事 | 不會 | | 我自己 | 不會 | | AI（同範圍 Issue / Fix 時） | 會，且會補充 | 只有 AI 會看。那為了 AI 維護這麼多 spec 值得嗎？ **結論**：不值得。修一個小 issue 還要先 reading 再調整，反而麻煩。而且這些 spec 加起來也拼不出一份完整的使用手冊，純粹是給 AI 當零散的記憶體用。 ### 更痛的點：計畫永遠對不上現實 我起草時已經很努力了——先寫草稿、再寫 Design、再寫 Task，把所有現實限制都餵給 AI。 結果呢？**我完成的功能跟「計畫」一字不差，但「計畫」本身和 PM 心中的需求有偏移。** 於是我得到的不是「做錯了」，而是更阿雜的「做對了，但對的不是 PM 要的」。Shit。 --- ## 第二階段：加入 brainstorming（4 月初） 為了打擊「計畫對不上現實」這個痛點，我把 SuperPowers 的 `brainstorming` skill 接到流程最前面。 **體感差異**：超大。 用 brainstorming 跑出來的草稿，完整度比我自己用 OpenSpec 寫的好太多。如果第一階段我已經覺得很讚，那這階段只能說是讚爆。 ### 為什麼 brainstorming 這麼有用？ 這個 skill 我有去把它整份讀完，建議你也讀，真的有意思。我這邊只挑幾個關鍵點： **它做的事，本質上是「擋掉你想直接動手的衝動」。** 在「呈現設計 + 使用者批准」之前，skill 強制禁止寫任何 code、scaffold、或呼叫任何 implementation skill。連改 config、加一個 utility function 都要走完整流程。 你心裡想「這太簡單了不需要設計吧」——skill 直接點名這就是 anti-pattern： > 簡單的專案，正是「未經檢驗的假設」造成最多浪費的地方。 **它強迫你做這幾件事**： 1. 一次只問一題（多選題優先） 2. 一定要提 2-3 個方案 + 推薦哪個 + 為什麼 3. 設計分節呈現，每節等使用者點頭才繼續 4. 寫完設計文件還要自審四項：placeholder / 一致性 / scope / ambiguity 5. 最後唯一能呼叫的下一個 skill 是 `writing-plans`，不能跳格 這套流程的精髓：**設計階段把選擇權還給人**。AI 不是丟一個方案讓你接受，是給你 2-3 個讓你導向。 ### 但問題還沒完全解決 brainstorming 解了「設計品質」的問題，可是 OpenSpec 那套 spec 維護的負擔還在。所以我又往下踩了一階。 --- ## 第三階段：魔改 OpenSpec（4/7） 我當時想：保留 OpenSpec 的結構，但塞進 SuperPowers 的紀律，會不會兩全？ 於是我改了 `OpenSpec.yaml`，要求 AI 起草時必須先用 brainstorming、必須照 brainstorming 的方式問問題、必須提案。 **結果**：他有時候會跳過。 我問 AI 為什麼跳過，他給我一句很經典的話： > 我不一定會遵守 yaml，但我一定會遵守 skills。 OK 我懂了。要魔改的不是 yaml，是把 OpenSpec 的四個基礎技能直接改成 SuperPowers 的形狀。 但我還沒動手，就跳到第四階段了——因為我發現根本不用魔改。 --- ## 第四階段：superpowers 全家桶（4/7 起） 我決定全程跑一次 superpowers，純粹是想搞懂他在做什麼。 跑完以後我整個人傻住，God 這到底是什麼玩意？ ### 三個 skill 串起來就是一條完整流水線 | Skill | 做什麼 | |-------|--------| | `superpowers:brainstorming` | 完整的設計思路 | | `superpowers:writing-plans` | 直接讀 CodeBase 設計 Task | | `superpowers:execute-plan` | 全程 SubAgent 開發，可開分支 + 獨立 worktree | 跑完一輪，我前面三階段在搞什麼鬼，自己都覺得好笑。 ### 真正讓我頓悟的是這件事 writing-plans 是直接讀 **CodeBase** 來設計 task 的。 那一刻我突然想通： > **規格文件其實是搞笑的。** 為什麼這樣說？ - Spec 文件可能有誤、可能過時、可能跟現實不同步 - CodeBase 永遠是最新的、它就是現實本身 - 既然 AI 可以直接讀 CodeBase，為什麼要透過一份「可能寫錯的 spec」轉譯一次？ 過去我一直把 spec 當「真理」，CodeBase 當「實作」。但其實反過來才對——**CodeBase 才是真理，spec 只是一份可能會 drift 的影子**。 ### 還有一個我沒預期到的紅利：可以直接拿去對 PM 這件事我一開始沒想到。 brainstorming 跑出來的設計，品質高到我可以**直接拿去跟 PM 對齊規格**——不是工程師之間的技術文件那種「對齊」，是 PM 看得懂、能討論、能挑剔的那種對齊。 更扯的是，因為 brainstorming 強迫你提 2-3 個方案 + trade-offs，過程中常常會挖出**連 PM 自己都沒想到、我也沒想到的邊界條件和限制**。等於是 AI 幫我們兩個人一起做需求釐清。 而且，順著 superpowers 的設計脈絡，可以**直接產 HTML demo 給 PM 看畫面**。PM 不用再看抽象的 spec 想像最終長怎樣，可以直接點、直接戳、直接抓問題。 回頭看第一階段那個讓我阿雜的痛點——「我做對了，但對的不是 PM 要的」——這套流程從根本解掉了，因為 PM 在 spec 階段就已經點過頭了，而且是看著 demo 點的。 ### 一個我自己也在懷疑的觀察：產能真的提升了嗎？ 用全家桶之後，我開始習慣**一次 hang 很多任務在跑**。 具體來說，可能在同一個半天裡： - 跟前端對接好幾個任務 - 同步把這些任務的後台部分完成 - 順便出 API - 再修一批 issue 而且我並不覺得很耗時，反而有「咦怎麼又做完了」的錯覺。 更扯的工作流是這樣：**遇到複雜任務，我會花 2-3 小時把 spec + plan 寫好，然後下班前一鍵送出，讓它照著 plan 執行**。 隔天早上來上班，東西就在那裡等我 review。 這算產能大幅提升嗎？我自己也說不準。但我可以確定的是——**當你不用親自打字寫每一行 code、不用自己盯著編譯、不用手動切 context、甚至連執行時間都能排到你睡覺的時候**，你的「同時在進行」上限會被放大很多倍。 我也在問自己：這樣會不會不好？ 目前我的觀察是：只要你還在審 plan、還在 review PR、還在驗收結果，那就是把自己從「打字員」升級成「決策者」，這件事應該是好的。但如果連 review 都跳過——那就是另一個故事了。 ### 時間成本？根本不是問題 - writing-plans 跑 20-30 分鐘 → 那又怎樣？寫出來的東西夠正確 - execute-plan 跑 1 小時 → 那又怎樣？我自己開發更久 而且這 1 小時我不用盯著，可以拿來寫下一份需求、處理其他事情。 這是藝術。我一開始就知道這個工具，幹嘛不好好用？ --- ## 我學到什麼 回頭看這四個階段，每一階段我都覺得「找到正解了」，下一階段又被自己推翻。最後的體悟是： > **所有一切自己的假設，必須先當作是錯的，用實戰去驗證他是對的。而感受到這是正解的當下，就是此時此刻的正解。** 「此時此刻的正解」這幾個字很重要——我不敢說 superpowers 全家桶就是終點，可能下個月又有新東西讓我打臉自己。 但這就是 SDD（或廣義的 AI-augmented 開發）有趣的地方：你不是在找一套「永遠對的流程」，你是在不斷驗證自己的假設，然後接受現在最有效的那一套。 希望這篇能讓正在踩 SDD 坑的你少走一點冤枉路。 如果你也是 superpowers 的使用者，歡迎留言聊聊你的流程；如果你還在純 OpenSpec 階段——試試看 brainstorming，然後就會回不去了。