30分钟用AI智能体造产品

▲ 本期嘉宾 Claire Vo——LaunchDarkly 首席产品官、ChatPRD 创始人、《How I AI》播客主持人，被称为「最高频用 AI 的产品负责人」。

• 嘉宾是「独一无二的 Claire Vo」，身兼三职：LaunchDarkly 首席产品官（CPO）、ChatPRD 创始人、《How I AI》播客主持人；主持人 Peter Yang 重背书「可以说没有哪个产品负责人像 Claire 这样高频地用 AI」，且 Claire 是他第一个正式采访过的嘉宾。这期的玩法是「反着来一遍 How I AI（the reverse How I AI move）」——平时嘉宾来她节目演示，这次她在 Peter 的节目里共享屏幕当场演示，范围是「其实就是我们在 ChatPRD 真实的做法」+ 聊 AI 怎样改变 PM 这职业。冷开场先剪了三句后面才展开的核心观点（产品经理已死「不是唱衰」/ Devon 本质是「语言界面」/「恭喜，我刚给你配了 10 个实习生」），分别对应本片三条主线。→ 详细

• ChatPRD =「给产品经理用的 AI 副驾」，内有聊天模式 + 文档模式，打磨方式「跟 ChatGPT 很像」：界面有点赞/点踩，背后跑了大量 AB 测试试不同模型/prompt/配置。痛点是「不对称」——用户点踩会弹窗问「哪里可改进」，能收到很具体的反馈（最常见三个：「太长了、太短了、不准确」）；但点赞是个黑洞：「你点爱心或点赞，我只会说一句谢谢、不再打扰你，我知道你喜欢，但不知道你具体喜欢哪一点」。这期要补的就是：给正向反馈也加上「具体喜欢哪点」的收集，做到和负向反馈对称。→ 详细

▲ 「懒 PM 工作流」起点：全程不离开 Slack，直接 @ChatPRD 这个 Slack 机器人，让它就着痛点写 PRD（右侧已列出 Introduction、Problem Statement 等章节）。

• 第一步：截图 + 进 Slack：她自称「我是个懒 PM」，第一个动作是把现状界面截个图。不开专门工具，因为「我是 PM，我天天泡在 Slack 里」，又「不想来回换模型（I don't like to change models）」，于是直接在 Slack 里找 ChatPRD。整套流程的起点不是高大上的产品工具，而是她本来就一直开着的聊天软件。→ 详细
• 她给的指令不算精细，但点明了对照对象：她对 ChatPRD 说的大意是——「帮我做一份 PRD，关于在大家喜欢某条 ChatPRD 回复时，接收正向反馈、评论和理由。我们对负向反馈是这么做的，但我想给正向反馈也做一套。」她自评这 prompt「问得不算特别详细」，但把 ChatPRD 当成「我泡在 Slack 里的产品经理」让它直接动笔。关键心法：你不必一次把需求写得滴水不漏，给个清晰意图 + 一个现成对照参照（「负向反馈已有的做法」），AI 就能自己补全大量上下文。→ 详细
• AI 会「逼她做个更好的 PM」：ChatPRD「会把它知道的关于 ChatPRD 的一切都过一遍」，然后反问她「为什么」——「它会说：Claire，这只是个想法，你没说为什么要做，没有商业理由，我们到底为啥要做这个？」它主动给出可补的章节（背景 context、问题陈述 problem statement），且自己生成的问题陈述切中要害，她念出来确认「其实它说得对」：「我在理解用户满意度这块有个失衡（an imbalance in understanding user satisfaction），还有要无缝融入现有工作流。」AI 不只是听写，它在帮她把一个模糊想法逼成有逻辑的产品需求。→ 详细

• 她的招牌一句话：看完问题陈述她说「我觉得这看着挺好的，我们是个小团队，不用抠太细」，于是用了那句贯穿全片的招牌 prompt：「This looks great. Write me a PRD I can send to my engineering team.（这看着不错，帮我写一份 PRD，我好发给我的工程团队。）」紧接着是全片最有梗的剧透——「剧透一下，我的工程团队其实也是 AI（my engineering team is AI, too）」。所以这份「发给工程团队的 PRD」真正的收件人是后面那个 AI 智能体 Devon。→ 详细
• 核心技巧：明确告诉 AI 下游接收方是谁：她把这条单独拎出来当方法论——「我会告诉它这份东西接下来要交给什么角色的团队成员，哪怕那个成员是个 AI（even if that team member is an AI）。」具体对照：如果说「帮我写一份 PRD 我好发给设计」，产出的就是「发给类似 v0 那种工具」的 PRD（v0 = 能把需求/草图变成界面原型的工具）；如果打算「直接发给 Devon」，她就说「发给我的工程团队」。她的观察：「它会根据它预判接收方那种角色的需求，去调整文档的内容（tune the content to what they anticipate that persona might）。」一句话：同一个想法，告诉 AI 下游是设计还是工程，它会写出侧重完全不同的两份文档——这是用极小成本撬动产出质量的杠杆点。本期目标是直接发给 Devon，所以她选了「发给工程团队」这个措辞。→ 详细

