Lovable 跟 Replit 的 Agent 點數不夠用？試試接上 GitHub 用 Claude Code 開發

然後我開始算。Lovable Pro 一個月 25 美金給你 100 credits,聽起來很多,但 default mode 一個稍微複雜的請求就要吃掉好幾個 credits。根據官方文件,複雜度越高,用掉的點數越多。如果你是 free plan,那更慘,一天只有 5 credits,一個月最多 30。

Replit 那邊也差不多。Core plan 一個月 20 美金,給你 25 美金的 usage credits。聽起來還行,但他們用的是 effort-based pricing,意思是 Agent 做的事情越複雜,收越多錢。簡單改個東西可能不到 0.25 美金,但如果要 Agent 從頭寫一個功能,那就不只了。而且更重要的是,Replit 的 credits 不會滾存,月底沒用完就消失。

這時候我就在想,能不能有個方法讓我省點數,但又不用放棄這些線上 IDE 的預覽功能？

然後我想到了。

把專案接上 GitHub：Lovable 和 Replit 都支援雙向同步

其實 Lovable 跟 Replit 都有 GitHub 整合功能,只是很多人可能沒注意到。這個功能讓你可以把專案跟 GitHub repository 連起來,然後做雙向同步。

Lovable 怎麼連 GitHub？

在 Lovable 裡面連 GitHub 超簡單。你去 Settings → Connectors → GitHub,點 Connect project,或是直接點右上角的 GitHub 圖示也行。官方文件寫得很清楚。

連上之後,Lovable 會幫你建立一個雙向同步。意思是你在 Lovable 裡改的東西會自動推到 GitHub 的 main branch,然後你在 GitHub 改的東西也會同步回 Lovable。這個同步機制讓你可以用任何你喜歡的工具修改程式碼,然後在 Lovable 裡面看預覽。

不過有個地方要注意。一旦連上,就不要去 GitHub 那邊重新命名、移動或刪除 repository。Lovable 的同步機制是根據 repository 的確切位置和名稱來運作的,你一動就會斷掉。

Replit 怎麼連 GitHub？

Replit 的做法也差不多,但步驟稍微多一點。你要先去 Replit 帳戶設定裡面找到 Connected Services,把 GitHub 連起來。根據官方說明,連好之後你可以直接從 GitHub 匯入專案,或是把現有的 Replit 專案推到 GitHub。

匯入的話,去 https://replit.com/import,選 GitHub,然後授權讓 Replit 存取你的 repositories。它支援 public 跟 private repositories,所以不用擔心。選好要匯入的 repo 之後,Replit 會幫你轉換成可以在他們環境裡跑的專案。

要把改動推回 GitHub 的話,打開左邊的 Version Control 面板,選你要 commit 的檔案,寫個 commit message,然後按 Push。就這樣。

我的工作流程：用 Claude Code 改,用 Lovable/Replit 預覽

連上 GitHub 之後,我的開發流程變成這樣。

首先,我會在 Lovable 或 Replit 裡用 Agent 把專案的基本架構跟環境設定搞定。這些事情讓 Agent 處理最快,因為它們對自己的環境最熟。而且說真的,手動設定環境超煩,能自動化就自動化。

等架構跑起來之後,我就把專案 clone 到本地,用 Claude Code 開始改 code。為什麼用 Claude Code？因為它沒有點數限制啊。Claude Code 的 GitHub Actions 整合讓我可以直接在本地跑 AI 輔助開發,想改多少就改多少,完全不用擔心點數用完。

改完之後,我會 commit 然後 push 回 GitHub。這時候 Lovable 或 Replit （要自已pull）會自動同步到最新版本。我就可以在它們的預覽環境裡看結果,確認功能有沒有正常運作。

如果預覽的時候發現有問題——比如說部署環境的設定跑掉了,或是某個套件版本不對——我就會切回 Lovable 或 Replit,直接用 Agent 修。這種環境相關的問題,Agent 處理起來又快又準,因為它知道自己的環境長什麼樣。

就這樣來回幾次,專案就做完了。

這種做法的三個優點

1. 省點數,而且省很多

最直接的好處當然是省點數。我用 Claude Code 寫主要功能,只有在需要調整環境設定或是 debug 部署相關問題的時候才回去用 Lovable 或 Replit 的 Agent。這樣一來,我的 Lovable Pro plan 100 credits 可以用一整個月還有剩。

