hackathon-team-formation

黑客松团队组建

由你决定黑客松参与者最终如何组队：活动简章公布的团队规模规则、当天采用的机制、未能成功组队的人如何安排、成员何时不再变动，以及这四者如何围绕开场安排。

这是参与者之间的问题，不是参与者与专家之间的问题。这两者经常被混淆。

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

你负责：

• 团队规模人数，以及个人参赛的安排
• 匹配机制
• 未组队参与者的处理流程
• 活动中途变更政策
• 任何按赛道划分的组队规则

以下四项由相关技能负责或交由相关技能处理——请移交，而不是重新决定：

• 公布的规则文本由 samber/dev-event-organizer-skills@hackathon-brief-design 负责。该技能的访谈会明确询问本技能的团队规模规则，且发布前检查会将此规则计为七项必备内容之一。你决定人数和规则意图；该技能负责撰写并发布。
• 为遇到困难的团队匹配专家由 samber/dev-event-organizer-skills@hackathon-mentoring 负责。请按以下方式划定边界：找不到团队的参与者是本技能要处理的问题；找不到技术帮助的团队则由该技能处理。不要在这里设立导师请求渠道。
• 活动流程中的时段安排——即路演环节或交流会在当天的具体位置，以及需要取代哪些安排——由 samber/dev-event-organizer-skills@event-run-of-show 负责。你提供时长和顺序限制；该技能会据此安排。
• 奖项资格及谁可以获得奖金由 samber/dev-event-organizer-skills@hackathon-cash-prize 负责。团队规模上限会影响非现金奖品的分配；说明团队成员名单如何确定，不要说明奖品价值。

以下各项菜单及其档位和排序维度，都是本技能自行设计的：依据机制进行推理，而非根据活动数据进行衡量。每项排序都是默认建议，不是硬性规定。访谈结束后，请结合你已了解的本届活动情况，重新评估每项排序：

• 去年的报名数据
• 以成队形式参加的往届参与者
• 曾组织过组队交流活动的组织团队
• 只有一个房间、没有其他空间的场地

访谈

每次只问一个问题，尽可能采用选择题。问题 2 至 9 分别对应一个阶梯、一项删除条件或一项晋级条件；未回答这些问题，就不能选择任何默认方案。

1. 活动是以组织者提供的题目为主题、开放式（参与者自带题目），还是两者兼有？
2. 编程时段有多长？开幕仪式和编程开始安排在同一个时段，还是不同日期？
3. 目前已报名的人中，有多少人以现有团队的形式报名，有多少人单独报名？估算也算有效答案；“我们不收集这项信息”则是最有用的答案。
4. 参加者中有多少人是第一次参加黑客松？报名时是否会询问技能、角色或参赛者想做什么？
5. 是否需要设置人口特征或技能水平类别，例如初学者类别、首次参加者名额、仅限学生的类别？其中是否有任何条件取决于团队中符合条件的人数比例，而非个人情况？
6. 活动会使用多少个房间？是否有第二个空间可用于主持引导的活动？
7. 奖项是否根据提交的项目评选？未成年人是否可以参加？
8. 这是一次性活动，还是需要确保活动机制明年仍适用的定期活动？规则最晚必须在什么时候发布？
9. 工作量上限是多少：活动前组织者能投入多少小时？编程时段内实际有多少名明确安排了任务的人员可以工作，而非只是在日程表上列了名？

问题 8 和 9 各自会调整一个明确的阶梯。重新排序时，请说明是哪一个。

• **问题 8，临近发布：**将已采用的规模规则排在任何草案之前，并降低活动前匹配的优先级，因为它的全部成本都在于阅读尚未收到的报名信息。
• **问题 8，定期举办：**提高一次编写、反复复用的阶梯的优先级，例如带有例外条款的规模规则和提案轮次脚本，因为一次性活动必须全额承担这些成本，而定期活动可以摊销。
• **问题 9，按组织者小时数计算的工作量上限：**不影响安全兜底。
• **问题 9，按编程时段内可用人员数计算的工作量上限：**直接取消现场巡查和升级处理，因为两者都需要有人投入精力，除此之外别无他物。请如实说明，而不要假装存在轮值安排。

