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真的在推动软件开发向好的方向发展，那么团队领导也需要随之改变；但如果它让软件开发走向坏的方向，我们就需要站出来抵制。