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

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

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

• 删掉 AI 所生成的代码可能更好。
• 提交的人连这门编程语言的基本知识都不懂。
• 文档写得一大堆废话，完全是堆砌出来的。
• 前后风格不统一，乱七八糟。
• 写了很多“极端情况”的处理，但根本没测试，反而埋下新问题。
• 瞎加一些没必要的东西，或者用已经过时的工具，还不知道自己为什么要加。

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

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

一些词解释

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

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

为什么我来写这个

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

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

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

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

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

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

良好的代码审查，使得：

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

审查的人也能提升自己。

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

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

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

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

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

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

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

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

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

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

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

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

有些情况其实问题不大

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

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

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

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

一些困境

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

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

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

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

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

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

本文来自微信公众号“CSDN”，作者：Stuart Spence，36氪经授权发布。