工作流

1. 进行访谈。如果有上一届的报名数据，请先阅读；Q3 和 Q4 的答案以该数据为准。
2. 先确定团队人数规则，再选组队机制。 机制必须能组出符合规则的团队；如果上限是 4 人，混组活动却组出 6 人团队，只会浪费场地。规则一经确定，就立即交给 samber/dev-event-organizer-skills@hackathon-brief-design。
3. 选择配对机制，并说明其时长和顺序限制。加载 references/matchmaking-mechanics-and-run-sheets.md。
4. 提前确定尚未组队参与者的处理方案，不要等到活动当天才决定。 加载 references/unteamed-participant-protocol.md。
5. 制定变更政策和截止时间，并对照第 4 步检查——如果冻结时间早于安全措施的执行时间，安全措施就会失效。
6. 如果机制或安全措施依赖项目待办清单，就先准备好清单，并根据 Q1 确定其规模。加载 references/team-size-and-composition-rules.md。
7. 将时段、时长和安排位置交给 samber/dev-event-organizer-skills@event-run-of-show，并将规则文本交给简报。
8. 在报名截止前发布规则。如果人们已经约好一起参加黑客松，之后才新增团队人数规则，就会使已经组好的团队失去资格。

按章节逐项提交决策供确认——人数规则、机制、安全措施、变更政策——不要一次性打包提交。规则写入简报前，必须获得明确批准；发布之后就无法撤回。

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

• 人数规则，以及是否允许个人单独报名
• 采用的机制及其实际耗时
• 扫查时仍未组队的人数
• 这些人最后各自的去向

最后一项是唯一能说明这些措施是否奏效的数据，不能用其他活动的数据代替。

团队人数政策

分为四档：未说明规则、仅规定人数上限、规定包含单人参赛的范围，以及范围规则加上按赛道设定的组成规则。

• 价值（提交时能避免的争议、单人参赛者能否在到场前知道自己可以报名，以及例外条款是否确实可执行）：范围规则加组成规则 > 包含单人的规定范围 > 仅规定人数上限 > 未说明规则
• 工作量（确定人数、拟定规则文本并逐一对照每条赛道检查）：范围规则加组成规则 > 包含单人的规定范围 == 仅规定人数上限 > 未说明规则
• 合规成本（各档规则引发的审核，以及由此牺牲的灵活性）：范围规则加组成规则 > 未说明规则 > 仅规定人数上限 > 包含单人的规定范围
• 效率：包含单人的规定范围 > 仅规定人数上限 > 未说明规则 > 范围规则加组成规则

支配关系结构：6 组比较，恰好有一种严格支配关系。 与单独规定上限相比，包含单人的规定范围价值更高、工作量相同、合规成本更低，因此它占优。效率排序也与此一致，将规定范围排在首位。

其余三档互不支配：

• 组成规则（各成本维度都最高）
• 未说明规则（不支配任何选项）
• 人数上限（不支配任何选项）

如果这里的排序有误，就无法通过检查，因此这轮分析是有意义的。

工作量上的 == 是经过论证的，并非敷衍。 上限和范围本质上是同一句话：确定最大人数时，就必须考虑一个人是否也算团队，因此上限规则并没有减少决策，只是没有把问题写明。两者都不到一小时；看似上限规则成本更低，只是因为它把问题推迟了，直到有人独自报名才显现出来。

• 明确规定范围，包括单人参赛 - 默认选项，也是本技能给出的最强单一建议。
  • 复制粘贴已发布的组织方指南中的文字：“团队可以由 1-4 人组成”。
  • 同一指南给出的限额理由是：“我们发现，最多 4 人的团队最容易取得成功。”这只是某个组织方网络的从业者观察，没有引用任何研究作为依据。
  • 借鉴这种形式；具体人数由你为自己的活动决定。
