截图能帮助确认页面上看得见的文字、控件和布局，却不能单独说明用户身份、数据如何保存、点击后的行为或后台权限。先把可见事实与待追问问题分开，再形成需求底稿。
本文以演示项目“社区读书会报名页”为例。输入是文字需求，不是客户截图；这里不声称AIPRD执行了OCR或处理了真实客户材料。
先记录能确认的内容
如果手上有截图，可以逐项抄录并标注来源：
演示输入明确给出的产品范围是：单场读书会、20个名额；居民查看时间地点，以昵称和自设口令报名或取消；组织者查看名单与剩余名额；需要处理满额、重复报名和取消释放名额。不采集手机号，也不做付款、消息通知、多场活动或社交功能。
截图看不到的行为要追问
截图无法回答以下问题，需求底稿应标记“待确认”：
没有确认之前，不要自行写成手机号登录、短信验证码、管理员后台或永久保存。演示范围明确排除了手机号。
可复制的截图整理 prompt
请依据我提供的截图或文字材料整理需求底稿，不要开始写代码。
请分成三部分：
A. 材料中直接可见或明确写出的事实；
B. 仅凭材料无法确认、需要向需求方追问的问题；
C. 暂不纳入范围的功能。
对每个页面列出可见标题、字段、按钮和状态文字；对每个按钮，只记录材料明确说明的动作。不要推测截图外的登录、保存、通知、支付、权限或接口行为。
最后给出可由需求方确认的范围摘要和验收问题。
若材料里没有行为说明，可在访谈后补一张流程表：操作人、前置条件、动作、成功结果、失败结果。将推测保留为问题，不让它悄悄变成开发要求。
从底稿到可报价清单
演示项目的一期边界可以写为：一个活动信息页、一套报名与取消动作、名单和余位展示；名额上限20人；覆盖满额、重复报名及取消后释放名额。明确不含手机号、付款、通知、多活动和社交功能。
验收条目应写可观察结果，例如“满额后新报名被拒绝且余位仍为0”，而不是“报名功能正常”。口令重置、组织者名单权限与数据保存策略仍需确认，不能提前算作交付要求或通过结果。
下一步
需求边界确认后，再将它拆成可验收小样任务，参见一句话需求拆解方法。本演示的输入过程和事实边界见社区读书会报名页演示记录；AIPRD入口在 aiprd.cc/app。准备报价和交付时，可使用外包报价/验收清单包。