Matt Pocock：AI 编程越快，越需要工程基本功

原始视频：AI Skills with Matt Pocock

The Pragmatic Engineer · 2026-09-17 · 96 分 36 秒

主持：Gergely Orosz · 嘉宾：Matt Pocock，Total TypeScript 与 AI Hero 创作者

补充一手资料：节目官网与文字稿 · Matt 的 Skills 仓库

本文依据完整英文自动字幕整理，并与发布方文字稿交叉核对。文中时间链接对应原始视频，嘉宾的经验判断保留其适用范围。

Gergely Orosz 想做一个很小的接口：外部活动拿着授权凭证，查询某个邮箱是否属于付费订阅者，方便给订阅者优先参与资格。

他调用 Matt Pocock 的 grill-me，结果被问了 35 个问题。身份怎么验证，凭证放在哪里，请求如何限流，额度是否必须严格卡住，每一个看似可以随手决定的细节都被摆到了桌面上。

Orosz 觉得烦，也承认自己很久没有经历过这么细的设计讨论。最有用的部分是，重要决定重新经过了他的思考。

这段经历贯穿了整场访谈。AI 可以快速生成代码，工程师仍要把目标说清楚，判断结果是否可信，并维护下一次修改所依赖的环境。 Matt 正在把这些工作写成一组小而可修改的 Skill。

知识更便宜了，判断仍然需要练习

Matt 做过 6 年声音教练，教唱歌、口音、莎士比亚台词，也给咨询公司做过公众表达培训。他希望离开伦敦，找到可以远程完成的工作，于是开始自学 JavaScript，并为学生制作练习工具，包括一个运行得并不理想的声音频谱分析应用。

大约在 2017 年，他进入软件行业。后来，他参与 XState 开源项目，在 Stately 工作，又加入 Vercel。沟通和教学经验没有被丢掉，它们成为他解释技术、制作课程的基础。

加入 Vercel 时，他争取到每周工作 3 天的合同，把其他工作日留给 Total TypeScript。课程预售获得足够强的反馈后，他才决定全职做教育。节目提到的累计收入里程碑是 2,500,000 美元，这是分成和费用扣除前的课程收入，不能当成他的个人净利润。

AI 出现后，这门课程的收入下降了。他没有给出具体降幅，但承认市场对语法知识的需求发生了变化。

他的解释是，技术教育同时传递两种东西：怎样写，以及为什么这样写。前者可以快速查询，也越来越容易交给模型；后者涉及取舍、约束和长期后果，仍要靠实践形成判断。

借用 John Ousterhout 对战术性编程与战略性编程的区分，Matt 认为 AI 已经能承担大量具体实现，人需要更关注软件长期怎样演变。这是他的工作判断，访谈没有提供足以证明所有工程任务都能自动化的测试。

grill-me 先补上人与 Agent 的沟通缺口

Matt 在介绍 Skill 的段落里反复强调，模型再聪明，也不知道使用者脑中没有说出口的优先级。

一个需求里可能藏着很多默认条件：哪些用户可以调用，什么延迟可以接受，哪些功能暂时不做，是否值得为了边界情况增加复杂度。Agent 若直接开始写代码，就会替人填上这些空白。

grill-me 把这个过程提前。它让 Agent 持续追问，直到目标、范围和关键选择变得明确。Matt 将灵感归功于 Anthropic 的 Thariq Shihipar：让模型采访使用者，往往比让使用者一次写完所有要求更有效。

Orosz 的订阅查询接口就是例子。讨论鉴权和限流时，他可以决定接受哪种复杂度，也可以先补充自己缺少的知识。模型负责把问题暴露出来，判断仍然经过人。

Matt 说，访谈时他的 Skills 仓库已经约有 230,000 个星标，一场相关演讲约有 1,200,000 次播放。这些是他当时给出的传播数据，不能证明 Skill 带来了同等幅度的生产率提升。

他对 Skill 的设计要求倒很明确：足够小，容易看懂，方便使用者修改和组合。流程只有能被理解，出问题时才有机会被修正。

用规格和工单，把长任务分进多个会话

需求说清楚以后，接下来是怎样让 Agent 完成足够大的工作。

在上下文讨论中，Matt 沿用了 Dex Horthy 的“聪明区”和“迟钝区”说法。对话不断增长，旧讨论、无关文件和失败尝试会争夺注意力，模型更容易漏掉关键联系。

