北京
作者 ｜ 木子
當大家還在熱議“靠寫 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 前線在不改變原意的情況下進行了編輯。
1 全職 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 的工作，甚至會幫企業團隊做一些內部工具；同時我現在也在做一些社區工具。所以我確實有點到處跑，但我喜歡這種環境：我被給到一個粗略的概念、一個粗略的想法，然后被要求盡快把它變成現實。
2 無技術背景，如何成為頂尖“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 種不同風格，還提供了可以直接復制的提示詞。
你要學習什么是好設計，學習各種設計風格，學習如何用提示詞調出這些風格——這大概就是我在這個階段最會去優化的方向。
3 技術棧不再重要，能力組合才是未來
主持人：你剛才說，未來真正拉開差距的是判斷力和審美，而不是某一個具體技能。從這個角度來看，你覺得現在這些傳統的職業標簽，比如“程序員”、“產品經理”、“設計師”，會不會慢慢失效？
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
會議推薦
InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
