评审结论

这套方案目前只能算“页面填充数据骨架”，还不是可支撑多域联调、财务对账、核销逆账、分销结算和生产演示的测试数据方案。

最大问题有五类：

  1. 实体模型明显不完整：已有“核销、福钥、账单争议、分销”等域没有在实体清单中展开，无法验证跨域一致性。
  2. 数量与状态比例偏向正常成功流：订单、核销、账单数量关系不闭合，异常、并发、逆向、跨周期场景不足。
  3. 真实价格采集不等于真实测试数据：直接使用真实商户、真实价格、真实路线会带来合规、时效、地域误导和业务规则缺失。
  4. “先 DELETE is_test 再 INSERT”不是可靠幂等：存在并发执行、外键、误删、部分失败、主键引用、事务过大等风险。
  5. 生产演示库仅靠 is_test 隔离不够：它解决不了支付、通知、搜索、报表、导出、权限、缓存和外部接口的副作用。

一、实体、数量和状态分布缺陷

1. 明显漏掉或未展开的实体

1.1 分销域实体缺失

材料只写了“分销域已有”，但当前规格没有任何分销实体和数量设计。

至少应明确是否包含：

依据：材料只定义了商户、商品、订单、核销、账单等实体，没有分销商、归因、佣金和结算实体；但审问明确要求关注已有分销域，因此当前数据无法验证“分销下单—核销—佣金生成—退款冲正—结算”的完整链路。

1.2 福钥记账域实体不完整

材料仅写：

商户服务费三档（300/1200/3800）各2条缴费记录+福钥余额对账

这不是完整的账务数据模型。至少还应有：

依据：“缴费记录+余额对账”只覆盖业务表层结果，不能验证余额由流水推导、重复记账、失败重试、冲正和对账差异处理。

1.3 两段核销实体和事件链不清晰

规格只有一个 redemption_events，但写了“覆盖两段核销全状态”。

这里至少需要区分：

依据：单独一个事件表无法证明两段核销的业务语义、顺序约束、部分核销、重复核销和逆账关系。尤其“撤销逆账5条”只给了数量，没有说明对应原核销、账务方向和状态关系。

1.4 账单域实体不足

当前只有 bills，但账单争议通常不是一个状态字段就能覆盖。至少需要：

依据：材料要求覆盖“待确认/已确认/自动确认/争议”，但没有定义争议发起方、争议原因、处理结果、金额调整和与核销明细的关联，无法测试争议闭环。

1.5 通用基础实体也不完整

材料未涉及，但真实联调通常还需要：

依据：当前设计强调“三端可点通”，但仅有业务主表并不等于支付、库存、退款、审核、异步通知等依赖链可运行。

2. 数量关系不闭合

2.1 核销数量与订单数量关系不合理或未定义

订单 120+，核销事件 60+，这本身不一定错误，但必须明确：

依据：材料要求核销订单状态为“已付/服务中”，但没有覆盖“已完成订单对应核销”的关系，也没有定义核销与订单状态是否双向驱动。

2.2 订单状态比例失真

当前订单分布：

问题包括：

依据：当前状态列表无法覆盖订单生命周期中常见的失败和逆向分支；且状态数量加总虽为120，但“120+”与固定分布存在规格歧义。

2.3 商品数量与商户数量关联不足

80+商品分布为：

但未规定：

依据：仅有总数，无法保证“全业态覆盖”在商品层真正成立，可能出现商户有记录但没有可售商品。

2.4 用户数量自相矛盾

用户表写：

游客30/商户 owner 10/领队3/平台运营1

总数为44，不是“测试用户40+”的明确设计，虽然符合“40+”，但还存在：

依据：30+商户要求每个商户至少一个owner，但owner只有10个，直接违反关联完整性约束，除非一名owner可关联多个商户，而材料没有说明。

3. 状态覆盖不足

3.1 商户状态不足

只有“旗舰/普通/新入驻”分层，不是状态覆盖。

应增加：

依据：分层标签不能替代业务状态，无法验证A端审核和商户运营权限。

3.2 商品状态不足

只有上架70、下架10，应补：

依据：“已下架商品的历史订单”只验证一个特殊关系，无法覆盖商品生命周期和可见性规则。

3.3 支付、退款、核销、账单状态不是互相独立的枚举

例如：

依据：材料按单表状态分布设计，未设计跨域状态不一致数据；但这类不一致正是多域系统最需要验证的场景。

二、用真实价位蓝本做测试数据的风险

1. “真实价格区间”不足以构成测试蓝本

真实价格只能提供一个参考维度，还缺少：

依据：材料价位表只有“住宿、餐饮、包车、向导、门票”的区间，没有价格口径和生效规则，直接使用会导致订单金额和账单金额无法稳定验证。

2. 真实商户和真实价格存在合规及品牌风险

可能造成：

依据：材料要求通过 web 检索真实商户和价格，但没有提供授权、脱敏、来源记录、使用期限和下线机制。

建议采用：

3. 真实价格会造成测试不稳定

价格会受到旺季、天气、路线管制、临时活动、平台佣金和商户调整影响。

依据：采集方案没有版本号、快照日期和过期策略；一旦每次种子使用最新网络价格，回归测试中的金额会变化，导致断言、快照、账单对账结果不稳定。

应把价格拆成：

测试数据不能只追求“像真实”，还要有可预测性。

4. 真实价位可能掩盖边界问题

单纯按真实区间造数据，可能遗漏：

依据：材料只要求低中高三档，没有金额精度、上下限和异常值设计。

三、幂等种子脚本的隐患

1. “先 DELETE is_test=true”风险很高

风险一：误删真实数据

