讀完這一章，你會知道如何把 Lovable 專案接回成熟的工程流程。你會分清楚 GitHub Git sync、GitHub API connector、Code Mode、Download codebase、外部部署和自管 infrastructure 的差別，並學會用 branch、pull request、code review 和本機 IDE 工作流，把 AI 生成的全端網站納入可維護的軟體開發流程。
這章的重點不是「開發者要不要介入」。真正的問題是：哪些工作最適合留在 Lovable，哪些工作應該進 GitHub、IDE、CI/CD 和工程審查。
Lovable 可以讓非工程背景的人快速把產品做出來。可是只要產品開始進入團隊協作、客戶交付、資安審查、長期維護或外部部署，你就不能只靠 chat history 管理變更。
你需要：
Lovable 的 GitHub integration 讓專案程式碼可以雙向同步到 GitHub。Code Mode 讓你在 Lovable 裡直接看檔案、改檔案、引用精確行號。這兩者合起來，讓 Lovable 不只是 prototype（原型）工具，而是可以接進工程團隊 workflow（工作流） 的 agentic development platform。
你可以這樣分工：
Lovable Chat = 產品意圖、快速實作、視覺迭代
Code Mode = 檔案檢查、精準修改、引用行號討論
GitHub Git Sync = 程式碼所有權、分支、PR、審查、備份
本機 IDE = 深度工程修改、測試、重構、除錯
外部部署 = 當 Lovable Cloud 不符合正式環境要求時才接手
不要把 Lovable 當成 GitHub 替代品。也不要把 GitHub 當成一定要馬上導入的負擔。
正確判斷是：
早期原型 -> 在 Lovable 內完成
需要共同維護 -> GitHub Sync
需要精準修改程式碼 -> Code Mode
需要工程審查 -> 分支 + Pull Request
需要組織部署規範 -> 外部部署
這是第 12 章最重要的區分。
GitHub Git sync 是把你的 Lovable project（專案）code 匯出並雙向同步到 GitHub repository。用途是 code ownership、備份、協作、branch、pull request、本機 IDE 和外部部署。
GitHub API connector 是你的 app 在 runtime 呼叫 GitHub REST API。用途是做 issue dashboard（儀表板）、PR tracker、release dashboard（儀表板）、repo automation 等產品功能。
簡單判斷：
我要同步 Lovable 專案程式碼 -> GitHub Git Sync
我要讓應用程式讀寫 GitHub Issue／PR／Repository -> GitHub API Connector
不要把兩者混用。
開始前，請先確認：
本章延續 LaunchNote。到第 12 章，它已經有：
這已經不是單純 prototype（原型）。它需要進入版本控制。
Lovable 文件明確說，不需要 GitHub 也可以使用 Lovable。很多使用者可以完全在 Lovable 裡 build and launch。
但以下情境建議接 GitHub：
如果你只是想要一份 code copy，paid plans 可以直接在 Code editor 下載 codebase，不一定要接 GitHub。
提示詞：
請協助我判斷 LaunchNote 現在是否應該連接 GitHub。
背景：
- 應用程式有身分驗證、資料庫、付款、信件和 AI 功能。
- 我希望開發者審查變更。
- 未來可能把前端部署到 Lovable Cloud 以外的平台。
請說明：
- GitHub Git Sync 對這個專案的好處。
- 連接後，工作流程會有哪些變化。
- 需要哪些權限。
- 我應該知道哪些風險或限制。
暫時不要連接。
圖 12-1：GitHub sync 由 workspace connection 與單一 project repository link 組成；Lovable 與目前 active branch 之間進行雙向同步。
GitHub sync 有兩層：
工作區連線
專案 Repository 連結
Workspace（工作區） connection 是 Lovable workspace（工作區）授權到 GitHub account 或 organization。它可以被多個 project（專案）重用。
Project（專案） repository link 是單一 Lovable project（專案）對應單一 GitHub repo。
Workspace（工作區） admins 和 owners 可以建立 workspace（工作區）connection。Project（專案） owner/admin 或 workspace（工作區）owner/admin 可以把 project（專案）連到 repo。
實作流程大致是：
連接後，Lovable 會建立新的 GitHub repository 並開始雙向同步。
注意：Lovable Git sync 目前不是把既有 GitHub repo import 進 Lovable。它是從 Lovable export 到 GitHub。
Lovable 只會編輯並同步一個 active branch。預設通常是 repository 的 default branch，例如 main。
這個規則非常重要：
Lovable 一次只同步一個作用中分支。
如果你在 GitHub 推到 feature branch，但 Lovable 目前同步的是 main，你不會在 Lovable 看到那些 commits，除非：
建立新 branch 時也要小心。Lovable 建立新 branch 的來源是「目前 active branch」，不是永遠從 main。
正確流程：
切到 main
-> 確認 main 是最新
-> 建立分支
-> Lovable 自動切到新分支
-> 在新分支上讓 Lovable 實作
-> 到 GitHub 建立 PR
-> 審查／測試
-> 合併
-> 切回 main
提示詞：
請為 LaunchNote 建立 GitHub 工作流程。
規則：
- main 應代表可正式上線的程式碼。
- 功能開發應在功能分支進行。
- 除非刻意選擇其他基底，Lovable 應從 main 建立分支。
- 開發者透過 Pull Request 審查變更。
- 受保護分支的衝突應在 GitHub 解決。
請提出：
- 分支命名規則。
- 何時使用 Lovable，何時使用本機 IDE。
- PR 檢查清單。
- Lovable 推送到備用同步分支時的處理方式。
圖 12-2：Code Mode 適合檢查檔案、做小範圍修正與針對特定檔案討論；大型重構仍應透過 branch、diff 與 review 管理。
Code Mode 讓你在 Lovable 裡看完整檔案結構、搜尋、編輯檔案、format code、copy file content、preview（預覽） Markdown、下載檔案，還可以把檔案或精確行號引用到 chat。
Code Mode 適合：
Button.tsx:42 這種精確位置給 Lovable。Code Mode 不一定適合：
Code Mode 提示詞：
我在 Code Mode 找到這個元件：
@src/components/BillingBanner.tsx
請檢查訂閱狀態的顯示邏輯。
需求：
- active 和 trialing 應顯示付費存取權限。
- past_due 應顯示帳務警告。
- canceled 應保留存取權限直到 current_period_end。
- expired 應阻擋付費功能。
不要修改無關的帳務檔案。
編輯前，請先說明變更內容。
如果你能引用精確檔案和行號，Lovable 的修改範圍會更清楚。
有些工作讓 Lovable 做很快，有些工作讓工程師在 IDE 做更穩。
適合 Lovable：
適合本機 IDE：
本機開發流程：
連接 GitHub Sync
-> Clone Repository
-> 建立功能分支
-> 在 IDE 編輯
-> 執行測試和建置
-> Commit 並 Push
-> Lovable 同步作用中分支，或把 PR 合併到同步分支
提示詞：
請準備把 LaunchNote 交接給本機開發者。
請產生一份開發者交接說明，包含：
- 如何 Clone 已同步的 GitHub Repository。
- 所需的 Node 版本。
- 建置指令。
- 本機開發所需的環境變數。
- 哪些檔案控制 Supabase 或 Lovable Cloud 存取。
- 如何安全測試身分驗證、付款、信件和 AI 功能。
- 在 Lovable Preview 以外執行時的已知限制。
當 Lovable 產生的變更開始影響 auth（驗證）、payments、RLS（Row Level Security，列層級安全）、Edge Functions、AI 或外部 API，就應該用 PR review。
PR checklist：
產品：
- 變更是否符合已核准的計畫？
- 是否保留既有使用者流程？
- 是否處理空白、載入、錯誤和權限狀態？
資料：
- Schema 變更是否符合預期？
- Migration 是否經過審查？
- RLS 是否仍保護私密資料？
安全：
- 前端程式碼中沒有 Secret。
- API Scope 沒有過度寬鬆。
- 沒有不安全的公開 Storage。
付款：
- 權益仍符合各方案狀態。
- canceled 和 past_due 的行為正確。
驗證：
- 確認建置通過。
- 相關測試通過。
- 已驗證手動瀏覽器流程。
你可以請 Lovable 幫忙產 PR 說明：
請為目前分支撰寫 Pull Request 說明草稿。
請包含：
- 摘要。
- 使用者可見的變更。
- 資料庫或 RLS 變更。
- 付款或整合變更。
- 測試計畫。
- 風險和復原說明。
請使用精簡繁體中文。
Git sync 不是魔法。當 branch protection、衝突或權限問題發生時，Lovable 可能無法把變更推回原本 synced branch。
文件提到一種情境：如果 synced branch rejected push，Lovable 可能把變更推到 lovable-sync-<timestamp> branch，避免遺失工作。
處理方式：
在 GitHub 開啟備用分支
-> 審查變更
-> 建立合併到受保護分支的 PR
-> 解決衝突
-> 執行測試
-> 透過正常審查流程合併
不要看到 fallback branch 就慌。它其實是在保護你的 work。
如果 branch 被刪除，Lovable 也可能切到 lovable-fallback branch，讓你可以繼續工作。這時候要選一個正確 branch，或在 GitHub 重建原 branch。
圖 12-3：GitHub API connector 是讓你的 app 呼叫 GitHub REST API；備份與同步 Lovable project code 應使用 GitHub Git sync。
如果你要做「GitHub issue dashboard（儀表板）」或「PR status hub」，那是 GitHub API connector，不是 Git sync。
GitHub API connector 使用 personal access token。Token 像密碼，要保護好，只給必要權限。API requests 會算在你的 GitHub account rate limits。
範例：
請使用 GitHub API Connector 建置內部 PR 儀表板。
需求：
- 列出所選 Repository 中開啟的 Pull Request。
- 顯示標題、Repository、作者、審查狀態、CI 狀態和建立天數。
- 醒目標示超過 3 天的 PR。
- 允許依 Repository 和作者篩選。
- 使用既有 GitHub Connector。
安全：
- 使用具備最小必要權限的 Token。
- 不要在前端程式碼暴露 Token。
- 清楚處理 403 權限錯誤和速率限制。
這個功能是你的 app 在 runtime 讀 GitHub data。它不會把 Lovable project（專案）code sync 到 GitHub。
Lovable Cloud 已經提供 production（正式上線）hosting、custom domains、SSL、managed backend（後端）、auth（驗證）、storage、security scanning 和 AI runtime。大多數團隊不需要一開始就外部部署。
外部部署通常是因為：
如果只是「感覺比較自由」，先不要急著搬。
Lovable ownership 文件的核心原則是：
外部部署 提示詞：
請評估 LaunchNote 是否應部署在 Lovable Cloud 以外的平台。
目前需求：
- 自訂網域。
- Paddle 付款。
- 身分驗證和 RLS。
- Resend 信件。
- AI 摘要。
- GitHub Sync。
請比較：
- 完全留在 Lovable Cloud。
- 把前端部署到代管平台，後端保留在 Lovable Cloud。
- 把後端移到代管的 Supabase。
針對每個選項，請列出：
- Lovable 仍負責管理的項目。
- 團隊需要承擔的責任。
- 風險。
- 遷移步驟。
- 建議。
如果你把 frontend（前端）部署到 Netlify、Cloudflare Pages、Vercel、AWS Amplify 或其他 Git-based hosting，基本建置設定通常是：
建置指令：npm run build
輸出目錄：dist
Node 版本：22
如果 backend（後端）還在 Lovable Cloud，你需要從 .env 提供 build-time VITE_ variables，例如：
VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY
VITE_SUPABASE_PROJECT_ID
你也要處理：
這些都是你的責任，Lovable 無法監控或 debug 它不控制的 production（正式上線）infrastructure。
請評估這個 Lovable 專案是否已準備好使用 GitHub Sync。
背景：
- 應用程式有身分驗證、後端資料、付款、信件和 AI 功能。
- 開發者需要審查變更。
- 未來可能把前端部署到 Lovable Cloud 以外的平台。
請提供：
- GitHub Sync 有何幫助。
- 所需角色和權限。
- 分支工作流程建議。
- 風險和限制。
- 初次設定檢查清單。
暫時不要連接。
為什麼有效：
請為 LaunchNote 建立功能分支工作流程。
規則：
- main 是可正式上線的版本。
- 新工作從 main 開始。
- Lovable 的功能開發應在分支進行。
- Pull Request 必須經過審查才能合併。
- 受保護分支的衝突在 GitHub 解決。
請包含：
- 分支命名範例。
- PR 檢查清單。
- 何時使用 Lovable。
- 何時使用本機 IDE。
- 如何處理備用同步分支。
為什麼有效：
請審查 Code Mode 中的這個檔案：
@src/components/BillingBanner.tsx
任務：
請修正訂閱狀態顯示。
規則：
- active 和 trialing 顯示付費存取權限。
- past_due 顯示警告。
- canceled 保留存取權限直到 current_period_end。
- expired 阻擋付費功能。
不要修改無關檔案。
套用前，請先說明預計進行的編輯。
為什麼有效：
請為這個 Lovable 專案建立開發者交接文件。
請包含：
- Repository 位置。
- 分支工作流程。
- Node 版本。
- 建置指令。
- 環境變數。
- 身分驗證和後端說明。
- 付款測試模式說明。
- Email 和 AI Connector 說明。
- 已知風險。
- 本機開發限制。
為什麼有效：
請評估外部部署選項。
選項：
- 留在 Lovable Cloud。
- 把前端部署到代管平台。
- 把後端移到代管的 Supabase。
- 完全自行管理基礎設施。
針對每個選項，請說明：
- 會有哪些變更。
- 團隊負責哪些項目。
- 環境變數需求。
- 部署風險。
- 復原策略。
- 對目前階段的建議。
為什麼有效：
替 LaunchNote 建立工程交接流程。
使用 Pattern 1 產生 GitHub sync adoption plan。
預期結果：
使用 Pattern 2 建立 branch 和 PR 規則。
預期結果：
在 Code Mode 找一個 billing 或 auth（驗證）component，引用到 chat，使用 Pattern 3 做精準修正。
預期結果：
使用 Pattern 4 產生工程交接文件。
預期結果：
GitHub API connector 是 app 功能。Git sync 是 code repository 同步。兩者不同。
Lovable 從目前 active branch 建新 branch。要從 main 開始，就先切到 main。
Auth（驗證）、payments、RLS（Row Level Security，列層級安全）、Edge Functions、AI integration 這類變更，應該走 feature branch 和 PR review。
Lovable 文件提醒，rename、move、delete repo 都會破壞 sync。不要任意更動 synced repo 的位置。
離開 Lovable Cloud hosting 後，你要自己處理 CI/CD、SSL、CDN、logs、rollback、env、OAuth redirect、uptime。
Download codebase 是拿一份 copy。GitHub sync 才是長期雙向協作流程。
先不接 GitHub也可以，如果：
但只要你進入付費、登入、真實資料、客戶交付或 team collaboration，就應該認真導入 GitHub。
VITE_ build-time variables 是否在外部平台正確設定？讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術