PRD、用户故事与验收标准

你写下“看完广告发一个提示”，实现者觉得很明确。直到玩家中途关闭、重复回调或奖励结果不确定，才发现每个人理解的“看完”和“发一次”都不同。

本篇帮助你把一句意图推导成可实现、可测试、可追溯的行为约定。广告情境是设计示例，具体能力需核验 平台专题。

为什么用户故事还不是验收标准

“作为首次玩家，希望看到路径反馈，以便知道连接是否有效”说明了谁、想做什么和目的，却没有说明无效连接是否高亮、松手后保留什么、反馈何时消失。不同实现都可能自认为满足故事。

用户故事负责保留动机；验收要写前置、动作和结果。这样才能用同一个情境判断完成，而不是用“体验不错”争论。PRD 的长度以消除会影响行为的歧义为准，接口细节可链接工程文档，规则与用户承诺应在正文中可见。

从一次奖励请求，推出必须写的分支

如果奖励请求可能重复回报，那么按每次回调发奖，就可能把一次承诺执行多次。因此要有稳定请求标识与一次权益发放的约定。若结果仍未知，立即显示成功又会承诺尚未确认的权益；若无广告就卡死，又把可选交换变成了核心流程门槛。

前置／触发	应有行为	为什么要这样约定
点击获取提示	先说明交换条件，再进入流程	让玩家知道自己选择什么
中途关闭	回到原关卡，保留已有资源	没完成交换不应损失原有权益
收到有效完成结果	同一次请求只发一次对应提示	回调次数不等于奖励次数
无广告或加载失败	可重试或继续原玩法	外部供给失败不应让玩家无路可走
结果不确定	可解释、可恢复的待确认状态	不能把未知当成功或直接抹掉请求

这里定义产品承诺；技术方案再落实状态保存、幂等与核对。幂等可以理解为：同一个请求重复执行，最终权益与执行一次一致，而不是简单屏蔽所有重试。

为什么先枚举状态，能减少补丁

“加载中”“展示中”“待确认”“成功”“失败”不是换几种按钮文案，而是回答哪些动作现在允许、系统正在等待什么、重启后如何继续。

假设展示中仍可连续点击，就可能产生多次请求；重启时把待确认清空，又可能失去补发线索。把迁移写成“触发＋条件＋输出”，能在开发前发现这些冲突。另需检查前后台、断网、旧版本和存档冲突，涉及次数、价格、资格、排序和奖励的规则写清单位与冲突优先级。

最小完整文档为什么要保留背景和非目标

背景证据解释为什么此时投入，目标说明要改变什么，范围与非目标限制发散；流程、状态、规则与数据保证落地；验收、依赖和发布让完成可核对。缺背景，未来容易保留已无意义的功能；缺非目标，执行中就容易把合理的扩展当成本版承诺。

版本与变更原因也很重要：当测试用旧规则、研发看新副本时，再清楚的文档都无法形成同一约定。独立开发写给未来自己的文档，同样会遇到这个问题。

适用边界：精确不等于提前锁死一切

还没验证的原型可以保留候选方案，但要标清本次测试到底采用哪种，不能混用。低风险文案不必写成长规格；高风险权益与恢复则不能只留一句“异常时处理”。

评审时分别从玩家、研发、测试和运营角度复述：看得懂吗、闭环吗、能复现吗、上线后能解释吗？代码合并只是一步，实际验收还包括用户行为、异常恢复、数据对账与上线材料。

练习：用 PRD 模板 写“退出后恢复关卡”，覆盖写入失败、存档版本不兼容和连续退出。每个分支都解释：若不约定，会出现哪两种不同实现。