The Claude Code Setup for Non-Technical PMs That Nobody Shows You

频道: Aakash Gupta
视频: https://www.youtube.com/watch?v=bYiXxeinhbg
原文语言: en
统计: 共 67 轮 · Aakash 21 · Andre 46

[0:00] Aakash

If you look at a lot of companies that have nontechnical PMs in teams, they're bureaucrats. They're stuck in Jira, Lineard, PowerPoints, they're dependent on their technical teams. Andre Albuquerque, he runs Europe's largest product builder school with over 4,000 students. And in today's [music] episode, he is giving you everything for free. The product owner culture in Europe. It focuses a lot on a bit of a glorified delivery manager without the actual technical skills. What's the flip side to this philosophy though? And you even have the word slop here. How do you avoid shipping slop? The biggest fear a lot of people have is like, oh, five coded, bad code.

你去看很多团队里有非技术 PM 的公司，会发现这些 PM 就是官僚。他们被困在 Jira、Linear、PowerPoint 里，完全依赖技术团队。Andre Albuquerque 运营着欧洲最大的产品 builder 学校，有超过 4000 名学生。而在今天这期节目里，他要把这些东西全都免费分享出来。欧洲的 product owner 文化，很大程度上推崇的是一种被美化了的交付经理角色，但实际上并不具备真正的技术能力。不过这套理念的另一面是什么呢？你这里甚至还用到了 slop（垃圾产出）这个词。你是怎么避免做出 slop 的？很多人最大的恐惧就是——天哪，AI 写出来的代码很烂、是坏代码。

[0:35] Aakash

Transformation is a big goal. Can you go ahead and show people how they get started with this new way of working? It has four [music] steps. The first one lovable. The second step a mix of lovable and blog post code. The third step is plot code and versell. And the fourth step is multi-cloud code, multiversell, and a lot of automation and agents. One of the things you wrote about on LinkedIn is that there are now only four jobs. Can you explain this? Before we get into today's episode, I wanted to share that you can get a free year of my favorite AI tools including bolt at new, mobin, arise, relay app, dovetail, linear, magic patterns, reforge build, descript, and speechifi if you join my bundle at bundle.acg.com. On top of that, I wanted to quickly ask you to please double check that you are subscribed on YouTube, Apple, and Spotify podcast. It's a free thing you can do that really helps support the show. And now into today's episode. If you're like me, you're getting overwhelmed by all of the AI tools, all the AI noise out there, and 90% of the guides assume that you are technical and you're an expert in cloud code. Today's episode is nothing like that. We are going to show you very step by step how you can start with lovable and AI prototyping. How you can layer in cloud code to your lovable workflow. Then how you can move to full cloud code and finally how you can use cloud code with tools like versel and cursor to actually ship updates to your codebase. There is not an episode like this on YouTube and I think I brought in the best person to do it. Andre Albuquerque really excels in giving you simple understandings building up your knowledge from zero. So if you're a nontechnical PM and you watch till the end, I guarantee you you will feel more confident using cloud

转型是一个很大的目标。你能不能现身说法，给大家演示一下怎么上手这种全新的工作方式？它一共有四步。第一步是 Lovable。第二步是 Lovable 加 Claude Code 的混合。第三步是 Claude Code 加 Vercel。第四步则是多个 Claude Code、多个 Vercel，再加上大量的自动化和 agent（智能体）。你在 LinkedIn 上写过一个观点，说现在只剩下四种工作了。你能解释一下吗？在我们正式进入今天这期节目之前，我想先告诉大家：你可以免费获得我最爱的一批 AI 工具一整年的使用权，包括 Bolt.new、Mobbin、Arize、Relay app、Dovetail、Linear、Magic Patterns、Reforge Build、Descript 和 Speechify——只要你加入我在 bundle.acg.com 上的工具包就行。另外，我想顺便拜托你一下，麻烦再确认一下你已经在 YouTube、Apple 和 Spotify 播客上订阅了我们。这是一件免费就能做、却能实实在在支持这档节目的事。好，现在进入今天的正题。如果你和我一样，正被各种 AI 工具、各种 AI 噪音淹没，而且 90% 的教程都默认你是技术出身、是 Claude Code 的专家——那今天这期完全不一样。我们会一步一步教你，怎么从 Lovable 和 AI 原型搭建开始，怎么把 Claude Code 叠加到你的 Lovable 工作流里，然后怎么过渡到完全用 Claude Code，最后怎么用 Claude Code 配合 Vercel、Cursor 这类工具，真正把更新推送到你的代码库里。YouTube 上没有第二期这样的节目，而且我觉得我请来了做这件事的最佳人选。Andre Albuquerque 特别擅长用最简单的方式讲清楚，帮你从零开始一点点建立起认知。所以如果你是个非技术 PM，又一直看到最后，我保证你会更有信心去用 Claude

[2:25] Aakash

code and we will even give you the Monday morning roadmap to go talk to your engineer. So let's get into it. Andre, welcome to the podcast.

Code，我们甚至还会给你一份「周一早上的行动路线图」，让你拿去跟你的工程师谈。那我们就开始吧。Andre，欢迎来到播客。

[2:32] Andre

Hi Akash, thank you very much for having me.

嗨 Aakash，非常感谢你邀请我。

[2:33] Aakash

So I want to address the non-technical PMs from the get-go and give them something they can use. What is the biggest problem nontechnical PMs face in their roles?

我想一上来就直接面向非技术 PM，给他们一些能立刻用上的东西。非技术 PM 在工作中面对的最大问题是什么？

[2:43] Andre

If you look at a lot of companies that have nontechnical PMs in teams, they're bureaucrats. They're stuck in Jira. They're stuck in linear. They're stuck in powerpoints. They're not actually building. They're not pushing code. They're not adding features. They're dependent on their technical teams to do that. And it's not like they don't want to. It's a combination of their not knowing how. They maybe the management culture doesn't allow them. Maybe they don't have the the skills and the tools to be able to do it. But they're basically there waiting and dependent on everyone. And when we look to a lot of AI native organizations or even new companies moving super fast, you see that that is not a reality. You see product managers technical or not actually contributing building stuff. You see CEOs contributing to to repositories in GitHub. You look at the Shopify CEO and his GitHub is fully green. you see uh entire teams that are maybe it used to be like 10 20 people and now there are super small teams and they're all actually pushing new features new codes to production and I think this is the the reality that if you're a nontechnical PM and your job is still managing backlogs your job is still writing issues your job is still creating [snorts] decks or powerpoints to present to someone and you're not really building stuff honestly you're being left behind and I I think you want to completely transform the way you see your role inside the team which then will influence everyone else in the team to rethink their own roles and transform the squads entirely.

你去看很多团队里有非技术 PM 的公司，会发现这些 PM 就是官僚。他们被困在 Jira 里，被困在 Linear 里，被困在 PowerPoint 里。他们其实并没有在「建东西」。他们不写代码，不加功能。要做这些，他们得依赖自己的技术团队。倒不是说他们不想做，而是几个原因叠加在一起：一是他们不知道怎么做；二也许是管理文化不允许；也许是他们没有相应的技能和工具去做。但总之他们基本上就是在那儿干等着，依赖所有人。可当我们去看很多 AI 原生的组织，甚至是那些跑得飞快的新公司，你会发现完全不是这样。你会看到产品经理——不管懂不懂技术——真的在动手建东西。你会看到 CEO 给 GitHub 上的代码仓库做贡献。你看看 Shopify 的 CEO，他的 GitHub 提交记录是全绿的。你会看到一些团队，以前可能是 10 个、20 个人，现在变成了超精简的小团队，而且每个人都在真正地往生产环境推新功能、新代码。我觉得现实就是这样：如果你是个非技术 PM，而你的工作还停留在管 backlog、还停留在写 issue、还停留在做 PPT 去给某个人汇报，而你根本没在真正建东西——说实话，你正在被甩在后面。我觉得你需要彻底改变你看待自己角色的方式，而这又会反过来影响团队里的每个人，让他们也重新思考自己的角色，从而把整个 squad（小队）都彻底重塑。

[4:19] Aakash

So transformation is a big goal. I don't know if we'll be able to deliver everything on transformation but can you go ahead and share your screen show people how they get started with this new way of working.

所以转型是个大目标。我不确定我们能不能把转型这件事全讲透，但你能不能现在就分享一下屏幕，给大家演示一下怎么上手这种全新的工作方式？

[4:30] Andre

Yeah. So what I'm going to show you just uh to give you context is how I actually went from I'm not a developer. I I don't know how to code and I started building. Now, this has multiple steps, right? And this is the format that worked for me. Uh it doesn't mean it's going to work for everyone, but it gave me a bit of comfort and I'll explain why. So, uh it has basically four steps, right? Uh the first one, and I'm going to address different tools. Again, you might be more of a a fan of a specific stack or a specific tool. I went through all of them and I'll explain why these were the specific steps. So the four levels were first with lovable and I'll explain why lovable. The second step was a mix of lovable and cloud code. The third step is cloud code uh and versel as the infrastructure and the fourth step is like multicloud code multiversell and a lot of automation and agents. All right. So that's how it works. So, I'm going to show you and kind of explain what happens with uh each one. So, let's start with uh lovable. First of all, why did I start with level? Because honestly, it's way less scary than just jumping straight into an IDE or jumping straight into uh a code environment. It the team at Loveable, first they're European, so of course I'm going to be a big fan of what they're doing. And second, they built a really easy product for anyone who has never coded, who potentially is a bit afraid to just start doing, right? This is step number one. So, and you can build like really simple tools. And my recommendation is you start with something personal. You don't start with something on your professional environment because that allows you to actually explore the tool. For example, uh I built so my family has a summer vacation home, right? And we

好。我先给你点背景：我要给你看的，其实就是我自己怎么从「我不是开发者、我不会写代码」一步步走到开始动手建东西的。这中间有好几步，对吧？这是对我管用的那套打法。不代表它对每个人都管用，但它给了我一点安全感，我会解释原因。它基本上分四步。第一步——我会提到不同的工具，你可能更偏爱某个特定的技术栈或某个特定工具，这些我都试过一遍，我会解释为什么我走的是这几步。这四个层级：第一步是用 Lovable，我会解释为什么是 Lovable；第二步是 Lovable 加 Claude Code 的混合；第三步是 Claude Code，再加 Vercel 作为基础设施；第四步就是多个 Claude Code、多个 Vercel，再加上大量的自动化和 agent（智能体）。好，运作方式就是这样。我会一边演示一边讲清楚每一步发生了什么。那我们先从 Lovable 开始。首先，我为什么从 Lovable 起步？因为说实话，它比直接跳进一个 IDE、或者直接跳进一个代码环境要没那么吓人。Lovable 这个团队——首先他们是欧洲人，所以我当然会很支持他们在做的事——其次，他们做了一个对任何从没写过代码、甚至可能有点害怕动手的人来说都非常容易上手的产品。这就是第一步。你可以用它来搭一些真的很简单的工具。我的建议是，从一个个人项目开始。别一上来就在你的工作环境里搞，因为个人项目能让你真正放开去探索这个工具。比如说，我家有一套避暑的度假房，对吧？我们

[6:22] Andre

are quite a lot of people and we needed a way to manage who has the house in certain periods of the year, who's going to be there, is the house fully booked or not. And this is not commercial like this is for the family, right? So I started actually building my first product on level was this simple tool to manage the availability of people. Now [snorts] this is actually a great way to start because again there's no risk like you're not contributing to the company's repository. You don't even need access because this is just for you and you can do mistakes the codebase it doesn't need to be beautiful because who cares at this level like it's fine. So you start building on love bowl and the beauty about love now is that [snorts] they bring a lot of the stack so that you don't actually need to care or think about it like databases authentication all the type of things that often tech non-technical people they don't even know that it matters right if you spend a bit of time on product or engineering you know what authentication is you know what these flows are you know what to call things but when you have never worked there like you don't even know that is something important So with Loveable as a step one, it actually doesn't matter. So it's a great way to get started. So this is my start. And by the way, the the app, whether it's an app or landing page, it can be as complex or as simple as you want, doesn't matter. You can play with it. You can start gaining a bit of feedback on how you're building. Like one really cool way is ask always asking your prompts if you're missing out on something. If you're not questioning or asking or prompting something you should and you'll always get the feedback back like you're working with a senior

家人挺多的，我们需要一种方式来管理一年中某些时段谁住这套房、谁会去、房子是不是被订满了。这不是商业用途，纯粹是给家里用的，对吧？所以我在 Lovable 上动手做的第一个产品，就是这个用来管理大家入住档期的简单工具。这其实是个很好的起步方式，因为它没风险——你又不是在给公司的代码仓库做贡献，你甚至不需要任何访问权限，因为这就是给你自己用的，你可以犯错，代码也不需要写得多漂亮，因为在这个阶段谁在乎呢，烂就烂吧，没关系。所以你就在 Lovable 上开始建。Lovable 的妙处在于，它把很多技术栈都帮你打包好了，让你根本不用去操心、也不用去想那些事——比如数据库、身份认证（authentication），这类东西非技术的人往往根本不知道它们重要。如果你在产品或工程领域待过一阵子，你知道 authentication 是什么，你知道这些流程是什么，你知道这些东西该怎么称呼。可如果你从没在那种环境里工作过，你甚至不知道这是个重要的东西。但有了 Lovable 作为第一步，这些根本无所谓。所以它是个很棒的起步方式。这就是我的起点。顺便说一句，不管你做的是 app 还是落地页，它可以做得很复杂，也可以做得很简单，无所谓。你可以拿它来玩，开始对自己「怎么建东西」积累一点反馈。一个特别好用的办法，就是在你的 prompt 里一直追问：自己是不是漏掉了什么。如果你没在质疑、没在追问、没在 prompt 一些本该问的东西，它总会把反馈反给你——就像你在和一位资深

[8:02] Andre

engineer which for now AI is a senior engineer to you and they'll also give you feedback and it's actually a great way to learn. So that is step number one. Then step number two, which is actually an accidental evolution, but it worked really well for me, which was I wanted to be able to do more, right? And lovable uh at least back when I was using loveable was still a bit limited on a few things. So I installed cloud code, right? And I installed cloud code on the cloud uh desktop app, right? So you start working with cloud code on the desktop app. Um actually, I'm gonna I'm going to switch screens to the desktop app. All right? So, you should be seeing clot code desktop app, right? And you land here and let's be honest, it's it's it's a bit scary. You land here and it's a bit scary. Like, you don't know what this is. You're not seeing a product. You just came from lovable where you saw the product in front of you. You had a chat. You had feedback. You don't even know what to do here, right? Okay. So, what I did was I knew I had to get my code somewhere. That somewhere typically is some repository. So you start an account on GitHub. That's the first thing. Super easy. And you connect your cloud code to your GitHub. So when you connect your cloud code to your GitHub, they're linked. You can also connect your lovable to the same cloud code and GitHub repository. So they're all synced. That means that if you actually do code on the cloud code desktop app and you update your repository on GitHub, Lovable will also get that update, right? And the good thing about this is that even though you don't have a visual understanding or at least easily a visual way of seeing your product evolving, you can actually use cloud uh lovable sorry you can use

