0. 简介OpenSpec、GitHub Spec Kit、Ossature 这几类工具和方法本质上都在解决同一个问题AI 已经很会写代码但它并不天然知道“你真正想要什么”。如果需求只写在聊天窗口里AI 这一次可能理解对了下一次换一个上下文、换一个模型、换一个人接手就可能又要重新解释一遍。更麻烦的是很多项目失败不是因为代码完全不能跑而是因为它跑出来的行为和最初想要的目标差了一点点例如少了一个边界条件、改坏了一个旧接口、忘记了失败回滚或者把一个临时方案当成长期架构。用更通俗的话说OpenSpec 像是给每一次 AI 编程任务准备的一份“施工单”先写清楚为什么要做、要改什么、不改什么、验收标准是什么再让 AI 按步骤动手。Spec DAG 则像是给整个系统画的一张“施工依赖图”先知道哪些地基要先打好哪些墙要依赖地基哪些装修不能早于水电。前者解决的是单次变更不要跑偏后者解决的是多个功能之间不要互相踩踏。你现在更需要先理解的是不要急着把两者都做得很复杂而是先用 OpenSpec 把每次需求讲清楚再在项目变大时用 Spec DAG 管住模块依赖。本文的客观边界也需要先说清楚OpenSpec 是 Fission-AI 维护的轻量级 spec-driven framework重点是围绕 proposal、specs、design、tasks、archive 等工件协作Spec DAG 更像一种规格依赖图思想在 Ossature 文档中有比较清晰的工程表达即 SMD 文件通过depends字段形成 directed acyclic graph。两者可以放在同一套工作流里使用但不应被混为一个官方功能。你可以把 OpenSpec 理解成“每次改动怎么写清楚”把 Spec DAG 理解成“很多改动之间的依赖怎么理清楚”。1. OpenSpec 是什么一个轻量的规格工件工作流1.1 OpenSpec 的定位不是项目管理平台而是变更意图管理层OpenSpec 可以先不要想得太玄它不是 Jira也不是 Notion也不是完整的产品管理系统。它更像是在代码仓库旁边放了一套“变更说明模板”让你每次找 AI 写代码之前先把这次要做的事情讲清楚。比如你要加一个“运行时切换地图”功能直接让 AI 改代码它可能马上去找服务、改参数、加回调但 OpenSpec 会引导你先写为什么要做这个功能、触发方式是什么、切换失败怎么办、切换后哪些状态要清空、哪些旧行为不能被破坏。这样 AI 开始写代码时不是只拿到一句口头命令而是拿到一份更稳定的任务说明。npminstall-gfission-ai/openspeclatestcdyour-project openspec init对个人开发者来说OpenSpec 的直接价值是减少“我刚才到底想让 AI 怎么改”的记忆负担。对团队来说它的价值是减少口口相传的隐性上下文。你可以把 proposal 看成“为什么要做”把 specs 看成“做出来应该是什么行为”把 design 看成“准备怎么做”把 tasks 看成“具体先做哪一步、后做哪一步”。这些东西放进仓库以后后续 review、返工、复盘、换人接手都会轻松很多。它不保证 AI 永远写对但它能让 AI 错得更容易被发现也更容易被纠正。1.2 OpenSpec 的工件链路proposal、specs、design、tasks一个很实用的理解方式是OpenSpec 不是让你“多写文档”而是让 AI 不要跳过思考。proposal 负责回答“这次改动的动机是什么”避免 AI 在没有目标的情况下乱扩展specs 负责回答“用户或系统能观察到什么变化”避免需求只停留在抽象形容词里design 负责回答“代码层面准备怎么落地”避免实现方案和现有架构冲突tasks 负责回答“先后顺序是什么”避免一次性修改太多文件最后出错了也不知道哪里错。这个链路越清楚AI 越像一个按图施工的执行者而不是一个凭感觉发挥的临时助手。1.3 OpenSpec 的工作方式actions而不是僵硬阶段OpenSpec 的一个重要特点是 “actions, not phases”也就是它更像一组你可以随时调用的动作而不是一条不能回头的瀑布流程。你可以先/opsx:explore探索问题也可以直接/opsx:propose创建变更需求清楚时可以快速走到/opsx:apply需求不清楚时可以先停下来修改 proposal 或 specs。这个设计对已有项目比较友好因为现实开发很少是“需求完全清楚、设计完全确定、代码一次写完”。更常见的是你边看代码边发现新约束边实现边发现原先设计需要收缩OpenSpec 的作用就是让这些变化仍然回到工件里而不是散落在聊天记录中。如果你现在想马上开始用我建议从最小闭环开始不要一上来追求完整体系。第一次只需要选一个中等复杂度功能用/opsx:propose让 AI 先生成变更说明和任务再由你审一遍把模糊点改清楚然后再/opsx:apply。实现完成后不要急着结束要让 AI 对照 specs 和 tasks 做一次核对确认哪些任务完成、哪些场景没覆盖、哪些设计和实现不一致。这个动作会让你很快感受到 OpenSpec 的价值它不是让开发变慢而是把返工提前暴露出来。2. Spec DAG 是什么把规格拆成可依赖的图2.1 Spec DAG 的基本概念规格节点和依赖边Spec DAG 可以先理解成一张“功能依赖地图”。在一个小项目里你可能只有一个页面、一个接口、一个数据库表所有需求写在一个文件里也能看懂但项目一大功能之间就会开始互相依赖。比如前端页面依赖 APIAPI 依赖认证和数据库订单依赖支付支付又依赖用户、商品、库存和回调。这个时候如果还是把所有需求写成一个长列表AI 很容易不知道哪个模块应该先稳定、哪个接口可以依赖、哪个内部实现不能被下游直接引用。Spec DAG 的作用就是把这些依赖关系画成有方向、没有循环的图。一个通俗比喻是盖房子地基、承重墙、水电、装修、验收之间有明显顺序。你不能先装修再铺水电也不能让墙依赖地基、地基又依赖墙。Spec DAG 里的每个节点就是一个规格例如 AUTH、DATABASE、API、FRONTEND每条箭头就是一个依赖例如 API 依赖 AUTH 和 DATABASEFRONTEND 依赖 API。这样做的意义不只是画图好看而是让 AI 在处理 FRONTEND 时知道它应该依赖 API 的公开接口而不是随便去改数据库内部结构处理 API 时也知道 AUTH 和 DATABASE 是上游能力不应该把它们当成可以随意重写的临时组件。2.2 Spec DAG 与普通任务列表的区别普通任务列表解决的是“今天要做什么”Spec DAG 解决的是“这些事情之间谁依赖谁”。这两个问题不一样。任务列表可以写成1. 建表2. 写接口3. 写页面4. 写测试。这样的线性列表很适合短期执行但它表达不了系统长期结构。Spec DAG 会问得更深一点建表属于 DATABASE 规格接口属于 API 规格页面属于 FRONTEND 规格测试可能属于 QA 或 ACCEPTANCE 规格API 依赖 DATABASEFRONTEND 依赖 APIQA 依赖所有需要验收的能力。这样 AI 在执行任务时就能知道当前任务处在整个系统的哪一层。这对 AI 编程尤其重要因为 AI 最怕两种上下文一种是太少它不知道约束另一种是太多它看了很多无关文件后抓不住重点。Spec DAG 让你可以更精确地告诉 AI“当前只做 API 规格你需要读取 AUTH 和 DATABASE 的公共接口但不要修改它们的内部实现。”这句话比“看一下整个项目然后实现接口”可靠得多。它也能帮助你在多人或多代理并行时分工例如一个代理做 AUTH一个代理做 DATABASE等它们公共接口稳定后再让另一个代理做 API。2.3 Spec DAG 的关键约束无环、接口边界和增量影响Spec DAG 里最重要的三个词是无环、接口、增量。无环表示依赖不能互相绕圈否则就没有清楚的先后顺序接口表示下游只应该依赖上游承诺暴露的东西而不是依赖上游内部实现增量表示当上游内部改了但接口没变时下游不一定需要重做。这个思想和传统工程里的编译依赖很像如果一个库内部优化了算法但函数签名和行为契约没变调用方通常不需要重写如果函数签名变了调用方就必须重新适配。3. OpenSpec、Spec DAG 与 Spec Kit三者如何客观比较3.1 OpenSpec 与 Spec DAG 的关系一个管变更一个管依赖OpenSpec 和 Spec DAG 最容易被混淆是因为它们都在讲“规格”。但它们关注的层级不同。OpenSpec 更关心一次变更怎么从想法走到实现比如“我要增加一个登录超时配置”这次变更应该有 proposal、specs、design、tasks最后 archive。Spec DAG 更关心多个规格之间的关系比如登录、会话、权限、API、前端之间谁依赖谁哪个公共接口变化会影响下游。你可以把 OpenSpec 看成一张张“施工单”把 Spec DAG 看成整个项目的“施工总图”。施工单让每次任务不跑偏施工总图让多个任务不互相撞车。在实际使用上比较合理的组合方式是先用 OpenSpec 管住单次变更再逐步把重要能力抽成 Spec DAG。比如你现在做机器人项目先不要急着为所有模块画一张巨大的依赖图。你可以先从一个真实功能开始例如“地图切换”用 OpenSpec 写清楚变更意图和验收场景等你发现地图切换会牵涉 localization、map storage、relocalizer、web UI、safety state再把这些能力整理成几个规格节点。这样 Spec DAG 是从真实问题长出来的而不是为了画图而画图。3.2 与 GitHub Spec Kit 的差异完整方法论与轻量落地GitHub Spec Kit 更像一套完整的规格驱动开发方法论它会强调 constitution、specify、plan、tasks、implement 等步骤适合从项目原则、用户故事、技术计划到任务执行形成比较完整的链路。OpenSpec 的定位更轻尤其适合你已经有一个代码库只是希望 AI 每次改动更可控、更可审查。两者并不是谁一定比谁好而是适用场景不同。如果你现在最缺的是“团队规范、项目原则、完整需求模板”Spec Kit 更适合先建立纪律如果你现在最缺的是“每次让 AI 改代码都容易跑偏”OpenSpec 更适合马上落地。对你当前的需求来说我会更建议先从 OpenSpec 开始而不是一上来追求完整 Spec Kit 或完整 Spec DAG。原因很简单你现在最想提升的是 AI 辅助开发效率和能力而效率提升的第一步不是建立庞大体系而是让每一次 AI 任务都更清楚、更可检查。等你用 OpenSpec 跑过三五个真实变更后你会自然看出哪些模块反复被依赖、哪些接口经常变化、哪些任务需要拆成上游和下游。到那个时候再引入 Spec DAG才会更贴合你的项目而不是变成额外负担。4. 如何落地用 OpenSpec 与 Spec DAG 提升开发效率…详情请参照古月居