我差点把AI单证助手做成第二套ERP

最初的目标很简单：单证员把一个出口项目的资料文件夹交给AI。它读完相关材料，经过几次必要确认，生成几组常用出口文件，并完成一致性审核。

我以为这会是一个边界很清楚的AI应用。

可一周以后，项目已经膨胀到数万行代码、两百多条业务和校验规则、数百个测试。网页、数据库、字段映射、基础数据、模板生成，能想到的东西都在往里面加。

它越来越像一套完整的软件。

也越来越不像我最初想要的AI助理。

这几天最大的收获，是我终于看清：外贸公司做AI落地，最容易踩的坑，可能不是模型不够强，而是我们还在用上一代软件的思路设计它。

功能越做越多，我却越来越不踏实

单证工作看上去很适合自动化。

资料来源相对固定，输出也有模板。金额要核对，数量要汇总，毛重、净重、包装件数、客户信息、港口和贸易条款，都有明确位置。

于是我很自然地开始拆字段、建规则、做映射。

可真实项目一放进来，事情马上变复杂。

同一个港口，在不同资料里可能有几种写法；同一种产品，采购、销售和报关环节可能使用不同名称；付款主体和合同主体不一致，既可能是资料错误，也可能是正常业务安排。

每测试一个项目，就会冒出几个新问题。

我当时最直接的反应，是继续加条件、加数据表、加异常分支。新问题出现，补一条规则；测试没通过，再增加一个映射。

可规则越多，我越不踏实。

照这条路走下去，一个AI助手会不断膨胀成第二套ERP，甚至是一套小型行业软件。

它要求我们提前维护大量国家、港口、产品、供应商和业务规则。任何一种新写法、一个新产品、一次特殊情况，都可能要求修改程序。

对一家外贸公司来说，这并非做不到，却很可能不值得。

我让程序负责了太多“理解”

回头看，项目做重的原因，是我没有分清AI和程序各自应该干什么。

我让模型读取资料，却试图让程序穷举资料之间的所有语义关系。

这相当于雇来一个会读、会判断、会追问的助手，却只让它负责把文字抄进表格。真正需要理解的部分，仍然交给一大堆固定条件。

新的边界应该更清楚。

AI负责高不确定性的工作：理解资料，识别文件之间的关系，判断不同叫法是否指向同一种产品，发现冲突和缺失，根据历史案例提出候选答案，并在拿不准时询问单证员。

程序负责确定性的工作：金额和数量计算、重量核对、模板写入、格式保持、文件生成、命名，以及已经明确的硬校验。

金额相加，不需要AI思考。

两份资料为什么不一致，也不该让一条死规则擅自决定。

这条边界一旦划清，原来很多复杂设计就可以删掉。

一个项目，只应该有一份事实

测试中还有一个很隐蔽的问题。

制作第一张表时，AI理解一次项目；制作第二组文件时，它又重新读取和判断；到了最后审核，它可能已经形成了第三套理解。

每张文件单独看，都可能没有问题。

放在一起，却容易出现同一个项目有几套答案。

真正需要建立的，是一份项目级的“事实表”，我把它叫作Project Facts。

员工把资料放进项目文件夹后，AI第一步不急着生成文件。

它先读完全部材料，把客户、国家、币种、商品、型号、数量、包装、重量，以及冲突项和缺失项，整理成统一的项目事实。

这份中间数据不一定要展示给员工，也不用进入一个庞大的永久数据库。

它只是当前项目的单一事实源。

后面的计算、申报资料、商业文件和一致性审核，都从同一份事实中取数。

整个项目只理解一次，所有输出共享同一个答案。

这个变化看似只是多了一层中间数据，却解决了AI应用里一个很常见的问题：每个任务都很聪明，合在一起却互相打架。

敢让AI提问，系统反而简单了

过去做软件，我们习惯追求这样的流程：输入资料，系统处理，自动输出。

为了让中间没有人参与，就必须提前覆盖所有可能性。

这正是项目迅速膨胀的另一个原因。

后来我想明白，单证助手不需要做到“永远不问人”。它更重要的能力，是把一堆散乱的不确定性，压缩成几个单证员能够快速回答的问题。

