10 · 团队协作和生产环境怎么落地

个人使用 Codex，重点是效率。团队使用 Codex，重点变成可控、可审查、可追溯、可回滚。

把 Codex 放进团队流程，不是给每个人开账号，也不是在 CI 里塞一个命令。你需要共识、权限边界、集成策略、自动化标准和治理机制。

五层落地顺序

flowchart TB
    Consensus["1. 共识<br/>AGENTS.md、团队规范"]
    Boundary["2. 边界<br/>sandbox、approval、secrets"]
    Integration["3. 集成<br/>GitHub、Slack、Linear、CI"]
    Automation["4. 自动化<br/>只读审查、受控修复"]
    Governance["5. 治理<br/>审计、用量、失败复盘"]

    Consensus --> Boundary --> Integration --> Automation --> Governance

顺序不能反：

• 没有共识，自动化会放大混乱。
• 没有边界，集成会扩大风险。
• 没有审查，自动化会变成黑箱。
• 没有治理，失败后无法追责。

第一层：共识

团队必须有共享规则，最小形式是 repo 中的 AGENTS.md。

它应该写清：

• 项目结构。
• 构建、测试、lint 命令。
• 包管理器。
• 代码风格。
• PR 规则。
• 敏感路径。
• 禁止事项。
• 完成标准。

AGENTS.md 应通过 PR review 修改。个人偏好不要写进团队文件。

第二层：边界

团队不能靠每个人手动选择权限。

需要统一：

• 默认 sandbox。
• approval policy。
• 网络访问。
• MCP allowlist。
• 凭据和 secrets 使用方式。
• 高风险 Git 操作限制。
• 删除、部署、生产数据和支付相关红线。

企业环境应优先用 managed configuration 或 requirements 强制底线。

第三层：集成

不要一开始就接所有系统。

低风险起点：

• PR summary。
• 只读 code review。
• issue triage。
• CI failure summary。
• release note draft。

高风险集成：

• 自动推送代码。
• 自动修生产问题。
• 写入 GitHub、Slack、Linear 或内部系统。
• 接生产日志、数据库或客户数据。

先让 Codex 产出可审查证据，再逐步开放写入。

第四层：自动化

CI 或 scheduled automation 的第一版应保守。

推荐阶段：

1. 只读审查：总结风险，不改代码。
2. 建议补丁：生成 patch 或 PR，人工审查。
3. 低风险自动修复：只处理格式、文档、快照等可复验任务。
4. 更深自动化：必须有强测试、回滚和 owner。

不要让 Codex 在 CI 中默认拥有全权限。read-only 和最小权限应该是起点。

第五层：治理

团队至少要记录：

• 谁触发任务。
• prompt 和输入范围。
• 使用了哪些工具和权限。
• 改了哪些文件。
• 跑了哪些验证。
• 失败原因。
• 人工审查和最终处理。
• 用量和成本。

治理不是为了限制使用，而是为了让团队知道什么有效、什么失败、哪里需要改规则。

四周落地路线

第一周：写共享规则。

• 建根目录 AGENTS.md。
• 补测试命令和目录边界。
• 写敏感信息和高风险操作红线。

第二周：统一权限。

• 确定 sandbox 和 approval 默认值。
• 定义网络、MCP、secrets、Git 操作边界。
• 企业环境下准备 managed configuration。

第三周：只读集成。

• 接入 PR review 或 CI summary。
• 不让 Codex 自动改代码。
• 收集质量反馈。

第四周：受控自动化。

• 选择一个低风险重复任务。
• 要求生成 PR 或 patch。
• 必须复跑验证并人工审查。

从第一天开始记录失败案例。失败案例比成功演示更能改进团队规则。

验收标准

团队落地算合格，应满足：

• 新成员能从 AGENTS.md 知道 Codex 怎么工作。
• 高风险动作有 policy 或 approval 控制。
• CI job 有明确触发条件和最小权限。
• Codex 改动都有 diff、验证、未验证项和 reviewer。
• 出问题能追溯触发者、输入、权限、文件改动和处理结果。

Codex 进入团队后，不再只是个人效率工具，而是自动化成员。自动化成员必须有规则、边界和责任链。