AI 落地实录：我们如何重构业务流程与组织协作

作者 | AICon 全球人工智能开发与应用大会

策划 | 罗燕珊

编辑 | 宇琪

随着生成式 AI 的迅猛发展，企业正面临着前所未有的数字化转型机遇与挑战。越来越多的组织希望 AI 成为重塑业务价值和提升组织效能的关键驱动力。但怎么打通企业内部数据？如何和业务流程集合？又如何和已有的工具集成？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了 网易游戏 AI 产品策划专家蓝师师、腾讯文档后台技术专家张瀚元、国际头部 ERP 企业专家吴云，在AICon全球人工智能开发与应用大会2025 深圳站即将召开之际，共同探讨 AI 如何重塑业务价值和提升效能。

部分精彩观点如下：

• AI 不仅重塑了业务流程，也重构了整个组织的协作模式。

• 真正优秀的 AI 产品，并不应该让用户清晰地察觉到“这是一个 AI 功能”。用户并不关心某个功能是不是由 AI 驱动的，他们关心的是问题是否被解决。

• 可以从“+ AI”或“AI +”两个角度去思考产品路径，但不必强求一定要做到“AI 加”才有价值。很多使用频率高、解决痛点深的小功能，依然能显著提升日常工作效率。

• 真正有价值的，是将大模型能力与企业现有 IT 系统深度集成，包括企业内部的文档与数据系统，从而开发出新产品、新服务，提升整体服务能力。

查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2025/shenzhen/schedule

以下内容基于直播速记整理，经 InfoQ 删减。

完整直播回放可查看：https://www.infoq.cn/video/3NYwz6oFiY1JBMfsjcCN

AI 提效进行时

蓝师师：我们都听说了不少“AI 提效”，但在不同领域，这个“效”可能差别很大。今天想先请大家从自己的视角出发，分享下大家各自在行业里 / 工作中，最近最成功或最典型的一次“AI 提效实践”是什么？

吴云：在我的工作中，最典型的 AI 提效实践体现在代码辅助方面。我们在为客户提供解决方案时，常常需要根据客户需求开发 Demo 程序用于展示。起初我们使用的是 AI 编程插件，后来转向使用 Cursor，从完整代码生成到代码补全，再到编程过程中出现问题时用 Cursor 来定位和修复 bug，这一整套流程显著提升了我们的开发效率。以前我们经常需要咨询技术专家，现在在售前团队中，大多数成员都能依靠 AI 编程助手独立完成 Demo 开发。

此外，在我们行业中，也有一些企业的代码结构较为特殊，通用模型支持有限。例如我了解的一家通信公司，他们所有的代码都是用 C 语言编写，而通用大模型对这种代码语言的支持度不高，也不了解他们的编码规范和常用模式。因此，他们在“千问”代码模型的基础上，训练了自己的内部模型，从而显著提升了代码开发效率。

张瀚元：我所在的是互联网行业，这一行业整体受到 AI 的冲击和影响相对更大，特别是在业务提效、编码习惯以及日常工作节奏方面。腾讯文档在文档编辑领域深耕多年，而这个领域本身已有四十年左右的发展历史，长时间的发展让行业逐渐形成了一套相对固化、传统的模式。

在推动 AI 提效方面，以往用户整理文件通常依赖文件夹，无论是在线还是本地，大家普遍采用多层级的文件夹结构来管理知识。从知识的流转生命周期看，可以分为四个阶段：第一是知识的获取与收集，第二是知识的沉淀，第三是知识的管理，第四是知识的消费与再流转。我们在 AI 的推动下，率先从知识流转的视角进行思考和优化。

今年，我们围绕“文档空间”这一概念进行灰度测试，重点聚焦在第三阶段——知识管理上，尝试打破以往基于层级文件夹的传统组织方式。我们推出了“文档空间”这一新体系，通过 AI 的能力，辅助用户提升文件搜索、整理以及跨维度知识规整的效率。

蓝师师：请问你所说的 AI 整理，是不是指通过 AI 对文件进行自动分类、打标签，然后形成某种“虚拟文件夹”来重新组织这些文件？

张瀚元：是的，我们对传统文件夹进行了功能升级。例如，我们会根据文档内容自动生成标签，并将文件夹概念扩展为“空间”这一新形态。在这个空间中，用户可以插入多种文件形式，比如在线文档、本地文件、云文件，甚至是视频、图片、文件夹等，实现多模态内容的统一管理。通过 AI 的打标和组织能力，我们可以对文档内容进行摘要和分类。比如一个关于 AI 的空间，可以通过预设问题引导用户搜索和定位相关知识，从而更高效地“消费”知识。