例如：付款主体与合同主体不一致，是否属于正常安排？同一产品存在两个历史分类结果，本次应该采用哪一个？资料中缺少必要信息，应该由谁补充？

员工只需要回答几个关键问题，AI就可以继续完成后面的工作。

允许AI提问以后，系统一下简单了很多。

人机协作最有价值的地方，是让人从反复抄写、查找和核对中释放出来，只保留那些真正需要承担责任的确认。

特别是商品分类、申报信息和付款关系这类高风险内容，我宁愿让AI明确说“我不确定”，也不希望它为了流程顺畅给出一个看起来完整的答案。

知识库不必一开始就做成百科全书

我一度很担心：没有完整的港口库怎么办？没有覆盖所有产品的分类资料怎么办？员工、供应商、产品和常用业务信息，是不是都要先进入数据库？

真实业务给出的答案，是没有必要先建一本百科全书。

公司固定信息只有几十条，一张小型配置表就够了。

历史确认过的产品分类、申报口径、名称映射和标准案例，适合放进公司的经验知识库。

全球开放信息和第一次出现的新产品，可以在真实项目发生时查询、判断和确认。

第一次遇到一种新产品，AI给出候选、依据和置信度，由单证员确认。

确认以后，再把结果沉淀进“已确认商品知识”。下次出现同类产品，优先调用它。

知识库应该跟着业务自然成长。

如果还没有跑过几个真实项目，就先花几个月建设全球基础数据，大概率会把时间用在永远不会出现的情况上。

已经写出来的代码，也没有白费

这几天的弯路，反而帮我把现有成果分成了三类。

第一类应该保留。

文件读写、金额计算、数量计算、模板填充、格式保持、文件命名和结果校验，这些确定性能力以后仍然是AI单证助手的手和工具。

第二类应该逐步淘汰。

大量为了理解国家、港口、产品别名和资料关系而写的穷举式判断，可以逐步交还给模型。

第三类应该从代码变成知识。

例如多份资料怎样合并、主体不一致时怎样确认、哪些问题必须报错、哪些问题只需要提醒。

这些规则里，有些适合硬校验，有些适合写进业务SOP，让AI按照公司的方法判断。

原来的规则和测试也不是负担。

它们告诉我哪些必须继续作为回归测试，哪些只是旧架构的补丁，哪些可以成为AI的验收标准。

弯路留下的资产，不只有代码，还有被暴露出来的业务边界、异常情况和验收口径。

我现在只想验证一个最小闭环

第一版，我不再继续开发完整网页，也不急着让多个AI专家互相讨论。

我只需要一个AI单证专家，负责一个出口项目到底。

它先读取项目资料，建立Project Facts，列出冲突和缺失；再调用几个边界清楚的工具完成计算、文件生成和一致性审核。

第一阶段不用证明它能处理全球所有出口项目。

我准备只拿三到五个已经完整做过的真实项目测试。

验收目标也很朴素：单证员把一个项目资料文件夹交给AI，经过最多几次人工确认，能否稳定生成需要的文件，并保证关键数字和字段一致。

如果这个闭环跑不通，再大的数据库、再漂亮的网页、再多的智能体都没有意义。

如果它能跑通，再把每一次真实纠正沉淀进知识、规则和测试集。

写在最后

这一周，我差点把一个AI单证助理，做成第二套ERP。

但我并不觉得这段时间白费了。

如果没有真的写代码、跑测试、拿实际业务去碰，我可能还会停留在“建知识库、做Skill、接大模型”的想象里。

那些不断冒出来的例外，让我看见了哪些问题应该交给AI，哪些必须交给程序，哪些只能由人确认。

企业AI落地真正难的地方，不是把一个演示做出来。

是把AI放进真实流程以后，愿意承认原来的设计不对，敢于删掉已经写出来的东西，再把系统收缩到最小闭环。

我现在想做的，也不是重新开发一套单证ERP。

我只想先做出一名真正能工作的AI单证助理：它会读资料，会理解公司的规则，会使用工具，会发现矛盾，拿不准时会问，确认以后能把整套工作稳定地做完。

如果你也在推进外贸公司的AI项目，先别急着做大。拿一个已经完成过的真实项目，从头跑一遍，把AI每一次需要人确认的地方记录下来。