本章目標

讀完這一章，你會知道如何把一次成功的 提示詞、規則、審查流程和團隊習慣，轉成 Lovable 可以長期使用的上下文。你會分清楚 Knowledge、Skills 和 Cross-project（專案）referencing 的用途，並學會把它們組成一套可重複的 agentic workflow（工作流）。

這章的重點不是「多放一些背景資料」。重點是讓 Lovable 每次工作時，都更像懂你產品、懂你團隊、懂你專案歷史的協作者。

為什麼這一章重要

前面幾章你已經學會了三件事：

• 用 Plan Mode 想清楚。
• 用 Build Mode 實作。
• 用 Subagents 拆調查。

但如果每次都要重新解釋產品、設計規則、程式風格、禁忌、測試要求、發布流程，你會很快累。更糟的是，不同團隊成員可能用不同方式 提示詞，導致同一個 workspace（工作區）裡的專案風格不一致。

Knowledge 和 Skills 解決的是「重複說明」的問題。

Knowledge 讓 Lovable 長期記得常駐背景。Skills 讓 Lovable 在特定任務出現時載入對應 playbook。Cross-project（專案）referencing 則讓 Lovable 讀取同一 workspace（工作區）內其他專案的既有實作，避免每次從零開始。

這三者合起來，就是把你的工作方式產品化。

思考模型：三種不同的記憶

你可以用三層記憶理解這章：

Knowledge = 永遠要知道的背景與規則
Skills = 特定任務才載入的工作手冊
Cross-project referencing = 從其他專案複用既有實作

Knowledge 適合放「每次都要遵守」的規則。例如 coding standard、品牌語氣、UI（使用者介面）design guideline、domain terminology、architecture decisions。

Skills 適合放「只有某類任務才需要」的流程。例如 launch checklist、SEO audit、accessibility review、release notes、Paddle go-live review。

Cross-project（專案）referencing 適合放「這個做法已經在另一個 project（專案）裡做過」的複用。例如沿用主站的 auth（驗證）flow、複用品牌色、參考另一個 app 的 onboarding。

如果你把三者混在一起，Lovable 會收到太多不必要或衝突的上下文。正確分類，是讓 agentic workflow（工作流） 穩定的關鍵。

Knowledge: 永遠放在背景裡的規則

Knowledge 分成 workspace（工作區）knowledge 和 project（專案）knowledge。

Workspace（工作區） knowledge 是整個 workspace（工作區）共用的規則。它適合放跨專案都該遵守的東西：

• Coding style。
• Naming conventions。
• Preferred libraries。
• Architecture rules。
• Testing requirements。
• Brand voice。
• Things Lovable should avoid doing。

Project（專案） knowledge 則是單一 project（專案）的背景。它適合放：

• 這個 app 是做什麼的。
• 目標使用者。
• 重要 user journeys。
• database schema 或 key tables。
• domain terminology。
• 專案特定 constraints。
• design guidelines。
• security 或 compliance requirements。

簡單判斷：

所有專案都要遵守 -> workspace knowledge
只有這個專案要知道 -> project knowledge

圖 7-1：Knowledge 會持續放進 Lovable 的上下文；共通規則放 workspace，單一產品的背景、架構與術語放 project。

專案知識範例

以下是一個適合放在 AI writing SaaS 的 project（專案）knowledge 範例：

專案概述
這是一個為台灣創作者和小型行銷團隊設計的 AI 寫作 SaaS。
產品協助使用者把零散筆記整理成完整的繁體中文社群貼文。

主要使用者
- 撰寫 LinkedIn、Threads 和電子報內容的個人創作者。
- 製作行銷活動文案的小型行銷團隊。

目前階段
- 採用前端優先策略的 MVP。
- 未經明確核准前，不要連接付款、AI API 或正式環境資料庫。

設計方向
- 有編輯感、聚焦且值得信任。
- 請使用繁體中文使用者介面文案。
- 避免使用空泛的 SaaS 填充文案。

架構規則
- 產品介紹頁的各區塊應保持模組化。
- 除非目前任務明確要求，否則不要加入身分驗證。
- 在純前端階段不要引入後端服務。

術語
- 「草稿」是指 AI 產生的寫作內容。
- 「創作者」是指產生內容的終端使用者。
- 「Pro」是指尚未實作的未來付費方案。

這份 knowledge 會讓 Lovable 在後續提示詞中更少猜測。你不用每次都重複「台灣創作者」、「繁體中文」、「先 frontend（前端）-first」。

Skills: 把任務流程變成 playbook

Skills 和 Knowledge 最大差別是：Skills 不會每次都載入。只有當 request 符合 skill description，或你用 /skill-name 直接叫它時，Lovable 才會使用。

這讓你可以在 workspace（工作區）裡保存很多專門流程，而不會讓每個提示詞都背負所有規則。

適合做成 Skills 的任務：

• Launch checklist。
• SEO review。
• Accessibility pass。
• Landing page critique。
• Paddle go-live readiness。
• Security review。
• Release notes。
• Customer support reply。
• Partner handoff checklist。

不適合做成 Skill 的內容：

