AI Coding也有坏味道 (Bad Smell)

公众号名称：沐然云计算

作者名称：吕昭波

发布时间：2026-06-17 23:48

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 编排问题，编排问题最终体现为质量和度量问题。这是一条因果链。

维度	核心问题	关键信号
上下文	AI 的记忆不可靠	长会话后产物偏离意图
规范	文档不等于可执行	Spec 存在但 AI 不按它写
Agent	编排不是自动化	一个超大 Prompt 试图搞定一切
质量	传统检查不适用	AI 改测试来"通过"检查
知识	经验沉淀不住	有效 Prompt 都在个人聊天记录里
度量	数据没有基线	ROI 数字靠感觉
组织	能力复制不了	一两个专家撑起整个团队

---

内容效果不满意？点此反馈