附錄四：AI 招聘自指污染命題

當企業用 AI 來定義 AI 人才，錯誤如何被循環放大？

一、命題摘要

本文提出一個新的補充命題：

AI 招聘自指污染命題： 當企業缺乏足夠的 AI 技術分層能力，而又使用 AI 工具、網路模板或市場既有職缺來撰寫 AI 職缺時，這些職缺可能會複製既有市場語言中的錯誤、混雜與膨脹。由於新的職缺又會進一步成為未來 AI、HR、招聘平台與企業模仿的語料來源，錯誤的人才定義便可能在市場中循環擴散，形成自指式污染。

用更簡單的話說：

企業因為不懂 AI，所以問 AI 要怎麼招 AI 人才； AI 又根據市場上已經混亂的 AI 職缺，生成一份看似專業的 AI 職缺； HR 因為不懂技術，無法判斷內容是否正確，於是直接採用； 這份新的職缺再度進入市場，成為下一輪模仿與生成的材料。

這就是 AI 招聘的自指污染。

它不是單純 HR 寫錯職缺。 也不是單純 AI 生成錯誤。 而是當新技術職能尚未被企業真正理解時，企業、HR、AI 工具與既有市場語料共同形成的一種錯誤循環。

二、傳統招聘為什麼比較不容易出現這種問題？

在傳統職位招聘中，HR 通常不是孤立寫職缺。

如果要招會計，HR 可以問財務主管。 如果要招法務，HR 可以問法務主管。 如果要招後端工程師，HR 可以問工程主管。 如果要招業務，HR 可以問業務主管。 如果要招設計師，HR 可以問設計主管。 如果要招營運人員，HR 可以問營運主管。

這些職能已經存在多年，企業內部通常已經有相對成熟的職務參照。

它們有既有團隊。 有現任員工。 有主管經驗。 有面試方法。 有績效標準。 有產業慣例。 有清楚的工作成果。 有相對穩定的能力模型。

所以即使 HR 不完全懂該職位細節，也能透過內部現場人員校正職缺內容。

例如 HR 不懂後端工程，也可以問工程主管：

「這個職位需要 Java 還是 Python？」 「需要懂資料庫嗎？」 「需要雲端部署經驗嗎？」 「這個職位是偏維護還是新產品開發？」 「這個職位需要幾年經驗？」 「哪些技能是必要，哪些只是加分？」

這種情況下，HR 有一個現場校正源。

但 AI 對許多企業而言不同。

很多企業在第一次導入 AI 時，內部根本沒有真正懂 AI 分層的人。 沒有 AI 架構師。 沒有 Agent 整合架構師。 沒有 LLM 應用工程團隊。 沒有模型部署經驗。 沒有 AI governance 經驗。 沒有真正做過 production-grade AI workflow 的團隊。

於是 HR 沒有人可以問。

這時候，HR 可能會轉向三種來源：

1. 網路上的 AI 職缺模板。

1. 其他公司的 AI 職缺。

1. AI 工具本身。

問題由此開始。

三、AI 職缺自指迴路如何形成？

AI 職缺自指迴路可以分成八個步驟。

第一步：企業感受到 AI 壓力

企業看到市場都在談 AI，競爭對手也在導入 AI，管理層開始要求公司招聘 AI 人才。

但管理層通常只提出模糊需求：

• 我們需要 AI 工程師。
• 我們要做 AI 產品。
• 我們要導入大模型。
• 我們要做 Agent。
• 我們要建立 AI 團隊。
• 我們要讓公司 AI 化。

這些說法方向正確，但不夠精確。

它們沒有說清楚：

• 是模型訓練？
• 是 AI 應用開發？
• 是企業資料接入？
• 是 RAG？
• 是 Agent 工作流？
• 是 AI 平台？
• 是 AI 治理？
• 是內部流程自動化？
• 是客服 AI？
• 是工程效率工具？
• 是本地模型部署？
• 是雲端模型整合？

如果第一步沒有定義清楚，後面的招聘就會開始失真。

