[AI] 用 grill-me 與 Codex 5.6 寫程式，還需要 Superpowers 嗎？
/ 9 min read
Updated:Table of Contents
有些需求看起來很簡單，例如「幫部落格加文章搜尋」
真正開始做時，你才會發現，要決定的根本不是程式，而是需求
要搜什麼？ 要怎麼排序？ 找不到怎麼辦？ 什麼才算完成？
模型負責判斷，Skill 負責把團隊或個人的習慣變成可以重複使用的流程
這篇想從這個角度，比較 grill-me、Superpowers，以及 GPT-5.6
grill-me跟 Superpowers 差在哪- 模型變強後，還要不要承擔 Skills 帶來的流程與 token 成本
先用 grill-me 把需求問清楚
grill-me 做的事很單純，它不是幫你生 code，而是強迫對話不要跳過決策
拿文章搜尋來說，第一輪可能先問讀者是誰、搜尋範圍是什麼、手機畫面怎麼用，你回答後，它再問排序、空狀態、是否需要支援中文斷詞
它一次只問一個問題，看起來很慢，但好處是你不會在回答「要不要支援 tag」時，又同時被迫決定索引架構與測試策略
最後得到的不是一套工程流程，而是一份比較像人話的需求
搜尋欄放在文章列表上方，先搜標題和 tag，輸入後即時篩選，這個站文章量不大，先不引入外部搜尋服務，沒有結果時顯示「找不到符合的文章」
這時再叫 Codex 實作，模型才有比較可靠的邊界可以工作
Matt Pocock 的 grilling 流程把這件事定義成逐一走訪決策分支，直到雙方有共同理解，它適合卡住的原因是「我其實還沒想清楚」，不是「我需要一整套開發制度」
如果不只要問清楚需求，還希望把專案用語、CONTEXT.md 和重要決策一起沉澱下來，Matt 現在的工具組裡有 grill-with-docs 與 domain-modeling
這不代表 domain-modeling 已經取代 grill-me
domain-modeling 適合「詞彙本身就是問題」的情況，例如同一個「會員」在不同地方其實代表帳號、付費者或組織，它會把釐清後的詞彙和難以回頭的決策記進 CONTEXT.md 與 ADR
Matt 目前的公開文件把 grill-me 列為非程式任務的入口，程式專案若要先把計畫問清楚，可用 grilling 或它的 grill-with-docs 包裝，若訪談過程還要連同領域知識一起留下，則用 grill-with-docs 比較完整
Superpowers 比一條流程更大
Superpowers 的範圍大得多
它不只問需求，還把許多工程團隊常用的 playbook 模組化，例如腦暴、實作計畫、subagents、systematic debugging、測試驅動開發、code review 和最後驗證
所以我會把它看成一套 AI Engineering Playbook，不只是「把流程拆細」
同樣是文章搜尋，流程可能會要求先確認資料來源和元件邊界，再寫計畫，先寫失敗的測試，完成後跑檢查，最後再做 review
這很適合下面這種工作
- 搜尋會影響既有路由、SEO 或資料索引
- 改動跨很多檔案，回歸風險高
- 團隊希望每次修改都有可檢查的設計和驗證紀錄
- 需求一開始還模糊，但又不能靠「先做再說」承擔風險
如果只是替文章卡片加一個 tag 篩選，完整流程可能比改動本身還重
這不是 Superpowers 的缺點，而是它本來就在處理另一種問題
兩者不是誰比較聰明
| 面向 | grill-me | Superpowers |
|---|---|---|
| 核心工作 | 把需求與取捨講清楚 | 把設計、實作與驗證串成流程 |
| 最適合的卡點 | 不知道真正要做什麼 | 知道目標，但工作複雜或風險高 |
| 產物 | 共同理解與下一步 | 設計稿、計畫、測試、review 與驗證紀錄 |
| 主要代價 | 多幾輪對話 | 多個關卡、工具輸出與檢查時間 |
這張表是依兩套公開流程做的整理，不是 benchmark
實務上可以先用 grill-me，需求釐清後，如果發現只是小改動，直接讓 Codex 做即可，如果牽涉架構、資料遷移、付款或權限，再把 Superpowers 加進來
GPT-5.6 變強，Skills 還有必要嗎？
有，但理由不是 GPT-5.6 不夠聰明
模型擅長根據上下文推理、比較方案和寫程式，Skill 的用途則是把一個可重複的做事方式保存下來，例如什麼時候要先問問題、什麼時候必須驗證、產出要長什麼樣子
換句話說，模型負責判斷，Skill 負責把團隊或個人的習慣變成可以重複使用的流程
Codex 的 Skills 採用漸進載入，模型一開始只看到名稱與描述，當任務符合時才載入完整的 SKILL.md，所以不是安裝越多 Skills，當下就一定花越多 token
真正的成本通常來自幾件事
- 被選中的完整指令內容
- 為了釐清需求而增加的對話回合
- 測試、搜尋、建置等工具輸出
- 多 agent 或高 reasoning 帶來的額外推理時間
OpenAI 也建議直接拿自己的代表性任務測試，不同模型和 reasoning 設定沒有固定答案
什麼時候不要用
先說結論，能用一句清楚的 prompt 完成，就不要硬塞一套儀式
| 工作 | 建議 |
|---|---|
| CSS 微調 | 直接 Codex |
| 一個範圍明確的 Component | 直接 Codex |
| 新 API，但需求還有取捨 | grill-with-docs |
| 新 Feature，還要釐清專案術語與決策 | grill-with-docs 或 domain-modeling |
| 大型重構 | Superpowers |
| Payment、Auth 或其他高風險改動 | Superpowers |
這張表不是硬規則，新 API 若只有一個明確 endpoint，直接 Codex 可能更快，大型重構若只是機械式改名，也不一定要套滿流程
我會怎麼選
把需求寫得很清楚，而且只是單一元件或小修正時，直接 prompt 給 Codex 就好
一句話需求背後其實有很多選擇時，先做 grilling，想要單純訪談時用 grill-me，程式專案又要留下術語與決策時用 grill-with-docs 或 domain-modeling
改動會跨多個模組、需要測試保護，或做錯代價很高時，再用 Superpowers
如果在意成本，不要只看單次 token，用同一個任務比較這四件事比較有意義
- 總 input 和 output tokens
- 完成前的互動回合數
- 工具與測試執行次數
- 最後有沒有因為漏需求而返工
Workflow 的價值會隨著專案規模和風險增加，不會隨著模型能力下降
GPT-5.6 越強，小功能越不需要流程，大型專案反而更需要流程，因為真正的瓶頸往往不是把程式寫出來，而是讓 AI 和團隊持續做出一致、可驗證的決策
對我來說，Skills 的價值不是把 prompt 寫得更長，而是把值得重複的工程做法，變成下一次還能直接拿來用的工具
參考
https://learn.chatgpt.com/docs/build-skills
https://learn.chatgpt.com/docs/models
https://developers.openai.com/api/docs/guides/latest-model
https://github.com/mattpocock/skills/blob/main/docs/productivity/grilling.md
https://github.com/mattpocock/skills/blob/main/docs/engineering/domain-modeling.md