AI 自动扫完二十张图，得到的是一批“值得注意的变化”，还不是一批“值得做的增长实验”。从异常直接跳到实验，会把埋点漂移、季节波动、版本故障和用户结构变化都误当成产品机会。真正应该自动化的是一条有刹车的链路：先确认变化真实，再定位受影响旅程，保留竞争解释，最后才生成可证伪的实验候选。
传统分析的旧问题是“人看不过来”：几十张看板、多个平台和版本，每周都可能有转化、留存或客服量变化。AI 很适合持续扫描，但它也会带来一个新问题——把“检测到变化”包装成“已经理解原因”。
Opportunity Triage（机会分诊），大白话是：像急诊分诊一样，先判断一个变化是噪声、测量问题、已知故障、外部变化，还是值得验证的产品机制，再决定补数据、修故障、做研究、设计实验或不动作。它不是一个华丽报告，而是一道把“观察”变成“可行动判断”的门。
生活类比是家里烟雾报警器响了。报警说明传感器看见异常，不等于已经证明厨房着火；也可能是蒸汽、电池故障或邻居烟雾。正确顺序是确认信号、定位房间、寻找其他证据，再决定灭火、维修报警器还是解除警报。直接根据报警声改造厨房，就把检测当成诊断了。
Momcozy APP 的待验证例子：某天“设备绑定完成率”下降。第一层只是在描述现象；第二层要查事件契约、APP / 系统 / 固件版本、网络与入口构成；第三层才形成竞争解释，例如新版页面故障、弱网用户增加、成功事件延迟，或帮助内容真的失效。只有当某个解释能写出“如果它是真的，还应看到什么；如果它是错的，什么证据会推翻它”，它才有资格进入实验或修复队列。
Mixpanel RCA：先验证异常，再让 AI 排查贡献维度
成熟的自动诊断不是看到曲线拐点就编故事，而是先检查它是否超出正常波动，再逐层拆分哪些人群、平台或渠道贡献了变化。
关键事实
Mixpanel 当前的 AI-Powered Root Cause Analysis（AI 驱动根因分析）会先为异常点建立基线：小时数据约看此前 24 小时，日数据约看此前 14 天，周数据约看此前 9 周，月数据约看此前 6 个月；再用 z-score（标准分，表示偏离历史均值多少个标准差）判断，文档把 2 以上作为异常门槛，并按同一星期或同一时段检查周期性。通过后，Agent 才选择 acquisition、audience、platform、data quality、identity 等属性，运行 breakdown（分解），计算各分群对总变化的贡献，并给出解释、置信等级与下一步。
编辑视角它证明了什么： 它证明“异常验证 → 维度选择 → 贡献拆分 → 解释”已经能被产品化，明显好过让模型只看一张截图自由发挥。但官方也明确写出 V0 尚未把 annotations（上线注释）、session replay（会话回放）、experiments（实验）和 metric trees（指标树）纳入推理。贡献最大只表示“变化主要发生在哪”，不等于“这个分群导致了变化”；z-score 也不能识别所有季节性或数据漂移。因此 RCA 给出的是调查起点，不是因果结论。
Amplitude：从全量扫图到摩擦聚类，仍只覆盖可见信号
AI 可以把散落的图表和会话信号压缩成优先级列表，但优先级取决于它能看到什么、怎样估计影响，不能自动等同于用户价值。
关键事实
Amplitude 的 Dashboard Agent 会分析一个看板上的全部图表，寻找趋势、异常、漏斗下降与受影响分群；周期运行时还会比较本周与上次结果，区分新发现、持续发现和已经变化的发现。其 Friction Monitor 则把跨会话出现的相似摩擦做 fingerprint（指纹识别）与聚类，按估计影响排序，并链接到对应 session replay，方便人看到真实上下文。
但边界写得同样清楚：Dashboard Agent 的全面扫描主要识别 pattern 与 correlation（模式与相关性），不是预测或因果模型；Friction Monitor 当前是 closed beta（封闭测试），现阶段只识别 dead click（点了没反应）与 error click（伴随错误的点击），还依赖 Autocapture 的覆盖与足够样本。更广泛的回放分析、异常识别和商业影响仍是后续能力。
编辑视角它证明了什么： 它证明 AI 的现实优势是“压缩调查空间”：从成百上千条信号缩成少数可查看问题，并把定量异常接回真实旅程。它没有证明排第一的问题一定最值得修，也没有覆盖设备离线、服务端确认、聊天结果或敏感用户状态。若可见数据只包含点击，系统就会天然把点击摩擦看得比设备稳定性更清楚。
先认识这个人，以及今天新增什么
Amol Avasare 是 Anthropic 的 Head of Growth，此前做过 Mercury、MasterClass 的增长。在 Lenny 2026 年 4 月的访谈中，他介绍了内部增长实验系统 CASH。我们此前已经拆过 CASH 的完整循环和 70/30 大赌注组合；今天只新增前端机制：AI 如何从大量图表中发现候选机会，以及为什么“自动扫图”只是入口。
过去怎么做，AI 改变了哪一步
访谈提到，增长团队过去需要反复阅读约 20–25 张图，寻找激活、转化或使用上的异常和机会。人的瓶颈不是不会看图，而是扫描频率、跨图记忆和重复劳动：某个分群连续三周变化，可能散落在不同看板；上次做过相似实验，也未必能被及时想起。
CASH 的意义不只是把图表总结成文字。AI 可以持续读取指标变化，提出“哪条旅程、哪类用户、哪个环节值得查”，再连接历史实验和后续执行。与传统自动报告相比，它开始参与机会发现与实验循环，而不是等人先决定问题。
最容易误解的地方
“Claude is growing itself”是对自动化程度的强表达，不等于模型可以从相关性直接宣布因果。图表只能显示系统记录到的行为；如果成功事件语义漂移、真实曝光丢失，或某次版本发布没有注释，Agent 会稳定地放大错误输入。Anthropic 是高频 AI 软件，反馈快、可重试性强；Momcozy APP 涉及实体设备、弱网、固件、母婴与健康语境，不能照抄其实验速度和自动放量边界。
我们真正能借的是：让 Agent 负责“持续扫描 + 竞争解释 + 查重 + 证据缺口”，而不是只负责“异常 + 单一原因 + 实验建议”。一个合格候选至少要带五件东西：观察到什么、最可能影响哪段旅程、还有哪些竞争解释、什么证据会推翻判断、若行动必须守住什么护栏。
以“增长机会分诊 Agent”为例，完整链路不能停在自动日报。
系统读取什么：经过事件契约校验的漏斗、留存、任务结果和护栏；APP、系统、固件与设备版本；发布注释、实验分组与真实曝光；脱敏 VOC、客服主题、商店评价与人工排障结论；历史异常、实验和修复结果。母婴、儿童、健康与设备数据必须按目的最小化使用，不能为了补全画像默认跨场景拼接。
形成什么判断：先给每个变化标记“正常波动、周期性、测量异常、已知故障、外部构成变化、疑似产品机制或无法判断”；然后列出受影响旅程、证据强弱、竞争解释和可证伪条件。无法区分“行为没发生”与“事件没到达”时，系统应优先补测量，不生成触达实验。
能做什么：自动扫描、查历史重复、运行允许的 breakdown、抽取少量脱敏旅程、生成一页机会卡；对已批准的低风险分析可提出 SQL、访谈样本或影子实验方案。它无权因为某条曲线下降就自动发送 Push、EDM、站内信，无权改变生产策略，也不能把已知设备故障包装成增长实验。
如何看结果并更新策略：如果进一步对账发现是事件漂移，就把该洞察降级为测量问题，并提高同类检查优先级；如果修复后指标恢复，只能证明故障关联，需要保留其他解释；如果随机实验通过可信门并改善真实任务结果与护栏，才提高对应机制的置信度。失败与“无结论”都进入实验记忆，避免 Agent 下次重复推荐。
何时交给人：核心指标定义变化、数据权限不清、样本很小、健康或儿童语境、设备安全、VOC 与行为信号冲突、因果主张、资源取舍和所有真实上线，都交给人。自动扫图和写解释属于 AI-assisted Operations（AI 辅助运营）；系统持续感知、分诊、提出可证伪候选、在权限内验证并用结果更新机会排序，才开始接近 AI-native Growth System（AI 原生增长系统）。
场景一：设备绑定与首次稳定价值。 待验证假设是，“绑定完成率下降”可能来自页面故障、权限变化、弱网、固件组合、事件延迟或真实流程摩擦。可以借 Mixpanel 的顺序，先验证异常与周期性，再按 APP / 系统 / 固件版本拆贡献；接着借 Amplitude 的思路，把异常分群接回脱敏旅程或错误日志。不能因为 Android 某版本贡献了大部分下降，就直接断言版本导致下降；最先需要的是发布注释、契约版本、真实曝光和设备稳定结果能否对齐。
场景二：AI 助手与 BBM/VOC。 待验证假设是，重复求助上升可能代表答案质量变差，也可能是入口更可见、用户更愿意继续问，或“再次求助”口径变化。系统可以联合任务类型、知识检索、回答结果、正确转人工与脱敏 VOC 做分诊；不能把会话量下降自动解释成体验改善，也不能用敏感对话建立营销画像。最先需要一小批人工校准，区分“未解决后重问、自然追问、新任务、正确接管”。
可以借什么、不能照抄什么：可以借自动扫描、历史查重、竞争解释和证据门；不能照抄高频软件按日优化的节奏。Momcozy 的真实结果可能延迟，阶段自然结束也可能是成功。系统首先应该减少错误实验，而不是最大化实验数量。
- Opportunity Triage｜机会分诊：先判断变化属于噪声、测量、故障还是可验证机制。Momcozy 例子：绑定下降先查版本与事件，再决定修复或实验。
- Anomaly Detection｜异常检测：判断一个数据点是否明显偏离正常范围。Momcozy 例子：某日稳定连接低于同星期历史区间；异常不等于原因已知。
- Root Cause Analysis / RCA｜根因分析：系统化寻找哪些因素最能解释变化。Momcozy 例子：比较系统、固件和入口贡献，但仍需实验或排障验证因果。
- Contribution Factor｜贡献因子：某个分群占总变化的多少。Momcozy 例子：某 APP 版本贡献了大部分下降，只说明变化集中在那里。
- Falsifiable Hypothesis｜可证伪假设：提前写清什么证据会证明自己错。Momcozy 例子：若问题来自新版帮助页，未真实曝光新版的人不应出现同幅下降。
做一张“异常不是机会”分诊卡，只选一个假想现象：设备绑定完成率突然下降，不查真实敏感数据、不改生产、不触达用户。
- 只写观察，不写原因：“哪个指标、什么时间、相对哪个基线、变化多大”；
- 写四个竞争解释：测量漂移、版本故障、用户构成变化、真实旅程摩擦；
- 每个解释各写一条支持证据和一条推翻证据；
- 规定下一步只能选一个：补测量、排障、看脱敏旅程、做研究或设计低风险实验；
- 写两条红灯：设备安全或隐私不清时必须交给人。
产出物是一页“观察—竞争解释—证伪证据—下一步—红灯”机会卡。完成后能更新的判断是：我们缺的是更多实验想法，还是缺少一套阻止系统把每个波动都变成实验的分诊纪律？最后只回答一个具体问题：在 Momcozy APP 里，哪一个指标一旦异常，最容易让我们过早跳到产品原因，却其实应该先查数据与版本？