AI距“闭眼交付”为时尚早、程序员和产品经理天天Battle，大模型应用真实现状 | 万有引力

嘉宾 | 张家瑞、陈奕名

对话 | 唐小引

编辑 | 屠敏

出品 | CSDN（ID：CSDNnews）

“大模型应用开发时代，人人都是程序员。”这是许多人对 AI 时代的美好想象：不懂代码也能构建应用；几小时内做出一款小游戏；写几句 Prompt，AI 就能帮你生成 UI、补全逻辑、连通接口。从此，软件开发似乎不再是程序员的专属技能。

然而，这种体验更像是“玩具”层面的创意实践，距离真正的产品化落地仍有不小的距离。简单来看，应用想要跑在真实业务场景中，无疑意味着系统之间的稳定集成、任务链条的有效承接、用户需求的真实满足，甚至是与业务逻辑的深度嵌套。而当开发者试图往这个方向迈进一步时，很快会发现：仅靠 Prompt 写代码远远不够。

这正是 Agent 概念走红的背景，也是 MCP 等系统性架构被提出的原因——人们希望构建的不只是“会对话”的模型，而是“能做事”的智能体。但从构想到现实，To B 和 To C 场景下的问题各不相同，大模型的集成牵涉系统架构与业务逻辑的深度适配，Agent 的上线过程远比想象中更复杂，MCP 架构在接入业务中也并非万灵药。

为此，在CSDN &《新程序员》执行总编、《万有引力》主理人唐小引的主持下，CSDN《万有引力》栏目在全球机器学习技术大会上特别邀请了两位来自一线的应用实践者——恒生电子研究院算法团队负责人陈奕名、金山办公 AI 应用算法负责人张家瑞，围绕大模型开发中的关键难点展开深度对谈。他们分别深耕金融科技和办公产品场景，代表了当前大模型 To B 与 To C 应用的两条典型路径。通过他们的实战经验，也许我们能更清晰地理解，大模型真正落地之前，还要跨过哪些坎。

AI 产品爆发，但你的痛点解决了吗？8.15-16 北京威斯汀·全球产品经理大 会 PM-Summit，3000+ AI 产品人社群已就位。
直面 AI 落地难题、拆解头部案例、对接精准资源！

扫码登记信息，添加小助手进群，抢占 AI 产品下一波红利：

进群后，您将有机会得到：
· 最新、最值得关注的 AI 产品资讯及大咖洞见
· 独家视频及文章解读 AGI 时代的产品方法论及实战经验
· 不定期赠送 AI 产品干货资料和秘籍

ToB 与 ToC 的真实战场：大模型行至何处？

唐小引：从 ChatGPT 到 DeepSeek-R1 的出圈，大家都在关注：大模型应用开发到底走到哪一步了？请两位老师先做一下自我介绍，然后分别基于自身所在的 To C、To B 行业分享 AI 应用的最新进展。

张家瑞：我于 2019 年加入金山办公，目前负责金山办公的 AI 算法应用团队。我们团队的日常核心工作是将机器学习、深度学习等算法应用到具体业务中，提升用户的办公体验。

进入大模型时代后，我们也迅速转向、积极拥抱这一新技术，将其应用于文档、演示、表格等核心组件中，推动一系列新功能的落地。可以说，我们的工作就是打通从算法到产品的“最后一公里”，也是最具挑战的一步。

时下，我们的重点工作集中在 WPS AI 2.0 的开发上。从 WPS AI 1.0 迭代到 2.0，我们上线了许多全新的 AI 功能，并提出了四个核心的 AI 助手，覆盖日常办公中最常见的应用场景。

以文档处理为例，用户最常进行的操作无外乎“读”和“写”。在写作方面，写作助手可以提供润色、改写、错别字纠正等支持；在读文档方面，阅读助手具备文档翻译、内容总结和问答等能力。

除了文本的撰写和理解，文档处理还包括一些视觉和排版相关的任务。例如，插图生成、图像超分辨率处理、智能抠图、PPT 页面设计等，我们将这类功能整合为AI 设计助手模块。

最后一个模块是数据分析助手，主要面向对表格有深度使用需求的用户，比如财务人员，他们常常需要处理复杂的、成千上万行的报表数据。通过自然语言描述，用户可以借助该助手完成数据分析、生成透视表、编写公式以及进行表格的整理和美化等操作。

除此之外，我想重点介绍一个我们近期着重推进的方向——文档生成 PPT。

大家可能已经在如 Kimi、豆包、天工等大模型产品中看到“一键生成 PPT”这一功能。这类工具通常基于一句话输入，再结合大模型自身的知识储备或搜索引擎返回的结果自动生成一份 PPT。这种方式的优点是生成速度快，操作简便。

但它也有明显的局限——无法利用用户自身的私有文档内容。比如，如果我想基于过去四周的周报生成一个月度总结，大模型并不了解这四周我具体做了什么。

因此，我们当前重点打磨的，是一种能够“基于文档生成专属 PPT”的能力。用户可以选择自己的总结、财报、报告、教案等内容作为输入，让系统生成一个高度贴合自身需求、真正个性化的 PPT。这种方式也获得了时下用户较高的认可和反馈。

唐小引：大模型在办公场景中，已经能胜任哪些任务？还有哪些能力尚未实现？在这个过程中，人与 AI 的协作处于怎样的阶段？你理想中的人机协作形态又是什么样的？

