hackathon-brief-design

黑客马拉松简章设计

你要撰写一份交给黑客马拉松参赛团队的文档：要构建什么、遵循哪些规则、谁可以参赛、要提交什么，以及如何定义“优秀”。这是每位参与者都会阅读的唯一文档，颁奖典礼上的每一场争议，最终都能追溯到文档中某个写明或未写明的句子。

此处“赛道”的含义

挑战赛道是团队为项目报名参加的主题类别，例如 AI 赛道、赞助商 API 赛道、新手赛道。这是一种内容和奖项设置。

samber/dev-event-organizer-skills@event-format-selection 中的“赛道”指的是并行的活动环节流，即单轨或多轨日程安排。同一个词，概念不同。

凡是读者可能理解成另一种含义的地方，都要写成挑战赛道。关于活动环节赛道的决定，在这里毫无帮助。

你负责什么，哪些事情已经决定

你负责撰写简章：

• 问题陈述
• 挑战赛道内容
• 规则和参赛资格说明
• 提交清单
• 赞助商挑战赛的设计
• 评审类别的_名称_

有三件事已经决定好了。请将其写入文档，而不是重新讨论。

• 演示／评审形式（展览桌、舞台演讲、仅视频，或两阶段混合形式）由 samber/dev-event-organizer-skills@event-format-selection 负责。你要把它转化为提交清单和截止时间，而不是自行选择：仅视频的活动中，视频就是交付内容；展览形式的活动中，视频则是可选项。交付内容的格式取决于该决定，绝不是由你在这里独立决定的。
• 评审标准权重、评分尺度、评委分配、平局处理和争议由 samber/dev-event-organizer-skills@hackathon-judging 负责。该技能从自身角度明确了职责边界：已发布简章中评审类别的名称由你负责；它会在此基础上设定权重并构建评审机制。列出类别，但绝不要写出权重、评分尺度或总分。
• 奖项金额、现金还是非现金奖品，以及奖金发放方式由 samber/dev-event-organizer-skills@hackathon-cash-prize 负责。写“每个挑战赛道都会颁发奖项”，绝不要写金额。

以下所有排序都只是默认顺序，并非定规。访谈结束后，请根据你对本次活动已知的信息，重新排列每个选项：

• 上届公布的规则
• 已签署的赞助协议
• 曾使用过该 API 的组织者
• 新手占比较高的参赛者群体

访谈

一次只问一个问题，尽可能采用选择题。第 3–5 题和第 8–9 题会决定各菜单默认采用哪个层级；未得到这些答案，不能确定默认选项。

1. 黑客活动的时长是多少小时？活动是线下举行还是完全以数字形式进行？
2. 已经选定哪种演示／评审结构？（固定输入——不要重新决定。）
3. 参与者是自带要解决的问题，还是由组织方提供问题说明？两者兼有也是有效答案。
4. 有多少赞助商为奖项提供资金？是否已有任何已签署的协议承诺设置具名挑战赛道？
5. 是否有赞助商的 API、数据集或硬件需要密钥或账户？组织团队中是否有人实际针对它从头到尾完成过一个小项目？如果活动中途它无法使用，这些团队该怎么办？
6. 谁可以参赛，谁不能参赛：仅限学生、最低年龄限制、地域或就业限制，以及组织者和志愿者是否受限？samber/dev-event-organizer-skills@hackathon-team-formation 已经确定了什么团队人数规则——人数上限、人数下限、是否允许个人参赛？（这是你要公布的固定输入，不是由你设定的规则。下方的通过门槛会计算这一项，所以起草前先确认人数。）
7. 是否需要按人口特征或技能水平划分参赛类别——例如初学者赛道、首次参赛者配额或仅限学生的类别？
8. 奖项是否具有现金价值？是否预计有未成年人参加？提交作品时是否会收集任何个人数据？（这决定了最精简的规则层级是否还能采用。）
9. 发布计划和活动举办频率是什么？
   • 必须何时发布说明？
   • 这是一次性活动，还是需要让规则在明年仍适用的定期活动？
   • 工作量上限是多少：发布前组织者可投入多少小时？是否完全没有法律顾问可用？
