Total TypeScript 作者 Matt Pocock：别把整个需求塞给 Agent，上下文一长模型就进“变笨区”

原创 姜篇 2026-09-30 12:10 日本  Agent会写的代码越来越多，上下文却不是越长越好。Total TypeScript作者Matt Pocock认为，任务拆分、上下文管理、测试反馈和工程判断，正在成为程序员驾驭Agent的基本功。   编辑 | 姜篇 > 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也会一次处理更多文件。开发者仍要替它决定哪些信息该进入当前会话、什么时候应该停下，以及结果达到什么标准才能进入下一步。 代码生成得更快以后，把问题切清楚、给出可靠反馈、维护好代码库，才是让这份速度留下来的办法。 参考链接： `——好文链接—— 程序员最大的风险不是被AI替代，而是“认知投降”！Chrome前负责人：代码写完了，人却看不懂系统 AI编程已经卷到头了！马斯克：把目光转向“现实世界工程”，下一场硬仗，是让AI走出IDE 软件开发正在变成“开工厂”！黄仁勋劝开发者别只盯着AI末日论，网友锐评：卖铲子的人让大家继续挖  ` [跳转微信打开](https://wechat2rss.bestblogs.dev/link-proxy/?k=778a6e0b&r=1&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMjM5ODI5Njc2MA%3D%3D%26mid%3D2655943165%26idx%3D1%26sn%3Da081929500383d2176416bb8eef5b0a9)