virtual-event-production

虚拟活动制作

你负责交付一场没有场地的活动。软件平台就是场地，每位参会者自己的网络连接就是上行链路，团队则由主持人名单和远程演讲者流程组成，而不是舞台工作人员。把活动形式视为已确定：samber/dev-event-organizer-skills@event-format-selection 已经选定完全虚拟。不要重新争论这个选择。

场地消失之处

此边界仅从你的角度撰写。请确认这一点，不要暗示双方已商定交接。

samber/dev-event-organizer-skills@event-production 负责任何需要布置实体场地的活动，从采集到发布母版的全过程，包括该场地可能产出的任何直播内容。其职责止于录制或直播输出。

只有在场地存在时，其整套模式才有意义：调音台、拍摄调音台画面的摄像机、盯着监视器的工作人员、舞台监督，以及以场地后方智能手机为标准命名的覆盖等级。你从场地彻底消失之处开始负责。

• 采集。 对准实体舞台的摄像机属于 samber/dev-event-organizer-skills@event-production 的信号路径，而非你的职责，即便观众是远程的也是如此。负责没有舞台可供拍摄的情况。
• 远程参会者的一天。 samber/dev-event-organizer-skills@event-attendee-experience 将范围限定为“普通参会者的现场体验”，并将所有机制（徽章领取台、路线指引、安静室）都与已签署的场地图关联，因此对远程参会者的体验只字未提。在此覆盖这部分对应内容；该技能并不知道此技能的存在。
• 频道架构。 samber/dev-event-organizer-skills@event-comms-channels 负责确定有哪些频道、谁在哪个频道，以及哪类消息发送到哪里，适用于远程和现场参会者。沿用其人员名单。只添加活动进行中的提问界面及负责监看的人员配置，并沿用其关于持续主持成本的论据，而不是另行推导一遍。
• 演讲者关怀。 samber/dev-event-organizer-skills@event-speaker-experience 负责端到端的演讲者关系，包括你不得逾越的录制同意记录。其技术检查针对“实际舞台设备”，绿房也是实体空间，因此远程连接测试、家庭设备指导和本地备份录制由你负责。将结果交回。
• 活动当天。 samber/dev-event-organizer-skills@event-run-of-show 会制作一份以场地、场地负责人和仅供组织者使用的频道为依据的流程单。一个专供组织团队使用、与所有面向参会者的频道分开的协调频道，可原样延用于虚拟活动。与场地关联的流程单的其他内容则不适用。
• 无障碍。 samber/dev-event-organizer-skills@event-accessibility-inclusion 决定是否需要字幕以及适用何种标准。在平台上提供字幕，并报告平台能做和不能做的事情。切勿自行设定标准。

以下所有排序都是默认值，并非铁律。访谈后，请结合你已了解的信息，重新排列全部四组菜单。以下每一项都会推翻一个默认层级：

• 已经在聊天空间中活动的社群
• 有过直播经验的组织者
• 雇主或赞助商已付费购买的平台
• 曾经发生过直播流中断的上一届活动

以下每个升级条件都在自身文本中注明了对应的访谈问题；“或”列表中的每个触发因素也各自单独对应问题，而非依附于第一个触发因素。切勿从上方的重新排序列表中获取条件：那是一条常设指示，并非访谈收集到的答案。四个 删除 项有意不引用任何问题——无论用户如何作答，它们都会基于同一论据无条件删除。

访谈

每次只问一个问题，尽量采用选择题形式。之所以有问题 7–9，是因为各菜单在见效速度、持久性和投入上的排序差异很大，不能替用户做决定。

1. 是否存在任何互动界面，还是说这是一个供人观看的信息流？ 这会重新排列下面的所有菜单，并决定菜单 3 是否存在。
2. 同时运行多少场活动，它们之间最短的间隔有多长？
3. 演讲者和观众分别在哪里——都在同一个时区，还是分布范围很广，以至于有人要在半夜演讲？
4. 关于形式的决定向谁承诺了什么：付费虚拟门票、注明直播的赞助商交付内容，还是为无法前往现场的人提供参与机会？
5. 每场活动的录制和发布授权情况如何，记录存放在哪里？与会者会在任何地方出镜吗——分组讨论、社交交流室或问答环节？
6. 是否有任何因素限制与会者数据的存储地点或可使用的平台——雇主的采购规定、赞助商合同或上级组织的规则？
7. 平台选择最晚在哪一天还能更改？这些菜单的排序依据是这个截止日期，而不是活动日期。
8. 是一次性活动，还是定期举办的活动？如果是定期活动，凡是收益要到本届之后才显现的选项都应优先考虑：经过排练的团队、成熟的备用方案，以及明年可以再次发送的家庭设备设置说明。
9. 投入上限是多少——活动期间有多少人可以只负责制作，而不兼做其他工作？活动结束后一周，还有谁能参与？
10. 现有哪些情况应当改变这些默认排序：观众已经使用的聊天空间、曾经负责过直播的组织者、有人已经付费的平台，或上一届活动的失败经验？
11. 哪些场次无法重办或改期，哪些包含现场演示，哪些演讲者的网络连接情况未知，或从未在这个平台上演讲过？ 上面的其他问题都无法了解场次的具体内容或其失败后果有多严重，而下面有四个选项正是因此应优先考虑。

