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。