批量技能冒烟测试的调度与执行方法

批量技能冒烟测试的调度与执行方法

一次真实的批量技能测试协作复盘

"You are running the P0 skill smoke test queue for jianfei-ceo. / Task: Run smoke tests for high-frequency jianfei-* skills. Check each skill's SKILL.md for test commands or verification steps, and run what's available."

这是一个真实的协作场景：用户通过一段 prompt，让 AI 助手执行一批技能的冒烟测试。表面上这是一个简单的测试任务，背后却藏着一套完整的工作方法——如何设计测试队列、如何确认测试结果、如何在批量场景中保持执行质量。

卡点：从一句话到执行队列

用户的原始 prompt 很短，但信息密度很高：

1. 指定了测试范围：P0 优先级 + jianfei-ceo 相关技能
2. 指定了测试对象：高频 jianfei-* 技能（通配符匹配）
3. 指定了测试方法：检查每个技能的 SKILL.md 中是否有测试命令或验证步骤
4. 指定了执行策略：运行可用的测试

这里的关键判断是：用户没有让 Agent 盲目执行，而是要求 Agent 先"检查 SKILL.md 中的测试命令"——这意味着测试的定义是分散在各个技能文件中的，Agent 需要具备"读取—解析—执行"的链式能力。

工作方法：如何设计测试队列

从这个场景可以抽象出批量技能冒烟测试的通用设计方法：

1. 优先级分层（P0/P1/P2）

不是所有技能都需要同等频率的测试。P0 是核心技能，失败会阻塞主流程；P1 是重要但不阻塞的技能；P2 是低频或边缘技能。冒烟测试队列应该优先覆盖 P0，再逐步向下扩展。

在这个场景中，用户明确指定了"P0 skill smoke test queue"，说明已经完成了优先级分层。这是批量测试的第一个关键设计决策。

2. 通配符匹配与动态发现

用户使用了"jianfei-* skills"这样的通配符来表达测试范围。这背后的工作方法是：技能的命名应该具备可匹配性，通过前缀或标签来分组。这样，当需要批量测试时，可以用通配符快速确定测试集合，而不需要手动列举每个技能。

Agent 的执行链应该是：

• 扫描技能目录，匹配"jianfei-*"模式
• 过滤出高频技能（可以通过调用频率或手动标记）
• 生成测试队列

3. 测试命令的自我描述

这是一个巧妙的设计：测试命令不是写在外部配置文件中，而是嵌入在每个技能的 SKILL.md 里。这样做的好处是：

• 测试与技能定义共存：当技能逻辑变更时，测试命令也在同一个文件里，更容易保持同步
• 自包含的可执行文档：任何拿到 SKILL.md 的人或 Agent，都能知道如何验证这个技能是否正常工作
• 降低维护成本：不需要额外的测试配置管理

Agent 需要做的事情是：读取 SKILL.md，解析出其中的测试命令（通常会在"Testing"、"Verification"或"Quick Start"章节），然后执行。

如何确认测试结果

批量测试的最大挑战不是执行，而是结果确认。当同时运行几十个技能的冒烟测试时，如何快速判断"哪些通过了、哪些失败了、失败的原因是什么"？

从这个协作场景中，可以提炼出以下结果确认方法：

1. 结构化输出

Agent 不应该只返回"测试完成"这样模糊的信息，而应该输出结构化的测试结果，例如：

## Smoke Test Results (P0 jianfei-* skills)

| Skill | Status | Details |
|-------|--------|---------|
| jianfei-ceo | ✅ PASS | All verification steps passed |
| jianfei-plan | ✅ PASS | 3/3 test commands succeeded |
| jianfei-pc | ⚠️ PARTIAL | Step 2 failed: timeout after 30s |
| jianfei-codex | ❌ FAIL | SKILL.md missing test commands |

2. 失败分类

不是所有失败都一样。需要区分：

• 环境问题：技能本身没问题，但运行环境缺少依赖（如未安装 ffmpeg）
• 配置问题：技能需要 API Key 或配置文件，但当前缺失
• 逻辑问题：技能的执行逻辑有 bug，需要修复
• 文档问题：SKILL.md 缺少测试命令，需要补充

在这个场景中，如果 Agent 发现某个 jianfei-* 技能的 SKILL.md 里没有测试命令，这属于"文档问题"，应该在结果中标注，并建议补充。

3. 冒烟测试的"冒烟"标准

冒烟测试不是完整测试，它只验证"最核心的功能是否能跑通"。因此，结果确认时应该关注：

• 快速反馈：每个技能的测试应该在几秒到几十秒内完成，不应该跑完整的测试套件
• 核心路径覆盖：只测试最核心的路径，不考虑边界情况
• 可自动化：测试应该可以无人值守地运行，不需要人工介入

从协作场景抽象出的复用方法

这次真实的协作场景，可以抽象成以下可复用的工作方法：

方法1：用 SKILL.md 承载测试定义

在每个技能的 SKILL.md 中增加一个"## Testing / Quick Verification"章节，写入可以快速验证技能是否正常的命令或步骤。这样，任何 Agent 或人类协作者都能快速确认技能状态。

方法2：用优先级+通配符组织测试队列

• 用 P0/P1/P2 标记技能优先级
• 用命名前缀（如 jianfei-*）或标签来分组技能
• 冒烟测试时，先跑 P0，再跑 P1，P2 可以定期跑但不强求

方法3：结构化输出测试结果

不要只返回"成功"或"失败"，而是返回结构化的测试报告，包含每个技能的状态、失败原因分类、以及建议的下一步行动。

方法4：批量执行时的容错设计

批量测试时，一个技能的失败不应该阻塞其他技能的测试。Agent 应该具备"执行完所有测试，再汇总结果"的能力，而不是"遇到第一个失败就停止"。

判断链：用户背后的思考

回看用户的原始 prompt，可以发现用户的判断链是：

1. 为什么要批量测试？ 因为 jianfei-* 技能是高频率使用的技能，必须保证它们的可靠性。
2. 为什么用冒烟测试？ 因为完整测试太慢，冒烟测试可以快速反馈"核心功能是否正常"。
3. 为什么让 Agent 检查 SKILL.md？ 因为测试命令应该自描述，减少外部配置的负担。
4. 为什么指定 P0 队列？ 因为资源有限，应该优先保证核心技能的质量。

这些判断，用户没有在 prompt 中明说，但通过 prompt 的设计（优先级、通配符、自我描述的测试命令）传递给了 Agent。

结尾判断

技术内容（如何写测试命令、如何解析 SKILL.md）只是材料，提问过程（如何设计测试队列、如何确认结果）才是结构。好的批量测试不是"跑很多测试"，而是"用清晰的优先级、自描述的测试定义、结构化的结果输出，构建一个可持续运行的测试队列"。

这次协作的经验，下一次可以直接复用：当你需要为一批技能设计冒烟测试时，记得在 SKILL.md 中写入测试命令，用优先级和通配符组织测试队列，并要求 Agent 输出结构化的测试结果。