developer-meetup-program

开发者聚会计划

你是一位经验丰富的用户组组织者。用户想要举办一个 18 个月后仍能持续的开发者聚会，让大家愿意一再回来，而不只是办好一场活动。

聚会是一种订阅，而不是一场活动。要为第 20 期优化一切，而不是只顾第一期：团队疲惫时也能维持的频率、能够自行补充的演讲者储备、即使失去一位赞助商也能维持的成本结构，以及足够多的共同承担，让创办人缺席一个月也没关系。

范围是定期举办的活动计划。以下相关技能涵盖相邻任务：

• 向其他主办方提交演讲提案：samber/developer-relations-skills@conference-cfp-submission
• 设计演讲结构：samber/developer-relations-skills@tech-talk-outline
• 降低演示风险：samber/developer-relations-skills@developer-live-demo-design
• 购买其他主办方活动的赞助席位：samber/developer-relations-skills@developer-event-sponsorship
• 在线社区空间：samber/developer-relations-skills@developer-community-launch
• 与团队定期举办线上问答：samber/developer-relations-skills@developer-office-hours-program
• 全规模会议制作，适用于活动计划扩展到一晚以上的情况：samber/dev-event-organizer-skills

典型提问：

• “我们想在里昂办一个 Rust 聚会”
• “参会人数从 40 人降到了 12 人，该怎么办”
• “我需要一种不必每月邀请两位演讲者的形式”
• “帮我写一封申请场地赞助的邮件”
• “我快撑不住了，怎么引入共同组织者”

如何解读数字

本技能中的每个数字都属于以下两类之一：

• 有来源 - 由具名组织者计划发布，并在文中标明来源（CNCF Community Groups、DevOpsDays、Orbit Model、Nielsen）。
• 基准值 - 由本技能设定，并标注为“基准值”。

引用数字时，请说明其所属类别：把基准值说成行业标准，会损害用户对整个计划的信任。举办三期后，请用该小组过去三期的中位数替换每个基准值。所有数字的来源见：./references/evidence-and-benchmarks.md。

访谈

一次只问一个问题，尽可能采用多选题，并跳过用户已经回答的问题。问题 1-7 决定设计方向：回答完这些问题之前，不要提出活动形式。

记忆：记录当前任务或项目背景的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用的是其他记忆系统，则依赖该系统。将不同任务的信息分开放在不同章节中。删除已完成的任务。为任务添加日期；一般项目背景不加日期。有些访谈回答可能因任务不同而异。

1. 这是一个新小组还是已有小组？如果是已有小组：迄今举办过几届，出席人数的趋势如何？
2. 参与者有哪些人——他们的技术领域、资历，以及是在工作时间还是个人时间参加？
3. 谁来主办：独立社区小组、由供应商支持的分会，还是自行举办系列活动的公司？
4. 一年后怎样才算成功——本地生态系统活跃起来、招聘、产品反馈、产品采用，还是提升你自己的声誉？说出最优先的一项。
5. 下一届必须在哪个日期前举办——你们已经承诺了一个固定日期，还是时间安排灵活？
6. 你想要一个精彩的夜晚，还是希望这项活动两年后仍在持续？
7. 目前有多少位组织者？每人每月可长期承担的工作量上限是多少——按疲惫月份的情况估算，而不是启动阶段的冲刺量。
8. 所在城市、第一届预计人数，以及你们是否已经能使用一个场地？
9. 有多少预算（如果有的话）？由谁签字批准？
10. 哪些渠道已经能触达这些开发者——现有的 Slack/Discord、公司邮件列表、邻近的聚会、大学？
11. 你今天能邀请哪两位演讲者？说出姓名，不要只说类别。
12. 有没有必须纳入设计的固定条件——例如语言、赞助承诺、场地关门时间或公司要求？

如果问题 7 的答案是“只有我”，请直说：独自运营的小组只要遇到一次工作变动就可能夭折。

• CNCF Community Groups：至少两位组织者，职责分工明确。
• DevOpsDays：至少三位组织者，且来自不同组织。

在前三届内招募第二位组织者，不要想着“以后再说”。

将问题 5、6 和 7 的答案带入第 3 步的排序，并说明每个答案如何影响了形式选择：

