讀完這一章，你會完成第四個端到端專案：一個企業內部營運工具。它包含 workspace（工作區）-only access、受控發布、角色感知畫面、外部商務資料整合、Slack 通知、GitHub sync、audit trail、security scan，以及一套適合團隊協作的 Lovable 工作流。
這章的重點不是「做一個 dashboard（儀表板）」。真正的重點是：
內部工具處理的是組織資料、團隊權限和營運流程，所以治理比畫面更重要。
內部工具通常不需要 SEO，也不需要公開流量。但它需要更清楚的 access boundary、更嚴格的 connector 權限、更可追蹤的變更紀錄，以及更可控的發布流程。
我們要做的產品叫做 OpsBoard。
OpsBoard 是一個內部營運看板，用來讓團隊集中查看客戶、案件、任務與異常狀態。它可以從 Airtable 或 HubSpot 讀取資料，讓團隊在一個更聚焦的 UI（使用者介面）裡處理日常工作，並在需要時把摘要或警示推送到 Slack。
第一版功能：
暫時不做：
這章是本書四個專案裡最接近「公司真的會拿去用」的案例。
內部工具有兩層 access：
這兩層彼此獨立。你把 project（專案）設成 workspace（工作區），不代表 live app 一定只有 workspace（工作區）members 能看。你把 website access 設成 workspace（工作區），也不代表所有 workspace（工作區）members 都應該能 edit project（專案）。
內部工具通常應該採用：
專案存取權：Workspace 或 Restricted
網站存取權：Workspace
應用程式層級驗證：必要
資料層級授權：必要
如果你的方案不支援 workspace（工作區）-only website access，就不能只靠「連結不要外流」。你至少要在 app 內加登入與權限，並評估是否需要 Business 或 Enterprise 的發布控制。
OpsBoard 可能處理：
這些不是公開網站資料。風險包含：
因此內部工具的開發節奏要比 landing page 更嚴格。
OpsBoard 第一版包含：
路由：
- /login
- /dashboard
- /customers
- /tickets
- /alerts
- /settings
角色：
- viewer：可以查看儀表板。
- operator：可以更新狀態並發送 Slack 通知。
- manager：可以檢視所有佇列並設定分派規則。
整合：
- 使用 Airtable 或 HubSpot 儲存營運紀錄。
- 使用 Slack 發送通知。
- 使用 GitHub 同步備份及審查程式碼。
治理：
- 網站僅限 Workspace 存取。
- 已檢查專案存取權。
- 限制外部協作者。
- 發布前執行安全掃描。
- Enterprise 方案需檢查稽核紀錄。
第一版可以先把 roles 存在 app database，不一定要做完整 workspace（工作區）group sync。重點是每個操作都要有權限意義。
圖 21-1：把內部工具邊界與角色需求送入 Lovable 後，右側生成具有 viewer、operator、manager 視角的 OpsBoard 儀表板。
提示詞：
請建立名為 OpsBoard 的 Lovable 應用程式。
產品：
OpsBoard 是供小型 B2B 團隊使用的內部營運儀表板。
用途：
- 協助團隊檢視客戶、服務單與營運通知。
- 從 Airtable 或 HubSpot 取得紀錄。
- 讓 operator 更新狀態。
- 讓 operator 將結構化通知發送到 Slack。
使用者：
- 營運團隊。
- 客戶成功團隊。
- 銷售經理。
存取方式：
- 這是內部工具。
- 不得允許公開存取。
- 若方案支援，已發布網站應僅限 workspace（工作區）成員存取。
- 必須有應用程式層級的身分驗證。
角色：
- viewer 可以查看儀表板。
- operator 可以更新狀態並發送 Slack 通知。
- manager 可以檢視所有佇列及管理分派設定。
第一階段先建置：
- 前端基本架構。
- 儀表板版面。
- 暫用資料。
- 依角色顯示的導覽。
- 暫不連接外部 connector。
先用 placeholder data 是刻意的。外部 connector 一旦接上，就涉及真實權限與第三方 API 限制。先把流程和 UI（使用者介面）固定好。
Project（專案） access 控制 editor、source code、chat history 和未發布變更。內部工具不應該開給整個世界，也不應該開啟 public remix。
建議：
提示詞：
請檢查 OpsBoard 的 Lovable 專案存取模型。
背景：
- 這是內部營運工具。
- 可能連接 Airtable、HubSpot 與 Slack。
- 可能包含客戶資料與內部工作流程。
請提出以下建議：
- 專案存取設定。
- 哪些人應受邀成為 editor。
- 哪些人應只有 viewer 權限。
- 是否應允許外部協作者。
- 開放 remix 或讓整個 workspace 編輯的風險。
Workspace（工作區） owners 仍然能存取 workspace（工作區）裡的 projects。不要把 Restricted 誤解成能排除 workspace（工作區）owner。
Published website access 是 live app 的入口控制。
內部工具最理想設定：
網站存取權：Workspace
這代表只有 authenticated workspace（工作區）members 能拜訪 live app。若方案不支援，請不要把 live URL 當成安全邊界。你必須靠 app-level auth（驗證）和 backend（後端）authorization。
提示詞：
請準備 OpsBoard 的發布存取設定。
需求：
- 這個應用程式僅供內部使用。
- 若功能可用，已發布網站應僅限 workspace（工作區）成員存取。
- 專案存取權與網站存取權必須分別檢查。
- 應用程式仍須要求使用者登入。
請回傳：
- 建議的發布設定。
- 網站存取權設為 Anyone 的風險。
- 發布前還需要執行的應用程式層級檢查。
這一步是 Chapter 17 的延伸：內部工具 publish 不是「不要公開宣傳」而已，是要明確設定 website access。
圖 21-2：送出 Auth／Roles prompt 並啟用 Lovable Cloud，實際生成 workspace-only 登入頁、profiles、角色 Policy 與受保護路由。
即使 website access 已限制 workspace（工作區），app 裡仍然要有角色與權限。
資料表：
profiles
- id
- user_id
- display_name
- role
- created_at
activity_logs
- id
- actor_user_id
- action
- target_type
- target_id
- metadata
- created_at
提示詞：
請為 OpsBoard 新增應用程式層級的身分驗證與角色權限。
角色：
- viewer 可以查看儀表板。
- operator 可以更新狀態並發送 Slack 通知。
- manager 可以檢視所有佇列並更新分派設定。
需求：
- 所有內部路由都必須登入才能使用。
- 儲存每位使用者的 profile 角色。
- 顯示依角色調整的導覽。
- 在後端邏輯中強制檢查角色，不能只限制前端介面。
- 請為重要操作建立 activity_logs。
- 不要讓使用者從前端變更自己的角色。
Role-aware UI（使用者介面）只是體驗。真正權限要在 backend（後端）function、RLS（Row Level Security，列層級安全） 或 connector action 前檢查。
OpsBoard 第一版可以選一個資料來源。
適合：
Airtable connector 使用 Personal Access Token。PAT 要限制 scopes 和 base access，只給 app 需要的資料表。
適合：
HubSpot connector 使用 service key，也要限制 scopes。
提示詞：
請協助我選擇 OpsBoard 的第一個資料來源。
選項：
- Airtable.
- HubSpot.
背景：
- 我們需要能檢視客戶、服務單和通知的內部儀表板。
- operator 可能需要更新狀態。
- manager 需要查看流程或佇列。
- 我們希望第一版盡可能精簡且安全。
請回傳：
- 建議使用的 connector。
- 必要的權限範圍。
- 需要讀取的資料表或物件。
- 需要寫入的欄位。
- 安全風險。
- 測試計畫。
第一版選一個就好。不要同時接 Airtable、HubSpot、Slack、Notion、Google Sheets。每個 connector 都是新的安全面。
如果選 Airtable，先指定 base、tables 和欄位。
提示詞：
請將 OpsBoard 連接至 Airtable。
使用情境：
- 從名為 `Operations` 的 Airtable base（資料庫）讀取營運紀錄。
- 資料表：`Customers`。
- 資料表：`Tickets`。
`Customers` 欄位：
- Name.
- Company.
- Status.
- Owner.
- Health.
- Last touch.
`Tickets` 欄位：
- Title.
- Customer.
- Priority.
- Status.
- Owner.
- Updated at.
需求：
- 將紀錄讀入儀表板的表格。
- operator 可以更新服務單狀態。
- viewer 不可更新紀錄。
- manager 可以依負責人與優先度篩選。
- 妥善處理 Airtable API 錯誤。
- 不要在前端程式碼中暴露 Airtable token。
若 app 需要寫回 Airtable，PAT 必須有 write scope。但請只給必要 base access，不要給整個 workspace（工作區）全權。
如果選 HubSpot，先定義 objects 和 actions。
提示詞：
請將 OpsBoard 連接至 HubSpot。
使用情境：
- 在內部儀表板顯示進行中的交易與支援服務單。
- 讓 operator 更新服務單狀態。
- 讓 manager 依負責人、階段與優先度篩選。
物件：
- `Contacts`：唯讀。
- `Companies`：唯讀。
- `Deals`：第一版唯讀。
- `Tickets`：可讀取及更新狀態。
需求：
- 請從後端程式碼使用 HubSpot connector。
- 不要在前端程式碼中暴露 service key。
- 將 HubSpot 錯誤轉換成容易理解的訊息。
- 將重要更新記錄至 activity_logs。
- 執行寫入操作前須檢查角色權限。
HubSpot API limits 和 scopes 由 HubSpot 帳號控制。Lovable 只是幫你把 connector 接進 app workflow（工作流）。
Slack 是內部工具很常見的輸出端。OpsBoard 可以在高優先度 ticket 或 deal 狀態變更時發 Slack alert。
提示詞：
請為 OpsBoard 新增 Slack 通知。
使用情境：
- operator 可以針對高優先度服務單，將結構化通知發送到 #ops-alerts。
需求：
- 請從後端邏輯使用 Slack connector。
- 只有 operator 和 manager 可以發送通知。
- viewer 不可發送通知。
- 通知訊息應包含服務單標題、客戶、優先度、狀態、負責人，以及返回 OpsBoard 的連結。
- 將每次 Slack 通知記錄至 activity_logs。
- 如果 Slack 發送失敗，顯示容易理解的錯誤，並維持原始紀錄不變。
- 不要在前端程式碼中暴露 Slack token。
注意 Slack private channel 需要 invite bot。若 alert 發不到 private channel，先確認 bot 是否在 channel 裡。
圖 21-3：把重要操作、欄位與 metadata 安全規則送入 Lovable，生成不可由前端編輯、依角色限制讀取的 activity log 模型。
OpsBoard app 內的 activity_logs 紀錄產品操作，例如：
Lovable workspace（工作區）audit logs 紀錄 workspace（工作區）和 project（專案）層級事件，例如：
兩者不同。
提示詞：
請設計 OpsBoard 的操作紀錄模型。
記錄以下操作：
- 服務單狀態已變更。
- Slack 通知已發送。
- manager 設定已更新。
- connector 同步失敗。
針對每筆紀錄，請儲存：
- actor_user_id.
- action.
- target_type.
- target_id.
- metadata.
- created_at.
規則：
- 使用者只能查看與其角色相關的操作紀錄。
- 操作紀錄不可從前端編輯。
- 不要在 metadata 中儲存密鑰或完整的 connector token。
Enterprise workspace（工作區）可以再用 Lovable audit logs 查 workspace（工作區）層面的治理事件。不要把 app activity log 當成完整合規系統。
內部工具常常會進入長期維護。這時 GitHub sync 很重要。
GitHub sync 的價值：
提示詞：
請準備將 OpsBoard 同步至 GitHub。
請檢查：
- 專案是否已準備好連接 GitHub。
- 建議使用的 repository 名稱。
- 應使用哪一個 branch。
- 哪些產生的檔案包含設定。
- 原始碼中是否意外包含密鑰。
- 適用於內部工具變更的程式碼審查清單。
注意：GitHub sync 不是讓所有人都能亂改。Lovable 的 GitHub workspace（工作區）connection 需要 workspace（工作區）admin 或 owner 設定，project（專案）repository link 也有角色要求。
內部工具應該檢查 workspace（工作區）-level controls：
提示詞：
請為 OpsBoard 建立 workspace（工作區）治理檢查清單。
請檢查：
- 預設專案存取權。
- 外部專案協作者。
- 預設網站存取權。
- 哪些人可以對外發布。
- 發現重大問題時阻擋發布。
- 首次發布前要求執行基本安全掃描。
- Connector 權限。
- GitHub 連線權限。
- Slack connector 權限。
- Airtable 或 HubSpot connector 權限。
- 稽核紀錄是否可用。
請回傳：
- 建議設定。
- 各項設定須由誰核准。
- 權限過於寬鬆的風險。
這不是每個 free/pro 個人專案都能完整設定，但作為 IT 書籍，讀者要知道企業場景該看哪些開關。
內部工具發布前要做 security review。
提示詞：
請為 OpsBoard 執行安全審查。
請著重檢查：
- 專案存取權。
- 已發布網站的存取權。
- 應用程式層級的身分驗證。
- 角色權限是否確實執行。
- Connector token 是否外洩。
- Airtable 或 HubSpot 的寫入權限。
- Slack 通知權限。
- 操作紀錄的完整性。
- 本機資料表的 RLS。
- 錯誤訊息。
- 敏感客戶資料。
- 同步至 GitHub 的程式碼。
請回傳：
- 阻擋發布的重大問題。
- 高優先度修正。
- 中優先度改善。
- 內部分享前需要執行的測試。
內部工具不代表風險較低。它通常比公開 landing page 更接近真實公司資料。
測試角色：
測試矩陣：
| Scenario | Anonymous | Viewer | Operator | Manager |
|---|---|---|---|---|
| Visit dashboard（儀表板） | blocked | allowed | allowed | allowed |
| View customers | blocked | allowed | allowed | allowed |
| Update ticket status | blocked | denied | allowed | allowed |
| Post Slack alert | blocked | denied | allowed | allowed |
| Update routing settings | blocked | denied | denied | allowed |
| View activity log | blocked | limited | relevant | full |
提示詞：
請為 OpsBoard 建立 Browser Testing（瀏覽器測試）計畫。
角色：
- 未登入使用者。
- viewer。
- operator。
- manager。
測試項目：
- 受保護路由的存取。
- 儀表板的讀取權限。
- 客戶資料表的讀取權限。
- 更新服務單狀態。
- 發送 Slack 通知。
- 更新 manager 設定。
- 操作紀錄的可見範圍。
- Connector 錯誤處理。
- 儀表板在手機或小螢幕上的可用性。
針對每個測試，請列出：
- 操作步驟。
- 預期結果。
- 該測試驗證的權限規則。
- 測試失敗是否會阻擋內部發布。
如果 connector write action 會影響真實資料，先用 test base、sandbox account 或 mock data。不要用 production（正式上線）CRM 做第一次 AI-generated workflow（工作流） 測試。
發布時設定：
專案存取權：Workspace 或 Restricted
網站存取權：Workspace
安全掃描：必要
重大問題：必須修正
正式環境冒煙測試：必要
Live smoke test：
提示詞：
請為 OpsBoard 建立內部發布檢查清單。
請包含：
- 專案存取權。
- 網站存取權。
- Workspace 成員。
- 外部協作者。
- 應用程式登入。
- 角色權限。
- Airtable 或 HubSpot connector。
- Slack connector。
- GitHub 同步。
- 安全掃描。
- 操作紀錄。
- 正式環境冒煙測試。
- 回復或取消發布計畫。
內部工具發布後也要有維護節奏。每次改 connector scopes、role rules、status workflow（工作流），都應該重新跑相對應測試。
建議順序：
1. 完成產品規格。
2. 審查專案存取權。
3. 規劃網站存取權。
4. 使用暫用資料建立前端基本架構。
5. 建立應用程式層級的身分驗證與角色權限。
6. 建立本機 profiles 與 activity_logs。
7. 選擇一個外部資料來源。
8. 連接 Airtable 或 HubSpot。
9. 新增會檢查角色權限的寫入操作。
10. 新增 Slack 通知。
11. 連接 GitHub 同步。
12. 完成 workspace（工作區）治理檢查清單。
13. 執行安全審查。
14. 依角色矩陣執行瀏覽器測試。
15. 內部發布。
這個順序能降低風險。先做內部邊界，再接外部資料。先接一個資料源，再加 Slack。先測角色，再 publish。
Project（專案） access 控制 editor。Website access 控制 live app。兩者要分開設定。
如果 live URL 是 Anyone，任何拿到連結的人都可能看到 app 入口。內部工具應該優先使用 workspace（工作區）-only website access。
Airtable PAT、HubSpot service key、Slack scopes 都要最小權限。不要為了省事給全域寫入。
Viewer 看不到按鈕不代表不能呼叫 backend（後端）。write action 必須在 backend（後端）檢查 role。
內部工具常常需要回答「誰改了這個狀態」。沒有 app-level activity log，產品操作很難追。
Audit logs 是 workspace（工作區）/project（專案）層級，不是你的 app 業務事件。兩者都重要，但用途不同。
第一次測 connector write action 應該用 test data。不要讓生成工具直接改真實客戶資料。
同步前檢查 source code，不要把 token、API key（API 金鑰）、內部資料寫進 repository。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術