OpenSpec

通过 SDD + OpenSpec，我们在一个真实的存量项目中，用 AI 生成了 9600+ 行可编译、可测试的代码，手动修改不到 50 行。本文记录了完整的实践过程、评测结果和踩坑经验。

OpenSpec 架构 整体架构 可以把它理解成三层： 状态层：仓库目录本身就是状态存储 计算层：schema + dependency graph + validator 交互层：CLI 和 skills，把结构化状态喂给 AI 或人 这套分层很重要，因为它避免了一个常见问题：把“流程”硬编码进 prompt。在 OpenSpec 里，prompt 只是表现层；真正的工作流定义在 schema 中，真正的状态在文件系统里。 核心对象 OpenSpec 其实有4个核心对象： specs：当前系统行为的 source of truth changes：待合入的变更包 schema：工作流定义，决定有哪些 artifact、它们如何依赖 archive：变更完成后的历史沉淀 如果第一次使用，你可能会好奇schema是什么? 在每次变更文件夹中，.openspec.yaml文件中就有 schema字段，默认值为spec-driven。可以在源码中，看到spec-driven定义了产出物（artifacts）的目录、文件名、文件格式、生成Prompt等，以及实施阶段（apply）读取的任务文件和Prompt。 这是OpenSpec预定义的schema，我们也可以自定义schema，对他进行扩展。 工作流 如下是OpenSpec默认的工作流，通过schema定义中的requires字段定义依赖关系。 flowchart LR proposal --> specs proposal --> design specs --> tasks design --> tasks tasks --> apply apply --> archive artifacts: - id: proposal generates: proposal.md requires: [] - id: specs generates: specs/**/*.md requires: [proposal] - id: design generates: design.md requires: [proposal] - id: tasks generates: tasks.md requires: [specs, design] apply: requires: [tasks] 这里的设计哲学：dependency is an enabler, not a gate。 也就是说，依赖表示“现在什么是可做的”，而不是“你必须严格按唯一顺序前进”。这和很多传统 spec 流程差异很大：后者把流程建模成 phase，前者把流程建模成 action + dependency。 ...

ing…