蓝师师：游戏行业有很大不同。我们会定期对内部开发者进行调研，结果显示，不同开发者面临的技术痛点也不一样：61% 的开发者认为代码理解困难，55% 认为调试困难，54% 觉得代码编写本身也很难。

在代码理解方面，游戏开发者面临的挑战可能超出大家的认知。首先，游戏项目的研发周期通常长达两到三年，期间涉及大量引擎资源，代码仓库的体积以 GB 计，而非一般行业常见的 MB 级别。新加入的开发者要熟悉如此庞大的代码体系，确实非常困难。

其次，游戏研发的技术栈本身就非常复杂。我们会使用多个不同的引擎，内部组件依赖也远比一般业务多样。同时，游戏行业使用的语言和技术也可能与主流互联网行业不同，例如我们会使用很多较小众的语言和框架，如内部的 LPC、LUA 语言等。整体来看，开发者需要掌握的知识体系更庞杂。再加上人员流动频繁、隐性知识难以沉淀，这就使得新人理解、上手项目代码的难度进一步加大。

为了解决这一问题，我们首先借助 AI 将隐性知识显性化。例如，在代码库层面，我们会对其进行解析，提取调用链、生成图谱，并通过 DeepWiki 的方式转化为可阅读的内容。同时，我们对开发过程中的文档、策划资料、设计资源等进行集中管理，借助 Embedding 和向量检索技术统一存储。

此外，还有一类重要但常被忽视的隐性知识——日常聊天记录。这些记录中往往包含对业务基本概念的理解，以及问题处理思路等关键信息。我们也将其纳入知识体系，构建出一个全面的“知识大脑”。基于此，我们搭建了一个多 Agent（Multi-agent）平台，实现研发代码的智能问答与生成，并将其集成进 IDE 中，使开发者在开发过程中能便捷调用相关信息进行学习。例如，过去新人入职通常需要资深同事“带教”，或者依赖大段文档来自行学习。而现在，新人可以通过与 AI 的对话方式，快速掌握一个三四年项目的核心内容。

这种对话有一定结构和提问顺序。首先，引导新人了解项目的背景和目标，然后逐步理解仓库的组织结构和架构设计，形成整体视图，最后深入到具体模块的核心逻辑，掌握如何运维和部署项目。对于新人而言，以前可能需要几周才能熟悉项目代码，现在通过 AI 的协助，仅需一到两天就能形成系统性理解。而且 AI 可作为一个 24 小时在线的导师，帮助新人随时解答疑问，提高学习主动性和效率。对导师而言，则可以大幅减少重复指导的时间，将精力用于更高价值的工作。我们也显著降低了文档编写的成本。通过对话生成，AI 可输出图文并茂的资料，例如架构图、设计说明等，减轻了团队的输出负担。

请问两位在团队内是否也有类似的实践？你们的成员在学习和上手阶段通常是怎样操作的？

张瀚元：我们现在也在尝试将企业资产进行结构化管理，尤其是针对新人的成长路径与学习资料。通过 AI 对知识的提炼和优先级排序，可以有效帮助新人聚焦于最核心的信息，快速融入团队。

蓝师师：不过文档还有一个难以避免的问题，那就是它的时效性。工程师普遍不喜欢写文档，但也讨厌没有文档。这是个矛盾点——人们往往缺乏主动沉淀知识的动力，就算曾经写过的文档，随着项目迭代也很难保持更新。如果要依赖 AI 做问答和学习，那如何确保这些知识是最新的、不至于误导用户？

张瀚元：根据我们的判断，大约 90% 的文档生命周期不超过一个月，只有少数内容会具备更长的使用周期。针对这些时效性强的文档，我们更希望能结合当前团队的目标和业务节奏，对其进行优先级排序和动态管理。我们一直认为文档本质上只是一个提效工具，是办公流程中的辅助手段，并不能替代人的判断。文档内容是否有价值、是否真正解决问题、是否抓住痛点，这些都很难由 AI 准确判断。

例如，同样一篇文章，其质量到底是 100 分还是 120 分，AI 很难给出明确判断。不同人对文档的接受程度也因个人经验差异而异。有人可能因为曾遇到类似问题，更认同某些文档的写法与内容。因此，我们在处理这些文档时，会将其与团队当前的目标、任务节奏相结合，通过设定优先级对其进行管理与整理。

