AI 加速的是軟體熵：用深度模組與戰略工程師救程式碼庫
AI 不只加速交付，也加速軟體熵。用深度模組、接縫、局部性與槓桿當共同詞彙，讓 agent 當戰術工兵、人當戰略工程師；先深化與測試防護網，再在遺留庫上放大 AI。
LinkedIn 上成千上萬的 CEO 貼文說：現在寫程式成本很低，速度比以往任何時候都快。
這句話有一半是真的——產出確實變便宜了。另一半常被略過：若每次修改沒有把整個 codebase 納入考量，你也在用同樣的速度，把奇怪的小問題堆進系統。問題會雪球化，直到庫變成一團難以下手的爛泥。
換句話說：AI 不只加速交付，也加速軟體熵。
預防靠好的設計習慣；治療則需要共同語言，以及清楚的人機分工——agent 適合當戰術工兵，人必須當戰略工程師。本文整理一套可操作的詞彙與工作流：深度模組、接縫、局部性與槓桿，以及如何用「改善架構」的巡檢節奏，把失控的 AI 改碼拉回可演化的軌道。
（理論核心來自 John Ousterhout《A Philosophy of Software Design》的 deep／shallow modules；實作節奏則對齊近年「用語彙驅動 agent skill」的做法。）
問題不是「AI 會不會寫」，而是「改完還改不改得動」
Coding agent 很擅長局部、快速的變更。風險在於：
| 局部最優 | 全域後果 |
|---|---|
| 這次 feature 綠了 | 平行實作開始漂移 |
| 介面為了趕工變肥 | 呼叫者每次都要學一堆 |
| 邏輯複製三份 | bug 修一處漏兩處 |
| 測試難掛 | 下次 AI 改動更不敢合 |
產能上升時，若沒有對應的架構紀律，你只是更快抵達「不敢重構、也不敢交給 AI」的狀態。
CEO 看到的是速度；維護者感受到的是熵。
先對齊詞彙：和 AI 講同一種語言
和 agent 協作，精確度取決於共用詞彙。下面這組詞，值得寫進 team 的 CLAUDE.md 或架構 skill 術語表。
模組、介面、實作
- 模組：應用中的一個單位——一頁的 React 元件組、驗證子系統、日誌器……
- 介面：呼叫者正確使用它必須知道的一切（方法、契約、必要文件）
- 實作：介面背後怎麼做（登入 API 怎麼打、token 怎麼存）
好的 codebase：模組靠介面協作，而不是靠「大家都去改同一團細節」。
深度模組 vs 淺層模組
| 介面 | 背後實作 | 感覺 | |
|---|---|---|---|
| 深度（deep） | 相對簡單 | 複雜度高、能力強 | 學一點，能做很多 |
| 淺層（shallow） | 複雜、囉唆 | 實際沒藏多少 | 學一堆，得到很少 |
深度的直覺定義：呼叫者每投入一單位學習成本，能換到多少行為。
優秀開源庫常是深度模組的範本——例如以簡單 hook／API 吞下快取、重試、競態的查詢庫：複雜度在裡面，呼叫者面前是薄介面。
接縫、轉接器、依賴
- 接縫（seam）：模組介面在系統裡「接起來」的位置；常常是測試插入 mock 的地方。
- 轉接器（adapter）：滿足該介面的具體實作（六角形架構直覺）——真實時鐘 vs 測試假時鐘。
- 依賴圖：誰依賴誰；圖越亂，改動爆炸半徑越大。
找接縫、清接縫，是架構改善的日常，不是 indirection 炫耀。
兩個優化目標：局部性與槓桿
改善 codebase 時，把目標收成兩條，避免「為重構而重構」：
| 目標 | 受益者 | 含義 |
|---|---|---|
| 高局部性（locality） | 維護者 | 變更、bug、修復集中在同一深層模組，不散落全庫 |
| 高槓桿（leverage） | 呼叫者 | 介面越深，每單位介面學習換到的功能越多 |
淺層、重複、平行實作，通常同時打傷這兩條：修 bug 要翻三處，學 API 也學不到能力。
典型「該深化」的味道：
- 同一概念前後端各寫一套，沒有單一接縫，一致性靠人腦
- 規則散落在 UI、API、job 三處，改一漏二
- 介面暴露一堆內部步驟，呼叫者變成第二個實作者
治療工作流：人當將軍，Agent 當士官
有一類 skill／提示流程專門做「改善程式碼庫架構」。重點不在工具品牌，而在節奏：
1. 探索：巡庫，找深化機會（淺層、低局部性、平行實作…）
2. 候選：列出幾處「加深後收益高」的點
3. 決策：人挑選 1 個優先項（不要一次全改）
4. 設計對話：討論介面、雛形、TypeScript／契約
5. 驗證細節：對齊現有行為與邊界
6. 落地：人手做，或寫成 issue 交給 AFK／背景代理實作
7. 測試：在新的清晰接縫上補防護網
這類流程要求人類高度在場。關掉「全程自動」往往更合適——自動模式在需要戰略判斷時，容易製造奇怪的半成品。
戰略 vs 戰術
| Agent | 人 | |
|---|---|---|
| 強項 | 掃庫、列候選、草擬介面、快速改碼 | 選戰場、定取捨、對長期健康負責 |
| 弱項 | 易局部最優、不知「什麼不該動」 | 掃全庫慢、易疲勞 |
比喻可以很直白：agent 是優秀的戰術程式設計師（士官巡線）；你是戰略程式設計師（將軍決定哪裡值得打）。
Skill 的價值是把巡線制度化，不是讓你交出指揮權。
建議：在快速變動的庫，每隔幾天跑一次這類巡檢；每次只深化一處，累積深度，而不是週末神話式大重寫。
與測試、遺留庫、AI 採用的閉環
這是最值得記住的因果鏈：
模組加深
→ 接縫變清楚
→ 高槓桿模組更好測
→ 測試成為 AI 改碼的防護網
→ 你才敢在遺留庫上放大 agent 的改動面
很多人問：「遺留系統怎麼開始用 AI？」
遺留在實務上多半等於：很難改的糟糕庫，常充滿淺層模組。
若還沒有防護網就讓 agent 到處改，熵只會加速。
因此起點往往不是「全庫 AI 重寫」，而是：
- 找出可深化、高價值的模組
- 收斂介面與局部性
- 在接縫上補測試
- 再讓 agent 在網內做戰術推進
測試寫得越好，AI 產出通常也越可用——不是因為模型變神，是因為驗收面變硬。
和「產能暴漲」系列怎麼接
| 層級 | 命題 |
|---|---|
| 組織 | 寫 code 快 100 倍後，卡在 PM／法務／整條鏈 |
| 小隊 | 高脈絡工程通才小隊做端到端閉環 |
| 本篇 · 程式碼 | 閉環裡的變更必須朝深度與接縫演化，否則 AI 在加速熵 |
通才小隊若只有速度沒有深度語言，會變成高速製造技術債的小隊。
深度模組與定期架構巡檢，是工程小隊的「內功」；平台 CI、設計系統、資安掃描則是外功護欄——兩者都要，角色不同。
可執行的最小實踐
本週就可以做：
- 在團隊詞彙表寫下：deep／shallow、seam、locality、leverage。
- 選一個真實痛點模組，畫出：誰呼叫它、介面是什麼、複雜度藏在哪。
- 找一處「平行實作／邏輯三處」——評估能否收成單一深度模組。
- 為新接縫補測試，再允許 agent 大改該區域。
- 建立固定節奏：架構巡檢 skill（或 checklist）→ 人挑選 → 小步深化。
明確不要：
- 無目標的「全面重構週末」
- 讓 agent 全自動「優化架構」然後直接合主幹
- 在零測試的淺層泥沼上放大 AI 產出
結語
AI 讓建造變便宜，並不自動讓系統變健康。健康來自介面背後的深度、變更的局部性、接縫上的測試，以及——在代理時代更關鍵的——人是否仍掌握戰略：什麼該加深、什麼不該動、什麼叫長期可演化。
Agent 可以巡庫、可以提案、可以寫 diff。
什麼對程式碼庫的長期健康有益，仍須高於模型的視角來裁定。
先減熵，再加速。
先加深模組，再放大 AI。
先接縫與測試，再談遺留庫全面 agent 化。
那才是在「寫程式前所未有地便宜」的年代，仍能把系統從爛泥裡拉回來的方法。
延伸閱讀
- John Ousterhout, A Philosophy of Software Design（深度／淺層模組）
- 寫 code 快 100 倍之後：真正卡住的是整條鏈
- 高脈絡通才小隊：AI 時代工程開發的組織單元
- 當實作不再是瓶頸：把「選擇與驗證」工程化
- 掌控思想，而非代碼
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。