Enterprise AI Exchange

# 科大讯飞交流会
AI 议题讨论材料

围绕数字员工、企业 AI 平台、流程 Skills、应用资产治理、业务自建 AI 与低代码平台的系统化回答口径。

01 不是“多做几个 AI 应用”，而是建设可进入流程的组织能力。
02 底座可以外采，但控制面、流程资产和评测机制必须掌握在企业自己手里。
03 从局部提效走向全局价值，需要把流程、数据、权限、责任和运营闭环拉通。
Opening Position

## 建议先用一个判断定调：企业 AI 不是多买几个大模型，而是让 AI 回到流程里。

真正的变化不是把某个人换成模型，而是把流程里的判断、协同、执行、监控和知识沉淀重新组织成可控闭环。

### 不是工具堆叠

平台、数字员工、Skill、Agent、低代码，都应该服务流程闭环，而不是各自成为孤岛。

### 不是单点炫技

一个 AI 功能能跑起来，不代表它已经创造业务价值。要看是否改变端到端结果。

### 不是全靠厂商

模型和底座可以多厂商，但流程资产、控制面、权限审计和评价体系要企业自有。

Discussion Map

## 9 个问题可以归成三组：能力体系、平台治理、落地生态。

A

### 能力体系

数字员工、流程 Skills、AI 从局部提效走向全局提效。核心是把任务、判断和方法沉淀成可复用能力。

B

### 平台治理

企业 AI 平台、应用资产管理、业务自建 AI 纳管。核心是控制面、资产目录、权限和评测。

C

### 落地生态

老系统 CLI 化、外采系统嵌入、低代码平台演进。核心是让 AI 能进入既有系统和真实流程。

这不是 9 个孤立问题，而是企业 AI 操作系统的 9 个切面。
Issue 1 · Digital Employee

## 数字员工体系建设：不要从“给岗位配机器人”开始，而要从流程任务包开始。

### 核心回答

数字员工不是聊天机器人，更像一个被授权的流程执行单元。它必须绑定具体任务、工具、权限、评测标准和责任人。

角色定位 + Skill 能力 + 工具接口 + 权限边界 + 评测标准 + 责任人

### 展开逻辑

- 如果从岗位开始，很容易做成“每个部门一个 AI 助手”，结果还是散点应用。
- 如果从流程任务包开始，可以明确它服务哪个流程节点、替谁减少什么动作、出错后谁接管。
- 数字员工的边界要提前设计：哪些动作可以自动做，哪些动作只给建议，哪些动作必须人工确认。
- 它的价值不只是“少一个人干活”，而是让流程里的信息整理、风险识别、状态推动和知识沉淀自动发生。

Issue 1 · Build Path

## 数字员工可以分三层推进：先助手，再流程员工，最后半自治。

1

### 岗位助手

帮助个人做摘要、检索、起草、分析。价值主要是个人效率提升，适合作为普及入口。

2

### 流程员工

进入合同、采购、审批、客服、项目管理等节点，读取材料、判断风险、生成建议、推动下一步。

3

### 半自治员工

监听任务、调用工具、回写系统、异常升级。关键动作仍保留人工确认，确保责任边界清楚。

### 建议起步场景

合同初审、采购需求补全、审批预审、客服工单总结、项目周报。共同特征是高频、规则相对清楚、价值容易衡量。

Issue 2 · Enterprise AI Platform

## 企业 AI 平台不要做成“大而全工程”，先拆成四层能力。

层级
建设重点
说明
开发层
Agent、Workflow、Prompt、知识库
让业务和技术团队能把 AI 能力做出来，支持低代码和高代码并存。
运行层
模型调用、工具调用、沙箱、弹性、稳定性、观测
这层重、慢、贵，成熟底座可优先外采或复用。
治理层
资产目录、权限、日志、成本、发布审批、责任追溯
这是企业必须掌握的控制面，不能只依赖厂商后台。
流程层
合同、采购、报销、客服、交付等业务流程
AI 只有进入流程节点，才会从工具变成组织能力。
一句话：底座可以外采，控制面必须自有。
Issue 2 · Control Plane

