为什么公司需要像 Labs 团队一样运作：Josh Woodward 谈 AI 产品、组织节奏与前沿判断

一、嘉宾背景

这期节目来自 Lenny Rachitsky 主持的 Lenny's Podcast，标题把问题直接推到组织层面：为什么每家公司现在都需要像 lab team 一样思考和运作。它不是一集泛泛谈 AI 趋势的访谈，而是围绕一个明确的产品和组织问题展开：当底层模型、构建方式和用户体验边界不断变化时，公司怎样发现新机会、快速验证、决定继续或停止，并把前沿实验带回真实业务。

嘉宾 Josh Woodward 的角色让这场对话有很强的一线管理视角。证据中给出的身份是 VP Google Labs，同时负责 Google Labs、Gemini app 和 AI Studio。他在 Google 工作超过 16 年，当前工作横跨新 AI 产品的实验与规模化，涉及 Google Labs、Gemini app、AI Studio、Notebook、Flow、Google Beam 等项目。也就是说，他既面对 0 到 1 的实验，也面对 Gemini 这种超大规模产品，因此访谈中的许多判断都来自“早期探索”和“规模化运营”之间的张力。

Lenny 在开场给出的前提是：底层技术和模型能力变化太快，公司不能只等既有路线图慢慢消化变化，而要有人持续站在 frontier，试最新模型，跑大量实验，在竞争对手或创业公司之前弄清楚什么已经变得可能。Woodward 认同这个前提，但他马上把问题从“要不要有 Labs”推进到“怎么真正做成”：怎样把创业公司式的方法、想法、能量和兴奋感带进中大型团队，并培养能在这种环境里成长的人与想法。

二、本期主要内容

整集访谈的主线，是 Google Labs 如何在 AI 高速变化中寻找、筛选、推进和放弃产品想法。Woodward 先谈创意来源：他不认为好想法主要来自 design sprint 或排进日历的 brainstorm，而是常常出现在走廊、周末、假期，来自小团队因为好奇和兴奋而忍不住做出的 side project。对 Labs 来说，管理创意不是把人关进会议室挤点子，而是让这些小原型有机会出现，并让组织能及时看见它们。

随后，访谈转向“前沿感”怎样被制度化。Woodward 说，Google Labs 会维护一份“almost possible”清单，持续观察哪些体验、模型能力和用户行为变化正在逼近临界点。当某项能力像相变一样跨过门槛，团队就可以迅速围绕它行动。他还提到，Labs 会思考软件设计与开发、创造力、工作、知识、娱乐等未来，并关注模型延迟、语言覆盖和模态能力等条件。内部甚至有 82 条以未来判断开头的预测；Woodward 同时承认，这些预测绝大多数可能会错。它们的意义不在于保证正确，而在于团队必须有观点，才有办法追逐未来。

访谈中也有不少具体产品例子。Woodward 回忆 NotebookLM 的早期信号，是团队把英国议会辩论交给 AI 主持人处理，结果内容变得有趣；Flow 和 Whisk 的信号则来自以前难以实现的可控创作体验。他还说，Labs 目前全部由 AI 驱动，但不只做软件，也包括 Google Beam 这种可被视为 AI 硬件或邻近 AI 的项目。他对消费 AI 的机会判断包括未来娱乐形态、重新打开的 messaging/chat 空间，以及围绕时间、金钱、记忆和线下共同体验等稀缺资源的新产品。

后半段更偏组织设计。人才上，Woodward 提出 unlearning rate、explosive endurance，以及与人和 agent 协作并快速建立信任的能力；节奏上，Labs 使用 seasons，在模型发布或 Google I/O 等节点前后冲刺，之后给团队 hack、rediscover、build for fun 的探索恢复期；规划上，团队采用约 6 个月 rolling roadmap，并希望优秀 Labs 小队能在 50 到 100 天内把想法推进到 meaningful milestone。最后，他谈到建立 Labs 团队的三条建议、常见组织错误，以及用 TPU harvester、golden bandaid、LLM whisperer 这类奖项把价值观变成可见行为。

三、核心观点：推理、例子与边界

这期访谈最核心的判断，是 AI 时代的产品组织不能只优化既有路线图，还必须持续接触 frontier。Lenny 的问题来自一个现实压力：模型和底层技术变化太快，很多“昨天不能做”的事情可能突然变得可做。Woodward 接受这个前提，但没有把答案简化成“成立一个创新部门”。他的逻辑更具体：Labs 的价值要同时建立在三件事上，一是持续发现技术和体验门槛的变化，二是把这些变化连接到真实用户问题，三是能在大公司结构中推进、放弃或毕业这些实验。少了任何一环，Labs 都可能变成热闹但无效的 R&D 玩具。

