面向PM的Claude完整课程

• 全片中心论点：「There's no good reason to talk to Claude just over a normal web chat anymore」——Pavel 私下对 Aakash 说过、被后者形容为「最疯狂的一件事」的话，Aakash 预判它「会让很多产品经理大吃一惊」。→ 详细
• 嘉宾 Pavel Hern：欧洲排名第一的 AI PM 之声，LinkedIn 超 20 万粉、newsletter 超 10 万订阅；本期是他第四次上节目（创纪录）。此前最火那期即兴上了整堂 AI 产品管理课，播放量超 6.5 万（频道史上最受欢迎）；还有一期 n8n 视频超 1 万播放，更早做过一堂 discovery 大师课。关键反差：他本是工程师、用 terminal 完全没问题，却把大量日常搬到 Claude——所以他讲「别用 chat」是真比较过。标志性比喻：只用 chat 就像「只用 Photoshop 来裁剪照片」，手握强大工具却只用最浅一层。本期承诺教你像 Anthropic 那样从头重设计流程、把生产力提高十倍。→ 详细

• Pavel 引 Aakash newsletter 的数字：Anthropic 52 天发布 74 个版本、16 个月从 10 亿做到 300 亿估值，「令人震惊」。但关键不在数字而在做法：这些公司「不是用 AI 去替换流程里的某些步骤，而是围绕『当下能做到什么』来重新设计整个流程」——全片方法论母题：别拿 AI 补旧流程的洞，要按新能力把流程整个重画。角色在靠拢而非合并：PM、产品营销经理、设计师、工程师彼此靠拢，做原型/测试/发布说明/基于设计系统设计界面「现在全都在被自动化」。→ 详细
• PM 如鱼得水的三个硬条件：① 懂技术；② 对传统上为工程师设计的工具（他点名 terminal）变自如；③ 走出舒适区理解战略——「理解自己的工作如何为业务带来收入、如何跟业务目标和产品战略挂钩」。未来属于「super PM / super individual contributor」——拥有跨多领域技能，而非「只会访谈客户、然后在 backlog 里创建条目」的 PM。Aakash 补刀：入行 16 年多，见证这行演变超常，现在这版「最贴近产品『裸机层』」、也是「产品管理最有意思的一个版本」。→ 详细

• 续聊墙：在 chat 里开工到一半得离开电脑——你「没法继续」，「没法把整段聊天记录复制到另一个窗口、再开一个远程会话续接」，更没法在手机上接着干。→ 详细
• 能力墙：干着突然「想写点代码」chat 做不到；想「做一个 HTML 页面，导出成信息图，再放进邮件里」也办不到，只能「再开一段不同的会话、带着不同 context 把前情重讲一遍」——这种「换工具就得重讲」的摩擦正是他从 Cowork/Dispatch/Code 起手的核心理由。Pavel 诚实交代并非完全不碰 chat（「说我完全不用 chat 是撒谎」），偶尔问个「这句话语法对不对」的小问题，但「大多数时候你开始一段会话时并不知道自己具体会需要什么」，故默认从 Cowork / Dispatch / Code 起手、再自由切换。→ 详细

• Chat：「像一个带各种工具的聊天机器人，类似 ChatGPT」，能起草邮件、扮演人物、总结信息、有时跑个简单脚本回个表格——「都是很基础的东西，除此之外没什么复杂的」。Cowork：关键词「处理真实文件 + 执行工作流」（例：整理桌面发票、做 HTML 信息图），能「规划长时间运行的任务」（五步六步七步逐一执行），还能派 subagent 并行——他给的完整例子：写一封邮件、要总结产品战略、附一份转 PDF 的演示文稿，就「一个 agent 去总结战略，一个去做 HTML 信息图转 PDF，一个去 CRM 找人资料」，主 agent 收回结果、重放某步、收尾；Cowork 跑在虚拟机里——这是它和 Code 的分界。Claude Code：「跟 Cowork 一样，只不过在写代码」，能在你真实机器上执行脚本/系统命令，「专门为跟代码库打交道调校过」，插件是为前端/数据库/调试而非知识工作。→ 详细
• 给非技术 PM 的劝诫（原话对答）：「Code 看着吓人、IDE 看着吓人，我能不能直接跳过？——不行，因为工程师会用 Code。」Aakash 加码：「作为 PM 你应该去学 Claude Code，我怎么强调都不为过。你得先迈过『这看起来不太友好』那道坎，但 Claude Code 真的超级强大。」→ 详细

• 先划边界：处理文件、分析信息、整理一个能自我改进的知识库这些「都可以在 Cowork 里做」，「Claude 几乎什么都能做」。差别在三处：① 没有 explorer 文件浏览器视图（只能拖拽或选中单个文件，主题 15 展开）；② 不能定义固定 subagent 人设（只有 Code 能定义「研究员」「负责测试的 agent」「负责写发布说明的 agent」等固定角色，Cowork 只能调用动态 subagent）；③ hook 在 Cowork 里不起作用（hook 是「Claude Code 特有的、跟操作代码库特有的」，在执行流程某节点强制插入固定逻辑）。结论：「作为一个跟工程师协作的 PM，你终归要用 Claude Code。」→ 详细

