強烈推薦看看這個演講，還配套 7 萬 Star 的開源 Skill。

視頻：https://www.youtube.com/watch?v=v4F1gFy-hqg

AI 令寫 code 快咗，但 code 從來冇變得更平。

呢個係 Matt Pocock 喺大會演講嘅核心觀點。

佢係前 Vercel 開發者佈道師，Total TypeScript 作者，而家搞咗個叫 AI Hero 嘅平台，專門教人用 AI Coding。

呢場演講發佈兩星期就 60 萬播放量，18 分鐘，資訊密度極高。

佢教咗 18 個月 AI Coding 之後，發現咗一個規律：嗰啲用 AI 用得好嘅開發者，唔係乜都交俾 AI 做嘅人，亦唔係乜都自己寫嘅人。

係嗰啲回歸工程基礎嘅人。

佢仲根據自己嘅 AI Coding 經驗整咗幾個 Skill，而家開源咗。

01

AI Coding 嘅兩個極端都有問題

而家行業入面對 AI Coding 有兩種極端態度。

一種係 vibe coding。

呢個詞係 Andrej Karpathy 提出嚟嘅，簡單講就係憑感覺叫 AI 寫 code，描述個大概，然後祈禱佢行得鬱。

另一種係 specs-to-code。

寫一份詳細嘅規格說明書，直接掟俾 AI 叫佢生成。呢派嘅假設係：code 係平嘅，規格先係珍貴嘅。

Matt 話呢兩個都有問題。

vibe coding 嘅問題好明顯：失控。你唔知 AI 寫咗啲乜，亦唔知佢點解咁寫，改起上嚟更加係災難。

但 specs-to-code 嘅問題更加隱蔽。

佢假設 code 係平嘅，但實際上，AI 生成嘅 code 同人類寫嘅 code 一樣，都會爛、會積累技術債、需要維護。

Code 從來都唔平。AI 只係令你快啲產出 code，但唔會幫你諗點組織 code。

Matt 嘅觀察係：真正成功嘅開發者，唔係全部交曬俾 AI 亦唔係全部自己寫。佢哋將 AI 當作一個超級實習生——執行力強，但你要俾清晰嘅方向同約束。

點樣俾清晰嘅方向？接下來就係佢嘅四個方法論。

02

唔好急住寫 code，先俾 AI 拷問一輪

Grill Me 係 Matt 開源嘅一個 Claude Code Skill。

即係前排成日掛喺 GitHub 開源熱榜嗰個 Skill 入面嘅。

佢嘅邏輯好簡單：喺動手寫任何 code 之前，叫 AI 先拷問你一輪。

唔係你問 AI，係 AI 問你。

佢會沿住你設計決策樹嘅每一個分支行落去，一條一條咁將模糊嘅想法逼成清晰嘅方案。

依賴關係、邊界條件、數據模型，全部都唔放過。

Matt 話佢每日收到大約 5 條消息，都係開發者話用咗 Grill Me 之後大開眼界。

Reddit 上都有人專登出帖講呢個 Skill 徹底改變咗佢用 AI 做規劃嘅方式。

後來 Matt 又進化咗一個升級版，叫 /grill-with-docs。

唔單止拷問你，仲會將拷問過程中達成嘅共識即時寫入一個叫 CONTEXT.md 嘅檔案。

如果你要問同 SuperPowers 嘅 Brainstorming 有咩分別，我用起上嚟嘅感覺係：

Brainstorming：適合任何新功能、新項目、重構啟動前嘅設計階段。

Grill-with-docs：更適合已有 code base 嘅項目，你需要對一個具體方案做決策、對齊術語、同步建立文檔。

如果你嘅項目仲未有 CONTEXT.md 體系，佢都會幫你從頭建立。

咁做嘅好處係咩？

傳統開發中，你腦入面對系統嘅理解同 code 之間總有 gap。

有咗呢個檔案，AI 喺後續所有開發中都有一份共識詞典可以參考，唔使每次都重新解釋一次。

簡單講，Grill Me 迫你喺寫 code 之前先諗清楚個設計。

AI 唔會幫你做決策，佢只會加速你已經做咗嘅決策。如果你自己都未諗清楚，AI 加速嘅只係混亂。

03

統一語言

令人、code 同 AI 講同一種話

Ubiquitous Language 呢個概念嚟自Eric Evans 2003 年出版嘅經典《領域驅動設計》。

核心思想係：令 code、開發者同領域專家都講同一套術語。

聽落理所當然，但實際操作中好少團隊做到。產品經理講一個詞，開發者理解成另一個意思，code 入面嘅命名又係第三樣嘢。

喺 AI 時代，呢個問題被放大咗。

因為 AI 冇隱含上下文，佢唔明你嘅暗示同慣例。

你說的用戶同 code 入面嘅 User 係咪同一樣嘢？你講嘅訂單同數據庫入面嘅 Order 係咪同一個概念？

如果你唔講清楚，AI 就會自己估。估錯咗，你就要做返工。

Matt 嘅做法係喺項目根目錄維護一個 CONTEXT.md 檔案，入面記錄曬所有核心術語嘅精確定義同佢哋之間嘅關係。

舉一個佢自己嘅真實例子。

佢喺開發課程管理系統時，新功能要加一個 Pitch 嘅概念（類似視頻嘅包裝方案）。

AI 當場發現咗一個術語矛盾：佢已經定義咗 Standalone Video 係 lessonId 為 NULL 嘅視頻，但新功能入面又叫視頻關聯到 Pitch。

咁呢種視頻仲算唔算 Standalone Video？

呢個問題如果唔解決，後續所有嘅變量命名、檔案命名、數據庫設計都會亂。

AI 俾咗兩個方案：一係重新定義 Standalone Video，二係將 Pitch 視為附加喺 Standalone Video 上面嘅獨立元數據。最後 Matt 揀咗後者。

呢個決定會影響成個 code base 嘅命名同組織方式。如果唔喺一開始就統一清楚，後面越寫越亂。

有咗統一語言，AI 嘅輸出質量會顯著提升。佢唔再需要冗長咁重新解釋每個概念，幾個詞就可以精準表達意圖。Token 慳咗，對齊都好咗。

Martin Fowler 都喺佢嘅 Blog 度專門寫過：統一語言嘅最大價值唔係文檔，而係佢迫令你喺溝通中消除歧義。喺 AI 時代，呢個價值被放大咗十倍。

04

TDD：唔係寫測試，係控制節奏

TDD 好多人覺得係先寫測試再寫 code，但 Matt 強調嘅 TDD 唔係呢個意思。

喺 AI Coding 嘅語境下，TDD 嘅核心作用係控制每一步嘅粒度。

AI 最大嘅問題係咩？佢太識寫。你叫佢做一個功能，佢可以一口氣幫你生成幾百行 code，涵蓋曬各種邊界情況。

但呢幾百行 code 你驗證得到嗎？你知唔知邊行有問題？

TDD 強迫你將工作切成細塊。Red 先寫一個失敗嘅測試，然後 Green 寫最少嘅 code 令測試通過，最後 Refactor 重構。每一步都可以驗證。

Matt 嘅觀點係：冇 TDD，AI 生成嘅 code 會好快變成意大利麵。

因為 AI 冇全局觀，佢只會根據當前上下文盡力而為。如果你唔控制每一步嘅範圍，佢就會越寫越散。

傳統開發中，TDD 嘅角色更多係質量保障。但喺 AI Coding 中，TDD 嘅角色變咗過程控制—確保每一步都喺可控範圍內。

小步快跑，每一步都有反饋，發現偏差即刻修正。

05

Deep Modules：藏起複雜，露出簡單

Deep Modules 呢個概念嚟自史丹福教授 John Ousterhout 嘅《軟件設計的哲學》。

Deep Modules 就係功能豐富但接口簡單嘅模塊。

反面係功能唔多但接口好複雜。

一個典型嘅 Deep Modules：JavaScript 嘅垃圾回收器。功能極之複雜，但對外暴露嘅接口得一個——你唔使手動管理記憶體。

一個典型嘅反面就係：一個淨係做參數校驗但要求傳入 10 個配置項嘅函數。

Matt 話喺 AI Coding 中，Deep Modules 嘅價值被放大咗。

因為 AI 嘅上下文窗口有限，佢可以同時理解嘅 code 範圍係受限嘅。如果你嘅模塊又淺又碎，AI 就要喺多個檔案之間跳嚟跳去，好容易丟失上下文。

而 Deep Modules 將複雜性收埋喺背後，只暴露一個簡單嘅接口。AI 只需要理解接口，唔需要理解內部實作，認知負擔大幅降低。

呢個對測試都友好。Deep Modules 測試起上嚟更容易，因為你要覆蓋嘅接口面更細。

