大家好，我是陈哥。
前几天，我看了一个 “The Future of Coding is Here” 的分享会视频，大概内容是讲如何完全依靠 AI 来生成代码。
视频中，有一位程序员提出了质疑：“如果说你不进行任何打开代码筛查的动作，我觉得这样的代码上线都是不负责任的，不仅不负责，而且是没办法去用的。”
这番话其实点明了当下 AI 编程的边界。在 AI Coding 时代，AI 只是一个辅助开发的提速工具，一套系统后续长久的 迭代与维护，最终还是要依靠程序员把控。
随着 AI 被训练得越来越成熟，越来越多的人开始用 AI 辅助编程。2025 年，Fastly 对 791 名开发人员进行调研后发现，32% 的资深开发人员所交付的代码，有超过一半是 AI 生成的。
但 AI 在生成代码方面存在着天然短板。它确实能快速搭建框架，但在业务逻辑、安全防护、边界异常等方面存在缺陷。如图所示，AI 显然造成了更多的技术债务。
这就意味着企业要更加重视代码审查。正如 Graphite 工程师 Greg Foster 所说：“如果上线的代码没有经过任何工程师的审查，那么企业将背负着极高的运营风险。”
《Engineering in the Age of AI: 2026 Benchmark Report 》数据显示，伴随 AI 工具的普及，每位作者提交的 PR 数量同比增长了 20%，但质量却受到了影响，每个 PR 的事故增加了 23.5%，变更失败率也上升了 30%。
代码产出效率确实提升了，但人工校验的节奏却远远跟不上产出速度，这就让代码审查直接成为项目迭代的核心瓶颈。
我们在整顿研发流程时，发布的《禅道研发流程规范 3.0》中就已经提出了提交限制：单次 commit 修改行数是 50；单次 push 行数是 200。
所以，面对 AI 编码的普及，企业更应该做出改变，主动重构原有研发流程，尝试推行增量拆分开发规范：将 AI 一次性生成的大块代码，拆解为多个体量小巧、功能独立的提交记录，从而降低单次审查的压力。
同时，还可以配套多层自动化校验工具，减轻人工审查负担：
流程改造只是第一步。在多人协作的企业环境中，代码错误造成的修复成本更高，周期也会更长，所以一定是人来最终决定代码，任务场景都不能完全放权给 AI。
安全问题在人工审查时的优先级是第一。《 Gen AI Code Security Report》显示，45% 由 AI 生成的代码都存在安全隐患。
除了代码问题，很多 AI 编程工具和集成 IDE 还衍生出一些新的问题，比如提示注入、数据泄露、RCE 漏洞等。对此，安全合规相关判定是不能交由 AI 独立完成，需要由人去判定。
举个例子，如果代码涉及身份验证、支付、密钥等，代码在合并前必须由人工进行完整的审查。
企业代码审查不只是纠错环节，更是团队成员同步系统设计、业务上下文、历史迭代逻辑的方式。如果这段代码完全由 AI 编写，那么开发人员很难去解释它的实现逻辑，一旦线上后发生故障，排查成本就会大幅飙升。
开源项目 OCaml 之前曾拒绝过一个 13，000 行 AI 生成的 PR，这恰恰说明了这个问题。
代码本身未必存在严重 Bug，但一次性提交这么大规模的改动，本身就会耗尽团队审核精力，更何况 AI 生成代码的审查难度远高于人工代码。
IBM 有条准则：计算机永远无法被问责。
谨记， 无论 AI 贡献了多少代码，都必须由人来承担责任。
明确人工审查的必要性后，企业可以制定一套适合自身的 AI 代码审查标准，我总结出四条可直接落地使用的规范：
企业想要最大化发挥 AI 编码工具的价值，就一定要搭建完善的测试体系。利用 AI 批量生成各类场景的测试用例，设置测试覆盖率门槛，通过自动化测试提前拦截 AI 代码潜藏的 Bug。
所有 AI 生成的代码提交前，必须进行单元测试，同步附上完整的测试日志。没有完成测试或者无法验证功能有效性的 PR，直接驳回。
不少团队会借助 AI 工具进行代码审查，但 AI 审查输出的所有问题仅能作为参考意见，最终的风险把控必须由人工完成。
简单通用的代码可以交由 AI 处理，人工要重点关注 AI 容易出错的盲区，如变更是否会引入安全漏洞、是否重复了现有代码、方法是否可维护等。
AI 编程重构了企业研发工作流，也让人工代码审查的价值被重新放大。
现在的代码审查不再只是关注代码本身，更要关注开发者与 AI 协同过程中的业务匹配度。
长期来看，企业要持续完善 AI 研发体系。无论技术如何进步，核心原则是不变：代码审查确保软件满足安全和可维护。
最后，再回到文章开头的事情，我想说：
AI 确实让很多不懂代码的人也能写代码，但做什么事情都要对行业抱有敬畏之心，不要自以为干什么都可以零基础上手。
