一句“做个报名页”还不足以直接开工。先把它改写成目标、用户、字段、动作、不做事项和验收条件，才能让小样有清楚的边界。
本文用一个演示项目说明拆解方法：社区读书会组织者想用手机管理单场活动报名。它不是客户案例，也不代表已经建成报名系统。
从原话到范围
演示输入是：单场读书会设20个名额；居民查看时间和地点，用昵称及自己设置的口令报名，也用这两项取消；组织者查看名单和余位。必须处理满额、重复报名和取消后释放名额。不收集手机号，不做付款、通知、多场活动或社交功能。
把这些话整理成一页任务说明：
目标：把群聊接龙改成单场活动的手机报名流程。
使用者：居民报名或取消；组织者查看名单和剩余名额。
活动范围：一期仅一场，最多20人。
报名信息：昵称、居民自设口令；活动时间和地点由组织者提供。
核心动作：查看活动、报名、取消、查看名单与余位。
本期不含：手机号、付款、消息通知、多场活动、社交功能。
待确认：口令如何找回或重置；组织者如何获得名单访问权限；活动信息由谁维护。
“待确认”要保留为问题，不要替用户擅自决定口令找回、管理权限或数据保存方式。尤其是昵称和口令是否足以防止他人代取消，需要活动组织者确认。
把验收写成可观察结果
小样任务可以要求逐项演示以下行为：
这些是建议写入小样任务的验收条件，不是已经通过的测试结果。正式实现前还要确认数据保存、组织者权限和口令安全规则。
可复制的任务整理 prompt
请把下面的一句话需求整理成可验收小样任务。先写需求，不要声称功能已经实现或测试通过。
原始需求：
【粘贴需求原话】
请输出：
1. 目标用户和本次目标；
2. 页面、字段和每个操作的预期结果；
3. 明确包含与明确不包含的范围；
4. 可由人实际操作检查的验收条件；
5. 信息不足时必须向需求方确认的问题。
不要自行补充付款、通知、手机号、账号体系或后台权限。
把假设和待确认问题分开列出，不要把建议当成已确认事实。
开始报价或开发前，先让需求方确认任务说明。需求变化时，更新范围与验收条目，再决定是否进入下一阶段。
下一步
本演示的范围来自正常访客在 AIPRD 中提交的需求；它展示需求整理过程，不证明报名程序已经生成或运行。可查看 社区读书会报名页演示记录，再按 外包报价/验收清单包 核对边界。若输入主要是截图，继续看截图如何整理成需求底稿。