vibecoding面试轮

• Aakash Gupta 开场说他刚跑完 Uber、Atlassian、Cisco、Roblox 等几家公司的 AI 岗面试，而他辅导的 PM 里越来越多人撞上一种新轮次——"它不是传统的 product sense 轮，也不是工程师的 coding 轮，而是两者的混合体，我管它叫 vibe coding 轮"。vibe coding（凭感觉编程，即你用自然语言指挥 AI 写代码、自己不逐行敲）在面试里的具体形态是：给你一道产品题，你要一路把它推到能在浏览器里打开的 prototype（可交互原型）。→ 详细
• 岗位含金量摆在这儿：Google、Meta、OpenAI、Anthropic 这类公司的 AI PM 岗，薪酬从 30 万美元一直到 100 万美元以上。而且是真的当场看你操作——他采访过的 Laurel AI 的 CPO Jiona Zen，会直接让候选人共享屏幕，展示"你怎么用 AI"。→ 详细
• 一个关键的反常识：市面上讲 vibe coding 面试的内容几乎都在教"从零做一个全新产品"，但真实面试里你最可能拿到的题是"在一个已有的成熟产品上加一个功能"。本期整场模拟面试就按这个设定来。→ 详细

• 面试官给的题：假设你是 LinkedIn 的 PM，LinkedIn 很在意用户与人脉保持联系，但人们普遍对主动联系有顾虑，希望 AI 能降低这些障碍——请构思一个功能，并把它做成 prototype。全场约 45 分钟，其中约 30 分钟要花在 vibe coding 上。面试官原话："我会给你一个 prompt，但我最想看到的是你 vibe coding 的整个过程。"→ 详细
• Aakash 的第一个动作是复述题目确认理解，第二个动作是反问"这个功能的目标是什么？为什么做它而不是别的？"。面试官答：用户来 LinkedIn 是被动消费内容，我们希望他们主动和人脉互动，而这件事本身有认知负担，把它降下来就能提升留存（retention，即用户隔天/隔月还回不回来用）和参与度。→ 详细
• 他随即把目标接回公司使命："LinkedIn 一直强调要创造经济机会，人们获得经济机会的方式就是留在平台上、和人脉互动，所以目标是把他们从被动的内容消费者变成主动的互动者。"面试官在最后复盘时专门表扬了这一步——"你能把它一路连回公司的使命，这就把'用户'牢牢锚定成对公司至关重要的东西"。→ 详细

• 面试官同意给他两三分钟整理思路，他回："其实我都不需要两三分钟，30 秒就够了，因为我更想边想边跟你一起讲。"在限时的面试里，把思考过程外放本身就是被评的对象。→ 详细
• 更值得抄的是他对 AI 分工的这句总纲："AI 可以做中间那 60% 的活儿，但前面那 20%——最初的思考——依然要人来做；最后的打磨、终稿的收口，也非常需要人来做。所以我想先以人的方式开场。" 于是他第一步用 Miro 白板手动分层用户，全程不开 AI。→ 详细
• 他当场把整场的四步计划报给面试官（这本身也是加分动作，让评委知道你的路线图）：① 先想清楚选定方案的 PRD 大概长什么样；② 用几个不同的工具分别做 prototype；③ 选定一个工具、在它上面迭代；④ 最后可能还把 backend（后端）也搭出来。时间分配上，他自己框定"只花五六分钟，几乎是用倍速跑一遍一场典型的 30 分钟 product sense 面试"，然后就切共享屏幕。→ 详细

• 第一刀沿用面试官给的背景：99% 的人消费内容，1% 的人生产内容——但他立刻指出这跟"跟人脉互动多少"是两个正交的维度，不能混着切。→ 详细
• 第二刀才是真正相关的：在任意一个月里，约 95% 的人完全不和自己的人脉互动，5% 会互动。产品要打的是那 95%。→ 详细
• 第三刀把那 95% 再拆成三桶：5% 正在积极找工作；80% 是想维护职业形象、为将来找工作做准备；15% 压根不在乎自己的职业发展（光谱一端是不做职业优化的人，另一端是"已经太有钱了"的人——他顺手讲了个梗：Apple 新任 CEO 连 LinkedIn 账号都没有）。他专门解释了为什么要硬标数字："我之所以要给出数字，是因为我想对每一组有多大有个体感。"→ 详细
• 选靶的逻辑是两条腿：80% 那桶最大，5% 找工作那桶最好切——"这个最大，那个最好切，我觉得我们可以把这两个都作为重点方向，没必要非说'我们只选一个'。"找工作的人要的是：referral（内推）、在目标公司建连接、跟职业上走在前面的人聊（"就算我不是冲着 referral 去的，我也想跟他聊聊，学他是怎么做到的"）、以及激活自己的存量人脉（比如校友）。→ 详细