实际影响决策的因素

社区运营还是供应商运营，对这里的影响没有看起来那么大。无论活动由谁资助，一个数据包传输所需的毫秒数都相同。它真正影响的是 Q6：供应商运营的活动更可能一开始就因采购要求而被指定使用某个平台，这会删掉某个选项，而不是重新排列顺序。

两个答案会依次重塑所有菜单：是否存在互动界面，然后是同时运行多少场活动。

• 如果只有一个关闭评论的信息流，那就是一场广播，几乎不需要做什么。
• 如果有三个同时进行的分会场且聊天开放，那么首先要解决的是人员配置问题，而不是技术问题。

只要两者的假设不同，就要说明建议分别基于上述哪一种情况。

工作流

1. 用一句话确定互动形式——是人们观看的直播流，还是人们置身其中的活动。先把它写下来；下面所有菜单都由此决定。
2. **阅读已有输入，而不是重新收集：**频道名单、每位发言者的同意记录、无障碍标准，以及形式决策所承诺的内容。
3. 选择平台形式（菜单 1），然后将供应商问题列在 references/platform-selection-and-vendor-questions.md 中，提交给能回答的人，并在做出承诺前获得书面答复。
4. 选择远程发言者准备程度（菜单 2），并在发出录用通知的当天发送家庭设备设置说明。详情见 references/remote-speaker-readiness.md。
5. 安排主持人员（菜单 3），按每场并发会议逐一安排，并明确到具体人员，而非只指定职能。如果第 1 步确定的是“人们观看的直播流”，则完全跳过此步骤。
6. 选择故障演练的深度（菜单 4），并在活动当天之前，将备用说明发布到观众会查看的位置。操作手册见 references/moderation-and-failure-drills.md。
7. **在活动实际使用的平台上排练一次。**这一步最容易被删掉，而在其他工具上排练毫无意义。
8. 将成本影响交给 samber/dev-event-organizer-skills@event-budget，并按精简级别会舍弃的内容拆分：直播流本身在所有级别中都会保留；互动界面及其所需人员最先被削减。
9. 活动结束后，将录制的场次交给 samber/dev-event-organizer-skills@event-content-repurposing，并将录制同意情况交回 samber/dev-event-organizer-skills@event-speaker-experience 检查。

按章节逐一展示计划以供确认——互动形式、平台、发言者、主持人员安排，然后是演练——在签署任何合同之前完成。签署后，更换平台就要花钱，而不只是沟通一下。

如果你的运行环境支持持久记忆，请按每届活动记录：

• 选择了哪种平台形式，以及供应商实际给出了哪些答复
• 哪些发言者需要哪一级准备支持
• 有多少主持人确实忙于工作，多少人处于空闲状态
• 每次故障及其被哪项演练发现
• 直播流中断后的几分钟内观众采取了什么行动

同一平台用过两次，就不必再重新摸索。

菜单 1 - 平台形式

平台就是你的场地。像评估场地一样给它排序：获取平台的成本、运行平台的成本，以及它实际上为观看者带来的价值。

排序（默认顺序，并非定律——Q1、Q6、Q7 和 Q10 会改变排序）：

