← 主页 NO.39
专栏 · AI 工作流实战 › 第 39 期 · 产品 · 收录于 2026 年 8 月 16 日
谷歌 PM 跑 7 个 Claude Code agent 做应用(零员工)
双人对谈 · 本期速读电台 00:00 / 48:30
TL;DR · 三句话
- 一一位谷歌 PM（Gabor Meer）用 Claude Code 把「一整家软件公司」复刻成一队专门化 agent——系统分析师、CTO、设计、品牌、实现、性能、可维护性、测试、UX 流程等十几个角色，由 system analyst agent（系统分析师 agent，相当于把需求翻译成开发任务的中间人）作中枢调度，真正做开发冲刺时 峰值 7-8 个 agent 并行，全程零真人员工。他的原话是：「我设置这些 agent 的方式，就是按照我在真实世界里跟一支软件工程团队协作时会想象的样子来配置的。」 → 详细
- 二核心方法论是 idea → prompt → code → product（想法→提示词→代码→产品，一条分步可控的流水线）：先用 Claude 把需求逐个问透、在 Confluence 写规格、在 Figma Make 出设计 brief、在 Jira 拆开发工单，最后才让一队 agent 并行写代码。他旗帜鲜明地反对「一个 prompt 一步出成品」的 vibe coding（凭感觉编程），并引用 Reddit 上一句戳中他的话——「vibe coding 不过是给那些没法维护的低质量源代码换了个马甲」。 → 详细
- 三全片是一场不剪辑的现场演示：几小时内从零做出冰球规则 AI app「Rule Ask」（Flutter 前端 + Firebase 后端 + Vertex 向量库做 RAG 检索增强），并真的推上 TestFlight（苹果的内测分发平台）。目的不是这个 app 本身（Gabor 自己说「我并不真的需要一个冰球规则 app」），而是证明 PM 能戴上「构建者」的帽子——因为两年后会亲手做东西的 PM，和只会拿 ChatGPT 提点效的 PM，差距会大到追不上。 → 详细
01
核心命题：这不是「PM 操作系统」，是「创业操作系统」
- 主持人定调：Aakash 把这期和自己以往的 Claude Code 节目区分开——「它不是一套 PM 操作系统，而是一套创业操作系统（startup operating system）」。区别在于：以往「PM 工具课」AI 是副驾、帮你更快写文档做调研；「创业操作系统」是把整条「需求→设计→开发→测试→上架」价值链都交给 agent，你只当那个把方向、卡关键节点的「团队负责人」。 → 详细
- Gabor 不只拿它做 PM 的活，而是复刻一整家公司：前端工程师、后端工程师、法律顾问都由 agent 扮演；他「每天熬到凌晨四五点泡在 Claude Code 里」打磨这套配置（后文 t099 回扣）。 → 详细
- 开场金句（冷开场剪辑）几乎是全片浓缩：「AI agent 在写 PRD、在 Figma 里做设计、写 Jira 工单，甚至直接发布代码——这一切都是凌晨 4 点由 100 个 agent 在干。」（「100 个」是夸张，真实配置见下节。） → 详细
02
到底有几个 agent？（标题「7」的真相）
03
System Analyst Agent —— 整个系统的中枢（最重要的一个）
- Gabor 反复强调它的地位：「我用得最重要的一个，大概是 system analyst agent。」「系统分析师」用大白话讲，就是站在业务和技术中间、把「我想要什么」翻译成「工程师该照着做什么」的人。 它的职责：把产品需求和技术规格拆解开，运作方式跟真人系统分析师一样——遇到含糊处会反过来问你澄清问题，并把依赖关系（哪件事必须先于哪件事做完）妥善记录下来。 → 详细
- 它是整套配置里的「关键角色」，因为它既是生成文档的那个，也是生成开发工单的那个——Gabor 原话：「我发现 system analyst agent 真的是我整套配置里的关键角色，因为它既是我用来生成文档（Confluence）的那个，也是我用来生成开发工单（Jira）的那个。」两条产出都归它，这就是为什么后面所有协作都围着它转。 → 详细
- 它的 prompt（提示词）设计有两个要点，Gabor 当场讲透了缘由：
- ① 先问问题、别急着写——「不同的 agent 有不同的倾向，有些 agent 或者说有些 LLM 特别爱立刻开始写代码，有些特别爱立刻开始写东西。所以我才会告诉 Claude，别开始写，先问问题。」
- ② 一次只问一个问题——「有时候它一上来就甩 25 个问题，那种情况下你很容易招架不住，很难把所有问题都答完。但如果它一次只问一个，对话就会线性得多。」他在 prompt 里原话写的是「请一次只问一个，因为如果你一次问太多，我可能会招架不住」。 → 详细
- 一个易被忽略的边界设定：他在 prompt 里还死死圈定了 agent 的活动范围——「这是你唯一能用的 Confluence 空间和 Jira 看板。请不要通过 MCP 碰任何其他的看板、空间或项目，只能用这两个。」这是为了防止 agent 在你的真实工作账号里乱动其他项目。 → 详细
04
其余各 agent 的职能（逐个点名）
- CTO agent：偏战略的技术架构决策（创建后端工单时点名「CTO agent 专门负责架构」）。Design agent：做实际设计，工单评审时让它「检查所有前端开发工单、确保信息足够且每张都附了截图」。Brand agent：盯品牌一致性，与设计 agent 经 Figma MCP 在 Figma 出屏。实现/写代码 agent ＝ Flutter mobile architect：真正写代码（演示里做后端实现；Flutter 是谷歌跨平台 app 框架）。App performance agent：负责应用性能。Product spec architect：检查 specification 结构是否清晰、好理解。Product council：专管数据怎么处理/怎么存、不留安全隐私漏洞（演示中把关「用户数据只存设备端」）。Test architect：制定测试计划/回归测试计划；Tester agent：与 system analyst 一起核实每张前端工单都附截图、覆盖到位（一个定策略、一个查执行）。UX flow architect：做可点击原型时自动连原型箭头（Gabor 开场就特意预告的最惊艳一环）。 → 详细 → 详细 → 详细 → 详细 → 详细
- Code maintainability agent ＝「spaghetti agent」（意大利面条代码 agent）：确保无循环引用（A 依赖 B、B 又反过来依赖 A 这种死结）、注释质量高、命名规范被遵守。它的由来是全片最有故事性的一段：「我在 Reddit 上读到一条关于 vibe coding 的评论，大意是说，vibe coding 不过是给那些没法维护的低质量源代码换了个马甲，这句话真的戳中了我。所以我做了什么呢？我建了一个 spaghetti agent。」他点出 PM 的真实软肋——「那些不懂代码的人……我们其实没法识别出软件结构上什么时候出了大问题」（自承有工程背景但「已经有大概 15 年没做过工业级编码了」）。第一次在代码库上跑它，「它确实揪出了其中一些问题」。 → 详细 → 详细
05
Agent 之间如何协作（这是全片的精髓）
- 中枢-辐条结构：system analyst agent 是 hub（中枢），主导讨论、产出 Confluence 文档 + Jira 工单、映射依赖；其余 agent 都「插」在它创建的工单上贡献视角。主持人顺口给它起了名——「这就是我们的 system analyst agent 网络，对吧？」 → 详细
- 全员评审、各出视角：写代码前，Gabor 坚持「让整个团队都来发表意见」。原话把理由讲得很白——「因为我通常希望整个团队都来发表意见。原因是每个 agent 都有不同的角色，你懂的——一个负责代码的可维护性，另一个负责确保我们的隐私设置到位，等等等等。所以这点很重要：在我们真正开始写代码之前，让它们每一个都在开发 ticket 里贡献出自己的视角。」 → 详细
- 具体协作配对（演示里点名调度的组合）：
- system analyst + design + brand → 通过 Figma MCP 在 Figma 里创建实际设计和各屏。Gabor 的目标提得很明确：「我想用最少的屏幕数量来覆盖所有用例。目标是屏幕质量极高，但数量尽量少。」 → 详细
- system analyst + UX flow architect → 过一遍文档和 Figma，连出原型箭头。他给的指令原文：「system analyst 和 UX flow agent，请把文档和 Figma 都过一遍，在 Figma 里创建出原型箭头。需要的时候请用 Chrome DevTools MCP，也用 Figma MCP 和 Confluence MCP。」 → 详细
- system analyst + test architect → 并行规划 epic（史诗，一大块功能）/story（用户故事，一小条需求）的拆解；同时 Flutter mobile architect 在另一条线做后端实现。屏幕上当场打出的话就是「现在让我并行启动 system analyst 和 test architect 这两个 agent，来规划 epic 和 story 的拆解」。 → 详细
- 工单全员 review（最终评审一轮，一口气点名五个角色各盯一摊）：designer 查前端工单截图与信息量；tester / test architect 保测试覆盖、并明确「整体测试计划和回归测试计划」；code maintainability 盯命名规范、确保代码「可维护、文档齐全、注释清晰」；product council 查数据只存设备端、服务端只处理不存储。 → 详细
- 并行执行省时：前端工单创建与后端实现并行跑；Gabor 的诀窍——「如果你等得太久，你其实可以再开一个终端窗口、再开一个终端窗口，你有多少算力就尽量并行多少活儿，只要有得并行就行。」主持人称这是「传说中的并行 agent 工作流（those infamous parallel agent workflows）」。 → 详细
- 告别人类团队的扯皮：Gabor 说这套体系最让他舒服的，是消灭了真人团队里那种没完没了的责任推诿——「以前总会有那种扯皮：到底谁该做这一步？谁该做那一步？这个『如果……就……』的逻辑该谁来定义？边界情况该谁去想？『不，那是 system owner 的活』『不，那是 product manager 的活』『不，那是 developer 的活』。这正是我喜欢这套东西的地方——它们真的帮了大忙。」 → 详细
06
MCP 是「迄今最大的解锁」
- MCP（Model Context Protocol）= 让 AI 直接读写外部软件的标准「插头」——不是截图给你看，而是真去 Jira/Confluence/Figma/浏览器里建页面、改文件、点按钮。相比 Cowork / dispatch / open claw，Gabor 直言目前真正最大的解锁还是 MCP——「我本质上是在复刻一整套常规软件开发团队的工作流程，只是把那些原则和步骤套用到 agent 身上。」用到的清单：Atlassian MCP（一口气连 Jira + Confluence）、Figma MCP（含 Figma Make，操作真实设计文件）、Chrome DevTools MCP（让 agent 像真人操作浏览器，「能更好地做对比、获取可视化结果来验证设计」）。两个实操点：①装新 MCP 后必须重启 Claude Code；②style guide 等要存进 project memory，「这样以后每次为这个应用做设计决策都会参考它」。主持人点破突破口：「你把 Figma Make 和普通 Figma 都接进来，让 Claude Code 像真实用户那样去操作它——这才是真正的突破点。」 → 详细 → 详细 → 详细
07
方法论：idea → prompt → code → product（反对一步到位）
- 与 Lovable / Bolt / Figma Make「prompt 一步直接到原型」不同，Gabor 的链路是「从 idea 到 prompt，从 prompt 到 code，从 code 到 product」——多出来那几步（先把规格问透、再拆工单）就是质量和可维护性的来源。入坑契机：看了 Lenny 播客里跟 Meta 的 Zevi 的对谈受启发，加上「现在都有 MCP 了，想挑战一下能不能真做出一个移动 app」。主持人提炼回他一句——「经典的产品管理能力，会让你成为一个更好的 vibe coder」（写规格、拆需求、管依赖这些老 PM 功夫，恰是 AI 时代最值钱的）。 → 详细 → 详细
08
为什么必须写 spec / 文档（建筑师比喻）
- 反面：很多 PM / vibe coder 上来甩一个 prompt，指望另一头蹦出完整软件。Gabor 的原话比喻很到位——「这就好比你想盖一栋新房子，你找了一个人，跟那一个人说『给我盖一栋三室的房子，要两间卧室』，然后半年后你回来，惊喜——房子可能根本不是你想要的样子。」 → 详细
- 正面：「但反过来，如果你找的是一个团队的负责人，比如一个手下有完整团队来盖房子的建筑师，并把你的需求说清楚，那你最终拿到的房子，质量很可能比你只跟一个人说一次时拿到的那一团糟要好得多。」对应到这里就是那句反复出现的核心律——「如果你有一份好的 specification，你就会有一个好的产品；如果你的 specification 是一坨，那你就会得到一个不及格的产品。」 → 详细
- 文档的价值在「可复现 → 可维护」：Gabor 把因果讲完整了——「如果我们把决策、specification 和软件开发步骤都记录得很好，它们就是可复现的，你的 app 也就可维护。」他用 Confluence 存文档（理由：「它在很多公司里几乎是行业标准」，且「能通过 MCP 跟 Claude 打通」），用 Jira 存工单。主持人一针见血地总结：「你在做的，是在前期把脚手架搭好，这样你一路往下构建的时候，就不会撞上那种一团乱的代码、没文档、根本没法在上面继续叠东西的代码。」 → 详细
09
完整工作流七步（全片骨架）
- 收尾时 Gabor 亲口把全流程复盘了一遍，七步串起来是：① Claude 桌面 app（消费端，也能在手机上跑） 用语音定义/细化需求（他强调「我可以把 Claude 切到语音模式……哪怕在遛狗的时候也能用」）；② 生成 Confluence 规格；③ 进 Figma Make 出设计 brief（排版/配色/CTA 按钮/颜色过渡/错误态）；④ 进 真 Figma 建各屏；⑤ 回 Claude Code 让 agent 创建 Jira 开发工单；⑥ 并行写代码到模拟器；⑦ 推 TestFlight。 → 详细
- 一个关键区分（别搞混）：Claude app 里「扮演」的角色 ≠ Claude Code 里真正配置的 agent——两边都有 system analyst，但 Claude Code 里那个是独立配置、以自己身份行事的真 agent。Gabor 特意停下来讲清楚：「我在 Claude app 里这场讨论、这个对话里设置的 agent 或角色，在 Claude Code 里是用不上的。所以在 Claude Code 里，我们其实需要单独再设置我们的 agent。」 → 详细
- 反直觉结论：写代码反而是最短的一段。主持人现场感慨「我回想一下，写代码反而是最短的一段——一旦你让它把工单建好，前端后端就几个提示，现在我们就有了一个能用的 app」；Gabor 顺势把这层因果讲透——「定义阶段才是真正的投入——为整个项目、整个应用打下好的骨架。这件事一旦做完，写代码就相当快了。而这恰恰是大多数产品经理被卡住的地方，就是单纯地『哦，我不知道从哪开始、怎么搭我的系统』。」 → 详细
10
现场演示的产物：冰球规则 AI app「Rule Ask」
- 做什么：一个 AI 聊天 app，帮冰球迷/球员/裁判更好理解 IIHF（国际冰球联合会）规则、为冷门情况快速查到适用规则。这是个真实痛点——Gabor 当了 20 年冰球裁判，「我看球的时候，经常有球迷过来问我问题。所以我设想，我就在那个 AI 里面，基于最新的规则回答问题」。 → 详细
- 技术栈（一段被主持人评为「这档播客上见过的最长的一段口述 prompt」的超长语音定义）：Flutter 前端 + Firebase 后端，两份资料源（官方 IIHF 规则手册 + IIHF 情境手册）转成向量 embedding 进向量库做 RAG；agent 人设是「扮演成用户的一个好朋友，这个朋友当了 20 年裁判」；面向 2025–2026 赛季，且有一条很妙的时效护栏——「每当你引用这样一段（网上旧的 Reddit）讨论时，一定要给用户标注出来：你在网上找到的这段讨论或资料源是更早时期的，这可能意味着规则从那以后已经变了。」 → 详细
- 检索优先级（三级瀑布）：他在 prompt 里把顺序钉死——「首要查询应始终在规则手册里进行，次级查询应始终在情境手册里进行，然后兜底才是通过搜索 API 进行在线搜索。」演示问「什么是 tripping（绊人犯规）」时，规则手册命中 4 条、加上情境手册后共 5 条命中就够了，根本没联网；答案精确定位到规则手册第 57 条，且「如果你不信，你甚至可以去翻 PDF，它会精确地定位到那里」——可一路回溯到原始 PDF 原文。 → 详细
- 杀手级功能：主持人脱口而出「我觉得这其实就是它的杀手级功能——能替你把整本规则手册过一遍」；Gabor 补一句「而且不只是规则手册，它实际上还会过一遍情境手册——情境手册通常是规则手册的扩展版，带例子」。 → 详细
- 一个轻松的彩蛋：连「这是不是 graph RAG 还是 vector RAG」这种技术细节他都没操心——「Claude Code 把这些全替你搞定了……我定义它应该用 Vertex 数据库时，这就隐含了 Vertex 是个向量数据库，所以它就隐含会用 embedding 了。」 → 详细
11
设计环节：Figma Make 出 brief + Mobbin 找灵感
- Gabor 只用 Figma Make 做设计 brief / style guide（排版、配色、CTA 按钮、颜色过渡、错误态），不用它做真原型——「如果把它跟 Claude Code 配合起来，我能做出质量更高的原型。」找灵感去 Mobbin（节目里口误成 spotted in prod；一个收录大量真实 app 截图的设计参考库）——「哪个抓住你眼球就点进去截个图，拿来用在你自己的 app 上」；他还拍了自己笔记本外壳的照片（去掉 Apple logo）当配色灵感。prompt 关键一句：「把它当灵感、不要照搬（use it as an inspiration, do not copy）」——不这么说 Figma 会拒绝帮你做拷贝。对 Lovable 的旧印象是被「AI 撒谎」坑过——「我发现一个 bug 让它修，它说修好了结果根本没修，一轮一轮兜圈子」，但他公允补充「相信 Lovable 这段时间进步了很多」。Figma Make 出图那刻他几乎失态——「看那些颜色……哪怕去年要做出这种质量的输入素材，你得雇一家 agency。」 → 详细 → 详细
12
工单与 Sprint：tag 变通 + 依赖映射 + 截图纪律
- MCP 没有创建真 sprint 的权限，变通办法是用它有权限的「标签 tag」把工单标成 sprint one / two。Gabor 讲了为什么非要分 sprint——「就跟任何其他软件开发项目一样，做软件的时候是有依赖关系的，你得确保有些东西在你开始构建另一些东西之前先做完，对吧，这就是为什么你需要 sprint。」 → 详细
- 截图纪律（重中之重，他强调到「我怎么强调都不为过」）：每张前端工单必须附截图或明确链接对应 Figma 文件。他把后果讲得很形象——「如果你不加截图，Claude Code 的 agent 就会做出那种典型的『一看就是 AI 做的』app，而不是你在 Figma 里设计的那个样子。它会做成那种典型的黑紫配色、一眼 AI 范儿的 app。」演示里点开一张工单，「我点开它，就会打开一个具体的屏幕……它已经选中了某个特定区域」——精确到屏幕的某块区域。 → 详细
- 工单规模的变化轨迹：epic 阶段 backlog 先有 29 张，Gabor 提醒「不止，因为每张 ticket 底下有些还带了子 ticket，还有依赖关系」，很快涨到约 35 张，他说「这些只是 epic，接下来它才会创建真正的 ticket」；最终演示收尾刷新时 51 张工单已完成、剩几个 bug 和 4 张在 backlog。 → 详细
- 一个诚实的教训（演示当场翻车的复盘）：设计阶段他没走「基于 ticket」的方式，而是直接把整份 spec 丢给 agent——「结果导致 context 太大，我猜中间发生了某种压缩，一些细节就丢失了。」最直观的证据：「我在上面连一个橙色的元素都没看到」（调色板没被完整用上）。他由此引出一句很关键的话——「基本上，如果你不让这些 agent 去对应真实的角色，你得到的 AI 垃圾内容（AI slop）就会更多。」 → 详细
13
后端与安全：密钥、成本、用量配额
- API key 绝不暴露到前端/源码，只存 Firebase Secret Manager（密钥库）——prompt 里写得极重：「API key 应该存放在 Firebase 的 secret store 里，绝不能暴露给前端或源代码，因为我不想因为不小心把 API key 暴露出去而产生额外成本。」主持人替观众点破后果：「一旦别人拿到你的 key，他们就能把 API 的用量记到你头上，账单得你来付。」此外还要给花费设兜底上限——「你要是傻到连一个消费上限都不设，又不小心把 key 暴露出去了，那确实可能出大麻烦。」 → 详细 → 详细
- 产品级用量限制：单用户一次对话（双向累计）超过 20,000 词就叫停、暂停该用户 24 小时并给警告，额度按设备跟踪（无需登录/账号）。隐私设计：用户数据只存设备端、服务端只处理不存储，因此不需要登录/SSO——「这也简化了移动 app 的发布，尤其第一次发布时」；演示中他还现场叫停了 Firebase 想自动启用的 Google/Apple 登录。 → 详细
14
模型选择、套餐与 Claude 用量曲线
15
权限与安全纪律
16
agent 自主时长 6 分钟+ 是关键解锁
17
对 dispatch / Cowork / open claw 的看法（且有反转）
- dispatch（灵感源自 open claw）：Gabor 觉得「没那么可靠、经常崩、产出质量不稳定」，用时必须盯着，「我经常得去告诉它：你漏了这块、那块。这有点烦」；但看好潜力——「它确实有机会替代一部分人对软件的需求，因为你只要用人话告诉它你想要什么，它就能做出来。」现场反转：主持人爆料「两周前你还觉得它们行呢」，Gabor 笑着招认——「两周前你问我 dispatch 怎么样，我说『绝了！』，可现在它又变得很脆弱了。我估计再过几周……就会变成『我的天，这简直是史上最棒的东西』。」open claw：他没怎么折腾，原因「挺深刻」——「我胆子不够大，不敢装在主力电脑上，于是单独订了一台 RAM 更大的，结果缺货得等，等它到货 Claude 已经推出了 dispatch。」定位：在 Claude 生态里 Claude Code 最强大、是这个用例首选，但他不把话说满——「我不至于说 Claude 是我做一切事情的终极首选」；Cowork/dispatch「还有点不太成熟、可靠性只能算中等，不过每天都在变好」。 → 详细 → 详细 → 详细 → 详细
18
Claude Code vs Codex / Lovable / Bolt
- Codex（OpenAI 同类工具）只浅试过——「用 Claude Code 对我来说就是更顺手，Codex 我就没再往深里研究」，对它没有强烈看法。「默认效应」反复出现：「这跟我之前试 bolt 又试 lovable 一样——头几步在 lovable 上感觉更轻松，于是最后就默认用 lovable 了。这次也基本一样，在 Claude 上一开始就感觉更强、更好上手。」（启示：第一印象更顺手的工具往往成为长期默认，哪怕后来差异不大。） → 详细
19
PM 为什么应该亲手做 agent（产品的未来是 agentic）
- Gabor 的核心论证——「如果他们理解今天的 agent 是怎么工作的、怎么表现的、有什么局限、用起来有哪些优点和坑，那么任何产品经理就更容易理解，自己手上正在做的那款产品应该怎么去服务用户。但如果你从不跟 agent 打交道，你就不会有那种感觉——跟一个 AI agent 协作到底是什么体验。」 主持人接话定性：「百分之百同意。产品的未来大体上会是 agentic 的。」 → 详细
- 主持人还把这层意思延伸到「决策模拟」——他举 Gabor 选 Atlassian 的例子：「他说『哦，他们有个 MCP server，我能很方便地连上去』。以后大家做决策就会是这种类型，而你会模拟做出大量这样的决策，这样你才能正确地排你的路线图优先级。」 → 详细
- 这个 app 还是作品集 / 不可辩驳的能力证明：上架 App Store 后可直接写进简历——「我可以给任何人看：嘿，这是我做的。我还能在这个 app 里做一个子板块，比如加个密码保护，在里面放上我是怎么把这个应用做出来的全部信息。所以这就提供了一个无可辩驳的证明：我作为一个产品经理，我懂这套系统是怎么回事，而且我能动手做出来。」 → 详细
20
PM 职业的两极分化（两年后差距大到追不上）
- 现状（Gabor 看得很清醒）：「每家公司都想做 AI。但产品经理在公司里的真实处境是：如果你是公司里少数幸运儿之一，正好在一个适合做 AI 的领域，而且你的领导也愿意往 AI 上投资，那你就能积累到 AI 经验。可大多数 PM 在日常工作里，未来一两年可能压根碰不到任何 AI 产品，只是因为 AI 没那么快渗透到每家公司的每个角落。」 → 详细
- 建议与那句标志性预言：「而对那些工作中没机会参与 AI 项目的 PM 来说，他们能做的就只剩下用 ChatGPT 让自己更高效一点，但这远远不够。两年后，那些动手做东西的人和那些只是把 AI 当效率工具用的人之间，差距会大到很难追赶。 所以我建议每个人都开始动手做东西——工作里没机会就在工作之外做——不是因为你想拿它创业，而是因为你想亲身体验，想证明自己有能力把东西做出来。」 → 详细
21
AIPM 证书该不该考
- 背景：主持人抛出市场行情——「我聊过的人都想转去做 AIPM……AIPM 薪水高 30%，岗位占所有公开 PM 岗的 30%。」Gabor 的观点同他对 Scrum/敏捷证书的看法——你需要的是知识，不是证书：「没人该为了证书而花钱去考证。花钱报课是为了学到东西……这些课程往往全自动，你交了钱不管有没有学到，最后系统都会自动生成一张 PDF。但等你真要上手做 AI，这张 PDF 几乎一文不值。」什么才是好课：「逼着你动手跟 AI 一起做项目的，因为那样你才真正积累了经验……最理想的是你不光做出了东西，还做出了之后能拿去分享的东西。」他还当场修正旧观点——「几年前我曾非常坚定地认为 PM 不需要作品集，但最近在修正：如果你能证明自己亲手做出过东西，那很有价值。」 → 详细 → 详细
22
调优故事：评分校准 bug（很好的演示素材）
- Gabor 在 app 里加了 observer mode（观察者模式）：打开能看到后台搭了什么、知识库有哪些、用了多少 token、延迟多少——专门为给别人演示/讲故事用。他说设计动机就是「如果哪天我要把这个 app 展示给别人看，我就会打开这个观察模式，带着对方走一遍我在后台都搭了些什么、这些东西是怎么运作的、知识库都有哪些」。 → 详细
- 他挖出的 bug 故事（一个绝佳的「演示故事」范本）：app 里有一套多组件评分系统（用来判断规则手册的某一段跟用户的提问是否相关、给个相关度分数）。这套打分分不清单复数和近义词——
penalties（点球/判罚，复数）和penalty（单数）、boarding（撞栏犯规）和board（栏板）被当成不同词，再加上「有些阈值也设得太严了」，结果没能识别出规则手册里正确的那个章节。他特意把这件事记录下来，因为「当我讲这个故事、解释这个 bug 是怎么影响真实用户体验的时候，这就是一个很好的——不能说是作品集吧——但是一个很好的演示故事」。 → 详细 - 彩蛋：启动画面（splash screen）藏了句裁判台金句——「『我瞎了，我聋了，我想当裁判』（I'm blind, I'm deaf, I want to be a ref）。这是我当裁判那会儿从看台上、从观众那儿听到的好玩的话之一。」 → 详细
23
Gabor 的逆袭：从 Deliveroo 骑手到谷歌 PM
- 失业：2020 年初入职新公司，4 月 COVID 重创公司。他刚从匈牙利（住了 30 年）搬到伦敦，又被要求以自雇身份（self-employed）入职——别人被裁能领政府补助，他「因为是自雇者、只干了两三个月，什么都没拿到」，封锁困住他、积蓄被房租掏空。只能在每周高峰（周五/周六下午）当 Deliveroo 骑手——「很磨人、很让人放下身段，但现在成了一个不错的故事。」 → 详细
- 攻下谷歌：先找份固定期限合同站稳脚跟；之前面 FAANG 总在终面（the loop）挂掉，于是网上找了个面试教练，立下对赌——「没进我付你一半，进了我付你两倍。」结果他拿到了两倍的钱。方法（极可复制）：备考约 200 小时，节奏每周 4 场模拟面试 + 1 场教练课；组队是意外收获——「我找到另外三个人，四人里有三个进了谷歌」（之前互不相识，网上找到彼此）。练习社群 IGotAnOffer.com / Exponent（Lewis Lin）门槛很硬：得手头正有 FAANG 在面试、把猎头邮件发过去才能加入。 → 详细 → 详细
- 熬夜节奏：周末能轻松干到凌晨四点，工作日得逼自己去睡——因为「早上要去健身房，不睡就没法早起去健身」。 → 详细
24
闪电问答 / 收尾
- 最爱的工具：第一是 Claude Code，第二是 NotebookLM（谷歌的资料整理/问答工具）——「当你想理解复杂的问题、复杂的生态系统或者复杂的话题时，你只要把你知道的一切都丢进去，它就会帮你把这些梳理清楚。」（演示尾声主持人还真用 NotebookLM 让 Gemini 复盘了一遍全流程，只错了一处——把「用 Claude 生成 prompt」说成了 Confluence。） → 详细
- 想上手该从哪开始：只想自己玩，就打开最爱的 AI（ChatGPT/Gemini/Claude Code）开始问怎么做——「如果你有时间，这是最省钱的入门方式」；想加速、要结构化路径，就找人帮忙（他在 Maven 有 AI builder 课）。 → 详细
- TestFlight / App Store 现实：上传 TestFlight 后苹果处理要几分钟，处理完就能邀请内部测试员「无论身在何处都能下载」；之后正式发布还需补截图、support URL（支持页）、privacy URL（隐私政策页）——而这些「也很容易用 Claude Code 生成，而且你可以同样把它托管在 Firebase 上」。一句重要提醒：因现在做 app 门槛极低，首次提交 App Store 审核突然变得很慢——「我原本以为最多一两天，结果第一次审核花了一个多星期。所以你得做好心理准备。」 → 详细
- 主持人定性：这是一堂「大师课」，教 PM 怎么戴上创始人/产品构建者的帽子——「教 PM 怎么有可能戴上创始人的帽子，开始让自己变成一个产品构建者……两年后你和其他 PM 之间的差距会大得惊人，所以一定要利用好这段时间。」 → 详细
25
金句池（可直接引用）
- 「如果你有一份好的 specification，你就会有一个好的产品；如果你的 specification 是一坨，那你就会得到一个不及格的产品。」 → 详细
- 「vibe coding 不过是给那些没法维护的低质量源代码换了个马甲。」（Gabor 引 Reddit 上戳中他的一句话） → 详细
- 「定义阶段才是真正的投入……这件事一旦做完，写代码就相当快了。而这恰恰是大多数产品经理被卡住的地方。」 → 详细
- 「如果你不让这些 agent 去对应真实的角色，你得到的 AI 垃圾内容就会更多。」 → 详细
- 「两年后，那些动手做东西的人和那些只是把 AI 当效率工具用的人之间，差距会大到很难追赶。」 → 详细
- 「『我瞎了，我聋了，我想当裁判。』」（启动画面彩蛋） → 详细
26
联系方式 / 资源
- 嘉宾 Gabor Meer：LinkedIn（主持人推荐关注）；Maven 课程「用 Claude Code 从 PM 进阶为 AI builder」——4 周项目，承诺真正发布一个上架 App Store/Google Play、内置 AI 功能的 app，含 Claude Code / Flutter / Firebase 技术栈、每周四现场工作坊、带里程碑清单的「构建伴侣」app、录播终身访问权 + PM 社群，定价 $2,995（主持人描述链接有折扣）。适合人群：想转 AI PM 但现岗没机会做 AI 产品的中高级 PM、有产品 idea 的技术型 IC、职业转型中的 PM——「你不需要会写代码，你只需要有意愿去理解软件是怎么运作的」。 → 详细
- 主持人 Aakash Gupta：礼包 bundle.aakashg.com（年付订阅免费拿九款 AI 产品一年：Dovetail、Mobbin/Maze、Linear、Reforge Build、Descript 等）；求职项目 landpm.com（12 周、首期 40% 学员结业前就找到工作，拿过 OpenAI/Anthropic offer，承诺至少两个面试否则退款）。 → 详细