1 天发一个功能：Cat Wu 拆 Anthropic 极速 shipping 法与 PM 在 AI 时代的重塑
How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
本报告由 AI 深度分析生成，基于视频完整字幕。
导读
Lenny's Podcast 是当下产品经理圈影响力最大的播客——Lenny Rachitsky 是 Airbnb 出身的资深 PM，他这档节目几乎采访了硅谷所有重量级产品负责人。这一期他请来了 Cat Wu——Anthropic 旗下 Claude Code 和 Cowork 的产品负责人，整个公司里离"重新定义产品经理工作"这件事最近的人。
为什么这场对话比同类播客更值得听？
- Anthropic 的 shipping 节奏在硅谷是异类——Cat 在视频里说，"The timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to even one day."（很多产品功能的时间表从 6 个月缩到 1 个月，有时甚至 1 天。）
- Claude Code 和 Cowork 是当下 PM 工作流变化最剧烈的两个产品——它们既是 PM 工具的对象，也是改造 PM 自己的工具。
- Cat 直接负责招聘 Anthropic 的 PM——她说她每周面试几百个 PM，看到的是一个正在被全面重新定义的角色。
这场对话最值钱的部分不是"用 AI 多快"——是 Cat 给出了一份当下 PM 该长什么样的清单：spec writing、eval setting、product taste、能直接 prototype。** 这份清单和 5 年前的 PM 教材毫无重叠**。
一句话核心论点：当代码变得几乎免费，"决定写什么"才是真稀缺资源。PM 的角色不在缩水——它在升级。但前提是：你要愿意亲手把模型当工具用、亲手 prototype、亲手设 eval——不能只做 PRD 投递员。
核心观点速览
- Anthropic 的 shipping 公式三件套 —— 清晰目标 + 可重复的发布流程 + 跨职能默契框架。第三件最少被讨论但最关键。
- Research Preview 标签是 shipping 的核心润滑剂 —— Anthropic 几乎所有 Claude Code 新功能都先以 "Research Preview" 标签发布——降低用户期待 = 降低团队心理成本 = 加速发布。
- PM 团队 30-40 人，分 5 大类 —— Research / Cloud Dev Platform / Claude Code & Cowork / Enterprise / Growth。每类对应一个信息流向，不是按产品线切。
- Anthropic 没有缩 PM —— 在反向扩 —— 因为工程跑太快，PM 和设计反而成了瓶颈。"PM 死了"的预测在 Anthropic 是反的。
- AI 时代 PM 的 4 项新核心技能 —— Spec writing / Eval setting / Product taste / 直接 prototype。和"会写 PRD 会画 wireframe"的旧 PM 完全两个物种。
- 统一使命是 Anthropic 的不公平优势 —— "Bringing safe AGI to all of humanity" 高于任何产品线 → 跨部门决策秒速达成 → 速度的根。
- AGI-pilling 的恰当度 —— 建造者既要相信 AGI 即将到来，又不能"太相信"——超前 6 个月正好。
- Cowork 被严重低估 —— 它是"非代码输出"场景的杀手，连接 Calendar / Slack / Gmail / Drive 后才显威力。
- Internal tools 爆发 —— Anthropic 内部出现"个性化工作软件"潮——销售员自己造定制 deck 生成器，从 Salesforce + Gong 自动拉数据。
- 完美主义法则 —— "There's not much value in 95% automation." 必须 100% 可靠才能真信任 → 必须建立 eval 反馈循环让它持续提升。
主体
一、为什么 Anthropic 能 1 天发一个功能：三件套机制
Cat 把 shipping 速度拆成三件具体动作——不是文化、不是天赋、是机制：
机制 1：清晰得近乎冷酷的目标
"LMs are so general that actually creates a lot of ambiguity in who we're building for, what problems we're trying to solve, what the top use cases are."
（LLM 太通用了，反而让"谁是用户、解决什么问题、关键用例是什么"全部变模糊。）
Cat 给的具体例子：
"Our key user is professional developers. The main problem is too many permission prompts and people are feeling fatigue. The use case is we want professional developers at enterprises to safely get to zero permission prompts."
（用户：企业里的专业开发者。问题：权限确认太多，用户疲劳。用例：让专业开发者在不损失安全的前提下，权限确认归零。）
这条三段式结构本身就是 PM 的工艺标准——目标定得越具体，就排除得越多潜在路径——速度从减少选项中来。
机制 2：Research Preview 标签
这是 Cat 提到的最低估的杀招：
"We ship almost all of our features in research preview. We clearly brand this when we ship something so that users know that this is an early product, this is just an idea, this is just something that we're trying to get feedback on and iterating on, and that this might not be supported forever."
（几乎所有功能我们都用 "Research Preview" 标签发。让用户清楚知道——这是早期产品、这是想法、这是为了收集反馈、它可能不会被永久支持。）
它在做的事是：把"发布"的心理成本拆成两层——"小步发布"和"承诺发布"。普通公司只有"承诺发布"，所以每次发都要走完整 QA / 文档 / 营销 / 客服培训链——结果一年发不了几次。Anthropic 用 Research Preview 把"小步发布"独立出来——用户期待降低 → 团队心理成本降低 → 一周甚至一天就能发。
⚠️ 可借鉴的设计：任何有用户基础的产品，都可以学 Anthropic 的"双发布通道"——Beta 通道用于实验，Stable 通道用于承诺。这件事看上去简单但很多大公司死活做不到，因为他们的市场部和客服部不愿区分两种期待管理。
机制 3：跨职能默契度（最被低估）
"For Claude Code, we have a really tight process between engineering, marketing, and docs. When engineers have a feature that they feel is ready and that we've dogfooded internally, they post it in our evergreen launch room. Sarah who leads our docs and Alex who leads PMM and Tar and Lydia on Devrel just like jump in and can turn around the marketing announcement for it the very next day."
（Claude Code 的工程 / 市场 / 文档之间有一套非常紧的流程。工程觉得功能准备好、内部 dogfood 过了，就发到 Launch Room。文档负责人 Sarah、PMM 负责人 Alex、DevRel 的 Tar 和 Lydia 立刻接手——第二天就能发布。）
这条最值得学的部分：他们用名字记住了流程——不是"工程通知运营"——是"工程通知 Sarah 和 Alex"。人和角色的绑定让流程从"协议"变成"反射"。这是大公司用 30 页 SOP 也复制不出来的，因为它需要小到每个人都能记住对方名字的团队规模。
二、Anthropic 的 PM 团队结构：5 类，按"信息流向"切
Cat 把团队画给 Lenny 听——结构非常清晰：
| 团队 | 角色 | 输出 |
|---|---|---|
| Research PM | 听客户对模型的反馈 → 喂给研究团队 | 模型迭代方向；负责 model launch |
| Cloud Developer Platform | 维护 Claude Code 跑在上面的 API | API + Managed Agents（用户造 agent，Anthropic 帮托管） |
| Claude Code & Cowork | 核心面向用户的产品 | Cat 的本职 |
| Enterprise PM | 让 Claude Code / Cowork 易于企业部署 | 成本控制、RBAC、安全控制——让 CIO 安心 |
| Growth PM | 全产品矩阵增长 | 跨产品转化与扩展 |
精彩之处：这套切分不是按产品切，是按"信息流向"切——
- Research PM 是信息进来（客户 → 研究团队）
- Enterprise PM 是摩擦消除（企业 IT 反对 → 落地）
- Growth PM 是信息往外（潜在用户 → 试用）
对应的产品哲学：每个 PM 都对一个**完整的"信息流回路"**负责，而不是一块"功能领域"。这套切分让团队避免了"有 5 个 PM 都在改同一个用户旅程"的常见公司病。
三、为什么 Anthropic 反而在扩 PM——而不是缩
视频里 Lenny 抛出一个争议性问题——硅谷流行的"PM 会被砍光"论。Cat 的回答是反向的：
"PMs and designers are squeezed because engineers are moving so fast. ... There's a lot more product definition required and there's lower ego about what work they do to help the team move faster."
（PM 和设计反而被挤压——因为工程跑得太快了。需要更多产品定义工作，而且需要那种"低自我"——愿意做任何让团队更快的事的人。）
这条的反直觉：很多人以为 AI 会让"产品定义"自动化——其实反过来。当工程跑得 10 倍快——PM 必须以 10 倍速度产出清晰的方向、明确的用户优先级、可执行的 spec——否则工程没东西做。真实的 bottleneck 转移到了 PM/Designer 身上。
Cat 给出的"AI 时代仍需人脑的 4 件事"：
"Humans still provide a level of common sense that the models don't. ... The model doesn't always have a great sense of who all the stakeholders are, how they relate to each other, what their preferences are, what are the right venues to communicate with them."
（人还能提供模型缺的"常识"——以及更重要的：stakeholder management（谁是利益相关方、他们如何关联、偏好、最佳沟通渠道） 。这种"tacit"的 EQ 知识仍然有价值。）
四、AI 时代 PM 的 4 项新核心技能（Cat 给的最实用清单）
① Spec writing skill（spec 撰写能力）
"As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write."
（当代码变得很便宜——决定写什么变得更值钱。）
Spec ≠ PRD。PRD 是"产品需求文档"——给工程看的需求列表。Spec 是"给模型看的可执行规范"——精确到 API contract、edge case 处理、性能阈值。不会写 spec 的 PM 在 AI 时代等于不会写 PRD 的旧 PM。
② Eval setting skill（评估集设置能力）
"Often the output of this is: okay, here are five evals that I made, this is how you run them, these are the ones that succeed and these are the ones that don't, and this is the prompt that I've used to increase the success rate."
（好的 PM 的输出常常是：这是我做的 5 套 eval、运行方法、哪些通过哪些不通过、用什么 prompt 把成功率提上去。）
Eval 是 AI 产品的"单元测试"——但比单元测试更难，因为答案不是"对/错"，是"够好/不够好"。好的 PM 必须能定义"够好"是什么样——这是一个质量定义工作，需要 product taste 和量化能力同时具备。
③ Product taste（产品品味）
Cat 反复强调的最虚但最重要的能力。她举了 Anthropic 内部公认的"taste 极强"的人：
"Amanda who molds Claude's character. ... The task is so ambiguous. Even coding is easier because you can verify the success whereas crafting the character requires a very strong sense of conviction."
（Amanda 是塑造 Claude character 的人。这个角色非常难——任务极其模糊。编码反而更简单，因为成功可验证。塑造性格需要一种近乎信念的坚定。）
Product taste 在 AI 时代的具体表现：
- 能感觉出一个模型回答"过于讨好"
- 能在 5 个回答里选出一个"虽然短但更对"
- 能为产品定义"它该有什么样的拒绝姿态"
④ 能直接用模型 prototype
"30% of my time is pushing the boundaries of what Cowork can do so that I have a very strong sense of what we're not good at."
（我 30% 的时间在用 Cowork 推它的边界——这样我才知道我们哪里不行。）
这条是分水岭——把 PM 分成两类：
- ❌ "我等工程做出来再来评估" = 旧 PM
- ✅ "我用模型自己造 demo 来定义需求" = AI 时代 PM
对中国 PM 的对应：今天就该开始在工作流里用 Claude / GPT / 字节系自家模型做日常工作，不是为了效率——是为了培养对模型能力边界的直觉。
五、Anthropic 的不公平优势：使命作为决策操作系统
Lenny 问了那个最关键的问题——为什么 Anthropic 起步晚、融资少、没分销、OpenAI 远远领先——今天却年化 110 亿美元 ARR？
Cat 的回答非常具体：
"We hire people who care most about bringing safe AGI to all of humanity. And this is actually something that we reference frequently in our decisions about what our entire product or org should focus on shipping. And because we put this mission above any individual product line, we're able to make very fast decisions that cut across the entire org."
（我们雇的人最在乎"为人类带来安全 AGI"。我们在决策"该发什么、不该发什么"时频繁回到这条使命——因为它高于任何单一产品线，我们能跨整个组织极速决策。）
这条洞察的深意：大多数公司决策慢不是因为聪明人不够——是因为有 5 个 VP 都觉得自己的产品线最重要——会议变成谈判。当"使命"高于产品线——所有跨部门撕扯瞬间有了仲裁标准。
第二个优势——AGI-pilling 的恰当度：
"It is very hard to be the right amount of AGI-pilled. It's very easy to build the product for the super AGI strong model. The hard thing is figuring out for the current model, how do you elicit the maximum capability?"
（"AGI-pilling 的恰当度"非常难拿捏。很容易为"未来 AGI"造产品——困难的是为今天的模型设计：怎么从它身上挤出最大能力？）
这条对所有 AI 产品创业者都是金句——太相信明天 = 造一堆超前但不可用的产品；太不相信明天 = 等着被超前 6 个月的人吃掉。正好超前 6 个月——是 Anthropic 找到的甜蜜点。
六、Cowork：被严重低估的那个产品
视频中段 Cat 花了大篇幅讲 Cowork——很多人以为它就是 Claude 网页版的换皮——其实是完全不同的物种：
"If I'm building something where the output is code, I'll use Claude Code. If the output is anything that's not code, I'll use Cowork."
（输出是代码 = 用 Claude Code；输出是非代码（slack 回复、邮件、PPT、文档）= 用 Cowork。）
Cowork 的核心机制：连接你的工作上下文源——
"Connect it to your Google Calendar. Connect it to Slack, Gmail, Google Drive. So that it just knows it has the flexibility to find relevant context."
（连接 Calendar、Slack、Gmail、Drive——让它能自由找到相关上下文。）
Cat 自己的具体使用案例：她要做一个 Code with Claude conference 的 talk，主题是"Claude Code 从 assistant 变成 agent 的转变"——她让 Cowork 从 Drive 和 Slack 拉所有相关产品发布、内部 demo 案例 → 自动拼出 talk 大纲。
为什么这件事对中国读者有启发：现在大家用 ChatGPT/Claude 时绝大多数是"开窗口、贴文本、问问题"——完全没用上"长期上下文 + 多源连接"的真威力。Cowork 模式（Cat 用了 30% 时间在它上面）才是 next-gen 助手的样子。
七、Internal Tools 爆发：Anthropic 内部的"自造软件"潮
Cat 描述的一个极有意思的现象：Claude Code 内部不只是"开发工具"——它催生了一波普通员工自造工作软件的浪潮：
"It really lowers the barrier to making any custom app that you want. We've seen this surge in personalized work software that people are building for custom use cases instead of using tools that don't perfectly fit the use case."
（它把"造任何自定义 app"的门槛降到极低。我们看到一波"个性化工作软件"涌现——人们为自己的具体场景造工具，而不是凑合用不完美的现成工具。）
她举的销售案例让人印象深刻：
一位 Cloud Code 的销售员发现自己反复在做相似的 customer deck——
- 他造了一个 web app
- 从 Salesforce 拉客户数据 + 从 Gong 拉销售通话录音 + 从笔记拉合同细节
- 输入客户名 → 自动生成定制 deck
- 自动判断："这家用 Bedrock？删掉 Cloud for Enterprise 的页"
- "这家关心 code review 阶段？加 code review 章节"
- "这家要 HIPAA？加合规页"
这件事的革命意义：以前"造内部工具" = 提需求给 IT → 排队 6 个月。现在 = 一个销售员自己 1 天造完。整个企业软件市场的逻辑会被这个改变——很多 SaaS 工具未来会被"内部自造工具"替代。
八、能力解锁 vs 产品迭代：Code Review 的故事
Cat 讲了一段关于"什么时候 build / 什么时候等"的真实例子：
"We've launched simpler versions of code review which is the slash code review command in the past. And it was only with the most recent models—Opus 4.5 and 4.6 and Sonnet 4.6—that we felt like 'okay this code review is so good that our engineering team relies on this code review to pass before we merge PRs.'"
（我们之前发布过简单版的 code review（/code review 命令）——但只有到 Opus 4.5/4.6 和 Sonnet 4.6 这一代模型，我们才觉得 "OK 这个 code review 已经好到我们工程团队会等它通过才合并 PR"。）
她由此提炼的产品方法论：
"It's pretty important to build products that don't necessarily work yet so that you know what is missing for this product to work. And then with the newest model you can just swap it in to the prototype you've already made and see does this new model close that gap."
（很重要的一件事是：建一些"今天还不 work"的产品——这样你才知道"这个产品要 work 缺什么"。然后新模型出来时，你直接把它塞进你已经造好的 prototype——看新模型是否填上了那个 gap。）
对所有 AI 产品创业者的启示：不要等模型能力到位再开始做。今天就造出"勉强能跑的版本"——把所有非模型瓶颈先解决掉——下一代模型出来时你比所有人提前 6 个月。
九、完美主义的力量：95% 不是好
视频后段，Cat 提到一个逆向洞察——很多 PM 满足于"95% 自动化"——她反对：
"There's just not much value in a 95% there automation. ... You really need to give it feedback so that it can improve its skill so that it can get to that 100%. And then really then you'll be able to rely on it."
（95% 自动化的价值真的不大。你需要给它反馈，让它持续提升直到 100%——只有到 100% 你才能真正依赖它。）
为什么 95% 反而是陷阱：
- 95% 意味着 你还要 100% 注意力监督它做对
- 你节省的不是时间，是把"做"换成"看着它做"
- 真正的解放只有当它 100% 可靠时才发生
她举了自己的反例：教 Cowork 做 Gmail inbox zero——一直没成功。Lenny 也分享他自己 95% 准确的 spam 分类器——结果漏了重要邮件反而更糟。
这条原则的延伸应用：任何"自动化任务"如果不能做到 100%，最好的策略可能是不做自动化。要么投入打磨到 100%，要么不要假装它在自动化。
十、Cat 的 4 条"在 AI 时代保持清醒"的建议
视频末尾，Cat 给 Lenny 留下了一份给所有 AI 时代工作者的清单：
1. 用每天必用的产品做 prototype
"I would really push people towards building apps that you're actually using every single day because I think only through that usage are you actually getting the value."
（真正用起来的产品才能教你东西——只有亲手用的，你才知道哪里不行。）
2. 接受混乱，找团队里能"对挑战微笑"的人
"Our team is full of people who lean into the chaos. We try to face every challenge with a smile because there's always so much going on. ... We really look for people who can look at a challenge, be like 'that's going to be hard but I'm excited to tackle it.'"
（我们团队都是"扎进混乱"的人。永远有那么多事在发生——如果你太焦虑就会 burn out。我们找那些能看着挑战说"很难但我很兴奋"的人。）
3. 30% 时间用在"推产品边界"
像 Cat 自己那样——30% 时间不是产出工作，而是用 AI 工具推它的能力边界——这是 PM 的研发投入。
4. "Just do things"
视频末尾 Lenny 问 Cat 最常用的 motto 是什么——她答："Just do things"。简单但关键——AI 时代最常见的失败不是"做错了"，是"还没做"。** 先做、再优化**。
行动启示：今天就能动的清单
- 审视你最近一次"PRD" —— 它能不能直接喂给一个 AI agent 让它实现？如果不行——你的 PRD 是给人看的，不是 spec。在 AI 时代它会被淘汰。
- 建立你的"第一个 eval set" —— 选你正在用 AI 做的一件事（写邮件 / 写文案 / 做总结）→ 准备 5 个测试案例 → 用不同 prompt 跑一遍 → 看哪个 prompt 真稳。这是新 PM 的肌肉。
- 接入一个长期上下文助手 —— 把你的 Calendar / Email / Notes 接到 Claude Cowork（或 GPT 类似工具）。至少花一周让它"认识你"——之后你才能体会到"长上下文助手"和"短窗口聊天"的差距。
- 造一个"今天还不 work 的产品" —— 选一个你想做但模型能力还差点的功能 → 今天就用现有模型造出一个"勉强能跑"的版本——下一代模型出来时你已经在前面。
- 设一个 100% 标准 —— 任何你正在做的"自动化"——问自己"95% 够吗"。如果不够——立刻投入到 100%。否则就别假装在自动化。
- 实践 Just do things 的反向操作 —— 列出你"想做但还没做"的 5 件 AI 探索 → 今天选一件 30 分钟内开始。
- 找一个能跨所有产品线的"使命语句" —— 不论是公司还是个人——一句高于所有具体产品 / 项目的使命——它会替你做掉一半的决策。
报告作者的延伸判断
1. Cat 这场对话最值钱的不是技巧——是观察方法论。她反复说"30% 时间在推边界"——这是研发型 PM 的特征，不是执行型 PM。中国大多数 PM 还在"执行 PRD"模式——用 30% 时间研究模型能力这件事，** 95% 的中国 PM 团队连 5% 都没做到**。
2. "Research Preview 标签"是被严重低估的产品工程发明。它表面看是个 UI 标签——本质是期待管理的工程化。任何 SaaS / 工具产品都能学。做这件事的成本接近 0，回报接近无限——但需要管理层授权"小步快发"。
3. Anthropic 招的 PM"低自我"这一条值得划重点。视频里 Cat 说她希望 PM "low ego about what work they do to help the team move faster"——翻译成中文就是"愿意打杂的 PM"。这不是贬义——这是 AI 时代的稀缺品质。坚持"我是 PM，不该写文档/不该做 deck"的人，会被快速淘汰。
4. "AGI-pilling 的恰当度"是这场对话里最适合做模因的洞察。它可以扩展到所有变化剧烈的领域：
- 加密：信仰 BTC 不能太早，不能太晚
- 新能源车：信仰电动化要正好早 5 年，不能 10 年
- 远程办公：信仰它要正好早 3 年，不能 7 年
所有"早一步是先驱、早两步是先烈"的领域，都需要 calibrated belief。
5. Code Review 的故事——揭示了一个比"模型能力"更深的产品规律：很多产品的"成立时刻"不是单点能力的提升——是好几个能力同时跨过阈值。Code review 等了 Opus 4.5 + Opus 4.6 + Sonnet 4.6 三步同时到位才能用——这意味着预判产品成立的窗口期需要"多曲线交叉"思维——单看一个模型的迭代曲线会错过。
6. 一个值得警惕的 Anthropic 口径偏差——Cat 全程极少谈"竞争"——只谈"使命""速度""产品"。这是大公司的优雅叙事方式——但读者要意识到 Anthropic 同时在打一场和 OpenAI/Google/Meta 的残酷战争。她说"使命让决策快"是真的——但生死压力让决策快也是真的——她没强调后者。
7. 这场对话的隐藏赢家是 Cowork —— 整个视频里 Cat 提到"Cowork"的频率几乎和 "Claude Code" 持平——但中文圈对 Cowork 的认知几乎为零。这可能是 Anthropic 接下来 12 个月最被低估的产品。如果 Cat 说的"非代码输出场景的杀手"成立——它会和 Notion / Slack / Microsoft Copilot 正面竞争。
附录：金句收录
-
"It is very hard to be the right amount of AGI-pilled." （"对 AGI 信仰的恰当度"非常难拿捏。）
-
"The timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to even one day." （很多功能的发布周期从 6 个月缩到 1 个月，有时 1 天。）
-
"As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write." （当代码变得很便宜——决定写什么变得更值钱。）
-
"LMs are so general that actually creates a lot of ambiguity in who we're building for." （LLM 太通用了，反而让"我们在为谁造"变模糊。）
-
"Set clear queer goals." （目标要清晰得近乎冷酷。）
-
"PMs and designers are squeezed because engineers are moving so fast." （PM 和设计反而被挤压——因为工程跑得太快了。）
-
"Humans still provide a level of common sense that the models don't." （人还能提供模型缺的那种常识。）
-
"We hire people who care most about bringing safe AGI to all of humanity." （我们雇最在乎"为人类带来安全 AGI"的人。）
-
"Because we put this mission above any individual product line, we're able to make very fast decisions that cut across the entire org." （因为我们把使命放在任何单个产品线之上，我们能跨组织极速决策。）
-
"30% of my time is pushing the boundaries of what Cowork can do so that I have a very strong sense of what we're not good at." （我 30% 的时间在推 Cowork 的边界——这样我才知道我们哪里不行。）
-
"It's pretty important to build products that don't necessarily work yet so that you know what is missing." （很重要的一件事是建"今天还不 work 的产品"——这样你才知道缺什么。）
-
"There's just not much value in a 95% there automation." （95% 自动化的价值真的不大。）
-
"I would really push people towards building apps that you're actually using every single day." （真正用起来的产品才能教你东西。）
-
"Just do things." （先做就对了。）
时间线索引
[00:00]开场：1 天发布、AGI-pilling 的恰当度[02:00]Cat 角色介绍：Head of Product, Claude Code & Cowork[07:05]三件套机制：清晰目标 + Research Preview + 跨职能默契[14:10]Anthropic PM 团队结构：30-40 人，5 大类[18:00]为什么 PM 不会被砍——反而在扩[21:15]人脑在 AI 时代的 4 个核心价值[28:20]Anthropic 成功的根：统一使命作为决策操作系统[35:25]Cowork 的存在意义：非代码输出场景[42:30]Internal Tools 爆发：销售员自造定制 deck 生成器[49:35]Token 花费 vs 工资：模型升级 → token 消耗升[55:00]AI 时代 PM 的 4 项新核心技能[56:40]谁是 Anthropic 内部最强 evaluator：Amanda + Claude Code 团队[63:45]Code Review 的故事：等模型到位的智慧[70:50]完美主义法则：95% 不是好[77:55]Cat 个人收尾：Whimo、just do things
评论
还没有评论，来第一个留言吧 ✨