hackathon-cash-prize

黑客马拉松现金奖

由你决定黑客马拉松如何奖励获胜者：奖励形式、奖池金额、分配方式、谁可以获得奖励，以及如何交付奖励而不产生未经核实的义务。

组织者通常会先询问现金，但现金并非推荐选项。在假设用户需要一个金额之前，请先阅读奖励形式选项。

你负责什么，以及哪些事项已经确定

你负责奖项：奖励形式、奖池总额、分配方案、获得奖励的资格，以及发放机制。

• 排名不归你负责。 samber/dev-event-organizer-skills@hackathon-judging 会给出每个赛道的排名结果，并将结果交给你。你要把名次转化为奖励。绝不要重新评定名次，也绝不能让奖项金额影响获胜者的判定。
• 规则文件不归你负责。 samber/dev-event-organizer-skills@hackathon-brief-design 负责发布活动简章，包括参赛资格：谁可以参赛、年龄要求、地区要求和雇佣关系要求。你负责的是更窄的问题：符合规则的团队获胜后，谁可以依法_获得_奖励。请将这段内容交给活动简章，而不是自行起草规则文件。
  • 在这项技能出现之前，任何一项技能都没有明确划分这项职责。介绍时请明确说明，因为使用过活动简章技能的读者会认为资格问题应由该技能负责。
• 奖池上限不归你负责。 samber/dev-event-organizer-skills@event-budget 会在整体损益表中设定 Prizes 项。提出的奖池和分配方案必须符合该项目的预算。
  • 绝不要脱离这一项自行设定奖池金额。如果该项目尚不存在，请直接说明，不要凭空估算。
  • 该技能会提及此技能，并以相同方式说明交接流程，因此你遵循的是双方商定的边界，而不是单方面规定边界。
• 赞助商出资的奖项在别处售卖，也在别处交付。 samber/dev-event-organizer-skills@event-sponsor-pricing 会为筹资的赞助加购项定价；samber/dev-event-organizer-skills@event-sponsor-fulfillment 会将其作为可追踪的福利进行交付。赞助签署后，由你决定奖项的形式——奖励形式、分配方式和资格。
  • 这两项技能都没有提及此技能，也都没有提到竞赛奖项：交付技能中唯一的奖品等级是下文的展位抽奖奖品。
  • 因此，你是在尚无约定的情况下确立这一边界，而不是重述已有约定。请明确说明这一点。
• 抽奖奖品不是竞赛奖项。 展位抽奖是面向所有参会者的参与激励，归 samber/dev-event-organizer-skills@event-sponsor-fulfillment 负责。竞赛奖项则根据评审排名颁发。两者都由赞助商出资，也都称为“奖品”，但机制不同，资格问题也不同。

以下所有排名都只是默认方案，并非铁律。完成访谈后，请根据你掌握的信息重新评估各选项的优先级：例如，已到手的赞助商额度、没有法律实体的组织者、希望获得零部件的硬件活动参与者，或上一届已经公布奖项结构的回归活动。

访谈

每次只问一个问题，尽量采用选择题。之所以有问题 4-9，是因为菜单会根据这些问题调整，而其他问题都无法揭示这些事实。

1. 活动预算中的 Prizes 一项包含什么，是否已经设定？（这是固定投入——奖项规模只能在预算内确定，不能增加预算。）
2. 简介中已经公布了哪些赛道和名次设置，其中是否承诺了任何奖项？设计任何内容前，先阅读已公布的规则；书面承诺的奖项是既定责任，而不是可选项。
3. 哪些赞助商为奖项提供资金，他们购买了什么，资金形式是现金、产品额度、硬件，还是由赞助商自己的公司掌控的机会？
4. 获奖者是否可能是未成年人，是否可能来自主办方所在国家以外？这两点都要明确询问——它们会分别从两个菜单中删去选项，其他问题都无法揭示这些事实。
5. 主办团队是否有自己的法人实体，还是依托学校、公司或财务托管方运营？这决定了谁有资格签署付款，以及资金转移需要多长时间。
6. 主办方、志愿者、导师、评委或赞助商员工是否可以参赛？如果可以，他们能否获奖？这是两种不同的许可，大多数活动会将它们混为一谈。
7. 你希望奖项在活动前吸引关注，还是在活动结束后奖励获奖者？为营销设计的奖项规模与为获奖者设计的奖项规模是两种不同的决策，也各有不同的失效模式。
8. 工作量上限是什么：活动前主办方能投入多少小时，活动后是否有人愿意追着获奖者补交材料，以及出错后能接受多大程度的不可逆影响？
9. 奖项设置必须在什么日期前公布？这是一次性活动，还是需要让设置明年仍然适用的定期活动？

