上個月，我花了大約 100 小時進行 vibecoding。

現在我非常確定，那些說他們「30 分鐘 vibecode 出一個應用程式」的人，要嘛是在複製現有專案的簡單版本，要嘛是產出一些有 bug 的爛東西，不然就是純粹為了吸引流量。

這並不是因為我是 AI 懷疑論者。事實上，恰恰相反。

在我之前的創業公司，我們在 2023 年底就開始使用 AI 編碼，那時甚至還沒有「vibe coding」這個詞。

當時這很有爭議，因為大型語言模型（LLM）還不夠好，而且我們是一個開源專案，這讓大家不願意貢獻到我們混亂的程式碼庫。

但 Tim 很早就認識到 AI 的潛力，他透過 gpt-cli 使用 gpt4-preview，而我則是直接將程式碼貼到 ChatGPT 應用程式中。我們用它來處理簡單的事情（例如將新內容放入應用程式的佈局），隨著 AI 變得越來越好，我們開始透過這種方式交付更複雜的功能。

後來我們轉向 Cursor 和 Claude Code，這種對 AI 的早期擁抱讓我們獲得了優勢。這讓我相信 AI 可以成為一種編碼的超級力量。

但是——截至 2026 年 3 月——這是有極限的。

除了在 Kiwi 進行 vibecoding，我還有一些「實際」編碼的經驗。我上過一個為期 100 天的 Python 課程，建置過 JS 天氣應用程式，部署過一些 Cryptozombies 的智能合約等等。當然，我也用 Claude vibecode 了許多本地應用程式。

現在是時候獨自完成將應用程式發布到公開的整個流程了，這本應讓我成為一個更好的產品經理。

由於我的主要目標是學習，我決定「以正確的方式」進行。這意味著我不想依賴 Replit 或 Lovable，因為它們的基礎設施部分被模糊化了。我想自己處理那些複雜性。

為了讓過程更愉快，我決定建置一個簡單可行產品（SLC）來做一些有趣的事情。

在我手上的幾個想法中，我選擇了 Cryptosaurus。這個應用程式會很簡單——你選擇一個恐龍，應用程式會擷取你的個人頭像（pfp），然後創建一個以你的 pfp 風格設計的恐龍。

我腦中有一個高層次的願景，並且知道如何「按部就班」地建置。但我當時想：「好吧，讓我們擁抱這個熱潮，像一些 Twitter 影響者說的那樣『就去建置』吧。」

而這個「就去建置」比我預期的花費了更長的時間。

我開始向 ChatGPT (5.2 Thinking Extended) 描述我的想法。我們討論了一段時間，縮小了範圍，我就準備開始了。我將範圍發送給 Opus 4.5，開啟了 Plan Mode，然後等待結果。

同時，我從 Gemini 取得了 API 金鑰，將它們添加到 .env 中……然後就完成了！第一個小時我就有了可運行的原型。

哇，我很快就要發布它了，對吧？

我不喜歡樣板化的設計。

所以我玩了一下 Coolors 來找到我喜歡的調色盤。選了一個，在 UI 上測試，改變了一些顏色。重複這個過程。幾輪之後，我得到了正確的顏色。

然後我注意到 Claude 過度複雜化了 UI 和 UX。所以我開始簡化它。如果我使用 Figma，我可以在 10 分鐘內製作出 10 個不同的變體，並精確控制結果。但我想「就去建置」，對吧？

於是我請 LLM 建置一個新的 UI。我不喜歡，所以請 Claude 重建它。一些重要的細節不見了，所以我必須重新提示。然後我發現我可以進一步簡化 UI，所以請它完全重建。

然後出現了一個奇怪的容器破壞了前端。然後在手機上渲染效果不好。然後它添加了一些我不想要的奇怪輪廓。諸如此類。每一次迭代都花費了幾分鐘：我的提示，LLM 建置，檢查我是否喜歡，重新提示。

時間一分一秒地過去。如果我「只使用 Figma」，我會快 10 倍地準備好我的 UI。但隨便吧，我們「就去建置」。

由於 Cryptosaurus 的主要「產品」是恐龍圖片，我必須確保它們看起來不錯。這些圖片用我的 pfp 來看起來不錯，但用別人的呢？

我挑選了一些邊緣案例的 pfp 來檢查輸出的效果。結果它們不起作用。有些改變了框架，有些在背景中渲染了隨機提示文字，有些則完全改變了圖片。

我開始與 Gemini、Codex（剛推出）和 Claude (4.6 剛推出) 討論。更改提示，上傳圖片，等待新圖片生成。現在背景消失了。現在缺少了頭飾。現在顯示了一些奇怪的文字，而且鬍子看起來不自然。

