先講一個很常見、也很難看的畫面。

三個月前上線的那套自動化，還在跑。每天早上照常吐出報表、照常把單子分好類、照常寄出通知。沒有人抱怨，因為沒有人看。真正的問題要等到某一天客戶打電話來，才會被翻出來：它其實從六週前就開始算錯了，只是錯得很安靜。

接下來的對話更值得記下來。你問這是誰負責的，行政說是找廠商做的，廠商說當初是資訊窗口驗收的，資訊說內容是業務端提的需求。三個人講的都對，沒有一個人的名字在上面。

它沒有壞。它只是沒有人管。

前面幾篇談的是蓋起來之後怎麼證明有效：先寫下驗收條件，別在第一個月急著問投報率。這一篇要問一個更早、也更少人問的問題。這東西上線之後，是誰的？

01導入會議上最少被問的一個問題

導入前的會議，問題其實都問得很好：這能省多少時間、多久可以上線、要花多少錢、資料安不安全。

然後有一個問題幾乎沒人問：三個月後它壞了，誰負責？

這是順序造成的錯覺。導入是一個專案，專案有起點有終點，上線那天感覺像終點。但自動化比較接近設備：會折舊、會失準、會需要保養，而保養從來不會自己發生。

有一份企業級 Agent 專案的復盤整理，把失敗歸成四種模式，其中一種寫得特別狠：上線即「失聯」，問題堆積，價值無法體現。同一份整理的結論是「技術是基礎，協作與反饋才是落地的關鍵」。它把落地最難的部分明白地放在組織那一側，不在模型那一側。

失聯這個詞用得準。它還活著，只是沒有人跟它保持聯絡了。

02它不會壞得很大聲

如果自動化會像機器一樣冒煙、跳電、發出巨響，這篇文章就沒必要寫了。麻煩在於它腐爛的方式很體面：輸出照常產生，格式照常正確，只是內容有一部分不再成立。

三種變化幾乎必然會發生，而且都不是技術事故。

流程會變。 報價單多了一個折扣欄位、退貨流程多了一道主管確認、客戶分級的標準改了。人會自己適應，因為人在現場開會。自動化不在，它照著三個月前那版流程繼續做。

資料源會改。 換了進銷存系統、Excel 的欄位順序調過、客戶名單從 A 表搬到 B 表。有時候連搬的人都不知道有東西接在上面。

模型會換版。 你用的那顆模型今天升級、明天調整、後天把某個行為改掉。它多半變好了，但「變好」不等於「跟你去年寫的那套指令仍然合拍」。

三件事都不會發出任何聲音。它們只是讓一個原本準確的流程，慢慢變成一個大致還可以的流程，再變成一個沒人敢完全相信、但也沒人敢關掉的流程。

不敢關掉，是這件事最後的形狀。中國那波 OpenClaw 棄養潮把這個階段演得很完整：安裝服務有人做、移除服務也有人做，閒魚和社群上一次收人民幣 299 元幫你把它清乾淨，有網友算完帳說這叫花 599 裝、再花 299 拆，付了兩次智商稅。

那些被棄養的東西，絕大多數不是壞掉。是養不動了，而養不動的起點，是一開始就沒說清楚誰要餵。

前面談過別養一隻你管不動的龍蝦。那篇講的是「別養」。這篇要接的是後半段：既然已經養了，誰餵。

03維護人不是一個技術職缺

到這裡最容易滑掉的地方是：把上面的問題翻譯成「所以要找一個工程師顧著」。

那是錯的方向，而且是很貴的錯誤。

有一份談企業 AI 為什麼不該當成 IT 專案的材料，把這件事拆得很清楚：把 AI 的 Owner 下放給資訊部門，專案會脫離業務、長期停在試點階段；可行的模式是一個三方治理三角，CEO 負責戰略引領，業務一號位負責價值創造，資訊端負責平台支援。它引用麥肯錫的 10-20-70 法則佐證：10% 算法、20% 數據與技術、70% 是人、流程與文化。

七成落在組織那一側。維護人這個角色，自然也在那一側。

因為判斷「它現在算得準不準」，靠的是業務判斷。報價合不合理、分類對不對、這封信該不該這樣回，會寫程式的人未必答得出來，天天在現場的人一眼就知道。

