Claude Code 效能工程師 Subagent：抓瓶頸、量影響、給最佳化

功能能跑不代表跑得快。讓 Claude Code 多一個只做效能的子代理：profile 你剛改的程式、抓出瓶頸、量影響、給可驗證的最佳化。

[ 登入後可看完整內容 ]

## 這是什麼／解決什麼痛點 「功能能跑」和「功能跑得快」是兩件事。很多效能問題——N+1 查詢、漏掉的索引、把整包資料塞進 payload、忘了快取、記憶體緩慢洩漏——在開發機上小資料量看不出來，一上正式環境帶真實流量就爆。這個「效能工程師」子代理把效能審查也左移到功能開發當下：你寫完一段查詢或 API，叫它 profile 一輪，它會找出實際熱點、量測每個瓶頸的影響、按嚴重度分類，並給出附 before/after 的最佳化與預期改善幅度。 它最值得學的一條原則是「先量測再最佳化」——明確反對憑直覺猜哪裡慢的過早最佳化，並要求每個建議都可驗證、不犧牲正確性。這正是讓效能工作不流於玄學的關鍵。 ## 為什麼這來源值得用 wshobson/agents（Seth Hobson 維護，MIT 授權，GitHub 3.6 萬星以上）的 performance-engineer 把分析面向拆得很實在：程式 profiling（CPU 熱點/記憶體/I/O/async）、資料庫（N+1、索引、查詢計畫、connection pooling、ORM 陷阱）、API（回應時間、payload 瘦身、分頁、批次）、快取（cache-aside/read-through/write-through + TTL + 命中率）、記憶體（洩漏、GC、物件池）、並行（執行緒池、資源競爭）、前端（bundle、lazy loading、code splitting）、負載測試（K6/JMeter/Gatling）、可擴展性（水平 vs 垂直、stateless 驗證）。它規定的五步工作流（profile → 量影響 → 分類 → 給最佳化 → 驗證）與統一輸出格式（影響分級 + 位置 + 根因 + before/after + 取捨 + 基準估計），讓它的建議能直接被排進工作，而不是一堆「也許可以更快」的模糊感想。 ## 怎麼用（步驟） 1. 在專案建立 `.claude/agents/performance-engineer.md`，貼入 full_prompt 的規格。 2. 觸發：「用 performance-engineer profile X」。把已知的效能目標（p99 延遲、記憶體上限、QPS）一併給它，它會以此為 SLO 對齊建議。 3. 它會回傳分級後的瓶頸清單，每項附根因、before/after 修法與預期改善幅度。 4. 照「前 3 大優先項」先改，改完用它建議的驗證方式（或它幫你寫的 K6/JMeter 腳本）量測前後差異。 5. 把它建議的 SLO 寫進監控/告警，避免效能回退。 ## 何時用 - 寫完查詢、列表 API、報表、批次工作後，懷疑會慢或吃資源時。 - 收到「某頁很慢」「記憶體一直漲」的回報，要定位根因時。 - 上線前要對熱路徑做一次效能體檢、或要設計負載測試時。 - 不適合在還沒有可量測對象時拿它做純臆測——它的第一步就是「先 profile」，沒有可跑的程式或資料它也只能猜。 📎 來源：wshobson/agents（作者 Seth Hobson，MIT 授權）— 本篇為繁中改寫整理，原始內容見上方連結。