三行 import，十四項以週計的需求：IM 介面層的造與買

未讀數、置頂、草稿暫存、歷史訊息載入、滾動位置錨定、發送狀態、撤回、引用、圖片、語音、檔案、安全區域、軟鍵盤、長按選單。把這份清單交給任何一個前端團隊，換回來的通常是一張以週計的排程表。2026 年 10 月初，掘金上一篇針對 Vue3 UIKit 的實測文章給出另一種結法：作者最初估計，替 Vue 3 專案補上聊天能力的主要工作量在 SDK 串接，登入、建連、收發訊息；需求拆完後發現，SDK 只覆蓋連線層，其餘十四項全部落在介面層，而且每一項在各家產品裡都被重做過一遍。

Vue3 UIKit 的基本盤可以一句話交代：@easemob-community/uikit-im，底層為 easemom-websdk（SDK5）的 Vue 3 元件庫，把對話列表、聊天頁、通訊錄、羣組管理、已讀回執、主題與手機版調適打包成預設元件。安裝三個套件、入口檔三個與之相關的 import，頁面上放一個掛著 app-key 的 Provider 元件與兩個容器元件，可用的聊天介面就成立。作者替這次評測訂了三個檢驗標準：接入要快、預設能力要完整、接進業務後要能改。三個標準對應到同一件事，通用工時的採購價格。

SDK 之上，業務之下

把聊天功能縱切開來，可以看到四層。最底層是連線：登入、建連、斷線重連，由 SDK 承擔。2013 年成立的環信，隔年把這層能力做成雲端服務時，賣點是訊息可靠送達。往上一層是訊息：收發、歷史、回執、多端同步，這一層十年間逐步變成制式規格，各家 PaaS 的功能表長得愈來愈像。第三層是介面，也就是那十四項需求所在，長期沒有標準答案，因為它跟著作業系統版本、螢幕規格與設計趨勢一起變動。最上層是業務：登入體系、使用者資料、權限規則、業務訊息，每家公司不同，也無從外包。

Vue3 UIKit 的定位，是把第三層商品化。文章裡有一句話把分層講得直接：三行程式碼不等於專案從此不需要開發，登入體系、使用者資料、權限規則和業務訊息仍然要接。換算成分層語言，元件庫買斷的是第三層的工時，第四層的工時原地不動。

造一次的帳，養每年的帳

先算一次性支出。十四項需求，作者的評估是每一項以週為單位，取一到兩週的區間，通用介面層的自研工時落在十四到二十八人週，摺合三到七個人月。這還只是首版。實測裡被點名的訊息氣泡有十幾種狀態，發送中、失敗重試、撤回、引用回覆，每一種都要在 iOS 的安全區域、各家 Android 的軟鍵盤行為、不同瀏覽器的滾動實作上重跑驗證，再加上斷線重連後的資料恢復，這些構成每年跟著作業系統大版本更新的經常性支出。

自研帳本還有一欄機會成本。前端產能固定的前提下，三到七個人月投入通用介面，等於同期排程裡的業務功能往後推。自製或外購決策的真實分母，向來是內部人月的完全成本。

供應商那一側的帳方向相反。同樣十幾種氣泡狀態、同一批裝置相容問題，環信只需要做一次，成本由全部客戶分攤，客戶基數愈大，單一客戶負擔的邊際維護費愈低。介面層之所以遲早會從各家公司的待辦清單，移到少數供應商的產品路線圖上，規模邏輯是主要推力。

連線層趨同之後，競爭軸上移

時間軸拉長看。2013 到 2015 年，環信、融雲、網易雲信先後成立或上線 IM 雲端服務，騰訊雲也把累積自 QQ 的通訊能力對外輸出，當時的差異化在協議可靠性與併發容量。十年下來，訊息送達、已讀回執、離線訊息、多端同步先後變成標配，SDK 層的功能表趨同，買方很難再靠底層規格分出勝負。競爭軸於是往兩個方向移動：計費端，各家多以日活或月活階梯定價，單價持續下探；交付端，從文件加 SDK，變成帶 UI 的元件庫、場景化方案與低程式碼整合。

類似的位移在其他技術市場已經走過一輪。頂尖模型分差一年縮掉八成之後，剩下的差距移往 API 牌價與封裝層。IM 中介軟體的時間尺度長得多，結構相同：底層能力變成制式規格後，可收費的差異移往整合速度與介面完成度。

對供應商而言，UIKit 的經濟意義在於縮短從評估到正式環境的距離。以活躍用戶階梯計費的模式下，客戶愈早上線，營收起算愈早；元件庫同時墊高替換成本，換掉一個 SDK 要重寫連線層，換掉一套客製過主題與訊息卡片的 UIKit，重做的是整個介面層。介面層的遷移成本高於連線層，這是元件化策略的商業動機。

省下的排期，失去的訂單

傳導方向可以先列清楚。把聊天當支撐功能的業務端受惠：電商售後對話、企業內部工具、垂直社羣的附屬聊天、醫療與教育的諮詢窗口，這些場景裡介面層沒有差異化價值，十四到二十八人週直接從排程上消失，工程資源移往業務訊息與資料模型。供應商受惠於整合週期縮短與替換成本上升。承壓的一側，是長期以自研聊天介面為主要交付物的外包與顧問團隊，報價基礎正是被元件化抹平的那段工時；另一側是交付物仍停在 SDK 加文件階段的二線 PaaS，在評估期就輸在演示完成度。

介面層的戰略位置，因為對話框正在變成交易入口而放大。當成交發生在對話流裡，聊天介面從支撐功能變成銷售現場，這與訂票入口搬進對話框的重分配方向一致。對採用方，這也代表客製邊界要提前檢驗：訊息卡片能否承載業務欄位、主題切換的粒度到哪一層、超過邊界時靠設定解決，還是必須 fork 源碼自行維護。作者訂的第三個標準，接進業務後要能改，正是這個風險的提問方式。fork 之後，上遊每次更新都要人工合併，自研的經常性支出以另一種形式回來。

兩種情境的採購判準

情境一，IM 是產品的支撐功能，差異化在商品、內容或服務，通用介面的完成度已高於自家能投入的工時上限。買斷介面層，把排期留給業務層，帳面是淨節省。情境二，對話體驗本身就是產品，陌生人社交與遊戲語聊屬於這一類，互動設計是留存的主要變數，通用元件的天花板很快就會變成產品的天花板。此時 UIKit 的合理位置是冷啟動與市場驗證階段，進入正式迭代後再逐塊替換。

框架的更換週期則是元件庫的採購窗口。Vue 3 於 2020 年 9 月發布，2022 年 2 月成為官方預設，生態元件庫的補齊通常落後框架一至兩年。環信選在此時把 Vue 3 版 UIKit 放進開源社羣，對應的是存量專案的遷移尾流與新專案的預設選擇。錯過這個窗口，下一批專案的預設元件就屬於別家。

結回成本帳：這筆交易的標的，是被省下的十四到二十八人週首建工時，加上之後每年跟著作業系統更新重跑的相容驗證。買方用套件依賴與客製邊界換工時，賣方用工時換活躍用戶階梯的營收起算點與更高的替換成本。兩側的帳都算得過，前提是先確認自己的產品落在哪一種情境。