编程智能体绕过而未使用的代码规范（Idiom）
· 阅读需 13 分钟
我合作的一个支付团队的高级工程师曾给我讲过一个故事，我认为每一个运行编程 Agent（AI 代理）的团队最终都会经历。他们的代码库有一个 Result<T, E> 封装器——这是自研的，位于单个 core/result.ts 文件中，在该服务的约两百处调用点被使用。新代码被要求在每一个可能失败的函数中传递 Result；而 throw 则保留给真正意料之外的状态。这并非由 lint 规则强制执行。这就是他们的“方言”。
在使用编程 Agent 交付六个月后，他们审计了 Agent 合并的 diff（差异）。大约三分之一的新函数完全忽略了 Result。Agent 选择了 try/catch，返回了 T | null，抛出了带有描述性消息的 Error 子类——在某些设想的代码库中，这些选择中的每一个都是正确的。但在当前这个代码库中，没有一个是正确的。代码通过了类型检查。测试通过了。审阅者批准了它，因为每一行看起来都没有错。但 Agent 修改的文件不再与它旁边的文件保持一致，团队在自己的服务内部悄然滋生出了第二种“方言”。
这就是我想谈论的故障模式：不是 Bug，不是幻觉，也不是违反了 lint 规则——而是惯用法漂移 (Idiomatic Drift)。Agent 交付的代码可以编译、运行并通过测试，但其风格并非你的代码库所使用的。随着合并次数的增加，代码库会分化为 Agent 风格区和人类风格区，而代价会体现在任何仪表 盘都无法监控的地方。
