非技术PM的ClaudeCode配置

主持人 Aakash Gupta 对话 Andre Albuquerque（运营欧洲最大产品 builder 学校 builderscamp.com，超 4000 名学生），开场定调「他要把这些东西全都免费分享出来」。核心反差点：市面上「90% 的教程都默认你是技术出身、是 Claude Code 的专家」，本期反其道逐级手把手带非技术 PM 上手，Aakash 放话「YouTube 上没有第二期这样的节目」，并承诺给一份「周一早上的行动路线图（Monday morning roadmap）」拿去跟工程师谈。他给 Andre 的人设：「特别擅长用最简单的方式讲清楚，帮你从零开始建立认知」，保证非技术 PM 看完「更有信心去用 Claude Code」。→ 详细 → 详细

• Andre 回答「非技术 PM 最大的问题」不绕弯：很多公司里这些 PM「就是官僚（they're bureaucrats）」——困在 Jira、Linear、PowerPoint 里，「他们其实并没有在『建东西』，不写代码、不加功能」，要做就得依赖技术团队。他补一句这不是态度问题：「倒不是说他们不想做」，而是三因叠加——一是不知道怎么做；二也许是管理文化不允许（management culture doesn't allow them）；三也许是没有相应的技能和工具。总之他们「基本上就是在那儿干等着，依赖所有人」。→ 详细
• 反面参照是 AI 原生组织和跑得飞快的新公司：那里能看到产品经理（不管懂不懂技术）真在动手建东西，看到「CEO 给 GitHub 上的代码仓库做贡献」。具体例子——「你看看 Shopify 的 CEO，他的 GitHub 提交记录是全绿的（his GitHub is fully green）」（几乎天天往代码库提交）。团队形态剧变：「一些团队以前可能是 10 个、20 个人，现在变成了超精简的小团队，而且每个人都在真正地往生产环境推新功能、新代码」。→ 详细
• 贯穿全片的判词（原话）：「如果你是个非技术 PM，而你的工作还停留在管 backlog、写 issue、做 PPT 去给某个人汇报，而你根本没在真正建东西——说实话，你正在被甩在后面（honestly, you're being left behind）」。Andre 强调连锁反应：你要「彻底改变看待自己角色的方式」，而这又会「反过来影响团队里的每个人，从而把整个 squad（小队）都彻底重塑」。→ 详细

Andre 把「从『我不是开发者、不会写代码』到动手建东西」的真实路径拆成四级，反复强调这是对他个人管用、给了他「安全感（comfort）」的打法，不代表对每个人都管用——工具他「都试过一遍」。一句话版：Level 1 用 Lovable；Level 2 Lovable + Claude Code 混合；Level 3 Claude Code + Vercel 作基础设施；Level 4 多个 Claude Code、多个 Vercel + 「大量自动化和 agent」。整套讲法就是不断「给你们叠加复杂度（keep layering on the complexity）」——一层稳了再加一层。→ 详细

• 为什么从 Lovable 起步：Andre 给三个理由——① 它比直接跳进 IDE、跳进代码环境「没那么吓人（way less scary）」（IDE = 集成开发环境，对外行有门槛）；② 半开玩笑「团队是欧洲人，我当然会很支持他们」；③ 更实在的是这产品「对任何从没写过代码、甚至可能有点害怕动手的人都非常容易上手」。→ 详细
• 强烈建议从个人项目而非工作项目入手：理由是个人项目能「真正放开去探索这个工具」——没风险、不是给公司仓库做贡献、「甚至不需要任何访问权限」、「代码也不需要写得多漂亮，因为在这个阶段谁在乎呢，烂就烂吧，没关系」。Andre 的第一个产品就是给自家避暑度假房做的「入住档期管理工具」——他家「家人挺多的」，需要管理「一年中某些时段谁住这套房、谁会去、房子是不是被订满了」，纯家用、非商业。→ 详细
• Lovable 的妙处（不用懂也能用）：它「把很多技术栈都帮你打包好了」，让你根本不用操心数据库、身份认证（authentication，即登录注册那套验证身份的流程）。Andre 点出非技术者特有的盲区：「这类东西非技术的人往往根本不知道它们重要」——「如果你在产品或工程领域待过，你知道 authentication 是什么……可如果你从没在那种环境里工作过，你甚至不知道这是个重要的东西」。一个具体学习技巧：在 prompt 里一直追问「我是不是漏掉了什么」——「如果你没在质疑、没在追问，它总会把反馈反给你，就像你在和一位资深工程师合作」。→ 详细

Level 2 是「一个意外的演进（accidental evolution），但对我来说效果特别好」：Andre 当时「想做更多的事」，而 Lovable「在一些地方还是有点受限」，于是装了 Claude Code（「装在了 Claude 的桌面 app 上」）。初见感受他没掩饰：「说实话这有点吓人（it's a bit scary）。你落到这儿会有点慌，不知道这是什么，你看不到一个产品」——不像 Lovable「能看到产品摆在面前，有聊天框、有反馈」。核心机制是三件东西串成一条链：先 GitHub 注册账号（「超级简单」）→ 把 Claude Code 连到 GitHub → 把 Lovable 连到同一个仓库；三者一同步，「你在 Claude Code 桌面 app 上写代码、更新了 GitHub 仓库，Lovable 也会同步到那次更新」（GitHub = 全球最大代码托管平台，可理解成「代码的网盘＋协作记录本」）。由此把 Lovable 当「基础设施（infrastructure）」用——「在 Claude Code 上推代码、享受它所有灵活性，同时仍能在 Lovable 上看到产品演进」，不用处理托管、部署。Andre 自评这是「一种意外的、用『待办任务（jobs to be done）』思路去使用 Lovable 的方式，不是他们当初设计的本意，但效果特别好，是个很棒的桥梁（a great bridge）」。→ 详细 → 详细

