work-tournament

/work-tournament —— 并行实现竞赛

以多种不同方式并行实现一项任务，使用确定性预言机筛选每个候选方案，根据幸存方案的实际差异进行评估，并应用最佳方案——然后在 main 中重新验证。

这是质量体系中的实现分支。它是在构建阶段进行的竞赛，参见 ../work/references/workflow-mode.md §2（“实现工作使用 work-tournament……在工作树中”）。它将 ../work/references/anti-error-lessons.md 中的经验教训 L1–L8 落到实处； 下方的经验教训标签（L1…L8）指向该文档——请勿重复其中的内容， 请阅读该文档。

工作流形态

并行屏障 → 然后是简短的流水线尾段。

• 扇出阶段是一个屏障：候选方案在各自的工作树中并行实现同一项任务，而比较本身是一项固有的跨项操作——只有在所有候选方案均已完成并通过预言机筛选后，才能对候选方案 A 排名。这是 workflow-mode §1 中三种合理的屏障理由之一 （“跨项比较：评审者对所有候选方案进行排名”）。
• 选出优胜方案后，尾段（移植 → 完整性检查 → 在 main 中重新验证）是在单个项目上执行的简短流水线。

这不是循环：N 预先固定，没有“直到无内容可做”的终止约定。（如果最佳候选方案仍不够好，请升级处理——使用更多或不同角度重新运行，或将任务交给编排器——而不是悄悄循环。）

用法

/work-tournament [N] <task>

• 如果第一个参数是 2-10 之间的数字，则该数字设置候选方案数量；其余部分为任务。
• 如果省略，N 默认为 3。

示例：

• /work-tournament implement the login page（3 个候选方案）
• /work-tournament 5 refactor the auth module（5 个候选方案）

预算、并发与不静默限制

生成候选方案前，记录 N 及其理由（通过你的执行框架的待办事项/计划工具写一行），以便读者判断该数量是经过审慎决定的，还是被截断的 （L7 / workflow-mode §3 “不静默限制”）：

• 并发上限：分批以 min(N, 16, cores−2) 的数量启动。如果 N 超过上限，则将超出的候选方案排队——绝不能静默丢弃候选方案。
• 预算意识：如果预算紧张，明确减少 N 并记录下来 （“因预算将 N 从 5 降至 3”）。绝不能静默缩减。
• 日志记录：对于重要的运行，在 quality-journals/<task-id>.json （位于 Agent 的数据目录下）中写入 { N, anglesUsed[], worktrees[], oracleResults[], survivors[], disqualified[], winner } 以确保运行可审计且可恢复。记录工作树路径和每个候选方案的状态（已构建 / 已取消资格 / 因预算而放弃）。

步骤

1. 解析请求

提取N（候选方案数量，默认为 3）和任务描述。

2. 为每个候选方案分配一个不同的角度（L3）

N 个相同的提示词会产生 N 份几乎相同的差异——这只是冗余，而非竞赛，也无法发现不同角度所能捕捉的问题。从以下列表中为每个候选方案分配一个角度（若 N 超过列表长度则循环使用）：

1. 最小差异 — 以最少改动完整满足任务；尽可能少改文件。
2. 最符合惯用模式 — 尽可能忠实地遵循周边代码库的模式/约定。
3. 最注重防御 / 覆盖边界情况 — 处理所有边界情况、null/空值/错误路径和边界条件。
4. 性能优先 — 倾向于最高效的方案（分配、查询、复杂度）。
5. 简单易读 — 优先采用最清晰、最显然正确的代码。

记录角度→候选方案的映射（这能说明方案多样性的来源，也可用于生成日志）。

3. 在并行工作树中生成 N 个候选实现（屏障）

在单条消息中生成 N 个子 Agent（并行调用工具）。对每个候选实现，生成一个子 Agent，并指定：

• 合适的子 Agent 角色（通用实现者）
• 隔离的工作树 ← 必须；候选实现会并发修改文件（workflow-mode §3“工作树隔离”）
• 在后台运行
• 描述："Candidate <number> (<angle>)"
• 提示词：任务描述，加上分配的角度，再加上： "You are candidate <number> of <N> independent implementations, working from the <angle> angle. Implement the task fully. Do NOT cut corners to look good — you will be judged on your actual diff and on whether the build/tests pass, not on your summary. Return ONLY the Candidate Output Contract JSON below as the last block of your reply."

