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

策划 | 李忠良

编辑 | 宇琪

在数字化浪潮席卷全球的今天，AI 正以前所未有的深度和广度融入企业发展的脉络之中，成为驱动创新与增长的核心引擎。那么，如何通过 AI 技术发现新的商业与增长机会？又如何利用 AI 实现更高效的用户拉新、留存与转化呢？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请值得买科技 CTO 王云峰担任主持人，和阿里巴巴高级技术专家梁筱武、彩讯股份 AI 产研部总经理邹盼湘一起，在 AICon 全球人工智能开发与应用大会 2025 北京站即将召开之际，共同探讨企业 AI 提效实战复盘。

部分精彩观点如下：

• 如果没有幻觉，就没有创造力。我们必须接受这种跳脱，同时用工程化手段将其控制在合理范围内，才能得到我们需要的结果。

• 在所有类型的 Agent 中，数据治理始终是大模型工程的前置关键环节。

• 项目一号位必须具备将底层 AI 能力包装成用户可感知、可理解、可使用的产品功能的能力，并能与业务部门沟通、熟悉客户场景和业务流程，从中提出 AI 需求。

在 12 月 19-20 日将于北京举办的 AICon 全球人工智能开发与应用大会2025 北京站上，我们特别设置了 【 AI 驱动的提效与增长实践】 专题。该专题将探讨面向 AI 场景的技术适配与架构演进，展现 AI 如何重塑企业流程、驱动创新与增长。

查看大会日程解锁更多精彩内容：

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

当“小学生”遇上“博士生”

王云峰：我们先聊聊“模型使用”。百川的王小川总曾经有个比喻，说现在的顶尖模型（像 GPT-4、Gemini 3）智商已经达到了“博士生”水平。 但我个人的体感是：模型虽然是博士生，但我们给它搭建的工程环境、甚至我们给它写的 Prompt，可能还停留在“小学生”水平。 这种“能力错配”，导致我们经常觉得 AI 不听话。在这一年的实战中，你们在工程上是如何把这个“博士生”的能力真正用好的？有没有什么共识性的经验？

梁筱武：基于我长期从事 GUI 自动化的背景，以及现在尝试利用 AI 对 GUI 进行能力升级，我总结出三个方面的体会。

第一是要根据具体场景挑选基础模型。GUI 操作本质上更类似 RPA，它对视觉的 grounding 与推理方式，与语音或文本任务具有显著差异。因此，在基础模型的选型与组合上，我们做了大量探索，尝试过国内外多种模型，最终发现千问 3 在我们 GUI 场景中的推理效果表现较为突出。

第二是 Agent 架构的设计。AI Agent 的架构与传统微服务工程体系并不相同，它需要从不确定性逐步收敛，而不是遵循固定流程。因此，如何通过工程化手段让 AI 模型的输出在可控范围内，让这个“博士生”能够与我们的系统进行可控且有效的交互，是架构设计的核心。

在 GUI Agent 中，我们采用了引入“裁判”角色的方式，在每一步操作加入裁判判断，这是模型之外的关键机制。

王云峰：公司前段时间搞黑客松，很多同事反馈说，如果没有从头到尾完整地构建过一个 Agent，就不会真正意识到上下文工程的核心意义。我们无法把所有知识一次性塞给模型，但任务往往需要大量信息，如果上下文工程做不好，模型能力只能发挥一小部分。

邹老师，B 端客户的需求往往很死板，你们是如何通过工程手段（比如思维链 CoT），让模型既发挥“博士”的智商，又遵守“小学生”的纪律？

邹盼湘：在 B 端场景中，C 端与 B 端在 AI 应用上差异很大。先谈一个常被提到的大模型的“幻觉”问题。很多人认为幻觉是负面的，但实际上正是因为幻觉，模型才具备生成能力。如果模型毫无幻觉，它就只是背知识，无法产生新的内容。

