如何让 Codex 检查产品导航是否清晰

产品导航不清晰时，用户通常不会直接说“你的信息架构有问题”。他们的真实反馈往往是：我找不到入口、这个功能在哪里、返回之后不知道在哪一层、移动端菜单点开以后更乱、同一个功能在不同页面叫法不一样。

这类问题不能只靠设计师凭感觉判断。尤其是 SaaS Dashboard、内容工具、后台系统、会员系统和多页面产品，导航问题经常藏在路由、组件、页面命名和权限逻辑里面。Codex 的价值不只是“看页面好不好看”，而是可以进入代码仓库，把导航结构、页面路由、菜单配置、组件状态和交互路径一起检查出来。

这篇文章讲的是一套可执行方法：如何让 Codex 把产品导航拆成具体检查项，输出问题清单、风险等级、修改建议，并在低风险范围内帮助你修正导航体验。

一、为什么产品导航要交给 Codex 检查

导航问题不是单个菜单的问题，而是“用户能不能在产品里稳定找到目标”的问题。真实项目里，导航混乱通常来自四个地方：页面越做越多、功能入口重复、命名没有统一标准、移动端和桌面端采用了两套不一致的结构。

如果只看一张截图，很容易漏掉深层问题。例如顶部菜单看起来正常，但侧边栏层级过深；首页入口清楚，但进入设置页以后没有返回路径；PC 端有面包屑，移动端却没有当前位置提示；管理后台里同一个页面在菜单叫“客户”，页面标题叫“用户管理”，URL 又叫“accounts”。这些都属于导航清晰度问题。

Codex 更适合做这类检查，是因为它可以读取实际项目文件，找出菜单配置、路由结构、页面组件、文案命名、状态样式和重复入口之间的关系。它不只是给主观建议，而是可以把问题定位到具体文件和具体页面。

二、Codex 可以检查哪些导航问题

其中“跨页一致性”和“当前位置”很容易被忽略。W3C 的 WCAG 也把一致导航和一致识别作为可访问性里的重要要求：重复出现的导航机制应保持相对顺序一致，功能相同的组件也应保持一致命名。放到产品设计里，这其实就是降低用户记忆负担。

三、不要这样问 Codex

很多人会直接对 Codex 说：帮我看看这个产品导航清不清晰。这个指令太空。Codex 可能会输出一堆宽泛建议，例如“建议优化导航层级”“建议统一菜单命名”“建议增强用户引导”，但你很难知道应该改哪个文件、改到什么程度、怎么验收。

错误指令示例：

帮我检查一下这个产品导航是否清晰，有问题就优化一下。

这个指令的问题有三个：没有说明检查范围，没有说明不能改什么，没有给出输出格式。导航检查很容易牵连页面结构，如果不限制范围，Codex 可能会直接重构菜单组件，甚至改动路由和布局。

四、正确做法：先审查，再决定是否修复

检查产品导航时，不建议一开始就让 Codex 直接修改代码。更稳的流程是分两步：第一步只审查，不改代码；第二步根据审查报告选择低风险问题让 Codex 修复。这样可以避免 Codex 为了“优化导航”而做过度重构。

• 先让 Codex 读取路由、导航组件、页面标题、侧边栏、顶部菜单、移动端菜单和权限逻辑。

• 要求 Codex 输出导航结构图，说明一级、二级、三级入口分别对应哪些页面。

• 让 Codex 按严重程度标记问题：高风险、中风险、低风险。

• 只让 Codex 对低风险问题给出可执行修改方案，例如统一命名、补 active 状态、增加面包屑、修复移动端入口。

• 修复后再让 Codex 做一次回归检查，确认导航路径、页面标题和菜单状态一致。

五、Codex 一键执行指令：只审查，不改代码

下面这条指令适合第一次使用。它不会让 Codex 直接改项目，而是让它输出一份导航清晰度审查报告。

