AI時代的執行邊界

序言　這些故事，不只屬於一家公司

許多企業第一次認真考慮引入 AI 時，想的並不是什麼宏大的未來。經營者想把成本降下來，主管希望月底少加幾天班，員工盼著不必再把同樣的資料從一張表格搬到另一張表格。有人盼著客戶少等一會兒。技術進入辦公室，往往從這些具體的願望開始。

最初，AI 更像一位隨叫隨到的助手。人問一個問題，它給出回答；人交給它一份文檔，它幫助歸納；人寫不出郵件，它起草一版，再由人修改、發送。即便答錯了，多數時候還有人在屏幕前決定是否採用。後來，隨著系統能夠接入業務資料、調用工具、連接工作流程，一些 AI 助手開始具備智能體（Agent）的能力：它們不只回答問題，還能夠連續完成任務，整理供應商報價、準備客戶回覆、核對賬目、安排服務時間，甚至在預先允許的範圍內推動下一步操作。這是值得歡迎的進步：機器的速度不再只體現在漂亮的文字上。

變化也從這裡變得複雜。一份報告可以很快生成，判斷其中的價格是否仍然有效，卻要面對真實的供需變化；一封客戶郵件可以措辭周到，卻可能作出公司尚未準備承擔的承諾；付款資料符合格式，不等於業務此刻確實應該付款。更令人困惑的是，問題未必出在一個不聰明的機器身上。資料可能過期，部門之間可能沒有及時溝通，審核的人可能疲憊，制度可能留下空白，最後發生的操作也可能和原先檢查過的內容不完全相同。

這些矛盾並非某一種行業獨有。生產企業需要在採購和交付之間作出選擇，服務企業在及時回應客戶與謹慎履行承諾之間尋找平衡，財務部門關心憑證與授權，技術部門則必須考慮一次改變會不會影響正在運行的業務。業務與風險各不相同；但當機器參與準備、判斷和行動時，組織可能遇見相似的問題：人究竟還應該檢查什麼，又該通過什麼方式，確保重要的要求沒有在最後一步落空？

為了把這些彼此關聯的問題講清楚，我們沒有把本書寫成若干互不相干的公司案例。接下來十五章裡，讀者將反覆遇見一家沒有名字的中型企業，看見採購、財務、銷售、客服、運維人員與經營者在日常工作中的欣喜、猶豫、爭執和改變。它並不指向現實中某一家特定公司，也不表示真有一家公司按書中的順序遭遇過所有這些事情。這是一家為敘事而構建的綜合性虛構企業：將不同組織在採用 AI 和自動化時可能碰到的典型處境，放進同一條連續的故事線，讓一件事留下的疑問，能夠在下一件事中得到追問。

因此，書中的人物、對話、業務往來及具體事件，不應被當作某家企業的調查記錄；出現的損失與客戶選擇，也不是未經註明便可以引用的真實案例或統計結論。故事能夠幫助我們理解一種風險怎樣形成，卻不能代替對現實公司的取證，更不能憑一段虛構情節證明某種技術必然有效。如果現實中有企業已經用成熟的權限管理、審批機制和自動化檢查很好地解決了某些問題，那也是這場討論應該承認的經驗，而不是為了故事的戲劇性必須抹去的事實。

我們之所以仍然選擇一家公司、一組人物貫穿全書，是因為制度問題很少孤零零地出現。今天為了提高效率而放開的權限，明天可能成為審核者無法解釋的操作；上個月為了堵住一次失誤而增加的審批，到了這個月又可能讓業務排起長隊。一位認真負責的員工，並不總能掌握他被要求批准的全部信息；一個發現了錯誤的團隊，也未必來得及挽回已經作出選擇的客戶。把這些情境放在同一家公司裡，讀者才能看見：問題不會每次從零開始，它們隨著組織的補救和學習改變形狀。

我們不想把這本書寫成對 AI 的控訴。能夠自動處理大量重複勞動、幫助人更早發現問題的工具，確實值得期待。更好的模型、更清楚的數據、更有經驗的員工和更完善的業務流程，也都能帶來改進。同樣，我們不想把傳統企業制度描繪成一堆已經過時的手續。崗位分工、授權、審批與相互制約，本來就是人類在承認彼此並不完美的前提下，仍然能夠共同工作的辦法。AI 的到來沒有讓這些經驗失去意義，只是讓它們面臨了新的速度、新的規模，以及能夠連續行動的新參與者。

真正令我們在意的，是討論常常停在兩個並不令人滿意的選擇之間：要麼讓人盯住機器做的每一件事，要麼等機器足夠聰明，再把更多事情放心交出去。可現實中的人也會誤判，審核能力也有盡頭；機器的能力可以持續提高，卻不能僅因為一次判斷看起來正確，就理所當然地得到讓現實隨之改變的資格。對於一項重要操作，企業除了問“方案好不好”“誰已經同意”，或許還必須繼續追問：到真正動手的這一刻，哪些條件不可缺少？誰有資格規定這些條件？如果條件不滿足，事情能不能停下來？

此前，我們已經圍繞執行控制寫過三本更偏技術與工程的書：《The Execution Gap》《Execution Control Engineering》和《Adversarial Completeness》。它們試著把有關權力、邊界與現實執行的問題講得嚴謹，卻也讓我意識到，這些問題不應該只留在技術人員之間討論。這兩年，也在 CSDN、虎嗅等平臺陸續發表相關文章，也為商業類週刊和媒體撰寫、投稿，嘗試從企業經營、組織管理和普通人的工作處境來理解 AI 帶來的變化。本書的許多問題與思考，正是從這些文章、稿件和此前三本書的長期積累中重新梳理出來的。它不是舊文章的簡單彙編，也不是把工程術語換成日常說法，而是希望讓那些原本顯得抽象的討論，能夠隨著一家公司裡發生的事情，走近更多讀者。

這不是一本要求讀者先懂程序、算法或安全工程才能讀下去的書。它從一份採購報告、一張審批單、一次客戶溝通寫起，逐步走向更深的權力和責任問題。這裡不會出現一個永遠正確的智能體，也不會出現一套能夠預知所有風險的制度。人有時保守，有時急躁，有時作出不划算的選擇；機器也不是永遠製造麻煩的角色。它們共同構成的，恰恰是我們需要認真面對的工作世界。

我們希望這十五章最終留下的，不是一份對今天所有 AI 風險的窮盡清單，也不是一種可以照搬到每家公司的標準答案，而是一種更踏實的思考方式：當智能已經能夠替我們完成越來越多的工作，甚至提出可以立即付諸現實的行動時，人類怎樣既不浪費這種能力，也不把治理責任寄託在任何一個參與者永遠正確的願望上。

故事從一個普通的星期一早晨開始。辦公室裡的咖啡機還沒有燒好水，一份原本要花半天才能完成的報告，已經靜靜躺在共享文件夾裡。對那家公司來說，這是效率提高的好消息。對我們來說，它也許是一個更值得慢慢追問的問題的開始。

---

致謝

寫這本書的時候，我常常想起這些年來與朋友們聊起人工智能的情景。有些交流發生在工作中，有些只是茶餘飯後的閒談。有人興奮地講述 AI 怎樣替自己省下了時間，有人分享一次令人驚喜的嘗試，也有人談到答非所問的無奈、反覆核對的疲憊，以及把一件事情交給機器時心裡那一點不踏實。

我要感謝這些願意與我分享使用心得和親身體驗的朋友。你們來自不同的工作崗位，有著不同的經歷，對 AI 的期待和擔憂也並不相同。正是這些樸素而真實的感受，讓我不斷提醒自己：討論人工智能，不能只停留在模型有多聰明、技術有多先進，還應該認真看看，它進入人們的工作和生活之後，究竟改變了什麼，又留下了哪些需要面對的問題。書中的企業和具體情節是綜合性的虛構故事，並不對應某位朋友或某家真實公司；但許多值得追問的問題，都受益於這些日常交流。

我還要特別感謝與我一起在 HAVENLON 工作的三位夥伴：吳夢婷、張勇、鄧江。我們一起面對過尚無現成答案的問題，也一起經歷過反覆討論、推翻想法和重新開始的過程。探索一件還沒有被充分理解的事情，並不總是令人興奮；更多時候，它意味著耐心、分歧、瑣碎的工作，以及面對不確定性時仍願意繼續向前。謝謝你們付出的時間、心力與信任。這本書雖然由我執筆，但其中許多思考，都離不開我們共同經歷的探索。

也要感謝我的家人。寫作和研究常常佔去本該留給生活的時間，是你們的理解與包容，讓我能夠安靜地把一些還不成熟的想法慢慢寫下來。尤其感謝家裡的小朋友。與你們相處的時刻，總能讓我從複雜的概念和爭論中回到生活本身，也提醒我：無論技術走得多遠，我們最終關心的，仍然是人怎樣生活、怎樣相處，以及怎樣為未來留下一點更好的可能。

::: {.ack-ending} 最後，感謝每一位願意翻開這本書的讀者。我並不期待所有人都認同書中的判斷。若這些故事能夠讓你在使用 AI、管理團隊，或思考人與機器的關係時，多問一個此前未曾認真想過的問題，那麼寫下它們，就已經很有意義。

王林

2026年10月於成都 :::

---

第一章　公司裡來了一群不會下班的新同事

從一份提前完成的報告開始

機器擅長把大量材料推到同一個地方，人卻往往必須重新走進材料背後的現實，才能對結果負責。

星期一早上九點，辦公室裡的人還在等咖啡機燒好水，採購部的一份供應商比較報告已經早早地躺在了共享文件夾裡。報告列出了幾家供應商的報價、交貨週期和付款條件，最後還附上了建議。負責採購的員工打開文件看了一遍，忍不住把屏幕轉向旁邊的同事：“這要是上個月，咱們倆得忙半天。”

報告並不是哪位同事週末加班做的。星期五下班前，採購部把幾份報價單和一張需求表交給新接入的 AI 助手，約定週一上班前整理出比較結果。到了早晨，它不但完成了表格，還把幾處報價差異單獨標了出來。員工原本準備先花兩個小時整理材料，現在只需要從結果裡找出值得進一步核對的地方。那天上午，採購部比平常早得多地結束了例會。

這是一家經營多年的中型企業。它沒有打算用機器取代所有員工，也沒有什麼令人眼花繚亂的技術計劃。最初的想法很樸素：公司每個月都有大量重複的資料整理、訂單核對、客戶答覆和系統檢查工作，能不能讓 AI 先做其中一部分，讓員工把時間留給真正需要經驗和判斷的事情？管理層算的是一筆日常經營賬。AI 服務的費用看得見，員工被瑣事佔用的時間卻分散在無數張表格、郵件和會議記錄裡。如果後者能減少一些，部門之間的配合也許會順暢許多。

剛開始，公司只是讓員工使用聊天式 AI 寫郵件、改報告、歸納長文檔。它像一個很有耐心的助手，問什麼答什麼，偶爾出錯，員工看過再用。後來，各部門陸續把一些固定流程接了進來：客服把客戶來信分類並起草回覆，財務讓系統整理對賬差異，採購用它收集報價、歸併相似物料，運維則用它彙總夜間告警和設備運行記錄。以前要等人把資料從幾個地方找齊，工作才能往下走；現在不少材料在員工打開電腦時就已經準備好了。

這種變化最初帶來的確實是輕鬆。客服人員不必在幾十封內容相近的郵件之間反覆複製說明，財務同事不再需要把相同的數字從一張表搬到另一張表，運維工程師早上也不用先讀完一夜的零散告警，才能知道有沒有值得關注的異常。那些新助手既不抱怨流程繁瑣，也不會因為到了下班時間就把任務留到明天。有人半開玩笑地說，公司一下多了一群不用排班、不會請假的同事。

管理層很快看到了效果。一份採購方案可以準備得更早，一次客戶諮詢能夠更快得到初步答覆，財務月末的材料也不再總是堆到最後兩天。部門負責人在會上展示的，不再只是“我們嘗試了 AI”，而是一些具體的變化：過去要等一上午的材料，現在開會之前就齊了；以前因為找不到資料而反覆確認的事情，現在有了整理好的出處。公司於是把更多日常任務交給這些助手，員工也開始習慣先看看機器準備了什麼，再決定自己要做什麼。

不過，工作被提前做好，並不等於工作已經結束。採購部的報告看起來完整，真正決定向哪家供應商下單之前，負責人仍然要確認報價有沒有過期、交貨期是否可靠，以及建議採用的付款條件是否符合公司的要求。財務系統能夠找出一筆賬和另一筆賬不一致，卻不能僅憑“數字對上了”就證明付款應該發生。客服助手寫好一封措辭周到的回覆，遇到退款、賠償或者特殊承諾，員工仍需要判斷那句話能不能代表公司說出去。運維報告把異常列得明明白白，涉及生產系統的變更，工程師仍要弄清楚現在究竟能不能動。

這些核對並不總是簡單的“看一眼”。報價表上的數字可以幾秒鐘排好，確認報價背後的條件卻可能要翻合同、問倉庫、聯繫業務部門；一封回覆幾乎不費時間就能寫成，判斷客戶的要求是否合理，卻需要了解之前的溝通和公司的處理原則。機器擅長把大量材料推到同一個地方，人卻往往必須重新走進材料背後的現實，才能對結果負責。

起初，誰也沒有覺得這是問題。既然 AI 是來幫忙的，重要事情由員工最後檢查，本來就是合理的安排。採購主管甚至很滿意：過去手下的人忙著整理報價，他連想比較幾個方案都不容易；現在各種方案几乎隨時都能拿出來。只是過了一段時間，他注意到自己的待辦列表正在悄悄變長。以前大家準備不出那麼多需要他判斷的事情，如今準備工作快了，等他作決定的事情也跟著多了起來。那些不會下班的新同事，並沒有把工作留在桌上等第二天再做；它們做完一件，又把下一件整整齊齊地送到了人面前。

越來越長的待辦列表

一份材料準備得越充分，往往越能把真正需要人考慮的選擇提前送到桌上。過去忙碌的是收集信息的人，現在忙碌的還有決定怎樣使用信息的人。

真正讓採購主管感到變化的，並不是哪一份報告特別難看懂，而是它們來得越來越密。上午剛確認完一批常用物料的採購建議，下午又送來幾份供應商替換方案。有人在群裡提醒他，前一天的訂單還等著確定數量；財務同事又來問其中一份合同的付款條件，是否已經得到業務部門認可。這些事情過去也有，只是往往要等採購員把資料找齊，才會一件一件來到他面前。現在，準備材料的等待時間縮短了，原來被等待遮住的判斷工作一下露了出來。

有個下午，他準備去倉庫看看一批到貨物料的情況，剛離開座位，手機便接連響了幾次。提醒的語氣都很客氣：一份方案已準備完成，等待確認；一張訂單缺少審核，暫不能進入下一步；另一份比價報告已經更新，建議重新查看。他走到電梯口又折了回來，想先處理最簡單的一件。打開以後才發現，所謂簡單，不過是表格只有一頁。表格上的三個價格很清楚，但其中一家供應商修改了最小採購數量，這可能影響倉庫接下來兩個月的庫存。要判斷這件事，他還得找另一個人聊聊。

他沒有因此認為 AI 不好。恰恰相反，如果沒有這些助手，員工可能還在整理第一頁報價，根本沒機會這麼早發現數量條款的問題。只是他開始明白，一份材料準備得越充分，往往越能把真正需要人考慮的選擇提前送到桌上。過去忙碌的是收集信息的人，現在忙碌的還有決定怎樣使用信息的人。文件夾裡的“待處理”不再只是工作尚未開始的標誌，也可能意味著大部分工作已經完成，只差一個不能隨便代替的判斷。

類似的變化並不只發生在採購部。客服的回覆草稿越寫越快，員工越能集中精力處理少數不那麼標準的問題；這些問題需要查聊天記錄、瞭解客戶以前的承諾，有時還要找到真正負責該訂單的同事。財務人員不再埋頭搬運賬目，卻有更多時間看見那些數字對得上、業務理由卻還需要解釋的交易。運維團隊也從一夜的告警裡更快找到幾項值得注意的變化，只不過發現得早，並不意味著可以不問影響就直接改動正在運行的系統。

每個部門其實都有收穫。最普通、最重複的勞動確實減少了，一部分事項甚至能按照清楚的規則自動完成，無須逐項請人批准。可是當公司把更多任務交給助手時，需要真正理解情況的事項也被更快地篩了出來。公司並不是突然多出了許多本不存在的問題，而是過去必須經過漫長準備才能抵達的那些問題，如今能在同一天裡一齊出現。人們可以處理的時間，卻沒有隨著機器產出速度的變化而變成原來的幾倍。

快，不等於已經完成

那些新同事確實勤奮，也確實讓不少工作變得容易了；只不過它們能夠不停地準備，而他不可能不停地判斷。

公司第一次認真討論這件事，是在一次再普通不過的業務進度會上。會上沒有人抱怨 AI 不夠聰明，也沒有人提出把它們全部停掉。採購部展示了已經完成的報告數量，客服部展示了初步回覆的速度，財務部則說月底整理資料輕鬆了不少。數字很好看，大家也知道這些變化是真的。直到一位負責交付的經理問了一句：“那為什麼有幾件事，資料明明早就齊了，還是拖到今天才定下來？”會議室才安靜了片刻。

原因並不神秘。一批物料的報價上午就整理完了，但採購主管下午才有空核對條款，業務部門又要到第二天才能回覆數量。客戶的問題當天就有了回覆草稿，但涉及特殊處理的那一封，還在等負責人的意見。機器完成的是整個過程中的一段，而客戶、倉庫和其他部門等待的，卻是整件事情真正走到下一步。對他們而言，報告提前兩小時生成固然是好事，若最後仍然要等兩天，感受到的改善就沒有報表裡那麼顯著。

那位經理把白板上的一條流程畫了出來：接到需求，準備資料，判斷，確認，然後再由相關人員完成後續工作。他沒有在圖上寫任何技術名詞，只把幾段時間分別圈了起來。幾個人很快發現，以前最費時間的地方是準備資料，現在那一段縮短了，確認和溝通卻仍舊照原來的節奏發生。工作並沒有憑空消失，只是原來最慢的一環變了。一個部門跑得再快，也沒辦法替整個公司把路跑完。

討論到這裡，財務負責人提出，難道不能讓系統先把容易檢查的事情檢查掉？其實公司早就在這樣做。重複單據、格式錯誤、部分金額差異，都可以由程序按照確定的條件自動提示或攔截；一些小額、規則明確的常規事項，也不必層層上報。問題在於，剩下的那部分審核之所以留下來，往往正是因為不能只比較兩個數字。報價是否合理，還取決於採購時機；一次特殊退款是否妥當，還涉及客戶關係；生產系統的調整即使技術上可行，也需要看業務此刻能否承受影響。

沒有人希望把這些必要的判斷輕率地取消。採購主管說，他寧可一份訂單晚些確定，也不願因為匆忙忽略交貨條件；客服負責人也不希望員工為了讓回覆速度好看，就對客戶作出未經確認的承諾。這些顧慮並非對機器的偏見。即便把工作交給一位經驗不足的新員工，他們也會要求對重要結果再看一眼。區別是，一個新員工一天能遞來多少件需要複核的事，大致有個限度；機器幾乎不會因為忙不過來，就主動把後面的文件留到下週。

會後，公司試著給待確認事項安排優先級，減少意義不大的重複提醒，讓一些已經有成熟檢查規則的流程繼續自動運轉。效果有所改善。採購主管不再被同一份文件反覆打斷，客服也能把真正特殊的申請集中交給負責人。這樣的改進提醒了大家，審核瓶頸不是使用 AI 後註定無法擺脫的命運，好的流程設計、分工與自動檢查仍然很有價值。可是，隨著新業務繼續接入，那些需要根據實際情況作出判斷的事情，還是會源源不斷地來到人的面前。

有時更讓人疲倦的不是待辦數量，而是每項工作看起來都已經完成了九成。資料齊全、格式整齊，連建議理由都寫得頭頭是道。面對這樣一份文件，人很容易產生一種錯覺：最後的確認應該只是舉手之勞。可是真正需要承擔判斷的人知道，自己不能只因為文字流暢、表格漂亮就放心。要確認一個結論，他得弄清楚機器用了什麼資料、遺漏了什麼變化，以及這份建議放進今天的業務環境裡是否仍然合適。機器花幾分鐘寫出的答案，並不會自動把這些問題的答案一併交給他。

老闆漸漸意識到，公司最初問錯了一個並不嚴重、卻越來越重要的問題。他們一直在問：AI 能替員工完成多少工作？這個問題沒有錯，只是不夠完整。更應當關心的是，一件事情從提出需求到真正辦妥，中間還有多少等待、返工、溝通與無法省略的判斷。只算機器生成了多少份材料，就像只統計一家餐館後廚做出了多少道菜，卻不看端到客人桌上的有多少。菜做得更快，當然值得高興；但如果出菜口已經擠滿了盤子，顧客就不一定吃得更早。

那天傍晚，採購主管終於清空了上午留下的幾項待辦。準備關電腦時，他看到新的提醒又彈了出來：明天要討論的一份採購方案，已經完成初步比較。他沒有像剛開始那樣驚喜，也沒有感到被機器冒犯。他只是苦笑了一下，把提醒留到了明天。那些新同事確實勤奮，也確實讓不少工作變得容易了；只不過它們能夠不停地準備，而他不可能不停地判斷。

幾天後，經營者在查看各部門的改進情況時，提出了一個大家原本不願意太早碰的問題：既然機器已經能把如此多的工作準備到最後一步，是否每一步都還必須等一個人親自作決定？這個問題沒有在當場得到答案。有人想到效率，有人想到風險，也有人想到企業多年來怎樣把不同的事情交給不同崗位處理。大家都明白，下一次討論不再只是怎樣讓助手幹得更多，而是要認真考慮：它究竟什麼時候能夠替人作決定。

---

第二章　機器什麼時候才能替我們做決定？

會議結束後，問題還在

如果智能體做出了建議，而人只是在原封不動地點頭，那麼這個點頭究竟幫助公司解決了什麼？

上次進度會結束以後，那句“機器究竟什麼時候能夠替人作決定”並沒有隨著人們離開會議室而消失。經營者起初以為，這只是採購主管抱怨待辦太多時提出的一種設想。過了幾天，他翻看各部門交上來的改進建議，才發現大家不約而同地問起了同一件事。客服希望某些常見問題不必每次等待負責人確認；採購希望對規格明確、重複購買的物料少走幾道請示；運維團隊則問，已經有固定處理辦法的日常異常，是否還要由值班工程師逐個決定下一步。

這些建議不像是員工要把工作推給機器。恰恰因為機器已經幫了很多忙，人們才更容易看見剩下的那一步。客服助手能夠找出適用的售後條款，整理客戶先前的溝通記錄，起草一封得體的回覆。可在一件稍微特殊的申請上，它依然要把所有資料送到員工面前，等人說一句“按這個方案處理”。採購主管遇到的情形也差不多：他有時只需確認一份長期使用的物料仍按慣例採購，有時卻必須花半天核對條款。兩件事情在系統裡都顯示為“待確認”，背後的判斷分量卻截然不同。

經營者把幾個部門的人請到一起，想弄明白這些建議究竟意味著什麼。沒人要求讓 AI 接管公司，也沒人打算把付款、合同或生產系統交給一個未經監督的 AI 智能體（Agent）。大家談的都是很小的事：已經答過許多次的問題，能否不必重複請示？員工過去按照習慣就能處理的普通事務，智能體可不可以也有一點自行判斷的餘地？如果智能體做出了建議，而人只是在原封不動地點頭，那麼這個點頭究竟幫助公司解決了什麼？

採購主管說起自己最近的一次經歷。一個常用物料的訂單，數量、規格和供應商都沒有明顯變化，助手把去年以來的採購記錄和最新報價擺得整整齊齊。他看完後同意繼續向原供應商詢價。整個過程沒有什麼難題，卻因為他當時正在處理另一份合同，直到第二天才點下確認。他知道這件事不值得驚動老闆，也不覺得自己在作什麼了不起的決定，只是按照崗位職責完成了一次普通判斷。如果類似的事情每天出現許多次，他很自然地會想：已經能把依據整理得如此清楚的智能體，能不能替他承擔其中一部分？

這樣的願望並不荒唐。企業讓 AI 進入工作流程，原本就是為了節省時間。倘若機器能夠做完九成準備，而每一項小事都必須等原來那幾個人最後點頭，公司得到的當然仍有好處，卻未必得到它曾期待的那種流暢。人們不是突然不願意承擔責任，而是開始懷疑：判斷一定要按照過去那樣，逐件由同一個崗位的人親自完成嗎？

公司原本就不是靠老闆決定每一件事

說智能體能夠完成複雜任務，與說它已經具備一名成熟員工的全部判斷方式，中間還有一段距離。

這場討論讓經營者想起公司還很小的時候。那時採購數量不多，客戶也有限，許多事情在辦公室裡喊一聲就能找到他。有人想買一臺電腦，他問問用途；客戶提出額外要求，他翻一下往來的郵件，就能給出答覆。那時大家覺得老闆做決定快，因為老闆幾乎知道公司正在發生的所有事情。後來業務多了，他漸漸發現，自己越想把每個決定都握在手裡，員工就越要等他。公司不可能靠一個人的時間長大。

於是，負責人開始被分配到不同部門。採購主管可以在一定範圍內決定常用物料怎樣安排，客服負責人可以處理慣常的售後爭議，運維工程師可以依據職責開展日常維護。重要合同、大額資金安排或影響整個生產的變更，仍需更高層參與。這套辦法並不完美，也常需要調整，但沒有人把它看成公司放棄了管理。恰恰相反，正是因為知道不同事情需要不同經驗與權限，企業才能讓越來越多的人一起工作，而不必把所有問題送到老闆桌上。

經營者在會上講起一位曾經帶過的採購員工。剛入職時，那位員工每遇到一家新供應商都要請主管看一眼；熟悉業務後，同樣的事情他已經能獨立處理。主管並不是某天突然決定完全信任他，而是在一次次合作中知道，他懂得核對哪些條件，遇到不熟悉的情形會主動詢問，也清楚自己負責到哪裡。最後留下的不是“不用管他”這樣一句籠統的話，而是一種雙方都明白的工作分工。

客服負責人接過話說，即使沒有 AI，員工也從來不是每封郵件都請經理簽字。常見問題有標準答覆，簡單的解釋由一線人員處理，碰到金額較大或者涉及特殊承諾的事情才向上請示。公司靠的從來不是“所有事情都讓老闆看過”，而是把日常判斷交給瞭解業務的人，把少見、複雜或後果較重的事情留給更合適的崗位。有些判斷甚至早就由普通軟件按照明確規則完成，例如檢查單據字段是否齊全、攔下重複提交的表單。沒人會因為這些工具沒有逐項請示，就認定公司失去了控制。

既然如此，為什麼輪到 AI，大家又要求它事事停下來等人？這個問題讓會議室裡的氣氛輕鬆了一點。採購主管說，也許大家只是習慣把機器當工具，不習慣讓工具參與判斷。可是話剛說出口，他自己就覺得不夠準確。舊軟件也能作出某種判斷，人員也未必總比機器可靠；區別恐怕不在於會不會叫它“同事”，而在於人們到底知道它能夠判斷什麼、判斷時依據什麼，以及在哪些情形下不應繼續相信它。

還有一個很難忽略的差別：人們願意給成熟員工更多自主空間，並不只因為他過去做對過事情。員工可以被培訓，可以主動解釋自己的顧慮；面對職責不清的任務，他會去找同事商量，也可能因為擔心出錯而暫緩處理。智能體可以依據系統設計提出疑問或請求幫助，但企業不能理所當然地把一個人憑職業經驗、處境和責任意識形成的謹慎，原樣想像到它身上。說智能體能夠完成複雜任務，與說它已經具備一名成熟員工的全部判斷方式，中間還有一段距離。

經營者沒有就此否定放權。他反而更願意認真討論，因為公司原本就靠不斷分配判斷責任來運轉。AI 的出現，不過是讓一個熟悉的問題以新的樣子回來：當一種新的工作參與者有能力處理更多事情，企業應當把多少判斷交給它？過去面對新員工，他們也沒有簡單回答“全部可以”或者“全部不行”。現在或許同樣不能只用一句話回答。

願意交出去的，和不敢交出去的

他第一次如此清楚地發現，自己同時盼望兩件相反的事：希望機器別再事事請示，也希望它不要在自己不放心的時候自作主張。

討論很快從“能不能”變成了“哪一些”。客服負責人隨手舉了兩個例子。第一個客戶只是問普通商品如何查詢物流，答案來自公司已經公開的服務說明；第二個客戶則要求退還一筆金額不小的費用，並聲稱銷售人員曾經作過特別承諾。前一個問題，助手把信息查準、按現有規則答覆，大家普遍覺得沒有必要讓主管再說一次“可以”。到了第二個問題，即使助手已經把記錄整理好，負責人還是希望自己瞭解事實後再作判斷。因為她需要考慮的，不只是一句回覆夠不夠通順，還包括公司是否真的承擔過那項承諾。

採購主管也拿出兩份看起來相似的方案。一份是按既定需求補充常用耗材，供應商、價格範圍和數量都比較穩定；另一份雖然報價更低，卻要求公司一次買進遠超慣常用量的庫存。機器可以把單價和總金額算得很快，也可以指出歷史採購規律，但囤貨是否值得，還要看之後的訂單、現金安排和倉庫空間。第一個判斷或許可以交出去更多，第二個就不能只因為報告把“推薦採購”寫得很漂亮而照辦。

運維工程師說，日常檢查也有這種差別。服務器的運行指標發生一個輕微變化，按照已經驗證過的流程收集日誌、生成工單，與在業務繁忙時改變一套正在使用的生產系統，並不是一回事。前者往往影響有限，做錯了也容易重新檢查；後者則可能牽動正在工作的其他人。即使兩份建議都寫著“建議立即處理”，也不能僅憑字面相同，就把它們放在同一個籃子裡。

財務負責人一直聽得很仔細。輪到她時，她沒有再舉一個更誇張的例子，只問了一句：“如果智能體判斷這筆付款合理，我們是不是就願意照著付？”有人說，要看金額，也要看合同和公司原來的付款安排。有人補充，即使金額不大，收款對象或交易背景發生變化時也不能掉以輕心。大家漸漸發現，自己並非不想讓智能體作決定，而是不願在沒有分清事情輕重之前，籠統地說它可以代替誰。

