以前你可以說「那不是我的職責」。現在？沒有不到位的理由了。
先講結論
IT 角色分工不會消失，但一個人需要能切換多種思維模式。AI 讓知識取得變便宜，但把知識點內化成思維方式，還是得靠你自己。
每個角色不是職位，是思維模式
別背職稱，理解他們在問什麼問題：
- PM：「什麼時候能交付？風險在哪？」
- SA：「使用者要的到底是什麼？系統怎麼承接？」
- SD：「架構怎麼切？模組怎麼溝通？」
- PG：「這功能怎麼寫最乾淨？」
- QA：「哪裡會壞？使用者會怎麼誤用？」
- SRE：「掛了怎麼辦？怎麼讓它不掛？」
- Security：「如果我要攻破這系統，我會怎麼做？」
重點是：你應該能在需要時切換到任何一個角色的視角。
為什麼以前要分工
三個歷史原因：知識取得成本高（二十年前要理解系統分析，你得找到一個願意帶你的 SA，或啃完 Pressman 那本磚頭書）、工具鏈學習曲線陡（做效能測試要會 JMeter + 讀 GC log + OS kernel tuning）、溝通成本隨人數 n(n-1)/2 成長。
現在呢？AI 幾分鐘整理一個領域的核心概念、幫你生成設定檔和測試腳本、大幅降低入門門檻。當一個人能理解多個角色的語言，溝通成本反而更低。
但這不代表角色會消失——而是你可以在需要時切換思維模式。
「什麼都懂一點」vs「理解全貌」
這是最容易踩的坑。
懂一點：知道 TDD 是「先寫測試再寫功能」。理解全貌：知道 TDD 的本質是用測試來定義需求，不是「為了覆蓋率」。
懂一點：知道 UML 是「畫圖的工具」。理解全貌：知道 UML 的價值是強迫你在寫 code 前想清楚物件關係，不是「畫漂亮的圖給主管看」。
前者是知識蒐集，後者是思維內化。AI 加速前者，後者得自己反芻。
從 T 型到 π 型
知識廣度
━━━━━━━━━━━━━━━━━━━━━━━━
┃ ┃
┃ ┃
專長 A 專長 B
(例: 前端) (例: 系統設計)
兩根柱子讓你能站在兩個角度看同一個問題。AI 讓你把橫線拉得更寬——以前「廣度」是「聽過」，現在可以做到「理解到能判斷」。
你可以開始跨界的方向
你是前端/後端工程師？試試這些：
- SA 思維：看到需求時腦中自動跑出資料流和狀態機
- QA 思維：寫的時候就在想邊界，而不是寫完才想怎麼測
- Security 視角：設計 API 時就想「這 endpoint 可以被怎麼濫用」
- SRE 思維：寫 code 時考慮「這服務掛了會怎樣？恢復要多久？」
- PM 思維：從「這功能要多久」變成「這功能的不確定性在哪」
問你自己：看到一個新需求，你的腦中跑過幾種角色的思維？還是只有「這功能我怎麼寫」？
延伸閱讀
你上次主動用「攻擊者視角」審視自己寫的東西是什麼時候？如果想不起來——嗯，那就是你下一個要練的。