警惕AI编程的“老年痴呆症”：为什么代码越改越乱？

“本来越修改应该越好，但是AI不一样，越修改可能越乱七八糟。”

最近，一位开发者在吐槽AI辅助编程时，用了一个极其精准的比喻——“老年痴呆症”。这并非个例，而是许多深度使用AI编程工具（如Cursor、Copilot等）的开发者共同面临的困境。我们原本指望AI能像一位不知疲倦的资深工程师，帮我们把代码打磨得越来越完美，但现实往往是：代码在不断的AI修改中逐渐失去了原本的逻辑脉络，甚至变成了一座摇摇欲坠的“屎山”。

为什么AI会患上“老年痴呆症”？

AI在修改代码时表现出的“越改越乱”，本质上是因为它缺乏人类程序员的“记忆”与“全局观”。

1. 概率预测而非逻辑理解
AI本质上是一个基于海量代码训练出来的“概率引擎”。当你让它修改一段代码时，它并不是在理解你的业务逻辑，而是在做“模式匹配”。它会根据概率输出一个“看起来最合理”的代码片段。这就导致了一个致命问题：AI在乎的是“像不像”，而开发者在乎的是“对不对”。当代码量变大，AI无法像人类一样在脑海中维持整个项目的架构地图，它只能看到眼前的片段，因此改着改着，逻辑就容易跑偏。

2. 增量式变更与“屎山雕花”
研究发现，当AI对系统不完全理解时，它倾向于通过“打补丁”的方式来规避风险。比如，它不敢轻易修改原有的复杂逻辑，而是选择在外面套一层新的包装器、创建新的辅助方法，甚至生成冗余的“OrderService2”、“最终改进版服务”。这种增量式的变更，虽然暂时解决了眼前的问题，却在不断堆砌冗余的抽象层，最终导致代码库变得臃肿不堪，维护成本极高。

3. 破坏性修改与行为漂移
AI在接到“简化代码”或“重构”等模糊指令时，往往会字面意义上地执行“清理”工作。它可能会把人类程序员特意保留的“冗余”错误处理机制删掉，或者为了追求代码的简洁而移除了某些特定场景下的业务分支。更危险的是，AI会自作聪明地引入一些“合理”的假设，比如“如果值缺失就默认为空字符串”或“调用失败就直接重试”。这些行为漂移在短期内可能让程序跑通，但在生产环境中却埋下了巨大的安全隐患。

数据背后的真相：AI代码的缺陷率更高

这种“老年痴呆”般的修改方式，直接导致了代码质量的下降。CodeRabbit公司的一项最新研究分析了GitHub上的数百个拉取请求，发现AI生成的代码在逻辑、可维护性、安全性和性能等维度上，平均比纯人工编写的代码多出了约1.7倍的缺陷。

特别是在逻辑正确性上，AI生成的代码增加了75%的问题，包括业务逻辑错误和不安全的控制流。而在可读性方面，由于命名不一致和格式混乱，AI代码的问题更是增加了三倍多。这也解释了为什么Linux内核社区的维护者Linus Torvalds会对AI代码嗤之以鼻，甚至将其称为“AI垃圾代码（AI slop）”——表面看起来语法正确，但在边界条件和异常处理上却充满了漏洞。

如何治好AI的“老年痴呆”？

既然AI目前还无法完全替代人类进行复杂的架构思考，我们在享受它带来的效率红利时，就必须建立一套严格的防御机制。

1. 明确边界：让AI做“打字员”，你做“架构师”
不要试图把整个项目丢给AI让它“优化”。应该将AI限制在确定性高、重复性强的任务中，比如编写单元测试、生成简单的CRUD接口或前端原型。对于核心业务逻辑、认证授权、加密算法等关键模块，必须由人类主导。

2. 建立“AI原生”的审查流程
永远不要直接合并未经审查的AI代码。Linux内核社区已经出台了相关准则，要求使用AI辅助的代码必须明确标注（如使用Assisted-by标签），并且责任完全由提交者承担。在实际开发中，我们可以建立“AI+人工”的双轮审查机制：先让AI进行基础的规范检查，再由人类聚焦于业务架构和逻辑连贯性。

3. 小步快跑，提供充足的上下文
为了避免AI“断片”，在让它修改代码时，尽量提供丰富的项目上下文，比如相关的类型定义、接口文档或架构约束。同时，遵循“小步快跑”的原则，改一点检查一点，利用静态代码分析工具（如ESLint、SonarQube）进行实时校验，一旦发现AI开始“胡言乱语”，立即回滚。

AI编程工具无疑是一把双刃剑。它能极大地提升我们的编码速度，但如果缺乏人类的把控，它也会迅速制造出难以维护的混乱。只有当我们清醒地认识到AI的局限性，并始终保持对代码的绝对掌控权时，才能真正避免陷入“越改越乱”的死循环。