因此，我们会根据具体场景反推是否需要幻觉。绝对消除幻觉不可能，但我们可以决定何时需要降低幻觉。在创作类场景，如视频营销面向不同用户群体时，幻觉有助于生成更具想象力与多样性的内容；但在 B 端业务场景，我们通常需要尽量降低幻觉。

可观测分为三个阶段。第一是意图理解，不同用户的问题清晰度不同，因此我们需要意图澄清过程，确保获取真实需求。澄清后进入任务规划阶段，每一步的思考过程，包括使用的知识、调用的工具等，都需要打印出来，让用户看到模型的推理路径。例如行程规划，模型需要反复询问时间、人数、交通方式、住宿偏好等信息，以确保规划符合需求。

上线前，我们通过让流程可观测、打印每一步推理过程、注入上下文等方式，使模型尽量沿着预期路径执行。上线后，AI 应用与传统 IT 应用的最大差异在于边界不明确。IT 系统的输出是可预测的，但 AI 只能做到“预估”。我们可以把上线时的水平从 60 分提升到 80 分，但永远无法达到 100 分。上线后需要不断通过迭代逐步从 80 分提升到 90、95 甚至 99 分，但依然不可能完美。

因此，我们必须通过工程化手段提前注入内容、人为干预或补充等方式，处理模型无法覆盖的部分。

AI 模型只是整个系统的一部分，而不是全部。因此，我们会增加许多配套模块和管理工具，甚至会在某些场景减少模型规模，降低其泛化能力，以提升可控性。有时我们会让模型先生成规划，再由人工校验，最终将规划转化为可控的路径搜索流程。我们在行业内做 Agent 时踩过很多坑，因此总结出 AI 落地应满足可观测、可迭代、可控、可信、可集成的要求。这些要求也反向推动交付团队与产研团队开发相应工具与工程能力，从而支撑整体落地。

王云峰：无论 C 端还是 B 端，大家最后的认知其实趋于一致：大模型的“智商”已经很高，但仅有一个高智商的大脑解决不了问题，仍然需要大量知识及工程化能力的支撑，而许多知识并不在模型本体中。因此不能期待模型一次给出最终答案，而是需要用工程化手段保证其输出可控。

模型的创造性、涌现能力来源于多样性，而多样性在今天被称为“幻觉”。如果没有幻觉，就没有创造力。我们必须接受这种跳脱，同时用工程化手段将其控制在合理范围内，才能得到我们需要的结果。

数据的“上下文”缺失

王云峰：聊完模型，咱们聊聊“数据”，这是 AI 的燃料。在值得买，我们为了让 AI 做好消费决策，必须给它看大量的用户行为和社区内容。这也是我推动 MCP（模型上下文协议） 的核心动力：我希望解决 AI 和企业私有数据之间的“上下文”连接问题。但实话说，这个过程比想象中艰难。在你们的实践中，让 AI “读懂”企业内部业务逻辑，最大的绊脚石是什么？邹老师，您在给 B 端客户交付时，是不是得花大量时间帮客户“洗数据”？如果客户的数据烂到根里了，这时候是强行上 AI，还是劝客户先把数字化重做一遍？

邹盼湘：在实际落地过程中，许多客户会提出疑问：模型已经如此强大，为什么仍然需要数据？需要什么类型的数据？又该如何开展数据治理？要回答这些问题，需要从“为什么做数据治理”谈起。

首先，模型往往无法理解企业自身的业务场景、流程和垂直领域的术语。例如，在运营商场景中，“套餐”指的是话费套餐，但如果直接询问模型“帮我定个套餐”，模型可能会理解成麦当劳或肯德基的套餐。因此，在具体业务场景中，我们必须将企业的私域知识传递给模型，使其理解特定术语的真实含义。

此外，数据治理还关系到专家经验的显性化与传递。专家经验通常体现为问题分析方法和处理流程，而模型依赖的是通用知识。如果缺乏专业知识的输入，模型无法解决许多场景化问题。

