不再“纸上谈兵”：大模型能力如何转化为实际业务价值

随着技术的快速发展，大模型在各行业的应用潜力日益凸显，但如何将大模型能力高效转化为实际业务价值，仍是企业面临的核心挑战。

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了 华为云 AI 应用首席架构师郑岩 担任主持人，和 蚂蚁集团高级技术专家杨浩、明略科技高级技术总监吴昊宇 一起，在 AICon 全球人工智能开发与应用大会 2025 上海站 即将召开之际，共同探讨大模型如何驱动业务提效。

部分精彩观点如下：

• 选择模型时，应重点考虑推理还是生成、上下文长度、响应性能三个方向。

• 做 AI 应用就像做工厂，虽然做的事情看似高大上，但在实际操作中，还是要在“车间”里与客户一起，逐步解决一个又一个问题。

• 理想中的 AI 智能体应该类似于生命体，它具备感知、认知和行动能力，并能够在实践中不断迭代和反馈。

在 5 月 23-24 日将于上海举办的 AICon 全球人工智能开发与应用大会 上，我们特别设置了【大模型助力业务提效实践】专题。该专题将围绕模型选型与优化、应用场景落地及效果评估等关键环节，分享行业领先企业的实战经验。

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

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

场景探索

郑岩：在探索大模型应用场景时，企业常会遇到“看起来很美但落地难”的需求，各位在实际项目中是如何判断一个场景是否值得投入的？

吴昊宇： 企业应用 AI 时，需要关注三个关键点：首先是识别最重要且值得解决的问题；其次是确保有高质量的相关数据支撑 AI 应用；第三，当效率低或解决效果差时，AI 可以作为辅助工具提升效率。

企业选择 AI 应用场景时，应遵循高频和有价值两个原则。通过识别最有价值和最频繁的问题，可以明确解决范围并合理投入资源，确保短期内看到效果。

杨浩： 财务领域 AI 应用可以分为三大类型：一是提升基础作业效率，过去在工程化阶段很难通过逐行代码写清楚审核规则，而 AI 应用后，审核场景的效果显著提升。二是风险防控，我们会根据不同指标建立模型，利用大模型分析并形成 SOP。三是创造增量价值，财务领域的司库投资场景可以通过大模型优化投资决策。

在落地具体场景时，我们关注 ROI，评估项目需求、人员和卡的投入，最终判断效果是否能覆盖投资成本。

郑岩：ROI 如果仅仅考虑人力和卡的成本，实际上投入非常大，这样是否会限制我们的场景选择呢？

杨浩： 确实会有影响。举个例子，如果我们投入两个人和两张 L20 推理卡，能够节省五个财务人员的工作量，那么我们认为投入产出是正向的。

虽然 AI 应用还不完全成熟，初期技术成本往往高于传统技术，但在财务领域，我们会根据三个分类优先评估那些高优先级的场景。

郑岩：AI 大模型带来的价值和长期发展趋势确实让我们无法忽视，但如果我们全面投入，尝试用 AI 大模型重做所有场景，成本又会非常高。因此，关键在于找到一个平衡点。

我们内部有总结一个 AI 场景识别的 checklist，称之为“AI 场景 12 问”，简单说，就是通常会从三个维度来考量：第一个维度是业务价值，也就是商业价值。我们虽然不会精准的衡量 ROI 来看这场要不要做，但是这会是一个重要的排序因素。接下来是成熟度，正如吴老师提到的业务、数据和技术的准备情况。

最后，我们还加入了一个维度：是否有持续运营的能力。因为我们通常认为 AI 应用上线后，很多时候无法达到普通员工的作业效果，还需要持续投入精力去优化和迭代。

吴昊宇： 以前在营销工作中，我们需要大量的数据支持，主要是写报告和查数据。过去，我们常用小模型，虽然成本低，但灵活性差。换个新行业看数据时，发现之前用的实体无法适应新需求，这时我们通常会依靠人力投入，进行大量人工标注。

