一張 T 字被畫了出來：通才型開發者，是一份被排好的能力藍圖

2026 年 10 月 6 日，掘金出現一篇標題為「AI 時代，我們都將成為通才型開發者：只懂 Android，已經不夠了」的文章。它轉述了長期深耕 Android 與 Kotlin 的開發者 Philipp Lackner 的一個觀點：We will all be generalists。文章本身談的是職涯，但最值得細看的，其實是它把「能力」畫成了一張圖的方式。

那張圖是一個大寫的 T。豎線代表深度，在 Android 這個例子裡是 Kotlin、Framework、架構與效能優化；橫線代表廣度，往 Backend、AI、Cloud、Database、Web 幾個方向攤開。一橫一豎，兩筆就把「通才不是萬金油」這句話變成了可以直接目視的結構。

先從這個 T 字的排版看起。豎線只有一筆，橫線也是一筆，但豎線被放在語意的中心：文章反覆強調專業深度仍然必要，AI 降低的是進入新領域的門檻，並沒有取消深度本身的價值。換句話說，這張圖的視覺重心刻意落在縱軸，橫軸是延伸，是用來支撐豎線站穩的底座。這是一個很誠實的設計選擇：如果真的主張什麼都碰一點就好，圖會畫成一條水平的虛線，而不是 T。

文章裡另一個被排得很整齊的結構，是開發者價值的移動路徑：理解問題、設計系統、選擇工具、驗證方案、解決問題。這一串動詞的排序本身就有設計感。過去的問題是 How do I write this code，答案落在鍵盤上；新的問題是 What is the right way to solve this problem，答案落在選擇之前。價值從「寫」往「選」移動，這和我們先前觀察過的宣告式介面如何把開發者的心智模型從怎麼做改成是什麼是同一種方向的位移：工具把實作的細節吸收掉，人往問題定義的那一端靠。

比較也需要基準。跟傳統的專業分工比，過去一位 Android 開發者要跨到後端或雲端，成本以月甚至年計；文章引用 Lackner 的判斷是，AI 把這個進入週期壓縮到幾天甚至幾小時。但文章同時劃出了一條界線：AI 能告訴你「這個技術應該怎麼用」，卻無法替你回答「它在真實專案裡什麼時候該用」。經驗仍然來自專案、除錯、失敗、重構與長期維護，AI 給的是速度，回傳的還是得由人驗收。這條界線畫得克制，沒有把工具講成萬能。

從介面設計的角度看，這套主張其實把開發者自己重新定義成了一種介面：一端接收問題，另一端組合工具。文章結尾那句「這個問題需要什麼技術，我來把它解決掉」，描述的正是一個從 Module Developer 走向 Problem Solver 的姿態。工具清單變長了，但判斷哪個工具該在哪個位置出場的責任，也一併移到了人這一側。

收在一個明確的觀點上：這篇文章真正被設計出來的東西，並非一份學習清單，而是一份能力的結構圖。T 字的誠實之處在於它承認深度與廣度不互相取代，AI 改變的只是取得兩者的時間成本。至於每個人的 T 要寬到哪裡、深到哪裡，那張圖沒有給尺寸，也本來就不該給。