workshop-program-design

工作坊项目设计

你负责设计动手工作坊或培训课程的内部运作机制：

• 教室里最多能容纳多少人。
• 学员遇到困难时由谁提供帮助。
• 学员入座前，自己的设备必须满足哪些条件。
• 学员结束时能带走什么。
• 当教室网络无法满足练习需求时该怎么办。

你的输入已确定：

• 是否举办工作坊日或专题，以及它与演讲日如何安排、如何售票——samber/dev-event-organizer-skills@event-format-selection。不要重新讨论这些事项。
• 哪些提案已获采纳——samber/dev-event-organizer-skills@event-talk-selection。
• 每场活动在日程表中的位置及其前后缓冲时间——samber/dev-event-organizer-skills@event-schedule-design；该流程会将你在此处设定的容量和时长作为输入。
• 已录制的工作坊所用的录制与直播信号链路——samber/dev-event-organizer-skills@event-production。它的故障面不同于学员笔记本电脑无法安装依赖的情况。你的讨论范围止于学员一侧的环境。

以下每项排序都只是默认方案，并非铁律；具体排序会因情境和执行者而异。访谈结束后，请结合你已了解的情况，重新排列全部四个选项菜单。以下任何一种情况都足以推翻默认排序中的某一级：

• 讲师已经在商业场景中举办过这场一模一样的工作坊。
• 你使用过某个场地四次，并测量过它的网络。
• 赞助方提供云环境。
• 学员使用由雇主管理的笔记本电脑。

访谈

一次只问一个问题，尽可能采用选择题。第 11 题之所以存在，是因为各选项在见效时间、持久性和投入方面的排序差异很大——不能替用户决定排序。

1. 此次交付中需要考虑哪一部分：单场活动的具体安排、工作坊日内所有活动的安排，还是对一场不顺利的工作坊进行复盘？跳过已经确定的选项菜单。
2. 结束时，学员必须能做到哪些现在还做不到的事？这些能力能否通过阅读材料获得，而不必在现场动手实践？
3. 练习是否需要在学员自己的设备上安装、下载或登录任何内容：软件、工具链、供应商账户？
4. 练习是否有任何环节依赖活动期间运行的在线服务，例如托管控制台、API、包注册表或远程实验环境？
5. 是否可以要求所有学员都自带能够运行相关内容的设备，并且允许在设备上安装软件？这样要求会不会将预期学员群体中的任何人排除在外？
6. 练习是否需要学员在不同的工作站或实体环节之间移动，还是所有人都在各自座位上做同样的事？
7. 预计有多少学员？教室实际能提供什么：座位、可移动家具、座位旁的电源？
8. 除了主讲人，教室里还有谁能提供帮助？他们熟悉课程内容，还是只擅长处理后勤事务？
9. 关于这间教室的网络，场地方是否已通过书面形式说明：持续带宽、可承载的设备数量，以及是否会屏蔽不常见的协议或设备类型？
10. 你作为组织者，是否会代表学员接受第三方平台的条款并为他们发放凭据？学员中是否会有未成年人？
11. 以下三点会重新影响所有排序，因此一并询问，因为它们只有放在一起才有意义：
    • 最迟必须在哪一天准备就绪。
    • 这是一次性的活动，还是每届都会举办的课程。
    • 投入上限是多少：组织者的工时、可以招募到现场的人手，以及选择需要具备多强的可逆性。
12. 往届活动中，是否发生过工作坊网络故障？具体出了什么问题——带宽不足、协议被屏蔽、某类设备被屏蔽，还是场地方始终没有答复？

动手实践承诺

第一个决定，也是最常被跳过的决定：本次活动是否要让参与者实际动手操作？排序（默认排序，并非铁律——Q2 和 Q9 会重新排序）：

• 投入（搭建、彩排、现场支持、活动当天的风险）：完整动手实践 > 仅演示 > 不进行现场动手实践
• 价值，参与者离开时能够独立完成这件事：完整动手实践 > 仅演示 > 不进行现场动手实践
• 价值，无论现场情况如何，都能交付内容：不进行现场动手实践 > 仅演示 > 完整动手实践
• 效率：不进行现场动手实践 > 仅演示 > 完整动手实践

