重點摘要(TL;DR)
- 萬人跨國集團導入 AI 腦子系統,不能用 80 人公司的 16 步從上到下做法 — 規模差兩個量級,順序要倒過來:農村包圍城市。
- 四階段:農村期(各自長)→ 根據地期(BU 正規化)→ 包圍期(中央彙整)→ 進城期(集團 Gateway),總時程 6-12 個月。
- 唯一不能省的前提:集團 Iron Rules 三條紅線今天就要 CIO 一人發出(BOM 配方/未公告財報/客戶合約)。其他都可以等。
- 核心翻轉:Working Group 從第一步延後到第三階段,Iron Rules 從第三步前置到最開始,Gateway 從中段砍到最後。
- 本文是《80 人公司的 AI 腦子系統》(why)和《16 步驟實戰建置》(how)的尺度延伸版。前兩篇是 80 人,本篇是萬人。
一、為什麼不用由上而下
傳統企業 IT 系統導入是由上而下:高層決策 → 統一規範 → 全面部署。這個模式在萬人跨國集團有三個致命弱點:
1. 啟動成本極高
第一步就需要 CIO + 法務 + 各事業群 VP 全員對齊,光是排到那個會議就要一個月,對齊完再兩個月,什麼都還沒做就半年過去了。
2. 規範是空白紙上畫出來的
在真實使用前就要定出 500+ 種資料分級,必然失準。法務傾向把所有邊界 case 定 A 級,導致 Gateway 裝好後 90% 流量被擋,系統等同報廢。
3. 員工沒有動機
「IT 規定要用」跟「用了真的更方便」,員工選哪個不言而喻。由上而下的系統沒有拉力,員工繼續用自己的 ChatGPT 帳號,治理形同虛設。
二、農村包圍城市的核心邏輯
借用毛澤東的戰略概念:不從總部開始,從願意動的團隊開始。
農村期 根據地成形 包圍城市 進城
各自長出來 → 各 BU 正規化 → 由上而下彙整 → 大腦子上線
(自然生長) (誰準備好誰先走) (整理已有事實) (全集團 loop in)每個階段的關鍵心法:
- 農村期:不強制格式,不需要中央協調,只要三條紅線保底
- 根據地:哪個 BU 準備好就先走,不等其他人
- 包圍城市:Working Group 整理的是「已發生的事實」,不是「空想的規範」
- 進城:Gateway 最後才裝,分級表已經實戰驗證,不是猜測
三、唯一不能省的前提:集團 Iron Rules
農村期開始之前,有三條紅線今天就要定下來。不需要 Working Group,CIO 一人決定即可發出。
集團 AI 使用紅線 v0(全員適用)
- BOM 配方、製程參數、合金成分比例
→ 禁止送任何雲端 LLM,僅可使用公司核准的本地 AI 工具 - 未公告財報數字(月報、季預估、年度計畫)
→ 禁止送任何 AI 工具(含本地)。違反視同內線交易風險處理 - 客戶合約原文、訂單金額、供應商報價
→ 禁止送雲端 LLM,須脫敏後才可使用 AI 協助分析
為什麼只有三條:條數越多,記得住的人越少。三條紅線,員工背得起來,才有意義。
四、四個階段詳細規劃
第一階段:農村期(各自長出來)
- 時間:2-3 個月
- 壓力:低,自然生長,不強制
- 需要誰:願意動的 RD / Senior,不需要主管強制
各 BU 各自做的事
| 動作 | 說明 | 工具 |
|---|---|---|
| 個人 brain 開始建立 | 員工把自己的工作 SOP、常見 prompt、領域知識整理成 markdown | 任何工具(Obsidian / Notion / 純文字均可) |
| BU 層級 Iron Rules | 在集團三條之上,各 BU 自己再加 3-5 條(例:電線電纜加「電纜規格書禁止送雲端」) | 一份 Google Doc 即可 |
| BU 資料類型盤點 | 列出「我們 BU 最常碰到的 20-30 種資料,哪些是絕對不能送出去的」 | 表格,不需要格式 |
| 紀錄什麼 AI 用得好 | 哪些場景 AI 幫上忙?哪些場景踩過坑? | Slack 頻道 / 週會口頭分享均可 |
農村期的成功標準
- 每個 BU 至少有 5-10 個員工在用 AI 做日常工作
- 每個 BU 至少有 1 個人願意分享自己的 brain / prompt 給同事
- 集團三條 Iron Rules 沒有被違反的事件
農村期刻意不做的事
- ❌ 不裝 Gateway(分級表還沒出來,裝了是空殼)
- ❌ 不要求統一格式(這個階段要讓實踐先長出來)
- ❌ 不開大型跨 BU 會議(成本高,收益低)
- ❌ 不建集中式 repo(時機未到)
第二階段:根據地成形(各 BU 正規化)
- 時間:每個 BU 各自 1-2 個月,可以交錯進行
- 壓力:中,BU 主管需要支持,但不需要集團介入
- 關鍵原則:誰先準備好,誰先走。不等其他 BU。
正規化的六個動作
① 建立 BU brain repo
{bu-name}-brain/ (BU 私有 git repo)
├── global/
│ └── CLAUDE.md ← BU Iron Rules(含集團三條)
├── departments/
│ ├── rd/
│ ├── sales/
│ └── manufacturing/
└── personal/ ← 員工個人 brain(不 push 至集團).gitignore 必須擋掉:.env、密碼檔、含客戶名的原始資料
② BU 資料分級表 v0.1
把農村期盤點的資料類型正式化,粗分 A / B / C:
| 等級 | 定義 | 處理方式 |
|---|---|---|
| A 級 | 洩漏會造成法律責任或競爭損失(BOM、財報、客戶合約) | 本地 LLM only / 禁止送 AI |
| B 級 | 脫敏後可送雲端(去除識別資訊後的分析資料) | 脫敏後可用雲端 |
| C 級 | 本來就是公開或無敏感性的資料 | 直接送雲端 |
邊界 case 原則:不確定的預設 B 級,不預設 A 級。過度保守的分級會讓系統失效。
③ BU 脫敏字典 v0
三份純文字,只需要這個 BU 用得到的:
bu-client-names.txt ← 這個 BU 的客戶名稱(從 CRM 匯出)
bu-employee-names.txt ← 這個 BU 的員工(從 HR 匯出)
bu-codes.txt ← 料號、專案代號、合約格式存放位置:不進 git,放另一個 access-controlled 位置,用 SSH key 拉取。
④ Pre-commit Hook 部署
只掃 staged diff,< 1 秒完成:
#!/bin/bash
# 字典命中就 block commit,提示員工手動脫敏
DICT_PATH="/secure/bu-dicts"
STAGED_DIFF=$(git diff --cached)
while IFS= read -r word; do
[ -z "$word" ] && continue
if echo "$STAGED_DIFF" | grep -qF "$word"; then
echo "⛔ 偵測到敏感字詞:'$word'"
echo " 請移除或脫敏後再 commit"
exit 1
fi
done < "$DICT_PATH/bu-client-names.txt"
exit 0⑤ BU Curator 指定
每個 BU 指定 1 名 Senior 擔任 Curator:
- 每週 1 小時 review brain PR(排進週計畫,不是「有空就做」)
- PR 5 個工作天內必須回應
- 每季半天「腦子健檢」清掉過時 brain
⑥ 種子推廣
Curator 挑 10-15 人的核心小組試跑 2-4 週,確認:
- brain 真的有人用
- Pre-commit hook 沒有造成工作流障礙
- 分級表的 A/B/C 判斷在實際使用中合理
確認後,向 BU 全員推廣。
第三階段:由上而下彙整(包圍城市)
- 時間:1-2 個月密集對齊
- 時機:至少 2 個 BU 完成第二階段後才啟動
- 這個階段 Working Group 才真正有意義
為什麼這時候才開 Working Group
此時 Working Group 做的是「整理已有的事實」:
- 各 BU 帶著真實用過的分級表來開會
- 各 BU 帶著真實踩過的坑來討論規則
- 所有討論都有數據和案例,不是空想
對比農村期就開 Working Group:那時所有人都在猜,法務說什麼都是 A 級,會議沒有結果。
Working Group 三場核心會議
- 第一場(90 分鐘):比對各 BU 分級表,找出共同模式(幾乎所有 BU 都把財報列 A 級)、找出差異點(電線電纜的料號是 A 級,不銹鋼的可能是 B 級)。產出:集團分級表草稿。
- 第二場(60 分鐘):在三條保底紅線之上,加入各 BU 共識的條款。產出:集團 CLAUDE.md v1.0。
- 第三場(90 分鐘):設計集團 Gateway 架構與統一格式 — 以各 BU 累積的真實流量數據為基礎,規劃集團共用編譯器(build.sh)、字典同步機制、Gateway 規則整合。具體實作對應 16 步建置的 Step 9-11,差別在於集團版是「整合多個已實證 BU 的版本」,不是「從 0 設計」。
第四階段:進城(集團 Gateway 上線)
- 時間:2-3 個月
- 時機:Working Group 三場會議產出已落地、至少 2 個 BU 試過集團版規範
這階段才裝集團 Gateway。具體實作 100% 對應 16 步建置的 Step 9-11(LLM Gateway 骨架 → 三層漏斗 → 雙引擎接入),差別在於:
- 規模:集團採購 Anthropic Enterprise / Azure OpenAI 是大客戶等級合約,費率和 SLA 比 80 人公司有利
- 路由:Gateway 規則已經被 2-3 個 BU 實戰過,直接套上不是猜測
- 本地 LLM:集團規模可以共用一組中央 GPU 機房(8x A100 / H100),分攤到上千員工成本合理
- 分級表:已經是 v3.0 而非 v0.1,失誤率低
進城期結束 = 集團 AI 治理基礎建設完成。後續演進(ISO 認證、知識淘汰機制等)同 16 步的 Phase 5。
五、16 步驟的對應關係
這是把 80 人版的 16 步重新編排成萬人集團版的對應表。順序大幅調整,但每一步本身的工程細節不變 — 80 人版是教科書,本版是針對集團規模的「演奏順序重排」。
| 原版步驟 | 農村包圍城市版對應 | 時機 |
|---|---|---|
| Step 1 Working Group | 延後到第三階段,這時才有實際數據可以討論 | M5-M6 |
| Step 2 雙 Repo | 各 BU 在根據地期各自建,進城期才合併成集團架構 | M3-M6 |
| Step 3 Iron Rules | 前置到最前面,農村期開始前就要有三條 | M1 Week 1 |
| Step 4 build.sh | 進城期才需要集團版編譯器,各 BU 根據地期用簡化版 | M7 |
| Step 5 種子部門 | 農村期本身就是種子,每個 BU 自然生長 | M1-M3 |
| Step 6 分級對應表 | 各 BU 根據地期各自出草稿,Working Group 彙整 | M3-M6 |
| Step 7 脫敏字典 | 各 BU 根據地期各自建,進城期接 SAP 自動同步 | M3-M7 |
| Step 8 Pre-commit Hook | 各 BU 根據地期部署,Browser Ext 進城期 MDM 統一推送 | M3-M7 |
| Step 9-11 Gateway | 進城期才裝,這時分級表已實戰驗證 | M7-M9 |
| Step 12 Curator | 各 BU 根據地期指定 BU Curator,Global Curator 在彙整期設立 | M3-M6 |
| Step 13 KPI Dashboard | 進城期 Gateway 上線後才有數據 | M7+ |
| Step 14-16 ISO / 演進 | 系統穩定後(M10+)再啟動 | M10+ |
六、一句話說明這個策略
原版是先建水庫再引水。
這個策略是先讓各地水源自然流,找到真實路徑後,再建剛好合用的水庫。
前者快但容易建錯地方;後者慢起步,但建好的系統是真實需求驅動的,員工願意用,知識才真正累積。
第一步只有一件事:CIO 今天把三條紅線發出去。其他 15 步都會跟著動起來。
延伸閱讀
- 《80 人公司的 AI 腦子系統:從個人腦擴展到全公司不洩密的工程設計》 — 為什麼這樣設計、雙 Repo + Gateway + 雙引擎、能管 vs 不能管邊界、拉力哲學。本文的哲學基礎。
- 《80 人 AI 腦子系統實戰建置:從 0 到上線的 16 個步驟》 — 五個 Phase、16 個 Step、四維框架、每步的目標 / 動作 / 產出 / 坑。本文的工程細節依據。