event-run-of-show

活动执行流程

你负责活动当天。议程表一经确定就不会再改：samber/dev-event-organizer-skills@event-schedule-design 从自身角度说明了职责划分：“议程表发布后，你的工作就到此为止：活动当天工作人员如何按分钟执行，以及遇到缺席或视听设备故障时如何现场应对，都属于 samber/dev-event-organizer-skills@event-run-of-show”。

它还会把另一份材料交给你，而不只是议程表：写入日程文档的突发事件优先顺序。

1. 首先保障全体会议或主题演讲。
2. 接着保障观众到场所期待的重头环节。
3. 尽量减少修复方案影响的其他环节数量。
4. 锁定修订后的议程表，并在本时段剩余时间内保持不变。

遵循这一顺序。不要在压力之下重新推导。

samber/dev-event-organizer-skills@event-speaker-experience 从自身角度说明了相同的职责边界：“活动当天按分钟执行的工作属于 samber/dev-event-organizer-skills@event-run-of-show”，并指出此技能负责“活动当天按分钟编排的文档；请将演讲者的时间安排需求交给它”。休息室、技术检查，以及现场引导演讲者前往会场的主持人，都属于该技能的职责。你接收演讲者的到场和时间限制作为输入；演讲者现场延迟后，需要做出决策时，就是你的职责范围。

另外还有两项职责边界：

• samber/dev-event-organizer-skills@event-risk-management 编制常设风险登记册和印刷版应急预案，明确可能出现的情况和联系人。你不会重新编写安全情景；你负责明确值班人员及在突发事件发生时执行该预案的沟通渠道。
• samber/dev-event-organizer-skills@event-production 负责设计技术冗余方案，例如备用麦克风和第二条录制链路。你负责明确冗余方案失效后 90 秒内，房间负责人应采取什么行动。

下面所有优先级排序都是默认方案，不是硬性规定；它们会根据具体情况和执行人员而变化。访谈结束后，请根据你已掌握的信息重新评估这三组选项的优先级。以下因素都可能改变默认排序：

• 活动现有的对讲机。
• 场馆位于没有信号的地下室。
• 志愿者团队已经完整执行过这场活动四次。
• 上一届活动中，某个会场每小时都会晚开始。
• 严格的简报截止时间。

访谈

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

1. 已公布的日程安排是什么？日程文件是否附有中断事件的优先级顺序？如果没有，先拿到这份顺序再着手编写（参见工作流步骤 1）。
2. 同时运行多少个房间或舞台？除了这些场地外，还有哪些需要人员值守的岗位——签到、制作、咨询台、赞助商展厅？
3. 活动当天实际有哪些人员到场，各自的班次是什么？志愿者、组织者、付费工作人员、场地方工作人员。此项信息来自 samber/dev-event-organizer-skills@event-volunteers，不是需要你编制的内容。
4. 工作人员所在的所有区域是否都有稳定的移动网络覆盖？场地方是否有自己的通信系统，要求你加入而不能另行使用？
5. 最晚到什么时候还可以做出变更——打印提示单、安排人员加入某个班次、向房间负责人说明情况？各项选择的排序依据应是这个截止时间，而不是活动日期。
6. 这是一次性活动还是定期举办的活动？定期活动应优先考虑收益在活动结束后才体现的选项：可重复使用的提示单模板、书面交接格式、记录下来的换场耗时。
7. 投入精力的上限是多少——由谁编写和维护这份文档，耗时多少小时？有多少人可以值班，而不是承担具体工作？
8. 是否已有纸质应急预案？预案中写明了谁？如果没有，这属于 samber/dev-event-organizer-skills@event-risk-management 的工作，而且在完成前会阻碍你继续。
9. 有哪些现有情况应当改变各项选择的优先级：上一届活动超时、已有的对讲机、信号不通的地下室、有经验的团队、总是延迟开始的房间？
10. 开场环节是否会录制或直播？是否有赞助商合同规定必须逐字宣读的内容？

社区主办还是供应商主办：经检验，这一区分只在部分环节成立

社区主办与供应商主办的区别适用于活动的一部分，但不适用于其余部分。

