本章目標

讀完這一章，你會知道 Subagents 在 Lovable 裡扮演什麼角色：它們不是一起改 code 的分身，而是暫時、唯讀、聚焦的調查員。你會學到什麼時候應該鼓勵 Lovable 使用 subagents，如何把複雜任務拆成可調查問題，以及如何閱讀 subagent findings 來做下一步決策。

Subagents 的價值不是「更多 AI 更厲害」，而是把大型任務中的探索、研究、檢查、比較分流，讓主 agent 不必把所有中間資訊都塞進同一段聊天裡。

為什麼這一章重要

小專案裡，Lovable 直接看幾個檔案就能理解狀態。大型專案不是這樣。

當專案變大，任何改動都可能牽涉：

• 多個 pages。
• 多個 shared components。
• auth（驗證）和 role logic。
• database schema。
• payment entitlements。
• edge functions。
• 第三方 integrations。
• 已經存在的 bug 或 workaround。

如果所有探索都塞在同一個 chat 裡，對話會很快變髒：檔案內容、搜尋結果、logs、猜測、失敗路徑、舊結論混在一起。你和 Lovable 都會難以抓住真正重要的決策。

Subagents 解決的是這個問題。它們把調查拆開，各自處理一個 bounded question，最後把有用 findings 回報給主 agent。主 agent 再綜合這些 findings，決定要不要 plan、build、解釋或停下來問你。

圖 6-1：Subagents 的定位是暫時、唯讀的調查員；它們把大型任務拆成聚焦問題，再把 findings 回報給主 agent。

思考模型：Subagents 是唯讀調查員

Subagents 有三個關鍵限制：

• 它們可以搜尋、檢查、研究、review。
• 它們不能新增、修改、刪除 project（專案）檔案。
• 所有實際變更仍然由 main Lovable agent 執行。

這個限制很重要。它讓 subagents 適合處理「了解情況」而不是「直接動手」。

你可以把它們想成一組臨時研究助理：

Main agent = 決策與執行負責人
Subagents = 聚焦調查員

主 agent 可以請一個 subagent 看 auth（驗證）flow，另一個看 dashboard（儀表板） performance，第三個研究 pricing page best practices。它們各自回報 findings，但不互相協調，也不直接改 project（專案）。

什麼時候該鼓勵使用 Subagents

你不需要手動設定 subagents。Lovable 會根據任務判斷是否有用。不過你可以在 提示詞裡明確提到 subagents，讓 Lovable 知道你希望把調查工作拆開。

適合 subagents：

• 你接手一個很久沒看的專案。
• 你要做大型功能，但不知道影響範圍。
• 你要重做 pricing page、dashboard（儀表板）、onboarding 等高影響頁面。
• 你遇到 performance 問題，需要同時看 UI（使用者介面）、data fetching、assets。
• 你要調查 auth（驗證）、payment、permissions 等 connected flows。
• 你想在 build 前研究最佳實務。
• 你要做 code review 或 launch readiness review。

不適合 subagents：

• 改一段文案。
• 新增一個 isolated FAQ。
• 調整按鈕顏色。
• 已經有明確 plan，只差執行。

Subagents 有成本，也會消耗模型使用量。不要為了小事啟動一堆調查。

Generic subagents 和 Explore

Lovable 文件提到兩種 subagent 類型。

Generic subagents 適合輸出特定形狀的 findings，例如比較、checklist、summary、review、recommendation。你可以把它們想成「幫我整理成某種格式」。

例如：

請使用 Subagents 比較三種重做價格方案頁的方法。
請回傳包含取捨與檢查清單的建議。

Explore 適合需要可追溯證據的問題，例如「這個流程在哪裡處理」、「為什麼這個行為發生」、「目前 auth（驗證）flow 怎麼運作」。它會做比較結構化的研究。

例如：

請使用 Explore 調查目前身分驗證流程的運作方式。
我需要檔案層級的證據，以及登入、工作階段狀態和受保護路由分別在哪裡處理的摘要。

