我做测试这行有些年头了。早些年团队里谁要是提"数据准备"，会议室里立刻一片叹气声。Excel 表格复制粘贴，SQL 脚本改一改再跑一遍，身份证号随手编一串，手机号凑够十一位就算完事。跑通了算运气好，跑不通就回头查是字段少了空格还是枚举值拼错了。那会儿我们常说一句话：写用例两小时，造数据一整天。
后来接口多了，微服务拆细了，一条业务链路要穿过七八个系统，手工造数彻底撑不住。我开始认真琢磨测试数据这件事，也慢慢接触到用 AI 生成数据的路子。这篇就把我踩过的坑、试出来的经验捋一捋，从测试数据到底顶什么用，讲到 AI 能干到什么程度、又干不了什么。
1.1 测试数据在功能、接口、性能与安全测试中的关键作用
功能测试里，数据就是用例的另一半。我写过一条"优惠券过期后不可使用"的用例，逻辑本身没问题，可造出来的券到期时间全在明天，跑十遍都是绿的。换成一个刚好差一秒过期的券，缺陷立马冒出来。边界值、状态流转、空值、超长字符串，这些场景没有对的数据就根本触发不了。测试用例写得再漂亮，数据不给力，等于拿空枪打靶。
接口测试对数据的要求更挑剔。字段类型、必填校验、长度限制、枚举取值、嵌套结构，一个不对，接口直接给你 400。我做过一个订单接口的测试，光是收货地址这块就有省市区三级联动、邮编格式、手机号归属地校验，手工拼 JSON 拼到眼花。性能测试又是另一个维度，数据量、数据分布、热点集中度都会影响压测结论。一千条均匀分布的数据和一百万条带倾斜的数据，跑出来的响应时间能差好几倍。
安全测试里的数据更敏感。SQL 注入的 payload、越权访问用的他人 ID、XSS 的脚本片段，这些"坏数据"反而是测试的主角。我还遇到过因为测试库里塞了真实用户手机号，被安全部门叫去谈话的情况。测试数据不只是让流程跑通，它还牵扯到合规和隐私这条红线。
1.2 AI生成测试数据的核心能力、优势与适用边界
我最初对 AI 造数是存疑的。试了几次之后，改观挺大。它最让我省心的地方是"读懂结构"——把建表语句或者 OpenAPI 文档丢进去，它能自己识别字段类型、长度、枚举范围，然后按约束吐出一批格式合法的数据。以前我要对着 DDL 一条条写生成规则，现在描述一句"生成 200 条 2024 年注册、状态为已激活的企业用户"，出来的数据基本能直接用。
优势很明显。覆盖面比我手工想的宽，各种边界组合它能自动铺开；生成速度快，几百上千条几秒钟的事；多样性也好，姓名、地址、备注这些文本字段不会像手工造数那样反复出现"张三""测试地址一"。我拿它做过一批商品描述数据，长短不一、中英文混杂，反倒更接近真实业务的样子。
边界也得说清楚。涉及精确业务计算的场景，AI 容易翻车。比如金额分摊、积分累计、库存扣减这种有严格公式的，它生成的数据看着合理，算起来对不上。强状态机的业务也麻烦，订单从待支付到已发货中间有七八个状态和若干约束，AI 不一定能保证每次流转都合法。还有合规敏感的场景，真实姓名、身份证、银行卡这类数据，我不会让它们进提示词。AI 是加速器，不是万能钥匙，哪些活交给它、哪些活自己盯着，心里得有本账。
1.3 使用AI生成测试数据的关键需求拆解：覆盖度、真实性、效率与合规
我把测试数据的诉求拆成四块来看，落地时对着这四块逐项检查，省了不少返工。
覆盖度讲的是数据能不能把该测的场景都碰到。正常值、边界值、异常值、空值、超长值，还有业务上的各种状态组合。我通常先列一张覆盖清单，让 AI 按清单逐项生成，生成完再核对有没有漏项。这一步偷懒，后面漏测的代价更大。
真实性不是说要跟生产数据一模一样，而是分布和形态要像。年龄不会全是 25 岁，地址不会全在北京，订单金额不会都是整数。我会给 AI 一些分布提示，比如"年龄服从正态分布，均值 32"，出来的数据看起来就自然多了。
效率这块 AI 的优势最直接。原来造一批关联数据要半天，现在提示词调好，几分钟出结果。省下来的时间我拿去做用例设计和结果分析，价值更高。
合规是我最看重的一条。测试数据里不能有真实个人信息，脱敏、合成、虚构这三条路得选一条走稳。我现在的习惯是提示词里明确写"生成虚构数据，不得使用真实姓名和证件号"，生成后再过一遍敏感信息扫描。
1.4 引入AI前后的成本、质量与效率对比
说个具体的事。去年我们做一个会员系统的重构，涉及用户、等级、权益、订单四张主表，还要造关联数据。按老办法，我一个人写生成脚本得两天，跑出来的数据还得手工补关联关系，前后折腾三四天。这次我换了思路，把表结构和业务规则整理成提示词，分批让 AI 生成，第一天下午就把基础数据铺好了，第二天做校验和补充，整体省了一半多时间。
质量上的变化更让我意外。手工造数有个通病——同质化。我造的地址永远是那么几个，备注永远是"测试数据"，结果一些跟地址长度、特殊字符相关的缺陷一直没暴露。AI 生成的数据杂得多，反倒把这些角落给照出来了。当然也出过岔子，有一次生成的一批数据里有个字段全是空字符串，原因是提示词没写清楚该字段必填，后面加了一条校验规则才解决。
成本这块不能只看省了多少人力。提示词调试、生成结果校验、敏感信息扫描，这些环节都要投入。我粗略算过，一个中等规模的项目，前期投入大概两三天，之后每轮迭代的边际成本很低。跑量大的团队收益更明显，小项目用不用 AI 差别没那么大，这个账得按实际情况算。
上一章聊了成本和质量的账，这一章我把整套流程摊开讲。我现在的习惯是把这个过程拆成五步走，每一步都有它该干的活，跳步容易返工。刚开始用AI那阵子我图省事，跳过了需求建模，直接把表结构甩给模型让它随便生成，出来的数据乍一看挺像回事，拿到测试环境一跑，关联字段对不上、状态跳转不合法，返工的时间比手工造还长。吃过那次亏之后我才明白，AI生成测试数据这事，功夫在生成之前。
2.1 测试数据需求建模：字段、约束、分布与覆盖目标
我现在动手前先做一张需求表，不复杂，但必须落到纸面上。字段这一列写清楚有哪些、什么类型、长度多少、是否必填；约束那一列记业务规则，比如金额必须大于零、状态只能是那几个枚举值、注册时间不能晚于当前时间；分布那一列写期望的数据形态，年龄集中在哪个区间、订单金额是均匀分布还是长尾分布；覆盖目标单独拉一列，把要触达的场景列全，正常值、边界值、空值、超长值、异常组合各要几条。
这张表看着琐碎，用处很大。一是给AI的提示词有了骨架，不用每次现想；二是生成完拿它当核对清单，逐项打勾；三是后面迭代的时候直接改表就行，不用从头捋。我做过一个支付系统的项目，光"金额"这个字段就列了七八条约束：最小值、最大值、两位小数、不能为负、退款金额不能超过原单、部分退款后剩余金额要能继续退。这些约束不列出来，AI生成的数据跑退款流程一跑一个错。
覆盖目标这块我踩过坑。一开始只想着"多生成点"，数量上去了但场景没铺开，跑完一轮测试发现几个关键状态压根没数据。后来我改成先列场景再定量，比如"已取消订单"要覆盖用户主动取消、超时取消、库存不足取消三种来源，每种来源各生成五到十条，配比上再跟真实业务大致对齐。这样出来的数据集小是小，但该测的都测到了。需求建模这一步花的时间，后面能从校验和返工里省回来。
2.2 提示词与上下文设计：让AI理解业务规则和边界条件
提示词我写过几十版，慢慢摸出点门道。最有效的做法是把业务规则翻译成"人能看懂的话"，别用行话糊弄模型。比如订单状态机，我不写"状态需满足FSM约束"，而是把流转路径一条条列出来：待支付只能变成已支付或已取消，已支付只能变成已发货或退款中，退款中只能变成已退款或退款失败。模型理解这种具体描述比理解抽象术语靠谱得多。
上下文我也会给足。光有表结构不够，我把字段的业务含义一并写进去，比如"status字段：0待支付、1已支付、2已发货、3已完成、4已取消"，再补一段真实业务场景的描述，说明这套订单系统是卖给谁的、下单到完成的典型周期。模型拿到这些背景信息后，生成的地址、商品名、备注都更贴业务，不会出来一堆"测试商品001"。
正例和反例是我的另一个习惯。我会在提示词里写两三条"合格的样本长什么样"和"不合格的样本长什么样"，模型对照着来，边界把握得准很多。有一次做优惠券数据，我怎么调都出来一堆过期券，后来补了一条反例——"不要生成所有券都已过期，至少保留三成有效券、两成未生效券"，问题当场解决。边界条件我会用"必须""禁止""至少""至多"这类词写死，模糊表述尽量少用，"适当""合理"这种词模型容易自由发挥。
2.3 批量生成、数据变异与异常样本构造策略
批量生成我习惯分批走，不一次要几千条。先把提示词调到能稳定产出十几条合格数据，再逐步放大批量。批量大了模型容易偷懒，后半截数据同质化明显，姓名翻来覆去那几个，地址也开始重复。我现在的做法是一批两百到五百条，每批稍微换个提示词侧重，比如这批侧重边界值，下批侧重状态组合，最后合并去重。
数据变异是我后来才用上的招。直接让模型生成异常数据有时不够"坏"，它生成来生成去都是格式错误那种低级异常。我改成先生成一批完全合法的数据，再写脚本或者让模型在合法数据上做定向扰动：把金额改成负数、把日期改到未来、把枚举值替换成未定义的值、把必填字段置空、把长度刚好卡在阈值上下。这样构造出来的异常样本更贴近真实缺陷场景，比如金额为负触发退款逻辑异常，日期在未来导致统计报表出错。
异常样本的配比我一般控制在两到三成，剩下的是正常数据和边界数据。全生成异常数据没法跑正常流程，全生成正常数据又测不出健壮性。我还会专门留一批"脏数据"，就是那种格式正确但内容离谱的，比如备注写满五千字、地址里嵌特殊字符、姓名带生僻字，这类数据专治各种编码和截断问题。批量生成和变异这两步我都做成脚本，跑一次几分钟，比手工构造快太多。
2.4 生成结果的校验、去重、抽样与人工复核机制
数据生成完不能直接用，我吃过这个亏。有一批用户数据看着没毛病，导进库之后才发现手机号字段全是十一位但中间有几位固定，跑接口测试时全撞在同一个手机号上。从那以后校验成了固定动作，分三层走：格式层查类型、长度、格式是否合规；业务层查约束是否满足，金额正负、状态合法性、时间先后关系；关联层查主外键能不能对上，订单里的用户ID在用户表里存不存在。
去重我用字段组合判断，单字段去重容易误杀，姓名重了很正常，手机号+邮箱+身份证号组合起来重复才算真重复。抽样复核我一般抽百分之五到十，人工看一遍，重点看分布是不是合理、异常数据是不是符合预期、有没有明显离群的值。抽样这步不能省，机器校验查的是规则，人眼查的是"像不像真的"，两者互补。
人工复核我还拉了业务测试的同学一起做。他们对业务规则熟，一眼能看出"这个订单状态组合在我们系统里根本不可能出现"。有一次他们指出一批退款数据里退款时间和下单时间只差几秒，虽然规则上合法，但业务上不可能这么快，后来的用例里专门加了一条针对这种情况的校验。复核记录我会留档，哪些规则被违反过、后来怎么改的提示词，攒下来就是团队的资产，下次做类似项目直接参考。
2.5 将生成数据交付到测试环境与持续集成流程
数据从生成到进环境中间还有一段路要走，这段路我一开始没当回事，后来发现最容易出乱子。交付方式我现在固定几种：小批量用CSV或者JSON文件，随用例走；中批量用SQL脚本，按依赖顺序插入；大批量走数据加载工具或者直接调接口灌数据。选哪种看场景，接口测试用JSON报文最直接，数据库测试用SQL脚本最省事，性能测试得走专门的加载通道。
进持续集成这块我踩的坑最多。最早是每次流水线跑起来现生成数据，结果有几次模型输出不稳定，流水线红了半天查不出原因。后来改成生成和加载分离，数据生成后落盘存成文件，跟代码一起进版本库，流水线直接用文件不现生成。文件里带着种子、提示词版本和生成时间，出了问题能追溯。数据文件也加了校验步骤，加载前先跑一遍格式和唯一性检查，不通过就直接拦住。
环境隔离我也做了区分。开发环境的数据可以有脏数据、边界数据多一些，方便开发自己调试；测试环境的数据要求最严，分布和配比都得按需求表来；预发布环境我一般只用脱敏后的合成数据，量也控制得小。数据清理这块我加了个前置钩子，每轮测试开始前先清空或者回滚到基线状态，避免上一轮的数据干扰这一轮。这套跑顺之后，数据准备从原来每次半天的活，变成流水线里一个自动步骤，我只在复核环节出现一下就行。
整套流程跑下来，我的体感是前面慢后面快。需求建模和提示词设计占了大头时间，一旦调好，后面批量生成、校验、加载都能半自动化。我现在接新项目，前两三天基本都在建表、写提示词、调样本，之后每轮迭代就是改改参数、跑跑脚本、抽抽样，边际成本很低。这条路上没有一劳永逸的配置，业务在变、模型在变，流程也得跟着调。我每隔一两个月回头看看需求表，把新冒出来的业务规则补进去，提示词也跟着更新一版，这套东西用久了是越用越顺手的。
前面把流程捋完了，这一章往深里挖一层，专门聊结构化数据。所谓结构化，说白了就是有格式、有约束、有字段定义的数据，数据库表、JSON、CSV、接口报文都属于这一类。这类数据是AI生成的主战场，也是最容易翻车的地方。我见过太多人把表结构往模型面前一扔，出来一堆字段对得上但逻辑全错的数据，导入就报错。这一章我把自己的做法拆开讲，重点是"可控"两个字。
3.1 如何用AI生成结构化测试数据：表结构、JSON、CSV与API报文场景
不同格式的数据，我用的提示策略完全不一样。表结构数据我习惯把建表语句直接贴给模型，让它照着字段类型和长度生成，同时补一句"遵守数据库约束"。这里有个细节：MySQL和PostgreSQL对字段的容忍度不同，我会在提示词里写明目标数据库，模型生成的日期格式、布尔值表示都会跟着变。有次忘了写，生成的数据里日期是"2024-13-45"这种，数据库直接拒收，白跑一轮。
JSON和CSV我更多用在接口测试和批量导入场景。JSON的关键是嵌套层级和数组结构，我会给模型一个完整的样例报文，包括嵌套的对象和数组，让它按同样的结构填充内容。CSV的坑在分隔符和转义，字段里带逗号、换行、引号的情况必须提前说明，我一般会补一句"对含特殊字符的字段做标准CSV转义"。API报文最麻烦的是字段间的联动，比如请求头里的签名要和请求体对应、时间戳要在有效期内，这种联动关系我会在提示词里单独列一段，模型照着写出来的报文才能通过接口校验。
我现在的习惯是每种格式准备一到两个模板，下次做类似项目直接改模板，比从零写提示词快得多。模板里把格式规范、字段约束、联动关系都写死，模型只负责填内容，出错的概率小很多。
3.2 基于Schema、DDL与OpenAPI的约束注入方法
Schema是结构化数据生成的命根子。我手头常备三种Schema来源：数据库的DDL、JSON Schema、接口的OpenAPI文档。DDL最直接，字段名、类型、长度、是否为空、默认值、索引约束全在里面，我把整段DDL贴进提示词，再补一句"外键关联的表结构如下"，模型基本能守住底线。有次做电商项目，订单表有二十多个字段，我把DDL和字段注释一起给模型，生成的订单数据连运费计算逻辑都对得上，省了我不少校验功夫。
OpenAPI文档是接口测试的利器。我会把相关的接口定义导出来，提取请求体和响应体的Schema，转成模型能读的格式。这里面有个技巧：把required字段、enum枚举、format格式、maximum/minimum这些约束单独拎出来强调一遍，模型对显式标注的约束遵守得更好。我还会把示例报文一起给它，示例比纯Schema更能让模型理解字段的实际含义。
JSON Schema我用得少一些，主要在前端Mock数据场景。它的优势是能描述复杂的嵌套和条件约束，比如"当type为A时字段X必填，为B时字段Y必填"。这种条件约束直接写进提示词，模型能理解，但要多验证几轮，条件分支多了它容易顾此失彼。我的做法是把条件约束拆成几组独立的提示词，每组只生成一种分支的数据，最后合并，比一次性生成所有分支稳。
约束注入这块我踩过一个坑：DDL里有些约束是数据库层面的，比如唯一索引、触发器、存储过程，这些贴给模型它看不懂也不会遵守。我的办法是把这些约束翻译成业务语言补在提示词后面，比如"email字段全局唯一，不要生成重复值"，模型才知道该怎么做。
3.3 关联数据与引用完整性：主外键、枚举、状态机与业务规则
关联数据是结构化生成里最费劲的部分。单表数据好生成，一到多表关联就容易出乱子，订单里的用户ID在用户表里找不到、订单明细的商品ID在商品表里不存在，这种数据导进库要么报外键错误，要么跑测试时各种空指针。我现在的做法是先父后子，先生成主表数据并落盘，把主键列表提取出来，作为上下文喂给模型生成子表数据，提示词里明确写"user_id必须从以下列表中选取"。
枚举和状态机是另一个重灾区。枚举值我会在提示词里写死，比如"status只能是pending、paid、shipped、completed、cancelled之一"，同时给出每个值的业务含义。状态机更复杂，订单从下单到完成有固定的流转路径，AI生成的数据经常出现"已发货又回到待支付"这种非法跳转。我的处理办法是把状态流转图画成文字描述，一条条列在提示词里，再补一句"生成的数据必须符合上述流转路径"。有次做物流系统，状态多达十几种，我把流转矩阵直接贴进去，模型生成的运单数据基本没再出过非法状态。
业务规则这块最难穷举。金额不能为负、退款不能超过原单、优惠券不能叠加使用、库存不能超卖，这些规则散落在需求文档和代码里，AI不可能自己知道。我的做法是每次生成前花半小时把相关规则整理成清单，一条条写进提示词。清单不用一次求全，跑一轮测试发现新规则就补进去，提示词跟着迭代。这套做法坚持下来，我现在手头的提示词模板里攒了几十条通用规则，新项目直接复用，只补项目特有的部分。
引用完整性还有一个隐性要求：数据量要匹配。订单表生成一千条，用户表只生成十条，一个用户对应一百个订单，跑性能测试时热点全集中在那几个用户上。我会在提示词里写明配比，比如"用户与订单按一比五生成"，或者干脆分两批生成，先定用户量再按比例定订单量。
3.4 边界值、异常值与脱敏合成数据的生成策略
边界值我有一套固定的构造方法。数值字段取最小值、最大值、最小值减一、最大值加一、零、负数；字符串字段取空串、单字符、最大长度、最大长度加一、含特殊字符；日期字段取过去、未来、临界时间点、闰年闰月。这些边界值我不指望AI一次全生成对，而是把清单列出来让它逐个填充，填完再用脚本校验一遍。有次做金额字段测试，最大长度加一的值模型生成成了科学计数法，数据库不认，这种细节必须靠校验兜底。
异常值要"坏得有逻辑"。纯格式错误那种异常太低级，真正有价值的是业务逻辑上的异常：金额为负触发退款、库存为零时下单、优惠券过期后使用、并发修改导致版本号冲突。我会把这些场景描述清楚让模型生成，再人工挑一部分做定向变异。比如生成一批合法订单，再用脚本把其中几笔的支付时间改到下单时间之前，构造出时间倒挂的异常数据，专测系统的校验逻辑。
脱敏合成数据这块我格外小心。真实用户数据绝对不能进提示词，这是红线。我的做法是用AI生成完全虚构的数据，姓名用生僻字组合、手机号用特定号段、身份证号用符合校验规则的假号、地址用虚构的门牌号。生成完还会跑一遍脱敏检测，确认和真实数据没有重合。有一次项目要求数据分布贴近生产环境，我把真实数据的统计特征提取出来（比如年龄分布、地域分布、金额区间），只把特征喂给模型，不给原始数据，生成出来的数据分布相近但不含任何真实信息。
脱敏数据还要保持格式一致。手机号得是十一位、身份证号得能通过校验位、银行卡号得符合Luhn算法，这些格式约束我会写进提示词。模型有时候会自作聪明生成"13800000000"这种明显假号，测试时全撞在一起，我会专门要求"号段随机、尾号分散、避免连续重复"。
3.5 结构化测试数据质量评估：合法性、覆盖率与可复现性
数据生成完得有个评估标准，不然全凭感觉。我定三个维度：合法性、覆盖率、可复现性。合法性最简单，写脚本查一遍类型、长度、格式、约束、关联完整性，不通过就打回重生成。这块我现在基本全自动，脚本跑完出一个报告，哪条数据哪个字段违规一目了然。覆盖率稍微麻烦点，得对照需求表检查场景有没有铺全，正常值、边界值、异常值各占多少，状态机每个状态有没有数据，枚举每个值有没有覆盖。我会写个统计脚本，把生成数据的分布打出来，和预期配比对照。
可复现性是我后来才重视的。早期生成数据没留记录，出了问题想复现都复现不了。现在每次生成我都记录四样东西：提示词版本、Schema版本、随机种子、生成时间。模型输出不稳定的时候，拿同样的种子和提示词重跑，能复现出一样的数据。种子这个参数很多模型都支持，用好了能省很多排查时间。我还会把生成的数据文件连同元信息一起入库，跟代码版本绑定，回归测试直接用，不现生成。
质量评估我还加了一条人工抽检。机器查规则，人眼查"像不像"。抽百分之五左右的数据看一眼，重点看分布是否合理、异常值是否符合预期、有没有一眼假的模式。业务测试的同学也会参与抽检，他们对业务场景敏感，经常能挑出机器查不出来的问题。抽检记录我会留档，违规的规则、修改的提示词、调整的参数都记下来，攒成团队的知识库，下次做同类项目直接查。
这套评估跑顺之后，我对生成数据的信心足了很多。以前是生成完不敢直接用，非得人工全量过一遍；现在是机器校验加小比例抽检，大部分数据能直接进环境。评估指标我也会定期回顾，业务变了、模型升级了，指标阈值跟着调，这套东西不是定死的，得跟着实际情况走。
工具这块我踩的坑比流程和结构化那两章加起来都多。前面聊的是"怎么生成"，这一章聊"用什么生成"。我最早的做法很朴素，打开聊天窗口贴一段表结构，让模型吐数据，能用但不可持续。项目一多、团队一扩，问题全冒出来了：谁来管提示词、生成记录存在哪、换个人怎么复用。这几节我把用过的工具按类别摊开讲，附上我的选型逻辑和踩坑记录。
4.1 AI生成测试数据工具推荐：选型维度与评估框架
我选工具不看宣传页上的功能列表，看五个维度：可控性、可复现性、集成成本、合规能力和长期维护成本。可控性排第一，指的是能不能精确控制字段规则、数据分布和异常样本比例。有些工具界面漂亮，一键生成十万条数据，结果你想指定"十分之一的订单状态是已取消"都做不到，这种工具我直接 pass。可复现性指的是同样的输入能不能拿到同样的输出，种子、提示词版本、Schema版本这些得能固定住，不然回归测试没法做。
集成成本是很多团队忽略的。工具再好，如果生成的数据要靠人工导出 CSV 再手工导入测试环境，那它在 CI 流程里就是个断点。我会重点看工具有没有 API、能不能嵌进流水线、有没有命令行版本。合规能力对金融和医疗类项目是硬门槛，数据出不出内网、能不能本地部署、生成过程会不会把 Schema 传到第三方服务，这些必须提前问清楚，别等上线了才发现数据合规过不了审。
长期维护成本我吃过亏。早期图省事用了一个小众开源工具，作者半年不更新，模型接口一变整条链路全断。现在我优先选社区活跃、有商业公司背书的工具，哪怕贵一点。评估框架我会列一张打分表，五个维度各占权重，每个候选工具打分，分数不是决定性的，但能帮我把感性判断拉回理性，免得被某个炫酷功能带偏。
4.2 通用大模型与提示词工作流：快速原型和自定义场景实践
通用大模型是我做快速原型的首选。GPT-4、Claude、DeepSeek、通义千问、Kimi 这几个我都用过，各自脾性不一样。GPT-4 对复杂约束的理解最稳，嵌套 JSON 和业务规则联动很少出错，缺点是贵，大批量生成成本吃不消。DeepSeek 和通义千问在中文业务场景下表现不错，字段注释是中文的时候理解准确率明显高，价格也友好，适合日常批量跑。Claude 在长上下文场景里优势明显，一次贴几十张表的 DDL 它也能扛住。
提示词工作流这块我自己攒了一套土办法。每种数据格式一个模板文件，模板里分三段：格式规范、字段约束、业务规则。模板存在 Git 仓库里，跟项目代码放一起，改提示词走正常的代码评审流程。生成脚本读模板、拼参数、调模型 API、落盘，一条命令跑完。这套东西不高级，但胜在透明，谁都能看懂、谁都能改。我带的几个项目现在都这么干，新同事上手半天就能自己加模板。
通用模型的短板也很明显。它不理解"数据库约束"这种工程概念，你写"遵守外键约束"它未必照做；批量生成几千条的时候，它会在中间偷懒，后面几百条质量断崖式下降；还有个隐蔽问题，同样的提示词跑两次结果不一样，回归测试没法复用。我的应对办法是分片生成，一次只让它生成两百到五百条，生成完立刻校验，不合格的重跑这一片。分片加校验这套组合拳下来，通用模型的可用性提升一大截。
4.3 专用测试数据生成平台与开源工具对比
专用平台我认真评估过几家。Mockaroo 上手快，字段类型丰富，支持正则和自定义列表，做 UI 原型和简单接口测试够用，缺点是业务规则表达能力弱，复杂的关联数据搞不定。Synthesized 和 Tonic 这类偏企业级，主打的是从生产数据里学分布、生成结构一致的合成数据，脱敏和合规做得扎实，价格也企业级。Delphix 和 K2View 更偏数据虚拟化，测试数据生成是附带能力，适合已经在用它们做数据管理的团队。
开源工具里 Faker 系列是我用得最多的。Faker.js、Python 的 Faker、Java 的 Datafaker，生态成熟，本地生成不联网，合规上最省心。它的定位是"造看起来像真的假数据"，姓名、地址、手机号、公司名这些开箱即用，业务字段得自己写 Provider 扩展。Mock.js 在前端圈子里流行，拦截 Ajax 请求返回 Mock 数据很方便，做前后端分离联调时省事，但它不解决数据分布和关联性问题。
专用平台和开源工具的分界线在"业务规则"上。开箱即用的工具解决的是通用字段，一旦涉及订单状态机、金额计算、库存扣减这类业务逻辑，要么自己写扩展，要么回到大模型加提示词的路子。我现在的组合是：基础字段用 Faker 生成，业务字段和关联关系用大模型补，两边拼起来再校验。这套组合不优雅，但灵活，项目之间迁移成本低。
4.4 数据库、接口测试工具中的AI能力评估
数据库工具里的 AI 能力这两年冒出来不少。Navicat、DataGrip 这些老牌工具陆续加了自然语言转 SQL、SQL 解释之类的功能，拿来生成测试数据有点绕，得先让它写 INSERT 语句再执行，中间多一层转换。我试过几次，简单表还行，字段一多它生成的 INSERT 语句字段顺序经常对不上，得手工调。这类能力目前更适合辅助写查询，生成数据只能算顺手用用。
接口测试工具这块变化快。Postman 加了 AI 辅助生成请求体和测试脚本，Apifox 有根据接口文档生成 Mock 数据的能力，国产工具在这块迭代速度比国外快。我的实际体验是，基于 OpenAPI 文档生成单条请求体效果不错，字段结构和类型基本能对上，批量生成和异常样本构造还是得靠外面的大模型。JMeter 生态里也有一些 AI 插件，成熟度参差不齐，我持观望态度。
评估这类内置 AI 能力，我看三点：能不能读到完整的 Schema、生成结果能不能导出复用、有没有版本记录。很多工具的内置 AI 是个黑盒，提示词改不了、生成逻辑看不见，出了问题没法排查，这种我最多拿来做个参考，不敢放进正式流程。工具自带的 AI 能力我会定期重新评估，这个领域三个月一变，上季度还不好用的功能这季度可能就补上了。
4.5 工具选型清单、POC验证与落地决策方法
选型清单我固定用一张表，分必选项和加分项。必选项包括：支持从 DDL 和 OpenAPI 导入约束、支持固定随机种子、有 API 或命令行接口、支持本地或私有化部署、有明确的版本更新记录。加分项包括：内置数据脱敏、支持数据分布配置、有可视化界面、社区活跃度高、有中文文档。必选项缺一个我基本就不考虑了，加分项按项目实际情况取舍。
POC 验证我有个固定套路，拿项目里真实的一张主表加两张子表，要求候选工具生成一千条关联数据，覆盖正常值、边界值和三种异常场景。验证指标四个：一次通过率、生成耗时、复现一致性、人工修正工作量。一次通过率指的是生成完直接跑校验脚本不用改的比例，低于八成我就得掂量掂量。复现一致性我会用同样的配置跑两遍，比对结果差异。人工修正工作量最实在，让测试同学实际用一遍，记录改了多少条、改了什么，这个数据比任何宣传都可信。
落地决策我不追求一步到位。通常是先在一个项目里试点，跑一个月看稳定性，稳定了再推到第二个项目。工具切换有成本，团队熟悉一套工具得几周时间，频繁换工具比用错工具还伤。我现在的原则是：核心链路用经过验证的成熟工具，边缘场景可以试新工具，试出来好的再往核心链路迁。工具选型没有标准答案，适合当前团队规模、项目节奏和合规要求的，就是好选择。
前面四章聊的是怎么把数据造出来，这一章聊怎么把它用好、用稳、用得让团队放心。我见过太多团队在POC阶段效果惊艳，一进真实项目就翻车。翻车的原因很少是模型不行，基本都是工程规范没跟上。质量没标准、合规没红线、复现没保障、规模化没配套，任何一个环节松了，前面攒的那点效率红利全吐回去。
5.1 建立测试数据质量标准与验收指标
我头半年做AI造数基本靠"看着差不多就行"。测试同学跑完用例没报错，数据就算过关。这套土办法坑了我好几次。有一回接口测试全绿，上线后才发现优惠券金额算错了，测试数据里压根没造过大额券叠加的场景。问题不在用例写得差，在数据本身没标准，谁也不知道该覆盖到什么程度，造数的人凭感觉，验数的人也凭感觉。
后来我把质量标准拆成四个能算数的指标：字段合法率、业务规则通过率、场景覆盖率、异常样本占比。字段合法率好理解，类型、长度、格式都得对，用脚本扫一遍就能出数。业务规则通过率指的是数据能不能过业务校验，订单金额等于明细之和、库存扣减不为负、状态流转不跳级，这些规则我从代码里抠出来写成校验函数，跟造数脚本绑着跑。场景覆盖率按需求文档里的业务场景清单来对，每个场景至少对应一组数据。异常样本占比我一般控制在百分之十到十五，太少了练不出系统的容错能力，太多了排查成本吃不消。
验收指标必须能自动校验，这是死规矩。靠人眼看数据对不对，看一百条就眼花，看一万条根本不可能。我把校验脚本和生成脚本串成一条命令，生成完自动出一份报告：通过率多少、哪些字段挂了、哪条规则没过。通过率低于九成直接打回重跑，不往测试环境里送。这套机制跑顺了以后，测试同学不再问"这数据能用吗"，改问"这份报告里哪几条没过"，沟通成本降了一大截。
可复现性验收也进了我的清单。同一套配置跑两次，结果必须能对上，对不上说明有随机因素没被控制住。每次发版前跑一遍双生成比对，差异报告存进批次记录。这条指标不显眼，但它是后面版本管理和回归测试的地基。
5.2 隐私保护与脱敏合成：避免真实敏感数据进入提示词
隐私这块我见过最吓人的操作，是有同事把生产库导出的CSV直接贴进对话框，让模型"照着这个格式造数据"。那份CSV里有真实手机号、身份证号和收货地址。事情没出事纯属运气，但这事给我敲了警钟。后来我在团队里立了条铁律：提示词里只放结构，不放值。
结构指的是DDL、字段注释、枚举定义、规则说明。值一个都不能带，哪怕是所谓的"示例值"也不行。很多人以为示例值脱敏过，实际上一串看着像假的手机号，很可能就是某个真实用户的。我的做法是把提示词模板分成两层，结构层从Schema自动生成，规则层人工维护，两层拼装的时候加一道正则扫描，命中手机号、身份证、银行卡这些模式就直接拦截。这道扫描拦下过好几次手滑，有次一个同事在字段注释里写了"参考客户张三138xxxx"，扫描直接给拦了。
模型部署方式得跟项目合规要求对齐。金融和医疗类项目我只用内网私有化部署的模型，数据不出机房。普通业务线可以用公有云API，前提是提示词经过扫描确认无敏感值。有些团队图省事全用公有云，等安全部门来查的时候整条链路推倒重来，那个返工成本比一开始就分开部署高得多。合规审查这件事，提前问一句能省掉后面十句解释。
脱敏合成这条路我推荐"合成优先"而不是"脱敏优先"。脱敏是在真实数据上做变形，变形规则一旦有漏洞就漏数据；合成是从零造数据，压根不接触真实值，风险面小很多。真实数据只在一种情况下用：需要拟合真实分布做性能压测。这时候也得先在内网做聚合统计，只把分布参数拿出来用，原始记录不离开生产域。这套流程走下来麻烦，但睡得着觉。
5.3 可复现性与版本管理：种子、提示词、Schema和生成记录
可复现性这事我吃过一次大亏。一个回归测试套件跑了两周都稳定，第三周突然开始随机挂。查了两天才发现是造数脚本调用的模型接口升级了，同样的提示词输出风格变了，几条边界数据造不出来，用例就挂了。那次之后我把"生成环境要版本化"写进了团队规范，不是建议，是硬性要求。
版本化管四样东西：随机种子、提示词模板、Schema定义、模型标识。种子固定住，伪随机序列就固定住。提示词模板进Git，改动走代码评审，跟业务代码一个待遇。Schema跟着项目代码一起版本化，表结构变了生成配置跟着变。模型标识要记到具体版本号，不能只写"GPT-4"，得写清楚是哪个快照、哪个日期。这四样凑齐了，一次生成结果就能完整复现，出问题能定位到具体是哪一样变了。
生成记录我存在对象存储里，按项目、按日期、按批次分目录。每条记录包含配置快照、输入哈希、输出文件路径、校验报告。查询的时候按输入哈希找，同样的输入配置能直接定位到历史输出，不用重跑。重跑成本不低，大模型API按token计费，批量生成几千条一次几块钱到几十块钱，项目多了这笔账不小。能复用就复用，省下来的钱够团队喝好几轮咖啡。
提示词模板的版本管理我用了个笨办法：模板文件名带语义化版本号，模板内容头部写changelog。改模板的人必须写清楚改了什么、为什么改、影响哪些项目。这个规矩执行起来有点烦，但它救过我一次。某个项目的数据突然大面积校验失败，翻changelog发现是有人改共享模板时动了枚举值，五分钟定位，十分钟回滚，没耽误发版。
5.4 在CI/CD与测试左移中的规模化应用
小规模用AI造数，手工跑脚本就够。项目一多、流水线一密，手工那套立刻撑不住。我现在的做法是把生成能力包成一个内部服务，对外暴露两个接口：一个按配置生成数据集，一个按数据集ID查询状态。流水线里加一个stage调这个服务，生成完自动触发校验，校验过了才往下走。测试同学不用关心模型是哪家的、提示词怎么写的，只管提配置、看报告。
测试左移这块我的体会是，数据契约得在需求评审阶段就定下来。以前是开发写完代码、测试写完用例，才想起造数据，数据成了卡脖子环节。现在需求评审会上就把关键字段、边界条件、异常场景列出来，形成一份数据需求清单。这份清单跟着需求文档走，开发阶段就能开始造数，等代码提测的时候数据已经备好了。左移省下的时间很实在，一个中等项目从提测到开测的等待时间从两天压到半天，测试同学也不用加班等数据了。
规模化绕不开成本和配额问题。大模型API有速率限制，一次要造十万条数据，串行调用得跑到天亮。我的解法是分片加并发，把数据集切成每片五百到一千条，多个worker并行跑，跑完合并校验。并发度控制在API配额以内，超了会被限流，反而更慢。缓存也得用上，相同配置的数据集生成一次就存起来，后续流水线直接拉缓存，重复调用的钱省下来很可观。
还有个规模化之后才冒出来的新问题：数据积压。每个流水线都造一份数据，存着不清理，三个月下来对象存储账单能吓人一跳。我加了个生命周期策略，非基线数据集保留三十天自动清理，基线数据集打标签长期保留。基线数据集的判定标准是覆盖核心业务场景的那几套，数量控制在项目组能维护的范围内。清理策略上线第一个月，存储成本降了六成，团队再没人抱怨"造数服务太贵"。
5.5 常见失败案例、风险控制与团队协作规范
失败案例我攒了一箩筐。最典型的一个是模型幻觉造出非法数据：字段要求是枚举值，模型自作主张造了个"待审核中"，校验脚本没覆盖到这个字段，数据进了测试环境，接口直接500。教训是校验规则要跟Schema自动同步，字段加进Schema校验规则跟着加，不能靠人记。第二个案例是批量生成中途质量塌方，一次让模型生成五千条用户数据，前两千条质量很好，后三千条开始出现重复记录和格式错乱。分段生成加分段校验之后这个问题基本消失了。第三个案例是工具切换断档，团队从A工具迁到B工具，A的历史生成记录没迁移，老项目的回归测试没法复现，只能重新造数。迁移之前先把历史记录归档，这个动作不能省。
风险控制我总结成三道闸：生成前的提示词扫描、生成中的分片校验、生成后的抽样人工复核。三道闸都过了的数据才进测试环境。人工复核不用全量，按批次抽百分之五，重点看业务规则相关的字段。抽检发现问题就整批打回，同时复盘是哪道闸漏了。三道闸不是摆设，每道都有拦截记录，季度复盘的时候拿出来看，能发现不少规律。有段时间提示词扫描拦得特别多，一查是某个新同事不知道规矩，培训完就消停了。
团队协作规范我写成一页纸的文档，钉在项目wiki首页。内容就几条：提示词模板谁维护、改动走什么流程、生成记录存哪、校验报告谁看、合规审查谁签字。规矩越简单越容易执行，写十页的规范没人看。我还设了个轮值角色，每周一个人负责审核新提交的提示词模板和处理校验失败告警，轮着来大家都有感知，不会出现"这事归谁管"的扯皮。轮值表贴在wiki上，谁当值一目了然。
这套规范跑了大半年，最大的变化是造数从"某个人的手艺"变成了"团队的基础设施"。新人进来照着文档走，半天能上手。老人离职，流程照样转。质量、合规、规模化这三件事，说到底拼的不是模型多强、工具多好，是团队愿不愿意把脏活累活标准化。标准化做扎实了，AI造数才真正算落了地。