一名員工提出一個聽起來很誘人的辦法：先挑那些過去很少出錯的事項，讓助手自動給出結論。這個主意得到了一些贊同。畢竟企業已經擁有不少歷史記錄，可以看到哪些判斷重複、結果穩定，哪些情況需要更多經驗。可採購主管提醒大家，過去一百次順利，並不等於第一百零一次的條件不會變化。客服負責人也說，一封平時適用的標準答覆，遇到一位經歷特殊情況的客戶，就可能不再合適。歷史表現值得參考，卻無法替企業提前知道每一個未來情形。

話說到這裡，經營者發現，大家真正擔心的並不總是機器會不會算錯。有時機器給出的方案從數字上看很合理，企業仍可能不願採取。採購一批物料，也許價格最低的方案並非此刻最適合；同意客戶的一項請求，也許能結束當前爭議，卻可能產生公司無法長期承擔的承諾。所謂“決定”，不只是從幾個答案裡挑一個分數最高的。它還意味著有人必須接受這次選擇與企業正在面對的現實有關，而現實不會因為一份報告完成得很漂亮就停下來等人。

員工們也開始說出各自不同的顧慮。採購主管希望擺脫那些明明按慣例就能處理的重複確認，因為它們佔用他看重要合同的時間；財務負責人擔心的是，智能體替人判斷之後，人們可能越來越難說清為什麼當時認為某筆錢可以付；客服負責人則夾在兩者中間，她既希望客戶更快得到答覆，也知道有些話一旦以公司的名義說出，後來就不是簡單撤回一封郵件那麼容易。

這又把問題帶回了經營者面前。他發現自己無法再簡單地要求員工“相信 AI”，也不能用“重要事情一律由人決定”結束討論。前一句話太輕率，後一句話雖然聽起來穩妥，卻沒有解釋什麼叫重要，更沒有讓公司繼續得到自動化本來可能帶來的好處。人們一直在試圖找到某種分寸：讓智能體承擔適合它的日常判斷，把那些必須結合更多業務情況、可能帶來較大影響的選擇留給人。這樣的分寸不可能只靠一次會議就被說清楚。

會議快結束時，有人問，是不是可以先從極少數常規事項試著做起。經營者沒有當場批准，也沒有否決。他要求大家先把各自真正希望減少的人工判斷說清楚，再想想為什麼這些事情過去由人負責。至少在這一步，大家願意承認，智能體能作出建議，不等於公司已經準備好接受它的每一次決定；讓智能體承擔部分判斷，也不意味著企業可以把後果一併交出去。

走出會議室時，採購主管看了一眼手機。幾項普通採購確認還在等他，另一份比較複雜的合同也排在後面。他希望有一天自己不用再為所有瑣碎事項點頭，好騰出時間真正研究那些值得他花時間的問題。但當他想到那份複雜合同，又覺得幸好今天還沒有誰宣佈所有判斷都可以自動完成。他第一次如此清楚地發現，自己同時盼望兩件相反的事：希望機器別再事事請示，也希望它不要在自己不放心的時候自作主張。

公司的討論暫時停在這裡。沒有人發現一套能立即解決所有問題的辦法，也沒有人要求把 AI 退回只會整理文件的位置。大家已經開始認真考慮，把一部分決定交給這些不會疲倦的新同事。只是還有個問題沒有人能替他們回答：即便智能體沒有惡意，甚至每次都認真按照它理解的任務去做，它仍然可能像一個經驗不足卻十分勤奮的員工那樣，作出讓企業後悔的決定嗎？

---

第三章　一個沒有惡意的“內鬼”

那些終於不用等待的決定

信任往往不是在一次鄭重其事的表態裡形成的，而是在許多個無需操心的下午裡慢慢長出來的。

那場討論之後，經營者並沒有馬上把更多工作交給智能體。他讓幾個部門各自挑出最熟悉、變化最少的日常事務，說明過去由誰判斷、出了問題又會影響什麼。採購部列出常用耗材的補貨，客服部選了幾類有明確處理辦法的小額售後申請，運維團隊則挑出不涉及生產系統改動的日常維護。清單被來回劃改了好幾次，最後留下的項目比大家最初想像的少得多。

採購主管原本想把常見物料的詢價、比價和下單都交出去，寫到一半又刪掉了“所有供應商”。有些供應商常年合作，規格和交貨方式很穩定；有些只是偶爾報價，條件每次都不同。他最後同意讓助手在一小部分重複採購中選擇已經合作過的供貨方，並在約定的金額範圍內，通過公司現有采購流程發出訂單。涉及大額採購、特殊合同和付款的環節仍由相應崗位處理。智能體獲得的不是“以後採購都由你管”的一句話，而是一小塊經過商量的工作。

試行開始的第一週，事情順利得讓人有些不習慣。倉庫報出一批包裝耗材快用完了，採購助手查找過去的訂單和庫存需求，按照慣常數量補了一單。採購主管直到下班前才在當天的記錄裡看到這件事。貨物按時送到，價格沒有異常，倉庫也沒有再催促。若按過去的辦法，助手先準備好一份建議，他還得從別的工作中抽出時間確認；這一次，那件普通的小事已經辦妥了。

客服負責人也感受到一點變化。幾筆條件明確的小額退款不再排進等待人工答覆的隊列，客戶更快得到了處理結果。對真正有爭議的申請，員工仍然照常核對。運維工程師則發現，過去要反覆點開的日常檢查工單有些已經按既定方式處理完畢，值班記錄反而更清楚了。公司沒有因此省掉全部審核，也談不上讓機器接管經營，但原來總被瑣碎確認打斷的人，終於有了一段可以安心處理複雜工作的時間。

採購主管尤其高興。他拿著一份拖了許久的合同坐進小會議室，一口氣看完了好幾頁過去沒時間細讀的條款。那天下午，沒有任何補貨提醒把他從合同裡叫出來。他甚至想，或許自己之前太謹慎了：只要事情足夠熟悉，為什麼一定要讓機器停在最後一步？當晚彙總裡寫著幾個簡單的字——“本日常規訂單已完成”。這種平靜，正是公司當初引入 AI 想得到的東西。

接下來的日子裡，類似的順利越來越多。員工不再因為每張小訂單打斷主管，主管也逐漸不再逐項回看所有記錄。偶爾有人問助手為什麼選了某家供應商，系統能夠列出歷史價格、交貨情況和需求數量，解釋看上去有理有據。人們便更願意把精力放到例外事項上。信任往往不是在一次鄭重其事的表態裡形成的，而是在許多個無需操心的下午裡慢慢長出來的。

報價單裡沒有寫出的變化

只是那份依據缺少了一件當時很重要的事情：現實已經向前走了，而它所理解的現實還停在上一份文件裡。

真正的麻煩出現在一次再平常不過的補貨中。倉庫需要一批常用的包裝材料，數量不大，也沒有超出試行範圍。採購助手像往常一樣查找已有報價和過去的交貨記錄，在兩家長期合作的供應商之間作了比較。它選中了價格較低、以往交貨也穩定的那一家，並按約定流程發出了訂單。對於系統當時能夠取得的資料，這個選擇並不顯得奇怪。

問題在於，助手拿來比較的價格表，是上個月保存到共享文件夾裡的版本。文件上列著清楚的規格、單價和聯繫人，卻沒有保證這些價格在本月仍然有效。供應商幾天前已向採購部門發送過新的報價說明，其中一項材料的價格有所上調，交貨週期也變長了。那封郵件還停留在一名員工的工作郵箱裡，沒有進入助手查詢的資料範圍。智能體沒有偽造報價，也沒有偷偷選擇陌生公司；它只是把能夠查到的上一份價格，當成了眼前仍可採用的條件。

第二天上午，供應商回覆訂單，說舊價格已經不能接單，最近的產線安排也無法保證原定交貨日。如果公司願意接受新報價，可以重新確認；若趕時間，最好另想辦法。收到回覆的採購員工起初並不緊張，畢竟修改訂單在日常業務裡並不罕見。他給主管發了條消息，請他看一下。直到倉庫提醒，有一批客戶需要的包裝材料正等著這次補貨，他才發現原本普通的訂單已經碰上了不普通的時間。

採購主管打開記錄時，第一反應不是責怪機器，而是問：“為什麼會選這家？”助手給出的依據很完整：以往多次合作、歷史供貨穩定、報價比另一家低。單獨看每一條，都能找到來源。採購主管順著鏈接翻開那份價格表，看見保存時間時，心裡忽然一沉。他又去翻同事轉來的新報價郵件，發現價格變化本來就在採購部門內部發生過，只是沒有被帶進這一次判斷使用的資料裡。

“它沒亂算。”他對同事說。對方點點頭，又問：“可這單怎麼處理？”這句追問比“機器到底有沒有算錯”更實際。公司得趕緊聯繫另一家供應商，確認能否提前送貨；原訂單需要取消或重新協商，倉庫也要調整備料時間。最後他們買到了材料，卻為加急運輸多付了一筆費用，幾個員工還臨時調換了工作安排。損失談不上讓企業傷筋動骨，但錢實實在在花出去了，時間也實實在在被佔用了。

這次錯誤尤其令人彆扭，因為誰也找不到一個像樣的“壞人”。供應商沒有故意刁難，員工沒有指示智能體去做一件明顯錯誤的事，助手也沒有逃避自己的任務。它依照公司交給它的工作，在已經允許的範圍內作出選擇，甚至留下了可供查看的依據。只是那份依據缺少了一件當時很重要的事情：現實已經向前走了，而它所理解的現實還停在上一份文件裡。

採購主管後來想，如果換成一名剛入職的採購員，大概也可能發生同樣的事。新人看見價格表，確認供應商在名單裡，又發現以往合作順利，便照著舊辦法發出訂單。經驗豐富的同事也許會提醒他，價格表放了一個月，最好問一聲有沒有變動；但這不意味著每位老員工都會記得，更不意味著人的判斷一定更準確。問題不在於機器犯了一種人類絕對不會犯的錯，而在於公司原本憑習慣、口頭提醒和零散郵件維持的那部分認識，沒有隨著工作交接一同到達新的判斷者手裡。

經營者聽完經過，沒有立刻要求停掉試行。他先問了三個問題：這件事給公司造成了什麼影響？當時的決定依據是什麼？如果換一個員工按同樣的材料辦事，我們又會怎樣看待？當人們不急著給錯誤尋找一個單獨的承擔者，事情反而清楚起來。智能體的判斷確實出了問題，供應商報價更新的傳遞也有缺口，而讓這類小訂單無需逐項人工確認，是公司經過討論作出的安排。它們共同構成了這次結果，誰也不能只用一句“AI 不可靠”來概括。

同一段時間裡，客服部門也發現了一件較小的麻煩。一位客戶的留言裡既提到了退貨，又提到之前客服答應補發配件；助手把它歸入了常規退款，給出了符合一般退貨流程的處理結果。客戶再次聯繫時，員工才知道對方真正希望解決的是那次補發承諾。事情最終通過人工溝通補救，沒有演變成嚴重糾紛，卻讓客服負責人意識到，文字被歸進一個熟悉類別，並不代表客戶的真實處境就一定被理解了。運維團隊則在一次例行維護建議中發現，助手沒有注意到業務部門臨時調整的使用時段；好在涉及生產調整的操作仍按原有流程等待工程師確認，建議被及時修改，沒有造成停機。

這兩件事沒有被經營者當成又一輪“機器出事”的證據展覽。它們涉及不同部門，後果也不同，卻有一個值得注意的相似處：事情越接近過去的慣例，工作人員越容易覺得不必再問；而現實恰恰可能在那些沒人特別留意的地方發生變化。有時新信息根本沒有進入資料庫，有時信息就在眼前，卻被錯誤地歸入某個熟悉類別，還有時規則本身是正確的，只是沒有覆蓋當天遇到的特殊情況。把原因都歸給模型聰明不聰明，反而會漏掉許多本可以看見的組織問題。

信任之後，誰還記得多問一句

複雜任務做得好，簡單任務未必永遠不會錯；做對過許多次，也不能使下一次決定自動變成正確。對員工如此，對機器同樣如此。

採購主管那幾天常想起自己帶過的一位年輕同事。那人剛來時做事認真，整理報價尤其細緻，有一次甚至主動發現了合同裡一處容易被忽略的運費差異。後來主管放心讓他獨立處理常規採購，卻在某次盤點前發現，對方按過去的消耗量多訂了一批材料。年輕人並不是偷懶，只是沒有注意到生產計劃已經調整。主管當時花了不少時間教他：熟悉的事情也要看一眼現在的情況，不能因為上個月這樣做過，這個月就照著做。

現在，類似的提醒需要用另一種方式重新表達。對人，主管可以問他有沒有收到倉庫的消息，可以觀察他是否理解問題，也可以在他猶豫時聽出不確定。對機器，企業可以改進輸入資料、調整工作範圍，讓它在遇到不清楚的條件時停下來詢問，還能通過測試發現某些薄弱環節。但人類員工會因為一次批評而記住難堪、因為對同事的瞭解而多問一句，這些心理活動不能直接當成機器也會自然擁有的能力。機器能改進，改進卻必須有實際依據和安排，不能寄望於它自己產生一種與人完全相同的謹慎。

更微妙的是，之前那些順利完成的訂單並非毫無意義。它們證明試行在許多正常情形下確實有用，也解釋了為什麼員工願意讓機器承擔更多工作。可成功累積起來，還會改變人們看待風險的方式。最初，採購主管每天都會打開記錄，看看助手選了誰、價格是多少；幾周之後，他通常只在出現提醒時才去翻。人不可能在每件小事上始終保持第一次嘗試時的警惕，否則有限放權帶來的輕鬆也就無從談起。恰恰是這份合理的信任，讓遺漏更容易在沒有明顯動靜的時候留存下來。

公司有人提議，把那家供應商的最新報價補進去，類似的事情以後就不會再發生。採購主管同意先補資料，卻不願把後半句話說得太滿。這次是供應商變了價格，下次也許是倉庫臨時調整需求，或者客戶提前交貨的安排改變了優先順序。修正已經發現的錯誤很重要，但修改一個文件，不等於未來所有相關信息都會及時、完整地到達。人會遺漏，機器也會依據不完整的資料作出判斷；而機器還可能在很短時間裡，對許多相似事務重複同一種誤解。

財務負責人聽到這裡，提醒大家幸虧這次沒有讓助手自行完成付款。採購主管並不同意把它簡單理解成“有個人最後管錢，所以就沒事”。訂單已經發出，重新採購和加急運輸也已經產生了成本；即便付款環節仍由人負責，前面作出的業務選擇也可能帶來後果。另一方面，保留付款審核的確避免了把錯誤進一步帶進資金處理。這次經歷既說明原有分工並非毫無價值，也說明一件事情往往在走到最後一步之前，就已經開始影響現實。

經營者想到“內鬼”這個有些刺耳的詞。過去公司一談內部風險，常會先想到有人故意隱瞞、違規操作，或利用手中的便利損害企業利益。採購助手顯然不是這樣。它沒有私人利益，沒有報復心理，也不需要編造一個傷害公司的動機。可是從結果看，錯誤偏偏發生在企業內部、發生在企業允許它參與的日常流程裡，最終仍由員工、客戶和公司承擔影響。把這樣的機器叫作“內鬼”，如果只是提醒人們內部信任也可能帶來風險，尚能理解；若把它當成有意作惡的指控，就完全說錯了對象。

真正讓經營者難以釋懷的，是這次出問題的並不是一道驚險的技術難題。助手沒有去破解系統，也沒有處理從未見過的鉅額合同，只是選擇一家常用供應商，完成一件看起來足夠普通的補貨。複雜任務做得好，簡單任務未必永遠不會錯；做對過許多次，也不能使下一次決定自動變成正確。對員工如此，對機器同樣如此。企業原本寄希望於讓助手越做越熟練，現在不得不接受一個不大舒服的事實：熟練和可靠有關，卻不是同一回事。

幾位負責人在走廊裡又談起要不要暫停試行。採購主管不願意一停了之，因為他記得那些被釋放出來的下午，也知道同事確實少做了許多機械的重複工作。客服負責人擔心，如果一齣問題就收回所有自主空間，原先堆在人工隊列裡的事項很快又會回來。可誰也沒有足夠的底氣說，只要更新了報價、補充了幾條說明，就可以繼續放心地把越來越多的決定交出去。兩邊都有可以理解的理由，也都不能單獨讓另一邊消失。

那天傍晚，經營者翻看試行記錄，看見大多數任務已經順利完成，出問題的幾件則被單獨標註了處理經過。報表沒有說謊：效率確實提高了，員工也確實輕鬆過；那筆額外運費同樣沒有說謊，錯誤已經進入了公司的經營賬本。他終於明白，自己需要面對的不是一群一無是處的機器，更不是一群存心作惡的新同事，而是一批已經相當能幹、卻仍可能在某個具體時刻判斷失誤的工作參與者。

公司沒有在那天作出最終決定。有人建議先把關鍵事情重新交給人確認，也有人希望保留試行，再尋找更穩妥的辦法。經營者讓大家把經過和顧慮都整理出來，約定下次再討論。辦公室裡，採購助手依舊在準備明天的補貨建議，客服助手也還在處理普通諮詢。它們沒有因為這次失誤停止工作；人卻不得不重新思考，究竟該讓它們走到哪一步。若讓人重新檢查每個判斷，最初那種等待審批的情形也許又會回來；若繼續放權，誰又能保證下一次看似普通的決定不會出錯？

---

第四章　一天要檢查多少次“可以”

把決定重新交給人

可是這份安心有一個不易察覺的前提：送來的事情不能太多，而且負責查看的人真的有時間去看。

那場討論幾天後終於有了一個暫時的結果。經營者把採購主管、財務和客服負責人，以及負責生產系統的運維工程師叫到一起，沒有再問機器到底靠不靠譜。他讓每個人說說，試行期間哪些事情確實做得更快，又有哪些事情一旦判斷錯了，部門就得花費更多時間補救。採購主管提起那份過期報價，財務負責人翻出為趕上交貨而增加的運輸費用，客服負責人則說起那個把補發配件誤當作普通退款的申請。大家說的都是已經處理過的事，沒有誰把它們誇大成公司遭遇了什麼危機。

經營者最後說，試行不能因為幾次失誤就全盤否定，但也不能因為大多數事情做對了，就對剩下的風險視而不見。眼下先把幾類容易受現實條件變化影響的事務收回來：供應商報價有更新或訂單條件發生變化的採購，需要主管確認；涉及特殊退款和承諾的客服處理，仍由員工判斷；牽涉生產系統狀態改變的操作，繼續沿用原有審批流程。那些格式檢查、資料整理和規則明確的日常事務則不必一律退回人工。公司沒有宣佈“從今以後機器做的事都要人簽字”，但確實重新把一些原本嘗試交出去的決定，放回了人的桌面。

這項決定得到的支持比經營者預想的多。採購主管雖然捨不得此前省下的時間，卻知道如果那份新報價有人提前核對，加急運費很可能就不必發生。財務負責人尤其贊成把條件發生變化的事項重新送審，因為付款之前看一眼金額，與採購時就弄清楚價格和交貨安排，是兩種不同的把關。運維工程師也覺得放心：機器仍可準備處理建議，而決定是否在當前時段調整生產系統，至少不會因為一條看似普通的提醒就被匆匆帶過去。

新安排實施的頭幾天，大家確實感到安心。待辦事項多了一些，管理人員卻能知道有哪些事情在等待自己。採購主管收到一份提示，說某種物料的報價有效期已過。他沒有馬上批准，而是讓員工聯繫供應商確認。新報價很快補齊，那份訂單第二天順利發出。公司既沒有發生什麼損失，也沒人專門表揚這次審核，但採購主管心裡很踏實。他想，審批這種老辦法之所以用了這麼多年，正是因為有些決定值得在發生之前停一下，讓瞭解業務的人認真看看。

可是這份安心有一個不易察覺的前提：送來的事情不能太多，而且負責查看的人真的有時間去看。新的流程剛運行時，大家還有餘力把每份報告打開、把原始材料翻出來。隨著其他業務部門不斷把更多工作交給助手，這種餘力慢慢變得緊張。過去要花半天準備的方案，現在上午可以生成好幾份；機器遇到不確定之處也不必苦等，它會很勤快地把問題標出來，交給被指定的審核人。一個個等待確認的事項看上去都有了明確去處，只是它們到達的速度，並不在意去處的那個人今天有沒有別的事要做。

尤其到了星期五下午，這種不同的節奏就顯得很具體。採購主管打算把本週的例行確認處理完再下班，臨走前卻發現又有幾份材料剛生成。它們有的關係到下週一要用的物料，有的只是提前準備好的備選方案，提醒聲音聽起來卻差不多。假如全部留下，週一可能有人因為等不到回覆而停工；假如全部現在看完，他就得取消原本安排好的工作。機器提前完成了自己的部分，本應讓人更從容，卻也使人更早面對哪些事情不能再等的判斷。

一張整齊的表，和它背後的現實

機器幾分鐘就能準備出的東西，未必能由人在同樣短的時間裡核實。

某個星期三，採購主管坐下來準備核對一份新合同，手機裡接連出現了幾次提示。他先打開最短的一份補貨建議。頁面上方寫著“建議通過”，理由依次列著歷史合作穩定、報價在允許範圍內、庫存接近補貨點，附件也整齊地排好了。他本能地想先點確認，把這件小事從列表裡劃掉。可剛才那次過期報價仍讓他不舒服，於是又往下翻了幾頁，才發現庫存數字來自前一天的記錄，倉庫當天上午剛臨時調整過領料計劃。

這一次並沒有釀成什麼錯誤。他打電話給倉庫，確認數量，把建議退回修改，前後用去一段本該看合同的時間。等電話掛斷，新的待審事項又添了兩件。他望著那張很漂亮的表格，忽然覺得“審核”這兩個字被系統界面寫得太輕了。報告已經把理由歸納好了，結論也看著順眼，但若要判斷它在今天是否仍然成立，他還是得向表格之外的人打聽。機器幾分鐘就能準備出的東西，未必能由人在同樣短的時間裡核實。

客服部門也遇到類似的處境。助手可以把來信、歷史記錄、售後條款和建議回覆放在同一屏幕上，對許多普通問題，這已經足夠讓員工快速處理。可碰到涉及特殊承諾的申請，負責人必須知道客戶此前到底與誰溝通過、那句話是否屬於正式答覆，以及如今的處理會不會讓客戶產生新的期待。有一次，界面摘要寫著“客戶要求額外退款”，她翻開原始往來才發現，客戶真正介意的並不是錢，而是之前答應補發的東西遲遲沒有寄出。摘要不能說完全錯誤，卻把最該先解決的部分擠到了後面。

她把那項申請退回，要求員工先核實補發進度。此後她開始習慣每次都多看幾條原始記錄。習慣是好事，時間卻是有限的。午飯前，幾份例外申請在隊列裡等著；吃完飯，一位員工來找她討論一宗真正複雜的投訴，她剛坐下，又看到提醒說有幾項待審事項即將超過內部處理時限。系統沒有催促她不負責任地簽字，它只是忠實地告訴她，還有一些工作沒有走到下一步。可每一條提醒背後，都有同事和客戶在等待。

財務負責人倒不太贊成把所有問題都看成新出現的。她說，以前沒有 AI 時，財務也常常面對材料齊全卻說明不了全部情況的申請。發票、合同、付款計劃能夠相互對應，並不保證交易在此刻仍符合公司的安排。過去要核對，現在仍然要核對；人的判斷從來沒有因為多了簽字這一環就自動變得正確。區別是，以前業務部門準備不出那麼多申請，財務總有一段可以追問的時間。現在資料整理的速度快了，核對過程中真正費時的那些電話、解釋和等待，一點也沒有按相同比例減少。

有一份付款申請便卡在這種等待裡。採購部門認為材料已經齊備，財務看到合同條款卻想確認貨物是否全部驗收，倉庫又說有一批尚在途中的貨需要採購解釋。助手替三個部門整理了往來記錄，甚至列出各自尚待回答的問題，可它不能替倉庫證明貨已收到，也不能替採購主管確認一項尚未完成的交付。財務負責人面對那份整理得很好的摘要，只能先選擇暫緩。這樣的暫緩不是效率低下的證據，而是必要信息還沒有到齊；只是對系統而言，另一項等待簽字的任務又多佔了一格。

那天傍晚，採購主管回頭整理工作記錄，發現自己批過的事項裡，既有幾秒鐘便可確定的普通事務，也有需要查合同、看庫存和詢問業務部門才能判斷的事情。它們在同一張列表裡，佔據相同寬度的一行；完成後，都留下一個綠色的“已通過”。這並不是系統出錯，而是系統只記錄了一件事情的處理狀態，並不知道人究竟花了多少心思。採購主管忽然想，如果明天別人只看這張表，大概會以為每個綠色標記背後都是一次同樣充分的檢查。

真正讓人疲憊的，還不只是事項數量。人在連續查看許多相似材料之後，很容易憑熟悉的樣子判斷下一份。開頭幾份他會仔細找日期、核對來源、問問有沒有變化；到下午，看見同一種版式、同一套理由，眼睛往往先落到機器寫出的建議結論上。若結論與往常一致，他就更需要提醒自己別把“看著沒問題”當作“已經核實過”。這不是某個人特別懶惰，而是當許多判斷被壓縮進一個下午時，人的注意力會被消耗，連保持謹慎本身都變成了一項工作。

點擊同意以後

但真正有效的把關，既要有適當的人，也要有這個人能夠使用的信息，還要留給他足以思考的時間。把一個人的名字寫進流程，並不會使這些條件自動出現。

月底的業務會上，經營者讓幾位負責人各自說說新審批流程的效果。採購部報告說，涉及價格變化的訂單得到及時提醒；客服說，一些有爭議的答覆在發出前被改得更妥當；運維也表示，涉及生產環境的操作仍然有人依據實際運行安排把關。沒有人否認這些好處。如果把人工審核全部看成拖慢工作的舊習慣，這些在錯誤發生前被發現的問題就無從解釋。

可是會議繼續往下開，另一組事實也擺了出來。幾位負責人原本打算處理的重要工作，常因待審事項被不斷打斷；部分申請由於需要跨部門確認，依然在隊列裡停留很久；一些並不複雜的事務，經過幾輪通知才等到有人點下同意。為了縮短等待，部門開始給系統摘要加上醒目的建議結論，審核人也學會先找最重要的幾個字段。這樣做有時確實提高了效率，卻也讓他們越來越依賴材料是怎樣被整理出來的。人仍然擁有說“不”的機會，但若不知道應該對什麼說“不”，那個機會便未必總能發揮作用。

有個採購員工說出了另一個細節：在系統裡點“同意”，只需要填寫很少的內容；選擇退回，則往往要解釋理由，通知申請人，有時還得重新約定處理時間。這個區別本身並不奇怪，退回本來就需要讓別人知道該改什麼。可在一天連續面對許多文件的時候，最省事的選擇與最有根據的選擇可能不再重合。員工當然不能因為趕時間就隨意通過；問題是，流程並不會自動替疲憊的人抵抗這種誘惑，反而可能讓他每次都要額外拿出一分精力。

經營者隨手打開一條已經完成的審批記錄。上面寫著申請內容、提交時間、批准人和通過時間，清清楚楚。他問採購主管：“如果過一段時間需要復盤，我們至少能知道誰同意了，對不對？”主管回答可以。經營者又問：“那能不能從這裡看出，他當時是否讀過原始報價、是否知道倉庫後來改了計劃？”主管看了一眼屏幕，說記錄本身看不出來，得去找當時的附件和溝通記錄；即便都找到了，也未必能證明一個人當時真正理解了多少。

他們並沒有因此覺得審批記錄無用。能夠知道誰在什麼時間作了決定，本來就是管理的一部分。有人簽字，意味著有人在履行被交付的崗位職責，也讓事後核查有了線索。問題只在於，記錄能準確證明的東西，比人們習慣從記錄裡想像的少一些。它能告訴公司“這件事經過同意”，卻不能僅憑一個名字和一個時間，就證明相關信息已經被充分閱讀、重要條件已被核實，更不能保證結論一定正確。公司想要的安心，有一部分來自記錄的清晰；真正的判斷質量，卻仍藏在看不見的過程裡。

採購主管想起前幾天的一件小事。那時他正準備接一通供應商電話，屏幕上跳出一份日常採購的確認請求。他掃過摘要，發現物料和金額都在熟悉的範圍內，手已經移到同意按鈕附近，卻又想起這份建議是否需要查看新庫存。於是他把界面暫時關掉，接完電話再找倉庫核對。結果證明建議本身沒有問題。如果當時順手點了同意，最後也許會得到完全相同的業務結果，記錄上同樣留下他的名字。不同的是，只有他自己知道，那兩次決定所依據的檢查並不一樣。

他又想到，真正值得自己花時間的那份合同，這些天一直被切成零碎的十幾分鍾。每次回到桌前，他都得重新想起上次看到哪裡、哪些條款還沒問清楚。審核提示從來沒有強迫他放下合同，卻在不斷提醒他，別人的工作還在等他的回應。一個組織完全可以合理地要求重要事項接受人工審查，同時也必須承認：審核人為了騰出注意力所付出的代價，會出現在他被迫放下的其他工作裡。把這些代價藏到審批按鈕背後，不能使它們消失。

這件沒有造成損失的小事反倒讓他有點害怕。管理制度不能靠猜測某個人點按鈕時是否認真，也不能要求所有人時時刻刻保持最高程度的注意力。人不是專門為確認機器輸出而存在的按鈕，更有合同要談、客戶要見、倉庫要跑、同事的問題要解決。讓人去審核真正需要經驗和判斷的事情，是對人的能力的尊重；把許多本不該交給同一個人、又很難認真看完的事項不斷塞給他，未必就叫作加強監督。

經營者意識到，他原本把問題理解得過於簡單了。機器出錯，於是增加人工審批；審批留痕，於是覺得心裡有底。但真正有效的把關，既要有適當的人，也要有這個人能夠使用的信息，還要留給他足以思考的時間。把一個人的名字寫進流程，並不會使這些條件自動出現。當然，有些重大或異常的事情就值得多花時間，必要時寧可延緩，也不能草率放行；但若所有不同分量的事項都擠在同一個入口，有限的時間便可能被許多不太需要它的事情耗盡。