• 演示：桌面一个「装着发票的文件夹」，攒了两个月的随机发票——点名 Atlassian 发票、Postmark 二月发票、一张波兰语加油发票。指令：「整理、分析这些 PDF 发票，按月份（Jan、Feb、Mar…）分文件夹，还有重复文件——文件名可能不一样但内容相同，它得自己想办法处理。」Cowork 列步骤：提取日期 → 用哈希函数识别删重复项 → 建月份文件夹移文件 → 最后验证。Aakash 点题：「为什么 Cowork 基本总比 chat 可取——它实际是在操作你文件系统里的东西。」→ 详细
• 结果与惊喜：创建了 April/February/Jan/March 四个文件夹、删了几个重复项；最妙是他只让处理 PDF，它「还处理了图片」——那张波兰语加油发票是图片格式，它理解到「也许 Pavel 自己都不知道里面有图片，那我们也把它们移过去吧」。Aakash 调侃：「现在能读图的可不止 Gemini，Claude 也行。」CLAUDE.md 首登：本例里文件没特别指令，但若存在就是那个写着「在这个文件夹里工作时」自定义指令的 CLAUDE.md。落地玩法：准备一个 inbox 文件夹，「每当出现新文件这个流程就重复一遍」——一次配置、长期自动归档。→ 详细

• skill「像一套操作流程」，激活是被动、按任务匹配：「一个 skill 有一段描述，agent 据此判断——这个 skill 是讲怎么处理 PDF 的，而我正在处理 PDF，那就看看里面有什么——然后才去读详细指令」。这套机制叫 progressive disclosure：「你可以有几十上百个 skill，Claude 只在某 skill 描述跟你当前想做的事匹配时才读它的详细指令」——先读「目录/简介」，对上号才翻「正文」，避免一次性把上百份手册塞进有限 context。skill 不只是文字，「里面也可以带要执行的脚本」，Cowork 能在虚拟机里跑起来。→ 详细

• 连接外部/本地服务「最流行的格式就是 MCP server」，比喻是「相当于 agent 的 USB 接口」；「在 Claude 里它们叫 connector」。已有连 Google Drive/Gmail/Slack 的，「还有几十上百个」，一部分 Anthropic 提供、一部分别人做。现场演示：连上 Gmail 问「我有多少封没回的邮件」，并当场加护栏「不要泄露任何个人信息或邮件内容」（在播客上直播真实收件箱）。→ 详细

• Pavel 真实配置：所有回复由 Claude 起草，但不自动发送（用「默认的、不能发送的 connector」，也可接能替你发的）。Slack 同理，且「理论上能自动回复，但会有一行『由 Claude 发送（sent by Cloud）』页脚大家都看得到」，所以选择「让它起草、由我核对」；日常「有人来问个网址我就直接批准或改一改，界面里有个『发送』按钮手动发」。埋伏笔的关键习惯：「每次会话结束后，Cowork 或 Code 会复核我的回复、从中学习，下次就做得更好」——不是重复劳动，而是持续给系统喂示范（后文「自我改进系统」的雏形）。→ 详细

• 开源仓库 phuryn/pm-skills 爆火：Aakash 报「72 小时 1300 个 GitHub star」，Pavel 当场更新「现在已经一万个 star」。三层结构：plugin = 一堆 skill 和命令的合集（按领域分——数据分析、go-to-market、市场调研，可单独上传安装）；每个 plugin 内含多个 skill（以产品探索为例：分析功能需求、头脑风暴、规划实验、设定追踪指标）；最上层能定义把多 skill 串起的 workflow——他描述整套产品探索 workflow：「分析客户需求 → 映射机会点（问题多重要、对现有方案多满意）→ 构思 → 梳理价值/可用性/可行性/商业可行性/伦理假设 → 规划实验验证或推翻」，「一条命令就是一整套产品探索工作流」。安装路径（他念叨「这界面一直在变」）：Customize → Personal plugins → Add marketplace → 粘完整 URL（提示「owner/repo 那种写法好像不管用」），点进去就能看到 Ansoff 矩阵、定价战略等 skill。→ 详细

• 理论上 skill 自动激活，但 Pavel 强烈推荐用斜杠命令显式触发。原因（讲清因果）：「有时候 Claude 对某个领域有通用知识，觉得自己懂，但你想覆盖掉它这部分；如果不明确指出，它就可能退回去用训练数据」——模型「自以为懂」会用泛泛答案盖过你精心定义的方法；显式调用后出来的才是你那套（「写『Google 产品战略画布』时，出来的是我创建的那一版」），加载后「它会先采访你获取更多信息，但这整个过程都是 skill 的一部分」。Aakash 的「市值蒸发」轶事：Anthropic 出过一批著名 plugin，「最主要那个当时算传奇——好几亿美元市值从股市蒸发，就因为人们意识到把某些流程描述出来、自动化掉多容易」；技术底气：「只要有一份由领域专家写好的规范 markdown，现在 Opus 4.5、4.6 就能真正用好 PowerPoint、Excel、Notion、Google Docs——只要给对指令就能像称职的人一样操作」。（注：transcript 此处说「主要那个像是 legal/法律」相关，可能是听写歧义，核心论点是「流程一旦能被文字描述就能被自动化」。）→ 详细

• 不用手写：判据「只要你能教会一个应届毕业生怎么做某件事，你把同样的话讲给 Claude，它就能创建出一个 skill」，他自己「一般不打开看里面，就用聊天界面跟 Claude 对话」。文件结构：主文件 skill.md（可放附加文件），开头一段「agent 会读的元信息」——名称、描述、什么时候用、干嘛的，「它们不会加载整个 skill，只加载这段元信息」（渐进式披露在文件层面的体现）。「何时用」示例措辞很具体：「在压力测试一个未来想法时使用」，于是用户写「我想测试这个想法、评估风险」，agent 就触发它。正文就是一个 prompt：可以是通用知识，也可以是「第一步从 A 处取信息、第二步按格式整理、第三步做某事」；以「识别假设」skill 为例，context 设成「你是一个唱反调的人（devil's advocate），我们在压力测试一个想法」+ 论点 + 分步指令。skill 内还能做软营销：「如果有人想了解更多，agent 会推荐我那些关于识别假设的文章——像 skill 内部的营销，但跟用户当下想做的事高度相关」。→ 详细

