从发现异常到验证结果，产品经理该把什么交给 Agent？

产品上线越来越快，维护、洞察和运营却未必同步变快。嘉宾通过结合三个客户案例，讲述如何让 AI 参与异常修复、指标归因和精细化运营，把报表连接到行动与结果；以及产品经理必须保留的三项判断：定义问题、选择可信数据、验收用户价值。

在 2026 AI 产品大会现场，友盟+冯成蹊老师做了《从看报表到跑闭环：Al Agent 驱动的 APP增长新范式》的演讲，老师从他十多年服务开发者和数据产品的经验出发，讨论的不是再做一张更智能的报表，而是把数据决策真正接入开发者的业务流程。他用三个客户案例拆解 AI 如何扩大产品团队的服务、洞察和执行半径，也反复强调：Agent 可以持续执行，但问题、证据和用户结果仍然要由人负责。

以下内容根据现场音频和演示材料整理，Enjoy：

一、产品做得更快，三个问题反而更重要

我在友盟+工作了十多年。过去我们更多给开发者提供数据统计、报表和智能决策能力。到了 AI 时代，我更关心的是，怎样把数据决策融入真实业务，形成一个能够持续运行的闭环。

现在借助 Agent，做出一个产品会越来越容易。但上线变快，并不等于产品经营变简单。相反，三个问题会更重要：产品上线后，客户遇到问题时，我们能不能服务得更快、更稳；数据发生变化时，我们能不能找到背后的原因；知道原因之后，我们能不能把运营动作执行到具体用户，并看到结果。

我今天不打算讲一个很大的方法论，而是讲三个合作伙伴的案例。它们分别对应服务、洞察和行动。过去因为人手、专业分工和排期覆盖不到的小问题，可能永远留在报表底下；如果把数据、分析和执行连起来，AI 有机会把这些问题纳入日常经营。

二、一个影响人数不多的无响应，为什么仍然值得马上处理

第一个客户团队不大，做了一款面向海外市场的测试类应用。具体名称在现场没有展开，我只讲它遇到的问题。这个团队用 Web Coding 很快完成开发，国内上线时会面对不少限制，转到海外后开始在不同设备、网络和用户环境中验证。开发快是优势，但上线以后，真实环境里的问题也更容易暴露。

他们在 5 月 24 日左右通过 APM 性能统计分析发现过无响应问题，第二天做了修复。之后产品在 6、7 月逐步投放到不同地域，到了 8 月，同一类无响应又反复出现。对这个团队来说，这不是唯一一款应用，也不是全公司会优先投入的重点产品。问题被记录下来，却未必排得进工程团队的近期排期。

从普通缺陷列表看，这个问题影响人数并不多。PPT 第 6 页记录了 812 次启动、428 名活跃用户、5 次 ANR，影响 4 名用户；音频中还按当时活跃用户口径提到约 1% 的影响。产品经理还要面对其他崩溃和高影响问题，它自然不一定排到最前面。

但沿着用户行为链路看，问题的业务含义完全不同。这 4 名用户进入应用后，在主流程提问和调用 AI 的前十秒就出现卡顿，后台不再响应，用户随后退出应用，而且没有再回来。它不是一个边角异常，而是新用户还没走完关键流程就流失。如果只看影响人数，问题会被推迟；如果看主链路，优先级就应该上调。

过去，排查这类问题要由工程团队提取日志、还原环境、定位代码、修改、编译、验证和发布。少则半天，多则三到五天。不是每一步都很难，而是每一步都要有人接手，影响人数少的问题很容易在排期中被推后。产品经理通常每天看新增、活跃、留存和使用时长这些大指标，却没有精力把每个异常底下的小问题都追完。

我们尝试把原来的链路重新连接起来。首先由产品线识别异常，给出它可能涉及的设备、网络和调用信息；接着把用户轨迹加入分析：用户什么时候进入、点击了什么、卡在哪里、服务端调用走到哪一步。过去这类轨迹只是一段数据，现在把它整理成 Agent 可以调用的 Skill，完整交给开发环境。

Agent 结合代码、用户轨迹和服务端调用去判断问题位置，给出修复方案；在开发环境中完成修改和编译验证，再把修复结果交回原有工程流程。最后仍然由产品经理或技术负责人判断方案是否合理、是否合并，以及上线以后用什么指标验收。我们不是把审批也交给模型，而是把人从重复搬运信息中解放出来。

在另一种实现方式里，可以直接调用开发环境智能 IDE 的底层能力，把用户路径和开发环境的异常交给它定位，再把通过编译的代码合并回原有分支。这个过程让从定位到修复的时间缩短到约五分钟。五分钟是我们测试时从发现问题、定位、修改到编译验证的口径，合并和正式发布仍然要按客户的工程流程执行。

这条链路跑通后，线上新增的边角数据、异常和 ANR 可以自动沉淀，后续同类问题不必再由产品经理每天盯着列表判断。AI 扩大的首先是服务半径：以前团队只能优先照顾最严重、影响面最大的故障；现在，一些影响人数暂时不多、却直接阻断关键流程的问题，也有机会得到及时处理。产品、运营和技术的边界会变得模糊，但人仍要定义哪些问题值得服务，以及最终以什么用户结果判断它被解决了。

