Spec v3:集團架構 + 開分店顧問 AI + V2 整合

2026-05-20 · 老闆 audit 完跨 App 權限後問:「總部+區經理會多出什麼?可以推測還能怎麼用?開分店顧問?BYOA?整合 V2?」這份是答案。承接 V1 + V2 critique
TL;DR — V3 把 V2 從「單店 AI 報告」擴成「集團智慧作業系統」。三個關鍵新東西:(1) 開分店顧問 AI(業界沒人做,我們的殺手 feature)、(2) BYOA 接入點(餐廳接自家 OpenAI/Claude/Gemini)、(3) tactic_plans 加 restaurant_id 修設計債(V2 在這裡卡關,V3 修)。

3 個一定要先知道的

  1. F6 migration 已建好集團 schema 但沒功能restaurant_groupsgroup_memberslocal_overrides 表都在,visibility='group' 欄位也在 recipes/ingredients/vendors,GroupDashboardView 雛形也有。V3 把這些功能完整做出來,不是從零起。
  2. 業界 SMB 集團市場是空的 — Toast Enterprise 服務 50+ 店大集團,Lightspeed 服務 6-160 店,Square 沒集團概念。2-25 店的「想擴張的單店 / 小集團」沒人服務。ChefsMate 的甜蜜點。
  3. 「開分店顧問 AI」是 ChefsMate 獨家 — 我們已 own 客戶/銷售/員工/財務全資料,可以客觀算 readiness。Toast / Lightspeed 都假設你已決定要開,只賣工具。我們可以更早介入 — 在客戶還是「單店但想開分店」階段就用 AI 教育、評估、規劃。這會是 starter → growth → multi 升級的核心引擎
目錄
  1. 為什麼現在做這個
  2. 三層 RBAC + Schema 設計
  3. HQ 視角 — 多出哪 6 大類功能(完整 inspect)
  4. 區經理視角 — 巡店 + 區域目標
  5. 中央廚房
  6. ⭐ 開分店顧問 AI Agent
  7. AI 智慧報告 V2 → V3 升級
  8. BYOA(Bring Your Own AI)接入點
  9. 訂閱層級對齊業界
  10. 12 個月實作 phases
  11. Open questions

為什麼現在做這個

2026-05-20 audit 跨 App 權限後的 4 個發現:
  1. F6 migration 已 deploy(restaurant_groups / group_members / local_overrides)— 但只有 schema 和 GroupDashboardView 雛形,功能沒做完。
  2. POS / Customer App 已用 per-restaurant SQLite container 物理隔離 — 集團切店體驗已通暢。
  3. RLS P0 漏洞已修(2026-05-20 migration) — 安全層 ready,可以放心擴 group features。
  4. 單店訂閱已飽和 — 老闆們開始問「我想開第二家,你的系統能跟我一起嗎?」
業界 multi-location SMB 是空白市場
競品單店2-5 店6-25 店25+ 店
Square🟡 flat locations
Toast Standard🟡 basic multi⚠️ Toast 強迫升級 Enterprise✅ Enterprise
Lightspeed
ChefsMate V3MultiGroupEnterprise
Lightspeed 是直接競爭者,但他們是西方品牌,在台灣的服務、繁中、本地金流(藍新/綠界)、政府開放資料(假日/勞基法)幾乎沒有。ChefsMate 已有的本土化是 moat

三層 RBAC + Schema 設計

角色階層

層級角色scope可做
集團HQ Owner全集團所有事 + 邀請 HQ Admin / 區經理 / 店長
HQ Admin全集團讀寫所有店資料但不能改集團 owner
區域Region Managerrestaurant_scope[]只能讀寫 scope 內的店
單店Store Owner單店該店所有事
Store Manager單店該店日常營運(不能改訂閱)
Staff單店打卡 / 點餐 / 查排班

Schema 變更

-- 1. group_members 加 restaurant_scope (區經理用)
ALTER TABLE group_members
  ADD COLUMN restaurant_scope UUID[] DEFAULT NULL;
  -- NULL = 全集團 (HQ tier)
  -- 有值 = 區經理只能訪問這幾家店

