最近在折腾OpenCode的实操流程，发现一个挺扎心的现象：整个AI编程链路里，SDD（规范驱动开发）这部分往往是最薄弱的一环。说起来重要，做起来敷衍，效率自然上不去。
直到遇见了Spec-Kit，这个问题才算真正有了解法——它专门给OpenCode补齐了SDD那块短板，把AI编程从“玄学”拉成了“工程”。
如果你也碰到下面这些让人头大的场景，那Spec-Kit大概就是你需要的东西。
一：需求说不清楚，AI死活听不懂
甩一句“帮我写个管理系统”，AI确实能给你生成一堆代码。但你定睛一看——数据库设计乱得跟蜘蛛网似的，API命名天马行空，完全没有扩展性，项目根本跑不起来。
二：改个需求，炸了整个工程
写到一半，产品经理过来说“加个功能”、“加个接口”。你让AI去改，结果牵一发动全身，之前辛辛苦苦写的代码全部报废，直接返工。
三：同样的需求，代码质量跟过山车一样
第一版写出来的代码结构清晰、层次分明，第二版——简直就是一坨屎山。你完全搞不懂为什么，只能归结为“AI今天心情不太好”。
四：版本管理一塌糊涂
Git提交记录乱七八糟，版本号根本对不上。每次想回退都得翻半天，最后索性不管了。
只要上述任何一条戳中了你，那这篇文章最好认真看完。
GitHub官方推出的Spec-Kit工具，专为OpenCode设计，把AI编程变成了真正标准化的工程流程。它的核心思路其实很简单——先想清楚，再动手写。
这套流程浓缩为最核心的5个步骤，直接集成到OpenCode中：
3分钟上手使用Spec-Kit
第一步：安装Spec-Kit
打开终端，执行安装命令：
# 安装specify命令行工具
uv tool install specify-cli --from git https://github.com/github/spec-kit.git
# 验证安装
specify check
第二步：初始化OpenCode项目
# 创建新项目（指定使用OpenCode）
specify init my-project --ai opencode
# 或者在当前目录初始化
specify init . --ai opencode
初始化完成后，打开OpenCode，你会看到左上角显示项目名称，同时AI助手已经加载了SDD相关的命令。
第三步：开始写规范
在OpenCode的AI对话中，依次输入以下命令：
1. 创建项目开发原则（宪法）
/speckit.constitution 创建项目开发原则：
- 代码优先使用.Net
- 遵循函数式编程范式
- 功能必须完整实现
- 单元测试覆盖率不低于80%
生成 .specify/memory/constitution.md，这相当于给AI定下了“家规”，所有代码都必须遵从这套底线规则。
2. 写清楚功能需求
/speckit.specify 开发一个问卷系统：
- 支持用户注册、登录、获取个人信息
- 支持问卷的增删改查
- 支持标签分类和全文搜索
- 实现基于JWT的认证机制
- API返回格式统一为 {code, message, data}
这里的关键：只说“做什么”，绝不说“怎么做”。技术细节交给下一步。
3. 规划技术方案
/speckit.plan 使用以下技术栈：
- vue.js + element ui框架
- .Net8 + SQLite（便于本地开发）
- JWT进行身份认证
- 使用标准的RESTful API设计
4. 生成任务清单
/speckit.tasks
AI会自动把大需求拆成可执行的小任务：
✅ 任务清单已生成：
任务1：项目基础结构搭建
├─ 创建.Net应用入口
├─ 配置SQLite数据库连接
├─ 设置CORS中间件
└─ 配置环境变量
任务2：用户认证模块
├─ 实现用户注册接口
├─ 实现用户登录接口
├─ 实现JWT token生成和验证
└─ 添加路由守卫中间件
任务3：问卷CRUD模块
├─ 创建问卷实体模型
├─ 实现问卷增删改查API
├─ 实现标签分类功能
└─ 实现搜索接口
5. 开始编码
/speckit.implement
AI会严格按照计划开始编写代码，每一行都有据可依。
项目结构一览
使用SDD后，你的项目会多出一个 .specify/ 目录，它就像项目的“中枢神经系统”：
my-blog-api/
├── .specify/
│ ├── memory/
│ │ └── constitution.md # 项目原则（宪法）
│ ├── specs/
│ │ └── 001-blog-api/
│ │ ├── spec.md # 功能需求文档
│ │ ├── plan.md # 技术方案文档
│ │ └── tasks.md # 任务清单
│ └── scripts/
│ └── *.sh # 辅助脚本
├── src/
│ ├── entities/ # 数据实体
│ ├── routes/ # 路由定义
│ ├── middlewares/ # 中间件
│ └── index.ts # 入口文件
├── tests/
├── package.json
└── tsconfig.json
为什么OpenCode + SDD这么好用？
优势一：需求描述更清晰
SDD强制你把模糊的想法转化为清晰的文档。AI不再是“猜你想要什么”，而是“按照文档实现什么”。从源头杜绝沟通偏差。
优势二：代码质量更稳定constitution.md定义了代码的底线标准，所有生成的代码都遵循同一套规范，不会再出现“第一版精品，第二版屎山”的过山车体验。
优势三：需求变更更可控
产品经理说要改需求？没问题。改一下 spec.md，然后重新执行 /speckit.implement，AI会自动调整代码，而不是胡乱打补丁。
优势四：团队协作更顺畅
新成员加入？看一遍 .specify/ 目录下的文档，就能大致了解项目全貌，完全不用翻历史记录去猜你的思路。
进阶技巧
需求有疑问？用 clarify！
/speckit.clarify
这个命令会自动分析你的需求文档，找出描述模糊的地方，逐个问你澄清。可以说是强化版的“需求确认”，确保需求100%明确。
写完想检查？用 checklist！
/speckit.checklist
生成一个质量检查清单，逐项验证代码是否满足需求。相当于给代码上了个自动审核器。
想看有没有遗漏？用 analyze！
/speckit.analyze
分析需求文档、技术方案、代码三者之间的一致性，发现潜在问题。相当于提前帮你踩坑。
只想验证环境？
specify check
检查你的OpenCode和其他必需工具是否安装正确。
什么时候用SDD？什么时候不用？
✅ 强烈推荐使用SDD：
- 正规项目开发（需要长期维护）
- 团队协作项目
- 功能复杂的业务系统
- 对代码质量有要求的项目
- 需求可能变更的项目
❌ 可以不用SDD：
- 快速原型验证
- 简单的脚本工具
- 学习新技术做实验
- 一锤子买卖的代码
快用Spec-Kit给你的OpenCode配上一套规范化的流程吧。它不是锦上添花，而是直接让AI编程从“野路子”走上了“正规军”的道路。