这一差异适用于主持。 DevOpsDays 写的是“一个或多个 MC”——复数形式也是一种合理的设计，并非备用方案。这是一个真正的分岔：

• **社区路线：**让熟悉活动规范的组织者分担主持工作，不依赖固定的剧本。安排组织者轮流主持，并为每场分享另设一位介绍演讲者的人。
• **供应商路线：**将主持视为一门明确的专业工作，由一位经过讲解和排练的主持人负责。相关从业者指南涵盖了如何根据活动文化编写主持稿，以及如何提前共同排练；还强调“开场的前 90 秒决定了整个活动的基调”（这条建议来自提供 MC 服务的专业主持机构，因此应注意其中的利益立场）。安排一位主持人、一份主持稿和一次排练，并相应提高提示单的详细程度。

其余环节则不适用。 过渡环节执行所需的时间不会改变，对讲机的通信距离不会改变，无论谁为场地付费，交接时遗漏的信息也不会改变。

真正改变其余工作的因素是：同时有多少个需要人员值守的岗位，以及当班人员是否还要兼做其他工作。三位组织者全天都能互相看见的单房间聚会，完全不需要设计通信频道。四个房间的活动则必须先设计通信频道，再考虑其他事项。

如果建议因路线或规模不同而有所差异，请说明该建议基于哪种路线或规模。

工作流

1. 获取已发布的日程表和突发情况优先级顺序。如果日程文档中没有优先级顺序，就去获取一份，而不是自行编造——排序是项目层面的决定，在 14:00、满场都是人的时候临场发挥，结果就是砍掉主题演讲来给赞助商留时段。
2. 收集当天所依赖的输入：轮班计划、每位演讲者的抵达时间和时间限制、场地自身的开放时段和工作人员，以及印有负责人姓名的应急预案。
3. 按姓名分配当天的职责（见下文），而不是只分配职能。“一名志愿者”不算负责人。
4. 按菜单所选的详细程度编制提示单，从日程表向外展开——每个环节和每次过渡各占一行，而不是每小时一行。
5. 设定通信频道架构，并将两条升级路径写在提示单上：常规路径（某个有工作人员值守的岗位遇到超出权限范围的问题）和事件路径（触发应急预案；不要改写预案）。
6. 制定值班轮换安排和交接格式。在提示单上公布每个时段的值班人员，并放在注册台的志愿者不用问人也能看到的地方。
7. 让所有人对照文档进行简报，而不是只围绕文档口头说明。简报时才能发现有两行假设同一个人同时在两个房间。
8. 执行当天的流程。每次过渡时，都按提示执行：排队位置、技术负责人、口播内容（见下文）。
9. 出现问题时，执行现场突发情况处理流程（见下文），而不是临时重新决定。
10. 每次换班时，确保交接完成后再让交班人员离开——包括现场通信频道检查。
11. 收尾：完成最后一个环节、将场地交还，以及当天记录文档中出错之处。

按章节逐项展示活动流程表供验证——先职责，再到提示单、通信和升级流程，最后是轮换安排——然后再打印并进行简报。打印后，每次修改都会让一个仍拿着旧版本的人承担代价。

如果你的运行框架具备持久记忆，请记录：

• 哪些行后来发现有误。
• 哪些过渡耗时过长。
• 通信频道在哪些地方失效。
• 实际上能联系到谁。
• 场地自身的通信和覆盖情况。

第二次使用同一个场地，就值得避免重新摸索一遍。

当天的职责

三个职责来自已发布的主办方指南。第四个由你自行定义，并会在出现的地方明确标注。

• 主持人（来源于指南）——开场并统筹活动。可以有一位或多位主持人；将职责分配给多人是明确列出的做法，不是妥协。
• 演讲者介绍人（来源于指南）——与主持人_分开_的职责，按场次分配。主持人统筹整个活动的流程；由其他人负责每场介绍下一位演讲者。下文将两者合并列为一种常见失误。
• 当班主办方负责人（来源于指南）——具名人员，负责在某个时段处理临时决策，也是常规升级路径的联系对象。指南明确将此角色作为危机决策时的单点故障缓解措施，而非公平轮换安排。
• 房间负责人（自行定义的职责）——每个房间一人，负责掌控房间的时间安排：推迟开始、缩短问答环节、联系技术负责人，并向当班主办方负责人升级问题。已发布的做法默认每个房间都有负责人，但未明确该人员可以决定什么，因此请在你自己的文档中明确界定其权限——哪些事情可以自行处理，哪些必须升级。

