过去我们认为好代码是「别人打开能看懂的」。好的命名、清晰的控制流、一致的格式。MSR 2026 年的一项研究分析了 403 次 AI agent 专门为「改善可读性」做的提交，结果挺有意思，56.1% 的提交反而让可维护性指数下降了，42.7% 让圈复杂度上升了（圈复杂度就是代码里独立执行路径的数量，值越高说明条件分支越多、代码越绕）。

作者管这叫 cosmetic readability，代码看起来整洁，命名没问题，注释该有的地方都有，但控制流比人类写的更绕。PR 审查一眼扫过去觉得「挺好」，实际上结构更糟了。

我自己在 Claude Code 写 Elisp 代码时也有类似感受。Claude 产出的代码结构规整、命名合理，但几乎不会利用 Elisp 的宏来消除重复模式。熟悉 Lisp 的开发者一眼就能看出「这里应该抽成一个宏」，但 LLM 倾向于写出完整的重复结构。代码看起来没问题，可维护性也不差，就是思维方式不对。它没学会用语言的特性去简化抽象。

多项数据都在说这事儿。一项研究发现，AI 生成代码的问题率是人类的 1.7 倍，其中可维护性错误高出 1.64 倍，逻辑错误高出 1.75 倍。

另一项受控比较（642 个 AI 方案对比 107 份专家代码）发现，AI 代码的圈复杂度高 34%，代码重复率是 2.1 倍，运行速度慢 15% 到 40%，内存也多占 25%。

问题在于这些都不会在测试中暴露。功能正常，测试通过，可质量在走下坡路。行业调查预测，到 2026 年有 75% 的技术领导者会因为 AI 驱动的开发速度而面临中等到严重的技术债务。少量 AI 生成的代码块勉强能接受，可如果一个仓库里三分之一都是这种「勉强能接受」的代码，累积的债务就超出能承受的范围了。

这是最吓人的数字。Veracode 测试了 80 个编码任务、100 多个 LLM，发现 45% 的生成代码引入了 OWASP Top 10 范围内的漏洞。OWASP Top 10 是 Open Web Application Security Project 发布的十大最关键的 Web 应用安全风险清单，常见条目包括 SQL 注入、跨站脚本（XSS）、认证绕过等。他们在 2026 年春天，GPT-5.1、Gemini 3 等最新模型出来后做了跟进测试，安全表现跟两年前的模型比，几乎没有差别。

根因在训练目标上。LLM 被优化的是「代码能通过测试、能编译、能满足 prompt」，跟安全性没啥关系。参数化查询和字符串拼接的 SQL 都能返回同样的结果行，模型没有动力去区分它们。跨站脚本（XSS）只有 12% 到 13% 的生成结果是安全的，日志注入的失败率是 88%。Java 的安全失败率超过 70%，原因也简单，训练数据里塞满了安全意识普及之前的旧代码。

这事儿不是模型变大就能自然解决的。现有训练信号不奖励安全，要修就得把安全纳入训练目标。但推动模型迭代的主要动力是「生成能跑的代码」，不是「生成安全的代码」。

代码能通过所有测试，但实现的业务逻辑是错位的。LLM 不知道你的授权模型、租户边界、数据分类规则。它满足了你写在 prompt 里的可见需求，但漏掉了你心里知道但没写进去的隐性约束，那些「这还用说」的东西。

这方面有一个模糊的共识，需要具备「意图感知」能力的验证工具，追踪原始 prompt、仓库历史、文档来检查生成的代码和实际需求之间是否一致。但这个领域还在早期阶段，连「怎么给意图忠实度打分」都没定义清楚。

单个 AI 生成的 PR 看起来没问题，代码风格也合规。但几百个这样的 PR 叠加几个月后，整个代码库的架构会慢慢漂移，命名约定散了，抽象模式乱了，模块边界模糊了。架构漂移不是新问题，但当 GitHub 月推送 8200 万次、其中 41% 是 AI 辅助的时候，漂移速度已经不是人类审查能跟上的了。