一个人做产品，发布前最容易犯的错不是代码没写完，而是把"我用标准流程跑通了"当成"用户能用"。你熟悉每一条路径、每一个按钮的位置，这种熟悉会替你自动补全缺失的说明、跳过的步骤和含糊的报错。检查清单的作用，就是把这层自动补全强行拆掉，逼自己站到一个第一次听说这个产品的人的位置上。

本文按用户路径组织检查项：首次了解、注册进入、核心使用、反馈离开。AI 在这条路径上适合做两件事——生成初稿、指出遗漏；不适合做一件事——替你判断质量是否达标。发布与否的决定权必须留在你手里。

为什么按用户路径而不是按功能模块检查

按功能模块列清单，你写出来的一定是"登录页正常、支付正常、导出正常"，因为那正是你脑子里的结构。但用户不这样走。一个真实用户看到的是：我为什么要点进来、我点了之后要做什么、我做完之后会发生什么、出问题了我该找谁。

腾讯云 ADP 的一篇上线检查清单文章提到，很多问题的共同来源是测试环境和真实用户之间的表达差异——测试时用标准问法，用户实际输入千奇百怪。这篇文章针对的是 AI Agent 部署，但它按维度拆解检查项的思路对独立开发者同样成立：真正会翻车的地方通常不在你测过的地方，而在你从没想过要测的地方。

按路径走，检查项会自然落到四个阶段，每个阶段的失败代价不同：首次了解阶段失败，用户根本不会进来；注册阶段失败，用户留不下账号；使用阶段失败，用户会流失；反馈阶段失败，你连自己错在哪都不知道。

阶段一：首次了解——更新说明与第一印象

检查项

• 产品一句话说明能否让陌生人说出它是干什么的
• 更新说明是否写清"这次变了什么、对用户有什么影响"，而不是罗列提交记录
• 落地页上承诺的能力，产品里是否真的存在
• 价格、额度、限制的表述是否一致，没有前后矛盾的数字

AI 可以怎么用

把更新日志、README、落地页文案一起丢给 AI，让它只做一件事：找出三份材料互相矛盾的地方，以及任何在落地页被承诺但更新说明里没提到落地的功能。这类交叉核对人眼容易漏，因为它需要同时记住三份文本。

示例提示词：

下面是我的落地页文案、更新日志和 README。
请只做两件事：
1. 列出三份材料之间互相矛盾或口径不一致的地方；
2. 列出落地页提到、但更新日志和 README 里找不到对应落地说明的功能。
不要评价文案好坏，不要改写，只做比对。

更新说明本身也适合让 AI 出初稿：把这次改动的提交信息或待办清单贴进去，让它按"用户能感知的变化"重写一遍，你再删掉它编出来的细节。

阶段二：注册与首次进入——别让用户卡在门口

新用户最脆弱，任何一点不确定都会让他关掉页面。这一阶段的检查项包括：

• 注册必需信息是否减到最少，能不能先体验再注册
• 验证、激活类邮件或短信是否说明"接下来会发生什么"
• 首次进入是否有明确的第一步指引，而不是一个空白界面
• 权限、数据用途的说明是否出现在需要它的位置，而不是埋在条款里

AI 在这里的用途是模拟一个挑剔的新用户。把注册流程的分步截图或文字描述给它，让它逐条提问："我不知道这里该填什么""这个按钮点下去会扣费吗"。它提出的问题不一定都对，但能把你自己已经无感的模糊点暴露出来。

阶段三：核心使用——帮助文档、错误提示、测试场景

这是检查量最大的一段，也是最容易用 AI 提效的一段。建议拆成三块并行推进。

帮助文档

先别急着写完整手册，先写"最小可用文档"：覆盖三条最高频路径和三个最高频失败场景。让 AI 基于你的功能列表和界面说明生成初稿，然后做两件事——

1. 逐条核对它写的内容是否真的符合产品现状，AI 很容易按通用产品逻辑补出你没有的功能；
2. 标出它没写但你实际遇到过的问题。

一份可参考的做法是把边界输入——长文本、特殊字符、空列表、弱网——存成一张固定清单，每次新功能交付前让 AI 按清单逐条过一遍。这个思路在掘金的一篇独立开发自测实践里有更具体的描述，可以直接借来当模板。

错误提示

错误提示的检查标准很简单：用户看完之后知道发生了什么、能不能自己解决、下一步做什么。常见问题包括只显示错误码、把技术栈信息暴露给用户、以及"操作失败"这种什么都没说的提示。

让 AI 帮你做一次审计：把所有报错文案列出来，让它逐条回应"如果我是一个不懂技术的用户，看完这句话我知道该做什么吗"。它给出的改写不用照抄，但它指出的"这句话没有信息量"通常是对的。

测试场景

把 AI 当场景生成器，而不是测试执行者。给它你的功能说明和用户路径，让它列出：

• 正常路径下的每一步预期结果
• 每一步可能失败的输入和失败后应有的表现
• 中断、返回、重复提交、并发操作等非顺序操作

生成之后，你自己判断哪些值得测、哪些是它想多了。AI 列不全的地方恰恰是你的业务知识所在，这部分只能靠你补。

阶段四：反馈与离开——让问题找得到你

• 应用内是否有不需要登录就能看到的反馈入口
• 反馈后是否有明确的响应预期说明
• 用户想注销、导出数据、退款时，路径是否写清楚
• 你自己是否有一个地方能集中看到这些反馈

一个实用做法是维护一份固定的反馈分类表：功能问题、文档问题、计费问题、其他。让 AI 把用户原文归类并提取关键信息，你只看归类结果和原文，能省下不少整理时间。但归类结果必须抽查，AI 对语气模糊的反馈经常会分错。

AI 辅助的边界：初稿可以给，裁决不能给

把上面四段的 AI 用法压缩成一句话：它负责生成初稿和扩大覆盖面，你负责判断是否正确、是否足够。以下这些事不要交给 AI 下结论——

事项	AI 可以做	必须人工确认
更新说明	按用户视角重写初稿	每条改动是否真实发生
帮助文档	生成结构与示例	步骤能否在真实产品中走通
错误提示	找出无信息量的文案	文案与实际错误原因是否对应
测试场景	列举边界与异常输入	哪些场景对业务真正重要
发布决定	汇总待办与风险点	是否上线、何时上线

一份可以立刻跑起来的最小流程

如果你今天就要发，按这个顺序做：

1. 列出四阶段的主路径，每阶段写三到五个检查项。
2. 把更新日志、帮助文档初稿、错误提示列表分别交给 AI 生成或审计。
3. 让 AI 输出"你不确定或没提到的地方"清单，你逐条判断。
4. 自己完整走一遍从了解到反馈的路径，中途不跳过任何一步。
5. 记录下这次实际发现的问题，补进下一版清单。

跑完第一轮你会发现，真正需要改的往往不是功能，而是那些你从来没写下来过的默认假设。清单的价值不在于一次检查完就结束，而在于每发一次版本，它就比上一版更贴合你自己的产品。