整理 | 唐小引出品 | CSDNIDCSDNnews2023 年“百模大战”进行时。几乎所有人都在做模型都在说模型是未来的核心竞争力。但大多数团队面对的现实是没钱、没卡、没资源。跟风还是基于自己的实际情况走一条不同的路这是第一个问题。然后是第二个问题。AI 团队和业务团队组成联合项目双方都很聪明都有预期但两个月过去几乎没有任何进展双方开始相互指责。每一方都觉得是对方没有准备好。这不只是协作问题更是人性问题——每个人都在等对方先迈出那一步却没有人愿意先承担理解对方的成本。还有第三个问题。一个团队为了积累 AI 经验先私下开发等上线了再说。组织提倡复用、避免重复建设但规则没有给探索留下空间探索就只能转入地下。这三个问题快手用户体验部都真实经历过。而他们也真实地走了出来——AI 客户服务落地三年按严格财务口径累计节省超过一个亿ROI1。但负责人徐欣说“要达到 ROI1 的结果需要的要求挺多。”这个“挺多”就是他这次演讲的全部内容。在 2026 奇点智能产品大会现场暌违许久的徐欣带来了他在 AI 时代的首次公开分享是他琢磨良久才定下的方向——不讲模型不讲方法论只讲他和团队真实踩过的坑以及坑背后那些更本质的东西组织、人性、规则还有认知。以下为徐欣的演讲实录大家好今天想和大家分享一些 AI 在业务落地过程中遇到的问题以及我们积累的经验。我们从三年前开始探索 AI。2022 年底到 2023 年初ChatGPT 横空出世模型能力实现了跨越式提升许多过去难以完成的事情变得可行。于是我们开始思考AI 究竟能够赋能哪些对象经过讨论和学习我们将其归纳为三类个体、团队和业务。对个体而言AI 可以拓展能力边界提升工作效率对团队而言它能够自动化大量事务性、流程性工作对业务而言则是推动整体目标实现包括降本增效和提升服务质量。因此三年前我们就开始探索如何让 AI 服务于客户服务、内部反馈、数据分析等具体场景最终推动业务目标的达成。“没钱、没卡、没资源”行业主流不一定是我们的答案当时我们面临的第一个问题是我们基本上什么也没有。2023 年整个行业都在做模型、做自研模型普遍认为模型会成为未来的核心竞争力。我们也认可这个判断但它未必适合我们所在的体验部门。因为我们没有足够的资金、算力和资源预算也相对有限。如果从模型切入即使方向正确推进难度也会很高。于是我们就在想我们到底有什么梳理下来我们发现自己有三类资产上千名一线同学包括客服、调研等职能每天数十万次的真实咨询数据以及一个完整的研发、测试、产品团队。这意味着我们具备三个闭环一线团队带来反馈闭环可以快速发现、调试和标注问题真实咨询数据带来数据闭环完整产研团队带来开发闭环。抽象来看我们的竞争力不在于基础模型本身而在于调优能力、迭代效率和业务数据。我的判断是即使模型能力能够形成壁垒投入门槛和持续成本也不是我们的优势。跟着别人进入同一条赛道实际上是在用别人的优势定义我们的路线。战略选择不能只看未来有什么价值还要看这份价值由谁更有条件拿到。因此我们选择的路线不是“先拥有一个模型再寻找用途”而是“先找到业务价值再选择足够好用的模型”。我们把路线拆成三个动作第一基于开源模型不把有限资源投入基础模型竞赛第二从高频、真实、可测量的业务场景切入第三用短周期实验严格核算 ROI只有回报大于投入才继续扩大。在场景选择上我们力争把钱花在刀刃上。例如有些业务场景用 NLP 已经可以很好解决那这部分就不上模型而有些场景判断依赖上下文NLP 识别难度较高这时大模型的上下文理解和推理能力就更有优势。ROI 的计算也非常严格。收益端我们只计算真实节省的人力和时间这部分清晰且可量化业务改善可以作为附加收益但在严苛口径下可以先不计入。成本端除了算力成本我们还会把产研人力成本全部纳入。只有这样才算得上经得起挑战的财务口径。这就是我们当时差一点踩的第一个坑也是很多传统企业会踩的坑到底应该从什么角度切入自己的业务。联合项目跑了两个月几乎没有任何进展第二个问题出现在我们真正开始试点并推动不同团队协作之后。我们先梳理了 AI 赋能的三种形式第一帮不上。这个环节的问题AI 目前解决不了。第二半自动。AI 能完成其中一部分但最终仍需要人工介入。第三全自动。这个环节可以交给 AI 独立完成但要明确要求质量不低于人工。基于这个判断我们给团队设定了优先尝试的标准高频、标准化程度高、成本收益容易衡量。我们认为在这些场景里AI 更有机会实现半自动或全自动处理。于是我们启动了第一个联合项目一边是客户服务业务团队另一边是 AI 团队包括 AI 产研和运营。起初我以为业务认知和 AI 能力结合起来应该能快速产出好结果。但到了第二个月复盘时我们发现情况并不均衡。有些线进展很好有些线却迟迟没有突破。更关键的是双方开始相互指责。AI 运营团队说“业务方应该按照我们的要求去梳理信息。我们的 Prompt 怎么写、大概结构是什么样的我们都列好了。他们应该按照要求去梳理而不应该老问我们基础的、重复的类似问题。”客户服务业务团队说“AI 团队应该多了解业务否则他们的方案和实际相差很大实际的很多东西都填不进去。”我当时意识到他们双方有一个共同的前提假设 理解成本应该由对方承担有问题那都是对方的问题。AI 团队在等的是对方给结构化的需求业务团队在等的是 AI 团队给成熟的方案让他们能往里套。这个联合项目有共同的名称却没有共同的工作方式目标、方式、要求都不一样。跨团队协作失败时先不要问谁没有配合要问理解对方的成本被分配给了谁。后来我分别和两个团队明确了责任。对 AI 团队我强调你们的价值不只是懂 AI而是同时理解 AI 和业务并主动在业务流程中找到提效位置。如果不理解业务即使业务方按格式提交信息也可能给错内容最终还是做不出好结果。对服务团队我讲了两件事第一你们一定要接受 AI一定要积极学习 AI因为这个车轮你没法阻挡它的高速发展我们都能看得见你不能装作看不到。你们要学习 AI这样以后才能从原本的一线客服有机会变成 AI 的服务运营。第二要建立判断能力。你们最了解业务现场因此要判断哪些事情可以被 AI 替代哪些不能。未来的出路要么是学习 AI 运营要么是强化 AI 暂时做不到的能力。两个团队共同的目标也被重新明确必须拿到合理的 AI 提效结果并用落地质量和节降效果来验收。我们把双方拉回到一个共同的、可验证的场景——纠纷判证项目。双方一起梳理了售后物流咨询场景通过系统分流和一些简单的规则化处理把一部分纠纷单改造成“只需要判断举证是否有效”的审核任务明确了负责人、原有效率基线和验收指标。一个月后项目取得了显著的提效结果。双方开始围绕同一条流程、同一组指标、同一个结果工作协同方式完全不一样了。到2025年底我们的AI客服已经完成落地。按照严格财务口径计算累计节降扣除成本后节省金额超过一个亿。这是这件事的一个阶段性成果。“偷着做等上线了再说”规则没有界定清楚探索就会转入地下第三个矛盾是今年才明确浮现出来的。三年前我们一直在内部强调 AI 的重要性鼓励每个岗位的同学都认真去学习 AI主动思考和探索如何把 AI 能力融入自己的日常工作。到了今年有两个变化变得非常明显。第一OpenClaw 快速火热。媒体持续跟进后大家发现 AI 能做的事情越来越多离线完成任务的能力越来越强。很多产品和研发同学也切身感受到AI 的能力已经远超他们之前的想象。第二行业里越来越多公司开始因为 AI 能力提升而进行人员优化。这两件事叠加在一起让很多同学感受到越来越大的压力。与此同时AI 也在不断模糊岗位职责的边界。比如一个没有技术背景的人现在借助 AI 工具也可以做出一个基础 MVP甚至做出可以上线、对外发布的产品。很多一线同学提出需求时不再必须依赖产品经理通过 Codex 或其他顺手的工具他们可以直接把过去需要“描述给产品、产品再找设计和研发”的事情做出来而且往往更准确、更贴近实际需求。岗位边界因此变得越来越模糊。我们内部也讨论过未来岗位可能会逐渐分成两类有技术背景的和没有技术背景的。没有技术背景的人可以借助 AI 做出简单产品复杂产品也能做出 MVP但在生产环境的稳定性、安全性以及复杂 Bug 修复上仍会遇到挑战。有技术背景的人可以解决上述生产环境的问题。且有可能达到一个人顶过去十个人、甚至几十个人的效率。在这样的背景下今年发生了一件很有代表性的事。我们有两个产研团队产研 A 团队主要做给一线服务同学用的工作台负责界面和功能产研 B 团队做的是智能客服也就是半自动或全自动的智能客服。过去这两个团队交集并不多。今年产研 A 团队想在工作台上加一些 AI Agent 的功能。内部讨论时B 团队说这个功能我们已经做好了你可以用我们的 Agent 开发框架做你们想要的 Agent直接拿去用效率高。但需求对着对着A 团队发现B 团队已有能力并不能完全满足自己的场景。于是流程就变成产品 A 向产品 B 提需求产品 B 再向研发 B 提需求研发 B 完善能力后再提供给研发 A 调用最终形成 A 团队需要的功能。这个流程听起来挺合理的。但产品 A 和研发 A 开始内耗了他们极度焦虑如果一直都是这样的合作模式那我们基于 Agent 的经验、能力、知识都得不到提升因为只要 B 团队做过的或者可能做得不完整的都由他们做我们就得不到成长。于是A 团队做了一个决定他们想要建设自己的 Agent 能力但 B 团队希望他们复用已有框架。如果只是复用他们就无法积累经验长期看会逐步失去竞争力。所以他们选择先自己做等上线后再说。这是一次真实发生的“地下探索”。而 B 团队那边感受也很不好“对方好像一直遮遮掩掩的有些需求业务都来问我们了他们还是不说对我们很防备。我们也只是想把以前做好的给他们用避免他们踩同样的坑。”我发现从哪一边来讲其实都有可以理解的部分。尤其是 A 团队他们希望通过实践获得成长这个诉求我非常理解也非常赞同。没有亲自做过经验就很难真正迭代。但他们也做了一个单方面假设只要对方已经做过我们就不被允许再做。结果是团队成员希望通过建设 Agent 生成器来积累能力这是个人成长诉求而组织层面则希望优先复用避免重复建设这是组织效率导向。两者之间缺少解释空间探索就转入地下本该更顺畅合作的团队之间反而产生了隔阂。我把这个矛盾称为个人成长诉求与组织导向之间的矛盾。我们现在的解决方式核心是厘清“重复建设”的边界。比如 Agent 开发框架这样的东西它其实是一个标准的框架任何团队都可以做、都可以尝试。但更重要的是后续治理要避免重复造轮子、重复造工具。不同团队做的东西要有规范的能力思路说明要可发现、易维护、好复用。最终我们判断可以允许 A 团队建设自己的 Agent 生成器。原因是它有通用的技术框架规范。且面向的用户不同所在的操作界面不同因此可以作为独立界面功能存在。但允许独立入口存在不等于允许它不断制造重复能力。生成出来的 Agent 和 Skill必须可发现、可维护、可复用避免让不同团队反复建设同样的业务能力。这里需要把两个层次分开入口和工具可以因为用户、场景、交互方式不同而并存底层业务能力则需要统一治理。如果我们不正面处理个人成长诉求与组织导向之间的矛盾不把规则边界讲清楚很多问题就会转入地下。真正的风险往往不是表面上的协作问题而是隐藏在背后的不信任和重复建设。小坑不断除了前面三个主要矛盾还有一些更具体、但很常见的坑。第一个是模型选择是否合理是否存在“大炮打蚊子”。这个问题在落地过程中很常见有些任务本来用轻量模型就能解决但因为团队对 AI 不够熟悉不清楚模型到底在哪个环节发挥关键作用就直接尝试 Claude、GPT或者 DeepSeek Pro 这类更强的模型。效果可能确实更好但很多时候不是因为任务本身必须用强模型而是需求没有描述清楚只能靠更强的推理能力去补足前期工作的缺口。原本一毛钱能解决的问题最后可能花了一块、十块甚至更多。在大型组织里这类情况一定会出现。因此我们需要通过审计和培训持续减少不必要的高成本调用。第二个是实际解决方案是否存在偷懒。如果需求没有厘清就直接从工程上堆方案本质上就是偷懒。这个问题不复杂但很常见也最容易被“AI 能跑起来”掩盖。第三个是多项目并行时是否还有优化空间。比如多个相似项目都需要对全量数据做模型理解和标注这时就不应该各做一遍而可以通过一次理解同时输出多类结果。Prompt 的调试和优化也非常关键。我们自己的案例里一个好的 Prompt 和一个不好的 Prompt效率差距可以超过 90%。这些坑相对更小但也更普遍。只要组织开始大规模落地 AI就可能会遇到。结语最难的往往不在 AI 本身通过过去一年的实践我们看到AI 与业务结合时不同角色有不同诉求。产研需要成长服务的用户需要质量一线团队——被 AI 影响最大的那些人——需要的可能是安全感而从组织角度要的是结果。资源错位提醒我们不要用别人的优势定义自己的路线。责任错位提醒我们联合项目必须共同承担理解成本。规则错位提醒我们技术变了组织规则也要重新解释。如果只带走三个问题我希望是第一我们是否从自己的独特资产出发第二AI落地的联合项目中谁在承担跨团队的理解成本第三避免浪费的导向是否会压制必要的探索所以我最后想说的核心观点是AI与业务结合落地最难的往往不在AI本身而在AI之外可能是组织管理可能是个人认知也可能是团队协同。模型会继续变化但这些问题不会自动消失。以上是我的分享谢谢大家。