Q7 至 Q9 会调整具体选项。重新排序时，请指出是哪一个问题导致的。

• **临近发布日期（Q9）**会优先选择无需采购准备时间的形式：先考虑荣誉认可和额度；只有在相应菜单的删除条件未触发时，才考虑现金。装备则会被排到最末，因为同一菜单的缺货预警指出其交付时间最长。
• **活动前吸引关注的意图（Q7）**是唯一会让旗舰奖池优先级上升的因素。若意图是奖励获奖者，旗舰奖池就会被冷落。
• **一次性活动（Q9）**会让赞助商资助的奖池优先，因为筹款工作已经在其他地方进行。若活动要求每年举办，则应优先选择编写一次、重复使用的内容，即标准付款条款和已公布的资格说明；这也使得法律顾问审查的成本能在多届活动中摊销，而不是只用一次。
• **较低的工作量上限（Q8）**会删去跨多个赛道平均分配的方案，因为其全部成本就是为每位获奖者重复办理付款。

工作流

1. 进行访谈。先阅读预算的 Prizes 行（Q1）和已发布的简章（Q2）。
2. 先回答奖品形式问题，再回答规模问题。 奖品形式决定哪些法律类别与当前情形相关；如果奖品不是现金，关于规模的讨论就有一半可以省去。加载 references/prize-medium-catalog.md。
3. 在 Prizes 行的范围内确定奖池规模，并区分组织方自己的基准金额与由赞助商出资的部分。两者的上限和责任方不同。
4. 根据简章已经公布的赛道结构选择分配方式，而不是从空白页面开始。
5. 编写领奖资格文本，并将其交给 samber/dev-event-organizer-skills@hackathon-brief-design，用于编写规则文档。加载 references/eligibility-to-receive-text.md。
6. 选择付款严格程度，并列出所选奖品形式和获奖者奖池会触发的所有风险类别。将每项交由相应负责人处理——不要自行作答。加载 references/payout-exposure-categories.md。
7. 在提交截止前，将奖品结构发布在简章中。团队已经选好要做什么后才公布奖品，就已经无法激励他们了。
8. 活动当天，获取 samber/dev-event-organizer-skills@hackathon-judging 提供的排名结果，并按照已发布的结构颁奖。记录实际交付的奖品、领奖人，以及仍未完成的事项。

按章节展示结构，以便逐项确认——奖品形式、奖池、分配方式、领奖资格、付款机制——确认完毕后再将其纳入已发布的简章。发布即不可逆，因为已发布的奖品就是一项承诺。

如果你的运行环境具有持久记忆，请记录：

• 奖品形式及其原因
• 奖池及其符合的上限
• 分配方式
• 领奖资格的排除项
• 各项风险类别交由谁处理

奖品形式

五个等级：

1. 现金
2. 实物：参与者可以留作己用的硬件、组件和工具。
3. 额度和代金券：云服务或 SaaS 额度、礼品卡、创客空间额度。
4. 机会：会议门票、导师辅导名额、面试或投资人引荐。
5. 仅荣誉：奖杯、头衔、公开报道，不含可转让价值。

这里的价值维度与直觉相反。MLH 的组织者指南将奖品决策描述为一种行为层面的选择，而非金钱层面的选择：奖品“充分体现了你们作为一个社区的特质、你们最初为何聚在一起，并极大地影响活动氛围”。MLH 表明了自己对现金的立场：“虽然现金奖对活动来说很容易发放，但我们不建议这样做。与传统奖品相比，现金奖的感知价值要低得多。”

