OKFDE｜80 万还是 42 万？AI 建议返利 56 万，谁敢签字？【Research #003】
合同、补充协议和邮件都读完了，系统还缺哪一步？
OKFDE RESEARCH · SCENARIO STUDY #003 · 场景研究笔记
Zoe｜OKFDE 技术布道师
本文用假设情境讨论年终返利与跨期对账，人物、对白、金额及处理过程均为示意创作，不对应真实客户。
01 / RESEARCH NOTES 研究笔记
两边各有依据，AI 又给了第三个数
王姐拿年度主合同核算，供应商应返八十万元。
供应商把年中签的补充协议翻出来。特价物料不参与年终返利，按这份约定排除相关采购后，只肯认四十二万元。双方差了三十八万。
王姐又打开一封后来的邮件。供应商的一位业务副总曾确认，考虑到后续扩大采购，特价物料可以纳入年度返利核算。
供应商认补充协议，王姐坚持邮件里已经答应过，谁也不肯在对账单上签字。
小王负责接入的 AI 已经把主合同、三份补充协议和往来邮件都读了进去。模型引用了双方的依据，最后给出一条建议，综合考虑限制条款与后续承诺，返利按五十六万元核算。
法务负责人老孙问：“这五十六万，哪份文件里约定过？”
小王往上翻了一遍引用，没有找到。
五十六万落在两个金额之间，看起来容易商量。但双方还没谈过这个数，也没有人授权系统替他们谈。
把 AI 的建议贴进对账单，原来争三十八万的两个人，又多了一笔要解释的账。
上一篇，我们讨论模型提取数字以后，怎样交给程序准确计算。这次连计算口径都还没定下来。材料里的每个字可以读对，采用哪一份约定，仍然需要核实。
02 / RESEARCH NOTES 研究笔记
盖了章的，就一定说了算吗？
小王想给系统补两条规则。补充协议优先于主合同，盖章文件优先于普通邮件。这样一排，四十二万元似乎就有了答案。
我查到的法律文本，要求我们在这里再停一下。
《民法典》第四百六十九条规定，符合条件的电子邮件也属于书面形式。第五百四十三条允许当事人协商一致变更合同，第五百四十四条则对变更内容约定不明确的情况作了规定。[1]
这封邮件能否改变返利约定，还要核实发送者的权限、双方是否就变更达成一致，以及原合同怎样约定变更手续。光看有没有公章，系统下不了结论。
日期也一样。后来发来的文件可能只适用于下一批货，某份较早的约定仍可能适用于本次结算。最高人民法院关于合同编通则的司法解释，也要求结合相关条款、缔约背景和履行行为等因素解释争议内容。[2]
小王于是调整工作台。系统先列出文件的形成时间、对应主体和适用范围，把提到同一批物料的条款关联起来。缺失的信息标为待核实，不能让模型自己补。
页面上留下两套测算。八十万元对应主合同口径，四十二万元对应排除特价料的口径；后来的邮件单独列在旁边，标明它可能影响哪些条款，还缺哪些核实材料。
时间轴能帮人找到冲突，不能自动替冲突排出法律上的输赢。
03 / RESEARCH NOTES 研究笔记
系统先交一张能拿去开会的表
重新开会时，老孙不必再从几十封邮件里找那句话。点开争议项，就能看到补充协议原文、完整邮件和各自对应的物料清单。
返利少了三十八万，具体差在哪些物料、哪个期间，计算表也列了出来。这个差额能复算，双方终于可以讨论同一组材料。
还有两件事需要分开。法务核实既有约定和授权依据，业务负责人决定是否提出新的协商方案。即使大家愿意谈五十六万元，这也应当成为一次明确的新协商，不能被记成 AI 从旧文件里算出来的合同金额。
在本文的参考设计里，系统保存争议处理记录。采用了哪套口径、哪些材料还不充分，都要说明；涉及新约定的，还需取得必要的对方确认，并走企业规定的授权程序。
企业内部两个人签字，并不会自动替交易另一方作出同意。双方仍有争议时，系统要保留各自的主张和处理进度。
口径确认以后，计算程序再生成对应的对账结果，由财务判断怎样入账、是否需要调整，以及适用哪个期间。法务的意见不直接变成一张调账凭证。
从材料到入账，参考流程可以简化为下面几步。
任何一处还没确认，争议项就保留待处理状态。系统应能说明卡在哪里、接下来找谁，避免大家重新把整包合同翻一遍。
04 / RESEARCH NOTES 研究笔记
对账谈妥了，接口又超时了
财务审核完本次处理方案，小王调用 ERP 接口写入凭证。页面等了一会儿，显示超时。
这时再点提交，可能让同一批调整进入系统两次。唯一的请求编号有助于识别重复操作，但目标系统也得支持相应机制。AWS 的安全重试说明专门讨论了请求标识、服务端去重和延迟请求的问题。[3]
本文的设计先把这笔写入转为“结果待核实”。后台执行程序暂停重复提交，再按原请求标识查询目标系统。查不到记录，也不能立即认定原操作没有执行。
需要限制的是这笔待核实操作，不能为了防重试，把所有关联合同都冻结得无法查阅。财务排障时还要用原件、审批版本和请求记录核对结果。
原凭证明确成功，系统记录结果；仍在排队或无法确认，就由指定人员继续处理。允许后续重试的条件，要在接入时和财务、ERP 维护方确认并演练。
对账口径确定以后，写入也要有准确的去向。不能让业务人员刚结束一场争议，又去查系统到底多记了几笔。
05 / RESEARCH NOTES 研究笔记
Zoe 会怎样看这个项目
我会请团队拿这组假设材料做一次演示，先不告诉模型最后该选哪个金额。
它需要把两套测算的依据列出来，指出邮件与补充协议冲突在哪里。缺少权限材料，就如实留下缺口。如果系统给了五十六万元，却无法解释这个数从何而来，我会先停掉自动生成结算建议的功能。
接着换一组材料。后来发出的文件明确只适用于下一年度，检查系统会不会拿它覆盖今年的约定。再补入一份有效的授权记录，观察系统能否更新待核实事项，避免始终机械地判定邮件无效。
模糊表述也要测。“原则上支持”后面如果还有条件，条件就得一起展示；“另行商定”仍未谈妥，程序不能擅自填入一个百分比。
最后模拟凭证写入成功、回执却没返回的故障。检查目标系统实际生成了几张凭证，再看页面状态，不能只凭按钮变灰就判定测试通过。
这些只是进入下一阶段验证的起点。真正使用以前，还要检查权限、资料完整性和异常处理安排。一次演示读出了所有条款，证明不了系统已经能处理所有合同争议。
我更愿意看一份仍有待确认事项、但每笔金额都能找到依据的对账草稿。至少下一位接手的人，知道该去问谁。
李总的对账立项备忘录
如果我是这套系统的采购负责人，会把下面几项写进演示和验收要求。
• 拿一组相互冲突的文件演示。不同金额对应什么依据，哪些信息仍需补充，必须能打开原件核对。
• 检查结论是谁确认的。内部审批和交易双方确认分别保存，修改金额或口径后，重新检查原授权是否仍然适用。
• 模拟一次写入超时。核对原请求、目标凭证和待办责任人，检查有没有重复入账，并按约定处理无法确认的结果。
这些条件没讲清楚，我会先批准隔离测试，不给系统开放正式账套的自动写入权限。
关于 OKFDE
我们关注 FDE，更关注 AI 真正落地之后发生的真实事件。
如果你也关注AI，关注产业，欢迎建联。
微信：okai-leo
公众号：OKFDE-AI不止Demo
参考材料 / REFERENCES
1. 《中华人民共和国民法典》，第四百六十九条、第五百四十三条、第五百四十四条。涉及书面形式与合同变更。
2. 最高人民法院关于适用民法典合同编通则若干问题的解释，第一条。涉及争议条款解释时需要考虑的因素。
3. Amazon Builders’ Library 安全重试与幂等接口。涉及请求标识、服务端去重与延迟请求处理。