• 他正要继续挖"维护职业形象"这桶的触发点时，面试官打断并重新聚焦："我更希望你多花点时间讲讲：你觉得阻碍人们去联系自己人脉的障碍是什么？……如果你能讲讲究竟是什么让人们不敢联系、或者让联系这件事变得尴尬，会更好。"并直接送了他一个假设——"我们可以假设他们一直处在'被动找工作'的状态"。→ 详细
• 他的处理方式是当场接住并感谢："那我们就聚焦在'被动找工作'的这群人上，也谢谢你帮我在用户这块加速。"——收尾时 Aakash 自己也强调：当面试官基本上直接把解法递给你的时候，你要愿意顺着往下走。→ 详细

• 他先列出认知层面的障碍：你连自己当初是怎么认识这个人的都忘了，也忘了为什么需要跟他聊，甚至不知道找他能有什么用。他举的三个具体用例：你正想跟他公司谈一笔合作、你要去参加一个他也会去的会议、你正在解决一个他在自己工作里也解决过的问题。→ 详细
• 然后他做了本场最被表扬的一件事：不推演，直接把 LinkedIn 打开，当场做一次 live product audit（真机体验走查）。他点进"我的人脉"tab，发现它跳到邀请列表；发现 catch-up（叙旧）功能是个空状态；一边走一边把截图往 Miro 里丢。→ 详细
• 走查里挖出的第二个坑更离谱："动态更新"这一栏跟通知绑定了——"我必须打开应用内通知，才能看到工作变动的信息。非常奇怪。"打开之后显示"暂无近期更新"，而"拓展人脉"按钮又把你甩回原地——"所以那个按钮基本上是完全坏的"。→ 详细
• 第三个坑：他点进一个好友（Anthropic 的 member of technical staff）的主页，"却完全不知道我是怎么、为什么跟他连上的，也不知道我们是什么时候连上的"。由此收敛出两块要改的地方：一是推荐"该跟谁聊"做得很差；二是定位到人之后没有足够的信息去跟他聊。→ 详细
• 他还顺手验了现成的 AI 能力：进消息框点"Write with AI"生成"介绍一下你自己"——等了挺久但确实有。面试官当场吐槽："不过这里面破折号（em dash）多得有点吓人啊"——意思是一点都不像人写的，而且没有把正确的上下文拉进来，不管是你跟这个人过去的互动，还是你跟他更大范围的关系。→ 详细

• 面试官给出了 LinkedIn 内部的判断，也是本期最漂亮的一句问题重构："你这张人脉网真正的价值在于那些相对弱的关系（weak ties）……问题不在于你忘了，而在于你找不到一个不尴尬的理由去联系他。"→ 详细
• 他顺势把 Aakash 走查出的缺口翻译成框架，并要求他带着这个框架走完全场：A，为了一个不真诚的理由去联系别人很尴尬；B，冷联系（cold outreach）对大多数人来说本来就难。同时明说"我更想多看看 prototype 那部分，所以我才往这个方向推"——于是问题空间和方案空间的完整探索被直接跳过。→ 详细

• 他给出的 PRD 骨架非常干净。总体目标：通过重新连上你的弱关系来创造经济机会。**非目标（non-goals）**明确列三条：垃圾消息（会让人离开平台）、没有上下文的消息、给你其实不认识只是加了好友的人发消息。→ 详细
• 成功指标拆成先导（leading）和滞后（lagging）：先导 = 多少人读了消息、多少人回了消息；他还补了一个很有意思的设想——"我不觉得我们真的会去读用户的消息内容，但如果我们真的读，甚至可以做一个 LLM judge（用大模型当评委）来判断他们后来有没有真的一起做成什么事"。滞后 = 留存。→ 详细
• 他明确点名了三个"不可妥协项"："所以我们有了整体假设、有了上下文、有了非目标。我觉得这三条是写出一份好 PRD 的三个不可妥协项。"——注意这三条不包含界面、不包含排期、不包含技术方案。→ 详细
• 面试官这里插了一刀，要求把关键词定义死："如果能定义清楚'弱关系'到底长什么样，会很有帮助；还有你说'带着正确的上下文'——你怎么看待 LinkedIn 上已经现成的上下文，跟你和这个人更广泛的关系之间的区别？"Aakash 当场给出可执行定义：弱关系 = 你的一度人脉，但过去 3 个月里你没给他发过消息、也没在他的内容下互动过。→ 详细
• 平台上现成的上下文他也列了清单：共同雇主、共同的学校、地理位置、互动数据，以及（不确定实际会不会用的）求职申请数据——"你们是不是对同一个领域感兴趣"。"数据从哪来"在 PRD 阶段就被拉到台面上，而不是留给工程。→ 详细