• 运营投入（设置所需时间、活动当天所需人手、所需技能）：组装式方案 > 托管式虚拟会场平台 > 内置提问队列的直播工具 > 单向直播加现有聊天空间 > 单一单向直播
• 采购成本（获取所需时间、签署的承诺、截至活动日期的可撤销程度）：托管式虚拟会场平台 > 内置提问队列的直播工具 > 组装式方案 == 单向直播加现有聊天空间 > 单一单向直播——有理由的并列：两者都是由你可以在同一周内启用并放弃的工具组装而成，没有签署任何协议。组装式方案的实际成本是时间，而这已经计入上面的运营投入；现有聊天空间是出于其他原因采购的，此决定不会让你进一步承诺使用它。
• 价值、覆盖范围（可观看、可听见的演讲通过某人的家庭网络送达）：单一单向直播 == 单向直播加现有聊天空间 > 内置提问队列的直播工具 > 托管式虚拟会场平台 == 组装式方案——顶部有理由的并列：聊天空间位于直播之外，而不是其中，因此不会增加视频传输路径必须承载的内容。底部有理由的并列：两者都要求观众登录并使用专用播放器，而不是使用公开视频平台的传输服务，而且都会在演讲者和观众之间增加环节。
• 价值、互动（参会者实时联系演讲者和彼此）：托管式虚拟会场平台 > 组装式方案 > 单向直播加现有聊天空间 == 内置提问队列的直播工具 > 单一单向直播——有理由的并列：一种方案提供参会者之间的交流，但不对问题进行管理；另一种方案提供经过管理的问题队列，但没有同伴交流空间。两者都无法兼得，而哪一种更有价值取决于 Q1 的答案，而不是这个排序。
• 合规成本（触发的审核，以及哪些事项将不再可撤销）：托管式虚拟会场平台 > 组装式方案 > 内置提问队列的直播工具 == 单向直播加现有聊天空间 > 单一单向直播——有理由的并列：两者都只在一个供应商的聊天记录或提问记录中保存参会者身份信息，不会创建可供第三方导出的目录。最高一档则有本质区别：参会者目录和面向赞助商的潜在客户信息采集会在签约前触发数据处理审核，而赞助商已经导出的名单则无法收回。组装式方案位居第二，因为你自行选择各个组件的管辖范围，因此需要由你负责审核，而不是由供应商的条款代为审核。
• 效率：单一单向直播 > 单向直播加现有聊天空间 > 托管式虚拟会场平台 > 组装式方案 > 内置提问队列的直播工具

支配关系检查：5 个档位、10 个配对、4 个成本与价值维度加合规性，存在 1 组真正的严格支配关系。

• 单向直播加现有聊天空间严格支配内置提问队列的直播工具：运营投入更低、采购成本更低、合规性持平、覆盖范围更好、互动性持平。支配关系要求在每个维度上都不差，且至少一个维度更好；这两项持平也属于该关系的一部分，并非缺项，因为这组方案在 3 个维度上严格更好。

• 其余 9 组中有 8 组受互动维度与投入相反的排序所阻碍：能够提供交流的档位，获取和运营成本都严格更高。其中有 1 组，即直播工具与组装式方案的对比，受到双重阻碍，因为采购成本与运营投入的排序也相反。

• 最后一组，即托管式平台与组装式方案的对比，受采购成本和合规性与运营投入及互动性的排序相反所阻碍：托管式平台的运营负担更轻，但承诺成本更高。

• 以上涵盖全部 10 组配对（1 组支配关系 + 8 组 + 1 组）。 关于覆盖轴的一条警告。 单独来看，它的排名几乎与反向努力程度完全一致，会让这个菜单退化为按最低成本排序，而排名规则存在的目的正是防止这一点。只有交互轴的方向与之相反时，它才有存在的意义，因为这能让菜单形成真正的支配关系，而不是一项空洞的检查。

• 单向直播流加现有聊天空间——默认选项。直播流发布到公开视频平台；对话则在 samber/dev-event-organizer-skills@event-comms-channels 已设计的空间中进行，无需第二次登录，也无需第二份名单。

  **只要 Q9 表明无人能在会议期间看管聊天，就降级为单一单向直播流：**以活动名义开放一个空间，却无人值守，这就成了一项没有响应者的行为准则义务。已发布的数字骚扰警告同样适用于这种情况，就像适用于有工作人员值守的会议一样。

• 单一单向直播流——最低可行方案，而且它胜出的情况比看起来更多。关闭评论，不需要账户，无需审核，页面上合规风险最低，也最能确保使用手机的参与者顺利观看。

  对于远程观众只想听讲座、不想社交的活动，这是诚实的选择。这并不等于“没有举办虚拟活动”——这个决定应由 samber/dev-event-organizer-skills@event-format-selection 负责。

• 内置提问队列的直播工具——严格来说已被上方选项支配，但仍保留在菜单中的唯一理由是：Q6 可能会表明它已经被选定并付费。既然已经有了，就使用它，并把省下的决策精力用于菜单 3。

