需要多模型对抗式代码审查时，用多个独立 LLM…

当你想要对代码改动做对抗式、多模型交叉审查（找盲点、压力测试、挑刺）时，用多个不同 LLM 各自独立评审同一份改动，再由你作为主评审综合出结论。

适用场景

解决思路

1. 确定审查范围：若用户指定了具体文件或 diff，就用它；若在功能分支上，运行 `git diff main...HEAD`（或对应的基线分支）获取完整改动集；若用户消息提到近期工作，收集相关文件。把 diff（或文件内容）连同评审员理解代码所需的上下文文件一起打包。
2. 在启动评审员之前，明确陈述意图。从用户消息、commit message、PR 描述（若有）以及代码本身推导意图，写成一段清晰的文字。如果不确定意图，先问用户再继续。
3. 在单条消息中通过 Task 工具一次性启动所有评审员。若存在 `~/.cursor/rules/pstack-models.mdc`，使用其中的 `interrogate reviewers` 列表，每个条目一个评审员，并按配置条目数量扩展或缩减 Reviewer A/B/C 标签；否则使用默认表格（Reviewer A: `claude-opus-5-5-max`，Reviewer B: `gpt-5.6-sol-max`，Reviewer C: `grok-4.7-xhigh-fast`）。
4. 为每个评审员设置：`subagent_type` 为 `generalPurpose`，`model` 为配置的 `interrogate reviewers` 条目或表格默认值，`readonly` 为 `true`。
5. 若某个 model slug 在启动子代理时被判定为无法解析，查看 Task 工具报错信息中的有效 slug，选择最接近的等价模型（优先同系列中推理层级最高的），用有效 slug 启动，并另开一个 PR 更新配置值或默认表格。不要因 slug 问题阻塞审查。若配置值为 `inherit-parent` 或 `auto`，则省略 `model`。绝不要把这两个别名当作损坏的 slug 而进入该回退流程。
6. 阅读 `references/reviewer-prompt.md`，用以下内容填充模板：1) 陈述的意图；2) diff 或文件内容；3) `references/rubric.md` 中的评审标准；4) `references/code-quality-review.md` 中的代码质量视角。同一份填充好的模板发给所有评审员，确保每个模型都应用代码质量视角。
7. 综合结果：1) 解析所有评审员的发现；2) 找出共识——被 2 个及以上模型独立提出的发现信号最强；3) 找出单一模型的发现——仍值得阅读，但相应降低权重；4) 去重——不同模型可能用不同措辞描述同一问题，合并并注明哪些模型提出；5) 记录分歧——若一个模型标记某问题而另一个明确表示相反，这对裁决是有用信息。
8. 作为主评审做判断：你是务实的资深工程师，而非中立的汇总者。阅读 `references/lead-judgment.md` 获取完整框架。把每条发现归入以下类别：**Act on**（真实问题，在给定实际目标下影响正确性、安全性或可维护性，会阻塞真实 PR）；**Consider**（合理观点，但你不确定现在处理是否值得其成本，值得用户关注）；**Noted**（技术上成立但不可操作，依赖上下文、过早优化或当前阶段影响低）；**Dismissed**（错误、吹毛求疵或缺少上下文，简要说明原因）。每条发现都要包含：哪些模型提出、所属类别、一句话归类理由。
9. 按以下结构输出裁决：### Intent（引用第 2 步的意图段落）；### Reviewers（每个评审员一条：Reviewer [标签]: [模型名], [N 条发现]）；### Act On（应处理的发现，每条含描述、哪些模型提出、为何重要）；### Consider（值得思考的发现，每条含描述、哪些模型提出、涉及的权衡）；### Noted（有效但低优先级，简要列表）；### Dismissed（被否决的发现及简要理由）；### Agreement Map（模型在哪里一致、在哪里分歧，以及这种一致/分歧模式说明了什么）。
10. 交付物是综合后的裁决。不要自动应用改动。

适用边界 · 注意事项

• 不要自动应用评审员提出的改动，只输出裁决。
• 若不确定代码改动的意图，不要直接启动评审员，应先询问用户。
• 不要把 `inherit-parent` 或 `auto` 当作损坏的 slug 而触发模型回退流程。