最近 Matt Pocock 在 AI Engineer Europe 上的一場演講「Software Fundamentals Matter More Than Ever」（軟體基礎比以往任何時候都更為重要）很紅。中文社群也已經有幾篇不錯的轉述文，把他演講裡的五個失敗模式、五個 skill 整理得很清楚（grill me、ubiquitous language、TDD、deep modules、介面/實作分離——對，就是那五個）。
我自己看完整段逐字稿之後，倒是想問一個 Pocock 沒回答、轉述文章裡也沒人處理的問題：
為什麼資深開發者，特別容易嫌 AI「太囉唆」？
這個感受，Pocock 在演講裡有提到（他列為失敗模式之二），他給的解法是 ubiquitous language——建立人與 AI 之間的共通詞彙表。聽起來像是技術調整。
但仔細想，「AI 太囉唆」這個情緒，跟字數多寡、技術深度、回答速度通通沒關係——AI 講的東西多半是對的，速度也比 Stack Overflow 快太多。那真正讓我們不爽的是什麼？
我跟 小思（Claude）來回討論了好幾輪，逐漸意識到：Pocock 這場演講的表層講了很多東西，但底下藏著一層他刻意沒明說的事——而那一層，正是「囉唆」這個感受的真正來源。
這篇就是要把那層挖出來聊聊。
先快速說一下 Pocock 在做什麼
給還沒看過影片的人快速補充一下背景。
Pocock 這場 18 分鐘的演講，結構非常乾淨：他先批判目前流行的「specs-to-code」路線（也就是 SDD 光譜上最極端的那一端，把規格當成唯一真理、程式碼（code）是編譯產物、人不看 code 只改規格），然後拋出他的反命題——「code is cheap」這個口號錯了，bad code 在 AI 時代反而是史上最貴，因為它讓你接不到 AI 的紅利。
接著他列了五個多數開發者都遇過的失敗模式，每個對應一個解法：
| 失敗模式 | Pocock 的解法 | 出處（文後附註） |
|---|---|---|
| AI 沒做到我要的 | grill me（讓 AI 拷問你直到對齊） | Brooks《設計的設計》 |
| AI 太囉唆 | ubiquitous language | Evans《領域驅動設計》 |
| AI 寫的 code 跑不動 | TDD | Kent Beck |
| codebase 變成 AI 自己也走不出來的迷宮 | deep modules | Ousterhout《軟體設計哲學》 |
| 你的腦袋追不上 AI 的速度 | 設計介面、委派實作 | Pragmatic Programmer |
注意他引用的全部是 20 年以上的老書——這個修辭安排本身就是論點。他在說：你過去學的東西沒過時，反而更值錢了。
這場演講的目標聽眾很明確：是已經有 20 年功夫、但對 AI 半信半疑的資深開發者。他開場那句「給那些覺得自己技能不再值錢的人一個安慰的訊息」，就是寫給這群人。
所以這場演講的真正功能不是教學，是入場邀請——他在用一群手刻派最熟悉的詞彙（介面、模組、TDD、領域語言）跟他們說：「來，這裡有你的位置。」
但我們要看的不是這個。
我們要看的是——他用這套包裝在勸資深者接受什麼？
「AI 太囉唆」這個抱怨，到底在抱怨什麼？
回到那個問題：為什麼資深開發者特別容易嫌 AI 囉唆？
我自己一開始用 Claude Code 寫東西時，也覺得它煩。問一個簡單的問題，它要先給我一段背景說明、列出三種選項、附上 trade-off 分析、最後才回答。我心裡的反應是：「我又不是新手，這些我都知道。」
但仔細想——讀過 RFC 跟 spec 的我們，從來沒嫌那些東西「太囉唆」啊。技術文件比 AI 冗長一百倍，我們甘之如飴。那為什麼 AI 講得稍微多一點，我們就不耐煩？
跟 Claude 對話到一半，我們挖出了真正的原因：
不是字數的問題，是 AI 不假設我們知道任何東西。
每次互動，AI 都從零開始。它對 30 年老兵跟剛入行的新人講一樣多的話，給一樣完整的脈絡、定義、選項、權衡。這對新手是恩賜，對我們而言是——降階。
在傳統工程團隊裡，我們資深者享受著一種「不被解釋的特權」。
Junior 不會跟我們解釋什麼是 mutex；程式碼審查者 看到我們的合併請求會放鬆閾值；新人問問題前會先評估「這會不會讓我看起來蠢」。整個團隊的社會結構，在保護資深者免於被「過度解釋」。我們發出一個短指令、一個縮寫、一個半句話，旁邊的人會自己補完意思。
這個特權是資歷的副產品——你混得夠久，就會自然累積。
但 AI 沒有這個社會結構。AI 對所有人一視同仁。
這個一視同仁，對新手是公平、對我們是降階。我們不再享有「不用解釋」的位置，每次互動都被當成第一次見面的客戶來對待。「囉唆」這個感受，本質上是省略特權被收回的徵兆。
不是 AI 的 bug。是 feature。
權力結構的翻轉：誰才是全知的一方？
更深一層的不舒服，藏在我們自己沒意識到的權力預設裡。
我們以為我們在「指揮」AI——下指令、它執行；下需求、它寫 code。這是延續傳統「人類設計、機器執行」的世界觀。
但仔細看 Pocock 的 grill me：「無情地拷問我這個計畫的每個面向，直到我們達到共識。」
這個指令發出去之後會發生什麼？AI 會問你 40 個、60 個、有時候 100 個問題。
等一下——這個位置在傳統團隊裡是誰的位置？
是分析師。是 PM。是資深工程師對客戶做需求收集時的位置。grill me 把 AI 從「執行者」抬升到「分析師」位置，這意味著——發出 grill me 指令的瞬間，我們其實是在說：「我承認我自己沒講清楚，需要你來把我問清楚。」
這對資深者的自我認知，是有衝擊的。因為它預設「我不是全知的那一方」。
而事實上，AI 確實是全知的。它讀過全部的書、見過所有的 pattern、記得每個 API 的每個參數。它唯一不知道的是——你腦中這個具體 codebase 的具體現況跟具體意圖。
所以權力結構其實長這樣：
- AI 知道所有泛用知識，但不知道你的特定脈絡
- 你知道你的特定脈絡，但不再壟斷泛用知識
這個結構在傳統團隊裡是有對應位置的：AI 是那個讀過所有書、但剛加入團隊的天才新人。他什麼都懂，但不認識你們的 codebase、不認識你們的領域、不認識你們團隊的決策歷史。所以他需要問。
而我們過去面對「天才新人」時的姿態——耐心解釋、把預設攤開、用人話而不是縮寫——現在被 AI 強迫重演。差別只在於，天才新人會學、會記住、下次不用再問；AI 沒記憶（除非你給它），所以它每次都要重新問。
「囉唆」是這個結構的必然副作用。
而真正的工作量不在 AI 那一側——AI 那邊的全知已經在那裡，你只要會問就拿得到。真正需要學會「攤開內心」的，是我們這一方。
這句話讀起來輕，但它的含意很重：過去資深者引以為傲的「言簡意賅」——一個縮寫攜帶五層意義的高密度溝通模式——在 AI 場景裡反而變成低解析度輸入。我們得學會把腦中的隱性知識重新講成人話。
而這件事，不是技能升級。是身分調整。
三條解法，三種程度的權力讓渡
Pocock 給的工具，剛好可以對應到三條程度不同的權力讓渡路徑：
第一條：每次讓 AI 問（grill me）
這是門檻最低、心理成本最低的路。你只需要在每次工作開始前，丟一段 grill me 提示詞，讓 AI 把你問到清楚為止。
但情感負擔最重——每次都要忍受被當新人問。對話結束、脈絡散掉，下次又重來。而且每次拷問完，你會清楚意識到「啊我剛剛根本沒想清楚」這件事。對某些資深者來說，這個小小的羞辱感，每次累積起來會變得很消耗。
第二條：累積記憶（CLAUDE.md、長期 session、persistent context）
你願意投資基礎建設，讓 AI 累積對這個專案的脈絡。權力讓渡多一點——你承認這個工具值得被持續投資、你願意花時間餵它。
回報是它越來越像「老團隊成員」、不再每次都從零開始問你「這個專案用什麼框架」「程式風格規範是什麼」。
但這條路要求你承認 AI 是「會留下來的同事」——不是用完就丟的工具。對某些資深者，光是這個心態調整就需要時間。
第三條：自己寫 ubiquitous language
這條路權力讓渡最深。你主動把腦中的隱性知識外部化、攤成人話文件、列成 markdown 表格。
寫一份 ubiquitous language——不是給 AI 的、是給自己用的。
我意思是：寫這份表的過程，迫使你把腦中那些「不用講大家都懂」的詞攤開、定義、寫成人話。寫完之後，你對自己 codebase 的理解被外部化了。AI 順便受惠，但真正的受益方是你自己。
但這條路有個代價——你等於把資深者「省略的特權」永久放棄。寫進 markdown 的東西就不再是「不用講大家都懂」，而是白紙黑字寫死。資深性的一部分，本來就建立在「我可以省略，因為大家都懂」這個心照不宣的默契上；攤成 markdown 之後，這個默契就解除了。
簡單來說：
| 路線 | 權力讓渡 | 心理成本 | 長期回報 |
|---|---|---|---|
| grill me | 最少 | 每次都被拷問的小羞辱 | 單次對齊好、但要重來 |
| 累積記憶 | 中 | 承認 AI 是長期夥伴 | AI 變成老團隊成員 |
| 自寫詞彙表 | 最多 | 放棄省略特權 | 思維被永久外部化 |
多數人會選第一條，少數會走到第二條。真正能走到第三條的，已經完成了一次身分轉換——他們不再依賴「省略的權力」來證明自己的資深。
這是 Pocock 整場演講真正在勸資深者做的事，但他沒有用「身分轉換」這個詞。他用「ubiquitous language」這個工程詞包裝整件事，讓你感覺只是學一個新 skill。
Pocock 為什麼不直接講？
這就是這場演講真正高明的地方。
Pocock 顯然知道他在勸的是身分轉換，不是技能升級。但他完全沒講破。為什麼？
因為他懂他的聽眾。手刻派最大的核心認同就是「我相信長期價值，不被市場潮流牽著走」。如果他直接喊「再不上車就來不及了」「資深者的省略特權要被收回」，會立刻引發兩個反應：
第一，他會被歸進「AI 推銷員」類別——跟那些他在演講開頭批判的 specs-to-code 派沒兩樣。 第二，這種講法會直接打到聽眾的核心認同，激起防衛反應。門就關上了。
所以 Pocock 走另一條路：他用工程詞彙當特洛伊木馬。
「介面」這個詞，攜帶的是 30 年累積的概念負荷——abstraction boundary、information hiding、API contract。聽眾聽到「design the interface, delegate the implementation」，腦中那套熟悉的思維框架自動接管理解工作，舊概念吸收新對象。介面在 module 之間是抽象邊界，在你跟 AI 之間是信任邊界——同一個詞、不同對象，但聽眾不會覺得自己在學新東西。
「ubiquitous language」也是同樣的操作。它讓資深者覺得只是多寫一份文件，而不是要把講話方式打掉重練。
兩個詞都在做同一件事：把實際上滿大的調整，包裝成聽起來只是技術升級的小事。
這個包裝是真誠的，不是欺騙。Pocock 知道——直接講出來，多數聽眾會關門；包裝起來，他們至少會走進來。走進來之後會發生什麼？那是聽眾自己用時間去碰、去撞、去體會的事。
我意思是，這跟我們在企業內訓帶過資深學員的經驗很像。你不能對一個帶 50 人團隊的技術主管說「你的領導風格要打掉重練」——他會立刻反彈。你只能說「來看看這個新工具，試試看怎麼用」，然後等那個工具自己把他帶到該去的地方。
好老師的標誌，不是把答案塞給學生，是把對的問題放在學生會撞到的地方，然後等。
Pocock 就在做這件事。
重新定錨：從匿名使用者到具名脈絡
Pocock 最後拋出的比喻——AI 是地面上的執行兵，你是上層的戰略指揮——其實有點侷限。
戰略指揮官對執行兵的關係是單向的：發號施令、不接收細節、不需要建立共識。但我們跟 AI 的真實關係不是這樣，我們需要互相對齊、互相校正、共同累積脈絡。
更精準的描述也許是這樣：
AI 對所有人一視同仁、所以對所有人都囉唆。唯一恢復「不用解釋的特權」的方法，是讓它認識你。
這個「認識」可以透過 grill me 的單次拷問建立、透過記憶系統的長期累積建立、或透過 ubiquitous language 的明文化建立。三條路本質上都是同一件事——把自己從「匿名使用者」變成「具名脈絡」。
匿名使用者得到的是 AI 對所有人都一樣的標準對待（也就是「囉唆」）。具名脈絡得到的是 AI 為你客製的協作（也就是「夥伴」）。
從匿名到具名，需要的不是學新技能，是承認自己過去享受的「不用解釋的權力」在 AI 場景裡需要重新賺取。
這個賺取的過程，正好就是 Pocock 五個 skill 在做的事。
收尾：給已經走進來的我們
如果你已經讀到這裡，大概是兩種人之一：
一種是已經跟 AI 共事了一陣子的開發者——你可能跟我一樣，曾經嫌過 AI 囉唆。看到這裡也許會點頭：「啊原來那個不舒服是這樣來的。」
另一種是還在門口猶豫的資深者——你看過影片、讀過幾篇轉述、但還沒下決心開始用 Claude Code 或 Cursor 寫東西。
對前者，我想說：那個「囉唆」的感受不會消失——除非你願意走第二條或第三條路，把自己從匿名變成具名。但走過去之後，你會發現另一邊風景不一樣。
對後者，我想說：Pocock 那場演講真正的訊息，是替我們留了一個位置。20 年的工程紀律，不是過時的累贅，而是現在這個時代解鎖 AI 紅利的入場券。但這張入場券有期限——當大量「資深 + AI 用得好」的工程師出現之後，純資深的位置會被擠壓。不是因為我們的技能變差，是因為市場對它的定價變了。
這話 Pocock 自己不會講，他太溫柔。我們可以替他講。
最後一個碎念——
寫這篇文章時，我跟 Claude（小思）來回討論了幾輪。整個過程本身就是這篇文章在講的事的示範：我把腦中的觀察一次次攤開、外部化、跟 AI 對齊。Claude 沒有比我懂 Pocock，但它能幫我把腦中那些飄著的、講不清楚的東西，一個一個逼出來。
這不是「AI 替我寫文章」，這是我跟 AI 一起把我自己腦中的文章挖出來。grill me、ubiquitous language、累積的對話脈絡——三樣 Pocock 講的東西，這場對話裡都用上了。
所以這篇文章某種意義上，就是 Pocock 那場演講的活見證。而我寫完這篇文章之後最大的感覺是——我已經回不去匿名使用者的位置了。
這應該也是好事啦。XD
演講連結：YouTube – It Ain’t Broke: Why Software Fundamentals Matter More Than Ever
Pocock 的 skill repo：GitHub – MattPocockSkills
文中提到的經典書籍
Pocock 整場演講引用的全部是 20 年以上的老書——這個修辭安排本身就是論點。如果你也想回頭翻翻這些書，下面列出完整資訊給有興趣的人參考：
- A Philosophy of Software Design（2nd Edition, 2021） John Ousterhout 著 — Pocock 引用的「複雜的 code 就是難以理解和修改的 code」、deep modules vs. shallow modules 的概念都來自這本。Ousterhout 是 Stanford 教授、Tcl/Tk 的發明者，這本書是他在 Stanford 開「軟體設計」課程多年後濃縮出來的觀察。
- The Design of Design: Essays from a Computer Scientist（2010） Frederick P. Brooks Jr. 著 — Pocock 引用的「design concept」（兩人共同設計時飄在腦中、講不出來、寫不進文件的那個共識）出自此書。Brooks 是《人月神話》的作者，圖靈獎得主。
- The Pragmatic Programmer: Your Journey to Mastery（20th Anniversary Edition, 2019） David Thomas、Andrew Hunt 著 — Pocock 引用的 software entropy（軟體熵）跟 “the rate of feedback is your speed limit” 都來自這本。原版 1999 年出版、20 週年紀念版於 2019 大幅改寫。是技術圈的經典。
- Domain-Driven Design: Tackling Complexity in the Heart of Software（2003） Eric Evans 著 — Pocock 整段 ubiquitous language 的論述基礎。DDD 的開山之作，影響了後來整個微服務、領域建模的思考方式。
- Test-Driven Development: By Example（2002） Kent Beck 著 — TDD 的開山經典。Pocock 收尾引用的「invest in the design of the system every day」精神也來自 Kent Beck 的一系列著作。
這幾本書，我想不少資深開發者應該多少都有個其中幾本。即使在 AI 時代讀起來，反而更有味道——因為現在我們才終於知道，這些書當初是寫給未來的我們看的。
