90分钟搭好电商AI测试助手:支付Bug多工作流联动,附完整教程

双 11 大促前夜，支付模块改了行代码，测试要回归登录、商品、购物车、订单、支付、库存、优惠券、退款整整 8 条链路。手工跑一遍，半天没了；漏测一条，就是资损。今天我们用 90 分钟，从 0 到 1 亲手搭一个电商 AI 测试助手，把这条链路变成分钟级联动回归。

一、为什么用电商项目做完整案例

电商系统几乎包含了测试里最复杂、最典型的链路：

登录 → 商品 → 购物车 → 订单 → 支付 → 库存 → 优惠券 → 退款

这里既有复杂业务规则，也有高风险资金链路，还有大量历史 Bug 和复杂的回归范围。一个成熟的电商 AI 测试助手，几乎能覆盖企业测试里的大部分复杂场景，特别适合练风险扩散分析和多模块联动回归。

举个最典型的例子，「支付成功」这一个动作，可能同时关联：

• 订单状态
• 库存扣减
• 优惠券核销
• 支付流水
• MQ 消息
• 退款链路

电商不是「业务难」这么简单，而是模块多、状态多、资金敏感，这正是把企业级 AI 测试助手做完整的最佳练兵场。

二、整体架构：工作流调度 + 知识库调用

先想清楚一件事，企业级 AI 测试助手的核心不是聊天，而是工作流调度 + 知识库调用。

用户输入    ↓AI 测试工作台（选任务入口）    ↓任务识别（用例 / Bug / 日志 / SQL / 回归）    ↓调用对应工作流 + 读取知识库    ↓生成测试建议 / 排查方向 / 回归范围    ↓人工复核（P0 结论必须人审）

工作流调度+知识库调用

对比一下就明白了：

一句话，聊天框是「问一句答一句」，工程化助手是「选入口 → 跑工作流 → 出可交付报告」。

三、动手 Step 1：创建工程化目录

真正的企业级助手，一定是工程化目录结构。先别急着写 Prompt，先搭目录。在本机终端执行：

mkdir -p Ecommerce_AI_Test_Assistant/{system,workflows,prompts,outputs,scoring,templates,assets}mkdir -p Ecommerce_AI_Test_Assistant/{historical_bugs,business_rules,sql_experience,log_patterns,regression_rules}mkdir -p Ecommerce_AI_Test_Assistant/system/{login,product,cart,order,payment,inventory,coupon,refund}touch Ecommerce_AI_Test_Assistant/README.md

目录含义速查：

⚠️ 注意：先搭目录再写 Prompt。没有目录约束，团队很快会陷入「每人一套 Prompt、输出格式全不同」的混乱。

到这一步，你应该能看到完整的 Ecommerce_AI_Test_Assistant/ 树形目录。接下来为「支付」模块写第一份模块配置。

四、八大业务模块：逐个配置 AI 助手

每个模块都遵循同一套模式：输入清单 → 调用工作流 → 输出测试点 → 核心测试重点。

以最高风险的支付模块为例，创建 system/payment/module.yaml：

module: paymentdisplay_name: 支付模块 AI 测试助手inputs:  - payment_rules  - callback_rules  - coupon_rules  - inventory_rulesworkflows:  - testcase_gen  - bug_analysis  - log_triage  - sql_analysis  - regression_listknowledge:  - historical_bugs/payment.yaml  - business_rules/payment.yamloutput_focus:  - 支付幂等  - 重复回调  - 订单状态同步  - 库存扣减一致性

再看登录模块的 Prompt 片段，可直接复制：

你是电商登录模块测试助手。根据【需求】生成用例。【需求】{{需求内容}}【必须覆盖】- 验证码：空/错/过期/重复使用/频控- Token：生成、刷新、失效拦截- 多设备登录、弱网重试、重复登录【输出】Markdown 表格：模块|场景|步骤|预期|优先级【参考历史 Bug】{{从 historical_bugs/login.yaml 粘贴 3 条}}

各模块核心重点速查：

💡 小贴士：不必 8 个模块一次做完。建议顺序，登录（简单）→ 订单 → 支付（最难）→ 库存/优惠券，每完成一个模块就在 outputs/ 存一份 AI 输出样例。

五、五类输入如何调用工作流

