跳至主要内容

別再用工程師的思維工作，開始像架構師一樣思考

· 閱讀時間約 11 分鐘
uuboyscy
uuboyscy
Data Engineer | Founder of uuboyscy.dev

很長一段時間，我以為自己的工作就是寫出好的程式碼。建好 pipeline、調好 job、修好 cluster。技術執行能力越強，我的價值就越高。

直到 AI 出現之後，這個價值的定義開始改變了。

我以前是怎麼思考的​

剛入行的時候，我整天都在處理實作。寫 Java、用 Spring Boot 開發 API、調 Spark 和 Flink 的 job、手動維運 Hadoop cluster。那時 Airflow 這類工具還沒有 managed service，全部都要自己安裝、自己設定，壞了也得自己修。

我當時的心智模型是：「能建越多、能 operate 越多，我就是越好的工程師。」執行力就是價值。

雲端讓事情有點不一樣了​

隨著 GCP 和 AWS 等雲端平台越來越成熟，BigQuery、Redshift、EMR、Dataproc 這類 managed service 大幅簡化了資料處理的流程。GCS、S3 這類儲存方案，加上 Athena 這類 query-first 工具，也讓資料管理變得更簡單。這個轉變讓團隊可以從基礎設施維運的負擔中解放出來，把心力放在治理、品質和業務洞察上，並開始大量使用 dbt、DataHub、Great Expectations 這類工具。

然後產業開始試著取代自己​

幾年前，Text-to-SQL 是一個很熱門的趨勢，意思是把自然語言的問題轉成資料庫查詢。團隊會在 data warehouse 或 lakehouse 之上建一層 semantic layer。你可以把它想成一個翻譯層，用來定義業務名詞（例如「active user」或「monthly revenue」），讓系統知道使用者問的問題實際上是什麼意思。它就像資料和 dashboard 之間的橋樑，讓非技術人員不需要工程師也能拿到答案。

有些公司會自己訓練模型來做這件事，有些則會找開源工具或第三方服務。目標都是讓工程師在日常的資料存取上變得不那麼必要。

這其實已經是一個訊號了。產業正在嘗試把工程師這一層自動化掉。

LLM 讓這件事更明顯​

然後 ChatGPT 出現了。團隊花了好幾年建出來的 Text-to-SQL 模型，瞬間就被通用型的 LLM 超越。一夜之間，很多過去的努力就過時了。

但有一個容易被忽略的點。LLM 取代了那些翻譯模型，但它並沒有取代 semantic layer 本身的需求。事實上，它讓 semantic layer（以及背後的 data catalog）變得比以前更重要。LLM 可以寫出幾乎完美的 SQL，但前提是你要給它正確的 context。如果它不知道「active user」是指過去 30 天內登入過的使用者，那它寫出來的 SQL 就會是「自信地錯」。

這也是為什麼現在 data catalog、data contract 和定義良好的 metadata 變得更重要。模型很強，但它的好壞取決於你餵給它的 context。如果你的資料定義清楚，而且維護的責任歸屬也很明確，AI 就會是一個真正的助手；如果你的資料是混亂的，AI 只會以更快的速度產出錯誤的答案。

同時，開發速度也整個變了。早上才討論一個新專案，下午就能拿出一個可運作的 prototype。交付一個 feature 不再一定需要一整個團隊和一個 sprint。

而且下一波的轉變已經開始了。很快地，使用你 pipeline 的對象不會只是看 dashboard 的人，而是會自己做決定的 AI agent。對可靠度的要求只會越來越高。

三年前，我以為 AI 要真正成為工程師的助手，至少還要五年。現在看，這個估計差得很遠。

你必須做出的轉變​

AI 在工程師這一層做得非常好。它可以寫程式、寫 SQL、做 prototype。但它不擅長的地方，是做那些需要它沒有的 context 才能做的決定。