公司於是討論怎樣把待審事項重新分開。哪些可以繼續由明確規則檢查，哪些應當交給熟悉客戶情況的人，哪些需要採購和財務一起核對，涉及生產環境的事情又該由誰結合實際運行狀態判斷？這些問題沒有在會上得到最終答案。採購主管擔心把隊列拆散後，有些跨部門的信息更難湊齊；財務負責人則認為，至少不能把所有付款相關事項都說成只需核對數字；運維工程師也提醒大家，他能看懂系統狀態，卻不可能總知道業務部門臨時作了什麼安排。

會議結束時，經營者沒有再要求大家把“審批通過率”做得漂亮一些。他只說，既然有些事情必須由人看，那就先弄明白應該由什麼樣的人看、給他看什麼，以及他怎樣才看得過來。採購主管聽到這裡，想到自己的待辦列表可能終於有機會縮短，又隱約覺得一個更難回答的問題正在出現：當檢查任務分到各個崗位，誰應當為檢查結果負責？如果一個人連完成充分檢查所需的時間和信息都沒有，企業又該怎樣理解他簽下的那個“可以”？

---

第五章　誰來檢查，誰來負責？

每件事終於有了負責人

他可以判斷操作會不會讓服務短暫中斷，卻不能替使用系統的人決定這段中斷是否可以接受。

那次業務會過後，辦公室裡最先發生變化的，是待辦頁面上的一列名字。過去，採購、財務、客服和運維的審核事項經常堆在幾個主管的列表裡，誰有空就先看一眼，遇到跨部門的問題再轉給別人。現在，每一種事項都有了默認的接收崗位：常規採購歸採購部，付款依據歸財務部，特殊售後歸客服負責人，涉及系統運行的建議歸運維人員。經營者希望，至少不要再讓一份材料在幾個人的郵箱之間來回轉，卻始終說不清究竟在等誰。

安排出來的第一個早晨，採購主管覺得輕鬆了一些。他打開系統，發現幾份付款相關的材料不再和採購建議混在一起，真正需要他確認的報價變化被放到了前面。一名採購員工接手了日常補貨的複核，倉庫那邊也有了固定聯繫人。先前為了找到一份訂單該找誰，員工要在群裡問上幾輪；如今頁面上能直接看到名字。對一家人手並不寬裕的企業來說，事情有了去處，已經是一個看得見的改善。

但名字寫得清楚，並不等於工作就按部門的邊界整整齊齊地分開了。那天下午，採購員工接到一份助手整理好的補貨建議，供應商報價是最新的，採購數量也落在約定範圍內。可他注意到，需求表寫的是下週必須到貨，而倉庫記錄裡沒有說明這批材料為什麼突然提前使用。他去問倉庫，倉庫說是業務部門調整了交付順序；他再問業務部門，對方說具體日期還在等客戶確認。建議沒有明顯算錯，訂單也不算大，採購員工卻無法回答最簡單的一個問題：現在下單，到底是不是公司真正需要的安排？

系統上標著“採購審核人”，催辦提醒也發給他。他能夠核對供應商、價格和通常的採購條件，卻不掌握客戶交付計劃；他可以退回建議，卻沒有資格替業務部門確定需求。於是他把問題轉給主管，主管又去找負責交付的經理。過了一圈，單子終於停在“等待業務確認”。採購員工看著自己名字旁邊那行紅色的逾期提示，覺得有些委屈。他並不是不肯看，也沒有故意拖延，只是有些答案根本不在自己的崗位上。

財務部門的情況更微妙。過去，付款申請送來時，財務人員就會核對合同、驗收材料和金額；如今 AI 能更快整理這些東西，也能找出其中的數字差異。分工調整以後，系統把“付款審核”明確派給財務員工，大家希望藉此減少申請在不同負責人之間等待的時間。有一份材料裡，合同金額、收款信息和賬目都對應得上，附上的說明卻寫著“相關交付已按計劃完成”。財務員工翻遍附件，只找到業務部門提交的進度摘要，沒有找到能夠確認交付情況的原始憑據。

她把申請退回去，請業務部門補充。申請人有些不解：“機器不是已經把材料都對過了嗎？你還要我們確認什麼？”她只能解釋，數字一致不等於事情已經發生；財務可以核查付款依據是否齊全，卻不能坐在辦公室裡憑一段文字判斷倉庫究竟收到了什麼。後來業務部門補上了必要材料，申請才繼續往前走。整個過程沒有產生損失，卻讓她發現，分配給自己的一項“審核任務”，可能包含幾項必須由不同崗位分別確認的事實。

運維工程師也遇到了差不多的情形。助手列出一項例行維護建議，技術上沒有特別複雜的地方；按以往經驗，安排在夜間處理就能減少對正常工作的影響。但他知道近期有些訂單需要趕工，生產部門的使用時段未必還按舊日程執行。他可以判斷操作會不會讓服務短暫中斷，卻不能替使用系統的人決定這段中斷是否可以接受。對方催問為什麼不盡快批准時，他回答：“我能告訴你它技術上怎麼做，不能替你說今晚停這幾分鐘沒有關係。”

工作重新分配之後，審核並沒有消失，只是從少數主管的桌上，移到了更多普通員工面前。有人獲得了更清楚的職責，也有人第一次在系統上看到自己的名字與一項自己無法獨立判斷的結果緊緊挨在一起。大家尚能接受這些麻煩，畢竟每個部門都有自己的工作範圍。真正讓氣氛發生變化的，是一份新發下來的內部說明。

“誰審核，誰負責”

幾位負責人漸漸發現，員工真正抗拒的，往往不是正常的崗位責任，而是一種沒有說清範圍的責任。

說明只有幾段話，主要是提醒各部門按職責認真核驗 AI 助手提交的工作結果，不要把機器的建議當成已經得到確認的事實。其中一句話寫得尤其醒目：“誰審核，誰負責。”寫這句話的人大概是想強調，審批不能流於形式，不能讓員工看見機器整理好的結論就隨手放行。採購主管讀完沒有反對；在企業裡工作多年，他也一直相信，簽過字的人至少應該說得清自己檢查了什麼。

可這句話轉到員工群裡以後，得到的反應不太一樣。有采購員工問，自己只負責核對報價，是不是連業務部門後來修改的交貨需求也要一併負責？財務員工問，系統把一份付款申請派到自己的列表裡，如果業務部門提供的驗收說明有誤，她怎麼能保證自己知道全部情況？運維工程師問得更直接：如果已經提醒業務部門某項維護可能影響生產，對方仍然堅持安排，最後結果不理想，究竟算誰沒檢查好？

這些疑問並不是同一時間爆發的。最初，大家只在午飯時抱怨幾句，或者在群裡留下一條不大客氣的回覆。後來有名採購員工遇到一份急單，連續給業務部門發了兩次確認消息，仍然沒有得到明確答覆。傍晚，催辦電話打到了採購主管那裡，說訂單不能再拖。主管找到員工，問為什麼還沒處理。員工把自己的查詢記錄翻出來，指著其中一條說：“如果你讓我只看報價，我現在就能籤；如果你讓我保證這單訂得對，我得先知道他們到底什麼時候用。這個事情我問不到，你讓我怎麼負責？”

採購主管沒有當場批評他。他知道對方並非毫無經驗的新手，平時也願意擔事。如果要求員工為了趕時間跳過詢問，出了問題再說“你已經簽字”，確實說不過去。但他也有自己的難處。倉庫和業務部門都在等採購結果，主管不可能每次都親自接過員工拿不準的事情。更不能因為一份材料牽涉多個部門，最後就沒有任何人願意說一句明確的話。沒有人承擔自己能夠承擔的部分，公司的流程一樣會停住。

第二天，經營者聽到了這些爭執。他先有些不高興，覺得不過是把原本就有的崗位職責寫得更明確，怎麼反而引出這麼多意見。財務負責人沒有立即替員工說話，而是把一份付款材料擺到他面前，逐頁問：“合同金額由誰確認？交付情況由誰確認？收款信息由誰核對？如果最後我在這裡簽了字，這些事情是否就都變成財務一個人的判斷？”經營者回答，當然不是，業務部門應當為它提供的事實負責。財務負責人又問：“那我們的說明裡，為什麼只寫了一句誰審核誰負責？”

經營者看著那句話，一時沒有接話。他明白管理層最初的意思，是不希望出現“機器做的，所以沒人負責”的空白。過去，人類員工也會出錯，制度要求不同崗位承擔職責，才能保證有人檢查、有人糾正、有人解釋。這套管理經驗並沒有因為來了 AI 就失去價值。可是，機器把資料更快地送到人面前，也把許多本來由不同崗位掌握的信息集中成了一份看似完整的報告。誰被指定為最後的審核人，誰就容易被別人當成那個理應知道全部情況的人。

客服負責人對此有另一層感受。她並不希望員工把每一封特殊來信都推給上級，彷彿只有負責人才能判斷客戶是否需要幫助。有些情形，員工掌握了完整記錄，確實應當按崗位要求認真處理，也應解釋自己的決定。可她同樣不願讓一名只看得到系統摘要的客服，對銷售人員過去作過的口頭承諾作出超出所知的保證。尤其在與客戶往來的事情上，一句“我已經看過了”，可能被理解為公司確認了整件事，而實際查看的人也許只接觸到其中的一部分。

幾位負責人漸漸發現，員工真正抗拒的，往往不是正常的崗位責任，而是一種沒有說清範圍的責任。採購員工當然應該檢查自己能核對的供應商條件，財務員工也應該對明確屬於財務核驗的項目盡到職責；因為工作量大就完全不看，或者明知材料有疑問仍然隨手批准，都不能算履職。但是，如果一份建議需要多個部門才能判斷，而流程只記錄最後一個點擊按鈕的人，把所有後果都往這個名字上放，既不能幫助員工認真檢查，也不能幫助企業弄明白究竟哪裡需要改進。

簽字之外，還有多少事情

當公司把一批機器的工作成果交給一個崗位檢查時，給他的不僅是一個按鈕，也是在要求他投入時間、取得信息、作出判斷，並在必要時承擔說“不”帶來的延誤與壓力。若這些條件沒有一同得到安排，僅僅把名字填進表格，並不會使他突然擁有相應的能力。

經營者沒有急著把那句說明撤掉。他覺得公司仍然需要有人為工作把關，也需要一種可以追溯的分工，否則今後每遇到問題，各部門只會相互推說“不歸我管”。他讓幾個負責人把近期卡住的申請挑出來，不看誰抱怨得最響，而是逐項說清：送到審核人面前的究竟是什麼，必須憑什麼才能判斷，缺少的材料又掌握在誰手裡。

這件事做起來比大家想像的費勁。採購部門拿出一份供應商調整建議，員工能說明報價、交期和合同條件是否有變，卻還需要業務部門說明需求為什麼改變。財務部門拿出那份已經補齊材料的付款申請，指出付款條件能查，交付事實仍要由實際驗收的崗位提供依據。運維團隊則拿出一個沒有執行的維護安排，說明自己能夠判斷技術影響範圍，業務是否允許停頓，還得聽真正使用系統的人意見。大家在同一張紙上寫下這些差別時，原先混在一句“負責”裡的許多事情，才顯出不同的形狀。

討論並不總是愉快。業務部門有人覺得，既然採購和財務都設了審核崗位，自己提供材料後就不應再被反覆打擾。採購主管反問，如果訂單的交貨日後來變了，卻沒人告訴審核人，難道讓他憑猜測採購？財務負責人也提醒，檢查資料是否齊全，不等於替資料的提供者保證每句話都真實。話說得重了，經營者便讓大家先停下爭辯。他發現每個部門講的都有一部分道理，也都容易把別人的困難看得過於簡單。

他隨後問了一個更具體的問題：“那是不是材料不全，你們就什麼都不用管了？”採購主管說不是。發現缺口、及時退回、說明需要誰確認，本來就是審核職責的一部分。財務負責人也說，遇到明顯不一致的材料還照樣通過，當然不能因為信息是別人填的就推卸自己的責任。運維工程師則補充，自己既然知道一個維護操作可能影響正在運行的業務，就應當把風險說清楚，而不是等事情發生以後再表示不知情。幾個人的回答讓經營者放心了一些：他們並非希望把責任從自己身上拿掉，而是希望責任落在真正能夠理解和影響的事情上。

問題隨之變得更尖銳。員工能指出一份建議哪裡缺少依據，卻不能決定業務部門什麼時候提供資料；能拒絕簽下一份自己看不懂的申請，卻不能阻止新的申請不斷進入隊列；能對眼前的一項操作提出疑問，卻不一定有權改變助手接下來繼續處理的工作範圍。當公司把一批機器的工作成果交給一個崗位檢查時，給他的不僅是一個按鈕，也是在要求他投入時間、取得信息、作出判斷，並在必要時承擔說“不”帶來的延誤與壓力。若這些條件沒有一同得到安排，僅僅把名字填進表格，並不會使他突然擁有相應的能力。

午後，採購主管回到座位，看見那份等待業務確認的急單仍然掛著提醒。他沒有命令員工先簽再說，而是給業務部門打電話，要求把需求日期確定下來。電話另一端的人解釋，客戶尚未確認交付計劃，自己也不願隨口報一個日期。主管只好承認，等待是這件事此刻真實的一部分，不該用一次沒有根據的簽字把等待藏起來。他隨後把預計會延遲的情況告訴相關同事。誰也沒有因此高興，但至少大家知道事情為什麼停在那裡。

傍晚，經營者修改了那份內部說明的措辭。他沒有宣佈一個人人都滿意的新制度，只把過於籠統的要求改成了更謹慎的表達：審核人員應對職責範圍內的檢查負責；發現信息缺失或超出判斷範圍時，應及時提出並交由相應崗位處理。真正複雜的職責怎樣劃分，仍需結合業務逐項明確。這並沒有使隊列馬上縮短，也沒有讓員工從此不再爭論，卻使一些人第一次覺得，自己提出“我不知道”不再天然意味著不負責任。

快下班時，財務負責人經過採購部，看見採購主管還在和同事核對第二天的工作安排。她開玩笑說，今天總算沒有再為了“誰簽字”吵起來。採購主管笑了笑，說只是把眼前幾件事分清楚了。他望著屏幕上仍在更新的助手任務，忽然意識到，他們這幾天一直在討論誰應該檢查、檢查什麼、出了問題該怎樣說明，可有些更早的決定從未成為討論的中心：這些助手為什麼會接到這樣的任務，為什麼能連續產生如此多的待審結果，又為什麼某些業務步驟已經允許它們自己往下走？

他沒有把這些疑問立刻拋給財務負責人。今天已經夠忙了，何況它們也不是財務部能夠獨自回答的事。走廊裡有人關了燈，另一側辦公室仍亮著幾臺電腦。機器照常準備明天的材料，人們則終於開始懷疑：如果只在最後找一個人負責檢查，卻從不回頭看看那些工作究竟怎樣交到機器手裡，自己是否一直在問題出現得太晚的地方尋找答案？

---

第六章　是誰把權力交給了機器？

一筆已經轉出去的錢

把她遺漏的一次核對找出來，是調查的一部分；若因此認為整筆款項為什麼會進入付款隊列已經解釋完畢，事情恐怕會在最容易找到名字的地方草草結束。

最近幾天公司裡關於審核職責的爭論總算安靜了一些。經營者修改過那句過於籠統的“誰審核，誰負責”，各部門也開始把需要別人確認的事情標得更清楚。採購主管不再催員工對看不懂的交貨日期簽字，財務負責人則要求付款材料寫明業務依據來自哪裡。大家並沒有找到一種能讓所有工作都變得輕鬆的辦法，但至少同意，不能把一個人的名字填進系統，就當作他已經掌握了整件事。

然而，一筆已經付出去的錢，把這份剛剛建立的平靜打斷了。財務負責人是在核對銀行流水時發現異常的：一筆設備改造項目的預付款已經轉給了長期合作的供應商，而項目負責人卻在另一封郵件裡詢問，既然改造計劃還沒恢復，為什麼供應商開始準備專用材料？兩邊說的竟是同一筆業務。財務負責人先以為是付款日期和項目安排錯開了，翻出審批記錄後才發現，款項並不是銀行誤划走的，也不是有人繞開制度偷偷付款。系統裡有完整的付款申請，收款賬戶屬於合同約定的供應商，最後還有財務員工按規定作出的同意記錄。

這項改造原本準備給公司的一條包裝線增加定製部件。業務部門幾周前提出需求，採購與供應商談好了價格和階段安排，合同約定收到預付款後，對方可以開始訂購專用材料。後來，因為客戶訂單的具體規格尚未敲定，業務負責人決定暫停項目，等下一次排產會議再說。暫停的消息發到了項目群裡，隨後被寫進業務部門的週報，卻沒有形成一份送到財務付款流程裡的正式變更。供應商那邊也沒有及時收到明確的暫停通知，於是，當預付款到賬時，它按照原先的合同安排開始了備料。

財務助手整理付款資料時，看到了合同、採購申請、供應商賬戶和此前確認的採購計劃，便將這筆預付款歸入可以繼續辦理的事項。它沒有自己登錄銀行轉賬，卻能按照公司後來配置的流程生成一份待審批的付款申請，把附件整理好、填入收款信息，並寫上“符合合同約定的付款階段”。這份申請進入財務員工的待辦列表。員工核對了金額、賬戶和合同頁碼，看見材料齊全，又因當天還有其他付款要處理，便點了同意。之後，公司原有的付款系統按照審批完成的指令辦理了轉賬，銀行流水裡留下了確切的支付時間。

問題發現後，公司趕緊聯繫供應商。對方並沒有拒絕溝通，也願意退還尚未動用的預付款，只是定製材料的採購已經啟動，其中有一部分加工和取消訂單的費用無法收回。兩邊核對後，公司承擔了八千多元實際費用，餘款退回。經營者看著那張費用確認單，知道這筆錢不會因為大家都沒有惡意而重新回到賬上；這也不是此前那筆加急運費的延續，而是一次新的、已經完成了付款的失誤。

內部最先被找到的，是最後點下同意的財務員工。系統記錄太清楚了，清楚得讓人幾乎不需要繼續詢問：什麼時候提交，誰在什麼時間打開過申請，誰確認通過，都能查到。有人脫口而出：“那不就是她審核的嗎？”財務負責人沒有立即反駁，只請那名員工把自己當時看到的材料找出來。員工顯得很緊張，反覆解釋自己對過賬戶，也核過金額，項目暫停的消息並沒有出現在付款摘要裡。講到最後，她停了一會兒，補充說自己確實沒有逐頁翻看所有往來文件，更沒有專門打電話向項目負責人確認是否恢復實施。

這句承認讓房間安靜了片刻。她有自己應當完成的審核工作，不能因為材料由智能體整理，就把漏掉的檢查說成與自己無關。但財務負責人也知道，這名員工既沒有決定啟動包裝線改造，也沒有安排供應商何時備料，更無權決定公司究竟要不要恢復項目。她所能接觸到的，是一份已經被前面許多環節加工過的付款申請。把她遺漏的一次核對找出來，是調查的一部分；若因此認為整筆款項為什麼會進入付款隊列已經解釋完畢，事情恐怕會在最容易找到名字的地方草草結束。

沿著申請單往回走

不同的人看見同一條工作鏈上的不同片段，片段之間留下的空處，才是這次調查逐漸露出的東西。

經營者讓財務和業務部門把這筆錢從頭到尾再走一遍，但這次不要急著填責任人的名字。他想知道的不是哪個按鈕在什麼時間被按下，而是為什麼一個已經暫停的項目，會在系統裡呈現為可以正常支付的項目。財務負責人先指出，付款摘要中的“符合合同約定”並非虛構：合同的確寫著可以預付，金額與供應商信息也沒有錯。錯的是一句沒有說出口的前提——項目必須仍然打算繼續，而不是已經暫時擱置。合同本身不能告訴付款人，公司昨天是不是改變了主意。

業務部門的人承認，暫停通知只發在自己日常使用的群裡。他以為採購主管知道，採購也應該告訴財務；採購主管則解釋，當時部門正忙著處理其他訂單，以為項目還在等待正式調整，不會有人主動推進下一步付款。沒有人把“暫停”這兩個字寫進那份仍然有效的採購申請。它看起來像一個仍在照常運行的項目，合同、供應商、金額都沒有被撤銷，付款階段甚至比此前準備得更完整。大家都曾做過自己認為足夠的一步，卻沒有人確認這些零散動作合起來是否真正改變了後面的工作。

技術人員在會議後調出了助手的處理記錄。智能體並沒有憑空創造一份合同，更沒有從未知賬戶裡找來收款人。它讀取的是公司允許它使用的業務資料，按已有字段匹配訂單與付款階段，再把結果送入人工審核。技術人員指著幾段記錄解釋，項目群裡的暫停消息沒有進入這次付款整理的數據來源；系統拿到的最後一份正式資料，依然是準備繼續實施的採購計劃。對它來說，那份計劃並沒有因為某個辦公室裡有人說“先等等”而自動消失。

“那它為什麼能送付款申請？”經營者問。技術人員說，這不是智能體自己要求來的能力。最早上線時，助手只能整理報表和核對字段，後來財務部門覺得逐張抄錄申請太慢，希望讓它自動準備付款草稿。技術團隊按業務需求接通了原有的申請系統，允許助手讀取指定的合同與供應商資料，再創建待審核單據。財務審批仍由員工完成，付款仍經公司的原有流程。他們甚至特意保留了這個人工環節，認為這樣既節省了錄入時間，也不會讓智能體直接掌握資金支付的最後一步。

財務負責人記得自己提過這個需求。起初，助手只是將幾頁附件彙總成一段說明；後來員工發現同一份合同的金額、付款階段、賬戶信息還要重新錄入，便希望它順手把申請也填好。那項改動上線時，大家曾仔細確認過，智能體不能直接批准自己的單據，審批人員的崗位權限也沒有變化。沒有人覺得自己在做一件冒險的事。畢竟，提交付款申請與批准付款本來就是兩個環節，人類員工每天也會替別人準備材料。

採購主管卻想起另一次改動。為了減少重複溝通，採購部門曾要求助手在固定供應商、已確認合同的情形下，把符合條件的採購信息自動傳給財務。否則，業務已經完成的事情還要由採購員工重新整理一遍，效率提升就停在部門門口。這個要求單獨看也有道理。合同是真的，供應商是真的，財務也保留了審核。直到今天，幾項看似謹慎的改進才被擺在同一張桌上：採購的信息更容易進入付款資料，智能體更容易生成正式申請，財務員工也更習慣面對一份已經寫好理由的單據。

經營者問：“這些改動，當時是誰批准的？”一時間竟有好幾個人可以回答。技術部門拿出需求單，寫著業務負責人確認功能範圍；財務部門保存著流程測試記錄，說明最終付款仍須人工審批；採購主管找到了自己同意自動同步資料的郵件。再往前，還有經營者批准購買系統和投入改造預算的決定。他沒看過每項字段怎樣傳遞，也沒有逐一同意過後來增加的每個操作能力。他批准的是一項提高效率的計劃，而這項計劃在落地過程中，被許多負責具體事務的人一點一點填成了如今的樣子。

有人覺得，既然流程經過這麼多人看過，就說明每個人都有責任；也有人立刻指出，不能反過來把責任平均攤給所有參與者。負責接口的人未必知道一個項目何時應當暫停，決定暫停的人可能不清楚那句群消息不會傳入付款資料，而最後審核的員工確實有核驗義務，卻無法修改助手的信息來源。不同的人看見同一條工作鏈上的不同片段，片段之間留下的空處，才是這次調查逐漸露出的東西。

經營者沒有再問“到底誰的錯”這樣一個期待立刻得到單一答案的問題。他拿起那張付款申請，注意到上面同時出現了幾個容易被混為一談的事實：智能體能夠填寫這張單，財務員工有資格審核它，公司系統能夠在審核完成後辦理轉賬，供應商也確實接到了款。這些事情依次發生，互相銜接，卻沒有哪一項單獨說明項目在那個星期應當繼續。一個環節在技術上做得到，另一個環節在流程上得到了同意，都還需要放回真實的業務變化中理解。

誰讓這件事成為可能

他知道，找到權力和能力形成的過程，不等於可以免除每一位參與者應盡的職責，更不等於已經完成了對責任的公正劃分。

那天下午，經營者又找來一位在公司待了多年的老員工，問她以前遇到類似問題時怎麼辦。她想起多年前的一次設備採購：一名新人按舊計劃訂了一批材料，後來才發現車間臨時改了生產安排。新人沒有把更新消息問清楚，應當接受批評；可主管當時也發現，車間修改計劃後沒有通知採購，兩個部門都以為對方會先確認。最後，公司沒有隻讓新人寫一份檢討就了事，還重新約定了什麼變化必須通知誰。她說，員工犯錯當然可能是自己疏忽，但如果讓後面的人總靠運氣才能知道前面發生了什麼，再換一個人也可能出問題。

經營者聽著覺得熟悉，卻也看到了眼下不同的地方。以前一名員工一天能提交的採購或付款申請有限，部門之間的信息缺口常常要等人來問才會暴露。如今助手可以很快把許多申請整理成看似完備的材料，並按照已經接通的流程持續送出。它沒有因為產出很快就自動獲得一項新的正當權利，卻實實在在改變了企業裡誰先看見什麼、什麼事情能夠進入下一步，以及員工面對多少需要判斷的事項。制度原先安排給人的檢查工作還在，工作抵達檢查崗位的方式和速度卻變了。

技術部門有人提出，既然問題出在暫停信息沒有送達，是不是在資料裡補上項目狀態就可以避免重演。這個建議值得做，經營者也同意先把眼前缺口補好。但他沒有再把一項修補當作完整答案。今天漏掉的是項目暫停，明天可能是合同條件更新，或業務部門在臨近交付時改變安排。把已經發現的問題修好，可以減少同類失誤；要理解為什麼它會一路走到付款，還必須看看誰能夠改變流程，誰能夠提供新的事實，以及哪一位負責人有機會發現兩者沒有接上。

財務員工後來主動找經營者談了一次。她不希望公司因為這件事就認定自己只是一個無辜的按鈕，也不希望用“系統沒有提醒”解釋一切。她說，看到預付款申請時，自己確實應該問一聲項目是不是仍按計劃繼續，尤其那份合同的簽署日期已經過去了一段時間。只是她也想知道，為什麼付款資料會主動告訴她“符合付款階段”，卻沒有提醒她這是一項可能受業務計劃變化影響的預付款。她能改進自己的檢查習慣，卻不能獨自保證以後所有類似項目的信息都會準時更新。

經營者對她說，公司的調查不會只看最後一次點擊，也不會因此忽略最後一次點擊。他們需要把每個崗位本來應當做的事說清，也要確認崗位是否得到了完成這些事所需的信息與條件。至於這次具體怎樣處理員工失誤、部門溝通和組織流程，還要繼續核對事實，聽取各方說明。他不願急著宣佈誰應該承擔全部損失，因為那樣的結論雖然簡單，卻可能讓公司錯過真正需要改變的地方。

幾天後，一張新的紙貼在會議室白板上。上面不是一份複雜的技術圖，而是經營者讓各部門寫出的普通工作經過：業務提出項目，採購確認條件，技術人員讓助手能夠整理並提交申請，財務人員檢查，原有付款流程辦理轉賬。每一步下面還有一些不同的人名和時間，旁邊留著幾個尚未填好的空格。它看起來沒有系統界面那麼整齊，卻比最初那張只顯示最後審核人的記錄，更接近這筆錢為什麼會付出去的真實經過。

採購主管站在白板前看了很久。他想起此前大家圍繞“誰審核，誰負責”發生的那場爭論，忽然意識到，審核是人們能夠看見的最後一道手續，卻不是智能體工作能力的起點。一個助手可以讀取哪些資料、形成什麼建議、把建議送到哪個崗位、在什麼情況下繼續推動工作，都不是它自己憑空決定的。這裡面有管理層的預算，有業務部門的需求，有技術人員的配置，也有一次次為了減少等待而作出的調整。有些決定正式寫進制度，有些只留下郵件，有些則藏在日常工作裡一句“以後這樣更省事”之中。

經營者最後沒有給白板上的某個人畫圈。他知道，找到權力和能力形成的過程，不等於可以免除每一位參與者應盡的職責，更不等於已經完成了對責任的公正劃分。他只是第一次如此清楚地看見，智能體能夠促成一筆現實付款，並不是某一天突然獲得了神秘的力量，也不是最後那個“同意”按鈕獨自造就的結果。許多原本為了讓公司運轉得更順暢的安排，在時間裡接到了一起；它們在多數時候讓工作更快，在這一次卻把一個已經改變的業務計劃送進了仍按舊計劃運行的流程。

調查沒有在白板寫滿時結束。那筆損失仍要入賬，供應商的後續安排仍要處理，各崗位應承擔什麼責任，也還需要依據實際事實作出判斷。只是公司終於不再滿足於問一句“最後是誰批准的”。經營者合上會議記錄時，隔壁銷售部的人正拿著一份新客戶的報價材料經過，準備繼續談一樁期待已久的合作。他看了一眼，沒有多想。企業內部可以用幾天甚至更久把一次付款的來龍去脈解釋清楚，可在公司之外，別人未必會把自己的決定停在那裡，等他們慢慢解釋完。

---

第七章　責任還在爭論，客戶已經走了

那份看起來沒有問題的報價

讓他難受的不是客戶寫了什麼難聽的話，而是對方一句責備也沒有。沒有人要求他們立即解釋，更沒有人提出只要重新改一份文件就繼續談。對方已經往前走了，只是禮貌地通知了他們。

經營者在走廊裡看見銷售人員抱著報價資料匆匆經過。那時，公司還在處理設備改造項目的錯誤付款，會議室白板上留下的幾個空格尚未填完。經營者沒有叫住他。對於銷售部而言，這本來是件值得高興的事：一家接觸了好一陣子的客戶終於準備比較正式方案，如果價格和交貨安排談得順利，公司便有機會拿下一筆新的訂單。

銷售人員為這位客戶忙了將近兩個星期。他記得第一次通話時，對方沒有急著問最低價，反倒反覆確認交付日期。客戶正在調整自己的生產安排，幾項配套設備和耗材必須在一個特定時段前到位，否則後面的人員排班和安裝計劃都會受到影響。售後服務也不能只寫一句“提供支持”：出了故障誰來響應，哪些情況需要現場協助，哪些費用另行計算，對方都問得很具體。