• 仅规定上限 - 用相同的时间也能带来实际价值，但这会让来源明确提出的问题“黑客能否单人参赛？”一直没有答案，直到有人在报名台询问。
• 未明确规定 - 只要简报发布，就从此菜单和上方的轴线中删除此选项（Q8）。samber/dev-event-organizer-skills@hackathon-brief-design 自身的发布前门槛将团队规模规则列为必须填写、不得留空的七项内容之一；没有这项规则就只有六项。它在合规性方面也排第二，因为发布前无需审核，却将所有裁定推迟到最难撤回的时刻——公开宣布奖项时，有一支团队正站在那里。
• 范围加团队构成规则 - 选择最少的选项：价值最高、工作量最大、合规成本最高。
  • 适用条件，以 Q5 和 Q7 为准：某赛道的参赛资格取决于团队中符合条件的成员占比，而不是每位成员个人是否符合条件。
  • 已发布的示例：“新手赛道要求至少半数团队成员首次参加黑客马拉松”。
  • 同一来源的程序性规则：“务必在活动前的规则中说明团队中有多少成员必须符合该类别。”
  • 将比例作为需要决定的内容，“一半”则视为某场活动采用的具体数值。

为什么团队构成规则在合规轴上排名最高。 以“首次参加黑客马拉松”为条件的比例是技能水平的替代指标，审核成本低。以年龄、学生身份、性别或残障为条件的比例则涉及受保护特征的特殊规定：发布前需要由负责该组织相关风险的人审核，而且活动开始后无法撤销，否则必须重新评定整个赛道。撰写规则前，先判断你要采用哪一种；如果是第二种，应转交相关负责人处理，而不是自己措辞。

组队机制

共五个等级：完全不设正式组队机制、项目展示并加入的环节、长期开放的项目公告板、有人引导的交流活动，以及根据报名数据进行的活动前匹配。这里有两个价值轴，因为它们的排序确实不同。

• 价值，覆盖率（结束该机制时已加入自己所选团队的参与者占比）：活动前匹配 > 有人引导的交流活动 > 项目展示并加入的环节 > 长期开放的项目公告板 > 不设正式组队机制
• 价值，项目匹配度（组建的团队既有可实现的构建目标，也有实现该目标所需的技能）：项目展示并加入的环节 > 活动前匹配 > 长期开放的项目公告板 > 有人引导的交流活动 > 不设正式组队机制
• 工作量（组织方的筹备、活动流程所需时间，以及组队时段内的协调工作）：活动前匹配 > 有人引导的交流活动 > 长期开放的项目公告板 > 项目展示并加入的环节 > 不设正式组队机制
• 效率：项目展示并加入的环节 > 长期开放的项目公告板 > 不设正式组队机制 > 有人引导的交流活动 > 活动前匹配

支配结构：10 对选项中，恰好只有一对构成严格支配关系。 项目展示并加入的环节在覆盖率、项目匹配度和工作量上都优于长期开放的项目公告板，因此形成支配关系。公告板只能触达路过的人，项目介绍旁边却没有人可以回答问题，而且仍需提供展示空间并安排人员全天维护。效率轴通过将项目展示并加入的环节排在公告板之前体现了这一点。

其他三个等级均不支配其他选项：

• 活动前匹配（工作量轴上排名最高）
• 有人引导的交流活动（项目匹配度不如项目展示并加入的环节和公告板）
• 不设正式组队机制（两个价值轴上都排名最低） 其余九种组合各自在不同维度之间取舍。检查不会验证这些组合，因此它们的排序取决于以下论据。

为什么两个价值维度会分化。 提案轮会围绕某人已经阐述并承诺要实现的项目组建团队。交流会则先形成社交小组，再由他们构思项目，这是最慢的首次提交路径。覆盖面和匹配度并非同一指标，而最大化其中一项的机制可能会牺牲另一项。