⚠️ 这里的效率按成本从低到高排序。 不要把它当作默认选项：Q2 决定默认选项；只要阅读无法教会这项技能，完整动手实践就是首选。

• 不进行现场动手实践——材料以已发布资源的形式提供，或者以演讲的形式讲授。从交付方式来看，这等于_完全不开设工作坊_，在效率这一项中显然胜出：活动当天没有任何环节会出问题。黑客马拉松组织者早已倾向于这样做，不过原因不同——保护构建时间。MLH 的硬件指南搭建了一整套异步学习内容：“异步资源让学生能够在黑客马拉松开始前，按照自己的时间安排熟悉工具和概念。”同一份指南还告诉组织者：“限制活动期间的工作坊数量，因为它们会占用宝贵的构建时间。”注意这条界限：活动当天是否举办由 samber/dev-event-organizer-skills@event-format-selection 决定，这件事已经定了；本次活动_是否安排动手实践_由你决定。
• 仅演示——由讲师操作，参与者观看，无人需要安装任何东西。一台设备和一个网络连接都可能出故障，而两者都由你负责。
• 完整动手实践——仅在阅读无法教会相关内容时作为默认选项。MLH 的会前工作坊涵盖了参与者实际会用到的组件，并说明：“这涵盖了基础接线和必要的初始代码上传。”晋级条件取决于 Q2：对“能否通过阅读学会”的回答是否定的。
• 删除，不要降级：如果 Q4 表明练习需要实时网络服务，而下方的网络选项无法消除这一依赖，并且场地方在准备就绪日期（Q11）前拒绝书面答复 Q9，就从此菜单和上方的排序行中移除完整动手实践。场地方只是尚未答复时，应继续催促，而非删除。此时应改为演示并发布材料。让参与者无法连接的动手实践，正是这项技能要避免的具体失败情形。把已删除的选项留在列表底部，会导致活动当天它又以工作范围的形式出现。

引导人员配置

参与者卡住时，如何帮助其继续进行。排序（默认排序，并非铁律——Q6 和 Q8 会重新排序）：

• 投入（招募、说明、活动当天的协调）：每个工作区安排固定助手 > 流动排障人员 > 结构化同伴结对 > 仅由讲师负责

• 价值，参与者在放弃前获得帮助并继续进行：固定助手 > 流动排障人员 > 结构化同伴结对 > 仅由讲师负责

• 价值，随着现场人数增加仍能维持覆盖：结构化同伴结对 > 固定助手 > 流动排障人员 == 仅由讲师负责——固定助手排第二，因为每位助手负责一个步骤；随着更多人经过，他们会越来越熟练地回答同一个重复问题。对此存在一个有理有据的平局判断：活动当天，无论是流动排障人员还是讲师，面对人数不断增加的现场，能够解答问题的人数都在招募时就已固定，所以无论哪种方式，现场人数翻倍，分摊到每位参与者身上的帮助都会减半。增加助手以维持比例，就意味着重新招募，属于投入成本，而非规模增长。

• 效率：结构化同伴结对 > 流动排障人员 > 仅由讲师负责 > 固定助手 ⚠️ 第一个价值轴与工作量的排序一致。 恢复延迟确实是一个实际指标，但按它排列各档并不能区分出工作量排序未体现的差异；仅依赖它的效率曲线最终会变成按成本从低到高排列。成长轴则将同伴结对推到了顶端。延迟决定了巡回协助高于单人辅导：招来一位熟悉材料的人，只需增加少量工作量，就能缩短等待时间。

• 巡回排障人员——默认选项：MLH 告诉工作坊主持人，“安排一位备用讲者四处走动，为开始掉队的参与者排障”；对于远程课堂，则要“请他们共享屏幕，以便排查问题”。招募熟悉材料的人，而不是负责后勤的志愿者——Q8 会询问你能招募到哪类人。Carpentries 通过一项公开惯例来扩展这一档：“每 8-10 名学生配 1 名助教，不包括两位讲师”（其讲师培训将其概括为“至少 1:10”）；在线授课时则需要更多人。

