小丁的家

標籤: 企業 AI

  • monday.com AI Work Platform 完整解析:4 大產品線、點數計費與 Casetify 實戰

    重點摘要

    • 2026-05-06 monday.com 從 Work Management Platform 轉型為 AI Work Platform,核心訴求是「人 + AI Agent 一起把事情做完」
    • 四大 AI 產品線:Sidekick(個人助理)、Agents(自主工作者)、Vibe(AI 開發工具)、Notetaker(會議轉錄)
    • 計費全面改成 AI 點數制:1 點 = $0.01 USD,所有產品共用同一單位
    • Casetify 用 5 個 Agent(Annie、AI 銷售管家、Eric、小蕾、AI 客服代表)跑完整 4 階段業務 lifecycle,專案準時交付率達 85%、ROI 5 倍
    • Enterprise 配套 Guardian add-on:TLE 帳號級加密 / BYOK 自帶金鑰 / DLP 資料外洩防護 / Multi-SSO
    • 支援多 LLM(Claude、GPT、Gemini)+ AI Permissions Governance 中央後台,admin 可控制誰用什麼模型在哪個 workspace
    • 誰該導入?5 種典型情境 + 6 個紅旗 + 4 種規模分水嶺 + 6 題自我檢核,文末有 50 人公司一年 TCO 估算(~$26,000–44,000 USD)

    monday.com 是什麼?從 2026-05-06 開始,它已經不是「專案管理工具」了。官方在投資人新聞稿宣布公司史上最大轉型:從 Work Management Platform 變成 AI Work Platform。這篇文章把 2026 年 5 月在台北的 monday.com × EpiCloud 線下發表會內容完整整理,涵蓋產品線、計費、實際案例、企業安全四大層面,並對照官方資料做硬驗證。

    什麼是 monday.com AI Work Platform?

    AI Work Platform 是一個不只幫你 plan 工作、還能實際執行工作的 AI-first 平台。它的差異化來自四大核心支柱:

    • Native AI Agents — Agent 原生內建,非技術人員可以設定、部署、指揮
    • Integrated AI — AI 織進每一層,從 data block 到 full-page app
    • Unified Execution — Agent 用現有的 permissions、security、governance,跨部門讀活資料來 plan、coordinate、execute
    • Flexible AI Ecosystem — 一鍵接 Anthropic Claude、Microsoft 365 Copilot、OpenAI ChatGPT

    它為什麼能跑?關鍵在 monday 本身的統一資料模型(boards / items / owners / statuses / timelines / dependencies)— 這層結構化、一致的資料,就是 AI Agent 可以 query 和 act 的 context layer。對比一般 AI 工具,這是有結構化資料當地基,不是空中樓閣。

    四大 AI 產品線:Sidekick、Agents、Vibe、Notetaker

    monday Sidekick — 個人 AI 助理

    2026 年 1 月正式脫離 beta,目前是 monday 平台 AI 的中央入口。Sidekick 是 context-aware 的,跨 boards、docs、人員理解你的工作。能力涵蓋:

    • Generate Workflows:一句話描述需求,自動建出完整 board(含 columns、groups、automations)
    • Summarize:多 board 進度、updates 自動摘要
    • Chat command 執行:直接在對話中建任務、改狀態、指派
    • Surface insights:主動抓延遲、建議 follow-up、highlight 趨勢
    • Sidekick Voice:語音互動,重要動作會先確認

    monday Agents — 自主 AI workforce

    Agents 是 monday 在這次轉型的旗艦產品。定位上叫「unlimited workforce」,代表人類自主執行任務。應用場景包括:行銷活動草稿、銷售 lead qualifying、support ticket 處理、員工 onboarding、採購單。

    新基礎建設讓 Agent 可以自行 sign up、authenticate、在平台內操作 — 換句話說,Agent 在 monday 裡是一等公民,跟人類員工同 UI 模型。在現場 demo 看到的 Campaign Planning Agent「Jennie」就是典型範例:有名字、有頭像、有人設、可被 @mention、可指派為 board item 的 owner、有 Brain tab 儲存長期記憶、有活動紀錄做 audit trail。

    monday Vibe — AI 開發工具

    Vibe 是讓非工程師用自然語言建客製化 view、dashboard、mini-app 的工具。對應前面 Sidekick 的「Generate Workflows」往上延伸:不只是 board,連完整 app 都能無 code 蓋出來。

    monday Notetaker — AI 會議助理

    邀進會議 → 即時轉錄(支援 Zoom、MS Teams、Google Meet)→ 自動產出 summary、transcript、影片錄影、action items,全部回流到 monday workspace。產出可以推到 Gmail、Slack 或其他外部工具,也可以直接寫入 CRM 的 deal timeline,讓業務不用會後手動 update。

    AI 計費:Consumption 點數制,1 點 = $0.01 USD

    2026 轉型同時 monday 把計費全面改成點數消耗制 — 所有 AI 產品共用單一計價單位「AI 點數(每月)」,1 點 = US$0.01。各產品的消耗速率如下:

    產品 消耗速率
    monday Agents 10–250 點 / 任務(視深度範圍)
    monday Notetaker 120 點 / 小時會議 = $1.20 USD/hr
    monday Sidekick 暫時免費(平台 AI 入口策略)
    monday Vibe 已發布 App + 1 張 Vibe Prompt ≈ 30 點
    monday Workflows 啟用中的工作流,每次 AI infused 執行 = 8 點

    Vibe Prompt 按模型分級計費

    Vibe 的 prompt 開始按模型消耗點數,使用者要自己決定 cost/quality trade-off:

    模型等級 模型 點數 / 則 prompt 換算美金
    輕量 Gemini Flash ~10–20 $0.10–0.20
    中等 Claude Sonnet ~30–50 $0.30–0.50
    最佳 Claude Opus ~50–500 $0.50–5.00

    關鍵觀察:Opus 一次 prompt 最高 $5 USD,monday 顯然把模型成本直接透傳給用戶 — 它自己也賠不起 Opus。這也回應業界對「AI 訂閱燒錢」的普遍焦慮:有 ROI 就用最強,沒有就退回 Flash。

    各 Plan 點數方案:Basic 卡很死,Enterprise 強制 25 席起

    Plan 起購 中階 高階 頂規
    Basic 1,000 點 ($10) — — —
    Standard 2,000 點 ($20) 4,000 ($40) 8,000 ($80) —
    Pro 3,000 點 ($30) 4,000 ($40) 8,000 ($80) 20,000 ($200)+
    Enterprise 席次 × AI 點數套裝組合 — 固定比例 1 席:800 點,最低 20,000 點(= 25 席起跳)

    Basic 1,000 點換算:大約跑得了 8 小時 Notetaker、4 次深度 Agent 任務、或 2 次 Opus 高階 prompt — 真正要用,馬上得升 Standard 以上。

    CASETiFY 實戰案例:5 個 Agent 跑完整業務 lifecycle

    CASETiFY 是全球 D2C 品牌,從手機殼起家,業務節奏跟 iPhone / Galaxy 新機同步、不停聯名 drop。100+ 國家營運、monday 使用者超過 300 人(2019 年 15 人起跳)。他們透過 AWS Marketplace 採購 monday Enterprise,把 AI 嵌進每個業務階段。

    4 階段 × 5 個 Agent 接力

    階段 Agent 名稱 AI 前 → AI 後
    1. 規劃行銷活動 Annie(行銷規劃 Agent) 人工策劃 → 自動化規劃,提升生產力
    2. 創造商機(qualification) AI 銷售管家 人工流程 → 自動規劃,更高價值互動
    2. 創造商機(outreach) Eric(銷售 Agent) 與管家分工:打電話、寄信、排會議
    3. 專案執行 小蕾(專案管理員) 遭遇風險 → 籌備下一步,減少交付延誤
    4. 客戶支援 AI 客服代表 人工分流 → 智慧分流,降低單一工單成本

    關鍵設計:商機階段刻意用兩個 Agent 分工(qualification 跟 outreach 分開),不是一個 super-agent 包山包海。Agent 之間透過 board 的 status 跟 column 接力,不直接 agent-to-agent 通訊 — 跟人類團隊 SOP 的 hand-off 邏輯一樣。

    量化成果

    指標 數字
    專案準時交付率 85%
    Scope creep 下降 20%
    ROI 5x
    PM 被追問 ticket 下降 ~30%
    內部溝通成本下降 20–30%

    CASETiFY 一年處理 600–700 個內部請求,過去靠 email + Excel + Slack 來回。導入 monday 之後,他們建了三種 board:Intake Boards(標準化請求收件)、Project Delivery Boards(可重複使用 template)、Capacity Planning Boards(產能 dashboard)。AI 做的事:長 submission 自動摘要、自動分類派工、跨語言翻譯、情緒偵測標記緊急請求。

    Growth PM Charlotte Chan 的原話:「我們一直收幾百個 request,但根本看不出有什麼進來、哪些重複、各自要花多少力氣。沒有透視度,計劃就會變成被動反應。」Engineering Director Terence Fung 補充:「monday 最大價值是真正統一的工作區 — 打掉部門 silo,讓跨團隊協作 seamless。」

    企業安全:Guardian add-on + AI Governance

    monday 對 enterprise 客戶開出兩道防線:資料層 Guardian add-on,治理層 AI Permissions Governance。

    Guardian add-on(Enterprise 專屬)

    • Tenant-Level Encryption (TLE):每個帳號專屬加密金鑰,定期輪替,跟其他客戶物理隔離
    • Bring Your Own Key (BYOK):金鑰存在你自己的雲端 KMS,你 100% 控制整個 lifecycle。撤銷 key = monday 立刻看不到你的資料(kill switch)
    • Data Leak Prevention (DLP):Admin 定義掃描規則,監控 updates 跟上傳檔案,自動執行政策
    • Multiple SSO:同帳號可配置多個身分驗證源(Okta + Azure AD + Google Workspace),適合併購整合場景

    AI Permissions and Governance

    Enterprise admin 中心提供兩個 tab:

    • AI Permissions Tab:控制哪些 role 能用 AI、在哪些 workspace 能用、用哪些 agent — 可細到單一 agent,也可一鍵套整體 default
    • Agent Directory Tab:全公司 Agent 的中央 dashboard,顯示 agent 名字、owner、sharing 狀態、目前狀態、asset access、建立日期、使用的模型。一鍵 activate / deactivate(等同「開除」Agent)

    支援的 LLM:Anthropic Claude、OpenAI GPT、Google Gemini,Sidekick 內建會為不同任務挑模型。對應前面 Vibe 那張 prompt 計費表 — 用戶或 admin 都能控制 cost/quality 平衡。

    合規認證一覽

    monday Trust Center 公開的清單:SOC 1/2/3 Type 2、ISO 27001 / 27018 / 27017 / 27032 / 27701、GDPR、HIPAA、CCPA、LGPD、PIPEDA、APPI、EU-US DPF、TX-RAMP、CSA STAR Level 1。資料中心 3 個 region:US、EU(法蘭克福)、APAC,全部跑在 AWS。

    一個容易踩雷的細節:即使選 EU region,monday 自家的 metadata(使用者憑證、profile、usage analytics)仍然存在 US — 只有 Customer Data 在 EU。法務團隊評估時這點要算進去。另外,region 由「第一個開帳號的人位置」自動決定,一旦設定不能改,真要從 US 遷 EU 得走特殊流程。

    誰該導入 monday.com AI Work Platform?

    講完功能、看完案例之後,真正的問題是:你公司適合導入嗎?monday 是個強大的平台,但不是萬靈丹。下面用情境、紅旗、規模、產業四個維度幫你判斷。

    5 種典型適配情境(這些情境,monday 真的會發功)

    情境 特徵 對應 monday 能力
    1. 大量標準化請求 一年幾百到幾千筆內部 request,目前散在 email/Slack/Excel Intake Form + AI 自動摘要分類派工(像 CASETiFY 600–700 件/年)
    2. 跨部門 silo 嚴重 行銷、業務、IT、客服各跑各的系統,資料對不起來 統一資料模型 + Agent 跨 board 串聯
    3. 業務 lifecycle 清楚分階段 行銷 → 商機 → 執行 → 客服,每階段有 SOP 多 Agent 接力,Board 當 handoff 介面(CASETiFY 5 Agent 模式)
    4. 重複性高的 knowledge work triage、分類、摘要、寫 brief、follow-up 占工時 30%+ Sidekick + Agents 自動化這些低 judgement 任務
    5. 跨國跨語言團隊 中英日韓夾雜,異地協作,時區跨度大 AI 自動翻譯 + 24/7 Agent 接力(CASETiFY 100+ 國家)

    6 個紅旗 — 出現這些就先別碰

    • 🚩 流程根本沒標準化 — 同樣的 request 每次都重新討論一次。Garbage in, garbage out,AI 只會把混亂變得更快更貴
    • 🚩 團隊 <10 人 — Basic plan 1,000 點只夠玩,要功能必須升 Standard。Enterprise(Guardian + 治理後台)強制 25 席起跳
    • 🚩 高度監管需要私有部署 — monday 是 cloud-only,銀行核心、醫療 EMR、政府內網不適合(只有 EU/US/APAC 三個 AWS region 可選)
    • 🚩 沒結構化資料基礎 — 還在用 Excel 跑生意、業務資料在每個業務私人筆記本裡。沒有 board / status / owner 概念,AI 沒有 context layer
    • 🚩 一次性專案、不重複的工作 — Agent 的價值在於規模化重複任務,單一專案直接找顧問划算
    • 🚩 只算 seat 費沒算 AI 點數 — 算 TCO 時忘了 Notetaker 120 點/hr、Vibe Opus prompt 最高 500 點/則 — 50 人團隊月跑 5 萬點 = $500 USD 是常態

    按企業規模看 ROI 分水嶺

    規模 建議 Plan 適配度 關鍵考量
    1–10 人 Basic / Standard ⚠️ 弱 AI 點數太少,Notion AI / ChatGPT Team 更划算
    10–50 人 Standard / Pro ✅ 中 Pro 點數彈性大,Vibe 應用 3 個夠用
    50–300 人 Pro(頂規 20,000 點) ✅ 強 最甜蜜點,有規模又不必上 Enterprise 門檻
    300+ 人 Enterprise + Guardian ✅ 強 BYOK / DLP / Multi-SSO / AI Governance 全套

    關鍵分水嶺:25 席 — Enterprise 強制最低 20,000 點 ÷ 800 點/席 = 25 席。10–25 人公司想要 BYOK 或多重 SSO,只能升到 25 席買 Enterprise,可能多花預算為了用不到滿的功能。這是台灣中型企業最常踩的雷。

    按產業看適配度

    產業 適配度 原因
    D2C / 電商 / 行銷代理 🟢 強適配 流程清楚、跨團隊協作密集、CASETiFY 即範例
    SaaS / 軟體 / 專業服務 🟢 強適配 數位化原生,intake/triage 量大
    製造業 / 營造 🟡 中等 看數位化深度,ERP 整合是關鍵
    教育 / NGO 🟡 中等 流程適合但預算敏感,Notion / Trello 替代
    金融核心 / 醫療臨床 🔴 弱適配 監管要求私有部署,monday cloud-only 不符合
    傳產零售第一線 🔴 弱適配 第一線員工不在電腦前,行動端體驗有限

    導入前 6 個自我檢核問題

    在掏錢前,先回答這 6 題。**5 題以上答得出來才繼續,否則先回去修內功**:

    1. 你的 intake 已標準化了嗎? — 同一類請求每次都用同一張表收?還是看心情寫 email?
    2. 你有 SOP / template 文化嗎? — 新員工三個月內能複製資深人員的工作流?還是每個人自己土法煉鋼?
    3. Stakeholder 習慣自己看 dashboard 嗎? — 主管會主動看數據還是等 PM 報告?自助看 = monday ROI 的核心
    4. 既有 SaaS 整合是否齊全? — Gmail / Slack / Calendar / Drive 用得熟?還是還在內部架 Lotus Notes?
    5. 法務 / IT 已對 AI 治理有共識嗎? — BYOK / 區域留存 / 不訓練第三方 — 法務願不願意簽?
    6. 你算過真實 TCO 了嗎? — Seat 費 + AI 點數 + Guardian + 變更成本(培訓、流程改寫)— 不只是 sticker price

    真實成本估算:50 人公司跑一年

    以一家 50 人公司 Pro plan 為例(粗估,實際以業務報價為準):

    項目 估算
    Pro 月費 × 50 席 × 12 月 ~$15,000–18,000 USD/年
    AI 點數(月跑 50,000 點 ≈ $500)× 12 ~$6,000 USD/年
    Notetaker(50 人 × 月平均 4 hr 會議) ~$2,880 USD/年(內含於 AI 點數)
    變更管理(培訓 / 流程改寫 / 顧問) $5,000–20,000 USD(一次性)
    第一年總計 ~$26,000–44,000 USD

    對應 CASETiFY 報的 5x ROI:他們省下的等於 $130,000–220,000 USD/年(主要是 PM 時間、溝通成本、減少漏單)。回本期通常 6–12 個月,前提是真的把流程改了,不是買來放著。

    變革管理 3 個重點(CASETiFY 經驗萃取)

    1. 先 1 個 board 起家 — 不要一次全公司導。CASETiFY 是 2019 年從 IT 一個 board(2 天建好)起步,慢慢擴散到 300 人。先有第一個成功案例,再橫向複製
    2. 找到一個 sponsor + 一個 super user — Sponsor 給預算和政治支持(通常是 COO/CIO),super user 教全公司怎麼用(通常是 PM 出身)。少一個都會失敗
    3. Agent 命名 + 人設 = 採用率關鍵 — CASETiFY 把 agent 取名 Annie、Eric、小蕾,有頭像有人設。研究顯示員工對「同事 Agent」採用率比「工具 AI」高 2–3 倍。心理門檻才是真門檻

    5 個導入原則(把 CASETiFY 經驗壓成一頁)

    1. 先標準化 intake — 沒這層,AI 都白搭。垃圾進垃圾出
    2. Template 化專案 — 不是每次重畫流程,踩過的坑變模板
    3. Dashboard 給 stakeholder 自助看 — 主動降低被追問次數,CASETiFY PM 被追問下降 30%
    4. AI 嵌進去 ≠ 取代人 — 加速 triage,judgement 在人身上。Agent 是擴增,不是替代
    5. monday 不是孤島 — CASETiFY 同時用 Databricks 跑資料層,monday 跑工作流層。要跟既有 stack 共存才有用

    最後一個容易被忽略的點:CASETiFY 的後端不是只有 monday — 資料層用 Databricks 統一資料湖,千萬級 SKU 平行跑模型。monday 不是孤島,要跟既有的資料 stack 共存才有用。如果你以為買了 monday 就能取代既有 ERP / CRM / BI,那是把工具當銀彈,通常會慘賠。

    結語:從工具到工作平台的範式轉移

    2026-05-06 這個日子,在工作管理軟體史上會被記住。monday.com 不只發新功能,而是整個產品定位重新定義 — 從「給人類用的工具」變成「人 + AI Agent 一起工作的平台」。Agent 在這個架構裡是 first-class citizen:有名字、有頭像、可被 @mention、可指派為 owner、有 Brain 記憶、有 audit trail、可被 admin 開除。

    對台灣中型企業來說,真正要決定的不是「要不要導入 monday」,而是「業務流程準備好讓 Agent 接手了嗎」 — Intake 標準化了嗎?Template 化了嗎?Dashboard 給 stakeholder 自助查的習慣建立了嗎?CASETiFY 那 85% 準時交付、5x ROI 不是 AI 變出來的,是 7 年累積的流程紀律加上 AI 放大。AI 是放大器,放大的是你既有的流程品質。如果流程本身是亂的,AI 只會把混亂變得更快、更貴。

  • Claude Code 訂閱 6/15 拆分:一個 Max 用戶的 evidence-based 評估與本地化反轉

    重點摘要

    • Anthropic 在 2026/6/15 把 Claude 訂閱拆兩半:互動式(終端機 Claude Code、IDE、claude.ai)維持訂閱補貼價,**程式化(Agent SDK、claude -p、GitHub Actions、第三方包裝)移到獨立 metered credit pool**,按 API 全價算。
    • 對「個人坐下來打字 + 派 Agent Team」這種使用方式,**影響幾乎是零**;真正會被打到的是把訂閱接到 Python 程式跑 24 小時 agent army 的套利型用法。
    • 但「字面合法、精神鑽縫」的灰色地帶會持續存在 — Anthropic 隨時可以用 fair use 條款補洞,你不會收到通知。**真正的應對是把 LLM 從 service 變 commodity**:本地優先 + cloud burst 的 gateway 架構。
    • 2026/5 當下的本地 stack 已經追平 frontier:Qwen 3.6-27B 在 agentic coding 上達到「半年前 400B 級」水準,DeepSeek V4-Flash 用 MoE 把 1M context reasoning 壓到 33GB 量化版可跑。**Claude API 從 default 降級成 escape hatch**。

    2026 年 5 月中,Anthropic 連續宣布三波 Claude Code 政策變動。5/6 把 5 小時池額度直接 ×2、Pro/Max 取消尖峰時段;5/13 週池額度 +50%(到 7/13 結束的補貼期);最關鍵的是 5/14 預告、6/15 生效的「訂閱拆分」政策 — 把程式化用量從訂閱補貼池移到獨立 metered credit pool。

    這篇文章是我作為一個 Claude Max 訂閱用戶,用 21 個 transcript 實際 audit + 政策原文交叉比對的 evidence-based 評估。涵蓋:三波變動的精確時間軸、Anthropic 拆分的真實業務動機、不同使用模式落到新政策的具體影響、灰色地帶與真實風險,以及用 Qwen 3.6 + DeepSeek V4 反轉成「本地優先」工作架構的可執行路線。

    三波政策變動的精確時間軸

    2026/5/6 — 5 小時池 ×2、尖峰取消。Claude Code 五小時池對 Pro / Max / Team / 企業版直接加倍。Pro / Max 取消「peak hours」限制。Claude API 的 Tier 1 input tokens 上限 +1500%、output tokens +900%。背景是 Anthropic 跟 SpaceX 簽算力協議,Colossus 1 設施提供 300MW 額外容量、超過 220,000 NVIDIA GPU。

    2026/5/13 — 週池 +50%(臨時加碼到 7/13)。週限額提升 50%,適用於 Pro / Max / Team / Enterprise。這是限定期加碼,7/13 之後會回到原本水準(除非 Anthropic 再續延)。業界解讀是 Anthropic 對抗 OpenAI Codex 搶 agent 市場的動作。

    2026/6/15 — 訂閱拆兩池(真正的結構變動)。訂閱使用從這天起分成兩個池子:

    使用方式 6/15 後歸屬 計費邏輯
    終端機 / IDE 內互動式 Claude Code互動池(訂閱)不變
    claude.ai 網頁 / 桌面 / 手機互動池(訂閱)不變
    Claude Cowork互動池(訂閱)不變
    claude -p 無頭模式Agent SDK Credit Pool按 API 全價
    Claude Code GitHub ActionsAgent SDK Credit Pool按 API 全價
    Claude Agent SDK(Python/TS)Agent SDK Credit Pool按 API 全價
    第三方包裝(OpenClaw / Conductor / Zed / Jean)Agent SDK Credit Pool按 API 全價

    SDK Credit Pool 額度按訂閱方案分配:Pro $20、Max 5x $100、Max 20x $200,Team Standard $20/seat、Team Premium $100/seat。額度不滾存,每月歸零。耗盡後可選擇 enable overage(繼續按 API 全價收費)或 disable overage(請求被 reject)。

    Anthropic 為什麼要拆?

    訂閱政策本來是「個人吃到飽」設計。Anthropic 賭你打字慢、思考慢,$20 一個月吃不爆等值的 API token 量。這個賭注在「個人開發者用 Claude 寫 code」場景下成立 — 一個人類一天寫不了 10 萬行的對話。

    但 Claude Agent SDK + 第三方包裝(OpenClaw、Conductor、Zed、Jean)讓人可以把 $20 訂閱接到自己寫的 Python 程式,24 小時不停跑 agent army,實際 token 量遠超過 $20 等值。等於把吃到飽 buffet 整個載走轉賣 — 訂閱被當成「便宜 API」用於 production 流量。

    Anthropic 沒禁這條路,只是把它改成獨立 metered 預算 — 「載走轉賣」要另外算錢,「個人坐下來吃」不動。順便擋住 OpenAI Codex 用低價搶 agent 市場,也保住 unit economics 才有錢付 SpaceX 那 300MW 算力擴張的帳。

    實際使用模式 audit:21 個 transcript 看出什麼

    政策評估不能憑印象,要有實際使用 evidence。我盤點過去 28 天的 Claude 使用情況:

    • 21 個 transcript / 13 個唯一日期:不是每天用,平均一週 3-4 天
    • 互動式為主:全部 transcript 都是終端機 Claude Code session,不是 SDK / API 程式化呼叫
    • ccbot Telegram bridge:bridging interactive session,不是獨立 inference
    • 5 個 claude-harness-* hook:全是 SessionStart / PostToolUse / PreCompact 注入,在 session 內運行
    • claude-limited cgroup wrapper:也是互動 session 內
    • Agent Team 18-25 並行:從 interactive session 用 Agent tool 派
    • /loop, /schedule, GitHub Actions, 第三方包裝:全沒有
    • crontab 11 條:全是 stock data 收集(analyst / TDCC / 機構投資人),完全不叫 Claude
    • 唯一例外:某個內部 LLM 評估 harness 有一條 subprocess.run(["claude", "-p", ...])

    把這份 audit 對照 6/15 政策表格,結果出奇地簡單:21 個 transcript 裡有 20 條繼續走訂閱池,只有 1 個 evaluation harness 那條 claude -p 會搬到 SDK Credit Pool。

    政策真正落到「典型重度使用者」頭上的點

    對於從終端機 / IDE 互動式使用 Claude Code、用 Agent tool 派 subagent、寫 brain / skill / memory 系統的人 — 也就是 Anthropic 設計訂閱時瞄準的客群 — 6/15 變動實質影響趨近於零。

    真正被打到的只有四類具體模式:

    1. 把 claude -p 串進 shell pipeline 或 CI/CD:每次 invocation 從訂閱池移到 SDK Credit Pool
    2. 用 Agent SDK 寫的 Python / TypeScript 程式:無頭運行的 production agent,完全脫離訂閱
    3. Claude Code GitHub Actions:CI/CD 整合在 workflow 內呼叫 Claude
    4. 第三方包裝:OpenClaw、Conductor、Zed、Jean 這些把 Claude 訂閱接成 IDE 後端的工具

    如果你已經習慣「人在前面打字,Claude 在後面派 agent 跑」的工作模式,這個政策變動就是 一個不會發生的事件。

    灰色地帶:cycle + Agent Team 字面合法但精神鑽縫

    但有一種模式介於兩者之間,Anthropic 官方文件沒明寫:從 interactive session 派出大量 Agent Team,搭配 /loop 或 hook-based cycle 讓 session 自動延續。

    技術上這完全合法。6/15 政策字面只點四個對象:claude -p、Agent SDK、GitHub Actions、第三方包裝。「cycle + 大量 Agent Team + 自動啟動循環」如果全部跑在 interactive Claude Code session 裡(用 Agent tool 派、用 /loop 接同 session、用 hook 觸發),技術上會被歸到互動池。

    但這顯然是「字面 vs 精神」的縫。Anthropic 拆這條政策的精神,就是要擋「沒人盯每一回合的大量自動化」 — 第三方分析給出的啟發式是:「if a Claude session runs without a human watching each turn, it is almost certainly moving to the new credit pool」。從這個精神判讀,大規模並行 Agent Team + 自動 cycle 精神上根本就是 programmatic,只是技術上沒被點名。

    兩個現實風險

    風險一:這個縫不會永遠在。Anthropic 看到統計上的 outlier 用戶(Max 訂閱跑出 Tier 4 API 等級的 token 量),下一輪政策補刀的機率不低。半年後可能變「subagent 從 interactive 派也算 programmatic」、或「同 session 自動 cycle 超過 N 次轉計費池」。歷史上 Anthropic 對訂閱濫用模式都是先觀察後動手 — 5/14 這次拆分本身就是這個 pattern 的證據。

    風險二:Fair use 抽象條款隨時可以動你。Terms of Service 寫的「abuse / excessive use」沒精確定義,他們覺得單帳號太誇張就可以單獨 throttle 你帳號,不需要先改政策、不需要事前通知。被點到的人通常只看到「Claude 突然變慢 / 限額變嚴 / 某些 tool 失效」,不會收到正式告知信。

    精確版說法:「字面合法、精神鑽縫、風險押在 Anthropic 不回頭補洞」。在他們補洞之前你賺,補了之後可能在毫無預警的下次續訂看到 SDK credit 開始扣 — 或更早,某一天突然發現自己被限流。

    反轉戰略:從 service 用戶變成 commodity operator

    真正的應對不是「擠到最後一秒用爆」,是 把工作系統的依賴從 Claude 拆出來,讓 LLM 變成可替換的 commodity。這個轉變的本質是反轉預設值:

    層級 現在(service 模式) 反轉後(commodity 模式)
    日常 code / reasoningClaude 預設,本地 fallback本地預設,Claude API 偶爾 burst
    Agent TeamClaude 的 Agent tool本地 orchestrator + 多 model 異質並行
    超長 contextClaude APIQwen 3.6 / DeepSeek V4 / Gemini 三家擇優
    A 級 PII / 客戶名 / 合約本地 7B(品質不夠)本地 70B 級,品質可用且不上雲
    vendor lock-in 風險Anthropic 政策變動 = 工作系統危機改 gateway config 而已

    架構的關鍵是 gateway 抽象層:用 LiteLLM 或自己寫一個薄 wrapper,讓所有 code 對外只看到一個介面 llm.complete(prompt, model_tier="cheap|standard|premium")。底下接什麼模型是 config,不是 code。Claude 政策再變、Anthropic 真的把帳號限流、OpenRouter 出新便宜模型 — 改一個 config 全部換完,所有專案不動。

    2026/5 最新 open weights stack:本地能跑什麼

    2026 中的 open weights 市場已經到「local 27B ≈ 半年前的 frontier closed」階段。對於配備獨顯 + 100GB+ RAM 的工作站,實際可選的本地 stack:

    Qwen 3.6 系列(2026/3-4 發布)

    • Qwen 3.6-27B(dense)— flagship 級 agentic coding,Q4 約 14GB VRAM。官方宣稱超越上一代 Qwen 3.5-397B-A17B,即「27B 在 2026 ≈ 半年前 400B 的水準」
    • Qwen 3.6-35B-A3B(MoE,35B 總參數 / 3B 啟動)— Q4 約 18GB。MoE 設計每次只算 3B 參數所以很快,適合並行 Agent Team
    • Qwen 3.6 Plus / Max-Preview — closed weights API only。Plus 在 Terminal-Bench 2.0 已贏 Claude 4.5 Opus(61.6 vs 59.3),SWE-bench Verified 還小輸(78.8 vs 80.9)。1M context、reasoning 預設。當 cloud burst 比 Anthropic API 更划算

    DeepSeek V4(2026/4/24 發布)

    • V4-Flash:284B 總參數 / 13B 啟動 MoE,完整模型需 ~170GB VRAM,重度量化壓到 33GB VRAM 可跑(2× RTX 4090 或 1× RTX 6000 Ada)
    • V4-Pro:1.6T 總 / 49B 啟動 — 100GB RAM 跑不了,跳過
    • 1M context native,hybrid attention(CSA + HCA)推理 FLOPs 比 V3.2 省 73%
    • 這是「反思 / 跨領域類比」的本地頂配

    Llama 3.3 70B 與其他

    Llama 3.3 70B ecosystem 最大,Q4 約 35GB。不再是 2026 中的首選,但作為「異質 diversity」角色仍有意義 — 同一 task 給不同 model 看,異質訓練資料能產生 outlier insight,單一 model 並行做不到。

    100GB+ RAM 機器的實際配置

    100GB 對 Qwen 3.6 系列來說是過剩配置。所以這台機器的設計目標不是「能跑大 model」,是「多 model 並行讓 Agent Team 有真實 diversity」:

    常駐 hot 在記憶體(同時 load):
