event-schedule-design

活动日程设计

你要将已选定的场次安排进实体网格：哪场演讲在什么时间、哪个房间举行，以及场次之间如何衔接。输入内容已由以下来源确定：

• 分会场数量、活动形式、场次形式组合、交付模式 - 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-speaker-experience 负责收集；此技能负责将它们与时间段对应起来。

你的工作止于发布网格。活动当天工作人员如何逐分钟执行，以及如何现场应对缺席或视听设备故障，属于 samber/dev-event-organizer-skills@event-run-of-show。

以下各项排序都是默认值，并非定律——会根据具体情况和执行者而变化。访谈结束后，请结合你对本次活动的了解，重新排列三组菜单中的所有选项：

• 各房间通向同一条狭窄走廊的场馆。
• 已在使用、且可免费计算冲突的排期工具。
• 曾明确告诉你他们难以取舍哪两条分轨的回头客。
• 严格的发布日期。

每种情况都可能颠覆默认排序。

访谈

每次问一个问题，尽可能采用选择题。提出问题 4-6，是因为以下菜单在见效时间、持久性和投入方面差异显著——不能替用户决定这些排序。

1. 有多少个房间会同时使用？你要安排多少天、多少场次？（这是会改变下文所有内容的分岔点——见下一节。）
2. 房间情况如何：名称、座位容量，以及步行相隔多少分钟？不考虑容量而制定的网格，等于一份只能在活动当天才会发现问题的座位安排。
3. 场馆合同规定了什么：开门和闭门时间、餐饮时段、房间租赁的开始和结束时间，以及是否有房间只租用半天？
4. 日程必须何时公开？这个日期是为了促进门票销售、方便预订行程，还是履行赞助承诺？
5. 这是一次性活动，还是会逐年积累价值的年度资产？（如果目标是逐年积累价值，就应提高见效较慢的选项的优先级：记录房间周转时间、发布带版本号的公开网格，以及设置能告诉你哪些冲突最令人困扰的问卷问题。）
6. 投入上限是多少——实际由谁制作和维护这份网格、能投入多少小时，以及当两场活动争用同一时段时由谁仲裁？
7. 你是否已掌握每位演讲者的可用时间段，以及多位演讲者参与的场次中所有共同演讲者的可用时间段？如果没有，先收集这些信息，再开始排期（见工作流）。
8. 哪些场次是固定安排、不能随意调整的：主题演讲、开场、闭幕、赞助商时段，或演讲者只能在某一天进行的场次？
9. 已有哪些信息可以影响菜单排序：上一届的日程及相关投诉、记录下来的超时情况、具有冲突检测功能的排期工具、已知的走廊瓶颈，或指出令人困扰的冲突的参会者调查？
10. 同一房间连续举办两场活动时，现场需要做哪些调整：重置视听设备、更换家具、重新布置舞台？
11. 受众构成有多复杂——只有开发者，还是开发者与非技术参会者并存？此外，该领域的发展速度是否快到可能导致提前数月安排的演讲到活动当天就已过时？

单轨与多轨

这也不像本合集常见的社区主办与厂商主办之分：无论开发者购买哪种活动的门票，他们走过走廊的速度都一样。活动归谁所有，只会影响选取哪些内容，不会影响房间如何清场。

真正会改变工作的，是是否会同时举办多个环节：

• 单轨 - 按这些工具的定义，不存在日程冲突问题：环节不会重叠，因此冲突检测归结为一个问题：演讲者是否在场。也不存在房间容量匹配问题；所有人都在同一个房间里，或者活动超售。全部设计工作都转向安排节奏、设置休息时间和缓冲时间；一场环节超时会影响整天的安排，而不只是某一条轨道。
• 多轨 - 四种冲突类型都适用，房间容量匹配成为实际的分配问题，走廊通行能力成为设计约束，而非事后才考虑的因素；单轨活动中无需特别安排的全体环节，现在则必须刻意重新安排。
• 规模上限 - 数十个房间。FOSDEM 2026 发布了 1,079 场活动，分布在 37 个房间和 71 条轨道上，并在日程表之外另行发布了“按轨道划分的房间占用情况”概览：到了这个规模，日程表不再是单一文档，房间与轨道的对应关系也成为独立的产物。应将其视为规模上限的基准，而非目标。

