第九章：企業遷移方案 | Chapter 9: Enterprise Migration Plan

目錄 | Table of Contents

1. 遷移目標
2. 遷移範圍盤點
3. 階段規劃
4. 多租戶設計
5. 組織變革管理
6. 風險與緩解
7. 成功指標
8. 附錄：架構決策記錄

1. 遷移目標 | Migration Objectives

1.1 現況摘要 | Current State

現行系統運行於個人 VPS（Oracle Cloud JP, ARM64, 4C/23GB），以單一使用者為中心：

• Claude Code 原生階層：~/.claude/CLAUDE.md (user) + ~/CLAUDE.md (workspace) + 子樹規則，形成三層指令傳遞鏈
• 39 位 Agent 架構：含決策層 6 位、協調層 1 位、產品層 2 位、執行層 24 位、驗證層 5 位、特殊 1 位
• 10 個 Skills：3 個核心長流程 skill（brand-research、marketing、research）+ 7 個輔助 skill
• Eval 框架：skill-eval protocol + skill-creator plugin，已完成三組 baseline（BR-001, MKT-001, RES-001）
• Hooks 系統：quality-gate（同步品質閘門）、debate-quality-judge（非同步辯論品質）、runtime-event-log（遙測）
• Library/Reference：方法論、框架、領域知識、來源清單，作為 Agent 的知識底座

核心問題：這套系統證明了 AI 輔助行銷調研的商業價值，但目前只有一個人能使用。公司需要讓行銷團隊也能操作，同時維持品質基準。

1.2 目標狀態 | Target State

1.3 遷移原則 | Migration Principles

1. 保留已驗證的架構核心：CLAUDE.md 階層、Agent registry、Skill dispatch、Eval protocol 是經過實戰驗證的，不應為了遷移而重寫
2. 增量改造而非重建：在現有架構上疊加多租戶與權限層，不從零開始
3. 品質基準可追溯：遷移前後的 skill 輸出品質必須可比較，使用既有 eval framework 作為驗收工具
4. 成本可預測：在放開使用前，必須有 quota 與審批機制

2. 遷移範圍盤點 | Migration Scope Inventory

2.1 必須遷移（原封搬移 + 最小調整）

2.2 需要調整（架構層級改造）

2.3 不遷移（個人/實驗性元件）

3. 階段規劃 | Phased Rollout

概覽

Phase 1 (1-2 週)          Phase 2 (2-4 週)           Phase 3 (1-2 月)
基礎環境 + 核心移植       多人存取 + Onboarding       Eval + 治理 + 全面運作
├─ 企業環境建置           ├─ 權限系統上線             ├─ Eval 框架導入
├─ CLAUDE.md 模板化       ├─ 行銷團隊帳號開通         ├─ 自動化 quality gate
├─ Agent/Skill 部署       ├─ 培訓 + 試用             ├─ 用量報表 + 成本分析
└─ 單人端到端驗證         └─ API quota 啟用           └─ 持續改善迴圈

Phase 1：基礎環境建置 + 核心移植 + 單人驗證（1-2 週）

目標：在企業環境中重現個人 VPS 的完整能力，由技術負責人驗證。

Phase 1 驗收標準：

• 在企業環境跑完 BR-001、MKT-001、RES-001 三組 benchmark
• 評分與個人 VPS baseline 相比無顯著退步（Structure completeness 與 Source discipline 不低於 baseline）
• quality-gate hook 正常攔截品質問題

Phase 1 估算：

• 樂觀 (O)：5 工作天
• 最可能 (M)：8 工作天
• 悲觀 (P)：12 工作天
• 加權估算 (E)：(5 + 32 + 12) / 6 = 8.2 天

Phase 2：多人存取 + 權限設定 + 行銷團隊 Onboarding（2-4 週）

目標：讓行銷團隊開始使用，建立基本的存取控管與成本管理。

Phase 2 驗收標準：

• 至少 3 位行銷人員能獨立執行 /brand-research 和 /marketing 並產出可用報告
• API 用量有日誌可查、月度彙總可出
• 客戶資料在不同使用者間不可互相存取

Phase 2 估算：

• 樂觀 (O)：12 工作天
• 最可能 (M)：18 工作天
• 悲觀 (P)：28 工作天
• 加權估算 (E)：(12 + 72 + 28) / 6 = 18.7 天

Phase 3：Eval 框架導入 + 品質管控 + 完整治理（1-2 月）

目標：從「能用」進化到「可持續、可度量、可改善」。

Phase 3 驗收標準：

• Eval baseline 在企業環境穩定運行 3 個月以上
• 品質評分（5 維度）的標準差 < 15%
• 月度成本報表可自動產出，偏差 < 10%
• Skill 改版有完整 eval trail

