重點先講：ECC 可以幫 AI 寫程式建立固定工作流程，但安裝後仍需要人工驗收。先確認三件事：安裝範圍、測試結果、回復方法。這篇用三步驟示範如何安全導入。
最後更新：2026 年 10 月 24 日
資料截點：2026-10-24 08:00（台北時間）
本文依 ECC 官方 GitHub 文件整理，屬安裝與工程方法教學，並非本站已完成的軟體實測。版本、安裝方式與支援程度可能隨專案更新。
ECC 是什麼？能改善 AI 寫程式的哪些問題？
想像一個常見情況：你請 AI 修改網站的登入功能。AI 很快交出程式碼，也說任務完成了。結果新功能看似正常，原本的密碼重設流程卻無法使用。
問題在於，AI 完成修改，不代表整個專案已經通過驗收。開發工作還包含閱讀現有設計、確認需求、測試相關功能、審查修改範圍，以及保存必要紀錄。
ECC，也就是 Everything Claude Code，試圖把這些經常被忽略的工作，整理成可重複使用的 Agent 工程流程。
它由 affaan-m 維護，官方 GitHub 倉庫位於 affaan-m/ECC，採 MIT 開源授權。
ECC 提供的主要內容包括：
- Skills：把特定工作的步驟、規範與檢查方式整理成可供 Agent 使用的技能。
- Agents：針對研究、規劃、程式修改、測試及審查等任務提供不同角色設定。
- Rules：讓開發工具在工作時參照事先制定的工程規範。
- Hooks：在支援的平台上，於指定操作前後觸發檢查或其他程式動作。
- Memory：提供保存與取回工作經驗的機制，協助後續任務參考。
- AgentShield：提供針對 Agent 配置與安全風險的掃描能力。
其中最大的差異是：Rules 和 Skills 主要提供工作指引；Hooks 和部分工具才會真正執行程式。即使寫了規範，也不代表每一項限制都能強制阻擋。
ECC 跟一般 Agent Skills 有什麼不同？
如果已經替 Claude Code、Codex 或 Cursor 安裝大量 Skills，可能會覺得 ECC 只是另一套技能集合。實際上，它的定位更接近開發工程工具組合，除了技能，也納入規劃、驗收、記憶及安全配置。
| 比較項目 | 一般獨立 Skill | ECC |
|---|---|---|
| 主要目的 | 完成指定工作 | 建立可重複的工程工作方法 |
| 流程規範 | 依每份 Skill 設計 | 包含 Rules、Agents 與 Skills 等組件 |
| 自動檢查 | 不一定提供 | 部分整合提供 Hooks 與檢查工具 |
| 任務記憶 | 視工具而定 | 提供記憶相關組件 |
| 跨工具支援 | 視格式與平台而定 | 有多種平台整合，但能力不完全相同 |
| 安裝風險 | 取決於內容與權限 | 需額外檢查配置、Hooks 與整合功能 |
這張表比較的是工具設計，不是實測成績。ECC 並沒有因此被證實在所有專案都比獨立 Skills 更準確或更省時間。
ECC 支援哪些 AI Coding Agent？
依本次讀取的官方 README，ECC 目前以 Claude Code 為主要整合環境，另外提供 Codex 原生插件，以及其他開發工具的整合路徑。
必須注意：在某個工具上可以讀取 ECC 的 Skill，不代表它能執行所有 ECC Hooks。
| 工具 | 官方說明中的支援形式 | 導入前重點 |
|---|---|---|
| Claude Code | 原生插件及引導式安裝 | 確認安裝範圍、Hook profile、現有插件 |
| Codex | 原生 marketplace 插件及專案配置 | 確認 Hook 信任設定與 Sandbox 權限 |
| Cursor | 整合配置與轉接機制 | 確認實際支援的事件與規則 |
| OpenCode | 插件整合 | 確認目前版本與事件相容性 |
| 其他工具 | 依各工具提供不同程度的支援 | 以官方支援矩陣逐項確認 |
若主要使用 Codex，不宜直接把 Claude Code 專用的 Hook 設定複製過去。兩者有不同的權限與執行方式。
第一步：ECC 安裝前應該檢查什麼？
最安全的導入方式，是先在測試專案評估需要哪些能力，再決定是否安裝到正式工作環境。
依官方 ECC 2.2 文件，引導式安裝工具需要 Node.js 18 或更新版本。Claude Code 插件設定也需要 Git，以及可用的 Claude Code 2.1 或更新版本。
在 Windows PowerShell 或相應的終端機中，可先執行以下唯讀檢查：
node --version
git --version
claude --version上述命令只檢查目前環境是否能找到對應工具，不會安裝 ECC。若只使用 Codex，應改依 Codex 的安裝前置條件確認，不必把 Claude Code 當成必裝項目。
正式安裝前，還需要完成以下確認：
- 將目前專案的工作檔案與設定檔建立可靠備份，確認版本控制狀態。
- 檢查現有 Skills、Hooks、插件及 MCP 設定，避免重複安裝或發生命名衝突。
- 閱讀官方安裝器的來源與將要修改的範圍，尤其是會執行命令的 Hooks。
- 先選擇測試專案，不直接使用具有正式部署權限的工作環境。
- 確認哪些操作需要人工核准，並保持最小必要權限。
若目前的 AI 開發環境運作正常，但沒有測試與回復機制，應先補足既有流程。增加更多工具本身，不能取代這些基礎工作。
第二步：ECC 怎麼安裝到 Claude Code 或 Codex？
官方提供不同安裝方式。以下是依本次 README 整理的操作範例，並非本站已執行的安裝紀錄。
Claude Code 的引導式安裝
官方 ECC 2.2.3 文件列出以下指令：
npx ecc-universal@2.2.3 setup執行前應先核對 npm 套件來源及版本。引導程序會協助選擇安裝範圍與 Hook 設定；不同範圍可能影響其他專案。
初次使用時，應逐項閱讀安裝器列出的設定變更，不要直接接受所有預設選項。
安裝完成後，可開啟新的 Claude Code 工作階段，依官方說明用插件清單確認 ECC 是否啟用。
注意：官方同時提供原生插件安裝方式，但不要在同一套 Claude Code 環境疊加多種完整安裝途徑，以免出現重複設定。
Codex 的原生插件安裝
官方文件列出的 Codex 安裝流程為：
codex plugin marketplace add affaan-m/ECC
codex plugin add ecc@ecc
codex plugin list --json前兩行會修改插件環境，因此只應在核對來源、確認 Codex 支援這些命令後，由使用者於授權環境執行；第三行用於查看插件清單。
官方也提供下列較保守的引導流程預覽指令：
npx ecc-universal@2.2.3 install --guided --harness codex --dry-rundry-run 的目的，是先預覽相關操作；仍須留意執行安裝器本身的供應鏈風險，不能把 dry-run 視為完全隔離的安全沙盒。
Codex 的原生 Hooks 有獨立的信任核准機制。啟用插件後，仍需逐項確認權限，不能認定安裝 ECC 就已啟用所有檢查。
若先前已使用舊版設定同步方式，應先查清既有安裝狀態，避免再疊加 marketplace 插件。
第三步：如何驗收 ECC 是否真的有幫助？
這一步比安裝更重要。我會用一個簡單、可重現的示範任務，檢查工具能否協助完成完整的工作循環。
以下是一份可由讀者自行執行的驗收設計，不代表本站已取得任何測試分數。
測試情境：修正簡單函式的邊界錯誤
建立一個新的測試專案，準備含有刻意錯誤的函式。例如，一個負責判斷折扣資格的函式，將符合資格的邊界值判成不符合。
交給 Agent 的任務可以寫成：
請先閱讀程式與現有測試，確認錯誤條件，再提出最小修改方案。修改後執行相關測試，列出實際變更檔案、測試結果及仍未確認的風險。未經核准，不要修改其他功能。
驗收時，不應只看 Agent 最後說了什麼，而要檢查實際檔案與測試輸出。
| 驗收項目 | 通過條件 | 失敗時怎麼處理 |
|---|---|---|
| 修改範圍 | 只修改授權的測試檔案與程式 | 檢查差異，撤回不必要修改 |
| 測試執行 | 有可檢查的實際測試結果 | 確認測試工具是否可執行 |
| 邊界條件 | 錯誤案例修正且相關回歸測試通過 | 補充測試，重新定位問題 |
| 安全性 | 沒有讀取敏感資料或使用未核准權限 | 停止任務並檢查操作紀錄 |
| 交付紀錄 | 能指出修改檔案與驗收證據 | 要求提供具體差異與測試輸出 |
若需要比較 ECC 的實際效果，可以在同一個測試環境中，以有 ECC 與無 ECC 的配置分別完成等價任務，記錄完成率、測試結果、人工修正次數與耗時。兩邊應固定模型及主要環境條件，否則很難判斷差異是否來自 ECC。
如果 ECC 安裝後出問題，怎麼回復？
最容易被忽略的是回復流程。安裝器可能修改插件、規則、Hooks 或其他開發配置。若之前沒有備份，事後就不容易分辨哪些內容原本存在。
可採取以下順序：
- 停止新的 Agent 修改任務，保留錯誤訊息與必要的非敏感診斷資訊。
- 查看目前安裝的 ECC 組件，判斷是原生插件、引導式安裝或舊版同步配置。
- 先閱讀對應版本的官方解除安裝或修復文件，不隨意手動刪除共用設定。
- 按照原本確認過的備份還原必要設定，再檢查其他插件是否受影響。
- 重新執行安裝前的測試，確認環境恢復正常後才考慮再次導入。
官方文件特別提醒，不同安裝方式不能任意疊加。已存在多層 ECC 安裝時，應先確認各層的擁有權及解除方式。
另外，版本控制能協助回復專案程式碼，但不一定涵蓋使用者層級的開發工具設定。因此安裝前需要另外備份會被修改的配置。
ECC 是免費的嗎？需要訂閱才可以使用？
官方 ECC 倉庫採 MIT 授權，開源部分可依授權條件使用；官方也另外提供 ECC Pro 等託管服務。
這不表示使用 ECC 就沒有其他成本。執行 Claude Code、Codex、模型 API、雲端服務或其他整合工具，可能仍有各自的使用費用與限制。
若只想了解 ECC 的工程方法，可以先閱讀公開的 Skills、Rules 與文件，不一定需要安裝完整工具組合。
若要評估付費託管服務，則必須另外確認官方方案及當期條款，不能把開源倉庫的授權等同於所有服務免費。
ECC 適合誰？哪些人可以先不用？
| 使用者 | 適合程度 | 理由 |
|---|---|---|
| 每天用 Agent 修改程式的開發者 | 可以優先評估 | 經常需要規劃、測試與交付紀錄 |
| 管理多個 AI 開發任務的小型團隊 | 適合先做試點 | 可評估統一流程是否減少協作錯誤 |
| 使用 Codex 的開發者 | 先確認原生整合 | 需處理插件、權限與 Hook 差異 |
| 完全不會寫程式的新手 | 先學基礎操作 | 完整工程工具組合可能增加理解成本 |
| 只用 AI 寫文章或整理資料的人 | 通常不必完整安裝 | 未必需要工程級開發流程 |
不會寫程式也可以先使用 ECC 的公開文件理解工作方法，但安裝 Hooks、MCP 與開發環境整合仍涉及一定技術門檻。
如果不使用 ECC，還有哪些替代方式？
如果現有工作流程已相當穩定，不一定要加入新的大型工具組合。
- 原生 Agent Skills：只為特定任務建立操作規範，適合需求明確、流程簡單的工作。
- 專案規範檔：例如 Codex 使用的 AGENTS.md，可用來傳達專案指示，但不能單獨代替可執行的測試。
- 自動化測試與 CI：由既有測試工具與持續整合程序執行客觀驗收，減少完全依靠 AI 自我報告。
- 人工審查：對重要部署、資料存取權限及不可逆操作，仍保留獨立核准。
這些方式也可以和 ECC 配合。比較重點應該是增加了哪些實際驗收能力，以及是否帶來可以量測的改善。
ECC 常見問題 FAQ
ECC 可以讓 Claude Code 自動寫對所有程式嗎？
不可以。ECC 提供流程及工程工具，但沒有證據顯示它能消除所有程式錯誤。測試、審查和人員核准仍然重要。
ECC 可以搭配 Codex 使用嗎？
可以。官方提供 Codex 原生插件及其他配置路徑，但 Hooks 和整合功能與 Claude Code 不完全相同，需要確認支援範圍。
安裝 ECC 會覆蓋原本設定嗎？
實際修改取決於安裝方式、目標工具與目前配置。操作前應先檢查預覽與備份，不能假設所有設定都會自動保留。
ECC 適合正式產品直接導入嗎？
正式導入前應確認安全性、相容性、修改範圍及回復能力，先用隔離的測試專案驗證。不要把開源工具存在 GitHub 視為正式環境的安全保證。
安裝越多 ECC Skills，AI 就越有效率嗎？
沒有這項必然關係。技能數量與實際任務成功率不同，應以固定測試與工作成果判斷是否有效。
結論：先用一個任務驗收，再決定要不要全面使用 ECC
ECC 最有價值的地方，是把 AI 開發過程中容易省略的規劃、驗收、審查及記錄整理成一套可重複的方法。
但工具越完整，設定也越需要管理。我會先從一個可回復的測試專案開始，確定它沒有增加不必要的風險，而且確實改善工作品質，再逐步擴大使用。
對已經依靠 AI 大量產出程式的人來說，真正值得投資的能力，是讓每次交付都能檢查、能重現，也能在發生錯誤時恢復。
延伸閱讀
- Agent Skills 怎麼管理？從大量技能中找到真正有用的流程
- Agent Skills 生態盤點：技能規模與工程品質如何區分
- NVIDIA OpenShell：AI Agent 安全沙盒與權限管理
- Cursor Plugins 安裝及驗收檢查表
資料來源
資料截點：2026-10-24 08:00（台北時間）。本次使用官方公開文件核對主要功能與安裝方式；未完成實機安裝、執行效能測試或獨立安全稽核。
利益揭露：本文未包含 ECC 付費推薦連結或聯盟邀請連結。文章屬工具介紹與工程教育內容，不構成安全認證或商業採購保證。
免責聲明：開源程式及第三方安裝套件可能修改本機設定、執行命令或存取專案資料。使用前應自行確認官方來源、授權、執行權限及備份。涉及正式系統、敏感資訊與部署操作，應由具備權限的人員審查。
發佈留言