本篇文章更新時間：2026/03/16
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
為什麼「30 分鐘做出一個 App」只是美好幻想？讀《The 100 hour gap between a vibecoded prototype and a working product》有感
編輯前言：這篇文章來自 The 100 hour gap between a vibecoded prototype and a working product。作者想驗證：AI 時代的「vibecoding」真的能讓人 30 分鐘做出一個產品嗎？他的實際經驗卻揭露了從原型到產品之間的巨大落差。
核心觀點 (Key Takeaways)
- AI 能讓你很快做出「能動的原型」，但離真正可上線的產品仍有 巨大 的距離。
- UI/UX、邊界情況處理、部署基礎建設等「剩下的 10%」卻是最耗時的部分。
- 工程經驗仍然重要，LLM 能加速，但無法完全替代資深工程師的判斷與修正。
深入解析
作者一開始抱著「就讓 AI 幫我 vibecode 一個 app 吧」的心態，用 ChatGPT、Claude、Gemini 等工具，只花一個小時就做出可運行的原型——但故事從這裡才真正開始。
作者說：「I created a prototype in an hour. But setting it up for production took about 100X longer.」
以下是我歸納的幾個核心難題：
-
UI/UX 不可能靠 LLM 一次到位：
作者不想使用像 Figma 這樣的專業工具，只靠 LLM 調整前端。但越調越糟，反覆改 UI 反而比自己設計更花時間。 -
生成圖片的提示調校極度耗時：
Cryptosaurus 的核心是「把使用者 pfp 變成恐龍圖」。要支援各種邊界案例（頭盔、背景、胡子、奇怪構圖），作者調 prompt 調了 200 次以上，最後 prompt.ts 高達 274 行。 -
基礎建設（infra）才是地獄級難度：
作者堅持不用 Replit/Lovable 等一鍵部署平台，選擇自己搭 AWS S3、Lambda、Vercel。結果遇到： -
.env 錯誤
-
LLM 自動建立錯誤 bucket
-
部署與權限問題層出不窮
-
Farcaster Mini App、NFT 合約、併發問題：
上線後的非預期情況才是考驗的開始，包括： -
Mini App 測試不完整
-
主網部署替代 testnet
-
需要 onlyMinter 權限設計
-
高併發時因為 nonce 問題導致交易成功但 API 沒接到請求
作者最後熬夜退款給使用者並修復 bug，才讓 v1 稱得上完成。
筆者心得與啟發
這篇文章最讓我有感的是：AI 並沒有讓「產品開發」變簡單，它只是把門檻往前移了一點。以前工程師花大量時間在架構、語法、部署；現在 LLM 幫你快速生出一堆能動的東西，你則得花更多時間去：
- 定義需求
- 判斷什麼是好的設計
- 找出邊界情況
- 管理愈來愈複雜的 AI 代理人
換句話說，AI 讓開發更像「管理團隊」，而不是「自己寫程式」。這種模式有明顯的加速效果，但也容易讓你掉入「LLM 產生的錯誤自己都沒察覺」的陷阱。
作者最後引用了工程界的名句：
“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent accounts for the other 90 percent.”
AI 只讓第一個 90% 更快，但真正區別「軟爛產品」與「被喜愛的產品」的，是那難以跨越的最後 10%。
對我來說，這篇文章提醒了三件事：
- AI 能讓你加速，但不能替你思考與選擇。
- 使用者看不到你的原型——只會在乎體驗是否順暢。
- 若真的想做產品，越早理解「基礎建設與環境差異」的重要性越好。
同時，這篇文章也讓我重新思考：
我們是否該盲信「30 分鐘做出 app」這類吸睛說法？還是該把心力放在打造真正讓人愉快的體驗上？
即使 AI 帶來 10–100 倍的效率提升，追求 craftsmanship 的人依然會佔上風。因為真正打動人的東西，從來不是程式碼，而是體驗。
以上便是我對這篇文章的閱讀筆記，原文可見：
The 100 hour gap between a vibecoded prototype and a working product。