• 判断逻辑：能复用就不重复造：写 PRD 时她插入一个重要的工作流判断——要不要先做原型？答案是「这次不做」，理由很硬：「这个弹窗在我代码库里已经有了，我已经有一个能复用的组件（I already have a component that I can reuse）」，所以「我大概率会跳过做原型这一步，因为它在这个工作流里是个多余的步骤（an unnecessary step in the workflow）」。她接下来要做的是「直接拿这份 PRD 导出来……发给 Devon，让它真正帮我把代码写出来」。一个很实用的元判断：原型不是每次都要做，当目标只是给已有组件加一种新用法时，原型反而是浪费。→ 详细
• 顺带一个小细节：GPT-4.1「特别能叨叨」：她一边等 ChatPRD 写文档一边解释为啥慢：「因为我们现在升级到了 GPT-4.1，它特别能叨叨（a real yapper），大家就爱这点。产品经理都爱写东西，所以会多花点时间。」写完 PRD 后「走不走原型」这个岔路口的判断（见上一条）正是在这里发生。→ 详细

• 她对各工具的真实分工：Peter 问「写代码这种事你其实不用 Cursor 或 Windsurf，直接交给 Devon？」（Cursor、Windsurf = AI 加持的代码编辑器/IDE，你坐里面一步步让 AI 改代码。）Claire 先打趣「别告诉别人——我其实很爱 Cursor，Windsurf 我也试过不少」，转折来了：「但说实话，自从 Devon 这几个月进步特别大、再加上 Claude Code 出来之后，我用 Cursor 的频率大概降了 70% 左右（dropped my cursor usage by like 70%）。」这是个很硬的数字，说明工具格局在她这一年里发生了真实位移。→ 详细
• 什么时候还用 Cursor、什么时候找 Devon：她讲得很具体——「开新项目的时候我还是会从 Cursor 起步，有时是想随便探索一下、想自己动手、或者对怎么做有很强的个人想法（have an opinionated view on how to build）。」但日常主力已是 Devon：「十次里大概有七次，我会让 Devon 帮我起一个 PR（seven out of ten times）。」最关键的一句是她对「为什么选 Devon」的判断——不是因为代码生成更强，而是因为交互方式：「这更多不是因为代码生成的技术能力（less about the technical capability of the codegen），反而更多是因为用户体验。」（这条「为什么是异步」在下一节展开。）→ 详细

• 她忙到没法一直坐电脑前：她把「异步」的价值用生活讲透——「我很忙，是个大忙人（Lady's busy），所以我没法一直同步地待在 IDE 里干活，也不是一直都在电脑前。」极有说服力的真实例子：「昨天早上我去晨走（early morning walk），人不在电脑边，结果客服那边给我发条消息说有个 bug，我手机上又打不开 IDE、也登不进去——哪怕那只是个很简单就能修的 bug。」→ 详细
• 而 Devon 把这件事变得不可思议地简单：散步、手机在手、连不上电脑，她的解法是：「我可以直接 @ Devon，跟它说去帮我把这个 bug 修了，它就在别的地方自己搞定了（it happens elsewhere）。」她再次强调落脚点：「这真不是代码质量的问题——虽然我觉得对大多数场景代码质量是够用的（sufficient for most use cases）——它真正的好处在于那种同步对异步的差别（synchronous asynchronous nature）。」→ 详细
• 同步 vs 异步的体感差别（片尾她又点了一次）：演示快结束时她收束得更利落：「我真的没法坐那儿盯着一个 IDE 看（can't sit and babysit an IDE），我就是做不到。」她对比 vibe 式编程（坐 Cursor/Windsurf 里实时盯着 AI 一步步响应）「比咱们刚才这个流程要琐碎、要一步一步得多」；而 Devon 的体验是：「我不会坐这儿干等它跑，我会去忙别的事，等它好了就会给我发 Slack 通知。所以那种等待、那种时间的感觉，都被压缩掉了（the sense of waiting and time is compressed）。」→ 详细

▲ ChatPRD 网页端生成的成稿 PRD——《Positive Feedback Collection for ChatPRD》，右侧能看到 Functional Requirements / Feedback Capture 等结构，这份就是接下来导出成 markdown、丢给 Devon 的「需求说明书」。

• 这份 PRD 到底要让用户能干啥：她快速复述 PRD 的三条核心目标——用户能快速表示「我喜欢这条回复」、能具体说出「我喜欢哪点」、如果很忙能跳过写评论但仍把反馈给出去。这三条后来正是 Devon 实现并通过测试的目标。→ 详细
• 关键操作：导出成 markdown：「我接下来要做的就是把它导出成 markdown。你知道的，AI 特别爱 markdown（AI loves markdown）。」（markdown = 纯文本轻量排版格式，结构清晰、AI 解析不易出错，喂给 AI 比花哨富文本更靠谱。）→ 详细
• 进 Devon 对话、给的三句指令（逐字还原）：她进到「很长很长的 Devon 对话」里，指令拆成三个要点：① 用同样方式做同样的事——「我想用跟我们采集负向反馈评论一模一样的方式，去采集正向反馈的评论」；② 明确点名复用组件——她顺手打开 Cursor 看负向反馈的实际代码，告诉 Devon「我们已经有一个组件叫 shared feedback modal，正向反馈也可以复用这同一个组件」，并举「爱心、点赞」这类正向类别；③ 把脑力活外包给 AI——「正向反馈的分类你自己编就行，我不想费脑子去想这个（You can make up the positive feedback categories. I don't want to think about that）」。最后附上 PRD：「再看一下附带的那份 PRD，了解更多背景。」一个被 Peter 确认的硬前提：Devon「能访问我的代码仓库（has access to my repo）」——正因为接进了真实代码库，它才能真去搜组件、改代码、提 PR，而不是只给一段「看起来对」的代码片段。→ 详细

