optimize

optimize skill 概覽

optimize skill 會做什麼

optimize skill 是一份專注在 UI 效能最佳化的實務指南。它會幫助 agent 診斷介面為什麼會讓人覺得載入慢、延遲、卡頓或整體偏重，並針對載入、渲染、動畫、圖片與 bundle 大小提出聚焦的修正建議。若你要的是 optimize for Performance Optimization，而不是一般性的程式碼檢查，這個 skill 就很適合。

誰適合安裝 optimize

如果你在做 web app、產品介面、landing page、dashboard，或各種互動式 frontend，而且需要把「感覺很慢」轉成可量測、可落地的改善方案，就應該安裝 optimize。它特別適合開發者、product engineer，以及已經看得出有性能問題、但還抓不準根因的 AI 輔助開發流程。

真正要解決的工作需求

使用者通常不想聽理論，他們真正想知道的是：

• 到底是哪裡慢
• 要怎麼量測
• 最可能的原因是什麼
• 哪些修正最值得先做
• 改完之後要怎麼驗證是否真的有改善

optimize skill 的設計就是圍繞這個流程，而不是提供一堆泛泛的效能建議。

這個 skill 和一般 prompt 有什麼不同

一般 prompt 很容易直接跳到猜測。optimize 的優勢在於，它會先做量測、瓶頸切分與優先級排序，再提出修正方向。這能降低過早最佳化的風險，也讓輸出對真實專案更能直接採用。

包含與不包含的內容

這個 skill 的定位很窄，但很實用：它提供一條結構化的 frontend 效能診斷與改善路徑。它不會在這個 repo snapshot 裡直接附上 scripts、benchmarks 或 framework-specific 自動化工具，因此你應該期待的是指引與決策支援，而不是開箱即用的完整工具鏈。

如何使用 optimize skill

optimize 的安裝與呼叫方式

使用以下指令安裝這個 skill：
npx skills add https://github.com/pbakaus/impeccable --skill optimize

安裝後，請直接要求你的 agent 使用 optimize，並指定目標範圍，例如某個頁面、流程、元件或 app 區域：

• Use optimize on our homepage load performance
• Use optimize for checkout jank on mobile
• Use optimize on the dashboard bundle size

第一次使用前，最佳安裝情境與準備

從 repo 可見的內容來看，目前只有 SKILL.md，所以比起研究 repo 結構，你實際提供的上下文更重要。在使用 optimize 前，建議先整理：

• 受影響的 URL、route 或 component
• 裝置情境：desktop、低階 mobile、慢速網路、特定 browser
• 症狀：載入慢、輸入延遲、掉幀、CLS、bundle 過大
• 你目前已經有的量測資料，例如來自 Lighthouse、DevTools、RUM 或 profiler 的輸出

如果沒有這些背景資訊，skill 仍然能幫忙，但建議會更廣泛，可信度也會比較低。

先讀這個檔案

請先從以下檔案開始：

• SKILL.md

因為這個 skill 本質上是單檔指南，沒有其他需要先研究的支援規則或資源。這對快速上手是好事，但也代表你在 prompt 裡需要提供更多和專案有關的具體證據。

optimize 需要哪些輸入才會表現得好

想讓 optimize usage 更有品質，關鍵在於具體證據。最理想的輸入包括：

• 目前的指標：LCP、INP/FID、CLS、FCP、TTI、FPS、memory、CPU
• 範圍：單一頁面、單一互動、單一動畫，或單一 build artifact
• 若已有懷疑，也可以提供可能原因
• 限制條件：不能做 framework migration、不能改 CDN、不能改 image pipeline 等
• 成功目標：像「把 mobile 的 LCP 降到 2.5s 以下」會比「讓它更快」好很多

把模糊需求改寫成有效的 optimize prompt

較弱的寫法：

• Make my app faster

較強的寫法：

• Use optimize on our React product page. Mobile Lighthouse shows LCP 4.1s, CLS 0.18, bundle is 1.2MB JS, hero image is 2.4MB, and filtering interactions feel laggy on low-end Android. Prioritize fixes by impact and implementation cost, explain likely causes, and suggest how to re-measure after each change.

這種寫法有效的原因是：

• 它定義了明確目標
• 它包含量測數據
• 它縮小了平台範圍
• 它要求的是優先排序，而不是丟一整包建議清單

一套實用的 optimize 工作流程

一份好的 optimize guide 通常會依照以下順序進行：

1. 先量測 baseline。
2. 把載入問題和執行期問題分開。
3. 找出最大的瓶頸。
4. 先做影響最大的修正。
5. 重新量測。
6. 之後再處理次要改善項目。

這正是這個 skill 最核心的建議：先量、再改、改完再量，不要盲目最佳化。

optimize 最擅長處理哪些問題

這個 skill 特別適合處理：

• 首次頁面載入很慢
• 圖片很多的頁面
• JavaScript 或 CSS payload 過大
• 互動反應遲鈍
• 動畫卡頓
• layout thrashing 與 reflow 造成的卡頓
• network requests 過多

這些也是原始內容裡最明確涵蓋的範圍。

建議要求 optimize 產出什麼格式

若想提升判斷品質，建議請 optimize 用結構化格式回覆：

• diagnosis
• ranked bottlenecks
• recommended fixes
• expected impact
• tradeoffs
• verification plan

這比起單純要求「列出最佳化點子」實用得多，尤其當你要決定哪些項目應該優先上線時更是如此。

能明顯提升 optimize 使用效果的技巧

可以要求 skill 明確區分以下面向：

• lab metrics 與 real-user symptoms
• desktop 與 mobile 的效能差異
• 初次載入與重訪問
• network-bound 與 CPU-bound 問題
• 一次性高成本工作與重複性高成本工作

