先摸清现状：建立导航基线
动手改配置之前，先做一件事：把当前pg模拟器导航的现状记录下来。没有基线，后面每一步改动都无法判断是变好还是变坏。这一步的产出是一份现状清单，而不是任何修改。
- 目标：知道现在有哪些入口、哪些能用、哪些长期没人点。
- 输入：现有导航条目、使用者的实际操作习惯、当前配置文件。
- 输出：一份逐条标注状态的基线表。
- 退出条件：每条导航都能说出“谁在用、用来做什么”。
准备阶段最容易踩的坑，是凭记忆整理。建议一边操作一边记录，把每条入口的实际跳转结果写下来，而不是照抄旧文档。 pg模拟器导航实用指南
第一阶段：让导航入口可用且可核对
第一步的目标很窄：让每个入口点得开、跳得对。不要在这一步做分类美化，先把可用性立住。
- 逐条点击现有入口，记录跳转结果与预期是否一致。
- 把失效或指向不明的条目单独列出，暂不删除，只做标记。
- 为每条保留的入口补一句用途说明，写清适用场景。
- 把标记为失效的条目移入待处理区，避免混在常用区。
这一步的退出条件是：常用区里不再有打不开的入口。达到之后才进入下一阶段，否则后面的规则整理都会建立在不可靠的基础上。
第二阶段：把适配与配置沉淀成可复用规则
入口可用之后，问题会从“能不能打开”变成“该不该放在这里”。第二阶段的产出是一套简单的分类与命名规则，让后来者不用重新猜。
- 目标：同类入口归到一起，命名能自解释。
- 输入：第一阶段的基线表与用途说明。
- 输出：分类规则、命名约定、每条入口的归属说明。
- 退出条件：新加一条入口时，能按规则直接判断放在哪。
常见的坑是分类过细。层级一多，维护成本立刻上升，使用者反而找不到东西。宁可少分几类，也要保证每类都有明确边界。
第三阶段：完成核对、记录与交接
第三步不是继续加功能，而是让别人能接手。交接做不好，前两阶段的成果会在几次改动后失效。
- 按基线表逐条复核，确认状态与记录一致。
- 把分类规则、命名约定和待处理区说明写成简短文档。
- 指定一位维护人，写清改动后需要更新哪些记录。
- 安排一次由接手人独立操作的验证，观察是否能按文档完成一次新增入口。
退出条件是：接手人不询问原作者，也能独立完成一次入口调整并更新记录。达不到这一点，说明文档还缺关键信息。
复核关卡与后续维护
三个阶段之间各有一道关卡，关卡不过就不要往下走：基线不清不做入口整理，入口不可用不沉淀规则，规则没文档不做交接。后续维护建议保持低频复核，每次改动只动一处并立即更新记录，这样问题范围始终可控。
把pg模拟器导航当成一份需要定期核对的清单，而不是一次配置完就结束的项目，维护成本会低很多。