前幾天有位學員拿了一個用 Lovable 做的活動報名頁給我看。畫面很好看，有活動介紹、有時間地點、最下面一顆「立即報名」的按鈕。他問我：這樣可以直接拿來收錢了嗎？

我先講結論：頁面可以，收錢不行。或者說得更準確一點，它可以「看起來能收錢」，但錢收進來之後會發生的每一件事，那個頁面都沒有。

這不是 Lovable 做得不好。是因為「一個頁面」跟「一套能做生意的系統」本來就是兩種東西。

你做出來的是一張海報，不是一個櫃台

用 AI 建站工具做出來的東西，我通常叫它「死的頁面」。它會顯示、會排版、手機上也不跑版，甚至能接一顆 Stripe 或綠界的付款按鈕。

但收錢這件事，從來不是按鈕本身。

有人按下付款，錢進到金流商那裡，接下來要有人記錄「這個人買了哪一場、付了多少、付款成功了沒」。要寄一封通知信給他，也要通知你。要把他放進名單裡，之後你才能寄提醒信、寄下一次活動的訊息。付款失敗要能重試，付了兩次要能退。活動有名額，要能算還剩幾個。

這些東西，在一個 AI 產出的靜態頁面裡，一個都沒有。它沒有後台、沒有訂單、沒有會員、沒有電子報。你頂多從金流商後台看到「有一筆錢進來了」，然後拿 Excel 自己對。

十個人報名還對得過來。五十個人、其中三個付款失敗、兩個要改場次，你就會發現自己每天在做一件系統該做的事。

一個能收錢的報名流程，至少要有這些

把「收錢」拆開來看，你會比較清楚頁面缺了什麼：

• 名額跟梯次：滿了要自動關閉，不同場次分開算
• 報名資料：姓名、email、電話，存在一個你之後找得到的地方
• 付款狀態：誰付了、誰沒付、誰付到一半
• 通知信：給報名者的確認信、給你的通知
• 名單：這個人自動進到你的電子報名單，下次活動不用重新找他
• 退款跟發票：一定會有人要

這張清單裡，一個 AI 生成的頁面通常只做到第二項的前半：有表單。其他的，都是「收錢之後」的事，也是你真正會花時間的地方。

為什麼 AI 不會主動幫你把這些補上

因為你沒有問。而你沒有問，是因為你還不知道要問。

Vibe Coding 壓縮的是開發流程的前期：描述需求、做出第一版、看到一個能動的畫面。這段真的變快了，我自己也大量在用。

但後面那些事沒有消失：訂單記錄、通知信、名單、權限、付款異常的處理、活動結束後的資料。這些以前是工程師在做，現在還是要有人做，只是做的人變成你。

我做網站十五年，這些細節多半是踩過坑才知道的。付款成功但金流商回傳失敗、同一個人重複付款、客戶付完錢沒收到信以為被騙。這些不是寫程式的問題，是流程的問題，而 AI 只會做你描述出來的那部分。

什麼情況下，那個頁面可以先用

我不會叫你把它丟掉。

如果你是第一次辦活動、只收十幾個人、收款走轉帳、報名資料用表單收，那個頁面完全夠用。你要的不是系統，是先驗證有沒有人想來。

真正要換工具的時間點，是你發現自己開始「手動做系統的工作」：對帳、寄信、回覆「我付款了為什麼沒收到通知」。當這些事每週吃掉你幾個小時，就是頁面已經撐不住生意的訊號。

到了那個階段，你需要的是一個建完就能收錢、名單自動進去、下一場活動接在同一個品牌底下的地方。這也是我做 Compassio 的原因：它的重點不是建站快，而是建完可以直接做生意。

一個常見的誤區

很多人以為「多接一個金流 API」就解決了。

接得上是真的，但接上之後那些流程還是空的。你等於是在一張海報後面站了一台刷卡機，刷卡機會收錢，可是誰買了什麼、要寄什麼、下次怎麼聯絡，還是沒人管。

所以問題不是「能不能收錢」，是「收了錢之後，你打算怎麼處理」。

你現在那個頁面，有人付款之後，第一件會發生的事是什麼？如果你答不出來，那就是你該補的地方。

如果你做到一半卡住，可以把狀況寫信給我。也歡迎訂閱我的電子報，我會持續寫這類「做到一半才發現的事」：https://iamlouis.ai/subscribe/edm