Josh Woodward 在 Lenny 的播客里讲到一位产品经理。团队原本很期待某项 Gemini 功能，早期反馈却没能支持这份期待。她提出：这东西不好，我们不该发布。Josh 的回应是感谢，而且把感谢回给了邮件里的其他人。
这个细节比“每家公司都要像实验室一样工作”的大命题更吸引我。说要多试新东西，很容易；当团队已经投入精力、领导也表达过期待时，还能不能说停，才会影响下一次实验有没有人敢讲实话。
读完这场对谈，我愿意把 Labs 的经验缩成一个要求：实验要有改变决策的权限。没有价值的可以停，有价值的有人接。 只给团队新工具和做原型的时间，这件事还没办完。
“几乎可行”，要写成用户的任务
Section titled ““几乎可行”，要写成用户的任务”Josh 说，他们维护一份“几乎可行”的清单，留意模型能力何时跨过门槛。这个做法很实用：把注意力从追逐发布会，转到那些一直想做、却卡在技术条件上的事情。
我会给这张清单加一个限制：每项都写成用户任务，后面再写卡住它的条件。
例如，假设一家企业想帮助客服整理复杂工单。“更强的长上下文模型”太宽泛；“从零散记录里找出客户反复遇到的问题，并给出可核对的依据”，才有办法试。接下来要看的，可能是漏掉关键信息的风险、核对所需的人工时间，以及处理成本。模型能读进材料，只是其中一项条件。
这样写还有一个好处：旧方案失效时，问题不会跟着消失。Josh 提醒团队，要爱上问题，别先爱上产品。对我来说，这句话意味着模型、交互和实现方式可以换，但用户为什么需要它，必须一直说得清楚。
访谈里最生动的例子，是他初次听到 NotebookLM 音频演示的回忆：英国议会辩论被变成 AI 主持人的讨论，原本不算引人入胜的材料，忽然有了另一种入口。这里的机会来自材料与使用方式的组合。Google 当年发布 Audio Overview 时，也同时提醒了生成讨论可能出现不准确之处。新体验可以令人兴奋，可靠性仍要单独验证。
所以“几乎可行”最好同时记录：谁遇到了什么问题，哪里还不行，出现什么证据后值得再试。这样，新模型到来时，团队有旧问题可回头检查，而不用临时给新能力寻找用处。
眼睛亮了以后，还要看他愿意付出什么
Section titled “眼睛亮了以后，还要看他愿意付出什么”Josh 对早期产品判断的描述很直接：把原型拿到楼外，观察人的眼睛。对方有没有凑近，有没有突然想把东西拿过来试，比这时急着搭一张指标看板更有帮助。
我喜欢这种朴素的观察。可演示结束以后，他下次遇到同样的问题，还会想起这个产品吗？这要另外验证。
顺着他的说法，我会继续看用户愿不愿意付出。对方只是夸好看，还是愿意带来自己的真实材料？试过之后，是否会主动再用？如果体验足够好，他愿不愿意改掉原有的工作习惯，甚至为它付费？这些都是后续验证的方向，不能靠演示时的表情代答。
回到客服的假想场景：看完自动整理的结果，客服说“很厉害”，当然是线索。但如果他不敢拿它处理实际工单，怕的是遗漏责任、找不到证据，那团队下一步应当修可信度。继续把摘要写得更流畅，很可能是在回答另一个问题。
我理解 Josh 所说的“看眼睛”，是先去找那些被打动的人，再跟着他们的实际使用往下看。等产品往前走，判断是否继续投入的证据也要跟着换。
独立的空间，与成果的去处要一起安排
Section titled “独立的空间，与成果的去处要一起安排”Josh 主张，实验室需要独立性，不能只是塞进既有业务部门。他也反复追问：实验室的目标究竟是把成果交给现有产品，还是创造新的产品线？
我读到这里有些犹豫。空间可以划出来，成果交给谁，却未必有人愿意回答。
放在成熟业务里，陌生想法容易被现有目标过滤：它暂时不贡献收入，用户还少，为什么要占用资源？给它一点距离，可以避免团队过早只做容易解释、容易汇报的事情。
可如果距离太远，业务团队就可能只在演示会上鼓掌。等实验有效了，才发现没人愿意接上线后的质量、成本和用户支持。研究团队继续做新东西，产品团队继续守自己的路线图，有用的原型留在两边之间。
我的补充是：独立性保护探索中的想法，承接约定给有价值的成果一个去处。 两者应当在实验开始时一起讨论。
这不意味着业务部门提前承诺收下任何结果。它意味着双方至少知道：实验在替谁探索；哪些证据足以开启移交讨论；谁有权决定继续投入；谁负责把原型变成可维护的产品。若做的是全新产品线，也要说清楚，届时谁来带它进入下一阶段。
我在《一个支持工单，什么时候值得惊动 CEO？》里关心的是，异常能不能抵达有权改规则的人。这次访谈让我把问题往前挪了一点：发现新机会以后，谁能把它带进公司的资源安排？允许试验，却没人有权改变资源分配，实验团队就很容易停留在展示成果。
这里的边界也要守住。独立探索不免除数据、质量和责任要求；让公司保持实验能力，也不要求所有团队都处在探索状态。已有用户依赖的服务，需要有人稳定地维护。
能撤掉旧认识的人，也要守住专业标准
Section titled “能撤掉旧认识的人，也要守住专业标准”访谈里我最想留下的词，是 unlearning rate。Josh 看重一个人学会某件事以后，能否根据新证据走开。
我理解的“撤掉旧认识”，包含很不舒服的动作：承认自己喜欢的方案没解决问题；接受那个熟悉的技术限制需要重新测试；发现原来有效的工作方式不再适合眼前任务。
它也容易被误用成追新。工具换得快，未必说明判断更新得好。上一项还没弄明白就去追下一项，也可能只是缺乏耐心。
我更愿意用两个问题检查：你改变了哪条判断？是什么证据让你改变？如果答案只有“大家都在用”，这次变化还谈不上学习。
Josh 还有一个提醒与此呼应：即使大家都能当 builder，专业特长也应保留，像大学里的主修和辅修。产品经理能做原型，设计师能写代码，都可以扩大试验范围；但产品判断、体验质量和工程可靠性，仍然需要有深度的人来负责。
跨过角色边界，最好让专业判断更早进入实验。例如工程师发现原型在真实数据上不稳定，这个判断就该影响是否发布。否则人人都能快速搭出来，团队反而更难承认“搭出来”和“做好了”之间的距离。
开头那位提出不发布的 PM，也让我重新理解管理者的作用。公开感谢她，是在告诉旁边的人：拿出坏消息，并不自动意味着你做得不好。想获得可信的实验结果，领导得为这种行为留位置。
下次立项，带上一份实验约定
Section titled “下次立项，带上一份实验约定”如果要把这场访谈变成团队动作，我会先选一个真实问题，带到下一次立项讨论，而不急着另设部门。
可以把下面这些内容写在同一页上：
- 用户任务：谁在什么场景下，需要完成什么？目前最难的一步在哪里？
- 待验证的判断：新能力究竟可能改变哪个条件？怎样用真实材料检查它？
- 停止与转向：什么结果说明当前方案不值得继续？由谁作出决定？
- 成果承接：什么结果值得扩大投入？哪个人或团队参与下一阶段，承担怎样的责任？
这些是我从访谈里延伸出的建议，并非 Google 的原版流程。至少讨论完这些，团队知道结果不好时怎样停，结果好时该去找谁。
也要给它明确的投入边界和复盘时间。得到了不支持原判断的结果，就保留依据，停止或换方案；有了积极信号，就安排后续验证与承接。若只是做出原型，问题还没验证清楚，也可以如实记录，别把它包装成业务成果。
Josh 谈到冲刺之后重新探索的节奏，我觉得同样适合放进这份约定里。团队需要交付时，说明这一阶段的目标；回到探索时，也让大家知道此时允许试探和放弃。若每段时间都必须交出可发布的功能，大家会越来越擅长挑选容易过关的题目。
读完后，我对“像实验室一样工作”的期待反而具体了：有人去试，有人敢说结果不好，也有人愿意接住有效的东西。下一次演示结束，除了问能不能发布，我还想听到团队说清楚：这次改变了什么判断，接下来由谁来做。