AI架構的三扇單行門：別讓MVP為未來踩坑

“早期架構是對自己成功的賭注?！边@句話貼在每一個技術合伙人的桌子前邊，但只有在真正輸過一次之后，你才會明白它說的根本不是技術選型。 四個月前，一家做AI合同審閱的創業團隊用開源模型搭了一個MVP。兩天之內，他們用手寫的JSON解析規則把合同里的關鍵日期、金額和條款扔進一個大表，前端只要調一下模型接口就能返回摘要——客戶買單、投資人感興趣，一切看起來都很對。數據開始涌進來，他們順手加了幾個字段，又因為某家客戶要求“每個部門只能看自己的合同”，就在代碼里用if-else做了部門過濾。直到有一天，一個銷售副總裁誤看見了法務部的合同條款，而同時數據庫里一張“合同事項”表已經膨脹到聯表查詢需要12秒，模型每次生成摘要都要帶著幾十條無關的歷史記錄——這時候他們發現，每一個當初“以后再說”的決定，現在都要在訂單不斷流入的生產系統上動手術，并且任何一個操作都可能停機、丟數據或者泄露客戶信息。 團隊當初面對的問題，和今天幾乎所有AI原生產品在MVP階段遇到的如出一轍：究竟哪些架構決策是無論怎么節省資源都不能潦草的？這個答案藏在單向門（one-way door）與雙向門（two-way door）的區分里——而我們今天就要把這幾扇單向門拆開，看到底哪些地方值得你傾注全部的小心翼翼，而哪些地方隨便選一個就能往前走。 大多數架構決策其實都是雙向門。UI框架、前端狀態管理工具、后臺任務隊列、甚至一開始用的托管平臺，這些都可以在后續的日子里被替換。它們的共同特征就是：遷移成本雖然耗時，但被一個叫作“工程規?！钡奶旎ò逅浪揽ㄗ　阒恍枰匦聦憥讉€組件、搬遷一批數據、改一版部署管線，中間可能會煩躁幾個星期，但不會動搖業務根基。團隊在這些事情上反復權衡、刷遍對比文章、用整整一個沖刺周期去做POC，本質上是在拖延真正的硬仗，因為它們會給你一種“我很謹慎”的錯覺，而實際上每多猶豫一天，你都是在推遲與真實用戶見面的時間。 單向門則截然相反。它們現在做決定幾乎不用花錢，可一旦線上數據開始流轉、客戶組織開始入駐，你就再也不能輕松把它們換掉了。更妙的是，這類決策的數量相當有限——這意味著你真的可以、也必須把它們當作一個短清單，逐一認真思考。在一個AI語言模型直接坐落在請求路徑上的產品里，這幾扇單向門尤其醒目，它們分別是：數據模型、認證與多租戶隔離，以及核心與AI層之間的那道接縫。 第一扇單向門是數據模型。它之所以被排在首位，不僅因為數據庫的回滾困難，更因為在一個AI驅動的產品里，數據模型實際上同時扮演了兩個角色：它既是你所有業務狀態的載體，也是未來模型能夠檢索到多干凈、多完整上下文的唯一來源。一旦一份合同、一條客服工單、一個項目文檔被拆散成太多無關的小行，后續當你需要為模型拼湊出“這位客戶在過去三個月的所有溝通摘要”時，你得到的不再是一個連貫的故事，而是一堆需要瘋狂聯表的碎片；反過來，如果什么都往一個寬表里塞，你今天省下的檢索時間，就會變成明天每次寫操作都在跟鎖競爭。這個問題不會在MVP頭兩周暴露，因為那個時候表里只有幾百行數據，任何SQL都能跑得飛快。但當你有了第一個付費客戶，他們開始上傳歷史合同并要求自動對比條款，而你突然發現“條款明細表”當初為了顯示方便把數值存成了字符串，現在連大小判斷都要做字符串轉換——這就不再是改版本號能解決的問題了。生產環境上的數據遷移，尤其是有用戶正在讀寫的線上數據遷移，往往需要拆分成多個階段：先建新列，再雙寫，再回填歷史數據，再切換讀取路徑，最后再清理舊列。在這個過程中，你無法接受任何一分鐘的計劃外停機，因為AI產品的用戶耐心遠比工具類產品更低——他們輸入一個指令，預期的是數秒內返回結果，如果此時你因為一個ALTER TABLE鎖表，他們就會以為“模型又壞了”。數據模型的一丁點疏忽，會在每一個月反復向你收稅，這也正是為什么現在多花幾個小時在白板上畫出核心實體、理清實體之間的關系、推演未來可能出現的查詢模式，是最劃算的投資。 第二扇單向門，是認證、授權與多租戶隔離，尤其對于B2B產品。幾乎所有AI應用在Demo階段都把用戶當作一個平面的列表，或者干脆只有一個默認的超級賬戶?！捌髽I版本我們后面再加”，這幾乎是每個人的第一反應。問題在于，當你后期要把一個真實的多租戶權限模型塞進一個已經假設只有一個扁平用戶空間的系統里時，它根本不是一個補丁能完成的工程。舉個最直接的例子：你的早期MVP里，工單表里每一行只有一個user_id，前端也直接根據當前登錄用戶的id去拉列表，API里甚至沒有一個tenant_id的概念。突然有一天，客戶說“我們市場部的經理需要看到自己部門所有成員創建的工單，但不能看到其他部門的”。如果你只是在前端加幾層過濾，那數據庫中產生的每一份中間緩存、每一次模型返回的歷史工單摘要，都可能把跨部門的信息拼在一起扔給模型，然后由模型生成一份“你可能感興趣的問題總結”，而這份總結恰好夾帶了隔壁研發部門的內部討論——在B2B場景下，這已經不只是產品事故，而是一起數據泄露事件。更麻煩的是，AI輔助編碼在這個領域制造的幻覺比在任何其他模塊都危險：你讓Copilot幫你寫一個基于角色的權限模型，它能在幾秒鐘內給你生成一套看起來很完整的中間件，有角色表、有權限表、有AssignRole函數，甚至還會幫你加上裝飾器。但這層“看起來合理”的權限層和你當初業務邏輯里那些散落在各處的“if user.role == admin”之間有著巨大的鴻溝，并且模型不會告訴你哪個API端點漏了驗權，不會提醒你某個后臺定時任務在做跨租戶數據聚合時直接繞過了所有隔離邏輯。這里的驗證必須是人的工作——你可以用AI生成代碼，但防護欄只能你自己去一根根敲進去。 第三扇單向門，是很多人甚至意識不到需要刻意去設立的那一道——核心邏輯與AI層之間的清晰接縫。對于任何把一個語言模型放在業務關鍵路徑上的產品，你的系統天然由兩種截然不同的部分構成：一邊是必須每次正確執行的確定性核心，包括賬戶、數據、工作流、支付；另一邊是智能層，它提供摘要、抽取、推薦，甚至以Agent形態采取行動。讓這兩部分在代碼里彼此糾纏，是架構師可能犯的成本最高的毛病。如果這條接縫足夠干凈，那么你會發現，將來想換一個模型、想對熱點請求加一個緩存層、想切到另一家推理服務提供商，或者干脆想在某些接口上把推理移出熱路徑做異步處理時，你甚至不需要觸碰核心邏輯的代碼。反之，如果模型調用散落在業務邏輯的每一個角落——比如在訂單創建的回調里直接調模型做風控推薦，在用戶注冊的中間件里實時生成歡迎語——那么任何一個看似獨立的改動都會變成一場外科手術：你想給推薦加一個緩存，結果發現要同時修改訂單服務、用戶服務、通知系統，而且每個地方對于模型超時和錯誤返回的處理方式還不一樣。所以，那道接縫的建設其實意味著三件事：AI層只能通過明確定義的接口與核心對話；模型產出的所有內容在被寫入任何重要字段之前，都必須經過一層校驗，無論是簡單的格式校驗，還是規則