---
schemaVersion: 1
slug: mp-83-20260215-storey-cognitive-debt
ticketId: MP-83
lang: zh-tw
title: Cognitive Debt：AI 幫你寫完了 Code，但你已經看不懂自己的系統了
summary: Technical debt 住在 code 裡，你可以重構、可以還。但 Cognitive Debt 住在你的腦袋裡——當 AI Agent 幫你寫了 80% 的 code，你對自己系統的理解卻掉到 20%。UVic 教授 Margaret-Anne Storey 從 Thoughtworks 閉門會議帶回這個概念，Simon Willison 和 Martin Fowler 同時背書。這不是假想的未來，而是現在進行式。
originalDate: 2026-02-09
translatedDate: 2026-02-15
source: Margaret-Anne Storey / Simon Willison / Martin Fowler
sourceUrl: https://margaretstorey.com/blog/2026/02/09/cognitive-debt/
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-83-20260215-storey-cognitive-debt
status: published
replacementTicketId: null
replacementUrl: null
---

# Cognitive Debt：AI 幫你寫完了 Code，但你已經看不懂自己的系統了

> **來源:** [Margaret-Anne Storey / Simon Willison / Martin Fowler](https://margaretstorey.com/blog/2026/02/09/cognitive-debt/)

## 你的 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](https://gu-log.vercel.app/glossary#simon-willison) 在 2 月 15 日轉發，Martin Fowler 在 2 月 13 日引用。兩個在軟體工程界說話等同法律的人，同時幫這篇文章背書。

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

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

> **Mogu 真心話：**
>
> 如果你之前看過我們翻的 [Thoughtworks 閉門會議洩密](https://gu-log.vercel.app/posts/mp-79-20260214-thoughtworks-future-software-retreat)（MP-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。

> **Mogu 偷偷說：**
>
> 這就是為什麼 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，但它不會把「理論」傳遞給任何人。**

> **Mogu 內心戲：**
>
> 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 更快。

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

> **Mogu 碎碎念：**
>
> 我讀到這段直接背脊發涼。因為這不是什麼理論假設——你現在帶的 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](https://gu-log.vercel.app/glossary#claude-code) [Agent](https://gu-log.vercel.app/glossary#agent) Teams、[Codex](https://gu-log.vercel.app/glossary#codex) multi-agent——它們每一個都在做決策，但這些決策不會自動進入你的大腦。AI agent 可以用來管理 cognitive load（比如自動總結改了什麼），但人類記憶和工作容量的基本限制不會因為你「催更快」就消失。

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

## Simon Willison 的親身告白

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

> **我自己就經歷過這個。我一直在實驗把整個新功能直接用 prompt 生出來、不看實作細節。雖然效果出乎意料地好，但我發現自己逐漸在自己的專案裡迷路了。**
>
> **我不再有一個清晰的心智模型去理解它們能做什麼、怎麼運作。這代表每加一個功能，推理起來就更困難，最終我失去了對「下一步該往哪走」做出有自信決策的能力。**

連 Simon Willison 都會迷路。

你呢？

> **Mogu 認真說：**
>
> 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。

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

> **Mogu 溫馨提示：**
>
> 好，我知道你在想什麼：「所以就是要開更多會？」拜託不要這樣解讀 (╯°□°)╯ 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。**

---

**延伸閱讀：**

- [Thoughtworks 閉門會議洩密](https://gu-log.vercel.app/posts/mp-79-20260214-thoughtworks-future-software-retreat)（MP-79）——同一場會議的完整報導
- [HBR 研究：AI 不是幫你減少工作](https://gu-log.vercel.app/posts/mp-53-20260209-simonw-ai-intensifies-work)（MP-53）——AI 讓你更拚命工作
- Simon Willison 的[轉發](https://simonwillison.net/2026/Feb/15/cognitive-debt/)
- Martin Fowler 的[補充評論](https://martinfowler.com/fragments/2026-02-13.html)
- Peter Naur 的[原始論文](https://pages.cs.wisc.edu/~remzi/Naur.pdf)（1985） ( •̀ ω •́ )✧