然而，使用大模型后，情况就变得简单了。业务人员只需要定义新领域的实体词，大模型就能自动识别。这样，社交媒体洞察报告可以根据行业定制，客户需求越细致，报告就越详细。报告的速度和质量也得到了显著提升。

郑岩：在立项初期，如何向决策层证明大模型投入的性价比？各位有哪些量化的“价值锚点”可以分享？

杨浩： 在财务领域，很多问题都可以通过 ROI 来衡量。对于效率提升的场景，我们会根据单量来衡量。例如，若通过辅助工具或无人值守模式提升了效率，我们会计算这种模式能节省多少人工工时。

财务高层最关心的往往是风险控制，而非纯粹的效率提升。在这种情况下，我们首先衡量场景的风险敞口，并评估引入大模型后能够覆盖的风险防控比例。

对于增量价值的创造部分，比如智能资金调拨、结构性存款和量化投资等，这些可以直接为公司带来实际的资金增值，能够明确计算出为公司赚了多少钱。

此外，像税务规划等场景，也能通过大模型收集数据，支持相关决策。这些场景的收益可以明确衡量，无论是减少风险敞口还是提升人效，投入的成本都能得到初步估算。如果 ROI 不为负，通常老板会愿意进行投资。

郑岩： 风险是怎么估算的？

杨浩： 通常通过扫描风险敞口，来确定能够管控的风险比例。比如审核流程中，财务有时会盲目审核一些采购单或报账单，这些单据可能存在巨大的风险敞口，特别是单笔金额上亿的情况下。使用大模型审核时，我们会逐个审核这些环节，并通过模型管控相应的风险比例。

郑岩： 最终还是需要人工核查吧？

杨浩： 当大模型的准确率足够高并且稳定时，某些场景我们已经能够实现无人值守。

吴昊宇： 在我们做营销时，很多时候并不是单纯关注钱的问题。我们对接了许多跨国公司，在这些公司里，中国区更加注重创新，如果实现了一个好的 AI 应用，它可能成为总部认可的机会，从而在总部获得更大的支持。

我们与一家医药客户合作，帮助他们的内部咨询部门关注一线人员的满意度。这个医药公司有大量的业务代表需要与医生接触，但因为医学专业性强，一线代表往往不敢直接提问，特别是担心问得多了会被视为不专业。

因此，我们帮助他们创建了一个基于知识库的应用，除了查询功能外，还包括内部培训和考试。经过这一套培训和练习后，他们的一线代表开始变得更加自信，敢于与医生沟通，见面的频率也有所增加，这对他们的销售工作帮助巨大。

技术落地

郑岩：在选择大模型技术路线时，不同业务场景对模型能力的侧重点可能完全不同，能否结合各位的实践，分享一下技术选型时的优先级考量？在改造传统系统时，各位是选择“颠覆重构”还是“渐进升级”？

杨浩： 不同版本的模型适用于不同的需求。选择模型时，我们主要考虑三个因素：首先，场景的重点是侧重推理还是生成；其次，上下文的长度，一些场景需要处理长上下文，而其他场景可能只需要短上下文；最后，响应性能。在某些场景中，高性能响应是必须的，特别是深度思考的模型常常响应迟缓，可能需要几秒到几分钟才开始返回结果，这在某些应用中是不可接受的。

另外，关于选择颠覆重构还是渐进升级，也需根据具体场景分析。AI 应用有三种范式：AI Embedding、AI Copilot 和 AI Agent。其中，前两者偏向渐进升级，AI Agent 则偏向颠覆重构。

尤其是在财务领域，第三种模式（AI Agent）占据了大部分比重，可能超过 50%。从 2023 年下半年开始，我们先进行了一些 AI 嵌入的工作，将 AI 能力融入现有财务体系中。