Phase 3 估算：

• 樂觀 (O)：20 工作天
• 最可能 (M)：30 工作天
• 悲觀 (P)：45 工作天
• 加權估算 (E)：(20 + 120 + 45) / 6 = 30.8 天

總體時程

4. 多租戶設計 | Multi-Tenant Architecture

4.1 架構分層

┌─────────────────────────────────────────────────────────────────┐
│                    存取層 Access Layer                           │
│   Slack Bot / Web UI / CLI Wrapper                              │
│   認證 + 路由 + quota 檢查                                      │
├─────────────────────────────────────────────────────────────────┤
│                    調度層 Dispatch Layer                         │
│   RBAC 權限閘門 → Orchestrator → Agent Dispatch                 │
├─────────────────────────────────────────────────────────────────┤
│               共享層 Shared Layer (唯讀)                         │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│   │ Agents   │ │ Skills   │ │ Library  │ │ Eval Framework   │ │
│   │ (39 位)  │ │ (核心 3) │ │ (Ref)    │ │ (Benchmark)      │ │
│   └──────────┘ └──────────┘ └──────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│               租戶層 Tenant Layer (隔離)                         │
│   ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐  │
│   │ User A          │  │ User B          │  │ User C       │  │
│   │ ├ projects/     │  │ ├ projects/     │  │ ├ projects/  │  │
│   │ ├ memory/       │  │ ├ memory/       │  │ ├ memory/   │  │
│   │ └ preferences/  │  │ └ preferences/  │  │ └ prefs/    │  │
│   └─────────────────┘  └─────────────────┘  └──────────────┘  │
├─────────────────────────────────────────────────────────────────┤
│               基礎設施層 Infrastructure                          │
│   API Key Pool + Quota + Telemetry + Backup                    │
└─────────────────────────────────────────────────────────────────┘

4.2 共享 vs 隔離邊界

4.3 客戶資料隔離方案

/enterprise/
├── shared/                          # 共享層（git 版控）
│   ├── agents/                      # 39 位 Agent 定義
│   ├── skills/                      # 核心 Skills
│   ├── library/                     # 知識庫
│   ├── hooks/                       # 品質閘門
│   └── eval/                        # Eval framework + baselines
│
├── team/                            # 團隊層
│   ├── memory/                      # 團隊共享記憶
│   ├── templates/                   # 團隊報告模板
│   └── decisions/                   # 團隊決策記錄
│
└── tenants/                         # 租戶層（嚴格隔離）
    ├── user-alice/
    │   ├── projects/
    │   │   ├── client-alpha/        # 客戶 A 專案
    │   │   └── client-beta/         # 客戶 B 專案
    │   ├── memory/                  # 個人記憶
    │   └── preferences/             # 個人偏好
    ├── user-bob/
    │   └── ...
    └── user-carol/
        └── ...

隔離機制：

• 檔案系統層級：每個租戶目錄權限 0700，僅 owner + admin 可存取
• 執行環境層級：每次 skill 執行時，working directory 自動切到租戶目錄
• 輸出層級：所有產出物落在租戶目錄下，不寫入共享層
• 搜尋層級：跨租戶搜尋功能預設關閉，admin 需明確授權

4.4 API Key / Quota 管理

                    ┌─────────────────────┐
                    │   API Key Pool      │
                    │   (企業主帳號)       │
                    ├─────────────────────┤
                    │ key-1: Claude API   │
                    │ key-2: Claude API   │
                    │ key-3: Web Search   │
                    └────────┬────────────┘
                             │
                    ┌────────┴────────────┐
                    │   Quota Manager     │
                    │   (中間層代理)       │
                    ├─────────────────────┤
                    │ Per-user 月額度      │
                    │ Per-skill 單次上限   │
                    │ 超額需審批          │
                    └────────┬────────────┘
                             │
            ┌────────────────┼────────────────┐
            ▼                ▼                ▼
      ┌──────────┐   ┌──────────┐   ┌──────────┐
      │ User A   │   │ User B   │   │ User C   │
      │ 月額 $50 │   │ 月額 $50 │   │ 月額 $30 │
      └──────────┘   └──────────┘   └──────────┘

Quota 規則：

成本參考（基於現有 baseline 資料）：

5. 組織變革管理 | Organizational Change Management

5.1 行銷人員培訓計畫

課程設計

教材清單

5.2 角色定義

5.3 漸進式導入策略

Week 1-2: Pilot Group (2-3 人)
  │  先行者 = 行銷團隊中最有好奇心的成員
  │  目標：收集真實使用回饋，找出最大痛點
  │
  ▼
Week 3-4: 回饋迭代
  │  根據 pilot 回饋調整：介面、教材、prompt 範例
  │  同時建立 FAQ 和 Troubleshooting Guide
  │
  ▼
