ECC：我為什麼把它看成 AI 代理工作流的底座，而不只是設定包

我一開始看 ECC（https://github.com/affaan-m/ECC）時，原本以為它只是另一個給 AI 編碼工具用的設定集合。讀完官方 README、安裝指南，還有 Hermes x ECC 的公開文件後，我的感受完全改變了：它不是把幾個 prompt、skills、hooks 疊在一起而已，而是把「代理人工作流」整理成一套可以複用、可以檢查、可以回復、也可以跨工具搬運的底層系統。

這也是我覺得它值得寫成文章的原因。很多人現在都在同時碰 Claude Code、Codex、Cursor、OpenCode，甚至還有 Gemini、Zed、GitHub Copilot。真正困難的，往往不是某一個工具會不會用，而是你能不能讓它們在不同環境裡維持一致的工作方式、相近的品質門檻，以及可持續的維護成本。ECC 想解的，就是這件事。

它解的不是「能不能做」，而是「能不能穩定重做」

如果把 AI 編碼工具當成一次性對話機器，那你很快就會遇到三個問題。

第一，設定會碎掉。你在 A 工具裡寫過的習慣、檢查步驟、上下文規則，到了 B 工具就不見了。每次重新調整，等於重新教育一次代理人。

第二，上下文會髒掉。工具越多、外掛越多、MCP 服務越多，你越容易把整個工作環境堆成一坨互相干擾的狀態。最常見的壞味道，不是功能太少，而是重複安裝、重複執行、重複載入。

第三，沒有治理層。你可能有 prompt、有技能、也有一些 automation，但缺少一個清楚的系統去說：這些東西誰負責、怎麼驗證、怎麼修復、怎麼升級、怎麼撤回。

ECC 的切入點很直接：它不是把 AI 代理當成「會講話的工具」，而是把它當成「需要治理的工作系統」。官方 README 甚至直接把它定位為 harness-native operator system for agentic work。這個描述很準，因為它背後的重點不是單點功能，而是整體運作方式。

我看到的四個關鍵設計

1. 它把 skills、agents、commands、hooks、rules、MCP 串成一個面

ECC 不是只押寶某一種機制。它同時整理了 skills、agents、commands、hooks、rules 與 MCP，讓不同層次的工作方式各自有位置：

skills：把重複工作流程包成可重用的方法
agents：把不同角色的工作分工制度化
commands：保留操作入口與遷移相容性
hooks：把檢查、修正與上下文控制掛到流程上
rules：把語言、框架與團隊規則拆成可選模組
MCP：把外部工具與資料源接進來，但又不把整個上下文炸掉

這種設計的好處是，你不用把所有東西都塞進單一設定檔。你可以選擇要哪一層、要多少、要不要 hooks、要不要完整安裝，這讓它比一般「prompt pack」更像一個真正的工作底座。

2. 它真的在處理跨 harness 的一致性

官方 README 明確寫到它支援 Codex、Claude Code、Cursor、OpenCode、Gemini、Zed、GitHub Copilot，而且 v2.0.0-rc.1 的公開說明還把 surface 對齊到 63 個 agents、249 個 skills、79 個 legacy command shims。這些數字本身不重要，重要的是它顯示 ECC 不是只為某一個編輯器或某一個 CLI 服務，而是想把相同的工作方法帶到不同 harness 裡。

如果你平常真的會在多個工具之間切換，這件事很有價值。因為你想保留的，通常不是某個工具的 UI，而是你腦中的工作標準：怎麼拆任務、怎麼驗證、怎麼紀錄、怎麼避免上下文污染、怎麼把一次性解法變成可複用流程。

3. 它不是「裝好就算了」，而是有明確的安裝邏輯與回復路徑

我很喜歡 ECC README 裡一個很務實的提醒：只選一條安裝路徑，不要疊加安裝方法。這聽起來很小，但其實很關鍵。很多複雜工作流壞掉，不是因為功能不夠，而是因為用戶自己把 plugin、manual install、rules 複製、hooks 安裝全部堆在一起，最後變成重複執行、重複載入、甚至完全不知道哪個版本在生效。

官方給的建議很明確：

claude --version
/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

如果你只想先試，不想把 hooks 一次全開，README 也給了最小化路徑：