这一说法的方向会改变默认排序。这是某位组织者陈述的立场，并非经测量得出的结果比较。

• 价值（获奖者感知到的价值，以及奖品所奖励的行为，如上述框架所述）：机会 > 实物 > 额度 > 现金 > 仅荣誉
• 投入（采购时长、采购流程、与第三方协调、事后联系获奖者）：机会 > 实物 > 额度 > 现金 > 仅荣誉
• 合规成本，指各等级引发的审核，以及由此付出的可撤销性成本：现金 > 额度 > 实物 > 机会 > 仅荣誉
• 效率：实物 > 仅荣誉 > 额度 > 现金 > 机会

五个等级的价值和投入排序一致。因此，不存在这样的两个等级：一个等级的价值大于或等于另一个等级，且各项成本都小于或等于另一个等级。不要试图通过断言现金无疑是成本最低的等级来人为制造分歧：现金最容易采购，却最难交付，因此其成本属于合规维度，而非投入维度。 合规性这一维度决定了菜单的重新排序，也解释了为什么默认选项既不是价值最高的一档，也不是成本最低的一档。现金通过支付渠道发放给具名个人，因此该渠道会涉及税务、跨境和未成年人发放类别；而在餐桌上递出一把键盘则不会。积分与现金并列，因为可兑换、可转售的代码具有货币价值，却不必经过银行。

这一支付渠道是有据可查的惯例，而非假设。Devpost 自身的奖金领取流程要求现金获奖者在资金发放前提交税务身份表格，并为国际个人和组织分别提供另一种表格；平台还明确指出，每位获奖者都要自行判断适用哪种表格。一般税务合规实践在申报时将礼品卡或代金券视同现金，而对实物商品则通过公平市场价值机制估值：这就是为什么积分在这一维度上与现金并列，而不是与设备并列。

机会档在这一维度上的位置完全基于推理。它仍是菜单中把握最小的一项，因此在介绍排序时，应将其表述为一个开放问题。

• 实物奖品——默认选项。 这是 MLH 自己推荐的方向，也是唯一兼具高感知价值且无需支付渠道的档位。它需要投入实际的采购时间，并且有一项已知限制：许多物品会缺货，因此要尽早订购奖品，确保及时到货。它还会带来其他档位没有的单件数量影响，详见组合菜单。
• 仅提供表彰。 这既不是后备方案，也不是降级选择。hackathon.guide 的作者有意按这一档举办活动：“别评选赢家和输家。真的别这么做。我的黑客马拉松从来没有啤酒、比赛或时间压力。”这是公民科技组织者自己的做法，因此这确实是经过选择的档位，不过未必适合竞争性学生活动。
  • 从另一个角度看：MLH、PennApps、Papers We Love 和 NASA Space Apps 在公开定位时，都把学习、构建和分享放在奖品规模之前。这样的活动只提供表彰，会显得前后一致，而非吝啬。
  • 提升条件，以 Q7 为准：奖品是为了奖励获胜者，而不是为了吸引关注；或者 Q5 表示团队没有法律实体，也没有财务托管方，此时只有这一档不需要两者。
  • 优先选择能在仪式结束后继续保留价值的形式。由一届届参与者传递的奖杯，或来自获胜者敬重之人的公开认可，都比没人会留存的证书更有持久价值。
