一个人用 Codex，很多事情可以靠经验判断。一旦进入团队协作，问题就变了：不是你会不会用，而是大家是不是按同一套边界在用。
如果没有统一约定，容易出现有人什么都敢批、有人什么都不敢批、有人把密钥带进上下文等问题。
> 前置教程：如何保护 .env、密钥和隐私信息
> 如果你还没有建立个人使用阶段的敏感信息边界，先完成前置教程。
> 依据来源：OpenAI Codex 官方手册中关于 approvals、sandbox、review、project instructions、workflow 的说明。
学习目标
学完后，你应该能做到：
- 知道团队在正式用 Codex 之前要先约定什么。
- 文案修改 / 样式调整
- 小范围页面修复 / README 补充
- 已知问题定位 / 构建失败排查
- 小范围重构建议
- 支付逻辑 / 权限系统
- 登录注册核心链路
- 数据删除与恢复
- 数据库结构变更
- 生产环境配置 / 密钥处理
- 安装新依赖 / 删除文件
- 覆盖大量改动
- 改构建配置 / 改部署配置
- 改数据库结构
- 提交 Git / 推送远程
- 任何任务完成后都要看 diff。
- 目标：
- 实际修改：
- 修改文件：
- 已做检查：
- 结果：
- 未做检查及原因：
- 超出范围的改动：
- 需要人工确认的地方：
- 是否建议进入提交前检查：
- 第一阶段：只允许只读分析、小范围文案/样式修改、构建排查。
- 允许用于只读分析、小范围代码修改、文档补充、构建排查。
- 愿意写清楚任务的人。
- 定义能做的任务与只适合分析的任务。
2. 知道哪些任务适合直接交给 Codex。
3. 知道哪些任务必须人工二次确认。
4. 知道怎样把这些边界写成团队可执行规则。
5. 知道如何避免“每个人各用各的”。
为什么团队需要“显式边界”
团队使用时，一个人的习惯会直接影响仓库质量、提交记录、配置安全和团队信任。所以团队第一次引入时，先讨论：哪些事允许它做，哪些事必须停一下，哪些结果必须人工看一眼。
1. 哪些任务适合交给 Codex
推荐优先放开的任务通常是：
共同点：目标清楚、范围可控、易于修正。
2. 哪些任务不能默认直接交给 Codex
下面这些任务，必须多一层人工判断：
稳妥做法：先让 Codex 只读分析 -> 再让它给最小方案 -> 最后人工确认后再改。
3. 哪些动作必须人工确认
团队里建议默认列为“必须确认”的动作：
4. 统一验收标准
团队必须统一最低交付线，例如：
2. 任何代码任务都要做最小必要检查。
3. 任何超出范围的改动都要单独说明。
4. 任何没有运行检查的任务都要说明原因。
5. 任何准备提交的任务都要先过提交前检查。
5. 统一汇报格式
最好统一成一套固定汇报格式，例如：
``markdown
修改摘要
检查结果
风险提示
`
分阶段引入计划
2. 第二阶段：逐步放开小功能修改、README 补充、局部重构。
3. 第三阶段：讨论复杂业务逻辑、配置改动、自动化工作流。
团队可复制规则草稿
`
Codex 团队使用边界：
2. 涉及支付、权限、登录核心链路、数据库结构、生产配置的任务，先只读分析，再人工确认。
3. 安装依赖、删除文件、改配置、提交 Git、推送远程，必须人工确认后才能执行。
4. 所有任务完成后，必须说明修改文件、检查结果、未检查原因和风险提示。
5. 不得把 .env、密钥、Cookie、账号信息、用户隐私信息原样带入任务上下文或总结。
6. 如果 Codex 发现需要扩大修改范围，必须先停下来说明原因。
`
如何避免“各自为政”
最直接的办法是提供两个固定模板：小范围修改模板 和 Bug 排查模板`。约定团队成员优先基于模板发任务。
谁适合做“团队第一批试点”
2. 愿意认真看结果、不会盲信的人。
早期关键是先把正确用法跑顺。
总结
做到这里，如果你已经能把团队使用边界概括成下面 5 件事，就说明本篇目的达到了：
2. 定义必须人工确认的动作。
3. 定义最低检查标准。
4. 定义统一汇报格式。
5. 从小权限、小范围、小任务开始试点。
下一篇建议看：提交前安全检查清单
那篇会把“准备提交前到底要看什么”收成一张真正能执行的清单。