Session: 2026-05-20 10:54:19 GMT+8

• Session Key: agent:main:dingtalk-connector:direct:17600802669338842
• Session ID: df054b62-9a76-4fa5-a6ae-fba41077ef31
• Source: dingtalk-connector

Conversation Summary

user: 我想要给U8 ERP做一个AI智能助手，你给一些建议 assistant: 可以，而且我建议你不要一上来就做“全能型 AI 助手”，先做一个能真正落地的 U8 场景助手。

我建议的方向

1）先选 1~2 个高价值场景

最适合先做的，不是“陪聊问答”，而是这些：

• 采购助手
• 查采购在途
• 查请购/采购/到货/入库进度
• 催料风险提示
• 供应商交期异常分析

• 销售交付助手
• 查订单是否能按期交付
• 缺料原因分析
• 预计完工/到货时间推测
• 自动生成交期回复建议

• 仓库助手
• 查库存、可用量、锁定量、在途量
• 找替代料
• 异常出入库识别

• 财务/成本助手
• 查材料成本波动
• 按你们口径做成本解释
• 自动生成月度分析说明

如果让我选，第一阶段最值得做的是：销售交付助手 + 采购执行助手。 因为这两个场景最容易直接产生价值，也最适合和 AI 结合。

2）不要让 AI 直接碰核心业务表写入

第一版建议：

• 只读查询
• 分析解释
• 生成建议
• 生成报表/回复话术
• 风险预警

先别做：

• 自动审核
• 自动下单
• 自动改单
• 自动过账
• 自动审核单据

原因很简单：U8 里“看起来只是改个字段”，实际上可能牵动权限、流程、财务口径和审计责任。

所以第一阶段最稳的是：

AI 做“大脑”和“解释器”，U8 继续做“交易系统”。

3）推荐的系统架构

可以按这层来搭：

A. 数据层

从 U8 拿数据，常见方式：

• 直连 SQL Server
• 读取现有报表/中间表
• 调用 U8 开放接口（如果你们环境有）

建议优先：

• 只读账号
• 建一层 业务视图 / 中间表
• 不让 AI 直接读特别底层、特别散的原始表

也就是：

U8 原始表 → SQL 业务视图/数据服务 → AI 助手

这样后面维护会轻松很多。

B. 业务规则层

这一层很关键，别全交给大模型。

比如：

• 什么叫“可交付”
• 什么叫“采购在途”
• 交期怎么推算
• 安全库存怎么判定
• 全月平均价怎么解释
• 哪些状态属于异常

这些都应该写成：

• SQL 规则
• Python/Node 规则
• 配置化规则

AI 负责：

• 理解问题
• 调用工具
• 汇总结果
• 用自然语言解释

也就是：

确定性规则 = 程序 模糊解释 = AI

这是成败关键。

4）你这个助手最好具备的 5 个能力

能力一：自然语言转业务查询

比如用户问：

• “这个销售单还能不能按时出？”
• “为什么这个物料一直没回来？”
• “帮我看 101 账套这个料最近采购异常”
• “有哪些订单会因为缺料延期？”

AI 要能把问题拆成：

• 单号 / 物料 / 客户 / 日期范围
• 调哪个查询
• 最后再组织回答

能力二：多表关联后的“解释能力”

很多人不是缺数据，而是缺解释。

例如 AI 不只是回答：

• 当前库存 120
• 在途 300
• 已分配 260

而是要进一步说：

• 表面库存够，但可用量不足
• 主要卡在采购单未到货
• 预计风险出现在 5 月 28 日之后
• 建议先协调 A 供应商或改用替代料 B

这个才叫“助手”。

能力三：异常检测 / 风险预警

很有价值：

• 长期未关闭采购单
• 交期连续延期的供应商
• 销售订单承诺日期临近但物料未齐套
• 呆滞库存但又重复采购
• 单据流程卡滞

这类功能甚至比“问答”更值钱。

能力四：自动生成业务输出

比如自动生成：

• 交期回复
• 催料清单
• 每日异常日报
• 周度采购跟踪总结
• 给老板看的风险摘要

AI 特别适合做这个，省很多人力。

能力五：知识库问答

把这些内容接进去：

• U8 操作手册
• 你们内部 SOP
• 常见 SQL 分析文档
• 业务口径说明
• 历史案例

这样助手不仅能查数据，还能回答：

• “这个字段是什么意思？”
• “为什么这个单据不能审核？”
• “采购插件里制单人为什么不对？”
• “这个流程该找谁处理？”