三、报表告诉我下降了，AI要继续找到原因

第二个客户是一款垂直的海钓类应用。某次 DAU 连续三四天异常下降，幅度大约 30%。运营团队排查了两三天：确认指标口径，检查内部发版、渠道、运营活动、数据质量和季节波动，也看了行业趋势，仍然没有找到原因，最后甚至怀疑是不是统计后台出了问题。

传统报表能告诉我们指标变化，却不能直接回答变化由什么引起。排查时要先确认 DAU 到底怎么定义，新用户、活跃用户和变化区间的口径有没有改变；然后检查版本、渠道投放、流量质量、运营活动、APP 或小程序是否出现不可控变化，再看这种下降是不是阶段性、季节性或周期性。如果整个行业都在下降，结论又会不同。

我们先沿着这条常规排查链路走了一遍。内部发版、渠道和活动没有明显异常，数据采集也没有发现同一时间的系统性问题，行业趋势同样没有解释这次波动。排查到这里，问题不应停在暂时不知道，而要继续把用户地域和外部环境放到一起看。

AI 在这里适合做的，是快速遍历这些可能性。我们把用户分布、海钓行业数据以及沿海地区的天气、潮汐等数据接入，让系统在波动时间段内寻找外部新闻和环境变化，再把这些结果与 DAU 曲线对齐。它不是直接宣布一个原因，而是把原来需要人一点点搜索和比对的可能性先收集出来。

当时的数据收敛到少数沿海区域，这些区域出现了影响出海活动的天气预警。预警规模没有达到台风级别，在全国总量里不显眼，但区域用户的下降趋势与天气变化能够对应。我们再把天气、潮汐、行业新闻的时间节点和内部 DAU 的变化连起来，发现外部情况过去后，DAU 也恢复了。

这次 AI 生成的报告只有四五百字，却包含了排查路径、内部数据、外部新闻链接、时间节点，以及受影响区域的用户占比。报告短不是因为问题简单，而是系统先把无关路径排除了，把剩下的证据集中到一个可以继续判断的结果上。

从人工排查三天，到 AI 大约五分钟定位主要影响因素，这个结果并不意味着 AI 可以替产品经理宣布原因。它能完成事实收集和初步解释，也能给出每个可能性的依据和置信程度，但产品经理仍要判断证据是否足够、数据来源是否可信，以及接下来应该行动还是继续观察。

我把这条闭环拆成四步。第一是事实：我们真正观察到了什么。第二是解释：哪些证据指向同一个主要原因。第三是动作：当前证据是否足以支持采取行动。第四是复盘：行动后指标是否按预期变化。AI 可以承担大量收集、比对和生成工作，但解释不能脱离数据，动作也不能脱离人的责任。

四、点击率不是终点，用户价值才是

第三个客户做内容阅读类应用，已经在使用推送和广告营销产品。过去运营团队最常优化的指标是点击率：短信点击率能不能提高，推送点击率能不能提高，广告点击率能不能提高。但用户点击之后是否有效阅读、阅读多久、是否形成付费或广告价值，往往由后面的团队继续处理。

我们换了一个起点，不再只问怎样让更多人点开，而是先确定这一轮运营真正要增加什么用户价值。对这个客户来说，最后定义的是有效增量用户数和有效增量阅读分钟数。这两个指标既可能带来会员转化，也可能带来更长的内容消费和广告价值。围绕目标，系统再反推应该给谁发、什么时候发、发什么内容，以及用推送、短信还是广告触达。

过去做精细化运营，常见方式是把用户分成几组，再给组内用户发送相同内容。我们通常只能照顾最重要的一部分用户，基于冷数据或温数据做相对粗的分群。加入 AI 后，人群颗粒度可以继续变小，时间和文案也可以按人调整。

系统把用户打开、阅读、停留时长等行为，与推送、统计和行业环境里的相关信息放在一起。比如某个用户可能是学生、上班族，或者在四五线城市送快递的人；他可能在通勤、休息或其他时间段打开手机。我们不需要为每个人预先写一套固定画像，而是让系统在已有行为里寻找更细的使用习惯，再判断什么时间、什么文案和什么内容更匹配。

如果给所有人早上八点或十点发送同一条消息，用户只能在看到以后再从通知里挑选自己感兴趣的内容。新的做法是根据他的历史打开时间，把消息放在他更可能查看手机的时段；文案也不再完全相同，而是与近期阅读和兴趣关联。人群、时机和内容都发生变化，才有机会把点击之后的消费继续接上。

分享中提到，多轮测试里，个性化时机与文案让点击率相对固定时机提高约 200% 到 500%；点击后的阅读时长约为原来的两倍。把点击和消费放在一起看，某些测试的整体表现接近十倍，后续稳定增量大约在五到六倍。PPT 第 24、25 页分别给出约 4.44 倍点击表现和 1.82 到 2.09 倍人均时长，这些数字对应的测试批次并不完全相同，正式对外使用时仍需要补齐样本、周期和基线口径。

