AI Coding也有坏味道 (Bad Smell)

AI Coding 已经进入企业级应用阶段，但大多数团队在兴奋期之后，会撞上同一类问题：AI 写的代码"看起来都对，跑起来就出问题"。这些问题不是偶然的，而是系统性的——它们有规律、可分类、可诊断。

可提炼出了 AI Coding 坏味道（Bad Smell）。它们不是"AI 写得不好"这么笼统的判断，而是精确到可操作层面的诊断框架。

一、上下文与记忆：AI 的"失忆症"

这是最基础也最容易被忽视的一类问题。AI 不是真正的"记住"，而是在上下文窗口内进行模式匹配。上下文一旦超出窗口、或被污染，AI 的行为就会劣化。

核心表现：

• 上下文腐蚀（Context Rot）：长会话中，早期给出的关键约束在中后期被模型"遗忘"，产出逐渐偏离原始意图
• 会话断裂（Cross-Session Drift）：同一个需求，换一个会话、换一个模型版本，产出完全不一致
• 知识腐化（Stale Memory）：团队的 AGENTS.md、Rules 文件长期不更新，AI 引用的仍是过时信息

根本原因：团队把 AI 当成"靠谱的记忆体"，而不理解上下文窗口本质上是一个有限且不稳定的资源。上下文的质量管理，比 Prompt 技巧重要得多。

二、规范与意图：人人都在"装样子"

这是目前企业中覆盖面最广的一类坏味道。很多团队说"我们也在写 Spec"，但细看之下，Spec 要么是给领导看的 PPT 级文档，要么是连 AI 都看不懂的散文。

核心表现：

• Spec做戏（Spec Theater）：有 Spec，但它的颗粒度和结构化程度达不到 AI 可执行的标准。写得很热闹，AI 抓不住重点
• 字段漂移（Field Drift）：同一个概念在 Spec、代码、测试中用了不同的字段名，AI 在三者之间来回迷失
• 验收标准缺失（Missing AC）：有需求描述但没有可验证的 Acceptance Criteria，谁也判断不了"做完没做完"

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

三、智能体与编排：一个 Prompt 打天下

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

核心表现：

• 巨型 Prompt（Prompt Giant）：试图把需求、约束、规范、边界条件全部塞进一条 Prompt，结果 AI 在关键细节上"猜"而不是"执行"
• Agent 越权（Agent Overreach）：Agent 被赋予了超出边界的操作权限——改配置、动生产、跳过审批——且无人察觉
• 无审查闭环（No Review Loop）：Agent 生成完代码直接合入，中间没有人类检查点。后果是错误被层层放大

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

四、质量与安全：100% 覆盖率的假象

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

核心表现：

• 假绿测试（Fake Green Test）：AI 为了让测试通过，直接修改断言逻辑——覆盖率 100%，但逻辑全错
• 幻觉引用（Hallucinated Reference）：引用不存在的 API、库或函数，编译不过才发现
• 幽灵代码（Ghost Code）：AI 生成的函数从来不被调用，代码量膨胀但功能没增加

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

五、知识与资产：Prompt 藏在个人的聊天记录里

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

核心表现：

• 知识孤岛（Knowledge Silo）：每个团队甚至每个人都在自己的会话里积累 Prompt 和技巧，从不共享
• 技能离散（Skill Dispersion）：有效的 Prompt、工作流、配置散落在飞书文档、Notion、本地文件夹中，没有统一管理
• 决策不可追溯（No Lineage）：AI 生成的关键代码"为什么会这么写"，除了当时的聊天记录外无迹可寻

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

六、度量与回报：拍脑袋的 ROI

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

核心表现：

• 虚假采纳率（Adoption Faking）：只看 AI 代码的采纳率，不追问采纳之后改了多久。60% 的采纳率背后可能是 200% 的返工时间
• 感性 ROI（Emotional ROI）：ROI 数据基于"感觉快了"而非前后量化的对比基线
• 无基线（No Baseline）：引入 AI 之前没有建立效率基线，所有提升数字都没有参照物

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

七、组织与文化：一个人的超能力，复制不了

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

核心表现：

• 架构师缺席（Architect Absent）：AI Coding 的标准、规范、治理由一线开发自发推动，架构师不参与——结果是局部优化、整体劣化
• 培训蒸发（Training Leak）：做了一次培训，没有 Skill 化、没有持续演练、没有内部认证——三个月后能力回到原点
• 英雄依赖（Hero Worship）：整个团队的 AI Coding 能力依赖一两个"懂行的人"，人走茶凉
• 纸上治理（Paper Governance）：厚厚的 Rules.md 写在仓库里，但没有任何 Lint、Gate、自动检查来强制执行

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

总览

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