先摸清现状：pg导航落地项目的基线准备
做pg导航落地项目，最容易踩的坑是一上来就动手改入口。第一步不是改，而是把现状记录下来。准备阶段的目标只有一个：让后面每个阶段都有可对照的起点。
你需要准备三样东西：一份现有入口清单、一份真实任务清单、一份可回滚的备份。入口清单记录当前网站导航里有哪些栏目、层级有多深、哪些是长期没人点的；任务清单记录用户实际会做的事，比如找资料、找入口、找更新；备份则是为了在结构调整不理想时能退回去。
- 入口清单：按层级列出全部导航项，标注层级深度与最后调整时间。
- 任务清单：用一句话描述用户要完成的事，不要写成栏目名。
- 备份与记录：保存当前配置，并留一份变更日志模板。
基线阶段结束时，你应该能回答：现在的pg导航里，哪些入口是任务必需的，哪些只是历史遗留。这个答案决定了后面两个阶段改什么、不改什么。
第一阶段：把入口结构整理成可用的导航骨架
第一阶段解决的是“能不能找到”。目标是把入口从堆叠状态整理成有层次的骨架，让每个入口都能对应到一类任务。
输入是基线阶段的入口清单与任务清单，输出是一份新的网站导航结构草案。做法上建议先归类，再定层级，最后定命名。
- 把入口按任务类型分组，同一组的入口放在同一层级。
- 控制层级深度，超过三层的入口考虑合并或下沉到二级页面。
- 用任务语言命名入口，避免使用内部才懂的缩写。
- 把被合并或删除的入口记入变更日志，说明原因。
这一阶段常见的坑是“为了整齐而整齐”：把入口归得很漂亮，但用户原来熟悉的路径被切断了。判断标准很简单——拿任务清单逐条走一遍，看能否在不搜索的情况下到达目标。如果走不通，就回到分组重新调整。
退出条件：每个任务都能在导航骨架里找到至少一条明确路径，且入口层级不超过约定深度。 pg导航资讯
第二阶段：让pg导航贯穿真实任务流
第二阶段解决的是“用起来顺不顺”。骨架有了，但用户是否愿意按它走，取决于导航是否出现在任务发生的地方。
输入是第一阶段的导航骨架，输出是任务流与导航的对应关系表。你需要把任务清单里的每件事，标注它在哪个页面、哪个位置需要导航支持。
- 任务起点：用户从哪进入，导航是否给出下一步。
- 任务中断点：用户在哪容易迷路，是否需要就近入口。
- 任务结束点：完成后是否有回到主路径的出口。
这一步可以按顺序推进：先处理高频任务，再处理低频但关键的任务，最后处理长尾。每处理一类，就用真实路径走一遍，记录卡点。这里的坑是把导航当成装饰，只在首页放一次；实际做法是让pg导航在任务的关键节点重复出现，但不要堆满整页。
退出条件：高频任务路径上不再出现“找不到下一步”的情况，且每个卡点都有对应的入口调整记录。
第三阶段：把导航交出去并保持可维护
第三阶段解决的是“能不能持续用”。pg导航落地项目不是一次性工程，交不出去就等于没做完。
输入是前两个阶段的骨架与任务流对应表，输出是一份可执行的维护说明。维护说明要写清楚：谁负责改、多久检查一次、改动后如何验证。
- 指定维护责任人，并明确改动入口需要经过谁确认。
- 约定检查节奏，例如按发布周期或按季度复核一次。
- 每次改动后，用任务清单抽三条路径做回归验证。
- 把验证结果记入变更日志，形成可追溯的记录。
这一阶段的坑是只交接结构、不交接判断标准。接手的人如果不清楚“为什么这样分组”，很快就会把入口加回去。因此维护说明里要保留基线阶段的任务清单，作为后续调整的依据。
退出条件：维护责任人能独立完成一次入口调整，并说出调整依据。
阶段验收门与交接清单
三个阶段之间不是自然过渡，而是有明确的验收门。前一阶段没通过，就不要进入下一阶段，否则后面会反复返工。
- 基线门：入口清单与任务清单齐全，能区分必需入口与遗留入口。
- 骨架门：每个任务至少有一条明确路径，层级符合约定。
- 任务流门：高频路径无中断，卡点有记录与处理。
- 交接门：维护责任人、检查节奏、验证方式均已确认。
交接时建议同时移交三份材料：导航结构说明、任务流对应表、变更日志。这三份材料合起来，就是一份可复用的pg导航实用指南，也是下一次调整的起点。
把pg导航落地项目拆成阶段来做，好处是每一步都有可检查的产出。你不必一次做对所有事，只要在每个验收门前停下来确认，导航就会从混乱的入口列表，逐步变成支撑真实任务的结构。