AI 寫得更快，你真的懂嗎？

此為 2026-04-24 於 DDD Taiwan Meetup 演講簡報。
活動連結：https://www.accupass.com/event/2604151522131437099244

--

AI 大幅加速開發，但工程師對系統的理解卻未必同步提升，
進而累積兩種隱性風險：認知債(Cognitive Debt)與理解債(Understanding Debt)。

講者 James 以自身實戰經驗，說明為何常見方法難以真正解決認知與理解問題，
並透過傳統工程實踐建立穩固的工程紀律。

在 AI 時代，世界越快，越要放慢腳步。

--

參考資料：

(1). Anthropic 今年一月釋出一份報告：
對於程式碼的理解能力，使用 AI 輔助寫程式的，比不用 AI 的人，能力明顯的下降，其中 debug 能力更是下降的最多。
- https://www.anthropic.com/research/AI-assistance-coding-skills
- https://arxiv.org/abs/2601.20245

(2). Margaret-Anne Storey 的經驗
- https://margaretstorey.com/blog/2026/02/09/cognitive-debt/

Transcript

1. D D D TA I WA N M E E T U P · A P R I L 2 0 2 6 AI 寫得更快， 你真的懂嗎？ James
2. 你多久—— 沒有和團隊 一 起站在 白 板前， 把事情吵清楚了？
3. 個 人 自 白 三個 月 前的週 一 早上， 我花了整個上午和 AI 討論架構。 Bounded context、aggregate 邊界、事件流、介 面 ——每個問題，AI 都回得很 漂亮。 圖、 文 件、spec，全都有了。 中午關掉電腦：「我今天，好有效率。」
4. 幾 天 後 ， 團 隊 R E V I E W 「基於什麼決策，決定這個 方 案？」 「還有其他 方 案嗎？」 三秒鐘的沉默
5. 那 一 刻的頓悟 我「知道」這個設計是對的，因為 AI 說服了我。但站在 白 板前被追問那 一 刻 —— 我根本不懂， 我 自己 到底同意了什麼。 那個上午，我不是在思考架構。 是在看 AI 思考架構。 我不是沒在 工 作。 我只是忘了——思考本 身 ，才是我的 工 作。
6. 另 一 個故事 有 一 個團隊。 他們導入 AI 之後，初期有些磨合， 一 開始不太順。 但慢慢地，他們找到了節奏。 然後，他們的表現——越來越好。
7. A 團隊 · 導入初期 效果驚 人 。 產出速度 2× PR 數量翻倍 進度 Velocity Sprint 提前完成 DEBUG 30分 貼 log，AI 搞定
8. 三個 月 後 「先丟 AI」成了團隊的第 一 反應。 遇到奇怪的 log → 丟 AI 客 戶 抱怨功能 → 丟 AI 新 人 問模組怎麼運作 → 「你先問 AI，不懂再來問我」 沒有 人 再打開 log viewer 了 沒有 人 再拉同事去 白 板前畫圖了 沒有 人 察覺有什麼不對——因為 velocity 還在往上。
9. 週五下午 客 戶 對帳結算系統出事了。 照 SOP，把錯誤訊息貼給 AI。 Round 1 「DB connection timeout，試試連線池設定」 沒解。
10. 週五下午 繼續問。 Round 1 「DB connection timeout，試試連線池設定」→ 沒解 Round 2 「重啟 batch job」 沒解。
11. 週五下午 · 幾個 小 時後 Round 1 「DB connection timeout」→ 沒解 Round 2 「重啟 batch job」→ 沒解 Round 3 「檢查 event queue dead letter」→ 沒解 有 人鼓 起勇氣打開 log viewer。 盯著看了三 十 秒，說不出話。 那個 timestamp 是 UTC 還是本地時間—— 他不知道。 有 人 打開 repo，想看 code。 那個模組，是幾 個 月 前 AI 協助 生 成的。 讀了半 小 時，讀不懂 自 己 當時 merge 過的東 西 。
12. 幾 個 小 時 後 ， 有 人 說 了 一 句 話 — — 「要不然，試試 rollback ？」 最後「運氣好」搞定，不是「救回來」
13. 集體失憶的時刻 COGNITIVE DEBT 認知債 個 人 思考能 力 的退化 忘了怎麼獨立 debug 忘了怎麼讀 log 忘了怎麼 追 code UNDERSTANDING DEBT 理解債 團隊知識架構的空洞 沒 人 懂系統的設計決策 沒 人 記得當初為什麼 沒 人 能解釋這段 code 平常看不出來。引爆的那 一 天，兩層 一 起還。
14. 敏 捷 宣 言 ， 第 一 條 個體與互動， 勝於流程 與 工 具。 Individuals and interactions over processes and tools.
15. 我們 用 AI ( 工 具)來提升「個體與互動」的效率， 結果消滅了 「個體與互動」本 身 。 這不是 agile 的背叛者幹的。 是我們 自己 ，在安靜地放棄當初寫 下那份宣 言 的理由。
16. M A R G A R E T- A N N E S TO R E Y · U V I C · I C S E 2 0 2 6 K E Y N O T E 累積認知債 的速度， 比 累積技術債更快。
17. P E T E R N A U R · P R O G R A M M I N G A S T H E O RY B U I L D I N G · 1 9 8 5 A program is a theory. 程式不是 code，是 一 個活在 人 腦袋裡的理論 。 AI 能 生 產 code，AI 生 產不出 theory。 洞 見 、理論
18. 什麼是 THEORY？ 想像你蓋了 一 棟房 子 。 程式碼 ＝ 房 子 的實體建築 Theory ＝ 蓋房 子 的 人 腦袋裡的東 西 ：為什麼這根柱 子 在這裡、地基為什麼這樣挖、這 面 牆能不能拆 房 子 蓋完後，那些 人 離開了。 新來的維修 工 程師可以量每 一 面 牆、看每 一 根管線—— 但不知道當初為什麼這樣決定。 你以為核 心 是 PETER NAUR 說真正的核 心 是 程式碼 工 程師腦袋裡的 theory 文 件 Theory 的殘影 重構、維護 重建 theory，不只是改 code
19. 問題從來不是「AI 寫的 code 好不好」。問題是—— 你的腦袋， 有沒 有在場？
20. 解法：紀律派三道防線 核 心 判準：把 AI 當「團隊成員」，不是「代寫者」 1 進場前 建立 Theory 白 板先吵，再 prompt AI · Event Storming · Ubiquitous Language · Domain Modeling → 2 進場中 守住 Theory 每個 PR， 至 少 一人 完整理解 · Pair AI and humans（ 人 主導） · BDD / TDD 先定 行 為邊界 · 講得出來的 Review → 3 進場後 擴散 Theory 讓知識跨時間流動 · ADR：記錄 Why · AGENT.md：AI 記憶 · Retro 追問決策
21. 第 一 道防線：進場前 先把 Theory 建起來， 再請 AI 補 code。 順序不能反。 白 板上 30 分鐘的「慢」，讓你後 面 和 AI 的對 話完全不同—— 你不是在「問 AI 該怎麼做」， 是在「請 AI 補完 一 個你已經有 theory 的設 計」。 EVENT STORMING 用 便利貼和 馬 克筆，把領域事件攤開 UBIQUITOUS LANGUAGE 用大 家都懂的語 言 ，把概念對 齊 DOMAIN MODELING 在 白 板前吵出邊界、吵出 aggregate
22. 第 二 道防線：進場中 寫 PR 的 人 ，和 Review 的 人 ， 都要能 用 嘴巴講出來。 不是眼睛看過。不是測試綠了就好。 是——能 講出來。講不出來，退回去重新理解。 不叫 pair programming，叫 人 × 人 × AI 協 作 。 開發過程中就 一 起，不是事後 review 才 碰。 慢了 20%。但崩潰的那天， 他們知道從哪 裡開始查 。 人 × 人 × AI 協作 開發過程中就 一 起思考，不只是事後 review。 人 主導 theory，AI 補實作。 BDD / TDD 先 用 測試定下 行 為邊界，再讓 AI 補實作。 測試是你 theory 的具體化。 講得出來的 REVIEW 發 PR 的 人 和 reviewer，都要能說清楚 「這段在幹嘛， 為什麼這樣寫」。
23. 第三道防線：進場後 讓 Theory 不只活在今天這幾個 人 的腦袋裡。 工 具 一 ：ADR Architecture Decision Records # 我 面 對什麼問題？ # 考慮了哪些選項？ # 最後選了哪個？ WHY: "為什麼是這個" 三個 月 後有 人 問——你還有答案，AI 也有答案。 工 具 二 ：AGENT.MD ＋ 週會 AI 時代才有的新 工 程紀律 每次 pair 結束，花 10 分鐘問 AI： 「我們這次學 到了什麼？」 → 寫進 AGENT.md。 每週固定 一小 時，整個團隊 同步這週學到了什麼。 人 和 AI 一 起，整理給下 一 組 人 和 AI。 知識，最終留給 人 和 人 。 過去的 工 程紀律，是給 人 看的。 AI 時代的 工 程紀律，要給 人 與 AI 一 起看。
24. 好 。 三 道 防 線 都 在 這 裡 了 。 問題從來不是知不知道 。 是 ——你，決不決定做？
25. 把決定權還給你 AI 加速開發，不會停下來。 觀望 等業界成熟了再說 合理的選擇。你有 sprint 要交付， velocity 要達標， 工 具政策未必是你能決定的。 行 動 從下 一 個 PR 開始 不 用一 次到位。 從你 自己 的桌 子 開始，建立你的新紀 律。 認知債和理解債，不會因為你在等， 而 停 止 累積。
26. 帶 人 的 人 ，請聽這 一 段 我們只教他們 AI Agent 多好 用 、 prompt 怎 麼寫—— 我們等於在剝奪他們成長的權利。 思考能 力 ，只能透過掙扎 長出來。 不能 透過 AI 代勞。 請教他們——怎麼在 用 AI 的同時，保住 自己 的腦袋 。這是我們的責任。
27. 我 再 問 一 次 你多久—— 沒有和團隊 一 起站在 白 板前， 把事情吵清楚了？ 如果你的答案是「很久了」——那我今天分享的，就是為了你。
28. 明天，做 一 件事 挑你下 一 個 PR。Merge 之前，關掉 AI。 用 你 自己 的嘴巴，對著你桌上的 小 黃鴨 ——講 一 次： 「這段 code 在幹嘛，為什麼這樣寫。」 講得出來 恭喜你。你的腦袋還在場。 講不出來 那，我今天這 30 分鐘，就有價值了。
29. AI，寫得快。 你——懂得慢。 但懂得慢，才走得遠。 J A M E S · D D D TA I WA N M E E T U P · A P R I L 2 0 2 6