编辑和迭代变更

变更中的每项产物都是 Markdown 文件，你可以随时编辑。 没有锁定的“规划阶段”，没有审批关卡，也无需进入特殊的编辑模式。开始实现后想修改提案？打开 proposal.md 并修改。实现到一半才发现设计有误？修正 design.md 并继续。这就是全部答案，也是刻意如此设计的。

如果你曾想过“等等，我还能回头修改吗？”，本页就是为你准备的。答案是可以。下面介绍几种常见情形的处理方式。

编辑任何内容的两种方式

你始终可以任选以下方式：

1. 直接编辑文件。 产物都是 openspec/changes/<name>/ 下的纯 Markdown 文件。在编辑器中打开 proposal.md、design.md、tasks.md 或 specs/ 下的差异规格说明并进行修改，无需其他操作。

2. 让 AI 帮你修改。 在聊天中直接说明需求：“更新提案，去掉缓存方案并添加限流章节”，或“设计应该使用队列，而不是轮询”。AI 会参考变更的其余内容并为你修改产物。

选择适合当前情况的方式。只是微调措辞？直接编辑文件。需要实质性重新考虑方案？让 AI 结合完整上下文修改。

“开始之后，如何更新提案（或规格说明）？”

直接更新即可。这仍是同一项变更，只是经过了完善。

如果使用扩展命令，常见流程是编辑产物，然后运行 /opsx:continue 以基于新状态继续，或运行 /opsx:apply 按更新后的计划继续实现。如果使用默认的 core 命令，则编辑产物后运行 /opsx:apply 即可；它会读取当前文件，因此会依据最新内容进行实现。

思维模型是：产物是实时计划，而非签署后不得修改的合同。AI 始终基于产物的当前内容工作，因此编辑它们就能引导工作方向。

You: I want to change the approach in this change.

You: [edit design.md, or tell the AI:]
     Update design.md to use a background job instead of a synchronous call.

AI:  Updated design.md. The task list still fits; want me to continue applying?

You: /opsx:apply

这也回答了一个常见问题：没有单独的“更新提案”命令，因为你并不需要它。文件本身就是唯一真实依据；无论你手动编辑还是让 AI 修改，都是在更新提案。

“实现之后，如何回到审查？”

无需“回去”，因为你从未离开。工作流是灵活的：审查、编辑和实现不是会把你困住的顺序阶段。

具体来说，完成部分 /opsx:apply 工作后：

• 想重新检查计划？打开并阅读产物，或在终端中运行 openspec show <change> 查看汇总内容。
• 发现需要修改的地方？编辑产物（或让 AI 修改），然后继续。
• 想有条理地检查代码是否符合计划？运行 /opsx:verify（扩展命令）。它会报告完整性、正确性和一致性，但不会阻止你继续。参阅工作流：验证工作。

不存在需要返回的“审查阶段”，因为你随时都可以进行审查，包括实现之后。

“我手动编辑了代码，如何与 OpenSpec 保持一致？”

这种情况经常发生，没有问题。你在编辑器中调整了代码，现在代码与产物内容不一致。根据实际情况，选择一个方向重新同步：

• 代码现在正确，规格说明已过时。 更新差异规格说明（必要时也更新任务），使其准确描述已经交付的行为。归档前规格说明必须与实际相符，因为归档会把它并入唯一真实依据。
• 规格说明正确，代码偏离了计划。 继续构建或修复，直到代码符合规格说明。

使用 /opsx:verify 可以快速发现不一致：它会读取产物和代码，并指出两者的差异。把输出当作协调清单，待两者一致后再归档。

原则是：归档时，规格说明会成为正式记录。因此，归档前应确保它如实描述代码的行为。欢迎手动编辑，但不要让这些修改悄悄导致规格说明与实际脱节。

完善不满意的提案

如果生成的提案不合适，可以采取以下三种方式：

• 直接迭代。 告诉 AI 哪些内容不合适（“范围太宽了，去掉管理功能”）并让它修改。这成本最低，通常也最合适。
• 先探索，再重新提案。 如果问题在于想法本身还不清晰，先退回 /opsx:explore 梳理思路，让它据此生成更明确的提案。参阅先探索。
• 重新开始。 如果意图已经彻底改变，新建一项变更可能比修补旧变更更清晰。

最后一种做法的决策指南如下。

何时更新现有变更，何时新建变更

简而言之：同一项工作只是进一步完善时就更新；意图彻底改变或范围膨胀成另一项工作时就新建。

• 目标相同，只是方案更好？更新。
• 缩小范围（先发布 MVP，以后再做更多功能）？更新并归档，然后为第二阶段新建变更。
• 问题本身变了（“添加深色模式”变成“构建完整主题系统”）？新建变更。

完整流程图和示例见工作流：何时更新，何时重新开始；深入讨论见OPSX：何时更新，何时重新开始。

关于任务的说明

tasks.md 是持续更新的清单，而非冻结的计划。实现过程中，你可以添加新发现的任务、删除不再需要的任务，或调整任务顺序。AI 会在 /opsx:apply 期间完成任务后勾选；如果你稍后再继续，它会从第一个未勾选的任务开始。在处理中编辑清单是预期行为。

接下来读什么

• 工作流——常见模式，以及更新与新建的决策指南
• 审查变更——实现之前用两分钟审查计划
• 先探索——当想法需要重新梳理时，从这里退一步
• 命令——详解 /opsx:continue、/opsx:apply 和 /opsx:verify
• 概念：产物——了解每项产物的用途