如果建议因规模类型而异，请说明所假设的是哪一端。

工作流

1. 进行访谈。在动用时间表前，先获取会议室列表及其容量和步行距离（Q2），以及场地不可调整的时段（Q3）——这两项都应删除，而非调整。
2. 在安排任何内容前，收集每位演讲者的可用时段；多位演讲者参与的场次，还要收集共同演讲者的可用时段。在提案提交时通过日历组件收集可用时段，是有资料来源支持的做法。如果表单没有询问，现在就询问并等待；公布后才发现时间冲突，会导致需要公开更正。表单应详细到什么程度，这项工作应由 samber/dev-event-organizer-skills@event-cfp-design 决定。
3. 统一场次时长（见下文），让时段可以互换。分配任何场次前就要完成这一步——如果网格中时长各不相同，一旦某项内容移动，就无法重新安排。
4. 先安排固定点（Q8）：开场、主题演讲、闭幕，以及只能安排在某一天的场次。其余内容再围绕这些安排。
5. 接下来安排午餐和休息时间，不要留到最后。在多轨道日程中，它们还能充当全体重新同步的节点，重置各轨道累积的时间偏差。PyCon US 在一个专用的大型会议室中安排 9:00-9:45 的主题演讲，约 10:30 安排上午中场休息，12:30-1:15 安排午餐，约 4:00 安排下午中场休息。
6. 根据预期听众人数匹配场次和会议室，而不是为了让轨道安排整齐（见下文）。
7. 将其余场次安排进网格。如果多个已录取的演讲竞争一个黄金时段，先安排限制最多的场次——只有一天有空的演讲者应优先于整周都有空的演讲者（借鉴最早到期优先的车间调度法；这只是组织安排的类比，并非需要机械照搬的规则）。
8. 选择轨道开始时间的对齐方式（见下文），并始终如一地应用。
9. 按菜单选择的深度进行冲突检测。此后每次有变更，都要重新检测，而不是只在最后检测一次。
10. 从菜单中设置缓冲时间，并根据 Q2 中的步行距离进行核对。
11. 通读全天日程，检查节奏，并明确标注这种阅读的性质（见“能量曲线节奏安排”）。
12. 将突发情况的优先处理顺序写入网格文档，并交给 samber/dev-event-organizer-skills@event-run-of-show。
13. 按菜单选择的方式发布，然后将网格视为持续更新的文档，而非最终成品。

按章节展示网格以供确认——先是固定点，再是休息时间、会议室分配，最后是完整网格——确认后再公开。日程一经发布，任何变更都会影响按照旧日程做好计划的参会者。

如果你的运行环境有持久记忆，请记录：

• 场次时长标准。
• 缓冲时间数值及选择原因。
• 后来证实有误的会议室容量假设。
• 参会者报告的冲突。
• 该场地的步行距离信息。

同一个场地用两次，就值得重新测量。

统一场次时长

选择少量时段长度，让每个场次都符合其中一种。有两项来自不同规模活动的参考做法：FOSDEM 的演讲时长约为 50 分钟，闪电演讲不超过 15 分钟；PyCon US 的演讲时长为 45 分钟。两者都统一了时长，也都不提供各不相同的时长选项。

统一的是_时段_，而不是演讲时长。一个 30 分钟的时段容纳一场 25 分钟的演讲，剩余的换场时间已包含在公布的时长中，因此下文默认的缓冲档位无需额外计算。在演讲者说明中分别写出演讲时长和时段时长，否则演讲者会按整个时段来安排。

房间与容量匹配

按以下顺序为场次匹配房间：

1. 预计观众人数。
2. 房间相邻情况。