• 提案并加入轮——默认选项，也是唯一有已发布流程表支撑的机制。
  • “活动开始时，编程从项目介绍开始。携带项目参加活动的参与者可以在活动一开始简要介绍（最多 1 分钟）自己正在做什么，让其他参与者加入该项目。”
  • 同一来源还指出了会破坏这一机制的反模式：“除非确实没有足够的项目可供选择，否则不要允许任何人提议一个自己不会在活动中参与的想法。”
  • 这种方式组建的团队被描述为“约 2-5 人”，这是该作者在公民科技活动中观察到的范围，并非需要强制执行的目标；它与上文的 1-4 人上限并列，而不包含在其中。
  • 两种辅助方法可以让这轮流程适用于更大的场地。它们都是本技能的建议，并非已发布的实践：
    • 每位提案者使用一个标记，能在场地内远处辨认，并与其所在位置对应，这样人群无需排队也能找到项目
    • 签到时发放按技能标记的腕带，让场内人员按专业领域自行平衡
• 持续开放的项目看板——主导性检查排除的那一级，仍保留在页面上，因为组织者在提案轮拖延、被砍掉时就会想到它。把它写出来，才能注意到这种情况已经发生。
• 完全不进行正式配对——确实存在的一种选择；如果活动报名者都是已组建的团队，这也是正确选择：它零成本就能达到与其他机制相同的覆盖面，因为所有人本来就有团队。**一旦 Q3 显示有人报名时没有团队，就从这个菜单和上方的维度线中删除这一选项。**从那一刻起，保持沉默就不再是轻量化的选择，而是决定把这些人留给现场自行解决。
• 引导式交流会——覆盖面排名第二、投入程度排名第二、项目匹配度排名第四，是一种资源不足的选择。推广条件由 Q4 和 Q6 决定：大多数参与者是第一次参加编程马拉松，携带项目的人又太少，无法通过提案轮吸纳场内人员，并且有第二个空间可供举办交流会。绝不要只满足第一个条件就推广它——在编程空间里举办交流会会挤占编程活动。
• 根据报名数据进行活动前配对——另一种资源不足的选择：覆盖面和投入程度均排名第一，也是唯一能在所有人到场前发挥作用的选择。
  • 同一指南将其作为一种实践而非机制发布：其报名表会询问“他们是哪类黑客？”，示例包括“开发者。设计师。数据科学家。领域专家。政府工作人员。沟通者。项目经理。倡导者。”
  • 指南还要求组织者“根据你掌握的任何信息，切实设想每位已报名参与者会如何在活动中保持忙碌。”
  • 推广条件由 Q3 和 Q4 决定：报名者中独自报名者占多数，并且报名表已经收集角色或兴趣字段。
  • 没有该字段，这一级并非成本高，而是根本不可能：报名开放后再添加字段，也无法触达已经报名的人。

以上每一级都是一种机制，而不是一种产品；电子表格、墙面和聊天频道都能实现其中多种机制，点名某个平台只会让这项技能显得过时，却无法解决任何问题。

没有团队的参与者

四级：仅将独自报名视为常态；再加上预先准备好的项目储备；再加上由指定人员进行现场排查；最后加上设有时限的升级处理。

• 价值（想加入团队却未能如愿的参与者在离开前得到联系）：限时升级 > 现场巡查 > 预先准备的待办事项 > 仅规范化个人参与
• 努力（活动前的准备，以及时段内某位具名人员投入的注意力）：限时升级 > 预先准备的待办事项 > 现场巡查 > 仅规范化个人参与
• 合规成本，即每个层级会触发的审查，以及为此付出的可逆性代价：限时升级 > 现场巡查 > 预先准备的待办事项 == 仅规范化个人参与
• 效率：现场巡查 > 预先准备的待办事项 > 仅规范化个人参与 > 限时升级

支配结构：6 组配对，没有严格支配关系。 两种机制阻止了所有 6 组配对：

• **一般情况（5 组）：**配对中价值更高的层级需要严格更多的努力、更多审查，或两者兼具。
• **险些成立的一组（1 组）：**现场巡查确实在价值和努力两方面都胜过待办事项，因为已经在会场走动的某个人可以顺便在原本就要进行的一轮中加问一个问题，而准备待办事项则需要在活动前撰写。只有合规这一项阻止了它形成支配关系：接触并识别一位落单的参与者，比撰写项目创意需要更多审查。

