---
title: "10 · 团队协作和生产环境怎么落地"
description: "把个人 Codex 使用升级成团队可治理流程：共识、边界、集成、自动化和审计。"
canonical: "https://xiangyugongzuoliu.com/openai-codex-team-production"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

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

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

> [!IMPORTANT]
> 团队落地不要跳层。没有 `AGENTS.md` 和权限底线，就不要直接做自动化；没有审计和回滚，就不要进入生产流程。

<Cards>
  <Card title="AI-native teams" href="/docs/codex/official/06-team-integration/59-ai-native-team">
    理解哪些工作交给 Codex，哪些仍由工程师负责。
  </Card>
  <Card title="Enterprise admin" href="/docs/codex/official/06-team-integration/54-enterprise-admin">
    查看企业管理员如何配置访问、RBAC 和治理。
  </Card>
  <Card title="GitHub Action" href="/docs/codex/official/06-team-integration/45-github-action">
    将 Codex 接入 CI 前先理解权限和触发边界。
  </Card>
</Cards>

## 五层落地顺序

```mermaid
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 进入团队后，不再只是个人效率工具，而是自动化成员。自动化成员必须有规则、边界和责任链。