• Aakash 的核心方法论（几乎逐字）：把 Pavel 的 skill 当基线（baseline）——「这样你至少有个底子；然后当你遇到关于这个 skill 的反馈时，把反馈给 Claude，说：『我想让你改进我那个「识别现有假设」的 skill。读一下我们的聊天记录，看看我给你的反馈，搞清楚是什么根本原因（root cause）导致你给出那个让我不得不提意见的输出，然后从第一性原理（first principles）出发重写这个 skill，让它不再犯那个错。』」他给出最高级别背书：「我发现这是我做的投入产出比最高的单项活动（the single highest ROI activity I do）……一旦你拿到初版 skill，你得真正去迭代它，才能榨出它的 ROI。」→ 详细
• Pavel 的呼应与「像做 eval 但不必真建 eval」的关键澄清：他先抛金句「我从不背 prompt（I do not memorize prompts）」，再类比到 eval——「就像在做 eval 一样，搭建某个 AI 系统、AI 流水线时，你得看它在真实场景里表现如何，然后找出它的失败模式（failure modes）」。但他随即降门槛：「在这个场景里你不用真去建一套 eval，只要给 Claude 反馈、告诉它哪里错了就行——它能理解上下文，因为它已经有了这个 context；然后它就会修好，你再测一遍、再测一遍，最终大概能消除 99% 的失败。」最后一句斩钉截铁：「这就是唯一的办法，你没法干坐着、靠什么神奇技巧一次就搞对（you cannot just sit and use some magic technique to get it right on the first try），根本不是那么回事。」→ 详细

• 触发：Pavel 只下一句「设计产品战略（design product strategy）」，它就同时加载两个 skill——Anthropic 内置的 PPTX skill + 他 plugin 里的产品战略 skill，「用这两个生成幻灯片」。产出（一张「Amazon 产品战略画布」，逐格）：产品愿景；市场细分（有环保意识的客户、独立品牌、相对成本）；权衡取舍（我们想说「不」的那些事）；关键指标（NPS、客单价、卖家留存率）；北极星 + 护栏（护栏逻辑「聚焦北极星时该监控什么防止其他领域退化」，例：碳中和配送率）；各细分的增长战略与单位经济。视觉上「配色/布局/图标都是 Claude 自己发挥，不是我的品牌色」「不是单一布局、多样布局多样图标」。Pavel 感慨「让应届生做，我不确定能在几个小时内拿到这种成果」。→ 详细
• 两个「炸裂洞察」（Aakash 原话）：① 「现在你再没借口带着一份糟糕的 PPT 去开会了（no excuse to walk into a meeting with a bad presentation anymore）」；② 它真落实了 skill 里定义的结构（北极星、护栏「都实现了」）——「这就是为什么只要有一份好 skill 就能一两分钟得到麦肯锡级输出，大家会说『rip McKinsey』」。规模：Pavel「已定义 60 多个 skill」，「外面还有几百上千个别人定义的」。安全提醒：「凡不是 Anthropic 定义的 skill，每一个都要核实一遍，确保契合你具体的用例」。→ 详细

• Aakash 发问「Cowork 够用了吧，为什么还需要 Code？」Pavel 两个理由：① 「Cowork 不适合处理代码库，而作为 PM 你会大量跟代码库打交道」；② 「搭建涉及多个文件的复杂系统时，Cowork 这种视图不适合」。痛点具体：想找刚生成的 PPT，只能点「在文件夹中显示」再专门去找。放大：「想象我有几百个文件——各种发票、承包商、合同、文章草稿、营销策略、图片、品牌指南，按层级组织，而 Cowork 里没法浏览，只能拖拽或选中单个」——这正是 Claude Code 的 explorer 视图所长（能展开文件夹看里面有什么）。现场演示层级：infographics → Cloud Code Pricing → Claude 生成的文件（「今天发在 newsletter 的图」和「带日历那张当时挺火的图」，「都是 Claude 生成的，不是我做的」）。→ 详细

• 两种入口：Pavel「在 Visual Studio Code 里用 CLI」，也可用 VS 扩展，「两者都差不多，都不算特别好上手」（呼应「先迈过看起来不友好那道坎」）。反复强调的工作姿态：「我一行代码都不写，连代码都不审（I don't write any code, I don't even review the code）。如果想知道某个东西怎么运作，我就在聊天窗口直接问」——用 Claude Code 不等于要会编程。→ 详细