-- 2. helper function 升級認 scope
CREATE OR REPLACE FUNCTION public.get_my_restaurant_ids()
RETURNS SETOF UUID AS $$
DECLARE v_user_id UUID;
BEGIN
  v_user_id := public.get_my_profile_id();
  IF v_user_id IS NULL THEN RETURN; END IF;

  -- 既有: restaurant_members
  RETURN QUERY
  SELECT rm.restaurant_id FROM public.restaurant_members rm
  WHERE rm.user_id = v_user_id AND rm.status = 'active';

  -- 新增: group_members (HQ / 區經理)
  RETURN QUERY
  SELECT r.id FROM public.restaurants r
  WHERE r.group_id IN (
    SELECT gm.group_id FROM public.group_members gm
    WHERE gm.user_id = v_user_id
      AND (gm.restaurant_scope IS NULL OR r.id = ANY(gm.restaurant_scope))
  );
END;
$$ LANGUAGE plpgsql SECURITY DEFINER SET search_path = public;
NEW Single source of truth for tenant access
get_my_restaurant_ids() 統一回該 user 能訪問的所有 restaurant_id。RLS policies 全部 reuse 這個 function,加區經理只改一處。

HQ 視角 — 多出哪 6 大類功能

1. 集團儀表板

NEW

2. 商品策略(業界對標 Lightspeed Multi-Location Menu)

NEW

3. 中央採購 + 中央廚房(見 §5)

NEW 簡介:集中採購壓低供應商議價、中央備料降低各店人事成本、配送路線優化。

4. 員工調度

NEW

5. 財務整合

NEW

6. 行銷

NEW

你推測還能怎麼用 — 我列 6 個沒人想到的

推測 A. 集團 NPS 競賽 — 每月公佈各店 NPS 排名,前 3 名分紅、後 1 名上 HQ review。
推測 B. 跨店「最佳實踐 (Best Practice) 自動發掘」 — AI 看哪家店某指標突然變好,自動 reverse-engineer 是什麼變化(菜單?定價?員工?)然後建議推給其他店。
推測 C. 客戶跨店追蹤 — 老客在海邊店點過 50 次,第一次到溪邊店,POS 自動提醒店員「VIP 客戶,知道他吃辣不吃香菜」。
推測 D. 集團 supply chain finance — 集團統一給供應商月結 → 用集團信用換更好的付款條件(60 天 vs 30 天)→ HQ 統一管理供應商風險。
推測 E. 同集團「找朋友」 — 客人在 A 店 wallet pass 顯示「你的朋友也常來這集團」,促進跨店推薦。
推測 F. 集團「副廠機制」 — 集團統計食材消耗 → 自動拆給 3 家供應商(主廠 60% / 副廠 30% / 緊急廠 10%)→ 避免單一供應商斷貨風險。Toast / Lightspeed 都沒這個。

區經理視角 — 巡店 + 區域目標

區域儀表板

NEW

巡店 (Field Visit) 系統

NEW
CREATE TABLE field_visits (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  group_id UUID NOT NULL REFERENCES restaurant_groups,
  restaurant_id UUID NOT NULL REFERENCES restaurants,
  region_manager_id UUID NOT NULL,
  visited_at TIMESTAMPTZ NOT NULL,
  checklist_responses JSONB,        -- {"廚房整潔": 5, "員工儀容": 4, ...}
  photos TEXT[],                     -- Supabase Storage URLs
  overall_score INT,
  issues JSONB,                      -- [{severity: 'high', desc: '...', assigned_to: UUID}]
  follow_up_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT now()
);

區域目標管理

NEW

中央廚房 (Central Kitchen)

為什麼集團要中央廚房

3-5 家店之後,各店各自備醬料 / 切肉 / 烘培,人事成本爆炸。業界主流(王品 / 鼎泰豐 / 八方雲集)都有中央廚房 — 把標準化、可運送的工作集中,各店只做最後組裝+出餐。降低各店廚師依賴 + 提升品質一致性。

Schema