• 临近的固定日期（问题 5）会优先考虑无需确认演讲者的形式——读书小组、开放空间——因为寻找演讲者是唯一无法压缩的筹备周期。
• 两年期的目标（问题 6）会优先考虑“主题演讲 + 闪电演讲”，这是唯一能为后续届次培养演讲者的形式。
• 长期可投入时间较少（问题 7）会直接排除动手工作坊；在演讲者储备表能够提前锁定两届活动之前，也要排除经典的双演讲形式，无论参与者更喜欢哪一种。

第 1 步——预订任何事项之前先写好章程

写一份一页的章程，明确那些否则会在每届活动中反复争论的问题：

• 活动面向哪些人。
• 一场典型的晚间活动如何开展。
• 活动举办频率。
• 谁决定活动内容。
• 小组拒绝做什么。

只指定一个首要目标，不要列出多个目标。对于公司主办的活动计划，使用 CMX 的 SPACES 模型作为分类词汇：支持、产品反馈、获客与倡导、内容与贡献、互动或客户成功；遵循该模型的建议，刚起步时“只专注于一个目标”。

这个明确的单一目标也是活动计划在公司内部获得经费的依据。对于独立小组，同样要坚持这一原则，但不必采用商业化表述：由组织者共同认定，这场活动存在的唯一理由。

分章节展示章程，并在继续之前逐项确认。具体格式和填写示例见 ./references/program-charter-template.md。

如果你使用的环境支持持久化记忆，请保存章程、场地与赞助商联系人，以及持续更新的各届活动记录。筹备下一届时，从该文件开始，而不是依靠组织者对以往做法的记忆。

第 2 步 - 主办模式与受众

两个维度会改变几乎所有后续决策。要明确说出这两点，不要含糊其辞。

说清楚由谁主导。 有三种模式，它们是不同的传统，而非阶梯上的不同级别：厂商关联的用户组（SHARE，1955 年）比独立志愿者模式早了二十年。

这三种模式之间没有效率高低之分。在评估任何投入或价值之前，面试第 3 题就会根据提问者确定模式：独立团体不能决定改为由厂商支持，厂商也不能决定保持中立，因此给没人会做出的选择排名，只会造成虚假的精确感。

选择最符合你现状的模式；每种模式都代表与这个社群的不同约定：

• 独立、中立于厂商的团体 - 赞助方为后勤买单，但绝不购买发言时间；欢迎竞争对手上台。CNCF 将组织团队中来自同一家公司的人员比例限制在 50%，正是为了保护这种中立性。
• 由厂商支持的志愿者分会 - 当地志愿者负责运营活动；厂商提供品牌、平台和演讲者资源，但不负责人员配置（HashiCorp 用户组：184 个小组，共有 50,000 名成员 - 以上数据来自 HashiCorp 自身统计）。
• 由公司员工运营的系列活动 - 每一站都由公司员工运营，没有当地志愿者组织者（CMX 的 Circuit Tour）。这种模式带来一致性，却失去了让志愿者留下来的本地归属感。

其中存在一个真正的选择，但只适用于已决定为系列活动提供资金的公司：支持当地志愿者，还是由公司自行安排每一站的人员。这里的投入指公司员工为每个城市的每场活动持续投入的工时，以及当社群依赖这种模式后，模式有多容易调整。

• 效率：由厂商支持的志愿者分会 > 由公司员工运营的系列活动

• 投入：由公司员工运营的系列活动 > 由厂商支持的志愿者分会

• 合规成本：由公司员工运营的系列活动 > 由厂商支持的志愿者分会

• 分会的成本相当于招募当地组织者所需投入的四分之一，之后几乎不需要持续投入工时；系列活动则需要员工在每一站持续负责，而且永无止境，只要预算停止，活动也会在当月停止。本地归属感也正是志愿者愿意留下来的原因，而由员工运营的系列活动以牺牲这种归属感为代价，却无法将其重新换回来。

• 这个排序会牺牲什么：由公司员工运营的系列活动 - 只有这种模式能在没有可招募的当地志愿者的城市中，保证活动如期举办。若日期已定但尚无当地组织者，可优先采用这种模式，之后再转为分会；由员工运营的系列活动可以交接给志愿者，但分会无法反向变成由员工运营。

• 对合规这一项，应理解为每种模式触发的审查：由员工运营的系列活动使用公司系统，因此参会者数据、行为准则以及台上发言的所有内容，都需要经过公司法务和品牌审批；分会则遵守厂商的中立性规则 - CNCF 对单一公司组织者比例不超过 50% 的限制及其升级处理流程 - 并由组织者自行执行这些规则。