• 灵感来源：「最近 Karpathy 展示了这么一套系统——你用 LLM 给人类构建个人 wiki 或知识库：把随机文章、附件、文档丢给 agent，它帮你组织起来，然后你能浏览、看不同事实怎么关联。」Pavel 的反转是核心创新：「我从 2026 年 2 月就开始做，但我不是给自己建第二大脑，而是给我的 agent 建第二大脑——我是信息的策展人（the curator of the information）。」→ 详细
• 起步做法（很具体）：他「在社交媒体上做截图」，把文章、信息图喂给 agent（「那会儿还用 Cowork」），问「是什么让这条帖子火了？是什么让这张信息图奏效的？」也可下更结构化的指令，如「分析 Aakash 最近 10 条、超过 200 个互动的帖子，看它们为什么有效」，关注「语气、钩子、情绪」；agent「有时知道答案，有时给一个假设」。**从「自己记」升级为「让 agent 记」**是关键转折：「与其自己手动记录，不如让 agent 来做。我跟它说：『建一个知识库吧，以后每次我给你一篇文章或一张信息图，按领域帮我归类。』」这里领域是社交媒体，可细分成 X、LinkedIn、Substack。最妙的是写规则的判据：「如果你看到重复出现的模式，就把它存成一条规则（rule）；如果你不确定，就先存成假设（hypothesis），以后分析更多数据时再验证。」→ 详细
• 沉淀出来的知识库长什么样（他逐项展示）：sound bites（金句）——创作者常用、基于数据在各平台通用的核心模式；核心技巧，如「interpretation layer（解读层）」、「先建立可信度再谈观点」（后者「在多个平台、所有创作者、所有成功帖子上都得到验证」）；用词选择；一份跨平台假设清单和被否决的条目（「过去考虑过、现在知道是错的也会记下来」）。两条具体假设：「『把成就作为佐证的钩子』优于『把成就作为重点的钩子』（achievement as proof hooks outperform achievement as point hooks）」、「『情绪多样化』与更高平均互动量相关」——后者编号 46，他当场感叹「这些都不是我自己总结的假设，我之前甚至没见过，这一条我现在还是第一次看到」，凸显系统真在自主产出他没想到的洞见。重要边界（防误解成「AI 代笔」）：「这并不意味着它替我写。我给的是原始知识和原始观点（raw knowledge and raw opinion），是我对某条具体新闻的看法；然后 Claude 再去调整格式、风格、钩子，让它适配信息、适配平台，跟别人产生共鸣。」→ 详细

• 那张爆火信息图——「搞定了 Anthropic 的 logo、搞定了八个人的脸，甚至把数据从 Twitter 上扒了下来」——「完全是 Claude Code 做的，是基于研究生成的 HTML」。Pavel 反复强调反直觉的点：「最难的部分就是研究本身（the most difficult part was the research）」，即从 Twitter 扒信息，而不是画图。数据获取的成本意识：「我付费用 X API」；为什么不全免费——「很多情况下可以免费抓取，就那个 FX Twitter 之类的，但有限制、不是每次都好用」（演示时正好报错），所以「为省成本，agent 默认先用免费的，不行再用我们一起开发的自定义工具」；而「一起开发」极简：「我就是给了它 Twitter API 的文档，它就自己给自己造了个工具（it created the tool for itself），把这个 API 包装成很好用的东西」——agent 自己造工具给自己用。→ 详细
• 人脸信息图的完整流程（一步步还原）：① 让它写脚本；② 从「本来就知道的免费 Anthropic 账号」出发；③ 「分析他们最近的帖子和转发，我假设他们最终都会互相转发每一位 Claude Code 团队成员的内容」；④ 「分析哪些成员用了『我们/我们刚发布了/我团队刚发布了（we / we just released / my team just released）』这种说法」；⑤ 「如果不确定，就去核实评论区，确保这个人确实是 Anthropic 员工」；⑥ 这样「过了大概 15 个 Anthropic 的人，针对每个功能映射出是谁最先写到它的」；⑦ 「对这些人从 X 上拿了头像」；⑧ 「反复迭代好几次琢磨怎么可视化」。另一支线（处理图而非人）：喂信息图 →「专挑容易用 HTML 编码出来的」→「提取可复用组件（reusable components）」→「用这个不断增长的组件库设计新信息图」。平民化收尾：「说到底你只是用自然语言跟 Claude Code 聊了好几个小时，这对别人也不是做不到。我完全不写代码。」（演示中还读了一段 agent 对 Aakash 帖子风格的分析——「纯粹的分析师口吻、话题极度多元，哪个浪头大就冲哪个，因为『揭示机制』的模式可迁移到食品科学、神经科学、物理学；前十条帖子里只有两条是科技类」，活生生展示知识库能产出多细的洞察。）→ 详细

• 反模式（很多人在犯）：「很多人讨论 CLAUDE.md，说可以把指令放进去。但问题在于，如果你把所有指令都塞进去，它会不断变大——可能不是指数级，但会越长越大，最终吃掉你大量的 context window；而且每次你在项目里发一个简单 prompt，整个 CLAUDE.md 都会被带上——它是你 prompt 的一部分。」大白话：CLAUDE.md 越胖，你每问一句都要先「背诵」一遍这本厚书，又慢又贵又挤占注意力。→ 详细
• 正确做法：「把你的知识组织到一个个专门对应某个领域的文件里。」主 CLAUDE.md「唯一目的就是说明这个项目是干什么的，不包含详细指令、不包含好做法坏做法的细节；所有这些都在其他文件里，CLAUDE.md 的唯一目标就是告诉 agent 怎么去找到这些知识、以及拿到新知识后该怎么处理」。他的主 CLAUDE.md 含四块：项目结构（让 agent 不用扫描整个 repo 就知道有哪些工具和脚本）、东西放在哪里、我是谁、以及最重要的知识系统。一个反复出现的元细节：「顺便说，这也是 Claude 写的，不是我写的——我不会在聊天里讨论我们怎么组织东西，是 Claude 自己给自己写指令（Cloud writes instructions for itself）。」→ 详细

