12 小時 4,518 行自造工具，載入仍 35 秒：給 Codex 優化任務設量測預算與停損

瀏覽次數: 4

本文大綱

先講清楚這篇的依據

這篇的起點是 r/ChatGPTCoding 上一則貼文，標題大意是「12 小時、Codex 自己造了 4,518 行工具，載入時間仍然是 35 秒」。我這次抓不到 Reddit 原文（工具被擋），所以貼文裡的細節我一概不轉述：用了哪個模型、優化什麼專案、工具長什麼樣、後來怎麼收場，都沒有查證。能引用的只有標題給的三個數字：12 小時、4,518 行、35 秒。

下面的內容分兩種：Codex 官方文件能查到的設定，標成「文件載明」；從這個標題情境推出來的做法，標成「建議」，是方法論，不是誰實測過的結論。你可以把它當成一份「Codex 做優化任務前的防呆清單」。

為什麼這個故事值得拆

看標題就知道問題在哪：投入 12 小時、產出 4,518 行程式，目標指標（載入時間）卻沒有移動。產出的行數很多，但那些行數不是在改產品，而是在服務量測。

這是 agent 做優化任務時常見的失控模式，原因很直白：

優化需要量測，agent 發現現有量測不夠準，就開始寫 profiler、benchmark 腳本、報表產生器。
每個工具本身都「合理」，所以沒有任何一步會觸發警覺。
工具又會長出新的需求（要比對、要視覺化、要快取結果），於是越寫越多。
agent 的完成感來自「做了很多東西」，而不是「指標下降」。

人在旁邊盯的時候，你會在第二個工具出現時喊停。無人值守跑 12 小時，就沒人喊停。所以解法不是叮嚀 agent「不要過度工程」，而是把停損寫成可檢查的規則。

核心做法：量測預算 + 停損

一、先把基準線寫死，由你來給

開工前你自己跑一次，手動量出基準，寫進 prompt。不要讓 agent 自己決定「怎麼量、量什麼」，那正是工具膨脹的起點。

目標：把 `npm run dev` 冷啟動到首頁可互動的時間，從 35 秒降到 15 秒以下。
量測方式（固定，不准改）：執行 scripts/measure.sh，取連續 3 次的中位數。
目前基準：35 秒（我在本機量的）。

重點是「量測方式固定」。量測口徑變來變去，數字就失去比較意義，agent 也有了藉口再寫新工具。

二、給量測工具一個行數預算

這是整套做法裡最有用的一條。在 prompt 或 AGENTS.md 明講：

量測預算：
- 新增的量測／輔助工具總計不超過 150 行，且必須放在 tools/ 目錄。
- 不准新增第二個量測腳本。需要新資訊時，先擴充 scripts/measure.sh。
- 超過預算時停下來回報，不要自行決定繼續。

150 行是我隨手舉的數字，沒有任何出處，請依專案調整。重點是有一個你事後可以用 git diff --stat 一眼驗收的上限。

三、設「每輪必須有指標」的停損

把工作切成回合，每回合結束必須回報一個數字：

每完成一次改動，執行 scripts/measure.sh 並回報：
  改動內容 / 量測中位數 / 與基準差異
連續 3 輪改善小於 5% 就停止，列出已嘗試的假設與結果，等我決定下一步。

這條規則同時解決兩件事：一是逼 agent 用「指標」而不是「產出量」衡量進度；二是在邊際效益遞減時，把決策權交回給人。

四、先分析、再動手：用 plan 階段卡住方向

優化類任務很吃方向判斷。建議先只讓 Codex 出計畫、不改檔，你審過再放行：

先不要改任何檔案。請根據 scripts/measure.sh 的輸出，列出前三個最可能的瓶頸假設，
每個假設附上：驗證方法（用現有工具）、預期收益、預期改動行數。
我挑一個之後你再動手。

「預期改動行數」這個欄位很實用：它會讓 agent 在提案階段就把成本估出來，你才有東西可以對照預算。

