AI Engineering 不該獨立存在：工程白板合併論

「AI Engineer」的崛起

過去兩年，「AI Engineer」作為一個職位迅速崛起。從 AI Engineer Summit 到各大公司開出的 JD，這個角色被定位為介於 ML Engineer 和 Software Engineer 之間——不訓練模型，但擅長使用 LLM API 來構建應用。

我對此持懷疑態度。不是因為這些技能不重要，而是因為把它隔離成一個獨立角色是錯誤的組織方式。

Stack Approach 的問題

目前多數組織採用「堆疊」的方式處理 AI 能力：

• 底層：Infra team 管 GPU 和模型部署
• 中層：ML team 做微調和評估
• 上層：AI Engineer 做 prompt、RAG、agent 整合
• 最上層：Product Engineer 負責 UI 和功能

這種分層的問題是——每一層都在等另一層。AI Engineer 等 ML team 提供更好的模型，Product Engineer 等 AI Engineer 把 API 包好。溝通成本巨大，而且 AI 功能的品質往往取決於對使用場景的深度理解，而非對 AI 技術的精通。

合併論：AI 是技能，不是角色

我的主張是：

每個工程師都應該具備基本的 AI 整合能力，就像每個工程師都應該會寫 SQL 一樣。

具體來說：

1. Prompt Engineering 是每個人的事。寫好的 prompt 需要理解使用者需求和業務邏輯，這些知識在 product engineer 手上。
2. RAG 是資料工程問題。索引建立、chunk 策略、retrieval 品質——這些更接近 data engineering 而非 AI research。
3. Agent 是軟體架構問題。狀態管理、錯誤處理、可觀測性——這些都是一般軟體工程的範疇。

但需要 AI 專家嗎？

需要。但是 AI 專家應該像 security team 或 platform team 一樣——提供基礎設施和指導，而不是替每個功能寫 AI 整合邏輯。

AI platform team 的職責可以是：

• 維護內部的 LLM gateway / proxy
• 建立 prompt 管理和版本控制系統
• 提供 evaluation framework
• 制定 AI 使用的 best practices 和 guardrails
• 處理真正需要深度 ML 知識的問題（微調、custom model）

結論

把「會用 LLM API」當作一個獨立職位，就像把「會用 REST API」當作一個獨立職位一樣荒謬。AI 能力應該是每個工程師的基本素養，輔以專門的 platform team 提供進階支持。

合併不是消滅，而是融合。當 AI 能力被分散到每個團隊時，AI 功能才能真正貼合使用者需求。