我經歷了至少 200 次這個過程。時間還在流逝——我遠遠超過了「30 分鐘建置一個應用程式」的時間。

而且我還沒有離開 localhost。

一旦我弄清楚了提示，現在是時候將它發布出去。

我在 Cloudflare 上購買了 cryptosaurus.app 網域，並在 Vercel 上進行了設定，現在是時候將我的後端放到伺服器上了。

經過與 LLM 的長時間討論，我決定使用 AWS，因為它很便宜，而且我一直想學習它。當我打開面板看到浩瀚的 AWS 服務時，我知道這有點小題大做。但與其使用更簡單的基礎設施，我決定堅持下去，設定了我的 S3 和 Lambda。

幾次嘗試後，似乎奏效了。但不行，有些東西壞了。我的儲存桶沒有設為公開。然後一些 .envs 沒有與 Vercel 或 AWS 共享。好的，找到了問題所在，繼續！

很快我發現了 AWS CLI，並對我的 LLM 可以為我設定東西感到興奮。

但在我請求幫助後，我的應用程式又停止工作了。經過調查，我發現我的 Claude 開始自動創建新的 S3 儲存桶，而不是使用我自行設定的那個。好的，修好了，但另一個「未知的未知」又擊中了我。

經過大量的來回溝通，我的基礎設施終於沒問題了。現在我必須讓它作為一個 Farcaster Mini App 運行，因為 FC 用戶喜歡收集 pfps，而且我已經在那個網路上有了分發管道。但是……我無法在開發者模式下完全測試我的應用程式，因為通知在那裡不起作用。

好的，必須添加 manifest 並包含 noindex，這樣應用程式就不會公開。好的，但然後我需要另一個帳戶來測試它，因為人們可能會看到我在我的主要帳戶上做了一些事情。好的，進行設定。

現在雖然行動裝置 UI 在瀏覽器中看起來正常，但在 mini-app UI 中卻出現了問題。又一次前端修復，這次我更聰明了，直接在瀏覽器中檢查程式碼，並將容器截圖發送給我的 LLM。

好的，現在來鑄造一個恐龍 NFT。啊，但是測試網在這些錢包上不起作用。將合約重新部署到 Base Mainnet。現在需要在所有地方更改 .envs。唉……

然後我想到……好吧，如果我試圖學習「生產級」的做事方式，我也應該保護我的智能合約不被透過 CLI 調用。

所以現在我需要確保只有我的應用程式可以創建恐龍。為此，我必須更改智能合約，並設定 onlyMinter，使用一個單獨的以太坊地址來代表用戶鑄造 NFT。

我也不希望它與 Owner 相同，以防私鑰洩漏，所以我必須設定 Safe 作為合約所有者，並在發生任何事情時更改 onlyMinter。

然後我心想……好吧，但如果同時有 100 個人想使用這個應用程式，它能應付嗎？我的 LLM 告訴我不能。所以我花了 2 天時間研究不同的邊緣案例、速率限制以及能讓應用程式為潛在用戶高峰做好準備的事情。我也將其中一些應用程式升級到了付費版本。

我完成了一個長長的檢查清單，現在是時候發布了。

在分享應用程式的兩週前，我進行了預發布，大約有 500 人在 Farcaster 上「安裝」了該應用程式。

我分享了發布貼文，發送了通知，人們開始打開應用程式……

……然後應用程式崩潰了。連同我精心製造的病毒式傳播。

儘管我使用了 Codex 5.3 Extra High 和 Opus 4.6 來準備應用程式和 API 以應對使用高峰，但兩個 LLM 都忘記了 nonces。所以當兩個人同時想獲得一隻恐龍時，他們的付款成功了，但他們的請求沒有到達 API 來生成圖片和鑄造 NFT。

我告訴所有受影響的人他們會得到退款，並開始修復這個 bug。

深夜，大部分問題都修復了，我寫了一個腳本來找到所有付款卡住的人。我退還了他們的錢（加上額外的 1 美元作為「感謝您的耐心」），並透過私訊通知他們。人們對我的快速回應感到驚喜，他們中的大多數人還是決定獲取他們的恐龍。

最終，儘管面臨所有挑戰，許多人鑄造並在動態消息中分享了他們的恐龍：

我們可以說應用程式的 v1 版本完成了。比 30 分鐘長多了，對吧？

正如我一開始說的，我在一個小時內創建了一個原型。