▲ Devon 智能体「醒来」干活：左为 Slack 里给它的指令线程，右为它在 IDE 里实时读代码、写组件——「它干活的方式就跟工程师一模一样」。

• Devon「醒来」后的工作方式和真人工程师一模一样：她形容 Devon「很友好，它『醒』过来了」，并给出精准类比：「它干活的方式就跟工程师一模一样（working like an engineer would）——它会想：好，我先看一遍 PRD，确保搞清楚它想实现什么；然后我去代码库里搜它提到的那个组件；诸如此类。」背后执行链路是：「在仓库里找到对的项目、定位代码、设计一个方案，然后去把这个体验做出来。」→ 详细
• 给设计师的洞察：AI 出活要花时间，所以界面必须传达「我收到了、我在想」：这是她特意点给「在场产品设计师们」的设计原则——「这个界面有意思的地方……它是要花时间的（it takes time）。你出回复要等，这时你会想确认你的消息被收到了（acknowledged）、想知道它在思考（it's thinking）。」她打了个传神的比方：「这有点像在等一个同事，你心里会犯嘀咕：你在吗？有空吗？能给我五分钟吗？」对做 AI 产品的人，这点破了一个易忽视的体验雷区：AI 慢不可怕，可怕的是它「沉默」让你不知道它到底有没有在干活。→ 详细
• Devon 会先给方案、并问你要不要审批：她描述返回节奏：「它很快就会带着一个方案回来（come back with a plan），说：这是我实现这个功能的计划。然后它会问我，是想等着确认这个方案，还是它可以直接 yolo 一把往下冲。」（yolo = 不等批准、直接梭哈往下做。）演示中她选不等：「我可以让它等我审批，但我不想等，所以它就直接往下走、真的去把方案做出来。」这一步体现 agent 的重要设计：先暴露计划、把「是否放手」的控制权交还给人，而不是闷头一把做完。→ 详细

▲ Devon 把方案回写到 Slack 线程（左），同时已起好一个 PR、右侧浏览器里是它生成的代码改动——计划、改码、提 PR 一气呵成，控制权再交还给人审批。

• 14 步计划（她自嘲会直接梭哈）：回到 Slack，Devon 给出方案她念出来——「哦，是个 14 步的计划，非常好。要是我自己估计就直接『梭哈』往代码里写了（I would have just yoloed in the code）。」计划骨架：① 新建分支 → ② 更新正向反馈选项 → ③ 改成支持「正/负」两种反馈类型（她评「这招聪明」）→ ④ 更新代码接收 rating（评分）参数 → ⑤ 确保所有地方都改到位 → ⑥ 测试 → ⑦ 推一个 PR。她特别夸第三步「可扩展，正好满足我的使用场景，不用再新建一个组件（Extensible, works for my use cases）」——Devon 没图省事新造组件，而是把已有组件改造成能同时处理正/负两种反馈，这正是她自己会选的工程做法。→ 详细
• 它自己编的正向反馈分类，质量在线：Devon 给的正向反馈类别——「清晰、可操作、简洁、举例恰当、语气得当（clear, actionable, concise, relevant examples, good tone）」，她评「它能让我清楚看出为什么有人会喜欢某个东西」。回想第 8 节她说「分类你自己编、我不想费脑子」，结果 AI 编的分类不仅能用，还正好对应「用户为什么满意」的几个维度。→ 详细
• 「好公民」的惊喜：没让它做埋点，它主动做了：审 PR 时她发现一个没要求的额外动作——「它还更新了我的数据分析埋点（updated my analytics tracking）。我没明确让它做，但它主动更新了埋点来适配这个新功能。真是个好公民（a good citizen）。」她借此吐槽真人工程师常见毛病：「工程师有时写完代码，你还得再开一张 Jira 工单去补埋点。埋点永远都是事后才想起来的东西（always an afterthought）。」（埋点 = 在代码里埋下统计代码，用户一操作就记录数据，是后续分析功能好不好用的命根子，但工程师常忘。）这说明 agent 的价值：它不只是「按指令干活」，还会把一个有经验的工程师「应该顺手做、却常常漏掉」的事补上。→ 详细

▲ 合并前的硬闸门：她把 PR 拉到本地、逐行读 diff（红删绿增）确认逻辑——「我们任何东西不经过审查都不会上线，AI 写的也一样」。

