对变更进行编辑和迭代
一个变更中的所有工件（artifact）都是你可以随时编辑的 Markdown 文件。 没有锁定式的“规划阶段”，没有审批门槛，也没有特殊的编辑模式需要进入。想在开始构建后修改提案？打开 proposal.md 并修改它。实现过程中发现设计有误？修复 design.md 然后继续进行。这就是全部答案，也是其设计的初衷。
本页面是针对你产生“等等，我能回去修改那个吗？”这种想法的时刻。答案是肯定的。以下是针对每种常见情况的操作方法。
两种编辑任何内容的方式
你始终拥有这两种方式：
直接编辑文件。 工件位于
openspec/changes/<name>/下，它们都是纯粹的 Markdown 文件。在编辑器中打开proposal.md、design.md、tasks.md或specs/下的 delta spec 进行修改。无需其他操作。请你的 AI 协助修订。 在聊天中，只需说明你想要什么：“将提案更新为移除缓存想法并添加一个速率限制（rate-limit）部分，”或者“设计应该使用队列而不是轮询。”AI 会利用整个变更作为上下文来为你编辑该工件。
根据当时的需要选择最合适的方式。只是措辞上的微调？编辑文件。实质性的重新思考？让 AI 在完整的上下文中进行修订。
“在开始后，我如何更新提案（或规范）？”
直接更新它。保持相同的变更，但有所完善。
如果你使用的是扩展命令（expanded commands），自然流程是：编辑工件，然后运行 /opsx:continue 以承接新的状态，或者运行 /opsx:apply 以继续根据更新后的计划进行实现。如果你使用的是默认的 core 命令，请编辑工件并运行 /opsx:apply；它会读取当前文件，因此会基于工件现在所描述的内容进行构建。
心智模型：工件是活生生的计划，而不是一份已签署的合同。AI 总是从这些工件的当前内容中工作，因此编辑它们就是在引导工作方向。
text
你: 我想修改这个变更中的方法。
你: [编辑 design.md，或告诉 AI:]
将 design.md 更新为使用后台任务（background job）而不是同步调用。
AI: 已更新 design.md。任务列表仍然适用；是否需要我继续应用？
你: /opsx:apply这回答了一个非常常见的问题：没有单独的“更新提案”命令，因为你不需要它。文件是真相来源（source of truth），而编辑它（无论是手动还是通过 AI）就是更新过程。
“在实现之后，我如何回去审查？”
你不需要“回去”，因为你从未离开过。工作流程是流动的：审查、编辑和实现不是你被困住的顺序阶段。
具体来说，在执行了一些 /opsx:apply 工作后：
- 想重新审视计划？打开工件并阅读它们，或者在终端中运行
openspec show <change>以获得整合视图。 - 发现需要修改的内容？编辑该工件（或请 AI 进行），然后继续进行。
- 是否想要一个结构化的检查来确保代码与计划一致？运行
/opsx:verify（扩展命令）。它会报告完整性、正确性和连贯性，而不会阻塞任何事情。参见 工作流程：验证你的工作。
不存在需要返回的“审查阶段”，因为审查是你可以在任何时间进行的，包括在实现之后。
“我手动编辑了代码。这如何与 OpenSpec 协调？”
这种情况会不断发生，这是正常的。你在编辑器中微调了一些内容，现在代码和工件之间出现了分歧。将它们同步回一致状态，无论朝哪个方向是正确的：
- 代码现在是正确的，规范（spec）已过时。 更新 delta spec（如果相关，也更新 tasks）来描述你实际交付的行为。在归档之前，规范应该与现实相符，因为归档会将规范合并到你的真相来源中。
- 规范是正确的，代码发生了漂移（drift）。 继续构建或修复，直到代码与规范一致。
一个快速发现不匹配的方法是使用 /opsx:verify：它会读取你的工件和你的代码，并告诉你它们在哪里分歧。将它的输出视为一个需要完成的待办事项列表进行协调，然后当它们达成一致时再归档。
原则是：在归档时，你的规范将成为记录的真相。因此，在你归档之前，请让规范诚实地反映代码的功能。手动编辑是受欢迎的；只是不要让它悄悄地使规范脱节（desync）。
如何完善一个你不满意的提案
如果生成的提案不尽如人意，你有三种好的做法：
- 原地迭代（Iterate in place）。 告诉 AI 哪里不对（“范围太广了，移除管理员功能”）让它进行修订。这是成本最低、通常最对的做法。
- 先探索，再重新提案（Explore first, then re-propose）。 如果问题在于想法本身不够清晰，则退回到
/opsx:explore，深思熟虑后，让一个更清晰的提案诞生。参见 先探索。 - 从零开始（Start fresh）。 如果意图发生了根本性的变化，一个新的变更可能比修补旧的方案更清晰。
最后一个做法有自己的决策指南，敬请查阅。
何时更新 vs. 启动新的变更
简而言之：工作内容相同但有所完善时进行更新；当意图发生根本性改变或范围爆炸到不同的工作时，则启动新的变更。
- 目标相同，方法更好？更新。
- 缩小范围（先交付 MVP，后期再做更多）？更新，然后归档，再为第二阶段启动一个新的变更。
- 问题本身发生了变化（“添加深色模式”变成了“构建一套完整的主题系统”）？新的变更。
工作流程：何时更新 vs. 从零开始 中有完整的流程图和案例示例，而 OPSX: 何时更新 vs. 从零开始 中有更深入的阐述。
关于任务（Tasks）的一点说明
tasks.md 是一个活着的清单，而不是一个固定的计划。在实现过程中，你可以添加新发现的任务，移除不必要的任务，或重新排序它们。AI 在 /opsx:apply 期间完成任务时会勾选项目，如果你稍后回来，它将从第一个未勾选的任务处恢复。中途编辑清单是预料之中的事情。