hackathon-judging

黑客松评审

你负责设计黑客松如何决定获胜者：评分标准、评分等级、谁评什么、分数如何合并、如何打破平局、如何处理利益冲突，以及如何公布结果并接受质疑。

有两个输入已经确定。请使用它们，切勿重新决定：

• 演示／评审形式（展位展示、舞台演讲、仅视频或两阶段混合形式）由 samber/dev-event-organizer-skills@event-format-selection 决定。它规定每支团队与评委接触的时间、评审是现场还是异步进行，以及评委是并行轮换还是作为一个评审团共同评审。
• 已发布的挑战说明文档中列出的评估类别由 samber/dev-event-organizer-skills@hackathon-brief-design 决定。为这些类别分配权重，并据此设计评审机制。

切勿设定奖金金额或其法律结构。samber/dev-event-organizer-skills@hackathon-cash-prize 会将排名结果转化为奖金发放方案。

评委不是导师：

• 导师在黑客松期间帮助团队开发项目（samber/dev-event-organizer-skills@hackathon-mentoring）。
• 评委在项目完成后进行评估。

小型活动可能会让同一批人兼任这两个角色。这是人员安排上的便利，不代表两者是同一种角色。

以下所有排名都只是默认建议，并非规则。采访后请重新排列每个选项。以下任何一项都足以推翻默认排序：

• 有回归评委。
• 上一届的评分标准。
• 已签署的赞助商合同。
• 颁奖典礼开始时间无法更改。

采访

每次只问一个问题，尽可能使用选择题。之所以要问第 3 至第 6 个问题，是因为下方的选项取决于这些答案；没有这些答案，就无法选定任何默认方案。

1. 已确定哪种演示／评审形式？它预设每支团队与评委接触多长时间？（这是固定输入。请勿在此重新决定。）
2. 已发布的挑战说明中列出了哪些评估类别？（这也是固定输入。请为它们分配权重，切勿替换。）
3. 预计有多少支团队提交作品？从提交截止到颁奖典礼开始之间有多少分钟？请提供分钟数，而不是“一个下午”。分配方案需要根据这两个数字进行计算。
4. 已确认有多少位评委？他们能否同时在同一房间内？
5. 有哪些奖项和赛道？是否有赞助商为其中任何一项提供资金？已签署的赞助协议是否要求该赞助商的代表评审其赛道？
6. 团队是否会收到逐队反馈？颁奖典礼结束后是否留有时间撰写反馈？
7. 已发布的规则对评审标准、平局处理和争议解决作出了哪些承诺？这是一次性活动，还是规则应在明年仍然适用的定期活动？请先阅读规则。评审流程应落实已发布的内容，而不是采用方便的做法。
8. 工作量上限是多少：典礼前主办方可投入多少小时、预筛选环节有多少志愿者，以及由谁拥有正式打破平局的权限？

工作流

1. 运行访谈。在设计任何内容之前，先阅读已发布的规则（Q7）和简报中的类别（Q2）。
2. 先根据 Q1、Q3 和 Q4 计算分配范围，再制定评分标准。它会从所有其他选项菜单中删除档位，而且这是唯一一个会让计划变得不可行、而不只是成本更高的步骤。加载 references/judge-allocation-math.md。
3. 为简报中的类别分配权重并选择评分尺度。在任何人打分前，把这两项写下来。在一轮评审中途更改评分标准，会导致先前接受评审的团队重新评分。
4. 根据第 2 步得出的分配范围确定组合规则——原始平均分、按评委标准化，或达成共识；绝不能脱离该范围单独决定。
5. 将决胜规则写成一份确定性的列表，并在提交截止前公布。
6. 开始评分前向评委说明：评审标准和权重、评分尺度、利益冲突规则、各自负责的分配范围，以及落后于进度时该怎么做。
7. 将分配图表整理为带名称的列表：评委、团队、顺序、开始时间。未分配任务的评委会无所事事，未被走访的团队则会引发争议。
8. 评分、汇总，并在颁奖仪式前检查算术可行性门槛（参见 Measurement）。
9. 根据准备好的列表宣布结果，并在规则规定的期限内保持竞赛申诉渠道开放。加载 references/coi-and-results-policy.md。
10. 记录实际情况：走访过的团队、启动的回避、收到的质疑。将每个赛道的排名结果交给 samber/dev-event-organizer-skills@hackathon-cash-prize。

