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

[wingtao]

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

[billzhuang]

小功能这样是效果很好的，大功能拆成小功能。

[iorilu]

任何模型都不可能简单几句话就能完成复杂功能
毕竟真实开发也是迭代过程中, 不断产生新问题,确认新得细节才能完成

[sillydaddy]

上下文工程，现状是什么样的呢？问了 AI 似乎没有什么特别的进展。
我前两天还吐槽 Cursor 的上下文压缩，直接导致了死循环： /t/1182810
如果说，在一个对话中的上下文压缩都弱到这种程度，很难期望 AI 在复杂业务上，能抽象出合理的上下文。

[nightlight9]

越复杂的业务效果越差，不如自己写

[maolon]

"模型天然存在“快速收敛”的生成倾向" 这个我认为是过快和轻率的得出结论，然后用错误的结论推导剩下的论点。
模型的生成倾向和他后训练的 RL 算法有关，确实我们会奖励以更少的步骤或者更少的 token 生成正确的结果，但是这个步骤本身不一定是“快速“收敛的，相反可能是一个很长的流程。
反面的例子就是 gpt5.2 high/xhigh 这两个 reasoning effort ，会花费大量的时间探索代码结构和任务意图，我不知道文章本身怎么定义”充分探索“，但是至少这两的探索过程会谨慎和小心的多

[sampeng]

先说结论。不能。
我发现跟着自己的思路一点一点往前推进是最好的。每次都重新读一遍代码很慢？再慢也比人写快。

[YanSeven]

@sampeng 是的，再慢也比人写快，以及代码块内的小 bug 也比人少。

[sampeng]

@YanSeven 模拟人写代码，我现在让 ai 越来越小的 function 级别去实现，或者设计一个模式，在 2 个满 token 的会话里面完成封装。然后做一轮重构和代码检查。比 spec 要好，spec 只是看着能 work ，项目越来越复杂后就是噩梦。

[OBJECTION]

一次性本身就是不可行的。。我现在 coding 之前都是会进行多轮的对话 加上人工的 review design.md 或者 background, 当然 prompt 也可以进行优化 比如再某些模糊的地方 让他主动的去询问你。。。

[ArrayBuffer]

试过 spec-kit 和 openspec, 简单的任务没必要用(因为用它太慢了), 复杂的任务它会描述的更复杂, 而且还要审阅它生成的文档, 进一步增加上下文长度, 而且我感觉 claude code 的 plan mode 已经够用了

[chtcrack]

写了好多个 AI 玩具,简单说,就是把大的任务拆分成 1 个个小任务.
别一次性搞那么多的功能让 AI 写,基本上没啥问题..

[maichael]

写代码知道没有银弹，用 AI 写代码就忘记了？没有最优，只有相对更优。

[qq1147]

试过一次，好像不太行

[wingtao]

@billzhuang 是的，我们假设现在模型现在只能完成 0.5-1pd 的事情，那么我们就需要一个工程方法能够把 10pd 的事情拆解到 0.5-1pd

[wingtao]

@iorilu 是的，所以一次性攒出来的 spec/plan 是一个伪命题，”讨论“是一个可行的方向，原文里也写了，只是太长我懒得粘过来了

[wingtao]

@sillydaddy 上下文压缩一般都不是主 Agent 中的模型做的压缩，一般是专门做的压缩，这里的压缩的确是有一定技巧的。 ”很难期望 AI 在复杂业务上，能抽象出合理的上下文。“这句话也是我们遇到的痛点，这篇文章也是说了解决这个痛点的一种方式

[wingtao]

@nightlight9 感官上是这样的，”复杂“这个词的背后可能就以为这需要的上下文时海量的，所以模型写不好，不一定是模型的智能程度不够

[wingtao]

@maolon 恩恩，这是通过工程实践上得到的一些结论，不一定完全正确，期待大家的讨论。模型之间的确有一定差异性，但是工程实践中有一个现象是加入有一个总结性的文档让模型读到了，那么这里面涉及到的知识很大可能性模型就不会再去读源文件了，就会导致最后得到的结论浮于表面非常不理想，实际上强制它读取应读的文件后给出的结论是理想的。

[wingtao]

@ArrayBuffer 类似 spec-kit 这种个人不认为它现在是一个理想的实现方式，因为它整个流程其实还是太固化了。这种死板的流程，它不应该 Agent 的一个最终形态。

关于 Plan 的话，我认为它跟 Spec 还不太一样。
总体上，这种一次性生成的 Plan ，其实我理解它能达到的效果可能跟 todo 是一样的，即：
1. 保证执行过程不偏离预定轨道
2. 但它并不会提高模型解决任务的复杂度

[wingtao]

@chtcrack 之前也是上手这种 0-1 的 Demo 项目，但在实际生产中，它就是一直不敢用，因为生产项目中主流程功能的实现是一部分还有很大一部分是要在一个已知的巨大项目中去集成而且还要考虑各种边界情况，这些在 0-1 的玩具项目中都是不需要考虑的

[maymay5]

小功能可行，不能作为这个模式有效的证明，小功能不用任何模式就纯自循环 Agent 也一样可行

[KingGaruda]

我在想是不是分成多次实现是不是就行， 让他自动生成 spec 并迭代代码，然后发现细节、边界等问题补充描述，完善 spec ，然后

[wings110]

我觉得没啥问题， 每个模块都有自己的 spec ， 需要读取到哪个模块的再加载对应的就好了呀，一次性的就算是资深的 pm/dev 写也不好文档呀

[AoEiuV020JP]

理想的效果我希望类似生成图片先生成低清晰度再逐渐变清晰，最好每一步都可以插手调整，
生成代码实现功能， 先生成 总纲，再生成具体设计，再生成关键 api ，再生成关键代码， 最后生成实际代码并编译，
理想是这样的， 每一步人工调整确认好了再下一步，

[graymmon]

vibe 的 duckdb-query 从最初的直接干活导致一堆硬编码+到处拉屎。
后来都是基于 kiro 的 spec+design+task 的模式，已经完成了整体重构，UI 也完全重构了，目前来说我都会按照这个模式去先生成类 kiro 的方案，之后用 codex 进行方案审查是否符合项目规范以及边界情况。
几乎没怎么出现过导出拉屎以及实现不对的问题了。

[rogerer]

我现在越来越不相信 spec 了而是相信小步快跑的 plan 。spec 库吃库吃些那么多东西其实我也不会去看，相当于没写。

[lihui4305]

写的很棒，我也有一篇上下文工程经验的播客，欢迎阅读交流，https://www.privydrop.app/zh/blog/ai-collaboration-playbook

[bytesfold]

Spec 是固化用的，加上 TDD

[GeruzoniAnsasu]

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]

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

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

[liminany1]

不太行的，可能过滤技术，看看大佬写的 https://mp.weixin.qq.com/s/T8mjBX69hbScn9UtenfH-g