• 有组织的同伴结对——效率领先者。按定义，其协助能力会随课堂人数增长，这正是它在成长轴上胜出的原因。CS 课堂中的结对编程教学法提供了具体机制，而非仅仅诉诸人数：分配驾驶员／导航员角色，每 5-10 分钟交换一次，让导航员在整个课程期间都盯着驾驶员的屏幕。“有组织”是关键。相同的指导将没有角色分工的普通结对称为“往往会导致一名或两名学习者很快失去专注”的做法——这正是此档自身未经管理时的失败模式，只是换了个名称。结对双方仍可能都卡住而无人察觉；应像巡回协助这一档那样，按固定频率检查各组情况。

• 每个工作区配备驻点助教——供不应求的选项：延迟最高，工作量也最高，因此效率轴永远不会选它。MLH 的工具站点建议“确保附近有一位导师驻点”，并要求“确保这些站点由经验丰富的志愿者值守”。晋升条件与 Q6 挂钩：练习确实分布在不同的工作站或物理上相互独立的步骤中，因此驻守某一处的助教可以帮助所有到达该处的人。

• 删除，而非降级：当动手环节菜单达到完全动手的状态时，立即从该菜单和上方的轴线中删除单人讲师。有人在课堂上做练习时，讲师可能正在讲解而无法及时帮忙；巡回协助以下的其他档位都无法解决这一问题。

分两步确定覆盖人数，并明确说明这两步：

1. 以以上 Carpentries 惯例为起点。这一惯例来自面向科学家的两天研究计算工作坊；课堂中已有两位讲师，助教也熟悉所用工具。引用时应说明这一背景。
2. 根据 Q6 和 Q8 调整：练习的故障点较多或课堂为远程形式时增加助教；只有一条线性流程时减少助教；不熟悉如何排障的人不计入人数。

切勿把黑客马拉松导师的人数作为工作坊配比。“每四名非专家参与者配一名左右”是为期多天的项目开发活动中，主题专家与项目的配比，而不是固定时段内的助教配比。

前置条件与环境

会话开始前，参与者的设备和账户必须满足哪些条件。排序（默认排序，并非一成不变——Q3、Q5 和 Q10 会重新排序）：

• 成本（构建、维护、支持两种方式还是一种）：同时提供两种路径 > 仅提供预配置环境 > 公布前置条件 > 未公布任何内容

• 价值，即实际上能够开始的参与者比例：同时提供两种路径 > 仅提供预配置环境 > 公布前置条件 > 未公布任何内容

• 价值，即会话进行期间不依赖现场网络的程度：公布前置条件 > 同时提供两种路径 > 仅提供预配置环境 > 未公布任何内容

• 合规成本（是否触发审查，以及可逆性）：仅提供预配置环境 == 同时提供两种路径 > 公布前置条件 > 未公布任何内容——有理有据的平局：这两个选项都会让你而非参与者代表一屋子人接受平台条款，并代他们发放凭据；在此基础上再提供第二种路径，并不会改变签署者是谁。

• 效率：公布前置条件 > 仅提供预配置环境 > 未公布任何内容 > 同时提供两种路径

• 公布前置条件——默认选项：DevOpsDays、PyCon US 和 SmashingConf 的研讨会页面都设有逐场填写的前置条件栏，Carpentries 则会在每场研讨会前发送安装说明。前置条件分为三类，具体内容列于 references/prerequisite-and-environment-sheet.md：已有知识、设备状态和账户。账户是最常被遗忘、也最容易在开场第一分钟出问题的一类。提供一份供参与者在活动前运行的检查，让他们确认工具、版本、操作系统和芯片架构，以及登录状态；并在一台全新设备上亲自试运行练习。

• 同时提供两种路径——参与者可自行选择使用本地设备 或 预配置环境。一场研讨会这样说明：“你可以选择在笔记本电脑上参加研讨会，也可以使用 GitHub Codespaces 和预配置环境。”准备度最高，成本也最高，因为你现在需要维护并支持两种环境。

