為了最大化AI Agent 效率，我們是否應該放棄部分人類對程式碼結構和命名的控制權？ 來自@AmpCode 團隊@rockorager 的文章“A Codebase by an Agent for an Agent”，提出了一個新的趨勢：隨著AI Agent 更深入參與開發，代碼結構是否要從以人為主，演進到以AI Agent 為主要考慮？ 核心衝突：人類直覺vs. AI 直覺作者在使用Amp 發展一個TUI 框架時，最初習慣於用人類的程式設計經驗去修正AI 的決策。例如，當AI 將一個螢幕刷新函數命名為present() 時，作者根據自己的習慣將其重新命名為swapScreens()。 然而，作者發現這種「人為修正」反而產生了負面效果。當AI 後續試圖再次修改或呼叫該功能時，它會基於其訓練資料中的機率去尋找present()，結果因找不到而感到困惑，導致消耗更多Tokens 並降低了工作效率。 實驗轉折：放權給AI 意識到這一點後，作者改變了策略，不再乾預AI 的命名習慣或文件存放位置，完全讓AI 自主決定代碼的「風水」。 結果令人驚訝：效率大幅提升。儘管AI 產生的程式碼使用了作者平時不會採用的命名方式、文件結構，甚至是一些非典型的物件導向模式，但AI 在這個它親手打造的環境中如魚得水。它能極快地理解並未被文件化的複雜框架，精準地添加新功能或修復Bug。 深度洞察：為AI 優化的程式碼庫文章得出的關鍵結論是，AI 的高效不僅源於其編碼能力，更源於程式碼庫本身是否符合AI 的「思維模式」。 · 機率的一致性：AI 是基於機率模型工作的。當程式碼庫的結構和命名順應AI 模型權重的預測（即符合其訓練資料中的統計規律，如類似Flutter 的API 設計）時，AI 就不需要「猜測」或「重新學習」程式碼邏輯，從而達到最高的運作效率。 · 新的平衡：作者認為，這誕生了一種新型的程式庫－「By an Agent, For an Agent」。這種程式碼庫在某種程度上犧牲了人類偏好的“可讀性”，換取了AI 極致的“可維護性”和執行速度。 閱讀原文
