ds-jury

ds-jury 用于让两个或三个独立评审者对同一处变更做出判断，然后反复修复，直到他们达成一致。

使用步骤

1. 先准备好工作。回复未解决的 PR 评论、修复已知问题并运行相关检查。只有在用户打算丢弃这批代码时，才可以跳过这一步。

2. 选择评审者。优先使用用户指定的模型；否则从两个或三个不同提供商（provider）中挑选最强的可用模型，并将推理强度设为高。

3. 在当前运行环境中找到能够联系到这些模型的方式：带模型设置的团队工作进程或子代理，终端中的第二个代理 CLI（例如 Codex 或 Claude CLI），或者 API 调用。如果只有一个模型可用，就启动两个或三个具有全新上下文的该模型子代理，并分别赋予不同角色：正确性、安全性与边界情况、简洁性与范围。

4. 为所有评审者编写同一份评审说明（brief）：仓库路径、基准 SHA、diff 命令、用一句话说明目标、范围外事项以及检查结果。告知他们只做评审，不做任何改动。

5. 要求每位评审者给出：结论（APPROVE 或 CHANGES）、10 分制评分，以及格式为 id severity file:line claim fix 的问题项。严重级别为 blocker、should 或 nit。

6. 并行运行各评审者，等待全部返回。超时或报错不应视为通过。

7. 自行逐项对照代码核实每条问题。对认同的问题以最小改动修复；对不认同的每条问题写一行拒绝理由。

8. 重新运行检查。使用同一份说明、你的答复以及新的 diff 开启新一轮评审。

9. 报告结果。如果有 PR，编辑其描述并添加表格：评审者、模型、每轮评分。评审者未给分时不写评分。如果没有 PR，把表格放在最终回复中。

停止条件

• 每位评审者都返回 APPROVE，且没有未解决的 blocker 或 should 级问题。
• 已完成三轮。报告仍存在的分歧，每方各用两行说明。由用户决定。
• 某一轮只返回 nit 级问题。此时停止，不再进行下一轮。

规则

• 评审者只读。他们不得编辑、推送、评论，也不得启动自己的子代理。
• 说明哪些评审者彼此是同一模型。不要声称联系到了实际未联系到的提供商。
• 绝不编造评分或结论。
• 守住范围。拒绝新功能请求，并将其列为后续事项。