• 拼装式技术栈——独立的直播软件、独立的聊天平台、独立的日程页面，由你把它们拼在一起。起步成本低，也容易更换；其全部代价就是组织者投入的时间，以及各组件之间的衔接问题。

  Major League Hacking 的警告在这里完全适用：办好一场数字活动，远不只是搭建一个聊天服务器。这是针对黑客马拉松技术栈的黑客马拉松组织者警告，因此应将其理解为对低估工作量的提醒，而不是对这些组件的否定。

• 托管式虚拟会场平台——被冷落的选项：交互性最高、运营投入最高、采购要求最高、合规成本最高，因此效率排序永远不会选中它。仅在以下条件下提升优先级，各条件分别对应：

  • 多场会议同时进行，参会者需要在会场间移动，对应 Q2（“有多少场会议同时进行”）
  • 赞助商交付内容指定虚拟展位，或将参会者名录作为门票权益出售，两者均对应 Q4（“付费虚拟门票、赞助商交付内容指定直播流”）
  • 采购限制导致别无选择，对应 Q6（“允许使用哪个平台——雇主的采购规定、赞助商合同”）

• 删除，而非降级：第二个承载相同会议内容的并行直播平台。 从此菜单和上方的轴说明中将其删除。它会让每个讲者回答问题时的观众数量减半，并使审核工作翻倍；而问题只会表现为有一半观众始终没有得到答复。

菜单 2 - 远程讲者就绪度

远程讲者的上行网络是你无法控制、也无法检查的家庭互联网连接。下面的每个等级要么降低连接故障的概率，要么让故障能够承受。

排名（默认排序，并非定律——Q3、Q4、Q8、Q10 和 Q11 会重新排序）：

• 耗费精力（组织者投入的工时、安排与协调每位演讲者的工作量）：单独进行技术检查并指导演讲者本地备份录制 > 按计划播放预录演讲 > 安排一次全体共享的技术检查时段 > 提供书面居家设置说明 > 提供幻灯片和加入链接
• 价值，保障性（无论演讲者的网络连接如何，都能进行一场可用的演讲）：按计划播放预录演讲 > 单独进行技术检查并指导演讲者本地备份录制 > 安排一次全体共享的技术检查时段 > 提供书面居家设置说明 > 提供幻灯片和加入链接
• 价值，现场感（让场次感觉是现场进行的——演讲者在场、即时回应，并在演讲中回答问题）：单独进行技术检查并指导演讲者本地备份录制 > 安排一次全体共享的技术检查时段 == 提供书面居家设置说明 > 提供幻灯片和加入链接 > 按计划播放预录演讲 - 有理有据的并列：两者都能让演讲者充分熟悉流程，不必在开场几分钟里才摸索界面；但两者都无法像在有人旁观的情况下实际讲过一次那样让人安心。
• 合规成本（触发的审核，以及因此不再能撤回的事项）：按计划播放预录演讲 > 单独进行技术检查并指导演讲者本地备份录制 > 安排一次全体共享的技术检查时段 == 提供书面居家设置说明 == 提供幻灯片和加入链接 - 有理有据的并列：这三项都不会生成文件，因此除了活动本身已有的录制要求外，都不会在同意记录中增加任何内容。以上两档会生成文件；文件一旦存在，之后就会有人询问能否发布；应在文件生成前，将相关事项纳入 samber/dev-event-organizer-skills@event-speaker-experience 的同意记录，而不是事后补上。
• 效率：提供书面居家设置说明 > 安排一次全体共享的技术检查时段 > 单独进行技术检查并指导演讲者本地备份录制 > 按计划播放预录演讲 > 提供幻灯片和加入链接

支配关系检查：5 个档位，10 组配对，两个成本轴和两个价值轴，严格支配关系为零。

• 十组配对全部由两种机制构成，且两者覆盖的配对并不重叠。

• 六组配对之所以不成立，是因为准备工作的协调成本严格更高，同时两个价值轴都能获得提升：包括现场交付各档位之间的所有比较，以及它们分别与不采取行动的档位之间的比较。六组中的五组在两个价值轴上都严格更优；第六组，即全体共享时段与居家设置说明之间的比较，保障性严格更高，而现场感持平。即使存在这种平局，也足以阻止支配关系成立，因为成本更低的档位并未在任何价值轴上获得提升。

• 另外四组配对则特定地受预录机制所带来的取舍影响：它以牺牲现场感来换取确定性，因此与它比较的每个档位相比，它的保障性更高、现场感更低；这也包括它同时更便宜的那组配对。

• 支配关系为零，说明此项检查没有发现排序错误；后续内容是论证，而非验证。

