不會寫程式，也能讓 AI 自己幹活：Claude Code 與 Codex 的 8 大機制

我不會寫程式，但我的 AI 系統每天早上八點會自己寫好一份晨報給我、半夜會自己巡專案待辦、我睡覺時它還在幫我備份及整理資料庫。

這件事靠的是 8 個機制：agent、skill、MCP、API、排程、腳本、hook、loop。這些詞第一次看到都像天書，但它們其實不難，而且不管你用 Claude Code 還是 Codex，用法都是同一套。這篇把 8 個機制一次講清楚，加一張「各自負責什麼」的對照表，讓你不必把它們當零散功能死背。

Claude Code 和 Codex 差在哪？我該學哪一個？

不用二選一，先搞懂機制比選工具重要。

Claude Code 和 Codex 都是同一類東西：會讀你的檔案、直接動手修改、能自己執行命令的 AI。網路上同時用過兩個的人，大致的使用感想覺得：Claude Code 適合「陪你一起解問題」，Codex 適合「把任務丟給它、你回頭驗收」。

Claude Code 偏即時互動：你邊想邊做、隨時插話改方向，在複雜、要來回討論的任務上，它的程式碼品質公認比較好，公開的程式能力評測長期排在前段。Codex 偏把整包任務交出去自己跑完：它擅長終端機、腳本、系統維運這種指令密集的工作，能在雲端或背景非同步執行，還能同時處理多個任務，跑同一件事用掉的資源也少很多。

我自己兩個都用，Claude Code 當主腦負責大部分規劃和寫作，Codex 專門委派去生圖和交叉審查稿件。對你來說，重點是：先挑一個順手的開始，因為它們底層的機制相似，學會了換工具也不用重學。

讓 AI 自己工作，到底要懂哪些機制？

答案是 8 個，分三層：角色分工層、能力工具層、自動化層。

第一層：角色分工層——決定「誰來做、它記得什麼」

Agent（子代理） 是把任務交給專職的 AI 角色，各自有自己的記憶、指令和工具權限，主線對話不會被塞爆。我的系統裡有三個角色：一個幕僚長負責接需求、判斷派給誰，一個工程師負責寫程式，一個負責記錄日誌和回顧。要查歷史就叫記錄員、要改程式就叫工程師，彼此的脈絡不互相干擾。當一個任務會用到大量無關的上下文、或需要不同專長時，就分成子代理，不要全塞給同一個 Agent。

AI 說明書：Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md。它就是一份 AI 每次開工自動讀的說明書，寫你是誰、有哪些慣例、AI 與使用者各自的權限。這份說明書該怎麼寫可以看：CLAUDE.md 怎麼寫？768 行砍到 153 行，AI 從通用助理變懂我的同事。

第二層：能力工具層——決定「它會做什麼、能碰到什麼」

Skill（技能） 是把一套重複性流程寫成文件、封裝成一個資料夾，裡面連「什麼情況該用它」的觸發條件都寫好，AI 判斷符合觸發條件時就自己讀進來照做。它不是程式碼，是寫給 AI 看的標準作業流程。我把「寫每日日誌」「專案檢討」這些反覆要做的事都寫成 Skill，需要時它自動觸發、或我打一個指令叫它，不必每次重講一遍步驟。同一套流程你講第三次的時候，就該把它變成 Skill。

MCP 是 AI 發現及呼叫外部工具的公開協定。它規定 AI 應用程式和工具之間怎麼描述能力、傳送參數及回傳結果，讓不同 AI 能用共同方式連接資料與工具。我把 Notion、n8n、資料庫、Google Drive、Gmail 都透過 MCP 接上 AI，它就能在對話裡直接讀我的真實資料、寫回我的系統，而不是等我複製貼上。

API 是服務對外開放的原生程式介面，讓其他程式能直接呼叫它的功能或讀寫資料，不必透過網頁逐頁操作。每個服務的 API 規格都不同；MCP Server 可以把這些能力整理成 AI 認得的工具。MCP、API 兩者不是二選一：以 Notion 為例，MCP 負責 AI 與工具之間的共同溝通方式，真正讀寫 Notion 資料的底層能力仍由 Notion API 提供。連同 Plugin，三者的差異我在下面單獨說明。

第三層：自動化層——決定「它什麼時候動、動完怎麼確認」

腳本 是確定性的小程式。用 AI 解決問題的過程中，你會遇到很多重複又繁雜的工作，這種事不必 AI 每次現場重做一遍，叫它寫成一支腳本，以後就是一個指令跑完，而且結果保證一致，不會這次對、下次錯。我系統裡就有幾個腳本：每天把 Notion 待辦匯出一份本地備份、每週抓網站數據算成報表數字、批次改檔名和搬檔案。該保證不出錯的固定工作就交給腳本，AI 只負責判斷。

