# 交叉审查循环：Claude x Codex CLI ## 概述 Claude 和 Codex CLI 之间的自主审查修复循环。每轮：**同时且独立**进行审查→分类结果→使用最佳可用技能进行修复→重复。当干净时、审稿人不同意时或最大轮数后停止。 ## 先决条件 * Codex CLI 安装：`npm install -g @openai/codex` * Codex 已验证：`codex auth 登录` * 在 `~/.codex/config.toml` 中进行配置，启用模型、推理工作和多代理： # ~/.codex/config.toml （示例 - 将模型调整为您的可用版本）型号 =“gpt-5.3-codex” model_reasoning_effort = "xhigh" [特点] 多代理=真可以选择定义审阅者角色，以实现更丰富的多代理代码审阅： [代理.安全审查者] 描述 =“查找安全漏洞、身份验证问题、注入风险和数据泄露。” config_file =“代理/审阅者.toml” [代理.绩效评审员] 描述 =“查找性能瓶颈、N+1 查询、内存泄漏和可扩展性问题。” config_file =“代理/审阅者.toml” [代理.测试审稿人] 描述 =“查找测试覆盖范围差距、缺失的边缘情况和片状测试风险。” config_file =“代理/审阅者.toml” 其中 `agents/reviewer.toml` 包含：型号 =“gpt-5.3-codex” model_reasoning_effort = "高" developer_instructions =“关注高优先级问题。具体说明：参考文件路径、行号和具体示例。” ## 清单按顺序执行每个步骤，完成一个步骤后再进行下一个步骤： 1. **检测工件类型** — 确定正在审查的内容（计划、代码、架构、设计） 2. **进行一轮审查** — 同时并行启动 Claude 代理和 Codex，然后收集结果并进行分类 3. **应用修复** — 发现最佳技能，调用它来修复可自动修复的问题 4. **检查退出条件** — 存在分歧？都干净了吗？最大回合数？决定是否循环或停止 5. **呈现结果** — 显示用户最终状态、剩余问题或所需决策 6. **清理中间文件** — 运行 `bash "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-reviews.sh"` （强制，无论退出原因如何） ## 核心工作流程有向图 cross_review_loop { 排名目录=TB；节点[形状=盒子]； “检测工件类型”->“启动并行审阅者”； “启动 PARALLEL 审阅者”->“生成 Claude 代理团队（3-5 个审阅者）”； “启动并行审阅者”->“run-codex-review.sh（后台）”； “生成克劳德代理团队（3-5个评论者）”->“等待：收集两个评论”； “run-codex-review.sh（背景）”->“等待：收集两条评论”； “等待：收集两条评论”->“关闭代理团队”； “关闭代理团队”->“保存两个审核文件”； “保存两个评论文件”->“分类：对结果进行分类+交叉验证”； “分类：对结果进行分类+交叉验证”->“有任何分歧吗？” [形状=钻石]； “有什么不同意见吗？” ->“停止：呈现给用户”[label=“yes”]； “有什么不同意见吗？” ->“有任何可自动修复的问题吗？” [标签=“否”]； “有任何可自动修复的问题吗？” ->“发现修复的最佳技能”[label="yes"]; “有任何可自动修复的问题吗？” ->“cleanup-reviews.sh”[标签=“否”]; “发现修复的最佳技能”->“调用技能/修复内联”； “调用技能/修复内联”->“保存组合评论轮N.md”； “保存组合审查轮-N.md”->“最大轮次？” [形状=钻石]； “最大回合数？” ->“cleanup-reviews.sh”[标签=“是”]; “最大回合数？” ->“启动并行审阅者”[label="no, N++"]; “cleanup-reviews.sh”->“显示结果”； } ## 步骤 1：检测工件类型检查要分类的目标文件：信号|神器类型 ---|--- `*-计划*.md`、`*实施计划*`、`*-任务*` | **计划** `*-design*.md`、`*-architecture*`、`*-spec*` | **架构** `*.cs`、`*.ts`、`*.py`、`*.js`、`*.go`、`*.rs` （源文件） | **代码** `docs/` 或 `plans/` 中的其他 `*.md` | **设计文档** 设置“ARTIFACT_TYPE”以用于技能发现和 Codex 脚本调用。 ## 第 2 步：进行审核（并行） **关键：同时启动 Claude 代理和 Codex。不要等到其中一个才开始另一个。** 两者都独立审查；交叉验证发生在分类期间。 ### 2a。启动法典（背景）通过插件脚本作为 **后台 bash 进程** 运行 Codex (`run_in_background: true`)： **对于代码工件：** bash "${CLAUDE_PLUGIN_ROOT}/scripts/run-codex-review.sh" 代码 docs/plans /path/to/project main 该脚本运行“codex review --base main”——专为具有多代理支持的代码审查而构建。不传递自定义提示（“--base”和“[PROMPT]”在 Codex CLI 中是互斥的）。 **对于非代码工件：** bash "${CLAUDE_PLUGIN_ROOT}/scripts/run-codex-review.sh" <计划|架构|设计> docs/plans /path/to/project target-file1.md target-file2.md 该脚本从“prompts/codex-base.txt”\+特定于工件的片段组装提示，然后运行“codex exec --full-auto”。基本提示指示 Codex 在每个审阅焦点区域生成一个代理（需要配置中的“multi_agent = true”）。 ### 2b。启动 Claude Agent Team（与 Codex 并行）在启动 Codex 的同时**产生克劳德特工团队。不要等待法典。 **核心审阅者**（始终产生这三个）：代理名称 |焦点 |子代理类型 ---|---|--- `安全审查员` |身份验证、注入、验证、秘密、数据暴露 | `通用` `绩效审核员` |瓶颈、N+1 查询、内存泄漏、可扩展性 | `通用` `测试评审员` |测试覆盖范围差距、缺失边缘情况、不稳定的测试风险 | `通用` **其他审阅者**（当工件需要时出现，总共最多 5 名）：代理名称 |何时生成 |焦点 ---|---|--- `建筑师-审阅者` |复杂的多组件变化，新系统|模式、关注点分离、可扩展性、部署 `需求评审员` |计划或规范工件、功能实现 |需求覆盖率、完整性、缺失验收标准使用代理工具将每个审阅者生成为代理团队中的后台代理。始终使用`model: "opus"`。每个审阅者提示应该： 1. 接收要查看的目标文件路径 2. 知道这是第 N 轮（如果 N > 1，则仅查看第 N-1 轮修复的增量） 3. 以严重性格式输出结果（严重/高/中/次要） 4. 返回包含结果的摘要消息 **团队生成模式：** TeamCreate: team_name = "交叉评审-N轮" 对于每个审阅者，请使用代理工具： - subagent_type：“通用” - 型号：“opus” - team_name：“交叉评审-N轮” - 名称：“<代理名称>” - 在后台运行：true - 提示：| 您是<焦点领域>审阅者。查看这些文件：<文件列表>。这是第 N 轮。<如果 N > 1：仅审查上一轮修复的更改。> 将您的发现结构化为： ### 关键问题（阻碍进展） ### 高问题（导致错误或架构问题） ### 中等问题（质量、一致性） ### 小问题（很高兴有）具体：参考文件路径、行号和具体示例。 ### 2c。收集两条评论并行启动后： 1.等待所有Claude代理消息到达，合成到`docs/plans/review-claude-round-N.md` 2. 等待 Codex 后台 bash 作业完成（检查 `docs/plans/review-codex-round-N.md` 是否存在且非空） 3、本轮关闭克劳德特工团队 **克劳德审查文件结构：** # N 轮交叉评审 — Claude（特工团队） **目标：** <文件> **日期：** <日期> **范围：** <全面审查| N-1 轮的增量> **评论者：** <产生的代理列表> ## 安全审查 ### 严重/高/中/次要问题 ## 绩效评估 ### 严重/高/中/次要问题 ## 测试覆盖率审查 ### 严重/高/中/次要问题 **关于输出格式的注意事项：** Claude 的审核按审核者领域（安全性 → 严重性、性能 → 严重性等）对结果进行分组，因为每个代理都是独立报告的。 Codex 的审查采用全球严重性优先的分组方式。分类步骤可以协调两种格式。 ## 步骤 3：分类结果两次审查完成后，对每项发现进行综合和分类。 **这就是交叉验证发生的地方**——比较两个独立的评论，找出他们同意和不同意的地方。 ### 分类规则对于两条评论中的每个独特发现： **可自动修复** - 两位审阅者都同意问题存在并且修复是明确的： * 两者都指出相同的问题（即使措辞不同） * 修复是一个具体的、具体的更改（不是设计决策） * 无需权衡或替代方法来权衡 **需求决定** — 以下任何条件： * 审稿人对于这是否是一个问题存在分歧 * 审稿人对严重程度意见不一（例如，Claude 说“中”，Codex 说“高”） * 审阅者针对同一问题提出不同的修复方案 *修复需要在方法之间进行选择 *修复有副作用或权衡 **信息性** - 两者均被评为“轻微”且无需采取具体行动 ### 输出格式保存到“docs/plans/combined-review-round-N.md”： # N 轮综合评审 ## 交叉验证总结 ### 协议（两位审稿人均已标记） - [严重性] 描述 — 克劳德：<发现>，法典：<发现> ### 分歧（审稿人冲突） - 描述 — 克劳德：<位置>，法典：<位置> ## 分类总结 |寻找|克劳德|法典|分类|行动| |--------|--------|--------|----------------|--------| | ... | ... | ... |自动修复 |修复 X | | ... | ... | ... |需求决策| ... | ## 自动修复问题 <包含具体修复操作的列表> ## 需要决定（阻塞） <包含两个视角的列表，供用户判断> ## 信息 <列表，无需执行任何操作> ## 步骤 4：通过技能发现应用修复 ### 动态技能发现根据“ARTIFACT_TYPE”在可用技能列表中搜索最佳匹配：神器类型|搜索关键词 ---|--- **计划** | “编写计划”、“执行计划”、“计划” **架构** | “建筑师”、“建筑”、“头脑风暴”、“设计” **代码** | `coder`、`code-review`、`implementation`、`feature-dev` （更喜欢特定于项目的） **设计文档** | “头脑风暴”、“写作计划”、“设计” ### 技能选择优先 1. 首先是特定于项目的技能（例如“unity-coder”、“unity-architect”） 2.通用技能第二（例如“写作计划”、“头脑风暴”） 3.如果没有找到匹配的技能并且修复很简单→应用内联（直接编辑） 4. 如果没有找到匹配的技能并且修复也很重要 → 停止，询问用户 ### 应用修复当调用发现的技能时： * 将可自动修复的结果列表作为上下文传递 * 技能根据自己的工作流程处理实际的编辑 * 技能完成后，验证修复是否已应用修复内联时（无可用技能）： * 使用编辑工具直接应用每个修复 * 尽量减少变更并专注于具体的发现 ## 步骤 5：检查退出条件每轮结束后，按顺序评估： 1. **在分类中发现分歧？** → **退出循环**。呈现“需求决策”项目，然后清理。 2. **所有问题都解决了吗？** → **退出循环**。呈现摘要，然后清理。 3. **达到最大轮次？**（默认值：3）→ **退出循环**。提出剩余的问题，然后清理。 4. **没有可用于重要修复的技能？** → **退出循环**。询问用户，然后清理。如果以上都不是→ **增加 N 并循环回到步骤 2**。 **关键：每个退出路径都通向步骤 6（当前结果），然后是步骤 7（清理）。切勿跳过清理。** ## 步骤 6：展示结果当循环退出时，呈现清晰的摘要： ## 交叉评审完成 **轮次：** N **退出原因：** <全部干净|分歧|最大回合 |没有技能> ### 已解决的问题 <所有轮次修复的问题列表> ### 剩余问题（如果有） <具有两种观点的需求决策项目> ### 需要做出的决定（如果有） <用户提出的具体问题，以及两位审阅者的背景> ## 步骤 7：清理中间文件（强制）运行清理脚本——无论退出原因如何，这都是强制性的： bash "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-reviews.sh" 文档/计划 **请勿删除**已审核的目标工件文件 - 仅删除审核轮文件。 **不要跳过此步骤** - 留下中间文件是一种已知的故障模式。 ## 迭代规则 * **默认最多 3 轮** — 仅由用户指令覆盖 * **第 N+1 轮仅审查增量** - 第 N 轮修复的更改，而不是完整的重新审查 * **每轮生成 3 个文件：** `review-claude-round-N.md`、`review-codex-round-N.md`、`combined-review-round-N.md` * **审核循环完成后，所有中间文件都会被删除**（第 7 步 — 强制） * **永远不要默默地解决分歧** - 任何审稿人冲突都会停止循环 * **技能调用是每轮** - 每轮重新发现技能（可用技能可能会改变） * **代理团队是每轮** — 为每轮 Claude 审核创建一个新的代理团队，收集结果后将其关闭 * **Codex 是每轮** - 每个 Codex 调用在该轮中都是新鲜运行的 * **两位审阅者同时开始** - 永远不要等待一个审阅者才启动另一个审阅者 ## 常见错误 * **在启动 Codex 之前运行 Claude 代理完成** — 两者必须同时启动；首先使用 `run_in_background: true` 启动 Codex 脚本，然后在同一回合中生成 Claude 团队 * **将 `--base` 与 `codex review` 中的提示结合使用** — `codex review --base ` 和 `[PROMPT]` 是互斥的；该脚本可以正确处理此问题，但如果手动运行，请单独使用“codex review --base main” * **将 Claude 的审阅传递给 Codex** — Codex 并行运行，看不到 Claude 的审阅；交叉验证发生在分类期间 * **不在 Codex 配置中启用`multi_agent = true` - 如果没有它，Codex 将作为单个代理运行，而不是产生专门的审阅者 * 在没有“--full-auto”的情况下运行“codex exec”会导致它挂起等待批准（“codex review”已经是非交互式的） * 跳过分类并仅应用两条评论会导致矛盾的修复 * 每轮审查相同的问题，而不仅仅是增量 * 在没有用户输入的情况下解决分歧——这是要避免的第一大错误 * 硬编码技能名称而不是动态发现它们 * 收集结果后不关闭克劳德特工团队——跨轮泄漏资源 * 审核完成后留下中间审核轮次文件 — 始终运行 `cleanup-reviews.sh` * 生成的 Claude 审阅者太少（总是生成至少 3 个：安全性、性能、测试覆盖率） * 为琐碎的更改产生太多审阅者 - 3 是基线，只有在复杂性需要时才添加更多审阅者

交叉审查

包含技能