如果 is_test 可为空、默认值不一致、某些关联表没有该字段，或者过滤条件写错，可能删除真实数据或留下孤儿数据。

依据：材料未定义所有表是否强制拥有 is_test、是否为非空字段、是否有外键级联策略。

风险二：外键删除失败

先删除父表可能违反外键约束；先删子表又需要维护完整删除拓扑。

依据：材料只要求“先 DELETE”，没有删除顺序、级联规则和跨模块依赖说明。

风险三：部分删除、部分插入

删除成功后插入中途失败，会得到半套数据；第二次运行可能因已插入部分数据、唯一键冲突或缺少依赖而失败。

依据：材料未要求事务边界、失败恢复、断点续跑或版本记录。

风险四：并发执行互相覆盖

两个管理员同时执行：

  1. A删除；
  2. B删除；
  3. A插入部分数据；
  4. B插入另一套数据；
  5. 最终出现混合数据。

依据：材料要求 staging 和生产演示库均可执行，但未设计分布式锁、数据库锁或运行互斥机制。

2. 仅依赖 is_test 不能保证真正幂等

脚本如果每次使用随机 UUID、随机手机号、随机 openid、随机时间，虽然“可重跑”，但结果不一致。

依据：验收要求“两遍结果一致”，但材料没有规定固定种子、确定性ID、稳定时间基准和数据版本。

应使用：

3. 分模块开关会破坏依赖顺序

例如单独执行 --orders 时：

依据：材料要求分模块开关，但没有声明模块依赖图和自动补齐策略。

应明确：

4. 使用物理删除可能破坏审计和账务语义

账务、核销、退款、争议数据通常不应简单物理删除，尤其生产演示库可能已有人工操作数据。

依据：材料要求一键清除全部 is_test 数据，但未区分演示数据、演示期间人工产生的数据和系统审计数据。

更安全的方式是：

四、生产演示库使用 is_test 的边界风险

1. is_test 不是安全边界

如果某个API、SQL、报表、异步任务忘记加 is_test=false，测试数据就可能：

依据：材料只要求“全部 is_test=true”和“严格隔离”，没有定义数据库层默认过滤、服务层强制过滤、报表层隔离和权限边界。

2. 可能触发真实外部副作用

包括：

依据：材料要求三端“全流程点通”，但没有说明支付、消息、财务、分销和外部服务是否使用sandbox、黑洞账号或副作用拦截。

3. 生产演示库可能被真实业务写入

若演示库与生产库共享数据库、消息队列、对象存储、缓存或数仓，真实用户请求可能关联到测试商户和测试商品，或者演示人员的操作污染真实数据。

依据：材料只说“生产演示库可跑”，没有明确生产演示库与正式生产的网络、数据库、消息、存储和权限隔离方式。

4. 测试用户凭证容易泄漏

材料规定：

但没有说明：

依据：前缀和号段只是数据标识，不是认证与权限隔离机制。

5. 清理存在误操作风险

“生产上线前一键清理”本身是高风险操作：

依据：材料未定义环境白名单、二次确认、审批、dry-run输出、删除数量校验、跨系统清理和回滚方案。

五、其他关键盲区

1. 缺少金额与账务不变量

至少应定义并自动校验：

依据：材料只写“金额可对账”“核销净额一致”，没有给出可执行的不变量公式。

2. 缺少时间模型

未定义：

依据：没有时间设计，就无法测试超时关闭、自动确认、账期、跨天、跨月、历史订单和未来预订。

3. 缺少并发与重复请求数据

应覆盖：

依据：材料要求幂等种子脚本，但没有把业务接口幂等和并发场景纳入数据设计；两者不是一回事。

4. 缺少失败数据和脏数据

真实系统不只需要完整数据，还需要可控的不一致数据：

依据：材料几乎只强调关联完整性，没有设计故障注入和数据质量异常集。

5. 图片、内容和安全数据未规划

“含带图评价”“图文内容”还不够，需要明确：

依据：材料只规定图文/纯文，没有媒体资源、审核和安全测试要求。

6. 缺少验收自动化

“三端全流程点通实录”偏人工验收，不能证明数据工程可靠。

应增加：

依据：当前验收主要是页面可点，没有数据级、跨域级和清理级自动验收。

六、建议立即修改的设计

P0：先补跨域数据模型

新增并明确以下数据集：

  1. 支付与退款；
  2. 两段核销及撤销逆账；
  3. 福钥账户、流水、余额和对账；
  4. 账单明细、争议、调整和确认；
  5. 分销归因、佣金、冲正和结算；
  6. 库存及库存流水；
  7. 权限、审核、操作日志；
  8. 消息、任务、回调和重试。

每个实体都要给出：

P0：把“全部is_test”升级为“数据集隔离”

建议增加：

P0：重写清理机制

禁止无条件：

DELETE FROM ... WHERE is_test = true;

应改为：

  1. 先生成dataset；
  2. dry-run列出影响表和行数；
  3. 校验当前环境白名单；
  4. 获取分布式锁；
  5. 按依赖拓扑删除；
  6. 删除后做残留扫描；
  7. 清理缓存、搜索、对象存储和异步消息；
  8. 产出审计报告；
  9. 必要时支持回滚或恢复。

P1：建立固定测试价格基线

真实采集结果只作为参考，测试数据使用固定版本：

P1：补状态迁移矩阵

不要只列状态数量，应列：

最终判断

当前版本最大的问题不是“数量太少”，而是没有把已有多域系统的数据闭环建出来。尤其是：

在补齐这些内容前，不建议把该脚本开放到生产演示库，更不建议将“一键清理”定义为验收通过条件。