Hook 是在 AI 運作的特定時機點自動執行你定義的動作。常見的時機點像：AI 要執行某個命令之前（先檢查是不是危險操作，例如刪除檔案）、改完一個檔案之後（自動整理格式或跑測試）、一輪任務結束時（發通知到你手機）。我在系統裡設了幾道這種強制關卡，例如開發新專案時一定要先做某些檢查，沒過就直接擋下來。它把「希望 AI 記得做」變成「系統保證一定會做」。

排程 把 AI 包成一個能被定時觸發的指令，時間到了自己跑、不必你開著對話視窗。設定的地方有幾種：最通用的是作業系統本身的排程器（Mac／Linux 的 cron、Windows 的工作排程器），定時去執行上面那個指令；不想碰系統設定的話，Codex、Claude Code 的 App 直接內建定時任務。我的晨報就是每天早上八點自動觸發、自己寫完、發到我的 Discord。

Loop 是把前面全部串起來的核心：AI 讀狀態、動手、看結果、不對就再來一次，直到完成。真正關鍵是它會自己驗證「做完了沒、做得對不對」。舉例像是我委派 Codex 去生圖、再讓它回頭檢查產出，就是一個 Loop。

Loop Engineering 這個概念最近很紅，因為 2026 年年中 AI 模型的產出品質更穩定了，你不必即時盯著它調整方向，也能有不錯的產出。做法是給它一個能被驗證的目標（例如「測試全部通過」「這份清單全部處理完」），讓它反覆做、驗、修，直到達標。從「寫出完美的一句指令」變成「設計一個可靠的循環」，不再是每一步都由你下指令，更像把任務整包交辦給員工。

這 8 個機制，各自負責什麼？

機制	它負責什麼
Agent／子代理	任務專職角色、隔離對話及分配權限
記憶檔（CLAUDE.md／AGENTS.md）	員工手冊
Skill	將重複性流程封裝成一個技能
MCP	連接外部工具與資料的方式
API（服務原生介面）	用服務自己的介面讀寫資料
腳本	確定性的計算與處理
Hook	在特定時機點強制執行
排程／Automation	定時自己啟動任務
Loop	以自主循環及自我驗證完成任務

最容易搞混的三個：MCP、API、Plugin 差在哪？

三個工具為不同功能：

• API＝能力：服務開放哪些功能給其他程式使用。
• MCP＝標準介面：AI 如何發現、理解及呼叫這些工具。
• Plugin＝整合產品：把一組指令、工具、權限與安裝流程整理好，讓使用者直接安裝使用。

名稱	它是什麼	解決什麼問題	Notion 範例
API	服務提供的原生程式介面	讓其他程式讀寫資料、執行功能	Notion API 負責建立頁面、查詢資料庫
MCP	AI 應用程式與工具之間的共同協定	讓 AI 用一致方式發現及呼叫工具	Notion MCP Server 把「建立頁面」等能力描述成 AI 可呼叫的工具
Plugin	可安裝的完整整合產品	把操作流程、連線、權限、介面與設定一次交付	安裝 Notion Plugin 後完成授權，直接請 AI 搜尋或整理頁面

用「讓 AI 讀寫你的 Notion」當例子：

• 直接用 API：你或 AI 要照 Notion 規定的網址、驗證方式及資料格式送出請求。這條路最直接、控制最細，但換成 Gmail，就要重新處理 Gmail 的規格。
• 透過 MCP：AI 先向 MCP Server 查詢有哪些工具，再用共同格式呼叫「建立頁面」。MCP Server 收到後，才去呼叫 Notion API。MCP 協定本身不提供 Notion 的能力，真正執行的是 MCP Server 與背後的 Notion API。
• 安裝 Plugin：使用者拿到的是已經整理好的整合產品，通常連安裝、授權、權限、操作指令與工具都一起處理。Plugin 內部可以直接呼叫 API，也可以包含 MCP、Skill、Hook 或操作介面，實際內容依平台而定。

所以三者不是競爭關係，也不是固定只能排成一條線。常見情況是：**Plugin 負責讓人安裝及使用，MCP 負責讓 AI 呼叫工具，API 負責讓底層服務真正執行功能。**以 Codex 為例，Plugin 可以把 Skill、MCP Server、Hook 與介面資源包在同一個可安裝套件裡；而 MCP 官方架構也明確區分 AI 應用程式、MCP Client 與 MCP Server，Server 暴露的工具可以呼叫 API，也可以操作檔案或資料庫。

不會寫程式的人，該從哪個機制先學？

從說明書開始，也就是 CLAUDE.md 或 AGENTS.md。

說明書寫好之後，挑一件你最常重複交代的事寫成第一個 Skill，再挑一個你最常用的工具裝上 MCP。這三塊各自都用順了，你自然會發現有些事「每次都要手動叫它做」很煩，那一刻再去碰 Hook 和排程。慢慢地你會發現，整套 AI 系統越用越順手。

---

這 8 個機制，就是邁向 Agent 的第一步。如果你使用 AI 還在問答模式，可以先從讓 AI 扮演不同角色開始升級。