第二步：HR 缺少內部校正對象

傳統職位可以問現任主管。 但 AI 新職位往往沒有現任主管。

公司可能連第一個 AI 人才都還沒招到。 因此 HR 無法像傳統招聘那樣，請內部專家幫忙校正 JD。

如果公司沒有 CTO、AI lead、solution architect 或懂 Agent 系統的人，HR 就只能外部找答案。

第三步：HR 詢問 AI 或套用模板

HR 可能會問 AI：

我們公司想招 AI 工程師，請幫我寫一份 JD。

或者：

我們要做 AI Agent 產品，需要什麼人才？

或者：

請幫我列出 AI 工程師需要的技能。

AI 會根據大量常見語料生成答案。

問題是，這些語料本身可能已經混雜了不同層級的人才需求。

例如，它可能同時列出：

• Python
• PyTorch
• TensorFlow
• CUDA
• NLP
• CV
• RAG
• LangChain
• LlamaIndex
• Kubernetes
• MLOps
• LLMOps
• prompt engineering
• model fine-tuning
• distributed training
• vector database
• API integration
• cloud deployment
• agent orchestration
• AI governance

這份答案看起來很完整，甚至很專業。

但它可能不是「精準 JD」，而是「AI 技術詞彙總整理」。

第四步：HR 無法判斷哪些必要、哪些加分、哪些無關

若 HR 不懂 AI 技術分層，就很難判斷：

• CUDA 對這個職位是否必要？
• 分散式訓練是否必要？
• RAG 是核心還是加分？
• 這是 ML Engineer 還是 AI Application Engineer？
• 這是 Agent 整合架構師還是後端工程師？
• 這是模型基礎設施職位還是產品應用職位？
• 這個人是要寫模型，還是要接模型？
• 是要做底層效能，還是要做工作流整合？

於是最安全的做法似乎是：

全部留下。

這會導致職缺技術詞堆疊。

第五步：職缺變成混合怪

最後 JD 可能變成一個混合怪。

它同時想找：

• 模型研究員
• 後端工程師
• 資料工程師
• DevOps
• Prompt Engineer
• Agent workflow designer
• 資安人員
• 顧問
• PM
• GPU 優化工程師
• MLOps 工程師
• 產品架構師

但薪資與職稱可能仍然只是：

AI Engineer

或者：

AI Specialist

或者：

AI Product Engineer

這就造成職位邊界模糊。

第六步：候選人被錯誤篩選

真正適合的人可能不投。

例如，一個很適合做企業 Agent 工作流的人，看到 JD 要求 CUDA、分散式訓練、深度學習研究經驗，就會認為自己不符合。

一個很適合做 RAG 與資料權限整合的人，看到 JD 要求模型預訓練與 GPU kernel，也可能放棄。

一個真正懂 Agent 系統架構的人，看到職缺把所有技術混在一起，可能判斷這家公司根本不知道自己要什麼。

反過來，投遞的人可能是偏底層模型或研究背景的人，但他入職後發現工作內容其實是：

• 串 API
• 做文件解析
• 接資料庫
• 設計權限
• 寫後端
• 做流程整合
• 跟業務部門開會
• 解決產品落地問題

於是雙方都覺得不匹配。

第七步：招聘失敗被解釋為 AI 人才短缺

當企業找不到合適人選時，最容易得到的結論是：

AI 人才真的很難找。

這個結論可能部分正確，但不完整。

更精確的說法可能是：

企業沒有正確定義 AI 職位，所以把可用人才排除在外，並吸引來不匹配的人。

此時，人才短缺就不只是供給問題，而是需求描述問題。

第八步：錯誤 JD 進入市場語料，成為下一輪模板

新的 JD 發布到招聘平台後，會被其他公司看到。

其他 HR 會模仿。 招聘平台會推薦類似寫法。 AI 工具未來也可能從類似語料中學習或檢索。 顧問文章也可能引用這些職缺作為市場趨勢證據。

於是錯誤開始循環。