├── Qwen 3.6-27B  → 主力 code / 對話       (~14GB)
├── Qwen 3.6-35B-A3B → 快速 Agent Team 主體 (~18GB,MoE 跑很快)
├── DeepSeek V4-Flash 量化版 → reasoning 深度  (~33GB)
└── Qwen 3.6-7B 之類 → 路由 / 簡單分類     (~5GB)
總計 ~70GB,留 30GB 給 vLLM cache + OS + agent 並行 context

按需 load(cold,需要時起):
├── Llama 3.3 70B Q4 → 異質 diversity 用    (~35GB)
└── 其他特殊微調 model

    Cloud burst 的新排序

    在 2026 中的市場狀態下,Anthropic API 不再是首選 burst 選項。新排序建議:

    1. Qwen 3.6 Plus API(阿里雲)— 主 burst。超長 context + 一般複雜任務。價格約 Claude Sonnet 的 1/3,Terminal-Bench 已贏 Claude 4.5 Opus
    2. Gemini API(Google)— multimodal / OCR / 大文件處理
    3. DeepSeek V4-Flash API — reasoning 硬 case 沒本地版時的備援
    4. Claude API — 只有「Anthropic 那條 reasoning 風格特別合用」的 edge case 才開,從 default burst 降級成偶爾用一下的特殊風味

    架構全景圖

    把上面所有層拼在一張圖上:應用層 → LiteLLM gateway 路由 → 本地 vLLM(95% 流量)+ Cloud burst(5%)→ 底層 model-agnostic 的 brain / skill / memory data layer。

    APPLICATION LAYER
    Aider · Open WebUI · Custom Agent Orchestrator(walsin/teams 通用化)
    ↓
    OpenAI-compatible API
    LITELLM GATEWAY
    routing rule = config,不是 code
    task tier → backend
    code / chat→LOCAL Qwen 3.6-27B
    Agent Team→LOCAL Qwen 3.6-35B-A3B(MoE,快)
    reasoning→LOCAL DeepSeek V4-Flash(量化)
    routing→LOCAL Qwen 3.6-7B(輕量分流)
    超長 context→CLOUD Qwen 3.6 Plus API(1M ctx)
    multimodal→CLOUD Gemini API
    edge reasoning→CLOUD DeepSeek V4-Flash API
    特殊風味→CLOUD Anthropic API(escape hatch,不是 default)
    ↓
    LOCAL(~95% 流量)
    vLLM on 100GB+ RAM + GPU
    HOT(同時 load):
    • Qwen 3.6-27B — 14GB
    • Qwen 3.6-35B-A3B(MoE)— 18GB
    • DeepSeek V4-Flash 量化 — 33GB
    • Qwen 3.6-7B 路由 — 5GB
    合計 ~70GB,留 30GB 給 vLLM cache + agent 並行 context
    COLD(按需 load):
    • Llama 3.3 70B — 異質 diversity
    • 特殊 fine-tune
    CLOUD BURST(~5% 流量)
    按 token 計費,非訂閱
    • Qwen 3.6 Plus — 阿里雲(主 burst)
    • Gemini API — Google
    • DeepSeek V4-Flash API
    • Anthropic API — 偶爾用 only
    用途:
    • 超長 context (>32K)
    • 圖片 / OCR
    • 本地解不出來的硬 case
    • A 級 PII 絕不出現在這層
    ↓
    DATA / MEMORY LAYER (model-agnostic,完全不動)
    Brain.md · Skill.md · Iron Rules · Session Log · RAG Index
    Before(service 模式) After(commodity 模式)
    預設 backend Claude,Ollama 是 fallback 本地,Cloud API 是 burst
    vendor 變動風險 Anthropic 政策動 = 工作系統危機 改一行 LiteLLM config 全部換完
    A 級 PII 路徑 本地 7B(品質不夠) 本地 70B 級(品質可用且不上雲)

    這張圖的核心訊息:所有 vendor 都在 gateway 後面,application code 完全不知道下面是誰。Claude 政策再變、Anthropic 真的把帳號限流、阿里雲漲價、Gemini 改 API — 改一個 routing config 全部換完,brain / skill / memory data layer 一行不動。

    軟體 stack 建議

    • vLLM — inference server,提供 OpenAI-compatible API。Code 對外就是 OpenAI 格式,model 可以隨時換
    • LiteLLM — gateway 抽象層。前面接所有 backend(本地 vLLM + Anthropic API + Gemini + Kiro)。Code 只認 LiteLLM,backend 換不換無感
    • Open WebUI 或 Aider — 取代 Claude Code 對話介面的 interactive REPL
    • 自家 agent orchestrator — 不要依賴 Claude 的 Agent tool,自己寫 multi-process 派發。pattern 可以參考開源的 CrewAI、AutoGen,或像我自己有的 ABC 三級分流 evaluation harness 通用化

    過渡期(現在到 6/15)該做的事

    1. 建立 baseline metric:從今天開始每天結束前記錄 claude /usage 截圖或 log 到檔案。沒 baseline,出事時你連「被砍多少」都判斷不出來
    2. 盤點所有 claude -p 用法:grep -rn "claude -p" ~/ 找出來。每一條都是 6/15 後會從訂閱池搬家的成本點
    3. 後備模型 stack cheat sheet:寫一份 1 頁文件「如果 Claude 突然不能用,brainstorming 切去 X、code review 切去 Y、daily 工作切去 Z」。不要等出事才想去哪找
    4. Agent Team 預設規模降到 6-8:18-25 改成「報備使用」。這同時對抗 token 燒速、降低被點為 outlier 的機率,順便逼自己思考「真的需要這麼多視角嗎」
    5. 5/20 到 7/13 是補貼期:互動池 +50% 週限額。這 8 週是 Agent Team 衝刺 / 大規模 refactor 最划算時段

    真的被限流了怎麼辦

    先診斷不要先動作。連 Anthropic console 看是哪一條被扣 — credit pool 被扣 vs 互動池速率變慢是兩個完全不同問題,處理方法不一樣。

    立刻把 hot path 切到備援。Agent Team 規模直接砍半、evaluation 暫停或全切非 Claude 後端、日常工作切 Ollama 本地 + Gemini 雲混合。這幾個動作 1 小時內要能做完,不是出事當下才開始研究。

    正式申訴 + 評估升 Max 20x。如果你判斷被誤分類(明明是 interactive 被當 programmatic),開 ticket 跟 Anthropic 講。同時評估:接下來工作密度有沒有可能升 Max 20x,把 $200/月 credit 當成「事故緩衝」不是「正常用量」。

    結語:訂閱不是 token 額度,是時間窗

    最重要的觀念修正:你訂閱 $100/月給你的不是「token 額度」,是「Anthropic 暫時容忍你這種重度用法的時間窗」。這個窗會關。準備的本質是「窗關了我有沒有別條路」,不是「擠到最後一秒用爆」。

    反轉成本地優先 + cloud burst 的真正好處,不是省那 $100/月,是 把 LLM 從 service 變成 commodity。你不再是 Anthropic 的 user、Google 的 user、阿里雲的 user,你是一個有自己 stack 的 operator。任何一家政策變、漲價、限流、倒閉,你都只需要改一個 config。

    對 2026 中要進企業環境推 LLM 的人來說,這個論述也是直接合規上的加分 — 集團真實場景就是要 A 級 PII 不上雲、不能綁單一 vendor、不能讓核心評估綁在個人帳號上。本地優先架構直接符合這三條,不需要為了合規綁手綁腳。

    Anthropic 6/15 拆分對「個人坐下來用」這群人是非事件。但它送出的訊號很清楚:訂閱補貼的時代正在收窄,LLM 市場往真實計費走。早一步做反轉的人,不是因為政策才動 — 是因為看到方向,提早把脆弱性拿掉。

  • 腦子系統壓軸:萬人製造集團 AI 治理 1 年實戰藍圖

    重點摘要(TL;DR)

    • 腦子系統前 7 篇是理論藍圖。本篇是萬人跨國製造集團 1 年實戰執行版:Day 1 到 M12 的 5 個 Phase Gate、三層治理、預算 NTD 4,000-6,000 萬具體 breakdown、22 個關鍵 gap、5 場真人會議。
    • 骨架不是憑空寫的 — 經過 4 輪 AI agent review × 10 個 domain × 28 份 expert opinion:CISO / AI 治理 / ERP / 法務 / IT 架構 / 組織變革 / 製造業 BU senior / HR / CFO / 外部會計師。
    • 核心心法 5 條:鄉村包圍欽點啟動、三條紅線下放、90 天法律化(非 30 天)、三道防線(內稽必須第三線獨立)、預算具體到 NTD 級距(非「中等到中高」)。
    • 給 CIO 的訊息:這份藍圖的價值不是告訴你答案,是告訴你接下來要問哪 5 群真人哪些問題。
    • 本文是腦子系統八部曲的壓軸實戰篇。前七篇:Why / How / Scale / Tools / ERP / Self-Service / ISO。

    一、為什麼寫這篇

    腦子系統前 7 篇講的是理論:為什麼這樣設計、怎麼蓋、怎麼擴展。但理論到實戰之間,有一條鴻溝 — 萬人跨國集團的真實政治、文化、預算、合規。

    這個鴻溝不是 1 篇文章 + 1 個 IT 主管腦袋能跨過。我為一家萬人製造集團寫了完整的 1 年實戰藍圖,經過4 輪 AI agent review × 10 個 domain expert(總共 28 份 expert opinion)後,把所有 cross-confirmed 的議題壓縮成這一篇。

    10 個 domain 包括:

    • CISO 資安(ISO 27001 + OWASP Top 10 LLM 紅隊)
    • AI 治理(ISO 42001 + 倫理 + 偏見)
    • ERP 架構(SAP / Oracle / iDempiere / Dynamics)
    • 法務合規(個資法 / 營業秘密法 / GDPR / 勞基法)
    • IT 架構(K8s / Gateway / SRE / vLLM)
    • 組織變革(萬人台灣集團 + 家族企業文化)
    • 製造業 BU senior 主管(20 年資歷)
    • HR / 員工關係(第四輪新增)
    • CFO / 財務(第四輪新增)
    • 外部會計師 / 內控(第四輪新增)

    每一個 domain 都找出了前面 9 個 domain 沒看到的盲點。這是本文跟一般 AI 治理藍圖的根本差異:不是某個 IT 主管的個人見解,是 28 份不同視角壓縮的最大公約數。

    二、戰略骨架(一句話)

    鄉村包圍城市:三條集團紅線下放 → 各 BU 自然生長 → 根據地正規化 → Working Group 整理已發生事實 → 集團 Gateway 上線。

    不從總部開始,從願意動的 BU 開始。起爆階段必須欽點(不能等自願)、擴散階段才靠拉力。

    為什麼不用傳統由上而下:啟動成本太高、規範是空白紙上畫的(法務全判 A 級系統失效)、員工沒採用動機。

    三、三條 Iron Rules + 90 天法律化(不是 30 天)

    1. BOM 配方 / 製程參數 / 合金成分 / 熔煉 know-how
   → 禁止送任何雲端 LLM
   → 「送出」涵蓋: completion / embedding / vector / fine-tune /
     batch / log retention / 第三方 RAG
   → 違反視同營業秘密外洩

