所有節目›AI Engineer Europe 2026World's Fair 2026World's Fair 線上軌AI in HealthcareSoftware Factories
Full Walkthrough: Workflow for AI Coding在 YouTube 看這一場

AI Engineer Europe 2026 · 工作坊 · 2026-04-24 · 97 分

從 grill 到 AFK 迴圈的寫碼流程

Full Walkthrough: Workflow for AI Coding · Matt Pocock

Matt Pocock 帶大家走一遍自己的 AI 寫程式流程:先 grill 對齊、寫 PRD、拆成垂直切片的看板,再交給 AFK agent 實作,最後人工 QA,並一路講深模組與回饋迴圈。

context 多寡看原片 ↗

概要

  • 兩個 LLM 限制Matt 的前提是 LLM 有聰明區與笨區,約 100K token 之後就變笨,而且每個 session 都會重置,像 Memento 裡的人。所以偏好 clear 而不是 compact,任務也要切小。
  • 先 grill 再寫 PRDMatt 反對只改規格不看程式碼的做法,改用很短的 grill me skill 逐題訪談,直到跟 AI 取得共識,再整理成 PRD。這份 PRD 自己並不讀,因為已經對齊,讀它只是在檢查摘要。
  • 看板與垂直切片Matt 請 AI 把 PRD 拆成有阻擋關係的獨立 issue,要求每個是貫穿各層的薄切片,而非一層一層做。這樣能儘早拿到回饋,也能讓多個 agent 平行。
  • AFK 實作加人工 QA人負責白班的規劃,夜班由 Ralph 迴圈實作,再以 TDD 與型別檢查當回饋。Matt 仍堅持人工 QA 與 code review,認為全自動會讓成品沒有品味。
  • 程式碼庫形狀決定 AI 表現Matt 說爛的程式碼庫養出爛的 agent,主張用深模組、小介面、把實作委派的灰盒子來維持對程式的掌握,並展示專門深化模組的 skill。
  • 平行化與 Q&AMatt 展示自己做的 Sandcastle,用 work tree 加 Docker 沙盒平行跑多個 agent,並回答了框架選擇、文件腐爛、編碼標準等聽眾問題。

原話

  • “Every time you add a token to an LLM, it's kind of like you're adding a team to a football league.”

    每多一個 token,就像聯賽多一支球隊

    ▶ 03:40
  • “I didn't need an asset. I didn't need a plan. I needed to be on the same wavelength.”

    我要的不是成品或計畫,而是跟 AI 想法同步

    ▶ 17:20
  • “bad code bases make bad agents.”

    爛的程式碼庫會養出爛的 agent

    ▶ 36:46
  • “AI loves to code horizontally. So it loves to code layer by layer.”

    AI 愛橫向做,一層一層寫

    ▶ 42:45
  • “TDD, I've found, is absolutely essential for getting the most out of agents.”

    我發現,要把 agent 的能力發揮到最大,TDD 絕對不可或缺

    ▶ 1:06:45

延伸

  • Matt 說 grill me 的靈感來自 Frederick P. Brooks 在 The Design of Design 講的「設計概念」:一起做新東西的人,腦中要有同一個想法,並發現自己跟 Claude 缺的就是這個,而不是一份計畫。
  • 把任務切小,Matt 說是 Martin Fowler 的 Refactoring 與 Pragmatic Programmer 早就講過的老建議,對人與 AI 都適用。

章節