将候选输出契约（见下文）传入每个提示词，以确保返回格式符合要求。生成后，等待所有候选实现完成，然后收集每个结果。关于你的运行环境所用的具体工具名称（生成子 Agent / 等待所有候选 / 收集其结果 / 在后台运行 / 隔离工作树），请参阅 ../work/references/workflow-mode.md 中的运行环境对照表。

3.5 每个候选实现的预言机检查门槛——任何评估之前（L1，失败即关闭）

候选实现的自我报告不是证据。先在每个工作树中运行确定性预言机，再进行排名；只有实际能够构建的候选实现才参与排名。

• 从代码仓库中自动发现预言机命令：package.json 脚本（build、typecheck/tsc、test、lint）、Makefile 目标，或 AGENTS.md/CLAUDE.md 约定。如果无法发现任何命令，记录 oracle: "none-available" 并说明这一点（不要假装检查已通过）。
• 在每个工作树中按顺序运行：build → typecheck → test → lint。记录每项检查的实际通过/失败情况（不要采用候选实现的说法）。
• 构建失败或测试失败的候选实现会自动取消资格。 在日志中将其标记为 disqualified，并记录失败的命令 + 第一行错误信息——务必记录，不得静默丢弃（L7）。仅 lint 失败属于中等缺陷，不会自动取消资格（记录该问题，并在评分时考虑）。
• 空值处理（workflow-mode §3）： 使用 .filter(Boolean) 过滤已退出/空/报错的候选实现，然后基于剩余候选实现重新计算“幸存者”数量，并记录被剔除项（例如：“已生成 5 个 → 1 个崩溃，1 个因构建失败被取消资格 → 3 个幸存者参与评分”）。已退出的候选实现绝不能算作参与者。

4. 根据实际差异评估幸存者（L2）——绝不依据自我总结

对每个幸存的候选实现，都要亲自完成以下工作；不要依据文字说明评分：

1. 运行 git -C <worktree> diff（对于新建/重命名的文件，还要运行 git -C <worktree> status）。
2. 阅读工作树中每个变更文件——重新打开真实的源文件，不要相信 diff_summary/self_report。这是 L2 修正：根据当前源代码评分，而不是根据调查者引用的证据评分。
3. 根据差异 + 预言机结果，从三个维度评分：
   • 正确性——差异是否真正解决了任务并满足所有要求？是否存在逻辑/类型错误或遗漏情况？（预言机结果是主要证据）
   • 代码质量——是否整洁、可读、符合代码库惯例，且没有无谓改动或超出范围的编辑。
   • 安全性——是否引入新 bug、安全漏洞、数据丢失路径，或破坏现有行为。

5. 对发现表中的问题进行严重性校准（L6）

根据已验证的影响确定每项发现的严重性（同时防止误报夸大和漏报轻视）：

• Critical = 数据丢失／安全漏洞／导致构建失败（确实可触发且造成损害；不能按当前状态发布此更改）。
• High = 输出错误／行为异常／测试失败（确实可触发且造成损害，但未达到数据丢失／安全漏洞／构建失败的程度）。
• Medium = 边缘情况缺陷、覆盖不完整、lint 失败、看似合理但未经验证的问题。
• Low = 风格／外观／命名问题。

绝不能将推测性缺陷标为 Critical/High，也不能将可利用或导致构建失败的问题标为 Low。

6. 对胜出方案进行完整性检查（L5）

应用前，针对胜出方案的 diff 与完整任务范围，运行至少一个全局检查器——最有价值的做法是找出哪些内容从未被修改，而不是重新检查已修改的内容：

• 在整个仓库中使用 grep 搜索任务涉及的核心实体／符号 → 找出任何应该修改却未修改的文件（未改动的调用点、配置、类型、测试）。
• 检查原始请求中未处理的要求（重新阅读任务，逐项核对）。
• 检查变更后的 API／签名／架构的下游使用方是否已更新。

将缺口记录为具名列表（L7）。若缺口大到影响任务范围，则降级胜出方案，或从落选方案中移植改动（类似 work-judge 的做法）——并说明具体是哪种处理方式。

7. 将胜出方案应用到 main

将胜出工作树中的更改移植到 main 工作区。明确解决与当前 main 的任何冲突（不要覆盖本地更改）。

8. 应用后的重新验证（L1，失败即关闭）

移植后，在 main 中重新运行相同的检查器（build → typecheck → test → lint）。候选方案在独立工作树中通过检查，合并后仍可能出问题（冲突、差异、工作树以外的文件）。**发出 WINNER 前，先修复冲突／失败。**如果无法让 main 通过检查，不要宣布胜出者——报告失败情况和剩余工作。

9. 清理