我们需要明确哪些数据需要治理，可以分为两大类：一类是知识性数据，包括专家经验、文档材料、方案内容以及结构化的分析数据等。这类数据需要显性化沉淀，通常以 PPT、Word、知识性数据可以通过两种方式与模型结合：其一是将数据纳入知识库；其二是用于模型训练。如果用于训练，需要明确模型类型（如多模态或语言模型）以及训练阶段（如 SFT、强化微调或对齐训练），相应的数据格式、数据量与处理工具也不同，需要进行清洗、去重、标注、脱敏等工作。

如果知识进入知识库，则需要考虑数据来源、类型、更新机制、冲突处理与时效性管理。治理的重点集中在解析入库、索引与召回阶段，确保知识在被检索时一致、有效且准确。

另一类数据是生产过程中的数据，包括 API 调用记录、系统日志、任务执行链路等。这类数据有时会作为模型强化学习的素材，但更多情况下，会在实时推理时作为上下文提供给模型。在此过程中必须设置严格的约束，不能将所有数据直接暴露给模型，尤其在多 Agent 环境中，数据可能被模型错误缓存并在不同代理间传递，从而造成跨权限的数据泄露风险。

例如，若财务 Agent 获取到企业财务数据并被模型缓存，而招聘 Agent 又在无权限的情况下访问到这些缓存数据，就会引发严重的安全隐患。因此，在生产数据治理中，需要重点关注账号体系、权限控制、隐私保护、数据脱敏，以及防范外部提示投毒等问题。

Agent 能否持续迭代的核心驱动力是 ROI，因此必须依赖这些上线后的数据来评估收益、定位问题是技术问题还是业务问题。此类数据治理属于上线后的持续运营工作，而非 AI ready 阶段的前置治理。

王云峰：梁老师，飞猪的 GUI Agent 是直接看屏幕的，这看起来好像绕过了“数据接口”的治理难题。这算不算是一种“逃课”？这种方式对数据的理解深度够吗？

梁筱武：在 GUI Agent 中，除了知识性数据，还有一个显著的特殊性：图形数据。GUI 的图像数据如果不准确，就会导致模型无法找到界面元素的位置。因此，图像数据的质量对 GUI Agent 的效果至关重要。

为此我们做了大量工作。例如，在提供 GUI 数据时，我们必须设计大模型能够理解的格式，这也是上下文工程的一部分。GUI 操作涉及“动作空间”，包括点击、拖拽等事件，而普通非 GUI 场景并不存在动作空间的概念。因此，我们需向模型明确这些动作的定义，使其能够正确预测下一步动作。

是“真提效”还是“更累了”？

王云峰：老板们都在喊提效，但有时候一线员工反馈是“更累了”：以前自己写代码 / 写文案，现在要给 AI 写 Prompt，写完还得复核，出了错还得背锅。在你们的项目上线后，有没有遇到过这种“越用越累”的情况？你们觉得，真正的“提效”拐点在哪里？

梁筱武：“员工是否感觉不累”，核心在于准确率。我们在构建 AI Agent 时始终要面对准确率的问题。与传统确定性的流程式工程不同，AI 是一个不断将不确定性收敛的过程。如果准确率较低，员工会缺乏信心，会觉得使用 AI 很累。以我们的 GUI Agent 为例，今年四月份准确率只有约 40%，员工很难依赖它。

而到了九月份，我们将准确率提升到 90%–95% 后，团队对 AI 的信心显著增强，也真正看到 AI 在提效上的价值。我们的 C 端业务目前已完全由 AI 接管，效率提升非常明显。

第二个感受是工程体系和工具体系对提效的影响。在构建 AI 工程时，需要配套调试工具、孵化工具、脚手架、Prompt 模板库等基础设施，让员工能够直接使用，而不用花时间处理和 AI 本身无关的技术细节，这与过去流程式架构的工具建设类似。

关于“AI 是提升效率还是让人更累”这个问题，我认为两者是并存的。首先，AI 的确显著提升了效率，包括我个人在写材料、做调研、分析、制定方案、项目管理和会议记录等方面，都大量依赖 AI 工具，效率提升非常明显。

