清楚的需求，应该让业务、研发和测试人员对同一个场景得到一致的理解：哪些条件适用，系统应当怎样处理，以及怎样判断结果符合预期。
在软件工厂中，你可以通过对话补充这些信息，让 AI 整理为需求材料，再逐项审阅。本篇继续使用“会员活动目标人群筛选”示例，说明如何把业务想法写成可以实现和检查的规格。
分清规则、场景与验收标准
业务规则描述功能始终需要遵守的约定。例如：“会员等级、地区和消费时间条件同时选择时，只保留同时满足全部条件的会员。”
场景描述一次具体使用过程。例如：“运营人员选择金卡会员和上海地区，然后执行筛选。”
验收标准说明在约定条件下应当观察到什么结果。例如：“使用指定样例数据筛选后，只匹配会员 A、B，覆盖人数显示为 2。”
规则为实现提供依据，场景帮助检查规则在具体情况下如何生效，验收标准则为判断结果提供明确条件。
先确定本期范围和业务口径
本例沿用两个需求项：组合条件筛选和覆盖人数预估。“保存筛选方案”留到后续，不加入本期的交付范围。
为每个需求项补充规则时，先明确：
- 使用者与对象：谁可以操作，处理哪些会员或数据？
- 条件与计算方式：多个条件如何组合，人数如何统计？
- 边界：条件为空、日期恰好位于起止日、会员从未消费时怎样处理？
- 异常：输入不合法或数据暂时无法取得时，用户看到什么，下一步可以做什么？
- 数据口径：以哪个数据来源和统计时点为准，页面如何说明更新时间？
“最近消费时间”尤其需要解释清楚：是最近下单时间、支付成功时间，还是其他业务事件的时间。使用相同词语的团队成员，也可能对它有不同理解。
把模糊描述改成可以检查的约定
上表是写法示例。具体规则和指标需要团队确认；尚未确定的值可以列为待确认事项，补齐依据后再写入正式规格。
涉及性能等质量要求时，要把适用条件与目标放在一起。例如，单人操作和多人同时操作可能需要不同的验证场景，验收时应采用约定的条件。
完整示例：筛选条件与覆盖人数
下面使用固定的教学数据演示写法。实际项目还需要确认可访问的会员范围、数据来源与更新频率。
业务规则
- 会员等级、地区和最近消费日期之间取交集；未选择的条件不限制结果。
- 本例将“最近消费时间”定义为最近一次支付成功的时间。
- 消费日期按北京时间解释，包含开始日和结束日的全天。开始日期晚于结束日期时，提示“开始日期不能晚于结束日期”，并要求修正后再执行筛选。
- 选择消费日期条件时，从未消费的会员不匹配；未选择该条件时，是否消费不影响筛选。
- 覆盖人数按会员去重计算。成功完成统计且没有匹配会员时，显示 0 人，并保留筛选条件。
- 统计失败时，显示暂时无法获取人数及重试入口，保留筛选条件；本次人数显示为不可用，避免将失败结果展示为 0 人或沿用旧人数。
其中，条件组合与日期处理属于“组合条件筛选”；人数去重、空结果和统计失败处理属于“覆盖人数预估”。两项共同使用同一组会员匹配规则。
固定样例数据
下表列出本次验证使用的全部会员，时间均为北京时间。验证过程中保持数据不变。
选择“金卡、上海、2026 年 9 月 1 日至 9 月 20 日”时，预期只匹配 A、B，覆盖人数为 2。
用“前置条件—操作—预期结果”描述场景
这个结构也常写作 Given、When、Then。可以直接使用中文描述：
前置条件：使用上述固定样例数据，操作者可以访问表中全部会员，数据统计服务正常。 操作：选择会员等级为金卡、地区为上海、消费日期为 2026 年 9 月 1 日至 9 月 20 日，执行筛选。 预期结果：仅 A、B 符合条件，覆盖人数显示为 2。开始日零点与结束日最后一秒的消费均被计入，下一日零点的消费不计入。
即使页面只展示人数，研发和测试人员仍可以用这组数据核对匹配逻辑。是否向用户展示会员明细，应由需求范围另行约定。
为关键边界补充验收标准
以下场景均基于上述数据和访问范围；除“统计失败”外，统计服务保持正常。
异常场景需要与研发或测试人员约定可重复的验证方法，例如在测试环境中使数据服务暂时不可用。写清触发条件，后续才能判断异常处理是否符合要求。
保留业务约束，分别整理实现方案
需求阶段应写清用户可观察的行为和必须满足的业务约束。例如，“没有查看权限的人员不能查看覆盖人数”是一条业务规则，需要同时补充权限来源和相应验收场景。
具体接口地址、请求结构、数据库表和实现代码，可以在技术设计中展开。已有系统的集成限制、兼容性要求或必须采用的数据来源，也应明确提供给研发人员，并注明依据。
软件工厂会检查结构化规格中的规则和验收标准；部分混入具体接口或报文写法的内容也会影响提交校验。出现相关提示时，保留业务含义，将实现细节整理到技术设计材料中，再重新检查。
让 AI 协助补全，但由团队确认规则
你可以在需求会话中使用以下指令：
请按需求项整理业务规则、场景和验收标准。检查条件组合、空值、日期边界、重复数据、权限和异常处理是否存在歧义。对适用的场景，写出前置条件、操作和可观察的预期结果。使用我提供的样例数据计算预期人数，并说明哪些会员被计入。缺少依据的规则请列为待确认事项，注明需要确认的问题，不要直接当作既定规则写入。
收到结果后，逐项确认 AI 补充的内容是否属于本期范围。规则有变动时，让 AI 更新相关场景、验收标准和原型，再核对样例结果。
待确认事项可以记录为：“待确认消费数据多久更新；由会员数据负责人提供结论；该结论影响人数展示口径与验收时点。”这样，团队能够知道需要补充什么，以及哪些内容会受影响。
提交前做一次内容审阅
- 每个需求项中的规格条目都有相应规则与验收标准，能够单独说明预期行为。
- 同一个术语在提案、规格和原型中含义一致，数量、单位、时间范围和时区清楚。
- 关键规则至少有一个可检查的场景，重要边界和异常有对应预期。
- 样例数据能够得到唯一的预期结果；涉及动态数据时，明确验证所用的统计时点。
- 待确认问题已标明影响，关键业务决定已有负责人确认，本期范围得到团队认可。
提交校验会检查材料是否满足提交条件，内容质量仍需要团队审阅。文档中的验收标准描述预期结果；实际测试与业务验收还需要执行检查并记录结论。
材料准备完成后，可以按提交你的第一个需求中的步骤进行提交。