附錄三：AI 招聘語言失真猜想
為什麼部分企業不是缺 AI 人才，而是把職缺寫錯了？
一、命題摘要
本文提出一個命題猜想：
AI 招聘語言失真猜想： 在企業 AI 轉型初期，部分企業所宣稱的「缺 AI 人才」並不完全來自人才市場供給不足，而可能來自職缺定義失真。當人才管理、人資部門或非技術管理層無法區分模型基礎設施、AI 應用工程與 Agent 整合架構三種不同層級的人才需求時，職缺內容容易被高端技術名詞污染，導致企業把應用層、整合層或流程層需求，誤寫成底層模型、GPU、演算法或研究型需求。
用更白話的方式說：
有些公司不是找不到人，而是根本沒有把自己真正需要的人寫清楚。
這種現象會造成幾個結果。
第一，職缺看起來很高端，但與產品實際需求不匹配。 第二，真正合適的人才看到職缺後不敢投，或認為公司需求混亂。 第三，企業吸引來的候選人可能過度偏研究、偏底層、偏模型，而不是能解決實際產品與流程問題的人。 第四，招聘失敗後，企業會誤以為「市場缺 AI 人才」。 第五，AI 人才短缺敘事被放大，但真正的問題可能是職能分層能力不足。
本文不是否定高端 AI 技術人才的重要性。 CUDA、GPU kernel、分散式訓練、模型推理優化、演算法研究，都是高價值能力。 但問題在於：不是每一個 AI 產品、AI 應用或企業 Agent 系統都需要這些能力作為核心職能。
若企業沒有分清楚自己到底是在做「模型基礎設施」、「AI 應用產品」，還是「企業 Agent 整合」，就很容易把不同層級的人才要求混在同一份職缺中。
這就是 AI 招聘語言失真的核心。
二、問題背景：當 HR 開始用 AI 寫 AI 職缺
在生成式 AI 普及後，許多人才管理與 HR 部門開始使用 AI 工具協助撰寫職缺。
這本身不是問題。 AI 可以幫忙整理職務描述、優化語氣、補充常見技能、建立 JD 模板。 問題在於：如果使用者本身不理解 AI 技術分層，AI 產生的內容就可能被直接複製貼上，而缺少必要的技術審查。
這會形成一個循環：
- 企業想招 AI 人才。
- HR 不確定該寫哪些技能。
- HR 查網路或詢問 AI。
- AI 根據常見職缺語料，生成一份看起來完整的 AI JD。
- JD 裡包含 Python、PyTorch、TensorFlow、CUDA、MLOps、LLMOps、RAG、LangChain、Kubernetes、分散式訓練、模型部署、資料治理、Prompt Engineering、NLP、CV 等大量詞彙。
- HR 或管理層未能判斷哪些技能真的必要。
- 所有詞彙被保留。
- 職缺變成技術名詞大雜燴。
- 候選人無法判斷公司真正要做什麼。
- 招聘效率下降。
- 企業宣稱「AI 人才很難找」。
這裡的問題不是 AI 協助寫職缺，而是：
AI 產生的職缺內容，沒有經過真正懂產品與技術架構的人重新分層。
因此，AI 招聘語言失真不是單純 HR 的問題，也不是 AI 的問題，而是企業內部缺少「技術需求翻譯者」的問題。
這個技術需求翻譯者，正是 Agent 整合架構師或 AI 總控架構師應該承擔的一部分職能。
三、三種 AI 人才層級：不能混為一談
要理解職缺失真，首先必須區分三種人才。
3.1 模型基礎設施人才
這類人才處理的是 AI 的底層能力與運算效率。
他們可能需要：
- CUDA
- Triton
- GPU kernel optimization
- CUTLASS
- TensorRT
- vLLM
- 分散式訓練
- 大規模推理服務
- 模型壓縮
- 量化
- 編譯器優化
- 高效能運算
- 多 GPU / 多節點調度
- 模型 serving infrastructure
這類人才非常重要。 但他們主要適用於：
- 基礎模型公司
- 推理引擎公司
- GPU 雲端平台
- AI infra 公司
- 高效能模型部署團隊
- 自研模型訓練平台
- 大規模 AI 運算平台
- 需要極致延遲與成本優化的產品
如果公司真的在做模型訓練、推理加速、GPU kernel、低延遲 inference、AI infra，那麼要求 CUDA 或 GPU 底層能力是合理的。
3.2 AI 應用工程人才
這類人才處理的是如何把現有模型能力做成產品。
他們可能需要：
- 後端工程
- API 整合
- LLM API
- RAG
- 向量資料庫
- 資料管線
- 文件解析
- prompt design
- 工具調用
- 產品功能開發
- 成本控制
- 日誌與監控
- 使用者介面
- SaaS 架構
- 雲端部署
- 資料權限
這類人才主要適用於：
- AI SaaS
- 企業知識庫
- AI 客服
- AI 助理
- 文件問答
- 銷售助理
- HR AI 工具
- 法務文件分析
- 內部資料查詢
- AI 生產力工具
這類產品通常不需要從零訓練大模型，也不一定需要 CUDA。 它們真正需要的是把模型能力、資料與產品流程接起來。
3.3 Agent 整合架構人才
這類人才處理的是企業 AI 系統如何進入工作流。
他們可能需要：
- Agent workflow
- 多 Agent 分工
- 工具權限
- 任務狀態管理
- human-in-the-loop
- 企業資料接入
- 權限治理
- 審計紀錄
- 錯誤回復
- 流程設計
- 任務升級機制
- 風險分級
- evals
- observability
- 部門協作
- 本地模型與雲端模型分工
- AI-native UX
- 組織導入能力
這類人才主要適用於：
- 企業 AI 轉型
- 多 Agent 工作流
- 內部流程自動化
- 跨部門 AI 系統
- 顧問公司 AI 導入
- 系統整合商
- 企業 AI 平台
- AI 工作流治理
- 內部 AI 作業系統
這類人才的核心不是底層演算法，而是統籌。
他們要回答的是：
AI 在公司裡到底可以看什麼、做什麼、做到哪一步、誰確認、怎麼追蹤、怎麼改善、怎麼避免出事？
這與 CUDA、GPU kernel、分散式訓練不是同一層問題。
四、CUDA 作為錯配指標：什麼時候合理？什麼時候可疑？
CUDA 是一個很好的觀察指標，因為它足夠專門，也足夠常被濫用。
CUDA 對應的是 GPU 平行運算與底層效能優化。 它通常與高效能運算、深度學習訓練、模型推理加速、GPU kernel、模型 serving、科學計算等場景有關。
因此，以下情況要求 CUDA 是合理的：
- 公司正在自訓大型模型。
- 公司正在開發推理引擎。
- 公司需要優化 GPU kernel。
- 公司需要降低模型推理延遲。
- 公司需要處理高併發大模型 serving。
- 公司正在做 AI infra。
- 公司需要模型量化、壓縮、加速。
- 公司正在做自研深度學習框架或 runtime。
- 公司要在邊緣裝置上進行高效能模型部署。
- 公司產品高度依賴 GPU 運算效能。
但如果公司主要做的是：
- 企業知識庫
- RAG 文件問答
- AI 客服
- 銷售助理
- HR AI 工具
- 會議摘要
- 文件自動化
- 內部流程 Agent
- 工單整理
- SaaS 型 AI 應用
- 使用雲端模型 API 的產品
- 多 Agent 工作流管理
- 企業資料接入與權限治理
那麼 CUDA 通常不是核心要求。
這些產品更需要的是：
- 後端工程
- API 整合
- 資料工程
- 權限設計
- Agent workflow
- RAG
- evals
- observability
- 工具調用
- human-in-the-loop
- 產品與流程理解
- 成本與風險控制
因此可以提出一個判準：
如果產品的核心問題是「如何讓模型跑得更快」，CUDA 可能是核心能力。 如果產品的核心問題是「如何讓 AI 幫企業做事」，CUDA 通常不是核心能力。
這不是說懂 CUDA 沒用。 而是說，把 CUDA 放進不需要 CUDA 的職缺，可能反映企業對 AI 技術層級的誤判。
五、職缺語言失真的典型症狀
AI 職缺語言失真通常有幾個症狀。
5.1 技術名詞堆疊
職缺列出大量彼此層級不同的技能：
- Python
- PyTorch
- TensorFlow
- CUDA
- NLP
- CV
- RL
- RAG
- LangChain
- LlamaIndex
- Kubernetes
- MLOps
- LLMOps
- Prompt Engineering
- Data Engineering
- DevOps
- AI governance
- AI ethics
- 多 Agent
- 分散式訓練
- 模型部署
- 雲端架構
- 資安
- 產品設計
- 顧問溝通
這種 JD 看起來完整，但實際上可能代表需求沒有被拆解。
5.2 一個職位想招一整個團隊
有些職缺同時要求候選人：
- 會模型訓練
- 會資料工程
- 會後端
- 會前端
- 會雲端部署
- 會資安
- 會顧問訪談
- 會產品規劃
- 會專案管理
- 會客戶溝通
- 會研究論文
- 會商業分析
- 會 Agent 系統
- 會 GPU 優化
這不是高標準，而是角色邊界不清。
企業真正需要的可能是：
- 一位 Agent 整合架構師
- 一位後端工程師
- 一位資料工程師
- 一位產品負責人
- 一位資安/治理支援
- 一位業務流程專家
但 JD 卻把它們全部壓到一個人身上。
5.3 產品層級與人才層級不匹配
例如，一個產品主要是企業 RAG 問答與文件搜尋，但 JD 要求 CUDA、分散式訓練、大模型預訓練經驗。
這種情況就需要追問：
這個產品真的有自研推理引擎嗎？ 真的有訓練基礎模型嗎？ 真的需要改 GPU kernel 嗎？ 還是只是使用外部模型 API？
如果答案是後者，那麼該 JD 很可能存在層級錯配。
5.4 面試官無法解釋技能用途
最簡單的測試是問：
這個職位為什麼需要 CUDA？
如果面試官能回答：
- 我們需要優化 transformer inference kernel。
- 我們正在做低延遲模型 serving。
- 我們要改寫特定 operator。
- 我們要優化多 GPU 記憶體傳輸。
- 我們要把模型部署到特定硬體上。
- 我們有自研 runtime。
那麼 CUDA 要求可能合理。
如果面試官只能回答：
- 因為我們是 AI 公司。
- 因為 AI 工程師應該懂。
- 因為 JD 模板上有。
- 因為主管覺得需要。
- 因為我們希望候選人技術底子好。
那麼這個要求就可能是裝飾性技能，而非任務必要技能。
六、AI 招聘語言失真猜想的形式化表述
可以將本文命題形式化為以下猜想。
猜想一：職缺技術名詞膨脹猜想
當招聘方缺乏 AI 技術分層能力時，職缺描述中的技術名詞數量會增加，但技術名詞與實際工作任務之間的相關性會下降。
換句話說：
越不懂自己要什麼，越容易把所有聽過的技術都寫進去。
猜想二：產品層級與人才層級錯配猜想
當企業產品位於 AI 應用層或 Agent 整合層，但職缺要求偏向模型基礎設施層時，招聘效率會下降，並導致企業誤判為 AI 人才短缺。
例如：
- 應用層產品要求 CUDA。
- RAG 產品要求分散式訓練。
- Agent 工作流產品要求基礎模型預訓練。
- SaaS AI 工具要求 GPU kernel optimization。
這些不一定完全錯，但需要明確理由。 若沒有理由，便可能是錯配。
猜想三：AI 輔助職缺生成污染猜想
當 HR 使用 AI 或網路模板生成 AI 職缺，且缺乏技術審查時，職缺更容易包含跨層級、低相關、高聲望的技術詞彙。
這裡的「高聲望技術詞」指的是聽起來很高端、很 AI、很有門檻，但不一定對該產品必要的技能，例如：
- CUDA
- 分散式訓練
- 強化學習
- 大模型預訓練
- GPU kernel
- 研究論文發表
- 高階數學模型
- 自研 transformer 架構
這些技術有價值，但若與實際產品需求無關，就會污染職缺語言。
猜想四：表面人才短缺猜想
部分 AI 人才短缺，其實是由職缺錯配製造出來的表面短缺。當企業重新定義職位、分離角色層級並降低無關技能要求後，可用人才池會顯著擴大。
也就是說：
不是沒有人能做這份工作，而是原本的 JD 把很多能做的人排除了。
猜想五：Agent 整合人才不可見猜想
由於傳統職缺分類尚未充分承認 Agent 整合架構師這一新型角色，企業往往將其需求錯誤塞入 AI Engineer、ML Engineer、Data Scientist、Solution Architect 或 Product Manager 等既有職稱中，導致真正的能力模型不可見。
這會造成：
- HR 不知道該怎麼寫。
- 候選人不知道是否適合。
- 管理層不知道該怎麼評估。
- 面試流程不知道該測什麼。
- 招聘失敗後繼續怪市場缺人。
七、如何驗證這個猜想？
本文提出的不是定論，而是猜想。 因此它應該可以被觀察、驗證與反駁。
可以用以下方法驗證。
7.1 職缺與產品比對
收集一批 AI 公司或企業 AI 職缺，將其產品類型分為：
- 模型基礎設施
- AI 應用產品
- Agent 整合系統
- 資料平台
- 顧問與導入服務
- 研究型團隊
然後比對 JD 中的技能要求是否與產品層級一致。
若大量應用層產品要求底層 GPU 或模型訓練技能，則支持本猜想。
7.2 面試官解釋測試
對職缺中每一項高端技能提問：
這項技能會在入職後的哪一個任務中被使用？
若招聘方無法清楚說明，代表該技能可能只是裝飾性要求。
7.3 入職後工作內容追蹤
追蹤候選人入職後實際工作內容，對比 JD 要求。
例如 JD 要求 CUDA，但入職後實際工作是：
- 接 API
- 寫後端
- 做 RAG
- 串 CRM
- 設計 prompt
- 處理文件解析
- 做權限管理
- 寫產品功能
那麼就可以確認 JD 存在技能錯配。
7.4 JD 改寫前後招聘效率比較
將原本充滿高端名詞的 JD 改寫成更精準的能力型 JD。
例如把：
熟悉 CUDA、分散式訓練、大模型預訓練、深度學習框架、RAG、Agent、MLOps、Kubernetes。
改成：
能設計並實作企業 RAG 與 Agent 工作流，包含資料接入、權限控管、工具調用、任務狀態、人工確認、評估與監控。
然後比較：
- 應徵人數
- 合格率
- 面試轉換率
- 入職成功率
- 入職後任務匹配度
若改寫後招聘效率提升，則支持本猜想。
八、如何避免 AI 招聘語言失真？
企業可以採取以下方法。
8.1 先定義產品層級，再定義技能
招聘前先問：
- 我們是在做模型基礎設施嗎？
- 我們是在做 AI 應用產品嗎？
- 我們是在做企業 Agent 整合嗎？
- 我們是在做資料平台嗎？
- 我們是在做顧問導入嗎？
不同層級需要不同人才。
8.2 將技能分成必要、加分與無關
每個技能都應被分類。
例如對一個企業 RAG / Agent 職位：
必要技能可能是：
- 後端工程
- API 整合
- RAG
- 資料處理
- 權限設計
- LLM 工具調用
- workflow
- evals
- observability
加分技能可能是：
- MLOps
- 雲端部署
- 資安經驗
- 多 Agent 經驗
- 特定產業知識
無關或低相關技能可能是：
- CUDA
- GPU kernel
- 分散式預訓練
- 自研 transformer 架構
除非產品真的需要，否則不應把低相關技能寫成核心要求。
8.3 用任務語言取代名詞語言
不要只寫：
熟悉 RAG、LLMOps、Agent、CUDA、Kubernetes。
應該寫：
能把企業文件與資料庫接入 AI 系統，設計檢索、引用、權限、人工確認與監控流程，並能讓 Agent 在限定工具與權限下完成可追蹤任務。
任務語言比名詞語言更能吸引真正合適的人。
8.4 讓技術負責人審查 JD
AI 職缺不能只由 HR 或 AI 工具生成後直接發布。 至少需要以下角色審查：
- 技術負責人
- 產品負責人
- 資料負責人
- 實際用人主管
- 若涉及 Agent，最好有懂 workflow 與治理的人審查
8.5 建立 AI 職能分層模板
企業應該建立自己的 AI 職能分層模板，而不是每次從網路複製。
例如分成：
- AI 使用者
- AI 應用工程師
- AI 資料工程師
- Agent 工作流工程師
- Agent 整合架構師
- AI 平台工程師
- 模型基礎設施工程師
- AI 研究員
- AI 治理與安全負責人
這樣招聘語言才不會混亂。
九、Agent 整合架構師在招聘中的新角色
Agent 整合架構師不只是企業 AI 導入者，也應該參與 AI 人才定義。
因為他能分辨：
- 這個產品到底需要哪一層 AI 能力？
- 這個職缺需要研究型人才嗎？
- 這個職缺需要 GPU 底層能力嗎？
- 這個職缺其實是不是後端 + RAG + workflow？
- 這個職缺是否需要治理與權限能力？
- 哪些技能是必要？
- 哪些技能只是加分？
- 哪些技能其實會誤導候選人？
因此，在 AI 招聘中，Agent 整合架構師可以扮演「職能翻譯者」：
把企業真正的 AI 任務，翻譯成正確的人才需求。
這件事很重要。 因為如果職缺一開始就寫錯，後面所有招聘流程都會跟著錯。
十、結論：部分 AI 人才短缺，是定義錯誤製造出來的
本文提出的核心命題是：
AI 人才短缺不只是供給問題，也是需求定義問題。
當企業無法區分模型基礎設施、AI 應用工程與 Agent 整合架構時，就會把不同層級的能力塞進同一份職缺中。
這會造成招聘語言失真。
一個企業知識庫產品，可能被寫成需要模型預訓練人才。 一個 AI 客服產品，可能被寫成需要 CUDA 人才。 一個 Agent 工作流產品，可能被寫成需要深度學習研究員。 一個企業流程自動化職缺，可能被寫成需要全端、模型、資安、顧問、DevOps、資料工程與 GPU 優化全包的人。
最後企業找不到人，便說市場缺 AI 人才。
但更精確的說法可能是：
市場不是沒有能做事的人，而是企業還沒學會正確描述自己要做的事。
因此，未來企業若想真正導入 AI，第一步不是盲目提高職缺要求，而是建立 AI 職能分層能力。
企業需要知道：
- 什麼時候需要模型研究員。
- 什麼時候需要模型基礎設施工程師。
- 什麼時候需要 AI 應用工程師。
- 什麼時候需要 Agent 整合架構師。
- 什麼時候只需要培訓現有員工。
- 什麼時候根本不需要新增職位，而是需要重組流程。
在 AI 進入企業工作流的時代，真正稀缺的不只是 AI 技術人才。 更稀缺的是能正確定義 AI 人才需求的人。
這也是為什麼 Agent 整合架構師不只是技術角色，而是企業 AI 轉型中的職能定義者、架構設計者與招聘需求校準者。
附：一句話版本
AI 招聘語言失真猜想：部分企業不是缺 AI 人才，而是因為不懂 AI 技術分層，把應用層與 Agent 整合層需求誤寫成模型底層與 GPU 工程需求，導致職缺被高端技術名詞污染，進而製造出表面人才短缺。