北京
作者 ｜ 木子
當大家還在熱議“靠寫 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 前線在不改變原意的情況下進行了編輯。
全職 Vibe Coder 做什么？
主持人：我之前邀請了 Elena Verna（Lovable 的增長負責人）上播客，她提到自己和一位專業的 Vibe Coding 師一起工作，就是你。首先，我想從最具體的工作本身開始：你日常做什么、具體負責什么？你拿全職薪水做 Vibe Coding，這太不可思議了。
Lazar：我做的事情，本來就是我愿意免費做的事情，世界上最好的工作。
我每天用像 Lovable 這樣的工具把項目推到生產環境里，無論是內部用，還是外部用。
內容可能很廣：從營銷、銷售側的各種模板，到構建帶很多集成和連接的內部工具都有。所以我覆蓋的“面”其實橫跨很多部門，因為這是一個非常靈活的角色，能補上很多東西。
說到底，這是一個“把想法落地”的角色。很多人有很棒的想法，但他們不知道怎么做出來，或者就是沒有帶寬去做。這就是我介入的地方：確保這些想法能被快速實現，并且達到它們在生產環境里應該具備的質量和安全性。
主持人：這里有個特別有趣的點：你做的既有內部工具，也有外部工具。很多公司確實有人用 AI 做一堆內部工具，但你交付的東西實際上是公開的，而且是產品級的產品。
Lazar：對，完全是。比如我發布的一些公開內容：當我們推出 Shopify 集成時，如果不是全部的話，大部分用戶重新混合（remix）的模板，都是我做的。還有商品商店，因為我們顯然想證明這個概念：你看，Lovable 和 Shopify 就是能跑起來，而且很簡單，任何人都能做。我用 Vibe Coding 搭了我們的商品商店。
所以，所有的商品，包括人們在線買的那件襯衫，都是從我搭的那家店里買的。
但在內部側，我們也想跟蹤很多東西。比如我們現在想做一個很酷的東西：功能采用矩陣。也就是我們做了一個功能之后，到底有多少人真的在用、在采用。這就需要很定制的實現，我們技術棧非常定制，我們在做的功能也很定制，市面上沒有什么現成的東西能讓我“直接從貨架上拿來用”，還比我自己做更快。
在這個階段，如果我為了某件事去開一個大企業賬戶要花一兩個小時，那我自己做可能更快。所以你可以說，我經常處在“自研 vs. 購買”的決策點上，很多時候我會選擇把船自己造出來。
主持人：那你向誰匯報？你是那種到處支援的“游牧者”，還是跟著某個固定團隊一起工作？
Lazar：我覺得更接近前者。我一開始是在增長團隊。Elena 早期招了我，因為她有很多好想法，她需要一個人具備正確的心態、速度和所有權，把這些想法接過來、做出來、上線，無論是教育向的，還是 go-to-market 的各種東西。
但顯然，當你能快速發貨時，在我們公司現在這種環境里，每個團隊都需要這種能力，我們是歷史上增長最快的初創公司之一。
所以現在幾乎每個部門都需要一個 Lazar，甚至“昨天就需要”。
我也在逐漸轉向更多 go-to-market 的工作，甚至會幫企業團隊做一些內部工具；同時我現在也在做一些社區工具。所以我確實有點到處跑，但我喜歡這種環境：我被給到一個粗略的概念、一個粗略的想法，然后被要求盡快把它變成現實。
無技術背景，如何成為
頂尖“Vibe Coder”？
主持人：你總結出了哪些專業技巧，能更成功地使用 AI 工具，比如 Lovable？有沒有兩三件事，特別幫助你把這份工作做得非常好？
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 世界里，我們不會因為“更好的原始輸出”被獎勵；我們會因為“更好的判斷力”被獎勵。
更好的判斷力從哪里來？從接觸開始。所以我會刻意讓自己接觸那些我知道會提升我的人和資源。然后也來自構建：說白了，一切都是肌肉，你需要練習，你需要親眼看到“什么是可能的”。這是我希望在后面某個階段，能借機灌輸給大家的技術和心態轉變。
所以，我在這里想說的是：編碼某種程度上已經變得像“一個被解決的問題”。
我不看代碼，我從沒真正編碼，我也不想看代碼，我不關心底層發生了什么；我看的是智能體輸出。
主持人：但我這里聽到的是：你把大量精力投在兩件事上，第一是清晰度：你到底想構建什么；第二是品味與判斷力：這是不是你真的想要的東西。回到“清晰度”這部分：我們來具體聊聊，你會怎么更清楚地向 Lovable，以及其他 AI 工具表達，幫助它構建出你真正想要的東西？
Lazar：這是我想先植入大家腦子里的第一個心態轉變：如果你只有一個模糊的想法，那就讓它成為項目的第一個版本。
打開 Cursor、Lovable，隨便你用什么，先輸入一個“腦內傾倒（brain dump）”的提示詞，就跟它說話。尤其是 Lovable，我不知道其他工具是不是也一樣，它有個很酷的語音功能：你點一下，對著它一直說，然后點發送。甚至別等它跑完，你就可以開一個新窗口，再打開一個 Lovable.dev。在這個過程中，你會發現：當我把腦子里的東西倒出來，我好像抓到了一條線索，事情開始變清楚了。
那我就開始第二個項目：更清晰、更可交付。我知道我要哪些功能、哪些頁面；也許我還能找到一個好的參考，我可以去 Maven、去 Dribbble，或者去任何地方，找一張好的截圖、一段好的動畫并附上，因為大多數工具都支持把文件作為輸入的一部分。于是第二個項目開始，事情更清楚了。
然后第三個：當你開始接觸質量之后，你會想，如果我能找到一個已經存在的模板呢？為什么要重新發明輪子？我是在一個別人已經搭好的平臺上做東西，那為什么不讓 AI 直接接觸“高質量長什么樣”？所以我會去找一些庫，比如 21st.dev、或者一些 build 站點，或者任何允許我不只是導出截圖、還能導出代碼片段的地方。因為說到底，哪怕英語是“第一編程語言”，Lovable 和其他工具用代碼溝通仍然最好。如果你想要像素級的結果，就給它代碼。它會比你的英語、西班牙語或任何自然語言，更準確地解釋和復刻它。于是第三個項目會更深思熟慮：我不再給一個寬泛的模糊概念，而是給代碼片段，“我就要這個確切的設計、這個確切的功能類型”。
當你做完這三步，你會進入一個完全不同的清晰度水平。
如果你只是坐在白紙前，或者只是和 ChatGPT 聊但不動手，你很難達到這種清晰。我認為“采取行動”今天的成本極低，順便說一句很多還是免費的：這些工具都有免費計劃。
很多時候你完全可以不花錢，只是開多個項目試一試，因為那除了消耗構建 credit 之外幾乎沒成本。你會得到三、四、五、六種不同的方案可以對比。
而當你對比時，清晰度會不斷涌現，事情越來越好理解。同時你也解決了你剛提到的一個大問題：AI 垃圾。我喜歡這個詞，很多人說 AI 垃圾，其實不是在說“代碼丑”，而是在說“設計俗”。而我剛講的這個過程，會給你四五個不同的設計選項，從長期看反而能省下大量 credit。
很多人會糾結：這不是更費 token/credit 嗎？我會說，是的，前期可能多花一點；但從長期來看，如果你真想把項目做完，你會省下幾百個 credit，甚至幾百美元，更不用說節省的天數，因為你從一開始就有更好的清晰度和更好的迭代路徑。
所以，這是解決清晰度的第一步。后面還有更多層，但我猜你可能會先對這一段有問題。
主持人：這太好了，它展示了“沒有工程背景的人進入這個世界”的力量。你的建議是“并行構建五次”，讓 AI 同時嘗試不同方法。這不是傳統軟件工程師、PM 或設計師通常會采用的方式，所以它特別有意思。也就是說：你啟動一個項目時，會用五種不同的方式并行開跑。
Lazar：對。
主持人：有人可能會想：你這不就是讓我們多花 Lovable 的 token 嗎？畢竟這是 Lovable 的人說的。但我反而覺得，這是最能省錢的地方：你一開始做對了，后面就能省下大量“把它拉回到正確方向”的成本。
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% 甚至更多的注意力都放在“輸出看起來怎樣”。那是我的癡迷。我不癡迷于今天講的這些流程，因為我知道接下來會發生什么：智能體會更強、模型會更好，它們不再需要我來擴展上下文，它們會自己做。
所以對我來說，我要優化的是“更好的決策”，而不是“更好的輸出”或“更好的對齊”。
主持人：也就是說：你先開多個項目并行嘗試，選出最對的方向；一旦方向確定，你基本會花一天不去構建，而是和 AI 智能體一起把計劃規劃清楚。
主持人：所以關鍵思路是：前期把時間花在規劃上，因為它會在后面省下大量時間；然后只有當你有了計劃，才讓它開始執行。這里有個關鍵點是“三個愿望規則”：你這樣做不僅是為了對計劃更清晰，也是在貫徹“一次只做一件事”，把智能體的上下文窗口保持得更小，它就不會丟失自己在做什么。
Lazar：對， 你報一個問題，但沒有引用文件、沒有架構，只是在描述“它壞了”。任何工具，Lovable、Cursor、Claude Code，都會說：好，我來調查。可你的代碼庫會越來越大：一開始可能只有 20 個文件，它還能讀完；但等你做到 60、70 個邊緣功能時，如果你只說“壞了”而沒有明確哪個功能、哪個文件對應什么，猜猜會發生什么？
Lovable 會把 token 分配的 80% 都花在“閱讀以獲得清晰度”上，最后只剩 20% 用來思考和執行。我是猜的，我無法證明，也許會有 LLM 專家在評論里說我錯了，但這是我作為一個“未受過教育的人”的最佳推斷。
這些工具往往很順從、很迎合。它們會對你“撒謊”：即使沒修好，也會告訴你修好了，因為它們想讓你開心，說“是的，我找到了問題并修復了”。當它們沒修好時，人們就怪機器。某種程度上我承認這也有道理，但更根本的問題是：這是你的錯，我的朋友。你沒給工具足夠的清晰度和上下文，你只是靠原始力量在泥里瘋狂打滑，結果越挖越深。
我們當然希望進入一個 AI 更誠實、而不是更迎合的時代：它會說“我只修復了一部分，因為你沒給我足夠上下文”。但更大的錯誤是：人們會相信工具真的修好了。然后他們去測試，發現還是不行，于是開始生氣、開始罵、開始吼，結果更糟。
為什么？因為 AI 還有個壞特性：它盡量不傷害你的感受，從不說“你才是笨的那個”，它會說“是我笨”。于是它在下一次請求里不再專注于閱讀和排障，而是花掉更多 token 去道歉、去安撫你。我還是那句：我沒受過教育，但如果你看過 ChatGPT 思考模型的思考流，你會明白我的意思，當我侮辱它時，它第一反應往往是“用戶生氣了，我得想辦法降低他的焦慮”。我會想：哦天啊，我掉進最差的陷阱了，我讓它把最稀缺的資源（token）花在安撫我的情緒，而不是解決實際問題。
所以我的建議是：為了好玩，你當然可以 Vibe Coding 著做、原型階段也可以 Vibe Coding 著做，探索很有價值，我也喜歡那部分。
但當探索結束，請使用引用文檔，使用你能用的所有智能體文件。因為 token 分配非常稀缺，它未來會擴展，事情會更快、更便宜，但在今天它依然非常寶貴。你必須確保它被用在正確方向上。
主持人：燈神這個比喻特別貼切：你“許愿”不清楚，它就會按字面理解，結果跑偏。有句話我很認同：AI 的上限不在“有多聰明”，而在它動手前“看到了什么”——你喂給它的上下文，本質上決定了它能不能做對。
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 被獎勵的，他們被獎勵的依然是更好的判斷力，對吧？寫作這件事，其他人也能做。你作為那個要指導和構建產品的人，需要知道什么真正有用、什么有品味、什么能推動事情向前。
我還想補一句：我這么強調“品味”，并不意味著你不應該去構建。恰恰相反，你會在構建過程中變得更好。所以每個聽到這里的人，真的都應該今天就去做點東西：一、二、三、四、五個項目，去測試這些工具——這才是你獲得清晰度的方式，不只是通過閱讀，更是通過實踐。
主持人：為了幫助大家用你描述的這套 MD 文件工作流，你能不能分享一些模板？比如這些文件的簡單模板，讓大家可以直接看、直接復制？
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：如果說后悔，其實更多是后悔沒早點意識到“表達”的重要性。包括寫作能力、結構化思考能力、把問題講清楚的能力。我年輕的時候更關注技術細節，覺得把代碼寫漂亮最重要。現在回頭看，其實真正決定你能走多遠的，是你能不能把復雜事情講明白，讓別人愿意跟你合作。
主持人：你現在狀態看起來很好，那你是怎么走到現在這個位置的？你當初是怎么進入 Lovable 的？
Lazar：其實挺偶然的。我最早只是一個重度用戶，用 Lovable 做自己的小項目。我會把自己做的東西公開在 X 上，寫我是怎么做的，用了哪些提示詞，踩了哪些坑。慢慢地，公司的人注意到我，覺得我對產品理解比較深，而且是真的在用。后來他們直接聯系我，說要不要試試一起合作。我甚至沒有走傳統投簡歷流程，更像是用作品給自己投了簡歷。
主持人：等于你是通過 Build in Public，把自己做進公司的？
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
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
