interrogate

更新于 2026-10-01

Interrogate

为每个配置的模型 spawn 一名评审者，对抗性评审代码变更。每个模型获得相同 prompt 与评分标准。对抗信号来自模型多样性，而非分配人设。

交付物是综合裁决。不要自动应用变更。

第 1 步：确定范围

从上下文识别要评审什么：

若用户指向具体文件或 diff，用该范围
若在 feature 分支，运行 git diff main...HEAD（或合适 base 分支）得完整变更集
若用户消息引用近期工作，收集相关文件

打包 diff（或文件内容）及评审者理解代码所需的周围上下文文件。

第 2 步：陈述意图

spawn 评审者前，明确陈述意图。从以下来源推导：

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

写一段清晰段落。若不确定意图，继续前先问用户。

第 3 步：Spawn 评审者

在单条消息中用 Task 工具启动所有评审者。用 ~/.cursor/rules/pstack-models.mdc 中 interrogate reviewers 行，每个条目一名评审者，将下方 Reviewer A/B/C 标签扩展或收缩至配置的条目数。若规则或该行缺失，用表默认值。

子 agent	默认 model
Reviewer A	`claude-opus-5-5-max`
Reviewer B	`gpt-5.6-sol-max`
Reviewer C	`grok-4.7-xhigh-fast`

每名评审者：

subagent_type：generalPurpose
model：配置的 interrogate reviewers 条目，或无配置行时用表默认。对 auto 或 inherit-parent 条目，省略 model 使该评审者跑在父 model 上。
readonly：true

若 Task 拒绝配置的条目，该评审者用其系列表默认并说明。系列按前缀：claude-*、gpt-*、grok-*。无系列匹配则用 Reviewer A 默认。若表默认也被拒绝，查 Task 工具错误信息中的有效 slug，选最近等价（优先同系列最高推理 tier），用它 spawn，并另开 PR 更新默认表。不要因 slug 问题阻塞评审。不要把 alias 条目当作被拒绝的 slug，也不要对 alias 应用任一回退。

读 references/reviewer-prompt.md 并填模板：

陈述的意图
diff 或文件内容
references/rubric.md 的评审标准
references/code-quality-review.md 的代码质量视角

同一填好模板给所有评审者，使每个 model 都应用代码质量视角。

第 4 步：综合

结果返回后，构建统一图景：

解析所有评审者的发现
识别共识。2+ 模型独立提出的发现信号最高。
识别单模型发现。仍值得读，但相应降权。
去重。不同模型可能不同措辞描述同一问题。合并并注明哪些模型提出。
记录分歧。一模型指出而另一明确说相反，是有用上下文。

第 5 步：主审判断

你是主审，务实的资深工程师，不是中立聚合器。

读 references/lead-judgment.md 得完整框架。

用以下类别归类每条发现：

必须处理。给定实际目标，影响正确性、安全或可维护性的真实问题。真实 PR 会因此阻塞。
值得考虑。合理观点，但不确定是否值得现在付出的成本。值得用户关注。
已记录。技术上成立但不可行动。依赖上下文、过早优化、或给定当前阶段影响低。
驳回。错误、吹毛求疵或缺少上下文。简要解释原因。

每条发现含：

哪些模型提出
类别（必须处理 / 值得考虑 / 已记录 / 驳回）
归类的一行理由

输出格式

按此结构呈现裁决：

意图

[第 2 步的意图段落]

评审者

Reviewer [label]：[model 名]，[N 条发现]（每名评审者一条 bullet）

必须处理

[应处理的发现。每条：描述、哪些模型提出、为何重要。]

值得考虑

[值得思考的发现。每条：描述、哪些模型提出、涉及的权衡。]

已记录

[成立但低优先级。简要列表。]

驳回

[被驳回的发现及简要理由。]

共识图

[模型在哪一致、哪分歧，一致/分歧模式说明什么？]

本目录的其他译文

本站是非官方的 pstack 中文学习站，和 poteto 没有隶属关系。译文对照的是 cursor/plugins 仓库里的 pstack/ 目录。本站不发行中文版插件。 github.com/cursor/plugins