活动上线前，先想一想用户会在哪一步卡住

活动页面准备发布，团队已经核对了设计、文案和上线时间。还可以换一个问题：“假如发布后报名失败，用户可能在哪一步被卡住？”这不是预言活动一定出问题，而是从不希望发生的结果出发，提前找出值得检查的地方。

从具体结果倒推，而不是只列担心

逆向思考可以先描述一个不理想的结果，再问它需要什么条件才会发生。例如，报名页面已经上线，但有人无法完成报名。可能的原因包括入口链接错误、截止时间让人误解，或者报名名额已满却没有清楚提示。

这些只是候选原因，不能当作真实故障。下一步要对照实际页面、流程和已有资料，判断哪些情况适用、现有措施是否覆盖，以及需要谁检查。没有出现过的场景，也不能因为写进清单就变成统计上的高概率事件。

事前验尸（Premortem）是其中一种更具体的做法：先假设项目未来已经失败，再请参与者回想可能导致失败的原因。它适合用来打开讨论；独立提出意见可以减少大家只跟随第一种说法的情况。事前验尸与一般的逆向提问有关，但不是完全相同的概念。

下面仍以假设的活动报名页面为例。具体操作和责任人要根据实际系统、时间和授权确定。

序号	假设情况	发布前可做的检查
1	用户从宣传链接进入了错误页面	逐个打开准备发布的入口，核对目标页面和活动名称
2	用户误解截止时间	检查日期、时间和适用时区是否一致，交给未参与制作的人阅读
3	名额已满，用户不知道下一步	在允许的测试环境中检查满额提示及联系入口

为每项检查写下负责人、完成时间和结果。涉及实际提交时，先确认使用测试环境或获得授权；不要为了验证反复向真实报名系统写入数据。遇到结果不明的提交，先确认记录是否存在，再决定是否重试。

也可以为重要环节准备恢复办法：如果某个入口无法访问，由谁确认问题、何时暂停推广、用户可以联系谁。恢复动作应由有权限的人决定，不能仅凭 AI 的推测操作正式系统。

把已知的页面流程和约束提供给 AI，可以请它按用户入口、信息理解、提交结果和后续联系等环节提出待核对的问题。先去掉不需要的个人资料、账号和密钥，再用实际流程逐项筛选。

以下是活动页面的脱敏流程：[填写入口、时间、报名步骤与已知限制]。请假设用户未能完成报名，列出可能原因、每个原因需要的触发条件、已有防护和不修改真实数据的检查方式。区分事实、假设与未知，不要编造概率或声称发生过事故，也不要执行操作。

风险清单越长并不自动越好。先挑影响较大、能够检查且在当前资源内处理的事项，把不确定之处留给对应负责人。检查后记录实际结果：哪些通过、哪些需要修复、哪些因为条件不足暂时未知。