2. 未公告財報數字(月報 / 季預估 / 年度計畫 / 財務假設)
   → 禁止送任何 AI 工具(含本地)
   → 違反視同內線交易風險

3. 客戶合約 / 訂單金額 / 供應商報價 / 客戶聯絡資料
   → 禁止送雲端 LLM
   → 須脫敏後才可使用 AI 協助分析

    第一個重大修正(來自會計師 review):CIO 一人簽 Iron Rules 在台灣上市公司治理上有重大瑕疵 — 涉及營業秘密 + 重大資訊管控屬資安政策層級,需經審計委員會或董事會核備。CIO 單簽日後查核會被會計師列 deficiency。

    真實時程 90-120 天(原藍圖寫 30 天嚴重低估):

    階段 動作 時間
    Day 1 CIO 緊急發布(行政命令位階)+ 全員 email 1 天
    Day 1-30 CISO 簽核 + 法遵核可 30 天
    Day 30-60 工會協商(勞基法 § 70 細則,30 天起) 30 天
    Day 60-90 工作規則修正報主管機關核備 14-30 天
    Day 90-120 審計委員會核准 + 董事會決議 30 天

    過渡期免責條款(會計師建議):Day 1-90 期間若違規,公司立合規導向處理(培訓 + 警告),不得作為解雇 / 賠償依據。否則「合理保密措施」舉證會被法院質疑。

    工會協商失敗 fallback(HR review):Iron Rule 1(BOM)走營業秘密法 § 13-1 強制,不需工會同意;Rule 2/3 走員工自願同意 + 工具權限分流(不簽就限制 AI 工具,不解雇)。

    四、五個 Phase Gate

    Gate 月 通過硬條件
    G0 啟動 M1 CIO 簽 Iron Rules + 任命準 CISO + 法遵 / 內稽通知
    G1 種子 M3 至少 2 個 BU 各 5 人在用、無 Iron Rules 違反
    G2 根據地 M4-M5 至少 2 BU 完成雙 Repo + 分級表 v0.1 + 脫敏字典
    G3 包圍 M8 Working Group 4 場核心會議完成 + 集團 v1 + AIIA SOP + Iron Rules 走完董事會核准(若 M8 未完,fallback「議程已排定 + 審計委員會初審通過」)
    G4 進城 M9-M10 Gateway + 雙引擎接入 + 北極星 70% + ERP MCP 1 BU 跑(用 Token Impersonation,不是 service account)
    G5 稽核就緒 M12 內審完 + Gap 補完 + ISO 27001 + 42001 stage 1 audit 通過

    五、三層治理結構(三道防線正確版)

    第二輪 AI review 點出 v0.2 違反三道防線(內稽應第三線獨立),v0.3 大幅修正:

    [第二線:管理]