此处的检查没有发现任何情况，不过有一组配对只差一个维度就会形成关系。因此，效率方面的结论依赖于下文的论证，而非任何验证。

为什么合规在这里是一个真实维度，而非装饰。 现场巡查会基于对某人社交处境的观察，将具名人员单独挑出；升级则会记录情况并将其转交处理。有未成年人参与时（Q7），这属于安全保护互动，而非接待工作，因此需要采用 samber/dev-event-organizer-skills@event-accessibility-inclusion 对便利措施数据所规定的同等原则：谁可以持有这些数据、持有多久，以及哪些内容绝不能记录下来。较低的两个层级完全不涉及任何人的数据，这正是论证 == 的依据。

• 由指定人员负责巡查 — 这是默认选项，依据是一份已发布的指南：“安排一人负责活动室……看看是否有人需要帮助，或者找不到可做的事情。”巡查的频率、负责人以及巡查人员可以提供什么帮助，都由你决定。单独选择这一项前，请注意它的依赖关系：巡查的价值取决于能把参与者引向何处，要么是备有任务的待办列表，要么是明确人手不足的团队。
• 预先准备好的项目待办列表 — 这项做法也有公开资料支持，而且能减少参与者完全找不到团队的情况：“准备一些新项目构想，以便那些无法加入现有项目的参与者能轻松上手。如果你预计不会有很多参与者自带项目，提前准备项目构想尤其重要！”同一资料也给出了判断项目是否真的适合加入、而不只是被列出来的标准：“为技能和水平各异的新手准备好可立即开始的任务”，并且构建环境“可在不到 20 分钟内启动”。
• 只将独自参与视为正常结果 — 这项做法有公开资料支持，也确实有价值。“一个人的项目，也就是有人独自工作，也是可以的！”这是最直白的表述：独自工作是合理结果，而非失败。无论你还会采取什么做法，都应在开场时明确说出来。
  • 一旦发布了高于“没有正式配对机制”的任何配对机制，就从这个选项菜单和上方的坐标轴说明中删除这一项，因为它不能再作为完整的解决方案。
  • 宣布一项机制会让人期待自己能找到团队。如果机制没能帮到某人，却回答“独自工作也没问题”，那是在回答对方没有提出的问题。
• 限时升级处理 — 这是证据最少的选项，位于三个坐标轴的顶端；它也是本技能自行设计的方案，而非已记录的实践：目前没有任何已发布的资料描述如何升级处理未能加入团队的参与者。该方案应指定负责人、设定一个时点，让继续寻找不再是参与者自己的问题，并明确说明负责人应提出什么帮助。晋级条件与 Q4 和 Q7 相关：参与者大多是第一次参加黑客马拉松，或者有未成年人参与，而独自待上一整天显然不能合理地视为个人偏好。

不要编造时长。 目前没有任何已发布的资料给出未能加入团队的参与者应在多少分钟后升级处理；在这里给出一个听起来合理的数字，只是把捏造伪装成基准。

应改用活动流程中已有的时间节点来设定时限，例如：

• 路演环节结束时
• 第一轮供餐时
• 第一场工作坊休息时

记录活动实际花费的时间，让下一届活动能有一个真实数字，而目前业界还没有这样的数据。协议、巡查人员的话术，以及升级处理可以和不可以提供哪些帮助，详见 references/unteamed-participant-protocol.md。

活动期间的团队变更

分为四档：未说明政策、在公布的时间点冻结成员名单、开放至公布的截止时间后冻结，以及全程开放并设有归属规则。对于团队组建后发生变更的情况，没有任何标准规定。以下每一档、每条坐标轴上的排序和两种支配关系，都是本技能自行构建的，是基于机制推演得出的，并非在任何活动中观察所得。

