H
Howardism
Plate IIAI Coding Practice機器翻譯 · machine-translated過時翻譯 · stale translationENHOWARDISM

設計概念拷問式訪談

PublishedMay 6, 2026FiledConceptDomainAI Coding PracticeTagsAgent EngineeringPlanningAlignmentReading7 minSourceAI-synthesised

Matt Pocock 的 `grill-me` skill；在任何計畫之前先達成 Brooks 所稱的「design concept」；對抗 specs-to-code；PRD 作為目的地文件，Kanban 作為旅程文件

設計概念拷問式訪談插圖

資料來源#

摘要#

Matt Pocock 的 grill-me skill——一個不懈追問的訪談提示，沿著決策樹逐一走過各個分支，每次只問一個問題，並提供建議答案——把「請 agent 制定計畫」改成「在任何計畫存在之前先達成共同理解」。重點是對齊，而不是產出。目標狀態就是 Frederick P. Brooks 在 The Design of Design 中所稱的 design concept：所有參與工作的人共同持有的一個想法。PRD 或計畫都是 design concept 的下游；未先對齊就產出其中任何一項，必然導致返工。

這項 skill（逐字引用）#

「持續拷問我這份計畫的每個面向，直到我們達成共同理解。逐一走過決策樹的每個分支，一個接一個解決依賴關係。針對每個問題提供你建議的答案。一次問一個問題……」

就這樣。這項 skill 刻意保持簡短——最小的表面積，最大的行為改變。

為什麼要在計畫前進行拷問式訪談#

Pocock 觀察到，處於計畫模式的 agents「真的非常急著產出計畫」——說一句「我想我已經掌握得夠多了」，就交付一份掩蓋未決問題的計畫。計畫讀起來沒問題，卻會以各種直到實作時才浮現的方式出錯。強迫 agent 先進行訪談，能在問題仍可低成本回答時揭露未決事項。

每個問題都附帶建議答案的模式是關鍵支柱：它讓使用者大多時候只要說「對，同意」，只在真正不同意的地方進行討論。純粹只問問題的訪談，會把使用者的注意力浪費在顯而易見的決策上。

對「從規格到程式碼」運動的反駁#

Pocock 最強烈的負面論點是：specs-to-code 只是換個名字的 vibe coding。 擁護者會說：「寫一份仔細的規格交給 AI，程式碼錯了就修改規格，永遠不要看程式碼。」Pocock 試過了：這行不通。

原因如下：

  • 程式碼才是戰場，不是規格
  • 不與程式碼互動的規格，會退化成願望清單
  • 回饋迴圈是經過一層（spec ⇄ AI ⇄ code），而不是在真正存在 bug 的地方運作（code ⇄ tests）
  • 不接觸程式碼，開發者對系統的心智模型就會腐化

拷問式訪談採取的是相反的紀律：規格是對齊的下游，對齊是任何產出的上游，而開發者在整個過程中都持續參與程式碼。

拷問式訪談的產出#

一場拷問式訪談可以從 10 個問題進行到 100 個問題；Pocock 曾經進行過長達一小時的訪談。最後的產物就是對話歷史本身——保留作為 PRD 步驟的原始素材。Pocock 的 write-a-PRD skill 會消化這段歷史（以及另一場簡短訪談），產出一份目的地文件。

他明確表示之後不會審查 PRD：

「我在這個階段到底要測試什麼？我想測試的失敗模式是什麼？我知道 LLM 很擅長摘要。我已經和 LLM 達到同一個波長。所以我做的事情只是檢查 LLM 的摘要能力。」

這之所以安全，只是因為拷問式訪談已經完成了對齊工作。跳過拷問式訪談，你就必須閱讀 PRD。

兩份必要文件#

拷問式訪談之後，Pocock 恰好產生兩份文件：

  1. PRD（目的地文件）——完成品的樣貌、使用者故事、完成定義、範圍外清單、實作決策、測試決策、要修改的模組
  2. Kanban（旅程文件）——切成可獨立抓取的垂直切片票券（見 Vertical Slice Tracer Bullets）