CREATE TABLE central_kitchens (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  group_id UUID NOT NULL REFERENCES restaurant_groups,
  name TEXT NOT NULL,
  address TEXT,
  capacity_kg_per_day INT,
  active BOOLEAN DEFAULT true,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE central_kitchen_products (
  -- 中央廚房做哪些半成品 / 成品
  id UUID PRIMARY KEY,
  kitchen_id UUID NOT NULL REFERENCES central_kitchens,
  -- 對應到 menu_items 或 ingredients
  source_recipe_id UUID REFERENCES recipes,
  produces_ingredient_id UUID REFERENCES ingredients,
  -- "300g 一袋的滷肉醬"
  unit_size NUMERIC, unit_label TEXT,
  cost_per_unit NUMERIC,             -- 中央廚房內部成本
  transfer_price NUMERIC             -- 賣給分店的價(內部轉撥)
);

CREATE TABLE central_kitchen_orders (
  -- 各店向中央廚房叫貨
  id UUID PRIMARY KEY,
  kitchen_id UUID NOT NULL,
  restaurant_id UUID NOT NULL,
  delivery_date DATE NOT NULL,
  status TEXT,                       -- pending / packed / shipped / delivered
  items JSONB                        -- [{product_id, qty, transfer_price}]
);

新增功能

NEW

⭐ 開分店顧問 AI Agent

KILLER 這是 ChefsMate V3 最大差異化 — 業界沒人做。Toast / Lightspeed 都假設客戶已決定要開,他們只賣 onboarding 工具。我們在客戶還在「想但不敢開」階段就介入,變成 starter → growth → multi 訂閱升級的天然漏斗。

為什麼 ChefsMate 能做這個而別人不能

  1. 已 own 客戶銷售/客流/客單價/翻桌率 → 算營收 readiness
  2. 已 own 員工排班/薪資/retention → 算團隊 readiness
  3. 已 own 食材成本/利潤率/現金流(藍新/Stripe) → 算財務 readiness
  4. 已 own NPS/取消率/回流率 → 算品牌 readiness
  5. 有政府開放資料(假日/勞基法/商業司登記) → 算市場 readiness

5 維度評分演算法(第一版用 expert rule,後期 ML)

CREATE TABLE expansion_readiness_scores (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  restaurant_id UUID NOT NULL REFERENCES restaurants,
  computed_at TIMESTAMPTZ NOT NULL DEFAULT now(),

  -- 5 維度 (0-100)
  financial_score INT,            -- 現金流月數 / 毛利率 / 負債比 / 應收帳款週轉
  operational_score INT,          -- SOP 完整度 / 員工 retention / 出餐穩定度
  brand_score INT,                -- NPS / 客戶回流率 / 社群觸及
  team_score INT,                 -- 副店長 ready / 二廚 ready / 招募 pipeline
  market_score INT,               -- 商圈飽和度 / 競品密度 / 房租 ROI 預估

  overall_score INT,              -- 加權總分
  recommendation TEXT,             -- AI 生成的整體建議
  blockers JSONB,                 -- [{dim:'financial', issue:'現金流只夠 3 個月', severity:'high'}]
  next_actions JSONB,             -- [{action:'招募並訓練副店長', months_needed:6, cost:200000}]

  ai_provider TEXT,                -- 'chefsmate' / 'openai' / 'anthropic' / BYOA
  ai_model TEXT                    -- 'claude-opus-4-7' / 'gpt-4-turbo' / etc
);

AI 對話流程

1. POS 主控台側欄出現「想開分店嗎?」icon (對 starter/growth tier 才顯示)

2. 點下去 → 進「擴張顧問」對話介面
   AI: 「我看了你最近 6 個月資料,目前 readiness 是 62/100。
        最大的 blocker 是現金流和團隊。要不要我細講?」

3. AI 列具體 blocker:
   🔴 現金流:目前每月淨利 ¥80k,新店需 ¥1.2M 開辦 + ¥150k/月燒錢。
      你的緩衝期只夠 3 個月,建議再存 ¥900k 或找投資人。
   🟠 團隊:目前主廚一人 dependency,二廚未訓 lead。
      建議招募並訓練二廚 6 個月,讓本店 SOP 可不靠你跑。
   🟢 品牌:NPS 72(優),客戶回流率 45%(高於業界 30%)— 你有客群可以複製。

4. AI 提 12 個月 roadmap:
   M1-M3: 招募二廚 + 開始 SOP 文件化
   M4-M6: 二廚獨立帶班 1 個月,觀察出餐穩定
   M7-M9: 存夠開辦金 + 開始看店面
   M10-M12: 簽約 + 裝潢 + 開幕

5. 月度 review:
   每月 1 日,AI 自動跑分數,推播給老闆
   分數變化 + 是否在 roadmap 上 + 建議下個月重點

readiness >= 80 自動觸發升級流程

NEW 系統主動 prompt:「你的 readiness 88/100 — 準備好了。要不要升級到 Multi tier?Multi tier 開新店 wizard 會用你的現店資料一鍵 clone 設定。」

AI 智慧報告 V2 → V3 升級

V2 是什麼(回顧)

V2 critique 的核心:

V3 新增能力

A. 集團維度查詢 (cross-store)

NEW
// 新 tool definitions (Anthropic Tool Use schema)
{
  name: "compare_stores",
  description: "比較集團內多家店的指標",
  input_schema: {
    type: "object",
    properties: {
      restaurant_ids: { type: "array", items: { type: "string" } },
      metric: { enum: ["revenue", "gross_margin", "customer_count", "table_turnover", "nps"] },
      period: { type: "object", properties: { from: "date", to: "date" } }
    }
  }
}
老闆可問:「比較我集團 3 家店這個月毛利率」/「為什麼海邊店這月來客數比溪邊少 20%?」AI 自動跑工具回答。

B. 戰術規劃 V3 — 修 tactic_plans 設計債

⚠️ 設計債:目前 tactic_plans / tactic_plan_items / tactic_plan_histories 三張表完全沒 restaurant_id 欄位。從 2026-05-20 RLS audit 發現的 — 這意味著 RLS 只能用 is_authenticated(),任何登入用戶看到任何餐廳的戰術 plan。
FIX V3 migration:
ALTER TABLE tactic_plans ADD COLUMN restaurant_id UUID REFERENCES restaurants;
ALTER TABLE tactic_plans ADD COLUMN group_id UUID REFERENCES restaurant_groups;
-- 舊資料回填(如果有的話):由現有 user_profile_id → restaurant_members → 第一家店
UPDATE tactic_plans SET restaurant_id = (...) WHERE restaurant_id IS NULL;
ALTER TABLE tactic_plans ALTER COLUMN restaurant_id SET NOT NULL;

-- 同步 tactic_plan_items(透過 plan_id → restaurant_id)和
-- tactic_plan_histories(同模式)

-- RLS
ALTER TABLE tactic_plans ENABLE ROW LEVEL SECURITY;
DROP POLICY dev_full_access ON tactic_plans;
CREATE POLICY tp_member_access ON tactic_plans FOR ALL
  TO authenticated
  USING (restaurant_id IN (SELECT get_my_restaurant_ids()))
  WITH CHECK (restaurant_id IN (SELECT get_my_restaurant_ids()));
NEW 集團戰術規劃:HQ 訂目標 → AI 拆到各店

C. 開分店顧問 (見 §6)

NEW 透過 ReadinessScore tool 接入 V3 architecture。AI agent 用 ToolUse 跑各維度評分函數。

D. 中央廚房優化建議

NEW 老闆問:「如果海邊店的醬料改從中央廚房送,省多少?」 AI 跑 cost calculator tool → 用各店食材消耗 + 中央廚房 capacity + 配送成本 → 回估計值。

BYOA — Bring Your Own AI 接入點

為什麼餐廳會想 BYOA

設計:Provider Adapter Interface

// 1. restaurant_settings 加 ai_config column
interface AIConfig {
  provider: 'chefsmate' | 'openai' | 'anthropic' | 'gemini'
          | 'azure-openai' | 'aws-bedrock' | 'self-hosted';
  api_key_vault_id?: string;  // Supabase Vault 加密儲存
  model?: string;             // 'gpt-4-turbo' / 'claude-opus-4-7' / 'gemini-1.5-pro'
  endpoint?: string;          // Azure / self-hosted custom URL
  system_prompt_override?: string;  // 集團 brand-specific
  monthly_token_cap?: number; // 自我約束(避免突然爆量)
}

// 2. 抽象成 ProviderAdapter
abstract class AIProviderAdapter {
  abstract async run(messages: Message[], tools: Tool[]): Promise<ToolUseResult>;
}

class AnthropicAdapter extends AIProviderAdapter { /* V2 既有 */ }
class OpenAIAdapter extends AIProviderAdapter { /* GPT-4 function calling */ }
class GeminiAdapter extends AIProviderAdapter { /* Google function calling */ }
class AzureAdapter extends AIProviderAdapter { /* Azure OpenAI endpoint */ }
class BedrockAdapter extends AIProviderAdapter { /* AWS Bedrock invoke */ }

// 3. Edge function 統一入口
// supabase/functions/ai-report/index.ts
const adapter = await getAdapterForRestaurant(restaurant_id);
const result = await adapter.run(messages, tools);
return result;

Tool definitions 統一不變

NEW 各 provider 都用同一套 tool schema(我們的 widget library)。 Anthropic Tool Use / OpenAI Function Calling / Gemini Function Declarations 在 JSON schema 上 99% 相容。 V3 抽象層只負責 message 格式轉換。

Pricing 策略

方案誰付 LLM 費用ChefsMate 收
ChefsMate AI(內建)ChefsMate訂閱費含 token cap(超出限速,不額外計費)
BYOA(自接)餐廳自己付 OpenAI/Anthropic不另收 AI 費用,僅一次性 setup fee ¥5000
Enterprise BYOA(Azure/Bedrock)客戶 cloud account整合 SLA fee,custom quote

訂閱層級對齊業界

Tier月費店數核心功能AI
Free$01訂位 / 點餐 / 結帳 basic-
Starter$301+ 會員卡 + 報表內建,100k token/月
Growth$801+ 完整功能 + 串接內建,500k token/月 + 開分店顧問 ⭐
Multi 🆕$2002-5+ Group dashboard + 跨店比較內建,2M token/月 + 集團維度
Group 🆕$5006-25+ 區經理 + 中央廚房內建,8M token/月 + 全功能
Enterprise 🆕custom25++ BYOA + SLA + custom dashboardBYOA(Azure/Bedrock)
對標:Toast Enterprise 每店 $69-165/月 + processing fee,Lightspeed Multi-Location 起跳 $129/月。 ChefsMate $200/Multi (2-5 店均攤每店 $40-100) 對中小集團有競爭力。

12 個月實作 Phases

Phase月份主題產出
P1M1-M23 層 RBAC + 區經理 group_members.restaurant_scope[] / get_my_restaurant_ids() 升級 / POS 區經理選店 picker / web /group/[slug]/region route
P2M3-M4集團儀表板 SQL views(group_daily_revenue 等)/ web GroupDashboardView 完整實作 / Realtime cross-store / 異常檢測 alert
P3M5-M6中央廚房 central_kitchens schema / 叫貨 UI / 配送路線 / 內部轉撥計帳
P4M7-M8AI V3 升級 + BYOA ProviderAdapter abstraction / tactic_plans 加 restaurant_id 修設計債 / 集團 tool definitions / BYOA UI
P5M9-M10開分店顧問 AI ⭐ expansion_readiness_scores schema / 5 維評分 / AI agent dialogue / Roadmap generator / 月度 review job
P6M11-M12Enterprise tier SLA infra(uptime + on-call) / Custom dashboard builder / Azure/Bedrock integration / dedicated CSM playbook

Open Questions(老闆要拍板)

Q1:tactic_plans 加 restaurant_id 怎麼回填?
現有資料(若有)需要某種對應規則。建議:由 user_profile_id → restaurant_members(取第一家 active store)。但如果是多店老闆已存了多店的 plan,可能會回填錯。需要先 query 看看有多少筆要處理。
Q2:BYOA 怎麼防 API key 洩漏?
選項:A. Supabase Vault(原生加密)/ B. AWS KMS / C. 餐廳每次 request 自己附 key。Vault 最簡單但要驗證生產環境 capability。
Q3:中央廚房成本內轉的會計模型對嗎?
目前設計:中央廚房算成本中心(損益歸 HQ),各店看「採購自中央廚房」=外部供應商一樣的入帳。但會影響稅務(集團內企業之間轉撥要不要開發票?要不要做 transfer pricing?)。建議找會計師 review 後再 finalize。
Q4:開分店 readiness 演算法權重?
第一版 expert rule:財務 30% + 營運 25% + 品牌 15% + 團隊 20% + 市場 10%。建議跟 5 個真實有開分店經驗的老闆 sanity check 後再 lock。
Q5:HQ tier 看員工個資?
區經理巡店看員工出勤、HQ Admin 看薪資 — 多大程度可讀員工 staff_personal_info?個資法 + 員工知情同意 怎麼設計?
Q6:集團會員卡 = 集團一張 vs 各店各一張?
Pros & cons:單卡通用對客戶體驗好,但若集團解散 / 加盟主退出,客戶資料歸屬權糾紛大。建議 default 各店一張,集團主動「啟用跨店」需要 group_owner 確認。

與 V2 spec 的關係

V3 is a strict superset of V2. V2 可以單獨上線(已 commit)。V3 需要 12 個月分 6 phases ship。
參考文件: V1 完整四層架構 · V2 critique + 業界對標 · 2026-05-20 跨 App 權限 audit