“为什么我拒绝 AI 生成的代码请求？”

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

作者 | Stuart Spence 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

有时候我会直接拒绝别人提交的合并请求（MR），甚至不做代码审查以及过多的解释，就是因为这份代码是用 AI 写的，而且写得很糟糕，反而给团队添了麻烦。在工作的时候，我经常遇到这几种情况：

• 删掉 AI 所生成的代码可能更好。

• 提交的人连这门编程语言的基本知识都不懂。

• 文档写得一大堆废话，完全是堆砌出来的。

• 前后风格不统一，乱七八糟。

• 写了很多“极端情况”的处理，但根本没测试，反而埋下新问题。

• 瞎加一些没必要的东西，或者用已经过时的工具，还不知道自己为什么要加。

如果你看到我拒绝了你的 AI 代码，而且没有额外说明，只是把你丢到这个页面来，那就是因为它踩中了上面的坑。

虽然现在有不少研究和讨论都承认 AI 在写代码时能帮上忙，但滥用 AI 也是个新问题。我们需要一些规则来识别这种情况。

一些词解释

• Merge Request（MR，合并请求）：就像一个人写好了一部分东西，然后把它交给团队，问“能不能把这部分合进我们的项目里？”

• Code Review（CR，代码审查）：另一位成员检查这个请求，给出意见，决定要不要采纳。

为什么我来写这个

• 我是搞 AI 和云计算的资深工程师，也带过二十来个学生和新人。

• 我有计算机和教育的背景，既懂技术也懂怎么教人。

• 我的 AI 项目装机量上百万，还能带来稳定收入。

• 平时我也喜欢关注和研究 AI。

• 我不是为了找工作、推销产品或赚广告费才写这些的。

为什么要做代码审查（CR）？

良好的代码审查，使得：

• 提交代码的人能从反馈里学到东西。

• 审查的人也能提升自己。

• 能帮大家检查重要改动是不是靠谱。

• 减少人和 AI 的心智负担，不至于越来越乱。

• 保证项目风格统一，代码更简单。

• 每次改动都能真正让项目变得更好。

• 提交的人要为自己的代码负责，并且说得清为什么这样写。

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

1. 删掉比留下好：比如写了项目里根本用不到的脚本，没清理干净，反而让审查的人多费心。

2. 连基础都不懂：如果你自己都看不懂 AI 给你的代码，我给你意见也没意义。

3. 文档灌水：像复制粘贴了两份几乎一样的说明，说明你根本没认真看。

4. 风格乱套：比如日志或测试写法前后完全不一致，让项目变得越来越复杂。

5. 过度处理边角问题：写了一堆没测试过的特殊情况，结果进步一点，却带来二十个新 bug。

6. 盲目加依赖：用了不必要的工具，甚至是过时的，还解释不清楚为什么要用。

有些情况其实问题不大

这些并不是死规定。如果遇到下面这些情况，我反而更可能接受 AI 写的代码，或者愿意帮忙审查：

• 这段代码只是临时用的，或者一次性的分析，不需要长期维护。能跑起来就行。

• 提交的人写清楚了为什么要用 AI、用了多少、以及自己做了哪些额外验证。

• 这只是个边缘的小功能，不会影响到系统的核心部分。

一些困境

作为一个带团队的人、老师，同时也自认为是个好相处的人，我其实很纠结：当我觉得某个新人的 AI 代码对他本人、对团队、甚至对项目都有害时，该怎么面对？

为什么这个新人会提交 AI 生成的代码？这是聪明的选择，还是只是偷懒？

我要不要直截了当地指出“这就是 AI 糊弄的垃圾”，还是应该换一种方式？

对我来说，什么时候该认真支持 AI 的好用法，什么时候该坚决拒绝 AI 的坏用法，这并不总是那么清楚。光是写下这些思考，就已经对我自己有帮助了。

毕竟，现在没人能真正说清楚：AI 糊弄出来的代码，会在长远上怎么影响团队的技术债务（积累的问题）和成员的成长。

如果 AI 真的在推动软件开发往好的方向走，那团队负责人也需要跟着改变；但如果它让软件开发往坏的方向走，那我们就需要站出来抵制。

【活动分享】2025 全球机器学习技术大会（ML-Summit）北京站将于 2025 年 10 月 16-17 日在北京威斯汀酒店举办。大会共 12 大主题、50+ 海内外专家，聚焦大模型技术和应用变革。详情参考官网：https://ml-summit.org (或点击原文链接）。