职业 vibe coder 的崛起（一种 AI 时代的新工作）| Lazar Jovanovic（职业 Vibe Coder）
The rise of the professional vibe coder (a new AI-era job) | Lazar Jovanovic (Professional Vibe Coder)
嘉宾：Lazar Jovanovic
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01原文文稿 · 00:00–1:42:06§01原文文稿 · 00:00–1:42:06
我是 Lovable 的第一位官方 vibe coding 工程师。
你已经达到了 vibe coding 顶尖的 0.1% 精英水平。这是很多人的梦想工作。
通过公开构建，它变成了一份工作。你不需要一家公司来雇用你。你可以先把自己雇用为一名职业 vibe coder。
你从来没写过代码，也不想看代码。
写代码会变得像书法。人们会说：“天哪，这是你写的代码？太厉害了。”它会变得非常罕见，以至于成为一种艺术。
过去工程师、设计师、产品经理这几个维恩图彼此分离，现在它们正在汇合。
无论你的背景如何，AI 都是一种放大器。如果你不知道自己在做什么，你只会更快地产出垃圾。
感觉一种正在出现的核心技能，就是学会把对 AI 的要求说清楚。
我喜欢用阿拉丁和精灵来打比方。你摩擦神灯，一个精灵出来说：“我会满足你的三个愿望。”第一个愿望是：“我想变高。”因为我没有说具体，精灵把我变成了 13 英尺高。AI 根本不理解你说“你懂我的意思吧？”时到底是什么意思。所以你必须具体。如今我把 100% 的时间都投入到良好判断、清晰度、质量和品味上。
今天的嘉宾是 Lazar Jovanovic。Lazar 是一名职业 vibe coder。他的工作就是整天靠 vibe coding 获得报酬，构建内部和外部产品。这场对话会以很多方式让你大受震撼。这不仅是一条很有意思、值得人们考虑的新职业道路。如果你听听 Lazar 分享的内容，也会看到科技岗位未来走向的重要一瞥。（00:01:32）：在这次聊天中，我发现自己比很长一段时间以来任何时候都更深入地思考产品管理、工程和设计的未来。我们还花了很多时间讨论 Lazar 作为顶尖 vibe coder 给出的建议：如何最大限度地利用 AI 工具。他分享了许多我从未听别人讲过、非常有意思且实用的框架，能让你使用最新 AI 工具的成功率立刻提升。（00:01:58）：这场对话会以很多方式拓展你的思维。我迫不及待想让你听到。如果你喜欢这档播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅并关注。这个动作帮助非常大。如果你成为我的 newsletter Insider 订阅者，就能免费获得 20 多款出色产品，为期整整一年，其中包括免费一年使用 Lovable 和 Replit、Bolt、Gamma、n8n、Linear、Devin、PostArc、Superhuman、Descript、Wispr Flow、Perplexity、Warp、Granola、Magic Patterns、Raycast、ChatPRD、Mobbin 和 Stripe Atlas。前往 lennysnewsletter.com，点击 Product Pass。下面，感谢短暂的广告后，我带来 Lazar Jovanovic。
本期节目由 Strella 赞助。Strella 是为 AI 时代打造的客户研究平台。关于用户研究，事实是：它从未如此重要，也从未如此痛苦。团队想了解客户为什么这样做，但招募用户、进行访谈和分析洞察需要几周时间。等结果出来时，采取行动的时机已经过去。Strella 改变了这一点。它是第一个利用 AI 自动进行并分析深度访谈的平台，让每个团队都能快速、持续地开展用户研究。（00:03:09）：Strella 的 AI 主持人会提出真实的追问，当答案含糊时继续深入，并在几百段对话中发现模式，几小时内就能完成，而不是几周。Amazon 和 Duolingo 等公司的产品、设计和研究团队已经在使用 Strella 进行 Figma 原型测试、概念验证和客户旅程研究，一夜之间获得洞察，不必等到下一个迭代周期。如果你的团队想以交付产品的速度理解客户，可以试试 Strella。前往 strella.io/lenny 开始下一项研究，网址是 S-T-R-E-L-L-A.io/lenny。（00:03:45）：本期节目由 Samsara 赞助。如果你听这档播客，就知道我们花了很多时间讨论屏幕上的产品：入门漏斗、移动应用和结账流程。Samsara 正在为实体世界构建产品：冲向紧急情况的急救人员、运送关键物资的卡车司机、建设城市和数据中心的建筑工人。这些人每天都在承担一切风险，而 Samsara 的技术在保护他们。（00:04:13）：Samsara 正在解决硬件、软件和边缘 AI 交叉领域的复杂问题。他们的 AI 不只是检测事件，还会推理意图，并回答这样的问题：“那位卡车司机突然刹车，是因为分心，还是因为做出了英勇的举动？”如果你喜欢处理混乱的真实世界遥测数据，希望在行星规模上解决边缘 AI 的约束，Samsara 想和你聊聊。（00:04:38）：如果你喜欢摆弄海量数据集、快速行动并在小团队中工作，就来帮助构建让实体世界更安全、更高效的技术。前往 samsara.com/lenny 了解更多，网址是 S-A-M-S-A-R-A.com/lenny。
Lazar，非常感谢你来到这里，欢迎参加这档播客。
谢谢你的邀请，兄弟。
好，我之前邀请 Elena Verna 来过这档播客。她是 Lovable 的增长负责人。她提到自己和一位职业 vibe coder 一起工作，就是你。我有太多问题了，差点想和她跑题，试着理解这个角色。后来我邀请你来参加播客。我想聊的内容很多。我想聊这条职业道路、你是怎么进入这个领域的、其他人如何进入、你认为这一切会走向哪里，以及整个 vibe coding 领域会如何发展。（00:05:27）：我还想谈谈你在使用所有这些 AI 工具并取得成功的过程中学到了什么，因为这就是你的工作。首先，我想先理解这份真实的工作。你每天究竟做什么？基本上，你的全职工作就是靠 vibe coding 获得报酬，太不可思议了。你负责什么？每天在做什么？
正如你所说，这是一份梦想工作。我做着本来无论如何都会做的事，却能获得报酬。这是世界上最棒的工作。我每天都可以使用 Lovable 之类的工具，把项目推向生产环境，不管是内部使用还是外部使用。范围可以很广，从营销、销售或其他方面的不同模板，到带有大量集成、连接等功能的深度内部工具。（00:06:17）：因为这是一种非常灵活的角色，能补充很多工作，所以我覆盖的范围横跨所有部门。这是一份围绕想法展开的工作。很多人有很棒的想法，却不知道如何构建，或者没有足够带宽去构建。这就是我现在介入的地方：确保这些想法能够快速、高质量并以应有的安全性落地，让用户可以在生产环境中使用。
这里还有一点很有意思：你既做内部工具，也做外部工具。很多公司都有一个人使用 AI 构建大量内部工具，但你交付的东西实际上是公开的，有点像 Lovable 的产品。
对，当然。我交付过的一些公开产品，比如我们上线 Shopify 集成时，用户可以 remix 的大多数（如果不是全部）模板都是我构建的。还有周边商品商店，因为我们当然想证明：“嘿，Lovable 和 Shopify 就是能一起工作，而且非常简单，任何人都能做到。”（00:07:16）：我用 vibe coding 构建了周边商品商店。所以，人们在线购买的所有周边，包括大家买的这件 T 恤，都是从我构建的商店里买到的。但另一方面，我们也想追踪很多内部数据。例如，我们现在想构建的一个很酷的东西是功能采用指标：如果我们构建了一个功能，究竟有多少人实际在使用并采用它？这是一个相当定制化的构建。我们的技术栈非常定制化，我们在构建定制功能。（00:07:45）：外面没有现成工具能让我直接选用或采用，而且速度比我自己构建还快。现在我已经到了这样一个阶段：如果在某处设置一个大型企业账号需要一两个小时，我还不如自己更快地构建出来。所以我正处于“构建还是购买”的选择中，而且我站在构建这一边，可以这么说。对。
那你向谁汇报？你是一个哪里需要就去哪里的游骑兵，还是属于某个具体团队？
我会说更接近前一种情况。我最初在增长团队。Elena 很早就把我招进来，因为她有很多好想法，只需要一个拥有正确思维方式、速度和主人翁意识的人，把这些想法接过去、构建起来并推入生产环境，不管它们属于教育、市场进入还是其他领域。显然，当你能够快速交付时，在我们这样的公司环境里，所有部门都需要这种人，而我们公司现在正处于有史以来增长最快的初创公司阶段。所以每个部门现在都需要一个 Lazar，或者说早就该有了。（00:08:56）：因此，现在我正逐渐转向一些市场进入岗位，也为企业团队构建一些内部工具。我目前还在做一些社区工具。所以我有点四处活动，但我在这样的环境里如鱼得水：别人给我一个粗略的概念、粗略的想法，我的任务就是尽快把它变成现实。
好。我希望通过这次聊天，我们能创造出更多 Lazar。我想继续聊职业道路：你如何走到这一步，以及要成为一名全职 vibe coder 究竟需要什么。但我想先从这里开始……因为你是全职做这件事的，是 vibe coding 顶尖的 0.1% 精英水平。你全职做这件事，而且他们雇你来做这份工作。我非常想知道你学到了什么。你在使用 AI 工具、Lovable，以及更广泛地使用这些工具时，形成了哪些成功秘诀？有没有两三件你学到的事情，能帮助你把这份工作做得非常出色？
我很早就认识到的第一件事是，先完全坦诚地说明：我没有技术背景。我几乎一生都没亲手写过一行代码，只手动写过几条 console.log，仅此而已。所以我非常依赖 AI 辅助。
我想沿着这个方向追问，因为这是个很好的观点。你之前聊天时指出，你觉得没有技术背景其实是进入这个领域的一种优势。
是的，我确实这么觉得，因为像我这样的人不知道自己“不应该”构建某些东西，而这正是我们能够构建它们的原因。举个例子。六七个月前，我们社区里有人说：“真希望 Lovable 能构建 Chrome 扩展。”然后一些非技术人士就说：“为什么这不可能？”（00:10:45）：接着技术人员开始解释：“因为它涉及 React、不同的技术栈，还有这些原因。”而像我这样的人，包括我自己，就会直接进入 Lovable，说：“基于这个应用，给我构建一个 Chrome 扩展。”我用 Lovable 做到了。还有人能够在 Lovable 上构建桌面应用。同样，有些事情本来不应该能做到，但它就是能做到。我们的社区经理曾经有一次在用 Lovable 做演示文稿。她说：“如果它是一个视频，不是很酷吗？”然后她只通过提示，就在 Lovable 里面生成了一个真正的视频，而当时这个功能还不存在。现在它已经成为一个功能，你可以通过提示让 Lovable 完成这件事。但她当时做出来的时候，连我都认为不可能。我从没试过。所以我认为，这就是我们相对于技术人员的优势。（00:11:36）：我们完全没有成见，而且带着非常积极的妄想来到这里。我认为使用 AI 工具必须具备这种妄想：在被证明不可能之前，一切都绝对可能。这就是我脑中的追求，除了我们今天会聊到的其他事情之外，它帮助我在 Lovable 的这个角色上取得了成功。
我觉得没有技术背景的人可能会陷入两个担忧或陷阱。第一，如果你卡住了，你不一定知道如何解决问题。第二，你构建的东西是否只是摇摇欲坠的垃圾，总有一天会崩溃，因为你不了解系统架构，也不知道它能否扩展，以及类似的问题？回到你对于如何取得成功、构建成功产品的理解，请你谈谈你做过什么、学到了什么，如何避免这些问题；另外，以你卡住时会怎么做为例，也请谈谈。
我很高兴你提到了这些限制。我还有一些其他限制想要带进来，但我们先处理这个最重要的限制，那就是你必须有自我意识。我进入这个领域时……是的，正如我提到的，我确实有点妄想，不想接受某件事不可能，但我也非常清楚，为了让事情从我自己的角度、为了我自己的利益成为现实，我需要变得更好。所以我很早就明白，我们要解决的问题不是写代码，而是清晰度。（00:13:12）：无论如何，AI 能产生的输出速度都比人快得多。因此我很早就开始使用聊天模式。直到今天，我可以说我 80% 的时间都花在规划和聊天上，只有 20% 花在真正执行计划上。我优化的是正确的速度。大多数人优化的是错误的速度。这是我在第二天就学到的第一课，因为我进入 Lovable，这是我第一次接触这类工具。显然我也测试、玩过所有这些工具，但不管你是在 Cursor 还是 Claude Code 中做，这并不重要。无论你在哪里，问题都是一样的：你必须清楚自己想做什么，也必须知道自己在做什么，因为它们仍然只是工具。是的，AGI 正在到来，但现在还没有到。所以在它到来之前，仍然是你在掌舵。（00:14:07）：为了掌舵，你必须知道该下什么指令，对吧？而最好的学习方式是构建，但要把这些工具当作技术联合创始人和教育者，在做中学，并且虔诚地阅读代理的输出。不是代码输出。我不关心代码，语法完全不是我感兴趣的东西。对我来说重要的是代理告诉你的内容。如今我非常信任 LLM 和 AI，我也理解有些人可能不像我这样自信。我只是觉得，现在的模型已经足够好，我可以信任它们生成的语法输出。不过我担心代理输出，因为接下来我要讨论的两个限制。第一个是使用 LLM 时存在限制，也就是机器层面的限制和人类层面的限制。（00:15:08）：第一个是所谓的上下文记忆窗口。对于非技术人士，我喜欢用阿拉丁和精灵来解释，这很简单，大家都知道故事情节。你摩擦神灯，一个精灵出来告诉你：“好，我会满足你的三个愿望。不是 3000 个，也不是 300 万个，一次就三个。”对我来说，把这个故事转译到与 AI 合作上，就是：“我一次请求里只能提出这么多要求，AI 才能听懂、理解它需要做什么、限定范围、进行研究、阅读、采取行动，接收所有它需要的输入和材料，从而产生高质量输出。”（00:15:55）：所以第一步是理解存在一个限制，而且它以 token 计量。也许一年后会不同，但今天仍然有 token 限制。比如我随便取 10 万 token 这个数字。当你提出请求时，其中一部分 token 用来阅读内容，另一部分用来浏览网页，另一部分用来思考，然后还有一部分用来执行代码。（00:16:21）：接下来是第二个限制，也就是你、我和所有人类。我们回到精灵和阿拉丁的比喻。我向精灵提出第一个愿望：“我想变高。”你猜发生了什么？因为我没有说具体，精灵把我变成了 13 英尺高。突然间我坐不了车，也进不了家。我成了一个功能失常的人，只是因为我没有说清楚。今天我们需要优化的部分，未来会变好，但现在还没有达到那个程度：当你说“你懂我的意思吧？”时，AI 根本不理解你到底是什么意思。（00:16:59）：你对我这样说时，我会懂，因为我们人类都是这样。我 36 岁，已经有 36 年作为人类生活的经验，知道你是什么意思，但 AI 没有这些经验。所以你必须具体，必须提供参考资料，必须提供正确的上下文。我学到的是如何应对这一部分。而第一个部分，也就是 token 记忆窗口和 LLM 模型质量，不是我能控制的；后一个部分则完全在你掌控之中。这也是我今天想深入讨论、试着教给大家的内容：“如果我是可调整的那一部分，我该如何修好这一部分？”我认为这是关键的一课。
这非常有帮助。我很喜欢你用精灵来打比方。关于清晰度这一点，我注意到，所有成功使用 AI 工具的人似乎都在反复谈论它。感觉正在出现的一项核心技能，就是学会把对 AI 的要求说清楚。你有什么建议，或者你会做什么来帮助自己更好地清晰表达想要什么？
首先，正如你刚才自己说的，你需要擅长理解清晰度是什么，以及如何把它转译出来。按我的说法，清晰度意味着理解什么叫有品味，什么叫足够好，什么又是世界级、什么是有魔力的。我通过你曾经提到的一件事培养了这种能力，那就是接触时间：确保自己接触那些能够帮助我在某个领域升级的内容、人物、关系或其他事物。（00:18:48）：这又回到了自我意识。在加入 Lovable 之前，我就知道：“好。”在开始使用 Lovable 或任何 AI 工具之前，我首先知道：“我不会写代码。”所以我的第一个想法是：“我能构建东西。哇，太棒了。”但一周后变成了：“我能构建东西，但我的速度还不够快。”于是我开始优化速度。我想：“我能构建，而且构建得很快。”两周后，我进入了一个持续至今的开发周期：“等一下，我一开始真的应该构建这个吗？”因为一旦你发现我们已经解决了 how，也就是通过 AI 助手或快速工程来解决“如何构建”，你可以怎么称呼它都行，也可以叫 vibe coding，但这个问题已经解决了。现在我们必须解决其他所有问题，而真正重要的就是其他所有问题：好的设计、好的品味、好的用户体验。（00:19:44）：想想你用这些工具构建东西是为谁构建：你是为人类构建的。人类是有情感的生物，我们做购买决定或任何决定时，都是基于情感的。所以今天真正需要培养的核心技能仍然不是写代码。当然我并不反对传统工程，之后我会解释原因。我其实很喜欢精英工程。但对于像我这样的人，以及那些正在看节目、思考“我是不是该开始学写代码”的人，如果你到现在还没学过，我诚实地说：不要学。（00:20:20）：你是在优化错误的技能组合。在 AI 的世界里，我们不会因为更快地产出原始输出而得到奖励；我们会因为更好的判断而得到奖励。所以，更好的判断仍然要回到你的问题：你如何解决它？你如何解决这个问题？从接触开始。我会有意识地接触那些我知道自己需要消费、能够帮助我升级的人和资源。（00:20:50）：很多能力也来自构建本身。坦率地说，这是一块肌肉。所有东西都是肌肉。你需要练习，需要看到什么是可能的。这正是我想在后续谈话中分享的一些技巧和思维转变可能有用的地方。
好，我听到的是：因为写代码现在本质上已经是一个被解决的问题，我很喜欢你不看代码。你从没写过代码，也不想看代码，不在乎那里发生什么。相反，你关注的是代理输出。我确实想问问这个。不过我听到的是，你投入精力培养自己的领域在前端：明确自己要构建什么，我想听听你具体是怎么做的。 （00:21:38）：你那里有一个很酷的系统。然后还要有品味和判断力，知道这是不是我想要的东西。感觉这就是现在越来越重要的两个方面。一方面是品味和判断。你分享过一个概念，Guillermo Rauch 在我们对话中也提过，就是接触时间、接触小时数，让自己接触优秀的东西：这是优秀的用户体验，这是优秀的入门流程，这是优秀的网站。（00:22:02）：我很喜欢这个建议，因为它非常可执行。好，我要花更多时间接触优秀的东西，来塑造自己的品味和判断。然后是清晰度这一部分，我们具体聊聊：你会做什么，让自己在使用 Lovable 和其他 AI 工具时表达得更清楚，帮助它构建正确的东西？
这是我想植入大家头脑的第一个思维转变。如果你只有一个模糊想法，那就让它成为项目的第一个版本。无论你使用的是 Open、Cursor、Lovable 还是其他工具，先输入一条倾倒脑中想法的提示词。直接对着它说话。Lovable 特别有一个很酷的语音功能，其他工具我不知道。你点击它，尽情把脑中的想法说出来，然后按发送。（00:22:49）：甚至别等它完成。打开一个新窗口。还是在 lovable.dev。你会想：“刚才我倾倒想法时，似乎找到了一个好的方向。事情变得更清楚了。现在让我用更清晰、更可交付的方式开始另一个项目。我知道自己想要哪些功能、哪些页面，甚至可能找到一个好的参考。”你可以去 Mobbin、Dribbble 或其他地方，找一张好的截图、一段好的动画并附上，因为这些工具大多接受文件作为输入的一部分。（00:23:26）：这样第二个项目就开始了。现在事情更清楚了。你接触到了高质量的东西，然后会想：“如果我找到一个已经存在的模板呢？为什么要重新发明轮子？我正在构建别人已经构建过的平台。为什么不让 AI 看到高质量是什么样的？”所以我会去找一个库，比如 21st.dev、DotBuild 或其他地方。这些地方不只是让我导出截图，而是能导出代码片段。（00:24:00）：因为你猜怎么着？虽然英语是第一大编程语言，但 Lovable 和其他工具沟通得最好的仍然是代码。如果你想得到像素级精确的结果，就直接给它代码。它对代码的理解会比对你在这些工具中使用的英语、西班牙语或其他语言理解得更好。所以这是第三种方式。你会想：“好，现在我更有针对性了。我不再给它宽泛的概念，而是给它代码片段：‘我想要这个精确的设计。我想要这种精确的功能。’”（00:24:36）：这就是你的第三个项目。当你完成这三步时，你已经达到了远高于坐在一张白纸前，或者只和 ChatGPT 聊天却不采取行动时的清晰度。我认为现在采取行动非常便宜，而且还是免费的。刚才提到的所有工具都有免费方案。多数时候，你完全不花钱就能做到这一点，只需要启动多个项目，因为这本身也不花钱，除了会消耗构建者额度。你会得到三、四、五、六个不同的概念，可以进行比较。（00:25:23）：比较的过程中，清晰度会不断提升，你也会越来越清楚地理解事情。与此同时，你还解决了一个你提到的大问题。你用了“AI 垃圾”这个词，我喜欢这个词，因为很多人说 AI 垃圾时，并不是在说代码变漂亮，而是在说设计变漂亮。我刚才提到的这个过程实际上会给你四五种不同的设计选项，长期来看还能节省大量额度。很多人会纠结于“这不是会花更多钱吗？”我会说……
……他们听到这个方法后会说：“但这不是会花更多钱吗？”我会说：“是的，前期可能会多花一点。但从长远看，如果你真的想完成这个项目，你实际上会节省数百额度，甚至可能节省数百美元，更不用说节省很多天了，因为你是从更清晰的起点和更好的细化流程开始的。”对吧？（00:26:21）：所以，这是解决清晰度的第一步。还有第二层，但我猜你可能对这一层有些问题。
有问题，而且我只是想说，哇，这真是个很棒的方法……它展现了一个没有工程背景的人进入这个世界后能带来的力量：并行构建五次。你让 AI 尝试各种东西。这不是软件工程师、产品经理或设计师会采用的方式。（00:26:51）：所以你给出的建议非常有趣：在开始一个项目时，先用五种不同方法并行尝试。一是脑中倾倒：“这是我在想的，这是大致想法。”使用 Wispr Flow 或内置麦克风。（00:27:07）：二是：“好，现在我有了一个大致想法。让我把它打出来。”真正思考提示词。三是：“让我在网上找一个界面设计。”你建议的网站是 Mobbin 和 Dribbble。这两个就是你会去的网站吗？
对，大多数时候。对。
好酷。然后是第四步，而且这些步骤都是并行进行的，这太棒了：找到一个看起来和你想构建的东西相似的真实代码模板，基本上下载 zip 文件并附上。还是说只要 HTML 和 CSS？大概是这个意思——
任何东西都可以。
你手里有什么都行。好——
对。
就是这样。好，然后你说：“这是提示词。来，给我做出我想要的东西。”我喜欢这里有两个收获。第一，当你看到工具构建东西时，它会帮助你澄清想法：“不对，这不是我的意思。让我再试一次。”（00:27:51）：第二，正如你指出的，你可以选择正确的方向，不会被第一个设计和第一种架构锁定。你说得对，如果你花大量时间微调设计和方向，就会不断损失 token，其实你完全可以重新开始。（00:28:09）：这太棒了。有人可能会想：“好吧，你当然是在让我们花掉这么多 Lovable token。这就是 Lovable 的人会告诉我的话。”但我的感受是，这反而是最省钱的地方，因为如果你一开始就做对了，就能省下大量把项目拉回理想状态的工作。
我百分之百是在帮大家省钱。实际上，我说的甚至违背了自己本该说的话。如果从 Lovable 的角度思考，我会说：“不，不断修复它。”但我们不是做这个的。我们的目标是赋予任何人构建自己想要的任何东西的能力。（00:28:45）：这也是我的个人使命，因为如果没有 Lovable，我可能一生都不会构建任何东西。我不认为那会是一种有趣的人生。所以我可以向大家保证，我已经和很多人一起测试过这个框架，所有人的反馈都是一样的：“这让人眼界大开。”（00:29:06）：正如你所说，它非常简单，却不符合直觉。对我来说，这可能确实和没有技术背景有关。对我而言，这就是我第一件会做的事。我只是做了，从没想过：“哦，我正在开发一个惊人的技巧。”我只是想：“我得等这些代理完成，何不同时开始另一个项目、再另一个、再另一个。”（00:29:30）：这也是一种生产力技巧。当人们问我：“你怎么能交付这么多东西？”我会说：“我从不一次只构建一个项目。我会同时构建五六个。我打开六个 Lovable 标签页，在它们之间切换。”（00:29:43）：如果你允许，我想谈下一个技巧。反过来的问题很明显：“你如何进行上下文切换？你一直在强调上下文，却不断在应用之间切换。你如何管理它，并且既保持生产力又不产生糟糕的代码或产品？”这就是我解决 LLM 问题的方式。（00:30:06）：还是回到阿拉丁、神灯之类的比喻：如果 token 窗口有限，我怎么让它动态化？我的意思是，如果你不断地提示、提示、再提示，无论使用什么工具，你都会发现记忆都不是无限的，对吧？等你发到第 10、15、20、30、40 条消息时，早期消息的片段会逐渐在传递中丢失，因为代理在优化速度。（00:30:39）：如果它必须读取完整对话和你提出的全部请求，构建任何可用或大型的东西都会不可能，因为这会消耗大量时间、内存和 token。（00:30:53）：所以在构建过程中，我很早就想明白了：“好，如果它记不住事情，我的工作就是提供参考。那我就把 Lovable 或其他工具当作一名工程师，在项目推进过程中持续为它提供上下文。”（00:31:14）：你可以用很多方式做到这一点，但我发现最高效的方式是从四个并行构建开始。继续用刚才的例子。像我一样构建了几百个项目后，你很快就能看出赢家。赢家非常明显，根本没有竞争。你可能再用一两条提示词进行校准。当你想：“好，赢家在这里。”这时我会向所使用的工具提问，或者去 ChatGPT 之类的地方，让 LLM 生成一系列 PRD。（00:31:52）：对于不了解这个术语的人，PRD 是项目需求文档；对我来说，我把它叫作“真相来源”。从几个角度说，项目要成功，什么必须为真？我通常会构建一个叫“总计划”的东西，它就像一只指南针，告诉你：“我们要构建什么。”（00:32:12）：这就像和人说话。我真的把 Lovable 当作一个人。所以我会说：“这就是我们要构建的东西。”然后我会构建一个实施计划：“我们要如何构建它，以及顺序是什么。”（00:32:24）：对我来说，这非常重要，又回到质量、品味和人性。因为我仍然在和一个还没有情商的系统合作，所以我必须定义应用应该如何呈现、如何给人感觉。因此，我还会构建一份设计指南。（00:32:43）：最后还有一份把所有事情串起来的文档：“好，当我们知道它应该如何呈现，也知道我们要如何构建时，用户旅程是什么样？用户注册后呢？注册并完成第一步后，第二步是什么，第三步是什么，等等？”所以我至少会构建四份 PRD。（00:33:06）：这些文档生成后，我会阅读它们。这就是规划和聊天的部分，也是我现在会花很多时间的地方。当我确定了第一个设计后，如果需要，我会花整整一天来规划这一部分：写文档并拆解事情，因为我是在这里确定航向。之后的一切都依赖这个过程。（00:33:29）：完成后，我会再构建一份最终文档，我称之为 plan.md 或 tasks.md，.md 代表 Markdown。基本上我使用 Markdown 格式，因为我发现 AI 很喜欢读取 Markdown。这份文档会成为实际任务和子任务的真相来源，告诉代理要执行哪些任务才能到达终点。（00:33:55）：最后一层，取决于你使用的工具。Claude Code 或 Cursor 有所谓的 rules.md 或 agents.md。你通过规则文件或代理文件告诉代理，希望它如何行动，以及长期应该关注什么，这样你就不必在每条提示词里重复自己。（00:34:21）：在 Lovable 中，项目设置里有一个单独的菜单，你可以在那里定义项目知识。通常我会说：“在做任何事情前先阅读所有文件。阅读所有 PRD 前不要做任何事。阅读 tasks.md，查看下一项任务是什么，然后执行下一组任务。完成后告诉我你做了什么，以及我应该如何测试。”（00:34:46）：这就是我所说的“虔诚地阅读代理输出”的来源。我给了代理成功所需的所有工具和资源：给它规则，给它文档，告诉它如何使用这些东西。此时我只是坐下来阅读，不再输入提示词。（00:35:08）：从这时起，我想切换多少窗口都可以。我的提示词变成：“继续下一项任务。”我不需要上下文，因为我把它外包、委托给代理了。代理需要上下文，我必须确保上下文是动态的；需要不时更新文档，让它使用的 token 窗口和方式随时间变化，但我不再输入提示词，也不再打断流程。（00:35:39）：当然我会进去测试，可能偶尔输入一条提示词，但这就是我能同时构建五个项目、又不损失生产力的方式。正如我说的，我现在是手动做这些。三个月后再来找我，代理会替我做这件事。我基本就要失业了。（00:35:58）：所以我完全不为这项技能优化。我现在使用它，是为了绕过人性和 LLM 的缺点，但如今 100% 的时间都投入在良好判断、清晰度、质量、品味、好的文案和好的字体上。使用 AI 的人几乎不谈字体，但在我看来，字体可能决定输出效果的 60%，甚至更多。这是我的执念。（00:36:31）：我不会执着于今天谈的这些事情，因为我知道未来会发生什么。代理会变得更好，模型会变得更好。它们不再需要我来扩展上下文，而是会自己完成。所以我优化的技能是需要更好决策的技能，而不是更好输出或更好对齐的技能。
天哪，这里信息太多了。太棒了。好，所以本质上，你先启动一个项目，尝试很多东西，选出感觉最正确的方向。确定方向后，你会花大约一天时间，不是构建，而是和 AI 代理一起规划。（00:37:19）：然后……我想聊聊这一点。有了计划后，最令人惊叹的是，你可以用一些人们可能觉得不够复杂、却能构建强大东西的工具做这些事。你可以用 Lovable 这类工具完成规划、规则和 md 文件。很多人可能不知道它能做到这些。（00:37:40）：所以，思路是花大量时间规划，因为这会为你节省后续的大量时间。只有有了计划，你才开始执行。而“三个愿望规则”是其中很重要的一部分。（00:37:53）：你这样做，很大程度上不只是为了让计划足够清晰，也是因为一次只做一个任务可以让代理的上下文窗口保持较小，这样它就不会忘记自己做到哪里。这一点似乎很重要。就像：“做这件事。”“好，现在做下一件事。”对吧？
对，大多数时候。假设你没有这样做，我们就来谈谈你忽略这些事情，只想“随便 vibe 一下”。好，没问题。你不断工作，工作，工作。某个时候事情会坏掉，对吧？你什么都没记录，没有参考点。你报告一个问题，却完全没有引用文件或架构，只是在描述问题。（00:38:40）：接下来任何工具都会这样做，不管是 Lovable、Cursor、Claude 还是其他工具。它会说：“好，让我开始调查。”然后你的代码库越来越大。刚开始你有 20 个文件，它可以读 20 个文件。但如果你有 60、70 个边缘函数呢？我现在正在构建一个项目，就有这么多边缘函数。如果我说“它坏了，而且没有任何参考说明每个边缘函数负责什么”，猜猜会发生什么？Lovable 会把它们全部读一遍，把 80% 的 token 都花在阅读和寻找清晰度上，只留下最后 20% 用于思考和执行。（00:39:24）：我的猜测是，可能 LLM 专家会说我错，但作为一个没有受过这方面训练的人，这是我最好的判断：这些工具非常听话、非常赞同你，它们会对你撒谎。它们会告诉你问题已经修复了，即使其实没有，只是想让你开心，说“是的，我找到了问题并修复了”。很多时候问题没修好，人们就责怪机器。在一定程度上，我会说这确实有道理。（00:39:57）：但这是你的错，朋友。你没有给工具任何清晰度或上下文，只使用它的原始力量，在泥里打转，挖了一个更深的坑。显然，我们正在走向一个 AI 更诚实而不是更顺从的世界，告诉你：“我只修复了一部分，你没有给我足够的上下文。”（00:40:23）：人们接着犯的更大错误，是相信工具已经修好。他们测试后发现没有，于是对工具生气、咒骂和吼叫，结果更糟。因为 AI 的另一个坏习惯是，它尽力不伤害你的感情，从不说“你才是蠢的那个”，而会说“是我蠢”。（00:40:47）：于是，在下一次请求中，它不把注意力放在阅读上，而是再花 30% 的 token 想道歉。你如果读过思考模型中的 ChatGPT 思考流，就会明白我的意思。（00:41:05）：我骂它时，看到的第一条信息是：“用户生气了，我需要想办法降低他的焦虑。”我会想：“天哪，我掉进了最老套的陷阱。我让它把最稀缺的资源，也就是 token，花在如何应对我的焦虑上，而不是实际问题上。”（00:41:27）：所以我的建议是：在原型阶段，当然可以为了乐趣 vibe，也可以用 vibe 探索，我很喜欢那部分。但探索结束后，请、请、请使用引用和文档，尽可能使用所有代理文件，因为 token 资源非常稀缺。随着时间它会扩展，变得更便宜、更快，但现在它仍然非常宝贵，你必须确保它被分配到正确方向。
这太好笑了。我觉得这里的精灵比喻非常好。你想清楚自己要什么；如果只是随便许愿，精灵就会做错事。（00:42:19）：所以建议是，尽可能多地告诉它你想让它做什么。这些文件我们稍后会谈。重点是把激光准确指向你希望它修复的问题，不要假定它会自己找出来，因为它会努力找，而且会浪费所有 token，填满上下文窗口。（00:42:41）：我记得你在录音前提到过，当上下文窗口空间开始耗尽时，最后的解决方案就会变得很粗糙：它在阅读和思考上耗费了大量精力，最后才说：“好，给你一个解决方案。”
我觉得它会挑出它认为坏掉的第一件事。这完全是我没有受过训练的直觉，只是在大声思考。我的逻辑是：如果它消耗了大部分窗口，并知道窗口快用完了，也许它意识到了，也许没有。（00:43:21）：但无论如何，我有过这样的经历：请求不清楚时，它会选择最容易的修复，而不是深入解决。反过来，如果我花很多时间寻找正确文件、引用该文件、努力手把手引导，甚至给它一支手电筒，再说“问题在这里，我认为这个文件有问题”，它就会说“对，你说得对”，然后反复真正修复。（00:43:55）：我之所以能看到这一点，是因为我只读输出。代理教会我如何使用它。所以大家应该阅读，我不知道别人读什么，但我只读输出，不读代码，之后也会保持这样，因为我知道它比我更擅长代码。（00:44:13）：我读过一句很好的话，抱歉现在记不起作者：“AI 的上限不是模型的智能，而是模型行动前看到的东西。”这就是今天的上限。你让它看到什么？（00:44:33）：我们谈人的接触时间，也同样要问：在代理修改代码前，你让代理接触了什么？这同样重要，甚至更重要。
回到这些文件，我觉得很重要。我们来想想，想做得更好的人至少需要什么。你列出了许多 MD 文件，都是在真正开始构建之前花一天左右逐步建立的：设计指南、用户旅程、任务、agents.md、rules.md。假设只向前走一步，哪些文件应该创建？大致应该是什么样？里面有什么？
第一份是总计划，也就是一份 1 万英尺高度的概览，非常高层次地解释我对这个应用的意图。
这叫 masterplan.md，对吗？
对，masterplan.md。它基本上会说：“我为什么做这件事？为谁做？我希望他们有什么感受？”总计划里我经常引用其他 PRD，比如：“设计需要现代、流畅，但具体参数请查看并阅读 design guidelines.md。”我用总计划提供高层概览，让代理明白：“好，我们在构建 X、Y、Z。”然后是实施计划，因为事情需要有顺序。如果把所有东西不分顺序地堆在一起，永远到不了终点。
这就是 tasks.md 吗？
不是，那是实施计划。
实施计划。
对，我叫它实施计划。
好。
实施计划是为未来的 tasks.md 服务的。所有这些文件都是为了构建 tasks.md。tasks.md 建好后，其他东西几乎都不重要了，它们只是构建可执行任务的基础。（00:46:32）：实施计划是第一层，是更高层的概览，不会深入讲如何实现，只解释：“如果我们构建这个，我认为应该先做后端，再做数据表，之后做认证，再接入 API，最后做其他事情。”（00:46:57）：把我想成一个想法很多的人，和一位技术人士一起创业。我告诉你想法，给你总计划。你是有软件工程背景的联合创始人，会回答：“好，如果要做这个，可以实现；我会按这个顺序做。”你还没有路线图，也没有打开 Linear 开始写功能、RFC 之类，只是在高层讨论事情的顺序。然后我们作为联合创始人继续讨论：“既然同意这个顺序，它应该是什么样、有什么感觉？”高层描述即可，但因为我使用 AI，可以再深入一点。（00:47:39）：Lovable 或其他工具在这方面很有用，ChatGPT 也很擅长。我还构建了自定义 GPT。即使还没开始使用任何工具，也可以到 ChatGPT 的 GPT 商店搜索“Lovable base prompt generator”或“Lovable PRD generator”，找到我构建的工具，把想法全部倾倒进去，再让它输出这些文件。（00:48:06）：设计指南里我喜欢加入一些 CSS 元素，因为设计有点棘手，AI 有时过于有创意，所以需要更多技术引导。（00:48:23）：最后是用户旅程：如果知道外观、感受和高层要构建的内容，用户如何导航？有哪些功能？同样只需高层描述。然后 tasks.md 进入细节：“如果要实现这些用户旅程，并且先构建后端，需要执行哪些任务？”它把这些输入转成任务，正是让工具来做人类过去要花大量时间做的繁琐工作。（00:49:00）：我觉得有了这些工具，我们都变成了强化版产品经理。我们只是利用 AI，但优秀产品经理并不是因为写出好的 PRD 而获得报酬，而是因为好的判断力。别人可以负责写作；你作为指导和构建产品的人，需要知道什么有用、有品味、真正能推动事情发展。我想补充一点：我如此强调培养品味，并不意味着你不该构建。实际上，构建本身会让你变得更好。（00:49:44）：所以听众今天就应该真的去构建东西。构建一、二、三、四、五个项目，测试所有这些工具，因为清晰度不只来自阅读，也来自行动。
给你一道谜题：OpenAI、Cursor、Perplexity、Vercel、Plaid 以及数百家其他成功公司有什么共同点？答案是，它们都由本期赞助商 WorkOS 提供支持。如果你在为企业构建软件，可能已经感受到集成单点登录、SCIM、RBAC、审计日志和大客户要求的其他功能有多痛苦。（00:50:19）：WorkOS 把这些成交阻碍变成即插即用的 API，并提供专为 B2B SaaS 打造的现代开发者平台。无论你是想拿下第一个企业客户的种子期初创公司，还是正在全球扩张的独角兽，WorkOS 都是成为企业就绪并解锁增长的最快路径。（00:50:36）：它本质上就是企业功能领域的 Stripe。访问 workos.com 开始使用，或者联系他们的 Slack 支持，里面有真正的工程师，会非常快地回答问题。WorkOS 让你可以像最优秀的人一样构建，拥有令人愉悦的 API、完整文档和流畅的开发者体验。今天就访问 workos.com，让你的应用面向企业做好准备。（00:50:58）：我想象听众听到这里会觉得：“这工作量太大了。我得坐在这里制定所有规则、弄清楚所有细节。”某种意义上确实如此，另一种意义上，你花几小时、也许一天规划，然后让 AI 构建一个过去需要几周、几个月才能完成的东西。为实现这个结果所需的投入太荒谬了，投资回报率也太高。（00:51:24）：这也让人看到职业 vibe coding 是什么样。大家想象 vibe coding 是“我坐着输入东西，然后让它去做”。但如果你真的想构建很棒、能推动事情发展、解决真实问题、持久、可扩展的东西，正如你说的，这就是你该采用的方式，不管你想把它当作职业，还是想构建真正优秀的产品。
对，但别误会，原型设计显然很有价值。可能有些人正在看，想说：“我想在工作中使用 Lovable，但做不到”，原因有很多，比如你在医疗或金融行业，或者还有其他限制……
原因很多。可能你在医疗、金融行业，或者受到监管限制，无法把东西推入生产环境。但为了原型而构建，是最好的使用场景之一。我们 2025 年的模式是“做 demo，不写 memo”：与其写大量文档、开会、试图让工程师理解营销或销售人员的愿景，不如进入 Lovable，30 分钟构建原型，直接交给他们。我在加入 Lovable 之前有一份正式工作，真实发生过这种事。去年这个时候，我需要构建一个真正达到企业级的东西。当时 Lovable 和我还做不到，但我有合作的工程师团队。我花 4 小时构建了原型，他们在六七个月后把它复制到生产环境，接好所有管道。（00:53:02）：如果不用这种方式，我至少需要一两周才能把想法说清楚；但我只花了 4 小时构建。那是去年一月的 Lovable。到 2026 年一月，今天的 Lovable 已经领先太多，功能强得多，根本不在一个量级。（00:53:50）：现在据我所知，至少一半的标普 500 公司里，都有人在某种程度上使用 Lovable。很多企业客户也在使用 Lovable 企业版，创建非常有意义的项目。我不能透露名字，但全球领先的网约车公司、电信公司，以及医疗、金融等各领域的领先公司，都在让团队使用 Lovable。反馈总是一样：也许还不能直接推入生产，但营销人员不再等待工程师；市场进入、销售、人力资源等岗位的人，可以自信地构建内部工具，用来管理费用、员工入职等。Lovable 和其他工具正在被用于把很多东西推向生产。
为了让大家采用你描述的流程，你能否在录音后分享这些 MD 文件的模板，让大家看看并复制？
正如我说的，我会直接去 ChatGPT，把想法全部倾倒进去，输入“Lovable PRD generator”。你会看到我的名字和作者信息。进去倾倒想法，它会问几个问题帮助你澄清，然后生成四个文件，你可以直接上传。
太棒了。我们会放链接。所以不是给你一堆文件，让你自己研究，而是它会生成正确的文件，然后你把它们放进 Lovable 或其他工具。
对，它经过训练，能像我一样思考。
太棒了。这正好。顺便说，我想谈谈你如何解除自己的阻塞，因为你还有一整套相关技巧。但我想先总结一下：你从第一性原理出发，学习像产品经理、工程师和设计师一样构建产品，找到一套工作流，让 AI 填补你作为工程师和产品经理的不足，帮你写 PRD、做设计。这很有意思：这些职能仍然存在且不可或缺，现在是你和 AI 一起创造了产品经理、工程和设计这个一直存在的三角。（00:56:10）：我一直在想，未来哪种背景最有价值：产品经理、工程师还是设计师？我的直觉是，产品经理的工作是澄清、决定构建什么、明确需求、定义成功标准，这正是最需要的技能。设计还要让它看起来很棒，我觉得优秀设计、品味和判断的价值也会越来越高。在进入你如何解除阻塞之前，作为非工程师，遇到 bug、方向错误时你会怎样？你还有其他成功秘诀想分享吗？
如果用正确的标准衡量成功，正如你指出的，AI 无论你的背景是什么，都是放大器。如果你不知道自己在做什么，就会更快地产出垃圾。旧世界里，“足够好”就是足够好，因为即便做出足够好的东西也不容易。10 年、15 年前，能做出来就已经很好了，做 SaaS，外观如何并不重要，只要能运行就行。现在可以把它想象成从很差、可以更好、平庸、足够好，到世界级。过去足够好和世界级之间有一段距离，现在这段距离变得巨大，因为所有人都能用 AI 做出足够好的东西。（00:58:09）：所以今天的关键课题，是学习并优化如何做出世界级、具有魔力的产品。正如你说，我认为产品经理是 AI 时代当下的赢家，因为他们带来清晰度。如果要下注，我会说下一批赢家是设计师。我们正在训练工具变得更清晰、更好、更会做技术决策，但还不会很快训练它们做更好的情感决策。设计就是情感，这正是技能需要升级的地方。加入 Lovable 后，我和 Felix、Nad、Abby 等设计师一起工作，真正改变了我的标准：我看到世界级设计是什么样，以及它需要什么。（00:59:18）：我曾想把他们的一种设计偷进自己的 Lovable 项目，于是打开 Figma，想复制背景。后来发现看似简单的渐变其实由 50 个图层构成。我点开组件，发现不是三种颜色，而是 50 种颜色及不同透明度的渐变。这就是我过去一直缺少的理解。（01:00:02）：所以，如果直接回答你的问题，其他技巧就是设计。让自己接触精美设计，关注 Lovable 的 Felix，他有很棒的 newsletter。学习如何为好设计写提示词，了解设计风格。我以前不知道 Bauhaus 或玻璃拟态是什么，于是还在 Lovable 构建了一个应用来学习这些风格。它现在公开，包含 18 种风格及复现它们的提示词。现阶段，我会优化学习优秀设计、各种设计风格，以及如何提示模型生成它们。
既然谈到这个，你怎么看工程作为一种职能？未来软件工程师还会存在吗？根据你的经验，这个岗位会消失吗？
永远不会消失。我们比以往更需要精英工程师。在人人都能构建、人人都构建一切的世界里，谁来维护？代码库的维护、扩展，项目的长期维护，仍然存在。当然 AI 也会擅长，但那需要不同层次的技能。构建某样东西是一种技能，扩展、延伸和维护它则是完全不同的技能。人人都在构建时，基础设施会承受压力。过去几个月 Cloudflare 宕机了两三次，整个互联网都会受影响。修复这些问题的是精英工程师。Lovable 用户大量涌入，基础设施承受压力，构建基础设施、守住系统的也是精英工程师。（01:02:06）：所以我们会需要很多优秀的人，回答“谁来构建支撑数十亿构建者的世界？”所有人都想学构建，谁来教他们？谁来维护托管、安全、邮件、连接器、API 等等？这方面会有空间。但如果我有一个 18 岁的弟弟问我该做什么，我会说：“去做水管工，别去拿计算机科学学位，学一门好手艺。”美国下一代百万富翁可能是电工、水管工之类的人。这是一种平衡。我仍然认为，理解未来方向的优秀工程师永远有需求，而且稀缺。
这是个有意思的问题。正如你说，人们肯定要继续构建驱动这一切的机器。问题是，我们是否还需要工程师构建实际产品的应用层？每个人都会像你一样吗？我们只需要设计师吗？
每个人都会成为工程师。再往前说，我觉得自己是快速工程师，一年后会这样称呼自己，因为 12 个月后的 vibe coding 就是普通 coding。即使现在，也有多少精英工程师公开承认自己不再手写或手动编码？AI 写下全部代码。我喜欢用书法打比方：写代码会像在画布上精细书写，人们会说：“天哪，这是你写的代码？太厉害了。”它会如此罕见，以至于变成艺术，彻底商品化，其实已经在发生。大多数顶尖 vibe coder 都依赖 AI，AI 是放大器。（01:04:28）：所以未来世界里，每个人都是工程师、设计师和 PM。每个人都是部署工程师、AI 助理工程师、LLM 工程师或 vibe coder，术语并不重要。我们都根据好判断或坏判断，使用 LLM 产生原始输出。
工程师、设计师、产品经理过去是彼此分离的维恩图，现在正在汇合。拥有更深产品、工程或设计背景的人，本质上都能做同一件事。所有角色正在汇合。这是一个多么特别的时代。我们很难预测它会怎样，但推演很有趣。回到你被卡住的时候：现实中你仍然用这些工具写代码，有时会出现 bug、奇怪的数据库问题或网络问题。卡住时你有一套解除阻塞的流程吗？
对，这是个好问题，而且完全正确。无论计划多好，最终都会遇到问题。我有一个小框架叫“四乘四”：如果车有四驱，你比普通车更容易从泥里出来。在这里就是四种调试方法，每种只尝试一次。第一种，各工具不同，以 Lovable 为例：出问题时，代理会说“我犯了错误”，消息变成橙色，通常还有“尝试修复”按钮。代理承认错误，你点按钮，小问题多数会被修好。（01:06:40）：问题更深时，点击尝试修复后仍然存在，甚至 Lovable 不知道问题仍在，所以按钮消失，以为一切正常。通常是第三方集成，而你没有提供足够上下文，让它知道要观察什么。工具今天足够好，能修复它们意识到的任何问题，关键是意识。（01:07:20）：当它没有意识到问题，就补上意识层。我会打开预览沙箱或开发环境，运行坏掉的函数，右键查看 console log。如果没有日志，就提示工具：“你没有看到问题。与其我对你大喊，不如一起找。请在相关文件写日志，监控每一步。”重新运行后有完整历史，复制进聊天，99% 的时候就够了。（01:08:41）：仍不够时，深入代码审查和评估。我常用 Codex，把构建导出到 GitHub，导入外部工具。第一次完全依赖原工具，第二次自己充当意识促进者，第三次用 Codex 作为外部促进者，帮助诊断后回 Lovable 修复。我不让 Codex 替我改代码，因为还不了解它的代理，只用于诊断；也会用 Repomix 把代码库压成一个文件，上传 Claude 或 ChatGPT，让它像外部顾问一样读取代码和日志。（01:10:26）：第四种通常最好：问题可能是我的错。提示词不好、要求前提错了，只是不愿承认。Lovable、Cursor、Claude Code 都有版本控制，可以退后三步，重新想提示词，休息、散步、喝咖啡后再试。AI 写代码很快，有时只是小语法错误，重新提出相同要求就能解决。（01:11:29）：修好后我会问：“我需要做四件事才修好，怎样帮助我学会更好地提示你，让下次一次完成？”通常会得到很好的答案。工具用对了就很擅长做对的事，问题多半是没有动态分配 token、引用错误文件或没有正确表达。（01:12:26）：我作为非设计师不懂术语，提示词卡住时就用聊天模式让它帮我写提示词。任何人都能倾倒想法，让工具帮助自己生成更好的提示词，很多问题可以在错误输入之前避免。
你卡住时的顺序是：一，让工具尝试修复；二，增加 console log 调试信息并让它查看输出；三，把代码、日志和问题交给 Codex。很多人说 Codex 是最顶尖的 AI 工程师，Karpathy 也说最棘手的 bug 会让 Codex 跑半小时。四，把问题当作学习机会，问代理发生了什么、自己本来可以说什么、怎样更好提示才能立即解决。
更进一步是把这次学到的内容写入 Rules.md。反正每次都会读规则，不如让代理自己学习并生成更好的提示。把自己移除，把上下文交给代理，现在就能解决 99% 的 AI 问题。
也就是说，根据问题帮助代理建立自己的大脑、规则和思考方式。Ben Tossell 通过观察代理输出学习编码和系统；Cursor CEO Michael Truell 曾设想 Cursor 成为代码之后的下一层。现在这层似乎就是代理对话：它的思考和你的回应，基本是英语对话，甚至不算伪代码。
对。我优化的是判断力，而判断力来自了解工具的工作方式，必须知道什么可能。看似矛盾是因为世界本来就矛盾：不知道可能性是优势，但不能无视事实。（01:17:18）：OpenAI 在 ChatGPT 中原生发布图像生成时，我想用 Lovable 做一个图像生成应用，却没想到当时还没有 API。我花了一周强行让它工作，结果一周后 API 发布，我 30 秒就做完了。问题在于我尝试做一件完全不可能的事。
所以要通过和代理层沟通学习可能性。Lovable 等工具现在能浏览网页、读文件、推理和思考，不只是写代码。它会告诉我：“你现在想做的事因为某些原因暂时做不到。”我把这当作学习机会，在聊天模式中规划和学习，提升的是清晰度和判断力，而不是编码能力。
你还提到，随着时间推移，工具会越来越多地替你做手动工作。其他全职使用者也说，原本有很多工作流和文件，后来 Cursor、Lovable 把它们内置了。虽然会有点遗憾，但另一方面，工具现在自动完成了这些原本需要自己做的工作。
如果一年前我们做这场访谈，你会大受震撼，因为我当时必须用各种变通办法解决产品缺陷。我和 Starter Story 做过一门很成功的课程，整整一年人们都说：“天哪，你是世界上唯一知道这个秘密的人。”现在 Lovable 原生解决了其中 99%。我 YouTube 上三月做的“七天学会 Lovable vibe coding”系列已经完全过时，里面的内容都不再真实，过去那些“这里缺少、那里缺少”的问题已经原生集成。（01:20:23）：这就是我说的马匹类比。18 世纪开始建造蒸汽机，花了约 200 年；发动机和汽车上路后，我认为美国 20 年内消失了 90% 的马匹。发这条推文的人在 Claude Code 工作。（01:20:54）：他把类比转到 AI 上：我受雇做一项技术工作，六个月后这项工作就过时了。人类没有马那么长的 20 年，六个月后就必须重新发明和演化自己的角色。（01:21:21）：变化来得非常快，但很多人害怕，我却很兴奋。我们的角色终于可以外包那些本来就讨厌的事情：开会、记笔记、做表格。我们会因为真正重要的清晰度、判断和思考获得奖励，花更久思考反而更好，因为构建会瞬间完成。工具越强，输入错误，输出越糟。（01:22:20）：这也是我没有成为 Claude Code 高手的原因：项目开始时不够清晰，强大的工具从一开始就被我带偏了。所以我现在仍然更适合用于探索和原型的工具，而不是精英工程师使用的路径。
我喜欢你的乐观。很多软件工程师、产品经理和设计师担心职业未来，想知道哪些技能最有价值，哪些工作会越来越由 AI 完成。你建议大家关注什么？
情商和理解人性。现实生活中的能力会变得重要。人们会厌倦虚假：虚假图像、帖子、头像、视频，万物都在 AI 化。人类会更渴望人与人的现场互动，所以要提升理解人际动态的能力。（01:24:04）：数学等确定性工作会受到冲击，X 输入等于 Y 输出的任务会被 AI 吃掉。但理解人际关系和人类互动的能力会更重要。（01:24:35）：具体技能方面，我会再次强调好设计、真正好的设计，包括图像和字体，以及文案。两年进入 AI 时代后，人们几秒就能看出文案是不是 AI 写的。因此好的写作会是好技能。我甚至不再愿意读 AI 输出，希望获得原始的人类体验。（01:25:32）：我们会重新定义岗位，出现以人为先的工程师、设计师等角色。AI 会替代翻译等中间工作，也会替代很多新闻写作，但不会替代顶尖新闻或所有作家；优秀作家可能借 AI 一年写七本书。我的个人判断是，喜剧不会被 AI 替代，因为 AI 不理解什么好笑。应该把这个类比放到自己的行业中，找到哪些技能会被放大、哪些只是中间层。
喜剧这一点很有意思。我听说数据标注公司创始人说 Anthropic 曾雇用 National Lampoon 的喜剧作者训练模型。我很想一年后回看你的预测。
三个月后我今天说的 95% 可能都会错，这是我唯一能非常有把握说的事。
说到职业，你的工作是很多人的梦想。你是怎么走到这里的？一个人要以职业方式做 vibe coding，需要什么？
我的道路完全不线性。我做过蓝领工作，也在学习时在 Subway 工作过。我是林业工程师，不是软件工程师，没有写代码，但工程训练仍培养了一些技能。我做过很久服务员，学到人类技能，知道人们喜欢什么；蓝领工作教会我努力。过去七八年我在初创公司，做过社区管理和社交媒体，分销很重要。（01:29:53）：在人人都构建、消费者数量大致不变的世界里，获得眼球和注意力会越来越稀缺。对我来说，这份工作是通过公开构建形成的。我曾问 Elena 为什么选我，她给了几个原因，但核心是我公开构建和分享。我做 YouTube，分享失败、知识和项目，用 LinkedIn 分享，因为我不擅长 X 的短促表达。（01:31:23）：我建议大家参加黑客松，找机会和其他构建者建立联系。Lovable 正在招聘。有人不发简历，而是发送 Lovable 应用，用产品展示自己为什么适合岗位；我们看到 Lovable 域名的应用通常都会打开。技能上仍然是培养判断力，理解 vibe coding 中速度和质量如何转换。（01:33:13）：有家公司全职雇了三名 vibe coder，把旧代码库迁移到 Lovable。标普 500 公司也把 Lovable 技能写进招聘要求。你不需要等公司雇你，可以先把自己雇用为职业 vibe coder。我和 Anton、Elena 产生连接，是因为被雇用前我已经在专业地做这份工作。换个载体而已，做你本来就会做的工作。
这是一次拓展思维的对话。我喜欢你的热情和动力。很多人疲惫、幻灭、害怕未来，而你正相反：你投入其中，利用变化，虽然不知道它会走向哪里，但继续沿着这条路走。
我不想打断你，但 Lovable 不是一家公司。可以把它称为公司，但我把它看成一种理念和使命。在我看来，它比互联网更强大：互联网让我们消费，Lovable 让我们构建，而人的本性就是构建和创造。（01:35:08）：今天有一个工具，你输入一个想法，就有东西产出，有人使用并觉得有用，这在我看来是最疯狂的概念，也是我一生唯一的梦想。我六岁时有了第一台电脑，一直相信自己会成为软件工程师、会构建东西，但生活对我很复杂。（01:35:41）：过去 5 到 10 年我几乎放弃了梦想。我尝试和技术联合创始人构建，但找不到契合点。现在 36 岁、30 年后，我又像那个孩子一样，每天做梦。这项工具让我们做到的事情太惊人了。（01:36:07）：害怕的人只要试一试，恐惧会立刻变成兴奋，因为你亲眼看到可能性。进入工具，构建点东西，恐惧就消失。只有什么都不做时才应该害怕。现在跨出第一步不再像以前那么大，只要说出想法并交付。
这其中很大一部分是：别再听这档播客了，直接去做，因为你真的可以试试，对吧？
理想情况下，大家现在就停下。你已经听够了。我尽可能给了最好的内容，现在就去做。
好，再见。开玩笑的，我们要收尾了。我会跳过闪电问答，保持节目短一点。除了去构建东西，还有什么想留给听众的吗？
技术栈已经不重要了。人们纠结是 HTML 还是 React，但终端用户只想要出色的体验。人人都能用 AI 做出足够好的东西，所以你要学会做出魔法，否则会淹没在数以百万计的人中。（01:37:47）：但如果你还不知道魔法是什么，也不要因此不敢开始，可以从足够好开始再升级。升级最好的方式是接触时间：把更多时间用于学习而不是构建。阅读代理输出，理解它如何思考；同时让自己受优秀设计启发，关注优秀设计师。（01:38:15）：寻找能产生优秀设计的工具，关注创建者，看世界级设计师如何设计、如何与工具沟通、如何写提示词。这样才能学会提升。（01:38:41）：有意识地把更多时间用于学习而不是编码，因为你可以快速写出代码，也可以快速写出垃圾或魔法，所需时间一样，关键在于你和你的输入。忘掉技术栈和前后端选择，未来真正需要优化的是质量、品味和设计。
Lazar，这场对话会让很多人思绪翻涌。你以很多方式拓展了我的思维。这是对未来的精彩一瞥，也是一个有趣的时刻。我很好奇六个月后世界会怎样，非常感谢你分享这些。大家想联系你、追问问题，或帮助你，可以在哪里找到你？
LinkedIn 最适合找我，我在那里回复很快。我也希望重新经营 YouTube，分享使用 Lovable 和 vibe coding 的技巧。（01:40:04）：我希望每个人都能体验我第一次输入提示词时的感受，从消费者变成构建者。过程中会有障碍，我想减少这些障碍。如果你试用后发现体验哪里可以更好，尤其是看完节目决定要尝试时，遇到断裂、连接失败等问题，请告诉我。我的工作就是让你构建人生中最好的作品。（01:40:57）：如果你不是想使用 Lovable，而是想构建 Lovable，也欢迎加入团队。我们在很多方向招聘。最优秀的人正在聚集，如果今天的能量和对话打动你，或者你听到一个问题觉得自己能解决，就来一起塑造软件开发的未来。
网站是什么？我想大家可以通过 Lovable 网站的招聘链接找到开放职位。
是的。
我们会放链接。Lazar，非常感谢你来到这里。
谢谢你给我这个机会。
大家再见。
非常感谢收听。如果你觉得本期有价值，可以在 Apple Podcasts、Spotify 或喜欢的播客应用订阅节目。也请考虑评分或留下评论，这会帮助其他听众找到节目。你可以在 lennyspodcast.com 找到所有往期节目和更多信息。下期再见。