他把当时前沿模型较可靠的工作区间粗略估在前 150,000 个 token 左右。这个数字是个人经验估计，不能当成所有模型通用的性能阈值；能装进上下文，也不等于能同样可靠地使用。

他的做法是把信息分成两层。规格文档说明最终要达到什么状态，以及怎样判断完成；工单说明当前会话要解决哪一小块工作。一个规格可以拆成 30 到 40 张工单，每次实现只拿当前需要的信息。

会话清空以后，代码、文档和任务状态仍然保存在外部。后续 Agent 从这些已经整理过的材料继续工作，减少对漫长聊天记录的依赖。

他把这种节奏称为白班与夜班：人集中处理规划和判断，Agent 获得一段连续执行时间，随后再由人检查。重点在于减少来回切终端和频繁打断，让委派真正腾出注意力。

Wayfinder 为复杂决策保留一张地图

如果连需求讨论都装不进一个会话，就需要拆分规划本身。

Wayfinder 用一张共享地图保存目标、已作出的决定、决策之间的依赖，以及暂时看不清的问题。每次会话处理一个节点，结果回写地图，再决定下一步。

节点可以是一轮追问，也可以是查资料、做原型或准备基础设施。Matt 说，他用过包含 50 到 100 张工单的地图，还把同样的方法用于课程设计和花园办公室的规划。这些是个人使用案例。

地图的价值在于允许未知继续存在。还没验证的想法可以先标出来，等研究或原型提供证据，再更新路线。规格因此会吸收探索结果。

Matt 同时明确反对每个改动都先长谈一轮。他根据做错后修正的成本选择流程：

他也会在确定规格前大量做原型，比较不同方案。规划与试做可以交替进行，流程的重量应当跟着问题变化。

经典工程词汇，可以缩短人与模型的距离

Matt 曾尝试持续修改规格，让 Agent 跟着重写实现，结果发现代码越来越难维护。糟糕的测试还会持续向 Agent 提供错误反馈。

重新读《程序员修炼之道》后，他开始用书中的概念描述希望 Agent 怎样工作。访谈中的具体例子是 tracer bullet，可以理解为先贯通一条最小但真实可运行的路径。

过去，Agent 往往先建完整数据库层，再建应用层和前端组件，最后才连接起来。接口和数据模型不合适的问题，到很晚才暴露。

按纵向切片推进时，数据库、业务逻辑和界面各完成一小部分，先让它们一起运行。反馈更早出现，后面的实现可以建立在已经验证过的连接上。

Matt 发现，tracer bullet、vertical slice、deep module 这些有明确工程含义的词，会改变模型处理任务的方式。他称它们为 leading words。访谈将此解释为可能唤起模型已有的概念联系，但没有验证具体训练数据，也没有提供受控实验。

他还从 Eric Evans 的领域驱动设计中借来统一语言的思路。在自己的课程管理应用里，一节尚未实体化的课程内容变为真实文件时，其所属章节和课程也要一起转成真实状态。他和 Agent 给这组关联行为起名为 materialization cascade，即实体化级联。

以后讨论这个行为，就可以直接使用同一个名称。grill-with-docs 把这种命名和记录融进需求讨论，文档、代码与人的表达逐渐对齐。

术语的价值来自共同定义。一个名字对应一组清楚的行为，才真正减少了反复解释。

把代码库整理成新同事也能工作的环境

Matt 用电影《记忆碎片》做比喻：一个每天醒来都忘记昨天的人，需要怎样的工作环境？

长期参与项目的人，可能记得某个模块为什么奇怪、某条测试为什么经常失败。新启动的 Agent 会话通常没有这些默认知识；即便产品提供记忆功能，也需要有人保存并提供相关上下文。

清楚的命名、合理的模块边界、可信的测试和有出处的设计决定，可以减少每次接手时的重新摸索。代码库也就成为 Agent 能否持续工作的环境。

Matt 对软件任务相对适合 Agent 的解释，是输入与反馈经常能用文本表达：源码、文档、类型错误、测试失败和检查结果都可以被读取，再用于下一轮修正。

界面交互里的细腻问题更难处理。悬停时动画是否自然、操作是否符合预期，需要实际观察。这里保留的是他对当时工具的使用经验，不能据此断言所有视觉模型都无法做好界面工作。

从这些例子可以归纳出一个设计要求：除了给 Agent 一项任务，还要给它看见失败、理解失败并再次尝试的条件。

