与 Matt Pocock 聊 AI 技能:当智能体吃掉战术编程

进入软件行业以前，Matt Pocock 多年教授发声、唱歌与公开表达。他为学生制作工具，包括一个很有野心、但运行很慢的声音分析应用，这段经历帮助他走向能够在伦敦之外从事的职业。

他的工程经历包括代理公司、TypeScript、XState 和 Stately，之后在测试课程生意时短暂兼职于 Vercel。他把 Total TypeScript 的成功描述为一种更有持续价值、也能多陪家人的工作方式。访谈中的收入是有合作分成和费用的业务总收入，不是个人到手收入。

这段背景很重要，因为教学与解释始终居于中心。后来的 AI 技能，是尝试把过程表达到足够清楚，让别人可以检查、修改和使用，而不是分发一块看不懂的自动化。

Pocock 区分了教人写什么，与教人理解为什么这样设计。他认为 AI 降低了获得语法和战术知识的成本，而较长期的判断仍然难学。

他早期把代理嵌入应用的实验，没有变成预期中的业务，却训练了他思考数据流：状态住在哪里，什么形状进入模型，哪些指令优先，以及清空上下文后保留什么。

开始制作代理循环时，这些经验迁移了过来。他看到的是能够用状态、事件和步骤间信息流描述的过程，技能则成为分发过程的方式。他对某些模型何时变得可委托的叙述，是历史上的个人经验，不保证所有代理现在都能无人看管地工作。

主持人讲到，用 Grill Me 设计一个看似简单的订阅者查询 API 时，认证、速率限制和范围问题，把它变成了比预期深入得多的设计讨论。

Pocock 解释，这个技能本质上只是一条要求持续采访用户的简短指令。收益不在必须问多少道题，而在让人停下来思考那些其实能够作出的决定，也找出需要进一步研究的问题。

他强调沟通缺口：模型不会自动知道用户的优先级。明确什么在范围内、什么最重要，与实现细节同样关键。主持人看重的是自己仍然负责选择，而不是交出一个说明不足的目标，事后才发现模型替自己作了什么决定。

Pocock 的规划过程，把目的地描述与实现单元分开。规格说明定义什么才算到达终点，工单则把工作分为可在不同会话中完成的部分。

他的理由是，更多上下文会争夺注意力，可能损害表现。访谈提到一个有用上下文区域的数值估计，但那是他的工作经验，并非针对所有模型和任务测得的统一上限。

新会话也不是一无所有：仓库、文档和环境在模型之外保存着状态。他希望充分规划后能有较长的实现时段，再进行审查，而不是不断切换终端。这个流程偏好不意味着可以发布未经检查的修改，或跳过任务原有约束。

一次澄清对话也可能超过合适的上下文。Wayfinder 引入一张地图，记录决定、已知目的地和尚未探索的问题。每次会话需要自己的目标，也要了解别处已经作出的相关决定。

工单不必全是对话。一个问题可能需要原型、研究或实际配置资源。这些行动会揭开地图的更多部分，也可能改变接下来应该决定什么。

Pocock 也把它用于课程规划和花园办公室。可迁移的想法是可见的共享状态与有意识地减少不确定性，而不是声称只要最初计划写得够长，任何项目都能被解决。

Pocock 说，只围绕规格反复修改的方式曾令他失望：代码变得更差，坏测试给代理错误信号，而把数据库、应用和界面整层做完后才连接，又推迟了集成问题的暴露。

他回到《The Pragmatic Programmer》，重新使用 tracer bullet 与纵向切片等概念。与其分别完成各层，不如先做一条贯穿所需层次的工作路径，观察结果，再向外扩展。数据库里的行为，可能改变界面应该显示什么。

他把 tracer bullet 这样的短语叫作引导词：似乎能把有用概念带进模型工作的简洁术语。这是他对提示方式的观察，不证明某本书确实进入了特定模型的训练集。只有代理实际改变行为并得到有效反馈，重复这些词才有意义。

Pocock 从领域驱动设计借来另一个想法：为应用建立共享语言。词汇应同时出现在对话、文档和代码中，让代理能找到相应概念。

他的例子是，草稿章节和课程中有一节草稿课。当这节课变成正式内容时，上级章节和课程也可能需要转成正式状态。把这个过程叫作 materialization cascade，能用一个紧凑名称指代复杂行为。