• 额度和代金券。 如果赞助商已经持有这些资源（Q3），采购成本就很低，对赞助商来说也几乎免费，因此它们在赞助商资助的赛道中比其他任何地方都更常见。它们带有有效期、兑换地区和账户要求，获胜者几个月后可能无法满足。请在公布的奖品方案中注明有效期，否则你会收到相关投诉。
• 现金。 采购成本最低，在合规性方面负担最大，因此效率排序将它列在第四，而非第一。如果 Q4 表示获胜者可能是未成年人或不在组织方所在国家，或者 Q5 表示没有法律实体且没有财务托管方，就从此菜单及上方的坐标轴说明中删除现金。 在这些情况下，正确支付现金所需的机制尚不存在，而菜单底部的现金奖会悄然变成仪式当天的计划。
• 机会——被冷落的选项：价值最高，投入最多，因此效率排序永远不会选中它。MLH 在自己的目录中列出了这一档：大会门票、“与偶像共进午餐”、参观公司，以及在其硬件指南中提到的向种子基金提供者作介绍。
  • 其法律定性尚无定论：在某些司法管辖区，实际构成求职或投资引荐的奖项可能涉及就业或证券法规。提供此类奖项时，应将其列为待解问题。
  • 提升条件，以 Q3 为准：外部机构——赞助商的招聘团队、大会或投资者——已作出书面承诺。
  • 如果没有这样的承诺，就从此菜单及上方的坐标轴说明中删除这一项：组织方无法实际兑现的机会，是唯一会在获胜者已经公布后公开失效的奖品。

完整的中等规模目录、收据和退货做法，以及单件数量的计算方式，见 references/prize-medium-catalog.md。

奖金池总额

分为四档：

1. 无现金奖金池
2. 适度奖金池：金额以「奖品」预算项为限。
3. 赞助商资助的奖金池：组织者自身的基准预算为零，奖金池仅随已签署的承诺而增加。
4. 旗舰奖金池：有意将其设为活动的头号亮点。

• 价值（参赛作品数量和到场人数——属于论证，并非测量结果）：旗舰 > 赞助商资助 > 适度 > 无现金奖金池
• 工作量（筹款、预算协商，以及随之而来的采购或发放工作量）：旗舰 > 赞助商资助 > 适度 > 无现金奖金池
• 合规成本：旗舰 > 赞助商资助 > 适度 > 无现金奖金池
• 效率：赞助商资助 > 适度 > 无现金奖金池 > 旗舰

三个维度的排序都相同。六种两两比较中，价值较高的一档在工作量和合规成本上都_严格_更差，因此没有任何一档能免费赢得某个维度，也没有任何一对能满足“价值大于或等于，且每项成本小于或等于”。以下排序依据论证，而非核查。

严谨的奖金发放方案菜单也同样没有意义，原因各不相同，具体原因见该处说明。

有两点与直觉上的价值排序相悖。应将两点都交由用户判断，而不是替用户定夺。

价值维度基于假设，而非测量结果。“旗舰奖金池会吸引更多参赛作品”尚未经过检验。应将其作为假设呈现给用户，因为已发布的材料正反皆有，无法得出定论。

• 反对按头条价值来设定奖金池。 Devpost 自身的组织者指南指出，奖金过低可能会抑制参与度；根据其自身经验，适度且分配合理的奖金池效果不逊于大得多的奖金池；奖金更多也无法保证参赛作品更出色。参与者互动、技术支持、宣传和简单的要求同样重要。
• 支持这一观点，但只是单届活动的示例，而非受控测量。 ETHGlobal Bangkok 在同一届活动中创下历史最高奖金池，同时吸引了 713 份项目提交，约有 1,950 名黑客参与，两项数据均创纪录。HackYeah 最近公布的数据则显示，参会者近 3,000 人，提交项目超过 300 个；但组织者没有按奖项名次列出奖金池金额。

这两场活动都没有控制各自的逐年增长，也没有公布同届活动中与更小奖金池的对比数据。应将两者视为背景情况，而非支持或反驳该维度的证据。

另一个制衡因素无论参与人数多少，都指向相反方向。 上述四个组织的首要宣传重点都是学习、构建和分享，而非奖金规模。因此，以头条奖金池为主打，等于在可信的大型活动有意避开的领域竞争，也会筛选出为奖金而来的参与者。

