一份 2026 年 6 月的研究专门测了一件事：AI 代理写的代码，后续还好不好接着改。研究者搭了一个叫 CodeThread 的框架，让编码代理在「人写的实现」和「代理写的实现」之上分别做后续任务，覆盖 4 个代理和 4 个基准。结果是，在代理自己写过的代码上继续干活，任务成功率明显更低，某些对比里完成率差了 13.1%，尽管两种实现最初都通过了测试。
差异藏在细节里：输入校验、错误处理、实现行为上都有更微妙的偏差。也就是说，测试通过不等于行为一致。
代码评审也在给出同样的信号
另一项研究分析了 300 个开源项目里 278,790 条行内评审对话。人类评审者面对代理写的代码时，评审轮次比面对人写的代码多 11.8%；AI 给出的评审建议被采纳的比例是 16.6%，而人类评审者的建议采纳率是 56.5%。还有一个附带发现：AI 的建议一旦被接受，往往带来更大的代码规模和复杂度增长。
人类评审者更常对测试、可理解性和知识转移提出疑问。这些研究都没有做到「同一任务在 Go、Python、JavaScript、Rust 上各跑一遍」，所以不能证明 Go 产出的代码更好维护。它们能说明的是：代码可以过掉当初的测试，却仍会绊倒下一个接手它的代理，剩下的改动大多还得人来处理。
Google 的答案：让语言当护栏
这正是 Google 把 Go 推向「给机器书写」的原因。8 月 11 日它在开发者博客上给出理由：Go 的语言表面积小、静态类型、工具链集成，能帮代理自己发现错误。
具体来说，gofmt 让所有文件的格式一致；编译器立刻拒绝不存在的方法和类型错误，而在动态类型语言里这些问题要到运行时才暴露；代理还可用原生模糊测试探查意外输入、用 govulncheck 找对已知漏洞函数的调用。下载模块时，Go 的校验和数据库能标出与记录版本不一致的副本。Go 1.26 重写的 go fix 能用预定义转换更新旧代码，gopls 则通过 MCP 服务器把编译错误直接送给 AI 工具。
但编译器判断不了代理是否误解了需求、套错业务规则、把信息暴露给了错误的用户，人工监督仍然需要。漏洞扫描也只能覆盖已录入数据库的问题，供应链风险不会因此消失。
这条路线有意思的地方在于，它把语言设计当成约束 AI 行为的手段：不是靠提示词让模型小心，而是让错误在编译阶段就过不去。对大量依赖代理产出的团队来说，这种用灵活性换可验证性的取舍，正在变得越来越划算。