开始评审前，按章节逐一提交设计方案以供验证：

• 分配
• 评分标准
• 组合规则
• 决胜规则
• 利益冲突规则
• 结果公布计划

评分一旦开始，更改规则就会使已完成的评分失效。

如果你的 harness 具有持久记忆，请记录权重、分配范围及其输入、决胜规则，以及每条规则具体需要听到什么样的投诉才会在下一届活动中作出更改。

评委分配深度

增加评委人数并不能让全面覆盖触及更多团队。 上限为 N ≤ W / t，其中没有 J：在全面覆盖的情况下，每位评委都要亲自评审全部 N 个团队，因此评委人数会在不等式中抵消。上限约束的是团队数量，而不是评委人数，也不是评审时段。

这个选项菜单取决于算术，而不是偏好。它由四个量决定：

• N - 预计提交项目的团队数（Q3）。
• t - 每个团队所需的评委时间（分钟），由形式固定（Q1）。
• W - 评审时段的分钟数（Q3）。
• J - 已确认的评委人数（Q4）。

t 的时间输入：

• 每个团队 10 分钟，适用于多团队现场演示交接：3 分钟演示、1-2 分钟问答、5-6 分钟设置和切换。MLH 给出的这个数字适用于颁奖仪式的演示时段，而非评审环节，因此可借鉴的是设置和切换所需的时间，而不是观众因素。评审时段没有观众，流程可以更紧凑。
• 在 Expo Table 环节，每个团队 3-5 分钟。
• 在 Stage Pitch 环节，每个团队 2-5 分钟加问答。
• 在 MLH 自己的科学展评审环节中，每个项目 4 分钟，每个项目评审 3 轮：2 分钟展示和演示、1 分钟提问并汇总评分、1 分钟评委移动时间。这是 MLH 公布的每个项目评委人数默认值，与上文 Expo Table 的数据相近。

3-5 分钟和 2-5 分钟的数据都没有为设置或切换留出时间，因此基于这些数据计算出的所有上限都只是乐观的上限，而非容量承诺。公布数字时要说明这一点。

根据这些输入计算出的两个交叉对比：

• 评审时段为 120 分钟、每个团队 10 分钟时，全面覆盖最多可评审 12 个团队。
• 同一时段内，每个团队 5 分钟时，全面覆盖最多可评审 24 个团队。

将 t 减半，全面覆盖可评审的团队数就会翻倍。这不会改变评委人数或评审时段。

排序（默认值，并非硬性规定——Q3、Q4 和 Q8 会重新排序）：

• 价值（实际参与排名的项目之间的可比性、评委校准、领奖台结果的可辩护性）：全覆盖 > 抽样评审组 > 初筛后决赛 > 每队一位评委
• 工作量（评委工时，以及组织者需要安排的分配和轮次）：全覆盖 > 初筛后决赛 > 抽样评审组 > 每队一位评委

这两个维度确实存在分歧，因此效率按区间公布，而不是用一条统一的排序表示。排序只会在算术边界处翻转，而非出于偏好：

• 区间 1，N ≤ W / t：效率为 全覆盖 > 抽样评审组 > 每队一位评委 > 初筛后决赛。全覆盖根本不需要分配方案，还能最大限度地提高可比性。如果所有项目都能安排下，初筛就只是纯粹的额外工作。
• 区间 2，W / t < N ≤ (J × W) / t：此处要从本菜单和上方的维度排序中删除全覆盖——这在算术上不可能，并非只是成本高。效率为：抽样评审组 > 每队一位评委 > 初筛后决赛。每队的覆盖率为 k = floor((J × W) / (N × t)) 位评委。
• 区间 3，N > (J × W) / t：此处要从本菜单和上方的维度排序中同时删除抽样评审组和每队一位评委——即使每队只安排一位评委，也无法满足要求。初筛后决赛是实时评审时段内仅剩的可行分配方式。如果形式尚未敲定，则交由 samber/dev-event-organizer-skills@event-format-selection 处理：异步视频评审属于形式变更，应由该技能决定。

