基于Skill机制驱动AI辅助性能测试全链路实战

很多团队在引入 AI 辅助性能测试之后，反而踩了更多坑：AI 生成的 JMeter 脚本要么跑不起来，要么压出来的结果跟线上表现完全对不上。出现这种情况，并不是 AI 本身不行，而是大部分用法停留在“让 AI 写一段脚本”的层面，缺少一套可约束、可沉淀、可复用的执行框架。本文从工程化角度，讲清楚如何基于 Skill 机制把性能测试经验固化下来，配合 JMeter 完成从需求分析、脚本生成、压测执行到结果分析的全链路实战，内容偏实操，代码和配置可以直接套用。

1. 为什么“AI 做性能测试”经常翻车

1.1 AI 生成脚本的常见误区

先说一个很典型的现象：很多测试同学拿到 ChatGPT、Codex 或内部 AI 工具之后，第一反应就是把接口文档丢进去，然后输入“帮我生成一个 JMeter 压测脚本”。AI 确实能在几秒内输出一大段.jmx内容，表面看结构完整、节点齐全，但拿回 JMeter 里一跑，问题就来了。

常见问题包括：

• 生成的.jmx缺少 testPlan 外层节点，JMeter 直接报解析错误。
• 请求路径中把POST请求的参数写进 URL，和接口实际定义不符。
• 断言写得过于宽松，响应已经是 500 了，聚合报告里错误率还是 0%。
• 线程数、循环次数没有结合业务复杂度，只是随机写了 100 个线程跑 10 秒。
• 缺少定时器、监听器、结果保存配置，跑完数据没落盘，想分析也没有素材。

这些问题不是 AI 的“智商”问题，而是上下文不足、约束条件缺失导致的。AI 生成脚本时，并不知道你的接口返回结构、业务高峰特征、服务器规格、压测机部署方式，它只能按通用套路给出内容。

所以，AI 做性能测试的正确姿势，不是“无脑向 AI 要脚本”，而是把 AI 当成一个执行者，再通过一套可重复使用的“技能包”约束它的输出。

1.2 性能测试的本质是什么

再往深一层说，性能测试的核心不是生成脚本，而是回答三个问题：

• 系统在当前配置下，能支撑多大的并发？
• 响应时间、吞吐量、错误率是否满足业务目标？
• 瓶颈出现在哪一层？是应用代码、数据库、缓存、网络还是压测机本身？

脚本生成只是整个流程中最前端的一小步。真正耗费精力的，是压测前的场景设计、压测中的监控采集、压测后的结果分析、瓶颈定位和调优验证。

传统的做法是资深测试工程师把 JMeter 脚本模板、监控命令、分析脚本沉淀成文档或工具，每次新项目都手工套用一遍。问题在于，这些经验存在个人脑子里，换个人就断档，而且重复性劳动占比很高。

1.3 Skill 机制解决了什么问题

Skill 机制最早来自 AI Agent 和 AI 编程工具中的“技能包”概念，核心思想是：把某个领域的完成某项任务所需的指令、模板、脚本和参考文档打包到一个目录中，AI 在执行任务时自动加载这个技能包，从而按照固定流程输出结果。

放到性能测试场景中，Skill 机制的本质就是把“资深测试工程师的套路”固化成 AI 可读的资产：

• 如何根据接口信息生成标准的 JMeter 脚本；
• 如何提取和校验响应结果；
• 如何设置合理的线程模型、超时时间和断言；
• 如何分析结果 CSV、计算 TPS、P95、错误率；
• 如何在报告中定位瓶颈线索。

一旦这些经验被打包成 Skill，AI 的产出就不再是“随机自由发挥”，而是“在约束框架内的高效协作”。这就是 Skill 驱动全链路实战的价值。

2. 环境准备与整体思路

2.1 技术选型与工具链

本文涉及的技术栈如下：

这里要特别强调，AI 工具的版本更新速度很快，不同产品对 Skill 的加载方式、目录约定、配置项可能不一样。本文以下内容不针对某一个特定 AI 产品，而是提供一套通用的 Skill 组织思路，读者需要结合自己的工具做适配。

2.2 示例项目结构

为了讲清楚全链路实战，我设计了一个电商查询接口的压测场景：模拟 100 个用户并发查询订单列表，压测时长 5 分钟，观察接口 TPS、响应时间、错误率和服务器资源变化。

