當 AI Skill 不再是工程師專利：一個讓全團隊安全貢獻自動化的設計

一句話就能跑的工作，背後是個治理問題

我們團隊十幾個人，工程師是少數，多數是業務、客戶成功（CS）、廣告投手。過去半年發生一件有趣的事：這些「不寫程式」的同事，開始自己做出可執行的 AI 自動化工具。

不是 prompt 模板，是真的「打一句話就跑完一整套流程」的東西——撈資料、整理、產出報告。我們把這種單元叫 skill：本質是一個 Markdown 檔，描述「什麼時候觸發、要做哪幾步」，AI agent 讀了就照做。

聽起來很美好。但當你想把這件事放大到「全團隊都能貢獻、互相共用」時，真正的難題不是技術，是這句話：

「CS 寫的那個查訂單 skill，會不會哪天不小心把整份客戶名單撈出來、貼到不該貼的地方？」

這篇講我們怎麼用一個輕量的「權限閘道（gateway）」把這個風險關起來，同時不殺死「人人都能貢獻」的彈性。

設計目標：賦能與治理要同時成立

兩個看似矛盾的目標：

• 賦能：非工程師也能寫 skill、投稿、共用，門檻越低越好
• 治理：碰到敏感資料（客戶名單、訂單明細）的 skill 必須被管控，誰能用、撈了什麼要留痕

多數團隊會選一邊：要嘛鎖死（只有工程師能碰自動化），要嘛放生（大家亂寫、出事再說）。我們想兩個都要。

核心：用「資料敏感度」分三級

每個 skill 在檔頭標一個等級 sg-level：

分級決定三件事：誰能用、要不要過閘道、PR 由誰審。

• Level 0：全員可用，PR 通過自動化檢查就自動合併
• Level 1：要授權才能用，主管層審核
• Level 2：最敏感，負責人親自審

光是「逼每個作者想清楚自己這支 skill 是哪一級」，就已經擋掉一大半的無意識外洩。

關鍵原則：不要相信 skill 自己宣告的等級

這是整個設計最重要的一句話。

skill 是純文字、放在共用倉庫，任何人 clone 下來都能把 sg-level: 2 改成 0。所以「檔頭宣告」這層完全不可信——它只是給人看的意圖宣示。

真正的防線是三層獨立把關：

1. Skill 宣告（不可信）：作者標的等級，只是宣示
2. Gateway 授權（可信）：閘道在伺服器端查「這個人有沒有權限跑這支 skill」，使用者改不到
3. Backend 按路徑守（最可信）：真正撈資料的後端服務，用「不同 endpoint 對應不同等級」寫死——攻擊者就算改了 skill 的判斷邏輯，也繞不過後端的路徑分流

每一層都不信任前一層。任何一層偷懶去信任上一層，整條鏈就被打穿。這是零信任在「內部自動化」場景的具體落法。

順帶一提：我們差點過度設計

最有意思的是收尾時的一個轉折。

一開始我們寫死規定：所有 skill，連 level 0 都要先打閘道驗身，理由是「統一留 audit log」。聽起來合理。

但實作到一半發現不對勁：level 0 的 skill 結構上就碰不到敏感資料（檢查機制會擋掉它連任何內部後端）。對一個碰不到敏感資料的工具，閘道唯一的作用只剩「記一筆誰跑過」。而我們有些 level 0 是「救命用的中途存檔工具」——如果閘道剛好掛了，難道連存個進度都不行？

於是改成：level 0 的閘道驗身是「建議」而非「強制」。

更關鍵的是想通一個機制細節：「宣告等級」和「真的去打閘道的那段程式碼」是兩回事。閘道會被呼叫，是因為 skill 內文裡寫了那段呼叫；不是因為你標了某個等級就自動觸發。所以「豁免」的正確做法是**「不寫那段」，而不是「加一個豁免開關」**——少一個開關，就少一個會被誤用的東西。

這是個小決定，但它提醒我一件事：安全機制也要過「奧卡姆剃刀」。為了「一致性」而對結構上無害的東西強制加管控，那不是嚴謹，是雜訊。

可以帶走的幾個原則

1. 賦能與治理不是二選一：用「資料敏感度分級」當共同語言，低風險的放手、高風險的收緊。
2. 不要相信宣告，要在執行端把關：任何「使用者改得到」的設定都只能當意圖，真正的防線要在伺服器端、且多層獨立。
3. 把審查流程綁在風險等級上：低風險自動過、高風險人工審，reviewer 的注意力才花在刀口上。
4. 安全機制也要剃刀：對結構上無害的東西強制加管控，是雜訊不是嚴謹。

讓非工程師也能安全地造工具，這件事的天花板比想像中高。難的從來不是讓他們會寫，是讓他們寫錯了也不會出事。

這套設計用 Claude Code 的 skill 機制落地。概念可遷移到任何「多人共用、分權限」的 AI agent 工具庫。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。