72小時造出AI關稅系統：這個產品經理把3年功夫藏進了周末

220,000條海關判例、19卷聯邦法規、47個MCP工具——Fahad Baig在復活節周末上線HTS MCP時，這些數字已經在他硬盤里躺了數月。他對外講的故事是"72小時造了個SaaS"，但真正的伏筆埋得更深。

關稅分類的本質是個AI問題，只是穿了個合規的外衣。Harmonized Tariff Schedule（協調關稅表，美國進口商品關稅判定系統）有數千行稅則號、嵌套層級、以及一套覆蓋表面匹配的通用解釋規則。Baig沒做過貿易合規，但他做過多年分類系統：檢索、領域建模、結構化引用層。他看到的不是陌生領域，而是一個熟悉的"問題形狀"。

周末開始前，他已經完成了數據基建：稅則號全量加載、22萬條CROSS（海關裁定在線搜索系統）真實判例、19 CFR（海關聯邦法規）全文分塊與嵌入。多層嵌入、語義圖譜、LLM分類邊——還有帶斷點續傳的術語表流水線，"因為之前吃過批量任務中斷的虧"。

冰山之下：讓速度成為可能的預制件

真正的加速來自架構慣性。Baig早就確立了MCP（模型上下文協議）工具的清晰邊界，采用共享核心模式：業務邏輯只寫一次，MCP、REST、CLI作為薄適配層疊加上去。他還有個eCFR Title 19的兄弟倉庫，能一次性移植到新系統。

「你只能這么快，如果架構本來就干凈到能移動。」

47個MCP工具橫跨9個數據域。五智能體系統帶工具白名單和質量門。這些不是周末現造的，是之前項目的遺產。

復活節周五下午1點，Baig開始動手。目標很明確：一個能回答"這件商品該交多少稅"的AI系統，輸出帶引用、可審計、能應對海關質疑。

他先花兩小時畫系統圖——不是裝飾性的，是用來暴露假設的。圖里標出數據流、失敗模式、以及"如果這部分錯了，整個答案就廢了"的關鍵路徑。畫完才發現，真正的瓶頸不是代碼，是驗證：怎么確認AI給的分類在法律上站得住腳？

周六：與幻覺的拉鋸戰

周六凌晨，第一版智能體開始跑測試。Baig用的方法是"約束即功能"：不給模型開放式回答空間，而是強制它走法定步驟——先查通用解釋規則（GRI），再匹配稅則描述，最后核對章節注釋。

但幻覺來得比預期快。一個測試用例里，AI把"藍牙音箱"歸到了音頻設備章，忽略了內置電池的供電功能——這該歸到另一章。錯誤很微妙，表面看起來合理，直到你核對GRI 3(c)的復合物品規則。

Baig的應對是雙重驗證層：智能體給出答案后，第二個驗證智能體專門挑刺，用CROSS判例庫反向檢查。如果找不到支撐判例，答案標記為"低置信度"，強制人工復核。

「不是消滅幻覺，是把幻覺逼到你能發現的地方。」

到周六深夜，核心循環跑通了：用戶輸入商品描述→智能體分解特征→多路徑檢索稅則/CROSS/法規→生成帶引用的分類建議→驗證層打分→輸出或標記。但界面還是命令行。

周日：在上線前砍掉一半功能

周日上午，Baig面臨經典的產品抉擇：原定要做的批量上傳、多國稅則對比、歷史稅率追蹤——全砍。72小時的約束逼他聚焦單一用戶場景：一個美國進口商，面對一件陌生商品，需要快速、可信的關稅答案。

界面用Streamlit（快速數據應用框架）搭了4小時。不是最優解，但"能讓用戶用起來的最快路徑"。他加了兩個設計：每個答案必須顯示引用的CROSS判例編號，以及一個"這個答案對嗎？"的反饋按鈕。

「合規人員不信任黑箱。你要給他們抓手去驗證你。」

周日下午6點，系統上線。Baig在LinkedIn發了條帖子，附上演示視頻：輸入"無線降噪耳機"，30秒后輸出HTS編碼8518.30.20，引用三條CROSS判例，標注"電池供電功能已按GRI 3(c)處理"。

72小時之后：真實用戶教的事

上線第一周，200多個注冊用戶，大部分是海關經紀人和合規專員。反饋分兩類：一類夸速度，一類挑錯——后者Baig更重視。

最尖銳的反饋來自一位從業15年的經紀人：「你們的AI把'電動滑板'歸到8711（摩托車），但CROSS有個2019年的判例明確歸到9506（運動器材）。你們的數據庫沒收錄？」

查完發現，Baig的CROSS快照是三個月前的，那個判例恰好在窗口期后發布。他當晚寫了增量同步腳本，把更新周期壓到24小時。

另一個意外是語言。Baig假設用戶用英文描述商品，但第一批測試里30%輸入是西班牙文——美墨貿易的進口商直接用西語查。他臨時加了翻譯層，但意識到長期得做多語言嵌入，不是簡單機翻。

三周后，HTS MCP有了付費企業客戶。Baig的定價策略很直接：按查詢量階梯計價，但每個答案帶"置信度分數"——低于閾值的不收費，"算我們的"。

「你要在商業模式里承認不確定性，而不是假裝它不存在。」

回看那個周末，Baig認為最大的誤判是低估了"解釋性"的工作量。代碼只占時間的小頭，大量精力花在設計答案的呈現結構：為什么選這個編碼、排除了哪些替代選項、法律依據在哪一段。這些不是技術問題，是產品信任問題。

他現在的迭代重點在"對抗性測試"：雇前海關審計員專門找系統的錯，找到就補進訓練集。另一個方向是垂直細分——醫療器械的關稅分類有獨立邏輯，和消費品完全不同，需要專門智能體。

HTS MCP的代碼庫仍在快速膨脹，但Baig堅持一個原則：每個新功能必須通過MCP工具暴露，保持架構的薄適配層。周末造的SaaS正在長成更復雜的系統，但底層的"問題形狀"識別能力，仍是那個讓他72小時啟動的底層資產。

最后一個細節：Baig在系統里埋了個彩蛋。如果用戶查詢"HTS MCP本身該歸哪個稅則號"，AI會回答8471.80（數據處理設備），然后附注——「但本系統的開發者認為，它真正的價值在于把3年領域工程壓縮成一次周末演示。」

這個答案的置信度分數是：0.97。