那個讓我後悔三秒鐘決定的下午：HR 到職流程全自動化的起點

我是浪花科技的資深工程師 Eric。某個週五快下班的時候，業務與 HR 部門的主管在群組裡丟了一句：「最近招募量很大，Eric，能不能讓 AI 幫我們把到職流程自動化就好？」

老實說，全辦公室當時都覺得這是個絕對賺的決定。那時候我也這樣想。畢竟我們都知道，HR 小姐姐每天要處理的行政瑣事本來就多得嚇人：從 offer letter 寄發、Google Workspace 帳號開通、Slack 群組加入、設備申請，一直到第一週報到行程安排。每一個環節都是獨立的老舊系統，每一個資料庫彼此都不互通，每一個步驟都全靠 HR 燃燒生命在手動 key-in。如果新人第一天報到，發現信箱沒通、權限沒開，那真的是大寫的尷尬。

「這有什麼難的？API 串一串，讓 AI 當大腦判斷就好了啊。」身為一個寫扣多年的工程師，我拍了拍胸脯接下了這個專案。但我沒想到的是，這個看似單純的企業數位轉型專案，即將在接下來的 45 天裡，變成一場差點搞垮新人到職體驗的血淚災難。

第一週：興奮期，一切看起來都很美好

開發的第一週，我們充滿了「改變世界」的工程師浪漫。我們選擇了 2026 年當紅的自動化神器 n8n，把公司老舊的 HR 系統、Google Workspace 和 Slack 全部透過 Webhook 與 API 串接起來，然後接上 Claude 的大語言模型（LLM）作為中間的判斷與文案大腦。

我們設計的系統邏輯非常簡單粗暴：

• 只要 HR 在招募系統後台將應徵者的狀態改為「確認錄取」。
• n8n 監聽到 Webhook，立刻啟動整條流水線。
• Claude 自動生成客製化的 offer 信。
• 系統背景自動建立 Google 帳號、開通 Slack 專屬頻道。
• 自動發送設備申請單給 IT 採購部門。
• 把報到行程自動塞進新人的 Google 行事曆。

當我們在測試環境按下執行的那一刻，看著終端機裡跑出的一排排 HTTP 200 OK，以及 Slack 頻道裡瞬間跳出的歡迎訊息，Demo 跑起來的那個瞬間，我們幾乎以為自己做出了什麼了不起的企業級 SaaS 產品。看著 HR 主管感動的眼神，我們以為專案已經可以順利結案了。

第二至第三週：細節開始崩壞，AI 的「超前部署」與「過度腦補」

身為工程師的小囉嗦：永遠不要相信系統在 Happy Path（理想路徑）下的測試結果。第一個真正的問題，發生在系統上線後的第九天。

一位準備入職的新進工程師，在預計報到日的前三天，突然收到了一封信。主旨是「歡迎你正式加入浪花科技」，內文不僅充滿熱情，還附上了他的員工編號、公司信箱密碼，以及第一天的超詳細行程安排。聽起來很完美對吧？

問題是，那位工程師的「實際到職日」根本還沒跟 HR 確認好！他甚至還沒跑完前東家的離職手續，我們連辦公室的座位跟電腦都還沒生出來給他。

我們翻開 n8n 的 Log 紀錄才發現，原來 HR 在後台只是順手把「錄取確認」的這個欄位打勾，打算先保留名額，但 AI 代理人一讀到狀態改變，就以為「一切都到位了」，像個急躁的新手一樣，直接觸發了整條報到流水線。沒有人告訴 AI，在系統的「打勾」跟現實世界的「一切準備就緒」之間，其實還差了十萬八千里的人工確認步驟。

另一個讓我們頭痛到不行的問題是，AI 在生成個人化歡迎信的時候，開始產生嚴重的「AI 幻覺（Hallucination）」。因為我們給的 Prompt（提示詞）是請它「根據職缺描述，給予新人期待與勉勵」。結果，Claude 開始自由發揮，在信裡寫了一堆「你將會負責帶領浪花科技跨部門的 AI 轉型專案，並重構我們的核心微服務架構」之類的句子。這段話聽起來又專業又漂亮，但……那個人只是來應徵初階客服助理的啊！

第三至第四週：條件越加越亂，災難性的邊界測試 (Edge Case)

遇到問題怎麼辦？工程師的直覺就是寫 if-else 加判斷條件。我們以為多設幾個防呆機制就能解決，結果沒想到條件越加越複雜，n8n 的工作流（Workflow）節點多到長得像一張台北捷運路線圖，牽一髮而動全身。

