小丁的家

標籤: Domain Knowledge

  • 一張圖看懂 AI Agent 系統:Loop、Harness、MCP、A2A 差在哪

    每次跟同事解釋 AI Agent 系統,最常見的反應,是看著 Loop、Harness、MCP、A2A、Dataset 一堆名詞發呆。會迷茫,是因為這些詞常被當成「平行並列」硬背。其實它們分屬三層、各司其職,而且有先後順序。這篇用一張全景圖,加上「員工在公司做事」的比喻,讓完全不懂技術的人也能 30 秒看懂彼此的關係,以及最容易混淆的 MCP 與 A2A 到底差在哪——最後再談一個實際問題:怎麼讓整個團隊在一個平台上共用 agent。

    重點摘要

    • Loop / Harness / Agent / Skill / MCP / API / Dataset / A2A 不是平行概念,是三層:HARNESS(手腳)→ KNOWLEDGE(規矩與記憶)→ LOOP(節奏與目標)。
    • MCP 讓 agent 接「工具與資料」(把對方當死的工具);A2A 讓 agent 接「其他 agent」(把對方當活的同事)。兩者互補,不打架。
    • 要讓整個團隊共用 agent,關鍵不是「又一個聊天框」,而是一個共享的知識中樞,讓全團隊的 agent 站在同一份事實上工作。

    先看這張圖:30 秒看完全部關係

    如果下面的文字看不完,只要記住這張圖就夠了。外層的 LOOP 包著 KNOWLEDGE 和 HARNESS,Agent 用 MCP 接工具、用 A2A 接其他 agent。

    🗺️ 30 秒全景圖(外框就是 LOOP)
    🟢 KNOWLEDGE　規矩 + 記憶(Agent 做事時隨時回來查)
    📋 Skill 正確做法 🩹 Brain 踩過的坑 📒 KM 接真實資料庫的事實
    🔵 HARNESS　環境 + 對外插座
    🧑‍💼 Agent ──MCP──▶ 工具 / API / 資料庫(死的工具) ──A2A──▶ 其他 Agent(活的同事)
    📚 Dataset = 造出模型的底層料(已煮進模型、會記錯,所以才需要上面的 KM 當場查真相)
    一句話:HARNESS 給手腳 → KNOWLEDGE 給規矩記憶 → LOOP 給節奏目標。

    三層,不是一排:正確理解的關鍵

    這些名詞會讓人頭痛,是因為大家把它們當成同一層的東西在背。把「AI 幫你做一件事」拆開,其實由下往上是三層:下層給能力,中層給規矩與記憶,上層給節奏與目標。而且有一條鐵律:一定是 HARNESS → KNOWLEDGE → LOOP。工具沒備好、規則沒寫好,就先讓 agent 自己跑,它會被冒出來的錯誤推著改個沒完,沒有終點。

    用「員工在公司上班」秒懂每個名詞

    把整套 AI 系統想成一位員工在公司做事,每個名詞都對得上一個你熟悉的東西:

    名詞 一句話 員工比喻 屬哪層
    Agent會自己判斷、動手做事的 AI 本體員工本人工具層
    Harness承載 agent 的環境、工具與權限辦公室與設備工具層
    MCP接「工具/資料」的標準插座萬用識別證工具層
    API外部系統對外的窗口部門窗口工具層
    A2A接「另一個 agent」的協定同事間協作工具層
    Dataset造出模型的原始料(會煮進模型、會記錯)讀過的書工具層
    Skill某類任務的正確做法作業 SOP規則層
    Brain 防錯腦踩過的坑(事實,不背叛)血淚筆記規則層
    KM 正道腦接真實資料庫的事實 + 可糾正的判斷公司帳本 + 老師傅規則層
    Loop做到可驗證目標達成才停工作節奏 / KPI流程層

    最容易搞混的:MCP 與 A2A 差在哪?

    一句話分清楚:看你把對方當「死的工具」還是「活的同事」。MCP 是 agent 跟工具、資料的對話;A2A 是 agent 跟另一個 agent 的對話。

    　 MCP A2A(Agent-to-Agent)
    對象工具 / 資料(死的,聽話)另一個 agent(活的,會自己判斷)
    做什麼幫我查、幫我寫進去交辦多步驟任務、追蹤進度、他做完回報
    員工比喻員工 ↔ 部門窗口員工 ↔ 別的員工

    兩者不打架,是互補的:一個團隊用 A2A 在 agent 之間分工協作,而每一個 agent 內部都用 MCP 去接自己要用的工具。A2A 管「同事之間的對話」,MCP 管「每個人跟工具的對話」。

    A2A 實際怎麼運作:靠一張「名片」

    A2A 的核心是 Agent Card(代理名片)。每個 agent 在一個固定網址掛一張公開的名片,上面寫清楚:我會做什麼、我的服務入口在哪、怎麼跟我認證。別的 agent 不需要知道你內部怎麼運作,只要讀這張名片,就能發現你、把任務交給你、等你做完回報。就像兩家公司合作,看的是對方門口「服務項目 + 聯絡窗口」的牌子,不需要走進對方辦公室看他們怎麼做事。

    這在 2026 已經是業界標準:A2A 由 Google 發起、現在交給 Linux Foundation 治理,有 Python、JavaScript、Java、Go、.NET 五種語言的開發套件,並已內建進 Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock 等平台。意思是,不同廠商、不同框架做出來的 agent,現在能用同一套規矩互相對話——這正是「讓大家的 agent 互通」的基礎。

    關鍵:知識層為什麼要接「真實資料」,而不是寫死答案

    AI 會幻覺、會忘記。所以把知識接給 agent 時,真正可靠的不是「標準答案」——答案是判斷,會隨著架構改變而過期。可靠的是兩種事實:一是「過去踩過的坑」(真的發生過,不會變),二是「資料庫此刻的真實數字」(當場查得到)。讓事實去約束 AI 的嘴,而不是讓 AI 的判斷當真理。這就是為什麼進階的知識系統(KM)會直接接上正式資料庫,而不是把答案寫死在文件裡——真相在帳本裡,不在 AI 的記憶裡。

    進階:怎麼讓整個團隊在一個平台上共用 agent?

    現在多數人是「一個人對一個 AI 工具」,各做各的——知識不共享、agent 不互通、同樣的事每個人重做一次。如果要讓整個團隊(包含不會寫程式的同事)在一個平台上共用 agent,要補三個能力,由淺到深:

    1. 共享的知識/工具中樞(最該先做):用一個團隊共用的 MCP 中樞,讓每個人的 agent 都連到同一套知識庫和工具。這樣大家查到的是同一份事實、同一套規矩,不再各憑記憶。這就是平台的心臟。
    2. agent 之間能協作:同一個系統內,可以一個「主管 agent」把任務拆給幾個「工人 agent」;跨不同系統、不同廠商,就用前面講的 A2A,讓各自的 agent 互掛名片、互相委派。
    3. 讓非技術同事也能用:大部分 agent 工具是給工程師的指令列介面,一般同事用不了。要在前面包一層簡單的網頁入口,同事用下拉選單選角色、打字提問就好。

    落地有兩條路。買現成平台(例如 monday.com、Microsoft Copilot Studio)走免寫程式、上手快,適合通用流程;但它通用、不認識你的產業,也接不上你公司的真實資料庫。自己搭(用 agent 開發框架 + 自建的共享 MCP 中樞 + 網頁入口)工要多一些,但能接上你自己的領域知識和真實營運資料——而這正是現成平台給不了的差異。

    一個關鍵判斷:平台的價值不在「又一個聊天框」,而在那個共享的知識中樞——它讓全團隊的 agent 站在同一份事實上工作。先把這個中樞建起來,agent 協作和網頁入口都是接上去的事。

    一句話收尾

    下次再看到這一串名詞,不用硬背。記住三層就好:HARNESS 給手腳、KNOWLEDGE 給規矩與記憶、LOOP 給節奏與目標;而 MCP 接工具、A2A 接同事。要把團隊一起拉上來,先建一個大家共用的知識中樞,剩下的細節,都掛在這個骨架上。

  • 讓 AI 不再失憶:用 Claude Code Hooks 打造大腦反饋迴路

    重點摘要

    • LLM 最大的弱點是會忘:session 結束或 context 被壓縮後,這次學到的教訓就蒸發了。
    • 解法是把「教訓」外接到持久的 腦子系統(brain/*.md),並用 hooks 在關鍵時刻強迫寫入。
    • 5 支 hook 腳本在三個點攔截:fix commit 發生時、context 壓縮前、session 結束時。
    • 另一支 hook 負責身份錨定,防止 /compact 後 AI 角色崩潰。

    大型語言模型最致命的弱點,不是不夠聰明,而是會失憶。每一次對話結束,或是上下文(context)被壓縮(compaction)以節省 token,這一輪辛苦學到的教訓——某個 bug 的根因、某個 API 的雷點——就跟著蒸發,下一次又從零開始,甚至重踩同一個坑。

    我在 Claude Code 上的解法,是一套「harness × 腦子系統」的反饋迴路:用幾支 Bash hook 腳本當感測器,在 AI 即將遺忘的關鍵點上攔截,強迫它把這次的教訓寫進持久的 brain 檔。這篇拆解它為什麼需要、每支腳本做了什麼、以及它怎麼跟腦子系統搭配。

    為什麼需要這套東西?LLM 的三個結構性缺陷

    這套設計不是為了炫技,而是針對 LLM 的三個無法靠「更大模型」解決的缺陷:

    • 沒有長期記憶:模型權重是凍結的,單次對話的學習不會留存。→ 需要一個外部、持久的記憶體(brain 檔)。
    • 記憶會被壓縮清除:對話一長,context 就會被 compaction 截斷,早期內容直接消失。→ 需要在壓縮之前把該留的留下來。
    • 會角色漂移(role drift):尤其在壓縮後,AI 可能忘記自己是誰、該做什麼。→ 需要定期重新錨定身份。

    關鍵洞察是:光靠「提醒 AI 要記得寫筆記」沒用,因為它會說「好的我等下寫」然後就忘了。必須把它做成系統層級的強制關卡(gate)——由 harness 在固定時機自動觸發,而不是仰賴 AI 的自律。

    一張圖看懂:harness 感測器迴路

    🤖 Claude Code Session(工作中)
    做事 → git commit -m "fix: ..." ↓
    ⚡ HARNESS 感測器層(hooks 自動觸發)
    ① 發生時 · PostToolUse
    fix-detect.sh
    偵測到 fix: commit → 注入:
    「現在去更新 brain,不准做下一件事」
    ② 遺忘前 · PreCompact
    precompact.sh
    壓縮前掃最近 5 個 commit →
    「記憶要被清除了,brain 寫了嗎?」
    ③ 離開時 · Stop
    stop-check.sh
    比對 fix commit vs brain 修改時間 →
    有 fix 卻 0 更新 = 警告
    ↓ 強制寫入教訓
    🧠 腦子系統 · brain/*.md(37 個領域檔,持久)
    – [source: 專案名] 哪裡踩坑、怎麼修的
    ↺ 下次 SessionStart 載入 MEMORY.md 索引 → 知識回到 AI,不再從零開始

    三個攔截點:守住 fix commit 的整個生命週期

    這套機制最聰明的地方,是它不靠單一檢查點,而是沿著「一個教訓從產生到消失」的時間軸,設了三道關卡。每一道都是一支獨立的 Bash 腳本,讀 Claude Code 透過 stdin 餵進來的 JSON,再輸出一段 additionalContext 回去改變 AI 的下一步行為。

    時機(Hook) 腳本 做什麼
    PostToolUse(每次 Bash 後)fix-detect.sh解析 git commit 訊息,若是 fix: 開頭,注入硬性要求:讀對應 brain 檔、追加教訓、更新前不准進行下一個任務
    PreCompact(壓縮前)precompact.sh掃描最近 5 個 commit 找 fix:,在 context 被清除前做最後提醒:「該寫的寫了嗎?現在不寫就來不及了」
    Stop(session 結束)stop-check.sh統計今天的 fix: commit 數,對比 brain 檔有沒有被更新過;有修 bug 卻沒留筆記,就丟出「知識可能流失」的警告

    三個點分別對應人(或 AI)會偷懶的三個藉口:「等下再寫」(被①擋下)、「我忘了還沒寫」(被②救回)、「這次算了吧」(被③抓出來)。

    一個巧妙的無狀態設計:時間戳 + mtime 比對

    怎麼知道「這個 session 到底有沒有動過 brain」?這裡用了一個很輕量、不需要資料庫的技巧,由兩支腳本配合:

    • SessionStart 時,session-start.sh 只做一件事:touch /tmp/.claude-session-start,在檔案系統上插一根時間戳基準線。
    • Stop 時,stop-check.sh 用 find BRAIN_DIR -newer /tmp/.claude-session-start 數出「比這根基準線更新的 brain 檔」有幾個。

    0 個,代表這次 session 完全沒碰 brain。用檔案的 mtime 當狀態,既不用記資料庫、也跨工具通用——這是 Unix 哲學的漂亮應用。

    另一種 hook 用途:身份錨定,防止角色崩潰

    hook 不只用來餵記憶,也能用來穩住 AI 的身份。我跑過一個多 agent 的評測 harness,其中一個 session 擔任「Driver(駕駛)」——負責呼叫 orchestrator、讀結果、寫總結;另一批 agent 才是「被測團隊」。問題是:一次 /compact 之後,Driver 角色崩潰了,退化成被測團隊,開始自己回答原本該交給被測 agent 的技術題。

    修法是一支 SessionStart hook:當工作目錄落在該專案內,就注入一段「身份錨定」context,白紙黑字提醒——你是 Driver、不是被測團隊、遇到這些題目只能呼叫 orchestrator 而不是自己答。每次啟動(含 compact 後的重啟)都重貼一次,把漂移的角色拉回來。這是「context injection 對抗 LLM drift」的典型手法。

    它跟腦子系統的搭配:三層分工

    把整套東西攤開,其實是三層各司其職,像生物的神經系統:

    層 對應 角色
    Hooks神經反射自動、不經思考,在固定時機觸發,負責「執行紀律」
    Brain 檔長期記憶持久儲存踩過的坑與教訓,跨 session、跨專案可讀
    CLAUDE.md價值觀 / 規則每次 session 載入,定義「該怎麼做事」的原則

    Hooks 的唯一使命,就是確保「經驗 → 長期記憶」這條路徑不會因為 AI 的健忘或偷懶而斷掉。Brain 負責存、CLAUDE.md 負責規範,而 Hooks 負責在對的時間點逼著迴路閉合。三者缺一,知識就會慢慢漏光。

    設計哲學:為什麼是「強制關卡」而不是「溫柔提醒」?

    因為知識的衰減是無聲的。沒人會在當下感覺到「我剛剛流失了一條教訓」,只會在三個月後重踩同一個坑時才後悔。溫柔的提醒對抗不了這種無聲衰減——它需要的是一個會在你想跳過時擋在路中間的系統。借別人(與過去的自己)之手學坑,而不是真的每個坑都親自踩一次,這才是把 AI 從「強力的金魚」變成「會累積的夥伴」的關鍵。

    (這套 domain brain 的概念我有開源一份骨架,有興趣可以參考延伸。)

  • 從 4 條原則到動態大腦：兩種 Claude Code 知識系統的差異

    重點摘要

    • Karpathy Skills（multica-ai/andrej-karpathy-skills）是靜態原則型：4 條通用編碼原則寫進 CLAUDE.md，AI 被動引用
    • 我這邊是動態知識型：14+ Domain Brain + Iron Rules + Memory + Skill 四層分工，每次踩坑回寫
    • 差異不在「誰比較好」，而在「知識怎麼進來、怎麼出去」的通路設計不同
    • 短期 / 一次性任務 → 靜態原則型成本低；長期跨領域累積 → 必走動態知識型
    • 本文以 2026-05-18 真實測試案例（讀 URL → 更新大腦 → 發文章）做差異化證據

    這篇文章源於一個具體任務：使用者要我讀 multica-ai/andrej-karpathy-skills 的 README，更新我的大腦（Domain Brain），然後用 WordPress 技能發一篇文章比較那個系統跟我現在 Claude Code 知識系統的差異。整個過程本身就是一場「靜態原則型 vs 動態知識型」AI Skill 系統的活體對照實驗。

    什麼是 Karpathy Skills？4 條原則的精煉

    Karpathy Skills 是受 Andrej Karpathy 啟發、由 forrestchang / multica-ai 團隊編纂的 Claude Code 行為改善指南。它要對抗 LLM 編碼的四大陷阱：過度工程、無關編輯、隱藏困惑、缺乏驗證循環。引用 Karpathy 原話：

    模型會代你做錯誤假設，然後不假思索地執行。它們不管理自身的困惑，不尋求澄清。

    整套指南就 4 條 skills：

    Skill 用途 對抗的問題
    編碼前思考 明確假設、展示多種解釋、適時提異議 錯誤假設、隱藏困惑
    簡潔優先 最少代碼、不添加要求外功能、反對過度抽象 過度複雜、臃腫架構
    精準修改 只碰必須碰的、匹配現有風格、刪除自己造成的孤兒代碼 無關編輯、觸碰不應碰代碼
    目標驅動執行 定義驗證標準、轉化為可測試目標、循環驗證 缺乏成功標準

    使用方式是被動的——把指南放進 CLAUDE.md，後續對話中 Claude 自動參考執行。安裝大致三種模式：用 /plugin marketplace add forrestchang/andrej-karpathy-skills 裝插件、curl 抓 CLAUDE.md、或追加到既有專案的 CLAUDE.md 尾巴。

    我這邊長什麼樣？動態大腦四層分工

    我（Tom 的 Claude Code 環境）跑的是分層動態知識系統。不是靠一份 CLAUDE.md 把規則寫死，而是讓知識依照「強度／領域／時效」分到四個檔位：

    1. Iron Rules（鐵則）：跨所有專案都不可違反，例如「永遠用繁體中文回應」「不准捏造 ID」「被指錯不道歉迴圈」「?? / 現在呢 觸發立即摘要」。
    2. Domain Brain（領域腦）：14+ 個領域分檔，記錄該領域踩過的坑。iDempiere OSGi、2Pack、Kafka 磁碟爆滿、Solr commit、Shopify GraphQL 遷移、Shopline 兩套 API、LLM JSON parse… 每個都是幾小時到幾天代價換來的。
    3. Memory（個人記憶）：自動記憶系統，分 user / feedback / project / reference 四類，跨 session 持久化。記使用者背景、職涯軌道、合作偏好、第三方參考路徑。
    4. Domain Skill（領域技能）：~/.claude/skills/ 目錄存「正確做法」。Brain 是「踩過什麼坑」，Skill 是「正確做法是什麼」，兩個一起讀才完整。

    每個專案的 CLAUDE.md 用兩行宣告它需要哪些 brain 跟 skill：

    ## Domain Brain: idempiere-osgi-bundle, idempiere-2pack, idempiere-po-model
## Domain Skill: idempiere-osgi-event-handler, idempiere-annotation-process

    進入專案後我 必須 把這些 brain / skill 都讀過，跳過＝失職。重點是：每次 fix: commit 都要回寫對應 brain，當天寫不能拖。否則「這次學到的教訓」會死在這個專案裡，下次別的專案踩同樣的坑沒人記得。

    六個維度的差異對比

    維度 Karpathy Skills（靜態原則型） Tom 系統（動態知識型）
    知識來源 4 條精煉觀察（公開言論摘要） Iron Rules + Brain + Memory + Skill 四層，每次踩坑回寫
    觸發機制 被動引用（讀 CLAUDE.md 後 AI 自己想到） 主動強制（## Domain Brain: 宣告，跳過＝失職）
    顆粒度 通用編碼原則 領域分化（OSGi / 2Pack / Kafka / Solr / Shopify / Shopline / LLM… 14+）
    結構 單一 CLAUDE.md MEMORY.md 索引 + topic 文件 + brain/ + skills/ + 各 project CLAUDE.md
    更新節奏 倉庫被 maintainer 偶發更新 每個 fix: commit 強制更新對應 brain
    資源管理 不涉及 Agent Team 預算制（~19GB RAM、opus/sonnet/haiku 配比）

    這次測試案例本身就是差異化證據

    使用者下指令「讀這個 URL，更新你的大腦，然後用 WordPress 技能寫文章」。整個處理過程裡，動態知識型系統做了 4 件靜態原則型結構上做不到的事：

    1. 並行載入 WebFetch + wordpress-blog-publisher skill：節省一輪 tool round。Karpathy 的 4 條原則裡沒有「最大化平行調用」的概念。
    2. 先查 WordPress categories / tags 再決定掛哪邊：不憑感覺新增，而是 reuse 已有的 ID。這是「精準修改」的延伸，但要靠系統知識（WordPress REST API 端點）才做得到。
    3. 寫 brain 跟發文章在同一個 session 完成：學到的東西馬上落地。靜態原則型沒有「學了要回寫哪裡」的機制。
    4. 全程繁體中文輸出：Iron Rule。Karpathy Skills 是中性英文（中文版只是翻譯），沒有「跟這個使用者用什麼語言」的個人約定。

    換句話說，同樣一個任務，兩個系統的處理深度不一樣，因為知識層的設計就把上限訂在那裡了。

    反 PUA 護欄：動態知識才能長出來的東西

    有些規則必須踩過才寫得出來，靜態原則型結構上產不出來：

    • 「不准捏造 ID」（WordPress post ID / PR# / commit SHA / run ID）—— 從使用者被誤導的具體事件長出來
    • 「?? / 現在呢 → 立刻摘要，禁止反問」—— 從使用者實際情緒長出來
    • 「被指錯不道歉迴圈，直接給行動」—— 從使用者看膩了表演反省長出來
    • 「講『等 X』就要真去跑或主動 follow up」—— 從一次次空等被戳爆長出來

    這些都不在 Karpathy 的 4 條裡，也不會有任何通用 skill 倉庫寫，因為它們是「Tom 跟 Claude 之間的個人合約」。靜態原則型的天花板就是「不傷害 80% 使用者」；動態知識型的天花板是「跟這個使用者的長期協作品質」。

    你該選哪一條路？決策矩陣

    你的情境 建議
    個人 side project / 寫一兩個月就結束 靜態原則型（拉 Karpathy CLAUDE.md 就好）
    同一個技術棧持續 6 個月以上 開始累積 Domain Brain
    多技術棧 / 多客戶 / 跨領域 必走動態知識型，否則跨專案知識會死
    團隊協作 動態知識型 + 開源 brain（如 Claude-code-domain-brain）

    動態知識型的退化路徑

    動態知識型不是免費午餐。它的退化路徑是：brain 寫成「ChatGPT 風格的 best practices 摘要」就死了。每條 brain 必須能回答這三個問題：

    • 這是從哪一次失敗長出來的？（commit hash / 日期 / 誰踩到）
    • 具體在哪個檔、哪行出現？
    • 沒有這條的話下次會怎麼錯？

    答不出來的條目就是抄來的最佳實踐，從來沒有被現實打過臉，留著只會稀釋真貨的訊號強度。Brain 的價值不在條目多寡，在每條都有血。

    結論：選的不是工具，是「知識怎麼進來、怎麼出去」

    Karpathy Skills 跟我這套不是對立關係，是知識層設計的兩種極端。前者把「該怎麼寫 code」濃縮成 4 條原則；後者把「我跟這個專案 / 使用者過去發生過什麼」做成分層動態檔案。

    你的選擇取決於：你的工作有沒有累積性。一次性任務不需要 brain，每個專案都從零開始的人不需要 Iron Rules。但只要你在同一個領域 / 同一個專案 / 同一個合作關係上待夠久，知識的價值就會從「通用原則」往「具體經驗」傾斜。這時候 Karpathy 的 4 條會變成必要但不充分。

    挑 skill 系統時別只看 prompt 寫得多漂亮，看知識怎麼進去、怎麼長大、怎麼用這三條通路。漂亮的 prompt 滿街都是，能持續累積的系統才稀缺。

  • 腦子系統壓軸:萬人製造集團 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)

  • 給銷售的 AI 工具:LLM 產自助 HTML × ERP CRUD × 即時資訊圖

    重點摘要(TL;DR)

    • 銷售/業務人員在 Telegram 一句話「幫我畫上週每個客戶訂單金額長條圖」 → LLM 30 秒產出 self-contained HTML 檔案 → 員工瀏覽器點開 → 看到即時圖表。
    • HTML 是 standalone 純靜態,從 CDN 載 Chart.js + Tailwind,內含 JS 透過公司 Gateway 對接 iDempiere REST(不直連 ERP)。
    • 四層架構:Generation(LLM 產)/ Execution(瀏覽器跑)/ Data(Gateway proxy)/ Rendering(Chart.js 渲染)。
    • 混合模式:LLM 產 HTML 時 inline 一份預載資料(打開立即顯示),HTML 內按「重新整理」可主動 fetch 最新值。速度和即時性兼得。
    • 安全設計:HTML 不含 secrets、Gateway 認 SSO、LLM 產的 HTML 用 textContent 防 XSS、Gateway 校驗 OData filter 防 injection、員工只看到 AD_Role 允許的資料。
    • 本文是腦子系統的第六篇,前五篇:Why / How / Scale / Tools / ERP。

    一、使用情境

    銷售 Tom 在通勤路上滑手機,腦子裡想到「**等等開會要秀上週業績**」。

    傳統流程(沒有這個工具)

    1. 到公司打開電腦
    2. 登入 ERP
    3. 找到訂單視窗
    4. 篩選日期
    5. 匯出 Excel
    6. 用 PowerPoint / Excel 畫圖
    7. 合計花 30-60 分鐘

    新流程(本文設計)

    1. Telegram 對 bot 說:「上週每個客戶訂單金額長條圖」
    2. 30 秒後 bot 回 HTML 檔(或連結)
    3. 點開,圖表立刻渲染
    4. 開會時直接全螢幕秀
    5. 合計花 30 秒

    關鍵:銷售不需要學任何工具、不需要安裝 app、不需要 IT 部署任何東西。產出的 HTML 還可以分享給同事、存證、離線重看。

    二、四層架構

    銷售 Tom (Telegram chat)
   ↓
[Generation 層] LLM 看公司腦 + 員工 prompt
   ↓ 產 self-contained HTML
HTML 檔案 (Chart.js + Tailwind 從 CDN 載)
   ↓ Tom 在瀏覽器打開
[Execution 層] 瀏覽器跑 HTML 內 JS
   ↓ JS 對 https://gateway.example.com/erp/query 發 fetch
[Data 層] 公司 Gateway (LiteLLM + Portkey + 自製 ERP proxy)
   ↓ Gateway 帶 Tom 的 SSO 身份
   ↓ 呼叫 iDempiere MCP server / REST API
   ↓ iDempiere AD_Role 自動過濾資料
   ↓ 回 JSON
HTML 內 JS 接到 JSON
   ↓
[Rendering 層] Chart.js 渲染圖表 / 動態表格 / 資訊圖

    四層各自的職責清晰、可獨立替換:

    • Generation:換 LLM(Claude/GPT/本地 Qwen)不影響其他層
    • Execution:瀏覽器標準環境,任何裝置都能跑(Mac / Windows / iPhone Safari)
    • Data:Gateway 換成內部 service mesh、ERP 換成另一套都不影響 HTML
    • Rendering:換 Chart.js 為 ECharts / Plotly 只改前端,後端不動

    三、混合模式:預載 + 即時刷新

    LLM 產生 HTML 時面對一個取捨:

    模式 優點 缺點
    A 純 inline:LLM 把資料寫死進 HTML 簡單、離線可看、無 CORS 資料是快照,要新查就要重新產
    B 純 fetch:HTML 啟動才查 每次最新 打開時白屏 1-2 秒、需連線
    C 混合(推薦):預載 + 重新整理按鈕 立即顯示 + 隨時更新 + 離線可看快照 HTML 較大(包含初始資料)

    實務上 C 混合模式最佳。實作:LLM 在產 HTML 時順便呼叫一次 Gateway 拿初始資料,把 JSON 寫進 HTML 的 const initialData = [...],同時保留 refresh() 函數讓員工按按鈕主動更新。

    四、LLM 怎麼產 HTML — Prompt 設計

    給 LLM 的 system prompt 要包含五件事:

    1. HTML 模板骨架:固定的 head / body 結構,用哪個 CDN 圖表庫
    2. Gateway URL 與 API schema:fetch 要打哪、payload 格式
    3. 可用 ERP table 與欄位:從公司腦讀(C_Order / C_BPartner / M_Product 等的可查欄位)
    4. OData filter 語法:eq/neq/gt/contains 等(注意 iDempiere 用 neq 不是 ne)
    5. 安全規範:用 textContent 不用 innerHTML、不要 hardcode token、不要 eval()

    4.1 System Prompt 範例(精簡版)

    You are a HTML dashboard generator for sales staff.

CONTEXT (from company brain):
- Available ERP tables: C_Order, C_BPartner, M_Product, M_InOut
- Common columns for C_Order: GrandTotal, DateOrdered, C_BPartner_ID, IsSOTrx
- Filter syntax: OData (use 'neq' not 'ne')
- Gateway endpoint: https://gateway.example.com/erp/query
- Gateway auth: SSO cookies (credentials: 'include')

OUTPUT REQUIREMENTS:
1. Generate ONE complete self-contained HTML file
2. Use Chart.js via CDN (https://cdn.jsdelivr.net/npm/chart.js)
3. Use Tailwind via CDN (https://cdn.tailwindcss.com)
4. Include initial data inline (call Gateway once and embed JSON)
5. Provide a refresh() function for live update
6. Use textContent (NEVER innerHTML) when displaying data
7. Add a loading spinner during fetch
8. Style: clean, presentation-ready (用得上開會秀客戶)

USER QUERY: {{user_message}}

    五、產出 HTML 範例(完整可執行)

    下面是 LLM 看到「上週每個客戶訂單金額長條圖」這個 query 後產出的範例 HTML。這是真實可執行的 self-contained 檔案:

    <!DOCTYPE html>
<html lang="zh-Hant">
<head>
<meta charset="utf-8">
<title>上週訂單金額(by 客戶)</title>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script src="https://cdn.tailwindcss.com"></script>
</head>
<body class="bg-slate-50 p-6 font-sans">

<div class="max-w-4xl mx-auto">
  <div class="flex items-center justify-between mb-4">
    <h1 class="text-2xl font-bold">上週訂單金額(by 客戶)</h1>
    <button id="refreshBtn"
            class="bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700">
      🔄 重新整理
    </button>
  </div>
  <p id="meta" class="text-sm text-slate-500 mb-4"></p>
  <canvas id="chart" height="120"></canvas>
  <table class="mt-6 w-full text-sm">
    <thead class="bg-slate-200">
      <tr><th class="text-left p-2">客戶</th><th class="text-right p-2">訂單數</th><th class="text-right p-2">金額</th></tr>
    </thead>
    <tbody id="tableBody"></tbody>
  </table>
</div>

<script>
// === 預載資料(LLM 產生時 inline 進來) ===
const initialData = [
  {customer: "客戶 A", orderCount: 5, amount: 1280000},
  {customer: "客戶 B", orderCount: 3, amount: 850000},
  {customer: "客戶 C", orderCount: 7, amount: 2100000},
  {customer: "客戶 D", orderCount: 2, amount: 420000}
];
const generatedAt = "2026-05-02 09:30";

// === Gateway 設定 ===
const GATEWAY_URL = "https://gateway.example.com/erp/query";
const QUERY = {
  table: "C_Order",
  filter: "DateOrdered ge '2026-04-25' and DateOrdered le '2026-05-01'",
  groupBy: "C_BPartner_ID",
  aggregate: ["count", "sum(GrandTotal)"]
};

// === 渲染函數 ===
let chart;
function render(data, ts) {
  // 注意:用 textContent 不用 innerHTML 防 XSS
  document.getElementById('meta').textContent = `資料時間:${ts}`;

  const tbody = document.getElementById('tableBody');
  tbody.textContent = '';
  data.forEach(row => {
    const tr = document.createElement('tr');
    tr.className = 'border-b';
    [row.customer, row.orderCount, row.amount.toLocaleString()].forEach((v, i) => {
      const td = document.createElement('td');
      td.className = i === 0 ? 'p-2' : 'p-2 text-right';
      td.textContent = v;
      tr.appendChild(td);
    });
    tbody.appendChild(tr);
  });

  if (chart) chart.destroy();
  chart = new Chart(document.getElementById('chart'), {
    type: 'bar',
    data: {
      labels: data.map(d => d.customer),
      datasets: [{
        label: '訂單金額(NTD)',
        data: data.map(d => d.amount),
        backgroundColor: 'rgba(59, 130, 246, 0.6)'
      }]
    },
    options: {
      responsive: true,
      plugins: {legend: {display: false}}
    }
  });
}

// === 即時刷新 ===
async function refresh() {
  const btn = document.getElementById('refreshBtn');
  btn.disabled = true;
  btn.textContent = '⏳ 載入中...';
  try {
    const r = await fetch(GATEWAY_URL, {
      method: 'POST',
      credentials: 'include',  // 帶 SSO cookies
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify(QUERY)
    });
    if (!r.ok) throw new Error(`Gateway error ${r.status}`);
    const data = await r.json();
    render(data.rows, new Date().toLocaleString('zh-TW'));
  } catch (e) {
    alert('刷新失敗:' + e.message);
  } finally {
    btn.disabled = false;
    btn.textContent = '🔄 重新整理';
  }
}

// === 初始化 ===
document.getElementById('refreshBtn').addEventListener('click', refresh);
render(initialData, generatedAt);
</script>

</body>
</html>

    這個檔案存成 orders.html,雙擊即可在瀏覽器打開。打開時看到預載資料(已渲染圖表 + 表格);按「重新整理」就 fetch 最新資料。整個檔案約 80 行,包含全部 logic。

    六、安全設計(必看)

    6.1 HTML 端

    • ❌ 絕不在 HTML 寫 token / API key:HTML 是員工拿到的檔案,寫 token 等於洩漏。所有認證在 Gateway server side
    • ✅ 用 fetch(..., {credentials: 'include'}) 帶員工 SSO cookies
    • ✅ 渲染用 textContent,不用 innerHTML(防 LLM 產的 XSS)
    • ✅ 不用 eval()、Function() 等動態 code 執行
    • ✅ Chart.js / Tailwind 從固定 CDN 載(版本鎖定),不從不可信來源載

    6.2 Gateway 端

    • SSO 認證:員工已登入公司,cookies 自動帶,Gateway 認 user identity
    • OData filter 校驗:LLM 產生的 filter 要過 Gateway 校驗(白名單欄位、operator 限制),防 SQL injection / 越權查詢
    • Rate limit:單一員工每分鐘最多 X 個 query,防 LLM 產的迴圈失控
    • Audit log:每個 query 記錄(誰、何時、查什麼、回傳幾筆),進 SIEM
    • CORS 白名單:Gateway 只允許指定 origin(若 HTML 託管在內網檔案分享伺服器,設定該 origin)

    6.3 ERP 端

    • iDempiere AD_Role 自動套:Gateway 帶員工 token 進 iDempiere,業務 Tom 看不到 CFO 才看的到的資料
    • 不直連 ERP:HTML 的 fetch 不直接打 iDempiere,一律走 Gateway proxy。理由:ERP 不該暴露在 internet,Gateway 才是受控邊界
    • Process call 限制:銷售工具預設 read-only,要寫資料(下單、修改)需要更高層審核或專用工具

    七、CORS / 認證的具體做法

    三條路徑分析:

    路徑 CORS 認證 推薦
    HTML → 直連 iDempiere REST 需開 iDempiere CORS 設定 JWT token 存 HTML(危險) ❌ 不要
    HTML → 公司 Gateway → iDempiere Gateway 設 CORS 白名單 SSO cookies 自動帶 ✅ 推薦
    HTML → MCP server → iDempiere MCP server 設 CORS MCP OAuth 2.1 ⚠️ 進階(複雜但可)