企业级 AI Coding 还有一堆问题，并没有像PR一样说的这么好用

推荐语

企业级AI写代码远未成熟，80%的“正确”背后隐藏着20%的生产级隐患。

核心内容：
1. AI代码的“80%问题”：功能可用但缺失关键生产级逻辑
2. 代码与项目架构的脱节：风格、库和模式不匹配的普遍困境
3. 上下文衰减效应：对话越长，AI生成代码的质量越差

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

如果你的团队正在用 AI 写代码（随便哪个AI工具），下面这些问题你大概率正在经历，或者即将经历。

一、80% 问题：功能写完了，但不能上线

AI 写代码最大的幻觉不是"它写错了"，而是"它写对了——但只对了 80%"。

AI 做得很好的 80%：

• CRUD 接口、标准 API 模式

• 基础参数校验、Happy Path 测试

• UI 组件渲染、状态管理

• 数据库查询、ORM 操作

AI 系统性遗漏的 20%：

• 重试逻辑、熔断器、限流

• 幂等键（网络超时时防止重复提交）

• 结构化日志、分布式 Tracing、告警埋点

• 跨接口一致的认证/鉴权中间件

• 边界条件、并发竞态、回滚策略

举个真实场景：

AI 生成了一个支付接口：

app.post('/api/payments', async (req, res) => {
  const { amount, currency, customerId } = req.body;
  const charge = await stripe.charges.create({ amount, currency, customer: customerId });
  await db.payments.insert({ chargeId: charge.id, amount, status: charge.status });
  res.json({ success: true, chargeId: charge.id });
});

• 第 1 周：测试全过，上线了

• 第 3 周：用户报告网络超时后被扣了两次钱（没有幂等键）

• 第 6 周：安全审计发现 4 个支付接口里有 3 个加了认证中间件，1 个漏了

这不是 bug。AI 写的每一行代码都是"正确的"。但它不是生产级代码。

二、代码不属于你的项目

这是最普遍的问题。AI 生成的代码"功能正确"但"无法采纳"，因为：

结果：你花 10 分钟让 AI 生成代码，花 30 分钟把它改成"属于这个项目的样子"。有时候还不如自己写。

三、Context Rot：对话越长，质量越差

这是有数据支撑的事实：

• 模型在短 prompt 下准确率 90%+，在 32,000 token 下急剧下降（Adobe 2025 研究）

• Agent session 中，观察结果（文件内容、测试输出）占 84% 的 token（JetBrains 2025）

• mabl 团队的 75 个仓库部署中，40% 的任务失败是 context drift 导致的

实际表现：

• 对话前 10 轮，AI 还记得你的架构规则

• 对话 20 轮之后，它开始忘记之前的约定

• 对话 30 轮之后，它可能推翻之前自己写的代码逻辑

• 对话 40 轮之后，让它"继续"基本等于让它重新开始

你越想在一个 session 里做完整件事，质量越低。

四、产出速度的幻觉

METR 2025 研究（目前最严格的对照实验）：

• 16 位资深开发者（平均参与大型开源项目多年）

• 246 个真实任务（bug 修复、feature、重构）

• 随机分配使用/不使用 AI 工具

结果：使用 AI 工具的组，完成任务实际慢了 19%。

但实验后，开发者自己估计 AI 帮他们快了 20%。主观感受和客观数据完全相反。

为什么：

• 代码接受率不到 44%——超过一半的 AI 建议被废弃

• 审查、测试、修改 AI 代码的时间超过了它"帮你省"的时间

• 在复杂上下文中，AI 产出需要大量人类"翻译"才能融入项目

Stack Overflow 2025 调查：

• 只有 16.3% 的开发者认为 AI "大幅"提升了生产力

• 41.4% 认为几乎没有效果

注意：这不是说 AI 没用。而是说"AI 让你快 10 倍"这种话，至少目前不是事实。

五、从不重构，只会叠加

GitClear 对 2.11 亿行代码的纵向研究（2020-2024）：

AI 的默认行为是"生成新代码"而不是"复用已有代码"。它不会说"这个功能你项目里已经有了，不需要再写"。

实际后果：

• 项目里出现 3 个功能相同但实现不同的工具函数

• 改一个 bug 要改 4 个地方，因为逻辑被复制了 4 份

• 代码量膨胀但实际功能没增加

六、安全是逐个接口加的，不是架构级别的

AI 写安全代码的方式是"你问它加它就加"——而不是在架构层面统一处理。

典型问题：

• 4 个 API 中 3 个有鉴权中间件，第 4 个漏了

• 每个接口自己做输入校验，规则不统一

• 认证 token 的刷新逻辑在 happy path 下正常，边界情况（过期、并发刷新）没处理

• 渗透测试通不过，不是因为代码有 bug，是因为安全策略不一致

Veracode 2025 报告：

• AI 生成的代码在 45% 的情况下引入安全漏洞

• Java 最严重：70%+ 的 AI 代码有安全缺陷

• 86% 的代码样本无法防御 XSS

• 88% 对日志注入攻击毫无防护

七、幻觉不只是"编造函数名"

代码幻觉比聊天幻觉更隐蔽，因为代码"看起来对的"。三种常见模式：