├─ Steering Committee(每季 sponsor)
│  └─ 家族成員 / 總經理室掛名,不參與每月運作
│  ⚠️ 議事規則明文「不得對 Working Group 個案決議下指導」+ 會議錄音
│
└─ Working Group(7-8 人,雙週例會,治理者)
   ├─ 準 CISO(主席)
   ├─ 法務 / 法遵代表
   ├─ IT/RD 代表
   └─ 3-4 BU senior 代表

[第三線:獨立監督]
└─ AI 治理監督委員會(每季,獨立)
   ├─ 內稽處長(召集人,雙線報告:行政→CIO,職能→審計委員會)
   ├─ 1 名獨立董事
   └─ 外部顧問(由審計委員會選聘 + 預算獨立 + 3 年輪換)

   季度 audit Working Group 自身 + Gateway log + bias probe
   直接向審計委員會報告(不經 CIO)

[第一線:執行]
└─ BU 內部
   ├─ BU Curator(技術骨幹,每週 45 分跑 PR)
   ├─ BU Senior 把關人(每週 15-30 分簽字)
   └─ BU 種子員工

    家族干預仍是 SOX 疑點(會計師 review):即使家族「掛名 sponsor」,Big-4 仍可能列「tone-at-the-top deficiency」。所以加 Steering Committee 議事規則 + 會議錄音是必要補丁。

    外部顧問獨立性閉環:必須由審計委員會選 + 預算獨立 + 3 年輪換 + 不得轉任公司任何職位,否則 Big-4 視為 management’s specialist 形同虛設。

    六、AI Agent Team 編制 + Curator HR 認證

    v0.1 寫「BU senior 兼任 Curator 每週 1 小時」,但 HR review 點出實務上 100% 推給課長 / 工程師 — senior 行事曆已被「客訴會、月結、業務檢討、產能調度」塞滿。v0.3 拆角色:

    • BU Curator(技術骨幹):>8 年資歷工程師,每週 45 分跑 PR review
    • BU Senior 把關人:senior 主管,每週 15-30 分簽字 + A 級判斷 + 口述補充業務知識

    HR 認證制度(避免空文化)

    • 完成 6 個月任期 + brain 達標 → HR 核發「AI 治理認證」
    • 0.5 P-band 加分(等同跨部門輪調)— 但需走集團人才發展委員會核可,IT 處單獨發會被 HR 退件
    • PBC 5%-10% 權重(集團強制下限 7%,避免 BU 主管壓到 5%)
    • senior 連 2 週缺席 → 自動升級 CIO,1 個月失能撤銷認證
    • 分初級 / 資深 Curator:資深需 2 年 + 跨 BU 貢獻才核發,避免認證貶值(1-2 年後人人有獎=沒獎)

    培訓教材決策(M2 必須定)

    8 小時 OWASP Top 10 LLM + ISO 42001 + 公司 brain 規範。中文教材沒現成 — 外購(BSI / SGS 客製課 35-60 萬/梯)vs 內製?M2 前必定。HR LMS(Cornerstone / SuccessFactors / 自建)需要排版上架、考題設計、合格標準 ≥ 80%、補考機制。

    七、預算 NTD 4,000-6,000 萬具體 breakdown(CFO 視角)

    v0.3「中等到中高」級距完全不能進審計委員會。CFO 真實要的數字:

    項目 級距 NTD 備註
    CapEx GPU 3-5x H100 1,200-2,000 萬 DGX 整機約 $300K USD/台,5 年攤提 ≈ 250 萬/年
    CapEx 多台 4090 200 萬 本地推理 + Layer 2 分類器
    OpEx 雲端 LLM Enterprise 1,500-3,000 萬/年 萬人 seat × $40-80/月(Anthropic / Azure / Bedrock)
    OpEx ISO 雙標稽核 + 內審準備 200 萬 Schellman / TÜV SÜD / BSI / DNV 任選
    OpEx RD x 2 + Curator 折算 600 萬
    OpEx SIEM 自架 stack 100-150 萬 OpenSearch + S3 + Glacier vs Splunk 商業版 3,000-8,000 萬,自架降一個量級
    OpEx 培訓教材外購 60-100 萬 BSI / SGS 客製課
    Year 1 全包 4,000-6,000 萬 這是 CFO 要的具體數字

    稅務套利(產創條例 §10-1)

    • GPU CapEx 認列「智慧機械」可申請 5% 投資抵減營所稅
    • 萬人集團單年 H100 採購 1,500 萬 → 抵減 75 萬
    • 5 年攤提下,財報「壓力」比一次性 OpEx 燒掉小

    ROI / Risk-Adjusted Savings(對審計委員會講)

    • 避免 GDPR 罰鍰:營收 4% 上限(萬人製造集團風險:數十億)
    • 避免 ISO 失效訂單損失:B2B 客戶常要求 ISO 認證,失效 = 失客戶
    • 員工生產力:保守 5% × 萬人 × 平均薪資 = 數億效益
    • 對審計委員會用「保險費比喻」,不要堆生產力數字

    預算占比 / 排擠效應

    • 萬人製造集團年 IT 預算約營收 0.8-1.5%
    • AI 治理 4-6 千萬 ≈ IT budget 8-12%
    • 會排擠 ERP 升級 / MES / 製造 IoT — 必須在董事會列「AI 治理 vs 其他 IT 投資」優先序

    隱性成本(v0.3 漏)

    • Layer 2 GPU HPA 4x baseline → 雲端 burst 月結尖峰可能單月燒 30% 預算 → 加 monthly cap
    • 廠商封鎖演練(每年 1 次)→ 計入 BCP 成本
    • WORM 7 年 audit log 取出費(egress)→ incident 時單次可能數十萬,需準備金

    八、Audit Log 三軌制(法庭採信 + 個資合規)

    Track 內容 保留 儲存 / 解密
    A. Metadata 員工 hash、tool、decision_code、bu_context、token jti 7 年 WORM OpenSearch 30天 → S3 1年 → Glacier 7年;HSM mapping CISO+法務雙簽
    B. 全文 prompt/response 完整對話內容 90 天 OpenSearch 加密分離,90 天自動刪
    C. Incident 凍結全文 觸發事件相關全文 7 年 WORM S3 Object Lock;CISO+法務+內稽三方簽

    HSM mapping 雙簽 break-glass 必須留書面審批單(會計師補丁):申請書 + 核准單 + 時戳服務(TWCA)。否則 SOX 404(d) ITGC 證據能力不足。

    勞動事件法 § 35(法務補丁):員工有舉證請求權調閱自身 audit log → 加員工查閱 SLA 14 天 + HR 介接窗口。

    九、4 輪 AI review 找出的 22 個 cross-confirmed gap

    從 28 份 expert opinion 提煉的最重要議題,按 review 階段:

    第一輪(v0.1 → v0.2,7 個 expert):結構性問題

    • Iron Rules 加 embedding / vector / fine-tune 涵蓋(防 OpenAI embedding 破口)
    • Curator 拆角色(senior + 技術骨幹)
    • Multi-ERP 不做統一 schema
    • SAP S/4HANA 工程量 6-9 個月(原估 3-4 嚴重低估)
    • Token Impersonation 強制(禁用 service account)
    • 三條 Iron Rules 治理路徑(CIO 簽不夠)
    • Brain PR Scanner + 雙審 + 簽章 commit

    第二輪(v0.2 → v0.3):重大治理結構

    • 三道防線正確化(內稽從 Working Group 退出第三線獨立)
    • 家族介入降溫(Steering Committee 季度 sponsor,不掛主席)
    • WORM 三軌制(metadata 7年 / 全文 90 天 / incident 7 年)
    • MCP tool schema 欄位級遮罩
    • iDempiere MSession + cache 分級 + 月結 SLO 例外
    • Gateway K8s HPA 5-15 pods(不寫死 3)
    • GPU 容量 3-5x H100 + 區域副本
    • 同意書脫鉤雇用條件
    • per-BU view scope(不全集團統一最高 A 級)
    • 跨境 geo-routing by 工作地 BU(不 by 國籍)

    第四輪(HR + CFO + 會計師)— 進階 gap(只在新 domain 加入後才被發現)

    • §16 重寫具體 NTD 級距 + 產創條例 §10-1 + ROI(CFO P0)
    • 30 天法律化時程改 90-120 天 + 過渡期免責(會計師 P0)
    • 監督委員會獨立性閉環(內稽行政線雙線報告 + 外部顧問獨立預算 + 3 年輪換)(會計師 P0)
    • HSM break-glass 留書面審批單 + 時戳(會計師 P0)
    • bias probe 獨立 validator(自選 = 自評違反 A.6.2.4)(會計師 P0)
    • 工會協商 fallback(HR P0)
    • HR LMS + 培訓教材外購 / 內製決策(M2 必定)(HR P0)
    • 退休 / 離職 brain 智財 + 錄影同意 SOP(HR P0)
    • 勞動事件法 § 35 員工查閱 SLA 14 天(法務 P0)

    關鍵 insight:第四輪 9 個 gap 是前 3 輪沒有任何 expert 點到的 — 這證明 HR / CFO / 外部會計師三個 domain 是真正的盲點。任何 AI 治理藍圖如果沒有這 3 個 domain 獨立 review,等於沒做完。

    十、真人 review 接手 — 5 場會議

    會議 時長 對象
    法律 / 合規 review 2-3 hr 法遵處長 + 外部勞動法律師 + 個資律師 + 工會代表
    組織治理 review 2 hr CIO + 法遵 + 內稽 + 獨立董事 + 審計委員會
    財務 review 2 hr CFO + 財務副總 + 集團 IT 預算負責人
    HR review 1.5 hr HR 處長 + LMS 負責人 + 工會代表
    IT / 工程 review 2-3 hr IT 主管 + RD lead + ERP 顧問
    BU 實戰 review 各 1.5 hr BU senior + 種子員工(各 BU 一場)
    ISO 機構 mock audit 半天 Schellman / TÜV SÜD / BSI / DNV 任選

    第一次 mock audit 應在 M9(不是 M11),時間夠改正。SOC 2 Type 2 需 6 個月運行證據,M12 才 Stage 1 → SOC 2 Type 2 報告最快 M18+。

    十一、Day 1 待確認的 6 件事

    1. 三條 Iron Rules 法務 review — BOM 配方、未公告財報、客戶合約合不合法務認知
    2. ERP 現況 — SAP / iDempiere / Oracle / Dynamics / 混合?(影響 30% 工程量)
    3. 準 CISO 人選 — IT 主管?資安代表?
    4. 種子 BU 候選 — 欽點 1 個營收前三主力 BU(不要等自願)
    5. 預算核給 — Year 1 NTD 4-6 千萬具體編列
    6. ISO 稽核機構意向 — Schellman / TÜV SÜD / BSI / DNV 任選一家

    十二、給 CIO 的最後三句話

    三條 Iron Rules + 90 天法律化 + 鄉村包圍欽點啟動 = Day 1 全部要做的事。

    4 輪 AI review + 28 份 expert opinion 找到的 22 個 gap 是骨架。真正的肉、血、溫度,在你接下來那 5 場真人會議。

    這份藍圖的價值不是「告訴你答案」,是「告訴你接下來要問哪 5 群真人哪些問題」。

    延伸閱讀:腦子系統八部曲

  • 腦子系統 ISO 整合治理框架:6 篇收成 1 個合規可審計藍圖

    重點摘要(TL;DR)

    • 把腦子系統前六篇收成合乎 ISO 27001:2022 + ISO 42001:2023 的整合治理框架。雙標準有 ~40% 重疊,已 27001 認證可快 30-40% 取得 42001。
    • 多場景多用戶多工具的統一架構:5 個共用元件(Gateway / 分級表 / Audit log / Curator / KPI Dashboard)+ 4 類工具(Coding Agent / Chat-native / Bridge / Self-service HTML)+ 5 種角色(銷售 / 客服 / 採購 / RD / 管理層)。
    • 鄉村包圍踏實落地的 5 個 Phase Gate:每個階段過渡前要過硬條件,對應 ISO 稽核里程碑。沒過 Gate 不要硬上下一階段。
    • 月度健檢三個關鍵指標:覆蓋率(80%+)、合規 gap 減少率、稽核就緒度。月度報告 ≠ 一次性稽核 — 持續可量測。
    • 稽核準備 90% 自動化:從 git log / Gateway log / Audit DB / Curator review 自動 export,RD 投入時間從 1-2 個月降到 1-2 週。
    • 本文是腦子系統第七篇收尾。前六篇:Why / How / Scale / Tools / ERP / Self-Service。

    一、問題重述

    腦子系統六篇文章寫完後,有個關鍵問題沒明確收斂:

    1. 整套架構合不合 ISO 27001 + ISO 42001?哪些直接合、哪些有 gap?
    2. 第三篇的「鄉村包圍」策略講了大方向,但怎麼穩定踏實做完?哪些真實風險會讓計劃流產?
    3. 多場景(銷售/客服/RD/管理層)、多用戶(80 人 vs 萬人)、多 AI 工具(Claude Code / OpenCode / QwenPaw / Self-service HTML)— 怎麼用一套框架統一治理?
    4. 怎麼確保多方都得到正確、安全、合規、整合的資料?

    本文是腦子系統的收尾整合,把前六篇收成可審計、可執行、可量測的治理框架。

    二、ISO 範圍界定(事實驗證)

    2.1 適用標準三件套

    標準 範圍 關鍵內容
    ISO 27001:2022 資安管理(ISMS) Annex A 共 93 controls,4 themes(Organizational 37 / People 8 / Physical 14 / Technological 34)
    ISO 42001:2023 AI 管理(AIMS) Annex A 共 38 AI-specific controls,9 control objectives,Clauses 4-10 結構
    ISO 27701 個資管理(PIMS) 針對 GDPR / 個資法,腦子系統的脫敏管道對應這個

    2.2 雙標準的重疊與互補

    • ~40% 重疊:Annex A 的 Clauses 4-10 結構大部分一致(Context / Leadership / Planning / Support / Operation / Performance / Improvement),已 27001 認證可快 30-40% 取得 42001([來源])
    • 60% AI-specific:42001 的 Clause 8(Operation)幾乎沒重疊 — AI Risk Treatment / AI System Impact Assessment / AI System Lifecycle / Data Management 都是 27001 沒有的
    • 同樣 3 年認證週期,可整合 audit 降低 disruption

    實務建議:先 27001 → 再加 42001。如果並行做,跟同一個認證機構(Schellman / TÜV SÜD / BSI / DNV)約整合稽核,證據文件大量 reuse。

    三、六篇文章 × ISO 控制項映射

    每一篇對應到具體 ISO 控制項。標 ✅ 是文章已涵蓋,標 ⚠️ 是 gap 需要補。

    3.1 ISO 27001:2022 Annex A 對應

    Control 名稱 對應篇 狀態
    A.5.10 Acceptable use of information 第 1 篇 Iron Rules ✅
    A.5.12 / A.5.13 Classification / Labelling of information 第 1 篇 A/B/C 分級 ✅
    A.5.19-21 Supplier relationship 第 4 篇 OpenClaw 教訓 ✅
    A.5.34 PII protection 第 2 篇脫敏 pipeline ✅
    A.6.3 Awareness, education, training 第 1 篇 Layer 3 規則+教育 ✅
    A.8.3 Information access restriction 第 5 篇 iDempiere AD_Role ✅
    A.8.15 Logging 第 2 篇 Gateway audit log ✅
    A.8.20-23 Networks security / Web filtering 第 1 篇 Gateway 流量管制 ✅
    A.8.28 Secure coding 第 6 篇 LLM 產 HTML 安全規範 ⚠️ 部分
    A.8.32 Change management 第 2 篇 git PR review ✅
    A.5.7 Threat intelligence 未涵蓋 ⚠️ Gap
    A.5.30 ICT readiness for business continuity 未涵蓋 ⚠️ Gap
    A.7.x Physical controls(機房 / 進出管制) 未涵蓋 ⚠️ 範圍外

    3.2 ISO 42001:2023 Annex A 對應(關鍵 9 個 control objectives)

    42001 Annex A 範疇 對應篇 狀態
    AI 政策(AI Policy) 第 1 篇 Iron Rules + 第 2 篇 Working Group ✅
    AI 風險評估(AI Risk Assessment) 第 2 篇分級表 + 第 4 篇 OpenClaw 廠商風險 ✅
    AI 系統影響評估(AI Impact Assessment) 第 2 篇 Working Group 跨部門 ✅
    AI 系統生命週期(AI System Lifecycle) 第 2 篇 Phase 0-5 + 第 4 篇 Harness 修改 ✅
    資料治理(Data Management) 第 5 篇 iDempiere AD_Role + 分級表 ✅
    透明度與可解釋(Transparency) 第 4 篇三層漏斗(規則優先,LLM 兜底) ✅
    第三方關係(Third-party relationships) 第 4 篇 Enterprise 合約 + DPA ✅
    監控與量測(Monitoring & Measurement) 第 2 篇 KPI Dashboard ✅
    人為監督(Human Oversight) 第 2 篇 Curator + 第 6 篇預設 read-only ✅
    偏見緩解(Bias Mitigation) 未明確涵蓋 ⚠️ Gap
    事故管理(AI Incident Management) 部分(audit log 可追,但無 SOP) ⚠️ 部分

    四、Gap 補強方案

    對應前面標 ⚠️ 的條款,給每個 gap 具體補強做法:

    4.1 A.5.7 Threat intelligence

    • 定期收集 LLM 廠商安全公告(Anthropic / OpenAI / Microsoft 等)
    • 訂閱 prompt injection / jailbreak / model 漏洞情報源(OWASP Top 10 for LLM Applications)
    • 每季 working group 會議納入「AI 威脅情報」議程,新威脅進腦子的 brain markdown

    4.2 A.5.30 ICT readiness for business continuity

    • Gateway 高可用(HA)+ 失效時的降級策略(本地 LLM 接管)
    • 本地 Ollama 機器是 backup endpoint(雲端 frontier 掛時切回來)
    • BCM 演練每年 1 次:模擬 Anthropic API 全面斷掉,測員工是否能繼續工作

    4.3 A.8.28 Secure coding(LLM 產 HTML)

    • 第 6 篇講的「textContent 不用 innerHTML」、「不用 eval」是 prompt 規範,但需要 server side 驗證
    • Gateway 端加 HTML scanner:用 ESLint security rules 或 OWASP HTML Sanitizer 掃 LLM 產的 HTML
    • 不通過 scanner 的 HTML 不出 Gateway,改要員工重新 prompt

    4.4 ISO 42001 偏見緩解(Bias Mitigation)

    • 定期測試 LLM 對特定 prompt 的回應差異(性別、年齡、地區)
    • 建立 baseline test set:每季用同一組 prompt 測各廠 LLM,看 bias drift
    • Working Group 評估該 bias 是否影響業務,進腦子 brain markdown 註明

    4.5 AI 事故管理(Incident Management)

    • 定義「AI 事故」:LLM 產生危害內容、員工誤洩 A 級資料、Gateway 規則失效、模型 hallucination 造成業務錯誤等
    • SOP:發現 → 通報 CISO → audit log 凍結 → 影響評估 → 補救 → 事後檢討進 brain
    • 每年至少 1 次 incident 演練(tabletop exercise)

    五、鄉村包圍踏實落地的 5 個 Phase Gate

    第三篇講了大方向。本節補上「每個 Phase 過渡前的硬條件」,沒過 Gate 不要硬上下一階段。每個 Gate 同時對應 ISO 稽核里程碑。

    Gate 時機 硬條件 ISO 對應
    G0 啟動 M1 W1 CIO 簽核 3 條集團 Iron Rules + 任命準 CISO 42001 Clause 5 Leadership commitment
    G1 種子 M2 結束 至少 2 個 BU 各有 5 人在用、無重大 Iron Rules 違反事件 27001 A.6.3 Awareness 已生效
    G2 根據地 M4 結束 至少 2 BU 完成雙 Repo + 分級表 v0.1 + 脫敏字典 + Pre-commit hook 27001 A.5.12-13 + 42001 Data Management
    G3 包圍 M6 結束 Working Group v1 集團 CLAUDE.md + 集團分級表 + 三場核心會議全 done 42001 Clause 6 Planning + AI Policy 落地
    G4 進城 M9 結束 Gateway 上線、雙引擎接入、KPI Dashboard 跑、北極星比例 > 70% 27001 A.8.x + 42001 Clause 8 Operation
    G5 稽核就緒 M12 內部稽核完成、gap 補完、外部稽核機構 walk-through 通過 兩標準 stage 1 audit 通過

    5.1 過 Gate 的紀律

    • G1-G2 沒過,不要進 G3 包圍:沒實戰數據的 Working Group 會回到「法務全判 A 級」失敗模式
    • G3 沒過,不要急著裝 Gateway:沒分級表的 Gateway 是裝飾,只浪費 RD 時間
    • G4 沒過,不要排稽核:北極星 < 70% 表示員工沒採用,稽核員問「實際運作」會答不出來

    六、多場景統一治理框架

    6.1 五個共用元件(全公司一套)

    元件 角色 維護方
    LLM Gateway 所有 AI 流量必經(LLM call + ERP query) 中央 RD + IT
    分級對應表 A/B/C 級資料定義 Working Group 月度 patch
    Audit Log 全程紀錄(誰、何時、查什麼) 中央 SIEM
    Curator 制度 brain 品質把關 + 過時知識淘汰 每 BU 一名
    KPI Dashboard 月度健檢 + 北極星追蹤 中央 RD

    6.2 五種角色 × 四類工具的整合矩陣

    角色 \ 工具 Coding Agent Chat-native Bridge Self-Service HTML
    RD ✅ 主要 輔助 ✅ 出差/移動 輔助
    銷售 不適用 ✅ 主要 不適用 ✅ 主要
    客服 不適用 ✅ 主要 不適用 ✅ 主要
    採購 不適用 ✅ 主要 不適用 ✅ 主要
    管理層 不適用 輔助 不適用 ✅ 主要(儀表板)

    關鍵:不同角色用不同工具,但全部走同一個 Gateway。Gateway 那層的分級 / 脫敏 / audit / 路由規則,所有工具共用。

    6.3 確保「正確 / 安全 / 合規 / 整合」的四個機制

    • 正確:資料不來自 LLM 幻覺,而是來自 ERP via MCP/Gateway。LLM 只是把 ERP 資料整理 + 渲染,不產生資料
    • 安全:三層縱深 — 員工身分(SSO)、Gateway 規則(分級脫敏)、ERP 角色(AD_Role)
    • 合規:每個元件都對應 ISO 控制項,稽核證據自動 export
    • 整合:Single Source of Truth — 不同部門看到的資料一致(因為都來自同一個 ERP)、不同 AI 工具產的回應背後是同一個 Gateway

    七、月度健檢:踏實的可量測指標

    7.1 北極星(唯一最重要)

    本月 Gateway request 數 ÷ (Gateway + 偵測到的網頁版 LLM 流量)
