hackathon-mentoring

黑客马拉松导师指导

你要为某一届黑客马拉松设计导师计划：现场需要多少支持，由谁提供，遇到困难的团队如何获得帮助，导师开始工作前要了解什么，以及导师支持如何在开发时段轮换。

在设计任何内容之前，先阅读已发布的活动简章。简章中的两项内容会影响以下所有选项：

• 挑战赛道，它们明确了现场必须具备哪些专业知识。
• 赞助商整合深度，它衡量活动已经作出了多大程度的承诺。

samber/dev-event-organizer-skills@hackathon-brief-design 从自身职责出发划定了边界：它将导师支持覆盖归为本技能的职责，包括赞助商 API 方面的指导；而它自身只说明活动会有导师。

以下所有排序都只是默认建议，并非硬性规则。面谈后，请根据活动现有的资源重新排列各个选项：回归的导师团队、合同约定必须参与的赞助商员工、只有一间房的开发场地，以及都熟悉赞助商 API 的组织团队。

导师不是志愿者，也不是评委

导师应作为独立角色对待，绝不能归为志愿者的一个子类。 MLH 的文档明确说明了这种平等地位：其《行为准则》将“赞助商、评委、导师、志愿者、组织者、MLH 员工，以及参与活动的其他任何人”列为并列类别；其组织者指南也为导师设置了独立的招募渠道、聊天频道和角色标识，而不是将他们纳入一般志愿者报名流程。

这是对身份的界定，而非对机制的界定。沿用人员配置的计算方式，不必重新设计。 samber/dev-event-organizer-skills@event-volunteers 中的支持覆盖规则——“在确认有人接替之前，不要离开岗位”——同样适用于导师轮班。

samber/dev-event-organizer-skills@event-volunteers 负责：

• 根据岗位和时长自下而上地确定人员名单规模。
• 预留抵达缓冲时间。
• 确认报名。
• 处理缺席和替补的流程。
• 与轮班挂钩的表彰。

本技能负责该技能未涵盖的内容：

• 专业知识标签。
• 按主题划分支持覆盖深度。
• 求助机制。
• 帮助与代做之间的界限说明。

评委不是导师，而且 samber/dev-event-organizer-skills@hackathon-judging 已经从自身职责出发，用明确的措辞说明了这一点：导师“在开发时段帮助团队构建项目”，而“评委在之后评估完成的项目”。这两项技能中的“说明”指的是两份不同的文档：前者是评审团说明，后者是导师说明。凡是读者可能混淆的地方，都应写成导师说明。

导师行为政策及其执行不属于你的职责。 与其他所有列出的角色一样，导师也纳入 samber/dev-event-organizer-skills@event-code-of-conduct 现有的流程中；不要另起炉灶制定一套。你的职责范围更窄，只涉及导师说明中的帮助与代做界限，以及了解技术栈的人与已连续熬夜二十小时的人之间的权力差异。

从一方视角说明导师与评委的利益冲突

导师实质性地帮助过某个团队，之后又评审该团队，这种利益冲突已由 samber/dev-event-organizer-skills@hackathon-judging 从其自身角度负责处理。该技能指出：“帮助团队完成项目的导师无法中立地给该团队打分”，并将此情况纳入其现有的回避规则：“对该人指导过的每个团队应用回避规则”。该技能负责这条规则及回避流程。

本技能只负责输入数据：一份导师与团队的联系记录，用于记录哪位导师曾与哪个团队投入实质性时间；在组建评委池时，这份记录应可供查阅。

• 只要已确认的导师同时在评委名单中，就保留这份记录（Q5）。
• 以声明方式表述规则：实质性帮助过某个团队的导师，应回避评审该团队。
• 将流程交由该技能负责，而不要在此处另行推导一套相互竞争的规则。

那一侧的交接仍缺少一半：回避规则要求找出“该人指导过的每个团队”，却没有说明这份名单从何而来。这份记录就是名单来源；该技能下次修订时应将其明确列出。

应拒绝提供的数量，以及唯一公开发布的比例

切勿编造以下数量：

• 导师与参与者的比例。
• 将导师可用性与项目完成率或满意度关联起来的证据。
• 解除阻塞的时延目标。
• 导师与轮班人员的配置公式。

这些数字看似可以放心编造，恰恰是因为活动当天没有任何东西能与之相矛盾。应根据实际机制进行论证：受阻团队若找不到求助渠道，就会放弃项目开发。

