80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計

緣起:為什麼個人腦子系統撐不住 80 個人

過去一年,我在自己的多台電腦之間累積了一套「腦子系統」。它由四件東西組成:全域規則(CLAUDE.md)、領域知識庫(brain markdown,例如 OSGi 踩坑、Kafka 注意事項、Shopee API 陷阱)、可重用的能力包(skills)、自動記憶(MEMORY.md + 各種 user/project/feedback 檔)。同步靠 git repo,個人用 100 分。

但當需求變成「給一間 80 人公司用,讓所有人都能累積知識、快速成長、自行用 AI 開發小工具,並且不限定 Claude Code,可能員工 A 用 Claude、B 用 Cursor、C 用 ChatGPT」,個人架構幾乎所有環節都會崩。本文把整套放大設計鉅細靡遺寫下來,讓 RD 或 IT 主管可以直接拿去當藍圖。

你以為的「腦子」其實是四層

先把概念釐清。很多人講「AI 腦子」其實是把四件不同的東西黏在一起,擴展時要分開看待:

層	內容	載體	擴展邏輯
規則層	Iron Rules、語言、Git 流程、安全紅線	CLAUDE.md / .cursorrules	全公司一致,變動少,PR review 嚴管
知識層	領域踩坑、API 陷阱、業務眉角	brain/*.md	分部門、分主題、有 curator 治理
能力層	可重用 skill、自動化腳本、模板	skills/, plugins	員工貢獻 + PR + 用量遙測
記憶層	個人偏好、進行中工作、context	MEMORY.md / 個人 .md	永遠留個人,不上中央

這四層的擴展方式不一樣。規則層是法律,知識層是百科,能力層是函式庫,記憶層是日記。設計時要分開,不能當一坨處理。

擴展前必須先回答的三個問題

不要直接跳進畫架構圖。先把這三題定義清楚,不同答案會走到完全不同的系統。

Q1:「同時使用」是什麼意思?

• (a) 員工各挑工具,讀同一份共用知識 ✅ 正確答案,可實作
• (b) 同一任務同時派 Claude + GPT 工作 ❌ 反模式,幾乎沒實用場景

Q2:員工貢獻知識的開放程度?

實務建議:opt-out(預設進公司腦,標記私人才留個人),特別是 bug 經驗 — 踩過的坑是最有價值的共享資產。但 opt-out 強制要配「自動脫敏管道」,不然 raw bug log 一進公司腦就帶四種污染:客戶名、訂單 ID、同事名、合約號。

Q3:資料敏感度怎麼分?

分級	例子	處理方式
A 紅	客戶合約、財務數字、員工個資、未公開合作案	嚴禁所有雲端 AI,只能本地 LLM
B 黃	bug log、客戶踩坑、商務邏輯、process 設計	脫敏後可送雲端
C 綠	純技術問題、開源元件、公開文件	直接送雲端 frontier model

務實話:不要追求 100% 不洩漏,要追求「降低洩漏面積」。100% 在 80 人團隊中不存在,追下去會做出沒人用的合規劇場。

架構藍圖:雙 Repo + LLM Gateway + 雙引擎

┌─ 公司腦 repo (private GitHub Org) ─────────────────┐
│  global/    Iron Rules(PR + 2 reviewer 才能改)      │
│  teams/                                              │
│    backend/  brain/* skills/*                        │
│    frontend/ ...                                     │
│  shared/skills/  跨部門通用 skills                   │
│  build/    編譯器:MD → 各工具格式                    │
│  redact/   自動脫敏規則 + 字典                       │
└──────────────────────────────────────────────────────┘
              │ git pull (每天自動)
              ↓
┌─ 員工本機 ─────────────────────────────────────────┐
│  公司腦/  ← clone 自上面                            │
│  個人腦/  ← 自己的另一個 repo,永遠不 push 中央       │
│  build.sh 把兩者編譯到所有工具:                      │
│   → .claude/CLAUDE.md  (Claude Code/Desktop)        │
│   → .cursor/rules/     (Cursor)                     │
│   → .github/copilot-instructions.md (Copilot)       │
│   → ~/chatgpt-prompt.md (給 Custom GPT 貼用)        │
└──────────────────────────────────────────────────────┘
              │ HTTP / MCP
              ↓
┌─ 公司內網 LLM Gateway ─────────────────────────────┐
│  攔截 → 分級 → 脫敏 → 路由 → 串流回應                │
│  本地 Ollama (A 級任務專用)                         │
│  雲端 frontier (B/C 級脫敏後)                       │
│  審計 log → SIEM                                    │
└──────────────────────────────────────────────────────┘

為什麼是「公司腦 + 個人腦」兩個 repo

• 員工本機把兩個 repo clone 在一起,build.sh 編譯時個人腦覆寫公司腦(個人偏好優先)
• 個人腦本機 commit,永遠不 push 到中央 — 這就是「自己選擇要不要上」的物理保證
• 要分享某筆個人筆記時,員工自己 git mv 進公司腦發 PR
• 「不上傳」變成預設物理行為,不是靠規則約束

關鍵概念釐清:Brain ≠ Model

很多人問「為什麼一定要雲?所有人都用本地 model 配腦子就好了啊?」這個直覺方向是對的,但前提是要把兩件事拆開:

概念	是什麼	耗 GPU?	在哪
Brain(腦子)	Markdown 文件、規則、踩坑紀錄	❌ 完全不耗	都本地(git repo)
Model(推理引擎)	LLM(Claude / Qwen / Llama)	✅ 很耗	看你選

腦子永遠該全本地,這沒有爭議 — 它就是 markdown 檔。爭議只在 model 要不要本地。所以真正的問題是「為什麼推理引擎要用雲」。

為什麼不能「全本地 model」— 三個誠實的事實

1. 能力差距是真實的

2026/5 現況:本地頂級開源這一年大幅追上 — Qwen3-Coder-Next(80B 總參 / 3B active,MoE 架構,256K native context)已能跟 Claude Code、Cline、OpenCode 等 coding agent 直接整合;Qwen3.6、Kimi K2.6、DeepSeek V4是 2026/4 的 open-weight 第一梯隊。MoE 架構讓 80B 總參只啟動 3B per token,消費級硬體加量化可跑。但跟 frontier 雲端(Claude Opus 4.7(2026/4)、GPT-5.5(2026/4)、Gemini 3.1 Pro、DeepSeek V4)比,在 long-context agentic、跨檔案 reasoning、tool orchestration 上還是差一個檔次。差距比一年前縮小很多,但沒抹平。

2. 80 人「全本地」的硬體成本

• 中央 inference server(8x A100 80GB):採購百萬人民幣級別 + 機房 + 維運,80 人並發要排隊
• 每人一台 Mac Studio M3 Ultra 192GB:採購 44 萬美金,出差不能用
• 對比 80 人用 Claude/GPT API:每人每月 $50-200 美金,年成本 5-20 萬美金
• 雲端在中小公司階段便宜一個量級

3. 強制全本地會把員工逼地下

能力不夠 → 員工抱怨 → 私下偷貼資料到 ChatGPT。把人逼到地下,比讓他在地上用更糟。雲端 ≠ 資料變成 OpenAI 訓練資料,Enterprise 合約(Azure OpenAI / AWS Bedrock / Anthropic Enterprise)是另一回事。

真正的答案:Local-first, Cloud-when-needed(雙引擎)

員工的 prompt
    ↓
┌─ 本地閘門 (Qwen3-Coder-Next / Qwen3.6) ─────┐
│  1. 偵測敏感度(A/B/C 級)                     │
│  2. A 級:本地 model 直接處理,不出去           │
│  3. B 級:自動脫敏後送雲端                     │
│  4. C 級:直接送雲端                           │
└──────────────────────────────────────────────┘
    ↓ (B / C 級才會到這)
┌─ 雲端 frontier model ────────────────────────┐
│  Claude Opus 4.7 / GPT-5.5                  │
│  Gemini 3.1 Pro / DeepSeek V4               │
│  各家擅長領域不同,Gateway 依任務型別路由       │
└──────────────────────────────────────────────┘

這才是「資料安全」和「員工生產力」雙贏的解。全雲洩漏 A 級、全本地犧牲 B/C 級體驗,雙引擎才永續。

LLM Gateway:員工感受不到的中間人

員工不可能每次手動選分級,要他們按 🟢🟡🔴 三天就沒人用了。正確做法是系統默默判,員工不感知。員工的 IDE / Claude Code / Cursor 不直接連雲端 API,改連公司內網的 Gateway:

員工的設定只有一行:
ANTHROPIC_BASE_URL=https://company-llm.internal/v1

之後做什麼都不變。Cursor 還是 Cursor,Claude Code 還是 Claude Code。

Gateway 的三個職責:

職責	在做什麼	用什麼
分級	判 A / B / C	Regex + 本地小型 LLM 分類器
脫敏	B 級資料抽掉客戶名/同事名/合約號	字典 + regex + 本地 LLM 補刀(Microsoft Presidio 可借力)
路由	送本地還是送雲端	規則引擎

三層漏斗:5ms 路由掉 90% 流量

不是「每個 prompt 都過 LLM 判」,那會塞爆。是三層漏斗:

1. Layer 1:Regex / 字典比對(< 5ms,攔 90%)
   • 含「大有建設」/「老王」/合約號格式 → 紅,本地
   • 純英文技術詞、無中文人名地名 → 綠,雲端
   • 命中就路由,不過 LLM
2. Layer 2:小型分類器(0.1-0.3 秒,攔 9%)
   • 用 fine-tune 過的 BERT 或 1B-7B LLM 做專門分類
   • 不是 70B 判分級,是 1B 做分類
   • 100ms 級延遲,員工幾乎感受不到
3. Layer 3:保守路由(fail-safe,1%)
   • 真模糊的 case,全部判 B 級 → 走脫敏 + 雲端
   • 寧可多脫敏,不要誤送:錯就錯在不便利,不要錯在洩漏

實際員工體驗:問「這個 process 跑 NPE,客戶大有建設訂單 SO20260415 卡住」→ Gateway 5ms 偵測到「大有建設」「SO\d+」→ 自動改寫成「客戶 [CUSTOMER_A] 訂單 [ORDER_ID]」→ 路由到雲端 Claude → 員工完全不知道發生了什麼,只覺得 AI 答得很好。

能管的世界 vs 不能管的世界

追求 100% 覆蓋會害死系統。要清楚畫出邊界,每塊用對應措施:

範疇	可管性	措施
Claude Code / Cursor / Continue / Aider	✅ 可改 BASE_URL	Gateway 嚴管
Claude Desktop / 自寫 script / n8n	✅ 可改 endpoint	Gateway 嚴管
公司網路出站流量	✅ Firewall force proxy	Gateway 嚴管
ChatGPT 網頁 / Claude.ai 網頁	⚠️ Browser extension 半攔	即時 paste 脫敏 + 警告
GitHub Copilot inline	❌ MS endpoint 不能改	規則 + 教育
手機 app / 私人裝置	❌ 物理上管不到	合約 + 信任 + 事後追溯

核心心法:不假裝管得到不該管的東西。每塊都有對應措施,沒有「假裝有但實際沒有」的灰區。資安部門能說明、員工能理解、出事能追責。

「拉力 > 推力」的設計哲學

對「不能管的世界」,訴諸三層(從硬到軟):

Layer 1: 用「拉力」把人留在 Gateway 裡(最重要)

讓 Gateway 比網頁版好用,員工自然不繞過:

• Gateway 自動注入公司腦(員工不用每次貼 context)
• Gateway 連 frontier 雲(Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4),員工不用自己付費,還能依任務路由到最強模型
• Gateway 整合公司 codebase RAG,網頁版做不到
• Gateway 串流速度比網頁版快(內網直連)

這是設計哲學的轉換:不是「禁止你用 X」,而是「Y 比 X 好用」。員工是理性人,會選好用的。80 人裡會有 70 人自動留在 Gateway,不用任何 enforcement。

Layer 2: Browser Extension(半受控的中間地帶)

• 偵測員工開啟 chat.openai.com / claude.ai / gemini.google.com
• input 框 paste 時即時 regex 脫敏
• 大量 paste(>500 字)跳警告:「這段內含 X 個敏感字,已自動替換 Y 個」
• 不阻擋、不上報,只做防呆 condom

Layer 3: 規則 + 教育 + 事後追溯

• 明確紅字 list 寫進員工守則
• 每季資安訓練(講具體案例)
• DLP 遙測不阻擋只記 log,事後可追
• 離職前 audit log 過一遍

分級對應表怎麼從 0 開始建

這是組織問題不是技術問題。沒有這張表,所有 Gateway 規則都是空的。

誰主導

• 準 CISO 角色(IT 主管 + 法務 + 老闆都接受的人)
• 不要 IT 一個人定(太技術)
• 不要法務一個人定(會把所有東西判 A 級,系統失效)
• 不要部門主管各說各話

Working Group(5-7 人)

• 1 × 準 CISO(主導)
• 1 × 法務(合規紅線)
• 1 × IT 實作者(技術可行性)
• 3-4 × 部門 senior(業務視角,挑會用 AI 的人)
• 1 × 老闆 sponsor(拍板用,不參與每週會)

四個 Phase(漸進式,不要追求一次到位)

Phase	時間	目標
Phase 0	1 週	列資料種類清單(50-100 種)
Phase 1	2 週	粗分 A/B/C,先有 v0.1
Phase 2	4-6 週	挑一部門試點,每週開會精修
Phase 3	持續	全公司 + 月度 patch

五個必避陷阱

• ❌「不確定就 A 級」→ 系統失效,員工全跑網頁版
• ❌ 追求 100% 完整才上線 → 永遠定不下來
• ❌ 一次寫完不再動 → 6 個月後過時,員工不信任
• ❌ 黑盒不公開 → 員工不知道為什麼被判 A 級
• ❌ 法務一個人說了算 → 變成沒人用的合規劇場

核心原則:先有粗版上線,再用真實流量精修 > 想清楚再上線。

KPI:唯一最重要的數字

North Star(唯一最重要)

本月 Gateway request 數
÷
(Gateway request 數 + 偵測到的網頁版 LLM 流量)

公司網路 DNS / firewall log 看得到員工開了多少次 chat.openai.com / claude.ai / gemini.google.com(域名級,不看內容,沒有隱私問題)。這個比例 = 「員工選 Gateway 的比例」,目標6 個月內達 90%+。< 70% 代表 Gateway 拉力不夠,要查為什麼。

四象限 Dashboard

象限	指標	目標
採用	月活用戶 / 全員	80%+
替代	North Star	90%+
體驗	Gateway p50 延遲	< 500ms
體驗	月度 NPS(vs 網頁版)	4.0/5+
健康	Layer 1 regex 命中率	> 85%
健康	員工申訴誤判率	< 0.5%

月度報告:三個問題就夠

1. 「上個月 X% 員工選擇 Gateway over 網頁版」← North Star
2. 「員工繞過 Gateway 的 Top 3 原因」← 下個月修哪邊
3. 「Gateway 帶來的安全收益 + 成本」← 攔住多少 A 級洩漏、雲端費用變化

第一個月 MVP 時程

不要一次蓋大廟。Phase 0 砍到極簡,先讓 Claude Code + Cursor 用戶跑起來,驗證治理流程能不能撐 80 人,再擴展。

週	交付
W1	公司腦 repo + 3-5 條 Iron Rules + build.sh(支援 Claude Code & Cursor)
W2	個人腦 repo template + 員工 onboarding 文件 + 第一場培訓
W3	脫敏字典 v0(client_names.txt + employee_names.txt)+ pre-commit hook 擋紅字
W4	Curator 制度上線(每 team 一個 + 每週 1 小時 review)

Brain Server / ChatGPT 整合 / 本地 Ollama / 完整 Gateway → 全部砍到 Phase 1(第 2-4 個月)。樂觀估計:1 個全職工程師 3-4 個月做到可上線 Gateway。悲觀:6 個月 + 2 個工程師。

結語:這是 AI 時代的雙贏

傳統 IT 部門做了再美的 UI,客戶都會嫌不好用 — 這是 ERP 行業 30 年的詛咒。AI 時代的反轉是:不要再做永遠改不完的 UI 了,做「給 AI 安全取資料的入口」就好。客戶用自己愛的 AI 工具(ChatGPT、Claude、Cursor),透過你架的 Gateway 安全地取資料、做事情。

這對 RD 是解放:

• 不再被「客戶嫌頁面醜」「客戶嫌操作太多步」這類無底洞的 UI/UX 工單吃掉時間
• 可以回去做真正有複利的工作:ISO 流程符合性、資安審核、業務邏輯正確性
• 每一個 RD 寫的 brain markdown,都是公司 domain knowledge 的長期資產,不會因員工離職就消失
• 新進員工從第一天就站在累積的 brain 上工作,onboarding 從 3 個月縮到 3 週

對員工是賦能:每個人都能用自己最熟的 AI 工具,在公司架好的安全護欄內,自行開發小工具、解決自己的痛點。對公司是護城河:domain knowledge 從個人腦袋變成公司資產,可累積、可審計、可傳承。

整套設計的核心心法只有四句:

• 能管的嚴管,不能管的不假裝管
• 拉力 > 推力,讓 Gateway 比網頁版好用
• 員工不感知,系統默默路由
• 先粗版上線,真實流量精修

剩下的就是把 working group 召集起來,開第一次會。

2026/5 技術參考時間戳

本文涉及的具體模型版本、開源工具、ISO 標準以撰文時間為準,LLM 領域變化快,請以最新發布為主:

• 雲端 frontier(2026/4 發布):Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4。各家擅長領域不同,「routing by task type」已成為主流架構。
• 本地頂級開源:Qwen3-Coder-Next(80B 總參 / 3B active,MoE,256K context)、Qwen3.6、Kimi K2.6、DeepSeek V4、Llama 3.3 70B。
• 本地 LLM 平台:Ollama 仍是預設選擇,production 並發推 vLLM V1(2-4 倍吞吐)。
• AI Gateway 開源工具:LiteLLM(unified API to 100+ providers)、Portkey(observability + guardrails + PII redaction)、Kong AI Gateway。2026 企業常見組合是 LiteLLM 當 proxy + Portkey 做 observability。
• PII 脫敏:Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版),含 image redactor 與 DICOM 醫療影像支援。
• 合規標準:ISO/IEC 42001:2023(AI 管理系統,目前唯一可認證 AI 標準)、ISO 27001:2022、ISO 27701。Schellman、TÜV SÜD、BSI、DNV 都是合格認證機構。