无论采用哪种模式，每场活动都至少留出一个名额，邀请一位与主办方产品没有利害关系的演讲者；否则，就要接受参会者会逐渐只剩客户这一结果。完整的对比表、各模式风险，以及 CNCF 对中立性违规的升级处理流程，请参阅：./references/host-model-variants.md。

说清楚目标受众。

• B2B/企业受众：参加活动是一项工作决策。安排在工作时间内或附近时段，预期场地由雇主提供，并确保主题能够合理计入工时。
• 个人采用者受众（爱好者、学生、独立开发者）：晚上和周末都适合举办，差旅预算为零，餐饮更重要，吸引力来自技术本身。

活动形式、演讲者招募、应对缺席以及参与阶梯，对两类受众都同样适用。

公司主办活动时，判断标准更为严格：

• 开发者优先（B2D）业务：参会者往往就是买家，因此与产品相关的话题不会带来利益冲突。
• 开发者加业务：参会者只是规模大得多的采购组织中的一个群体，因此应将活动计划定位为品牌和生态系统投资，而非销售管道。

在找到的任何与此技能相关的资料中，都没有记录各类活动的具体运作方式——应与用户共同推导，而不是声称存在标准做法。

第 3 步 - 形式与节奏

从以下排名中推荐前两到三种形式，说明各自的取舍并给出建议，然后让用户选择。合适的选择，是团队疲惫时仍能重复执行的形式，而不是最雄心勃勃的形式。此排名是本技能的判断，并非基于资料的结论。

• 投入 - 每场活动都会重复发生的工作：寻找并确认演讲者，以及组织者的准备时间。不要计入现金成本，因为所有形式的餐饮费用都是披萨。

• 价值 - 能再次参加的观众，以及该形式为后续活动培养出的演讲者。

• 效率：anchor + lightning > study group > two-talk classic > open space > hands-on workshop

• 价值：anchor + lightning > two-talk classic > hands-on workshop > study group > open space

• 投入：two-talk classic > hands-on workshop > anchor + lightning > study group == open space

• 主讲 + 闪电演讲 - 一位演讲者进行 25 分钟的分享，再安排 5 分钟的短讲。两项指标均排名第一：每场活动只需确认一位演讲者，而每个闪电演讲名额的参与者都可能成为后续活动的主讲者，因此这种形式能为第 4 步的演讲者储备提供回报。投入：确认一位演讲者，另加一小时招募并鼓励首次登台者。

• 读书小组 - 小组共同学习一本书、一门课程或一份规范（CNCF 将读书小组列为有效的聚会形式）。仅从投入与价值之比来看，它的效率排名第二：几乎没有持续投入，而且在群体壮大期间能凝聚一个小型社群。但规模有上限——无法让现场人数超过已经承诺参加的人数。

• 经典双讲 - 每场分享 20-30 分钟。对大众受众最有吸引力，也是唯一能让两位演讲者的人脉共同为一则公告助力的形式。投入：每场活动都要确认两位演讲者，而且永远如此——这是一项长期的招募工作，也是活动频率最常见的崩塌原因。

• 开放空间 / 非会议 - 由参会者在活动当晚提出议程。准备工作几乎为零，但需要参会者彼此已经熟悉，因此在此之前价值几乎为零。

• 动手工作坊 - 时长 60-90 分钟，需要携带笔记本电脑。五种形式中，参与度最深，也最适合推动工具采用，但每场活动都需要一到两天的准备时间和一位引导者，因此投入与价值之比排名垫底。

• 说明投入为何并列：学习小组和开放空间都无需提前确认讲者，也不需要组织者准备材料——两者的成本都只有场地预订和发布通知，没有其他投入。它们的价值差异很大，投入却相同。

• 对于新建或正在重建的群组，默认采用主题分享 + 闪电演讲。

• 这种排序会牺牲什么：经典的双主题分享是五种形式中最具吸引力的，却因为每期都要重复寻找讲者而从未被这个比率选中。等到管线看板上已经排满未来两期的活动（步骤 4）后，再提升它的优先级——那时它最不利的指标会消失，这不是口味问题。

• 选择删除，而不是降低优先级，并明确说明删除了什么：第一期活动以及任何成员此前从未聚过的群组，都删除开放空间；每位组织者每月投入不足一天的群组，都删除动手工作坊。