這些問題過去會讓銷售人員花不少時間。他要找產品部門核對型號，向負責交付的同事詢問排期，再從幾份服務說明裡挑出適合客戶的條款。現在，銷售助手可以把客戶來信整理成需求清單，找到相關產品資料，比較組合價格，連報價函的開頭和結尾都寫得周到。那天中午，他把需求交給助手，下午就看到一份排版整齊的正式報價草稿。表格裡的數量與單價乘起來沒有錯誤，折扣也落在公司允許的範圍內，產品介紹讀起來比他倉促寫出的版本還清楚。

銷售人員不是沒看。他逐項核對了客戶名稱、設備型號、數量、總金額和付款安排，發現一處聯繫人電話寫錯，還專門改了過來。至於交付週期，文檔中寫著“三週左右”，與他記憶裡某次內部溝通得到的答覆相近。他沒有再次打開交付部門最近更新的計劃表。服務部分則寫著“按公司標準售後方案提供支持”，後面附了一段簡短說明。客戶此前問過現場響應，他原打算在下一輪溝通中再作解釋，卻沒有注意到這一版正式文件已經把含糊的表述留在了報價裡。

他為什麼趕著發送，並不難理解。客戶說過，近期就要把各家方案提交內部討論；如果報價遲遲不到，銷售人員擔心公司連進入下一輪比較的機會都沒有。前幾次詢價，助手幫忙準備的材料大多準確，主管也認可這種方式節省了反覆整理文件的時間。銷售人員確認了自己能立即看出的項目，在發送記錄裡留下名字，便按公司原有流程把報價發到了客戶指定的郵箱。電腦顯示“發送成功”時，他長長地鬆了口氣。此前花在材料準備上的一個下午，終於沒有再拖成好幾天。

接下來的兩天沒有什麼動靜。銷售人員打過一次電話，客戶的聯繫人說資料已經轉給採購和使用部門，正在一起評估。他聽見這個回答反而放心：至少報價已經進入了認真比較的範圍。他忙著回覆其他詢盤，間或看看郵箱，想著等對方提出進一步問題，再請交付同事一起參加電話會議。對於他來說，這份文件仍然代表一個尚有希望的機會。

幾天後，客戶的回信到了。措辭很客氣，卻沒有留下多少餘地。對方指出，報價中寫的交付週期與此前得到的溝通信息不一致，現場服務的響應範圍也不夠明確；由於項目時間較緊，他們已經決定優先與另一家供應商推進後續安排。郵件最後感謝了銷售人員先前的配合，並表示未來有合適的項目仍可保持聯繫。

他把這封郵件從頭讀了兩遍。讓他難受的不是客戶寫了什麼難聽的話，而是對方一句責備也沒有。沒有人要求他們立即解釋，更沒有人提出只要重新改一份文件就繼續談。對方已經往前走了，只是禮貌地通知了他們。

錯在哪裡，大家說得越來越清楚

那張報價裡的每一項內容似乎都能找到來源，放到客戶眼前卻沒有完整呈現公司此刻真正能夠承諾什麼。

銷售人員馬上找來原始報價和客戶前期的溝通記錄。他逐頁對照，才發現“三週左右”出自一份較早的產品交付說明。後來，交付部門因生產排期調整，把相關型號的預計週期改成了五到六週，並在新的內部資料中註明特殊訂單需要另行確認。銷售助手查到的舊版本仍放在共享文件夾裡，新版本則保存在產品部門後來啟用的資料位置。數字並沒有被機器算錯，只是用來說明現實的那份資料已經不再新鮮。

售後部分也有相似的來歷。舊說明把遠程諮詢、基礎故障指導和進一步現場協助合在一段話裡，新版服務方案卻已經明確區分響應方式與適用條件。助手沿用了舊版的簡化表述，銷售人員看見“標準售後”幾個字又覺得熟悉，沒有發現客戶反覆追問的現場服務安排其實沒有被清楚回答。那張報價裡的每一項內容似乎都能找到來源，放到客戶眼前卻沒有完整呈現公司此刻真正能夠承諾什麼。

他先給客戶打電話，表示願意立即修訂交期和服務條款。對方沒有拒絕通話，也沒有藉機發火。聯繫人耐心聽完，說他們不只是關心表格裡某個數字，內部使用部門更在意供貨日期能否配合項目安排。其他供應商已經提供了更明確的排期和服務說明，他們的採購流程也開始往下走。即便這家公司現在把文件改好，是否重新納入比較，還得看項目進度和內部決定。銷售人員聽出對方不是故意為難，卻也明白自己不能要求別人因為他發現了錯誤，就暫停已經展開的工作。

掛斷電話後，他去找銷售負責人，接著又聯繫交付與產品資料部門。負責交付的同事把更新通知翻了出來，時間比報價發出早了好幾天；資料維護人員也找到了新版服務說明，文件的建立日期清清楚楚。技術人員查看助手記錄後確認，生成過程和原定操作沒有異常：系統按照能夠取得的資料整理報價，沒有出現未經允許直接發送文件的情況。正式發送仍由銷售人員完成，公司也有審核要求。這些發現使錯誤的經過越來越清楚，卻並沒有讓任何人立刻鬆一口氣。

銷售人員最擔心的是，大家會認為自己既然點過確認，就等於所有材料都應該重新核實一遍。他不否認那次審核過於倉促，也後悔沒有就交期再打一個電話；可他同樣清楚，如果銷售人員要從頭重做助手整理的每項工作，還要挨個查證所有資料是不是最新的，引入助手原本節省的時間就會大幅減少。他不是為了逃避檢查才把工作交給機器，而是在公司認可的分工中使用一項工具。他原以為自己核對的重點已經足夠，現在才知道其中有兩個恰好是客戶最在意的部分。

資料維護人員聽見“舊資料”三個字，也覺得不好受。新版信息確實發佈過，部門內部的員工都能找到，但舊文件並未撤下，兩個位置上的內容沒有建立清楚的替代關係。她說，資料更新不僅是把新文件放進去，還需要讓使用資料的人知道哪一份有效；但銷售部門此前也從未明確要求，所有準備正式報價的系統都必須從同一個位置讀取最新版本。她承認部門應該改進維護方式，同時也希望別人明白，發過更新通知不等於所有下游流程都已經收到了更新。

技術人員的解釋則更謹慎。他們可以說明系統當時讀取了什麼、依照什麼任務生成文本，也可以幫助補齊數據來源；但“客戶最關心哪項服務承諾”這類判斷，並不是技術部門從程序運行正常與否就能替銷售部門作出的。經營者沒有因這番話就認定技術沒有責任。他只是想起上一筆錯誤付款，發現企業又一次面對許多環節各有道理、合起來卻產生不合適結果的局面。不同的是，這次損失並未表現為賬上的一筆費用，而是銷售人員辛苦維繫的一次商業機會開始遠離。

銷售負責人決定繼續聯繫客戶，補上一份內容完整的更正說明，併為不一致的信息道歉。他還請交付部門說明真實排期能否提前，免得為了挽回訂單又寫出一個做不到的承諾。公司沒有因為客戶說了“優先與另一家合作”便立刻放棄，也沒有把一次報價失誤誇大成客戶百分之百因此流失。對方的價格比較、原有合作關係、技術偏好和內部日程，本來就可能影響採購選擇。他們能確認的是，自己的報價存在重要缺陷，而客戶已經把接下來的精力投向了別處。

這份區別讓銷售人員有點難過。如果能證明客戶只因為報價錯了才離開，也許事情反而顯得簡單：找到錯誤，改好錯誤，重新爭取。現實卻不提供這樣乾淨的因果關係。客戶可能本就有別的傾向，錯誤的文件只是降低了他們繼續溝通的意願；也可能他們原本很有興趣，卻在時間緊迫時選擇了更讓人放心的方案。對客戶而言，所有這些因素都是一起發生的，他們沒有義務替供應商逐一分析哪個因素佔了多少分量。

客戶的時間不會停在會議室門口

這也是為什麼更正並不等於回到原點。郵件可以再發一封，報價可以重新計算，服務條款可以補寫完整；但客戶已經為比較其他方案投入了時間，可能向內部作過彙報，甚至開始協調安裝或採購安排。

公司內部開始討論如何處理這件事。經營者要求還原資料從發佈、被讀取、形成報價到由銷售人員發送的全過程，因為以後還會有別的客戶，類似的失誤不能只用一句“下次注意”帶過。銷售負責人需要向團隊解釋什麼情況下必須核對交期，產品部門需要處理不同版本並存的問題，技術部門也得弄清助手為什麼取到了舊文件。這些工作都有意義。沒有調查，就難以分辨是資料過時、審核疏漏還是流程安排出了缺口，更談不上公平地要求哪個崗位改善。

但會議開著開著，討論仍然不自覺地轉向了“究竟誰該負責”。有人認為銷售人員既然向外發送正式文件，就不能只檢查數字；也有人認為，讓一個銷售人員在緊張的期限裡核驗所有後臺資料，本身就不是合理的工作安排。負責資料的人說明更新已經發布，負責系統的人解釋運行並無故障，主管則強調正式報價必須可靠。每個人的話裡都有應該認真對待的部分，也都帶著一點不願讓自己的工作被輕易否定的心情。經營者沒有禁止爭論，他知道不讓人說清事實，只會把不滿留到下一次。

銷售人員卻不時望向窗外。他的手機上仍留著客戶發來的那封郵件，讀到“未來保持聯繫”時，總忍不住想起之前幾次通話。對方曾認真問過安裝時需要多少人手，也問過如果設備出現問題，能不能及時得到現場支持。那時他覺得這些問題說明客戶很重視他們的方案。現在同一段聊天記錄還在，提問的人卻已經去討論另一家供應商的安排。公司內部即使今天就把責任歸屬寫成一份所有人簽字認可的結論，那些談話也不會因此自動接上。

他試著換到客戶的位置想這件事。假如自己是採購負責人，手裡同時擺著幾份方案，一家供應商的交期需要重新解釋，服務條款又與之前溝通得不一樣，而項目本身正在倒計時，他會不會為了給這家供應商一個澄清機會，把其他人的工作全部暫時擱置？他未必會。客戶要對自己的生產安排負責，也要向同事解釋為什麼選擇某個合作方。所謂信任，有時不是覺得對方從不出錯，而是相信對方提供的信息足夠穩定，可以作為自己繼續安排事情的依據。

這也是為什麼更正並不等於回到原點。郵件可以再發一封，報價可以重新計算，服務條款可以補寫完整；但客戶已經為比較其他方案投入了時間，可能向內部作過彙報，甚至開始協調安裝或採購安排。即使最終尚未簽訂合同，某些判斷與期待也已經發生變化。供應商可以為自己的失誤道歉，卻不能替客戶抹去看過那份錯誤文件的經歷，更不能單方面恢復對方最初願意認真瞭解自己的那份耐心。

並不是所有後果都無法補救。客戶也可能接受解釋，重新安排一次比較；雙方仍有可能在將來合作。經營者不願在結果尚未完全確定時，就把它寫成一樁註定失敗的買賣。他讓銷售部保持禮貌而適度的聯繫，不再為了爭取一句肯定而反覆催促。可他們必須承認，客戶已經明確把當前項目的優先方向轉向了另一家供應商，這件事本身就是真實的商業變化，不能因為公司仍在努力而當作沒有發生。

經營者想起早些年公司剛成立時，自己曾親手寫錯過一封給客戶的郵件。發現以後，他連夜重新解釋，對方最終也沒有繼續合作。當時沒有 AI，沒有複雜的工作流，更沒有什麼機器幫人生成材料。他一直記得那次經歷，並不是因為能夠確定客戶究竟為何放棄，而是第一次體會到：企業內部認定一個錯誤可以修復，與外部的人願不願繼續信任你，從來不是同一件事。今天不過是同樣的無奈，出現在速度更快的工作環境裡。

這一回，助手並沒有獨自決定將報價發送給客戶；最後的郵件確實經過了銷售人員的檢查和發送。公司有崗位分工，有文件審批的習慣，也能查出每一步的操作記錄。正因為這些安排都在，人們才更難用“根本沒有管理”來解釋發生的一切。管理並非全無作用，它讓數字錯誤得以被發現，也留下了可供復盤的經過；只是它並沒有讓一份包含過時交期、遺漏重要服務說明的文件停留在公司內部。

傍晚，經營者走到銷售部，看到銷售人員正把修訂後的報價和說明歸檔。他問客戶有沒有新的回覆。銷售人員搖搖頭，說聯繫人已經確認收到更正，但目前仍按原來的安排推進。經營者沒有再追問他是不是盡了全力，只請他把整個過程留下來，供以後改進。銷售人員關上郵件，屏幕上那條“已發送”仍然清晰。它證明文件已經離開，卻不能告訴他們，客戶看到文件以後會怎樣決定。

經營者回到辦公室，桌上放著上一筆錯誤付款的調查記錄，還有今天銷售部整理的報價經過。前一件事讓他明白，找到最後簽字的人並不等於找到了智能體行動能力的全部來歷；後一件事則提醒他，即便最終把所有人的職責都說清，也不能要求外面的世界照著公司內部的調查進度重新開始。他不打算放棄追責，更不打算以一句“AI 會犯錯”來原諒所有疏忽。只是今後再有一份正式報價準備出門，他希望公司能在它抵達客戶郵箱之前，就弄清楚那些不應該遺漏的事情。

那天他沒有提出一套新的技術方案，只問了銷售負責人一個樸素的問題：既然我們有審核流程，也知道誰可以代表公司發送報價，為什麼這份材料還是帶著已經失效的信息發出去了？銷售負責人一時沒有回答。經營者又想，能發送一封郵件，與這一封郵件現在是否值得發送，也許原本就不是同一個問題。等客戶作出選擇之後再把道理講得多麼清楚，終究趕不上文件尚未離開公司的那個時刻。

---

第八章　給機器立規矩

不再只問是誰的錯

真正困難的地方，是把適合明確判斷的規矩從日常語言裡挑出來，讓系統知道在什麼情形下應該繼續、停下或者請人確認。

那份發給客戶的錯誤報價，在公司內部留下的痕跡比銷售人員預想的更久。幾天過去，客戶仍然把當前項目的合作洽談優先留給另一家供應商。銷售人員按約定補發了更正說明，沒有再急著打第三通電話。他知道對方已收到材料，也知道自己不能憑一份道歉就要求客戶重新安排採購會議。公司的業務照常向前走，他卻在準備下一份報價時，忍不住把交付日期多看了一遍。

經營者也沒有再讓各部門反覆討論那封郵件應該由誰負責。該複核的審核記錄還要複核，該釐清的崗位職責還要釐清，但他覺得公司不能一直停留在這件事已經發生之後。前一段時間，企業先因機器的效率而高興，後來又因需要審核而疲憊；嘗試給機器一點自主空間，出了錯便把更多事項交回人手。幾輪下來，人們似乎始終在兩個不大令人滿意的選擇之間來回移動。如今客戶已經作出了選擇，再把這條路走一遍，至少不能只得到一句“以後一定仔細”。

有一天早上，他把銷售負責人和幾位相關同事請來，不要求大家先解釋責任，而是問：“如果明天又有一份報價準備發出去，有沒有哪幾件事，是我們現在就能明確說不能錯的？”銷售負責人想起客戶郵件裡最在意的交期，馬上說，正式報價不能再使用過期的交付資料。產品資料維護人員接著補充，除了交付週期，產品價格和服務方案都有版本；寫在共享文件夾裡的某份資料，並不等於它始終有效。財務負責人也提起，超過規定額度的折扣，不應僅因為文檔看起來合理就直接進入正式報價。

談著談著，大家發現這些要求並不陌生。公司以前就有報價有效期、折扣審批、合同簽署和客戶信息核對的制度，部門主管培訓新人時也會提醒：沒有確認的交期別隨口答應，超過授權範圍的優惠別自行承諾，特殊服務要先問清能不能提供。只是過去許多規則依賴人在工作中記住，有的寫在員工手冊裡，有的藏在一張審批表中，還有的靠老同事在臨發郵件時問一句。引入助手後，人們仍然保留了這些制度，卻未必把制度裡的每項要求一起帶進新的工作過程。

經營者並不打算再給員工發一份更厚的注意事項。他想到前些日子那些排得越來越長的審核隊列：如果一件事明明可以根據日期和金額判斷，為什麼還要每天交給某位主管重新看一遍？可如果這些判斷只留在員工的記憶裡，助手照著舊資料準備好十份文件，主管又不得不從十份裡挨個尋找同一種問題。他希望把那些已經說得清楚的要求，從“大家應該記住”，變成每次準備正式文件時都要經過的檢查。

這並不是什麼從未有過的管理思想。一家企業招來新人，不能只說希望他永遠不犯錯，還要給他工作範圍、金額限制和遇到例外時該找誰的辦法。會計不能因為自信就跳過付款手續，銷售也不能因為著急拿訂單就任意改變合同條件。機器進入同樣的組織，並沒有獲得一種天然不受規矩約束的身份。真正困難的地方，是把適合明確判斷的規矩從日常語言裡挑出來，讓系統知道在什麼情形下應該繼續、停下或者請人確認。

把“應該注意”寫成“必須核對”

公司並沒有取消審批，只是讓原來可以機械核對的部分，不再全部耗費人的注意力。

最先被整理出來的，是產品資料。資料維護人員把同一種型號的舊說明與現行版本擺在桌上，給大家看其中幾處細小變化：交付週期從“三週左右”變成了需要結合排期確認，部分服務條款也改了適用範圍。她建議每一份用於正式報價的產品信息都標明版本和生效狀態，舊版可以留下供查詢，但不能再被當作當前的正式依據。銷售人員聽後問，如果某條舊信息其實還沒有變化，難道也要一律停下？她回答，問題不在於舊文件裡的每句話都錯了，而在於公司不能要求準備報價的人憑感覺挑出哪些句子還算數。

技術人員把這個建議接過去，問得更細。誰有資格宣佈一份資料生效？它在哪一天開始適用？如果一份文件已經被撤回，系統能不能把它和仍然有效的資料區分開？同事們起初覺得只是給文件加個日期，談到這裡才意識到，文件的保存時間不一定是業務生效時間；某份資料昨天才被複制進目錄，也可能包含上個月的安排。討論進行了一陣，他們決定先把用於正式報價的主要產品資料交由維護崗位統一確認，明確可用版本，而不是讓助手在許多相似文件裡自行猜測哪一份最新。

銷售部則把報價中的幾個數字條件重新寫清。一般折扣可以由經授權的銷售人員在規定範圍內處理，超過範圍的優惠必須取得相應批准；特殊的交付承諾要結合交付部門確認的排期，不能只因為客戶希望早一點收到貨，就在文檔裡隨手縮短日期。重要客戶需要定製服務時，也不能把普通的“標準服務”字樣直接當作已經談妥的具體承諾。財務負責人提醒，金額上限可以做成明確比較，折扣比例可以用數字核對，而“這個客戶是不是重要”“這項承諾是否足夠清楚”，往往還需要業務人員認真判斷。

技術人員沒有提出再部署一個更聰明的助手來替每個負責人審核。他們先把那些答案明確的事項接入原有報價流程：報價引用的資料是否屬於已確認的有效版本，折扣是否落在經授權的範圍內，必須填寫的客戶與產品信息是否齊全，特殊情形是否具備所需的人工確認。若某項必要條件不滿足，系統便不給這份報價繼續進入正式發送的準備環節，並告訴經辦人缺的是什麼。至於複雜的商業解釋、客戶實際意圖和例外處理，仍然交回有相應職責的人。

第一次試用就碰到一份舊產品資料。銷售助手從歷史客戶檔案裡找到一套熟悉的設備組合，連同舊報價一起整理成新草稿。若只看文字，它與之前成功交付過的方案很相似；但檢查程序發現其中一項產品說明已不屬於當前可用版本，於是暫停了正式報價的後續處理。銷售人員點開提示，找到最新資料，才發現交付條件確實發生過變化。他修改草稿時並沒有責怪機器，因為助手完成的比較和整理仍然省了不少時間，真正有用的是系統及時指出了一個無需他重新通讀所有目錄也能查明的事實。

幾天後，一名銷售同事為了爭取訂單，在建議方案裡填寫了比自己通常權限更大的折扣。助手把金額計算得很準確，報價版式也十分漂亮，檢查卻沒有因此放行。頁面提示該折扣需要額外批准，銷售同事只好找負責人說明商業理由。負責人聽完決定先與客戶重新談條件，沒有立即同意降價。價格沒有在客戶面前變成公司的正式承諾，也沒有讓經辦人誤以為“機器都算好了”便代表優惠已經得到允許。

這些小小的停頓，給人的感受與從前不太一樣。過去，員工往往在文件準備完畢後才開始一項項檢查；如今，一些日期和數值上的明顯問題被更早指出，不必等主管在堆滿待辦的列表裡碰巧發現。部門負責人漸漸把精力放回真正需要解釋的事情上，例如客戶為什麼要求特殊服務、現有產能能否支持某種交付安排。技術人員在記錄裡也能區分，哪些草稿因資料無效被暫停，哪些因為超出折扣範圍而等待確認。公司並沒有取消審批，只是讓原來可以機械核對的部分，不再全部耗費人的注意力。

採購部看到變化，也想把自己的舊問題納入類似的處理。此前那份過期報價曾給公司帶來加急運輸費用，採購主管至今記得資料明明能夠查到，卻不是當時應該使用的資料。他讓員工整理常用供應商的報價有效期與確認方式，試著把超出有效期的報價標出來。財務負責人也提出，對於已經明確需要額外批准的付款申請，應先確認相關審批狀態，再繼續下一步。大家並非突然發現企業必須守規矩；他們只是把原先分散在不同崗位裡的限制，慢慢搬到智能體越來越頻繁參與的工作過程中。

經營者在一次例行彙報裡看見了這些改變。他問銷售人員是否因此又增加了許多麻煩，對方說，起初確實不習慣頻繁看到“不能繼續”的提示，但比起把問題藏進正式報價發給客戶後再解釋，在內部改一份草稿要容易得多。有時系統提示的只是缺了一項資料，並非確認整份方案有錯；這樣的提醒也不需要每次都升級到經營者那裡。公司終於感到，除了在事後檢查誰出了錯，自己還能在事情尚未走出辦公室時，用一部分老規矩擋住一些已知的疏漏。

規矩能看見的，和看不見的

規則可以排除某些明確不合適的情形，卻無法代替組織判斷所有情形下什麼才是更好的選擇。只有承認它能做什麼，才不會在它通過之後，把剩下的問題全都忽略。

隨著最初幾項檢查得到認可，新的要求陸續被提出。客服負責人希望特殊退款必須核對是否存在其他服務承諾，採購部門希望異常交期能夠自動提醒，財務希望更多申請在資料不齊時就暫緩處理。每一個想法都能找到曾經發生過的麻煩作為理由。技術人員開始接到越來越多的請求：這個也查一下，那個也限制一下，最好以後所有不妥當的事情都提前攔住。經營者聽得出大家急於把過去的無奈變成確定的辦法，卻也發現有些話一旦追問便很難落在紙上。

比如“重要客戶的報價必須更謹慎”。誰算重要客戶？是訂單金額大的，還是合作時間長的，抑或眼下雖然規模不大、卻可能決定未來合作的客戶？再比如“交付時間必須合理”。數字上晚三天不一定有問題，早三天也不一定是好消息；它還取決於工廠的排期、客戶的安裝計劃以及雙方是否已經作過特殊約定。這些判斷並非不能形成制度，但在定義還含糊的時候，若隨便選一個數字寫進系統，就可能把人的模糊共識偽裝成機器能夠準確判斷的事實。

有一次，銷售人員準備給另一家客戶提交方案。報價引用的價格在有效期內，折扣沒有超過上限，交付日期也來自正式維護的資料。所有已經建立的檢查都顯示通過。銷售人員沒有立刻發送，因為他記起客戶在電話裡說過，希望設備到場後有人幫助完成首次安裝，而草稿裡只寫著遠程技術支持。這個差別並未觸犯現有的金額或資料版本要求，卻可能決定客戶怎樣理解公司的承諾。他找到客服與交付同事，確認可以提供怎樣的協助，再把方案改得更明確。

這次沒有損失，也沒有出現新的“機器闖禍”。恰恰因為事情在發送前被人發現，大家才得以平靜地討論：剛剛那些自動檢查都是真的通過了，為什麼草稿仍然需要修改？技術人員指出，程序認真核對了公司交給它核對的條件；它從來沒有被要求判斷客戶口頭表達的所有期待是否已經寫進合同。銷售負責人也承認，不能為了讓系統顯得可靠，便把“沒有發現已定義條件的違規”寫成“這份商業方案完全正確”。一種檢查能夠成立，不等於所有商業問題都已得到回答。

資料維護人員又提出一個更容易被忽略的問題：既然系統只認有效版本，如果負責維護的人誤把一份過時的服務說明標為有效，檢查會怎樣？大家很快明白，程序仍可能給出通過，因為它判斷的是資料是否具有約定的有效標記，而不是憑空知道現實中每一次服務安排的變化。有人建議再增加核對，也有人認為應改善資料發佈時的確認流程。討論沒有得出一種可以消滅所有差錯的辦法，但它使團隊更認真地對待數據從哪裡來、由誰維護，以及業務條件改變後如何傳遞給後面的工作。

經營者原本有些失望，以為規則增加得足夠多，就能讓員工再也不必為智能體提交的材料操心。後來他想，這樣的期待或許從一開始就不合適。公司為採購設預算，不代表每筆預算內的採購都值得做；對銷售設折扣上限，也不代表每一份符合價格規定的報價都能滿足客戶；要求付款資料齊全，更不能保證一個已經改變的項目仍然應該付款。規則可以排除某些明確不合適的情形，卻無法代替組織判斷所有情形下什麼才是更好的選擇。只有承認它能做什麼，才不會在它通過之後，把剩下的問題全都忽略。

規則多了，還會出現彼此之間需要協調的情況。一項特殊折扣可能在銷售授權範圍之外，卻已得到某位負責人書面同意；某份產品資料雖然仍處有效期，交付部門卻剛剛通知某些型號需要重新確認排期。若把所有限制簡單堆在一起，系統可能擋住本應正常辦理的事務；若為了方便把例外開得過寬，又可能使原本的要求失去意義。管理者不得不逐項弄清規則適用於哪些情況、由誰有權批准例外、什麼信息能夠證明例外已經成立。這些勞動並不比寫一句“機器必須守規矩”輕鬆，卻讓公司的要求逐漸具體起來。

技術人員把新增檢查留在現有業務系統和工作流之中，與公司的資料維護、授權和審批機制相銜接。這樣做並不天然有什麼不妥：企業原來就靠這些流程經營業務，其中許多機制經過多年使用，能夠有效阻止特定的不合規操作。經營者也不願為了追求一個抽象的新概念，就否定眼前實實在在減少的錯誤。不過，當他看到一張顯示“檢查通過”的記錄時，開始學著多問一句，這個結果究竟說明了什麼。他知道它表明約定的條件在當時得到核驗，卻不願再把它理解成公司對接下來所有事情都作了保證。

臨近月底，銷售負責人把舊報價事故的復盤記錄與新流程的檢查記錄放在一起。前者寫著那份報價如何引用舊資料，又怎樣在客戶已經作出選擇後被更正；後者顯示幾份新的草稿因為使用舊版本而被暫停，一份異常折扣被送去額外審批。他對這些改進感到踏實，甚至覺得自己終於不再只能靠催員工認真一點來維護工作的質量。只是當技術人員問他“檢查通過後，報價是不是還會被修改”時，他稍稍愣了一下。銷售人員有時確實會在最後整理格式，偶爾也會根據新的溝通調整措辭；正式發送仍走公司的既有程序。他們之前討論了很多關於檢查什麼的細節，卻還沒有把這個問題認真放到桌面上。

經營者沒有要求當場作出結論。公司剛剛學會把一部分能夠說清的管理要求落實成檢查，這份成績值得保留。他只是讓大家下次把報價從準備、核驗到真正發給客戶的經過完整看一遍，尤其要分清哪些是檢查時看到的內容，哪些是最終離開公司的文件。規矩已經寫了不少，也確實替人攔住了一些錯誤；接下來需要弄明白的是，當這些規矩說了“可以”以後，那份準備真正走出門的東西，是否仍然是它們剛剛檢查過的東西。

---

第九章　規矩都立好了，誰守著那道門？

“已通過”的是哪一份

每個動作單獨看，都能解釋它為什麼發生；把它們按時間放在一起，經營者才看見：批准記錄指向修改前的內容，而客戶收到的卻是修改後的內容。

經營者讓銷售部把一份報價從準備到發出的經過重新走一遍。他並不是懷疑前些日子建立的檢查毫無用處。恰好相反，技術人員給他看過好幾條記錄：一份草稿因為引用過期產品說明被擋了下來，另一份因為折扣超過規定範圍而要求重新批准。過去這些問題也許要等到主管翻開附件時才會發現，如今員工在整理文件的過程中便能收到提醒。銷售負責人說，最近同事們已經習慣先把資料弄齊，再考慮按下發送鍵，待辦列表不像從前那樣動不動堆滿了同一種小錯誤。

變化發生在一次並不特別隆重的內部復盤裡。技術人員原打算選幾份已經發送的報價，檢查新流程有沒有遺漏記錄。他們沒有挑過去那位客戶已經轉向其他供應商的業務，而是找來最近一份普通客戶詢價的資料。銷售同事用助手準備了初稿，系統對照現行產品資料確認價格仍然有效，折扣沒有越權，必要的客戶信息也填寫完整。銷售主管看過後作了批准。頁面上留下了一個清晰的狀態：“檢查通過”。從流程記錄看，這正是新規矩應當起作用的樣子。

可技術人員把發出郵件中的附件打開，又找出檢查時保存的草稿，發現兩份報價的交付條件不完全一樣。最初那份寫著“預計六週交付，具體日期以訂單確認為準”。最終發送的文件裡，這行字卻變成了“四周內交付”。總金額沒有變化，產品型號也一樣，表格的頁眉頁腳甚至連位置都沒有挪動。若只看系統的通過標記，很容易認為它們是同一份經過核驗的文件；若把兩份文檔放在一起，差別卻就在客戶最可能關心的那一行。

