一位开发者用AI写权限判断逻辑,同一套isActivehasPermissionisSuspended条件,在route handler、后台任务、API端点、webhook里各写了一份,四份代码几乎一模一样。等他要第五个端点时,AI没有抽取共用helper,直接把前四份逻辑原样复制了一遍。他得出一个结论:AI在"学"他的坏习惯,而且学得比他自己还快。

这个说法流传很广,听起来也很有画面感。但它可能问错了机制,也只看到了一半证据。

复制粘贴不新鲜,新鲜的是复制的速度

四处重复的访问权限判断,是软件工程里最经典的代码异味之一。DRY原则(Don't Repeat Yourself)几十年前就在提醒这类问题:同一段逻辑散落在多个文件里,以后改一次就要改四次,漏一处就是一个漏洞。

反常的地方不在这个异味本身,而在于复制的成本变了。人工手写时,复制四份需要一个人手动敲四次,过程里总有机会停下来问一句"是不是该抽个函数"。AI辅助下,这个停顿几乎消失——五份、十份重复,生成速度快过人意识到问题的速度。

AI没有"学坏",它只是在抄现场

关键的澄清是:多数消费级编码助手,在一次会话里并不会更新模型权重。它照抄前四份逻辑,靠的是读取当前打开的文件最近的改动仓库里已经存在的模式——这是上下文模仿,不是训练。

这个区别决定了应对方式完全不同。如果真是"模型被训练坏了",换个项目问题照样在;如果只是"仓库模式模仿",换一个干净仓库,同一个模型立刻恢复正常。第一份重复代码被merge进仓库的那一刻,才是真正的分水岭——不是模型变差,是环境变了。

误会 vs 真相:AI在"学"什么 常见说法 "AI被我训练坏了" 暗示模型权重被污染 换个项目问题还在 听起来像不可逆 更准确的机制 "AI在抄仓库现场" 读取仓库现有模式 换干净仓库即恢复 可逆,看首份代码
焊进仓库的坏代码,AI只会照单全收。

GitHub的数据说好,论文说险

反证来了。GitHub自己做过一项研究:Copilot辅助写出的代码,在可读性上提升3.62%,可靠性提升2.94%,可维护性提升2.47%,简洁性提升4.16%。这四个数字都在涨,和"AI会放大坏习惯"的直觉正面冲突。

学界的解读更细。一份基于SonarQube等质量指标的实证研究,专门比较LLM生成代码和人工代码在可维护性、可靠性、修复成本上的差异;一篇覆盖104篇文献的综述,提出了"快速集成债务"(fast-integration debt)这个概念——代码merge的速度远快于评审和抽象的速度,债务不是显性变差,而是悄悄堆积。另有大规模GitHub仓库研究,专门追踪命名规范、复杂度和代码重复度的长期趋势。

两组证据合起来看:整体质量指标在涨,但跨文件的语义重复,恰恰是这些指标最不敏感的盲区。SonarQube这类工具擅长抓孤立的坏味道,不擅长认出"这五处判断逻辑其实是同一件事"。

GitHub自测:代码质量在涨 +3.62% 可读性 +2.94% 可靠性 +2.47% 可维护性 +4.16% 简洁性 但指标未必测到跨文件重复

工具不是铁板一块

原文没细说用的是哪款工具,但业内经验是:同一个问题,不同助手表现不一样。偏保守的助手更倾向照抄当前文件已有风格;支持跨文件检索、能做大范围重构的工具,更容易在改动前提醒"这四处逻辑重复了,要不要抽个helper";偏对话式的助手,常常会先问一句"这里是不是该抽象一下"再动手。

这意味着原文的警示不是所有AI编程都必然如此,而是工具默认行为加上使用习惯共同决定的结果。同一个人换一套工具、换一种提问方式,第五次生成可能就从"复制"变成"重构"。


焊在仓库里的,才是真正的债

作者最后那句反思方向是对的:他以为在把维护工作外包给AI,实际是在训练AI延续自己的偷懒。只是"训练"这个词用错了对象——真正被固化的不是模型,是仓库,是团队的默认风格。

  • 结论.坏代码一旦合并进仓库,AI下一次生成会把它当作"这里的规矩",复制速度比人手写快得多,越往后越难靠一句prompt清干净。
  • 风险.常规质量指标可能整体向好,但跨文件的语义重复恰恰是这些指标测不出来的盲区,容易让团队误以为"用了AI,代码就自动变好"。

孔子说"其身正,不令而行",放在这儿意思相近:代码库的风气正不正,不看AI嘴上说不说最佳实践,看merge进去的第一份代码长什么样。第一份权限判断代码要是当场抽了helper,后面四份根本不会长成复制粘贴的模样。

人类真正该盯紧的时刻,是第一次merge按下确认键那一下——不是AI第五次照抄的时候。