標籤: Step by Step

  • 80人AI腦子系統實戰建置:從0到上線的16個步驟

    重點摘要(TL;DR)

    • 把 80 人 AI 腦子系統從 0 蓋起來,共 5 個 Phase、16 個 Step、約 16 週。本文逐步拆解每一步的目標、動作、產出、坑。
    • 每一步都用四維框架檢查:安全(不洩漏)、穩定(不掛)、累積(知識變資產)、好用(員工願意用)。任何一步如果四維都不過,就砍掉。
    • 核心心法:物理保證 > 規則約束、拉力 > 推力、先粗版再精修、安全在前但好用不能放最後
    • 順序很重要,不能跳步。例如沒有 Step 6(分級對應表)就做 Step 9(Gateway),Gateway 規則沒依據;沒有 Step 12(Curator)就累積知識,3 個月後變垃圾堆。
    • 本文是《80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計》的實作續篇。前篇講為什麼,本篇講怎麼做。

    為什麼要從「順序」談起

    很多公司導入 AI 治理失敗,不是技術不行,是順序錯了。常見錯誤:

    • 先買 Gateway 軟體,再去定資料分級 → 規則沒依據,Gateway 變裝飾
    • 先請大家寫 brain markdown,沒有 Curator 制度 → 3 個月後變過期文件墳場
    • 先做華麗 Dashboard,沒有 audit log 來源 → KPI 是亂編的
    • 先全公司鋪開,沒先試點 → 第一週體驗不好,80 人對系統信任歸零,救不回來

    本文每個 Step 都標「為什麼是這個位置」,讓你看完知道哪些可以平行、哪些必須串行。

    四維檢查框架

    每個 Step 都要回答四個問題。如果一個 Step 四維都打不到 ≥1 分,就砍掉 — 是 nice-to-have,不是 must-have。

    維度 問題 具體判斷
    🔒 安全 這步降低洩漏面積嗎? A 級資料更不會出去?稽核能找到證據?
    🛡️ 穩定 這步可用性夠嗎? 壞了能降級?有災難回復?HA?
    📚 累積 這步留下了什麼長期資產? 員工離職還在?可審計?可移交?
    😊 好用 員工這步以後生活更好嗎? 少打字?少切視窗?少等待?少抱怨?

    Phase 0:基礎準備(W0–W2)

    不要先動程式碼。先把組織結構知識容器建好。

    Step 1 — 召集 Working Group(W0,3 天)

    • 目標:讓 5-7 人(準 CISO + 法務 + IT + 3-4 部門 senior + 老闆 sponsor)成為這套系統的第一批決策者
    • 動作:第一次會議 60 分鐘,議程:同步為什麼要做、確認名單、排定 Phase 0 清單會議、訂下兩週一次例會
    • 產出:一份 working group 章程文件、會議紀錄、共享日曆
    • 四維:🔒 ✅(分級權威來源)、🛡️ —、📚 ✅(決策歷史可追)、😊 ✅(員工知道有人扛責)
    • 常見坑:老闆不到場 → 後面拍板沒人敢動;法務一個人說了算 → 後面所有東西判 A 級

    Step 2 — 建立雙 Repo(W1,2 天)

    • 目標:把「公司腦」和「個人腦」變成兩個物理上分離的 git repo
    • 動作:在公司 GitHub Org 建 company-brain(private)、發給每位員工一份 personal-brain template(github classroom 或 cookiecutter)
    • 產出:兩個 repo + README 說明使用方式 + .gitignore 範本
    • 四維:🔒 ✅✅(個人腦永不 push 中央=物理保證)、🛡️ ✅(git 提供版本+回復)、📚 ✅(每筆變更有 PR)、😊 ✅(員工用熟悉的 git workflow)
    • 常見坑:個人腦放公司 GitHub 而不是員工自己的 → 隱私保證失效;沒有 .gitignore 擋掉 .env / 密碼檔 → 第一週就有人 commit 進去

    Step 3 — Iron Rules v0(W1-W2,1 週)

    • 目標:寫下 3-5 條全公司必守的紅線,變成 company-brain/global/CLAUDE.md
    • 動作:Working Group 開 1 次會議,每個人提 5 條,合併成 3-5 條全體共識
    • 範例:「禁止把客戶合約原文送雲端 LLM」「Bug log 進公司腦前必須脫敏」「所有 brain 修改必須走 PR」
    • 產出:CLAUDE.md v0 commit 進 company-brain/global/
    • 四維:🔒 ✅(底線設定)、🛡️ —、📚 ✅(規則進 git)、😊 ✅(規則少而清楚 > 50 條沒人記)
    • 常見坑:寫成 30 條 → 沒人記得住;寫太抽象(「做正確的事」)→ 不能執行

    Phase 1:同步機制(W3–W4)

    讓「腦子」能流到員工每個 AI 工具。不寫 Gateway,先解決 build & sync

    Step 4 — build.sh 中性編譯器(W3,3-5 天)

    • 目標:一個 script 把 markdown 編譯到所有 AI 工具的格式
    • 動作:寫 bash / Python script,輸入 company-brain/ + personal-brain/,輸出:
      • .claude/CLAUDE.md(Claude Code / Desktop)
      • .cursor/rules/*.mdc(Cursor)
      • .github/copilot-instructions.md(Copilot)
      • ~/chatgpt-system-prompt.md(ChatGPT 用 Custom GPT 貼用)
    • 關鍵設計:每個 brain 檔的 frontmatter 加 tools: [claude, cursor, copilot, gpt],編譯時依目標 model 過濾
    • 產出:可執行的 build.sh + 4-5 種工具的編譯範例
    • 四維:🔒 ✅(可依工具過濾敏感腦)、🛡️ ✅(編譯失敗有錯誤訊息)、📚 ✅(中性格式不被工具鎖死)、😊 ✅✅(員工不用學新格式)
    • 常見坑:編譯太久 → 員工不願意每天 build,設成 git pre-push hook 自動跑

    Step 5 — 種子部門試跑(W4,1 週)

    • 目標:挑 10-15 人的部門(通常是 RD)當第一批用戶,真實流量驗證 Phase 0+1
    • 動作:每天收 1 次回饋(短 Slack 頻道)、每週 1 次 30 分鐘 retro 會議、補 brain
    • milestone:第一週結束,company-brain 有 ≥10 筆 brain markdown(由種子用戶產出)
    • 四維:🔒 —、🛡️ ✅(早期發現問題)、📚 ✅(brain 種子)、😊 ✅(早期使用者教其他員工)
    • 常見坑:挑錯部門 → 行政部根本不寫 brain;挑太大部門 → 回饋處理不過來。挑用 AI 最多的小團隊

    Phase 2:分級與脫敏(W5–W8)

    這是整個系統的核心。沒這 Phase,後面 Gateway 全是空殼。

    Step 6 — 分級對應表 v0.1(W5-W6,2 週)

    • 目標:列出 50-100 種公司會接觸的資料類型,粗分 A/B/C
    • 動作:Working Group 兩次會議,每次 90 分鐘,一次處理 30 種
    • 產出:company-brain/global/data-classification.md 表格化,進 git 管理
    • 原則:不糾結邊界 → 先有 v0.1 → Phase 2 試點時精修
    • 四維:🔒 ✅✅✅(整套架構的權威來源)、🛡️ —、📚 ✅✅(可審計、可移交)、😊 —(員工目前還用不到,但是後續所有 UX 的基礎)
    • 常見坑:法務說「不確定就 A 級」→ 後續 Gateway 90% 流量被擋,系統失效。**邊界 case 預設 B 級**(脫敏後可送雲),不是 A 級

    Step 7 — 脫敏字典 v0(W7,5 天)

    • 目標:三份純文字字典,擋掉 80% 紅字
    • 動作:從 CRM / HR / 專案系統匯出
      • client_names.txt(客戶公司名 + 簡稱)
      • employee_names.txt(員工姓名 + 暱稱 + Slack ID)
      • project_codes.txt(內部專案代號、產品代號、合約格式 regex)
    • 產出:三份 .txt + 每月由 HR / PM 維護的責任分配
    • 進階(可選):接 Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版)當第二層補強。Presidio 是開源 PII 脫敏框架,內建 NER + regex + checksum,支援多語言,還有 image redactor 處理 DICOM 醫療影像。字典擋已知字、Presidio 擋通用 PII(信用卡、身分證、地址等),兩層疊加。
    • 四維:🔒 ✅✅(一次擋掉 80% 洩漏)、🛡️ ✅(純文字,壞不掉)、📚 ✅(離職員工從字典移除有歷程)、😊 ✅(員工不用記哪些字是紅字)
    • 常見坑:字典放 git 中 → 字典本身就是敏感資料(客戶 list)。要放另一個 access-controlled repo,build.sh 用 SSH key 拉

    Step 8 — Pre-commit Hook + Browser Extension MVP(W8,1 週)

    • 目標:在員工提交 brain 時、貼資料到網頁版 LLM 時,第一道防線
    • 動作:
      • Pre-commit hook(.git/hooks/pre-commit):掃 staged 檔案,字典命中就 block commit
      • Browser Extension(Chrome/Edge):偵測 chat.openai.com / claude.ai 的 paste 事件,字典命中跳警告 + 自動替換
    • 產出:兩個工具 + 內部 IT 自助安裝頁
    • 四維:🔒 ✅✅(防呆,擋住 80% 「員工懶得開 IDE」場景)、🛡️ ✅(本地執行,不 break 工作流)、📚 —、😊 ✅(警告比阻擋友善)
    • 常見坑:Pre-commit 跑太慢(掃整個 repo) → 員工 git commit --no-verify 繞過。**只掃 staged diff**,< 1 秒

    Phase 3:Gateway 上線(W9–W16)

    這是工程量最大的 Phase。前面都做完才有意義。

    Step 9 — LLM Gateway 骨架(W9-W11,3 週)

    • 目標:用開源 AI Gateway 做基礎,偽裝 Anthropic / OpenAI API。2026 主流選擇:LiteLLM(unified API 到 100+ providers)、Portkey(內建 guardrails + PII redaction + observability)、Kong AI Gateway。企業常見組合是 LiteLLM 當 proxy + Portkey 做 observability
    • 動作:
      • 架 LiteLLM 在內網(Docker),或用 Portkey self-host
      • 第一版只做 proxy + audit log,不做分級
      • 讓種子部門切過來:ANTHROPIC_BASE_URL=https://company-llm.internal/v1
    • 產出:可用 Gateway + audit log 進 SIEM + 每日 throughput 報告
    • 四維:🔒 ✅(流量集中)、🛡️ ✅✅(HA + 健康檢查)、📚 ✅✅(全程 audit)、😊 ✅(員工只改一行設定)
    • 常見坑:沒做 HA,Gateway 掛 = 80 人不能工作。**第一天就要 HA**,或備用 endpoint 自動切換

    Step 10 — 三層漏斗實作(W12-W14,3 週)

    • 目標:在 Gateway 內加分級 + 路由邏輯
    • 動作:
      • Layer 1:Aho-Corasick 演算法搜字典(< 5ms)
      • Layer 2:fine-tune 小模型做分類(BERT、Qwen3 1.7B、Llama 3.2 3B 都可),0.1-0.3s
      • Layer 3:fail-safe 全部判 B 級走脫敏 + 雲端
    • 產出:三層命中率分布 dashboard
    • 四維:🔒 ✅✅✅(自動分級)、🛡️ ✅(每層獨立可降級)、📚 ✅(每筆分類有紀錄)、😊 ✅(員工無感)
    • 常見坑:一開始就追求 Layer 2 LLM 完美 → 永遠上不了線。**先 Layer 1 + Layer 3 兩層上線**,Layer 2 之後加

    Step 11 — 雙引擎接入(W15-W16,2 週)

    • 目標:把雲端 frontier 和本地頂級開源模型都接進 Gateway
    • 動作:
      • 雲端:簽 Anthropic Enterprise(Claude Opus 4.7)、Azure OpenAI(GPT-5.5)、AWS Bedrock(多家)、Google Vertex AI(Gemini 3.1 Pro)。要 DPA + zero data retention 條款。2026 主流是「routing by task type」:Opus 4.7 跑 multi-file coding、GPT-5.5 跑 terminal/browser、Gemini 3.1 Pro 跑 long-context research。
      • 本地:架 Ollama 或 vLLM(production 用 vLLM,2-4x 並發)+ Qwen3-Coder-Next(80B 總參 / 3B active,MoE,256K context)或 Qwen3.6,給 A 級任務專用。MoE 架構讓消費級 GPU 可跑。
      • Gateway 路由規則:A 級 → 本地、B 級 → 脫敏 + 雲端、C 級 → 直接雲端,並依任務型別選最適合的雲端模型。
    • 產出:完整雙引擎可用、第一張月度安全報告(攔了多少 A 級)
    • 四維:🔒 ✅✅✅(A 級永不出去)、🛡️ ✅(雲端掛了本地頂)、📚 ✅(成本/用量數據)、😊 ✅(員工拿到 frontier 能力)
    • 常見坑:用個人帳號的 Claude / GPT → ISO 27001 第三方供應商不過。**必須 Enterprise 合約有 DPA**,費用貴 30-50% 但這是硬門檻

    Phase 4:治理機制(W13+,與 Phase 3 並行)

    沒這個 Phase,brain 會在 6 個月內變垃圾堆。Gateway 蓋好但沒 KPI,3 個月後沒人知道有沒有效。

    Step 12 — Curator 制度(W13,2 週啟動)

    • 目標:每個 team 一個 Curator,有權合併 / 刪除 brain
    • 動作:
      • 挑選:每 team 一個 senior(自願 + 部門主管同意)
      • 授權:GitHub team admin 權限 + 每週 1 小時 review brain PR
      • 儀式:每季全公司「腦子健檢日」,半天清掃過時 brain
    • 產出:Curator list + review SLA(PR 5 個工作天內處理)
    • 四維:🔒 ✅(防止劣化)、🛡️ —、📚 ✅✅✅(知識保鮮)、😊 ✅(垃圾不會堆)
    • 常見坑:Curator 沒被分配時間 → 永遠不 review。**1 小時/週要正式排進 KPI**,不是「有空就做」

    Step 13 — KPI Dashboard(W14-W16,3 週)

    • 目標:把 North Star + 四象限 KPI 變成可看的 dashboard
    • 動作:
      • 串 Gateway audit log → Grafana / Metabase / 自寫
      • 串 firewall log → 偵測網頁版 LLM 流量
      • 串 git activity → 計算 brain 增長率
      • 每月例會看「3 個問題」:North Star、Top 3 繞過原因、安全收益
    • 產出:每月 dashboard + 月報自動產生
    • 四維:🔒 ✅(可量測)、🛡️ ✅(早期警告)、📚 ✅(歷史趨勢)、😊 ✅(高層願意持續投資)
    • 常見坑:做太多指標(20+)→ 沒人看。**只看 5-7 個**,北極星 + 四象限就夠

    Phase 5:長期演進(M5+,持續)

    系統上線後不是結束。三件事要持續做。

    Step 14 — ISO 對應與稽核準備(M5-M6)

    • 目標:把 Step 1-13 的產出對應到 ISO 27001 / 42001 控制措施
    • 動作:
      • 產出 iso-mapping.md:每條 ISO 控制措施 → 對應的 Step + 證據(git log / Gateway log / Dashboard)
      • 第一次內部稽核(找外部顧問跑一遍)
      • 修正稽核發現的 gap
    • 產出:ISO 對應表 + 稽核 readiness 報告
    • 四維:🔒 ✅✅(對外背書)、🛡️ ✅(壓力測試)、📚 ✅✅(合規資產)、😊 —(這 Phase 員工不會直接受益,但對外贏單時受益)
    • 常見坑:把稽核當一次性活動 → 證書到手就鬆懈,3 年後重審手忙腳亂。**Dashboard 要持續跑**,稽核資料 90% 自動產出

    Step 15 — 第二批工具支援(M5+)

    • 目標:涵蓋第一批沒處理的工具
    • 動作:
      • ChatGPT 透過 Custom GPT Action 串 Gateway HTTP API
      • 移動端 Claude / ChatGPT app(只能靠規則 + 教育,管不到)
      • n8n / Dify / 自建 workflow 接 Gateway
    • 四維:🔒 ✅(更多入口受控)、🛡️ —、📚 ✅、😊 ✅(更多員工享受到拉力)

    Step 16 — 過時知識淘汰機制(M6+)

    • 目標:防止 brain 累積成考古學遺址
    • 動作:
      • 每筆 brain 加 last_verified: 2026-05 frontmatter
      • 用量遙測:90 天無 reference 的 brain 自動標 stale: true
      • 每季 Curator 審 stale list,合併 / 刪除 / 更新
    • 四維:🔒 —、🛡️ ✅(防誤用過期知識)、📚 ✅✅(品質才是知識的本質)、😊 ✅(搜尋更準)

    16 Step 全景表

    Phase Step 時程 產出 主導
    0 基礎 1 Working Group W0 章程 + 例會 準 CISO
    0 基礎 2 雙 Repo W1 git repo x2 IT
    0 基礎 3 Iron Rules v0 W2 CLAUDE.md Working Group
    1 同步 4 build.sh W3 編譯器 RD
    1 同步 5 種子部門試跑 W4 ≥10 brain 部門主管
    2 分級 6 分級對應表 v0.1 W5-W6 A/B/C 表 Working Group
    2 分級 7 脫敏字典 v0 W7 三份 .txt HR + PM
    2 分級 8 Pre-commit + Browser Ext W8 兩個工具 RD
    3 Gateway 9 Gateway 骨架 W9-W11 LiteLLM 上線 RD
    3 Gateway 10 三層漏斗 W12-W14 分級+路由 RD
    3 Gateway 11 雙引擎接入 W15-W16 本地+雲端 RD + 法務(合約)
    4 治理 12 Curator 制度 W13+(並行) Curator list + SLA 部門主管
    4 治理 13 KPI Dashboard W14-W16 月報 準 CISO + RD
    5 演進 14 ISO 稽核準備 M5-M6 對應表 準 CISO
    5 演進 15 第二批工具 M5+ ChatGPT etc. RD
    5 演進 16 知識淘汰 M6+ stale 機制 Curator

    關鍵心法:這 16 步背後的設計原則

    1. 安全在前,但好用不能放最後

    Phase 0-2 都在做安全基礎設施,但每個 Step 的「好用」維度都要 ≥1 分。**安全是必要不充分,沒有好用的安全系統會被員工繞過,等於沒做**。Step 4 的 build.sh、Step 8 的 Browser Extension,都是「安全 + 好用」並重的範例。

    2. 物理保證 > 規則約束

    能用 git 結構保證的(Step 2 雙 Repo),不要靠政策文件。能用 Pre-commit hook 自動擋的(Step 8),不要靠員工自律。能用 Gateway 路由強制的(Step 11),不要靠規範。**規則會被忘記,結構不會**。

    3. 拉力 > 推力

    Step 11 雲端 frontier 接入是「拉力」核心 — 員工為什麼選 Gateway 不選網頁版?因為 Gateway 給他 frontier model + 公司腦自動注入 + 速度更快,**而且不用自己付費**。讓 Gateway 比網頁版好用,員工自然不繞過。

    4. 先粗版上線,真實流量精修

    Step 6 分級表 v0.1、Step 7 字典 v0、Step 9 Gateway 骨架都明確標 v0 / 骨架。**等想清楚才上線 = 永遠不上線**。Phase 2 試點 4-6 週收斂的速度,比關門想 6 個月快 10 倍。

    5. 治理機制與技術建設並行

    很多公司先蓋 Gateway 再想 Curator,結果 Gateway 上線 6 個月後 brain 變垃圾堆。Step 12 Curator 在 W13 啟動,**和 Step 13 KPI Dashboard 並行**,因為 brain 累積速度從 Phase 1 試點就開始,治理不能等。

    常見問題

    16 週太長,3 個月能上線嗎?

    可以,但要砍 Phase 3+4。「3 個月版」=Step 1-8 + 簡化版 Gateway(只做 proxy + audit log,不做分級),Phase 4 治理機制延後。**重點是先把基礎(雙 Repo + 分級表 + 脫敏字典 + 種子部門)立起來**,Gateway 可以 v0.5 上線、v1.0 慢慢迭代。

    16 步可以跳哪幾步?

    可跳:Step 8(Browser Ext)、Step 15(第二批工具)。 不可跳:Step 1(Working Group)、Step 6(分級表)、Step 12(Curator)— 跳了系統會壞。 可緩:Step 14(ISO 稽核)— 等系統穩定再啟動。

    一個人(全職)能撐多少?

    • Phase 0-2(8 週):一個人可獨立完成,主要是文件 + 字典 + 簡單 script
    • Phase 3 Gateway(8 週):**要 1.5-2 個 RD**,因為要做 HA + 規則層 + 雲/本地對接
    • Phase 4-5(持續):0.5 個 RD + 0.3 個 CISO 角色就能維護
    • **最低配置:1 個全職 RD + 1 個準 CISO 兼職,跑 4 個月**

    沒有 ISO 認證需求,還要做這套嗎?

    要,只是 Step 14 可以跳。這套架構即使不認證 ISO,**對「accumulating domain knowledge」「員工生產力」「資安基線」三件事**都有獨立價值。ISO 是副產品,不是目的。

    結語:安全 / 穩定 / 累積 / 好用,缺一不可

    大部分企業 AI 治理失敗,不是某一維崩了,是四維沒有平衡:

    • 只要安全 → 員工地下繞過 → 安全也沒了
    • 只要穩定 → 沒有治理 → 半年後變垃圾堆
    • 只要累積 → 沒有 Gateway → 客戶資料外流
    • 只要好用 → 沒有分級 → 一夕事故

    這 16 步的順序,就是「四維平衡的最小可行路徑」。每一步都至少打中兩維,串起來就是一個能跑、能審、能成長、員工願意用的系統。

    第 0 週要做的事只有一件:打開行事曆,把 Step 1 的 Working Group 第一次會議排進去。其他 15 步都會跟著動起來。

    延伸閱讀:《80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計》 — 講為什麼這樣設計、雙引擎本地+雲、能管 vs 不能管的邊界、拉力哲學。本文是它的實作續篇。

    2026/5 技術棧時間戳

    本文 Step 9-11 涉及的具體工具版本以撰文時間為準:

    • Gateway:LiteLLM(open source)、Portkey(內建 guardrails + PII redaction + 1600+ LLM)、Kong AI Gateway。企業常見組合 LiteLLM + Portkey 雙搭。
    • 本地 LLM:Qwen3-Coder-Next(80B-A3B MoE,256K context)、Qwen3.6、Kimi K2.6、DeepSeek V4、Llama 3.3 70B。Ollama 為日常 default,production 並發推 vLLM V1。
    • 雲端 frontier:Claude Opus 4.7(2026/4)、GPT-5.5(2026/4)、Gemini 3.1 Pro、DeepSeek V4。各家擅長領域不同,「routing by task type」是 2026 主流架構。
    • PII 脫敏:Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版),含 image redactor + DICOM 支援。
    • 合規認證:ISO/IEC 42001:2023(目前唯一可認證的 AI 管理系統標準)。Schellman、TÜV SÜD、BSI、DNV 都是合格認證機構。