## 企业自己的控制面，必须回答一组管理问题。

企业有哪些 Agent？来自哪里？处于什么版本和状态？
每个 Agent 归谁负责？服务哪段流程？影响哪个业务结果？
它能访问什么数据？能调用什么工具？是否涉及高风险动作？
谁能创建、发布、调用、审批？是否需要人工复核？
调用记录、成本、失败、人工接管和用户反馈在哪里看？
什么时候灰度、升级、暂停、下线？失败后谁接管？

### 可以这样对外表达

我们不一定要重造模型网关和运行底座，但必须建设企业 AI 的管理面，让 AI 应用从“能跑”走向“可管、可审、可复用”。

Issue 3 · From Local Efficiency to Global Value

## AI 提效要从“个人少花时间”，升级为“端到端业务结果改善”。

### 核心回答

局部提效是某个人少花几分钟；全局提效是端到端周期、质量、风险、返工和客户体验发生变化。

不要只问“这个动作能不能交给 AI”，要问“这条流程的业务结果能不能被 AI 重构”。

### 展开逻辑

- 先看流程里的真实流动对象：信息、责任、风险、单据、状态或实物。
- 再拆具体动作：谁输入、谁判断、谁确认、谁处理异常、谁承担责任。
- AI 不应只是自动化旧流程，而要重排判断、协同、执行和复盘方式。
- 价值评估要从单点效率，扩展到流程周期、一次通过率、返工率和异常处理时间。

Issue 3 · Method

## 可以用“点、线、面、体”把局部提效转成全局价值。

点看具体痛点：谁在什么节点做什么动作，为什么慢、错、返工。
线回到端到端流程：触发、判断、协同、执行、验证、复盘是否连起来。
面拉通组织、角色、系统、数据、供应商、客户等横向要素。
体形成规则、权限、日志、指标、知识库、评测和持续迭代机制。

### 节点账

减少多少重复动作、重复录入、人工整理。

### 工时账

不同角色节省多少分钟，等待减少多少。

### 交期账

端到端周期能否从 50 天变 30 天。

### 质量账

一次通过率、返工率、异常处理时间是否改善。

Issue 4 · Legacy IT & CLI

## 信息化陈旧时，不要等接口全部统一后再做 AI，先把高频动作工具化。

### 核心回答

CLI 化不是把所有老系统强行改成命令行，而是围绕流程动作封装一层“可调用工具”，让 Agent 能在授权范围内读、查、写、触发。

能用接口用接口；不能用接口，先用插件、RPA、桌面智能体或 CLI 把流程跑起来。

### 三条接入路径

- 有 API 的系统，优先走正式 API，并接入统一身份、权限和日志。
- 没有 API 但有 Web 页面，先用浏览器插件、页面读取、RPA 或桌面智能体旁路接入。
- 高频稳定动作，再沉淀为 CLI、MCP 或工具层，供 Agent 在流程中调用。
- 早期尽量先做只读和建议，等准确率、权限、审计稳定后，再逐步开放回写。

Issue 4 · Tool Examples

## 围绕流程动作封装工具，而不是围绕系统菜单封装工具。

查询待办查询某人的待审批列表、待处理工单或待确认任务。
读取详情读取采购单、合同、报销单、供应商档案等关键对象。
补齐上下文获取预算余额、历史订单、供应商资质、过往风险记录。
创建动作创建工单、生成预收货单、发起补资料任务。
更新结果更新审批意见、状态、标签、风险等级和处理结论。
生成归档生成项目周报、复盘摘要、审计记录和知识库条目。
三条底线：用户授权、最小权限、全链路日志。
Issue 5 · Process Skills

## 流程 Skills 化不是把豆包、DeepSeek 里的零散场景拼起来。

### 核心回答

从高频 AI 使用场景切入是对的，但要回到流程节点，经过方法论清洗后，再沉淀成可复用、可审计、可评测的 Skill。

一个合格 Skill 不只是提示词，而是一段可复用的专业方法。

