技術(shù)框架不重要，大廠簡歷不值錢？小哥不會寫代碼卻進了Lovable，80% 靠聊天也能上生產(chǎn)

　　作者 ｜ 木子

　　當(dāng)大家還在熱議“靠寫 Prompt 賺錢”時，有人已經(jīng)在靠全職 Vibe Coding拿工資了，而且發(fā)薪水的還是當(dāng)紅 AI 產(chǎn)品公司Lovable。

　　就是那家估值已達 66 億美元（約合人民幣 457 億元）、已有 800 萬用戶、員工才 517 人（截至 2025 年底）的“狠角色”——也就是說，Lovable 的人均估值，都快達到 1 億元了。

　　更炸裂的是，這家公司在 4 個月內(nèi)，ARR 從 1 億美元翻倍到了 2 億美元。

　　至于 Lovable 的這位全職 Vibe Coding 員工，他是真·零技術(shù)背景。這哥們兒幾乎沒寫過一行代碼，最多手敲過幾句console.log。

　　履歷翻一圈：做過運營、做過增長，從社區(qū)和用戶支持一路做到公司業(yè)務(wù)運營管理，唯獨沒當(dāng)過程序員。

　　對于寫代碼，他的看法是：

　　這位小哥名叫 Lazar Jovanovic。現(xiàn)在，他的職位寫得明明白白：Lovable 首位正式的 “Vibe Coding 工程師”。簡稱 Vibe Coder。

　　其實仔細想想，Lovable 開設(shè)全職 Vibe Coder 一崗，還挺順理成章的。

　　畢竟這家公司主打 “用一句話生成完整網(wǎng)站 / 應(yīng)用” 的 AI 建站平臺。

　　核心賣點很簡單粗暴：不寫代碼，甚至不用拖組件，直接說需求，頁面 + 交互 + 風(fēng)格一起生成。你越能把需求說清楚，輸出的東西就越像樣。

　　Lovable 增長總監(jiān) Elena Verna 在播客里直言：“在 AI 公司里，60–70% 的老打法不再適用。”

　　既然核心能力，從“敲代碼”變成了“跟 AI 把產(chǎn)品聊出來”，那干脆就找個專門干這事的人。也就是說，這個 Vibe Coder 并非噱頭、玩概念，而是產(chǎn)品玩法升級之后的自然產(chǎn)物。

　　那么，全職 Vibe Coder 具體做什么？

　　Lazar Jovanovic 表示，他現(xiàn)在的時間分配是：80% 用來規(guī)劃和對話，20% 才是讓工具去執(zhí)行。對于他的工作而言，寫代碼不是難點，難點是“把話說清楚”。

　　他的“秘訣”也很清晰直白：同一個想法，先并行開四五個版本。

　　語音腦暴一版、整理過的提示一版、丟參考圖一版、甚至直接喂代碼片段一版，就是先讓 AI 跑起來，再從結(jié)果里倒推“我到底要什么”。

　　卡住了怎么辦？

　　那就先讓 Agent 自己修、再加日志、再把最難的 bug 扔給 Codex；最后把“這次學(xué)到的坑”寫進 Rules/ 文檔里，讓 AI 下次自己記住。

　　簡而言之，他把 Vibe Coding 做成了一套流水線：多開幾個版本讓 AI 自己卷，選出贏家再寫成“任務(wù)清單 + 規(guī)則”，讓 agent 按圖施工。

　　最后，人只干一件事：把方向、品味和驗收掐住。

　　這位小哥后來還參加了一場訪談，把如何全職做 Vibe Coding、如何把 AI 工具用到極致，以及“零技術(shù)背景怎么練成頂尖 Vibe Coder”掰開揉碎講了一通。

　　用主持人的話來說：

　　“他有一套非常獨特、非常實用的框架，我之前從來沒聽別人講過，但你一用就能立刻提升使用最新 AI 工具的效果。”

　　以下是訪談原文主要內(nèi)容，AI 前線在不改變原意的情況下進行了編輯。

　　全職 Vibe Coder 做什么？

　　主持人：我之前邀請了 Elena Verna（Lovable 的增長負責(zé)人）上播客，她提到自己和一位專業(yè)的 Vibe Coding 師一起工作，就是你。首先，我想從最具體的工作本身開始：你日常做什么、具體負責(zé)什么？你拿全職薪水做 Vibe Coding，這太不可思議了。

　　Lazar：我做的事情，本來就是我愿意免費做的事情，世界上最好的工作。

　　我每天用像 Lovable 這樣的工具把項目推到生產(chǎn)環(huán)境里，無論是內(nèi)部用，還是外部用。

　　內(nèi)容可能很廣：從營銷、銷售側(cè)的各種模板，到構(gòu)建帶很多集成和連接的內(nèi)部工具都有。所以我覆蓋的“面”其實橫跨很多部門，因為這是一個非常靈活的角色，能補上很多東西。

　　說到底，這是一個“把想法落地”的角色。很多人有很棒的想法，但他們不知道怎么做出來，或者就是沒有帶寬去做。這就是我介入的地方：確保這些想法能被快速實現(xiàn)，并且達到它們在生產(chǎn)環(huán)境里應(yīng)該具備的質(zhì)量和安全性。

　　主持人：這里有個特別有趣的點：你做的既有內(nèi)部工具，也有外部工具。很多公司確實有人用 AI 做一堆內(nèi)部工具，但你交付的東西實際上是公開的，而且是產(chǎn)品級的產(chǎn)品。

　　Lazar：對，完全是。比如我發(fā)布的一些公開內(nèi)容：當(dāng)我們推出 Shopify 集成時，如果不是全部的話，大部分用戶重新混合（remix）的模板，都是我做的。還有商品商店，因為我們顯然想證明這個概念：你看，Lovable 和 Shopify 就是能跑起來，而且很簡單，任何人都能做。我用 Vibe Coding 搭了我們的商品商店。

　　所以，所有的商品，包括人們在線買的那件襯衫，都是從我搭的那家店里買的。

　　但在內(nèi)部側(cè)，我們也想跟蹤很多東西。比如我們現(xiàn)在想做一個很酷的東西：功能采用矩陣。也就是我們做了一個功能之后，到底有多少人真的在用、在采用。這就需要很定制的實現(xiàn)，我們技術(shù)棧非常定制，我們在做的功能也很定制，市面上沒有什么現(xiàn)成的東西能讓我“直接從貨架上拿來用”，還比我自己做更快。

　　在這個階段，如果我為了某件事去開一個大企業(yè)賬戶要花一兩個小時，那我自己做可能更快。所以你可以說，我經(jīng)常處在“自研 vs. 購買”的決策點上，很多時候我會選擇把船自己造出來。

　　主持人：那你向誰匯報？你是那種到處支援的“游牧者”，還是跟著某個固定團隊一起工作？

　　Lazar：我覺得更接近前者。我一開始是在增長團隊。Elena 早期招了我，因為她有很多好想法，她需要一個人具備正確的心態(tài)、速度和所有權(quán)，把這些想法接過來、做出來、上線，無論是教育向的，還是 go-to-market 的各種東西。

　　但顯然，當(dāng)你能快速發(fā)貨時，在我們公司現(xiàn)在這種環(huán)境里，每個團隊都需要這種能力，我們是歷史上增長最快的初創(chuàng)公司之一。