• 知识系统的内部构成：所有文件的索引（X 文件、LinkedIn 文件、Substack 文件、Substack notes 文件）；跨平台通用知识（voice archetypes「声音原型」、craft「手艺」）；每个平台各自「不同元素放在哪里」；以及「系统应遵循的 workflow——怎么为 Twitter 抓数据、怎么处理 LinkedIn 帖子、怎么处理 Substack」。→ 详细
• 最关键的「当被要求研究/分析时（when asked to study and analyze）」流程（逐步还原）：每次他给它帖子（「研究一下最近 100 条帖子」或「我喜欢这条，分析它为什么有效」）→ 它「知道该用哪些工具」，去提取钩子、模式、结构、金句、互动指标→ 只有明确要求做视觉分析时才去分析附带的图片（为省 token，不是每次都分析图）→「对照已有的模式和『错误信念（false beliefs）』做检查」→「有现成假设就用新证据更新；若发现这条帖子没奏效，就给这个假设降权（demote），或直接变成被否决」→「把分析过的帖子追加到数据库里」。系统的自主性与人机分工：「这套系统是自己在学习，不需要我去告诉它某条内容为什么有效，Claude 自己就做了。」而当 Pavel 表达观点（「我喜欢这条，但我觉得它跟另一个想法有联系」，或「我喜欢 Karpathy 这条，但它会随时间贬值」），「Claude 就用我的想法、我的标签，但用一种能引起共鸣的方式重新排版」。他还补一句很妙的话——「你不需要 Obsidian——如果使用者不是真人的话（you don't need Obsidian if the user is not a person），因为我们是在为 agent 构建知识库」：给人看的漂亮界面对只读纯文本的 agent 毫无意义。→ 详细

• Aakash 替观众发问：「这套太偏内容了，对一个不写代码的 PM 有什么用？最小可行的搭建方案是什么？」Pavel 说他「专门为这个做了一张海报」，主题是「怎么创建一个能自我学习的知识系统」，并强调「这个 prompt 非常简单，你不需要把我做的全套都搭出来，从这个 prompt 开始就行」。→ 详细
• 可直接粘进 CLAUDE.md 的核心 prompt（接近原话）：「在开始一个新任务之前，先回顾一下这个领域已有的规则和假设（review existing rules and hypotheses for this domain），然后默认应用那些已被确认有效的规则。」Pavel 特别点出它的普适性——「这就是你需要粘到 CLAUDE.md 里最重要的那部分，而且它跟具体内容无关（this is not content specific）」：无论 Claude 在测试软件、写营销材料、还是写发布说明，都让它先回顾该领域的规则与假设、再把确认有效的规则用上。PM 的落地场景（把抽象翻成日常活）：你先喂一批示例——「一个好的测试用例长什么样、好的用户故事怎么写、验收标准（acceptance criteria）该怎么写，或发布说明、客户报价的好坏例子」——它就「去尝试提取出规则」；下次你说「给这个新客户再做一份报价」，它会「回顾已有的规则和假设——因为这些不是你写的，是它根据看过的数据推理出来的」，并且「持续学习，每次给它新信息都更新知识和假设，如果有什么地方可以由人给反馈，它还会反过来问你问题」。知识「按领域组织——定价、营销、测试、质量、策略」。→ 详细
• 配置形态与可扩展的喂料：「你要做的就是创建这样一套知识、配上一个带路由的 index.md（an index.md that has a router），然后在 CLAUDE.md 里给它上面那段 prompt，这样它就能自我改进。」其他可喂的数据两例：「那些成交过的报价（the offers that worked）」、以及「成功候选人的简历（resumes of successful candidates）——它就会开始生成规则，下次再来一个候选人，你就可以问 Claude『这是个好候选人吗？』」→ 详细

• 结论先行：Pavel 已经不用 Chrome MCP 了。 它「本质上就是一个控制你浏览器的 MCP」，运作跟 Claude in Chrome 差不多（后者是 Anthropic 的浏览器扩展）。致命问题：「这些扩展高度依赖截图，而截图意味着大量 token。如果任务要定期重复、或是复杂流程，你很容易一小时就烧掉 100 美元，尤其用 Opus 时」，而且「屏幕上还能看到它在动」。替代方案：Vercel Labs 的 agent browser（命令叫 agents dev），「根据我的测试是最可靠的」：同样用真实浏览器真实渲染，但能在无头（headless）模式下运行；「把页面的结构解释给 agent 而不用呈现整个 HTML」，「能看到带特定 ID 的按钮，哪怕原始按钮本来没有 ID（会替它补上 ID）」；需要时执行 JavaScript；「它会等待渲染完成——单页应用或几秒后才加载的资源它会等」。总价值：「它把页面呈现给 agent 但不用截图，所以省 token；它不是 MCP，是个 CLI 工具，协议非常简单。」使用场景：「基本上就是所有那些你没有 API 能从外部系统取数据的场景」——个人（去 LinkedIn 看收件箱、分析 Aakash 帖子评论）、企业（访问没 API/MCP 的遗留软件如 SAP、老 CRM）。Aakash 的行动纲领：「作为 PM，你得把 Claude Code 接到几乎所有东西上（hook your Claude Code into absolutely everything），没有 MCP/CLI/API 可接的就用 agent browser。」→ 详细