Aakash 强调稀缺性：「我还没见过有人讲过这个，这是全新的独家内幕（this is new alpha）」，请 Andre 亲手演示怎么把 Lovable 和 Claude 桌面 app 连到同一个 GitHub 仓库。Andre 现场新建「mentor match simple」导师匹配工具，先在 Lovable 用一句 prompt 把产品「bootstrap（起步）」出来（定义：「你从一个 prompt 开始，不管它多大多简单多复杂，你就是在给产品起步」）。前置条件清单：① 你自己的 GitHub 仓库（挂个人名下）；② 一个 Claude Code 账号——「我觉得你可能需要一个 Pro 账号，不太确定免费账号能不能这么用，但就算你用的是最低档的套餐，那也足够你开始玩这套东西了」；③ 在 Claude Code 的 connectors（连接器） 里确保 GitHub 集成已连接。最容易踩的方向性约束：必须从 Lovable 起步——「如果你在 Claude Code 上写代码、发到 GitHub，你是没法把代码直接导回 Lovable 的，你必须从 Lovable 起步」。连上后新仓库会出现在 GitHub 列表和 Claude Code 仓库下拉里。→ 详细 → 详细 → 详细

第一个改动：让 Claude Code「把设计系统改成绿色」（原本米色加红色调）。机制是「我在往仓库里写代码，说 merge 时因为 Lovable 连着这个仓库，它就会更新」，PM 就能可视化 QA。只改配色「不用处理 branch，记住这是面向非技术人员，我们想把生活简化」。关键认知（谁才是「上线」那一步）：Claude Code 更新产品时「会去检查有没有 pull request，没有就创建一个，它做的全是那些通常你工程团队在做、你作为 PM 一般看不到的事」（PR = 「请把我这段改动并进主代码」的正式提交单）；但反直觉点是——「记住，是这个 publish 按钮才把东西推上线的，不是 Claude Code 把代码 merge 进仓库这一步」。第二个迭代极简到「连说明都不用给」：不满意 header 就「截了一张图」粘进 Claude Code，只说「弄点不一样的（do something different）」——「你甚至都不用说具体怎么弄」，回 Lovable「重新设计的 hero header 已经自动显示出来了，我什么都没干，且差别非常明显」。→ 详细 → 详细

非技术者「最有意思的玩法之一」：互动「不一定非得是『我要这个，去实现』」，而可以是一场对话——「就像你跟 Claude 聊天那样」。反常规用法：「你其实可以让 Claude Code 反过来问你问题（ask Claude Code to ask you questions），这样你就能把需求打磨得更好」。代价是「它在消耗 token」（AI 处理文字的计费单位），但值得。心态类比：「你可以把它看成是在和你的 lead engineer、或你 squad 里的工程师打交道，你做的是一样的事，也可以一样地对待它」。→ 详细 → 详细

Aakash 替观众扫盲（自承「过度简化」）：「有一个 main 分支。你写代码时通常会从 main 拉出你自己的一个分支（branch）。满意了就提一个 pull request，通常有人 review，然后 merge 回 main」（大白话：main 是正式版剧本，branch 是拿去单独改的副本，PR 是把副本交回请人审阅再并入正式版）。这次个人项目「有点跳过了 pull request 的 review 阶段」，因为「自己很快地 vibe coding 一下、直接 merge 到 main」（vibe coding = 凭感觉编程，靠自然语言让 AI 边聊边生成代码）。Andre 补「现阶段 vs 进公司」的差别：进公司要适应开发流程和 pipeline（工程团队从写代码到上线那整套固定流水线）；但现阶段「你真的不用怕，甚至不需要知道这些术语，直接跟它说『我不知道该怎么办，你把这个上线、或加到我的代码库里』，Claude Code 其实会懂」。→ 详细 → 详细

发布流程：点 publish → continue，它问「公开链接还是只给自己看」——「用免费版或最低档，这些选项可以一路『是、是、是』点过去」；「想做商业应用就在这上面好好弄，否则直接 continue，嘭，app 就上线了」，URL「大家都能访问」。preview link 的角色（「Lovable 当基础设施」的落地）：「你在 Claude Code 上改动并 push 后，它们会在 Lovable 更新，但你需要 publish 才能更新那个公开链接」——没 publish 前「Lovable 就像一个预览（preview）」，点开得到 preview link，而「这个预览链接是你在 Lovable 界面之外做 QA 的方式：看它在手机上、浏览器里怎么样，可以发给别人」。→ 详细