张家瑞：就当前的情况来看，大模型在办公场景中已经在多个方面显著提升了效率。例如，在写作时，甚至在我自己写代码时，都会借助 AI 生成初稿，帮助快速搭建出大致框架。

但要说已经发展到可以“闭着眼睛”直接交付文档或运行代码的程度，我认为还存在一定差距。这个差距来自两个方面：

• 一方面，是对 AI 的信任度问题。当前即便使用 AI 生成了报告或文章，用户仍会选择人工复核、校对。这说明我们在实际使用中，仍需要人为把关内容的准确性和质量。

• 另一方面，在对外展示或正式汇报的场景中，例如需要制作一份“满分级别”的 PPT，通常还需要设计师参与美化与排版，或者由本人对内容进行多次修改和完善。

我认为，AI 目前已经能够帮助我们完成从 0 分到 60 分、70 分，甚至 80 分的初步工作。但要将成果打磨到 100 分，仍需人工介入：一部分是用户自身的检查与润色，另一部分则是设计等专业环节的人工优化。

唐小引：从 To B 角度来看，金融行业以及恒生电子团队在 AI 领域的最新进展如何？

陈奕名：我目前主要聚焦于恒生自研大模型 LightGPT 的训练，并在此基础上构建上层应用，比如金融场景下的 RAG、审核、信息抽取等。在这个过程中，我们踩过不少“坑”，积累了不少实战经验。

在我们探索金融场景中的 AI 应用时，用我们院长白硕的一句话来说，就是产品与技术在“双向奔赴”。产品团队基于大量客户需求，深入挖掘真正的痛点；而技术团队则思考，如何以尽可能低的成本，同时解决多个需求点。

举个例子，如果过去需要 10 个人才能解决的问题，技术团队就需要评估当前的技术趋势，判断是否有可能通过未来的发展来更高效地解决。有些问题，当前解决成本较高，但如果预判某项技术将在两年内成熟，我们可能会选择暂时搁置这个需求，待技术成熟后再回头解决。

唐小引：如何判断某项技术两年后一定能够成熟？这样的判断依据是什么？

陈奕名：我可以举一个例子来说明。现在大模型的发展趋势，实际上与 2017 年计算机视觉（CV）领域中 CV 模型的兴起非常相似。

彼时 CV 模型刚兴起时，我在京东数科实习期间曾参与过一个项目，是做猪脸识别——即给猪进行面部识别。这项技术本质上与人脸识别非常接近。

我们当时尝试了各种 CV 算法，比如 YOLO、Faster RCNN、Mask R-CNN 等。效果最好的模型参数量往往非常大，例如 Mask R-CNN 可以达到 800MB 或 1GB 的规模，而 YOLO 模型通常只有 50MB。尽管大型模型效果更好，但在当时很难实际部署。

但到了 2020 年，随着边缘计算能力的提升，我们开始能够在小型设备上运行当年的大模型。例如 Mask R-CNN 已经可以较为顺畅地在边缘设备上部署。换句话说，早期选择效果更好的模型做积累，当硬件成熟时就可以顺利落地。

今天的大模型也有类似趋势。最初流行的多是参数量高达 72B 的模型，而如今，随着 DeepSeek 等项目的发展，我们已经可以使用经过蒸馏压缩的 32B 模型。这种模型在保持性能的同时，参数量更小，更易部署。

硬件的发展也在不断推进。无论是华为的 NPU 还是其他国产 GPU，整体性能和性价比都在提升。再加上算法层的持续优化，模型的部署门槛会不断降低。因此，我们的策略是，先用当前性能最优的大模型（比如 72B）完成任务，而不是过早地为“如何压缩模型”而牺牲效果。未来随着硬件与算法的进步，自然会推动成本的下降与部署的普及。

唐小引：金融领域的不少从业者认为，通用大模型难以满足行业的垂直需求。你怎么看待这个问题？

陈奕名：垂直场景可以分为两类：

• 第一类，是可以在互联网上搜索得到的内容，比如金融法律法规数据。这类数据往往也被通用大模型所覆盖，因此专属模型在这方面的优势空间正在被不断压缩。

• 第二类，是企业内部的专属数据，例如我们公司内部的生成代码相关内容。这些知识既无法公开获取，也缺乏外部语料支持。比如我们曾遇到一个问题：在开发中，如何快速定位“注册模块”的代码位置？从常规逻辑看，应该搜索与“注册”相关的文件。但实际上，在我们内部，它被归在一个名为“网络投票（特殊）”的模块中。这种与业务强绑定的语义，通用模型是难以理解和处理的。

  对于此类任务，我们会训练较小规模的定制模型，通过注入企业内部知识，实现更高效的提效。

唐小引：恒生电子内部的实际使用中，目前采用的是大模型与小模型协作的方式？

陈奕名：是的。

唐小引：结合团队的实际经验，金融行业在大模型应用中最受关注的技术瓶颈和已有的突破是什么？

陈奕名：可从两个方面来看：

第一是金融类长表格的处理问题。在金融类大模型的实际应用中，很多人可能第一反应是模型的金融知识不够，导致回答不准确。但我们发现，这类问题其实通过优化提示词（Prompt）已经能够解决 95% 的情况。