用户并未感知到这是 AI 应用，只是看到了自动化的流程。比如在界面的右下角弹出一个机器人，用户可以与其交互进行智能分析、审核等任务。对于 AI Agent，我们正在定义数字员工，实际上是在重新构建整个财务系统的入口，这属于颠覆重构的方式。

郑岩： 财务体系相对其他业务领域，数字化成熟度是比较高的。如何在如此成熟的数字化体系中，深度采用 AI 且以超过 50% 的比例进行重构，如何确保业务能够适应这些变化？

杨浩： 财务领域确实有很多子领域，每个子领域基本上都有后台管理系统。在新的 AI Agent 模式下，我们设计了一个 AI Native 的财务体系，提供统一的入口，后端连接各个子系统，并且这些不同领域的 Agent 通过协议进行通信。

从业务角度来看，用户不再关注各个系统的功能，而是关注自己的业务需求。我们内部提出的口号是“从做功能到做服务”，举例来说，报销和报账是每个公司都会涉及的内容。

传统的系统需要用户手动处理提单、审核结算等复杂流程，而现在我们的系统只需要用户简洁地输入一句话，比如“我要报一个账”，并上传发票，后续的提单和审核等流程系统会自动完成，这是对用户体验的一次重要变革。

吴昊宇：对于营销类客户，他们更加关注模型是否能够从多样化的材料中挖掘出相关信息。例如，若客户查询草莓相关内容，但历史报告只包含蓝莓数据，严格排除蓝莓内容可能导致无法提供有用信息。

因此，模型需要具备一定的灵活性。而对于医疗客户，他们对准确性、引用的精确性以及可解释性要求非常高。在这种情况下，模型必须严格按照原文回答，不能自行生成或引用其他知识。

在推理模型的应用中，处理报告和问答时，我们首先进行发散性推理，探索用户可能的需求和相关问题，但在回答时，必须确保模型的高准确性，避免过多的推理。这些差异决定了模型选择时需要根据客户需求进行权衡。

在传统系统的改造过程中，我们逐步升级。例如，在页面上添加类似 Copilot 的插件，用户可以通过该插件直接进行问答或操作。同时，我们将一些传统的判断逻辑转交给大模型处理，特别是在涉及关键节点的场景。

过去，这些节点依赖代码规则或小模型判断，而现在，大模型可以更好地利用工作流上下文，从而提供更准确的结论。虽然界面变化不大，但系统架构已发生显著变化。

郑岩： 我们在实际选型和采用各种模型时，还会考虑到一个问题：我们不希望模型的种类过于发散。技术团队若要熟悉多种不同模型的能力、风格、架构和部署方法，成本会相当高。

因此，在进行 POC（概念验证）或原型验证时，我们可以适度发散，但在生产环境中，我们更倾向于收敛。

郑岩：从 Open AI 提供 Agent 架构之后，大家都在 Agent 都有创新，在大家各自的领域，Agent 架构有哪些创新？或者实践？

杨浩： 我们自己定义了一套 Agent 体系，并将其分为四个主要部分：感知、决策、执行和反馈。

感知分为主动感知和被动感知。被动感知比较简单，就是用户通过对话给我们的信息。主动感知则是我们在企业内部应用中，通过感知用户的角色、岗位、权限和任务等，来为用户打标签并进行画像。

系统会根据这些信息推荐相关的任务和操作。决策部分涉及到存储和各种决策模型，决策模型帮助 Agent 决定要做什么以及如何做。执行部分则涉及各种工具的调用，比如 API、SQL 等，Agent 通过调度这些工具来完成任务。

我们在反馈链路方面进行了创新。例如，用户遇到问题并认为大模型的回答有误，但如果不做调整，下次用户再问相同问题时，大模型可能仍无法给出正确答案。

为了解决这一问题，我们构建了一个反馈链路，让用户可以格式化地反馈问题，指出模型在某些场景中的不足之处。

我们将这些反馈信息整理成学习知识库，并通过动态调整来优化模型性能。通过这一动态反馈机制，Agent 能够不断学习，逐步提升模型的能力。