触发点是「我想开始做得更快，而通常要做得更快，你就得用上 branch」。学习曲线是自然的：「一旦你开始玩仓库、Claude Code 和 Lovable，只要有点好奇心就会多懂一点，而且你完全不需要像你最资深的工程师那么技术」——慢慢学到 branch、merge 到 main、一点 work tree（同一仓库里并行的多个工作副本）。现实需求：「你很快就会发现自己想同时开多个 session……同时做多个功能」，这需要基础设施来「安全顺畅地同时处理多个 branch、处理冲突」。于是从 Lovable 转到 Vercel——「Lovable 本来就不该是个 infra 产品，是我自己这么用的」，Vercel「作为『典型工作方式』要有名得多」。写代码可二选一：继续用 Claude Code 桌面端，或用 IDE。Andre 选后者：「我喜欢用 Cursor，但我是用 Cursor 配 Claude Code」（装 Claude Code 扩展、用的是 Claude Code 不是 Cursor 的 agent，只把 Cursor 当 IDE）。他把这纯个人偏好类比成工程圈经典口水战：「有点像『空格 vs 制表符（spaces versus tabs）』之争」，个人偏爱是因为喜欢「竖排的那种视图（vertical view）」。→ 详细

Andre 坦言初见 Vercel「看着是有点吓人」，逐项拆解：overview 里看到产品本体；deployments 里「是我在做的所有功能，过去这几个小时一直在做的功能，能看到时间，所以是忙碌的一天（busy day）」。deployments 里每一行「其实就是一个分支（branch），一个分支里可以有一个改动，也可以好几个改动打包进同一分支」，展示的是「某个还没上线的改动」，潜台词「你刚做好这个东西，现在可以测试了」。Vercel 会给一个**预览链接（preview link）**试效果，满意后「merge，推到生产环境，也就是推到 main 主分支上」。→ 详细 → 详细

Aakash 替观众发问（「Vercel 看起来跟 Lovable 有点像」），请 Andre 讲清。最简心智模型：「有一个写代码的地方，比如 Claude Code（Y）；一个代码存放的地方，GitHub；再有 Vercel（Z），它是连接你 GitHub 仓库和用户之间的桥梁」——流程是「把代码从 Claude Code 推到仓库，然后告诉 Vercel：把我刚写好的代码发布给用户」。重要澄清（为什么 Vercel 像 Lovable）：「我用 Lovable 的方式是最不典型的（most atypical way possible）」，因为 Lovable 本身是 AI IDE；而「Vercel 其实也有这功能，叫 V0」，他现在展示的是基础设施那一面、「故意做了过度简化（oversimplifying on purpose）」。Aakash 点破本质：Lovable 把托管、数据库内置进产品所以更简单，而「其实就连 Vercel 本身也是一堆抽象」。核心心法（全片最实用的自我定位）：「当你是非技术背景，最重要的一点是：你没有时间也没有能力去深入理解每一个技术细节，你只想务实一点，让东西能跑起来就行（just be pragmatic and just make stuff work）」；Andre 把它拔高成一项核心能力：「这正是你现在作为一个想动手做东西的非技术 PM，能培养的最好的技能」。→ 详细 → 详细

Aakash 在「竖排视图」偏好外补了「至少两个」更硬的理由。理由一：「Cursor 有一个非常非常慷慨的免费套餐（a very, very generous free plan），可以用它的 agent 来调试你在 Claude Code 上遇到的问题」——具体卡壳场景：「比如 Claude Code 起不来、你登录不进去，卡在第零步（stuck at step zero）动弹不得」，这时打开一个 Cursor agent，把问题粘进去（「嘿，我打不开 Claude Code」），免费 agent 就会帮你调试。理由二：「Cursor 跟 GitHub 同步做得特别好。你一旦登录了 GitHub，之后在 Cursor 里用 Claude Code 打开的所有项目，都会自动跟你的 GitHub 关联起来」。→ 详细 → 详细

Andre 的对应关系：「对我来说，一个 session 就是一个 epic（史诗任务）」——「一个 epic 里面有好几个功能」（epic = 一大块需拆成多个功能/故事来做的大任务）。完整工作流：开新 session 说「搞定某个 epic」→ Claude Code 写代码、你与它互动 → 准备好说「部署吧/合并吧/开个 PR」，它「就会在 Vercel 上显示成一个分支、一条新的线」→ QA 满意后「回到同一个 session，说：都跑通了、该看的我都看了，咱们合并到 main」。Cursor 的可视化对非技术者友好：「这条黄线是一个分支，在紫线之外，紫线就是你的 main，是大家正在用的那个分支。最终我把它合并，黄线上的功能在紫线上也能用了」——「你不需要懂 git、不需要懂分支怎么运作，因为可视化已经把发生的事解释清楚了」。他补一句心理学：非技术人员搞技术活时会想找「让你自在的区域（comfort areas），这能让你少点恐惧，更专注在做事上」。→ 详细 → 详细

• Level 4 = 「拥有 agent 和 skill，并创建你自己的流程」。产出是「能真正并行跑多个 session、同时做多个项目，能真正并行交付非常大的 epic，又不会给产品制造问题，甚至还能在 Vercel 上用不同方案做实验」。→ 详细
• 直面最普遍的恐惧：「很多人最大的恐惧就是：vibe coding 写出来的是烂代码；或者用 agent 构建时它们会搞出一大堆复杂度、一大堆代码行」。Andre 说「这么想其实没错」，尤其非技术者「你不知道自己在要求什么（you don't know what you're asking）」，结果「用一些很简单的 prompt，很容易就生成出一大堆 slop（垃圾内容）、一大堆废料（trash）」——而「这正是一套好的 agent 基础设施能帮到你的地方」。→ 详细
• Andre 自建了「我自己的 agent 仓库、skill 仓库，甚至还有我的 Claude MD」，把这套叫「制造机器的机器（the machine that builds the machine）」，存在的全部意义就是「把你的时间解放出来」——让你专注本该专注的几个问题（连珠炮列出）：「我是不是在解决正确的问题？是不是足够理解这个问题？是不是拿到了所有需求？是不是跟所有相关的人都聊过了？」。他给出那条产品圈公认却常被违背的原则：「如果你把时间花在方案设计（solution design）上，你就不会有足够的时间花在问题探索（problem discovery）上。我们都知道，最好的那批产品经理，会花更多时间在问题探索上」。→ 详细