• 转到做原型时，他先解释了为什么前面舍得花那么多时间在体验走查上："如果拿我三年前做的时候和现在对比，很多技巧其实已经消解掉了——模型越来越好，所以前期的定义反而更重要。"→ 详细
• 他在 Claude Code 里开了一个空文件夹，第一件事不是提需求，而是"把这个文件夹的上下文搭起来"。面试官抛来一个刁钻问题："如果你有一根魔法棒，可以给自己配一个 harness（脚手架），你最想往里放的前三样东西是什么？"→ 详细
• 他的答案是三样：① design system（设计系统）；② 整体上下文——公司战略和历史功能，以及自己的 skill；③ 一个 prototyping skill。 他还提到自己平时可以直接把"我自己的 PM operating system（PM 操作系统）"拉进来。→ 详细
• 落地的 prompt 极简："假设你是 LinkedIn 的 PM，只用公开信息，建一个 AI prototyping skill，再把 LinkedIn 的 design system 建出来。"配料是他刚才在 Miro 里截的那几张图——"我甚至没有在 prompt 里把它们摆得特别讲究，因为我发现……它是能处理好的"。他还专门说明这一步的产物就是他的 harness。→ 详细
• 收尾复盘时面试官把这一步单拎出来定性："你一上来就先立了一个 harness，正是这个 harness 之后才能把 design system 拉进来，我觉得这一步相当关键。"→ 详细

• 核心做法："我其实不会只用 Claude Code。我发现一个做法很有用：写一份 prompt，然后拿它跨多个工具去跑。"→ 详细
• 工具各有各的用途，他讲得很清楚：Claude Code——有 harness、能先建 design system 和 context library；Magic Patterns——"我喜欢它的地方是它不建后端，因为只做前端，所以特别快"；Lovable 是他做这类活儿"第三喜欢"的工具；Bolt 也在名单里。对 Magic Patterns 这类没有 harness 的工具，他的办法是先去 Claude Chat 让模型帮他写 prompt："给 Lovable、Bolt、Magic Patterns 这类 AI prototyping 工具写一个 prompt。"→ 详细
• 给 Claude Chat 喂上下文的方式也很土但有效：直接把 Miro 白板整块截图丢过去，"如果画面太小它可能读不清，所以我会把其中一些信息放大一点"。任务描述里他补了三个落地界面：首页、Grow your network（拓展人脉）页、以及一度人脉的个人主页。→ 详细
• 于是同一时刻他手上有四条线在跑：Claude 里在生成 prompt、Magic Patterns 已登录待命、Claude Code 里在搭 harness、Lovable 待命。"接下来就有点变成等 Claude 了，所以我才喜欢搞并行系统。" 并行的第一动机是"不让自己空等"。→ 详细
• 他还有一个每次都做的动作：sanity check（收货核对）——回 Claude Code 看它建的 design system 和 context library 怎么样，"挺好……不过 context library 我现在看下来，好像还需要更多信息。比如这个 product 部分，就没有我们刚才聊到的那些上下文"，于是决定把 Miro 白板补喂进去。建完不是完，要开箱验。→ 详细