真正的难点在于长表格。比如在处理招股说明书时，会遇到各种表格，其中利润表通常篇幅较短，但专利信息的表格可能会持续 10 到 20 页，涉及多个维度，如发明专利、外观专利等。这种大体量的结构化信息超出了当前大模型的上下文窗口，很容易造成处理失败。

我们的应对方法是：用工程化的方法把解析过程拆分成了几个步骤。首先，我们先定位关键信息的位置，这相当于先做了一次检索；接着再把这些关键区域的内容提取出来，送给大模型进行处理。通过这种方式，就能较好地应对一些超长表格的解析问题。

第二个难点在于模型能力的提升。其实提升模型能力无外乎几种方式：第一种是改 prompt，这也是最简单的方式；第二种是调整采样方式，就是在不重新训练模型的前提下，通过控制它的输出采样策略来增强表现；第三种才是直接对模型进行训练。

但问题在于，大多数人首先就倾向于选择训练这条路。然而只要一涉及训练，就绕不开一个非常现实的难题。比如我说想训练一下这个模型的能力，我的领导就会立刻问我：“那你准备投入多少人力？”我算了一下，大概需要一到两周的数据准备时间，可能得 14 个人，再加上算力工程师的支持也得 7 个人日。他说：“我现在没有这么多人手，没法专门为一个场景投入。”所以这条路径基本上就被“掐死”了——尤其当我们还要同时服务多个客户时，靠训练是覆盖不过来的。

其次，改 prompt 虽然简单，但能力提升也比较有限。最后，我们转向了采样控制的方式。我们探索的是，如何通过调整采样策略，让模型在生成时“意识到”：在某些场景下不要太发散，需要更严谨一些。我们用这种方式去“管住”它的输出，尽可能逼近我们预期的效果。

不同场景下，如何写好 Prompt？

唐小引：我个人一直觉得提示工程并不容易，很多人说模型不给力，其实是提示词写得不对。但提示词怎么写才算“对”？这在金融场景中，你是怎么把握的？

陈奕名：确实，我们在实践中也总结出几个关键要点：

第一，避免“脑补”信息。比如之前我们提到某个“注册”模块，业务中实际代码放在“网络投票（特殊）”模块里。这种非通用、绑定业务语义的知识不能默认模型“应该知道”，而是必须在 Prompt 里明确说明。不能以为模型能理解你脑中隐含的上下文。

第二，避免依赖情绪化或模糊表述。以前我也犯过类似错误，比如在 Prompt 中加入类似“你一定要写得很好”、“请一定帮我完成”等祈求式措辞。但这种话对模型没有实际约束力，反而会造成生成内容发散、结果不可控。关键还是要明确任务目标、具体约束，而非情绪化引导。

唐小引：在张老师看来，提示工程在面向行业和面向 C 端用户时，有什么不同吗？

张家瑞：我们在产品设计时，通常不会直接把 Prompt 写作的接口开放给用户。提示词是由内部的产品经理或 Prompt Engineer 预先编写好的，用户点击某个按钮时，实际调用的是我们封装好的 Prompt。

当然，我们也接入了 DeepSeek、MiniMax 等模型，允许用户自己设定提示词。

从我们实际使用来看，Prompt 编写质量的好坏，最好的办法是把你写好的提示词交给一个完全不熟悉这个业务的同学去看，看看他能不能通过这段提示词快速理解你要完成的任务是什么、有哪些注意事项。如果他能理解，大模型通常也能理解；但如果他觉得提示词里有规则漏洞、说明不清，或者不知道下一步该怎么做，那么大模型也大概率会“卡壳”。

之所以一定要找不熟悉业务的人，是因为熟悉业务的同学脑中已有任务的背景知识，他们在写提示词时，很多内容其实是依赖了脑海中的默认信息，可能提示词里有些缺失自己也察觉不到。但对一个“陌生人”来说，这些信息必须写清楚、写完整——能否让陌生人看懂，其实就是判断提示词质量的最好方式。

大模型应用开发的最新进展

唐小引：大模型出圈以来，“如何做好落地”是一个热门话题。早期应用常常面临两个问题：幻觉问题和数据隐私问题，尤其在金融行业尤为突出。如今，经历了两三年的发展，再加上今年 DeepSeek 的爆火和 Agent 概念的火热，大模型应用开发上发生哪些新变化？

陈奕名：在金融领域，我们通常通过外挂知识库的方式来缓解模型的幻觉问题，也就是采用 RAG 技术。但如果从根本上希望减少幻觉，仍需从模型本身着手，比如通过强化学习对模型进行微调。

我们在今年 1 月 DeepSeek 发布 R1 模型后观察到一个现象：当模型的“思考过程”变得较长时，其幻觉问题依然比较明显。

为了解决这一问题，我们在工程实践中通常会将任务进行拆解。首先需要分析幻觉产生的原因。总结来看，幻觉往往出现在以下几种情况：

1. 回答事实性问题时；

2. 面对复杂任务时；

3. 提示词表达不清晰时。

自行优化第一种和第三张情况后，我们重点聚焦在第二种：任务本身是否过于复杂。我们的做法是尽可能将复杂任务拆解成多个小步骤。比如，让模型识别“陈奕名”这个名字或回答“水是什么”这样的任务非常简单，几乎不会出错。但如果让它先抽取名字、再生成十个名字、再为每个名字构建一个族谱，模型就容易出现幻觉，甚至每次输出都不同。