5）落地时最容易踩的坑

我直接说几个最常见的。

坑一：一开始就想做全模块

结果范围太大，最后每个模块都半成品。

建议：只打一个闭环。 比如先做：

销售订单交付分析 → 缺料判断 → 采购在途追踪 → 生成交期回复

这个闭环做成，就已经很有用了。

坑二：把 AI 当数据库本身

AI 不能代替清洗过的数据模型。

如果底层数据关系乱、口径不统一，AI 只会把混乱说得更像那么回事。

所以一定先做：

• 指标口径统一
• 核心 SQL 固化
• 关键字段字典化

坑三：没有权限隔离

不同岗位看到的数据不一样：

• 销售能看订单
• 采购能看供应商与到货
• 财务能看成本
• 老板能看汇总
• 普通员工不该看到敏感价格

所以助手一定要做：

• 账号权限
• 数据范围控制
• 操作日志

坑四：回答“像对的”，但其实不准

所以要让回答尽量带上：

• 数据来源
• 截止时间
• 判断依据
• 不确定项

比如：

截至 2026-05-20 09:30，物料 A 当前可用库存 80，在途采购 200，最近到货承诺为 2026-05-24；若供应商按期交货，则订单 SOxxxx 大概率可满足首批出货。

这种就靠谱很多。

6）我建议你的实施路径

第一阶段：做“查询 + 解释”

目标：

• 聊天式提问
• 自动调用 SQL / 接口
• 返回结构化结果 + 人话解释

先做 3 类问题：

1. 查库存/在途
2. 查订单交付风险
3. 查采购执行异常

第二阶段：做“日报/预警”

目标：

• 每天自动跑
• 推送异常
• 自动生成摘要

比如：

• 今日延期风险订单
• 今日未齐套订单
• 今日超期采购单
• 今日异常供应商

第三阶段：做“流程辅助”

目标：

• AI 帮人，不替人背责

例如：

• 自动生成交期回复草稿
• 自动生成催料消息
• 自动整理会议纪要
• 自动归档分析结果

第四阶段：谨慎做“半自动动作”

只建议做低风险动作：

• 创建待办
• 发送提醒
• 生成草稿单据
• 提交审批建议

不要急着让 AI 直接改 U8 正式单据。

7）技术上我建议怎么做

如果你是准备自己推动，我建议这个组合很稳：

• 数据层：SQL Server + 只读视图
• 服务层：Python / FastAPI
• AI 编排层：OpenClaw 或类似 Agent 框架
• 知识库：内部 SOP + SQL 文档 + U8 说明书
• 前端入口：钉钉 / 飞书 / Web
• 输出：聊天问答 + Excel/日报 + 风险推送

一个很实用的模式是：

AI 不直接碰 U8 表 AI 调你封装好的查询工具和业务接口

这样可靠很多，也方便审计。

8）如果让我帮你定义第一版，我会这样定

产品名

U8 智能交付与采购助手

第一版核心功能

• 按销售单查询交付风险
• 按物料查询库存/在途/请购/采购/到货状态
• 自动识别缺料原因
• 自动输出交期回复建议
• 输出采购催办清单
• 每日推送异常订单摘要

第一版目标用户

• 销售跟单
• 采购
• PMC / 计划
• 供应链负责人

9）我对你的直接建议

如果你现在准备开干，先别问“能做多智能”，先定这三件事：

1. 先服务谁

• 销售？
• 采购？
• PMC？
• 财务？

1. 先解决哪个高频痛点

• 回交期慢
• 查缺料麻烦
• 采购跟催低效
• 数据很多但没人能解释

1. 先统一哪几个核心口径

• 可用库存怎么算
• 在途怎么算
• 齐套怎么算
• 交期风险怎么算

这三件事定了，项目就能落地。

如果你愿意，我下一步可以直接帮你出一版更实用的东西，任选一种：

1. 《U8 AI 智能助手整体方案》
2. 《第一阶段功能清单 + MVP 范围》
3. 《技术架构图 + 模块拆解》
4. 《适合你们公司的 10 个具体 AI 场景》

如果你想，我也可以直接按你现在的业务背景，帮你先写一版“销售交付 + 采购跟催”MVP 方案。 user: wl assistant: 1、WL-0132 ：openclaw拆解，适合企业内部使用的方案 2026-05-18；

2、WL-0130 ：个人知识库搭建 2026-05-18；

3、WL-0129 ：企业知识库搭建（统一搜索入口，可以考虑每个来源都做索引） 2026-05-18；

