在当前复杂业务系统研发中，我们常陷入诸多困境：需求反复变更导致开发返工，AI 辅助编程易出现幻觉生成无效代码，多人协作时重复开发浪费精力，上线后频繁出现回归 bug，文档与代码脱节成为'无效资产'。这些问题的核心，是缺乏一套统一可落地的研发范式，让需求、设计、开发、测试全流程形成闭环。规格驱动开发（SDD，Spec-Driven Development）正是解决这一痛点的关键。
很多开发者对 SDD 的认知停留在'先写文档再写代码'的表面，甚至觉得它是'额外负担'，尤其在工期紧张的复杂项目中，更倾向于跳过规格设计直接编码。但事实上，SDD 并非传统意义上的'文档绑架'，而是结合 AI 时代研发特点，形成的一套高效可落地的工程化方法。
本文结合 OpenSpec 这一主流 SDD 工具，从实操层面拆解 SDD 在复杂业务系统中的落地全流程，解答工具使用、流程设计、痛点解决等关键问题，帮助每一位开发者真正用好 SDD，提升复杂系统研发效率与质量。
核心概念明确
SDD 中的 Spec（Specification，规格），本质是对业务需求、技术设计、实现细节的标准化描述，是整个研发流程的'唯一真理来源'。与传统系统分析文档不同，SDD 的规格文档是'活文档'——与代码同步迭代、可执行、可验证。
OpenSpec 作为目前社区最热门的 SDD 工具之一，以轻量、敏捷、贴合 AI 辅助编程的特点，成为复杂业务系统落地 SDD 的首选。接下来从工具实操入手，逐步深入 SDD 落地逻辑。
一、OpenSpec 基础实操：从 CLI 命令到目录结构，快速上手不踩坑
复杂业务系统落地 SDD 的第一步，是选择合适工具并掌握其基础用法。OpenSpec 的核心优势是'轻量无侵入'，无需改造现有项目结构，通过简单 CLI 命令即可快速集成，且完美适配 AI IDE（如 Cursor），让 AI 成为撰写规格、生成代码的辅助，而非负担。
1.1 CLI 命令实操：6 个核心命令，覆盖全研发流程
OpenSpec 的 CLI 命令设计简洁，核心逻辑与 Git 类似，分为'初始化、日常开发、质量控制、归档'四大场景，日常常用命令不超过 3 个，其余可由 AI 代劳。
关键区分：AI 负责'创造'（写规格文档、生成代码）；CLI 负责'管理'（初始化工具、查看进度、验证格式、归档变更），分工明确、互不冲突。
以下逐一拆解核心 CLI 命令的用法、行为及适用场景，结合复杂业务场景给出使用建议：
（1）项目初始化：openspec init
- 作用：在当前项目目录初始化 OpenSpec，搭建基础目录结构（引入 OpenSpec 的第一步，唯一需手动执行的初始化操作）。
- 具体行为：自动创建
.openspec/或openspec/目录（无本质区别），生成两个核心文件：project.md：记录项目上下文（技术栈、目录约定、业务核心规则等），相当于项目'备忘录'，方便新人上手和 AI 理解项目规范；AGENTS.md：AI 说明书，配置 AI 工具（Cursor、Copilot 等）的提示词规则，确保 AI 生成内容符合项目规范。
- 适用场景：引入 OpenSpec 到现有复杂项目、新建项目启用 SDD 模式时。建议项目初始化阶段执行，避免后续规格文档混乱。
（2）配置更新：openspec update
- 作用：更新 OpenSpec 配置文件和 AGENTS.md 文档，确保 AI 提示词始终最新。
- 具体行为：升级 OpenSpec 的 npm 包、修改项目规范需同步 AI 提示词时，自动检测配置差异，更新 AGENTS.md 提示词规则及项目基础配置。
- 适用场景：升级 OpenSpec 版本后、AI 生成内容不符合项目规范时（大概率提示词过时）。复杂项目建议每 1-2 个迭代周期执行一次，确保 AI 与项目规范同步。