吴云：几年前我们尝试搭建一个智能助手，目的是回答客户关于招标文件中的技术问题。我们的设想是，把客户的问题输入进去，由助手从知识库中一次性生成完整回答，交由人工审核后直接提交客户。但实际操作中，问题暴露了出来。

知识库的构建完全依赖团队成员主动上传内容。然而，很多文档都是有时效性的，随着公司的销售策略、管理规定或产品标准的更新，旧文档里的答案很容易变成错误的。更糟的是，不同的人可以上传不同格式、不同语言的内容，导致知识库变得杂乱难以维护。最终，这个系统因为无法保证回答的准确性而被废弃，团队也重新回到手工维护知识和人工回答客户问题的老路上。

现在大模型技术逐渐成熟，我们也在考虑用像 Dify 这样的平台，重新构建面向售前人员的智能问答助手。只不过这次我们吸取了经验，准备引入“生命周期”管理的机制，为每个知识点设置有效期，对一些易变内容设定较短周期，并定期进行审核和淘汰。这样才能确保知识的时效性和准确性，避免误导客户。

AI 能“重塑”哪些业务？

蓝师师：提效是第一步，但更深入的影响，其实是“重塑”。我们越来越多地看到，AI 不只是帮你干活，还能促使整个业务流程、甚至职责划分发生变化。这种更深层次的“智能重构”，你们有亲历或正在推进的吗？

张瀚元：以搜索为例，如今各大公司、搜索平台和引擎都在重新定义搜索的能力。在我们这样的互联网型业务中，搜索不仅是知识消费的重要入口，更是连接用户与内容的门户型功能。因此，今年上半年我们重点推进了搜索能力的重构，目前已经全面向用户开放。传统搜索更多依赖关键词匹配、倒排索引等机制进行内容检索与推荐。而我们现在通过 AI，对这一功能进行了更深层次的升级。

搜索的智能化背后，依赖的是一整套 AI 基础设施，尤其是面对文档、图片、视频、音频等多模态数据时，我们需要统一的、标准化的处理机制。因此，我们对用户已有的数据资产进行了重组，将原本分散的文字、图像等内容，通过向量方式进行统一存储与管理。

用户发起搜索时，我们可以快速识别其意图，并精准匹配出其希望获取的内容。同时，我们还能基于其行为和偏好提供进一步的推荐。更重要的是，在用户消费信息之后，系统还能辅助其开启新一轮的知识生命周期：从信息获取、再生产、再沉淀、再整理，最终再次被消费。这种循环正是我们构建智能搜索的核心目标。

蓝师师：目前腾讯文档在搜索资料片段时，文档的整体数据规模最大可以达到什么程度？

张瀚元：目前我们的向量规模已经达到百亿级。与其他文档平台不同，我们更强调社交协作属性。文档不再只是“个人资产”，而是在协作环境下支持更开放的权限控制，能容纳更多用户共同编辑，我们当前所支持的协作规模也是业内最大的。

蓝师师：我们这边在建设知识检索系统时，也经历了类似挑战。一开始只面对几千篇文档，问题不大。但当扩展到企业级别、几十万篇文档后，内容切片质量和检索效果差异就显现出来，Embedding 、重排算法（re-rank）、行为数据的利用等都成为影响问答质量的关键因素。你们在大规模文档检索方面，有哪些经验可以分享？

张瀚元：各个处理环节都做了大量优化。比如文档是流式排版，其换行方式各有差异。我们会根据内容进行智能切片，并保留一定上下文重叠，提升模型对上下文的理解能力。

文本文档相对简单，但处理表格就复杂得多，尤其是我们要支持超大表格。面对单个表格动辄几十 GB 的数据，我们要对其合理切片，并保留上下文信息，确保模型理解结构与数据的语义逻辑。同时还要支持用户基于这些数据进行列计算、聚合分析和图表生成等操作。

除了切片环节，我们还在多个阶段进行优化，例如：对用户搜索 Query 的重写、召回结果的多轮重排，从不同维度评估文档的相关性与相似度，最终再将处理后的结果提交给大模型，帮助其更精准地理解用户问题并生成高质量回答。

吴云：我分享一个去年在日本关西国际机场服务的案例。这个项目两三年前启动，目标是面向旅客提供一个聊天机器人服务。旅客可以在到达机场前，通过手机端查询停车、行李托运等信息；到达机场后，也可在自助一体机上继续使用该机器人；离开后还可以通过它处理如遗失物品等问题。

