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小时之后:真实用户教的事

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。