切勿根据哪个主题线看起来更值得使用大房间来匹配。这样做是为了避免一种单向且显而易见的问题：场次观众人数超过房间座位数时，参会者会被挡在门外；而场次安排在过大的房间里，只会显得冷清。

根据你实际掌握的信息估算预计人数：

• 上一届各场次的观众人数。
• 该主题在你所在社区的吸引力。
• 讲者的粉丝群体。
• 该主题线在征稿中的占比。

这里的所有估算都是你自己的判断，而不是基准数据，因此要明确说明这一点。如果某场次有可能坐满溢出，可以为它安排更大的房间，或者将其安排在另一场同样吸引观众的场次对面，让观众分流而不是集中到同一处。

当房间数量较多时，应将房间与主题线的对应关系单独整理成一份资料，而不是从日程表格中推断——FOSDEM 单独提供的房间占用情况概览就是这样做的。

另外两项排期调整几乎不影响多主题线日程的连贯性和公平性；这两点是自行设定的，而非公开的惯例：

• 在内容允许的情况下，将相邻时段按主题分组，让参会者可以在同一房间连续听两场，而不必每两场之间都更换房间。
• 如果每条主题线在一天中交替使用较大和较小的房间，应在当天中途互换各主题线的房间，让同一条主题线的观众不至于整天都待在较小的房间里。

冲突检测深度

真正的日程安排工具会将其建模为四种截然不同的冲突类型，而不是一个笼统的标记：

• 场次超出其所在房间的可用时间范围。
• 场次与演讲者声明的不可用时间冲突。
• 同一房间内的两场活动时间重叠。
• 同一演讲者被安排在同时进行的多场活动中。

对于有多位演讲者的场次，可用时间范围是所有共同演讲者可用时间的_交集_——只要有一位共同演讲者无法出席，该场次就不能安排在那个时间。完成这些检查并不需要工具，甚至任何工具都不需要：这四种类型是网格必须表示的内容，而电子表格可以容纳所有这些信息。

排序（默认情况，并非铁律——Q1、Q6 和 Q9 会重新排序）：

• 工作量（必须收集的新数据、需要遍历网格的次数、所需判断）：受众重叠检查 > 可用时间范围检查 > 演讲者重复预约 == 同一房间时间重叠——这里并列是有依据的，不是回避问题：两者都只是对网格已有数据进行纯算术检查，无需收集新数据，也无需判断；无论执行一项还是两项，都只需遍历一遍。
• 价值：让场次能按公布的安排实际进行：可用时间范围检查 > 演讲者重复预约 == 同一房间时间重叠 > 受众重叠检查。可用时间范围检查排在首位，因为它会静默失败——演讲者在飞机上时，网格上看不出任何问题。
• 价值：打造令观众满意的节目安排：受众重叠检查 > 可用时间范围检查 > 演讲者重复预约 == 同一房间时间重叠。这条轴正是存在被搁置选项的原因；三项机械检查能确保日程顺利执行，却无法确保任何人乐在其中。
• 效率：同一房间时间重叠 == 演讲者重复预约 > 可用时间范围检查 > 受众重叠检查

支配关系检查：4 个层级、6 组配对、零个严格支配关系——只有通过构造才做到干净，而通过构造绝不等于通过检查。 三种机制阻断了这 6 组配对：

• 受众重叠检查与其他三项的配对，受到价值轴方向相反的阻碍——它在节目质量上居首，在日程能否执行上垫底。
• 可用时间范围检查与两项算术检查的配对，仅受到工作量的阻碍：可用时间范围检查在_两个_价值轴上都占优，但成本仍然更高。
• 最后一组配对，即同一房间时间重叠与演讲者重复预约，则因两个层级在所有轴上都并列而受阻，因此两者都没有严格优势。

这三种理由都不是证据；效率排序依赖下文的论证。

