背景

最近看到 TesterHome 社区孙高飞老师分享的《AI 提效：编写性能测试的 skills 实战》，文章基于 CodeBuddy + Locust 构建了一套完整的性能测试 Skill。核心思路是三层架构：

• SKILL.md：工作流大脑，定义意图识别和流程分支
• scripts/：稳定可复用的原子脚本，避免大模型每次自由发挥
• references/：Cookbook 参考手册，约束动态生成脚本的质量

这个思路非常好。但我们团队用的是 k6 而不是 Locust，所以我基于 Kiro IDE 的 Skills 机制，参考原文方案做了一版 k6 适配和优化，并实际跑通了一个压测场景。下面分享整个过程。

---

一、方案设计：从 Locust 到 k6 的优化

直接照搬原文方案到 k6 是不合适的，k6 有自己的生态优势。我做了以下关键优化：

优化点	原文（Locust）	优化后（k6）
脚本语言	Python	JavaScript（k6 原生）
指标上报	手动 fire_success/fire_failure	k6 内置 Trend/Counter/Rate/Gauge
负载模型	Locust User 类	k6 Scenarios（constant-vus/ramping-vus/constant-arrival-rate 等）
数据驱动	自己实现 Queue 消耗方案	k6 原生 SharedArray
通过/失败判定	人工看数据	k6 Thresholds 自动判定
数据准备脚本	Python	Node.js（与 k6 统一 JS 生态）
新增能力	无	场景模板（templates/）+ 结果分析流程

其中最关键的是 Thresholds 自动判定——脚本自带通过/失败标准，跑完 k6 自动出结论，退出码 0 表示通过、99 表示失败，天然适合 CI/CD 集成。

---

二、Skill 目录结构

最终构建的 Skill 目录如下：

.kiro/skills/k6-perf-test/
├── SKILL.md                          # 工作流定义（大脑）
├── assets/                           # 运行时资产文件
│   └── test-results/                 # 压测结果输出
├── references/                       # 参考手册
│   ├── k6-cookbook.md                 # k6 脚本编写 Cookbook（核心）
│   └── api-notes.md                  # API 接口说明
├── scripts/
│   ├── data-prep/                    # 数据准备脚本（Node.js）
│   │   ├── create-spaces.mjs
│   │   ├── create-apps.mjs
│   │   ├── create-users.mjs
│   │   ├── add-users-to-space.mjs
│   │   └── utils/                    # 公共工具（api-client/asset-store/batch-runner）
│   └── k6/                           # 开箱即用的 k6 压测脚本
│       ├── http-api-perf.js          # 通用 HTTP API 压测模板
│       ├── list-app-perf.js          # 查询应用列表
│       ├── list-space-perf.js        # 查询空间列表
│       └── helpers/                  # 可复用辅助模块（auth/metrics/data-loader）
└── templates/                        # 场景模板
    ├── scenario-constant-vus.js      # 恒定并发
    ├── scenario-ramping.js           # 阶梯加压
    └── scenario-arrival-rate.js      # 恒定 RPS

沿用了原文的三层架构，同时新增了 templates/ 目录。k6 的 Scenarios 模式是有限且固定的（5 种），直接提供模板比纯 Cookbook 文字描述更精确，AI 可以直接基于模板修改而不是从零生成。

---

三、SKILL.md 的工作流设计

SKILL.md 定义了 4 个入口和 3 个流程：

入口 A：用户说"我要做性能测试"（意图模糊）→ 询问确认 → 分流
入口 B：用户明确要求组装脚本 → 直接进入流程 2
入口 C：用户明确要求数据准备 → 直接进入流程 1
入口 D：用户提供了压测结果文件 → 直接进入流程 3（结果分析）

流程 2（组装 k6 脚本）的核心步骤：

1. 收集需求：压测场景、负载模型、通过/失败标准
2. 参考 Cookbook 编写脚本：按 k6-cookbook.md 的规范生成独立脚本
3. 询问是否执行
4. 执行并输出结果

流程 3（结果分析）是相比原文新增的——读取 k6 JSON summary，生成可读报告，对比 Thresholds 判定是否通过。

---

四、k6-cookbook.md：Skill 的灵魂

Cookbook 是整个 Skill 最关键的文件，共 11 章，覆盖了 k6 脚本编写的方方面面：

1. 脚本整体结构（标准骨架：import → options → setup → default → teardown）
2. 环境变量与常量配置（__ENV 读取模式）
3. 鉴权与签名（HMAC-SHA256 的 k6/crypto 实现）
4. HTTP 请求与响应处理（check 模式、SSE 流式解析、文件上传）
5. 业务 API 层（按需复制的代码片段）
6. 自定义指标定义（Trend/Counter/Rate/Gauge + 命名规则）
7. Thresholds 配置模式（P95/P99、错误率、按 tag 分组）
8. Scenarios 负载模型（5 种 executor 的完整示例）
9. 数据驱动（SharedArray + JSON/CSV + 数据耗尽自动停止）
10. 工作流编排模式（setup/teardown、group、fail-fast）
11. 运行方式与结果输出（headless、JSON summary、HTML 报告、CI/CD）