支配关系检查，重新推导：谨慎核验，结果干净。 存在一种严格支配关系：抽样评审组的价值高于初筛后决赛，且工作量更低。每个区间的效率排序都遵循这一关系。错误的排序会无法通过检查，因此这次检查通过是有意义的。

• 全覆盖永远不占支配地位（位于工作量维度的顶端）。
• 每队一位评委永远不占支配地位（位于价值维度的底端）。
• 在任一维度上，初筛后决赛都不支配抽样评审组。

效率排序会舍弃什么：

• 全覆盖——它在两个维度上都位居顶端，因此区间 1 结束后，效率排序就会舍弃它。晋升条件对应 Q3：队伍数量不超过 W / t。应核对算术结果，而不是凭“我们规模不大”的感觉判断。
• 初筛后决赛——它没有任何一方面成本低，只有在区间 3 才合理。只有当 Q8 确认有志愿者团队负责已公布的通过／不通过初筛时，才应提前启用。

包含示例分配方案、k 的计算过程以及带数字的区间边界，见 references/judge-allocation-math.md。

评分标准的细致程度和权重

为简述中已提及的类别设置权重（Q2）。排序如下（默认顺序，并非定律；Q1 和 Q6 会重新排序）：

• 价值（对团队和赞助方的说服力、抗争议性、可用于决胜）：加权标准并附逐项书面评论 > 加权标准 > 列出标准但不加权 > 单一总分
• 工作量（评委说明、每支团队在时段内占用的时间、组织者准备工作）：加权标准并附逐项书面评论 > 加权标准 > 列出标准但不加权 > 单一总分
• 效率：加权标准 > 列出标准但不加权 > 单一总分 > 加权标准并附逐项书面评论

支配关系检查，重新推导后得出的结论：仅因构造方式而干净，并不代表通过。 价值和工作量的排序相同，因此不存在某个选项的价值 >= 另一个选项且工作量 <= 另一个选项的情况。既然不存在支配关系可供违反，这项检查就无法在此发现排序错误。排序依据是下面的论证，而不是这项检查。

• 加权标准——默认选择。设定权重是活动前一次性付出的成本，评分表会自动计算，因此在 3-5 分钟的时段内，边际成本为零。它能带来不加权标准无法提供的两点：
  • 赞助方能看到其挑战确实受到重视。
  • 出现平局时，有一个有原则的首选决胜依据。
• 列出标准但不加权——少做一个决定，成本更低，但这个决定并不会消失。每位评委会自行采用不同的权重，因此技术评委和业务评委实际上在悄悄评判不同的比赛。只有在组织者确实认为各类别同等重要时，这种做法才合理。
• 单一总分——成本最低，但无法提供任何站得住脚的依据，因为一个孤立的数字无法说明原因。只要有多条赛道颁发奖项，就应从此选项菜单和上方的排序中删除它（Q5）。一个数字无法区分各赛道的获胜者，把它留到颁奖环节才处理，只会悄然重新引入问题。
• 加权标准并附强制性的逐项书面评论——被冷落的选项：价值最高，工作量也最大，因此效率永远不会选它。工作量会落在黑客松最紧张的环节，也就是现场时段内。评委每支团队只有几分钟，而不是几天。
  • 晋升条件（依据 Q1 和 Q6）：评审仅通过视频进行，或以其他异步方式进行，或者承诺为每支团队提供反馈，且活动后留有撰写反馈的时间。两种情况下，评论都不会占用现场时间。

评分尺度的形式是独立于权重之外的决定。可选的形式有两种：

