台大資工 vs Anthropic 工程師：差距不在 AI 工具，而在你怎麼看待「控制權」

最近跟一位朋友聊到一個問題：台灣頂尖的工程師，和 Anthropic 這些世界一流 AI 公司的工程師，差距到底在哪裡？

聊完之後我有一些想法，但後來自己反覆思考，又覺得最初的結論不夠完整。

所以這篇文章，我想把「我原本的假設」和「後來的自我反駁」都攤開來講。

我原本的觀察：Mindset 的差距

我發現台灣的工程師其實也在用 AI 工具。

但大部分人的使用方式是這樣的：問一個問題，AI 幫你搜尋、找到要修改的地方，你確認之後點 OK，讓它去改。

整個過程中，人是主導者，AI 只是建議者。

但頂尖公司的做法完全不同。

他們會同時讓多個 AI 平行協作，開發者甚至不需要看到具體的修改細節，而是透過系統化的驗證方式來確認成果。

這裡面有一個哲學上的根本轉變：你完全信任 AI 會去執行，你也知道它可能會做錯，但你思考的不是「我要不要接受這個建議」，而是「當它做錯的時候，我怎麼用系統化的方式去捕捉錯誤」。

當你能讓七八個 AI 平行處理不同功能，再用多個角度去交叉驗證，你的產能瓶頸就不再是人腦一次只能處理一件事，而是 Token 用量和運算資源。

你能處理的複雜問題會呈現指數級上升。

我原本認為，這個 Mindset 的轉變，就是工程師最需要突破的地方。

但後來我自己反駁了自己

想了一陣子之後，我覺得這個結論只對了一半。

把差距歸結為 Mindset，其實低估了結構性因素。

Anthropic 的工程師之所以敢放手讓多個 AI 平行協作，不是因為他們心態比較開放，而是因為他們有極其完善的測試基礎設施。

他們的 CI/CD pipeline、自動化回歸測試、eval framework 的覆蓋率，讓「不看細節」變成一個合理的選擇。

反過來看，台灣工程師面對的現實是什麼？

測試覆蓋率可能不到 30% 的 codebase，部署一次要跑半天，staging 環境不完善。

在這種環境下，每一行都要人眼確認，不是保守，是理性的風險管理。

所以真正的問題不是工程師不願意信任 AI，而是組織沒有建立起讓「信任」成為合理選擇的基礎設施。

第二個反思：平行協作的成本沒有想像中低

讓七八個 AI agent 同時開發聽起來很美好，但背後的 coordination cost 是巨大的。

多個 AI 同時改同一個系統的不同部分，merge conflict、狀態不一致、隱性耦合造成的 bug，這些不會因為你有正確的心態就自動消失。

能把一個系統性任務拆解成真正獨立、可平行執行的子任務，這本身就是頂級的工程能力，跟 AI 無關。

這不是 Mindset 的勝利，是軟體架構設計能力的勝利。

第三個反思：「不看細節」不是革命，是抽象層級的提升

我原本把「開發者不需要看修改細節」描述成一種哲學躍進。

但冷靜想想，這其實就是軟體工程一直在做的事。

從組合語言到高階語言、從手寫 SQL 到 ORM、從手動部署到 Kubernetes，每一次進步都是「不再看底層細節」。

AI 協作只是這條路上的最新一步，不是質變。

而且每一次抽象層級提升都帶來同樣的隱患：當抽象洩漏的時候，不懂底層的人會完全束手無策。

最危險的不是「還在人工確認每一行」的工程師，而是「完全放手但不理解底層在做什麼」的工程師。

前者慢但穩，後者快但脆。

所以真正的差距在哪裡？

綜合這些思考，我認為台灣頂尖工程師和世界一流 AI 公司工程師的差距，核心在三件事：

第一，問題定義能力。

頂尖公司的工程師花大量時間定義「什麼是做對了」，也就是 evaluation criteria。

台灣工程師花大量時間在「怎麼做」。

在 AI 時代，前者的價值暴增，後者正在被取代。

第二，系統設計的品味。

知道什麼該拆開、什麼該合在一起、interface 該畫在哪裡。

這決定了 AI 能不能有效地平行協作，而這是純粹的工程判斷力。

第三，對失敗模式的想像力。

要設計出有效的防護機制，前提是你要能預見 AI 會怎麼錯。

這需要深厚的領域知識，不是光靠信任就夠的。

結論

Mindset 的轉變確實重要，但它是結果，不是原因。

真正的原因是工程基礎設施、架構能力、和問題定義能力的差距。

只改 Mindset 而不改這些底層條件，就像告訴一個沒有降落傘的人「你只需要相信自己會飛」。

但反過來說，如果你已經有了完善的基礎設施和架構能力，卻還停留在「AI 只是建議者、我是主導者」的框架裡，那你就是背著降落傘卻不敢跳。

兩者都是問題。

而真正的高手，是一邊縫降落傘、一邊學跳傘的人。