OpenSpec 裝了不等於用上：5 種最常見的用廢姿勢

作者：AI智聞說

日期：2026年6月5日上午8:35

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

OpenSpec 裝咗但用唔好？五種常見用廢姿勢，中兩條以上就係擺設

整理版摘要

OpenSpec 係 Fission-AI 開源嘅規範驅動開發框架，GitHub 上有 52,546 star，最新 v1.4.1。核心理念係喺 AI 寫 code 之前用一份行為契約講清楚「系統應該做啲乜」。但好多用戶裝完之後發現 AI 仲係唔跟規範走，原因係用錯咗方法。

作者歸納咗五種最常見嘅用廢姿勢：第一，將 spec.md 當 PRD 或實現文檔寫，塞滿咗庫名、類名同步驟；第二，apply 時發現 spec 錯咗都唔回頭改，硬係要 AI 湊出來；第三，AI 話 archive 咗但其實只係移咗文件，主 spec 冇更新；第四，裝完 OpenSpec 之後冇每個項目跑 openspec update，AI 完全唔知呢套規範存在；第五，apply 時唔委派子代理，主模型一個人扛曬所有 context，搞到越做越差。

總括而言，OpenSpec 嘅「可預測」唔係裝完 CLI 就自動有，而係要靠每日做好五件小事：寫行為契約、隨時改 spec、真 archive、跑 update、委派子代理。只要做齊，先可以真正發揮規範驅動開發嘅威力。

規範要寫行為契約，唔好寫實現細節；spec.md 出現庫名、類名或「先⋯⋯再⋯⋯」就代表用廢咗。
apply 中途發現 spec 錯咗要即刻改，spec 係流動嘅，唔係簽死嘅合同。
archive 唔係 AI 自己移文件夾，要用 openspec archive 命令先會更新主 spec。
每個項目要跑 openspec update 先可以令 AI 認得 OPSX 命令，裝完唔 update 等於冇裝。
apply 時要委派子代理執行任務，主模型只做決策同驗收，咁先可以慳 context 同保持質量。

值得記低

流程

OpenSpec 五項體檢腳本

貼到項目根目錄跑一次，檢查五種用廢姿勢：檢查 spec 有冇被 PRD 化、spec 中途有冇改過、archive 係咪真係跑咗、update 係咪跑過、apply 模板有冇要求委派。

整理重點

OpenSpec 係咩？點解成日裝完用唔到？

OpenSpec 係一個規範驅動開發框架，核心理念係喺 AI 寫 code 之前用一份規範講清楚「系統要做啲乜」。最新 v1.4.1 統一咗 OPSX 命令前綴，但好多用戶裝完之後發現 AI 仲係唔跟規範走。

規範係行為契約（behavior contract），唔係實現計劃。

作者歸納咗五種最常見嘅用廢姿勢，只要中兩條以上，OpenSpec 基本就係裝嚟當擺設。下面逐個拆解。

整理重點

姿勢一、二：Spec 當 PRD 寫，同 apply 唔改 Spec

第一種姿勢係打開 spec.md，寫滿「用 React 18 + Zustand 實現」或者「先建 users 表，再寫 service」。呢啲係 PRD 或者實現文檔嘅寫法，唔係行為契約。

1 錯誤版：「用 jsonwebtoken 庫實現 JWT 登錄」；正確版：「登錄成功後，系統必須返回一個 JWT token」。
2 規範要用 GIVEN / WHEN / THEN 格式寫場景，只描述外部可觀測行為。
3 自查信號：spec.md 出現 import、class、「先⋯⋯再⋯⋯」等字眼；用 grep 一搜就知有冇中招。

第二種姿勢係 apply 時發現 spec 漏咗細節，但唔改 spec 硬要 AI 湊出來。好多人心態係「propose 階段已經批准，spec 唔鬱得」，但 OpenSpec 嘅設計哲學係「fluid not rigid」——規範係流動嘅。

實現暴露 design 略偏 → UPDATE 現有 change；產品方向變咗 → 開新 change。

apply 中途隨時改 spec.md 同 design.md，OPSX 就係為邊寫邊調而設計。
如果改到 scope 完全唔同，就開新 change，唔好死磕。
自查信號：一次 change 走完 spec 文件從未改過——好可能係唔敢改，唔係寫得完美。用 git log 睇 spec.md 嘅 commit 歷史就知。

整理重點

姿勢三、四：冇真 Archive 同冇跑 Update

