OKFDE｜AI能读懂采购单，为什么还不能直接审批？【Research #001】

OKFDE RESEARCH· SCENARIO STUDY #001 · 场景研究笔记

本文涉及的情节、对白、数据及项目过程均为基于工程现实的示意创作，不对应真实客户，亦不代表 OKFDE 已完成的项目能力。

01 /  RESEARCH NOTES 研究笔记

这笔折扣，谁同意的？

一张送货单上，供应商写了临时让利 5%。附件里有聊天截图，提到按此前约定的特批价格结算。采购系统里的合同单价却还是原价。

在这个假设里，小王正在帮客户做 AI 审核。系统读出了数量和单价，也找到了折扣备注，把几份材料里不同的价格标了出来。

审核员王姐点开那条提示。折扣算得对，截图里的话也找到了，但她没有继续提交。

她把单子转给李总，问这笔特价有没有正式批过。

李总检查附件，发现截图只能说明有人提过折扣。那个人有没有权批准，约定是否适用于这批货，材料里都没交代清楚。

单子先停住，采购人员去补授权记录。

这一步容易让工程团队为难。模型已经读对了，还要补什么？在这张单据上，缺的是企业允许采用这个价格的依据。换一个更强的模型，也得有人提供这份材料。

我想用它解释一件事。AI 能替审核人少翻几页附件，企业还得决定找到的信息能拿来做什么。

02 /  RESEARCH NOTES 研究笔记

小王需要改的那句提示

原来的提示写着“发现特批折扣，建议通过”。王姐看到“特批”两个字，很容易以为系统已经检查过授权。

小王把它改成“发现折扣说明，与合同价格不同，需补充审批依据”，并让王姐能直接打开那张送货单和完整的相关对话。

这样，王姐可以检查系统有没有读错，也能看出还缺什么。她不用猜那句建议从哪里来。

文档识别工具已经能提供文字在原文件中的位置。例如微软的文档分析结果可以带上页码和区域坐标，供应用定位抽取内容。[1]

不过，标出截图里的字，证明不了截图真实；截图真实，也还要查发送者的权限。系统应该把这些待核实事项保留下来。

这次修改值得测试。王姐找到依据用了多久，是否仍要重复翻附件，都可以记录。界面看起来清楚，只说明设计往前走了一步。

03 /  RESEARCH NOTES 研究笔记

批准的内容，还得说清楚

采购人员补齐材料后，单子送到有权限的负责人那里。这里假设企业制度要求，由他确认这次异常价格。

负责人同意的是这批零件的折扣。系统接下来可以把获批价格写入指定采购记录，付款仍按企业原有流程处理。

如果界面只放一个“同意”按钮，批准范围容易含糊。王姐确认单据要素齐全，负责人批准价格异常，两个人做的事需要分别记录。

还要保存他们当时看到的内容。若批准后有人改了金额，系统应重新检查审批是否仍然有效。否则，原来的同意就可能被用来执行后来改过的单据。

李总关心这件事有道理。他以后检查一笔交易，需要知道是谁按什么依据批准了哪项操作。小王则要把这些要求写成系统可以检查的条件。

在本文的设计里，审核页面和执行程序都检查权限。页面上的按钮只允许符合条件的人操作，真正写入时再核验一次，避免等待期间的权限变化被忽略。

04 /  RESEARCH NOTES 研究笔记

页面超时了，先别再点一次

批准完成，小王调用接口，把结果写回采购系统。页面等了一会儿，显示请求超时。

王姐准备再点提交。小王先把这笔操作挂起，让排障人员核对结果。

超时意味着调用方没有及时收到答复。远端系统可能没收到请求，也可能已经写入，只是答复没传回来。若后一种情况发生，再提交一次就有重复记账的风险。

工程上把一种防重复机制叫作幂等。同一笔操作重复提交，接收系统仍按约定只执行一次。请求标识要保持一致，接收方也得真正识别它。AWS 的公开工程说明专门讨论了这类重试问题。[2]

旧系统未必支持这种机制。小王需要查清怎样核对原操作结果，不能只在自己的程序里加一个编号，就宣布重复问题解决了。

查询暂时没返回记录，也不足以证明原请求没执行。无法确认时，单子继续显示“结果待核实”，由指定人员处理。用户看到这个状态，就知道此刻不能靠反复点击解决。

这会让个别单据停得久一些。排障人员必须有明确的处理安排，否则挂起队列会越积越多，业务仍然做不下去。

05 /  RESEARCH NOTES 研究笔记

Zoe 会怎样看这个项目

走到这里，采购单已经经过了好几个人。AI 找出差异，采购人员补材料，有权限的人作决定。执行超时以后，小王还要确认结果。

这些工作都影响系统能不能继续使用。模型抽取准确率可以单独测试，验收也需要检查异常价格被送给了谁，以及超时后会不会重复写入。

我建议先拿一组历史异常单据，在隔离测试环境里走完这个过程。请业务人员核对预期处理方式，争议样本单独保存。技术故障用测试接口模拟，避免拿真实付款试错。

记录处理耗时的时候，把等待审批和人工操作分开。新系统省下翻附件的时间，如果又让王姐多做一遍录入，交付团队就需要继续修改。

最后再安排一次故障测试。让测试系统已经写入成功，却不向页面返回答复。请测试人员再次点击提交，检查目标记录和页面状态。

如果目标系统多出了一张单据，这个版本就还不能上线。小王要留下原请求记录，修好重复处理，再把同一项测试跑一遍。

关于 OKFDE

我们关注 FDE，更关注 AI 真正落地之后发生的真实事件。

如果你也关注AI，关注产业，欢迎建联。

微信：okai-leo

公众号：OKFDE-AI不止Demo

邮箱：leo@okfde.net

参考材料 / REFERENCES

1. Microsoft Learn，文档智能分析结果说明。参考其中的页码、区域坐标与文本位置。

2. Amazon Builders’ Library，安全重试与幂等接口。参考其中的请求标识复用与延迟请求处理。