• 硬规矩：不审、不批，绝不上线——AI 也一样：Peter 半开玩笑问「然后你就可以在本地测一测，没问题就 merge？」Claire 立刻把底线讲清楚：「对，但我确实会看代码。我们公司代码库是硬性要求的——PR 必须经过审查、必须有人 approve。我们任何东西不经过审查都不会上线，AI 写的也一样（We don't deploy anything without review including AI stuff）。」再自动化的流程，最后一道「人来把关」的闸门她没省。→ 详细
• 她真审，而且审得细（Cursor 在这里派用场）：她描述完整动作——「我一定会把 PR 拉到本地、在本地跑起来、在本地测（pull up locally, run locally, test locally），而且我真的会去看代码，确认逻辑说得通。」她现场逐行读了一段逻辑确认对错：「选中的评分，如果是 bad（差），就记为负面评分；否则，如果不是 bad，就是正面。没错。」她点明 Cursor 的角色：「这时候 Cursor 有时候就派上用场了」——用 Cursor 辅助看/读这份 AI 写出来的代码。→ 详细
• Devon 命中率约 80%，十次约一次直接扔掉重来：她给了很务实的可靠性数字——「我用 Devon 的话，大概有 80% 的命中率（80% hit rate）——质量过关、精准命中产品需求，而且在可扩展性上也是按我自己会写的方式来做。」剩下的怎么办？「偶尔它也会做出不对的东西，那我就在 PR 里给它反馈；要么大概十次里有一次，我就直接把这个分支扔了，该干嘛干嘛去（trash the branch and move on）。」她还专门夸 Devon 的软技能——PR 描述写得好：「工程师一般不爱把这种东西写得这么详细，但它写得很到位，连怎么测试的都讲得很清楚。」→ 详细
• 演示收尾：拉分支、点爱心、弹窗、提交、检查通过、批准合并：她现场跑了一遍——拉分支到本地 → 跑 localhost（「现场演示这种事永远让人心跳加速」）→ 进到一个聊天 →「咱们就使劲点那个爱心按钮，看看会冒出什么（smash that heart button）」→ 弹窗成功出现，里面显示「解释清晰、建议可落地、简洁、有帮助。我很喜欢」→ 点「提交反馈」成功。合并前最后两步：「确认我的检查（checks）都通过了。确实都过了。我会批准这个 PR，然后它就可以合并了。」她最后那句感叹是这期最佳注脚：「而且你知道吗，咱俩可是一边录完一整期播客，一边把这个搞出来的。」Peter 的反应：「太厉害了，我一直没把 Devon 当回事，我真该试试。」→ 详细

• 团队小到什么程度：Peter 注意到她 Slack 频道「全是各种 app 和 bot」，问「你手底下真有活人在干活吗？」她给出真实编制：「说到 ChatPRD，到现在为止写代码最多的还是我自己（I still by far ship the most code）。跟我一起做的工程师全球加起来差不多一个半人——一个全职、一个兼职。另外有一个兼职做增长的（她刚生娃在休假），还有个朋友给我做兼职的企业销售（fractional enterprise sales）。」→ 详细
• 工程师：通过 Toptal 招，体验惊艳到「当天面试、次日入职」：很多 PM 想搞副业不知去哪找人，她把三个人怎么来的都讲了。工程师走 Toptal（全球技术人才对接平台）：「我十年前做上一家创业公司就用过，onboarding 做得相当惊艳。」很有画面感的场景：「我是去年七月四号（美国独立日长周末）招的——当时带着孩子在 Santa Cruz，结果还在那儿写代码，因为用户量突然暴涨。」内心独白很真实：「我这是在干嘛？这个产品明明是盈利的。Claire，你完全有资格雇人啊（This product is profitable. Claire, you're allowed to hire people）。」于是「我提交了个需求，当天就安排了面试，第二天就把人招进来了（same day interviews and next day hired）」。→ 详细
• 增长 Alisa：先做了个 ChatPRD 的 YouTube 视频，被转给 Claire：增长负责人 Alisa 来路不同——「大概一年前 Alisa 做了个关于 ChatPRD 的 YouTube 视频，有人转给我看。我直接给她发了封邮件谢谢她，拍得真的特别用心。」Alisa 回了句客套「以后你有任何需要尽管开口」，而 Claire 没让它停在客套——「我说：那你能不能教我怎么当 YouTube 网红、顺便帮我搞搞营销？」从此 Alisa「就一直帮我们做 newsletter、社媒、增长和视频营销」。她总结这是「一个很自然冒出来的用户（an organic user）」。→ 详细
• 销售 Travis：前 Optimizely 同事，一句「咱俩能做到一百万 ARR」就上船：第三个人是哥们儿 Travis——「我俩以前一起在 Optimizely 共事，他管销售、我管产品。我约他喝咖啡说：老兄，我觉得咱俩光靠自己就能把这玩意儿做到一百万 ARR（a million in ARR）。」（ARR = 年度经常性收入，订阅软件最看重的营收口径。）他觉得「特别有意思、是个值得攻克的难题」，于是帮她打理客户关系（企业客户线索 prospects、onboarding 等），因为她「企业级 inbound 多到管不过来」。→ 详细
• 招人哲学两条铁律：Peter 特别欣赏 Alisa——「她就是单纯做了个视频、根本没问能不能参与，你完全是通过她的实际成果（proof of work）发现她的。」Claire 顺势讲出两条原则：① 给的是非常具体的「我能为你做什么」——「Alisa 跟别人不一样的是，她给我的是非常具体的、她能帮我做的事，不是那种『你想到啥需要的就告诉我』。」② 只雇付钱的人——「第二，我只雇我会付钱的人。我绝不会去招无薪实习生，也不用志愿者（only hire people that I'm going to pay. Not unpaid interns. No volunteers）。」背后逻辑：「正因为如此，我希望这些人在公司里是极高杠杆的，他们必须能补上我没有的能力（add something I don't have）。」——付钱，才有底气要求高杠杆、要求对方补足你的短板。→ 详细