项目的核心目的是缓解 call center 和现场信息服务人员的工作压力，尤其是考虑到 2025 年大阪万博会将带来大量游客。传统客服方式难以应对高峰需求，因此我们引入无人化的聊天机器人，帮助处理旅客的常见问询，让人工资源聚焦于更复杂的服务任务。这样既提升了旅客的满意度，也提高了运营效率。

蓝师师：在实际部署过程中有没有遇到什么困难？尤其是在服务质量和用户体验方面，你们是如何保障的？怎么确保这个机器人不会因为答非所问而降低用户满意度？

吴云：面向客户的聊天机器人，准确率必须接近 100%。因此我们没有使用大模型生成内容，而是采用传统的 FAQ 问答系统，通过用户输入匹配预设问题，从而返回一到三个高匹配度的答案，避免大模型生成时出现的不确定性。

如果用户的问题在 QA 表中没有匹配项，我们的后台系统会自动记录这些问题，由人工定期补充、维护，持续优化问答质量。尤其是在机场这样高频、标准化的场景中，我们更倾向于保障准确率和一致性，而不是追求生成内容的丰富性。

蓝师师：我们的方式是：先用大模型批量生成 QA 对，再由人工筛选、整理后进入知识库。这样既利用了 AI 的生成能力提升效率，又保障了最终回答的准确性。

我的角色是产品经理，传统上我们其实很少参与编码。但现在 AI 的出现，衍生出很多“产品经理、研发人员是否还需要精细分工”的讨论，比如“一键写代码”“自动生成交互设计”等等，好像各职能都能用 AI 能力互补。但从我的实际体验来看，至少目前还做不到真正替代。尤其在像游戏这样的大型项目中，仓库结构复杂、历史技术债深厚，AI 很难单独应对。

所谓的“重塑”更准确地说，是开发左移、质量左移的过程。以前我们的交付物是 PRD 和交互稿，之后才是开发 Review 和开发实施，再经过一段时间才进行体验反馈。而现在，这种流程正发生着明显的前移和融合。出现后，产品经理在前期的产品可行性验证中能做得更多了。以构建 AI 搜索产品为例，我的工作已不再是单纯撰写需求文档和画交互图，而是定义两个关键数据集：训练集和验证集。最基础的验证方式是通过 Prompt，基于已有 Embedding 数据集测试搜索能力；进阶一点，我们可以使用如 Dify 等 AI 编排工具，实现更复杂的流程，比如意图识别、分类或兜底策略等。

进一步地，为了更好地与开发同学对齐产品愿景，我们会使用 Vibe coding 工具搭建前端页面，并连接编排 API，构建原型。这种方式比以往的交互稿更直观，有助于拉齐认知、加速落地。功能上线后，我们还需评估 AI 搜索的实际效果。这包括建立测评管线，通过验证集及线上数据，定期评估问答质量。

同时，开发流程也发生了变化。例如“质量左移”：过去，测试压力多压在 QA 上，虽然强调 Code Review，但在时间紧任务重时往往难以落实，进而影响代码质量。而现在借助 AI 工具，开发同学可以在提交前发现并修复问题，从源头上提升代码质量。我们的千行代码 Bug 率也显著下降，减少了对 QA 的依赖。所以我认为，AI 不仅重塑了业务流程，也重构了整个组织的协作模式。

张瀚元：虽然 AI 能协助 Coding、Code Review、Code Fix 等，但它仍只是工具，不能完全脱离人类。打个比方，AI 可能代替我们做很多事情，但它永远无法“背锅”。面对失败和批评，我们仍需要人为判断与调整方向，这是 AI 无法替代的。

吴云：AI 在研发提效上确实作用巨大。我最近了解到一个小型产品，能将用户需求直接转化为产品原型。流程是将用户需求输入大模型，结合链式思维和提示词，再传入需求原型模型，生成产品原型和流程图。他们的口号是：“上午谈需求，下午演示产品。”尽管初始准确率约 80%，但通过微调可提升到 90% 甚至更高，这种方式极大提升了从需求到产品原型的效率。原本 AI 主要应用在编码提效上，现在逐渐扩展到需求阶段，对研发流程的重塑正在逐步深入。

听众提问：老师可以再谈谈关于聊天记录归档和整理方面吗？

