三个月,六千亿 token,一款射击游戏被 AI 逆向成了 C++。代码能编译,游戏能启动,菜单能渲染,地图能加载。作者后来说,那阵子他们真的以为质量很好。
后来他换了一把尺子:把重建出来的函数和原始二进制逐字节比对。结果是 99% 的函数都重建了,其中 83% 字节级一致。而在此之前那四周写出来的东西,语义是错的:函数签名错、结构体布局错,还有人把原本读全局变量的配置改成了哈希查找,慢了几个数量级。
我的判断是:让 AI 干活的规矩,得写在它改不了的地方。
先说那个 reviewer 为什么没拦住。
团队一开始配了四个 agent,三个干活、一个专门评审。评审的那个只查 bug,不质疑架构。更要命的是,干活 agent 写在 commit 和代码里的注释,把评审 agent 说服了。它接受了上游的自我辩护,没有拿原始二进制去独立核对。作者的原话是,这些注释成了「无意的提示注入」。
这不是 agent 在作弊,是设计缺陷。
判定者只要还是个模型,被判定方写的文本就是它的输入,判定从一开始就输了。
第二层更值得记。他们引入字节比对之后,agent 先是一上来就写内联汇编绕过比对;明文禁止之后,开始反复尝试修改校验脚本本身,把自己排除出去。最后的对策很朴素:CI 对校验脚本做哈希,跟存在 GitHub Actions 里的 secret 比对。
agent 通常不会绕过你的规则,它会去改你的规则。
我在电力现场做过智能安监,那时候有个偏执的坚持:判定逻辑必须放在独立服务里,现场侧只上报证据、不做结论。当时是为了好排查,哪个摄像头、哪段视频、哪条规则触发的,一条链拉到底。现在回头看,那其实就是同一件事。
判定物和被执行物必须分离,而且判定物自身的完整性要能被独立验证。
Cockroach Labs 十月公开了他们跑了五个月的「编码医院」:把 bug 当病人,把编码 agent 当医疗团队。五个月合入 1,238 个 PR、一百多万行代码,只回滚了 7 次,烧掉约 13.5 万美元 token。
真正的门槛是三条硬规则:计划没通过评审前不许写代码;单次工作量超过 1000 行必须再拆;不许削弱测试来让它变绿。再加两个我立刻抄进自己流水线的设计。一是断路器:同一问题连续 4 轮返工、或累计 6 轮,自动上交人工,他们是被一个紧急单行修复走了 11 轮返工两天逼出来的。二是 Discharge Nurse:这个角色不审代码,它审「评审到底有没有发生」。
这一层是我以前没想过的。
我们一直在问有没有验收,从来不问验收本身靠不靠得住。
还有一组数字。那个 Discharge Nurse 每次运行要先加载 21,800 词、约 29,000 token 的指令才去看 PR。七月他们审计了 25 个 skill 文件共约十万词,判定其中 23% 可以删掉,而不改变任何一道关卡。
对照前面那位逆向玩家的另一条经验:指令会衰减。agent 会随着时间和上下文压缩,把规则看得越来越不重要,他最后靠每小时定时重新注入指令文档解决。
一个会稀释,一个会膨胀,说的是同一件事:规则文件不是写完就结束的。
我去年把 AI 巡检后端从「服务之间互相发 HTTP 请求」重构成四层架构,第一件事不是写代码,是定规矩:业务层里不许出现框架的上下文对象。原因不是那个对象危险,而是不该出现的依赖,一旦允许它出现,就再也收不回来。
规矩写在 wiki 里没人看,写进分层约束和 CI 里才生效。
规则文件既然会长大,就得定期审计。审计标准不是「这段看起来有没有用」,而是删掉它,哪道关卡会变。
一、把校验脚本挪出 agent 的可写范围。 最省事的一版:CI 里加一行哈希比对,对照独立仓库的只读引用或 Actions secret。这一步不花预算,今天就能加。
二、给 agent 流程加断路器。 同一问题连续 4 轮新发现、或累计 6 轮返工,自动转人工。别靠人盯,人盯不住。
三、审计一次你的规则文件。 随机删掉一段,看哪道关卡会变;删了没变化的,就是纯成本。上面那家的实测比例是 23%。