1135个AI代理PR揭示代码审查的真实盲点

一个GitHub仓库里的26个AI代理角色在五个月内合并了1135个拉取请求。讨论转化为规格说明，规格说明再生成拉取请求，但所有内容必须通过代码审查、安全审查和验收才能合并。作者原本对AI代码审查的多个预判都被事实推翻，这些发现直接关系到任何试图在代码库附近部署代理的开发者。

AI写的代码和AI审查常常漏掉同一类问题。作者发现，模型作为作者时容易产生的缺陷，换成同一个模型去审查时也很难发现。这不是巧合，而是因为它们共享相同的训练数据和模式识别边界。

当模型生成代码时，它倾向于重复自己在训练集中见过的最常见实现路径。审查时，它又用同一套模式去判断“好不好”。结果就是，某个逻辑漏洞或边缘情况处理不当的地方，作者模型没写对，审查模型也看不出来。作者原本以为人机搭配能形成互补，现在看来，在当前模型能力下，盲点是重叠的。

这意味着单纯把代码丢给另一个AI去review效果有限。开发者必须清醒认识到，AI审查不是万能的第二道防线。它可能放大而不是弥补作者的弱点。实际操作中，审查者需要刻意引入不同于模型的视角，比如人为制造对抗样本，或者用静态分析工具去覆盖模型容易忽略的安全和性能边界。

对中国开发者来说，这一点尤其实用。很多团队已经在用Copilot或类似工具辅助编程，如果再叠加AI审查环节，就要避免把所有希望寄托在“AI互查”上。更好的做法是让资深工程师重点盯住模型最容易集体失明的区域，比如并发处理、权限边界、数据验证这些训练数据覆盖不均的场景。

这一发现也解释了为什么很多AI生成代码在上线后才暴露出问题。盲点共享导致审查流程形同虚设。只有当审查者和作者的“思维模型”存在实质差异时，审查才真正发挥作用。目前大多数商用模型在底层逻辑上过于相似，这就放大了这一风险。

26个agent角色把讨论直接变成可合并PR

这个自主软件团队把整个开发流程拆成26个明确角色。从GitHub Discussion开始，一个agent负责把讨论提炼成规格说明书。另一个agent根据规格生成代码和测试。再有专门的agent进行代码审查、安全扫描和最终验收。所有环节串行，只有全部通过才能合并。

这种链条让AI第一次真正跑通了从需求到上线的闭环。Discussion里用户或产品经理提出的功能点，经过agent转化后变成结构化的spec，避免了自然语言的模糊性。spec再驱动代码生成，保证了可追溯性。

作者强调，这套流程里最关键的是“nothing merges until code review, security review and acceptance all pass”。即使前面agent已经写了1135个PR，也必须经过这三道人工或混合审查关卡。这不是对AI的不信任，而是对生产环境负责的底线。

对中国团队而言，这种工作流有直接借鉴价值。很多国内企业已经在尝试让AI参与需求分析和代码生成，但普遍缺少严格的审查闭环。引入类似的分角色agent系统，可以把产品经理的零散意见快速变成可执行的PR，但前提是保留人工审查环节，不能让agent自己决定合并。

实际落地时，团队可以先从小规模仓库开始试验。把Discussion作为入口，配置不同agent承担spec writer、coder、reviewer、security checker等角色。工具链上可以结合GitHub Actions实现自动触发和状态流转。重点是把审查标准做成可执行的 checklist，避免agent绕过关键检查。

这种链条也暴露了当前AI的局限。agent虽然能把讨论变成代码，但生成的spec质量高度依赖初始Discussion的清晰度。如果产品需求本身模糊，agent转化的spec就会带着错误往下游传递。因此，人类在Discussion阶段的把关仍然不可或缺。

1135个PR推翻了作者最初的大部分假设

作者坦言，自己在项目启动前对AI代码审查有不少预判，结果五个月和1135个PR下来，大部分都被现实推翻。

他最初以为AI生成的代码会特别“干净”，风格统一，容易审查。实际却发现agent代码常常出现重复模式，虽然语法正确，但可维护性并不比人类新手高多少。另一个错误假设是认为AI会严格遵循spec，结果很多PR在实现细节上偏离了最初的规格说明，需要审查者强行拉回。

作者还曾认为安全问题会是AI代码的最大风险点。但跑下来发现，真正频繁出现的反而是逻辑完整性缺陷，比如边界条件缺失、错误处理不全。这些问题模型在生成时容易忽略，审查时也容易放过。

1135个PR的数据让作者意识到，AI在处理复杂业务逻辑时的表现远不如预期。模型擅长样板代码，却在需要领域知识的场景下频繁出错。这直接颠覆了他早期“AI能大幅提升开发速度”的乐观判断。

