做接口压测这些年，我在 JMeter 里写过的脚本片段，加起来能绕线程组转三圈。BeanShell 断言、JSR223 前置处理器、Groovy 签名、参数化文件读取——每一样都是现用现搜，或者从旧项目里翻出来改。时间长了你会发现，真正花时间的不是压测本身，而是这些零碎脚本的编写和调试。后来我换了个思路：把这些脚本助手整理成一个可复用的 Skill，让 AI 直接照着写，我只需要负责审核和组装。
这个 Skill 不是玄学，也不是把一堆脚本打个包就完事。它是一套结构化的技能定义：告诉 AI 助手在什么场景下输出什么类型的 JMeter 脚本片段，包含哪些模板、遵守哪些规则、避开哪些坑。做完之后，我在项目里让 AI 生成 beanshell 断言、生成签名逻辑、生成随机测试数据，基本都是一次成型，改几行就能跑。这篇文章就把我的完整做法、踩过的坑、以及怎么把它做成团队可复用的资产，全部拆开讲清楚。
1. 为什么要把脚本助手做成了 Skill
1.1 散装脚本的痛，做过压测的人都懂
先说说我最早的状态。本地有一个文件夹叫 jmeter_scripts，里面按功能存了几十个 .txt 和 .jmx 文件，什么“登录态提取.jmx”“MD5签名.txt”“CSV参数化.txt”。看着挺全，但真到用的时候，问题一个接一个。
首先是找得慢。你记得自己写过“一个提取 token 的正则”，但想不起来放在哪个文件里，只能挨个打开翻。其次是改得乱。旧脚本里绑定的变量名、参数名跟新接口对不上，复制过去之后一堆报错。第三是没法保证质量。很多脚本是当年在某个特定版本、特定压测场景下写的，换了个 JMeter 版本或者换个接口风格，直接跑就失败。
我意识到，散装脚本的本质问题是：有内容，没结构。它们沉淀了经验，但没有沉淀“什么时候用哪段、怎么改、为什么这么写”。这些东西全在我脑子里，AI 帮不上忙，同事也用不上。
1.2 Skill 到底是什么，跟普通脚本库有什么区别
后来我开始用 AI 辅助写压测脚本，遇到一个新问题：AI 不是不会写，而是太爱自由发挥。你问它“帮我写个 BeanShell 断言”，它给你写一个能跑的；你再问一次，它给你写一个风格完全不同的。变量名一会儿 snake_case 一会儿驼峰，JSON 解析一会儿用 fastjson 一会儿用内置 JSONObject。每次都要人工校对，等于没省时间。
Skill 解决的就是这个问题。它不是脚本本身，而是给 AI 的一套“操作手册 + 模板库”。它告诉 AI：你遇到这类请求时，优先使用哪些模板；输出代码必须包含什么；不允许出现什么；变量名统一用什么风格。AI 还是那个 AI，但你给了它一个明确的边界和工作方式，产出就稳定了。
打个比方：普通脚本库等于扔给你一堆零件，Skill 等于给了一张图纸，外加装配要求和质检标准。我封装的就是这样一套东西：一面写“怎么做”，一面写“不许怎么做”。
注意：Skill 和 Agent 是两码事。Skill 是被调用的静态规则集，Agent 是能自主规划的执行体。这里做的不是 Agent，不需要常驻决策，只是让 AI 在收到指令时按照固定规范产出脚本。轻量、可控、没有额外的模型调用开销，这才是 Skill 适合做脚本助手的核心理由。
2. Skill 里都放了哪些核心内容
2.1 BeanShell 断言：压测场景里最刚需的一类
整个 Skill 里，断言脚本的模板数量最多，使用频率也最高。因为压测时最烦的不是造请求，而是写断言——尤其当你压的是内部系统，接口返回一堆 JSON，你只要判断其中某个业务字段是否正常。
我在 Skill 里内置了三个层级的断言模板，按需选用：
基础层：判断 HTTP 响应码和响应体是否为空。适合冒烟场景。
业务层：解析 JSON 并判断业务 code。这类最重要，因为 HTTP 200 不代表接口成功，很多系统业务失败时也返回 200。
数据层：从响应体中提取指定字段，与预期值比对。适合下单、查询等有明确返回值的接口。
业务层的模板长这样：
import org.apache.jmeter.assertions.AssertionResult; import com.alibaba.fastjson.JSON; import com.alibaba.fastjson.JSONObject; String body = prev.getResponseDataAsString(); if (body == null || body.isEmpty()) { Failure = true; FailureMessage = "响应体为空"; } else { try { JSONObject obj = JSON.parseObject(body); if (obj.getIntValue("code") != 0) { Failure = true; FailureMessage = "业务失败: " + obj.getString("msg"); } } catch (Exception e) { Failure = true; FailureMessage = "JSON解析失败: " + e.getMessage(); } }这里有一个值得注意的细节：模板里用的是prev.getResponseDataAsString()，而不是prev.getResponseData()。后者在 JMeter 5.x 里返回 byte 数组，处理中文时经常出现编码问题；前者直接拿到字符串，配合 UTF-8 就不会乱码。这个坑我在早期踩过好几次，所以直接写死在模板注释里，AI 生成时不会跑偏。
2.2 参数处理脚本：随机数、时间戳、加解密签名
接口压测跟功能测试最大的不同，是请求参数不能是写死的常量。每次请求都要不同的手机号、时间戳、随机字符串，有时还要按照接口规范做签名。这个工作量，手写几次还行，每次都让 AI 从零写就太浪费了。
Skill 里内置的参数处理模板，按用途分成几类：
随机数据生成。包括随机手机号、身份证号、订单号前缀 + 时间戳、UUID、指定位数的随机字符串。这些全部封装成短小的代码块，AI 在生成过程中可以直接引用。
时间戳处理。压测里经常遇到“当前时间戳 + N 天”这种需求。脚本里直接给出
System.currentTimeMillis()、Calendar加减、以及格式化输出的写法，避免 AI 每次瞎写导致时区错乱。加密签名。这是重头戏。现在接口基本都要验签，HMAC-SHA256 是最常见的。Skill 内置了标准模板：
import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.binary.Hex; String secret = "${sign_secret}"; long ts = System.currentTimeMillis() / 1000; String data = "appId=test&ts=" + ts; Mac mac = Mac.getInstance("HmacSHA256"); SecretKeySpec keySpec = new SecretKeySpec(secret.getBytes("UTF-8"), "HmacSHA256"); mac.init(keySpec); byte[] raw = mac.doFinal(data.getBytes("UTF-8")); String sign = Hex.encodeHexString(raw); vars.put("timestamp", String.valueOf(ts)); vars.put("sign", sign);这段脚本放在 JSR223 前置处理器里，用 Groovy 语言执行。为什么用 Groovy 不用 BeanShell？因为签名涉及加密库，Groovy 在 JMeter 5.x 里默认支持更好，import 路径不会因为 JDK 模块化出问题。这个选型也写在了 SKILL.md 的规则里，AI 不会自己去选 BeanShell。
2.3 前置处理与后置提取：让脚本串起来
单接口压测用不着太多前置后置，但一旦做业务流程压测——比如“登录 -> 下单 -> 支付”这种串行链路——脚本之间的参数传递就成了关键。
Skill 内置了后置提取的两大模板：正则提取器和 JSONPath 提取器。常规做法是前者匹配任意文本，后者专门处理 JSON。这里我要求 AI 在生成时优先推荐 JSONPath，因为 JSON 结构比正则好维护得多，尤其接口文档一更新，正则大概率就废了，JSONPath 改起来快很多。
提取到变量之后，下游接口直接用${token}引用，这个约定也写进了 Skill 规则。还有一个容易踩的坑：正则表达式里如果遇到$、.、\这些字符，必须转义，否则提取结果永远是空。模板注释里专门加了一行提醒。
{ "token": "$.data.token", "orderId": "$.data.orderId" }3. 从 0 到 1 构建一个可用的 Skill
3.1 Skill 的目录结构与命名规范
如果你只是想“让 AI 帮我写 JMeter 脚本”，那直接写一个长提示词就够了。但要做“可复用的 Skill”，必须有一套稳定的目录结构和命名规范，不然用几次就变成新的“散装脚本库”。
我的目录结构长这样：
jmeter-script-assistant/ ├── SKILL.md ├── templates/ │ ├── assertion/ │ │ ├── http_status.bhs │ │ ├── business_code.bhs │ │ └── field_compare.bhs │ ├── generator/ │ │ ├── random_mobile.groovy │ │ ├── timestamp_cal.groovy │ │ ├── hmac_sha256.groovy │ │ └── base64_codec.groovy │ ├── extractor/ │ │ ├── jsonpath_extract.groovy │ │ └── regex_extract.bhs │ └── common/ │ └── variable_conventions.md └── examples/ ├── business_flow_demo.jmx └── assertion_demo.jmx命名规范有两个要点：一是按功能分类，而不是按接口分类；二是文件和其中的代码必须具备“可迁移性”——不写死某个业务的变量名、接口地址、数据库连接串，全部用${}占位符表达。
提示：Skill 目录里不放 .jmx 压测工程文件，或者只放 demo 级别的简化示例。原因是 .jmx 是 XML 格式，AI 修改它很容易破坏结构，而且里面绑定了具体的线程数、监听器、环境信息，迁移成本太高。Skill 的核心产出是脚本片段，不是完整压测工程。
3.2 SKILL.md 怎么写才有效
SKILL.md 是整个 Skill 的灵魂。它不是说明书，而是给 AI 的“行为准则”。我前后改了很多版，最后发现有效的 SKILL.md 不需要长篇大论，但必须包含四个板块：能力边界、输出规则、模板索引、禁忌清单。
能力边界是告诉 AI 这个 Skill 管什么、不管什么。比如“本 Skill 只负责生成 JMeter 脚本片段，不负责搭建压测环境、不负责分析压测报告”。没有边界，AI 就会什么你都让它干，最后 Skill 逐渐膨胀成一坨分不清职责的杂物。
输出规则要落到非常细的操作层面。我写的规则包括：脚本必须包含完整 import；变量名统一使用 lowerCamelCase；线程组级别的变量用${var}引用，不能用vars.get("var")；时间戳一律使用毫秒并显式标注单位；涉及中文时统一使用 UTF-8 声明。
模板索引是给 AI 的目录指针。AI 在收到“写个签名”这样的指令时，应该先去templates/generator/下找 hmac_sha256.groovy，而不是凭空创作。这一点非常重要：Skill 的模板库是“参考答案”，AI 的默认行为是“自己写”，必须用索引把 AI 引导到参考答案上。
禁忌清单同样关键。我列的最多的两条：不允许使用System.out.println()作为输出方式，必须使用log.info()；不允许在 BeanShell 中用 JDBC 连接字符串方式拼 SQL，因为 JMeter 的变量替换时机导致 SQL 里的引号永远转义不对。
下面是 SKILL.md 的核心模板骨架：
# JMeter 脚本助手 ## 功能边界 - 生成与 JMeter 相关的脚本片段，包括断言、参数化、签名、提取 - 提供可直接粘贴到 JMeter 中的完整脚本，包含 import 与注释 - 不负责生成压测方案、不负责分析性能瓶颈 ## 输出规则 - 脚本使用 Groovy 或 BeanShell，优先 Groovy（JMeter 5.x 内置支持） - 所有业务可变项使用 ${} 占位符 - 中文输出统一 UTF-8，禁止硬编码编码格式 - 每个脚本必须包含使用说明注释：适用场景、依赖项、修改项 ## 模板索引 - 断言模板：templates/assertion/ - 数据生成模板：templates/generator/ - 参数提取模板：templates/extractor/ ## 禁忌清单 - 禁止使用 System.out.println 输出 - 禁止在 JSR223 中直接操作数据库连接 - 禁止在 BeanShell 中声明与 JMeter 内置函数同名的方法 - 禁止输出没有 import 的脚本片段3.3 必备的验证清单
Skill 做完不是直接丢给 AI 就完事，还要经过一套验证流程，确保 AI 基于这个 Skill 生成的脚本确实能用。我自己验证时，会拿一份真实接口文档，让 AI 按 Skill 生成脚本，然后逐个跑一遍。
验证清单里最核心的几条：
- 脚本能否被 JMeter 5.x 直接解析执行。特别检查 Groovy 引擎版本是否匹配，import 路径是否存在。
- 断言失败时能否给出明确的错误信息。很多 AI 生成的断言失败就是一句 "Assertion failed"，根本不知道哪里错了。Skill 要求失败时必须带有实际值和预期值。
- 中文字符是否乱码。在响应体断言场景里，如果
prev.getResponseDataAsString()用错，返回结果全是问号。 - 变量作用域是否正确。线程组之间传递的变量和线程组内传递的变量，在 JMeter 里作用域完全不一样，写错就取不到值。
这些验证不是每次都要跑全量，但至少在 Skill 的初版和新模板加入时，必须完整过一遍。版本一多你就会发现，脚本模板最大的风险不是写不出来，而是写出来跑不通，又因为“看着对”而直接进到压测里，最后整个测试结果作废。
4. 让 Skill 真正融入到工作流里
4.1 接入 AI 助手的方式
具体怎么接入，每个 AI 编程助手的方式不太一样。有些支持在项目根目录放一个说明文件作为全局上下文，有些支持单独引用某个 Skill 文件，还有一些支持把 Skill 做成插件在对话里直接激活。
我的做法是通用优先：把 SKILL.md 放在项目根目录，让 AI 助手在首次交互时就加载它。在文件顶部写一行“本仓库使用 JMeter 脚本助手 Skill，所有生成的压测脚本必须遵守 SKILL.md 规范”，这样整个对话过程都会受到约束。
如果你用的工具支持多文件上下文，还可以把 templates 目录作为附属资料让 AI 读取。有一个小技巧是把模板文件本身写成“带使用说明的代码”，而不仅仅是裸代码。比如 hmac_sha256.groovy 开头几行用注释说明适用场景、需要修改的参数、输出变量名，这样 AI 在读取模板时能更快理解使用方法。
接入之后，我的日常使用模式变成：先在对话里描述接口场景，AI 根据 Skill 自动生成脚本片段；我审查一遍关键逻辑后贴进 JMeter；跑一次验证，没问题再进入正式的压测计划。原来一个带签名的接口，从写脚本到跑通大概要半小时，现在压缩到五到十分钟，而且基本不用返工。
4.2 让 Skill 成为团队资产的可复用经验
单机版 Skill 是自嗨，能给别人用才是资产。要让 Skill 真正可复用，有几个经验非常关键。
第一个经验是把 Skill 当成代码来维护。放入 Git 仓库，每次更新都要写提交说明，谁改了模板、为什么改，都有迹可查。否则团队里几个人各自往里面加模板，最后 Skill 膨胀得连 AI 都找不到重点。
第二个经验是“模板贵精不贵多”。每次加模板之前先问自己：这个场景是不是足够通用？如果只是某个项目的一次性需求，那应该写到项目的 JMeter 工程里，而不是进 Skill。Skill 里每多一个模板，AI 在匹配时的选择成本就高一分。
第三个经验是版本与 JMeter 强相关。Skill 的 README 里明确标注“适用于 JMeter 5.4 及以上版本”，遇到升级 JMeter 大版本时，要重新跑一遍验证清单。最典型的例子是 JMeter 4 到 5 迁移时，很多 BeanShell 库的加载方式变了，不更新 Skill 的话 AI 生成的旧式脚本就会全部报错。
DISCLAIMER：不同 AI 产品对 Skill 的加载机制各不相同，迁移到新工具时不要强行照搬目录，先确认新的工具是否支持自定义上下文或技能文件。规则内容可以复用，但加载方式要看工具文档。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
在使用这个 Skill 的过程中，我和团队成员至少遇到过二十多种问题。这里把最高频的几类整理成一个速查表，按“症状 -> 原因 -> 处理”的顺序排列，方便以后直接查：
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| 断言一直失败，但接口返回正常 | 脚本里用的 JSON 解析库没引入，或者引错了包 | 检查 import 是否完整，BeanShell 下确认处于 JSR223 而不是 BeanShell Sampler |
| responseDataAsString 中文乱码 | JMeter 默认编码不对，或脚本里用了 getResponseData() 数组 | 统一用 getResponseDataAsString()，HTTP 测试计划采样器设置 UTF-8 |
| 生成的签名值服务端验签失败 | 时间戳单位不一致，签名原文拼接顺序错误 | 确认是毫秒还是秒，用 log.info 打印签名原文逐一核对 |
| 提取出来的变量在下一个请求取不到 | 变量作用域写错，或者后置处理器名称写错 | 检查 JSONPath 后置处理器放在取样器子节点还是同一层级 |
| 压测跑了一半脚本报编译错误 | 多个线程同时使用静态变量导致的问题 | 将静态变量改为 ThreadLocal，或在线程组中设置独立变量 |
| AI 生成的脚本每次都不同 | Skill 规则没加载，或者提示词里没引用 SKILL.md | 重新确认 SKILL.md 是否在工作目录，并在对话中明确“使用 JMeter 脚本助手 Skill” |
5.2 更隐蔽的坑，以及我总结的避坑技巧
速查表里的问题比较基础，下面这几个才是真正让人头痛的坑。
关于 JSR223 和 BeanShell 的选择，我的结论是：能用 Groovy 不用 BeanShell。BeanShell 在 JMeter 中的表现很不稳定，尤其是在 Java 17 以上的 JDK 环境下，反射访问受限导致内置变量vars、prev经常不可用。Groovy 从 JMeter 5.x 开始就是默认推荐语言，内置支持好，语法也更接近 Java。Skill 里的模板除了几个历史遗留的断言外，新模板全部换成了 Groovy 版本。
另一个容易忽略的细节是 JMeter 内置函数的断言时机。__time()这类函数在脚本执行前就已经被替换成字符串，所以你在 BeanShell 里引用${__time()}时，拿到的可能是一个旧值。更可靠的做法是在脚本内部用System.currentTimeMillis()获取时间，再通过vars.put()存到变量里供其他请求使用。这个坑在压测高并发场景下非常致命，因为${__time()}在每个线程里的取值时机会漂移。
多线程共享变量的坑也值得单独拎出来说。JMeter 的vars对象是线程独立的，这点很多人知道；但如果你在一个 BeanShell 里写了static变量来缓存数据，那就等于所有线程共享一份。高并发下面是典型的“看起来能用，跑起来全错”。压测一启动，多个线程同时写同一个静态变量，后面的请求全用到被覆盖的数据。Skill 里我专门加了一条规则：JSR223 脚本中禁止使用static关键字定义可变状态。
结语
做这个 Skill 的过程，本质上是一次“把自己的经验结构化”的练习。以前我说“我有一堆 JMeter 脚本”，现在我可以明确地说：我有一套规则、一堆模板、一组禁忌，AI 照着它能稳定地产出可用的脚本。这个转变带来的效率提升是实打实的，但我更看重的是另一件事——这套东西从我的个人经验变成了团队能共同维护的资产。新同事上手压测，不再需要靠翻我的聊天记录找脚本；我自己的工作量，也从“写代码”变成了“审代码和丰富模板”。
如果你也在做接口压测，我建议从最小版本开始，别一上来就搞大而全的 Skill。先把你最常用的三类脚本收进去，写好 SKILL.md，用两三个真实接口验证一遍，然后边用边加。过程中你一定会发现，真正有价值的不是那段脚本本身，而是你在 SKILL.md 里写下的那些“为什么”。每次有人踩坑，就补一条规则进去。半年之后回头看，这个 Skill 沉淀的东西，比你自己脑子里记得的要多得多。