可识别的团队作为输入提供，而非由你定义的职责：来自 samber/dev-event-organizer-skills@event-code-of-conduct 的行为准则响应团队，以及大型会议中的无障碍与包容团队 samber/dev-event-organizer-skills@event-accessibility-inclusion。在开场口播内容和当班安排中都列出各团队：说明每个团队的职责，以及如何辨认团队成员。

流程单详细程度

排序（默认排序，并非硬性规定——Q5、Q6、Q7 和 Q9 会重新排序）：

• 工作量（撰写、排练、逐环节计算、简报协调所需的小时数）：word-for-word MC script > per-slot execution budget > scripted transitions > timed grid with named owners

• 价值：让活动日程顺畅进行，不出现冷场或交接遗漏：scripted transitions > per-slot execution budget > timed grid with named owners > word-for-word MC script

• 价值：观众对开场和闭幕的记忆：word-for-word MC script > scripted transitions > timed grid with named owners == per-slot execution budget——有理有据的并列：无论负责人列还是布置和换场时间，都不会改变观众听到的任何一句话。两者都能让活动顺利进行，却无法让人记住某个瞬间。

• 效率：timed grid with named owners > scripted transitions > per-slot execution budget > word-for-word MC script

• 标明负责人的计时表格——默认选项：每个环节和每次转场都有开始时间、负责人和场地。工作量几乎为零，因为表格已经存在，只需添加一列。一旦某个环节的交接速度快于缓冲时间所能消化的速度——闪电演讲、演示、连续的赞助商环节——或者多个场地同时进行，就提升一个等级。

• 转场脚本——明确每次交接时要做什么：下一位演讲者站在哪里、谁负责技术，以及要说出的台词。这是从一个快节奏形式中提取出的做法，并推广到任何紧凑的转场；具体机制和一个示例行见 references/cue-sheet-anatomy.md。

• 每个环节的执行时间预算——对于存在现场执行风险的环节，把布置和换场的时间成本计入预算，而不是假设公布的环节时长足以涵盖这些时间。唯一有来源的具体示例是：一次现场演示为每个团队安排十分钟，其中三分钟用于演示，一到两分钟用于提问，剩下的五到六分钟用于布置和切换到下一团队——超过一半的环节时间都没有用于演示或提问。应将其表述为该活动在该形式下的具体安排，绝不能当作固定数值。

• 逐字 MC 脚本——最不受重视的选项：写好并排练每一句台词。它在易记性方面排名第一，工作量也最大，因此效率排序中永远不会选它。升级条件，对应 Q10：由一位受聘或接受过简报的主持人负责，而不是由多位组织者分散主持；开场内容会被录制或直播；赞助商台词必须严格按照合同约定宣读；或者这是首届活动，没人有过相关经验，照稿朗读比即兴发挥更合适。

• **删除，而非降级：**将面向参会者发布的日程用作工作人员的工作文档。它没有标明负责人、转场或技术安排；把它留在选项中，就可能导致活动当天由手持手机的人照着公开议程来执行。

通信渠道架构

此处借鉴的是一种结构模式，而非某个产品：设置一个专供组织团队使用的协调渠道，并让它与所有面向参与者的渠道分开——包括参与者用来 联系 组织者的渠道。后者是另一个公开空间，组织者只是会留意其中的消息。原文在聊天平台上实现了这种划分，因为它描述的是一场黑客马拉松；这种划分同样适用于无线电、电话群组，或三个彼此看得见的人。请根据活动实际拥有的媒介来命名。

排序（默认情况，并非定律——Q2、Q4 和 Q9 会重新排序）：