• 每项标准采用 1-5 或 1-10 的数字评分尺度——默认选择，也是评委在两张桌子之间走动时能记在脑中的形式。
• 带有明确分值差异的命名能力阶梯，其中包括对简单路径的负分差。对于应主动劝阻团队选择最省事方案、而不只是不给予奖励的标准，应使用这种形式：阶梯会明确写出奖励结构，而普通数字尺度会将其隐含起来。将开放式阶梯的总分通过参赛群体的最小-最大值归一化映射到已发布的评分尺度上，这样内部评分标准仍有充分表达空间，同时评委和团队看到的数字也具有可比性。

阶梯模式、归一化公式、尺度选择、加权计算示例以及正负分配对示例，详见 references/rubric-and-scoring-mechanics.md。

淘汰条件

评分标准衡量程度。淘汰门槛则只回答是或否：无论加权得分如何，都可据此取消提交资格。两者应作为独立的内容处理：若将淘汰条件并入评分标准的一项，它看起来就只是低分项，而非取消资格的依据。

淘汰规则应针对本次活动的主题本身容易引发的作弊方式，而不是照搬其他活动的通用清单：

• 被破解或绕过的工具。
• 使用了必需技术，但它并非项目的核心——“没有它也能做出来”。
• 技术代际太旧或过于简单，达不到简章中所述的目标。
• 简章要求至少提供代码或无代码实现，但提交的只有设计文件，没有可运行的构建成果。
• 简章的提交清单要求公开代码，但代码从未公开。

在简章中，与类别名称一并公布完整清单。在此处编写规则；samber/dev-event-organizer-skills@hackathon-brief-design 会将它们打印在资格条件文本旁边。

公布类别名称和完整的淘汰清单即可满足披露要求，数值权重则不必公布。 下文所说的失败，是指团队在完全不知道评审内容的情况下参赛；公布类别名称和完整的淘汰清单已经可以避免这种情况。在这些内容公开后，不公开权重本身是一种合理的防作弊选择：它能阻止团队针对一个自己本来无从得知的数字，精确到小数位地进行优化。

合并多位评委的评分

在全面覆盖时，标准化毫无收益；在抽样评审时，标准化能挽回整个排名。 其原理只需一行算术：一位打分普遍偏严的评委，会给自己评过的每个团队加上相同的常数。

• 全面覆盖——该评委给所有团队打分，这个常数会同等作用于所有团队，不会改变排名。标准化纯属额外开销。
• 抽样评审——这个常数只作用于该评委评审的那部分团队，因此最终排名在一定程度上反映的是团队分到了哪组评审，而非项目本身。标准化恰好能消除这一偏差。

应根据评审分配区间选择此菜单，不要脱离该区间单独做决定。

排序（默认建议，不是定律——Q1 和 Q4 会重新排序）：

• 价值（评审者效应校正——最终排名在多大程度上反映项目本身，而非碰巧评审该项目的是哪位评委）：同步共识 > 按评委标准化 > 原始平均分
• 工作量（准备工作、评委说明，以及在固定仪式开始时间之前召集所有评委）：同步共识 > 按评委标准化 > 原始平均分
• 全面覆盖时的效率（区间 1）：原始平均分 > 按评委标准化 > 同步共识
• 抽样评审或单评委分配时的效率（区间 2-3）：按评委标准化 > 原始平均分 > 同步共识

支配性检查，重新推导后：只因构造方式而干净，这并不代表通过。 价值和工作量的排序方向相同，因此没有需要检查的组合，也没有可由该检查发现的错误。此排序依据的是上述算术原理。

同步共识是两个区间中都不占优势的选项。与合并独立评分相比，它需要所有评委同时在同一间会议室里进行一轮讨论，且日程不能太紧。黑客松评审团必须赶在无法更改的颁奖仪式开始时间之前完成评审。

晋升条件（依据 Q4）：评委人数少到可以在同一间会议室开会，且走访结束后仍有时间余量。如果评审是异步进行，或评委结束自己的时段后会立即离开（Q1、Q4），就从此菜单和上方的排序项中删除该选项——一场没人会参加的会议若被放在菜单末尾，就会悄然变成计划的一部分。

