AI辅助开发中SDD规范的重要性

Cder
107 阅读6分钟

你用AI工具了吗

没有AI的时候，开发一个功能，步骤是：需求文档 --> 撸代码 --> 测试 --> 部署上线

到了AI初期阶段，代码开发借助AI工具，可以快速生成代码，个人生产力在激增，但是项目级别的工程可预测性却在降低，原因在于用模糊的自然语言描述问题和零散的对话来指导AI工作，也就是所谓的 Vibe Coding 这个时候需要一种规范来约束AI的行为，让AI能按照我们的预期工作，这就是所谓的SDD(规范驱动开发)

如今AI辅助工具层出不穷，各种大模型也相继迸发，更多的程序员借助AI的能力解放双手，也衍生出了AI辅助规范，可以通过定义Rules、Skills、Commands这些文件配置来让AI更规范，更精准的生成符合我们需求的代码

Vibe Coding 存在的问题？

我：给我开发一个用户登录功能

AI：balabala...开发好了（结果，不符合逾期，我只需要手机号登录，并且验证密码的强度）

我：补充完需求后....

AI：balabala...开发好了（结果，还是有问题，没验证手机号格式，没有登录错误次数限制）

我：继续补充需求后

AI：一顿输出，还是有大大小小的问题.....

......

来来回回的拉扯，AI理解的跟我们实际的需求还是有偏差，需要我们反复修正，同时任务拆解不细致，容易遗漏功能点

而OpenSpec作为一个有效的SDD轻量级框架，提供了实用的工具包，同时兼容强，支持主流的AI编码工具（Claude Code、Cursor、Github Copilot等），其结构化的四阶段工作流使得项目开发更精准，更低的返工率

四阶段工作流：强制执行提案、审查、实施和归档

Vibe Coding 和 SDD 的区别是什么？

类比盖房子，Vibe Coding就是凭感觉去盖房子，而SDD就是按照图纸去盖房子

类比做菜，Vibe Coding就是凭感觉放调料去做菜，味道不稳定，而SDD就是按照菜谱精确配比去做菜，稳定出品

讲SDD之前先了解下Rules、Skills、Commands？

  1. Rules：规则，约束AI的行为，比如，你是一个专业的前端专家，擅长React开发（自动触发，但你要求AI给你初始化生成一个项目的时候，AI会根据你的规范，给你生成一个React的工程，而如果你没写这个Rules，可能就会给你生成一个Vue项目，不符合你的实际需求）

  2. Skills：要什么，一个需要智能达成的目标，通常是多步、对话式的协作过程（确定性相对较低，AI有自助决策空间，结果可能因描述而异）。比如：帮我新建一个Vue项目，Agent会根据你在skill中定义的规则（用Vue3创建项目，用组合式API组织代码...）来完成任务

  3. Commands： 做什么，一个具体的动作指令，通常是单次的直接的执行（高，结果可预测）

Tip：Sill 和 Command 选择

当你需要快速、精准地执行一个操作时，使用 Command。

当你需要AI 帮你分析、规划并完成一个相对复杂的开发任务时，使用 Skill。

开始使用OpenSpec

npm install -g @fission-ai/openspec@latest 全局安装

openspec init 初始化（会生成一个.cursor基础目录结构，其中有config.yaml，并且会内置一些默认的Rules、Skills、Commands）

  • 主规格库：openspec/specs/，存放各能力的正式规格（单一事实来源）。
  • 变更：openspec/changes/<name>/，一次需求或改动的完整记录（proposal、specs、design、tasks）。
  • 归档：完成的变更可移入 openspec/changes/archive/YYYY-MM-DD-<name>/，并将 delta spec 合并回主规格。

Tip： >Version 1.0.0 版本已经更改了指令语法

AI辅助工具中

  1. 配置文件：openspec/config.yaml，用于配置项目的基本信息和规则（旧版本是通过Project.md和Agent.md文件来配置的）
  • schema：默认工作流，如 spec-driven（proposal → specs → design → tasks）。
  • context：多行文本，描述项目目的、技术栈、代码风格、架构、领域概念等；创建或完善工件时会被 AI 读取，不要把整段 context 抄进工件里。
  • rules：按工件类型约束内容，例如：
    • proposal：明确项目范围与 Non-goals，使用领域术语。
    • tasks：任务约 2 小时粒度，API 使用 kebab-case 与分层架构。

修改项目约定或领域说明时，应更新 config.yaml 的 context/rules，而不是只改单次变更的文档。

  1. /opsx-new： add-dark-mode 添加一个changes（add-dark-mode）
  2. /opsx-continue： 开始第一个工件proposal.md的编写，执行这个会根据你的上一步骤的名称推测出你要做什么，这个时候我们可以根据自己需求修改proposal.md内容
  3. 后续像步骤3一样，执行/opsx-continue，直到完成所有工件的编写（design.md、tasks.md、specs.md）
  4. 3和4这两个步骤可以合并执行，/opsx-ff，一步到位把几个工件全部完成，个人建议按/opsx-continue一步步来，方便修改，因为后续的design、spec和task是依赖proposal的，完善好proposal的编写有利于AI帮我们补充更准确的其它工件内容
  5. /opsx-apply 执行任务，按照我们生成出来的task.md文件一步步执行，并更改任务状态
  6. /opsx-archive 归档变更，将完成的变更移入 openspec/changes/archive/YYYY-MM-DD-<name>/。

目录结构

openspec/
├── specs/                          # 所有系统规范的当前真相来源（最后 archive 后会合并到主规格库）
│   └── theme-dark-mode/
│       └── spec.md
├── changes/                        # 所有提议、活动和已归档变更的目录
│   └── add-dark-mode/              # archive 后会删除此目录(完成后的changes会移动到archive目录)
│       ├── proposal.md             # 变更的「原因」和「内容」
│       ├── design.md               # 变更的「设计」
│       ├── tasks.md                # AI 的实施检查清单
│       └── specs/                  # 规范的增量「补丁」
│           └── theme-dark-mode/
│               └── spec.md
└── archive/                        # 归档的变更目录（完成后的 changes 会移动到这里）
    └── 2026-02-06-add-dark-mode/
        ├── proposal.md
        ├── design.md
        ├── tasks.md
        └── specs/
            └── theme-dark-mode/
                └── spec.md

总结

OpenSpec虽然好，但是在前期完善需求变更提案(proposal)，以及执行任务(apply)中需要花比较多的时间，对AI生成的代码也需要验证。对一些需要快速原型验证、不需要文档沉淀的场景不太适用OpenSpec

OpenSpec迫使研发需要更清晰了解业务，以及架构设计，去给AI设置一些边界，这样才可控

其它

规范驱动工具还有：spec-kit（擅长0 -> 1） Kiro（擅长1 -> n）

引用

avatar
文章
阅读
粉丝