• 成本（硬件、设置、教会从未用过的人使用它所需的规范，以及需要管理的消息量）：带呼号的无线电网 > 按角色划分的渠道 > 文字与实时通信组合 > 单一组织者渠道

• 价值：发生突发状况时，消息能到达合适的人：带呼号的无线电网 > 按角色划分的渠道 == 文字与实时通信组合 > 单一组织者渠道——对并列排序的解释：两者都是对同一条未区分的信息流进行一次划分，一个按职能划分，一个按紧急程度划分；哪种划分更有帮助，取决于当天的混乱主要来自角色不清还是噪音干扰。两者都无法联系到不在信号覆盖范围内的人。

• 价值：交接工作或活动后复盘时，有记录可读：文字与实时通信组合 > 按角色划分的渠道 > 单一组织者渠道 > 带呼号的无线电网。无线电不会留下记录，这正是它在这里排最后、在上面却排第一的原因。

• 合规成本（会触发的审查，以及难以撤销的事项）：带呼号的无线电网 > 单一组织者渠道 == 文字与实时通信组合 == 按角色划分的渠道——对并列排序的解释：后三种都使用活动开放参与者渠道时已经接受过条款的平台，因此不会触发尚未进行过的审查。只有无线电会触发审查——请确认所在地区的频段是否免许可证使用，以及场地是否已有必须加入、不可干扰的无线电网。无线电到场后才商定的频道规划，是最难撤销的事项。

• 效率：单一组织者渠道 > 文字与实时通信组合 > 按角色划分的渠道 > 带呼号的无线电网

• 单一组织者渠道——默认选择：为组织团队设置一个协调空间，并在结构上与所有面向参与者的渠道分开。只要有值班人员会离开屏幕，或交接班时接班人需要了解之前发生的事情，就应上调一级。

• 文字与实时通信组合——一个会留下记录的文字渠道，加一个用于实时协调的渠道。原文推荐的正是这对组合，成本是多开一个渠道。

• 按角色划分的渠道——按职能（场地、报名、现场制作）分别设置渠道，同时保留组织团队渠道。这样更精确，但需要所有人判断每条消息该发到哪里，还需要有人盯着四个窗口。

• 带呼号的无线电网——资源最紧张的选项：覆盖能力最强，成本也最高；具体规范由你制定——呼号、按角色分配频道、按下通话键发言的礼仪，以及频道受到干扰时的处理方式。适用条件：场地移动网络覆盖不佳；场地分布在多层楼或多栋建筑；工作人员双手都忙；消息量大到文字渠道滚动速度超过任何人阅读的速度；或场地已有必须加入的无线电网。

• **删除，而非降级：**用于组织者沟通的面向参与者渠道。它会让所有人看到组织者在为什么慌乱，而真正需要当班人员看到的那条消息，也会被其他人的消息淹没。把它搁置在最底部，只会让它在 09:00 时重新出现，而组织团队渠道却还没创建。

值班轮换与交接

轮换遵循已发布的组织者实践；以下关于班次_如何_交接的内容，均借鉴自工程值班实践——沿用其结构，绝不照搬其工具或数字。完整映射见 references/shift-handoff-protocol.md。

排序（默认顺序，并非铁律——Q3、Q6 和 Q7 会重新排序）：

• 工作量（投入人数、每次交接需要两人投入注意力的分钟数、排班复杂度）：两人共同值班 > 定时重叠并现场确认 > 书面交接清单 > 每个时段指定一名值班人员——重叠优于清单，因为它包含了清单：这段时间既用于书写_也_用于交谈，而且交接时两人都必须在同一地点；而写好后留在原地的清单做不到这一点。
• 价值：接班人员清楚自己接手了什么：两人共同值班 > 定时重叠并现场确认 > 书面交接清单 > 每个时段指定一名值班人员
• 价值：危机决策不会由单独一人承担全部责任：两人共同值班 > 每个时段指定一名值班人员 > 定时重叠并现场确认 == 书面交接清单——有理有据的并列：两者都不会改变能做决定的人数，只会影响下一位值班人员得到交代的充分程度。指定值班人员的轮换机制优于两者，因为源实践明确指出，这正是应对这种失效情形的做法。
• 效率：每个时段指定一名值班人员 > 书面交接清单 > 定时重叠并现场确认 > 两人共同值班

