AI生成代码的审查边界：为何我拒绝你的合并请求

随着AI编程工具日益普及，加拿大政府一位高级计算机科学家兼教育工作者撰写了一篇题为《为什么我拒绝你的 AI 生成的 MR》的文章。他并非全盘否定AI，而是旨在厘清边界：在何种情况下AI生成的代码可被接受，在何种情况下必须坚决拒绝。文中，他分享了作为团队负责人的真实困境——如何应对新人对AI的依赖和滥用，并给出了代码审查中的底线与判断标准。

有时我会直接拒绝他人提交的合并请求（MR），甚至不进行代码审查或过多解释，只因这些代码由AI生成且质量低劣，反而给团队增添麻烦。工作中，我常遇到以下几种情况：

• 删除AI生成的代码可能比保留更好。
• 提交者缺乏对该编程语言的基本了解。
• 文档冗长空洞，纯属堆砌内容。
• 代码风格前后不一，杂乱无章。
• 过度处理“极端情况”但未经测试，反而埋下新隐患。
• 盲目添加不必要组件或使用过时工具，且无法说明原因。

如果你发现我拒绝了你的AI生成代码，且未额外说明，仅将你引至此页面，那说明它触及了上述问题。

尽管当前许多研究和讨论认可AI在编码中的辅助作用，但滥用AI已成为新挑战。我们需要规则来识别此类情况。

术语解释

合并请求（MR）：如同个人完成部分工作后，提交给团队并询问“能否将此部分集成到项目中？”

代码审查（CR）：由其他成员检查该请求，提供反馈，决定是否采纳。

为何我来撰写此文

我是一名专注于AI和云计算的资深工程师，曾指导过二十余名学生和新人。

我拥有计算机与教育背景，既精通技术也擅长教学。

我的AI项目装机量已超百万，并能带来稳定收入。

我平时热衷于关注和研究AI领域。

我撰写此文并非为了求职、推销产品或赚取广告费。

为何要进行代码审查（CR）？

良好的代码审查能带来以下益处：

提交者可从反馈中学习提升。

审查者也能锻炼自身能力。

帮助团队检查重要改动是否可靠。

减轻人和AI的认知负担，避免混乱加剧。

确保项目风格统一，代码更简洁。

每次改动都能切实优化项目质量。

提交者需对代码负责，并能清晰阐述编写理由。

为何有些MR根本不值得审查？

删除优于保留：例如编写了项目中根本用不到的脚本，未清理干净，反而增加审查负担。

缺乏基础知识：若提交者自身无法理解AI生成的代码，提供意见也意义不大。

文档灌水：如复制粘贴近乎相同的说明，表明提交者未认真审阅。

风格混乱：例如日志或测试写法前后不一致，让项目更复杂。

过度处理边缘问题：编写大量未测试的特殊情况处理，虽略有改进却引入众多新缺陷。

盲目添加依赖：使用不必要或过时的工具，且无法解释原因。

有些情况其实可接受

这些并非绝对规则。在以下情况下，我可能更愿意接受AI生成的代码或协助审查：

代码仅用于临时任务或一次性分析，无需长期维护。能正常运行即可。

提交者明确说明了使用AI的原因、使用程度及自行进行的额外验证。

这只是边缘小功能，不影响系统核心部分。

面临的困境

作为团队领导者、导师，同时自认为易于相处的人，我常感纠结：当我认为新人的AI生成代码对其个人、团队或项目有害时，该如何应对？

为何新人会提交AI生成的代码？这是聪明选择，还是仅仅偷懒？

我该直接指出“这是AI敷衍的垃圾”，还是换种委婉方式？

对我而言，何时应支持AI的正确使用，何时应拒绝AI的误用，并非总是清晰。仅记录这些思考，已对我有所帮助。

毕竟，目前无人能确切说明：AI敷衍生成的代码，将如何长期影响团队的技术债务（积累问题）和成员成长。

如果AI真的推动软件开发向好发展，团队负责人需相应调整；但如果它导致软件开发恶化，我们必须站出来抵制。