• Anthropic 最近几个月发布了四种远程入口：web sessions、remote control、Dispatch、channels。Pavel 先坦白「Anthropic 有个问题，就是这些入口彼此重叠（overlap），我用它们的比例也不一样」，并明确已弃用 channels：「测试过但弃用了，我没看出价值——搞这么个 Telegram 式界面，因为我已经有一个专门的 Claude 频道，在那儿什么都能干。」→ 详细
• Dispatch 详解：它是「桌面端 app 里新出现的一个标签页，手机上也有、一模一样」。易混点提醒——「它显示在 Cowork 下面有点让人困惑，但它其实是一个完全不同的产品」。比喻是**「对讲机（walkie-talkie）」：「它可以启动多个后台任务，每次任务完成时都会回报当前状态。」现场演示连发两个任务：①「用 Anthropic 风格为下面这段文字（关于 board 和 windsurf）做一张信息图，LinkedIn 分辨率」；②「过去 2 小时里我收到了多少封邮件？不要名字、不要个人数据」——「它不需要先结束上一个任务，会直接再启动一个」。机制：「它把这些任务委派给不同的线程（threads）/subagent**，你会在左侧面板里看到它们作为 dispatch 的任务出现，所以你可以同时启动多个 agent、用一个界面跟它们全部沟通」。他还当场拿起手机打开 Claude app，验证「在网页和手机上是同一个界面」。价值主张（Aakash 原话）：「所以真的没什么借口了（there's really no excuse）——你在外面散步、在开会、在参加会议，都可以让你的 agent 替你干活。」→ 详细

• 自报占比（先声明「不记得确切数据，三个界面都用，比例每天都不一样」）：「大部分时间我用 dispatch 和网页会话，加起来可能 70% 左右；然后 5% 偶尔用 chat，剩下的是 Claude Code。」为什么 dispatch 占比这么高：「因为我根本不带着笔记本电脑工作（I just don't work with my laptop）。我去逛街、带孩子出门，就直接 dispatch 任务。」工作模式纯反馈式——「我不写代码，只是在 chat 里给文字反馈，然后 Cowork dispatch 把结果呈现给我；我看结果、再 dispatch 另一个任务，然后继续做手头的事」。他的感慨：「这真的改变了我做事的方式、改变了我的每一天」——不必再「划出一块块专门工作的时间（blocks dedicated to work）」，生活和工作的结合「好太多了」。→ 详细

• web sessions 是另一回事：在 dispatch 里「根据你给的任务，它可以把任务 dispatch 给 Cowork」——他问「最近三条推文」，「这里就有一个 dispatch 线程，是 dispatch 在跟这个 agent 对话，但人能看到」；「也可以从 dispatch 里 dispatch 写代码的任务，它会去实现并回报」。演示彩蛋：它「甚至给你的帖子做了一张图，比如『AI 原型设计图』」，Aakash 说「挺不错的」。Dispatch 的两个局限：① 「要让 dispatch 工作，你的电脑必须在线（your computer must be online），而有时候并不是这样、会出问题、会停止工作」；② 「有时你有太多并行线程，单一 chat 界面很难管理——这里没有标签页（no tabs），手机上就是一大串消息流，没法整理」。所以做更复杂工作时切换到 Code 任务。→ 详细
• Code 任务是什么 + GitHub 同步的威力：「你可以理解成 Visual Studio Code 加上 Claude Code，只不过它在云端、由 Anthropic 托管。」它「是一个会话列表，可以选一个特定文件夹——要么本地、要么 GitHub 里的（比如我的 editor 项目）」。关键在 GitHub 同步：「所有那些文件、所有知识文件、假设、金句、钩子，全都跟我的私有 GitHub 仓库同步。即使我的笔记本电脑离线，我也可以从手机上来问它，它会在云端工作，不需要任何设备（it will work in the cloud without any device）。」Aakash 加上安全与强背书：「这其实是一种更安全的运行方式，因为它在 Anthropic 的服务器上。所以我非常非常非常推荐——你构建的一切、你所有的操作系统都放进 GitHub，通过网页会话指向它们，然后在这里干活。」需要更好组织或想专注写代码时（「比如我的 Accredia.io 平台」）就切到 Code，「主要也是在手机上做」。→ 详细

• Pavel 的答案：「最大的错误就是每次都从零开始 prompt，而不是用 Claude（去搭系统）。」他坦承组织知识对他本人也难——「我逼着自己去组织知识，这在写文章时非常困难，但 Claude 可以毫不费力地做到」。所以「与其去收集 prompt、琢磨怎么做某件事，不如直接搭一个系统，让 Claude 能从自己的错误中学习、从你的反馈或数据中学习，它能去假设、去琢磨出更好的工作方式」。把错误说到最重：「不组织你的知识、不从错误中学习、把所有东西都装在脑子里（having everything in your head）——这就是 PM 能犯的最大错误。只是来这儿、指望自己能学到更好的 prompt——要分析的数据太多了。」→ 详细

• Pavel 先纠正前提：「这不是二选一（This is not an alternative）。我会从 Cowork 开始，因为你在 Cowork 里学到的一切都会帮你更好地理解 Code。」更妙的是两者可共用同一个 repo：「我从 Cowork 和从 Claude Code 用的是同一个 repo」——他选中那个 editor 项目演示，「它有 CLAUDE.md，会看到同样的文件、同样的结构；所以我可以让它在这个界面分析推文、可以在手机上用 dispatch 做、可以在网页会话里做、可以在 Visual Studio 里做——这全都指向同一个 repo」。为什么先学 Cowork（讲清易用性差异）：「这个界面更简单，你不用去适应 explorer 和终端，更友好；你能看到文件、直接打开它们——不需要插件、不需要琢磨怎么显示 markdown 或 HTML；如果你看到 HTML，点一下它就把 HTML 展示给你。而在 Visual Studio 里，有些小窍门（tricks）是你必须得学的。」推荐路径：「先从 Cowork 开始，搞懂怎么跟 agent 协作、怎么把知识聚合起来、怎么定义工作流；等你上手了再加上终端这一块。对很多人来说，这样比那种没体验过 Cowork 就直接学 Claude Code 要更有效。」→ 详细