组织者推翻评委合并结果，不是此菜单上的一个选项，而是应当彻底删除。 被拒绝的提交从未被承诺获得基于技能的排名，而争夺奖项的落败团队却得到了这样的承诺。推翻结果正是让结果可能遭到质疑的机制；让团队在颁奖仪式数周后才发现结果被推翻，时机完全不对。

利益冲突与披露

无所作为并不是这里成本最低的选项。 合规成本衡量某个层级触发的审核及其带来的可逆性代价；按这个维度，“没有正式流程”的排名很高，而不是很低。这就是为什么默认选项不是成本最低的层级：

• 没有正式流程：活动开始前不会触发审核，因此会把整个审核推迟到最难挽回的时刻：奖品发出之后，此时仅剩的选择就是重新举办评审轮次，或者接受结果。
• 自行申报并回避：只需在评委简报中加上一行。如果漏报了冲突，只要结果尚未产生，就可以通过重新分配该评委负责的部分来悄然补救。
• 书面登记册：每届活动都要进行治理审核，而且最难撤回，因为下一届撤下已发布的政策会显得像是在退缩。

排序（默认排序，不是定律——Q5 会重新排序）：

• 价值（规避赞助商关系风险、确保公布结果的可信度）：附带披露登记册和升级处理路径的书面政策 > 申报回避并指定替补评委 > 自行申报并回避 > 没有正式流程
• 工作量（评委简报所需时间、活动期间组织者的跟进工作、正式程度）：附带披露登记册和升级处理路径的书面政策 > 申报回避并指定替补评委 > 自行申报并回避 > 没有正式流程
• 合规成本：附带披露登记册和升级处理路径的书面政策 > 没有正式流程 > 申报回避并指定替补评委 > 自行申报并回避
• 效率：自行申报并回避 > 申报回避并指定替补评委 > 没有正式流程 > 附带披露登记册和升级处理路径的书面政策

重新推导的支配性检查：只有在价值和工作量维度上通过构造才算干净，而且这并不代表通过。 这两个维度的排序相同，因此不存在违反支配关系的情况。真正重新排列这些选项的是合规维度，而不是这项检查。

• 自行申报并回避——默认选项。告诉评委，不要给自己关系密切的团队打分，而应回避评审，而不是先打分再披露。这种基于诚信的约定只有在快速重新分配任务时才行得通：CFP 可以在数天内重新分配评审员，黑客马拉松则必须在活动期间完成。如果某个团队因太多评委回避而导致其分数失去可比性，应提前明确备用方案。
• **申报回避并指定替补。**晋升条件以 Q5 为准：任何赞助商资助某个赛道，且有评委与该赞助商存在关联。跟踪评委与赞助商之间的关联，并实时调整分配方案。
• 没有正式流程。只要有任何赞助商资助赛道奖项，就应立即从此菜单和上方的各项维度排序中删除该选项（Q5）。此时，一方对结果存在财务利益，却没有任何明确规则对此作出规定。
• 附带登记册和升级处理路径的书面政策——在价值、工作量和合规成本维度上排名第一，却受限于条件而难以采用。晋升条件以 Q5 和 Q7 为准：多届活动的已发布规则已经承诺设有争议处理流程，或者奖池足够大，以至于落败团队会追问由谁作出决定、依据是什么。

这套阶梯无法靠排序解决的棘手情况。 已签署的赞助协议可能会要求赞助商自己的代表评审其资助的挑战赛道。签约时已经接受了这一冲突，因此它优先于此处的所有选项。

• 将赞助商评委的职责限制在该赛道，并禁止其参与总奖项评审。
• 至少为其搭配一名中立评委。
• 检查去掉其评分后，该赛道排名是否仍然成立。
• 在投稿截止前，于已发布的规则中披露评委构成。

包括排名不再成立时该如何处理在内的完整说明，见 references/coi-and-results-policy.md。如果相关条款尚未签署，条款措辞应放在 samber/dev-event-organizer-skills@event-sponsor-agreement，而不是这里。

平分时的决胜规则

在提交截止前，就在简报中公布决胜顺序，不要等到颁奖台上才临时制定。按顺序逐项比较，遇到第一个能区分队伍的规则时就停止。