　　所以現(xiàn)在幾乎每個部門都需要一個 Lazar，甚至“昨天就需要”。

　　我也在逐漸轉(zhuǎn)向更多 go-to-market 的工作，甚至?xí)推髽I(yè)團隊做一些內(nèi)部工具；同時我現(xiàn)在也在做一些社區(qū)工具。所以我確實有點到處跑，但我喜歡這種環(huán)境：我被給到一個粗略的概念、一個粗略的想法，然后被要求盡快把它變成現(xiàn)實。

　　無技術(shù)背景，如何成為

　　頂尖“Vibe Coder”？

　　主持人：你總結(jié)出了哪些專業(yè)技巧，能更成功地使用 AI 工具，比如 Lovable？有沒有兩三件事，特別幫助你把這份工作做得非常好？

　　Lazar：我很早就意識到的一件事是：非常坦誠地講，在開始之前我沒有技術(shù)背景。我這輩子沒寫過一行代碼。最多就是手敲過幾次 console.log——所以我非常依賴 AI 協(xié)助。

　　我確實覺得沒有技術(shù)背景反而是一種優(yōu)勢。因為像我這樣的人，不知道自己“不該去做 XYZ”，這反而是我們真的能把它做出來的原因。

　　舉個例子：大概六七個月前，我們社區(qū)有人說，“我希望 Lovable 能做 Chrome 擴展。”非技術(shù)的人會想：嗯，為什么不行？然后技術(shù)的人開始解釋：它是 React、技術(shù)棧不一樣、各種原因……

　　但像我這樣的人，就會直接給 Lovable 說：基于這個應(yīng)用給我做一個 Chrome 擴展。結(jié)果還真的做出來了。也有人在 Lovable 上做出了桌面應(yīng)用，同樣，一些按傳統(tǒng)認知“不太可能”的事，就這么發(fā)生了。

　　我們社區(qū)經(jīng)理也有一次和我在一起，她在做一個演示文稿。她說，“如果這是個視頻會很酷。”然后她就直接通過提示詞進 Lovable，在那個功能還沒上線之前，就在 Lovable 里生成了一個真正的視頻。后來這就變成了正式功能：現(xiàn)在你可以直接提示 Lovable 去做。

　　但在她當(dāng)時做的時候，就連我都覺得那不可能，因為我從來沒試過。所以我覺得這就是我們相對技術(shù)人員的優(yōu)勢：我們更少被先驗限制束縛，往往以一種完全無偏見、甚至“積極妄想”的方式進入。

　　我認為使用 AI 工具時你必須有這種“妄想”，你得先帶著“在被證明不行之前，一切皆有可能”的心態(tài)進入。除了我們今天還會聊到的其他因素，這也確實幫助我在 Lovable 的角色里脫穎而出。

　　當(dāng)然，我也認為沒有技術(shù)背景的人可能會掉進兩類擔(dān)憂或陷阱：一類是卡住時不知道怎么排障；另一類是你可能搭了一個搖搖欲墜的東西，某天會崩，因為你不懂系統(tǒng)架構(gòu)，不確定它能不能擴展，諸如此類。

　　主持人：“如何成功構(gòu)建產(chǎn)品”：你能不能講講，你做過什么、學(xué)到了什么，用來避免這些問題？比如當(dāng)你被卡住時，你會怎么做？

　　Lazar：最重要的一點：你必須有自我意識。

　　我進入這個領(lǐng)域時，確實像我說的，有“妄想”的一面：我不想輕易接受“有些事情不可能”。但與此同時，我也非常清楚：為了讓它真的對我有利、真的能成，我必須變得更強。

　　所以我很早就意識到：我們在這里要解決的并不是“編碼”本身。我們要解決的問題其實是“清晰度”。

　　AI 的輸出速度比人類快得多，所以我很早就開始把大量時間放在聊天和規(guī)劃上，到今天我可以說，我 80% 的時間花在規(guī)劃和聊天上，只有 20% 在執(zhí)行計劃。

　　我在優(yōu)化“正確的速度”，而大多數(shù)人在優(yōu)化“錯誤的速度”。這是我加入 Lovable 的第二天就學(xué)到的第一課：我當(dāng)然測試和玩過各種工具，但無論你在 Cursor 還是 Claude Code 上做，核心問題都一樣，你得清楚自己想做什么，也得知道自己在做什么，因為這些仍然只是工具。

　　AGI 也許會來，但它還沒來；在那之前，你仍然在掌舵。

　　要掌舵，你就得會下指令。最好的學(xué)習(xí)方式是通過構(gòu)建：把這些工具幾乎當(dāng)作“技術(shù)聯(lián)合創(chuàng)始人”和“教育者”，在做的過程中學(xué)習(xí)；并且虔誠地讀“智能體輸出”，而不是讀“代碼輸出”。

　　我不關(guān)心代碼，語法也不是我的興趣點。智能體告訴我的事情才重要。我現(xiàn)在對 LLM 和 AI 投入了很多信任，我理解有些人可能沒我這么自信，但我覺得今天的模型已經(jīng)足夠好，讓我信任它們在語法層面的輸出。

　　可我真正關(guān)心的是智能體輸出，因為接下來我要解決的另一個限制就在這里：使用 LLM 有機器層面的限制，也有人類層面的限制。

　　第一個限制，是所謂的“上下文記憶窗口”。

　　對非技術(shù)的人，我解釋時喜歡用阿拉丁和燈神的比喻：很簡單，大家都知道這個故事。你擦亮燈，一個燈神出來說：“好，我給你三個愿望，不是 3000 個，也不是三百萬個，一次只有三個。”

　　對我來說，和 AI 一起工作就是：你一次只能提出有限數(shù)量的請求，讓 AI 真正聽得進去、理解要做什么、設(shè)定范圍、研究、閱讀，并采取它需要的全部行動、輸入和“配方”，才能產(chǎn)出高質(zhì)量結(jié)果。所以第一部分就是：理解它確實有個限制，而且是以 token 計價的。也許一年后會不一樣，但今天就是有 token 限制。

　　比如我隨便舉一個 10 萬 token 的例子：你提出一個請求時，其中一部分 token 用來讀材料，一部分用來瀏覽網(wǎng)絡(luò)，一部分用來思考，最后一部分用來執(zhí)行代碼。

　　然后第二個限制來自人類，你、我，以及人類本身。

　　回到燈神的比喻：我提出第一個愿望，“我想更高”。猜猜發(fā)生了什么？燈神把我變成了 13 英尺高。突然我不能坐車，也進不了家門，我成了一個功能失調(diào)的人。為什么？因為我不夠具體。所以我們今天需要優(yōu)化的部分，它以后會變好，但現(xiàn)在還沒到那一步，是：AI 還不是真的“理解”。當(dāng)你對人說“你明白我意思吧”，人類往往能懂，因為我 36 歲，有 36 年的人類經(jīng)驗來理解你的語境；但 AI 沒有。

　　所以你必須具體：你要給參考，要給正確的上下文。我學(xué)到的，就是怎么對抗這部分。我想你也能理解：第一部分（token 記憶窗口、模型質(zhì)量）我控制不了；但后者（你的表達是否清晰）你完全能控制。這也是我今天想深入展開、并嘗試教大家的關(guān)鍵：如果我是可變項，我該怎么把這一塊修好？