目標: 90%+
< 70% = 拉力策略失敗,要查為什麼員工繞過

    7.2 三個關鍵健檢指標

    指標 定義 目標 頻率
    覆蓋率 月活使用 Gateway 員工 / 全公司 80%+ 月
    合規 gap 減少率 本季新發現 gap 數 vs 已修復 gap 數 修復 ≥ 新增 季
    稽核就緒度 90% 證據可從系統自動 export M9 後達標 季

    7.3 月度報告(高層用)

    不要丟一堆數字給高層,只回答三個問題:

    1. 「上個月 X% 員工選擇 Gateway over 網頁版」← 北極星
    2. 「員工繞過 Gateway 的 Top 3 原因」← 下個月修哪邊
    3. 「ISO 稽核就緒度 + 安全收益 + 雲端費用」← 投資回報

    八、稽核準備 90% 自動化

    傳統公司 ISO 稽核要花 1-2 個月補資料、做文件、開會。腦子系統的設計讓大部分證據自動產出:

    稽核需要的證據 來源 準備時間
    AI 政策文件 + 變更歷史 company-brain git log 0(隨時可拉)
    分級表執行紀錄 Gateway audit log 0(已存在)
    脫敏執行實證 Gateway pipeline log 0(已存在)
    員工訓練紀錄 HR 既有訓練系統 既有資料
    第三方供應商 DPA 合約管理系統 既有資料
    KPI 持續監控 Dashboard 0(自動產生)
    變更管理 git PR 紀錄 0(已存在)
    事故管理 SIEM ticket 系統 既有系統
    人為監督 Curator 月度 review log 0(已存在)

    結果:RD 投入稽核準備時間從 1-2 個月降到 1-2 週。準備重點變成「整理 + 解釋」,而不是「補資料」。

    九、12 個月時程(對應第三篇 + 本文)

    月 關鍵交付 Gate
    M1 Iron Rules 三條 + 準 CISO 任命 + 種子 BU 招募 G0
    M2 2 BU 種子員工開始用 AI G1
    M3-M4 BU 各自雙 Repo + 分級表 v0.1 + 脫敏字典 G2
    M5-M6 Working Group 三場核心會議 + 集團 v1 G3
    M7-M9 Gateway 上線 + 雙引擎 + Self-service HTML + iDempiere MCP G4
    M10-M11 Gap 補強 + 內部稽核 + 外部顧問 walk-through —
    M12 ISO 27001 + 42001 stage 1 audit G5

    對 80 人公司:可加速到 6-9 個月。對萬人集團:可能延長到 18 個月,但鄉村包圍策略讓每個 BU 看到自己的進度,而不是等全集團一起。

    十、結語:從 6 篇到 1 個治理框架

    前六篇是分散的拼圖:Why / How / Scale / Tools / ERP / Self-Service。本篇把它們收成一個整體。

    「合不合 ISO」答案是:大部分天然合,有 5 個 gap 要補強。「鄉村包圍怎麼踏實做完」答案是:5 個 Phase Gate + 月度健檢 + 北極星 KPI。「多場景多用戶多工具怎麼統一」答案是:5 個共用元件 + 角色×工具矩陣。

    真正讓系統「正確、安全、合規、整合」的不是任何一個元件,是所有元件都會合在 Gateway 那一層:那是員工、AI、ERP、稽核員看的同一個交集點。設計對了,後面都對。

    對企業 IT 主管的最後一個具體下一步:

    1. 把本文的 ISO 控制項對應表存成 git repo 一份檔,作為日後稽核 SoA(Statement of Applicability)的基礎
    2. 下一次 working group 會議,把本文的 5 個 Phase Gate 排進共享日曆
    3. 稽核機構初步接洽:Schellman / TÜV SÜD / BSI / DNV 任選一家,問整合 27001 + 42001 報價
    4. 北極星 KPI 上 dashboard,讓員工看得到(透明度本身是 ISO 42001 的要求)

    延伸閱讀:腦子系統七篇

    可運作的 Reference Links(2026/5 撰文時驗證)

    ISO 標準官方

    Annex A 控制項對照(實作指南)

    業界實戰

    OWASP Top 10 for LLM(對應 A.5.7 Threat Intelligence)

  • Chat-native AI Agent + Harness 設計 + OpenClaw 事件:腦子系統工具中性化

    重點摘要(TL;DR)

    • AI 工具有三類完全不同定位:Coding Agent(Claude Code / OpenCode)、Chat-native General-purpose Agent(OpenClaw / QwenPaw / Nanobot)、Bridge(ccbot / 官方 Channels)。前一版混淆了,本篇修正。
    • OpenClaw 事件(2026/4/4):Anthropic 撤銷 OAuth、訂閱費不再支援第三方工具。對企業最重要的教訓:永遠用 API key 走 Enterprise 合約,不要把員工個人訂閱當公司基建。
    • OpenClaw 替代品光譜:QwenPaw(對企業 air-gapped 最優)、Nanobot(輕量)、PraisonAI(low-code multi-agent)、Hermes / grip-ai / Chatbox / Enclave AI 等。
    • Harness 設計(Anthropic 2026/3 三 agent 方法論):Simplicity First / Strip away non-load-bearing / Evaluator 看任務難度。模型升級時主動砍腳手架。
    • 企業整合三版本:A(Claude Code + 官方 Channel)、B(Claude Code + ccbot + Gateway)、C(QwenPaw + Ollama + Gateway 完全 air-gapped)。可同時並存於同一集團不同 BU。
    • 本文是腦子系統四部曲第四篇(Tools 工具中性化),前三篇:Why / How / Scale。

    一、修正前篇:三類工具的真實定位

    本文重寫前一個版本,因為前版誤把 OpenClaw 當作 OpenCode 處理。實際上這兩個工具完全不同類,分屬不同層的解決方案。整個生態系應該分成三類來看:

    類別 代表工具 主要任務 介面 目標用戶
    A. Coding Agent Claude Code、OpenCode、Cursor、Aider、Cline、Codex CLI 寫 code、debug、跨檔案 refactor Terminal / IDE RD / DevOps
    B. Chat-native General Agent OpenClaw、QwenPaw、Nanobot、PraisonAI、Hermes email / 行事曆 / 訂機票 / 表單填寫 / 一般行政自動化 原生支援多 chat app(WhatsApp/Telegram/Slack/Signal/iMessage) 全公司員工(含非 RD)
    C. Bridge / Channel ccbot、Anthropic 官方 Channels、CloudCLI 把 Coding Agent 延伸到行動端 Telegram / Discord / iMessage RD(出差/移動中)

    關鍵 insight:B 類(Chat-native)對「萬人集團 80% 不寫 code 的員工」覆蓋面最大 — 業務、客服、行政、HR 不需要 coding agent,他們要的是 email / 行事曆 / 訂機票 / 表單自動化,而且要從原本就在用的 chat app 直接呼叫。

    二、OpenClaw 事件:企業導入的重大警訊

    2.1 事件時間軸

    • 2025/11:作者 Peter Steinberger(奧地利開發者)發布 Clawdbot
    • 2026/2/14:作者宣布加入 OpenAI(這個時間點在後續事件中很微妙)
    • 2026/3:Clawdbot 改名 OpenClaw,支援 50+ integrations
    • 2026/4/4:Anthropic 正式撤銷第三方工具的 OAuth 存取,Claude Pro/Max 訂閱不再支援 OpenClaw 等工具(改算 extra usage)
    • 2026/4/10:Anthropic 短暫封鎖作者本人帳號,輿論發酵後恢復

    2.2 為什麼被封鎖

    Anthropic 的官方說法:違反 Consumer Terms of Service。

    • Claude.ai 訂閱(Pro / Max)是個人用 — 「for personal use through Anthropic’s own interfaces」
    • 不可 power programmatic workflows(自動化流程、批次處理)
    • OpenClaw 用 OAuth 把訂閱費當 API 用,實質是「訂閱價跑 API 等級流量」 — Anthropic 形同補貼
    • Anthropic 法務頁面明寫:「Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted」

    2.3 對企業的四個重大教訓

    1. 永遠用 API key,不要用個人訂閱 OAuth:員工說「我用我的 Claude Pro 帳號接公司工具」聽起來省錢,實際上隨時被切。企業 AI 基建只能架在 Enterprise 合約 + API key 之上。
    2. 「廠商封鎖風險」要納入工具選型:同一家廠商可能因為政策、競爭、法務等原因突然改規則。OpenClaw 的 50 倍成本上漲、不少 OpenAI 第三方工具被封鎖、API rate limit 突調 — 都是真實案例。不要把全公司流量壓在單一廠商。
    3. 本地模型 + 開源 chat-native agent 是唯一不被綁的路徑:OpenClaw + Anthropic 訂閱會被切,但 QwenPaw + Ollama + Qwen3-Coder-Next 完全自主,沒有任何第三方可以動你的服務。對 A 級資料 BU 是必選。
    4. 合約條款要求「廠商如改政策提前 90 天通知」:Enterprise 合約 negotiate 時,把「policy stability」寫進去。Anthropic 對個人訂閱可以說改就改,但對 Enterprise 客戶通常得提前通知 — 這個條款要爭取。

    三、OpenClaw 替代工具完整地圖

    OpenClaw 事件後,生態系冒出大量替代品。按企業適用場景分:

    3.1 對企業 air-gapped BU 最理想:QwenPaw

    • 來源:agentscope-ai 開源(原名 CoPaw,2026 改名 QwenPaw 強調 Qwen 生態整合)
    • 特色:本地模型優先(Qwen3-Coder-Next、Qwen3.6 等)+ 多 chat app 介面(DingTalk / Feishu / WeChat / Discord / Telegram)
    • 對台灣企業:中文 chat app 支援度最高,適合製造業 / 集團內部
    • 適合:萬人集團 A 級 BU、要完全 air-gapped、製造業 BOM / 財務 / HR

    3.2 輕量化:Nanobot

    • 來源:香港大學,4,000 行 Python(對比 OpenClaw 的 430K 行)
    • 支援:Telegram / Discord / WhatsApp / Slack / Email out of the box
    • 適合:小團隊、想完全掌控代碼、不需要 50+ integrations 的企業

    3.3 多 agent 編排:PraisonAI

    • 特色:low-code 多 agent 平台,100+ LLM 支援,內建 handoffs / guardrails / memory / RAG
    • 支援:Telegram / Discord / WhatsApp
    • 適合:需要 Anthropic 三 agent harness 設計、但不想自己從頭寫的企業

    3.4 其他主流選項

    工具 特色 適合
    Hermes Agent self-improving 學習迴圈,從複雜任務生 skill 文件 需要長期累積能力的場景
    grip-ai Claude Agent SDK based,31 tools,826 tests 仍想用 Anthropic 但要可控的開發者
    NanoClaw 5 個檔案 vs 430K 行,Linux 容器隔離,WhatsApp focus 資安要求高、要細粒度隔離
    Chatbox 統一介面接 ChatGPT / Claude / Gemini / Ollama 員工想跨多家 LLM 的桌面用戶
    Enclave AI iPhone / Mac 完全本地,語音對話 A 級資料行動端、無雲依賴
    OpenJarvis Ollama / vLLM / SGLang / llama.cpp 整合,有 learning loop 已有本地推理基建的企業
    Moltworker Cloudflare 推出的 self-hosted personal agent 已用 Cloudflare 生態的企業

    四、Harness 設計方法論

    「Harness」(腳手架)是 Anthropic 2026 提出的核心工程概念,指 AI agent 周邊的所有非模型組件:system prompt、memory 機制、tool 定義、context 管理、agent 多步循環、評估迴圈。Anthropic 在 Harness design for long-running application development(2026/3)正式發表了完整方法論。

    4.1 Anthropic 三 agent harness

    Agent 角色 職責 Handoff 產出
    Planner 把模糊的初始 prompt 展開成詳細規格 feature 清單(Anthropic 範例 200+ 條)
    Generator 執行核心工作、實作功能、自我評估進度 code + progress tracking artifact
    Evaluator / QA 用具體 criteria 獨立評估,抓 generator 漏掉的 gap 合格/不合格 + 具體缺漏清單

    三 agent 分離的目的:解決長時間任務的 context overflow。一個 agent 跑 8 小時 context 會爆,三個 agent 用 structured handoff artifact 傳遞狀態,每個 agent 自己 context 重置 — 這就是 Anthropic 講的「maintain coherence across multiple context windows」。

    4.2 公司腦子系統如何映射到 Harness

    Anthropic Harness 元件 公司腦子系統對應 維護方
    System Prompt global/CLAUDE.md(Iron Rules) Working Group
    Memory(persistent) 公司腦 brain markdown + 個人腦 Curator + 員工自己
    Tools / MCP servers Skills(可重用能力包)+ 內部 RAG RD + 部門 Curator
    Context 管理 build.sh 編譯時依目標 model 過濾 RD
    Evaluator agent Curator 月度 review + KPI Dashboard + ISO 稽核 準 CISO + Curator

    4.3 修改 Harness 的三條原則

    1. Simplicity First:找最簡解,需要才增加複雜度。每個 harness 元件都 encode 了一個假設「模型自己做不到 X」 — 這些假設要定期 stress-test。
    2. Strip away non-load-bearing pieces:模型升級時(Opus 4.5 → 4.6 → 4.7),原本必要的腳手架可能變成包袱。Anthropic 觀察 Opus 4.6 比 4.5 需要更少腳手架 — 模型越強,harness 越輕。
    3. Evaluator 看任務難度:「worth the cost when the task sits beyond what the current model does reliably solo」。簡單 CRUD 不需要 evaluator;跨檔案 refactor 才需要。不為對稱加 evaluator,只在它真的攔到問題時保留。

    五、行動端通訊三種模式(正確分類)

    模式 對應 機制 適合場景
    A. Coding Agent + 官方 Channel Claude Code + 官方 Channels(2026/3/20) Anthropic 官方 MCP server,連 Telegram/Discord/iMessage 純 Claude Code 用戶、簡單設定
    B. Coding Agent + Bridge Claude Code / OpenCode + ccbot(tmux 之上) tmux thin layer,讀 pane output、送 keystrokes RD 想多 session 平行、跨 coding agent
    C. Chat-native Agent(Native) QwenPaw / Nanobot / OpenClaw 等 自帶 agent + 自帶多 chat app,本機跑 全公司員工(含非 RD),日常自動化

    關鍵差別:

    • A 和 B 後面接 Coding Agent(只做 coding 任務的延伸)
    • C 本身就是 Agent(做廣義自動化:email、行事曆、表單、訂機票)
    • 覆蓋面:A、B 給 RD;C 給全員

    5.1 ccbot 機制深入(B 模式代表)

    ccbot 是 B 模式主流。技術核心:tmux 之上的 thin control layer,不是 SDK wrapper。

    • Claude Code 進程原封不動跑在桌機 tmux window
    • ccbot 監聽 JSONL 轉錄檔(每 2 秒 polling)
    • Telegram 訊息 → 送 keystrokes 到 tmux pane
    • terminal output → ccbot 解析後 forward 回 Telegram
    • 1 Telegram topic = 1 tmux window = 1 Claude session

    適配到其他 coding agent(OpenCode / Aider / Cline)需要 fork ccbot 改 transcript parser,核心架構不變,1-2 週可做出 v0。

    六、企業整合架構:三種模式 × Gateway

    6.1 完整流量路徑

    員工手機 (WhatsApp / Telegram / Slack / Signal)
    ↓ chat message
