系列文章: Superpowers (3/6)
using-superpowers 與 brainstorming：為什麼不能跳過設計直接開工
很多人用 AI 寫程式的起手式是：「幫我加一個功能。」聽起來沒問題，但代理如果立刻開始改檔，你很快就會進入經典劇情：改了三版才發現AI Agent第一版就理解錯。這篇要談兩個常常一起出現的角色：using-superpowers（怎麼正確啟用整套習慣）與 brainstorming（開工前先想清楚）。目標只有一個：先把設計與共識拿到，再讓AI Agent 開工。
using-superpowers 在管什麼
你可以把 using-superpowers 想成 教練：它不是在替你寫程式，而是在提醒代理（也順便提醒你自己）——Superpowers 這套東西要怎麼用才不算白裝。
實務上它常在做幾件事：先搞清楚現在對話裡有哪些可用的 skills、什麼情境該先讀哪一份、以及 在還沒動手寫實作之前，該把哪個流程 skill 叫出來。簡單說：它管的是「開場與路由」，避免你一上來就直奔實作，結果後面整條線都歪掉。
using-superpowers 和後面常接著的 brainstorming，也會一起把你拉回「先探索上下文」：先看專案裡已經有什麼檔案與慣例、團隊或環境有什麼不能踩的線、最近改動過哪裡——不是愛查勤，而是因為 腦中的需求若沒對上真實程式庫，第一版實作就很容易整段作廢；先花一小段時間掃過現場，通常比事後重寫便宜太多。
brainstorming 的核心流程
brainstorming 這類 skill，核心不是「聊天打發時間」，而是一條很務實的產線，大意如下（用概念講，不要求你背名詞）：
- 把意圖攤開：你到底想解決誰的什麼問題？成功長什麼樣子？
- 把限制講清楚：時間、技術棧、不能動的舊程式、上線風險——能講的先講。
- 列出可行方向：不只一條路，讓取捨變成「選擇題」而不是「通靈題」。
- 對齊再往前：你點頭（或你明確說要哪一條）之後，才進入更細的規劃或實作。
所以它不是「腦力激盪很熱鬧就好」，而是 把不確定變成可選方案，並且留下「我們到底選了哪一條」的共識。沒有這一步，實作很容易變成 各說各話的競速。
為什麼要先拿到設計同意
這裡的「設計同意」不用畫到很美，但要達到一個底線：你和代理對「要做什麼、不先做什麼、怎麼算做完」有一致說法。
如果跳過這段，常見後果包括：代理以為要重構，其實你只想補一個小按鈕；代理以為可以換套件，其實你的團隊規定不能動；代理以為「完成」是畫面有出來，其實你要的是通過測試與無障礙檢查。
先拿到同意，不是官僚，是 把昂貴的誤會移到便宜的字數階段解決。真的，這比半夜 diff 地獄療癒多了。
哪些任務該先 brainstorming
用新手也好記的判斷：只要你心裡有一個「其實我不太確定怎麼做最好」的時候，就先 brainstorming。 例如：
- 新功能：使用者流程、資料從哪來、邊界案例 都還在霧裡。
- 改舊程式：怕動到別人也在用的行為、或你不確定副作用在哪。
- 架構取捨：兩種以上做法，而且各有代價。
- 你說得出「我想要 X」但說不出「不要 Y」：範圍還在膨脹。
相反地，若你已經有清楚 ticket、清楚檔案、清楚 acceptance criteria，而且改動範圍真的小到不可能誤會——那才可能考慮縮短流程（但新手期我仍會建議：寧可多問兩句）。
常見誤區
- 把 brainstorming 當聊天：沒有選項、沒有取捨、沒有結論，最後還是「那你做吧」——這等於沒做。
- 心裡早就決定方案，卻假裝在討論：浪費步數，也浪費代理的算力；不如直接說「我選 A，請幫我檢查風險」。
- 跳過 using-superpowers 的節奏：一進對話就寫碼，等於自己把品質把關拆掉；不是一定爆炸，但 爆炸時通常很難救。
- 以為設計同意＝永遠不能改：後續發現新資訊本來就可以調整；重點是 調整時要說清楚變更，而不是默默改到面目全非。
下一步
回到系列總覽
這篇負責 using-superpowers 與 brainstorming 的角色與使用時機。若要回到系列的閱讀地圖與建議順序，請開 Superpowers 入門課。