目标是让术语精确连接底层规则，而不是为术语而术语。他把新代理会话比作需要熟悉代码库的新同事，这解释了结构为什么重要，但不意味着每个工具都完全没有任何持久记忆能力。

Pocock 把架构决定比作一张调音台，调完以后要等几个月才能听见效果。把滑杆推向更多服务，或者推向单体很容易，学到后果却需要更久。

他认为，代理加快产出也可能让错误更早显现。主持人追问，修复变容易，会不会让学习不如一次严重事故来得深刻。对话并没有解决，企业在这种条件下究竟该怎样培养下一代工程师。

Pocock 承认，自己对初级招聘和成长并无确定答案。他更有把握的主张是，当一个人能指挥更多产出时，对代码、后果和长期方向的理解会更有价值。这是检查代理工作环境的理由，并不是完全放弃战术知识的理由。

被问到怎样证明基本功投入值得时，Pocock 建议观察代理在做什么、哪里成功、哪里失败。不同仓库之间的差异，可能揭示值得共享的实践。

共同的流程与技能集合，有助于让实验可比较。人们可以尝试变体，再贡献学到的东西。主持人补上人的反馈环：同事仍需讨论什么有效、什么无效，以及哪些地方应该完全由人负责。

自动提出架构改进是他的例子之一，但出现提案不意味着每份都应接受。改善生产过程所花的时间，与功能工作一样需要结果。访谈没有证明一个适用于所有团队的固定投入比例。

Pocock 正在探索通过 Discord 使用远程机器，这让他离开笔记本也能工作，并运行定时过程。更大的想法是，团队的代理和规划对话应能被同事访问，而不是隔离在某个人的许多终端中。

主持人提出复杂开发环境的复制，以及前端反馈等实际顾虑。对延迟敏感的工作、交互问题，会让安排没那么简单。转发开发服务器可能有帮助，但双方没有证明它能消除所有例外。

这描述的是他的配置与探索方向，并非所有本地开发都过时了，也不是一台云机器自动提供安全、协作流程的通用结论。

Pocock 明确说，不要对所有事情使用 Grill Me。小而明显的修改可以先做、再检查。较大的选择如果难以撤回，则应在错误代码影响后续工作前先对齐。

他的粗略区分是：可以直接检查的小改动、一次会话能够完成的澄清，以及需要 Wayfinder 的大规划。边界取决于工作性质，不是一套每次变更都必须经历的仪式。

他也强调，在提交规格之前积极制作原型。便宜的原型能够暴露方案应该是什么样。这里的规划包含从实验中学习，并不是为不受新证据影响的多年固定计划辩护。

Pocock 对 TDD 有保留。他看重先见到失败的反馈，以及证明改动解决问题的证据，同时质疑围绕人类较小工作记忆设计的流程，是否始终适合代理。

即使不严格遵守红、绿、重构顺序，他也要求提供没有这次改动就会失败的证据。重复一个常量或重新陈述实现的测试，并不能给有用行为带来多少信心。

重要区别在信号质量。测试套件既能正确引导代理，也能错误引导。访谈没有证明代理不能钻测试空子，它是在要求检查证据，而不是把测试数量自动当作质量改善。

Pocock 用未来修改变难来定义技术债。代理即使在小仓库、小补丁里，也能引入这种问题。单独的审查过程可能帮助发现坏测试或规范偏离。

他马上又问，怎样知道审查者本身做得好？增加一个审查代理，不会消除评估审查的需要。产出增加时，持续的任务仍是让代码库可理解、可修改。

同样的判断也出现在他的教育观里：把想法图谱排成有用的学习路径，是策划与选择。他将业务转型部分归功于时机和运气，而不是声称成功证明了自己能预知行业未来。

对现在的学习者，Pocock 鼓励使用代理建设真实东西，同时对代码和过程都保持好奇。当年的声音应用若有人协助调查性能，会受益很多，但理解为什么慢仍然重要。

园丁比喻把对话串起来。需要有人在问题淹没仓库前，注意累积的抑制指令、混乱边界和脆弱流程。Pocock 把工程师描述为代理的平台团队：他们塑造工作能够成功的条件。

他最后强调自省：检查自己在做什么，把过程写成语言，尝试改进，再评估结果。技能只是这种实践的一种表达，不能替代让过程值得重复的判断。