因此，我们在实际项目中会将任务尽量拆分细化，以提高准确性。不过，归根结底，幻觉问题的长期解决方案仍然是提升模型本身的能力。

唐小引：除了幻觉问题，金融行业对数据安全也高度重视。而在应用端，大家近来都在关注 Agent 的发展，比如从年初的 DeepSeek 火爆开始，再到 MCP 等新技术的推进。你在这方面有看到哪些变化或趋势？

陈奕名：其实我们过去一年一直在重点投入 Agent 相关方向。可以说，随着大模型能力的增强，Agent 的应用也逐渐具备现实可行性。

在 DeepSeek R1 发布之前，Agent 面临的一个主要问题是“规划能力不足”。在模型能力尚未成熟的阶段，Agent 经常无法按照设计意图执行任务，甚至会陷入无限循环。比如我们测试过一个问题：“关羽和张飞谁的战力更强？”模型会先尝试比较战功，发现差距不大后，又回头再比战功，如此循环，一直跳不出来。这种情况下，Agent 的表现就很难称得上智能。

因此在那之前，我们当时重点在提升 Agent 的插件调用能力。但 R1 模型发布之后，它引入了“同步深度思考”机制，规划能力显著提升，我们也开始将 Agent 引入金融业务的实际场景。

不过这过程中也有一个认知转变。正如我们院长白硕老师所说：数字化程度越低的场景，越容易与 AI 结合。反过来，在一些高度结构化、已通过传统软件工程（如 if-else 逻辑）构建完善的流程中，引入 AI 的空间非常有限。但对于那些数字化程度低、流程复杂、规则模糊的场景，AI 反而能大幅提升效率。

我们目前的主要应用集中在这些“长尾场景”，比如客服系统。客户的问题千变万化，无法预设流程，而 Agent 可以通过识别意图，动态响应。

当然，在某些标准化流程中，如开户等业务，我们也在尝试让 Agent 参与优化。虽然这些流程已有成熟系统支撑，但 AI 可以进一步帮助判断流程中的步骤是否有冗余，是否可以简化。例如，原本需要执行 123 和 456 两个独立步骤，AI 通过分析可能将其融合为两步完成，提高整体效率。我们相信这类流程优化将是 Agent 在金融领域的重要落点，也是我们接下来会重点投入的方向。

唐小引：能否具体举个例子说明在数字化程度较低的场景下，你们是如何通过 AI 实现突破的？

陈奕名：比较典型的还是客服场景。严格来说，不能简单认为客服“数字化做得不好”，但它的“智能化”确实存在较大短板。

很多企业已经搭建了基础的 AI 客服框架，比如用户输入后会出现推荐问题、可点击选项等，看似实现了“数字化”。但实际上，它们的对话系统内核仍较为薄弱，导致理解能力不足，响应不准确。

举个例子，我最近订票时尝试联系人工客服。我说“转人工客服”，系统却回复“好的，现在为你转接到订票服务”，完全没有理解我的意图。这种情况在传统 NLP 体系下是常见的，因为模型泛化能力有限，准确率往往只有 60% 左右。

我们通过引入基于 Agent 的大模型对话框架，能将准确率提升到 90% 左右。这种能力边界的拓展，就是我们所谓的“切入点”。相比之下，那些流程化、结构化极强的业务模块，我们反而很难找到明确的 AI 介入空间，甚至会被质疑“你到底在优化什么？”

唐小引：从 To C 的角度来看，张老师最近有哪些新的观察或趋势判断？你的团队在这一方向上又有哪些最新的实践探索？

张家瑞：虽然大家更熟悉我们 WPS Office 在 To C 场景的表现，但其实我们在 To B 方向也在持续发力。WPS 365 就是我们面向企业推出的一站式 AI 办公平台。

WPS 365 将聊天、协同办公（OA）、会议、日程、邮箱、文档等功能整合在一个平台上。一旦引入智能 Agent，办公体验可以发生质的变化。

举例来说，日程安排、邮件发送、会议预约这些任务可以由 Agent 自动完成。Agent 会先解析用户的需求、提取相关参数，再调用内部组件完成任务，实现高效自动化。这背后其实释放了巨大的效率提升潜力。

唐小引：在日常办公中很多人已经在用飞书、企业微信、钉钉等工具实现了，WPS 365 与之相比，差异在哪？

张家瑞：目前 WPS 协作的用户可能还不算多，它也提供类似的群聊、办公沟通体验。但我最大的感受是，它在与文档的打通方面做得更深入。比如在钉钉中发送文档后，如果要打印、排版，还得回到 WPS 操作。而在 WPS 协作中，聊天中分享的文档可以直接编辑、评论，甚至通过 @ 精准通知协作者。这种无缝协作体验，是我们比较突出的优势。

唐小引：对标微软 Teams，WPS 在使用习惯或场景上有何不同？

张家瑞：我身边很多朋友反馈，WPS 在文档处理和在线协作方面，功能设计更贴近国人的使用习惯。

唐小引：在企业端应用上，请分享你的一些观察和思考？

张家瑞：刚才提到企业通过 Agent 能实现任务规划与串联，我们还看到了更深层的想象空间。

随着 MCP 协议的提出，企业可以把自己的内部工具，比如出差审批、报销流程、订票系统，甚至代码审核等功能，统一接入 MCP。WPS 365 作为平台，就可以通过 MCP 协议调度这些工具，打通企业内外的系统与服务。

