增长实验不是“主指标赢了就上线”，而是一份包含目标、不可伤害项和停止条件的契约。AI 让实验变多、读数变快之后，真正稀缺的反而是：系统能否在局部转化变好时，及时看见可靠性、信任或长期价值正在变差。对 Momcozy APP，Guardrail Metric（护栏指标）不是看板上的附属数字，而是 Agent 获得任何执行权限之前必须遵守的边界。
做产品实验时，人最自然会先选一个 Primary Metric（主指标）：例如，希望新版绑定帮助让更多用户完成设备绑定。问题是，一个动作可能让主指标上升，却把代价转移到别处：用户被引导反复重试，短期“完成次数”增加，但设备连接并不稳定；AI 助手回答更短，任务看似更快结束，却漏掉必要的风险提示。
Guardrail Metric（护栏指标），大白话是：我们允许系统追求增长，但先规定哪些重要结果不能被明显伤害。生活类比是开车导航。目标是更快到达，护栏不是“另一个目的地”，而是不能闯红灯、不能走危险道路、不能让油耗失控。最快路线一旦越过边界，就不再是好路线。
护栏还要配 Stopping Rule（停止规则）：什么信号出现时要暂停、回滚或交给人。否则“监控了投诉率”只是一句愿望。Momcozy 的待验证例子是：测试一段新的绑定指导，主指标可以是首次稳定连接；即时护栏可以是错误率、重复失败和崩溃，较长期护栏可以是客服求助、负面 VOC 与合理周期内的稳定使用。涉及母婴、儿童、健康或安全的信息，不应拿“统计上暂时没变差”换取放宽底线；有些边界必须是硬门槛。
Airbnb：护栏触发的不是自动否决，而是强制升级判断
当多个团队同时优化不同目标时，系统需要在上线前识别“一个局部指标变好、公司级体验却可能变坏”的实验，并把它升级给人讨论。
关键事实
Airbnb 工程团队披露，其平台每周并行数千个线上实验，每个实验监控约数十个指标。团队把公司级护栏分成业务/财务、用户体验、战略优先级三类，并设置三种检查：影响是否超过可接受负向阈值、样本量是否有足够检验能力、某些关键指标是否出现统计显著的负向变化。该系统当时每月大约标记 25 个实验进入升级审查；约 80% 在补充分析和讨论后仍上线，约 20%，即每月约 5 个，被停止。文章还提醒，若同时对 50 个指标都用 0.05 显著性报警，在 AA test（两个相同版本的空实验）中出现至少一个假警报的概率可达约 92%，所以护栏不是越多越安全。
编辑视角它证明了什么： 这是一套真实的大规模实验治理系统，证明“触发护栏 → 人工升级 → 补证据或停止”可以兼顾速度与风险。它不能证明 Airbnb 的阈值适合 Momcozy；母婴、儿童、健康和设备安全的风险结构不同，有些伤害也可能很稀少、很晚才出现，不能只靠总体统计发现。
Airbnb 2026 GenAI 实践：AI 质量门槛要在开发前写进流程，而不是上线后补一张分数表
对非确定性的 AI 功能，目标与发布门槛应先于规模化开发；少数清晰、校准过的评测，比几十个模糊分数更能守住产品边界。
关键事实
Airbnb 在 2026 年 7 月发布的 Eval-driven Development（评测驱动开发）实践中，建议先明确“优化什么、发布前必须满足什么”，从约 100 个样本读真实输出，再把发现的失败写成持续测试。文章主张保留 3–5 个聚焦且校准良好的 LLM Judge（大模型评审），而不是堆 20–30 个嘈杂评测；建立 50–100 条、同时包含好坏例子的黄金样本，把自动 Judge 与人工判断校准到高 80%–90% 的一致区间，并定期重校。对 Agent，还要分别检查步骤、执行路径和整段会话是否达到用户目标。
编辑视角它证明了什么： 这是一手工程方法，支持“AI 产品的护栏应成为可执行发布门槛”，也说明人工判断仍是高风险和分歧场景的基准。但文章主要分享流程与建议，不是增长效果实验；高一致率也不等于真实用户留存、信任或任务结果一定改善。离线质量门槛与线上价值实验仍要分开。
这次新增什么
Hamel Husain 与 Shreya Shankar 长期帮助产品团队建立 AI Evals，并培训过 2,000 多名产品与工程人员。前几期我们已经拆过 Error Analysis（错误分析）、覆盖度和 Judge 校准；今天不再讲“怎样打分”，只深读节目 1:00:51 提出的另一层：Evals are the new PRDs——评测正在变成 AI 产品“活的需求文档”。
过去的 PRD 为什么不够
传统 PRD（Product Requirements Document，产品需求文档）可以写：“助手应给出相关、清晰、安全的回答，并在必要时转人工。”但生成式 AI 不会像普通按钮那样每次返回同一结果。文字写得再完整，也无法证明新 Prompt、模型、知识库或工具变化后，这些要求仍然成立。
“活的 PRD”不是把需求文档交给 AI 自动写，而是把关键要求绑定到真实样本、通过/失败标准和可重复运行的检查：什么算解决用户问题，什么算不当确定，什么情况必须承认不知道，什么情况必须交还给人。每次出现新的真实失败，这份需求就增加一个例子或修订一条标准；每次系统变化，它都重新接受检查。
AI 改变的是“要求如何持续生效”
过去，产品要求主要在评审会上被阅读；上线后，是否偏离要求往往靠投诉、抽查或事故才被发现。现在，代码检查可守格式和禁用项，校准过的 Judge 可规模化检查相关性、语气与依据，人工专家负责高风险、分歧和新型失败。这样，需求从静态文字变成持续运行的质量门。
但不要误解：Eval 不是产品目标，也不能替代线上实验。它能说“系统是否符合我们写下的要求”，不能独自证明“这些要求真的创造用户价值”。如果 Eval 通过率提高而任务解决、信任或长期使用没有改善，我们要校准需求与代理指标，而不是继续追分。
Momcozy 最值得借什么
最值得借的不是先建一套庞大 Eval 平台，而是给一个具体场景写一页“可执行要求”。例如 AI 设备帮助：回答必须引用正确设备知识；不确定时不得猜；连续失败要带上下文转人工；敏感内容不被用于无关个性化。可以自动检查的写成规则，需要判断的配人工样本，任何高风险边界由人负责。这样 Agent 的权限由一份可验证契约约束，而不是由“模型升级了”决定。
以“护栏感知的增长实验 Agent”为例：
系统读取什么：经授权、最小化的实验假设、目标人群资格、主指标、即时与长期护栏、风险等级、实验曝光、设备和 APP 版本、任务结果、脱敏 VOC、人工接管，以及历史实验在哪些条件下有效。敏感母婴、儿童、健康和设备数据不能为了提高预测能力被默认拼接。
形成什么判断：先检查实验契约是否完整——主指标之外是否有不可伤害项、阈值、观察窗口、最小样本和停止规则；运行中再区分主指标上升且护栏稳定、主指标上升但护栏恶化、证据不足、埋点异常、分群伤害被总体平均掩盖等状态。
能做什么：自动生成缺失护栏提示、做历史回放和影子监控、聚合异常分群、准备暂停或回滚建议；只在事先批准的低风险、可逆范围内，才可以按明确阈值暂停实验。未经明确授权，不向真实用户发送 Push、EDM、站内信，不修改生产设备或健康指导，也不自行扩大流量。
如何看结果并更新策略：实验结束后，不只记录“赢/输”，还记录效果是否稳定、代价出现在哪个分群和时间窗、哪个护栏真正提供了信息、哪个只是噪声。若主指标赢但重复失败或负面 VOC 上升，系统降低该策略置信度；若护栏频繁误报，则由人调整阈值或口径，而不是悄悄删除护栏。
何时交给人：高风险健康或儿童语境、任何设备安全异常、隐私投诉、全新失败类型、样本不足、长期指标尚未成熟、主指标与信任指标冲突，以及所有真实上线与触达。自动生成护栏看板仍是 AI-assisted；持续检查契约、发现越界、在权限内止损、用结果更新下一轮契约，才接近受治理的 AI-native 闭环。
场景一：设备绑定与首次稳定使用。 待验证假设是，缩短步骤或强化重试提示可能提高当次绑定完成，却让部分设备或系统版本出现更多重复失败。可以借 Airbnb 的“影响 + 检验能力 + 显著负向”思路，但不能直接照抄阈值。主指标应更接近首次稳定连接，而不是按钮点击；即时护栏包括错误、崩溃、重复失败和异常重试，较长期护栏包括客服、负面 VOC 与合理周期稳定性。最先需要的证据是：实验曝光、设备版本、重试与最终结果能否可靠串联。
场景二：AI 助手首次问题解决。 待验证假设是，压缩回答长度或提高自动解决率可能让会话更快结束，却增加误解、重复求助或不当不转人工。可以借“活的 PRD”，把正确知识、能力边界、应否转人工和隐私最小化写成发布门槛；线上再看任务解决、重复追问、人工接管和信任。不能把“减少转人工”天然当增长，高风险场景中，正确交接本身就是成功。
场景三：订阅或配件转化。 待验证假设是，更积极的推荐可能提高短期点击，却在故障、投诉或敏感阶段制造被利用感。主指标可以是合格场景下的转化，护栏应包含关闭、投诉、退款、后续留存和推荐相关性。不能根据推断出的孕产育阶段自动扩大营销；资格、授权、频控与不动作选项必须先定义。最先需要的不是更聪明的文案，而是哪些情境根本不应推荐。
- Primary Metric｜主指标：实验最希望改善的核心结果。Momcozy 例子：绑定帮助实验看首次稳定连接，而不是只看帮助卡点击。
- Guardrail Metric｜护栏指标：允许追求主目标时，明确不能被明显伤害的结果。Momcozy 例子：绑定完成上升时，重复失败、客服和负面 VOC 不能同步恶化。
- Stopping Rule｜停止规则：实验前写清什么信号出现就暂停、回滚或升级给人。Momcozy 例子：某设备版本错误集中上升，立即停止扩大流量。
- Power｜检验能力：实验有多大机会发现一个真实存在的变化。Momcozy 例子：样本太少时，“没看到伤害”不等于“证明没有伤害”。
- Living PRD｜活的产品需求文档：把产品要求连接到真实样本与持续检查，而不是写完即归档。Momcozy 例子：AI 助手每次变更都重新验证正确知识、风险边界和人工接管要求。
写一张“增长实验契约”，只选 设备绑定帮助 或 AI 助手首次问题解决，不运行真实触达：
- 写一个主指标，并说明它为什么比点击或会话数更接近用户价值；
- 写两个即时护栏、一个较长期护栏；
- 为每个护栏写清观察窗口，以及“暂停 / 回滚 / 人工复核”条件；
- 写一个绝不进入普通增长实验的高风险边界。
产出物是一页目标—护栏—停止条件卡。完成后能更新的判断是：我们设计的是一个“有机会赢”的实验，还是一个“即使赢也知道没有拿信任和安全交换”的实验？最后只回答一个具体问题：如果绑定完成率上升，但同一批用户的重复失败和客服求助也上升，我们会把它判成赢、输，还是证据不足？为什么？