支配关系检查：4 个等级，6 组比较，严格支配关系为零。 这种排序只有按构造才显得干净，而按构造得出的结果绝不等于过关。两种机制阻止了这 6 组比较形成支配关系：

• **其中 4 组在工作量上落败：**简报质量更高的等级必然成本更高，包括重叠与清单的比较：重叠在简报上更优，在单点故障上持平，却仍然成本更高。
• 其余两组（重叠与指定值班人员轮换的比较，以及清单与指定值班人员轮换的比较）受相互对立的价值维度阻碍，因为轮换是唯一既成本低廉又能解决谁有权做决定的等级。

这两种理由都不是证据。以下排序有其论据。

• 每个时段指定一名值班人员——默认做法，也是有来源依据的实践：在提示表上公布每个时段的值班人员，让岗位上的志愿者无需询问就能看见。凡是交接可能发生在问题正在处理中时，或交班人员会在交接点离开大楼时，就提升一个等级。
• 书面交接清单——由固定栏目组成，并要求每栏都必须填写：每个栏目都有内容或明确写明“无”，事项才算完成。明确写明“无”是关键——它能区分“没有需要报告的内容”和“没人检查过”，而仓促交接恰恰会掩盖这一区别。
• 定时重叠并现场确认——设置短暂的重叠时段，而非立即切换；结束时进行现场检查，确认接班人员确实能联系上该频道，而不是只听一句口头保证。如果交班人员已经离开，就改用简短的书面交接，加上一段简短的录制讲解。
• 两人共同值班——人员最紧张的选项：每个时段安排两人，并错开排班，确保两人不会同时交接。在连续性两个维度上都最佳，工作量也最大；在社区规模的活动中，额外的人手_就是_组织团队。升级条件：通宵活动、没人了解失效模式的首届活动、值班人员同时也是主持人或演讲者，或规模大到足以让两件事同时出问题的活动。
• **删除，而非降级：**不指定值班人员，理由是由离得最近的人决定。这正是源实践要防止的单点故障，只不过披上了灵活性的外衣——实际上会变成由一个人决定所有事情，而且此人无法离开大楼。

执行转场

转场由三项机制保障，时间安排不在其中（这些机制源自快节奏演示活动形式，并推广到任何紧凑的交接场景）：

• 排队位置 - 下一位演讲者实际站在哪里：站在舞台旁，而不是观众席里。
• 技术归属 - 使用一台设备，由一位操作员负责，并提前收集好材料，这样交接时只需切换文件，而不用交换笔记本电脑。
• 口头提醒 - 活动当天口头重申活动形式的限制，尽管大家都已提前获知。

来源明确指出，最好在实际使用时再次提醒，而不是默认大家记得之前的说明。

两个环节影响格外重大，值得在提示表中用最详尽的条目来安排：

• 开场 - 它为当天定调。
• 收尾 - 人们会记住开头和结尾。

开场内容检查清单和收尾机制的来源见 references/cue-sheet-anatomy.md。

保障收尾后的时间

最后一场活动结束后的社交时间是一个独立环节，而不是剩余时间。结束后的饮酒交流是同行在快速变化的领域中互相传授经验的场合；一位组织者称它是当晚最重要的部分。前面任何环节超时都会挤占这段时间，因为提示表上没有任何安排能保护它。

• 为收尾活动单独设一行：明确开始时间、负责人，以及用于开启活动的口头提示。
• 为最后一场活动设置硬性结束提示，由场地负责人负责，并与收尾活动的开始时间挂钩，而不是与该时段公布的结束时间挂钩。
• 当 samber/dev-event-organizer-skills@event-official-social-program 为日程提出保障要求时，应在中断处理顺序中将预留时间视为受保护时段：优先压缩问答或转场缓冲时间。
• 留意最后一场活动中有人提前离场的情况。这意味着活动流程超时，或收尾环节始终没有让人觉得它是活动的一部分。

现场处理突发情况

