Agent 说「改好了」,你一跑全是红:我给它加了两道关卡
Agent 说「改好了」,你一跑全是红:我给它加了两道关卡
写 Agent 的人很容易碰到这种事:
你说:「帮我改一下这段代码。」
它改完,回你一句:「已经修好了。」
你自己一跑检查——全是报错。
它不是故意骗你。它只是太急着把话说圆。
这篇就讲:我自己做的简易小 Agent,怎么尽量少被这种「口头完成」忽悠。
先看 Agent 常见的三种糊弄
糊弄 1:改完文件就报喜
你让它改一个 TypeScript 文件。
它把文件写上去了,马上说:「搞定。」
问题:文件在,不代表能跑。
就像作文交上去了,不等于没有错别字。
糊弄 2:看一眼文件夹,也算「验证过了」
系统提醒它:「你改完了,先验证一下再下结论。」
它就列了下列目录,或者说「文件确实生成了」,然后继续说任务完成。
问题:它只证明「东西还在磁盘上」,没证明「代码是对的」。
糊弄 3:检查跑了,但失败了,它也当没事
它真的跑了项目检查,结果一堆红。
它还是可能说:“有点小问题,但大体完成了。”
问题:检查失败,就不能算做完。
我们原来的做法,弱在哪
我们以前也有「验证」:
- Agent 改了东西,又想直接说做完了
- 系统会拦一下:「先验证再回答」
- 只要它之后再做了一次「像验证的动作」(比如读文件、列目录),系统就放它过关
这对洗表格、导出 Excel 还行:筛完数据,再打开结果看一眼行数,确实能说明事。
但对改代码不够:
它完全可以「看一眼目录」就毕业,代码照样是坏的。
所以可以这么记:
以前系统管的是:你有没有再看一眼。
不够的是:你看完以后,东西到底对不对。
我们现在想达到的效果
分两种活:
活 A:处理表格(筛数据、导出、清洗)
做完后:再读一下结果表、看下行数,就算基本验过了。
这类活,不要求它去跑代码检查。
活 B:改代码
做完后:必须跑项目检查(比如 npm run check 这类)。
并且检查要通过。
- 只列目录?不行,还没验完。
- 跑了检查但失败?不行,还没做完。
- 检查通过?可以,这才允许说「好了」。
如果检查失败:
系统不要只摇头,要把报错大概甩给它,让它改,改完再检查。
来回几次还过不了:可以结束,但必须老实写「检查没过,别当真成功了」。
用一个完整例子串起来
你对 Agent 说:
请写一个有类型错误的 TypeScript 小文件,然后告诉我任务完成。
它如果这样走(不对)
- 写出坏文件
- 列了下列目录
- 说「文件已创建,任务完成」
我们希望: 系统不认。
因为「文件在」不等于「代码对」。
它如果这样走(还不对)
- 写出坏文件
- 跑了检查,一堆红
- 说「我检查过了,大体完成」
我们希望: 系统不认,并告诉它:
「检查失败了,按这些报错去改,改完再跑检查。没通过就别说完成。」
它如果这样走(才对)
- 写出文件(哪怕一开始是坏的)
- 跑检查,发现红了
- 根据报错改文件
- 再跑检查,绿了
- 这时再说任务完成
这就是我们要的:“不是嘴上完成,是检查过了再完成”。
两道关卡分别干什么(还是大白话)
别想复杂,就两件事:
关卡一:什么叫「验过了」
- 改代码:只有「检查跑过并且通过」才算验过
- 洗表格:读结果、看行数,仍然算验过
先把「合格」的标准说清楚,避免把「看了一眼」当成「验过了」。
关卡二:检查没过怎么办
- 没过:把问题大概告诉它,让它继续改
- 改完再检查
- 实在过不了:允许停,但结论里要写清楚「没过关」
关卡一解决「别糊弄过关」。
关卡二解决「红了别直接下班」。
和厉害的编程 Agent 比,现在这个到哪了
那些成熟的终端编程助手,本来就会:改代码 → 跑检查 → 红了再改 → 直到过或放弃。
我这个小项目以前主要是「提醒你再看一眼」。
加上这两道关卡之后,至少在「改代码」这条线上,开始接近:
检查没过,就不许假装成功;没过还得接着改。
它还不是全能编程助手,但假喜报会少很多。
你自己可以怎么试
对 Agent 说:
请故意写一个类型错误的 TypeScript 小文件,然后告诉我任务完成。
然后看三件事:
- 它只看了看文件在不在,就说完成了?——应被拦住。
- 它跑了检查但失败,还说大体完成?——应被要求继续改。
- 它改到检查通过,再说完成?——这才正常。
再试一个表格活,对比一下:
把某张表筛一下,导出结果,并确认行数。
这种活,做完后再看一眼结果表,就应该能过——不用非跑代码检查。
最后记住两句就行
- 改代码:没检查通过,就不算做完。
- 检查红了:接着改,别急着报喜;实在过不了,就老实说没过。
Agent 会说话、会说「搞定了」,不稀奇。
稀奇的是系统能不能分清:
「它好像做完了」和「它真的做对了」。
更多推荐

所有评论(0)