10. 主题范围有多窄——限于一个垂直领域，还是任何领域都可以？是否有人测试过是否有足够多的人愿意围绕该主题开发？（这决定是否要在问题说明之前进行 § 主题需求测试。）

第 9 题的三个答案都会调整一个具名层级。重新排序时请说明调整方式：

• 如果临近发布日期，就应优先采用现成的标准规则集，而不是任何起草中的方案；同时降低完整规格挑战方案的优先级，因为其起始代码库和验收测试是这里所有菜单中组织者耗时最长的构建工作。
• 如果是定期活动，就应优先采用编写一次、重复使用的层级：带有例外条款的现成规则集，以及每条赛道的提示词框架。它们的成本可摊销到多届活动中，而一次性方案则要一次性承担全部成本。
• 如果工作量上限明确且没有法律顾问支持，不要因此降低完整法律级方案的优先级，而应说明这条路径无法实现。请如实说明，不要用自行撰写的、听起来像法律文本的内容来替代。

工作流

1. 进行访谈。如果上届有已发布的规则，先阅读。
2. 在问题陈述之前修订规则和资格要求文本。这会删去其他选项菜单中的若干阶，而且承载着真正的风险。加载 references/rules-and-eligibility-source-text.md。
3. 如果 Q10 指定了一个狭窄主题，请运行主题需求测试（见 § 主题需求测试）。然后确定挑战赛道结构，并为每条赛道撰写一份问题陈述。加载 references/problem-statement-patterns.md。
4. 将每项赞助承诺转化为赛道提示词或额外奖项评判标准，并为赞助商平台出现故障的情况撰写备用说明。
5. 确定评估类别。在简报中明确说明由谁设定权重，以及何时公布权重，然后将这些类别交给 samber/dev-event-organizer-skills@hackathon-judging。
6. 根据选定的演示结构制定提交清单，切勿使用通用模板。加载 references/submission-checklist-and-categories.md。
7. 进行歧义检查：针对每条规则，设想一个持相反解读的团队会引用什么依据。
8. 在报名截止前发布，然后冻结规则。等团队开始开发后再新增规则，就等于为一场无人报名的比赛制定规则。

按章节逐项展示简报以供确认，切勿一次性整体展示：

• 规则
• 资格要求
• 赛道
• 问题陈述
• 提交清单
• 评估类别

发布前必须获得明确批准；发布即是不可逆的节点。

如果你的执行环境支持持久记忆，请记录：

• 已发布的规则集及编辑过的字段
• 每条赛道选择的具体程度档位
• 赞助商备用说明
• 活动期间参与者实际提出的每个问题，尤其是最有用的问题，因为每个问题都指出了下一版简报需要补充的一句话
• 主题需求检查点：日期、自行设定的数量、实际数量，以及主题是否扩大
• 每个项目的活动后结果（见 § 衡量），并在活动后自行设定的时间间隔进行复核

问题陈述的具体程度

从宽泛主题到带有起始代码仓库和验收测试的完整挑战，共分为四个档位。

让目标与时间限制相匹配。 有一条从业者经验法则广为流传：“在有限时间内，大多数项目能完成的，大约只有他们认为自己能完成的 25%。”理解这个数字时要看清正确的分母：这是团队对自身工作范围的黑客马拉松前预估，而不是组织者的提示词，也不是任何绝对指标，更不是完成率。这只是某位组织者的观察，并非经测量得出的比率。

这一设计原则贯穿以下每个档位：撰写每条提示词时，都应确保团队实际完成的四分之一内容本身就可以演示；具体做法是明确列出最低可行提交内容，而不是让团队到第 40 小时才自行摸索出来。

• 价值（团队能自行判断是否符合范围；评委能将各提交进行比较）：完全指定 > 结构化陈述 > 领域限定提示词 > 开放主题
• 工作量（组织者发布前撰写所需时间，以及确保所有提示词始终符合规则所需的维护工作）：完全指定 > 结构化陈述 > 领域限定提示词 > 开放主题
• 效率：结构化陈述 > 领域限定提示词 > 开放主题 > 完全指定

