主题
基于规范的 AI 编程 SDD(Spec-Driven Development for AI)
引言
vibe coding
gemini给出的一个定义: 通过描述需求(Vibe)而非逻辑细节来构建应用的开发方式
存在问题
抽卡式开发”：输入 Prompt 像拉老虎机，运气好代码能跑，运气不好改一天 上下文遗忘：多轮对话后，AI 忘了第一句的要求 维护地狱：逻辑散落在几十轮聊天记录里，无法复现
如何改善
从“聊天”转向“工程化约束” - SDD
一种开发模式 强调在编写代码前,通过结构化的规范文档(Spec)明确 "做什么" 和 "为什么"
目的 规避 AI 的幻觉与上下文歧义的开发模式
工作流对比：
vibe coding 模式：想法 -> 聊天 -> 代码 -> 修改聊天 -> 代码
SDD 模式：人产生想法 ->由AI配合人 编写 Spec 文档 -> AI 读取 Spec -> 生成代码 -> (若有错) 修改 Spec -> 重新生成。
spec 长什么样
一般情况下是一个md文档 结构：目标 (Goal) + 上下文 (Context) + 约束 (Constraints) + 步骤 (Steps)。 例子
目标：支持科学计算功能
上下文：GUI界面，类似Windows计算器
约束：
支持三角函数、对数、幂运算
保留10位小数精度
提供历史记录功能
使用web技术,vue
步骤：
初始化GUI界面
绑定按钮事件
解析并计算表达式
显示结果
保存到历史记录
模式的特点
- 先确定Spec(规范), 再生成代码
- 当实现与 Spec 冲突时，以 Spec 为准。先修改规范, 然后根据规范通过agent修改代码
- 人类作为设计师定义问题、审查计划
- AGENT 负责按图施工
仅了解, 鉴于当前大模型的能力还层次不起, 在实际工作中可以变通, 不必严格遵守
在什么情况下使用
建议使用的情况
- 梳理业务或者技术
- 创建演示demo
- 创建/重构模块
- bug修复
不建议使用的情况
- 小修改, 比如改css颜色, 修改方法名称, 增加实体字段
- 探索性编程, 需要ai发挥场景
能带来什么收益
在合适场景下, 可以带来以下收益
- 节省token消耗 -- 避免产生的结果和预期不符, 反复修改反而造成了token的浪费
- 理清思路 -- 通过反复和agent反复沟通和确认, 可以细化业务逻辑和技术方向
- 基于规范的约束,方便回顾, 审查代码 --
- 方便自查和团队沟通 -- 用规范草进行沟通, 方便问题的发现和解决, 和功能的增减
如何使用 - how
SDD是一个规范, 目前已经存在多个实现该规范的ide和agent
实现有计划模式的IDE和
- claude code
- iflow
- trae
- cursor
实现计划模式的库
- spce-kit
- openspce
主推 openspce 网址: github.com/Fission-AI/… 特点: - 不绑定于任何工具, 可以agent A创建提案, agent B执行提案 - 基于文件系统, 可以手动修改 - 适用于0到1之外的阶段 (spec-kit与Kiro: 擅长全新功能 (0到1)) - ...
不同工具在实现上和文档结构定义上会有有差异, 但是其思想有意或者无意和SDD契合
主体
哪些人可以使用
- 开发 ...
- 产品: 在规范的技术上, 生成文档形式的内容
- 测试人员: 基于规范, 生成测试用例或者测试规范
- 运维: 基于 Spec 生成 Terraform/Docker/K8s 配置。 通过 Spec 约束云资源的使用（例如：限制实例类型、强制打标签），实现“文档即基础设施” 我有次电脑一直被检测到攻击, 我用codex排查了2天, 最后找到原因, 结论windwos的发现机制导致的攻击
一些结论
- 简单来说就是 使用spce(规范)约束ai产生内容, 减少结果和预期差异的工具
- SDD作为一个规范, 受限于agent调度方式和大模型生成能力的差异, SDD目前表现能力也有待提升, 但是这个模式具有启发意义
- 建议: 用贵的模型进行规划, 用快的模型进行编码
- 具体使用方法可以哔站或者@我