蓝师师：现在很多公司都有自己的 IM 工具，在群聊中其实会沉淀大量有价值的信息。第一种情况是需求讨论，我们经常在群里讨论一个需求是否可实现、实现路径、技术限制等，甚至会有人指出需求存在的问题，需要修改的点。第二种情况是待办事项，讨论过程中会自然形成任务分配，过去这些内容需要群主或关注人手动“爬楼”，再整理成 Todo，最后开入工单系统。第三种情况是用户答疑，特别是在用户群中，消息很多，很容易遗漏用户提出的问题或未解答的问题。

针对这些场景，我们做了一件有趣的事：在聊天系统中接入了一个小助手，通过建立一条管线，定期抽取聊天记录并进行处理，结合业务场景进行分类整理。如果是 FAQ 场景，我们会提炼出有代表性的问答，沉淀到知识库中，供下一轮自动问答使用。如果是需求反馈，我们会提取出围绕某个需求点的讨论内容，特别是变更前和变更后的信息，然后将其与原始需求文档进行比对和整合，最终生成一份清晰的 Diff。这对文档编写者非常有帮助，因为以往需要爬楼查找修改点，还常常因遗漏而导致需求不一致。现在通过自动生成的差异内容，可以有效提升文档的准确性和一致性。此外，对于待办事项的提取，模型在结构化信息处理上的能力也非常强，能快速提炼出 Todo list。

AI 更多是一次性项目，还是能力资产？

蓝师师：做一个 AI 项 目不难，难的是让 AI 能力变成组织的长期资产、甚至成为平台能力。你们在这方面有哪些尝试？是否有形成体系化能力的路径？有没有一些经验可以跟大家分享？

张瀚元：对于我们自身的业务来说，这项工作无疑是一项长期的能力建设，而不是一次性的项目。市面上的很多软件，尤其是在互联网行业，往往专注于解决某一具体环节或问题，不同产品各自聚焦于不同的问题或需求。

就腾讯文档而言，我们目前覆盖了十个大类产品，除了常见的 Word、Excel 和 PPT，还包括智能文档、智能表格、智能白板等。每一类工具都针对不同的使用场景设计，我们的产品矩阵本身就很丰富，因此当我们尝试用 AI 去重构业务时，面临的挑战和复杂度也更高。

从技术角度看，这要求我们拥有一个强大且稳固的技术底座，也就是所谓的 AI 中台，以持续支撑上层的业务和应用。以 PPT 为例，目前市面上已有不少 AI 生成、改写、润色 PPT 的产品。而我们关注的并不仅仅是如何把 AI PPT 做得更好，而是更进一步思考如何通过标准化、流程化的 AI 基础能力，赋能其他产品品类。比如，能否将 AI PPT 中的能力迁移至白板工具中？能否将表格的 AI 能力复用于智能表格？我们希望实现的是不同品类之间的能力迁移，从而降低用户对具体 AI 功能的显性感知。

在我们的理解中，真正优秀的 AI 产品，并不应该让用户清晰地察觉到“这是一个 AI 功能”。用户并不关心某个功能是不是由 AI 驱动的，他们关心的是问题是否被解决。我们不希望通过简单地植入一个 AI 助手或标注“AI 功能”来体现技术存在，而是希望 AI 能够润物细无声地嵌入用户体验中，真正帮助用户提高效率、优化体验，实现更长期的价值提升。

蓝师师：在与各业务线协同过程中，会面临一个挑战——不同业务的诉求差异很大，而且很多对接人对 AI 的理解可能不如实际操作者那样深入，甚至会提出一些不太合理的需求。从你的角度看，你认为中台如何更好地与前台业务协作，共同打造出更好的 AI 产品？

张瀚元：我认为，首要的一点是“标准化”。在构建 AI 能力的过程中，我们发现有些元素是会变的，但也有一些是不变的。我们需要理清这两者之间的关系，抽取出那些可以标准化的部分。比如我们的一些核心业务流程和既有能力，其实在上层表现形式上是相对稳定的，比如翻译功能或 PDF 的处理能力。这些功能在未来仍会存在，只是其底层实现方式可能会从传统 NLP 模型迁移到更先进的大模型。

此外，在 SaaS 和私有化场景，尤其是 ToB 业务链路中，企业往往出于安全考虑，不希望自己的数据被外部模型调用用于训练。因此，他们更倾向于采用自有模型能力，并要求我们进行对接。这就要求我们提前设计好相应的抽象接口，保证在不影响上层业务逻辑的前提下，能够灵活替换底层的模型与基础设施。