第三種姿勢係 AI 話 archive 咗，但 changes/ 文件夾仲喺度，主 spec 冇更新。OpenSpec 嘅 archive 命令係要將 change 入面嘅 delta（ADDED/MODIFIED/REMOVED）翻譯返去 openspec/specs/，AI 自己移文件係冇用嘅。

第四種姿勢係裝完 OpenSpec 之後冇每個項目跑 openspec update。好多 UX 以為裝一次就全世界用得，但 OpenSpec 要喺每個項目生成 AI 入口文件（skill 同 slash 命令模板），先可以令 AI 認得 OPSX 命令。

openspec update 係每個項目都要跑嘅命令，用嚟生成或刷新 AI skill 入口。

項目首次接入：openspec init → openspec update。
團隊成員 clone 項目後第一步就跑 openspec update。
升級 OpenSpec 包之後要喺每個項目再跑一次。
穩妥做法：將 openspec update 加落 project 嘅 postinstall 腳本。
自查：睇 .claude/skills/ 或 .codex/skills/ 下有冇 openspec skill 檔案，冇就係冇 update。

整理重點

姿勢五：唔委派子代理，主模型扛曬所有 Context

第五種姿勢係 apply 時主模型一個人由頭做到尾，唔委派子代理。tasks.md 五個任務，做到第三個 context 就食一大半，後面質量明顯下降。

主模型只應該做決策同驗收，執行細節交俾子代理。

點樣改？揾返對應 AI 工具嘅 apply 命令模板（例如 Claude Code 係 .claude/commands/opsx/apply.md），將「sequentially work through tasks」改成強制委派。自查信號：apply 完之後用 /cost 或 /context 睇主模型剩幾多 context，如果已經食咗一大半，就代表委派唔夠。

整理重點

點樣一次過檢查自己中咗幾條？

文章最後俾咗一個五項體檢腳本，貼到項目根目錄跑一次，就知自己中咗邊啲用廢姿勢。下面係腳本內容：

OpenSpec 五項體檢腳本 bash

echo "=== 1. spec 有冇被 PRD 化 ==="
grep -rE "import |class |function |先.*再" openspec/specs/ 2>/dev/null | head -5
echo "=== 2. spec 中途有冇改過 ==="
git log --oneline --all -- "openspec/changes/*/spec.md" | head -5
echo "=== 3. archive 係咪真係跑咗 ==="
echo "openspec list 行數：$(openspec list 2>/dev/null | wc -l)"
echo "changes/ 文件夾數：$(ls openspec/changes/ 2>/dev/null | wc -l)"
echo "=== 4. update 係咪跑過（按你用嘅 AI 工具睇對應目錄） ==="
for dir in .claude/skills .codex/skills .cursor/skills; do
  if [ -d "$dir" ]; then
    ls "$dir" 2>/dev/null | grep openspec && echo "  ↑ 喺 $dir 找到" \
      || echo "  $dir 存在但冇 openspec skill"
  fi
done
echo "=== 5. apply 模板有冇要求委派（以 Claude Code 為例） ==="
tmpl=".claude/commands/opsx/apply.md"
if [ ! -f "$tmpl" ]; then
  echo "$tmpl 唔存在 —— 先跑 openspec update"
elif grep -q "subagent\|delegate" "$tmpl"; then
  echo "已委派"
else
  echo "未委派"
fi

五項檢查跑完，邊條冇過就係你目前嘅用廢姿勢。

記住：OpenSpec 嘅「可預測」係靠每日做好五件小事得返嚟，唔係裝完就自動有。

OpenSpec 現在 GitHub 上 52,546 star，6 月初剛發了 v1.4.1。但裝完跑兩三次發現「AI 還是沒按規範走」的人不少。歸納下來就 5 種用法，每一種官方都明確說過別這麼幹。

寫在前面

OpenSpec 是 Fission-AI 開源的 SDD（Spec-Driven Development，規範驅動開發）框架，核心理念是在 AI 寫代碼之前先用一份規範把「系統該做什麼」說清楚。2026 年 6 月 1 日發了 v1.4.0，6 月 3 日跟了一個修復版 v1.4.1。

主推的工作流半年裏悄悄換了一遍：從老的 /openspec:proposal 切到了 OPSX —— /opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive。 OPSX 是 v1.4 起統一的命令前綴（產品命名，不是縮寫），老的 /openspec:* 還能用，但官方已經標成 legacy（舊版）。

