企业官网建设流程全解析

pstack的interrogate技能解析：让3个模型联手摧毁你的diff

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude

pstack 是一套面向 AI 编程 Agent 的技能包（Skill Stack），支持 Claude Code、Codex、Copilot、Pi 等主流运行时。其中interrogate是它最有攻击性的技能：一次派出 3 个不同的 AI 模型，以"对手"身份围攻你的代码改动（diff），找出 Bug、设计缺陷和安全隐患，最后由主审汇总成一份分级裁决。这篇文章带你完整看懂这套多模型对抗式代码评审（multi-model review）是怎么运作的，以及你该如何配置和使用它。

一句话理解 interrogate：评审的火力来自"模型多样性" 🔍

大多数 AI 代码评审让一个模型"顺便看看代码"，结果往往客气、笼统、充满"可以考虑优化"。interrogate 的设计哲学完全不同，它的主指令只有一句话（见 reviewer-prompt.md）：

你是一名对抗式代码评审员。你不是来帮忙或鼓励的，你是来压力测试这份代码的。

关键点在于：对抗信号来自模型多样性，而不是给每个模型分配人设。3 个来自不同"脑回路"的模型，拿着同一份提示词、同一份评分标准，从独立视角攻击同一份 diff。如果两个模型各自独立地发现了同一个问题，那几乎可以肯定它是真问题——这就是所谓的"共识信号"（consensus signal）。

默认评审面板配置如下（可通过setup-pstack自定义，见 SKILL.md）：

面板以只读模式（readonly: true）运行：评审员只能看、只能跑git diff，不能改代码。最终交付物是一份综合裁决报告，绝不自动修改你的任何一行代码。

五步流程：从一份 diff 到最终裁决 ⚔️

整个技能定义在 interrogate/SKILL.md，流程分为五步：

第 1 步：圈定评审范围

从上下文判断要评审什么：用户指定的文件或 diff、当前分支相对主干的完整改动（git diff main...HEAD），或最近讨论的工作内容，并打包周边上下文文件一起发给评审员。

第 2 步：声明改动意图

在派出评审员之前，先用一段话明确"这次改动的意图是什么"（来自用户消息、提交信息或 PR 描述）。评审员被要求只挑战执行，不挑战意图——这让火力集中在"代码有没有实现好目标"上，而不是无休止地争论方向。

第 3 步：一次性派出全部评审员

在一条消息里并行启动所有评审子代理。每位评审员收到的模板完全相同，包含四要素：

1. 声明的意图（Intent）
2. 待评审的 diff 或文件内容
3. 评审评分标准（rubric.md）
4. 代码质量视角（code-quality-review.md）

每条发现必须标注严重级别（critical / warning / nit）、给出具体位置和证据链，"空报告"也是合法结果——找不到问题就直说"no findings"，禁止夸奖、禁止硬凑。

第 4 步：综合各模型发现

结果回来后做四件事：解析所有发现 → 找出共识（2 个以上模型独立提出的发现信号最强）→ 保留单模型发现（降权对待）→ 合并重复项，并记录模型之间的分歧。

第 5 步：主审拍板（Lead Judgment）

这一步是 interrogate 区别于"简单投票机"的灵魂。主审不是中立的聚合器，而是一名务实的资深工程师（判定框架见 lead-judgment.md）。它要过滤掉对抗式评审天然会产生的噪音：

• 吹毛求疵引力：找不到大问题的评审员会用风格建议凑数——全是 nit 说明代码大概率没问题；
• 假想 vs 实际："如果有人传 null 呢？"只有调用方真的能传 null 才算数；
• 过度抽象警告：不需要第二种变化的代码，不需要抽象；
• "我会写得不一样"：这是代码评审中最常见的误报，直接驳回并说明理由。

裁决报告长什么样？四级分类 + 共识地图 ✅

最终输出是一份结构化裁决，每条发现都会标注"由哪个模型提出"：

报告末尾还有一张Agreement Map（共识地图）：哪些点模型们一致、哪里出现分歧、这种分歧模式本身说明了什么。

值得强调的是：Dismissed 部分不是走过场，而是信任机制——它把主审驳回的理由摊开给你看，让你可以在不认同时推翻它的判断。另外，一个健康的裁决中 "Act On" 列表不应超过 5 条，超了说明主审过滤得不够狠。

快速上手：如何触发与配置 interrogate 🚀

触发方式：装好 pstack 插件后，直接说"interrogate 一下这个改动"、"挑战这份代码"、"stress test this diff"，或在支持斜杠命令的运行时输入/pstack:interrogate（命令一览见 docs/reference.md）。也可以什么都不做——在 poteto-mode 工作流里，当设计存在争议时，它会在发布前自动引入 interrogate（见 playbooks/feature.md）；开 PR 的子代理也会自动执行 interrogate +/deslop+/no-comments三连。

配置评审面板：运行setup-pstack技能，在覆盖表中修改interrogate reviewers一行即可增删评审员，例如：

interrogate reviewers: opus, fable, sonnet

列表多长就派几个评审员。还可以给角色追加推理强度（如opus @xhigh）。注意一个细节：如果运行时能访问的模型家族太少（比如只有一个厂商可用），技能会要求用不同的推理强度来制造多样性，并在裁决中注明"多样性已降低"。

评审到底看什么？评分标准里藏着高级工程师的直觉 🧠

评分标准（rubric.md）覆盖了六大视角，每一条都很"实战"：

• 正确性：边界值、错误是捕获还是被吞掉、幂等性（重跑两次会怎样）、并发访问如何序列化；
• 根因 vs 表象：重试逻辑是不是在掩盖一个坏掉的契约？"别做 X"的注释能不能变成类型约束或 lint 规则？
• 结构完整性：校验是否发生在系统边界？这次改动是"补丁式拼接"还是"本来就该长这样"？
• 可验证性：Bug 修复有没有配套测试？检查的是真实产物还是模型的自我汇报？
• 复杂度预算：为不存在的场景预留的参数和"以防万一"的代码路径，全部清掉；
• 安全：用户输入流向危险汇点（SQL、shell、eval）的路径必须被完整追踪出来。

叠加在上面的 代码质量视角 更狠：它要求评审员主动寻找"code judo"（代码柔术）式重构——不改变行为、却让整段复杂度消失的结构性简化；并立下明确红线：把一个 1000 行以下的文件推过 1000 行，默认视为必须解释的坏味道。

总结：什么时候该请出三位评审员？

一句话记忆：设计有争议、改动跨模块、要开 PR 之前，是 interrogate 的最佳战场。它的价值不在于"多看了几遍代码"，而在于用模型多样性制造独立视角、用共识信号过滤噪音、用主审框架把 30 条原始发现收敛成一份你读完就能安心发布的裁决。如果你的 diff 只是改了一个拼写，让它歇着；如果它动了系统的承重墙，让三个模型先把它拆一遍吧 🔨

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude