[AI未來已來-2] 規則是黏合劑，拆它需要什麼

上一篇我們講了一個現象：AI的能力到位了，成本也崩了，但絕大多數企業就是搞不出成果。一百年前換了電動機但沒改廠房的工廠，和今天買了大模型但沒動組織的企業，本質上是一回事。

但這只回答了「發生了什麼」，沒回答「為什麼這麼難改」。

廠房為什麼不動？傳動軸為什麼不拆？不是因為老闆懶，不是因為工程師笨。是因為那套傳動軸和皮帶系統不是一堆散裝零件，而是一套彼此咬合的規則。你動一根軸，就得動整條生產線。

要理解這件事，我們得先把「規則」這個東西拆開來看。

多倫多大學的阿維·戈德法布（Avi Goldfarb）和他的兩位合作者在《權力與預測》這本書裡，提出了一個看似簡單實則深刻的框架。他們說，任何一個決策都可以拆成兩個部分：預測和判斷。

預測回答的是「會發生什麼」。明天會不會下雨？這個客戶會不會買？這張廣告素材的點擊率會是多少？

判斷回答的是「該怎麼做」。下雨了要不要取消活動？客戶可能會買要不要追加預算？點擊率低要不要換素材？

預測是填補未知資訊，判斷是權衡不同結果的價值。在人的腦袋裡，這兩件事是綁在一起的。你看了天氣預報（預測），決定帶不帶傘（判斷），整個過程一氣呵成，你甚至不覺得自己做了兩件事。

但問題在於，預測是昂貴的。不是金錢上的昂貴，是認知上的昂貴。你要預測一個客戶會不會買，你得看數據、跑報告、憑經驗做判斷。這件事費腦子、費時間、費精力，而且容易出錯。

所以人類發明了一個工具來降低預測的認知成本：規則。

規則是什麼？規則就是把預測的結果提前固化下來，變成標準流程，以後不用每次都重新預測。你不知道哪個客戶會買，所以你定一條規則：每月消費超過一定金額的客戶歸為VIP，享受專屬服務。你不知道哪條廣告素材效果好，所以你定一條規則：每條素材跑三天，點擊率低於行業平均就換掉。

規則的好處很明顯。第一，降低認知成本，你不用每次都從頭想。第二，提高可靠性，不同的人照著規則做，結果至少不會差太遠。一個組織之所以能穩定運轉，就是因為有大量規則在代替員工做預測。

規則的好處說到這裡。但戈德法布他們真正要講的不是規則有多好用，而是規則有多難拆。

戈德法布他們用了一個精確的比喻：規則是系統的「黏合劑」。你定了一條「所有客戶投訴24小時內回覆」的規則，這條規則就把客服、技術、物流三個部門的決策黏在了一起。客服接到投訴，技術排查問題，物流補發商品，三件事必須在24小時內協調完成。規則把相互依賴的決策黏合在一起，讓整個系統穩定協作。

外科醫生阿圖·葛文德（Atul Gawande）在《清單革命》裡講過一個故事。1935年，美國陸軍在選新一代轟炸機。波音公司的299型飛機性能遠超對手，能攜帶五倍於陸軍要求的炸彈載荷，飛得更快、飛得更遠。但在測試時墜毀了。不是設計問題，是飛行員操作失誤。這架飛機太複雜了，一個人記不住所有操作步驟。

陸軍沒有放棄這架飛機，也沒有給飛行員更多培訓。他們做了一件更簡單的事：給飛行員制定了一份清單。起飛前查什麼、降落時做什麼，一條一條列清楚。

結果是，這架飛機安全飛行了數百萬英里，成了二戰的主力轟炸機。

清單就是規則。它把「飛行員需要記住的所有判斷」固化成了一組標準流程，降低了認知成本，提高了可靠性。從此，任何一個受過訓練的飛行員都能安全駕駛這架複雜的飛機。

但規則有一個代價。它犧牲了靈活性。

規則的本質是「不預測」。你不去預測每個具體情況，而是假設「大部分情況差不多」，用一條規則覆蓋所有場景。機場要求你提前兩小時到，不是因為每個人都需要兩小時，而是因為無法預測你具體需要多久。規則用「最壞情況」覆蓋了所有情況，安全，但浪費。

問題來了。規則這麼好用，為什麼要拆它？

因為AI讓預測變得極其便宜了。

當預測的成本高、不可靠的時候，規則是最優解。你負擔不起為每個客戶做精準預測，所以用規則代替。但如果AI能在一秒鐘內為每個客戶做精準預測呢？你還需要那條「月消費超過一定金額歸為VIP」的規則嗎？

戈德法布他們的判斷是：AI降低預測成本之後，決策會從「規則驅動」轉向「預測驅動」。以前用規則掩蓋的不確定性，現在可以用預測來揭開。

聽起來很美好。但這裡有一個陷阱，也是《權力與預測》這本書最精彩的洞察。

規則不是一條一條孤立的。它們彼此咬合。

書裡舉了一個教育的例子。假設你做了一個AI，能精準預測每個學生下一步最適合學什麼。這是一個點解決方案，在現有系統裡做一個優化。你把這個AI放進現在的學校裡，會發生什麼？

什麼也不會發生。

因為學校的整個系統是圍繞「按年齡分班」這條規則設計的。按年齡分班決定了教室的布局、課程的編排、老師的培訓方式、考試的評分標準、甚至家長的期待。你把AI預測塞進這個系統，AI說「這個學生應該跳到高三的數學課」，但系統說「他是初二的，得待在初二」。AI的預測再準，也繞不過這條規則。