• 先承认现实：PM 还是得写一堆内部文档，不可能整天做原型：Peter 铺背景——「很多 PM 还是得写一大堆内部文档，比如战略这类东西，再怎么说我们都想整天做原型，但这并不是这份工作眼下的真实状态。」他还替很多 PM 道出一种执念：「PM 总觉得做战略特别『高大上』，好像得进一个房间对着冥思苦想两个小时。」Claire 后面整套 AI 用法正是对「闭门空想」的反驳。→ 详细
• 她对「产品战略」的定义：本质是市场战略：「我其实是把产品战略当成市场战略来看的。说到底我想的是怎么打造一个东西、解决客户问题，而且这种方式得有独特的市场竞争优势、能提升利润率（margin accretive）、能在已有平台上形成复利（compounds on the platform），而且团队还得有技术能力把它落地。」一句话收口：「产品战略就是基于你对市场和客户的独特理解所采取的一系列行动——这也是我对产品管理的定义。」→ 详细
• 她用 AI 干嘛：不是列待办，而是把市场认知建扎实：「我用 AI并不一定是用来列出该做哪些事，而是用来确保我对市场背景有非常扎实的理解——我们独特的技术差异化在哪、未来可能发生什么。」AI 在这里不是「执行清单生成器」，而是帮她把战略的「认知地基」打牢的工具。→ 详细
• 最有用的补充是 deep research，附 LaunchDarkly 真实案例：「我发现有一个特别有用的补充，就是 deep research（深度研究），因为它能拿到那么及时、那么丰富的信息，而这些信息靠个人去汇总要么很难、要么极其费时。它让我对市场有一个广得多、也深得多的视角。」真实案例就是自己公司：「就拿 LaunchDarkly 来说，在 feature management（功能管理）和实验（experimentation）这个领域，市场上发生了大量整合。我们正往很多相邻领域扩展，光今年我们就做了两笔收购（two acquisitions just this year），还在做多产品扩展。随着平台和产品组合扩大，竞争对手和合作伙伴的版图也跟着变大，再加上一堆宏观层面的力量。」→ 详细
• 为什么个人盯不住市场：「要盯住每一个竞争对手实在太难了——他们在做什么、做哪些功能、这些功能透露出他们整体战略的什么信号、在招什么人、为什么招。这太花时间了，当你得自己去做这些调研时，很容易对市场只有一个非常浅的认识（a very shallow view of the market）。」→ 详细
• 她的战略提问范式（可直接照抄）：「我经常做的一件事，就是退一步问自己：如果我们看这三个竞争对手过去三个月的动作——他们在 ship 什么（出了什么新东西）？在招什么人？这透露出他们产品战略的什么信号？跟我们已经定下的产品战略（X、Y、Z 这几条）有什么关系？有哪些潜在威胁可能冒出来、是我们战略里没顾及的？我们又该在哪些地方加码、好为自己创造一点优势（where should we lean in harder that could create an edge）？」→ 详细
• 具体用法 + 真正的目的：Peter 复述并得确认——「你是先用类似 ChatGPT 的 deep research 去调研竞争对手，然后再把你们旧的产品战略、或 LaunchDarkly 的背景喂给它？」Claire：「对。」她点明真正图什么：「它倒不一定是为了想出更有意思的产品点子（not for more interesting product ideas），真正的作用是帮你识别出业务里那些更高杠杆、值得投入的发力点（higher leverage points），或者那些你也许该撤出的地方——因为市场在那儿就是没有拉力（the market doesn't have the pull there）。」一句话：用 deep research 做战略，目的不是发散，而是收敛——找到该重押和该撤退的两端。→ 详细

