OpenSpec 入门：把 AI 编程需求变成可审阅的变更材料
OpenSpec 架构：材料依赖图如何决定下一步
沿着模式定义、图计算、文件状态和指令策略，理解准备就绪的含义。
OpenSpec 架构：材料依赖图如何决定下一步知识学习CN编辑简报更新 2026-09-23
你将学会
- 依赖关系包含分叉与汇合
- 图计算与文件检测各有职责
- 状态继续交给下一步策略
开始前需要
- 基本 Git 与 Node 知识
- 可独立试验的样例仓库
用合成模式解释阻塞原因，把规划状态与实现证据放在不同列中。
先看结论
- 规格和设计共享提案依赖。
- 优先顺序不是依赖边。
- 编辑范围元数据不是系统隔离。
依赖关系包含分叉与汇合
默认模式中，提案没有前置依赖，规格与设计都依赖提案，任务则同时依赖规格和设计。虽然界面常显示线性顺序，实际依赖图包含一个分叉和汇合。
模式中的声明顺序可以优先推荐规格，却不意味着设计必须等待规格完成。分析自定义流程时，应区分推荐顺序与真正的前置依赖边。
图计算与文件检测各有职责
ArtifactGraph 保存材料标识、依赖和声明位置，计算构建顺序、就绪项及阻塞依赖。状态模块读取变更目录，再把输出检测交给 artifactOutputExists。
这些职责不等于阅读文档并判断内容正确。就绪只说明依赖被记录为完成，不能证明需求准确、场景充分，或应用中已经有对应测试。
状态继续交给下一步策略
resolveNextStep 选择第一个就绪材料并构造指引命令；规划全部完成后，它构造查看实施进度的 apply 指引命令。选定的 store 标识也会进入命令。
buildActionContext 输出项目根目录及允许编辑位置等流程元数据。它有助于解释范围，但所检查的函数没有建立操作系统沙箱或强制文件权限。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
画出模式中的分叉和汇合。
- 2
分开图状态与文档质量。
- 3
追踪就绪状态对应的指令。
可复制示例
text
proposal -> specs -> tasks
proposal -> design -> tasks
状态 -> 就绪材料 -> 下一步指引常见问题
设计必须等规格完成吗？
默认模式中两者只依赖提案；任务才依赖两者。声明顺序优先推荐规格。
就绪代表正确吗？
它表示依赖就绪，不证明内容正确或测试通过。
资料来源
- OpenSpec / schemas/spec-driven/schema.yaml来源核查 2026-09-23
- OpenSpec / src/core/artifact-graph/graph.ts来源核查 2026-09-23
- OpenSpec / src/core/artifact-graph/state.ts来源核查 2026-09-23
- OpenSpec / src/core/change-status-policy.ts来源核查 2026-09-23