软件工程 / 架构设计方法论知识图谱 / 分组目录 / 案例层 / OpenSpec 规约驱动解析
X · P1 · active

OpenSpec 规约驱动解析

Spec-Driven Development Toolchain Comparison
P1进阶verified案例X · 跨域/其他质量属性技术债GC-CASE · 案例层

§1摘要与结论

TL;DR · 一句话结论

对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。

别名：OpenSpec、Superpower、规约驱动开发　|　英文：Spec-Driven Development Toolchain Comparison　|　类型：案例 / tool-analysis

§2局部关系图

OpenSpec 规约驱动解析 的 1-2 跳邻域关系图依据推导（derives_from）：规格说明落实可验证与可追溯特性前置依赖（prerequisite）：获取到的需要需经规格化形成信息项前置依赖（prerequisite）：需求分类是规格说明的结构化前提前置依赖（prerequisite）：规格化后按属性与优先级管理需求依据推导（derives_from）：准入时机的质量门槛与便利性是权衡的体现依据推导（derives_from）：自动化方式按可信度与频率取舍依据推导（derives_from）：演化中的一致性取舍依据权衡不可消除依据推导（derives_from）：度量与反馈是对取舍效果的检验依赖关联（dependency）：增量演化治理依赖度量反馈闭环依赖关联（dependency）：触发时机的落地依赖自动化方式选择组合（combination）：准入时机与自动化方式需协同设计案例印证（case_instance）：印证：以增量同步与契约替代全量重建的一致性治理案例印证（case_instance）：印证：以增量同步与契约替换全量重建案例印证（case_instance）：印证：可机器解析的需求规约契约案例印证（case_instance）：印证：Delta Spec 增量叠加与归档合并案例印证（case_instance）：印证：跳过规约与显式激活的门控时机实现（implements）：追溯与影响分析落地需求规格说明实现（implements）：需求属性与追踪关系在平台中落地实现（implements）：以规格质量特性识别需求技术债组合（combination）：追溯链路为需求债度量提供覆盖缺口案例印证（case_instance）：印证：requires 工件 DAG 建立需求到实现可追溯链OpenSpec 规约驱…OpenSpec 规约驱动解析（CAS-X-14）需求规格说明需求规格说明（MTH-F-04）准入与触发时机选择准入与触发时机选择（MTH-O-02）增量演化与一致性治理增量演化与一致性治理（MTH-O-10）需求可追溯性与影响分析需求可追溯性与影响分析（TEC-F-01）权衡的不可消除性权衡的不可消除性（ESS-O-03）度量与反馈闭环度量与反馈闭环（MTH-O-11）插件 DAG RC5→R…插件 DAG RC5→RC7 升级（CAS-X-06）需求获取需求获取（MTH-F-02）自动化方式选择自动化方式选择（MTH-O-07）需求技术债识别与度量需求技术债识别与度量（TEC-F-02）插件 DAG 两次级联升…插件 DAG 两次级联升级（CAS-X-07）需求属性与优先级需求属性与优先级（MTH-F-06）需求可追溯性与可验证性需求可追溯性与可验证性（ESS-F-03）功能与非功能需求分类功能与非功能需求分类（MTH-F-05）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 4 个直接邻接、外环 10 个二跳节点，共 15 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

把需求、设计、任务、实现从口头约定变成可机器校验的工件 DAG，是规约驱动开发的核心。工件之间用 requires 声明依赖，而非强制阶段顺序，于是流程既支持增量推进（每次补一个工件），也支持一键全生成；依赖 DAG 同时让中断可恢复、每一步可验证。规约本身以 SHALL/MUST 与严格标记语法写成可解析契约，使「未实现」与「已实现」没有灰度地带，验收不再依赖人的解读。Delta Spec 机制进一步让变更以增量形式（新增、修改、删除、重命名）叠加，归档时才合并回主规约，从而保留并发变更与回滚能力。这套设计的本质，是把软件过程从依赖记忆与默契，转为依赖可校验的显式约束，让流程可在无原作者在场时被接手。当规约成为系统的一部分，它就不再是写完即弃的过程文档，而是随代码一起演进、可被校验和被归档复用的工程资产。它也回应了一个常见痛点：流程知识常随人员流失，而规约化把知识固化进了仓库。

§4机制 · 如何运作

