Day 18 最後，我們把模型從「一個我去使用的產品」，變成「一個我可以組進自己系統的能力」。有了 API，模型可以被放進自己的程式、網站或小工具裡；接下來的問題是：當 AI 不只回答一次，而是要持續幫忙做事，我們怎麼讓它知道這裡的做事方式？
這也是前面介紹 Codex、Claude Code、Ollama 與 API 後，很自然會遇到的下一步。當自己開始打造產品，或進階使用 Coding Agent，AI 可能讀專案檔案、改程式、跑指令，還把結果交給下一步。這時候，重要的就不只是它會不會回答，而是：
它會怎麼做？
Chat mode 當然沒有不夠好。它很適合發想、整理和一次性的問題。不過，如果 AI 要反覆碰同一個專案，我們就得先交代一些很實際的事情：這個專案怎麼啟動？哪些檔案不能碰？改完後要檢查什麼？不確定時能不能自己猜？
想像你請一位新同事協助整理工作室。你不會只說「弄好它」，然後把鑰匙、收銀機和所有抽屜都交出去。你會先說明物品放哪裡、哪些東西不能丟，以及收工前要不要確認瓦斯關了。Agent 也需要這份說明。
這類檔案的用途很單純：把每次都得重新交代的專案規則，寫在專案裡，讓 Agent 開工時可以讀到。
AGENTS.md 是許多 Coding Agent 採用的共通格式，Codex 也會讀它。可以把它想成「給 AI 同事看的專案說明書」。
CLAUDE.md 則是 Claude Code 使用的規則檔。Claude Code 官方文件也特別說明：它讀的是 CLAUDE.md，不是 AGENTS.md。如果同一個專案同時要給 Claude Code 與其他 Agent 使用，可以在 CLAUDE.md 引用 AGENTS.md，把共用規則只寫一份，再補上 Claude 專用規則。
所以不必背一堆格式。初學時只要先記住：
多數支援 AGENTS.md 的 Coding Agent
→ 看 AGENTS.md
Claude Code
→ 看 CLAUDE.md
同一個專案同時使用兩者
→ 共用內容寫在 AGENTS.md，CLAUDE.md 再引用它
不同工具的細節會繼續演變，但核心概念不變：讓 AI 不必每次開新對話，就從零猜測這個專案的規矩。
先不要急著寫成《AI 員工守則大全》。一份對初學者有用的規則檔，只要回答四個問題就很好：這是什麼專案？怎麼開始？哪些事不要做？怎樣才算完成？
例如，假設你和朋友正在做一個社團活動網站，可以先寫成這樣：
# 專案約定
- 先閱讀 README，了解怎麼啟動網站。
- 不要修改 `.env`；裡面可能有 API Key。
- 不確定需求時，先說明你的疑問，不要自行加功能。
- 完成後，告訴我改了什麼，以及還有哪些地方沒驗證。
它看起來很簡單，卻能避免不少麻煩。尤其是「不要修改 .env」和「不要自行加功能」這兩句，常常比「請寫出高品質程式」有用得多。後者像對新同事說「請表現優秀」；前者才是能照著做的交代。
如果你發現自己每次都對 Agent 說：
不要順手重寫整個網站，我只要你改按鈕。
那句話就很適合搬進規則檔。如此一來，下一次不用再從聊天紀錄裡把它挖出來。
規則檔適合放長期有效、每次開工都用得到的約定，不適合什麼都往裡面塞。API Key、密碼與私人資料當然不能放；今天才有用的臨時任務、整段聊天紀錄，以及還沒確認的猜測，也不該住進去。
例如「今天先把首頁標題改短」是一次性的任務，留在這次對話就好；「修改首頁後要檢查手機版」才像是值得長期保留的規則。否則規則檔最後會像那個大家都不敢打開的廚房冷凍庫：裡面存放著長年累月號稱冰著就不會過期的物品。
規則檔的內容會被放進 Agent 的 Context，也就是它這次工作時能看到的資料。塞得太長，就像新同事第一天收到一千頁手冊：真正重要的內容反而容易被埋住。
OpenAI 分享 Codex 的做法時，也提到曾經把大量知識集中在一份巨大的 AGENTS.md，結果效果不好。後來改成讓它保持精簡，像一張地圖；需要深入了解時，再引導 Agent 去看 README、設計文件或其他專門文件。
所以一開始不必寫專案的全部歷史。把「每次都要知道、而且能直接影響這次工作」的事留下就好。像是啟動方式、不可碰的檔案、測試方法和完成標準。
專案變大後，才需要分工：根目錄放大家都要遵守的規則；某個資料夾若有自己的需求，再在那裡放更具體的說明。這就像大樓有總樓層指南，進實驗室才要看實驗室規範，不需要在電梯裡背完所有房間的注意事項。
第一次寫規則檔時，不知道從哪裡開始很正常。GitHub 上的 forrestchang/andrej-karpathy-skills 提供了一份可參考的 CLAUDE.md。它不是 Andrej Karpathy 本人公開的私人設定檔；比較準確地說，它是專案作者根據 Karpathy 對大型語言模型寫程式常見問題的觀察，整理出的四項守則。它不需要整份照抄；真正有價值的地方，是提醒我們四件很樸素的事：(1)先想清楚再動手、(2)先用簡單方法、(3)只改這次要改的地方、(4)最後確認是否真的完成。
我尤其喜歡「只改這次要改的地方」。AI 有時候像很熱心的室友：你請它換一顆燈泡，它順手把客廳重新粉刷、調整家具位置，還把你以為不用的插座拆掉。
所以如果你只說「幫我修報名按鈕」，規則檔可以補上一句：
只修改這次任務需要的地方；若發現其他問題，先提出，不要順手一起改。
這比「請寫出高品質程式」更具體，也更容易檢查。名人的範本可以當起點，但最後應該留下的規則，還是要從你自己的專案、自己的痛點長出來。
不一定。
檔案放在專案裡，不等於你目前使用的 Agent 一定會找到它、支援它，或剛好從正確的資料夾啟動。最常見的問題不是規則寫得不夠兇，而是檔名、位置或工具根本沒有對上。
剛開始練習時，可以在規則檔加上一句小小的「讀取回條」(感謝Ci當初的分享)：
若你已讀完這份規則，開始回覆時先說：
「吉伊卡哇!」
所以當你在執行的畫面上看到「吉伊卡哇!」，至少表示 Agent 有看到這條規則。至於它有沒有讀懂其他規則、後面是否真的照做，還要繼續觀察實際行為。若完全沒出現，就先檢查：你用的是 AGENTS.md 還是 CLAUDE.md？有沒有打錯字？檔案是否放在專案根目錄？目前的工具是否支援這個格式？
這不是安全證明，只是第一個可觀察訊號。先確認它有讀到，再檢查它有沒有做到。
如果想親眼比較，可以打開 day19_practice.ipynb。Day 18 是「孔明，你怎麼看？」；到了 Day 19，我們把它換成「翼德，這局怎麼打？」。你可以切換「不載入規則」、「載入 AGENTS.md」與「載入 CLAUDE.md」，觀察同一個模型是否從普通助理變成滿口「俺老張」、催你先動手做的三弟。
這份 Notebook 是教學模擬：程式會主動讀取規則檔，再把內容放進模型的 system prompt。真正使用 Codex、Claude Code 或其他 Coding Agent 時，規則檔由各工具依自己的方式載入，不能因為 Notebook 示範成功，就假設所有工具都會自動找到同一個檔案。 規則以及執行畫面如下：
# 翼德工作守則
- 你是張飛，字翼德。
- 稱呼使用者為「主公」，自稱「俺老張」。
- 開始回答時，先說：「報告主公，俺老張已讀過軍令！」
- 遇到生活煩惱時，可以自然地說「俺也一樣」或「這有何難」，但不要每句都喊。
- 不寫長篇分析，直接把問題拆成三個可以立刻行動的步驟。
- 個性豪爽、急性子、有點莽撞，但建議必須實際可行。
- 「能動手就別空想」是指開始做事，不是叫人打架。
- 遇到醫療、法律、投資或危險問題時，不可逞強，要提醒主公找專業人士。
- 整則回答不超過 450 個中文字。
## Claude 專用規則
- 最後加上一句：「主公，先做再說，但桌子先別掀。」
CLAUDE.md 與 AGENTS.md 是提醒，不是鐵門看到讀取回條，也不代表後面每條規則都會被遵守。規則檔能告訴 Agent：「我們平常這樣做。」但本質仍是文字指令，不是保證。
Claude Code 官方文件也說明：CLAUDE.md 會進入 Context，卻不是強制執行的設定。Agent 仍可能漏掉或看錯規則。
如果是偏好，寫成規則就很合適。例如「回覆請用繁體中文」、「先看 README」或「不確定時先問」。
但若是不能出錯的事情，例如「絕對不要改到 .env」、「每次改完都要做固定檢查」，只靠提醒就有點像在冰箱貼便利貼：家人看得到，不代表一定會照做。
2026 年 2 月，Meta 負責 AI Alignment 的主管 Summer Yue 分享了一次 OpenClaw 郵件事故。她原本只請 Agent 建議哪些信可以刪除或封存，沒想到 Agent 直接動手刪信，連她後來要求停止也沒有理會。
Summer Yue 認為，主要信箱裡的資料太多，觸發了 Context compaction，可能讓「先確認、不要直接動手」這項指令被漏掉，而使用者可能沒有把提醒加進去AGENTS.md／CLAUDE.md。
這正好接回 Day 13：Compaction 可能遺失資訊。AGENTS.md／CLAUDE.md 能讓長期規則重新進入 Context，但仍不是鐵門。像「刪信前一定要確認」這類要求，還需要權限限制、確認步驟或 Hook；不然規則寫得像聖旨，信箱還是可能被當成換季清倉。
這時候，才輪到 Hooks。
Hooks 會在特定時機自動執行一個動作。Claude Code、GitHub Copilot 等 Coding Agent 都有類似機制，但設定方式與支援時機不完全相同；以下先用 Claude Code 來理解。
Hooks 的觸發時機很多。初學者可以先記住最常用的兩個：工具執行前與工具執行後。前者適合阻擋危險操作，後者適合整理格式或檢查結果。除此之外，還有 Session 開始、等待使用者回覆、Context compaction 前後等時機，不需要一次全部背起來。
最生活化的例子是：Claude Code 等待你回覆時，讓電腦跳出通知。你就不用盯著 Terminal 發呆，可以先去泡咖啡；需要你時，它再叫你回來。
另一個例子是保護檔案。當 Agent 準備修改 .env 或正式環境設定時，Hook 可以在動作發生前擋下來。這不像只貼一張「請不要進機房」，而是多加一道門禁。不過，規則必須涵蓋 Agent 可能使用的修改方式，不能把一扇門鎖好，卻忘了旁邊還有窗戶。
還有一類很適合自動化的工作：每次修改檔案後自動整理格式，或在結束前跑一次固定檢查。這些事不需要 AI 判斷得多有智慧；電腦照規則做，反而比較可靠。
可以這樣區分：
CLAUDE.md / AGENTS.md
＝ 告訴 Agent 這個專案通常怎麼做
Hooks
＝ 在特定時機，讓系統自動做一件事
不過，初學者現在不用急著自己寫 Hook。先看懂它解決的問題就夠了：有些事情適合提醒 AI；有些事情則應該交給系統直接執行。真的要設定時，再查你正在使用的 Agent 文件，不要把 Claude Code 的設定格式直接貼到別的工具裡。
我最喜歡的起點是：當 Agent 第二次犯同一個錯時。
第一次，也許只是剛好理解錯了。第二次又發生，例如它又把不相干的檔案一起改掉，你就可以把修正寫下來：
只修改這次任務需要的檔案；若要延伸修改，先說明原因。
如果日後發現這條規則還是不夠，並且電腦可以明確判斷「它有沒有碰到不該碰的東西」，再考慮用 Hook 或其他檢查方式處理。
這是一個很實際的循環：先工作、觀察錯誤、寫下規則；真的不能接受失敗，再把規則交給系統執行。不要還沒開工，就先寫出一部比產品本身還厚的規則百科。
從今天開始，Agent 不再只是幫我們回答問題的對話框。它開始有工作環境、專案規則與自動化檢查；而我們也開始學著分辨：哪些事情可以交給 AI 判斷，哪些事情應該用系統保護。
你不需要一次把所有規則都寫好。先選一個正在做的小專案，記下你最不想再重複說的一句話。那就是一份 AGENTS.md 或 CLAUDE.md 最好的第一行。
下一篇會再把這個有規則的 Agent 接上外部資料與工具，看看 MCP 怎麼讓它不只會讀專案，也能在適當的範圍內取得外面的資訊。
iThome鐵人賽
看影片追技術