著名技术导师 Matt Pocock 访谈：AI时代软件工程进阶指南 把 AI 当“严厉的架构师”而不是打字机

当大模型写代码的速度比人类快上百倍时，软件工程面临的挑战不再只是写不出代码，而是可能快速制造出难以维护的「代码大泥球」。面对这种情况，关键是不要让 AI 直接替你做主，而是让模型像架构师一样促使你把设计和方案想清楚。模型需要人把目标与判断标准传达给它，做决定的始终是工程师自己。

TypeScript 教育者 Matt Pocock 曾凭借 Total TypeScript 课程创下超过 250 万美元的销售额。但在大模型能力提升后，单纯讲解语法与实现细节的战术知识吸引力明显下滑。然而，当开发者尝试把真实业务交给自动化 Agent 时，往往容易遇到问题：模型容易曲解意图、臆造权限逻辑、堆砌同义反复的无效测试，甚至在上下文膨胀后破坏既有架构。

Matt 自己的转型历程正是这种变化的缩影。在投身软件行业前，他做了六年声乐老师；为了能在乡下远程工作，他自学编程入行，写的第一个作品是给学生分析嗓音频谱与共振峰的网页工具。他入行的优势在于多年教学练出的沟通能力：能把技术原理讲明白，晋升很快。这也是他后来做教学以及注重「如何向 Agent 表达意图」的基础。后来他全职做开发，并凭借 Total TypeScript 课程被广泛认知。随着大模型能力提升，单纯教授语法细节的课程收入明显下滑。他曾尝试转向制作「如何把 AI 接进应用」的课程，但收益未达预期。直到去年底假期试用前沿模型后，他根据自己的体验判断，模型的能力已经足够接手大部分局部的具体编码，开发者可以把更多精力放在系统设计与全局架构上。

完整节目可以在 YouTube 观看：The Pragmatic Engineer《AI Skills with Matt Pocock》，1 小时 36 分，可开自动字幕。下文各节附有配好中英字幕的精华片段。

为了解决这些失效模式，Matt Pocock 梳理出了一套开源技能库 mattpocock/skills，在 GitHub 上已超过 26 万星。这套方案并没有发明某种全新的「AI 原生理论」，而是将《程序员修炼之道》《软件设计哲学》《领域驱动设计》等经典软件工程著作中的核心原则，转化为能够约束和激发模型的具体工作流。

这套技能库主要解决什么

• 动手前把需求问清楚：grill-me 让 Agent 先追问业务取舍和架构决定，避免它自行填补关键假设。
• 把讨论沉淀成可执行任务：to-spec 将决定整理为规约，to-tickets 再拆成能在单个上下文窗口内完成的垂直工单。
• 管理跨会话的大型项目：wayfinder 用地图、依赖关系和战争迷雾记录已经确定与尚未确定的工作，让新会话能够接着推进。
• 用真实反馈约束实现：实现技能要求先建立会失败的测试，再写代码并检查回归，减少同义反复的无效测试。
• 持续改善代码库结构：架构检查技能寻找浅模块、重复概念和不断增加的理解成本，把可执行的重构建议转成日常工单。

战术交给 Agent，战略留给人：为什么「智慧」反而没有变得更好学？

在 Matt 看来，AI 正在重塑软件工程中不同技能的相对价值。在日常教学中，编程可以拆分为两层：一层是语法细节与具体实现的「知识」（the what），另一层是探究设计原因与权衡的「智慧」（the why）。如今查阅具体语法的门槛大幅降低，但系统层面的工程思考并没有变得更容易——缺乏架构判断依然会遇到设计瓶颈。Matt 借用斯坦福大学教授 John Ousterhout 在《软件设计哲学》中的分野指出：专注于局部实现的「战术编程」（Tactical Programming）越来越适合交由模型辅助，而开发者需要把重心放在关注全局与系统演进的「战略编程」（Strategic Programming）上。

战略编程往往更难掌握，原因在于它的反馈周期很长。如果在一家公司只工作几个月就离开，早期的架构缺陷可能很久之后才会暴露。Matt 把战略编程比作调音台上的推子——例如一个推子代表「可部署单元数量」，推高是拆成微服务，推低是合并为单体。做架构决策类似调音，往往要等很长时间系统遇到瓶颈，才能验证当初的选择是否合理。在 Matt 看来，AI 提升了编码和验证的速度，客观上也加快了暴露设计缺陷的节奏，让战略层面的反馈周期缩短。

