Menu
当需要自动化测试-修复闭环、持续验证直到通过时使用
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | supervisor-fix |
| description | 当需要自动化测试-修复闭环、持续验证直到通过时使用 |
作为测试-修复循环的自动化调度器，协调测试agent验证指定功能，当发现问题时调用技术骨干分析根因后交由开发专员修复，持续循环直到所有测试通过或达到最大重试次数。
核心原则遵循
skills/shared/PRINCIPLES.md。规范先行 + Agent 自修复 + 四重验证，防止 Agent “绕过”问题。
| 参数 | 默认值 | 说明 |
|---|---|---|
| maxIterations | 5 | 最大修复迭代次数 |
| testTimeout | 300s | 单次测试超时时间 |
| fixTimeout | 600s | 单次修复超时时间 |
| failureThreshold | 3 | 连续失败数增加则触发熔断 |
| enableStaticCheck | true | 是否启用静态检测前置 |
| enableWorkaroundDetection | true | 是否启用 Workaround 检测 |
遵循
skills/command-executor/SKILL.md。循环开始前检测 OS，测试命令带 timeout，服务器后台启动，禁止 --watch。命令超时重试1次，仍超时则触发熔断上报用户。
| 状态 | 含义 | 后续动作 |
|---|---|---|
| pending | 等待开始 | 开始静态检测 |
| static_checking | 正在执行静态检测 | 等待检测完成 |
| testing | 正在执行动态测试 | 等待测试完成 |
| validating | 正在执行四重验证 | 等待验证完成 |
| fixing | 正在修复问题 | 等待修复完成 |
| passed | 四重验证全部通过 | 结束循环，报告成功 |
| max_iterations_reached | 达到最大迭代仍失败 | 结束循环，报告失败 |
| loop_detected | 检测到死循环 | 结束循环，报告失败 |
| aborted | 用户中止 | 清理资源 |
| failed | 发生异常 | 上报用户决策 |
| 级别 | 含义 | 处理优先级 |
|---|---|---|
| P0 (CRITICAL) | 阻塞执行，致命问题 | 最高，必须首先修复 |
| P1 (HIGH) | 影响质量，严重问题 | 高，应该修复 |
| P2 (MEDIUM) | 建议改进，一般问题 | 中，可选修复 |
| P3 (LOW) | 轻微问题，体验优化 | 低，可延后 |
在执行实际测试前，先进行静态分析，覆盖以下问题类型：
| 类型 | 代码 | 检测内容 |
|---|---|---|
| 运行时 | RT | 语法错误、导入错误、权限问题 |
| 结构 | ST | 缺失文件、缺失字段、缺失目录 |
| 格式 | FT | 命名不规范、编号错误 |
| 逻辑 | LG | 引用不存在、循环依赖 |
| 缺陷 | BG | 路径写死、变量未定义 |
| 索引 | IX | 链接失效、索引过时 |
| 接口契约 | IC | 脚本与配置不匹配 |
通过实际执行测试，检测运行时问题：
| 类型 | 代码 | 检测内容 |
|---|---|---|
| 启动失败 | DY-01 | 服务无法启动 |
| 权限错误 | DY-02 | 文件/API权限不足 |
| 输出缺失 | DY-03 | 预期输出未生成 |
| 输出无效 | DY-04 | 输出内容为空或格式错误 |
| 超时 | DY-05 | 执行时间超过阈值 |
| 异常退出 | DY-06 | 进程非正常退出 |
| 断言失败 | DY-07 | 测试断言不通过 |
| Workaround模式 | DY-08 | Agent绕过脚本错误 |
| 资源泄漏 | DY-09 | 未正确释放资源 |
| 数据流断裂 | DY-10 | 上游输出未被下游消费 |
| 状态不一致 | DY-11 | 状态与预期不符 |
核心原则：测试通过 ≠ 修复成功，必须同时满足以下 4 个条件：
┌────────────────────────────────────────────────────────────┐
│ 四重验证 │
├────────────────────────────────────────────────────────────┤
│ ✅ 1. Issues 清零 → 所有检测到的问题已修复 │
│ ✅ 2. Output 完整 → 预期文件全部生成且内容有效 │
│ ✅ 3. Dataflow 畅通 → 数据从上游正确流转到下游 │
│ ✅ 4. Workarounds 归零 → 没有任何"绕过"行为 │
└────────────────────────────────────────────────────────────┘
│
▼
四项全部通过 → 修复成功
任一项失败 → 继续修复循环
这是防止 Agent "假修复"的关键验证
检测以下 Workaround 模式：
当脚本/测试执行失败时，Agent 可能会"绕过"问题而非真正修复：
| 模式 | 检测方法 | 示例 |
|---|---|---|
| 空文件创建 | 检查文件大小和内容有效性 | 脚本崩溃后创建空的 output.json |
| 硬编码绕过 | 检查是否新增了魔法值/硬编码 | 返回固定值而非计算结果 |
| 测试注释 | 检查是否注释/删除了测试用例 | // test.skip(...) |
| 空异常处理 | 检查 catch 块是否有实际处理 | catch(e) {} |
| 路径替换 | 检查是否修改了输出路径而非修复逻辑 | 把输出写到临时目录 |
| 降级处理 | 检查是否返回默认值而非修复逻辑 | 失败时返回 [] 而非报错 |
1. 标记为 DY-08 (Workaround模式)
2. 严重级别: P0 (CRITICAL)
3. 要求开发专员修复根因，而非绕过
4. 在报告中高亮显示 Workaround 行为
每个发现的问题应包含：
## ISSUE-{编号}
- **检测阶段**: STATIC | DYNAMIC
- **问题类型**: RT | ST | FT | LG | BG | IX | IC | DY-01~11
- **严重级别**: P0 | P1 | P2 | P3
- **标题**: {问题简述}
- **位置**: {文件路径:行号}
- **错误信息**: {详细错误}
- **预期值**: {如适用}
- **实际值**: {如适用}
- **是否 Workaround**: YES | NO
- **修复建议**: {具体修复方向}
当AI助手使用此skill时，需要承担测试流程管理的责任：
首次测试某功能时：
/项目根目录/docs/测试流程/{功能名}.md）后续测试相同功能时：
docs/ 文件夹）每次执行完成后，AI助手应在报告中包含：
开始 → 解析目标 → 查找流程
│ │
├─找到流程─────→使用流程─→根因分析─→静态检测─→动态检测─→四重验证
│ │ │ │ │ │
└─未找到流程──→创建流程─┘ │ │ │
│ │ │
┌──────────────┘ │ │
▼ │ │
修复阶段←─────验证失败───────┘ │
│ │
└───────────验证通过────────────┘
│
▼
结束循环
| 事件 | 触发时机 | 携带数据 |
|---|---|---|
| loop:start | 循环开始 | state |
| loop:iteration | 每轮迭代开始 | iteration, state |
| loop:static_check | 静态检测完成 | staticIssues, state |
| loop:dynamic_check | 动态检测完成 | dynamicIssues, state |
| loop:validate | 四重验证完成 | validation, state |
| loop:fix | 开始修复 | iteration, issues, state |
| loop:approved | 四重验证通过 | state |
| loop:max_reached | 达到最大迭代 | state |
| loop:loop_detected | 检测到死循环 | state, previousIssues |
| loop:complete | 循环结束 | finalState |
| loop:error | 发生错误 | error, state |
为防止对抗循环无限进行，系统设计了以下退出策略：
| 退出类型 | 条件 | 处理 |
|---|---|---|
| 正常退出 | 四重验证全部通过 | 输出成功报告 |
| 达到上限退出 | 运行 N 轮未修好 | 输出报告供人工判断 |
| 无法修复退出 | 遇到无解问题（如依赖不存在的 API） | 立即报告 |
| 循环检测退出 | 连续两轮的问题列表完全相同 | 说明陷入死循环，及时止损 |
1. 每轮修复后，记录当前的问题列表 (issues)
2. 比较当前问题列表与上一轮的问题列表 (previousIssues)
3. 如果完全相同（问题ID、类型、位置均一致），则判定为死循环
4. 触发 loop:loop_detected 事件，立即退出循环
5. 在报告中说明死循环原因，建议人工介入
## 循环状态
- **ID**: {uuid}
- **测试目标**: {target}
- **当前迭代**: {iteration} / {maxIterations}
- **状态**: pending | static_checking | testing | validating | fixing | passed | max_iterations_reached | loop_detected | failed
- **开始时间**: {startedAt}
- **完成时间**: {completedAt}
## 四重验证状态
| 验证项 | 状态 | 详情 |
|--------|------|------|
| Issues清零 | ✅/❌ | {P0:n, P1:n, P2:n, P3:n} |
| Output完整 | ✅/❌ | {已生成/预期} |
| Dataflow畅通 | ✅/❌ | {检查点列表} |
| Workarounds归零 | ✅/❌ | {发现数量} |
## 迭代历史
| 迭代 | 静态检测 | 动态检测 | 四重验证 | 问题列表 | 修复摘要 |
|------|----------|----------|----------|----------|----------|
| 1 | 2 issues | 3 issues | ❌❌✅❌ | ISSUE-1,2,3,4,5 | 修复了xxx |
| 2 | 0 issues | 1 issue | ❌✅✅❌ | ISSUE-6 | 修复了yyy |
| 3 | 0 issues | 0 issues | ✅✅✅✅ | - | - |
## 累计问题
{所有发现的问题列表}
## Workaround 记录
{所有检测到的 Workaround 行为}
## 熔断报告 ⚠️
### 熔断原因
{具体触发条件}
### 当前状态
- 迭代次数: {n}
- 失败趋势: {递增/递减/波动/死循环}
- 最后一轮失败数: {count}
- 四重验证状态: {详情}
### 问题分析
- 可能存在架构层面的问题
- 修复方向可能不正确
- 建议人工介入分析根因
### Workaround 检测结果
{是否检测到绕过行为，如有则列出}
### 建议动作
1. 检查测试用例是否合理
2. 检查修复策略是否正确
3. 考虑是否需要重构
4. 检查是否存在循环依赖
task({
subagent_name: "测试专员",
description: "执行静态检测",
prompt: "对以下目标执行静态检测：{测试目标}
## 检测要求
1. 检查语法错误、导入错误（RT）
2. 检查缺失文件/字段/目录（ST）
3. 检查命名规范（FT）
4. 检查引用和依赖（LG）
5. 检查硬编码和未定义变量（BG）
6. 检查链接和索引（IX）
7. 检查接口契约匹配（IC）
## 返回格式
### 静态检测摘要
- 总问题数: {total}
- P0: {n}, P1: {n}, P2: {n}, P3: {n}
### 问题详情
对每个问题按 ISSUE 格式返回"
})
task({
subagent_name: "测试专员",
description: "执行动态测试",
prompt: "执行以下测试并返回详细结果：{测试目标}
## 测试要求
1. 运行完整测试套件
2. 收集所有失败测试的详细信息
3. **检测 Workaround 行为**（DY-08）
4. **检测数据流断裂**（DY-10）
## Workaround 检测
注意观察是否有以下行为：
- 脚本报错后创建空文件
- 跳过失败步骤
- 注释测试用例
- 硬编码绕过
## 返回格式
### 测试摘要
- 执行命令: {command}
- 总测试数: {total}
- 通过: {passed}
- 失败: {failed}
- 跳过: {skipped}
### 失败详情（如有）
对每个失败测试按 ISSUE 格式返回
### Workaround 检测结果
{是否发现绕过行为}"
})
task({
subagent_name: "开发专员",
description: "按根因分析修复测试失败",
prompt: "按技术骨干的根因分析修复以下测试失败：
## 失败测试列表
{按严重级别排序的问题列表}
## 问题详情
{每个问题的完整信息}
## 根因分析结果
{技术骨干提供的根因分析和修复建议}
## 修复要求
1. 严格按根因分析结果修复，不要自行发挥
2. 按严重级别优先修复 P0 > P1 > P2 > P3
3. 确保修复不破坏其他测试
4. 对每个修复说明改动内容
5. **严禁使用 Workaround 绕过问题**：
- 不要创建空文件或假数据
- 不要注释或跳过测试
- 不要用硬编码替代逻辑
- 不要用空 catch 吞异常
## 返回格式
### 修复摘要
- 修复问题数: {n}
- 改动文件: {files}
### 修复详情
对每个修复的问题：
- 问题ID
- 修复方式
- 改动说明"
})
## 测试-修复循环完成 ✅
### 最终状态
- **结论**: PASSED
- **总迭代次数**: {n}
- **总耗时**: {duration}
- **开始时间**: {startedAt}
- **完成时间**: {completedAt}
### 四重验证结果
| 验证项 | 状态 |
|--------|------|
| Issues清零 | ✅ |
| Output完整 | ✅ |
| Dataflow畅通 | ✅ |
| Workarounds归零 | ✅ |
### 迭代历史
| 迭代 | 静态 | 动态 | 四重验证 | 修复内容 |
|------|------|------|----------|----------|
| 1 | 2 | 3 | ❌❌✅❌ | 修复了输入验证 |
| 2 | 0 | 1 | ❌✅✅❌ | 修复了边界条件 |
| 3 | 0 | 0 | ✅✅✅✅ | - |
### 问题修复摘要
共发现 {total} 个问题，已全部修复：
- P0 (CRITICAL): {n} 个
- P1 (HIGH): {n} 个
- P2 (MEDIUM): {n} 个
- P3 (LOW): {n} 个
### 修复详情
| 问题ID | 严重级别 | 标题 | 修复方式 |
|--------|----------|------|----------|
| ISSUE-1 | P1 | 空指针异常 | 添加空值检查 |
| ISSUE-2 | P2 | 类型错误 | 修正类型定义 |
## 测试-修复循环完成 ❌
### 最终状态
- **结论**: FAILED ({失败原因})
- **总迭代次数**: {n}
- **总耗时**: {duration}
### 四重验证结果
| 验证项 | 状态 | 详情 |
|--------|------|------|
| Issues清零 | ❌ | 仍有 {n} 个问题 |
| Output完整 | ✅ | - |
| Dataflow畅通 | ✅ | - |
| Workarounds归零 | ❌ | 发现 {n} 处绕过 |
### 迭代历史
| 迭代 | 静态 | 动态 | 四重验证 | 修复内容 |
|------|------|------|----------|----------|
| ... | ... | ... | ... | ... |
### 仍然失败的测试
| 问题ID | 严重级别 | 标题 | 错误信息 |
|--------|----------|------|----------|
| ISSUE-5 | P1 | 异步竞态 | Promise rejection |
| ISSUE-6 | P2 | 状态不一致 | State mismatch |
### Workaround 检测结果 ⚠️
{如有发现，列出所有绕过行为}
### 失败分析
- 问题可能涉及架构设计
- 自动修复无法解决的原因分析
- 建议的人工排查方向
### 建议动作
1. 检查异步处理逻辑
2. 审查状态管理设计
3. 考虑增加集成测试覆盖
4. 检查是否存在循环依赖
## 测试-修复循环完成 🔄
### 最终状态
- **结论**: LOOP_DETECTED (检测到死循环)
- **总迭代次数**: {n}
- **总耗时**: {duration}
### 死循环详情
- **触发条件**: 连续两轮问题列表完全相同
- **重复的问题**:
| 问题ID | 类型 | 标题 |
|--------|------|------|
| ISSUE-X | DY-07 | ... |
| ISSUE-Y | BG | ... |
### 原因分析
- Agent 可能在相同的修复策略上反复尝试
- 问题的根因可能超出自动修复能力
- 可能存在测试用例与实现的逻辑冲突
### 建议动作
1. 人工分析重复问题的根因
2. 检查修复策略是否正确
3. 考虑是否需要架构调整
1. 检查测试命令是否正确
2. 检查测试环境是否就绪
3. 重试一次（最多1次）
4. 仍失败则:
- emit('loop:error', {type: 'test_execution_failed', ...})
- 上报用户，等待决策
1. 检查错误信息是否完整
2. 补充上下文后重试
3. 仍失败则:
- 标记问题为 "需人工介入"
- 继续处理其他可修复问题
- 在报告中高亮显示
1. 立即标记为 P0 问题
2. 在下一轮修复中优先处理
3. 明确告知开发专员不接受绕过
4. 如连续出现 Workaround，触发熔断
1. 记录本轮新增的失败测试
2. 检查熔断条件
3. 未触发熔断:
- 在下一轮修复时一并处理新问题
4. 触发熔断:
- 停止循环
- 输出熔断报告
- 上报用户
用户: 测试用户登录功能并自动修复问题
supervisor-fix 执行:
1. emit('loop:start')
2. 静态检测: 发现 IC-01 (配置缺失字段)
3. 调用开发专员修复静态问题
4. 动态测试: 发现 2 个失败
- ISSUE-1 [P1] 空密码未校验
- ISSUE-2 [P2] 错误提示不准确
5. 四重验证: Issues未清零, Workarounds=0
6. 调用开发专员修复动态问题
7. 再次四重验证: 全部通过
8. emit('loop:approved')
9. emit('loop:complete')
用户: 运行测试并修复
supervisor-fix 执行:
1. 第1轮: 动态测试失败 (脚本崩溃)
2. 调用开发专员修复
3. 第2轮: 动态测试"通过"，但四重验证发现:
- Output: 文件存在但内容为空 ❌
- Workaround: 检测到 Agent 创建了空文件 ❌
4. 标记 DY-08，要求开发专员修复根因
5. 第3轮: 四重验证全部通过 ✅
用户: 修复类型错误
supervisor-fix 执行:
1. 第1轮: 发现 ISSUE-1 [P1] 类型不兼容
2. 开发专员修复: 添加类型转换
3. 第2轮: 仍然是 ISSUE-1 [P1] 类型不兼容
4. 问题列表与上轮完全相同 → 死循环检测触发
5. emit('loop:loop_detected')
6. 输出死循环报告，建议人工介入
每次测试-修复循环结束（无论成功或失败）时，必须进行复盘。
结构见 skills/templates/通用模板.md 之「复盘报告通用结构」。必填内容如下：
## supervisor-fix 复盘报告
### 执行概况
- **测试目标**: {目标描述}
- **最终状态**: {PASSED/FAILED/MAX_REACHED/LOOP_DETECTED}
- **总迭代次数**: {n}
- **总耗时**: {duration}
- **收敛趋势**: {改善/恶化/波动}
### 问题统计分析
- **发现问题总数**: {n}
- **按严重级别**: P0={n}, P1={n}, P2={n}, P3={n}
- **按类型分布**: {RT/ST/FT/LG/BG/IX/IC/DY-01~11}
- **Workaround检测**: {发现次数}
### 修复效果分析
- **修复成功率**: {修复数/发现问题数}
- **引入新问题数**: {n}
- **修复后复发数**: {n}
- **平均修复轮次**: {总轮次/解决问题数}
### 四重验证分析
| 验证项 | 结果 | 耗时 | 问题 |
|--------|------|------|------|
| Issues清零 | ✅/❌ | {时间} | {具体问题} |
| Output完整 | ✅/❌ | {时间} | {具体问题} |
| Dataflow畅通 | ✅/❌ | {时间} | {具体问题} |
| Workarounds归零 | ✅/❌ | {时间} | {具体问题} |
### Skill协作评估
- **技术骨干分析质量**: {根因准确性、建议可用性}
- **开发专员修复效果**: {一次修复成功率、Workaround倾向}
- **测试Agent检测精度**: {漏报率、误报率}
- **调度策略有效性**: {循环次数、收敛速度}
### 改进建议
#### 对现有流程的优化
1. **静态检测优化**:
- 问题: {观察到的不足}
- 建议: {具体改进}
2. **根因分析优化**:
- 问题: {技术骨干分析的盲点}
- 建议: {分析方法的改进}
3. **修复策略优化**:
- 问题: {修复效果不佳的环节}
- 建议: {修复流程的调整}
#### 对Skill的改进建议
1. **技术骨干**:
- 建议增强: {排查方法的某个方面}
- 建议新增: {某种分析工具或方法}
2. **开发专员**:
- 建议改进: {修复质量的某个方面}
- 建议避免: {常见的Workaround模式}
3. **supervisor-fix自身**:
- 建议调整: {参数配置、流程步骤}
- 建议新增: {某种检测或验证机制}
#### 新增能力建议
- **预防性措施**: {如何提前避免同类问题}
- **快速通道**: {针对特定问题类型的专用流程}
- **学习机制**: {如何从成功案例中学习}
复盘报告输出到 .vibe/docs/supervisor-fix复盘-{日期}.md，并更新：
.vibe/docs/修复模式库.md - 记录有效的修复策略.vibe/docs/问题模式库.md - 记录常见问题及对策