AI-native Growth 的起点不是“让 AI 自动跑实验”，而是先建立一套能判断好坏的 Evals（评估体系）。没有它，系统只会更快地产生动作，却不知道自己是在改善体验，还是在放大错误。真正的闭环是：看见失败 → 定义失败 → 衡量失败 → 修复 → 再验证。
传统软件的功能相对确定：点击按钮，要么成功跳转，要么报错；工程师可以写一条明确规则自动检查。但 AI 产品的输出不是固定答案。同一个问题可能有十种合理回答，也可能语气正确、事实却错，或者内容都对，却没有真正解决用户此刻的问题。
Evals（Evaluations，评估体系）就是把“这个 AI 表现得好不好”从模糊感觉，变成一组可以持续检查的标准、样本和判断方法。
可以把它理解成母婴产品的“质检体系”，但它检查的不是螺丝有没有拧紧，而是更模糊的事情：建议是否安全、是否理解用户阶段、是否遗漏关键追问、是否在不确定时及时交给人。
一个完整 Eval 通常包含四样东西：
- 真实样本：用户到底问了什么，AI 当时怎么回答；
- 失败模式：哪些错误最伤体验或信任；
- 判断标准：什么算通过，什么必须失败；
- 重复运行的方法：产品、Prompt、模型或数据变化后，再检查旧问题有没有回来。
Momcozy APP 的假设例子：如果用户说“宝宝喝奶后一直吐”，评估不能只看回复有没有提到 reflux（反流）。还要检查：有没有识别潜在风险、有没有避免越权诊断、有没有给出清晰的就医边界、有没有根据宝宝年龄和症状继续追问。这就是为什么 AI 产品不能只看点击率或满意度。用户可能点开了，也可能觉得回复温柔，但核心安全问题仍然存在。
Netflix：先决定一周该不该打扰，再决定此刻说什么
个性化触达不应只优化“哪条 Push 最可能被点”，还要先管理长期疲劳、退订和信任。
关键事实
Netflix 公开的新通知系统把决策拆成两层：慢策略按更长周期规划一个用户的 Push / 邮件节奏和预算；快策略才在预算内选择此刻最相关的内容。它不再让触达频率成为逐条预测的副产品，而是把“这周值得打扰几次”作为独立决策。
编辑视角它证明了什么： 这说明短期局部指标和长期关系不是同一个优化问题。但 Netflix 没有公开具体提升数字，也不能由此推断所有 APP 都应该增加触达；真正可借的是“长期策略与即时执行分层”。
Lovable：AI 产品增长从优化漏斗，转向持续创造新价值
当产品能力每一到三个月都可能变化，旧增长漏斗的微调速度可能追不上产品价值本身的变化。
关键事实
Lovable 增长负责人 Elena Verna 在 Lenny’s Podcast 里说，她过去积累的增长打法只有约 30%–40% 能直接迁移；在 Lovable，大约 95% 精力投向增长创新，5% 才是传统优化。她列出的有效做法包括持续发布可传播的新能力、build in public（公开展示构建过程）、让用户或社区组织者低门槛体验产品，并通过真正让人惊喜的结果形成口碑循环。
编辑视角它证明了什么： 这是一个高速变化 AI 产品的操盘经验，不是适用于所有公司的普遍定律。Momcozy 是“硬件 + APP + 母婴服务”场景，不能照抄大量免费额度；但可以借用一个问题：我们是在优化旧入口，还是产品还没有创造出足够强的首次价值？
Anthropic：增长团队开始让 AI 参与“发现做什么”
AI 在增长中的上限，不是自动写实验文案，而是参与发现异常、提出实验候选并缩短验证周期。
关键事实
Anthropic 增长负责人 Amol Avasare 公开介绍了内部增长实验工具 CASH，也分享了让 AI 每天分析 20–25 张图、寻找异常与机会的工作方式。访谈还强调 activation（激活，即用户第一次真正获得价值）是 AI 产品中杠杆最高的问题，并采用约 70/30 的大项目与小优化组合。
编辑视角它证明了什么： 公开访谈能证明他们正在自动化增长研究和实验流程，但不足以证明系统已经完全自主决策。目标、风险、资源分配和上线边界仍由人负责，因此它更像“半自动闭环”，而不是无人增长机器。
先认识这两个人：他们不是来教你做排行榜
Hamel Husain 与 Shreya Shankar 长期帮助产品和工程团队建立 AI Evals，并培训过 2,000 多名 PM 和工程师。两人最重要的观点不是“选一个评估工具”，而是：先亲眼看失败，再决定要测什么。
很多团队顺序正好相反：先让 LLM 给输出打一个总分，再去找这个分数代表什么。这样很容易得到一张漂亮 Dashboard，却不知道该改产品的哪一部分。
第一步不是写评分 Prompt，而是 Error Analysis
Error Analysis（错误分析）是人工查看一批真实 traces——也就是“用户输入、系统中间过程、AI 输出”的完整记录——然后自由写下每一条哪里不对。
一开始不要急着套固定标签。看到“AI 没有问宝宝年龄”，就写这句话；看到“回答很长，但真正的操作建议埋在最后”，也直接写下来。这个阶段叫 Open Coding（开放编码）：先让问题自己浮出来，而不是拿已有分类硬套。
当记录逐渐重复，再把相近问题合并成 Axial Coding（轴心编码）。例如：
- 信息收集不足：缺年龄、症状持续时间、设备状态；
- 风险边界不清：该转人工或就医时仍继续回答；
- 回答不可执行：看起来正确，但用户不知道下一步做什么；
- 个性化错误：把孕期建议给了产后用户；
- 表达问题：过长、过度安慰、关键结论不突出。
这一步的价值是把“AI 有时不太好”变成产品团队可以修的具体问题。
为什么最初不能全部交给 AI
访谈里强调，第一次错误分析需要一个能做最终判断的人，他们称为 benevolent dictator（善意的最终裁判）。不是因为一个人的看法永远正确，而是产品必须先明确自己的价值取舍：安全和简短冲突时谁优先？信息不足时是继续给一般建议，还是先追问？
LLM 可以帮助整理大量笔记，但不能替团队凭空决定这些价值标准。否则就会出现“让一个还没被校准的 AI，去定义另一个 AI 是否正确”的循环。
什么时候才用 LLM-as-judge
当人已经找出稳定的失败模式，并写出清晰标准后，才适合让 LLM-as-judge（用另一个大模型当评审）批量检查。例如判断“是否在高风险症状下给出了明确人工接管建议”。
但 Judge 本身也要拿人类判断做校准：同一批样本先由人标，再看 Judge 是否经常误判。它适合扩大检查规模，不适合替代最初的产品判断。
这也是“Evals are the new PRDs”的含义：过去 PRD 写“功能应该做什么”；AI 产品的 Eval 进一步保存“哪些真实回答算做好、哪些失败绝不能回来”。它是一份会持续运行的产品要求，而不是上线后就过期的文档。
今天这条完整链路可以画成：
- 感知：读取用户对话、设备行为、VOC、人工接管记录和实验结果；
- 发现：AI 聚类异常，但人先抽样查看真实记录，确认问题不是数据噪声；
- 定义：把失败模式写成清晰 Eval，例如“高风险场景必须明确建议人工接管”；
- 提出动作：系统生成 Prompt、流程、帮助内容或触达实验候选；
- 上线前验证：新方案跑过历史 Eval 集，确认旧错误没有反弹；
- 小范围执行：只在明确人群和权限内运行，保留回滚；
- 反馈学习：比较通过率、真实行为、负面 VOC、人工接管和长期留存，再更新失败模式。
如果只做到第 1–3 步，这是 AI-assisted Product Analysis；做到第 4–6 步，是有治理的半自动实验系统；只有系统能持续从结果中更新机会优先级，同时人仍掌握目标和红线，才接近 AI-native Growth System。
关键不是“人退出”，而是人从逐条执行者变成目标、标准和权限的设计者。
场景一：AI 助手的回答质量
待验证假设：目前如果主要看使用量、点赞或投诉，可能看不到“回复被打开了，但实际没有解决问题”的中间层失败。
可以先建立最小 Eval 集：从公开测试问题或经过合规处理的匿名样本中，覆盖孕期、产后、哺乳和育儿阶段；分别检查信息收集、安全边界、可执行性、阶段匹配和表达清晰度。涉及健康与儿童信息时，真实数据必须满足授权、最小化使用和匿名化要求；高风险问题必须保留人工接管。
不能照抄 Lenny 案例的地方：母婴场景的错误成本远高于普通物业 AI 助手，不能仅依赖 LLM Judge。安全类标准需要专业人员参与，低置信度应直接转人工，而不是继续生成。
场景二：设备绑定与首次价值达成
待验证假设：“注册完成”未必等于 activation。真正激活可能是完成绑定、成功获得第一条有用数据、理解一个关键功能，或者第一次解决设备使用问题。
这里的 Eval 不只评 AI 文本，而是检查整个旅程：系统是否识别用户卡在哪一步、帮助内容是否对应真实故障、问题解决后用户是否继续完成绑定。Agent 可以读取授权后的事件序列与错误码，提出卡点类型；但在证据不足时只能生成“待核验假设”，不能直接给用户下结论。
最先需要的证据不是再做一张总漏斗，而是抽样看 10–20 个失败旅程：用户在哪一步离开、当时看到了什么、系统提供了什么帮助、是否重复尝试。先看人，再定义指标。
- Trace｜运行轨迹：一次 AI 任务从用户输入到最终输出的全过程。Momcozy 例子不是只保存最后一句回答，而是同时看用户问题、系统调用了哪些知识、是否追问、为什么转人工。
- Error Analysis｜错误分析：人工看一批真实失败，找出可重复的问题。它回答“到底哪里坏了”，不是只看平均分下降。
- Open Coding｜开放编码：第一轮先自由记问题，不预设分类。像整理用户访谈时先贴原始便签，不急着塞进旧框架。
- Axial Coding｜轴心编码：把大量具体便签归成几类稳定模式。例如把“没问年龄”“没问持续多久”合并为“关键信息收集不足”。
- LLM-as-judge｜大模型评审：让另一个模型按照明确标准批量判分。它像经过培训的质检员，可以扩规模，但标准仍需人制定，并定期与人工结果对表。
用 25 分钟建立第一版“不可接受失败清单”。任选一个场景：AI 助手回答，或设备绑定帮助。写出 5 条你认为绝不能发生的失败，每条补一句“为什么伤害用户”。
产出物不是完整 Eval，而是一页最原始的产品判断。完成后我们就能检查：哪些可以自动测，哪些必须由人判断，哪些涉及安全或隐私红线。
你想先从 AI 助手回答质量，还是从 设备绑定/首次价值达成 开始建立第一套 Evals？