建议在工作目录下建立如下结构：

performance-test-demo/ ├── skill/ │ ├── performance-testing/ │ │ ├── SKILL.md │ │ ├── prompts/ │ │ │ ├── create-test-plan.md │ │ │ └── analyze-result.md │ │ ├── scripts/ │ │ │ └── parse_jmeter_result.py │ │ └── references/ │ │ └── jmeter-template.jmx ├── jmx/ │ ├── order_query_test.jmx │ └── testdata/ │ └── order_ids.csv ├── result/ │ ├── order_query_result.jtl │ └── html_report/ └── conf/ └── jmeter.properties

这个结构有四个关键部分：

• skill/保存性能测试 Skill 的全部资产，是整个体系的核心。
• jmx/存放最终生成并执行通过的 JMeter 脚本。
• result/保存压测结果和 HTML 报告。
• conf/保存 JMeter 输出格式等配置。

2.3 全链路流程拆解

整个 Skill 驱动的全链路流程可以拆成六步：

1. 需求分析：确定接口、压测目标、业务模型。
2. Skill 初始化：加载性能测试 Skill，让 AI 进入“性能测试专家”角色。
3. AI 辅助生成脚本：基于接口信息，在 Skill 约束下生成 JMeter 脚本。
4. 人工审核与校验：先小并发冒烟，确认脚本无误。
5. 压测执行与监控：命令行执行，同时采集服务端指标。
6. 结果分析与报告：AI 辅助分析 CSV，结合监控数据定位瓶颈。

后面每一节都会覆盖这六步中的具体操作。

3. Skill 机制核心原理拆解

3.1 Skill 的本质：把经验固化成资产

Skill 不是一个神秘的技术，它本质上是“上下文工程 + 自动化脚本”的组合。一个完整的 Skill 至少需要包含三部分：

• 指令层：告诉 AI 面对某类任务时，应该遵循什么步骤、输出什么格式、注意哪些边界。
• 模板层：提供可直接套用的脚本、配置、提示词模板。
• 工具层：提供能够处理结果的本地脚本，用于数据分析、格式转换、结果校验。

换句话说，没有 Skill 时，AI 像一个刚入行的实习生，什么都按常识来；有了 Skill，AI 就变成了一个“带着老师傅笔记”的执行者。

3.2 SKILL.md 与 Skill 目录设计

下面是我建议的性能测试 Skill 入口文件SKILL.md：

--- name: performance-testing description: 用于生成 JMeter 性能测试脚本并分析压测结果，适合接口压测、全链路压测场景。 version: 1.0.0 --- # Performance Testing Skill ## 适用场景 - 对 HTTP 接口进行并发压测 - 根据接口文档生成 JMeter 脚本 - 分析 JMeter 输出结果并给出瓶颈线索 ## 工作流程 1. 读取用户提供的接口信息、压测目标与业务模型。 2. 根据 scripts 目录下的脚本与 references 目录下的模板生成 .jmx 脚本。 3. 要求用户先以 5 个线程、1 次循环做冒烟验证。 4. 根据用户提供的 result 目录下的 .jtl 文件，使用 parse 脚本进行分析。 5. 输出 TPS、平均响应时间、P95、P99、错误率，并结合监控数据定位瓶颈。 ## 输出规范 - .jmx 文件必须有完整的 XML 结构，不能只输出片段。 - 所有压测数据必须参数化，禁止在脚本中硬编码业务数据。 - 断言必须包含响应码校验与响应体关键字校验。 - 压测结果必须保存为 CSV 或 JTL 文件，并生成 HTML 报告。

这个文件的目的是让 AI 在每次执行性能测试相关任务时，先读一遍规则，再动手。规则不需要写得特别长，但要把关键红线说清楚。

3.3 Prompt 模板设计要点

除了 SKILL.md，还需要准备两个 Prompt 模板：一个负责生成脚本，一个负责分析结果。

生成脚本的模板prompts/create-test-plan.md：