工程师合作——而现在的 AI 对你来说就是一位资深工程师——他们也会给你反馈，这其实是个绝佳的学习方式。这就是第一步。然后第二步，其实是个意外的演进，但对我来说效果特别好：我想做更多的事，对吧？而 Lovable——至少在我用它那会儿——在一些地方还是有点受限。于是我装了 Claude Code，对吧？我把 Claude Code 装在了 Claude 的桌面 app 上。所以你开始在桌面 app 上用 Claude Code。我其实……我换个屏幕切到桌面 app。好，现在你应该能看到 Claude Code 的桌面 app 了。你打开它，落到这个界面——说实话，这有点吓人。你落到这儿，会有点慌。你不知道这是什么。你看不到一个产品。你刚从 Lovable 过来，在那边你能看到产品就摆在你面前，你有个聊天框，你有反馈。在这儿你甚至不知道该干嘛，对吧？好。所以我当时做的是：我知道我得把我的代码放到某个地方。那个「某个地方」通常就是某个代码仓库。所以你去 GitHub 上注册一个账号，这是第一件事，超级简单。然后你把你的 Claude Code 连接到你的 GitHub。当你把 Claude Code 连到 GitHub 之后，它们就关联起来了。你也可以把你的 Lovable 连接到同一个 Claude Code 和 GitHub 仓库。这样它们就全都同步了。这意味着，如果你真的在 Claude Code 桌面 app 上写代码、更新了你 GitHub 上的仓库，Lovable 也会同步到那次更新，对吧？这样做的好处是，即便你没有一个可视化的理解方式、或者说没有一种能轻松看到产品演进的可视化途径，你其实还是可以用 Claude——抱歉是 Lovable——你可以把

[9:49] Andre

lovable as your infrastructure. What that means is that you can be pushing code on cloud code with all the flexibility on all the great things that cloud code offers but you can still see the evolution of your product on lovable with all the easiness of the [snorts] lovable platform. And I think this is actually a a great transition because you're not fully getting out of it. You don't have to deal with hosting and infrastructure and you don't need to think about deployments because look, let's say that I am contributing to uh my lovable project, right? I used to think I had a retention problem. Turns out I had a messaging problem. I was sending [music] the same onboarding emails to every new user whether they activated on day one or never logged in again. [music] I had no idea who was slipping or why. Customer.io changed that. Every message I send is now based on what users actually do in the product. Someone hits a key activation moment, they get nudged to the next one. Someone goes quiet, they get a different path entirely. Their AI agent makes it fast. I [music] describe the campaign I want and it builds the full journey form. Triggers, timing, copy, even branching logic. And when I want to know how something is performing, I just ask the agent directly and it tells me what to do next. They also have an MCP server, which means AI tools like Claude can see directly what's happening in your customer.io IO workspace, your segments, your customer data, your attribution, all of it. So instead of explaining your business context every [music] time you need help, Claude already knows it. Notion used customer.io to personalize their onboarding and hit nearly 50% open rate, improved conversion by 6 to 7% [music] with localized campaigns and pushed open

Lovable 当作你的基础设施。意思就是，你可以在 Claude Code 上推代码，享受 Claude Code 提供的所有灵活性和各种好处，同时你仍然可以在 Lovable 上看到你产品的演进，享受 Lovable 平台带来的所有便利。我觉得这其实是个很棒的过渡，因为你没有完全脱离它。你不用去处理托管和基础设施，也不用去操心部署——因为你看，假设我正在给我的 Lovable 项目做贡献，对吧？（广告插入）我以前以为我有一个留存问题，结果发现我其实有的是一个「触达信息」的问题。我当时给每一个新用户发的都是同样的 onboarding 邮件，不管他第一天就激活了、还是再也没登录过。我完全不知道谁在流失、为什么流失。Customer.io 改变了这一点。现在我发的每一条消息，都是基于用户在产品里实际做了什么。有人触发了某个关键的激活节点，就会被推着去走下一步。有人沉寂了，就会被引导走另一条完全不同的路径。它的 AI agent（智能体）让这一切变得很快。我只要描述我想要的活动，它就能搭出完整的旅程——触发条件、时机、文案，甚至连分支逻辑都有。当我想知道某个东西的效果怎么样，我就直接问这个 agent，它会告诉我下一步该怎么做。他们还有一个 MCP server，意味着像 Claude 这样的 AI 工具可以直接看到你 Customer.io 工作区里正在发生的事——你的用户分群、你的客户数据、你的归因，全都能看到。所以你不用每次需要帮助时都重新解释一遍你的业务 context，Claude 已经知道了。Notion 用 Customer.io 来个性化他们的 onboarding，把打开率做到了将近 50%，靠本地化活动把转化率提升了 6% 到 7%，还通过 A/B

[11:22] Andre

rates up another 20% through AB [music] testing. The idea is simple. Customer.io helps you deliver more impact from every message you send. If you're a Pammer founder and your onboarding is still one-sizefits-all, try customer.io at customer.io. Today's episode is brought to you by Amplitude. Replays of mobile user engagement are critical to building better products and experiences. But many session replay tools don't capture the full picture. Some tools take screenshots every second, leading to choppy replays and high storage costs from enormous capture sizes. Others use wireframes, but key moments go missing, creating gaps in your understanding. Neither approach gives you a truly mobile experience. Amplitude does things differently. Their mobile replays capture the full experience. Every tap, every scroll, and every gesture with no lag and no performance hit. It's the most accurate way to understand mobile behavior. See the full story with amplitude. Unlovable. Let's say this is a project that I've used in that transition period. So I was building a platform, right? And this platform was for my school builder scamp in the beginning and I was already using cloud code because I wanted to understand the tool. I wanted all the capabilities but I didn't want to completely leave lovable because it was super comfortable like I had my chat here. I could see and ask questions anyway. But uh what do you see here on the chat on the left side is merges right? What that means is that I'm actually using cloud code to work. I'm merging meaning I'm sending the code to GitHub and GitHub is telling loveable look there was an evolution on the product and it changes here. So the beauty about this is that I can actually test the product do my QA my quality

测试把打开率又往上拉了 20%。道理很简单：Customer.io 帮你让发出去的每一条消息都产生更大的影响。如果你是个 PM 或创始人，而你的 onboarding 还是「一刀切、所有人一个样」，那就去 customer.io 试试 Customer.io 吧。今天这期节目由 Amplitude 赞助。要做出更好的产品和体验，回放移动端用户的互动行为至关重要。但很多 session replay（会话回放）工具并不能捕捉到完整的画面。有些工具每秒截一张图，结果回放卡顿，而且因为捕获体量巨大，存储成本很高。还有些用线框图，但关键时刻丢失了，让你对全貌的理解出现断层。这两种做法都给不了你真正的移动端体验。Amplitude 的做法不一样。他们的移动端回放能捕捉完整体验——每一次点按、每一次滑动、每一个手势，没有延迟，也不拖累性能。这是理解移动端行为最精准的方式。用 Amplitude 看到完整的故事。（广告结束）回到 Lovable。假设这是一个我在那段过渡期里用过的项目。我当时在搭一个平台，对吧？这个平台是给我的 builder 学校做的，叫 BuilderCamp，一开始我就已经在用 Claude Code 了，因为我想搞懂这个工具，我想要它所有的能力，但我又不想彻底离开 Lovable，因为它太舒服了——我这儿有我的聊天框，反正我能看、能问问题。但你在左边这个聊天里看到的是 merge（合并），对吧？这意味着我其实是在用 Claude Code 干活，我在 merge，也就是把代码推送到 GitHub，然后 GitHub 去告诉 Lovable：嘿，产品有了一次演进，于是它在这里发生变化。所以妙处就在于，我可以直接在 Lovable 上测试这个产品、做我的 QA、做我的质量

[13:00] Andre

assurance directly on lovable and as I'm using lovable as my infrastructure the deployment meaning putting stuff live for people in the actual URL comes from lovable I don't need to deal with all the more technical infrastructure like versel and I'm going to go there next because love takes care of that so it's it's a accidental uh jobs to be done way of using loveable that I don't think they intended, but it worked really well and it's a great bridge.

保证（quality assurance），而且因为我把 Lovable 当作我的基础设施，所以部署——也就是把东西上线、让大家在真实 URL 上访问到——这件事是 Lovable 来搞定的。我不需要去处理那些更偏技术的基础设施，比如 Vercel——这个我下一步会讲到——因为 Lovable 把它包办了。所以这是一种意外的、用「待办任务（jobs to be done）」的思路去使用 Lovable 的方式，我觉得这并不是他们当初设计时的本意，但它效果特别好，是个很棒的桥梁。

[13:28] Aakash

I haven't seen anybody talk about this. So, this is new alpha. This is really exciting information for people. If somebody's just they need that extra step of you showing them, can you just show us exactly how to connect lovable and clawed desktop app to the right GitHub repo? That's the same one.

我还没见过有人讲过这个。所以这是全新的独家内幕，对大家来说是非常令人兴奋的信息。如果有人就是需要你多走一步、亲手演示给他们看——你能不能就给我们演示一下，到底怎么把 Lovable 和 Claude 桌面 app 连到同一个正确的 GitHub 仓库上？就是同一个仓库。

[13:46] Andre

Yeah. So, let me So, uh I I need to do some some setup. So very quickly, uh let's say let's see if I can use one that I already have. Uh [snorts] because yeah, I agree it's uh it's something different, right? So let's see if I can do this. Um yeah, so what we can do is let's actually build a a small tool or a small product right now. Uh I think that's that's the step. Okay, but let's also do this. Uh one recommendation is that you need to have your repository. Okay, let's say that you have your GitHub and it's under your name. Even my my personal one is under my name. So, it's here. Um, and this is where I'm going to basically keep all the repositories that are connected to Lovewell because again, what we're saying is this is for your personal usage or even for your business, not for the company. If it's for your company, the setup is different because your engineering team is going to have their own repository. They need to give you access, but we'll go to that a bit later. So let's say you have these are projects that I have for myself. Okay. So let's say that I want to build a new product. Let's say so I'm going to go to love bowl and I say I want to build a mentorship. So I'm going to say a mentorship matching tool. Make it simple. So I'm going to build. So what this does is I'm actually bootstrapping the tool on lovable which is way easier to start than starting on cloud code if you don't have the infrastructure yet built. So let's assume you don't. So you start on lovable you say I want to build something. So you explain and then throughout the the the episode I'm also going to show you how this gets significantly more advanced without actually you having to know a lot more than what I just did here. So level right now is going through its setup. So

好。那我……我得做点准备工作。很快，我们看看……看我能不能用一个我已经有的。因为，是的，我同意这确实是个不一样的东西，对吧？那我们看看能不能这么搞。嗯，我们可以这样：干脆现在就来建一个小工具、或者一个小产品。我觉得这就是那一步。好，但我们也顺便做这件事。一个建议是，你得先有你的仓库。好，假设你有你的 GitHub，它挂在你自己的名下。连我自己那个个人的也是挂在我名下，就在这儿。这就是我之后会用来存放所有跟 Lovable 关联的仓库的地方，因为我们一直在说，这是给你个人用的、甚至是给你自己生意用的，不是给公司用的。如果是给你公司用的，配置方式就不一样了，因为你的工程团队会有他们自己的仓库，他们得给你授权访问，不过这个我们稍后再讲。那假设你有……这些是我给自己留的项目。好，那假设我想建一个新产品。比如说，我去 Lovable，然后我说我想建一个 mentorship（导师匹配）。我会说：做一个导师匹配工具，做简单点。然后我就开始建。这一步做的事，其实就是我在 Lovable 上把这个工具的雏形搭起来（bootstrap）——如果你还没把基础设施搭好，这比直接从 Claude Code 开始要容易得多。那我们就假设你还没搭好。所以你从 Lovable 开始，你说我想建个东西，你把需求一讲。然后在这期节目过程中，我还会演示给你看，这东西怎么会变得明显高级很多，而你其实并不需要懂得比我刚刚做的这点东西多多少。好，Lovable 现在正在跑它的初始化设置。所以

[15:41] Andre

while it's working, it's important you need to have your repository here. And then what you also need to have is your repository connected to level. But I'll show you how you do this. So now it's I asked it to be simple so it doesn't take a long time, but it still might take a few seconds in. So we want to make sure that just to recap the flow is you have your GitHub repository, you're starting on lovable, but you also have a cloud code account. Now, you can use I think you need maybe a pro account to be able to use Cloud Code. Not fully sure if the free account allows you to do this, but let's say you're on the lowest plan, which is more than enough to start playing with this. Uh, you have your Cloud Code account. All right. So, now what I'm going to do, oh, and it's important to know that you also need to have your Cloud code connected. So, your GitHub connected to your cloud code. While Loveable is building, I'm going to switch the share to my cloud code desktop app. So, you should be seeing my cloud code. And if you go to your connectors, and you can see I have a lot of connectors here, you [snorts] need to guarantee your GitHub integration is connected. And when you're connecting this, mine is already connected. You're going to choose your account. You're going to log in and authenticate. You're going to put your password and it's going to link. What that means is that when you go to cloud code, so if you see here, when you go to cloud code, your repository is going to show here, you'll be able to work on it. Okay? Uh and you can choose your repository. So these are my repositories right now. So what I'm going to do is as I'm going to be creating a new repository on this new love tool, I'll then open it up here. So I'll add it here. Okay. So let's go back

