一个人用 Codex，规则记在自己脑子里就够了。多个人一起用，规则就得写进仓库，否则每个人拿到的结果都不一样。团队接入的重点其实就三件事：规则写清楚，验证跑起来，案例沉淀下来。

先弄清权限是怎么组合出来的

团队里最容易吵起来的是它能干什么这个问题。这个答案由三样东西拼出来，都在配置项里。

配置项	管什么
approval_policy	审批策略，决定越界请求是确认，拒绝，还是不再询问
approvals_reviewer	审批人，由 user 或 auto_review 判断是否放行
sandbox_mode	沙盒范围，判断动作是否还在文件，网络，命令的边界内

任务动作按这个顺序过一遍。改文件，跑命令，联网或者调用工具，先进入沙盒判断。沙盒范围内直接执行，越界了才交给审批策略和审批人。

AGENTS.md 是团队共享规则的落点

团队接入清单里有五样东西要准备。

项目	建议
AGENTS.md	写清项目结构，命令，风格，安全边界
测试命令	提供最小相关测试和全量测试命令
PR 模板	要求说明 Codex 参与范围，验证结果和风险
安全规则	明确生产数据，密钥，发布，迁移的审批要求
案例库	把成功任务和失败复盘都沉淀下来

AGENTS.md 本身按提纲写就行，七个小节。开头放项目概览，常用命令，目录边界。收尾放代码规范，测试要求，安全边界，PR 交付要求。

第二项容易被漏掉。光有测试命令不够，还要区分最小相关测试和全量测试，前者给日常改动用，后者给合并前用。

共享的和私人的要拆开

团队的共同规则进 AGENTS.md。个人本机路径，私有工具习惯，临时限制和回复偏好这几类，拆到 AGENTS.local.md 里。

团队如果允许用社区工具，可以评估 codex-agents-local。装之前先确认 AGENTS.local.md 和 AGENTS.override.md 会带来什么影响。这个东西已经加进 ignore，同时让 Codex 审查安装步骤对 ~/.local/bin 和 ~/.codex/hooks.json 的改动。

PR 模板是给人看的证据链

PR 描述模板分成六块。先是背景和改动。然后是 Codex 参与范围，这一块是团队最需要的，它逼着提交者说清楚哪些部分是 Codex 做的，哪些是人补的。后面接着验证，风险，还有截图或日志。

例会拿这五个问题复盘

每个迭代开一次复盘，问这几句就够了。哪类任务 Codex 表现稳定，哪类任务容易失控或者需要更强的约束。

剩下三句挑沉淀方向。哪些命令和规则应该写进 AGENTS.md，哪些成功案例可以沉淀成模板，哪些失败案例应该写进排障手册。案例库就是这么一点点攒起来的。