这样一来，不仅是我们向企业输出能力，企业也能反向将自身流程标准化、组件化，接入平台进行统一管理和调用。对企业用户而言，这带来的提效空间，甚至超过个人用户。

唐小引：金山办公已经在落地 MCP 协议了吗？

张家瑞：我们确实在积极推进这方面的工作。当前主要是在将 WPS 365 中的组件接口，逐步封装为符合 MCP 协议的标准接口。

其实在 MCP 协议正式提出之前，我们已经在内部做了很多相关探索，也做过不少 demo，支持类似的功能调用。但过去这些调用往往是单个函数级别的 function call，没有统一的协议框架。

现在 MCP 提供了一个通用的协议标准，我们内部也开始考虑是否要搭建一个 MCP 工具管理平台，方便更多组织以标准方式接入自己的工具和服务。

唐小引：也就是说，未来 WPS 也能支持部署多个 MCP server 吗？

张家瑞：目前我们主要聚焦在企业工具的接入，还没有完全走到 MCP server 的层面。但随着 Agent 架构的普及和成熟，这肯定是发展方向。

“快速部署 DeepSeek”引发的误区

唐小引：今年年初 DeepSeek-R1 发布后，很多公司一窝蜂地接入 R1。你们怎么看这种“快速上马 DeepSeek”现象？有没有看到一些误区或值得警惕的问题？

张家瑞：确实，今年年初 R1 特别热的时候，我们也感受到了某种“政治正确”的压力。很多单位，包括体制内的，也在尝试接入 R1，仿佛不接就落伍了。

但是以我在实际业务中遇到的一个典型场景为例，分享一些误区。我自己平时也经常使用 DeepSeek，给我最直观的感受是：它让人有种在“跟一个人对话”的感觉，尤其在生成文章时，无论是文笔还是语言组织都非常自然。

但如果接入的是 R1，你会发现它有一个比较明显的“Think”（同步思考）过程。但在办公场景下，并不是所有任务都需要这种深度思考。很多时候，用户的需求是非常明确且直接的：我有一个问题，你能不能尽快给我一个答案？

比如我们在 2023 年上线了一个功能叫“AI 帮你写公式”。背景是这样：表格里常用的函数大约有 420 多种，而且这些公式之间还能进行各种组合、嵌套运算，基本属于无法完全枚举的复杂体系。许多用户在学习函数时会遇到门槛，不得不去论坛、社区求助。

而我们希望解决的就是：用户不必再去问人，只需要输入一句自然语言描述，就能生成对应的表格公式。

比如：“我想根据 B 列的身份证号提取出生年月日”——这个公式其实挺复杂的，很多人写不出来，但确实是很常见的需求。

在这种场景下，用户的核心诉求是：我有一个问题，你快速给我一个能用的公式就好，甚至他不在乎公式的原理，只要结果对、能复制粘贴使用即可。而 R1 如果在这个过程中进入较长的 sync 状态，生成时间可能会达到 30~40 秒，这对办公效率来说其实是个明显的延迟。反而我们现在线上自研的模型，因为响应速度快，用户的体感更好。

但这并不意味着 R1 不适用于办公场景。我们也有一些场景，比如“数据助手”功能中涉及数据分析——需要根据自然语言生成一段 Python 代码，运行后完成数据绘图、分析并输出结论。这类任务本身就比较复杂，用户对生成时长的容忍度更高，而这时候 R1 的规划能力和准确率就能发挥出优势。

所以我的看法是：不同场景对大模型的响应速度和思考深度的要求不一样，不能一概而论，还是要具体问题具体分析。

陈奕名：今年 1 月份 DeepSeek-R1 发布时，我们注意到它是一个具备“深度思考”能力的大模型。它在回答问题时会先进行一段系统的推理过程，然后再输出最终答案。这种“慢思考”模式，其实在此之前 OpenAI 也做过类似的探索，比如 o1 模型，也是先进行推理，再给出结果。

我印象特别深的是一个具体场景，也是我职业生涯中有些“痛苦”的时刻。当时我们在做 RAG 系统，客户提出了不少挑战，我老板也对效果表示担忧——他们都觉得系统“太慢了”。那时候我们用的是自研的 72B 模型 LightGPT，虽然我们在追求准确率，但确实在响应速度上没能满足客户期望。

客户很直接地提出：“你们这个系统太慢了。”但我们团队技术上是有坚持的，我当时跟团队说：“我们不能为了快而牺牲准确率，哪怕慢一点，我们也要保证它是准的。”但现实就是，客户希望我们既快又准，这个平衡确实很难。

转折点出现在 R1 发布之后。R1 的“慢思考”虽然响应时间更长，但我们测试下来发现，它的准确率提升非常明显。可以说是上了一个台阶。

我们随即在恒生的 RAG 系统中接入了 R1，结果发现它在实际应用中的准确性确实提升显著。虽然响应时间变长了，但这一次我们面对客户时就更有信心了。我们会直接跟客户解释：“是的，速度确实慢了一些，但这是为了换取一个质的准确率飞跃。”客户看到效果之后，也确实提升了对“慢一点”的容忍度——只要答案准，他们愿意等。

当然，我们不会就此满足于“慢”。在产品设计上，我们也做了很多优化，确保用户在使用过程中不会出现“转圈圈”等卡顿体验，即便底层模型响应较慢，前端交互也依然流畅、自然。

