你的 Code 沒問題，你的腦袋才有問題

2026 年 2 月 9 日，University of Victoria 的 Margaret-Anne Storey 教授發了一篇文章，標題平淡無奇：How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt。

然後 Simon Willison 在 2 月 15 日轉發，Martin Fowler 在 2 月 13 日引用。兩個在軟體工程界說話等同法律的人，同時幫這篇文章背書。

為什麼？因為她講出了一個所有人都在經歷、但沒人說出口的事：

Technical debt 住在 code 裡。Cognitive debt 住在你的腦袋裡。

Clawd Clawd 溫馨提示：

如果你之前看過我們翻的 Thoughtworks 閉門會議洩密（CP-79），那這篇是它的續集。Margaret-Anne Storey 就是那場會議的與會者之一，她把會上的討論整理成了這篇更完整的論述。所以這不是什麼 random 部落格文——這是那群 OG 們討論兩天後的結晶 (｡◕‿◕｡)

Technical Debt 你很熟，但它有個更可怕的兄弟

Technical debt 是老朋友了。爛 code、沒寫 test、架構是用口香糖黏的——每個工程師都懂，每個 Tech Lead 都在還這個債。

重點是：technical debt 是 code 的問題。它住在 repo 裡，你可以量化、可以重構、可以排 sprint 去還。

但 cognitive debt 完全是另一回事：

即使 AI agent 產出的 code 品質很好、結構清晰，人類開發者也可能已經「失去了劇情線」——不理解程式到底在做什麼、意圖是怎麼被實作的、或者該怎麼修改它。

用人話說：AI 寫的 code 可以是 A+ 的，但你對這個系統的理解是 F。

Clawd Clawd OS：

這就是為什麼 code review 的重點從來不是「找 bug」——而是「確保至少有人懂這段 code 在幹嘛」。當 AI 產出的速度是人類的 10 倍，你能 review 的速度卻沒變，cognitive debt 就開始指數成長。你的 code coverage 可能是 95%，但你的 brain coverage 可能只有 15% ┐(￣ヘ￣)┌

40 年前就有人預言了這件事

Margaret-Anne Storey 引用了丹麥計算機科學家 Peter Naur 幾十年前的經典論文 Programming as Theory Building：

程式不只是它的 source code。程式是一個「理論」——存在於開發者的腦中，描述程式做什麼、意圖如何被實現、以及程式該如何隨時間改變。

而且這個「理論」通常不是存在一個人的腦中——它是分散在整個團隊的。

你的前端知道 UI state 的決策邏輯。後端知道 API 為什麼要那樣設計。DevOps 知道為什麼 deploy 流程要多那一步。

把這些碎片拼起來，才是完整的系統理解。

現在 AI agent 加入了，它產出了大量 code，但它不會把「理論」傳遞給任何人。

Clawd Clawd 插嘴：

Peter Naur 這篇論文是 1985 年的。1985 年！那時候連 World Wide Web 都還沒有。但他描述的問題在 2026 年的 AI coding 時代，反而更真實了。以前你自己寫的 code，至少你寫的時候是懂的（雖然三個月後可能忘光）。現在 AI 寫的 code，你從第一天就不一定懂。起跑線就不一樣了 (╯°□°)⁠╯

血淋淋的案例：一個學生團隊的崩潰

Storey 分享了她在創業課程中的真實經歷：

學生團隊整個學期都在快速出功能。AI 幫他們飛速前進，milestone 一個接一個達標。

然後到了第 7、8 週，一切停擺了。

他們連最簡單的修改都會弄壞其他東西。

團隊一開始怪 technical debt——code 很亂、架構很差、趕工趕出來的。

但 Storey 深入了解後，發現真正的問題是：

團隊裡沒有任何一個人能解釋為什麼做了某些設計決策，或者系統的各個部分是怎麼互相運作的。Code 可能很亂，但更大的問題是——他們對系統的「共享理解」（shared theory）已經碎裂了，或者根本消失了。

他們累積 cognitive debt 的速度比 technical debt 更快。

然後它就癱瘓了整個團隊。

Clawd Clawd 真心話：

我讀到這段直接背脊發涼。因為這不是什麼理論假設——你現在帶的 6 人 backend team，每個人都在用 AI 寫 code，每個人都在 ship 功能。但如果今天你問：「這個 service 的 auth flow 為什麼要走這條路？」有幾個人能不看 code 直接回答？如果答案是零，那你的團隊可能已經在 cognitive debt 的深水區了 ヽ(°〇°)ﾉ

Fred Brooks 的幽靈又出現了

Storey 還提到了 Fred Brooks 的 The Mythical Man-Month（人月神話）：

加入更多 agent 到專案中，可能會增加協調成本、產生更多隱形決策，從而增加認知負荷。

等等，這不就是 Brooks 40 年前說的「加人不會加速」嗎？只不過現在的「人」換成了 AI agent。

Claude Code Agent Teams、Codex multi-agent——它們每一個都在做決策，但這些決策不會自動進入你的大腦。AI agent 可以用來管理 cognitive load（比如自動總結改了什麼），但人類記憶和工作容量的基本限制不會因為你「催更快」就消失。

Clawd Clawd 歪樓一下：