4、WL-0128 ：u8erp+AI 2026-05-15；

5、WL-0127 ：从文件服务器（群晖）自动检索文件 2026-05-14；

6、WL-0124 ：jxd Gemini 增加提示词优化功能 2026-05-12；

7、WL-0121 ：编程规范整理，统一存放，包括使用代理，使用路径方式，readme 文档包含模块等 2026-05-12；

8、WL-0103 ：Hermes 原理分析 2026-04-27；

9、WL-0101 ：武平物料标识卡生成 2026-04-26；

10、WL-0100 ：武平 openclaw 邮件识别 skill 2026-04-26；

11、WL-0099 ：武平 openclaw 样品需求清单整理汇总 skill 2026-04-26；

12、WL-0085 ：U8（101）采购到货单20200724009（已关闭）影响LRP原因排查 2026-04-22；

13、WL-0083 ：网站搭建 2026-04-22； user: 现在开始做“企业知识库搭建（统一搜索入口，可以考虑每个来源都做索引）”这个任务，先帮我 一起规划 assistant: 可以，我们先把这件事规划对，别急着上工具。

我先给你一个判断： “统一搜索入口”是表象，真正难点是“来源异构 + 权限边界 + 索引更新 + 结果解释”。 如果这四件事不先定，后面很容易做成一个“能搜，但不好用”的系统。

另外我查了下之前的上下文，这个任务已经记成 WL-0129：企业知识库搭建（统一搜索入口，可以考虑每个来源都做索引）。Source: memory/2026-05-18-1456.md#L1-L39

我建议先把目标拆成 4 层

1）入口层：统一搜索入口

用户只管问：

• 某个制度在哪里
• 某个客户资料在哪
• 某个 U8 SQL 有没有现成
• 某个流程怎么走
• 某个文件服务器上的文档有没有
• 某个系统里的记录在哪

这层的核心不是“把所有东西塞一起”，而是：

• 一个输入框 / 一个聊天入口
• 支持关键词检索
• 支持自然语言提问
• 支持按来源过滤
• 支持返回“答案 + 来源链接 + 原文位置”

2）索引层：每个来源独立建索引

你之前说“可以考虑每个来源都做索引”，我认为这方向是对的。Source: memory/dreaming/light/2026-05-19.md#L1-L22

我建议不要一开始就做“全量混合一个大库”，而是做：

• 文件服务器索引
• U8 知识文档索引
• 内部系统页面/导出数据索引
• Wiki 索引
• 邮件/聊天沉淀资料索引（后面再说）
• 数据库元数据/业务口径索引

这样做有几个好处：

• 每个来源更新机制不同，便于单独维护
• 权限更容易控制
• 某个索引坏了不会拖垮全局
• 后面能做“联邦搜索 + 统一排序”

我的建议是：

架构上分源建索引，体验上统一搜索。

3）编排层：查询路由 + 结果融合

用户一句话进来后，系统要先判断：

• 这是找文件？
• 找制度？
• 找 SQL？
• 找业务解释？
• 找结构化数据？
• 还是找某个来源里的内容？

这一层要做两件事：

A. 查询路由

例如：

• “采购在途 SQL” → U8 SQL 知识索引
• “报销流程” → 制度/SOP/Wiki
• “某客户合同” → 文件服务器或合同库
• “这个字段什么意思” → 数据字典/知识库
• “SOxxxx 能不能交” → 这已经不是知识库，是业务助手

B. 结果融合

同一个问题，可能多个来源都有答案。 这时不要简单罗列 20 条结果，而要：

• 先给最可能答案
• 标注来源
• 给关联结果
• 给时间戳
• 给版本/状态

4）治理层：权限、质量、版本、更新

这层是最容易被忽略、但最决定能不能长期用的。

至少要先定：

• 谁能看什么
• 哪些来源是权威来源
• 文档过期怎么处理
• 重复内容怎么去重
• 更新频率怎么定
• 搜索不到时怎么兜底

我建议的第一阶段范围

别一口气做“全企业全系统”。

第一阶段目标

先做一个企业知识搜索 MVP，只覆盖 3 类最有价值来源：

来源 A：已有知识文档 / Wiki

比如：

• 你已经整理过的 wiki
• SOP
• 内部说明文档
• U8 学习资料沉淀

你之前已经把大量 /Users/mac/Desktop/吉信德知识库文件 按专题整理进 wiki，包含 openclaw、U8-ERP、孚盟crm 等内容，这部分很适合当第一批知识源。Source: /Users/mac/.openclaw/workspace/MEMORY.md

