work-judge

/work-judge — 生成式设计 / 方案评审小组

此技能实现了 评审小组 质量模式：通过生成多样化候选方案来探索广阔的解决方案空间，根据证据评判这些方案，并综合出一个吸收其他方案优点的胜出方案。

这是质量系统中的一种模式。编排模型（形态、机制、架构约定）位于 ../work/references/workflow-mode.md； 它要防范的失效模式见 ../work/references/anti-error-lessons.md （经验 L1–L8）。此技能将这些内容付诸实践，而非重复阐述。

适用场景

• 解决方案空间广阔：架构、设计权衡、“我们应该如何实现此功能？”
• 你想明确探索多个角度，而不是只采用一个“最佳猜测”。
• 不适用于纯粹验证已有主张 → 使用 ../work-refute/SKILL.md。
• 不适用于从已经构建好的实现中挑选方案 → 使用 ../work-tournament/SKILL.md（在 worktree 中进行锦标赛）。

与 work-refute 的区别：此技能是生成式的（产出候选方案）+ 比较评分+综合。对抗式则是破坏式的（试图推翻已有发现）。

L1 门槛——召集评审小组前，先用低成本方式解决问题

如果一个决策可以由确定性依据解决，就不要召集评审小组。 在启动任何操作前， 先问：是否有确定性答案？

• 失败/通过的测试、类型检查、基准测试、显示类似决策结果的 git log、能证明可行性的 20 行临时原型，或已经规定应如何选择的 AGENTS.md 规则。
• 如果只需一条命令的判定工具或临时验证就能解决问题，就运行它、记录 决策并跳过评审小组。 对已经有定论的问题，用 1-of-N 个通用角度组成的“评审小组” 只是作秀（L1，以及 workflow-mode §5 中的 Scale-to-the-ask）。

评审小组适用于确实开放、且没有低成本判定工具的设计空间。

用法

/work-judge [N=3] "the design problem or decision to explore"

选项：

• /work-judge 5 "problem description"
• 添加角度：/work-judge angles="MVP-first,risk-first,user-experience,performance,maintainability" "problem"
• 聚焦方向：/work-judge focus="security and multi-tenancy" "problem"

编排器 (../work/SKILL.md) 通常会将此技能作为更大型流程的设计阶段调用。

---

编排形态：并行 / 屏障

在分流并发前，在计划/待办事项中说明这一点（workflow-mode §1）。此评审小组采用 屏障模式，而非流水线，因为其中两个阶段确实存在跨条目依赖——必须等到 前一阶段的所有条目都生成后才能开始：

Generate   →  parallel fan-out: N candidate agents, one per angle  (no barrier among them)
   ║  BARRIER #1 — judging compares candidates against EACH OTHER → needs ALL candidates
Judge      →  parallel fan-out: judges score the full candidate set
   ║  BARRIER #2 — synthesis grafts across ALL verdicts → needs ALL judge verdicts
Synthesize →  single agent picks base + grafts the best of the losers

为何使用屏障（而非流水线）：评审者会相对于其他候选方案对候选方案进行排序， 而综合阶段会从各项评审结果中交叉汲取创意——这两者都涉及真实的跨条目比较，正是 workflow-mode §1 中所说需要使用屏障的情形。每个阶段内部的 Agent 会并发运行；屏障只是主 Agent 中简单的集合/收集逻辑，绝不是 Agent 调用。

提前退出（候选方案数量下限）：对候选方案进行空值过滤后（见“机制”）， 如果存活方案少于 2 个，就不要进行评审——没有可供比较的对象。终止 锦标赛，记录原因；然后要么将唯一的存活方案作为非比较草案返回，要么重新生成已失败角度的方案一次。一个人的“评审小组”不算评审小组。

评审者数量下限：每个候选方案都需要至少 1 个有证据支撑的评审结论（workDone:true）。 如果某个候选方案的所有评审者都弃权了（敷衍的评审结论，见下文 L8），则该候选方案 属于未经评审，而不是“得分为 0”——应重新计算并记录，绝不能把弃权当作分数。

---

阶段（编排）

通过你的流程编排工具的待办/计划功能宣布每个阶段（workflow-mode §3 日志/阶段）。阶段： "L1 oracle check" → "Angle coverage" → "Generating candidates" → "Judging" → "Synthesizing"。

0. 问题界定与角度覆盖检查（主 Agent）