趁它在跑，有件事很重要：你这里需要有你的仓库。然后你还需要的，是把你的仓库连接到 Lovable。不过我会演示给你看怎么做。现在……我刚让它做简单点，所以不会花太久，但可能还是要等几秒钟。我们想确保——简单回顾一下整个流程：你有你的 GitHub 仓库，你从 Lovable 起步，但你同时也有一个 Claude Code 账号。现在，我觉得你可能需要一个 Pro 账号才能用 Claude Code，我不太确定免费账号能不能这么用，但就算你用的是最低档的套餐，那也足够你开始玩这套东西了。你有了你的 Claude Code 账号。好。那现在我要做的——哦，还有一点很重要：你也需要把你的 Claude Code 连上，也就是把你的 GitHub 连接到你的 Claude Code。趁 Lovable 还在搭，我把共享屏幕切到我的 Claude Code 桌面 app。所以你现在应该能看到我的 Claude Code。如果你进到 connectors（连接器），你能看到我这里有很多 connector，你需要确保你的 GitHub 集成是已连接的。连接的时候——我的已经连好了——你要选你的账号，你要登录并完成认证，你输入你的密码，它就会关联上。这意味着当你进到 Claude Code，你看这里，当你进到 Claude Code，你的仓库就会显示在这里，你就能在上面干活了。好吧？然后你可以选你的仓库。这些就是我现在的仓库。所以我接下来要做的是：因为我会在这个新建的 Lovable 工具上创建一个新仓库，到时候我就会在这儿把它打开，把它加进来。好。那我们回到刚才。

[17:21] Andre

to Loveable. Let's see if we already have uh our tool available. So it's called mentor match. All right. So we have something that was built. This is what I call the bootstrap. So the bootstrap is you start with a prompt. However big, however simple, however complex, it doesn't matter. You're bootstrapping the product. Okay. Now it's here. Now let's say you want to continue on cloud code because you're already okay with working with the tool. So, what you're going to do is you want to make sure that you connect this to your um Okay, give me two seconds. Let's say you connect this to your GitHub. Okay, so you should be able to go to uh GitHub. So, git GitHub and you're going to have your account. So, I'm going to connect in this case I have multiple accounts. So, I'm going to connect to my personal account. So, I'll connect. What that means is now the code that lovable built is going to go straight to GitHub. Now important thing with lovable if you create your code on cloud code send it to GitHub you won't be able to actually port the code directly into love. It doesn't work that way. You need to start on lovable. They made the product super simple for that specific use case. All right. So this now created a new repository called mentor match simple. So if I actually go to my GitHub and I refresh it, you now see mentor match simple is here. So now you go to clot code. Remember up until now we bootstrapped the product on love. We connected to GitHub. I showed you the GitHub page and since your cloud code you connected to GitHub your GitHub via the connectors. Now if you actually are in cloud default and you select the repo, you'll see that now mentor match is here. Okay. So now I know I'm coding to mentor match. So now whenever I do

切到 Lovable。我们看看是不是已经有我们做的那个工具了。它叫 mentor match。好，我们已经做出来一个东西了。这就是我说的「bootstrap（起步）」。所谓 bootstrap，就是你从一个 prompt 开始，不管它多大、多简单、多复杂，都无所谓，你就是在给产品起步。好，现在它在这儿了。假设你想继续在 Claude Code 上做，因为你已经习惯用这个工具了。那你要做的，是确保把它连上你的……好，给我两秒。假设你把它连到你的 GitHub。好，你应该能进到 GitHub。点 GitHub，然后这里会有你的账号。我这里有好几个账号，所以我连到我的个人账号。点连接。这意味着 Lovable 做出来的代码现在会直接进到 GitHub。这里 Lovable 有个很重要的点：如果你在 Claude Code 上写代码、发到 GitHub，你是没法把代码直接导回 Lovable 的。它不是这么运作的，你必须从 Lovable 起步。他们就是把产品针对这个具体场景做得超级简单。好，所以现在它创建了一个新仓库，叫 mentor match simple。如果我去我的 GitHub 刷新一下，你现在就能看到 mentor match simple 在这儿了。那现在你去 Claude Code，记住到目前为止我们是在 Lovable 上给产品起的步，连上了 GitHub，给你看了 GitHub 页面，因为你的 Claude Code 通过 connectors 连上了你的 GitHub。现在如果你在 Claude Code 默认界面里选那个 repo，你会看到 mentor match 现在就在这儿了。好，所以现在我知道我是在给 mentor match 写代码。那现在只要我做

[19:10] Andre

things here on cloud code on cloud code desktop app I'm going to do something. So let's say I want to change the design system to green. So let's keep it simple. Okay. I'm just asking it to change. Keep in mind we started on lovable. So I'm going to switch to lovable. And as you can see here, the tool is basically beige and and red tones theme that is more on this uh palette. And I I want to change the the setup. I asked cloud code to do a bit more uh green. So what will happen is I'm actually coding into the repository. And when I say merge or add to the repository, as lovable is connected to the repository, it's going to update here. And you'll be able to see. So you'll be able to see do I like it? Is this the experience or the feature that I wanted in this case I'm changing the design system so I'll be able to actually visually see is this what I was looking for and if I don't like I can either do the changes directly here on lovable or I can continue working on cloud code and in reality what I'm doing is I'm using lovable as my infrastructure before I bring this to production before I actually publish keep in mind this publish button is what puts this live not the actual clot code merging into that repository I'm using Loveable as my infrastructure and it's in this case super simple because I don't need to deal with branches. I don't need to deal with way more complex stuff. Keep in mind this is non-technical. So we're trying to simplify life. So I am going to now switch to cloth code to see what is happening there. [snorts] Okay. So the tool is working and done. It says light theme replaced orange tones dark theme. So it basically worked on the background. Uh and now what we're going to do is we're going to ask it to actually uh merge this. So we're telling

在 Claude Code 里、在 Claude Code 桌面端做点什么，我都会动手。比如说我想把设计系统改成绿色，咱们就保持简单。好，我就是让它改一下。记住我们是从 Lovable 起步的，所以我切到 Lovable。你能看到这里，这个工具现在基本上是米色加红色调的主题，更偏这个色系。我想改一下这个配色，我让 Claude Code 弄得绿一点。会发生的是，我其实是在往这个仓库里写代码。当我说 merge、或者说加进仓库的时候，因为 Lovable 连着这个仓库，它就会在这儿更新。然后你就能看到了。你就能看到：我喜欢吗？这是不是我想要的体验或功能？这次我改的是设计系统，所以我能很直观地看到：这是不是我要找的效果？如果我不喜欢，我可以直接在 Lovable 这儿改，也可以继续在 Claude Code 上做。其实我在做的事情，是把 Lovable 当成我在上线前、在真正发布前的基础设施。记住，是这个 publish 按钮才把东西推上线的，不是 Claude Code 把代码 merge 进那个仓库这一步。我把 Lovable 当我的基础设施用，这次特别简单，因为我不用处理 branch，不用处理那些复杂得多的东西。记住这是面向非技术人员的，我们是想把生活简化。所以我现在切到 Claude Code 看看那边发生了什么。[吸鼻子] 好，工具在跑，搞定了。它说浅色主题替换了橙色调、深色主题。它基本上是在后台完成了。现在我们要做的是让它真正去 merge 这个。所以我们告诉

[21:08] Andre

this I want you to update the product itself. Like I want you to take the code you just built. They're going to be checking for a pull request. Creates one. So it's doing all the stuff that typically your engineering team is doing that you as a product manager you don't tend to see or care. [snorts] And now you can still not see or care, but it's happening anyway. So now the pull request was created and merged, which means that if I actually go into lovable, it's going to be changing. Remember the previous plet was beige with red tones. So now we should be seeing something different, right? And one thing you'll see is that see here on LoveBall where you can actually see switch design system callers. This came from GitHub because you just merged something from cloud code directly. So if things worked out, we should do some update and the product should have changed. Again, I don't know what I'll be able to QA or I'll be able to see it. It depends on what happened with the code. But I asked to the design system to change. All right. So it's updating. So you already know that something's happening in the background. Uh, and by the way, see this is what happened. So the design system changed. You didn't work on Love Bowl, but you're able to QA. You're able to test. You're able to see I don't like this. I want this to be different. So let's do something else. Let's say I don't like this uh header. So I'm actually going to take a screenshot. And I just screenshot. I don't know if you can see this on the screen, but I took a screenshot. And what I'm going to do is I'm actually going to go and paste this on cloud code and say I really don't like the header. So now I'm going to share my cloud code. Keep in mind you're using this format which is what I

它，我要你更新产品本身。就是说我要你把你刚写的代码拿过来。它会去检查有没有 pull request，没有就创建一个。所以它在做的全是那些通常你的工程团队在做、而你作为产品经理一般看不到也不太关心的事。[吸鼻子] 现在你还是可以不看不管，但它照样在发生。所以现在 pull request 创建好并 merge 了，这意味着如果我真的进到 Lovable，它就会变。记住之前的配色是米色加红色调，所以现在我们应该看到点不一样的东西，对吧？你会看到一点，就是在 Lovable 这儿你其实能看到「切换设计系统」之类的提示。这是从 GitHub 来的，因为你刚从 Claude Code 直接 merge 了东西过去。所以如果一切顺利，应该会有更新，产品应该变了。再说一次，我也不知道我能 QA 到什么、能看到什么，这取决于代码那边发生了什么。但我让它改设计系统了。好，它在更新了。所以你已经知道后台有事情在发生。顺便说，看，这就是结果。设计系统变了。你没在 Lovable 上动手，但你能 QA，能测试，能看到「我不喜欢这个，我想要不一样的」。那咱们再来一个。比如说我不喜欢这个 header。我去截个图。我截了。我不知道你们在屏幕上看不看得到，但我截了一张图。然后我要做的，是去 Claude Code 把这个粘上去，说我真的不喜欢这个 header。所以现在我要分享我的 Claude Code。记住你用的就是这个方式，这就是我所谓的

[22:57] Andre

call the bridge is you're using love as a bit of a QA infrastructure. Uh but you're still using cloud code and everything cloud code brings to the table. And this will include skills and agents. We'll talk more about that. But you can still in the transition period use LoveBall as a bit of a way of hosting your infrastructure, dealing with your product, visually testing it, which becomes a big part of your job. So I just pasted a screenshot I took and I say I don't like this header. Do something different. You can go like you don't even need to specify it. You can just say do something different. And then you'll see it changing on lovable. And that's also a great way to experiment to try new designs in a really simple way. I mean there's other new tools like claw design and whatnot. But if you're trying to simplify your life because you're just getting started, this is actually a great way. So it's running everything. So guaranteeing that it understands what you asked, understanding the screenshot, it's having it's going to all the context of the code. And now again the same thing is going to happen. It's going to give the implementation. You're going to ask it to merge it. And then you're going to see the change on the uh lovable environment. So now it's done. Uh now it's committing. So it's actually already knowing what to do because it adapts to your uh to to to the way you worked. And we're just going to ask it is this merged because I want to make sure that this is on GitHub. If it's not on GitHub, you won't see it on level. So I can even ask stuff. By the way, one of the most interesting hacks for nontechnical people is the interactions with clot code. They don't need to be just I need this implemented implement. It can actually be a conversation that

「bridge（桥接）」：你把 Lovable 当成一种 QA 基础设施来用，但你还是在用 Claude Code，以及 Claude Code 带来的一切，这就包括 skills 和 agents，这个我们后面会细说。但在过渡期，你还是可以把 Lovable 当成一种托管你基础设施、处理你产品、做可视化测试的方式——而可视化测试会变成你工作里很重要的一块。所以我刚粘了一张我截的图，说我不喜欢这个 header，弄点不一样的。你甚至都不用说具体怎么弄，你就说「弄点不一样的」就行。然后你就会看到它在 Lovable 上变。这也是一个很好的实验方式，用一种特别简单的方法去试新设计。我是说，还有别的新工具，比如 Claude 的设计工具什么的。但如果你是想简化生活、因为你刚起步，这其实是个很好的办法。所以它在跑所有东西。它在确保它理解了你的要求，理解了截图，它拿到了代码的全部 context。然后又是同样的流程：它会给出实现，你让它 merge，然后你就会在 Lovable 环境里看到变化。好，现在搞定了。现在它在 commit。它其实已经知道该怎么做了，因为它会适应你的工作方式。我们就问它一句：这个 merge 了吗？因为我想确认它在 GitHub 上。如果它不在 GitHub 上，你在 Lovable 上就看不到。所以我甚至可以问东西。顺便说，对非技术人员来说最有意思的玩法之一，就是和 Claude Code 的互动。它不一定非得是「我要这个，去实现，实现」。它其实可以是一场对话，就像

[24:38] Andre

you would have with a chat of clot the same way. Yes, it's consuming tokens, but you can ask questions. You can actually ask clot code to ask you questions so that you can improve the requirements, do things differently. I mean, all of that is actually um a great way of working. You can see it as interacting with your lead engineer or your uh engineer on your squad. You do the same. You can treat it the same way. So it's asking me, do you want to merge it? I say yes. So let's actually push this. So we see the evolution on lovable. So now I'm going to pass the recording to lovable and you'll see what happens. So for a nontechnical PM, they might be intimidated by merge and branch and pull request. So, here's the simplest explanation. There is a main branch. And what you typically do when you're working on coding something is you'll go out and you'll create your own branch off the main. And once you're happy with it, then you'll submit a pull request and somebody will usually review it and that'll merge that back into the main branch. That's like the basics. I'm oversimplifying it. So, what we're doing here is we're kind of skipping the pull request review phase, which is usually what engineers do because we're just vibe coding this on our own really quick and we're just merging it to main.

你跟 Claude 聊天那样。是的，它在消耗 token，但你可以提问。你其实可以让 Claude Code 反过来问你问题，这样你就能把需求打磨得更好、换个方式做事。我是说，这些都是很好的工作方式。你可以把它看成是在和你的 lead engineer、或者你 squad 里的工程师打交道。你做的是一样的事，你也可以一样地对待它。所以它在问我：你想 merge 吗？我说想。那咱们就 push 这个。这样我们就能在 Lovable 上看到演进。现在我把录屏切到 Lovable，你们就能看到发生什么。

对一个非技术 PM 来说，他们可能会被 merge、branch、pull request 这些词吓到。所以这是最简单的解释：有一个 main 分支。你在写代码的时候通常会做的，是从 main 拉出你自己的一个分支。等你满意了，你就提一个 pull request，通常会有人来 review，然后把它 merge 回 main 分支。这就是最基础的流程，我这是在过度简化。我们这儿在做的，是有点跳过了 pull request 的 review 阶段——那通常是工程师会做的——因为我们就是自己很快地 vibe coding 一下，然后直接 merge 到 main。

[25:59] Andre