### 为什么不能直接拼 Prompt

- 零散 Prompt 解决的是单次输出，不解决流程上下游衔接。
- 没有输入边界，AI 不知道什么时候该追问、什么时候该拒绝、什么时候能下判断。
- 没有评测标准，输出看起来像答案，但不能稳定交付。
- 没有责任和失败处理，进入真实业务后很难审计和复盘。

Issue 5 · Best Practice

## 建议用四步把流程节点沉淀成 Skill。

As-Is 先还原现状：这条流程现在到底怎么跑，输入、输出、角色、系统、异常是什么。
ECRS 先消除、合并、重排、简化。不要给本来不该存在的节点套 AI。
AI To-Be 设计 AI 先干、人确认、异常升级、证据留存和责任兜底。
Skill 把稳定、重复、规则明确、有交付标准的节点沉淀成 Skill。
输入边界：需要什么材料，缺什么必须追问。
处理步骤：按什么顺序分析，先判断什么再输出什么。
工具调用：什么时候查数据、读附件、访问系统。
判断规则：哪些规则确定，哪些需要模型推理。
输出格式：报告、表格、意见、任务、回写字段。
失败处理和评测标准：错了怎么退回，怎么持续打磨。
Issue 6 · AI Application Asset Management

## AI 应用资产管理建议分成 Agent Asset 和 Agent SKU 两层。

对象
面向谁
回答什么问题
Agent Asset
技术和平台团队
这个 Agent 在哪里构建、在哪里运行、由谁维护、通过什么入口调用、当前版本和状态是什么。
Agent SKU
业务和管理团队
业务看到和申请的是哪个能力、适用于哪个流程、谁能用、风险等级是什么、效果如何评价。
流程归属
流程架构负责人和业务负责人
这个 Agent 到底服务哪段流程，替谁减少动作，出了问题影响哪个业务结果。
Issue 6 · Governance Mechanism

## 管理机制至少覆盖八件事，避免 AI 应用越建越多以后变成黑盒。

资产登记：名称、来源、版本、负责人、状态、退役规则。
流程归属：绑定到端到端流程、流程域、具体节点。
权限策略：谁能创建、发布、调用、审批。
数据域和风险等级：是否涉及敏感数据、高风险动作、外部工具。
发布审批：Draft、Review、Published、Deprecated。
调用网关：所有生产调用经过统一入口。
日志审计：调用人、调用内容、工具、结果、耗时、成本。
运营评测：调用量、失败率、人工接管率、用户反馈、业务效果。
管理不是为了“管住大家”，而是让 AI 应用可复用、可追责、可持续运营。
Issue 7 · Business Self-Built AI

## 业务方纷纷自建 AI 应用，不应该简单禁止，而要从无序自建变成联邦创新。

### 核心回答

AI 时代业务方具备构建能力是好事。问题不在“业务能不能自建”，而在“生产级应用是否被纳入企业治理”。

业务可以分散创新，生产必须统一纳管。

### 三条规则

- 创新可以分散：业务方可以用低代码、Agent 平台、AI Coding 快速做原型。
- 生产必须纳管：进入真实业务、真实客户、真实数据，就必须注册资产、接身份、走权限、留日志、做评测。
- 能力必须复用：平台提供模型网关、知识库、工具目录、Skill 模板和流程组件，减少重复建设。
- 平台方不是把业务创新收走，而是把可用场景变成组织资产。

Issue 8 · AI Embedded in Vendor Systems

## 外采系统很多时，不要陷入“每个系统都用各自厂商 AI”的局面。

1

### 轻嵌入

浏览器插件、侧边栏、页面读取，不改原系统，先让 AI 出现在业务页面旁边。

2

### 中嵌入

通过 API、Webhook、MCP、CLI、RPA，把外采系统动作封装成企业 Agent 可调用工具。

3

### 深嵌入

对核心流程节点做正式系统集成、事件监听、状态回写和权限联动。

### 表达重点

厂商 AI 可以用，但不要让厂商 AI 成为企业 AI 架构的唯一入口。企业应保留自己的控制面、Skill 目录、Agent 资产目录和评价体系。

