# 科大讯飞交流会 AI 议题回答口径

## 一、建议先用这段开场定调

我最近对企业 AI 落地有一个比较稳定的判断：企业 AI 不是“多买几个大模型、多做几个智能体”，而是要让 AI 回到流程里。

真正的变化不是把某个人换成模型，而是把流程里的判断、协同、执行、监控和知识沉淀重新组织成一个可控闭环。平台、数字员工、Skill、Agent、低代码，本质都应该服务这件事：让企业把零散 AI 使用，变成可治理、可复用、可评测、可进入业务流程的组织能力。

这也是我不太主张一上来讨论“自研还是外采”的原因。底座可以外采，模型可以多厂商，但流程资产、Skill 目录、Agent 控制面、权限审计和业务评价体系，最好长在企业自己手里。

## 二、9 个问题逐题回答口径

### 1. 数字员工体系建设思路

我不建议先从“给每个岗位配一个数字员工”开始，而是先从流程和任务包开始。

数字员工不是一个聊天机器人，更像是一个被授权的流程执行单元。它至少由六件东西构成：角色定位、Skill 能力、工具或接口、权限边界、评测标准、责任人。

可以分三层建设：

1. 岗位助手：帮助个人做摘要、检索、起草、分析，价值是个人提效。
2. 流程员工：进入合同、采购、审批、客服、项目管理等流程节点，能读取材料、判断风险、生成建议、发起下一步。
3. 半自治员工：能监听任务、调用工具、回写系统、异常升级，但关键动作仍保留人工确认。

我会建议从高频、规则相对清楚、价值能衡量的流程开始，而不是从组织架构图开始。比如合同初审、采购需求补全、审批预审、客服工单总结、项目周报，这些都适合先做。

### 2. 企业 AI 平台建设思路

企业 AI 平台不要混成一个“大而全平台”。我更倾向于拆四层来看：

1. 开发层：让业务或技术团队能做 Agent、Workflow、Prompt、知识库。
2. 运行层：负责模型调用、工具调用、沙箱、弹性、稳定性和观测。
3. 治理层：负责资产目录、权限、日志、成本、发布审批、责任追溯。
4. 流程层：把 Agent 和 Skill 放进合同、采购、报销、客服、交付这些业务流程。

大多数企业不一定要从零自建运行底座。成熟厂商能提供模型网关、沙箱、工具、可观测和弹性运行，就可以优先利用。

但企业必须建设自己的控制面。这个控制面要回答：企业有哪些 Agent？归谁负责？服务哪段流程？能访问什么数据？能调用什么工具？谁能用？失败谁接管？成本算到哪里？什么时候下线？

一句话讲：底座可以外采，控制面必须自有。

### 3. AI 提效如何从局部提效转变为面向业务价值的全局提效

局部提效看的是“某个人少花了几分钟”。全局提效看的是“端到端业务结果有没有变好”。

我会用“点、线、面、体”来推进：

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

指标也要从个人效率升级为四类账：

1. 节点账：减少多少重复动作、重复录入。
2. 工时账：不同角色节省多少时间。
3. 交期账：端到端周期缩短多少。
4. 质量账：一次通过率、返工率、异常处理时间是否改善。

所以我会强调，AI 项目不能只问“这个动作能不能交给 AI”，而要问“这条流程的业务结果能不能被 AI 重构”。

### 4. 企业信息化陈旧、没有统一接口和权限管理，如何 CLI 化

这个问题很现实。我的观点是，不要等所有老系统都完成 API 化、权限统一、数据治理以后再做 AI，那样项目会被拖死。

可以分三条路径：

1. 有 API 的系统，优先走正式 API。
2. 没有 API 但有 Web 页面的系统，先用浏览器插件、页面读取、RPA 或桌面智能体做旁路接入。
3. 高频稳定动作，再沉淀成 CLI 或工具层，供 Agent 调用。

所谓 CLI 化，不是把所有系统强行改造成命令行，而是围绕流程动作封装一层“可调用工具”。例如：

1. 查询某人的待审批列表。
2. 读取某张采购单详情。
3. 获取供应商历史记录。
4. 创建工单。
5. 更新审批意见。
6. 生成并回写项目周报。

这层工具必须有三个底线：用户授权、最小权限、全链路日志。早期可以先做只读和建议，不急着直接写回；等准确率、权限、审计稳定后，再逐步开放回写动作。

AI + 审批的演化不是越来越“AI”，而是越来越看不见。能用接口就用接口，不能用接口就先用插件、桌面智能体、CLI 把流程跑起来。

### 5. 流程 Skills 化最佳实践

从已经高频使用 AI 的场景出发是对的，但不能停在“把零碎 Prompt 拼起来”。

我会建议按这个顺序做：

1. 先还原 As-Is：这条流程现在到底怎么跑。
2. 再过 ECRS：哪些动作该消除、合并、重排、简化。
3. 再设计 AI To-Be：哪些节点 AI 先干，哪些节点人确认，哪些情况必须升级。
4. 再挖 Skill：把稳定、重复、规则明确、有交付标准的节点沉淀成 Skill。

一个合格的 Skill 不只是提示词。它应该包含输入边界、处理步骤、工具调用、判断规则、输出格式、失败处理和评测标准。