Yeah, 100%. Uh, keep in mind, we started with personal projects. The moment you go into your company and your squad, you'll be adapting yourself to the development process and the pipeline, meaning the way the engineering team works together. And you'll be able to integrate that the moment you're comfortable and they're comfortable. and you'll gain a lot more knowledge about everything just explained that you explained. Um, so for now, I mean, you don't need to be afraid of this because you don't even need to know that these terms. You can just ask it, look, I don't know what to do. Just put this live or just add this to my uh code or code base. Clot code will actually know what it means. So now let's see if this has landed. So, we're now back to Loveable. And [snorts] you can already see that the redesign hero header, which was the feature I just asked, is already here. So, it's already showing automatically. I didn't need to do anything. And Loveable takes a bit of time to update, but we already know the code is here. So, we should be seeing the header change. I don't think it changed yet. So, we'll wait for a few seconds and eventually uh there is a change in the header. Okay, now we're seeing Lovable loading the new experience with the code that we just developed on cloud code and it completely changed everything. Again, I didn't give any specifications. I just said different and it did. It's significantly different. And now to finalize this, as I said, even though you push that code, if you're using Loveball as your infrastructure, you still need to publish the app, right? So what happens is you're going to click publish. You're going to click continue. You're going to say, "Oh, is this a public link or is just for you?" Let's

对，完全正确。记住，我们是从个人项目开始的。等你一进到公司、进到你的 squad，你就得让自己去适应开发流程和 pipeline，也就是工程团队协作的方式。等你自在了、他们也自在了，你就能融进去。而且关于刚才解释的这一切，你会学到多得多的东西。所以现阶段，你真的不用怕这些，因为你甚至不需要知道这些术语。你就可以直接跟它说：听着，我不知道该怎么办，你就把这个上线、或者把这个加到我的代码、代码库里。Claude Code 其实会懂这是什么意思。那现在咱们看看这有没有落地。我们现在回到 Lovable。然后 [吸鼻子] 你已经能看到，重新设计的 hero header——也就是我刚才要的那个功能——已经在这儿了。它已经自动显示出来了，我什么都没干。Lovable 更新需要点时间，但我们已经知道代码在这儿了。所以我们应该会看到 header 变。我觉得它还没变。那我们等几秒，最后 header 会有变化。好，现在我们看到 Lovable 在加载新体验，用的是我们刚在 Claude Code 上开发的代码，它把一切都彻底改了。再说一次，我没给任何具体说明，我就说了「不一样」，它就做到了。差别非常明显。现在来收个尾，就像我说的，哪怕你 push 了那段代码，如果你是把 Lovable 当基础设施用，你还是得 publish 这个 app，对吧？所以接下来你要点 publish，点 continue，它会问你：「哦，这是公开链接，还是只给你自己看的？」咱们

[27:40] Andre

just say that you are either the free or the lowest tier. So you can actually do this. So we'll say this is public. I want people to be able to access it. And you can just actually say yes, yes, yes to all of this. If you are looking to do a commercial application, then I'd recommend you working on this. Otherwise, you can just continue and boom, your app is going to be live. So you just publish this which means that this URL people can access it. Now very important here when you do changes on cloud code and you push them they'll update here on lovable and you need to publish it to update the public link. While you don't publish lovable works like a preview you can see the link. So you click on this and you'll see that this opens up a preview link. This preview link is your way of QAing outside. So doing quality assurance or testing outside the lovable interface. You can actually see how it works on mobile, how it works on a browser. You can send the preview link to someone. So this is a way of using lovable as infrastructure.

就假设你用的是免费版或最低档。你完全可以这么做。我们就选公开。我希望大家都能访问它。这些选项你其实可以一路「是、是、是」点过去。如果你是想做一个商业应用，那我建议你在这上面好好弄。否则你就直接 continue，然后嘭，你的 app 就上线了。所以你刚 publish 了它，这意味着这个 URL 大家都能访问。现在这里很重要：当你在 Claude Code 上做改动并 push 后，它们会在 Lovable 这儿更新，但你需要 publish 才能更新那个公开链接。在你没 publish 之前，Lovable 就像一个预览，你能看到链接。你点这个，就会看到它打开一个预览链接。这个预览链接是你在外部 QA 的方式——也就是在 Lovable 界面之外做质量保证或测试。你其实可以看它在手机上怎么样、在浏览器里怎么样。你可以把预览链接发给别人。所以这就是把 Lovable 当基础设施用的一种方式。

[28:39] Aakash

Love it. So that's level two. Level one lovable. Level two lovable plus cloud code via that GitHub integration that we just walked you through. What's level three? Show us that.

太喜欢了。所以这就是 level 2。Level 1 是 Lovable。Level 2 是 Lovable 加上 Claude Code，通过我们刚带你走了一遍的那个 GitHub 集成。那 level 3 是什么？给我们演示一下。

[28:50] Andre

So level three. Level three for me is I got off Lovable, right? because I wanted to start working faster and typically to work faster you need to have branches. So now we're going to get a bit more technical. The moment you start playing with repositories and cloud code and loveable you start, if you're curious, you start understanding a bit more of things and you don't need to be as technical as your most senior engineer, not even close. But you start learning a bit about branches and you start learning about merging domain and you start learning a bit about work trees. And the moment you start playing with cloud code, you'll see yourself very quickly wanting to work with multiple sessions at the same time. What that means is that you're going to start building multiple features at the same time. Right? So that means you need to have an infrastructure that allows you to work well safely with multiple branches at the same time. That when you branch you can deal with conflicts that basically you can see stuff in a reli reliable environment. Right? for that. That means I transitioned from lovable as my infrastructure. And by the way, lovable isn't supposed to be an infra product. I just use it that way to Versel, which is way more known as the typical way of working. So what happens is you set up your Versel product, right? Uh so I'm going to I'm going to share my own. So I'll actually share the builder camp one so you can see how it actually works. And [snorts] in my case as well, you can then decide one of two things. you can keep on cloud code desktop app uh or you can start using an ID. Let's say that you like to go into the files themselves. You like to see the code you want to explore. In my case, I like to use cursor but I use cursor with cloud code. That means I

那 level 3。对我来说 level 3 就是我离开了 Lovable，对吧？因为我想开始做得更快，而通常要做得更快，你就得用上 branch。所以现在我们要稍微技术一点了。一旦你开始玩仓库、玩 Claude Code 和 Lovable，你只要有点好奇心，就会开始多懂一点东西，而且你完全不需要像你最资深的工程师那么技术，差远了。但你会开始学一点 branch，开始学 merge 到 main，开始学一点 work tree。而且一旦你开始玩 Claude Code，你很快就会发现自己想同时开多个 session。这意味着你会开始同时做多个功能，对吧？那就意味着你需要有一套基础设施，能让你安全、顺畅地同时处理多个 branch；当你分叉的时候能处理冲突，基本上就是能在一个可靠的环境里看东西。为了做到这个，意味着我从用 Lovable 当基础设施——顺便说，Lovable 本来就不该是个 infra 产品，是我自己这么用的——转到了 Vercel，那个作为「典型工作方式」要有名得多的东西。所以你要做的，是搭好你的 Vercel 项目，对吧？我来分享一下我自己的。我把 builder camp 那个分享出来，让你看看它实际怎么运作。[吸鼻子] 在我这个情况里，你接下来可以在两件事里挑一个：你可以继续用 Claude Code 桌面端，也可以开始用一个 IDE。比如说你喜欢进到文件本身里，喜欢看代码、想去探索。我自己的话，我喜欢用 Cursor，但我是用 Cursor 配 Claude Code。也就是说我

[30:36] Andre

have the cloud code extension inside cursor and I'm using cloud code basically not the cursor agents or anything but I use cursor as my ID. I get access to the files to the code if I want. I don't need to but I like it. Uh in my case personally uh and I think this is going to be a bit of a uh spaces versus tabs in engineering which is like in cursor and I can actually show you my cursor uh the cloth code. So I'm going to share my screen. Here's the dirty secret about prototyping. You spend two weeks building a prototype. You validate your assumptions. Engineering loves the direction. Then what happens? You throw the whole thing away. Bolt changes this completely. When you prototype in Bolt, you're not building throwaway mockup. You're building real front-end code that integrates with your existing design system. So, when you hand it to engineering, they don't throw it away. They ship on top of what you've built. I use Bolt every single day. I host my land PM job cohort on it. And honestly, I'm up till 2:00 a.m. some days just vibing in the tool, having fun, and building. That's when you know a product is good. When you're using it past midnight, not because you need to, but because you want to. Check out Bolt at bolt.new. Link in the show notes. I'm notoriously bad at my inboxes. I guess there's a version of that where I [music] seem cool and unavailable, but the reality is I miss sponsor emails, guest pitches, and stuff that my team actually needs me for. So, I got an AI assistant, the [music] sponsor of today's episode, Ariso. Ariso connects to my email, calendar, [music] and Slack. Then, I just chat with it over Slack, and it helps me with everything. It builds workflows to respond to emails, resolve customer issues, prep me for meetings. It actually comes to my

在 Cursor 里装了 Claude Code 扩展，我基本上用的是 Claude Code，而不是 Cursor 的 agent 之类的，但我把 Cursor 当我的 IDE 用。我能拿到文件、拿到代码——如果我想的话。我不一定需要，但我喜欢这样。就我个人而言，我觉得这会有点像工程里「空格 vs 制表符」之争，就是这种事。在 Cursor 里我其实可以给你看我的 Cursor、看 Claude Code。我来分享一下我的屏幕。

关于做原型，这里有个不能说的秘密：你花两周做了个原型，验证了你的假设，工程团队也喜欢这个方向。然后呢？你把整个东西扔了。Bolt 彻底改变了这一点。当你在 Bolt 里做原型时，你做的不是一次性的 mockup，你做的是真正的前端代码，能跟你现有的设计系统集成。所以当你把它交给工程团队时，他们不会扔掉它，他们会在你做的东西上面继续往上发布。我每天都在用 Bolt。我的 land PM job 训练营就是托管在它上面的。说实话，有时候我会在这工具里待到凌晨两点，就是图个乐子在那儿 vibe、在那儿做东西。当你这样的时候，你就知道一个产品是好的——当你过了午夜还在用它，不是因为你必须用，而是因为你想用。去 bolt.new 看看 Bolt，链接在 show notes 里。

我出了名地不会管我的收件箱。我猜这事有一种版本是显得我很酷、很难约，但现实是我会错过赞助邮件、嘉宾约稿，还有我团队真正需要我处理的事。所以我搞了个 AI 助理，也就是今天这期的赞助商 Oriso。Oriso 连着我的邮箱、日历和 Slack。然后我就在 Slack 上跟它聊，它帮我搞定一切。它会搭工作流来回邮件、解决客户问题、帮我做会前准备。它真的会来我的

[32:10] Andre

meetings, updates [music] its own knowledge, and remembers context from past conversations. So, every time I talk to it, [music] it already knows what I'm working on. I used to pay for Granola and Lindy separately. Oriso replaced both. One tool does more and it lives right in Slack where I [music] already work. Check it out ato.ai/ aos. That's a r i o.ai/ aa k ash. I hope you're enjoying today's episode. Are you interested in becoming an AI product manager, making hundreds of thousands of dollars more, joining OpenAI anthropic? Then you might want to do a course that I've taken myself, the AIPM certificate ran by OpenAI product leader McDad Jaffer. If you use my code and my link, you get a special discount on this course. It is a course that I highly recommend. We have done a lot of collaborations together on things like AI product strategy. So check out our newsletter articles if you want to see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavle Hearn, is the build labs leader. So you're going to live build an AI product with Pavvel's feedback if you take this AIPM certificate. So be sure to check that out. Be sure to use my code and my link in order to get a special discount. [music] And now back into today's episode. Uh cloud code shows as tabs, right? So you should see so you see all my tabs are up here. and actually dive deep into this in a few minutes. Uh while in the cloud code desktop app, so I'm going to share my screen back to the cloud code desktop app. They show as they show differently. So as you can see, they're here, right? And in my opinion, I don't know why again I think this is something more personal. Uh I prefer the uh vertical uh view. So cursor became comfortable for me. But I

会议，更新它自己的知识库，还记得过往对话里的 context。所以每次我跟它说话，它都已经知道我在忙什么了。我以前要分开付 Granola 和 Lindy 的钱，Oriso 把这俩都替代了。一个工具做得更多，而且它就活在 Slack 里，也就是我本来工作的地方。去 ario.ai/aakash 看看，就是 a-r-i-o.ai 斜杠 a-a-k-a-s-h。

希望你喜欢今天这期节目。你有兴趣成为一个 AI 产品经理、多挣几十万美金、加入 OpenAI 或 Anthropic 吗？那你也许会想上一门我自己上过的课——由 OpenAI 产品负责人 McDad Jaffer 主理的 AIPM 证书课程。如果你用我的码和我的链接，就能拿到这门课的专属折扣。这是一门我强烈推荐的课。我们一起做过很多合作，比如 AI 产品战略这类。所以你想看看你能学到的那种思考的质量的话，就去看看我们的 newsletter 文章。我的常驻合作者之一 Pavle Hearn 是 build labs 的负责人，所以如果你上这门 AIPM 证书课，你会在 Pavle 的反馈下实操做出一个 AI 产品。所以一定去看看，一定用我的码和我的链接，这样才能拿到专属折扣。[音乐] 现在回到今天这期节目。

Claude Code 是以 tab 的形式显示的，对吧？所以你应该能看到——你看我所有的 tab 都在上面这儿。这个我们过几分钟会深入讲。而在 Claude Code 桌面端里，我切回桌面端给你看，它们显示得不一样。你看，它们在这儿，对吧？依我看，我也不知道为什么——我又觉得这更偏个人喜好——我更喜欢竖排的那种视图。所以 Cursor 用着对我来说更顺手。但我

[33:54] Andre

think every single person will find their own comfort. All right. Uh, and again I'm not technical. It's not like I can write the code directly into the files. I'm not doing that. But I just find some comfort. And what you'll see is that when you're non-technical working on some technical stuff, you want to find the comfort areas, right? It's going to make you feel less fear and be more focused on on doing stuff. Okay. So let's go into Verscell. So as you can see, this is my Versell environment. And now this looks a bit scary if it's the first time you're seeing something like Versel. Um and on the overview you can see like my product this is builder scam web page so website uh and on the deployments what you see are all the features that I'm building right these are all features that I've been building in the last hours you can see the hours right so busy day

觉得每个人都会找到自己顺手的地方。好。再说一次，我不是技术出身。也不是说我能直接往文件里写代码，我不干那个。但我就是觉得这样有点顺手。你会发现，当你这种非技术人员在搞一些技术活儿的时候，你会想去找那些让你自在的区域，对吧？这能让你少点恐惧，更专注在做事上。好，那我们进 Vercel。你看，这就是我的 Vercel 环境。第一次看到 Vercel 这种东西，它看着是有点吓人。在 overview 里你能看到我的产品，这是 builder camp 的网页、网站。在 deployments 这儿你看到的是我在做的所有功能，对吧？这些都是我过去这几个小时一直在做的功能。你能看到时间，对吧？所以是忙碌的一天。