你是资深性能测试工程师。请基于以下接口信息，生成一份完整的 JMeter 测试脚本。 接口信息： - 接口地址：{base_url} - 请求路径：{path} - 请求方法：{method} - 请求头：{headers} - 请求体：{body} - 是否参数化：{param_required} - 参数化数据文件：{csv_file} 压测模型： - 线程数：{threads} - 是否使用持续压测：{duration_mode} - 压测时长（秒）：{duration} - 超时时间（毫秒）：{timeout} - 断言关键字：{assert_keyword} 输出要求： 1. 输出完整的 .jmx 文件，包含 testPlan、ThreadGroup、HTTPSamplerProxy、断言、聚合报告。 2. 参数化数据通过 CSV Data Set Config 读取。 3. 每个请求都要有响应码断言和关键字断言。 4. 脚本中不得出现具体用户名、订单号等敏感数据。 5. 给出启动压测的命令行命令。

这个模板的核心价值，是把“接口信息 + 压测模型 + 输出要求”三部分信息一次性提供给 AI，避免反复追问和自由发挥。

分析结果的模板prompts/analyze-result.md：

你是一名性能测试结果分析专家。请根据以下压测结果文件，生成分析报告。 结果文件路径：{jtl_file} 压测目标：接口 TPS 不低于 {target_tps}，平均响应时间不超过 {target_avg}，P95 不超过 {target_p95}，错误率不超过 {target_error_rate} 分析要求： 1. 计算总体 TPS、平均响应时间、P95、P99、错误率。 2. 对每个事务单独统计。 3. 如果指标不达标，根据耗时分布和错误码，分析可能的原因。 4. 给出下一步调优建议。

这两份模板是 AI 协作过程中的“作业指导书”。有了它们，AI 的产出质量会稳定很多。

4. 全链路实战：从需求到报告

4.1 需求分析与压测目标

动手压测之前，先把目标定下来。本文示例目标是“订单查询接口”。

业务背景：运营活动期间，预计订单查询接口的峰值并发为 100 个用户同时操作，每次查询必须在 1 秒内返回。

由此确定核心指标：

需求分析阶段还有一个容易忽略的点：确认压测环境。千万不要直接对生产环境发起压测，除非有明确的变更窗口和授权。本文示例假设在测试环境执行。

4.2 准备参数化数据与 JMeter 配置

实际压测时，接口通常不允许所有线程带同一个参数请求，那样会引入缓存干扰。所以先用 Python 准备一批订单号：

# 文件路径：performance-test-demo/jmx/testdata/gen_order_ids.py import random order_ids = [] for i in range(1000): order_id = f"ORDER2025{random.randint(100000, 999999)}" order_ids.append({"order_id": order_id}) with open("order_ids.csv", "w", encoding="utf-8") as f: f.write("order_id\n") for item in order_ids: f.write(item["order_id"] + "\n") print(f"生成 {len(order_ids)} 条订单号")

这个脚本会在jmx/testdata/目录下生成 1000 条订单号，供 CSV Data Set Config 读取。

同时修改 JMeter 输出配置，确保结果文件包含全部关键字段。编辑conf/jmeter.properties：

jmeter.save.saveservice.output_format=csv jmeter.save.saveservice.print_field_names=true jmeter.save.saveservice.thread_name=true jmeter.save.saveservice.label=true jmeter.save.saveservice.response_code=true jmeter.save.saveservice.response_message=true jmeter.save.saveservice.success=true jmeter.save.saveservice.time=true jmeter.save.saveservice.timestamp=true jmeter.save.saveservice.latency=true jmeter.save.saveservice.connect_time=true jmeter.save.saveservice.bytes=true jmeter.save.saveservice.sent_bytes=true jmeter.save.saveservice.thread_counts=true jmeter.save.saveservice.sample_count=true jmeter.save.saveservice.assertion_results=false jmeter.save.saveservice.xml=false

这段配置的作用是让 JMeter 输出 CSV 格式的结构化结果，方便后续用 Python 或 BI 工具分析。

4.3 让 AI 在 Skill 约束下生成 JMeter 脚本

准备好 Skill 和接口信息后，向 AI 发起请求。建议的请求内容是：

请加载 performance-testing Skill，按 create-test-plan 模板，为以下接口生成 JMeter 压测脚本。 接口信息： - 接口地址：test-api.example.com - 请求路径：/api/v1/orders/query - 请求方法：POST - 请求头：Content-Type: application/json - 请求体：{"orderId":"${order_id}","pageNum":1,"pageSize":10} - 参数化：order_id 从 order_ids.csv 读取 - 断言关键字：result 压测模型： - 线程数：100 - 持续压测：是 - 压测时长：300 秒 - 超时时间：3000 毫秒

