你的AI編程總是翻車？因為你少做了一步：設計隔離 | 拆解 Grill-me，Superpowers，Openspec 的第一步

大家好,我是為什麼叫QQ 你有沒有想過 為什麼有些工程師 能快速把模糊的想法 變成清晰的設計 而有些人卻在規劃階段 就陷入無盡的討論 問題不在於他們的聰明程度 而在於他們用的規劃工具不一樣 今天我要講的是 三個最近很有代表性的 規劃型skill和工作流 Matt Pocock的GrillMe 和SuperpowersTheBrainstorming 還有OpenspecTheExplore 他們看起來都在做同一件事 幫你把想法理清楚 但方法完全不同 有的像一個咄咄逼人的面試官 有的像一個嚴格的項目經理 有的像一個好奇的思維夥伴 這三個框架到底有什麼區別 哪一個纔是最適合你的 如果你要自己設計一個規劃工具 應該怎麼做 這些問題看起來簡單 但答案會讓你重新思考 整個需求分析的流程 在AI時代 代碼生成工具變得越來越強大 但強大的工具也帶來了新的問題 如果你的需求本身就是模糊的 再強大的代碼生成工具 也幫不了你 所以規劃階段變得比以往任何時候都重要 這三個框架都是在這個背景下誕生的 Matt Pocock是TypeScript社區的教育者和工程師 他的GrillMe是一個入口 實際會觸發Grilling 用連續追問來壓力測試你的計劃 Superpowers是一個完整的AI編程助手系統 Brainstorming是其中的核心模塊 OpenSpectre Explore 更像是先別急著提案的探索模式 當問題還不清楚時 先讀代碼比較選項 畫圖澄清範圍 等方向明確後 再交給Propose形成共建 他們都在解決同一個問題 如何在實現之前 確保你真正理解了你要做什麼 第一個關鍵點 流程嚴格性的差異 讓我們先看流程的嚴格性 這是三個框架最根本的區別 Matt的Grilling是最清亮的 他的核心思想很簡單 讓AI扮演面試官 一個問題一個問題地追問你 直到你們達成共同理解 具體怎麼用呢 你告訴AI你有一個想法 比如我想建一個實時協作編輯器 AI就開始問 這個編輯器要支持多少個並發用戶 數據要實時同步嗎 如果網絡斷開了怎麼辦 衝突怎麼解決 它會沿著設計樹逐個追問 每個問題都等你回答後再繼續 這個方法的好處是快速 而且有很強的訪談紀律 你不能含糊其詞 每個問題都得正面回答 但它不強制產出文檔 所以事後很難追蹤你們討論了什麼 六個月後你還記得為什麼要這樣設計嗎 肯定不記得 Grilling特別適合這樣的場景 你已經有一個初步的想法 需要快速驗證這個想法是否可行 或者你在實現過程中遇到了問題 需要快速討論解決方案 Superpowers the brainstorming 有一套九步checklist 先探索項目上下文 再在真正需要可視化時 按需提供visual companion 然後逐個提出澄清問題 給出兩到三個方案 展示設計並獲得用戶確認 寫入設計文檔作字審查 讓用戶審查最後才進入writing plans 這個框架的哲學是 沒有項目太簡單到不需要設計 即使是一個簡單的代辦事項列表 也要走完整個流程 這聽起來挺折騰人的 但它能逼著你把所有沒想清楚的坑都填上 Brainstorming特別強調一個原則叫 設計隔離和清晰性 這意味著系統的每個部分 都應該有一個清晰的目的 通過良好定義的接口與其他部分通信 可以獨立理解和測試 這話聽著像教科書裡的廢話 但在實際幹活時能救命 你回憶一下 多少次你改了一行代碼 結果系統另一頭崩了 這就是邊界沒劃清楚的代價 還有一個細節 Brainstorming會在需要時提供Visual Companion 也就是一個瀏覽器伴侶 用來展示原型和圖表 但這不是自動打開的 而是當某個問題確實看圖更清楚時 先詢問用戶 用戶同意後才啟用 每個問題都要單獨判斷是否用瀏覽器 OpenSpec的Explore介於兩者之間 但更接近Grilling 它沒有固定的步驟 強調的是靈活性和適應性 Explore的重點不是立刻產出文檔 而是把問題想清楚 按當前公開文檔 Explore本身不創建Change Folder 也不寫Proposal Spec Design或Tasks 它會在方向明確後 把上下文交給Obseqs Propose 等OpenSpec Explore Skill允許 在用戶明確要求時捕捉為OpenSpec Artifacts 這是版本差異 當你盯著一個龐大且混亂的系統 完全不知道從哪下手時 Explore就像個坐在你旁邊的老同事 它問問題不是為了讓你交差 而是為了幫你把腦子裡的亂碼理順 第二個關鍵點 可視化支持的演進 現在看可視化支持 這是一個很容易被忽視 但是很重要的維度 Grilling沒有任何可視化工具 它就是純文本對話 這對於簡單的決策很有效 但當你需要展示一個複雜的系統架構 或UI佈局時 就顯得力不從心了 想像一下你在用Grilling 討論一個多Agent系統的架構 AI問這個系統有多少個Agent 你說五個 分別是規劃執行監控學習和協調 AI繼續問他們怎麼通信 你開始用文字描述 規劃發送任務給協調 協調分配給執行 說到這裡你已經有點混亂了 如果能看到一個圖表就好了 Brainstorming包含了一個叫 Visual Companion的工具 這是一個瀏覽器介面 可以顯示圖表設計選項的對比 關鍵是它不是強制使用的 框架會根據問題的性質判斷 如果某個問題確實更適合視覺化 並且用戶統一啟用Visual Companion 才會打開瀏覽器 之後每個問題仍然單獨判斷 是否需要可視化 比如當討論UI佈局時 Visual Companion會顯示幾個不同的佈局選項 你可以點擊選擇 當討論系統架構時 它可以顯示一個交互式的架構圖 這種按需可視化的方式很聰明 避免了過度設計 而且它不是一個通用的可視化工具 而是在brainstorming的九步 流程中的第二步就已經內置了 OpenSpec的Explore 可視化方式聽起來很原始 但實際上很有效 一個簡單的ASCII圖表 可以快速表達系統的結構 數據流狀態轉換 對工程師來說 這種極簡的可視化很有實用性 公開文檔只提到Draw Diagrams 沒有指定ASCII 不用打開畫圖軟件 不用拖拽對齊 純文本畫完 直接貼進代碼註釋或者文檔裡 乾淨俐落 第三個關鍵點 輸出和追蹤機制 最後看輸出和追蹤 這決定了你的規劃工作 是否能被長期維護 Grilling的輸出 就是一個共同理解 你和AI討論完了 你明白了 AI也明白了 然後就結束了 沒有文檔沒有記錄 只有你腦子裡的理解 這對於快速決策很好 但對於需要長期維護的項目 就成了問題 六個月後 你還記得為什麼要這樣設計嗎 你的團隊新成員 怎麼理解這個設計 如果需要改動 你怎麼知道會影響哪些部分 Brainstorming 強制生成一個設計文檔 保存到指定的目錄 並提交到Git 這個文檔會經過自審查 檢查是否有站位符 矛盾起疑 然後用戶還要再審查一遍 我知道聽到寫文檔和雙重審查 很多人的第一反應是太重了 但你仔細想想 當你試著把腦子裡的想法 變成文字時 是不是經常卡殼 那是因為你根本沒想清楚 這份文檔不僅是寫給 未來的接盤俠看的 它更是你現在用來約束AI 防止他亂寫代碼的緊箍咒 這種高度的靈活性聽起來很爽 但說實話非常考驗你的自律 沒人逼著你輸出 你很容易聊著聊著就跑偏了 如果你在explore的過程中 明確要求捕捉為弓箭 系統會幫你組織信息 比如一個提案會包含問題陳述 建議的解決方案 權衡分析 一個設計會包含 架構組建數據流 一個規範會包含 需求約束成功標準 但這些都是可選的 不是explore的默認流程 很多人會覺得 Brainstorming的九步流程太重了 Grilling的輕量級方法更高效 但實際上 這取決於你的項目規模 和團隊成熟度 對於初創團隊或個人項目 Grilling確實更高效 快速發現問題 快速迭代 你一個人做決策 不需要文檔 不需要審查 就是快 但對於中等規模以上的項目 特別是有多個人參與的項目 Brainstorming的嚴格流程 反而能節省時間 為什麼 因為它強制你在早期就達成共識 避免了後期的反攻 想像一個場景 你的團隊有五個人 要開發一個新的功能 如果用Grilling 可能每個人都有自己的理解 開發到一半時才發現 理解不一致 需要反攻 如果用Brainstorming 雖然前期花了更多時間 討論和文檔 但實現時 大家都在同一條線上 反而節省了總時間 而explore呢 它最適合那些 需要深度思考的場景 當你面對一個真正複雜的問題 不確定從哪裡開始時 explore的靈活性就變成了優勢 它不會強制你走某個流程 而是陪伴你逐步釐清思路 現在我要提出一個 我的思維方法 我把這三個框架 看作是規劃階段的 三個不同維度 第一個維度是規範性 Brainstorming最規範 有強制的步驟和輸出 Grilling次之 有基本的對話結構 explore最靈活 沒有固定的步驟 第二個維度是輸出確定性 Brainstorming有強制的文檔輸出 確保你一定會有一個設計文檔 Grilling有隱性的理解輸出 你明白了就行 explore默認不生成弓箭 但在你open spec裡 用戶明確要求時 可以捕捉為open spec artifacts 第三個維度是學習成本 Grilling最容易上手 就是對話沒有學習成本 explore需要一些經驗 主要是判斷什麼時候繼續探索 什麼時候轉入purpose 或者在open spec裡 什麼時候明確要求捕捉為弓箭 Brainstorming的學習曲線最陡峭 九個步驟 每個步驟都有具體的要求 如果你把這三個維度 畫成一個坐標系 你會發現它們佔據了不同的位置 沒有哪一個是絕對最優的 最優的選擇取決於你的具體場景 但這裡有個更深層的洞察 這三個框架代表了三種不同的哲學 Grilling是質量保證哲學 它的核心是通過對抗式的提問 來發現問題 就像一個嚴格的代碼審查目標 是找出漏洞 這個哲學假設 如果你能回答所有的問題 那你的計劃就是可靠的 Brainstorming是過程管理哲學 它的核心是通過結構化的流程 來確保完整性 就像一個嚴格的質量管理體系 每一步都有檢查點 這個哲學假設 如果你遵循正確的流程 就能得到正確的結果 Explore是認知知識哲學 它的核心是通過靈活的工具 來支持思考 就像一個思維夥伴幫你整理思路 這個哲學假設 思考過程本身就是價值 不一定非要有最終的輸出 但在現在這個AI滿天飛的時代 光靠一種套路是不夠的 我們需要像面試官一樣揪出漏洞 需要像項目經理一樣把控流程 也需要像老搭檔一樣碰撞靈感 如果我們要設計一個新的規劃工具 應該怎麼做 我認為應該有以下幾個特點 它得能接得住各種爛攤子 有些人有模糊的想法 有些人有初步的計劃 有些人遇到了具體的問題 不同的入口應該導向不同的流程 比如如果你扔過來一句 我想見個AI助手 系統得知到這只是個腦洞 然後切到Explore模式 陪你慢慢盤邏輯 如果你說 我想在現有的系統裡 加一個新的功能 系統應該識別這是一個初步的計劃 然後進入Grilling模式 快速發現問題 如果你說我遇到了一個架構問題 不知道怎麼解決 系統應該識別這是一個具體的問題 然後進入Brainstorming模式 幫你係統的分析問題 它得知道什麼時候該深挖 什麼時候該打住 第一層是快速澄清 5到10分鐘內發現主要問題 第二層是深度探索 15到30分鐘的詳細討論 第三層是設計文檔可選的 用戶可以根據需要選擇層級 如果你只是想快速驗證一個想法 就停在第一層 如果你需要一個完整的設計 就繼續到第三層 它得懂什麼時候該畫圖 不是所有問題都需要圖表 但關鍵問題應該有 系統應該自動判斷 什麼時候需要可視化 比如當討論系統架構時 自動生成SK圖表 當討論UI佈局時 自動生成原型 當討論權衡時 自動生成對比表格 它得自帶防呆機制 檢查完整性 一致性 奇異性 這樣可以減少人工審查的負擔 比如自動檢查 是否有微定義的術語 是否有矛盾的需求 是否有模糊的表述 它得能輸出 大家都能看懂的東西 有些人需要文檔 有些人需要OpenSpec工件 有些人只需要一個理解總結 系統應該能夠生成 不同格式的輸出 適應不同的使用場景 最重要的是它得能自我進化 記錄哪些問題最有效 哪些提問方式最能引發深思 隨著時間的推移 系統應該變得越來越聰明 比如如果發現 對於API設計的問題 問這個API 會被哪些不同的客戶端使用 特別有效系統 就應該在類似的場景下 優先使用這個問題 在我的實踐中 我發現最有效的方法是 混合使用這三個框架 對於新項目 我通常先用Explore 花15到20分鐘 和AI一起思考 這個項目的本質是什麼 核心問題是什麼 有哪些關鍵的設計決策 這個過程中 我會生成一些ASCII圖表 和初步的想法 然後我用Grilling 來快速驗證這些想法 問一些尖銳的問題 看看有沒有明顯的漏洞 這個過程通常 很快5到10分鐘 最後如果這是一個重要的項目 我會用Brainstorming來 生成一個完整的設計文檔 這確保了設計的完整性 和可追蹤性 這個混合方法的好處是 快速深入完整 另一個經驗是 不要過度設計 很多工程師的問題 不是設計不足 而是設計過度 他們試圖在規劃階段 就解決所有的問題 結果導致規劃階段無限延長 我的建議是 規劃階段的目標是 發現關鍵的問題 和做出關鍵的決策 不是所有的細節 都需要在規劃階段確定 有些細節可以在實現階段決定 最後一個經驗是 要重視文檔 即使你用的是Grilling 這樣的輕量級方法 也應該花五分鐘 寫下關鍵的決策和理由 這個文檔不需要很長 但應該清晰 我寫了這麼多年代碼 這幾個框架 讓我明白了一件事 規劃框架的本質是什麼 是幫助我們在 複雜性爆炸之前 儘可能地理解問題 在AI時代 這變得更加重要 因為AI工具 可以快速生成代碼 但他們不能為我們思考 如果我們的需求 本身就是模糊的 AI生成的代碼 再完美也沒用 所以規劃階段的價值在於 確保我們問的是 正確的問題 而不是快速得到 錯誤的答案 別再盲目抄作業了 找準你現在的痛點 纔是正經事 Grilling適合快速驗證 特別是當 你已經有一個初步想法時 Brainstorming適合 系統化管理 特別是當 你有一個團隊要協作時 Explore適合深度思考 特別是當 你面對一個複雜問題時 如果你非要我給個建議 一個人折騰的小玩具 用Grilling 面對一團亂麻的舊系統 用Explore 如果是要上線的核心業務 老老實實走 Brainstorming的流程 但最好的做法是 把這三個框架的優點 結合起來 為你的團隊設計一個 定製化的規劃流程 好了這就是今天的全部內容 如果你覺得有收穫 歡迎點贊投幣收藏 也歡迎在評論區 分享你用過的規劃工具 你覺得哪個框架最有用 為什麼 把你的看法打在公屏上 也別忘了長按點贊 我們下期見