Spec，真的能解决 AI Coding 的问题吗？

过去一年，围绕 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