很多团队在接触 AI 生成性能测试脚本之后第一反应都是“真快”但真正把脚本放进 JMeter 跑完一轮压测才发现数据根本不敢拿给业务看。问题不出在 AI 不会写代码而出在性能测试本身就不是“生成一段脚本”就结束的事。本文会用 Skill 的思路把性能测试从需求梳理、脚本生成、执行压测到结果分析整条链路串起来讲清楚每一步怎么做、为什么这么做以及如何让 AI 在你的流程里真正发挥作用而不是把你带沟里。1. 先泼盆冷水AI 做性能测试为什么容易翻车这两年 AI 辅助测试的话题热度一直很高尤其是让 AI 生成 JMeter 脚本、生成压测报告这类操作几乎成了性能测试领域的标配玩法。但冷静下来看AI 在性能测试里真正能稳定交付的部分其实比想象中要窄。如果只是把需求丢给 AI让它“写一个登录接口的压测脚本”产出的东西大概率能跑但跑出来的结果不一定有意义。1.1 有脚本不等于能压出有效数据性能测试和功能测试最大的区别在于功能测试关注“对不对”性能测试关注“快不快、稳不稳、资源够不够”。这导致性能测试脚本的编写要求比功能测试脚本高得多。一段能让 AI 五分钟生成的 JMeter 脚本通常只包含一个 HTTP Sampler最多加一个查看结果树。但真实的性能测试脚本需要具备参数化不能用同一个账号、同一份数据疯狂并发否则服务端缓存、数据库连接复用都会干扰结果。关联登录后要提取 token后续接口要带上 token否则压的接口全是 401。断言不是“收到响应就算成功”要校验响应码、业务码甚至关键字段值。场景控制并发数、Ramp-up 时间、持续时长、是否阶梯加压这些参数直接影响压测结论。AI 在不了解业务上下文的情况下很难把这些细节一次做对。它会给出一段语法正确、结构完整的脚本但脚本里缺少参数化、缺少断言甚至把“成功”简单定义为 HTTP 200。这样的压测结果平均响应时间可能很好看但完全不能反映真实业务。1.2 AI 的结果分析容易给你虚假的安全感很多 AI 工具在压测结束后会基于 JTL 文件生成一段结论常见写法是“平均响应时间 120ms吞吐量 800 QPS系统性能表现良好。”这句话的问题很大。性能测试分析绝对不能只看平均值。真实场景下一个接口 90% 的请求耗时 80ms但 10% 的请求耗时 2 秒平均值可能是 272ms。这个平均值掩盖了长尾延迟问题而长尾直接决定用户体验。正确分析至少要看 P90、P95、P99还要结合错误率、吞吐量、资源使用率一起判断。AI 做结果分析还有一个致命问题它非常善于“顺着结论找证据”。如果你在提问时说“这个系统应该没问题”AI 很容易从数据里挑出支持这个判断的指标。这种确认偏误在性能分析和性能调优场景里是非常危险的。性能测试报告是决策依据不能建立在被美化的数据上。1.3 缺少人工评审和流程约束性能测试行业有一个共识压测报告的结论决定了系统能不能上线、要不要扩容、是否需要优化架构。这是一件必须对结果负责的事。AI 可以帮你写脚本、帮你算指标、帮你整理报告模板但它无法替代测试工程师对业务的判断。说到底AI 在性能测试中的合理定位是“加速器”不是“决策者”。脚本要有人评审数据要有人复核结论要有人负责。Skill 这套机制的核心理念正好是把这种“人工约束”固化到 AI 的工作流程里让 AI 输出的每一步都经过规则校验。2. 什么是 Skill它和普通提示词有什么区别最近在 AI Agent、AI 编程助手领域“Skill”这个概念出现频率越来越高。这里说的 Skill不是传统意义上的技能树而是指一种结构化的指令包。2.1 Skill 的通俗定义一个 Skill 本质上是一个文件夹里面包含一份SKILL.md说明文件以及配套的脚本模板、代码示例、检查清单、参考文档。AI 在收到相关请求时会读取这份说明文件按照里面定义的规则去执行任务。举个例子。普通提示词是“你是一个性能测试专家请帮我写一个登录接口的压测脚本。”Skill 驱动的方式是调用“性能测试助手”这个 SkillAI 会先读取SKILL.md里面明确规定第一步要确认测试目标、并发模型、业务场景。第二步要生成符合参数化、关联、断言规范的脚本。第三步要输出脚本评审清单。第四步要按规范执行压测并输出统一格式的报告。可以看到Skill 不只是给 AI 一个角色设定而是给 AI 一套可执行的流程和规则。它把“经验”结构化成了 AI 能稳定执行的工作流。2.2 与普通提示词的区别普通提示词的效果严重依赖提问者描述得够不够详细。问题是新手根本不知道性能测试脚本需要哪些细节提问时自然漏掉关键信息。AI 就像一个能力很强但没有主见的新人你不告诉它要参数化它就真的不做参数化。Skill 则把这条约束前置了。只要调用了 SkillAI 就必须遵守说明文件里写好的规则即使用户没有主动提到参数化AI 也会在流程中主动检查。这种“把经验固化到机制里”的思路正好解决了 AI 做性能测试最大的痛点。另外Skill 具有可复用性和可版本管理性。同一个团队可以维护一套统一的性能测试 Skill所有成员共享同一套规范。规范更新了团队里所有人用到的都是最新版本不会出现“张三的脚本规范、李四的脚本随意”这种问题。2.3 为什么性能测试特别适合 Skill 化性能测试是非常适合 Skill 化的领域原因有三点第一性能测试流程相对固定。需求分析、场景设计、脚本开发、执行压测、结果分析、报告输出这个链路在绝大多数项目中是一致的适合固化成标准流程。第二性能测试有大量可沉淀的模板。JMeter 脚本模板、JTL 分析脚本、报告模板这些都可以放在 Skill 目录里复用。第三性能测试对规范性要求极高。一个断言写错、一个参数没做关联整个压测结论就可能失效。Skill 里的检查清单能在 AI 输出结果时强制逐项校验降低低级错误概率。3. 环境准备与项目目录在开始实现 Skill 之前先把环境准备好。本文的示例以常见环境为主重点演示配置思路实际使用时可按照你的项目情况调整。3.1 环境清单建议准备以下环境组件说明JMeter 5.x性能测试工具本文示例以 5.6.x 为例JDK 8 或 11JMeter 依赖 Java 运行环境Python 3.8用于编写结果分析脚本pandas / matplotlibPython 数据分析与图表库执行pip install pandas matplotlib安装这里强调一点不同 JMeter 版本的脚本兼容性整体较好但插件版本、报告样式可能存在差异。比如 JMeter 5.5 和 5.6 在 HTML 报告生成逻辑上基本一致但如果你用了第三方插件就需要单独确认插件版本。遇到问题时优先检查 JMeter 版本和插件版本的匹配关系。3.2 JMeter 安装验证安装完成后在命令行执行jmeter -v如果能正常输出版本信息说明环境没有问题。JMeter 的 GUI 模式用于脚本调试压测执行建议使用非 GUI 模式。3.3 项目目录设计整个 Skill 项目建议按下面的目录结构组织performance-test-skill/ ├── SKILL.md # Skill 核心说明文件 ├── templates/ │ ├── standard_test.jmx # 标准 JMeter 脚本模板 │ └── report_template.md # 压测报告模板 ├── scripts/ │ ├── analyze_jtl.py # JTL 结果分析脚本 │ └── smoke_check.jmx # 冒烟脚本模板 ├── checklists/ │ └── review_checklist.md # 脚本评审清单 └── examples/ └── login_scene.md # 业务场景示例这个目录结构的好处是模板、脚本、清单各自独立团队成员可以分别维护AI 在生成内容时也能按需加载对应文件。4. Skill 核心实现把性能测试经验固化下来这一节是全文的关键。我们将完整实现一个“性能测试助手” Skill让 AI 按照规范流程工作而不是自由发挥。4.1 编写 SKILL.mdSKILL.md是整个 Skill 的入口文件AI 会优先读取它来理解任务规则。文件路径为performance-test-skill/SKILL.md--- name: performance-test-skill description: 基于 JMeter 的全链路性能测试辅助 Skill覆盖脚本生成、参数化、断言、压测执行与结果分析。 --- # 性能测试助手 ## 职责范围 本 Skill 用于协助工程师完成性能测试全流程工作包括 1. 测试需求梳理与场景设计 2. JMeter 测试脚本生成与评审 3. 压测执行与结果分析 4. 压测报告输出 ## 工作流 ### 第 1 步需求确认 在生成任何脚本之前必须与用户确认以下信息 - 被测接口路径、请求方法、请求参数 - 业务场景登录、下单、查询等 - 预计并发数或目标 TPS每秒事务数 - 压测持续时间 - 是否有生产环境流量数据参考 如果用户没有提供完整信息必须主动提问禁止直接生成脚本。 ### 第 2 步场景设计 根据需求确认结果输出测试场景设计包括 - 线程组配置并发数、Ramp-up、持续时间 - 参数化方案数据来源、关联方式 - 断言规则 - 监控指标 ### 第 3 步脚本生成 严格按照 templates/standard_test.jmx 的模板结构生成 JMeter 脚本。 必须包含 - 用户自定义变量 - 线程组配置 - HTTP 请求默认值 - 参数化配置CSV Data Set Config 或函数助手 - 断言 - 聚合报告或简单数据写入器 ### 第 4 步脚本评审 生成脚本后必须逐项检查 checklists/review_checklist.md 中的清单并向用户输出检查结果。 ### 第 5 步执行与结果分析 压测执行命令使用非 GUI 模式 jmeter -n -t {script}.jmx -l {result}.jtl -e -o {report_dir} 结果分析必须覆盖以下指标 - 吞吐量TPS/QPS - 平均响应时间 - 响应时间百分位P90、P95、P99 - 错误率 - 资源使用率如有监控数据 禁止只给平均值结论。 ### 第 6 步报告输出 按 templates/report_template.md 输出压测报告。这份SKILL.md看起来不长但它已经完成了三件关键的事一是把工作流拆成了固定步骤AI 不能跳过需求确认直接写脚本二是把规范写死在流程里参数化、断言、P99 这些指标变成“必须项”而不是“可选项”三是把人工评审嵌入到 AI 的输出流程中AI 生成脚本后必须逐项检查清单。这是普通提示词很难稳定做到的事情。4.2 编写标准 JMeter 脚本模板templates/standard_test.jmx是 AI 生成脚本时参照的模板。出于篇幅考虑这里展示核心 XML 片段实际项目中建议维护一份完整的可运行模板。先看测试计划的整体结构?xml version1.0 encodingUTF-8? jmeterTestPlan version1.2 properties5.0 jmeter5.6.3 hashTree !-- 测试计划 -- TestPlan guiclassTestPlanGui testclassTestPlan testname性能测试计划 enabledtrue elementProp nameTestPlan.user_defined_variables elementTypeArguments guiclassArgumentsPanel testclassArguments testname用户自定义变量 enabledtrue collectionProp nameArguments.arguments elementProp namebase_url elementTypeArgument stringProp nameArgument.namebase_url/stringProp stringProp nameArgument.valuehttp://127.0.0.1:8080/stringProp stringProp nameArgument.metadata/stringProp /elementProp /collectionProp /elementProp /TestPlan hashTree !-- 线程组 -- ThreadGroup guiclassThreadGroupGui testclassThreadGroup testname模拟用户线程组 enabledtrue intProp nameThreadGroup.num_threads50/intProp intProp nameThreadGroup.ramp_time10/intProp longProp nameThreadGroup.duration300/longProp boolProp nameThreadGroup.schedulertrue/boolProp /ThreadGroup hashTree !-- HTTP 请求默认值 -- ConfigTestElement guiclassHttpDefaultsGui testclassConfigTestElement testnameHTTP 请求默认值 enabledtrue stringProp nameHTTPSampler.domain${base_url}/stringProp stringProp nameHTTPSampler.port8080/stringProp stringProp nameHTTPSampler.protocolhttp/stringProp /ConfigTestElement !-- 后续在这里添加 HTTP Sampler、CSV 数据文件、断言等 -- /hashTree /hashTree /hashTree /jmeterTestPlan在真实使用中AI 需要在这个骨架基础上补充每个接口的 Sampler。为了规范 AI 的行为建议在 SKILL.md 中再明确几条硬性规则HTTP Sampler 必须使用${base_url}变量禁止硬编码域名和端口。涉及多个测试账号时必须使用 CSV Data Set Config 做参数化禁止所有线程使用同一账号。必须添加响应断言至少校验 HTTP 响应码为 200并同时校验业务响应码。必须添加“查看结果树”以外的监听器推荐使用“简单数据写入器”输出 JTL 文件避免 GUI 监听器在非 GUI 模式下影响性能。这些规则看起来是技术细节但它们恰恰决定了压测报告是否可信。4.3 编写脚本评审清单checklists/review_checklist.md是 AI 在生成脚本后必须对照检查的清单# JMeter 脚本评审清单 ## 基础项 - [ ] 测试计划中是否存在硬编码域名或端口 - [ ] 是否使用变量管理环境地址 - [ ] 线程组配置是否符合场景设计 ## 参数化 - [ ] 是否有多个测试账号 - [ ] 账号数据是否通过 CSV 或函数助手参数化 - [ ] 是否存在所有线程共用同一份数据的风险 ## 关联 - [ ] 接口是否需要登录鉴权 - [ ] 鉴权信息是否通过正则表达式提取器或 JSON 提取器关联 - [ ] 后续请求是否携带正确 token ## 断言 - [ ] 是否校验 HTTP 响应码 - [ ] 是否校验业务响应码 - [ ] 断言失败是否会影响最终错误率统计 ## 数据清理 - [ ] 是否避免压测产生脏数据 - [ ] 是否确认测试数据可回收或可隔离 ## 执行参数 - [ ] 是否配置了合理的 Ramp-up 时间 - [ ] 是否配置了压测持续时间 - [ ] 是否配置了 JTL 输出这份清单的价值在于它把人工评审的经验沉淀成了可重复执行的检查项。AI 每生成一个脚本都必须把这份清单逐项过一遍并把检查结果输出给用户。这比用户自己事后凭经验审核要可靠得多因为 AI 不会因为“赶时间”而跳过检查。4.4 编写结果分析脚本压测执行完成后JTL 文件是一堆原始数据不能直接拿来看。我们需要用 Python 写一个分析脚本提取关键指标。文件路径为performance-test-skill/scripts/analyze_jtl.py# 文件路径performance-test-skill/scripts/analyze_jtl.py import argparse import pandas as pd def analyze(input_file, label_fieldlabel, elapsed_fieldelapsed, success_fieldsuccess): 分析 JMeter 导出的 JTL 文件输出关键性能指标。 注意列名需要与 JMeter 的 jtl 输出配置保持一致。 df pd.read_csv(input_file, sep,) # 过滤掉空 label 或监控行 df df[df[label_field].notna()] # 按接口标签分组统计 result [] for label, group in df.groupby(label_field): total len(group) success_count group[success_field].eq(true).sum() error_rate 1 - (success_count / total if total 0 else 0) elapsed group[elapsed_field].astype(float) result.append({ 接口: label, 请求数: total, 错误率: f{error_rate * 100:.2f}%, TPS: f{total / (elapsed.max() - elapsed.min()) * 1000:.2f}, 平均响应时间(ms): f{elapsed.mean():.2f}, P50(ms): f{elapsed.quantile(0.50):.2f}, P90(ms): f{elapsed.quantile(0.90):.2f}, P95(ms): f{elapsed.quantile(0.95):.2f}, P99(ms): f{elapsed.quantile(0.99):.2f}, 最大响应时间(ms): f{elapsed.max():.2f}, }) result_df pd.DataFrame(result) print(result_df.to_string(indexFalse)) return result_df if __name__ __main__: parser argparse.ArgumentParser(description分析 JMeter JTL 文件) parser.add_argument(-i, --input, requiredTrue, helpJTL 文件路径) args parser.parse_args() analyze(args.input)这个脚本的输出包含接口维度、请求数、错误率、TPS、平均响应时间、P50、P90、P95、P99 和最大响应时间。有了这些指标才能对系统性能做出相对全面的判断。需要注意的是JMeter 的 JTL 文件列名并非固定不变它取决于你在jmeter.properties或测试计划中开启的字段。使用脚本前先确认 JTL 文件中确实包含label、elapsed、success这几列。如果不一致调整脚本里的字段名参数即可。5. 全链路实战从业务分析到报告输出Skill 文件准备好之后接下来我们把整条链路跑一遍。以一个典型的登录接口压测为例演示 AI 如何在这种流程约束下从需求分析一路走到报告输出。5.1 业务调研与测试目标在调用 Skill 之前首先要把测试目标定清楚。以登录接口为例需要明确以下信息被测接口POST /api/login请求参数username、password业务场景工作日早高峰登录预计同时在线用户数约 5000峰值阶段登录请求约 800 TPS压测目标接口在 1000 并发下P95 响应时间低于 500ms错误率低于 0.1%这个目标看起来简单但已经包含了关键信息并发数、目标指标、可接受的错误率。没有这些前置信息AI 生成的脚本就是无源之水。5.2 场景设计与并发模型确定测试目标后就要设计压测场景。常见的性能测试场景包括基准测试低并发如 10 线程跑 5 分钟验证脚本正确性和系统基线。负载测试逐步增加并发如 100、300、500、800、1000观察系统在不同负载下的表现。压力测试超过预期负载如 1500 甚至 2000找出系统的拐点。稳定性测试在合理负载下持续运行 30 分钟至数小时观察是否存在内存泄漏、连接泄漏。对于首次压测建议按“基准测试 → 负载测试 → 压力测试”的顺序推进。每次压测之后根据结果决定是否继续增加并发。AI 在 Skill 的约束下会把这些场景组织成可执行的测试计划而不是一上来就给你一个 1000 并发的脚本。5.3 AI 生成测试脚本按照 SKILL.md 的工作流AI 在确认完需求后应该输出类似下面的场景设计和脚本信息场景设计 - 基准测试10 并发Ramp-up 10 秒持续 60 秒 - 负载测试1100 并发Ramp-up 20 秒持续 300 秒 - 负载测试2300 并发Ramp-up 30 秒持续 300 秒 - 负载测试3500 并发Ramp-up 50 秒持续 300 秒 参数化方案 - 使用 CSV Data Set Config 加载 1000 个测试账号 - 所有线程从 CSV 文件循环读取 username/password - 登录成功后通过 JSON 提取器获取 token 断言方案 - HTTP 响应码必须为 200 - 响应 JSON 中的 code 必须为 0 - 响应 JSON 中的 token 字段不能为空有了这个设计AI 再生成 JMeter 脚本时每个配置项都有明确的来源。脚本中的线程组参数、CSV 文件路径、断言规则都能一一对应到场景设计上而不是凭空猜测。5.4 脚本冒烟与基准执行脚本生成后不能直接上高并发。先用小并发做冒烟验证确认脚本本身没有逻辑错误。执行命令如下# 冒烟验证10 并发跑 60 秒 jmeter -n -t login_smoke.jmx -l smoke_result.jtl -e -o smoke_report冒烟完成后查看smoke_report目录下的 HTML 报告重点确认所有请求是否成功。断言是否通过。是否做了真实的参数化不能出现所有请求都用同一个账号。响应时间是否符合预期。如果冒烟阶段就出现大量错误先把脚本问题解决不要急着跑正式压测。这就像开车之前先检查轮胎轮胎没气跑高速是会出大事的。5.5 正式压测执行冒烟通过后按场景设计依次执行压测。注意每次压测之间要留出足够的资源回收时间避免上一次压测的遗留连接影响下一次结果。执行命令示例# 负载测试500 并发持续 300 秒 jmeter -n -t login_load_500.jmx -l load_500_result.jtl -e -o load_500_report在压测执行过程中最好同时采集服务器资源监控数据。常用的监控指标包括 CPU 使用率、内存使用率、磁盘 I/O、网络带宽、数据库连接数、Tomcat 线程数等。这些数据在后续瓶颈定位时至关重要。5.6 结果分析与瓶颈定位压测结束后使用前面写的分析脚本处理 JTL 文件python scripts/analyze_jtl.py -i load_500_result.jtl预期输出类似接口 请求数 错误率 TPS 平均响应时间(ms) P50(ms) P90(ms) P95(ms) P99(ms) 最大响应时间(ms) /api/login 15000 0.02% 833.33 180.50 152.30 320.80 410.60 680.30 1200.50单看这组数据系统的平均响应时间只有 180msP95 是 410ms看起来是达标的。但 P99 已经到 680ms最大响应时间到了 1.2 秒说明存在明显的长尾延迟。如果目标要求 P95 低于 500ms那么当前结果算勉强达标但如果业务要求 P99 也低于 500ms这个系统就需要优化了。这个例子很好地说明了为什么不能只看平均值。如果你让 AI 直接总结它很可能会说“平均响应时间 180ms系统性能良好”但真实的长尾问题就被掩盖了。在 Skill 的规则里AI 被强制要求输出 P90、P95、P99这就能把长尾问题暴露出来。5.7 报告输出与上线决策最后一步是输出压测报告。报告不需要花哨但必须包含足够的证据链。建议的报告结构如下测试概述测试目的、测试时间、测试环境。测试方案并发模型、场景设计、数据准备。测试结果关键指标汇总表。瓶颈分析结合监控数据定位瓶颈。结论与建议是否达到上线标准、需要做哪些优化。Skill 的templates/report_template.md就是用来固化这个结构的。AI 将分析结果填入模板工程师只需要审核数据正确性而不是从零开始拼报告。6. 常见问题与排查思路在实际操作中AI 生成性能测试脚本并执行压测时会遇到各种问题。下面把高频问题整理成表方便排查。问题现象常见原因解决思路脚本能跑但请求全部失败缺少关联登录 token 未提取或未传递添加 JSON 提取器或正则表达式提取器调试时开启“查看结果树”所有线程使用同一个账号导致数据冲突未做参数化使用 CSV Data Set Config 加载多组账号数据压测结果错误率为 0但业务上请求实际失败断言缺失或断言过弱增加业务码字段断言确认响应 JSON 中的业务状态压测过程中 JMeter 本机 CPU 飙高监听器过多、聚合报告等 GUI 组件占用资源非 GUI 模式执行减少监听器使用简单数据写入器输出 JTLP99 明显高于 P95长尾严重存在慢请求、垃圾回收暂停、连接池耗尽结合监控数据定位慢请求阶段检查 GC 日志、数据库慢查询高并发时出现连接超时线程池满了、数据库连接池不够、带宽瓶颈逐步排查应用线程池、数据库连接池、网络出口多次压测结果波动很大压测环境不干净、存在定时任务干扰压测前清理环境关闭非必要定时任务固定压测时间窗口重点提醒两个问题。第一个是“错误率为 0 的假象”。很多 AI 生成的脚本只断言了 HTTP 200但后端业务返回码可能不是 0比如“账号被锁定”“密码错误”这类业务异常也返回 HTTP 200。这种情况下压测报告显示错误率为 0实际上大量请求都是业务失败。这是 AI 做性能测试时最危险的坑之一。解决办法是必须加入业务断言校验响应体中的业务状态码。第二个是“压测机成为瓶颈”。当你用单台机器跑到几千并发时JMeter 本身的性能可能成为瓶颈。如果压测机的 CPU 已经接近 100%压测结果反映的不是被测系统性能而是压测机自己的性能。遇到这种情况应改用分布式压测或者降低单机并发、增加压测机。7. 最佳实践与工程建议Skill 驱动下的 AI 性能测试最终还是要落到工程规范上。结合经验给出以下建议。7.1 脚本评审不可省略无论 AI 生成的脚本看起来多完整都必须经过人工评审。评审时对照评审清单逐项检查重点看参数化、关联、断言三块。尤其是 AI 生成的断言经常会“能通过但不全面”。建议在团队内建立“AI 生成脚本必须附评审清单”的约定把这一步固化成流程而不是靠个人自觉。7.2 测试数据与生产数据隔离性能测试一定会产生数据。压测时往生产库写入了脏数据是很多团队踩过的坑。建议在进入压测前先确认目标环境是不是独立的压测环境测试账号是否与生产账号隔离压测产生的订单、流水是否有对应的清理脚本。这部分 AI 帮不了你必须由工程师在环境层面把关。7.3 监控数据与压测数据配套压测结果分析不能只看 JMeter 的响应数据要结合被压服务器的监控数据一起看。CPU 到 90%、内存持续上涨、数据库连接耗尽这些现象往往能直接解释响应时间变长的原因。建议每次压测都同时记录监控数据并保存在压测报告的同级目录中方便复盘。7.4 使用 Skill 做保守输出在 Skill 的规则中应该明确要求 AI 在结论不确定时说明风险。比如“当前数据无法判断是否为性能瓶颈建议补充 XX 监控指标再分析”。这能有效避免 AI 盲目给出乐观结论。一个原则是AI 可以提出假设但结论必须由工程师审核。7.5 逐步推进压测不要一口气拉满新手最容易犯的错误是一上来就 1000 并发接口直接被打挂却不知道瓶颈在哪里。正确的做法是从低并发开始逐步加压每轮都记录关键指标找到系统的性能拐点。这个思路也应该写进 SKILL.md让 AI 默认按渐进式加压方案执行。7.6 善用版本管理Skill 目录本身应该纳入 Git 管理。模板更新、清单变更、分析脚本优化都要有记录。团队里任何人修改了规范其他人执行压测时自动使用新版本。这样可以避免“规范写在文档里实际执行靠心情”的情况。8. 写在最后AI 做性能测试本身不是坏事坏的是把 AI 当成一个不需要约束的性能测试工程师来用。Skill 的核心价值就是给 AI 一个清晰的流程边界和一套可执行的规则让它在固定的轨道上发挥生成能力同时把参数化、断言、长尾分析、人工评审这些关键环节牢牢锁住。本文从一个最常见的 AI 压测翻车场景说起讲清了 AI 做性能测试的局限性然后一步步实现了 SKILL.md、JMeter 模板、评审清单和分析脚本最后跑通了一条从需求分析到报告输出的全链路流程。到这里你应该能感受到AI 真正提升效率的部分恰恰是在流程和模板被固化之后它才能在不犯错的前提下帮你省时间。下一步你可以做两件事一是把本文的 Skill 结构套用到自己团队的接口和业务场景中补齐模板里的具体接口参数二是尝试进一步完善 SKILL.md比如加入分布式压测规范、依赖不同中间件Redis、MQ的监控采集规则。Skill 这种东西越贴近团队真实流程价值越大。如果你正在用 AI 辅助性能测试建议先别急着让它“自由发挥”给它一套规则你可能会发现它能比你想象的靠谱得多。