重點摘要
- 灌 540 萬包裹壓測，警衛的社區包裹列表要 7330 毫秒。病根是 RLS 兩條 PERMISSIVE policy 用 OR 合併，讓查詢規劃器用不到 community_id 索引。
- 全面拔除 173 條 policy、85 張表的 RLS，租戶隔離 100% 改由應用層帶 community_id。同一條查詢從 7330ms 降到 1.34ms，約 5500 倍。
- 但拔掉 RLS 不是終點——第二波跨社區洩漏被「單租戶壓測」蓋住了：對照社區在多數表是 0 筆，洩漏判準（本社區數＝全平台數）自動成立。要每張表都灌 ≥2 個社區才測得出；而且漏帶 community_id 不只洩漏，更是少了索引，同一個病根換地方又長。
- AI 把規模準備的「建造成本」打掉了，但有兩個成本它打不掉：分區帶來的「複雜度稅」（維護照繳），與「取決於規模實測才知道對錯」的經驗決策（RLS 自己就是反例）。
- 結論：AI 時代「規模化 Day One」從奢侈變預設，但「準備什麼」的判斷力更值錢——有把握的提前上，取決於壓測的，老實留給壓測。
一個 V2 產品、兩天、一個 AI 協作者，把一套多租戶系統從「靠資料庫兜底」推進到「應用層自己負責」。這篇記錄的不是 commit log，是技術選型的隱性成本，怎麼在特定規模與特定哲學下才現形——以及 AI 怎麼悄悄改寫了「該不該提前準備規模化」這道老題目。
先講結論：MVP 智慧是成本算出來的啟發法，不是定律
傳統智慧說：MVP 先做，別過度工程，規模化以後再說。這句話我一直信，直到這兩天我意識到——它是一條成本驅動的啟發法，不是定律。
它成立的前提是「規模準備很貴」。以前要做分區、多租戶隔離、idempotency、離線佇列這整套規模機械，往往要多三到四倍的人力、好幾個月。那個成本，才讓「先別做、等需要再說」變成理性選擇。但兩件事同時改變了這個算式：
- AI 把建造成本打掉了。那套規模機械，AI 輔助下生成 + 維護的人力崩塌。
- 這是 V2，不是 try。前一版已經證明了領域——住戶、警衛、包裹是真需求，而且會有很多社區。規模不是猜測，是 near-certainty。「You Ain’t Gonna Need It」的前提「你可能不需要」，直接是假的。
所以對一個 AI 輔助、領域已驗證的 V2，Day One 就準備規模化，比經典 MVP 智慧主張的更該做。但這篇真正有料的地方，是兩個 AI 也打不掉的成本。後面講。
當初為什麼這樣選技術？
這套系統的技術選型，是三股力量的合力：領域驅動 + 規模前瞻 + 不重蹈前版覆轍。
- Flutter 單一 codebase：住戶用手機、警衛用平板，功能大半重疊靠角色 gate。兩份原生 = 兩倍維護；一份 + responsive 是省力的對。加上離線優先是硬需求（警衛平板斷網也要能收件、拍照、印通知條）。代價老實說：CanvasKit 的 web 端很痛，e2e 自動化一路在跟它的無障礙語意樹搏鬥。
- Go + GraphQL（型別契約）：Go 單一 binary 好部署、並發強，對著「1000+ RPM / 1000 社區」的目標。GraphQL 用型別嚴謹的契約——這是對前版的反動：舊版用 category/method 字串路由 + PHP 的型別強制轉換怪招，踩過坑。型別世界 = runtime 少驚喜。
- PostgreSQL + RLS（Row-Level Security）：這個最值得講，因為我們親手拆了它。
RLS 的故事：為安全而選，為清亮而拆
RLS 當初為什麼選？防禦縱深。理由聽起來無懈可擊：「把租戶隔離放在資料庫層，app 出 bug 也繞不過。」每個社區的資料用 policy 鎖死，誰都別想跨社區看到別人的包裹。
然後規模化壓測來了。我們灌了 540 萬包裹、5.4 萬戶、202 個社區，模擬一個 V2 跑兩三年後的樣子。一量——警衛的社區包裹列表，7330 毫秒。七秒。
病根不是索引沒建，是 RLS 的兩條 PERMISSIVE policy 用 OR 合併：(是系統管理員) OR (社區=X)。community_id 只出現在 OR 的一邊，查詢規劃器就用不到 community_id 索引，只能 Seq Scan 掃完整張表的所有分區。這個病，設計時看不出來，要到 5.4M 才現形。
業主的反應很關鍵。他不要「在 DB 加更多限制」來繞，他要的是更乾淨：「我不要我的資料庫跟我的 AP 有這樣的依賴。本來就該做到零洩漏，怎麼會依賴 RLS？」
於是我們全面拔除 RLS——173 條 policy、85 張表，全部 DROP。租戶隔離 100% 改由應用層：每一條碰租戶資料的查詢，自己帶上 community_id = current_setting('app.community_id')。
拆的過程，反過來證明「本來就該零洩漏」當時是假的
審計時我抓到，授權中介層對「同社區範圍」的操作寫死了一行註解：「RLS 負責租戶隔離，這裡不另外檢查。」也就是說，有好幾個改別人資料的後端進入點（停用警衛、在別社區建戶、復活別社區的軟刪戶），它們的隔離正確性，本來就完全押在 RLS 上。RLS 一拔，這些就是跨社區提權漏洞。
派去掃的 AI 子代理一開始判了 23 個缺口；我逐條人工驗證，收斂到 3 個真缺口——其餘有的早被別的守衛擋著、有的是子代理幻覺出根本不存在的函式。這也是個教訓：AI 的清單要逐條驗，不能盲信。
拆完，效能呢？同一條查詢，帶上 community_id：
| 查詢 | RLS 開（OR 合併擋索引） | RLS 拔除 + 應用層 community_id |
|---|---|---|
| 警衛社區包裹列表（5.4M 列） | 7330 ms（Seq Scan 全分區） | 1.34 ms（Index Scan） |
| 包裹改動歷程鑽取 | — | 0.2 ms |
從 7330ms 到 1.34ms，約 5500 倍。反諷的地方：當初選 RLS 是「為了安全」。它不但變成效能地雷，還讓 app 層偷懶——「反正 DB 會兜底」，於是 app 層的隔離就不嚴謹了。兜底機制養出了被兜底者的鬆懈。
拔完 RLS 之後：洩漏沒結束，是換了個地方躲
拔掉那天修了 3 個提權，我以為收工了。錯。RLS 一拔，等於把「DB 兜底」這層拿掉，所有原本偷懶的查詢全部裸奔——真正的第二波，要再跑一輪壓測才現形。
一個包裹計數查詢，給某社區警衛回了 280 萬——那是整個平台的數字，不是他那個社區的。病根：這個 count 自己手寫 WHERE，繞過了會自動補 community_id 的中央 helper。同一類的還有一票：社區統計（*Stats）、各種計數（*Count）、住戶/包裹 picker、以及「先 load-by-id 再改」的 mutation——全是各自為政手寫查詢、漏帶租戶欄位的高風險地帶。
但這篇最該記住的，是為什麼第一次壓測沒抓到。答案很反直覺：單租戶結構上測不出跨租戶洩漏。
我第一次灌的 540 萬，只灌在 parcels 和 households 兩張表，其他維度（使用者、訪客、公告、picklist）對照社區根本 0 筆。而洩漏的判準是「本社區查到的數字 == 全平台的數字」——當對照組是 0，這條恆等式自動成立，洩漏被 0 資料蓋得死死的。修法不只是補 WHERE，是補資料形狀：每一張要驗的表，都灌進 ≥2 個社區的資料，動態探針才有對照組去抓「你回給我的，有沒有混進別人的」。
還有一層，業主一句話點破：漏帶 community_id 不只是洩漏，是效能。「為什麼還有功能沒戴上 ID，這不只會洩漏，重點是效能會變差，沒用到 index。」少了那個欄位，查詢就跟當初 RLS 的 OR 一樣用不到索引、掃全表。防洩漏和上索引，是同一個動作——community_id 既是隔離邊界，也是索引前綴。當初那個「OR 擋索引」的病根，拔了 RLS 之後，在每一條手寫查詢裡換個地方又長了出來。
規模下另外兩個 Day One 就得拍的板
同一輪還拍了兩個一旦上線就很難回頭的板，都是「規模 + 時間」逼出來的。
- 快照 vs 正規化：歷史標籤不准 join。包裹上的物流公司、儲位、包裹類型、收件人姓名，全部存成當下的文字快照，不是外鍵。為什麼不正規化？因為這些是歷史事實。若做成外鍵去 join 現行字典，哪天某家物流公司改名或下架，過去的包裹紀錄會被回頭改寫——未來的公司出現在過去的資料上。原則一句話：身分用外鍵，歷史標籤用快照。這跟「證據鏈不可竄改」是同一個底層要求。
- 控制面狀態用單例快取，不是每頁查 DB。社區可被系統管理員停用，每個請求都得確認「這社區還活著嗎」。最笨的做法是每頁打一次 DB——那又是另一種 RLS 式的過度防禦。做法是一個程序級單例快取（map + 鎖），10 分鐘 TTL，miss 才查 DB，停用/復活時主動逐出；隔離檢查收斂在一個 chokepoint（進交易時查一次），不撒在每條查詢。順手修了個誠實問題：社區停用後登入原本回「帳密錯誤」會誤導用戶，改成帳密對的人才告知「社區暫停服務中」——既不誤導本人，也不洩漏社區存在給攻擊者。
兩個 AI 也打不掉的成本
回到開頭的 thesis。AI 讓規模準備「便宜到值得 Day One 就做」——但有兩個成本它打不掉。
| 成本 | AI 打掉了什麼 | AI 打不掉什麼 |
|---|---|---|
| 複雜度稅 | 建造成本（生成分區/隔離/佇列） | 維護稅：每次改動/debug 都要付。例：pg_total_relation_size 對分區母表回 0，最大的表都報 0，要展開分區層才量得到 |
| 經驗決策 | 實作速度 | 壓測經驗：RLS 的「OR 擋索引」要 5.4M 才看得見，連 AI 都沒辦法 Day One 告訴你對的選擇 |
成本一：AI 打掉「建造成本」，沒打掉「複雜度稅」。月分區讓程式更難推理。這兩天我們親自繳了這個稅：監測資料量時，pg_total_relation_size 對分區母表只算母表本身（回 0）；還有 FK 要複合鍵、分區不繼承 RLS、清測試資料時被自己剛上的 append-only trigger 擋住……這個複雜度，是每一次未來改動、每一次 debug 都要付的稅，連 AI 也付。「AI 讓規模準備好建」是真的，「規模準備免費」是假的——稅照繳，只是從建造繳給了維護。
成本二：有些規模決策是「經驗的」，Day One 就是準備不了——RLS 自己就是鐵證。RLS 本來就是 Day One 的規模準備（多租戶隔離），結果它是錯的 Day One 選擇。為什麼當初設計看不出來？因為「OR 擋索引」這個病要 5.4M 壓測才看得見。有些決策，正確答案取決於規模行為，而那行為你預測不了——那是壓出來的，不是設計出來的。而且如前面那一節的教訓：光有規模還不夠，要對的「資料形狀」——對照社區是 0 筆的那次壓測，把第二波洩漏整個蓋住了。經驗決策不只需要壓力，需要對的壓力。
AI 時代，「規模化 Day One」從奢侈變預設。但「準備什麼」的判斷力反而更值錢：有把握的結構提前上（便宜了）；取決於規模實測的決策，老實留給壓測。
有把握的（會有很多社區 → 按社區/時間分區；離線不可妥協 → 佇列），提前做。沒把握的（隔離機制、索引策略），別假裝設計階段就能拍板。這跟我之前寫過的 企業 AI 落地為什麼失敗 是同一個底層觀念：方法論不能照抄，要看你的前提條件還成不成立。
方法：規格化、決策留證、以及「我自己打臉自己」的報告
這兩天還做了第二件大事——把包裹做成可被法庭級檢驗的證據鏈。改動寫進不可竄改的 log（鑽一顆包裹的歷程，5.4M 下 0.2 毫秒）、簽名與照片在儲存層鎖死不可刪、系統管理員調查要「破窗」且每次都留審計。但比功能更值得分享的是方法：
- 規格先行。每個設計決定都先寫進規格、辯論清楚、鎖進文件，才動手。對話會被壓縮遺忘，規格不會。
- 決策留證，不靠主觀評分。業主不信任 AI 加工過的「成本/風險」評分，他要看真實檔案、真實行數、schema 影響。所以需要他拍板的時刻，我生的是事實卡片，不是紅黃綠燈。
- 三份報告的誠實檢驗。最後他要一份評分報告。但他要的不是一個數字——他要三份做比較：原始版、我「現在的預估」（鎖時間戳，不准事後改）、和「全部做完 + 全面測試後的真實量測」。核心是拿我的主觀預估去對真實量到的，差多少 = 我的評估可信度。
結果：我預估綜合 7.5，真實約 7.8，誤差約 0.3 分；方向性預測（「dev 環境的測試污染會讓部分整合測試紅、但那不是回歸」「forensic 能力做完會升」「效能會守住」）全中。唯一校準：我對「系統穩定度」過度保守——實際零回歸。這種「逼 AI 先承諾預測、再用真實數據打臉」的設計，把「AI 的話可不可信」變成一個可量測的問題。
人機協作：最好的部分不是分工，是辯論
這兩天的分工大概是：業主出領域知識與方向決策，AI 出執行、驗證與反思。但最好的部分不是分工，是辯論。RLS 該不該拆、拆了 sysadmin 怎麼查日誌、照片資料夾要不要鏡射分區、孤兒清理會不會變成刪證據的後門——這些不是「下指令、執行」，是來回推。
業主用領域常識把我拉回現實（「哪有警衛不分社區的，警衛 A 在四個社區工作就是四個警衛」），我用壓測數據和審計把假設證偽（「你說本來就零洩漏，但我們現有 code 就漏了 3 個」）。AI 不會累、能掃完每個呼叫點、能把 23 個候選逐條驗到剩 3 個真的；但判斷「準備什麼」「什麼時候該停下來問人」，還是要人。
結語
如果只能留一句：老的 RD 有老的包袱，所以才有「MVP、先別管規模」的智慧。但那個智慧是成本算出來的。當 AI 把建造成本打掉、當你做的是領域已驗證的 V2——規模化就是 Day One 的事。只是別忘了，AI 打不掉複雜度稅，也替不了你壓測；有把握的提前上，沒把握的，老實壓出來——而且要用對的資料形狀去壓，單租戶測不出跨租戶的洩漏。
RLS 是我們「Day One 準備了錯的東西、規模化才發現」的活標本。它沒有讓這個決定變壞——它讓這個決定有了教材。
技術細節：Flutter + Go(gqlgen) + PostgreSQL 16；月分區、River 佇列、MinIO。壓測 540 萬包裹 / 202 社區 / RLS-off：熱查詢 1.34ms、改動 log 鑽歷程 0.2ms。