北京
我经营着一个小型开源商业工具集合，大部分时候是我一个人在干，AI子代理承担了大量跑腿活儿：跨仓库读代码、起草文档、把声明与真实代码做交叉验证。
很长一段时间里，这套配置的问题不在于代码写错，而在于那种过于自信的行文。某个代理会写“这已经在框架里做了标准化”——听起来靠谱，框架里确实有类似的东西，但如果我没去亲自翻看，就会把一句根本不成立的句子发布出去。不是故意的，纯粹是模型拿着一点蛛丝马迹把缺口给抹平了，抹得还挺像那么回事。
于是我往每个子代理的任务指令里加了一段话。
这段指令不花哨。就是一条贯穿所有任务的硬规矩：要么引用来源，要么放弃它。每一项声明都必须对应一个具名来源——某份文件、某个PR、某一行代码。如果你找不到出处，就别说这话；跳过它，并说明你跳过了。不要链接到你没确认过存在的锚点。报告你没能完成的事情。跳过一步是信息，不是需要遮掩的失败。别碰无关改动，动手前先检查git状态。
就这样。没有框架，没有评估套件。一段简短的列表，把“说得像真的”扭成了“把凭据亮出来”。
真正有意思的地方在于，代理们开始自我纠察了。
其中一次运行里，一个代理正在记录某个特性，想从一个兄弟仓库里复用一句话：“同步机制在这里已被标准化。”它查了一下，发现兄弟仓库压根没这回事，就自己把这项声明拿掉了，还附了条备注，说查无出处。
另一次，它想用深度链接指向一个命名段落，但那个段落并不存在。它没自己编造锚点，而是退回到文件级别的链接，并把情况标记了出来。
还有一个让我反复回味的例子：我给一个代理发了条指令，说某项工作处于“第二阶段，进行中”。它去核查了最新状态，发现那个阶段早在几天前就已经交付完成了，顺手把我给它的指令纠正了过来。
最后这个事值得琢磨。那道防线不止是阻止代理凭空捏造，它还恰恰揪出了我那些早已过时的假设——因为“对照记录核实”这件事，刀锋是双向的。
接着，它来真格的了，直接把我自己的问题摆上了台面。这才是整件事里最让人服气的部分。
我曾经让一个代理起草一篇技术文章，讲的是一个关于共享主机环境下某个Bug的失败故事。每个代码片段都对，每个默认值、每个配置细节，跟仓库一一对照全都吻合。技术层面来说，无可挑剔。
然而叙事框架是虚构的。
文章把它讲成了一次真实的生产事故：“我推送了内存版本的实现，测试全绿，结果上生产后它从来没触发过。”听着很带感，问题是根本没发生过。Git历史清清楚楚——那个组件从第一版提交起就是基于文件存储的。内存版本从来就没被部署过。我正打算用第一人称讲的那段“生产事故”，在代码和记录里找不到一丝痕迹。
一次带有审查把关的复核在发布前把它拦了下来。我现在会拿几个审查视角对新草稿做一遍对抗性通读——
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