這些差異常常會直接改變正確的修正方向。例如，圖片壓縮比較適合 network-heavy 的頁面；而 layout thrash 的修正則更影響執行時的順暢度。

常見的適用限制

這個 skill 以「提供判斷與指引」為主，不是對某個生態系特別深挖的工具。如果你需要精準的 framework internals、客製 bundler 指令，或自動化 patch 產生，請把 optimize 和你自己 codebase 的 repo-specific context 搭配使用。它最有價值的情境，是有足夠證據可供推理；不是預設就知道你的整個技術棧。

optimize skill 常見問題

optimize 適合新手嗎？

適合，只要你能提供症狀與量測數據。這個 skill 的結構對新手相對友善，因為它是從量測與優先排序開始。不過如果你是完全初學者，在拿到最佳建議之前，可能還是需要先有人幫你蒐集 DevTools 或 Lighthouse 的資料。

什麼時候該用 optimize，而不是一般 coding prompt？

當效能本身就是主要任務，而不是附帶議題時，就該用 optimize。如果你的需求是「修掉卡頓」、「改善載入時間」或「縮小 bundle size」，它會比通用 prompt 更合適，因為它就是為了先診斷、再處理性能問題而設計的。

optimize 可以取代 profiling tools 嗎？

不能。optimize skill 是用來補強 Lighthouse 和 browser profiler 這類工具，不是取代它們。它的價值在於協助你解讀發現、排定優先順序，並把原始訊號整理成可執行的行動計畫。

optimize 只適用於 web performance 嗎？

從原始內容來看，它主要針對 UI 與 web 類型的性能問題：Core Web Vitals、圖片、network payload、渲染與動畫。若你要處理的是 backend query tuning 或 infrastructure latency，它就不是首選。

什麼情況下 optimize 不太適合？

以下情況建議不要用 optimize：

• 你沒有明確的 UI 目標
• 問題完全在 backend
• 你想在沒有量測的情況下直接拿一份「最佳實務」
• 你需要 framework-specific 的實作細節，但又沒有提供任何專案背景

在這些情況下，輸出很可能會過於籠統，無法支撐你做出有把握的修改。

這個 repo 有額外的參考資料或自動化工具嗎？

在目前的 snapshot 裡沒有。從 repository 的內容來看，只有單一的 SKILL.md，也沒有支援資料夾。這讓安裝很簡單，但也表示你的 prompt 品質與本地量測資料，會更直接影響結果好壞。

如何進一步提升 optimize skill 的效果

給 optimize 更好的證據，而不是更大的目標

想讓 optimize 的輸出更快變得有用，最有效的方法就是提供更精準的輸入：

• 明確頁面或 route
• 指標數值
• 螢幕截圖或複製出的 profiler findings
• 受影響的裝置／網路情境
• 最近的 regression 或可疑變更

「首頁很慢」得到的建議，通常會比不上「mobile LCP 在加入 autoplay video 和新的 analytics tag 後，從 2.6s 退化到 4.0s」。

要求依影響與成本排序

效能工作很容易很快變得雜亂。請明確要求 optimize 依下列面向排序建議：

• 對使用者體驗的影響
• 信心程度
• 實作成本
• regression 風險

這能避免低價值的清理工作，蓋掉真正的大問題，例如過大的圖片或過量的 JavaScript。

把載入修正和渲染修正分開處理

常見的失敗模式之一，就是把所有效能建議混在一起。若要提升結果品質，建議一次只要求 optimize for Performance Optimization 的其中一條路線：

• loading：images、payloads、request count、code splitting
• rendering：reflows、paint cost、animation strategy、main-thread work

這樣切開之後，通常會得到更清楚、可執行的下一步。

盡早提供限制條件

請直接告訴 skill 你不能改什麼：

• 不能做 CDN migration
• 不能重寫 framework
• 這個 sprint 不能改 image format
• 必須保留動畫行為
• bundle 必須維持與 legacy browser targets 相容

限制條件會迫使建議更貼近現實，也能減少無效輸出。

要求 optimize 解釋每個修正為什麼重要

如果第一輪回答看起來太泛，可以進一步要求：

• 每個修正是在處理哪個 bottleneck
• 它應該改善哪個 metric
• 要如何驗證收益
• 有哪些 tradeoff，例如 CPU 與 bandwidth，或 smoothness 與 fidelity 之間的取捨

這會讓建議更容易被信任，也更容易正確落地。

第一輪之後持續迭代

最好的 optimize guide 使用方式其實是迭代式的：

1. 先取得初步診斷
2. 套用一到兩個最優先修正
3. 蒐集新的量測結果
4. 帶著 before/after data 再跑一次 optimize

這能把 skill 從一次性的建議工具，變成真正可操作的最佳化迴圈。

需要避免的常見失敗模式

在以下情況下，結果通常會比較弱：

• 一開口就要求「所有性能改善」
• 完全不提供 metrics
• 把 backend、infra 和 frontend 問題混在同一個請求裡
• 沒有交代裝置與網路情境
• 還沒確認 bottleneck 就先要求修法

這個 skill 在問題邊界清楚、而且有證據支撐時，表現會最好。

如何拿到更接近可實作的輸出

如果你想要的是可以快速動手的修改建議，請直接要求：

• 一份 top-3 修正清單
• 符合你技術棧的 code-level examples
• 一份量測檢查清單
• rollback 或 verification plan
• 與其做完整 audit，不如先回答「這週第一步該做什麼」

這樣的 framing 會更容易被團隊採用，因為它把建議直接轉成可交付的執行計畫。