导读：前两篇我们推荐了让测试"跑起来"的 api-test-executor、让失败脚本"自己修好"的 api-failure-diagnoser。但跑完、修完之后，环境里堆满了测试数据。
今天给大家分享一款一键清空测试数据的 skill——api-testdata-cleaner。
先问大家一个问题：你的测试环境，有多久没"打扫"过了？
大概率是这样的——
行业统计，数据污染占 Flaky Test 成因的 60% 以上——这是接口自动化"随机失败"的头号元凶。
如果以上场景你中了三条以上，那么今天这款 skill，你一定要了解——api-testdata-cleaner，一款能让测试数据"一键净空"的 Agent Skill。
api-testdata-cleaner 是接口自动化测试的数据清理专家，你可以把它理解成测试环境的"智能清洁工"。
它的核心定位非常克制——只做一件事：
安全、精准、全场景地清理测试产生的脏数据，实现"执行前数据准备、执行中数据隔离、执行后数据清理"的全流程自动化，让环境始终处于"干净、可控、可复用"的状态。
听起来简单？但它从源头解决了接口自动化"随机失败"的问题。
这是它最核心的能力。
测试产生的脏数据，不止数据库一种。api-testdata-cleaner 覆盖三层：
| 清理层 | 清理内容 | 清理方式 |
|---|---|---|
| 数据库（MySQL） | 测试账号、商品、分类、订单等 | 按主键批量删除、按条件软删除 |
| 缓存（Redis） | 登录 Token、验证码、临时会话 | 按 Key 前缀批量删除 |
| 本地文件 | 测试日志、报文、临时数据文件 | 按目录扫描清理 |
为什么三层都要清？
因为只清数据库，残留的 Redis Token 可能导致登录态错乱；只清缓存，堆积的日志文件可能拖慢环境——脏数据在哪，它就清到哪。
这是它最让人放心的能力。
自动清理最怕的是什么？误删核心数据。api-testdata-cleaner 用"数据归属标记 + 白名单保护"双重机制，确保只清理测试产生的临时数据：
白名单保护范围：
测试数据识别特征：
存疑处理：判定测试数据时如果有不确定的，会主动找人工确认再执行删除，绝不莽撞行事。
这是它最专业的能力。
普通的清理工具，往往是"DELETE FROM 表"的一刀切——简单粗暴，但会破坏业务关联。api-testdata-cleaner 支持按业务模块定制清理规则：
| 业务模块 | 差异化清理规则 |
|---|---|
| 订单模块 | 删除测试订单 + 还原库存 |
| 用户模块 | 注销测试用户 + 清空用户购物车 |
| 商品模块 | 删除测试商品 + 清理关联分类 |
| 购物车 | 清空测试账号的购物车记录 |
为什么要做业务适配？
以电商场景为例：如果只删订单不清库存，库存数据会越来越乱；如果只删用户不清购物车，会留下大量孤儿数据——真正的清理，要顺着业务逻辑走，而不是简单的"删库"。
这是它最硬核的能力。
数据清理最怕的是什么？在生产环境执行了 DELETE。
api-testdata-cleaner 内置强制拦截机制：
这是数据安全的最后一道防线——哪怕配置错了、参数传错了，也不会对生产环境造成任何破坏。
这是它最被低估的设计哲学。
为什么把数据清理独立成 Skill，而不是嵌入到执行或修复 Skill 里？
因为数据清理是通用能力，使用场景非常多：
如果逻辑写死在执行/修复 Skill 里，这些场景都无法单独调用，只能重复编写代码。
独立成 Skill 的好处是——一份能力、全场景适配，无论何时何地需要清理，一个命令搞定。
场景一：日常测试后的数据清理
一轮测试跑完，环境里堆满了测试数据：
/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 跑全量回归——保证每次回归的数据基线一致。
场景四：脚本修复重测前的数据隔离
修完一个因为账号重复失败的脚本，想立刻重测：
/api-testdata-cleaner 清理用户模块测试数据，保留调试日志
通过 keep_debug_data=true，清理脏数据但保留调试日志——既隔离数据，又方便复盘。
场景五：按模块精细化清理
只想清某个模块，不动其他数据：
/api-testdata-cleaner 只清理购物车模块的测试数据
支持按模块精细化控制（user / cart / order / address / all）——灵活适配各种场景。
这是AI 进化社中一个非常典型的实战场景。
起因：调用 api-test-executor 执行测试、使用 api-failure-diagnoser 处理脚本故障后，环境中留存了大量测试数据——商品管理里有冗余的测试商品、商品分类里有大量测试分类、用户管理里出现大量测试用户。
比如商品管理中，存在大量冗余的测试商品数据：
商品分类中，存在大量的测试分类数据：
用户管理中出现大量的测试用户数据：
为避免数据堆积、防止数据污染，我希望在每轮接口测试执行和校验完毕后，能自动清理这些测试数据。
但如此同时，会面临一个方案实现决择，针对这个需求，我们应该是选择在现有技能上做改造，还是新建一个专门负责数据清理的独立Skill技能？
先说结论：优先考虑新增一个独立的技能，比如
api-testdata-cleaner（测试数据自动清理技能），如果有需要，还可以通过调用链联动，在接口执行、故障修复完成后自动触发清理；
为什么？原因其实很简单，我们可以先对比一下这两个方案的优劣区别。
如果在现有 Skill 中嵌入清理逻辑，也就是把数据库、缓存、临时账号 / 订单 / 购物车等数据清理代码，直接写到 api-test-executor 或 api-failure-diagnoser 内部。虽然实现简单，短期开发成本低，单次执行也不需要额外调用其它技能，但：
违反了单一职责原则，我们前面所有的skill技能设计，都遵循一个原则：一个 Skill 只做一件事：
api-test-executor：只负责用例调度、接口执行、结果收集；
api-failure-diagnoser：只负责故障诊断、脚本修复；
如果强行嵌入数据清理，会让单个技能职责臃肿，代码耦合严重，后续维护、修改逻辑时容易牵一发而动全身。
复用性极差，测试数据清理是通用能力：
单条用例调试需要清数据；
全量回归前需要初始化环境；
定时任务执行前需要重置；
问题排查前也需要清理脏数据。
如果逻辑写死在执行 / 修复技能里，其他场景无法单独调用清理能力，只能重复编写代码，产生冗余。
灵活性不足，无法按需控制，实际测试中存在差异化需求：
部分场景：执行完必须立刻清数据（常规回归）；
部分场景：执行完保留数据用于问题排查（故障复盘、BUG 定位）；
部分场景：只清理某一个模块数据（如仅清空购物车，保留用户账号）。
内嵌逻辑只能 “一刀切”，无法灵活配置
开发一个独立通用的数据清理技能，可以让其专门负责数据库、Redis、临时文件、测试账号、业务临时单据（订单 / 购物车 / 优惠券） 等全量 / 指定范围测试数据清理、环境重置工作。
虽然需要额外开发一个新 Skill，短期多一点开发工作量，但长期收益远大于成本，具体表现在几方面：
循单一职责，架构更标准：
高复用，全场景适配，该技能可独立调用，也可被其他技能联动调用：
配置灵活，支持精细化管控，可在 Skill 入参中定义规则，按需清理：
支持全局清理 / 按业务模块清理（用户 / 订单 / 购物车分离清理）；
支持 “执行后自动清理” / “手动触发清理” 两种模式；
支持 “调试模式保留数据” / “正式回归强制清理” 开关。
可独立迭代扩展
后续新增数据表、缓存、第三方临时数据，只需要更新 api-data-cleaner 这一个技能，不用改动整条链路的核心代码，迭代成本极低。
用口语化的方式，直接输入要清理的内容和范围
/api-testdata-cleaner 清理数据库中重复的测试数据
接收到提示词后，会先连接当前测试环境（被测项目的环境配置），校验环境信息是否连接成功，然后开始执行数据库测试数据清理操作。
最终效果，我还是挺满意的，该删除的测试数据全部都删除了，之前由我人工创建的数据也全部保留下来了（没有被误删），而且整个操作几乎是在几秒钟内完成，期间没有任何人工介入的动作。
除了控制台显示清理结果外，还会单独生成一份markdown格式的数据清理报告，方便后续留存：
数据清理完成后，我们打开被测项目前端页面，在前端页面上，比之前干净多了（页面上所有的测试数据全部被清理掉了)
执行过程：
最终效果：
温馨提醒：如果在新开会话中调用，需要提供被测项目的路径，这样它才能读取到项目配置文件。在连续会话中，它会自动继承上下文的项目路径。
强烈推荐：
特别适合：
不太适合：
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 工具里直接说：
"/api-testdata-cleaner 清理数据库中重复的测试数据"
就可以开始用了。
小贴士：建议把它和 api-test-executor、api-report-generator 串起来用——通过
api-pipeline-scheduler一键编排「执行 → 清理 → 报告」全流程。
测试行业有个共识："Flaky Test 是自动化最大的敌人。"
而 Flaky Test 最大的源头，就是数据污染（占比 60% 以上）。
api-testdata-cleaner 解决的就是这个源头——让测试环境始终干净、可控、可复用。
它不会替代你的环境管理规范，不会替代你的数据隔离策略，更不会替代你对生产环境的敬畏。它只是把你从手动 DELETE、担心误删、反复重置环境的焦虑中解放出来，让你把精力聚焦在更有价值的事情上——测试策略优化、Flaky 根因深度分析、自动化体系持续改进。
需要强调的是：数据清理涉及生产安全，任何自动化能力都必须建立严格的保护机制。白名单、环境拦截、日志留痕——这三道防线，缺一不可。
而这，正是 AI 赋能测试的真正意义——不是替代人，而是让人更安心。
如果你也厌倦了每天手动清理测试数据，强烈推荐试试这款 skill。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。