• 面试官中途叫停："你能不能花几秒钟讲讲，是什么让这成为一个强 prompt？一个好的 prototyping prompt 和一个不怎么样的 prompt，区别到底在哪儿？"→ 详细
• Aakash 的答案是四条，而且他强调"跟任何 prompt 都一样"：① 给它一个非常清晰的任务步骤定义——所以这份 prompt 开头就是"生成五个不同的 UI 概念"；② 定义好你的上下文；③ 说清楚你想要的输出是什么——要有明确的 requirements 段和 output 段；④ 说清楚你不想要什么。他对照着自查："我觉得它其实四个要素都齐了，我挺满意的。"→ 详细
• 面试官立刻做了一次实操压测："你不想在这上面给它一些 LinkedIn 的设计指引吗？"Aakash 先辩解说写在最前面了，看了一眼后认错："是我看错了。对，是有一些信息，但确实可以更好。老实说你是对的。"然后当场把几个正在跑的 prompt 全部停掉去迭代——"很多时候我们确实需要迭代 prompt"。→ 详细
• 迭代时他做了一个重要的分工判断：发散不该交给便宜模型，也不该交给 prototyping 工具——"我不确定我真的想让 prototyping 工具去生成这五个多样化方案，我甚至不想让 Sonnet 来生成，我想让 Fable 这种模型来生成。"理由有二：他更信更强模型的品味；以及"我也不想把太多东西喂给那些工具，它们有时候连底下用的是哪个模型都不告诉我"。→ 详细
• 顺带出现的一个行业张力：设计师会争论**"code first 还是 canvas first"**（先出代码还是先出画布），他说两条路都行，但这次选择在更强的模型里先发散。→ 详细
• 还有一个他"特别喜欢的工作流"值得单记：先让工具把 design system 定义出来，之后再喂给它更多信息——一句"学习 LinkedIn 的 design system"加一张截图，就这么简单。同一套 prompt 他原样丢给 Magic Patterns，此刻"等于有三个 AI agent 同时在给我们干活"。→ 详细

• Fable 跑出的五个概念（他吐槽"格式排得不太好看"，但时间紧就往下走）：① 首页 feed 里的"温度信号"守门层；② 一个独立 tab，把"拓展你的职场人脉"做成收件箱；③ 把一度人脉渲染成可视化关系图；④ profile 上的上下文层；⑤ 首页通知。→ 详细
• 评估用的是四个问题："这个有多创新？它对成功的推动力有多大？这个入口界面拿得到足够的曝光面吗？它能不能推动我们的终极目标？"当场结论：热力图/关系图比 reconnect 队列创新得多但另外两维打平；"温度前置露出"量大、拉动强但不创新。→ 详细
• 一个容易被忽略的分类动作：他判断第 4、5 个"其实不是方案，是承载功能的入口界面"，可以跟任何一个主方案共存，所以真正要在里面挑的只有一号和三号——最后决定"把几个概念组合起来，三号到五号组合起来"，再让模型生成给三个工具用的最终 prompt。→ 详细

• 面试官问如果还要做后端会怎么做。他的回答："我对'IDE 加上 Codex、Gemini 或者 Claude 模型'这套组合毫无抵抗力"——现场用的就是 Cursor 加 Claude Code。→ 详细
• 前端产物怎么交接到后端：Magic Patterns 支持直接导出；Lovable 可以直接 publish 到 GitHub。所以他的流程是 Lovable 推 GitHub、Magic Patterns 导出，然后拿进 IDE 继续。→ 详细
• 模型分工的 90/10 口径（很具体，值得记）："90% 的情况我是 Claude 党，胜过 Codex 和 Gemini。剩下那 10% 我真正会用 Codex 的场景，是超长时间跑的编码任务，比如我真的在写后端的时候。"前端他偏爱 Fable 5 的审美；后端长任务上 Codex 的两条理由是"比 Fable 5 便宜一点"和"它就像一头老黄牛——能连着干一整天，而 Fable 大概只想干一个小时"。→ 详细

• Magic Patterns 问要不要先搭系统骨架（scaffold），他说要。Claude Code 那边他故意给了更大的自主权（因为底下是 Fable），结果它自己又想出了五个概念并逐个写 HTML。→ 详细
• Warm Threads（温度会话）：在浏览器里打开——"漂亮，我很喜欢这个"。面试官附议它"在忠实还原 design system、把正确的上下文拉进来这两件事上都做得挺不错"。Aakash 给"满意"下的定义很硬："它在 design system 之内，而且是一个真的能跑通的功能。"→ 详细
• Reconnect Queue（重连队列）："这周值得联系的人" + "带上下文起草"——正对着刚才定义的问题。Home Moments（首页时刻）：他判断"差不多是个 P2 或 P3 的功能"，因为前面几个"触达的是更常见的入口界面，发生得更频繁、覆盖的人更多"。Drafts（草稿）："它确实像你说的那样，把上下文用得很到位。"→ 详细
• 最有意思的一次判断反转是 Constellation（星座图）："我们之前在聊天里讨论的时候，我以为 constellation 会是那个杀手级功能。现在真看到了，我心想：呃，也许不是。"——把东西做出来再判断，和在脑子里判断，结论不一样。最终他按 product sense 和 product taste 选出最强的三个：Warm Threads、Reconnect Queue、Drafts。→ 详细

