AI产品正从“模型能力”竞争转向“任务完成度”竞争。本文以PPT生成等场景为例，剖析模型选型与产品设计的核心差异，对比豆包与WorkBuddy如何将模型能力转化为用户可用的结果，揭示AI产品拉开差距的关键所在。

用户对AI说：“把这页PPT拆成两页，按主要观点重新排版。”

有的AI产品会给出两页文案；有的能直接改动原文件，并留下可以继续编辑的结果。功能表上，它们都可以写“AI生成PPT”。但对用户来说，一个只是证明模型会做，另一个真的把工作往前推了一步。

这正是AI产品开始拉开差距的地方。接入一个强模型并不难，难的是选对模型，再把它变成一款用户愿意开始、能够完成，并且下次还会继续使用的产品。

一、模型提供能力，产品围绕任务组织能力

最简单的区分是：模型提供能力，产品组织任务。

GPT系列是模型；ChatGPT和Codex是产品。模型回答的是“能做什么”：它能理解问题、生成文字、识别图片，也能编写代码。产品回答的则是“怎样让人用起来”：这项能力服务谁，放进什么场景，用户怎样开始，最后又能拿到什么。

把模型接进来，并不会自动得到一款好产品。团队还要把能力拆成一条具体的任务：用户要提供哪些材料，中间需要做几次选择，结果怎样呈现，不满意时能不能局部修改。这些决定不会改变模型本身，却会直接改变用户感受到的产品能力。

功能相同，产品也可以很不同。同样是“生成PPT”，一款产品可能只交付一段文案，另一款可以让用户在原文件里继续修改。差距不在功能名称，而在用户为了完成任务，还需要自己衔接多少步。

所以，同一类模型能力可以长成完全不同的产品。ChatGPT选择了通用对话的形态，让用户直接提问；Codex则围绕编程任务，让用户更关心项目里发生了哪些改动。它们之所以成为不同的产品，不只是因为能力不同，更是因为团队选择了不同的用户、任务和交付方式。

产品也就不是模型外面的一层包装。它要把“模型能做”变成“用户日常做得成”。

把模型和产品分开以后，团队就不该先追逐抽象意义上的“最强模型”，而应先确定产品准备为哪类任务负责，再选择最合适的模型。即使模型在评测中表现不错，也只说明它具备完成任务的条件。用户是否愿意开始、能否顺利做完，还要由产品继续回答。

二、模型选型，是一道业务题

选型和评测不是同一件事。选型要回答“用谁”；评测则提供“凭什么这么选”的证据。更稳妥的顺序，是从产品要完成的任务往回推，而不是先找一张榜单，再想办法证明榜首适合。

先定需求：把产品目标拆成可以测试的条件

“做一个办公助手”无法用来选模型。产品经理得先写清最高频的任务。它要读多长的文档？要不要处理表格？是否必须按固定格式输出？错一次又会给用户带来多大损失？评估维度要从这些场景里长出来，不是从榜单上抄几个名词。

然后，把条件分成两类。上下文长度不够、不支持所需输出格式、数据部署方式不符合要求，都可以是“不达标就淘汰”的硬需求。语言风格、推理深度和响应速度，则可以作为软需求设置权重。先淘汰不能用的，再比较谁更好。

再拉候选：先算一次任务，不只看单价

公开榜单和厂商文档适合用来缩小范围。候选模型不宜过多，而且要记录准确版本。同一个模型名字，在不同版本、接入方式和参数下，结果可能已经不是同一回事。

图1：不同模型在智能、速度和单任务成本上的排名并不一致，截图来自Artificial Analysis。

图中没有一个模型同时占据智能、速度和成本的第一名。这才是公开榜单对选型最实用的价值：它帮团队看见取舍，不是替团队宣布冠军。

成本也不能只看“每百万token多少钱”。产品真正支付的，是一次业务任务的总成本。输入、输出、重试、备用模型和其他处理环节，都要计入其中。单价低的模型如果需要反复调用，最后可能更贵；单次贵一些的模型如果能提高一次完成率，反而可能更划算。

然后实测：小样本用来找问题，正式评测才用来下结论

一开始不需要急着铺几百条数据。先用5—10个真实任务试跑，是一个实用的起点。目的是找出漏掉的维度和候选模型的明显短板，再回头修正需求。这一轮是摸底，不足以宣布谁赢了。

正式评测时，样本应尽量来自真实用户问题。如果产品还没有上线，也可以从用户访谈、现有工作材料和同类任务中整理。整个样本集既要有高频任务，也要有难例和高风险任务。标准也要写到能真正执行。“逻辑好”“回答优质”都无法稳定打分；“关键事实是否错误”“必填字段是否齐全”“输出是否还需要大量人工修改”，才更容易让不同人得出接近的判断。

