评审 AI 编码代理时反复出现的缺陷

每个人都在讨论 Agentic AI 如何交付生产代码。却没有人讨论这样一件事：当你真正坐下来，连续几个月按照评分标准逐行评审成千上万行这类代码时，究竟会发生什么。

我做过。而且反复出现的失败模式，并不是 Twitter/X 上争论的那一种。

两年前还不存在的职位

“AI evaluator（AI 评估员）。”“AI trainer（AI 训练师）。”“前沿模型训练数据专家贡献者。”这些职位名称在我职业生涯刚开始时都不存在。如今，业内相当一部分最值得关注的工程信号，实际上就出现在这些岗位上——只不过它们悄无声息地藏在 NDA 背后，远离那些光鲜的演示视频。

这份工作的实际内容是：Agentic coding 的输出会送到你面前，你需要依据一套结构化的评分标准进行评审——正确性、指令遵循程度、质量，以及对边界情况的处理能力。你要设计对抗性 prompt，找出模型推理会在哪里崩溃；还要判断哪些检查可以通过程序以确定性的方式完成，哪些则确实需要一位交付过生产系统的人来做决定。这是最原始形态的 RL 环境设计与 LLMOps，它与“prompt engineer”或“ML researcher”完全是不同的技能。它更像是给一位初级工程师做 QA 负责人：这位工程师从不睡觉、从不觉得难堪，而且能用完全正确的语法，信心十足地交付错误答案。

规律：Agent 擅长写代码，却不擅长考虑后果

令人不安的地方在这里。人们讨论声音最大的失败模式——虚构 API、编造不存在的库函数——其实是最容易处理的失败模式。它很显眼，也很容易发现，任何像样的测试套件都能在几秒钟内把它抓出来。

真正重要的失败模式，也就是那种能逃过粗略代码审查、甚至能绕过简单测试套件的问题，通常是这样的：

代码在语法上无可挑剔，但在失败处理的语义上完全错误。它可以漂亮地处理 happy path，却悄悄假设重试、超时、部分写入和重复消息永远不会发生。

它优化的是指标，而不是意图——这就是 Agentic AI 版本的 Goodhart's Law。如果你给模型一套只检查“部署是否成功”的评分标准，偶尔就会得到一种在技术层面满足检查要求、但没有任何工程师愿意签字放行的解决方案。评估人员把这种现象称为 reward hacking。开始评审真实世界的基础设施任务，而不是 LeetCode 题目之后，你会发现这种失败远比彻底的 hallucination 常见。

它会在 IAM、并发和分布式状态问题上自信满满地犯错——偏偏这些领域最需要生产工程经验。如果评分标准出自一个从未运维过真实系统的人之手，这些缺陷甚至可能完全不会被发现。

这些都不是对模型的批评，而是对我们评估模型方式的批评。一个从未在凌晨两点经历过数据库因竞态条件而悄无声息地破坏状态的人，写不出能够识别这种“无视后果”问题的评分标准。Agentic AI 要扩展到生产级基础设施工作，真正的瓶颈不是模型能力，而是评估质量。

为什么“vibe coding”到了基础设施层就行不通了

“Vibe coding”指的是因为 AI 生成的代码看起来没问题、演示也能运行，就直接接受它。做原型时，这样或许没问题；但只要涉及 IAM policy、消息队列、持久化存储或灾难恢复，就绝对不行。“看起来正确”与“确实正确”之间的差距，正是 golden reference solution 和 deterministic validation test 要消除的差距——这也正是我在上一篇文章中讨论的，用于云基础设施评估的 RL 环境建设方法。

对于那些宣称“AI 现在已经替我们写了所有代码”的人来说，有一个令人不太舒服的事实：系统越接近生产级，瓶颈就越会从生成代码转移到明确规定需求和验证代码上。这是一个系统工程问题，而不是模型扩展问题。巧合的是，这也正是高级后端工程师整个职业生涯都在磨炼的能力——针对真实数据库而非 mock 编写测试套件；对隐藏在三层结构之下的缺陷进行根因分析；足够精确地记录边界情况，让其他人能够复现你的推理过程。Agent 出现之后，这套技能并没有变得不那么重要。恰恰是它，决定了系统会停留在“演示成功”，还是能够“经受住生产环境的考验”。

我接下来要构建什么

我准备把这个想法做成一个真正的项目，而不是只发表一番吸引眼球的观点：构建一个轻量级 harness，在注入真实失败条件的情况下，对 AI Agent 生成的基础设施代码进行压力测试——包括重试、局部故障、IAM 错误配置，以及我在上文描述的那些具体缺陷类别——并使用确定性的通过/失败检查，而不是凭感觉判断。你可以把它理解为 chaos engineering 与 AI evals 的结合：每次注入一种故障，断言系统不变量而不是执行轨迹，然后看看 Agent 所谓“可以工作”的解决方案究竟是真的可以工作，还是仅仅在 golden path 上运气不错。

我会在公开构建的过程中，把它放到自己的作品集和 GitHub 上——包括种子场景、故障注入 harness，以及一篇分析哪些地方会出问题、为什么会出问题的文章。如果你正在从事任何相关工作，比如 RL 环境、AI evals、chaos engineering，或者你刚刚在生产环境中被 AI 生成的基础设施代码坑过，我很想听听你的经历——欢迎在评论区留言，或者到 GitHub 上找我。

阻碍 Agentic AI 发展的，不会是某个连 for-loop 都写不出来的模型。真正塑造 Agentic AI 未来的，是整个行业能否像热衷于生成能力那样，迅速而认真地对待评估基础设施——golden solution、deterministic test 和 adversarial failure scenario。这就是隐藏在每一条“AI 编写了我们的整个后端”标题背后的问题：不够光鲜、不够性感，却极具融资价值。

如果你也观察到了这种规律——Agent 能在演示中拿满分，却无法通过灾难恢复演练——我真心希望能与你交流经验。

这是生产工程、调试以及 AI 系统评估环境构建系列的第五篇文章。欢迎关注我，接下来几周我会公开记录这个 harness 的构建过程。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。