10 · 团队协作和生产环境怎么落地
把个人使用 Codex 升级到团队和生产环境：共识、边界、集成、自动化、治理五层逐步落地。
个人用 Codex，核心问题是“我能不能更快完成任务”。团队用 Codex，核心问题变成“流程是否可控、结果是否可审查、权限是否安全、出事是否能追溯”。
这是一道质变门槛。不是给每个人开账号就叫团队落地，也不是把 CI 里塞一个 Codex 命令就叫生产化。
先理解：团队场景多了什么问题
个人模式下，你自己提需求、自己看 diff、自己决定要不要合并。即使出错，影响范围也相对可控。
团队模式下，Codex 可能影响多人代码、CI、PR、发布、权限、凭据和审计。这个时候它不再只是“帮我写代码的工具”，而是进入团队协作流程的自动化成员。
自动化成员必须满足三件事：有规则可遵守，有边界可约束，有结果可审查。
五层落地顺序
第一层是共识。团队必须有一份提交进仓库的 AGENTS.md，写清项目结构、构建测试命令、禁止事项、代码风格、PR 规则和安全边界。它不是个人偏好文件，而是团队协作接口。
第二层是边界。个人可以临时调整 sandbox 和 approval；团队需要强制底线。企业场景里用 requirements.toml、managed settings、权限策略和 hooks 来约束危险模式，避免每个人按自己习惯乱开。
第三层是集成。Codex 要进入 GitHub、Slack、Linear、CI 或内部工单系统，但不要一开始全接。先从 PR review 或 issue triage 这种低风险入口开始。
第四层是自动化。等团队已经能审查 Codex 输出，再让 CI 里运行 codex exec、Codex GitHub Action 或结构化检查。自动化的第一目标不是“自动合并”，而是稳定产出可审查证据。
第五层是治理。团队需要看用量、失败率、触发者、修改范围、审批记录、敏感信息风险和成本。没有治理，自动化越多越难追责。
怎么判断当前该做哪一层
如果团队每次都在问“Codex 应该怎么跑测试、哪些目录不能改”，先补 AGENTS.md。
如果大家经常为了省事开大权限，先补边界层。
如果 Codex 结果只能停留在个人终端，才考虑接 GitHub 或 Slack。
如果 PR review 已经稳定、prompt 已经固定、输出能被团队理解，再进 CI。
如果 Codex 开始频繁影响生产流程，再补治理和审计。
不要跳层。没有共识就做自动化，只会把混乱放大。
AGENTS.md 在团队里怎么用
团队级 AGENTS.md 应该进入 git，并通过 PR review 修改。它适合写稳定、共享、每次任务都要知道的规则。
根目录写跨团队规则，例如禁止 force push、默认测试命令、敏感路径、变更前必须读的文档。
子目录可以有自己的 AGENTS.md，写后端、前端、移动端、数据层的局部规则。这样既有团队共识，也给子团队留出自治空间。
不要把个人习惯写进团队文件。个人偏好应该放本地配置或用户级规则。
CI 里跑 Codex 要保守
CI 里的第一版 Codex 应该只读。让它审查 PR、总结失败原因、列出风险，不直接改代码。
第二版可以生成 patch，但要复跑测试，并以 PR 形式交给人审。
第三版才考虑自动修复某类低风险问题，例如格式化、文档过期、测试快照更新。
不要让 Codex 在 CI 里无条件拿到全权限。codex exec 默认 read-only 是好事；需要写文件时再给 workspace-write；danger-full-access 只适合隔离 runner。
团队常见误解
给每个人开账号不等于团队落地。账号只是入口，流程和边界才是核心。
AGENTS.md 不是装饰文档。它应该像团队开发契约一样 review。
CI 跑 Codex 不一定昂贵。只读 review、窄 prompt、结构化输出、固定触发条件，可以把成本控制住。
个人 sandbox 配置不等于企业安全底线。团队需要不可绕过的 managed policy。
自动评论不等于自动可信。Codex 的输出要有来源、范围、未验证项和剩余风险。
新手常见坑
- 一开始就接太多工具：GitHub、Slack、Linear、CI 同时接，出错时无法定位。
- 让 Codex 直接写主分支：团队还没建立信任就放大风险。
AGENTS.md没有 owner：规则过期没人维护。- 没有复跑测试：自动修复无法证明有效。
- 只看成功案例：失败的 Codex run 也要被记录和复盘。
- 没有敏感信息策略：prompt、日志、tool output 可能带出私有数据。
四周落地路线
第一周，只做共识。写根目录 AGENTS.md，补测试命令、目录边界、PR 规则和禁止事项。
第二周，做边界。统一 sandbox、approval、敏感路径、凭据规则和最低权限。
第三周，做只读集成。让 Codex 进入 PR review 或 CI summary，但不改代码。
第四周，做受控自动化。只允许它处理一种低风险重复任务，并要求复跑测试、开 PR、人工 review。
治理不要等半年。至少从第一天记录：谁触发、任务是什么、改了什么、验证了什么、哪里失败。
怎么验收团队落地
团队成员能在不问人的情况下，从 AGENTS.md 知道 Codex 应该怎么进入项目。
Codex 的高风险动作有 approval 或 managed policy 控制。
CI 里的 Codex job 有明确触发条件、最小权限、固定输出和失败处理。
每次 Codex 产生的代码改动都有 diff、测试结果、未验证项和人工 review。
一旦出现问题，你能追溯触发者、prompt、权限、文件改动、日志和最终处理结果。