• CLAUDE.md 是什么：Andre「喜欢把它叫做记忆，或者说文化——我那个 Claude 的价值观，或者说我跟它之间的互动方式」。机制上它「存在于你的 Claude Code 里」，且「每次你问 Claude 什么，在后台——你看不见——但它们会读这份文件」，于是「所有规则、你决定放进去的一切，都会拿来定义自己的工作方式」。比方很到位：「就好比你在一个团队里，告诉他们『看，我们是这么干活的，这些是我们在意的东西』，你知道你的团队做决策、干活时会把这些放在心上。Claude MD 的运作方式一模一样」。→ 详细
• Andre 的 CLAUDE.md 包含四块：默认行为（default behavior）、规则（rules）、agent 策略（agent strategy）、架构（architecture）——architecture 指「根据我所要求的功能不同，会触发一些特定的事情」。他的评价很务实：「我的这份比我见过很多人的 Claude MD 简单得多，但它管用」，并说愿意「把这份东西放到节目笔记里」。→ 详细
• 自我改进机制（把它从静态配置变成会进化的资产的关键）：「当你在工作时发现自己在重复做某些事，或者发现 Claude 在做一些你不喜欢的事，你其实可以改进你的 Claude MD。你可以对 Claude 说：看，我不喜欢这样，或者我老是在重复这个，你能不能把这条加进 Claude MD？这样下次它就已经知道该怎么做了，你就不用一直碰到那个错误」。→ 详细

• Andre 用得最多的特定 agent——「我把它叫做 PM agent……我在 Claude 里有一个我的私人产品经理（a personal product manager inside Claude），而且它专门是一个编排者（orchestrator）」。铁律是只调度、不亲手干活：「这个 PM——它是个 PM.md——不会自己去做事。它只负责接收信息，然后决定该调用哪些其他 agent，因为那些 agent 会更擅长做某件事」。核心指令（原话）：「永远不要自己动手做，因为总会有某个 agent 比你更擅长（never do the work yourself because there's going to be some agent better than you）。你只管编排」——他点破这恰恰映照 PM 本质：「说实话这其实有点像 PM 的本职工作」。→ 详细
• 加载与触发机制（Aakash 追问「这个 agent 会主动出击吗」引出）：「每次你启动一个新 session，你的 Claude.md 就会被加载，还有那个 claude 文件夹里的一切，包括你的 agent 和 skill」。但关键是——「它不会去用 skill，除非你调用它们；不会去用 agent，除非你明确调用它们」。那 PM agent 凭什么每次被叫起来？因为「在我的 Claude MD 里，有一条非常重要的规则——第一条规则：对每一个任务，都调用 PM agent（Rule number one: for every task call the PM agent）」。所以 Andre 明确纠正：「它不是主动出击的（not proactive），而是因为我们把 Claude MD 架构成了这种方式，而 Claude MD 始终是被加载的」。→ 详细
• 类比（拎清你的新角色）：「这就好比，假设你是 CEO，第一件事就是去找 PM，对他说：我是 CEO，我们发现了一个新机会，请着手处理。你做的差不多就是这样，只不过这种情况下，你手底下不是一个团队，而是一群 agent」。→ 详细

• PM agent 之下的具体 agent（对应真实产品团队工种）：researcher（研究员）——「做团队里用户研究通常做的事」；discovery（探索）——「一个很特定的 agent」，Andre 说它「很有意思（a very interesting one）」；designer（设计师）——「对设计系统、对 UX 最佳实践非常在行」；engineer（工程师）——「作用是防止我的代码变成烂代码，或者尽量别变成烂代码」；implement（实施者）——「最后那个真正去写代码、把东西落地的人」。→ 详细
• 最佳建议——别重复造轮子（don't try to reinvent the wheel）：「试着去看看你实际上是怎么跟你的团队协作的，然后把他们表示成 agent——他们怎么干活、在意什么、怎么做决策，把这些写下来，让它们成为你的 agent。这是最好的建议之一」。→ 详细
• 最糟做法（反面教材）：「你能做的最糟糕的事情之一，就是跑到 X 上、跑到 LinkedIn 上，看那些非常有名的人分享的所有 skill，然后就一股脑加载几百个你压根不知道它们存在的 skill，而你并没有在用第一性原理（first principles）思考」。正确做法是「向他们学习——那里有很棒的内容，但要深入研究哪些 skill 对你有意义、哪些契合你的流程，然后只采用那些，或者最理想的是基于你自己的探索去写你自己的」。→ 详细

