用一张每周汇总表限定第一期
假设业务人员每周从三个门店收集订单表，合并后统计已付款订单。本期目标写成：“读取指定目录内符合格式的订单文件，按订单日期筛选上一自然周的已付款订单，生成明细、门店汇总和异常清单。”报表是否自动发给外部收件人，不包含在这句话里，需要单独决定。
贯穿测试使用三条示例记录：订单 A001 已付款 600 元，A002 已付款 900 元，A003 已取消 200 元；三条日期均落在目标周。预期结果是两笔有效订单、合计 1,500 元，取消记录不计入。这个小例子是后续核对的基准。
交付物一：覆盖例外的样本包
样本包至少包含正常文件、空文件、缺少必需列的文件、完全重复的订单、同一订单编号但金额冲突的记录，以及跨周日期。每个样本附一行预期处理结果。门店原始文件应保留，流程在副本上验证，避免试运行改变后续核对依据。
样本不是越多越好。十个完全相同的正常文件，检验不了“订单编号相同、金额不同”时会怎样。优先补齐会改变处理路径的情况。
交付物二：一张能执行的规则表
| 项目 | 约定 | 不满足时 |
|---|---|---|
| 统计时间 | 订单日期在上周一至周日，含首尾日期 | 日期无法识别则进入异常清单 |
| 有效状态 | 仅统计“已付款” | 已取消单列数量，其余未知状态提示确认 |
| 唯一标识 | 订单编号在本次数据范围内唯一 | 完全相同的重复行只计一次；冲突行暂停计入 |
| 文件结构 | 包含订单编号、订单日期、门店、金额、状态 | 缺列时拒绝该文件并列出缺失列 |
“智能去重”不能代替上述约定。若业务中一个订单允许分次收款，应先改变数据粒度和唯一标识，再处理样本；否则去重本身会删除有效记录。
交付物三：结果旁边有核对依据
输出除汇总数字外，还应包含采用的明细、排除记录及原因、读取的文件名和目标周。对于示例数据，读者能够从 600 加 900 得到 1,500，并找到 200 元被排除的理由。如果只给出一个总数，人员发现差异后仍要从头翻文件。
遇到异常时，可以继续生成一份清楚标记“存在未处理记录”的预览，但不能把它命名为已确认的正式报表。是否允许部分结果用于内部查看，应在规则里说明。
交付物四：双方看得懂的验收记录
| 输入变化 | 预期结果 |
|---|---|
| 使用三条基准记录 | 有效两笔，金额 1,500 元，排除一笔取消订单 |
| 再加入一条相同 A001 | 金额仍为 1,500 元，并记录一次去重 |
| 把新增 A001 金额改成 650 元 | 标出 A001 冲突，不悄悄选一条覆盖 |
| 某文件删去“状态”列 | 报告该文件缺列，结果显示文件未纳入 |
验收记录应写明实际输出、样本版本与结论。需求方确认业务解释，开发方确认程序行为，两者都通过才算这项规则完成。
交付物五：下周换个人也能运行
交接说明需要写清文件放哪里、怎样选择统计周、输出保存在哪、异常找谁核对、规则变更由谁确认。再做一次由实际操作员独立完成的运行：开发人员不代为放文件、不口头补步骤，观察说明是否足够。
首版完成后，下一项扩展应来自真实运行记录。例如“经常收到门店新增的支付状态”比“顺便做个大屏”更有明确依据。每次扩展都增加对应样本和规则，避免流程只有最初演示时可靠。