星期四下午，是 AI Tool Platform 固定的 Release Window。

平台團隊發布了三支工具。Security Review、權限、Schema Validation、Regression Test、文件與舊版相容性都已完成，Dashboard 一片綠燈。

其中一支叫作 escalation_analysis_tool。

它的功能很簡單：客服輸入 ticket ID，工具回傳 recommended_team，告訴使用者案件應該交給哪個團隊處理。

同一時間，客服營運團隊正在測試另一個尚未上平台的 Workflow。

前一週，這個 Workflow 的名稱是 Find Escalation Owner。實際跑過幾筆重大客訴後，團隊發現「找 Owner」不是整件事。

有些案件同時牽涉產品、帳務與區域營運。他們真正要先判斷的是：誰負責第一時間回覆、誰有補償決策權、還缺哪些證據、多久後必須升級主管。

兩天後，Workflow 改名為 Prepare Escalation Case。輸出也改成一份處理建議，而不是一個團隊名稱。

平台上的 Tool 此時還是舊版本。下一個 Release Window 在三週後。

平台沒有慢，現場是在學習

客服團隊提出 Change Request：把 recommended_team 改成回覆責任、決策責任、支援團隊與升級期限。

平台工程師回覆這會改變 Output Schema，屬於 Breaking Change。要開 v2、保留 v1、準備差異說明、Regression Case 與 Migration Plan。

流程本身沒有問題。正式工具一旦有人接入，不能任意改掉介面。

但產品經理問了一句：「現在有 Client 在用 v1 嗎？」

答案是沒有。

而客服團隊很快又發現，部分重大案件根本沒有明確的 Decision Owner。問題不是找出哪個人，而是辨認案件缺少哪一種決策權，再把它送到具備那項權限的角色。

v2 還沒開始測試，原本想固定的欄位又變成暫時答案。

這不是需求方反覆無常。團隊每多跑幾個案例，就更清楚自己原本把哪一段工作想得太簡單。

探索期的規格變動，常常就是這種學習留下的痕跡。

太早發布，會讓錯誤答案變得很難改

一支 Tool 進入正式 Registry 後，名稱和 Schema 會出現在文件、架構圖與其他團隊的整合計畫裡。之後每一次修改，都要連同相容性、版本、權限與支援責任一起處理。

於是討論的重心很容易改變。

原本應該問的是：recommended_team 是否真的是使用者需要的結果？

上平台後，團隊卻開始想：如何保留 recommended_team，再附加更多欄位，避免破壞既有 Schema？

舊欄位即使失去意義，也會因為已經被發布而被留下。新的理解只能往舊介面上堆。

這和 Prompt 一直補規則很像；差別是平台裡的錯誤假設，還會連同文件、監控與 SLA 一起被保護。

先把正在變的東西留在能修改的地方

客服團隊後來把這項工具移回 Sandbox。它不承諾 Schema 相容，也沒有 SLA；團隊只持續保存每筆案件中的人工修改、被拒絕的建議，以及反覆出現的責任類型。

六週後，原本一支大型工具拆成三段：

• collect_case_context
• identify_missing_decision
• prepare_escalation_packet

其中只有 collect_case_context 被其他部門以相同方式使用。它的輸入、輸出與查不到資料時的處理，連續一個月沒有重大調整。

這一項才重新進入正式平台。

另外兩段仍留在客服 Workflow 裡，因為它們依賴客訴政策、授權層級與部門處理方式。把它們放進共用平台，只會太早把仍在理解中的工作固定下來。

平台化不是能力第一次出現的時間點。

它是團隊已經能說清楚：這份工作會反覆出現、第二個使用者能照同樣方式完成、而且現在開始承擔版本與治理成本是值得的。

下一次 Release Window，平台只發布一項 collect_case_context。

Dashboard 的新增數量少了。但第一個外部團隊沒有客服工程師協助，也完成了案件資料整理。

工具每天都在改，不一定表示流程失控。有時候只是它還在長成一份真正可以被組織承諾的工作。