對變更進行編輯與迭代
一個變更中的所有工件（artifact）都是你可以隨時編輯的 Markdown 文件。 沒有鎖定的「規劃階段」，沒有審批門檻，也沒有特殊的編輯模式需要進入。想在開始建構後更改提案？打開 proposal.md 並修改它。實施過程中意識到設計有誤？修復 design.md 並繼續進行。這就是全部答案，這是故意的設計如此。
本頁面是針對你腦中出現「等等，我可以回去修改那個嗎？」這一刻的解答。是的。以下是每個常見情況下的做法。
兩種編輯任何內容的方式
你始終擁有這兩種方式：
直接編輯文件。 工件位於
openspec/changes/<name>/下的純 Markdown 文件。在你的編輯器中打開proposal.md、design.md、tasks.md或specs/下的 delta spec 並進行修改。無需其他操作。請 AI 審閱並修訂。 在聊天中，只需說明你想要什麼：「將提案更新為移除快取（caching）的想法並增加一個速率限制（rate-limit）部分」，或者「設計應該使用佇列（queue），而不是輪詢（polling）」。AI 會利用變更的剩餘內容作為上下文來編輯該工件。
請根據當下情況選擇合適的方式。只是措辭上的微調？直接編輯文件。需要實質性的重新思考？讓 AI 在完整的上下文下進行修訂。
「我在開始後，如何更新提案（或規格）？」
直接更新它。保持相同的變更，但經過精煉。
如果你使用的是擴充命令（expanded commands），自然的流程是：編輯工件，然後運行 /opsx:continue 以從新的狀態繼續進行，或者運行 /opsx:apply 以針對更新後的計畫持續實施。如果你使用的是預設的 core 命令，請編輯工件並運行 /opsx:apply；它會讀取當前的文件，因此它將根據工件目前所說的一切來建構。
心智模型：工件是活生生的計畫，而不是一份簽署的合約。AI 始終是從它們目前的內容中工作，所以編輯它們就能引導工作方向。
text
你: 我想更改這個變更中的方法。
你: [編輯 design.md，或告訴 AI:]
將 design.md 更新為使用背景任務（background job）而不是同步呼叫（synchronous call）。
AI: 已更新 design.md。任務清單仍然適用；是否要我繼續實施？
你: /opsx:apply這回答了一個非常常見的問題：沒有一個獨立的「更新提案」命令，因為你並不需要它。文件是真實性的來源（source of truth），手動或透過 AI 編輯它就是更新本身。
「我在實施後，如何回去審查？」
你不必「回去」，因為你從未離開過。工作流程是流暢的：審查、編輯和實施並非你被困住的順序階段。
具體來說，在執行了一些 /opsx:apply 的工作之後：
- 想重新檢視計畫？打開工件並閱讀它們，或者在終端機中運行
openspec show <change>以獲得整合性的視圖。 - 發現需要更改的地方？編輯該工件（或請 AI 進行），然後繼續進行。
- 想進行一項結構化的檢查，確保程式碼與計畫一致？運行
/opsx:verify（擴充命令）。它會報告完整性、正確性和連貫性，而不會阻礙任何事情。請參閱 Workflows: Verify。
沒有一個「審查階段」需要返回，因為審查是你可以在任何時候進行的事情，包括在實施之後。
「我手動編輯了程式碼。這如何與 OpenSpec 保持一致？」
這種情況會不斷發生，而且這是正常的。你在編輯器中微調了某個東西，現在程式碼和工件不一致了。請將它們同步回同一方向：
- 程式碼已正確，規格（spec）過時了。 更新 delta spec（如果相關，也包括 tasks）以描述你實際交付的行為。在歸檔之前，規格應該與現實保持一致，因為歸檔會將規格合併到你的真實性來源中。
- 規格正確，程式碼發生漂移（drift）。 持續建構或修復，直到程式碼與規格匹配。
一個快速發現不匹配的方法是 /opsx:verify：它會讀取你的工件和你的程式碼，並告訴你它們在哪裡分歧。將其輸出視為一個需要完成的待辦事項清單來進行協調，然後在它們一致後再歸檔。
原則是：在歸檔時，你的規格將成為記錄的真相。因此，在歸檔之前，請讓規格誠實地反映程式碼所做的事情。手動編輯是受歡迎的；只是不要讓它悄悄地使規格失去同步。
對於不滿意的提案進行精煉
如果一個生成的提案不夠好，你有三個好的做法：
- 原地迭代（Iterate in place）。 告訴 AI 有什麼地方不好（例如：「範圍太廣了，移除管理員功能」）並讓它修訂。這是成本最低且通常正確的做法。
- 先探索，再重新提案（Explore first, then re-propose）。 如果問題在於想法本身不夠清晰，請退回到
/opsx:explore，仔細思考，然後讓一個更清晰的提案從中產生。請參閱 Explore First。 - 全新開始（Start fresh）。 如果意圖發生了根本性的變化，一個新的變更可能比修補舊的更有意義。
最後那一步驟有自己的決策指南，稍後會說明。
何時更新 vs. 開始新變更
簡而言：當它是同一項工作但有所精煉時，就進行更新；當意圖發生根本性變化或範圍擴大到不同的工作時，則開始新的變更。
- 相同的目標，更好的方法？更新。
- 縮小範圍（先交付 MVP，之後再做更多）？更新，然後歸檔，接著為第二階段創建一個新變更。
- 問題本身改變了（「新增深色模式」變成「建構一套完整的佈景主題系統」）？新的變更。
Workflows: When to Update vs Start Fresh 中有完整的流程圖和範例，而 OPSX: When to Update vs. Start Fresh 提供了更深入的闡述。
關於任務（Tasks）的備註
tasks.md 是一個活生生的檢查清單，而不是一個固定的計畫。在你實施過程中，你可以新增發現的任務、移除不必要的任務，或重新排序它們。AI 會在 /opsx:apply 期間完成項目並打勾，如果你之後回來，它會從第一個未被勾選的任務處恢復。中途編輯清單是預期的。
下一步該去哪裡？
- Workflows - 模式範例，以及更新 vs. 新增的決策指南
- Explore First - 當一個想法需要重新思考時應退回的地方
- Commands -
/opsx:continue、/opsx:apply和/opsx:verify的詳細說明 - Concepts: Artifacts - 每個工件的用途