• 每次都要遵守的 coding standard。
• 專案目前商業目標。
• 產品 domain terminology。
• 永久的 design system 規則。

這些應該放 Knowledge。

圖 7-2：Skills 是有名稱與 description 的按需 playbook，可由斜線指令或符合任務時自動載入，不必每則訊息都攜帶。

一個 Skill 應該長什麼樣

每個 Skill 有三個核心部分：

• Name：短且固定，例如 launch-checklist。
• Description：Lovable 用來判斷何時載入的 trigger。
• Instructions：實際要遵守的 markdown playbook。

Description 是最容易被低估的部分。它不能只寫「Helps with launch」。它要說清楚何時用、何時不用。

不好的 description：

協助上線。

比較好的 description：

當我說準備上線、交付、發布，或要和使用者分享專案時使用。請先執行上線前準備檢查，再判斷「可上線」或「不可上線」。不適用於早期原型回饋。

清楚的 description 可以避免 skill 在不該出現時亂入。

Skill 範例: Paddle go-live review

這本書第 11 章會以 Paddle 作為台灣讀者的金流主線。你可以先把 Paddle 上線前檢查做成 skill。

Name:

paddle-go-live-review

Description:

當我要檢查含 Paddle 付款功能的 Lovable 應用程式是否準備正式上線時使用。請檢查產品準備程度、法律頁面、結帳行為、權益判斷邏輯、測試模式和 Paddle 人工驗證步驟。不用於從零實作付款功能。

Instructions:

Paddle 正式上線檢查

在判定應用程式可以接受真實付款前，請檢查：

產品和價格
- 產品名稱和價格清楚。
- 價格方案頁說明使用者能獲得什麼。
- 沒有造成誤解的暫用文案。

法律和信任頁面
- 隱私權政策存在。
- 服務條款存在。
- 退款政策存在。
- 聯絡資訊可見或容易取得。

結帳和權益
- 測試結帳成功。
- 已處理付款失敗狀態。
- 只有付款成功後才解鎖付費功能。
- 除非產品規則明確要求，已取消或失效的訂閱不會繼續保有存取權限。

Lovable 和 Paddle 準備狀態
- 最新應用程式版本已發布。
- Paddle 驗證或 KYC/KYB 狀態仍需人工確認。
- 網域審查可能仍需人工確認。
- 必須在 Paddle 儀表板中檢查撥款設定。

輸出格式
- 通過
- 未通過
- 需要人工確認
- 建議修正方式

不要提供法律或稅務建議。遇到法律、稅務、撥款和服務商資格項目時，請標記為需要人工確認。

這個 Skill 的重點不是替你完成法律判斷，而是讓 Lovable 每次 review Paddle 上線時都不漏掉基本面。

Cross-project（專案）referencing: 複用已經做對的東西

如果你在同一 workspace（工作區）裡已經有一個 project（專案）做好了 auth（驗證）flow、pricing layout、brand style、onboarding，你不一定要重新描述。

Cross-project（專案）referencing 讓 Lovable 讀取同 workspace（工作區）中你有權限存取的其他 project（專案）。它可以看 file structures、source code、相關 chat history，也可以複用 assets，例如圖片和 fonts。被 reference 的 project（專案）是 read-only，不會被修改。

常見用法：

請使用 @BrandSite 的標誌和色彩組合。

請使用 @MainApp 的身分驗證設定和 @ContactApp 的表單驗證模式，建置這個新手引導流程。

這在團隊裡很有價值。你可以把一個成功專案變成其他專案的參照來源。

圖 7-3：Cross-project reference 能唯讀探索另一個專案的檔案、程式碼、聊天紀錄與資產；來源專案不會被修改。

什麼時候用 Cross-project（專案）referencing

適合：

• 多個產品需要同一套 brand style。
• 想沿用已驗證的 auth（驗證）flow。
• 想複用 onboarding 或 pricing page 結構。
• 想參考另一個專案的 integration pattern。
• 想把 agency 或團隊常用模板複製到新 project（專案）。

不適合：

• 來源 project（專案）權限不清楚。
• 來源 project（專案）是過時做法。
• 你只是需要一段簡單 UI（使用者介面）。
• 來源 project（專案）在不同 workspace（工作區）。

Cross-project（專案）referencing 只能在同一 workspace（工作區）內使用，且受 project（專案）access 和 cross-project（專案）sharing 設定限制。Restricted project（專案）也不是所有 team members 都能 reference。

Workflow: 建立你的 Lovable 工作記憶系統

步驟 1：寫 workspace（工作區）knowledge

先定共通規則。

工作區規則
- 除非任務另有指定，使用者可見文案請使用繁體中文。
- 早期原型的 MVP 優先採用前端優先策略。
- 除非明確要求，否則不要加入付款、身分驗證或資料庫。
- 修改共用版面、身分驗證邏輯或付款邏輯前，請先詢問。
- 完成 Build Mode 任務後，摘要說明修改的檔案。
- 執行上線相關任務時，驗證行動版、SEO 基礎設定、安全性和暫用內容。

步驟 2：寫 project（專案）knowledge

