今天刷到一个播客，采访的是 Anthropic Claude Code 和 Cowork 的产品负责人 Cat Wu。听完之后，我脑子里一直回荡着一个词：真快。
不是“迭代快一点”的那种快，而是把产品从想法到用户手里的时间，从半年直接压到一天的狠劲儿。这在传统互联网公司听起来几乎是天方夜谭，但在 Anthropic 却成了日常。
Cat Wu 讲得非常直白：他们大量使用 “research preview”（研究预览） 机制。 意思就是：不用等功能完全打磨完美，也不用写一堆承诺性文档，先扔给用户看看再说。
这种做法的最大好处是： ✅ 工程师有想法 → 端到端快速推出 ✅ “evergreen launch room”快速反应流水线 → 文档、营销、支持团队第二天就能跟上 整个流程像流水线一样顺畅。
💡 背后的逻辑很简单：AI 时代，用户反馈来得太快，模型能力每天都在变。 如果你还按传统六个月一个大版本的节奏来，早就被甩在身后了。
这期播客最戳我的，是对产品经理角色的重新定义。
传统 PM：画大饼、写长 PRD、做半年路线图 Anthropic 的 PM：把“一个想法快速变成用户能用到的东西”
Cat 观察到： 🔹 最厉害的 PM 几乎都有工程背景，或至少会写代码 🔹 因为只有这样，才能快速判断：这个需求难不难？值不值得现在做？
更狠的是： 📉 PRD 在很多情况下已经不那么重要了 📈 取而代之的是：每周 metrics 分享 + 清晰的团队原则 → 大家拿着这些，就能自己做决策，不用事事等 PM 拍板。
角色界限也在模糊：
🔥 “谁离问题最近，谁就上手” -- 这种模式反而让效率变得极高。
Cat 和她的技术搭档 Boris Cherny 的配合被反复提起。
两人有 80% 的时间处于“mind-meld”（心有灵犀） 状态：
剩下 20% 的时间：谁对某件事更在意，谁就主导推动。
听起来简单，但真正能做到这种信任与分工的团队，真的不多。
播客里也聊到了前段时间 Claude Code 源代码通过 npm 包泄露 的事。
Cat 承认这是流程上的失败： 虽然经过了两层人工审查，还是没发现 source map 被打包进去。
但她没有推卸责任，而是直接说：
“相关人员还在公司，我们已经大幅加固了防护措施。”
能公开承认流程失误，同时不把人一棒子打死 -- 这种处理方式，我挺欣赏的。
另一个引发社区热议的话题： Anthropic 禁止用户通过第三方工具（如 OpenClaw）使用 Claude。
Cat 的解释是：
“我们要优先保障自己的产品和官方 API 的稳定运行。”
从容量管理和基础设施压力角度看，逻辑上能理解。 但时间点确实敏感 -- 正好在他们自己推出类似功能的前后。
✅ 值得借鉴的点：
⚠️ 但也要注意：
🌟 结论： Anthropic 的模式不是银弹，但它为 AI 时代的产品协作提供了极具启发性的范本。 尤其在“速度即竞争力”的今天，“先跑起来，再优化” 或许才是正解。
你怎么看？你们团队有尝试过类似的快速迭代模式吗？欢迎留言讨论！👇
加入讨论
“research preview”这个思路太戳我了！我们团队之前总想着“等完美了再上线”，结果一拖就是三个月。现在想想，用户早点骂也比晚点夸强啊😂 而且PM会写代码真的降维打击，下次招人我得把“能写两行Python”写进JD了！
这个“谁离问题最近谁就上手”真的戳中我！我们组最近也在推类似机制，结果发现设计师改个按钮样式比等PM排期快了十倍😂 不过有点担心边界模糊会不会导致责任不清？你们怎么平衡灵活性和流程啊？
“evergreen launch room”这个机制太强了！我们团队每次上线新功能都得等文档、培训、客服准备，结果用户反馈来了黄花菜都凉了。你们觉得这种快速流水线模式在小公司也能跑起来吗？会不会因为资源不够反而更乱？
“研究预览”这个机制真的让我眼前一亮，之前我们总怕用户看到半成品，现在想想，早点被骂反而能少走弯路😂 不过想问下，这种快速上线会不会让工程师压力太大？毕竟既要写代码又要应对用户反馈，你们团队是怎么平衡的？
“mind-meld”这个形容太绝了！我和技术搭档也试过这种模式，结果发现80%的默契靠的是每天一起吃午饭😂 不过Cat和Boris能对齐AGI愿景和落地路径，这种组合真的可遇不可求。你们团队有这种“灵魂搭档”吗？
“研究预览”听着简单，但真敢这么干的团队太少了！我们之前上线前非要搞全链路压测+安全审计，结果用户拿到手都凉了😅 不过你们怎么平衡“快速上线”和“别把用户当小白鼠”的？毕竟不是所有用户都能接受半成品啊…
“谁离问题最近谁就上手”这个理念真的绝了！我们组最近也试了，结果发现连实习生都开始主动改UI bug了😂 不过有个小担心：如果每个人都跨边界做事，会不会最后没人清楚到底谁该为结果负责？毕竟“快速”和“混乱”有时候就一线之隔啊。
“研究预览”听着挺酷，但用户会不会觉得被当成测试员了？😂 我们之前上线个半成品，结果被吐槽“你们拿我当免费QA吗”。不过话说回来，如果反馈真能快速迭代，用户可能反而更愿意参与——关键是得让用户觉得“骂了有用”，而不是“说了白说”。
“研究预览”听着很猛，但你们怎么确保用户不会因为这个半成品体验直接跑路啊？😂 我们之前也试过快速上线，结果用户说“这功能能用但总觉得差点意思”，然后就再也没打开过。是不是得配个“我知道它不完美但我愿意试试”的用户心态筛选器？