• 现场在 Cursor + Claude Code 上演示真实流程：「每当我要一个功能，它会在后台运行我的 Claude MD，而它已经知道需要调用 PM 了。我不需要去调用 PM，只需要说我想让它做什么」。这正是 PM 该有的省心状态：「因为我搭建了这套基础设施，它们会去解决那些我不需要操心的问题。我只需要操心功能本身、我要解决的问题、我提出的需求——就是你作为 PM 通常做的那些典型的事，这太棒了，因为你等于已经搭好了你的团队」。第一回合里 engineer agent「在代码库里发现了一些东西，给了我一些建议，好让我心里有数」，而「我不需要理解这里的一切」（虽然愿意花点时间是能理解的）。→ 详细
• 多 agent 协作的具体案例（「agent 反问 PM」最生动的一处）：Andre「要了一个特定的功能，但我对设计不太确定」，于是「PM 决定：好，Andre 对设计不确定，那我去调用设计师 agent」。设计师 agent「做了一份简报（brief）」——里面「有对设计师各项决策的总结，谈到具体布局，谈到代码（它对代码也有理解），谈到视觉体验，给出建议，它甚至还反过来问我问题」，而「这些是在工程师 agent 写代码、写架构之前提出的问题」。→ 详细
• 「被反问」的价值（即使不懂技术也答得上）：「哪怕你不是技术背景——你就是这种情况——你回答问题的方式，就跟你自己是团队里的工程师、或你自己是设计师，在团队会议上被问到同样的问题时一模一样」。提供这些信息就「能避免你的代码变得更糟，避免功能被做错，避免给产品加上它其实根本不需要的功能」。一句话收束 Level 4：「你开始打造一台机器，再由它来替你造产品，你就能把更多精力放在问题框定（problem framing）上——搞清楚要做什么、什么才合理、优先级是什么——因为你有了一个团队」。→ 详细

• Andre 的「最后建议」，先描述那个几乎人人都有的错误本能：做完功能、切到分支后「不喜欢做出来的东西、不喜欢这个流程、或不喜欢它做的那些决策」，本能反应是「直接跟 Claude 说把这个功能改一改让它变好，然后我就能推上去、上线」。他斩钉截铁：「但这其实不是正确的心态」。→ 详细
• 正确心态（去找病根、改机器）：「正确的心态是：在这条 pipeline 里，是你的 agent 和 skill 哪个环节出了问题，导致了这个糟糕的结果。你把它找出来，然后去改那个 agent、改那个 skill，或者改你的 Claude MD」。为什么——「因为下一次你再做功能时，你不希望同样的问题再发生。所以你就是在改进这台机器，好让将来你能更轻松地再次只专注于问题」。具体动作：「如果我不喜欢刚做出来的某个功能，我就去改这台机器，然后让它重新做一遍，再跑一次 pipeline，看看最终结果是不是更接近、或者正好就是我真正想要的」。→ 详细
• 金句（原话）：「这就是 AI native 团队在做的事——他们有 50% 的时间花在改进基础设施、改进机器本身，而不是一个功能一个功能地修修补补（working 50% of the time on improving the infrastructure, the machine itself, rather than just tweaking feature by feature）」。→ 详细

• 经典铁三角（产品经理 + 工程师 + 设计师）依旧在，但角色变了：「你照样可以有那种经典的铁三角，但他们全都是 builder，意思是他们都在交付代码、都在做功能」；区别在「他们各自有一部分时间用来拿自己的专业知识去改进 agent 或 skill」——「工程师改工程师的 agent 和 skill，设计师改设计师的，甚至连 PM 也在改进 PM 的编排 skill 和 agent」，于是「随着时间推移，它会带着每个人各自的做事方式一起变得越来越好」。→ 详细
• 结果（一句话总账）：「所以现在你有三个 builder，有一套基础设施在背后撑着他们，你就得到了产出能力的三倍加速（a triple acceleration of what you can build）。这就是为什么你会看到 AI native 公司里的小团队，能用这么少的人交付得这么快」。→ 详细
• 连接层 = 团队共享的 Claude 配置仓库（Aakash 总结、Andre 百分百确认）：「我建了这么一个仓库，把我的 skill 都放进去，每次做了改动就推上去，然后我的团队会在 Slack 上收到一条通知，说『嘿，团队的 skill 仓库有更新了，请重新 clone、或者更新你自己的，这样你用的都是最好的那些』」，「至少你建立了一套标准」。规模化提示：「公司更大你甚至可能会有一整个 AI ops 团队、或 R&D 团队，专门替其他所有人搭这些」；但小团队最该投入——「如果你是个小团队——而恰恰是这些团队最需要提速——那你绝对应该在这件事上投入、花时间」。→ 详细

这是 Andre「特别喜欢」但声明非原创的一个 LinkedIn 观点——「原话不是我先写的，我只是喜欢去评论它，但这事完全成立，每次你看一家新的初创公司就能验证」。他用自己在 VC 做早期投资的经历背书：那些早期团队都超小、非常务实，通常就三个创始人——「一个明显偏商业，一个明显偏技术，还有一个通常明显偏产品」。四种角色就是「这些创始人在公司刚起步时的样子」：商业（commercial）——「负责拉单，保证销售、市场、把声音传出去（getting the word out）」；产品（product）——「保证东西真的被做出来，而现在他们有能力亲手把它做出来了」，且给早期产品人开「放开糊」的绿灯：「是的，他们会到处 vibe coding、到处糊（slop）一堆东西，因为在早期找产品市场契合（PMF）时，你做太多东西又有什么关系呢？你就是在拼命对着目标多打几枪（getting shots at the target）」；技术（technical）——「保证做出来的东西有合适的可扩展性（scalability）、足够可靠，撑得住团队扩张」；外加第四种 infra/安全。由此「很容易看到一个全栈 squad（full stack squad），里面有一个 owner，对一个 P&L 负责、对影响力负责、对结果负责，并拥有这一整套能力栈」（P&L = 损益表，指对一块业务的盈亏成败真正负责）。→ 详细

