大部分 coding agent 出包的場景長得差不多：你在對話框打一段「幫我做這個……順便處理一下那個……」，agent 很有信心地生出一整包程式碼，檔案結構有模有樣，跑起來才發現它做的是另一件事。回頭翻對話紀錄想找是哪一句講錯，才發現需求從頭到尾只活在那幾段訊息裡，沒有第二個地方可以對照。
問題通常不是模型不會寫程式，是「要做什麼」這件事沒有被寫成一個可以檢查的東西。OpenSpec 就是針對這一段來的。
OpenSpec 想當的是規格層
它的自我描述是 lightweight and configurable framework for creating and managing software specifications：一個輕量、可配置的框架，用來建立和管理軟體規格。它的角色是疊在你原本的 coding agent 上面的一層：把想做的東西寫成 spec，讓團隊和 agent 在工作持續演進的時候還對得齊，幫你 refine requirements 把需求修清楚、validate 它描述的是不是對的東西、verify 實作有沒有符合規格。官網把這串收成一句話：build the right thing and build it right，先做對的事，再把事做對。
這種 spec 就是純 Markdown，落在專案裡的 `openspec/` 目錄。一次變更是一個 change 資料夾，裡面放 `proposal.md`、`specs/`、`design.md`、`tasks.md`；spec 裡寫的是一條條 requirement 加 scenario，沒有要先學的語法。官方 repo 自己就用 OpenSpec 在管，`specs/` 和進行中的 changes 都放在裡面，想看看實際長什麼樣，點進去就有。
一輪 change 走五個動作
一輪工作被拆成五個 `/opsx:` 指令：
- `/opsx:explore`：先摸問題、讀 codebase，把現況和選項攤開，還不急著寫程式。 - `/opsx:propose`：把討論收成 `proposal.md`、`specs/`、`design.md`、`tasks.md`，變成一包可實作的計畫。 - `/opsx:apply`：照著 spec 裡的 tasks 一項一項做。 - `/opsx:verify`：回頭確認寫出來的東西有沒有對上 spec。 - `/opsx:archive`：把做完的 change 歸檔、更新 spec，等下一輪。
這些檔案由 AI 草擬，人在任何程式碼被寫下之前先審過計畫。流程也沒有被綁成不能回頭的階梯，專案自己列的哲學是 fluid not rigid、iterative not waterfall、easy not complex，任何一份檔案隨時可以改，沒有卡死的 phase gate。順序常變的團隊應該懂這有多實際。
它怎麼讓 agent 不亂跑
Spec 進到 repo 之後，它就變成一個人和 agent 都讀得到、都能指著的東西。Agent 不用從一長串對話裡猜你到底要什麼，它讀 proposal 和 tasks；人也不用等程式碼生出來才發現方向錯了，因為 propose 階段產出的就是一份可以先審的計畫。工作演進的時候，要改的是這些檔案，不用再往聊天室補一句「喔對了那個也要」。
這件事在多人、多 repo 的專案上更明顯。README 裡有個還在 beta 的 Stores 設計，把 `openspec/` 目錄獨立成一個 repo，用 git push 分享，平台團隊持有 spec、產品團隊直接引用，每個 agent 讀到的是同一份來源，不會各自從自己的上下文重猜一遍。
GitHub repo 的一行說明是 Spec-driven development (SDD) for AI coding assistants，把規格驅動開發對準 AI coding assistant。放到 AI-native 的開發流程裡看：程式碼的產出變便宜之後，瓶頸移到「決定要做什麼」和「驗證做完的東西對不對」，spec 讓這兩件事有同一個東西可以對。
相容性上，OpenSpec 接的是你原本就在用的工具，用 slash command 把各家 coding agent 和 CLI 串起來，官方名單有數十個，Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI、OpenCode 都在裡面。同一個指令在不同工具的叫法會有點差異，Cursor 和 GitHub Copilot 可能寫成 `/opsx-propose`，Codex 是 `$openspec-propose`，底下跑的是同一套流程，讀的也是同一份 spec。專案以 MIT 授權釋出，是 TypeScript 寫的 CLI，站上標的版本是 v1.13.0。
數字要分清楚是誰說的
常被貼出來的那幾個數字，來源要分清楚。站方自報的有三個：68.0k GitHub stars、每兩秒就有一個新 spec 被建立、每月超過 265,000 位開發者使用。這些是官網自己的說法，讀的時候當成站方自報的數字就好。另一個可以自己查：2026-09-17 直接讀 GitHub API，這個 repo 是 68,584 顆星。
Agent 寫程式的速度只會愈來愈快，「先講好要做什麼」和「做完對得回來」的相對成本就愈來愈高。OpenSpec 沒有要發明新的開發方法論，它做的事很窄：把 spec 放回流程裡，變成人跟 agent 之間那個可以共同指著的檔案。它不會替你想清楚要什麼，方向模糊的話，spec 也只是把混亂排得整齊一點；方向清楚的時候，至少每個人和每個 agent 都看著同一份東西往前進。
想自己驗的人，第一個可以看的點是跑一次 `/opsx:propose` 之後，那份 spec 有沒有講中你心裡真正要做的那件事。有，這套流程就成立；沒有，星星再多也幫不上忙。