AI 相關紀錄 v5｜Rules：專案規則多了之後怎麼拆？
整理 Claude Code Rules 與 Codex AGENTS.md 的拆分方式，說明何時該拆、怎麼依目錄管理專案規則。
W
前面整理過：
CLAUDE.md
AGENTS.md
這兩個檔案可以放 AI Coding Agent 在專案中需要知道的工作規則。
例如：
- 專案使用什麼技術
- 常用開發指令
- Coding Style
- 測試方式
- 修改限制
- 驗證流程
一般小型專案其實先使用：
CLAUDE.md
AGENTS.md
就已經很夠用了。
不用一開始就建立很多規則檔案。
等到規則真的越來越多，CLAUDE.md 或 AGENTS.md 開始不好整理時，再考慮把它們拆開。
Claude Code：.claude/rules/
Claude Code 可以使用：
.claude/
└─ rules/
把比較多的專案規則拆成不同 Markdown。
例如：
my-project/
├─ CLAUDE.md
│
└─ .claude/
└─ rules/
├─ testing.md
└─ security.md
可以先簡單理解：
CLAUDE.md
↓
主要專案規則
.claude/rules/
↓
規則變多後
拆開分類管理
例如測試相關規則越來越多，就可以另外建立：
.claude/rules/testing.md
內容可能是：
# Testing
- 修改功能後執行相關測試。
- Bug Fix 如果可以重現，考慮補上 Regression Test。
- 測試失敗時先確認原因，不直接刪除既有測試。
原本全部放在：
CLAUDE.md
之後變成：
CLAUDE.md
↓
留下主要規則
testing.md
↓
測試相關規則
security.md
↓
安全相關規則
主要目的就是讓文件比較容易整理。
不一定要拆很多 Rules
看到：
.claude/rules/
不代表一定要建立：
frontend.md
backend.md
database.md
testing.md
security.md
...
如果目前只有一類規則特別多，也可以只有：
.claude/
└─ rules/
└─ testing.md
需要什麼再增加什麼即可。
如果現在 CLAUDE.md 本身內容不多，而且很好理解，也完全可以維持原樣。
Rules 比較像：
規則開始變多之後的整理方式。
而不是：
每個 Claude Code 專案都一定要建立的結構。
Codex：使用不同目錄的 AGENTS.md
Codex 在專案規則這件事情上，做法跟 Claude Code 不太一樣。
Claude Code 可以使用：
.claude/rules/
拆分規則。
Codex 則可以在不同目錄放：
AGENTS.md
例如：
my-project/
├─ AGENTS.md
│
└─ server/
└─ AGENTS.md
根目錄的：
AGENTS.md
可以放整個專案共同需要知道的規則。
而：
server/AGENTS.md
則可以補充 server/ 這個區域特有的規則。
可以先簡單理解：
根目錄 AGENTS.md
↓
整個專案的規則
子目錄 AGENTS.md
↓
該區域額外需要知道的規則
一定要建立很多 AGENTS.md 嗎？
也不用。
例如一般小型專案：
my-project/
└─ AGENTS.md
其實就可以了。
只有當專案真的變大，而且不同區域的開發方式開始出現明顯差異時，才需要考慮增加子目錄的 AGENTS.md。
例如：
frontend/
server/
兩邊有完全不同的開發規範，這時才可能變成：
my-project/
├─ AGENTS.md
│
├─ frontend/
│ └─ AGENTS.md
│
└─ server/
└─ AGENTS.md
不用一開始就把所有目錄都放一份。
Claude Code / Codex 可以先這樣記
如果只是先理解 Rules，我覺得記這些就夠了：
| Claude Code | Codex |
|---|---|
CLAUDE.md | AGENTS.md |
.claude/rules/*.md | 子目錄 AGENTS.md |
| 規則可以依主題拆開 | 規則可以依目錄拆開 |
例如：
Claude Code
CLAUDE.md
↓
主要規則
.claude/rules/testing.md
↓
測試規則
Codex：
AGENTS.md
↓
主要規則
server/AGENTS.md
↓
server 區域規則
兩邊的做法不同，但目的很接近：
專案規則開始變多後，不需要全部塞在同一份文件。
什麼時候才需要拆 Rules？
我目前會先把它理解成：
規則不多
↓
CLAUDE.md / AGENTS.md 就好
等到真的出現：
規則越來越多
↓
一份文件不好整理
或者：
不同區域
↓
有不同的開發規則
再開始拆即可。
不需要為了讓 AI Coding 設定看起來「很完整」，一開始就建立很多檔案。
不知道怎麼拆，可以先請 AI 幫忙整理
如果已經累積不少規則，但不知道該怎麼分類，也不用一開始就自己設計完整結構。
可以先請 AI：
閱讀目前的 CLAUDE.md / AGENTS.md，
幫我找出哪些規則適合保留在主文件，
哪些規則可以另外分類。
先提出拆分建議，不要直接修改檔案。
AI 可以先根據內容整理成類似：
主要專案規則
→ 保留在 CLAUDE.md / AGENTS.md
Testing
→ 測試相關規則
Security
→ 安全相關規則
API
→ API 開發規則
如果專案本身已經有明確的目錄結構，也可以請 AI 一起參考：
請閱讀目前的專案結構與規則文件，
判斷是否真的需要拆 Rules。
如果需要：
1. 建議怎麼分類
2. 說明每一類為什麼值得拆開
3. 先給我預計建立的檔案清單
4. 等我確認後再修改
我覺得這種方式比直接跟 AI 說：
幫我把 Rules 全部拆好
更容易控制。
因為有些專案其實規則並不多，AI 看完後也可能發現：
目前不用拆，維持一份文件比較簡單。
這反而也是合理的結果。
所以在不知道怎麼拆的情況下，可以先把 AI 當成：
協助分類與整理規則的人。
先讓它提出方案，再決定是否真的拆分即可。
最後簡單整理
Claude Code：
CLAUDE.md
↓
主要專案規則
規則變多
↓
.claude/rules/
Codex：
AGENTS.md
↓
主要專案規則
某個子目錄有自己的規則
↓
子目錄 AGENTS.md
所以對一般專案來說：
先從 CLAUDE.md / AGENTS.md 開始
↓
實際使用
↓
規則真的開始增加
↓
再考慮拆分
就可以了。
Rules 對我來說比較像是：
專案規則變多之後的整理工具。
而不是建立 AI Coding 環境時一定要先準備完整的一套設定。