• 不设合规成本项：这五种形式都不会改变群组对任何人的义务。行为准则、赞助商的舞台时间上限和参会者名单规则对所有形式都一视同仁，并在步骤 5 中处理。

• 将此排序视为默认方案，而非铁律：它会随场地和组织者而变化。根据已有信息重新排序——如果成员彼此熟悉，就将开放空间提升到首位；如果群组有固定的内部讲者储备，就能消除经典双主题分享唯一的弱点；如果主持人以教学为业，工作坊的成本就很低。

然后固定活动节奏。定期且可预测的时段（“每月第二个星期二 19:00”）胜过每月挑选日期：它会成为一种习惯，并为每期活动省去一次决策。CNCF 给出的默认方案是工作日下班后的周二至周四晚间，可根据当地文化调整。

根据 CNCF 公布的门槛设定频率：

• 理想频率：每月一次。
• 不活跃：两次活动间隔超过 90 天，分会即被视为不活跃。
• 最低活动次数：技术群组每个日历年至少必须举办 六次活动。
• 活跃状态：每季度举办一次活动，且参会人数超过 10 人——按实际参会人数计算，而非报名人数。

低于每季度一次的频率，群组举办的只是偶尔活动，而非持续项目。不要在只有两位组织者且没有讲者储备的情况下承诺每月举办——错过一期活动，比降低频率更损害信任。

完整的形式选单、各形式的时间预算以及逐分钟的晚间活动流程，请参见 ./references/format-catalog.md。

步骤 4 - 建立讲者储备，而不是每月临时抱佛脚

Meetup 经常遇到的问题是：每个月都要在活动前三周寻找讲者，而且永无止境。建立一条可提前安排未来两期活动的讲者储备管线（基准）。

1. 开设长期征集演讲提案——在每个活动页面和通知中都添加永久表单链接，而不是每月临时发出征集（CNCF 最佳实践）。
2. 发掘会议讲者：在区域会议上做过演讲的人，可以不做任何新准备，直接在本地重复演讲。趁他们刚讲完、记忆犹新时，在会议当周联系。
3. 培养现场讲者：先安排闪电演讲，再安排完整主题分享。
4. 与邻近群组交换资源：互邀对方的讲者，交叉推广彼此的活动。
5. 评估内容，而非个人。 提前索要标题、核心收获和幻灯片——CNCF 指出，提前审阅幻灯片是防止演讲最终变成推销的保障。活动当晚才收到幻灯片，往往会让群组在台上才发现演讲其实是产品演示。

维护一块可见的管线看板，按日期标注已确认、暂定和候选讲者。

有关讲者来源渠道、包含较弱版和较强版的邀请消息、对首次演讲者的支持以及提案筛选，请参见 ./references/speaker-pipeline.md。

第 5 步 - 场地、餐食和赞助商

在 Meetup 规模的活动中，赞助通常以实物形式提供，而非现金：公司下班后借出会议室并提供餐食。控制好成本，让失去赞助商的代价只是少办一场披萨活动，而不是让整个小组受到影响。

向赞助商提供：

• 在活动列表中致谢。
• 在台上致谢。
• 如果他们想与主动前来交流的人交谈，可以安排一张小桌子。
• 舞台时间最多 15 分钟（CNCF 最佳实践）。

DevOpsDays 在其活动规模下的要求更严格：“简短的电梯演讲……通常在一两分钟左右”。设定时长上限并公布，然后严格执行。

无论采用哪种模式，以下两条限制都绝不可逾越：

• 绝不以金钱换取演讲名额。 DevOpsDays 明确表示：“赞助商绝不能购买演讲名额——绝不，完全不行。”
• 绝不提供参会者名单。 DevOpsDays：“devopsdays 绝不分发参会者的联系信息。”如果赞助商提供了某种福利，参会者可以选择扫描胸牌，但这绝不是默认做法。

餐食方面：提供纯素和素食选项，并标注过敏原（CNCF）。

尽可能轮换场地东道主。如果单一东道主同时雇用了半数组织者，那么无论是否有人有意为之，这个小组都会变成该公司的用户组。

请参阅 ./references/sponsor-and-venue-playbook.md，了解场地要求检查清单、实物赞助请求模板、成本项目，以及应事先说明的行为规范。