• 仅提供预配置环境——资源匮乏时的选择：它彻底消除了硬件和安装权限方面的障碍。一场研讨会是这样说明的：“所有操作都在 Web 浏览器（Chrome、Firefox）中完成——笔记本电脑上不需要运行本地命令或安装任何内容”，并为每位参与者提供单独的登录凭据和预装了指定版本工具链的环境。升级为此选项的条件，以 Q5 和 Q10 为准：不能指望参与者拥有性能足够的设备，或他们无权在自带设备上安装软件，或要求参与者自备设备会排除部分目标群体。

• **删除，不要降级：**一旦 Q3 表示需要安装、下载或登录任何内容，就从这个菜单以及上方的排序项中删除 未公布任何内容。空白的前置条件栏意味着承诺什么都不需要；只有承诺属实时，才可以留空。

合规问题。 为一屋子人搭建环境，意味着你要代表那些从未阅读条款的人接受供应商条款，并发放和持有凭据。如果 Q10 表示有未成年人参加，那么这是替无法自行接受条款的人作出接受。请明确说明这会触发哪些审查：

• 平台关于第三方使用的条款。
• 你自己的凭据数据处理方式。
• samber/dev-event-organizer-skills@event-accessibility-inclusion 对参与者数据提出的同一项同意问题。

在可逆性方面，这些选项确实有所不同。这种不对称是此技能自身提出的论点，而非已有发表观点：你可以按自己的时间安排拆除自己搭建的环境；参与者按你的要求创建的账户，在你退出后仍会存在，而你无法代他们删除。

容量：三项上限，取最低值

这里故意不做排名。 这是对同一个数字设定的三项上限，并非价值不同的备选方案。哪一项起限制作用，取决于你的练习和场地，而不是能通过效率比来选择，因此排名会造成虚假的精确感。计算这三项，取最低值，并说明是哪一项起了限制作用。

• 场地上限——现有家具布置下，场地能容纳的人数。技术活动分组讨论室的常见容量范围是 10-20 人或 20-40 人，椅子可以移动成圆形（参见 samber/dev-event-organizer-skills@event-venue-sourcing 的空间规划）。电源与座位数是两个独立问题：Carpentries 要求「为所有参与者提供电源插座」，Smithsonian 的 Carpentries 主办方检查清单则按「每 3 名学员配一个电源插排」进行预算。
• 辅导覆盖上限——讲师加上通过引导师选项菜单招募的人员，实际能辅导多少人，才不会有人放弃。将上文的配比反过来计算：有能力的帮手人数乘以 8 到 10，仅适用于两位讲师授课的情况，之后再应用你的调整。只有一位讲师时，练习期间按一位帮手的覆盖能力计入讲师，并将结果标注为自行设定。说明哪些是惯例，哪些是你自己的设定。
• 练习吞吐量上限——受真正有限的资源约束，能让多少人获得实际动手练习的时间：套件、每位参与者的登录账号、许可证席位、实体工作站。这是最常被忽视的一项上限，因为只有当第 21 位参与者需要第 9 块开发板时，它才会显现出来。

2017 年某个工作坊日采用过一种低成本做法：提前请参与者「为你最喜欢的工作坊投票」，并说明「这将帮助我们决定把它们安排在哪些房间」。提前收集需求，胜过排期时的猜测；而且只需在 samber/dev-event-organizer-skills@event-attendee-email-sequences 已发送的活动前邮件中，顺手加入这项请求即可，成本很低。

对于免费场次，要为报名者未到场的情况做好准备：设置候补名单，并在场次开始时放出无人认领的席位。超额报名人数应根据你上一届测得的缺席比例来确定，绝不要照搬别人的比例。

场次时长应以观察为准，而非规定。会议中的有日期记录的动手实践场次时长为 150-180 分钟，而已发布的时段菜单也提供 45 到 120 分钟的选项。设备检查时间计入场次时长；较长的时段应拆分成多个部分并安排休息，就像一份 180 分钟的议程中安排的「四个 45 分钟环节」一样。包含每个工作坊对应活动和时长的完整清单，见 references/capacity-length-and-network-evidence.md。将选定的时长作为输入交给 samber/dev-event-organizer-skills@event-schedule-design；不要通过对不同活动的时长取平均值来决定时段长度。

