从“切工具”到“走流程”:我搭了个AI工作台,Bug分析从30分钟缩到5分钟

你有没有算过，自己一天的时间都去哪儿了？

我算过。每天8小时工作时间，真正花在“测试思考”上的，不到3小时。剩下的5小时，全部消耗在“把信息从一个地方搬到另一个地方”。

查日志切到Kibana，查数据切到MySQL，提Bug切到Jira，写分析开Word，补用例翻Excel，做回归又切回测试平台。一个Bug从发现到闭环，工具切了七八次，脑子也跟着切了七八次。

到了下午，精力全花在找东西上，真正有价值的思考反而没时间做。

后来我用LangChain搭了一个AI测试工作台，把日常工作收拢到一个界面里。半年下来，Bug分析从30分钟缩到5分钟，用例生成从半小时缩到1分钟，日志排查从翻半天变成AI直接定位。整体算下来，效率翻了不止3倍。

源码我开源了，文末有链接。这篇不讲虚的，直接说怎么搭的、长什么样、能干什么。

一、为什么“万能聊天框”救不了测试人

很多团队做AI测试助手，只做了一个输入框。

测试人把所有问题都丢进去：生成用例、分析Bug、查日志、分析SQL、写报告。结果AI不知道当前任务是什么，输出也越来越乱。

单一聊天框的问题在于：任务类型混在一起、输入结构不统一、输出格式每次不同。

同一个问题，十个人能问出十种问法，AI的回答也飘忽不定。今天给你Markdown表格，明天给你自然语言描述，后天把异常和正常混在一起——每次都要手动调整，我等于多了一个AI实习生，干活快但不稳定，还得我给它收拾烂摊子。

更烦的是，每次我都得重新写一遍Prompt：“你是资深测试工程师，请覆盖正常、异常、边界、鉴权四类场景……”同样的话，我说了不下50遍。

二、“容器”长什么样

偶然看到一篇关于测试Skill的文章，里面提到一个概念——把测试流程固化成AI的“肌肉记忆”。

思路一下子通了：如果我把每个测试场景都做成一个标准化的“入口”，每个入口绑定固定的Prompt和输出格式，那AI不就是个听话的流水线工人了吗？

工作台就两部分：左边是任务栏，右边是工作区。

任务栏六个入口：生成用例、分析Bug、排查日志、分析SQL、写报告、回归验证。点任何一个入口，右边出现对应的输入表单。填完点提交，AI输出结构化的结果。

跟普通聊天框最大的区别是：每个入口的表单字段不一样，输出格式也不一样。

生成用例要填需求描述、优先级、关联模块——输出是表格。分析Bug要填现象描述、错误日志、截图——输出是结构化报告。排查日志要填日志片段、traceId、时间范围——输出是调用链+问题定位。

好比你去餐厅点菜，不用对着服务员喊“我要吃点什么”，而是直接看菜单——每个菜有编号、有描述、有价格，你只需要勾选就行。

三、知识库是AI的“参考书”

工作台分两层：知识库在下，任务入口在上。

知识库是AI的参考书。没有参考书，AI只能凭通用能力回答问题，给出的答案大概率不贴合项目实际。

我在知识库里放了五样东西：

• • 历史用例库：按模块分类，包含用例编号、步骤、预期结果。AI生成新用例时会参考已有用例的颗粒度和命名风格。
• • Bug库：记录历史Bug的现象、根因、解决方案。AI分析新Bug时会检索相似问题，给出参考。
• • 需求文档：当前版本的需求说明和PRD。AI生成用例和报告时需要知道业务背景。
• • 日志规范：系统日志的格式、字段含义、常见错误码。AI排查日志时能准确理解每条日志的含义。
• • 表结构文档：数据库表名、字段名、字段含义。AI分析SQL时能检查字段是否存在、类型是否匹配。

知识库不要求一步到位。先放最核心的历史用例和Bug库，其他边用边补。每处理完一个任务，把有价值的信息整理进去，知识库会越来越大，AI的回复也越来越准。

四、六个入口，每个都是一套Skill

下面逐个说每个入口怎么设计、怎么用。

入口一：生成测试用例