你现在是产品信息架构审查员和前端代码审查员。请检查当前项目的产品导航是否清晰。 【任务目标】 只做审查，不要修改任何代码。请基于真实代码仓库检查产品导航结构、路由结构、菜单命名、当前位置提示、移动端导航和用户路径是否清晰。 【请重点读取】 1. 路由配置文件，例如 app/、pages/、router、routes、navigation、menu 等相关文件。 2. 导航组件，例如 Header、Sidebar、Nav、TabBar、Breadcrumb、MobileMenu、DrawerMenu。 3. 页面标题、面包屑、按钮入口、空状态入口和权限控制相关代码。 4. 移动端导航、响应式菜单、底部 Tab 或抽屉菜单相关组件。 【检查维度】 1. 一级导航是否覆盖产品核心任务。 2. 二级导航是否按用户任务分组，而不是按技术模块分组。 3. 菜单命名、页面标题、URL、按钮入口是否一致。 4. 用户进入内页后是否能知道当前位置。 5. 是否存在入口重复、入口缺失、死入口、无权限入口。 6. 是否存在层级过深、核心功能隐藏过深的问题。 7. PC 端和移动端导航是否保持同一套信息结构。 8. 是否具备 active 状态、面包屑、返回路径、空状态引导。 9. 键盘访问、aria-current、nav 语义和焦点状态是否基本可用。 【输出格式】 请按以下结构输出： 一、当前导航结构梳理 - 一级导航： - 二级导航： - 关键用户路径： - 移动端导航结构： 二、问题清单 请用表格输出： 问题位置 / 问题类型 / 严重程度 / 具体表现 / 影响用户 / 建议处理方式 / 涉及文件 三、导航清晰度评分 请从 0 到 100 分打分，并说明扣分原因。 四、优先级建议 请分为： P0：必须修复，否则影响用户完成核心任务 P1：建议尽快修复，会明显影响理解效率 P2：可优化，主要影响一致性和专业感 五、暂不建议修改的部分 请说明哪些问题需要产品决策，不应该由 Codex 直接改代码。 【限制】 - 不要修改代码。 - 不要新增依赖。 - 不要改变业务逻辑。 - 不要重新设计视觉风格。 - 不要把所有导航重构成另一套架构，只输出审查报告。

六、审查报告应该怎么看

Codex 输出报告后，不要只看评分，要重点看三个部分：涉及文件、问题影响、建议处理方式。导航问题最怕“看起来都对，但没人知道怎么改”。一个合格的报告必须能告诉你：问题发生在哪个组件、影响哪条用户路径、应该优先改哪一类问题。

• 如果问题集中在菜单命名，说明产品语言不统一，优先做文案和命名收敛。

• 如果问题集中在页面层级，说明信息架构需要重新分组，不能只改 UI。

• 如果问题集中在当前位置提示，通常可以低风险修复，例如补 active 状态、面包屑、页面标题。

• 如果问题集中在移动端，说明响应式导航不是简单折叠，而是需要重新考虑入口优先级。

• 如果问题涉及权限和角色，需要先确认业务规则，不要让 Codex 直接猜。

七、Codex 低风险修复指令

如果审查报告里大部分问题属于命名不一致、active 状态缺失、页面标题不统一、面包屑缺失或移动端菜单状态混乱，可以让 Codex 做低风险修复。

请基于上一轮导航清晰度审查报告，对当前项目做低风险导航优化。 【允许修改】 1. 统一导航菜单、页面标题、面包屑、按钮入口中的同类命名。 2. 修复当前菜单 active 状态、aria-current、焦点样式和当前页面识别问题。 3. 为二级或三级内页补充合理的面包屑或返回路径。 4. 优化移动端导航展开、关闭、当前状态和菜单分组展示。 5. 删除明显重复的导航入口，但必须确认不会影响核心路径。 6. 补充空状态中的返回入口或下一步引导。 【禁止修改】 1. 不要重新设计整套视觉风格。 2. 不要改变核心路由结构，除非审查报告明确指出是死路由或重复路由。 3. 不要新增大型依赖。 4. 不要修改后端接口、权限规则和数据结构。 5. 不要移除业务功能。 【输出要求】 1. 先列出计划修改的文件和修改原因。 2. 再进行修改。 3. 修改后输出变更摘要。 4. 说明每一处修改对应解决了审查报告中的哪个问题。 5. 运行项目已有的 lint、typecheck、test 或 build 命令。 6. 如果无法运行，请说明原因，并给出人工验收步骤。 【完成标准】 - 核心导航命名一致。 - 当前页面有明确的 active 状态或位置提示。 - 移动端导航可以打开、关闭、识别当前位置。 - 不破坏原有页面布局和业务流程。 - 没有新增明显的控制台错误和类型错误。