有一个已公开发布的比例。Joshua Tauberer 的 hackathon.guide 指出（在 主题式黑客松 一节中）：“确保大约每四名非专家参与者至少有一位主题领域专家和一个可行项目”。该比例的目的是确保项目供应，而非配置导师人手。

该比例的适用范围很窄：

• 仅适用于主题式黑客松（即只有一个问题领域）。
• 统计的是非专家参与者，而非团队。
• 描述的是项目内部的领域专家，而非流动导师。

应将其作为证据，说明稀缺的是专业知识，而非人数。切勿将其换算成导师与参与者的比例公式。

访谈

每次只问一个问题，尽可能采用选择题。问题 1–4 和 6–9 都不能省略，因为菜单会根据这些答案进行调整：没有这些答案，就无法替用户选定默认方案。

1. 活动是线下、线上还是混合形式？黑客活动空间占用几个房间？活动时段是否持续至深夜？
2. 已发布的活动说明中列出了哪些挑战赛道？赞助商的参与深度属于哪种——仅列出资助方、提供可选的加分挑战、某个赛道必须参与，还是完全以赞助商的技术为基础？
3. 活动是否有主题和组织者提供的问题，还是开放式活动，由参与者自带问题？
4. 哪些人已承诺担任导师：社区成员和校友、赞助商的技术人员，还是两者都有？是否已有任何赞助商人员安排承诺写入签署的协议？
5. 是否有已确认的导师也列在评委名单上？
6. 奖项是否具有现金价值？是否有赞助商为其中任何奖项提供资金？
7. 这些导师以前是否担任过导师？这是一次性活动还是周期性活动？
8. 工作量上限是多少：活动前组织者最多投入多少小时？活动期间是否有人负责现场协调导师？志愿者计划中是否已有轮班表？
9. 名单最迟必须在哪天敲定，参与者最迟必须在哪天收到请求方式？各个渠道都需要提前准备，而且必须在活动时段开始前发布请求方式，因此这个日期会同时限制两者，而不只是表达偏好。
10. 哪些现有条件是默认排序未考虑的：上一届活动的导师名单、能派出多名人员的大学院系或用户组、已有员工在现场布置展位的赞助商，或曾基于此 API 开发过的组织团队。

重新排序时，请指出每个答案具体改变了哪个优先级：

• 名单截止日期较近（Q9）时，应优先考虑仅由社区成员和校友担任导师，因为联系熟人名单只需几天，而协商赞助商人员安排则需要数周。应降低与专业领域匹配的导师名单的优先级，因为标注和对齐工作是最后才能完成的环节。
• 如果活动是周期性的（Q7），应优先考虑边界说明加场景演练的简报，这份简报只需撰写一次，就能在后续届次重复使用，无需再次付费。
• 如果工作量上限较低（Q8），应降低由组织者负责分配请求的渠道的优先级，因为它会在整个活动时段内持续产生工作，而不是只需一次性设置。

工作流

1. 阅读已发布的简报后，开展访谈。
2. 按赛道而非人数设定覆盖深度。如果赞助方集成依赖某种特定技术，那么该赛道的要求就应从“有导师可咨询”提高到“该赛道开展工作期间，现场始终有导师保障”：简报中自己的兜底说明，前提是平台确实能获得支持。
3. 选择招募渠道，并按照名册截止日期所要求的提前量启动招募。加载 references/coverage-and-recruitment.md。
4. 为每位确认参加的导师标注其实际掌握的知识，使用简报中的术语：每个挑战赛道一个标签，外加赞助方技术的名称。无法对应到赛道的标签，不能起到分流作用。
5. 将名册交给你不负责的排班机制。人员规模、缓冲安排、确认和替补流程由 samber/dev-event-organizer-skills@event-volunteers 负责。你要提供排班所依据的约束：哪些时段必须安排哪些专业知识。
6. 选择请求方式，并在黑客活动开始前，将其发布在团队阅读简报的同一位置。
7. 向导师说明情况。加载 references/mentor-briefing-and-request-mechanic.md。
8. 在活动期间记录联系情况，即导师兼任评委时（Q5），记录哪些导师与哪些团队进行了有实质意义的交流。将该记录交给 samber/dev-event-organizer-skills@hackathon-judging。
9. 收尾。记录哪些赛道在什么时段缺少覆盖，然后将导师名单交给下一届的招募负责人。

在活动开始前，按章节展示设计方案并逐项确认：覆盖深度、招募渠道、专业知识标签、请求方式、导师说明。活动中途更改请求方式，会导致一半团队都没机会了解新方式。