呢個同好多人追求嘅細而美模塊化思路其實係相反。唔係越細越好，而係封裝得當先好。

06

底層邏輯：管理認知負荷

如果你仔細睇呢四個方法論，會發現佢哋有一個共同嘅底層邏輯：管理認知負荷。

Grill Me 令你喺寫 code 前先諗清楚，減少返工帶來嘅認知消耗。

統一語言令人、code 同 AI 使用同一套術語，消除歧義帶來嘅認知負擔。

TDD 控制每一步嘅範圍，避免一次處理太多資訊。

Deep Modules 將複雜性封裝起嚟，令每次互動只需要理解接口而唔係全部細節。

Matt 嘅核心洞察係：喺 AI 時代，開發者嘅角色由寫 code 嘅人變咗做戰略設計嘅人。

AI 係你嘅戰術執行者，佢寫 code、行測試、做重構。但戰略層面嘅決策——點樣組織模塊、點樣定義概念、點樣切分任務——呢啲一定要由人嚟定。

07

全部都唔係新嘢

而呢四個方法論，全部都唔係新發明。

統一語言嚟自 2003 年出版嘅《領域驅動設計》。

TDD 嚟自 Kent Beck 喺 1999 年提出嘅極限編程。

Deep Modules  嚟自 2018 年出版嘅《軟件設計的哲學》。

佢哋冇過時，亦冇失效。喺 AI 時代，佢哋反而變得更重要。

因為當你有一個一秒鐘寫 100 行 code 嘅助手時，你需要嘅唔係更多 code，而係更好嘅約束。

Matt 喺演講最後講咗一句話，大意係：呢啲原則幾十年前已經有，佢哋冇被打敗——佢哋變得更重要。

08

點樣開始

唔好急住學新框架新工具，返去重讀兩本經典。

一本係 Eric Evans 嘅《領域驅動設計》，一本係 John Ousterhout 嘅《軟件設計的哲學》。

然後試下 Matt 開源嘅 Skills 倉庫，入面有 Grill Me 同其他實戰 Skill，可以直接裝到 Claude Code 度用。

開源地址：https://github.com/mattpocock/skills

如果你覺得 18 分鐘嘅演講仲未夠喉，Matt 仲錄咗一個接近 1.5 小時嘅完整工作流影片，親身示範點樣用呢套方法論由零開始建立一個真實項目。

喺 YouTube 搜 Full Walkthrough: Workflow for AI Coding — Matt Pocock 就可以揾到。

09

㩒下面張卡，關注逛逛 GitHub

呢個公眾號歷史發佈過好多有趣嘅開源項目，如果你懶得翻文章一個一個揾，你直接關注微信公眾號：逛逛 GitHub ，後台對話聊天就得：

視頻：https://www.youtube.com/watch?v=v4F1gFy-hqg

AI 讓寫代碼變快了，但代碼從來沒變得更便宜。

這是 Matt Pocock 在大會上演講的核心觀點。

他是前 Vercel 開發者佈道師，Total TypeScript 作者，現在搞了一個叫 AI Hero 的平台，專門教人用 AI Coding。

這場演講發佈兩週就 60 萬播放量，18 分鐘，信息密度極高。

他教了 18 個月的 AI Coding 之後，發現了一個規律：那些用 AI 用得好的開發者，不是什麼都委託給 AI 的人，也不是什麼都自己寫的人。

是那些迴歸工程基礎的人。

他還基於自己的 AI Coding 經驗搞了幾個 Skill，目前開源了。

01

AI Coding 的兩個極端都有問題

現在行業裏對 AI Coding 有兩種極端態度。

一種是 vibe coding。

這個詞是 Andrej Karpathy 提出來的，說白了就是憑感覺讓 AI 寫代碼，描述個大概，然後祈禱它能跑。

另一種是 specs-to-code。

寫一份詳細的規格說明書，直接扔給 AI 讓它生成。這派的假設是：代碼是廉價的，規格才是珍貴的。

Matt 說這兩個都有問題。

vibe coding 的問題很明顯：失控。你不知道 AI 寫了什麼，也不知道它為什麼這麼寫，改起來更是災難。

但 specs-to-code 的問題更隱蔽。

它假設代碼是廉價的，但實際上，AI 生成的代碼和人類寫的代碼一樣，都會腐爛、都會積累技術債、都需要維護。

代碼從來就不廉價。AI 只是讓你更快地產出代碼，但不會替你思考代碼該怎麼組織。