郑岩： 可以举一些动态反馈的例子吗？

杨浩： 在智能审核场景中，我们关注每个审核点，如核对税率是否与合同一致。若从合同提取的税率错误，用户可结构化反馈，系统自动生成反馈内容。

收到反馈后，我们会人工确认其质量，确保数据准确无误，再将其加入知识库并定期更新。更新后的模型用于评测历史数据，若准确率提升，经过灰度测试后正式投入使用。最终，模型能像人一样理解并响应反馈，达到智能优化的效果。

郑岩： 不仅让大模型能“听懂人话”，还能让用户参与到大模型的持续演进过程中，形成一个非常有价值的循环。

杨浩： 关键在于让业务方真正成为大模型应用的“老师”。

郑岩： 这真的就变成了“AI 训练师”——用户在不断地帮助 AI 进行训练。

吴昊宇： 在我们的内容营销系统中，我们倾向于将整个系统看作一个 AI Agent，最终目标是实现内容生产的全自动化。我们将内容营销 Agent 分为三个部分：感知、认知和行动。

感知系统方面，我们需要了解市场上发生了什么，避免盲目做内容。在做营销之前要“五看”：看趋势、看行业、看目标人群、看竞品和本品。这些信息都依赖于我们的“魔方 Pro”系统来收集，它能从市场中提取相关信息，作为内容创作的基础，决定创作方向。

认知系统方面，我们基于明敬超图多模态大模型创造了一个通过模拟人的主观感受来评估内容的系统。这个系统能够从不同年龄层或性别的人群角度出发，通过模型模拟他们的反应。通过这种方式，我们可以提前预判广告的受众反应，避免不必要的内容测试，减少成本，提高 ROI。

行动系统则关注广告内容的自动化生产，以及如何与人工合作进行内容创作。广告投放后，需要通过收集数据进行迭代反馈，确保广告的 ROI 持续提升。如果某个广告效果好，我们可以加大投入，进行加热推送，让其表现更佳。

整体来说，我们的反馈和行动系统核心在于内容的迭代和反馈，通过这个过程使营销活动实现自动化。我们的最终目标是将整个营销过程——从感知、认知到行动——整合为一个连贯的系统。在不需要太多人力干预的情况下，广告商能把内容交给 AI Agent，放心地期待回报。

郑岩：MCP 非常火热，不同的技术栈应用如何快速支持，以及是否决定支持？

吴昊宇：MCP 在开发全新 AI 应用时非常有用，但对于一些相对成熟、流程固定的产品，MCP 的优势不如传统技术明显，甚至在某些情况下还不够成熟。

所以，对于旧产品，我们根据现有情况进行测试和选择；而对于新产品，我们更多地进行适配。之前，我们调用内部工具时通常使用函数调用的方式，将所有内容写成一个非常长的 prompt，交给大模型来调度。现在，我们搭建了 MCP Server，各团队接入时操作变得更加简便。

尽管如此，在新的 AI 应用中，我们也发现 MCP 的变动非常大。因此，目前我们还是在有限制地使用 MCP，并且希望 MCP 协议能够尽快成熟，以便我们可以更加放心地使用它。

杨浩： 蚂蚁内部 MCP 的应用比较激进。举个例子，像支付宝的支付 API，现在可以通过 MCP 的方式结合，直接在 Agent 中完成支付操作，这在支付领域的应用非常前卫。我们在 AI 应用进程中，作为客户端去调用蚂蚁内部的各种服务，这部分使用较多。

另外，针对一些财务领域的老旧系统，很多是基于 Java 架构的，我们在这些小众场景中尝试将 MCP 应用进行试点。为了支持 MCP，我们会在一些小众场景中，通过 Server list 等模块来支持 MCP 的应用。所以，作为消费者，我们更多的是调用蚂蚁内部的 MCP 服务器。

