benchmark
作者 affaan-m使用 benchmark 技能來量測效能基準、在 PR 前後偵測回歸，並比較頁面、API 與建置之間的技術棧替代方案，協助進行 Performance Optimization。
這個技能的評分是 67/100，代表可以列入目錄供使用者參考，但在實作上仍有明顯缺口。倉庫已足夠清楚說明何時該使用 benchmarking，以及要在頁面、API 與建置效能上量測哪些指標，因此代理程式多半能正確觸發。不過，使用者應預期需要自行提供工具選擇、命令與報表流程，因為這個技能比較像一套量測框架，而不是完整可直接執行的操作配方。
- 觸發條件明確："When to Use" 章節清楚界定了 PR 前後檢查、建立基準、排查變慢、上線準備與技術棧比較等情境。
- benchmarking 覆蓋完整：它列出了頁面效能、API，以及建置／開發迴圈效能的具體指標，包括 Core Web Vitals 與延遲百分位數。
- 對代理程式很有幫助：編號式量測步驟與目標門檻，提供了比泛用效能評估提示更明確的結構。
- 操作層面的清晰度有限：技能提到 browser MCP 與 benchmarking 模式，但沒有提供安裝命令、支援檔案或可直接執行測試的具體命令範例。
- 信任與採用深度普通：沒有腳本、參考資料、資源或配套素材可證明可重複的工作流程或範例輸出。
基準測試 skill 概覽
benchmark skill 的用途
benchmark skill 可協助你建立效能基準、找出回歸，並用可重複的流程比較不同方案，而不是臨時性地東看西看。它是為了在 benchmark for Performance Optimization 情境下使用，適用於網頁、API、建置流程，以及變更前後的比較。
適合安裝這個 benchmark skill 的對象
這個 benchmark skill 特別適合工程師、技術主管，以及需要證據來判斷「是不是變慢了？」或「這個 PR 有沒有提升效能？」的 AI 輔助開發者。當你在上線前、使用者抱怨之後，或評估技術棧變動時，需要一套共同的量測方法，它尤其有用。
相較於一般提示詞，benchmark skill 的價值
一般提示詞可能只會叫代理程式「檢查效能」。這個 skill 更好，因為它提供了具體的基準測試框架：像是 Core Web Vitals 和頁面重量這類頁面指標、API 延遲百分位數與併發檢查，以及建置與測試耗時這類開發迴圈指標。這種結構能減少猜測，也讓輸出更容易長期比較。
如何使用 benchmark skill
安裝情境與先看什麼
進行 benchmark install 時，先從包含 skills/benchmark 的 repo 安裝這個 skill，然後先打開 SKILL.md。在這個案例中，skill 是自包含的，所以大部分可直接使用的指引都在那個檔案裡。建議依照以下順序閱讀：
SKILL.md- “When to Use” 區段
- 與你的任務相符的模式：page、API、build，或 before/after comparison
benchmark skill 需要哪些輸入
要把 benchmark 用得好，關鍵在於提供真實的目標與成功標準。實用的輸入包含：
- 目標 URL 或 API endpoint
- 環境：local、staging、preview、production
- 測試中的變更：branch、PR、commit，或 stack 選項
- 預期目標：LCP、INP、p95 latency、build time、bundle size
- 測試限制：auth、seed data、region、device 假設
較弱的提問是：「幫我 benchmark 我的 app。」
更強的提問是：「對這 3 個 staging URL 使用 benchmark skill，收集 LCP/CLS/INP、頁面重量和 request 數，然後和 production 比較，標出超過 10% 的回歸。」
把粗略目標改寫成更強的 benchmark 提示詞
benchmark 指南可以用這種提示詞模板：
- 範圍： page、API、build，或 before/after
- 目標： 精確的 URL、endpoint、命令或 branch
- 指標： 要量測什麼，以及門檻是多少
- 比較： baseline vs candidate
- 輸出： 摘要表、回歸、可能原因、下一步行動
範例：
「請使用 benchmark skill 比較這個 PR branch 和 main。針對頁面效能，測試 preview deployment 上的 /、/pricing 和 /checkout。回報 LCP、FCP、CLS、INP、TTFB、總頁面重量、JS 重量，以及 request 數。請標出超過 5% 的回歸，並提出前三項修正建議。」
能提升輸出品質的實務流程
高訊號的 benchmark usage 流程是：
- 一開始先只選一種模式。
- 在穩定環境建立 baseline。
- 用變更後的版本跑相同 benchmark。
- 要求比較表與回歸摘要。
- 最後才要求診斷與最佳化建議。
這個順序很重要。如果你跳過 baseline，代理程式可能會產生看起來合理、但可信度不高的建議。如果結果波動很大，就縮小範圍，只測更少的目標，並在更受控的條件下重複測試。
benchmark skill FAQ
benchmark skill 適合頁面、API，還是建置？
三者都適用。這個 skill 明確涵蓋頁面效能、API 效能，以及建置／開發迴圈效能。這讓它比只看 Lighthouse 的流程更廣，也更適合效能問題同時出現在前端、後端與工具鏈時使用。
什麼時候該用 benchmark，而不是一般效能提示詞？
當你需要可重複的量測、變更前後比較，或偵測回歸時，就該用 benchmark。一般提示詞適合腦力激盪最佳化想法，但這個 skill 更適合真正的工作重點是量測，而不是意見判斷的情境。
benchmark skill 適合新手嗎？
適合，只要你能提供清楚的目標即可。你不必事先知道每一個指標，但你應該知道要 benchmark 什麼，以及在哪裡 benchmark。新手最容易從單一頁面或單一 endpoint 開始，等第一次執行結果看得懂之後再擴大範圍。
什麼情況下不太適合？
如果你只是想了解一般效能概念，而不是要做量測，那就先別用這個 benchmark skill。當你的環境太不穩定，無法比較不同執行結果，或你無法提供可存取的 URL、可呼叫的 endpoint，或可執行的建置命令時，它也不是很適合。
如何改善 benchmark skill
提供更乾淨的輸入，讓 benchmark 結果更好
最有效的改善方式就是提升輸入品質。對於 benchmark for Performance Optimization，請明確指定：
- 精確的目標
- production 或 staging 環境
- baseline 與 candidate 版本
- 對團隊重要的門檻
- 任何必要的 auth／設定
「幫我們 benchmark API」太模糊。
「在 staging 上對 POST /search 和 GET /products/:id 做 100 次請求、10 個併發，並對照我們 300ms 的 p95 SLA 回報 p50/p95/p99」就很可執行。
避開常見的 benchmark 失敗模式
常見問題包括：
- 在不同環境之間做比較
- 把多個變更混在同一次測試裡
- 使用不具代表性的頁面或 endpoint
- 還沒量測就先要求診斷
- 沒有定義可接受的回歸門檻
這些失誤會讓 benchmark 輸出雜訊變大，也更難信任。先把測試設定控制好，再來解讀結果。
要求比較，不要只看單一數字
單一指標截圖不如相對變化有用。你可以透過以下要求，改善 benchmark skill 的輸出：
- baseline vs candidate 表格
- 百分比變化
- 是否通過門檻
- 只針對前幾個回歸項目推測原因
這會把代理程式從單純倒資料，推進到能支援決策的層次。
第一次 benchmark 跑完後要持續迭代
第一次跑完後，請收斂範圍。可以要求代理程式只重跑最慢的頁面、最差的 API 百分位數，或最重的 build 步驟。接著再提出更聚焦的後續問題，例如「請專注於 render-blocking assets」或「調查為什麼 p99 遠比 p50 差」。這種迭代式流程正是 benchmark guide 最有價值的地方，因為它能把一次廣泛的量測，轉成實際可執行的最佳化計畫。