• 三项机械检查——默认选项，一次检查完成：同一房间时间重叠、演讲者重复预约，以及两类可用时间范围检查（包括多位演讲者的时间交集）。这三项合起来就是工具能自动化的全部内容，而且成本足够低，因此少做任何一项都谈不上合理节省。
• 受众重叠检查——被搁置的选项：两场有共同受众且都受他们欢迎的活动被安排在同一时段。没有计算方法能算出这一点；需要熟悉社群的人查看网格并指出哪些活动会冲突。它在节目质量轴上居首，在工作量上也最高，因此效率排序永远不会选它。
  • 启用条件：有两条明显拥有共同受众的活动轨道、专门为减少时间冲突而新增一条活动轨道，或有回访观众已告知你上一届哪些冲突最令人遗憾。
• **删除，而非降级：**单轨活动应彻底删除时间重叠检查、重复预约检查和受众重叠检查——因为没有任何活动会同时进行，唯一需要检查的是演讲者的可用时间。把多轨活动的检查清单搁在单轨计划的底部，正是第二条活动轨道悄然重新成为项目范围的方式。

场次之间的缓冲

排序（默认排序，并非铁律——Q2、Q5 和 Q9 会重新排序）：

• 工作量（网格算术、逐房间记账、占用的日程时长）：考虑房间换场的缓冲 > 按比例设置的缓冲 > 固定场次间隔 == 场次内部缓冲——两者并列的理由：它们都公布一个适用于整个网格的数值，并且只需做一次决定即可设定；缓冲是在场次内部还是场次之间，只会改变参会者看到的内容，不会改变计算方式。

• 价值：场次按时开始：考虑房间换场的缓冲 > 按比例设置的缓冲 > 固定场次间隔 == 场次内部缓冲——基于相同理由，两者仍然并列，因为无论采用哪种方式，消耗的分钟数都相同。

• 价值：参会者能真正安排进日程的走廊交流时间：固定场次间隔 > 考虑房间换场的缓冲 > 按比例设置的缓冲 > 场次内部缓冲。公布的间隔是可见的时间，参会者可以用来在走廊交流；隐藏在场次内部的缓冲看起来像空档，超时的讲者反而会占用它。

• 效率：场次内部缓冲 > 固定场次间隔 > 按比例设置的缓冲 > 考虑房间换场的缓冲

• 场次内部缓冲——默认选项：公布的场次时长要长于其中讲座的时长，并向讲者说明这两个数字。成本近乎为零，因为缓冲包含在本来就要公布的时长中。

• 固定场次间隔——在每场之间设置一个固定间隔，所有地方都相同。FOSDEM 的开场主题演讲（09:30-09:50）与随后的场次（10:00-10:50）之间，明显留有 10 分钟间隔；整个会场共有 37 个房间。应将此作为高密度与缓冲之间权衡的真实案例，而非推荐数值——对于这样的场地规模，10 分钟很紧张，而这正是实现 1,079 场活动的代价。

• 按比例设置的缓冲——缓冲时长按前一场的时长比例设置，而非采用固定数值；并将缓冲的消耗程度视为渐进信号（充足、逐渐紧张、已耗尽），而不是简单区分准时或迟到。这种模式源自制造业生产调度。借鉴这种模式即可，不要照搬制造业的具体百分比——其 50% 的缓冲比例和 33%/67% 的区间边界来自不同领域，不适用于这里。

• 考虑房间换场的缓冲——最少见的选项：针对每个房间的每对连续场次，根据实际需要调整缓冲时长，例如重置视听设备、将工作坊的桌子恢复为剧院式座位，或为圆桌讨论摆上椅子。这种模式源自制造业生产调度中的换线排序；由于需要逐对记录，它在准时价值和工作量方面都排在首位。

  • 启用条件，以 Q10 为依据：同一个房间承办多种活动形式；场地的视听设备需要在场次之间实际重置；或有持续改进的要求，需要记录一次实际换场时长，并在每届活动中重复使用。
  • 还有一种免费的配套做法：在同一房间内按活动形式排列场次，以减少需要更换的布置。

• **删除，而非降级：**只要房间位于不同楼层，或步行距离超过几分钟，就不要采用零间隔网格。假设参会者能瞬间移动的日程会让他们整天都迟到；若仍将其列为选项，当日程显得过长时，这种做法就可能卷土重来。

