不要让团队各自“凭感觉”用 Codex：一套可落地的团队 Playbook

一个人使用 Codex，只要自己知道项目怎么跑、哪些地方不能改就够了。

团队使用则完全不同。如果每个人的提示词、权限、测试方法和验收标准都不一样，Codex 只会放大原有流程差异。

团队落地的关键不是统一安装，而是统一规则、验证和复盘。

团队接入需要五块基础设施

基础设施	解决的问题
AGENTS.md	项目结构、命令、风格和安全边界
测试与 CI	怎样证明改动有效
PR 模板	怎样披露 Codex 参与范围、验证和风险
权限基线	哪些操作可自动执行，哪些必须人工审批
案例与排障库	怎样复用成功经验和失败证据

这五项没有建立之前，不适合直接推动“全团队自动开发”。

一份团队版 AGENTS.md 应该包含什么

# AGENTS.md

## 项目概览
## 常用命令
## 目录边界
## 代码规范
## 测试要求
## 安全边界
## PR 交付要求

重点不是篇幅，而是让规则可以执行：

• “保证质量”改成明确的测试命令；
• “注意安全”改成禁止读取的文件和必须审批的操作；
• “不要乱改”改成目录边界和禁止无关重构；
• “完成后汇报”改成固定交付字段。

团队共同规则进入仓库；个人路径、工具习惯和私有配置留在本机。

PR 必须披露 Codex 做了什么

建议增加以下模板：

## 背景

## 改动

## Codex 参与范围

## 验证

## 风险

## 截图或日志

这里的目标不是给 AI 使用贴标签，而是让审查者快速知道：

• 哪些部分由 Codex 分析或修改；
• 人工做了哪些判断；
• 验证是否真实运行；
• 是否存在未检查的生成内容；
• 高风险变更是否经过额外 review。

统一权限基线

团队里如果有人使用只读模式，有人长期使用完全访问，问题发生后很难复现。

可以按任务等级建立基线：

任务	建议
分析、Review、文档总结	只读
日常编码和测试	工作区写入 + 按请求审批
需要减少频繁弹窗	工作区写入 + Auto-review
发布、迁移、生产数据	强制人工审批
凭据和用户数据	隔离环境，最小权限

权限机制负责控制行动边界，代码质量仍然通过测试、CI 和人工 review 保证。

从小范围试点开始

第一阶段：低风险任务

从文档、测试、代码解释和失败日志整理开始，观察团队使用方式。

第二阶段：建立规则

把反复出现的项目说明写入 AGENTS.md，把验证命令加入 PR 模板和 CI。

第三阶段：沉淀工作流

把稳定的 PR Review、CI 修复和文档发布流程整理成 Skill。

第四阶段：有限自动化

对只读汇总、死链检查和提醒类任务使用 Automation；高风险动作仍保留人工确认。

例会应该复盘什么

• 哪类任务表现稳定？
• 哪类任务容易超出范围？
• 哪些命令和规则值得写入 AGENTS.md？
• 哪些成功案例可以变成模板或 Skill？
• 哪些失败应该进入排障手册？
• 团队成员是否真实检查了 diff 和验证结果？

只记录成功会让团队高估能力。失败原因和恢复过程同样值得沉淀。

衡量效果，不要只统计生成代码量

更有价值的指标包括：

• 从任务开始到通过 review 的时间；
• 首次提交的测试通过率；
• 无关改动比例；
• 人工返工次数；
• 被复用的规则和 Skill 数量；
• 因权限或流程避免的高风险操作；
• 排障恢复时间。

写在最后

Codex 的团队价值，不在于让每个人写出更多代码，而在于把项目知识转化为可执行流程。

可靠的团队路径是：

小范围试点
→ 固化项目规则
→ 统一验证和权限
→ 沉淀成功与失败案例
→ 复用为 Skill
→ 再逐步自动化

先让团队的协作方式稳定，再让 Agent 加速它。