不會寫程式的人，如何靠 Vibe Coding 拿到正職？Lovable 首位「氛圍工程師」的實戰方法論

本文整理自《Lenny’s Podcast》2026 年 2 月播出的單集。

一個從沒寫過程式的人，怎麼成為全職工程師

2025 年 2 月，前 Tesla AI 總監 Andrej Karpathy 在 X 上隨手發了一則貼文，描述他用 AI 寫程式的體驗，創造了「vibe coding」這個詞。一年後，這個詞不只進了維基百科，還變成了一種正式職稱。

Lazar Jovanovic 是 AI 開發平台 Lovable 的第一位「Vibe Coding Engineer」。他的背景是林業工程，從來沒寫過程式碼（除了幾行 console.log），卻負責替這家估值 66 億美元的新創公司打造內部和外部產品。他最近上了知名科技 Podcast 主持人 Lenny Rachitsky 的節目，分享他如何用 AI 工具從零建構產品的完整方法論。

這不是一個「AI 好厲害」的故事。Lazar 在訪談中反覆強調的核心訊息是：AI 只是放大器，如果你不知道自己在做什麼，你只會更快地生產垃圾。真正的瓶頸不是寫程式，而是「清晰度」。你能不能把腦中模糊的想法，轉化成 AI 能理解、能執行的具體指令？這才是決勝點。

80/20 法則：八成時間不寫程式

多數人拿到 AI 工具後的第一反應是「趕快開始建」。Lazar 的做法剛好相反。他說自己 80% 的時間花在規劃和對話，只有 20% 在實際執行。

這個比例聽起來違反直覺，但背後有務實的理由。AI 模型有 token 上限，它的「記憶體」不是無限的。當你一路 prompt 下去，到了第十幾、二十幾則訊息的時候，早期的指令就開始從模型的注意力中消失。如果你在這個階段才發現方向不對，前面花的所有 token 都浪費了。

Lazar 用一個精準的比喻來解釋：把 AI 想成阿拉丁的神燈精靈，它只能幫你實現有限的願望。你的第一個願望如果是「我想變高」，精靈可能讓你變成四公尺高，你連家門都進不去。問題不是精靈不夠強，是你的願望不夠精確。所以真正該最佳化的不是 AI 的速度，而是你自己的清晰度。

他用一句話總結：大多數人在最佳化錯誤的速度。他們追求更快地產出程式碼，但真正該追求的是更好的判斷力。

平行原型法：同時開五六個專案

這是 Lazar 最反直覺的做法。當他有一個模糊的點子時，他不會坐下來想清楚再動手，而是直接打開五六個分頁，同時啟動多個版本。

第一個專案是純粹的腦力傾倒。打開 Lovable（或任何 AI 開發工具），用語音或文字把腦中所有想法一股腦丟進去，不修飾、不整理，按下送出就好。第二個專案比較有方向了：從第一個版本裡抓到一條值得發展的線索，加上更具體的功能描述和頁面規劃，也許還附上從 Dribbble 或 Mobbin 找來的設計參考圖。第三個專案更精準，直接去 21st.dev 或類似的元件庫抓程式碼片段餵給 AI，因為雖然自然語言是最方便的輸入方式，AI 讀程式碼還是比讀中文或英文描述來得精準。

到了這一步，你手上已經有三到五個不同方向的原型。哪個版本的設計最好、哪個方向最有潛力，一目了然。這個過程不只幫你釐清想法，還同時解決了「AI 美感不足」的問題，因為你有多個版本可以比較，不會被第一版的設計綁住。

有人質疑這樣做不是浪費資源嗎？Lazar 的回答是：表面上多花了一些 token，但長遠來看省下大量修改成本。因為如果你在錯誤的方向上深入開發，回頭重來的代價遠比多開幾個原型高得多。

PRD 文件系統：讓 AI 自己管理上下文

當平行原型中的「贏家」浮現後，Lazar 會進入他工作流程中最關鍵的階段：文件規劃。他會花上一整天的時間，不寫任何程式碼，只做一件事，用 AI 產生一系列 PRD（專案需求文件）。

他的文件系統通常包含四到五個 Markdown 檔案。第一個是 masterplan.md，這是一萬英尺高度的鳥瞰圖，說明這個產品為什麼要做、為誰而做、希望使用者有什麼感受。第二個是 implementation plan，定義開發順序，例如先做後端資料庫、再做認證、然後串接 API，最後做前端介面。第三個是 design guidelines，包含具體的 CSS 參數，因為 AI 有時候會「過度創意」，需要明確的設計柵欄。第四個是 user journey，描述使用者從註冊到完成核心操作的每一步。

這四份文件最終會彙整成一份 tasks.md，把所有待辦事項拆解成具體的任務和子任務。Lazar 說，一旦 tasks.md 建好，其他文件就變成參考資料了，因為 AI 只需要讀取任務清單，就知道下一步該做什麼。

