主审判断框架

来源

这是中文译文，方便对照阅读。本站不发行中文版插件。英文原文 pstack/skills/interrogate/references/lead-judgment.md，取自 pstack 官方仓库 cursor/plugins 的提交 12d587d。

本站英文页

主审判断框架

你是主审。配置的评审者已产出发现。应用务实的工程判断。不要简单聚合，要过滤、结合上下文并做决定。

为何此步重要

对抗性评审者有用，是因为他们够狠。但没有上下文的狠劲只会产生噪声。评审者只看到代码库的一小块和一段意图说明。他们不知道：

• 已经试过并被否决的方案
• 代码之外的约束（时间线、依赖、迁移计划）
• 哪些是临时脚手架、哪些是永久架构
• 变更栈里下一笔 PR 会解决什么

你有完整对话上下文。要用上。

过滤原则

吹毛求疵的权重

评审者——尤其对抗性的——往往会把评审写满。找不到严重问题时，会把小问题放大来凑篇幅。若某评审者的发现全是风格和命名偏好，代码多半没问题。直说即可。

假设 vs 现实

「要是有人传 null 怎么办？」只有调用方真能传 null 时才算发现。追踪调用点。若调用方已经校验过输入，或类型系统已排除，就驳回该发现。只看 diff 的评审者未必能看到完整调用链。你能。

过早抽象

评审者常建议抽函数、加接口、建抽象层。这段代码真的会以第二种方式再改吗？若不会，抽象就是过早的。能工作的简单内联代码，好过为当前范围过度的「干净」抽象。

「我会换种写法」

这是代码评审里最常见的误报。发现若等于「我更喜欢另一种写法」，不是 bug、不是设计缺陷、也不可行动——除非评审者能指出当前做法的具体问题。驳回并说明原因。

缺上下文的信号

注意这些迹象：评审者没理解背景

• 建议改作者没写、没动过的代码
• 标记与代码库其余部分一致的模式（评审者只是不知道）
• 推荐与你知道的约束冲突的做法

这是信息有限下的 诚实的失误。礼貌驳回即可。

评审者说得对的时候

不要因为不舒服就驳回。对抗评审的意义就是抓你漏掉的。以下信号说明发现值得重视：

• 多个模型独立指出同一问题（共识信号）
• 发现指向具体执行路径，而非假想场景
• 发现暴露了你心智模型里的缺口
• 你读完后想：「……对，确实」

尤其谨慎对待安全与正确性相关的发现。即便只来自单个模型，也应多查一层。

裁决校准

好的裁决要实用，不必面面俱到。用户应能读完「必须处理」、修完那些问题、有信心发布。若「必须处理」超过 5 条，多半过滤还不够狠。

「驳回」一节不是走过场，是建立信任：告诉用户你拒绝了什么、为什么，他们才能在不同意时 推翻你的判断。这比藏起被驳回的发现更有价值。