有了这份 Cookbook，AI 生成的脚本就不会天马行空，而是严格遵循规范。

---

五、实战：压测获取 App 接口

Skill 构建完成后，我直接用自然语言发起了一次压测：

"我要对 https://staging.xxxxxxxxxx.cn/ 的获取 App 接口进行压力测试"

AI 按照 SKILL.md 的流程 2 开始收集需求，我提供了：

• 负载模型：恒定并发，10 个 VU 跑 1 分钟
• 通过标准：响应时间 < 500ms，错误率 = 0%
• 鉴权方式：Bearer Token
• 接口路径：/form/api/project/list-with-permission

AI 参考 Cookbook 生成了完整的 k6 脚本：

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE_URL = __ENV.BASE_URL || 'https://staging.xxxxxxxxxxxx.cn';
const TOKEN = __ENV.TOKEN || '';

export const options = {
  insecureSkipTLSVerify: true,
  scenarios: {
    constant_load: {
      executor: 'constant-vus',
      vus: parseInt(__ENV.VUS || '10'),
      duration: __ENV.DURATION || '1m',
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate==0'],
    checks: ['rate==1'],
  },
};

export default function () {
  const res = http.get(`${BASE_URL}/form/api/project/list-with-permission`, {
    headers: {
      'Authorization': TOKEN,
      'Content-Type': 'application/json',
    },
    tags: { name: 'list-app-with-permission' },
  });

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response has data': (r) => {
      try {
        const body = r.json();
        return body !== null && body !== undefined;
      } catch (e) {
        return false;
      }
    },
    'response time < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1);
}

执行过程中遇到了一个小插曲：staging 环境的 SSL 证书过期了，所有请求都因 TLS 验证失败而报错。AI 自动识别了问题，在 options 中加上 insecureSkipTLSVerify: true 后重新执行，顺利跑通。

---

六、压测结果

█ THRESHOLDS

  checks
  ✗ 'rate==1' rate=99.33%

  http_req_duration
  ✓ 'p(95)<500' p(95)=289.23ms

  http_req_failed
  ✓ 'rate==0' rate=0.00%

█ TOTAL RESULTS

  ✓ status is 200
  ✓ response has data
  ✗ response time < 500ms
    ↳  98% — ✓ 490 / ✗ 10

  HTTP
  http_req_duration..: avg=215.47ms min=182.22ms med=202.63ms max=544.32ms
                       p(90)=239.27ms p(95)=289.23ms
  http_req_failed....: 0.00% (0 out of 500)
  http_reqs..........: 500   8.19/s

AI 给出的结果分析：

指标	结果	判定
总请求数	500	-
RPS	8.19 req/s	-
错误率	0.00%	✅ 通过
平均响应时间	215.47ms	-
P90	239.27ms	-
P95	289.23ms	✅ 通过（< 500ms）
最大响应时间	544.32ms	-
响应时间 < 500ms	98%（490/500）	有 10 个请求超标

结论：接口整体表现不错，P95 在 289ms，错误率为 0。但有 10 个请求（2%）响应时间超过 500ms（最大 544ms），导致 checks 的 100% 通过率阈值未达标。这些慢请求可能是偶发的后端延迟或冷启动导致的。

---

七、总结与思考

三层架构确实有效

原文提出的 SKILL.md + scripts + references 三层架构，迁移到 k6 后依然成立：

• SKILL.md 负责流程编排和意图识别，是 Skill 的大脑
• scripts/ 保证历史验证过的方案能稳定复用
• references/cookbook 约束 AI 动态生成脚本的质量，避免天马行空

k6 相比 Locust 的优势

在 Skill 场景下，k6 有几个天然优势：

1. Thresholds 自动判定：脚本自带通过/失败标准，不需要人工看数据
2. SharedArray 数据驱动：原生支持，不需要自己实现 Queue 消耗方案
3. Scenarios 机制：5 种 executor 覆盖了几乎所有负载模型，模板化非常方便
4. 单文件独立：k6 脚本天然就是单文件 + 内置模块，不需要额外约束

新增的 templates/ 目录很实用

k6 的 Scenarios 模式是有限且固定的，直接提供模板文件比纯 Cookbook 文字描述更精确。AI 基于模板修改比从零生成靠谱得多，这是对原文方案的一个有效补充。

从"对话"到"一句话压测"

整个过程从提出需求到拿到压测报告，只需要几句自然语言对话。Skill 的价值在于把性能测试的专业知识沉淀下来，让 AI 每次都能按照最佳实践执行，而不是每次自由发挥。

---

本文基于 Kiro IDE 的 Skills 机制实现，参考了 TesterHome 社区孙高飞老师的原文方案。感谢原作者的分享。