• Aakash 问「12 个月后 PM 的日常工作流是什么样？」Pavel：「我不觉得 12 个月后这角色会消失，但我们正走向那种超级个人贡献者型的 PM（super IC PM），顶层是 CPO、CEO。」对未来日常的描述很冷静：「大部分时间你会跟 agent 一起工作，同时编排多个 agent（orchestrating multiple agents at the same time）、不断切换上下文。这不会变轻松，工作可能甚至会更费劲（It will not be easier. The work might be even more demanding）」，但「琐碎的事会变少——写工单、调试、准备演示文稿，这些都是应该被自动化的」。谁会胜出：「发展出多个领域技能的人——比如 P 型、甚至更宽的形状（P-shaped or even broader shaped），既懂市场、战略、技术、产品，又能跟客户对话，懂得足够多以便去委派工作、评估结果（understand enough to delegate the work, assess the results）。」（注：片头「π 型人才」即此意——护城河不是某项深技能，而是「广到足以指挥与验收一群 agent」。）→ 详细

• Pavel 的判断：「我有种感觉，大家还没意识到（配上合适的 harness 和系统围绕它之后）它到底能做什么。」用自己经历佐证「低估」之深：「我跟 Claude、跟 agent 打交道已经 2 年多了，但才刚开始真正大力投入自动化和 harness，我知道我能变得高效得多。」结论金句（几乎逐字）：「我不觉得有什么是被过度炒作的——根本没有炒作，炒作得还不够（there's no hype, there's not enough hype）。所以现在一切都是被低估的（everything is underhyped right now），各位。去学我们刚才给你们展示的东西吧。」→ 详细

• Aakash 问「n8n 过时了吗？」Pavel 一个字：「不（No）。n8n 仍然很有用。」他划出两类自动化的分界。第一类·个人自动化：「为自己自动化一些事，比如『我想分析 100 条推文』『起草一封回复客户邮件的草稿』——用 Claude Code 来做」；此外「在代码库内部自动化特定流程，比如 code review、release notes、前端设计，让这些 subagent 去做，没问题」。→ 详细
• 第二类·生产级自动化（production processes）→ 不该靠 Claude Code。Pavel 的根因分析直指 harness 本质：「我们所做的一切只是在 Anthropic 定义的 harness 里编辑文本文件，agent 可能遵守、也可能不遵守。我们没法告诉 agent『如果 Anthropic API 调用失败了，重试三次』，或『做这件事之前你应该总是先验证客户邮箱存在』『客户必须有权访问这些数据』——我们只是创建文本文件，然后期望 agent 会遵循我们的指令。」（补一句「你可以用 hooks 加一些例外，但总体上我们依赖 Anthropic 的 harness 去解读我们的文本文件」。）结论：「这不可扩展、不够安全、对生产流程也不够有效。」核心原则 + 三版本案例：生产环境要「有硬性的准则（hard guidelines），而不是 prompt」——如「客户不能访问另一个客户的数据、不能删除数据」。一句话原则：「凡是不需要自主的，就不应该让它自主（everything that doesn't have to be autonomous shouldn't be autonomous）；该有代码就有代码、该有条件判断就有、该有护栏就有；如果有一个必须遵循的流程，它就该是代码——而流程里也许嵌一些 LLM 调用。」他拿实战为证：「我们用三个版本搭过同一个 agent——从最不自主的那个开始（大部分是代码、只有一次 LLM 调用），然后混合方案，最后才是完全自主的版本；这实现起来更难，但比依赖 agent 遵守指令要划算得多、也安全得多。」Aakash 总结：「要构建真正生产级的自动化，你还是会用到 n8n，尽可能多地把硬性规则定义清楚。」Pavel 补一条进阶路：「你也可以用 Anthropic API（或 OpenAI 的 agentic API 等）在代码里定义 agent 和工作流——但这跟『组织文本文件让 agent 遵循指令』不是一回事；不过对不写代码的人来说，最简单的方式还是用 AI。」→ 详细

• 0:00–0:39 片头钩子：核心金句「别再只用网页 chat」+ 嘉宾 Pavel 介绍（欧洲第一 AI PM 之声、第四次上节目、史上最火那期 6.5 万播放）。→ 详细
• 2:51–5:16 Anthropic 速度的启示：52 天 74 个版本、16 个月 10 亿→300 亿；围绕「当下能做到什么」重设计流程；PM/PMM/设计/工程角色靠拢、super PM。→ 详细
• 9:00–13:09 四工具分工 + 必学 Code：chat/Cowork/Code/Dispatch 的「如果……那就……」；Cowork 跑虚拟机、Code 在本机执行；subagent 人设与 hook 是 Code 独有；「工程师都会用 Code，所以你跳不过」。→ 详细
• 15:21–22:30 发票实战 + skill/MCP：整理去重发票（4 个文件夹、还顺手归类了图片）、CLAUDE.md 首秀、progressive disclosure、MCP=agent 的 USB、Gmail connector 现场问「多少封没回的邮件」。→ 详细

• 22:31–25:06 邮件/Slack + skill 市场：所有回复只起草不自动发、会话后自学；pm-skills 仓库 72 小时 1300 star、已破 1 万 star。→ 详细
• 25:06–31:03 plugin/workflow 与触发：plugin=skill+命令合集（按领域分、可单独装）、产品探索整套 workflow 浓缩成一条命令、用 slash 命令显式触发避免退回训练数据。→ 详细
• 31:03–35:55 skill.md 结构 + 迭代 ROI：口述即可生成 skill（能教会应届生就能教会 Claude）、元信息+prompt 结构+软营销、「迭代 skill 是单项 ROI 最高的事」、像 eval 一样给反馈消除 99% 失败。→ 详细
• 35:55–44:33 产品战略 PPT：PPTX skill + 产品战略 skill 组合、Amazon 战略画布（市场细分/权衡/北极星+碳中和护栏/单位经济）、「rip McKinsey」、PowerPoint 能力大涨、非 Anthropic 的 skill 要逐一核实。→ 详细