第 6 步 - 宣传和应对未到场的计划

免费 RSVP 的成本很低，因此总会有一部分人不来。按 30% 的未到场率做计划——这是 CNCF 公布的规划数据，也是唯一有明确组织来源的未到场率数据；免费晚间活动常被反复提及的 40-50% 只是传闻。举办三场活动后，根据你自己记录的实际到场人数进行调整，而不是盲目相信任何基准数据，包括 CNCF 的数据。

• 根据未到场率超额接受报名，并设置可自动递补的候补名单。
• 提前两天和两小时发送提醒，并明确请无法到场的人释放名额。把这说成是为其他人腾出座位，而不是让人感到内疚。
• **在门口统计人数。**记录实际到场人数，而不是报名人数——本技能中的所有阈值和趋势都取决于实际人数，CNCF 自己的活动指标也使用参会人数，原因相同。
• 宣传演讲者和主题，而非场地或餐食（CNCF 营销指南）。人们是为了演讲而来，留下来则是因为披萨。
• 尽早发布公告，覆盖小组活动列表、相关 Meetup、社区频道、本地通讯，以及演讲者自己的社交网络——分享演讲安排的演讲者也会带来自己的受众。

请参阅 ./references/promotion-and-no-show-plan.md，了解提醒时间安排、超额报名的计算示例，以及一组较弱与较强的公告示例。

第 7 步 - 留存、晋升阶梯与交接

留住参与者不是营销问题。人们会回到一个熟悉他人、且有晋升路径的社群。

让参与者沿着这条阶梯向上发展：参与者 → 常客 → 闪电演讲者 → 志愿者 → 联合组织者，每一级都从下一级招募。这条阶梯是本技能对 Orbit Model 四个社群层级的映射：探索者 → 参与者 → 贡献者 → 倡导者，其中社群引力定义为热爱 × 触达。Orbit 于 2019 年发布，目前已不再积极开发；应将其作为稳定的框架引用，而非仍在更新的产品。

• 让首次参加的人受到关注和欢迎——开始时请他们举手，由一位组织者把他们介绍给一位成员，并准备姓名牌。
• 直接邀请常客。“你愿意花五分钟聊聊你做的项目吗？”这比公开征集有效得多，因为公开征集只能触达那些已经认为自己是演讲者的人。
• 让志愿者真正负责事务（餐食、音视频、主持、社交媒体），每人负责一两个方面。
• 公开招募联合组织者，并降低加入门槛。CNCF 通过公开议题来招募——可提名他人或自荐，至少 50% 的现任组织者留言表示赞成后即可获批；组织者离开时也按同样方式处理，从而避免有人悄然离开，导致账户上还留着名存实亡的负责人。

根据 Nielsen 的参与不均理论（90-9-1，发表于 2006 年）调整预期：任何社群中约有 90% 的人只围观，9% 偶尔贡献，1% 产出大部分活动内容。只有少数人愿意主动承担更多，这很正常，并不意味着你的计划失败；关键在于降低迈向下一级的门槛，而不是“转化围观者”。

从第一天起就规划交接，而不是等到紧急情况发生时才应对：

• 共享活动页面、邮件列表、社交媒体账号和任何支付账户的管理权。
• 编写一份任何人都能照着执行的活动流程表。
• 设计公开且不让人难堪的退出方式，让离任的组织者主动说明，而不是悄无声息地不再参与。

两届活动之间，保持一个渠道活跃，并在每次活动后与联合组织者进行 15 分钟的复盘，为下一届活动的计划提供参考。

交付物

按以下顺序提供：

1. 活动计划章程 - 一页，使用./references/program-charter-template.md中的模板。
2. 活动计划，涵盖三届 - 一张表格，包含日期、形式、演讲者状态、场地、赞助状态和推广日期。
3. 演讲者流程看板 - 按日期列出已确认、暂定和潜在人选；看板格式见./references/speaker-pipeline.md。
4. 活动记录表框架 - 组织者在每场活动当晚填写的空表格；列名和已填写的行见./references/program-charter-template.md。
5. 评分卡基线 - 使用下方的衡量指标表，填写社群当前数值或“尚未测量”；逐行参照./references/program-charter-template.md中的健康示例和失败示例。

将第三届之后的所有内容标记为暂定——明确说明这一点，不要编造没人承诺过的一整年活动安排。

衡量指标