分轨开始时间对齐

这里刻意不做排名。同步开始和错峰开始的决策成本相同，执行成本也相同——一次调用、一遍遍历日程网格——因此对两者进行效率排序属于虚假的精确。选择取决于场地，而非比例：

• 错峰开始：当多个会场同时换场会堵塞走廊时采用。PyCon US 2026 在五个主会场错峰安排开始时间——实际观察到的开始时间为 11:00、11:45、12:30、1:45、2:45、3:30 和 4:30——这样，一个分轨结束时，另一个分轨的会议正进行到一半，人流便会分散，而不是集中。错峰会让你无法遵守整点统一开始的简洁规则，也会让冲突检查变得更难阅读。
• 同步开始：当会场数量较少、所有人同时移动仍能顺利疏散时采用；或者当你希望所有观众一起参加全体会议时采用。

无论采用哪种方式，都要保留全体会议的同步节点：主题演讲或午餐会将所有分轨汇聚到一个会场，也能在下一个时段开始前，重置各分轨此前累积的时间偏差。PyCon US 和 FOSDEM 都以这种方式在日程表的开头和结尾安排全体会议。

能量曲线节奏安排

有明确名称的组织方会在一天中调整会议形式和密度，而不是始终保持不变；低谷时段（结构性地更容易出现低出席率的位置）是一个真实且有明确名称的问题，并非只是换了名称的制造业类比（完整来源列表请参见 references/published-schedule-benchmarks.md § 能量曲线节奏安排与低谷时段：有明确名称的来源）：

• DevOpsDays 自己的组织指南安排上午进行结构化演讲，随后是简短的 Ignite 演讲，下午则是自组织的 Open Space——这是从高度结构化到低度结构化的公开形式梯度。
• 午餐后的警觉度下降是昼夜节律现象，与参会者吃了什么无关；这正是午餐后应避免安排高密度内容的生理依据。
• 在所研究的会议中，最后一天的最后一个时段在实证上出席率最低、参与度也最弱；如果安排在周末，这种风险同样会在全天尺度上出现。

除了查看自己的日程网格外，这些来源还介绍了两种具体方法：

• 调整形式，而非调整内容。 DevOpsDays 不只是避免在午餐后安排某些内容，还会更换形式——从讲座式演讲改为自组织的 Open Space，让时段适应观众当时的实际精力状态，而不是与之对抗。
• 按时段跟踪未到场率，作为诊断指标（参见下文“测量”）。逐届逐时段记录哪些时段的实际到场人数低于预期，能让“哪些时段在这里是低谷”从经验之谈变成你可以在自己的活动中测量的指标。

每个会议日的开场和收尾都安排不同形式的主题演讲

每个会议日都以主题演讲开场和收尾，并让两场主题演讲采用与其间演讲不同的形式：趣味表演、鼓舞人心的故事、艺术演出、现场演示或秀场。组织者自身的经验支持这种做法；此处未引用已发表的来源。

• 开场主题演讲。 它定下基调，并在各分轨开始前汇聚全场观众。不同寻常的形式能传达出这不是一场演讲马拉松。
• 收尾主题演讲。 它为当天画上共同的句号，也为观众留下来参加最后一个时段提供理由；上文关于低谷时段的发现表明，这一时段通常最弱。应有意将收尾主题演讲安排在这里，并放在全体会场进行，确保没有分轨同时占用它。
• 形式应与演讲不同。 再安排一场风格相同的技术演讲，就无法实现目的。向表演者说明会场情况、时段长度，以及观众在那个时刻的精力状态。
• 先确定固定节点。 在填充各分轨内容前，先将开场和收尾主题演讲与其他固定节点（Q8）一同安排好。

在你自己的活动中进行验证：比较收尾时段的出席率与没有安排收尾主题演讲的届次中同一时段的出席率。

单轨晚间活动的深度梯度

混合型会场的一项排序规则（Q11）：

