从 Vibe Coding 到 SDD：企业级 AI 编程范式的演进与实践

Thu, 16 Apr 2026 10:00:00 +0800

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

OpenSpec 架构：把 AI 协作从“对话驱动”变成“状态驱动”

Sun, 19 Apr 2026 20:00:00 +0800

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。

openspec增强