举例来说，有些客户可能没有使用向量数据库，而是依然依赖于传统的 Elasticsearch 进行数据存储；有些企业不能接入 ChatGPT 或 DeepSeek，而是使用千问等自研或本地模型。我们的目标是通过标准化和抽象，将 AI 能力模块化，从而应对不同客户和业务场景的需求。这不仅有助于我们为多个项目提供赋能，也让我们能在长期维度上持续提升自身的技术能力和产品质量。

吴云：这里分享一个我辅导的日本企业的案例，我为他们做的第一件事，是为其中国区高层近 60 人开展了一次培训。培训内容主要包括大模型与 AI 的基础理论、行业应用案例、提效效果、安全性问题，以及企业在人才引进与培养方面的组织应对策略等。完成高层培训后，我们进一步面向基层员工开展全员线上培训，尤其聚焦制造业的业务和职能部门，讲解大模型可落地的应用场景及相关工具。

鉴于员工分布在各地，这些培训大多在线上进行。我们还提供了 B 站上的工具教学视频，帮助他们在培训后继续学习。接下来会深入各个部门，尤其是制造部门，根据他们的需求进行更具体的支持。由于线上培训缺乏实操环节，线下我们会协助他们搭建与业务相关的职能体系，指导使用 AI 工具，帮助其开发具体场景下的 AI 应用。

随着他们对大模型能力的理解逐步深入，往往也会提出一些更定制化的需求，需要与软件公司合作开发应用，把 AI 能力真正固化在组织之中。通过这套从培训到落地的辅导体系，企业不仅在员工层面实现了能力提升，也逐步构建起组织层面的 AI 能力。

蓝师师：我觉得这个路径确实非常科学。一开始先通过系统培训拉齐大家对 AI 的认知，破除神话，然后再引导他们基于已有工具结合自身业务场景做小规模的试验。试验后如果有可规模化落地的可能，再和技术方合作进行平台化、产品化的深化推进。

我们这边其实也遇到过类似的情况，比如我们在培训中介绍 Dify 的使用场景时，大家兴趣很高，但听完之后会觉得上手难度大，最终选择放弃。我想知道你们那边是否也碰到类似问题，又是怎么解决的？

吴云：像 Dify 这样的工具，虽然定位是面向非技术人员的，但一旦涉及稍微复杂的应用，业务人员还是会觉得困难，需要技术人员介入进行搭建。不过这并不妨碍业务人员去使用 AI，很多场景下，他们仍可以用 Dify 搭建出一些精度不是特别高但满足基本需求的工具，这本身就能带来明显的提效。

如果这些应用在 ROI 上能体现价值，企业往往会进一步投入资金和人力，安排开发人员做支持。像 Dify 这类工具需要部署服务器、承担流量成本。这些投入如果能由企业承担，就能有效推动 AI 应用在组织内部的落地。

蓝师师：这类工具上手门槛较高，所以我们在完成初步培训后，会进一步为用户提供基础场景的模板。我们会事先梳理出常见的应用场景并进行分类，然后将每类场景中最简单的编排逻辑固化成模板，让用户挑选符合自身痛点的场景，基于模板进行修改。

除了模板支持，我们还会组织一些激励性质的小型比赛，鼓励大家在使用过程中尝试创造内容。这样一来，用户参与的积极性会提升，过程中也会享受创造的乐趣。我们还有一个基本要求：完成编排实践后，必须在企业内部的知识分享平台上沉淀成果，分享操作心得和解决问题的经验。

推动一个已经验证有效的 AI 产品落地，通常会涉及两种方式，行业中一般称之为“+AI”和“AI+”。“+AI”是以原有业务为核心，适度叠加 AI 能力，比如在已有流程中新增生成、扩写等小功能，提升效率，这类属于局部增强；而“AI+”则是以 AI 为核心，从底层重构整个业务流程，打造原生 AI 产品形态。

这两种方式的设计与落地难度差异较大。如果希望体系化构建一个高效的 AI 产品，我建议采用“三步走”的方式：第一步是以“+AI”的形式，在现有流程中嵌入小能力，收集用户反馈，验证功能是否真正解决了痛点。这一步很关键，因为看似不错的想法，一旦融入真实流程，用户未必接受。

在收集到足够的用户反馈与数据之后，第二步是尝试“AI+”，即以 AI 为中心，重构关键业务流程，引导用户建立新的使用习惯，逐步过渡到更原生的 AI 体验。最终第三步，是全面打造 AI Native 的全新产品形态。事实上，如果你了解一些 AI 编码工具的发展路径，会发现它们大多也是按照这一模式演进的。

