把更貴的模型換上去，產出品質沒有等比提升——這是不少團隊導入 AI 編程代理（coding agent）後的真實感受。模型能力確實在進步，但決定一個 AI 代理能否真的加速開發的，往往不是它寫程式的能力，而是它能不能「看懂你的專案」。
模型很強，但專案脈絡才是真瓶頸
AI 代理在公開 benchmark 上的表現愈來愈好，可是這些評測多半是孤立的演算法題或單檔修改。真實專案完全是另一回事：跨檔案的依賴、團隊內部約定俗成的命名、半套自製的框架、過去某個 PM 留下的奇怪欄位、還有不寫在文件裡的業務規則。
舉個例子，假設一個典型的中型電商系統，訂單狀態橫跨好幾個服務，折扣規則散落在三四個地方。你叫代理「加一個新的折扣類型」，模型本身沒問題，但它如果只看到單一檔案，就會寫出語法正確、邏輯卻錯的程式碼——因為它不知道折扣最終會在另一個服務裡被重新計算一次。
這就是為什麼 retrieval、上下文壓縮、專案索引這些「不性感」的議題，在 2026 年反而成了 AI 工具競爭的主戰場。Cursor、Claude Code、GitHub 的 agent 模式，差別愈來愈不在背後的模型，而在於它們如何把對的檔案、對的歷史紀錄、對的 lint 規則塞進有限的 context window。
真正會用 AI 代理的團隊，反而更重視紀律
反直覺的一點：愈是仰賴 AI 代理的團隊，工程紀律反而要愈嚴。原因很簡單——當生成速度變快，code review 的負擔會線性放大。如果原本一週合併幾十個 PR，現在可能變成上百個，但人類審查的頻寬沒有變。
我們的經驗法則是，在建議客戶導入 AI 代理前，會先看三件事：
- 測試覆蓋率夠不夠：沒有自動測試，AI 寫的程式碼等於沒被驗證。
- 型別系統嚴不嚴格：TypeScript 的嚴格模式、Rust 的 borrow checker，這些都是免費的審查員。
- PR 顆粒度小不小：代理一次塞給你三百行改動的 PR，沒人能好好讀。
換句話說，AI 代理不是把工程師變成「按按鈕的人」，而是把工程師的角色往上推一層——從寫程式，變成設計約束、審查產出、維護專案脈絡的人。沒有這些前置條件，導入再強的代理也只是讓技術債生成速度變快而已。
我們的觀察
選 AI 編程工具時，不要只看模型分數。比較實際的問題是：它怎麼讀你的 codebase？它能不能跑你的測試？它生成的 diff 是不是適合審查？這些工程化的細節，比模型本身的 IQ 對日常生產力影響更大。模型還會繼續變強，但真正的競爭優勢，會留給有紀律地把它整合進開發流程的團隊。