# 用友U8数据接入AI：怎样做到只读、可核对、不乱答

> Source: https://netray.co/zh/yonyou-u8-ai-data-query
> Language: zh
> Publisher: Netray (netray.co)

U8 的业务数据存放在 SQL Server 中，AI 问数的可行做法是：用只读账号连接，把库存、采购、销售、生产订单等口径先固化成受控的查询模板，再由本地部署的大模型把自然语言翻译成这些查询，并展示 SQL 供核对。写回 U8 必须经过人工确认。

很多使用 U8 的制造和贸易企业都有同样的困扰：库存、采购到货、销售发货、生产订单的数据都在系统里，但每次想看一个交叉的问题，比如「哪些在途采购会影响下周三张生产订单」，都要找信息部写 SQL 或者导出多张报表在 Excel 里拼。报表做出来时，问题往往已经变了。

把大模型直接接到 U8 数据库上并不等于问数就能用。U8 的表很多，同一个业务量有多个口径，比如现存量、可用量、预计入库量，随意让模型猜表名，答案看起来很流畅却可能是错的。本文从一线实施的角度，讲清楚在 U8 上做 AI 问数应该怎样搭，哪些场景值得做，哪些场景用 U8 自带报表和用友自己的能力就够了。

## U8 数据的特点：能查到，不代表能直接问

U8 通常部署在企业自己的 SQL Server 上，账套按年度和账套号分库，业务数据分散在库存、采购、销售、生产订单、总账等模块的表里。例如现存量常见于 CurrentStock，采购入库单和销售出库单分别落在 rdrecord01、rdrecord32 这类出入库主表和对应的 rdrecords 明细表中，存货档案、客户、供应商各有自己的档案表。具体表名和字段会随版本和是否做过二次开发而不同，必须在客户现场的库里逐一核实，不能照搬。

难点不在于连不上，而在于口径。同样问「库存还有多少」，是账面现存量，还是扣除已分配、已锁定后的可用量，是否包含在检、不合格仓、委外仓，不同企业的定义不一样。AI 如果不知道企业自己的口径，就只能猜，因此第一步是把口径写下来，而不是先接模型。

- 按账套和会计年度确认要查询的库，避免跨年度数据混在一起
- 为每个常用业务量写明口径：现存量、可用量、在途量、已发货未开票
- 标出做过二次开发的自定义字段和自定义表，单独说明含义
- 确认仓库属性，例如是否计入可用量、是否为委外或不良品仓

## 架构：只读连接、受控查询、SQL 可见

推荐的结构是在内网为 AI 建一个专用的只读数据库账号，只授予需要的视图或表的查询权限，不授予写权限，也不使用 U8 管理员账号。更稳妥的做法是在 SQL Server 上建一层只读视图，把口径固化进视图里，模型面对的是名字清楚、含义明确的视图，而不是几百张原始表。

模型把自然语言问题翻译成针对这些视图的查询，系统在执行前后都向用户展示实际执行的 SQL 和结果行数，业务人员或信息部可以核对。不确定时，系统应该反问，比如「您问的库存是现存量还是可用量」，而不是给出一个看似确定的数字。这与 Netray 的 ERPray 思路一致：只读为默认，展示查询，尊重 ERP 中的角色。

- 专用只读账号，限制到视图级别，限制并发和单次返回行数
- 查询超时和只在业务低峰执行大查询，避免拖慢正在录单的 U8
- 保留问题、SQL、结果和操作人的日志，便于追溯
- 模型与向量检索都部署在内网，U8 数据不出企业网络

## 值得先做的几个场景

第一类是跨模块的问数。比如「某物料当前现存、已分配、在途采购和未来两周的生产订单需求分别是多少」，这个问题需要同时看库存、采购订单和生产订单，传统做法要导出多张表。第二类是例外清单：超期未到货的采购订单、超过一定天数未开票的发货单、长期呆滞的库存。这类问题规则清楚，适合固化成模板，让模型负责理解问法和选择模板。

第三类是对账辅助，比如库存账与总账存货科目差异的初步定位。这类场景只做定位和解释，不自动调整分录。财务数据的修改应该始终回到 U8 中，由有权限的人员操作。

## 权限、合规与数据留在哪里

U8 里有按操作员、按仓库、按部门的数据权限。AI 查询层需要尊重这些限制，常见做法是由使用者登录后映射到对应的数据范围，在视图或查询模板里加上过滤条件，而不是让所有人共享一个看得见全部数据的账号。采购价格、成本、薪资相关数据要单独评估是否开放给 AI 问数。

数据方面，企业数据涉及商业秘密，部分还含有个人信息，按《数据安全法》和《个人信息保护法》的要求做好分类分级。把模型部署在企业自己的服务器或私有云里，数据不经过公网上的第三方模型接口，是满足这些要求最直接的方式。是否需要等保测评由企业所在行业和系统定级决定，Netray 不代替企业做合规结论，只提供能让企业自行满足要求的架构。

## 怎样开始，以及什么时候不必做

建议从一个两到四周的评估开始：选三十个业务人员真实会问的问题，逐个写出正确口径和标准答案，在只读视图上验证模型能否稳定答对，再决定是否扩大。这样可以在投入大量成本前，就知道准确率和边界。

也要说实话：如果企业的需求只是固定的几张报表，用 U8 自带的报表工具或用友的分析产品就足够，不需要大模型。AI 问数的价值在于问法多变、需要跨模块组合的临时问题。如果数据本身录入不规范，比如存货编码重复、仓库混用，应先治理数据，否则 AI 只会更快地给出错误答案。

## FAQ

### AI 会不会修改 U8 里的数据？

默认不会。问数使用只读账号，只能查询。如果以后要做写回，比如自动生成请购单草稿，应经人工确认后再通过 U8 的正规接口提交，而不是直接写数据库。

### U8 的数据库可以直接给大模型读吗？

不建议直接开放原始库。应当用只读账号加上口径明确的视图，限制行数和并发，这样答案更准确，也不会影响正在使用的 U8。

### 数据会传到国外或第三方云吗？

按私有化方案部署时不会。模型运行在企业自己的 GPU 服务器或私有云上，可以采用 Qwen、DeepSeek 等开源权重模型，问答过程不调用公网模型接口。

### 为什么 AI 给的库存数字和 U8 报表不一样？

多半是口径不同，比如现存量与可用量、是否含在检仓。所以我们会先把企业的口径固化到视图里，并在结果里显示用的哪个口径和对应的 SQL。

### 需要多大的服务器？

取决于使用人数和模型大小。问数类场景用中等规模的开源模型加量化通常就够，具体要在评估阶段按并发和响应时间要求测算，不能凭空给固定数字。