但与此同时，我们也确实变得更累了。一方面，整个行业正处于技术转型期，我们必须持续学习新技术、拓展认知、补充知识，这本身就会带来压力。另一方面，虽然 AI 能替我们处理许多任务，但我们面对的整体工作量和复杂度也显著提高了。以往做 IT 开发，需求明确，产出可量化，周期也较为可控。

但在 AI 时代，我们需要花大量时间验证效果、解释现象、分析问题、不断探索。以前开发一个页面三天就能完成，而现在要把 AI 的准确率从 80% 提升到 95%，所需时间几乎无法预测。项目在估算成本和投入产出时的难度也比过去高得多，一旦有某个点无法突破，投入就会成倍增加，团队的压力也随之上升。

我认为这种“更累”主要出现于当前阶段。未来，随着我们对 AI 的认知逐渐清晰，业务流程被重新梳理，各类改造逐步完善，我们会逐渐进入一个更轻松的阶段。但目前我们仍处于最艰难的过渡期，大家都在寻找最优路径、沉淀工具、做好服务治理和数据治理，同时还要应对算力基础与模型本身的持续迭代。

王云峰：我想先引用一下我们在直播开场提到的一份报告，其中有些数据非常值得讨论。这是 MIT 主导的一项联合研究，主要评估当前人工智能技术能覆盖美国经济中多少劳动力任务。他们提出了一个概念，叫“Iceberg Index”（冰山指数），意指我们通常看到的只是水面上的少部分，而大部分价值都在水下。

研究结论显示，目前 AI 技术能力已可以覆盖美国经济中约 11.7% 的劳动力任务，涉及的薪资规模高达 1.2 万亿美元。但其中有一个反常识的发现：那些位于“冰山之上”的技术圈层任务，实际上只占约 2.2% 的劳动力。如果只看到这些数据，可能会得出“AI 的冲击主要集中在技术行业”的错误结论。

然而，这项研究构建了 1.3 万个技能，并与 1.3 万多个 AI 工具进行交叉匹配，最终发现：除了显而易见的编程和创意类岗位之外，大量认知型和行政型任务在技术上也已高度可自动化。这些任务并非集中在技术密集行业，而是广泛存在于金融审核、保险理赔审核、物流协调、医疗行政管理、供应链监控等领域。

这些岗位并非技术行业，但却支撑着现代经济的基础。换言之，“冰山之下”的任务规模是“冰山之上”的五倍。从这份报告得出的关键结论是：真正取代岗位的不是 AI 本身，而是“更会使用 AI 的人”。

更进一步问，随着 AI 越来越强， 那些原本做基础工作的人，他们的工作是被 AI 彻底替代了，还是被迫转型了？ 作为技术管理者，两位老师现在招人的标准变了吗？你们更看重候选人的什么能力？

梁筱武：整体来看，AI 确实在这些领域发挥了作用，但我认为岗位不会消失，而是会转变为借助 AI 完成更高效的工作。例如原来做金融科目核对的人，未来可能会基于 AI 输出结果进行更深入的分析。

从技术研发的角度看，招聘标准也会有一些变化，但总体而言，软件工程的基础能力、架构能力仍是招聘的核心，不会发生根本性变化。可能会新增一些加分项，例如具备 AI 工程相关能力、概率思维能力、效果评估能力等。与大模型交互的工程从来无法做到 100% 准确，因此如何理解概率模型、如何让模型的输出收敛到更高准确率，都会成为重要能力。同时，像基座模型效果评估、上下文工程评估等也都是加分项。

邹盼湘：我们面向 B 端，同时配置研发和交互团队，过去几年也经历了多轮阵痛，因此在人员要求上做出了较大的调整。过去从需求、方案设计、开发到测试上线，流程清晰，但现在客户往往不清楚从哪些场景切入、哪些值得做、做完需要怎样的环境以及能达到什么效果，整体预期并不明确。因此，我们将项目的“一号位”从项目经理调整为兼顾项目管理与产品设计的角色。他必须既理解业务、具备产品思维，又要懂战略规划，并掌握一定的 AI 基础技术。

