为什么现在做一次pg导航审计
pg导航落地项目上线之后，最容易出现的问题不是打不开，而是“还能用，但已经不对”。入口被随手加、分类被反复改名、失效链接没人清理，团队仍然每天点进去，却没人说得清当前结构是否还匹配任务。审计的价值在于把“感觉有点乱”变成可核对的事实。
本清单针对已经存在的pg导航落地项目，不讨论从零搭建。你可以把它当作一次体检：先定范围，再按组逐项打勾，最后按整改顺序处理。
先划定审计范围与准备材料
第一步不是打开页面挑毛病，而是明确这次审计覆盖什么。范围不清，检查结果就无法收敛。 网站导航
- 确认审计对象：是全部入口，还是某一条任务流涉及的入口集合。
- 准备入口清单：导出当前所有条目，含名称、地址、所属分组、最近修改人。
- 准备任务清单：列出团队最常执行的几条任务，作为判断入口是否有效的参照。
- 准备权限说明：谁可以新增、改名、删除入口，是否有审批环节。
- 约定记录方式：每项检查只记“通过 / 不通过 / 待确认”，避免主观描述。
准备阶段常见坑是范围过大。第一次审计建议只覆盖一条主任务流，跑通流程后再扩展。
入口与任务流清单
这一组检查回答一个问题：用户能不能从入口顺利走到目标。逐项核对，不要凭印象。
- 每个入口都能对应到一条具体任务，而不是“可能有用”。
- 同一任务在导航中只有一个主入口，重复入口已合并或标注关系。
- 入口名称使用团队内部通用说法，新人不需要额外解释。
- 分组顺序与任务发生顺序一致，而不是按添加时间排列。
- 每个入口点击后落在预期页面，无跳转错误或空白页。
- 入口描述不超过一句，说明“用来做什么”而非“是什么系统”。
如果这一组不通过项超过三处，先不要动结构，优先修入口本身，否则结构调整会掩盖问题。
结构与可维护性清单
第二组检查回答另一个问题：这套导航能不能被长期维护。结构问题往往比入口问题更隐蔽。
- 分组层级不超过两层，第三层内容已改为标签或搜索解决。
- 每个分组有明确负责人，新增入口需要经过该负责人确认。
- 失效链接有固定清理节奏，且清理记录可查。
- 命名规则统一，不混用缩写、全称和英文。
- 导航页面本身有变更记录，能回溯最近几次调整的原因。
- 存在一个“待归类”区域，临时入口不会直接混入正式分组。
维护性检查的重点不是当前是否整齐，而是下一次变更会不会再次失控。
危险信号与整改顺序
审计结束后，先识别危险信号，再决定先改什么。以下情况出现任意两条，说明结构已经影响使用：入口数量在短期内明显增长却无人清理；同一任务出现三个以上近似入口；分组名称与团队实际说法脱节；无人能说清某个入口的负责人。
整改顺序建议如下：
- 先修失效与错误跳转，这类问题影响最直接。
- 再合并重复入口，减少选择成本。
- 然后统一命名与分组顺序。
- 最后补上负责人和变更记录，防止问题复发。
每一步完成后重新跑一遍对应清单，确认通过项增加再进入下一步。审计不是一次性动作，把它固定成周期性检查，pg导航落地项目才不会退回入口混乱的状态。