作为测试人，我们对这种场景再熟悉不过：团队里谁擅长性能分析，遇到慢的问题就找谁；谁对日志排查熟，出了bug就拉谁一起看。测试经验的传递，大部分时候就是靠这种"口耳相传"。

这种模式在团队稳定的时候运转得不错。但这两年，不少团队都经历了缩编——人少了，活没少。以前三个人分工的事，现在一个人扛。大量的时间花在了重复性的排查工作上——查日志、看监控、翻数据库，这些事情流程固定、耗时却不短，挤占了我们去做更有价值的事情的精力。

每个人的核心经验当然还是自己最有力的武器，但那些重复的、流程化的排查工作，能不能让AI来分担？让测试人员把精力省下来，专注于用例设计、风险分析、探索性测试这些真正需要人的判断力的事情。

从招助手到造助手

大部分测试团队都经历过类似的成长过程：一开始就一两个人，什么都得自己来。后来事情多了，开始招人分工——有人专门做性能，有人负责自动化，有人擅长数据库排查。

现在很多团队的处境刚好反过来——人在减少，但每个人需要覆盖的面更广了。一个测试人员可能同时要应付性能问题、日志分析、数据库排查，而这些以前分别是不同人的专长。

思路其实可以借鉴当初招助手的逻辑：用AI给每个人配一个"虚拟专家助手"。它不是替代人，而是帮每个人分担那些重复性的排查工作，让大家有更多精力投入到真正需要思考和判断的事情上。

具体来说，我把团队里几个关键方向的经验，分别做成了独立的Skill，再用一个编排层把它们串起来，就构成了一个完整的测试助手智能体。

四个Skill：把专家装进工具箱

Skill 1：服务器性能分析（linux-ops-analyst）

🎯 一句话看懂：相当于给你配了一个24小时在线的性能测试专家，你说"页面慢"，它就去服务器上查CPU、内存、磁盘、网络，告诉你到底卡在哪里。

产品页面响应慢的时候，性能排查是一套相对固定的流程：先看服务器资源，再定位是哪个进程在消耗资源，最后判断是产品代码的问题还是硬件扛不住。这套流程每次都要手动跑一遍，费时间但思路是固定的。

这个Skill就是把这套排查流程交给AI来执行。它会通过SSH连上服务器，按照分层诊断的逻辑，从CPU、内存、磁盘IO、网络逐层排查，找到资源消耗的源头，再反向推导根因。测试人员省下来的时间，可以去做更有价值的分析判断。

Skill 2：日志查询与关联分析（product-log-query）

🎯 一句话看懂：你告诉它"某某功能报错了"，它自动知道该去哪些组件查日志，还能跨组件做关联分析。

测试过程中发现bug之后，日志排查是最耗时的环节之一。先要知道这个功能涉及哪些后台组件，再去对应的服务器上找日志文件，然后在海量日志里过滤关键信息，有时候还需要跨多个组件做时间线关联。

这个Skill把"哪个组件的日志在哪台机器的哪个路径"这些信息提前整理好，连同组件之间的调用关系一起喂给AI。测试人员只需要描述问题现象，它就能自动去对应的地方查日志，还会沿着调用链往上游追溯，看看是不是上游组件先出了问题，导致下游级联报错。

Skill 3：数据库诊断（product-db-query）

🎯 一句话看懂：你说"资产列表页面加载慢"，它知道这个页面背后查的是哪几张表，直接去库里分析是数据量太大、分区不合理，还是查询语句有问题。

日志能告诉你"出错了"，但有些问题日志里体现不出来——比如数据不一致、慢查询、分区碎片化。这时候需要直接查数据库。

这个Skill的核心是一份功能模块→接口→数据表的映射关系。我整理了产品43个功能模块，每个模块对应的API接口、后端服务、ClickHouse表和MySQL表，甚至标注了接口的基准响应时间。AI拿到这份"地图"之后，就能根据用户描述的功能问题，精准地去查对应的表，而不是在几十张表里盲目搜索。

Skill 4：平台监控数据查询（product-mcp-query）

🎯 一句话看懂：通过MCP协议接入产品平台，直接调用平台自身的分析能力，相当于让AI也能像你一样登录管理后台看数据。

如果你的产品本身有mcp，也应该纳入排查范围。这个Skill通过MCP（Model Context Protocol）接入产品平台，让AI在分析问题时有更全面的数据视角。

一个编排者：把专家组织起来

有了四个"专家"还不够，还需要一个"项目经理"来协调它们——这就是product-issue-test-assistant，测试助手的编排层。

它负责三件事：

1. 问题分类
   ：听到用户描述的问题后，判断应该从哪个方向切入——是基础设施问题、产品bug、数据库问题，还是需要查监控数据
2. 跨Skill联动
   ：当一个Skill的分析结果指向另一个方向时，自动触发下一个Skill。比如linux-ops-analyst发现是ClickHouse进程吃光了CPU，编排层就会自动调用product-db-query去查数据库层面的问题
3. 综合归因
   ：把多个Skill的分析结果汇总，判断因果方向——是系统瓶颈导致了产品故障，还是产品bug导致了系统过载

看一个实际例子

假设测试人员反馈："帮我分析一下，获取XX的接口响应超过5秒，正常应该在1秒以内。"

编排层收到这个问题后，处理流程大致是这样的：

第一步：问题分类。接口响应慢，可能是服务器资源问题，也可能是数据库慢查询。编排层先把它分类为"infrastructure"方向，从服务器性能分析切入。

第二步：服务器排查。linux-ops-analyst连上服务器，发现CPU使用率正常，但磁盘IO的写延迟达到了50ms（正常应在5ms以内），进一步定位到是ClickHouse进程在大量写入。

