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

GeruzoniAnsasu

1 月 7 日

spec 本质就是逐条检查的清单，用来把难以控制的 AI 自由发挥细化为逐字逐行的约束和回归项。

在这个前提下却还在讲「一次性完成」，在我来看根本就是匪夷所思的，好比老中制定了「 10 个 5 年计划但是细节不看总之 make china great again 就完事了」。

spec 的正确用法就是让人类工程师能逐指令逐步骤地跟踪 AI 的产出使其符合设计目标。我目前的工作范式：

1. 让 LLM 写 spec
2. 让 LLM 分析项目状态指出 spec 有没有不足之处
3. 人工介入，把 spec 和预达成目标缩减/补充至可行范围，同时确保每个 step 都有足够的逻辑骨架来 check （比如第一步实现业务的数据模型，第二步根据模型实现 DAO ，第三步用 DAO 拼接业务逻辑，第四步调整中间件…………）
4. 让 LLM 给出可重入的 prompt ，每个 step 在单独会话中实现，但要求把增改记录都同步回 spec/设计文档中
5. 反复重试直至达到设计预期
6. 根据刚才的实现步骤重读 spec 并补充细节
7. 循环 => 2

p.s. 这个工作范式只能搭配 claude 的模型，codex 和 gemini 都跟不上，因为它们的抽象思维太弱，无法理解「分析」具体对应到哪些工作，产出不了 reasonable feedback

BeautifulSoap

1 月 7 日

Spec 驱动开发绝对不是 ai 开发的未来。真做过项目的就知道 Spec 这东西本质上就是一个项目的详细设计书（尤其日本 it 开发喜欢这一套。开发项目先确定需求,然后做完整的系统的设计，这种设计可能详细到每个小功能逻辑步骤）
大部分是你用了 Spec 驱动开发，往往结果如下

1. 对于一个复杂功能，生成的 spec 过度复杂
2. 虽然能拆分功能 spec ，但是功能的复杂度是改变不了的，spec 的复杂和 ai 生成的大量 spec 结果就是根本懒得去看
3. spec 详细到了代码细节实现，review spec 本质上和 review 伪代码没区别，到后来就和 2 一样懒得去详细看 spec 了
4. spec 对各自的功能模块只适合功能变化不大、较为稳定的情况。当你的设计书经常动不动就发生大的变化（实际上开发中经常遇到），spec 也经常会发生巨大变动，如何将最新的变动融入已经写下去的 spec 并且更新到代码也是个问题。而且每个 spec 之间都互相依赖，牵一发动全身。