• 书面居家设置说明 - 默认方案：与加入链接一同发送，可异步阅读、可在下一届重复使用，演讲者只需花几分钟。它能在安排通话前解决最常见的问题——多人共用网络连接、后台同步占满上行带宽、笔记本电脑摄像头对着天花板。

  内容见 references/remote-speaker-readiness.md。只要有演讲者从未在该平台上进行过演讲，就上调一档——此条件对应 Q11（“哪些演讲者的网络连接情况未知，或从未在该平台上进行过演讲？”）。

• 一次共享的集体技术检查时段——所有人同时加入真实平台，并且在活动当天之前留出足够时间，以便仍能修复检查中发现的问题。它只占用一个组织者时段，而不是每位演讲者各占一个；还能一次性发现平台范围的问题，而不必反复发现。

• 个人技术检查加上有指导的本地备用录制——为每位演讲者安排一个时段，在真实平台上进行，结束时确保演讲者已做好当天本地录制的准备。重点在于本地录制：如果直播流中断，损失的只是现场环节，而不是演讲。提升优先级的条件，均对应 Q11，这是唯一能触达这些条件的问题：

  • 无法重办的环节（“哪些环节无法重办或改期”）
  • 连接情况未知或已知不佳的演讲者（“哪些演讲者的连接情况未知”）
  • 包含现场演示的演讲（“哪些环节包含现场演示”）

• 按计划播放预录演讲，演讲者同时在线参与聊天——这是最缺乏优势的选项：保障能力仅次于最强，投入也接近最高，实时性却最低，因此效率考量永远不会选它。它的先例是 ACM SIGCHI：该组织完全取消了远程参会，并为无法前往现场的作者提供预录视频，在现场观众面前播放。不能照搬的是场景：那是线下活动为无法到场的作者提供的便利，并非虚拟活动的默认做法。提升优先级的条件分别对应：

  • 环节安排在演讲者半夜进行，对应 Q3（“时区跨度大到有人要在半夜演讲”）
  • 现场演示已经失败过一次，对应 Q11（“哪些环节包含现场演示”）以及 Q10（“上一届的失败情况”）
  • 演讲者完全无法参加现场时段，对应 Q11（“哪些演讲者的连接情况未知”）

  ACM 自己的管理委员会会议纪要记录了其某次会议的远程演讲缺席情况：演讲者没有出现，正是这一层级旨在消除的问题。

• **删除，而非降级：在与活动实际使用工具不同的工具上进行技术检查。**将它从此菜单和上方的轴线中删除。它看起来像是检查，却测不到任何重要事项：既测不到平台的屏幕共享路径，也测不到其音频设备处理方式，更测不到演讲者的浏览器在该平台上的表现。samber/dev-event-organizer-skills@event-speaker-experience 从实体舞台的角度提出了同样的要求——检查实际使用的设备——这里的道理完全相同。

菜单 3 - 现场主持人员配置

**如果菜单 1 最终选择了单向直播流，则完全跳过此菜单。**没有互动界面，就没有需要主持的内容；不存在高于最低配置的层级，也就无需讨论人员配置。以下内容均假设已开放一个互动界面。

开放空间的常规成本已由 samber/dev-event-organizer-skills@event-comms-channels 论证过：设置需要一小时；空间开放期间，主持工作始终需要有人负责；其中的行为准则职责与房间内完全相同。不要重新推导。这份菜单只增加该技能未涵盖的_现场环节内_层面：谁将问题转达给看不到聊天内容的演讲者，以及谁会注意到直播流中断。

排序（默认排序，并非铁律——Q1、Q2、Q9、Q10 和 Q11 会改变排序）：

