整理 | 唐小引

出品 | CSDN（ID：CSDNnews）

2023 年，" 百模大战 " 进行时。几乎所有人都在做模型，都在说模型是未来的核心竞争力。

但大多数团队面对的现实是：没钱、没卡、没资源。

跟风，还是基于自己的实际情况走一条不同的路？这是第一个问题。

然后是第二个问题。AI 团队和业务团队组成联合项目，双方都很聪明，都有预期，但两个月过去，几乎没有任何进展，双方开始相互指责。每一方都觉得，是对方没有准备好。

这不只是协作问题，更是人性问题——每个人都在等对方先迈出那一步，却没有人愿意先承担理解对方的成本。

还有第三个问题。一个团队为了积累 AI 经验，先私下开发，等上线了再说。组织提倡复用、避免重复建设，但规则没有给探索留下空间，探索就只能转入地下。

这三个问题，快手用户体验部都真实经历过。而他们也真实地走了出来—— AI 客户服务落地三年，按严格财务口径，累计节省超过一个亿，ROI>1。

但负责人徐欣说：" 要达到   ROI>1 的结果，需要的要求挺多。"

这个 " 挺多 "，就是他这次演讲的全部内容。

在 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   之外，可能是组织管理，可能是个人认知，也可能是团队协同。

模型会继续变化，但这些问题不会自动消失。

以上是我的分享，谢谢大家。

2026 奇点智能产品大会汇聚 40+ 位一线产品技术专家与行业实践者围绕 Agent、企业级 AI、AI Coding、具身智能、AI 原生组织、行业应用落地等方向，分享了大量 AI 产品实践与落地思考。

我们将陆续整理嘉宾演讲内容，帮助大家复盘现场精彩观点。欢迎读者朋友们扫码领取大会 PPT 合集，获取一线专家的实践经验与深度洞察。