前两年大家专注于模型的研发和提升，而最近，MCP 开始引起关注。可以看出，大家已经从单纯的卷模型转向卷应用。MCP 作为一个标准化的通信协议，解决了通信协议这一层的工程化问题，它不是模型层的创新。

郑岩：从实验室效果到生产环境稳定表现，各位是如何实现的？能否揭秘关键评测环节的设计思考？

吴昊宇：POC 阶段大家认为一切顺利，但只有真正进入生产并面向客户时，才发现实际上工作才刚刚开始。面对不确定性系统，最重要的就是多测试。测试不仅是覆盖多个场景、领域和行业，还要反复进行，而不是一次性测试完就结束。

举个例子，在与客户一起上线知识库系统时，需要不断测试其材料，客户提了意见后，我们要去验证解决方案。有时甚至需要人工与客户一起整理资料，因为客户提供的资料质量可能很差，我们需要与客户合作，提升资料质量，从而提高最终的问答质量。

当然，客户会有基本的预期，期望在经过一定的测试和优化后，达到预定效果。你不可能一直修改下去，因此要设定好标准，并与客户不断磨合。做 AI 应用就像做工厂，虽然做的事情看似高大上，但在实际操作中，还是要在“车间”里与客户一起，逐步解决一个又一个问题。

郑岩： 在交付给客户时，您是否会和客户约定一个准确率的承诺指标，或者其他类似的标准？

吴昊宇： 准确率的承诺指标通常建立在数据集基础上。客户会提供他们日常问答中常见的问题和问题类型，我们会根据这些问题，进行优化，力争解决 90% 的日常问题。达到了这个目标后，就可以交付了。

郑岩： 像 AI 大模型这种技术我们无法做到“零 BUG”，这意味着可靠性评估最终还是要依赖评测集。但设计评测集的方式会影响指标的表现，所以，业界的各种评测集也在不断迭代和优化。

吴昊宇： 客户关注的不是你给出的评测指标，而是从他们日常应用或者业务价值出发。因此，每个客户的评测集都可能不同，包括文档范围、内容，甚至他们想问的问题类型都有差异。所以，评测集的设计和应用确实是因客户而异的。

杨浩： 在做模型时，大家常听到“数据决定效果”，这条规则仍然适用于确保应用的稳定性。在 POC 阶段，效果可能很好，但在线上面对更多不可控因素时，问题就暴露出来了，本质上是因为数据集不够全面。

那么，如何解决？在实践中，首先，我们会根据场景设置详细的指标体系。例如，在审核场景中，我们会针对不同的审核要素、审核点和审核单据等维度，设计精确度、召回率、准确率等指标。

第二，在上线过程中，我们采取了两种模式。最初，我们并没有完全用 AI 替代人工，而是将其作为辅助审核，最终决策依赖人工。在这个阶段，我们与业务方密切合作，每周分析所有错误案例，持续优化模型。

上线初期，审核场景的准确率仅为 20%，几乎无法使用。经过三个月的调优，准确率提高到 90% 以上，在审核要点维度上达到了四个 9 的准确率。

财务领域对准确性要求极高，因此，我们首先采用辅助审核模式，不断对齐和调整，确保准确性。当某个场景的准确率足够高时，比如单一类目下审核的准确率在三个月内持续保持 100%，我们才会将该场景转为无人值守，AI 自动替代人工审核。但这并不意味着人完全不参与。

我们设有后续检查流程，定期抽检 AI 审核的单据。如果 AI 审核错误，系统会回退到辅助模式。这种流程提供了容错空间，也允许我们逐步过渡到完全无人值守的模式。

郑岩： 从 20% 到 90% 准确率的提升过程中，最有效的措施是什么？

杨浩： 首先，我们设计了非常详细的指标体系，通过这些指标，我们可以反推每个案例的问题所在。针对这些问题，我们与业务方一起逐一对齐。我们将人工经验注入到模型应用中，这是一个非常复杂的过程。

郑岩： 您是通过 Prompt 工程还是通过训练将人工经验对齐到模型中？