支配关系检查，重新推导：只有通过构造才能得到“无支配关系”，而通过构造得出绝不等于通过检验。 两个维度的排序相同，因此不存在这样的一对档位：其中一档的价值大于或等于另一档，同时工作量小于或等于另一档。不存在任何支配关系；这项检查无法发现此处的错排，因此效率排序完全依赖下文的论据，而非任何验证。

• 结构化陈述——默认选项，分为五部分：背景、以问题形式提出的挑战、约束条件、提供的资源，以及明确说明的最低可行提交。这是团队无需询问组织者，就能判断「我们是否符合范围」的最低成本档位，也是提交清单和评估类别共同据以制定的档位，无需另行撰写。

  项目质量模板要求项目「有一个明确的问题或要解决的问题，并提出一个相当具体的解决方案」。该模板假设参赛者推介的是自己的项目，因此由组织者编写提示词时，组织者承担的责任也随之增加。

• 领域限定提示词——只用一句话点明领域，不包含其他内容。几乎不花成本就能实现有效分组，但仍未明确项目是否符合范围，而这个问题会引发澄清请求，让组织者整个周末都忙着回复。

• 开放主题——几乎不花成本，而且在参赛者自带问题的活动中确实是正确选择。推广条件以 Q3 为准：参赛者带着自己的项目到场并进行推介，此时简报的作用是说明推介机制，而非提出问题。

  只要有任何赞助商为奖项提供资金，就从此菜单和上方的坐标轴说明中删除它（Q4）。赞助商奖项需要有明确的评判标准，而把开放主题放在最底部，会悄悄让这个奖项失去评判依据。

  如果选择推介机制，同时发布一项改进要求：推介必须陈述问题，而非解决方案。推介「我们想打造 X」的团队，会在任何人验证问题是否真实存在之前就承诺采用某种方案；推介「这个目标群体面临这个问题，以下是证据」的团队，则让加入者自行决定解决方案。还要一并发布两项内容——简短的证据要求（访谈、数据、亲身经历——此处认可的任何证据）以及团队开始开发前必须达到的明确最低要求——并将二者交给 samber/dev-event-organizer-skills@hackathon-team-formation，作为推介机制运行所需的内容。

• 完整定义的挑战——被冷落的选项：价值最高，投入也最大，因此效率原则永远不会选它。搭建入门代码库、数据集和验收测试属于组织者的工程工作：需要一两天，其中大部分时间用于端到端测试代码库。

  推广条件以 Q1 和 Q5 为准：时限为一周或更长，或者赞助商已有自己的集成测试，并可原样移交。若时限短于一个周末左右，这也会改变活动的性质，把开发活动变成评分练习。

  没有任何来源给出公式，能将具体程度档位换算为所需小时数。另一个独立来源只认同这一趋势，并未提供更多信息：关于撰写 AI/ML 挑战提示词的指南按复杂度划分层级，并明确指出，最难的层级——真实世界系统、不可预测的数据、企业级可靠性——「往往超出标准的 24-72 小时时间窗口，可能更适合较长的活动形式」，而较低层级则适合在该时间窗口内完成。切勿将其视为与上文 25% 数值相同指标的第二个数据点；二者衡量的是不同的事物。

主题需求测试

主题是一场需求赌注，主题过于狭窄，甚至可能在任何人阅读活动简介之前就失败。一次主题范围狭窄的垂直领域黑客马拉松，报名人数太少。活动开始前大约一个月，团队拓宽了主题，活动名额随即报满。这是单次活动的自我报告：应将其视为测试需求的理由，而不是宽泛主题总能报满的证明。

请在发布问题陈述之前进行测试，而不是事后再测：

