第一步：盘点现有入口与使用场景
在动手搭建 pg导航 之前，先花半天把现状摸清楚。这一步不写页面、不选工具，只做记录。很多团队跳过准备阶段，直接开始堆链接，结果做出来的 pg导航 谁也记不住、谁也不用。准备阶段的目标只有一个：拿到一份能直接用于下一步的入口清单。
需要准备的材料
- 浏览器书签导出文件，或团队成员各自收藏的常用地址截图。
- 最近两周内实际打开过的系统、后台、文档与报表入口。
- 一份简单的使用场景说明：谁在什么情况下会打开哪个入口。
按顺序完成盘点
- 合并所有来源的入口，去重后得到原始清单。
- 为每个入口标注使用角色与使用频率，频率只分高频、偶尔、极少三档。
- 标出已经失效、重复或指向同一系统的入口。
- 把清单交给两三位日常使用者过一遍，补上遗漏项。
这一步的产出是一份带角色与频率标注的入口清单。放行标准：清单里没有无法说明用途的条目，且每位主要使用者都能在清单中找到自己常用的入口。
阶段一：把入口整理成可维护的分组结构
有了清单，才进入真正搭建 pg导航 的阶段。本阶段的目标不是页面好看，而是让分组结构稳定、可增删、可解释。分组方式决定了后续维护成本，因此要先定规则再动手。
本阶段目标
- 确定分组维度：按角色、按业务线或按使用场景，三选一并坚持到底。
- 控制层级深度，一般不超过两级，避免使用者反复点击。
- 为每个入口写好一句用途说明，减少猜测成本。
输入与产出
输入是上一步的入口清单；产出是一份分组草案，包含分组名称、组内入口顺序和每个入口的说明文字。顺序按使用频率排列，高频入口放在最前。
常见坑
- 同时用角色和业务线两种维度分组，导致同一入口出现在多处，维护时容易漏改。
- 分组名称过于抽象，使用者看不懂该点哪里。
- 一次塞入全部入口，把低频入口也放在首屏。
放行标准：随便找一位使用者，能在不看说明的情况下说出每个分组的用途，并找到自己最常用的三个入口。
阶段二：让 pg导航 成为团队默认入口
结构定下来之后，问题从“怎么排”变成“怎么让人真的用”。本阶段的目标是让 pg导航 成为打开浏览器的第一站，而不是又一个被遗忘的页面。 pg导航
本阶段目标
- 把 pg导航 地址固定到浏览器首页或新标签页。
- 在团队常用的沟通渠道里放一份入口说明。
- 收集第一轮真实使用反馈，记录找不到的入口。
按依赖顺序推进
- 先由维护者自己连续使用三天，确认没有明显错误链接。
- 再邀请少量使用者试用，收集“找不到”的具体场景。
- 根据反馈调整分组或补充说明，而不是直接加新入口。
- 稳定后再向更大范围公布地址。
这一步的产出是一份反馈记录和一轮调整后的页面。放行标准：试用者能独立完成至少一次完整的查找动作，且反馈中不再出现同一类结构性问题。
阶段三：建立维护节奏与交接机制
pg导航 最容易出问题的地方不是搭建，而是没人管。本阶段的目标是把维护变成有节奏的例行工作，并明确交接方式，避免维护者离开后页面失修。
维护节奏
- 固定周期核对一次失效链接，只做删除与替换，不做大改。
- 新增入口需说明用途与使用角色，避免清单膨胀。
- 结构变动前先在小范围确认，再整体替换。
交接要点
- 记录分组规则与命名习惯，写清为什么这样分。
- 保留入口清单的原始版本，方便回溯。
- 明确至少一位备份维护者，避免单点依赖。
放行标准：接手者能仅凭记录完成一次常规核对，并说清下一次结构变动的判断依据。
复盘闸门：每个阶段结束前的核对与放行
三个阶段之间不是自然过渡，而是需要明确闸门。每个闸门只问三个问题：产出是否齐全、使用者是否能独立完成目标动作、遗留问题是否已记录。任何一个问题答不上来，就停在本阶段补齐，而不是带着问题进入下一阶段。这样推进的 pg导航 不一定最花哨，但能长期被人使用和维护。