前言：那些年我们“造”过的数据
“小王，明天演示环境要上线，数据库里需要100个带订单的真实用户，还有30天连续登录的数据，今晚搞定一下。”
这种需求，干过开发的应该都不陌生。刚入行那会儿，我最怕听到“造点数据”——打开Navicat，对着Excel一行行复制粘贴，姓名全是“测试1、测试2”，手机号全是13888888888变个尾号，地址永远“北京市朝阳区”。结果第二天演示，老板一点开用户详情：“怎么全是张三李四？这看着太假了，客户会觉得我们产品没人用。”
手动造数据，耗时、无聊、还不真实。更别提涉及用户隐私时，直接用生产数据还有合规风险。
今天这篇文章，我想聊聊我们团队这两年摸索出来的“组合拳”：用Faker搞定80%的基础数据，用LLM搞定剩下20%需要业务逻辑的复杂场景。两者结合，基本能覆盖从单元测试到全链路压测的所有数据需求。
第一部分：Faker——那个靠谱的老伙计
先说Faker。这玩意儿在测试圈混了十几年，江湖地位稳如老狗。不管是Python版还是PHP版，核心思想就一个：让你三行代码生成一个看起来像真人的假数据。
1.1 基础操作：三分钟上手
装过Faker的同学都知道，这东西简单到有点无聊：
from faker import Faker
fake = Faker('zh_CN') # 中文环境
print(fake.name()) # 张敏
print(fake.email()) # xlei@example.com
print(fake.address()) # 上海市浦东新区新城街79号
print(fake.phone_number()) # 13812345678
就这么几行，姓名、邮箱、地址、电话全齐活。而且每次运行都不一样，跑个循环，100条用户数据就有了。
但说实话，这种基础用法也就应付一下开发环境的数据填充。真要模拟业务场景，光有随机名字可不够。
1.2 进阶技巧：让Faker更像“真人”
我们团队用Faker踩过不少坑，总结出几个比较实用的技巧：
技巧一：保持字段一致性用户的用户名、邮箱、姓名应该是有关联的。你生成一个“张伟”，结果邮箱是liwei@gmail.com，这就穿帮了。
def create_realistic_user(fake):
first_name = fake.first_name()
last_name = fake.last_name()
return {
"username": f"{first_name.lower()}.{last_name.lower()}",
"email": f"{first_name.lower()}.{last_name.lower()}@example.com",
"full_name": f"{first_name} {last_name}",
"display_name": f"{first_name[0]}.{last_name}"
}
技巧二：处理唯一性约束数据库里的用户名、身份证号必须是唯一的。Faker提供了unique属性，但要注意——如果生成数量太多，会抛出异常。我们一般会自己维护一个set来去重。
class SafeDataGenerator:
def init(self):
self.fake = Faker('zh_CN')
self.used_phones = set()
def get_unique_phone(self):
while True:
phone = self.fake.phone_number()
if phone not in self.used_phones:
self.used_phones.add(phone)
return phone
技巧三：本地化不是摆设之前有个项目做东南亚市场，刚开始全用zh_CN，结果产品经理说“泰国用户地址怎么是北京海淀区”。后来改成fake_th = Faker('th_TH')，地址、姓名瞬间变成萨瓦迪卡风格。
1.3 Faker的局限性：为什么还需要LLM？
Faker虽然好用，但遇到需要“业务逻辑”的场景就有点力不从心了。举个例子：
生成一个“频繁购买母婴用品的用户”，年龄应该在25-40岁之间，性别偏向女性
生成一条“投诉退款”的订单评价，语气要带点愤怒
模拟“双11大促”的流量峰值，用户行为要符合“先加购、后付款、再催单”的规律
这些需要上下文理解和业务规则的数据，Faker搞不定——它不“理解”自己在生成什么，只是从预定义的词库里随机拼凑。
这时候就得请LLM出场了。
第二部分：LLM——那个会“动脑子”的新人
大模型的出现，让“造数据”这件事有了质的飞跃。以前我们要写一堆规则来判断“什么年龄的人该有什么消费习惯”，现在只需要把规则用大白话告诉LLM。
2.1 最简单的玩法：让GPT直接生成JSON
最开始我们尝试的是最粗暴的方式：写好Prompt，让GPT返回结构化数据。
你是一个测试数据生成专家。请生成10条电商用户数据，要求：
- 年龄在18-60岁之间，符合正态分布
- 消费能力与年龄正相关（30-45岁消费最高）
- 包含姓名、年龄、年消费额、常购品类
- 返回JSON格式
结果呢？效果惊艳。生成的用户年龄分布合理，消费数据也基本符合业务常识。但问题也很明显：贵、慢。生成100条数据就要调用100次API，耗时几十秒，根本没法批量用。
2.2 工业级方案：Dify工作流+LLM批量生成
后来我们发现了Dify这个工具，算是找到了比较靠谱的落地方案。
核心思路是：用循环器控制生成次数，用Prompt定义业务规则，用代码节点做后处理。一个典型的工作流长这样：
第一步：配置循环器设置循环次数为1000，定义一个循环变量{ {index}}，用来生成唯一ID。
第二步：设计Prompt这是最关键的环节。Prompt写得越具体，生成的数据越真实。
请生成一条中国电商用户数据，要求：
- 姓名：随机中文姓名
- 年龄：根据会员等级决定（钻石会员30-50岁，普通会员18-30岁）
- 会员等级：从[普通, 白银, 黄金, 钻石]中随机，但钻石比例不超过5%
- 最近30天订单数：与会员等级正相关
- 常用搜索词：与常购品类相关
输出JSON格式，字段名用英文，值用中文。
{
"user_id": "U" + 9位数字,
"name": "",
"age": 0,
"level": "",
"orders_30d": 0,
"favorite_category": "",
"recent_search": ""
}
第三步：代码节点处理LLM返回的是文本，需要转成JSON，同时把循环索引拼接到user_id里确保唯一性。
第四步：批量导出跑一次工作流，1000条数据自动落库，整个过程不到10秒。
2.3 更高级的玩法：让LLM学会用Faker
最近看到一个很有意思的思路：让LLM生成调用Faker的代码，而不是直接生成数据。
为什么要这么做？因为Faker快啊！生成一百万条数据，Faker毫秒级，LLM分钟级还烧钱。让LLM写个Faker脚本，然后用脚本批量跑，速度和真实性就兼得了。
学术界的论文里把这叫做“三层次提示”：
Level 1：直接让LLM生成数据（适合小批量、高复杂度）
Level 2：让LLM生成特定语言的代码（比如Python脚本）
Level 3：让LLM生成调用Faker库的代码（适合大规模生产）
我们试过Level 3，效果确实不错。Prompt大概是：
请写一段Python代码，用Faker库生成1000个电商用户。
要求：
- 使用Faker('zh_CN')
- 年龄符合正态分布，均值35，标准差10
- 钻石会员占比5%，年消费5万以上
- 代码要包含唯一性处理和异常处理
- 输出为CSV文件
LLM生成的代码稍作修改就能直接用，比自己写快多了。
第三部分：合体技——Faker+LLM的场景实战
讲完各自的本事，说说怎么组合。根据我们团队的经验，Faker负责“量”，LLM负责“质”，分工明确。
场景一：登录模块的异常测试
测登录功能，需要各种奇葩的账号密码组合。Faker可以生成各种格式的邮箱和手机号，但“看起来像邮箱实际不符合RFC标准”这种边界case，Faker搞不定。
我们的做法：
Faker生成正常的邮箱（如test@example.com）
LLM生成异常的邮箱（如test@.com、test@@example.com、test@example）
两者合并，覆盖正常和异常场景
场景二：全链路压测的数据准备
压测需要百万级用户数据，同时要求每个用户的订单、地址、支付方式都有逻辑关联。这种量级，LLM直接生成不现实。
我们的方案：
用Faker批量生成100万用户基础信息（姓名、手机、地址），跑个脚本几分钟搞定
写几条规则：用户ID取模分桶，每个桶对应不同的消费习惯
用LLM生成规则模板，比如“ID尾号0-2的用户属于高价值人群，订单均价500元以上”
压测脚本读取规则，实时生成带业务语义的请求数据
这样既保证了数据的真实感，又满足了性能要求。
场景三：AI训练数据的“数据增强”
最近在做一个推荐系统的项目，需要用户行为序列数据。真实用户的行为往往稀疏，需要补充一些“合成用户”来增强训练集。
我们用LLM生成用户画像（“一个25岁的程序员，喜欢买机械键盘和咖啡”），然后用Faker根据画像生成具体的行为日志——浏览商品、加购、下单、评价。LLM提供“人设”，Faker填充“日常”。
第四部分：避坑指南
摸爬滚打两年，该踩的坑基本都踩过，分享几个印象深刻的：
坑一：LLM生成的重复数据有次让LLM生成1000条商品名，结果发现“华为P40”出现了50多次。解决方案是在Prompt里强调“品类多样、品牌多样”，或者在代码节点做去重。
坑二：Faker的随机性太“随机”Faker生成地址是真的随机，会出现“上海市黄浦区某某村某某组”——这在城市用户里根本不常见。解决方法是自定义Provider，限定地址范围为城区。
坑三：业务逻辑的一致性比如生成“订单表”和“订单明细表”，需要保证总金额=明细金额之和。Faker自己做不到，LLM单条生成也容易出错。我们的做法是用LLM先生成“订单头”，再用规则生成“明细”并做校验，不符合就重试。
坑四：成本控制LLM不是免费的。之前试过用GPT-4生成100万条数据，账单下来直接傻眼。后来改用本地部署的Qwen，加上上面说的“LLM写脚本、Faker执行”的方案，成本降了90%。
写在最后：怎么选？
如果你的需求是：
单元测试、基础数据填充 → Faker就够了，别折腾
演示环境需要“看起来像真人” → Faker + 少量LLM优化关键字段
压测需要百万级真实逻辑数据 → Faker批量 + LLM生成规则模板
AI模型训练需要复杂场景 → LLM主导 + Faker辅助
最后说句实在话：工具永远是工具，核心是你要清楚自己的数据“长什么样”。花一天时间分析生产数据的分布规律，比花一周研究Prompt技巧更有用。
毕竟，再聪明的AI，也猜不出你们公司业务那套“只有老板懂的”定价规则。