所以从我们的角度来看，DeepSeek-R1 的出现解决了我们此前很头痛的一个关键问题。

大模型开发技术栈：到底是在进化，还是在“内卷”？

唐小引：去年大家还在热议如何用 RAG 解决大模型应用的落地问题，结果到今年，RAG 却被不少人认为是“过时技术”，讨论的焦点转向了 Agentic RAG。类似的还有 Function Calling——MCP 一出，很多人也说前者已经不够用了。时下，大模型应用开发中的关键技术真的是这样“快速更替”的吗？技术栈的演进，是否真如开发者圈子里那样被迫不断更新？有哪些新技术现在确实在大量落地？

陈奕名：其实 RAG 并没有过时，它仍然是当前大模型应用中非常关键的方案。Agentic RAG 之所以现在火，是因为它能处理更复杂的任务，在某种程度上是对 RAG 的增强。

比如说，用传统 RAG 比较恒生电子 2022 和 2023 年财报，模型一次检索上下文的能力是有限的，很难同时处理两年的数据。而引入 Agentic RAG 后，可以先独立处理 2022 年，再处理 2023 年，最后再融合结果，从而解决了传统 RAG 无法处理的复杂任务。换句话说，Agentic 是在“协助”RAG，而不是取代它。

关于 MCP 与 Function Calling，其实两者的差异并不只是接口定义。MCP 做的更重要一件事是“权限统一”。接口的统一相对容易，但权限校验就非常复杂。像恒生和金山这样的公司，各自的身份认证体系差异很大。如果没有 MCP，开发者需要分别去对接多个身份系统，非常低效。

而 MCP 的设计理念就是，所有服务端各自实现认证能力，对外则只暴露一个统一的认证接口。调用方只需接入 MCP 就能访问多方服务。这在企业级系统里是非常关键的能力。

当然，统一认证也带来了安全风险。一旦 MCP 被攻击成功，攻击者可能就能获得对所有系统的访问权限。因此 MCP 的部署是权衡场景、规模与安全性的选择。在小规模应用中，直接调用反而更灵活。

多模态发展虽有些许滞后，但是一个重要发展方向

唐小引：除了 Agent 与 MCP，近期在大模型应用开发中，还有哪些值得关注的技术变革？

张家瑞：我认为，目前仍值得持续关注的重要方向之一是多模态技术的发展。

相较于当前主流的大语言模型，多模态大模型的整体进展仍相对滞后，可能还落后半步甚至一步。在多模态模型中，各模态间的融合方式整体上仍偏浅层，尚未实现真正意义上的深度融合。

以当前主流的开源多模态模型为例，比如千问 VLM、InternVL，以及近期新发布的一些 VLM 模型，大多采用类似的结构：通过 Vision Transformer（ViT）处理图像，再将其与文本的 token 一起输入到上层的大语言模型中。这种方式虽然实现了形式上的融合，但在我看来，并未真正做到深度融合和语义对齐。

回顾大语言模型的成功，很多分析都指出其庞大的参数量使其能够储存和调取大量知识——这些知识多数被认为存在于 KV Cache 中，源自其预训练阶段摄取的大规模语料。事实上，图像同样蕴含丰富的知识，无论是文档图、自然图像还是其他形式的视觉数据。

在早期，我们使用 VGG 或 ResNet 作为视觉模型的 backbone 时，其预训练权重中其实也包含了知识。这些知识可能体现在从底层纹理信息到中高层语义特征的提取能力上。然而，如何将这种视觉知识与人类通过文本积累的海量知识体系进行有效结合，目前的多模态模型仍未给出理想的解决方案。

更进一步说，除了图文融合，我们还面临语音、视频等模态的集成挑战。因此，在我看来，多模态不仅是未来模型能力提升的重要方向，也可能是当前技术瓶颈突破的关键路径之一。

值得一提的是，像 Kimi 最近开源的多模态模型，也开始探索更复杂的结构设计。虽然它可能不是第一个，但它采用了 MoE（Mixture of Experts）架构，并在前端引入 Vision Encoder 与 Adapter Layer，再将融合后的结果输入主模型。这种尝试在结构上具备一定创新性。

然而，目前还没有团队将类似 GPT-4 或 DeepSeek-R1 这种超大规模模型应用到这样的多模态融合架构中。这说明，在模型体量、融合方式以及模态扩展等方面，仍有很大的探索空间。

因此，无论未来多模态技术是否会被其他路径替代，它本身仍将是一个极具价值的研究方向，值得持续投入与追踪。

唐小引：这确实是一个关键领域。尤其是在经历两年的大语言模型热潮后，文本处理已经较为完备，但视频等多模态仍存在很多挑战。我举个例子，我们 CSDN 是面向开发者的社区，程序员日常会使用 AI 编程工具。例如出现错误时，我会截图标注出报错位置，交给 AI 助手进行分析和 debug——这其实就是一个实用的多模态应用。在恒生和金山办公的实践中，是否也有类似多模态落地的例子？进展如何？

张家瑞：金山办公的多模态场景还是蛮多的。譬如，当我们处理一篇文档时，里面往往既有文本也有图片。如果想理解图像内容，并将其与上下文、标题、摘要等建立关联，就需要多模态能力。