[34:45] Andre

um and every single one of these lines what it basically is is a branch and inside a branch you can have a feature uh change or you can have multiple changes that were maybe bundled into a single branch. And what is happening here is that every single one of these is showing you a change in the website that is not yet public. What's happening is it's saying look, you just built this and now you can test it. All right. And the good thing about Versel is it also gives you a preview link where your changes to the code are basically here and you can experiment see how it's working if you if it goes in line with your requirements and then you can say all right it's all good let's merge this let's get this into production which is let's put this on main right so if I'm a non-technical PM I'm a little confused right now Verscell kind of seems similar to lovable can you just clearly help me in my mind understand Lovable is X, cloud code is Y, Verscell is Z. What are these exactly?

嗯，这里的每一行其实就是一个分支（branch），一个分支里可以有一个功能改动，也可以有好几个改动被打包进同一个分支。这里发生的事情是，每一行都在向你展示网站里某个还没上线的改动。它的意思是说：看，你刚刚做好了这个东西，现在你可以测试它了。Vercel 的好处在于，它还会给你一个预览链接（preview link），你对代码的改动基本上都在这儿，你可以试一试、看看效果如何、是否符合你的需求，然后你就可以说：好，没问题，咱们把它合并（merge），推到生产环境，也就是推到 main 主分支上。所以假如我是一个非技术的 PM，我现在有点懵——Vercel 看起来跟 Lovable 有点像。你能不能帮我把脑子里这几个概念理清楚：Lovable 是 X，Claude Code 是 Y，Vercel 是 Z，它们到底分别是什么？

[35:48] Andre

Yeah. So, important to say that I'm using Lovable in the most atypical way possible because Lovable is a AI IDE meaning you build projects on Lovable. That's its goal. Versell also has that which is called Vzero. But what I'm showing you is the infrastructure version. And this is I'm simp oversimplifying on purpose is the infrastructure of Verscell for the applications and the projects. So what I'm showing here is basically you have your place where you code. Let's say it's cloud code and then you have the place where the code lives which is GitHub and then you have Verscell which is your bridge between your GitHub your repository and users right you need to have this connection the bridge and what you're doing is you're pushing the code from cloud code to your repository and then you're telling look versel now make the code I just created available to users that's basically it all right

嗯。首先得说明，我用 Lovable 的方式是最不典型的，因为 Lovable 本身是一个 AI IDE，意思是你在 Lovable 上构建项目，这才是它的本职。Vercel 其实也有这个功能，叫 V0。但我现在给你展示的是基础设施那一面。我故意做了过度简化——它是 Vercel 为应用和项目提供的基础设施。所以我这里展示的基本上是：你有一个写代码的地方，比如说是 Claude Code，然后你有一个代码存放的地方，也就是 GitHub，再然后你有 Vercel，它是连接你 GitHub 仓库和用户之间的桥梁。你需要有这个连接、这座桥。你做的事情就是把代码从 Claude Code 推到你的仓库里，然后告诉 Vercel：嘿，把我刚写好的代码发布给用户。基本上就这么回事。

[36:47] Aakash

so basically Lovable has some of this infrastructure, hosting, databases built into its product, so it's a little bit more easy to use. Now, we're uncovering one layer. We're showing you one more layer. Even Versel is a bunch of abstractions built upon a bunch of stuff, but we're basically showing you how you go from GitHub to

所以基本上 Lovable 把其中一部分基础设施——托管、数据库——内置进了它的产品里，所以它用起来更简单一些。而现在我们是揭开了一层，给你多展示了一层。其实就连 Vercel 本身也是一堆抽象，建立在一堆东西之上，但我们基本上是在给你展示，怎么从 GitHub 一步步走到——

[37:08] Andre

Exactly. Exactly. And by the way, one of the most important things when you're non-technical is you don't really have the time or ability to really deeply understand every technical aspect. You just want to be pragmatic and just make stuff work. That's what I did with Loveful in my beginning. And probably this is what I'm doing with Versell as well. If I'd compare my usage with technical folks, it has absolutely nothing to do with that, but it works for me. And that's what you're looking for. That is the best skill you can develop right now as a nontechnical PM who wants to start building. So I'm now going to show you my cursor and how I'm using cursor to develop which is the next level which is like okay you're using cloud code or you're using cursor with cloud code. So I'm going to switch to so we keep layering on the complexity for you guys. We had cloud code desktop app plus versell. Now we're doing cloud code inside cursor plus versel. And Andre gave you a couple reasons why he likes Cursor, the vertical visual tabs. I would add in like at least two more reasons why you might want to use Cursor. Number one, Cursor has a very, very generous free plan. So, you can use their agents to debug issues that you have with Claude Code. Let's say Cloud Code isn't spinning up and you're unable to sign into Cloud Code. You're just stuck at step zero. you open up a cursor agent, which you can do in this top right there. You see this like button up there in the top right to open up a cursor agent or you can go to the top and hit new agent. And then you can literally paste in whatever issue there. Andre's opened it up. You can paste in whatever issue you're getting like, hey, I'm unable to turn on cloud code or whatever. And the free cursor agent will

没错，没错。顺便说一句，当你是非技术背景的时候，最重要的一点是：你其实没有时间、也没有能力去深入理解每一个技术细节。你只想务实一点，让东西能跑起来就行。我一开始用 Lovable 的时候就是这么干的，现在用 Vercel 大概也是这样。如果拿我的用法跟技术大佬的用法去比，那完全是两码事，但对我来说够用了。这正是你想要的。这也是你现在作为一个想开始动手做东西的非技术 PM，能培养的最好的技能。所以我接下来要给你看我的 Cursor，以及我是怎么用 Cursor 来开发的——这是更进阶的一层，就是说，好，你用 Claude Code，或者你在 Cursor 里用 Claude Code。我现在切换一下，咱们继续给你们叠加复杂度。前面是 Claude Code 桌面应用加上 Vercel，现在我们是在 Cursor 里跑 Claude Code，再加上 Vercel。Andre 刚才给了你们几个他喜欢 Cursor 的理由，比如纵向的可视化标签。我再补充至少两个你可能想用 Cursor 的理由。第一，Cursor 有一个非常非常慷慨的免费套餐，所以你可以用它的 agent 来调试你在 Claude Code 上遇到的问题。比如说 Claude Code 起不来，你登录不进去，卡在第零步动弹不得，你就打开一个 Cursor agent——右上角就能开，你看右上角那个按钮就是开 Cursor agent 的，或者你也可以到顶上点 new agent。然后你就可以直接把遇到的任何问题粘进去，Andre 已经打开了。你把遇到的任何问题粘进去，比如「嘿，我打不开 Claude Code」之类的，免费的 Cursor agent 就会——

[38:54] Aakash

help you debug any issues. So that's reason one I recommend you guys use cursor. Reason two is what Andre mentioned around GitHub. Cursor is really good at syncing up with GitHub. Once you log into GitHub, once everything all the projects you open up in Cursor with Cloud Code will automatically be linked up to your GitHub. So this is the next level. Start using Cloud Code inside Cursor. So on this level, as you can see, what you're seeing here on top are multiple sessions. And for me, a session is I have an epic. Let's say you work in product and you work with epics or you can even say there's stories but my sessions are at epic level which means inside an epic there's like multiple features right so when I open up or spin up a new session I'm going to say look I want to tackle a specific epic I want to work on this uh let's see how we can implement this and cloud code is going to basically do the code for you you're going to interact with it I'll show you a couple examples and the moment that you are ready you're going going to say let's let's deploy this or let's merge this or let's open up pull request as a cash explain and it's going to show up as a branch as a new line on Verscell that you can test and the moment you're happy you can just come back to the same session and you can say all right everything worked I QA I saw everything I needed to see it's working let's merge this to main meaning let's put this on the live uh branch the the main branch and users can now access it. All right, so this is like level three, which is you are using cloud code. You're inside the IDE, you're pushing this to a versel or an infrastructure. You're being able to run multiple branches. As you can see here, the yellow line [snorts] is a branch that is outside the purple line,

帮你调试任何问题。这就是我推荐你们用 Cursor 的第一个理由。第二个理由就是 Andre 提到的 GitHub 那块。Cursor 跟 GitHub 同步做得特别好。你一旦登录了 GitHub，之后你在 Cursor 里用 Claude Code 打开的所有项目，都会自动跟你的 GitHub 关联起来。所以这就是进阶的一层：开始在 Cursor 里面用 Claude Code。在这一层，你可以看到，你顶上看到的这些是多个会话（session）。对我来说，一个 session 就是一个 epic（史诗任务）。比如说你在产品岗工作，你跟 epic 打交道，或者你也可以说还有 story（用户故事），但我的 session 是 epic 级别的，意思是一个 epic 里面有好几个功能。所以当我打开或启动一个新 session 时，我会说：看，我想搞定某个特定的 epic，我想做这个，咱们看看怎么实现，然后 Claude Code 基本上就会帮你写代码，你跟它互动，我等会儿给你看几个例子。等你准备好了，你就说：咱们部署吧，或者咱们合并吧，或者像 Aakash 解释的那样开个 pull request，它就会在 Vercel 上显示成一个分支、一条新的线，你可以去测试。等你满意了，你就回到同一个 session，说：好，都跑通了，我做了 QA，该看的我都看了，没问题，咱们合并到 main，意思是把它推到线上分支、main 主分支，用户现在就能访问到了。好，所以这算是第三级，就是你在用 Claude Code，你在 IDE 里面，你把东西推到 Vercel 或者某个基础设施上，你能够同时跑多个分支。你看这里，这条黄线（笑了一声）是一个分支，它在紫线之外——

[40:42] Andre

which is your main, which is your uh the branch that people are using. And eventually I merge it meaning they combine which means the features that I worked on the yellow line are now available on the uh purple one. And again the visual part of cursor is is nice for nontechnical people because it makes it very simple for you to understand what's happening now. You don't need to understand git and how branches work and whatnot. You don't need to be very technical there because the visual explains you what's happening. Right? So that's level three. The last level or level four is agents and having agents and skills and creating your own process. I think that is the last level. It allows you to actually run multiple sessions in parallel working on multiple projects at the same time. Uh being able to actually ship very large epics in parallel uh without actually creating problems for your product and even experiment on Versel with different approaches. So I I'd say that is the last level uh that we can get to.

紫线就是你的 main，是大家正在用的那个分支。最终我会把它合并，也就是把它们合到一起，意思是我在黄线上做的那些功能，现在在紫线上也能用了。再说一遍，Cursor 的可视化部分对非技术人员来说很好，因为它让你非常容易理解现在发生了什么。你不需要懂 git、不需要懂分支是怎么运作的之类的，你在这儿不需要很懂技术，因为可视化已经把发生的事情解释清楚了。对吧？所以这就是第三级。最后一级、也就是第四级，是 agent——拥有 agent 和 skill，并创建你自己的流程。我觉得这就是最后一级了。它能让你真正并行跑多个 session，同时做多个项目，能够真正并行交付非常大的 epic，又不会给你的产品制造问题，甚至还能在 Vercel 上用不同方案做实验。所以我会说，这就是我们能达到的最后一级了。

[41:44] Aakash

All right, agents. How do I build those?

好，agent。这些我该怎么搭建？

[41:46] Andre

Okay, so the the this fourth level, the agents. Uh the most interesting thing is or or actually let's let's say it like this. The biggest fear a lot of people have is like oh vibe coded code is bad code or when you're building with agents or vibe coding uh they're going to do like they're going to create a lot of complexity, a lot of lines of code. And thinking like this is not wrong. Like it happens to a lot of people, especially when you're nontechnical. You don't know what you're asking. It's very easy with very simple prompts to be creating a lot of slop or a lot of trash. That's where a good agent infrastructure can help you. So I want to show you what I have. And by the way, I want to show you also what I bring to my team. So [snorts] what I did was I built my own repository of agents, of skills, and even my Claude MD, which is the memory or the culture. I like to call it the values of my claude or the interactions I have with him. And this is basically what allows me to work very freely without being super considerate about the rules or about what I need to care about when I'm talking with clot code because I know the agents and the skills in my cloud MD will take care of that for me. So let me dive a bit deeper because this is what I call level four because it frees you time. It gives you time to focus on what you should be focusing which is am I solving the right problem? Do I understand the problem well enough? Do I have all the requirements? Have I talked with all the people? Like if you're spending time on solution design, you're not going to be spending enough time on problem discovery. And we all know that the best product managers out there, they spend more time on problem discovery, right? But you need to create your infrastructure. I call it the

好，那这第四级，agent。最有意思的是——或者，咱们这么说吧。很多人最大的恐惧就是：哦，vibe coding（凭感觉编程）写出来的代码是烂代码；或者当你用 agent 来构建、或者 vibe coding 的时候，它们会搞出一大堆复杂度、一大堆代码行。这么想其实没错，这种情况确实发生在很多人身上，尤其是当你非技术背景的时候，你不知道自己在要求什么。用一些很简单的 prompt，很容易就生成出一大堆 slop（垃圾内容）、一大堆废料。这正是一套好的 agent 基础设施能帮到你的地方。所以我想给你看看我有什么。顺便说一句，我还想给你看看我带给我团队的是什么。所以（笑了一声）我做的事情是，我搭建了我自己的 agent 仓库、skill 仓库，甚至还有我的 Claude MD，也就是记忆，或者说文化——我喜欢把它叫做我那个 Claude 的价值观，或者说我跟它之间的互动方式。基本上正是这套东西让我能非常自由地工作，而不用太操心规则、不用太操心我跟 Claude Code 对话时需要顾虑哪些东西，因为我知道我那些 agent、skill 以及 Claude MD 会替我把这些都搞定。所以让我稍微再深入讲讲，因为这就是我所说的第四级，因为它把你的时间解放出来了。它给你时间去专注在你本该专注的事情上：我是不是在解决正确的问题？我是不是足够理解这个问题？我是不是拿到了所有需求？我是不是跟所有相关的人都聊过了？如果你把时间花在方案设计上，你就不会有足够的时间花在问题探索上。我们都知道，最好的那批产品经理，他们会花更多时间在问题探索上，对吧？但你得先搭建好你的基础设施。我把它叫做——

[43:22] Andre