把規則落到 Codex 的設定

AGENTS.md 放常駐規則

文件載明：Codex 會從 Git 根目錄一路走到目前目錄讀取 AGENTS.md（同層若有 AGENTS.override.md 則優先），由根往下串接，離工作目錄越近的越晚出現、因此優先。預設有 32 KiB 的合併大小上限（project_doc_max_bytes），可在 ~/.codex/config.toml 調高。所以常駐規則要精簡，塞太滿會被截掉。

建議在做優化的子目錄放一份短的：

# 優化任務規則
- 先量測再改動；量測只用 scripts/measure.sh，不得新增其他量測腳本。
- 輔助工具總量上限 150 行。
- 每次改動後回報：改動／中位數／與基準差異。
- 連續 3 輪改善 < 5% 即停止並回報。

控制單次工具輸出與上下文

第三方整理（Daniel Vaughan 的 Codex CLI 效能文章）列出幾個 config.toml 設定，我沒有逐一對照官方文件，使用前請自行確認你的版本是否支援：

tool_output_token_limit = 12000
model_auto_compact_token_limit = 64000
model_reasoning_effort = "medium"

這幾個設定的用意是：profiler 之類的工具常吐出巨量輸出，限制單次輸出可以避免上下文被量測資料灌爆；而 reasoning effort 開太高會多耗好幾倍 token（該文章提到 xhigh 約是 medium 的三到五倍，屬作者說法）。

兩種跑法的差異

簡單說：放任式把「怎麼量」交給 agent，預算式由你固定口徑並設上限。前者產出行數無上限，後者每一輪都有數字可看。

數據與限制，老實講

12 小時、4,518 行、35 秒這三個數字，只來自貼文標題，我沒有讀到內文，無法確認 35 秒是優化前還是優化後，也無法確認是什麼專案。所以我不拿它推論「Codex 不擅長優化」，那樣太武斷。
上面的 150 行、5%、3 輪都是示範門檻，沒有實驗背書。你該做的是第一次跑時先用寬鬆值，看實際分佈再收緊。
停損規則有代價：有些瓶頸需要先投資量測才看得見（例如要先做 tracing 才找得到慢在哪）。這時請由你明確放行一次「量測投資」，而不是讓 agent 自行擴張。

什麼時候該用、什麼時候別用

適合用預算式停損：

目標指標明確、可重複量測（啟動時間、建置時間、API p95）。
無人值守或長時間執行的任務。
你已經看過 agent 在這個專案上「愛造工具」的前科。

不必這麼嚴：

一次性小修（單檔、十分鐘內能量完）。
探索性研究，目的本來就是理解系統而不是降數字。

對工程團隊的意義：可以照做的清單

開工前自己手動量一次基準，寫進 prompt。
固定量測腳本，禁止新增第二個。
在 AGENTS.md 寫行數預算與停損條件。
每輪強制回報「改動／數字／差異」。
第一步只做 plan，讓 agent 先估預期改動行數。
收工用 git diff --stat 檢查：量測工具佔比如果超過實際修正，就該回頭檢討 prompt。

最後一點最值得記：agent 的工作量可以輕易灌水，指標才是進度。把這個原則寫進規則，比任何「請保持簡潔」的叮嚀都有用。

來源

原始討論：r/ChatGPTCoding 貼文（標題：12 hours, 4,518 lines of tooling it built for…；本文未能讀取內文）https://www.reddit.com/r/ChatGPTCoding/comments/1wvrpho/12_hours_4518_lines_of_tooling_it_built_for/
OpenAI Codex 文件：AGENTS.md 讀取規則（原 developers.openai.com/codex/guides/agents-md，現導向 learn.chatgpt.com）https://learn.chatgpt.com/docs/agent-configuration/agents-md
Daniel Vaughan：Codex CLI Performance Optimisation（第三方整理，設定值未逐一對照官方）https://codex.danielvaughan.com/2026/04/08/codex-cli-performance-optimization/