如果你的团队正在使用 AI 辅助编码（无论使用何种工具），下面这些问题你大概率正在经历，或者即将面临。AI Coding 并非万能，它目前有着明确的边界和限制。了解这些挑战，比盲目相信"AI 让开发效率提升 10 倍"更为重要。

一、"80% 问题"：功能完成，但无法上线

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

AI 做得好的 80%：

• CRUD 接口、标准 API 模式
• 基础参数校验、Happy Path 测试
• UI 组件渲染、状态管理
• 数据库查询、ORM 操作

AI 系统性遗漏的 20%：

• 重试逻辑、熔断器、限流
• 幂等键（防止网络超时时重复提交）
• 结构化日志、分布式 Tracing、告警埋点
• 跨接口一致的认证/鉴权中间件
• 边界条件、并发竞态、回滚策略

真实场景：AI 生成了一个支付接口，测试全过并上线。第 3 周用户报告网络超时后被扣了两次钱（缺幂等键）；第 6 周安全审计发现 4 个支付接口中有 1 个漏了认证中间件。这不是 Bug，每一行代码都是"正确"的，但它不是生产级代码。

二、代码"不属于"你的项目

这是最普遍的问题。AI 生成的代码功能正确，但无法融入现有项目：

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

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

有数据支撑的事实：模型在短 prompt 下准确率 90%+，在 32,000 token 下急剧下降（Adobe 2025 研究）。在 Agent session 中，观察结果（文件内容、测试输出）占 84% 的 token（JetBrains 2025）。

实际表现：

• 对话前 10 轮，AI 还记得你的架构规则
• 对话 20 轮之后，它开始忘记之前的约定
• 对话 30 轮之后，它可能推翻之前自己写的代码逻辑
• 对话 40 轮之后，让它"继续"基本等于让它重新开始

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

四、产出速度的幻觉

METR 2025 研究（目前最严格的对照实验）：16 位资深开发者，246 个真实任务。结果：使用 AI 工具的组，完成任务实际慢了 19%。但实验后，开发者自己估计 AI 帮他们快了 20%。主观感受和客观数据完全相反。

原因：

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

Stack Overflow 2025 调查：只有 16.3% 的开发者认为 AI "大幅"提升了生产力，41.4% 认为几乎没有效果。

五、从不重构，只会叠加

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

AI 的默认行为是"生成新代码"而不是"复用已有代码"。它不会说"这个功能你项目里已经有了，不需要再写"。实际后果是项目里出现多个功能相同但实现不同的工具函数，改一个 Bug 要改 4 个地方。

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

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

典型问题：4 个 API 中 3 个有鉴权中间件，第 4 个漏了；每个接口自己做输入校验，规则不统一；认证 token 的刷新逻辑在边界情况没处理。

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

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

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

• 幻觉 API 签名（占幻觉的 20.4%）：AI 写了 stripe.charges.create({idempotencyKey: ...})，但实际 SDK 参数名是 idempotency_key 放在 options 里。代码能跑，但幂等不生效。
• 幻觉依赖包：AI 推荐 npm install response-validator——这个包根本不存在。或者推荐一个名字接近但已经弃用 3 年的包。
• 修改代码时幻觉加倍：研究表明，让 AI 修改已有代码（而非从零生成）时，幻觉率翻倍。因为它需要同时推理旧代码和新代码的状态，partial context 极易出错。

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

原因：

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

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

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

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 不行所以不要用"。AI Coding 是真实可用的工具，但它目前有明确的边界和限制。了解这些限制，比盲目相信"AI 让开发效率提升 10 倍"更重要。