你不一定要指定類型，Lovable 會自行判斷。但知道差異後，你可以把問題寫得更清楚。

圖 6-2：Subagent 執行時會出現在 activity card；展開後可以查看它讀過的檔案、搜尋、工具與回傳 findings，主 agent 再彙整結果。

Workflow: 把大型任務拆成調查問題

步驟 1：先說明大目標

我想重做儀表板，使它速度更快、資訊更清楚，也更容易維護。
修改程式碼前，請使用 Subagents 調查目前的實作方式。

步驟 2：拆成獨立調查面向

請把調查拆成以下面向：
1. 目前的儀表板結構和關鍵檔案。
2. 資料取得和狀態管理。
3. 使用者介面複雜度和可重複使用的元件。
4. 效能風險。
5. 建議的重做計畫。

這些問題彼此獨立，適合平行調查。

步驟 3：要求可用的 findings 格式

針對每個調查項目，請回傳：
- 檢查過的內容
- 主要發現
- 證據或檔案參照
- 風險
- 建議的下一步

這能避免 findings 變成泛泛心得。

步驟 4：要求主 agent 綜合

Subagents 回報後，請把所有發現整合成一份決策備忘錄。
先不要實作。

Subagents 的結果要回到決策，不是堆資料。

步驟 5：再決定 Plan 或 Build

你拿到 findings 後，可能有三種結果：

• 需求很清楚，可以請 Lovable 產生 plan。
• 發現風險太高，先縮小 scope。
• 發現根因不在你以為的位置，改變方向。

這才是 subagents 的價值：它們幫你在動手前降低不確定性。

圖 6-3：要鼓勵 Lovable 使用 Subagents，提示詞應說明要調查的面向；陌生專案、建置前研究與效能問題都適合拆分。

提示詞範例

範例 1：探索陌生專案

修改前，請使用 Subagents 探索這個專案。
我已經有一段時間沒有碰這個專案。

調查項目：
- 主要頁面和路由
- 資料流程
- 身分驗證和角色
- 重要的共用元件
- 外部整合
- 看起來容易出錯的區域

請回傳一份精簡的專案地圖，並附上證據。
不要修改檔案。

範例 2：重做 定價頁 前研究

請使用 Subagents 協助我重做價格方案頁。

請並行調查：
1. 這類產品出色的 SaaS 價格方案頁應具備哪些要素。
2. 目前價格方案頁的結構。
3. 價格方案是否連接任何付款或權益判斷邏輯。
4. 建置前應修改哪些項目。

請回傳建議與分階段計畫。
先不要實作。

範例 3：效能調查

請使用 Subagents 調查儀表板操作緩慢的原因。

把研究拆成以下面向：
- 資料取得和網路請求
- 元件渲染和狀態更新
- 資產和程式包問題
- 使用者可感受到的症狀

請依影響程度排序，回傳可能原因、證據與修正方式。
先不要修改程式碼。

範例 4：大型功能規劃

請使用 Subagents 協助規劃新增留言和按讚功能。

研究項目：
- 留言和按讚功能常見的資料模型
- 這些功能應放在目前應用程式的哪些位置
- 身分驗證和權限上的影響
- 所需的使用者介面元件
- 測試和濫用風險

調查結果出來後，請先摘要說明建置這些功能代表需要承擔哪些工作，再開始建置。

如何閱讀 Subagent findings

Subagent findings 不是命令。它們是證據和建議。

你要看：

• 它是否回答了原本問題？
• 它有沒有 file references 或 traceable evidence？
• 它有沒有把猜測和確定事實分開？
• 它有沒有指出風險？
• 不同 subagents 的 findings 是否互相矛盾？
• 主 agent 的綜合是否合理？

如果 findings 太空泛，可以追問：

這些調查結果太籠統。
請提供檔案層級證據，並區分已確認事實與假設。

如果 findings 互相衝突，可以要求主 agent 做 reconciliation：