在 Matt 的工作流中，代码本身是 Agent 工作的环境，工程师的核心工作是维护和优化这个环境。下文的三道防线，是他针对战略编程总结出的具体做法——第一步就是在需求阶段通过提问把模糊决策理清。

从 Ralph 循环到有限状态机：技能到底是什么，又是如何诞生的？

确立分工后，Matt 把「让 AI 促使开发者做决定」整理成了一套可安装的技能。这套方法的雏形来自 Geoffrey Huntley 提出的「Ralph 循环」。传统做法常让模型先制定宏观计划再逐步落地，但 Agent 在编码遇到新情况时计划容易变形。Ralph 循环的做法是：给 Agent 设定明确目标，每次只执行离目标最近的一小步，随后清空上下文重置；系统状态保存在代码和本地文件（如 Markdown 清单）中，不依赖模型单次会话中的记忆。此前做应用集成的经验，让 Matt 更加关注上下文的数据结构、优先级以及清空时机。在他看来，这些执行循环本质上是由状态与事件驱动的流程，与他在 XState 中使用的有限状态机（Finite State Machine）原理相通。

在把自制状态循环应用到视频剪辑器等项目后，Matt 发现切回默认环境时效果会有落差。为了复用这些流程，他借用了工具生态中的载体——技能（Skills）。技能的形式很直观：本质上是一个包含若干 Markdown 文件的本地目录，安装后可通过斜杠命令在终端或对话中调用。这类技能在机制上分为两类：一类由模型根据上下文自主触发（Model-invoked），另一类由用户手动触发（User-invoked），grill-me 便属于后者。

看到社区中出现 Superpowers、Claude Code 插件以及 Garry Tan 的 GStack 等技能集后，Matt 将自己的工作流整理开源，该仓库随后成为他获星最多的开源项目，他也受邀在 AI Engineer 大会上以此为题发表演讲。在编写技能时，Matt 的原则是保持简明，便于人工阅读和检查。面对差异较大的实际业务，现成工作流很难直接适用所有场景；逻辑清晰直接，开发者才更容易按需修改和引入项目。

第一道防线：把 AI 当严厉的架构师，用设计树一轮轮拷问你

使用代码 Agent 时，常见的问题是预设模型能理解开发者的意图和权衡。如果只输入「帮我实现某个功能」，模型为了尽快输出结果，往往会自行推测未说明的细节，可能做出不合适的鉴权方式或数据结构选择。

应对方法是不让 Agent 立即写代码，而是让它向开发者反向提问确认需求（Grilling）。主持人 Gergely 尝试过：做一个简单的「邮件订阅校验接口」，被连续追问了 35 个工程细节：鉴权 Token 放在 Header 还是请求体？每天 1000 次的频率限制，是否严格卡在第 1000 次？

grill-me 的设计灵感来自 Claude Code 团队成员 Thariq 的建议：「让 Agent 在动手前先全面采访你」。固化为技能后，模型不仅能排查逻辑漏洞，有时还能提出不同的设计视角。Matt 提到，这种连续提问让他联想到早年工作中有经验的架构师追问方案的场景。虽然最终决策由开发者做出，但提问过程能暴露出未曾深思的技术盲区，促使人查阅资料并理顺逻辑。主持人 Gergely 认为，人机协作的关键在于保持开发者的主动思考；如果连对系统的理解也完全外包给模型，后续就容易积累维护隐患。

这套机制在底层将所有待确定的决策抽象为一棵设计树（Design Tree）。每一个父级决定的落定，都会解锁一批悬挂在下方的子问题。前置条件都已落定、眼下就能问的那批问题，叫作「前沿」。

在每一轮交互中，Agent 会将查证客观事实与提出决策问题区分开。如果一个问题依赖代码库中现有的文件结构、数据库字段或工具配置，Agent 会派子 Agent 自行查找，而不是把可通过工具获知的事实抛给开发者。只有涉及业务取舍或架构权衡的问题，才会列入本轮问题清单。

提问也有明确规范：把所有前置条件已满足的问题合并在同一轮提出，每个问题附带推荐答案，随后等待开发者回复。每次回答后重新计算设计树前沿，直到没有未明确的假设，提问流程才算结束。在前期把需求与判断标准对齐，有助于降低后续返工的成本。