optimize

optimize 技能總覽

optimize 技能會做什麼

optimize 技能的重點，不是靠猜測去套用各種「加速祕訣」，而是協助代理實際診斷並改善 UI 效能問題。它特別適合用在網站或應用程式出現載入慢、卡頓、掉幀、沉重、反應不靈敏等情況時，並聚焦在最常真正影響體驗的面向：載入、渲染、動畫、圖片、bundle 大小，以及執行期行為。

哪些人適合使用 optimize

這個 optimize 技能最適合開發者、產品工程師、前端專家，以及需要在 AI 輔助開發流程中，對既有介面做實用效能檢查的人。當你已經有明確的頁面、元件或應用行為可供檢視時，它的價值最高；如果你只是想要一些泛泛的效能建議，幫助就相對有限。

optimize 真正要解決的工作

多數使用者要的不只是「讓它變快一點」。他們真正需要的是：

• 找出真正的瓶頸，
• 避免過早優化，
• 選出對使用者影響最大的調整，
• 並驗證修改後是否真的改善效能。

這也是為什麼 optimize for Performance Optimization 會比寬泛提示詞更有用：它會把工作導向量測、瓶頸辨識與有針對性的修正，而不是給一串籠統建議。

optimize 技能和其他方式有什麼不同

optimize 技能最大的差異，在於它對範圍有明確紀律。它不會把效能視為一個模糊的大問題，而是拆解成可量測的類別，例如 Core Web Vitals、載入時間、bundle 體積、動畫流暢度、CPU 成本、記憶體使用量，以及網路額外負擔。這讓 optimize 在真實 repo 裡更容易落地執行，而不是停留在概念層面。

如何使用 optimize 技能

如何安裝 optimize

請透過你的 skills 工作流程使用這個技能：

npx skills add pbakaus/impeccable --skill optimize

安裝後，請先打開：

• SKILL.md

這個 repository 的佐證內容相對精簡，因此 SKILL.md 就是 optimize 指南與工作流程的主要依據。

實務上什麼時候該呼叫 optimize

當使用者提出以下這類描述時，就很適合呼叫 optimize：

• 「這個頁面載入很慢」
• 「捲動時感覺很卡」
• 「動畫會頓」
• 「bundle 太大了」
• 「手機上的效能很差」
• 「可以幫我改善 Core Web Vitals 嗎？」

只要任務牽涉到既有 UI，且能觀察到明確的遲緩或卡頓，optimize 通常都很合適。相對地，如果問題只在後端延遲、資料庫調校，或基礎設施成本優化，它就不是理想選項。

optimize 技能需要哪些輸入

如果你能提供以下資訊，optimize 技能通常會發揮得最好：

• 目標頁面、route 或元件，
• 哪裡感覺慢，
• 問題發生的位置或情境，
• 裝置或瀏覽器脈絡，
• 你目前已經掌握的量測結果，
• 以及限制條件。

好的輸入範例：

• 「Optimize the product listing page on mobile Safari; LCP is high and scroll stutters.」
• 「Optimize our React dashboard initial load; bundle grew after adding charts.」
• 「Optimize modal open/close animation; it drops frames on mid-range Android devices.」

較弱的輸入：

• 「Make the app faster.」

把模糊需求整理成高品質 optimize 提示詞

更有效的 optimize 使用方式，通常會包含：

1. 先指出目標。
2. 描述症狀。
3. 提供證據。
4. 說明限制條件。
5. 要求依優先順序提出修正方案。

範例提示詞：
「Use the optimize skill on our /pricing page. Problem: slow first load on 4G and layout shifts after hero image loads. Current signals: LCP 4.1s, CLS 0.19, JS bundle increased after adding testimonials carousel. Constraints: keep design unchanged, no framework migration. Please identify likely bottlenecks, rank fixes by impact, and propose code-level changes.」

這樣的提示詞能讓代理有足夠脈絡去做真正的效能分流與診斷，而不是只產出一堆通用建議。

先量測，再動手修

optimize 技能裡最重要的一個原則，其實就是：修改前後都要量測。實務上，你的 optimize 工作流程應該先從現況評估開始：

• Core Web Vitals：LCP、INP/FID、CLS
• 繪製與互動時間，
• bundle 與資產大小，
• 幀率與執行期成本，
• 請求數量與 waterfall 模式。

如果跳過這一步，輸出品質通常會很快下滑，因為代理只能自己猜測瓶頸在哪裡。

optimize 技能通常會檢查哪些面向

從原始內容來看，optimize 技能主要圍繞以下幾類效能問題：

• 載入效能，
• 渲染效能，
• 圖片優化，
• 動畫流暢度，
• JavaScript 與 CSS 體積，
• 網路與 payload 傳輸效率。

這也讓它特別適合用來做前端效能稽核，以及規劃具體、有目標的修正方案。

建議的 optimize 使用流程

一個實用的 optimize 工作流程可以是：

1. 找出變慢的畫面或互動。
2. 收集量測數據或重現細節。
3. 帶著目標與症狀呼叫 optimize。
4. 檢視它提出的可能瓶頸與修正建議。
5. 先套用高影響、低風險的修改。
6. 重新量測。
7. 針對剩餘瓶頸持續迭代。

這個順序對應的正是使用者真正關心的事：用較少無效重構，換到更快的結果。

想快速上手 optimize，可先這樣讀 repository

這個技能除了 SKILL.md 之外，幾乎沒有太多額外結構，所以最有效率的閱讀路徑很簡單：