但由於我不想發布一個 vercel215810.buggyslop.com 類型的應用程式，也不想採取 Replit/Lovable 的捷徑，將其設定為生產環境花費了更長的時間。在這個案例中，大約是 100 倍的時間。

如果我是一個沒有任何編碼經驗的受虐狂，想要遵循我的「就去建置，但也要以正確的方式」的方法，我猜他們會花費更多時間。

最耗時的元素之一是 UX、UI 和最終產品（恐龍輸出）。我決定投入時間在這些方面的原因是，我們已經有足夠多的未經打磨的軟體了。在 AI 出現之前就已經是這樣了，當時人們只是複製開源儲存庫，改變一些參數來建置自己的應用程式。

歸根結底，你可以像這樣建置一個天氣應用程式：

我的應用程式當然遠不及 Windy 的水平，但你懂我的意思。

好消息是，我達成了我的主要目標——在沒有與高級工程師（像我在 Kiwi 那樣）緊密合作的情況下建置了應用程式，並在此過程中學到了很多東西。儘管目標是學習，但應用程式的性能也相當不錯。1,000 多人下載了該應用程式，180 多人支付了 2 美元購買恐龍，該應用程式在其發布的第一週就進入了 Farcaster Mini App 商店的前三名。

這當然是一個簡單的應用程式，並沒有對世界產生什麼影響。但這也是「就去建置一個 SLC」計畫的一部分。之後我想交付第二階段，屆時你可以使用你的恐龍玩遊戲，並與你的 Farcaster 好友比較分數。

隨著時間的推移，我學會了如何更好地使用這些工具。

我仔細地為我的 LLM 規劃工作，以便讓 3-4 個代理程式同時處理同一個程式碼庫，而不會互相干擾。

我注意到 Codex 比 Claude 容易過度複雜化問題，所以我要求它在我的 agents.md 中始終尋找簡單、優雅、程式碼行數少的解決方案。

我花更多時間在架構上，要求 LLM 創建流程圖，並在我的代理程式花費 30 分鐘完成程式碼之前對其進行迭代。

後來我稍微放棄了「就去建置」的哲學，改用 Figma 來打磨設計，而不是等待 LLM，這使得整個過程不那麼令人沮喪。

我在 Obsidian 中記錄了這些以及許多更小的教訓，以便記住它們，有時我只是將這些教訓貼到我的提示中。

雖然 vibecoding 在我的案例中沒有達到「30 分鐘建置一個應用程式」的炒作程度，但它帶來了 10-100 倍的速度提升。如果我使用 Replit 或 Lovable，這種加速效果會更加顯著。

不過，這是一種不同的體驗。

以前我手動編碼時，會進入一種愉快的創意流動狀態。現在我只是一個給數位員工分配任務的經理，當他們沒有按照我的意願交付時，我就會感到沮喪。但是……這仍然是值得的，因為現在我可以專注於建置東西，而不是修復語法。

而工程經驗仍然很重要。特別是當你想把細節做到完美時。

有一次 Brave 開始顯示奇怪的顏色，覆蓋了我的淺色主題。我想在應用程式中禁用它，並嘗試了 3 個不同的 LLM 來解決。一個小時後，沒有任何改變。我向一位資深設計工程師朋友尋求幫助，他用一行程式碼就解決了問題。

有很多類似的問題，如果我身邊有一位經驗豐富的工程師，我本可以 10 倍快地解決。所以我強烈建議向你的資深開發者朋友尋求幫助，因為 LLM 仍然有其極限。

這整個經驗讓我想起了 Tim Cargill 永恆的名言：

「前 90% 的程式碼佔了開發時間的 90%。剩下的 10% 的程式碼佔了開發時間的另外 90%。」

有了 AI，更容易完成前 90%。這意味著我們可以花更多時間在剩下的 10% 上，這意味著有更多時間用於精湛工藝和弄清楚如何讓用戶滿意。

「剩下的 10%」是爛東西和人們喜歡的東西之間的區別。

因為 vibecoding 剔除了編碼中無聊的部分，為精湛工藝創造了更多空間，我認為我們最終會擁有更多酷炫的數位體驗。而創造這些酷炫體驗的能力，是許多人進入科技領域的原因。

所以總而言之，在代理程式變得比人類更優秀的產品經理之前，產品建置應該是件有趣的事。

PS：如果你想看看 Cryptosaurus，可以點擊這個連結，它應該會在你的 Farcaster 帳戶中啟動 mini app。如果你鑄造了一隻恐龍，你將能夠在即將推出的應用程式的第二階段中使用它。

PS2：非常感謝 Pugson、Kris Kaczor 和 Sayangel 在過程中分享的技巧。