「規範驅動開發」這件事，核心是把規範寫成行為契約——用「系統在什麼輸入下必須給出什麼輸出」的方式描述需求，跟「先做 A 再做 B」那種實現步驟完全是兩件事。這個詞後面會反覆出現，先記住一句話：行為契約關心「外部能觀察到什麼」，不關心「內部怎麼做」。

下面這 5 種姿勢，只要中了兩條以上，OpenSpec 基本就是裝着當擺設。

一、把 spec.md 當 PRD 或實現文檔寫

最常見的第一種用廢姿勢：打開 spec.md，裏面寫滿「使用 React 18 + Zustand 實現」「先建 users 表，再寫 UserService，最後掛路由」。

更糟一點的版本是直接把產品需求文檔複製粘貼進去：「用戶希望看到一個炫酷的暗黑模式，主色調用深灰偏藍……」。

會這麼寫，是因為大家寫 PRD 和寫實現的肌肉記憶太強——以為 spec 就該詳細到能照着寫代碼。

但 OpenSpec 官方文檔 concepts.md 第一段就把這件事講死了：

規範是行為契約（behavior contract），不是實現計劃。
spec 裏要避免：內部類/函數名 · 庫或框架選型 · 一步步實現細節 · 詳細執行計劃——這些應該放在 design.md 或 tasks.md。

代價很直接：

把庫名和實現步驟寫進 spec，重構一次（比如從 Zustand 換 Jotai）就立刻過時；AI 下一次讀 spec 時，分不清「這是行為要求還是歷史實現」；spec、design、tasks 三個產物的邊界被攪爛，開新 change 時基線全是錯的。

對照一下兩種寫法的差別：

維度	錯誤版（PRD 風）	正確版（行為契約風）
形式	「實現 JWT 登錄，用 jsonwebtoken 庫」	「登錄成功後，系統必須返回一個 JWT token」
細節	「先建表 → 寫 service → 掛路由」	用 GIVEN / WHEN / THEN（假設/當/則）三段式寫場景
落點	把設計、實現、需求混一起	只描述外部可觀測的行為

OpenSpec 官方給的標準模板長這樣：

### Requirement: User Authentication

The system SHALL issue a JWT token upon successful login.

#### Scenario: Valid credentials

- GIVEN a user with valid credentials

- WHEN the user submits login form

- THEN a JWT token is returned

這裏的 SHALL 來自 RFC 2119，是一組寫規範用的強弱詞：MUST/SHALL 表示絕對要求，SHOULD 表示推薦（但允許例外），MAY 表示可選。

關鍵不在於強行用英文寫 spec。中文裏寫「登錄成功後，系統必須返回一個 JWT token」也算合格的行為契約，重點是這句話能被翻譯成一個測試。

自查信號很簡單：spec.md 裏出現具體庫名、類名、或者「先……再……」這種動詞步驟——大概率寫廢了。

立刻驗證：在項目根目錄跑一行 grep——

grep -rE "import |class |function |先.*再|步驟" openspec/specs/

命中越多，說明被實現細節污染得越嚴重。

怎麼改：spec 只寫「系統必須做什麼」，技術選型挪到 design.md，具體步驟挪到 tasks.md。三個產物各管一塊，互不串味。

二、apply 時發現 spec 錯也不回頭改，硬着頭皮實現

第二種用廢姿勢出現在 apply 階段。

典型場景是：propose 階段寫完 spec 看着挺好，apply 跑到一半，AI 生成的代碼不對勁，回頭一看才發現 spec 漏了關鍵細節。

這時候多數人不知道該不該改 spec，硬讓 AI 湊出來。

GitHub issue #684 就是用戶原原本本提出這個困惑：

跑 /opsx-apply 之前看所有 spec 文件（proposal.md、design.md、spec.md、task.md）都還行。但 apply 幾個任務後發現生成的代碼不對，因為細節不夠清楚。這時候要往 spec 里加內容或更新，請問有什麼推薦做法或標準流程嗎？

這條 issue 拿到了 14 個用戶的反饋支持（原帖裏寫的 /opsx-apply 是用戶手誤，官方語法是 /opsx:apply 帶冒號），說明很多人卡在同一個地方。

根因是瀑布思維：propose 階段已經批准 → spec 就被當成簽字蓋章的合同，不能動。

但 OpenSpec 的設計哲學恰好相反。opsx.md 裏有一句立場清晰的話「fluid not rigid」（規範是流動的，不是死的），同一份文檔裏也給了明確的決策：

