这个从没写过一行代码的人，靠 Vibe Coding 拿到了全职 Offer
Lazar Jovanovic 是 Lovable 的第一位官方 Vibe Coding 工程师。
他的工作内容就是用 AI 工具构建产品——内部的、外部的，从营销模板到功能追踪工具，什么都做。
他负责的周边商品商店是他自己用 Vibe Coding 搭的，用户真的在上面买东西。
重点来了：他这辈子几乎没手写过一行代码。可能手敲过几个 console.log ，仅此而已。
而且他认为这是一种优势。
一、不知道"不可能"，反而做成了
Lazar 说了一个特别有意思的观点：像他这种完全没技术背景的人，根本不知道自己"不应该"去构建某些东西。
他举了个例子。有人在社区里说："我希望 Lovable 能做 Chrome 扩展程序。"
技术人员马上开始解释：不行，React 的技术栈不同巴拉巴拉……
而 Lazar 呢，他直接打开 Lovable，输入："基于这个应用给我建一个 Chrome 扩展"。
然后就做出来了。
还有人用同样的方式做出了桌面应用——理论上也是"不可能"的。
他们的社区经理想把 PPT 变成视频，就不停地输入提示词，居然在 Lovable 里生成了一个实际可播放的视频。
这甚至是在那个功能正式推出之前。
Lazar 把这叫做" 盲目自信 "—— 在使用 AI 工具的时候，你必须相信一切都是可能的， 直到被证明不行 。
二、80%的时间在聊天，20%在执行
这是 Lazar 分享的最核心的洞察。
大多数人用 AI 工具的方式是：
打开工具，输入一个模糊的想法，期待它给出完美结果，然后失望，然后骂 AI 垃圾。
Lazar 反过来。他把 80% 的时间花在规划和对话上 ，只有 20% 在实际执行。
他用了一个阿拉丁神灯精灵的比喻来解释这件事——我觉得这个比喻太到位了。
精灵给你三个愿望。你说"我想变高"，精灵把你变成了 13 英尺高。你坐不进车，进不了房子，成了一个功能失调的人。
为什么？因为你没给具体指令。
AI 工具也是这样。
当你说"你懂我意思吧"，它其实不懂。它没有你 36 年的人生经验来推断你到底想要什么。
你必须具体，必须提供参考，必须提供正确的上下文。
而大部分人优化的方向搞错了——他们在优化"写代码的速度"，但真正需要优化的是" 清晰度 "。
三、一个项目开5个版本的"反直觉"方法
这是 Lazar 分享的最具操作性的建议。
他说，当你有一个模糊想法时，不要死磕一个项目。直接同时开好几个：
第一个版本：
大脑倾倒。打开工具，对着语音输入一股脑儿说出你的想法，按回车。别等它完成。
第二个版本：
在第一个的基础上，你的思路已经稍微清晰了一点。
这次你可以写 更有条理的提示词 ，甚至去 Mobbin 或 Dribbble 截一张好看的设计图附上去。
第三个版本：
更进一步。找一个长得差不多的现成代码模板或组件库，直接把代码片段喂给 AI。
因为虽然英语是第一大"编程语言"，但 AI 最擅长理解的还是 代码本身 。
做完这三四个版本后，你不需要任何人帮你决定方向——AI已经完全懂你的意图了。
而且这个过程解决了一个很多人头疼的问题： AI 审美疲劳 。
因为你有四五个不同的设计方向可以比较，不再被第一个输出锁死。
很多人觉得这会浪费积分。
Lazar 说恰恰相反——
如果你一开始就做对了方向，后面省下的反复修改、推倒重来，能省上百美元甚至更多。
四、PRD 不是给产品经理看的，是给 AI 看的
确定了方向之后，Lazar 会花整整一天的时间来规划——不写一行代码。
他会构建四个核心文档：
Master Plan（总体规划）：
高层概述，说明"我们正在构建什么，为谁构建，用户怎么用"。
就像跟联合创始人解释你的想法。
Implementation Plan（实施计划）：
构建的顺序是什么？先做后端还是先做前端？先搞数据库还是先搞认证？
Design Guidelines（设计指南）：
包含一些 CSS 元素，因为 AI 在设计上容易过度发挥创造力，需要技术引导。
User Journey（用户旅程）：
用户注册后第一步干什么，第二步干什么，完整的流程。
最后，基于这四个文档，他生成一个 tasks.md ——这才是 AI 真正执行的" 任务清单 "。
从那之后，他的提示词变成了一句话："继续下一个任务。"
他不需要提供上下文了，因为所有上下文都在文档里。AI 自己去读，自己去执行。
他只需要坐在那里看输出，偶尔测试一下，然后切换到下一个项目的窗口。
这就是他能同时推进五六个项目的秘密。
五、卡住了怎么办：4x4 越野框架
无论计划多好，你总会遇到 bug。
Lazar 有一个他叫做 "4x4" 的排错框架——四种方法，每种只试一次。
第一步：让工具自己修。
Lovable 的 Agent 会标出错误，给你一个"尝试修复"按钮。小问题通常到这一步就解决了。
第二步：给它意识。
打开浏览器控制台，读 console.log。
如果没有日志，就让 AI 在相关文件里加上 console.log ，重新运行，把输出喂回给它。99%的情况这就够了。
第三步：请外援。
把代码库导出到 GitHub，用 OpenAI 的 Codex 做诊断——但只做诊断，不让它改代码。
因为 Lazar 不熟悉那个工具的 Agent 行为，只把它当外部顾问。
第四步：承认是自己的错。
回退几步，重新审视自己的提示词。深呼吸，去散个步，回来重新提。
很多时候同样的请求再来一次就过了——可能上一次只是一个偶发的语法错误。
最关键的是第四步之后的动作：问 AI "你能帮我学习下次如何更好地提示你吗"，然后把学到的东西写进 rules.md 。下次它自己就知道了。
六、未来需要什么样的人
Lazar 说了一句我印象很深的话：
"在 AI 的世界里，我们不会因为输出速度快而获得奖励，我们将因为更好的判断力而获得奖励。"
当每个人都能用 AI 产出"足够好"的东西时，"足够好"就不够了。你必须能产出"魔法"。
他认为下一批赢家是设计师。
因为我们可以训练 AI 做更好的技术决策，但还训练不了它做更好的 情感决策 。设计全是关于情感的。
具体到技能，他列了几个：
好的设计和品味 ：包括图像和字体。他说 "字体决定了你 60% 的输出外观"，但用 AI 的人根本不聊字体。
文案写作 ：AI 的文案三秒就能被识破。 真正好的文案是一种稀缺技能 。
情感智能 ：理解人性，理解"人对人"的动态。
还有一个被他反复强调的东西： 暴露时间 。刻意让自己接触世界级的设计、产品、体验。
他关注 Lovable 的 设计师 Felix 的 Newsletter ，看他做设计的完整过程视频。
不是说"我要成为设计师"，而是说： 我要知道什么是好的，才能要求 AI 产出好的 。
关于软件工程师会不会消失，Lazar 的回答很有意思： 永远不会 。
在一个所有人都在构建的世界里，谁来做维护？谁来扩展基础设施？
Cloudflare 过去几个月宕机了好几次，修复这些问题的是 精英工程师 。
但他对自己 18 岁的弟弟的建议是：" 去当个水管工吧，别去拿计算机科学学位了 。"
最后，他说了一句让我觉得这个人跟其他所有 AI 鼓吹者不一样的话：
"Lovable 不是一家公司，它是一个使命。我六岁时有了第一台电脑，一辈子都想构建东西。但生活对我来说并不简单。过去五到十年里，我几乎放弃了那个梦想。现在 36 岁，30 年后，我又可以像那个孩子一样做梦了。"
手动写代码这件事，可能正在变成一种像书法一样的艺术。
精美，但不再是唯一的路径。
恐惧会转化为兴奋——前提是你得先动手做点什么。
热门跟贴