AI Coding时代仍要以人为本

大家好，我是陈哥。

前几天，我看了一个“The Future of Coding is Here”的分享会视频，大概内容是讲如何完全依靠AI来生成代码。

视频中，有一位程序员提出了质疑：“如果说你不进行任何打开代码筛查的动作，我觉得这样的代码上线都是不负责任的，不仅不负责，而且是没办法去用的。”

这番话其实点明了当下AI编程的边界。在AI Coding时代，AI只是一个辅助开发的提速工具，一套系统后续长久的迭代与维护，最终还是要依靠程序员把控。

一、企业构建适配AI编码的研发流程

随着AI被训练得越来越成熟，越来越多的人开始用AI辅助编程。2025年，Fastly对791名开发人员进行调研后发现，32%的资深开发人员所交付的代码，有超过一半是AI生成的。

但AI在生成代码方面存在着天然短板。它确实能快速搭建框架，但在业务逻辑、安全防护、边界异常等方面存在缺陷。如图所示，AI显然造成了更多的技术债务。

ai-coding-1

这就意味着企业要更加重视代码审查。正如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-coding-2

明确人工审查的必要性后，企业可以制定一套适合自身的AI代码审查标准，我总结出四条可直接落地使用的规范：

企业想要最大化发挥AI编码工具的价值，就一定要搭建完善的测试体系。利用AI批量生成各类场景的测试用例，设置测试覆盖率门槛，通过自动化测试提前拦截AI代码潜藏的Bug。

所有AI生成的代码提交前，必须进行单元测试，同步附上完整的测试日志。没有完成测试或者无法验证功能有效性的PR，直接驳回。

不少团队会借助AI工具进行代码审查，但AI审查输出的所有问题仅能作为参考意见，最终的风险把控必须由人工完成。

简单通用的代码可以交由AI处理，人工要重点关注AI容易出错的盲区，如变更是否会引入安全漏洞、是否重复了现有代码、方法是否可维护等。

ai-coding-3

AI编程重构了企业研发工作流，也让人工代码审查的价值被重新放大。

现在的代码审查不再只是关注代码本身，更要关注开发者与AI协同过程中的业务匹配度。

长期来看，企业要持续完善AI研发体系。无论技术如何进步，核心原则是不变：代码审查确保软件满足安全和可维护。

最后，再回到文章开头的事情，我想说：

AI确实让很多不懂代码的人也能写代码，但做什么事情都要对行业抱有敬畏之心，不要自以为干什么都可以零基础上手。