过去一年，围绕 AI Coding 的讨论里，Spec / Plan / 设计文档几乎被当作了“解药”。似乎只要模型能先生成一份 Spec ，再由 Agent 按图索骥，复杂任务似乎就可以被自动完成。但在实际工程实践中，结论往往并不乐观。这里问题并不在于 Spec 本身不重要，而在于——我们正在用一种错误的方式，去理解和生成 Spec 。
## 我们在说的 Spec ，到底是什么？
当前语境下，大家对 Spec 的默认理解往往是：在编码前生成的一份文档描述实现步骤或技术方案一次性完成，用于驱动后续执行这种理解，本质上继承自传统软件工程流程。但在 AI Coding 场景中，这个定义本身就存在偏差。Spec 的真正价值，并不在于“计划本身”，而在于它是否承载了足够完整的上下文。换句话说：Spec 不是 Plan ，而是“上下文的显式化表示”。如果上下文是错的或不完整的，再精致的 Spec ，也只是在系统性放大错误。
## 一次性生成 Spec ，为什么在机制上必然失败？
当前大量 AI Coding 的实践，都隐含了一个假设：
在上下文不完整的前提下，让模型一次性生成一份可用的 Spec 。
这个假设在机制上是站不住的，主要有两个原因。
1. 模型天然存在“快速收敛”的生成倾向
大模型在生成内容时，目标并不是“充分理解问题空间”，而是尽快产出一个看起来合理、结构完整的答案。
这会带来几个典型后果：
在信息探索上，模型倾向于在“够用”的地方就停了
在代码库搜索中，一旦找到可行实现，很少主动做反证式分析或者交叉验证
在不确定的地方，默认使用最常见、最安全的假设
而 Spec 恰恰需要的是：
全面性
边界条件
被否定方案以及否定的原因
隐性约束的显性化
这与模型的默认生成动力学是相反方向的。
2. 上下文缺失时，模型只能“编造合理性”
在 Coding Agent 场景中，模型能直接获取的上下文主要是：
代码结构
API 与类型信息
有限的历史提交
这部分我们可以称为技术上下文。
但真正决定任务能否正确完成的，往往是另一类信息：
为什么现在要做这件事
成功的判定标准是什么
哪些方案在历史上被否定过
哪些约束写不进代码，但绝对不能触碰
也就是业务上下文。
而这部分上下文，目前并不存在于代码仓库中，也无法通过搜索自动补齐，只能由人提供。
在这种情况下，一次性生成的 Spec ，本质上只是“合理幻想”。
## 从第一性原理看 AI Coding 的真实瓶颈
如果从第一性原理来抽象问题，其实非常清楚：
智能模型 + X = 可完成的任务
那么这个 X ，一定不是流程，而是充足的上下文。
近年来，模型的“智能”提升极快，但 AI Coding 能独立完成的任务边界并没有等比例扩大，根本原因就在于：
技术上下文在增长
业务上下文几乎没有被系统性地纳入
因此，没有业务上下文的 Coding Agent ，本质上只能做代码层面的自动化，而不是任务层面的自动化。
## 小任务为什么“看起来可行”，大任务却必然翻车？
这也是一个经常被忽略，但在工程上非常重要的边界条件。
对于 0.5 PD 或 1 PD 的小任务
上下文简单、约束清晰、失败成本低
一次性生成的 Plan / Spec 偶尔是可以工作的
但对于持续时间超过一周的复杂任务
上下文高度耦合、隐性约束大量存在
一次性生成的 Spec 几乎必然失效
这不是模型能力问题，而是问题复杂度的自然结果。
原文链接： https://mp.weixin.qq.com/s/p__fr5J9DzPYWFJtg8PB0A