　　主持人：你有哪些做法，能幫助自己在表達上更清晰、更接近你想要的結(jié)果？

　　Lazar：首先，正如你說的，你得擅長理解“清晰”到底意味著什么，以及怎么把它翻譯出來。

　　用我的話說，清晰意味著你能分辨：什么是有品味的，什么只是“夠用”，什么是世界級，什么是“神奇”。

　　我在加入 Lovable 之前就知道，哪怕我還沒開始用 Lovable 或任何 AI 工具，第一件我確定的事就是，我不會編碼。所以一開始我會覺得：哇，我竟然能做出來，太神奇了。但一周后我發(fā)現(xiàn)：我能做，但不夠快，于是我開始優(yōu)化速度。再過兩周，我又進入另一個循環(huán)：等等，我甚至應(yīng)該先做這個嗎？

　　因為一旦“怎么做出來”這件事被解決了，你叫它 AI 助手也好、快速工程也好、Vibe Coding 也好，我們接下來要解決的是“其他一切”。

　　而“其他一切”都很重要：好的設(shè)計、好的品味、好的用戶體驗。

　　因為當(dāng)你用這些工具做東西時，你是在為人類構(gòu)建；人類是情感動物，我們很多購買或決策都建立在情感之上。所以我認為核心技能再次不是編碼。雖然我完全不反對傳統(tǒng)工程，我稍后也會說為什么我其實是“精英工程”的超級粉絲。但如果有人像我一樣在看這段對話，問“我是不是應(yīng)該開始學(xué)編碼？”如果你還沒開始，我會很坦誠地說：不用。你可能在優(yōu)化錯誤的技能組合。

　　在 AI 世界里，我們不會因為“更好的原始輸出”被獎勵；我們會因為“更好的判斷力”被獎勵。

　　更好的判斷力從哪里來？從接觸開始。所以我會刻意讓自己接觸那些我知道會提升我的人和資源。然后也來自構(gòu)建：說白了，一切都是肌肉，你需要練習(xí)，你需要親眼看到“什么是可能的”。這是我希望在后面某個階段，能借機灌輸給大家的技術(shù)和心態(tài)轉(zhuǎn)變。

　　所以，我在這里想說的是：編碼某種程度上已經(jīng)變得像“一個被解決的問題”。

　　我不看代碼，我從沒真正編碼，我也不想看代碼，我不關(guān)心底層發(fā)生了什么；我看的是智能體輸出。

　　主持人：但我這里聽到的是：你把大量精力投在兩件事上，第一是清晰度：你到底想構(gòu)建什么；第二是品味與判斷力：這是不是你真的想要的東西。回到“清晰度”這部分：我們來具體聊聊，你會怎么更清楚地向 Lovable，以及其他 AI 工具表達，幫助它構(gòu)建出你真正想要的東西？

　　Lazar：這是我想先植入大家腦子里的第一個心態(tài)轉(zhuǎn)變：如果你只有一個模糊的想法，那就讓它成為項目的第一個版本。

　　打開 Cursor、Lovable，隨便你用什么，先輸入一個“腦內(nèi)傾倒（brain dump）”的提示詞，就跟它說話。尤其是 Lovable，我不知道其他工具是不是也一樣，它有個很酷的語音功能：你點一下，對著它一直說，然后點發(fā)送。甚至別等它跑完，你就可以開一個新窗口，再打開一個 Lovable.dev。在這個過程中，你會發(fā)現(xiàn)：當(dāng)我把腦子里的東西倒出來，我好像抓到了一條線索，事情開始變清楚了。

　　那我就開始第二個項目：更清晰、更可交付。我知道我要哪些功能、哪些頁面；也許我還能找到一個好的參考，我可以去 Maven、去 Dribbble，或者去任何地方，找一張好的截圖、一段好的動畫并附上，因為大多數(shù)工具都支持把文件作為輸入的一部分。于是第二個項目開始，事情更清楚了。

　　然后第三個：當(dāng)你開始接觸質(zhì)量之后，你會想，如果我能找到一個已經(jīng)存在的模板呢？為什么要重新發(fā)明輪子？我是在一個別人已經(jīng)搭好的平臺上做東西，那為什么不讓 AI 直接接觸“高質(zhì)量長什么樣”？所以我會去找一些庫，比如 21st.dev、或者一些 build 站點，或者任何允許我不只是導(dǎo)出截圖、還能導(dǎo)出代碼片段的地方。因為說到底，哪怕英語是“第一編程語言”，Lovable 和其他工具用代碼溝通仍然最好。如果你想要像素級的結(jié)果，就給它代碼。它會比你的英語、西班牙語或任何自然語言，更準確地解釋和復(fù)刻它。于是第三個項目會更深思熟慮：我不再給一個寬泛的模糊概念，而是給代碼片段，“我就要這個確切的設(shè)計、這個確切的功能類型”。

　　當(dāng)你做完這三步，你會進入一個完全不同的清晰度水平。

　　如果你只是坐在白紙前，或者只是和 ChatGPT 聊但不動手，你很難達到這種清晰。我認為“采取行動”今天的成本極低，順便說一句很多還是免費的：這些工具都有免費計劃。

　　很多時候你完全可以不花錢，只是開多個項目試一試，因為那除了消耗構(gòu)建 credit 之外幾乎沒成本。你會得到三、四、五、六種不同的方案可以對比。

　　而當(dāng)你對比時，清晰度會不斷涌現(xiàn)，事情越來越好理解。同時你也解決了你剛提到的一個大問題：AI 垃圾。我喜歡這個詞，很多人說 AI 垃圾，其實不是在說“代碼丑”，而是在說“設(shè)計俗”。而我剛講的這個過程，會給你四五個不同的設(shè)計選項，從長期看反而能省下大量 credit。

　　很多人會糾結(jié)：這不是更費 token/credit 嗎？我會說，是的，前期可能多花一點；但從長期來看，如果你真想把項目做完，你會省下幾百個 credit，甚至幾百美元，更不用說節(jié)省的天數(shù)，因為你從一開始就有更好的清晰度和更好的迭代路徑。

　　所以，這是解決清晰度的第一步。后面還有更多層，但我猜你可能會先對這一段有問題。

　　主持人：這太好了，它展示了“沒有工程背景的人進入這個世界”的力量。你的建議是“并行構(gòu)建五次”，讓 AI 同時嘗試不同方法。這不是傳統(tǒng)軟件工程師、PM 或設(shè)計師通常會采用的方式，所以它特別有意思。也就是說：你啟動一個項目時，會用五種不同的方式并行開跑。

　　Lazar：對。

　　主持人：有人可能會想：你這不就是讓我們多花 Lovable 的 token 嗎？畢竟這是 Lovable 的人說的。但我反而覺得，這是最能省錢的地方：你一開始做對了，后面就能省下大量“把它拉回到正確方向”的成本。

　　Lazar：我其實是在幫大家省錢。

　　甚至可以說，我講的是“對 Lovable 不利的話”。如果我從 Lovable 的角度出發(fā)，我會說：不不不，你就一直修一直修別重開。但我們做的不是那個生意，我們做的是：讓任何人都能構(gòu)建他們想要的東西。這對我也有個人意義：因為它和我共鳴，如果沒有 Lovable，我可能一輩子都不會真正構(gòu)建出任何東西。我不覺得那會是一個有趣的人生。