正常情况下，AI 会输出一个.jmx文件内容。这一类脚本的核心逻辑分为三块。

线程组部分：

<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="订单查询接口压力测试"> <stringProp name="ThreadGroup.num_threads">100</stringProp> <stringProp name="ThreadGroup.ramp_time">20</stringProp> <stringProp name="ThreadGroup.duration">300</stringProp> <stringProp name="ThreadGroup.delay"></stringProp> <boolProp name="ThreadGroup.scheduler">true</boolProp> <boolProp name="ThreadGroup.same_user_on_next_iteration">true</boolProp> </ThreadGroup>

HTTP 请求部分：

<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="查询订单列表"> <stringProp name="HTTPSampler.domain">test-api.example.com</stringProp> <stringProp name="HTTPSampler.port">443</stringProp> <stringProp name="HTTPSampler.protocol">https</stringProp> <stringProp name="HTTPSampler.path">/api/v1/orders/query</stringProp> <stringProp name="HTTPSampler.method">POST</stringProp> <boolProp name="HTTPSampler.postBodyRaw">true</boolProp> <elementProp name="HTTPsampler.Arguments" elementType="Arguments"> <collectionProp name="Arguments.arguments"> <elementProp name="" elementType="HTTPArgument"> <boolProp name="HTTPArgument.always_encode">false</boolProp> <stringProp name="Argument.value">{"orderId":"${order_id}","pageNum":1,"pageSize":10}</stringProp> <stringProp name="Argument.metadata">=</stringProp> </elementProp> </collectionProp> </elementProp> </HTTPSamplerProxy>

CSV 参数化部分：

<ConfigTestElement guiclass="CsvDataSetConfigGui" testclass="CsvDataSetConfig" testname="读取订单号参数"> <stringProp name="filename">testdata/order_ids.csv</stringProp> <stringProp name="variableNames">order_id</stringProp> <stringProp name="delimiter">,</stringProp> <boolProp name="quotedData">false</boolProp> <boolProp name="recycle">true</boolProp> <boolProp name="stopThread">false</boolProp> <stringProp name="shareMode">shareMode.all</stringProp> </ConfigTestElement>

需要特别说明的是：AI 生成.jmx之后，我建议你先把<jmx>外层节点补全，或者在本地保留一个已验证的空模板，再把 AI 生成的 ThreadGroup 和 HTTPSamplerProxy 填进去。这样能规避 AI 偶尔遗漏外层节点的问题。

一个最小可用的.jmx外层结构如下：

<?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.6.3"> <hashTree> <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="订单查询性能测试计划"> </TestPlan> <hashTree> <!-- 在这里放入 CSV 配置、线程组、HTTP Sampler、聚合报告等节点 --> </hashTree> </hashTree> </jmeterTestPlan>

4.4 冒烟测试与脚本校验

脚本生成之后，直接上 100 线程是危险的。原因是：

• 脚本本身可能有语法错误。
• 断言可能过严或过松。
• 压测环境可能没有足够资源。

所以先做冒烟测试，把线程数改成 5，循环次数改成 1：

jmeter -n -t jmx/order_query_test.jmx -l result/smoke_result.jtl -j result/smoke_log.log

冒烟测试通过的标准是：

• 退出码为 0，没有异常堆栈。
• smoke_result.jtl文件存在且有数据。
• 错误率为 0，断言全部通过。

如果冒烟测试有失败请求，先看响应消息。常见的失败原因是请求体格式不对、缺少认证头、参数文件路径错误。这时候可以把 AI 生成的脚本和实际接口返回对比，人工修正后再继续。

4.5 正式执行压测

冒烟通过后，用命令行正式压测：

jmeter -n -t jmx/order_query_test.jmx \ -l result/order_query_result.jtl \ -e -o result/html_report \ -j result/order_query_log.log

参数解释：

• -n：非 GUI 模式，适合压测。
• -t：指定测试计划文件。
• -l：指定结果日志文件，保存为 JTL 或 CSV 格式。
• -e：压测结束后生成 HTML 报告。
• -o：HTML 报告输出目录。
• -j：JMeter 运行日志文件。

压测过程中，建议同时打开一个终端观察服务端资源：

