让存量系统 AI-ready：从可靠写入说起

问题：不是模型不够强，是数据不敢用

在流程化工的现场，我们反复见到同一种情形：企业已经上了 MES、ERP，也采购过若干套系统，但只要谈到"让 AI 参与判断"，技术负责人就会犹豫——因为没人敢担保底下的数据是对的。

这种不信任往往来自很具体的旧伤：

• 夜里批量写入失败，早上才发现，中间的记录不知去向；
• 手持终端在车间信号不好的地方提交，界面显示成功，系统里却查不到；
• 重试怕重复、不重试怕丢单，于是操作员养成了"多点几次再去系统里翻一遍"的习惯；
• 出了异常想追溯，却发现关键环节的记录缺了一段，或者被人改过。

只要这些还在发生，任何"智能"都建立在流沙上。所以我们的第一步从来不是接模型，而是把写入做到可靠。

方法：把"写入"当成一等公民

可靠写入不是一个功能，而是一组彼此配合的机制。我们的做法有五条：

一、写入唯一入口。 所有业务写入必须经过统一的动作层，不允许业务代码各自开事务、各自拼 SQL。入口收敛之后，事务纪律、审计、留痕才有可能被统一保证——这也是许多老系统积重难返的根因：写入散落在几百处，没人说得清。

二、幂等键。 每一笔写入都由客户端生成一个唯一操作标识，服务端"先查后写"：命中过就直接返回上次结果，而不是报错或写第二条。有了它，重试才是安全的。

三、在线优先 + 最小持久命令。 关键写入默认要求在线：断网时明确阻止并提示，而不是在本地"假装成功"。同时在提交前落一份最小命令记录，仅用于覆盖"服务端已提交、但响应丢了"这种情况——恢复后凭同一标识去查询结果，收敛为"已提交"或"被拒绝"。

四、批量按逐条语义。 批量提交不得因为其中一条非法就整批回滚。每条独立成败、独立可查，返回逐条结果。这是对"一条脏数据毁掉整批"的直接修正。

五、死信队列与告警。 重试超限或持续异常的操作进入死信队列，并触发值班告警。没有告警的可靠性是纸面上的可靠性。

在写入之外，还有三件同样属于地基的事：审计 append-only（审计与业务写在同一个事务里，数据库层面收回修改与删除权限，做到"有业务必有审计"且事后无法抵赖）、读写物理隔离（报表与分析永远不和现场写入抢资源）、数据生命周期契约（每张表建表时就声明保留、归档与增长策略，避免"只进不出、越查越慢"）。

如何验证：可以当场演练的验收方法

这部分才是我们认为最重要的——方法要能被验证，否则就是承诺。以下演练可以在验收时现场执行：

演练	做法	通过标准
断网写入	断网后提交 N 笔关键写入	每笔都被明确阻止；0 笔"假成功"；0 笔进入业务库
响应丢失	提交瞬间切断网络	恢复后凭同一操作标识收敛；0 丢单、0 重复
服务重启	写入高峰重启后端 / 数据库	未决写入收敛，无脏数据
重复投递	同一操作标识重放 10 次	业务表仅 1 条，其余按"重复"返回
脏数据隔离	批量中混入若干非法数据	合法项成功、非法项被拒且原因可读，不整批失败
浸泡	模拟三班倒节奏连续跑 24 小时	写入成功率 ≥ 99.9%，死信为 0
追溯回放	任取一个业务对象导出全生命周期	时间线无断点；尝试修改/删除审计记录被数据库拒绝

我们也把性能写成可验收的预算，例如：单笔写入 P99 < 500ms、批量 50 条 P99 < 3s、报表满载时写入链路 P99 劣化 ≤ 10%。能被拒收的指标，才是真指标。

诚实边界

本文所述做法属于已实证：它们是我们在真实产线交付中执行的工程纪律与验收条款，不是设想。但要说明三点：

1. 这些是工程纪律，不是产品魔法——它们需要在项目一开始就写进规范与门禁，事后补做代价很高。
2. 具体阈值（并发、TPS、保留年限）必须按现场容量重新标定，不能照搬。
3. 做好可靠写入并不等于"有了 AI"。它解决的是"数据敢不敢用"，而不是"AI 有多聪明"——但没有它，后面的一切都不成立。