产出能比对
一张草稿单对着原文看，字段对不对、数量差没差，业务员三十秒就能判。说不清对错的 AI，没法验收，也没法追责任。
先说清楚定位
窄，不是因为保守，是因为要能验收
场景越窄，越能回答三个问题：它做对了吗？做错了会怎样？它到底动了哪些数据？ 这三问答不上来，功能上得再热闹，客户也不敢让它碰真单子。
错了不致命
它交出来的是草稿，后面仍是原来那道审核、那次信用校验、那笔过账。判错最多让人多改两下，不会把账做坏。
边界不用猜
它只在两个已有的东西之间搬数据：单据模型，和审批/过账引擎。不新增流程，也不改任何一条口径。
所以官网上不会出现「AI 帮你经营工厂」这种话——那既不能验收，也没法追责任。
能写下来的只有一句：把来信变成草稿，你确认了才算数。
一条链路
一封邮件，怎么变成一张能审的单
五步，每步都写着机器做哪半段、人保留哪半段。中间任何一步断了，后面都不许硬走。
01
收进来
- 机器
- 邮件正文、微信转发的文字、企业微信推来的消息，统一落成一条「待处理来件」，原文一字不动地留着。
- 人
- 这封信要不要接、归谁跟，仍然由人决定；不相关的来件直接丢掉，不进流程。
02
拆字段
- 机器
- 从一段自然语言里找出客户、料号规格、数量、单价、交期——包括「6061 铝板 3mm，先来 200 张」这种口语写法。
- 人
- 拆出来的每个字段都带置信度；低于阈值的留空标黄，不替你补一个「看起来合理」的数。
03
对主数据
- 机器
- 按客户简称、料号别名、历史成交去匹配已有档案，给出候选与匹配依据，而不是直接改档案。
- 人
- 匹配不上就是匹配不上：列三个候选让人点。新建客户或物料仍走主数据页面，不走 AI。
04
生成草稿
- 机器
- 落成一张销售订单草稿：行、数量、单价、税率、交期。开单走的是原来那条保存链路，单号、金额都由服务端重算。
- 人
- 草稿在列表里长得跟手开的单一样，只多一个来源标记；改哪个字段就改哪个，改完走原来那道审核。
05
人确认
- 机器
- 草稿、来源、置信度、缺哪些必填项，一屏摆完；点确认后进现有审批，信用校验与过账照旧。
- 人
- AI 到此为止。核价、承诺交期、放不放行是人的事——最后一步永远是一双手点下去。每次改动都记进修正台账：同一个写法被绑到同一档案满两次，下次就按它自动匹配；规则从人的选择里长出来。
parsed-order.json
{
// 来件留着原样，后面能翻回原文
"source": "mail/2026-11-02-0931.eml",
"customer": { "raw": "宏远机械 王工", "match": "C-0021", "score": 0.96 },
"lines": [
{ "raw": "6061 铝板 3mm 200 张",
"item": "M-0188", "qty": 200, "price": null, "score": 0.93 },
{ "raw": "M8 沉头螺钉 若干",
"item": null, "qty": null, "score": 0.31 }
],
"delivery": null,
// 缺的列出来，不猜、不套历史价
"needsReview": [
"第 2 行未匹配到料号，也没有数量",
"第 1 行没写单价",
"交期只写了「月底前」，没落成具体日期"
]
}它交出来的不是答案，是「半成品 + 待办」
这份解析结果里最要紧的不是匹配成功的那两行，而是三处 null 和下面那三条
needsReview。系统据此做两件事：草稿里对应字段留空标黄，页面顶部提示还差哪几项。
-
认出客户是「宏远机械」，匹配到档案
C-0021，置信度 0.96——只有在这种把握下它才敢自动填，否则就让人从候选里点。 - 第一行认出了料号与数量，单价没有——那就空着，等业务员填。
- 第二行只有「螺钉 若干」：料号与数量都不给，只留原文，不硬凑一行。
这段结构也可以直接当接口契约看：AI 服务只产出这种 JSON，落单由服务端做， 这样「模型换了」和「单据逻辑改了」互不影响。
三个场景
只挑小型制造与贸易里最费手的三件事
不挑「最难的」，挑「重复最多的」。这三个场景的共同点是：输入是人写的自然语言， 输出是系统里本来就有的一张单——中间那段纯属搬运。
订单来信 → 销售订单草稿
- 吃什么
- 客户的采购邮件（专用邮箱定时收）；微信里复制出来粘进去的一段话；企业微信回调推来的消息。
- 吐什么
- 一张销售订单草稿，走原来的审核与信用校验；缺料另到缺料分析页按工单展开。
- 谁签字
- 业务员核价与交期，采购核供应商与批量。
- 「先来 200 张，月底前要」这种写法也认：数量与交期各进各的字段
- 价格没写就留空，绝不拿上次成交价顶上——顶上去的单子最容易被顺手审过
- 一封邮件里写了三个品种，拆成三行，而不是揉成一张大杂单
- 人改过的字段记进修正台账；同一写法被绑到同一档案满两次，自动固化成别名，下次不用再点
库存与在途 → 催料待办
- 吃什么
- 已有的安全库存、在途采购、未清工单需求——这三样系统里本来就有。
- 吐什么
- 今天该催的三条，每条写清为什么催：低于安全库存多少、哪张工单等着它、供应商承诺哪天到。
- 谁签字
- 采购看一眼，该打电话打电话。AI 不发邮件、不询价、不下单。
- 排序按「停线风险」而不是缺口数量：缺 3 个关键件比缺 300 个包装袋更要命
- 给的是理由不是结论：「A 料按当前领用速度只够 4 天」，人能立刻判断对不对
- 预警本来就在，AI 做的是把它写成一句人话，并挂成今天要处理的待办
往来对账 → 差异清单
- 吃什么
- 客户对账单的文本（粘贴进来），加上系统里的应收明细。
- 吐什么
- 一张差异清单：对方有我方无、我方有对方无、金额不一致、我方已收清但对方仍列着。逐条留档，待办未自动生成。
- 谁签字
- 会计逐条核；核销金额仍由人填，走原来那套收款核销。
- 先比总额再比单据：总额都不平，就不用逐行了
- 「他方有我方无」单独列一栏——可能是漏开单，比几块钱的差额更值得追
- 识别不出的行如实留在「未匹配」里，不合并、不四舍五入、不凑平
五条硬边界
先把「它不会做什么」写死
客户真正在意的不是它有多聪明，是它会不会乱来。这五条不是产品策略，是代码里已经定死的位置： AI 服务交完草稿就退出，后面整条链上都没有它的位置。
不自动审核
产出永远是草稿。审批链、信用额度校验、过账走的是原来那段代码，AI 不在链上，也拿不到那颗审核按钮。
不编数据
缺数量、缺交期、缺规格，就留空并标出来。宁可让人填两格，也不给一个「看起来合理」的假数——假数比空着危险。
不出内网
来件只在你的实例里解析，模型可本地或私有化部署。要接云端模型，得在配置里显式打开，页面上会写明数据发到哪。
不碰价格与账
不改单价、不做核销、不生成凭证。它给依据——原文怎么写、历史成交多少——决定仍由人做。
有据可查
每张草稿挂着它的来源与置信度；谁改了什么记在修正台账里，别名怎么来的也查得到。查得到出处，才敢让它参与业务。
现状
现在到哪一步，写清楚
没做完的不装作做完了。下表逐条标了状态：哪些已经能用、哪些只做了一部分、哪些明确不做—— 这张表会随版本更新，而不是一次写完挂着不动。
| 能力 | 状态 | 说明 |
|---|---|---|
| 六类主数据 xlsx 导入（预检到行列、整批回滚） | 已具备 | 解析的上一代做法：模板固定，人照着填 |
| BOM 多层展开与缺料分析 | 已具备 | 采购建议的算法底座，AI 不重算，只调用 |
| 安全库存预警与在途统计 | 已具备 | 催料待办的数据来源 |
| 应收应付账龄与收款核销 | 已具备 | 对账任务的比对对象 |
| 单据草稿态 + 服务端审批门禁 | 已具备 | 草稿能落库、审核拦得住，AI 的产出才有地方放 |
| 人工修正台账与别名自动固化 | 已具备 | 改过哪些字段、改了几次都记账；同一写法满 2 次且无歧义才生效，可随时停用 |
| 邮件 / 粘贴文本 → 订单草稿 | 部分 | 邮件与粘贴两条入口已跑通，含复核、修正台账、草稿开单；照片与 PDF 待 OCR |
| 微信 / 企业微信消息直接接入 | 部分 | 回调端点已实现（验签 → 落库 → 入队），需企微后台建应用并配回调；未配置前用粘贴 |
| 对账单差异识别 → 对账任务 | 部分 | 四类差异（对方有我方无 / 我方有对方无 / 金额不一致 / 已收清仍列着）的比对与留档已能跑；尚未把每条差异挂成待办任务 |
| 自动审核 / 自动定价 / 自动付款 | 不做 | 这三件事错了直接赔钱，且没法用「改两下」挽回 |
表里前五行不是凑数：没有草稿态、没有审批门禁、没有缺料分析，AI 产出的东西无处可落。
所以这条线不是推倒重来，而是往既有单据模型上再开一个输入口——算法用的还是原来那套。