做多帳號管理系統，最早該定下來的不是介面，而是裝置這一層的欄位與生命週期。抽象做錯，帳號一多、裝置類型一變，上層功能就得整體返工，修改會形成連鎖反應。
開發一個多帳號管理系統，多數人的第一版都是從介面開始想的：做一個帳號列表，每個帳號掛一個瀏覽器設定檔，然後呼叫介面去操作。看起來夠用，直到真正跑起來。
第一版的寫法往往很直接。帳號 A 指向設定檔 001，帳號 B 指向設定檔 002，帳號 C 掛一台雲端手機。麻煩會在三個地方冒出來：營運說那台機器壞了，能不能把帳號 A 挪到雲端手機上，你只能說改資料庫、手動處理、有風險；接進來一個新的裝置來源，問怎麼加，得到的回答是帳號模組要重構；想讓同一個帳號上午用瀏覽器環境、下午用雲端手機分時段跑，基本做不到。
這三個情境看起來互不相干，根因只有一個：帳號這個實體裡塞進了本來不屬於它的東西。當前登入的裝置、歷史用過的裝置、指紋參數、出口位址，全都寫在帳號上。於是換裝置就等於改帳號，牽一髮動全身。
裝置要單獨成為一類物件
拆開之後，帳號和裝置之間應該是多對多。帳號不存指紋，只記錄目前綁定在哪個裝置上；切換裝置做成一次原子操作，歷史綁定單獨留一張表備查；裝置自己有唯一識別碼，對外只認這個識別碼，狀態可即時查詢。
這麼做不是因為模型好看。它縮短的是營運想調整時和開發要改程式碼之間的距離，而這個距離會隨著裝置數量一起放大。
抽象層要交代清楚的四類欄位
一個撐得住擴充的裝置抽象，對外只需要回答四件事。
- 環境 ID：唯一且穩定。上層只透過它引用環境，底層實作裡的編號、容器名稱、程序 ID 都不該暴露出去
- 出口綁定：這個環境從哪個網路出口出去，以及配套的時區、語言、DNS 是否成套。出口單獨抽出來的好處是，換出口不動環境本身
- 狀態：建立中、可啟動、執行中、被任務占用、異常、待回收。沒有狀態模型，池化和回收就無從談起
- 生命週期：建立、啟動、占用、釋放、回收分別由誰觸發，任務逾時怎麼辦，環境異常了誰來收尾
狀態和生命週期經常被合併成一個欄位，這是最省事也最貴的做法。狀態回答現在是什麼樣，生命週期回答下一步誰能動它。正式環境裡真正的麻煩幾乎都出在後者：任務崩了沒人釋放環境，或者環境還開著就被回收，下一次啟動才發現出口已經變了。
抽象做錯，代價會在擴充時結帳
十個環境的時候什麼都看不出來。到了幾十上百個，問題集中爆發：
- 新增一類裝置要動帳號模組，迴歸範圍從裝置層擴到帳號層
- 換裝置要走改資料庫，營運不敢碰，系統慢慢只有開發能維護
- 沒有狀態和占用記錄，異常退出的環境沒人回收，殭屍環境越積越多
- 上層任務、內容、自動化全都建立在帳號與裝置一對一的前提上，改一次全鏈路重來
不同來源的裝置在實作上差別很大，本機瀏覽器環境、雲端手機走的介面都不一樣。抽象層的作用是把它們放在同一組介面後面：新增一類裝置，補一個介面卡把啟停和狀態查詢實作掉就夠了，上層邏輯不用動。也有一個很直接的辦法能判斷抽象對不對：加一種裝置，需要改的程式碼是不是只落在一個檔案裡。
第一階段做得越少越好
技術模型定下來之後，介面會自然很多。選單按業務物件組織，帳號、任務、裝置各占一塊，而不是設定、參數、日誌。介面上最該顯眼的是狀態和異常，因為使用者找的是有沒有問題，不是有多少筆記錄。
功能上，第一階段只做裝置列表、加入裝置和一條最小任務閉環就夠了。選單能省就省，先把一件事跑通，不用的先不做。
如果不想從零實作環境隔離，也可以把這些交給現成能力。PurpleMark 提供獨立環境與出口綁定，支援按分組批次建立和狀態查詢，上層只需要實作範本、占用和任務排程這幾件事，把工程投入留在業務邏輯上。
多帳號系統的複雜度從來不在帳號數量上，而在裝置的生命週期管理。先把裝置當成一個有身分、有出口、有狀態、有生命週期的資源，上層功能才不會被加一次推翻一次。