• 同步协作在分布式世界里成本极高：Peter 点出内核——「它有点像跟 AI 协作，我自己一个人关在房间里干想两个小时是行不通的，我得找个人聊一聊。」Claire 上升成设计观察：「这正是这些 agentic（智能体式）体验一个特别有意思的设计优势——尤其在分布式或远程办公的世界里，同步协作的成本变得非常高（synchronous collaboration feels very expensive）。你得跳进一个会议，还得确保你想聊的人都有空，因为有这种空间和时间上的限制，协作就会被拖得很长。」→ 详细
• 「超级 IC 崛起」——什么都能自己干，但很孤独：她抛出一个很有共鸣的概念——「所以就出现了所谓的『超级 IC（个人贡献者）崛起』（Rise of the Super IC）——什么都能我自己一个人干，但那其实挺孤独的。」她自陈心声：「我大概能自己写出一份还不错的产品策略，但这么干真的一点都不好玩（it's sure as heck not very fun）。」她给了一个戳人的周末场景：「比如周末，我们的工程师周末是休息的，但我手头在搞一个东西，又想找个人一起协作。那好吧，至少还有老伙计 Dev 在这儿陪我（at least I have good old Dev in here to hang with）。」（Dev = 她对 Devon 的昵称。）→ 详细
• 「我跟这些工具说话，比跟同事说话多得多」：Peter 追问「你跟这些工具说话不比跟同事少吧？」Claire 给了句坦白的金句：「哦那当然了，我跟这些东西说话的次数，绝对比我跟同事说话多得多（I talk to this stuff way more than I talk to my co-workers）。」她把这种「协作感」上升为推动采用的设计点——「这可能正是它会推动组织去采用这些工具的原因（might make organizations drive adoption）。」也就是说，让 agent 像「能随时找的同事」而不是「冷冰冰的工具」，本身就是让人愿意用它的关键。→ 详细

• 她自嘲答案是「我就是一直在工作」，给了具体作息：5:30 起床 → 先看欧洲那边客服工单队列、手机回一堆客服 → 给工程团队发消息（他们因时差「一天过了一半」）确认没卡住谁的进度、必要时做 PR review → 孩子六点起，老公做早午饭、她给孩子穿衣送学、俩人总有一个抽空锻炼，然后进 LaunchDarkly 的工作。放学后「全家一起做作业——孩子做他们的作业，然后我做我的（LaunchDarkly / 播客 / ChatPRD 的作业）」，晚上读书洗澡到八九点，「九点半到九点四十五之间睡着」。周末两份工：开车带孩子做体育 + 集中补一大堆 ChatPRD 的事；底气是「这门生意是盈利的，所以我招得起人」。平衡心得：引用 Sahil「我们职业上最忙的那段时间，恰恰也是孩子最需要我们的时候」；她自己消化负罪感靠「写下来：为什么让孩子看到我热爱我做的事是好事」，还「和七岁的孩子一起 vibe coding，五岁的孩子总能让我特别保持谦卑」；孩子的回应最戳心——「『你的头号工作是当我们的妈妈』」。伴侣是她「做一切事情的搭档，俩人一起创办了大概六家创业公司」，他在 ChatPRD 背后管报税/法务/行政。→ 详细

• 更准确的说法：传统产品管理正在消亡，但还没死：她回应很审慎：「也许吧，咱们走着瞧。至少就目前它肯定还没死——因为我还在招产品经理（still hiring a product manager），LaunchDarkly 刚招了一批。」但她坚持核心判断：「这个角色、对它的预期会发生很大变化，你需要的工具和硬技能也会变（the expectations, the tools and the hard skills are going to change）。」她特别好奇的是「新团队会怎么开始组建，未来一个『构建型团队』的新画像会长什么样」——比如设计师正在变成「设计工程师」（design engineer），也许会有「一个更偏后端、但同时懂产品的人」。→ 详细
• 她为什么甘愿说「已死」这种重话——两个理由：这是本节最关键的一段。「我说『产品管理已死』并不是出于什么悲观末日论（not because of doom and gloom）。」理由①（逼你准备）：「如果你没为接下来 18 个月里的这场变革做好准备，你会非常痛苦（a world of pain），没做好准备是你能对自己职业生涯做的最糟糕的事（the worst thing you can do for your career）。所以如果用一点点『煽动性』的说法（be a little bit incendiary）能让你动起来去准备，那我就用。」理由②（这行很多活儿不好玩）：「这份工作里有很多事并不有趣，很多是琐碎的活儿、没什么创造性、跟客户的实际影响也离得很远（tedious, not creative, very disconnected from customer impact）。如果你能把那些不高杠杆、不有意思的部分压缩掉，你就能把更多时间花在我喜欢的地方——也就是搞创意、做产出、动手去做、跟团队协作、跟客户聊天，还有在市场上竞争（being creative, generative, building, collaborating, talking to customers, competing）。我觉得这些才是这个角色里好玩的事。」→ 详细