• 明确决策、约束、成功标准和已知的判定依据（测试、现有代码、AGENTS.md 要求）。先运行上方的 L1 门槛。
• 角度覆盖预检（L5 — 完整性检查关注角度列表未覆盖的内容）。 生成方案前，逐项检查标准关注点清单，确认每项都由某个角度负责，或明确记录为范围外： security · multi-tenancy / isolation · data migration · rollback / reversibility · observability / operability · cost / quota。 未由某个角度覆盖、也未有意排除在范围外的关注点，都属于未被发现的缺口。将覆盖映射（关注点 → 角度或 out-of-scope: reason）写入决策记录。这对应生成阶段的 L5 问题：“范围未覆盖哪些内容？”

1. 并行生成多样化候选方案（扇出）

在单条消息中启动 N 个候选 Agent（并行子 Agent 调用），与 ../work-tournament/SKILL.md 的机制保持一致，确保生态系统协调统一：

• 子 Agent 角色：通用角色（纯设计且不写入文件时，使用仅规划角色）。
• 隔离：仅当候选方案会编写或运行代码（一次性原型 / 技术验证）时才使用隔离工作树。纯设计提案为只读 → 不使用工作树。
• 在后台运行。
• 描述："Candidate <id>"（中性 ID — 参见盲评）。
• 提示词：问题 + 分配的角度 + 候选方案约定：

  "你是候选者 <id>，是 <N> 个独立提案之一，采用 <angle> 视角。请从该角度提出一份完整、独立的提案。包括关键权衡、你有意降低优先级的事项、具体后续步骤 / 伪代码 / 数据结构，以及任何可通过测试 / 类型检查 / 原型验证的假设。 只返回下方的 Candidate JSON 对象。"

未指定时的默认角度：MVP-first、risk-first / safety、user-first、 performance / scalability、maintainability / simplicity。结合 L5 覆盖映射进行协调 — 如果 focus="security and multi-tenancy"，确保每项都有一个角度负责。

**并发上限（workflow-mode §3）：**分批启动，每批 min(16, cores−2) 个；超出的排队等待。切勿为了符合上限而悄悄删去某个角度 — 参见预算。

等待所有候选 Agent 完成，然后收集各自结果。

2. 评审（屏障 #1 — 需要全部候选方案）

所有候选方案均已返回并经过空值过滤后，针对完整候选方案集启动评审 Agent。评审者采用盲评（参见盲评），并遵循下方的强化评审约定。他们返回 Judge Verdict JSON。

3. 综合（屏障 #2 — 需要全部评审结果）

主 Agent（或专门的综合 Agent）按照字典序规则（见下文）汇总评审结果，选出最强的基础候选方案，并将落选方案中最佳的可嫁接思路 / 缓解措施 / 简化方案嫁接其中。输出：综合提案 + 评分表 + 嫁接思路列表 + 剩余风险 + 建议的直接验证步骤。

4. 优先直接验证（L1，再次执行，失败即关闭）

候选方案提出的每个可确定性检查的假设，都必须在最终确定建议前进行检查。任何未验证的假设都必须列入 openQuestions — 绝不默默假设其为真。

强化版评审契约（将 L2、L6、L8 落实为操作要求）

根据候选方案的自我报告打分的评审毫无价值。每位评审 MUST：

1. 独立重新打开源文件（L2）。 对于候选方案引用为可行性／风险证据的每个 file:line、测试名称、命令或文档，都要从当前源文件中重新读取／重新运行。 不要相信任何自我报告。在 reReadSources 中准确记录重新读取的内容，并在 workDone 中记录是否实际完成了工作。
2. 将每项评分锚定在经核实的影响上（L6 — 双向）。 评分不得基于评审未确认的主张。防范两类错误：不要夸大无法核实可行性的提案，也不要否定未实际追踪风险的提案。每项评分都要附带一行 evidence（file:line／命令输出／“没有可用的判定基准 — 未经核实”）。
3. 只有实际完成了工作，评审结论才计入（L8）。 返回 workDone:false／reReadSources 为空的评审属于弃权，不算投票 — 该结论会被过滤并记录日志，候选方案将依据剩余有证据支撑的结论进行评判（如果没有剩余结论，则标记为未评判）。一项证据充分的结论，权重高于两项信心十足却空洞的结论（依据 L8 按证据加权）。

这是 anti-error-lessons §"the case" 中 bug 的生成式映射：一次性评审只读了一条路径，就“排除”了一个真实的隔离 bug。这里的评审如果没有重新读取候选方案涉及的存储处理程序，却给出“风险：9，安全”的评价，就是在犯同样的错误 — 在 workDone:true 之前，其结论属于弃权。

评分标准（1–10 档，锚定在经核实的影响上 — L6）

每个维度都采用相同的校准档位评分，以便不同评审的评分可以比较：