點時碼直接跳到原片的那一段。

  1. 開場與主張Matt Pocock 說自己這半年的前提是:AI 雖然是新典範,但跟人合作用的軟體工程基本功,用在 AI 身上一樣有效。這場 workshop 要示範這件事,現場並開了 Slido 收問題。
  2. 聰明區與笨區Matt 引用 HumanLayer 的 Dex Horthy 的說法:對話剛開始最聰明,token 越多越笨。自己的經驗則是不管視窗是 200K 還是 1 million,大約 100K 就開始變笨,所以任務要切小。
  3. 多階段計畫與 RalphMatt 到去年 12 月都還在用多階段計畫,後來發現那就是一個迴圈。Ralph Wiggum 做法是只講終點、每次小改一點,覺得可以,只是偏好多一點結構。
  4. 像 Memento 的 LLMLLM 每次都重置回初始狀態,所以 system prompt 要小,一個 session 大致分探索、實作、測試。Matt 討厭 compact,偏好 clear 之後回到固定的起點。
  5. Grill me 與 specs-to-codeMatt 反對只改規格不看程式碼的 specs-to-code,說自己試過行不通。取而代之的是很短的 grill me skill,逐題訪談、每題附建議答案,目標是跟 AI 對齊。並現場拿客戶 Slack 訊息的遊戲化需求來跑。
  6. Q&A:規劃框架與配對有聽眾問 SpecKit、OpenSpec、Taskmaster 之類的框架。Matt 的看法是沒有明確贏家,應該盡量掌握自己的規劃流程;也認為讓 AI 加入配對甚至多人一起 grill 都行。
  7. 要人在場 vs 可離開Matt 把任務分成需要人在場(human in the loop)與可以離開鍵盤(AFK)兩種。規劃與對齊一定要人在場,實作則可以變成 AFK。
  8. 目的地與旅程兩份文件grill 完之後要把結果整理成兩份文件:一份記目的地(使用者故事與完成定義),一份記路線怎麼切。Matt 展示這場 grill 用了 25k token,並說裡面大多是有用的東西。
  9. 寫 PRD 與不讀 PRDwrite a PRD skill 會產出問題、解法、使用者故事、實作決策與測試決策,也會列出要改的模組。Matt 自己不讀 PRD:既然已經跟 LLM 對齊,讀它只是在檢查摘要能力。
  10. Q&A:Claude Code、TS、1M被問不愛 Claude Code 的話改用什麼,Matt 借「民主是最不壞的制度」來形容它;也認為還是要深入懂程式碼,因為爛的程式碼庫養出爛的 agent。至於 1 million context,則認為多出來的主要是笨區,適合檢索、不適合寫程式。
  11. 用看板取代多階段計畫Matt 請 AI 把 PRD 拆成有相互阻擋關係的 ticket,也標示哪些是 AFK,並說這比循序的多階段計畫更好用;當時它提了五個任務。
  12. tracer bullet 垂直切片Matt 觀察到 AI 愛一層一層橫著做,要到第三階段才有回饋,於是要求改成貫穿各層的薄切片,並以 Pragmatic Programmer 的 tracer bullets 當比喻,現場還把第一份太橫向的切法退回。
  13. Q&A:何時停止 grill有聽眾問 AI 問個沒完怎麼辦。Matt 說可以叫它收斂、加停止點,改 skill 即可;也講到曾用「說話省略文法」的提示,後來改以 grill 取代。
  14. 可平行的獨立 issue這些 issue 設計成獨立可領取,形成有向無環圖,可以讓多個 agent 同時做。Matt 說這是自己不用循序計畫的原因,也順手把 AI 誤建在 GitHub 的 issue 改成本機 markdown。
  15. 白班夜班與 Ralph 迴圈人類負責白班的規劃,夜班交給 AI 實作。Matt 逐行講解 Ralph 的 prompt 與 once.sh:把 issue、最近五個 commit 一併傳給 Claude,AFK 版本跑在 Docker sandbox,現場只示範一次性版本。
  16. Q&A:審查量、團隊、前端Matt 說用 agent 寫程式,code review 只會變多,自己也沒有好答案。團隊面,從想法到 PRD 那段要大家一起討論;前端則請 AI 產出三個可點選的拋棄式原型再拿回去 grill。
  17. 清掉 context 再審查Matt 主張實作完要有自動審查,並且先清空 context,否則審查者是在笨區工作、會比實作者還笨。
  18. TDD 紅綠重構TDD 對 Matt 來說是用 agent 的關鍵。AI 常先做整層實作再補測試,像是在作弊,所以要教它先寫失敗的測試再通過。
  19. Ralph 跑完與手動 QA跑完後得到一個 commit 與摘要,AI 也跑了測試與型別檢查,共 284 個測試。Matt 強調回饋迴圈的品質是上限,並說手動 QA 是把品味放回程式碼的時刻,全自動會做出沒品味的 slop。
  20. 深模組與淺模組Matt 引用 John Ousterhout 的深淺模組:淺模組又多又碎,AI 難導航也難切測試邊界;深模組介面小、功能多,好測,所以在 PRD 裡就指定要動的模組。
  21. 灰盒子保持掌握為了在快速交付時不失去對程式的掌握,Matt 建議自己設計模組介面,把實作委派出去,當成灰盒子,只要知道它在什麼條件下怎麼表現。
  22. improve codebase architectureMatt 有一個專門找地方深化模組的 skill,並分享在自己的瀏覽器影片編輯器上,用它做出可從外部整段測試的大模組,AI 改動能力因此大幅提升。
  23. Q&A:文件腐爛與標準Matt 不保留已完成的 PRD,因為會有文件過時、誤導 agent 的問題,所以在 GitHub 上直接關閉;也不認為要把 PRD 優化到完美,並說明編碼標準對實作者用 pull、對審查者用 push。
  24. Sandcastle 平行迴圈Sandcastle 是 Matt 花約一週做的 TypeScript 函式庫,用 work tree 加 Docker 沙盒跑迴圈:planner 排出 issue,實作、審查,再由 merger 合併;實作用 Sonnet,審查用 Opus。
  25. 架構掃描結果與總結improve codebase architecture 找出的候選包含沒有任何測試的 quiz scoring service。Matt 最後總結整條流程,並推薦大家去買那些老書來讀。

名詞

smart zone / dumb zone
Matt 引用 HumanLayer 的 Dex Horthy 的說法:對話越長 LLM 越笨,自己的標記大約是 100K token
grill me
Matt 自己的短 skill,逐題訪談並附建議答案,用來跟 AI 對齊
AFK
可以離開鍵盤的任務,與要人在場的 human in the loop 相對
Ralph(Ralph Wiggum)
只講終點、反覆小改的迴圈做法,Matt 的 AFK 實作迴圈沿用此名
tracer bullets / vertical slices
貫穿各層的薄切片,用來儘早拿到回饋
deep module
介面小而功能多的模組,Matt 引用 John Ousterhout 的說法,相對於淺模組
Sandcastle
Matt 做的 TypeScript 函式庫,用 work tree 與 Docker 沙盒平行跑 agent
course video manager
Matt 平常錄課用的自家應用,也是這場的實戰 repo 範例

相關影片 同屬「context 多寡」