如果你是 free plan 使用者,這個方法更重要。一天 5 credits 真的不夠用,但如果你只用來處理環境問題跟預覽,那就綽綽有餘了。

2. 開發初期不用煩惱部署環境

說真的,專案初期最煩的就是設定環境。Docker、CI/CD、環境變數、domain 設定,這些東西超耗時間,而且常常會卡關。

但如果你用 Lovable 或 Replit 的預覽環境,這些問題都不存在。Lovable 的 publish 功能讓你一鍵部署,Replit 的 Deployments 也是。你只要專心寫 code,環境的事情讓平台處理。

等到專案真的要正式上線了,再來處理自己的部署環境也不遲。這樣可以省下很多開發初期的時間。

3. 把 Agent 用在它最擅長的地方

我覺得很多人對 Lovable 跟 Replit 的 Agent 有點誤解。他們以為 Agent 什麼都能做,結果發現 Agent 有時候會寫出很蠢的 code,或是搞不清楚你要什麼。

但其實 Agent 最擅長的是處理環境相關的問題。它知道自己跑在什麼環境裡,知道有哪些套件可以用,知道怎麼設定才能讓東西跑起來。所以當你的 app 跑不起來,或是 log 噴一堆錯誤的時候,讓 Agent 來 fix 通常很快就能解決。

至於寫複雜的業務邏輯、重構程式碼、或是實作特定演算法,這些事情還是交給 Claude Code 比較靠譜。畢竟 Claude Code 背後是完整的 Sonnet 4.5 model,理解能力跟程式碼品質都比那些線上 IDE 的 Agent 好很多。

把對的工具用在對的地方,才是最有效率的開發方式。

實際案例：我用這個方法做了什麼

上個月我在做一個小工具,功能是幫我整理 Notion 裡面散落的筆記。我用 Lovable 起了一個 React + Vite 的專案,讓 Agent 把 Notion API 的 integration 設定好,然後把基本的 UI 框架拉出來。

這個階段大概用掉 15 個 credits。

然後我把專案 clone 到本地,用 Claude Code 寫主要的邏輯——怎麼解析 Notion 的資料結構、怎麼分類、怎麼產生摘要。這部分比較複雜,如果用 Lovable 的 Agent 來做,我估計至少要 30-40 credits,而且不一定能一次寫對。

用 Claude Code 寫完之後,我推回 GitHub,然後在 Lovable 的預覽環境測試。結果發現有幾個地方跑不起來,log 顯示是 CORS 設定的問題。我就直接在 Lovable 裡跟 Agent 說「fix CORS error」,它馬上就改好了。用掉 2 個 credits。

整個專案做完,我總共只用了不到 20 個 credits。如果全部用 Lovable 的 Agent 來做,我估計至少要 50-60 credits,而且過程中還會有很多來回修改。

值得。

Lovable vs Replit：我會怎麼選？

你可能會問,那到底要用 Lovable 還是 Replit？

說真的,兩個都不錯,但適合的情境不太一樣。

比較項目	Lovable	Replit
月費（付費方案）	$25/月（Pro）	$20/月（Core）
免費方案點數	每日 5 credits,月上限 30	有限的免費額度
付費方案點數	100/月,可滾存至 150	$25 usage credits,不滾存
計費方式	依訊息複雜度計算	Effort-based（依任務複雜度）
GitHub 同步	雙向自動同步	手動 push/pull
預覽環境	即時預覽,需手動 publish	開發環境與正式環境分離
適合場景	前端專案、快速原型	全端專案、需要後端的應用

我自己的選擇標準是這樣。如果專案主要是前端,或是只需要靜態網站,我會用 Lovable。它的預覽環境很快,而且 UI 相關的調整用 Agent 處理起來很順。而且 credits 可以滾存,比較不會浪費。

如果專案需要後端、database、或是複雜的部署設定,我會選 Replit。它對各種語言跟框架的支援比較完整,而且 Deployments 功能很強大,可以設定 autoscale、scheduled deployment 這些東西。

但不管選哪個,我都會接上 GitHub,然後用 Claude Code 寫主要邏輯。這個工作流程對兩個平台都適用。

幾個踩過的坑

Lovable 的 GitHub 同步會斷掉

