跨部門資料規格兜不攏時，不要急著統一規格，而是要先有一份彼此看得懂的合約
這是最近的例子，幾個部門想做一個中央資料庫，當作核心來讓 AI 據此交換資料，所以大家開始談一個大一統的資料庫規格，跟理論物理界一樣，希望有個可以一勞永逸的解決方案，這聽起來很合理，畢竟要開個共用資料庫，先說好要怎麼放通常是第一步，但問題也出在這，對於資料該怎麼被處理跟傳遞，大家都有自己的想像，所以吵來吵去一直沒有定案，如果你處理過跨部門專案，對這種場景應該不陌生，畢竟單獨部門的想法都說得通，但是全部疊在一起的時候，就會發現這像好幾張比例尺不同的地圖，怎麼對都對不齊。
這時候，一定會有一個躲在角落的小咖會被老闆交付這個任務(對，吵不完的東西最後總會落到某個人頭上，比如我)，而我的回答並不是直接給資料庫規格，而是：每個部門都可以有自己的規格，但我們需要有一個共同的語言，也就是合約， 這樣才能讓大家理解彼此在做什麼、哪一份資料代表什麼意義，以及可以去哪裡存取。
這跟規格有哪裡不一樣？為什麼不乾脆給一份規格就好？說實話，如果我也丟一份規格出去，充其量只是桌上多了一張比例尺不同的地圖而已，他會成(或者最後不成)，只是因為我是負責人+老闆現在相信我，並不是因為他能解決問題，所以真的要解決問題，應該要從源頭來解決，才能更好的幫助每個部門，而這一切要先從 SOP 這個東西怎麼來的講起。
SOP 為什麼誕生，又為什麼變成累贅
當然，我不是說企業不需要 SOP 或是標準流程，從企業運作觀點來看，大型企業內部需要高度協同性以避開運作的摩擦，這也是為什麼所謂的工作流程以及 SOP 會在企業之中誕生，跨部門或跨單位協作的時候，把流程標準化跟依循 SOP 可以幫助不同部門在不需太多溝通的狀況下同時處理一件複雜的事情，有一個 SOP 把這些事情拆分為被詳細定義好的步驟與選項，可以讓需求或開發可以被有效率、快速地推進，並減少往來修改、確認的時間，這是 SOP 理想中的樣子，就是一張大家都看得懂的地圖。
但隨著企業成長，這樣的結構也隨之變大，但效率反而開始下滑，這是因為事情被複雜化跟細分化，導致流程拆得太細、確認事項太多，使得確認本身變成了一種成本，這就像地圖本身越畫越細，細到比路本身還複雜了，使用者只能每走一步就停下來對一次地圖，反而拖長了到達目的地的時間。如果你曾經為了一個小改動，就因為 SOP 反覆確認過一輪又一輪，大概懂我在說什麼，到這個地步，SOP 反而變成那個綁住企業彈性變化、也綁住個人做事手腳的原因， 失去原本的初衷，這不是因為設計有問題，而是因為它長太大了。
其實我們一直在講同一份資料
想想那些跨部門的交接，你有沒有覺得，很多資料的交換並不是真正的處理，只是我們用不同的方法在講一份同樣的資料？
這其實很自然，因為每個部門在處理工作時都需要特定訊息，所以會特化資料裡對自己重要的部分，減弱不重要的部分，在這樣的過程中，大家會生出自己的格式和流程，但其實最終，這些流程只是同一份資料從進去到出來的變形過程與流進流出，有點像同一份 Excel 在每個部門手上被另存一次新檔，這邊刪兩欄、算一算加總之後在那邊加一欄、再換個欄位名稱，最後檔名變成「最終版_修改_v3」，但打開來看，講的還是同一件事。
這也就是開頭那份資料庫規格吵不完的原因，每個部門都想把同一份資料塑形成自己要的樣子，而要大家統一成一份規格，等於要求每個部門放棄自己的特化，偏偏那些特化，正是他們各自把工作做好的方式，這樣看來，吵不出結果一點也不奇怪，大家爭的不是資料本身，是那份資料在自己手上該長什麼樣子。
先讓 AI 交換資料
AI 進入工作之後，不少團隊試著用 AI 重新定義資料交換過程，讓流程中一些已經標準化或有 SOP 的結構化訊息透過 AI 處理來加速，更進步一點的公司已經試著把這些資訊集中到中央資料庫，讓 AI 撰寫程式來做資料交換，把原本需要拆分許多步驟、靠人工確認的東西，透過讓 AI 讀取相同資料或共享同一份記憶，來減少資訊交換的摩擦，所以，以往要人工把關跟確認的步驟，會變成 AI 處理、人類把關的流程。
做到這一步，我們可以開始思考，在流程的一開始有一個所謂的「AI 資料合約」來定義整體的大框架，讓 AI 自主進行資料的變形或交換，把這個過程交給不同的 AI 來協同，甚至不同部門的不同 AI 直接讀同一份資料，並擷取各自需要的部分來處理，而不需要在交接過程中，一直重新把資料塑形成每個部門要的樣子，就像是我們的資料都回到同一份 Excel 的不同欄位，不再另存新檔，大家打開同一份，各自看自己需要的那幾欄。
這件事我在 Agent Team 裡碰過一次，之前寫溝通架構的那篇講過，統一格式在異構 Agent 間沒有意義，每個 Agent 的產出結構天生不同，硬套統一格式只會逼每個 Agent 把最有價值的結構化資訊壓成一份通用摘要，所以我最後做的不是統一格式，而是一張 inspection map 和一份 Return Contract，說好去哪裡看、看什麼、回報要壓到多短，至於每個 Agent 內部怎麼長就不是重點(細節就不在這裡重講了)，而這就是我給各部門那個答案的第一層，各部門留著自己的規格，中央資料庫不需要統一規格，只需要大家都找到自己的那一塊，也就是合約。
但資料還是在原本的流程裡流動
雖然做了這樣的改變，但必須要說，這樣的改變雖然適合做知識或資料交換的架構，但其實它還是在原本的流程之中流動， 資料不用再被重新塑形了，可是流程本身還是那條流程，上游交給下游，第一關結束之後到第二關，AI 讓每一關的交接變快，但關卡還是一樣，流程還是一樣。
這讓我想到我們用 AI 的這幾年，剛開始用 AI 寫程式時，我們會人工在每一個階段檢查 AI 的輸出跟輸入，接著我們定義 AI 怎麼樣用規格來驗收他自己的產出、要參照什麼樣的文件，而在 AI 發展了兩三年後，現在用 AI 做程式開發，已經變得更像是定義最後結果的框架，以及我們怎麼樣確認這個結果是可行的，中間所有開發的流程跟檢驗已經讓 AI 自主規劃且自主進行，反而沒有所謂 SOP 的概念。
回到 AI 的資料交換上，我想也是時候讓企業走向下一步，用 AI 去流程化／客製化， 我們不必再去在意流程或步驟應該依照什麼樣的順序、方式或定義進行，而是要去定義輸入與產出的資料結構合約，在中間設定幾個檢核點，只要這幾個檢核點的架構合約或輸出驗證結果符合定義，中間的步驟與流程怎麼進行，我們不需要一步一步去管。
流程消失了嗎？沒有，只是不再由我們定義而且一步一步定下來，因為流程不是重點，合約才是，(這句話有點眼熟？對，之前寫〈架構不是重點，Context 才是〉的時候用過一樣的句型，這次輪到流程讓位)。
這個想法我在自己的工作目錄小規模試過一次，前幾天盤點下來，資料散在好幾個地方，同一批對話紀錄被複製了好幾份，同一套 skill 給 Claude Code 和 Codex 各放一份，十幾個共用 skill 兩邊全部長得不一樣。
這次我沒有先寫分類 SOP，只定了五個分區各一行的規則，加上每個檔案的 YAML 檔頭格式，這是合約，再加一個 index:check，這是檢核點，然後讓十幾個 Agent 平行讀了一百多個檔案，自己決定每個檔案的去處，skill 合併成一份正本之後，Codex 只讀 name 和 description，其他欄位直接忽略，Claude Code 則讀得更多，同一份檔案，兩個 AI 各取所需。
如果連流程都不固定
所以我說的客製化，並不是每個部門各做各的，而是我們連流程這件事情都沒有固定，我們只專注在最後的輸出， 合約說好進來的是什麼、出去的是什麼，檢核點守在幾個真正需要人類把關的位置，中間怎麼走，就交給 AI。
回到一開始那份沒有共識的資料庫規格，這邊合約只是第一步，合約讓各部門的資料可以互相看懂、知道去哪裡拿，但資料流動的路，還是原本那條路，這邊真正的問題不是讓大家照著同一份規格走，而是我們應該想想，當流程都交給 AI 之後，我們人類還剩下什麼需要定義、把關，而 AI 跟 AI 之間，又該用什麼樣的合約交談？
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
