跳至主要內容
技術

Claude Code 與 Codex 共用專案規則:CLAUDE.md、AGENTS.md 與設定檔

Claude Code 與 Codex 共用專案規則:CLAUDE.md、AGENTS.md 與設定檔
Updated: 2026-07-14
Codex 和 Claude Code 雙修 第 3 / 7 篇 ,前往系列總覽

本篇是「Codex 和 Claude Code 雙修」系列的第 3 / 7 篇。你可以從系列總覽開始閱讀,也可以直接接著看本文。

同一個 repo 同時使用 Claude Code 和 Codex,最先出現的問題通常不是模型,而是規則分家:建置指令在 CLAUDE.md,測試要求在 AGENTS.md,半年後兩份內容已經互相矛盾。

我的解法是先把資訊分成三類:

  1. repo 規則:兩邊都該遵守的事。
  2. client 設定:權限、hooks、MCP、介面行為。
  3. 可重用流程:有步驟、腳本和參考資料的 Skills。

三類分開後,大部分內容只需要一份正本。

這是系列第 3 篇。上一篇是Claude Code 與 Codex 功能對照

共用核心:讓 CLAUDE.md 匯入 AGENTS.md

兩邊的 instruction file 概念相近,但載入規則不同。與其維護兩份完整副本,我會把跨工具規則放在 repo root 的 AGENTS.md

# Repository Guidelines

## Commands

- Install: `npm ci`
- Check: `npm run check`
- Build: `npm run build`

## Working agreements

- Preserve unrelated user changes.
- Use existing design tokens; do not hardcode colors.
- Run check and build before handing off.
- Never commit secrets or local environment files.

接著在 CLAUDE.md 匯入它:

@AGENTS.md

# Claude Code notes

- Use project Skills for release and content workflows.
- Ask before running commands that change external services.

@AGENTS.md 是 Claude Code 文件支援的 import 語法。相較於把兩個檔案做成 symlink,這個做法有兩個好處:

  • CLAUDE.md 可以保留 Claude Code 專屬附註;
  • 對 Windows、壓縮檔和某些 Git 設定比較友善。

Symlink 仍可用,但適合個人且環境一致的 repo。團隊專案應先確認每個開發環境都能正確保留連結。

官方載入規則可參考 Claude Code memoryCodex AGENTS.md

Instruction file 不是安全機制

AGENTS.mdCLAUDE.md 裡寫「不要刪資料」,本質上仍是給模型的上下文,不是作業系統層級的禁止規則。

我會把限制分成兩層:

  • 指引層:架構、流程、風格、該跑哪些檢查,寫在 instruction file。
  • 強制層:檔案寫入、網路、指令、credentials,交給 permission rules、sandbox、容器和 CI 權限。

規則可以解釋「為什麼不該做」,沙箱才負責「真的做不到」。兩者缺一不可。

大型 repo:把局部規則放近一點

如果 frontend、API 和 infra 的指令不同,不要把所有細節塞進根目錄。Codex 會依目錄層級讀取 AGENTS.md,較接近目前工作目錄的內容可以補充或覆寫上層規則。

AGENTS.md
apps/
  web/
    AGENTS.md
services/
  api/
    AGENTS.md

根目錄只放全 repo 共識,局部檔案再寫專屬測試、產生碼或部署限制。Claude Code 也支援分層的 memory;實際搜尋與優先順序仍以各自官方文件為準,不要假設兩邊完全相同。

Client 設定:接受兩份格式,不要硬合併

工具執行設定本來就不同,強迫共用只會讓結構更難懂。

設定範圍Claude CodeCodex
專案.claude/settings.json.codex/config.toml
使用者~/.claude/settings.json~/.codex/config.toml
常見內容permissions、hooks、pluginssandbox、approval、MCP、features

Codex 支援受信任專案裡的 .codex/config.toml,並且會與使用者設定和 CLI 參數依優先順序疊加。需要多套個人設定時,Codex 的 profile 會載入 $CODEX_HOME/<name>.config.toml,再用 codex --profile <name> 選取;不要沿用舊文章裡的 [profiles.name] 寫法。

這些檔案只放 client 行為。像「PR 前要跑哪些測試」仍應寫在共用規則,否則換工具後就消失了。

不要再用舊式 prompt 目錄共用工作流

過去常見的對照是:

.claude/commands/
~/.codex/prompts/

這不再是適合新專案的長期方案。Claude Code 已把 commands 的能力併入 Skills;Codex custom prompts 也已標示為 deprecated,官方建議改用 Skills。

如果一段流程需要被反覆呼叫,例如:

  • 發版前檢查;
  • 依專案格式寫部落格;
  • 產生 migration 並驗證;
  • review 未提交 diff;

就把它寫成 SKILL.md,附上需要的 scripts 和 references。下一篇會處理如何讓同一份 Skill 被兩邊找到。

一個可維護的 repo 結構

最後的目錄大致會長這樣:

repo/
├── AGENTS.md                 # 跨工具 repo 規則
├── CLAUDE.md                 # @AGENTS.md + Claude 專屬附註
├── .claude/
│   ├── settings.json         # Claude client 設定
│   └── skills/               # Claude 的 skill discovery 路徑
├── .codex/
│   └── config.toml           # Codex client 設定
└── .agents/
    └── skills/               # Codex 的 skill discovery 路徑

檢查這套結構時,我會問四題:

  1. 共用規則是否只有一份正本?
  2. 工具專屬設定是否留在各自目錄?
  3. 安全要求是否有真正的執行層限制?
  4. 重複流程是否已從 instruction file 移到 Skill?

這樣做不是追求「所有檔案完全共用」,而是讓每一種資訊只出現在最合理的位置。該共用的共用,該分開的分開,之後換模型或更新 CLI 才不會整份重寫。

上一篇:Claude Code vs Codex 功能對照 · 下一篇:一份 SKILL.md 兩邊用

留言討論

esc
輸入關鍵字搜尋文章...
查看收藏 →