top -H

或者用vmstat看 CPU 和内存：

vmstat 2

如果压测机和服务端不在同一台机器，建议部署 Node Exporter + Prometheus + Grafana，把采集到的 CPU、内存、磁盘、网络指标和 JMeter 结果放在一起看。

4.6 用 Python 脚本二次分析结果

JMeter 自带的聚合报告和 HTML 报告能提供基础指标，但在批量统计、多轮对比、自定义阈值告警方面不够灵活。这时候可以用 Python 脚本做二次分析。

保存脚本skill/performance-testing/scripts/parse_jmeter_result.py：

import pandas as pd import sys def analyze_jtl(file_path): df = pd.read_csv(file_path, delimiter=',') # JMeter 开启 print_field_names 后会自动带表头，这里做兼容处理 if 'timeStamp' not in df.columns: df.columns = [ 'timeStamp', 'elapsed', 'label', 'responseCode', 'responseMessage', 'threadName', 'success', 'failureMessage', 'bytes', 'sentBytes', 'grpThreads', 'allThreads', 'Latency', 'IdleTime', 'Connect' ] df['elapsed'] = pd.to_numeric(df['elapsed'], errors='coerce') df['success'] = df['success'].astype(str).str.strip() total = len(df) if total == 0: print("结果文件为空") return error_count = (df['success'] == 'false').sum() error_rate = error_count / total * 100 print("========== 总体指标 ==========") print(f"总请求数: {total}") print(f"错误数: {error_count}") print(f"错误率: {error_rate:.2f}%") print(f"平均响应时间: {df['elapsed'].mean():.2f} ms") print(f"P95响应时间: {df['elapsed'].quantile(0.95):.2f} ms") print(f"P99响应时间: {df['elapsed'].quantile(0.99):.2f} ms") print(f"最小响应时间: {df['elapsed'].min():.2f} ms") print(f"最大响应时间: {df['elapsed'].max():.2f} ms") t_start = df['timeStamp'].min() t_end = df['timeStamp'].max() duration_sec = (t_end - t_start) / 1000 if duration_sec > 0: print(f"实际压测时长: {duration_sec:.2f} s") print(f"整体TPS: {total / duration_sec:.2f}") print("\n========== 各事务指标 ==========") for label, sub in df.groupby('label'): sub_total = len(sub) sub_error = (sub['success'] == 'false').sum() sub_tps = sub_total / max(duration_sec, 1) print(f"[{label}]") print(f" 请求数: {sub_total}, 错误率: {sub_error / sub_total * 100:.2f}%") print(f" TPS: {sub_tps:.2f}") print(f" 平均响应时间: {sub['elapsed'].mean():.2f} ms") print(f" P95: {sub['elapsed'].quantile(0.95):.2f} ms") print(f" P99: {sub['elapsed'].quantile(0.99):.2f} ms") if __name__ == "__main__": if len(sys.argv) != 2: print("用法: python parse_jmeter_result.py <result.jtl>") sys.exit(1) analyze_jtl(sys.argv[1])

运行方式：

python skill/performance-testing/scripts/parse_jmeter_result.py result/order_query_result.jtl

输出效果类似：

========== 总体指标 ========== 总请求数: 62345 错误数: 87 错误率: 0.14% 平均响应时间: 452.12 ms P95响应时间: 980.45 ms P99响应时间: 1432.88 ms ========== 各事务指标 ========== [查询订单列表] 请求数: 62345, 错误率: 0.14% TPS: 208.11 平均响应时间: 452.12 ms P95: 980.45 ms P99: 1432.88 ms

到这里，一次完整的压测执行链路已经走通。但要注意，脚本只是辅助工具，真正判断系统是否存在瓶颈，还需要结合服务端监控。

4.7 结合监控定位瓶颈

拿到 TPS、响应时间、错误率三个指标后，先做一个快速判断：

如果 TPS 不达标但响应时间不高，通常不是服务端处理慢，而是并发上不去。此时重点看服务端连接数、线程池大小、数据库连接池和网络带宽。

如果响应时间长且错误率上升，通常是服务端资源耗尽，重点看 CPU、内存、GC、慢 SQL。

如果错误率集中在某几个响应码：

AI 可以帮你快速列出这些可能性，但最终确认根因，仍然要依赖监控数据和日志。这也是 Skill 驱动流程里强调“结果分析与监控结合”的原因。

