Codex Team（通用多角色协作）

一套与执行后端无关的多角色协作方法。它只规定角色边界、任务合同、审查与验收规则， 不规定谁来执行、用哪个模型、用哪种会话或监控实现。

一句话：协调者把一个可验收的目标拆成带读写边界的工作包，交给合适的角色；审查与验收 角色独立于实现者，失败必须带着证据返回修复。

何时使用

• 任务需要多步实现 + 独立验证，或需要探索、实现、审查分离；
• 任务可以被拆成写作用域不冲突、可独立验收的若干单元。

何时不要使用

• 单文件、单步骤、结果自明的改动：直接做。不要为了“像团队”而拆成多角色，也不要为此 开启任何团队流程。
• 需要的能力当前执行者没有（例如没有图像生成工具、没有视觉能力）：先如实说明能力限制， 再决定是换执行者、换工具，还是缩小任务范围。

简单任务直接执行是本方法的正常路径，不是例外补充：没有团队就没有“多角色”要求， 也就不存在独立审查这一环。直接执行时不要声称做过独立审查。

加载顺序

1. 本文件（入口与规则总纲）。
2. references/roles.md — 角色职责、只读/可写边界、按需启用。
3. references/workflow.md — 工作包合同、调度、审查、失败返回、验收。
4. 需要给人或机器填写任务时使用 assets/WORK_PACKAGE.md 模板。

同一个角色可以一次承担多个任务，但一个成员同一时刻只应有一个活动任务。

与其他 Skill 组合

本方法可以和其他 Skill 一起使用，但不建立跨目录耦合：不要求先加载别的 Skill，不定义 优先级继承或覆盖关系，也不把本目录以外的文件列为必读。是否加载外部材料由使用者自行决定， 本方法不以此作为前置条件。

硬性规则（与本项目无关的通用部分）

• 单一负责人：每个任务恰好一个负责人；协调者掌握创建/依赖/改派，其他角色不自行改派。
• 写作用域：每个任务声明自己的可写路径与只读路径；只读角色不得修改任何文件。
• 独立审查：审查者不得审查自己实现的内容；审查结论必须给出可复现的证据。
• 失败返回修复：验证或审查失败时，任务带证据回到原实现者（或明确改派），不得由审查者 “顺手修好”以掩盖失败。
• 证据：结论必须能被第三方按记录复现（命令、退出码、输出、差异），不允许只给结论。
• 不重复劳动：同一个检查不为“再确认一次”跑两遍；一个结果已足够就不重复取第二个相同结果。
• 不虚构：不得声称发生过实际未发生的子代理调用、后台常驻、会话持久化或长时间监控。
• 能力诚实：图像生成/编辑需要真正的图像生成工具；视觉理解（识图、OCR、截图分析、 GUI 视觉判断、视觉验收）需要真正的视觉能力。两者是不同的能力，不可互相代替；缺少对应 能力时如实说明，不得用纯文本猜测代替，也不得把这类任务改名绕过限制。
• 后端解耦：模型、权限、并发上限来自用户与宿主配置。本方法不写死模型名，不规定固定的 权限模式，也不要求为简单任务开启团队。
• 规模克制：不为凑齐角色数量而拆任务；能直接做完的就直接做完。

与后端的关系

本方法定义“需要哪些角色、每个角色能写什么、怎么验收”。谁来执行由宿主决定：

• 宿主有原生子代理：直接使用，作为一等用法，不依赖任何外部后端。
• 宿主只能提供单一执行者：没有第二个执行者，就没有独立审查。此时如实说明这是 单执行者自检，不要把自检写成独立审查，也不要把同一个执行者扮演的不同角色说成 相互独立验收。可以仍然按工作包的清单逐项自查，但结论的独立性必须标注为不足。
• 可选后端（例如某个具体的远程/本地执行框架）只作为适配层接入：适配层负责把工作包 发送出去、把结果与证据取回并映射回本方法的角色边界。不要描述尚未实现的后端能力。

独立性取决于是否由不同执行者完成，与是否并行无关：不同执行者串行执行同样可以保持 独立审查。不要用“顺序执行”本身作为独立性不足的理由；没有第二个执行者才是。