第三步：跨Skill联动。编排层发现瓶颈指向ClickHouse，自动触发product-db-query。数据库Skill查到资产表的分区粒度是30分钟，数据量已经超过5000万行，分区数过多导致查询时需要扫描大量小分区。

第四步：日志佐证。编排层再触发product-log-query，查到对应时段的日志里有大量"Read timed out"和慢查询警告，时间戳与用户反馈的慢响应时间窗口吻合。

第五步：综合归因。三个方向的证据汇总：磁盘IO高 → ClickHouse分区碎片化 → 资产列表查询慢。根因是分区策略不合理，建议将分区粒度从30分钟调整为6小时。

整个过程，测试人员只说了一句话，剩下的AI自己完成了。

核心难题：如何让分析结果更精准

工具搭起来之后，最大的挑战不是"能不能跑起来"，而是"分析结论到底准不准"。

自己迭代下来，结论不准主要有两类问题：

问题一：结论浮于表面，不是根因

AI分析完告诉你"磁盘IO高"——这当然没错，但这不是根因。作为一个有经验的测试人员，我们会接着追问：是谁导致的IO高？为什么这个进程会产生这么大的IO？是周期性任务还是持续性的？

所以我在linux-ops-analyst里设计了一个"闭环三问"的迭代机制：

每一轮分析结束后，AI必须回答三个问题：

• **谁**——能不能具体到进程名、PID？
• **为什么**——能不能解释这个进程为什么会产生这个负载？
• **可操作**——这个结论是否足够具体，让人拿到就能行动？

三个问题全部回答"是"，才算闭环，否则继续下一轮深挖。最多迭代5轮，防止无限循环。

这里有一个关键的设计：每轮分析只在上下文中保留15行摘要，完整数据写到磁盘文件里。这样即使迭代5轮，上下文也不会被撑爆，AI始终有足够的"思考空间"来分析新一轮的数据。

问题二：结论看着合理，但逻辑不严谨

还有一种更隐蔽的问题：AI给出的结论看起来头头是道，但经不起推敲。比如它看到某个进程CPU占用80%就断言"这个进程是罪魁祸首"，但其实这个进程可能是"受害者"——是其他原因导致它不得不消耗这么多资源。

对付这个问题，我设计了"质疑者"机制——分析结束后，AI要切换角色，从"诊断者"变成"质疑者"，用六个维度来挑战自己的结论：

1. 因果方向
   ：这个高负载进程到底是"肇事者"还是"受害者"？
2. 替代假设
   ：同样的数据，能不能支撑一个完全不同的解释？
3. 已知误诊模式
   ：这个结论是否匹配团队踩过的坑？（我整理了一份误诊模式库，比如"w_await高不一定是硬盘差，可能是业务写入模式的问题"）
4. 阈值边界
   ：关键数据是否刚好在判断阈值附近？如果偏差5%，结论还成立吗？
5. 症状解释力
   ：这个结论能完整解释用户反馈的所有症状吗？
6. 建议可行性
   ：给出的建议是否足够具体，能精确到文件、配置项、命令？

质疑最多进行2轮，每轮最多补充3条验证命令。经过质疑后，结论会被标记为四种状态之一：经受住了（高置信）、有保留地通过（中置信）、被推翻（回到迭代）、不确定（列出所有候选假设）。

编排层的第二道关卡

除了单个Skill内部的质疑，编排层在输出最终报告前，还有一道独立的质疑关卡，从更宏观的角度检查：

1. 数据真实性
   ：引用的数值是实际查询结果，还是AI自己推测的默认值？
2. 因果充分性
   ：建议的优化方案真的能解决问题吗？
3. 变更必要性
   ：当前的配置/结构真的有问题吗？
4. 副作用评估
   ：建议的改动会不会引入新问题？
5. 可验证性
   ：结论能不能当场跑一条命令来证实？如果能，直接执行验证，不要留给用户
6. 用户可操作性
   ：建议是否具体到了确切的文件路径、配置项、操作命令？

凡是能当场验证的结论，AI必须自己执行验证，不通过验证的建议会被标记删除线。这一条是迭代过程中加上去的——早期版本经常出现AI信誓旦旦说"某个配置值是X"，实际查出来完全不一样的情况。

不只是工具，是越用越顺手的助手

这个测试助手不是一个静态的工具。它有一个自学习机制——当你纠正它的分析结论时（"不对，真正的原因是XX"），这些纠正会被沉淀到知识库里，下次遇到类似场景，AI会优先匹配已有的经验模式。用得越多，它越懂你们团队的产品特点和常见问题模式。

对测试人员来说，核心的分析能力、测试设计能力仍然是自己的竞争力。AI助手做的是把那些重复性的排查、查询、关联分析的体力活承担下来，让每个人都能把时间花在刀刃上。

不过这篇只讲了"怎么让结论更准"，还有两个绕不开的工程问题没展开：

多个Skill之间的数据到底怎么传？服务器分析的结果要交给数据库Skill做进一步排查，日志Skill的发现要反馈给编排层做综合判断——这中间的数据流转不是简单的"把上一步的输出丢给下一步"就能搞定的，涉及到数据格式、摘要策略、文件落盘等一系列设计。

这么多Skill轮番调用，上下文怎么控制不爆？一个完整的排查流程下来，可能涉及4个Skill、多轮迭代、还有质疑环节，如果每一步的原始数据都堆在上下文里，Token很快就会见顶。怎么在保证AI"记得住关键信息"的同时，把上下文控制在合理范围内，这里面有不少取舍。

这两个问题，下一篇单独拆开来聊。

欢迎关注「测试老Z」，咱们接着聊。