如果你的团队正在使用 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 生成的代码功能正确，但无法融入现有项目：
| 问题 | 典型表现 |
|---|---|
| 用了项目没有的库 | 项目用 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）。
实际表现：
- 对话前 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）：
| 指标 | 2020 | 2024 |
|---|---|---|
| 重构/移动代码占比 | 24.1% | 9.5% |
| 复制粘贴代码占比 | 8.3% | 12.3% |
| 5 行以上重复代码块 | 基线 | 8 倍增长 |
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 越不好使
| 项目规模 | AI 表现 |
|---|---|
| 新建小项目（<50 文件） | 很好，几乎可以全自动 |
| 中型项目（50-200 文件） | 开始出现"不属于项目"的代码 |
| 大型项目（1000+ 文件） | 大量 context 丢失，经常产生互相矛盾的改动 |
| 遗留系统 | 几乎不可用——AI 不了解未文档化的约定和隐含 contract |
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 倍"更重要。