編輯和迭代變更

變更中的每項產物都是 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
• 概念：產物——瞭解每項產物的用途