• 按内容从最广泛到最深入的顺序安排整场活动。 非技术观众能完整听到前面的演讲，专家则听最后的演讲。这样，没人会在了解背景之前就听到深入探讨。
• 搭配漏斗式演讲。 每场演讲都从几乎所有人都能跟上的内容开始，逐步深入；samber/dev-event-organizer-skills@event-talk-selection 中的录用简报和 samber/dev-event-organizer-skills@event-speaker-experience 中的指导都会传达这一要求。日程表只负责确定顺序。
• 为何不设两条轨道：同一批组织者报告称，他们曾试行将技术和非技术内容分成两条轨道。效果还算可以，但参会者在选择会场时感到困惑。轨道数量本身由 samber/dev-event-organizer-skills@event-format-selection 决定；应在那里报告试行结果，而不是在日程表中重新讨论。

这种梯度与前文关于冷门时段的发现相冲突：最深入的演讲会被安排在最后，落入最差时段。对于一场专家会留下来听深入内容的晚间聚会，接受这种取舍，并观察每个时段的缺席率以验证效果。

references/production-scheduling-concepts.md 中的均衡化（平准化生产排序）类比，仍是解释为何将高强度内容前置有帮助的最接近机制。上述来源证实了这一方向，却没有说明原因；它们补充提到的午餐后低迷期，则是轮班末尾赶工类比完全没有涵盖的第二个风险时段。阐述节奏判断时，应说明哪些是有来源支持的，哪些属于判断；两者都不要编造数字。

演讲者限制与突发情况

会场和演讲者各自都有可用时间段，两者是独立的限制：会场的预订时段不等于演讲者的日程。在分配时段时：

• 核对两者的时间安排。
• 多位演讲者共同参与的环节，采用其可用时间的交集。
• 将行程时间视为可用时间限制——演讲者若在当天上午才抵达，就不能负责当天的开场。

设计日程表时，应确保突发情况发生后仍能维持运行，并将优先顺序写入文档，而不是留待压力之下临时决定（借鉴制造业生产排程中的突发情况重新排序方法；该领域的沟通方式和锁定时长数据不适用于此处）：

1. 优先保障全体会议或主题演讲时段。
2. 接着保障观众为之而来的重磅承诺。
3. 尽量减少需要调整的其他环节。
4. 修改后的日程表在该时段剩余时间内保持锁定，不要随着活动进行反复调整。

活动当天按上述顺序执行，属于 samber/dev-event-organizer-skills@event-run-of-show 的职责，而不是此技能的职责。

发布策略

排序（默认为此顺序，并非定律——Q4、Q5 和 Q9 会重新排序）：

• 工作量（首次发布后的维护、公告协调）：版本化发布 > 尽早发布并迭代 > 分阶段揭晓 > 延后敲定
• 价值：让参会者能预订行程并规划个人日程：版本化发布 > 尽早发布并迭代 > 分阶段揭晓 > 延后敲定
• 价值：可获得的公告时机：分阶段揭晓 > 版本化发布 == 尽早发布并迭代 > 延后敲定——有据可依的平局理由：两者都会一次性公布完整日程，因此各自只带来一个公告时机；更新日志会改变回访者看到的内容，却不会增加公告次数。
• 效率：尽早发布并迭代 > 分阶段揭晓 > 版本化发布 > 延后敲定

支配关系检查：4 个等级、6 组配对、零组严格支配关系——只有刻意设计才能做到这一点，但这不代表过关。 两种机制阻止了这 6 组配对形成支配关系：

• 单看工作量就阻止了其中 4 组：规划价值较高的等级，维护成本必然更高。其中包括所有 3 组与延后敲定的配对——延后敲定是因为价值较低而落后，并非免费赢得任何优势；还包括版本化发布与尽早发布的配对——版本化发布在规划价值上领先，公告时机上打平，但成本仍然更高。
• 价值轴之间的冲突阻止了另外 2 组：尽早发布与分阶段揭晓之间的配对，以及分阶段揭晓与版本化发布之间的配对。