又比如在文档自动生成 PPT 的场景中，如何决定插图应该落在第几页、与哪段内容关联，也要靠多模态模型来理解整体语义和视觉要素。

这些功能目前已经基本落地，正在逐步开放给部分用户体验，等到技术能力和产品形态足够成熟之后，再向更多用户开放。

陈奕名：在恒生的应用场景中，我们对多模态技术的探索主要集中在“菜单导航”这一方向。具体来说，就是希望在客户已有的系统页面上，通过多模态能力识别用户的问题或需求，并引导用户点击对应的菜单项。

目前我们主要采用的是“侵入式”的实现方式。这种方式下，我们预先知道系统中有哪些菜单项，比如“业务办理”、“个人主页”等，然后接入相应的接口，再通过 Function Call 或 Agent 调用来实现导航功能。

其实多模态的优势在于，理想状态是它可以帮助我们设计“无侵入式”的系统。也就是说，我们无需了解客户系统中具体有哪些接口，仅通过视觉识别和人类直觉来判断应该点击哪里——这与 OpenAI 提出的 Computer User 能力比较类似。

不过，现实中会遇到一些挑战。比如像张老师提到的 WPS 系统，是他们自己开发和控制的，这类场景部署会更顺利。而我们的系统往往部署在客户侧，一些菜单结构和功能入口隐藏得非常深，不容易获取。

从 AI 的角度来看，我们通常会先用人的方式去判断一个任务是否具备“可解性”——也就是说，先看看一个人能否在不事先了解系统结构的情况下完成任务。如果人都很难判断，那 AI 去做也会面临同样的挑战。

唐小引：你们的产品路线目前是不是可以概括为：先是 Agent，然后 MCP，再到多模态？

陈奕名：可以这么理解。多模态的部分我们还是在观察和评估阶段。

唐小引：为什么要观望？是产品和技术两方面都有顾虑吗？

陈奕名：目前技术能力和实际产品场景之间还存在一些差距。多模态能力在特定场景下表现不错，但在客户系统中，页面复杂性极高，算法的通用性还不足。我们判断，如果等一段时间，技术发展到更成熟的阶段，比如模型本身的通用准确率提高，我们再介入，效果可能会更好。那我们就先等一等，让子弹再飞一会儿。

另外，从产品角度来说，有些页面的结构和逻辑连我们自己都很难迅速理解，更别说 AI 去识别并引导操作。只有当我们能保证让一个完全不了解业务的人也能快速找到所需功能时，我们才认为“时机到了”。

唐小引：所以“等一等”的时间预期应该不会短，可能不会在今年落地？

陈奕名：大概率是这样的。但如果技术上突然有突破，比如某个团队推出了非常强的多模态模型，我们也可以快速跟进。

唐小引：那目前技术壁垒是决定性因素？

陈奕名：是的，技术问题更关键。

未来规划及展望

唐小引：除了 Agent 和 MCP，还有什么是你们现在已经在规划、调研或者正在推进的？

陈奕名：金融 Agent 产品，当前在研究院内部紧密研发与推进中，等待完成后会给大家展示。我们目前主推、并持续迭代更新的核心产品是 RAG。我们将它与 Agent 结合使用，以应对更复杂的问题场景。

比如，我们之前遇到一个典型案例：客户上传了一批金融相关的法律法规文档，接着提问“交叉持股要不要缴税？”。问题在于，客户上传的资料中并没有出现“交叉持股”这四个字。文档里的描述全是很平铺直叙的，只有类似“公司 A 持有公司 B，B 又持有 A 股份”的描述。

这种情况下，不论是单纯使用 RAG，还是加入 Agent 做增强检索，都很难准确匹配到答案，因为中间存在一个明显的语义 Gap。“交叉持股”其实是一种行业内的黑话，是从大量实际使用中逐渐总结出来的说法，可能只在论坛、律师口语或业内交流中出现。诸如“交叉持股”、“循环持股”这样的“黑话”是不会出现在正式的法律文件中的。

我们的解决思路，就是把这些行业黑话和术语做归纳整理，并逐步映射到实际的检索与理解系统中。因为在实际使用中，无论是业务人员还是其他用户，他们更倾向于用这种口头化、非正式的表达方式，而不是文档里那种标准表述。我相信大家日常使用时也是一样的。

唐小引：WPS 目前除了多模态和 Agent，还有其他规划吗？

张家瑞：从业务场景的角度来看，AI 应用与在实验室里做基础研究最大的区别在于：基础研究和科研通常依赖标准的 Benchmark，只要指标够好，就能发论文、实现 SOTA，成果相对直观、明确。但在真实的业务中，算法落地的挑战远远复杂，尤其是在面向客户的应用场景中，会遇到大量的“长尾问题”。这也是为什么我认为算法应用是最难的一步。

举个例子，我们曾分析用户在平台上提出的“写公式”类需求。起初，我们统计了使用频率最高的前 10 个公式，后来逐步扩展到 Top20 个、Top50 个。但即使是排名前 50 的高频公式，加起来也只覆盖了全部公式需求的约 30%。这说明，用户实际提问中有大量使用频率较低、但依然真实存在的“长尾需求”，这类需求在真实业务中非常普遍，也最难被算法全面覆盖。