1. 先看 SKILL.md 了解範圍與流程
2. 優先閱讀 “Assess Performance Issues” 這一節
3. 再往下看 loading、rendering 等優化分類

這是一個相當精簡的技能，上手阻力不高；但也因為內容精簡，你需要自行補上工具鏈與 repo 專屬的效能證據。

好的 optimize 輸出應該長什麼樣子

一份有用的 optimize 結果，通常應該包含：

• 最可能的瓶頸，
• 它為什麼會影響使用者，
• 要如何驗證，
• 可行的修正方案，
• 以及建議的優先順序。

例如，「convert oversized hero images to AVIF/WebP」這種建議，若能搭配「目前圖片寬度是 3000px，但在 mobile 上只以 360px 呈現，導致 LCP 延後」，就會比單獨丟一條建議更有決策價值。

一開始就該先講清楚的常見限制

如果你希望 optimize 的安裝後使用效果更好，請先告訴代理你是否必須保留以下條件：

• framework 選擇，
• 視覺設計，
• SEO 行為，
• 動畫手感，
• 瀏覽器支援範圍，
• analytics scripts，
• 或第三方 widgets。

因為效能建議會隨著這些限制而大幅改變：你能不能移除程式碼、延後 script、改變圖片傳遞方式，或簡化 UI 行為，會直接影響建議是否可行。

optimize 技能常見問答

optimize 做效能工作，真的比一般提示詞更好嗎？

通常是，前提是你手上真的有 UI 效能問題。一般提示詞往往會直接跳去亂開藥方；optimize 技能則更有價值，因為它會先把重點放在診斷，再進入有針對性的修正。

optimize 只適用於前端 web app 嗎？

大致上是。optimize 技能很明顯是以 UI 效能為中心：載入速度、渲染、動畫、圖片、bundle 大小，以及使用者感知到的流暢度。它不是拿來處理資料庫、佇列或伺服器調校的主要工具。

我一定要先有 Lighthouse 或 Web Vitals 資料嗎？

不一定，但有會差很多。你仍然可以用症狀導向的輸入來使用 optimize，不過若能提供實際量測數據，或至少有可靠的重現路徑，結果通常會明顯更好。

初學者也能用 optimize 技能嗎？

可以，只要能把頁面與症狀描述清楚。這個技能本身提供了不錯的結構，但對初學者來說，蒐集證據與套用 framework 專屬修正時，可能仍需要額外協助。

什麼情況下不該使用 optimize？

以下情況就不太適合看這份 optimize 指南：

• 問題只在後端延遲，
• 問題其實不是效能，而是可用性，
• 你需要的是架構層級的擴充與 scaling 建議，
• 或你根本沒有可檢查的目標畫面、流程或症狀。

optimize 技能會自動修改程式碼嗎？

這個技能本質上偏向提供指引與判斷。在 AI coding workflow 裡，它可以驅動程式碼修改，但修改品質會很大程度取決於你提供了多少 repository 脈絡、量測資料與限制條件。

如何改善 optimize 技能的使用效果

給 optimize 明確目標，不要丟整個 app

想提升 optimize 輸出品質，最快的方法就是縮小範圍。「Optimize checkout page submit flow on low-end Android」遠比「optimize my app」有效。目標越清楚，猜測越少，產出的修正方案也越能直接落地。

同時提供使用者症狀與技術訊號

最好把定性與定量資訊一起給：

• 「scroll stutters after opening filters」
• 「INP regressed to 280ms」
• 「hero image loads late」
• 「bundle grew by 400 KB after adding editor」

這種組合能幫助 optimize 技能把指標和根因更精準地連起來。

要求依優先順序排序建議

好的提示詞應該要求代理把建議拆成：

• 高影響、可快速落地的改善，
• 中等工作量的改善，
• 以及侵入性較高的變更。

這會讓 optimize for Performance Optimization 更利於決策，特別是在團隊無法承擔大規模重寫時。

提前說明會影響修法的限制

如果有以下限制，效能建議往往會完全不同：

• 必須使用 SSR，
• 設計不能變，
• 第三方 scripts 不能移除，
• 圖片品質必須維持高水準，
• 或動畫豐富度本身就是產品特色。

如果你沒有先講清楚，optimize 技能很可能提出技術上合理、但在你的環境裡根本不能用的方案。

要求提供修改前後的驗證步驟

不要停在「套用修正」這一步。你應該要求這個技能明確定義修改後要重新量測什麼：

• 哪個指標應該改善，
• 應該去哪裡檢查，
• 成功門檻是什麼。

這是提升 optimize 使用品質最實際、也最常被忽略的一步。

留意 optimize 常見失效情境

以下情況最容易讓 optimize 技能表現不佳：

• 提示詞沒有明確目標，
• 沒有提供任何量測，
• 症狀混雜在多個頁面之間，
• 或要求代理一次優化所有東西。

另一個常見失效模式，是過度聚焦在 bundle 大小，但真正問題其實是 layout thrashing、過大的媒體資產，或 script 執行成本。

要求根因分析，而不是一份建議清單

如果你第一次拿到的結果太泛，可以這樣補強：
「Use the optimize skill again, but identify the top two likely root causes for this page and explain why they are more probable than the others.」

這樣能把輸出從 checklist 模式，推進到真正的診斷模式。

optimize 第一輪之後要繼續迭代

實務上，最好用的 optimize 指南通常都是迭代式的：

1. 先修掉最大的瓶頸，
2. 重新量測，
3. 找出下一個限制，
4. 再次 optimize。

效能工作很少一次就徹底解決，而 optimize 技能在作為循環流程使用時，通常比單次命令更有價值。