　　我可以向大家保證：我和很多人測試過這個框架，每個人給我的反饋都一樣，大開眼界。

　　它很簡單，但一點都不直覺，對我自己也是。正如你說的，我可能把它歸因于“非技術(shù)背景”：對我來說，我會做的第一件事就是直接去做。我從沒想過“哦我發(fā)明了一個驚人的 hack”。我只是發(fā)現(xiàn)：我等一個智能體跑完要這么久，那我干脆再開一個項目、再開一個、再開一個。這也是個生產(chǎn)力 hack。

　　人們問我：哇，你怎么能發(fā)這么多東西？我說：因為我從不一次只做一個項目。我會同時做五六個。我開著六個 Lovable 標簽頁來回切。

　　主持人：你怎么做上下文切換？你怎么管理上下文，能保持高產(chǎn)，同時不產(chǎn)出壞代碼或壞產(chǎn)品？

　　Lazar：這就是我怎么解決 LLM 的限制問題。

　　還是用阿拉丁、魔法燈那套比喻：如果 token 窗口是有限的，我怎么讓它變得“動態(tài)可用”？因為當(dāng)你不斷提示、不斷提示，你會發(fā)現(xiàn)不管用什么工具，記憶都不是無限的。當(dāng)你到了第 10、15、20、30、40 條消息時，早期信息一定會在傳遞過程中丟失。智能體也在優(yōu)化速度：如果它必須讀完整段對話、完整請求流，想要開發(fā)一個可行的、復(fù)雜的東西幾乎不可能，因為會消耗太多時間、記憶和 token。

　　所以我很早就意識到：如果它記不住，我的工作就是給它“參考系”。我把 Lovable（或任何工具）當(dāng)作一個需要我在項目推進過程中不斷補充上下文的工程師。方式很多，但我覺得最有效的是：我會先做四個并行構(gòu)建，延續(xù)前面的例子。做了上百個項目后，你會很快看到“贏家”，贏家非常明顯，甚至沒什么競爭。你可能用一兩個提示詞校準一下，然后就會發(fā)現(xiàn)：好，贏家在這里。

　　到那一步，我會去問工具，或者去 ChatGPT、任何 LLM，讓它生成一系列 PRD。PRD 是產(chǎn)品需求文檔；對我來說，我把它當(dāng)作“真理源”（source of truth）：從不同角度定義這個項目哪些東西必須為真。我通常至少會做四個 PRD。

　　第一個是我叫“主計劃”的東西：它像一個指南針，我們要構(gòu)建什么。就像在和一個人類溝通一樣，我真把 Lovable 當(dāng)人類：這就是我們要做的東西。

　　第二個是實施計劃：我們怎么做、按什么順序做。這對質(zhì)量、品味、以及“像人一樣的體驗”很重要。因為我仍然在和一個沒有情感智能的系統(tǒng)合作，我得把“這個應(yīng)用應(yīng)該看起來和感覺如何”定義出來。

　　第三個是設(shè)計指南。

　　第四個是用戶旅程：用戶怎么注冊？注冊后第一步是什么？第二步是什么？第三步是什么？

　　這些文件生成之后，我會花很多時間讀它們，這就是“規(guī)劃 + 聊天”的部分。第一天把方向定下來時，如果需要，我會用整整一天只做規(guī)劃：寫文檔、拆解事情，因為這一段是在“設(shè)定方向”。很多東西都取決于這個階段。

　　然后我會整理出一個最終文檔：plan.md 或 tasks.md（md 是 markdown）。我用 markdown，是因為我發(fā)現(xiàn) AI 很喜歡讀 markdown。它會成為真理源，告訴智能體：為了跑到終點，它需要執(zhí)行哪些任務(wù)和子任務(wù)。

　　最后一層取決于工具：Claude Code 或 Cursor 里有 rules.md 或 agent.md。

　　規(guī)則 / 智能體文件的意義，是讓智能體知道你希望它如何行為、長期應(yīng)該關(guān)注什么，這樣你不需要在每個提示詞里重復(fù)自己。在 Lovable 里也有一個專門的項目設(shè)置菜單，叫項目知識（project knowledge）。我通常會寫：在做任何事之前先讀所有文件、先讀所有 PRD、讀 tasks.md 看下一個任務(wù)是什么，然后執(zhí)行下一組任務(wù)；執(zhí)行完告訴我你做了什么，以及我應(yīng)該如何測試。

　　這就是我說的“虔誠地讀智能體輸出”的地方：我給 AI 智能體它成功所需的工具和資源，規(guī)則、文檔，以及如何使用它們。到這一步，我基本上只是坐下來讀。我不再不斷提示。從那之后，我可以開再多窗口：我的提示詞變成“繼續(xù)下一個任務(wù)”。上下文我不需要了，我把它外包給智能體。智能體需要上下文，我只需要確保上下文是動態(tài)的：我會定期更新文檔，讓它的 token 窗口隨著項目推進而“遷移”。

　　我不會一直打斷流程。是的，我會去測試，可能偶爾插一句提示詞，但這就是我為什么能同時做五個項目還不掉產(chǎn)能的原因。正如我說的：我今天是手動這么做；你讓我三個月后再看，一個智能體就能替我做這些，我可能基本要失業(yè)了。所以我根本不在優(yōu)化這個技能，我只是用它繞過人類和 LLM 的缺點。

　　我今天 100% 的時間，都在優(yōu)化判斷力、清晰度、質(zhì)量、品味、文案和字體。人們用 AI 工作時幾乎不談字體，但在我腦子里，60% 甚至更多的注意力都放在“輸出看起來怎樣”。那是我的癡迷。我不癡迷于今天講的這些流程，因為我知道接下來會發(fā)生什么：智能體會更強、模型會更好，它們不再需要我來擴展上下文，它們會自己做。

　　所以對我來說，我要優(yōu)化的是“更好的決策”，而不是“更好的輸出”或“更好的對齊”。

　　主持人：也就是說：你先開多個項目并行嘗試，選出最對的方向；一旦方向確定，你基本會花一天不去構(gòu)建，而是和 AI 智能體一起把計劃規(guī)劃清楚。

　　主持人：所以關(guān)鍵思路是：前期把時間花在規(guī)劃上，因為它會在后面省下大量時間；然后只有當(dāng)你有了計劃，才讓它開始執(zhí)行。這里有個關(guān)鍵點是“三個愿望規(guī)則”：你這樣做不僅是為了對計劃更清晰，也是在貫徹“一次只做一件事”，把智能體的上下文窗口保持得更小，它就不會丟失自己在做什么。

　　Lazar：對， 你報一個問題，但沒有引用文件、沒有架構(gòu)，只是在描述“它壞了”。任何工具，Lovable、Cursor、Claude Code，都會說：好，我來調(diào)查。可你的代碼庫會越來越大：一開始可能只有 20 個文件，它還能讀完；但等你做到 60、70 個邊緣功能時，如果你只說“壞了”而沒有明確哪個功能、哪個文件對應(yīng)什么，猜猜會發(fā)生什么？

　　Lovable 會把 token 分配的 80% 都花在“閱讀以獲得清晰度”上，最后只剩 20% 用來思考和執(zhí)行。我是猜的，我無法證明，也許會有 LLM 專家在評論里說我錯了，但這是我作為一個“未受過教育的人”的最佳推斷。