┌────────────── 三種入口都進這層 ──────────────┐
│  A: Coding Agent + 官方 Channel              │
│  B: Coding Agent + ccbot Bridge              │
│  C: Chat-native Agent (QwenPaw 等)           │
└────────────────────────────────────────────┘
    ↓ HTTP request 經 BASE_URL 改寫 (關鍵!)
公司 LLM Gateway (LiteLLM + Portkey)
    ├─ Layer 1 regex 脫敏 / 分級
    ├─ Layer 2 小模型 fail-safe
    ├─ 路由 + audit log
    └─ ↓               ↓
       雲端 frontier   本地 Ollama
       (B/C 級,API key) (A 級)

    三種模式的共同點:都要把 endpoint 指向公司 Gateway,讓分級 / 脫敏 / audit 都生效。不可以讓員工的 Chat-native Agent 直接連 Anthropic / OpenAI 的 API,即使是 Enterprise 合約也不該繞過 Gateway。

    6.2 安全考量(必看)

    • 訊息 channel 也要分級:Telegram / Discord / WhatsApp 訊息會經過第三方伺服器 → 即使 Gateway 端脫敏,訊息已經先到第三方。建議:
      • Slack(enterprise)/ Mattermost(self-host)→ B/C 級可
      • Signal → B 邊界、C 級可
      • Telegram / Discord / WhatsApp → 僅 C 級
      • iMessage → 視所在地區法規(歐盟禁、台灣彈性)
      • A 級 BU(財務 / HR / BOM 配方 / 法務)禁止任何外部 chat channel,只能 Mattermost self-host
    • 身份驗證:Bridge / Chat-native Agent 必設 ALLOWED_USERS 白名單,綁員工 chat app 帳號;離職立即撤銷
    • 不要用個人訂閱 OAuth:OpenClaw 事件的核心教訓 — 員工說「我用我的 Claude Pro 接公司工具」聽起來省錢,實際上隨時被切;公司基建只能架在 API key + Enterprise 合約

    七、企業導入的三個版本

    A 基礎版:Claude Code + 官方 Channels

    • 適合:80 人以下、已用 Claude Code、員工以 RD 為主
    • 成本:Anthropic Enterprise 合約 + 官方 Channels 免費
    • 工程量:1 人 1 週設定完成
    • 限制:覆蓋率低(只給寫 code 的人)、A 級資料無法處理

    B 開源版:Claude Code + ccbot + 公司 Gateway

    • 適合:80-1000 人、有 RD 維護能力、想多 session 平行
    • 成本:Anthropic Enterprise + ccbot 自架 + 公司 Gateway
    • 工程量:1.5 RD x 2-3 個月
    • 限制:仍綁 Anthropic、覆蓋率仍偏 RD、A 級資料要走 Mattermost self-host

    C 完全本地版:QwenPaw + Ollama + 公司 Gateway ⭐

    • 適合:萬人集團、製造 / 金融 / 國防 / 醫療,有 air-gapped 法規要求
    • 成本:QwenPaw 免費 + GPU 機房(中央 1x H100 + 多台 4090)+ Mattermost self-host + 公司 Gateway
    • 工程量:2-3 RD x 4-6 個月
    • 優勢:
      • 整套 air-gapped,A 級資料完全可處理
      • 不被任何雲端 LLM 廠商鎖死(OpenClaw 事件不會發生在你身上)
      • 覆蓋全公司員工(含 80% 不寫 code 的人)
      • 支援中文 chat app(QwenPaw 原生支援 DingTalk / Feishu / WeChat)

    三個版本可以同時並存於同一集團:RD BU 用 B 版(Claude Code + ccbot)做 coding;業務 / 客服 / 行政用 C 版(QwenPaw)做日常自動化;管理層內部工具用 A 版(官方 Channels)。不同 BU 不同需求,Gateway 是唯一共用層。

    八、結語:工具中性化 + 廠商獨立

    不應該把員工綁在某個 AI 工具的某個 UI 上,也不應該把公司基建綁在某家廠商的政策善意上。

    讓員工選工具(Claude Code / OpenCode / QwenPaw / OpenClaw),選位置(桌機 / 手機 / 平板),選通訊頻道(Telegram / Discord / Signal / Slack / WhatsApp / Mattermost)。公司只負責 Gateway 那層的腦子注入和分級路由。

    OpenClaw 事件提醒我們:廠商可以在任何時間用任何理由改規則。本地模型 + 開源工具 + 自有 Gateway 是唯一不會被切的路徑。Bridge 和 Gateway 正交組合,工具汰換不影響腦子系統 — 這才是真正的工具中性化。

    同樣道理:模型升級時,Anthropic 教我們「strip away non-load-bearing pieces」。腦子系統的每季健檢就是這個原則的應用。Harness 不是寫一次就完的,是隨模型演化、隨廠商政策變動而調整的活系統。

    延伸閱讀

    2026/5 工具與事件參考

  • 萬人跨國集團如何導入AI腦子系統:農村包圍城市策略

    重點摘要(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(全員適用)

    1. BOM 配方、製程參數、合金成分比例
      → 禁止送任何雲端 LLM,僅可使用公司核准的本地 AI 工具
    2. 未公告財報數字(月報、季預估、年度計畫)
      → 禁止送任何 AI 工具(含本地)。違反視同內線交易風險處理
    3. 客戶合約原文、訂單金額、供應商報價
      → 禁止送雲端 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 步都會跟著動起來。

    延伸閱讀