企业官网建设流程全解析

客户上传一张付款水单，前端成功提取了金额、收款人和参考编号，接下来能不能自动把订单标成已付款？我的回答是先停一步：文档字段是用户提供的证据，到账状态应由有权确认它的系统提供。

这里讨论提取工具的数据边界，不提供跨境结算或报关判断。不同银行、格式与业务状态需要分别接入验证，不能让一份整齐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不应把提取进度画成支付进度

“正在识别”“字段待复核”“正在核验付款”适合分别呈现。提取成功时可以显示已读取的字段，但别立刻给订单绿色的已付款徽标。字段有出处，状态有责任方，用户才不会把两种成功混为一谈。

本地代码没有验证任何真实水单，也没有实现银行消息格式解析或资金核验。一个可靠的提取工具，应当让人更容易查证，而不是让未经查证的材料看起来更可信。