所以，最佳实践不是“豆包、DeepSeek 用得多的场景直接打包”，而是从高频场景切入，回到流程节点，经过方法论清洗以后，再资产化为 Skill。

### 6. 企业 AI 应用资产管理机制的建设思路

我建议把 AI 应用资产分成两类：Agent Asset 和 Agent SKU。

Agent Asset 面向技术和平台团队，关注它在哪里构建、在哪里运行、由谁维护、通过什么入口调用。

Agent SKU 面向业务和管理团队，关注它叫什么、适用于哪个流程、谁能用、风险等级是什么、是否需要审批、效果如何评价。

管理机制至少包括八项：

1. 资产登记：名称、来源、版本、负责人、状态、退役规则。
2. 流程归属：绑定到端到端流程、流程域、具体节点。
3. 权限策略：谁能创建、发布、调用、审批。
4. 数据域和风险等级：是否涉及敏感数据、高风险动作、外部工具。
5. 发布审批：Draft、Review、Published、Deprecated。
6. 调用网关：所有生产调用经过统一入口。
7. 日志审计：调用人、调用内容、工具、结果、耗时、成本。
8. 运营评测：调用量、失败率、人工接管率、用户反馈、业务效果。

这个机制的核心不是“管住大家”，而是避免 AI 应用越建越多以后变成新的黑盒。

### 7. 业务方纷纷自建 AI 应用，带来新的系统和数据竖井，如何解决

我不建议简单禁止业务方自建。AI 时代业务方具备构建能力是好事，关键是要从“无序自建”变成“联邦创新 + 中央治理”。

可以定三条规则：

1. 创新可以分散：业务方可以用低代码、Agent 平台、AI Coding 快速做原型。
2. 生产必须纳管：只要进入真实业务、真实客户、真实数据，就必须注册资产、接统一身份、走权限、留日志、做评测。
3. 能力必须复用：平台提供通用模型网关、知识库、工具目录、Skill 模板、流程组件，减少重复造轮子。

这样既不压制业务创新，也不让企业重新长出一堆 AI 孤岛。

可以用一句话讲：业务方负责发现场景和快速验证，平台方负责把可用场景变成可治理、可复用、可审计的组织资产。

### 8. AI 需要嵌入业务系统，但大量业务系统外采，厂商希望推广自己的 AI 能力，嵌入成本高，如何解决

这个问题要避免陷入“每个系统都用各自厂商 AI”的局面。那样短期看方便，长期会形成新的锁定和割裂。

我会建议采用三层嵌入方式：

1. 轻嵌入：浏览器插件、侧边栏、页面读取，不改原系统，先让 AI 出现在业务页面旁边。
2. 中嵌入：通过 API、Webhook、MCP、CLI、RPA 等方式，把系统动作封装成工具。
3. 深嵌入：对核心流程节点做正式系统集成、事件监听、状态回写和权限联动。

对外采系统，企业要向厂商要的不是“你有没有自己的 AI 助手”，而是几个基础开放能力：

1. 能不能开放稳定 API 或事件。
2. 能不能接企业统一身份和权限。
3. 能不能输出日志和审计。
4. 能不能以工具方式被企业 Agent 调用。
5. 能不能让企业自有 Agent 进入页面或流程节点。

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

### 9. AI 时代低代码平台是否还有前景，平台部门该怎么做

低代码不会消失，但它的角色会变化。

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

AI 时代的平台部门不应该只是跟风帮业务做几个 AI 应用，而是要建设新的中后台能力：

1. 流程架构和流程资产管理：知道企业哪些流程最值得 AI 化。
2. Skill 平台：让经验、规则、模板、评测集可复用。
3. Agent 控制面：统一管理 Agent 资产、SKU、权限、发布、审计。
4. 工具和接口网关：把老系统、新系统、外采系统封装成 Agent 可调用工具。
5. 数据和知识资产目录：管理知识库、数据域、质量、权限和使用记录。
6. 评测与观测平台：看准确率、失败率、人工接管、成本和业务价值。
7. 人机协同机制：哪些动作 AI 能做，哪些动作必须人确认，哪些动作要升级。

所以低代码平台还有前景，但要从“让业务自己搭页面”，升级为“让业务在治理框架内搭 AI 流程能力”。

## 三、可以反复使用的几个金句

1. AI 流程再造不是把旧流程接上大模型，而是重新组织判断、协同、执行、监控和知识沉淀。
2. 底座可以外采，控制面必须自有。
3. 企业真正长期积累的，不是平台页面，而是流程 Skill 目录。
4. 数字员工不是聊天机器人，而是被授权、可审计、可评测的流程执行单元。
5. 局部提效看个人少花几分钟，全局提效看端到端业务结果有没有变好。
6. 不要等老系统全部 API 化再做 AI，先用插件、CLI、RPA、MCP 把高频动作工具化。
7. 业务方可以分散创新，但生产级 AI 应用必须统一纳管。
8. 厂商 AI 可以用，但企业不能把流程资产和治理权交给厂商。
9. 低代码的未来不是拖页面，而是承载 AI 时代的业务建模、流程编排和治理能力。