這就是自指污染：

錯誤職缺生成錯誤職缺。 混亂語言強化混亂語言。 表面專業掩蓋實際不匹配。

四、AI 招聘自指污染的核心悖論

這個問題最有趣之處在於它具有自指性。

企業缺 AI 人才。 但企業不知道 AI 人才該怎麼定義。 於是企業用 AI 來幫自己定義 AI 人才。 但 AI 的答案來自既有市場語料。 而既有市場語料可能正是由不懂 AI 的企業寫出來的。 於是 AI 把既有錯誤重新包裝成專業建議。 企業再把這份建議發布成新的職缺。 新的職缺又成為未來市場語料。

因此，問題不是單純：

HR 不懂 AI。

而是：

HR 不懂 AI，所以依賴 AI； AI 依賴市場語料； 市場語料來自不懂 AI 的 HR 與管理層； 於是錯誤變成標準答案。

這就是自指污染的核心。

可以用一句話表示：

當一個尚未被正確理解的新職能，透過既有失真語料被 AI 反覆生成時，錯誤會以專業化形式自我複製。

這也是為什麼 AI 招聘自指污染比普通 JD 寫錯更危險。

普通 JD 寫錯，錯誤停留在一家公司。 AI 生成式 JD 寫錯，錯誤可能透過模板、平台、生成工具與市場模仿被擴散。

五、自指污染造成的五種後果

5.1 企業誤判人才市場

企業可能以為：

市場上沒有足夠好的 AI 人才。

但實際上，市場上可能有不少能解決該公司問題的人，只是他們不符合錯誤 JD 中的高端詞彙。

例如企業真正需要的是 AI 應用工程師，卻寫成模型基礎設施工程師。 真正需要的是 Agent 整合架構師，卻寫成 ML Research Engineer。 真正需要的是後端 + RAG + workflow，卻寫成 CUDA + 分散式訓練 + 大模型預訓練。

這會讓企業對人才市場產生錯誤認知。

5.2 合適人才被排除

職缺要求越混亂，越容易嚇退合適人才。

特別是那些具備跨域整合能力的人，往往不會自認符合所有底層技能要求。

因此職缺寫得越「高端」，不一定越能吸引強者。 有時反而會吸引錯誤類型的人，排除真正適合的人。

5.3 面試流程失焦

如果 JD 本身混亂，面試也會混亂。

面試官可能問一些與實際工作無關的問題。 例如工作其實是做企業 Agent workflow，卻問 CUDA、模型訓練、論文細節。 或者工作其實是做 RAG 系統，卻過度考深度學習數學推導。 或者工作其實是做 AI 產品落地，卻只考 LeetCode 與模型名詞。

這會導致面試無法測到真正需要的能力。

5.4 薪資與職級錯配

如果職缺寫得像模型實驗室，企業可能必須用很高薪資吸引人才。 但入職後工作內容其實只是應用整合，雙方都可能不滿意。

企業覺得花太多錢。 人才覺得工作不符合期待。 團隊覺得人不適合。 HR 覺得 AI 人才難管。 最後又回到「AI 招聘很難」的結論。

5.5 AI 轉型節奏被拖慢

最嚴重的後果是，企業真正需要的 AI 轉型被延誤。

因為公司一直在找錯人。 一直改 JD。 一直面試不匹配的人。 一直做不出可落地系統。 一直停留在 demo 與工具使用階段。

結果不是 AI 沒價值，而是人才定義錯了。

六、這不是 HR 的錯，而是缺少 AI 職能翻譯者

本文並不主張把責任全部推給 HR。

HR 的專業是人才流程、招募管理、組織制度、面試協調與人才發展。 HR 不可能自動理解所有新興技術分層。

在傳統職位中，HR 可以依賴內部用人主管提供職能定義。 但在 AI 新職能中，很多企業內部還沒有這種用人主管。

所以真正缺的是：

AI 職能翻譯者。

這個人需要能把企業模糊的 AI 需求，翻譯成正確的人才需求。

例如：