• • 输入表单：需求描述（必填）、优先级（选填）、关联模块（选填）
• • 固定Prompt的核心逻辑：让AI参考历史用例风格，覆盖正常流程、异常流程、边界条件，输出为表格。
• • 实战例子：需求描述“用户登录支持手机号+验证码方式”，AI生成12条用例——正常登录3条、验证码错误2条、验证码过期2条、手机号格式错误2条、并发登录3条。以前手写这12条用例至少半小时，AI一分钟搞定。

入口二：分析Bug

• • 输入表单：Bug现象描述（必填）、错误日志（选填）、截图/录屏（选填）
• • 固定Prompt的核心逻辑：让AI还原Bug现象、推断根因、给出验证方法和修复建议、关联历史相似Bug。
• • 实战例子：用户反馈“支付成功但订单状态未更新”。输入错误日志后，AI定位到支付回调接口更新订单时数据库连接超时，关联到3个月前一个相似的Bug记录，给出事务+重试机制的修复建议。以前做这种分析至少30分钟，现在5分钟。

入口三：排查日志

• • 输入表单：错误日志片段（必填）、traceId（选填）、时间范围（选填）
• • 固定Prompt的核心逻辑：让AI分析调用链路、定位错误环节、推断根因、给出排查建议。
• • 实战例子：输入一段包含“ConnectionTimeout”的日志，AI画出网关→服务A→数据库的调用链，定位到数据库连接池耗尽，建议检查连接池配置和慢查询。

入口四：分析SQL

• • 输入表单：SQL语句（必填）、执行场景说明（必填）、期望结果（选填）
• • 固定Prompt的核心逻辑：让AI检查语法正确性、性能风险、数据安全、规范检查，给出优化建议。
• • 实战例子：分析一条SELECT * FROM orders WHERE create_time > '2024-01-01'，AI指出未走索引，建议在create_time字段建索引，并建议只查询必要字段而非*。

入口五：生成测试报告

• • 输入表单：测试轮次（必填）、用例执行结果（必填）、Bug统计（必填）
• • 固定Prompt的核心逻辑：让AI生成包含测试概述、用例执行情况、Bug分布分析、风险评估、测试结论的标准报告。
• • 实战例子：输入P0轮次的执行数据（总用例150条，通过142条，失败8条），AI生成完整报告，风险评估指出支付模块2个P0 Bug未修复，建议延期上线。

入口六：回归验证

• • 输入表单：本次变更说明（必填）、影响范围（必填）、已有用例集（选填）
• • 固定Prompt的核心逻辑：让AI从历史用例中筛选直接相关用例、间接相关用例，给出新增用例建议，按优先级排序输出回归清单。
• • 实战例子：变更说明“优化支付回调事务处理”，影响范围“支付模块、订单模块”。AI从历史用例库中筛出12条支付模块用例、8条订单模块用例，补充2条并发回调的新用例。

五、更好玩的是“联动”

单个入口只是第一步。真正提升效率的，是入口之间的数据流转。

拿一个真实的线上问题走一遍全流程：支付成功但订单状态未支付。

整个过程从接到反馈到输出Bug分析、补充用例、拿到回归清单，一共不到10分钟。放在以前，这套流程走下来至少一小时。

六、几点实在的感受

用了大半年，说几点真实的感受。

好处很明显：重复性工作少了很多。以前写用例要翻历史用例参考格式，现在AI自动生成，我只需要审核和微调。排查问题时不用在日志系统和聊天框之间来回切换，一个界面里全搞定。

但也不是万能的：AI生成的用例偶尔会遗漏边界条件，需要人工补。Bug根因分析有时会过度推理，给出的原因看着合理但实际不对。所以我的习惯是：AI生成初稿，我审核修改，最终产物还是人在把控。

源码是起点不是终点：开源的1.0版本是基础框架，真正好用需要根据自己团队的业务和规范去定制——调整Prompt模板、补充知识库内容、修改输出格式。

七、你可能会问的几个问题

工具搭好了，省出来的时间远比你想象的多。当你不用再为工具切换消耗精力的时候，才能真正把时间花在理解业务、设计策略、把控质量上。