不要临时做决定。按以下流程执行：

1. 在现场说明情况。 场地负责人说明发生了什么，并开始计时——例如演讲者未到场、信号传输失败，或一场 30 分钟的演讲已经进行了 40 分钟。
2. 按流程上报。 现场工作人员能独立解决的问题，由他们自行处理。超出其权限的问题，按常规途径通过组织团队频道提交给值班组织者。安全、医疗或安保事件则直接按照印制的应急预案联系相关人员；该预案由 samber/dev-event-organizer-skills@event-risk-management 编写，你应执行预案，而不是改写它。
3. **根据已公布的突发情况处理顺序做决定，**而不是看现场反应。首先保障全体会议或主题演讲，其次保障重点承诺，然后尽量减少调整对其他场次的影响。
4. **确定调整后的日程表，**并在本时段剩余时间内保持不变，避免随着活动推进而反复调整。
5. 在现场和频道中大声宣布变更。 如果没有人宣布变更，接下来按印制日程表行事的人就可能把它改回去。
6. 趁问题仍在发生时，在文字频道中记录出错的那一行。 下一班工作人员和下一届活动都会承接这份记录。

第 3 步由谁拥有何种决策权限，由你自行定义。提前决定并写入文档，明确说明是谁做的决定，而不要把它说成标准做法。如果你想参考一个起步模型，而不是从空白页面开始，references/comms-and-escalation.md 提供了跨行业的分级处理惯例。

收尾

收尾时：

• 按合同要求将场地交还。
• 明确通知工作人员结束工作，而不是任由大家陆续离开。
• 当天记录文档中暴露的问题：哪些条目有误、哪些转场超时，以及哪些升级请求无人响应。

事后复盘能还原决策，却会丢失时间细节。

失效模式

• 每次危机决策都由一个人承担，形成单点故障。 没有明确的轮值安排，因此同一位组织者接下每个电话，也无法离开会场。资料中给出的解决办法是值班轮换，并按时段公布。
• 主持人还负责介绍每位发言者。 两个有据可查的角色被合并为一个，结果是负责统筹当天流程的人还必须每四十分钟准时站在特定讲台前。将两者拆开；介绍人角色可以自由轮换。
• 在面向参会者的频道里讨论组织者事务。 问题在相关人员面前被讨论，而重要信息则被其他消息淹没。应在活动当天之前创建单独的频道，而不是等到当天才创建。
• 转场没有提示。 时间表只写着某场环节于 11:20 结束，却没说明谁来发言、下一位人员站在哪里，或谁的设备上有幻灯片。结果是出现冷场，耗掉原本为此预留的缓冲时间。
• 默认场地布置会在无人察觉的情况下完成调整。 同一空间两次使用之间的重置没有指定负责人，也没有安排专门时段，因此要么占用下一环节的时间，要么直接被跳过。像处理其他转场一样，为重置安排专门时段，并在当前环节仍在进行时开始，而不是等它结束后再动手。
• 闭幕后的社交时间被所有超时挤占。 每场环节都超时五分钟，而同行真正交流知识的饮酒社交时间则被压缩到荡然无存。解决办法：为最后一场环节设置严格的结束提示，并与闭幕时段的开始时间挂钩（§ 保护闭幕后时间）。
• 交接时没有实时确认。 接班人员说自己已接入频道，却在第一次遇到升级事件时才发现并没有接入。在交班人员离开之前，进行实时确认。
• 临时决定中断处理顺序。 时间表已经公布了处理顺序，而它存在的目的正是避免有人在压力之下由离故障最近的人临时做出决定。
• 把自己的惯例说成行业惯例。 无线电纪律、场地负责人的权限和换班机制都是你设定的惯例；其中最后一项借鉴了值班工程实践。实时权限层级的结构现在参考了公开的舞台管理和演出制作惯例，但具体人员名单仍需由你确定。把自己的具体做法说成既定标准，会削弱有据可查部分所需要的公信力。

衡量

开门前即可核查的两项完整性检查，不需要争论阈值：