1. 设定一个检查日期，留出足够时间，以便仍能修改：主题一旦改变，问题陈述、赞助商提示词和宣传文案都要随之调整。
2. 为该日期设定一个由自己确定的预注册人数目标，依据自身容量和往届情况。绝不要照搬其他活动的数字。
3. 在开放报名之前，与组织者和主题赞助商预先商定扩大主题的触发条件：如果检查日期当天的报名人数低于目标，就扩大主题。现在就写下更宽泛的主题，让决策依据规则执行，而不是变成一场争论。
4. 预先商定主题扩大后哪些内容保留。 为狭窄主题提供资金的赞助商，可在更宽泛的主题中保留一条赞助商挑战赛道；请参阅下方的赛道结构。要在检查日期之前与赞助商确认，而不是等到检查日期当天。
5. 检查日期之后冻结主题。 扩大主题是最后一次主题变更。工作流第 8 步仍然有效：团队开始构建后，不再做任何调整。

将检查日期和人数目标交给 samber/dev-event-organizer-skills@event-marketing-plan，该技能负责报名目标。本技能只负责主题调整。

挑战赛道结构

四个层级：一个统一挑战赛道、普通赛道加一个赞助商赛道、普通赛道加多个赞助商赛道，以及完全划分（每个赞助商、每种人群各设赛道，另设开放赛道）。

增加挑战赛道不会拆分参赛队伍。 一支队伍提交一个项目，而这个项目可以进入多个挑战赛道；标准规则集会将两条规定并列发布：“You may not submit multiple projects”和“You may submit to multiple challenges”。每支队伍在参加赞助商赛道的同时，仍有资格角逐普通奖项，因此，增加一个赛道的边际成本是确保规则一致，而非损失参赛项目数量。这一杠杆经常被忽视，也正是它让下面每个层级都能负担得起。

• 价值（赞助商满意度、受众细分、奖项灵活性、新手的获奖机会）：完全划分 > 普通赛道加多个赞助商赛道 > 普通赛道加一个赞助商赛道 > 一个统一挑战赛道
• 工作量（撰写每项提示词、确保资格例外规定一致，以及跨赛道提交规则）：完全划分 > 普通赛道加多个赞助商赛道 > 普通赛道加一个赞助商赛道 > 一个统一挑战赛道
• 效率：普通赛道加一个赞助商赛道 > 普通赛道加多个赞助商赛道 > 一个统一挑战赛道 > 完全划分

支配关系检查，重新推导：这种排序本身就保证了结果干净，但按构造得出的结果绝不算通过。 价值和工作量在四个层级中的排序完全相同，因此不存在严格支配的成对选项，检查也没有验证这里的任何内容。上面的论证就是该排序的全部依据。

• 普通赛道加一个赞助商赛道——默认选项。第一个赞助商赛道只需增加一项提示词和一条奖项说明，就能让赞助商从提供标志展示变为挑战赛道的负责人。这里也会首次写明跨赛道规则，而这才是真正的成本。
• 普通赛道加多个赞助商赛道——每增加一个赛道所需的边际工作量会_下降_，因为第二个赛道可以套用第一个赛道已付出成本形成的模式，而价值仍在增加。总工作量依然会上升，所以它排在默认选项之下；边际工作量下降，则是它优于一个统一挑战赛道的原因。
• 一个统一挑战赛道——成本最低，但会放弃奖项灵活性和赞助商价值。只要有任何赞助商资助奖项，就立即从此菜单和上方的坐标轴说明中删除该选项（Q4）：没有命名赛道，赞助商的奖项就没有公开标准，颁奖时只能临场 improvisation。
• 完全划分——最被忽视的选项，在两条轴上都居首。启用条件与 Q4 和 Q7 相关：赞助商数量足够多，每个赞助商都资助自己的奖项，并且已经需要按人群划分资格，因此每个赛道的资格说明无论如何都得撰写。若缺少这两个条件，划分只会造出空赛道和无人角逐的奖项。

没有公开的比例可以根据参赛人数来确定赛道数量。 唯一有来源支持的上限，是根据评审能力来确定的：MLH 自己的指南建议，在没有赞助商赛道且没有总排名第 1、第 2、第 3 名的情况下，目标是设 3 个赛道，绝不超过 20 个；只有在负责评审讨论的评委能够应付、评审团不会因此陷入混乱时，才提高赛道数量。应将赞助商和评委人数视为该上限实际依据的变量，而不是参赛人数。