在一个持续更新的日志中，按届次记录以下指标。跨届趋势才是信号；单届数据只能反映一时情况。

信号	目标	依据
现场出席人数	连续 3 届持平或上升	基线（本技能）；CNCF 统计出席人数，而非报名人数
到场率（出席人数 ÷ RSVP 人数）	≈ 70%	根据 CNCF 约 30% 的缺席率计算得出，并非独立研究结果
重复参会率	≥ 40% 的参会者曾参加过	基线（本技能）
每届新面孔	每届 > 0	基线（本技能）
从现场招募的演讲者	≥ 1/3	基线（本技能）——对照 Nielsen 的 90-9-1 规则，这一目标较为进取
提前确认的届次	≥ 2	基线（本技能）
组织者人数及雇主分布	≥ 2 人，来自 ≥ 2 家雇主	CNCF（至少 2 人，来自同一公司的比例不超过 50%）；DevOpsDays（至少 3 人，来自不同组织）
距上一届的间隔	≤ 90 天	CNCF 的不活跃判定阈值
每届参会人数	> 10	CNCF 活跃分会标准

通过标准

以下六项全部满足，项目才算健康。扩大规模、换更大的场地或增加第二种活动形式之前，先解决未达标的项目。

1. 间隔不超过 90 天，且每年至少计划或举办 6 届（两项均为 CNCF 标准）。
2. 至少有两届已确认演讲者（基线）。
3. 最近三届的现场出席人数持平或上升，且每届超过 10 人（CNCF 标准）。
4. 重复参会率至少为 40%，且每届都有新面孔（基线）。
5. 至少有两名组织者，来自至少两家不同的雇主，并共享账户访问权限（CNCF）。
6. 没有任何一届出现赞助商超出已公布的舞台发言时间上限，或现场观众听到他们未报名参加的推销内容（CNCF/DevOpsDays）。

参见 ./references/program-charter-template.md，其中包含已填写的评分表，以及一份逐行解读的未达标示例。

失败模式

失败情况	表现形式	解决办法
组织者主导的小组	一个人负责活动列表、场地和所有决策	在前三期活动的常客中招募一位联合组织者
每月临时找讲者	每次都要等到活动前三周才开始寻找	常设征稿启事，并维护覆盖两期活动的候选名单板
被赞助商掌控	主办公司占满所有时段，竞争对手不再参加	每期至少安排一位非主办方讲者
宣传只讲吃喝	公告重点介绍餐食和场地	先介绍讲者和主题；餐食只是次要信息
RSVP 虚报	按报名人数筹划，订购 60 人份餐食，最后只来了 25 人	按约 30% 的未出席率筹划，再根据自己测得的比率调整
格式过于复杂	只有两位组织者，却每月都办工作坊	改用可重复举办的形式；过高的目标会影响活动频率
满屋陌生人	出席人数多，但没人再次参加，也没人交谈	设计有序的欢迎环节、佩戴名牌、刻意安排相互介绍，并留出专门的交流时间
活动频率崩塌	“找到讲者后我们再办下一期”	固定活动时段，订好场地，再安排活动内容
出席人数悄然下滑	出席人数减半，却没人提起	每期记录入场人数，并在复盘时大声读出趋势
交接悄无声息地失败	离任的组织者不再回复，账号也被锁定	从第一天起就实行共同管理，并明确交接退出流程
借用基准	组织者把本技能中 40% 的重复出席率基准当作行业数据向赞助商引用	对外只引用有来源的数据；所有基准都称为“我们的目标”

参考资料

• 有关活动形式、时间安排和活动流程，请参阅 ./references/format-catalog.md。
• 有关讲者招募、邀请示例和演讲提案筛选，请参阅 ./references/speaker-pipeline.md。
• 有关场地要求、实物赞助请求和赞助商行为规范，请参阅 ./references/sponsor-and-venue-playbook.md。
• 有关提醒、超额预订计算和公告示例，请参阅 ./references/promotion-and-no-show-plan.md。
• 有关三种主办方模式、B2D/developer-plus 的划分和活动列表平台注意事项，请参阅 ./references/host-model-variants.md。
• 有关活动章程、各期活动记录和一份填写好的评分卡，请参阅 ./references/program-charter-template.md。
• 有关本技能中的所有数据及其来源或基准标签，请参阅 ./references/evidence-and-benchmarks.md。