Woodward 对创意来源的判断尤其值得拆开。他说，强想法很少来自 design sprint 或排进日历的 ideation，而常常来自走廊对话、周末、休息时间、小型高热情团队，以及人们忍不住继续做的 side project。这不是反流程，而是在说明早期创意的原材料往往是强好奇心、前沿体验和个人投入。Google Labs 的“almost possible”清单，就是把这种直觉变得更可管理：团队不是空等灵感，而是先对未来娱乐、软件开发、创造力、工作和知识形成假设，观察模型延迟、语言覆盖、模态和行为趋势等条件；一旦某个条件跨过门槛，就能更快把人和资源组织起来。这里的限制也很清楚：预测本身并不可靠。Woodward 说，82 条预测里可能九成甚至 9.9 成都会错，所以这些预测不能被当成事实路线图，只能作为让团队更快学习的临时观点。

第二个核心观点，是早期 PMF 的证据和成熟产品的证据不能混用。Woodward 明确说，早期原型不是先看 DAU、DAU/MAU 或 D7，而是看用户眼睛是否亮起来、是否身体前倾、是否被真实痛点击中。NotebookLM 的例子说明了这种信号：英国议会辩论本身不天然有趣，但 AI 主持人的处理让它变得可听，团队因此看到了体验层面的可能性。Flow 和 Whisk 的例子也类似，重点不只是模型能生成内容，而是用户获得了过去难以实现的可控创作体验。不过这个观点的边界也必须说清楚：眼睛发亮不是规模化成功的充分条件。Woodward 自己也承认，团队会对一些东西兴奋，做出来却不好；早期判断更像艺术，有时依赖少数人的 conviction，因此需要多次试错，不能把一两个惊艳 demo 当作确定性。

第三个观点，是“爱上问题，不要爱上第一个方案”。Woodward 说，一个方向往往要经历三、四、五次 pivot，才知道是否有东西可做。这句话把 Labs 的实验观和普通功能开发区分开来：如果团队爱上的是具体产品形态，就容易在证据不支持时继续防守；如果爱上的是问题，就能在 Notebook、Flow、Gemini 或其他形态之间移动，寻找真正击中用户痛点的表达。与此对应，杀项目也不应只等领导拍板。Woodward 说，团队通常比领导更早知道项目不行，信号包括热情耗尽、所有能试的都试了仍没有进展，以及团队能否说出“这个不够好，不该发布”。这个观点的管理含义很硬：领导的责任不是永远维持士气，而是创造能讲不舒服真话的环境。

第四个观点，是 AI 降低执行成本后，小团队会更有杠杆，但组织优势不会自动来自“会用 AI 写代码”。Woodward 预期，Labs 项目团队可能从过去常见的五到七人，变成两三人或四人；PM 可能会 coding 和 design，strategy、ops、BD、marketing 也可能成为 builders。但他同时反对用“人人都是 builder”抹平专业性。他用 major/specialty 的方式说明：AI 扩展副能力，不取消主专业。真正变重要的是 unlearning rate、explosive endurance、人与 agent 的协作，以及人与人之间扩展信任的能力。也就是说，AI 让执行更便宜，但判断、节奏、信任和专业深度变得更贵。

第五个观点，是 Labs 必须设计与母公司的连接方式。Woodward 说，每家公司都需要 frontier team，成员要跟进新模型发布、X 上 24 小时内爆火的新东西，以及新的构建方式；但他也指出，大公司 lab 历史上常在三四年后失效，或者无法商业化成果。因此 Labs 的成败不只是“够不够前沿”，还取决于是否有清楚的成功规则：是把项目毕业到现有产品，还是发明新产品线；是只探索技术，还是也挑战公司工作方式。这里的不确定性在于，不同公司没有同一套答案。Google Labs 和 Gemini 可以共享“用户第一、Google 第二、产品第三”的优先级，但其他公司必须按自己的组织结构、商业化路径和风险承受力重建这套机制。