實現暴露 design 略偏（Implementation reveals the design was slightly off）→ UPDATE 現有 change
Update preserves context. New change provides clarity.

代價是：spec 和實際實現脱節，下次新 change 從「錯的基線」出發；AI 看到的 spec 和代碼對不上，越往後越亂套；違背 OpenSpec 最根本的「iterative not waterfall」（迭代而非瀑布）理念。

怎麼改：

apply 中途隨時回頭改 spec.md 和 design.md，OPSX 就是為這種「邊寫邊調」設計的。

但萬一改着改着發現 scope（範圍）變得跟原來不是一回事了，就該開新 change，不是死磕原來的。opsx.md 給了一張實用的決策表：

判斷維度	走 update（改當前 change）	開新 change
目的	同一件事的細化	完全不同的工作
範圍交疊	跟原 change 重合不止一半	跟原 change 重合不到一半
完成度	不改就「做不完」	原 change 可以獨立完成，新工作單獨立項
故事連貫性	update 鏈條講得通	強行 update 反而讓歷史更亂

一句話總結：實現暴露 design 略偏 → update；產品方向變了 → 開新 change。

實操上，apply 完之後必跑一次 /opsx:sync，把 spec 和實現真正對齊。

自查信號：apply 一次 change 走完，spec 文件一次都沒回頭改過——大概率不是 spec 寫得完美，是不敢改。

立刻驗證：用 git 查這次 change 提交裏有沒有 spec.md 的改動——

git log --oneline --follow openspec/changes/<change-name>/spec.md

只有一次「初次創建」的 commit，沒有後續修改，就符合這一種用廢姿勢。

三、AI 跑完不真的 archive，change 全堆在 changes/

第三種用廢姿勢更隱蔽：tasks.md 裏五個任務都打勾了，AI 說「已歸檔」，但 openspec/changes/ 裏這個 change 還在；openspec/specs/ 裏對應模塊的規範沒更新。

GitHub issue #863 把這件事講得很清楚（拿到 15 個用戶反饋支持）：

OpenSpec 官方 CLI 把 openspec archive 定位成歸檔 change 和同步規範的標準命令。但自動生成的 AI 命令模板裏，/opsx:archive 讓大模型「手動移文件」（read/write/mv），並沒有真的調用 openspec archive。

也就是說：AI 以為自己 archive 了，實際只做了文件移動。

這裏要解釋一下機制。每個 change 文件夾裏其實是一份「改動清單」（OpenSpec 官方叫 delta，標着 ADDED、MODIFIED、REMOVED 三種動作），不是完整規範。必須經過 openspec archive 跑一遍，才會被翻譯成主 spec 的真實增刪改，寫回 openspec/specs/。AI 自己挪文件夾，主 spec 就永遠停留在「這次 change 沒發生」的狀態，下次新 change 從過時的基線出發，整套規範驅動開發退化回普通的「帶文件夾的 todo 列表」。

怎麼改：

每次 apply 完成後，人工跑一次完整的 archive 命令，而不是隻讓 AI 跑 /opsx:archive：

openspec archive <change-name> --yes

跑完後用 openspec list 驗證——結果應該只剩下還在進行的 change，已經做完的不能再出現在列表裏。如果以前已經堆了一堆沒真歸檔的 change，OPSX 在 v1.x 加了 /opsx:bulk-archive 專門清積壓。

如果想更進一步在 archive 前先抓一次錯，可以加一步 /opsx:verify —— OPSX 擴展 profile 裏的產物校驗命令，專門檢查 change 文件夾裏的 delta 是否合規、tasks 是否真的全打勾，跟前面提到的「每次 apply 完做 sync」是同一類把關動作。

團隊協作時，把「archive 後 specs 已更新」當成一條合併前必檢項；個人項目可以在每次提交時人工瞄一眼 openspec/specs/ 有沒有變動。AI 自動歸檔不靠譜，得有人盯着這一步。

自查信號：openspec/changes/ 目錄裏堆了好幾個已經標記完成但沒歸檔的 change → archive 流程肯定斷了。

立刻驗證：

openspec list # 列出所有 change

ls openspec/changes/ | wc -l             # 文件夾實際數量

openspec list 報告的數量 ≠ 文件夾數量，就說明有 change 嘴上歸檔了，實際還堵在 changes/。

四、裝完沒跑 openspec update，AI 入口裏沒接進去

第四種姿勢是裝完就以為完事。