按人群划分资格本身就是另一个措辞问题。 应在活动开始前说明团队必须满足的比例，绝不要在团队组建后再审核。一个公开示例是“新手赛道，团队中至少一半成员必须是第一次参加黑客马拉松”。应将比例视为需要决定的内容，而将“一半”视为某场活动采用的具体数字。

规则与资格审核的严谨程度

四个层级：最低限度（团队人数上限加行为准则链接）、采用标准规则集、采用标准规则集并添加例外规定，以及经法律顾问审阅的完整法律级文本。

• 价值（避免争议、取消资格的依据是否充分、赞助方和参与者的信心）：完整法律级 > 采用并添加例外条款 > 采用标准规则集 > 最低限度
• 工作量（发布前的起草和审阅时长）：完整法律级 > 采用并添加例外条款 > 采用标准规则集 == 最低限度
• 合规成本，取决于每个级别触发的审阅以及为此付出的可逆性代价：完整法律级 > 最低限度 > 采用并添加例外条款 > 采用标准规则集
• 效率：采用标准规则集 > 采用并添加例外条款 > 最低限度 > 完整法律级

工作量上的 == 是经过论证的，并非回避问题。 最低限度并非不花时间：仍然需要有人确定团队人数上限、撰写规则并链接行为准则。采用已发布的规则集，只需进行少量修改，就能省去起草工作，因为其来源明确表示可供分叉使用——“组织者可以原样使用这些规则，也可以分叉并按需修改”。

两者的工作量处于同一数量级：不到一小时。这个等式是本技能所有菜单中唯一真正的变通之处，下面的检验也正是围绕它展开。

支配关系检查，重新推导：审慎考虑后通过。 恰好存在一种严格支配关系：采用标准规则集的价值严格高于最低限度，工作量相等，合规成本严格更低；效率排序也体现了这一点，将采用标准规则集排在首位。

• 完整法律级永远不会支配其他选项（它在每个成本维度上都最高）。
• 采用并添加例外条款永远不会支配采用标准规则集（价值更高，但工作量也严格更高）。
• 最低限度不支配任何选项。

如果这里的排序有误，检查就会失败；因此，这次检查所得的信息是其他三个菜单的检查所没有的。

• 采用标准规则集 - 默认选项，也是本技能最强烈的单项建议。已发布且可分叉的规则集已经涵盖：

  • 团队人数
  • 跨渠道发布
  • 一个项目、多条赛道
  • 活动期间进行的工作
  • 既有代码和开源软件的使用
  • AI 工具披露
  • 公开代码要求
  • 谁可以参赛
  • 取消资格的依据

  明确的规则让组织者“在必须因黑客作弊而取消其资格时，能够轻松指出具体规则”。references/rules-and-eligibility-source-text.md 列出了仍需编辑的字段；采用规则集却不编辑这些字段，是最常见的失误。

• 采用并添加例外条款 - 升级条件，以 Q6 和 Q7 为依据：设置人口特征或技能水平赛道、年龄下限，或地域或就业限制。每项例外都需要针对赛道撰写规则，并与基础规则协调一致且不相矛盾；额外的工作量就花在这里。

• 最低限度 - 一旦有任何奖品具有现金价值，或有任何赞助方提供资金，就从此菜单和上方的各维度行中删除此选项（Q8、Q4）。奖品具有价值，就会让争议变成索赔，而届时没有任何已发布的规则可供援引。它在合规成本排序中位居第二，原因也相同：活动前不触发任何审阅，而是把整个审阅推迟到最难挽回的时刻——在公开场合、奖品在场时取消资格。

• 完整法律级 - 被冷落的选项：价值最高，工作量最高，合规成本也最高。升级条件，以 Q8 和 Q9 为依据：奖品池金额高到落败团队会聘请律师，或赞助协议规定了知识产权条款。升级时应转交实际律师处理，绝不要自行撰写听起来像法律条文的句子。

