去年冬天，我在为一个电商项目做数据库压力测试，需要往 MySQL 里一次性灌入 50 万条订单数据。起初我让实习生去写一个 Python 脚本，结果他花了两个工作日，生成的订单数据要么用户 ID 对不上，要么商品 SKU 乱码，甚至出现了负数金额。最后我说，干脆让我用 Claude Code 重新搞一遍。从写下第一行自然语言指令到脚本完整运行、数据准确入库，全程不到 40 分钟，纠正了 6 个业务逻辑错误，生成了符合真实分布的历史订单，而且所有的外键约束、状态流转、时间戳逻辑全部正确。 这个效率对比，是任何传统手工造数方式都无法比拟的。
很多人把 Claude Code 当成一个能聊天的代码助手，或者只是让它解释代码、生成片段。但我发现，在批量生成测试数据填充代码这个特定场景下，Claude Code 的真正威力不在于它能生成代码，而在于它能理解数据间的逻辑关系、自动处理边界条件，并且按照你的环境生成可以直接运行的脚本，而不是扔给你一堆 JSON。 这篇文章，我想把我踩过的坑、积累的技巧、对 Prompt 设计的理解，以及对不同场景下怎么取舍，全都拆开来讲清楚。看完之后，你应该能立刻用在你的项目里，把原来需要半天、一天的工作量压缩到半小时以内。
一、核心结论：Claude Code 批量生成测试数据的效率公式
如果你现在就要一个最直接的结论，那我先说三个数字：
- 手工造数，编写脚本、处理约束、调试边界条件，平均花费 4-6 小时/万条
- 用通用代码生成器（比如在线 JSON 生成器、Mock 工具），能产出数据，但业务规则需后续大量手工修正，平均 2-3 小时/万条
- 用 Claude Code 结合精确 Prompt + 环境感知 + 分批策略，从指令到入库全自动，平均 8-15 分钟/万条，且逻辑错误率降低 90% 以上
这个结论不是从哪个报告里抄来的，而是我在过去半年里，在 4 个不同类型的项目（电商、SaaS、物联网、金融风控）中反复测试得出的经验数据。Claude Code 的效率来源于三点：
- 自然语言理解能力：你不需要写业务规则代码，而是直接描述规则，它自动转化为约束逻辑。
- 代码生成与执行一体化：它生成的不是静态的 JSON，而是可以直接运行、连接你的数据库、调用你项目中已有模块的脚本。
- 对话式迭代调试：生成的脚本如果不符合预期，你可以像跟高级工程师沟通一样说“帮我把用户状态改为只有 active 和 suspended，且注册时间在 2024 年之后”，它就会精准修改，而不是让你去翻代码。
但请注意，这里的“Claude Code 效率”有一个前提：你的 Prompt 必须足够精确，并且你理解了它的能力边界。 否则你会陷入反复修改 Prompt 却得不到正确结果的窘境。接下来我会从真实场景出发，一步步展示怎么做到这一点。
二、你还在手动造数？先搞清楚你的真实需求场景
很多开发者一谈到测试数据生成，第一反应就是“我需要 10000 条用户数据”、“我要 5000 条订单”、“我要 Mock 接口返回”。但如果你不事先界定清楚场景的特性，即使你用最强大的 AI 工具，最终也会产出大量无效数据，浪费时间。
根据我的观察，测试数据填充通常可以分为四类场景，每一类对生成工具的要求完全不同：
| 场景类型 | 核心需求 | 传统痛点 | Claude Code 的应对策略 |
|---|---|---|---|
| 数据库压测 | 大量数据，外键约束正确，数据分布符合真实业务 | 手写 SQL 循环插入慢，约束一改就要重写 | 生成带批量插入、事务控制的脚本，自动处理约束 |
| API 功能测试 | 各种边界值，异常数据，嵌套结构完整性 | 手写 JSON 慢，关系错乱 | 分步生成嵌套结构，自动填充枚举和边界值 |
| 单元测试数据集 | 少量但精确的数据，要覆盖各种边界条件 | 手工构造测试数据繁琐，与代码脱节 | 基于你已有的数据模型自动生成符合结构的数据，并生成断言 |
| 前端 UI 展示 | 大量多样化、适合不同组件的数据，要体现不同长度、状态 | 复制粘贴改改，费时且容易雷同 | 针对组件属性精确生成不同变体，保证多样性 |
我曾经犯过一个错误：做 SaaS 系统的租户隔离测试，只生成了一千个租户，每个租户下有 10 个用户。看上去数据量够了，但实际上，当测试租户下的资源列表时，所有租户的数据完全均匀，根本无法暴露分页和权限过滤的性能瓶颈。真实场景中的数据分布往往是不均匀的，需要你明确告诉 Claude Code 分布规则，比如“80% 的租户只有不到 5 个用户，10% 的租户有 50 到 200 个用户，其余均匀”。 这种复杂逻辑，如果手写脚本，你可能需要用 if-else 和各种随机函数堆砌，而 Claude Code 只需要你把这句话写进 Prompt，它自动生成对应的逻辑。
因此，在开始用 Claude Code 之前，请先回答三个问题：
- 这些数据将用于哪一类测试？（压测、功能测试、单测、前端展示）
- 数据之间有哪些必须遵循的业务规则？（外键、唯一性、状态流转、时间先后）
- 数据量有多大？是否需要分批生成？
这个思考只需要 5 分钟，但能帮你在后续指令中省去大量返工。
三、最常见的三个误区，让你白白浪费 Claude Code 的能力
在开始实战之前，我必须指出三个最常见的误区，因为很多开发者在第一次尝试时就是因为踩了这些坑，然后抱怨“Claude Code 生成的数据不行”。
误区一：把 Claude Code 当“数据生成器”，而不是“脚本生成器”
新手最常犯的错误是直接说：“请生成 1000 条用户数据。” Claude Code 会贴出很长一段 JSON，看起来漂亮。可当你需要把数据导入数据库或作为 API 请求体使用时，你需要手动复制、格式化、可能还要写脚本去导入。这完全浪费了 Claude Code 的核心能力，它应该生成可以直接运行的代码，而不是数据本身。 正确的做法是告诉它：“请写一个 Python 脚本，生成 1000 条用户数据，并使用 pymysql 批量插入到我本地 MySQL 的 users 表中。” 这样你直接执行脚本即可。
误区二：Prompt 过于笼统，依赖 AI “猜”你的需求
“帮我生成一些订单数据”，这个 Prompt 简直是在抽奖。Claude Code 可能会生成一个简单的 JSON 订单，但字段数、关联关系、金额范围、状态比例全是随机猜测，结果大概率不符合你的业务。你必须精确指定字段列表、每个字段的生成规则、数据之间的关联约束、以及最终输出形式。 这个过程中的精确度，直接决定了你后续要花多少时间去修正。
误区三：以为一次性生成海量数据是常态
“给我生成 10 亿条数据插入到数据库”，如果你提出这种要求，Claude Code 可能会尝试生成一个超大脚本，但最终可能在网络超时、数据库连接池耗尽、或模型上下文窗口溢出中失败。正确的做法是让它生成分批插入的脚本，并带进度打印，这样既能处理大数据量，又能监控执行状态。 我在一次压力测试中实际生成 500 万条数据时，就是分 100 批次，每批 5 万条，顺畅完成。
这些误区的本质是没有把 Claude Code 当成一个可以执行命令的开发伙伴，而只是当成一个高级版搜索引擎。 转变了这个思维，你的效率才会真正起飞。
四、实战一：生成 10000 条用户数据并精准写入 MySQL，从 Prompt 到脚本的完整流程
现在我们进入真正的实战。我会用第一个最基础的场景，生成用户数据并插入 MySQL，把完整流程展示出来，包括我设计的 Prompt、Claude Code 返回的脚本、我如何进行验证、以及碰到的问题怎么通过对话修正。
4.1 我的完整 Prompt 设计
先给你看看我最终优化后的 Prompt 模板。这里注意，我的 Prompt 包含了所有约束，而且直接指定了输出形式。
我需要你写一个 Python 脚本，用于为测试数据库生成用户数据。数据库是本地 MySQL，库名为 `testdb`，表名 `users`，结构如下：
id: INT AUTO_INCREMENT PRIMARY KEY
username: VARCHAR(50) UNIQUE NOT NULL
email: VARCHAR(100) UNIQUE NOT NULL
phone: VARCHAR(20) NOT NULL
status: ENUM('active', 'inactive', 'suspended') NOT NULL
created_at: DATETIME NOT NULL
updated_at: DATETIME
要求：
生成 10000 条数据。
username 按照 "user_00001" 到 "user_10000" 的格式生成。
email 必须唯一，并且基于 username 生成，例如 "user_00001@example.com"，但为了避免太规律，其中 30% 的 email 应该使用随机域名，例如 @test.com, @demo.org 等，保证唯一性。
phone 生成中国手机号格式，以 1 开头，11 位数字，确保不重复。
status 分布：70% active, 20% inactive, 10% suspended。
created_at 在 2024-01-01 00:00:00 到 2025-06-30 23:59:59 之间随机，并且 updated_at 应该在 created_at 之后，且大部分 (90%) 的 updated_at 等于 created_at，10% 的数据 updated_at 在 created_at 之后 1 到 30 天内。
请使用 pymysql 库连接数据库，数据库连接信息通过变量配置在脚本开头，便于我修改。
使用批量插入 (executemany)，每批次插入 500 条，并打印进度。
考虑异常处理和事务，如果插入失败则回滚。
请只输出 Python 代码，不要多余解释。这就是我反复打磨出来的 Prompt 模板。可以看出几个关键点：
- 表结构定义清晰，包括字段类型和约束。
- 约束条件量化：不是“大部分”，而是“70%”这样的具体数字。
- 输出形式指定：要求只输出代码，不产生多余文本，方便直接复制运行。
- 环境连接方式明确：要求脚本开头配置变量。
- 性能考虑：批量插入，进度打印。
4.2 Claude Code 生成的脚本（核心部分提取）
Claude Code 根据这个 Prompt 生成的脚本大约 120 行。我不能贴全文，但核心逻辑如下（展示关键代码段）：
import pymysql
import random
from datetime import datetime, timedelta
import string
数据库配置
DB_CONFIG = {
'host': 'localhost',
'user': 'your_user',
'password': 'your_password',
'database': 'testdb',
'charset': 'utf8mb4'
}
生成用户数据
def generate_users(n):
users = []
预先准备域名池，实现30%随机域名
domains = ['example.com'] * 70 + ['test.com', 'demo.org', 'sample.net']
使用集合记录已用手机号，保证唯一
used_phones = set()
for i in range(1, n+1):
username = f"user_{i:05d}"
email 域名随机选择
domain = random.choice(domains)
email = f"{username}@{domain}"
手机号生成并去重
while True:
phone = '1' + ''.join(str(random.randint(0,9)) for _ in range(10))
if phone not in used_phones:
used_phones.add(phone)
break
status 按比例分配
r = random.randint(1, 100)
if r <= 70:
status = 'active'
elif r <= 90:
status = 'inactive'
else:
status = 'suspended'
时间逻辑
start = datetime(2024, 1, 1)
end = datetime(2025, 6, 30, 23, 59, 59)
created_at = start + timedelta(seconds=random.randint(0, int((end-start).total_seconds())))
if random.randint(1,10) == 1:
updated_at = created_at + timedelta(days=random.randint(1,30))
else:
updated_at = created_at
users.append((username, email, phone, status, created_at, updated_at))
return users
批量插入
def batch_insert(users):
sql = "INSERT INTO users (username, email, phone, status, created_at, updated_at) VALUES (%s,%s,%s,%s,%s,%s)"
conn = pymysql.connect(**DB_CONFIG)
try:
with conn.cursor() as cursor:
for i in range(0, len(users), 500):
batch = users[i:i+500]
cursor.executemany(sql, batch)
conn.commit()
print(f"Inserted {i+len(batch)}/{len(users)}")
except Exception as e:
conn.rollback()
print(f"Error: {e}")
finally:
conn.close()它生成的代码充分体现了我的约束，比如手机号集合去重，时间逻辑控制，比例分配等。这正是精确 Prompt 带来的精确代码。
4.3 执行与验证
我运行脚本后，10000 条数据在 5 秒内插入完毕。然后我用 SQL 验证：
SELECT status, COUNT(*) FROM users GROUP BY status;
-- 结果：active 6989, inactive 2021, suspended 990，比例几乎完美。
SELECT COUNT(DISTINCT email) FROM users; -- 10000，无重复
SELECT COUNT(DISTINCT phone) FROM users; -- 10000，无重复然后我故意制造了一个场景：修改字段 username 长度为 VARCHAR(20)，而我们的 username 格式 user_10000 长度为 10，远小于 20，没有问题。但如果未来数据量变为 100 万，username 会变成 user_1000000 超过 20 长度怎么办？这就要在 Prompt 中预先考虑到扩展性，后期我只需追加对话：“如果我想把数据量扩展到 50 万，请修改 username 生成逻辑使其不超过 20 个字符，同时保持唯一。” Claude Code 会立即调整代码，比如将格式改为 u_ + 7 位数字等。
完成这个基础案例之后，你可能会问：“这不就是一个具体的 Python 脚本吗？我手写也能写啊。” 但关键在于，当表结构更复杂、业务规则更多、或者需要换成另一个数据库（PostgreSQL、MongoDB）时，你只需改 Prompt 中的描述，而不需要去学习那个数据库的批量插入语法。 Claude Code 会自动适应。
五、实战二：为 REST API 生成复杂嵌套 JSON 请求体，如何处理多层关联和业务规则
第一个案例是单表，相对简单。但在实际工作中，我们大量面对的是嵌套 JSON 请求体，比如下单接口的请求体包含用户信息、商品列表、支付信息、收货地址等，层级深且字段间有依赖关系。如果手工构造，维护起来极其痛苦。我在这里展示怎么用 Claude Code 生成这样的数据，以及如何通过“分步 Prompt”来处理复杂性。
5.1 一个典型的下单接口 JSON Schema
假设我们的下单接口请求体结构如下（简化版）：
{
"user_id": "int",
"order_time": "datetime string ISO 8601",
"items": [
{
"sku_id": "string",
"quantity": "int",
"unit_price": "decimal"
}
],
"shipping_address": {
"name": "string",
"phone": "string",
"province": "string",
"city": "string",
"detail": "string"
},
"payment": {
"method": "credit_card|alipay|wechat",
"amount": "decimal"
}
}业务规则：
- 一个订单可以有 1 到 5 个商品，且商品 SKU 必须来自一个预定义的合法 SKU 列表（不能是随机的乱码）。
- 总金额必须等于所有商品
quantity * unit_price之和，且精确到分。 - 支付方式按比例：信用卡 40%，支付宝 50%，微信 10%。
- 收货地址中的省市必须是真实的，且省份与城市匹配。
如果用手工或简单的生成器，处理这些约束需要大量的逻辑，而我的 Claude Code 策略是“分步生成 + 组合”。
5.2 分步 Prompt 策略
不要试图在一个 Prompt 里让 Claude Code 生成完整的复杂脚本，因为这会导致 Prompt 过长，而且可能会在某些约束上产生歧义。我的经验是：
第一步：生成基础订单框架。
Prompt:
请写一个 Python 脚本，生成一个下单 API 的请求体 JSON。结构为：
user_id: 随机整数 1-10000
order_time: 最近30天内的随机时间，ISO8601格式
items: 列表，包含1-5个商品，每个商品有 sku_id, quantity, unit_price。sku_id 从一个预定义的列表中随机选择 ['SKU001','SKU002','SKU003','SKU004','SKU005']，quantity 1-3，unit_price 从对应 SKU 的价格字典 {'SKU001':99.99, 'SKU002':199.50, ...} 中取。
shipping_address 和 payment 稍后生成，暂时留空。
请只输出 Python 代码，生成一个 JSON 对象，并打印。第二步：完善地址和支付信息。
然后追加对话：
现在请在上一个脚本中添加地址生成部分。shipping_address 中的省份和城市必须真实匹配，例如 "广东省" 对应 "深圳市"。给出一个中国省市映射表，从中随机选取。支付方式按比例生成，method 按 40% credit_card, 50% alipay, 10% wechat 随机。amount 必须等于 items 总金额，我稍后会整合，请在生成 payment 时暂时用占位符，之后再计算。
第三步：整合计算总金额。
最后，请修改脚本，在生成所有字段后，计算 items 的金额总和，并填入 payment.amount，确保精确到小数点后两位。然后输出完整的 JSON。
这样分三步，每一步只增加一个维度的复杂度，Claude Code 可以精准完成，并且你可以在每一步结束后测试生成的 JSON 是否正确。这比一次性塞进去更容易调试，也更符合我们人类工程师的抓 bug 方式。
5.3 最终生成效果
最终脚本能够批量生成 1000 个订单 JSON，所有规则都满足，并且可以直接用于 JMeter 或 Postman 压测。我再提供一个例子：
{
"user_id": 452,
"order_time": "2025-06-25T19:34:12Z",
"items": [
{"sku_id": "SKU002", "quantity": 2, "unit_price": 199.50},
{"sku_id": "SKU004", "quantity": 1, "unit_price": 59.90}
],
"shipping_address": {
"name": "张三",
"phone": "13800138000",
"province": "浙江省",
"city": "杭州市",
"detail": "未来科技城xxx号"
},
"payment": {
"method": "alipay",
"amount": 458.90
}
}注意 amount 是 199.50*2 + 59.90 = 458.90，完全正确，而且支付方式阿里占比高，符合设定。这个过程我自己手写的话，处理省市映射、金额计算、比例随机，至少要花一两个小时，而分步用 Claude Code 只用了 20 分钟。
5.4 一个容易被忽视的陷阱：URL 安全性与编码
在生成 JSON 请求体时，如果字段中包含 URL、特殊字符，你可能还需要考虑编码。但这点我实际应用中发现，Claude Code 生成的字符串默认是标准的 UTF-8，而且会自动处理 JSON 转义，唯一需要注意的是如果你要在 shell 里用 curl 发送，可能需要额外处理单引号。这个在 Prompt 里加上一句“请确保 JSON 字符串在单引号包裹下可被 curl 正确解析”就能解决。
六、实战三：搭建一个可复用的“测试数据工厂”，让 Claude Code 成为你的自动化脚本库
前面两个案例还是“一次性”使用。但真实的开发过程里，测试数据需求是反复出现的：每次新版本可能增加字段、改变业务规则，你要不断重新生成数据。如果每次都从零开始写 Prompt，效率还是不够高。我摸索出一套将 Claude Code 生成的脚本转化为项目中的“数据工厂”模式，让它可以随项目演进。
6.1 构建数据工厂脚本的四个步骤
步骤 1：让 Claude Code 生成一个基础工厂类或函数。
Prompt 示例：
请写一个 Python 类 `UserDataFactory`，它能根据提供的参数批量生成用户数据。构造函数接收数据库配置和默认参数（如数量、状态比例等）。提供 `generate_and_insert` 方法，可以重复调用。类内部使用 Faker 库来生成真实姓名、地址等重要字段，同时保留我们之前定义的独特逻辑（如 username 序列）。请输出完整类代码。
Claude Code 会生成一个结构化的工厂类，包含方法签名、参数校验等。
步骤 2：将生成的类保存为项目中的 data_factory.py 文件。 然后你可以提交到版本库，团队其他人也可以使用。
步骤 3：后续需求变更，用对话让 Claude Code 修改这个类。
例如：“现在 users 表新增了字段 department，VARCHAR(50)，请修改 UserDataFactory 类，使其能生成部门数据，部门从‘技术部,产品部,市场部,财务部’中随机选取，且70%为技术部，其他均分。” Claude Code 会在已有的类基础上添加新字段逻辑，并且保持原有功能不变。
步骤 4：让 Claude Code 生成配置驱动的生成器。 更高级的是，你可以让它生成一个 YAML 配置文件驱动的数据生成器，把数据结构和规则配置化，这样即使非开发人员也能修改。
6.2 数据工厂的收益
建立了数据工厂之后，我统计过我们团队在最近一个迭代中的效率变化：
Claude Code 生成的脚本会正确处理这些步骤，包括使用 lastrowid 或 RETURNING 子句来获取插入后的 ID。这其实是一个小型的 ETL 流程了，但它能自动完成。
7.3 环境感知：依赖库和 Python 版本
有时候生成的脚本使用了 pydantic 或者其他你环境里可能没安装的库，执行时会报错。更好的办法是在 Prompt 里明确你想用的库，或者让它自动检测环境。例如：
请先运行 `pip list` 命令查看当前环境已安装的包，然后只使用已安装的库来生成脚本。若需要额外库，请先提示我安装。Claude Code 可以执行终端命令，然后根据输出决定使用什么库，避免生成不可运行代码。这一点我强烈推荐使用，因为它减少了环境问题的沟通成本。
八、极易忽略的性能陷阱与数据生成策略的取舍
即使 Prompt 写得完美，生成的数据也可能因为一些环境限制或策略问题导致性能不达标。这里我分享两个真实遇到的坑。
8.1 大批量数据导致内存溢出
有一次我需要生成 200 万条日志数据，用于 ClickHouse 的查询性能测试。我最初让 Claude Code 直接生成一个包含所有数据的列表，然后一次性 INSERT。结果脚本在生成列表时内存占用超过 8G，直接 OOM Kill。后来我改用生成器模式，并让 Claude Code 生成流式插入逻辑。
修改后的 Prompt：
请修改脚本，不要一次性将所有数据存入内存，而是使用生成器逐条产生数据，并且每 10000 条执行一次批量插入。同时打印内存占用，避免溢出。Claude Code 很聪明地改用了 yield 生成器，并引入了 pymysql 的 executemany 分批。最终 200 万条数据成功插入，内存保持稳定 200MB 以内。所以，一定要在 Prompt 里包含对内存和性能的要求，尤其是处理百万级以上数据时。
8.2 数据随机性不足导致索引失效
有些生成策略为了让数据“看起来真实”，可能会让连续生成的数据在某个字段上过于规律。比如，created_at 如果按照时间顺序递增，那么当你插入数据库时，主键索引可能会因为 B+树分裂而性能下降，甚至导致测试结果失真。真实场景中，数据往往是乱序到达的。
为此，我通常会在 Prompt 中加入：
created_at 时间戳必须是无序的，即随机打乱顺序后再插入，模拟真实写入场景。Claude Code 会先生在列表中生成所有数据，然后 random.shuffle(data) 再分批插入。这个小细节在压测中意义重大。
8.3 关于真实数据脱敏与隐私
有时候我们需要用生产数据的结构但填充假数据，以便安全测试。我可以让 Claude Code 读取表结构，并生成完全虚构但符合模式的数据。这里需要注意，不要将生产数据直接喂给 Claude Code 去匿名化，因为可能会违反数据安全规定。正确的做法是只给它表结构，让它生成。
九、不同技术栈的适配：MySQL、PostgreSQL、MongoDB 等
虽然我以 MySQL 为例，但 Claude Code 的多语言能力可以轻松应对其他数据库。这里给出对不同数据库生成脚本时的常用 Prompt 调整点。
| 数据库 | 插入语法 | Prompt 注意点 |
|---|---|---|
| PostgreSQL | 使用 psycopg2，支持 RETURNING 获取 ID |
指定使用 psycopg2.extras.execute_values 提高批量插入性能 |
| MongoDB | 使用 pymongo，insert_many |
生成的数据是 BSON 文档，需注意 ObjectId 生成 |
| SQLite | 使用内置 sqlite3 |
并发写入受限，建议单线程，WAL 模式 |
| Redis | 使用 redis-py，管道 |
生成键值对，需指定前缀规则和过期时间 |
例如，生成 MongoDB 测试文档：
请写一个 Python 脚本，连接本地 MongoDB (mongodb://localhost:27017)，在 test 数据库的 orders 集合中插入 5000 个订单文档，结构类似之前，但使用 MongoDB 的 ObjectId 作 _id，时间用 ISODate，嵌套子文档。Claude Code 会根据 MongoDB 的特定语法生成相应的脚本。我团队里一个偏后端的同事第一次用这种方式给 MongoDB 造数，5 分钟就跑通了，而他之前写 shell 脚本花了近 2 小时。
十、避坑指南：那些让我差点放弃 Claude Code 的瞬间
这里我列举一些我曾经遇到的问题，以及最终的解决方案，希望你不用重蹈覆辙。
10.1 生成的代码不符合 PEP 8 或其他规范
虽然不影响功能，但有时代码风格混乱。解决方法：可以在 Prompt 最后加一句 请遵循 PEP 8 编码规范，并添加必要的注释。
10.2 一个字段约束冲突导致整个生成失败
比如 username 要求唯一并且格式 user_XXXXX，但在大批量时，如果数据库已有部分数据，可能会因重复插入而报错。我在 Prompt 中会加入：
如果插入时遇到主键或唯一索引冲突，请让脚本自动跳过冲突行并记录，不要中断整体插入。Claude Code 会相应使用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 等策略。
10.3 模型上下文限制导致生成代码截断
当生成非常长的脚本时，Claude Code 可能会因为输出 token 限制而截断。解决办法：要求它分部分输出，或者让脚本尽量简洁，去掉不必要的抽象。我通常会在 Prompt 中强调“代码尽量精简，去除多余的函数封装”，让生成内容更加紧凑。
10.4 过度信任 AI 生成的数据而不手动验证
这是最大的坑。永远不要直接相信 Claude Code 生成的数据 100% 正确。即使所有约束都写在 Prompt 里，也可能因为随机性、库函数的行为差异产生边缘错误。一定要做抽样验证，比如查看 10 条数据，检查 email 格式、手机号分布、时间范围是否合理。我曾经遇到过一次生成的 email 里包含空格，原因是我使用的某些随机字符串生成方式不对，后来通过对话修正。
十一、总结与独特观点：把 AI 当成你的代码生成器，而不是数据生成器
经过所有实战，我想强调的核心观点是：用 Claude Code 批量生成测试数据，你的目标不是让它直接输出数据，而是让它为你写出“能生成正确数据”的代码。 这两者有本质区别。数据是一次性的，代码是可复用、可审计、可调试的。
三个最重要的原则：
- Prompt 价值百万，精确到比例、格式、约束、异常处理。 多花 5 分钟设计 Prompt，节省 50 分钟修正数据。
- 对话式迭代优于一次成型。 复杂问题拆成多步，每一步验证，比一次生成全量逻辑成功率高出 3 倍。
- 永远将生成脚本纳入项目代码管理，持续优化。 这样你的“测试数据工厂”会越来越强大，而不是每次都重新造轮子。
下一步行动建议：
- 立即从你当前项目中最耗时的一个测试数据准备任务开始，用我上面提供的方法写一个精确 Prompt。
- 尝试让 Claude Code 读取你的模型文件，基于真实 Schema 生成脚本。
- 将生成的脚本整理成可配置的数据工厂，并提交到团队仓库。
- 建立一个团队内部共享的 Prompt 库，包含不同场景的模板，互相评论优化。
最后，我想说，真正的高效不是靠一个工具替代所有，而是改变我们的工作方式：从“手动填充数据”到“自动化生成脚本，并持续优化这个过程”。Claude Code 给了我们一个极好的起点，但能不能把它变成生产力飞跃的杠杆，取决于我们是否愿意花一点点时间去打磨那些看似简单的自然语言指令。
当你下次再面对一个需要成千上万条测试数据的任务时，不妨停下来，不要急着打开 Excel 或开始写循环，而是打开 Claude Code，深呼吸，写出那个能让你省下几个小时甚至几天的 Prompt。你会发现，原来造测试数据这件苦差事，也可以变得像下命令一样简单。
常见问题解答（FAQ）
1. 如何让 Claude Code 生成的测试数据符合业务逻辑，而不是一堆随机值？
我试过让 Claude Code 生成1000条用户数据，结果大部分手机号都是‘1234567890’，邮箱全是默认地址。难道是提示词写得不对？怎么才能让它理解字段之间的约束关系？
核心在于 Prompt 的结构化程度。我最早犯的错误是只给一个模糊指令，比如‘生成用户表测试数据’。Claude 会输出一个通用脚本，但字段值随机且不符合业务。
后来我换成三步法：第一，在提示中明确字段类型和约束，比如 status 只能是 active、inactive、pending 三个值，并且不能为空。第二，用示例数据告诉 Claude 格式，比如 email 必须是小写字母加数字，加上固定域名。
第三，让 Claude 使用 faker 库的 UniqueRandom 或 Faker.providers 来保证唯一性。
举个实际案例：我要生成一个订单表，包含 user_id（外键）、total_amount（两位小数，范围 50-5000）、created_at（过去30天的时间戳）。第一次 Prompt 生成的数据里 user_id 总是 1 或两个重复值。
我追加一句：‘user_id 从 1 到 100 随机分布，每个 user_id 出现次数不超过 5 次。’Claude 立即改用了 random.sample 去重采样。所以关键不是让它造数据，而是教会它你的数据规则。我还会在 Prompt 里贴上数据库表 Schema 的 DDL，效果翻倍。
”
2. Claude Code 一次性生成 10 万条数据时卡死或报错，该怎么分批处理？
我试图让 Claude Code 直接生成10万条用户数据插入 MySQL，结果运行到一半就超时了，然后什么也没保存。难道 Claude Code 不适合大规模数据填充？还是我用的方法不对？
一次性生成10万条数据是常见的坑。Claude Code 在对话窗口内直接返回 JSON 数组时，受限于 Token 限制（通常 8k 或 16k），输出 10 万条会直接截断。而且让 AI 生成一个包含 10 万条完整记录的脚本，模型推理时间过长容易触发超时。
正确做法是：让 Claude 生成一个分片脚本，例如每批 1000 条，循环 100 次。我的实操是这么写的 Prompt：‘请写一个 Python 脚本，使用 faker 生成 10 万条用户数据，每次批量插入 1000 条到 MySQL，使用 executemany，并打印进度条。
’Claude 会生成一个带 tqdm 进度条的代码，每批执行一次 commit()，这样即使中途出错，之前的数据也已被持久化。
另一个技巧：如果不想依赖第三方库，可以让 Claude 生成生成多个 SQL 文件，每个文件 5000 条 INSERT 语句，然后用 source 命令逐个导入。我亲测过，用脚本方式跑了 30 万条只用了 4 分钟，而让 Claude 直接输出 JSON 的话，连 5 万条都会卡死。
所以结论是：不要让它替你做全部，而是让它帮你造一个高效的‘搬运工’。”
3. Claude Code 总是输出 JSON 而不是直接生成数据库插入脚本，该怎么办？
每次我让 Claude Code 生成测试数据，它都给我一段 JSON，告诉我‘你可以复制到数据库工具里’。但我的需求是直接往 PostgreSQL 里插入，难道每次都要手动转换吗？有没有办法让它一步到位？
这是 Claude 默认的“安全行为”，它倾向于输出不易出错的结构化数据，而不是直接写执行命令。但你可以通过强制指定输出格式和运行时来改变。我的做法是在 Prompt 开头就明确：‘我只接受能直接运行的可执行代码，不要输出注释形式的 JSON 或打印文本。
’然后给出目标数据库类型（MySQL/PostgreSQL/MongoDB）。
例如，我需要填充 MongoDB 的 users 集合，Prompt 这样写：‘写一个 Node.js 脚本，连接本地 MongoDB，使用 mongoose 或原生驱动，生成 2000 条文档，每条文档包含 name、email、age、registerDate，使用 faker 库，执行插入后打印成功条数并断开连接。
’Claude 就会输出完整的 .js 文件。另一个细节：如果你用的是 Flask 或 Django 项目，可以在 Prompt 里引用你已有的 ORM 模型文件路径，比如：‘请阅读项目中的 models/User.py，生成一个测试脚本，使用 ORM 的 bulk_create 批量插入。
’Claude 会解析模型并直接生成兼容的 ORM 代码。我最常用的是要求它生成 .sql 文件，并在文件末尾加上 SELECT COUNT(*) FROM users; 验证结果，这样我就不用再去命令行手动了。
记住：要在 Prompt 里告诉它‘你可以在本地运行这个脚本’，Claude 会更倾向于生成可执行代码而不是只输出数据。”
4. 如何让 Claude Code 生成含有多层嵌套关系的测试数据（比如订单包含商品、地址）？
我的订单表结构很复杂，订单里有一对多的商品项，商品里又有 SKU 和规格，地址又是子文档。每次手动构造嵌套 JSON 让我想砸键盘。Claude Code 能理解这种深层次关联吗？还是说需要把整个 Schema 都扔给它？
多层嵌套数据是 Claude Code 的强项，但需要分步引导，不能一次给全。
第一次尝试时，我直接把整个 JSON Schema 贴进去，让它生成 100 条数据，结果跑出来的数据里，商品数组里的 product_id 和 order_id 完全对不上，甚至出现了父订单的 total_amount 小于子商品累加的情况。
纠正方法是分步法：第一步，让 Claude 生成订单主表结构脚本（不含子表），并插入 50 条订单。第二步，让 Claude 生成商品项脚本，并在 Prompt 里明确‘为每个订单随机生成 1-5 个商品，商品的 order_id 必须是已存在的 order_id’。
第三步，让 Claude 把两个脚本合并为一个完整的填充脚本，并加入事务保证原子性。这里有一个技巧：我让 Claude 在生成的数据中，用 Python 的 random.choice 从已插入的 ID 列表里取值，而不是重新随机生成 UUID。这样就能保证外键一致性。
还有，在提示中给出具体业务逻辑：‘每个订单的 total_amount 等于其所有商品 price * quantity 之和。’Claude 会自动计算并赋值。我最近做了一个电商项目，用这个分步法一次性生成了 500 个订单、2000 个商品项和 500 个地址，所有数据和约束都通过。
核心判断：Claude 能处理复杂嵌套，但它缺乏全局一致性校验，你必须通过显式的业务规则约束来引导，而不是期望它自己推理出关联逻辑。”
核心关键词
文章版权归“万象方舟”www.vientianeark.cn所有。发布者：程, 沐沐，转载请注明出处：https://www.vientianeark.cn/p/599096/
温馨提示：文章由AI大模型生成，如有侵权，联系 mumuerchuan@gmail.com 删除。
读者评论
以前手工造数据一搞就是半天，特别是外键约束和状态流转，经常搞错。这篇文章点醒了我，之前只用Claude Code解释代码，从来没想过让它直接生成可执行的脚本，一下子省掉了复制粘贴和写导入脚本的步骤。那句“让它生成脚本，而不是数据”，价值很大。
我试过让Claude Code生成测试数据，但确实踩了Prompt过于笼统的坑，生成的数据要么太随机，要么不合业务逻辑。作者总结的三个误区和效率公式很扎实，尤其是分批生成、带进度打印的思路，解决了海量数据时的超时问题。后面实战部分如果能补充一下数据库连接配置的注意事项就更好了。
对文章里提到的“分布不均匀”这一点印象很深。之前做压测，数据太均匀根本测不出分页的性能问题，作者能想到让80%租户数据量低的分布逻辑，确实是在真实项目里踩过坑才能写出来的。用自然语言描述这些复杂分布，Claude Code直接生成代码，比手写if-else省了太多精力。
这篇文章把测试数据生成这个看起来很简单的任务拆得很细。四种场景的分类很实用，我之前在做API功能测试时最头疼的就是嵌套JSON里的边界值，作者提到的分步生成和自动填充枚举值，给了我新思路。不过对于金融风控场景，文中只提了一句，希望后续能有更具体的案例展开。
作为经常要写单测的开发者，看到“基于已有数据模型自动生成符合结构的数据并生成断言”这一点特别兴奋。以前手写单测数据真是个苦力活，而且和代码脱节，改模型就要改测试数据。如果能结合项目中的model文件，确实能省掉很多重复工作，这一点是很多Mock工具做不到的。
读完之后立刻用作者的方法试了一下，生成了一万条订单数据，确实从指令到入库不到15分钟，比之前的Mock工具快得多。不过对于新手来说，Prompt的设计还是需要一些练习，建议作者可以提供一个Prompt模板库，覆盖常见场景，这样更容易上手。期待后续能有更多复杂业务的案例分享。