• 时间到了，他用一段话把后续路线讲完：把这几个整合到一起 → 先只停在前端 → 自己和自己团队先做一轮用户测试 → 放到 UserTesting 或 UserVoice 这类平台（"在那儿你可以直接付钱找人来跟一个前端交互"）收反馈 → 拿到正向信号后再做后端，把它做成真正能跑的活 prototype，接进 GitHub、从真实代码库和真实 design system 里拉东西 → 然后可以做个 0.1% 的 AB test。→ 详细
• 最后他还把方案接回指标闭环：把有温度的人脉推到首页 feed 和"拓展人脉"tab、配上带上下文的消息，"一定能在先行指标上——比如发出去多少条消息、多少条得到回复——打出明显的增量，也希望能带动滞后指标，比如留存"。→ 详细
• 他自评 8 分（满分 10），并且诚实说出遗憾："我有点遗憾没能看到 Magic Patterns 和 Lovable 跑完……这里最大的挑战永远是怎么在 30 分钟里把所有东西走完。"如果重来，他会在用户和问题上再快一点。→ 详细

• 面试官对 Aakash 前半段的定性是双面的："从传统的 product sense 角度看，你做得非常好……但在 prototyping 面试里，更关键的是你得快速把这部分过掉，好腾出时间展示你在 prototyping 部分的本事。"→ 详细
• 然后给出本期最该抄进笔记的一句："诀窍就在于：在更短的时间里达到同样的思考深度，从而让你的 prototype 也是有深度、有想法的，而不只是浮在表面。……如果你在前半段没有投入足够的时间和思考，你的 prototype 就不会出彩。"→ 详细
• 配套的一句同样硬："面试官不是只来看你的过程的，他们同时也在评估你最后落到的结果。"——过程分和结果分是两笔账，都要给。→ 详细

面试官明确说"Akash 你用的这套框架，拿去应对任何 prototyping 面试都很好用，那我就直接用它"，于是按七段逐项打分。总评：8.5 到 9 分，"非常清楚、非常有把握的一个 pass"（Aakash 自评 8 分，被面试官认为"把自己评低了一点"）。→ 详细

• ① 用户（user）：8.5–9 分。 好在哪：分层做得非常好（从"人脉活跃者"到"求职者"），给每一层都配上数字"特别有帮助……这总体上是很强的直觉"；而且能把它一路连回公司使命，把用户锚定成对公司至关重要的东西——"表达干净利落，判断也对"。改进建议：在面试官把他往回带之后，本该再补一小段探索，讲讲"维护职业形象"那一层要怎么保住。→ 详细
• ② 问题（problem）：8 分（全场最低之一）。 扣分点很明确："因为我得推你一把，你才走到那个底层的核心问题——门槛、认知负荷等等——而且是更快一点走到。" 也就是说，问题的深度是被面试官推出来的，不是自己走到的。→ 详细
• 但同一维度里有全场最大的亮点：现场做的 live product audit"是这一段的亮点，这一点大概比 95% 的候选人都强——那些人只会对整个体验做理论推演，而不是真的把 App 打开"。他找到的空 catch-up 状态、诡异的通知耦合"全都是非常真实的问题，面试官看到会想：啊，对，我明白它今天为什么不成立了"，并且能顺畅地把人带进后面的方案环节。→ 详细
• ③ 方案（solution）：8.5–9 分。 好在哪：概念渲染出来之后能给出五个方向非常清晰的想法。改进建议："这里真正能拉开差距的，是对方案本身有更多具体细节、更强的观点。"但面试官明说因为时间限制不扣分，并补了一句区分："如果是在时间宽裕得多的 product sense 面试里，那'品味和观点'这一块的权重就会大得多。"→ 详细
• ④ PRD：稳稳的 8–8.5 分。 好在哪："那些不可妥协项你都干净利落地打到了：你有一组非常清晰、锋利的目标，还有一组非目标；你还把先行指标和滞后指标清清楚楚地分开了，这个相当漂亮。"→ 详细
• ⑤ prompt：9–9.5 分（全场最高）。 关键判词很反直觉："虽然你的 prompt 是用 AI 生成的，但我觉得这个做法对很多人来说并不是自然就能想到的。所以尽管你的 prompt 是 Fable 或者 Sonnet 写的，我还是要给你 9 到 9.5 分。" 更打动他的是能讲清楚一个 prompt 好在哪——"如果给你时间、给你足够的脑力空间去写这个 prompt，我有信心你能写出一个很棒的 prompt。而看着你用 AI 来写 prompt，算是锦上添花。"→ 详细
• ⑥ 并行（parallel）：没给具体分数，但定性最高。 "这是你框架里非常独特的一环，也是大多数人会低估、或者用不好的部分。" 面试官的评判理由不是"用了多少工具"，而是**"你很清楚什么时候该用什么，甚至清楚该怎么用"——"你没有拿 Claude Code 去做比方说想法 X，你是专门用它先搭 harness，然后再跳到下一步；你用一个非常特定的工具去生成你的想法图谱。"结论："这种'同时并行操作一套相当宽的工具'的能力，正体现出大多数面试者和面试官想要考察的那种 AI 原生度。"**→ 详细
• ⑦ 后端（back end）：8 分（另一个最低）。 "我们没能在后端上花太多时间，但你讲 Codex、讲你会怎么走完剩下那段旅程，对我来说已经是足够有把握的信号了。"改进建议明码标价："如果时间够、你能再往后端设计里多讲一些，我大概会给到 9 到 9.5 分。"→ 详细