• 人力投入（每场每小时值守的人数）：信息版主、技术监看员和 feed 主持人 > 信息版主加技术监看员 > 每场并行活动配一名信息版主 > 整场活动配一名信息版主 > 不安排信息版主
• 价值：空间有人值守（问题能传达给演讲者，并在违规行为发生之处执行行为规范）：信息版主、技术监看员和 feed 主持人 > 每场并行活动配一名信息版主 == 信息版主加技术监看员 > 整场活动配一名信息版主 > 不安排信息版主——争议性并列：技术监看员不会阅读聊天。这两个层级的信息审核能力完全相同；增加的第二个人只服务于另一个价值维度。
• 价值：打破沉默（故障发生当分钟内就被发现并告知观众）：信息版主、技术监看员和 feed 主持人 > 信息版主加技术监看员 > 每场并行活动配一名信息版主 > 整场活动配一名信息版主 == 不安排信息版主——争议性并列：一个人无法同时监看多个流的状态，因此当并行活动不止一场时，整场活动的那名信息版主发现直播流中断的时间不会早于无人值守的情况。
• 合规成本（触发的审查，以及哪些事情将无法挽回）：不安排信息版主 > 整场活动配一名信息版主 > 每场并行活动配一名信息版主 == 信息版主加技术监看员 == 信息版主、技术监看员和 feed 主持人——争议性并列：这三个方案都会在每场活动期间，为每个开放空间安排一名明确的响应人员，这正是值守职责的全部要求。除此之外增加人员只会改变谁能发现故障，不会改变谁要为行为负责。这一维度与此处其他所有方案的排序都相反，这正是结论：成本最低的层级合规成本最高，因为开放空间无人看管，就意味着有义务却无人响应，其中造成的伤害也无法挽回。Major League Hacking 的组织者指南明确指出，数字空间会增加风险，而非降低风险。请将这一反转视为关于谁应承担责任的论述，绝不要将其当作法律解读：各国的职责、平台条款和数据保留规定各不相同，应由组织者与自己的法律顾问确认。
• 效率：每场并行活动配一名信息版主 > 整场活动配一名信息版主 > 信息版主加技术监看员 > 信息版主、技术监看员和 feed 主持人 > 不安排信息版主

支配关系检查：5 个层级、10 对组合、两个成本维度和两个价值维度，严格支配关系为零。

• 十对组合均可由三种机制解释。
• 其中八对的阻碍很简单：人员配置成本严格更高，却能在所有方面带来更多收益，包括履行职责。
• 不安排信息版主与整场活动配一名信息版主这一对需要单独说明，因为沉默维度上的结果相同，此时“各方面收益都更多”就不成立了。阻碍因素仅在人力投入与空间有人值守这两个维度：信息版主需要占用一个人力，却能提升仍有变化的那项价值维度。合规反转并不是这里的阻碍因素；若将其称为阻碍因素就是错误的。它的方向恰恰相反，这也正是为什么应当选择信息版主，而不是两者都不占优。
• 最后一对——每场活动配一名信息版主与信息版主加技术监看员——之所以无法构成支配关系，是因为两者的信息审核能力确实完全相同，只有故障监看这一维度有差异。
• 支配关系为零，说明此次检查没有发现排序错误。
• 每场并行直播配备一名主持人——默认方案：每场同时进行的直播安排一名指定人员，负责阅读聊天内容、筛选并传递问题，以及维护行为规范。这种方案随并行场次增加，而非随参会人数增加，因此完全不需要按参会人数设定比例。
• 整个活动配备一名主持人——对于单轨日程，这样就足够且合适；当 Q2 的答案表明一次只进行一场活动时，这也是默认方案的同一级别。但只要有两件事同时发生，这种方案就会失效。
• 主持人加一名技术观察员——每场增加一名人员，其唯一职责是确认信号是否正常、声音是否清晰、音画是否同步。这一模式源自线下活动的直播需要“活动期间至少有一人负责运行”（DevOpsDays 组织指南）。无法照搬的是设备配置：这里没有需要操作的控制台，因此这名人员要像观众一样，从制作流程之外观察输出。升级条件，分别对应：
  • 任何无法重播的直播，对应 Q11（“哪些场次无法重播或重新安排”）
  • 往届活动曾出现信号中断却无人察觉的情况，对应 Q10（“上一届活动的问题”）
• 主持人、技术观察员和直播中的现场主持人——资源最紧张的选项：两个价值维度都最高，所需投入也最高，因此按效率考量永远不会选它。只有这一级别会有人在演讲出问题时真正向观众说明情况——直播画面空白、聊天里满是“只有我这样吗？”就是下面两级方案都无法避免的问题。升级条件，分别对应：
  • 付费虚拟门票，或赞助权益中明确要求直播，对应 Q4（“付费虚拟门票，赞助权益中明确要求直播”）
  • 持续数小时的节目，中间需要填补空档，对应 Q2（“它们之间最短的间隔有多长”）
  • 观众没有其他途径了解现场情况，对应 Q1（“是否有任何互动渠道，还是观众只是在观看直播”）
• 删除，而非降级：由演讲者在演讲时自行主持聊天。 从这个菜单和上面的坐标轴描述中删除此项。它看起来像是免费的主持方案，但根本算不上一个级别：演讲者同时做两件事，只会两件都做不好；而且演讲者不可能一边与观众交谈，一边对自己观众中的某个人执行行为规范。上面的最低一级明确说明无人值守；这一项却并非如此。