Andre 把 infra/安全单独高亮，因为它是整套设想成立的「闸门」：「你一旦搭出一套很棒的基础设施，让一个非技术背景的人也能用 AI 真的往生产仓库里写代码，那这个人是不是技术背景就不再重要了，因为真正重要的是那个 infra 或者安全的人在很出色地保护这个仓库」。关键是重新定义「保护」：「这里说的『保护』不是拦着不让代码进来，而是新进来的代码必须经过一连串检查，确保它进生产环境时是安全的」。他给了个让人安心的类比——这事早就存在：「这跟一个资深工程师面对刚出校门的初级工程师加入软件开发团队时做的事，本质上一模一样。这不是什么新东西。区别只在于，现在这个『初级工程师』是一个用 AI 来 vibe code、做新功能的非技术人员」。他对外界反应有点不以为然：「我看到很多人对这事大惊小怪（making a fuss out of this），但这其实是个早就存在的现实，而且很多团队都会朝这个方向转型，因为交付的速度差得简直离谱（the velocity to ship is crazy different）」。→ 详细

• 由 Aakash 的尖锐提问引出：「你怎么避免交付出 slop？怎么避免——就像出了名的，Claude 团队东西是发出来了，但他们的可用性（uptime）很差——这类问题？」（uptime = 服务正常在线、不宕机的时长。）→ 详细
• 尾端摩擦（上线检查）：「你在推理安全（inference security）上投入得越多，就越有可能防止那种情况，因为你制造了摩擦」。Andre 强调这是「好摩擦」——「这里的摩擦不是阻止人去做东西，而是『这东西通过所有检查了吗』，这样它上线时才不会带来更多风险、更多问题」。→ 详细
• 头端摩擦（问题侧），这是「投入做基础设施的产品人应该花时间的地方」。Andre 有三个 skill，每开一个 epic 就跑一遍：(1) jobs-to-be-done（待办任务框架）；(2) opportunity solution tree（机会-解决方案树）——明确归因「基于 Teresa Torres 那本很棒的书」；(3) MoSCoW——「用的是 must / should / could / won't 这套优先级排序方法」（把需求分成「必须做/应该做/可以做/这次不做」四档）。这三个 skill 的具体动作：「在那条需求、那份 PRD 上创建三个 Notion 页面，分别用这三套框架去展开」，目的是逼大家停下来想清楚：「我想让大家去读、去看：这说得通吗？我们有没有投入足够的时间？能不能确认一下、然后进到方案构建的下一阶段？」——「在那份文档被彻底想清楚之前，我不希望大家就开始做方案」。且这不是 PM 的专利：「不只是 PM、或非技术 PM 在做，工程师也这么做，设计师也这么做，因为我们全都是 builder」。一句话收尾：「这就是在头和尾两端防止 slop 的两种方式」。→ 详细

• 反常识判断：「最拖累个人、团队、公司的东西之一，其实是协作（collaboration）。这听起来反直觉，但事实就是：大家不得不一起协作这件事，恰恰是让一切都慢下来的原因」——但关键限定是协作放错了位置。→ 详细
• 开发三阶段与「协作该在哪」：他把开发分成「构思/发现（ideation/discovery）是第一阶段，执行（execution）是第二阶段，交付/赋能（delivery/enablement）是第三阶段」。理想是「协作应该发生在头和尾」——「开头把人聚到一起一起决策、琢磨问题；结尾又让大家把产品拿在手里，一起推它上市、商业化」。但现实是「协作全堆在执行阶段：堆在各种依赖关系上，堆在『我做这个、你做那个』上，结果把一切都拖慢了」，反而「在开头和结尾没有协作——只有 PM 在做决策，只有工程师在交付。整个就完全反过来了（completely flipped）」。→ 详细
• 掰正后的样子：「这时候大家在决策上大量协作，然后每个人、甚至『一人团队（teams of one）』都能自己独立完成执行，最后大家再聚回来，在结尾协作：这说得通吗？我们能合并吗？跟产品契合吗？然后一起把产品交付给用户」。Andre 认为「一旦这么做，我们就能大大减少 slop，并大大给团队提速」。→ 详细

触发于 Aakash 提到的一篇 LinkedIn 帖（「你写过……欧洲 90% 的 PM 都是非技术背景」）。Andre 对数字留了余地：「我不能 100% 确定那个数字到底是 90%、99%、还是介于两者之间，但它肯定是个相当相当高的数字」。他指出欧洲产品文化的独特之处：「你去很多欧洲公司，会看到一大堆 PO、也就是 product owner，这在美国、甚至亚洲市场都很少见」。金句：欧洲的 product owner 文化「很大程度上聚焦在一个被美化了的『交付经理』角色上，并不具备真正的技术能力（a glorified delivery manager without the actual technical skills）」，「某种意义上你就是在做文件搬运工（paper shuffling）——夹在定义战略/路线图/倾听客户的那个人，和工程、设计团队之间，卡在中间努力做翻译，可能还顺带干点项目管理，但你的手脚被这套产品文化捆得有点死」。由此点出最大浪费：「这是欧洲很多科技/软件开发领域最大的问题之一：那些有才华、聪明、本应能真正驱动大量决策的人，却没能力去驱动那些决策」。→ 详细