machine that builds the machine to be able to spend that time there. And this is my machine. So we have claw.md which again is your values. I'm going to go deep into mine in a few minutes, but I also have my agents and I have my skills. So, let's start with my Claude MD. So, as you can see, Claude MD is something that exists inside your cloud code. Uh, and every time you ask Claude something on the background, you don't see this, but on the background, they're going to be reading this. And that means that all the rules, everything you decide to put here, they're going to use it to define their own way of working. It's like when you're inside a squad, a team and you tell them, look, this is how we work. These are the things we care about, etc. You know that your team is going to be thinking about that as they make decisions or as they work. Cloud MD works exactly the same. So, in my case, I have a default behavior. I have rules. So, this is how I see it working. I have then agent strategy. I'll explain that in a minute. And I have architecture. I have specific things that happen depending on the feature that I'm asking. So all of these rules are here. I'm happy to make this available uh on the show notes or to to send on uh on the podcast. But basically this is the memory. These are the rules and these are the values that we care. Very important. As you're working and you see that you're doing things repetitively or that Claude is doing stuff that you don't like, you can actually improve your Claude MD. You can say to claude, look, I don't like this or I'm repeating this. Can you please add to Claude MD? So that the next time it already knows what to do and how to do and you don't need to keep getting that error or that issue or something

「制造机器的机器」，这样你才能把时间花在那上面。这就是我的机器。我们有 Claude.md，它就是你的价值观。我等几分钟会深入讲我自己的，但我还有我的 agent 和我的 skill。咱们先从我的 Claude MD 说起。你可以看到，Claude MD 是存在于你的 Claude Code 里的东西。每次你问 Claude 什么，在后台——你看不见——但在后台它们会读这份文件。这意味着所有的规则、你决定放进去的一切，它们都会拿来定义自己的工作方式。这就好比你在一个小队、一个团队里，你告诉他们：看，我们是这么干活的，这些是我们在意的东西，等等。你知道你的团队在做决策、在干活的时候会把这些放在心上。Claude MD 的运作方式一模一样。所以在我这边，我有一套默认行为（default behavior），我有规则（rules）——这是我看待它运作的方式。然后我有 agent 策略，这个我等会儿解释。我还有架构（architecture），就是根据我所要求的功能不同，会触发一些特定的事情。所以这些规则都在这儿。我很乐意把这份东西放到节目笔记里，或者发到播客上。但基本上这就是记忆，这些是规则，这些是我们在意的价值观。很重要的一点：当你在工作时发现自己在重复做某些事，或者发现 Claude 在做一些你不喜欢的事，你其实可以改进你的 Claude MD。你可以对 Claude 说：看，我不喜欢这样，或者我老是在重复这个，你能不能把这条加进 Claude MD？这样下次它就已经知道该怎么做、怎么处理了，你就不用一直碰到那个错误、那个问题，或者别的——

[45:03] Andre

you don't like. Right? So this is like part number one and you can see this can become super complex. You don't need mine is significantly less complex than claudes that I've seen a lot of people but it works well. Now it works well because of my agents. So let me go to the agents because I have a very specific agent that I use a lot and this is called what I call the PM agent. So this agent which uses the agent infrastructure of claude is my product manager. I have a personal product manager inside cloud and it's specifically an orchestrator. Now the PM which is a PMD uh is not going to be building stuff. It's only going to take information and deciding which other agents to call because they're going to be better at doing something, right? So, as you can see, I explain very specifically what the product manager orchestrator is, what they do. I even say never do the work yourself because there's going to be some agent better than you. You're simply orchestrating, meaning you're deciding who does what, who you go to, etc. Which honestly is a bit the work of a PM, right? And then this lost right now. What exactly am I seeing here? I'm a non-technical PM. I've never used cloud code.

——你不喜欢的东西。对吧？所以这算是第一部分，你可以看到它会变得超级复杂。你不需要这样——我的这份比我见过很多人的 Claude MD 简单得多，但它管用。它之所以管用，是因为我的那些 agent。所以让我去看看 agent，因为我有一个用得特别多的、很特定的 agent，我把它叫做 PM agent。这个 agent 用的是 Claude 的 agent 基础设施，它是我的产品经理。我在 Claude 里有一个我的私人产品经理，而且它专门是一个编排者（orchestrator）。这个 PM——它是个 PM.md——不会自己去做事。它只负责接收信息，然后决定该调用哪些其他 agent，因为那些 agent 会更擅长做某件事，对吧？所以你可以看到，我非常具体地说明了这个产品经理编排者是什么、它做什么。我甚至写了：永远不要自己动手做，因为总会有某个 agent 比你更擅长。你只管编排，意思是你来决定谁做什么、你去找谁，等等。说实话这其实有点像 PM 的本职工作，对吧？然后现在彻底懵了——我到底在看什么？我是个非技术 PM，我从没用过 Claude Code。

[46:18] Aakash

You just showed me cloud MD.

你刚刚给我看了 Claude MD。

[46:20] Andre

Yeah,

对，

[46:20] Aakash

which seemed pretty complex. And now you're in the agents folder PM. What exactly are these agents? Who is this? Does this mean that you're going to spin up a new Claude instance every time this agent is called? Is this agent going to be proactive? Help me understand what this agent is.

它看起来挺复杂的。现在你又进到了 agents 文件夹里的 PM。这些 agent 到底是什么？这是谁？这是不是意味着每次这个 agent 被调用，你就会启动一个新的 Claude 实例？这个 agent 会主动出击吗？帮我理解一下这个 agent 到底是什么。

[46:34] Andre

All right. So every time you spin a new session, your cloud.md [snorts] is loaded, right? And everything that you have inside that folder, the cloud folder, which includes your agents and your skills, they're also there. So they always exist whenever you spin up a new session, when you start a new session, when you ask something to claim MD, right? It doesn't go anywhere else. It doesn't go to the skills unless you call them. It doesn't go to the agents unless you call them specifically. It goes specifically to claude MD. Now on my claude MD I have a very important rule. Rule number one for every task call the PM agent. So it's like let's say that you're the CEO and the first thing you're going to do if you're the CEO is you go to the PM and you say I'm the CEO. We've found a new opportunity. Please work on this new opportunity. You're kind of doing the same but in this case instead of you having a team you have agents.

好。每次你启动一个新 session，你的 Claude.md（笑了一声）就会被加载，对吧？还有那个文件夹——claude 文件夹——里面的一切，包括你的 agent 和你的 skill，它们也都在那儿。所以每当你启动一个新 session、开始一个新 session、向 Claude MD 提问的时候，它们始终都在。它不会跑到别的地方去。它不会去用 skill，除非你调用它们；它不会去用 agent，除非你明确调用它们。它只会去找 Claude MD。而在我的 Claude MD 里，我有一条非常重要的规则——第一条规则：对每一个任务，都调用 PM agent。所以这就好比，假设你是 CEO，作为 CEO 你做的第一件事就是去找 PM，对他说：我是 CEO，我们发现了一个新机会，请着手处理这个新机会。你做的事情差不多就是这样，只不过这种情况下，你手底下不是一个团队，而是一群 agent。

[47:30] Aakash

So got it. It's going to call the agent which is a PMMD and then the PMMD

所以明白了。它会去调用那个 agent，也就是 PM.md，然后这个 PM.md——

[47:35] Andre

not proactive but because we've architected our cloud MD in this way that says always call the PM agent. Claude MD is always loaded. So then it goes to the PM agent and then it gets called.

——它不是主动出击的，而是因为我们把 Claude MD 架构成了这种方式，规定了永远要调用 PM agent。而 Claude MD 始终是被加载的。所以接下来它就去找 PM agent，然后 PM agent 就被调用了。

[47:47] Andre

Exactly. Exactly. And then the PM agent is going to decide which other agents are actually going to do the work. Right. And we have multiple agents here. As you can see here, you have a researcher which does what user research typically does in the team. We have discovery which is a very specific agent and I'll go a bit deeper here because it's a very interesting one. Uh we have a designer which is very knowledgeable about design system about best practices of UX. We have an engineer which is an agent that is preventing my code from being a bad code or ideally being a bad code. uh we have an implement which is the final person who's going to actually write the code and implement stuff. So these are just a few examples. One recommendation I give to people is don't try to reinvent the wheel. Try to see how you actually work with your teams and try to represent them as agents like how they work, what they care about, how they decide. Write that down and make them the agents. Right? That's one of the best recommendation. One of the worst things you could do is go on X or go on LinkedIn and see all of those skills from really famous people who have very specific ways of working and then just loading hundreds of those skills that you don't even know they exist and you're not thinking in first principles. You can learn from them. there's great content, but dive deep into which skills make sense to you, which ones could fit your uh flow and then only adopt those or ideally write your own based on what you're exploring and seeing. Right? [snorts] So this is what my PM MD is basically doing. Let me actually show this working in in a production environment. So now we are on cursor with clot code, right? And we have a feature, right? And whenever I

没错，没错。然后 PM agent 会决定实际由哪些其他 agent 来干活。对吧？我们这儿有好几个 agent。你看这里，你有一个研究员（researcher），它做的就是团队里用户研究通常做的事。我们有 discovery（探索），这是一个很特定的 agent，我会在这儿稍微深入讲讲，因为它很有意思。我们有一个设计师（designer），它对设计系统、对 UX 的最佳实践非常在行。我们有一个工程师（engineer），这个 agent 的作用是防止我的代码变成烂代码，或者说尽量别变成烂代码。我们还有一个实施者（implement），它是最后那个真正去写代码、把东西落地的人。这些只是几个例子。我给大家的一个建议是：别去重复造轮子。试着去看看你实际上是怎么跟你的团队协作的，然后试着把他们表示成 agent——他们怎么干活、他们在意什么、他们怎么做决策，把这些写下来，让它们成为你的 agent。对吧？这是最好的建议之一。你能做的最糟糕的事情之一，就是跑到 X 上、跑到 LinkedIn 上，看那些非常有名的人、有着非常特定工作方式的人分享的所有 skill，然后就一股脑加载几百个你压根不知道它们存在的 skill，而你并没有在用第一性原理（first principles）思考。你可以向他们学习，那里有很棒的内容，但要深入研究哪些 skill 对你有意义、哪些可能契合你的流程，然后只采用那些，或者最理想的是基于你自己的探索和观察去写你自己的。对吧？（笑了一声）所以这基本上就是我的 PM.md 在做的事。让我实际给你演示一下它在生产环境里怎么跑。所以现在我们在 Cursor 里跑 Claude Code，对吧？我们有一个功能，对吧？每当我——

[49:32] Andre

ask for a feature, what it's going to do is going to run my cloud MD on the background. And my cloud MD already knows that they need to call the PM. I don't need to call the PM. I just need to say what I want it to do, right? And as I built this infrastructure, they are solving the problems that I don't need to care about. I only need to care about the the feature, the problem I'm solving, the requirements I raised, like the typical thing you do as a PM, which is great because you just built your team. And I I asked this feature, right? And let's see, I got an answer like I'm not going to give you the whole context of the feature, but I got an answer from the engineer. The engineer found some things inside the codebase and gave me some recommendations, right? And it's telling me specific things so that I'm aware. I don't need to understand everything that's here. I mean, you can if you spend a bit of time. I understand it. But, um, it tells me this is my recommendation. I'm actually going to go up because I want you to see an example where multiple uh multiple agents are being called. Okay. So, perfect. We have this example. So, I asked for a specific feature, but I wasn't sure about the design. So, what the PM decided was, all right, the myself, me, Andre, is not sure about the design. I'm going to call the designer agent. So the designer agent does a brief. This is an answer, right? And it has a summary of the designer's decisions. So it talks about a specific layout. It talks about the code because it also has uh understanding of the code. It talks about visual exp uh experiences. It gives recommendations. It even asks me questions. Uh and these are questions before the engineer agent writes the code or writes the architecture. So it's

——要一个功能时，它会做的事情就是在后台运行我的 Claude MD。而我的 Claude MD 已经知道它们需要调用 PM 了。我不需要去调用 PM，我只需要说我想让它做什么就行，对吧？而因为我搭建了这套基础设施，它们会去解决那些我不需要操心的问题。我只需要操心功能本身、我要解决的问题、我提出的需求——就是你作为 PM 通常做的那些典型的事，这太棒了，因为你等于已经搭好了你的团队。我要了这个功能，对吧？咱们来看看，我得到了一个回复——我不会把这个功能的完整背景都讲给你听，但我从工程师那儿得到了一个回复。工程师在代码库里发现了一些东西，给了我一些建议，对吧？它在告诉我一些具体的事情，好让我心里有数。我不需要理解这里的一切，我是说，你要是愿意花点时间，是能理解的，我也能理解。但它告诉我：这是我的建议。我现在要往上翻一下，因为我想让你看一个调用了多个 agent 的例子。好，完美，我们有这个例子。所以我要了一个特定的功能，但我对设计不太确定。于是 PM 决定的是：好，Andre 本人对设计不确定，那我去调用设计师 agent。设计师 agent 做了一份简报（brief）。这是它的一个回复，对吧？它有一份对设计师各项决策的总结。它谈到了一个具体的布局，它谈到了代码——因为它对代码也有理解，它谈到了视觉体验，它给出了建议，它甚至还反过来问我问题。而这些是在工程师 agent 写代码、写架构之前提出的问题。所以它——

[51:15] Andre

asking me stuff so that I can answer or make decisions so that the next agent can start working on it. And the beauty about this is that even if you're not technical, which is the case, you're answering as if your own engineer or your own designer in a team in a team meeting with you would be asking you the same questions. And the fact that you're giving them the information, it prevents your code from being worse. It prevents features from being wrongly built or adding functionality that your product doesn't actually need. And this is the level four which is like you're starting to build a machine that then is going to build a product for you and you can focus a lot more on problem framing on understanding what to build what makes sense what priorities because you have the team. Now I have a final recommendation here uh which is when you're building something let's say you build a functionality you had this flow going and you get to your branch after building something and you don't like what happened you don't like the flow or you don't like the design or you don't like the decisions your instinct would be oh I'm going to just say to cloud fix these things on the feature so that it it's great and then you can push this and make it live for your user. others. That's actually not the right mindset. The right mindset is what within the flow, the pipeline, your agents and your skills failed and led to a bad result. You identify that and you change the agent or change the skill or change your cloud MD. Why? Because the next time you're going to have a feature, you don't want that to happen again. So, you just improve the machine so that in the future it becomes way easier for you to just again focus on the problem. Ask your team, ask your agents, and then ship the feature

