interrogate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Interrogate

代码质询

Spawn four reviewers on four different models to adversarially review code changes. Each model gets the same prompt and rubric. The adversarial signal comes from model diversity, not assigned personas. Models differ in blind spots, priors, and reasoning patterns. Agreement across models is high-confidence signal; lone-model findings are worth reading but lower confidence.

The deliverable is a synthesized verdict. Do NOT auto-apply changes.

基于四个不同模型生成四位审查者，对代码变更进行对抗式审查。每个模型使用相同的提示词和审查准则。对抗性信号来自模型的多样性，而非预设角色。不同模型的盲点、先验知识和推理模式各不相同。多模型达成共识的结论是高可信度信号；单一模型的发现虽值得参考，但可信度较低。

最终输出为综合审查结论。请勿自动应用任何代码变更。

Step 1, Determine Scope

步骤1：确定审查范围

Identify what to review from context:

If the user points at specific files or a diff, use that
If on a feature branch, run
```
git diff main...HEAD
```
(or the appropriate base branch) for the full changeset
If the user's message references recent work, gather the relevant files

Package the diff (or file contents) plus any surrounding context files the reviewers need to understand the code.

根据上下文确定审查对象：

如果用户指定了特定文件或差异内容，以此为审查对象
如果处于功能分支，执行
```
git diff main...HEAD
```
（或对应基准分支）获取完整变更集
如果用户消息提及近期工作内容，收集相关文件

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

Step 2, State the Intent

步骤2：明确审查目标

Before spawning reviewers, state the intent explicitly. What is this code trying to accomplish? Derive this from:

The user's message
Commit messages
PR description if one exists
The code itself

Write one clear paragraph. Reviewers challenge whether the work achieves the intent well, not whether the intent itself is correct. If you're unsure about the intent, ask the user before proceeding.

在生成审查者之前，需明确阐述审查目标。这段代码的目的是什么？可从以下来源推导：

用户消息
提交信息
若存在PR描述，参考该描述
代码本身

撰写一段清晰的说明。审查者将质疑代码是否能很好地达成目标，而非目标本身是否合理。若对目标存在疑问，请先询问用户再继续。

Step 3, Spawn Reviewers

步骤3：生成审查者

Launch all four in a single message using the Task tool, each with a different model.

Subagent	Model
Reviewer A	`claude-opus-4-8-thinking-xhigh`
Reviewer B	`gpt-5.3-codex-high-fast`
Reviewer C	`gpt-5.5-high-fast`
Reviewer D	`composer-2.5-fast`

For each reviewer:

```
subagent_type
```
:
```
generalPurpose
```
```
model
```
: the model from the table
```
readonly
```
:
```
true
```

If a model slug in the table is rejected as unresolvable when you try to spawn the subagent, check the valid slugs in the Task tool's error message, pick the closest equivalent (prefer the highest-reasoning tier of the same family), spawn with the valid slug, and open a separate PR to update this table. Do not block the review on the slug issue.

Read

references/reviewer-prompt.md

and fill in the template with:

The stated intent
The diff or file contents
The review rubric from
```
references/rubric.md
```
The code-quality lens from
```
references/code-quality-review.md
```

The same filled template goes to all four reviewers, so every model applies the code-quality lens.

Each reviewer produces structured findings as described in the prompt template.

使用Task工具在一条消息中启动四位审查者，每位对应不同模型。

Subagent	Model
Reviewer A	`claude-opus-4-8-thinking-xhigh`
Reviewer B	`gpt-5.3-codex-high-fast`
Reviewer C	`gpt-5.5-high-fast`
Reviewer D	`composer-2.5-fast`

每位审查者的配置如下：

```
subagent_type
```
:
```
generalPurpose
```
```
model
```
: 表格中的对应模型
```
readonly
```
:
```
true
```

若尝试生成子代理时，表格中的模型标识（slug）无法解析被拒绝，请查看Task工具错误信息中的有效标识，选择最接近的替代模型（优先选择同系列中推理能力最强的层级），使用有效标识生成子代理，并提交单独的PR更新此表格。请勿因标识问题阻碍审查流程。

阅读

references/reviewer-prompt.md

，并在模板中填入以下内容：

明确的审查目标
差异内容或文件内容
来自
```
references/rubric.md
```
的审查准则
来自
```
references/code-quality-review.md
```
的代码质量审查视角

