benchmark

benchmark 技能概览

benchmark 技能是做什么的

benchmark 技能帮助你用可重复的工作流来建立性能基线、发现性能回退、比较不同方案，而不是靠临时性的零散检查。它专为 benchmark for Performance Optimization 场景设计，适用于网页、API、构建流水线，以及变更前后对比。

哪些人适合安装这个 benchmark 技能

这个 benchmark 技能最适合工程师、技术负责人，以及借助 AI 开发的工程人员：当你需要回答“这里是不是变慢了？”或“这个 PR 到底有没有提升性能？”时，它特别有价值。尤其是在上线前、收到用户性能投诉后，或评估技术栈调整时，如果你需要一套团队可共享的测量方法，这个技能会很实用。

和通用提示词相比，它为什么更有用

普通提示词可能只会让智能体“检查一下性能”。而这个技能更强的地方在于，它提供了一套明确的 benchmark 框架：包括页面指标，如 Core Web Vitals 和页面体积；API 指标，如延迟分位数和并发检查；以及开发链路指标，如 build 和 test 耗时。这样的结构能显著减少猜测空间，也让不同时间点的结果更容易横向比较。

如何使用 benchmark 技能

安装时先看什么内容

进行 benchmark install 时，从包含 skills/benchmark 的仓库中添加这个技能，然后优先打开 SKILL.md。这个技能本身是相对自包含的，因此大部分可直接使用的指导都集中在这个文件里。建议按下面顺序阅读：

1. SKILL.md
2. “When to Use” 部分
3. 与你任务对应的模式：page、API、build，或 before/after comparison

benchmark 技能需要哪些输入

想把 benchmark 用好，前提是提供真实的测试目标和明确的成功标准。常见有效输入包括：

• 目标 URL 或 API endpoint
• 环境：local、staging、preview、production
• 被测变更：branch、PR、commit，或某个技术栈方案
• 期望目标：LCP、INP、p95 latency、build time、bundle size
• 测试约束：auth、seed data、region、device assumptions

一个较弱的请求是：“Benchmark my app。”
一个更强的请求是：“Use the benchmark skill on these 3 staging URLs, collect LCP/CLS/INP, page weight, and request counts, then compare against production and flag regressions over 10%.”

如何把模糊目标改写成高质量的 benchmark 提示词

给 benchmark guide 写提示词时，可以套用下面这个模板：

• Scope: page、API、build，或 before/after
• Targets: 精确的 URL、endpoint、command，或 branch
• Metrics: 要测哪些指标，以及目标阈值
• Comparison: baseline vs candidate
• Output: summary table、regressions、likely causes、next actions

示例：
“Use the benchmark skill to compare this PR branch against main. For page performance, test /, /pricing, and /checkout on the preview deployment. Report LCP, FCP, CLS, INP, TTFB, total page weight, JS weight, and request count. Call out any regressions above 5% and suggest the top 3 fixes.”

能提高输出质量的实用 benchmark 工作流

一个高信噪比的 benchmark usage 工作流通常是：

1. 一开始只选一种模式。
2. 先在稳定环境上建立 baseline。
3. 再对变更后的版本运行同样的 benchmark。
4. 要求输出 comparison table 和 regression summary。
5. 完成这些之后，再让它做诊断和优化建议。

这个顺序很重要。如果你跳过 baseline，智能体很可能会给出看似合理、但可信度不高的建议。如果结果波动很大，就先缩小范围，只测更少的目标，并在更可控的条件下重复执行。

benchmark 技能常见问题

这个 benchmark 技能适用于页面、API，还是构建流程？

三者都支持。这个技能明确覆盖 page performance、API performance，以及 build / developer-loop performance。所以它比只依赖 Lighthouse 的工作流更广，也更适合前端、后端和工具链多个环节都存在性能问题的场景。

什么情况下应该用 benchmark，而不是普通性能提示词？

当你需要可重复的测量、变更前后对比，或性能回退检测时，就应该用 benchmark。如果你只是想头脑风暴一些优化思路，通用提示词也够用；但如果真正的任务是“测量”而不是“发表看法”，这个技能明显更合适。

benchmark 技能对新手友好吗？

友好，前提是你能提供清晰的目标。你不需要一开始就懂所有指标，但至少要知道自己在 benchmark 什么、测的是哪里。对新手来说，最好的起步方式是先从一个页面或一个 endpoint 开始，等第一次结果能看懂之后，再逐步扩大范围。

哪些情况下它不适合用？

如果你只是想了解一般性的性能知识，而不是真的要做测量，就不建议用这个 benchmark 技能。如果你的环境波动太大，导致结果无法比较，或者你无法提供可访问的 URL、可调用的 endpoint、或可执行的 build command，它的适配度也会比较低。

如何改进 benchmark 技能的使用效果

用更干净的输入，拿到更好的 benchmark 结果

最有效的改进点就是输入质量。对于 benchmark for Performance Optimization，尽量明确说明：

• 精确目标
• 是 production 还是 staging 环境
• baseline 版本和 candidate 版本
• 团队真正关心的阈值
• 所需的 auth / setup

“Benchmark our API” 太模糊。
“Benchmark POST /search and GET /products/:id on staging with 100 requests, 10 concurrency, and report p50/p95/p99 against our 300ms p95 SLA” 才是可执行的请求。

避开常见的 benchmark 失败模式

常见问题包括：

• 比较了不同环境
• 把多个变更混在一次测试里
• 选了不真实的页面或 endpoint
• 还没完成测量就先要求诊断
• 没有定义可接受的性能回退阈值

这些问题都会让 benchmark 输出变得嘈杂，也更难让人信服。先把测试设置控制好，再去解读结果。

不要只看单点数字，要主动要求对比

单个指标的快照，价值通常不如相对变化。想提升 benchmark 技能的输出质量，建议明确要求：

• baseline vs candidate 对比表
• 百分比变化
• 相对于阈值的 pass/fail
• 只针对最严重回退项给出 suspected causes

这样可以把智能体从单纯“罗列数据”推向真正的决策支持。

在第一次 benchmark 之后继续迭代

第一轮跑完之后，就该收紧范围。你可以让智能体只重跑最慢的页面、最差的 API percentile，或最重的 build step。然后再提出更聚焦的后续请求，比如“focus on render-blocking assets”或“investigate why p99 is much worse than p50.” 这种迭代式循环，正是 benchmark guide 最有价值的地方，因为它能把一次宽泛的测量，逐步变成真正可落地的优化计划。