菜单 4 - 故障演练深度

线下会场出问题时，现场人员彼此看得见。虚拟活动出问题时，只会陷入沉默，每位参会者首先都会以为是自己这边出了问题。

排序（默认方案，并非定则——Q4、Q8、Q10 和 Q11 会改变排序）：

• 成本（准备时间、协调工作、保持基础设施就绪）：在第二个平台进行完整故障演练 > 保持一个常备的备用去处就绪 > 针对最可能发生的单一故障，演练交接流程 > 提前发布一条书面的备用说明 > 不做演练
• 价值：受众留存（人们知道发生了什么，并会继续留下）：在第二个平台进行完整故障演练 == 针对最可能发生的单一故障，演练交接流程 > 保持一个常备的备用去处就绪 > 提前发布一条书面的备用说明 > 不做演练 - 有理有据的并列：两者都会演练故障发生时有人要说的话，而这正是留住受众的全部关键。完整演练增加的是基础设施，而非镇定。
• 价值：内容得以保留（而非丢失，场次本身能够恢复）：在第二个平台进行完整故障演练 > 保持一个常备的备用去处就绪 > 针对最可能发生的单一故障，演练交接流程 > 提前发布一条书面的备用说明 == 不做演练 - 有理有据的并列：两者都无法恢复任何内容。发布说明能告诉人们去哪里查看，却无法让一场演讲恢复直播。
• 效率：提前发布一条书面的备用说明 > 针对最可能发生的单一故障，演练交接流程 > 保持一个常备的备用去处就绪 > 在第二个平台进行完整故障演练 > 不做演练

支配关系检查：5 个层级、10 对比较、1 个成本维度和 2 个价值维度，严格支配关系为 0。

• 不显示合规维度，因为这里没有任何方案在此维度上有所不同：每个层级的风险暴露都取决于平台和同意方面已作出的决定。
• 三种机制解释了全部 10 对比较。
• 其中 8 对因准备成本随方案深入而增加、且两个价值维度都因此提升而无法判定。7 对在两个维度上都严格更优；第 8 对是“不采取行动”与“发布书面说明”的比较：受众留存明显更好，内容保留则持平，因此同样无法判定支配关系。
• 其中 1 对，即“演练交接流程”与“保持备用去处就绪”，无法判定的原因是两个价值维度确实相互交叉：演练话术成本更低且更能留住受众，而只有基础设施能恢复内容。
• 最后一对，即“演练交接流程”与“完整演练”，无法判定的原因是两者在受众留存维度上持平，只有内容保留维度能区分它们。
• 支配关系为 0，说明检查没有发现排序错误。
• 提前发布一条书面备用说明——默认选项，成本几乎为零：只需一句话，发布在受众本来就会查看的地方，明确说明直播中断时该去哪里。它只需花一句话的功夫，就能避免虚拟活动故障期间最糟糕的那一分钟——没人知道问题出在自己这边，还是别处。只要有了版主，就立刻上调一个等级，因为届时会有人实时说明情况。
• 针对最可能发生的单一故障，排练一次交接——演练一种场景：演讲者在演讲过程中断开连接，并提前商定版主开场时要说的确切话语。这是此菜单中价值最高的一小时，带来的是沉着应对，而非基础设施。
• 备好随时可用的备用直播目的地——第二个直播目标已启动但保持静默，发布的说明指向它。这是第一个能让活动重新开播、而非仅仅解释为何停播的等级。
• 在第二个平台上进行完整的故障演练——被冷落的选项：内容轴得分最高，受众轴并列最高，所需精力也最高，因此效率永远不会选它。升级条件分别对应：
  • 可能需要退款的付费线上门票，或写明直播要求的赞助合同，两者都对应 Q4（“付费线上门票、写明直播要求的赞助交付项”）
  • 确实无法改期的场次，对应 Q11（“哪些场次无法重播或改期”）
  • 上一届直播中断，对应 Q10（“上一届的问题”）和 Q8（重复举办的活动，这使上一届的问题具有预测价值）
• **删除，而非降级：没有人读过的应急文档。**从此菜单和上方的轴说明中删除它。它看起来像一项演练，实际上并不是——真正需要时，没人找得到它，也没人知道该说什么。上面最低一档是一句已发布、受众看得到的话，这是完全不同的东西。

失败模式