有兩項調查結果似乎互相衝突。
請比較兩者，並說明哪一項有較充分的證據支持。
這件事解決前不要開始建置。

Subagents 與 Plan Mode 的關係

Subagents 常常適合搭配 Plan Mode。你可以先讓 subagents 調查，再讓 Plan Mode 把調查結果變成 plan。

典型流程：

Subagents（子代理）調查 -> Main agent（主代理）彙整 -> Plan Mode 建立計畫 -> 你審查 -> Build Mode 實作

這比直接 Build 更適合大型任務。

例如你要加 Paddle payment unlock，不應該直接說「幫我加付費功能」。更好的流程是：

1. 用 subagents 調查現有 auth（驗證）、pricing UI（使用者介面）、feature gating、backend（後端）狀態。
2. 用 Plan Mode 設計 payment flow 和 entitlement（權益）model。
3. 審查 Paddle go-live 需求與 non-goals。
4. 最後才 Build Phase 1。

實作練習

拿你前面建立的 AI Writer Landing 或任一 Lovable project（專案），假設你要把它升級成 AI writing SaaS。

不要直接 build。先用 subagents 做調查。

提示詞：

請使用 Subagents 協助我評估如何把這個產品介紹頁發展成 AI 寫作 SaaS。

調查項目：
1. 目前的頁面結構和可重複使用的元件。
2. MVP 需要哪些新的使用者流程。
3. 後續會出現哪些後端、身分驗證、AI 和付款相關考量。
4. 第一階段應排除哪些項目。

請回傳一份精簡的決策備忘錄。
不要修改檔案。

預期結果：

• 你得到一份 project（專案）assessment。
• 你知道目前 project（專案）離 SaaS 還缺哪些能力。
• 你有一份更清楚的 Phase 1/Phase 2 邊界。
• 你沒有在資訊不足時直接開始 Build。

常見錯誤

錯誤 1：以為 Subagents 會幫你改 code

Subagents 是唯讀的。真正改檔案的是 main Lovable agent。

錯誤 2：問題拆得太模糊

「研究一下這個 app」太空。拆成 auth（驗證）、data flow、UI（使用者介面）、performance、integration 等面向。

錯誤 3：不看 evidence

沒有證據的 findings 只能當建議。大型改動前要要求 traceable evidence。

錯誤 4：把 findings 當 final plan

Findings 是調查結果，不是實作計畫。要再轉成 plan，review 後才 Build。

錯誤 5：小事也要求 subagents

改文案、改 spacing、加 FAQ 不需要 subagents。工具要用在能降低不確定性的地方。

上線前檢查清單

• [ ] 任務足夠複雜，值得使用 subagents。
• [ ] 調查問題已拆成獨立面向。
• [ ] 已要求 findings 格式。
• [ ] Findings 有 evidence 或 file references。
• [ ] 已分清 facts、assumptions、recommendations。
• [ ] Main agent 已綜合 findings。
• [ ] Findings 已轉成 plan，而不是直接 Build。
• [ ] 有處理互相矛盾的 findings。
• [ ] Subagents 沒被用在低價值小任務。

延伸閱讀

• Subagents（子代理）
• Plan Mode（規劃模式）
• Agent Mode（建置模式）

名詞解釋與延伸提問

• Subagents：把調查、分析或修復拆給多個 AI 子任務協作的能力。
• Parallel investigation：同時從不同角度調查問題，例如資料、UI（使用者介面）、權限與錯誤訊息。
• Synthesis：把多個調查結果整理成可執行結論。
• Root cause：造成問題的真正原因，而不是表面症狀。

如何問延伸問題

讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：

• 「請根據我的專案，重寫本章的檢查清單。」
• 「我的目前版本最可能在哪三個地方失敗？」
• 「請把本章流程改成我下一次可以直接貼上的提示詞。」
• 「如果我要在兩天內完成 V1，哪些範圍應該先刪掉？」

嗨！我是 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。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！