摘要让 Agent 把按钮改成蓝色它顺手注入了兼容样式、写了迁移脚本、跑了 50 轮压测。有论文实测上下文文件让 Agent 探索更广、推理成本涨两成成功率却没变。问题不在模型不够聪明是它算不出这个活儿值多少钱。有人做了个网页opusfived.dev把一句话摆出来让你试「把加入购物车的按钮改成蓝色别的都不许动。」结果按钮是变蓝了页面上其他东西也一起蓝了还多出一个你从没提过的 hover 渐变。最后它报告完成。这个页面在 9 月 9 日前后冲到了 Hacker News 首页第一分数停在九百上下、评论三百多条快照时间不同数字会有出入。有意思的不是分数是评论区的分裂一半人说自己天天用这类工具从没见过这种场面另一半说这就是日常尤其是那个「过度解释」和「范围蔓延」。两边都很真诚。吵到最后没人拿出一个数字。一个被争论了两年的产品特性到今天还没有一个能对齐的度量。三个真实的下午Hacker News 上有人把具体经历写了出来比游戏还像游戏。第一个一个初始化不到两小时的仓库零用户、零流量要改一个字段名。人打开全局替换十秒改完提交完事。模型的做法是新名字加上去、旧名字留着、再手写一组兼容映射防的是「可能存在的外部调用方还在查旧字段」。第二个有人只想让它生成点标记搭个临时 UI 原型。模型自己起了个高可用埋点框架对着第一次构建连跑 50 轮延迟测试。作者只能一遍遍按中止。第三个就是那个按钮。除了把页面搞蓝它还注入了向后兼容的过渡样式、写了个迁移脚本、跑了一整套压测。三个下午同一个模式。它缺的不是能力是预算同一个模型能在一个下午里把真实 Bug 追到根因也能在一行 CSS 上花掉半小时推理。差别不在能力在于它不知道这件事值多少钱。一个做了多年的工程师看到「把按钮改成蓝色」脑子里会瞬间填出一张表风险极低、只碰一个文件、代码寿命可能就几个月、用户数未知、允许投入五分钟。表填完动作就定了——改 CSS扫一眼页面收工。模型手上没有这张表。它看到的是「软件改动」→「必须正确」→「验证做得越充分越好」。于是它为一个值五分钟的任务投入了三十分钟的算力。论文测出来的结果和现象对得上苏黎世联邦理工的一篇论文专门测过这件事arXiv:2602.11988。他们建了个基准138 个真实 Python 任务来自 12 个不太出名、但开发者自己写了上下文文件的开源仓库。三条结论上下文文件整体上并没有提升任务成功率推理成本反而涨了两成以上行为上上下文文件让 Agent 探索得更广——测得更勤、翻的文件更多Agent 是真的会听指令的。第三条最要命。指令没有被忽略是被认真执行了代价从别的地方冒出来。论文自己的结论写得很直接多余的要求会让任务变难人写的上下文文件应该只保留最小必要的信息。这条结论解释了很多人踩过的坑。你为了让 Agent「更严谨」在规则文件里写了三十条禁忌结果它逐条去核对相关性翻了十几个根本不该碰的文件最后交出来的补丁又大又不完整。为什么它天生只会打补丁那条 Hacker News 讨论的最高赞把根因说得比我清楚老工程师会在「在现有抽象上继续打补丁」和「从第一性原理重新设计」之间做成本比较然后挑便宜的那条。模型没有这个多维度的成本意识。它在训练时读的是海量企业级开源代码于是带着一种很强的现状偏见把每一行已有代码当成自然事实。你让它改功能 A它的算力立刻扑到「会不会弄坏看不见的 B 调用方」上最后交出一叠防御性适配层、兼容开关和兜底分支。更麻烦的是另一层误读它会把你仓库里的「已有代码」读成「设计意图」。这两件事经常不是一回事。老系统里那些绕来绕去的结构可能只是某次赶工留下的形状不是设计。人看得出来模型看不出来于是它总在给一个错误的形状加固。你写下的每一条「不要」都在让它更谨慎有两份实测值得放在一起看。一份来自 Augment Code 团队的内部评测写得最好的上下文文件带来的质量提升相当于把模型从 Haiku 换成 Opus写得最差的那份效果比什么都不写还糟。他们找到的有效模式里有一条很反直觉——只写「不要」的文件效果很差Agent 会变得过度谨慎、过度探索、产出更少。每条禁令最好配一条替代方案❌ 不要直接实例化 HTTP 客户端✅ 不要直接实例化 HTTP 客户端用lib/http里的共享apiClient它自带重试中间件另一份就是前面那篇论文任何上下文文件都会让推理成本涨两成左右哪怕写得再好。两份数据拼起来指向同一件事规则文件不是写得越细越好写的是「限制」还是「替代方案」结果差很远。所以真正有用的那几条规则长这样## 改动范围 - 只改需求指定的行为每行 diff 都要能对应到需求 - 改超过 3 个文件先出计划等我确认不要直接动手 - 允许不向后兼容这是个人项目没有外部调用方 - 验证只跑受影响的测试不要跑全量最后一条是最反直觉、也最省时间的一条。有人在开源仓库里就是这么写的除非明确要求否则不要保留向后兼容。这句话直接把前面三个下午里的「兼容映射」「迁移脚本」「全量压测」全按住了。交出去之前把预算写上回到那张表。工程师脑子里那张表有四行这次改动值多少风险、影响多大范围、这段代码活多久、允许花多少时间。模型填不出来只能你把答案写在它读得到的地方。四行分别对应四种写法风险这是本地演示页不用考虑线上范围只允许改这一个文件其他文件只读寿命这是原型两周后大概率重写时间五分钟内给结果不要跑测试写完这四行你会发现 Agent 突然像个正常人。它不再给原型搭监控也不再给两小时的仓库修兼容性。什么时候你反而希望它过度验证这套做法有边界而且边界很硬。低风险、可回滚、局部的小改动上收窄范围和停止条件收益最大——你把五分钟的任务放开给它它能给你干成三十分钟。但换到碰钱的链路、数据迁移、认证授权、不可逆操作上前面那套「允许不向后兼容」「不要跑测试」就是自杀式配置。这些场景你反而希望它把现有调用方翻一遍、把回滚路径想清楚、多跑几轮验证。前面那份评测里也有对应的做法auth、支付、权限、加密、数据迁移这类改动必须先问人。判断标准不是「让 Agent 少做点」而是这个改动最坏情况能不能一键撤回。能撤回就按预算给限制不能撤回就给足谨慎。总结那个按钮游戏的作者大概没想过一个关于颜色的玩笑会变成一次行业体检。它测出来的问题不在模型够不够聪明。模型知道怎么写迁移脚本、怎么搭压测框架、怎么加兼容层——这些都是真本事写进正经项目里都算加分项。它只是不知道这个活儿配不配得上这些本事。这件事原本是人来补的。人靠着「这活儿值多少钱」的直觉把绝大多数任务挡在了完整工程流程之外。Agent 进来之后这层直觉没人接班它就开始给每一件小事配正规军。所以下次它做得比你要求的多先别怪它。把预算写上就四行。作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。