Matt 的觀察是：真正成功的開發者，既不全委託也不全自己寫。他們把 AI 當作一個超級實習生--執行力強，但需要你給出清晰的方向和約束。

怎麼給出清晰的方向？接下來就是他的四個方法論。

02

先別寫代碼，先被 AI 拷問一輪

Grill Me 是 Matt 開源的一個 Claude Code Skill。

也就是前段時間一直掛在 GitHub 開源熱榜的那個 Skill 裏面的。

它的邏輯特別簡單：在動手寫任何代碼之前，讓 AI 先把你拷問一輪。

不是你問 AI，是 AI 問你。

它會沿着你設計決策樹的每一個分支往下走，一條一條地把模糊的想法逼成清晰的方案。

依賴關係、邊界條件、數據模型，全都不放過。

Matt 說他每天收到大約 5 條消息，都是開發者說用了 Grill Me 之後大開眼界的。

Reddit 上也有人專門發帖說這個 Skill 徹底改變了他用 AI 做規劃的方式。

後來 Matt 又進化出了一個升級版，叫 /grill-with-docs。

不僅拷問你，還會把拷問過程中達成的共識實時寫進一個叫 CONTEXT.md 的文件裏。

如果你要問和 SuperPowers 的 Brainstorming 有啥區別，我用起來的感受是：

Brainstorming：適合任何新功能、新項目、重構啓動前的設計階段。

Grill-with-docs：更適合已有代碼庫的項目，你需要對一個具體方案做決策、對齊術語、並同步建立文檔。

如果你的項目還沒有 CONTEXT.md 體系，它也會幫你從頭建起來。

這麼做的好處是什麼？

傳統開發中，你腦子裏對系統的理解和代碼之間總有 gap。

有了這個文件，AI 在後續所有開發中都有一份共識詞典可以參考，不用每次都重新解釋一遍。

說白了，Grill Me 強迫你在寫代碼之前先把設計想清楚。

AI 不會幫你做決策，它只會加速你已經做出的決策。如果你自己都沒想清楚，AI 加速的只是混亂。

03

統一語言

讓人、代碼和 AI 說同一種話

Ubiquitous Language 這個概念來自 Eric Evans 2003 年出版的經典《領域驅動設計》。

核心思想是：讓代碼、開發者和領域專家都說同一套術語。

聽起來理所當然，但實際操作中很少有團隊做到。產品經理說一個詞，開發者理解成另一個意思，代碼裏的命名又是第三個東西。

在 AI 時代，這個問題被放大了。

因為 AI 沒有隱含上下文，它不懂你的暗示和慣例。

你說的用戶和代碼裏的 User 是不是一個東西？你說的訂單和數據庫裏的 Order 是不是同一個概念？

如果你不說清楚，AI 就會自己猜。猜錯了，你就得返工。

Matt 的做法是在項目根目錄維護一個 CONTEXT.md 文件，裏面記錄所有核心術語的精確定義和它們之間的關係。

舉一個他自己的真實例子。

他在開發課程管理系統時，新功能要加一個 Pitch 的概念（類似視頻的包裝方案）。

AI 當場發現了一個術語矛盾：他已經定義了 Standalone Video 是 lessonId 為 NULL 的視頻，但新功能裏又讓視頻關聯到 Pitch。

那這種視頻還算 Standalone Video 嗎？

這個問題如果不解決，後續所有的變量命名、文件命名、數據庫設計都會亂。

AI 給了兩個方案：要麼重新定義 Standalone Video，要麼把 Pitch 看作附加在 Standalone Video 上的獨立元數據。最終 Matt 選擇了後者。

這個決定會影響整個代碼庫的命名和組織方式。如果不在一開始就統一清楚，後面越寫越亂。

有了統一語言，AI 的輸出質量會顯著提升。它不再需要冗長地重新解釋每個概念，幾個詞就能精準表達意圖。Token 省了，對齊也好了。

Martin Fowler 也在他的博客裏專門寫過：統一語言的最大價值不是文檔，而是它迫使你在溝通中消除歧義。在 AI 時代，這個價值被放大了十倍。

04

TDD：不是寫測試，是控制節奏

TDD 很多人覺得是先寫測試再寫代碼，但 Matt 強調的 TDD 不是這個意思。

在 AI Coding 語境下，TDD 的核心作用是控制每一步的粒度。

