在把 AI 引入日常开发工作流近两年后，我们发现了一个反直觉的规律：模型能力提升，某些类型的错误不降反升。
这不是某个模型的问题，而是当前所有 AI 编程工具共有的结构性缺陷。我们把它归纳为两个：
缺陷一：上下文不足
AI 模型在处理代码时，看到的永远是片段，而不是系统。它能读懂你粘进去的那几个文件，但它看不到：
- 这个函数被哪 23 个地方调用
- 这个模块和其他模块的依赖链是什么
- 上周刚做的架构决策（因为那是另一个 session）
- 这个类的子类在其他文件里有哪些覆写
结果是幻觉——不是模型乱说，而是模型在信息不完整的情况下做出了局部合理但系统错误的决策。它写出的代码技术上是正确的，但违反了你的架构意图。
更糟的是：模型越自信，这个问题越严重。GPT-4 比 GPT-3.5 更流畅地写出"看起来合理但实际上破坏了依赖关系"的代码。强模型 + 差上下文 = 以机器速度生产技术债。
缺陷二：流程无结构
给 AI 一个需求，它会立刻开始写代码。这听起来很高效，但实际上跳过了软件开发中最重要的几步：
- 这个需求真正要解决什么问题？
- 现有代码库里有没有可以复用的部分？
- 改动会影响哪些下游模块？
- 完成之后如何验证它真的工作了？
没有这些步骤，你得到的是失控：需求范围悄悄扩大，没有测试，上线后静默回归（功能 A 的修改悄悄破坏了功能 B，没有任何报错）。
19 种失败模式
这两个缺陷在三个层面产生了可预测的失败模式：
| 层面 | 失败模式 |
|---|---|
| 架构层 | 不必要的抽象层、过度模块化、过早泛化、事件系统过度设计、配置系统过度设计 |
| 模块层 | 单模块功能膨胀、职责不清、跨模块重复逻辑、耦合过重、接口不稳定 |
| 代码层 | 死代码残留、循环依赖、函数拆得过碎、内聚度低、测试覆盖空洞、文档与实现脱节 |
这 19 种失败模式都不是随机的，它们都有同一个根源：模型在没有完整信息的情况下做了不可逆的结构决策。
为什么更强的模型让这些问题更严重
当模型能力弱时，开发者不会完全依赖它——你会验证、会质疑、会自己检查。
当模型能力强时，开发者倾向于直接采纳输出。GPT-4o 或 Claude 3.7 Sonnet 写出来的代码，90% 的情况下语法完美、逻辑流畅，你不会逐行检查。但这正是问题所在：它的输出质量足够高，让你忽略了结构层面的错误。
有一个比喻：弱模型像一个慢但诚实的初级工程师，你知道要检查他的工作。强模型像一个快速自信的高级工程师，你倾向于信任他——但这个"高级工程师"对你的系统历史一无所知，每次对话都是第一天上班。
解法的方向
针对这两个缺陷，解法方向很明确：
- 上下文不足：需要一个代码库级别的知识图谱，索引函数、类、调用关系、依赖链，让模型在需要时能精确获取结构信息。
- 流程无结构：需要将软件开发生命周期的关键节点（需求精化、影响评估、测试覆盖、端到端验证）结构化，强制每一步基于代码事实而非 LLM 想象。
这是我们构建 Manon 的出发点，也是我们交付软件开发服务的底层方法论。后续文章我们会详细介绍知识图谱的工作原理和我们的开发流程。