審閱變更
OpenSpec 的核心承諾是，你與你的 AI 在撰寫任何程式碼之前，先就「要建置什麼」達成共識。這份共識只有在你真的閱讀 AI 起草的內容時才有意義。本頁說明的就是你花這兩分鐘要做的事——要打開哪些檔案、依什麼順序、要關注什麼重點。其中的邏輯很簡單：在單段計畫中發現錯誤方向幾乎毫無成本，但要在 300 行程式碼裡發現同一個錯誤就完全不是這麼回事。審閱就是你兌現這份打賭收益的環節。
你進行審閱的兩個時機
只有兩個時機：
/opsx:propose ──► 審閱計畫 ──► /opsx:apply ──► 審閱程式碼 ──► /opsx:archive
（寫程式碼前） （/opsx:verify）- 執行
/opsx:propose（或/opsx:ff）之後、執行/opsx:apply之前——在計畫還只是文字時閱讀它。 - 建置完成後，執行
/opsx:verify——確認程式碼確實做到了計畫所說的事。
第一次審閱能節省最多成本，卻也是最多人跳過的環節。本頁絕大部分內容都會圍繞這個環節展開。
依此順序閱讀
一項變更是 openspec/changes/<name>/ 下的純 Markdown 檔案資料夾。請依以下順序閱讀檔案，這樣一發現問題就能盡早停止：
openspec/changes/add-dark-mode/
├── proposal.md 1. 意圖與範圍 ← 若此處有誤，直接停止閱讀
├── specs/…/spec.md 2. 需求規範 ← 審閱的核心
├── design.md （僅適用於較大規模的變更）— 技術方案
└── tasks.md 3. 工作計畫你不需要逐行閱讀，只需要回答三個問題，每個檔案對應一個問題。
proposal.md：這是否是你想解決的正確問題？
首先打開 proposal.md，它記錄了變更的「為什麼」與「做什麼」——也就是意圖、範圍，以及用一兩段話說明的處理方式。
良好的狀態應符合： 單一明確的意圖、你認得的範圍，以及說明現在執行這項變更是值得的原因。
警示徵兆：
- 它解決的問題與你提出的問題略有不同。
- 範圍已經膨脹——你只要求做主題切換，但提案裡卻連帶包含了驗證相關的改動，「順便處理一下」。
- 內容過於模糊。「改善設定頁」不是明確的範圍；「新增尊重系統偏好設定的深色模式切換開關」才是。
需要回答的問題： 這份提案是否符合我實際提出的需求，有沒有偷偷塞進額外內容？ 如果答案是否定的，就停止閱讀後續內容——先修正提案（詳見 反饋修改成本很低）。
spec 增量檔：完成的定義是否正確？
這是審閱的核心。specs/ 目錄下的增量規範說明了這項變更上線時會成立的事實——包含需求本身，以及能證明需求符合的場景：
markdown
## ADDED Requirements
### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.
#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode良好的需求應符合： 一個明確的 SHALL/MUST 陳述句，可以直接交給測試人員執行，且至少有一個 GIVEN/WHEN/THEN 場景能實際驗證該陳述句。
警示徵兆：
- 需求過於模糊。「系統 MUST 執行速度快」無法被實作或測試，怎樣才算快？
- 需求沒有對應的場景，或是場景無法驗證其所屬的需求。
- 最寶貴的發現往往是遺漏的內容。 AI 會如實寫下你說過的內容，你的工作是發現你遺漏沒說的部分。如果你最在意的是系統偏好設定的場景，但沒有任何場景提到這一點，那這次審閱就已經值回票價。
閱讀增量檔時問自己：如果系統完全只做到這些、一點都不多，我會滿意嗎？ 此時還沒有涉及程式碼，因此修改成本仍然很低。
tasks.md：工作計畫是否合理？
最後打開 tasks.md，它是 AI 執行實作時會遵循的檢查清單。
良好的狀態應符合： 步驟有序、每一項都能對應到某個需求、沒有來歷不明的內容。
警示徵兆：
- 任務沒有對應的需求（這項任務是從哪來的？）。
- 有一個龐大的「實作功能」任務，隱藏了所有實際的決策細節。
- 任務涉及你剛批准範圍之外的內容。
你在這裡不需要評估工時或過度微觀管理——你只需要確認這份計畫與你已經接受的需求一致。
反饋修改成本很低
如果上述三個問題有任何一個的答案是否定的，直接說出來。流程沒有階段限制，也沒有內容被鎖定——你可以修正後繼續推進。有兩種修正方式，和 編輯變更 中說明的一樣：
- 自己編輯檔案。 檔案是純 Markdown 格式；你可以修改範圍說明、收緊需求、刪除任務。
- 告訴 AI 哪裡有問題，讓它來修改：「拿掉驗證相關的改動——超出範圍了」、「新增使用者已經選過主題時的場景」、「把任務 3 拆成資料庫 schema 和介面兩部分」。
修改後重新閱讀你改動的部分，不斷調整草案，直到它是一份你願意簽名背書的計畫。來回討論的過程，就是產品真正成型的過程。
程式碼寫完後：驗證
工作建置完成後，/opsx:verify 就是你第二次審閱的環節。它會重新閱讀所有產出物與程式碼，並從三個維度回報不符合的地方：
| 維度 | 檢查項目 |
|---|---|
| 完整性 | 所有任務都已完成、所有需求都已實作、所有場景都有對應覆蓋 |
| 正確性 | 實作內容符合規範的意圖、邊界情況已處理 |
| 一致性 | 設計決策確實反映在程式碼中 |
You: /opsx:verify
AI: Verifying add-dark-mode...
COMPLETENESS
✓ All 8 tasks in tasks.md are checked
✓ All requirements in specs have corresponding code
⚠ Scenario "Respects the OS preference on first load" has no test coverage它會將問題標記為 CRITICAL（嚴重）、WARNING（警告）或 SUGGESTION（建議），且不會阻擋封存流程——它只會列出缺口，最終由你決定是否要繼續封存。這就是「AI 有沒有寫程式碼」和「AI 有沒有建置出我們約定的內容」之間的差異。
/opsx:verify 屬於進階設定檔的功能。如果你沒有這個指令，可以用 openspec config profile 開啟（之後執行 openspec update），或是直接自己重新閱讀變更內容與差異比對結果。
依規模調整審閱力度
不是每項變更都需要完整的審閱流程。只修改一個檔案的拼字錯誤，花二十秒掃過一遍就足夠。但涉及驗證、付款、或是無法復原的資料的變更，就值得你仔細回答上面所有問題。重點從來不是走形式——而是把你的注意力放在出錯成本高的地方，出錯成本低的地方就快速掃過即可。
兩分鐘檢查清單
- [ ] 提案的意圖符合我提出的需求。
- [ ] 沒有多餘內容偷偷塞進範圍裡。
- [ ] 每一項需求都具體到可以被測試。
- [ ] 每一項需求都有對應的場景能實際驗證它。
- [ ] 我最在意的那個場景有被涵蓋。
- [ ] 任務都能對應到需求；沒有來歷不明或超出範圍的任務。
- [ ] 如果 AI 完全只做到這些、一點都不多，我會覺得放心。
如果七個項目都通過，就可以放心執行 /opsx:apply。如果任何一項沒過，這不是挫折——這兩分鐘已經發揮作用了。