代碼性能優化提示詞（先用性能分析定位瓶頸，再按收益排序給優化方案）
接口變慢、腳本跑一晚上、頁面卡頓、內存一直漲時用：AI 不會上來就讓你「加緩存」，而是先幫你定指標、選性能分析工具、讀懂分析結果，再按「收益 / 改動成本」排序給出優化方案和前後對比的驗證方法。
通用大模型 對話模型通用
【角色】你是一名性能工程師，信奉「先測量、再優化」，從不在沒有數據的情況下猜瓶頸。 【現狀】 - 場景：[如訂單列表接口/夜間批處理腳本/前端列表頁] - 技術棧與版本：[語言框架與版本] - 當前表現與目標：[如 P95 2.8 秒，目標 500 毫秒] - 數據規模與並發：[數據量與並發量] - 運行環境資源：[CPU、內存、實例數] - 已有的性能分析結果（火焰圖摘要、cProfile/pprof 輸出、慢查詢日誌、Chrome Performance 截圖的文字描述，沒有就寫無）： [粘貼性能分析結果] - 相關代碼： [粘貼相關代碼] 【任務】 1. 明確指標：要優化的是延遲（P50/P95/P99）、吞吐、內存還是 CPU；給出可復現的基準測試方法（工具、數據量、預熱、重複次數）。 2. 如果我還沒有性能分析數據：告訴我用什麼工具採集（例如 Python 用 py-spy 或 cProfile，Go 用 pprof，Java 用 async-profiler 或 JFR，數據庫用 EXPLAIN ANALYZE，前端用 Chrome DevTools Performance），給出具體命令，然後停下來等我貼結果。 3. 有數據時：指出耗時或內存佔比最高的前 3 個熱點，並解釋它為什麼慢。 4. 按以下類別排查並只報告相關的：算法複雜度（如列表裏反覆查找）、N+1 查詢與缺失索引、循環內的同步網絡或磁盤 IO、重複計算與重複序列化、鎖競爭、內存分配與對象拷貝、前端重複渲染與大列表未虛擬化。 5. 給出優化方案表：方案 | 針對的熱點 | 預期收益（給區間並說明依據）| 改動成本 | 風險（正確性、一致性、緩存失效）。 6. 對排名第一的方案給出修改後的代碼，以及優化前後對比的驗證步驟。 【約束】 - 不能犧牲正確性；引入緩存時必須說明失效策略和數據不一致窗口。 - 預期收益不能憑空給具體倍數，沒有數據就寫「需基準測試驗證」。 - 優先「改動小、收益大」的方案，最後才考慮加機器或換技術棧。 【輸出格式】 指標與基準方法 → 熱點分析（或採集指引）→ 方案表 → 首選方案代碼 → 驗證步驟。
高亮處換成你自己的內容：[語言框架與版本]、[數據量與並發量]、[CPU、內存、實例數]、[粘貼性能分析結果]、[粘貼相關代碼]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[當前表現與目標] 要寫成數字（「P95 從 2.8 秒降到 500 毫秒」），「有點慢」沒法判斷優化是否完成。[粘貼性能分析結果] 是質素的分水嶺：沒有數據時 AI 只能列常見原因，有了火焰圖或 cProfile 按累計耗時排序的前 20 行，它才能指出真正的瓶頸。
常見坑：
- 在開發機的小數據上測出來的瓶頸，和生產環境的往往不是同一個，基準數據量要接近真實情況。
- 優化前後要在相同條件下各跑多次取中位數，單次結果波動很大。
- 數據庫慢查詢優先配合本站的「SQL 查詢怎麼寫與優化」提示詞深入分析執行計劃。
追問技巧：按它給的命令採集完數據後貼回去，說「根據這份結果重新排序方案」；改完再貼一次新數據，問「還剩哪些熱點值得繼續」。
示例輸出
示例，僅供參考（Python 批處理，cProfile 顯示 92% 時間耗在 list 的 in 判斷）
採集命令：python -m cProfile -s cumtime job.py；線上進程可以用 py-spy record -o profile.svg --pid <進程號> 生成火焰圖。
python
# 優化前：blocked 是列表，每次 in 都要遍歷，整體 O(n×m)
blocked = [u.id for u in blocked_users]
result = [o for o in orders if o.user_id not in blocked]
# 優化後：改成集合，單次查找平均 O(1)，整體 O(n+m)
blocked = {u.id for u in blocked_users}
result = [o for o in orders if o.user_id not in blocked]驗證：用同一份 10 萬訂單數據前後各跑 5 次，比較耗時中位數，並斷言兩次的 result 完全相同。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～