• 当 Aakash 问「体系是坏的，该不该跳去跨国公司」，Andre 不主张逃离：「我不觉得你该走人，因为这就是你的现实。如果你有那个能量（energy），你应该去争取，把它变成一个更好的现实」。病根指向管理层：「很多东西根植在管理层里——可能那些管理者、产品负责人自己也没见过别的做法，所以就把这套格式一层层往下传（trickling down that format）」。开眼界的办法：「去一家美国公司待一待、看看他们怎么做东西，你就会发现差别非常大」。→ 详细
• 具体动作是「去建一个小小的实验飞地（that small pocket of experimentation），用不一样的方式做事」——双赢：「这不光对你自己有好处——能让你真正拓宽产品管理的职责范围、把 product owner 那一套甩在身后——它对团队也有好处」。→ 详细
• 「product owner」头衔本身的危害（反复观察到的现象）：「当你有一个 product owner 时，团队不管无意识还是有意识接收到的信号，就是『这个人独自拥有这个产品』。可这不对，因为整个团队、至少整个 squad 都应该是产品的 owner，但他们不是，因为头衔上写着那个人才是——这是个谎言（which is a lie）」。它还反噬持有者自己：「你自己也会觉得自己是产品的 owner，这让你成了一个其实你并不是的领导者/管理者。又是这样，是头衔在把这一切搅坏（the title is breaking all of this）」。后果讲到具体：很多欧洲组织里 squad/pod「彻底被剥夺了权力（completely disempowered）……工程团队不参与决策、不是构思的一部分、不是发现过程的一部分；也常看不到设计团队参与最终交付。团队全都被孤立成一个个筒仓（siloed）」，根源恰恰是「存在一个 product owner，而不是整个团队都感觉自己是产品的 owner」。→ 详细

• 第一步——先见过「好菜」：引用前经理的话「要想做出好菜，你得先吃过好菜（to cook great food you have to have had great food）」——「你得明白外面是有好菜的，是存在别的、更好的做产品的方式的」；做法是读内容、看别人怎么思考/做东西/跟团队互动/搭自己那套。一句话点题：「先从搞清楚『好菜』是什么样子开始，这样你才能开始在内部把它做出来」。→ 详细
• 第二步——找指导 + 看清差距：「去找些指导、找些 mentorship，找那些可能就在用这种方式做事的公司里的人，问他们：这怎么运作？我该做什么？你怎么做到的？」；同时「跟你的经理建立那种汇报关系、跟产品文化建立联系，然后看清楚：你在哪儿看到了差距，可以从那儿入手去改变工作方式」。→ 详细
• 第三步——在团队里争取盟友：「你要开始在团队里争取盟友，也就是你的工程团队、设计团队、AI 团队」，明确告诉他们（原话）：「听着，我们不想让你们待在流程的末端，我们希望你们参与到开发过程的每一个节点——从决策、到构思、到发现、到最后的交付、到上市和赋能——我们想让团队成为整个过程的 owner」。→ 详细

不必一夜剧变：「哪怕你已经有了一份路线图、一条赛道、经理对你有期待，也可以从路线图里找一些事情，换一种方式在团队内部管理。你不需要一夜之间彻底改变工作方式，可以从小处入手、当成一个实验」。关键是改造「仪式（rituals）」：「如果到现在你做需求探索或拍板决策时，团队里有相当一部分人都不在场——那就先把他们拉进来（get them in the room）。否则他们永远不会参与进来」。说到根上：「如果范围、需求、设计这些决策全是你一个人在做，那本身就已经是个问题了，别人也应该参与、甚至对这个过程有所有权（ownership）」。→ 详细

• 前提：「这个目标挺有野心的，很大程度上取决于你的团队」，假设你已走到大概 Level 3、感觉自在。第一件事：「去找你的工程师——假设你有一个 GitHub 账号——跟他说：把我加成一个低风险仓库的协作者（collaborator of a low-risk repository）。哪怕专门给我建一个仓库都行，只要它跟产品相关，一个新仓库、一个新功能，让我能动手做点什么」。→ 详细
• 第二件事（挑一个「永远不会被做」的功能）：「去看你们的 backlog，挑一个躺了很久的功能，按最早创建排序（sort it by oldest），挑一个你心里清楚、压在 backlog 最底下、永远不会被做的东西。每个 PM 手里都有一大堆这种东西」，然后「不给任何需求文档（without requirements），直接让 Claude Code 把它做出来，甚至可以推一个分支」。→ 详细
• 目的不是上线、而是「亲眼看魔法」：「你不会把它合并到生产环境——工程师们也不会让你这么干。但你就去亲眼看看那种神奇的事情发生（see the magic happening），看看你作为一个 PM 现在拥有了多大的能力」。愿景拉到团队尺度：「想象一个现实：产品小队里的每一个人都能为真实的 backlog 做这件事」——并以身作则收尾：「这就是我的周一早上——我听到这些之后，会立刻开始做的事」。→ 详细

本期没有独立「闪电问答（lightning round）」环节，结尾为常规收束：