Q8 的两个答案是门槛条件，而非菜单选项。 预计有未成年人参与，以及通过提交内容收集个人数据，这两种情况都涉及效率排序无法左右的义务：无论按比例评估后落在哪个级别，都必须在发布前由律师或负责组织实体数据保护的人员完成审阅。 义务决定应做什么；效率只用于排序仍可选择的方案。行为准则也是如此：所有层级都指向同一份准则，即由 samber/dev-event-organizer-skills@event-code-of-conduct 负责，简介会链接到它，而且绝不会把它当作可以与工作量权衡的选项。

关于知识产权，本技能不声明任何条款，也不作任何建议。 MLH 规则集完全没有知识产权归属条款，也没有原创性保证；唯一与归属相关的要求是，提交的代码必须公开，并持续保持公开，才有资格获奖。

提交作品归团队、组织者还是赞助商所有，属于取决于司法管辖区的法律问题。赞助商提出此类要求时，应通过 samber/dev-event-organizer-skills@event-sponsor-agreement 转交法律顾问处理，绝不要用听起来似乎合理的句子代替答案。

赞助商挑战集成深度

分为四个等级：赞助商仅作为奖金出资方列名、使用其产品的可选加分挑战、某个赛道必须使用其技术，以及将其技术作为活动的唯一底层平台。

这里的各项评估轴结论一致，而且这种分歧无法凭空制造。 一个看似合理的反驳是：相比必须使用赞助商技术的赛道，将其技术作为唯一底层平台所需的提示词撰写工作_更少_，因为不需要与通用赛道保持一致。这一点没错，但它不会颠倒评估轴的排序——与只为一个赛道的参赛者准备相比，为每位参赛者提供密钥和导师的工作量更大。应该如实说明，而不是捏造分歧。

• 价值（赞助商回报和续约可能性——基于论证，而非测量）：唯一底层平台 > 某个赛道必须使用 > 可选加分挑战 > 仅列名出资方
• 工作量（审核赞助商文档、配置密钥和账户、协调导师、在限制条件下编写提示词）：唯一底层平台 > 某个赛道必须使用 > 可选加分挑战 > 仅列名出资方
• 依赖风险（如果平台、密钥、文档或速率限制在活动期间出问题，活动简章会受到什么影响）：唯一底层平台 > 某个赛道必须使用 > 可选加分挑战 > 仅列名出资方
• 合规成本，指每个等级会触发的审查及其造成的可逆性损失：唯一底层平台 > 某个赛道必须使用 > 可选加分挑战 > 仅列名出资方
• 效率：可选加分挑战 > 某个赛道必须使用 > 仅列名出资方 > 唯一底层平台

四项评估轴的排序完全一致，因此不存在价值大于或等于另一项，同时任何成本小于或等于另一项的组合。检查在此没有发现问题，排序完全基于上述论证。

依赖风险评估轴正是这份菜单包含四条成本线，而不是两条的原因。 工作量是组织者在活动开始前付出的成本；依赖风险则是活动期间发生组织者无法控制的故障时，活动会失去什么。两者在这里的变化趋势一致，但并非同一度量，只有后者会在活动当天直接取消某个等级。

• 可选加分挑战——默认选项：赞助商产品只是获得加分奖的一种途径，绝不是唯一途径。无法拿到密钥的队伍仍能参赛，因此平台宕机只会影响一个奖项，不会影响整场活动。

• 某个赛道必须使用——与 Q4 和 Q5 挂钩的升级条件：已签署的协议承诺设置指定挑战赛道，并且组织团队中有人在发布前使用赞助商 API 端到端构建过一个小项目。绝不要仅凭赞助商声称文档质量良好就升级。

• 仅列名出资方——成本低且安全，但也是最容易违背赞助承诺的等级。如果已签署的协议承诺设置指定挑战赛道（Q4），就从这份菜单和上方的评估轴中删除此选项——此时它是合同条款，而不是菜单选项。

• 唯一底层平台——效率评估中最弱的选项，也是唯一可能被_另一个_评估轴直接剔除的等级。与 Q4 和 Q5 挂钩的升级条件：单个赞助商为整个奖金池提供资金，且活动以其名义举办，并且所有 Q5 确认事项均已获得书面确认。

  如果赞助商无法书面确认同时提供沙盒或离线备用方案，以及满足预期队伍数量的速率限制余量，就从这份菜单和上方的评估轴中删除此选项（Q5）。效率只是将其排在最后；依赖风险才会使其无法实施，而这是两项独立结论——升级绝不会凌驾于删除条件之上。