我们发现很多传统项目经理难以承担 AI 项目，因为他们的工作逻辑很难转变。面对客户提出的问题，他们往往不知道如何判断需求是否合理，也缺乏对目标、时间和成本的评估意识，容易导致团队内部出现大量沟通与执行层面的内耗。

因此，我们要求项目一号位必须具备将底层 AI 能力包装成用户可感知、可理解、可使用的产品功能的能力，并能与业务部门沟通、熟悉客户场景和业务流程，从中提出 AI 需求。同时，他还需理解主流 AI 技术，特别是 RAG 和 Agent，对其原理、能力边界、适用场景及可达上限有清晰判断，以确保项目能够有序、高质量地交付。

在学习能力方面，我们要求公司全员具备 AI 能力，包括销售、解决方案、交付和研发线条。公司为各类岗位提供了 AI 培训路线、学习资料与评估指标。例如，测试人员需学习对抗性攻击、大模型评测基准、Agent 评测标准等，以补齐过去无法评价 Agent 效果的短板。

对于前端岗位，过去只需根据 UI 完成功能开发，而现在他们需要参与交互界面设计，提出创新的用户体验，包括流式响应、多模态交互、可溯源结果呈现等。在 AI 时代，许多产品界面将大幅简化，甚至可能只有一个对话框，交互在任务执行过程中实时触发。因此，前端需要思考何时呈现信息、以何种形式呈现、如何处理多任务并行等问题。

王云峰：AI 产品的开发与传统开发在范式上有明显差异，思路也完全不同。我们曾经遇到的问题是，如果研发人员缺乏强学习能力或对新事物的接受能力，无法判断 AI 的优势与局限，而继续沿用传统确定性技术的思路进行设计，往往无法胜任，甚至可能无法通过试用期。

因此，我们非常看重的一点是候选人是否真正愿意使用 AI，并且在日常中频繁使用 AI、具备一定判断力，能形成真实的体感。只有这样，在产品设计或开发过程中才能把握 AI 的特性与行为规律。其他岗位也同样如此，广泛使用 AI 对提升工作效率具有非常显著的作用。

价值与终局——算账与未来

王云峰：咱们俗一点，算算账。现在的 Token 成本、推理成本依然不低 。如果让您给企业老板一个建议：什么样的业务场景，是现在立刻、马上就应该用 AI 重构的？什么样的场景，建议“再等等”？

邹盼湘：我认为当前的核心痛点主要集中在场景选择与价值衡量。做场景选择时要避免两个极端：一是好高骛远，即在探索阶段就尝试对核心系统进行 AI 化升级；一旦出现问题，后果难以承受。二是隔靴搔痒，即选择极低频的边缘场景，虽然安全，但无法产生实际业务价值。

在场景选择上，我们采用几个评估原则。首先从业务价值出发，理想场景应具备高频、刚需和明确的付费方。其次从数据就绪度评估数字化程度、知识结构化程度及相关文档沉淀情况。理想状态下，数据已准备充分，具备 AI 升级改造的基础。

此外，还需关注容错空间，通过引入 human-in-the-loop 的人机协同模式，将错误率控制在可接受范围内。如果某个场景既无人监管，又属于核心业务，则不宜在早期触碰。

场景确定后，需要进一步评估其价值。我们通常从两方面衡量：一是总拥有成本，包括显性成本（如 GPU 等硬件投入、Token 费用）和隐性成本（如人力运维、合规与风险成本）；二是价值机会，包括效率提升、体验改善和决策优化。效率提升对应降本省人，体验改善可能带来提价或留存，决策优化有助于规避风险。当价值机会减去总拥有成本为正时，从 ROI 角度看，这个场景就值得投入。

梁筱武：目前还没有一个能适用所有行业的通用方法来判断“AI 该在哪个场景落地”。无论是 C 端、B 端、App 端还是机器人，各行业国内外都在试验，各类应用场景正处于“遍地开花”的探索阶段。我的建议是采用快速迭代方式，小规模试点、小流量验证，持续大胆尝试。