它会问我各种问题，让我来回答、做决策，这样下一个 agent 就能接着干。最妙的地方在于，哪怕你不是技术背景——你就是这种情况——你回答问题的方式，就跟你自己是团队里的工程师、或者你自己是设计师，在团队会议上被问到同样的问题时一模一样。而你把这些信息给它，就能避免你的代码变得更糟，避免功能被做错，避免给产品加上它其实根本不需要的功能。这就是第四级，也就是你开始打造一台机器，再由它来替你造产品，你就能把更多精力放在问题框定上——搞清楚要做什么、什么才合理、优先级是什么——因为你有了一个团队。这里我有个最后的建议，就是当你在做东西的时候，比如说你做了一个功能，整个流程跑下来，做完之后切到分支，结果你不喜欢做出来的东西，不喜欢这个流程，或者不喜欢设计、不喜欢它做的那些决策——你的本能反应会是「我直接跟 Claude 说把这个功能里的这些地方改一改，让它变好，然后我就能推上去、上线给用户用了」。但这其实不是正确的心态。正确的心态是：在这条流程、这条 pipeline 里，是你的 agent 和 skill 哪个环节出了问题，导致了这个糟糕的结果。你把它找出来，然后去改那个 agent、改那个 skill，或者改你的 Claude MD。为什么？因为下一次你再做一个功能时，你不希望同样的问题再发生。所以你就是在改进这台机器，好让将来你能更轻松地再次只专注于问题：去问你的团队、问你的 agent，然后把功能

[52:59] Andre

better. I even do something else, which is if I don't like a feature I just created, I change the machine and I ask it to build it again, run the pipeline again, and see if the final result is closer or is exactly what I actually want. This is what AI native teams are doing is they're working 50% of the time on improving the infrastructure, the machine itself, rather than just tweaking feature by feature. Right? So if you actually now see uh a AI native team, what you'll see is like you can have like two or three people. You can still have the typical trio like a product manager, engineer, a designer, but they're all builders, meaning that they're all shipping code, they're all building features, but then a percentage of their time is improving the agents or the skills with their own knowledge. So the engineer is going to be improving the engineer agents and the engineer skills inside the infrastructure. The designer is going to be improving the designer agent, the designer skills and even the PM is improving the PM orchestrator skills and agent so that then every single one of them when they build they all have access to this infrastructure and it's all becoming better over time with their own ways of building. So now you have three builders, you have an infrastructure supporting them and you have a triple acceleration of what you can build. This is how you see small teams in AI native companies shipping so fast with so few people

做得更好。我甚至还会做另一件事：如果我不喜欢自己刚做出来的某个功能，我就去改这台机器，然后让它重新做一遍，再跑一次 pipeline，看看最终结果是不是更接近、或者正好就是我真正想要的。这就是 AI native 团队在做的事——他们有 50% 的时间花在改进基础设施、改进机器本身，而不是一个功能一个功能地修修补补。对吧？所以你现在去看一个真正的 AI native 团队，你会看到可能就两三个人。你照样可以有那种经典的铁三角——产品经理、工程师、设计师——但他们全都是 builder，意思是他们都在交付代码、都在做功能，但他们各自有一部分时间用来拿自己的专业知识去改进 agent 或 skill。所以工程师会去改进工程师的 agent 和工程师的 skill，把它们放进基础设施里。设计师会去改进设计师的 agent、设计师的 skill，甚至连 PM 也在改进 PM 的编排 skill 和 agent。这样一来，他们每个人在做东西的时候，都能用上这套基础设施，而且随着时间推移，它会带着每个人各自的做事方式一起变得越来越好。所以现在你有三个 builder，有一套基础设施在背后撑着他们，你就得到了产出能力的三倍加速。这就是为什么你会看到 AI native 公司里的小团队，能用这么少的人交付得这么快。

[54:24] Aakash

and it sounds like the connective layer is that team claude config that you showed because the engineer will be updating the engineer MD and what it's using there the design will be updating the design MD the PM will be updating the PM and they all are connected into that team cloud config is that right

听起来把这一切串起来的那一层，就是你刚才展示的那个团队 Claude 配置——因为工程师会去更新工程师的 MD 以及他在里面用的东西，设计师会更新设计的 MD，PM 会更新 PM 的，而他们全都连到那个团队的 Claude 配置上。是这样吗？

[54:41] Andre

yeah 100% everyone's going to be uh connected to that in my case for example I create this repository with my skills and every time I make a change, I push it there and my team gets a notification on Slack saying, "Hey, there was an update on the team's repository of skills. Please upload or download or clone it again or update your own so that you're up to date and you're using the best ones." And then you can choose which ones to use, of course, but at least you're creating standards. Now, if your company's bigger, you might even have an whole team, an AI ops team or R&D team just building this for everyone else. But if you're in a small team and those are the teams who need to accelerate more, you definitely want to invest or put time uh on that specific topic. One of the things you wrote about on LinkedIn that relates to all of this that we've just shown people is that there are now only four jobs. Can you explain this and what the future really looks like of these roles?

对，百分之百。每个人都会连到那上面。拿我自己举例，我建了这么一个仓库，把我的 skill 都放进去，每次我做了改动，就推上去，然后我的团队会在 Slack 上收到一条通知，说「嘿，团队的 skill 仓库有更新了，请上传、下载、或者重新 clone 一下、或者更新你自己的，这样你就保持最新，用的都是最好的那些」。当然，具体用哪些你可以自己选，但至少你建立了一套标准。如果你公司更大一些，你甚至可能会有一整个团队，一个 AI ops 团队、或者 R&D 团队，专门替其他所有人来搭这些东西。但如果你是个小团队——而恰恰是这些团队最需要提速——那你绝对应该在这件事上投入、花时间。你在 LinkedIn 上写过一个东西，跟我们刚给大家展示的这一切都有关系，就是现在其实只剩下四种工作了。你能解释一下这个说法、以及这些角色的未来到底会是什么样吗？

[55:35] Andre

Yeah. So, I love this post. It wasn't me originally writing it. I like to comment on it, but um this is completely true every time you look to a new startup. Like I worked for a while in VC investing in early stage and those early stage teams they're super small so they're going to be very pragmatic and you're going to have maybe three founders and you have typically one founder which is significantly more commercial you have one founder who's significantly more technical and you have typically one founder who's significantly more product oriented. Right? This is what happens. And if you think about these four roles it's what those founders look like in their inception. Right? You have the commercial one which is the hot one which is basically guaranteeing that sales are done, marketing happens, you're getting the word out. Uh you have the product person who's basically guaranteeing that something gets built. Now they have the ability to actually build it, right? And yeah, they're going to be vioding and slopping and doing a lot of stuff because in the beginning when you're trying to find product market fit, who cares if you're doing too much stuff? You're trying to get shots at the target. And then of course your technical person is going to be the person trying to guarantee that what gets done has the right scalability, is reliable, it's built the right way, etc., etc., so that when you grow the team uh when people join. So it's not that different from this reality, but now applied to multiple teams. So you can easily see uh a full stack squad that is an owner that owns a P&L, owns a impact, owns an outcome and has this stack. And the beauty about this and I want to highlight specifically the security or S sur or infra because the

嗯，我特别喜欢那篇帖子。原话其实不是我先写的，我只是喜欢去评论它。但这事是完全成立的，每次你看一家新的初创公司就能验证。我有一阵子在 VC 做早期投资，那些早期团队都超小，所以他们会非常务实，你可能就三个创始人：通常有一个创始人明显偏商业，有一个明显偏技术，还有一个通常明显偏产品。对吧？现实就是这样。如果你去想那四种角色，其实就是这些创始人在公司刚起步时的样子。你有那个偏商业的——也就是那个负责拉单的——基本上是在保证销售搞定、市场做起来、声音传出去。然后你有那个产品的人，基本上是在保证东西真的被做出来。而现在他们有能力亲手把它做出来了，对吧？是的，他们会到处 vibe coding、到处糊（slop）一堆东西，因为在早期当你还在找产品市场契合的时候，你做太多东西又有什么关系呢？你就是在拼命对着目标多打几枪。然后当然，你那个偏技术的人，会负责保证做出来的东西有合适的可扩展性、足够可靠、用对的方式搭起来，等等等等，这样当你团队扩张、有新人加入时才撑得住。所以这跟那个现实其实没多大差别，只是现在被放到了多个团队的尺度上。所以你很容易就能看到一个全栈 squad，里面有一个 owner，他对一个 P&L 负责、对影响力负责、对结果负责，并且拥有这一整套能力栈。而最妙的地方——我想特别强调一下安全、或者说 infra 这块——因为那一刻，

[57:17] Andre

moment you create a great infrastructure that allows a non-technical person to actually code with AI to a production repository. It doesn't matter if that person is not technical anymore because what matters is the infra or security person is doing a great job at protecting the repository. And protection here doesn't mean prevent the code. It means new code that comes in needs to go through a bunch of checks to guarantee that when it goes into production is safe. This is literally the same thing a senior engineer does when a junior engineer out of school joins a organization of software developers, right? It's not new. The difference is now the junior engineer is a nontechnical person using AI to vibe code and new functionality. And I see a lot of people making a fuss out of this, but this is a known reality and I think a lot of teams are going to be transitioning this way because the velocity to ship is crazy different. What's the flip side to this velocity though? And you even have the word slop here.

你一旦搭出一套很棒的基础设施，让一个非技术背景的人也能用 AI 真的往生产仓库里写代码，那这个人是不是技术背景就不再重要了，因为真正重要的是那个 infra 或者安全的人在很出色地保护这个仓库。这里说的「保护」不是指拦着不让代码进来，而是指新进来的代码必须经过一连串检查，确保它进生产环境时是安全的。这跟一个资深工程师在面对刚出校门的初级工程师加入软件开发团队时做的事，本质上是一模一样的，对吧？这不是什么新东西。区别只在于，现在这个「初级工程师」是一个用 AI 来 vibe code、做新功能的非技术人员。我看到很多人对这事大惊小怪，但这其实是个早就存在的现实，而且我觉得很多团队都会朝这个方向转型，因为交付的速度差得简直离谱。不过这种速度的另一面是什么呢？你这里甚至还用了 slop 这个词。

[58:17] Aakash

How do you avoid shipping slop? How do you avoid, you know, famously like the Claude team shipped like this, but they have bad uptime. How do you avoid those issues? Yeah, I mean again the the more you invest in inference security, the more likely are you to prevent situations like that because you create friction, right? The friction here is not preventing people from building. It's is this passing all the checks so that when it goes live, it's not creating more risk or more problems. That's number one. Number two, the friction you create on the problem on the problem side or and this is where product people investing in infrastructure should uh be putting their time because for example I have three skills that whenever I run an epic I have a jobs to be done skill I have an opportunity solution tree based on trees to amazing book and I have a Moscow skill which goes for the must should could and won't prioritization technique and what it does is like it creates three notion pages on that requirement ments on that PRD that explores those three frameworks and what I'm actually doing is I want people to read through them and see is this making sense like have you we dedicated enough time can we check and go to the next phase of solution building and until that document or that memo or that addition to the PRD which is built by the skills with cloud code is completely thought through like I don't want people building the solutions but then that becomes part of the initial process right And it's not just PMs or nontechnical PMs doing that. Engineers do that. Designers do that because we're all builders. And it completely changes the what you decide to build. And that's the two ways you prevent slop in the beginning and the end. And I want to

你怎么避免交付出 slop？你怎么避免——你知道的，就像出了名的，比如 Claude 团队东西是发出来了，但他们的可用性（uptime）很差——你怎么避免这类问题？

Andre：嗯，我还是那句话，你在推理安全（inference security）上投入得越多，你就越有可能防止那种情况发生，因为你制造了摩擦，对吧？这里的摩擦不是阻止人去做东西，而是「这东西通过所有检查了吗」，这样它上线时才不会带来更多风险、更多问题。这是第一点。第二点，你在问题这一侧制造的摩擦——这恰恰是那些投入做基础设施的产品人应该花时间的地方。比如说，我有三个 skill：每当我开一个 epic，我有一个 jobs to be done 的 skill，有一个 opportunity solution tree 的 skill（基于 Teresa Torres 那本很棒的书），还有一个 Moscow 的 skill，用的是 must / should / could / won't 这套优先级排序方法。它做的事是：在那条需求、那份 PRD 上创建三个 Notion 页面，分别用这三套框架去展开。而我真正想达到的，是让大家去读这些内容、去看：这说得通吗？我们有没有投入足够的时间？我们能不能确认一下、然后进到方案构建的下一阶段？在那份文档、那篇 memo、或者由 skill 加 Claude Code 写出来的那部分 PRD 被彻底想清楚之前——我不希望大家就开始做方案，这就成了整个初始流程的一部分，对吧。而且这不只是 PM、或者非技术 PM 在做，工程师也这么做，设计师也这么做，因为我们全都是 builder。它彻底改变了你决定去做什么这件事。这就是在头和尾两端防止 slop 的两种方式。我还想

[1:00:00] Andre

highlight something really important here, which is um one of the things that decelerates people, teams, companies the most is collaboration. And this sounds contrarian which is like the fact that you have people having to collaborate it's what slows everything down. Now if you look at the development process in three stages ideation or discovery stage one execution stage two and delivery or enablement stage three collaboration should be happening in the beginning and in the end meaning you get people together deciding working on problem etc. And in the end you get people actually having the product in their hands and helping push it to the market, push it to commercial. But in reality what's happening is collaboration is happening on the execution right it's happening on dependencies it's happening on I do this you do that etc and it slows everything down and then in the beginning and the end there's no collaboration only PMs are in the decision only like engineers are delivering and then it's completely flipped up and when you start changing this you see acceleration deeply because then people work a lot on collabor they collaborate a lot on decision-m and then every single person people teams of one can execute by themselves and then they come back in the end and collaborate on like did this make sense? Can we merge this? Is this working with the product? And we together deliver the product to the user. I think this completely changes the uh completely flips. But if this happens, we reduce a lot of slop and we accelerate teams a lot. You caught my eye a couple months ago when you made this LinkedIn post about 90% of European PMs being non-technical. talk to me a little bit about the differences between PMs in Europe and the United States and