某天晚上，系統在跑定時批次任務（Cron Job）的時候，遇到了一個我們沒處理好的 Edge Case（邊界測試情境）。系統因為某個 API 回傳了 Timeout，導致 n8n 的 Retry 機制大爆走，同時觸發了五封語氣截然不同的歡迎信給同一位新人。五封。同一個人。同一個晚上。

那位新人隔天早上驚恐地傳訊息給 HR 問說：「請問我是不是不小心錄取了貴公司的五個不同職位？」

但比發錯信更嚴重的，是設備申請那條線。AI 被賦予了根據職稱「自動填寫硬體申請單」的權限。結果它看到一位來應徵「業務經理」的人，自作主張地判斷「經理」需要最高效能，於是把他的設備規格設定成資深後端工程師等級的頂規 M4 晶片筆電，外加兩顆 4K 雙螢幕。採購部門收到 ERP 系統的 API 請求後，以為是高層簽核過的正式需求，就直接下單了。等到 HR 發現的時候，幾十萬的設備已經在送來公司的路上了。

這件事給我們上了一堂超貴的課：當 AI 代理人接管了 API，它在做決策的時候，永遠不知道「這個動作會觸發物理世界不可逆的成本代價」。在數位世界發錯信還能解釋，但在現實世界買錯東西，那是真的會搞垮公司帳務的。

第五至第六週：我們終於停下來，重新想清楚「人機協作」架構

痛定思痛之後，我跟團隊決定按下暫停鍵。我們意識到，問題不在 AI 不夠聰明，而是我們給了它「錯誤的權限與期待」。我們把整個像麵條一樣糾纏的 n8n 流程打掉重練，拆成兩個完全物理隔離的區塊：

1. 準備層（Draft Layer）：AI 的沙盒遊樂場

在這個層級，AI 可以盡情發揮它強大的統整與生成能力。它可以幫我們草稿一切：生成歡迎信、預填設備申請單、整理報到行程。但是，所有的產出都只會存放在一個內部 Dashboard 的「草稿夾」裡。沒有任何一條 API 會直接對外發送請求，沒有人工確認，就不會觸發任何對外的動作。

2. 執行層（Execution Layer）：人類的最後防線

HR 只需要每天早上打開系統，確認 AI 準備好的草稿。如果沒問題，點擊一個「確認並發送」的按鈕，系統才會將 Webhook 丟進執行層，真正發出信件與採購單。聽起來好像讓 AI 做的事情變少了？不，實際上減少的只有「AI 自作主張的破壞力」，它依舊幫 HR 省下了 80% 撰寫與填表的時間。

除此之外，身為被坑怕了的工程師，我還加了一個很土但是非常有效的追蹤機制。就是每一封對外發出的信件、每一筆 API 請求，都必須在標題的隱藏欄位或 Header 帶上一個 timestamp（時間戳記）和 flow_id（流程 ID）。這樣日後如果流程再暴走，我們三秒鐘就能從龐大的 Log 中抓出是哪個觸發點在作怪。

結語：自動化不是拔掉人工，而是升級人工

經過這 45 天的血淚復盤，我們的 HR 自動化系統終於穩定了下來。現在的新人報到體驗非常絲滑，HR 主管也不用再為了跨系統建帳號而加班。但在這背後，是我們學到的深刻教訓：在 2026 年，把 AI 當作全能神仙直接放養，絕對是企業災難的開端。真正的自動化，應該是讓 AI 負責繁瑣的「準備工作」，而把最終的「裁量權」保留給人類。

延伸閱讀：更多 AI 自動化翻車與救援實戰

如果你正在規劃企業的 AI 自動化導入，千萬別錯過我們團隊用血淚換來的這些避坑指南：

• 2026 系統排程大屠殺：AI 代理人接管 WordPress 與 Laravel Scheduler 的 45 天血淚復盤與避坑指南
• 2026 終極翻車實錄：把 n8n 與 AI Agent 當業務主管用？60 天差點燒光客戶名單的血淚復盤
• 告別 AI 幻覺！2026 企業專屬 AI 大腦建置指南：用 RAG 技術讓 LLM 讀懂內部機密文件

你的企業也正在為了老舊系統的整合與 AI 自動化導入而頭痛嗎？不要等到系統大翻車才來找救援！現在就到 浪花科技聯繫我們 填寫表單，讓我們的資深工程團隊幫你規劃最安全、高容錯的自動化架構。