先区分愿望与可执行需求
“导出做得好一点”很难验收。使用 Claude 整理需求时，先说明用户是谁、要完成什么任务、当前问题和已知限制。需求应能让开发与测试理解同一个结果。本文例子为虚构产品设想，不表示本站已提供相关功能。
准备目标、范围和排除项
目标写用户需要解决的问题，范围写本轮具体做什么，排除项写本轮不覆盖什么。例如只讨论导出选中记录，不包括自动邮件发送或批量账号管理。范围越模糊，模型越容易添加你没有决定的能力。
虚构案例：导出已选记录
材料：“用户选择三条记录后可以导出；只有查看权限的人不能导出；导出失败时要提示。”可整理成选择范围、权限条件、成功结果和失败提示四项。文件类型没有提供时应待确认，不能自行补成Excel或PDF。
用条件和结果描述验收
可以按“给定条件、操作、预期结果”组织。给定拥有导出权限且选中三条记录，执行导出后结果包含这三条；给定只有查看权限，则不能执行导出。未选记录的行为还未定义，需要提出问题，而不是猜测导出全部。
把未决问题单独列出来
需要确认的可能是文件类型、字段顺序、空值显示、最大记录数和失败后能否重试。模型可以提示你遗漏了这些维度，但不能代替业务做决定。每项问题标负责人或确认渠道，没有明确时写待分配。
检查条件是否彼此冲突
如果一条要求所有人可导出，另一条又限制查看用户，就应列冲突与来源。不要生成看似完整却互相矛盾的说明。引用原材料编号，确认优先级后再生成最终需求。保留原始版本，便于后续追踪变更。
常见问题：需求能直接交给开发吗
先由相关人员确认范围、权限和验收条件，再讨论实现与测试。Claude输出是整理稿，不是已经评审通过的决定。版本变化可参考《Claude 文档对比教程：核对版本差异与新增条件》；验收条件确定后再设计测试场景。