网络与依赖情况

在亲身吃到苦头之前，先想好如何应对教室的网络状况。排序如下（默认排序，并非铁律——Q4 和 Q9 会重新排序）：

• 成本（协调工作、场地压力、接受设计约束）：移除实时依赖 > 以书面形式确认教室网络情况 > 声明依赖并提供备用方案 > 假设网络正常
• 价值，即使教室网络状况不佳，课程仍能进行：移除实时依赖 > 以书面形式确认教室网络情况 > 声明依赖并提供备用方案 > 假设网络正常
• 价值，即使没有网络，练习仍能教授相关主题：假设网络正常 == 声明依赖并提供备用方案 == 以书面形式确认教室网络情况 > 移除实时依赖——前三者之间存在合理的并列：它们都不会改变练习可以包含的内容；它们的区别仅在于你事先了解什么、说明了什么。只有第四种做法会从可教授内容中删去主题。
• 效率：声明依赖并提供备用方案 > 以书面形式确认教室网络情况 > 假设网络正常 > 移除实时依赖

⚠️ 弹性轴的排序与成本轴相同。 只有内容轴会区分不同层级，这也是移除依赖排在最后而非最前的原因。

• 声明依赖并提供备用方案——默认选项，几乎不费力：一个工作坊会说明“需要互联网，因为我们将使用基于云的 ClickHouse 实例”；另一个工作坊要求连接互联网以访问远程实验环境，并明确说明参与者侧的备用方案“（使用 Wi-Fi 或自己的移动数据）”。这种备用方案会把成本转嫁给参与者，而且漫游数据会让部分国际参与者无法使用；发布信息时请说明这一点。导致这类课程无法进行的，往往是策略限制，而非带宽不足：VPN、广告拦截器或被封锁的协议都可能造成问题。共用出口也会如此：四十台笔记本电脑共用一个场地 IP 地址，可能会同时触发注册表的匿名拉取限额或 API 密钥配额。具体原因列于 references/capacity-length-and-network-evidence.md。
• 以书面形式确认教室网络情况——推广使用的条件，与 Q9 和 Q4 对应：练习需要不常见的协议、端口或设备类别，或者场地尚未回复——此时应跟进确认。造成问题的是策略限制，而非容量不足：MLH 建议组织者与场地基础设施团队合作，并“确保网络允许 IoT 和其他设备接入，因为标准的大学网络通常会封锁这些设备”；某个已发布工作坊的先决条件也明确要求“（允许 RDP 协议）”。向场地提出 samber/dev-event-organizer-skills@event-venue-sourcing 中已列出的问题，并询问设备数量和协议列表。
• 移除实时依赖——最受限的选项：弹性最高、成本最高，也是唯一会牺牲内容的层级。推广使用的条件：场地拒绝回答 Q9、上一届活动的教室网络曾发生故障（与 Q12 对应），或者主题确实不需要网络。两项成本低的配套措施：
  • 请参与者提前下载，并附上 MLH 给出的理由：“鼓励黑客提前下载软件驱动程序和 IDE，以减少活动期间的网络负载”。
  • 携带一套离线工具包进入教室。较早的 Software Carpentry 讲师建议清单列出了装有课程文件和安装程序的 USB 闪存盘，“以防教室 WiFi 无法承受负载”，还建议携带 WiFi 集线器，“以防教室网络无法正常工作”。这是唯一能在课程进行中使用的备用方案。
• 删除，不要降级： 每当 Q3 或 Q4 表明参与者必须在课程期间下载、安装或进行身份验证时，都应从此菜单和上方的轴说明中删去 假设网络正常。全班同时安装属于负载情况，而非假设——要求提前下载，正是为了消除这种情况。

现场及结束之后

用于当天执行的工作坊机制——详情和反面示例请参阅 references/coverage-and-room-mechanics.md：