所以維護人要負責的其實是三件事，沒有一件需要打開程式碼：

知道它現在還準不準。 有一個固定週期、有一個看得出對錯的判準。這是前面寫過的那張驗收條件的紙，在上線之後的續集。

有權喊停。 發現不對的時候，他不需要開會、不需要等廠商回覆，可以直接把它關掉。沒有這個權限的人不叫維護人，叫回報人。

流程變動時會被通知。 公司改流程、換系統、調欄位的時候，他在名單上。這一條最常被漏掉，也最常是後面所有錯誤的起點。

至於實際動手改的人，廠商、資訊同事或外部顧問都可以。那是能外包的部分；簽字的那一格不能。

04這個角色，業界早就給過名字

Anthropic 的 Claude Code 負責人 Boris Cherny 提過一組角色原型，主張用它取代傳統職稱來組織團隊：Prototyper（發想）、Builder（快速落地）、Sweeper（整理精簡）、Grower（迭代成長）、Maintainer（維護成熟系統的穩定與效率）。他還補了一句對中小企業特別有用的話：多數人會橫跨其中兩到三種角色，而且這些角色跟職稱沒有對應關係，同一個職稱的人可能分屬不同原型。

更值得記住的是他對階段的判斷。全新的東西需要 Prototyper、Builder、Sweeper；已經站穩的東西，主力換成 Sweeper、Grower、Maintainer。同一組說法在另一篇報導裡的角度更直接：AI 時代團隊最缺的兩種人，是清理的人與維護的人。

那篇報導最後給管理者留了三個問題：團隊是不是只獎勵新增功能、誰有權停止一個錯誤的方向、誰明確負責清理與維護。三個問題都不必動到組織圖。

翻成老闆聽得懂的版本：導入期你花錢買的是搭建，上線之後你需要的是照顧，還有敢刪。多數公司只編了第一種的預算。

好消息是這通常不必新增人頭。既然角色跟職稱無關，維護人往往就是現在那位最熟這條流程的同事。差別只在於，這件事現在是他工作說明上寫著的一格，而不是他順手在做的一件事。

順手在做，是最脆弱的安排。他休假的那兩週沒人接，他離職那天整件事跟著走。

還有一種指派方式要特別避開。有一份談分工誤判的管理材料列了四種常見錯法，第一種是「看誰閒，就分給誰」，第三種是「只把活分出去，沒把標準講清」，只說你來做，沒說做到什麼程度、什麼時候算完成。維護人這個位子，剛好是這兩種錯法最愛落腳的地方：交給手上比較空的那個人，然後不告訴他要看什麼。

05上線那天，該落筆的三行字

這件事的解法不需要制度，不需要委員會，不需要一份辦法。需要的是三行字，在上線那天寫進交付文件裡。

第一行 · 誰負責它壞掉。 寫名字，不寫部門。部門不會在半夜發現報表算錯。

第二行 · 多久檢查一次，用什麼判準。 每月抽十筆比對、每週看一次退件率、每季由某人重跑一遍去年的案例。頻率不重要，寫下來才重要。

第三行 · 什麼情況下關掉它，誰有權關。 這一行最像廢話，也最少人寫。它的作用是讓「關掉」變成一個正常選項，而不是一次要驚動所有人的事故。

過去 一套系統上線，交付物是帳號、密碼、教育訓練

現在 還要多一張紙：一個名字、一個週期、一個退場條件

寫下這三行，不會讓自動化更聰明。它只是把一個沒有主人的東西，變回一件資產。

會關掉的東西，才是你的

這一批文章從「你怎麼知道 AI 真的有幫上忙」開始問，問到這裡收在同一個地方：能不能被驗收、能不能被停用，決定一個工具是資產還是負債。

談模型外面那一層時說過一句話，放在這裡剛好成對：拆不掉、沒人敢動、只有某一個人知道怎麼跑的東西，不是資產。這篇要補的是那句話的前半段。會不會走到那一步，在上線那天就決定了，而決定它的不是技術選型，是文件上有沒有人簽字。

這也是做 AI 落地體檢時，我們在既有系統上第一個問的問題：它是誰的。答不出名字的，通常也就是那幾套沒人敢碰、卻每個月照常付費的東西。

讓 AI 加速，讓人定錨。系統可以自動，責任不行。

為品牌築根，為數位開路。