每個 project（專案）補上自己的背景。

這個專案是為台灣創作者設計的 AI 寫作助理產品介紹頁。
目前階段：驗證產品定位並收集潛在客戶資料。
第二階段前，不要實作登入、Paddle 付款、AI API 呼叫或資料庫。
請使用有編輯感且值得信任的語氣。

步驟 3：建立 2 到 3 個高價值 Skills

一開始不要做太多。建議先做：

• launch-checklist
• landing-page-review
• paddle-go-live-review

步驟 4：標記可複用 project（專案）

把常用 reference project（專案）命名清楚，例如：

• BrandSite
• MainApp
• AuthTemplate
• PricingExperiment

這樣之後用 @ mention 時不容易選錯。

步驟 5：定期整理

Knowledge 和 Skills 會過期。當產品方向、技術選型、品牌語氣或上線流程變了，要更新它們。過時的指令比沒有指令更危險。

提示詞範例

範例 1：產生 專案知識

請協助我為這個應用程式撰寫 Project Knowledge 草稿。

請包含：
- 產品概述
- 目標使用者
- 目前階段
- 主要使用者流程
- 設計方向
- 架構限制
- Lovable 應避免執行的事項

內容請保持精簡，並寫成可長期沿用的指示。
不要修改應用程式。

範例 2：建立 上線檢查清單技能

請協助我建立一個名為 launch-checklist 的工作區 Skill。

當我說準備上線、交付、發布，或要和真實使用者分享專案時使用。

這個 Skill 應檢查：
- 核心使用者流程
- 行動版版面
- 暫用內容
- SEO 中繼資料
- 安全風險
- 如有身分驗證和權限，檢查其設定
- 如有付款功能，檢查其準備狀態

請針對每個項目回傳「通過」、「未通過」或「需要人工確認」。

範例 3：儲存成功流程為 skill

你剛才執行的審查很實用。
請把它儲存成 Skill。
當我要求在發布前評論產品介紹頁時，應套用這個 Skill。
請包含相同的審查結構、評分標準和輸出格式。

範例 4：複用其他專案

請使用 @BrandSite 作為這個專案的視覺參照。
沿用其標誌、色彩組合、字體風格和按鈕樣式。
不要複製無關的頁面或內容。
建置前，請說明會沿用哪些項目。

實作練習

回到你的 AI Writer Landing 專案，建立一套最小工作記憶系統。

任務：

1. 寫一份 project（專案）knowledge。
2. 寫一份 workspace（工作區）knowledge 草稿。
3. 設計一個 landing-page-review skill。
4. 如果 workspace（工作區）裡有另一個可參考 project（專案），用 cross-project（專案）reference 複用它的 logo 或色彩。
5. 要 Lovable review 目前 project（專案）knowledge 是否過長、過短或有衝突。

預期結果：

• Lovable 對你的產品背景理解更穩定。
• 你不用每次重複「繁體中文、台灣創作者、frontend（前端）-first」。
• 你有第一個可重複 review playbook。
• 你知道哪些規則該放 Knowledge，哪些該做 Skill。

常見錯誤

錯誤 1：把所有東西塞進 Knowledge

Knowledge 會常駐。只放每次都重要的背景。偶爾才用的 checklist 應該做成 Skill。

錯誤 2：Skill description 太模糊

Skill 是否觸發主要看 description。要寫清楚 use when 和 not for。

錯誤 3：Knowledge 過期

專案方向變了，Knowledge 沒改，Lovable 就會繼續照舊規則行動。

錯誤 4：Cross-project（專案）來源不乾淨

不要複用一個已經很亂、過時或有安全問題的 project（專案）。Reference 之前先 review。

錯誤 5：忽略權限

Cross-project（專案）referencing 受 workspace（工作區）、project（專案）access 和 sharing settings 限制。不要假設所有人都能 reference 所有專案。

上線前檢查清單

• [ ] Workspace（工作區） knowledge 只放跨專案共通規則。
• [ ] Project（專案） knowledge 只放該 project（專案）的背景和限制。
• [ ] Knowledge 具體、簡短、可執行。
• [ ] Skills 有清楚 name、description、instructions。
• [ ] Skill description 有 use when 和 boundary。
• [ ] 高價值重複流程已做成 Skill。
• [ ] 過時 Skills 已刪除或更新。
• [ ] Cross-project（專案）references 來自可信 project（專案）。
• [ ] Restricted 或敏感 project（專案）的 sharing 設定已確認。
• [ ] Knowledge 與 Skills 沒有互相矛盾。

延伸閱讀

• Knowledge（知識）
• Skills（技能）
• 跨專案引用

名詞解釋與延伸提問

• Knowledge：專案中長期保存的背景與規則，讓 Lovable 在後續提示中持續參考。
• Skills：可重複套用的工作方式或專業規則。
• Cross-project（專案）referencing：引用其他專案的設計、模式或實作方式。
• Team convention：團隊約定的命名、設計、權限與流程規則。

如何問延伸問題

讀完本章後，建議用自己的專案情境繼續追問 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 點額度。名額有限，送完為止！