标准写完后，可以先拿10—20条做试标。如果两个人对同一个结果总是打出不同的分，首先说明标准没有写清，而不是标注者“凭感觉”。格式合不合规可以做二值判断；内容质量可以分档，但每一档都要有可以对照的例子。

最后还要测稳定性。最简单的做法，是让关键样本连续跑3次，看它是不是每次都能过。对核心功能来说，3次只对2次仍然不算可靠，因为用户无法知道自己恰好会遇到哪一次。选型也不能把某一次的高分当成稳定能力。

最后下结论：推荐一个，备选一个，把风险说清

达标线和单项否决线要在评测前定，不能看完结果再临时改规则。报告也不能停在“三个模型各有优势”。产品经理应该给出一个推荐、一个备选，以及它们各自的风险和适用边界。模型分数只是证据，决策仍然要由产品团队来做。

如果没有一个模型能适合所有任务，再考虑多模型路由。但这不是默认答案。它会额外带来路由判断、结果一致性和维护成本，只有当任务差异足够大、调用规模足以支撑时，组合方案才值得做。

做完这些，团队得到的是“在当前条件下，用哪个模型最合适”。它仍然没有回答另一个问题：用户会不会在真实场景里，顺利拿到评测里的那个好结果？

三、把评测里的能力，变成用户手里的结果

评测为了比较，会故意把输入整理好，再把标准写清楚。真实用户不会替产品做好这些前置工作。他可能只说一句模糊的话，丢来一张照片，或者把资料散在不同文件里。产品要做的，是把用户模糊的需求整理成模型能够处理的任务，再把模型的输出变成用户可以继续使用的结果。

豆包和WorkBuddy都受到了市场关注，但两者服务的人群和任务并不相同。豆包是面向大众的综合AI助手，场景覆盖生活、学习和信息获取。WorkBuddy主要面向办公任务，更关心文件、表格和PPT有没有真正被处理完。

它们的用户规模不适合直接对照，值得比较的是各自怎样补上模型评测之外的那段流程。豆包首先要解决“怎样让更多人开始使用AI”；WorkBuddy则在尝试回答“怎样让AI不只给建议，还能把工作往前推一步”。

豆包先解决的，是普通人为什么要用AI

很多AI产品第一次打开都是一个空白输入框。它看起来极其简单，却把一个并不简单的问题留给了用户：我现在应该问什么？

专业用户知道怎样拆任务、补充背景和修改提问方式，普通用户往往只知道自己遇到了一件麻烦事。豆包的选择，是尽量不让用户先学习“怎样使用大模型”。它在产品介绍里很少强调参数和推理方式，而是直接告诉用户：可以查资料、讲题、规划出行、语音提问、修图，也可以生成文档和PPT。

关键不是功能有多少，而是这些能力都被翻译成了熟悉的动作。不会描述图片，就拍下来问；不想打字，就直接说；用户不需要知道“多模态”是什么，也能用一句话修改照片。实时语音和拍照识别真正降低的，是用户表达需求的成本。

产品的增长也不能离开营销和分发单独谈。2026年春节期间，多家AI产品通过红包、内容平台和集团资源大规模拉新。QuestMobile的报告显示，春节流量高峰之后，豆包的日活仍维持在1.4亿左右；到2026年6月，月活跃用户规模达到3.82亿。

图2：2026年6月月活跃用户规模TOP10 AI原生App，截图来自QuestMobile。

同一份报告中，豆包2026年6月人均使用76.7次、人均使用时长143.7分钟，两项指标同比分别增长66.1%和61.9%。月活说明多少人来过，使用次数和时长则补充了另一层信息：至少在统计期内，豆包承接的不只是一次性打开，也包含相当规模的重复使用。

图3：2026年6月AI原生App人均使用次数与人均使用时长，截图来自QuestMobile。

这些数据并不证明豆包在所有任务上效果最好，增长也不只来自产品设计。投放规模、字节的内容生态、品牌认知和分发渠道都发挥了作用。但在流量高峰过去以后，仍有大量用户继续使用，说明营销把人带到了产品面前，部分场景又把其中一部分人留了下来。

营销不等于产品能力，但它决定了产品怎样被看见。尤其是AI仍需要用户教育时，广告不只是在介绍一款产品，也在演示AI能帮人做什么。不过，下载量只代表用户曾经来过。下一次遇到问题时，他是否还会想起这个产品，才能检验价值有没有真正成立。

豆包值得产品经理学习的，不是简单复制语音、P图和PPT，而是先把一个陌生的技术翻译成普通人已经拥有的行为：说话、拍照、搜索、修改和提问。它争取的是更低的首次使用门槛，以及更多可能重复发生的日常入口。