npm install -g @fission-ai/openspec 跑完，OpenSpec CLI 裝上了。但打開項目一看，.claude/skills/ 目錄是空的，或者只有半年前老版本的 skill。AI 完全不知道這套規範存在，照樣自由發揮。（skill 是 AI 工具加載的能力包——一組寫在 markdown 裏的指令，告訴 AI「碰到 OpenSpec 這種場景該走什麼流程」。沒有 skill，AI 就看不到 OpenSpec 的存在，跟你沒裝是一個效果。）

OpenSpec README 的「Updating」一節明確寫了：

在每個項目裏跑這條命令，重新生成 AI 指引、確保最新的 slash 命令處於激活狀態：

openspec update

openspec update 這一步重要的原因，是 OpenSpec 的 AI 入口（每個工具下面的 skill 文件夾和 slash 命令模板）是按項目本地生成的，不是裝一次走天下。OpenSpec 支持十幾個 AI 工具——Claude Code、Cursor、Codex、Gemini CLI、Kimi CLI 等等——每個工具對應一套獨立的本地文件，全部要靠 update 命令重新生成。CLI 升級後命令模板格式可能變了，但本地 skill 文件不會自己改，必須手動 update 一次。

這一步常被跳過，背後其實是同一個誤解——以為 OpenSpec 是裝一次走天下的全局工具。具體表現有三種：忘了它要在每個項目裏生成 AI 入口文件；跟着舊教程跑而舊教程沒提 update；升級 OpenSpec 包後沒重新 update，skill 還停留在老版本。

GitHub issue #890 拿到了 18 個用戶反饋支持，是「升級後沒 update」的典型例子：codex-cli v0.117.0 升級後，/opsx:* 命令直接不識別。根因就是 OpenSpec 升級到 v1.4.x 後，項目裏的 skill 還是舊版本，沒跑 update 把新 skill 註冊進去。

代價：裝了等於沒裝；團隊成員 clone 項目後跑代碼，AI 不認識 /opsx:* 命令，code review 時誰也說不清「為什麼我這邊能跑你那邊不能」；升級 OpenSpec 包之後老 skill 跟新 CLI 不匹配，命令直接報錯。

怎麼改：

每個項目首次接入跑兩條命令：

openspec init # 初始化 openspec/ 目錄

openspec update    # 生成或刷新 AI skill 入口

團隊成員 clone 項目後，第一步就跑 openspec update。升級 OpenSpec 包之後，在每個用到 OpenSpec 的項目裏都再跑一次。

更穩妥的做法是把 openspec update 加進項目的 postinstall 腳本——npm install 跑完自動 update，減少人為忘記。

自查信號：項目裏 .claude/skills/openspec-* 或 .codex/skills/openspec-* 目錄不存在或為空——沒接進去。

立刻驗證（實際目錄路徑以你使用的 AI 工具為準）：

ls -la .claude/skills/ | grep openspec   # Claude Code 用戶

ls -la .codex/skills/ | grep openspec    # Codex 用戶

沒有匹配項，或者只看到幾個月前的文件，立刻跑一次 openspec update。

五、apply 時不委派子代理，主模型扛所有 context

最後一種姿勢屬於「日常用得多了之後才會撞上」的進階坑。前面 4 條都沒中招的人也別跳過這一節——這條不是用廢的反面，而是讓 OpenSpec 跑得更順的額外收益。

可以這樣理解：apply 階段讓主模型一個人幹所有事，相當於讓項目經理同時去擰每顆螺絲、跑每個測試。能跑，但越到後面越沒精力管全局。

場景是這樣：跑 /opsx:apply，主模型從頭到尾自己一個人寫。tasks.md 裏五個任務，做到第三個的時候，主模型的工作記憶區（專業說法叫 context，一次能裝的內容有上限）已經吃掉一大半。再往後任務質量肉眼可見地下降，AI 開始遺忘前面定下的決策。

根因是同一件事：主模型幹了不該它乾的活。默認的 apply 模板寫的是「sequentially work through tasks」，沒強制委派；大家又想着用最強的模型一路幹到底質量最高，結果主模型既要做決策、又要讀自己生成的所有代碼和 spec 改動，context 一下子被吃滿。

GitHub issue #572（14 個用戶反饋支持）裏有用戶給出了實測改法：

把 apply 命令第二步裏那句「sequentially work through tasks, keeping edits minimal」加上一個硬限制——任務必須通過委派給 @general subagent（子代理）去執行，主模型自己不動手。