• 在计划中预留恢复时间，而不是寄希望于时间刚好够用：“在日程中安排时间，用于分组讨论、故障排查和提问”。
• 即使已提前发送先决条件，也要先检查设备。较早的 Software Carpentry 建议安排“至少 20 分钟检查学员的设备”，并提醒设置可能需要 30-60 分钟，“因为无论如何都会发生”。先决条件可以缩短这段时间，但绝不能将其取消。
• 根据现场人数安排开场：“对于参加人数较少的工作坊，我们建议从破冰活动开始”。
• 降低承认自己遇到困难的心理负担。MLH 明确将此责任交给讲师：“充分意识到代码审查和提问会让参与者感到多么有压力”。
• 发放两种颜色的便利贴，作为 Carpentries 的求助标记：一种颜色贴在笔记本电脑屏幕上表示“我需要帮助”，另一种表示“已完成”。这种标记比举手“更不显眼”，学员可以继续操作，而教室前方的人也能一眼看出全班的情况。他们的讲师培训建议使用蓝色和黄色，而非红色和绿色，以照顾色盲参与者。
• 告知助教：“只要条件允许，就应由学员自己敲代码”。没有这条规则，助教就会接过键盘，参与者也无法从修复过程中学到任何东西。
• 为每项练习提供一个检查点：为每个步骤准备带标签的分支或解决方案文件夹，这样遇到困难的参与者就能在下一步重新跟上，而不是进一步掉队。
• 将讨论环节分成每组约 10 人的小组，每组各设一名召集人；不要让全场一起讨论。samber/dev-event-organizer-skills@event-format-selection 中的开放空间小组机制介绍了详细做法。
• 为材料提供一个后续存放之处：“在 Slack/Discord 上建立一个频道，让参会者在工作坊结束后就主题提出后续问题。”公布访问期限（两个已公布的实例：72 小时，以及会议结束后一个月）。

失败模式

• 照搬比例，却忽略适用条件。 Carpentries 提出的每 8 到 10 人配 1 名指导者，前提是有两名指导者和能排查工具问题的助教。一个 40 人的场地里有 4 名后勤志愿者，虽然人数比例达标，却无法提供任何技术支持。应同时说明这一惯例、适用背景和你的调整方案。
• 先决条件只列软件，忘了账号。 已发布的工作坊通常会要求 GitHub 账号、供应商注册账号或免费产品账号，就像要求安装软件一样。注册账号需要完成注册、确认电子邮件，有时还要通过雇主的 SSO；这一切都要在活动开始时、借助场地网络，同时为所有人完成。
• 把预配置环境当作安全选项。 它消除了本地安装失败的风险，却让整个活动完全依赖场地网络，还会带来上述合规风险。它只对你明确列出的那些故障更安全。
• 照抄其他活动网页上的时长。 每场活动的时长都取决于场地、参与者群体和练习。可以借鉴形式，但不要照搬数字。
• 接受场地方对 WiFi 的回答：“没问题”。 实际的网络故障往往由策略造成，例如屏蔽某类设备、屏蔽某些协议、要求使用 VPN 或启用广告拦截器；单看带宽数据无法发现这些问题。
• 在超过约 10 人的工作坊中安排全场讨论。 轮流发言一圈就会耗尽整个时段，而且一半安静的参与者始终不会发言。解决办法：分成每组约 10 人的小组，每组安排一名召集人（§ 在现场及活动之后）。
• 重新讨论形式选择。 如果讨论偏离主题，开始争论是否应该举办工作坊日或该如何定价，那属于 samber/dev-event-organizer-skills@event-format-selection，而且这件事已经决定。
• 混淆参与者侧故障和活动制作故障。 如果全场笔记本电脑都无法安装依赖项，这是你的问题；如果录制画面中的摄像头画面中断，则属于 samber/dev-event-organizer-skills@event-production。

衡量指标

选择两到三个指标。提前决定什么结果会促使你调整下一届活动，并在活动开始前写下指标及其触发条件。

