40 秒的假象：AI「思考」時間究竟花在哪裡

請 AI 建構器串接一個可運作的登入流程──表單、驗證、路由、資料庫檢查──你通常要等 35 到 90 秒才會看到差異出現。若端到端剖析這個請求，模型本身，也就是實際產生 token 的部分，大約只佔 3 到 4 秒。網路往返再加上 1 到 2 秒。剩下超過 30 秒，也就是你感受到的「AI 在思考」，幾乎完全是別的事情：你的智慧代理團隊在讀取檔案、執行建置、並在顯示結果前檢查自己的工作。

第一次看到這個比例被量測出來時，幾乎所有人都感到驚訝，包括以此為業的工程師。直覺告訴我們，更大、更慢的模型一定是瓶頸，所以緩慢建置的解方一定是換用更快的模型。有時候確實如此。但大多數時候並非如此，理解原因會改變你對提示長度、專案規模的想法，以及當一次建置「卡住」時你該有的預期。

時間實際花在哪裡

把一個「新增功能」的請求拆成幾個階段，就能立刻看出一個模式：模型的時間花在短暫、低成本的爆發式動作上──決定下一步做什麼、寫出工具呼叫、讀取結果──而昂貴、緩慢的部分則發生在這些爆發之間，在硬碟上、在終端機裡。

從這張表格中可以得出兩件在並排比較之前並不明顯的事。第一，建置步驟的規模是隨整個專案的大小而定，而非隨你的提示大小──在一個 400 個檔案的應用程式上做一行 CSS 微調，驗證起來可能比在全新專案中新增五個檔案的功能還要久，因為無論如何編譯器都要檢查更多東西。第二，最大的單一槓桿根本不是模型。而是有多少東西被牽動到。

為什麼這種錯覺會持續存在

串流介面某種程度上（是好意上）該負責。第一個 token 通常在一秒內出現，所以介面立刻感覺很有反應──你看到計畫成形、句子逐字打出、工具呼叫捲動而過。這種首字延遲，就是人們心理上認定的「AI 的速度」。他們沒清楚看到的是，模型一旦決定好要做什麼，就會交棒給一條與語言模型完全無關的建置流程。一次 `docker build`、一次 `npm install`、一個走訪匯入圖的型別檢查器──這些都不會因為 GPT-5 取代了 GPT-4，或 Sonnet 取代了舊版 Sonnet 而變快。它們會變快，是因為有人快取了相依套件層，或省略了一次多餘的檢查。

我曾看過建構者在同一週內兩次換模型，只為了修正「緩慢」的建置，後來才發現真正的瓶頸是驗證流程每次儲存都重新執行完整型別檢查，而不是漸進式檢查。換模型什麼都沒改變，因為模型從來就不是慢的那部分。

這在哪些地方真正咬人

實際的後果會出現在幾個可預期的地方：

• 龐大、分散的提示感覺特別慢──不是因為模型難以解析，而是因為一個涉及十二個檔案的請求，會觸發十二次檔案讀取、十二次寫入，以及一次現在必須整合所有變更的建置。
• 隨著專案成長，迭代速度會變慢，即使每個提示本身仍然很簡單，因為建置與驗證階段會隨專案總規模擴大。
• 「卡住了」很少是模型在停滯。 幾乎總是建置步驟在等待套件註冊表，或是驗證代理在重跑一個其實不需要重跑的檢查。
• 把一個大請求拆成幾個小請求，通常整體反而更快完成，因為每個較小的請求會觸發範圍更窄的建置和更輕量的驗證，即使你現在要等待更多個別步驟。

我們 Discord 上一位創作者說得很好：「我一直要求更快的大腦，但我需要的其實是更小的差異。」

什麼才能真正縮短等待時間

真正有效的修正方法都與更大的模型無關。只重新編譯有變動部分而非整個專案的漸進式建置，能大幅削減建置階段所佔的比例──這是目前最大的單一槓桿，往往勝過其他所有最佳化的總和。在多次執行之間快取相依套件安裝，可以省去與你特定提示無關的一大塊工具執行階段。將驗證範圍限定在實際的差異上，而不是每次都重新檢查整個程式碼庫，能讓該階段的時間與變動量成正比，而非與整個既有程式碼庫的規模成正比。而平行執行彼此獨立的工具呼叫──一次讀取三個不相關的檔案而非依序讀取──能在完全不動到模型的情況下，實實在在省下檔案讀寫階段的秒數。

這些做法都不算光鮮亮麗。但這也是為什麼兩位建構者在同一天於同一平台輸入幾乎相同的提示，卻會有截然不同的「聰明」或「快速」體驗──真正的差異在於專案結構，而非模型品質。模型從來就不是你一直盯著看的那個時鐘。它只是看起來像而已。