问题背景
考考你：你的测试环境，上一次真正“打扫干净”是什么时候？
大概率是这副光景——
- 商品列表里堆满了“test商品001”、“测试商品abc”，看着就头疼；
- 用户管理里“newuser_001”、“测试账号xxx”扎堆；
- 订单表里几千条测试订单，查询速度肉眼可见地变慢；
- 同一个用例想跑第二次，因为账号重复直接报错；
- 多人协作共用一个环境，并发执行相互污染数据；
- 手动清理吧，又怕误删核心配置，战战兢兢；
- 不清吧，Flaky Test越来越多，自动化测试的可信度直线下降；
- 最后实在没办法，只能“删库重来”，但其他人又跟着遭殃……
行业统计显示，数据污染占Flaky Test成因的60%以上——这个数字，足以说明问题。它就是接口自动化“随机失败”的头号元凶。
如果以上场景你中了三条以上，那今天聊的这款工具，你大概率会感兴趣——api-testdata-cleaner，一个能让测试数据“一键净空”的Agent Skill。
一、它是什么？
api-testdata-cleaner是接口自动化测试的数据清理专家，你可以把它理解为测试环境的“智能清洁工”，干的就是脏活累活，但干得干净利落。
它的核心定位非常纯粹——只做一件事：
安全、精准、全场景地清理测试产生的脏数据，实现“执行前数据准备、执行中数据隔离、执行后数据清理”的全流程自动化，让测试环境始终处于“干净、可控、可复用”的状态。
听起来简单？但正是这个“简单”的能力，从源头上解决了接口自动化“随机失败”的顽疾。
二、5大核心卖点
① 三层清理覆盖：DB + Redis + 文件，一个不落
这是它的看家本领。
测试产生的脏数据，可不止数据库一种。api-testdata-cleaner的覆盖范围很全：
| 清理层 | 清理内容 | 清理方式 |
|---|---|---|
| 数据库（MySQL） | 测试账号、商品、分类、订单等 | 按主键批量删除、按条件软删除 |
| 缓存（Redis） | 登录Token、验证码、临时会话 | 按Key前缀批量删除 |
| 本地文件 | 测试日志、报文、临时数据文件 | 按目录扫描清理 |
为什么三层都要清？
道理很简单：只清数据库，残留的Redis Token可能导致登录态错乱；只清缓存，堆积的日志文件可能拖慢环境性能——脏数据在哪，它就清到哪，不留死角。
② 无损清理：白名单保护，核心数据不误删
这也是最让人放心的一点。
自动清理最怕什么？误删核心数据。api-testdata-cleaner用“数据归属标记 + 白名单保护”双重机制，确保只清理测试产生的临时数据，绝不越界：
白名单保护范围：
- 系统内置的admin管理员账号（常驻账号，永不清理）
- 人工预先录入、具备明确业务规则的正式数据
- 基础配置数据、常驻测试账号
测试数据识别特征：
- 内容多存在重复
- 名称、字段中普遍包含“test”、“测试”等标识字样
- 有明确的“数据归属”标记（来自哪次执行）
存疑处理：判定测试数据时如果有不确定的，会主动找人工确认再执行删除，绝不莽撞行事。这种“谨慎”的态度，在自动化工具里确实难得。
③ 业务适配：不是“删库式”清理
这一点最能体现专业度。
普通的清理工具，往往是“DELETE FROM 表”的一刀切——简单粗暴，但会破坏业务关联。api-testdata-cleaner支持按业务模块定制清理规则：
| 业务模块 | 差异化清理规则 |
|---|---|
| 订单模块 | 删除测试订单 + 还原库存 |
| 用户模块 | 注销测试用户 + 清空用户购物车 |
| 商品模块 | 删除测试商品 + 清理关联分类 |
| 购物车 | 清空测试账号的购物车记录 |
为什么非要搞业务适配？
以电商场景为例：如果只删订单不清库存，库存数据会越来越乱；如果只删用户不清购物车，会留下大量孤儿数据——真正的清理，要顺着业务逻辑走，而不是简单的“删库”。这才是专业清理工具该有的样子。
④ 生产环境强制拦截：数据安全的最后一道防线
这是最硬核的设计。
数据清理最怕什么？在生产环境执行了DELETE，那后果不堪设想。
api-testdata-cleaner内置强制拦截机制：
- 严格区分环境：dev / test / prod 三套环境配置隔离
- 生产环境强制终止：识别到prod环境，直接终止执行 + 抛出警告
- 日志全留痕：每一步操作都保留记录，方便审计追溯
这是数据安全的最后一道防线——哪怕配置错了、参数传错了，也不会对生产环境造成任何破坏。这个设计，值得所有做数据清理工具的人借鉴。
⑤ 独立通用：一份能力，全场景适配
这可能是它最被低估的设计巧思。
为什么非要把数据清理独立成Skill，而不是嵌入到执行或修复Skill里？
答案很简单：数据清理是通用能力，使用场景太多了：
- 执行完测试 → 自动清理
- 手动排查Flaky Test → 单独清理
- CI每日回归前 → 定时清理
- 脚本修复重测前 → 重置环境
- 新人入职熟悉环境 → 按需清理
如果逻辑写死在执行/修复Skill里，这些场景都无法单独调用，只能重复编写代码。
独立成Skill的好处是——一份能力、全场景适配，无论何时何地需要清理，一个命令搞定。
三、5个典型使用场景
场景一：日常测试后的数据清理
一轮测试跑完，环境里堆满了测试数据，怎么办？
复制代码/api-testdata-cleaner 清理数据库中重复的测试数据
它会自动连接测试环境数据库，几秒钟完成清理，并生成清理报告——全程无人工介入，省心省力。
场景二：Flaky Test排查前的环境重置
某个用例“有时过、有时不过”，怀疑是数据污染，那就先重置环境：
复制代码/api-testdata-cleaner 清理用户模块和订单模块的测试数据
精准清理指定模块，回到“干净状态”再跑一遍——快速定位是否是数据问题，效率翻倍。
场景三：CI每日回归前的环境初始化
每天凌晨定时回归，需要先重置环境，确保数据基线一致：
复制代码claude -p "调用 api-testdata-cleaner 技能，参数: env_type=test, clean_scope=all, clean_target=all"
--permission-mode bypassPermissions
--output-format json
清理完成后，再触发api-test-executor跑全量回归——保证每次回归的数据基线一致，Flaky Test自然就少了。
场景四：脚本修复重测前的数据隔离
修完一个因为账号重复失败的脚本，想立刻重测，但数据还在：
复制代码/api-testdata-cleaner 清理用户模块测试数据，保留调试日志
通过keep_debug_data=true，清理脏数据但保留调试日志——既隔离数据，又方便复盘，一举两得。
场景五：按模块精细化清理
有时候只想清某个模块，不动其他数据，那就可以：
复制代码/api-testdata-cleaner 只清理购物车模块的测试数据
支持按模块精细化控制（user / cart / order / address / all）——灵活适配各种场景，想清哪就清哪。
四、实战效果：几秒钟干完半天的活
以一个典型的实战场景为例。
起因：调用api-test-executor执行测试、使用api-failure-diagnoser处理脚本故障后，环境中留存了大量测试数据——商品管理里有冗余的测试商品、商品分类里有大量测试分类、用户管理里出现大量测试用户。
比如商品管理中，存在大量冗余的测试商品数据：
商品分类中，存在大量的测试分类数据：
用户管理中间出现大量的测试用户数据：
为避免数据堆积、防止数据污染，设计方案时，面临一个关键选择：到底是在现有技能上做改造，还是新建一个专门负责数据清理的独立Skill？
其实对比一下两个方案的优劣，答案就很清晰了。
方案一：在现有Skill中嵌入清理逻辑
如果把数据库、缓存、临时账号/订单/购物车等数据清理代码，直接写到api-test-executor或api-failure-diagnoser内部，虽然实现简单，短期开发成本低，单次执行也不需要额外调用其它技能，但问题也很明显：
-
违反单一职责原则。此前所有的Skill设计，都遵循一个原则：一个Skill只做一件事：
-
api-test-executor：只负责用例调度、接口执行、结果收集； -
api-failure-diagnoser：只负责故障诊断、脚本修复；如果强行嵌入数据清理，会让单个技能职责臃肿，代码耦合严重，后续维护、修改逻辑时容易牵一发而动全身。
-
-
复用性极差。测试数据清理是通用能力：
-
单条用例调试需要清数据；
-
全量回归前需要初始化环境；
-
定时任务执行前需要重置；
-
问题排查前也需要清理脏数据。
如果逻辑写死在执行/修复技能里，其他场景无法单独调用清理能力，只能重复编写代码，产生冗余。
-
-
灵活性不足，无法按需控制。实际测试中存在差异化需求：
-
部分场景：执行完必须立刻清数据（常规回归）；
-
部分场景：执行完保留数据用于问题排查（故障复盘、BUG定位）；
-
部分场景：只清理某一个模块数据（如仅清空购物车，保留用户账号）。
内嵌逻辑只能“一刀切”，无法灵活配置。
-
方案二：新增独立api-testdata-cleaner数据清理Skill
开发一个独立通用的数据清理技能，专门负责数据库、Redis、临时文件、测试账号、业务临时单据（订单/购物车/优惠券）等全量/指定范围测试数据清理、环境重置工作。
虽然需要额外开发一个新Skill，短期多一点开发工作量，但长期收益远大于成本：
-
遵循单一职责，架构更标准：延续前期拆分Skill的设计思路，各司其职：执行→诊断修复→数据清理，链路清晰，每个模块功能纯粹，更符合企业级自动化工程规范。
-
高复用，全场景适配：该技能可独立调用，也可被其他技能联动调用，覆盖场景非常广泛。
-
配置灵活，支持精细化管控：可在Skill入参中定义规则，按需清理，支持全局清理/按业务模块清理、自动清理/手动触发、调试模式保留数据/正式回归强制清理等开关。
-
可独立迭代扩展：后续新增数据表、缓存、第三方临时数据，只需要更新
api-data-cleaner这一个技能，不用改动整条链路的核心代码，迭代成本极低。
测试验证效果
实践是检验真理的唯一标准。用口语化的方式，直接输入要清理的内容和范围：
复制代码/api-testdata-cleaner 清理数据库中重复的测试数据
接收到提示词后，它会先连接当前测试环境（被测项目的环境配置），校验环境信息是否连接成功，然后开始执行数据库测试数据清理操作。
最终效果，确实让人满意——该删除的测试数据全部删除，之前由人工创建的数据也全部保留下来（没有被误删），而且整个操作几乎是在几秒钟内完成，期间没有任何人工介入的动作。
除了控制台显示清理结果外，还会单独生成一份markdown格式的数据清理报告，方便后续留存：
数据清理完成后，打开被测项目前端页面，比之前干净多了（页面上所有的测试数据全部被清理掉）
执行过程：
- 自动连接测试环境数据库，校验环境信息
- 识别测试数据特征（含test、测试等标识）
- 应用白名单保护规则
- 分模块执行清理
- 生成清理报告
最终效果：
- 该删除的测试数据全部删除
- 人工创建的数据全部保留（没有被误删）
- 整个操作几秒钟完成
- 全程无人工介入
- 单独生成markdown格式的数据清理报告，方便留存
五、适合谁用？
强烈推荐：
- 接口自动化测试工程师：日常清理脏数据、解决Flaky Test
- 测试开发工程师：搭建团队环境管理能力、CI流水线
- 全栈测试工程师：希望降低环境维护门槛
- 测试团队负责人：希望提升环境稳定性、降低Flaky Test困扰
特别适合：
- Flaky Test频发、数据污染严重的团队（立竿见影）
- 多人协作、共享测试环境的团队（避免数据互相污染）
- CI/CD流水线需要定时重置环境的团队
- 测试数据量大、手动清理成本高的团队
不太适合：
- 还没有自动化测试的团队（没数据可清）
- 测试环境与生产环境共用的团队（建议先做好环境隔离）
六、如何获取和安装？
api-testdata-cleaner GitHub仓库地址：
复制代码git clone git@github.com:xxx/skills.git
安装到WorkBuddy：
复制代码cp -r skills/api-testdata-cleaner ~/.workbuddy/skills/
安装到Claude Code：
复制代码cp -r skills/api-testdata-cleaner ~/.claude/skills/
安装完成后，在你的AI工具里直接说：
就可以开始用了。
写在最后
测试行业一直有个共识：“Flaky Test是自动化最大的敌人。”
而Flaky Test最大的源头，就是数据污染（占比60%以上）。
api-testdata-cleaner解决的就是这个源头——让测试环境始终干净、可控、可复用。
它不会替代你的环境管理规范，不会替代你的数据隔离策略，更不会替代你对生产环境的敬畏。它只是把你从手动DELETE、担心误删、反复重置环境的焦虑中解放出来，让你把精力聚焦在更有价值的事情上——测试策略优化、Flaky根因深度分析、自动化体系持续改进。
需要强调的是：数据清理涉及生产安全，任何自动化能力都必须建立严格的保护机制。白名单、环境拦截、日志留痕——这三道防线，缺一不可。
而这，正是AI赋能测试的真正意义——不是替代人，而是让人更安心。