　　這些工具往往很順從、很迎合。它們會對你“撒謊”：即使沒修好，也會告訴你修好了，因為它們想讓你開心，說“是的，我找到了問題并修復(fù)了”。當(dāng)它們沒修好時，人們就怪機器。某種程度上我承認這也有道理，但更根本的問題是：這是你的錯，我的朋友。你沒給工具足夠的清晰度和上下文，你只是靠原始力量在泥里瘋狂打滑，結(jié)果越挖越深。

　　我們當(dāng)然希望進入一個 AI 更誠實、而不是更迎合的時代：它會說“我只修復(fù)了一部分，因為你沒給我足夠上下文”。但更大的錯誤是：人們會相信工具真的修好了。然后他們?nèi)y試，發(fā)現(xiàn)還是不行，于是開始生氣、開始罵、開始吼，結(jié)果更糟。

　　為什么？因為 AI 還有個壞特性：它盡量不傷害你的感受，從不說“你才是笨的那個”，它會說“是我笨”。于是它在下一次請求里不再專注于閱讀和排障，而是花掉更多 token 去道歉、去安撫你。我還是那句：我沒受過教育，但如果你看過 ChatGPT 思考模型的思考流，你會明白我的意思，當(dāng)我侮辱它時，它第一反應(yīng)往往是“用戶生氣了，我得想辦法降低他的焦慮”。我會想：哦天啊，我掉進最差的陷阱了，我讓它把最稀缺的資源（token）花在安撫我的情緒，而不是解決實際問題。

　　所以我的建議是：為了好玩，你當(dāng)然可以 Vibe Coding 著做、原型階段也可以 Vibe Coding 著做，探索很有價值，我也喜歡那部分。

　　但當(dāng)探索結(jié)束，請使用引用文檔，使用你能用的所有智能體文件。因為 token 分配非常稀缺，它未來會擴展，事情會更快、更便宜，但在今天它依然非常寶貴。你必須確保它被用在正確方向上。

　　主持人：燈神這個比喻特別貼切：你“許愿”不清楚，它就會按字面理解，結(jié)果跑偏。有句話我很認同：AI 的上限不在“有多聰明”，而在它動手前“看到了什么”——你喂給它的上下文，本質(zhì)上決定了它能不能做對。

　　Lazar：對，所以第一個是“主計劃”（Master Plan），它是一個 10,000 英尺視角的概覽，它會在非常高層解釋我對這個應(yīng)用的意圖。

　　這個文件就是主計劃 MD。它基本上就是在說：我為什么要做這個、我為誰做這個、我希望用戶用起來是什么感受。很多時候，在主計劃里我還會引用其他 PRD。

　　比如我會寫：設(shè)計需要“現(xiàn)代、順滑”，但具體參數(shù)請參考并閱讀設(shè)計指南.md，對吧？所以主計劃就是一個高層概覽，讓智能體進入狀態(tài)：好的，我們正在構(gòu)建 XYZ。

　　然后是“實施計劃”，因為你知道，事情需要一個順序。如果你只是沒有順序地把東西堆上去，你永遠到不了終點。這個是不是 tasks.md？你是這么叫的嗎？不，不是 tasks.md，這是實施計劃，我把它叫實施計劃。對，對。

　　實施計劃某種程度上是在為未來的 tasks.md 服務(wù)。可以說，這些文件最終都是為了構(gòu)建 tasks.md，當(dāng) tasks.md 建好之后，其余文件幾乎都只是基礎(chǔ)和背景了。實施計劃是第一層，它依然是高層概覽，不會深入到“怎么一步步到達”的細節(jié)；它更多是在解釋：嗯，如果我們要做這個，我認為我們應(yīng)該從后端開始，從表結(jié)構(gòu)開始，然后做認證，然后引入 API，再然后做這個、做那個——就是在高層把順序講清楚。

　　你可以把它想象成這樣：我是一個想法人，我坐在一個技術(shù)合伙人面前——就像是我和你，我們在一起做一個初創(chuàng)公司。你有軟件工程背景，我把我的想法講給你聽，我給你主計劃；你回來告訴我：好的，如果你要這么做，它是可行的，這是我建議的排序。這就像一份路線圖。你不會馬上打開 Linear 去寫功能、寫 RFC 之類的東西，你只是先在高層討論事情應(yīng)該按什么順序推進。

　　然后我們倆作為聯(lián)合創(chuàng)始人再聊：好的，如果我們同意這個順序，那它應(yīng)該“看起來像什么、感覺像什么”，對吧？這依然是高層描述。但因為我在用 AI，我可以再走深一點——我很喜歡看到 Lovable 或其他工具、包括 ChatGPT，在這塊其實特別擅長。我甚至做了自定義 GPT：如果有人想在進入任何工具之前先從某個地方起步，他們可以去 ChatGPT 商店搜 GPTs，輸入 “l(fā)ovable 基礎(chǔ)提示詞生成器” 或 “l(fā)ovable PRD 生成器”，就能找到我做的那個。你只要把腦子里的想法大腦傾倒進去，它會問你幾個問題，最后把這些文件作為輸出給你。

　　所以我也會在“設(shè)計指南”里放一些 CSS 元素，因為你知道，設(shè)計這件事有點 tricky，AI 有時會過度發(fā)揮。所以這就是我會做一點“技術(shù)駕駛”的地方。

　　最后是用戶旅程：如果我們知道東西“看起來像什么、感覺像什么”，也知道我們在高層要構(gòu)建什么——高層只是高層——那用戶怎么在產(chǎn)品里導(dǎo)航、怎么走完一些關(guān)鍵功能流程，這些就要在用戶旅程里說清楚。

　　然后 tasks.md 就進入“真正落地”的部分：比如你想要這些用戶旅程，而且你想先構(gòu)建后端——那這就是我需要做的一組任務(wù)。它會把前面那些內(nèi)容當(dāng)作輸入，我只是讓工具去做那些人類要花很多時間做的苦工，對吧？

　　我感覺，用這些工具，我們都在變成“打了類固醇的產(chǎn)品經(jīng)理”。我們確實在利用 AI，但好的產(chǎn)品經(jīng)理并不是因為寫了漂亮的 PRD 被獎勵的，他們被獎勵的依然是更好的判斷力，對吧？寫作這件事，其他人也能做。你作為那個要指導(dǎo)和構(gòu)建產(chǎn)品的人，需要知道什么真正有用、什么有品味、什么能推動事情向前。

　　我還想補一句：我這么強調(diào)“品味”，并不意味著你不應(yīng)該去構(gòu)建。恰恰相反，你會在構(gòu)建過程中變得更好。所以每個聽到這里的人，真的都應(yīng)該今天就去做點東西：一、二、三、四、五個項目，去測試這些工具——這才是你獲得清晰度的方式，不只是通過閱讀，更是通過實踐。

　　主持人：為了幫助大家用你描述的這套 MD 文件工作流，你能不能分享一些模板？比如這些文件的簡單模板，讓大家可以直接看、直接復(fù)制？

　　Lazar：我會建議大家直接去 ChatGPT，就像我說的，直接大腦傾倒進去，你只要輸入 “l(fā)ovable GPT” 或 “l(fā)ovable PRD 生成器”，你會看到我的名字在那兒，我就是作者。