• 44:33–51:41 给 agent 建第二大脑：Karpathy 思路反转、自 2026.2 当策展人、按领域存规则/不确定存假设、X API 付费 vs 免费 FX Twitter、agent 拿 API 文档自造工具。→ 详细
• 51:41–55:53 爆款人脸信息图：Claude Code 全程、研究最难、15 人映射「谁先写到某功能」、靠「我们/刚发布」措辞+评论区核实身份、HTML 组件库复用、「我完全不写代码」。→ 详细
• 55:53–1:02:17 CLAUDE.md 架构 + study 工作流：别把指令塞满 CLAUDE.md（吃 context、每次都被带上）、瘦身只做路由、按领域拆文件、规则/假设随证据更新与降权/否决、Claude 自己给自己写指令。→ 详细
• 1:02:17–1:07:08 最小可行系统 + Chrome MCP：可复制的领域无关 prompt（「开新任务前先回顾本领域规则与假设」）、index.md 路由、喂报价/简历也能学；弃用 Chrome MCP（截图烧 token，Opus 一小时 100 刀）。→ 详细

• 1:07:08–1:11:00 agent browser + 四远程入口：Vercel agent browser 无头省 token、给无 ID 按钮补 ID、等待渲染、抓无 API 的数据（LinkedIn/SAP/旧 CRM）；四入口彼此重叠、弃用 channels。→ 详细
• 1:11:00–1:18:20 Dispatch/web sessions/Code 任务：对讲机式后台多任务、占比 dispatch+web≈70%/chat 5%/其余 Code、不带笔记本工作、GitHub 私有 repo 同步、离线用手机也能在云端跑、Accredia.io。→ 详细
• 1:18:20–1:24:56 经验提炼：最大错误=每次从零 prompt（不组织知识、靠脑子记）；先学 Cowork 后学 Code（共用同一 repo）；12 个月后同时编排多 agent、更费劲但琐事被自动化、P 型/π 型人才胜出。→ 详细
• 1:24:56–1:32:14 低估论 + n8n + 收尾：「一切都被低估了，去学」；n8n 没过时、个人自动化用 Code、生产级要硬规则护栏（三版本案例、凡不需自主就别自主）；Cloudathon 5/9 开课（仅 60 名额）、bundle 推广。→ 详细

本期没有独立的「lightning round」环节，但片尾有一组「关键经验」式快问快答（已在主题 26–30 完整展开），核心答案速查如下：

• PM 搭 Claude 最大的错误？ → 每次从零写 prompt，而非搭一个能自我改进、能从错误/反馈/数据中学习的系统；「把所有东西都装在脑子里」是大忌。→ 详细
• 只能学一个，Cowork 还是 Claude Code？ → 「不是二选一，先学 Cowork」——界面更简单（不用碰 explorer 和终端、点一下就能看 HTML）、可与 Code 共用同一 repo，上手后再加终端这一块。→ 详细
• 12 个月后 AI PM 的日常？ → 角色不会消失，走向 super IC（顶层 CPO/CEO）；同时编排多 agent、不断切上下文，「不会更轻松、可能更费劲」，但写工单/调试/做 PPT 等琐事被自动化，胜出者是 P 型/π 型多领域人才。→ 详细
• Claude 生态里什么被过度炒作/被低估？ → 「根本没有过度炒作——炒作得还不够，现在一切都被低估了。」→ 详细
• n8n 过时了吗？ → 「不。」个人自动化用 Claude Code；生产级自动化仍需 n8n + 硬规则/护栏（凡不需自主就别自主，能写成代码就写成代码）。→ 详细

收尾资源（片尾）：Pavel 的 Cloudathon / Buildathon 5 月 9 日开课——这一届聚焦用 Claude Code + AI + Trigger Dev 构建真正的 agent 工作流（上一届 250 名学员、用 AI + Lovable 造产品），本届仅 60 个名额；有公开作品画廊「几十个解决方案可浏览、投票、看架构、下载文档」。Aakash 的 bundle（成为 newsletter 年度订阅用户即免费拿一年多款 AI 工具付费版）：片头清单含 Maven、Arize（视频中亦写作 Arise/Evolve）、Relay App、Dovetail、Linear、Magic Patterns、Deep Sky、Reforge、Build、Descript、Speechify；片尾再点 Dovetail、Mobbin、Linear、Reforge、Build、Descript 等「九款 AI 产品整整一年免费」。→ 详细

• 嘉宾 Pavel Hern：LinkedIn（20 万+ 粉丝）、个人 newsletter（10 万+ 订阅）；开源仓库 phuryn/pm-skills（GitHub，>1 万 star，含数据分析 / go-to-market / 市场调研 / 产品探索 / 产品战略等 plugin）；Cloudathon/Buildathon 课程（5/9 开课、60 名额）；自建平台 Accredia.io。
• 主持人 Aakash Gupta：YouTube 频道「Aakash Gupta」、Apple/Spotify 播客；工具礼包 bundle.akashg.com（片尾也念成 bundle.akashsharma.com，以 bundle.akashg.com 为准）。
• 双方表示会把本期相关的 skill/repo 链接放进各自 newsletter。→ 详细