ClearForge
重點：AI 給你一個看起來不錯的方案，能不能看出來、敢不敢推翻——這是只會用 AI 跟能駕馭 AI 的工程師之間真正的差距。
架構設計的成長卡點，是知識，還是判斷？
過去架構決策的焦油坑，是「自己想錯了還不知道」。
現在的焦油坑，是「AI 給了一個看起來不錯的方案，你按了 Accept」。
而能不能看出來、敢不敢推翻，也許會是只會用 AI 的工程師，跟能駕馭 AI 的工程師之間真正的差距。
「你應該開的是架構設計的課」
5/16 剛交付完一場 Agentic Coding 工作坊，下課後跟 Marcus、Roberson 聊到我之後想開的 SBE AI 版課程，結果被兩位敲碗——「你應該開的是架構設計的課」。
當下我笑了笑，但心裡蠻猶豫的。
架構決策最麻煩的特性：遞延風險
架構設計這件事，從我還是菜鳥工程師時就在做了——只是當時不知道。
每一個 if-else 放哪、每一個 method 歸給誰，都是微型的架構決策，只是它的影響要一段時間後才會浮現。
這是架構決策最麻煩的特性——遞延風險。
你做決定的當下只能靠想像力，當感受到真實的痛苦時，已經來不及了。
而要在「來不及」之前就先看見，需要的不只是更多知識。
知識只是入場券，真正讓你做決策的是判斷力
菜鳥時期覺得要學會很多架構知識才能做好決策，但這麼多年下來，越覺得知識只是入場券，真正讓你能做決策的，是「在不確定中做取捨的判斷力」。
知識可以流動：
- 一本《Implementing Domain-Driven Design》翻完，你就知道 BC、Aggregate、Repository 是什麼
- Greg Young 那場 CQRS 經典演講看完，你會知道 Event Sourcing 跟 CQRS 為什麼常常一起出現
但這些都不會讓你變成一個能做架構決策的人。
真正讓你能做架構決策的，是疤痕
真正讓你能做架構決策的，是你在各種焦油坑裡掙扎過、留下的疤痕：
- 那個你以為很乾淨的 BC 切分，三個月後業務一調整你才發現切錯邊的痛
- 那個你信誓旦旦推薦的 Event Sourcing，半年後 debug 時想撞牆的悔
- 那個你跟 PM 對賭「萬一有這種需求呢？」，結果一年過去，想像中的需求變更不存在，面對新成員問為什要設計成這樣，你那滿臉的尷尬
這些東西，我有辦法把我過去的經驗整理成「方法」嗎？可以。但能不能套公式般套到每個人的產業／技術棧？不行。
學功夫學到出師要領悟，但學員上完課能不能真的「領悟」？以架構設計來說，不容易。
我這個年資的人特有的失敗模式：over design
寫到這裡我突然意識到，我舉的三個例子都是 over design——做了不必要的切分、用了過於複雜的模式、為了不存在的需求預留設計。
這其實是我這個年資的人特有的失敗模式。
新手踩的是另一邊：沒做該做的設計。沒有 idempotency、沒切 service 邊界、沒設計 multi-tenant、沒做可觀測性——這些「現在不做也能跑」的設計，三個月後變成救火現場。
而架構判斷力的核心，其實就是在 over 和 under 之間找平衡。
這個平衡點，沒有公式，因為它跟你的業務階段、團隊規模、技術棧、甚至公司財務狀況都有關係。
這正是為什麼架構設計教不會——不是知識不夠，模式也是可以歸納的。難的是**「模式怎麼套到你的情境上」的那個判斷**——這個判斷只能從你自己的疤痕長出來。
Cash Wu 戳到問題最深的那一層
我把這個猶豫貼在留言區之後，朋友 Cash Wu 丟了一句很精準的話：
「在 i don’t know i don’t know 的情況下，很難判斷 AI 架構設計的問題」
這句話戳到了問題最深的那一層。
架構設計最可怕的不是「我不知道」，而是「我不知道我不知道」。
而且這件事我自己也躲不掉。我每天用 Claude 寫 code、跑架構討論，常常會懷疑——
我現在做的這個判斷，是真的基於我的經驗？還是另一種我看不出來的 Accept？
經驗讓你以為自己能判斷，而那本身就可能是盲點。
Senior 工程師最大的成長卡點，往往不是技術書讀得不夠，而是還沒踩過某些坑——你以為自己在做架構決策，其實只是在重複過去成功經驗的舒適區。
AI 時代把這個問題放大了不只一倍
- LLM 要不要放在 critical path？
- Prompt 該不該跟 code 一起進 PR review？
- AI 輸出有不確定性，傳統單元測試已經失效，新的測試框架怎麼設計？
- 模型升級時的 regression 怎麼處理？
很多題目連業界都還沒形成共識，怎麼可能在課堂上「學會」？
「需要的是進坑」——這句玩笑話可能就是答案
我回 Cash 的時候開玩笑說：
「在完全不知道的狀態下，需要的是進坑。」
但回頭想想，這句玩笑話可能就是答案。
如果架構設計的判斷力，本質是「焦油坑經驗的累積」——那麼「教架構設計」這件事，能做的最大價值不是「傳授知識」，而是：
- 把學員推進「對的坑」——選一個有教學價值、後果可控的真實情境，讓他親自踩
- 在他爬出來時，幫他看清楚剛才到底發生了什麼——這一步如果有人一起討論，才有機會看見自己的盲點
- 讓不同學員交換各自坑裡的見聞——別人的疤痕，是你最快的學習材料
這個形態，大概率不會是「投影片 + 講授 + 部份實作」式的短期工作坊。要真的有效果，可能會更像找健身教練——有人陪你練、看你動作、針對你的狀況調整課表。但具體會長什麼樣子，我還沒完全想清楚。
回到開頭
「AI 給了一個看起來不錯的方案，你按了 Accept」。
Claude 給你一個 BC 切分方案、Copilot 建議你加一層 Event Bus、ChatGPT 說這裡應該用 Saga Pattern——這些建議看起來都很有道理，引用的還是業界標準術語。
問題是：你有沒有判斷力知道哪一個建議該接受、哪一個該推翻？