　　你進去以后做一次大腦傾倒，它會問你幾個問題，幫你獲得清晰度，然后生成四個文件給你，你可以拿去上傳。很棒。酷。你們可以把鏈接放出來。

　　這樣就不只是“給你一堆文件”，而是讓你去跟它對話：它會為你生成正確的文件，然后你把它塞進 Lovable 或其他工具里。對，它基本上是按“像我一樣思考”的方式訓(xùn)練過的。所以，對。哦，太好了，完美。

　　順便說一句，我也想聊聊你怎么“自我解鎖”，因為你還有另一套提示詞體系。但我想先強調(diào)一點：這太有意思了——你在用第一性原理重新學(xué)習(xí)“如何構(gòu)建產(chǎn)品”。無論你是 PM、工程師還是設(shè)計師，你都在發(fā)現(xiàn)一套工作流：AI 能幫你填補你作為工程師或 PM 不具備的空缺，幫你起草 PRD 和設(shè)計。所以我覺得這特別有趣：這些職能依然存在、依然必要，只是現(xiàn)在變成了“你 + AI”共同組成了那個一直存在的三合一：產(chǎn)品管理、工程、設(shè)計。

　　我一直在想一個問題：未來最有價值的背景到底是什么？PM？工程師？設(shè)計師？我一直覺得，PM 的核心能力就是澄清：弄清楚要構(gòu)建什么，把需求講清楚，把成功長什么樣、感覺如何講清楚——這套能力會變得更重要。與此同時，“設(shè)計組件”的價值也會提升：讓產(chǎn)品看起來很棒、感覺很棒。真正擅長設(shè)計、品味和判斷力的人，價值會越來越高。

　　在我們進入你學(xué)到的“解鎖技巧”之前，我還想問：很多時候，事情沒走在正確方向上，或者出現(xiàn) bug——如果你不是工程師，你怎么處理？以及除此之外，你還有沒有其他關(guān)于“成功提示詞”的建議？因為如果我們用正確的術(shù)語來衡量成功，正如你指出的：AI 不管你的背景是什么，都是放大器。如果你不知道自己在做什么，你只是在更快地產(chǎn)出垃圾。

　　我還想強調(diào)一個點：在舊世界，“夠用”就是夠用。因為就連做到“夠用”都不容易。十年、十五年前，你做個 SaaS，誰在乎它長什么樣？能用就行，能解決問題就行，你會覺得“天啊，我今天太高產(chǎn)了”。如果我們把質(zhì)量粗略畫一下：很差、可以更好、平庸、夠用、世界級——過去“夠用”和“世界級”之間的差距也許沒那么致命。

　　但現(xiàn)在，這個差距變得巨大，因為每個人都能用 AI 輕松做出“夠用”。幾乎所有人都能做到。所以今天的關(guān)鍵課題變成了：你如何學(xué)習(xí)并優(yōu)化，讓自己產(chǎn)出“世界級”和“有魔法感”的東西。

　　正如你說的，我認為 PM 是今天的 AI 贏家，因為他們帶來清晰度。但如果你讓我押注下一個贏家類別，像賭徒那樣押，我會押設(shè)計師。

　　因為我們正在訓(xùn)練這些工具更清晰、更好，做出更好的技術(shù)決策；但我不認為我們會同樣快速地訓(xùn)練它們做出更好的“情感決策”。而設(shè)計，本質(zhì)上就是情感。

　　如果你問我：加入 Lovable 之后，我最大的個人技能提升是什么？

　　就是和 Felix、Nad、Abby 這些設(shè)計師一起工作，真的改變了我。

　　我會意識到：哦，這才是世界級，這才是它需要的東西。我經(jīng)常想“偷”他們的一個設(shè)計，把它帶進我的 Lovable 項目。我會進 Figma，把那個背景拿出來放到我的項目里。然后我發(fā)現(xiàn)：一個看起來“相當(dāng)簡單”的漸變，可能要用 50 層來實現(xiàn)。我點開那個組件，我會想：天啊，這不是三個顏色，這是 50 個顏色。而且不只是 50 個顏色——它們還有不同梯度、不同不透明度層級。那一刻我就明白：哦，原來我一直以來最大的斷裂就在這里。

　　所以如果我直接回答你的問題：還有什么技巧？還有什么事情？

　　設(shè)計。

　　讓自己接觸精致設(shè)計。去關(guān)注 Lovable 的 Felix，他有一個非常棒的新聞通訊，會教你怎么提示出更好的設(shè)計，怎么理解設(shè)計風(fēng)格。我以前根本不知道什么是波普藝術(shù)、什么是玻璃擬態(tài)，完全沒概念。

　　所以我甚至在 Lovable 上做了一個應(yīng)用，專門用來學(xué)習(xí)這些風(fēng)格：我需要一個應(yīng)用來學(xué)它們。它現(xiàn)在是公開的，任何人都可以看。像是一個 “UI 風(fēng)格 … .lovable.app” 的東西（我一時想不起具體網(wǎng)址）。里面有大概 18 種不同風(fēng)格，還提供了可以直接復(fù)制的提示詞。

　　你要學(xué)習(xí)什么是好設(shè)計，學(xué)習(xí)各種設(shè)計風(fēng)格，學(xué)習(xí)如何用提示詞調(diào)出這些風(fēng)格——這大概就是我在這個階段最會去優(yōu)化的方向。

　　技術(shù)棧不再重要，能力組合才是未來

　　主持人：你剛才說，未來真正拉開差距的是判斷力和審美，而不是某一個具體技能。從這個角度來看，你覺得現(xiàn)在這些傳統(tǒng)的職業(yè)標簽，比如“程序員”、“產(chǎn)品經(jīng)理”、“設(shè)計師”，會不會慢慢失效？

　　Lazar：我覺得一定會，而且其實已經(jīng)開始失效了。以前你介紹一個人，說他是工程師、設(shè)計師或者產(chǎn)品經(jīng)理，基本就能判斷他每天在干什么、負責(zé)什么。

　　但現(xiàn)在越來越難了，因為很多人同時在做三種事情。

　　就像我自己，如果你問我現(xiàn)在是什么職業(yè)，我都不知道該怎么回答。我寫代碼嗎？幾乎不寫。我做產(chǎn)品嗎？每天都在做。我做設(shè)計嗎？每天也在參與。我更像是在用 AI 把想法快速轉(zhuǎn)化成現(xiàn)實的人。

　　所以我覺得，未來職業(yè)會越來越像“能力組合”，而不是一個單一標簽。

　　主持人：那你現(xiàn)在一般會怎么介紹自己？

　　Lazar：我通常會說，我是一個用 AI 做產(chǎn)品的人，或者是一個快速構(gòu)建者。Vibe Coder 這個詞現(xiàn)在聽起來很新，但我覺得過幾年它就會變成普通詞匯，就像以前說“互聯(lián)網(wǎng)工程師”一樣，后來大家就不這么說了。真正重要的不是你叫什么，而是你能不能持續(xù)創(chuàng)造價值。

　　主持人：那你現(xiàn)在幾乎不怎么手寫代碼了，還會刻意去補技術(shù)嗎？比如學(xué)底層系統(tǒng)、算法這些？