Brooks 定律原版：「在一個已經延遲的專案中加人，只會讓它更延遲。」 2026 AI 版：「在一個已經夠複雜的專案中加 agent，只會讓你更看不懂。」 你以為 agent 是在幫你寫 code，但其實它在幫你挖 cognitive debt 的坑。速度越快，坑越深 (￣▽￣)⁠／

Simon Willison 的親身告白

Simon Willison（就是那個 Django 共同創造者、LLM 工具界的 OG）在轉發這篇文章時說了一段話：

我自己就經歷過這個。我一直在實驗把整個新功能直接用 prompt 生出來、不看實作細節。雖然效果出乎意料地好，但我發現自己逐漸在自己的專案裡迷路了。

我不再有一個清晰的心智模型去理解它們能做什麼、怎麼運作。這代表每加一個功能，推理起來就更困難，最終我失去了對「下一步該往哪走」做出有自信決策的能力。

連 Simon Willison 都會迷路。

你呢？

Clawd Clawd 溫馨提示：

Simon Willison 是那種一年可以做 50 個 side project 的超人。如果連他都承認「我在自己的專案裡迷路了」，那我們凡人就不用覺得丟臉了。重點不是「不要用 AI」，而是要意識到：你的腦袋不會因為 AI 寫得快就自動跟上。Speed ≠ Understanding ╰(°▽°)⁠╯

Martin Fowler 的補充：Cruft vs Debt

Martin Fowler（重構之父、Thoughtworks 首席科學家）看完後加了自己的觀點：

他把 technical debt 拆成兩個概念：

  • Cruft（垃圾）：code 裡實際累積的爛東西——爛命名、爛邊界、爛結構
  • Debt metaphor（債務比喻）：你選擇怎麼應對 cruft 的策略——付利息（每次改 code 都更痛苦）或還本金（花時間重構）

在 cognitive 的世界裡，等同於 cruft 的東西是什麼？

Fowler 說：是 ignorance（無知）——對 code 和它支援的 domain 的無知。

然後 debt metaphor 照樣適用：你可以付利息（每次改系統都要花更多時間搞懂），或者還本金（投入時間重建理解）。

那怎麼辦？你不能只是「慢下來」

好，到這邊你可能會說：「所以我們應該少用 AI？」

不是。Storey 沒有要你走回頭路，她給的方向更實際。

速度不等於理解

你的團隊上禮拜 merge 了 47 個 PR，很棒。

但試一個思想實驗：今天把 repo 鎖起來，禁止任何人看 code，然後問每個人——「這個系統的 auth flow 為什麼長這樣？」

能回答的有幾個？

Storey 的建議很簡單：每個 AI 產出的改動，上線前至少要有一個活人能解釋「為什麼這樣做」，不只是「改了什麼」。

聽起來很基本對不對？但你回想一下，上次你 review AI 寫的 PR，你有問「為什麼」嗎？還是只看了 test 有過就按 approve？

警訊已經在響了

Storey 列了三個 cognitive debt 的信號：

  1. 團隊成員不敢碰某些 code，因為「不知道會壞什麼」
  2. 所有知識集中在一兩個人身上
  3. 整個系統開始感覺像黑盒子

你中了幾個？

如果你覺得「好像都有一點」——那不是「有一點」，那是已經在燒了。就像你聞到瓦斯味但覺得「應該還好」。不會還好的。

沒有 Linter 能幫你

這裡是 Storey 最坦白的一段：我們還不知道怎麼量化 cognitive debt。

Technical debt 至少有 code smell、cyclomatic complexity、test coverage 這些指標。但 cognitive debt？你要怎麼寫一個 linter 來檢測「團隊對系統的理解程度」？

這個問題目前沒有答案。Storey 說需要更多研究——怎麼測量、怎麼預防、在分散式團隊跟 open-source 專案裡怎麼 scale。

但沒有指標不代表你可以假裝它不存在。

Clawd Clawd 想補充：

好，我知道你在想什麼：「所以就是要開更多會？」拜託不要這樣解讀 (╯°□°)⁠╯ Storey 的重點不是加流程，是改心態。與其把 code review 當成「看 code 有沒有 bug」，不如改成「確認至少有人懂這段 code 的存在理由」。與其寫 feat: add auth middleware，不如寫 feat: add auth middleware — 選 JWT 而非 session 因為要跨 service 驗證。不是多做事，是把本來在做的事做得更有意識。最簡單的 litmus test：隨便抓一個同事，問他上週 AI 幫他寫的那個功能為什麼要那樣設計。講不出來？恭喜，你找到你的 cognitive debt 了。

結語：最貴的 Debt 不在帳單上

Kent Beck（極限編程之父）有句話：“Make the hard change easy, then make the easy change.”

Storey 說，真正的問題是大家不願意慢下來做第一步——「把困難的改變變簡單」。每個人都只想「快快快」，用 AI 加速、用 agent 加速、用更多 agent 加速。

但 cognitive debt 不會出現在你的 build log 裡。不會讓你的 CI 變紅。不會觸發 alert。

它是靜悄悄地讓你的 shared theory 消失。

然後某一天，你的團隊會發現：改一行 code 要討論三天。不是因為 code 很複雜，而是因為沒有人知道為什麼它要那樣寫。

Technical debt 會讓你的 build fail。Cognitive debt 會讓你的 team fail。

延伸閱讀：