1. 最高权重评分项得分最高的队伍。权重已经体现了活动最看重什么；如果权重无法打破平局，那就是权重设置错了。
2. 在评审亲自看过的队伍中，将该项目列为第一名的评审人数最多的队伍。
3. 由指定的决胜评审当场决定，并记录在案，用一句话说明理由。
4. 仅当奖品可以拆分，且已提前在公布的规则中说明时，才共同获奖。

已公布的规则都采用了相同的模式：先按确定性的评分顺序逐项比较，再进行后续计票或评审团投票，最后由指定人员决断；只有在规则承诺过的罕见情况下，才将可拆分的奖品共同颁发。

• Devpost 的规则模板被数十场由 Devpost 承办的黑客松重复使用，依次比较列出的评审标准，最后再由评审投票决定。
• MLH 自己的竞赛条款赋予评审全权和最终裁定权，完全没有逐项比较标准的流程。
• HackMIT 从结构上避开了数字评分平局：它通过两两比较对项目排名，而不是分别评分，因此不会出现平局。
• Salesforce 是有记录以来唯一彻底放弃基于评分来解决平局的案例。2013 年的一场评审争议后，Salesforce 宣布共同冠军，并平分 Salesforce1 Hackathon 的大奖。这是事后危机处理，并非事先公布的规则。

完整先例（包括 WildHacks 的三级评分兜底规则）见 references/coi-and-results-policy.md。

有两种做法应当拒绝，原因各不相同：

• 重新评分。 演示已经结束，重新评审的依据将是记忆，而不是项目本身。
• 抛硬币或任何随机抽签。 在某些司法管辖区，奖项竞赛是否被视为不同类型，取决于结果能否明确证明由技能决定。在依赖任何法律限制前，请通过 samber/dev-event-organizer-skills@hackathon-cash-prize 确认这一点。

结果公布与结果争议

• 在颁奖仪式前收集获奖名单，包括赞助商赛道的获奖名单，而不是在现场收集。通过幻灯片宣布，而不是口头宣读。
• 评审尚未结束时，不要在闭幕仪式安排现场演示。演示时段和评审时段会占用同样的时间。
• 提前整整一小时请评委到场参加颁奖仪式前的简报。评分表一旦准备好，就附在日历邀请中，而不是等到签到时才临时发放。
• 提前布置评审室——安排座位、准备饮品和书写工具——而不是等评委已经入场后才开始准备。
• 如果上述组合规则的结果是同步达成共识，就分两轮计时进行评审讨论，而不是进行一场不设限的开放讨论：
  • 先为每支队伍安排一个简短的固定时段，然后只对入围名单进行较长时间的讨论。
  • 在评审轮次开始前指定一名计时员。
  • 评审期间，室内所有联网设备都要断开网络。结果若在公布前泄露，就没人会相信这个结果。
• 公布名次和评审标准。不要公开每位评委和每支队伍的原始分数，也不要公开数值权重，除非活动已在提交截止前公布这些权重：公开其中任何一项，都会把决策变成排行榜，队伍会以评分标准根本无法支持的精度对其进行审查；公开原始分数还会暴露评委的姓名。
• 在提交截止前，于已发布的规则中说明一条争议处理途径：
  • 谁会收到申诉。
  • 申诉期限；该期限应在奖品发放前结束，因为发奖后推翻结果就成了 samber/dev-event-organizer-skills@hackathon-cash-prize 的问题。
  • 实际上哪些内容可以更改。计算错误或资格判定错误可以更改结果；评委的意见不能。
• 这条争议处理途径是本技能自行设计的内容。行为准则处罚申诉是另一个主题，有些活动会公布此类申诉流程；评审申诉则不会。

失败模式

