---

title: AI 時代工程師真正的護城河：不是做 CRUD，而是 systems thinking 與 distributed systems date: 2026-04-08 source: https://www.threads.com/@rdmcolors/post/DW2Pt5LEnRn category: articles tags:

• Distributed Systems
• MIT 6.824
• Systems Thinking
• AI Era
• Engineering Moat
• Computer Science created: 2026-04-08 updated: 2026-04-08

---

AI 時代工程師真正的護城河：不是做 CRUD，而是 systems thinking 與 distributed systems

概要

這則 Threads 表面上是在推薦 MIT 6.824: Distributed Systems，但它真正有價值的，不只是「哪門課好」，而是它指出了一條在 AI 時代越來越清楚的能力分界線：

真正難被 AI 取代的，不是會不會做 todo app、記帳 app，甚至不是會不會叫模型寫程式，而是你有沒有理解複雜系統如何運作。

貼文的語氣雖然很猛，但核心其實很準：

• AI 可以幫你生成大量樣板程式
• 可以幫你加速 CRUD
• 可以幫你組 UI、補 API、寫測試

但當系統開始進入：

• 一致性
• 容錯
• 分散式協調
• 失敗模式
• 延遲與吞吐量權衡
• 資料正確性與恢復策略

這些層級時，真正重要的就不再是「會不會寫碼」，而是 會不會思考系統。

這篇真正的重點

1. AI 最容易吃掉的，是低層次、可模板化的工程工作

這篇提到「不是 todo app、不是記帳 app」，這句話不是在貶低小專案，而是在點出一個現實：

越標準化、越可預測、越像樣板拼裝的工作，越容易被 AI 高效率吸收。

像這種任務：

• CRUD API
• 後台介面
• 表單流程
• 常見資料表操作
• 一般 App scaffold

未來不是不需要人做，而是：

• AI 可以很快生成初稿
• 低階實作的邊際價值下降
• 純 execution 型工程能力會被壓縮

所以如果工程師的核心價值只停留在這裡，那確實很危險。

2. 系統思維才是 AI 無法直接替你內建的東西

這篇最值得收進 Allen KB 的地方，是它把重點放在 systems thinking。

什麼叫系統思維？ 不是只知道有哪些技術名詞，而是知道：

• 為什麼這裡會出 race condition
• 為什麼某個設計在單機可行、分散式就不行
• 為什麼一致性、可用性、延遲不可能同時最大化
• 為什麼某些錯不是 code bug，而是 system property
• 為什麼看似合理的局部優化，會在整體系統裡產生副作用

AI 可以幫你補語法、給 pattern、產出方案，但： 真正的架構判斷與 trade-off 理解，還是來自你是否理解系統本身。

3. Distributed systems 是最能訓練工程深度的一門學科之一

推薦 MIT 6.824 其實很合理，因為 distributed systems 幾乎濃縮了許多工程本質問題：

• fault tolerance
• leader election
• replication
• consensus
• idempotency
• partial failure
• network unreliability
• state synchronization

這些問題不是只存在於超大型公司。只要你的系統涉及：

• 多服務
• background jobs
• event-driven flows
• cache 與 DB 一致性
• 金流、訂單、同步、排程

你其實就已經在碰 distributed systems 的影子了。

所以這門課的價值不只是學一門冷門高深理論，而是： 它會逼你正視系統在真實世界中的失敗方式。

為什麼這在 AI 時代更重要

因為 AI 把「寫程式」這件事的門檻往下壓了，於是高階差異反而更明顯。

以前會寫 code 本身就有很高門檻；現在模型讓很多人都能很快產出程式碼，所以真正拉開差距的能力會越來越變成：

1. 問題分層能力

你能不能分辨：

• 這是語法問題
• 還是狀態管理問題
• 還是架構問題
• 還是系統邊界定義錯了

2. Trade-off 判斷能力

你能不能知道：

• 為什麼這裡應該選 eventual consistency
• 為什麼這裡應該犧牲吞吐量保證正確性
• 為什麼這裡要多寫一層保護機制

3. Failure-first 思維

你能不能先想：

• 如果網路斷了怎麼辦？
• 重試會不會重扣？
• worker 掛掉後資料狀態會不會髒掉？
• 事件重播時系統會不會爆？

這些才是真正接近 senior / staff / architect 級別的能力，而不是只會把功能做出來。

對資工學生與工程師的真正提醒

這篇如果把情緒抽掉，可以濃縮成一個非常實際的建議：

在 AI 時代，不要只把自己訓練成一個會調 API、拼框架、做 app demo 的人；要把自己訓練成一個看得懂系統約束與失敗模式的人。

這不表示大家都要去做分散式資料庫，而是：

• 你應該知道系統不是只有 happy path
• 你應該理解 state、coordination、failure 的本質
• 你應該能在 AI 幫你寫碼之後，判斷哪些地方其實很危險

我的判斷

值得注意的點

1. 這篇真正推薦的不是一門課，而是一種工程能力升級方向
2. AI 最先壓縮的是模板化工程工作，而不是系統級思考
3. distributed systems 是很有效的 systems thinking 訓練場
4. 未來工程師的差異會更多體現在架構判斷與 trade-off 理解上

應持續觀察的點

1. AI coding 工具是否讓工程教育更快速兩極化：會用工具的人很多，但真正懂 system 的人更稀缺
2. 新一代工程師是否越來越需要從早期就接觸 distributed systems / OS / networking 等硬底子課程
3. 團隊在招募時，是否會更重視 system design 與 failure reasoning，而不只是語言熟練度
4. Claude Code / Copilot 類工具是否反而讓「理解系統的人」生產力更恐怖地放大

一句話總結

這則 Threads 真正值得記錄的，不是 MIT 6.824 很神，而是它提醒了一件更重要的事：在 AI 時代，工程師最難被取代的價值，不在於會不會寫常見功能，而在於能不能理解一致性、容錯、協調與系統權衡這些真正決定複雜系統成敗的東西。