来源 B：文件服务器

比如：

• 群晖共享盘
• 部门共享目录
• 常用 Excel / Word / PDF / txt / md

来源 C：U8 相关结构化知识

不是直接查业务单据，而是先查这些：

• SQL 脚本
• 数据字典
• 业务口径说明
• 账套说明
• 表关系说明

你现在已经有不少 U8 相关 SQL/文档沉淀，这非常适合做一个专门索引源。Source: memory/u8-docs/_file_list.md#L93-L124

我建议的“来源分层”

为了后续不乱，我建议一开始就定义清楚：

一类：文档型来源

适合全文索引 + 向量索引

• md
• txt
• doc/docx
• pdf
• html
• wiki 页面

二类：表格型来源

适合结构化抽取 + 元数据索引

• xls/xlsx/csv

这里不能只做全文索引，因为表格更适合抽：

• 文件名
• sheet 名
• 列名
• 样例行
• 关键字段
• 更新时间

三类：系统型来源

适合 API/数据库/页面抓取后二次建索引

• U8
• CRM
• OA
• 标签系统
• 内部门户

四类：规则型来源

适合“权威知识库”

• 制度
• SOP
• 业务规则
• 口径说明
• FAQ

这类最好单独标记“权威等级”，搜索排序时优先。

一个很关键的设计：不要把“知识搜索”和“业务查询”混为一谈

这个坑很大。

知识搜索

回答的是：

• 有什么文档
• 某规则怎么写
• 某流程怎么做
• 某 SQL 在哪
• 某历史经验是什么

业务查询

回答的是：

• 这个订单现在什么状态
• 这个物料库存多少
• 这个采购单为什么没到
• 这个客户最近出货多少

前者靠知识库索引，后者靠系统接口 / SQL / 报表服务。

所以企业知识库第一阶段建议只聚焦：

让人“找得到、看得懂、能追溯来源”。

而不是立刻承担实时业务问答。

我建议的检索机制

统一入口背后，建议不是单一检索，而是混合检索：

1. 关键词检索

适合：

• 文件名
• 单号
• 料号
• 客户名
• 术语精确匹配

2. 语义检索

适合：

• “有没有讲采购在途的”
• “报销流程怎么弄”
• “这个问题以前有人总结过吗”

3. 元数据过滤

适合：

• 按来源
• 按部门
• 按时间
• 按文件类型
• 按系统
• 按权限级别

4. 重排序

最后再做排序：

• 权威来源优先
• 更新时间较新优先
• 精确命中优先
• 用户所在部门相关内容优先

结果页我建议长这样

别只给“10 条蓝色链接”。

应该返回：

顶部：AI 摘要

• 先用 3~6 句话总结最可能答案
• 标注“基于哪些来源”

中间：核心命中

每条包含：

• 标题
• 来源系统
• 文档路径
• 摘要片段
• 更新时间
• 权限标记
• 打开方式

底部：相关资料

• 同主题制度
• 相关 SQL
• 相似案例
• 关联目录

现在最需要先定的 8 个规划项

我建议我们一起先把这 8 个问题定下来：

1. 目标用户是谁

比如：

• 管理层
• 销售
• 采购
• PMC
• 财务
• IT/数据团队

不同用户决定了入口和权限策略。

2. 第一阶段纳入哪些来源

建议只选 3~5 个，别太多。

3. 每个来源的更新方式

• 定时全量
• 增量同步
• 手动触发
• 事件触发

4. 每个来源的权限边界

• 全员可见
• 部门可见
• 指定角色可见
• 敏感信息脱敏

5. 检索结果的权威排序规则

比如：

1. 制度/SOP
2. Wiki 归档知识
3. 业务沉淀文档
4. 文件服务器普通资料
5. 临时聊天记录

6. 是否需要版本与失效机制

同一份制度有多个版本怎么办，这是大坑。

7. 搜索不到时怎么处理

• 返回相似内容
• 建议去哪个系统找
• 提供“发起补充知识”入口

8. 第一阶段成功标准是什么

例如：

• 常见问题 70% 能搜到
• 搜索响应 < 5 秒
• 前 3 条结果命中率高
• 业务人员愿意持续使用

我给你的推荐方案

如果你想稳一点，我建议按下面这个路线：

Phase 1：知识入口 MVP

目标：

• 一个统一搜索入口
• 接 3 个来源
• 支持关键词 + 语义检索
• 返回来源和原文片段
• 先不做复杂权限联动，只做基础可见性控制

Phase 2：企业知识中台

目标：

