写在开头
先问大家一个问题：接口测试跑完之后，你最头疼的是什么？
大概率是这样的——
几十条失败用例堆在面前，不知道从哪条看起；
翻日志，错误堆栈一大堆，看不出所以然；
判断是环境问题、数据问题、脚本问题还是产品缺陷，全靠个人经验；
好不容易定位了根因，还要手写代码修复；
修完不确定对不对，得重跑一遍验证；
下次接口一变更，同样的问题又来一遍；
失败用例没人盯、没人修，脚本越跑越烂；
最后整个团队对自动化报告"视而不见"……
行业统计，测试工程师平均花费 40%~60% 的时间在失败分析上——这恰恰是最该被 AI 接管的环节。
如果以上场景你中了三条以上，那么今天这款 skill，你一定要了解——api-failure-diagnoser，一款能让失败脚本"自己修好"的 Agent Skill。
一、它是什么？
api-failure-diagnoser 是接口自动化测试的失败智能诊断专家，该技能是失败分析的"智能大脑"，基于执行结果和日志，自动分类失败类型、定位根因、生成修复建议、自动修复。
它的核心定位同样——只做两件事：
失败诊断：自动分类失败类型（环境/数据/脚本/产品缺陷），定位脚本层面的根因；
自动修复：针对"脚本问题"类失败，自动生成修复补丁、应用、验证。
听起来像魔法？但它是真实存在的。
二、5 大核心亮点
① 分类自动诊断：不是所有失败都一样
这是它最核心的能力。
面对一堆失败用例，第一步不是急着修，而是先分类。
api-failure-diagnoser 会自动把失败分成四类：
失败类型 判定特征 处理方式
ENV_ERROR（环境问题） 连接超时、拒绝连接、502/503/504 ❌ 不修复，提示人工检查服务
DATA_ERROR（数据问题） 404、401/403、数据校验失败 ❌ 不修复，提示人工清理数据
SCRIPT_ERROR（脚本问题）⭐ 断言失败、接口路径 404、响应字段缺失、参数构造错误 ✅ 自动修复
BUG（产品缺陷） 500、业务逻辑错误、状态流转异常 ❌ 不修复，生成 Bug 报告
为什么要先分类？
因为不同类型的失败，处理方式完全不同：
环境问题 → 找运维
数据问题 → 清数据
脚本问题 → 改脚本（AI 能干）
产品缺陷 → 提 Bug
不分类就乱修，等于瞎忙。
② 只修该修的：明确的能力边界
这点是它最被低估的优势。
明确不做的事：
不做环境修复（服务宕机交给运维）
不做产品缺陷修复（Bug 交给开发）
不做复杂重构（架构级改动交给人工）
为什么不做？
因为一个试图修好所有的 AI，最终什么都会修不好。环境、产品缺陷——每一项都涉及不同的协作链路和权限边界，强行让一个 Skill 包揽，只会带来误操作和混乱。
api-failure-diagnoser 只聚焦"脚本问题"这一类，把这件事做到极致——这种克制反而让它更安全、更可靠、更值得信赖。
③ 7 种根因精准定位：不是笼统说"脚本错了"
针对 SCRIPT_ERROR，它还会进一步细分根因，给出具体的修复策略：
根因类型 典型特征 修复策略
接口变更 请求返回 404/405，响应字段缺失/新增 同步更新请求路径、参数、断言
断言过严 断言检查非核心字段（时间戳、随机 ID） 放宽断言条件，移除不稳定字段
定位失效 元素定位失败（XPath/CSS 失效） 更新定位策略
参数构造错误 参数类型错误、必填字段缺失 修正参数构造逻辑
异常处理缺失 未处理错误响应结构，导致 KeyError 补充异常分支处理
时序/异步问题 断言时响应尚未完成 补充显式等待、轮询
数据依赖错误 前置步骤未正确传递参数 修正参数传递逻辑
这意味着：它不是笼统告诉你"脚本错了"，而是精准告诉你"错在哪一行、该怎么改" 。
④ 5 条修复原则：安全可信赖
自动修复最怕的是什么？改坏了原本好的代码。
api-failure-diagnoser 用 5 条原则保证修复安全：
最小侵入：仅修改导致失败的最小代码范围，不改动无关逻辑；
规范一致：修复后的代码严格遵循团队编码规范；
可回滚：修复前自动备份原文件（.bak），支持一键回滚；
验证闭环：修复后自动重跑受影响用例，验证通过才确认修复成功；
人工确认：默认生成 .patch 文件，由人工审核后应用。
特别说明：默认是 --auto-fix=false，也就是先生成补丁让你审核，确认没问题再应用。这是对人工经验的尊重——AI 负责"初筛和提效"，人负责"把关和决策"。
⑤ 结构化输出：可追溯、可审计、可衔接
修复完成后，它会输出一套完整的"修复档案"：
- repair_report.md（诊断与修复报告）
人能直接读的修复报告，包含：
执行摘要（分析用例数、各类问题数量）
脚本问题详情（每个问题的根因、修复操作、修复前后对比、验证状态）
未修复问题（环境、数据、产品缺陷的处理建议）
2. 修复补丁文件（.patch）
当 --auto-fix=false 时生成，供人工审核后应用。
- 修复后的脚本文件
当 --auto-fix=true 时直接修改原文件，并保留 .bak 备份。
- bug_reports/ 目录
产品缺陷的详细 Bug 报告，建议提交给开发团队。
也就是说，每一次修复都有完整的档案可追溯——改了什么、为什么改、改完效果如何，全部留痕。这对团队协作和审计至关重要。
三、典型使用场景
场景一：日常失败排查
一轮测试跑完，面对几十条失败用例：
/api-failure-diagnoser 请诊断 shop-lab-api-test 项目本次执行中的失败用例，帮我看看，并修复一下失败的测试脚本
它会自动加载执行结果，分类失败、定位根因、给出修复方案——几分钟干完你半天的活。
场景二：接口变更后的批量修复
后端接口改了（路径变了、参数增减、响应结构调整），脚本批量失效：
/api-failure-diagnoser 请针对本次失败用例自动修复，并结合最新接口文档对比变更
它会自动识别"接口变更"根因，批量同步路径、参数、断言——不用你一条条手改。
场景三：数据污染问题修复
脚本里硬编码了用户名，第二次跑就因为账号重复失败：
/api-failure-diagnoser 请诊断并修复 test_register_success 这条失败用例
它会识别为"数据依赖错误"，给出修复方案（如动态生成用户名）——从根因上解决重复执行失败。
场景四：产品缺陷自动识别
有些失败不是脚本的问题，而是接口真的有 Bug。它会自动识别为 BUG 类型，生成完整的 Bug 报告，包含：
Bug ID、发现用例、接口路径
问题描述、期望结果、实际结果
优先级、复现步骤
直接可以提交给开发，省去你写 Bug 报告的时间。
场景五：接入 CI/CD 的自愈闭环
通过 Claude CLI 的非交互模式，可以实现"失败 → 诊断 → 修复 → 重跑"的自愈闭环：
claude -p “调用 api-failure-diagnoser 技能，参数: project_path=P R O J E C T P A T H , e x e c u t i o n r e s u l t s = {PROJECT_PATH}, execution_results=PROJECTPATH,executionresults={RESULTS_PATH}, auto-fix=true, verify=true”
–permission-mode bypassPermissions
–output-format json
–max-turns 30
让接口测试真正具备"自我修复"能力。
四、真实案例：从 25% 到 98.7% 的自愈爬坡
这是AI 进化社中一个非常典型的实战案例，完整展现了 api-failure-diagnoser 的自愈能力。
1、调用 api-test-executor 跑 P0 用例。
/api-test-executor 在 test 环境跑一下shop-lab-api-test 项目P0级测试用例
shop-lab-api-test项目路径为：/xxx/shop-lab-api-test
将提示词发送后，api-test-executor技能会先自主检测服务是否正常，然后根据执行要求过滤统计出了，当前项目共有八十多条P0级测试用例，覆盖了49个文件。
第一轮执行结果如下：
从上述执行结果可知，只有21条通过，通过率仅25%。（首轮P0级测试用例执行通过率只有 25%（21/83 通过））
2、首轮测试执行完成后，我们不用急于人工介入排查修复，直接调用api-failure-diagnoser 技能自动批量修复问题。
等待修复即可，需要注意不同的问题会采取不同的脚本修复策略。
