當每個人的 AI 都長成自己的樣子，企業要標準化的不再是流程，而是 AI 跟 AI 之間的那份合約。
上一篇說到，企業導入 AI 之後，與其再寫一份更細的 SOP，不如定義輸入與產出的資料結構合約，在必要的地方設檢核點，中間怎麼走就交給 AI，講到最後說：「我們連流程這件事情都沒有固定的流程，我們只專注在最後的輸出」，這句話說得好像很乾脆，但流程交給 AI 之後的事，上篇沒有講完。
如果流程真的交給 AI，那企業還剩下什麼需要定義？每個部門的 AI 都長出自己的樣子之後，彼此之間又要怎麼溝通？
從寫程式到讓 AI 自己塑形：三段演進
要回答這個問題，我想先把時間軸拉開，看看我們這幾年是怎麼把一件事情交給 AI 的，如果每個階段都問同一個問題：保留多少固定，交出多少決策權？大概可以看到三個很清楚的台階。
第一段：讓 AI 寫一支程式。 最開始的做法，是用 AI 寫一支程式來解決一件事情，好處是「機械化、可控制、可固定、標準化，而且完成這個程式之後，我們就不太需要 AI 了」，AI 在這裡比較像一位外包工程師，交完件就離場，決策權幾乎全部被寫死在程式裡，缺點是程式一旦要遷移，跨作業系統、跨硬體平台、跨資料集的問題就一個一個冒出來，只好針對不同的資料集做出各式各樣的接頭(adapter)，這就是早期 API 的概念：讓一個元件處理某個任務，但事先定義好格式跟輸出入的介面。
第二段：在節點插入 AI。 再下一步的做法，是在流程的節點串入 AI，讓 AI 在一些需要模糊判斷的部分做出決策，從既有選項之中挑出正確的選項，這時候我們給 AI 的身份比較像只能勾選項的審核員，TypeSafe 在 9 月 15 日發表的 Jev 就是專門做這件事，藉以加速整個流程，他回傳的是選項、分數或帶機率的布林式答案(Yes or No)，設計給 classification、routing、scoring、extraction 這類「bounded decisions」[1]，也就是有邊界的決策，在這樣的流程設計裡，我們還是保留了大部分固定的結果，但讓 AI 加入了決策權，取代人類在某一些節點上面的功用，流程因此變得更有彈性，可以適應更多的狀況，甚至有更多的變形。
第三段：讓 AI 自己決定流程。 從去年開始，新趨勢是更加開放的讓 AI 自己決定流程，被固定下來的不再是流程本身，而是流程要達成的目標，中間要走幾步、先走哪一步、哪一步可以省略，AI 自己決定，到這一段，AI 更像一位只拿到目標、自己排工序的專案經理。
三段放在一起看，是一條決策權逐步外移的線，外包工程師寫完程式就把決策權交回給程式，審核員在我們框好的選項裡打勾，專案經理連框框本身都自己畫。
LLM Wiki：每個人的都不一樣
第三段最好的例子，大概就是目前最流行的 LLM Wiki，這個 LLM Wiki 並不是一個固定的程式架構、固定的資料庫，甚至不是固定的工具，Karpathy 在那份 gist 裡寫得很清楚：「This document is intentionally abstract. It describes the idea, not a specific implementation.」，而且「The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice.」[2]，原作者提出的只是一個讓 AI 搭建整個知識的方法論、框架與流程，他甚至直說，這份文件的任務只是把 pattern 講清楚，目錄、頁面這些就讓你的 AI 自己想辦法，也就是交給使用者，更準確地說，是交給使用者手上的 AI。
所以使用者會依照自己的情境、資料需求，以及當下使用的 AI 模型解讀，或是提供給 AI 模型的資料樣態，來決定他的 LLM Wiki 應該長成什麼樣子，我自己的 Agent Em 就是一個例子，之前談知識系統的時候提過，Em 的 wiki 套用了網路大神的方法論，從 28 頁長到 120 個檔案，方法論是借來的，但長出來的樣子是我的，那些分類、那些交叉引用，都是依照我的需求、問題、資料一次次 ingest 出來的。
這個 LLM Wiki 做出來之後，其實只是針對當下這個使用者的特化版本，今天如果換了一個人，這個 LLM Wiki 就有可能是完全不一樣的面貌。
或許你會說，這樣子資料交換性是不是會很差？這個 LLM Wiki 是不是在每個人的電腦裡面定義都不一樣？答案是肯定的，但這也就是我說的 AI 客製化。
上一篇說過，客製化並不是每個部門各做各的，這裡我想把這個詞講得再慢一點，因為「客製化」在企業裡常被當成難維護、難交接，但我說的客製化不是這個意思，AI 客製化是方法論可以共享，但每一份實作都依照使用者的情境長成自己的樣子， 這不是說沒有標準，而是設計上本來就允許、甚至鼓勵這樣的共模式但不同樣態的結果。
要標準化的是合約，不是流程
那資料交換怎麼辦？在這樣的狀況之下，我們要考慮的並不是這件事情本身有沒有被正規化、標準化或流程化；我們要考慮的是，當我們需要把資料或知識做交換的時候，這個輸出有沒有一個共同的語言， 也就是 AI 跟 AI 之間溝通的「合約」應該長什麼樣子。
這份合約可以比我們想像中的更寬鬆，因為傳統的資料規格會把格式、數值、欄位定義得清清楚楚，但如果這份合約能夠讓兩個 AI 溝通，並達成各自要做的事情，那在某些情境下，我們不必把資料該如何被定義寫死，甚至可以讓兩個 AI 自己協議出來，合約可以從資料的格式、數值、欄位，退一步到「如何讓兩個 AI 就某一個目的進行溝通」，只要目標能完成，他們究竟用什麼欄位與格式交換資料，資料又該如何被儲存與傳遞，在這個 AI 的時代並沒有這麼重要。
但牽扯到財務、法規、ISO 標準認證之類的資料，仍舊需要制定一定的規範，由人先定下來、不能交給兩個 AI 協議。
同樣的問題在 Agent Team 裡也有對應，之前從 OS 的 IPC 看 Agent 溝通時整理的五層決策模型裡，最上面那一層是 L4 Content Contract，決定的是「傳什麼」，當時我借了前同事的說法，這是目前所有系統做得最粗糙的一層，Agent 之間是這樣，我認為企業的部門之間也是，管線接通只是把資料送到，L4 決定的是對方拿到之後能不能用。
回到上一篇開頭那場沒有共識的資料庫規格，我給的答案不是一份統一規格，而是各部門留著自己的規格、大家共用一份都看得懂的合約，就是這個概念在企業這個場景裡的第一步。
所以企業導入 AI 的下一步，並不是訂出更多 AI 的標準，而是創造一份讓 AI 可以交換資料、彼此通訊的合約， 這樣才能在企業內部長出一個撐得住這份合約的 ecosystem(生態系)，所以我們要訂的是部門跟部門之間的責任義務怎麼劃分，以及每一件要解決的事情裡，AI 彼此怎麼溝通。
這樣子的概念其實是讓 AI 變成企業的主體，讓部門跟部門之間接手、交換資料的主體變成 AI，而人只守在需要把關的檢核點上。
那 AI 斷線怎麼辦？我們可以信任 AI 嗎？
當然，AI 一旦成為主體，對某些傳統 IT 人員來說，這樣以合約為中心的架構可能顯得太過激進，而疑慮也很直接：如果 AI 停止服務該怎麼辦？如果這些模型有一天無法連線，或是收費變得很貴怎麼辦？你又怎麼能信任 AI 的判斷？他出錯了該怎麼辦？
很眼熟嗎？
對，說實在的，不久前才剛經歷過類似的事情，大概 10 到 15 年前雲端剛興起的時候，也有很多人認為雲端服務不穩定，雲端服務網路斷線怎麼辦？地端資料留在自己手上才能更好地掌控，結果到了現在，已經有許多企業把整個服務架在雲端，過去我們擔心雲端中斷服務會跟著停擺，結果反而是地端網路斷線導致服務中斷，雲端則透過異地備援、跨雲主機、Edge Computing 的協助，讓服務在更完整的網路架構下提供給不同地區的使用者，展現出更強的韌性，而關於 AI 的判斷，好像就是自動駕駛的歷程一樣，從不相信 AI 會開車，到現在每天有幾百萬台的 Tesla 在路上跑(2026 年 7 月累計產量破一千萬台了)。
我覺得人類跟系統總是會找到解決方式，而且往往是用我們當時意想不到的方法實現， AI 大概也會走上同一條路，變成所謂的基礎建設，所以與其擔心 AI 斷線該怎麼辦，不如去思考斷線時我們的應對機制，我相信相關的機制很快就會發展出來，現階段自己在雲端架設算力、提供屬於自己的模型，而不是完全依賴外部 AI 模型，也是一個暫時的解決方案。
真正讓我擔心的反而是另一件事，這樣以合約為中心的架構不會等到問題發生才憑空出現，如果現在不開始佈局，之後要追趕的就不只是機房架設、AI 模型架設這樣的問題，而是整個內部的資料結構需要依照 AI 重新建設，而我們過去這幾年用 AI 打造的結構和資料，根本不是依循這樣的模式，很多東西會沒辦法直接沿用，也就是說，我們會經歷兩次到三次的 AI 再造，但這些再造是現在就應該可以討論或是發生的東西。
至於這份合約落到我自己手上會長什麼樣子，我在實戰篇拿自己做的兩個工具攤開來看，寫的是要交出什麼、怎麼檢查，而不是一步一步怎麼走。
流程可以交給 AI，但 AI 之間用什麼語言談，得由我們先定下來。
或許，這個時間點，我們該問自己的不是準備好用 AI 了沒，而是你的下一步，這一步是再寫一份更細的 AI SOP，還是寫一份讓 AI 彼此聽得懂對方的合約？
參考資料
[1] Let’s Data Science — TypeSafe Jev launch（2026-09-15；支持「the model returns choices, scores, or Boolean-style answers with probabilities.」與「Jev is designed for classification, routing, scoring, extraction, and other bounded decisions where an application needs an answer it can use directly.」）
[2] Andrej Karpathy — LLM Wiki gist（2026-04-04；支持「This document is intentionally abstract. It describes the idea, not a specific implementation.」、「The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice.」與「The document’s only job is to communicate the pattern. Your LLM can figure out the rest.」）
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
