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

企业级AI写代码远未成熟，80%的“正确”背后隐藏着20%的生产级隐患。这可不是危言耸听，如果你的团队正在用AI写代码，下面这些问题你大概率正在经历，或者即将经历。

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

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

AI擅长什么？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生成的代码“功能正确”但“无法采纳”，因为：

问题	典型表现
用了项目没有的库	项目用Axios，AI用fetch；项目用dayjs，AI用moment
绕过分层架构	项目有Repository模式，AI直接db.query()
命名风格不一致	项目用getUserById，AI写fetch_user
不知道已有的工具类	项目有统一的ApiResponse.success()，AI自己包一个{code: 200, data: ...}
错误处理模式不同	项目统一抛自定义异常，AI写try-catch返回字符串
不了解配置方式	项目用环境变量，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里做完整件事，质量越低。

四、产出速度的幻觉

（目前最严格的对照实验）：

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

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

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

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

代码接受率不到44%——超过一半的AI建议被废弃；审查、测试、修改AI代码的时间超过了它“帮你省”的时间；在复杂上下文中，AI产出需要大量人类“翻译”才能融入项目。

：只有16.3%的开发者认为AI“大幅”提升了生产力；41.4%认为几乎没有效果。

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

五、从不重构，只会叠加

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

指标	2020	2024
重构/移动代码占比	24.1%	9.5%
复制粘贴代码占比	8.3%	12.3%
5行以上重复代码块	基线	8倍增长

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

实际后果：项目里出现3个功能相同但实现不同的工具函数；改一个bug要改4个地方，因为逻辑被复制了4份；代码量膨胀但实际功能没增加。

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

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

典型问题：4个API中3个有鉴权中间件，第4个漏了；每个接口自己做输入校验，规则不统一；认证token的刷新逻辑在happy path下正常，边界情况（过期、并发刷新）没处理；渗透测试通不过，不是因为代码有bug，是因为安全策略不一致。

：AI生成的代码在45%的情况下引入安全漏洞；Ja va最严重：70%+的AI代码有安全缺陷；86%的代码样本无法防御XSS；88%对日志注入攻击毫无防护。

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

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

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

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

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

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

原因在于：理解成本，要理解一段不是你写的、也不是你同事写的代码逻辑；命名误导，AI可能用了看起来合理但实际含义不同的变量名；隐含假设，AI代码里藏着你不知道的假设（比如它假设某个字段永远不为null）；错误链条，AI的一个早期错误可能在后续5个文件里传播。

：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）。

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

十一、“Almost Right”是最贵的bug

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

“几乎对”比“完全错”更危险：完全错的代码一眼看出来，扔掉重写；“几乎对”的代码你可能不会仔细审查就接受了；等到出问题的时候，你已经在这段代码上面建了5层逻辑。

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

项目规模	AI表现
新建小项目（<5 文件）	很好，几乎可以全自动
中型项目（50-200 文件）	开始出现“不属于项目”的代码
大型项目（1000+ 文件）	大量context丢失，经常产生互相矛盾的改动
遗留系统	几乎不可用——AI不了解未文档化的约定和隐含contract

：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的研究发现：

。人写的context文件也只提供了平均4%的改善。

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

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

一个很少被讨论但正在发生的事：当团队大量采用AI代码后，Review质量下降。因为PR体积变大（AI一次产出多文件），reviewer疲劳；“AI写的应该没问题吧”的心理——自动化偏见（automation bias）；代码不是reviewer自己的同事写的，缺乏“这个人通常会在这里犯错”的直觉；改动太快，reviewer跟不上节奏。

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

当前AI Coding的核心问题一览

#	问题	一句话
1	80% Problem	功能写完了但不是生产级代码
2	项目融入	代码不属于你的项目
3	Context Rot	对话越长质量越差
4	速度幻觉	主观觉得快了，客观可能慢了
5	不重构	只加代码，不复用不整合
6	安全碎片化	安全是逐接口加的不是架构级的
7	隐蔽幻觉	代码看起来对但其实不生效
8	Debug更难	理解别人写的非人类逻辑更耗时
9	多文件矛盾	跨文件改动容易不一致
10	假测试	测试通过但没测到关键逻辑
11	Almost Right	“几乎对”比“完全错”更贵
12	规模反比	项目越大AI越不好使
13	非确定性	同样prompt不同结果
14	Spec不够	Spec只解决“做什么”不解决“怎么做”
15	Review退化	人类审查质量因自动化偏见下降

这些问题不是“AI不行所以不要用”。AI Coding是真实可用的工具，但它目前有明确的边界和限制。了解这些限制，比盲目相信“AI让开发效率提升10倍”更重要。