在出發前往今年的 Google Cloud Next 2025 之前,社交媒體的河道上充斥著很多朋友分享他們使用 Replit 的心得——說它可以很容易地寫出自己想要的應用。
緊接著,Google 也在 Next '25 開始前夕與在 Keynote 上發表了 Firebase Studio,做出一個類似的產品:讓使用者可以用自然語言就創作出自己想要的應用程式。
於是,身為一個一直鼓吹團隊要善用 AI 協作的人,如果自己沒實際用過一遍,總覺得評論就說不上有說服力。就在某個晚上,我乾脆直接跳坑,親身來體驗一回。
這篇文章,我沒有要做什麼深入的評論,只是單純想記錄一件事:我在小兒子生日的那天,從晚上九點左右回到家後,開始用手機請 AI 幫我做一個 Web App。這個過程大概花了我 30 美金,以及 7 個小時左右的時間 (對,我那天跟 AI 聊到快三點才睡) ——這些時間包含了 AI 的思考與實作時間、我自己協助 debug 的時間,以及我邊滑其他 App 的時間。
以下就是這次快速產出的成果:KidBank: https://kidbank.pro (目前這個網站還不穩定,我有空會 Vibe 一下,但是 test 沒有加完,有時候 AI 寫的 code 沒注意到,就會改壞了。)
![]() |
家長管理介面,還有 impersonate 小孩的介面 |
會想寫這個小工具主要是因為想把平常給他們的獎勵更具象化並有個紀錄,例如完成 Duolingo 的 50 天連勝 (每天要做完三個每日任務) 我會給他們 50 元的零用金,另外紅包的紀錄也可以放在裡面。
那為什麼不真的幫他們開戶呢?
其實我有幫他們開戶,但是真的要存錢、轉錢、提錢有點麻煩,因此才有了這個「爸媽銀行」的想法。
這 7 個小時內 AI 幫我產出了這些功能:
- Google Account Login
- Firebase 整合(Analytics, Auth)
- 帳號階層架構(Family → Parent's View → Child's View)
- 家長管理介面,可以轉換成小孩介面,查看小孩目前的畫面
- 小孩可以不用 email 登入,可以只靠隨機碼 + 密碼完成登入
- 成就系統
- 隨機顯示與金融相關的智慧語彙
- 利息設定與定時派發利息功能
- 存款、提款功能
- 可自訂的存提款用途說明與獎勵機制
- 多國語系 (英文和中文,但之前加的英文還沒花錢叫它抽出來)
- 刪除家庭功能
粗工 vs 細工
這次的體驗讓我再次感受到,AI 很適合擔任「粗工」的角色:它能幫我把基本架構快速搭建起來,甚至補上一些邏輯流程,讓我可以專心處理後續的「細工」——包括使用者體驗的細節、bug 修復、語意與流程的調整。
舉個例子來說,我在 Replit 上為了一個問題花了十幾塊美金,來來回回試了很多次,還是沒能讓 Firebase 的 signInWithRedirect 成功運作。問題出在 Firebase 在測試時對網址 (localhost 本機端) 測試時的處理標準是一致的,因此不是 SSL 和 Port 443,就會無法正確取得認證成功的使用者資訊。所以如果要在本機開發環境中使用轉導(redirect)方式來模擬登入流程,不但無法像彈跳視窗那樣方便,還必須使用 Port 443,並手動設定好 SSL 憑證。這些眉角是 AI 一直查不出來,需要我一步一步下去除錯後才找到的癥結。
當然,也有可能是因為 context 的長度限制、prompt 的寫法,或是 token 費用考量等因素,才導致模型沒有辦法一次命中。但即使如此,我仍然覺得 Replit 的調教成果與整體體驗已經算是非常不錯了。特別是在它 debug 的過程中,那些一步一步推理與顯示的方式,其實滿療癒的,也讓我從中學到不少新知。
不過,隨著專案規模變大,如果沒有有效導入 snapshot 等 Vibe Coding 技術,或者對工具使用不夠熟練,整體開發難度確實會提升。但整體而言,我仍然對這種人機協作的模式持樂觀態度。
近期的開發模式,可能會越來越多這樣的搭配:AI 負責粗工,人類專注細工。
開發者不需要從零開始,但也不能完全不碰,對於剛入門的開發者,這或許是把兩面刃,不過我相信益處會是大於缺點的。這樣的趨勢,應該也是下一階段的創作節奏。
最後補充一下我去年在 AWS Summit 的 Developer Lounge 演講上提到與 AI 協作的看法:我覺得 AI 不好用 (?)
留言
張貼留言