• 赞助商资助——有任何赞助商参与时的默认选项（Q3）。 现有的赞助技能已经涵盖筹款；奖金池随实际签署的承诺而增减，而非寄望于尚未落实的资金；也不会占用组织者自身的「奖品」预算项。其失败模式是资金尚未到账就宣布奖金池。
• 适度奖金池，以「奖品」预算项为限——没有赞助商为奖项提供资金时的默认选项。 实际的预算上限为其划定边界，因此这种方案才安全。
• 无现金奖金池。 在所有维度上都近乎为零，而且是合理的方案，并不代表失败。它排在第三而非第一，仅仅因为它放弃了有资金支持的奖项所带来的赞助商资源。
• 旗舰——受限选项：在所有维度上都处于顶端，因此效率维度永远不会选它。推广条件与 Q1 和 Q7 挂钩：「奖品」预算项确实足够大，奖金池可纳入其中而无需调整其他预算项，并且用户明确表示，活动前吸引关注比活动后给予奖励更重要。如果 Q1 表明「奖品」预算项尚未设定，就从此菜单及上方的维度排序中删除旗舰选项——在没有预算上限的情况下设定头条奖金池，等于代表一笔尚未编制的预算作出承诺。

结构划分

分为四档：

1. 赢家通吃：一个大奖，亚军奖项较少或没有。
2. 阶梯式领奖台：第一、第二、第三名，奖项依次递减。
3. 仅设赛道奖项：不设总奖项；所有奖项都归属于某个挑战赛道。
4. 多个赛道平分奖项：设有许多相近的奖项，不设头条大奖。

• 价值（让团队有明确目标、完成赞助商赛道要求、让新手有机会获奖）：多个赛道平分奖项 > 阶梯式领奖台 > 仅设赛道奖项 > 赢家通吃
• 工作量（奖项数量、反复进行的每位获奖者资格检查，以及单件采购）：多个赛道平分奖项 > 仅设赛道奖项 > 阶梯式领奖台 > 赢家通吃
• 合规成本，即针对不同获奖者重新检查某一风险类别的次数：多个赛道平分奖项 > 仅设赛道奖项 > 阶梯式领奖台 > 赢家通吃
• 效率：阶梯式领奖台 > 赢家通吃 > 仅设赛道奖项 > 多个赛道平分奖项

效率这一行将阶梯式领奖台排在仅设赛道奖项之前，是因为阶梯式领奖台的价值更高、工作量更少，合规成本也更低。

Devpost 自己的组织者指南直接支持价值这一维度：按照该平台的经验，将奖池拆分成多个获奖机会是最有效的结构，因为参与者希望在投入数小时进行构建之前，先有合理的获奖机会。

支配关系检查：

• 多个赛道平分奖项不会支配其他选项（在每个成本维度上都排第一）。
• 赢家通吃不会支配其他选项（价值最低）。
• 仅设赛道奖项不支配任何选项。

仅设赛道奖项在价值上低于阶梯式领奖台，原因很明确：如果没有总奖项，没使用任何赞助商产品的团队就完全没有目标可争取，而这类团队往往正是活动最希望留住的。

有一种机制能让这份菜单更具体，却经常被忽略：非现金奖品按人头计算单位数量，现金则不按人头计算。 MLH 将其列为组织者必须决定的规则之一——“团队人数可以不设上限吗？这样你可能只有 4 份奖品？”

MLH 也给出了相应的采购做法：“保存所有奖品的收据。如果获胜团队有 3 名成员而不是 4 名成员，你可以退回奖品，把预算留到下一年。”因此，规划装备或额度分配时，应按团队人数上限以整数单位拆分，并明确规定剩余单位的处理方式。现金则可以任意拆分，这就是为什么要先考虑奖品形式。

• 阶梯式领奖台——默认选项。 比最低档多一个奖项、多一次资格检查，却能让第二和第三支团队也有实实在在的目标可争取。一种已公开的方案是：PennApps 将前三名的奖池按 50/30/20 分配给总冠军、第二名和第三名，因此总冠军奖项是第三名的 2.5 倍，第二名奖项是第三名的 1.5 倍。

• 赢家通吃。 每个维度上的成本都最低，但只能激励那些本就认为自己有望获胜的团队。一旦有赞助商为某个赛道提供资金，就从这份菜单和上方的维度排序中删除此选项（Q3）：赞助商购买的是一个具名奖项，而这种结构没有位置安排它。