每个依赖赞助商的提示词都必须附带一条公开的备用方案说明。 在活动简章中说明：如果某支队伍并非因自身过错而无法使用赞助商集成方案，将如何处理：根据其设计和集成计划进行评审，而不是要求其提供可正常运行的调用。在活动开始前写清楚，这就是规则；故障发生时临时决定，那就成了特例，而所有已经完成的队伍都会这么说。

简述中的评审类别

列出类别。切勿为其设定权重、缩放分数或计算总分：这些都属于 samber/dev-event-organizer-skills@hackathon-judging 的职责，而在这里公布权重会形成一项承诺，该技能之后必须遵守或与之相悖。

同时列出淘汰标准。二元淘汰清单会直接取消提交资格，因此应放在类别名称旁边，而不是纳入加权评分标准。完整列出；其内容由 samber/dev-event-organizer-skills@hackathon-judging 决定。

一套值得借鉴的已发布类别如下，每个类别都附有书面说明，阐明评委应关注什么：

• 技术
• 设计
• 完成度
• 学习

这套类别自带默认权重。不要在简述中公布权重，而应将其作为输入交给评审技能。

公布不予评审的内容是常被忽视的另一半，每项排除都应说明原因：

• 代码质量
• 团队的演示表现
• 创意质量
• 项目解决实际问题的能力

团队会针对简述中列出的内容进行优化，因此，排除清单是阻止 40 支团队忙着润色幻灯片的最简单办法。借鉴这种结构，并为自己的活动决定具体内容：评审商业可行性的企业黑客松，排除的项目就会有所不同。

提交指南

根据上游选定的演示形式拟定核对清单，切勿套用模板。纯视频活动应以视频作为交付成果，并将其限制条件设为强制要求；博览会或舞台活动则应将视频设为可选项，并以现场演示为核心。弄反了，就会出现简述要求提交无人观看的视频，或漏掉评审所依赖的材料。

以下是值得采纳的 MLH 已发布规则，均明确为绝对要求，而非建议：

• 提交的代码应公开可用，最好放在 git 仓库中，并且活动结束后仍保持公开，才能继续具备获奖资格
• 分享前应移除 API 密钥
• 在 readme 中列出使用的库和框架
• 在提交材料中披露 AI 工具的使用情况

对于完全线上举办的活动，同一来源还要求提交时附上一段不超过两分钟的演示视频。视频必须在活动期间制作、开头点明黑客松名称，并在活动结束后保持公开。

**公开代码的要求并非可以不加思考地照搬。**它以默认开放的活动文化为前提，而企业或涉及客户数据的黑客松可能根本无法做到公开。复制这句话之前，先作出决定。

将提交截止时间设为指定时区中的具体时刻，并在有人逾期之前说明逾期提交会如何处理。references/submission-checklist-and-categories.md 包含各演示形式对应的完整核对清单、截止时间安排，以及针对每项材料的具体措辞。

失败模式

• 为简报中的类别设定权重。 列出类别是你的职责；设定权重则不是，而且在此公布的权重会约束尚未完成计算的同级技能。
• 选择交付格式。 视频还是现场演示已由格式技能确定。你只需翻译。再次选择会导致评审计划无法执行清单。
• 混淆挑战赛道与活动赛道。 这是由不同技能负责的不同决策。如果简报把活动赛道数量当作挑战赛道数量，就会凭空创造出无人赞助的类别。
• 开始制作后新增规则。 团队是按照已公布的文本制作的。活动进行到一半时新增规则，会重新评定已经完成的团队。
• 提示词没有设定最低可行提交标准。 如果团队只完成了自身计划的四分之一，就拿不出可演示的成果，而这正是简报决定的。
• 根据赞助商的营销文案编写赞助赛道。 营销文案描述的是优势，而非可实现的约束。应将其改写为问题，再请赞助商确认改写内容。
• 等团队组建后才裁定豁免比例。 “团队至少一半成员”这样的要求，必须在参与者选择队友前公布，否则这条规则会暗中排除已经组建的团队。
• 采用已公布的规则集，却不修改其中针对活动的字段。 规则集可能包含别人的黑客马拉松时长、资格范围和评审方式。
• 锁定狭窄的垂直主题，却不测试需求。 狭窄的主题可能无法吸引参赛者，直到活动前几周才不得不扩大范围。若没有事先约定的触发条件，扩大范围就会演变成与赞助商的临时争论，注册也会停滞。