1. 幻觉 API签名（占幻觉的 20.4%）

AI 写了 stripe.charges.create({idempotencyKey: ...})，但实际 Stripe SDK 的参数名是 idempotency_key放在 options 里。代码能跑，但幂等不生效。

2. 幻觉依赖包

AI 推荐 npm install response-validator——这个包根本不存在。或者推荐一个名字接近但已经弃用 3 年的包。

3. 修改代码时幻觉加倍

研究表明，让 AI 修改已有代码（而非从零生成）时，幻觉率翻倍。因为它需要同时推理旧代码和新代码的状态，partial context 极易出错。

八、Debug AI 代码比 Debug 自己的代码更难

为什么：

1. 理解成本：你要先理解一段不是你写的、也不是你同事写的代码逻辑

2. 命名误导：AI 可能用了看起来合理但实际含义不同的变量名

3. 隐含假设：AI 代码里藏着你不知道的假设（比如它假设某个字段永远不为 null）

4. 错误链条：AI 的一个早期错误可能在后续 5 个文件里传播

Stack Overflow 数据：45% 的开发者表示 debug AI 代码比预期耗时更长。

这是最坑的：你以为 AI 省了写代码的时间，结果在 debug 上花了更多时间。净效率可能是负的。

九、多文件改动时容易互相矛盾

AI 一次处理一个文件没问题。但当改动涉及多个文件时：

• 在 A 文件里定义了一个接口，在 B 文件里用的时候签名对不上

• 在 Service 层加了一个参数，但 Controller 层没传

• 修改了数据库 Schema，但 ORM Model 没同步

• 改了一个公共工具函数的返回值，但调用方没更新

特别是在多 Agent 协作时（Multi-agent workflow），不同 Agent 对同一个 API contract 的理解可能不一致。

十、测试"通过"但"无意义"

AI 写的测试有一个通病：测试在通过，但没在测你关心的东西。

典型表现：

• 测试只覆盖 happy path，不测边界条件

• Mock 了所有外部依赖，测试其实只在测 mock

• 断言太弱——只断言"没抛异常"或"返回了 200"，不验证具体数据

• 测试了 AI 自己写的实现细节（把实现当成 spec）

OpenAI Harness 团队的经验：他们每周五花 20% 的时间清理"AI slop"——通过测试但实际质量不行的代码。后来他们被迫建了自动化 GC 机制来持续清理。

十一、"Almost Right" 是最贵的 bug

Stack Overflow 2025：66% 的开发者表示最大的挫败感是 AI 给出"几乎对了但不完全对"的答案。

"几乎对"比"完全错"更危险，因为：

• 完全错的代码一眼看出来，扔掉重写

• "几乎对"的代码你可能不会仔细审查就接受了

• 等到出问题的时候，你已经在这段代码上面建了 5 层逻辑

十二、项目越大，AI 越不好使

Google 2025 DORA Report：

• AI 采用增加 90% 的同时

• Bug 率增加 9%

• Code Review 时间增加 91%

• PR 体积增加 154%

大型项目中的 AI 代码需要更多人力来审查，而不是更少。

十三、非确定性：同一个 prompt 不同结果

你今天让 AI 写一个组件，它用 React Hooks。明天同样的 prompt，它用 Class Component。后天，它用一个你没见过的第三方状态管理库。

在个人开发中，这是小问题。在团队协作中，这是灾难：

• 不同开发者用 AI 生成的代码风格不一致

• 同一个功能被 AI 用三种不同方式实现

• PR Review 的时候看到的不是"对不对"而是"这次用的哪种风格"

十四、Spec 写了也不一定有用

即使你写了 Spec（PRD、用户故事、API 规格），AI 的代码质量改善也有限。因为：

Spec 告诉 AI "做什么"，但不告诉它：

• 这个项目用什么技术栈和版本

• 已有的代码是什么风格

• 哪些工具类可以复用

• 架构分层规则是什么

• 团队的错误处理约定是什么

• 什么库绝对不能用

ETH Zurich 的研究发现：LLM 生成的 context 文件反而让任务成功率降低 3%，同时推理成本增加 20% 以上。人写的 context 文件也只提供了平均 4% 的改善。

不是"写了 Spec 就好了"——关键是 Spec 之外的项目级上下文怎么传递。

十五、人类不愿意花时间Review代码

一个很少被讨论但正在发生的事，当团队大量采用 AI 代码后，Review 质量下降。因为：

• PR 体积变大（AI 一次产出多文件），reviewer 疲劳

• "AI 写的应该没问题吧"的心理——自动化偏见（automation bias）

• 代码不是 reviewer 自己的同事写的，缺乏"这个人通常会在这里犯错"的直觉

• 改动太快，reviewer 跟不上节奏

BCG 研究指出：人类 oversight 在 AI 辅助工作流中经常被自动化偏见、直觉判断和上升通道阻塞所削弱。

当前 AI Coding 的核心问题一览

这些问题不是"AI 不行所以不要用"。AI Coding 是真实可用的工具，但它目前有明确的边界和限制。

了解这些限制，比盲目相信"AI 让开发效率提升 10 倍"更重要。