• AI configs：她喜欢到亲自挂名当 PM：用自己公司的真实例子说明角色正在怎么变——「在 LaunchDarkly 我们有个产品叫 AI configs，团队特别棒。我太喜欢这个产品了，以至于我现在亲自在给它做 PM，算是这个产品挂名的产品负责人（the named product lead）。」但她有高管本职：「我有一份高管的工作，还有一大堆别的事，所以他们其实只能拿到一个『半个产品经理』（a partial product manager）。」（AI configs = LaunchDarkly 的产品，让团队像管功能开关一样去管理/配置 AI 相关设置。）→ 详细
• 关键观察：设计负责人、工程经理都在写 PRD，拿来时已成型 80%：这是这节核心——「我们那位超级棒的设计负责人在写 PRD，我们那位超级棒的工程经理也在写 PRD（our design lead is writing PRDs. Our engineering manager is writing PRDs）。他们拿来给我的时候已经成型了 80%（coming to me 80% formed），我就能说：『这里得调一下』，或者『这是我从业务角度衡量它的方式』，或者『别忘了这一部分』——但他们并不需要一个全职的我来推动那一块落地（don't need a full-time me）。」结论很清楚：「拥有合适硬技能和合适工具的人，能够补上这个空缺，为一个灵活、能适应变化的团队把事情真正做成（people with the right hard skills and tools can step into the gap）。」Peter 补「这份工作有希望变得更好玩」，她认同。→ 详细

• 她大约每六个月做一次「重规划」，专留三天，「其实更偏产品战略」。结构上先问业务目标、再进产品战略：「一上来就问未来这六个月我们的业务目标是什么？我们要卖什么？怎么卖？怎么给公司带来价值？我们是否一致认为这些目标既可实现又重要？我们会在这上面花很多时间。」产品战略的定义是「我们要做什么、为什么做，以及怎么把它商业化、推向市场」。最反直觉的一刀：只花不到 10% 时间在具体路线图条目上（「条目就是顺着层层往下展开 cascade down」），靠的是一份**「永远在线」的路线图**——「公司内部要找任何信息我都知道去哪儿找，每个团队在做什么我都清楚，任何一个季度里最重要的五件事是什么，我们定期去看。」她和领导团队在打一场**「正义之战」抵制往规划会议里砸时间**，「把更多时间花在跟踪『事情有没有真的做完』上」、当下更灵活地应对。节奏是「三天高强度集中、不会拖很久；每个团队约两周准备但不是全职」。（OKR = 目标与关键结果；她其实是说规划重心要放在「业务目标与战略」而非被 OKR 形式吞掉时间。）→ 详细

• 先泼一盆冷水：盯着「vibe coding 是胜负手」是短视的：被问「评估 PM 的 AI 能力时你看重哪些技能？」她先纠误区——「我觉得说『vibe coding 会成为胜负手』或『做原型的能力会成为胜负手』是相当短视的，因为那些只能带你走这么远（only takes you so far）。」她真正在想的是：「怎么去培养那些能让你的职业在这个 AI 时代『面向未来』的素质（attributes that futureproof your career），而不是 AI 的硬技能。」→ 详细
• 素质①：Scrappiness（不挑条件、用极少资源硬把事干成）：「第一个素质是 scrappy——用极少的资源把事情搞定的能力。如果我得解决一个问题，手里又一点资源都没有，我怎么把它搞定（if I have zero resources, how do I get that done）？我能不能证明自己能在一个非常精简的环境里把事情做成？也许会借助一套工具，也许不用。」→ 详细
• 素质②：学习能力：「第二点我会考察学习能力。你可以证明你能学会某个工具、学会新技能，也可以展示你能去搞懂市场、搞懂财务（learning the market or finance）。我真心觉得，在当下这个时刻，学习能力是把事情做成的一个非常重要的素质。」→ 详细
• 素质③：清晰沟通（话痨反而占便宜，因为 Devon 是语言界面）：「我觉得现在**『清晰沟通』的能力极其关键**（the ability to clearly communicate is so critical）。这可能正是传统产品经理有优势的地方——我们这些『话痨』反而占了便宜（us yappers have the edge）。因为 Devon 这样的东西就是一个基于语言的交互界面（a language-based interface），你是在告诉一个系统去做什么。你能不能把要做的事讲清楚，讲到这个系统能正确理解、能调用它那套工具、把活儿正确干完——这是个非常重要的技能。你可以管它叫 prompt，也可以叫清晰沟通。」金句：「每次你在写 prompt 的时候，其实都是在锻炼你的书面表达能力（every time you're prompting, you're improving your written communication skills）。」→ 详细
• 素质④：低自我（low ego）：「我想往那个清单上再加的第四个素质就是『低自我』（low ego）。如果你很有地盘意识，在这些新型组织里你是活不下去的（you're not going to survive in new orgs if you get territorial）。」她举例：「一个设计师说『除了我谁都不能设计这个』，或者一个工程师说『除了工程师谁都不能提交代码』——面对这种相当激进的变革，这种心态是非常局限的（very limiting）。」收束很有分量：「只要你具备这类素质，你在几乎任何角色里都会做得很好（you'll be successful in any role）。」→ 详细

