编辑 | 姜篇
Matt Pocock：知识已经变得很便宜，工程智慧却没有变得更容易获得。
Matt Pocock：你给Agent的上下文越多，它的表现反而越差。
Matt Pocock：把规格拆成一张张独立工单，一次会话只处理一张。
模型会写的代码越来越多，程序员的基本功却没有跟着贬值，反而越来越重要。
同样一项改造任务，有人把需求文档、代码、日志和报错一次性塞进Agent，几个回合后，会话里全是过期信息。模型还在继续输出，改动却开始偏离最初的要求。
另一种做法是先把任务拆开：这一轮只定位问题，下一轮补测试，再开一个干净会话修改代码。每一步都有明确范围，也知道怎样才算完成。
两种用法调用的是同一个模型，结果可能完全不同。
Matt Pocock谈的“基本功”，并不是背语法、记API。现在这些知识随时可以问模型。他所说的是另一类能力：能不能把需求说清楚，能不能把大任务切成Agent接得住的小块，能不能发现测试虽然通过了，代码却没有解决真实问题。
Agent把错误答案写成代码的速度，和写对答案一样快。开发者判断错一次，它可能沿着错误方向改完整个仓库。
备注：Matt Pocock是Total TypeScript作者，也是一名开发者教育者。他创建了Grill Me、Wayfinder等AI编程Skills。最近，他在The Pragmatic Engineer的访谈中，集中谈了上下文管理、任务拆分、测试反馈和代码库质量。
这些听起来都不新鲜，却决定了Agent到底是帮手，还是一台跑得很快的返工机器。
以下为访谈内容，我们进行了翻译与整理。
Matt Pocock认为，知识获取成本下降了，工程判断仍要在真实问题中学习
知识变便宜了，工程经验没有
AI把很多过去需要搜索和记忆的东西压缩成了几秒钟。
不熟悉一个API，可以直接问模型；刚进入一套代码库，也能让Agent解释目录、调用链和关键模块。开发者获取知识的速度比以前快了很多。
Matt认为，变便宜的是知识，不是做工程决策的经验。
Matt Pocock：“You can find out about any part of a codebase extremely quickly. But the wisdom has gotten no easier to learn.”
Matt Pocock：你可以很快了解代码库的任何部分，但工程智慧并没有变得更容易学习。
这种“智慧”并不神秘。它是开发者在项目里反复碰壁以后留下的判断：需求该拆到多小，哪项约束必须先确认，什么样的测试才算覆盖风险，什么时候该停止重构。
Agent能给出一套漂亮的目录结构，却不知道团队三个月后会不会因此多维护两个服务；它能迅速升级依赖，也不会替人判断旧数据是否兼容、上线窗口是否合适。
Matt Pocock：“You are still going to run into the same issues that you would have run into even with AI.”
Matt Pocock：即使有了AI，你仍会碰到过去那些软件工程问题。
AI没有把这些问题拿走。它让每个决定更快变成代码，错误的决定也会更快铺满仓库。
上下文越堆越多，Agent开始听不清重点
Matt在访谈里借用了开发者Dex Horthy提出的两个概念：smart zone和dumb zone，可以理解为Agent的“高质量工作区”和“变笨区”。
Matt谈Agent的“高质量工作区”和“变笨区”，这一说法来自Dex Horthy
Matt Pocock：“There’s this thing that Dex Horthy talks about, which is the smart zone and the dumb zone.”
Matt Pocock：Dex Horthy讲过一个概念，叫“高质量工作区”和“变笨区”。
上下文窗口只说明模型能装下多少内容。材料放进去以后，模型能否稳定抓住当前任务的重点，是另一回事。
一个会话先讨论数据库，再贴报错，又让Agent改前端，随后补充安全要求。每条内容都可能有用，它们的重要程度却不同。已经放弃的方案和失败日志仍留在会话里，也会继续影响下一次判断。
Matt Pocock：“Every token is shouting for attention. And the more voices you put into that room, the harder it is to hear the important ones.”
Matt Pocock：每个Token都在争夺注意力。房间里的声音越多，重要信息就越难被听见。
上下文里的每个Token都在争夺模型注意力
Matt目前把前约15万Token视作多数前沿模型较可靠的工作区。超过这条经验线后，他会开始警惕输出质量下降。
Matt Pocock：“The smart zone is about the first 150,000 tokens for most frontier models, regardless of whether their context size is a million.”
Matt Pocock：按我的经验，多数前沿模型较可靠的工作区大约在前15万Token，即便它标称拥有100万Token上下文。
15万不是所有模型的统一上限。模型、任务和工具链都会改变结果。这个数字的用途，是提醒开发者别把“能装下”直接理解成“始终能想清楚”。
一张工单，只占用一次会话
上下文不能无限堆，任务状态又必须保留。Matt的处理方式，是把状态从对话里搬出去。
Matt Pocock：“Do the smallest possible change that will get us further towards that goal, and then clear your context and start from fresh.”
Matt Pocock：完成一个能让项目向目标前进一步的最小改动，然后清空上下文，从新会话继续。
规格、工单、代码、测试结果和提交记录都在仓库里。新会话不需要记住前面聊过的每句话，只要读取已经留下的结果。
Matt建议把规格拆成独立工单，每张工单使用一次新会话
“重做账号系统”不适合直接交给Agent。它可以继续拆成登录失败次数记录、锁定策略、管理员解锁接口、前端提示和回归测试。每项任务都有清楚的改动范围和验收条件，做完一项，再开启下一轮。
新会话不用背着前一次试错产生的旧方案，开发者也能看清这一轮究竟改了什么。
Matt把自己的流程分成三段：先让Agent追问需求，再生成规格和工单，最后逐张执行。白天由人做规划和取舍，夜里再让Agent处理边界已经说清的任务。
Matt Pocock：“You’re doing the planning during the day shift, and then during the night shift your agents are actually working on these tickets.”
Matt Pocock：白天把计划做清楚，夜里再让Agent按照这些工单执行。
先别写代码，让Agent把问题问完
Matt的Grill Me Skill会故意给开发制造一点摩擦。
主持人Gergely Orosz用它规划一个简单API接口时，被连续问了35个问题：身份验证怎么做，异常返回什么，数据能否重放，哪些内容不在本次范围内。
Grill Me持续追问，迫使开发者把范围、约束和取舍说清
Matt Pocock：“It relentlessly interviews you, and it is 10 times better than anything I have used.”
Matt Pocock：它会不停地追问。在我用过的这类工具里，它的效果好得多。
连续追问会逼着开发者亲自做决定。
Matt Pocock：“It forces you to make those decisions and reminds you of things you might have overlooked.”
Matt Pocock：它会迫使你做出决定，也会提醒你那些可能漏掉的问题。
只说“帮我写一个接口”，Agent很容易交出能运行却不合用的实现。输入输出、权限、失败方式、兼容范围和不可触碰的边界被说清以后，代码才有明确方向。
Grill Me没有替人完成思考。它把原本藏在开发者脑子里的假设逼了出来。
测试绿了，Agent仍可能自证正确
Agent需要能读懂的反馈。测试、类型检查、运行日志和性能指标，都可以告诉它这次修改有没有接近目标。
Matt Pocock：“Agents really do need feedback loops. They need to have something that they can look at to tell them if what they’re doing is working or not.”
Matt Pocock：Agent确实需要反馈循环。它必须有东西可以检查，才能知道自己的修改是否有效。
测试、类型检查和运行日志，为Agent提供可以读取的反馈
Matt会要求Agent拿出两份证据：修改后的测试能够通过，同时证明没有这次修改时测试会失败。
Matt Pocock：“Ask it to provide evidence that what it has done has worked, and that if you hadn’t made the change, it would have failed.”
Matt Pocock：要求它提供证据，证明修改确实生效，也证明没有这次修改时测试会失败。
绿灯仍然不等于正确。
Matt Pocock：“Agents are very good at writing bad tests, tautological tests.”
Matt Pocock：Agent很擅长写出糟糕的测试，甚至是自证正确的测试。
Agent可能按照自己的实现理解需求，再补一个刚好能证明这份实现正确的断言。
测试全绿，真实业务仍然可能出错。
支付系统里的幂等逻辑就是一例。函数测试通过以后，开发者还要检查历史订单怎么补偿、消息是否会重复消费、旧版本数据库能否兼容。验收条件最好来自需求、旧行为和生产数据，不能让同一个Agent既出题又判卷。
代码库越乱，Agent越容易把错误复制下去
团队成员在一个项目里工作几年，会记住哪些模块不能随便碰，哪些奇怪命名背着历史兼容。Agent每次进入新会话，都没有这段记忆。
Matt Pocock：“The agent is like a new starter every single session.”
Matt Pocock：Agent在每次新会话里，都像一名刚入职的新员工。
人可以靠经验绕过坏设计，Agent只能从目录、命名、接口、文档和测试里理解系统。几处信息相互矛盾，它就得猜。
Matt Pocock：“Your code is the environment the agent operates in.”
Matt Pocock：你的代码，就是Agent工作的环境。
代码库是Agent工作的环境
坏环境的代价还会被生成速度放大。一个错误抽象过去可能几个月后才暴露，现在Agent可以在一晚之间沿着它生成几十个文件。
Matt Pocock：“It’s so easy for agents to just make a codebase worse over time.”
Matt Pocock：Agent很容易在持续生成中，让代码库一点点变差。
生成速度提高后，结构性问题也会更快扩散
实现Agent后面再接一个审查Agent，可以挡住一部分问题，挡不住所有问题。单行改动也可能破坏权限边界、状态机和数据兼容。团队仍需要有人理解系统为何这样设计。
这也是软件基本功重新变得显眼的地方。清楚的命名、稳定的接口、可执行测试和可信文档，过去方便人协作，现在也决定Agent能否稳定工作。
评论区：有人认可基本功，也有人质疑个人项目经验
评论区里，支持者最认同的是Matt把话题拉回软件基本功。
图片
有观众认为，每次编程能力跃升都会带来更复杂的系统，开发者仍要保持好奇并继续写代码
网友@larsfayedev写道，过去约50年里，人们多次声称编程已经被“解决”。每次能力大幅提升以后，软件没有自动变简单，行业只是开始构建更复杂的系统。
另一边的质疑也很直接：个人项目上的方法，放进大型业务团队是否仍然成立？
有观众质疑，个人项目经验与大型关键业务团队的工作环境存在明显差异
这个问题确实存在。大型项目还有跨团队依赖、合规审批、发布窗口和历史数据，不能靠清空一次会话解决。
规模越大，任务边界、验收条件和可追溯记录越重要。Matt的方法无法代替组织治理，它能做的是把Agent一次出错的范围压在一张工单里。
写在最后
Matt在访谈接近尾声时，把开发者的新角色形容成Agent的平台团队。
Matt Pocock：“We are our agents’ platform team. We have to build the environment for them to succeed.”
Matt Pocock：我们就是Agent的平台团队，需要为它们搭好能够工作的环境。
开发者需要为Agent准备清楚的环境、反馈和边界
可以先把五条规则放进日常开发：一次会话只处理一个验收目标；规划和实现使用不同会话；规格、工单和关键决定写进仓库；要求Agent用测试、类型检查和日志证明结果；任务跨过自然边界时，主动清空上下文。
重复使用的工作方法，还可以继续写成Skill、脚本或项目规范。
Matt Pocock：一项很重要的能力，是看清自己的工作过程，把它说出来，再编码给AI。
模型会继续获得更长的上下文，Agent也会一次处理更多文件。开发者仍要替它决定哪些信息该进入当前会话、什么时候应该停下，以及结果达到什么标准才能进入下一步。
代码生成得更快以后，把问题切清楚、给出可靠反馈、维护好代码库，才是让这份速度留下来的办法。