Week 5-6: 第一次擴大 (5-8 人)
  │  加入第二批使用者，由 pilot 成員當 mentor
  │  此時品質和成本數據已足夠做初步分析
  │
  ▼
Week 7-8: 全員開放
  │  全行銷團隊開放使用
  │  建立定期 office hour（每週 30 分鐘）
  │
  ▼
Month 3+: 常態運營
     定期 eval + 月度報告 + 季度 review

5.4 抗拒管理

6. 風險與緩解 | Risks & Mitigation

6.1 風險矩陣

6.2 逐項緩解方案

R1：API 成本失控

防線一：Per-user 月額度（$50 預設）
    │ 超過 → 帳號暫停 + 通知 admin
    │
防線二：單次 skill 上限（$5）
    │ 預估超過 → 需 admin 核准
    │
防線三：團隊月預算（$500）
    │ 80% 水位 → 團隊預警
    │ 100% → 全團隊暫停 + 管理層決策
    │
防線四：突發偵測
    │ 1 小時內 > 3x 日均 → 自動暫停 + 即時通知

R2：品質不一致

• 源頭管控：核心 skill 唯讀，不允許個人修改 prompt
• 即時閘門：quality-gate hook 在每次 Write 時同步檢查 epistemic tags
• 定期驗證：每月至少執行一次 3 組 benchmark，比對 baseline
• 回溯追蹤：所有 skill 輸出都有 telemetry 記錄，可追溯到使用者和時間

R4：客戶資料外洩

• 檔案系統隔離：租戶目錄 0700 + ACL
• 執行環境隔離：每次 skill 執行限定 working directory
• 搜尋限制：跨租戶搜尋預設關閉
• 稽核：月度存取日誌審查
• 規範：新客戶專案建立時強制走隔離流程，不可放在共享目錄

7. 成功指標（KPI） | Success Metrics

7.1 核心 KPI

7.2 輔助指標

7.3 量測節奏

7.4 Go / No-Go 決策點

附錄：架構決策記錄 | Appendix: ADRs

ADR-001：共享 Agent/Skill 層 vs 個人複本

狀態：提議

上下文：遷移至多人環境時，需決定 Agent 定義和 Skill prompt 是每人一份還是共用一份。

決策：採用共享唯讀層，所有使用者使用同一版本的 Agent 定義和 Skill prompt。

理由：

• 39 個 agent 定義和 3 個核心 skill 已經過大量調教，品質是核心資產
• 若允許個人修改，eval baseline 失去意義（無法比較不同版本的品質）
• 集中管理可確保 bug fix 和改善一次部署全員生效

替代方案：

• 每人複本 + 定期 sync：管理成本太高，版本碎片化風險大
• 繼承覆寫（shared base + personal overlay）：增加架構複雜度，Phase 3 可再評估

後果：

• 正面：品質一致、管理簡單、eval 有意義
• 負面：個人無法客製化 agent 行為，某些特殊需求需透過 admin 處理

ADR-002：Slack Bot 作為 Phase 2 首選存取介面

狀態：提議

上下文：行銷人員不熟悉 CLI，需要更友善的操作介面。選項包括 Web UI、Slack Bot、VS Code Extension。

決策：Phase 2 以 Slack Bot 作為 MVP 存取介面。

理由：

• 行銷團隊已經每天使用 Slack，學習成本最低
• Slack Bot 可自然整合 approval workflow（quota 審批）
• 建置成本低於全功能 Web UI
• 可利用現有 n8n 自動化平台快速搭建

替代方案：

• 全功能 Web UI：功能最完整但開發時間長（需 4-6 週），適合 Phase 3+
• CLI wrapper + SSH：技術門檻太高，不適合非技術人員

後果：

• 正面：快速上線、低學習曲線、自然整合工作流
• 負面：Slack 介面受限（長報告需外連、格式有限），未來仍需 Web UI

ADR-003：API Key 集中管理而非個人帳號

狀態：提議

上下文：多人使用時，API key 的管理方式需要決定。

決策：使用企業主帳號的 key pool，透過中間層代理分配，不讓個人持有 API key。

理由：

• 集中 key 可統一監控用量和成本
• 避免 key 外洩風險（個人設備遺失等）
• 便於實施 quota 和 rate limiting
• Anthropic 企業方案支持 usage tracking by user

替代方案：

• 個人帳號各自付費：無法團隊管控、成本不可預測
• 個人帳號公司報銷：管理複雜、無法即時管控

後果：

• 正面：成本可控、安全集中、用量透明
• 負面：單點故障（主帳號問題影響全員），需建立 key rotation 機制

本章完。遷移方案在管理層批准後，由系統管理員主導 Phase 1 執行。