业务现场的手脚
- 企业微信接单、补问、确认、回执
- 本地智能体原件解析与任务调度
- T+Cloud ERP正式落单与独立查询
- 原件与台账只读来源，留存验收证据
企业微信截图PDF / 清单
AI结构化订单包字段归一 · 异常确认
系统写入 → 独立回读
业务链路示意CASE 02 · AI 交付滑启 · AI 订单中枢
滑启 · AI 订单中枢
制造业端到端订单流
把企业微信里的订单原件，变成 T+Cloud 中可验证的正式订单。本地执行、云端治理、人工确认，共同守住业务落地的每一步。
结果概览
4阶段
诊断 → 建模 → 建设 → 验收
8步
原件 → 确认 → 正式单号与回读
1个
受控写入入口 · 中央适配器
阅读口径：依据 2026-10-13 本人项目总结整理，展示流程与方法；单量、人效、差错率不作未经核验的提升承诺。
角色 / ROLE项目制 AI 落地负责人（FDE）
阶段 / SCOPE诊断 → 建模 → 建设 → 验收
交付 / STACK
FDE 现场部署企业微信腾讯云 ADPT+Cloud中央适配器业务本体 / 知识库
挑战 · Challenge
订单以截图、PDF、采购单与清单进入企业微信，客户名称、存货描述和规格各不相同。人工需要理解原件、匹配编码、录入 ERP，再核对结果，重复录入、歧义和漏单都可能发生在这条链路上。
企业微信订单截图PDF采购单规格清单
ROLE · 本人角色
以 FDE（深入客户业务现场）的方式负责 AI 落地：梳理真实订单流程，建立业务对象与字段规则，组织本地、云端和多智能体协同，定义正式单号与独立回读的验收标准。
01 / SYSTEM DESIGN
云端想得周全。
本地做得可靠。
云端负责标准化、门禁和复核；本地接入企业微信、业务文件和 ERP。中央适配器把判断与执行连成一条受控链路。
中央适配器
唯一写入入口
身份授权查重回读
判断与执行全程留痕
业务决策的大脑
- 腾讯云 ADP工作流与智能体编排
- 标准化与门禁确定编码、校验、阻断重复
- 独立复核检验字段与原始证据
- 知识检索与运行记录供给依据，沉淀可追溯记录
组合方案的关键是明确职责与写入边界。云端可用，并不代表本地执行链路始终可用；仍需进程守护、故障告警与人工接管。
02 / ORDER JOURNEY
一张聊天截图，
怎样成为正式订单？
从收到原件到发出回执，共八个步骤。点击任一步，查看责任、输出和停止条件。
业务入口
企业微信接单
把订单原件作为只读证据归档，让后续每个判断都能回到来源。
这一步的输出原件与来源记录
停止与放行规则原始材料只读，不覆盖、不改写。
本地执行
解析与身份识别
解析客户、存货、规格、数量和日期；根据稳定的人员标识确认下单身份，避免把昵称当作身份。
这一步的输出待校验的结构化订单包
停止与放行规则缺字段就补问，存在歧义就暂停。
云端治理
标准化与门禁
把客户和产品描述映射到受控编码，检查订单合法性，并用来源单据标识查重。
这一步的输出标准化订单包与门禁记录
停止与放行规则重复订单停止；不猜测模糊编码。
云端治理
独立复核
由独立复核流程检查字段完整性、原件一致性与证据关联。执行者不能只凭自己的判断放行。
这一步的输出复核结论与依据
停止与放行规则复核不通过，退回补充，不进入写入。
人工决策
负责人确认
向有权限的负责人展示客户、明细、数量与备注，获得对本次订单内容的明确确认。
这一步的输出与本次订单绑定的授权
停止与放行规则无明确确认不写入；内容改变后需重新确认。
本地执行
受控写入
通过中央适配器执行授权后的写入，按固定字段映射创建 T+Cloud 正式销售订单。
这一步的输出正式订单与执行记录
停止与放行规则唯一写入入口，禁止绕过检查直接落单。
结果验证
后台独立反查
从 ERP 后台独立查询新建单据，核对客户、明细、数量、日期与状态，保存验收证据。
这一步的输出正式单号 + 独立回读证据
停止与放行规则接口返回成功不等于验收通过。
闭环完成
回执与归档
只有后台反查通过后，才回传正式单号和成功回执，并关联台账、原件与执行记录。
这一步的输出可追溯的订单档案
停止与放行规则失败保留证据并转人工，禁止虚报成功。
01 / 08
正式单号 ＋ 后台独立回读 ＝ 成功
“AI 说完成了”不是验收依据。只有业务系统中的真实结果，才能关闭这一单。
03 / BUSINESS KNOWLEDGE
先把业务讲清楚，
再让 AI 理解业务。
本体定义“是什么、怎么关联”；知识库提供“有哪些依据”。两者一起为智能体的判断与执行服务。
业务关系示意 · 无真实客户数据
统一名称、编码与关系，歧义进入待确认清单。
- L3
智能体与业务入口
用知识问答、校验和办理业务。
- L2
知识库：可检索的内容
实体卡、资料文档、词表与出处。
- L1
本体：业务骨架与规则
客户、存货、规格、关联与消歧。
- L0
权威来源：事实与证据
ERP 主数据、订单原件与业务档案。
多智能体，共用一份项目事实
统一维护项目状态、规则与变更记录；执行、复核和编码分别承担职责，避免各自记住不同版本。
复制方法，重新配置现场
业务对象 → 字段与规则 → 最小订单闭环 → 测试验收 → 授权上线。可复用骨架、测试和 SOP，客户数据与权限在新现场配置。
我怎样交付 · FDE PROCESS
四步把分散订单流收拢成一条可复制、可隔离、可验收的链路。
01 / 04
流程诊断
沿真实链路梳理，定位重复录入与关键确认点，选定一条高频、可回退的最小链路作试点。
接单→生产→仓储→发货→财务
真实链路梳理 · 试点选定最小可回退链路
02 / 04
业务建模
把多源资料归一为结构化「订单包」，建立确定性字段映射，缺失或歧义时硬停止而非猜测。
多源资料→订单包→字段映射
确定性字段
客户存货SKU颜色尺码
缺失或歧义 → 硬停止，不猜测
03 / 04
跨系统协同
API 优先、受控浏览器备用，以身份、权限、查重、独立复核、动作白名单控制写入风险。
API 优先受控浏览器备用
写入风险控制
身份权限查重独立复核动作白名单
跨系统协同 · 适配器结构示意
04 / 04
验收交付
以正式业务单号 + 独立后台回读作为「成功」的唯一证据，配置失败队列、人工接管、备份回滚与分层，产出 SOP 与复制部署指南。
- 正式业务单号
- 独立后台回读
- 失败队列
- 人工接管
- 备份回滚
- DEV / UAT / PROD
- SOP
- 复制部署指南 v1.0
八道验收门 · 交付纪律
成果 · Outcome
从企业微信到 T+Cloud，形成可验证的订单主链路与可复用的交付方法。
- 多源订单归一为结构化「订单包」，确定性字段映射
- 本地执行 + 云端门禁复核，以中央适配器作为唯一写入入口
- 正式单号 + 独立回读作为唯一成功证据
阶段边界：主链路进展依据本人总结；MES 等下游协同仍按阶段扩展。单量、人效与差错率以实际运营数据为准。
可复制的交付物
规则骨架测试用例部署模板SOP复制指南
复盘 · Learnings
01
能复制的是「能力」不是「数据」，把规则、骨架、测试与模板沉淀为产品包，把客户身份、主数据与密钥留在现场重新配置。