• 仅设赛道奖项。 当活动说明已公布赛道且不设总类别时，这是正确选择；这是活动说明中的决定，而不是这里的决定。如果已公布的活动说明中设有总类别，这一档就与之矛盾。

• 多个赛道平分奖项——资源紧张时的选项：在每个成本维度上都排第一，而且每增加一个奖项，都要针对新的获奖者重复整套资格和发奖检查。升级条件由 Q2 和 Q3 决定：已经公布多个赞助商赛道，并且奖品形式为非现金，因此重复的获奖者检查只是交接，而不是付款。

  平分奖项的结构通常会组合不同类型的奖项，而不是重复同一种模式：

  • 排名领奖台
  • 由参会者投票决定、而非由评委评选的观众选择奖
  • 每种赞助商技术或方法各设一个横向奖项，让每位赞助商都有一个以其命名的奖项，同时不削弱领奖台奖项的分量
  • 如果主竞赛期间还并行开展非评审活动，则为该活动单独设置一个小奖项，并与任何评审奖项明确区分

按照本菜单各自的标准，每一层仍然都是一个奖项。每个奖项都要重复进行资格和支付核查。

获奖资格与支付严谨性

有资格领取奖项，不等于有资格参赛；已有公开实践明确区分了两者。MLH 的可直接复制规则写道：“本活动仅限学生参加。志愿者、组织者或导师均无资格获得任何奖项，但如果愿意，他们可以为自己的作品集参与项目开发。”

这句话允许同一批人参与开发，却禁止他们获奖，正是我们所说的区分。同一来源还指出，年龄范围是可直接复制的规则中故意留空、由组织者填写的一项。

samber/dev-event-organizer-skills@event-volunteer-experience 从志愿服务的角度得出了相同结论：任何具有实际现金价值的志愿者奖励都应取消，因为如果奖励看起来像工资，就不再属于志愿服务。将两者视为同一原则：所有参与活动工作的人都不能领取奖项，不论他们获准参与哪些开发工作。

支付方式本身有四个层级：

1. 非正式交付：奖品当场易主，不作任何记录。
2. 标准表单支付：公布领取资格说明、设置领奖步骤，并根据支付方式收集适当的身份或状态信息。
3. 托管支付：由财务托管方或提供资金的赞助商按照自己的流程支付，组织者仅提供协助。
4. 法律顾问审查后支付：宣布任何奖项前进行法律审查。

• 价值（奖项受到质疑时的可辩护性，以及实际避免的风险）：counsel-reviewed > administered > standard-form > informal handover
• 工作量（耗费的时间、与托管方或赞助商的协调，以及聘请法律顾问的成本）：counsel-reviewed > administered > standard-form > informal handover
• 合规成本，取决于每个层级会触发的审查，以及因此失去的灵活性：counsel-reviewed > informal handover > administered > standard-form
• 效率：standard-form > administered > informal handover > counsel-reviewed

价值和工作量的排序完全一致，正如奖池规模菜单中的排序。合规这一维度也不会产生支配关系：被重新排序的非正式交付，在工作量上也是成本最低的，因此没有任何一对能同时在所有维度上胜出。下面的论证说明了这一排序的依据。

合规这一维度有意采用非单调排序，且此处的论证针对的是支付，而非借用 samber/dev-event-organizer-skills@hackathon-judging 中关于利益冲突的菜单。非正式交付不会触发活动前审查，而是将全部审查推迟到最难撤回的时刻——钱或物品已经交到陌生人手中之后。

错误的排名可以重新公布。支付无法撤销，而奖品若交给了错误的领取者，就只能请求对方归还。正因两者不对称，默认选项才不是成本最低的层级。