• 来源扩展到文件服务器、Wiki、U8 知识、CRM 文档、制度库
• 加入更新任务、去重、版本管理
• 引入权限映射
• 加入管理后台

Phase 3：知识助手 + 业务助手联动

目标：

• 知识检索 + 实时业务查询结合
• 例如“这个订单交不了货”时，同时给出：
• 业务数据
• 历史规则
• 相关 SOP
• 处理建议

这时候就和你之前想做的 U8 AI 助手连起来了。

我对第一阶段的具体建议

如果今天就开始规划，我建议先锁定：

场景目标

“让员工能从一个入口找到企业内部知识和资料，不再到处翻群、翻共享盘、翻历史聊天。”

首批来源

1. Wiki / 已整理知识库
2. 文件服务器（先选 1~2 个关键目录）
3. U8 相关 SQL / 数据字典 / 业务规则文档

MVP 能力

• 全局搜索
• 来源筛选
• 关键词 + 语义混合检索
• 文档摘要
• 原文定位
• 相关推荐

暂不做

• 实时业务写操作
• 全企业权限打通
• 所有系统一次性接入
• 复杂审批流

我们接下来可以直接一起产出规划文档

如果你愿意，我下一条就可以直接帮你整理成一版：

方案 A：偏业务版

《企业知识库搭建规划（业务视角）》

• 建设目标
• 用户对象
• 场景清单
• 分阶段范围
• 成功标准

方案 B：偏技术版

《企业知识库统一搜索架构方案》

• 数据源分层
• 索引策略
• 检索架构
• 权限模型
• 更新机制
• 技术选型

方案 C：最实用版

《企业知识库 MVP 实施清单》

• 第一阶段范围
• 数据源清单
• 字段设计
• 索引任务
• 页面/交互
• 2~4 周实施路线

我建议我们直接走 方案 C + 方案 B，最容易落地。

如果你点头，我下一条就直接给你出： 《企业知识库 MVP 实施清单 v1》。 user: 给出U8根据采购发票的金额查询采购发票的sql语句 assistant: 可以，先给你一条常用版 SQL： 按 采购发票金额 查询采购发票记录。

SELECT
    a.ID,
    a.cPBVCode AS 发票号,
    a.dVouchDate AS 发票日期,
    a.cVenCode AS 供应商编码,
    v.cVenName AS 供应商名称,
    a.cDepCode AS 部门编码,
    a.cMaker AS 制单人,
    a.iTaxRate AS 税率,
    a.iSum AS 原币无税金额,
    a.iTax AS 原币税额,
    a.iMoney AS 原币价税合计,
    a.iNatSum AS 本币无税金额,
    a.iNatTax AS 本币税额,
    a.iNatMoney AS 本币价税合计
FROM PurBillVouch a
LEFT JOIN Vendor v ON a.cVenCode = v.cVenCode
WHERE 1 = 1
    -- 按本币价税合计金额查
    AND a.iNatMoney = 1000
ORDER BY a.dVouchDate DESC, a.cPBVCode DESC;

如果你想查“某个金额附近”的记录

因为金额有时会有小数，建议用区间：

SELECT
    a.cPBVCode AS 发票号,
    a.dVouchDate AS 发票日期,
    a.cVenCode AS 供应商编码,
    v.cVenName AS 供应商名称,
    a.iNatSum AS 本币无税金额,
    a.iNatTax AS 本币税额,
    a.iNatMoney AS 本币价税合计
FROM PurBillVouch a
LEFT JOIN Vendor v ON a.cVenCode = v.cVenCode
WHERE a.iNatMoney BETWEEN 999.99 AND 1000.01
ORDER BY a.dVouchDate DESC;

如果你要模糊按“含税金额 / 无税金额”分别查

1）按本币价税合计查

AND a.iNatMoney = 1000

2）按本币无税金额查

AND a.iNatSum = 1000

3）按本币税额查

AND a.iNatTax = 1000

4）按原币价税合计查

AND a.iMoney = 1000

我提醒你一个点

U8 里采购发票表常见是 `PurBillVouch`，但不同版本、环境字段可能略有差异。 如果你这边想要的是：

• 按明细行金额查
• 按发票总金额查
• 按供应商 + 金额查
• 按日期区间 + 金额查
• 查到后联查对应入库单/采购订单

我可以继续直接给你改成对应版本。

如果你要，我下一条可以直接给你这 3 个现成版本：

1. 按采购发票总金额查询
2. 按采购发票明细金额查询
3. 按金额反查对应采购订单/入库单