如果你的运行环境具备持久记忆，请记录各赛道对应的专业知识标签、哪些时段覆盖不足、使用的请求方式及其失效方式，以及愿意再次参加的导师。

导师覆盖深度

分为四个层级：不设导师计划、由组织者随时待命、排定导师轮班，以及根据简报中的赛道按专业知识匹配导师名册。

• 价值（帮助团队解除阻碍、让团队真正能使用赞助方技术、覆盖每个赛道）：按专业知识匹配的导师名册 > 排定导师轮班 > 由组织者随时待命 > 不设导师计划
• 活动前的工作量（招募、排班、专业知识标注）：按专业知识匹配的导师名册 > 排定导师轮班 > 由组织者随时待命 > 不设导师计划
• 活动期间消耗的组织者精力：由组织者随时待命 > 不设导师计划 > 排定导师轮班 > 按专业知识匹配的导师名册
• 效率：排定导师轮班 > 按专业知识匹配的导师名册 > 由组织者随时待命 > 不设导师计划

支配关系检验：这种设计只是从构造上避免了问题，而从构造上避免问题绝不算通过。 价值与活动前工作量的排名完全相同，因此一种机制就能阻断全部六组比较，而不是只阻断其中几组：一组中的任何两个层级，价值较高的层级在活动前工作量上也严格更高，因此无需查看第三个维度就已无法通过检验。

第三个维度确实存在差异，但仍无法挽救任何一组比较。要构成支配关系，必须满足价值 ≥，且两项成本都 ≤；而每一组的工作量条件都已经不成立。不存在任何严格支配关系，这项检验无法发现这里的排序问题，效率这一项完全依赖下文的论证。

仍应保留组织者精力这一维度，因为它与活动前工作量的反向排序并不完全相同。 如果按活动前工作量的反向排序，顺序应为 不设导师计划 > 由组织者随时待命 > 排定导师轮班 > 按专业知识匹配的导师名册；按组织者精力的排序则是 由组织者随时待命 > 不设导师计划 > 排定导师轮班 > 按专业知识匹配的导师名册。前两位互换，而这正是关键发现：随时待命是第二省事的筹备方式，却是活动期间最耗精力的方式。 这正是为什么低成本档并不安全。值班看似免费，因为无需招募。但它会把所有技术问题都交给同时负责运行活动流程的人，而且偏偏是在最难运行流程的时候。

MLH 的指南指向相反的做法，要求志愿者“在 Discord 上保持关注，寻找需要帮助的黑客，并将他们引导至上述导师频道”，把问题从普通工作人员转给指定的导师团队。

• 排班制导师轮班——默认选项。招募和轮班表只会在活动前产生一次性成本，而 samber/dev-event-organizer-skills@event-volunteers 已提供了轮班表所需的机制，因此新增工作只是列出导师名单，而不是搭建排班系统。它能提供值班无法提供的唯一东西：一位明确安排好、专为此事而来的人员。
• 按专业领域匹配导师排班——资源不足的选项：价值最高，活动前工作量也最大，因此效率不会优先选择它。新增工作包括为每位导师添加标签，并根据赛道安排进行匹配。提升条件与 Q2 和 Q3 相关：简报将某项赞助商技术列为至少一个赛道的必需技术，或活动有明确主题，且题目来自单一领域。若未达到这些条件，团队实际需要的是通用技术支持。
• 由组织者值班——适用于组织团队确实拥有该领域的专业知识，且规模足够小，能够及时解答问题而不影响活动流程的情况。其成本会在活动期间产生，而这段时间没有任何余裕。
• 不设导师计划——这是一个真实且可排序的选项，并非稻草人：如果是开放主题活动，参与者带来自己的项目，且未指定赞助商技术，那么可能确实不需要导师；Tauberer 的指南描述的正是这种活动形式。只要简报将任何赞助商技术列为至少一个赛道的必需技术或更高要求，就从此菜单和上方的轴线中删除此选项（Q2）。此时，简报已经承诺提供活动并未安排人员的支持，而将该选项放在末尾，会悄然让这项承诺失去资金保障。

关于支持覆盖的计算方式、专业领域标签词汇，以及没有导师能够覆盖所需技能时的升级处理路径，请参阅 references/coverage-and-recruitment.md。

招募来源

四个档位：仅社区成员和校友、仅赞助商技术人员、混合团队，以及混合团队加书面参与规则，明确要求赞助商人员在担任导师时不得推销或招募。