档位	含义（必须以证据为依据，绝不可推测）
9–10	已核实，表现强：判定基准／重新读取的源文件／原型证实了这一点；此维度没有未解决的风险。
6–8	有一定可信度且已部分核实；存在少量未核实的假设，并已全部列明。
3–5	有一定可信度但未经核实 — 没有可用／已运行的判定基准；视为暂定。
1–2	已核实，表现弱：重新读取的内容或判定基准表明此维度存在具体的失败／阻碍因素。

禁止：对评审无法核实的维度打 9–10（应打 3–5，标记为“未经核实”），也禁止对从未实际追踪的维度打 1–2。这与 L6 的要求一致：绝不可因推测性的缺口给出高分，也绝不可对已确认的问题给出低分。

聚合规则（按字典序 — 确定性地选出胜者）

按字典序合并六个维度来选出胜者，不要使用含糊的平均分（平均分可能让可维护性上的优势掩盖正确性失败）：

1. 正确性／可行性 — 取有证据支撑的评审给出的最低分中的最高值。无法奏效的候选方案无论表面多么完善都会落败。
2. 风险／安全性 — 在可行性打平的候选方案中，已核实风险最低者胜出。
3. 与项目规则（AGENTS.md／约束）的一致性 — 风险之后的决胜项。
4. 然后依次以 userValue、performance、maintainability 作为剩余的决胜项。

所有层级均打平 → 由综合评估根据可嫁接性做出决定（更容易嫁接的候选方案成为基础）。记录胜者在哪个层级胜出，确保决策可审计。

盲评（将 L7 落实为操作要求 — 如跳过则记录）

评审应在不知道每个候选方案来自哪个角度的情况下打分，避免“风险优先”标签预先影响风险评分：

• 评审前，移除每个候选方案中的 angle 字段和任何能标识角度的措辞，并分配中性 ID（A、B、C……）。仅由主 Agent 保留私有的 ID↔角度映射。
• 如果无法盲评（例如提案文本不可分割地提到了自身角度），则在决策记录和你的执行框架 todo／plan 工具中记录“跳过盲评：<原因>”（L7 — 不得默默设限）。可以跳过盲评，但不能默默地跳过。

---

结构化 I/O 契约（强制）

