Lovable公司聘请无技术背景员工，通过“Vibe Coding”与AI沟通，实现产品快速迭代。清晰表达与品味成为关键。
原文标题：技术框架不重要，大厂简历不值钱？小哥不会写代码却进了Lovable，80% 靠聊天也能上生产
原文作者：AI前线
冷月清谈：
怜星夜思：
2、文章中提到“技术栈不再重要，重要的是质量、品味、设计”，你对此怎么看？你认为未来哪些能力会变得更加重要？
3、Lazar Jovanovic 提到 “作品比履历重要得多”，你怎么理解这句话？在AI时代，个人如何打造自己的“作品集”， 从而提升竞争力？
原文内容
当大家还在热议“靠写 Prompt 赚钱”时，有人已经在靠 全职 Vibe Coding 拿工资了，而且发薪水的还是当红 AI 产品公司 Lovable。
就是那家估值已达 66 亿美元（约合人民币 457 亿元）、已有 800 万用户、员工才 517 人（截至 2025 年底）的“狠角色”——也就是说，Lovable 的人均估值，都快达到 1 亿元了。
更炸裂的是，这家公司在 4 个月内，ARR 从 1 亿美元翻倍到了 2 亿美元。
至于 Lovable 的这位全职 Vibe Coding 员工，他是 真·零技术背景。这哥们儿几乎没写过一行代码，最多手敲过几句 console.log。
履历翻一圈：做过运营、做过增长，从社区和用户支持一路做到公司业务运营管理，唯独没当过程序员。
对于写代码，他的看法是：
这位小哥名叫 Lazar Jovanovic。现在，他的职位写得明明白白：Lovable 首位正式的 “Vibe Coding 工程师”。简称 Vibe Coder。
其实仔细想想，Lovable 开设全职 Vibe Coder 一岗，还挺顺理成章的。
毕竟这家公司主打 “用一句话生成完整网站 / 应用” 的 AI 建站平台。
核心卖点很简单粗暴：不写代码，甚至不用拖组件，直接说需求，页面 + 交互 + 风格一起生成。你越能把需求说清楚，输出的东西就越像样。
Lovable 增长总监 Elena Verna 在播客里直言：“在 AI 公司里，60–70% 的老打法不再适用。”
既然 核心能力，从“敲代码”变成了“跟 AI 把产品聊出来”，那干脆就找个专门干这事的人。也就是说，这个 Vibe Coder 并非噱头、玩概念，而是产品玩法升级之后的自然产物。
那么，全职 Vibe Coder 具体做什么？
Lazar Jovanovic 表示，他现在的时间分配是：80% 用来规划和对话，20% 才是让工具去执行。对于他的工作而言，写代码不是难点，难点是“把话说清楚”。
他的“秘诀”也很清晰直白：同一个想法，先并行开四五个版本。
语音脑暴一版、整理过的提示一版、丢参考图一版、甚至直接喂代码片段一版，就是先让 AI 跑起来，再从结果里倒推“我到底要什么”。
卡住了怎么办？
那就先让 Agent 自己修、再加日志、再把最难的 bug 扔给 Codex；最后把“这次学到的坑”写进 Rules/ 文档里，让 AI 下次自己记住。
简而言之，他把 Vibe Coding 做成了一套流水线：多开几个版本让 AI 自己卷，选出赢家再写成“任务清单 + 规则”，让 agent 按图施工。
最后，人只干一件事：把方向、品味和验收掐住。
这位小哥后来还参加了一场访谈，把如何全职做 Vibe Coding、如何把 AI 工具用到极致，以及“零技术背景怎么练成顶尖 Vibe Coder”掰开揉碎讲了一通。
用主持人的话来说：
“他有一套非常独特、非常实用的框架，我之前从来没听别人讲过，但你一用就能立刻提升使用最新 AI 工具的效果。”
以下是访谈原文主要内容，AI 前线在不改变原意的情况下进行了编辑。
Lazar： 我做的事情，本来就是我愿意免费做的事情，世界上最好的工作。
我每天用像 Lovable 这样的工具把项目推到生产环境里，无论是内部用，还是外部用。
内容可能很广：从营销、销售侧的各种模板，到构建带很多集成和连接的内部工具都有。所以我覆盖的“面”其实横跨很多部门，因为这是一个非常灵活的角色，能补上很多东西。
说到底，这是一个“把想法落地”的角色。很多人有很棒的想法，但他们不知道怎么做出来，或者就是没有带宽去做。这就是我介入的地方：确保这些想法能被快速实现，并且达到它们在生产环境里应该具备的质量和安全性。
Lazar： 对，完全是。比如我发布的一些公开内容：当我们推出 Shopify 集成时，如果不是全部的话，大部分用户重新混合（remix）的模板，都是我做的。还有商品商店，因为我们显然想证明这个概念：你看，Lovable 和 Shopify 就是能跑起来，而且很简单，任何人都能做。我用 Vibe Coding 搭了我们的商品商店。
所以，所有的商品，包括人们在线买的那件衬衫，都是从我搭的那家店里买的。
但在内部侧，我们也想跟踪很多东西。比如我们现在想做一个很酷的东西：功能采用矩阵。也就是我们做了一个功能之后，到底有多少人真的在用、在采用。这就需要很定制的实现，我们技术栈非常定制，我们在做的功能也很定制，市面上没有什么现成的东西能让我“直接从货架上拿来用”，还比我自己做更快。
在这个阶段，如果我为了某件事去开一个大企业账户要花一两个小时，那我自己做可能更快。所以你可以说，我经常处在“自研 vs. 购买”的决策点上，很多时候我会选择把船自己造出来。
Lazar： 我觉得更接近前者。我一开始是在增长团队。Elena 早期招了我，因为她有很多好想法，她需要一个人具备正确的心态、速度和所有权，把这些想法接过来、做出来、上线，无论是教育向的，还是 go-to-market 的各种东西。
但显然，当你能快速发货时，在我们公司现在这种环境里，每个团队都需要这种能力，我们是历史上增长最快的初创公司之一。
所以现在几乎每个部门都需要一个 Lazar，甚至“昨天就需要”。
我也在逐渐转向更多 go-to-market 的工作，甚至会帮企业团队做一些内部工具；同时我现在也在做一些社区工具。所以我确实有点到处跑，但我喜欢这种环境：我被给到一个粗略的概念、一个粗略的想法，然后被要求尽快把它变成现实。
无技术背景，如何成为
顶尖“Vibe Coder”？
Lazar： 我很早就意识到的一件事是：非常坦诚地讲，在开始之前我没有技术背景。我这辈子没写过一行代码。最多就是手敲过几次 console.log——所以我非常依赖 AI 协助。
我确实觉得没有技术背景反而是一种优势。 因为像我这样的人，不知道自己“不该去做 XYZ”，这反而是我们真的能把它做出来的原因。
举个例子：大概六七个月前，我们社区有人说，“我希望 Lovable 能做 Chrome 扩展。”非技术的人会想：嗯，为什么不行？然后技术的人开始解释：它是 React、技术栈不一样、各种原因……
但像我这样的人，就会直接给 Lovable 说：基于这个应用给我做一个 Chrome 扩展。结果还真的做出来了。也有人在 Lovable 上做出了桌面应用，同样，一些按传统认知“不太可能”的事，就这么发生了。
我们社区经理也有一次和我在一起，她在做一个演示文稿。她说，“如果这是个视频会很酷。”然后她就直接通过提示词进 Lovable，在那个功能还没上线之前，就在 Lovable 里生成了一个真正的视频。后来这就变成了正式功能：现在你可以直接提示 Lovable 去做。
但在她当时做的时候，就连我都觉得那不可能，因为我从来没试过。所以我觉得这就是我们相对技术人员的优势：我们更少被先验限制束缚，往往以一种完全无偏见、甚至“积极妄想”的方式进入。
我认为 使用 AI 工具时你必须有这种“妄想”，你得先带着“在被证明不行之前，一切皆有可能”的心态进入。除了我们今天还会聊到的其他因素，这也确实帮助我在 Lovable 的角色里脱颖而出。
当然，我也认为没有技术背景的人可能会掉进两类担忧或陷阱：一类是卡住时不知道怎么排障；另一类是你可能搭了一个摇摇欲坠的东西，某天会崩，因为你不懂系统架构，不确定它能不能扩展，诸如此类。
Lazar： 最重要的一点：你必须有自我意识。
我进入这个领域时，确实像我说的，有“妄想”的一面：我不想轻易接受“有些事情不可能”。但与此同时，我也非常清楚：为了让它真的对我有利、真的能成，我必须变得更强。
所以我很早就意识到：我们在这里要解决的并不是“编码”本身。我们 要解决的问题其实是“清晰度”。
AI 的输出速度比人类快得多，所以我很早就开始把大量时间放在聊天和规划上，到今天我可以说，我 80% 的时间花在规划和聊天上，只有 20% 在执行计划。
我在优化“正确的速度”，而大多数人在优化“错误的速度”。这是我加入 Lovable 的第二天就学到的第一课：我当然测试和玩过各种工具，但无论你在 Cursor 还是 Claude Code 上做，核心问题都一样，你得清楚自己想做什么，也得知道自己在做什么，因为这些仍然只是工具。
AGI 也许会来，但它还没来；在那之前，你仍然在掌舵。
要掌舵，你就得会下指令。最好的学习方式是通过构建：把这些工具几乎当作“技术联合创始人”和“教育者”，在做的过程中学习；并且虔诚地读“智能体输出”，而不是读“代码输出”。
我不关心代码，语法也不是我的兴趣点。智能体告诉我的事情才重要。我现在对 LLM 和 AI 投入了很多信任，我理解有些人可能没我这么自信，但我觉得今天的模型已经足够好，让我信任它们在语法层面的输出。
可 我真正关心的是智能体输出，因为接下来我要解决的另一个限制就在这里：使用 LLM 有机器层面的限制，也有人类层面的限制。
第一个限制，是所谓的“上下文记忆窗口”。
对非技术的人，我解释时喜欢用阿拉丁和灯神的比喻：很简单，大家都知道这个故事。你擦亮灯，一个灯神出来说：“好，我给你三个愿望，不是 3000 个，也不是三百万个，一次只有三个。”
对我来说，和 AI 一起工作就是：你一次只能提出有限数量的请求，让 AI 真正听得进去、理解要做什么、设定范围、研究、阅读，并采取它需要的全部行动、输入和“配方”，才能产出高质量结果。所以第一部分就是：理解它确实有个限制，而且是以 token 计价的。也许一年后会不一样，但今天就是有 token 限制。
比如我随便举一个 10 万 token 的例子：你提出一个请求时，其中一部分 token 用来读材料，一部分用来浏览网络，一部分用来思考，最后一部分用来执行代码。
然后第二个限制来自人类，你、我，以及人类本身。
回到灯神的比喻：我提出第一个愿望，“我想更高”。猜猜发生了什么？灯神把我变成了 13 英尺高。突然我不能坐车，也进不了家门，我成了一个功能失调的人。为什么？因为我不够具体。所以我们今天需要优化的部分，它以后会变好，但现在还没到那一步，是：AI 还不是真的“理解”。当你对人说“你明白我意思吧”，人类往往能懂，因为我 36 岁，有 36 年的人类经验来理解你的语境；但 AI 没有。
所以你必须具体：你要给参考，要给正确的上下文。我学到的，就是怎么对抗这部分。我想你也能理解：第一部分（token 记忆窗口、模型质量）我控制不了；但后者（你的表达是否清晰）你完全能控制。这也是我今天想深入展开、并尝试教大家的关键：如果我是可变项，我该怎么把这一块修好？
Lazar： 首先，正如你说的，你得擅长理解“清晰”到底意味着什么，以及怎么把它翻译出来。
用我的话说，清晰意味着你能分辨：什么是有品味的，什么只是“够用”，什么是世界级，什么是“神奇”。
我在加入 Lovable 之前就知道，哪怕我还没开始用 Lovable 或任何 AI 工具，第一件我确定的事就是，我不会编码。所以一开始我会觉得：哇，我竟然能做出来，太神奇了。但一周后我发现：我能做，但不够快，于是我开始优化速度。再过两周，我又进入另一个循环：等等，我甚至应该先做这个吗？
因为一旦“怎么做出来”这件事被解决了，你叫它 AI 助手也好、快速工程也好、Vibe Coding 也好，我们接下来要解决的是“其他一切”。
而 “其他一切”都很重要：好的设计、好的品味、好的用户体验。
因为当你用这些工具做东西时，你是在为人类构建；人类是情感动物，我们很多购买或决策都建立在情感之上。所以我认为核心技能再次不是编码。虽然我完全不反对传统工程，我稍后也会说为什么我其实是“精英工程”的超级粉丝。但如果有人像我一样在看这段对话，问“我是不是应该开始学编码？”如果你还没开始，我会很坦诚地说：不用。你可能在优化错误的技能组合。
在 AI 世界里，我们不会因为“更好的原始输出”被奖励；我们会因为 “更好的判断力” 被奖励。
更好的判断力从哪里来？从接触开始。所以我会刻意让自己接触那些我知道会提升我的人和资源。然后也来自构建：说白了，一切都是肌肉，你需要练习，你需要亲眼看到“什么是可能的”。这是我希望在后面某个阶段，能借机灌输给大家的技术和心态转变。
所以，我在这里想说的是：编码某种程度上已经变得像“一个被解决的问题”。
我不看代码，我从没真正编码，我也不想看代码，我不关心底层发生了什么；我看的是智能体输出。
Lazar： 这是我想先植入大家脑子里的第一个心态转变：如果你只有一个模糊的想法，那就让它成为 项目的第一个版本。
打开 Cursor、Lovable，随便你用什么，先输入一个“脑内倾倒（brain dump）”的提示词，就跟它说话。尤其是 Lovable，我不知道其他工具是不是也一样，它有个很酷的语音功能：你点一下，对着它一直说，然后点发送。甚至别等它跑完，你就可以开一个新窗口，再打开一个 Lovable.dev。在这个过程中，你会发现：当我把脑子里的东西倒出来，我好像抓到了一条线索，事情开始变清楚了。
那我就开始 第二个项目：更清晰、更可交付。我知道我要哪些功能、哪些页面；也许我还能找到一个好的参考，我可以去 Maven、去 Dribbble，或者去任何地方，找一张好的截图、一段好的动画并附上，因为大多数工具都支持把文件作为输入的一部分。于是第二个项目开始，事情更清楚了。
然后 第三个：当你开始接触质量之后，你会想，如果我能找到一个已经存在的模板呢？为什么要重新发明轮子？我是在一个别人已经搭好的平台上做东西，那为什么不让 AI 直接接触“高质量长什么样”？所以我会去找一些库，比如 21st.dev、或者一些 build 站点，或者任何允许我不只是导出截图、还能导出代码片段的地方。因为说到底，哪怕英语是“第一编程语言”，Lovable 和其他工具用代码沟通仍然最好。如果你想要像素级的结果，就给它代码。它会比你的英语、西班牙语或任何自然语言，更准确地解释和复刻它。于是第三个项目会更深思熟虑：我不再给一个宽泛的模糊概念，而是给代码片段，“我就要这个确切的设计、这个确切的功能类型”。
当你做完这三步，你会进入一个完全不同的清晰度水平。
如果你只是坐在白纸前，或者只是和 ChatGPT 聊但不动手，你很难达到这种清晰。我认为“采取行动”今天的成本极低，顺便说一句很多还是免费的：这些工具都有免费计划。
很多时候你完全可以不花钱，只是开多个项目试一试，因为那除了消耗构建 credit 之外几乎没成本。你会得到三、四、五、六种不同的方案可以对比。
而当你对比时，清晰度会不断涌现，事情越来越好理解。同时你也解决了你刚提到的一个大问题：AI 垃圾。我喜欢这个词，很多人说 AI 垃圾，其实不是在说“代码丑”，而是在说“设计俗”。而我刚讲的这个过程，会给你四五个不同的设计选项，从长期看反而能省下大量 credit。
很多人会纠结：这不是更费 token/credit 吗？我会说，是的，前期可能多花一点；但从长期来看，如果你真想把项目做完，你会省下几百个 credit，甚至几百美元，更不用说节省的天数，因为你从一开始就有更好的清晰度和更好的迭代路径。
所以，这是解决清晰度的第一步。后面还有更多层，但我猜你可能会先对这一段有问题。
Lazar： 对。
Lazar： 我其实是在帮大家省钱。
甚至可以说，我讲的是“对 Lovable 不利的话”。如果我从 Lovable 的角度出发，我会说：不不不，你就一直修一直修别重开。但我们做的不是那个生意，我们做的是：让任何人都能构建他们想要的东西。这对我也有个人意义：因为它和我共鸣，如果没有 Lovable，我可能一辈子都不会真正构建出任何东西。我不觉得那会是一个有趣的人生。
我可以向大家保证：我和很多人测试过这个框架，每个人给我的反馈都一样，大开眼界。
它很简单，但一点都不直觉，对我自己也是。正如你说的，我可能把它归因于“非技术背景”：对我来说，我会做的第一件事就是直接去做。我从没想过“哦我发明了一个惊人的 hack”。我只是发现：我等一个智能体跑完要这么久，那我干脆再开一个项目、再开一个、再开一个。这也是个生产力 hack。
人们问我：哇，你怎么能发这么多东西？我说：因为我从不一次只做一个项目。我会同时做五六个。我开着六个 Lovable 标签页来回切。
Lazar： 这就是我怎么解决 LLM 的限制问题。
还是用阿拉丁、魔法灯那套比喻：如果 token 窗口是有限的，我怎么让它变得“动态可用”？因为当你不断提示、不断提示，你会发现不管用什么工具，记忆都不是无限的。当你到了第 10、15、20、30、40 条消息时，早期信息一定会在传递过程中丢失。智能体也在优化速度：如果它必须读完整段对话、完整请求流，想要开发一个可行的、复杂的东西几乎不可能，因为会消耗太多时间、记忆和 token。
所以我很早就意识到：如果它记不住，我的工作就是给它“参考系”。我把 Lovable（或任何工具）当作一个需要我在项目推进过程中不断补充上下文的工程师。方式很多，但我觉得最有效的是：我会先做四个并行构建，延续前面的例子。做了上百个项目后，你会很快看到“赢家”，赢家非常明显，甚至没什么竞争。你可能用一两个提示词校准一下，然后就会发现：好，赢家在这里。
到那一步，我会去问工具，或者去 ChatGPT、任何 LLM，让它生成一系列 PRD。PRD 是产品需求文档；对我来说，我把它当作“真理源”（source of truth）：从不同角度定义这个项目哪些东西必须为真。我通常至少会做四个 PRD。
-
第一个是我叫“主计划”的东西：它像一个指南针，我们要构建什么。就像在和一个人类沟通一样，我真把 Lovable 当人类：这就是我们要做的东西。
-
第二个是实施计划：我们怎么做、按什么顺序做。这对质量、品味、以及“像人一样的体验”很重要。因为我仍然在和一个没有情感智能的系统合作，我得把“这个应用应该看起来和感觉如何”定义出来。
-
第三个是设计指南。
-
第四个是用户旅程：用户怎么注册？注册后第一步是什么？第二步是什么？第三步是什么？
这些文件生成之后，我会花很多时间读它们，这就是“规划 + 聊天”的部分。第一天把方向定下来时，如果需要，我会用整整一天只做规划：写文档、拆解事情，因为这一段是在“设定方向”。很多东西都取决于这个阶段。
然后我会整理出一个最终文档：plan.md 或 tasks.md（md 是 markdown）。我用 markdown，是因为我发现 AI 很喜欢读 markdown。它会成为真理源，告诉智能体：为了跑到终点，它需要执行哪些任务和子任务。
最后一层取决于工具：Claude Code 或 Cursor 里有 rules.md 或 agent.md。
规则 / 智能体文件的意义，是让智能体知道你希望它如何行为、长期应该关注什么，这样你不需要在每个提示词里重复自己。在 Lovable 里也有一个专门的项目设置菜单，叫项目知识（project knowledge）。我通常会写：在做任何事之前先读所有文件、先读所有 PRD、读 tasks.md 看下一个任务是什么，然后执行下一组任务；执行完告诉我你做了什么，以及我应该如何测试。
这就是我说的“虔诚地读智能体输出”的地方：我给 AI 智能体它成功所需的工具和资源，规则、文档，以及如何使用它们。到这一步，我基本上只是坐下来读。我不再不断提示。从那之后，我可以开再多窗口：我的提示词变成“继续下一个任务”。上下文我不需要了，我把它外包给智能体。智能体需要上下文，我只需要确保上下文是动态的：我会定期更新文档，让它的 token 窗口随着项目推进而“迁移”。
我不会一直打断流程。是的，我会去测试，可能偶尔插一句提示词，但这就是我为什么能同时做五个项目还不掉产能的原因。正如我说的：我今天是手动这么做；你让我三个月后再看，一个智能体就能替我做这些，我可能基本要失业了。所以我根本不在优化这个技能，我只是用它绕过人类和 LLM 的缺点。
我今天 100% 的时间，都在优化判断力、清晰度、质量、品味、文案和字体。人们用 AI 工作时几乎不谈字体，但在我脑子里，60% 甚至更多的注意力都放在“输出看起来怎样”。那是我的痴迷。我不痴迷于今天讲的这些流程，因为我知道接下来会发生什么：智能体会更强、模型会更好，它们不再需要我来扩展上下文，它们会自己做。
所以对我来说，我要优化的是“更好的决策”，而不是“更好的输出”或“更好的对齐”。
Lazar： 对， 你报一个问题，但没有引用文件、没有架构，只是在描述“它坏了”。任何工具，Lovable、Cursor、Claude Code，都会说：好，我来调查。可你的代码库会越来越大：一开始可能只有 20 个文件，它还能读完；但等你做到 60、70 个边缘功能时，如果你只说“坏了”而没有明确哪个功能、哪个文件对应什么，猜猜会发生什么？
Lovable 会把 token 分配的 80% 都花在“阅读以获得清晰度”上，最后只剩 20% 用来思考和执行。我是猜的，我无法证明，也许会有 LLM 专家在评论里说我错了，但这是我作为一个“未受过教育的人”的最佳推断。
这些工具往往很顺从、很迎合。它们会对你“撒谎”：即使没修好，也会告诉你修好了，因为它们想让你开心，说“是的，我找到了问题并修复了”。当它们没修好时，人们就怪机器。某种程度上我承认这也有道理，但更根本的问题是：这是你的错，我的朋友。你没给工具足够的清晰度和上下文，你只是靠原始力量在泥里疯狂打滑，结果越挖越深。
我们当然希望进入一个 AI 更诚实、而不是更迎合的时代：它会说“我只修复了一部分，因为你没给我足够上下文”。但更大的错误是：人们会相信工具真的修好了。然后他们去测试，发现还是不行，于是开始生气、开始骂、开始吼，结果更糟。
为什么？因为 AI 还有个坏特性：它尽量不伤害你的感受，从不说“你才是笨的那个”，它会说“是我笨”。于是它在下一次请求里不再专注于阅读和排障，而是花掉更多 token 去道歉、去安抚你。我还是那句：我没受过教育，但如果你看过 ChatGPT 思考模型的思考流，你会明白我的意思，当我侮辱它时，它第一反应往往是“用户生气了，我得想办法降低他的焦虑”。我会想：哦天啊，我掉进最差的陷阱了，我让它把最稀缺的资源（token）花在安抚我的情绪，而不是解决实际问题。
所以我的建议是：为了好玩，你当然可以 Vibe Coding 着做、原型阶段也可以 Vibe Coding 着做，探索很有价值，我也喜欢那部分。
但当探索结束，请使用引用文档，使用你能用的所有智能体文件。因为 token 分配非常稀缺，它未来会扩展，事情会更快、更便宜，但在今天它依然非常宝贵。你必须确保它被用在正确方向上。
Lazar： 对，所以第一个是“主计划”（Master Plan），它是一个 10,000 英尺视角的概览，它会在非常高层解释我对这个应用的意图。
这个文件就是主计划 MD。它基本上就是在说：我为什么要做这个、我为谁做这个、我希望用户用起来是什么感受。很多时候，在主计划里我还会引用其他 PRD。
比如我会写：设计需要“现代、顺滑”，但具体参数请参考并阅读设计指南.md，对吧？所以主计划就是一个高层概览，让智能体进入状态：好的，我们正在构建 XYZ。
然后是“实施计划”，因为你知道，事情需要一个顺序。如果你只是没有顺序地把东西堆上去，你永远到不了终点。这个是不是 tasks.md？你是这么叫的吗？不，不是 tasks.md，这是实施计划，我把它叫实施计划。对，对。
实施计划某种程度上是在为未来的 tasks.md 服务。可以说，这些文件最终都是为了构建 tasks.md，当 tasks.md 建好之后，其余文件几乎都只是基础和背景了。实施计划是第一层，它依然是高层概览，不会深入到“怎么一步步到达”的细节；它更多是在解释：嗯，如果我们要做这个，我认为我们应该从后端开始，从表结构开始，然后做认证，然后引入 API，再然后做这个、做那个——就是在高层把顺序讲清楚。
你可以把它想象成这样：我是一个想法人，我坐在一个技术合伙人面前——就像是我和你，我们在一起做一个初创公司。你有软件工程背景，我把我的想法讲给你听，我给你主计划；你回来告诉我：好的，如果你要这么做，它是可行的，这是我建议的排序。这就像一份路线图。你不会马上打开 Linear 去写功能、写 RFC 之类的东西，你只是先在高层讨论事情应该按什么顺序推进。
然后我们俩作为联合创始人再聊：好的，如果我们同意这个顺序，那它应该“看起来像什么、感觉像什么”，对吧？这依然是高层描述。但因为我在用 AI，我可以再走深一点——我很喜欢看到 Lovable 或其他工具、包括 ChatGPT，在这块其实特别擅长。我甚至做了自定义 GPT：如果有人想在进入任何工具之前先从某个地方起步，他们可以去 ChatGPT 商店搜 GPTs，输入 “lovable 基础提示词生成器” 或 “lovable PRD 生成器”，就能找到我做的那个。你只要把脑子里的想法大脑倾倒进去，它会问你几个问题，最后把这些文件作为输出给你。
所以我也会在“设计指南”里放一些 CSS 元素，因为你知道，设计这件事有点 tricky，AI 有时会过度发挥。所以这就是我会做一点“技术驾驶”的地方。
最后是用户旅程：如果我们知道东西“看起来像什么、感觉像什么”，也知道我们在高层要构建什么——高层只是高层——那用户怎么在产品里导航、怎么走完一些关键功能流程，这些就要在用户旅程里说清楚。
然后 tasks.md 就进入“真正落地”的部分：比如你想要这些用户旅程，而且你想先构建后端——那这就是我需要做的一组任务。它会把前面那些内容当作输入，我只是让工具去做那些人类要花很多时间做的苦工，对吧？
我感觉，用这些工具，我们都在变成“打了类固醇的产品经理”。我们确实在利用 AI，但好的产品经理并不是因为写了漂亮的 PRD 被奖励的，他们被奖励的依然是更好的判断力，对吧？写作这件事，其他人也能做。你作为那个要指导和构建产品的人，需要知道什么真正有用、什么有品味、什么能推动事情向前。
我还想补一句：我这么强调“品味”，并不意味着你不应该去构建。恰恰相反，你会在构建过程中变得更好。所以每个听到这里的人，真的都应该今天就去做点东西：一、二、三、四、五个项目，去测试这些工具——这才是你获得清晰度的方式，不只是通过阅读，更是通过实践。
Lazar： 我会建议大家直接去 ChatGPT，就像我说的，直接大脑倾倒进去，你只要输入 “lovable GPT” 或 “lovable PRD 生成器”，你会看到我的名字在那儿，我就是作者。
你进去以后做一次大脑倾倒，它会问你几个问题，帮你获得清晰度，然后生成四个文件给你，你可以拿去上传。很棒。酷。你们可以把链接放出来。
这样就不只是“给你一堆文件”，而是让你去跟它对话：它会为你生成正确的文件，然后你把它塞进 Lovable 或其他工具里。对，它基本上是按“像我一样思考”的方式训练过的。所以，对。哦，太好了，完美。
顺便说一句，我也想聊聊你怎么“自我解锁”，因为你还有另一套提示词体系。但我想先强调一点：这太有意思了——你在用第一性原理重新学习“如何构建产品”。无论你是 PM、工程师还是设计师，你都在发现一套工作流：AI 能帮你填补你作为工程师或 PM 不具备的空缺，帮你起草 PRD 和设计。所以我觉得这特别有趣：这些职能依然存在、依然必要，只是现在变成了“你 + AI”共同组成了那个一直存在的三合一：产品管理、工程、设计。
我一直在想一个问题：未来最有价值的背景到底是什么？PM？工程师？设计师？我一直觉得，PM 的核心能力就是澄清：弄清楚要构建什么，把需求讲清楚，把成功长什么样、感觉如何讲清楚——这套能力会变得更重要。与此同时，“设计组件”的价值也会提升：让产品看起来很棒、感觉很棒。真正擅长设计、品味和判断力的人，价值会越来越高。
在我们进入你学到的“解锁技巧”之前，我还想问：很多时候，事情没走在正确方向上，或者出现 bug——如果你不是工程师，你怎么处理？以及除此之外，你还有没有其他关于“成功提示词”的建议？因为如果我们用正确的术语来衡量成功，正如你指出的：AI 不管你的背景是什么，都是放大器。如果你不知道自己在做什么，你只是在更快地产出垃圾。
我还想强调一个点：在旧世界，“够用”就是够用。因为就连做到“够用”都不容易。十年、十五年前，你做个 SaaS，谁在乎它长什么样？能用就行，能解决问题就行，你会觉得“天啊，我今天太高产了”。如果我们把质量粗略画一下：很差、可以更好、平庸、够用、世界级——过去“够用”和“世界级”之间的差距也许没那么致命。
但现在，这个差距变得巨大，因为每个人都能用 AI 轻松做出“够用”。几乎所有人都能做到。所以今天的关键课题变成了：你如何学习并优化，让自己产出“世界级”和“有魔法感”的东西。
正如你说的，我认为 PM 是今天的 AI 赢家，因为他们带来清晰度。但如果你让我押注下一个赢家类别，像赌徒那样押，我会押设计师。
因为我们正在训练这些工具更清晰、更好，做出更好的技术决策；但我不认为我们会同样快速地训练它们做出更好的“情感决策”。而设计，本质上就是情感。
如果你问我：加入 Lovable 之后，我最大的个人技能提升是什么？
就是和 Felix、Nad、Abby 这些设计师一起工作，真的改变了我。
我会意识到：哦，这才是世界级，这才是它需要的东西。我经常想“偷”他们的一个设计，把它带进我的 Lovable 项目。我会进 Figma，把那个背景拿出来放到我的项目里。然后我发现：一个看起来“相当简单”的渐变，可能要用 50 层来实现。我点开那个组件，我会想：天啊，这不是三个颜色，这是 50 个颜色。而且不只是 50 个颜色——它们还有不同梯度、不同不透明度层级。那一刻我就明白：哦，原来我一直以来最大的断裂就在这里。
所以如果我直接回答你的问题：还有什么技巧？还有什么事情？
设计。
让自己接触精致设计。去关注 Lovable 的 Felix，他有一个非常棒的新闻通讯，会教你怎么提示出更好的设计，怎么理解设计风格。我以前根本不知道什么是波普艺术、什么是玻璃拟态，完全没概念。
所以我甚至在 Lovable 上做了一个应用，专门用来学习这些风格：我需要一个应用来学它们。它现在是公开的，任何人都可以看。像是一个 “UI 风格 … .lovable.app” 的东西（我一时想不起具体网址）。里面有大概 18 种不同风格，还提供了可以直接复制的提示词。
你要学习什么是好设计，学习各种设计风格，学习如何用提示词调出这些风格——这大概就是我在这个阶段最会去优化的方向。
Lazar： 我觉得一定会，而且其实已经开始失效了。以前你介绍一个人，说他是工程师、设计师或者产品经理，基本就能判断他每天在干什么、负责什么。
但现在越来越难了，因为很多人同时在做三种事情。
就像我自己，如果你问我现在是什么职业，我都不知道该怎么回答。我写代码吗？几乎不写。我做产品吗？每天都在做。我做设计吗？每天也在参与。我更像是在用 AI 把想法快速转化成现实的人。
所以我觉得，未来职业会越来越像“能力组合”，而不是一个单一标签。
Lazar： 我通常会说，我是一个用 AI 做产品的人，或者是一个快速构建者。Vibe Coder 这个词现在听起来很新，但我觉得过几年它就会变成普通词汇，就像以前说“互联网工程师”一样，后来大家就不这么说了。真正重要的不是你叫什么，而是你能不能持续创造价值。
Lazar： 老实说，我现在不会把主要精力放在这上面。不是说技术不重要，而是机会成本太高。假设我花两年时间去学底层系统，我大概率还是比不过真正的系统工程师。但如果我把这两年用在理解用户、理解产品、理解商业、理解审美上，我可能会变成一个非常稀缺的人。每个人都应该围绕自己的比较优势去投入，而不是盲目补短板。
Lazar： 如果说后悔，其实更多是后悔没早点意识到“表达”的重要性。包括写作能力、结构化思考能力、把问题讲清楚的能力。我年轻的时候更关注技术细节，觉得把代码写漂亮最重要。现在回头看，其实真正决定你能走多远的，是你能不能把复杂事情讲明白，让别人愿意跟你合作。
Lazar： 其实挺偶然的。我最早只是一个重度用户，用 Lovable 做自己的小项目。我会把自己做的东西公开在 X 上，写我是怎么做的，用了哪些提示词，踩了哪些坑。慢慢地，公司的人注意到我，觉得我对产品理解比较深，而且是真的在用。后来他们直接联系我，说要不要试试一起合作。我甚至没有走传统投简历流程，更像是用作品给自己投了简历。
Lazar： 完全是这样。现在很多人觉得，必须有完美简历、名校背景、大厂经历，但现实是，在 AI 时代，作品比履历重要得多。
你能不能持续输出真实、有价值的东西，别人一看就知道。我的 GitHub、Demo、产品链接，比任何简历都管用。
Lazar： 我觉得完全可以，但前提是你要真的做事，而不是表演。
现在很多人“Build in Public”只是发截图、晒进度，但背后没有长期积累。真正有效的是，你持续半年、一年输出真实项目，别人自然会记住你。你不需要等机会，作品本身就是机会。
Lazar： 对，我现在的安全感不来自公司，也不来自职位，而来自能力组合。我知道自己可以快速学习新工具、快速理解需求、快速做出产品，这让我不太害怕变化。公司可能倒闭，岗位可能消失，但这种能力很难被拿走。
Lazar： 不会消失，我们比以往任何时候都更需要精英工程。
因为我想问一句：在“人人都能构建、人人都在构建”的世界里，谁来做维护？维护代码库、扩展代码库、维护项目——这些仍然是实打实的工作。显然 AI 会越来越擅长这些，但那需要的是另一种层级的技能，对吧？“把东西做出来”是一类能力；“把它扩展、把它撑住、把它长期维护好”，是完全不同的一套技能。
更别提，在人人都在构建的世界里，基础设施也更容易被冲击、被打坏，对吧？我们都知道、也都经历过：Cloudflare 过去两三个月里下线两三次，整个互联网都跟着受影响。修这些问题的人，就是精英工程师。Lovable 也经历过大量新用户涌入，基础设施被冲击；顶住、加固、把它撑住的，也是精英工程师。
所以我认为这里面一定有空间：我们需要真正有硬实力的人，来构建一个能支撑“数十亿构建者”的世界。因为每个人都想学会构建东西——那我们怎么教他们？怎么维护他们所需要的一切：托管、安全、邮件、连接器、API……等等。所以我觉得工程永远有位置。
但我也会说，这是个平衡。我也站在另一派：如果我有个 18 岁的弟弟问我该做什么，我可能会说：去当水管工吧。别去读 CS 学位，去学一门扎实的手艺。因为在美国，新一代百万富翁其实往往是电工、水管工之类的人，对吧？所以这是一个平衡动作。我也说不好。但我确实相信：对未来有感觉、真正优秀的工程师，会一直稀缺、一直需要。
主持人： 你刚刚提到精英工程师。现实里，即使你用这些工具写代码，也一定会遇到问题：代码跑着跑着出错、引入 bug、数据库很怪、网络出问题……当你卡住时，你怎么做？
Lazar： 不管你计划得多好，最终都会遇到问题。我有一个小框架，叫“4x4”。
还是举个例子：如果你车上有 4x4，你会更容易脱困，对吧？同样的意思：我有四种不同的调试方式。每种方式我只尝试一次，我最后会解释为什么“只试一次”。
第一种： 每个工具不一样。我先拿 Lovable 举例，当东西坏掉时，Lovable 的智能体有时足够聪明，会直接说“我犯了一个错误”，它会把那条信息标成橙色，并给你一个小按钮，通常叫“尝试修复”。智能体等于承认：我搞错了。你点一下按钮，大多数时候如果只是小问题，它会直接纠正代码、修好它——没问题。
但显然也有更深的问题。你点了“尝试修复”，问题还在；甚至有时候问题还在，但 Lovable 的智能体并不知道问题还在，于是也不会再给你“尝试修复”按钮。Lovable 以为一切正常，但实际上不是。罪魁祸首通常是：你用到了第三方集成，但你没有给 Lovable 足够的上下文告诉它“该观察什么、该看到什么”，所以它根本看不到问题的存在。
因为今天的 Lovable、Cursor、Cloud Code，它们已经足够好到可以修复“它们知道的任何问题”。所以再次，自我意识很关键：当它们对问题“不知情”时，就需要第二步：把“意识层”带进来。
第二种方式就是： 我去 打开应用的预览环境 / 沙盒 / 开发环境，去复现坏掉的功能，右键打开控制台，看 console log。每个浏览器都可以读控制台日志，很多时候它会记录错误。
如果没有记录，我就会提示工具：“我认为你没看到问题，我们一起找。我觉得问题在 XYZ。我希望你在相关文件里加上 console.log，这样我们能监控每一步。”它会加日志，你重新运行。现在你就有了完整的发生过程。你复制这些日志，粘贴回聊天里。99% 的情况下，这就够了。AI 会说：好的，我找到了，然后修复它。
第三种： 如果连这都不够，那就 进入“代码审查与评估”。 我今天最常用的工具是 Codex（OpenAI）。做法是：无论我做什么构建，我都会导出到 GitHub。Lovable 允许你拥有代码，Cursor 也一样，所有这些工具都允许你导出一份自己的代码。然后我把它导入 Codex。
我从 Beta 就开始用 Codex。这里我会把它当成“外部工具促进者”。第一步我完全在工具里氛围构建；第二步我把自己当成“意识促进者”；第三步我引入外部工具作为“诊断促进者”：我去 Codex 里聊，把诊断结论再带回 Lovable 修复。
我不会让 Codex 直接替我改代码——很多人会问为什么。我当然知道它模型很好，但我不确定它的 agent 行为我是否完全理解；我不想用一个“我还不会驾驶”的工具去做危险操作。所以我只用它做诊断，然后回到熟悉的工具里修复。
再往前推一步，在 Codex / Cloud Code 之前的旧工作流，我也会用 Repo Mix 之类的工具把整个代码库压缩成一个文件，然后上传到 Claude 或 ChatGPT：“这是我的代码库，这是问题，这是控制台日志。” 这就像你去外面请了个顾问——你团队处理不了了，你去找外部专家，对吧。
第四种（而且通常是最有效的）：很多时候问题是我的错。 无论你自尊多大，兄弟，相信我，很多时候就是你的错。你给了一个坏提示词，你用错误方式设定前提，你不愿承认，或者你忘了自己做过什么，但很多时候就是你把系统带偏了。
所以这一步是：回滚。Lovable、Cursor、Cloud Code 都内置版本控制。你发现前三种都不行，就退回三步，重新想一遍提示词，呼吸一下，散个步，喝杯咖啡，脑子清醒一点再来一遍。因为有时候 AI 只是非常快地写代码，它可能被一个很小的“石子”绊了一下，你重试同样的请求，它就能过去。这往往只是一个小 snag、一个语法小错误之类的东西。
然后我会做最后一件事，这件事才是关键：当问题修复之后，我会切到聊天模式问它（我叫它 Lola）：“我刚才用了四种方式才修好。你能不能教我，下一次我该怎么提示，才能一次就到位？”
99% 的时候，它会给我一个特别好的答案，让我下次知道该怎么做。
所以总结一下：我们需要意识，也需要现实。这些工具在被正确使用时，非常擅长把事情做对。很多时候问题不在工具，而在输入：我没有动态移动 token 的分配，我没有引用正确的文件，我没有用正确方式说清楚。
对我来说，作为一个非设计师，我也不知道术语、也不知道各种标题怎么叫，所以我经常在提示上卡住。这时我就用聊天模式让它帮我起草一个更好的提示词。任何人都可以这么做：如果你卡住了，晚上十点，你不知道怎么问——切到聊天模式，大脑倾倒，然后说：“帮我起草一个更好的提示词，帮我更好地提示你。”
让工具有效地提示它自己。很多时候你根本不会走到“坏输入导致的 bug”。
-
第一步：让工具“尝试修复”。很多时候它会说：我发现错误了，我来修吗？你说：请修。可能就好了。
-
第二步：加更多控制台日志，让它看见问题发生的全过程。我太喜欢这个建议了：让它给自己的 console 加更多调试信息，帮助它知道发生了什么。
-
第三步：去 Codex。这也很有意思，我经常听人说：Codex 像“最精英的工程师”。Karpathy 之前好像也发过推。我们也请过 Codex 的负责人上播客，他说：每次遇到最乱七八糟的 bug，他就丢给 Codex 跑半小时，能解决掉——这在其他工具里不太能做到。所以你去 Codex，把代码、日志、问题描述都给它，让它去定位。
-
第四步：回滚、冷静、重写提示——很多时候问题根源是提示本身。
然后你还有“最后一步”：把这次当学习机会，问智能体：我怎么做才能下一次一次到位？
甚至更进一步：把这次学到的东西写进 rules.md——因为反正它会读 rules，那就让它把“你这个人容易犯的错”记下来，让它下次自己帮你提示自己，就是把上下文从“你脑子里”移动到“规则里”。
Lazar：技术栈不再重要。
人们总痴迷：这是 HTML 写的，还是 React 写的？——不重要。它以前就没那么重要，而现在更不重要。最终用户只想要一个卓越体验。
我们正生活在一个“任何人都能产出‘够用’”的世界里。所以你最好开始学习怎么产出“魔法”，否则你最后就会跟数百万人一样淹没在一起。但同时，如果你还不知道“魔法”长什么样，也别沮丧——先从构建任何东西开始，从“够用”起步，再一点点提高。
提高的最好方式，是接触时间：花更多时间学习，比花时间编码更重要。去读智能体输出，去理解它怎么想，这样你才知道“什么是可能的”。然后也要去找灵感：在 X 上关注好的设计师；找到能产出好设计的工具，关注它们的创作者。
有一个工具，我就专门关注那个做工具的人，因为他几乎每天发 40-50 分钟的视频，边设计边讲。我想看一个世界级设计师怎么做，我想看他怎么跟工具对话，怎么写提示词——这就是我学习变强的方式。
所以还是那句话：接触时间。要有意识地把更多时间放在学习上，而不是编码上。因为你可以很快编码，但你既可以很快编码出垃圾，也可以很快编码出魔法。花的时间差不多，关键在于你的输入。
忘掉技术栈决策吧。忘掉用哪个后端、哪个前端，那不重要。
重要的是：质量、品味、设计。这就是你在未来需要优化的一切。
参考链接：
https://www.youtube.com/watch?v=0XNkUdzxiZI
https://lovable.dev/blog/series-b