这项检查在此处没有发现问题。

• 尽早发布并迭代——默认选项，也是有资料支持的建议：“不要等到日程完美才发布——尽早发布并迭代。”它把已发布的日程视为一份不断更新的文档，这也是唯一坦诚承认日程安排经常变动的策略。
• 分阶段揭晓——先公布演讲者和演讲内容，之后再公布日程。成本低，还能带来第二波宣传；只是旅行规划得等到第二波信息公布后才能开始。
• 版本化发布——投入不足的选项：尽早发布，_并且_保留明显标记，说明自上次发布以来哪些内容发生了变化，让已经规划好行程的人能看出哪些安排变了。规划价值最高，工作量也最大，因为维护它是一项持续任务，而非一次性工作。适用条件：多天、多会场轨道的日程，参会者会据此制定个人日程；变更在售票后发生；或者活动逐年举办，受众回访时会期待一贯的可靠性。
• **删除，不要降级保留：**只要参会者需要长途出行才能到场，就不要采用延后发布日程。提前两周才发布的日程，无法为两个月前预订的航班提供参考；把这个选项放在排序末尾，正是忙碌的项目主席最容易采用它的原因。它只适用于同城、小型聚会级别的活动，没人会为了参加而专门买票出行。

后期确定的热点议题场次（不在选项列表中，可与任何等级兼容）：在快速变化的领域（Q11），组织者反映，去年的热门话题很快就会过时。发布日程时自行设定若干个标记为“主题稍后公布”的场次，并在活动临近时通过 samber/dev-event-organizer-skills@event-speaker-sourcing 补上内容。场次、会议室和时间都已确定；只有演讲内容会晚些确定。

失败模式

• 多位演讲者的分享被重复安排。 检查了每位联合演讲者的时间窗口，却没有检查交集。要明确计算交集；只要有一位联合演讲者无法出席，就不能安排该场分享。
• 容量不匹配。 预估某场分享规模较小，于是安排在小房间，结果人太多，有人被挡在门外。分配场地前先估算人数；凡是有可能超出容量的活动，都安排到更大的房间——房间过大只会显得冷清。
• 开始时间同步，走廊拥堵。 所有房间同时散场，涌向无法承载这么多人的场地。PyCon US 的错峰安排是有资料佐证的反例：它牺牲了整点开始的整齐规则，换来了畅通的走廊。
• 没有为房间转换留出缓冲时间。 时间表中的间隔仿佛两场活动之间不会发生任何实际工作，尤其是在活动形式需要变化的房间里。场地转换确实需要时间，而且取决于前后两场活动的组合。
• 把借用的启发式方法当成活动领域的事实，或把有来源支持的发现视为普遍适用。 heijunka 类比来自制造业，而非活动领域，应始终标明这一点。关于冷门时段和午餐后低潮的来源确实是针对活动和生理学的研究，但测得的幅度来自经济学会议和实验室数据，而非开发者大会——除非你有自己的数据，否则只引用趋势，不引用具体数值。
• 在排期表中重新讨论分会场数量。 排期表排不下，并不意味着应该增加一个分会场——该决策由 samber/dev-event-organizer-skills@event-format-selection 负责，且已经作出；在排期过程中增加分会场，会悄然改变与之配套的内容构成。
• 以深度内容开启混合型晚间活动。 把最进阶的演讲放在最前面，会导致非技术观众整晚都不再参与。顺序应从宽泛内容逐步过渡到进阶内容。
• 只运行一次冲突检测。 每次调整都会使之前的检查失效。每次变更后都要重新检查，包括发布后做出的调整。

衡量

这里的每个阈值都由你自行设定，而不是要达到的基准。介绍时请说明这一点。