每个候选方案和评审者都必须返回带围栏的 ```json 代码块，并符合以下架构。主 Agent 会校验格式，并在输出格式错误时重新请求一次，之后才将该 Agent 视为失败（工作流模式 §4）。枚举值是固定的——自由格式字符串会破坏校准（L6）。

候选方案对象（每个生成器返回的内容）：

{
  "id": "A",
  "angle": "risk-first",
  "proposal": {
    "summary": "one-paragraph thesis",
    "keyChanges": ["concrete change 1", "concrete change 2"],
    "tradeoffs": ["what this costs"],
    "deprioritized": ["what this angle deliberately skips"],
    "concreteNextSteps": ["step or pseudocode the reader can act on"]
  },
  "risks": ["named risk + why"],
  "assumptions": ["assumption that a test/type-check/prototype could verify"],
  "verifiableClaims": ["claim X — oracle: run `test <module>` / read the auth middleware"]
}

评审判定对象（每个评审者返回的内容；candidateId 是盲测 ID）：

{
  "candidateId": "A",
  "scores": {
    "feasibility": 7, "risk": 4, "userValue": 6,
    "performance": 5, "maintainability": 8, "alignment": 9
  },
  "scoreEvidence": {
    "feasibility": "re-ran the type checker clean",
    "risk": "the upload handler — storage tenant from ?hostname, unverified mitigation"
  },
  "strengths": ["..."],
  "weaknesses": ["..."],
  "graftableIdeas": ["specific idea worth stealing into the winner"],
  "overallRecommendation": "strong",
  "directVerificationIdeas": ["oracle the synthesizer should run before committing"],
  "reReadSources": ["src/.../upload-handler:171"],
  "workDone": true
}

枚举值：

• scores.*：整数 1–10，按上述评分标准区间进行校准。
• overallRecommendation："strong" | "acceptable" | "weak"。
• workDone：boolean — false ⇒ 判定为弃权，予以过滤并记录（L8）。

综合输出（该技能的最终产物）：综合后的提案 + 完整评分表（展示原始分数，绝不只展示获胜者）+ 融合创意列表（每项均标注其来源候选方案）+ winnerDecidedAtTier + openQuestions[] + 建议直接核验的事项 + 所有 loggedCaps[]。

---

已应用的执行机制

以下机制可确保流程可靠（完整列表：工作流模式 §3）。针对本评审组：

• 空值处理 + 重新计算（工作流模式 §3）。 失效、报错或无内容的候选方案或评审者都会被过滤掉（.filter(Boolean)）——绝不计入。过滤后，基于剩余项重新计算最低数量要求，并记录淘汰情况："candidate C died → 2 survivors, ≥2 floor met" 或 "candidate C died → 1 survivor → tournament aborted (min-candidate floor)"。评审者失效绝不能被视为低分；候选方案失效绝不能被视为“这个角度落败”。
• 并发上限。 每批执行 min(16, cores−2) 个；超出部分排队。
• 预算——在本地明确记录，绝不静默处理（L7）。 预算不足时，通过删除优先级最低的角度来减少 N（即其关注点已被 L5 映射中的其他角度覆盖），或者减少评审者数量后停止——并写入具名记录行： "budget: dropped angle 'performance' (covered by 'scalability'); N 5→4"。绝不静默缩小评审组。任何缩减后都要重新推导最低数量要求（仍需 ≥2 个候选方案，并且每个候选方案至少有 1 个基于证据的评审者）。
• 工作树隔离。 只有编写或运行代码的候选方案（原型）才使用 isolation:"worktree"；纯设计类的并行任务为只读，无需隔离。
• 日志记录 / 恢复（工作流模式 §3）。 长时间运行时，将 quality-journals/<task-id>.json（存放在 Agent 的数据目录下）写入磁盘： { phasesDone[], anglesUsed[], blindMap, survivors[], abstentions[], droppedDueToCaps[], winnerDecidedAtTier }。 恢复时，加载该文件；不要重新生成 anglesUsed[] 中的角度，也不要重新评审 survivors[] 中已有的候选方案——并保留 droppedDueToCaps[]，避免预算导致被删除的角度被静默地视为“已覆盖”。
• 不允许静默触发上限（L7）。 每个未执行的角度、跳过的评审者、降低优先级的维度或跳过的盲测，都必须在决策记录中以具名记录行列出，并通过执行框架的待办 / 计划工具呈现。读者必须能区分“已充分探索”和“已截断”。
• 日志 / 阶段。 通过执行框架的待办 / 计划工具，输出上述阶段名称，让实时计划清晰可见，并可由人工中断。

---

实战示例（精简版）

/work-judge 3 angles="MVP-first,risk-first,scalability" focus="multi-tenancy" "How to add real-time notifications to a multi-tenant app's kanban board"

1. L1 gate — 没有测试或预言机能决定“该选哪种实时传输方式”；继续执行（已记录）。
2. 角度覆盖（L5） — 映射：安全性→risk-first，多租户→risk-first， 迁移→out-of-scope: greenfield feature (logged)，回滚→MVP-first（功能标志）， 可观测性→scalability，成本→scalability。没有未标明的遗漏。
3. 生成 — 3 个子 Agent，仅承担计划角色，不使用 worktree（仅设计）， 盲化 ID 为 A/B/C，剥离角度信息。其中一个（scalability）返回格式错误的 JSON → 重新请求 一次 → 返回有效结果。
4. BARRIER #1 / 评审 — 评审者重新查看上传处理程序和租户设计记录（L2）。对 B 的评审返回 workDone:false → 弃权，已过滤并记录；B 仍有一个有证据支撑的 结论，因此 B 会接受评审，不会被舍弃。
5. 聚合（字典序） — A 和 C 的可行性得分并列（8）；C 的已验证租户风险较低（重新读取后确认每租户使用独立频道）→ C 在风险层级胜出（已记录）。
6. BARRIER #2 / 综合 — 以 C 为基础；融入 A 的功能标志回滚方案和 B 的 背压说明。openQuestions：“确认频道身份验证绑定到会话，而不是 ?hostname” → 标记，交由 ../work-refute/SKILL.md 处理。

---

与其他模式的集成

• 通常接在理解阶段之后（../work-sweep/SKILL.md 或研究）。
• 综合后的胜出方案自然可作为 ../work-refute/SKILL.md 的输入，用于对最终提案进行破坏性评审（解决其 openQuestions）。
• ../work-gaps/SKILL.md 在综合后运行： “整个评审组遗漏了哪些重要角度或风险？”——L5 覆盖映射是其输入。
• 若要在已构建的实现方案中进行选择，而不是在提案之间选择，请使用 ../work-tournament/SKILL.md。

此模式可提高对设计决策的信心，尤其适用于没有明显唯一答案的情况； 并且借助 L1 gate，在低成本预言机已有答案时拒绝运行。