尤其在办公场景中，不论是文字、演示还是表格，看似标准化的工具，用户的使用方式却高度自由。例如，有用户在文字中插入大型表格，再在表格内写大量文字；在表格中，也有团队将其作为文档工具，在单元格中写上几百字的 OKR 说明。这些非典型用法带来了极高的复杂度，要求我们的模型和系统在各种变化场景下都能稳定、精准地表现。

再细分到当前我们重点专注的 PPT 场景，其中我们使用了 RAG 技术。RAG 的门槛看似不高，许多本科生、研究生的项目都可以搭建起一个基础系统，譬如选一批财报数据、构建知识库、做 Embedding，再结合开源工具完成召回与生成。但想从“可用”的 60 分，提升到 80 分、90 分，难度非常高。RAG 系统还存在典型的“木桶效应”——从解析到召回，再到答案生成，任何一个环节出现短板，都会成为整个系统的性能瓶颈。

因此，在我们看来，算法应用的发展，一方面要持续跟进前沿技术，另一方面也要把已经成型的方案做深做透，真正解决好那些分散、复杂、琐碎但又影响体验的长尾问题。这才是 AI 应用最具挑战性、也是最有价值的部分。

大模型应用开发：需要脚踏实地，也不忘仰望星空唐小引：在大模型领域，模型层更多是在“仰望星空”，追求前沿技术的突破；而应用层则更强调“脚踏实地”，要解决实际使用中的各种痛点。这也是我们认为应用开发至关重要的原因。最后，请二位老师结合自己的实践，给大家分享一些经验、教训或建议，帮助更多开发者更好地参与大模型应用开发？张家瑞：回顾我们在 WPS 的 AI 应用实践，从早期的传统机器学习、深度学习，到如今的大模型时代，再到未来的演进，我认为一个核心始终未变：要脚踏实地，关注真实业务中的“长尾问题”，解决那些看似琐碎但真实存在的场景需求。 与此同时，我也想强调另一个同样重要的方向——保持对新技术的敏感度。在当前这个阶段，AI 的发展速度远超以往，几乎每天都有新模型、新工具、新思路涌现。如果长时间不关注最新进展，就很容易错过重要的趋势和技术机会。 我经常鼓励团队去读 DeepSeek-V3 和 DeepSeek-R1 的论文。我们并不一定要自己训练这些模型，硬件资源也有限，但更重要的是学习它们背后的工程思维。比如 DeepSeek 的出色之处，不仅体现在算法能力上，更在于其工程实现的高效性和实际问题的解决策略，这些往往是其他厂商在落地时容易忽视的。 所以我的建议是：一方面要扎实解决眼前的问题，另一方面也要持续关注行业前沿。脚踏实地的同时，不忘仰望星空。陈奕名：我非常认同张老师的观点。因为我之前也在 To C 公司工作过，深有体会：To C 的技术挑战非常大，面对的是成千上万、甚至上亿的用户，需要在体验、性能和效果之间找到一个最优解，技术要求非常高。 现在我在恒生电子，主要面向的是 To B 场景，这和 To C 是完全不同的两条路径。To B 更聚焦于垂直行业的具体需求，虽然问题本身技术难度可能没那么复杂，但业务属性更强，客户更关注结果是否“好用”、“对业务有价值”。 我一开始转向 To B 时其实有些不适应，还带着 To C 的思维方式，想把所有问题一网打尽。后来才意识到，客户不一定在意你解决的问题是不是“通用难题”，他们更在乎的是：在我的场景下，这个功能够不够准，能不能帮我把事办好。哪怕是定制化方案、哪怕与其他模块有冲突，只要能满足他们当前的业务诉求，就是好方案。所以我们团队逐渐摸索出一套合作机制：技术定方向，产品打细节。我们工程师很多时候不太了解客户真正的痛点，而产品同事离客户更近，能告诉我们哪些地方需要打磨，哪些地方不用花力气。 当然，这个过程并不总是顺利的。我们和产品几乎天天“Battle”。但也正是这种“Battle式”合作，才能真正打磨出让客户满意的产品。有时候吵得热火朝天，客户却一试就说：“你们这个怎么做得这么准？”我们听着当然高兴，但心里也清楚：其实是产品把需求抠得太准了。 所以说，没有“Battle”，就没有“好用”。如果我们技术完全听产品的，啥都不问、全盘接受，那这个项目基本就完了。

唐小引：让我想起来程序员和产品经理的不共戴天之仇。

陈奕名：对，我们是白天吵，吵完之后晚上一起吃饭。

关于《万有引力》：

这是由 CSDN &《新程序员》执行总编唐小引主理的对话栏目。技术趋势多变，一不留神总担心错过。正在发生的技术事件，对于我们开发者意味着什么？我们面临的诸多困惑从何寻找答案？《万有引力》即志在于此，直面事件与困惑，抽丝剥茧，解读技术真相。

• 栏目定位：一档面向开发者群体，聚焦解读技术事件的对话直播栏目。

• 直播观看平台：CSDN 视频号、CSDN 网站 & App

• 多形式：文章、视频、音频都会有，持续关注 CSDN 公众号都可获取。目前《万有引力》栏目已上线小宇宙平台，欢迎大家关注！

2025 全球产品经理大会

8 月 15–16 日

北京·威斯汀酒店

2025 全球产品经理大会将汇聚互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人，围绕产品设计、用户体验、增长运营、智能落地等核心议题，展开 12 大专题分享，洞察趋势、拆解路径、对话未来。

更多详情与报名，请扫码下方二维码。