筆者要來 Demo 一個在 Vibe Coding 裡比較少人在講、但實務上非常重要的主題：Performance Profiling。
很多人 Vibe Coding 完：「可以跑，好棒，收工！」結果上線之後，使用者按一下按鈕，伺服器開始思考人生，然後大家一起盯著 loading spinner 發呆。程式能動不代表程式跑得快，更不代表它撐得住正式環境啊~
所以今天筆者會用 Microsoft 提供的 ContosoOnlineStore 範例，搭配 .NET 的 BenchmarkDotNet 與 Github Copilot，實際走過一次「建立 baseline → 找瓶頸 → 讓 AI 優化 → 再測一次 → 比較結果」的完整流程。 這對使用 Copilot 協助開發的工程師、需要接手舊程式的團隊，以及常常被產品經理問「為什麼這頁這麼慢」的人，都很有幫助。
這次使用的是 .NET 生態系裡很常見的 BenchmarkDotNet。這個工具其實已經存在一段時間了， 不是什麼剛上市的新玩具，筆者看到 Visual Studio 裡的 BenchmarkDotNet 套件畫面時，也順便感受到一點時代的眼淚： 原來這些工具已經陪我們很久，只是平常大家都忙著趕功能，沒空理它。
筆者這次把流程拆成四個階段，先量測、再分析，最後才動手改。這一點很重要，因為如果沒有 baseline， 優化完只靠「感覺好像比較快」，那叫做玄學，不叫做效能工程。
1. Setup
建立專案並跑出 baseline
2. Ask
請 AI 找出可能的瓶頸
3. Agent
讓 AI 協助重構與修正
4. Compare
再跑一次並比較前後差異
📌實測如下
分析結果指出幾個很明顯的熱點，包括重複的線性搜尋、逐筆查詢、非必要的同步等待，以及大量的 Thread.Sleep 或 Task.Delay。 其中有一段商品查詢，查找 800 個產品竟然花了 6,000 多毫秒，也就是大約 6 秒。不過這是範例程式，用來展示Performance Profiling的效果，實務上還是會有差異，但概念是一樣的。
⚠️ 這裡有一個容易誤判的地方
範例專案裡刻意加入一些延遲，目的是讓效能差異更容易被觀察。 所以 AI 找到的 Delay 確實是瓶頸，但在真實專案裡不能看到 Delay 就全部刪掉。 有些等待可能是為了限流、重試、外部 API 或業務流程，必須先確認用途，再決定是否移除。
📊 產生最佳化後的結果
這裡筆者請 AI 產生一份 compare.md，讓前後結果有清楚的差異紀錄。 這份 Markdown 不只是報告，也是之後團隊 Review、Pull Request 或效能回歸檢查時的依據。 凡走過必留下痕跡，效能測試也不例外啊~
🚀 實測結果：居然改善非常有感
比較結果出來後，筆者有點意外，因為這個範例的改善幅度相當明顯。 當然，這是示範專案，原本刻意放入了延遲與低效率的查找方式，所以不能直接拿來推論所有正式系統都能快這麼多。 但它很清楚地示範了：只要有量測、有證據，AI 確實可以幫忙快速找出值得優化的地方。
2,850 ms → 35.63 ms
訂單完成處理時間
3,320 ms → 60 ms
整體處理時間
6,460 ms → 接近 0 ms
商品查詢 Benchmark
12,360 ms → 0 ms
五筆訂單處理 Benchmark
這些數字主要來自兩件事：移除模擬用的序列延遲，以及把重複的線性查找改成索引存取。 原本每次都要在清單裡慢慢找，改成 Dictionary 後，查找成本自然大幅下降。 這種優化不算什麼神秘魔法，但如果平常只看功能、不做 profiling，還真的很容易漏掉。
實作細節的部分，請參考完整版影片囉
🧠 今日結論
沒有 baseline，就沒有可信的改善
不要只看程式碼覺得「這段應該很慢」，先跑出數據。人腦很會腦補，CPU 可沒有義務配合我們的想像。
AI 適合找方向，但最後仍要人工驗證
AI 可以快速掃描多個檔案、整理熱點、提出重構方式，這是非常實用的能力；但修改是否符合業務邏輯、是否影響交易一致性、是否破壞安全性，還是要由人確認，這也是先用Ask Mode而不用Agent Mode的原因。
測試、效能、安全性，其實是同一條路
今天的效能改善不只是在追求「快」，也可以順便檢查 API 呼叫、密鑰使用、同步阻塞、執行緒安全與資源管理。 效能測試做得好，常常會順便挖出架構與安全性的問題，算是一次買三種保險。
今天這個流程筆者非常推薦大家拿自己的小專案練手：先找一個可以 Performance Profiling 的框架，建立 baseline， 再請 AI 做分析與重構，最後用相同條件重新測試。不要一開始就挑全公司最重要、最複雜、最不能壞的系統， 先從小地方練習，補齊這一塊。
iThome鐵人賽
看影片追技術