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 天试点验证业务价值、治理机制和复用路径。