模板 · PRD 与验收

适用：定义一个可交付的版本或功能。方法见 PRD。

从两种合理实现，找出必须写清的规则

虚构示范：“退出后恢复进度”可能被实现成恢复关卡编号，也可能恢复全部未提交路径。两者都说得通，玩家经历却不同。

先写承诺保存什么、何时确认，再填状态和验收。若写入失败，不能无依据显示保存成功；若旧存档不兼容，要定义保留原记录和可恢复出口。这样规则就从一句期望变成可以复现的行为约定。

原型可以明确保留未知，但同一轮测试必须固定实际方案。文档不必替代接口设计，高后果的资产、状态和恢复却不能只写“异常时处理”。

文档与问题

• 名称、负责人、版本、日期、关联任务：
• 修订记录（改了什么、为什么）：
• 背景、证据与待解决问题：
• 人群、触发场景与用户故事：
• 目标、指标、基线、窗口与护栏：
• 本次范围、非目标与依赖：
• 比较过的方案、所选理由与改变选择的条件：

流程与状态

主流程（用步骤或图说明）：

状态	进入条件	可见信息与可操作项	退出条件	异常与恢复
初始
处理中
待确认
成功／失败

规则与内容

• 资格、次数、时间、排序与冲突优先级：
• 资源发放／消耗／权益期限：
• 关卡或内容配置、版本与来源：
• 文案、交互、视觉、音效与无障碍：
• 前后台、断网、重复操作、重启和旧版兼容：
• 隐私、授权、平台能力与材料核验：

验收与数据

编号	前置条件	操作／触发	用户可见结果	资产／数据结果	验收证据
AC01

• 指标／事件表链接及触发定义：
• 目标设备和性能条件：
• 关键错误、日志与对账方式：
• 上线门槛、发布观察与回滚：
• 未决问题、负责人和解决日期：

验收：成功、取消、失败、重复、状态未知和恢复有明确定义。涉及奖励与付费的规则能逐笔解释，客户端技术实现另链接工程方案。