八、AGENTS.md 中可以加入的导航审查规则

如果你经常让 Codex 检查页面和导航，建议把导航规则写进 AGENTS.md。这样以后每次涉及导航组件、页面结构、路由调整时，Codex 会先读取这些约束，不需要你每次重新解释。

产品导航审查规则

除非任务明确要求，不要重做整套导航系统。导航标签、页面标题、面包屑和主要按钮文案要保持一致。主导航应该代表用户能理解的任务，而不是数据库字段或代码模块名。新增页面时，要判断是否需要导航入口、面包屑、当前状态、返回路径或空状态入口。不要为同一个目标创建重复导航入口，除非存在清楚的用户路径理由。嵌套页面要让用户知道自己在哪里，以及如何返回。桌面端和移动端应共享同一套信息架构，交互项必须有可见焦点状态。当前页面需要清晰 active 样式，必要时使用 aria-current="page"。修改路由结构前，先说明影响并确认。修改后运行 lint、类型检查、测试或构建，并手动验证首页到核心功能、列表到详情、详情返回、移动端菜单、刷新后的当前状态、未授权和空状态路径。

九、适合让 Codex 检查的产品类型

不是所有导航问题都适合直接交给 Codex，但下面这些项目非常适合用 Codex 做结构审查。

• SaaS Dashboard：模块多、侧边栏复杂、设置页深，很容易出现功能入口重复。

• 后台管理系统：权限、角色、数据页面多，容易出现无权限入口和页面命名不一致。

• 内容型网站：栏目、标签、专题、文章页关系复杂，容易让用户不知道当前位置。

• AI 工具站：功能入口、模板库、历史记录、账号中心、订阅页之间需要清晰路径。

• 移动网页和小程序：屏幕小，底部 Tab、顶部菜单和抽屉菜单容易互相冲突。

• 设计系统较弱的项目：导航组件分散在多个页面里，状态和命名难统一。

十、哪些问题不应该让 Codex 直接决定

Codex 可以帮助你发现导航问题，也可以执行低风险修复，但它不应该替代产品决策。下面这些问题需要你先做判断，再让 Codex 执行。

• 一级导航到底放哪些业务模块。

• 是否合并两个功能模块。

• 是否砍掉某个低频但重要的入口。

• 不同角色的权限入口是否调整。

• 产品是否从内容导航改成任务导航。

• 移动端是否采用底部 Tab、顶部菜单还是抽屉菜单。

这些问题背后是产品定位、用户任务和商业目标。Codex 可以给建议，但最终需要产品负责人或设计负责人确认。

十一、导航清晰度验收标准

十二、Codex 回归验证指令

导航改完后，需要让 Codex 再检查一次，不要只看页面有没有报错。

请对刚才的导航修改做一次回归验证。 【验证目标】 确认产品导航比修改前更清晰，并且没有破坏已有页面、路由和交互。 【请检查】 1. 一级导航、二级导航、页面标题、面包屑是否命名一致。 2. 当前页面 active 状态是否正确，包括刷新页面后的状态。 3. 深层页面是否有返回路径或面包屑。 4. 移动端菜单是否可以正常打开、关闭、定位当前页面。 5. 是否出现重复入口、死入口、无效链接或无权限死路。 6. 是否破坏了原有布局、样式、类型检查或构建流程。 7. 是否存在明显的可访问性问题，例如焦点不可见、aria-current 缺失、nav 语义缺失。 【输出格式】 一、已通过的检查项 二、仍存在的问题 三、是否建议继续修改 四、需要人工确认的产品决策 五、已运行的命令和结果 【限制】 这一次只做验证。除非发现明显低风险错误，否则不要继续修改代码。