所有四位审查者使用相同的填充后模板，确保每个模型都采用统一的代码质量审查视角。

每位审查者需按照提示词模板生成结构化审查结果。

Step 4, Synthesize

步骤4：综合分析

As results come back, build a unified picture:

Parse all findings from the four reviewers
Identify consensus. Findings raised by 2+ models independently are highest signal.
Identify lone-model findings. Still worth reading, but weight accordingly.
Deduplicate. Different models may describe the same issue differently. Merge these and note which models raised it.
Note disagreements. If one model flags something and another explicitly says the opposite, that's useful context for the verdict.

收到所有审查结果后，构建统一的分析视图：

解析所有结果：整理四位审查者的所有发现
识别共识：由2个及以上模型独立提出的发现是最高可信度信号
识别单一模型发现：此类发现仍值得参考，但需适当降低权重
去重合并：不同模型可能以不同方式描述同一问题，需将其合并并标注提出该问题的模型
记录分歧：若一个模型标记了某问题，而另一个模型明确提出相反观点，需将此作为结论的重要背景信息

Step 5, Lead Judgment

步骤5：主导判断

You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.

Read

references/lead-judgment.md

for the full framework. Reviewers only see a slice of the codebase. You have the full context (the goal, the constraints, the timeline, which tradeoffs were already considered). Use that context aggressively.

Categorize every finding into one of four buckets:

Act on. Real issues affecting correctness, security, or maintainability given the actual goals. These would block a real PR.
Consider. Legitimate points, but you're not sure they outweigh the cost of addressing them right now. Worth the user's attention.
Noted. Technically valid but not actionable. Context-dependent, premature optimization, or low-impact given the current stage.
Dismissed. Wrong, nitpicky, or missing context. Brief explanation why.

For each finding, include:

Which model(s) raised it
The category (act on / consider / noted / dismissed)
A one-line rationale for the categorization

你作为首席审查者，需以务实的资深工程师视角判断，而非中立的结果汇总者。

阅读

references/lead-judgment.md

获取完整判断框架。审查者仅能看到部分代码库内容，而你拥有完整上下文（目标、约束、时间线、已考虑的权衡因素），需充分利用这些上下文信息。

将每个发现归入以下四个类别之一：

立即处理：影响代码正确性、安全性或可维护性的实际问题，此类问题会阻碍PR合并
考虑处理：合理的观点，但不确定解决这些问题的成本是否超过收益，值得用户关注
记录在案：技术上有效但暂无行动必要，例如依赖上下文、过早优化或当前阶段影响较小的问题
予以驳回：错误的观点、吹毛求疵或缺乏上下文的问题，需简要说明驳回理由

每个发现需包含以下内容：

提出该发现的模型
类别（立即处理/考虑处理/记录在案/予以驳回）
分类的单行理由

Output Format

输出格式

Present the verdict in this structure:

审查结论需按照以下结构呈现：

Intent

审查目标

[The stated intent paragraph from Step 2]

[步骤2中撰写的审查目标段落]

Reviewers

审查者信息

Model A: [model name], [N findings]
Model B: [model name], [N findings]
Model C: [model name], [N findings]
Model D: [model name], [N findings]

模型A：[模型名称]，[N项发现]
模型B：[模型名称]，[N项发现]
模型C：[模型名称]，[N项发现]
模型D：[模型名称]，[N项发现]

Act On

立即处理

[Findings that should be addressed. For each: description, which models raised it, why it matters.]

[需处理的发现：每项需包含描述、提出模型及重要性说明]

Consider

考虑处理

[Findings worth thinking about. For each: description, which models raised it, tradeoff involved.]

[值得思考的发现：每项需包含描述、提出模型及相关权衡因素]

Noted

记录在案

[Valid but low-priority. Brief list.]

[有效但低优先级的发现：简要列表]

Dismissed

予以驳回

[Rejected findings with brief rationale. This shows the user what was filtered out and why, so they can override your judgment if they disagree.]

[被驳回的发现及简要理由：向用户展示过滤内容及原因，以便用户在不同意时推翻判断]

Agreement Map

共识与分歧图谱

[Where did models agree, where did they diverge, and what does the pattern of agreement/disagreement tell us?]

[模型达成共识的领域、存在分歧的领域，以及共识/分歧模式所反映的信息]