改完之後，整個流程跑下來只用了 30% 的 context，留出大量空間做後續調試和修改。

這跟 Claude Code 最近主推的「main agent + subagents」編排是一脈相承的——核心模型負責決策和審計，子代理（subagent）負責執行。

代價：單個 change 越長，質量下降越快；context 滿了之後 AI 開始省着回答，遺漏邊界條件；主模型在執行細節上把寶貴的 context 全佔滿，真正需要它判斷的地方反而沒空間了。

怎麼改：

修改項目裏的 apply 命令模板，在 step 2 里加上「by delegating to a general-purpose subagent」（強制委派給通用子代理）。具體路徑根據 AI 工具不同而異——Claude Code 用戶去找 .claude/commands/opsx/apply.md，其他工具的路徑可以在項目的 openspec/ 目錄下找到對應的命令模板文件。

讓主模型只做三件事：讀 proposal/spec/design 拿全貌、把任務分發給子代理、驗收回來的結果。

委派子代理的另一個好處是 context 隔離：每個子代理跑完任務就退出，它讀過的代碼、查過的文檔不會進主模型的 context。主模型最終只接收一句「任務完成 + 改了哪幾個文件」的彙報。單個 change 跑下來，主模型仍然有足夠餘量處理驗收、回頭改 spec、跨任務一致性檢查。

模型搭配：主模型用當下最強的（Opus 4.x、Codex 同級），子代理用相對便宜的（Sonnet 4.x）。這樣既保留了主模型的判斷力，又省下了執行環節的成本。

自查信號：apply 一次 change 跑完，主模型 context 明顯比 issue #572 那位用戶報告的「30%」高出一截（比如已經吃掉一大半）——沒委派或委派不充分。

立刻驗證：在 Claude Code 裏打開 /cost 或 /context，看 apply 跑完後主模型還剩多少餘量。如果留給後續驗收、改 spec 的空間已經不舒服，就該回去改 apply 模板。

這 5 種姿勢，對照一下自己佔了幾條

姿勢	自查信號	一句話正解
1. spec 當 PRD 寫	spec.md 出現具體庫名、類名、「先……再……」	spec 只寫「系統必須做什麼」，實現挪到 design.md
2. apply 中不改 spec	apply 一次都沒回頭改過 spec	apply 時隨時改 spec，spec 是活的
3. 沒真的 archive	`changes/` 裏堆了好幾個已完成但沒歸檔	人工跑 `openspec archive <name> --yes` 驗證
4. 沒跑 update	`.claude/skills/openspec-*` 為空	每個項目跑一次 `openspec update`
5. 不委派子代理	apply 一次主模型 context 吃掉一大半	改 apply 模板，強制把任務委派給子代理

如果想三分鐘一次性體檢完，把下面這段貼到項目根目錄跑一遍：

echo "=== 1. spec 有沒有被 PRD 化 ==="

grep -rE "import |class |function |先.*再" openspec/specs/ 2>/dev/null | head -5

echo "=== 2. spec 中途有沒有改過 ==="

git log --oneline --all -- "openspec/changes/*/spec.md" | head -5

echo "=== 3. archive 是否真的跑了 ==="

echo "openspec list 行數：$(openspec list 2>/dev/null | wc -l)"

echo "changes/ 文件夾數：$(ls openspec/changes/ 2>/dev/null | wc -l)"

echo "=== 4. update 是否跑過（按你用的 AI 工具看對應目錄） ==="

for dir in .claude/skills .codex/skills .cursor/skills; do

  if [ -d "$dir" ]; then

    ls "$dir" 2>/dev/null | grep openspec && echo "  ↑ 在 $dir 找到" \

      || echo "  $dir 存在但沒有 openspec skill"

fi

done

echo "=== 5. apply 模板有沒有要求委派（以 Claude Code 為例） ==="

tmpl=".claude/commands/opsx/apply.md"

if [ ! -f "$tmpl" ]; then

  echo "$tmpl 不存在 —— 先跑 openspec update"

elif grep -q "subagent\|delegate" "$tmpl"; then

  echo "已委派"

else

  echo "未委派"

fi

五項檢查跑完，哪一條沒過哪一條就是你目前的用廢姿勢。

寫在最後

OpenSpec 在 README 裏把自己定位成「讓 AI 編程更可預測的規範框架」。但「可預測」不是裝完 CLI 就自動獲得的——它來自上面五件每天都要做對的小事