• 价值，覆盖简报中各赛道所需专业知识的程度：混合团队并附书面规则 == 混合团队 > 仅赞助商人员 > 仅社区成员和校友
• 价值，参与者对帮助自己的人不是来推销的这一点的信任：混合团队并附书面规则 > 仅社区成员和校友 > 混合团队 > 仅赞助商人员
• 工作量（两个招募渠道、协商赞助商承诺、编写规则）：混合团队并附书面规则 == 混合团队 > 仅赞助商人员 > 仅社区成员和校友
• 合规成本，按各档位引发的审查以及由此付出的可逆性成本计算：仅赞助商人员 > 混合团队 > 混合团队并附书面规则 > 仅社区成员和校友
• 效率：仅社区成员和校友 > 混合团队并附书面规则 > 混合团队 > 仅赞助商人员

支配关系检查：经仔细核查，无误。 恰好存在一组严格支配关系。与不附规则的混合团队相比，附有书面规则的混合团队在专业知识覆盖方面价值相同，信任价值严格更高，工作量相同，合规成本严格更低；效率排序也对此作出了合理体现，将附规则的选项排在其上方。

仅社区成员和校友的专业知识覆盖价值最低，因此不能支配其他选项；仅赞助商人员的信任价值最低且合规成本最高，因此也不能支配其他选项。若此处的排序有误，就无法通过检查，因此这轮检查提供了其他三个菜单的检查所没有的信息。

这两个 == 都有依据，并非敷衍。

• 专业知识。 书面规则改变的是赞助商代表可以 说什么，而不是他们 知道什么，因此人才库对简报中各赛道的覆盖范围不会因此改变。
• 投入。 这条规则是在导师简报中加入一段话，而下一个菜单的默认选项本来就会生成这份简报；此外，还要给 samber/dev-event-organizer-skills@event-sponsor-agreement 加一行内容：投入量级与不加规则的混合人才库相同，相对于以周计的赞助协商，只需几分钟。

为什么合规成本会改变菜单排序。 赞助商代表若利用导师接触机会推销产品或招募参与者，就会造成披露问题。若未披露，这个问题会在活动结束后浮现，届时只剩道歉和赞助协商这两种补救方式。

写下这条规则会触发活动前的审核，只需一段文字，却能避免下一届再出现同样的问题。仅限社区成员的选项完全没有这种风险，这也是它在效率比上领先的另一半原因。

• 仅限社区成员和校友 - 效率领先者。将其作为面向熟人的邀请，而不是公开招募：联系“现有的导师或助教，让他们担任导师，因为他们已经体会到辅导他人的价值”，然后联系“你们学校的校友、行业专业人士和教授”。无法迁移的是具体场景。这个渠道假设活动是由院系支持的大学黑客松，因此企业或社区活动应改为联系用户组、往届参与者名单或合作公司。
• 附带书面参与规则的混合人才库 - 资源不足的选项，也是需要刻意推广的选项：它在两项价值指标和投入指标上都领先，因此，只要活动没有需要赞助商专属支持的内容，成本更低的社区渠道就会在效率比上胜出。推广条件应结合 Q2 和 Q4 来判断：只要简报提及任何赞助商技术，不论深度如何，因为不能假设社区导师了解这些技术，而赞助商自己的员工是唯一能可靠掌握这些技术的人。
• 没有规则的混合人才库 - 支配性检查会排除的选项。将它留在页面上，是因为如果没人写下那段话，默认就会变成这样。把它列出来，才能发现这种情况已经发生。
• 仅限赞助商员工 - 只要简报在赞助商赛道之外还包含常规赛道（Q2），就应从此菜单和上方的轴线上删除此选项 - 这正是 samber/dev-event-organizer-skills@hackathon-brief-design 自带的默认结构。只了解一个平台的人才库，会让每个常规赛道的团队都找不到导师，也会让每位参与者把导师的雇主徽章看成销售话术。

如果赞助商提供自己的员工，该渠道就不是志愿者报名，而是赞助交付内容，应在 samber/dev-event-organizer-skills@event-sponsor-agreement 中协商，并按承诺交付。赞助商导师缺席应视为未履行交付义务，绝不能视为爽约。

请求机制

陷入困境的团队如何联系导师。分为五级：非正式地找人；只提供可识别的导师；设置有工作人员值守、供团队上前咨询的导师区；设置请求渠道，由组织者分派每项请求；安排定时答疑时段。

