建立pg导航基线：把现状盘清楚
做pg导航落地项目，第一步不是动手改页面，而是把现在的入口状态盘清楚。很多团队一上来就重新排菜单，结果改完发现原来的高频入口被埋得更深。基线阶段的目标只有一个：让所有人对“现在长什么样”有一致认知。
准备材料：一份现有导航截图或结构导出、一份近两周的入口点击记录（如果有）、一份团队内部“找不到入口”的反馈汇总。没有数据也没关系，用人工走查替代。
本阶段要完成的事：
- 列出当前所有一级入口及其指向的目标页面
- 标注每个入口被使用的场景，例如查资料、提交内容、查看状态
- 记录已经确认失效或指向错误页面的入口
- 把“没人知道该放哪”的入口单独列成待定区
退出条件：能画出一张现状图，并指出至少三个明显问题，例如入口重复、命名含糊、层级过深。基线没完成之前，不要进入下一步。
第一阶段：产出可用的pg导航入口草案
这一阶段的目标是拿出一个能讨论的入口草案，而不是最终版。草案的价值在于把分歧提前暴露出来，避免后期返工。
输入：上一阶段的现状图与问题清单。输出：一份一级入口不超过七个、每个入口都有明确命名和指向的草案。
操作步骤：
- 把现有入口按使用场景重新分组，而不是按部门或系统归属分组。
- 为每组选一个最直白的名字，避免内部术语和缩写。
- 给每个入口写一句“点进去能做什么”，用来检验命名是否准确。
- 把待定区里的入口暂时挂到最接近的分组下，并标记为待确认。
- 把草案贴到团队能看到的地方，收集一轮书面反馈。
常见坑：把“网站导航”当成收藏夹来堆链接，入口越多越显得完整，实际使用时会让人犹豫。草案阶段就要克制数量。
退出条件：草案能覆盖基线阶段列出的主要场景，且每个入口都有人能说清它的用途。
第二阶段：按任务流校准pg导航结构
草案有了，接下来要按真实任务流校准。校准不是重新设计，而是检查“用户带着一个任务进来，能不能顺着入口走到目标”。
本阶段的目标：让pg导航在常见任务路径上不出现断点。输入：入口草案、三到五个典型任务描述。输出：校准后的结构说明与调整记录。
校准时要逐条走查：
- 任务一：新成员第一次找入口，能否在两步内到达目标
- 任务二：老成员重复访问，能否直接定位到常用页面
- 任务三：临时需要某个冷门页面，能否通过搜索或二级入口找到
- 任务四：入口命名是否在不同角色之间产生歧义
每发现一个断点，就记录“任务—断点—调整方式”三列，方便后续复盘。调整时优先改命名和分组，其次才考虑增加入口。
退出条件：典型任务都能走通，且调整记录里没有未处理的断点。
第三阶段：让pg导航进入可维护状态
结构定下来之后，真正决定成败的是它能不能被维护。很多pg导航落地项目在交付当天看起来不错，几周后因为没人负责更新而逐渐失效。
本阶段目标：建立最小维护机制。输入：校准后的结构说明。输出：一份维护责任说明和一份变更记录表。
需要落实的事项：
- 指定一个入口负责人，负责接收新增或修改请求
- 约定变更频率，例如每两周集中处理一次
- 每次变更都写入记录表，包含时间、入口、原因
- 每季度做一次快速走查，确认没有失效指向
常见坑：把维护交给“大家”，结果没人真正负责。责任要落到具体角色，而不是一个模糊的群体。
退出条件：负责人明确，记录表已建立，且至少完成一次变更记录。
退出条件与交接：pg导航上线前怎样验收
交接不是把文件发出去，而是让接手的人能独立判断“这个入口该不该加”。验收时按下面的顺序检查：
- 确认基线阶段的问题清单已逐条处理或有明确结论。
- 确认入口草案的每个命名都能被非项目成员理解。
- 确认典型任务走查记录完整，断点已关闭。
- 确认维护责任人和变更记录表已就位。
如果以上四项都能给出明确答复，pg导航落地项目就可以进入交接。交接后保留一个短周期的观察窗口，用于收集真实使用中的反馈，再决定是否微调结构。整个过程不追求一次到位，而是让每个阶段都有清晰的退出条件，避免问题被带到下一阶段。 pg导航