96 分钟 Workshop · 15 个核心判断

Matt Pocock:
从一句 Slack 消息到可交付代码

AI Engineer Europe 2026 · 伦敦 · 近两小时 AI 编程工作流实录
YouTube · 完整实录 →

🎯 Matt Pocock
💻 TypeScript Educator
🏗️ 160K ⭐ Skills Repo
🎤 AIE EU 2026
🧠 上下文的物理学
1
技术
"Every time you add a token to an LLM it's kind of like adding a team to a football league... it scales quadratically."
上下文不是越大越好。每个 token 都要和其它所有 token 建立注意力关系,token 越多,关系数量呈平方级膨胀——于是无论 20 万还是 100 万的 context window,塞满了都会变慢、变笨。
2
犀利
"Around a hundred K is my new marker... it just starts to get dumber and dumber until it's making stupid decisions."
大约 10 万 token 是 Matt 现在的"变笨"分水岭。这是 HumanLayer 的 Dex Horthy 提出的 Smart Zone / Dumb Zone 框架:刚开新对话、上下文最干净时模型最聪明,所以任务必须切到能塞进"聪明区"的大小。
3
犀利
"Devs love compacting for some reason, but I hate it. I much prefer my AI to behave like the guy from Memento."
别对抗 LLM 的"失忆",为它优化。compact(压缩)会掺进上一轮的"沉积物",状态不再干净;clear(清空)才能每次回到同一个干净起点——像《记忆碎片》主角一样,初始状态永远一模一样。为清空而优化,不为压缩而优化。
🎯 对齐才是主战场
4
犀利
"I tried this, I really tried it, and it sucks... you need to keep a handle on the code. The code is your battleground."
他正面反对 specs-to-code:写规格 → 生成代码 → 不看代码 → 改规格 → 再生成。那本质上是换了名字的 vibe coding——你在假装代码不重要。代码才是主战场,你必须始终抓着它不放。
5
洞察
"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."
grill-me(把我架在火上烤)是他最贴近内心的 skill:让 AI 沿着设计树逐个分支盘问你,一次只问一个,每个问题都给推荐答案。它甚至逼出了"积分要不要追溯历史记录"这种连需求方 Sarah Chen 都没想到的刁钻岔路口。
Claude Code 终端里运行 /grill-me,AI 正在逐个提问
6
犀利
"All I'm doing is checking the LLM's ability to summarize. So I don't tend to read this."
生成的 PRD(18 条用户故事)他根本不读。因为已通过 grilling 和 AI 达成"共享的设计概念",PRD 只是"目的地"的记录——读它只是在检验 AI 的摘要能力。这就是"目的地 vs 旅程"的分野。
🔀 垂直切片、看板与夜班
7
技术
"AI loves to code horizontally. It codes layer by layer. You don't get feedback until you've completed phase three."
AI 默认横着写:phase 1 写完所有 schema,phase 2 写完所有 API,phase 3 才加前端——到那时才第一次拿到反馈。正解是"垂直切片 / 追踪弹":一片薄薄地贯穿所有层,第一片就能对整条链路拿到端到端反馈。
8
流程
"A sequential plan can really only be picked up by one agent. That's why I prefer a kanban board to a sequential plan."
把 PRD 拆成带阻塞关系的看板 ticket,而不是线性计划。看板构成一张 DAG:phase 2 里两张卡可以被不同 agent 同时领走——线性计划只能被一个 agent 干。
把 PRD 拆成带阻塞关系的看板 ticket
9
流程
"This is the day shift for the human — planning everything... once we kick it over to the night shift, the AI can just work AFK."
规划全程"人在环内"(白班):idea → grilling → PRD → Kanban,每一步人都审。实现才交给"夜班"——一个或多个 agent 在 Ralph 循环里离开键盘自动跑。前面攒下的一切,都是为夜班准备的一队待办。
完整工作流全景:Idea → Research → Prototype → PRD → Kanban → Implementation → QA
🔁 反馈循环是天花板
10
犀利
"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 输出差,往往要去提升反馈循环的质量,而不是换 prompt。反馈循环的质量,就是天花板。
11
技术
"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."
为什么非 TDD 不可:不用 TDD 时 AI 会在测试上作弊——先写完整实现,再补一层"配合"它的测试。TDD 强制它先埋好失败的探针(confirmed red)再写代码,作弊就难多了。这个仓库最后攒到 284 个测试。
12
洞察
"QA is how I impose my opinions back onto the codebase, how I impose my taste."
测试不是全部。Matt 亲自以学生身份登录、点"完成课程",撞出一个 sqlite 迁移错误。把想法、QA、研究全自动化的团队,最后只会得到"没有品味、甚至跑不通的 app"——slop。
🏛️ 架构、编排与老功夫
13
流程

Reviewer → Push

  • 把编码标准直接推给它
  • 连同待审代码塞进上下文
  • 有明确基准逐条核对
  • 配 Opus,审查要更强的脑子

Implementer → Pull

  • 给它按需拉取的机会
  • 有疑问时自己去翻 skill
  • 不长期挤占上下文 token
  • 配 Sonnet,实现主力
"In the reviewer I would push the coding standards. In the implementer I would allow it to pull."
同样是"让 AI 按你的规矩写代码",方向要选对:push 永远随每次请求发送(往上下文推 token),pull 让 agent 需要时自己来取(skill 就是典型)。这正好和 Sandcastle 里"Sonnet 实现 + Opus 审查"的分工咬合。
14
洞察
"Design the interface for these modules, but then delegate the implementation."
深模块 vs 浅模块(Ousterhout)。浅模块一堆小文件、依赖交错,AI 寸步难行;深模块对外只暴露一个简单接口、内部藏大量功能,好测又好用。你只设计接口、把实现委派出去——既跑得快,又保住对代码库整体形状的掌控。
15
犀利
"Bad codebases make bad agents. If you have a garbage codebase, you're going to get garbage out of the agent working in it."
全场地基。想让 AI 干得好,代码库本身得对 AI 友好。而最后一条建议朴素得出人意料:去亚马逊把那些二十年前的老软件工程书成堆买回来——"几乎每一页都有用,是塞进 prompt 的绝对富矿"。

从 Smart Zone 到追踪弹,从 TDD 到深模块,
这套工作流没有一件是 AI 时代的发明。
AI 换了新范式,
但让软件真正落地的那套基本功,一点没变。