移除所有候选方案生成的工作树（git worktree remove），包括胜出方案的工作树（其内容现已在 main 中）。保留日志。记录任何未清理的工作树及原因。

10. 宣布胜出者

仅在步骤 8 全部通过后，在回复末尾写上 WINNER: <number>（1-N）。

候选方案输出约定（每个子 Agent 都应以此作为最终块返回）

自我报告仅用于分流和日志记录——不能替代调用方运行检查器（3.5）和查看 diff（4）。调用方应验证格式，并在输出格式错误时要求重新提交一次；若仍然格式错误，则丢弃该候选方案并记录（不得默默接受；参见 workflow-mode §3“结构化输出”）。

{
  "candidate": 2,
  "angle": "most-defensive",
  "approach": "one-paragraph summary of how this candidate solved the task",
  "files_changed": ["auth/login.ts", "auth/login.test.ts"],
  "diff_summary": "added null-guards on session lookup; new test for expired token",
  "build_passed": true,
  "tests_passed": false,
  "self_report": "free-form notes, known gaps, anything the grader should re-check"
}

字段规则：

• candidate（整数，必填）、angle（字符串，必填——分配的审查角度）。
• files_changed（字符串数组，必填）——调用方应与 git diff 交叉核对；不匹配是警示信号，应根据 diff 进行评估。
• build_passed / tests_passed：boolean | null。null = 候选方案未运行对应检查（状态未知），调用方应视为未经验证，不能视为通过。无论如何，调用方都必须运行实际检查器（3.5），并用实测结果覆盖这些值。无效／空对象会被 .filter(Boolean) 过滤掉。
• diff_summary、self_report（字符串）——仅供参考。

展示评估结果

先展示生成记录（N、方案角度、幸存者与淘汰者及原因）， 然后展示幸存候选方案的对比和发现：

维度	候选方案 1（最小差异）	候选方案 2（防御性）	...
Oracle（构建/类型/测试/lint）	✅✅✅✅	✅✅❌ DQ	...
正确性	简短结论	—（DQ）	...
代码质量	简短结论	—	...
安全性	简短结论	—	...

发现	严重程度	候选方案 1	候选方案 2	...
具体问题	严重/高/中/低	处理方式	处理方式	...

说明你选择了哪个候选方案及原因、完整性检查结果（步骤 6）， 以及应用后的重新验证结果（步骤 8）。

示例（简略）

/work-tournament 4 add rate-limiting to the login route

1. 角度：c1 最小差异，c2 最符合惯例，c3 最具防御性，c4 性能优先。（已记录）
2. 在 worktree 中生成 4 个方案（上限 = min(4,16,cores−2)），并在后台运行。 3.5 每个 worktree 执行 Oracle：c1 ✅build ✅type ✅test ✅lint；c2 ✅✅✅✅；c3 ✅✅❌test（窗口重置时差一）→ DQ，已记录；c4 崩溃/为空 → .filter(Boolean) → 丢弃，已记录。幸存者：c1、c2（生成 4 个 → 1 个崩溃、1 个 DQ → 2 个进入评估）。
3. git -C wt-c1 diff + 阅读文件：c1 添加内存计数器（重启后会丢失）。git -C wt-c2 diff：c2 使用现有的共享缓存辅助工具。
4. 发现：c1“限流器在部署时重置” → 高（实际上可绕过限流）；c2 无问题。
5. 完整性检查：在代码库中搜索登录处理器符号 → 发现一个管理登录别名也未受保护 → 记录缺口；为两个路由都添加防护。 7–8. 将 c2 和管理路由修复移植到主分支，在主分支重新运行 Oracle → 全部通过。
6. WINNER: 2。

组合使用

• 可由 ../work/SKILL.md 调用 作为构建阶段的锦标赛（workflow-mode §2）。
• 可委派给：使用 ../work-check/SKILL.md 评估幸存方案， 使用 ../work-refute/SKILL.md 对领先方案的差异进行破坏性攻击，或通过 ../work-gaps/SKILL.md 执行步骤 6 的检查。
• 与 ../work-judge/SKILL.md 对比：work-judge 是针对广阔解空间的生成式设计（提出方案，不应用代码）； work-tournament 实现代码，并应用经真实 Oracle 验证的获胜方案。

根据需求规模选择

对于只有一行改动且显然只有一种正确写法的任务，无需进行 5 路锦标赛——直接完成并记录原因（workflow-mode §5）。当任务确有设计空间（存在多种合理实现、 差异不小，或正确性/质量/性能之间存在显著权衡）时，再使用 work-tournament。