• 第一块：AI fluency（工具熟练度），在工程线影响尤其大：被问到晋升评估，第一块是 AI fluency——「你需要有 AI 的熟练度，这一点在工程线上影响可能更大（even more impactful in the engineering track，她补『我同时也管着工程组织』）。」很实在的清单：「你得搞明白怎么用 AI 加持的 IDE；得搞明白在你们组织内部怎样用 Devon 这类东西才合适；还得对『什么模型适合干什么』有自己的判断（have an opinion on what models work for what）；还得有能力把一个代码仓库架构成更容易配合这些工具来用的样子（architect a repo to be easier to use with these tools）。」她强调这些「都属于硬技能，应该成为软件工程师晋升阶梯的一部分；产品/设计那侧也有完全对应的东西」。→ 详细
• 第二块：杠杆（leverage），越资深越看这个：「随着你在产品岗位上越来越资深，大家对你的期望就是你对业务有更高的影响力（higher impact on the business），而我的期望是，你会动用一切可用的工具来产生这种影响（use all the tools available to you）。所以我们会去看『杠杆』，尤其在资深岗位的晋升上——这个人是不是对业务产生了很高的影响，通常都是因为他们把一切可用的工具都用上了。」→ 详细
• 金句：「恭喜，我刚给了你 10 个实习生」+ 要人头先问「你团队效率拉满了吗」：一个反复出现、特别能传播的做法——「我跟所有的工程经理都这么说：当他们用 Devon 的时候，我会说『恭喜，我刚给了你 10 个实习生』（Congratulations. I just gave you 10 interns）。没有哪个工程经理会对增加人头嗤之以鼻（no engineering manager turns their nose up at headcount）。」当真有人来要**真人 headcount（编制名额）**时，她的反问很犀利：「你的团队效率拉满了吗（is your team maximally efficient）？他们有没有做过实验，知道自己在哪些地方还能提效？很多时候答案是『有，而且我心里很有数』；有时候是『没有』，那他们就得先把这块搞清楚。」（headcount = 公司批给团队的真人招聘名额。）→ 详细

• 管理侧她给了一套系统解法。先搭财务与安全框架让人敢做实验：财务不是问题（「我可以白天黑夜地为这些工具的高 ROI 来论证」）；信息安全只需「搭一套框架，让他们能快速对一个工具的使用『点赞』或『点踩』」，「一旦有了框架，工具接入就能跑得非常快」。第二件事：把 AI 使用「常态化」，否则「从安全角度你会被一堆**『影子 IT』困住——人们偷偷用个人账号、在不受管控的授权下用，那是最糟的情况」，不如「给他们一条干净的路径、把它摆到台面上」。（影子 IT = 员工绕过 IT 管控私自使用的工具/账号，公司看不见也管不了，风险最大。）真正的胜负手是文化：他们建了个 Slack 频道叫「project building with AI」（用 AI 搞建设）——「你要申请 AI 工具权限就得在那个频道里申请，所以每个拿到权限的人都在同一个频道」，大家在里面「展示什么管用、什么不管用、试了什么、学到什么」，「制造出很强的势头、把大量用例『社交化』」。技术侧指定一位「AI 落地负责人」Zach**，帮公司评估工具、给 cursor rules / Devon 环境配置出建议，还主持每周五的「AI power hour」（像 Zach 用 AI 的一个 Twitch 直播，「我每周大概有 60、70 个人来」）。→ 详细

• 收尾犀利观点（Claire 是「hot take 女王」）——「今年是 agent 元年」：她的判断很硬：「我觉得今年就是 AI agent 元年（the year of the agent）。今年是个转折点：AI 从那种 co-pilot 式的单人体验，转向了更像有同事在身边的多人协作式 agent 体验（from co-pilot single-player experiences to multiplayer agentic experiences that feel more like your colleague）。」行动建议是一串具体动作：「学会怎么跟 AI agent 协作，搞清楚现在市面上哪些 agent 是真正有价值的，搞清楚怎么把 prompt 写对，搞清楚怎么把多个 agent 编排到一起协同工作（how you orchestrate them together）。」收束语与 TL;DR 呼应：「今年就是你从单人模式里走出来、开始拥有一支『AI 实习生团队』的一年（get out of single player mode and start getting your team of AI interns）。」（orchestrate/编排 = 把多个 agent 像乐队指挥那样组织起来分工协作。）→ 详细

• agent 的定义（Peter 当场求定义）：Peter「agent 就是那种会自己跑去帮你干活、还能跟其他 AI 协作的东西？」Claire 确认「对，没错」，并用刚才的演示作注脚：「就像你用 Devon 演示的那样，你不用一直用 prompt 盯着它，它自己就能把活儿干了（you don't have to babysit it with prompts）。」→ 详细

• 《How I AI》播客在哪听：「我推荐 Spotify 或 YouTube，因为我们的嘉宾会上来分享屏幕、演示他们的 AI 用例。各大播客平台也都有，但我更推荐看视频版。」——这是个高度依赖「看演示」的节目，光听音频会丢掉一半信息。→ 详细

• X（Twitter）: @Clarvo — Claire 本人。她还透露「我也可能会重新开始玩 TikTok，所以『首席产品官的 TikTok』说不定要回归了」；但笑着自嘲「我就是没法再接第五份、第六份工作了，而玩 TikTok 感觉就像第五、第六份工作」。→ 详细

• 播客：《How I AI》（Spotify / YouTube / 各大播客平台，推荐看视频版，因为嘉宾会现场共享屏幕演示）。→ 详细

• 产品：ChatPRD（给产品经理用的 AI 副驾，帮你更高效、更高质量地写产品文档、做产品工作）。→ 详细