审查变更
OpenSpec 的核心承诺是，你和你的 AI 在编写任何代码之前就商定好要构建的内容。只有当你真正阅读 AI 起草的内容时，这份约定才有意义。本页内容就是关于你花这两分钟要做的事——要打开哪些文件、按什么顺序打开、以及要关注什么。
这个逻辑很简单：在一段话的计划里发现走错方向几乎零成本，但要在 300 行代码里发现同样的错误就没这么容易了。审查就是你兑现这份收益的环节。
两个审查时机
恰好有两个：
/opsx:propose ──► 审查计划 ──► /opsx:apply ──► 审查代码 ──► /opsx:archive
（编写代码前） （/opsx:verify）- 在
/opsx:propose（或/opsx:ff）之后、/opsx:apply之前——在计划还只是文字的时候阅读它。 - 构建完成后，使用
/opsx:verify——检查代码是否真的按照计划实现了功能。
第一次审查能帮你省最多麻烦，但也是大多数人会跳过的一步。本页内容大部分篇幅都会围绕这一步展开。
按此顺序阅读
变更是 openspec/changes/<name>/ 下的纯 Markdown 文件夹。按以下顺序阅读文件，这样一旦发现问题可以尽早停止：
openspec/changes/add-dark-mode/
├── proposal.md 1. 意图与范围 ← 如果这里有问题，直接停在这里
├── specs/…/spec.md 2. 需求说明 ← 审查的核心
├── design.md （仅适用于较大变更）— 技术方案
└── tasks.md 3. 工作计划你不需要逐行阅读所有内容，只需要回答三个问题，每个文件对应一个。
提案：这是正确的问题吗？
首先打开 proposal.md。它用一两段话说明了「为什么做」和「做什么」——包括意图、范围和实现思路。
合格的表现： 只有一个明确的意图、你认可的范围，以及说明现在做这件事的必要性。
危险信号：
- 它解决的问题和你提出的问题略有不同。
- 范围扩大了——你只要求加个主题切换功能，提案里却顺便把认证模块也改了。
- 表述模糊。「优化设置页」不是明确的范围，「添加一个跟随系统偏好的深色模式切换开关」才是。
需要回答的问题： 这份提案是否符合我实际提出的需求，有没有偷偷加入额外内容？ 如果答案是否定的，直接停下来——不要继续往下读，先修改提案（参见提出异议成本很低）。
规格增量：「完成」的定义正确吗？
这是审查的核心。specs/ 下的增量规格说明了变更上线后会成立的内容——包括需求本身，以及能证明需求达成的场景：
markdown
## ADDED Requirements
### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.
#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode合格的需求应具备以下特征： 一条清晰的 SHALL/MUST 声明，可直接交给测试人员执行；同时至少有一个 GIVEN/WHEN/THEN 场景能实际验证这条声明。
危险信号：
- 需求表述模糊。 比如「系统 MUST 速度快」既无法实现也无法测试，什么叫快？
- 需求没有对应的场景，或场景无法验证其所属的需求。
- 最值得捕捉的问题：遗漏的内容。 AI 会如实记录你说过的内容，你的工作是注意到你忘记说的内容。如果你最在意系统偏好场景，但没有任何一个场景提到它，那这次审查就已经值回票价了。
阅读增量规格时问自己：如果系统完全、且只按照这里描述的内容运行，我会满意吗？ 这里还没有涉及代码，所以修改成本很低。
任务：工作计划是否合理？
最后打开 tasks.md。这是 AI 会逐项执行的实现清单。
合格的表现： 步骤有序，每一项都能追溯到对应需求，没有模糊不清的内容。
危险信号：
- 没有对应需求的任务（不知道是从哪来的）。
- 一个名为「实现功能」的巨型任务，把所有实际决策都藏了起来。
- 涉及你刚批准的范围之外内容的任务。
你在这里不需要估算工期或进行微观管控——你只需要确认计划和你已经认可的需求一致。
提出异议成本很低
如果三个问题中有任何一个的答案是否定的，直接提出来。这里没有阶段限制，也没有内容被锁定——你修改完继续推进就行。有两种修改方式，和编辑变更里提到的一样：
- 自己编辑文件。 文件是纯 Markdown 格式；你可以修改范围描述、收紧需求表述、删除任务。
- 告诉 AI 哪里有问题，让它来修改：比如「删掉认证相关的改动——超出范围了」「加一个用户已经选过主题的场景」「把任务 3 拆成数据 schema 和 UI 两部分」。
然后重新阅读你修改过的部分，反复调整直到你愿意为这份计划背书。这种来回沟通的过程，本身就是产品在正常推进。
代码编写完成后：验证
工作构建完成后，/opsx:verify 就是你的第二次审查。它会重新阅读所有产物和代码，从三个维度报告不一致的地方：
| 维度 | 检查内容 |
|---|---|
| 完整性 | 所有任务都已完成、所有需求都已实现、所有场景都有覆盖 |
| 正确性 | 实现符合规格的意图，边界情况已处理 |
| 一致性 | 设计决策真正落地到了代码中 |
你：/opsx:verify
AI：正在验证 add-dark-mode...
完整性
✓ tasks.md 中的 8 个任务全部已完成
✓ specs 中的所有需求都有对应代码实现
⚠ 场景「首次加载时遵循系统偏好」没有测试覆盖它会将问题标记为 CRITICAL（严重）、WARNING（警告）或 SUGGESTION（建议），并且不会阻止归档——它只会列出缺口，由你来决定是否归档。这就是「AI 写了代码」和「AI 按我们约定的内容构建了功能」的区别。
/opsx:verify 在扩展配置文件中。如果你没有这个命令，可以通过 openspec config profile 开启（然后执行 openspec update），或者直接自己重新阅读变更内容和代码差异。
合理把控审查力度
不是所有变更都需要走完全部审查流程。只改一个文件的拼写错误，花 20 秒扫一眼就够了。涉及认证、支付或无法恢复的数据的变更，才值得你逐条核对上面所有问题。审查从来不是为了走流程——而是要把注意力花在出错成本高的地方，出错成本低的地方快速扫过即可。
两分钟检查清单
- [ ] 提案的意图和我提出的需求一致。
- [ ] 范围里没有偷偷加入额外内容。
- [ ] 所有需求都足够具体，可以用于测试。
- [ ] 每个需求都有对应的场景能实际验证它。
- [ ] 我最关心的场景已经被覆盖。
- [ ] 任务和需求一一对应，没有模糊或超出范围的内容。
- [ ] 如果 AI 完全按照这份计划执行、不做任何额外改动，我会感到放心。
如果以上七项都通过，就可以放心执行 /opsx:apply。如果有任何一项不通过，这也不是挫折——这两分钟已经发挥了它的作用。