全国30米土地利用遥感数据生产全流程解析：从影像预处理到精度验证
2026/8/30 20:59:51
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-g@fission-ai/openspec@latestcdyour-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 可以先理解成一张“功能依赖地图”。在一个小项目里，你可能只有一个页面、一个接口、一个数据库表，所有需求写在一个文件里也能看懂；但项目一大，功能之间就会开始互相依赖。比如前端页面依赖 API，API 依赖认证和数据库，订单依赖支付，支付又依赖用户、商品、库存和回调。这个时候如果还是把所有需求写成一个长列表，AI 很容易不知道哪个模块应该先稳定、哪个接口可以依赖、哪个内部实现不能被下游直接引用。Spec DAG 的作用，就是把这些依赖关系画成有方向、没有循环的图。
一个通俗比喻是盖房子：地基、承重墙、水电、装修、验收之间有明显顺序。你不能先装修再铺水电，也不能让墙依赖地基、地基又依赖墙。Spec DAG 里的每个节点就是一个规格，例如 AUTH、DATABASE、API、FRONTEND；每条箭头就是一个依赖，例如 API 依赖 AUTH 和 DATABASE，FRONTEND 依赖 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 依赖 DATABASE，FRONTEND 依赖 API，QA 依赖所有需要验收的能力。这样 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，才会更贴合你的项目，而不是变成额外负担。