场景搭建：某场馆夜场的三类需求
某场馆的夜场安排在一个周末晚间，现场没有专职的技术值守，只有两名轮换的协调人员。他们需要在同一时间段内照顾三类需求：一是场内大屏需要稳定的实时比分呈现，二是到场观众希望用手机随时查看观赛助手给出的进程提示，三是赛后需要一份可回看的简要记录，方便第二天交接。
这里提到的星空体育平台，并不是一个单独的硬件，而是把实时比分、观赛助手和资讯条目放在同一套使用流程里的统称。场景的难点不在功能多少，而在于当网络和人力同时吃紧时，先保哪一项、后放哪一项。
约束条件：网络、人手与信息延迟
先把约束摆清楚，后面的推演才有意义。当晚的约束大致有三条：
- 场馆内公共网络在入场高峰时会出现短时波动，手机端刷新不一定即时；
- 协调人员只有两人，一人负责入场引导，另一人兼顾屏幕与记录；
- 实时比分本身存在客观延迟，观赛助手的提示也依赖同一份数据源，二者不会完全同步。
这三条约束决定了不能追求“全都要、全都快”，而要在场景里排出优先级。约束不是缺陷，而是推演的前提。
推演过程：从实时比分到观赛助手的取舍顺序
把当晚的决策拆成顺序步骤，比一次性铺开更容易执行：
- 开场前，先确认大屏端的实时比分展示是否稳定，把它作为第一优先项，因为它是全场共享的信息面。
- 入场高峰时，暂缓对观赛助手的密集推送，避免手机端在弱网下反复重试，把有限带宽留给比分刷新。
- 中场休息时，网络压力下降，再恢复观赛助手的进程提示，让观众自行查看关键节点。
- 结束后，用同一套记录口径整理资讯条目，只保留可核对的比分节点与时间点，不做主观评价。
这个顺序的核心判断是：共享信息优先于个人提示，稳定优先于丰富。星空体育平台的价值在场景里体现为取舍的余地，而不是功能清单的长度。 观赛助手
边界情形一：网络持续波动时
如果波动不是短时而是持续，就需要把观赛助手降级为“仅查看、不推送”，并把大屏比分改为固定间隔刷新，减少重试次数。此时不追求即时感，而追求可读性。
边界情形二：只有一人在场时
单人值守时，记录与展示会互相打断。可行的做法是先把实时比分展示固定下来，记录改为赛后补录，并明确补录只写时间点与比分，不写过程描述，避免事后回忆造成偏差。
边界情形三：观众自带数据源时
部分观众会同时打开其他来源，出现数字不一致。这时不争论谁更准，而是说明场内展示的口径与刷新节奏，把差异归因于延迟，而不是归因于某一方出错。
复盘与决策备注
夜场结束后回看，真正影响体验的不是功能多寡，而是约束下的顺序安排。可以留下三条备注：第一，实时比分的展示稳定性要放在观赛助手之前考虑；第二，观赛助手的推送节奏应跟随网络状况调整，而不是固定不变；第三，资讯条目的整理要克制，只保留可核对的信息，避免把推演写成结论。
这套推演并不适用于所有场馆，它只是某一次夜场的场景记录。把它当作一份可调整的参考，而不是标准答案，才更接近场景案例本来的用法。