銷售同事聽見這個發現，起初很驚訝，隨後想起發送前曾收到交付部門的一條新消息。對方說，如果客戶能及早確認安裝時間，生產排期有機會協調得更緊湊，四周左右也許可以爭取，但需要重新確認產能和交付計劃。他當時正在處理另一通客戶電話，便把這段消息轉給助手，讓它把報價裡的交付說明調整得更貼近最新溝通。助手很快完成了修改，替換了仍在準備發送的文檔。銷售同事看到同一個報價編號下仍顯示“已通過”，又覺得交期是交付部門剛剛提供的信息，便按慣常方式發出了郵件。他沒有意識到，“也許可以爭取”在最後的文件裡已經變成了沒有附加條件的“四周內交付”。

這不是智能體從未得到許可便自行闖進客戶郵箱。正式發送仍然由擁有相應崗位權限的銷售人員操作，先前的價格和折扣檢查也真實完成了。問題恰恰出在那些本來都算正常的步驟之間。銷售同事提出修改，助手根據收到的消息更新文件，發信操作沿用了原先的批准狀態。每個動作單獨看，都能解釋它為什麼發生；把它們按時間放在一起，經營者才看見：批准記錄指向修改前的內容，而客戶收到的卻是修改後的內容。

所幸這份報價還處在溝通階段，客戶尚未據此確認訂單。銷售負責人立即讓負責交付的人重新核對排期，隨後主動向客戶澄清：四周只是有待確認的協調目標，正式承諾仍須依據最終排產情況確定。客戶表示理解，沒有因此提出賠償或中斷洽談。經營者不願把這件事寫成又一次重大事故。它是在復盤中發現的缺口，得到及時說明，沒有證據表明已經造成新的損失。但沒有造成損失，並不意味著那個缺口從來不存在。若不是有人拿兩份文件逐字比較，它也許會一直躺在一條漂亮的通過記錄後面。

會議室裡，銷售人員問了一句：“既然檢查是真的，批准也是真的，為什麼到頭來還是不一樣？”技術人員沒有馬上回答。他把電腦轉向大家，打開同一份報價的兩個保存版本，先請所有人看清楚系統當時究竟檢查過哪份材料。經營者第一次覺得，一張寫著“通過”的記錄雖然沒有說謊，卻可能讓人誤以為它承諾了從未承諾過的東西。

規矩沒有錯過，文件卻向前走了

前一件事需要問依據是不是當前可信的事實，後一件事還要問，依據檢查的究竟是不是最後準備做出去的那件事。

技術人員解釋，新流程把報價編號當作一項業務的標識。草稿生成後，系統在某個時刻檢查其中的資料版本、金額和審批狀態；通過的結果保存在這項業務的記錄裡。到了發送環節，工作人員從相同的業務頁面取出準備好的最新文件，確認後交給郵件系統。設計這套流程時，大家想的是一份報價從草稿走向批准，再走向發送，沒有認真考慮過批准以後仍然可以繼續改寫正文。系統能夠回答“這個編號曾經通過檢查”，卻沒有在發送時重新回答“眼前這份內容是否仍然是當時通過的內容”。

有人說，那就在發送前再檢查一遍，不就好了？技術人員點點頭，說這至少可以修補眼前的缺口。但他又問：“如果再檢查以後，還能修改呢？”銷售負責人皺起眉頭，說那就不允許在最後確認後繼續改。技術人員接著問，如果確實收到客戶的新要求，必須修改怎麼辦？“重新走流程。”採購主管回答得很快。幾個同事都覺得有道理，經營者卻讓大家先別急著把結論寫進新規定。他希望先分清楚，為什麼原先已經存在的規定，沒有管到實際發送的那一份文件。

他們沿著記錄往回看，發現整個過程沒有哪一條規則主動宣佈失效。價格沒有越界，服務資料的版本也沒有被撤銷，審批人確實作過批准。被忽略的是規則所指向的對象在時間裡發生了變化。檢查發生在下午兩點，助手兩點十幾分更新交付文字，郵件在稍後發出。幾次操作都圍繞同一個報價編號進行，辦公室裡的人說起“那份報價”也覺得沒有歧義。但對客戶來說，“六週交付”和“四周內交付”不是格式上的兩種寫法，而是兩種可能影響自己安排的承諾。

經營者想起財務部門曾為一筆暫停的項目付款爭論過很久。當時大家逐漸明白，合同裡的條件本身可以正確，業務是否仍應繼續卻是另一回事。眼前這份報價又把問題向前推了一步：即便檢查時業務信息正確，流程中仍可能產生另一個沒有接受同等檢查的結果。這兩件事不是同一種錯誤，不能靠反覆強調員工“認真一些”混作一個答案。前一件事需要問依據是不是當前可信的事實，後一件事還要問，依據檢查的究竟是不是最後準備做出去的那件事。

資料維護人員坐在一旁，聽到這裡提出另一個問題。公司現在給正式產品資料標註有效版本，由指定崗位確認後才能供報價使用；可誰能修改這些標記，誰有資格宣佈一種舊資料重新有效？她舉出最近收到的一個請求：銷售部希望把一份尚待交付部門確認的臨時排期當作當前報價依據，因為客戶催得很急。她沒有直接同意，而是要求先取得負責排產人員的明確確認。如果為了減少等待，任何經辦人都能自己把資料改成“有效”，系統核對有效標記時仍然可以嚴絲合縫，卻不一定守住公司原本想守住的要求。

這並不表示銷售人員不值得信任，更不是說助手會故意篡改規則。銷售需要爭取客戶，產品部門需要保持資料準確，技術部門需要讓流程運轉得順暢，每個人的工作目的都說得過去。只是負責準備一件事情的人，往往同時希望它儘快完成。若他既能夠決定採用什麼事實，又能決定那份事實算不算已確認，再能沿著自己的工作步驟直接把結果發出去，企業就需要格外仔細地看一看：那些寫在紙面上的限制，是否還具有獨立於這次工作意願的意義。

技術人員又拿出一張簡單的流程圖。對外報價通常經過公司新建的資料檢查、折扣核驗和主管批准，最後由銷售人員發送；但公司多年前還保留著一套人工準備報價的辦法。遇到系統故障或者特別緊急的詢價，具備相應崗位權限的人可以使用普通辦公軟件製作文件，再從工作郵箱發送。那條路徑不是為規避規則專門留下的漏洞，而是公司原本就有的工作方式，有時還承擔著正常的業務需要。可是，新加入的那些自動檢查是否也覆蓋它，大家一時說不清楚。

銷售負責人說，傳統的人工報價同樣受崗位制度約束，不能因為沒有經過新頁面，就認為員工可以隨便承諾。技術人員表示同意。他們並未發現有人利用舊路徑故意逃開檢查，也不能僅憑存在另一種發送方式，就斷言舊制度形同虛設。但經營者開始意識到，系統展示多少次“自動檢查通過”，只說明經過這些檢查的事項發生了什麼；那些並未進入同一流程的工作，是否接受等效約束，還得另行核實。統計表上從未出現的事項，並不會因為沒被統計就自動安全。

採購主管想起倉庫出貨的規矩。庫房裡可以貼著醒目的裝箱要求，倉管員也會逐項核對；若有人在核對後更換箱內貨物，或者另一個出口根本不走同樣的登記手續，先前那張完整的檢查單便無法獨自說明最終發出了什麼。這不是要把每個搬貨的人都當成可疑對象。相反，正因為企業相信多數員工在認真工作，才更需要一種能適應疏忽、臨時變化和不同操作習慣的安排。制度不是用來證明人永遠可靠，而是讓人不必只靠記憶和運氣才能把事情辦妥。

經營者順著這個比喻往下想。在過去的管理裡，他們一直知道預算不能隨意超支，合同不能任意改寫，某些付款不能越過必要籤批，倉庫也不能不看單據就把貨交出去。公司從來不是沒有邊界，只是邊界散落在不同崗位、制度和系統之中。以前靠人走過這些環節，事情發生得相對慢，幾個有經驗的員工還能發現前後不一致。如今助手能在很短時間裡完成整理、修改和傳遞，人甚至還沒有完全反應過來，下一步已經準備好了。舊制度並未因此一夜失效，卻暴露出哪些銜接過去是靠人的習慣維繫、今天不能再只靠習慣。

最後一道門站著誰

反過來，現有工作流、權限管理和必要的相互核驗，如果能夠有效限制誰能改、什麼時候必須查、沒通過就不能繼續，同樣能形成真正有用的約束。問題是控制關係是否成立，而不是外表上看起來分成了幾塊。

接下來的幾天，公司沒有停用助手，也沒有要求所有銷售人員把每份報價從頭再做一遍。技術部門先修正了已經發現的流程：凡是影響價格、交期、服務承諾等正式業務內容的改動，都不能繼續沿用改動前的檢查結果；在新的條件得到核對之前，發送環節不能把它當作已批准文件。資料維護人員也與銷售、交付部門確認，臨時消息不能由準備報價的同事自行變成正式有效的交付依據。這些改動有明確的適用範圍，不能保證今後所有商業承諾都絕不出錯，但它們確實補上了此次復盤找到的空處。

經營者對改進表示認可，卻沒有像剛建立那套檢查時那樣急著把每發現一個問題都寫成一條新規定。他知道新檢查本身也要有人制定、有人維護，還要有人負責把它放在正確的位置。如果負責準備報價的助手仍可以在檢查後替換將要發送的正文，重新核驗就可能再次落在錯誤的時間；如果所有正式資料的有效狀態都能由使用者自行隨意更改，檢查也可能只是在認真核對一份未經獨立確認的標記。規則寫得再細，都回答不了“誰有權改變規則所依據的東西”這一問題。

財務負責人說，企業裡其實一直有類似安排。經辦人可以發起付款申請，卻不必因此擁有批准自己的付款、修改財務限額的權力；倉庫員工能夠準備出貨，也不意味著任何人都能自行取消發貨記錄。這些分工未必每處都依賴不同的軟件，更不是要求老闆坐在每個操作前面親自監督。制度把不同的職責交給不同崗位，有的是為了相互核對，有的是為了防止某個人在自己承擔的工作中既定條件又單方面宣佈條件已滿足。人可以被信任，也可以得到便利，但信任和便利不必以取消必要的約束為代價。

技術人員補充，自動化系統同樣可以承擔許多明確的檢查。金額有沒有超過上限、資料是否具有正式生效的狀態、必要批准是否存在，都是在條件清楚、依據可靠時可以穩定核對的事情。助手還可以幫助識別難以形式化的風險，向人提出提醒，幫助他們理解複雜的商業背景；沒有必要把所有事情都變成冰冷的數字比較。但如果最終能否放行一項操作，完全依賴正在準備該操作的助手自己宣佈“我已經查過了”，那麼即使它大部分時間都很準確，公司也應該知道自己究竟把最後的判斷交給了誰。

“那是不是必須再買一套專門的設備來把門？”銷售負責人問。技術人員搖頭，說現在討論的首先不是買什麼東西，也不是把原來一套程序搬到另一臺電腦上。即使兩套系統擺在不同的房間裡，若同一個業務過程仍能隨意改寫關鍵條件、忽略拒絕結果或者從旁邊的路徑直接完成操作，房間分開也不解決問題。反過來，現有工作流、權限管理和必要的相互核驗，如果能夠有效限制誰能改、什麼時候必須查、沒通過就不能繼續，同樣能形成真正有用的約束。問題是控制關係是否成立，而不是外表上看起來分成了幾塊。

經營者聽懂了這層意思，腦海裡卻沒有出現一幅整齊的技術圖。他想到的是公司門口那位負責放行貨車的門衛。門衛不需要懂得倉庫為何採購這些貨，也不必判斷客戶簽下的訂單是否划算；但至少要知道哪一輛車、裝著什麼貨、持有什麼有效手續，才可以從自己負責的出口離開。倘若裝車清單在門衛看過後被換掉，那張蓋過章的舊清單就不能當作新貨物已經核對的證明。更重要的是，如果一輛車可以從無人管理的側門開走，正門核驗得再認真，也不能說明整個出貨過程已經受到同樣管理。

當然，公司的郵件與系統操作不是真正的貨車，也不是所有商務文件都需要一扇可以看得見的門。銷售人員可以發出諮詢郵件，可以與客戶商量尚未確定的方案，並非每次敲擊鍵盤都要經過一項莊嚴的許可。經營者關心的是那些會形成正式承諾、轉移資金、改變設備狀態或給公司帶來現實後果的行動：企業究竟要求它們滿足什麼條件，誰能夠決定條件的適用範圍，以及在條件不滿足的時候，誰真正有能力讓它停下。這些問題既可能由現有系統回答，也可能需要調整不同崗位和工作流程之間的關係，不能先假定只有某種特別的技術才能做成。

復盤的最後，銷售同事又打開那份報價。他把修改前和發送後的兩個版本並排放著，看到同一個客戶名稱、同一組產品和金額，只有交付條件有了不同。過去他最在意的是文件有沒有準備好、自己有沒有獲得批准；今天他第一次問，主管批准時看到的到底是哪一組條件，批准之後發生變化，那次同意還意味著什麼。他並不想因此把所有工作重新推給主管，更不希望助手退回只能整理文字的工具。他只是希望下次面對“檢查通過”四個字時，能夠知道它真正對應的是哪件準備發生的事。

經營者沒有立刻回答。他想起這幾個月裡一次次圍繞機器展開的討論：剛開始，大家只想讓工作更快；出了錯，便想讓人多看看；人看不過來，就分配崗位、爭論責任；等客戶作出選擇之後，他們又開始把規矩寫進流程。如今這些嘗試並沒有白費，只是共同把公司帶到了一個比“多檢查幾次”更準確的疑問前面。機器可以繼續提出方案，也可以在授權範圍內自行完成許多普通事務。但在一項真正會影響外部世界的行動發生前，那道負責說“可以”或“不可以”的關口，究竟應該憑什麼判斷，又由誰掌握？

夜裡，辦公室漸漸安靜下來。第二天要發出的報價仍在繼續準備，產品資料有人維護，銷售有人跟進，助手也照常整理材料。經營者沒有讓所有人停下等一個完美答案。他只在會議記錄的最後寫了一句話，提醒自己下次不能再把兩個問題混成一個：有人同意了一件事，是否就意味著任何版本的它都可以繼續？一個人或者一臺機器在技術上能把事情做出去，又是否代表它在此刻理應讓事情發生？

---

第十章　人類最後還能夠決定什麼

公司從來不是靠老闆一個人運轉

事情仍然有秩序地向前走，不是因為所有員工在那幾天都不可能犯錯，而是因為公司早就約定了哪些決定屬於正常崗位範圍，哪些變化需要額外確認。

復盤結束後，經營者沒有馬上安排下一次技術會議。他把那份已經修訂過的報價放進文件夾，順手翻到公司早年留下的幾頁管理制度。那時企業規模不大，很多安排都是幾個人在辦公室裡商量出來的：採購員在多少金額以內可以自行辦理，超過預算要找誰商量，誰負責核實貨物已經收到，什麼樣的合同需要經營者親自簽字。紙張有些舊了，條款也經歷過修改，卻讓他想起一件幾乎被最近的爭論遮住的事實：公司從來沒有要求他坐在每個員工身後，決定每一件事情。

初創時，他的確常常親自看報價、挑供應商，甚至連給客戶寄一件樣品都要問清緣由。不是因為他特別享受這些瑣事，而是公司既沒有那麼多人，也沒有成熟的安排。後來訂單多了，員工熟悉了業務，他便把一部分選擇交給採購主管，允許銷售在一定範圍內談價格，讓財務按既定流程處理日常付款。每當有人問他是否放心，他總會說，只要知道什麼事情由誰做、做到哪一步必須停下來找別人，就沒有必要把老闆變成整家公司的瓶頸。

他還記得有一年自己去外地見客戶，路上手機信號很差。回來時，他發現倉庫照常收貨，財務結清了幾筆到期款項，銷售也向幾個老客戶發出了例行報價。他並沒有預先讀過每一份文件，更沒有逐筆打電話同意。事情仍然有秩序地向前走，不是因為所有員工在那幾天都不可能犯錯，而是因為公司早就約定了哪些決定屬於正常崗位範圍，哪些變化需要額外確認。那些規定有時會被人理解錯，也會隨業務變動而過時，但它們確實讓一家企業不必依賴某個人時時在場。

最近引入助手之後，經營者卻一度忘了自己原本懂得的道理。機器犯錯，他想增加人工檢查；人工看不過來，他又想找清楚每一個簽字的人。再後來，企業把價格、資料有效期和特殊條件寫進自動檢查，終於減少了一些可以預見的失誤。他們沿著問題一路修補，直到發現批准過的報價與最終發送的報價不是同一份，才再次想到：如果一項工作的安排本來就有明確範圍，那麼組織真正需要守住的，也許並不是“誰最後按了按鈕”這麼簡單。

他把幾個部門負責人請來，不是讓他們重新討論那位已經轉向別家供應商的客戶，而是請他們回憶公司在沒有助手的時候究竟怎樣做事。採購主管說，普通物料在預算和供應商範圍內，由採購崗位依據需求辦理；若價格異常或交期影響生產，就得重新詢問業務部門。財務負責人補充，知道付款賬戶並不等於可以付錢，付款還要有正當業務依據、相應的批准和當前滿足的條件。銷售負責人說得更直白：一名銷售人員有資格代表公司聯繫客戶，卻不能因此隨意承諾任何價格、任何交期。

幾個人越說越發現，過去的制度裡原本就藏著許多“可以”和“不可以”。有的寫在合同審批表上，有的寫在崗位說明中，有的由業務系統在金額超限時自動提醒，有的靠倉庫、財務和銷售之間的交接來保證。它們並不都完美，也不總是執行得一樣嚴格。可如果把它們全說成一堆沒有用的舊手續，就解釋不了公司為什麼能夠在經營者不在時正常工作，也解釋不了為什麼某些未經核實的付款會被財務退回，某些交期承諾必須等生產部門確認。

“所以我們其實早就知道，不是每件事都要人重新批准。”經營者說。採購主管點頭：“但我們過去常常知道找誰，卻未必把到底批准了什麼說得那麼精確。”這句話讓經營者想起那份報價。同一個業務編號、同一個客戶、同一個銷售人員，主管在下午兩點看過的版本寫著六週交付，後來準備發送的卻變成了四周內交付。如果只問有沒有主管同意，系統能給出肯定答案；若問主管到底同意了哪一個承諾，答案就不再那麼簡單。

同意一件事，和讓它發生

能做一件事，說明手裡有使它發生的手段。至於該不該做、在什麼條件下可以做，需要依據工作安排和適用的制度另行判斷。

銷售負責人把那份報價的兩個版本再次打開。這一次，大家沒有忙著尋找新漏洞，只試著用日常語言說清各自做過什麼。銷售人員提出了報價請求，助手幫助整理資料；銷售主管在自己的職責範圍內，看過一份包含產品、價格和交期的材料，表示可以向那個客戶報價；隨後文檔發生了改變，銷售人員仍能使用郵箱把文件送出去。這幾步在同一條業務記錄裡捱得很近，但它們回答的其實不是同一個問題。

經營者先問銷售主管：“當時你說可以，是允許這個員工給客戶發任何版本的報價嗎？”主管搖頭，說自己批准的當然是看到的內容。經營者又問：“如果價格沒有變，只把六週改成四周呢？”主管說，交期本來就是報價的重要部分，是否能夠承諾四周，還得先取得實際負責交付的崗位確認。經營者沒有繼續追問誰更謹慎，只在紙上寫下第一件事：有資格審查某項事務，併為它給予必要同意，是一種明確的崗位權力。銷售主管有這種審批資格，普通員工未必有；但這種資格本身也有對象和範圍。

接著他問技術人員，為什麼銷售員工後來仍能發出改變後的文件。技術人員回答，因為郵箱不會天然知道哪一段交期已經獲得認可。具備工作郵箱的人員可以寫信、添加附件、點擊發送；助手如果被賦予相應工具，也可能具備準備乃至發送材料的技術手段。郵件系統可以確認某個賬戶有發送能力，卻不一定理解這封信是否在代表公司作出一項超出權限的正式承諾。公司上次修補的是已發現的版本變化問題，而不是從此要求所有郵件都先由老闆讀一遍。

這讓幾位負責人想到一種熟悉而平常的區別。庫房員工能夠打開貨物存放區，並不表示他可以把任何貨物交給任何來取貨的人；財務人員能夠使用付款系統，不表示只要有人報出一個賬戶就能付款；駕駛員能夠把車發動起來，也不表示所有道路、所有時段都可以駛入。能做一件事，說明手裡有使它發生的手段。至於該不該做、在什麼條件下可以做，需要依據工作安排和適用的制度另行判斷。技術人員說，在他們的工作裡，這樣的區別並不新鮮，只是以前很多情形有人站在流程的不同位置，習慣上就把幾件事區分開了。

經營者把紙轉過來，讓大家看上面漸漸出現的三行字。他說，第一行是審批權：誰有資格對某項事務給予必要同意。第二行是正當執行權：依據組織的正當制度和當前適用條件，誰有權限讓這一項具體行動進入執行。第三行是事實執行能力：誰在技術上有辦法促成它發生。一個人可能同時擁有這些條件中的幾項，也可能只擁有其中一項；它們不必永遠分配給三個不同的人或三套系統。但把它們想成同一件事，容易讓組織在最需要解釋的時候說不清楚。

銷售主管聽到“執行權”一詞，問是不是意味著還要再設一位專門批准發送的人。經營者說，他也不想這麼做。這裡說的不是再找一名領導坐到流程盡頭，而是辨認這一次行動在制度上究竟有沒有資格發生。一個已經在崗位權限、有效報價範圍和明確條件內的日常銷售活動，完全可能無需重新請示；某個價格超限、交期未確認的正式承諾，則不能因為員工有郵箱、助手也會寫郵件，就自動獲得同樣的資格。以後他們說“執行權”，應當指正當制度意義上的權限，而不是簡單指手裡有工具、技術上做得到。

採購主管提了一個反例：“要是我按制度批准了一份普通採購，員工當然就可以下單。難道還要把批准和下單硬拆開？”財務負責人回答，不需要硬拆。正常業務裡，一次合格的批准可能恰好補齊了當次下單所需的最後一個條件；但這要以需求仍有效、數量和價格沒有變化、採購崗位本來有相應辦理權限為前提。如果批准的是一百件常規材料，後來有人改成兩百件，又不能只拿原先的“已批准”三個字說明新訂單同樣可以發出。她說，這個區別其實一直存在，只不過過去通過工作習慣和系統限制處理，如今必須更清楚地說出來。

運維工程師也舉了自己最熟悉的例子。生產部門允許某次維護在星期日夜間進行，並不意味著工程師星期一上午看到同一項維護任務，就可以不問當時的生產狀態直接實施。他可能有操作賬戶，可以在電腦上完成變更，甚至技術步驟沒有任何錯誤，但業務時段已經改變，原先同意的條件就不能原封不動地套到新的時刻。反過來，如果維護原本就在被允許的時間、範圍和操作計劃中，工程師也不必為了證明自己謹慎，要求經營者每天凌晨再打電話說一次可以。

“那真正留下來的決定是什麼？”經營者問。這回沒有人馬上把答案說成“由老闆最後簽字”。銷售負責人想了一會兒，說企業可以事先規定，哪些正式承諾必須由交付部門確認，哪些折扣屬於銷售崗位範圍；財務負責人說，可以規定付款所需的依據和限額，以及哪些崗位不能自行更改這些要求。對於正常發生的每一筆事務，組織不一定要重新討論這些規矩本身。人需要保留的不是把每一個動作抓回手裡，而是通過合適的治理安排決定規矩如何建立、適用於誰、在什麼情況下改變。

經營者知道，這並不意味著老闆從此獨自擁有一切規則的制定權。財務對支付控制有專業職責，業務部門對能否按時交付負有判斷義務，某些要求來自合同、法律以及其他不能因銷售著急便隨意改變的安排。銷售可以申請特殊交期，卻不能替交付部門宣佈已經確認；財務可以要求付款依據，卻不能單憑自己方便就改寫業務事實。多個崗位需要分別滿足的條件，不一定要通過每次開會投票才能成立。恰恰因為它們負責不同的事情，有些同意不能彼此代替。

把規矩帶到這一次行動面前

人並不需要守在每封郵件和每筆訂單的最後一秒，才能證明自己仍在治理公司。真正重要的是，正當的組織是否還能決定行動的範圍、必要條件和改變條件的資格；一項具體行動在成為現實之前，是否必須尊重這些安排。

討論到這裡，技術人員提出了一個讓大家不再只談抽象道理的辦法：不要先問還要加多少審批，而是拿一份準備發出的具體報價，試著寫清它在離開公司之前究竟必須具備什麼。銷售負責人翻出一份新的正常業務草稿，裡面有客戶名稱、產品組合、金額、交貨安排和服務說明。助手已經整理好了材料，銷售人員準備按照日常程序跟進。它並不是新的事故，也沒有什麼特別緊急的請求，正好可以讓大家在平靜的時候檢驗自己的理解。

經營者請他們從已有制度裡找答案，而不是憑空創造一套新規矩。產品與價格必須來自當前有效的正式資料，折扣不能超出銷售崗位被允許的範圍；如果有特殊承諾，就要取得負責相關事項的崗位確認；正式發送的客戶和文件內容，應當與獲得必要認可的對象相符。若條件原本就由公司規定且能夠明確查驗，助手和業務系統可以自動完成檢查；遇到需要解釋的商業例外，再交給有職責的人判斷。這樣整理下來，大家發現真正需要關心的不是機器做了多少次思考，而是這一次準備產生現實影響的行動，是否滿足適用於它的那些必要條件。

這時，經營者在白板上寫下四個字：執行准入。他沒有把它當成一項已經購買的產品，也沒有說公司只需再增加一個名叫“准入”的按鈕。這個詞只是幫助大家準確提出問題：當一項具體行動準備進入真正的執行階段時，按照當前有效的制度、授權和必要約束，它是否具備被允許繼續的資格？如果某個必須滿足的條件不成立，就不應僅憑助手認為合理、文件看起來齊全，或者過去曾有一次審批記錄，宣佈當前這項行動已經可以發生。

財務負責人馬上問，既然先前那筆設備改造預付款也經過人工審核，是不是隻要設置了執行准入，就能保證那種錯誤不再發生。經營者說不能。若系統只檢查合同金額、賬戶和簽字是否齊全，卻不知道項目已經暫停，檢查仍可能在自己能夠看見的條件下給出肯定結果。必要條件應當由懂業務的人合理確定，所依據的事實也應當能夠反映當時真實的業務狀態。執行准入不是一個能讀懂所有人心思的神奇答案，更不能替代企業弄清資料來源、維護制度與處理例外的責任。

採購主管接著想到，之前那位客戶沒有繼續與公司推進當前項目。即使那份報價的資料完全有效、交期也確實能夠承諾，對方仍可能因為價格、合作習慣或自己的安排選擇別人。一個行動符合公司規定，不等於這個行動在商業上一定成功；一份經過合法合規流程發出的報價，也不等於客戶必然喜歡。經營者同意。他想區分的正是兩件很容易互相糾纏的事情：組織可以規定哪些要求必須得到滿足，卻不能因此宣稱自己能夠預知市場上每一個結果。規矩限制不合適的行動，並不替管理者承擔所有經營判斷。

技術人員說，若把每條檢查都交回人工，恐怕很快又會走回審批越堆越多的老路。銷售負責人反倒笑了：“我們不是已經做過這些了嗎？”從建立那套自動檢查以來，系統早能核對有效價格、優惠限額和必要批准；現在要改進的，不是讓同事重新數一遍金額，而是明確檢查究竟針對哪一次、哪一份、哪個客戶，以及條件變化之後原有結果還能否適用。此前的改造沒有白費，它使許多清楚的要求可以在機器速度下得到核對。執行准入若只是換個名字讓所有事項重新排隊等人點頭，就失去了這場討論的意義。

於是，他們又試著把這件事放回普通員工的工作裡。銷售人員仍可以自行聯繫客戶、準備草稿、商量尚未形成正式承諾的方案；採購助手仍可以比較供應商、整理常規訂單；財務助手也能繼續核對資料並準備付款申請。在那些符合崗位範圍、資料有效、金額正常、沒有額外限制的事務上，公司並不需要經營者重新說一次“允許”。只有當一項行為將要成為正式報價、真實付款、對外承諾或系統狀態的改變時，相關的必要條件才必須以適合該行動的方式得到確認。不同風險和業務不必使用同樣繁重的手續，某些條件也不可能全部寫成簡單的數字判斷。

經營者漸漸覺得，自己過去對機器的擔憂，常常把自由和失控當作兩個只能擇一的結果。放機器自行工作，彷彿就要接受它有可能把任何想法付諸現實；要求它事事請示，又會把人重新壓在無窮無盡的待辦事項下面。現在他看到的是第三種可能：讓智能繼續分析、準備和提出行動，讓員工在崗位範圍內作判斷，而由企業事先明確的制度決定哪些條件不能在具體行動面前被省略。這樣的安排未必適合所有情形，也需要有人不斷維護，但至少不再把安全寄託在“機器永不犯錯”或者“某個人永遠看得過來”之上。

他還提醒大家，決定條件由誰制定、誰有資格修改，比簡單寫下一份條件清單更難。有時業務部門需要根據市場變化提出調整，有時財務必須堅持一項不能被進度壓力取消的約束；若一名負責執行任務的人員可以為了把手頭事情辦成，就自行把必要條件改為“已滿足”，那麼制度表面仍然存在，實際上卻失去了應有的分量。企業需要一套正當的辦法安排這些權限，讓各自負有職責的崗位能夠參與治理，也讓臨時的業務願望不至於輕易代替已經確定的限制。

會議散去時，經營者把白板上那幾個詞留了下來。它們沒有像新的軟件界面那樣令人興奮，也不能立刻修復此前失去的機會，卻讓他重新理解了“人類最後還能夠決定什麼”這個問題。人並不需要守在每封郵件和每筆訂單的最後一秒，才能證明自己仍在治理公司。真正重要的是，正當的組織是否還能決定行動的範圍、必要條件和改變條件的資格；一項具體行動在成為現實之前，是否必須尊重這些安排。至於某個員工、主管或系統是否具有實際操作手段，是另一個不能被混作許可的問題。