• 面试官的结语："大多数人都低估了在一个成熟的存量产品上做迭代有多难——比想出一个全新的点子难多了。 说一句'好，给一批全新的用户造一个产品 X'，那是相当容易的。但当面试官让你去演进一个已有的产品和它的功能时，其实已经存在一堆约束和假设了，而这些东西往往没被摆到台面上，也没人特意提出来。所以这种题反而更难接得住。"→ 详细
• Aakash 自己也补了一个重要的现实说明：这道题他事先没见过，所有变化球都没提前对过，全是现场的——"你必须见招拆招，同时还得盯着计时器"。→ 详细

• 他把整套东西命名为 UPS PPPB 框架——即 User（用户）/ Problem（问题）/ Solution（方案）/ PRD / Prompt / Parallel（并行）/ Backend（后端） 七段，这是他和 Anka 在付费 cohort 里教的内容，本期算"放了一点内部料"。→ 详细
• 时间分配没有标准答案："你能看到，这套框架你得按时间去调整。有时候后端拿不到 10 到 15 分钟，有时候某些环节就得压缩时间。……这种面试本身还在演化中，并没有一个明确的时间分配标准。"另一条实战建议：看清你面试官的风格——当他基本上直接把解法递给你时，你要愿意顺着往下走。→ 详细

• 视频中段插播 Land PM Job 第四期：第一期 30 名学员、第二期 50 名、第三期 75 名；第四期八月开始、为期三个月。→ 详细
• 师资与内容：Aakash 本人做周一早上的简历/行为面试/LinkedIn 逐份过；Bart Jaworski 讲 2026 年的 PM 基本功——怎么写 AI PRD、怎么用 Claude Code 做 AI prototype；Ang Vermani（Uber 的 AI PM）讲 AI 产品管理；Prasad Reddy 做一对一的市场复盘、LinkedIn 主页诊断、候选人与市场匹配度评估。→ 详细

本期没有 lightning round，但结尾有一段明确的"怎么准备"清单，逐条录下：

• 练时间把控。 "你必须见招拆招，同时还得盯着计时器。所以我会说，练一练你的时间把控。连我自己这次都还可以做得更好。"→ 详细

• 用不同的工作流、不同的工具去练手感和自信。 "多用不同的工作流、不同的工具去练，把手感和自信练出来。这也是我今天做的事情里我自己最满意的一点。"→ 详细

• 练"说清楚"。 "然后练一练怎么把话说得干净利落：这些是问题，这些是解法，这就是 PRD。 当你把这一整套都串起来，你就已经做好准备拿下这场面试了。"→ 详细

• 主讲/被面试方：Aakash Gupta（本频道主理人，同时是本场模拟面试里的候选人）

• 课程：Land PM Job 第四期 — landpmjob.com（八月开班，三个月）→ 详细

• 本期提到的其他人：Jiona Zen（Laurel AI 的 CPO，面试里会要求共享屏幕看你怎么用 AI）、Bart Jaworski、Ang Vermani（Uber 的 AI PM）、Prasad Reddy、Anka（cohort 里与 Aakash 合教 vibe coding 面试的搭档）

• 本期出现的工具清单：Claude Code、Claude Chat、Cursor、Codex、Gemini、Magic Patterns、Lovable、Bolt、Miro、GitHub、UserTesting、UserVoice；模型层面提到 Fable / Fable 5 与 Sonnet