AI 專案跑一小時才結束，問題多半不在模型慢，在測試排隊

10月21日，V2EX 一名開發者發文分享了一段排查經驗。他的專案交給 AI（文中使用 Codex）執行時，動輒超過一小時。詢問 AI，得到的回答是在測試、回歸測試、修問題再測試。因為社羣近來普遍有「模型變慢了」的印象，他也沒有多想，直到某天才發現：AI 加入的大量測試是串行執行的。

更麻煩的是結構問題。原Po表示，先前曾要求 AI 將測試分類、平行執行，AI 也確實照做了，但只建立了一層粗略的大分類，之後新增的測試全被塞進其中一個分類裡，越積越多，執行時間也越拉越長。換句話說，AI「理解並執行」了指令，但執行品質隨著任務累積逐漸走樣。

串行和平行，差在哪裡

用日常生活比喻：串行執行像只有一個結帳櫃檯，十位顧客排隊，一位一位來；平行執行則是開了五個櫃檯同時結帳。測試數量少的時候，一個櫃檯也夠用，沒人察覺問題。等到 AI 不斷往系統裡加測試，櫃檯前的隊伍越排越長，總時間就被喫掉了。

這類問題的麻煩在於，它不會報錯。程式照樣通過測試，只是愈跑愈久，表面上看起來像模型或機器變慢，實際上是工作流程的組織方式出了岔。

討論串裡幾位回應者提供了類似的經驗。暱稱 ntdll 的使用者指出，這類模型的單元測試顆粒度太細，甚至對每個內部方法都寫一個測試案例，其中多數沒有必要，還浪費時間與 token。他的建議是硬性要求只對導出方法或公共方法做測試，若是 Web 服務就只測 API 端點。

另一位回應者 Parva 的觀察更概括：Codex 做什麼都容易過度，過度設計、過度開發、過度測試，明確提醒它「不要過度」通常能改善。

原Po自己在回覆中也提到一個兩難：完全不加測試，AI 就會偷懶，宣稱沒問題，但自己實際執行卻是錯的。這大概是許多把 AI 整合進開發流程的人共同的心得，測試太少抓不到 AI 的錯，測試太多又拖垮整個迭代循環。

綜合這串討論，可以整理出幾個可行的做法。

第一，不要只問 AI「為什麼這麼久」，要直接看它產出的測試是怎麼被執行的。串行還是平行、分類是否真的發揮作用，這些要打開設定或腳本確認，而不是聽 AI 複述它做了什麼。原Po的經驗正是如此，AI 說有分類平行，實際上分類只做了一層就停了。

第二，對測試範圍設下明確邊界，例如只測公共介面與 API 端點。這與我們先前整理過的 DeepSeek 換版後 token 預算管理是同一類課題：模型的能力上來了，但消耗資源的方式需要使用者主動設限。

第三，隨著任務累積，早期的指令會被淹沒。原Po提到已加了全域 agents 設定檔，AI 仍「越走越遠」，懷疑是 context 太長忘記了早前的要求。這代表長時間、多輪次的專案裡，關鍵規範需要定期重申或收斂任務範圍，不能假設第一次說過就永久生效。

這篇貼文真正值得留意的，不是某一個工具的 bug，而是 AI 代理工作模式的通性：它對「把事情做完」很在行，對「用最省的方式做完」沒有天然動機。測試越多它越有把握交差，但時間成本由使用者承擔。當 AI 專案的執行時間明顯異常時，先檢查它自己建立起來的流程，往往比怪罪模型速度更有用。