杨浩： 我们先通过工程化的方式将场景做到一定程度，然后再利用高质量的数据集进行训练，最终将这些经验融入到模型中。

观众：怎么看待 A to A?

杨浩：MCP 解决的是人与技能之间的问题，而 A to A 则是解决人与人之间的问题。在财务领域会涉及一些场景，比如在接入新的业务时，需要评估如何进行核算、税率是多少、是否为关联交易等，这些场景通常需要不同领域的 Agent 之间进行沟通和反复协作，但目前我们还没有通过 A To A 实现 Agent 间的直接沟通，更多的还是在使用 MCP。

吴昊宇：A to A 其实是多 Agent 之间相互沟通的方式，这种方式会带来更多的不确定性。不过，我相信当 Agent 系统足够丰富或复杂时，Agent 之间如何互动将会是行业未来的研究重点。

但现在，我们的首要任务是先确保单一 Agent 的功能完善，确保它能够充分发挥自己的技能，再考虑如何实现 A to A 的交互。

观众：幻觉问题如何解决？

吴昊宇： 在做知识库的过程中，我们发现幻觉问题很多时候是因为大模型在自由发挥。解决这个问题的方法就是不断调整 Prompt，确保大模型按规定执行。比如，如果你发现它常常举一些不存在的例子，就需要在 Prompt 中明确禁止它举例，只允许引用原文。另一个常见问题是某些模型喜欢合并同类项，有时合并错误。在这种情况下，你需要提示模型不要合并同类项，而是直接按原文回答。

郑岩： 企业内部的很多“黑话”和术语，是导致幻觉问题的一个常见原因。比如说“胶片”，很多人都不理解这个是什么意思，而大模型更理解不了，其实是指 PPT。

我们所处的行业技术性较强，缩写使用频繁，很多时候我们需要帮助大模型理解这些缩写和术语，来消解它们的歧义。整体来说，随着技术的进步，大模型的幻觉问题从指标上来看已经越来越少了。

观众：提示词和模型微调是否能达到四个 9 的准确率？

杨浩： 提示词与提示词之间有很大的差异，编写一个好的提示词并不简单。我们针对特定任务流程编写了一套非常严格的专家框架，类似于 SOP。

在执行任务时，模型需要按照我们的要求一步步执行，而且每一步之间可能还存在依赖关系。因此，准确率的评估需要根据不同的场景来进行，不能一概而论。

未来展望

郑岩：现在优秀的 AI 大模型层出不穷，企业 AI 应用如何应对？当大家都在谈 AI Native 时，各位心中理想的“智能体”应该具备哪些特质？当前距离这个目标还有多远？

吴昊宇： 理想中的 AI 智能体应该类似于生命体，它具备感知、认知和行动能力，并能够在实践中不断迭代和反馈。

此外，智能体应该具备学习能力。现在我们的模型进化依赖大量算力进行训练，但生命体的学习速度远快于此。未来理想的智能体应该能够通过少量样本或某种学习方式快速进化，而不是像现在这样从零开始重新训练。

杨浩： 企业应对大模型发展的方式可从模型和应用两个视角探讨。底层大模型训练方面，企业需快速掌握模型架构、训练方法和优化算法，特别是奖励函数设计，关注技术深度。

应用层面，核心是快速接入、评估、部署新模型，并利用其特性。替换底层模型时，必须确保新模型准确率优于现有模型，否则会影响业务。

虽然理想的智能体可自我演化，但现实中模型的智能是有限的。评估智能体时，应关注设计、数据、领域知识和动态性。AI Native 应用设计不同于传统 GOI，需设计合适的卡片、工作流程和图谱，复杂任务执行图与传统设计有很大不同。

企业要深入了解和掌握内部数据，确保模型能够理解和处理数据。领域知识对专家系统至关重要，尤其是在财务领域，了解会计、税法等知识。模型应具备动态性，根据人类反馈自我学习。

