你好呀，我是歪歪。
前段时间去了参加了一场音乐节，感受了一下现场的魅力。
在乐队换场休息时间，我和 Max 同学就在盘点我们这几年一起听过的音乐节。
细细一盘，发现从 2022 年到 2026 年，每一年都参加了音乐节：
在盘点的过程中，我就想着做一个海报，海报的内容就是记录自己看过哪些乐队。
刚好最近在研究 OpenSpec 这个玩意。
于是需求这不就来了吗？
我想用 AI Coding 的方式，结合 OpenSpec，开发一个网页，支持输入在哪个音乐节看过哪些乐队，然后生成我想要的海报。
啥是 OpenSpec
这是 OpenSpec 的 github 地址，截至目前已经有 50+ 的 star：
官方是这样介绍 OpenSpec 的：
AI 编码助手在需求仅存在于聊天历史中时非常强大但难以预测。OpenSpec 添加了一个轻量级规范层，以便在编写任何代码之前就同意要构建的内容。
这个描述看起来还是很抽象的。
其实用我个人的理解来说，就是它想要解决在 AI 编程中的“抽卡性”。
在当下，我们进行 AI Coding 的时候，大多都是直接把我们的需求扔给 AI，差异点只是在于我们对需求描述的细致程度上。
然后 AI 就开始啪啪啪的一顿输出。
特别是面对“一句话”形式的模糊的需求时，AI 也不会拒绝。
最终输出的产物的问题就是要么少了重要功能，要么多了一些莫名其妙的需求。
代码也不符合预期，整体架构混乱。
OpenSpec 就是想要解决这样的问题。
它的解决思路就是“先定规范，再写代码”，在需求、规范没有明确之前，绝对不写任何一行代码。
说到 OpenSpec，就不得不提到 SDD 编码模式了。
SDD，就是 Spec-driven development，规范驱动开发：
SDD 的核心思想是：先写规范，后产代码。
如果把 AI 比作一支施工队，那么 SDD 就是在动工之前，先为它提供一份详尽、清晰的“工程图纸”，这份“图纸”就是 “规范”。
AI 不再“凭感觉”即兴创作，而是严格按照这份蓝图来施工，确保最终成果准确、可控。
一份高质量的规范通常会包括：
- 明确的需求与业务目标：不仅描述功能，也阐明其商业价值。
- 清晰的技术架构和约束：规定技术选型、系统边界与核心数据流。
- 具体的实现任务清单：将目标拆解为可被追踪、执行的具体步骤。
SDD 这个概念，是 2025 年初的时候，被提出的一个概念。
然后在今年，涌现了一些真正把概念落地的开源项目。
其中 OpenSpec 就是这些开源项目的佼佼者中的一个。
除了 OpenSpec 之外，还有 Spec Kit 和 Kiro。
关于这两个，在 OpenSpec 的 github 上也有一个简单的对比：
而关于这三个项目的对比，我觉得 AI 的这句话总结的很到位：
这是三个不同的路线，但是殊途同归。
OpenSpec 支持的 AI 编码工具也特别多，不管是主流的还是非主流的，基本都支持了：
上手实操
回到我最开始的需求上。
我现在的需求就是一句话：
我要做一个网站，网站可以生成“看过的乐队演出”的海报。在网站上可以输入具体的音乐节名称，时间，以及有哪些乐队，然后生成一张具有设计感的海报。比如，我2026年5月看了草莓音乐节，有这些乐队：棱镜，马赛克，夏日入侵企画，DOUDOU，梅卡德尔，声音碎片，逃跑计划，痛仰。
这个需求可以说提的非常模糊了，我们看一下 OpenSpec 的表现如何。
我们从头开始。
首先，创建一个空文件夹，我文件夹名称就叫 OpenSpecTest：
可以看到这个文件夹，里面啥都没有，新的，纯新的，毫无争议的新。
OpenSpec 的安装非常的简单，就两行代码：
进入 OpenSpecTest 文件夹，打开 Claude Code。
先安装 OpenSpec：
npm install -g @fission-ai/openspec@latest
然后输入 openspec init 就完成了初始化动作：
这个时候 OpenSpecTest 文件夹就变成了这样：
可以看到 openspec init 命令里面其实就是安装了几个 commands 和 skills：
具体的 skills 内容，我这里就不展示了，但是建议你实操的时候，每个都研读一下。
比如，你就会看到，在 explore 里面就有这样的约束原则：
- 不要直接实现 —— 永远不要编写代码或实现功能。创建 OpenSpec 的文档产物是可以的，但不能写应用代码。
- 不要假装理解 —— 如果有不清楚的地方，要继续深入挖掘，而不是假装已经理解。
- 不要急于推进 —— 发现与分析阶段是思考时间，不是任务执行时间。
- 不要强行套结构 —— 让模式和结构自然浮现，而不是预先强加。
- 不要自动记录信息 —— 应当先提出是否需要保存洞见，而不是直接自动保存。
- 要进行可视化表达 —— 一张好的图表/示意图胜过很多段文字。
- 要探索代码库 —— 所有讨论尽量基于真实代码与实际情况。
- 要质疑假设 —— 包括用户提出的假设，以及你自己的假设。
而 openspec 目录下面什么都没有。
但是不要慌，接下来的操作，就会让里面有东西了。
接着，按照官方示例，可以先使用 /opsx:explore 命令，来讨论一下需求：
对应到我们这个需求就是这样的：
/opsx:explore 我要做一个网站，网站可以生成“看过的乐队演出”的海报。在网站上可以输入具体的音乐节名称，时间，以及有哪些乐队，然后生成一张具有设计感的海报。比如，我2026年5月看了草莓音乐节，有这些乐队：棱镜，马赛克，夏日入侵企画，DOUDOU，梅卡德尔，声音碎片，逃跑计划，痛仰。
在开始之前，其实我也不知道我的这个需求讨论成什么样子。
经过短暂的等待后，它基于我的需求输出了这样的内容：
主要可以关注这个部分：
你可以看到，这就是我前面说的：它在和你讨论需求，让这个模糊的需求一步步细化。
当我回答了这些问题后，它会再次抛出更加细节的问题，比如数据存在哪里？分享方式要包含哪些？到底需要哪些主题？
前面我说了参考草莓音乐节的官宣图，它就让我给它一个链接，它要看看风格。
那我就给它随便找一个，然而它并没获取到。
但是这个目前不重要，它还是输出了它自己对于这个需求的整体理解：
这个整体理解，比起我前面的那个原始需求，就细化了很多。
而到这一步，整个项目还没产生任何文档和代码，只是围绕需求，把需求讨论明白了。
所以在“/opsx:explore”这个环节，你可以反复和它对话，一直到你觉得它把你的需求完全理解到位了之后，再进入下一步。
下一步就是 /opsx:propose。
你可以按照它的指引，直接让它开始创建 change proposal。
它就会去调用 /opsx:propose 这个 skill：
也就说在 /opsx:explore 阶段把探索需求清晰后，可以默认过渡到 /opsx:propose 阶段。
当然了，你也可以输入命令，手动触发 /opsx:propose 阶段。
这个阶段完成后，你会看到项目中的 openspec 目录下多了这几个东西：
其中 proposal.md 文件长这样，可以理解为详细的需求描述：
design.md 文件的内容是这些，我觉得可以把这个文件等同于需求的详细设计文档：
tasks.md 就是把需求拆分后的一个个具体的小任务：
同时，可以看到这里拆分出了四个大的功能模块：
随便展示一个，比如 concert-poster-generator 里面的内容是这样的：
这一些功能模块，才是最核心的部分。
这里的 Scenario-WHEN-THEN 已经不是需求文档了，是专门写给 AI 看的，告诉 AI 系统应该做什么，不应该做什么，边界在哪。
是给 AI 的一份契约文档。
到这一步执行完成，还是一行代码没有写，但是产出了上面这些文档。
按照 OpenSpec 的指示，接下来，就是运行 /opsx:apply，这一步才开始正式的编码流程。
它会去读取前面产生的这些文档：
经过 10 分钟的编码，它完成了整个任务：
这就是它最终交出的页面：
这是我插入数据之后的样子：
但是它出现了一个问题，只能输入一个音乐节的信息。
我看了一下在原始的需求中，我确实没有说用户需要多次输入信息，但是在 /opsx:explore 阶段，我明确说了：注意用户可能就会输入多次音乐节的记录。
它并没有实现这个需求。
但是我也看了一下 proposal.md 文件，这里面确实没有包含这个功能：
它是严格按照 proposal.md 文件进行实现的。
这其实是一种非常“工程化”的行为。
它不再猜你想要什么，而是只对“被确认过的需求”负责。
所以，这个问题也再次说明了，应该把更多的时间花在需求讨论的阶段，一定要把需求和原始需求进行对比，查漏补缺。
这里也阴差阳错的反馈出了我想要表达一个观点。
在以前，以聊天的方式和 AI 结对编程，它会自己脑补，会猜我喜欢，会自作聪明。
但是 SDD 不会，只要 proposal.md 里面没有的，AI 绝对不会擅自发挥。
接下来，就是 /opsx:archive 归档阶段：
我们先看一下在执行这个命令之前的项目结构：
执行完成之后，整个 concert-poster-generator 文件夹就归档到 openspec/changes/archive/2026-05-24-concert-poster-generator/ 路径下了：
这样就算是完成了整个需求的归档，里面包含了整个过程中所有的 md 文档。
而这些文档，你是可以也应该要上传到代码仓库中去的。
其实，为了验证它的迭代能力，前面缺失的需求我也加上了：
操作流程和前面讲的是一样的，这里就不赘述了。
这是它修改后的页面：
然后我把这个需求也进行了归档：
后面我追溯需求的时候，一看到文档就知道：哦，原来支持输入多组数据，是在这个需求里面实现的。
所以，这些文档最大的价值，并不是“方便 AI 理解需求”。
而是它第一次把 AI Coding 过程中那些原本散落在聊天记录里的隐性决策，正式沉淀成了可追溯、可协作、可版本化的工程资产。
第四个时代
还记得这篇文章的标题吗？
AI Coding 开始进入第四个时代。
我说的这第四个时代，就是 SDD 规范驱动开发的时代。
看完前面的介绍，你应该对“规范驱动开发”有一个大概的概念了。
就是先写文档，定规范。
比如上面这个案例，当我们看完 /opsx:propose 阶段产生的这些文档，其实心里也就有底了。
有详细需求文档，有详细设计文档，有细分任务文档，还有专门写给 AI 的契约文档。
而在我的眼里，其实到这一步，这个需求已经完成了 90% 了。
当文档描述的足够完整，接下来的编码过程是整个环节中最简单的一步。
而对于一个项目来说，这些文档才是项目中最宝贵的资产，比代码宝贵多了。
毕竟，只要你有这些详细描述的文档，你扔给任何一个大模型，它都能把代码给你搞出来。
SDD 模式还解决了程序员不喜欢写文档的世纪难题。
在这个模式下，当你去回溯一个需求的时候，基本上只需要去回溯这些文档就行了，而不是去翻源码。
在传统开发里，代码是最终产物，文档只是说明书。
而在 SDD 模式里，规范才是真正的“源代码”，代码只是规范编译后的结果。
虽然要达到这个目的，还有很远的路要走。
但是我觉得在 AI Coding 的时代背景下，这是正确的方向。
所以，规范驱动开发是一个新时代，是 AI Coding 的第四个时代。
那么另外三个时代是什么呢？
第一个时代是古法编程时代，代码一行行的写，纯手搓代码。遇到不会的就打开搜索引擎。
第二个时代是和大模型在网页进行对话的时代。
就是以 ChatGPT 为代表的大模型出现之后，遇到问题就问 AI 的时代。
但是网页问答型的 AI 不知道你的项目结构，所以只能解决一些简单的问题。
即使是这样的，也已经冲击到了绝大部分初级程序员。
第三个时代就是 AI 编码工具时代。
以 Cursor、Claude Code、Codex 等为代表的 AI IDE 的出现后，它们可以读取你的项目，直接修改项目文件，能极大程度上解放双手了。
但是它们带来的问题也是突出的。
它们的产物是代码，但是它们的编码速度已经远超人类程序员 CodeReview 的速度了。
而当你想要去了解当时 AI 为什么要写这样的代码的时候，只能去翻之前和它的对话。
需求是散落在对话中的。
而 SDD 模式，先有文档，后有代码。对话的最终结果是以文档的形式存在，是可以和代码一起提交到代码仓库中的。
很好的解决了需求回溯的问题。
所以，SDD，Spec-driven development，规范驱动开发，就是 AI Coding 的第四个时代。
在接触 SDD 之前，我还是老思维，认为即使在 AI Coding 时代，代码生成就是软件开发。
现在，我有点转变这个思维了。
但 AI 时代的软件开发，已经不是写代码了。
而是形成各种规范文档、约束文档。
代码只是基于文档的输出结果。
写在最后
AI Coding 的第四个时代应该是翻天覆地的变化了。
在传统的软件开发流程里，代码是核心资产。
谁写代码快，谁厉害。
谁框架熟，谁价值高。
程序员最重要的能力，是“实现需求”。
但是 AI Coding 出现之后，一个很明显的变化开始发生了：
代码，正在变得越来越廉价。
以前一个功能可能要写一周。
现在交给 AI IDE 十分钟就出来了。
甚至很多时候，真正耗时的已经不是“怎么写”，而是“到底要写什么”。
这也是为什么 AI Coding 发展到今天，真正稀缺的能力，已经不是 Coding。
这已经是大家默认的事实了。
真正稀缺的能力是抽象需求、定义边界、拆解问题、描述系统、约束 AI、形成规范。
过去这些东西，很多时候只是“辅助工作”。
但现在，它们正在逐渐变成开发流程里的核心。
代码反而变成了最后的“编译产物”。
这也是为什么会出现 SDD 这样的理念。
如果没有规范，AI 的“创造力”，很多时候其实只是另一种形式的随机生成。
而规范，本质上是在把“随机生成”，变成“稳定生产”。
以前，文档是代码的附属品。
现在，代码是文档的衍生物。
再说一句
其实你回头去看，我的这个需求很简单，要生成海报嘛，当然是直接扔给 ChatGPT 就行了：
这两个海报的质量已经非常高了，我已经很满意了：
比我们 AI Coding 出来的质量不知道好了多少倍。
我用前面的例子只是为了刚好有个例子可以用来引出 SDD 这个概念，转而体验 OpenSpec。
真的要生成海报，还是得 GPT-image-2。
这玩意生成图片啥的，确实牛逼，属于第一梯队了。
在真实的场景中，千万不要为了使用 AI 而使用 AI。
别忘了，我最开始只是想做一张海报而已。
