本文是 Lenny's Podcast 与 Anthropic Claude Code & Cowork 产品负责人 Kat Wu 的对话。通过她的分享，我看到的不仅是 AI 时代 PM 的工作方式重塑，也窥见了一些 Anthropic 的"AI 原生"组织范式。在一个能力边界不断被重画的行业里，个体与组织正发生着怎样的进化？
一、AI 时代 PM 的角色重塑
1.1 产品迭代周期快速压缩，这个能力的背后是什么
AI 之前，技术迭代以 6--12 个月为周期，PM 的主要工作是跨部门对齐多季度路线图。现在，模型能力每几个月就有大的跃迁，很多功能的交付周期从 6 个月压到 1 周、甚至 1 天。
Kat 的核心判断是：AI 原生产品中，PM 的工作重心从"对齐长期路线图"转向"缩短从想法到交付的时间"。
I think the PMs who do the best on AI-native products are the ones who can figure out how can I shorten the time from having this idea to actually getting the product in the hands of users and help define what are the most important tasks that need to work out of the box for my product.
那么 PM 具体靠什么把时间压到一周甚至一天？Kat 在访谈中明确列出的 三件事。
① 设定清晰目标（Set Clear Goals）
LLM 足够通用，这恰恰带来了"我们到底给谁做、解决什么问题"的模糊。好的 PM 能把模糊变精确，以 Claude Code 的权限提醒为例：
- 核心用户：企业里的专业开发者
- 核心问题：权限提示（permission prompts）太多，用户疲劳
- 目标用例：让专业开发者安全地做到"零权限提示"
清晰目标的本质就是收窄方案空间，这样一句话排除掉了"用另一种方式减权限提示"的选项。
② 可重复的发布流程：Research Preview
Claude Code 几乎所有新功能都以"研究预览"（Research Preview）身份上线，明确 brand："这是实验性产品，可能不会长期支持。" 把团队对内、对用户的承诺成本降了一个数量级，团队也不再怕"这功能万一没人用、万一要废弃怎么办"，因此敢于快速试错。
③ 跨职能协作框架：evergreen launch room
团队里有一个 Slack 频道叫 evergreen launch room。工程师觉得某个功能内部验证通过了，就发到这个频道。然后：
- Docs 负责人接手写文档
- PMM 负责人立刻产出 marketing 文案
- ......
PM 不用再手动协调，因为框架建好了，每个合作伙伴自己知道"什么时候该我上场、我的期待是什么"。
1.2 Product Taste 是最稀缺的能力
代码变便宜了，"决定写什么"就成了最珍贵的能力。在 GitHub 上，Claude Code 每天都有上万条 issue 涌进来，哪些值得做就是 Product Taste。
Kat 的判断是：这个能力可以来自工程、产品、设计任一背景。"只要你强烈展现了这个能力，我们愿意招任何角色。"
1.3 工程背景短期内仍占优
Kat 本身是工程背景的，她提到工程背景短期内仍占优势。其实很好理解：有工程底子能更快判断"这个功能大概多难"。一个 1 小时能写完的功能，可以直接上手干了；但是一个需要重构 infra 的功能，就得提前规划好。
但 Kat 强调：这只对未来几个月成立。每一代模型都会重新洗牌"什么技能最重要"。长期看，具备第一性原理思考、能随时切换角色补团队缺口的人才是稀缺品。
- 什么是第一性原理思考：把一个问题剥到不能再剥的最底层事实，再从这些事实出发重新推导结论，而不是照搬别人的经验、类比或行业惯例。这个理论亚里士多德最早提出，Elon Musk 把它用在 SpaceX 火箭成本测算上。典型思考路径是：不问"别人怎么做"，只问"物理定律允许的下限是什么"，然后把现实与这个下限之间的差距，当作要解的问题。
- 为什么在 AI 时代尤其重要 ：每一代新模型上线，旧的"经验"------比如"这类任务必须人工做"、"前端验证只能人肉点"------都可能在一夜之间失效。靠类比（别人怎么做我们就怎么做）会把你锁死在上一代范式里；只有能回到"用户到底要什么 / 模型到底能做什么 / 约束到底是什么"这三层事实上重新推导的人，才跟得上模型进化的节奏。
二、Anthropic 的组织哲学
这种个体层面的"自适应"，离不开背后强悍的组织支撑。Kat 讲述的过程中，窥见了一些 Anthropic 的组织哲学，我把它大体概括为三条：保持聚焦 · 团队价值观 · 极简流程。我觉得很有意思，单独开个章节展开说说。
2.1 使命统一 保持聚焦
团队在决策产品发布应该聚焦什么时，会以 Anthropic 的最高使命为灯塔："把 AGI 安全地带给全人类"。如果有两个竞争的优先级，团队会讨论哪个对 Anthropic 的使命更重要，保持聚焦让产品在做决策时容易得多。
保持聚焦这一点，其实从两件事中也可以看出来。
第一件事是 Claude 的定位。之前 Anthropic 花了据说 800 万美元，在超级碗投放广告：Ads are coming to AI. But not to Claude.（广告正涌向 AI，但 Claude 除外。）后来他们也在博客解释道："我们的商业模式很简单------通过企业合同和付费订阅赚钱，这是一种权衡（Tradeoff）。"
另外一件事是 Claude API 对 OpenClaw 限流，Claude 订阅不再能用在第三方产品上，开源社区哀声一片。Kat 也直接回应了："订阅按第一方产品用量定价，第三方用量完全不同，$200/月 本身就是严重补贴，我们必须优先保障第一方产品和 API。" 产能有限时，优先服务"把模型能力安全送达用户"的主干，而不是最大化短期订阅指标。
2.2 团队价值观：拥抱混乱、brutally prioritize
AI 时代每周都是救火现场。Lenny 问 Kat 怎么在这种节奏下不 burnout，Kat 的回答实际上勾勒出了 Anthropic 团队价值观：
- 拥抱混乱（lean into the chaos）。团队喜欢招"能笑着面对挑战"的人。"总有太多风险和棘手情况，你如果每件事都焦虑，马上就会 burnout。我们找的是看到挑战会说'这会很难，但我很高兴能去搞定它'的人。"
- Brutally prioritize + 睡好觉。"一个需求上周日还是 P0，周一就成了 P00，周一下午又变成 P000------回头看周日的那个 P0 并不那么重要。人的精力是有限的，你能做的其实就两件事：睡好觉让第二天的决策更清醒，然后 brutally 地决定时间花在哪里。"
- 接受不完美。"我们发的产品有时没我希望的那么 polish，但只要不阻塞开发者的核心用例，带着 bug 发也 OK------我们会听到反馈，下个版本修掉。这以前能让我整晚睡不着，现在我能接受------因为反馈回路足够短。"
- 招"经历过起伏的人"。团队偏好招在行业里待过一阵子、经历过多轮起伏的人。他们对"什么消耗自己、什么给自己供能"有清晰认知，能把能量维持在长期水平。
Lenny 给了个形象的比喻："像《加勒比海盗》里的一个场景，船在身边被拆得稀稀烂烂，主角还能气定神闲地走下楼梯。" 这大概就是 Anthropic 团队的写照。
"We try to face every challenge with a smile." ------ 当风暴就是常态时，情绪稳定本身就是一种工作能力。
2.3 极简的流程
"我们的流程非常精简，我们想消除发布东西的每一个障碍。我们想确保团队每个人都感到有权力把自己的想法从一个想法变成一个发布到世界上的东西------在不到一周内，有时甚至一天。"
"墙"修得越少，船开得越快。Kat 讲的"极简流程"不是口号。
2.4 引申
这三点让我想起了 Clayton Christensen 在《创新者的窘境》里讲过一段话，大意是：
机构的初创阶段，大多数工作的开展得益于它的员工资源 ------几个关键人员的加入或离开，都可能对其成功与否产生深远的影响。但随着时间的推移，机构的能力轨迹会逐渐转向其流程和价值观：在员工们通力合作、反复解决同类任务的过程中，流程被逐步确定下来；而随着商业模式的成型，哪些业务值得做、哪些不值得做，价值观也随之建立。
我觉得 Anthropic 的高明之处在于，在还是"人"的阶段，就把价值观和流程沉淀出来了。
三、给从业者的实操技巧
除了组织层面的宏大叙事，Kat 也分享了许多 AI 原生个体在日常开发中的具体技巧。
3.1 评估模型的三种方法
访谈里提到了几个评估方法，非常可复用：
- 让模型自省 ：当模型行为异常（比如只改前端不点 UI 验证），直接问它"你为什么这么做"。它通常会告诉你是 system prompt 有歧义、或者不知道前端验证属于任务的一部分。很多 Harness 缺陷就是这么被发现的。
- 找到你最信任的 5 个人：评估模型好坏需要"会表达直觉的人"。找出身边最会描述 model + harness 组合优劣的 5 个人，形成快速反馈回路。
- 写 10 个好 Eval：不需要几百个，10 个高质量 eval 就能帮团队量化"目标是什么、进展到哪了"。
3.2 自动化不到 100% 就不叫自动化
很多人把自动化做到 90--95% 就放弃了。但 90% 不是自动化，最后那 5--10% 确实要花更多时间，但这是唯一值得做的部分。
3.3 反对过度定制：用起来 > 炫配置
Twitter 上总有人晒"看我这套 MCP + skills 配置多优雅"------Kat 直言："你到底在 build 什么？"
她观察到两个极端：一类从不自动化任何东西；另一类沉迷折腾配置、反而分散了主业。简洁配置反而更有效，重点是"你每天真的在用这个工具产出价值吗"。
四、未来：在下一代模型的"能力边缘"造产品
面对不断突破的行业边界，团队该如何保持领先？
4.1 新模型上线后先做减法
每次新模型上线，Claude Code 团队做的第一件事是通读整份 system prompt，逐条问"这个提示还需要吗？"。
"The model will eat your harness for breakfast." 模型越强，你的 harnness 越精简。
4.2 在"还不够好"的边缘造原型
方法论：提前为"未来 6 个月可能做到"的场景写原型，等新模型一来，直接替换推理层，看是否补上了最后那段 gap。这样当模型真的到位，你是全世界最先拥有这个能力产品的人。
4.3 Just Do Things
Kat 的人生信条："Jobs are fake."
只要你理解了约束、清楚要优化什么，就能推导出正确的行动，然后就去做，快速迭代，做错了道歉就是。这既是创业公司思维，也是 AI 时代每个人都需要的能力：不要等别人告诉你 你可以做什么。