同时，企业需要具备与大模型类似的“快速反思能力”。在任何项目与产品实践中，如果发现方向不对，要能迅速纠偏并切换到新的场景继续验证。

从当前的实践来看，在“效率提升”这一方向已有大量成功案例。大模型在效率层面的优势非常明显，商业效果则因应用成本和场景不同而存在差异。在企业内部，从简单任务开始试验通常最为稳妥，例如使用数据分析类 AI 自动生成日报和周报，以替代重复性的文本整理工作，这类改造通常能取得不错的效果。

在更复杂的效果型场景，如 Agent 的探索方面，各家公司仍在不断试验，目前还很难总结出普适的套路。但我认为，可以大胆尝试，并尽量贴近大模型的思维方式，将自身产品体系与底层模型能力深度融合。当 Agent 产品与大模型在认知模式和工作方式上实现对齐后，其整体速度和迭代效率将显著提升。

观众：如何精确匹配个人对商品的需求和商品信息？

王云峰：传统搜索中，用户输入 query，系统从原始商品信息中进行匹配，再由用户判断结果是否相关。后来出现推荐算法，通过用户行为进行预测，但这也容易形成“信息茧房”，因为系统会不断强化用户过往行为，使其接收越来越同质化的信息。我们认为，如果利用 AI 对全网数据进行结构化整理，可以打破这种局限。

AI 能理解用户行为背后的真实需求。如果用户提出一个意图，我们应充分利用其相关的身份信息去推断更真实的需求。此外，商品信息往往并不完整，因此需要结合大量用户描述、社交媒体内容和公开资料，构建对商品的完整表述，以判断商品适用的场景。用户的购物需求本质上是特定场景与商品适配性的匹配，通过完善商品与场景的描述，才能更好地实现人与商品之间的精准匹配。

但现有数据质量无法完全满足这一需求，因此必须在前期进行充分的数据预处理与治理，只有把数据打好底子，后续的匹配效果才能得到保证。

观众：邹老师，您在给企业做 AI 应用落地的过程中遇到的最难环节是什么？

邹盼湘：这个问题很难回答，因为从整体架构构建、数据治理到账号权限、安全等模块都不容易。但如果一定要选最难的环节，我认为是服务治理。B 端场景不是从零构建新产品，而是要把 AI 与企业现有业务流程、业务系统和业务数据深度融合。过去我们做 IT 时，是物理世界与 IT 世界的融合；现在是 AI 与 IT 世界的融合。以我们在南网的智能问诉项目为例，过去制作数据看板和分析流程时，每一步都是人编码定义，而现在需要实时动态构建，因此必须把原有流程知识化。过去系统由人操作，现在要实现人机协同，让系统具备一定的思考能力，需要设计好人与系统共生的方式。

在企业项目中还会遇到系统数量庞大的问题。例如在线公司有十几个业务系统、超过四万个 API。如何将这些 API 转化为模型可调度的插件或 MCP 服务，并保证它们的性能、管理、注册与监控，都是服务治理中的关键难题。任何一个环节处理不好，都可能导致整体系统混乱。

观众：Agent 自主操作手机的模式会不会失控，让设备擅自行动？

梁筱武：如果 Agent 的准确率和流程控制在可确定范围内，它是不会失控的。但由于 Agent 天然具有不确定性，不可能做到 100% 准确。如果准确率是 95%，那么剩下 5% 的不确定场景就需要通过风险前置方式来处理，包括在产品流程和技术实现层面进行防护。例如，在 Agent 需要进行规划与推理时，一旦前序步骤出现错误，我们应该能够快速终止流程，从源头避免异常扩散。

我们还可以在产品端加入流程控制机制，例如“阀门式”安全措施；在技术端加入可视化链路，甚至引入第三方裁判或监督机制，对关键步骤进行实时中断。通过这些方式，可以有效规避 Agent 在不确定性场景中的风险。本质上，这是关于如何设计 AI 产品与技术体系，使那部分不可避免的不确定性得到妥善处理。