2026年10月7日 · 平台 · 技術文章

平台更新：小改自動，大改停下來等人

平台、服務、應用三層各自鎖定版本，用訂閱說明要收哪個頻道；更新一層一層往下走，回饋一層一層往上走。

AiTOM閱讀約 6 分鐘

重點摘要

想像你用的一套工具每週都在改版。有時候是修了錯字，有時候是多了一個新功能，有時候是某個欄位的格式整個換掉。前兩種你大概不在意，第三種卻可能讓你手上正在跑的案子突然對不上。

一個會持續進步的平台，一定會遇到這個難題：改得太慢，大家用的都是舊東西；改得太快，下游的服務和案子跟著壞掉。這篇文章說明我們怎麼讓平台的更新「小改自動流下去，大改停下來等人」。重點不在於讓更新變慢，而在於讓每一次更新都知道自己會碰到誰、出了事能退回哪裡、什麼時候該把決定交還給人。

我們把系統分成三層。最底下是平台：共用的標準、腳本、進出的門，以及一份所有人都要遵守的協定。中間是服務：建在平台上、研發成服務與產品的那一層。最上面是應用：實際拿來用的場景，例如公司自己的版本，或給客戶的版本。

每一層都明確寫下自己要跟哪個版本、哪個頻道。這份設定就像一張訂閱單：平台發新版時，系統照著訂閱單決定要不要送、送給誰。平台本身也分頻道發版，從開發中、試行到穩定，越往後越可靠，下游可以自己選要跟哪一個。

分層的好處是各管各的。平台改了，不代表服務和應用必須同時跟著改；每一層都可以照自己的步調，在確認沒問題之後再往前。反過來，某個應用出了狀況，也不會牽動整個平台。層與層之間只透過版本和協定對話，彼此不必知道對方內部怎麼做。

回饋的方向剛好相反。使用中發現的問題，如果是通用的，就回報給平台改進；只屬於某一家公司的設定，留在那家公司自己的設定裡；只屬於某個產品的，留在產品自己。分清楚回饋該去哪裡，平台才不會被某一方的特殊需求拖成一團。

新版來了，該不該自動套用？我們發現，與其看改動「大不大」，不如問一個更精確的問題：「這次改到我依賴的格式了嗎？」

回答這個問題的，是貫穿平台各層的那份協定。它規定了資料長什麼樣、編號怎麼編、事件怎麼記、權限怎麼算。協定本身不負責觸發更新，它負責把關：拿新版和下游正在依賴的格式比對。只修了錯、或只是新增東西，舊的用法完全不受影響，就讓它自動流下去；一旦改到了下游依賴的格式，就停下來。

發版：平台先通過自己的測試，打上版本號，發出一則新版事件，送給那個頻道的訂閱者。
看訂閱：沒有訂閱這個頻道的，不受影響，到此結束。
協定比對：有訂閱的，就比對這次有沒有改到自己依賴的格式。
小改先試用：沒改到的，先在一到兩個案升級試用。正在交付中的客戶案，只收安全修正，不收其他變動。
健康檢查：試用的案子要通過健康檢查，包括讓不同的 AI 工具各自從零開始接手一次，確認找得到平台、讀得懂規則。通過了，其他案才跟著升級；失敗了，一鍵回退到舊版。
大改停下來：改到依賴格式的，不自動套用，而是列進待決清單，附上遷移步驟，等人回「可」才進入試用。

為什麼只先試一兩個案？因為試用的目的，是在影響最小的地方先看見問題。一兩個案足以跑過真實的流程，出了狀況也只需要回退這一兩個。等它們順利跑過一段時間，再讓其他案跟上，風險就被切成了很小的一塊。

正在交付的客戶案又更謹慎一些。對客戶來說，交付期間最重要的是穩定，新功能再好也可以等交付結束再收。所以這段期間只接受安全修正，其他更新都先排隊。

每一步發生了什麼，都寫進只能追加的事件紀錄，每個案的版本鎖定也保留完整歷史。萬一某次更新漏接了，每天的例行檢查會再補一次，不會因為一則事件沒送到就永遠停在舊版。

更新不會一次灌進所有地方。平台升級並通過檢查後，才通知服務；服務升級並通過檢查後，才通知應用。這樣即使某一版有問題，影響也會被擋在最上面那一層，不會一路擴散到正在給客戶用的地方。

另一個原則是不追溯。新版平台帶來的型態結構和預設，只用在之後開的案；已經在跑的案子，保留開案時那一版的結構。可以安全轉換的欄位格式，會附上遷移步驟一起處理，但不會趁機改寫舊案的骨架。

回退之所以能做到一鍵，正是因為每個案的版本鎖定都有完整歷史。系統知道它升級前跟的是哪一版，退回去只是把訂閱單改回上一行，而不是靠人憑記憶去還原。可以放心退，才敢放心試。

就算每一次更新都安全，改得太頻繁一樣會讓人跟不上。所以除了管線，我們也替「什麼時候能改什麼」定了節奏：

節奏的意義在於讓人可以預期。你知道平日不會有大改突然出現，也知道想提的改動該在什麼時候提。系統在變好，但不會讓人每天醒來都要重新認識它。

小改讓它自己流下去，大改一定停下來等人。