• 把聊天空间当成免费的。 设置需要一个小时；只要空间开放，就需要有人持续看管，而其中的行为规范责任与实体会场完全相同。已发布的警告指出，数字空间会增加而非降低骚扰风险。
• 出故障时保持沉默。 直播流中断，却没有任何地方发布消息，结果每位参会者都要花几分钟排查自己的连接问题。提前一天发布备用话术，并在故障发生时立即通过该渠道告知大家。
• 在不同的工具上排练。 如果检查时没用活动实际运行的平台，就无法测试屏幕共享流程、音频设备，也无法了解演讲者的浏览器在该平台上的表现。
• 演示时播放背景音乐。 这是已知的平台风险：直播流中出现的背景音乐可能导致平台直接在会议进行期间下架内容，而且无法及时申诉成功。提前一天提醒演讲者。
• 发布超出同意记录范围的内容。 只要录制内容存在，就会有人要求发布。samber/dev-event-organizer-skills@event-speaker-experience 保存了同意记录；本地录制的备份、参会者出现在镜头中的分组讨论，以及包含参会者面孔的问答环节，都不在某场演讲的同意范围内，除非当时以相应方式取得了同意。
• 购置没人会用的互动功能。 分组讨论室、展位和名录无论是否有人使用，都需要采购、运营和数据处理审查。已发布的远程参会人数证据也指向同一结论，而且来自技术行业之外——应将其视为趋势，而非具体数字。
• 套用实体活动的数字。 已发布的成本证据估算的是 混合 活动的虚拟部分，而非独立的线上活动制作成本。切勿将其直接套用，仿佛它能反映你活动的规模。
• 假设参会人数会减少。 某场会议改为线上后，自身不同届的总人数可能上升也可能下降：PyCon US 在 2021 年（线上，约 2,650 人）的参会人数比 2019 年（线下，3,393 人签到）少约 22%；而 KubeCon+CloudNativeCon North America 的注册人数则几乎翻了一番，2019 年为 11,891 人（线下），2020 年增至 22,816 人以上（线上）。减少差旅成本、打破地域限制，带来的人数增长可能与失去实体会场导致的人数下降一样容易发生。应根据本次活动自身的信号规划容量，而不是默认人数会朝任何一个方向变化。
• 按自己的时区安排日程。 按组织者所在地制定的日程，会让部分演讲者和观众不得不在半夜参与。这属于 Q3，因此这类时段恰恰适合采用预录制这一档。

衡量指标

三项完整性检查，可在首场会议开始前完成，且无需争论任何阈值：

• 每场并行会议都指定了一名主持人，或者关闭了该会议的互动功能。不是一个职位——而是一个具体姓名。
• 每位演讲者都至少在活动当天之前，加入过活动实际运行的平台一次。
• 备用话术已经发布，而且负责大声说出这句话的人知道该怎么说。

以下所有内容都是你自行设定的指标，并非行业标准；介绍时应明确说明这一点。

• 未发生观众可见故障的场次，占计划场次的比例（自行设定）。如果某场会议没有音频，也应计为故障，因为演练正是为了避免这种故障。
• 从直播流中断到告知观众所用的时间（自行设定）。这是演练方案实际能改善的指标。
• 转达给演讲者的问题数，占观众提问总数的比例（自行设定）。这能衡量主持人员配置是实际到位还是只有名义上的安排。
• 在活动当天之前参加过检查的演讲者人数，占计划演讲者总数的比例（自行设定）。这是在任何问题发生前可用的唯一先行指标。

选出两到三项，写明每项指标会触发什么变化，并在活动前而非活动后记录下来。

调用示例

• “我们今年的大会完全在线上举办。我们到底需要什么平台？”
• “怎样让远程演讲者做好准备，确保连接中断不会毁掉演讲？”
• “三个并行的虚拟分会场需要多少名主持人？”
• “如果主题演讲期间直播中断，我们有什么应对方案？”
• “我们的演讲者分布在太多时区。对于那些演讲时段落在他们半夜的人，我们该怎么办？”

预期输出：一份执行计划，包含：

1. 一句话说明互动方式
2. 选定的平台方案，并以书面形式列出尚待确认的供应商问题
3. 演讲者准备等级，以及通知或检查安排
4. 按姓名为每场并行会议分配主持人员
5. 故障演练方案和已发布的备用说明
6. 在实际平台上进行彩排的日期
7. 按项目拆分的预算影响

按章节逐一提交验证，确认后再签署任何文件。

参考资料

另请参阅同一合集中的：

• samber/dev-event-organizer-skills@hybrid-event-design - 负责同时服务现场观众和远程观众的活动。分界点在于舞台：混合活动总会有舞台，因此这里列出的所有选项都不适用于混合活动。