實作完成後，他會刪除（或關閉）PRD——見 doc rot。

模組地圖出現在 PRD 中#

PRD 包含「要修改的模組」——具體指出哪些既有模組會變更，以及哪些新模組會被引入。這讓規畫與架構產生連結（見 Deep Modules for Agents）。重點是在整個規畫過程中都記住程式碼庫的形狀，而不是等到實作時才事後考慮。

何時跳過拷問式訪談#

拷問式訪談適用於人類參與迴圈的任務。對於短小且範圍明確的變更（「在整個程式碼庫中重新命名這個函式」），其額外成本就浪費了。紀律的強度應隨利害關係調整：功能越大、簡報越模糊、走錯方向的代價越高 → 就越該深入拷問。

相關連結#

  • Matt Pocock——這項 skill 的作者
  • Vertical Slice Tracer Bullets——接在 PRD 之後的 Kanban
  • Deep Modules for Agents——PRD 中的模組地圖將規畫連結到架構
  • Agent Loop Pattern——拷問式訪談位於漏斗頂端的人類參與迴圈；迴圈則排空底端的 AFK 部分
  • Context Window Smart Zone——拷問式訪談使用 sub-agents 讓父層 context 保持精簡
  • Agent Harness Engineering——在規畫層「強制執行不變量」就是「在任何計畫之前先達成對齊」
  • Claude Code Best Practices——explore→plan→code 工作流程具有相同形狀；grill-me 是「explore」步驟更積極的變體
  • Interaction Models——拷問式訪談就是協作式即時迭代；turn-based interfaces 正是讓它如今顯得笨拙的原因，而互動模型正是讓這種拷問式協作感覺原生的基礎
  • HTML as the New Markdown——brainstorm → 讓 Claude 訪談你 → plan，就是拷問式訪談的形狀；Thariq 的 HTML 計畫是比 markdown PRD 更豐富的目的地產物，但代價是更難版本控管
  • Agentic Technical Debt——拷問式訪談產生會寫入 CLAUDE.md 的 design concept；這是防止「每次工作階段重新推導而產生的債務」最強的上游防線
  • Zero-Friction Scope Creep——透過拷問式訪談達成的強大 design concept，能以書面 PRD 單獨通常做不到的方式抵抗範圍擴張
  • Evals as Product Spec——拷問式訪談產生 design concept；evals 編碼了它是否達成。Matt 的「verification loops」和 Cat 的「ten great evals」是規畫另一端的同一個基本原語
  • Building Is Cheap, Arguing Is Expensive——有益的張力：Fiona Fung 的「產生三個 PR 並比較」把設計重新定位到已建構的產物中；在此可調和為原型是 design concept 的媒介，而不是達成 design concept 的替代品

開放問題#

  • 拷問式訪談能否針對另一個持有使用者偏好的 agent 以 AFK 方式執行？Pocock 在 2026 年的答案是「不行，這部分必須有人類參與」——但隨著 agents 越來越擅長建模其主體，這個問題仍然開放。
  • 在多個人類需要對齊的團隊工作中，拷問式訪談會如何改變？Pocock 的提示是：讓 agent 參與房間內的結對程式設計，把它視為第三位對話者。

推導#

資料來源#

§ end
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Cited by 29
Related articles
  • Harness Shrinkage as Models Improve

    Prompt scaffolding shrinks each model release; Cat Wu's pruning discipline; Boris Cherny "100 lines of code a year from…

  • Context Window Smart Zone

    Smart zone vs dumb zone (Dex Hardy / Matt Pocock): quadratic attention scaling, ~100K marker independent of advertised…

  • Claude Code

    Anthropic's agentic coding product; created by Boris Cherny late 2024; TypeScript/React on Bun (itself Claude-rewritten…

  • Deep Modules for Agents

    Ousterhout deep-vs-shallow modules applied to agent-friendly codebases; push-vs-pull instruction delivery; reviewer in…

  • Agent Harness Engineering

    Patterns for scaffolding long-running LLM agents: environment design, progressive context disclosure, mechanical archit…