Issue 8 · Vendor Requirements

## 对外采系统，企业要向厂商要“开放能力”，而不只是问有没有 AI 助手。

能不能开放稳定 API 或事件，让企业 Agent 能读到流程对象和状态变化。
能不能接企业统一身份和权限，避免形成另一套账号和授权体系。
能不能输出日志和审计，支持企业自己的调用追踪和责任追溯。
能不能以工具方式被企业 Agent 调用，而不是只能在厂商页面里使用。
能不能允许企业自有 Agent 进入页面或流程节点，形成一致的用户体验。
能不能支持灰度、回滚、人工确认和高风险动作拦截。
厂商负责提供系统能力，企业负责统一治理和流程编排。
Issue 9 · Low-Code in AI Era

## 低代码不会消失，但它必须从“搭页面”升级为“搭 AI 流程能力”。

### 核心判断

传统低代码如果只是拖表单、画流程、做简单 CRUD，会被 AI Coding 和 Agent 平台挤压。但如果升级为业务建模、流程编排、权限治理、人机协同和评测运营，仍然很有价值。

低代码的未来不是拖页面，而是支撑业务在治理框架内搭 AI 流程能力。

### 平台部门的角色变化

- 从“帮业务做应用”变成“提供可复用能力和治理框架”。
- 从“页面配置平台”变成“流程建模、工具编排和人机协同平台”。
- 从“一次性交付系统”变成“持续运营 AI 能力资产”。
- 从“审批需求排期”变成“让业务安全地快速试错”。

Issue 9 · New Middle Platform Capabilities

## AI 时代的平台部门，应建设一组新的中后台能力。

流程架构和流程资产管理：知道企业哪些流程最值得 AI 化。
Skill 平台：让经验、规则、模板、评测集可复用。
Agent 控制面：统一管理 Agent 资产、SKU、权限、发布、审计。
工具和接口网关：把老系统、新系统、外采系统封装成 Agent 可调用工具。
数据和知识资产目录：管理知识库、数据域、质量、权限和使用记录。
评测与观测平台：看准确率、失败率、人工接管、成本和业务价值。
人机协同机制：定义哪些动作 AI 能做，哪些动作必须人确认，哪些动作要升级。
复用运营机制：把试点中跑通的能力沉淀成下一条流程可复用的资产。
90-Day Pilot

## 如果对方追问“怎么启动”，建议给一个 90 天试点路径。

1

### 0-30 天：选流程，拆 As-Is

选一条高频、规则相对清楚、价值能衡量的流程，拆输入、输出、角色、系统、耗时和异常处理。

2

### 31-60 天：做 Skill 和工具

完成 ECRS 清洗，设计 AI To-Be，把节点拆成 Skill、Agent、工具接口和人工确认点。

3

### 61-90 天：试运行和评测

通过控制面纳管资产，跑真实 case，观察准确率、人工接管率、周期、质量和业务反馈。

关键不是证明“AI 很强”，而是证明“这套流程能力可以复制到下一条流程”。
Reusable Lines

## 现场可以反复使用的几句收束话。

### AI 流程再造不是把旧流程接上大模型。

而是重新组织判断、协同、执行、监控和知识沉淀。

### 底座可以外采，控制面必须自有。

适合回答平台建设、自研外采、厂商 AI 和资产治理问题。

### 企业长期积累的不是平台页面。

而是流程 Skill 目录、Agent 资产、评测集和运营数据。

### 业务可以分散创新，生产必须统一纳管。

适合回答业务方自建 AI 和新竖井问题。

Closing

## 最后可以收束到一个判断。

未来企业拼的不是谁做了更多 AI 应用，而是谁更早把 Agent 变成可治理、可复用、可进入流程的组织能力。

### 下一步一

共同选一条高频流程，明确流程目标、角色、系统和数据边界。

### 下一步二

把流程节点拆成 Skill、Agent、工具和人工确认点。

### 下一步三

用 90 天试点验证业务价值、治理机制和复用路径。