AI 是新范式,但让软件真正落地的那套老功夫——对齐、切片、反馈循环、模块设计——一样也没过时。这是 Matt Pocock 在 AI Engineer Europe 2026 上,用近两个小时手把手演示的答案。
开场:AI 是新范式,软件工程基本功没有因此过时
核心观点:真正决定 AI 产出质量的,不是某个 prompt 技巧,而是那些和人类协作时同样管用的软件工程基本功。
Matt Pocock 是 TypeScript 领域的知名教育者,经营着 aihero.dev,他的 mattpocock/skills 仓库在 GitHub 上有 16 万 star。这场 workshop 里,他没有讲抽象方法论,而是带着一个真实的课程管理平台(一个面向讲师和学生的 CMS),从一句模糊的想法出发,一路走到可交付的代码,完整演示他过去半年打磨出来的工作流。
他反复强调的 thesis 只有一句话:
"We all think that AI is a new paradigm... but we forget that software engineering fundamentals — the stuff that's really crucial to working with humans — also works super well with AI."
我们都觉得 AI 是全新范式,却忘了那些和人类协作时至关重要的软件工程基本功,用在 AI 身上同样极其管用。
整场演示的目标,是给平台加一个 gamification(游戏化) 功能——需求来自客户 Sarah Chen 的一条 Slack 消息:课程平台的留存不理想,学生报名几节课就流失了,她想加点游戏化机制。Matt 要做的,就是把这句话变成能上线的功能。
Matt Pocock 在 AI Engineer Europe 2026 舞台上
Smart Zone 与 Dumb Zone:LLM 的"注意力天花板"
核心观点:上下文越长,LLM 越笨——大约 10 万 token 是"变笨"的临界点,所以任务必须切到能装进"聪明区"的大小。
这个框架来自 HumanLayer 创始人 Dex Horthy:LLM 有一个 Smart Zone(聪明区)和一个 Dumb Zone(愚蠢区)。刚开新对话、上下文最干净的时候,模型做得最好,因为此时 token 之间的注意力关系压力最小。Matt 用了一个很妙的类比:
"Every time you add a token to an LLM it's kind of like you're adding a team to a football league. Think of the number of matches that get added — it scales quadratically."
每往上下文里加一个 token,就像往足球联赛里加一支球队:要新增的比赛场次是平方级增长的。
原因是每个 token 都要和其他所有 token 建立注意力关系(位置的 + 语义的)。于是无论你用的是 20 万还是 100 万的 context window,结果都一样:
"Around a hundred K is kind of my new marker for this... it just starts to get dumber and dumber until it's making stupid decisions."
大约 10 万 token 是我现在的分水岭……它会越来越笨,直到开始做蠢决定。
所以核心纪律是:把任务切到能塞进 Smart Zone 的大小,别让 AI"贪多嚼不烂"。这其实是 Martin Fowler 的《重构》、《程序员修炼之道》里的老建议——别一次咬下超过你能嚼的量,任务小到人类开发者不会崩溃、不会进入"愚蠢区"。
那大任务怎么办?Matt 梳理了几条路径。AI 公司希望你走的那条,是一路怼下去,进了 Dumb Zone、烧掉大量 token,再 compact(压缩)回来,然后继续——他认为这条路不好走。更常见的做法是 multi-phase plan(多阶段计划):把大任务拆成 phase 1、2、3、4,每个小块都在 Smart Zone 里完成。但他一针见血:
"Any developer worth their salt will look at this and go: this is a loop."
任何合格的开发者看一眼都会说:这不就是个循环吗?
phase 1、2、3、4 → 何不直接 phase N,在计划外面套一层循环跑到完成为止?这正是 Ralph Wiggum 这个说法的由来——只要指定旅程的终点(一份 PRD),然后让 AI 不断做一点小改动、逐步逼近终点。Matt 的评价是:Ralph 能用,但他想要多一点结构。
Memento 问题:优化"失忆",而不是对抗它
核心观点:LLM 像《记忆碎片》里那个不断失忆的人,与其对抗它的健忘,不如为"每次都从干净状态重来"做优化。
第二个约束更反直觉。Matt 说 LLM 就像电影《Memento(记忆碎片)》里的主角,永远在失忆、永远重置回初始状态。他画了一张图来拆解每个会话的固定阶段:最底层是 system prompt(那个永远待在上下文里的灰盒子)→ 探索阶段(coding agent 在代码库里翻找)→ 实现阶段 → 测试与反馈循环。
关键在于第一层:
"You want this [system prompt] to be as small as possible. If you have 250K tokens in there — like I've seen people do — you go straight into the dumb zone without even being able to do anything."
system prompt 要尽可能小。我见过有人往里塞 25 万 token,那你还没开始干活就已经掉进愚蠢区了。
当你 clear(清空)上下文,就"啪"地回到 system prompt,前面的一切都删掉。而 compact(压缩)则是把整段对话挤进一个更小的空间,生成一份历史记录。很多开发者热爱 compact,Matt 却明确反对:
"Devs love compacting for some reason, but I hate it. I much prefer my AI to behave like the guy from Memento, because this state is always the same."
不知为何开发者都爱压缩,但我讨厌它。我更希望 AI 就像《记忆碎片》里那个人——初始状态永远一模一样。
因为 compact 会留下"沉积物":每次压缩都掺进上一轮的噪声,状态不再干净。为清空(clear)而优化,而不是为压缩(compact)而优化——如果你能做到每次都从同一个干净起点重来,你就处在最佳位置。为此他把 token 状态行当作每次会话的必备信息:实时显示用了多少 token,你才知道自己离 Dumb Zone 还有多远。
Grill Me:和 AI 达成"设计共识"
核心观点:AI 编程最大的隐形杀手是"错位对齐";解决它靠的不是一份计划,而是一场让 AI 反复拷问你、直到双方在同一频率上的对话。
这是 Matt "最贴近内心"的一个 skill,叫 grill-me(把我架在火上烤)。它出奇地小、出奇地简洁,却直击他认为 AI 协作里最核心的问题——misalignment(错位)。
他要正面反对的,是所谓 specs-to-code(规格到代码)运动:先写一份规格文档,把文档丢给 AI 生成代码;代码有问题,不看代码,回去改规格,再生成,如此循环。Matt 说这本质上就是换了个名字的 vibe coding——你在假装代码不重要。
"I tried this, I really tried it, and it sucks. It doesn't work, because you need to keep a handle on the code. The code is your battleground."
这个我真的试过,烂透了,根本行不通。你必须始终抓着代码不放——代码才是你的主战场。
那正确的开局是什么?面对 Sarah Chen 那条 Slack 消息(存在仓库根目录的 clientbrief.md),Matt 不进 plan mode——因为他发现 plan mode 里的 AI 太急着掏出一份计划:"我觉得信息够了,啪,给你个 plan。" 他要的恰恰相反。grill-me 的内容极短,核心就是:
"Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies one by one. For each question, provide your recommended answer. Ask the questions one at a time."
就这个方案的每一个方面,不留情面地盘问我,直到我们达成共识;沿着设计树的每个分支往下走,逐一解决依赖;每个问题都给出你推荐的答案;一次只问一个问题。
Matt 引用了 Frederick P. Brooks 在《The Design of Design》里的 design concept(设计概念):当一群人一起造新东西时,存在一个所有参与者共享的核心想法。这正是他要的:
"I didn't need an asset, I didn't need a plan. I needed to be on the same wavelength as the AI, as my agent."
我要的不是一份产出物,也不是一份计划。我要的是和 AI、和我的 agent 处在同一个频率上。
Claude Code 终端里运行 /grill-me,AI 正在逐个提问
演示中有几个细节很有说服力。首先是 sub-agent(子代理):grill-me 先派出一个 explore 子代理,在 Opus 上烧掉了 93.7K token 去探索代码库,但 Matt 自己主上下文的 token 几乎没涨——子代理有独立的上下文窗口,探索完只把摘要"滴灌"回主 agent。这就是委派的价值。
然后是问题本身的质量。第一个问题是"积分经济:哪些行为得分、得多少",AI 直接给了推荐答案(保持简单、两个积分来源起步,跳过"看视频"这种既嘈杂又容易刷分的事件)。真正精彩的是一个 Matt 自己都没想到的问题:
"Should points be retroactive? There are existing lesson progress records... This is a really nasty question."
积分要追溯吗?已经存在历史学习进度记录了……这是个非常刁钻的问题。
要不要回填所有历史记录——这种问题,如果不对齐就没法把功能做对,而 Sarah Chen 当初根本没考虑。这就是 grilling 的价值:它逼出了需求里那些沉默的、你我都没想到的岔路口。这样的对话可以很长,Matt 说他被问过 40 个、80 个、甚至 100 个问题,能坐着聊一个小时。最后攒下的这段对话历史,本身就是"设计概念"这项资产。他补充,你甚至可以把和领域专家开会的录音喂进 grilling session,让 AI 帮你拷问那些你没意识到的假设。
这里他给出一个贯穿全场的分类:human-in-the-loop(人在环内)任务 vs. AFK(away-from-keyboard,离开键盘)任务。实现可以变成 AFK,但规划、对齐这个阶段必须人在环内,没有例外。
Slido 上观众投票的高赞提问
面对现场 Slido 的提问,Matt 也澄清了几点立场。有人问为什么不用 spec-kit、OpenSpec、Task Master 这些框架,他的回答是 inversion of control(控制反转):
"You should own as much of your planning stack as you possibly can."
你应该尽可能多地掌控自己的规划技术栈。
他见过太多学生过度依赖某个框架,一旦出问题、又对整条链路没有可观测性,就只会说"这玩意儿不行"。而你若拥有整个栈,至少知道怎么去修。至于 Claude 内置的 ask-user-question UI,他直言"坏掉了、很讨厌";他全程用 Claude Code,但也毫不掩饰"我并不怎么喜欢它",强调这套方法你可以自由换任何工具来跑。还有人问 grill-me 是不是更适合 PO 而非开发者,他的回答是:关键决策恰恰需要更多人——你、领域专家、其他开发者和 AI 一起,像 mob programming(群体编程)那样把问题问透。
PRD:目的地文档,写完不用看
核心观点:PRD 只是"目的地"的记录;既然已经和 AI 达成设计共识,读它只是在检验 AI 的摘要能力,所以他根本不读。
grilling 结束时,Matt 用了 25K token,而"这些几乎全是金子"。下一步是把这份设计概念固化成一份 PRD(Product Requirements Document,产品需求文档)。他专门有个 write-a-prd skill:先让用户给一段详尽的问题描述 → 探索仓库 → 再来一轮 grilling → 套进 PRD 模板。模板包含问题陈述、解决方案、一组 user stories(用户故事)、一串实现决策,以及关键的测试决策。
屏幕上的 gamification 需求规格代码
这里藏着一个"深层原因":write-a-prd 会先提出一组它打算改动的模块。Matt 强调,这一步恰恰证明了他不是在做 specs-to-code——整个流程里代码从未离开视野。比如 AI 建议:"gamification service 是唯一有实质逻辑的 deep module,建议给它写测试。" 这种"心里始终装着模块地图"的做法,会一路延续到实现阶段。
他实际工作中用的是 GitHub issues 来承载这些 PRD。他给现场看了自己的"工作仓库" mattpocock/course-video-manager——一个他用来录制视频的应用,录了大约一千个视频,累计 744 个 closed issues,全是 PRD 和实现 issue。
最反直觉的一点来了。生成的这份 PRD(18 条用户故事、若干实现决策),Matt 根本不读:
"What am I testing at this point? I know LLMs are great at summarization. I have reached the same wavelength as the LLM using the grill-me skill — we have a shared design concept. So if I have a shared design concept, all I'm doing is checking the LLM's ability to summarize. So I don't tend to read this."
我读它是在检验什么呢?我知道 LLM 摘要能力很强。我已经通过 grill-me 和它在同一频率上了,我们有共享的设计概念。既然如此,读 PRD 只是在检验它的摘要能力而已——所以我一般不读。
这就是"目的地 vs. 旅程"的分野:PRD 记录的是去哪里(destination),它甚至不需要写得多精炼。有观众问"现在有 100 万 token 了,该用起来吗",Matt 的回答呼应了 Smart Zone:厂商只是"给你运来了更多的 Dumb Zone"。大上下文适合检索(往里塞五本《战争与和平》再捞信息),但不适合写代码;当下的 Smart Zone 大约就是 10 万 token,它会慢慢变大,那会是很好的改进。
Kanban + Vertical Slices:用"追踪弹"切片,而不是排线性计划
核心观点:把 PRD 拆成带阻塞关系的看板,再强制 AI 按"垂直切片"而非"水平分层"来切——这样每一片都能尽早拿到端到端反馈,还能并行。
到了拆分阶段,常规做法是让 AI 给一份多阶段计划。Matt 换了个思路:做成一块 Kanban(看板)——一组带阻塞关系(blocking relationship)的 ticket。演示里 AI 把功能拆成 5 张卡:① schema + gamification service(无前置,标注为 AFK)② streak 追踪 ③ 把积分和连击接入课程/测验完成(被 ① ② 阻塞)④ 历史回填(被 ① 阻塞)⑤ 最后一张(被全部阻塞)。
AFK Multi-Phase Plans:把 PRD 拆成带阻塞关系的看板 ticket
为什么这一步还要人来 review?因为它极快、极便宜,而 Matt 一眼就能看出问题。这里引出全场最实用的技巧之一——来自《程序员修炼之道》的 tracer bullets(追踪弹)/ vertical slices(垂直切片)。系统是分层的:部署单元层面有数据库、API、前端(CDN);单元内部又有各种 service(quiz、team、user、coupon、course),彼此有依赖。而 AI 的默认习惯是:
"AI loves to code horizontally. It codes layer by layer."
AI 特别喜欢横着写——一层一层地写。
phase 1 把所有 schema 写完,phase 2 把所有 API 写完,phase 3 才加前端。问题在哪?
"You don't get feedback on your work until you've completed phase three."
你要到 phase 3 才拿得到反馈。
在此之前根本没有一个能测的、集成起来的系统。正确做法是垂直切片:一片薄薄的、贯穿所有相关层的功能,让 AI 在 phase 1 就能对整条链路拿到反馈。Matt 的 prd-to-issues skill 里明确写着:"用 vertical slices / tracer bullets 把 PRD 拆成可独立领取的 issue。" 追踪弹的比喻很生动:
"A tracer bullet — like an anti-aircraft gunner at night. If you're firing normal bullets you have no idea where they're going. Tracer bullets glow, so every sixth bullet you see a line in the sky — you have feedback on where you're aiming."
追踪弹就像夜里的高射炮手:打普通子弹你根本不知道打哪儿去了;追踪弹会发光,每第六发就在夜空里划出一条线,你就有了瞄准的反馈。
演示里 AI 第一次切片仍然"横着切"——只建了个孤零零的 gamification service。Matt 想看到的第一片垂直切片是:一些 schema 改动 + 一个新 service + 前端上一个最小的呈现。他只回了一句"the first slice is too horizontal(第一片太横向了)",AI 就自己纠正过来,给出:"award points for lesson completion, visible on dashboard(完成课程即得分,并在仪表盘上可见)"——一个漂亮的垂直切片:干了一大堆事,但结尾有看得见的东西,AI 后续可以往上叠加。
这样切出来的是可独立领取的 issue,它们构成一张 DAG(directed acyclic graph,有向无环图):phase 1 先做一张,phase 2 里两张可以被不同 agent 同时领走,phase 3 再收口。
"A sequential plan can really only be picked up by one agent. That's why I prefer a kanban board to a sequential plan."
线性计划只能被一个 agent 领走。这就是我偏爱看板而不是线性计划的原因。
顺带一提,他分享过一个老 tip:在 claude.md 里写 "be extremely concise, sacrifice grammar for the sake of concision(极度精简,为了简洁可以牺牲语法)",让计划读起来更省力。但自从他不再读计划、改用 grilling 之后,这条也被他弃用了——既然不读计划,就不需要它精炼。
Implementation:把实现变成 AFK 循环,交给"夜班"
核心观点:规划全程人在环内(白班),实现则交给循环里的 agent 离开键盘自动跑(夜班)——前面攒下的一切,都是为夜班准备的一队待办。
到实现阶段,人离开循环。Matt 拉出全流程的全景图来复盘:一个 idea → grilling(可跳过 research 和 prototype)→ PRD(目的地)→ Kanban → 实现。前面每一步都由人审阅,到实现这一步,才退后一步、让一个或多个 agent 去把看板做完。
完整工作流全景:Idea → Research → Prototype → PRD → Kanban → Implementation → QA
他用了一个很传神的说法:这是 day shift(白班)与 night shift(夜班)。
"This is the day shift for the human — planning everything, getting all the stuff ready. Then once we kick it over to the night shift, the AI can just work AFK."
这是人类的白班——把一切规划好、准备好;交给夜班之后,AI 就能离开键盘自己干了。
实现的骨架是一个 Ralph 循环。他给看了 once.sh:一个 bash 脚本,把所有 issue(markdown 文件)cat 进一个变量,再抓最近 5 次 commit,拼上 prompt,以 --permission-mode accept-edits 跑 Claude。而完整的 AFK 版本会更复杂,关键是跑在 Docker 沙箱里。once.sh 是"人在环内"的单次版本——反复跑它,观察 agent 的行为,再回去调 prompt。ralph 的 prompt 有自己的一套优先级:关键 bug 修复 → 开发基础设施 → 追踪弹 → 打磨快赢 → 重构;拿到任务后探索仓库 → 用 TDD 完成 → 跑反馈循环。
Matt 很坦诚地回答了几个尖锐问题。"现在是不是要做更多 code review 了?" 是的,而且他没有好答案:实现是唯一的 AFK 环节,产物仍要人来 QA 和 review;可"一个循环实现四个 issue"又和"PR 要小而自包含"这条老规矩天然打架。
"I don't honestly know what the answer to this is yet. I think we just need to be ready to be doing more code review, which is not fun."
老实说我还没有答案。我觉得我们得做好心理准备:code review 会变多——这并不好玩。
前端怎么办?——前端对人眼极其敏感,而 AI 没有眼睛,Playwright MCP、agent browser 这类工具目前"还不太行",在成熟代码库里也造不出好看的前端。他的用法是把它当一次性原型:"给我三个原型放在一条 throwaway 路由上,我点着切换、挑一个最顺眼的",再把这个原型资产喂回 grilling。要不要让 AI 去 QA AI?——可以,而且应该做自动化 review。但有个陷阱:
"If the reviewer reviews in the same context as the implementation, it's reviewing in the dumb zone — the reviewer will be dumber than the thing that implemented it. Clear the context, and you review in the smart zone."
如果 reviewer 和实现共用一个上下文,它是在愚蠢区里审的——reviewer 会比写代码的那个更笨。清空上下文,你才是在聪明区里审。
TDD:AI 编码的质量底线
核心观点:没有反馈循环,AI 永远写不出像样的代码;而 TDD 是让 AI 无法在测试上作弊的那道底线。
Matt 说 TDD(test-driven development,测试驱动开发)对榨干 agent 的价值"绝对必不可少"。仓库里有个 skill 专门教 AI 做 red-green-refactor(红-绿-重构):先写一个失败的测试(确认"红")→ 写实现让它通过(确认"绿")。演示里 AI 正是这样:先用现有工具搭了个测试数据库,测试因为模块还不存在而失败——"confirmed red",随后实现、通过。
TDD 反馈循环:测试与类型检查同时在跑
为什么非 TDD 不可?因为不用 TDD 时,AI 会在测试上作弊:
"It tends to cheat at the tests, because it does it in layers. It'll do the entire implementation, then do the entire test layer just below it."
AI 倾向于在测试上作弊,因为它是分层写的:先把整个实现写完,再在下面补一整层测试。
而 TDD 强制它先给代码埋好探针,再写代码,作弊就难多了。Matt 说他"甚至把整套技术都围着'让 TDD 跑得更顺'来扭曲"。他把这条上升为一句斩钉截铁的判断:
"If your codebase doesn't have feedback loops, you're never ever ever gonna get decent output out of AI. The quality of your feedback loops is the ceiling."
如果你的代码库没有反馈循环,你永远、永远别想从 AI 那里得到像样的产出。反馈循环的质量,就是天花板。
如果 AI 输出很差,往往要去提升反馈循环的质量,而不是换 prompt。演示中这个仓库最后攒到 284 个测试。但测试不是全部:Matt 亲自以学生 Emma Wilson 身份登录、点"完成课程",结果报了个 sqlite 错误(缺 point_events 表,需要跑迁移)。这正是手动 QA 的意义所在——
"QA is how I impose my opinions back onto the codebase, how I impose my taste."
QA 是我把自己的判断、把我的品味,重新压回代码库的方式。
他警告说,那些试图把一切(想法、QA、研究、原型)都自动化的团队,最后做出的是"缺乏品味、甚至根本跑不通的 app",只会得到 slop(粗制滥造)。QA 阶段其实还藏着一个功能:为看板生成更多 issue——你可以边实现边 QA,把新发现的问题作为阻塞 issue 无限往看板里加。
Deep Modules vs Shallow Modules:AI 友好的代码架构
核心观点:AI 在"浅模块"堆成的代码库里寸步难行;把系统重构成"深模块",既让 AI 更能干,也让你只需设计接口、把实现放心委派出去。
想让 AI 在你的代码库里干得好,代码库本身得对 AI 友好。Matt 搬出 John Ousterhout 的《A Philosophy of Software Design》里的 deep modules(深模块)vs. shallow modules(浅模块)。
Agent 正在探索代码库架构,寻找可加深的模块
浅模块是一堆小文件、各自导出一点点东西、彼此依赖交错。这对 AI 很不友好:它搞不清楚满图的依赖关系,得手动一条条追;测试边界也没法画——是把每个小函数各包一个测试边界(于是产出一堆彼此 mock 的烂测试),还是把一大坨相关模块囫囵测在一起、祈祷它们能协同?深模块则相反:对外只暴露一个小而简单的接口,内部藏着大量功能。它好测(在单个模块外面画一个大测试边界,就能覆盖大量逻辑),对调用者也友好(接口简单)。
问题是,没人盯着的话,AI 默认会写出浅模块那种代码库。于是有了 improve-codebase-architecture skill——扫描代码库,寻找可以"加深"的地方。演示里它跑出的结果很具体:quiz scoring service 目前零测试、是最大的缺口,还识别出可抽取的排序逻辑、给出耦合理由和依赖分类。Matt 说这是他"如果今天只能带走一样东西"的推荐:
"Just try running this skill on your repo and see what happens. AI working on a video editor is pretty brutal if you don't give it good tests."
就在你的仓库上跑一下这个 skill,看看会发生什么。
他举了自己的例子:course-video-manager 里有个浏览器端的视频编辑器,工程难度很高。他用这个 skill,靠一个判别联合(discriminated union)把从前端一路到后端包成一个巨大的可测模块,AI 于是能看见、能操作、能测试整条链路,效果"天差地别"。
深模块还带来一个"心理小把戏",也是 Matt 对"如何在快节奏下仍不失去对代码库的掌控"给出的答案:
"Design the interface for these modules, but then delegate the implementation."
设计模块的接口,但把实现委派出去。
模块成了灰盒子:你只需知道它的形状、它在什么条件下有什么行为,内部实现不必全部 code review、不必样样都懂。你保有对代码库整体形状的把握,同时把内部实现委派掉——既跑得快,又保住理智。
关于要不要留下这些 PRD / 计划 markdown,Matt 的态度是"倾向于扔掉"。他最怕 doc rot(文档腐烂):一个月后代码早已面目全非,AI 却翻出那份陈旧 PRD 奉为圭臬,反而被带偏。因为他用 GitHub issues,直接标记 closed 即可——有"已完成"的视觉标记,需要时也能拉回来看。
Sandcastle:并行 Agent 编排
核心观点:把顺序的 Ralph 循环升级成并行流水线——planner 排相位、多个 implementer 在沙箱里并行、reviewer 审、merger 合,并给实现和审查配不同档位的模型。
Matt 花了大约一周做了个叫 Sandcastle 的 TypeScript 库,因为他对现有的 AFK agent 运行方案都不满意。它的核心是一个 run 函数:创建 work tree、在 Docker 容器里沙箱化、在里面跑一个 prompt;work tree 就是一个 git 分支,之后可以 merge。
main.ts 把前面那个顺序 Ralph 循环升级成了并行流水线:
- planner:看 backlog,根据阻塞关系算出各个相位(phase),挑出一批可并行的 issue;
- 对每个 issue 创建一个沙箱,跑一个 implementer(传入 issue 编号、标题、分支);
- 若产生了 commit,就 review 这些 commit;
- 最后交给 merger:合并各分支,顺手解决类型和测试上的冲突。
一个关键的模型分工是:
"I'm using Sonnet for implementation and Opus for reviewing. I consider reviewing... I need the smarts then."
实现我用 Sonnet,审查用 Opus——审查这一步我需要更强的脑子。
这套 planner → implementer → reviewer → merger 的流水线,是 Matt 长期以来做多数项目的主力工作流。
Push vs Pull:编码标准的双向策略
核心观点:同样是"让 AI 按你的规矩写代码",对实现者用"拉"、对审查者用"推"——方向选错,标准要么被忽略,要么白白挤占上下文。
如何在 agent 上强制执行编码标准?Matt 给了一个清晰的二分:push(推)与 pull(拉)。
VS Code 里 mattpocock/skills 的 skill 目录
- Push:把指令直接推给 LLM。比如在
claude.md里写"像海盗一样说话",这条会永远随每次请求发过去——你在往它上下文里推 token。 - Pull:给 agent 一个按需拉取更多信息的机会。skill 就是典型:它带一个描述头,告诉 agent"需要时你可以来拉我"。
他当前关于 code review 和编码标准的思路是:
"In the reviewer I would push the coding standards. In the implementer I would allow it to pull."
对 reviewer,我会推编码标准;对 implementer,我允许它拉。
对实现者用 pull——它有疑问时能自己去查(比如翻 skill);对自动化审查者用 push——把编码标准连同待审代码一起推给它,让它有明确的对照基准去逐条核对。这也正好和 Sandcastle 里"Sonnet 实现 + Opus 审查"的分工咬合在一起。
不是 Spec-to-Code,是软件工程基本功
核心观点:这套流程是对 vibe coding 的反命题——烂代码库喂出烂 agent,把一切自动化会做出"没有品味"的应用;真正的杠杆,是那些二十年前的老书里早就写清楚的东西。
收尾时,Matt 把整场串了起来:这不是一个"规格进、代码出"的编译器,不是那种只管吐代码的 AI。整个流程里,代码库的形状始终在脑子里——你对要动哪些模块、代码库长成什么样,都非常刻意。你靠 grilling session 把想法锤到最对齐;你不过度打磨 PRD、不逐字去读它;你把它切成可并行的 issue,实现,然后把 QA 和 code review 做到极致,再不断回到实现。
他反复回到的那句判断,是整场的地基:
"Bad codebases make bad agents. If you have a garbage codebase, you're going to get garbage out of the agent working in it."
烂代码库喂出烂 agent。代码库是垃圾,在里面干活的 agent 吐出来的也是垃圾。
以及对"全自动化"团队的警告:把想法、QA、研究、原型统统自动化,最后只会得到"缺乏品味"的 app——没有人的触碰,产出的就是 slop。QA 之所以不能省,正因为它是人把品味重新压回代码库的那一刻。
而最后一条建议,朴素得出人意料:
"Head to Amazon and just buy a ton of those old software engineering books. On every single page I found something useful. We're really trying to verbalize best software practices in English — and these 20-year-old books have already done that. It's an absolute gold mine for prompts."
去亚马逊,把那些老软件工程书成堆地买回来。我几乎在每一页上都找到有用的东西。我们如今拼命想用英语把最佳实践讲清楚,而这些二十年前的书早就讲清楚了——拿来塞进 prompt,是绝对的富矿。
从 Smart Zone 到追踪弹,从 TDD 到深模块,Matt 这套工作流没有一件是 AI 时代的发明。它们是 Brooks、Ousterhout、《程序员修炼之道》里的老功夫,只是被重新对准了一个新的协作者。AI 换了新范式,但让软件真正落地的那套基本功,一点没变。
来源
- 演讲:Matt Pocock,《Full Walkthrough: Workflow for AI Coding》,AI Engineer Europe 2026(2026 年 4 月 8 日,伦敦)
- 完整视频(96 分钟):youtube.com/watch?v=-QFHIoCo-Ko
- Matt Pocock 宣布精简版的推文:x.com/mattpocockuk/status/2075218406266036236
- 讲者:@mattpocockuk · aihero.dev · github.com/mattpocock
本文基于 Matt Pocock 在 AI Engineer Europe 2026 的 workshop《Full Walkthrough: Workflow for AI Coding》完整视频整理，对口语做了结构化编排，尽量保留讲者原话的语气与英文原文。完整内容请观看原视频。
视频观看：YouTube · AI Engineer