書裡的結論是：想釋放這個AI的潛力，主要挑戰不在於構建預測模型，而在於把教育從「按年齡分班」這條規則裡解放出來。而這條規則，目前把整個系統緊密地黏合在一起。

你動一條規則，就得動教室布局、課程編排、老師培訓、考試標準、家長期待。你動一條，就得動一串。

這就是規則的黏合性。它不是牆上的一張紙，你撕下來就行了。它是黏合劑，把整個系統黏在一起。你要拆它，就得把黏在一起的所有東西都拆開重新組裝。

回到我自己的經歷。

上一篇講了CMO工具開發的新流程：我跟AI先完成初版，上傳到GitHub，後端工程師拿到版本後再拆解重構。這套流程比傳統的「規格書→工程師」高效得多。

但當這套新流程撞上組織的舊規則，阻力以三種形式出現。

傳統的開發流程裡，安全審查有一套現成的規則：程式碼由工程師提交，經過code review，通過測試環境驗證，再上線。每一個環節都有人負責，每一個步驟都有文檔記錄。但在我們的新流程裡，產品經理直接寫了程式碼上傳GitHub，工程師在這個基礎上做重構。安全審查應該在哪個環節介入？審什麼？誰來審？產品經理寫的程式碼要不要經過和工程師一樣的審查標準？

這些問題在舊規則裡都有答案。但在新流程裡，每一個都是空白。

但在新流程裡，產品經理也寫程式碼了。那工程師的角色是什麼？從「寫程式碼的人」變成了「拆解和重構程式碼的人」。這不是微調，是角色的重新定義。工程師的價值從「實現需求」變成了「架構設計和品質把關」。

但組織的分工規則沒有跟著變。薪資結構還是按「工程師比產品經理高一級」的邏輯定。績效考核還是按「你寫了多少程式碼」的邏輯算。職涯路徑還是按「工程師→技術主管→技術總監」的邏輯走。

產品經理寫的程式碼算不算正式產出？如果出了問題誰負責？工程師重構了產品經理的程式碼，功勞算誰的？這些問題在傳統分工裡有現成答案，在新流程裡全是新的。

但在傳統的控管規則裡，模組的優先級排序屬於產品經理的職權範圍。產品經理說先做哪個就做哪個，工程師照著執行。但在新流程裡，工程師在技術架構層面做了優先級判斷，而且這個判斷是對的。可是從控管角度，這就出現了一個模糊地帶：技術架構的決定權到底在誰手裡？

傳統規則說在產品經理手裡。但產品經理不懂底層架構，他做不了這個決定。工程師做了這個決定，但組織沒有給他這個授權。

你看，安全、分工、控管，這三道關卡不是三個獨立的問題。它們是三條彼此咬合的規則。安全規則依賴分工規則（誰負責什麼決定了誰來審查），分工規則依賴控管規則（職權劃分決定了產出歸屬），控管規則又依賴安全規則（控管的目的是為了安全）。你動一條，另外兩條就跟著鬆動。

這就是規則的黏合性在實踐中的真實面貌。你以為你在拆一堵牆，其實你在拆一整棟樓。

《權力與預測》裡有一組概念，正好能解釋這個困境。

書裡把AI的應用分成兩個層次。一個是點解決方案，在現有系統裡做局部優化，不改變系統本身。另一個是系統解決方案，推翻既有規則，重新設計整個系統。前面講的三道阻力，本質上就是從點解決方案往系統解決方案走時會撞上的東西。

點解決方案的特徵是「強化既有系統」。你給銷售團隊裝一個AI推薦工具，幫他們篩選潛在客戶。銷售流程不變，分工不變，控管不變，只是多了一個工具。這種東西好推廣，因為不動規則。

系統解決方案的特徵是「推翻既有系統」。你不再用「銷售員逐一打電話」這條規則了，你重新設計了一整套從AI預測到自動觸達到人工跟進的流程。分工變了，控管變了，安全標準變了。這種東西極難推廣，因為要動規則。

我們的CMO工具開發流程，本質上已經是一個系統解決方案的雛形。產品經理的角色變了，工程師的角色變了，分工邏輯變了，控管方式變了。但組織還在用點解決方案的方式對待它：把它當成一個新工具，插進舊系統裡，希望它自己跑起來。

這就像你把一台新引擎塞進舊車架，引擎轉了，但變速箱、傳動軸、輪胎全是為舊引擎設計的，力量傳不出去。

戈德法布他們說了一句很準的話：點解決方案強化既有系統，系統解決方案推翻既有系統。而推翻既有系統之所以難，是因為規則是黏合劑，它把整個系統黏在一起，你拆一條就牽動一串。

所以下次你看到一家公司說「我們已經在用AI了」，你可以問一個問題：他們是在舊規則上插了一個新工具，還是重新設計了規則？

不是AI不夠強。是絕大多數企業把AI當成了點解決方案，插進舊系統裡，希望它自己跑起來。但AI真正能創造價值的地方，是需要推翻舊規則的地方。而推翻舊規則，意味著拆掉黏合在一起的整個系統，重新設計。

這不是技術問題。這是組織問題。

但組織問題說到底，是人的問題。規則是人定的，規則背後是人的利益、人的恐懼、人的邊界感。你拆一條規則，就有人在問：那我以後算什麼？