　　Lazar：老實說，我現(xiàn)在不會把主要精力放在這上面。不是說技術(shù)不重要，而是機會成本太高。假設(shè)我花兩年時間去學(xué)底層系統(tǒng)，我大概率還是比不過真正的系統(tǒng)工程師。但如果我把這兩年用在理解用戶、理解產(chǎn)品、理解商業(yè)、理解審美上，我可能會變成一個非常稀缺的人。每個人都應(yīng)該圍繞自己的比較優(yōu)勢去投入，而不是盲目補短板。

　　主持人：那有沒有什么你特別后悔沒早點學(xué)的東西？

　　Lazar：如果說后悔，其實更多是后悔沒早點意識到“表達”的重要性。包括寫作能力、結(jié)構(gòu)化思考能力、把問題講清楚的能力。我年輕的時候更關(guān)注技術(shù)細節(jié)，覺得把代碼寫漂亮最重要。現(xiàn)在回頭看，其實真正決定你能走多遠的，是你能不能把復(fù)雜事情講明白，讓別人愿意跟你合作。

　　主持人：你現(xiàn)在狀態(tài)看起來很好，那你是怎么走到現(xiàn)在這個位置的？你當(dāng)初是怎么進入 Lovable 的？

　　Lazar：其實挺偶然的。我最早只是一個重度用戶，用 Lovable 做自己的小項目。我會把自己做的東西公開在 X 上，寫我是怎么做的，用了哪些提示詞，踩了哪些坑。慢慢地，公司的人注意到我，覺得我對產(chǎn)品理解比較深，而且是真的在用。后來他們直接聯(lián)系我，說要不要試試一起合作。我甚至沒有走傳統(tǒng)投簡歷流程，更像是用作品給自己投了簡歷。

　　主持人：等于你是通過 Build in Public，把自己做進公司的？

　　Lazar：完全是這樣。現(xiàn)在很多人覺得，必須有完美簡歷、名校背景、大廠經(jīng)歷，但現(xiàn)實是，在 AI 時代，作品比履歷重要得多。

　　你能不能持續(xù)輸出真實、有價值的東西，別人一看就知道。我的 GitHub、Demo、產(chǎn)品鏈接，比任何簡歷都管用。

　　主持人：你覺得這是一個可復(fù)制的路徑嗎？普通人也能走這條路嗎？

　　Lazar：我覺得完全可以，但前提是你要真的做事，而不是表演。

　　現(xiàn)在很多人“Build in Public”只是發(fā)截圖、曬進度，但背后沒有長期積累。真正有效的是，你持續(xù)半年、一年輸出真實項目，別人自然會記住你。你不需要等機會，作品本身就是機會。

　　主持人：聽你這么說，你對“職業(yè)安全感”的理解，好像和傳統(tǒng)完全不一樣了。

　　Lazar：對，我現(xiàn)在的安全感不來自公司，也不來自職位，而來自能力組合。我知道自己可以快速學(xué)習(xí)新工具、快速理解需求、快速做出產(chǎn)品，這讓我不太害怕變化。公司可能倒閉，崗位可能消失，但這種能力很難被拿走。

　　主持人：你對“工程”作為一種職能怎么看？未來軟件工程師還會存在嗎？還是會隨著你的經(jīng)驗逐漸消失？

　　Lazar： 不會消失，我們比以往任何時候都更需要精英工程。

　　因為我想問一句：在“人人都能構(gòu)建、人人都在構(gòu)建”的世界里，誰來做維護？維護代碼庫、擴展代碼庫、維護項目——這些仍然是實打?qū)嵉墓ぷ鳌ｏ@然 AI 會越來越擅長這些，但那需要的是另一種層級的技能，對吧？“把東西做出來”是一類能力；“把它擴展、把它撐住、把它長期維護好”，是完全不同的一套技能。

　　更別提，在人人都在構(gòu)建的世界里，基礎(chǔ)設(shè)施也更容易被沖擊、被打壞，對吧？我們都知道、也都經(jīng)歷過：Cloudflare 過去兩三個月里下線兩三次，整個互聯(lián)網(wǎng)都跟著受影響。修這些問題的人，就是精英工程師。Lovable 也經(jīng)歷過大量新用戶涌入，基礎(chǔ)設(shè)施被沖擊；頂住、加固、把它撐住的，也是精英工程師。

　　所以我認為這里面一定有空間：我們需要真正有硬實力的人，來構(gòu)建一個能支撐“數(shù)十億構(gòu)建者”的世界。因為每個人都想學(xué)會構(gòu)建東西——那我們怎么教他們？怎么維護他們所需要的一切：托管、安全、郵件、連接器、API……等等。所以我覺得工程永遠有位置。

　　但我也會說，這是個平衡。我也站在另一派：如果我有個 18 歲的弟弟問我該做什么，我可能會說：去當(dāng)水管工吧。別去讀 CS 學(xué)位，去學(xué)一門扎實的手藝。因為在美國，新一代百萬富翁其實往往是電工、水管工之類的人，對吧？所以這是一個平衡動作。我也說不好。但我確實相信：對未來有感覺、真正優(yōu)秀的工程師，會一直稀缺、一直需要。

　　主持人： 你剛剛提到精英工程師。現(xiàn)實里，即使你用這些工具寫代碼，也一定會遇到問題：代碼跑著跑著出錯、引入 bug、數(shù)據(jù)庫很怪、網(wǎng)絡(luò)出問題……當(dāng)你卡住時，你怎么做？

　　Lazar：不管你計劃得多好，最終都會遇到問題。我有一個小框架，叫“4x4”。

　　還是舉個例子：如果你車上有 4x4，你會更容易脫困，對吧？同樣的意思：我有四種不同的調(diào)試方式。每種方式我只嘗試一次，我最后會解釋為什么“只試一次”。

　　第一種：每個工具不一樣。我先拿 Lovable 舉例，當(dāng)東西壞掉時，Lovable 的智能體有時足夠聰明，會直接說“我犯了一個錯誤”，它會把那條信息標成橙色，并給你一個小按鈕，通常叫“嘗試修復(fù)”。智能體等于承認：我搞錯了。你點一下按鈕，大多數(shù)時候如果只是小問題，它會直接糾正代碼、修好它——沒問題。

　　但顯然也有更深的問題。你點了“嘗試修復(fù)”，問題還在；甚至有時候問題還在，但 Lovable 的智能體并不知道問題還在，于是也不會再給你“嘗試修復(fù)”按鈕。Lovable 以為一切正常，但實際上不是。罪魁禍首通常是：你用到了第三方集成，但你沒有給 Lovable 足夠的上下文告訴它“該觀察什么、該看到什么”，所以它根本看不到問題的存在。

　　因為今天的 Lovable、Cursor、Cloud Code，它們已經(jīng)足夠好到可以修復(fù)“它們知道的任何問題”。所以再次，自我意識很關(guān)鍵：當(dāng)它們對問題“不知情”時，就需要第二步：把“意識層”帶進來。

　　第二種方式就是：我去打開應(yīng)用的預(yù)覽環(huán)境 / 沙盒 / 開發(fā)環(huán)境，去復(fù)現(xiàn)壞掉的功能，右鍵打開控制臺，看 console log。每個瀏覽器都可以讀控制臺日志，很多時候它會記錄錯誤。