对中国开发者来说，这些被推翻的假设有现实警示意义。很多团队把AI工具当作生产力倍增器，却没有提前准备好应对其系统性弱点。正确的态度是把AI当作初级开发助手，而非替代者。审查重点应该放在逻辑正确性、业务一致性和长期可维护性上，而不是只看代码是否能跑。

作者没有给出具体哪五个真相被推翻，但从整体叙述能看出，他对AI自主性的预期明显下调了。AI团队不是“无人值守”的，它仍然需要人类在关键节点持续介入。这对当前热衷于全AI开发流程的国内创业团队是个提醒：1135个PR的代价是五个月的持续人工审查投入。

安全审查和验收成为agent PR的硬性门槛

在这个实验里，没有任何PR能绕过安全审查和验收直接合并。这两条被设置为硬性门槛，任何agent生成的代码都必须通过才能进入主分支。

安全审查主要检查权限使用、依赖漏洞、敏感数据处理等问题。验收则聚焦功能是否真正满足spec、测试覆盖率、性能表现等。作者发现，只有把这两关做实，AI团队才不会把低质量代码持续注入代码库。

这一设置的必要性在1135个PR过程中得到充分验证。早期曾有少量PR在安全检查前合并，结果暴露出了潜在风险。此后严格执行门槛，问题发生率明显下降。

对中国开发者而言，这一点特别重要。国内不少团队在引入AI编码工具时，安全意识相对滞后。直接把AI生成的代码合并进生产仓库的情况并不少见。这套实验证明，安全审查不能是事后补救，而必须成为前置强制环节。

具体建议是建立双人审查机制：一个AI reviewer做初步扫描，人类安全专家做最终判断。同时把验收标准量化，比如要求单元测试覆盖率达到80%以上，关键路径必须有集成测试。工具上可以集成SonarQube、Dependabot或国内的代码安全扫描服务，实现自动化初步过滤。

硬性门槛也带来了额外成本。1135个PR意味着同样数量的安全和验收工作量。这提醒团队，在规模化使用AI agent前，必须先把审查人力和流程准备好，否则很容易出现质量滑坡。

这些经验适用于任何把agent放进代码库的人

作者反复强调，这篇文章不是推广某个特定工具，而是总结了把agent引入代码库后的普遍规律。这些教训对使用任何AI编码助手或自主agent系统的开发者都成立。

无论你是用开源的Auto-GPT类项目，还是商业化的GitHub Copilot Workspace，核心问题是一致的：AI擅长生成代码，却不擅长判断代码是否真正“好”。审查者的角色不能被完全替代。

对中国开发者来说，这意味着需要调整现有AI辅助工作流。过去很多团队把重点放在“怎么让AI写得更快更多”，现在应该转向“怎么让AI写的代码更安全可维护”。具体做法包括：建立AI代码审查 checklist，重点覆盖盲点区域；定期人工审计AI生成模块的质量；把agent限制在低风险模块，避免核心业务逻辑完全依赖AI。

另一个实际意义是人才结构的变化。未来开发者需要同时具备编码能力和AI审查能力。能有效指出AI代码缺陷的人会变得更有价值。这对中国高校计算机教育和企业培训都提出了新要求。

经验还表明，agent系统适合处理重复性、高规则性的任务，而不适合创新性或高不确定性的工作。中国企业在落地时应该先从工具类、辅助类功能开始试点，积累足够数据后再扩大范围。

agent代码审查中仍存在未解决的开放问题

尽管1135个PR提供了丰富观察数据，但作者也留下了几个尚未给出明确答案的问题。

比如，如何量化AI审查的有效性？目前主要靠人工判断，缺少可靠的自动化指标。另一个问题是，当模型版本升级后，之前的盲点是否会改变？作者没有给出长期跟踪数据。

此外，如何平衡审查成本和开发速度也是开放议题。严格的安全和验收门槛提高了质量，但也拖慢了整体迭代节奏。在资源有限的创业团队里，这可能成为瓶颈。

对中国开发者而言，这些开放问题意味着实践仍需持续迭代。目前还没有成熟的“AI代码审查方法论”，每个团队都需要根据自身业务特点摸索适合的流程。

作者的实验提供了一个有价值的起点，但远不是终点。未来可能需要专门的AI审查模型、针对agent代码的静态分析规则，以及更精细的人机协作界面。这些方向都值得持续关注和实验。

整体来看，这1135个PR最有价值的贡献不是证明AI能替代人类，而是清晰展示了当前AI在代码生成和审查上的真实边界。对任何准备大规模引入agent的团队来说，先理解这些边界，再制定应对策略，才是务实的路径。

参考来源