interrogate

质询

为每个已配置的模型各启动一名审查者，对代码变更进行对抗式审查。每个模型使用相同的提示词和评审标准。对抗信号来自模型的多样性，而非指定的人设。模型的盲点、先验和推理模式各不相同。多个模型达成一致是高置信度信号；单个模型提出的问题值得关注，但置信度较低。

交付内容是一份综合结论。不要自动应用任何变更。

第 1 步：确定范围

根据上下文确定要审查的内容：

• 如果用户指定了特定文件或差异，就按指定内容审查
• 如果当前处于功能分支，运行 git diff main...HEAD（或适当的基准分支）查看完整变更集
• 如果用户的消息提到了近期工作，就收集相关文件

打包差异（或文件内容）以及审查者理解代码所需的上下文文件。

第 2 步：说明意图

启动审查者之前，明确说明意图。这段代码要实现什么？根据以下内容推断：

• 用户的消息
• 提交消息
• PR 描述（如有）
• 代码本身

写一段清晰的文字说明。审查者应评估这项工作是否充分实现了意图，而非质疑意图本身是否正确。如果不确定意图，请先询问用户。

第 3 步：启动审查者

在同一条消息中，为已配置的 interrogate 列表中的每个模型启动一名审查者（默认模型为 claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）。

每名审查者需满足：

• subagent_type：generalPurpose
• model：已配置的 interrogate 列表中的一个模型
• readonly：true

如果尝试启动子 Agent 时，某个已配置的模型标识符被拒绝，提示无法解析，请检查 Task 工具错误消息中的有效标识符，选择最接近的模型（优先选择同系列中推理能力最高的等级），并使用有效标识符启动审查者，同时另开一个 PR 更新已配置的默认值。不要因模型标识符问题而暂停审查。

阅读 references/reviewer-prompt.md，并填写模板中的以下内容：

1. 已说明的意图
2. 差异或文件内容
3. references/rubric.md 中的评审标准
4. references/code-quality-review.md 中的代码质量审查视角

所有审查者都使用相同的完整模板，因此每个模型都会应用代码质量审查视角。

每名审查者都应按照提示词模板中的说明，生成结构化审查结果。

第 4 步：综合结果

随着审查结果陆续返回，形成统一结论：

1. 解析所有发现
2. 识别共识：由至少 2 个模型独立提出的问题具有最高信号强度。
3. 识别单个模型的发现：仍值得关注，但应相应降低权重。
4. 去重：不同模型可能用不同方式描述同一问题。合并这些问题，并注明是哪些模型提出的。
5. 指出分歧：如果某个模型标记了问题，而另一个模型明确表达了相反观点，应在结论中说明这一背景。

步骤 5：首席评审判断

你是首席评审，一位务实的资深工程师，而不是中立的汇总者。

阅读 references/lead-judgment.md，了解完整的框架。评审者只能看到代码库的一部分。你掌握完整背景（目标、约束、时间安排，以及已经考虑过的权衡）。请充分利用这些背景。

使用以下类别对每项发现进行分类：

• 采取行动。根据实际目标，确实会影响正确性、安全性或可维护性的问题。这些问题会阻碍真实 PR 的合并。
• 考虑。合理的意见，但你不确定现在解决它们是否值得付出相应成本。值得提醒用户关注。
• 记录。技术上有效，但目前无法采取行动。这些意见取决于具体背景、属于过早优化，或在当前阶段影响较小。
• 驳回。错误、吹毛求疵或缺少背景。简要说明原因。

对每项发现，请注明：

• 哪个模型提出了该意见
• 类别（采取行动／考虑／记录／驳回）
• 一句话说明分类理由

输出格式

请按以下结构给出结论：

意图

[步骤 2 中陈述的意图段落]

评审者

每位评审者单独占一行，格式如下：- <模型名称>：[N 项发现]

采取行动

[应当处理的发现。对于每项发现，请说明内容、由哪些模型提出，以及它为何重要。]

考虑

[值得斟酌的发现。对于每项发现，请说明其中涉及的权衡。]

记录

[有效但优先级较低的意见。简要列出。]

驳回

[驳回的意见，并简要说明理由。这样可以让用户了解哪些意见被筛除以及原因，便于他们在不同意时提出异议。]

共识图

[模型在哪些方面达成一致，在哪些方面存在分歧？共识与分歧的模式说明了什么？]