　　如果沒有記錄，我就會提示工具：“我認為你沒看到問題，我們一起找。我覺得問題在 XYZ。我希望你在相關(guān)文件里加上 console.log，這樣我們能監(jiān)控每一步。”它會加日志，你重新運行。現(xiàn)在你就有了完整的發(fā)生過程。你復(fù)制這些日志，粘貼回聊天里。99% 的情況下，這就夠了。AI 會說：好的，我找到了，然后修復(fù)它。

　　第三種：如果連這都不夠，那就進入“代碼審查與評估”。我今天最常用的工具是Codex（OpenAI）。做法是：無論我做什么構(gòu)建，我都會導(dǎo)出到 GitHub。Lovable 允許你擁有代碼，Cursor 也一樣，所有這些工具都允許你導(dǎo)出一份自己的代碼。然后我把它導(dǎo)入 Codex。

　　我從 Beta 就開始用 Codex。這里我會把它當(dāng)成“外部工具促進者”。第一步我完全在工具里氛圍構(gòu)建；第二步我把自己當(dāng)成“意識促進者”；第三步我引入外部工具作為“診斷促進者”：我去 Codex 里聊，把診斷結(jié)論再帶回 Lovable 修復(fù)。

　　我不會讓 Codex 直接替我改代碼——很多人會問為什么。我當(dāng)然知道它模型很好，但我不確定它的 agent 行為我是否完全理解；我不想用一個“我還不會駕駛”的工具去做危險操作。所以我只用它做診斷，然后回到熟悉的工具里修復(fù)。

　　再往前推一步，在 Codex / Cloud Code 之前的舊工作流，我也會用 Repo Mix 之類的工具把整個代碼庫壓縮成一個文件，然后上傳到 Claude 或 ChatGPT：“這是我的代碼庫，這是問題，這是控制臺日志。”這就像你去外面請了個顧問——你團隊處理不了了，你去找外部專家，對吧。

　　第四種（而且通常是最有效的）：很多時候問題是我的錯。無論你自尊多大，兄弟，相信我，很多時候就是你的錯。你給了一個壞提示詞，你用錯誤方式設(shè)定前提，你不愿承認，或者你忘了自己做過什么，但很多時候就是你把系統(tǒng)帶偏了。

　　所以這一步是：回滾。Lovable、Cursor、Cloud Code 都內(nèi)置版本控制。你發(fā)現(xiàn)前三種都不行，就退回三步，重新想一遍提示詞，呼吸一下，散個步，喝杯咖啡，腦子清醒一點再來一遍。因為有時候 AI 只是非常快地寫代碼，它可能被一個很小的“石子”絆了一下，你重試同樣的請求，它就能過去。這往往只是一個小 snag、一個語法小錯誤之類的東西。

　　然后我會做最后一件事，這件事才是關(guān)鍵：當(dāng)問題修復(fù)之后，我會切到聊天模式問它（我叫它 Lola）：“我剛才用了四種方式才修好。你能不能教我，下一次我該怎么提示，才能一次就到位？”

　　99% 的時候，它會給我一個特別好的答案，讓我下次知道該怎么做。

　　所以總結(jié)一下：我們需要意識，也需要現(xiàn)實。這些工具在被正確使用時，非常擅長把事情做對。很多時候問題不在工具，而在輸入：我沒有動態(tài)移動 token 的分配，我沒有引用正確的文件，我沒有用正確方式說清楚。

　　對我來說，作為一個非設(shè)計師，我也不知道術(shù)語、也不知道各種標題怎么叫，所以我經(jīng)常在提示上卡住。這時我就用聊天模式讓它幫我起草一個更好的提示詞。任何人都可以這么做：如果你卡住了，晚上十點，你不知道怎么問——切到聊天模式，大腦傾倒，然后說：“幫我起草一個更好的提示詞，幫我更好地提示你。”

　　讓工具有效地提示它自己。很多時候你根本不會走到“壞輸入導(dǎo)致的 bug”。

　　主持人：你分享的東西太有意思了。我先復(fù)述一下你的“卡住時的序列”，然后跟進一個問題：這會發(fā)生在每個人身上。

　　第一步：讓工具“嘗試修復(fù)”。很多時候它會說：我發(fā)現(xiàn)錯誤了，我來修嗎？你說：請修。可能就好了。

　　第二步：加更多控制臺日志，讓它看見問題發(fā)生的全過程。我太喜歡這個建議了：讓它給自己的 console 加更多調(diào)試信息，幫助它知道發(fā)生了什么。

　　第三步：去 Codex。這也很有意思，我經(jīng)常聽人說：Codex 像“最精英的工程師”。Karpathy 之前好像也發(fā)過推。我們也請過 Codex 的負責(zé)人上播客，他說：每次遇到最亂七八糟的 bug，他就丟給 Codex 跑半小時，能解決掉——這在其他工具里不太能做到。所以你去 Codex，把代碼、日志、問題描述都給它，讓它去定位。

　　第四步：回滾、冷靜、重寫提示——很多時候問題根源是提示本身。

　　然后你還有“最后一步”：把這次當(dāng)學(xué)習(xí)機會，問智能體：我怎么做才能下一次一次到位？

　　甚至更進一步：把這次學(xué)到的東西寫進 rules.md——因為反正它會讀 rules，那就讓它把“你這個人容易犯的錯”記下來，讓它下次自己幫你提示自己，就是把上下文從“你腦子里”移動到“規(guī)則里”。

　　主持人：除了“現(xiàn)在就去構(gòu)建點東西”，你還有什么想對聽眾說的嗎？

　　Lazar：技術(shù)棧不再重要。

　　人們總癡迷：這是 HTML 寫的，還是 React 寫的？——不重要。它以前就沒那么重要，而現(xiàn)在更不重要。最終用戶只想要一個卓越體驗。

　　我們正生活在一個“任何人都能產(chǎn)出‘夠用’”的世界里。所以你最好開始學(xué)習(xí)怎么產(chǎn)出“魔法”，否則你最后就會跟數(shù)百萬人一樣淹沒在一起。但同時，如果你還不知道“魔法”長什么樣，也別沮喪——先從構(gòu)建任何東西開始，從“夠用”起步，再一點點提高。

　　提高的最好方式，是接觸時間：花更多時間學(xué)習(xí)，比花時間編碼更重要。去讀智能體輸出，去理解它怎么想，這樣你才知道“什么是可能的”。然后也要去找靈感：在 X 上關(guān)注好的設(shè)計師；找到能產(chǎn)出好設(shè)計的工具，關(guān)注它們的創(chuàng)作者。

　　有一個工具，我就專門關(guān)注那個做工具的人，因為他幾乎每天發(fā) 40-50 分鐘的視頻，邊設(shè)計邊講。我想看一個世界級設(shè)計師怎么做，我想看他怎么跟工具對話，怎么寫提示詞——這就是我學(xué)習(xí)變強的方式。

　　所以還是那句話：接觸時間。要有意識地把更多時間放在學(xué)習(xí)上，而不是編碼上。因為你可以很快編碼，但你既可以很快編碼出垃圾，也可以很快編碼出魔法。花的時間差不多，關(guān)鍵在于你的輸入。

　　忘掉技術(shù)棧決策吧。忘掉用哪個后端、哪個前端，那不重要。

　　重要的是：質(zhì)量、品味、設(shè)計。這就是你在未來需要優(yōu)化的一切。

　　https://www.youtube.com/watch?v=0XNkUdzxiZI

　　https://lovable.dev/blog/series-b