• 价值，解困延迟（刚遇到问题的团队要多久才能联系上人）：带分派机制的请求渠道 > 有工作人员值守的导师区 > 可识别的导师 > 非正式地找人 > 定时答疑时段
• 价值，专业匹配度（前来协助的人是否确实了解相关内容）：带分派机制的请求渠道 > 定时答疑时段 > 有工作人员值守的导师区 > 可识别的导师 == 非正式地找人
• 投入（设置、时段内的持续协调、导师耗费的时间）：带分派机制的请求渠道 > 有工作人员值守的导师区 > 定时答疑时段 > 可识别的导师 == 非正式地找人
• 效率：可识别的导师 > 有工作人员值守的导师区 > 带分派机制的请求渠道 > 定时答疑时段 > 非正式地找人 支配关系检查：清晰，通过关怀视角，每十组关系中仅有一组。 两条价值轴确实存在分歧：按时段安排的答疑在延迟轴上处于最差档，在匹配度轴上则是第二优档，这种分歧正是这份菜单不能排成阶梯的原因。只有一组严格支配关系经得住检验：可识别的导师在延迟上严格优于非正式地找人，专业匹配度和精力投入相同，因此前者支配后者。效率排序体现了这一点。

其余九组关系各自在不同轴上有所取舍，因此这项检查无法验证它们，排序依据如下论证。

两个 == 都有论据。

• 专业匹配度。 一个可见标记只能告诉参与者谁是导师，却无法说明这位导师了解什么，因此与询问陌生人相比，匹配度丝毫没有提升。
• 精力投入。 两档的投入都近乎为零，且处于同一数量级：一档只是文具选择和角色分配，另一档则什么都不用做。

按上述效率顺序排列的五档：

• 可识别的导师 - 默认方案，也是本页成本最低的实际干预。给导师一个参与者在房间另一头也能认出的标记，并在活动的各个频道中标明其姓名；MLH 两者都做了，还设置了 "@mentor role"，让“黑客能轻松辨认导师”。samber/dev-event-organizer-skills@event-volunteers 记录了同一机制如何为另一类人群提供寻路帮助，这也是为什么预算削减时应保留标记，而不是某种福利。使其优于非正式找人的关系，只会在一种活动中失效：规模小到每位参与者都能凭面孔认出每位导师。把这视为重新排序的触发条件，而不要把它当作应写入计划的例外。
• 设有工作人员值守的导师区 - “一个专门的导师区域，黑客可以走过去提问”。晋升条件，以 Q1 为准：黑客活动空间超过一个房间，或导师团队人数多于组织团队；到了这种情况，“找一位导师”就不再是可靠的指引。
• 由组织者分流的请求频道 - 资源不足时的选择：它在两条价值轴和精力投入轴上都居首，因为整个时段都需要有人持续负责分流。公开的做法是在一个频道中让“导师知道去哪里查看请求”，同时由组织者“在聊天中保持活跃”，把黑客与导师联系起来。晋升条件，以 Q1 和 Q2 为准：活动为线上或混合形式，因此没有场地可供走动；或黑客活动空间横跨多个房间；或赞助商赛道的问题必须交给某位指定人员。
• 按时段安排的答疑 - 将其作为补充方案而非机制发布：“导师答疑时段：一种同伴小组形式的体验，人们可以在指定时间提问”。专业匹配度极佳，延迟则可能最差。如果黑客活动时段涵盖了答疑时段未覆盖的时间，就从这份菜单和上面的坐标轴说明中删去它，不能让它成为唯一途径（Q1）。凌晨三点遇到障碍的人不会等到十点的时段。
• 非正式地找人 - 在效率排序中垫底，是因为支配关系检查排除了它，而不是因为它受某项约束所限。这正是没有导师计划的活动实际上会采用的做法。

直接删除：让每项请求都经由一位指定组织者的私信转达。 从这份菜单和上面的坐标轴说明中删去它。它看起来像是成本最低的排队方式，实际上却是一个单点故障，会恰好在黑客松最需要它的时刻失效，因为那个人正在睡觉。

导师简报深度

四档：不做简报；仅介绍后勤安排；介绍后勤安排并明确说明帮助与代做之间的界限；在界限说明之外，再通过情景演练排练应对方式。