以 Trae 为例，它的前身是 MarsCode，本质上是一个基于传统 IDE 的插件，只在需要时调用问答、生成等能力，不改变用户原有的编码习惯。当用户逐渐习惯后，Trae 以一个更完整、更流畅的 AI IDE 产品形态推出，提供更原生、更顺滑的体验。我们可以从“+ AI”或“AI+”两个角度去思考产品路径，但不必强求一定要做到“AI+ ”才有价值。很多使用频率高、解决痛点深的小功能，依然能显著提升日常工作效率。

张瀚元：“+ AI”和“AI +”这两种模式，觉得可以理解为在面向用户的业务层或应用层上，如何更好地向用户呈现 AI 能力。这两条路径并不冲突，反而可以结合使用。例如在文档编写或代码编写场景中，既有 Copilot 这样的加 AI 辅助工具，也有 AI IDE 这种原生方式。两种方式各有优势，也各有局限。

对于不同用户来说，他们的偏好也不尽相同。有些人习惯自己动手编码，更适合用 Copilot；有些人更喜欢由 AI 提供完整支持，AI IDE 更适合他们。文档场景也是一样，有人偏向使用 AI 扩写或润色，有人则喜欢更原生的写作方式。

所以我认为，这两种路径并不冲突。考虑到当今上层业务变化频繁、场景更新迅速，我们每天可能都面临新的小应用、产品或流程，这种快速迭代也要求我们根据实际业务场景的特点灵活选型。最重要的，是因地制宜地进行定制化，选择适合当前问题和用户习惯的方式，这可能是更可行、也更具落地性的做法。

听众提问：作为 IT 部门的同学，如果希望在企业内部推广 AI 能力与优势，应该如何选择一个合适的场景，促使业务部门和管理层积极参与，从而顺利实现落地？

吴云：从管理层角度来看，最核心的考量是 ROI，也就是投入产出比。如果 AI 能力能够明显提升效率、降低成本，管理层会更愿意推动落地。而从业务人员的角度来看，他们关心的是 AI 是否真正解决了具体业务中的痛点。业务部门如果认同 AI 能力的价值，愿意提出明确需求并配合落地，那么推动起来就会顺利得多。

蓝师师：在推动落地时，决策者的参与非常关键。比如我们觉得一个 AI 编码工具很好用，但采购需要审批，需要预算支持，只有管理层认可其价值，业务部门才能真正使用。而即便工具采购进来了，还要解决“用得起来”的问题。

我们遇到的情况是，决策层关注的是这个工具是否真的带来了实质价值。这个价值通常需要通过参考同行的成功案例，加上公司内部的一些小范围试用反馈来传递。通过这些信息同步，让他们建立起对工具效益的清晰认知。当管理层认可了工具的潜力，并判断它与公司未来发展方向契合，才可能决定正式引入。

引入工具只是第一步，真正的挑战在于“落地”。很多时候，工具本身并不差，问题在于人的习惯。例如我们在内部推广 AI 编码工具时发现，经验丰富的工程师往往接受度反而较低，因为他们早已形成固定的编码习惯，对新工具的兴趣不大。而年轻同事的接受度普遍更高。

针对这种情况，我们采取了一些内部运营手段，比如定期举办应用大赛，鼓励员工参与并在过程中探索工具的价值。赛后会组织经验分享，同时从中筛选出一些 KOL，让他们以“自己人”的身份、用自身实践向其他团队分享工具的价值。因为相比产品经理或采购方的推荐，来自同事的“口碑”更容易被信任。

此外，我们还会结合日常用户数据，分析使用活跃度、流失情况，并进行用户访谈，了解他们遇到的问题。有些人可能是不知道怎么用，有些则不了解工具能解决哪些问题。基于这些调研结果，我们再有针对性地进行下一步改进或引导。

从采购到真正落地，其实是一个偏文化驱动的长期过程。这中间需要花很多时间去教育、运营和迭代，才能真正让 AI 工具在企业内部发挥应有的价值。

趋势观察

蓝师师：在你们各自的行业或视野中，AI 应用的下一波值得关注的变化是什么？有哪些方向你们已经开始试水，或者建议大家提前关注？

张瀚元：对于我们这种以文档为核心的业务来说，目前正在推进的未来方向主要有两个。第一个方向是“超级 Agent”。因为文档领域本身涉及知识的获取、沉淀、整理、输出等完整生命周期，我们设想打造一个能够贯穿全流程的 Agent。当我们给出一个命题或方向时，它能自动执行一系列操作，包括从网络获取信息、筛选有用内容、结构化归纳，并以层级方式组织、沉淀，并进一步以固定形式输出，形成闭环。通过这种 AI 流转的迭代方式，这个 Agent 能够自动完成知识管理的全过程，从而大幅提升效率，释放人力。

