Appearance
Codex 工程协作教程：用 Git、测试和自动化控制风险
当 Codex 从“回答问题”进入真实仓库，协作规则比单次提示词更重要。团队需要知道它能读取什么、改动什么、如何运行验证，以及谁负责合并结果。
图示：分支、测试、审查和合并构成的 Codex 协作闭环，图片为本站原创示意图。
1. 每项任务使用独立分支
bash
git status
git switch -c codex/issue-123分支名应能对应需求或 Issue。即使 Codex 产生了多余改动，也可以用 diff 定位，必要时只保留其中一部分。
2. 给代理最小必要权限
把仓库中的密钥、生产配置和个人数据排除在任务范围之外。提示词中直接写出禁止项，例如“不要访问 .env”“不要执行生产部署”“不要修改迁移历史”。涉及删除文件、批量替换和网络请求时，要求先列计划也更稳妥。
3. 把验证命令写进任务定义
text
完成后运行 npm test 和 npm run lint。
如果测试失败，保留失败输出，先修复当前改动引入的问题。
不要通过删除测试或放宽 lint 规则来“修复”失败。完整测试耗时很长时，可以先运行受影响模块的测试，再由人工或 CI 执行全量检查。关键是让验证命令成为任务的一部分。
4. 用 diff 和审查结果决定是否合并
合并前确认：改动只覆盖需求相关文件；新增测试能在失败时真正报错；错误处理和权限检查没有被绕过；依赖、构建产物和配置文件没有无意变化；任务说明、代码和测试三者一致。
发现问题时，用具体文件、行号和复现命令反馈，让 Codex 做一次小范围修复。修复后重新看 diff 和测试，不要直接接受整段重写。
5. 适合自动化的任务与不适合自动化的任务
适合自动化：补充重复测试、生成类型定义、整理文档、检查格式、根据明确规则更新小范围代码。不适合无人值守：生产部署、删除数据、修改权限系统、批量升级核心依赖、处理未脱敏用户数据。后者需要人工审批和可回退方案。
AIMI 与 AICNBOX 在团队流程中的位置
团队可以使用 AIMI（chat.aimirror123.com）或 AICNBOX（chat.aicnbox.com）先做需求澄清、文档改写、PPT 或图像素材整理，再把确定后的任务交给 Codex 修改仓库。这样能把内容讨论和代码执行分开。两个平台的实时能力与政策请以各自页面为准。
常见问题
Codex 工程协作教程中的 Git 分支为什么重要？
独立分支能隔离代理改动，便于查看 diff、运行测试、回退和发起审查。没有分支保护时，错误改动更容易混入主分支。
Codex 自动化任务可以直接部署生产环境吗？
不建议默认允许。生产部署涉及权限、数据和回滚，应由 CI、审批和人工检查共同控制，Codex 只负责明确范围内的准备工作。
Codex 如何参与 Code Review 才不会变成形式？
要求它按严重程度给出文件、行号、触发条件和影响，并让人工复现关键问题。没有证据的泛泛建议不应直接转成修改。
AIMI、AICNBOX 和 Codex 如何组合使用？
先用 AIMI 或 AICNBOX 整理需求、文档或视觉素材，再用 Codex 执行仓库内的编码和测试任务；最终合并仍由团队按 Git 和 CI 规则完成。