前面提過了,但還是要再強調一次。連上 GitHub 之後,不要去重新命名或移動 repository。我第一次用的時候就踩到這個坑。我在 GitHub 那邊把 repo 改名了,結果 Lovable 就找不到了,同步整個斷掉。

如果真的不小心動到了,你可能要重新連一次。但這樣會很麻煩,所以最好一開始就把 repo 名稱取好。

Replit 的 credits 不滾存

這個也是我後來才知道的。Replit 給你的 usage credits 月底會清零,沒用完就消失。根據一些第三方評測,這是 Replit 跟 Lovable 最大的差異之一。

所以如果你用 Replit,最好每個月都把 credits 用完。或是乾脆用我這個方法,把大部分開發工作移到 Claude Code,這樣 credits 就夠用了。

預覽環境不等於正式環境

這個是很多人會忽略的。Lovable 跟 Replit 的預覽環境雖然很方便,但跟真正的正式環境還是有差。比如說效能、安全性設定、domain 設定這些,預覽環境都是簡化過的。

所以這個工作流程比較適合開發初期。等到要正式上線了,還是要處理真正的部署環境。但至少在開發階段,你可以省下很多時間跟麻煩。

常見問題（FAQ）

Q: 我一定要付費才能用 GitHub 整合嗎？

不用。Lovable 跟 Replit 的 GitHub 整合功能在免費方案也能用。你只要有 GitHub 帳號就行了。

Q: Claude Code 是免費的嗎？

Claude Code 本身是 Anthropic 官方的 CLI 工具,但使用時會消耗 Claude API 的額度。如果你有 Claude Pro 或 API 訂閱,可以用你的 API key。如果沒有,你也可以用 Anthropic 提供的免費額度,但有使用限制。

Q: 這個方法適合團隊開發嗎？

適合,而且更適合。因為 GitHub 本來就是為團隊協作設計的。你們可以用 pull request、branch、code review 這些標準的 Git 工作流程,然後在 Lovable 或 Replit 預覽結果。只要注意不要多個人同時在線上 IDE 裡改同一個檔案就好。

Q: 如果我不會用 Git 怎麼辦？

那可能要先學一下基本的 Git 操作。但說真的,如果你打算認真做開發,Git 是遲早要學的。而且 Lovable 跟 Replit 的 GitHub 整合已經幫你處理掉很多複雜的部分了,你只需要會 clone、commit、push 這幾個基本指令就夠了。

Q: Lovable 跟 Replit 的 Agent 真的不夠聰明嗎？

不是不聰明,而是有侷限性。這些 Agent 在處理環境設定、簡單的 UI 調整、或是 debug 部署問題的時候很強。但如果要寫複雜的業務邏輯、做大規模重構、或是實作特定演算法,Claude Code 背後的完整 model 會做得更好。

Q: 我可以用其他的 AI coding tool 代替 Claude Code 嗎？

當然可以。這個工作流程的核心概念是把主要開發工作移到本地,只在需要預覽跟處理環境問題的時候才用線上 IDE。你用 Cursor、GitHub Copilot、或任何其他 AI coding tool 都行。我選 Claude Code 是因為它對 GitHub 的整合比較好,而且沒有點數限制的問題。

Q: 這個方法會不會讓開發流程變複雜？

一開始可能會覺得多了一些步驟,但習慣之後其實更順。而且你省下的點數跟時間絕對值得這點學習成本。我自己用了一個月之後,已經完全回不去純線上 IDE 的開發方式了。

Q: Lovable 跟 Replit 未來會不會改變 GitHub 整合的方式？

有可能。這些平台一直在更新功能。但 GitHub 整合是很基本的需求,我覺得他們應該會繼續支援,甚至做得更好。如果有重大改變,我會更新這篇文章。

寫到這裡,我突然想到莊子說過的一句話：「工欲善其事,必先利其器。」

Lovable 跟 Replit 是很好的工具,Claude Code 也是。但重點不是工具本身有多強,而是你怎麼組合使用。把對的工具用在對的地方,才能發揮最大效益。

如果你也在用 Lovable 或 Replit 開發,而且覺得點數不夠用,或是 Agent 有時候不夠聰明,不妨試試這個方法。接上 GitHub,用 Claude Code 寫主要邏輯,讓 Agent 專心處理環境問題。你可能會發現,開發效率整個提升了一個檔次。

至少對我來說是這樣。

分類與標籤：Coding程式寫作, AI/AGI 人工智能, #