TDD 可以讨论，证明改动有效不能省略

Matt 在谈 TDD 时保留了两种同时存在的态度：他仍然推荐测试驱动开发，也开始怀疑是否每一步都要严格复制人类的工作节奏。

先写失败测试，再实现，再重构，对容易被打断的人很有帮助。失败测试能提醒人工作进行到了哪里。Agent 的单次工作记忆更大，他因此觉得这种节奏的一部分价值需要重新讨论。

不过，他没有放弃测试。他更频繁地要求 Agent 提供证据：这次改动确实产生了预期行为，而且拿掉改动之后，相应检查会失败。

这个要求比“所有测试都绿了”更具体。如果测试只是把实现复制一遍，例如定义一个常量，再检查它等于刚写下的值，那么测试通过也没有证明用户需要的行为。

Matt 会让实现 Agent 之后再接一个审查 Agent，寻找这类无效测试和代码质量问题。但他随即提出另一个问题：谁来判断审查 Agent 做得好不好？

自动审查增加了一层反馈，并没有消除验收责任。完成一次生成之后，仍要检查软件怎样运行，以及验证方法究竟能发现什么错误。

团队要共享流程，也要观察失败

Matt 建议团队记录 Agent 做了什么、哪些任务成功、哪些失败，比较不同仓库和不同工作流程的效果，再把有效经验写回共享 Skill。

这些是他提出的改进方法，访谈没有给出团队采用后的对照数据。它们至少让讨论有了更具体的对象：一次失败来自需求不清、上下文混乱、环境问题，还是检查方法不可靠。

他也在转向远程 Agent。来录制节目的火车上，他通过 Discord 与 Hetzner 服务器上的 Agent 沟通，修改课程工具、处理学生反馈。机器保持在线，就能继续执行任务和运行定时工作。

他更看重团队协作的可能性：同事可以进入同一段讨论，理解已经作出的决定，并继续处理问题。把流程藏在每个人自己的终端里，会增加这种协作的难度。

讨论也保留了现实限制。复杂本地环境能否复现、前端反馈是否及时、网络延迟是否影响体验，都会改变选择。Matt 描述的是自己的迁移方向。

初学者需要练习取舍，教师需要安排学习路径

战略判断难学，是因为后果往往来得很晚。某个拆分决定当下看起来合理，可能等系统演化很久以后才成为负担。生成代码更快，并不会自动缩短所有这类反馈周期。

因此，Matt 没有为初级工程师怎样获得长期经验给出一个完整答案。他在给初学者的建议中强调，多用这些工具做真实项目，同时保持对代码和生产过程的好奇。

需求追问可以成为学习机会。一个人发现自己解释不清鉴权选择、数据关系或测试目的时，就有了具体的学习问题。关键在于参与判断，并追踪判断的后果。

这也解释了他为什么仍然看重教师。知识像一张存在前后依赖的图，教学要把它整理成适合学习者前进的路线：先理解什么，再练习什么，哪些误解需要提前处理。

模型能提供大量解释，课程的组织和取舍仍然有价值。Matt 从 TypeScript 语法教学转向 AI 工作方式，也是把自己的教学重心移到了这一层。

工程师的另一项工作，是照料 Agent 的工作环境

访谈末尾，两人谈到代码库里的“园丁”：有人持续观察新增改动，发现杂乱的依赖、逐渐失效的规则和越来越难修改的模块，在问题扩大之前处理它们。

Matt 把工程师比作 Agent 的平台团队。人除了安排下一项功能，还要维护它执行任务的环境，决定哪些反馈可信，哪些流程值得复用，哪些捷径会留下长期成本。

他推荐的阅读材料也沿着同一方向展开：《程序员修炼之道》帮助理解反馈与软件熵，John Ousterhout 的《软件设计哲学》讨论复杂度和模块设计，Eric Evans 的《领域驱动设计》前面的章节帮助建立共同语言。

从这场访谈可以提炼出的实践顺序是：先根据任务大小决定需要多少讨论，把已经明确的目标和决定留下记录，让实现尽早接受反馈，再用真实行为检查结果，持续整理代码库和工作流程。

AI 扩大了代码生成的速度，也扩大了坏决定被重复执行的速度。Skill 能保存工程经验，它的价值最终要在后续修改是否更容易、错误是否更早被发现、团队是否更理解自己的系统上得到检验。