OpenSpec 概述： 用 OpenSpec，让 AI 写代码这件事变得“靠谱”

这两年，AI 写代码已经从“新奇体验”变成了很多团队的日常工具。

但很快大家会遇到一个更现实的问题：
AI 确实能写，但它写得对不对、稳不稳，其实很难保证。

有时候你只是说了一句需求，它却补全了一整套你没打算做的东西；
有时候它理解偏了一点点，你却要花几倍时间去修正。

问题往往不在 AI，而在输入。

于是，一种更“工程化”的用法开始出现——OpenSpec。

AI 写代码，为什么总是“差一点”

大多数人用 AI 写代码，流程大概是这样的：

• 在聊天里描述需求
• AI 给出实现
• 来回修几轮
• 勉强可用

看起来很高效，但隐患很明显：

• 需求散落在对话里，无法沉淀
• 不同轮次的上下文容易冲突
• “做到什么算完成”没有明确标准

换句话说：
我们在用一种“聊天方式”，做一件本质上是“工程协作”的事情。

这就是问题的根源。

OpenSpec 在做什么？

OpenSpec 提供了一种很简单但很关键的转变：

把“对话”变成“规格”，再让 AI 按规格工作。

它并不复杂，只是把一次开发拆成几类固定的信息：

• proposal：为什么要做这件事
• specs：具体要满足哪些需求与场景
• design：打算怎么实现
• tasks：拆成可以执行的步骤

这些内容通常会放在一个 change 目录里，对应“一次改动”。

这件事的本质是：
把原本会丢失的上下文，变成可以复用的工程资产。

一个直观的对比

假设你想做一个“暗黑模式”。

传统方式，你可能会这样说：

帮我加一个暗黑模式

AI 会帮你“猜”，然后生成一套它认为合理的实现。

而用 OpenSpec，你会这样写 specs：

• 场景1：用户切换开关后，页面主题立即变化
• 场景2：刷新页面后，主题保持不变
• 场景3：未加载 JS 时，使用系统默认主题

再补充一句：

• 非目标：不支持多主题，仅支持亮/暗两种

这时，AI 不再需要猜，而是按你的定义执行。

差别就在这里。

它为什么有效？

OpenSpec 有效，不是因为它“更规范”，而是因为它解决了三个核心问题：

1. 把“模糊需求”变成“可执行输入”

AI 最怕的不是复杂，而是模糊。

当你把需求写成具体场景，它就有了明确边界。

2. 把“理解成本”前置

以前的问题是：
写代码的时候才发现理解错了。

现在变成：
在 specs 阶段就对齐清楚。

这会极大减少返工。

3. 让结果“可以验证”

当你写清楚：

• 输入是什么
• 输出应该是什么
• 哪些情况算通过

那么“完成”就不再是主观判断，而是可验证的结果。

实际怎么用？很简单

OpenSpec 的实际使用，可以理解为一个循环：

第一步：提出 change

一句话描述需求，例如：

“为用户系统增加暗黑模式，并在刷新后保持状态”

然后生成初始的 proposal / specs / design / tasks。

重点不是完美，而是先有结构。

第二步：边做边修

在实现过程中：

• 发现需求不清 → 改 specs
• 发现方案不合理 → 改 design
• 任务太大 → 拆 tasks

整个过程是“流动的”，而不是一次定死。

第三步：归档

完成后，把这次 change 保存下来。

久而久之，你会得到一套很有价值的资产：

• 可复用的需求写法
• 稳定的设计模式
• 清晰的验收标准

一个关键转变

很多人第一次接触 OpenSpec，会觉得：

“是不是要多写很多文档？”

其实恰恰相反。

OpenSpec 的核心不是“写更多”，而是：

只写真正影响结果的那部分信息。

尤其是两点，非常关键：

• 写清楚“非目标”（不做什么）
• 用“场景”代替“口号”

这两件事，会直接决定 AI 是否跑偏。

什么时候值得用？

OpenSpec 并不是银弹，但在这些场景里特别有价值：

• 需求经常变化的项目
• 需要多人协作的团队
• 在已有系统上持续迭代
• 希望 AI 输出“可 review、可复用”的代码

而对于一次性脚本、小修小补，它可能反而有点“重”。

最后

AI 写代码这件事，正在从“生成能力”走向“工程能力”。

而 OpenSpec 代表的是一种趋势：

我们不再只是让 AI 帮忙写代码，而是让它参与一套可控的开发流程。

当“规格”成为核心输入后，AI 的角色也会发生变化——
从一个“有时很聪明的工具”，变成一个稳定可靠的协作者。