• Aakash 预告：Andre 还做企业内训（corporate training）——「想让你老板把 Andre 请进公司，可以考虑找他做这个」。→ 详细
• 主持人结尾呼吁：①评论；②留评分/评价（「这些能真正帮助别人理解我们投入到节目里的价值和制作水准」）；③分享本期；④确认订阅。理由很真诚：「这一期可不好做，我们做了大量前期准备、为你们精心剪辑、请来了最好的嘉宾」。→ 详细
• 贯穿全片的金句备查（原话）：
  • 「If your job is still managing backlogs, writing issues, creating decks... honestly, you're being left behind.」→ 详细
  • 「the machine that builds the machine（制造机器的机器）」→ 详细
  • 「never do the work yourself because there's going to be some agent better than you」→ 详细
  • 「AI native teams... working 50% of the time on improving the infrastructure, the machine itself, rather than just tweaking feature by feature.」→ 详细
  • 「the product owner culture in Europe... focuses a lot on a bit of a glorified delivery manager without the actual technical skills.」→ 详细
  • 「to cook great food you have to have had great food（要做出好菜，你得先吃过好菜）」（Andre 引用前经理）→ 详细

提及的工具/资源清单：Claude Code（桌面 app）、Lovable、Vercel（及其构建产品 V0）、Cursor（内嵌 Claude Code 扩展，免费 agent 可用来 debug）、GitHub、CLAUDE.md（默认行为/规则/agent 策略/架构四块）、PM.md（PM agent 编排器）、Notion（三个 skill 各输出一个框架页面）、Slack（团队 skill 仓库更新通知）。方法论：jobs-to-be-done、opportunity solution tree（Teresa Torres）、MoSCoW（must/should/could/won't）。 （主持人赞助商口播：Customer.io、Amplitude、Bolt.new、Ario、AIPM 证书课 / Bundle.acg.com — 与正文方法论无关，仅作记录。）

• Andre Albuquerque：主要用 LinkedIn（「欢迎加我」）；想了解更多去 builderscamp.com——「那是我们办训练营的地方，我们在那里培训大家成为 builder」，并提供企业内训。→ 详细

• Lovable / V0：AI IDE，用自然语言在网页里直接把产品「建」出来，内置托管、数据库、身份认证。Andre 却「最不典型地」把 Lovable 当基础设施（QA/预览层）用。

• Claude Code：写代码的地方（可跑在 Claude 桌面 app，也可作扩展跑在 Cursor 里），连 GitHub 后能真往仓库推代码。

• Vercel：连接 GitHub 仓库和用户之间的桥梁/托管层，deployments 里每一行≈一个 branch/待测改动，给 preview link，merge 即上线。

• Cursor：IDE，慷慨免费套餐的 agent 可用来 debug「Claude Code 起不来」这类卡壳；跟 GitHub 同步好；可视化 branch（黄线/紫线）对非技术者友好。

• GitHub：代码托管平台（「代码的网盘＋协作记录本」），三工具靠同一仓库同步。

• CLAUDE.md：Claude Code 的「记忆/文化/价值观」，每次提问后台都读；含默认行为/规则/agent 策略/架构四块；可自我进化。

• PM.md / PM agent：纯编排者，「永不自己动手」，只路由到 researcher/discovery/designer/engineer/implementer；靠 CLAUDE.md「第一条规则：每个任务都调 PM agent」被触发。

• bootstrap：从一个 prompt 给产品起步。epic：一大块含多个功能的大任务，Andre 一个 session ≈ 一个 epic。

• slop / trash：AI 凭感觉生成的垃圾产出/废料。vibe coding：凭感觉、靠自然语言让 AI 边聊边生成代码。

• friction（好摩擦）：不是拦人做事，而是「通过所有检查了吗」的关卡；头端逼想透问题、尾端逼过安全检查。

• 头端三 skill：jobs-to-be-done、opportunity solution tree（Teresa Torres）、MoSCoW（must/should/could/won't）。

• work tree / branch / merge / PR / pipeline / P&L / PMF / uptime / authentication：分别为并行工作副本 / 分支 / 并回主干 / 合并请求单 / 上线流水线 / 损益表 / 产品市场契合 / 在线不宕机时长 / 身份认证。

本节提炼自 Aakash 团队的配套书面报道《The Claude Code Setup for Non-Technical PMs》，它把节目里散落的论点重新命名、结构化。下面这些「命名概念」是报道的编辑提炼，并非 Andre 在视频里逐字说出的原话——单列于此方便记忆与引用，请勿当成嘉宾原话转述。

• 三大拦路虎（Three Blockers）——① 官僚约束：被流程/工单困死，没机会动手建；② 虚假的所有权（false ownership）→ 延迟税：单一 PO 头衔制造「一个人独占产品」的假象，在决策与交付间堆出时间成本；③ 错误的起点：学习路径一上来就跳进太重的工具/层级劝退非技术者。（对应正文第 2、27-28、4 节。）
• 延迟税（Latency Tax）——从「客户问题出现」到「功能上线」之间的延迟成本：传统流水线要数周，PM 能自己建原型时压到数小时。
• 四级建造栈（Four-Level Building Stack）——Level 1 纯 Lovable → Level 2 Lovable + Claude Code + GitHub → Level 3 Claude Code + Vercel + Cursor → Level 4 多 agent 基础设施（详见正文第 3-16 节）。
• 建造者的直觉（Builder's Gut）与技术同理心（Technical Empathy）——只有亲手建过，PM 才长得出「什么可行、什么会很贵、工程师在顾虑什么」的直觉与同理心，从而与工程/设计同频。
• 50/50 基础设施—功能投入比——AI native 团队把约一半时间投在「改进机器（agent / skill / CLAUDE.md）」而非逐个修功能（正文第 21-22 节）。

出处：完整书面报道 https://www.news.aakashg.com/p/claude-code-non-technical-pms ｜ 人工校订文字稿（含分章时间戳）https://www.aakashg.com/albuquerque-podcast/