技術人員在收拾電腦時問：“我們現在能說清這份報價在什麼條件下才應該發出去。可如果有人沒有滿足這些條件，郵件系統又確實允許他點擊發送，我們憑什麼確信它不會照樣出去？”經營者看了看白板，沒有再說讓銷售主管多檢查一遍。他知道今晚討論得出的，是一項行動應當遵守怎樣的准入要求；這些要求如何真正落到每一條會產生後果的操作路徑上，仍然需要回答。公司終於分清了什麼叫作應該允許，卻還沒有完全說明，究竟誰有能力在不應該允許的時候，讓事情停下來。

---

第十一章　誰能讓一件事情真正發生

說了不可以，事情就會停下嗎

制度沒有消失，檢查也沒有撒謊，只是兩者與實際行動之間缺少了有效的聯繫。那一刻，規則的意義就被留在了文件和會議紀要裡。

那個問題沒有隨著會議散場而消失。第二天上午，經營者到辦公室時，看見銷售負責人和技術人員正在一臺電腦前核對報價流程。他們沒有準備再造一份複雜的新報表，只把同一份報價從起草到發送的幾個步驟攤開，想弄清楚一個非常實際的細節：如果某項必要條件沒有滿足，負責發送郵件的人還能不能把正式報價發出去？

銷售負責人覺得答案本該很簡單。既然企業已經規定價格、交期和服務承諾必須符合相應要求，系統發現異常就應當阻止發送。可技術人員打開郵件界面，提醒他公司原有的做法是先在業務系統裡檢查報價，再把批准過的文件交給員工發送。業務系統確實可以拒絕通過一份不合格的報價，員工卻仍然可能打開自己的郵箱，重新附上一份文件，按下發送鍵。郵件服務器只知道這個賬戶有權發送郵件，並不知道附件裡的四周交期，是否就是主管剛才同意的六週交期。

經營者想起先前那次受挫的客戶合作，也想起那份報價在核對後又被改動的事。那次復盤已經讓大家知道，檢查過一份材料，不等於後來發出的必然還是同一份；後來的討論進一步讓他們說清，員工有發送郵件的技術能力，並不表示每一封代表公司的報價都具有正當的執行資格。可現在，大家才真正碰到下一步：企業既然已經知道某封正式報價不應發送，是什麼讓這句“不應當”在實際操作面前有分量？

“那就禁止銷售自己發郵件？”有人提出。銷售負責人立即搖頭。部門每天要向客戶說明產品、約定見面、回覆普通問題，許多往來根本不是正式承諾。如果把每封信都關進審批流程，他們早晚會回到最初那種工作做完卻等著人蓋章的局面。技術人員也說，郵箱本來承擔很多用途，不能因為正式報價需要特殊控制，就斷言所有郵件都必須由同一套業務規則決定能否發出。

他們把話說得更仔細了一些。對於普通溝通，員工可以按照既有崗位權限發送；對於企業明確列為正式報價的文件，應當有確定的形成與發出方式。假如一份文件只是在業務系統裡獲得“已核驗”的標籤，之後卻任由人用別的工具修改和發送，那麼標籤並沒有真正管住那次正式行為。反過來，倘若公司的正式報價只能通過能夠核實當前條件和發送內容的業務流程發出，員工仍然可以把大量準備工作交給助手，符合條件時照常快速辦理，不符合條件時才必須停下來解決問題。

“可一個人總能把內容複製到普通郵件裡。”銷售人員提醒。經營者沒有迴避。企業不能憑空阻止一個人使用所有溝通方式，也不能假裝一項內部規定就能控制每一個外部渠道。真正需要先說清的是，公司究竟把哪些操作視為受管理的正式業務行為，哪些途徑可以代表公司產生相應效力，現有的權限、系統和管理辦法能否約束這些途徑。如果員工仍然能夠通過其他被認可的流程完成同樣的正式報價，而那裡完全不做必要檢查，原先的改進就不能稱得上完整。至於有人脫離公司認可的渠道私下承諾，則又涉及組織紀律、合同效力與其他治理問題，不能靠一個發送按鈕解決。

經營者發現，自己開始明白技術人員為何一直追問“最後有沒有辦法讓它停下來”。過去他們花了很多時間討論誰來提出要求、誰有資格審批、要核驗哪些材料。這些都重要，卻仍可能發生一種尷尬：檢查人員認真地說了不可以，現實中的工具卻照樣能夠完成操作。制度沒有消失，檢查也沒有撒謊，只是兩者與實際行動之間缺少了有效的聯繫。那一刻，規則的意義就被留在了文件和會議紀要裡。

不同的門，通向不同的事情

真正有效的辦法不是把審批表放在訂單旁邊，讓填單人看完以後自覺遵守；而是在正式提交那份訂單時，讓受控的操作本身受到這些必要條件約束。

採購主管聽說銷售部正在檢查報價出口，帶來一份已經按新規定整理好的常規訂單。他說，採購其實早就有類似的安排。員工可以向供應商詢價，可以用助手比較方案，也可以在內部準備訂單；但向供應商正式下單時，採購系統會核對崗位的採購範圍、預算和必要的審批。金額超出範圍或條件不齊，系統不能僅僅提醒一句“存在風險”，然後允許同一個流程繼續提交。至於已經獲得允許的普通訂單，則無須每次把經營者叫來，再聽他重複說可以。

這項安排並不神奇。它是企業多年積累的做法，只不過過去經常被概括成“採購要走流程”。如果主管批准的是某種材料的一百件，採購員工後來決定改成兩百件，系統理應識別這不是原來那筆已被認可的訂單。若供應商或者交貨條件發生變化，相關檢查也可能需要重新進行。採購主管說，真正有效的辦法不是把審批表放在訂單旁邊，讓填單人看完以後自覺遵守；而是在正式提交那份訂單時，讓受控的操作本身受到這些必要條件約束。

財務負責人把話題帶回付款。前些日子的設備改造預付款仍在他們的工作記錄裡，但這一次沒有人要重新尋找犯錯者。她只想說明，一家企業通常不會因為有人寫好一份付款說明，就讓錢自動轉走。業務部門可以發起申請，財務崗位可以核驗材料，具備相應資格的人可以作出審批，實際資金轉移還要經過支付系統乃至銀行或支付機構的既有控制。不同角色各司其職，恰好是為了避免一份材料從提出到支付全靠同一個人的一句話。

不過，她也提醒大家，流程裡出現多個名字不代表一定安全。如果付款系統只認申請上有一個“已批准”的標記，不管標記針對的是哪個賬戶、多少金額，後面真正轉出的錢仍可能與前面核驗的內容不一致。反過來，若實際支付環節能夠確認所付的對象、數額和相應授權仍然對應原先獲准的那筆業務，這項檢查才真正觸及資金要發生轉移的時刻。銀行的支付控制、企業的崗位分離以及業務系統的規則，本來就可能分別承擔其中一部分任務，沒有必要為了證明一種新思想而否定它們已經發揮的作用。

運維工程師說起工廠的設備時，大家對“最後一道門”有了更直觀的感覺。生產主管批准晚上維護一臺設備，計劃當然有意義；工程師的操作賬戶也確實能發出啟動或停機指令。可是，某些設備還會依據當前狀態、現場條件和安全聯鎖決定某項動作能否繼續。一個管理人員已經同意某個計劃，不代表設備在任何狀態下都應該服從。假如必要的安全條件不滿足，實際控制裝置能夠拒絕動作，這種拒絕不是在替主管重新決定生產計劃，而是在執行另一組同樣重要的約束。

這裡也有不能誇大的地方。並非所有機器都有完善的安全聯鎖，已有聯鎖也只針對它所設計和覆蓋的條件發揮作用。一個只監測防護門是否關閉的裝置，不能替企業判斷今天有沒有必要生產這批貨；一個能夠阻止某種危險啟動的控制，也不保證工廠不會發生別的故障。經營者覺得這個比喻的價值，正在於它提醒自己分清職責：計劃由誰提出、由誰認可，與實際動作還須受到哪些條件限制，本來就是可以分別回答的問題。

三種業務擺到一起之後，會議室裡沒有出現想像中的統一設備。採購的正式下單發生在採購系統，付款最終涉及企業支付流程，生產設備的動作有現場控制，銷售的正式報價又與業務文件和對外溝通渠道有關。它們所用的軟件不同，操作的人不同，有的控制來自崗位與流程，有的落實在系統功能裡，有的依賴設備本身。誰也不認為公司應該把全部業務搬到某一臺新服務器上，只為了讓它有資格替所有部門說最後一句話。

技術人員在白板上畫了兩條不太整齊的線。一邊是提出任務、整理資料、比較方案和形成決定的活動；另一邊是真正讓訂單發出去、讓資金轉移、讓設備改變狀態、讓正式承諾到達客戶的活動。兩邊並非永遠由不同的人或者不同機器承擔，有時候同一個員工從頭做到尾，有時候助手能夠自動完成其中不少工作。但只要某項行動被企業納入受控範圍，必要的條件就不能因為前面負責準備的人很有信心，而在後面真正實施時自動消失。

“這些負責把條件落到行動上的職責，”技術人員說，“也許可以被當作同一件事情來理解。”經營者問它是不是又一種審批。技術人員搖頭：審批給出必要的同意，業務規則規定適用的限制，而這裡討論的，是這些同意和限制怎樣在實際操作面前有效。它可能使用審批結果，卻不等於增加一次審批；它可能調用程序檢查，也不等於只在屏幕上顯示一個檢查結論。它必須與受管理的行動建立真實的控制關係，至少在規定的範圍內有辦法讓不符合要求的操作無法繼續。

智能可以繼續工作，行動必須有邊界

經營者覺得，這種區分反而給自由留出了位置：不必限制機器能夠想到什麼，卻要認真安排它最終能夠促成什麼。

經營者讓技術人員把白板上那項共同職責寫成一句能讓所有部門看懂的話。幾個人討論了好一陣，最後把它稱為執行控制層（Execution Control Layer）。這裡的“層”，首先是思考和組織上的一層：當人、智能體或其他系統提出一項準備影響現實的行動時，相關控制職責負責讓當前適用的執行准入條件作用於這項具體行動，決定受控流程能否繼續，並使不合條件的行動在其控制範圍內被阻止。

銷售負責人擔心，這個名稱聽起來像是公司將要採購的新系統。經營者說，他們剛才已經看過採購、財務和設備的例子，沒有理由把那些成熟的辦法一筆抹去。執行控制層並不一定是一套獨立軟件，也不一定有自己的機櫃、頁面或統一的管理中心。在有些企業，它可以主要體現為原有工作流、崗位權限和業務系統共同形成的控制關係；在另一些場景，它可能由分佈在支付渠道、應用接口和設備控制中的多個環節協作承擔。重要的不是給哪些設備貼上這個名稱，而是能不能解釋清楚：誰在規定邊界，誰在核實當次條件，哪個受控環節有權決定繼續或拒絕，以及最終操作為什麼必須尊重這個結果。

採購主管很快提出一個實際問題：“如果控制點分佈在幾個地方，會不會最後還是沒人真正負責？”技術人員承認有這種可能。分佈並不自動意味著有效。採購流程在自己的出口檢查通過，不代表支付系統就可以把那項許可當作付款許可；銷售系統認定報價合格，也不能替設備決定今天能否啟動。不同控制職責必須各守其範圍，又要在確實需要彼此銜接的地方把關係接起來。否則，白板上看似有好幾道門，現實中卻可能留下某條大家以為別人會檢查的通道。

“那讓所有動作都去同一個地方檢查，不是更容易管理？”經營者問。技術人員說，集中有時便於統一管理與記錄，也可能適合某些業務，但並不是邏輯上必需的答案。支付業務有自己的操作條件，生產設備有不能依賴遠處網絡響應的現場要求，銷售的正式文件又屬於另一類場景。若強行讓一處系統代替所有業務的最終控制，可能增加新的故障集中點，也可能使某些現實操作根本無法及時得到有效約束。分散實現同樣有協調和一致性的難題。選擇哪種辦法，應當由業務性質、已有控制能力與具體風險決定，而不是先給“層”畫出一臺唯一的機器。

銷售負責人又問，既然有了執行控制層，助手是否只能提建議，不能再做實際工作。經營者馬上想到最初引入這些不會下班的新同事，就是希望它們承擔更多重複勞動，不願又把所有事情收回員工手裡。答案並不是禁止機器行動。對於公司已經明確授予相應範圍、必要條件能夠得到滿足的業務，助手完全可以繼續自動準備、提交，甚至在受控路徑內促成實際操作。它能替人省下許多等待，也能比人更穩定地完成某些明確檢查。區別只是，它不該因為自己認為任務合理，就有資格把適用於這次行動的約束一併判作已經滿足。

經營者問：“如果助手同時負責準備文件和檢查文件，不就又回到它自己說自己可以了嗎？”技術人員沒有立即回答“絕對不行”。在日常工作裡，讓同一個軟件完成數據整理和部分自動校驗本來就很常見，也可能足夠滿足某些低風險需求。可是，對於企業明確要求不能由受控行動者隨意改變的關鍵限制，僅僅讓助手自己宣佈檢查通過，不能替代對實際操作路徑的約束。邏輯上分清智能決策和執行控制的職責，只是幫助企業知道需要保護哪種關係；至於現實裡是否真正做到必要的獨立、隔離或者不可繞過，還得根據具體系統逐一證明。

為了不讓討論停留在名稱上，他們重新看了那份作為練習的銷售報價。助手仍然可以根據客戶需求生成內容，銷售人員仍然可以反覆修改草稿。若其中出現特殊折扣，便需要取得相應崗位的認可；若交期超出已確認範圍，就必須先查清能否作出承諾。正式發出時，受管理的流程應當確認此刻準備送出的正是滿足條件的那份內容，而不是憑一條針對舊版本的記錄，放行後來改過的文件。如果條件不齊，正確結果應當是暫緩或拒絕這次正式發出，並告訴相關人員需要補什麼，而非只寫下一個無人理會的警告。

這並不要求助手像一個害怕犯錯的員工那樣，在每句話後面問一聲“我可以嗎”。它可以在草稿裡試驗不同表達，可以比較新的組合，可以提出更大膽的商業建議；人也仍然能夠討論是否應該調整一項原有規則。討論和建議本身，不等於真實支付、正式承諾或設備動作已經發生。只有當某項具體行動準備跨過組織認定的正式界線時，才需要讓與之相適用的約束以實際有效的方式出現。經營者覺得，這種區分反而給自由留出了位置：不必限制機器能夠想到什麼，卻要認真安排它最終能夠促成什麼。

財務負責人提醒，不能把拒絕能力講得過於浪漫。如果企業把錯誤的規則寫得非常嚴密，系統也可能忠實地阻止本來合理的業務；如果規則遺漏了某種需要防範的情況，操作即使全部通過，也未必符合公司真正希望的結果。銷售部此前那次合作機會受挫時，報價裡的問題不是每個數字都算錯，而是資料有效期和服務承諾沒有被充分表達。現在即使能夠擋住那些已知的不合格條件，企業仍需有人持續審視條件是否合理、信息是否及時，以及規則變化應當經過怎樣的授權。把規矩落實到行動，不代表規矩從此不必接受人的治理。

運維工程師還補了一句：一道門能否守住，取決於行動是不是真的從門前經過。如果生產設備還有一條未納入控制的操作途徑，或者系統能夠在檢查之後把關鍵內容換掉，白板上的職責就算畫得再清晰，也不能據此斷言所有操作都受控。經營者想進一步追問該怎樣證明這些事情，技術人員卻說，今天先別急著給出漂亮結論。他們剛剛形成的是一種看問題的方法，還不能憑一個名稱證明已有實現可靠。要談可靠，就得認真檢查規則從哪裡來、狀態依據是否可信、受控範圍是否完整，以及拒絕決定是否真能在需要時生效。

會議快結束時，銷售負責人重新打開那份練習報價。他這一次沒有問要不要給銷售人員再增加一次人工簽字，而是問正式發送的那一步，是否能夠確認當前版本符合當次要求；如果不能，誰會阻止它繼續。財務負責人想到的是另一套支付流程，採購主管想到的是下單時必須滿足的崗位條件，運維工程師則想到生產設備實際接受指令前的現場限制。他們並沒有在腦海裡看見同一臺機器，卻開始用相似的問題審視各自的工作。

經營者關掉投影，看著白板上留著的兩片區域：一邊是不斷產生想法和方案的智能工作，一邊是會讓現實發生改變的行動。中間並沒有被他畫上一堵無法穿越的牆，因為許多正當的行動本來就應該順利通過，也因為企業需要智能繼續工作。他只在兩邊之間留下了一行樸素的提醒：必要的條件不能停在同意和檢查的記錄裡，必須真正管到受控的行動。至於這些控制為什麼值得相信，是否存在誰都沒有看見的繞行道路，又該憑什麼驗證，公司還遠遠沒有討論完。那將是他們接下來必須面對的另一道難題。

---

第十二章　不相信機器永遠正確，仍然能夠建立約束

守門的人，也可能看錯

把判斷過程變得可重複，是減少隨意性的一種辦法，卻不是免除制定規則的人認真思考的理由。

會議結束後，那塊白板在會議室裡多留了兩天。有人經過時會停下來讀幾眼，看到“執行控制層”幾個字，又不免想像公司是否準備添置什麼新系統。經營者索性沒有擦掉它。剛剛形成的認識值得保留，卻也不能只因為大家終於為一件事情找到了名字，便以為那些沒有解決的困難都已經消失。

第二天，財務負責人來找他確認一項新的付款流程。她沒有帶著異常報告，也沒有報告又出了什麼事故，只是指著白板問：“我們以前信任助手，它會用舊資料；後來要求人審核，人也可能漏看；現在讓受保護的流程把關，如果把關的程序寫錯了呢？”她說這話時沒有反對改進，反而顯得格外認真。設備改造項目的預付款已經讓她知道，一份看起來完全正常的材料，可以在某個無人注意的地方與現實脫節。多加一道檢查，憑什麼就不會發生同樣的事？

經營者請技術人員一起坐下。技術人員沒有說新辦法絕不會出錯。他在白板上畫了一張普通的付款申請，先問最簡單的問題：假設公司規定，這個崗位一次只能批准不超過一定金額的付款，系統能不能準確檢查數字是否越界？財務負責人說可以，原有系統就具備這類功能。技術人員接著問，付款對象是否屬於已經確認的供應商、這份授權是否已經到期，也能不能按明確記錄檢查？她說通常可以，只是要看記錄從哪裡來、有沒有更新。談到這裡，幾個人發現自己說的其實不是一位永遠聰明的守門人，而是一些可以分別提出、分別驗證的具體條件。

一位經驗豐富的員工看一張申請，往往會順帶想起合同、供貨習慣和與同事的交談。有時這種經驗彌足珍貴，有時也會因為記憶或疲勞出錯。AI 適合把許多雜亂材料整理成可供討論的線索，卻不一定適合替企業宣佈所有經營判斷都已正確。相反，像金額有沒有超過限額、指定的批准有沒有失效、執行時刻是否落在禁止時段之內，只要定義得清楚，並取得可靠的依據，便可以用相同的方法反覆核對。檢查結果至少能夠說明它滿足了哪些已定義的條件，而不只是某個助手回答“我覺得沒問題”。

採購主管聽說這場討論，也拿著一份常規訂單加入。他提醒大家，確定性檢查並不意味著自然正確。一個金額上限若少寫了一個零，再穩定的程序也可能忠實地執行錯誤規定；若把某家早已停用的供應商仍列為有效對象，核驗成功只證明名單上的名字匹配，不能替企業證明這筆採購就該發生。甚至兩個人對同一句規則理解不同，也會在寫進系統以前埋下分歧。把判斷過程變得可重複，是減少隨意性的一種辦法，卻不是免除制定規則的人認真思考的理由。

於是，他們沒有急著給所有部門增加一大批規則，而是把已經有的幾項要求逐條問清：為什麼需要它，由哪個崗位提出，有什麼適用範圍，什麼情況下應當停止使用，誰可以批准調整。經營者發現，這些問題並不陌生。過去制定預算、簽署合同和修訂管理辦法時，公司也會討論。不同的是，以前寫在紙面上的一句要求，往往還需要員工在各種情況下自行理解；現在若要讓它在機器速度下自動影響具體行動，含糊的地方便不能一直靠執行時臨場猜測。

財務負責人想到那個暫停的設備項目。假如公司只規定“金額與合同一致且已獲財務同意，就可以付款”，當時的申請仍有可能通過。因為真正缺失的，是“項目已暫停時不得繼續預付”這一業務要求，以及有人把暫停狀態及時帶到付款環節的安排。經營者點頭。規則不是越多越顯得安全，而是應當由有資格制定它們的人，明確哪些條件對此類行動不可缺少。漏掉一個關鍵條件，再整齊的通過記錄也填不上這個空白。

規則知道什麼，必須有人說得清

執行控制層若有價值，恰恰不在於它替所有人當上最高主管，而在於它能把已經正當確立、當前適用的必要條件，在具體行動面前認真對待。

一週後，技術人員請財務與銷售兩邊各帶一份正常業務材料，做一次桌面核對。他特意說明，這不是安排助手當眾表演能力，更不是把一份文件扔給它，讓它想出一套新的公司制度。他們要檢查的，是企業已經寫下的要求，究竟依賴哪些事實才能判斷。會議桌上擺著一份常規付款申請、一份準備向客戶發送的報價，以及一張記錄各部門修改意見的紙。

付款申請先遇到的問題不是金額，而是收款對象。賬戶號碼填寫完整，名稱也與合同上的供應商一致，技術人員卻問：“我們憑什麼知道這是現在仍然允許收款的賬戶？”財務員工答，供應商信息在檔案裡。採購主管補充，供應商更換賬戶通常需要單獨確認，不能因為一封自稱來自供應商的郵件寫了新號碼，就自動把它當成新的有效檔案。否則，負責準備付款的助手只要讀到那封郵件，就可能同時提出變更和宣稱變更已經合法完成。

他們順著這個問題往下找，發現系統是否會比較兩個號碼，並不是最困難的部分。更重要的是，誰能正式確認供應商賬戶發生了變化，確認依據如何保存，舊賬戶什麼時候停止適用，某個員工的臨時備註能不能取代已經登記的資料。財務負責人強調，業務人員可以提出變更，也可以說明為什麼需要儘快辦理，卻不能因為付款趕時間，就隨手取消賬戶核驗。採購主管對此並不反感。清楚知道哪些事情可以商量、哪些必須由相應崗位確認，反而能讓他在催促面前少一點無謂爭執。

銷售負責人打開那份準備發出的報價。客戶名稱、產品型號、單價和交期都已填寫。助手在旁邊列出了“已通過價格檢查”的說明，銷售負責人卻問，客戶前天要求把一項服務從遠程支持改成現場服務，這份資料是否已經反映？負責產品資料的人查了最新服務安排，才確認需要重新說明。價格檢查的確沒有錯，可它從來沒有被賦予判斷全部服務承諾的職責。若有人把一個綠色的“通過”理解為“整份報價毫無遺漏”，便是把有限的證明當成了無限的保證。

技術人員建議，今後在這些必要檢查面前，至少讓使用它的人說得出三件事：檢查的是哪件事，依據的是哪些當前有效的信息，未通過時實際會發生什麼。銷售人員不能只看到一個漂亮的勾號，卻不知道它針對的究竟是價格，還是對外正式承諾的完整條件。財務也不能把“合同存在”理解為“項目狀態必然正常”。這樣的說明未必能在一張界面裡寫得面面俱到，但其背後的核驗過程，應當經得起追問，而不是一遇到疑問就只能回答“系統說可以”。

有人擔心，這樣會不會又讓員工逐項查資料，回到先前的審批疲勞。財務負責人反而解釋，建立可信資料的工作，與要求每名審核員工每天重新打電話確認一次，並不是同一回事。供應商賬戶的有效性可以按約定的程序維護，付款時核對當前記錄；產品服務條款可以由相應部門發佈有效版本，正式報價時引用它。機器能夠承擔大量重複匹配的工作，人的精力則更多花在確立規則、處理真正的變化和解釋不能簡單歸入既有條件的例外上。

不過，可信也不意味著記錄裡寫著什麼就永遠信什麼。運維工程師用生產系統的排班舉例：昨天確認今晚可以維護，不代表今天下午訂單突變後仍然可以停機；上週有效的崗位授權，也可能因為人員調整不再適用。若必要狀態尚未更新，控制程序再精確也只是在對舊世界作判斷。他提醒大家，對一項會改變現實的操作來說，有些信息缺失或者過期，就不應被當作已經滿足條件；這也許意味著多等一會兒，直到能取得足夠可信的依據。

經營者想到另一種不舒服的情況：假如一道關鍵檢查暫時無法取得狀態，業務卻急得不得了，系統是不是可以先讓事情繼續，事後再補材料？幾位負責人並沒有把所有業務都歸成一種答案。普通的信息整理可以繼續，不涉及正式承諾的草稿也不必全部停下；但對於公司已經明確規定必須具有有效依據才能發生的付款、正式報價或特定設備操作，缺少依據就不能僅憑急迫性視為通過。確實需要例外時，應該由有資格的崗位按正當程序改變條件或作出特別安排，而不是讓正在執行任務的一方自行宣佈例外成立。

“可如果今天准許例外，明天誰知道它還有效？”採購主管問。他想起舊報價、舊交期和被遺忘的暫停通知，終於明白規則有自己的時間。許可可能有起止期限，有適用對象，也可能依賴某個仍然成立的業務狀態。一個上個月獲得的批准，不應當未經檢查就被當成今天所有相似行動的通行證。把這些事情說清楚，是為了防止企業反覆栽在同一種錯覺裡：以前有人同意過，所以現在必然還可以。

討論末尾，技術人員把所有人的意見整理成一份尚待確認的記錄。他沒有替財務決定預算，也沒有替銷售確定服務承諾，更沒有讓助手自己擴大可用的操作範圍。這些決定依舊需要合適的業務主體作出，有時還會涉及多個崗位各自不能被省略的約束。執行控制層若有價值，恰恰不在於它替所有人當上最高主管，而在於它能把已經正當確立、當前適用的必要條件，在具體行動面前認真對待。

檢查過的，必須還是要發生的那件事

企業真正能夠努力做到的，是承認這些不完美，把不可省略的要求說清楚，讓它們在能夠驗證的範圍內有效，並繼續對遺漏、例外和外部後果保持警覺。這樣的保證有限，卻不因有限而沒有價值。

真正讓這場討論變得緊張的，是銷售人員後來提出的一個很小的問題。他打開報價系統裡那份已經通過檢查的文件，問技術人員，假如自己在發送前發現客戶稱呼寫得不夠妥當，只改一個稱呼是否還需要重新檢查。旁邊有人覺得這過於謹慎，改一個字又不影響價格。技術人員卻沒有立刻給出“所有改動都必須重新開始”的答案。他先問：公司究竟允許哪些修改不改變已核驗的行動，哪些修改會觸及已被認可的條件？如果沒有人說得清，系統就不能僅憑文件名相同，認定前後的內容仍然一致。

他們重新看先前那份在客戶作出選擇前發出的錯誤報價。此前的問題不是電腦裡沒有留下審批記錄，而是交期和服務承諾本來就沒有被準確核實。如今即便這些條件已經被核驗，若員工隨後把交期由五到六週改成三週，仍借用原版本的通過記錄向外發送，控制就只停在過去的那份文件上。被允許的是甲，真正送出去的卻是乙。技術人員說，重要的不只是保存一份“已同意”的證明，還要能在正式發出時認出它究竟對應哪份報價、哪個客戶，以及哪些被認可的關鍵內容。

財務負責人接過話頭。若一筆款項經過授權時的金額、收款賬戶與實際發起支付時不同，哪怕兩張單據都寫著同一個項目名稱，也不能據此把原有批准沿用下去。採購主管想到的則是訂單數量和供應商；運維工程師想到的是批准維護的設備與實際收到指令的設備。這些場景不是完全一樣，必要的核驗細節也不能生搬硬套，但它們都在問同一件事：先前檢查過的，究竟是不是馬上要改變現實的那個對象和那組條件？

銷售負責人問：“只要我們保存了文件內容，就能保證送出去的一定正確嗎？”技術人員說仍然不能。保存和比對能夠幫助確認兩次所指的是同一份內容，或者發現其中的關鍵差異；可是，原先的內容可能就有不符合客戶實際需求的地方。一個完全沒有被修改過的報價，仍然可能因為交期過長而失去訂單。公司能要求正式承諾遵守哪些明確條件，卻不能因此保證對方願意成交。控制機制能證明的事情應當有界限，證明不了的也要誠實說出來。

還有一條路容易被忽略。業務系統裡已經不允許發送未通過核驗的正式報價，但如果員工仍然可以用另一種被公司認可的方式，把同樣具有正式效力的文件發給客戶，而且那條途徑沒有檢查，原先的規則就沒有約束全部受控行動。運維工程師也說，假如一項設備指令有兩個入口，只在其中一個入口設置限制，便不能說設備的相應動作已經受到全面控制。他們開始把各種真實出口列出來，不是為了把所有交流和所有設備都塞進一箇中心，而是要找出哪些路徑確實能夠促成公司想管理的行動。

經營者提出一個實際難題：有時系統需要維護，控制程序可能不可用。如果所有受控事項都因此停下來，企業會不會承擔新的損失？技術人員承認會。拒絕不合格操作不是沒有成本，錯誤拒絕、狀態缺失和系統故障也可能耽誤業務。企業需要根據風險設計恢復程序、人工介入的合法途徑和必要的應急安排，還要確認這些安排不會變成平時繞開規則的捷徑。對於確實要求先滿足某項必要條件的操作，不能把“控制失效時默認同意”當成無需說明的方便選項。

這時，經營者才覺得白板上那道門變得真實起來。它不應是一個出於善意便會自動開合的比喻，而是一組必須能回答具體問題的關係：規則是誰制定的，是否仍然適用；核對的信息從哪裡來，是否值得相信；允許的是哪一次行動；真正發出的指令與所核對的是否一致；必要條件不成立時，受管理的操作究竟能不能繼續。只要其中一處含糊，整套安排就可能在最需要發揮作用的時候失去分量。

