夜雨聆风不绑定任何工具、一条命令生成规范——这是个人开发者拥抱SDD的最低门槛路径。
在前几篇文章中，我们完整走通了从"为什么要SDD"到"怎么落地SDD"的全过程：第一篇揭示了Vibe Coding的困境和SDD范式革命的必然性；第二篇用一张全景图梳理了SDD的工具生态和技能框架；第三篇通过保姆级教程演示了如何用OpenSpec从零到一交付完整项目；第四篇则聚焦在祖传代码的存量系统中如何引入SDD。如果你对之前的内容还不熟悉，建议先查看文末的合集目录，回顾系列中的相关文章，再来阅读本篇会更加顺畅。
本篇我们将视角转向个人开发者——不绑定任何工具，用OpenSpec加上你手边的任何AI，就能体验SDD的完整工作流。
一、轻量组合：个人开发者拥抱SDD的最佳起点
1.1 什么是轻量组合？
在SDD的工具生态中，轻量组合指的是：OpenSpec（规范层）+ 你手边的任意Coding Agent（执行层） 。
核心特点：
| 零API成本 | |
| 不绑定特定AI | |
| 上手最快 | npm install命令即可完成安装 |
| 规范可迁移 |
1.2 为什么个人开发者最适合轻量组合？
个人开发者（或小团队）面临三个典型困境：
困境一：预算有限。 Claude Pro订阅每月20美元，API调用按量付费——对于个人开发者来说，这是一笔不小的持续支出。轻量组合的OpenSpec完全免费，你只需要使用手边已有的AI工具（可能是免费版的ChatGPT、Claude.ai、或是你已经订阅的Cursor）。
困境二：工具不固定。 个人开发者往往在多个AI工具之间切换——今天用Cursor写前端，明天用Claude Code调后端，后天用ChatGPT做代码审查。轻量组合不锁定任何工具，你可以随时切换。
困境三：流程缺失。 个人开发者最容易陷入"Vibe Coding"陷阱——需求散落在聊天记录里，AI生成的代码质量忽高忽低。轻量组合用一套文件化的规范系统解决了这个问题。
1.3 轻量组合的适用场景
💡 核心优势：轻量组合让你用最低的成本、最快的速度体验SDD的完整工作流。等项目和团队成长后，可以无缝升级到标准组合或企业级组合。
二、OpenSpec完整工作流详解
OpenSpec的核心理念是：写代码前，先让人类和AI对"要做什么"达成一致。它通过四条核心命令，将开发过程分为四个清晰的阶段。
2.1 四条核心命令
OpenSpec提供四个核心Skill（技能），覆盖完整的开发周期：
2.2 /opsx:explore：探索模式（只读）
用途：在创建任何文件之前，先和AI"头脑风暴"，理清需求和设计思路。
语法：/opsx:explore [主题]
执行机制：
- 只读模式
：AI可以阅读代码、搜索文件、分析架构，但绝不创建或修改任何文件 - 交互式对话
：AI会提出澄清性问题，帮你把模糊想法变成清晰方案 - 无产出物
：探索阶段不产生任何文件，所有内容留在对话中
典型交互流程：
你: /opsx:explore 我想做一个天气查询命令行工具
AI: 好的，让我们一起来理清这个需求。
我先问几个澄清性问题：
1. 你希望支持按什么方式查询天气？（城市名/ZIP code/自动定位）
2. 需要显示哪些天气信息？（温度/湿度/风速/预报）
3. 你希望输出什么格式？（纯文本/JSON/彩色表格）
4. 需要调用外部API吗？有偏好的天气API吗？
请告诉我你的想法，我会帮你完善设计方案。
什么时候用：
需求模糊，需要AI帮助澄清 不确定技术方案，需要AI对比选项 想在写规范前确认方向是否正确
2.3 /opsx:propose：提案模式（写入）
用途：一步创建变更并生成所有规划制品。
语法：/opsx:propose [变更名称或描述]
执行机制：
创建变更目录： openspec/changes/<change-name>/自动生成四个制品文件：
openspec/changes/<change-name>/
├── proposal.md # 为什么要做、做什么
├── design.md # 技术设计方案
├── tasks.md # 实施任务清单
└── specs/ # 规范增量（Delta）
└── <domain>/
└── spec.md # 功能需求与验收场景
四个制品的详细说明：
| proposal.md | ||
| spec.md | AI编码的依据 | |
| design.md | ||
| tasks.md | AI执行的路线图 |
2.4 /opsx:apply：实施模式（写入）
用途：按tasks.md逐条实现代码。
语法：/opsx:apply
执行机制：
AI读取 tasks.md中的任务清单逐条完成任务，并在完成后标记为 [x]实时显示进度
典型执行过程：
你: /opsx:apply
AI: 正在执行任务...
✅ 1.1 创建项目目录结构
✅ 1.2 安装Python依赖
✅ 1.3 实现天气查询函数
✅ 1.4 添加CLI参数解析
✅ 1.5 添加错误处理
⏳ 2.1 测试有效城市名 (进行中...)
2.5 /opsx:archive：归档模式（写入）
用途：归档已完成变更，将规范增量合并到主规范库。
语法：/opsx:archive
执行机制：
将 changes/<name>/specs/中的增量规范合并到specs/将整个变更目录移动到 changes/archive/YYYY-MM-DD-<name>/更新项目的主规范库
归档前 vs 归档后：
2.6 两种工作流模式
OpenSpec提供了两种工作流模式：
| 快速工作流（core） | /opsx:propose/opsx:apply → /opsx:archive | 个人开发者、小需求 | |
| 扩展工作流 | /opsx:new/opsx:continue → /opsx:ff → /opsx:apply → /opsx:archive |
💡 轻量组合推荐使用快速工作流——个人开发者追求效率，一步到位生成所有制品，然后聚焦在审阅和执行上。
三、与任意Coding Agent的协作模式
3.1 支持的AI工具全景
OpenSpec支持22+种AI编程工具，包括但不限于：
| 终端原生 | ||
| IDE集成 | ||
| 通用对话 | ||
| 其他 |
3.2 三种协作模式
模式一：原生集成（Claude Code等）
如果你使用Claude Code，OpenSpec初始化时会自动配置斜杠命令。在对话中直接输入/opsx:propose、/opsx:apply等命令即可。
模式二：IDE集成（Cursor、Windsurf等）
在Cursor的Composer或Windsurf的对话中，同样可以输入OpenSpec的斜杠命令。OpenSpec初始化时会根据你选择的AI工具生成对应的配置文件。
模式三：通用方式（ChatGPT、Claude.ai、Gemini等）
如果你使用的是不支持斜杠命令的通用AI工具，操作流程如下：
操作示例：
# 第一步：在ChatGPT/Claude.ai中输入
请按OpenSpec规范，为"天气查询命令行工具"生成以下制品：
1. proposal.md（为什么做、做什么）
2. spec.md（需求+验收场景）
3. design.md（技术决策）
4. tasks.md（实施清单）
# 第二步：将AI生成的内容保存到本地
# 第三步：将tasks.md的内容作为Prompt，输入任意AI
请根据以下任务清单，逐项实现代码：
## 1. Core Implementation
- [ ] 1.1 实现天气查询函数
- [ ] 1.2 添加CLI参数解析
...
💡 通用方式的优势：你完全不受工具限制——今天用ChatGPT，明天用Claude.ai，后天用Gemini，规范文件是通用的。
四、开发者在轻量组合中的角色
在轻量组合中，开发者的角色从"编码者"转变为"规范定义者"和"质量把关者"。
4.1 探索参与者
在/opsx:explore阶段，你的核心工作是回答AI的澄清性问题。AI不知道你的业务上下文，需要你提供：
功能的真实使用场景 你偏好的技术方案 已知的约束和限制
4.2 规范确认者
/opsx:propose生成四个制品后，你必须审阅。这个阶段修改成本最低——改几行Markdown比改代码快得多。
审阅检查清单：
proposal.md:
- [ ] Why是否说清楚了问题？
- [ ] What是否覆盖了所有功能？
- [ ] Impact是否准确？
spec.md:
- [ ] 每个需求是否包含至少一个Scenario？
- [ ] Scenario是否使用GIVEN-WHEN-THEN格式？
- [ ] 边界情况是否覆盖？
design.md:
- [ ] 技术选型是否合理？
- [ ] 风险是否已识别？
- [ ] 是否有过度设计？
tasks.md:
- [ ] 任务粒度是否合适（2-5分钟/个）？
- [ ] 任务依赖关系是否正确？
4.3 质量把关者
/opsx:apply执行过程中，每个任务完成后需要进行检查点验证：
检查点清单:
功能正确性:
- [ ] 代码是否实现了spec.md中对应的Scenario？
- [ ] 是否有spec.md未定义的额外功能？
代码质量:
- [ ] 代码风格是否一致？
- [ ] 是否有明显的bug或逻辑错误？
测试覆盖:
- [ ] 核心逻辑是否有测试？
- [ ] 测试是否覆盖了边界情况？
五、实战案例：天气查询CLI工具
下面通过一个完整的实战案例，演示轻量组合的完整流程。
5.1 场景设定
需求：创建一个命令行天气查询工具，用户输入城市名，返回当前天气信息。
技术约束：
使用Python 零外部依赖（仅用标准库） 调用免费天气API
5.2 步骤一：/opsx:explore 理清需求
在AI助手中输入：
/opsx:explore 我想做一个天气查询命令行工具，用户输入城市名就能看到天气。
帮我理清需求、技术方案和边界情况。
AI会进行多轮对话：
AI: 好的，让我帮你理清这个需求。
几个澄清性问题：
1. 天气数据来源：你希望用哪个天气API？
- wttr.in（免费，无需API Key）
- OpenWeatherMap（需要免费API Key）
- 其他？
2. 需要显示哪些信息？
- 仅当前温度
- 温度 + 天气状况（晴/雨/多云）
- 温度 + 湿度 + 风速 + 预报
3. 输出格式偏好？
- 纯文本
- 彩色终端输出
- JSON格式（供其他工具使用）
4. 错误处理：
- 无效城市名 → 显示友好错误信息
- 网络超时 → 重试还是报错？
请告诉我你的选择。
经过几轮往返，确认最终方案：
- API
：wttr.in（免费、无需API Key） - 显示信息
：城市名、温度、天气状况 - 输出格式
：纯文本 - 错误处理
：无效城市名显示友好错误，网络超时显示提示
5.3 步骤二：/opsx:propose 生成规范
/opsx:propose "创建天气查询命令行工具"
AI自动生成四个制品文件：
proposal.md：
# Proposal: 天气查询命令行工具
## Why
在终端快速查看天气，不需要打开浏览器或手机。
## What Changes
- 新增 weather-cli 命令行工具
- 支持 weather <城市名> 和 weather --help
- 支持含空格的城市名（如 "New York"）
## Impact
- 新增文件：weather.py
- 无外部依赖（仅用 Python 标准库）
spec.md（核心）：
# Weather CLI Specification
## Requirements
### Requirement: 城市天气查询
系统SHALL接受城市名并返回当前天气信息。
#### Scenario: 有效城市名
- **GIVEN** 用户已安装weather-cli
- **WHEN** 用户运行 `weather London`
- **THEN** 系统显示伦敦的当前天气（温度+状况）
#### Scenario: 含空格的城市名
- **WHEN** 用户运行 `weather "New York"`
- **THEN** 系统正确显示纽约的天气
#### Scenario: 无效城市名
- **WHEN** 用户运行 `weather xyzxyzxyz`
- **THEN** 系统显示友好错误信息："未找到城市，请检查城市名"
### Requirement: 帮助信息
系统SHALL提供 --help 选项。
#### Scenario: 显示帮助
- **WHEN** 用户运行 `weather --help`
- **THEN** 系统显示使用说明
design.md：
# Design: 天气查询CLI工具
## Decisions
- **API**: wttr.in（免费、无需API Key）
- **语言**: Python 3（仅用标准库）
- **输出**: 纯文本
- **超时**: 10秒
## Risks / Trade-offs
- [API可能被限流] → 添加超时处理和重试
- [城市名含空格] → 支持引号包裹
tasks.md：
# Tasks: 天气查询CLI工具
## 1. Core Implementation
- [ ] 1.1 实现天气查询函数（调用wttr.in API）
- [ ] 1.2 添加CLI参数解析（argparse）
- [ ] 1.3 添加错误处理（网络超时、无效城市）
## 2. Testing
- [ ] 2.1 测试有效城市名
- [ ] 2.2 测试含空格城市名
- [ ] 2.3 测试无效城市名
- [ ] 2.4 测试 --help
## 3. Documentation
- [ ] 3.1 添加README
5.4 步骤三：审阅与确认
人工审阅四个制品，确认：
✅ 需求覆盖了有效城市、含空格城市、无效城市三种场景 ✅ 技术选型合理（wttr.in免费、零依赖） ✅ 任务拆解粒度合适（每个任务2-5分钟） ✅ 边界情况已覆盖（网络超时、无效输入）
5.5 步骤四：/opsx:apply 执行实现
/opsx:apply
AI逐项完成任务：
# 1.1 实现天气查询函数
import urllib.request
import json
import sys
def get_weather(city: str) -> dict:
"""调用wttr.in API获取天气信息"""
url = f"https://wttr.in/{city}?format=j1"
try:
with urllib.request.urlopen(url, timeout=10) as response:
data = json.loads(response.read().decode())
return {
"city": data["nearest_area"][0]["areaName"][0]["value"],
"temp": data["current_condition"][0]["temp_C"],
"condition": data["current_condition"][0]["weatherDesc"][0]["value"]
}
except urllib.error.URLError:
return {"error": "网络连接失败，请检查网络"}
except json.JSONDecodeError:
return {"error": "未找到城市，请检查城市名"}
AI继续完成1.2（CLI参数解析）、1.3（错误处理），以及2.1-2.4（测试）。
5.6 步骤五：/opsx:archive 归档
/opsx:archive
AI将规范合并到主规范库，变更移至归档目录。
AI: 已归档至 openspec/changes/archive/2026-07-01-add-weather-cli/
规范已更新。准备好进行下一个特性开发。
六、轻量组合的优缺点分析
| 零成本启动 | |
| 工具自由 | |
| 上手最快 | npm install命令即可开始 |
| 规范可迁移 | |
| 渐进式升级 |
| 缺少流程自动化 | ||
| 缺少SubAgent能力 | ||
| 规范质量依赖人工 | ||
| 大规模项目效率不足 |
七、本章小结
本章我们完整走通了SDD轻量组合的全流程：
轻量组合是什么：OpenSpec（规范层）+ 任意Coding Agent（执行层）——零成本、不绑定工具、上手最快。
四条核心命令：
/opsx:explore：探索模式，只读不写，理清需求 /opsx:propose：一步生成proposal/specs/design/tasks四个制品 /opsx:apply：按tasks.md逐项实现代码 /opsx:archive：归档变更，合并规范 三种协作模式：原生集成（Claude Code）、IDE集成（Cursor）、通用方式（任意AI）——无论你用哪个工具，都能使用OpenSpec。
开发者四重角色：探索参与者 → 规范确认者 → 流程协调者 → 质量把关者。你不是在"写代码"，而是在"定义意图"和"验证输出"。
实战案例：天气查询CLI工具——从
/opsx:explore理清需求，到/opsx:propose生成规范，到/opsx:apply实现代码，到/opsx:archive归档——完整走通全流程。
核心心法：
轻量组合 = OpenSpec（规范引擎）+ 你手边的任何AI（执行引擎）
你不需要花一分钱，不需要学新工具，不需要改变工作习惯。
只需要在写代码之前，先让AI帮你把"要做什么"想清楚、写下来。
这就是个人开发者拥抱SDD的最低门槛路径。下一章，我们将升级到标准组合——看看OpenSpec + Superpowers + Claude Code这"三驾马车"如何协同作战，实现1+1>2的效果。
📌 系列预告
- 第6章
：谁写规范？谁控流程？谁写代码？——SDD标准组合"三驾马车"的分工艺术 - 第7章
：从"完成项目"到"沉淀能力"：企业级SDD组合的复利之道 - 第8章
：SDD是银弹还是噱头？——规模化落地、争议与未来展望
如果觉得这篇文章对你有帮助，欢迎点个关注，后续还会继续分享SDD标准组合和企业级组合的实战经验。文末有合集目录，可以回顾系列中之前的文章，也能第一时间获取最新更新。
