！ 本篇文章將會介紹基本盤技能實戰：grill-me 的拷問哲學、tdd 的紅綠循環、code-review 的雙軸審查 :D

TL;DR: https://dev.benben.me/slides/s/ironman-26-mp-skills-beginner

本篇目標

讀完這篇你會學到：

• 用 /grill-me 在動工前對齊需求
• 用 /tdd 建立可靠的 feedback loop
• 用 /code-review 做雙軸審查、用 handoff 無縫交接

/grill-me：動工前的拷問現場

用法沒有儀式：腦子裡有個想法就打 /grill-me 我想在 blog 加一個訂閱功能，然後準備被拷問：

你：/grill-me 我想在 blog 加訂閱功能
AI：目標讀者收到什麼？全文還是摘要？
你：摘要就好
AI：那 unsubscribe 流程呢？需要 double opt-in 嗎？
你：呃……沒想過
AI：儲存訂閱者資料有個資考量嗎？GDPR？
你：……你贏了，讓我想想再來

grill-me 會一路逼問到「計畫樹的每個分支都有答案」為止。它解的是 Day 06 那個老問題——九成的 AI 做錯都是人沒講清楚——只是這次是 AI 主動把你的沒講清楚全部挖出來。

筆者心得：grill-me 最有價值的輸出不是答案，是那些「呃我沒想過」的瞬間。每個「沒想過」如果發生在實作後，就是一次重工。

/grill-with-docs：拷問加上共同語言

/grill-with-docs 是 grill-me 的工程版——拷問過程中順便做兩件事：

1. 把專案的領域術語沉澱進 CONTEXT.md（shared language 文件）
2. 難以解釋的設計決策寫成 ADR（Architecture Decision Record）

用過一輪後，AI 講你的專案開始出現「materialization cascade 有問題」這種一行命中式的句子——context 省、命名一致、AI 導航 codebase 也更準。Matt 自己說這「might be the single coolest technique in this repo」。

/tdd：紅綠重構的紀律

AI 寫測試常見的墮落模式：一次生成二十個測試、測試模仿實作（implementation 寫什麼就測什麼）、測試與 bug 無關。/tdd skill 把紀律寫死：

• 紅：先寫一個會失敗的測試
• 綠：寫剛好通過的最小實作
• 重構：綠燈下整理

一次一個 test、一個 minimal implementation、循環。看起來慢，但 AI 的「一次寫一大包」看似快、debug 慢——feedback loop 的速率才是真正的速度限制。

/code-review：雙軸審查

review 一個 diff，其實在問兩個獨立的問題：

1. Standards：這 code 有沒有遵守 repo 的規範？（coding standards + Fowler 的 code smell 基準）
2. Spec：這 code 有沒有忠實實作「當初那個 issue / spec」？

/code-review 把兩軸拆成平行的 sub-agent——各自看各自的，互不污染。輸出並列：這裡違反規範、那裡偏離 spec。審查品質瞬間從「憑感覺」升級成「有清單」。

交接神器：/handoff

對話越長 context 越髒，這是 agent 工作的宿命。/handoff 把當前對話濃縮成一份交接文件：做到哪、決策了什麼、下一步是什麼——新的 agent session 讀完文件無縫接手。長任務必備，等於幫 AI 寫「工作日誌 + 交接單」。

一次完整的基本盤流程

把今天的技能串起來：

1. /grill-me        ← 拷問需求，補滿計畫樹
2. （動工）          ← plan agent 排方案
3. /tdd             ← 紅綠重構實作
4. /code-review     ← 雙軸審查 diff
5. /handoff         ← 今天做到這，明天見

在 opencode 裡，1–2 用 plan agent（Day 05）、3–4 交給 build agent——每一步都是前十五天學過的機制，skills 補上「紀律」這塊拼圖。

常見問題

Q：grill-me 問太多很煩，可以叫他收斂點嗎？
A：可以，直接說「重點問三個就好」。但筆者建議前幾次忍住——煩，代表你的計畫真的有洞。習慣之後你會開始在被打問之前自己先想。

Q：tdd 適用所有任務嗎？
A：有明確行為定義的功能與 bug fix 最有效。視覺微調、探索性 spike 就別硬上了——紀律是工具不是信仰。

Q：code-review 的「Spec 軸」在沒有 spec 的專案怎麼辦？
A：它會退而追蹤「原始 issue 或對話意圖」。當然，有 Day 23 的 OpenSpec 或 Day 27 的 to-spec，Spec 軸才有真正的錨。

小結

• /grill-me 拷問到計畫樹全綠；/grill-with-docs 加送 CONTEXT.md 與 ADR
• /tdd 一次一測的紅綠循環，速率來自 feedback 而不是爆量
• /code-review Standards + Spec 雙軸平行審查
• /handoff 讓長任務跨 session 存活

明日預告

Day 27：進階工作流——to-spec、to-tickets、wayfinder 到 implement，把「一個想法」加工成「一排可執行的 ticket」再全部做完。

有任何疑問但沒有 iT 邦幫忙帳號，或是想匿名提問？
歡迎到 https://dev.benben.me/q/P3C5U6 提問或加油打氣，沒意外的話會在完賽之後一起回答 :D