这里最重要的不是一个漂亮倍率，而是指标关系发生了变化。点击率只是入口。真正需要经营的是触达、阅读、留存与长期价值之间的链路。系统执行以后，结果继续回到数据系统，成为下一轮判断的输入，闭环才算成立。

五、Agent负责持续执行，人负责三种判断

三个案例放在一起，AI 可以承担的工作越来越多：收集数据、发现异常、定位问题、生成策略、执行触达、回收结果。产品经理剩下的不是无事可做，而是更集中地负责三种判断。

第一，定义问题。报表里同时存在很多变化，哪些是用户关键路径上的真实问题，不能只按数量或技术严重度排序。第二，判断证据。哪些数据可信，哪些数据带有行业 Know-how，哪些外部信息只是一种相关性，需要人把边界说清楚。第三，验收价值。我们最终要改善的是留存、转化、使用时长、广告价值，还是别的用户结果，必须在 Agent 开始执行前定义。

人在流程里还要定义数据源、执行步骤和验收节点。产品经理或业务真正的一号位先说清楚目标是什么、哪些数据可以喂给 AI、什么结果算完成；中间的收集、分析和执行可以交给 Agent；到了需要阻断、确认和校验的节点，再由人接回来。没有这些边界，自动化只是把不确定性跑得更快。

组织也要负责治理。Agent 能访问哪些数据、能修改什么、什么时候必须由人确认、出现什么情况要中断，都不能临时决定。一个人快速做产品，可以用一个真实问题、一份数据和一次人工确认先跑起来；三四人的小团队更需要明确谁对结果拍板；大企业还要补上数据权限、平台边界和回归测试机制。

我经常看到一种情况：Agent 把每个人的效率都提得很高，整体组织效率却没有提升。问题往往不在模型，而在结果没有负责人。大家各自完成了更多任务，却没有人确认这些任务是不是指向同一个用户结果。先把结果负责人定下来，再把 Agent 放进流程，协同才不会变成各自提效。

六、从一个小问题开始，把服务、洞察和行动接起来

不管是个人开发者、小团队还是大企业，我都建议先找一个原来能看到、但没有精力解决的小问题。先定义问题边界，明确数据来源和服务边界，再写清楚真实反馈的结果目标，以及谁为这个结果负责。只要结果可验证，就可以让 Agent 从一个小节点开始。

第一条流程可以是一次线上异常的定位与修复，一个指标下跌的归因，或者一次面向特定人群的运营触达。流程中间由 Agent 持续收集、分析和执行，关键节点由人确认。跑通一次以后，再把相同的方式复制到其他业务节点，而不是先设计一个万能 Agent 或推动一轮大规模组织变革。

我把这类落地归纳成四件事。第一，保障客户服务，把原来顾不过来的小问题纳入服务范围，保证问题被稳定接住。第二，用数据报表结合 AI，快速洞察指标变化背后的可能原因。第三，把用户切分到尽可能小的执行单元，按业务指标选择渠道、时机和内容。第四，把执行后的数据收回来，继续验证指标，形成闭环。

这四件事仍然围绕同一个顺序：先从指标发现变化，再由 AI 收集证据，之后由人判断哪些证据足以支持行动，最后观察行动后的用户结果。AI 可以把链路自动跑起来，但不能替我们决定什么叫真实问题，也不能替我们承担结果。

我们现在也在调整自己的产品形态。过去友盟+主要做数据统计、数据采集、报表和智能决策，帮助开发者在不同节点用工具提效。现在更希望把数据上下文、评测、推测和诊断放到更靠近结果的地方，反馈给产品和运营团队。团队需要做的不是再看一张更复杂的图，而是判断是否要加入更多数据，判断结果是否符合行业经验，确认行动是否真的与目标指标关联。

三个案例最终落在同一个应用场景：海外应用的异常由数据采集和 AI 流程持续修复；用户指标的异常由内部数据和外部信息共同洞察；洞察出的策略再交给用户分群、触达和内容流程执行，最后把真实用户结果回收到指标里。这不是把工具换成 AI 的口号，而是把服务、感知和行动放在一条能反复运行的线上链路中。

我不建议大家先想着通过组织变革把 AI 的效率提升多少。先选一个过去看得到、但一直没有精力解决的问题，把问题、数据和结果定义好，丢给 AI 跑通。这个节点跑通以后，再把原来顾不过来的问题逐步经营起来，最后回到组织里讨论如何扩大效率，通常更容易落地。

AI 很擅长放大执行，但在放大之前，我们必须知道要放大什么。服务、感知和行动最终要围绕同一个用户结果循环：用户的问题被稳定解决，数据变化被正确理解，运营动作确实产生价值，结果再回到下一轮判断。产品团队真正扩大的不是做报表的能力，而是对用户结果负责的经营半径。

大会专题（可查看所有嘉宾精彩分享）：

https://www.woshipm.com/topic/2026-ai-bj

分享嘉宾：冯成蹊，阿里巴巴高级产品专家

本文基于@冯成蹊 在2026AI产品大会上的演讲进行整理，分享观点仅代表个人，不代表公司。内容未经许可，禁止转载。

题图来自大会现场照片