• 标准形式的奖金发放——默认选项。 活动前趁修改成本还低时，先写好并发布一段说明和一个申领奖励步骤。这是合规性维度上的最低一档，因为它触发的审核发生在犯错无需付出代价的唯一时机。
• 由管理方发放奖金。 推广条件与 Q3 和 Q5 相关：由财政托管方保管资金，或出资赞助方倾向于直接向其赛道的获胜者发放奖金。宣布前要书面明确职责分工，因为“赞助方会处理”不算奖金发放计划。
• 非正式交接。 如果奖品是现金或现金等价物，或者 Q4 的答案表明获胜者可能是未成年人或不在组织者所在国家／地区，就从此菜单和上方的维度说明中删除此选项。 只有在活动现场向成年接收者交付实物时，才保留此选项。
• 由律师审核——最不受青睐的选项：价值、工作量和合规成本均处于最高档。推广条件与 Q1 相关：奖池足够大，以至于落败团队会追问由谁决定、依据是什么。应转交实际的法律顾问或财政托管方来推进，而不是自己撰写听起来像法律条文的句子。

Q4-Q6 中有三项答案是门槛，而不是菜单选项，比例对此没有发言权。 获胜者中有未成年人、获胜者不在组织者所在国家／地区，以及赞助方自己的员工有资格赢得该赞助方自己的赛道，这三种情况各自都涉及法律义务。存在义务时，应由义务决定应对方式，而不是将其与工作量权衡。

这三种情况中的任何一种出现时，无论效率线落在哪一档，都应在公布奖项前由法律顾问或财政托管方审核奖金发放事宜。效率此时只用于排序剩下的事项：如何管理仍然可行的奖金发放机制，而不是决定是否进行审核。

无论选择哪一档，都应公布一项机制。奖项可以附带获胜者必须持续履行的条件；MLH 公布的规则规定，获奖资格取决于提交的代码和视频之后是否继续公开：“如果你的仓库和视频未公开，可能会选出新的获胜者。” 若采用持续性条件，应在公布的规则中说明奖项何时成为最终结果，因为在此之前奖项都可以撤销，所有人都应知情。

可公布的资格文本、例外清单，以及可交给简报的措辞，见 references/eligibility-to-receive-text.md。

本技能绝不会说明的内容

竞赛法律分类、税款预扣和申报、跨境付款以及未成年人的处理方式都因司法管辖区而异，而且会发生变化。本技能绝不提供任何数字门槛、税表名称或货币金额。 在指导组织者如何向陌生人付款的文档中，给出一个听起来似乎合理的门槛，比完全不提供指导更糟。

指出相关风险类别，每次都说明具体门槛或表格因司法管辖区而异，并指引其寻求相应帮助。

• 竞赛法律分类——在特定司法管辖区内，奖项竞赛究竟算技能竞赛还是机会游戏；这会改变适用的监管制度。这也是为什么 samber/dev-event-organizer-skills@hackathon-judging 避免用抛硬币决定平局：平局处理方法是少数几项可能让活动跨过这条界线的组织者决策之一。
• 具有货币价值的奖项所涉及的付款方税务申报和预扣，通常由组织者而非获奖者承担。
• 跨境付款——付款渠道本身，以及适用于另一国家获奖者的任何当地规则和税收协定问题。
• 未成年人领取奖项，可能需要由监护人代领或共同签署。这与 MLH 清单涵盖的问题不同；MLH 的清单涉及未成年人在场地过夜的豁免。
• 赞助商员工领取该赞助商自己的专题赛奖项——这是一个实际存在的利益冲突，与 samber/dev-event-organizer-skills@hackathon-judging 已经处理的排名评审利益冲突不同。
• 组织者、志愿者、导师和评委领取任何奖项，这是唯一有公开惯例可循的类别（见上文）。

将每项实际涉及的类别转交法律顾问、财政托管方或出资赞助商自己的法律团队处理。

MLH 的组织者指南提供的是转交处理的框架，而非答案，可用作活动前检查清单：

• 非营利组织身份
• 保险
• 谁拥有签署权限，以及审核需要多长时间
• 资金存放在哪里，以及实际需要多久才能支出
• 引用来源原话：“我们是否需要了解任何税务要求？是否需要保留收据？”

