一件事該給 AI 還是留給人?可逆、可查證、誰扛責——三個問題，把同事既有的工作一起考慮進去

幕一花了六天做一件事: 把 AI 從媒體敘事裡拆出來，看清它到底是什麼、能到哪、又到不了哪。D6 的 WEBEX 實例甚至讓你親眼看到——它會自信地錯。

那問題就來了: 既然它有極限、又真的能扛規模與速度，面對一件具體的事，你到底該把它交給 AI，還是留給人? 這篇不給你一句「重要的留給人」這種廢話。

給你三個能實際拿去用的問題。而且你會發現，這三個問題劃出來的不只是「AI vs 人」的線——也劃出你的同事在這套新環境裡，站在哪。

還有一件更容易被漏掉的: 當你把一段責任劃給某個人，你有沒有同時把「他守得住那段責任」需要的東西一起給他。

幕一結束在「AI 會自信地錯」，那接下來要問什麼?

接下來要問的，不是「AI 夠不夠強」，而是「這件事的性質，適不適合交給一個又快又不累、但偶爾會自信地錯的東西」。 判斷的對象，從「AI」換成「這件事」。

同一個 AI，拿去「每天把全球上百條新漏洞讀過、判讀哪幾條跟自家環境相關」很適合(規模、重複、它不累);拿去「決定這台對外主機今晚要不要停機升級」就很不適合(一停機影響一片、錯了收不回)。差別不在 AI，在這兩件事的性質不一樣。怎麼快速分辨?問下面三個問題——它們各自對應一個工程上的老概念: 可逆性(reversibility)、可驗證性(verifiability)、可歸責性(accountability)。

該給 AI 還是留給人?先問: 這件事「可逆」嗎?

第一問: 做錯了，收得回來嗎? 可逆的事——做錯能輕易回滾、影響範圍小——很適合交給 AI，因為它就算偶爾錯，代價也低、還救得回。不可逆的事——一按下去影響一片、收不回——最終那一下，留給人。

不是「不可逆的事 AI 不能碰」，而是分工: AI 可以把不可逆決策「之前」的所有準備做完(蒐集、比對、整理出選項與風險)，但扣下扳機的那一下留給人。AI 把你帶到決策點，人做那個不具「可逆性」的決定。

第二問: 結果「可驗證」嗎?

第二問: 它給的答案，有可驗證性嗎? 這一問直接接著 D6——AI 會自信地錯，所以能不能快速驗證它的產出，決定你敢不敢放手。

• 產出查得證(有客觀依據、能對回原始資料): 像 AI 判讀「這台設備的狀態哪裡不對勁」，它標出的每一點都能回頭對原始狀態檔查證——可以放手讓它大量做，人抽驗即可。
• 產出查不了(只能憑感覺相信它): 那就要留一道人的把關，別讓一個會幻覺的東西給出無人複核的結論。

在 AI 應用開發裡，可驗證性就是一個設計決定——它決定了人要站在「抽驗」還是「逐件複核」的位置。

第三問: 出事「誰扛責」?

客戶開口問「這張報價是誰同意的」的時候，你不能回答「系統算的」。

第三問，也是最硬的一問: 這件事出了事，誰承擔後果? 因為責任沒辦法轉移給 AI。

所以凡是「有一個人的名字要扛在上面」的事——對外的報價承諾、放行的簽核、影響客戶或資安的決定——那個人就必須真的在迴圈裡，不是橡皮圖章。 AI 在這裡的角色是那個人的放大器(幫他把該看的都看完、該比的都比完)，不是替他簽名的替身。

三問合起來很好記: 可逆、可查證、誰扛責。 三個都偏「是/低風險」→ 大膽交給 AI;任一個偏「否/高風險」→ 那一段留一個人在。

劃完界，別忘了劃權——那個人憑什麼守得住?

但三問只做完一半的事。 它劃出了「哪一段留一個人在」，卻還沒回答一個更難的問題: 那個人，憑什麼守得住?

你把「不可逆的那一下」留給他，等於把責任放在他身上。而責任不能空手扛。所以劃界的同時，必須把兩樣東西一起給他:

• 技術上，要給他能力。 他被要求負責的範圍，人力本來就守不住——一天讀不完的漏洞、看不完的狀態檔、比不完的型號相容。AI 補上規模與速度，目的不是接他的位置，是把這個範圍變成扛得動的。開發 AI 就是來幫你把原本無法處理的事情真的扛起來。
• 組織上，要給他權力。 最起碼的一項是——他有權說不。 系統推薦今晚停機升級，他看完說「今天不行」，那就不行，不需要為了擋下一個自動化流程去寫報告解釋自己。一個不能否決的人，不是負責的人，是背鍋的人。

這也是為什麼很多公司的 AI 導入會卡住: 界劃得清清楚楚，責任壓在人身上，權卻沒跟著給。劃界，同時就是劃權。 後面幾篇會一項一項交出來: 讓抗拒的人有權參與設計(D9)、沒有正式職權時怎麼取得推得動的資源(D11)、怎麼保留一條退得回去的舊路(D13)——照著流程做卻還是出錯時，錯在設計不在操作者(D29)。

把三問套到真實系統上——劇透這三套上線後「真的」變成什麼

這三問不是紙上談兵——我後面 D19 開始會實際做給你看的三套系統，分工線就是照這三問劃的。 先各給一個決策點，再劇透它上線後「真的」變成什麼(完整過程留到各系統的引用篇):

