Menü
当需要自动化测试-修复闭环、持续验证直到通过时使用
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 - 记录常见问题及对策