对于没有独立法人实体的组织者，同一来源将财政赞助列为标准途径，并列出 Hack Club 和 Hack+ 这两个专为黑客松提供财政赞助的机构。相关类别和转交处理流程见 references/payout-exposure-categories.md。

失败模式

• 先决定金额，再考虑形式。 关于金额的讨论有一半涉及现金奖才会遇到的问题。始终先确定形式。
• 在没有上限的情况下确定奖池。 如果预算中还没有“奖项”这一项，就先公布奖项，相当于替别人承诺花钱。
• 赞助款到账前就公布由赞助商出资的奖项。 奖项公布后，赞助未能落实，组织者就得自己承担资金缺口。
• 把实物奖品当成现金一样分配。 四件奖品遇上三人获胜团队时，应该提前决定怎么分，或者在颁奖台上临场决定。
• 让奖项影响排名。 samber/dev-event-organizer-skills@hackathon-judging 会给出排名结果。为了让偏爱的团队获得更好的分配而重新调整奖品分配，实质上就是换个方式重新评审。
• 把参赛资格当成领奖资格。 志愿者可以为了丰富作品集而开发项目，并不代表他们也可以带走奖品。
• 回答税务问题。 这个问题每次看起来都很简单，但正确答案每次都是转交给相关人员处理。
• 认为赞助商提供的实物赞助就值其零售价。 samber/dev-event-organizer-skills@event-sponsor-pricing 按实物赞助所抵扣的预算项目金额来估值。将这种方法用于奖品前，先确认它是否适用：奖品抵扣的是组织者原本可能根本不会支出的“奖项”预算。
• 认为实物奖品的领奖台顺序与感知价值相符。 不同赞助商提供的额度或产品奖品，实际用途各不相同，因此，第三名获得的实物奖品对获奖者来说，可能比第一名从实用性较低的赞助商那里获得的奖品更有价值。在向提供奖品的赞助商说明各奖项档次前，先确认每件奖品对获奖者的实际价值。

衡量标准

以下所有标准都是自行设定的门槛，并非行业标准；介绍时请说明这一点。不同活动的奖池规模和分配方式不可直接比较，因此不要照搬其他活动的数字作为目标。

通过门槛（结构性，仅此一项）：简章发布前，以下六项都已书面明确，且没有任何空白。

• 奖品形式。
• 奖池总额及其对应的预算项目。
• 分配方式及奖项数量。
• 领奖资格说明。
• 明确由谁移交什么的发奖方式。
• 曝光类别清单，以及每类交由谁处理。

反复完善，直到六项齐全。

之后值得记录的信号（自行设定）：

• 实际发出的奖项与已公布奖项的数量对比
• 从未领取奖品的获奖者
• 按团队人数规则分配后剩余的奖品数量
• 活动当天出现、但已发布规则中没有答案的资格问题

选两三项，并写下每项会促使你做出什么修订。

调用示例

• “我们有三个赞助商赛道和一个综合奖项。奖池应该怎么分配？”
• “我们应该发现金还是硬件？无论哪种方式，预算都是固定的。”
• “一位获奖者是未成年人，另一位身处不同国家。我们需要处理哪些事项？”
• “我们的赞助商想为自己的 API 赛道出资设奖。他们的工程师可以赢得这个奖吗？”
• “为我们已发布的规则撰写奖项部分。”

预期输出：一份奖项结构，包含：

1. 奖品形式、选择理由及其合规影响。
2. 奖池总额及其对应的预算项目，并区分组织者的基础资金与赞助商出资金额。
3. 分配方式、奖项数量，以及按件数计算奖品时的剩余奖品处理规则。
4. 可直接写入简章的领奖资格说明。
5. 发奖方式及各方分工。
6. 当前适用的曝光类别，以及每类交由谁处理。

按部分逐项呈现，供发布前确认。

参考资料

• references/prize-medium-catalog.md
• references/eligibility-to-receive-text.md
• references/payout-exposure-categories.md

另请参阅同一集合中的：

• samber/dev-event-organizer-skills@event-vendor-sourcing - 采购装备类奖品所需的实物商品，并考虑媒介选项清单提示的交付周期。