夜雨聆风事情是这样的。
我最近在帮团队搭测试工作流的时候，发现一个特别普遍的问题。一个 Bug 报上来，要同时翻日志、查 SQL、定回归范围，还得验证 Prompt 稳不稳定。每次都得重新组织语言，输出格式五花八门，想拉同事一起用又无从下手。
今天这篇，我们手把手搭一个 AI 测试工作流工具箱，让 AI 像测试团队一样协同工作。
一、为什么测试人需要 AI 工作流工具箱？
先别急着写代码，我们想清楚一个问题，为什么零散的 Prompt 不够用？
真实工作里，一个 Bug 往往牵一发动全身。要看日志定位异常、要查 SQL 确认数据状态、要定回归范围、还要验证 Prompt 在同样本上是否稳定。如果每次都用零散 Prompt，你会发现自己一直在做三件低效的事：
- 重新组织语言
：同一个 Bug 分析需求，每次都要从头描述一遍背景。 - 输出格式不统一
：今天输出一段话，明天输出一个列表，后天想汇总都难。 - 难以团队协作
：同事拿不到你的 Prompt，你也没法复用别人的经验。
而工具箱的价值，恰恰不是「多几个 Prompt」，而是 清晰入口 + 固定流程 + 统一输出。它把散落的 Prompt 收拢成一套可复用的工程化结构，让 AI 的输出像测试团队一样有章法。
二、工具箱核心原理：五个助手与统一规则
这个工具箱的核心，是 五个职责清晰的小助手，而不是一个大而全的万能助手：
每个助手都有自己独立的 输入清单 → workflow 流程 → 输出格式，互不干扰。而把它们串起来的，是 system 层的三份统一规则：
- 风险等级规则
：所有输出必须带 P0–P3 等级并说明理由。 - 人工复核规则
：关键结论必须由测试人勾选确认。 - 总规则
：只执行对应 workflow、输出符合格式、引用资产、禁止硬猜根因。
这套设计的精髓在于，组合使用，而非单点依赖。下面我们就从零开始，一步步把它搭出来。
三、实战第一步：创建目录骨架
打开终端，在项目根目录执行下面这段命令，一键创建整个工具箱的骨架：
export TOOLBOX=AI_Test_Workflow_Toolbox
mkdir -p $TOOLBOX/{system,workflows,prompts,outputs,assets,templates,examples}
touch $TOOLBOX/SKILL.md执行完，你应该看到这样一棵目录树：
AI_Test_Workflow_Toolbox/
├── SKILL.md # 总入口：5 个任务路由
├── system/ # 统一规则
├── workflows/ # 5 个工作流
├── prompts/ # 5 个助手 Prompt
├── outputs/ # 5 个输出格式
├── assets/ # 5 类业务资产库
├── templates/ # 输入表单模板
└── examples/ # 完整联动案例输出⚠️ 注意：创建完务必用
tree AI_Test_Workflow_Toolbox（或find）确认目录结构一致。很多新手在这里漏建了templates或examples，后面联动案例就没地方放了。
四、实战第二步：编写 system 层统一规则
目录建好了，我们先写最关键的 system 层，这是整个工具箱的「宪法」。
第一步：风险等级规则（system/风险等级规则.md）
要求：所有助手输出必须带 P0–P3 之一，并写一句理由。
第二步：人工复核规则（system/人工复核规则.md）
以下结论 必须由测试人勾选确认 后方可作为正式结论：
[ ] 根因是否有日志/SQL/接口证据 [ ] 风险等级是否与业务影响一致 [ ] 回归范围是否过大或过小 [ ] SQL 优化建议是否需研发/DBA 确认 [ ] 日志证据是否完整（含 traceId 链路） [ ] Prompt 测试样本是否覆盖边界与异常输入
第三步：总规则（system/AI 测试工作台总规则.md）
用户选择任务入口后，只执行对应 workflow，不得混用其他助手流程。 输出必须符合 outputs/中对应格式。必须引用 assets/中相关资产；标注「必须加载」的文件不得跳过。证据不足时禁止硬猜根因，按各 workflow 列出缺失信息。 所有输出文末附「人工复核点」并引用 system/人工复核规则.md。风险等级统一遵循 system/风险等级规则.md。
到这里，工具箱的「宪法」就立好了。接下来我们开始造五个助手。
五、实战第三步：打造五个职责清晰的助手
每个助手都需要三个文件：workflow（流程）+ output（输出格式）+ prompt（入口）。下面给出每个助手的可运行最小版。
5.1 Bug 分析助手
输入（templates/bug_input.yaml）：
title: 「支付成功后订单仍显示未支付」
steps: [「完成微信支付」, 「订单列表仍为待支付」]
actual: 「status=待支付」
expected: 「status=已支付」
log_snippet: 「（粘贴日志）」
api_response: 「（粘贴 JSON）」
version_change: 「v2.3.1 优化支付回调」workflow 要点：提取现象 → 影响模块 → 可能原因 → 推荐日志/SQL → 关联历史 Bug → 回归范围 → 风险等级 → 人工复核
Prompt 入口（prompts/Bug 分析助手 Prompt.md）：
你是 Bug 分析助手。严格按 workflows/Bug 分析工作流.md 执行。
加载 assets/历史 Bug 库.md。输出必须符合 outputs/Bug 分析输出格式.md。案例输出要点（支付未更新订单）：
影响模块：支付回调、订单状态、MQ、支付流水 推荐日志：payment callback、order status update、mq consume 推荐 SQL：order_info、payment_record 回归范围：支付、订单、库存、优惠券、退款 风险等级：P0
5.2 日志排查助手
输入：原始日志、traceId、发生时间、业务场景、环境。
workflow：关键词 → 异常类型 → 调用链 → 模块 → 历史规律 → 排查建议 → 证据不足清单
案例日志：
ERROR order-service traceId=abc123
Call inventory-service failed: Read timed out输出要点：异常类型=接口超时；调用链=订单→库存；建议查 inventory-service 同 traceId 日志与慢 SQL。
5.3 SQL 分析助手
输入：SQL、业务场景、表名、数据量级、接口名、现象。
案例 SQL：
SELECT * FROM order_info
WHERE status = 1
ORDER BY create_time DESC
LIMIT 100000, 20;输出要点：SELECT *、status 低区分度、深分页、order by 风险；建议 EXPLAIN、游标分页；风险 P1。
5.4 回归测试助手
输入：本次改动、需求/Bug 说明、接口变更、历史 Bug 库、业务链路。
案例改动：「优化支付回调逻辑」
输出要点：必回归支付回调、订单状态、流水、库存、优惠券、MQ、退款；历史 Bug：重复回调、订单未支付；优先级 P0 项标注。
5.5 Prompt 测试助手
输入：待测 Prompt、测试目标、测试样本、期望输出规则。
待测示例：请根据需求生成测试用例。
测试维度：
同一需求重复运行是否稳定 需求缺失是否提示补充 错误需求是否识别矛盾 多轮是否保持输出格式 证据不足是否乱编
输出：稳定性/边界/错误输入/多轮一致性/幻觉风险/优化建议/是否通过。
五个助手都建好后，我们还需要一个「总调度」——SKILL.md。
六、实战第四步：总入口 SKILL.md 路由设计
SKILL.md 是整个工具箱的「前台」，用户说一句话，它就知道该走哪条流程。
---
name: ai-test-workflow-toolbox
description: AI 测试工作流工具箱。Bug 分析、日志排查、SQL 分析、回归清单、Prompt 测试五入口。
---
# AI 测试工作流工具箱
## 任务入口（用户说哪句 → 走哪条流程）
| 用户意图 | 执行 |
|----------|------|
| 分析 Bug / 缺陷 | workflows/Bug 分析工作流.md + prompts/Bug 分析助手 Prompt.md |
| 排查日志 / traceId | workflows/日志排查工作流.md + prompts/日志排查助手 Prompt.md |
| 分析 SQL / 慢查询 | workflows/SQL 分析工作流.md + prompts/SQL 分析助手 Prompt.md |
| 回归范围 / 回归清单 | workflows/回归测试工作流.md + prompts/回归测试助手 Prompt.md |
| 测试 Prompt / 验证 Prompt | workflows/Prompt 测试工作流.md + prompts/Prompt 测试助手 Prompt.md |
## 全局规则（必须先读）
- system/AI 测试工作台总规则.md
- system/风险等级规则.md
- system/人工复核规则.md
## 多助手联动
当用户描述完整 Bug 且需要全流程时，按 workflows/联动工作流.md 顺序调用（见第七节）。到这里，工具箱已经能单点工作了。但真实场景往往是「一个 Bug 牵扯多个环节」，这时候就需要多助手联动。
七、实战第五步：多助手联动实战案例
我们用一个真实场景来演示：用户支付成功，但订单状态未支付。
协同流程：
① Bug 分析助手：现象、影响模块、风险 P0、推荐日志/SQL
↓
② 日志排查助手：支付回调、订单状态、MQ 相关日志
↓
③ SQL 分析助手：order_info、payment_record 状态一致性查询
↓
④ 回归测试助手：支付、订单、库存、优惠券、退款清单
↓
⑤ Prompt 测试助手（可选）：验证 Bug 分析 Prompt 在同样本上是否稳定联动工作流模板（workflows/联动工作流.md）：
# 多助手联动工作流
## 触发条件
用户需要「全流程分析」或同时提供 Bug+日志+SQL 场景。
## 执行顺序
1. Bug 分析工作流 → 产出主报告（outputs/Bug 分析输出格式.md）
2. 若用户提供日志 → 日志排查工作流，traceId 与 Bug 报告对齐
3. 若涉及数据状态 → SQL 分析工作流，使用 Bug 报告中的「推荐 SQL」
4. 回归测试工作流，输入 version_change + 影响模块
5. （可选）Prompt 测试工作流，待测 prompts/Bug 分析助手 Prompt.md
## 禁止
- 跳过 Bug 分析直接猜根因
- 各助手输出格式互相混用建议验证 SQL（供 SQL 助手输入）：
SELECT o.order_id, o.status AS order_status,
p.pay_status, p.callback_time
FROM order_info o
LEFT JOIN pay_record p ON o.order_id = p.order_id
WHERE o.order_id = 'YOUR_ORDER_ID';按联动流程跑一遍（可在 Cursor 中 @ 本 Skill），将合并结果保存到 examples/支付成功订单未支付_联动案例.md。
⚠️ 注意：联动时最容易犯的错是「跳过 Bug 分析直接猜根因」。记住，Bug 分析是主报告，其他助手都是围绕它补充证据，顺序不能乱。
八、落地避坑：常见错误与修复方案
搭建过程中，下面这几个坑几乎人人都会踩，提前帮你排掉：
⚠️ 特别提醒：
assets/目录千万别空着。历史 Bug 库、日志规律库这些资产，是 AI 输出质量的「弹药库」。哪怕先放 3 条真实案例，也比空目录强得多。
九、适用场景与章节小结
这个工具箱适合哪些场景？
日常 Bug 分析，快速定位影响模块和风险等级 日志排查，通过 traceId 串联调用链 SQL 优化，识别慢查询和深分页风险 回归范围制定，基于改动自动生成清单 Prompt 稳定性验证，确保输出可复用
工具箱价值总结：
- 清晰入口
：用户一句话，路由到对应流程 - 固定流程
：每个助手有标准 workflow，不跑偏 - 统一输出
：字段固定、风险等级明确、可团队协作
最终观点：未来测试人的核心能力，不是写更多 Prompt，而是把测试工作拆成多个可复用助手，让 AI 像测试团队一样协同工作。
下一步行动：按下面的 checklist 完成你的交付清单，然后用 Git 管理整个工具箱，和团队一起迭代。
[ ] 5 个工作流文件（workflows/） [ ] 5 个助手 Prompt（prompts/） [ ] 5 个输出格式（outputs/） [ ] 3 个 system 规则 [ ] 5 类 assets（可先做精简版，每库 ≥3 条） [ ] 1 个联动案例（examples/） [ ] SKILL.md 总入口
搭好之后，你会发现：以前要花半小时组织的 Bug 分析，现在一句话就能触发完整流程，输出还整齐划一。这就是工程化的力量。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。