編輯與迭代變更
變更中的每個產物都只是可隨時編輯的 Markdown 檔案。 沒有鎖死的「規劃階段」、沒有審批關卡、也不需要進入任何特殊編輯模式。開始建置後想修改提案？打開 proposal.md 直接改就行。實作中途發現設計有問題？修正 design.md 後繼續推進就好。這就是全部答案，而且是刻意設計成這樣的。
本頁正是為你產生「等等，我能不能回頭改那個？」的念頭而準備的。答案是肯定的。以下針對每種常見情境說明操作方法。
編輯任何內容的兩種方式
你隨時都可以使用這兩種方式：
- 直接編輯檔案：所有產物都是儲存在
openspec/changes/<name>/下的純 Markdown 檔案。打開proposal.md、design.md、tasks.md，或是specs/下的差異規格檔，在編輯器中修改即可，不需要任何其他操作。 - 請你的 AI 協助修改：在對話中直接說出你的需求即可，例如「把提案中的快取構思拿掉，新增速率限制章節」，或是「設計應該用佇列，不要用輪詢」。AI 會以變更中的其他內容為上下文，自動為你編輯對應產物。
根據當下情境選擇合適的方式即可：只是微調措辭？直接編輯檔案就好。需要大幅度調整思路？讓 AI 帶著完整上下文協助修改更合適。
「開始實作後該如何更新提案（或規格）？」
直接修改就好，屬於同一項變更的優化調整。
如果你使用的是擴充指令集，自然流程是：編輯產物後，執行 /opsx:continue 從新狀態繼續推進，或是執行 /opsx:apply 依據更新後的計畫持續實作。如果你使用的是預設的 core 指令集，編輯產物後執行 /opsx:apply 即可；它會讀取當前檔案內容，因此會依據產物當前的內容推進工作。
核心概念：產物是動態的計畫，不是簽署完的合約。AI 始終以產物當前的內容為依據工作，因此修改產物就能夠引導工作方向。
text
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（擴充指令）。它會回報完整性、正確性與一致性，且不會阻擋任何後續操作。詳見 Workflows: Verify。
沒有需要回歸的「審查階段」，因為審查是任何時候都能進行的操作，實作完成後也不例外。
「我手動修改了程式碼，該如何讓它與 OpenSpec 保持一致？」
這種情況非常常見，完全沒有問題。你在編輯器中調整了某些內容，現在程式碼與產物出現了不一致。你可以根據實際情況，選擇以下任一方式讓兩者重新同步：
- 程式碼已經是正確的，規格已經過時：更新差異規格（若相關的話也更新任務清單），描述你實際上線的行為。在封存變更前，規格必須與實際情況一致，因為封存操作會將規格合併到你的可信來源中。
- 規格是正確的，程式碼偏離了規格：持續建置或修正，直到程式碼與規格一致。
快速找出不一致的方式是執行 /opsx:verify：它會讀取你的產物與程式碼，回報兩者的差異之處。你可以把它的輸出當成對齊工作的待辦清單，等兩者一致後再執行封存。
核心原則：封存時，你的規格會成為正式記錄的真相。因此在封存前，請確保規格如實反映了程式碼的實際行為。手動編輯是被歡迎的，只是不要讓它悄悄導致規格與實際情況脫節。
優化你不滿意的提案
如果生成的提案不符合預期，你可以採取以下三種合適的做法：
- 原地迭代：告訴 AI 哪裡不對（例如「範圍太廣，拿掉管理員功能」），讓它直接修改。這是最省成本的方式，通常也最有效。
- 先探索，再重新提案：如果問題出在構思本身不夠清晰，可以先回到
/opsx:explore重新梳理思路，再從中產出更明確的提案。詳見 Explore First。 - 重新開始：如果需求的核心已經發生了變化，建立新的變更往往比修改舊的變更更清晰。
最後一種做法有對應的決策指南，見下一節。
何時更新變更、何時建立新變更
簡短版本：如果是同一項工作的優化調整就更新變更；如果需求核心發生了變化、或是範圍膨脹成了完全不同的工作，就建立新變更。
- 目標相同，只是方法更優？更新變更。
- 範圍縮小（現在先上線最小可行產品，後續功能再另外處理）？更新變更、封存後，為第二階段建立新的變更。
- 問題本身發生了變化（從「新增深色模式」變成「打造完整的主题系統」）？建立新變更。
完整的流程圖與實作範例見 Workflows: When to Update vs Start Fresh，更深入的說明見 OPSX: When to Update vs. Start Fresh。
關於任務的說明
tasks.md 是動態更新的任務清單，不是凍結的計畫。實作過程中，你可以新增發現的任務、刪除確認不需要的任務，或是調整任務順序。AI 會在執行 /opsx:apply 時逐項勾選完成的任務，如果你後續回來繼續工作，它會從第一個未勾選的任務開始推進。在執行過程中編輯任務清單是預期內的行為。
下一步閱讀
- Workflows - 工作模式，以及更新與新建變更的決策指南
- Reviewing a Change - 建置前對計畫進行兩分鐘快速檢視
- Explore First - 當構思需要重新梳理時可回退的探索流程
- Commands -
/opsx:continue、/opsx:apply與/opsx:verify的詳細說明 - Concepts: Artifacts - 各產物的用途說明