Skill: Superpowers/brainstorming
前言 #
一開始我以為它只是讓 AI 更會腦力激盪，但讀完後發現，它其實更像是一套「把模糊想法整理成工程設計」的流程。它會要求 AI 先理解現有背景，再透過提問、比較方案、確認設計，把一個還不清楚的需求，慢慢收斂成可以實作的小區塊。
這個過程有點像身邊坐著一位資深工程師教練。他不會一聽到需求就衝去寫 code，而是先問你：「你真正想解決的是什麼？」「這個範圍會不會太大？」「有沒有其他做法？」「我們現在選這個方向的理由是什麼？」
對人類來說，回答這些問題的過程本身也很有價值。很多時候，我們不是不知道答案，而是還沒被問到那個會逼自己想清楚的問題。這樣來來回回地討論，很像以前一個人想破頭想不出來，結果找人聊個天就突然解開的那種窘境。
如果在釐清需求的過程中發現範圍太大，brainstorming skill 也不會硬做下去，而是會先討論怎麼拆成更小的部分。需求越小，看得越清楚，做起來也會更明確、更不容易出錯。這是亙古不變的道理。
等需求釐清後，它還是不會直接進入實作，而是先產出設計，分段和使用者確認，再把確認過的內容寫成設計文件。最後，還會要求對設計文件做 self review，檢查有沒有前後矛盾、範圍過大或語意不清的地方。
也就是說，這個 skill 真正做的不是「幫你想點子」，而是把點子整理到可以進入下一階段規劃的狀態。
幾個我覺得有趣的 Skill 設計 #
1. 不論問題多簡單，都需要設計 #
這點我覺得很重要，因為這是人類跟 AI 都常會犯的錯：以為事情很簡單，就覺得不用想了。
但越是這種「應該很簡單吧」的情況，越容易東漏西漏。因為我們會跳過釐清，直接把腦中模糊的假設當成共識。等到真的開始做，才發現有些邊界沒想清楚，有些需求其實彼此衝突。
brainstorming skill 很明確地要求，即使只是一個 Function 也要先走過設計流程。簡單的事情可以有簡單的設計，但不能完全沒有設計。
2. 工程化流程 #
這個 skill 很有趣的一點，是它把工程師處理不明確需求的方式寫成了流程。
先看現況，再釐清問題，接著拆 scope、比較方案、確認設計，最後產出文件。整個過程就是把一個不明確的東西，慢慢變成可以被討論、可以被實作、也可以被驗收的東西。
我覺得這也是 Superpowers 這類 skill 有意思的地方。它不是只教 AI「遇到問題要回答什麼」，而是試著把某種工作方法寫下來，讓 AI 依照這個方法去思考。
3. 一次問一個問題 #
我認為這很像在做決策。很多時候，我們其實是在決定要往左還是往右。如果已經決定往右，那左邊那條路的細節就不用再花時間看了。
一次問一個問題，可以避免討論一次打開太多分支，也比較容易讓人保持思路清楚。每回答一題，就把可能性縮小一點，疑惑也跟著收斂一點。
這個限制看起來很簡單，但其實很有效。因為一旦問題太多，人類很容易開始跳來跳去，AI 也會跟著發散。一次處理一個決策點，反而比較容易把事情往前推進。
4. 選擇題優先 #
選擇題優先也像是快速決策的一環，而且我覺得這對人類滿友善的。
如果 AI 直接丟一個開放式問題，人類常常還要先整理自己的想法，甚至不知道該從哪裡回答。但如果它先提供幾個選項，我們就可以很快判斷：「這個接近」、「那個不對」、「我想要的是 A 跟 C 的混合」。
透過選擇題，可以快速走過初步分歧，把時間留給真正值得討論的地方。這不是要限制人的想法，而是先給一個可以反應的基準。
5. 提供 2-3 組方案，給出建議並說明原因 #
很多時候我們會糾結在各種 trade-off。這時候如果 AI 只是把所有選項攤開，反而會讓人更難決定。
brainstorming skill 要求 AI 提供 2-3 組方案，說明取捨，然後給出推薦和原因。這點我覺得很實用，因為它不是只把選項列出來，而是把判斷也一起攤開。
如果你被說服了，多半就會選建議的方案；反之，如果你不能被說服，也會立刻提出質疑。這時候討論就會往更精準的方向前進，接著長出下一輪更貼近需求的方案。
內心 OS：這是不是某種程度的心理學？
6. 手術式的修改 #
這點其實最早是從 Andrej Karpathy 分享的 觀點 中了解到的，裡面也分享了 AI 開發常見問題與如何改善。
brainstorming skill 也有類似的概念：在既有 codebase 裡工作時，要先探索目前結構，並且盡量遵循現有模式。如果有值得重構的地方，而且會影響這次需求，可以把它納入設計。
但它也提醒不要去重構跟這次無關的地方。這點很重要，因為工程師很容易看著看著就手癢，最後 scope 無止境擴大。
我滿喜歡這種「手術式」的態度：可以改善，但改善要服務於這次需求，而不是趁機把整個世界重寫一遍。
7. 設計文件的位置可以調整 #
brainstorming skill 預設會把設計文件輸出到 docs/superpowers/specs/YYYY-MM-DD--design.md，但也允許使用者指定其他位置。這點我滿喜歡的。流程是固定的，但輸出形式可以配合團隊習慣，把成果接進既有工作流裡。
另外，它也 skill 內偷偷推薦他的另一個 skill elements-of-style:writing-clearly-and-concisely 來修飾文件，很好笑，找一天來看看這個 skill 的內容。
8. 自我審查 #
這我覺得也是 harness 的一環：不只是產出內容，還要讓產出的內容自己先過一層檢查。
產出設計文件後，AI 不是直接把它交出去，而是要自己 review 一次，減少明顯的低級錯誤。像是有沒有留下 TODO、前後講法是否一致、範圍是不是太大、是否有模糊到實作者會誤解的地方。
有趣的是，這個流程以前似乎有用 subagent review，後來改成 inline self-review。原因也滿務實：subagent review 成本高、時間長，但對 spec 這種文件來說，品質提升不一定值得。很多常見問題其實用 checklist 自己掃一遍就能抓到。
這讓我學到一件事：不是所有多 agent 流程都比較好。有些問題適合派另一個 AI 來看，有些問題則是讓同一個 AI 用明確 checklist 回頭檢查，反而更划算。
小結 #
讀完 brainstorming skill 後，我覺得它最有價值的地方，不是「讓 AI 更會腦力激盪」這麼簡單。
它真正做的事情，是把模糊需求整理成可討論、可拆分、可驗證的設計。這其實就是很多工程工作裡最困難、也最容易被低估的一段。
以前我們可能會說：「先想清楚再做。」
但 brainstorming skill 更像是在補上下一句：
「那要怎麼想清楚？」