AI编程实践中的常见缺陷与诊断框架

AI编程已进入企业级应用阶段，但多数团队在新鲜感消退后，会遭遇同样的困境：AI生成的代码"表面看起来没问题，运行时就暴露缺陷"。这些问题并非偶发，而是具有规律性——它们可以被提炼、分类和诊断。

本文总结了AI编程中的典型缺陷模式（Bad Smell）。这些并非简单的"AI表现不佳"这样模糊的评价，而是精确到可操作层面的诊断框架。

这是最基础也最容易被忽视的一类问题。AI并非真正"记住"信息，而是在上下文窗口内进行模式匹配。一旦上下文超出窗口范围或被污染，AI的表现就会下降。

主要表现：

上下文衰减（Context Rot）：长会话中，早期设定的关键约束在中后期被模型"遗忘"，产出逐渐偏离原始目标

会话漂移（Cross-Session Drift）：同一需求，换一个会话或换一个模型版本，产出完全不同

知识陈化（Stale Memory）：团队的AGENTS.md、Rules文件长期未更新，AI引用的仍是过时信息

根本原因：团队把AI当作"可靠的信息库"，而未认识到上下文窗口本质上是有限且不稳定的资源。上下文的质量管理，比Prompt技巧重要得多。

这是目前企业中覆盖面最广的一类缺陷。很多团队声称"我们也在编写Spec"，但仔细审视后发现，这些Spec要么是给领导看的演示级文档，要么是连AI都难以理解的模糊描述。

主要表现：

规范表演（Spec Theater）：有Spec，但颗粒度和结构化程度达不到AI可执行的标准。写得热闹，AI抓不住要点

字段漂移（Field Drift）：同一概念在Spec、代码、测试中使用了不同的字段名，AI在三者之间来回迷失

验收标准缺失（Missing AC）：有需求描述但没有可验证的验收标准，谁也判断不了"完成与否"

根本原因：团队把"有文档"等同于"有规范"。人类看文档可以脑补，AI不能。给AI的Spec必须是结构化、可验证、能直接驱动的——这是范式级的差异。

从单模型到多智能体协作，是AI编程正在发生的重大变化。但多数团队仍停留在"写一个大Prompt期望AI全搞定"的阶段。

主要表现：

巨型Prompt（Prompt Giant）：试图将需求、约束、规范、边界条件全部塞进一条Prompt，结果AI在关键细节上"猜测"而非"执行"

Agent越权（Agent Overreach）：Agent被赋予了超出边界的操作权限——修改配置、操作生产环境、跳过审批——且无人察觉

无审查闭环（No Review Loop）：Agent生成完代码直接合入，中间没有人类检查点。后果是错误被层层放大

根本原因：团队把多Agent编排理解为"把任务丢给AI就行"。实际上，编排的核心不是"自动化"，而是"可检查的分解"。拆得越细，每一步越可验证，整体质量越高。

AI生成代码的速度是人工的5-10倍，但质量检查工具没有同步升级。结果就是：代码写得快，埋的坑也快。

主要表现：

虚假通过（Fake Green Test）：AI为了让测试通过，直接修改断言逻辑——覆盖率100%，但逻辑全错

幻觉引用（Hallucinated Reference）：引用不存在的API、库或函数，编译不过才发现

幽灵代码（Ghost Code）：AI生成的函数从来不被调用，代码量膨胀但功能没增加

根本原因：传统的质量门禁（Code Review + CI）是为"人类写代码"设计的。AI的出错模式完全不同——它不是粗心，而是系统性幻觉和模式过度泛化。需要的不是更严格的Code Review，而是专门针对AI特征的质量防线。

企业引入AI编程一段时间后，往往出现一个悖论：每个人都在用AI，但团队的集体能力几乎没有沉淀。

主要表现：

知识孤岛（Knowledge Silo）：每个团队甚至每个人都在自己的会话里积累Prompt和技巧，从不共享

技能离散（Skill Dispersion）：有效的Prompt、工作流、配置散落在飞书文档、Notion、本地文件夹中，没有统一管理

决策不可追溯（No Lineage）：AI生成的关键代码"为什么会这么写"，除了当时的聊天记录外无迹可寻

根本原因：AI编程的"知识"不再是代码注释或设计文档，而是Prompt模板、Skill配置、上下文组合策略。这些资产的形态变了，但大多数团队的知识管理体系没有同步升级。

这是管理层最关心的问题。大多数企业的AI编程效果评估停留在"团队说挺好的"或"PR接受率60%"这个层面。

主要表现：

虚假采纳率（Adoption Faking）：只看AI代码的采纳率，不追问采纳之后改了多久。60%的采纳率背后可能是200%的返工时间

感性ROI（Emotional ROI）：ROI数据基于"感觉快了"而非前后量化的对比基线

无基线（No Baseline）：引入AI之前没有建立效率基线，所有提升数字都没有参照物

根本原因：度量体系是事后补课，而不是一开始就设计的。企业需要三条线同时监控：效率（DORA指标）、质量（缺陷密度）、体验（开发者满意度）。单腿走路的数据没有说服力。

最后一个维度往往被技术团队忽略，但它决定了AI编程能否从"试点成功"走向"组织规模"。

主要表现：

架构师缺席（Architect Absent）：AI编程的标准、规范、治理由一线开发自发推动，架构师不参与——结果是局部优化、整体劣化

培训蒸发（Training Leak）：做了一次培训，没有Skill化、没有持续演练、没有内部认证——三个月后能力回到原点

英雄依赖（Hero Worship）：整个团队的AI编程能力依赖一两个"懂行的人"，人走茶凉

纸上治理（Paper Governance）：厚厚的Rules.md写在仓库里，但没有任何Lint、Gate、自动检查来强制执行

根本原因：AI编程的组织挑战是"能力资产化"——把个人的AI协作经验变成团队的系统能力。这不是技术问题，是管理和文化问题。

把七类缺陷摊开来看，它们之间不是孤立的——上下文问题会导致规范问题，规范问题会放大Agent编排问题，编排问题最终体现为质量和度量问题。这是一条因果链。

维度

核心问题

关键信号

上下文

AI的记忆不可靠

长会话后产物偏离意图

规范

文档不等于可执行

Spec存在但AI不按它写

Agent

编排不是自动化

一个超大Prompt试图搞定一切

质量

传统检查不适用

AI改测试来"通过"检查

知识

经验沉淀不住

有效Prompt都在个人聊天记录里

度量

数据没有基线

ROI数字靠感觉

组织

能力复制不了

一两个专家撑起整个团队