./install.sh --profile minimal --target claude

如果你是想要更細的控制，或者你只想先把 rules、agents、commands、skills 拿進來，也可以走手動安裝。但重點是：不要插件安裝完又再跑 full installer。這不是什麼教條，而是避免重複與衝突的基本衛生習慣。

4. 它有狀態、有檢查，也有修復思維

真正讓 ECC 跟一般模板包拉開差距的，是它有一套狀態與修復思路。官方文件提到，你可以用像這樣的命令檢查已安裝內容：

node scripts/ecc.js list-installed
node scripts/ecc.js doctor
node scripts/ecc.js repair

另外，ecc status --markdown --write status.md 也能把目前狀態整理成可攜的交接檔。這代表它不是只想讓你「裝一次」，而是想讓你在後續維護、故障排查、團隊交接時，都有一個可被讀懂的狀態面。

對我來說，這是 ECC 最成熟的地方。因為一套 AI 代理系統如果不能被驗證、不能被修復、不能被交接，那它最後只會變成另一種脆弱的玩具。

我會怎麼開始用，才不會把它裝壞

如果是我自己要導入，我會照這個順序來。

第一步：先確認版本與前提

官方文件有寫，Claude Code plugin 需要 Claude Code CLI v2.1.0+。所以我會先確認版本，避免把問題誤判成安裝錯誤：

claude --version

第二步：只選一條路

如果我想要最省事、也最接近官方推薦，我會先走 plugin 路徑。這樣可以直接拿到 commands、agents、skills、hooks 的整合能力。

如果我只是想先觀察，不想一次導入太多東西，我會先用 minimal profile，或只複製 rules/common 加上一個我真的會用的語言／框架包。

第三步：先找對組件，再決定安裝多少

ECC 還提供查詢式的顧問流程，像這樣：

npx ecc consult "security reviews" --target claude

這很實用，因為它讓你先看預覽，再決定要不要真的裝。對於 production 場景，這種「先查、再裝、再驗證」的節奏，比盲目全裝來得安全很多。

第四步：如果你用 Codex，也要用官方同步腳本

README 對 Codex 也有完整支援，還提供同步腳本把 ECC assets 帶進 ~/.codex。這意味著 ECC 不是只照顧單一 CLI，而是真的在做跨 harness 的一致化。

這種專案適合誰

我會把 ECC 分成三種很適合的使用者。

第一種，是已經在多個 AI 編碼工具之間切換的人。你最需要的不是更多 prompt，而是同一套工作標準可以跟著你走。

第二種，是團隊裡已經開始把 AI 代理當工作夥伴，而不是聊天玩具的人。你需要的是可維護、可稽核、可回復的系統，不只是個人習慣。

第三種，是已經感受到 context 汙染、重複安裝、工具衝突的人。ECC 的價值，很多時候不是讓你變得更炫，而是讓你少踩很多坑。

如果你只是想要一個很輕的提示詞包，ECC 可能太重。如果你要的是一個可以長期演化的代理工作平台，那它就非常值得看。

我對 ECC 的結論

我現在會把 ECC 看成一種很務實的答案：當 AI 編碼工具越來越多、工作流越來越長、上下文越來越貴的時候，你需要的不是更多零散技巧，而是一套可以把方法論、安裝邏輯、記憶、護欄、驗證與跨平台一致性串起來的系統。

它當然不是萬靈丹，也不是「裝了就會自動寫出好程式」的神奇套件。但它很像一個成熟團隊早晚都會需要的東西：工作流的標準底座。

如果你最近也在同時使用 Claude Code、Codex、Cursor 或其他 harness，我會很認真建議你看一眼 ECC。它不是在賣一套更花俏的提示詞，而是在回答一個更底層的問題：我們能不能把 AI 代理變成可持續運作的工程系統？

參考資料

GitHub Repo：<https://github.com/affaan-m/ECC>
官方 README：<https://raw.githubusercontent.com/affaan-m/ECC/main/README.md>
Hermes x ECC Setup：<https://raw.githubusercontent.com/affaan-m/ECC/main/docs/HERMES-SETUP.md>
Cross-harness architecture：<https://github.com/affaan-m/ECC/blob/main/docs/architecture/cross-harness.md>