WorkBuddy先解决的，是AI怎样把工作做完

办公用户通常已经不缺一个聊天工具。他们更常遇到的问题是：AI给了一大段建议，最后整理文件、修改表格、查资料、制作PPT和保存结果的还是自己。AI把“生成”做快了，却可能把筛选、核对和执行都留给了人。

公开报道提到，WorkBuddy的起点来自汪晟杰和早期CodeBuddy团队的一次判断。团队过去做的是编程助手，却发现不少非技术用户也在拿它查论文、整理资料和生成分析。对这些用户来说，背后是不是在写代码并不重要，重要的是最后能不能拿到一份可继续修改的文档、表格或PPT。于是，团队保留了原来“读取材料、处理文件、检查结果”的能力，把复杂的编程环境藏到后台，改造成面向办公用户的工作台。

这个决策不是给原有能力换一个名字，而是重新定义了产品要交付什么。编程助手的价值不只在于回答问题，还在于把修改真正落进项目；换到办公场景，团队也没有停在“给一段建议”，而是把交付目标改成一份可以继续编辑的文档、表格或PPT。

产品形态也跟着改变。用户不需要知道背后接了哪些模型，只需要说清想完成什么。WorkBuddy可以找到文件、完成处理，并把结果整理成可继续修改的文档、表格或PPT。用户获得的不只是一次更聪明的回答，还少了几段原本需要自己衔接的工作。

与此同时，WorkBuddy并没有追求所有事都自动完成。汪晟杰在采访中强调低门槛、安全和开箱即用。这是一个明确的取舍：AI的权限越大，能替用户做的事越多，一次出错的代价也越大。当产品开始接触本地文件、企业数据和办公系统时，哪些内容能读、哪些操作必须先确认，都会直接影响用户是否敢用。

腾讯的产品生态还让这件事更顺了一步。过去，用户要先下载腾讯文档，上传到WorkBuddy，处理后再重新保存；接入以后，WorkBuddy可以直接找到文档并处理。模型可能没有变，“修改文档”这项功能也早已存在，但用户少了搬运文件和来回切换的步骤。这正是功能之外的产品差异：它没有发明一个新需求，而是把同一件事做得更顺，把原本由用户承担的几步操作收进了产品里。

图4：WorkBuddy在同一文档中根据自然语言指令修改内容，截图来自腾讯云官方账号。

QuestMobile数据显示，WorkBuddy近三个月活跃用户规模增长115.3%。这说明办公用户对“AI替我做一部分工作”有明显兴趣，但还不能据此判断长期留存和商业化已经跑通。产品也赶上了AI办公产品的关注高峰，得到了腾讯生态流量、组织资源和市场投放的支持。增长来自一组决策和条件，不必强行归结为某一个人或某一项功能。

豆包和WorkBuddy做对的并不是同一件事。一个在扩大入口，一个在深入任务。它们的用户规模和功能清单不适合直接对照，但放回各自的任务流程，就能看到一个共同点：它们都在替用户收走原本必须亲自完成的步骤。

四、从被看见到再次使用，产品要打通一条完整路径

高日活不会由某个功能单独带来。投放、渠道和价格决定有多少人进来；只看产品内部，重复使用还要经过一条连续路径：遇到问题时想起产品，打开后容易开始，拿到可以直接使用的结果，并愿意下次再来。前一步没有发生，后一步也就无从谈起。

豆包把更多资源放在路径前端。广告、内容分发和场景演示建立产品联想，语音和拍照让用户不必先学提示词。WorkBuddy主要补后半段，把结果交回文档、表格和PPT，减少用户搬运和整理。两款产品不适合比较谁更强，却能看出它们各自选择了路径中最关键的一段。

权限确认、过程反馈和可编辑结果不应被单独归为一种“风险成本”，它们更像整条路径的安全带。过程不可控，用户可能不愿开始；结果无法修改，即使这次完成，也未必愿意再来。信任不是最后一步，而是影响每一步能否继续的条件。

对产品经理来说，这条路径首先用于定位问题。看到宣传却没有打开，可能是场景没说清；打开后迟迟没有输入，可能是入口太难；结果很少被保存、修改或分享，说明任务没有真正完成；效果不错却没有再次使用，则要继续判断场景是否低频、结果是否不稳定，或者用户下一次根本想不起产品。

因此，学习高活跃产品，不是照抄功能清单，而是学习它怎样判断用户在哪一步离开，又如何通过产品、交互、分发和交付把这一步接上。模型升级可以让结果更好，却不会自动打通路径。产品经理要决定先修哪一段，再用真实行为验证它有没有被修好。

真正好的AI产品，未必会时时提醒用户模型有多聪明。更多时候，它只是让人下一次遇到问题时愿意再来，并且更稳定地把事情做完。