十三、常见错误

错误一：只让 Codex 改菜单样式

导航不清晰不一定是样式问题。很多时候菜单看起来很漂亮，但结构、命名和路径是乱的。如果只改视觉样式，用户还是找不到功能。

错误二：把所有功能都放进一级导航

一级导航不是功能清单。一级导航应该承载产品的核心任务。如果所有功能都被放到一级导航，用户会失去判断优先级的能力。

错误三：PC 端和移动端完全两套逻辑

移动端可以改变展示方式，但不应该让用户感觉进入了另一个产品。移动端导航应当继承同一套信息架构，只是入口优先级和交互方式有所调整。

错误四：页面标题、URL 和菜单名各叫各的

这会直接破坏用户的路径记忆。比如菜单叫“项目”，页面标题叫“工作台”，URL 叫 /workspace，面包屑叫“任务中心”，用户会不断怀疑自己是否点错了页面。

错误五：忽略无权限和空状态路径

导航不仅要服务正常状态，也要服务异常状态。用户没有权限、数据为空、链接失效时，都需要明确告诉用户现在在哪、为什么看不到内容、下一步能做什么。

十四、FAQ

1. Codex 能直接判断导航是否适合真实用户吗？

不能完全替代真实用户测试。Codex 可以基于代码和页面结构检查一致性、路径、命名和明显可用性问题，但它不知道你的真实用户习惯。关键导航调整仍然建议结合用户反馈、数据和产品目标判断。

2. Codex 检查导航前，我需要准备什么？

至少要让 Codex 能读取项目代码。如果有产品说明、页面地图、用户角色、核心路径或设计稿链接，也可以作为上下文提供。上下文越清楚，Codex 越不容易误判。

3. 导航审查和 UI 审查有什么区别？

UI 审查更关注视觉层级、间距、字号、颜色和组件一致性。导航审查更关注用户能否找到功能、理解层级、知道当前位置，并顺利完成任务。两者有关联，但不是同一件事。

4. 可以让 Codex 直接重构导航系统吗？

可以，但不建议作为第一步。正确做法是先让 Codex 审查，再让它输出重构方案，最后你确认产品方向后再执行。导航系统是产品骨架，不能像改按钮样式一样随意重构。

5. 如果项目没有统一的导航组件怎么办？

可以先让 Codex 找出所有分散的导航入口，整理成清单，再建议是否抽象成统一组件。不要直接让它“统一导航”，否则改动范围可能过大。

十五、总结

让 Codex 检查产品导航是否清晰，关键不是让它凭感觉评价页面，而是把导航拆成可检查的工程和产品问题：路由是否清楚、菜单是否一致、层级是否过深、当前位置是否明确、移动端是否可用、异常状态是否有回路。

最稳的流程是：先审查，不改代码；再根据报告选择低风险修复；最后做回归验证。如果把这套规则写进 AGENTS.md，Codex 就可以在后续每次改页面、加功能、调路由时自动遵守导航规范。

对达灵感这类面向 AI 任务执行的产品来说，真正有价值的不是“提示词库”，而是把这些检查流程变成可复用的任务系统。导航审查也一样：指令越具体，输出越可用，修改越可控。

参考资料

• OpenAI Developers：Codex web。

• OpenAI Developers：Codex Best practices。

• OpenAI Developers：Custom instructions with AGENTS.md。

• W3C WAI：WCAG 2.2 Understanding Success Criterion 3.2.3 Consistent Navigation。

• W3C WAI：WCAG 2.1 Understanding Success Criterion 3.2.4 Consistent Identification。