强调一个非常重要的点，就是——最拖累个人、团队、公司的东西之一，其实是协作。这听起来有点反直觉，但事实就是：大家不得不一起协作这件事，恰恰是让一切都慢下来的原因。现在，如果你把开发过程分成三个阶段——构思或者说发现是第一阶段，执行是第二阶段，交付或者说赋能是第三阶段——那么协作应该发生在头和尾：开头你把人聚到一起，一起决策、一起琢磨问题等等；结尾你又让大家把产品真正拿在手里，一起推它上市、推到商业化。但现实里发生的是，协作全堆在执行阶段：堆在各种依赖关系上，堆在「我做这个、你做那个」上，结果把一切都拖慢了。然后在开头和结尾反而没有协作——只有 PM 在做决策，只有工程师在交付。整个就完全反过来了。而当你开始把这个掰正，你会看到深层次的加速，因为这时候大家在决策上大量协作，然后每个人、甚至「一人团队」都能自己独立完成执行，最后大家再聚回来，在结尾协作：这说得通吗？我们能合并吗？这跟产品是契合的吗？然后我们一起把产品交付给用户。我觉得这彻底改变了、彻底反转了局面。一旦这么做，我们就能大大减少 slop，并大大给团队提速。几个月前你写过一篇 LinkedIn 帖子，让我特别注意到你，那篇说欧洲 90% 的 PM 都是非技术背景的。跟我聊聊欧洲和美国的 PM 之间有什么差别，以及

[1:01:41] Aakash

the implications for adopting AI tools.

这对采用 AI 工具意味着什么。

[1:01:43] Andre

Yeah, so uh even though I'm not 100% sure of the number of if it's 90% if it's 99 or if it's something in between, it's going to be a pretty pretty high number, you got to see the the product culture in Europe is very different. If you go to a lot of European companies, you're going to see a large number of POS of product owners. Something that you very rarely see in the US or even in the Asia market. Uh, and the product owner culture in in Europe, it focuses a lot on a bit of a glorified delivery manager without the actual technical skills. You're in a certain sense you're paper shuffling between someone defining strategy or roadmap or listening to customers and then the engineering and the design team on the other side and you're kind of in the middle. You're trying to do a great translation work. You're possibly trying to do a bit of a project management work within these teams, but unfortunately your hands are a bit tight by this product culture. And um yeah, I think this is one of the biggest problems we see in a lot of tech or software development in Europe is that the people who are talented, who are smart, and who should be able to actually drive a lot of decisions are not being able to drive them.

嗯，虽然我不能 100% 确定那个数字到底是 90%、还是 99%、还是介于两者之间的某个值，但它肯定是个相当相当高的数字。你得看到，欧洲的产品文化是非常不一样的。你去很多欧洲公司，会看到一大堆 PO、也就是 product owner，这在美国、甚至亚洲市场都是很少见的。而欧洲的这种 product owner 文化，很大程度上聚焦在一个被美化了的「交付经理」角色上，并不具备真正的技术能力。某种意义上你就是在做文件搬运工——夹在定义战略、路线图、倾听客户的那个人，和另一头的工程、设计团队之间，你卡在中间，努力做好翻译工作，可能还顺带干点项目管理的活，但很遗憾，你的手脚被这套产品文化捆得有点死。嗯，我觉得这是我们在欧洲很多科技或软件开发领域看到的最大问题之一：那些有才华、聪明、本应能真正驱动大量决策的人，却没能力去驱动那些决策。

[1:03:04] Aakash

So if the system is broken, what's a move for a PM in this environment? Go work for a multinational company or how do they get out of it? I think it has to do a lot with uh your personal energy because I mean I don't think you should move because that's your reality. I think if you have the energy you should try to fight to make it a better reality. Uh I truly believe like a lot of this is ingrained in in management right like maybe the managers the product leaders they haven't seen any other way so they're kind of trickling down that format but you just need to spend a bit of time in a US company for example or seeing how they build and you see it's it's very different right so if you have the energy you should definitely try to influence uh how product is built uh create that small pocket of of experimentation of doing things differently because it's not just good for you to actually gain the scope of product management and kind of leave behind the product owner. It's also good to the team and specifically because one thing I notice in a lot of companies that I work with is that when you have a product owner, [snorts] what the team is well unconsciously or consciously seeing is that that person alone owns the product. And that's actually not true because the entire team, the entire squad at least, should be owners of the product, but they're not because the title says that person is the owner of the product, which is a lie. And you at the same time, again, unconsciously or not, you feel like you're the owner of the product, which makes you an again a leader where you're not, or at least a manager where you're not. And again, the title is is breaking all of this. And you end up seeing in a lot of European organizations squads or teams or pods

那如果这个体系是坏的，身处这种环境里的 PM 该怎么破局？去一家跨国公司工作，还是说他们要怎么跳出来？

Andre：我觉得这跟你个人的能量关系很大，因为——我其实不觉得你该走人，因为这就是你的现实。我觉得如果你有那个能量，你应该去争取，把它变成一个更好的现实。嗯，我是真心相信，这里头很多东西是根植在管理层里的，对吧——可能那些管理者、那些产品负责人，他们自己也没见过别的做法，所以就把这套格式一层层往下传。但你只要花点时间，比如去一家美国公司待一待、或者看看他们是怎么做东西的，你就会发现差别非常大，对吧。所以如果你有那个能量，你绝对应该试着去影响产品是怎么被做出来的，去建一个小小的实验飞地，用不一样的方式做事。因为这不光对你自己有好处——能让你真正拓宽产品管理的职责范围、把 product owner 那一套甩在身后——它对团队也有好处。具体来说，我在合作过的很多公司里注意到一件事：当你有一个 product owner 时，[轻哼] 团队不管是无意识还是有意识地接收到的信号，就是「这个人独自拥有这个产品」。可这其实不对，因为整个团队、至少整个 squad，都应该是产品的 owner，但他们不是，因为头衔上写着那个人才是产品的 owner——这是个谎言。而你自己同时也会——同样不管有意无意——觉得自己是产品的 owner，这让你成了一个其实你并不是的领导者，或者至少是一个其实你并不是的管理者。又是这样，是头衔在把这一切搅坏。于是你最后会在很多欧洲组织里看到一些 squad、团队、或者 pod，

[1:04:46] Andre

which are completely disempowered and they don't like that. They they engineering teams are not participating in decision-m they're not part of the ideation. They're not part of the discovery. Often you don't see the design teams participating in the final delivery and actually bringing the product to the customer. And it feels like the teams are all siloed. And in my opinion, it actually starts with the fact that there is a product owner rather than a team feeling owner of the product.

彻底被剥夺了权力，而他们并不喜欢这样。他们的工程团队不参与决策，不是构思的一部分，不是发现过程的一部分。你常常也看不到设计团队参与最终交付、参与把产品真正带给客户。感觉上，团队全都被孤立成了一个个筒仓。而在我看来，这一切的根源恰恰就在于：存在着一个 product owner，而不是整个团队都感觉自己是产品的 owner。

[1:05:12] Aakash

So what is the answer here? How do how can PM start to build more themselves?

那答案是什么呢？PM 怎样才能开始更多地亲自去做东西？

[1:05:17] Andre

First of all, I think you need to understand that that is not the reality that you should be aiming for like there's other ways to do that's the first thing. I had a manager who once told me that to cook great food you have to have had great food. Uh so you need to understand that there is great food out there like there are other ways better ways of building product. Number two is get some coaching or get some mentorship from people who are maybe inside companies who are building this way and spend a bit of time if you can spend a bit of time asking them like how does it work? What am I supposed to do? How can you do this? like my own program and when you read content online, content that you post, you see how other people think and how they build and how they interact with their teams, how they set up their own design. So start there. Start by understanding what great food looks like so you can start cooking it internally. Number two is you want to start getting that report with your manager, getting that report with a product culture within the organization and start understanding where you see a gap to start changing the way you operate. And number three, you want to start getting allies with your team, meaning your engineering team, your design team, your AI team, and kind of explaining to them, look, we don't want you to be in the end of the line. We actually want you to participate in every single point of the development process, both from decision to ideiation to uh to the discovery to the last delivery and the go-to market and the enablement like we want the team to be an owner of the entire process. So start with this and even if you already have a road map, you have a track and your manager has expectations because you have milestones, you have a road map to

首先，我觉得你得明白，那不是你应该去追求的现实——还有别的做法，这是第一点。我有个经理曾经跟我说过：要想做出好菜，你得先吃过好菜。所以你得明白，外面是有好菜的——是存在别的、更好的做产品的方式的。第二点，去找些指导、找些 mentorship，找那些可能就在用这种方式做事的公司里的人，如果可以的话，花点时间去问他们：这是怎么运作的？我该做什么？你是怎么做到这个的？比如我自己的项目，还有当你读网上的内容、读你自己发的内容时，你会看到别人是怎么思考、怎么做东西、怎么跟团队互动、怎么搭起他们自己那套东西的。所以从这儿开始。先从搞清楚「好菜」是什么样子开始，这样你才能开始在内部把它做出来。第二点，你要开始跟你的经理建立那种汇报关系，跟组织里的产品文化建立联系，然后开始看清楚：你在哪儿看到了差距，可以从那儿入手去改变你的工作方式。第三点，你要开始在团队里争取盟友，也就是你的工程团队、设计团队、AI 团队，跟他们说：听着，我们不想让你们待在流程的末端，我们其实希望你们参与到开发过程的每一个节点——从决策、到构思、到发现、到最后的交付、到上市和赋能——我们想让团队成为整个过程的 owner。先从这个开始。而且哪怕你已经有了一份路线图、有了一条赛道、你的经理对你有期待，因为你背着里程碑、背着一份路线图——

[1:06:52] Andre

deliver, start trying to find some things in the road map that you can just try to manage differently within the team. You don't need to completely change the way you work from one day to the other. You can start small as an experiment and try to do things differently. Now that means that you need to also change a few of the rituals, right? If up to now you have a ritual of discovery or decision-m where maybe a significant part of your team is not in the room well start by getting them in the room otherwise they'll never participate right if you're doing all the decisions of scope and requirements and design decisions like that is already a problem like other people should participate or even have ownership of of that process so I think making these small changes is definitely step number one. Wow, so much ground we covered here today. What's the thing a PM should go do on Monday morning? What's the Monday morning roadmap to becoming a builder PM? Okay, so this is ambitious. Let's say it depends a lot on your team. But if I was getting started on this and I went through the levels and I'm getting to the level like three and I'm feeling comfortable, I would definitely go to my engineer uh and let's assume you have a GitHub account and I would ask look put me as a collaborator of a a lowrisk repository meaning even if you can create a repository for me like that is connected to the product uh a new repository a new feature and and just allow me to just do something and then go to your backlog. Pick a a a feature that has been on the backlog forever. Like literally sort it by oldest. Doesn't matter, right? Pick something uh something that you know that is in the bottom of the backlog and it's never going to get done. Every single PM had a bunch of these and then

去交付。从路线图里找一些事情，试着在团队内部换一种方式来管理。你不需要一夜之间彻底改变工作方式，可以从小处入手，当成一个实验，试着把事情换个做法。当然这也意味着你得改掉一些固有的仪式，对吧？如果到现在为止，你做需求探索或者拍板决策时，团队里有相当一部分人都不在场——那就先把他们拉进来。否则他们永远不会参与进来。如果范围、需求、设计这些决策全是你一个人在做，那本身就已经是个问题了，别人也应该参与进来，甚至应该对这个过程有所有权。所以我觉得，做这些小改变绝对是第一步。哇，我们今天聊了好多东西。一个 PM 周一早上应该去做的第一件事是什么？想成为 builder 型 PM，周一早上的行动清单是什么？好，这个目标挺有野心的，而且很大程度上取决于你的团队。但如果是我刚开始上手，我已经走过了那几个层级，到了大概第三级、感觉比较自在了，那我一定会去找我的工程师——假设你有一个 GitHub 账号——我会跟他说：把我加成一个低风险仓库的协作者。哪怕你为我专门建一个仓库都行，只要它跟产品相关，一个新仓库、一个新功能，让我能动手做点什么。然后去看你们的 backlog，挑一个在 backlog 里躺了很久的功能，干脆按最早创建排序，无所谓。挑一个你心里清楚、压在 backlog 最底下、永远不会被做的东西。每个 PM 手里都有一大堆这种东西，然后

[1:08:38] Andre

ask cloud code without requirements to build it, right? And you can even push a branch. You're not going to merge it to production like the engineers are not going to let you. But just try to see the magic happening. See the power you just gained by being able to do that as a PM right now. Imagine a reality where every single person in the product squad can do this for the actual backlog. Like this would be my Monday morning like I heard this and this is what I would start doing.

不给任何需求文档，直接让 Claude Code 把它做出来，对吧？你甚至可以推一个分支。你不会把它合并到生产环境——工程师们也不会让你这么干。但你就去亲眼看看那种神奇的事情发生，看看你作为一个 PM 现在拥有了多大的能力。想象一下这样一个现实：产品小队里的每一个人都能为真实的 backlog 做这件事。这就是我的周一早上——我听到这些之后，这就是我会立刻开始做的事。

[1:09:07] Aakash

Amazing. Andre, people love the episode. They want to learn more. They want to get in touch with you. Where should they go to find you online?

太棒了。Andre，大家很喜欢这一期。他们想了解更多，也想跟你取得联系。他们应该去哪里在网上找到你？

[1:09:13] Andre

I basically use LinkedIn. Feel free to connect. And if you want to know more, builderscamp.com is where we run our boot camps, where we train people to become builders. So that's basically it.

我基本上用 LinkedIn，欢迎加我。如果你想了解更多，可以去 builderscamp.com，那是我们办训练营的地方，我们在那里培训大家成为 builder。差不多就这些。

[1:09:24] Aakash

All right. And I think he even does corporate training. So if you want to get your boss to get Andre to come in, consider him for that as well. Andre, thank you so much for being here.

好的。我记得他还做企业内训。所以如果你想让你老板把 Andre 请进公司，也可以考虑找他做这个。Andre，非常感谢你来上节目。

[1:09:33] Andre

It was a pleasure, Akash. Really appreciate the time.

很荣幸，Aakash，真的很感谢你抽出时间。

[1:09:36] Aakash

See you guys in the next episode. I hope you enjoyed that episode. Couple things you can do to support the show. One, comment. Two, review. Those ratings and reviews really help other people understand the value and the production that we are putting into this. Right? This wasn't an easy episode to produce. We put in a ton of pre-work. We edited it for you. We brought in the best guests. If you don't mind sharing a rating and review, sharing the episode with others, making sure you are subscribed, that really helps the show do bigger and better productions. I'll see you in the next episode. Here is one of those that YouTube thinks would be a great fit for

我们下一期再见。希望你喜欢这一期。有几件事你可以做来支持这档节目：第一，评论；第二，留个评价。这些评分和评价能真正帮助别人理解我们投入到节目里的价值和制作水准，对吧？这一期可不好做，我们做了大量的前期准备，为你们精心剪辑，请来了最好的嘉宾。如果你不介意，给个评分和评价，把这期分享给别人，并确保你已经订阅了，这真的能帮助节目做出更大更好的内容。我们下一期见。下面这个视频是 YouTube 认为你会很感兴趣的内容之一