• 价值（团队增员或减员后仍可提交作品，且评审时作者身份没有争议）：开放至截止时间 > 全程开放并设有归属规则 > 在公布的时间点冻结成员名单 > 未说明政策
• 投入（公布规则，以及提交时核对成员名单）：全程开放并设有归属规则 > 开放至截止时间 > 在公布的时间点冻结成员名单 == 未说明政策
• 合规成本，按每档规则引发的审查以及为此付出的可逆性衡量：未说明政策 > 全程开放并设有归属规则 > 开放至截止时间 > 在公布的时间点冻结成员名单
• 效率：在公布的时间点冻结成员名单 > 开放至截止时间 > 全程开放并设有归属规则 > 未说明政策

支配结构：6 组，两种严格支配关系。 其中两组有参考意义，这已经是本技能任何一个选项菜单所能达到的上限：

• 在公布的时间点冻结成员名单，相较于未说明政策，在价值上更优、投入相同、合规成本更低，因此占优。
• 开放至截止时间，相较于全程开放，在三个维度上都更优，因此也占优。

效率排序同时符合这两点。截止时间方案和全程开放方案都不支配冻结方案，因为它们带来的价值提升都需要付出更多投入；未说明政策方案则不支配任何方案。

投入维度上的 == 是有理由的。 这两档方案大致都只需一句话说明，提交时也几乎不增加工作量。区别不在于工作量，而在于时机：冻结方案把这一个小时花在活动开始前；未说明政策方案则把同样的一个小时花在提交时，在截止时间压力下，还没有规则可供执行。因此，这两档方案的差异体现在合规维度，而不是投入维度。

• 在公布的时间点冻结成员名单——效率最高，但也有意不作为推荐默认选项。
  • 晋升条件，与 Q3 和你在第 4 步做出的决定相关：只要你采用任何高于“仅规范个人参赛”的兜底方案，就改用截止时间方案。
  • 如果在提案轮次时就冻结名单，那么扫描就无法安排任何人加入，因为有空位的团队已经不能接收他们。
  • 这是本技能中唯一一处明知比值排序不适用、仍予以推翻的情况；做出这一决定的是本技能自己在前两个菜单中设定的内容，而非个人偏好。
• 开放至公布的截止时间，之后冻结——因此推荐采用此方案。它能让成员名单在兜底机制实际运行的时段内保持可调整，并在评审开始前确定下来，因此交给 samber/dev-event-organizer-skills@hackathon-judging 和 samber/dev-event-organizer-skills@hackathon-cash-prize 的名单，就是最终评分和发放奖金所依据的名单。
• 全程开放并设有归属规则——这是缺少支持的选项，也是检查规则排除的方案。晋升条件，与 Q2 相关：活动持续数天或一周的情况；如果团队在第 3 天失去一名成员，否则就完全无法提交作品，此时冻结名单会是更严厉的规定。
• 未说明政策——一旦根据作品发放奖金，就应从此菜单和上方的坐标轴排序中删除此选项（Q7）。没有规则时，团队成员身份问题会在金钱价值最高、且最难撤销的时刻才得到解决。

成员构成规则与变更政策冲突时。 如果第一个菜单中公布了按赛道设定的成员比例要求，就应说明有人离队后，不再符合该要求的团队会如何处理。

• 提前决定，代价是多加一项条款。
• 评审时再决定，代价是失去一个赛道。

开场环节的时间安排

已公布三项时间安排：

• 安排位置值得借鉴。 项目介绍环节紧接欢迎环节进行，而不是稍后单独安排时段。同一指南中的活动当天议程先安排欢迎环节——组织者、赞助商、活动历史、行为准则、后勤安排——然后是：“带了项目来做的人，接下来应该向大家介绍自己的项目。”
• 确保介绍环节不超时的机制。“项目负责人通常会尽可能长时间地发言，因此你可能需要在一分钟后打断他们。”对介绍者而言，这一环节“不是为了招募，而是为了炫耀自己这一天会过得多精彩”。
• 容易被误读的规模指标。“在小型活动中（约 30 人以内），可以让所有参与者都做自我介绍。”这个门槛适用于_所有人都做自我介绍_，而不是项目介绍环节；无论如何都会进行项目介绍。

除此之外，所有时间安排都是本技能自行制定的。公开资料没有说明：

