第一圈：先写出商城演示要讲的故事
演示数据库不只是装满表格的容器。你点击订单列表时，应该看到新订单、已付款订单和退款订单；打开客户详情时，应该能找到对应的购买记录。真实感来自业务关系，而不是姓名和地址看起来多么逼真。
先用一个小型商城练习。写下三个演示动作：查看客户、筛选订单、展示退款。只为这些动作准备客户、商品和订单三类数据，暂时不添加不会展示的字段。这样更容易发现缺口，也不会把练习变成庞大的造数工程。
第二圈：给每个字段定规则
生成之前，先列出字段说明。客户需要唯一编号、虚构姓名和注册时间；商品需要编号、名称和单价；订单需要所属客户、商品、数量、金额、状态和创建时间。字段名称、格式和必填要求应与数据库保持一致。
- 客户编号不能重复，订单引用的客户和商品必须存在。
- 数量必须是正整数，金额应根据单价、数量和优惠计算，不要随意填写。
- 客户注册时间不能晚于下单时间，退款时间不能早于付款时间。
- 订单状态只能使用系统已经支持的值，避免出现页面无法识别的状态。
这些规则就是验收清单。模型负责提出候选内容，数据库约束和检查程序负责把关，不能因为文字读起来顺畅就直接导入。
第三圈：让普通订单占多数
如果每个客户都买同样多的商品，每种订单状态都出现同样多次，页面虽然整齐，却不像真实业务。可以先设定一批演示用分布：多数客户只有少量订单，少数客户重复购买；普通商品经常出现，冷门商品偶尔出现；退款只占一小部分。
这些比例是为了讲清演示故事，不代表真实市场统计。还要保留几条有明确用途的特殊记录，例如没有订单的新客户、名称较长的商品、包含优惠的订单，以及等待处理的退款。每条特殊记录最好对应一个要验证的页面行为。
第四圈：把造数要求写成明确任务
不要只告诉模型“生成一些真实数据”。可以这样描述：“请为虚构商城生成二十名客户、十种商品和六十笔订单。先输出客户与商品，再输出引用它们的订单。编号必须唯一，金额使用两位小数，日期统一格式。多数订单已完成，保留少量待付款和退款订单。只返回约定字段，不添加解释。”
需要调用模型时，推荐使用本站的模型中转服务，按实际使用量付费，方便围绕同一份要求调整数据；欢迎注册，使用新账户赠送的小额额度先试一批。无论使用哪种模型，都应先生成小样本，确认字段和关联正确后再扩大数量。
第五圈：用程序补齐数量与金额
模型适合编写自然的商品名称、虚构人物设定和业务场景，但不适合独自承担大量记录的一致性计算。更稳妥的做法是让模型提供少量素材，再由生成程序分配编号、选择关联对象、计算金额并排列时间。
如果生成程序使用随机选择，可以固定随机种子，也就是给它一个固定的起点。保存相同配置和生成程序版本，通常就能重新得到同一批数据。再把生成结果保存成文件，演示出问题时便能恢复现场，而不是重新请求模型碰运气。
绿灯前：检查、隔离，再导入
- 检查记录数量、必填字段、编号重复和关联缺失。
- 检查金额计算、时间先后以及状态与字段是否匹配。
- 确认数据完全虚构，不复制真实客户资料，也不使用可能触达真实用户的联系方式。
- 只导入独立演示环境，关闭短信、邮件、支付等真实外部动作。
- 导入后亲自走一遍演示流程，并准备清空和重新导入的步骤。
最后，把演示数据文件、生成规则和检查结果一起保存。下次新增筛选条件或修改订单页面时，先更新对应场景，再重新生成和验证。这样得到的不是一堆临时记录，而是一套可以反复使用的演示材料。