• 价值（团队是学习，而不是被带着走；参赛作品在颁奖时也经得起质疑）：边界说明加场景演练 > 说明边界 > 仅说明后勤安排 > 无
• 工作量（准备工作、简报时长、书面材料）：边界说明加场景演练 > 说明边界 > 仅说明后勤安排 > 无
• 合规成本，取决于每个等级会触发的审查，以及因此付出的可撤回性成本：边界说明加场景演练 > 无 > 仅说明后勤安排 > 说明边界
• 效率：说明边界 > 仅说明后勤安排 > 无 > 边界说明加场景演练

支配关系检查：只有通过构造才干净，而通过构造绝不算通过。 这里的价值和工作量排序也完全相同，因此仍然有一个机制挡住全部六组比较：每一组中价值更高的等级都需要更多工作量，因此没有任何一组能进入合规成本比较。

合规轴是非单调的，会真正重新排列效率轴上的顺序。重新排列和挽救是两项不同的工作，而它只做了前者。支配关系为零，这项检查什么也没有验证；排序依据如下论证。

合规轴衡量的是创作归属污染，而且它刻意呼应了 samber/dev-event-organizer-skills@hackathon-judging 中的利益冲突模式。 导师在没有明确边界的情况下将代码写入团队的代码仓库，会造成可争议的创作归属问题。问题会在颁奖仪式上浮现，奖品摆在眼前，却没有任何已发布的内容可供查证：这是最难撤回的时刻。

因此，“无”在工作量上成本最低，在合规成本上则位居第二高，默认选项也不是成本最低的等级。这种风险是真实存在的，而非纸上谈兵：samber/dev-event-organizer-skills@hackathon-brief-design 引用了已发布的要求，规定提交的代码必须公开且持续公开，才能保留获奖资格，因此提交记录清晰可见，代码归属也一目了然。

场景演练在同一轴上成本最高，原因恰恰相反。它是一项书面标准，活动方之后必须遵守，因此在发布前会触发审查；而导师接受过相关简报后，这也是最难撤回的等级。这与 samber/dev-event-organizer-skills@hackathon-judging 中的披露登记等级性质相同，后者正是出于同样的原因，在自身的合规轴上成本最高。

• 明确说明边界——默认选项，也是四种方案中合规成本最低的一种。在活动开始前就划定界线，此时只需一句话；而在活动进行到一半时提醒一次，也仍能纠正偏差。边界是你设定的一条界线，而不是可供引用的标准；其措辞以及经过推演的正反案例见 references/mentor-briefing-and-request-mechanic.md。
• 仅说明后勤安排——到哪里、何时、用哪个频道，以及向谁升级求助。这些信息必不可少，但单靠它们远远不够：它没有回答导师实际会遇到的那个问题。MLH 的指南接近这一档，要求导师指南涵盖“要问参赛者的问题、如何与参赛者一起排查问题，以及实用的入门工具／资源”，并要求提供“一套导师在辅导期间该做什么的准则，为他们提供一个流程”，但将“帮助还是代做”的界线留给组织者决定。
• 不设规则——只要任何奖项具有现金价值，或有赞助商提供资金，就应立即从此选项菜单和上方的各档说明中删去（Q6）。这与 samber/dev-event-organizer-skills@hackathon-brief-design 的做法一致：在相同触发条件下，出于相同原因删去了其中最宽松的规则档。奖项一旦有价值，分歧就会变成索赔；而未接受过简报的导师提交的代码变更，则会引发无人能回答的参赛资格问题。
• 边界说明加情景演练——资源最紧缺的选项：价值最高，所需精力和合规成本也最高。晋升条件依据 Q7 和 Q4：大多数导师此前都没有担任过导师，或赞助商员工正在为其雇主有商业利益的代码库提供辅导，或活动会定期举办，且演练只需编写一次、供后续各届重复使用。

无论选择哪一档，简报都必须包含的内容、关于权力关系的指引，以及指向行为准则处理流程的升级求助说明，见 references/mentor-briefing-and-request-mechanic.md。

按专业领域轮换

班次时长、到场缓冲时间、报名确认和缺席后的补位，都是 samber/dev-event-organizer-skills@event-volunteers 的计算范畴；这里不再重新推导。你对排班表的贡献只有一项约束：**每小时都需要有哪些专业领域的人员在场。**也就是说，安排赞助商 API 专家值守该赛道实际开展工作的时段，而不只是安排某人到场值守。

**报名时直接向导师确定时段。**两种已发布的做法都支持这一点：“通过表单让有意向的人报名，并让他们选择一个时段”，以及“为每位导师分配时段，让他们更清楚自己的时间安排，同时鼓励他们在整个黑客松期间都在场”。原文在这里留有一处矛盾：既分配时段，又要求导师无论如何都到场。在排班表中解决这一矛盾，而不是留到说明会上：时段代表承诺，时段之外的到场则是额外帮忙；排班时只能将其中一种作为依据。