• 每个有工作人员值守的岗位，都能在不询问任何人的情况下说出该时段的值班组织者。
• 提示单上的每个环节都有明确负责人；每个换班节点都有交接记录，且每个部分都填写了具体内容或明确注明“无”。

以下每项指标都是你自行设定的，并非需要达到的基准。介绍这些指标时要说明这一点。

• 转场冷场时长（自行设定）：一个环节结束到下一个环节开始之间的秒数，分别统计提示单已编排和未编排的转场。这个比较结果将用于说明下一届为何需要更细致的安排。
• 联系到值班人员的升级事件（自行设定）：记录数量，绝不淡化——数量为零通常意味着工作人员联系不上任何人，而不是没有发生任何情况。
• 与已公布的中断处理顺序不符的实时变更与临时决定的数量（自行设定）：应努力减少的是后者。
• 闭幕时间的落实情况（自行设定）：实际提供的闭幕后社交时间分钟数与预留分钟数之比，以及闭幕后社交时间开始前离场人数的粗略估算。
• 提示单偏差（自行设定）：后来发现有误的条目——负责人不在现场、技术设备不在注明的位置，或环节根本不存在。这些内容将成为定期举办活动的模板所继承的经验。

挑选两三项指标，写下每项指标会触发的修订，并在活动当天之前记录，而不是活动结束后才记录。

调用示例

• “为期两天、设有三个会场的会议日程已经敲定。请为我编写流程表。”
• “活动当天谁应该配备对讲机？我们需要哪些频道？”
• “我们的主题演讲嘉宾堵在路上，二十分钟后就要开始演讲。我们该怎么办？”
• “上午和下午的当值组织者之间该如何交接？”
• “请为我们的闭幕式编写提示表，其中有八个团队演示。”

预期输出：流程表，包含：

1. 明确的角色分工，包括每个时段由谁当值。
2. 按选定的详细程度编写的提示表，每个环节和每次转场各占一行。
3. 通信频道架构及其使用的媒介。
4. 直接写在表上的两种升级处理路径。
5. 交接格式及变更发生的时间点。
6. 现场突发情况处理流程，并在其中引用日程的优先级顺序。
7. 收尾步骤。
8. 两项完整性检查关卡及选定的指标。

按章节逐一提交验证，通过后再打印并进行简报。

参考资料

• references/cue-sheet-anatomy.md - 提示表作为执行文档的构成：每一行包含什么、完整引用的转场机制、开幕式内容检查清单和闭幕式机制、附有来源活动及形式的现场演示时间拆分，以及一组正反提示表行示例。

• references/comms-and-escalation.md - 频道分离模式，以及如何将其映射到对讲机、聊天或电话群组；并列展示两种升级处理路径及其区别；角色到频道的分配示例；引用的跨行业现场指挥权阶梯惯例；以及需自行制定的对讲机规范。

• references/shift-handoff-protocol.md - 此处借鉴的待命交接结构（重叠时段、必填条目检查清单、单独的事件处理中模板、现场确认、异步备用方案），并明确说明了映射方式；还包括不适用的内容及不得重复使用的数据。

• samber/dev-event-organizer-skills@event-schedule-design - 制定本文件执行的时间表，并提供突发情况处理的优先级顺序；本文件不会重新讨论这些内容。

• samber/dev-event-organizer-skills@event-speaker-experience - 负责绿间、技术检查和现场主持，并将每位演讲者的到场及时间限制作为输入提供。

• samber/dev-event-organizer-skills@event-risk-management - 编写常设风险登记册和纸质应急计划；本技能会触发其中的情境和联系人处理流程，但不会改写这些内容。

• samber/dev-event-organizer-skills@event-production - 负责设计影音、舞台和录制的冗余方案；冗余方案失效后，由本技能规定会场负责人应采取的行动。

• samber/dev-event-organizer-skills@event-volunteers - 招募、安排并简报人员，其轮班计划是本文件的输入；本技能则编写这些岗位在活动开始后的工作流程。

• samber/dev-event-organizer-skills@event-social-media - 规划活动当天的实时报道；指定发布人员和拍摄规则必须写入本文档，而不能另放在当天无人查看的页面上。