衡量

以下每项门槛都是自行设定的，并非行业标准；介绍时请明确说明。不要照搬其他活动的取消资格率、无效提交率、规则争议率或完成率作为目标：这些数字在活动形式、规模和受众不同的情况下无法比较。

目前没有任何平台或学术调查发布过整个领域的汇总取消资格率或规则争议率。最接近的具名活动数据，是某位组织者在争议期间公开发布的事后统计：大约四分之一的提交只是一个想法，没有实际构建任何东西。这只是一场活动的自报数据，用于回应一场评审争议，不能将其作为数据套用到其他任何地方。

**通过门槛（结构性要求，仅此一项）：**发布前，以下七项都必须以书面形式明确，且不得留空。

1. 编程活动的开始和结束时间，精确到时钟时间
2. 资格说明
3. 团队人数规则
4. 每个赛道的问题陈述及其最低可行提交内容
5. 与所选演示形式相匹配的提交清单
6. 明确列出的评估类别
7. 提交截止时间及逾期政策

反复修改，直到计数达到七项。

**歧义门槛（发布前）：**针对每条规则，写明持相反意见的团队会如何解读。只要一条规则还存在第二种合理解读，就说明尚未写清楚。

下一届需记录的信号（自行设定）：

• 活动期间提出的所有澄清问题
• 被判定为无效的提交及其原因
• 没有收到任何提交的挑战赛道

每项信号都应指出下一份活动说明需要补上的句子，或不应再设置的赛道。

**活动结束后的成果作为影响力证据（自行设定）。**组织者报告称，他们的黑客松多次促成了公司的成立，并且至少有一个社群诞生于一场黑客松并从中发展壮大。报告没有提供数量。每届活动都记录：

• 在自行设定的时间间隔后仍活跃的项目
• 由黑客松团队或项目创立的公司
• 由参与者创立的社群、聚会或定期小组
• 后来以导师、赞助商或组织者身份回归的参与者

为每项成果记录其来源——由团队提供，或有公开页面佐证——并且绝不计算比率。将记录交给 samber/dev-event-organizer-skills@event-sponsor-fulfillment，用于赞助商报告；交给 samber/dev-event-organizer-skills@event-debrief，用于影响力记录；并在撰写下一份活动说明的背景段落时参考记录。提交时询问参与者是否同意日后就项目的后续发展联系他们；否则后续跟进将没有获得同意的依据。

调用示例

• “为我们的 36 小时 AI 黑客松撰写挑战说明——包含两个赞助商赛道和一个初学者赛道。”
• “我们的赞助商希望大家使用他们的 API。如何措辞，才能避免 API 故障时影响活动？”
• “我们要发布哪些规则和资格说明？哪些内容不应由我们自行撰写？”
• “将我们选定的展位评审方式整理成提交清单和截止时间。”
• “我们有主题，但没有问题陈述。问题陈述需要具体到什么程度，才能适用于一个周末？”

预期输出：一份可供发布的活动说明，包含

1. 规则和资格说明，并列出已编辑的字段
2. 挑战赛道结构及跨赛道提交规则
3. 每个赛道各一份问题陈述，注明具体程度层级，并列出最低可行提交内容
4. 赞助商相关说明及备用句子
5. 明确列出的评估类别和排除项清单
6. 根据演示形式制定的提交清单，以及截止时间和逾期政策

发布前，逐节呈现以供确认。

参考资料

• 规则和资格说明源文本
• 问题陈述范式
• 提交清单和评估类别