OpenSpec + OMC 雙劍合璧：讓 AI 編程從各自為戰到規劃即執行
整理版優先睇
OpenSpec 同 OMC 協同，令 AI 編程嘅規劃同執行打通曬
呢篇文章由術哥寫，佢係專注 AI 編程、Agent Skills、MCP 嘅技術實踐者。文章想解決嘅問題係：用 AI 編程助手時，規劃同執行各顧各，需求傳達唔清、規範執行唔到位。整體結論係：OpenSpec 同 OMC 兩個工具配合用，可以由規劃行到落地，形成真正閉環。
OpenSpec 喺代碼同 AI 之間加咗一層輕量規範，令雙方先對齊目標；OMC 就透過 29 個專業 Agent 同四大互鎖系統，將執行過程編排得井井有條。OpenSpec 管「做咩」，OMC 管「點做」，兩者唔係競爭，而係唔同抽象層嘅互補。
協同使用嘅關鍵係：OpenSpec 嘅 Skills 檔案會自動俾 OMC 嘅 Agent 發現，tasks.md 可以直接俾 executor agent 逐條執行，仲有雙層驗證（規範驗證加工程驗證）確保結果靠譜。成個流程濃縮為：OpenSpec 負責將做咩講清楚，OMC 負責將執行落實到位。
- OpenSpec 負責定義「做咩」，OMC 負責管理「點做」，兩者協同先形成完整閉環。
- OpenSpec 用 specs/changes 雙軌機制同 DAG 依賴引擎，將變更規範化，仲有 Delta 規範做增量變更。
- OMC 用四大互鎖系統（Hooks、Skills、Agents、State）將執行自動化，支援 29 個專業 Agent 同 Team 模式。
- OpenSpec 支援 25+ 種 AI 工具，跨平台通用；OMC 目前只支援 Claude Code，但可透過 tmux 調度 Codex 同 Gemini。
- 建議個人開發者先用 OpenSpec 理清需求，小團隊加 OMC autopilot 模式，大團隊用 Team 模式配合雙層驗證。
OpenSpec：規範先行，對齊目標
OpenSpec 嘅核心諗法好簡單：喺 AI 編碼助手同代碼之間插入一個輕量規範層。寫代碼之前，先將做咩講清楚，形成一份人同 AI 都明嘅共識文檔。
呢份規範唔係另一個需求管理工具，而係解決 AI 收到模糊需求後過度發揮或者理解偏差嘅問題。
佢嘅目錄結構分兩條軌道：specs/ 管系統當前行為嘅規範，係 Source of Truth；changes/ 管每次變更嘅全生命週期，從 proposal 到 design 再到 tasks。
DAG 依賴引擎追蹤工件狀態：proposal 冇依賴可以最先建立，specs 同 design 依賴 proposal，tasks 最重要等前兩者完成。
唔需要額外狀態服務，文件本身就係狀態。
Delta 規範係增量變更嘅核心創新，用 ADDED、MODIFIED、REMOVED、RENAMED 四種格式描述差異。OPSX 工作流將日常操作封裝成一條命令：/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive。
/opsx:propose add-dark-mode
/opsx:apply
/opsx:sync
/opsx:archive/opsx:explore 可以喺正式規劃前幫你理清思路，/opsx:verify 從完整性、正確性、一致性三個維度檢查實現。
OMC：多智能體編排，落實執行
如果 OpenSpec 係建築圖紙，OMC 就係施工隊。佢嘅定位係 Claude Code 嘅多智能體編排系統，透過 Hooks、Skills、Agents、State 四大互鎖系統將複雜開發任務拆成多個專業 Agent 協同工作。
Hooks 系統攔截 11 個生命週期事件，例如 UserPromptSubmit 用來檢測魔法關鍵詞。
Skills 系統有 38 個技能，分三層組合：Guarantee Layer（可選，例如 ralph「不完成不停止」）、Enhancement Layer（例如 ultrawork 並行）、Execution Layer（default、orchestrate、planner）。
- 1 Agents 系統有 29 個專業 Agent，分佈喺 Build/Analysis、Review、Domain、Coordination 四條泳道。
- 2 每個 Agent 默認綁定模型級別：haiku 做探索，opus 做架構設計同審查，sonnet 做日常編碼。
- 3 State 系統用 .omc/ 目錄嘅 notepad、project-memory.json、state/ 實現跨會話持久化，解決上下文壓縮信息丟失嘅問題。
Notepad 係抗壓縮備忘板，通過 MCP 工具讀寫，喺 PreCompact 事件保存關鍵信息，壓縮後自動重新注入。
Team 模式分五階段：team-plan → team-prd → team-exec → team-verify → team-fix（循環），同 OpenSpec 嘅 propose→apply→verify 異曲同工。
魔法關鍵詞例如 autopilot、ralph、ultrawork、team，可以透過 Hooks 自動觸發對應 Skills。
OMC v4.4.0+ 仲引入 tmux CLI 工作者，跨終端分派任務，例如 /omc-teams 2:codex "security review"。
協同機制：當建築圖紙遇上施工隊
兩者最直接嘅連接點係 Skills→Agent 鏈路。OpenSpec init 會喺 .claude/skills/openspec-*/ 生成 Skill 文件，OMC 會自動發現並加載，唔使手動複製。
tasks.md 嘅標準 checkbox 列表可以直接俾 OMC executor agent 逐條執行，verifier agent 驗證完成狀態。
雙層校驗係協同使用嘅最大價值：OpenSpec 嘅 /opsx:verify 確保你做啱嘅事（Do the right things），OMC 嘅 BUILD/TEST/LINT/ARCHITECT 確保你將事做啱（Do things right）。
- OpenSpec 用文件系統追蹤工件狀態，簡單直接但粒度有限。
- OMC 用 .omc/state/ 追蹤運行時進度，支援 notepad 同 project-memory，粒度更細。
- 兩個系統疊加，宏觀進度睇 OpenSpec 嘅工件完成度，微觀進度睇 OMC 嘅運行時狀態。
實戰演示同經驗總結
假設要為一個 Node.js 項目加認證功能。先用 OpenSpec 規劃：npm install -g @fission-ai/openspec@latest，openspec init --tools claude，然後 /opsx:propose add-auth 生成所有規劃工件。
- [ ] 1.1 創建 User 模型和數據庫遷移
- [ ] 1.2 實現密碼哈希工具函數
- [ ] 1.3 創建認證中間件
- [ ] 1.4 實現註冊接口
- [ ] 1.5 實現登錄接口
- [ ] 1.6 實現 token 刷新接口
- [ ] 1.7 編寫單元測試然後用 OMC 執行：ralph: 按照 openspec/changes/add-auth/tasks.md 逐條實現。OMC 會自動編排 explore、architect、executor、test-engineer、code-reviewer 等 Agent。
ralph 模式嘅關鍵係不完成不停止，驗證唔通過會自動修復循環。
執行完先開 OpenSpec 嘅規範驗證 /opsx:verify，再開 OMC 嘅工程驗證（BUILD/TEST/LINT/ARCHITECT）。兩層綠燈後，/opsx:sync 合併 Delta 規範，/opsx:archive 歸檔。
團隊規模建議：個人開發者用 OpenSpec 足夠；2-5 人小團隊用 OpenSpec + OMC autopilot；5 人以上用 Team 模式配合雙層驗證。
🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃 第 121 篇，AI 編程最佳實戰「2026」系列第 37 篇
大家好，歡迎嚟到 術哥無界 | ShugeX ｜ 運維有術。
我是術哥，一個專注於 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫嘅技術實踐者同開源佈道者！
Talk is cheap, let's explore。無界探索，有術而行。
圖 1：OpenSpec 規劃層 + OMC 執行層雙軌協作全景
你喺用 AI 編程助手做項目嘅時候，可能踩過呢啲坑：
同 AI 傾咗半日需求，佢轉頭就唔記得，重新解釋一次又一次 規範文檔寫咗一大堆，AI 寫出嚟嘅代碼完全唔跟規範行 任務拆得好清楚，但係冇自動化嘅手段追蹤完成度同質量
呢啲問題嘅根源係同一個：規劃同執行之間冇形成閉環。 你話俾 AI 做乜嘢係一回事，AI 真正跟規範去執行係另一回事。
OpenSpec 同 OMC（Oh-My-ClaudeCode）分別喺呢兩個環節發力。OpenSpec 喺代碼同 AI 之間加咗一層輕量規範，等雙方先就做什麼達成一致；OMC 就透過 29 個專業 Agent 同四大互鎖系統，將怎麼做嘅執行過程編排得有條有理。
說明：本文內容係基於 OpenSpec（Fission-AI/OpenSpec）同 OMC（Yeachan-Heo/oh-my-claudecode）嘅官方源碼同文檔分析整理而成，源碼分析係根據筆者本地倉庫版本，仲未喺所有場景中完成全部驗證。文中嘅配置模板同參數建議僅供參考，實際效果請以你嘅項目環境同測試結果為準。如果有實際使用經驗，歡迎喺評論區分享交流。
單獨用佢哋其中任何一個，已經可以解決唔少問題。但係當呢兩個工具配合起嚟嘅時候，由規劃到落地嘅整條鏈路先至真正行得通。今日呢篇文章就嚟拆解佢哋各自嘅架構設計，以及協同使用嘅具體玩法。
1. OpenSpec：規範先行，等 AI 同人先對齊目標
核心定位
OpenSpec 嘅核心思路好簡單：喺 AI 編碼助手同代碼之間插入一個輕量規範層。寫代碼之前，先將要做啲乜講清楚，形成一份人同 AI 都明嘅共識文檔。
佢唔係另一個需求管理工具。佢解決嘅係一個更具體嘅問題：AI 編碼助手收到一個模糊嘅需求之後，一係過度發揮，一係理解偏差。OpenSpec 透過結構化嘅規範文件將邊界畫清楚。
圖 2：OpenSpec 雙軌目錄結構——specs/ 管規範，changes/ 管變更
雙軌機制：Specs + Changes
OpenSpec 嘅目錄結構分為兩條軌道：
openspec/
├── specs/ # 系統當前行為的規範
│ ├── auth/
│ │ └── spec.md
│ └── payments/
│ └── spec.md
└── changes/ # 待處理的變更
├── add-dark-mode/
│ ├── proposal.md # Why & What
│ ├── design.md # How（技術方案）
│ ├── tasks.md # 實現清單
│ ├── .openspec.yaml # 變更元數據
│ └── specs/ # Delta 規範
└── archive/ # 已歸檔的變更
specs/ 目錄係系統嘅 Source of Truth（事實來源），記錄當前系統嘅行為規範。changes/ 目錄就管理每次變更嘅全生命週期：由提案（proposal）到技術設計（design），再到實現任務清單（tasks）。
呢種雙軌設計有個好處：主規範唔會成日被修改。每次變更都喺獨立嘅子目錄入面完成，透過 Delta 規範描述要增刪改邊啲行為，驗證通過之後再合併返主規範。
DAG 依賴圖引擎
呢四個工件之間有嚴格嘅依賴關係：
proposal（根節點）
│
┌─────────────┴─────────────┐
▼ ▼
specs design
(依賴: proposal) (依賴: proposal)
│ │
└─────────────┬─────────────┘
▼
tasks
(依賴: specs, design)
proposal 冇依賴，可以首先創建。specs 和 design 都依賴 proposal。tasks 最重，要等 specs 和 design 都完成先至可以生成。
OpenSpec 用文件系統存在檢測嚟追蹤每個工件嘅狀態：BLOCKED（依賴未滿足）→ READY（可以創建）→ DONE（文件已存在）。唔需要額外嘅狀態服務，文件本身就係狀態。
Delta 規範：增量變更嘅核心創新
呢個係 OpenSpec 設計中比較精巧嘅部分。每次變更唔需要重寫整個規範，而係用 Delta 規範描述增量：
ADDED Requirements：新增行為，追加到主規範MODIFIED Requirements：變更行為，替換現有需求REMOVED Requirements：廢棄行為，從主規範刪除RENAMED Requirements：重命名，使用FROM:/TO:格式
咁做嘅好處係：每次變更嘅影響範圍一目瞭然。合併時都唔容易產生衝突，因為 Delta 只描述差異，唔重複已有內容。
OPSX 工作流
OpenSpec 將日常操作封裝成 OPSX 工作流：
/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive
一條命令 /opsx:propose add-dark-mode 就可以創建變更目錄同生成所有規劃工件。/opsx:apply 執行實現。/opsx:sync 合併 Delta 規範到主規範。/opsx:archive 歸檔已完成嘅變更。
仲有擴展模式：/opsx:explore（探索想法）、/opsx:verify（三維度驗證）、/opsx:ff（快進創建所有工件）等。
/opsx:explore 比較特別。佢唔係直接創建變更，而係進入探索模式，幫你喺正式規劃前理清思路。比如你對某個技術方案有疑慮，先 explore 一下，再決定要不要 propose。
/opsx:verify 從三個維度檢查實現：Completeness（所有任務係咪完成、所有需求係咪實現）、Correctness（實現係咪匹配規範意圖、邊界條件係咪處理）、Coherence（設計決策係咪反映喺代碼中、模式係咪一致）。呢三個維度覆蓋咗規範驗證嘅關鍵視角。
OpenSpec 仲支持項目級配置。喺 openspec/config.yaml 入面，你可以指定技術棧上下文同每種工件嘅規則約束：
schema: spec-driven
context:|
Tech stack: TypeScript, React, Node.js
rules:
proposal:
-Includerollbackplan
specs:
-UseGiven/When/Thenformat
context 字段俾 AI 提供技術棧背景，rules 為每種工件定義額外約束。例如要求每個 proposal 必須包含回滾計劃，每個 spec 必須使用 Given/When/Then 格式。呢啲約束會喺生成工件時自動注入到 AI 嘅上下文中——等於俾 AI 加咗一層睇唔到嘅圍欄。
另外，OpenSpec 支持 25+ 種 AI 編碼工具，唔綁定特定平台。透過 openspec init --tools claude,cursor 可以同時為多個工具生成 Skills 文件。呢個意味住你嘅團隊入面有人用 Cursor 有人用 Claude Code，規範層係統一嘅。
2. OMC：多智能體編排，將執行落到實處
定位同核心理念
如果話 OpenSpec 係建築圖紙，OMC 就係施工隊。佢嘅定位係 Claude Code 嘅多智能體編排系統，透過 Hooks、Skills、Agents、State 四大互鎖系統，將複雜嘅開發任務拆解成多個專業 Agent 嘅協同工作。
圖 3：OMC 四大互鎖系統——Hooks → Skills → Agents → State
四大互鎖系統
OMC 嘅架構可以用一條流水線嚟概括：
User Input → Hooks（事件檢測）→ Skills（行為注入）→ Agents（任務執行）→ State（進度追蹤）
Hooks 系統攔截 11 個生命週期事件。例如 UserPromptSubmit 用嚟檢測魔法關鍵詞（後面會講到），PreCompact 喺上下文壓縮前保存關鍵信息到 notepad，Stop 事件就可以強制 Claude 繼續執行。
Skills 系統有 38 個技能，分三層組合：
Guarantee Layer（可選）：ralph - "不完成不停止"
Enhancement Layer（0-N）：ultrawork（並行）| git-master（提交）
Execution Layer（主要）：default | orchestrate | planner
組合公式係：[執行技能] + [0-N 增強技能] + [可選保證技能]。比如 orchestrate + ultrawork + ralph 就係編排模式 + 並行執行 + 唔完成唔停止。
Agents 系統係 OMC 嘅核心執行層，29 個專業 Agent 分佈喺 4 條泳道：
| Build/Analysis | ||
| Review | ||
| Domain | ||
| Coordination |
每個 Agent 默認綁定咗模型級別：haiku（快速便宜）負責代碼探索，opus（高推理質量）負責架構設計同審查，sonnet（平衡）負責日常編碼同測試。
State 系統解決咗一個好實際嘅問題：Claude Code 嘅上下文窗口有限，壓縮後容易唔見咗關鍵信息。OMC 用 .omc/ 目錄下嘅 notepad（抗壓縮備忘板）、project-memory.json（項目知識庫）、state/（運行時狀態）嚟實現跨會話嘅持久化。
.omc/
├── state/ # 每模式狀態文件
│ ├── autopilot-state.json
│ ├── team/
│ └── sessions/
├── notepad.md # 抗壓縮備忘板
├── project-memory.json # 項目知識庫
├── plans/ # 執行計劃
└── logs/ # 執行日誌
Notepad 係其中比較精巧嘅設計。佢透過 MCP 工具讀寫，喺 PreCompact 事件時保存關鍵信息（例如當前任務嘅進度、重要嘅設計決策）。上下文壓縮後，呢啲信息會自動重新注入。講白啲就係俾 AI 一個壓縮抵抗嘅外掛記憶。
Team 模式：五階段流水線
OMC 推薦嘅編排方式係 Team 模式，分為五個階段：
team-plan → team-prd → team-exec → team-verify → team-fix（循環）
規劃、需求、執行、驗證、修復形成循環，直到驗證通過。呢個同 OpenSpec 嘅 propose → apply → verify 有異曲同工之妙，但 OMC 嘅關注點喺工程執行層面。
魔法關鍵詞
OMC 有個幾得意嘅設計：透過魔法關鍵詞觸發唔同嘅執行模式。輸入 autopilot 啓動全自主執行，ralph 激活持久循環（唔完成唔停止），ultrawork 或 ulw 開啓並行化，team 就進入 Team 編排模式。
呢啲關鍵詞透過 Hooks 系統喺 UserPromptSubmit 事件中被檢測，然後自動注入對應嘅 Skills。用戶唔需要記住複雜嘅命令，只要喺對話中自然咁提到關鍵詞就得。
除咗單機編排，OMC v4.4.0+ 仲引入咗 tmux CLI 工作者，可以跨終端分派任務：
/omc-teams 2:codex "security review"
/omc-teams 2:gemini "redesign UI"
呢行命令嘅意思係：喺第 2 個 tmux 窗格中，分別用 Codex 同 Gemini 執行唔同嘅任務。OMC 嘅 ccg 關鍵詞更進一步，同時調度 Claude + Codex + Gemini 三個模型協作。
仲有一個容易被忽略嘅功能：自定義技能。項目作用域嘅技能放喺 .omc/skills/（受版本控制，團隊共享），用戶作用域嘅放喺 ~/.omc/skills/（所有項目通用）。透過 /skillify 命令可以從當前操作中提取可複用模式，生成新嘅 Skill。匹配嘅技能會喺後續會話中自動注入——等於 AI 可以從你嘅操作習慣中自動學習。
3. 協同機制：當建築圖紙遇上施工隊
圖 4：OpenSpec + OMC 聯合工作流全景——三條關鍵集成鏈路
呢節係成篇文章嘅核心。單獨睇 OpenSpec 同 OMC，佢哋各自解決咗一半嘅問題。但係當佢哋配合起嚟，由規劃到執行先至形成咗真正嘅閉環。
架構層面嘅互補關係
先講一個關鍵判斷：OpenSpec 同 OMC 唔係競品，佢哋喺唔同嘅抽象層工作。
| 核心關注點 | ||
| 工作流階段 | ||
| 多工具支持 | ||
| 狀態管理 | .omc/ | |
| 驗證機制 |
OpenSpec 管嘅係呢個功能應該滿足啲乜嘢需求、跟從啲乜嘢規範，OMC 管嘅係用啲乜嘢 Agent 去實現、用啲乜嘢模型去做 code review、點樣追蹤進度。
打個比喻：OpenSpec 係產品經理寫嘅 PRD 同設計稿，OMC 係項目經理排嘅迭代計劃同分工表。兩者缺一不可——冇 PRD 嘅開發係盲人摸象，冇計劃排期嘅 PRD 係一紙空文。
Skills → Agent 嘅鏈路
呢個係兩個工具之間最直接嘅連接點。
OpenSpec 透過 openspec init --tools claude 喺項目中生成 Skills 文件，路徑係 .claude/skills/openspec-*/SKILL.md。OMC 作為 Claude Code 嘅插件，會自動發現同加載呢啲 Skills。
即係話，當你用 OpenSpec 定義好一個變更之後，OMC 嘅 Agent 可以直接讀取呢啲規範文件作為執行上下文。唔需要手動複製粘貼，亦唔需要額外嘅配置。
具體嘅路徑係：OpenSpec 嘅 init 命令在 .claude/skills/openspec-apply-change/SKILL.md 等位置生成技能描述文件。OMC 啓動時會掃描呢啲路徑，將 OpenSpec 嘅規範上下文注入到 Agent 嘅指令集中。當 executor agent 接到任務時，佢已經知道項目嘅技術棧、變更嘅目標、設計約束等信息。
呢種設計嘅好處係零配置集成。你唔需要寫膠水代碼，唔需要配置 API 對接，兩個工具透過共享嘅文件系統自然咁交換信息。
tasks.md → executor agent 嘅任務傳導
OpenSpec 喺變更目錄下生成 tasks.md，格式係標準嘅 checkbox 列表：
- [ ] 1.1 創建認證中間件
- [ ] 1.2 實現 JWT 簽發和驗證
- [ ] 1.3 添加權限校驗裝飾器
OMC 嘅 executor agent 可以逐條執行呢啲任務。每完成一項，勾選 checkbox。OMC 嘅 verifier agent 可以驗證完成狀態。呢個唔係兩個系統之間嘅 API 對接，而係透過共享嘅文件格式實現咗松耦合嘅協作。
雙層校驗：規範驗證 + 工程驗證
呢個係協同使用中價值最高嘅部分。
OpenSpec 嘅 /opsx:verify 從三個維度驗證實現：
Completeness：所有任務完成、所有需求實現 Correctness：實現匹配規範意圖、邊界條件處理 Coherence：設計決策反映喺代碼中、模式一致
OMC 嘅驗證協議從工程角度檢查：
BUILD：編譯通過 TEST：所有測試通過 LINT：冇 Lint 錯誤 ARCHITECT：Opus 級別審查通過
兩層驗證互補：OpenSpec 確保你做啱咗事情（Do the right things），OMC 確保你將事情做啱（Do things right）。
狀態追蹤嘅互補
OpenSpec 用文件系統追蹤工件狀態。proposal.md 存在就說明提案完成，tasks.md 入面嘅 checkbox 勾選咗就說明任務完成。簡單直接，但粒度有限。
OMC 用 .omc/state/ 追蹤運行時進度，支持 notepad（跨壓縮嘅信息持久化）同 project-memory（項目知識積累）。粒度更細，但同規範層冇直接關聯。
兩個系統疊加之後，宏觀進度睇 OpenSpec 嘅工件完成度，微觀進度睇 OMC 嘅運行時狀態。
4. 實戰演示：幫項目加認證功能
講完原理，嚟行一次完整流程。假設要幫一個現有嘅 Node.js 項目加用戶認證功能。
第一階段：OpenSpec 規劃
# 安裝 OpenSpec
npm install -g @fission-ai/openspec@latest
# 初始化（指定使用 Claude Code）
cd your-project
openspec init --tools claude
初始化之後，用 OPSX 工作流創建變更：
/opsx:propose add-auth
呢條命令會喺 openspec/changes/add-auth/ 目錄下生成所有規劃工件：
# .openspec.yaml 變更元數據
name: add-auth
status: planning
# proposal.md - 為什麼做、做什麼
## 動機
系統目前沒有用戶認證，所有接口裸奔。
## 目標
添加 JWT 認證，支持登錄、註冊、token 刷新。
# design.md - 技術方案
## 架構決策
使用 JWT + bcrypt，中間件模式攔截請求。
## API 設計
POST /auth/register, POST /auth/login, POST /auth/refresh
# tasks.md - 實現清單
- [ ] 1.1 創建 User 模型和數據庫遷移
- [ ] 1.2 實現密碼哈希工具函數
- [ ] 1.3 創建認證中間件
- [ ] 1.4 實現註冊接口
- [ ] 1.5 實現登錄接口
- [ ] 1.6 實現 token 刷新接口
- [ ] 1.7 編寫單元測試
同時，OpenSpec 會喺 .claude/skills/ 目錄下生成對應嘅 SKILL.md 文件，為下一階段嘅 OMC 執行做準備。
第二階段：OMC 執行
# 安裝 OMC（Claude Code 插件方式）
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode
/omc-setup
安裝完成之後，OMC 會自動發現 OpenSpec 生成嘅 Skills。而家用 ralph 模式執行任務：
ralph: 按照 openspec/changes/add-auth/tasks.md 逐條實現認證功能
OMC 會咁樣編排執行：
explore agent（haiku 模型）先掃描項目結構，瞭解現有代碼嘅組織方式、路由配置、數據庫連接等 architect agent（opus 模型）讀取 design.md，確認 JWT + bcrypt 嘅技術方案係咪適合當前項目，評估有冇架構風險executor agent（sonnet 模型）逐條執行 tasks.md入面嘅任務，每完成一項勾選 checkboxtest-engineer agent（sonnet 模型）編寫單元測試，覆蓋註冊、登錄、token 刷新等核心場景 code-reviewer agent（opus 模型）做代碼審查，關注安全性同代碼質量
ralph 模式嘅關鍵特性係唔完成唔停止——如果驗證冇通過，會自動進入修復循環。
如果你有多個獨立嘅任務想並行執行，都可以用 Team 模式：
/team 3:executor "實現 openspec/changes/add-auth/tasks.md 中的認證功能"
呢條命令會啓動 3 個並行嘅 executor agent 同時工作，每個負責 tasks.md 入面嘅一部分任務。OMC 仲支持混合編排，例如用 /omc-teams 2:codex "security review" 等 Codex 專門做安全審查。
第三階段：雙層驗證
執行完成之後，先跑 OpenSpec 嘅規範驗證：
/opsx:verify
檢查三個維度：所有 tasks.md 嘅 checkbox 係咪都勾選咗（Completeness），實現係咪符合 proposal 中定義嘅目標（Correctness），代碼風格係咪同 design.md 中嘅架構決策一致（Coherence）。
然後跑 OMC 嘅工程驗證：
ultrawork: 運行所有測試，確認無迴歸
檢查 BUILD、TEST、LINT 係咪全部通過。
兩層驗證都綠燈之後，合併 Delta 規範並歸檔：
/opsx:sync
/opsx:archive
圖 5：完整聯合工作流時序——規劃 → 執行 → 雙層驗證 → 歸檔
整個過程可以濃縮為：OpenSpec 負責將做啲乜講清楚，OMC 負責將執行落實到位，雙層驗證確保結果靠譜。
你喺項目中用過類似嘅方案嗎？例如用規範驅動開發，或者多 Agent 編排？歡迎喺評論區傾下你嘅經驗。
5. 經驗總結同最佳實踐
睇咗一輪官方文檔同社區討論，整理出啲實用建議。
幾時淨係用 OpenSpec
如果你嘅團隊已經在用成熟嘅 CI/CD 流水線同代碼審查流程，OpenSpec 單獨使用就夠了。佢嘅價值在於俾 AI 編碼助手提供上下文同約束，防止 AI 過度發揮。
另外一個重要場景：你嘅團隊使用嘅 AI 編碼工具唔係 Claude Code。OpenSpec 支持 25+ 種 AI 工具，包括 Cursor、Windsurf、GitHub Copilot、Codex、Gemini CLI 等。OMC 目前只支持 Claude Code（雖然可以透過 tmux 調度 Codex 同 Gemini）。如果你嘅團隊工具棧比較雜，OpenSpec 係更通用嘅選擇。
從使用成本嚟睇，OpenSpec 係純本地工具，安裝只需一條 npm 命令，唔需要 API Key，唔依賴特定平台。OMC 作為 Claude Code 嘅插件，需要先有 Claude Code 嘅訂閲。
幾時引入 OMC
當項目複雜度上升，單個 AI 會話搞唔掂嘅時候，OMC 嘅價值就體現出嚟。29 個專業 Agent 分工協作，opus 級別嘅模型做架構審查，haiku 級別嘅做代碼探索，既保證咗質量又控制咗成本。
特別適合呢幾種場景：
大規模代碼重構：多個模塊需要同步修改，單會話嘅上下文窗口裝唔落 多人協作嘅功能開發：需要 code review、security review 等多角色參與 嚴格質量把關：BUILD/TEST/LINT/ARCHITECT 四層驗證一個都唔可以少 長時間任務：ralph 模式嘅唔完成唔停止特性適合跑批處理式嘅開發任務
聯合使用嘅注意事項
講真，兩個系統疊加會增加配置嘅複雜度。幾個伏位需要提前知道：
OpenSpec 需要 Node.js 20.19.0+，環境版本要先確認 OMC 嘅 Team 模式需要啓用實驗性功能： CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1OpenSpec 嘅上下文注入有 50KB 大小限制，複雜項目要控制規範文件嘅篇幅 OMC 嘅 npm 包名係 oh-my-claude-sisyphus，不是oh-my-claudecode，唔好搜錯OpenSpec 官方推薦使用高推理模型（例如 Codex 5.5、Opus 4.7）嚟執行規劃任務，低配模型可能生成質量唔夠嘅工件
仲有一個容易忽略嘅點：兩個系統都透過 Skills 機制擴展，但 Skills 嘅目錄結構唔完全一樣。OpenSpec 嘅 Skills 喺 .claude/skills/openspec-*/，OMC 嘅自定義技能喺 .omc/skills/。唔會衝突，但需要清楚邊個文件歸邊個系統管。
唔同團隊規模嘅建議
個人開發者：OpenSpec 單獨使用足夠。輕量、通用、唔挑工具。日常開發中用 /opsx:propose 將需求理清楚，再用你慣用嘅 AI 編碼助手執行就得。
2-5 人小團隊：OpenSpec + OMC 嘅 autopilot 模式。規範對齊 + 自動執行，性價比高。OpenSpec 解決大家諗嘅唔係同一件事嘅問題，OMC 解決執行質量唔穩定嘅問題。
5 人以上團隊：OpenSpec + OMC 嘅 Team 模式。多 Agent 協作 + 雙層驗證，質量更有保障。OpenSpec 嘅 Delta 規範喺多人協作時特別有用——每個人嘅變更都喺獨立目錄入面，合併衝突嘅概率低。
總結
講到尾，AI 輔助開發嘅瓶頸已經從AI 識唔識寫代碼轉向了人點樣同 AI 有效協作。純粹嘅 prompt engineering 解決唔到系統性嘅問題——你唔可能每次都將所有上下文同約束塞入一個 prompt 入面。
OpenSpec 用結構化嘅規範層解決咗對齊嘅問題。OMC 用多智能體編排解決咗執行嘅問題。兩者協同，等由規劃到落地嘅整條鏈路唔再係兩條平行線。
如果你正在用 AI 編程助手做複雜項目，建議先試試 OpenSpec 嘅 openspec init，感受一下規範驅動嘅開發流程。等項目嘅複雜度上嚟，再將 OMC 加埋入嚟做編排同質量保證。
好啦，多謝你睇我嘅文章，如果鍾意可以點讚轉發俾需要嘅朋友，我哋下一期再見！敬請期待！
🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃 第 121 篇，AI 編程最佳實戰「2026」系列第 37 篇
大家好，歡迎來到 術哥無界 | ShugeX ｜ 運維有術。
我是術哥，一名專注於 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫的技術實踐者與開源佈道者！
Talk is cheap, let's explore。無界探索，有術而行。
圖 1：OpenSpec 規劃層 + OMC 執行層雙軌協作全景
你在用 AI 編程助手做項目時，可能踩過這些坑：
跟 AI 聊了半天需求，它轉頭就忘，重新解釋一遍又一遍 規範文檔寫了一堆，AI 寫出來的代碼壓根不按規範走 任務拆得挺清楚，但沒有自動化的手段追蹤完成度和質量
這些問題的根源是同一個：規劃和執行之間沒有形成閉環。 你告訴 AI 做什麼是一回事，AI 真正按規範去執行是另一回事。
OpenSpec 和 OMC（Oh-My-ClaudeCode）分別在這兩個環節發力。OpenSpec 在代碼和 AI 之間加了一層輕量規範，讓雙方先就做什麼達成一致；OMC 則通過 29 個專業 Agent 和四大互鎖系統，把怎麼做的執行過程編排得井井有條。
說明：本文內容基於 OpenSpec（Fission-AI/OpenSpec）和 OMC（Yeachan-Heo/oh-my-claudecode）的官方源碼及文檔分析整理而成，源碼分析基於筆者本地倉庫版本，尚未在所有場景中完成全量驗證。文中的配置模板和參數建議僅供參考，實際效果請以你的項目環境和測試結果為準。如果有實際使用經驗，歡迎在評論區分享交流。
單獨用它們中的任何一個，已經能解決不少問題。但當這兩個工具配合起來的時候，從規劃到落地的整條鏈路才真正跑通。今天這篇文章就來拆解它們各自的架構設計，以及協同使用的具體玩法。
1. OpenSpec：規範先行，讓 AI 和人先對齊目標
核心定位
OpenSpec 的核心思路很簡單：在 AI 編碼助手和代碼之間插入一個輕量規範層。寫代碼之前，先把要做什麼說清楚，形成一份人和 AI 都能理解的共識文檔。
它不是另一個需求管理工具。它解決的是一個更具體的問題：AI 編碼助手收到一個模糊的需求後，要麼過度發揮，要麼理解偏差。OpenSpec 通過結構化的規範文件把邊界畫清楚。
圖 2：OpenSpec 雙軌目錄結構——specs/ 管規範，changes/ 管變更
雙軌機制：Specs + Changes
OpenSpec 的目錄結構分為兩條軌道：
openspec/
├── specs/ # 系統當前行為的規範
│ ├── auth/
│ │ └── spec.md
│ └── payments/
│ └── spec.md
└── changes/ # 待處理的變更
├── add-dark-mode/
│ ├── proposal.md # Why & What
│ ├── design.md # How（技術方案）
│ ├── tasks.md # 實現清單
│ ├── .openspec.yaml # 變更元數據
│ └── specs/ # Delta 規範
└── archive/ # 已歸檔的變更
specs/ 目錄是系統的 Source of Truth（事實來源），記錄當前系統的行為規範。changes/ 目錄則管理每次變更的全生命週期：從提案（proposal）到技術設計（design），再到實現任務清單（tasks）。
這種雙軌設計有個好處：主規範不會被頻繁修改。每次變更都在獨立的子目錄裏完成，通過 Delta 規範描述要增刪改哪些行為，驗證通過後再合併回主規範。
DAG 依賴圖引擎
這四個工件之間有嚴格的依賴關係：
proposal（根節點）
│
┌─────────────┴─────────────┐
▼ ▼
specs design
(依賴: proposal) (依賴: proposal)
│ │
└─────────────┬─────────────┘
▼
tasks
(依賴: specs, design)
proposal 沒有依賴，可以首先創建。specs 和 design 都依賴 proposal。tasks 最重，要等 specs 和 design 都完成才能生成。
OpenSpec 用文件系統存在檢測來追蹤每個工件的狀態：BLOCKED（依賴未滿足）→ READY（可以創建）→ DONE（文件已存在）。不需要額外的狀態服務，文件本身就是狀態。
Delta 規範：增量變更的核心創新
這是 OpenSpec 設計中比較精巧的部分。每次變更不需要重寫整個規範，而是用 Delta 規範描述增量：
ADDED Requirements：新增行為，追加到主規範MODIFIED Requirements：變更行為，替換現有需求REMOVED Requirements：廢棄行為，從主規範刪除RENAMED Requirements：重命名，使用FROM:/TO:格式
這樣做的好處是：每次變更的影響範圍一目瞭然。合併時也不容易產生衝突，因為 Delta 只描述差異，不重複已有內容。
OPSX 工作流
OpenSpec 把日常操作封裝成了 OPSX 工作流：
/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive
一條命令 /opsx:propose add-dark-mode 就能創建變更目錄並生成所有規劃工件。/opsx:apply 執行實現。/opsx:sync 合併 Delta 規範到主規範。/opsx:archive 歸檔已完成的變更。
還有擴展模式：/opsx:explore（探索想法）、/opsx:verify（三維度驗證）、/opsx:ff（快進創建所有工件）等。
/opsx:explore 比較特別。它不直接創建變更，而是進入探索模式，幫你在正式規劃前理清思路。比如你對某個技術方案有疑慮，先 explore 一下，再決定要不要 propose。
/opsx:verify 從三個維度檢查實現：Completeness（所有任務是否完成、所有需求是否實現）、Correctness（實現是否匹配規範意圖、邊界條件是否處理）、Coherence（設計決策是否反映在代碼中、模式是否一致）。這三個維度覆蓋了規範驗證的關鍵視角。
OpenSpec 還支持項目級配置。在 openspec/config.yaml 中，你可以指定技術棧上下文和每種工件的規則約束：
schema: spec-driven
context:|
Tech stack: TypeScript, React, Node.js
rules:
proposal:
-Includerollbackplan
specs:
-UseGiven/When/Thenformat
context 字段給 AI 提供技術棧背景，rules 為每種工件定義額外約束。比如要求每個 proposal 必須包含回滾計劃，每個 spec 必須使用 Given/When/Then 格式。這些約束會在生成工件時自動注入到 AI 的上下文中——等於給 AI 加了一層看不見的圍欄。
另外，OpenSpec 支持 25+ 種 AI 編碼工具，不綁定特定平台。通過 openspec init --tools claude,cursor 可以同時為多個工具生成 Skills 文件。這意味着你的團隊裏有人用 Cursor 有人用 Claude Code，規範層是統一的。
2. OMC：多智能體編排，把執行落到實處
定位與核心理念
如果說 OpenSpec 是建築圖紙，OMC 就是施工隊。它的定位是 Claude Code 的多智能體編排系統，通過 Hooks、Skills、Agents、State 四大互鎖系統，把複雜的開發任務拆解成多個專業 Agent 的協同工作。
圖 3：OMC 四大互鎖系統——Hooks → Skills → Agents → State
四大互鎖系統
OMC 的架構可以用一條流水線來概括：
User Input → Hooks（事件檢測）→ Skills（行為注入）→ Agents（任務執行）→ State（進度追蹤）
Hooks 系統攔截 11 個生命週期事件。比如 UserPromptSubmit 用來檢測魔法關鍵詞（後面會講到），PreCompact 在上下文壓縮前保存關鍵信息到 notepad，Stop 事件則可以強制 Claude 繼續執行。
Skills 系統有 38 個技能，分三層組合：
Guarantee Layer（可選）：ralph - "不完成不停止"
Enhancement Layer（0-N）：ultrawork（並行）| git-master（提交）
Execution Layer（主要）：default | orchestrate | planner
組合公式是：[執行技能] + [0-N 增強技能] + [可選保證技能]。比如 orchestrate + ultrawork + ralph 就是編排模式 + 並行執行 + 不完成不停止。
Agents 系統是 OMC 的核心執行層，29 個專業 Agent 分佈在 4 條泳道：
| Build/Analysis | ||
| Review | ||
| Domain | ||
| Coordination |
每個 Agent 默認綁定了模型級別：haiku（快速便宜）負責代碼探索，opus（高推理質量）負責架構設計和審查，sonnet（平衡）負責日常編碼和測試。
State 系統解決了一個很實際的問題：Claude Code 的上下文窗口有限，壓縮後容易丟失關鍵信息。OMC 用 .omc/ 目錄下的 notepad（抗壓縮備忘板）、project-memory.json（項目知識庫）、state/（運行時狀態）來實現跨會話的持久化。
.omc/
├── state/ # 每模式狀態文件
│ ├── autopilot-state.json
│ ├── team/
│ └── sessions/
├── notepad.md # 抗壓縮備忘板
├── project-memory.json # 項目知識庫
├── plans/ # 執行計劃
└── logs/ # 執行日誌
Notepad 是其中比較精巧的設計。它通過 MCP 工具讀寫，在 PreCompact 事件時保存關鍵信息（比如當前任務的進度、重要的設計決策）。上下文壓縮後，這些信息會自動重新注入。說白了就是給 AI 一個壓縮抵抗的外掛記憶。
Team 模式：五階段流水線
OMC 推薦的編排方式是 Team 模式，分為五個階段：
team-plan → team-prd → team-exec → team-verify → team-fix（循環）
規劃、需求、執行、驗證、修復形成循環，直到驗證通過。這和 OpenSpec 的 propose → apply → verify 有異曲同工之處，但 OMC 的關注點在工程執行層面。
魔法關鍵詞
OMC 有個挺有意思的設計：通過魔法關鍵詞觸發不同的執行模式。輸入 autopilot 啓動全自主執行，ralph 激活持久循環（不完成不停止），ultrawork 或 ulw 開啓並行化，team 則進入 Team 編排模式。
這些關鍵詞通過 Hooks 系統在 UserPromptSubmit 事件中被檢測，然後自動注入對應的 Skills。用戶不需要記憶複雜的命令，只要在對話中自然地提到關鍵詞就行。
除了單機編排，OMC v4.4.0+ 還引入了 tmux CLI 工作者，可以跨終端分派任務：
/omc-teams 2:codex "security review"
/omc-teams 2:gemini "redesign UI"
這行命令的意思是：在第 2 個 tmux 窗格中，分別用 Codex 和 Gemini 執行不同的任務。OMC 的 ccg 關鍵詞更進一步，同時調度 Claude + Codex + Gemini 三個模型協作。
還有一個容易被忽略的功能：自定義技能。項目作用域的技能放在 .omc/skills/（受版本控制，團隊共享），用戶作用域的放在 ~/.omc/skills/（所有項目通用）。通過 /skillify 命令可以從當前操作中提取可複用模式，生成新的 Skill。匹配的技能會在後續會話中自動注入——等於 AI 能從你的操作習慣中自動學習。
3. 協同機制：當建築圖紙遇上施工隊
圖 4：OpenSpec + OMC 聯合工作流全景——三條關鍵集成鏈路
這節是整篇文章的核心。單獨看 OpenSpec 和 OMC，它們各自解決了一半的問題。但當它們配合起來，從規劃到執行才形成了真正的閉環。
架構層面的互補關係
先說一個關鍵判斷：OpenSpec 和 OMC 不是競品，它們在不同的抽象層工作。
| 核心關注點 | ||
| 工作流階段 | ||
| 多工具支持 | ||
| 狀態管理 | .omc/ | |
| 驗證機制 |
OpenSpec 管的是這個功能應該滿足什麼需求、遵循什麼規範，OMC 管的是用什麼 Agent 去實現、用什麼模型去做 code review、怎麼追蹤進度。
打個比方：OpenSpec 是產品經理寫的 PRD 和設計稿，OMC 是項目經理排的迭代計劃和分工表。兩者缺一不可——沒有 PRD 的開發是盲人摸象，沒有計劃排期的 PRD 是一紙空文。
Skills → Agent 的鏈路
這是兩個工具之間最直接的連接點。
OpenSpec 通過 openspec init --tools claude 在項目中生成 Skills 文件，路徑是 .claude/skills/openspec-*/SKILL.md。OMC 作為 Claude Code 的插件，會自動發現並加載這些 Skills。
也就是說，當你用 OpenSpec 定義好一個變更後，OMC 的 Agent 能直接讀取這些規範文件作為執行上下文。不需要手動複製粘貼，也不需要額外的配置。
具體的路徑是：OpenSpec 的 init 命令在 .claude/skills/openspec-apply-change/SKILL.md 等位置生成技能描述文件。OMC 啓動時會掃描這些路徑，把 OpenSpec 的規範上下文注入到 Agent 的指令集中。當 executor agent 接到任務時，它已經知道項目的技術棧、變更的目標、設計約束等信息。
這種設計的好處是零配置集成。你不需要寫膠水代碼，不需要配置 API 對接，兩個工具通過共享的文件系統自然地交換信息。
tasks.md → executor agent 的任務傳導
OpenSpec 在變更目錄下生成 tasks.md，格式是標準的 checkbox 列表：
- [ ] 1.1 創建認證中間件
- [ ] 1.2 實現 JWT 簽發和驗證
- [ ] 1.3 添加權限校驗裝飾器
OMC 的 executor agent 可以逐條執行這些任務。每完成一項，勾選 checkbox。OMC 的 verifier agent 可以驗證完成狀態。這不是兩個系統之間的 API 對接，而是通過共享的文件格式實現了松耦合的協作。
雙層校驗：規範驗證 + 工程驗證
這是協同使用中價值最高的部分。
OpenSpec 的 /opsx:verify 從三個維度驗證實現：
Completeness：所有任務完成、所有需求實現 Correctness：實現匹配規範意圖、邊界條件處理 Coherence：設計決策反映在代碼中、模式一致
OMC 的驗證協議從工程角度檢查：
BUILD：編譯通過 TEST：所有測試通過 LINT：無 Lint 錯誤 ARCHITECT：Opus 級別審查通過
兩層驗證互補：OpenSpec 確保你做對了事情（Do the right things），OMC 確保你把事情做對了（Do things right）。
狀態追蹤的互補
OpenSpec 用文件系統追蹤工件狀態。proposal.md 存在就說明提案完成，tasks.md 裏的 checkbox 勾選了就說明任務完成。簡單直接，但粒度有限。
OMC 用 .omc/state/ 追蹤運行時進度，支持 notepad（跨壓縮的信息持久化）和 project-memory（項目知識積累）。粒度更細，但和規範層沒有直接關聯。
兩個系統疊加後，宏觀進度看 OpenSpec 的工件完成度，微觀進度看 OMC 的運行時狀態。
4. 實戰演示：給項目添加認證功能
說完了原理，來跑一遍完整流程。假設要給一個現有的 Node.js 項目添加用戶認證功能。
第一階段：OpenSpec 規劃
# 安裝 OpenSpec
npm install -g @fission-ai/openspec@latest
# 初始化（指定使用 Claude Code）
cd your-project
openspec init --tools claude
初始化後，用 OPSX 工作流創建變更：
/opsx:propose add-auth
這條命令會在 openspec/changes/add-auth/ 目錄下生成所有規劃工件：
# .openspec.yaml 變更元數據
name: add-auth
status: planning
# proposal.md - 為什麼做、做什麼
## 動機
系統目前沒有用戶認證，所有接口裸奔。
## 目標
添加 JWT 認證，支持登錄、註冊、token 刷新。
# design.md - 技術方案
## 架構決策
使用 JWT + bcrypt，中間件模式攔截請求。
## API 設計
POST /auth/register, POST /auth/login, POST /auth/refresh
# tasks.md - 實現清單
- [ ] 1.1 創建 User 模型和數據庫遷移
- [ ] 1.2 實現密碼哈希工具函數
- [ ] 1.3 創建認證中間件
- [ ] 1.4 實現註冊接口
- [ ] 1.5 實現登錄接口
- [ ] 1.6 實現 token 刷新接口
- [ ] 1.7 編寫單元測試
同時，OpenSpec 會在 .claude/skills/ 目錄下生成對應的 SKILL.md 文件，為下一階段的 OMC 執行做準備。
第二階段：OMC 執行
# 安裝 OMC（Claude Code 插件方式）
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode
/omc-setup
安裝完成後，OMC 會自動發現 OpenSpec 生成的 Skills。現在用 ralph 模式執行任務：
ralph: 按照 openspec/changes/add-auth/tasks.md 逐條實現認證功能
OMC 會這樣編排執行：
explore agent（haiku 模型）先掃描項目結構，瞭解現有代碼的組織方式、路由配置、數據庫連接等 architect agent（opus 模型）讀取 design.md，確認 JWT + bcrypt 的技術方案是否適配當前項目，評估是否有架構風險executor agent（sonnet 模型）逐條執行 tasks.md中的任務，每完成一項勾選 checkboxtest-engineer agent（sonnet 模型）編寫單元測試，覆蓋註冊、登錄、token 刷新等核心場景 code-reviewer agent（opus 模型）做代碼審查，關注安全性和代碼質量
ralph 模式的關鍵特性是不完成不停止——如果驗證沒通過，會自動進入修復循環。
如果你有多個獨立的任務想要並行執行，也可以用 Team 模式：
/team 3:executor "實現 openspec/changes/add-auth/tasks.md 中的認證功能"
這條命令會啓動 3 個並行的 executor agent 同時工作，每個負責 tasks.md 中的一部分任務。OMC 還支持混合編排，比如用 /omc-teams 2:codex "security review" 讓 Codex 專門做安全審查。
第三階段：雙層驗證
執行完成後，先跑 OpenSpec 的規範驗證：
/opsx:verify
檢查三個維度：所有 tasks.md 的 checkbox 是否都勾選了（Completeness），實現是否符合 proposal 中定義的目標（Correctness），代碼風格是否和 design.md 中的架構決策一致（Coherence）。
然後跑 OMC 的工程驗證：
ultrawork: 運行所有測試，確認無迴歸
檢查 BUILD、TEST、LINT 是否全部通過。
兩層驗證都綠燈後，合併 Delta 規範並歸檔：
/opsx:sync
/opsx:archive
圖 5：完整聯合工作流時序——規劃 → 執行 → 雙層驗證 → 歸檔
整個過程可以濃縮為：OpenSpec 負責把做什麼說清楚，OMC 負責把執行落實到位，雙層驗證確保結果靠譜。
你在項目中用過類似的方案嗎？比如用規範驅動開發，或者多 Agent 編排？歡迎在評論區聊聊你的經驗。
5. 經驗總結與最佳實踐
翻了一圈官方文檔和社區討論，整理出一些實用建議。
何時只用 OpenSpec
如果你的團隊已經在用成熟的 CI/CD 流水線和代碼審查流程，OpenSpec 單獨使用就夠了。它的價值在於給 AI 編碼助手提供上下文和約束，防止 AI 過度發揮。
另外一個重要場景：你的團隊使用的 AI 編碼工具不是 Claude Code。OpenSpec 支持 25+ 種 AI 工具，包括 Cursor、Windsurf、GitHub Copilot、Codex、Gemini CLI 等。OMC 目前只支持 Claude Code（雖然可以通過 tmux 調度 Codex 和 Gemini）。如果你的團隊工具棧比較雜，OpenSpec 是更通用的選擇。
從使用成本來看，OpenSpec 是純本地工具，安裝只需一條 npm 命令，不需要 API Key，不依賴特定平台。OMC 作為 Claude Code 的插件，需要先有 Claude Code 的訂閲。
何時引入 OMC
當項目複雜度上升，單個 AI 會話搞不定的時候，OMC 的價值就體現出來了。29 個專業 Agent 分工協作，opus 級別的模型做架構審查，haiku 級別的做代碼探索，既保證了質量又控制了成本。
特別適合這幾種場景：
大規模代碼重構：多個模塊需要同步修改，單會話的上下文窗口裝不下 多人協作的功能開發：需要 code review、security review 等多角色參與 嚴格質量把關：BUILD/TEST/LINT/ARCHITECT 四層驗證一個都不能少 長時間任務：ralph 模式的不完成不停止特性適合跑批處理式的開發任務
聯合使用的注意事項
說實話，兩個系統疊加會增加配置的複雜度。幾個坑需要提前知道：
OpenSpec 需要 Node.js 20.19.0+，環境版本要先確認 OMC 的 Team 模式需要啓用實驗性功能： CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1OpenSpec 的上下文注入有 50KB 大小限制，複雜項目要控制規範文件的篇幅 OMC 的 npm 包名是 oh-my-claude-sisyphus，不是oh-my-claudecode，別搜錯了OpenSpec 官方推薦使用高推理模型（如 Codex 5.5、Opus 4.7）來執行規劃任務，低配模型可能生成質量不夠的工件
還有一個容易忽略的點：兩個系統都通過 Skills 機制擴展，但 Skills 的目錄結構不完全相同。OpenSpec 的 Skills 在 .claude/skills/openspec-*/，OMC 的自定義技能在 .omc/skills/。不會衝突，但需要清楚哪個文件歸哪個系統管。
不同團隊規模的建議
個人開發者：OpenSpec 單獨使用足夠。輕量、通用、不挑工具。日常開發中用 /opsx:propose 把需求理清楚，再用你慣用的 AI 編碼助手執行就行。
2-5 人小團隊：OpenSpec + OMC 的 autopilot 模式。規範對齊 + 自動執行，性價比高。OpenSpec 解決大家想的不是同一件事的問題，OMC 解決執行質量不穩定的問題。
5 人以上團隊：OpenSpec + OMC 的 Team 模式。多 Agent 協作 + 雙層驗證，質量更有保障。OpenSpec 的 Delta 規範在多人協作時特別有用——每個人的變更都在獨立目錄裏，合併衝突的概率低。
總結
說到底，AI 輔助開發的瓶頸已經從AI 能不能寫代碼轉向了人怎麼和 AI 有效協作。純粹的 prompt engineering 解決不了系統性的問題——你不可能每次都把所有上下文和約束塞進一個 prompt 裏。
OpenSpec 用結構化的規範層解決了對齊的問題。OMC 用多智能體編排解決了執行的問題。兩者協同，讓從規劃到落地的整條鏈路不再是兩條平行線。
如果你正在用 AI 編程助手做複雜項目，建議先試試 OpenSpec 的 openspec init，感受一下規範驅動的開發流程。等項目的複雜度上來了，再把 OMC 加進來做編排和質量保證。
好啦，謝謝你觀看我的文章，如果喜歡可以點贊轉發給需要的朋友，我們下一期再見！敬請期待！