周五交付前：用 Gemini 3.1 Pro 核对中英日采购文件

周五交付的任务：三份文件，一笔采购

跨境采购系统上线前，最棘手的往往不是翻译，而是确认不同语言的文件是否在说同一件事。中文订单写着一个交货日期，英文报价单用了另一种日期格式，日文补充条款又增加了验收条件。开发者需要的不是三份流畅的摘要，而是一份能追溯证据的差异清单。

这次围绕 Gemini 3.1 Pro 的现场测试设计，就从这个交付场景出发。先说明边界：本文使用合成采购资料做桌面演练，未实际调用模型；下文给出的是测试输入、验收标准和接入判断，不是已测得的准确率或速度报告。

测试样本：把矛盾埋在金额、日期和脚注里

准备三份各两页的样例：中文采购订单、英文报价单、日文交付补充说明。为每份文件保留稳定的文件名、页码与段落编号，再埋入三类问题。

• 金额：订单为一百件、每件十二美元，报价单却把总价写成一千三百二十美元，脚注另列百分之十的服务费。
• 日期：英文报价单写“04/05/2026”，中文订单要求五月四日交货，但报价单没有标明日期格式。
• 条件：日文补充说明规定，验收完成后起算三十天付款；中文订单只写收到货物后三十天付款。

金额差异未必是算错，日期也未必真正冲突；付款起算点却可能改变实际账期。这些区别，正好能检验模型是在理解文档，还是只在寻找看起来不同的字符串。

提交方式：先确认文件通道，再固定提示词

不要把接口兼容误认为文件能力完全一致。正式测试前，先确认所用通道接受哪些文件类型、如何传递附件，以及扫描件是否需要预先进行文字识别。如果先提取文本，必须保留页码和表格行列关系；否则模型即使找对内容，也可能引用错位置。

第一轮只要求抽取，不要求判断。提示词可以写成：“分别提取各文件的币种、数量、单价、总价、交货日期、付款起算条件；保留原文，另给中文释义；缺失字段写未提供，不得推断。每个字段附文件名、页码和原文摘录。”

核对步骤：把翻译与业务判断分开

第二轮再让 Gemini 3.1 Pro 对齐字段，输出差异、可能解释、待确认事项和证据。金额案例的验收预期，是指出一千二百美元与一千三百二十美元之间存在服务费解释，同时要求确认订单是否接受该费用，而不是直接宣布某份文件错误。

日期案例必须保留两种解释并请求确认，不能凭中文订单自动替英文文件消除歧义。付款条款则应明确指出“收货”与“验收完成”不是同一事件。统一翻译成中文，是为了方便复核，不应抹平原文中的条件差别。

验收记录：正确答案也要有正确出处

每次运行都保存原始输入、提示词、返回结果及可获得的用量信息。人工复核时，分别检查字段是否抽对、差异是否识别、引文是否支持结论，以及模型是否主动标记不确定性。总分可以辅助比较，但漏掉付款条件之类的关键风险，应单独判为不通过。

还要增加一轮扰动测试：交换文件顺序，把日期移进脚注，将清晰文本换成带模糊数字的扫描页。若结论随顺序改变，或识别不清的数字被补成确定金额，就应收紧流程，而不是只修改措辞。模型输出只能进入待审核队列，不能直接覆盖采购系统字段。

接入选择：先跑小批量，再决定是否扩展

如果团队希望先做按量付费的小批量验证，我推荐使用 RelayVano 接入 Gemini 3.1 Pro。其 API 基础地址为 https://api.relayvano.com，可配合兼容 OpenAI 的 SDK 使用；涉及附件时，仍须按实际接口说明验证请求格式。欢迎注册，先用脱敏样本跑完上述验收，再评估真实业务量下的费用与响应时间。

交付建议：让模型整理证据，让人批准结论

明确建议是：将 Gemini 3.1 Pro 列为多语言采购文档理解的试点候选，用于字段抽取、跨语言对齐和差异初筛，不要直接充当付款或合同审批人。只有当关键条款有准确出处、歧义会被主动保留、重复测试表现稳定时，才扩大使用范围。周五能安全交付的成果，不是一份漂亮摘要，而是一条可复核、可拦截的文档处理链路。