**根据团队何时需要各项专业技能来错开覆盖时段，而不是让所有专业领域的导师都在相同的固定时段值守。**如果某条赛道一开始就需要进行问题定义工作，那么早期阶段的导师就应尽早到位。如果某条赛道只有在团队明确方向后才能开始构建，那么技术导师就应晚些到位。只要排班表允许，就遵循说明中的实际阶段安排，绝不要安排所有人从开放到结束全程值守。

Opportunity Hack 的导师指南也根据构建进度安排了相同的错峰轮换：早期安排验证导师，活动中期安排调试导师，团队“应该已经开始编写代码”后安排完成阶段导师，最后阶段安排演示导师。每个阶段都由具名的专业领域人员负责（产品、GitHub、云部署、软件工程），而不是由一个不分专业的导师池统一负责。

**为每位导师负责的团队安排可核查的走访频次，而不只是规定其值守时段。**为每个分配到的团队设定最低检查频次——次数由本次活动自行确定——就能将“保持待命”转化为导师可以做到、组织者也可以核实的要求。最后冲刺阶段开始前就停止安排走访，让团队能够不受打扰地做好最后准备，避免临时调整干扰他们自己的收尾工作。

排班表还需由你决定两件事：

• **夜间时段。**黑客松的活动窗口可能延续到深夜，而会议日不会；因此，基于白天假设制定的轮换安排会让受阻团队最多的时段无人覆盖。请审慎决定这些时段是安排人员值守、减少人员值守，还是明确不安排人员值守，并公布决定。
• **无人覆盖的技能。**如果导师名单中没有人具备所需技能，应公布升级求助渠道，而不是临时 improvisation。提前说明要向谁求助，以及得到“无人可求助”的答复时该如何告知团队。

干预节奏

主动覆盖意味着导师主动巡场，而不是等人求助；团队始终更偏好这种覆盖方式：这样一来，团队不必等到自己意识到陷入困境后才得到帮助。如果缺乏协调，实际效果就会与承诺背道而驰：团队每遇到一位路过的导师，就得重新介绍一遍项目，每次都浪费几分钟，而导师团队也没有记录，无法知道谁已经拜访过哪些团队。

保留主动覆盖，不要用上文的请求机制取而代之，因为两者解决的是不同问题。应当限制主动覆盖的频率：

• 为每次拜访设定时间上限，并使用团队可见的计时器；只有在确实需要动手操作、无法限定时长的情况下，才放宽限制。
• 由团队自行控制的“请勿打扰”信号，并确保在房间另一端也能看见。
• 公布每位在场导师实际擅长的领域清单，这样使用上文请求机制的团队就能按姓名找到合适的人。
• 共享的实时视图，显示哪些团队目前遇到了阻碍以及具体问题；这样闲着的导师就能找到下一个需要帮助的团队，而不是再次拜访并不需要帮助的团队。

需要留意的失效信号：短时间内，几位专长重叠的导师接连拜访同一团队，而另一个团队数小时无人问津。这是协调不到位，而不是覆盖深度不足。上面的覆盖深度选项无法解决这个问题，只有共享各导师拜访过哪些团队的视图才能解决。

失效模式

• 把主题活动中的专家比例当作导师配备公式。 现有的唯一数字统计的是主题活动中参与项目的领域专家人数与非专家参与者人数之比，它是项目供给目标，而不是人员配备目标。它既不统计导师，也不统计团队，而且不适用于开放主题或赞助商赛道的活动。解决方法：根据活动简章中的赛道及其工作时长来确定覆盖规模。
• 活动简章承诺了赞助商赛道，现场却无人提供支持。 简章中的备用方案假定平台能够获得支持；如果集成只能依赖某个底层平台，而导师虽可能提供帮助却难以找到，那么这项承诺就会悄无声息地落空。解决方法：先了解集成深度（Q2），再确定覆盖深度。
• 参与者无法辨认导师。 本页所述最容易避免的失效：导师在场，参与者却认不出他们，结果整个房间都以为没有人能帮忙。解决方法：先准备一个标识，并明确导师的角色，无需一开始就做得更复杂。
• 导师接过键盘。 这样虽然能修复错误，却会影响提交作品的创作归属；该作品将接受评审，也可能获得报酬。解决方法：在简报中说明边界，并明确导师应该采取什么做法。
• 在此处重新设计轮班表。 人员规模、缓冲和补位方式已在相邻章节介绍，在那里推导更合适。解决方法：明确专长方面的约束，并让负责排班的人据此安排。
• 把导师当成评委来做简报。 两份文档，两类受众，一个称谓。解决方法：每次都说“导师简报”。
• 导师评审自己曾辅导过的团队。 解决方法：如果导师也担任评委，就保留接触记录，并在评委名单确定前交出记录。
• 通宵活动只采用办公时间这一种机制。 解决方法：办公时间只能补充响应时延机制，绝不能取而代之。
• 巡场导师之间没有共享的拜访记录。 覆盖虽然存在，却没人知道哪些团队仍需要帮助，于是导师都聚到最后一个介绍得最响亮的团队那里，而另一个团队数小时无人问津。解决方法：限制拜访频率，并共享受阻团队视图，而不是只招募更多导师。