• 各房间的准时开始率（自行设定）：在缓冲时间内开始的场次所占比例。某个房间全天都在拖延，说明缓冲时间设定有问题，而不是演讲者的问题。
• 缓冲时间消耗程度分级（阈值由你自行设定；分级方式借鉴自生产缓冲管理）：实际消耗了多少缓冲时间，按「充裕 / 趋紧 / 超出」来判断，而不是按「准时 / 迟到」来判断。
• 场地适配结果（自行设定）：统计超出房间容量的场次，以及几乎空场的场次。前者是公开发生的失误，后者是容量浪费；两者的比例能帮助你估算下一届的需求。
• 发布后变更次数和最后变更日期（自行设定）：排期表公开后调整了多少内容，以及最后一次调整发生得多晚。这决定了下次是否值得付出成本，采用版本化发布流程。
• 报告的场次冲突（自行设定）：活动结束后的问卷询问参与者当时难以取舍的是哪两场。效率排序会忽略受众重叠度，而这项衡量是唯一能反映这一因素的方法。
• 每个时段的缺席率（活动排期指南中提及的一项方法，由你跟踪）：未到场人数占预期人数的比例，按时段位置记录，而非按场次记录。如果某个时段在多场活动、多个届次中持续表现不佳，那么无论已发表的资料如何概述一般时段情况（参见上文的「能量曲线排期」），它在你的场地上就是冷门时段。

选择其中两到三项，写下每项会触发的调整，并在活动开始前记录下来，而不是等活动结束后再记录。

调度示例

• “我们有 42 场已接收的演讲、四个会场和两天时间。帮我排出日程表。”
• “我们的会场分布在三层，去年大家赶场总是迟到——我们需要预留多少缓冲时间？”
• “我们的两个分会场面向相同的受众。怎样才能避免把它们安排在同一时间？”
• “一位主题演讲嘉宾只能在周六上午 11 点抵达。应该把她安排在哪个时段？”
• “我们现在就发布日程，还是等最终确定后再发布？”

预期输出：一份日程计划，涵盖以下内容：

1. 时长标准，以及每个时段包含的内容。
2. 已安排的固定环节及其安排理由。
3. 休息时间和全体同步环节。
4. 各会场的安排，以及每个会场容量估算的依据。
5. 完整日程表。
6. 冲突检测的深度检查过程及其发现。
7. 缓冲时间，以及核对过的步行距离。
8. 分会场的开场时间对齐情况及原因。
9. 标注为判断的节奏评估。
10. 交给 samber/dev-event-organizer-skills@event-run-of-show 的突发情况处理优先顺序。
11. 标注日期的发布策略。

按章节逐一呈现，供验证后再对外发布。

参考资料

• references/grid-mechanics-and-clash-types.md - 按会场和时间组织的日程表模型；详细说明四种冲突类型分别能发现和遗漏哪些问题；区分会场可用性与演讲者可用性，以及多位演讲者的可用时间交集；说明休息时间与内部阻塞项的区别；并提供正反时段安排示例。
• references/published-schedule-benchmarks.md - FOSDEM 和 PyCon US 发布的日程表；并列对比两种不同的拥挤度策略；列出关于节奏安排与低谷时段的具名组织者和经同行评审的来源；说明每份日程表未展示的内容。
• references/production-scheduling-concepts.md - 本技能借鉴的制造业排程概念（分级缓冲区、带稳定性锁定的突发情况重新排程、换场排序、均衡节奏），明确说明每项概念如何对应；还列出不适用的部分，以及不得沿用的数值。

另请参阅同一集合中的：

• samber/dev-event-organizer-skills@event-format-selection - 确定本日程表所采用的分会场数量、活动形式和演讲时长组合。
• samber/dev-event-organizer-skills@event-talk-selection - 提供带有形式和分会场标签的已接收演讲。
• samber/dev-event-organizer-skills@event-venue-sourcing - 提供本日程表所依据的座位容量、步行距离和合同时间窗口。
• samber/dev-event-organizer-skills@event-speaker-experience - 收集会影响时段安排的演讲者出行和可用时间限制。
• samber/dev-event-organizer-skills@event-run-of-show - 在活动当天执行本日程表。
• samber/dev-event-organizer-skills@event-cfp-design - 负责征稿表单中的可用时间字段，以及是否添加该字段的设计决策。