第二个方向是“AI Native”。我们的文档产品涉及大量复杂格式，特别是在 Word、Excel、PPT 这些传统办公工具中，背后都依赖微软推出的 OOXML 协议。这是一套结构复杂、标签众多的 XML 编码标准，用来定义文档的各种格式。单是协议文档本身就有数千页，其中 Excel 的函数就超过上千个，但日常用户真正常用的只有十几个。我们希望通过将这一套协议“喂”给大模型，让 AI 能够直接生成结构完整、排版精细的 Word、PPT、表格等内容。这样 AI 的输出就不仅限于 Markdown 或 HTML 这种粗粒度的标记语言，而是能够精准处理段落级、文字级的内容，输出真正精美、结构化的文档成果。

吴云：现在很多企业已经在使用大模型，但如果只是停留在问答级别的使用，实际上对企业提效的帮助是非常有限的。稍微进阶一些的应用是构建知识问答系统，扩展知识库内容，但这仍不够。真正有价值的，是将大模型能力与企业现有 IT 系统深度集成，包括企业内部的文档与数据系统，从而开发出新产品、新服务，提升整体服务能力。

在 DeepSeek 出现前，Agent 落地面临很大挑战——一方面是模型本身能力不足，难以准确调度工具；另一方面工具编排的能力也有限。但 DeepSeek 的出现在一定程度上提升了解决这些问题的可能性。与此同时，MCP 的逐渐成熟，也帮助模型实现对工具的有效调用。通过 MCP，我们可以将企业的各类 IT 系统封装为标准接口，供模型调度使用，从而实现在企业内部快速构建面向业务的职能 Agent，推动自动化落地，释放生产力。

以我们公司的 ERP 系统为例，我们的第一阶段是做内容生成，比如点击按钮后自动生成一段文字，用 AI Assist 辅助填充输入区域。第二阶段是知识问答：在 ERP 系统的右侧页面提供聊天窗口，针对业务操作中的疑问进行实时答复。第三阶段，我们正开发类似 Dify 的 Agent 开发平台，与 ERP 系统无缝集成。这些 Agent 可以直接读取系统数据，用于内容生成、任务编排，最终实现业务流程的智能化与自动化。

听众提问：涉及到各种 API 对接的时候，应该如何实现该规范的抽象统一呢？是否有更可行的技术路线吗？

蓝师师：我们的目标是从一个简单的业务需求出发，首先对其进行分类分级。对于较为简单的需求，可以尝试由 Agent 执行完整的端到端交付流程，最终生成代码，由程序员做二次审核后即可上线。而对于业务背景复杂、需求不明确的情况，则更适合采用 AI Assistant 模式，辅助开发者提升各个环节的效率——包括技术规划、代码生成、差异审查、单元测试等环节。

第二点，我们特别关注“上下文工程”，这是目前讨论非常热的方向。过去大家谈得比较多的是 Prompt 工程，强调如何写好提示词。但实际上，仅有 Prompt 是不够的，因为大模型的上下文窗口是有限的，而其能展现的能力很大程度上受限于上下文质量。因此，工程化地管理上下文，就变得尤为关键。

我们需要思考如何在有限的上下文空间内，构建并输入最优的信息。这背后涉及到知识治理：如何提炼、固化高质量信息，并通过分类、打标、知识图谱等形式进行聚合；再通过更优的召回与排序策略，在检索阶段将关键知识动态整合进上下文中，从而放大模型效能。

尤其在编码场景中，输入的信息量大且碎片化，我们需要系统地处理“短期记忆”与“长期记忆”的管理。例如：如何将短期工作信息结构化沉淀，成为下一步的上下文输入？或如何将经验固化为可复用的规则或工作流？像 Cursor 就采用了 cursor rule 来固化经验，Windsurf 也有其专属的 workflow 系统，而 Davin 则能基于长时间对话生成小结，优化后续对话的上下文输入。上下文管理与工程能力，将成为构建高质量 AI 应用的核心能力。

会议推荐

首届 AICon 全球人工智能开发与应用大会（深圳站）将于 8 月 22-23 日正式举行！本次大会以 “探索 AI 应用边界” 为主题，聚焦 Agent、多模态、AI 产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！