Spectra 其實在我剛開始使用 OpenSpec 時就已經推出，我也看過龍哥的介紹。不過，考量到 Spectra 本身也是從 OpenSpec 延伸而來，我想先熟悉 OpenSpec 的資料結構與 workflow，理解這套流程怎麼運作，再來使用 Spectra。這樣比較能分辨哪些是 OpenSpec 原本的設計，哪些是 Spectra 做的調整，也比較能理解這些調整背後的原因。
等實際跑過幾輪 OpenSpec，對原本的流程比較熟悉後，我才開始把 Spectra 導入自己的專案。這時第一個碰到的問題是：專案裡已經有 OpenSpec 的規格與 changes，換成 Spectra 後，這些文件還能繼續用嗎？初始化時，又會多出哪些東西？
這篇使用哪個版本？ 下面的操作、設定與 Skills 都以 Spectra 2.3.1 為準。寫鐵人賽期間，剛好又推出了 3.0.0，所以遇到新版已經不同的地方，我會再用引用區塊補充。
和前面介紹的 Spec Kit、OpenSpec 一樣，Spectra 也有自己的 CLI。可以在專案中執行 spectra init，再透過 --tools 指定要搭配的 AI 工具。例如，使用 Claude Code 時可以這樣執行：
spectra init --tools claude
初始化完成後，檔案結構大致如下圖：
.claude/skills/ 會多出 discuss、propose、apply、ingest 與 archive 等 Skills；.spectra.yaml 則是 Spectra 自己的設定檔，可以設定產生 artifacts 時使用的語言，以及是否啟用 TDD、parallel_tasks 等功能。
圖中用虛線標出的 openspec/LANGUAGE.md 是選用檔案，不是 spectra init 一定會建立的內容。它用來記錄專案的共用詞彙，讓 discuss 討論需求時有一致的用語可以參照。
初始化後，根目錄的 CLAUDE.md 也會多出一段由 Spectra 管理的整體流程導覽，告訴 AI 每個 Skill 適合在什麼情況下使用，並列出主要的 workflow。後續介紹 Spectra 的運作方式時，我們再來看這份導覽如何與 Skills、CLI 及各步驟的檢查配合。
如果使用 Codex： 對應的 Skills 會改放到
.agents/skills/，同一類 workflow 提示則會注入AGENTS.md。Spectra 會依照初始化時選擇的 AI Agent，新增對應的 Skills 與專案指引檔。
至於 openspec/，Spectra 仍然沿用 OpenSpec 的資料格式。正式 specs、進行中的 changes 與 archive 都不需要重新換一套結構，config.yaml 的 context 與 rules 也可以繼續使用。
現在有什麼不同？ Spectra 3.0.0 將新專案的預設規格目錄改成
docs/spectra/。所以，現在初始化專案時，會看到和前面目錄圖不同的路徑；圖中保留的是當時的目錄結構。
這裡先統一一下名稱： 不同 AI Agent 呼叫 Skill 的寫法不太一樣，後面會直接統一使用 discuss、propose、apply、ingest 與 archive 這些流程名稱。
知道 Spectra 初始化後多了哪些內容，接下來我們就把這些流程串起來看看吧！
Spectra 平常會走的主要流程是 discuss? → propose → apply → archive，其中 discuss 可以視需求跳過。如果實作途中需求或方向改變，則可以透過 ingest 更新進行中的 change，再繼續 apply。
除了這條主要路徑，tasks 完成後也可以先執行 verify，再進入 archive。把這些流程各自的用途整理在一起，就會像下面這張表：
| 流程 | 這個流程在做什麼？ |
|---|---|
| discuss（可選） | 在建立 change 前和 AI 探索想法、釐清需求與整理方向；需求已經很清楚時可以跳過。 |
| propose | 建立 change，並一次準備 proposal、specs、design 與 tasks。 |
| apply | 讀取 artifacts 與 tasks，開始修改 code，並更新工作進度。 |
| ingest（需要時） | apply 途中需求或方向改變時，把新的討論或 plan 更新回進行中的 change，再繼續實作。 |
| verify（可選） | tasks 完成後，把實作與 artifacts 放在一起核對；需要時可以在 archive 前執行。 |
| archive | 確認 artifacts、tasks 與規格同步狀態，再保存完成的 change。 |
前面介紹 OpenSpec 時，已經簡單說明過 apply，也在【Day - 9】介紹了 verify 與 archive。Spectra 延續了這些流程的基本用途，也加入 ingest，讓實作途中改變的需求可以更新回 change，再繼續 apply。把主要路徑和這些可選的流程畫在一起，就會像下面這張圖：
OpenSpec 原本可以單獨執行的 sync 去哪裡了？【Day - 7】介紹 OpenSpec 時，sync 可以先把 delta specs 合併回正式 specs，再讓 change 繼續留在進行中的目錄。Spectra 沒有把這個動作保留成平常可以單獨呼叫的 CLI command，而是把同步規格的選擇收進 archive。進入 archive 後，archive Skill 會先比較 delta specs 和正式 specs，再問我要不要同步；選擇同步時，這一步會由 AI 在 archive 流程裡處理。因此，圖上只畫出 archive，沒有另外放一個 sync。
看過流程後，我最有感的其實是：Spectra 把我原本搭配 OpenSpec 使用的幾個步驟，整理進了同一套 workflow。
【Day - 7】提過，我在使用 OpenSpec 時，會先用 Superpowers 的 brainstorming Skill 和 AI 一題一題討論需求與可能的作法，再進入 OpenSpec 的流程。而 Spectra 的 discuss 和 brainstorming 雖然不是同一個 Skill，不過放在我已經習慣的 workflow 裡，其實是同樣的原理，兩者都是在建立 change 以前，先讓我和 AI 把想法、限制與方向談妥和釐清。
實作前可以怎麼討論？ 後面談到 discuss 的設計時，我們會再回來看這些討論流程怎麼準備背景、安排提問與整理結論。
等方向比較明確後，接著就是 propose。當時的 OpenSpec 要先用 new 建立 change，再用 ff 一次準備好實作前需要的 artifacts；Spectra 的 propose 用起來就很接近把這兩個步驟接在一起，不用先 new，再決定要 continue 還是 ff，而是一次把 proposal、specs、design 與 tasks 準備好。
經歷過 Spec Kit 一步一步的流程後，我使用 OpenSpec 時幾乎都直接選擇 ff。龍哥也在部落格裡說過，他沒耐心一直 continue 下去XD。看到這句我只想說：我也是！所以看到 Spectra 的流程時，我幾乎不用重新適應：方向談好後直接 propose，接著 apply，做完再 archive。少了先 new 再 ff 的兩個步驟，整體跑下來根本完全符合我要的節奏。
除了流程幾乎不用重新適應，圖形化介面也讓我少做了很多事情。我要找某一份規格或確認 tasks 進度時，不需要再開著檔案總管或 VS Code，在一整片 Markdown 文件中慢慢尋找。
這個差別在 tasks 上尤其明顯。以前 AI 留下一項需要我手動完成的工作時，我做完後還得先找到這次 change 的資料夾，打開 tasks.md，定位到那一項，再把 [ ] 改成 [x] 才算完成。到了 Spectra，這些 tasks 可以直接從畫面勾選，少掉找檔案、找項目和手動輸入 x 的過程，操作方便很多。
後來和團隊討論時，我還可以直接開著 Spectra 一起看規格與 tasks。即使是非工程背景的成員，也能跟著畫面確認現在討論的是哪一份規格，而他們也終於不用再和我一起面對那些密密麻麻的 Markdown 語法了！不然直接打開 VS Code 給他們看，他們可能都會誤以為我要教他們寫 code 呢XD。
圖形化介面讓規格更容易閱讀與操作。不過，建立新的 change 時，還有一個之前碰過的問題：AI 怎麼知道這次需求應該沿用哪一份既有規格？
【Day - 9】提過，如果 AI 沒有沿用既有 capability 的名稱，archive 後可能把同一項功能分成兩份正式規格。
因此，開始建立 artifacts 以前，Spectra 的 propose 會先掃描 openspec/specs/，找出和這次需求可能有關的 specs，再讀取其中的 Purpose。這樣 AI 在決定要沿用哪一個既有 capability，還是建立新的規格以前，就能先知道目前已經有哪些能力。而找到的結果只會作為判斷時的參考，不會停下來等我確認。
.openspec.yaml 也會多留下資料找到這次要使用的 capabilities 後，propose 就會建立 change。這時候 .openspec.yaml 才會出現。Spectra 沿用 OpenSpec 原本的 schema 與 created，另外加入建立者，以及這次透過哪個 AI Agent 建立：
schema: spec-driven
created: 2026-08-27
created_by: 作者
created_with: claude
created_with 只有在建立 change 時有指定 AI Agent 才會出現。這些資料不會改變 artifacts 的內容，主要是替這份 change 留下建立時的基本資訊。
.openspec.yaml 多了幾項建立資訊，那麼規格本身的 spec.md 呢？我們可以從文件結構、delta 操作、規格語言與範例寫法，對照 OpenSpec 1.0 和 Spectra 2.3.1，看看哪些沿用、哪些有所調整：
| 格式或規則 | OpenSpec 1.0 | Spectra 2.3.1 |
|---|---|---|
| 正式 spec 結構 | 使用 Purpose、Requirements、Requirement 與 Scenario |
沿用相同結構 |
| delta spec 操作 | 使用 ADDED、MODIFIED、REMOVED 與 RENAMED |
沿用相同操作 |
| requirement 與 scenario | requirement 使用 SHALL／MUST；scenario 維持四層標題並使用 WHEN／THEN |
沿用相同規則 |
| 規格語言 | 沒有固定只能使用英文 | 不論專案設定的語言為何，spec 一律使用英文 |
| 具體範例 | 主要透過 scenario 描述情境 | 可以再加入選用的 ##### Example，用 GIVEN／WHEN／THEN 或表格補上實際資料 |
因此，從 OpenSpec 接到 Spectra 時，原本的 requirement、scenario 與四種 delta 操作都不需要重新學。Spectra 調整的是規格語言與範例寫法；遇到資料轉換、排序、狀態變化或不容易看出邊界的情境時，可以再用 Example 把輸入與結果寫得更具體。
規格格式確定後，propose 還會把實作需要的 design 與 tasks 一起準備好，再交給 apply 依照規劃實作。不過，真的開始做以後，我還是可能想到新的需求。這時候，已經寫好的規劃文件要怎麼跟著調整？
【Day - 9】提過，當時的 OpenSpec 可以直接修改 artifacts，但如果實作途中追加需求，或做完後又想到一個和原需求很接近的功能，我還是得自己判斷 proposal、specs、design 與 tasks 哪些要一起調整，再一份一份請 AI 更新。說真的，這真的非常麻煩，當時我差點就為了這件事自己手刻一份 Skill，還好後來遇到了 Spectra 的 ingest！
剛開始使用時，我遇到中途追加需求的情況還不算多。不過，隨著系統持續演進，功能做出來後，我也很常開始天馬行空：「這裡是不是還可以順便再加個功能（完全慣老闆心態XD）？」如果是完全不同的新功能，另外開一個 change 就好了；麻煩的是，新想法有時候會影響目前 change 已經談好的內容，甚至和正在實作的方向發生衝突。
這時，我會先和 AI 把新增的內容與影響談清楚，再透過 ingest 更新進行中的 change，接著繼續 apply；如果討論後發現比較適合另開 change，也可以改走新的規劃。這類狀況變多後，ingest 就慢慢成為我很常使用的流程之一。
透過 ingest 更新 artifacts 後，就可以繼續 apply。等 tasks 全部完成、需要的核對與修正也處理好，這份 change 就可以準備 archive。除了更新正式 specs、保存 change，Spectra 還會留下哪些資料呢？
change 進入 archive 時，Spectra 會在 .openspec.yaml 補上 archived_by 與 archived_at，記錄由誰在什麼時候完成歸檔。
新 capability 的 Purpose 產生時機也沒有另外調整，仍然沿用【Day - 9】看過的作法：delta spec 不需要先提供，archive 建立正式 spec 時，才會放入一段待整理的內容。
現在有什麼不同？ Spectra 3.0.0 的 propose 流程改成要求先寫好新 capability 的 Purpose，讓 archive 建立正式 spec 時可以沿用這段用途說明，不用再留下 TBD 等之後補齊。
Spectra 也會保存 snapshot（封存前備份），留下正式 specs 更新前的內容。之後需要回頭查看時，就能找回規格被更新以前的樣子。
不過，snapshot 保存的是整份 spec 更新前的內容。如果我們只想知道某一條 requirement 最近是從哪個 change 來的，就需要另一種線索。
@trace 讓 requirement 找得到來源 changeSpectra 在 archive 時，還會替新增或修改的 requirement 加上一段 @trace。它是一段放在 Markdown 裡的註解，不會變成 requirement 的正文，內容大概會像這樣：
<!-- @trace
source: add-sync
updated: 2026-08-29
code:
- src/sync.js
tests:
- src/sync.test.js
-->
source 是最近加入或修改這條 requirement 的 change，updated 是這次 archive 的日期；code 與 tests 則是 archive 當下辨識到的相關檔案。想回頭查看當時為什麼這樣改時，可以先沿著 source 找到 archived change，再查看裡面的 proposal、delta specs、design 與 tasks。
code 與 tests 是根據歸檔當下的 Git 變更整理出的線索，適合拿來找相關檔案，但不是每條 requirement 對應哪些程式與測試的精準清單。
從初始化、主要流程，到 change 歸檔後留下的紀錄，Spectra 怎麼接續 OpenSpec、又多提供了哪些功能，我們已經看過一輪了。不過，知道這些功能的用途後，實際操作時，AI 從哪裡知道接下來該做什麼？文件寫好後有哪些檢查，歸檔時又怎麼更新正式 specs 呢？
下一篇，我們就從初始化時多出的 workflow 導覽開始，看看 Spectra 怎麼安排這些步驟吧！
iThome鐵人賽
看影片追技術