從 Vibe Coding 到上線的眉角：SIM《為萬國禱告》的誕生之路

網址：prayer.simtaiwan.org

一頓午餐完成的 PoC

那天午餐的時候，SIM 的 Roger 突然問我：「能不能找個時間聊聊？」
我心想反正我帶著電腦，就說：「不如現在就開始吧。」
他有點驚訝，本來以為要先交通想法、評估困難度，沒想到我們就直接開工了。

一小時以後，網站圓形大致完成。但是從看起來完成，到一個專業可維護的上線網站，中間還發生了什麼事呢？

從原型到正式上線

PoC 雖快，但要真正上線還有幾個關卡。

Github Pages 提升效能

Lovable 的痛點在於 loading 太慢。所以我把專案接上 Github，利用 Github Pages 來發佈，效能直接提升。Loading的時間從3秒鐘降到幾百毫秒。
但這裡有個坑：因為我們是 SPA（Single Page Application），直接放在 Github Pages 會遇到 routing 問題。

上傳到 Github Pages 的時候，會遇到一個特別的麻煩：SPA（Single Page Application）本身的路由，會被 Github Pages 的內建 routing 擋住。原因是這樣的：

• 在 React Router（或 Vue Router）裡，/prayer/123 其實只是由前端解讀的虛擬路由。
• 但 Github Pages 不是這樣想，它會真的去伺服器裡找 /prayer/123 這個資料夾或檔案。
• 找不到？那就直接回 404。

換句話說，Github Pages 的靜態檔案伺服器 router，會先攔截掉 request，導致 React Router 根本沒機會處理。

Workaround：Custom 404 Redirect

解法是我們自己做一個 客製化的 404 頁面：

1. 使用者打 /prayer/123 → Github Pages 找不到 → 跳到我們的 404.html。
2. 在 404.html 裡，我們把當前的 path、query parameter、hash 都記下來。
3. 接著用 JavaScript 把使用者導回 /（root）。
4. 這時候 React Router 接手，讀到剛剛傳過來的路由資訊，再判斷該顯示哪一個頁面。

自訂網域 & Cloudflare

接著，我們需要一個好記的網址。SIM 的 IT 幫忙在 DNS 加了 CNAME，指到 Github Pages。再透過 Cloudflare 設定 Custom Domain，就能用上 prayer.simtaiwan.org (請看Github官方教學)。

Supabase 帳號切換

由於我自己的 Supabase 免費額度已經爆掉，所以乾脆用 SIM 的 email 申請新的專案，再邀請我自己進去做管理員，方便長期維護。

工程品質：從 README 到 Release

穩定上線後，專案不只要能跑，更要「可維護」。

1. README / Contributing Guide
   我用 Cursor 和 Claude Code 幫忙生成文件，讓任何後續的同工可以快速上手。
2. CI/CD 品質控管
   設定了 linter、type check、prettier 等自動檢查，避免品質下滑。
3. Dependabot 自動更新
   套件沒有定期更新，是很多專案的主要死因...
4. 版本管理 Conventional Commit + Release Please

這個組合是我在自己的開源專案裡愛上的一套流程。

Conventional Commit 的規範，要求我們在 commit message 裡面加上簡單的前綴：

• feat: → 新功能
• fix: → 修 bug
• docs: → 文件更新
• chore: → 其他雜事
  …還有其他細分。

這樣一來，commit log 不再是「亂糟糟的備忘錄」，而是結構化的資訊。

接著，Release Please 就能讀懂這些規範化的 commit，幫我：

1. 自動產生 CHANGELOG（清楚列出新增、修正、變更）。
2. 自動 bump 版本號（依照 semver：feat 就升 minor，fix 就升 patch）。
3. 自動發 release（甚至能幫忙建 tag、打 package）。

結果就是：我根本不用自己盯著版本號，或擔心 changelog 忘了寫。
整個 release 流程只要點幾下即可完成，特別適合這種公開、要長期維護的專案。

產品思維：從需求翻譯開始

這段過程最有趣的，其實是「需求翻譯」。

Roger 一開始希望上傳兩張圖：一張中文，一張英文。但我建議直接用 i18n（國際化機制），同一張圖就能自動切換語言，不需要兩份檔案。一般使用者在把一個想法轉成網站的時候，會想像把它本來的流程原封不動變成網頁，但是作為設計師我們可以用我們對於網站如何被使用的專業，來協助。

很多使用者其實不知道還有什麼可能性。例如：字體調整，Dark Mode，PWA（安裝成 App）... 等等，這些都是讓手機版更好閱讀的工具。

另外，每一篇禱告到底要是一個popup還是一個獨立頁面？這就跟你有沒有想要讓使用者分享某一篇禱告，還是你只有想要讓使用者分享網頁。這些設計所帶來的使用者習慣區別，都可以溝通清楚～

以上通通只要在 Lovable 聊聊天就完成，完全不用寫 code。真正有價值的地方，就是釐清真實需求。

圖片壓縮：為 20 年後預先設想

另一個潛在問題，是 Supabase 免費空間只有 1G。禱告圖檔一張就好幾 MB，照這樣上傳，五年內就爆掉了。

我先想過請同工壓縮再上傳，但這樣太麻煩，也不現實。最後決定直接在前端用 compressor.js：每張圖在上傳前自動壓到 300kb 左右。這樣 1G 空間至少能撐 50 年，使用者也完全不用改變習慣。

回顧：Vibe Coding 的精髓

Vibe Coding 讓有些人覺得，好像以前那些程式能力都派不上用場了。
但其實不是被取代，而是 「與人互動、溝通、理解」的能力被放大了價值。

社會學者 Bruno Latour 曾提出一個有趣的問題：我們真正關注的究竟是 matter of fact，還是 matter of concern？

• Matter of fact，在這個例子裡，就像是網站本身要用react還是next、PWA該如何實現，style 應該要用 tailwind 還是 styled component。
• Matter of concern，則是我們如何去關注重要的議題：如何與使用者一起挖掘真正重要的功能？這項產品服務的對象是誰？我們做的每一件事情，能不能推動使用者開始關注重要焦點？

在 Vibe Coding 的時代，我相信 系統設計與運維的能力會更加重要，因為這些是基礎建設。但同時，更重要的是：站在使用者角度思考，翻譯他們的需要，真誠地希望做出能幫助人的產品。

網址再次附上 👉 prayer.simtaiwan.org 一起為世界禱告
也歡迎參與貢獻：https://github.com/Fruitful-Tools/sim-weekly-prayers