• 設備運作分析: AI 負責「把人讀不完的設備狀態檔判讀完、標出異常、還推論出為什麼要緊」——可查證(流量分佈、埠狀態都是客觀訊號)，放手交給它;「這台要不要動」的處置留給人。而它上線後的結局出乎我意料: 最值錢的不是拿來修自家設備，是變成一份別人端不出、對客戶的差異化服務——能在客戶的設備裡指出連他自己都還沒察覺的問題。因為這件事本來根本沒人做得到，它沒取代誰，是憑空長出了新位置。完整故事在 D21。

• 每日 CVE 通報: AI 負責「把全球每天上百條新漏洞讀過、盯出跟自家相關的、生成一份讀得下去的通報」——可逆、可查證，放手交給它;「這條要不要通知、那台要不要停機升級」留給人。而它上線後幾乎不是拿來「擋駭客」的——是進了客戶的資安稽核與認證流程，還變成「連旁相關的風險都替你盯著」的主動接觸話題。漏洞管理本來就是人人在做的本質工作，AI 沒取代它，是讓這件 **「該做卻永遠做不滿」**的事終於跟得上全球規模。完整故事在 D24。

• 向原廠下單: AI 負責「從一句需求生出一版湊好型號、相容、即時價的報價」——可逆、可查證，放手交給它;但「這張報價送不送、折扣讓不讓」——留給業務作為談判的手牌，所以它出的永遠是一版草案。這是三套裡最硬的一次考驗: 報價本來就有業務在做。結果那個業務沒被取代——被接走的是「湊料號、比即時價」的苦工，人回到「懂客戶、會談判、敢簽名」那半，系統還被順手拿去當跟客戶互動的談資。完整故事在 D27。

你會發現，同一組三問，劃出了三種不一樣的「不取代人」: 設備分析是開一塊本來沒人站得上的新疆域、CVE 通報是把一件做不滿的本質工作做滿、下單報價是接走既有工作裡最磨人的那半、把人推回值錢的那半。形狀不同，底層同一句: AI 去它擅長的規模與速度，人守在要簽名的那個位置上——而且整件事情守得住，因為該讀完的、該比完的，都替他做完了。 至於人站上那個位置之後會長出什麼，後面三篇會一個一個做給你看。

劃完 AI 和人的線，別忘了它有可能會動到別人原本的工作

這條線最容易被忽略的一件事: 你在設計新系統與新流程時，它同時會動到「你身邊那位同事原本怎麼工作」。 這決定了他會擁抱這套系統、還是抵制它。

想像那位做了十年、對設備瞭若指掌的資深同事，他原本的工作就是「逐台巡、逐條比」。如果新系統把這塊接走了，而你在設計時沒把他既有的工作流程與職掌考慮進去——他很自然會覺得自己被取代。但如果你設計系統與流程時，一開始就把他原本的工作事務納進來一起看，會發現「查得證要抽驗、不可逆要拍板、出事要扛責」的那半——正好需要他那十年經驗。

換句話說: 設計 AI 系統與流程，本身就會重塑同事原本的工作。 三問幫你把「該交給 AI 的」交出去，同時也幫你看清「該留給人的」——而在設計新流程時把同事既有的工作事務一起考慮進來，那半正是他的經驗最派得上用場的地方。至於他被納進來之後，願不願意站上那個位置，又是另一回事了。

這裡先埋個伏筆: 後面你會看到，一開始最抗拒、覺得自己要被取代的那位資深同事，他對「被 AI 取代」的焦慮怎麼被實際的分工化解——這條「取代焦慮 → 實際分工」的線，到 D27 會被正面、完整地收掉(前面 D21、D24 先停在組織與商業層，還沒碰個人)。

簡單來說

• 判斷的對象是「這件事」，不是「AI 強不強」: 同一個 AI，適不適合，取決於這件事的性質。
• 三問: 可逆、可查證、誰扛責: 三個都偏低風險 → 交給 AI;任一個偏高風險 → 那一段留一個人在。
• 共同形狀: AI 把人帶到決策點，並讓他有能力做那個決定: 機器負責規模與速度，人守住收不回的那一下——而 AI 的工作就是讓這一下守得住。
• 責任不能轉移給 AI: 高責任的事一定要有一個人的名字扛著，AI 是放大器不是替身。
• 劃界的同時要劃權: 把不可逆的那一下留給人，就得同時給他「有權說不」——不能否決的人不是負責的人，是背鍋的人。
• 設計新系統與流程時，把同事既有的工作納入考量: 別只把他原本的工作接走，「抽驗/拍板/扛責」那半正好需要他的經驗——這是化解抗拒的第一步。

這三個問題，不是要你把工作分給機器就好，是幫你看清一件事: AI 接手的是「人做起來吃力又容易錯」的那半，人守的是「收不回、要簽名」的那半——而 AI 的工作，就是讓這半守得住。 而你身邊的同事，本來就站在後面那半——問題只在於，你在設計新系統與流程時，有沒有把他原本的工作流程與職掌一起考慮進去，有沒有把權跟能力一起交到他手上。

但位置留好了，不等於他就會站上去: 就算你把權和能力都給足了，他還是可能一開始就抗拒。 因為抗拒往往不是理性的位置問題，是「自動化=威脅」的直覺反應、是世代對改變的不安。那到底怎麼回事、又怎麼化解?從明天 D8 開始講。