AI 最大的問題是什麼？它太能寫了。你讓它做一個功能，它能一口氣給你生成幾百行代碼，涵蓋各種邊界情況。

但這幾百行代碼你能驗證嗎？你知道哪行有問題嗎？

TDD 強制你把工作切成小片。Red 先寫個失敗的測試，然後 Green 寫最少的代碼讓測試通過，最後 Refactor 重構。每一步都是可驗證的。

Matt 的觀點是：沒有 TDD，AI 生成的代碼會迅速變成意大利麪條。

因為 AI 沒有全局觀，它只會根據當前上下文盡力而為。如果你不控制每一步的範圍，它就會越寫越散。

傳統開發中，TDD 的角色更多是質量保障。但在 AI Coding 中，TDD 的角色變成了過程控制—確保每一步都在可控範圍內。

小步快跑，每一步都有反饋，發現偏差立刻修正。

05

Deep Modules：藏複雜，露簡單

Deep Modules 這個概念來自斯坦福教授 John Ousterhout 的《軟件設計的哲學》。

Deep Modules 就是功能豐富但接口簡單的模塊。

反面是功能不多但接口很複雜。

一個典型的 Deep Modules：JavaScript 的垃圾回收器。功能極其複雜，但對外暴露的接口就一個——你不用手動管理內存。

一個典型的反面就是：一個只做參數校驗卻要求傳入 10 個配置項的函數。

Matt 說在 AI Coding 中，Deep Modules 的價值被放大了。

因為 AI 的上下文窗口有限，它能同時理解的代碼範圍是受限的。如果你的模塊又淺又碎，AI 就需要在多個文件之間跳來跳去，很容易丟失上下文。

而 Deep Modules 把複雜性藏在背後，只暴露一個簡單的接口。AI 只需要理解接口，不需要理解內部實現，認知負擔大幅降低。

這也對測試友好。Deep Modules 測試起來更容易，因為你要覆蓋的接口面更小。

這和很多人追求的小而美的模塊化思路其實是反的。不是越小越好，而是封裝得當才好。

06

底層邏輯：管理認知負荷

如果你仔細看這四個方法論，會發現它們有一個共同的底層邏輯：管理認知負荷。

Grill Me 讓你在寫代碼前先想清楚，減少返工帶來的認知消耗。

統一語言讓人、代碼和 AI 使用同一套術語，消除歧義帶來的認知負擔。

TDD 控制每一步的範圍，避免一次處理太多信息。

Deep Modules 把複雜性封裝起來，讓每次交互只需要理解接口而不是全部細節。

Matt 的核心洞察是：在 AI 時代，開發者的角色從寫代碼的人變成了做戰略設計的人。

AI 是你的戰術執行者，它寫代碼、跑測試、做重構。但戰略層面的決策——怎麼組織模塊、怎麼定義概念、怎麼切分任務——這些必須由人來定。

07

都不是新東西

而這四個方法論，都不是什麼新發明。

統一語言來自 2003 年出版的《領域驅動設計》。

TDD 來自 Kent Beck 在 1999 年提出的極限編程。

Deep Modules  來自 2018 年出版的《軟件設計的哲學》。

它們沒有過時，也沒有失效。在 AI 時代，它們反而變得更重要了。

因為當你有一個能一秒鐘寫 100 行代碼的助手時，你需要的不是更多的代碼，而是更好的約束。

Matt 在演講最後說了一句話，大意是：這些原則幾十年前就有了，它們沒有被打敗——它們變得更重要了。

08

怎麼開始

別急着學新框架新工具，回去重讀兩本經典。

一本是 Eric Evans 的《領域驅動設計》，一本是 John Ousterhout 的《軟件設計的哲學》。

然後試一下 Matt 開源的 Skills 倉庫，裏面有 Grill Me 和其他實戰 Skill，可以直接裝到 Claude Code 裏用。

開源地址：https://github.com/mattpocock/skills

如果你覺得 18 分鐘的演講還不過癮，Matt 還錄了一個近 1.5 小時的完整工作流視頻，手把手演示了怎麼用這套方法論從零搭建一個真實項目。

在 YouTube 搜 Full Walkthrough: Workflow for AI Coding — Matt Pocock 就能找到。

09

點擊下方卡片，關注逛逛 GitHub

這個公眾號歷史發佈過很多有趣的開源項目，如果你懶得翻文章一個個找，你直接關注微信公眾號：逛逛 GitHub ，後台對話聊天就行了：