最後一塊拼圖是 rules.md（在不同工具中可能叫 agent.md 或 project knowledge），這份文件告訴 AI 在執行任務前必須先讀完所有 PRD，完成後要回報做了什麼、測試結果如何。有了這套系統，Lazar 的 prompt 從長篇大論變成一句話：「繼續執行下一個任務。」他不需要記住上下文，因為上下文全部存在文件裡，由 AI 自己管理。

這也是他能同時推進五六個專案而不混亂的秘訣。每個專案都有自己的文件系統，切換視窗時不需要重新建立 context，AI 讀完文件就能接著做。

4x4 除錯框架：四種方法各試一次

不管規劃多完善，開發過程一定會遇到 bug。Lazar 發展出一套他稱為「4x4」的除錯框架，取名來自越野車的四輪驅動，意思是讓你更容易脫困。

四個步驟，每個只嘗試一次。第一步是讓工具自己修。Lovable 的 agent 夠聰明，會偵測到錯誤並標記為橘色，通常會附上一個「嘗試修復」的按鈕。小問題按一下就解決了。但如果問題比較深層，agent 可能修不好，甚至以為自己修好了，實際上問題還在。

第二步是手動帶入意識層。打開瀏覽器的開發者工具，執行出問題的功能，把 console log 複製下來。或者直接叫 AI 在相關檔案裡加入 console.log，讓每一步的執行過程都有紀錄。把這些紀錄貼回聊天視窗，大約八成的問題到這裡就能解決，因為 AI 終於「看到」了問題的全貌。

第三步是找外援。Lazar 的首選是 OpenAI 的 Codex。他會把程式碼匯出到 GitHub，然後在 Codex 裡做診斷，但只拿來診斷，不讓 Codex 直接改程式碼，因為他不夠熟悉那個 agent 的行為模式。另一個方法是用 RepoMix 把整個程式碼庫壓縮成單一檔案，丟進 Claude 或 ChatGPT 做程式碼審查，就像請外部顧問看一下。

第四步是承認自己寫了爛 prompt。Lazar 說，不管你的自尊心有多高，問題幾乎都是你自己造成的。這時候該做的是回滾到之前的版本，喝杯咖啡，出去走一走，回來之後重新想一下 prompt 怎麼寫。AI 寫程式碼的速度很快，有時候就是踩到一個小石頭跌倒了，重跑一次可能就沒事。

但整套流程最精華的部分是最後一步：問題修好之後，切到聊天模式問 AI，「我剛才花了四種方法才修好這個問題，你能教我怎麼更好地提示你，讓下次一步到位嗎？」AI 給出的回答通常非常實用。然後把這些學到的東西寫進 rules.md，這樣 AI 下次就會自動避開同樣的坑。

為什麼「不懂技術」反而是優勢

Lazar 反覆強調一個有趣的觀點：不懂程式碼的人在 AI 開發上有一種獨特的優勢，他稱之為「正面的妄想」。

他舉了一個例子。幾個月前，Lovable 社群裡有人說「要是能用 Lovable 做 Chrome 擴充功能就好了」。技術背景的人立刻解釋為什麼不行：React 和 Chrome extension 是不同的架構、不同的 stack。但像 Lazar 這樣不懂技術的人，根本不知道「不應該可以」，所以他直接在 Lovable 裡打了「幫我做一個 Chrome 擴充功能」，然後它就做出來了。同樣的故事也發生在桌面應用程式和影片生成上，都是「不該可行」的事，被不知道這個限制的人做出來了。

這不是在說技術知識沒用。Lazar 很明確地說，精英工程師在 AI 時代只會更重要，因為當所有人都在建東西的時候，誰來維護、擴展、確保基礎設施不會崩潰？那是完全不同層級的技能。他的意思是，對於用 AI 工具建構產品這件事，少一點「這不可能」的預設，反而能發現更多可能性。

我的觀察

Lazar 的方法論裡藏著一個深層的洞察：他做的事情，本質上就是產品經理加上工程師的工作，只是用不同的工具。寫 masterplan 是在做產品策略，寫 implementation plan 是在做技術規劃，寫 design guidelines 是在做設計規範，寫 tasks.md 是在做 sprint planning。這些都是軟體團隊每天在做的事，他只是一個人用 AI 把全部串起來。

這意味著什麼？以前一個產品從想法到上線需要 PM、工程師、設計師三個角色協作，現在一個有清晰思考能力和良好品味的人，配合 AI 工具，就能獨立完成。角色的邊界正在模糊，而決定成敗的因素從「你會什麼技術」轉向「你能不能想清楚要做什麼」。

Lazar 自己也承認，他今天手動維護的 PRD 系統，三個月後大概就會被 AI agent 自動化。他說自己「快要失業了」。但他一點都不擔心，因為他最佳化的技能不是文件管理或 prompt 工程，而是判斷力、品味和清晰度。這些技能不會被自動化，反而會因為 AI 的普及而更值錢。