它不認識你的公司。它不知道哪一個 stakeholder 看到某個數字變動會生氣。它不知道你正在設計的這條 pipeline，最後會餵進一個每月一號必須正確的財務報表。它可以建議用 streaming 還是 batch，但它不需要為這個選擇承擔後果。

它也不在乎你的雲端帳單。AI 可以很有自信地寫出一段 SQL，去掃過十億筆資料，一個下午就把你的 BigQuery 或 Snowflake 額度燒光。成本，是其中一個最容易看出「為什麼還是需要人類判斷」的地方。

這些決定需要對整體有完整的理解。這就是架構師的思維，不是工程師的思維。

工程師會問的問題：「我要怎麼把它做出來？」 架構師會問的問題：「對業務的影響是什麼？誰會依賴這個東西？如果它壞了，下游會怎麼樣？」

如果你擔心 AI 會取代你，這就是你該做的轉變。不是去學一個新工具，也不是寫得更快，而是把你的思考層級往上提一層。

但你還是得把基本功學好​

我想老實說一件事。我今天能用架構師的方式思考，是因為我花了很多年寫程式、修壞掉的 job，甚至為了修一條失敗的 pipeline，或一整個壞掉的 Hadoop cluster 熬夜到天亮。是這些經驗讓我今天有能力做這些判斷。

如果你才剛入行，請不要以為自己可以跳過工程師這個階段。架構師的思維是建立在工程師的經驗之上，不是取代它。如果你不知道一個壞掉的 Spark job 長什麼樣子，你就沒辦法判斷 AI 給的建議是對還是錯。而 AI 講錯的時候，跟講對的時候一樣有自信。

所以還是要把基本功學起來：SQL、資料建模、分散式系統怎麼運作、pipeline 為什麼會失敗。把 AI 給你的程式碼讀懂、debug、並且質疑它。新的核心能力不是寫程式寫得更快，而是有能力閱讀、判斷、並且為 AI 產出的東西負責。這個能力只能靠自己親手做過才會有。

還有一件事。很多剛入行的工程師以為當架構師就是用更多的工具、更多的框架、更多的服務。其實常常是相反的。真正的架構師知道什麼時候該說「不」。複雜性很容易加進去，要拿出來卻非常難。

AI 沒辦法取代的事​

AI 寫程式比你快，這是一個讓人不舒服的事實。但寫程式只是工作的一部分，還有很多事 AI 沒辦法做。這些才是你真正的價值所在：

  • 簽合約。 AI 沒辦法為 production 出問題的時候負責。一定要有一個人來承擔結果，一定要有一個人坐在客戶面前回答這件事。
  • 跟人對話。 真實的專案是透過跟 stakeholder、PM、其他團隊的對話建立起來的。理解別人真正需要什麼，而不只是他們嘴上說什麼，這仍然是人類的能力。
  • 理解業務。 AI 從來沒有參加過你公司的會議。它不知道為什麼 Table A 的 user_id 跟 Table B 對不起來，也不知道 marketing 上一季把「conversion」的定義改了。
  • 在不明確的時候做判斷。 真實的工作充滿模糊地帶。當需求亂七八糟、deadline 又是明天的時候，總要有一個人做決定。AI 可以給你選項，做決定的還是人。

結語​

如果回頭看整個時間軸，每一次的轉變其實都是同一個模式。重複性的工作，還有那些已經不夠有效率的工作，總是會被更好的工具取代。AI 只是下一個。

不要對抗趨勢。擁抱新的技能，並放下那些已經不再適合你的舊思維。

所以不要試著跟 AI 在它已經比你強的事情上競爭。把 AI 當成你的工具，讓它去處理程式、SQL、prototype。這樣你才有時間做真正重要的事，例如設計整個系統、跟業務溝通、做那些難下的判斷。

在這個時代能持續成長的工程師，不是寫最多程式的那個，而是知道什麼東西值得被建出來、以及為什麼要建的那個人。

AI 是手，你是腦。

感謝你的閱讀！如果你覺得這篇文章對你有幫助，歡迎在 LinkedIn 上跟我聯繫。