郑岩： 大模型发展确实非常非常快，配得上“日新月异”，因此在变化背后，我们就更需要抓住大模型的发展过程哪些是不变的。我之前简单总结过，称为“五更”，分别是：更强、更便宜、更快、更长（的上下文）和更多模态，这些趋势基本上在最近三年一直保持着。

从 AI 工程和应用的角度来看，我们要尽可能避开这些大模型的主航道，不要在大模型快速发展的过程中“绣花”。毕竟，升级一个版本后，可能会发现你费尽心力改进的几个百分点，随着更强的基模型发布，直接就可以带来几十个点的增益，之前的投入就白费了。

另外，我认为有一个问题很多同行没有被重视，就是评测。很多人认为评测很基础、低级，认为做大量的评测用例好像没什么意义。但实际上，评测是 AI 能够持续落地的关键。

如果测试集足够好，它就能够足够好地还原业务本质。如果评测工程做的足够好，就能够以更快的速度迭代 AI 应用。在这个基础上，再去优化 AI，才能有的放矢。如果评测的方向错了或偏了，那很多努力就会浪费。

郑岩：在组织能力建设方面，各位观察到哪些新型岗位正在崛起？传统团队需要补充哪些“超能力”？

杨浩： 第一个岗位是“企业知识管理师”，AI 应用依然遵循“有多少数据就有多少智能”的原则。因此，企业内部的应用需要有高质量的数据，知识越丰富，数字员工才有可能变得真正智能。

另外，很多互联网公司实际上没有完善的知识库，尤其是在业务快速发展的情况下，知识库往往是后置的。

接着，传统团队需要补充哪些超能力呢？比如我们这样的工程型团队，可能涉及的角色包括前端工程师、后端工程师、算法工程师、数据工程师、质量工程师等。前端工程师以前主要做一些传统的 GUI 应用，比如有堆叠的导航栏和输入框。

但在 AI 浪潮下，前端技术架构需要进行升级，不能再依赖传统的框架。后端工程师过去主要以 Java 为代表的技术栈为主，使用分布式系统的架构。而现在，AI 应用更多依赖 Python 技术栈，框架可能会转向使用 LangChain 等新的工具。算法工程师以前做的多是机器学习、深度学习的小模型，而现在则是大模型，尤其是 transformer 模型，训练方法完全不同。

数据工程师过去可能更多使用 SQL 来处理数据，现在则需要做逻辑建模、指标工程，构建符合自然语言交互的数据集市。质量工程师过去测试主要关注功能验证，而现在的核心任务是构建评测集，提升场景中的准确率、召回率和精确率等指标。核心是要加强这些技能的补充。

吴昊宇： 首先，大家需要理解 AI 能够做什么，不能做什么，这个是通过不断使用 AI 来摸索和理解的过程。例如，写代码的同事需要知道如何通过 AI 代码编辑器生成代码，并理解 AI 写出来的代码能满足什么样的需求。他们需要与 AI 编辑器不断交互，摸索出最适合的工作流程。

第二点是，AI 在日常工作中的作用。比如我们团队的成员现在基本上都用 AI 来写 PPT，这种方式在 PPT 制作上已经发生了巨大的变化。甚至在写产品文档时，AI 也在帮助我们完成这些任务。

最后，就是对于 AI Native 产品的理解能力。如何将这些充满不确定性的内容展示给客户，使其看起来具有确定性。这不仅是产品设计的问题，也需要研发团队的同事去思考：如何确保产出的内容能够最大程度地控制不确定性，并在此基础上提供一个可交付的效果？这也是我们在工作中不断摸索和积累出的能力。

活动推荐

AICon 2025 强势来袭，5 月上海站、6 月北京站，双城联动，全览 AI 技术前沿和行业落地。大会聚焦技术与应用深度融合，汇聚 AI Agent、多模态、场景应用、大模型架构创新、智能数据基建、AI 产品设计和出海策略等话题。即刻扫码购票，一同探索 AI 应用边界！！