• 开始编写代码之前多久应公布规模规则
• 预先匹配应在报名时进行，还是提前一周进行
• 为期两天的活动在第二天早上如何处理迟到者

应根据先后顺序的约束推导出这些安排：

• 随活动简报一同公布规模规则
• 在编写第一行代码之前运行该机制
• 在评审开始之前设定更换项目的截止时间
• 在该机制运行后、截止时间之前留出缓冲

将时长交给 samber/dev-event-organizer-skills@event-run-of-show，让它来安排。

按角色覆盖情况而非人数

当团队询问自己还缺什么时，应从职能而非人数角度作答。一份已发布的角色模型来自硬件黑客马拉松指南，其中列出了多学科“强”团队的四个核心角色：

• 程序员
• 制造者
• 设计师
• 愿景制定者，明确指项目管理

另有一项职责不与人数挂钩：“团队中还应有人专注于质量保证和调试。”各角色的完整范围见规模参考。

纯软件活动没有制造者，而这里列出的角色是硬件项目的物理依赖。可沿用结构，但不要照搬名单：列出团队需要覆盖的三到四项职能，并将它们与人数区分开来，这样四人上限和五项职能清单才能兼容；再让该机制揭示由谁承担哪些职能。这样的延伸是本技能自行推导的，并非已发布的软件活动角色模型。

同一资料中最常被忽略的是招募理由：它要求组织者邀请“可能不会自我认定为‘黑客’”的人，因为如果申请者全是程序员，那么无论选择何种机制，在匹配时都不可能实现技能平衡。相应的职能划分由你来制定；指南提供的是框架，而非清单。

另有一个已发布的数据涉及项目供给。在主题黑客马拉松中：“确保每四名非专家参与者至少有一位领域专家和一个可行项目。”

每次使用时都要保留这项数据的所有四项限制：

• 仅适用于主题活动，项目范围仅限于一个问题领域
• 统计的是非专家参与者，不是团队，也不是报名人数
• 专家是参与某个项目的领域专家，不是流动导师
• 这是项目供给目标，目的是避免现场分出第三类“难以找到相关项目可做的参与者”，而不是为任何工作配置人员

samber/dev-event-organizer-skills@hackathon-mentoring 说明了更完整的适用范围，并明确提醒不得将其换算成每位参与者对应的导师数量。在其他地方再次使用这个数字之前，请先阅读该资料。

失败模式

• 在安全网启动前冻结团队成员名单。 这正是本技能要防止的顺序错误：协调员发现有人尚未组队，一支人手不足的团队想招收这名参与者，而已公布的规则却禁止这样做。修正方法：将变更截止时间设在排查之后，而不是项目介绍环节之后。
• 对未被选中的参与者说“单人参赛也没问题”。 在开场时这么说是恰当的，但对唯一一个被这种方式落下的人来说却不合适。修正方法：优先安排其加入人手不足的团队或已有储备项目，并将单人参赛作为一种选择，而不是最终安排。
• 交流活动结束后没有任何储备项目可接续。 社交小组组建后，才发现没有项目，也没有负责人，于是到午餐时便散了。修正方法：绝不在没有项目待办清单的情况下举办以人为先的活动。
• 介绍项目的人不会亲自实现项目。 这会占用本轮的时间，却让加入者加入一个没有作者的项目。修正方法：在本轮开始前说明规则，并执行截止时间。
• 团队人数上限与奖品规则相矛盾。 按人数发放的非现金奖品，在四人上限下与随意瓜分的现金奖是不同的承诺。修正方法：在公布任一规则前，对照 samber/dev-event-organizer-skills@hackathon-cash-prize 检查团队名单规则。
• 团队组建后才判定成员构成比例。 提交时才发现的新人比例配额，会排除已经组建、且此前无从知晓要求的团队。修正方法：随活动说明一同公布比例。
• 将配对形式视为人人都能参与。 面向全场的项目介绍环节和有主持的交流活动，都默认参与者能自在地在嘈杂环境中与陌生人交谈；这是一个独立于“尚未组队者的后续安排”的无障碍问题。修正方法：为同一机制提供非口头参与途径，并将设计问题提交至 samber/dev-event-organizer-skills@event-accessibility-inclusion。
• 收集无人使用的报名信息。 除非有指定人员在活动当天之前查看，否则表单上的技能字段毫无用处。修正方法：只有在确实选择了活动前配对这一环节时，才添加该字段。

