别再神化Spec了，它可能只是AI Coding的临时补丁

在 AI Coding 越来越火的今天，Spec 几乎快成了"标准动作"。

但如果我们退一步看，会发现一件事：
Spec 很重要，但它未必代表未来。

它更像是当前大模型能力边界下，为了让 AI 更好理解需求、减少生成偏差，而出现的一种阶段性工程化补丁。

很多团队现在谈 AI 开发，都会默认把 Spec 放进流程里：先写需求、再整理 Spec、再让 AI 生成代码。

这套方式在当下当然有效，但我越来越倾向于把 Spec 看作一种过渡方案，而不是长期终局。

这篇文章想聊四个问题：

Spec 到底是什么？
为什么 AI Coding 阶段会需要 Spec？
Spec 真正该怎么写，才不会变成新的负担？
当 AI 越来越懂代码，Spec 还会不会存在？

一、Spec 是什么？

先说结论：

Spec 不是需求文档的别名，也不是设计文档的翻版。

在 AI Coding 语境里，它更像是一份给 AI 看的结构化任务说明书。

它的核心作用，不是"记录"，而是"压缩上下文"。

因为真实开发环境里的信息通常很分散：

需求在 PRD 里
交互在设计稿里
规则在口头沟通里
历史约束藏在旧代码里
边界条件可能只存在于某次评审结论里

这些信息对人来说还能慢慢拼起来，但对 AI 来说，如果输入不够聚焦，它就很容易"理解得八九不离十，但实现总差一点"。

所以，Spec 存在的意义，就是把这些零散信息重新整理成一种更利于 AI 消费的结构化表达。

你可以把它理解成：

Spec = 面向 AI 的需求摘要 + 约束清单 + 验收提示

它不是为了替代代码，也不是为了替代产品文档，而是为了在当前模型能力还不够强的时候，帮 AI 更高效地抓住重点。

二、为什么现在大家都在谈 Spec？

本质原因就一个：

AI 还不具备低成本、稳定、完整理解真实工程的能力。

虽然现在的大模型已经能写很多代码，甚至能读懂局部模块，但一旦进入稍微复杂一点的项目场景，问题就会出现：

它未必知道整个代码库的真实上下文
它未必理解历史设计决策
它未必知道哪些是通用逻辑，哪些是业务特殊规则
它也未必能从杂乱输入里准确提炼出真正重要的约束

这时候，Spec 就变成了一种很实用的中间层。

它不是因为"先进"才存在，而是因为在当前阶段，AI 还需要人类先帮它整理上下文。

换句话说：

Spec 不是理想形态，而是现实妥协。

三、Spec 为什么会越写越重？

这也是我觉得很多团队容易踩坑的地方。

一开始，大家觉得 Spec 很好用：

"把需求写清楚，AI 生成就更准。"

但随着项目复杂度上来，Spec 很容易从"提效工具"变成"维护负担"。

1）多人协作下，Spec 很容易冲突

一个功能在真实项目里，通常不只是一个人参与：

产品会改需求
设计会调交互
后端会加约束
前端会补兼容方案
测试会补边界 case

问题在于，每个人都可能在更新认知，但不一定同步更新 Spec。

于是就会出现这种情况：

文档里写的是 A
评审会上说的是 B
最终代码实现的是 C

Spec 本来是为了统一理解，结果最后反而成了另一个"版本分叉源"。

2）Spec 和代码很容易不同步

这是更现实的问题。

代码是持续演进的，但 Spec 往往不是。

尤其在迭代快、变更频繁、灰度发布很多的团队里，代码每天都在变，但文档更新往往滞后。

这会带来一个很尴尬的结果：

本来是想用 Spec 帮助 AI，最后却变成 AI 被过期 Spec 误导。

一旦出现这种情况，Spec 不但不能提效，反而会增加返工成本。

3）很多 Spec 其实在重复"行业共识"

还有一种常见问题是：

Spec 写得很长，但信息密度很低。

比如开发一个购物车，文档里写满了这些内容：

支持商品数量增加
支持商品数量减少
支持删除商品
支持计算总价

这些当然没错，但问题是：这类功能本身就是高度共识。

对于一个已经见过大量电商系统样本的模型来说，这些描述未必是最值得占用上下文的位置。

真正应该被重点强调的，往往不是"常规功能"，而是那些不符合默认模式的业务差异。

四、Spec 到底该怎么写，才更适合 AI？

如果一句话总结我的观点，那就是：

少写共识，多写差异。

这可能是当前阶段写 Spec 最重要的原则。

1）别把 Spec 写成"功能流水账"

很多人写 Spec，习惯从头到尾罗列功能点。

但对 AI 来说，真正有价值的不是"功能列表有多全"，而是：