• 在这里重新决定演示形式。 Expo、Stage 或 Video 已在上游确定，作为 t 输入传入，而不是待选项。重新讨论会使已计算出的分配方案失效。
• 在计算评审时段前招募评委。 评委人数是算式最后需要的输入，而不是第一个。先询问 N、t 和 W。
• 为实现全面覆盖而增加评委。 上限 N ≤ W / t 中没有 J。增加评委只会让抽样评审小组更充实，绝不会延长全面覆盖的范围。
• 对抽样评审小组的原始分数取平均值。 只有每位评委都评审过每支队伍时，偏严评委常数才会相互抵消。在抽样评审中，它只会影响其中一组结果，并改变名次。
• 在颁奖仪式上才发现有赞助商评委。 同一事实，仅因披露时间不同就会导致截然相反的结果：
  • 提前在规则中披露，这是规则。
  • 公布结果后才披露，这是丑闻。
• 在领奖台上临时编造平局处理规则。 两支队伍打平却没有已公布的决胜顺序，就意味着谁先发言，谁就能在现场、当着两支队伍的面决定结果。
• 类别从未出现在队伍读到的简报中。 队伍会针对被告知的评审要点进行优化。未披露的类别评审的是一场根本没人报名参加的竞赛。隐去每个类别背后的数值权重，是另一项合理的防刷分保密措施（参见 § 淘汰标准）——不要把两者混为一谈。
• 评委同时参赛。 组织者、志愿者、评委和赞助商不得作为黑客参赛。评分前就要核对参赛者名单和评委名单，而不是评分后才核对。

测量

以下各项均为自行设定的门槛；介绍时请明确说明这一点。

通过门槛（仅一项，结构性）：开始评分前，以下六项都已书面列出，且没有任何空白。

• 评审标准及权重。
• 评分等级。
• 分配表，注明每位评委负责评审哪些团队。
• 利益冲突规则及回避时的替代方案。
• 平局决胜顺序。
• 竞赛申诉流程。

反复迭代，直到六项齐全。

**可行性门槛（算术，活动当天前核验）：**计算 k = floor((J × W) / (N × t))。

• k ≥ 1：确认的评委能在该形式规定的接触时间内评审每个团队，按现有方案即可实施。
• k < 1：评委无法做到。这属于第 3 档，而不是方案失败。根据该档规定的分配选项，重新核算分流轮次的门槛。预筛选是通过／不通过检查，会占用部分 W，因此决赛名单必须按晋级决赛的团队数量 N₂ 和剩余时间窗口 W₂ 满足 k ≥ 1。如果届时仍不满足，唯一合理的应对方式是延长时间窗口或更改形式，并且两者都必须在活动开始前决定。

绝不要在活动当天通过缩短 t 来消化 k < 1。这会让先被评审的团队获得不同的评分机会。

记录以下信号，以供下一届参考：

• 在时间窗口内完成所分配评审任务的评委。
• 获得的评委人数少于分配表承诺的团队。
• 启动回避程序的次数。
• 收到的申诉。

选取两到三项，写明每项将触发的修订，并在颁奖前而非颁奖后记录下来。

调用示例

• “我们预计有 60 支团队、12 位评委，从提交截止到颁奖典礼之间有 2 小时。该如何评审？”
• “为我们的 AI 黑客松的三个赛道制定评分量表和权重。”
• “某赞助商的合同规定，由他们的副总裁评审自家挑战赛。我们该怎么办？”
• “有两支团队并列第一。规则是什么？原本应该是什么规则？”
• “撰写评委简报和结果公布计划。”

预期输出：一份评审计划，包含：

1. 分配档位，列出算术计算过程及最终每队对应的评委人数。
2. 完整列出的加权评分量表及评分等级。
3. 与该档位对应的评分汇总规则。
4. 利益冲突规则及回避时的替代方案。
5. 已公布的平局决胜顺序。
6. 评委简报。
7. 结果公布计划和竞赛申诉流程。
8. 需要记录的信号。
9. 如活动设有淘汰标准，应将其与加权评分量表分开公布。

在开始评审前，按章节逐一呈现，以便核验。

参考资料

• samber/dev-event-organizer-skills@event-run-of-show - 安排评审时间窗口和颁奖典礼，本技能的算术计算依赖这些安排。
• samber/dev-event-organizer-skills@event-feedback - 在活动结束后收集参与者对评审公平性的看法。