PRD写清楚了范围，不代表业务程序已经实现。交付检查要把每条要求转换成可操作的检查步骤，并记录实际结果、证据和未完成事项。
本文使用演示项目“社区读书会报名页”的需求输入说明清单写法。当前记录的是需求整理，不是已建成的报名系统或客户交付。
从需求逐条映射到检查动作
演示输入限定为单场活动、20个名额。居民查看时间地点，以昵称和自设口令报名或取消；组织者查看名单与余位。不收集手机号，不做付款、消息通知、多场活动或社交功能。可据此建立验收表：
需求：活动最多20人。
检查：从空名单连续完成20个有效报名；第21个报名被拒绝。
证据：记录每次结果、名单数量和剩余名额。
需求：重复报名不能重复占位。
检查：由需求方确认“同一报名者”的识别规则后，按该规则再次提交；确认系统反馈且名额不再减少。
证据：保存操作前后名单与余位。
需求：取消释放名额。
检查：使用对应昵称和口令取消；名单移除该记录，余位增加1。
证据：记录取消前后的名单和余位。
需求：不采集手机号、不做付款和通知。
检查：逐页检查输入项与流程，不应要求手机号、支付或消息授权。
证据：记录检查过的页面和流程。
上面是建议的检查设计，不是执行结果。没有可运行版本和实际操作证据时，结果应写“未测试”或“待验证”，不能标成通过。
PRD里还要保留的待确认项
这个需求没有确定报名者识别方式（昵称是否唯一、重名如何区分）、口令找回规则、组织者身份验证与名单访问权限、数据保存方式，也没有说明同时争抢最后名额时的预期。把这些单列为待确认，并在实现前由需求方决策。未确认事项不能悄悄转成验收通过标准。
可使用下面的通用交付检查 prompt：
请根据已确认的需求和实际可运行版本，生成验收检查表。
每条检查包含：对应需求、前置条件、操作步骤、预期结果、实际结果、证据位置、状态。
规则：
- 只把亲自执行并有证据的项目标为通过；未执行写“未测试”。
- 缺少可运行版本、账号或数据时，列为阻塞条件。
- 将需求未确认项单列，不推断为已实现。
- 检查不包含范围，确认没有意外加入手机号、付款、通知或其他未要求功能。
- 不要因为PRD、截图或代码存在，就认定业务流程已实现。
交付时检查范围与证据
除了核心流程，交付包还应说明实际交付物、启动或访问方式、已知限制和本次未包含内容。对演示或原型，要清楚标记“演示项目”；没有验证业务效果时，不写获客、收益、节省时间或提升比例。
每一项状态都应能回答：谁执行了什么步骤、看到了什么结果、证据在哪里。若付款、持久化、部署或生成流程尚未完成，就写明未完成或未验证，不用未来计划代替测试记录。
下一步
本例的需求来源和范围记录见社区读书会报名页演示记录，AIPRD入口为 aiprd.cc/app。如果还在整理原始一句话需求，可先看小样任务拆解，或截图需求底稿。报价、付款节点与交付物可继续核对外包报价/验收清单包。