他沒有要求技術人員把所有控制集中到一臺機器上。採購原有的下單限制、支付系統的賬戶與授權核驗、銷售正式報價的出口、設備現場的安全聯鎖，本來就處在不同業務裡。它們可以各自承擔職責，也可以在必要處相互配合；關鍵是保護關係要真實存在，受約束的一方不能僅憑自己想把事辦成，就隨意改掉不可省略的條件。至於怎樣檢驗這些關係、它們可能面對什麼故障或者有意繞行，仍然需要具體測試和持續審查，不能只靠會議室的一張圖證明。

離開前，銷售負責人又問了一句：“我們現在把門守嚴了，是不是就不會再失去客戶？”屋裡有人笑了，沒人把這當作一個愚蠢的問題。過去那位客戶將當前項目優先轉向別家，正是整場討論的重要起點；人自然希望找到一種辦法，避免再次承受同樣的失落。經營者說，規則能夠幫助公司避免使用已經失效的資料、越過明確的金額限制、缺少必須取得的同意，或者用未獲準的內容冒充已經檢查過的文件。但即使這些事情全部做對，客戶也可能選擇更便宜、更適合或者更熟悉的供應商。企業不能把市場的不確定性，交給一道門來替自己消除。

那天下班時，他經過採購部，看見員工正與供應商確認交貨安排；財務仍在核對一筆材料齊全的普通付款；銷售人員則讓助手繼續準備明天的客戶溝通。沒有人因為建立了更清楚的執行約束，就突然變成不會犯錯的人，助手也沒有因此獲得神奇的判斷能力。大多數日常工作仍然在繼續，有些事情比以前更方便，有些必須停下來等信息，而那些本不該跨過的限制，終於有機會在受管理的行動面前得到真實執行。

經營者回到辦公室，望著這些天積累起來的流程和問題記錄，忽然不再執著於找到一個可以永遠放心交付一切的參與者。人會疲憊，機器會誤解，規則會遺漏，控制程序也可能需要修正。企業真正能夠努力做到的，是承認這些不完美，把不可省略的要求說清楚，讓它們在能夠驗證的範圍內有效，並繼續對遺漏、例外和外部後果保持警覺。這樣的保證有限，卻不因有限而沒有價值。

他把先前討論時留在白板上的最後一個問號擦掉，沒有在原處寫上“安全已經解決”。接下來，公司還要面對另一個更久遠的問題：如果不再期待某個員工或某臺機器永遠正確，企業該怎樣重新安排工作、信任與責任，讓不同的人和智能參與者都能在自己的位置上發揮作用？那將不是再增加一條檢查規則就能完成的事情，而是組織本身需要學習的新辦法。

---

第十三章　從好智能體到好制度

公司從來沒有等到一個完美的人

即使公司招到了最優秀的財務主管，也不會把供應商登記、付款授權、對賬和資金操作全部無條件交給他一個人；並不是公司懷疑他有惡意，而是經營活動不能只靠任何一個人的正確判斷維持。

星期一早上，採購主管把一份訂單退回給剛入職不久的同事。那不是因為發生了什麼嚴重錯誤，只是兩種規格相近的材料被填進了同一欄，若按原樣送到倉庫，收貨員還得再問一遍。年輕人有些不好意思，解釋自己按照上週的模板整理，沒注意這次供應商調整了包裝單位。採購主管讓他把實際需求和供應商的計量方式再對一次，隨後又把那份訂單交還給他。整個過程不過十來分鐘，既沒有要求他以後每填一欄都請示，也沒有因為一次差錯就取消他的採購工作。

經營者恰好經過，聽到了最後幾句。他想起自己剛創業時的一位老員工。那個人熟悉幾乎全部供應商，遇到急單總能想出辦法，卻也曾看錯過交付日期。公司沒有因此認定他不可靠，而是調整了交期確認的方式，要求特殊交付條件有明確記錄。他繼續負責重要採購，後來還帶出了幾個新人。經營者當年認為這不過是正常的管理，如今卻忽然覺得，這件小事裡藏著他們這些天一直沒有說清楚的答案。

他回辦公室後，把新近制定的智能體使用規範又讀了一遍。文件裡有很多認真寫下的條款：哪些資料應當核對，哪些操作須經過批准，什麼情況下停止自動處理，出了異常向誰報告。這些安排並沒有錯，可在文件旁邊，還夾著一份待討論的採購建議。有人希望更換一款能力更強的模型，理由是當前助手偶爾會誤解業務描述；另一個人建議將所有重要結果重新交給人工複核，至少這樣比較安心。兩份建議都出於善意，卻讓經營者想起最初那幾個月，他們也曾這樣反覆搖擺。

午後，他請採購、財務、銷售和技術人員找個空檔一起談談，開場沒有問哪個模型最好，只問了一件看似與人工智能無關的事：“假設我們要等每個員工都保證不犯錯，才准許他獨立做事，這家公司還能開下去嗎？”財務負責人笑了笑，說那樣連她自己都不該有批准付款的資格。她經歷過設備改造項目的失誤，知道工作年限和認真態度並不能阻止人忽略某條已經變化的業務信息。採購主管則指著上午退回的訂單說，他沒有要求新人永遠不再填錯，而是讓錯誤有機會在恰當的位置被發現和糾正。

銷售負責人最初沒有接話。他仍然記得那位已經轉向其他供應商的客戶。報價準備得太快，錯誤的信息又沒有在正式發出前被識別，事後再怎樣解釋也沒能挽回客戶當時的決定。在那之後，他對任何自動生成的正式材料都格外警惕。他擔心今天一說接受不完美，明天大家便會把客戶損失當成無法避免的代價。經營者沒有讓他放下這份警惕，只是反問：如果同樣的失誤出自一名經驗豐富的銷售人員，公司會不會從此不允許人向客戶報價？當然不會。公司會調查過程，分清責任，修改做法，同時讓業務繼續。為什麼輪到機器參與時，他們就只能在完全信任和完全不信任之間選擇？

這並不是說機器與員工沒有區別。人會從批評中反省，也會因為合同、崗位職責和現實後果承擔責任；智能體沒有同樣的人事身份和心理機制，卻能夠在短時間處理遠超一名員工的任務。人的一次粗心可能隻影響一張單據，配置不當的自動化流程卻可能連續處理許多張。經營者因此不願用“把它當成普通員工”來替代管理設計。他真正想借用的，是公司早已習慣的一種做法：承認參與者能力有限，仍然根據工作性質分配職責，並在容易出錯的地方設置相應約束。

技術人員說，換模型、改提示、改善數據質量當然值得做。更準確的助手可以減少返工，更清楚的資料能降低誤判，必要的人工審核也能彌補一些機器難以理解的情況。如果把這些努力一概說成無用，就像要求採購主管放棄培訓新人一樣荒唐。問題在於，培訓一個人和建立崗位制度從來不是二選一。即使公司招到了最優秀的財務主管，也不會把供應商登記、付款授權、對賬和資金操作全部無條件交給他一個人；並不是公司懷疑他有惡意，而是經營活動不能只靠任何一個人的正確判斷維持。

經營者把那份關於新模型的建議放到桌面上。建議可以繼續評估，但他在旁邊寫下另一行字：模型能力改善之後，哪些治理要求仍然不能省略？他不再把升級看成通向“終於可以完全放心”的最後一步。一個員工可以因為經驗增長而獲得更多權限，機器也可以在經過評估後承擔更復雜的任務，可職責變化需要有理由、有範圍，不能因為某個演示表現得漂亮，就把原來屬於不同崗位的權力合併成一個籠統的“讓它全權處理”。

把信任放進合適的位置

共同治理不是把所有參與者拉進每一次操作，而是讓必要的權利和約束在需要它們的時候不被忽略。

幾天後，公司開始討論一份新的崗位安排。與過去不同，這次沒有先列出一大串禁止詞，也沒有按部門計算每天需要多少個人點同意。經營者讓每位負責人帶來一種真正反覆發生的工作，說清楚完成它通常需要什麼判斷，出了差錯會有什麼後果，以及現有崗位怎樣分擔這些風險。他們不是要重新設計整家公司，只想先找到那些已經被習慣掩蓋的權力關係。

採購主管拿來的是一份普通耗材補貨記錄。庫存低於常用水平，供應商穩定，單價處於已確認的範圍，過去這類訂單通常由經辦人員處理，超過一定數量或遇到異常價格才找主管。讓智能體整理需求、比較有效報價甚至在明確的小額範圍內推動常規訂單，並沒有天然違背公司的管理經驗。相反，如果任何紙張、包裝帶都要等主管逐筆批准，主管就沒有時間處理真正需要經驗的替代供應商和緊急交貨問題。關鍵不是批准機器自由買任何東西，而是明確它在什麼品類、數量、金額與業務狀態內能夠自行辦理，什麼時候應該停下。

財務負責人提出了不同意見。付款畢竟涉及資金，她不願直接照搬採購的做法。她說公司原有制度就區分日常小額支出、已經完成核對的應付賬款以及需要特別授權的付款。智能體可以準備付款資料，提醒核對差異，幫助整理合同與發票；對於是否能夠在限定場景下進一步自動處理，應分別考慮賬戶核驗、預算、項目狀態和可追溯記錄，不能只因為機器能夠填好支付申請，就將最終資金操作一併交出。她的謹慎並沒有讓採購主管覺得自己被否定，兩種工作本來承擔著不同後果。

運維工程師也不贊成用一張統一的權限表覆蓋所有機器任務。清理過期臨時文件、生成運行報告，與修改生產設備的配置不是一回事。某個操作即使平時只有很小的影響，也可能在訂單集中交付的時段變得敏感。管理者需要考慮現實狀態和恢復成本，而不只是把工作按“簡單”“複雜”貼標籤。有的動作適合自動完成並留下記錄，有的需要值班人員確認，有的則應受生產安排和設備現有保護機制約束。不同部門可以採用不同做法，只要責任和必要條件能說清楚。

銷售負責人提出的例子讓討論慢了下來。助手能夠根據當前價格表生成報價，也能提醒交期和服務範圍是否完整。可客戶有時會要求一項特殊承諾：比標準交期更早交付，並安排工程師在指定日期到場。他過去習慣先與客戶談好條件，再回頭協調內部資源。現在如果讓助手自主處理談判，誰可以代表公司答應這兩個條件？銷售可以判斷客戶的重要程度和商業機會，卻不能憑一封郵件改變生產排期；生產同事清楚現場能否按時完成，也不一定有權決定為爭取客戶犧牲多少利潤。一個完整的承諾可能同時跨過好幾個崗位的職責邊界。

有人建議，既然涉及多個部門，不如建立一個小組，意見多數通過就允許助手發送。生產負責人聽完不太贊同。他說，如果生產已經確認某天根本沒有可用產能，不能因為其他三個人覺得客戶重要，就把不存在的生產能力投票投出來。財務負責人補充，若一份承諾觸及必須遵守的付款或預算要求，也不能用熱鬧的會議代替有效的批准。大家漸漸明白，協作可以充分商量，有些決定確實適合集體討論；但不同崗位的必要條件，不是每個人都能替另一個人作主。

經營者請大家暫時不談投票方式，而把那項特殊承諾拆回現實工作。銷售有權提出客戶要求，解釋這筆業務為什麼值得爭取；生產負責人根據排期與資源確認能否交付；涉及特殊成本和折扣時，由有相應權限的人決定可接受的商務條件；客戶服務負責人則說明現場支持範圍能否兌現。每個人的意見都可能影響最終方案，但只有在企業制度確實賦予某個崗位相應職責時，它的確認才構成那類必要條件。有人反對不等於天然擁有否決任何事情的權力，有人贊同也不能自動取消他人依法或依制度享有的必要約束。

採購主管擔心這樣會不會把工作重新變成一串又一串的審批。經營者說，恰恰要防止這種結果。標準條件已經明確、當前資料可靠、相關權限仍然有效的普通報價，不該因為討論了一次特殊訂單便全部改成人工會籤。特殊情況需要協調，是因為有人提出了標準範圍之外的承諾；一旦各部門形成了清楚且正當的規則，許多重複核對仍可以交給既有流程和自動化檢查。共同治理不是把所有參與者拉進每一次操作，而是讓必要的權利和約束在需要它們的時候不被忽略。

技術人員在一旁把意見記下，卻沒有替任何部門決定標準條件應當是什麼。他提醒大家，建立制度並不等於從此只需看一張表。崗位會輪換，客戶服務範圍會調整，供應商和生產能力也會變化。誰負責維護哪些事實、怎樣提出規則修改、變更要經過什麼程序，同樣需要安排。如果允許負責準備報價的智能體因為趕進度便自行調高折扣上限，或者讓它把某位負責人的沉默解釋為長期放棄審核，這份新制度很快就會失去原來的意義。

會議結束時，桌上留下的不是一臺更聰明的機器，也不是可以讓所有人卸下責任的系統。它更像一份尚未完成的崗位分工：人負責怎樣提出需求和作出具有正當來源的治理決定，機器可以在哪些範圍內處理常規任務，不同崗位的確認如何共同影響特定行動，以及發生異常後應找誰解釋、糾正和調整。經營者沒有讓大家在當天簽字宣佈改革完成，只請他們回去看看，這些安排是否真的符合日常工作的節奏。

不是找一個可以託付一切的人

接受不完美不是把錯誤合理化，更不是為了提高自動化程度而偷偷降低企業對風險的容忍界限。制度能夠做的，是讓錯誤不必總等到後果擴大後才引起注意，使恰當的人在恰當的位置擁有判斷和調整的能力，並儘可能避免一個參與者的失誤未經約束便變成全部人的損失。

這份討論記錄傳到員工手裡，反應比經營者預想的複雜。一位銷售同事擔心，公司現在說要把更多準備和判斷交給智能體，將來出了問題是否又要由最後點擊發送的人承擔全部責任。另一位採購員工則問，既然一些常規操作可以自動完成，以後自己是不是隻剩下給機器擦屁股的工作。過去大家一面抱怨審批太多，一面也從自己掌握的步驟中獲得職業上的安全感。如今公司重新安排權力，改變的並不只是流程圖，還有人們對於工作價值和責任位置的理解。

銷售負責人把這些問題帶回經營者面前。他說，過去那封報價確實是銷售部門的人發給客戶的，不能把這一步從事實中刪掉；但公司若要讓人工只在異常時介入，也得確保介入者知道為什麼要他決定，能夠拿到可靠資料，並有實際阻止不合適承諾的手段。否則，他的名字可能仍然出現在最後一欄，能夠判斷和改變的事情卻比以前更少。經營者聽得很認真。之前那場關於“誰檢查誰負責”的爭論沒有因此過時，只是終於有機會變成更明確的職責安排。

財務負責人隨後提出另一個容易忽略的地方。制度往往喜歡寫“異常交由負責人處理”，可什麼叫異常，負責人不在場怎麼辦，緊急任務是否允許延期，誰有權決定變通，都可能影響員工是否真正敢說不。若公司只把拒絕的責任交給某個崗位，卻不給它足夠的信息和正當權限，所謂相互制約也可能變成相互推諉。反過來，如果任何人都能以“我有顧慮”為由讓全部業務停擺，企業同樣無法正常運作。真正成熟的規則，需要給判斷留下合理空間，也要讓分歧有可以處理的途徑。

經營者意識到，這比購買一款工具困難得多。買工具時，供應商可以介紹速度、準確率和功能；重新分配職責卻要面對誰失去了一部分習慣性的決定權，誰增加了新的義務，哪些安排原來靠熟人之間一句話就能辦妥，哪些模糊之處如今必須寫明白。過去公司也經歷過類似的調整。業務擴大時，他們曾把由老闆親自批准的普通採購交給主管；財務系統上線時，曾重新規定誰維護賬戶、誰核對憑證、誰確認付款。那時也有人擔心不方便，但他們沒有因此放棄組織分工。AI 帶來的變化更快、範圍更廣，卻仍然需要企業以同樣認真的態度面對制度中的人。

幾天後，採購主管又帶著那個年輕同事完成了另一批常規材料的補貨。助手先整理了數量和有效報價，員工核實了這次補貨的真實需要，系統按現有業務約束檢查，過程中沒有出現必須升級處理的異常。採購主管只看了一眼彙總，沒有重新逐項翻看全部材料。他把騰出的時間用來與一家供應商談交付穩定性，並教年輕同事怎樣辨別看似便宜但未必適合生產安排的報價。那名員工仍然會犯錯，也還需要練習；機器同樣不會因為被允許承擔部分工作，就突然理解所有商業取捨。可兩者開始在不同的地方發揮作用。

銷售部門也做了一項小調整。面對普通客戶詢價，助手照常準備材料；需要改變標準交期和現場服務承諾時，銷售人員先收集客戶的真實需求，再協調相關崗位，而不是要求助手自行把問題解決後宣佈一切已獲同意。這並沒有讓公司立刻重新獲得那次已經受挫的項目機會，也不能保證下一份報價必然成交。銷售負責人仍然要判斷市場、理解客戶，必要時承擔自己作出承諾的責任。不同的是，他不再需要為了證明謹慎，把每一項普通工作都拖回完整的人工流程。

經營者後來在內部討論中說，他越來越不願意把“信任”理解成一句籠統的話。相信一名員工有能力，不等於允許他改變任何預算；相信智能體可以準確整理訂單，不等於允許它決定所有采購；信任一套檢查程序，也不等於放棄對規則來源、業務變化和運行結果的管理。信任可以具體到一類工作、一組條件和一個明確的範圍。範圍內的自主，才有機會成為有效率的合作；範圍之外的限制，也不必被理解成對某個參與者人格或能力的否定。

他也沒有要求大家從此不再追究錯誤。發生問題時仍要查清原因，履行該履行的責任，補償能夠補償的損失，並判斷是否需要改變人員安排、訓練方法、規則或控制措施。接受不完美不是把錯誤合理化，更不是為了提高自動化程度而偷偷降低企業對風險的容忍界限。制度能夠做的，是讓錯誤不必總等到後果擴大後才引起注意，使恰當的人在恰當的位置擁有判斷和調整的能力，並儘可能避免一個參與者的失誤未經約束便變成全部人的損失。

到了月底，公司並沒有舉行一場慶祝改革成功的會議。新的分工仍有待細化，一些崗位的職責還需要商量，員工會提出不同意見，技術人員也有不少工作要做。經營者反而覺得這比較真實。企業從來不是因為終於招到一群完美員工才能夠維持經營，也不該因為出現了一群能夠高速工作的機器，就把全部希望押在找到一個永不犯錯的智能體身上。人和機器各自的能力值得提高，但讓他們能夠長期合作的，是一套願意面對失誤、尊重正當權利、不斷修正自身的組織制度。

他最後在那份崗位安排旁邊寫下了一個現實的問題：既然不同業務已經決定採用不同的約束強度，這些要求究竟應當怎樣接到現有的付款、報價和設備系統上？普通操作不必承受過重的手續，高風險行動又必須得到足夠的控制；紙面上的職責劃分，還要在真實工作中經得起檢驗。這個問題不再要求誰來證明執行控制層值得存在，而是把企業剛剛作出的制度選擇交給下一段更艱難的工作：讓技術按照現實風險和業務需要，提供相稱、可檢驗、能夠持續改進的控制能力。

---

第十四章　當制度開始要求技術說“不”

不是每一扇門，都需要同樣重的鎖

低風險、容易補救的工作，可以主要依靠原有權限、確定的業務條件和事後抽查；金額較大、承諾難以收回或可能中斷生產的操作，則需要更明確的對象確認、權限狀態與拒絕能力。所謂提高控制水平，不是把全部任務都改成最繁重的人工會籤。

月底的崗位安排討論結束後，技術負責人收到的第一份任務並不是開發新系統，而是把公司的幾條業務流程重新走一遍。經營者在記錄後面寫道：普通補貨減少重複審核，大額付款須核對授權和對象，正式報價不得擅自承諾交期，生產變更要有明確條件。文字讀起來不復雜，幾位部門負責人甚至覺得，這些原本就是自己每天在管的事。直到技術人員問起最後一步究竟在哪個軟件裡完成，大家才發現，答案沒有寫在同一張紙上。

採購主管拿來了常用材料的訂貨頁面。數量、供貨價格和收貨地址早已可以在現有系統裡核對；庫存不足時，助手會整理補貨建議，主管只在超出常規範圍時介入。財務負責人打開付款軟件，給大家看已經使用多年的崗位權限和分級批准記錄。銷售有客戶資料系統、報價模板和郵件工具，生產運維則使用另一套設備管理程序。公司並非沒有有效控制，只是各種限制分屬不同系統，彼此有時沒有接上。

有人提議乾脆採購一套能夠統一審批、統一授權、統一記錄的產品，把各部門都接進去。技術負責人沒有立即反對，只問他準備用它替掉什麼：財務的付款權限由銀行和企業現有系統共同約束，生產設備有自己的安全操作要求，報價發給客戶則涉及郵件和附件。把管理界面放到一處，也許能讓人看得清楚，卻不等於那些真實行動從此只能經由這一個界面完成。反過來，要求全部系統重做，不僅費用高，遷移時還可能丟掉原先經過多年磨合的有效控制。

經營者讓他先做一張不漂亮但有用的表：每種重要行動究竟在哪裡發生，哪些條件已經有系統負責檢查，哪些情況只是有人習慣上會看一眼，還有哪些動作實際上能夠從別處發起。他強調，過去的制度不是廢紙，新安排也不該為了顯示先進就處處加一道手續。採購員工每天訂購少量標準耗材，與財務準備一筆較大預付款，結果和可挽回程度顯然不同。對前者，價格、數量和供應商限制可以處理多數常規事項；對後者，僅憑“金額沒超標”就付款顯然不夠。

這張表在部門間傳了一圈，爭論反而比上次更實際。銷售負責人問，客戶催得急時，報價能不能先發一份說明性質的草案；財務負責人追問，授權人在出差途中失去審批資格，已經排隊的付款該怎麼辦；運維人員則擔心半夜設備告警時，如果每個恢復操作都等總經理醒來簽字，生產損失可能比操作風險更大。他們開始權衡失誤後果、能否撤回與等待的代價。

技術負責人提出，控制強度應當跟這些差別相稱。低風險、容易補救的工作，可以主要依靠原有權限、確定的業務條件和事後抽查；金額較大、承諾難以收回或可能中斷生產的操作，則需要更明確的對象確認、權限狀態與拒絕能力。所謂提高控制水平，不是把全部任務都改成最繁重的人工會籤。若每份辦公用品訂單都要三位主管批准，公司又會陷入審核積壓。

從寫著“已檢查”，到真的不能繼續

以前大家喜歡問：“這個程序支持審批嗎？”現在的問題是：“哪一個真實操作會被它擋住？什麼情況下能擋住？擋住以後，還有沒有另一個我們沒檢查過的入口？”

他們先選擇銷售報價做一次小範圍改造。這是大家都記得的教訓：先前那位潛在客戶已將當前項目優先轉向另一家供應商，價格數字看似沒有問題，交期和服務範圍卻沒有跟上現實變化。公司後來增加了報價資料的有效性檢查，確實攔下過一些過期數字；但銷售負責人也親眼見過另一種麻煩，一份材料通過了檢查，臨近發送時又發生改動，屏幕上留下的通過記錄並不能替最後發出的文件作擔保。

新安排沒有取消銷售人員的業務判斷。助手仍然負責整理客戶需求、準備標準條款，生產和服務崗位繼續維護自己有資格確認的信息。技術人員要補上的，是這些信息與正式發送之間的一段連接：當銷售選定最終報價時，系統要能夠知道現在準備送出去的究竟是哪一份；假如交期、報價對象或特殊服務承諾發生改變，先前對舊文件的確認不應被當成新文件的通行憑據。

第一輪測試用的是公司內部的模擬客戶地址。銷售人員先準備一份符合規定的報價，完成所有應有的確認，再由發送程序生成正式附件。結果很順利，頁面出現了“已發送”，內部測試郵箱也收到了文件。幾個人看了演示，原本都覺得差不多了。銷售負責人卻讓同事把已確認的交期改短一週，再試一次。助手很快重新整理了附件，頁面上仍留著此前的批准記錄。新的發送步驟重新檢查最終文件，沒有把修改版當作原版放出，而是要求再次確認。

技術人員展示了屏幕上的拒絕提示，銷售負責人卻沒有急著鼓掌。他打開測試郵箱，又檢查了實際生成的附件，確認不只是頁面報錯、郵件卻照常到達。隨後有人提出另一種情況：如果銷售不用報價系統的發送入口，直接把附件下載到電腦裡，再通過普通郵箱發送呢？房間裡安靜了一會兒。不是因為這個問題多麼高深，而是所有人都明白，一個工具只能約束它真正接管的動作。新的發送控制能約束正式報價流程，卻不能憑一個按鈕消除員工所有自行通信的可能。

公司沒有因此宣佈改造失敗。他們查清了現有郵件渠道、客戶承諾的登記辦法，以及哪些正式文件必須由受管理的流程發出。能夠納入系統約束的，就調整入口和權限；暫時無法技術性阻斷的，就由職責、記錄和複核繼續管理，並明確不能宣稱它已經獲得同等保證。對個別非正式交流，他們還保留了靈活空間，因為客戶溝通不可能全部變成固定格式。銷售負責人第一次覺得，這樣劃清能力範圍，比在說明書上寫“防止一切錯誤報價”可信得多。

財務部門接著提出了兩筆測試付款。第一筆金額與收款對象都符合要求，必要批准也仍有效；第二筆在審批完成之後，收款賬戶被換成另一個未獲確認的賬戶。舊流程裡有些信息由人工複核，系統也有自己的支付限制，新工作只是把這些既有機制與最終付款對象對應得更清楚。技術人員在測試環境中讓第一筆正常流轉，讓第二筆停在提交前。他沒有說這證明資金絕對安全，只請財務負責人確認，當前測試覆蓋了哪些付款入口、哪些賬戶信息由誰維護，以及最後提交前發生變更會怎樣處理。

財務負責人又提出一個更棘手的情況：金額、收款方和審批材料都沒變，只是在排隊期間，原本有權同意這筆款項的人離開了那個崗位。技術負責人說，如果制度要求權限在真正提交時仍然有效，就不能把幾天前的同意無條件當成今天的資格。這不是否定過去的審批，而是承認審批附帶時間和狀態條件。測試人員隨即撤銷模擬賬戶的相應權限，再走了一遍流程。系統給出的是明確的停止與重新處理要求，而不是讓助手根據“上週確實有人點過同意”自行猜測公司的真實意思。

一位財務同事擔心，若權限狀態偶爾讀取不到，付款是不是都會卡住。這個擔心並不多餘。技術人員承認，不能憑缺失的信息聲稱已經滿足必要條件，但也不能只留下一個沒有解釋的錯誤框，讓業務部門無從處理。他們因此約定了異常提示、可聯繫的負責人和恢復程序：系統說不出憑什麼放行時，要能說明是哪一項必要信息無法確認；若屬於緊急付款，應該走經過制度認可的例外程序，而不是讓助手偷偷改掉條件，或者請誰臨時借用一個高權限賬號。

到了運維環節，問題的形狀又變了。車間設備需要例行維護，有些檢查不影響生產，有些操作卻可能讓生產線停下。運維負責人拿出自己用了多年的變更單，強調很多危險步驟原本就必須核對設備狀態，操作人員也不可能任意越過設備本身的保護。新的任務不是假裝這些措施不存在，而是看當助手提出一項維護動作時，操作工具能否辨認它屬於日常檢查還是生產變更，相關時段與批准是否仍適用，真正觸發設備動作的入口是否在受控範圍內。

他們安排了一個不影響生產的試驗時段。助手按慣常資料提出調整建議，運維人員將它導入測試設備。一次允許的操作順利完成；第二次故意改變目標設備編號，結果被拒絕；第三次讓相同操作落在禁止的生產時段，系統沒有執行。現場人員沒有僅憑記錄裡的“拒絕”兩個字就結束測試，還核對了設備狀態是否維持原樣。對他們來說，審核日誌有用，但設備有沒有動作更要核實。

然而，運維負責人發現舊工具中還保留著一條供維修人員使用的直接操作路徑。它有自己的安全保護和崗位要求，卻沒有納入這次智能體變更試驗。有人覺得只要機器不會從那邊進去，就不必處理。技術負責人不同意這樣一句話便劃掉風險：今天它也許只向維修人員開放，明天升級接口或調整賬號權限之後，自動化工具是否會獲得新的調用機會，誰都不能光憑印象保證。他們把這條路徑標成另行管理的範圍，核對訪問資格，決定哪些操作必須納入統一的變更條件，哪些仍應由設備原有的受保護機制承擔，並給後續測試留下明確記錄。

接連幾次試驗之後，經營者發現部門討論的語言變了。以前大家喜歡問：“這個程序支持審批嗎？”現在的問題是：“哪一個真實操作會被它擋住？什麼情況下能擋住？擋住以後，還有沒有另一個我們沒檢查過的入口？”這些問題幫助技術人員尋找銜接點，也讓管理者與員工明白控制的實際範圍。

上線不是把風險畫上句號

更有價值的，是讓管理層知道當前保證適用於哪些工作、建立在什麼假設上，改變條件後需要重新檢驗什麼。

有一回，採購主管把一張看似普通的補貨單帶來，問為什麼系統突然不讓助手繼續。原來供應商最近調整了包裝單位，採購人員填入的數量在舊單位下完全正常，換算成新包裝後卻超出了原來規定的常規範圍。這次拒絕並不意味著機器發現了一個精心設計的攻擊，更不是供應商有問題；它只是提醒企業，業務事實發生了變化，而寫進檢查流程裡的計算依據沒有同步調整。採購主管先把訂單交給員工核實真實需求，再請有相應職責的人更新資料。技術人員修正程序之後，將類似情形加入迴歸測試，避免下一次仍在同樣的地方出錯。

這件小事也讓經營者看到，控制程序給出拒絕，並不能替人判斷一項採購究竟值不值得做。假如供應商包裝變化已經合法確認，舊規則仍把它擋住，企業就需要按正當程序調整規則；反之，如果員工為了趕進度隨意提高限制，系統即使運行得流暢，也可能失去應有的作用。他們必須同時關心錯誤放行和不必要的阻斷，既不能用業務著急為由取消所有邊界，也不能把頻繁拒絕當作系統值得驕傲的成績。

