AI給了8個最佳化方案全都對卻沒一個有用：一篇掘金長文背後的工程判斷難題

2026年9月17日，掘金使用者「東東拿鐵」發布一篇約7分鐘閱讀長度的技術長文，標題直白：《AI給了我8個最佳化方案，全都是對的，但沒有一個有用》。文章記錄了作者接手一個陌生領域專案後，借助AI快速建立理解、卻在實際效能最佳化上遭遇判斷困境的完整過程。本臺以回顧角度，綜合原文內容與公開資料，整理這篇長文的事件輪廓、技術細節與可核實資訊的邊界。

接手陌生專案：一天追上過去幾週的理解進度

根據原文自述，作者近期從同事手中接手一個新專案。這個專案對他而言是完全陌生的領域，包含大量病理業務知識與專業術語、複雜的狀態流轉，以及前後端相互配合的處理流程。作者形容，「就像是跳槽換了一份工作一樣」。

作者準備了幾套提示詞。第一套讓AI協助梳理病理業務、專業名詞與狀態流轉；另一套則讓模型閱讀前後端程式碼，分析程式結構與主要處理流程。AI整理了業務流程、解釋陌生術語、分析模組間的呼叫關係，最後生成了一份後端知識庫。作者寫道，一天之後，他已能看懂這個專案的基本業務邏輯與技術結構。

文中對照了過去的做法：接手一個專案，得先花半天搞清楚程式碼倉庫的目錄結構，然後從controller一路追到service、再追到dao，追到一半常發現命名與文件對不上，而文件往往還是兩年前寫的。現在把一個模組的程式碼交給AI，直接問「這塊做了什麼」、「這個狀態怎麼流轉」，模型就能給出對應答案。作者估計，一天下來對專案的理解程度，約等於以往花幾週累積的水平。

這種藉由大型模型加速程式碼理解的實踐，近月在開發者社羣持續出現。先前本臺整理過的Neovim子會話工具pi2.nvim，便是開發者為了在編輯器內更有效率地調度AI代理而做的嘗試，反映同類需求正在不同工具鏈中落地。

真正的麻煩：每個方案都說得通

第二階段出現了轉折。作者開始處理專案中實際存在的效能問題：系統需要在本地處理一個約1GB的大檔案，再上傳到檔案伺服器，整條鏈路耗時過長，需要最佳化。

面對陌生程式碼，作者先懷疑既有技術方案，把問題交給AI，要求分析可能的效能瓶頸並給出不同的最佳化方向。模型很快生成多個方案：有的建議增加平行處理，有的建議最佳化圖片轉換，還有方案從ZIP打包與磁碟讀寫入手，甚至有方案提議重新調整整個處理架構。

作者指出，每一個方案都有完整的理由，從問題分析到技術實現，看起來都很合理。麻煩也正在這裡：無論AI說什麼，他都覺得有道理。模型沒有胡說，給出的每一個方向在技術上幾乎都能找到成立的理由，但作者鑑別不了哪個方案擊中了當前瓶頸，哪個方案只是理論上可行。

原文對此有一段直白的描述：以前沒有答案的時候，會覺得困難；現在AI一次給出很多答案，困難沒有消失，只是換了個樣子。過去不知道有哪些方案，現在則是不知道該相信哪個方案。

換更強的模型：結果沒有多大變化

作者一度把問題理解為模型能力不足。既然當前模型給不出確定答案，那就換更強的模型，他接著嘗試了GPT-6。

試過之後，作者的結論是：結果沒有多大變化。問題還沒有被準確定位，更強的模型也只能生成更多合理答案。這些答案可能更完整、論證更充分，甚至連實作步驟都寫好了。作者觀察到一個反向關係：AI給的答案越多，需要判斷的東西反而越多。如果連究竟哪個變數限制了結果都不知道，模型表現得越自信，人越容易沿著一個看起來正確的方向走下去。

這一觀察與近來開發者社羣對模型能力邊界的討論方向一致。本臺先前整理Codex Pro 20x停售傳聞的V2EX討論時，也記錄了使用者對AI編碼服務算力供給與實際產出之間落差的兩種解讀，顯示「模型升級是否等於問題解決」已是社羣反覆檢驗的題目。

沉下去讀程式碼：瓶頸出現在十萬張小檔案

作者最終沒有繼續追問模型，而是決定把整條圖片處理流程重新看一遍。

具體過程如下：檔案轉化的第一步依賴一個開源解析框架，改不動原始碼，但支援多執行緒，作者立刻調大了執行緒數。轉化後的檔案會生成具體圖片，需要把整個資料夾的圖片打包壓縮後上傳到OBS（物件儲存服務）。作者在系統每一步加入日誌，對整條鏈路進行觀測，發現耗時最長的環節是打包：這一步差不多用了十分鐘。

打包為什麼慢？作者的結論是圖片太多，一個檔案裡有十幾萬張圖片，作業系統每讀一個檔案都要做一次磁碟尋址。他強調，這不是演算法問題，也不是架構問題，就是檔案太碎了。文中用了一個日常類比：用硬碟拷貝一個電影很快，但拷貝一堆小檔案就非常慢，這是由系統與硬體決定的。

直接解決檔案數量這個變數，得到的提升最大。根據原文，最終整條處理流程的耗時縮短了約80%。

作者隨後回頭檢視先前AI給出的那些方案：平行處理、換壓縮演算法、最佳化圖片格式，沒有一個碰到這個點。他認為這不是因為那些方案錯了，而是因為自己從來沒有告訴AI瓶頸在打包環節、而打包環節的問題是小檔案數量。用原文的話說：「我一直問的是怎樣提高效率，當然有很多種方案。但哪些方案最適合當下，需要你自己判斷。」

事件脈絡與可核實資訊的邊界

需要說明的是，這篇文章屬於個人技術經驗分享，文中的80%耗時縮短、十分鐘打包時間、十幾萬張圖片等數字，均出自作者單方面自述，未有獨立驗證的基準測試或第三方覆核。文中的專案背景（病理業務、1GB檔案、OBS上傳）同樣僅見於原文，細節不足以定位具體企業或系統。

不過，文章描述的技術現象本身有可對照的常識基礎。大量小檔案的隨機讀寫受磁碟尋址開銷制約，是儲存系統領域長期存在的已知問題；觀測日誌先行、定位瓶頸再動手最佳化，也是效能工程領域的標準做法。作者的經歷可視為「先測量、後最佳化」這一原則在AI輔助開發情境下的一次案例重演。

文章結尾引述了作者的一段反思。他表示這次經歷之後，對AI的態度從興奮慢慢轉為冷靜：AI加快了執行速度，但工程師依舊很忙；模型可以給出很多方案，卻解決不了「該選哪個」。原文最後一句寫道：「模型是公平的。但你帶著什麼進入對話，不是。」

截至本臺發稿，該文見於掘金平臺，作者為「東東拿鐵」，發布日期為2026年9月17日。文中提及的GPT-6嘗試屬作者個人使用紀錄，模型在該情境下的表現無法由外部重現檢驗。本臺僅就原文可核實內容進行整理，文中結論代表作者個人觀點。