三套系统数据打通：用 AI 画流程图并标出人工兜底点

一句话结论

把三套系统的字段表交给 AI，让它先画数据流向、再逐节点标出「失败后谁接手」，输出流程图和人工兜底清单。

这篇解决什么问题

订单、库存、工单三套系统各管一段，中间靠人肉传话。出问题时运营说不清卡在哪，技术翻日志要半天，常常要等客户投诉才定位得到。

适用：系统已经上了，但跨系统数据还靠人同步的团队。不适用：三套系统之间已经做了完整事件驱动改造，或者压根还没上系统的情况。

开始前要准备什么

• 豆包网页版，免费够用，画图和推演都在对话里完成。
• 扣子账号一个，免费额度能撑起这活里的提醒节点。
• 三套系统的字段清单，导出即可，不必给全表。
• 近一周的真实异常记录，工单或客服反馈都行。
• 第一次做留出 1 到 2 小时，跑顺之后 40 分钟能收工。

具体怎么做

第 1 步 · 把三套系统的字段摊平

先别急着画图。三套系统的字段名经常对不上，图一画就歪，我在这上面返工过两次。

你是做系统对接方案的技术顾问。下面是三个系统能提供的字段，括号里是脱敏后的示例值。
【系统 A · 订单中台】
order_id（SO20240512001）、status（paid / shipped / closed）、sku_id（SKU8891）、qty（2）、created_at（2024-05-12 10:23:41）、buyer_note（要发票）
【系统 B · 库存系统】
sku_code（SKU8891）、available_qty（36）、locked_qty（2）、warehouse_id（WH02）、updated_at（2024-05-12 10:24:05）
【系统 C · 工单系统】
ticket_id（T20240512007）、order_id（SO20240512001，可为空）、type（缺货 / 破损 / 催发）、assignee（客服组）、created_at（2024-05-12 11:02:10）、resolved_at（空）
请做三件事：
1. 找出三张表之间能对上的关联键，指出哪些字段名不同但语义相同、需要做映射；
2. 列出对不上的字段，说明原因（命名不一致、粒度不同、缺主键、时间格式不同等）；
3. 输出一张 markdown 对照表，三列：「业务含义」「系统 A 字段」「系统 B / C 字段」，对不上的位置写「缺失」。
不要自己编字段，也不要给改进建议，先只做字段层的对照。

预期产出：一张三系统字段对照表，一眼能看出哪几个字段是关键打通点、哪几个是缺失的。

第 2 步 · 让 AI 画出数据流向

把上一步的对照表整段贴回去让它画。Mermaid 代码可以直接放进文档工具渲染，也让它同时给一份文字版。

基于上一步的三系统字段对照表，画一张数据流向图。
要求：
1. 用 Mermaid flowchart 语法输出，节点命名规则是「系统简称_动作」，比如「订单_创建」「库存_锁定」；
2. 只画主干链路，从订单创建到工单关闭，节点控制在 12 个以内；
3. 每条连线上用 code 格式标注传递的字段名；
4. 跨系统的连线用虚线，标签里写清同步方式，比如「接口实时」「定时 5 分钟」；
5. 图后面附一段纯文字版流程，按顺序编号，让不看图的人也能读懂。
对照表里没有的信息标成「待确认」，不要猜。

预期产出：一张不超过 12 个节点的流程图，跨系统连线标了同步方式和传递字段。

第 3 步 · 逐节点做失败推演

流程图看着顺，坏点都藏在连线上。这一步是全文里最值钱的地方，别跳过去直接要方案。

接着上面的流程图，逐个节点做一次失败推演。每个节点回答四个问题：
1. 这一步可能因为什么失败？给两种具体原因，要能落到字段或状态上；
2. 失败时数据停在哪、以什么状态停下？会不会出现「订单已付款但库存没锁住」这类不一致；
3. 失败之后谁先发现？系统告警、客户投诉，还是根本没人发现；
4. 如果一直没人处理，后果有多重，用一句话说。
输出一张表格，列为：「节点」「可能的失败」「失败后的数据状态」「谁先发现」「后果」。
只写你能从字段和链路推断出来的，不要写「网络异常」「接口超时」这种放到哪个系统都成立的答案。

预期产出：一张失败推演表，能看出哪些环节出了问题时，实际上是没人知道的。

第 4 步 · 生成人工兜底清单

不是所有节点都值得上监控。先让人接住那些「没人发现」的环节，成本低，见效也快。

把上面表格里「谁先发现」不是系统告警的行挑出来，生成一份人工兜底清单。每条包含：
– 动作名称：一句话说清人具体做什么；
– 触发条件：写成可判断的规则，比如「订单状态为 paid 且 locked_qty 超过 10 分钟未变化」；
– 执行角色：写「运营」「技术」「客服」这类岗位，不写具体人名；
– 处理时限：写「10 分钟内」「当天」这样的量级；
– 核对方式：人做完之后用什么办法确认数据真的对齐了；
– 升级路径：兜底也失败时，往上交给谁。
按「发现难度」从高到低排序，越难被发现的排越前面。结尾单独一段，列出暂时给不出兜底方案的节点，说明只能靠监控覆盖。

预期产出：一份带优先级的兜底清单，末尾附一段「暂无兜底」的节点名单。

第 5 步 · 把清单落进扣子

清单躺在文档里没人看。挑几条高风险的做成提醒，比开会强调十遍管用，我试过两种做法，差别明显。

我要在扣子上搭一个提醒机器人，输入就是上面这份人工兜底清单。请把每条转成一段工作流节点说明，格式固定为：
节点名 / 触发条件（自然语言描述，触发器我自己配）/ 需要查询的系统与字段 / 判断逻辑 / 满足条件后发给谁、发什么内容。
发送内容写成消息模板，控制在 60 字以内，必须包含单号、卡住的环节、建议动作。
能合并的条目合并，最终节点数不要超过 8 个。

预期产出：一份能照着搭的节点说明，每条带触发条件、查什么表、发什么消息。

实测记录

上一次用纯人工做同样的事，前后约了三次会对齐口径，散会各自回去补表，一周才画出能看的版本。

返工基本都发生在推演环节。AI 第一遍给的失败原因全是「网络异常」「接口超时」这种放之四海皆准的话，追问到具体字段和状态之后才变实在。

成本这块没什么可说的，豆包和扣子都在免费额度内跑完了整轮，没有额外支出。

最容易错的 3 个地方

1. 只给字段名不给示例值：AI 只能猜语义，映射必错。补脱敏示例值即可。
2. 一步要完整方案：它会跳过失败推演。先只要推演表，确认后再要清单。
3. 兜底写成「关注异常订单」：没人知道何时动手。每条必须有触发条件、岗位、时限。

可复用的东西

五段提示词其实是同一个套路：给约束、定格式、不给结论就不让它往下走。我把它们收成一份模板，顺序就是「字段 → 流向 → 失败点 → 兜底 → 落地」，下次换系统只改第一段的字段表，后面四段照抄。

流程图和兜底清单本身不新鲜，值钱的是「失败后谁接手」这句话被写进了每个节点。做完这活，运营和技术终于能在同一张图上说话，不用再各自猜。

你手上的三套系统，最容易卡在哪一段？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接