任务目标是什么？
哪些规则不能违反？
哪些地方和行业默认做法不一样？
哪些边界条件最容易出错？
最终验收标准是什么？

所以，与其写成一篇长长的功能说明，不如写成一份高信息密度的约束清单。

2）重点写"非共识需求"

举个例子。

如果你要做一个购物车，下面这类内容可以少写：

支持修改购买数量
支持删除商品
支持展示合计金额

因为这些是共识逻辑。

但下面这些内容就必须重点写：

商品列表需要按保质期升序排列
生鲜商品和普通商品的库存校验规则不同
满减和会员折扣的计算优先级遵循门店策略
预售商品不能与即时配送商品一起结算

这些才是真正决定 AI 是否会"写歪"的关键约束。

3）让 Spec 只承担"必要信息传达"

Spec 最怕的一件事，就是越长越像"新文档系统"。

一旦团队开始追求"什么都写进去"，Spec 就会迅速膨胀，最终失去它最初的价值。

所以更合理的做法是：

只把当前任务中最重要、最特殊、最容易误解的信息写进去。

我会更建议把 Spec 控制在这几个维度内：

五、一个更实用的 Spec 写法模板

如果你想在团队里落地，我建议直接用这种轻量模板：

1. 任务目标

一句话说清楚这次要做什么。

示例：

为购物车模块增加"按商品保质期排序"的能力，并保持现有促销计算逻辑不变。

2. 改动范围

明确这次会动哪些内容，不动哪些内容。

示例：

涉及购物车商品列表排序逻辑和前端展示顺序；

不修改促销引擎，不改库存服务接口。

3. 特殊规则

重点写与默认实现不同的部分。

示例：

生鲜商品按保质期升序排序
非生鲜商品维持原有排序逻辑
保质期相同按加入购物车时间排序

4. 边界条件

列出最容易遗漏的 case。

示例：

商品缺失保质期字段时，排在生鲜商品末尾
失效商品仍展示，但不可参与结算
预售商品不参与保质期排序

5. 验收标准

让 AI 和人都知道"做到什么程度算完成"。

示例：

排序结果符合规则定义
原有促销结果不受影响
现有接口返回结构不变
单元测试覆盖新增排序逻辑

这个模板的好处是：

短
清楚
可复用
更适合给 AI 喂上下文

六、Spec 的未来，大概率不是越来越重，而是越来越轻

这是我对 Spec 最核心的判断。

今天我们之所以需要 Spec，本质上还是因为 AI 对代码库和业务上下文的理解能力有限。

但这个前提正在变化。

随着模型能力持续增强，未来会越来越明显地出现两个趋势：

1）更大的上下文窗口

AI 能一次读进更多文件、更多模块、更多历史实现。

这意味着很多原本需要手动摘要的信息，未来可以直接从代码里获取。

2）更强的代码库理解能力

未来 AI 不只是"读到代码"，而是能逐步理解：

模块边界
依赖关系
数据流转
历史实现风格
业务规则沉淀位置

一旦 AI 能直接从工程中提取这些信息，很多今天需要人工维护的 Spec，就会失去存在基础。

七、所以，Spec 会消失吗？

我觉得更准确的说法不是"消失"，而是：

Spec 会从主角，退回成辅助角色。

未来不会没有需求表达，也不会没有约束说明。

但"人工维护一份完整静态 Spec，再交给 AI 执行"这件事，很可能会越来越少。

取而代之的，可能是另一种方式：

人只表达目标、约束和差异
AI 自己去代码库里找上下文
AI 自动抽取模块规则和实现边界
AI 基于真实工程生成方案和代码

如果真走到这一步，Spec 就不再是开发流程里的核心枢纽，而只是 AI 能力不足时期的一种过渡性补丁。

八、结语

回过头看，Spec 当然有价值。

在今天，它依然是帮助 AI 理解任务、提升生成质量、降低偏差的重要手段。

但我不太认同把它神化成"AI Coding 时代的长期基础设施"。

因为它解决问题的同时，也制造问题：

它需要维护
它会冲突
它会过期
它会和代码脱节

所以，比起"凡事都写 Spec"，我更认同另一种做法：

只为那些真正非共识、易出错、差异化强的部分写 Spec。

把 Spec 写轻，把约束写准，把 AI 最容易误解的地方说清楚。

这可能比写一份冗长而完整的"大而全 Spec"，更有现实价值。

摘要：

Spec 不是银弹，它更像是当前 AI 能力边界下的一种工程化补丁：通过结构化文档帮助模型理解需求。但随着上下文窗口扩大和代码理解能力增强，Spec 大概率会从主角退回到辅助角色。真正值得写进 Spec 的，不是行业共识，而是差异化约束。