技術負責人開始為這些試驗建立一份樸素的記錄。每次只寫清業務場景、使用的系統版本、要檢查的條件、實際採用的操作路徑，以及結果發生在哪裡。對於拒絕測試，除了程序返回什麼，還儘可能確認外部行動沒有在受控路徑中發生；對於成功測試，則檢查最後執行的對象確實對應批准或核驗的對象。記錄不必讓普通主管讀懂全部技術細節，但至少要讓他們知道，所謂“已經驗證”，到底驗證了多少，哪些仍然只是計劃。

經營者曾希望收到一個簡單的百分比，最好告訴他這套措施已經覆蓋公司多少風險。技術負責人想了想，沒有交出一個看似精確的數字。他說，可以統計已發現的正式執行入口、完成測試的路徑和尚待處理的問題，但無法把所有未知錯誤和商業判斷都變成同一個覆蓋率。一次未測出的路徑不會因為報告寫著高分便自動消失；某項正常允許的操作將來造成損失，也不必然意味著拒絕程序失靈。更有價值的，是讓管理層知道當前保證適用於哪些工作、建立在什麼假設上，改變條件後需要重新檢驗什麼。

隨著改造逐步推進，原本沒有太大交集的部門開始共享一些工作方法。銷售修改報價模板，會主動通知負責最終發送校驗的同事；財務調整審批職責，會確認未完成付款怎樣重新核對；運維升級管理軟件前，會列出可能新增或改變的操作入口。他們按影響大小，把必要複核放進原有變更流程。業務繼續推進時，技術控制也跟著現實發生調整，而不是上線那天凍結成一塊再也不動的標牌。

一次系統升級後，他們就發現一處此前沒有預計到的差別。新版銷售工具增加了從移動端快速分享文件的功能，普通銷售人員覺得方便，技術人員卻意識到，這條途徑如果被用來發正式承諾，原先在桌面端檢驗附件的流程未必自動覆蓋。公司沒有因為新功能出現就禁止所有移動辦公，而是核對它能做什麼、正式報價是否仍應走原來受管理的出口，並在完成相應調整之前向員工說明適用範圍。新功能不是敵人，未經檢驗便把舊結論搬到新路徑上，才是需要警惕的習慣。

幾位員工也逐漸接受了這樣一種節奏：系統拒絕並不代表有人犯了大錯，有時只是資料過期、崗位變更、必要確認尚未完成。採購同事不必把每次停止都解釋成技術部門妨礙做生意，技術人員也不該對業務負責人只說“規則就是這樣”。他們約定，拒絕提示儘可能使用業務語言，指出需要補全什麼或應找誰處理；出現反覆阻斷時，由相關崗位一起檢查，是制度真的要求如此，還是實現方式過於僵硬。能夠被解釋、能夠被申訴和調整的約束，更有機會在日常工作中被認真遵守。

經營者問技術負責人，照這個方向發展，行業裡會不會遲早出現一套人人都能用的通用方案。技術負責人說，有些需要的東西確實相似：不同系統怎樣表達一次行動、怎樣傳遞有資格的確認、怎樣記錄真正執行或拒絕的結果、怎樣測試變更後原來的保證是否仍在。這些需求可能催生共通接口和評價方法。但銀行付款、工業設備和客戶溝通的風險不同，企業規模和既有系統也不同，甚至同一個行業裡各家的制度都未必一樣。未來會形成哪些共同做法，得由真實使用、成本和反覆驗證慢慢回答，不能今天先宣佈一個所有人都必須採用的名字。

這番話讓經營者鬆了一口氣。他不再尋找能代替全部制度的工具。幾個月前，公司談起人工智能，最常問的是模型能多快寫完報告，助手能否替人處理更多事項。現在他仍然希望機器做得更多，卻開始向技術部門提出另一種問題：公司明確不允許的那類行動，在哪個實際入口會被拒絕？對於已經允許的日常工作，又有沒有不必要的關卡讓它白白等待？兩類問題並不矛盾，只有一起回答，自動化的效率才不至於靠忽視後果換來。

接近下班時，銷售負責人拿到一份新的常規客戶詢價。助手整理了現行價格、可用交期和標準服務說明，系統完成相應的校驗，銷售人員只需要處理客戶提出的具體商業問題。另一份詢價要求承諾一個沒有確認產能的交付日期，助手同樣很快準備了草案，卻沒有把它當成可以正式發出的文件。銷售負責人看見提示後，聯繫生產同事商量替代方案。這一次，沒有人要求他把所有普通報價逐字複核，也沒有人允許智能體因為客戶催促就替企業作出尚未獲得必要確認的承諾。

技術負責人下樓時，正好看見銷售還在與生產討論那個特殊交期。他想起此前有人抱怨，新制度好像總在教系統怎樣說“不”。可是他剛剛看到的並不是停頓的一天：常規業務仍在流轉，需要人判斷的事情終於顯露出真正的分量。控制能力沒有替銷售贏得客戶，也沒有替生產憑空創造產能；它只是讓一次不該擅自作出的承諾，能夠在進入現實之前停下來，留給有職責的人商量。

經營者在當天的工作記錄裡寫下，公司的制度與技術如今終於有了一些能夠相互印證的地方：不是因為畫出一套完整架構就宣告安全，而是他們確實在有限、明確的業務範圍內，看到了允許怎樣發生，也驗證了拒絕怎樣發生。明天還會有新的業務、新的例外與新的缺口，這些工作不會隨著一次上線而結束。不過，當邊界不再只是一句要求，企業也不必讓每一個人繼續守在每一個按鈕後面。機器仍然會犯錯，人也一樣；接下來值得思考的，已經不只是怎樣擋住錯誤，而是當彼此都不完美時，他們究竟能夠怎樣更長久、更從容地一起工作。

---

第十五章　與不完美的智能共同生活

又一個普通的星期一

過去他們把認真看住每一份文件當作負責，如今更願意把有限的精力花在有判斷價值的地方，同時確保已經說清楚的限制真正得到遵守。

還是星期一早上九點，辦公室的咖啡機仍然要等一會兒才能燒好水。採購部的員工剛坐下，就看見供應商比較報告已經出現在工作臺上。有人順手拿起杯子，像從前一樣說了句：“這幫同事真是不知道下班。”旁邊的人笑了起來。話還是那句話，語氣卻有些不同。過去他們說這話時，既驚訝機器做得快，也隱隱擔心那些不斷送來的報告最後又要壓到自己身上。現在，報告不再意味著又多了一整份必須逐字看完的作業。

這份報告把本週幾家常用供應商的報價和交貨條件整理得很清楚，也指出其中一家的最低訂貨量有了變化。已經確認的常規採購可以沿著現有安排往下走；涉及新增數量和倉儲佔用的部分，則留給採購主管決定。主管沒有像過去那樣一大早面對幾十個等待點擊的按鈕。他先看了庫存變化，去倉庫問了幾句，再與負責交付的同事商量，決定推遲其中一部分訂單。機器沒有替他考慮完所有經營問題，卻把值得他考慮的事情及時擺到了面前。

財務部也在照常忙碌。對賬助手清晨就把幾處差異歸了類，屬於登記時間不同的項目已有相應的核驗結果；另一筆付款因為項目狀態剛發生變更，暫時沒有繼續。財務人員需要確認變更是否已經正式生效，以及新的付款安排由誰決定。她沒有因為系統停止就認為出了事故，也沒有因為前幾次核驗都順利，就把這次停頓當成多餘。她知道，做賬、確認事實、決定付錢，本來就不是同一項工作。

客服部門的屏幕上，一批普通詢問已經得到符合現行服務規則的答覆草稿，適用範圍清楚的事項按授權流程完成處理。只有一封來自老客戶的來信引起了組長注意。客戶沒有抱怨產品質量，只是在解釋自己的特殊處境：原定的安裝日期遇上了廠區停產檢修，如果照標準流程安排，可能要錯過下一次開工。助手提出了幾種處理辦法，還把過去類似情形的記錄列了出來。組長讀完以後，沒有立刻選機器排在第一位的方案，而是給客戶打了電話。對方真正需要的，也許不是一次優惠，而是一段能夠配合停工窗口的技術支持。

午飯時，採購部有人提到幾個月前那段忙亂的日子。那時他們最怕聽見提示音，生怕又有一項看不完的材料等著批准。有人索性在手機上一次處理許多確認，直到後來發生了供應商報價資料過期、項目暫停卻仍推進付款，以及報價沒有及時反映交期變化的事情。現在回頭看，那些失誤並沒有教會公司一個神奇的方法，卻慢慢改變了他們對工作的理解。過去他們把認真看住每一份文件當作負責，如今更願意把有限的精力花在有判斷價值的地方，同時確保已經說清楚的限制真正得到遵守。

那個收到錯誤報價、隨後把當前項目優先轉向其他供應商的客戶，並沒有因為公司後來改好了制度就自動重新考慮這家公司。銷售負責人仍會想到這件事，尤其是在核對交期和服務承諾的時候。但他已不再把每一封郵件都當成一道必須憑個人小心才能守住的關。普通報價有穩定的資料來源和實際發送前的核驗，特殊承諾則需要找到能對產能、服務和商務條件負責的人。他依然可能作出不夠好的商業判斷，也可能丟掉訂單；不同的是，企業盡力不讓那些能夠明確阻止的錯誤，一次又一次憑運氣逃過檢查。

不必找到一個完美的同事

更成熟的信任，不是相信某個參與者不可能出問題，而是知道它大致能夠做什麼、被允許做什麼、做不到時怎樣求助，以及出現偏差後怎樣發現和糾正。

變化並不全讓人輕鬆。一次部門交流中，一位年輕員工問技術負責人：“如果機器以後越來越會判斷，我們是不是隻剩下處理麻煩事？”他問得認真，並不是要給新系統挑毛病。起初，AI 接走了整理表格的工作，大家覺得省事；後來它又能比較合同、判斷常規申請、給出運營建議。一部分熟悉的勞動正在改變，有的人因此獲得更多做判斷的機會，也有人擔心自己的經驗會慢慢變得不值錢。

技術負責人沒有拿一句“人永遠比機器重要”來安慰他。對某些重複而繁雜的任務，機器確實已經做得更快；將來在某些專業分析和具體判斷上，它也可能長期表現得比某些人更好。企業沒有理由為了證明人的優越而故意不用這些能力。經營者補充說，工作變化並不意味著所有員工都會自動得到更好的崗位，公司還得考慮培訓、職責調整和因自動化產生的實際影響。建立執行約束，可以幫助重新安排機器的行動範圍，卻不能替企業解決勞動分配、收入與成長機會這樣的問題。

採購主管想起自己剛入行時，也不是因為永遠不會犯錯才被允許做事。老同事教他查報價、問交期、核實供應商；主管在適當範圍內讓他試著決定，出問題再一起追究原因。那時公司沒有要求每個人在上崗前證明自己絕不出錯，也沒有因為他能獨立處理小訂單，就把銀行賬戶、所有合同和生產計劃一併交到他手裡。人類一直是在有限信任、明確分工和持續學習之中工作的。智能機器的能力不同，責任性質也不同，但組織為何需要制度，這個理由並沒有突然過時。

更成熟的信任，不是相信某個參與者不可能出問題，而是知道它大致能夠做什麼、被允許做什麼、做不到時怎樣求助，以及出現偏差後怎樣發現和糾正。員工要接受監督，主管的決定可以被複核，業務制度可以接受質疑；有能力的智能體同樣不必被關在只能回答問題的窗口裡，也不能因為曾經做對了很多次，就自動得到原先沒有授予它的行動資格。能力可以成為擴大授權的理由，卻不能在缺少正當決定的情況下自己變成授權。

幾周後，公司嘗試讓客服助手承擔更多售後調度工作。以前它只負責整理客戶需求，現在還能根據工程師排班和服務區域提出可行時間，甚至在普通服務範圍內完成預約。試運行結果不錯，一些過去必須人工來回確認的事項明顯加快了。有人提出，既然系統安排得比人工更少出錯，是否可以乾脆讓它自行調整服務範圍的限制。客服組長搖搖頭。他很認可機器的表現，卻指出了另一件事：改變服務範圍，涉及對客戶的承諾、現場人員的工作安排和公司的成本，不能因為排班算法出色，就假定這些不同方面已經同意。

這次沒有人急著把建議否決。助手確實發現舊規則裡有幾處不合理的地方：兩個距離相近的客戶被劃入不同的服務片區，導致工程師反覆繞路；某些長期合作客戶的維護窗口也沒有隨著新合同更新。客服組長請助手把情況和可能的調整方案整理出來，交給服務、銷售與財務的相關負責人討論。機器參與了發現問題和設計方案，卻沒有在討論尚未完成時，悄悄把自己的建議寫成已經生效的新規定。

討論並不總是很快達成一致。銷售部希望照顧長期客戶，服務部門必須考慮工程師在路上的時間，財務部需要判斷額外承諾會不會超過批准的資源範圍。有些要求可以通過改善排班同時滿足；有些則必須承認存在取捨。最後作出怎樣的安排，取決於各方依照公司制度具有的職責和權利，而不是哪一個部門嗓門更大，也不是讓所有參會人員機械地各投一票。某項必要條件若涉及特定主體的正當權利，也不能僅憑其他人贊同就當作已經獲得了它的同意。

方案確認以後，技術團隊才把新的適用範圍和生效條件落實到相關流程裡。對已經安排而尚未完成的預約，他們另外規定了怎樣處理，避免用一條新規則去掩蓋舊承諾。那位年輕員工參與了檢查，發現助手曾把一位客戶的服務地址與登記地址混在一起，於是補充了需要人工確認的條件。大家既沒有因此推翻所有自動調度，也沒有為趕著上線而忽略這個問題。機器幫助組織識別了不一致，人也通過實際經驗發現了機器沒注意到的事情。

這段經歷讓他對自己的工作有了另一種認識。他過去覺得自己越來越像一名給機器收拾殘局的人，如今開始理解，分析例外、核實現實條件、提出改變制度的理由，也是具體的專業勞動。當然，並不是每個人都會因此感到安心；新的崗位能力需要時間學習，公司仍須承擔轉型中的管理責任。所謂人與 AI 合作，不該只是管理層在會上畫出的一張漂亮分工圖，還應當體現在誰有機會學習、誰能夠提出異議，以及承擔後果的人是否真的參與了相關決定。

規矩也要學會改變

成熟的制度不是尋找一個無所不能的好人，而是明確誰可以決定什麼、誰需要共同參與、誰有權要求程序遵守承諾。

新制度運行一段時間後，經營者發現自己收到的報告裡多了一種以前很少見的記錄：某項規則為什麼被暫時停用，某次阻斷後來為何被證明不必要，以及誰在什麼依據下批准了修訂。剛開始他看得不太習慣，總覺得既然建立邊界，就應儘量少改。技術負責人提醒他，業務本身並不會因為程序寫好了就保持不變。供應商調整供貨方式，客戶變更合同，人員離職或調崗，新的服務種類進入公司，去年合理的條件今年就可能不再適用。

但可以調整規則，與任何人著急時都能隨手取消限制，是兩回事。對一條明顯擋住正常業務的規定，員工可以提出解釋和複核請求；具備相應職責的人可以核實事實，決定是否修改；確需臨時例外，也應按照事先確定的條件處理，並留下適當記錄。反過來，一位主管即便擁有較高職級，也不應僅憑“我是負責人”就不受所有必要條件約束。成熟的制度不是尋找一個無所不能的好人，而是明確誰可以決定什麼、誰需要共同參與、誰有權要求程序遵守承諾。

助手也開始參與這類改進。它可以從已經允許使用的記錄裡發現某條限制頻繁拒絕正常申請，可以比較新舊流程造成的等待時間，也可以提醒管理員某項權限與崗位變更不再一致。它提出的建議有時比人工更早，有時也會因為缺少現場信息而偏離實際。每次出現分歧，真正值得討論的不是“機器有資格說話嗎”，而是它提供了什麼依據，哪些資料需要核實，哪些決定必須交給有權承擔治理職責的主體。聽取機器的意見，不等於把制定規則的權力無條件交給機器。

經營者曾經擔心，既然規則會變、模型會更新、員工也會犯錯，這套合作方式是不是永遠無法真正完成。後來他漸漸接受了一個不那麼令人激動、卻更適合經營企業的答案：它本來就不會像安裝一臺機器那樣，在某個下午徹底完成。企業每年都會調整崗位、預算和業務流程，從來沒人指望寫出一次永遠無需修改的管理制度。把自動化行動納入治理，也意味著長期維護、反覆核驗，並誠實承認尚未覆蓋的地方。

有時，完善控制甚至意味著主動減少自動化。一項業務連續遇到新的異常，相關信息又無法得到及時確認，公司便暫時收窄助手的處理範圍，重新由員工接手其中的關鍵步驟。等資料來源、規則和核驗辦法更明確，再逐漸放開。銷售人員起初擔心這會影響效率，後來發現，能在不確定時退回來，比明知道條件不清楚還硬著頭皮繼續，更容易贏得同事與客戶的理解。自動化範圍應當隨著實際保證能力變化，而不是隻能越擴越大。

它也並不是一把能衡量所有事情的尺子。有一次，兩份供應商方案都滿足公司已經確認的採購條件，一份價格稍低，另一份交貨更有彈性。助手認為前者綜合成本更優，採購主管卻擔心下一季度的生產安排會發生變化。他們討論之後選了後者。後來需求沒有變化，回頭看前者或許更省錢。沒有人因此說規則失效，也不能證明主管的判斷一定比機器更高明。制度能夠要求決定在特定範圍內進行，卻未必能預先確定所有選擇的商業優劣。

經營者越來越願意把這種不確定性擺在桌面上。員工的專業判斷值得尊重，也應接受質疑；模型的建議可能非常有價值，也需要知道它依據什麼；執行控制能夠在已經明確、實際覆蓋的條件下阻止一些不合格行動，卻不能保證每一項被允許的決定都正確。企業遇到的法律爭議、倫理選擇與不同人的利益衝突，更不可能僅憑一次技術檢查就得到公正解決。這些問題需要組織治理，也可能需要行業規則、公共制度和社會討論參與。技術能幫助人承擔更多工作，不能替人把所有關於應當怎樣生活的問題回答完。

他想起公司剛接入 AI 時，最願意展示的是處理速度和節約了多少人工時間。如今他仍然看這些數字，卻也關心另外一些不那麼好看的事實：員工是否有辦法指出一條不合理的限制，出現誤判能不能解釋清楚，規則調整會不會影響已經作出的承諾，以及一項新功能開通後，原來的控制還有多大範圍有效。這些問題沒有統一的漂亮分數，也很難做成令人興奮的演示，但它們慢慢成為公司日常管理的一部分。

不久前，客戶服務部門把一次特殊預約爭議帶到了月度業務會上。客戶認為自己的合同應當獲得優先服務，內部資料卻沒有找到足夠明確的依據。助手提出了兩種可能解釋，並提醒有一份補充協議尚未核實。客服組長沒有要求系統自行挑一個“最合理”的答案去執行，也沒有讓客戶一直等待到所有人下次開會。他請銷售負責人儘快找出簽署記錄，服務部門先提供能夠確定的普通支持，再由有權限的人處理額外承諾。客戶未必會對每一步都滿意，但企業至少能解釋哪些事項已經決定，哪些仍然需要確認，為什麼不能把不確定當作已經同意。

那個沒有消失的瞬間

一個傍晚，採購主管準備離開辦公室，路過銷售區時，看見銷售負責人還在核對一份客戶要求臨時改期的合同。助手已經把修改條款和前後差異整理好了，涉及正式交貨承諾的地方清清楚楚。生產部門尚未確認新的排期，文件因此不能按原計劃發出。銷售負責人正在電話裡與對方商量一個可能接受的替代日期。他沒有對著屏幕反覆點擊，也沒有把工作全部扔給系統；真正需要談妥的事情，仍然留在他手上。

採購主管停下腳步，想起早些時候他們為了趕進度，常常希望某個人能在最後一刻替所有事情負起責任。那時一個按鈕總讓人既依賴又不安：按下去，流程便能前進；不按，別人又會抱怨耽誤。後來他們才知道，那次猶豫裡其實擠著許多不同的問題——信息是否可信，誰有資格同意，哪些必要條件已經滿足，以及真正做出去的是否就是此前確認的事情。人不可能總在疲勞中把這些問題一次想全。

現在，部分日常操作不再需要人伸手去按最後那個按鈕。機器可以自己整理，可以在被允許的範圍內判斷，也能讓一些普通工作及時完成。有些行動在條件不足時會停下來，把理由交還給相關崗位；有些商業選擇即便條件齊全，仍要留給懂得客戶、產品和現實後果的人作決定。企業也還會碰見新的錯誤，新的爭論，甚至新的損失。沒有哪一天會宣佈，從此人和機器都不會再犯錯。

銷售負責人結束通話，拿起桌上的水杯，對採購主管說，客戶接受了一個新的討論時間，明天還得與生產一起確定最終方案。他臉上並沒有特別興奮的神色，只像處理完了一件普通而麻煩的工作。兩人關了燈，一起走向電梯。辦公室裡的其他電腦還亮著，一些助手正在繼續準備第二天的材料。沒人需要專門留下來守著它們，但也沒人把公司明天可能發生的一切都交給它們自行決定。

電梯門合上前，採購主管回頭望了一眼。他知道，明天早上的咖啡機依舊不會很快，新的報告卻可能已經準備好了。那些不會下班的新同事還會越來越能幹，也仍然有犯錯的可能。而真正值得他們繼續做的，不是永遠跟在機器身後，也不是尋找一個終於可以完全放手的時刻。是讓人的經驗、機器的能力與可以被質疑和修正的制度一道工作，讓每一次改變現實的重要行動，都儘可能經得起正當的約束與檢驗。

讓智能自由思考，讓執行受到約束。這並不意味著把未來關在一道永遠不動的門裡，而是讓人類在與不完美的智能同行時，仍然有能力認真決定哪些門應該打開，哪些門必須關上，以及當世界改變以後，誰有資格重新商量那道門的位置。

---

附錄 A　核心概念與術語釋義

本附錄幫助讀者回顧書中反覆出現的關鍵問題：機器能夠做什麼，誰有資格同意，哪些條件應當在現實行動發生前得到滿足，以及制度怎樣真正約束行動。它不是技術實現手冊，也不替代各章的故事與討論。

帶有 C 編號 的條目採用《執行控制工程術語規範》v0.1 的正式名稱、英文對照和最小定義；“在本書中”提供故事中的理解方式。沒有 C 編號的條目，是本書採用的表達，不表示它們另有獨立的規範概念編號。

正文以連續故事講述問題；本附錄供閱讀後查閱，不要求讀者在閱讀故事前先記住這些術語。

從智能體的想法到現實行動

智能體（Agent）

本書指能夠在一定工作流程中接入資料、調用工具並連續處理任務的 AI 系統。智能體可以整理報價、準備客戶答覆或推動部分允許的業務操作，但能完成任務不等於可以自行決定所有真實行動。

關聯閱讀：序言、第1—3章；貫穿全書。

不完美主體（Fallible Subject）〔C003〕

規範定義： 不完美主體是能夠理解、判斷、授權、調用、控制或執行 Action，但其未來判斷不能被假設為始終正確的主體。

在本書中： 一筆錯誤報價未必出自惡意。員工會遺漏信息，智能體也可能使用過期資料，因此制度不能建立在某個參與者永遠正確的假設之上。

關聯閱讀：第3章、第15章。

意圖（Intent）〔C002〕

規範定義： 意圖是對希望發生之 Action、對象、參數、條件或結果的表達。意圖即使真實、明確並具有來源，也不能自動推出最終執行或現實結果正確。

在本書中： 助手可以提出“向客戶承諾四周交付”的行動設想，但提出這個設想，不表示公司已經認可，也不表示郵件應該被正式發送。

關聯閱讀：第8—11章。

執行（Execution）〔C001〕

規範定義： 執行是使一個 Action 從表達、判斷與承諾進入現實狀態變化的上位過程。

在本書中： 正式報價發出、付款發生、設備狀態改變，都屬於會帶來現實後果的行動。生成文件或通過一次審核，不能直接視為已經完成現實執行。

關聯閱讀：第10—11章。

執行縫隙（Execution Gap）〔C004〕

規範定義： 執行縫隙是 Intent、理解、判斷、授權或表示與最終現實執行及結果之間可能產生偏差的系統性空間。

在本書中： 被審核的是六週交期的報價，最終發出的卻可能是四周交期的版本。局部檢查正確與現實結果正確之間，可能仍然留有距離。

關聯閱讀：第7—9章。

能力、審批與行動資格

審批權

第10章對這一表達的解釋是：誰有資格對某項事務給予必要同意。它有明確的崗位、對象和適用範圍；批准一份報價，不等於批准事後改動的另一份。

關聯閱讀：第10章。

授權（Authorization）〔C005〕

規範定義： 授權是判斷主體是否被允許擁有或使用某類能力的資格邊界。授權成立不代表一次具體 Action 在當前狀態、參數和邊界下必然應該執行。

在本書中： 銷售人員能夠代表公司聯繫客戶，不等於可以承諾任意價格和交期；某項審批已經取得，也不表示變更後的報價自動獲得許可。

關聯閱讀：第8—10章。

執行能力（Execution Capability）〔C007〕

規範定義： 執行能力是主體、組件或路徑使某類現實 Action 實際發生的能力。

在本書中： 員工能使用郵箱發信、財務人員能操作付款系統，屬於實際行動能力；這不自動證明該次正式報價或付款具有正當資格。

關聯閱讀：第10—11章。

事實執行能力

第10章指誰在技術上有辦法促成行動發生。例如，員工能夠用郵箱發送文件，卻不表示其有權代表公司發出未經確認的正式承諾。它與上文“執行能力”相關，但更強調“實際上有辦法操作”這一事實，不能因此推斷本次操作已獲准許。

關聯閱讀：第10章。

正當執行權

第10章將其界定為：依據組織的正當制度和當前適用條件，誰有權限讓這一項具體行動進入執行。這裡強調組織制度賦予的當次行動資格，不直接等同於某個具體控制環節輸出允許或拒絕的最終裁決權。

關聯閱讀：第10章。

執行准入

本書在第10章提出的具體問題：行動準備真正進入執行階段時，按照當前有效的制度、授權和必要約束，它是否具備繼續的資格？有歷史審批記錄，不表示當前對象、條件或權限變化後仍應放行。

關聯閱讀：第10章；第11章繼續使用。

狀態（State）〔C011〕

規範定義： 狀態是在特定時點，與某次 Action 能否被判斷和執行直接相關的事實與條件集合。

在本書中： 付款排隊期間，原審批人員可能已經調崗；報價確認之後，交期或文件版本也可能改變。執行時所依據的狀態必須與當次行動有關。

關聯閱讀：第10章、第14章。

讓限制真的管住行動

執行控制（Execution Control）〔C017〕

規範定義： 執行控制是當具體 Action 即將改變現實狀態時，基於當前 State、參數、Authority、Policy、Boundary 與 Evidence，判斷該 Action 是否仍滿足執行條件，並使該判斷能夠真實約束現實執行。

在本書中： 業務系統標出“已檢查”還不夠；正式提交或發送的受控路徑，必須實際受相關條件約束。

關聯閱讀：第11章、第14—15章。

執行控制層（Execution Control Layer）

第11章對企業應當建立的控制職責所作的組織性概括：讓適用的執行准入條件作用於具體行動，並使不符合條件的受控操作在相應範圍內被阻止。它不必是一套獨立軟件或集中設備；其意義是控制關係有效成立，而非產品外觀。本書用“層”組織這些控制職責，而非指定一種部署形態。

關聯閱讀：第11章；第13章。

執行前控制（Pre-Execution Control）〔C018〕

規範定義： 執行前控制是在現實副作用發生之前，依據當前 State、Policy、Authority、Boundary 和 Evidence 決定 Action 是否可以繼續，並能夠真實限制、延遲或拒絕執行的控制形式。

在本書中： 正式報價發送前，應核對將要發送的實際文件及其當時有效的條件；檢查之後若關鍵內容變化，就不能繼續使用舊的通過結果。

關聯閱讀：第11章、第14章。

執行邊界（Execution Boundary）〔C019〕

規範定義： 執行邊界是在 Action 成為現實之前，對其狀態、參數、資格和允許結果進行最終約束，並能夠真實允許或阻止現實副作用的邊界。

在本書中： 書中反覆出現的“最後一道門”指向此類要求：應當能在真正改變現實之前擋下受控範圍內不符合必要條件的行動。

關聯閱讀：第9章、第11章、第14章。

邊界獨立性（Boundary Independence）〔C020〕

規範定義： 邊界獨立性是一個控制邊界的成立不依賴於其所約束主體能夠同時關閉、重寫或繞過該邊界的性質。

在本書中： 把檢查頁面放在另一套軟件裡並不夠。如果同一受約束路徑仍可隨意改寫條件或繞行，控制就可能只是形式上的分開。

關聯閱讀：第9章、第11章。

安全失敗（Fail-Secure）〔C023〕

規範定義： 安全失敗是在必要執行條件、State、Evidence 或 Boundary 無法被充分證明時，不允許系統把不確定性轉化為現實執行的上位執行語義。默認方向是收縮執行能力，而不是擴大執行許可。

在本書中： 必要權限狀態暫時讀取不到時，不可把“無法確認”當作“已經允許”；應有明確的停止、說明及受管理的恢復或例外程序。

關聯閱讀：第14章。

信任、證據與制度更新

信任（Trust）〔C013〕

規範定義： 信任是在特定執行判斷中，系統允許某個主體、組件或事實來源承擔某類判斷作用的有限假設。

在本書中： 允許員工和智能體承擔工作，並不意味著信任可以無限擴張。企業仍應明確任務範圍、複核辦法和異常時的處理路徑。

關聯閱讀：第9章、第15章。

證據（Evidence）〔C021〕

規範定義： 證據是能夠支持關於執行前條件、執行判斷、邊界狀態或執行結果之可驗證事實的材料。

在本書中： “已通過”的系統記錄只能證明某次檢查發生過，不能單獨證明客戶實際收到的附件就是已核驗的那一份。

關聯閱讀：第9章、第14章。

治理（Governance）〔C022〕

規範定義： 治理是決定執行規則、角色、閾值、狀態及其變更與恢復條件的受約束過程。治理可以改變未來執行邊界，但不等同於每一次現實執行。

在本書中： 誰有資格制定折扣上限、調整付款條件、批准必要的例外，屬於制度治理；它與每次由誰點擊發送或付款不是一回事。

關聯閱讀：第10章、第13—15章。