跟 AI 對齊需求:不是寫厚 spec,是讓它反問你、再把對齊存成會複利的薄文件
多數人跟 AI 合作第一步都一樣:坐下來寫 spec。把需求列清楚、功能描述完整、邊界案例都想好,然後貼進去。結果 AI 照做了,但做出來的東西就是差那麼一截。
問題通常不在 AI 的能力,而在你貼進去的那份 spec 本身——它是你在真正理解需求之前猜出來的。
需求是潛在的
需求有個讓人不舒服的特性:它們是潛在的(latent)。就像使用者測試裡的受訪者總說「見到才知道自己要什麼」,你在 spec 裡寫下的,往往是你能語言化的部分,不是你真正需要的部分。這兩者之間的落差,會在執行後半段以 bug、方向偏移、或「做完了但感覺哪裡不對」的形式出現。
這是很多 spec 失效的根本原因——不是格式不對,而是在需求還沒被充分揭露之前就產出了。
第一步:讓 AI 逼出你腦裡的東西
Matt Pocock 的 grill-me 機制,切入點剛好相反。skill 極短,核心只有一件事:讓 AI 無情地訪談你這個 plan 的每個面向,走過決策樹的每一個分支,逐一解開依賴,每題給你建議答案,一次只問一題。結果是 AI 反過來問你四十到一百題,把你腦中說不清的需求逼出來。
這個設計有理論根據。Fred Brooks 在《The Design of Design》裡描述過共享設計概念(shared design concept)——共同建造時漂在所有參與者之間、那個無形的「我們要做什麼」的理論。它不是 Jira ticket、不是 markdown,而是一種需要先對齊才能協作的隱性理解。沒有它,就算 spec 再厚,每個 agent 都在做自己想像中的那個東西。
但對話留不住:把對齊沉澱成會複利的薄文件
grill-me 紅了之後,Matt 自己卻把它換掉了——影片標題就叫「我不再用 grill-me 寫 code」。原因很實在:有 codebase 時,光靠對話會漏掉一塊。
他發現每開一個新 session,都得重新跟 AI 解釋領域裡的非顯性術語(例如他的「standalone video」其實是「lessonId 為 null 的影片」);而且 grill 過程中好不容易談出的精準講法,沒被記在任何地方,下次又要重來。對話對齊了當下,卻沒有累積。
補上的那塊,是 DDD(領域驅動設計)的 ubiquitous language:開發者的對話、code 的命名、跟 AI 的溝通,全部從同一套詞彙衍生。Matt 把它落成 repo 裡一份 context.md 術語表(大型 repo 用 context map 分多個 bounded context),grill 時讓 AI 讀它、拿你的新講法去挑戰並磨利既有術語、對照 code、邊談邊更新。grill-me 加上這層,就成了他現在用的 grill-with-docs。
回報是複利:有人連用四五次後發現,AI 在 grill 中開始自動接住 context、對齊到「話還沒說出口它就懂」。共用語言讓 AI 回覆更精簡、連它自己的思考軌跡都更短;更關鍵的是——你定義的這套語言,同時就是程式碼的命名、也是使用者在畫面上看到的字。三者同語,code 自然好導航。
術語表裝得下「語言」,裝不下「為什麼這樣決定」。那層 Matt 用 ADR(Architecture Decision Record):repo 裡的簡單 markdown,只記難以反悔、沒 context 會讓人意外、是真實 trade-off 結果的決策。可以隨手換掉的(用 A 庫還是 B 庫)就別記——不是什麼都寫,是只寫「之後的人少了這段就會踩雷」的那種。
用哪個有個簡單規則:有 codebase → grill-with-docs;沒 codebase(純發想、甚至幫你訪談寫一篇悼詞)→ grill-me;專案極早期 → 也用 grill-with-docs,因為那正是該建立共同語言的時候。
對齊之後,文件的角色變了
先對齊、再產文件,順序不能反。grill 走完,Matt 才產 PRD,而且他不細讀它——LLM 很會摘要,PRD 讀起來對,代表對話被整理準確了;讀起來不對,才回頭修。PRD 在這裡是對齊品質的驗收,不是執行依據。執行依據是接下來的 Kanban:把 PRD 拆成一堆可獨立抓取、帶 blocking 關係的 issue,形成有向無環圖,讓不互相依賴的 issue 交給多個 agent 平行跑。
要不要把規格寫成詳盡 Markdown?有個觀察:Markdown 超過約兩百行人就不讀了;HTML 規格能內嵌視覺方向、截圖、互動元素,同樣 token 量資訊更密,還讓人幾秒就確認方向對不對。規格的目的是對齊,能讓人快速確認方向的格式,比能塞很多字的格式更值錢。
一個提醒:reviewer 要在 smart zone
實作完、交給 AI review 前,別用那個已經燒掉大量 token 的同一個 session——context 太擠,reviewer 狀態不好。clear context、把 code + 規範主動推給它(push,不是讓它自己 pull),它才從實作者的框架裡解放出來、真的看見問題。
對齊的單位是對話,但對齊要留得住
把這些放在一起,結論其實很簡單:
對齊的單位不是文件的厚度,是對話的深度;但對齊本身要留得住,靠的是最薄的持久層,不是厚 spec。
厚 spec 給 AI 的是你已知的需求;grill 逼出的是你不知道自己知道的需求——前者是資訊傳遞,後者是需求揭露。而 grill-with-docs 多做的那一步,是不讓揭露出來的東西每次都蒸發掉:把共同語言收進 context.md、把難回復的決策收進 ADR。這層薄薄的文件,正是「框架要薄、技能要厚且必須是你的」裡那塊厚技能——它留在你的 repo,下一次對齊就從更高的起點開始。
反問你到對齊,只是開始;把對齊存成會複利的東西,才走得遠。