工程化助手的核心能力，是把五类输入分别路由到对应工作流：

5.1 需求 → 用例生成 粘贴需求到表单，系统自动：识别业务模块 → 读 business_rules → 读 historical_bugs → 调用 prompts/testcase_gen.txt。核心原则：需求分析一定要关联历史 Bug，在 Prompt 里用 {{历史 Bug}} 占位符注入。

5.2 Bug → Bug 分析 结构化输出：问题现象、影响模块、推荐日志关键词、推荐 SQL 方向、回归范围、风险等级 P0/P1/P2、需人工补充的证据。禁止无证据断言根因。

5.3 日志 → 日志排查 例如 ERROR payment-service lock wait timeout，AI 应收敛为：异常类型（数据库锁等待）→ 疑似模块（订单更新、支付回调）→ 建议（检查事务提交、订单表锁、并发更新）。

5.4 SQL → SQL 分析 例如 SELECT  FROM order_info LIMIT 100000, 20;，应输出：深分页风险、慢查询风险、建议游标分页、建议减少 SELECT  字段。

5.5 版本改动 → 回归测试 输入「支付回调逻辑优化」，期望回归：支付、订单、库存、优惠券、MQ、退款，并关联历史 Bug：重复回调、订单状态不同步、库存未回滚。

六、完整实战：支付 Bug 多工作流联动

这是本篇最重要的「照着做」环节。准备下面输入包，按顺序跑 4 个工作流，最后人工汇总。

6.1 准备输入包

【Bug 现象】支付成功，订单仍显示未支付【日志片段】ERROR payment-service lock wait timeout【可疑 SQL 方向】订单状态更新 SQL；是否存在长事务锁表【版本背景】近期优化过支付回调逻辑

6.2 依次执行 4 个工作流

6.3 汇总为「人工复核报告」

将四步输出合并为 outputs/payment_incident_report.md：

# 支付状态不一致 — AI 辅助分析报告## 问题现象支付状态与订单状态不一致## 影响模块支付回调 / 订单服务 / 数据库事务## 排查方向- 日志：payment callback, order update- SQL：订单 status 更新、事务锁等待## 回归范围支付、订单、库存、优惠券、退款## 风险等级P0（需人工复核后确认是否阻塞上线）## 人工待验证- [ ] 查支付流水与订单表同一 traceId- [ ] 复现并发回调场景- [ ] 确认事务隔离级别与索引

⚠️ 注意：企业级 AI 助手真正强在多工作流联动，而不是单次问答。你完成 6.3 即算跑通本篇主线。

七、动手练习：设计你的电商 AI 助手

从下面模块选一个深度设计，不要贪多：登录 / 订单 / 支付 / 库存 / 优惠券。

填写练习表：

【选定模块】________________【输入清单】（至少 4 项）1. 2. 3. 4.【绑定工作流】□ 用例生成 □ Bug 分析 □ 日志 □ SQL □ 回归【知识库条目】（至少 3 条历史 Bug 或规则）1. 2. 3.【Prompt 文件名】prompts/____________.txt【输出格式】例：现象|模块|日志关键词|SQL 方向|回归|P 级【人工复核点】（至少 2 条 AI 不能替人决定的）1. 2.

完成标准：用真实或虚构输入跑通 1 次工作流，输出能直接交给测试负责人复核。

八、常见问题

九、小结与下一步

电商 AI 测试助手 = 八大业务模块 + 六大 AI 能力（用例/Bug/日志/SQL/回归/报告）+ 知识库（历史 Bug + 业务规则 + 日志/SQL 经验）+ 工作流 + Prompt + 输出结构 + 人工复核。

工程化落地的关键，不是「会不会用 AI」，而是能否把项目测试经验做成可复用助手。目录先行，模块配置 + 知识库 + Prompt 分离，这是从「单兵测试」走向「AI 测试工程师」的第一步。

接下来可以：

1. 完成第三节目录搭建
2. 做支付模块 + 第六节联动演练
3. 完成第七节单模块练习
4. 与 6.4 节工作台 YAML 合并，形成可演示的「电商 AI 测试工作台」

下一篇，我们来做「综合实战：搭建企业级 AI 测试助手原型」，把今天搭的模块真正跑起来～