用途
Simmer Judge Board 是 simmer 的评审团子技能，用于在迭代优化流程中替代单个评审。它派出一组持有不同视角的评审，让他们独立打分、进行一轮审议并相互挑战分数，最终收敛为共识分数与一个 ASI（最高杠杆改进方向）。评审团的输出与单个评审的输出完全相同，编排器、reflect 与生成器都无法分辨差异。
采用评审团的理由是：单个评审存在盲点，会锚定最先注意到的内容，其 ASI 只反映单一视角。三位不同视角的评审能捕捉不同问题并相互挑战，审议产生的 ASI 因盲点被暴露而更强。这在迭代进入平台期时尤为重要——当单个评审因看不到真正瓶颈而反复建议同一类修复时。
主要能力
接收的上下文
评审团接收与单个评审相同的上下文（由编排器传入）：当前候选（完整产物文本或关键工作区文件）、评分标准（2-3 条标准及 10/10 的描述）、迭代编号、种子校准（迭代 1+：原始种子 + 迭代 0 分数）、评估器输出（评估器模式下为评估器命令的 stdout/stderr）、上下文纪律附加项（仅代码/流水线：先前 ASI、迭代历史、搜索空间、探索状态）。
评审团特有上下文包括：JUDGE_PANEL（可选，来自设置简报的自定义评审定义）、问题类别（文本/创意、代码/可测试、流水线/工程）、ARTIFACT_TYPE（单文件或工作区，决定生成器可更改的内容）、SEARCH_SPACE（若定义，明确可探索范围的边界）、BACKGROUND（约束、可用资源、执行环境，评审需据此校准 ASI）、上一轮审议摘要（迭代 2+，结构为 WORKING / NOT WORKING / DIRECTION）。
变更边界
评审必须理解生成器实际能更改什么。单文件模式下生成器只能更改产物文本内容（提示词、文档、配置文件），不能更改模型选择、代码、基础设施、流水线拓扑或新增文件。工作区模式下生成器可更改工作区目录内任意文件（代码、配置、提示词、脚本、新增文件），但不能更改工作区之外或搜索空间之外的外部基础设施。若定义了 SEARCH_SPACE，则进一步约束范围。评审产出的每个 ASI 都必须在此边界内可执行。
评审在打分前必须阅读相关产物：候选、评估器脚本、配置文件、先前候选，理解系统如何运作以及分数为何如此。若遇到不知如何修复的失败模式，应先研究方案。ASI 应来自理解，而非读指标猜测。
使用方式
阶段一：独立打分（并行）
派出 3 位评审作为并行子代理。每位接收完整评审上下文外加唯一的 LENS 分配。每位评审调用 simmer:simmer-judge，复用现有评审技能，lens 作为前置上下文框定其视角。
面板成员提示词模板要求：先调查（迭代 0 读评估器脚本理解打分方式、读真值理解理论上限、读背景约束；每次迭代读候选文件、代码/流水线读先前候选、遇到未知失败模式先搜索方案），再打分（从自身视角对所有标准打分，而非只打一条），最后给出 ASI（须在生成器边界内可执行、引用调查发现、引用先前迭代、若搜索过则引用搜索结果）。
每位面板成员产出标准评审输出格式：ITERATION [N] SCORES、COMPOSITE、ASI。
阶段二：审议（一轮）
收集所有独立分数后，进行一轮审议。每位评审看到其他评审的分数与推理（但暂不看到其 ASI 候选，ASI 审议在综合阶段进行）。审议提示词要求对每条标准：同意则简述、不同意则挑战并引用证据、被说服则让步并修订分数。仅一轮，直接了当。
仅一轮的原因：迭代审议有收敛到最大声音的风险。一轮“看到并反应”能在不丧失独立性的前提下暴露盲点。暂不公开 ASI 候选的原因：若评审在审议中看到彼此的 ASI，会锚定他人方向而非捍卫自身视角。
阶段三：综合（书记员）
由评审团编排器充当书记员，内联运行，无需子代理。
第一步：共识分数。对每条标准取审议后分数（让步者用修订分，坚持者用原分）。全部在 1 分以内用中位数并注明一致；审议后仍有 2 分以上差距用中位数并注明张力及分歧原因。综合分为平均值，保留一位小数。
第二步：综合 ASI。阅读三位评审的独立 ASI 候选及审议要点，然后提炼而非选择。识别单一最高杠杆动作；检查与面板结论的一致性；检查生成器可行性；保持聚焦（一个方向、一个主要变更）。
第三步：审议摘要（供下一轮面板使用）。写结构化摘要，含三部分：WORKING（保留，勿移除或更改）、NOT WORKING（勿重试同一方法）、DIRECTION（面板关于下一步的结论，一句话）。若可用，纳入 reflect 子技能的 STABLE WINS。
第四步：输出。产出标准评审输出格式，与单个评审产出完全一致。
评审团构成
评审团在运行开始时一次性组建，针对具体问题定制。它读取产物、标准、背景、评估器与约束，然后构建 3 位持有不同视角的评审。这些评审在每轮迭代中复用——每轮获得更新上下文（评估器输出、稳定胜利、审议摘要），但视角与能力保持固定。
组建流程：读取完整问题上下文；设计 3 位持有不同视角的评审（问“评估此产物最不同的 3 种方式是什么”）；从原语库为每位评审赋予相关能力。
评审原语库包括：核心（适用于所有评审）——通过种子校准打分、打分前先诊断、保护高分元素、从自身视角对所有标准打分；评估器存在时——按类型聚类评估器失败、从有损来源验证专有名词、标记评估器随机性；涉及探索时——回顾已尝试内容、标记天花板、卡住时研究。
适用场景
适用于 simmer 迭代优化流程中需要多视角评审的场景，尤其是迭代进入平台期、单一评审反复给出同类修复建议时。示例组合包括：带评估器的代码/流水线（评估器分析师、约束现实主义者等）、DND 冒险钩子（工艺、玩家、DM）、冷启动外联邮件（文案、收件人、送达率）。
限制
审议仅进行一轮，以避免收敛到最大声音。ASI 候选在审议阶段不公开，以防锚定。评审团输出与单个评审输出格式相同，编排器无法区分。单文件模式下生成器只能编辑文本，不能提议代码更改、模型替换或架构更改，除非产物类型为工作区。若瓶颈超出生成器边界，应说明，由书记员建议提前终止或模式变更。