场景与约束
某团队正在搭建内部的星空入口，用来承载分散在多个子系统的页面与功能导航。场景并不复杂：成员每天要在若干系统之间来回切换，入口页承担聚合与跳转的角色。真正的难点不在页面本身，而在约束。
第一类约束来自访问：入口需要在内网与部分外网环境下都能打开，但团队并不希望把全部子系统的鉴权逻辑重新实现一遍。第二类约束来自维护：负责入口的只有一两个人，任何方案都必须能被快速理解和接手。第三类约束来自边界：入口只做导航与聚合，不承担业务逻辑，也不复制子系统里的数据。
这三类约束决定了推演的方向——先确认入口该做什么、不该做什么，再讨论怎么接。
推演路径
团队把推演拆成几步，按顺序推进，每一步都留下可回看的记录。
- 列出入口清单。把成员高频访问的页面按用途分组，标注哪些必须直达、哪些只需跳转。清单只记录事实，不做优先级排序。
- 划出职责边界。明确入口负责展示与跳转，鉴权交给各子系统，入口只透传登录状态。边界写下来，避免后续反复争论。
- 选择接入方式。在自建页面与聚合配置之间做取舍：自建灵活但维护成本高，聚合配置上手快但受限于既有能力。团队按维护人力做了倾向性选择，并记录理由。
- 做小范围试运行。先让一个小组使用，观察打开速度、跳转是否顺畅、登录状态是否透传，收集问题而不是收集好评。
- 形成回滚预案。保留旧入口一段时间，出现异常时可以切回，避免把所有成员卡在新入口上。
推演过程中，团队刻意把“要不要做搜索”“要不要做个性化推荐”这类问题放到边界分支里讨论，而不是在主线里展开，避免范围失控。
边界分支
分支一：外网访问是否必须
如果外网访问只是少数人的临时需求，可以先不做，用其他方式过渡；如果它是常态需求，就要在接入方式选择时提前考虑，而不是上线后再补。团队的做法是先确认需求频率，再决定是否纳入本期范围。
分支二：子系统数量增长怎么办
入口清单会随子系统增加而变长。团队约定按用途分组、定期清理失效条目，避免入口页变成一张越堆越乱的清单。这一条不需要技术方案，只需要维护习惯。
分支三：登录状态透传失败
这是推演中最容易被低估的分支。团队的做法是把失败表现记录下来，区分是子系统侧的问题还是入口侧的问题，再决定由谁处理，而不是在入口里加一层兜底逻辑。
复盘与决策备注
复盘时，团队没有去统计提升了多少效率，而是回看几个更朴素的问题：入口清单是否准确、职责边界是否被遵守、试运行中发现的问题是否都有归属、回滚预案是否真的可用。这些问题的答案决定了这次推演是否站得住。 星空入口实用指南
决策备注里写下了三条：第一，星空入口的定位是导航与聚合，不承担业务逻辑；第二，接入方式的选择以维护人力为主要依据，而不是以功能多少为依据；第三，任何新增需求先判断属于主线还是边界分支，再决定是否纳入本期。
对类似团队来说，这份推演的价值不在于给出标准答案，而在于把约束摆到前面，让取舍有据可依。星空入口的落地是否顺利，往往取决于这些看似琐碎的边界是否在动手之前就想清楚。