• 开始时准备就绪情况（自行设定）：参与者在到场前完成先决条件的比例。这个数字能告诉你是否应提高先决条件的要求；你可以通过活动前的检查结果获取，也可以在入口处询问。
• 活动前后的信心（有来源的惯例）：针对所教的具体技能，简短询问“我有信心……”，在活动开始前和结束时各进行一次。这是此处唯一有明确先例的指标。Carpentries 在数千场实操技术技能工作坊中，准确使用了这组前后调查。其 2018 年 Data Carpentry 前后调查报告显示，使用编程处理数据的信心“从 33% 上升到 61%”。这一先例针对的是面向科学家的研究计算培训，而非开发者会议；它衡量的是自我报告的信心，而不是观察到的任务完成情况。借鉴这种做法，不要照搬这个数字。
• 开始人数与完成人数（自行设定目标）：到达最后一个练习的参与者人数。在每个练习处记录“完成”标记，了解有多少人中途掉队。如果差距很大且现场人数充足，说明需要更多支持；如果差距很大且现场人数较少，说明先决条件有问题。
• 求助响应时间（自行设定目标）：求助标记持续显示的时长。自行设定目标。等待时间过长，说明应提高支持力度，为参与者安排能力更强的助教。
• 活动后材料使用情况（自行设定）：在你公布的时间范围内，已发布材料的访问量。这也是检验 不安排现场动手实践 这一档是否可行的有效方式——如果材料本身就能支持学习，那么现场活动并非必需。
• 单独售票的工作坊日售票情况属于 samber/dev-event-organizer-skills@event-format-selection，不在此处讨论。

调用示例

• “我们有一场面向 40 人的 Kubernetes 三小时工作坊。需要多少名协助人员？要让参会者安装什么？”
• “去年的工作坊当天，场地 WiFi 在安装环节时断了，整个活动乱了套。今年要避免这种情况。”
• “我们应该采用动手实践的形式，还是只录制演示并发布代码仓库？”
• “为我们的 LLM 工作坊编写先决条件部分——练习需要使用云控制台和供应商账号。”

预期输出：每场活动一份交付清单，其中包括：

• 动手实践的安排及原因；
• 容量数值，以及受哪项或哪些上限约束；
• 引导人员的配置，以及说明人数依据；
• 先决条件，分为知识、机器状态和账号；
• 网络方案，以及场地给出的答复；
• 材料，以及材料的可用时段；
• 下届活动中会触发各项选择调整的条件。

按章节逐项呈现，以便验证，不要合并成一个整体。

如果你的执行环境支持持久记忆，请记录实际约束容量的数值及其对应的上限、最终提供的先决条件清单、当天实际出现的问题，以及场地提供的书面网络答复。下届活动从这些记录开始，而不是重新推导。

参考资料

• references/coverage-and-room-mechanics.md - 四个引导覆盖级别的详细说明、教室内及工作坊后的机制与反例，以及导师模式对比。
• references/prerequisite-and-environment-sheet.md - 先决条件文档：三类内容、预配置环境和双路径级别、材料及其访问时段、合规审查触发条件，以及一个填写示例和一个反例。
• references/capacity-length-and-network-evidence.md - 三项上限、通过需求投票分配教室的机制、已发布的活动时长及其对应活动、密度比例及其注意事项，以及列明的现场故障原因。

另请参阅同一合集中的内容：

• samber/dev-event-organizer-skills@event-format-selection - 决定是否安排工作坊日或专题分会场、其前后安排模式及票务；本技能将这些视为既定条件。
• samber/dev-event-organizer-skills@event-schedule-design - 将活动安排到日程表中，并为其设置缓冲时间；它会采用本技能确定的容量和时长。
• samber/dev-event-organizer-skills@event-talk-selection - 跨活动形式筛选提案；对于动手实践提案，应判断讲师能否在所提供的容量下开展活动，以及练习能否扩展规模，这正是本技能关注的问题。
• samber/dev-event-organizer-skills@event-venue-sourcing - 将本技能生成的工作坊专属场地、电力和网络要求作为场地寻源的输入。
• samber/dev-event-organizer-skills@event-accessibility-inclusion - 制定便利措施和参会者数据的标准，包括发放给整个教室的凭证。
• samber/dev-event-organizer-skills@event-volunteers - 招募并培训引导人员配置方案所需的人员，并负责处理本技能所依赖的后勤与内容分工。