OpenSpec 抽象四个概念：Change（变更目录）、Artifact（受 schema 定义的工件）、Schema（声明 requires 依赖与生成指令）、Capability（随归档增量更新的持久规约）。规约用固定层级的场景标记与强约束动词保证可测试性，纯重构可显式声明跳过规约阶段以避免无意义的形式负担。Superpower 抽象五个概念：Workflow、Bundle、Memory、Control Point、Learning Candidate；其核心工作流只编排子工作流而不含实现逻辑，激活模式要求显式召唤、拒绝自动运行，跨会话记忆把重要决策、已知故障与可复用教训持续回写。两者组合，覆盖从探索到归档再到记忆沉淀的完整链条。这种把「过程」物化为「可检查对象」的做法，使协作不再依赖参与者是否记得约定，而依赖约定本身是否可被工具执行与验证。这种「显式声明」的风格贯穿两者：任何例外的跳过都必须写明理由，避免规则被悄悄绕过。

§5工程 · 怎么落地

两者搭配成五阶段交付链：探索阶段产出非正式设计稿；锁定阶段生成提案、规约、设计与任务；执行阶段产出实现计划、代码与测试；归档阶段把增量规约合并回主规约；记忆回写阶段沉淀当前状态、决策记录、会话日志与教训清单。每个阶段都有明确的物理产物与门控，使整个流程可被工具检查、可被中断恢复、可被他人接手。工件 DAG 而非固定瀑布，是这套流程既能严格又能灵活的关键：严格在于依赖不可跳过，灵活在于生成时机与路径可选。这条链路的意义在于角色可替换：任何人按同一套产物与门控接手，都能还原出上一阶段的状态，而不必依赖口头交接或会议记录。门控与产物清单本身也被纳入版本管理，使流程的变更同样可追溯、可回滚。

§6权衡卡

收益 · 正确姿势

更根本地，规约驱动把价值押在「需求稳定到值得形式化」上——探索性、快速试错的任务里，写全规约的投入可能远超收益。

代价 · 风险

严格标记与强约束动词带来可校验性，也带来写作负担与学习成本；团队不熟练时，规约阶段会从护栏变成瓶颈，产出大段正确但无人细读的规约。

显式激活提升安全（AI 不背着人做事），代价是每次都要召唤，降低顺滑度。

原文要点
  • Delta 机制避免了主规约的直接冲突，却要求参与者准确理解各操作的语义，误用会让归档丢失已有场景。
  • 工具只保证形式一致，不保证规约内容正确，也不保证实现与规约真正对齐，这三者的落地仍靠人。
  • 因此是否采用它，取决于需求的可预期程度与团队的流程成熟度；对高度不确定的探索期，更轻量的记录方式往往比完整规约更有效。
  • 若团队尚无稳定需求与协作节奏，先落地最小可用的规约骨架，再逐步加严，通常比一次到位更可行。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7案例带

CAS-X-01 · 2 跳派生：当前节点 → MTH-F-04 → TEC-F-02

去中心化聊天架构逆向

对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。

CAS-X-04 · 2 跳派生：当前节点 → MTH-O-02 → ESS-O-03

网申 v2 深度重构

一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。

CAS-X-06 · 经 MTH-O-10

插件 DAG RC5→RC7 升级

一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。

CAS-X-07 · 经 MTH-O-10

插件 DAG 两次级联升级

在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。

CAS-X-16 · 2 跳派生：当前节点 → MTH-O-10 → MTH-O-11

控制理论⊗Agent 设计

将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。

CAS-X-17 · 2 跳派生：当前节点 → MTH-O-02 → MTH-O-07

技术知识中枢交付法

从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。

CAS-X-18 · 2 跳派生：当前节点 → MTH-O-02 → MTH-O-07

AI Agent 架构 DAG 复盘

对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。

§8信源与核验

核验状态True（verified）
置信度medium
复核日期2026-09-10
生命周期active
规范信源LOC-033
勘误
常见误解：规约驱动开发只是把文档换成 Markdown，属于流程仪式
核验结论：其价值在于工件 requires DAG 与 SHALL/MUST 机器可校验契约，配合 Delta Spec 增量叠加与归档合并，使流程可工具化、可回滚；但只保证形式一致，不保证内容正确　[LOC-033]

§9原始关系清单

展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
关系方向对端节点说明
案例印证→ MTH-F-04需求规格说明
E-981		印证：可机器解析的需求规约契约
案例印证→ MTH-O-02准入与触发时机选择
E-983		印证：跳过规约与显式激活的门控时机
案例印证→ MTH-O-10增量演化与一致性治理
E-982		印证：Delta Spec 增量叠加与归档合并
案例印证→ TEC-F-01需求可追溯性与影响分析
E-18		印证：requires 工件 DAG 建立需求到实现可追溯链