衡量

以下每项门槛都由组织方自行设定，并非行业标准；介绍时要明确说明。不同活动的组队率、单人报名占比、组队耗时和未组队人数并不可比，因此不要照搬其他活动的数据作为目标。

通过门槛（结构性要求，仅此一项）： 在公布活动说明前，以下五项都必须有书面记录，且没有空缺：

• 团队人数规则及单人参赛的安排
• 如有赛道需要，注明成员构成比例
• 指定的机制及其时长
• 指定的安全网负责人
• 以钟表时间表示的变更截止时间

持续迭代，直到计数达到五项。

覆盖率门槛（活动当天）： 机制结束后，尚未加入团队的参与者人数必须是一个明确数字，而不是凭印象估计。如果没人能说出这个数字，排查就没有目标，升级处理也没有触发条件。

记录以下信号，供下一届活动参考（自行设定）：

• 独自报名和以团队形式报名的人数
• 排查开始时仍未组队的人数
• 他们各自之后如何安排
• 项目介绍环节实际耗时与预留时间的差距
• 截止时间过后仍有成员变动的团队数

本领域不会公布这些数据，因此你能进行的唯一比较，就是与你自己的第二届活动进行比较。

执行示例

• “我们的 200 人黑客松应允许多大的团队？是否允许个人参赛？”
• “活动当天如何组建团队？我们的报名者大多是个人。”
• “有人没有被任何团队选中，也不想单独参赛。我们实际该怎么做？”
• “团队可以在周六下午增加成员吗？截止时间该怎么定？”
• “我们的新手赛道要求团队中至少一半成员是首次参赛者——该如何表述并落实？”

预期输出：一套组队决策，包括：

1. 团队规模规则及其对个人参赛的规定和任何成员构成比例，提交给活动简报
2. 选定的机制，注明所属等级、持续时间及顺序限制，提交给流程表
3. 未组队参与者的处理方案，注明负责人及以当天活动时间为基准的限时安排
4. 成员变更政策，注明具体的截止时刻
5. 需要记录的信号

按章节逐项呈现，以便在内容进入活动简报前进行验证。

参考资料

• references/team-size-and-composition-rules.md - 可采用的团队规模规则措辞、成员构成规则机制及受保护特征的区分、明确列出的角色覆盖范围、项目待办事项规模，以及各机制所需的报名字段。
• references/matchmaking-mechanics-and-run-sheets.md - 五种机制的流程表、推介轮次脚本和截止时间执行办法、看板和交流活动设计、根据报名数据进行活动前匹配，以及一组正面和负面的示例。
• references/unteamed-participant-protocol.md - 详述人员扫尾和升级处理流程及各自可提供的帮助、无障碍和安全保障方面的补充安排，以及绝不能记录的内容。

另请参阅同一集合中的：

• samber/dev-event-organizer-skills@hackathon-brief-design - 将团队规模规则和任何成员构成比例写入活动简报；其访谈会明确指定本技能负责确定人数。
• samber/dev-event-organizer-skills@hackathon-mentoring - 根据专业知识为团队匹配导师；本技能负责参与者之间的匹配，而该技能负责全面确定主题活动中的专家比例范围。
• samber/dev-event-organizer-skills@event-run-of-show - 根据本技能提供的时长和顺序限制，在当天流程中安排相关机制。
• samber/dev-event-organizer-skills@hackathon-judging - 接收冻结后的成员名单；评审窗口开启后若成员发生变更，已评分结果将重新开启。
• samber/dev-event-organizer-skills@hackathon-cash-prize - 决定每位成员的奖品价值，因此必须在选择非现金奖品前确定团队人数上限。
• samber/dev-event-organizer-skills@event-volunteers - 提供并安排指定人员，供人员扫尾和升级处理流程依赖。