企業說：

我們要做 AI 客服。

AI 職能翻譯者要能拆解成：

• 是否需要 RAG？
• 是否需要工單系統整合？
• 是否需要 CRM 資料？
• 是否需要 human escalation？
• 是否需要語音？
• 是否需要多語言？
• 是否需要合規紀錄？
• 是否需要模型 fine-tuning？
• 是否需要本地部署？
• 是否需要 Agent 自動建立工單？
• 是否需要客服主管監控面板？

然後再決定要招：

• AI 應用工程師
• 後端工程師
• 資料工程師
• Agent workflow engineer
• 產品經理
• 資安/治理支援
• 或是否需要模型工程師

這個翻譯工作非常關鍵。

Agent 整合架構師正好可以承擔這種角色。

七、Agent 整合架構師如何打斷自指污染？

Agent 整合架構師不只是設計 AI 系統，也應該參與 AI 招聘需求校準。

他可以打斷自指污染迴路。

7.1 將模糊需求轉成明確任務

企業說「我們要 AI 人才」，他要追問：

• 你要解決哪個流程？
• 你要 AI 做到哪一步？
• 你有什麼資料？
• 你有哪些內部系統？
• 你是否要自動執行？
• 你是否需要人工確認？
• 你是否需要審計紀錄？
• 你是否需要本地部署？
• 你是否真的需要模型訓練？

7.2 將技術詞彙分層

他要能區分：

• 模型基礎設施能力
• AI 應用工程能力
• Agent 整合架構能力
• 資料治理能力
• 產品流程能力
• AI 治理能力

避免把所有詞塞進一份 JD。

7.3 刪除裝飾性技能

如果產品不需要 CUDA，就不要把 CUDA 寫成必要條件。 如果不做分散式訓練，就不要要求分散式訓練。 如果不自研模型，就不要要求大模型預訓練經驗。 如果只是使用雲端模型 API，就不要把職缺寫成基礎模型研究職位。

7.4 用工作任務描述取代技術名詞堆疊

例如不要只寫：

熟悉 RAG、Agent、LLMOps、MCP、Kubernetes、CUDA。

而要寫：

能設計企業文件問答與任務型 Agent 流程，將內部資料、權限、工具與人工確認節點整合起來，並建立評估、監控與錯誤回復機制。

這樣才能吸引真正合適的人。

7.5 設計面試測試

Agent 整合架構師可以協助設計真正 relevant 的面試題。

例如：

• 請設計一個客服 Agent 的權限與升級流程。
• 如何讓 Agent 接入 CRM 但避免越權？
• 如何評估 RAG 回答品質？
• 如何設計 human-in-the-loop？
• 如何處理 Agent 工具調用失敗？
• 如何判斷某個流程是否適合自動化？
• 本地模型與雲端模型如何分工？

這些題目比單純問技術名詞更能測到實際能力。

八、可觀察的判準

AI 招聘自指污染可以用一些現象觀察。

如果一份 AI JD 出現以下特徵，就可能存在自指污染：

1. 職位名稱很模糊，例如 AI Specialist、AI Engineer、AI Expert，但工作內容不清楚。
2. 技能清單極長，包含多個不相干層級。
3. 產品是應用層，但要求底層 GPU 或大模型預訓練。
4. 職缺要求像一整個團隊，而不是一個人。
5. 必要技能與加分技能沒有分開。
6. 面試官無法解釋每項技能對應哪個工作任務。
7. JD 中大量使用熱門詞，但缺少具體任務描述。
8. 公司說要 AI 轉型，但沒有說明要改造哪個流程。
9. 職缺要求研究能力，但實際產品是流程整合。
10. 招聘方說「希望候選人都懂一點」，但沒有明確核心職能。

這些不是絕對證據，但可以作為警訊。

九、如何避免 AI 招聘自指污染？

企業可以採取以下方法。

9.1 先問任務，不先問技能

不要一開始問：

AI 工程師需要哪些技能？

應該先問：

我們要讓 AI 完成哪些任務？

