客户上传一张付款水单前端成功提取了金额、收款人和参考编号接下来能不能自动把订单标成已付款我的回答是先停一步文档字段是用户提供的证据到账状态应由有权确认它的系统提供。这里讨论提取工具的数据边界不提供跨境结算或报关判断。不同银行、格式与业务状态需要分别接入验证不能让一份整齐JSON替代核验。Swift的UETR说明介绍了用于支付追踪的36字符参考标识。参考号适合关联查询仅从截图提取到一个格式正确的编号不能据此推断资金状态。这是提取系统应保留的证据边界。给证据标注层级我会分别存文档原文、规范字段、人工复核结果和支付系统状态。即使这四层暂时值相同也不要合并成一个paid布尔值。这样后续发现票据被替换、字段错读或状态延迟时系统还有能力解释变化来自哪里。2026年10月19日的Clairic提取模型预览展示了专门提取模型这一方向。能提取字段仍不等于应用已经获得确认付款的权限。这里是应用设计上的推论不是对该产品真实识别效果的测评。内图把文档分支停在复核队列只有经过业务核验的状态才能推动订单。这条线应由服务端控制不能由浏览器隐藏按钮代替。避免一个含糊的成功标记下面只验证状态组合不连接银行、支付平台或模型。样本是教学数据。const assert require(node:assert/strict); function decision(record) { const states [unknown, pending, confirmed, rejected]; if (!states.includes(record.paymentState)) throw new Error(invalid state); if (record.paymentState rejected) return review; if (record.paymentState confirmed record.amountMatched true) return can_reconcile; return wait_for_verification; } assert.equal(decision({ extracted: true, paymentState: unknown, amountMatched: true }), wait_for_verification); assert.equal(decision({ paymentState: confirmed, amountMatched: true }), can_reconcile); assert.equal(decision({ paymentState: confirmed, amountMatched: false }), wait_for_verification); console.log(payment-evidence: 3 assertions passed);保存为payment-evidence.cjs运行node payment-evidence.cjs。can_reconcile只是本例的候选状态真正入账还需核对币种、对象、手续费、重复交易及业务规则不能直接用它修改生产账目。UI不应把提取进度画成支付进度“正在识别”“字段待复核”“正在核验付款”适合分别呈现。提取成功时可以显示已读取的字段但别立刻给订单绿色的已付款徽标。字段有出处状态有责任方用户才不会把两种成功混为一谈。本地代码没有验证任何真实水单也没有实现银行消息格式解析或资金核验。一个可靠的提取工具应当让人更容易查证而不是让未经查证的材料看起来更可信。