5. 常见问题与排查思路

下面是整个流程中最容易踩的坑，我整理成了一张表，方便直接检索。

另外，单独说一个容易被忽略的问题：JMeter 自身的 JVM 内存。默认堆内存可能只有 1G，压测线程一多就容易 Full GC，导致压测结果失真。建议根据压测机配置适当调大：

export HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m" jmeter -n -t jmx/order_query_test.jmx -l result/result.jtl

6. 最佳实践与工程建议

6.1 Skill 资产要进版本管理

性能测试 Skill 不是一次性的。接口在变、业务模型在变，但底层的方法论和模板可以长期复用。建议把skill/目录纳入 Git 管理，每次执行压测前先明确当前 Skill 版本，压测报告里记录 Skill 版本号。这样即使过了半年，也能回头追溯某次压测是“在什么模板指导下做的”。

6.2 把参数外置，禁止硬编码

Skill 的 SKILL.md 和 Prompt 模板里都要写清楚：接口地址、端口、业务数据、阈值指标，全部通过参数传入，禁止写死在脚本或模板中。原因有两个：

• 每个项目的环境不同，硬编码会导致换环境后重新改脚本。
• 业务数据硬编码，压测会集中在同一份数据上，缓存命中率失真，结果没有参考价值。

6.3 冒烟验证必须是强制步骤

不要跳过冒烟测试直接上大并发。压测脚本的正确性验证成本极低，但出错成本极高。一旦用错误的脚本跑完一轮压测，不仅结果无效，还可能因为参数异常给服务端带来不必要的压力。

冒烟验证建议固定为三步：

1. 5 线程 1 次循环，确认请求成功。
2. 请求成功后再检查断言是否覆盖业务关键字。
3. 单线程重复 100 次，观察响应时间分布是否合理。

6.4 安全与授权边界

性能测试本身是一种“攻击性”测试行为，必须遵守安全边界：

• 只对已授权的测试环境或经批准的压测窗口执行压测。
• 不把压测请求指向未授权的第三方系统。
• AI 生成的脚本中如果涉及登录态、Token、密码等敏感信息，要使用环境变量或加密配置，不能明文写入 Git。
• 生产环境压测前必须走变更审批流程，提前确认降级预案和回滚方案。

6.5 结果归档与对比

每轮压测的结果文件、日志、脚本、Skill 版本、监控截图，建议按以下格式归档：

result/ └── 2025-04-10_order_query ├── jmx/ ├── jtl/ ├── html_report/ ├── logs/ └── summary.md

summary.md里至少包含：压测目标、压测环境、最终指标、是否达标、瓶颈分析、优化建议。方便后续多轮对比。

6.6 定期更新 Skill

Skill 里沉淀的经验不是一次写死就永远正确的。随着业务和技术栈变化，需要定期更新：

• 新增的断言模式有没有收录？
• 新的监控连接方式有没有补充？
• 之前踩过的坑有没有写进常见问题表？

把 Skill 当作一个内部知识库来运营，而不是一个一次性脚本集。

7. 总结与下一步建议

这篇文章从“AI 做性能测试为什么容易翻车”切入，核心目的是帮大家把 AI 辅助性能测试从“让 AI 写一段脚本”升级为“用 Skill 封装经验、驱动全链路执行”。读完之后，你应该能理解 Skill 机制的本质，能自己搭建一套包含 SKILL.md、Prompt 模板、JMeter 模板和分析脚本的性能测试技能包，也能跑通脚本生成、冒烟验证、正式压测、结果分析这一条完整链路。

下一步可以往三个方向继续深入：

• 把性能测试 Skill 扩展成支持分布式压测的版本，解决单机压测机瓶颈问题。
• 结合 Prometheus 和 Grafana 做应用指标联动分析，进一步提升瓶颈定位效率。
• 将沉淀的 Skill 推广到团队，统一性能测试规范和报告模板。

最后给一个实用建议：不要急着把 Skill 做得大而全，先找出团队最近半年最常做的一类接口压测，围绕这个场景写一个最小可用版本，跑通之后再逐步补充。同时记得，AI 生成的所有内容都要经过人工审核，尤其是在断言、参数化、安全边界这三个地方，不要盲目信任输出结果。