测试修复Skill（test-fixing）：用智能错误分组，把一堆失败测试按优先级逐个清零
- 一个技能解决一类麻烦事：当你运行测试套件看到满屏红灯、又不知道从哪下手时，这个技能会先跑一遍测试，把失败项分组，再按优先级一组一组修到通过。
- 核心方法是"先分组、后修复"：它按错误类型、模块文件和根本原因归并相似失败，避免同一类问题被反复修十遍。
- 修复顺序有讲究：先修基础设施类的 ImportError、缺失依赖和配置问题，再修接口签名变更，最后才处理断言与业务逻辑，每一步都用针对性测试验证。
- 有明确的收尾标准：所有分组修完后重跑完整测试套件，确认没有回归再收工。
- 适用人群广：重构后测试全崩的开发者、CI 一直飘红的团队、接手陌生项目要先让测试跑绿的新人，都能直接用。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
这个技能的中文名是测试修复Skill，英文名是 test-fixing，技能 ID 为 12115。它的定位非常明确：运行测试并修复所有失败的测试，使用智能错误分组策略，让"测试套件损坏"这件事从一场漫长的手工排查变成一条有条理的工作流。
它要解决的痛点很具体——不是"测试为什么重要"，而是测试已经失败了、而且失败得很多。当一个模块被重命名、一次函数签名变更、一个依赖没装好时，测试结果往往不是"失败 1 个"，而是"失败 15 个"，其中大量失败其实是同一个根因的不同表现。人工逐个点开报错、逐个改，效率极低；而盲目地一次性让 AI 大面积改代码，又容易引入新的破坏。这个技能提供的正是中间那条路：先诊断归类，再小步修复，逐组验证。
关于安装，需要说明的是：本文所依据的技能详情只描述了技能的能力与使用方法，未提供具体的安装命令、下载地址与收费信息，因此这里给出通用的接入思路，具体命令与入口请以官方说明为准。
一键安装 AI 技能的通用思路与步骤：
- 确认安装前提：你需要在支持 AI 技能（Skill）机制的客户端或插件环境中操作，通常是具备文件读写、命令执行能力的 AI 编程助手；同时确保本地项目已配置好可运行的测试环境（详情中默认使用
make test作为入口命令）。 - 进入技能市场或技能管理入口：在客户端内打开技能列表、插件市场或扩展管理页面，找到"添加技能/安装技能"的入口。
- 检索并安装：用中文名"测试修复"、英文名
test-fixing或技能 ID12115进行搜索，找到目标技能后点击安装或启用；具体命令行安装方式以官方说明为准。 - 确认技能已启用：安装完成后，在已安装技能列表中应能看到"测试修复 / test-fixing"处于启用状态。
- 验证是否生效：在对话中直接提出一个与该技能触发描述一致的需求，例如"帮我修复这些失败的测试"或"测试套件损坏了，让它跑通"。如果技能被正确唤醒，它应该先执行
make test并分析输出，而不是直接开始改代码——这就是它生效的标志。
该技能的主要功能和特点
- 自动触发识别：当用户明确要求"修复测试"“使测试通过”、报告"测试失败"“测试套件损坏”、完成实现后希望测试通过，或提到 CI/CD 因测试而失败时，该技能即进入工作状态，无需用户记住复杂指令。
- 初始测试全量摸底：第一步永远先运行
make test，统计失败总数、归纳错误类型与模式、标出受影响的模块与文件，形成一份"失败地图"。 - 智能错误分组：这是它区别于普通"AI 修 bug"的核心能力。它按三个维度归并失败——错误类型（ImportError、AttributeError、AssertionError 等）、模块/文件（同一文件导致多个测试失败的归为一组）、根本原因（缺失依赖、API 变更、重构影响）。
- 按影响面与依赖顺序排优先级：分组后先处理受影响测试数量最多的组，并优先修复基础设施类问题，因为基础设施不修好，后面的功能级修复往往是在错误的地基上打补丁。
- 小步修复 + 逐组验证：每修完一组，立即用测试子集验证，组不通过绝不进入下一组，从而把"改崩了不知道哪一步崩的"风险控制在最小范围。
- 遵循项目自身约定：修复时会参考项目约定（详情中以
CLAUDE.md为例），并使用编辑工具做最小化、有针对性的改动，而不是大范围重写。 - 善用版本差异定位根因：通过
git diff检查最近更改，快速判断失败是否由某次重构或提交引入。 - 收尾有验收动作：全部组修完后重跑完整套件
make test，并检查测试覆盖率保持不变，确保没有"把测试删掉换来变绿"的情况。
和普通工具相比，它强在方法论：普通做法是"运行测试 → 看到红色 → 逐个手动查"，或者"让 AI 一次性全改"，而它把过程拆成了可验证的批次，兼顾了效率与安全。
如何使用该技能？
使用方式覆盖"直接下达修复指令"和"按流程手动推进"两种形态。以下是推荐的分步骤用法。
步骤 1：明确表达需求，触发技能
不需要复杂话术，用自然语言说出当前状况即可，例如：
- “重构之后测试全挂了，帮我修复测试”
- “CI 因为这个失败一直不通过，使测试通过”
- “我刚完成实现，跑一下测试并把失败的都修掉”
步骤 2：执行初始测试运行，形成失败清单
技能会运行：
make test
然后分析输出中的失败总数、错误类型与模式、受影响模块/文件。输入说明：无需额外传参，依赖项目既有的 make test 目标。输出说明：一份按错误类型和模块归类的失败概览。
步骤 3：审阅智能分组结果
你应当看到类似这样的分组（示例取自技能的典型工作流）：
- 8 个 ImportError —— 原因是模块重命名
- 5 个 AttributeError —— 原因是函数签名更改
- 2 个 AssertionError —— 原因是逻辑错误
分组的意义在于：把 15 个"失败"还原成 3 个"根因"。
步骤 4：按优先级逐组修复
对每一组（从影响最大的开始），技能会依次做三件事：阅读相关代码并用 git diff 定位最近更改；用编辑工具进行最小化修改；运行该组的测试子集验证。
步骤 5：用测试子集验证单组修复
详情中给出了两种精确验证方式：
uv run pytest tests/path/to/test_file.py -v
uv run pytest -k "pattern" -v
前者按文件路径跑，后者按名称模式筛选。输入示例：uv run pytest -k "import" -v 用于验证导入相关修复。输出说明：该组测试通过后，方可进入下一组。
步骤 6：遵循修复顺序策略
- 基础设施优先：导入错误、缺失依赖项、配置问题
- 然后是 API 更改：函数签名更改、模块重组、变量/函数重命名
- 最后是逻辑问题：断言失败、业务逻辑错误、边缘情况处理
步骤 7：最终验证与回归检查
全部组修复完成后，重新运行完整测试套件：
make test
确认全部通过、无回归、测试覆盖率保持不变。到这里，一次完整的修复闭环才算结束。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 测试修复Skill（test-fixing） | AI 技能：系统性修复失败测试 | 全量摸底、智能错误分组、按优先级逐组修复、逐组验证、最终回归检查 | 需在支持 Skill 的 AI 客户端中安装启用，项目需具备可运行的测试入口（如 make test）；具体安装方式以官方说明为准 |
重构后大面积失败、CI 持续飘红、接手陌生项目需要先跑绿 | 优势是方法论完整、修复顺序科学、每步可验证；不足是强依赖项目已有测试与 make test 目标，测试本身缺失时无法发挥 |
| pytest 手动排查 | 原生测试框架 + 人工分析 | 运行测试、输出报错栈、支持 -k/文件路径筛选 |
零安装成本（框架已在项目中），但完全依赖人工经验 | 失败数量少、根因单一的小问题 | 优势是可控、无额外依赖；不足是失败多时逐个排查耗时极长，且容易漏掉共性根因 |
| CI 自动重试机制 | 流水线层面的稳定性兜底 | 失败作业自动重跑、失败通知 | 需在 CI 平台配置 | 偶发性的不稳定测试（flaky test） | 优势是配置简单、能过滤抖动；不足是对真实的代码级失败毫无帮助，重跑多少次还是红 |
| 通用 AI 编程助手（对话式改代码） | 通用代码生成与修改 | 读代码、改代码、解释报错 | 使用门槛低，直接对话即可 | 单个明确报错的定点修复 | 优势是灵活、上手快；不足是缺少"分组—排序—逐组验证"的结构化流程，容易一次改太多、难以定位是哪次修改引入的新问题 |
| 静态检查/自动修复工具 | 代码规范层面的自动修正 | 格式修复、部分可自动修的 lint 问题 | 通常一条命令即可运行 | 风格问题、明显的静态缺陷 | 优势是速度快、误改风险低；不足是覆盖不到断言失败与业务逻辑错误，无法替代测试修复 |
从表中可以看出：重试机制治的是抖动，静态工具治的是风格，手动排查治的是少量问题，通用助手治的是单点，而这个技能治的是"成片失败"——它们的边界并不冲突，反而可以组合使用。
该技能的典型应用场景与实际体验情况
场景一：大规模重构后的"测试雪崩"
后端开发者把某个工具模块改了名、合并了几个文件，一跑测试发现 15 个用例全红。痛点是报错信息看起来五花八门，逐个点开要花掉半天。使用方式：直接说"重构后测试失败"，技能会先 make test 摸底，然后归出"8 个 ImportError / 5 个 AttributeError / 2 个 AssertionError"这样的结构，先处理导入问题。体验情况：上手难度低，最大的价值不是"会改代码"，而是给出了动手的先后顺序——如果先去改那 2 个断言失败，很可能改完发现导入都修好后它们自己就好了。
场景二：CI/CD 流水线持续失败，发布被卡
团队负责人的痛点是流水线一直红，但本地跑有时又正常，沟通成本极高。使用方式：把 CI 失败日志贴给技能，或让它按 make test 复现，先判断是环境与依赖问题（基础设施优先）还是真实逻辑回归。体验情况：效果取决于失败能否在本地复现；如果是纯环境差异，技能会把它归到"配置问题/缺失依赖"这一组，指向性很强。注意事项是：CI 环境相关的失败，仍需要人工确认依赖版本是否一致。
场景三：接手陌生项目，先让测试跑绿
新入职或接手遗留项目的开发者，面对一仓库不熟悉的老代码，想先建立信心。使用方式：让它跑一遍完整套件，把失败分组，从模块最集中的那一组开始修。体验情况：这类项目往往失败数量大但根因少（常见是依赖没装齐、配置缺失），基础设施优先策略收益很高。注意事项：需要给技能提供项目约定文档（详情中提到参考 CLAUDE.md），否则修改风格可能与团队规范不符。
场景四：功能开发完成后的自检收尾
开发者写完新功能，主观上觉得"应该没问题"。使用方式：一句"我完成了实现，跑测试并修到通过"。体验情况：这一场景的修复量通常最小，收益体现在逐组验证 + 最终回归两道关卡上，能避免"新功能通过、老功能被顺手改坏"的情况。
整体体验小结：上手难度低（自然语言触发即可），效果最显著的是"失败数量多但根因集中"的情形；最需要注意的两点是——必须有可运行的测试入口，以及严格遵守"一组不通过不进入下一组"的纪律，否则会退化成普通的盲目改代码。
该技能能为用户带来的价值
第一，把"修测试"从体力活变成流程活。 面对成片失败，最大的成本从来不是改那几行代码，而是"不知道从哪开始、改完不知道对不对"。技能用"摸底 → 分组 → 排序 → 逐组修 → 逐组验 → 全量回归"六步把不确定性压到最低，让每一次修改都有明确的验证点。
第二，用分组大幅减少重复劳动。 15 个失败归并成 3 个根因，意味着实际要处理的问题从 15 个变成 3 个——效率提升不是线性的，而是随失败数量增长被放大的。对于失败集中、根因单一的典型重构场景，这是最直接的收益来源。
第三，降低修复风险与回归概率。 “最小化、有针对性的更改”+“组不通过不进入下一组”+"最终检查覆盖率保持不变"这三条约束，直接对冲了 AI 改代码最常见的两个风险：改得太多、以及把测试删掉换取变绿。
第四，降低了新人和跨模块协作的门槛。 不熟悉代码库的人也能借助"先基础设施、再 API、后逻辑"的顺序获得一条清晰的排查路径，不必依赖资深同事的经验传承。
长期价值在于习惯养成：团队可以把这个工作流沉淀为"测试红了之后的标准动作"，让 CI 红灯不再是一件需要开会讨论的事。
常见问题 FAQ
Q1：这个技能怎么安装？会不会很难配？
在支持 AI 技能机制的客户端中，通过技能市场或扩展入口搜索"测试修复"、test-fixing 或技能 ID 12115 即可安装启用，具体命令与入口请以官方说明为准。使用时不需要额外传参，技能默认以项目的 make test 作为测试入口，因此唯一的前置条件是项目本身有可运行的测试命令。
Q2：这个技能收费吗？
本文依据的技能详情未包含任何定价信息，是否收费取决于所在客户端或平台的商业规则，请以官方说明为准。建议安装前先查看平台的价格页与试用政策。
Q3：它适合谁用？前端项目、Python 项目都能用吗？
最适合的人群是：刚完成重构需要收尾的开发者、被 CI 红灯卡住的团队、接手陌生项目的新人。从技能详情看，其示例命令使用的是 make test 与 uv run pytest（含 -v、-k 模式筛选），说明默认面向使用 pytest 的 Python 项目；但由于核心方法是"分组 + 排序 + 逐组验证"，只要项目存在等价的测试入口命令，这套方法论同样可以参考借鉴，具体适配情况以实际使用为准。
Q4：它会不会为了"让测试通过"而乱改测试或者删掉测试？
从技能的约束设计看，它在最终验证阶段会检查测试覆盖率保持不变，并以"最小化、有针对性的更改"为原则，这本身就是对"删测试换绿"的防线。不过要提醒：任何自动化修复都需要人来审核改动，尤其是涉及断言修改的部分，建议你在每组修复后扫一眼 git diff 再放行。
Q5：和直接用通用 AI 助手改代码、或者让 CI 自动重跑相比，该怎么选？
如果只是单个报错、根因明确，通用 AI 助手更快；如果是偶发抖动的测试，CI 重试就够了；但如果是一次提交导致成片失败，请用这个技能——它的不可替代之处在于"智能错误分组 + 按影响面与依赖顺序排序 + 逐组验证"，这是通用助手和重试机制都不提供的能力。实践中三者可以叠加：先用技能把真实失败清零，再让 CI 重试兜住剩余抖动。