任務清楚後，技能才會清楚。

9.2 建立 AI 職能分層表

企業應該先建立基本分類：

• AI 使用者
• AI 應用工程師
• Data / Context Engineer
• Agent Workflow Engineer
• Agent 整合架構師
• AI Platform Engineer
• Model Infrastructure Engineer
• AI Researcher
• AI Governance Specialist

不同職位不要混寫。

9.3 所有 AI 生成 JD 必須由技術/架構人員審查

AI 可以協助起草，但不能直接成為最終版本。 尤其是 AI 職缺，必須經過懂 AI 分層的人審查。

9.4 將必要技能限制在少數核心能力

一份好的 JD 不應該列出 30 個必要技能。 如果真的需要 30 個技能，通常代表這不是一個職位，而是一個團隊。

9.5 明確標記加分技能

如果 CUDA 只是加分，就不要寫成必要。 如果模型訓練只是加分，就不要讓候選人以為這是核心工作。 如果雲端部署只是加分，也要說清楚。

9.6 建立入職後工作內容回饋機制

企業應追蹤：

• JD 要求了什麼？
• 入職後實際做了什麼？
• 哪些技能根本沒用到？
• 哪些能力漏寫了？
• 哪些要求嚇退了候選人？

用這些資料改善下一版 JD。

十、理論意義：AI 不只改變招聘，也改變職能定義本身

AI 招聘自指污染命題的意義，不只是提醒企業不要亂寫 JD。

它揭示了一個更大的問題：

當 AI 進入新職能定義過程時，AI 不只是工具，也可能成為市場語言的放大器。

如果市場語言準確，AI 可以提高效率。 如果市場語言混亂，AI 也會放大混亂。 如果市場語言充滿錯誤分層，AI 會將錯誤分層重新整理成看似合理的文本。 如果企業沒有校正能力，錯誤就會擴散。

因此，未來企業不只需要會使用 AI，也需要有能力審查 AI 生成的組織語言。

招聘語言就是其中之一。

AI 可以寫 JD。 但 AI 不應該替企業決定職能本質。 職能本質必須來自對產品、流程、技術層級與組織目標的理解。

這正是 Agent 整合架構師與 AI 總控架構師的重要性。

十一、結論：缺的不只是 AI 人才，而是定義 AI 人才的人

AI 招聘自指污染說明了一件事：

在 AI 新時代，企業缺的不只是 AI 人才，也缺少能正確定義 AI 人才的人。

傳統 HR 在成熟職能中可以依賴內部主管校正。 但在 AI 新職能中，許多企業尚未擁有這種內部校正能力。

於是 HR 轉向 AI。 AI 轉向市場語料。 市場語料又包含許多失真的 AI 職缺。 結果錯誤被專業化、模板化、再生成化。

這就是自指污染。

要打斷這個迴路，企業必須建立 AI 職能分層能力，並讓懂技術、懂流程、懂產品、懂治理的人參與招聘需求定義。

這種人可以是 CTO。 可以是 AI 產品架構師。 可以是 Solution Architect。 也可以是本文所說的 Agent 整合架構師。

未來，企業要問的不是：

我們要不要用 AI 來寫 AI 職缺？

而是：

我們有沒有能力判斷 AI 寫出來的 AI 職缺是否正確？

如果沒有，那麼企業越依賴 AI 寫 AI 職缺，就越可能複製錯誤的人才定義。

因此，AI 招聘自指污染命題最後可以濃縮成一句話：

當企業不懂 AI，卻用 AI 來定義 AI 人才時，AI 可能不是解決招聘問題，而是在放大招聘問題。

附：一句話版本

AI 招聘自指污染命題：企業因為不懂 AI 職能而詢問 AI 如何招聘 AI 人才，但 AI 生成的職缺又依賴既有失真的市場語料；當 HR 缺乏技術分層能力而直接採用這些內容時，錯誤的人才定義便會被循環引用、模板化與擴散，進而製造出表面上的 AI 人才短缺。