最后，Woodward 对 AI 行业的价值排序提出了一个有约束的提醒：原则和价值观被低估，benchmark、Elo、speeds and feeds 被高估。他不是说能力指标没有用，而是说多数用户并不直接关心 Elo rating，产品最终必须把模型能力翻译成真实价值。这个观点和前面的 Labs 方法互相扣合：如果团队只追模型指标，容易做出技术展示；如果只追用户眼睛发亮，又可能忽略长期安全性、商业化和规模化质量。真正困难的是在不同阶段使用不同证据：0 到 1 看强反应，10 到 100 看 funnel、CPA 和 magic moments 转化，同时持续追问这个产品编码了什么原则、到底帮了谁。

四、学习与应用

如果把这期访谈转成公司可用的做法，第一步不是立刻命名一个“AI Lab”，而是建立可重复的 frontier sensing 机制。团队可以维护一份“almost possible”清单，按用户问题、模型能力、体验变化和行为趋势来记录，而不是只记录热门工具。每条假设都应同时写清触发条件：例如延迟降到什么程度、语言覆盖到什么范围、模态能力达到什么质量、用户行为出现什么变化，才值得组队尝试。这样做的价值，是让灵感之前先有准备；边界是这些判断大概率会错，所以清单不能变成承诺式 roadmap。

第二步，是把早期验证设计成对“强需求信号”的观察，而不是过早套用成熟指标。对于 0 到 1 原型，团队应该主动走出办公环境，把 demo 给真实用户看，记录他们是否前倾、是否追问、是否把它连接到自己的痛点、是否愿意继续使用或付费。这里可以借鉴 Woodward 的尺度：早期看 eyes 和 pain point，进入 10 到 100 之后再看 waterfalls、CPA、转化到 magic moments。取舍在于，定性信号快而敏感，但容易被 demo 新鲜感误导；量化指标更稳定，但太早使用会把小而强烈的需求误判为“不够大”。

第三步，是为实验团队设置短周期但非短视的节奏。Woodward 的 rolling six months 和 50 到 100 天 meaningful milestone，适合转化成一套轻量治理：每个方向有 6 个月视野，但每 50 到 100 天必须证明它有明显进展。进展可以是更强的用户反应、关键技术门槛跨越、商业化路径更清楚，或明确发现方向不成立。与此同时，团队需要 seasons：重大模型发布、行业事件或公司发布会可以成为冲刺节点；冲刺后必须保留 hack、rediscover、build for fun 的恢复探索期。限制是，这需要领导敢于承认“看似没发货”的时间也有产出，否则组织会把所有季节都压成冲刺，最终耗尽创造力。

第四步，是用人才标准保护 Labs 的行为模式。招聘或选人时，不能只看某人是否会 prompt、会 coding、会快速做 demo，还要看 unlearning rate：他们能不能根据用户测试放弃昨天的判断；看 explosive endurance：他们能不能在关键阶段冲刺，又不把团队烧光；看信任扩展能力：他们能不能同时和 agent、工程师、设计师、PM、营销或 BD 协作。AI 时代确实会让角色边界变模糊，但应用 Woodward 的观点时要保留 major/specialty：让 PM 的 coding 服务于更好的产品判断，让设计师的 AI 使用服务于更强体验，而不是把专业性抹平成“都会一点”。

第五步，是在组织结构上提前回答 Labs 的归宿问题。一个 frontier team 需要独立空间，否则会被现有业务单元的短期指标吸走；但它也不能完全脱离公司，否则容易变成无法商业化的玩具。公司应在成立时就说明：这个团队的项目是毕业到现有产品、孵化新产品线，还是两者都有；进入 one-to-ten 或 ten-to-a-hundred 后，指标、人员和决策权如何变化；什么时候该交给主业务，什么时候该继续独立。Woodward 提到，过早整合和过快招聘都是常见错误，也提到 30 名工程师却没有 PMF 的教训。应用上，更稳妥的做法是先让小队证明用户强反应和问题价值，再扩人和加流程。

第六步，是把文化价值变成具体、可重复的仪式。TPU harvester、golden bandaid、LLM whisperer 这些奖项之所以有用，不只是因为有趣，而是因为它们把抽象价值编码成可见行为：优化底层效率、修复小的产品摩擦、探索模型边界。任何公司都可以借这个思路设计自己的符号，但必须奖励真正想重复的行为，而不是奖励表演式忙碌。最后的边界仍然回到 Woodward 对 benchmark 的提醒：所有 Labs 机制都应该服务于用户价值和组织学习，而不是服务于“我们看起来很前沿”。

来源

• 原始节目：Why every company now needs to think and operate like a lab team | Josh Woodward (VP Google Labs)