真正让产品在发布当天翻车的，往往不是没写完的功能，而是把"我已经跑通了"当成"用户能用"。开发者对产品的熟悉会无意识地补全缺失的说明、跳过的步骤和含糊的报错，这种补全发生在意识之外，常规自查很难发现。路径检查法的实质，就是用陌生人的行走顺序把这层自动补全强行拆掉。

按功能模块列清单，写出来必然是"登录正常、支付正常、导出正常"，因为那正是开发者脑中的结构。用户不这么走。他看到的是：我为什么点进来、点进来做什么、做完会发生什么、出问题找谁。按路径组织，检查项会自然落到四个阶段，且失败代价递进：前一段失败，后一段根本无从谈起。

首次了解阶段的关键动作是交叉核对落地页文案、更新日志与说明文档：承诺的能力是否真的存在，价格、额度、限制的口径是否一致。这需要同时记住多份文本，人眼容易漏，适合交给 AI 做机械比对，只让它列矛盾和缺口，不让它评价或改写。

注册与首次进入阶段的核心是减少不确定：必需信息能否更少、能否先体验再注册、验证类通知是否说明接下来会发生什么、首次进入有没有明确的第一步。可以让 AI 扮一个挑剔的新用户逐条提问，它的问题未必都对，但能暴露开发者已经无感的模糊点。

核心使用阶段检查量最大。帮助文档先覆盖最高频的路径和失败场景；错误提示要让人看完知道发生了什么、能否自行解决、下一步做什么，只显示错误码或一句"操作失败"等于没说；测试场景则把 AI 当生成器而非执行者，重心放在边界输入、异常操作、重复提交和中断返回。

反馈与离开阶段最容易被跳过：有没有无需登录就能看到的反馈入口、反馈后是否说明响应预期、注销与导出数据的路径是否写清楚。

有一条边界必须守住：初稿可以给 AI，裁决不能。某项改动是否真实发生、步骤能否在真实产品里走通、哪些场景对业务真正重要、什么时候上线，这些判断只能由发布者自己做。

今天就要发，顺序可以很简单：四个阶段各写三到五个检查项，把更新说明、帮助文档、错误提示分别交给 AI 生成或审计，再让它输出一份"你不确定或没提到的地方"逐条判断，最后自己完整走一遍从了解到反馈的全路径。第一轮跑下来通常会发现，要改的不是功能，而是那些从没被写下来的默认假设。