衡量标准

以下所有阈值都是自行设定的，并非行业标准。介绍时请说明这一点，并且只与本次活动的上一届进行比较。

通过阈值（结构性，仅一项）：在黑客活动时段开始前，以下五项均已书面落实且没有任何空缺。 反复迭代，直到计数达到五项。

• 将专业领域标签映射到简报中的赛道。
• 每条赛道的覆盖承诺。
• 团队会看到的求助方式。
• 导师简报，包括边界说明。
• 没有导师能覆盖某项技能时的升级路径。

活动时段内值得记录的信号（自行设定）：

• 等待时间最长的求助，以及它来自哪条赛道。
• 哪些时段没有带对应标签的导师在场。
• 完全找不到任何人的求助。
• 如果任何导师兼任评委，则记录联系日志本身。

选取两到三项，写明每项会触发怎样的修订，并在活动期间实时记录，而不是事后还原。

调用示例

• “我们有 200 名黑客和一条赞助商 API 赛道。需要多少名导师，分别由谁担任？”
• “卡住的团队凌晨 2 点到底怎么联系导师？”
• “写一份导师简报——他们可以对别人的代码仓库做什么？”
• “我们的赞助商想派四名工程师担任导师。我们需要书面约定什么？”
• “我们有一名导师同时也是评委。这有问题吗？”

预期输出：一份导师计划，包含：

1. 每条挑战赛道的覆盖深度，并注明对应等级。
2. 招募渠道及各自所需的提前时间。
3. 将专业领域标签映射到简报中的赛道。
4. 传递给排班计划的专业领域限制。
5. 参与者会看到的求助方式。
6. 导师简报，包括边界说明和升级指引。
7. 联系日志的处理决定。
8. 适用于推送式覆盖的打断频率限制机制。

在活动时段开始前，按章节逐项呈现并验证。

参考资料

• references/coverage-and-recruitment.md - 根据赛道而非人数确定覆盖规模、完整说明适用范围的主题活动比例、专业领域标签词汇、包含提前时间和赞助商交付物表述的招募渠道，以及没有导师能覆盖某项技能时的升级路径。
• references/mentor-briefing-and-request-mechanic.md - 导师简报的内容，其中写明了帮助与代为构建之间的边界，并提供一组正反示例、权力关系指导、赞助商代表参与规则，以及按参与者实际看到的方式发布的求助方式。

另请参阅同一集合中的以下项目：

• samber/dev-event-organizer-skills@hackathon-brief-design - 定义挑战赛道和赞助商集成深度，本技能据此确定覆盖规模；其中说明简报只会提到有导师。
• samber/dev-event-organizer-skills@hackathon-judging - 负责导师兼任评委时的回避规则及其机制，并已从自身角度说明；本技能仅提供该规则所需的导师团队联系日志。
• samber/dev-event-organizer-skills@event-volunteers - 负责人员名单规模、轮班表、到场缓冲时间、报名确认和未到场人员的替补流程；本技能直接沿用，不重新设计。
• samber/dev-event-organizer-skills@event-code-of-conduct - 负责适用于导师及所有其他明确列出的角色的行为准则、报告和执行；本技能负责说明，不负责监督。
• samber/dev-event-organizer-skills@event-sponsor-agreement - 在赞助商提供导师的承诺及约束其参与的规则纳入本计划之前，负责协商相关事项。
• samber/dev-event-organizer-skills@event-run-of-show - 负责安排黑客活动时段，专业领域轮班安排需与其时长相匹配。