AI 不只幫你寫 Code： 當專案從 300 暴增到 1500， 我們如何撐住 DevOps

AI Agent 浪潮席捲企業，帶來的不只是開發效率的提升，還有一個很多人沒預料到的副作用 — 公司的專案數量從 300 個在短時間內暴增到 1500 個。

當每個單位都在用 AI 快速產出服務，DevOps 的壓力不是線性成長，而是指數級爆炸。

這場演講要分享的，是我們如何在這波暴風式成長中，建立起一套可規模化的 DevOps 體系，讓品質不會因為速度而崩盤。

第一，讓 AI 守住每一個 PR 的品質底線。

1500 個專案，靠人力 Review 已經不可能。

我們在 PR 流程中導入 AI 驅動的架構審查與資安審查，讓每個專案不管大小，都有一道自動化的品質防線。

這不是錦上添花，而是在這個規模下唯一能活的方式。

第二，讓新團隊兩週內跑起來，而不是三個月。

面對大量湧入的新專案與新單位，我們不可能每次都花三個月手把手導入開發流程。

透過 AI 輔助，團隊導入標準化流程的時間從三個月壓縮到兩週，讓 DevOps 的推廣速度跟得上專案的增長速度。

第三，用 GitOps 打造 MCP 服務的自動化上架流水線。

當 AI Agent 本身成為需要部署的服務，我們用 Gitea、API 與 Gitea Action 建立了一套 GitOps 驅動的 MCP 上架流程。

一次 git push，從程式碼到服務上線全自動完成。

人幫 AI 建 DevOps，這件事已經不是未來式，而是我們的日常。

這場演講不講理論，只講真實戰場上的決策、取捨與教訓。

如果你的組織也正在面對 AI 帶來的爆發式成長，這場分享會讓你看到一條走過驗證的路。

聽眾收穫：

學會如何用 AI 驅動 PR 審查，在專案數量暴增時仍能守住品質與資安底線
了解如何將新團隊導入標準化開發流程的時間從三個月壓縮到兩週
掌握以 GitOps 驅動 MCP 服務自動化上架的流水線實作方式
獲得一套經過 300→1500 專案規模驗證的 DevOps 擴展策略與實戰經驗

https://devopsdays.tw/2026/session/4709

Transcript

1. D E V O P S D A Y S T A I P E I 2 0 2 6 REAL-WORLD DEVOPS 一場關於規模失控的實戰 AI 不只 幫你寫 Code 當公司專案從 300 暴增到 1500， 我們如何撐住 DevOps。 appleboy 後端架構工程師 40 min Tech Talk 2026 . 06 . 26 指數級成長 壓力不是 ×5 ，而是不斷外擴
2. A B O U T T H E S P E A K E R 講者介紹 appleboy 後端架構工程師 GitHub github.com/appleboy Speakerdeck speakerdeck.com/appleboy 現任後端架構工程師，負責公司內部 Technology Platform 開發與維運。 擅長以 Go 構建微服務架構，熱衷導入 DevOps 與自動化流程，改善團隊 協作效率。長期貢獻 Open Source，曾任多場技術研討會講師。目前專注 於 AI 工具導入，探索 AI 能為軟體團隊加速多少開發流程與決策效率。 Go 微服務架構 DevOps · 自動化 Open Source AI 工具導入 帶領三個小團隊 01 Backend 02 Kubernetes 03 CI / CD 02
3. T H E T U R N I N G P O I N T 專案數量的成長，不是一條直線 01 　起點 2025 少量、可控 專案數量有限，人工就能看顧每個 repo、每條 pipeline，DevOps 還跟得上。 02 　轉折 AI 工具普及 每個單位都能用 AI 快速做出服務，新專案開始自 助湧現，不再經過同一批人。 03 　現在 2026 不可預期 數量暴增到 1500+ 且持續成長，沒有人能預測上 限——成長變成了預設值。 為什麼我們的專案，從一開始的少量， 到現在的不可預期？這中間的變化過程 起點 · ~300 轉折 現在 · 1500+ 03
4. A D O P T I O N T I M E L I N E 從工具問世，到全公司落地的這一年 外部生態 內部整合 規模落地 2025 · 02 Claude Code 橫空 出世 AI coding agent 正式登 場，外部生態的起點。 2025 · 03 整合 AI Gateway IT 協助把 Claude Code 串進內部 AI Gateway。 2025 · 05 串接 Observability IT 接上可觀測性，開始 量化導入效益。 2025 · 09 導入 SWRD 部門 落地軟體研發相關部門。 2025 · 10 Anthropic 推出 Skill 改變了整個 Workflow 生態。 2026 · 04 落地 HWRD 部門 擴展到硬體研發相關 部門。 04 2025 2026
5. 05 P A R T 0 1 · P L A T F O R M 工具問世，只是起點。真正的工程在落地。 怎麼讓全公司裝好就能用， 又管得住？ 把單點工具，變成一座可治理的內部平台。 接下來：先讓 AI 都走同一道 Gateway →
6. Z O O M I N · 2 0 2 5 · 0 3 在規模失控之前，先讓 AI 都走同一道門 外部生態 內部整合 規模落地 06 2025 2026 本場接下來，放大這一 段 → 2025 · 03 整合 AI Gateway IT 協助把 Claude Code 串進內部 AI Gateway ——所有 AI 流量統一進 出，可管控、可計量。
7. A R C H I T E C T U R E · G A I S F G A T E W A Y CLI 等開發者工具，都先整合進 GAISF Gateway，才連上三大雲與自建模型 不論 CLI、Web 還是 Browser，開發者端每一次 AI 呼叫都統一從這道閘門進出——再由 Gateway 分流到公有雲與自建 GPU。 C-DOMAIN · 開發者端 使用者入口 CLI 工具 Web Service Browser → RD-DMZ · 單一進出口 GAISF Gateway 所有請求集中進出，統一治理與分流 Grafana & Loki Log Service Usage Log 已過濾 Request / Response Body ，只留稽核所需 → CLOUD PROVIDER · 公有雲 AWS Bedrock Claude Azure AOAI GPT GCP Gemini INTERNAL DOMAIN · 自建 GPU Qwen3 GPU GLM-5.2 GPU E5-Embedding GPU 單一進出口，於是我們能 四件事一次到位 01 USAGE 使用量分析 誰用了多少、用在哪，靠 Grafana & Loki 全看得見。 02 AUDIT 內部稽核 每次呼叫都進 Log Service 留痕，事 後可追溯。 03 COST 控管流量花費 集中計量與設限，雲端與 GPU 成本 不再失控。 04 ACCESS 權限控管 依部門與角色，決定可用的模型與 範圍。 07
8. R E L I A B I L I T Y · M U L T I - C L O U D H A M O N I T O R 對接三大公有雲，靠 跨 region HA 撐住可用性 Gateway 背後是 Azure、AWS、GCP 三大雲加上自建核心——任何一朵雲抖動，都不能讓全公司的 AI 工具停擺。 為什麼需要跨 REGION HA 01 多 region 部署 每朵雲都串接多個 region，單一 region 故障時自動繞 過、不影響服務。 02 健康檢查 + 自動 failover 即時偵測錯誤率，異常節點立刻切走，流量重導到健康 區域。 03 逐模型監控告警 30+ 模型的成功率與錯誤數逐一追蹤，異常立即通知。 可用性就是信任——AI 工具要被全公司採用，背後 的 gateway 必須隨時都在。 Gateway · Provider Availability 近 30 天 · 成功率 Azure OpenAI + Cognitive 99.6% AWS Bedrock Claude 99.9% GCP Gemini 99.7% On-Prem 自建 98% 健康 ≥ 99% 留意 < 99% 軸 90–100% 08
9. I N T E R N A L T O O L I N G · C C H 一支內部 CLI，讓全公司 裝好就能用 我們做了 Coding CLI Helper（cch），協助全 公司一鍵裝好 Claude Code、Gemini CLI、 Codex CLI 等工具，再透過 GAISF Gateway 做 內部控管。 01 一鍵安裝 互動選單勾選想用的 AI CLI，自動安裝與更新。 02 統一認證 用 GAISF 認證，免去各家 API Key 各自管理。 03 內部控管 所有流量走 Gateway，使用、成本、權限皆可控。 cch · Coding CLI Helper v6.20.2 Which tools do you want to install? → [✓] Claude Code Anthropic's AI coding assistant [ ] Claude Code Router Proxy for OSS LLM support [✓] Gemini CLI Google's AI coding assistant [ ] OpenCode The open source AI coding agent [✓] Codex CLI OpenAI's AI coding assistant Submit enter/␣ select · ↑↓ navigate · ↔ tabs · a all · n none · esc back 09
10. T H E D A T A · P E R - U S E R D A S H B O A R D （ ） Track your AI model consumption and costs across all providers — 每位使用者每天的用量都看得到。 Today's Usage 2026-06-09 15.8% 0% 25% 50% 75% 100% USED TODAY $2.6336 REMAINING $14.0664 DAILY CAP $16.7000 實時顯示當日用量（USD）；可切換日期區間查看歷史數據。 TOTAL COST $2.63 USD · across all providers TOTAL REQUESTS 23 API calls completed TOTAL TOKENS 1,838,392 Input + Output combined CACHE READ 455,168 Served from cache · reduces cost Usage Details DATE PROVIDER MODEL COST (USD) REQUESTS INPUT CACHE READ OUTPUT 2026-06-09 AOAI gpt-4.1 $0.0196 2 3,625 2,304 1,973 2026-06-09 AOAI gpt-5.2 $2.6140 21 1,822,824 452,864 9,970 Token Daily Usage 10
11. Z O O M I N · 2 0 2 5 · 0 5 在規模失控之前，先讓一切可被觀測 外部生態 內部整合 規模落地 11 2025 2026 本場接下來，放大這一 段 → 2025 · 05 串接 Observability IT 接上可觀測性，開始 量化導入效益——也是 撐住後續規模的關鍵。
12. 12 P A R T 0 2 · I M P A C T 平台跑起來了。那，成果呢？ AI 在真實專案裡， 到底做了多少？ 不靠感覺，用數據說話。 接下來：每 10 行裡，AI 寫了幾行 →
13. T H E D A T A · S I N C E 2 0 2 5 . 0 8 新增的每 10 行程式，有 9 行是 AI 寫的 90.4% 9.6% 12.24M AI 產出行數 （code + 文件 + 測試） 1.29M 工程師親手撰寫行數 9.5× AI 是人類產出的倍數 工程師的產出其實沒有變少，每月大致持平——是 AI 的爆量，把人的佔比稀釋到一成以下。 資料區間 2025.08 – 2026.06 ，全公司每月新增行數加總；2026.06 為當月累計，尚未結算。 AI 產出 工程師 13
14. T H E D A T A · M O N T H L Y T R E N D AI 暴衝、工程師平盤，差距持續拉開 AI 佔比從 2025.08 的 66%，一路爬升到近期的 96%；同時月產出量也成長近 9×。 AI 產出 工程師親寫 各月數字下方為該月 AI 佔比（AI ÷ 全部新增行數） 。單位：每月新增行數（code + 文件 + 測試） ；2026.06 為當月累計（淡色） ，尚未結算。 08 66% 09 10 11 12 01 02 03 04 05 96% 06 2025 2026 0.22M 0.57M 0.46M 0.76M 1.18M 1.56M 1.40M 1.31M 1.89M 2.08M 0.80M 80% 80% 80% 88% 91% 94% 91% 95% 97% 14 66%→ 96% AI 佔比，10 個月一路爬升
15. T H E D A T A · B Y C A T E G O R Y 人最不想寫的文件與測試，AI 補得最滿 三個類別 AI 都過半，但 文件、測試的 AI 佔比（96%）甚至高於程式碼（86%）。 DEVELOP 程式碼 共 7.61M 行 86.3% 由 AI 產出 AI 6.57M 工程師 1.04M DOCUMENTATION 文件 共 5.00M 行 95.6% 由 AI 產出 AI 4.78M 工程師 0.22M TESTING 測試 共 0.93M 行 96.4% 由 AI 產出 AI 0.90M 工程師 0.03M 資料區間 2025.08 – 2026.06 。文件 + 測試是過去最常被省略的部分，如今幾乎全由 AI 補上。 15
16. 16 T A K E A W A Y · W H A T W E A C T U A L L Y M E A S U R E 數字看完了—— 但別把它當成評分表。 從來不是 評估產出的標準。 我們真正在意的，是該如何協助 AI 產出更有價值的資料——更可靠的 程式、更完整的文件與測試，而不是更長的 diff。 所以下半場，談的是 品質 → 行數
17. 17 P A R T 0 3 · Q U A L I T Y 數量的故事說完了，接下來是品質。 產生這麼多程式碼， 該如何把關優化？ 每 10 行有 9 行是 AI 寫的——數量不是問題，品質才是。 接下來：把把關搬進 PR 流程 →
18. T H E G U A R D R A I L · W H E R E W E F O C U S AI 已經在寫 code、文件、測試——我們把力氣花在兩端 中段的「實作」已大幅由 AI 接手；真正決定品質的，是更早的 Plan，與更後面的 CI。 更早 Plan · 規劃 需求、架構、規格先想清楚，AI 才寫得對。把人的判斷投在上游，少 返工、少技術債。 後段 CI · 整合驗證 在 PR 流程裡放上自動化的架構與資安審查，把守住品質的工作交給 流程——這正是下一頁要談的。 18 Plan 規劃 我們著重 ← Code 開發 AI 已接手 Docs 文件 Test 測試 CI 整合驗證 → 我們著重 Deploy 部署
19. P L A N · T E A M S K I L L 把團隊規範寫成 Skill，讓 AI 動手前先「規劃」 在 Plan 階段導入 plan-feature ——一個依團隊規範撰寫的 Skill，強制 AI 在寫任何 code 前，先把需求、範圍與驗證想 清楚。 核心做法 當 AI 的 PM 寫 code 前花 ~15 分鐘，把需求、限制與 「完成的定義」講清楚，而不是直接丟一 句話。 產出 一份 plan.md 含一張 Mermaid 設計圖，描述功能怎麼接 起來——讓人一眼看懂、容易審查。 交棒 乾淨地執行 開新對話、照 plan.md 執行；計畫就是合 約，不偏離 scope。 觸發　要 add / build / implement 一個非瑣碎功能時 略過　typo 、單行修改、改名等瑣碎變更 19 “多數失敗的 AI coding，不是模型不行，而是人沒給足夠的 context。
20. P L A N · 8 - S T E P W O R K F L O W 八步工作流：把模糊變成確定，再交給 AI 01 釐清目標 CLARIFY THE GOAL 誰用、 「完成」長什麼樣、已知限制 ——先得到一段確認過的問題敘述。 02 探索程式碼 EXPLORE CODEBASE 找結構相似的既有功能、既有慣例， 分清 core 與 leaf。 03 界定範圍 IDENTIFY SCOPE 列出「可改」與「不可改」兩份清 單，碰到 core 要明講。 04 訂驗證策略 VERIFICATION 先想好 3 個 e2e 測試（1 正常 + 2 錯 誤） ，驗證先於實作。 ✓ 驗證先於設計 05 畫設計圖 SKETCH DESIGN 用 Mermaid 畫出功能怎麼接起來， 錯誤的邊界在圖上一眼可見。 06 撰寫 plan.md DRAFT PLAN.MD 照模板寫得具體、不抽象，像給新人 的 onboarding 文件。 07 取得核可 GET APPROVAL 與使用者逐一走過設計圖；確認前不 寫任何 code。 ⛔ 寫 code 前的停損點 08 交棒執行 RECOMMEND HANDOFF Compact 或開新對話，以乾淨的脈 絡照計畫執行。 依序進行 第 1–6 步把計畫備齊、第 7 步取得核可前不動 code 、第 8 步才交棒實作。 20
21. P L A N · T H E O U T P U T plan.md — 一份讓任何工程師都能照做的合約 plan.md # Goal 誰用、完成長怎樣 ## Architecture ```mermaid 設計圖``` 最重要 ## Scope May / Must-not modify ## Patterns 要遵循的既有寫法 ## Constraints 效能 · 相依 · 安全 ## Verification 3 個 e2e 測試 ## Done ☐ 完成的定義（checklist ） ## Risks 風險與回滾方式 ## Open questions 尚待釐清 ## Architecture · 一張圖看懂 與其讀冷冰冰的文字，不如用一張架構圖搞懂這次功能怎麼蓋 Client API Handler NEW ROUTE Domain Service EXISTING Async Worker NEW JOB Datastore 新增 New 既有 Existing 節點控制在 15–20 內 畫得出的，才是真的會蓋的——錨定在 scope，別畫理想架構。 碰到 core code 一定要明講，交給人主導，別讓 AI 在核心累積技術債。 21
22. T H E G U A R D R A I L · P R R E V I E W 這麼多 AI 程式碼，品質誰來把關？ 靠人力逐行 Review 已經不可能 —— 我們把把關搬進 PR 流程，由 AI 自動審查。 01 建立 PR OPEN PULL REQUEST → 02 AI 自動審查 ARCHITECTURE · SECURITY → 03 通過才能 Merge QUALITY GATE PASSED 審查 A ARCHITECTURE 架構審查 確保 AI 寫出來的程式符合專案設計原則，不會在規模成長下逐漸 腐化。 模組邊界與相依關係是否合理 是否遵循團隊既有的設計慣例 複雜度與可維護性是否失控 審查 B SECURITY 資安審查 在 Merge 之前就攔下風險，不讓漏洞流進主幹，每個 PR 都是一道 關卡。 機敏資訊與金鑰是否外洩 注入、權限等常見漏洞掃描 第三方相依套件的已知風險 ✓ 不管專案大小，每個專案都有一道自動化的品質防線——把關不再依賴人力，而是內建在流程裡。 22
23. T H E G U A R D R A I L · S E C U R I T Y R E V I E W CI 流程最關鍵的一關：資安審查 同一個 PR，三道並行的 code review 同時把關 —— 從靜 態分析、漏洞掃描，到 AI 情境審查。 每個 PR 並行觸發三道掃描 三道全綠才放行 01 Coverity Scan SAST 原始碼靜態分析 記憶體錯誤、資源洩漏、Null 解參考 注入漏洞與不安全的 API 使用 02 Trivy Scan SCA 相依套件 / 映像漏洞 已知 CVE 與 OS 套件漏洞 IaC 設定錯誤與外洩金鑰 03 Claude Code Review AI REVIEW AI 情境語意審查 商業邏輯漏洞與不安全模式 前兩者掃不到的情境問題 ✓ 工具掃廣度、AI 補語意 —— 三層互補，沒有一道漏洞能單靠一種方法溜過去。 23
24. S E C U R I T Y R E V I E W · 0 1 / 0 3 01 Coverity Scan 原始碼靜態分析 SAST 不執行程式，直接追蹤原始碼的資料流，把藏在邏輯深處的 安全缺陷與品質問題挖出來。 CI 觸發 每個 PR · 每日 build 分析對象 原始碼（data-flow 追蹤） 特色 深度資料流分析、誤報率低 攔截的風險 記憶體錯誤、Null 解參考、資源洩漏 SQL / Command Injection 等注入漏洞 不安全的 API 呼叫與未驗證的輸入 coverity · static analysis $ cov-analyze --dir idir --strip-path $PWD ▸ HIGH RESOURCE_LEAK payment/gateway.go:142 conn 在錯誤路徑未關閉 ✗ 3 high · 7 medium → PR blocked 24
25. S E C U R I T Y R E V I E W · 0 2 / 0 3 02 Trivy Scan 相依套件 / 映像漏洞掃描 SCA 掃描相依套件、容器映像與設定檔，比對已知漏洞資料庫， 攔下從外部帶進來的風險。 CI 觸發 build image 後 · 每個 PR 分析對象 套件 / 映像 / IaC / 金鑰 特色 開源、快速、涵蓋面廣 攔截的風險 相依套件與 OS 套件的已知 CVE Dockerfile / IaC 的設定錯誤 程式碼與映像中外洩的金鑰 Security Scan Summary trivy fs · target . repo marketplace/extension-catalog commit 8490a527 0 VULNS 0 SECRETS 1 MISCONFIG 25
26. S E C U R I T Y R E V I E W · 0 3 / 0 3 03 Claude Code Review AI 情境語意審查 CONTEXT 讀懂整個 PR 的上下文與商業邏輯，像資深工程師一樣指出 問題，並直接給出修補建議。 CI 觸發 PR 留言 / 自動觸發 分析對象 diff + 上下文語意 特色 理解情境、附修補建議 攔截的風險 商業邏輯漏洞與邊界條件 工具掃不到的不安全設計模式 可讀性與可維護性的隱性問題 Claude · Code Security Review .env.example crypto_certificate_validation MEDIUM EXTCAT_GITEA_INSECURE_SKIP_VERIFY 從 false 改為 true —— 等於對所有 Gitea API 通訊停用 TLS 憑證驗證，而 .env.example 常被直接複製 成 .env，新部署將預設關閉驗證。 建議 還原為 false；本機若需略過自簽憑證，加註解警告勿用於 production。 26
27. T O O L I N G · C L A U D E C O D E A C T I O N I N C I 不只 Review——把 Claude 接進 CI，一次設定、三種模式自動切換 在 PR、Issue 或 workflow 事件上掛一支 action，Claude 依情境自動判斷該做什麼——不用為每個任務寫不同的整合。 INTERACTIVE 觸發 · @claude 留言 互動助手 在 PR / Issue 直接 @claude 提問，它能回 答、實作修正、重構，並把改動 commit 回來。 REVIEW 觸發 · pull_request 自動審查 PR 一開或更新就自動審查，用 inline comment 標出問題，並以 checkbox 即時追 蹤進度。 AUTOMATION 觸發 · label / workflow_run 自動化任務 依 label、assignee 或 CI 結果跑自訂 prompt ——修 CI、triage issue、分析 commit 都行。 一支 ACTION ，順手做到 讀 CI log 找根因 改 code 並 commit inline 行內審查 進度 checkbox 結構化輸出 --json-schema commit signing Gitea / GitHub 雙平台 自架執行 27
28. I N P R A C T I C E · R E A L C I C A S E S 實際跑在 CI 上的四個案例 每一個都只是一支 workflow + 一段 prompt——以下全部來自我們正在用的設定。 01 自動修復 CI 失敗 workflow_run · failure CI 一紅，Claude 自動讀 log、定位根因、修正並 commit 回 PR，省去來 回貼錯誤訊息。 allowedTools "Edit, Bash(git:*), mcp__gitea_ci" 02 Flaky 還是真 bug？ workflow_run · failure 用結構化輸出判斷該重跑還是擋下，結果（含信心值）自動回貼到 PR。 --json-schema '{ is_flaky, confidence, summary }' 03 PR 全面審查 + 進度追蹤 pull_request 品質、資安、效能、測試逐項審查，inline 標註問題，checkbox 即時更 新進度。 track_progress: true · mcp__gitea_inline_comment 04 Issue 自動 triage / 去重 issues · opened 新 issue 一開，比對既有 issue 找重複、貼上連結，並依內容自動 上 label。 allowedTools "mcp__gitea, mcp__gitea_labels" 28
29. P R O O F · 真實 W O R K F L O W 設定 就是一支 workflow——四個案例都長這樣 核心一致：監聽事件 → 給 Claude 一段 prompt → 限定 allowedTools。走內部 GAISF Gateway（gaisf_api_key） ，差別只在觸發事件與那段 prompt。 auto-fix-ci.yml CASE 01 on: workflow_run: workflows: ["CI"] types: [completed] jobs: auto-fix: if: ${{ github.event.workflow_run.conclusion == 'failure' }} runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/claude-code-action@v2 with: gaisf_api_key: ${{ secrets.GAISF_API_KEY }} github_token: ${{ secrets.CLAUDE_GITEA_TOKEN }} prompt: | 讀 CI logs 、定位根因、 修正後 commit 回此 PR 。 claude_args: | --allowedTools "Edit,Bash(git:*),mcp__gitea_ci" 其他三個案例，只改這兩處 同樣的骨架，換掉 觸發事件與 prompt / args 就是另一個案例。 02 Flaky vs 真 bug claude_args: --json-schema '{ is_flaky, confidence, summary }' 03 PR 審查 + 進度 on: pull_request with: { track_progress: true } 04 Issue triage / 去重 on: issues [opened] claude_args: --allowedTools "mcp__gitea,mcp__gitea_labels" 29
30. B R I D G E · C I 之後的問題 CI/CD 接上了 Claude Code——而它的手腳，全是 MCP Tool 回頭看剛剛的 allowedTools：每一個 mcp__* 背後，都是一個要有人寫、有人部署、有人維護的 MCP Server。 ONE PIPELINE 一條 pipeline，就用了這些 mcp__gitea mcp__gitea_ci mcp__gitea_labels mcp__gitea_inline_comment 而這還只是接 Gitea 一個服務。 × COMPANY-WIDE 全公司的服務都想這樣做 Jira Confluence K8s 監控 資料庫 內部 API… 每個團隊都在為自己的服務寫 MCP Server。 = THE MESS 幾十個 MCP Server，散落各處 各自部署、各自發 key 品質與安全沒人把關 想用的人，根本找不到在哪 那——全公司服務長出來的 MCP 工具，該怎麼處理？ NEXT · AI MARKETPLACE → 30
31. 31 P A R T 0 4 · A I M A R K E T P L A C E 程式碼把關完了—— 下一個要管的，是 MCP 本身。 AI Marketplace 裡， MCP 怎麼上架與認證？ 每個團隊都在寫自己的 MCP Server——誰能上架、誰來把關、誰可以 用，需要一套企業內部的管理流程。 接下來：MCP 上架流水線 →
32. M A R K E T P L A C E · M C P 上架流程 一張 Gitea Issue 表單，從申請到上線全自動 開發者只做兩件事：填表、寫 code。審核通過後，建 repo、開路由、部署，全部由系統接手。 ✓ 上架不是開單等人開通——是一張表單加一個 approved label，剩下交給流程。 32 01 填寫 Issue 表單 APPLY 開發者 02 審核 + approved REVIEW 審核人員 03 Repo + 路由 + 部署 PROVISION 全自動 04 開發 MCP Tools DEVELOP 開發者 05 Push → 自動部署 DEPLOY 全自動 06 Claude Code 接上 CONNECT 使用者
33. M A R K E T P L A C E · 申請與審核 申請只是一張 Issue 表單——審核就是一個 label 表單即規格：名稱規則由系統即時驗證，人只負責判斷「該不該上」 。 I S S U E F O R M · 申請欄位 Repo Name xxx-mcp 小寫英文 + 連字號，系統自動驗證格式與重 複 Language Python / Go / Node——對應三套 template Domain OA / HWRD / SWRD / MPD，可複選，各自建 Kong 路 由 Service 描述 TA、要解的問題、預期成果 Egress 要連外網需附 EWF 申請單，部署時自動注入 egress sidecar 01 系統即時驗證 送出當下檢查 repo name 格式與重複，結果直接回在 Issue 裡。 02 審核人員 Review 判斷服務定位與 domain 合理性，通過就加上 approved label——這 是唯一的人工把關點。 03 Bot 建好一切、回報、關單 repo URL、Kong endpoint、Claude Code 設定，全部回覆在 Issue 後 自動 close。 33
34. M A R K E T P L A C E · A P P R O V E D 之後 加上 approved label，1–2 分鐘內四件事自動完成 開發者拿到的不是一個空 repo，而是已經接好路由、部署到 staging 的服務。 01 · REPO 從 Template 建立 Repo Python / Go / Node 三套 template， 申請人直接設為 repo admin。 02 · ROUTE 建立 Kong API 路由 每個勾選的 domain 各一條，內建認 證與限流。 03 · DEPLOY 初始部署到 Staging template 內建 Gitea Actions workflow，開箱就能跑。 04 · REPORT 回報結果、關閉 Issue repo URL、endpoint、Claude Code 設定一次給齊。 git push main → Staging 每次 push 自動部署 git tag v1.0.0 → Production 打 tag 才上正式環境 ✓ 之後的每一次上版，也都不需要找任何人——push 與 tag 就是部署。 34
35. M A R K E T P L A C E · 認證與接入 認證不歸 MCP 管——統一收在 Gateway 這一層 所有 Kong 路由掛同一個 gaisf-auth-plugin：開發者不用自己發 key，使用者拿原本的 GAISF token 就能接。 ~/.claude/settings.json CONNECT "mcpServers": { "spec-assistant": { "type": "http", "url": "https://appgw-it.internal/mcp/spec-assistant", "headers": { "Authorization": "Bearer <GAISF_TOKEN>" } } } # 或一行 CLI ： claude mcp add --transport http spec-assistant \ {endpoint} --header "Authorization: Bearer ..." 同一套 GAISF 認證 跟 Part 01 的 AI Gateway 同一個 token 體系——MCP 不自己管金鑰，權 限與稽核集中在閘道。 Endpoint 跟著 Domain 走 四個 domain 各有 staging / production 入口，路徑規則一 致： /mcp/{short_name} 。 不只 Claude Code 任何支援 StreamableHTTP 的 MCP Client 都能接——一條 URL、一個 header，完成。 ✓ MCP 也是服務——用管服務的方式管它：流程上架、閘道認證、流水線部署。 35
36. M A R K E T P L A C E · 安全性疑慮 但有個問題：Token 是明碼躺在 Client 端 不管是下指令還是開編輯器手動寫入——GAISF token 都以明碼落地，這是很大的安全風險。 ~/.claude/settings.json RISK "headers": { "Authorization": "Bearer eyJhbGciOiJSUzI1NiIs..." } # 明碼寫死在設定檔裡 # 用 CLI 加？一樣—— 還多留一份： $ claude mcp add ... --header \ "Authorization: Bearer eyJhbGci..." $ history | grep Bearer # shell history 裡也是明碼 明碼落地，到處複製 設定檔、shell history、dotfiles 同步與備份——一份 token 散落多處，任 何一處外洩都等於全部外洩。 拿到 Token 就是你 GAISF token 代表個人身份——拿到的人能以你的名義呼叫所有你能用的 MCP 與模型。 洩了難查、换了難推 散在每台機器的設定裡，誰洩的、何時洩的難以追查；輪換 token 還得每 個人手動改設定。 ! 認證收進 Gateway 是對的——但 token 的存放方式，是下一個要解的題。 36
37. M A R K E T P L A C E · 解法 · M C P A U T H O R I Z A T I O N 解法：走 MCP Authorization 規範——設定檔裡不再有 Token MCP 官方規範把授權交給 OAuth 2.1：token 由 Authorization Server 即時簽發，人不再經手、也不落地。 明碼消失 設定檔只剩 URL 沒有東西可以被同步、備份、grep 出來——上一頁的 風險源頭直接拔掉。 短效 + 輪換 洩了也活不久 規範要求短效 access token、refresh token 輪換， 外洩的影響窗口被壓到最小。 ✓ 從「人搬 token」變成「協定發 token」 ，再用 RFC 8707 把 token 鎖在單一資源上——上一頁的三個風險一次拆掉。 綁定資源 · RESOURCE INDICATORS RFC 8707 Token 只對一台 Server 有效 resource 參數把 token 綁定 audience——偷走也 不能拿去打別的服務。 主要重點 37 01 連線被擋下 401 CHALLENGE Server 回 401 + WWW- Authenticate，附上 metadata 位置 02 自動發現授權伺服器 DISCOVERY Client 讀 Protected Resource Metadata，找到 Authorization Server 03 瀏覽器授權 OAUTH 2.1 + PKCE 使用者按一次同意——這是唯一的人 工步驟 04 短效 Token 自動續期 SHORT-LIVED Access token 自動帶上、到期自動 換，全程不寫進設定檔
38. M A R K E T P L A C E · 內部架構 目前的內部架構：Kong 把關、AuthGate 發 Token，Client 不直連 MCP 每個請求都先過 Kong 上的 mcp-oauth2 驗 JWT，驗過才帶著身分與 scope 轉發進 MCP 集群。 MCP CLIENT 端 開發者工具 Claude Code OpenAI Codex Gemini CLI → Bearer JWT GATEWAY · 單一進入點 Kong Gateway + mcp-authgate plugin verify sig (JWKS) iss aud exp scope ↑↓ fetch JWKS （快取 / 自動輪替） AUTHORIZATION SERVER AuthGate /authorize · /token · Auth Code + PKCE → RS256 → X-MCP-Subject / Scope MCP 集群 內部 MCP Servers Gitea MCP Jira MCP Confluence MCP 只信 Kong 轉發進來的身分標 頭，自己不碰 token。 01 · CHALLENGE 無 token 請求被擋：401 + WWW- Authenticate 指向 resource_metadata 02 · DISCOVERY Client 讀 /.well-known/oauth- protected-resource 找到 AuthGate 03 · AUTHORIZE Auth Code + PKCE 走完授權， AuthGate 簽發 RS256 token 04 · VERIFY Kong 以 JWKS 驗簽章，再驗 iss / aud / exp / scope 05 · FORWARD 通過才轉發，附上 X-MCP-Subject 與 X-MCP-Scope 38
39. M A R K E T P L A C E · 設計取捨 為什麼是 RS256 + JWKS，而不是 HS256？ 驗證跑在最外緣的 Kong 上——簽章金鑰要不要交給 gateway，直接決定了攻擊面的大小。 vs ZERO-TOUCH ROTATION 金鑰輪替零接觸 在 AuthGate 換金鑰，Kong 透過 keyfunc 背景自動接手——完全不用改 Kong 設 定、也不用重啟。 ✓ 抓公鑰、快取、背景輪替、擋假 kid 的限流——這些雜事 keyfunc 全包了,而它們正是自己用 Lua 手刻時最容易出包的地 方。 HS256 · 對稱式金鑰 Gateway 得「持有」簽章密鑰 同一把密鑰既拿來簽、也拿來驗——等於把一把「能偽造任何 token」 的鑰匙，擺在最外緣的 gateway 上。 shared secret 簽 + 驗 同一把 不採用 RS256 + JWKS · 非對稱式 Kong 永遠只摸得到「公鑰」 私鑰只留在 AuthGate；Kong 從 JWKS 抓公鑰驗章——偷走公鑰也偽造 不出 token。 public key only AuthGate 簽 · Kong 驗 採用 ALG CONFUSION BLOCKED 演算法鎖死在 RS 家族 plugin 拒收 HS*，擋掉最經典的偽造手法：拿 RSA 公鑰當 HMAC 金鑰去簽 HS256。 安全關鍵 39
40. M A R K E T P L A C E · 細節流程 細看一次完整握手：從 401 到 200 以 Gitea MCP 為例——前段發現、中段授權，最後 Kong 驗章再轉發。 40 GET /mcp/gitea （no token ） 401 + WWW-Authenticate: resource_metadata GET /.well-known/oauth-protected-resource /mcp/gitea 200 Protected Resource Metadata Auth Code + PKCE （/authorize, /token ） RS256 access token fetch JWKS （cached / auto-rotated ） GET /mcp/gitea + Bearer JWT forward + X-MCP-Subject / X-MCP-Scope 200 200 ✓ MCP Client Kong + mcp-oauth2 AuthGate MCP Server verify ：sig(JWKS) + iss + aud + exp + scope
41. 41 R E A L I T Y C H E C K · M C P I N T H E E N T E R P R I S E 流水線、閘道、OAuth 都建好了—— 但現場是另一回事。 MCP 在企業內落地太難, 大家都往 Skills 走。 門檻就是門檻:不熟軟體流程的同仁,還是不懂怎麼建一個安全的 MCP Server——「寫一份 Markdown 就好」的 Skills,成了大家的出口。 所以—— 「MCP 已死」? 先別急 →
42. O U T L O O K · M C P × S K I L L S 「MCP 已死、Skills 取而代之」——這個說法很可能是錯的 企業內 MCP 落地確實辛苦——但兩者解的根本不是同一題:各做對了一件事,終局是融合,不是取代。 vs ! 先別急著把 MCP 下架——看清楚每一邊真正做對了什麼,再決定怎麼用。 THE CLAIM 「Skills 輕量好寫,MCP 該退場了」 Skills 一出,寫份 Markdown 就能教模型做事;對比之下 MCP 門檻高—— 不熟軟體流程的同仁,連一個安全的 MCP Server 都建不起來。 MCP IS DEAD? 社群上的熱門標題 流行的說法 THE REALITY 各做對一件事,缺的剛好是對方有的 MCP 在驗證(Auth)上領先,Skills 在引導與輕量化上勝出——接下來兩 頁分開看,再看怎麼合。 CONVERGE 融合, 而非取代 比較可能的現實 42
43. O U T L O O K · M C P 這一邊 MCP 做對的是 Auth——被罵的 Context 肥大,2026 已經解掉 最常見的批評:接太多 Server 之後,用不到的工具 schema 也塞滿 context window——但那是工程問題,而且已經被 lazy loading 修好,不是協議的死因。 vs ✓ Context 肥大已是修好的 bug——Tool Search 在工具佔比超過 10% context 時自動啟用;內建 Auth 才是別人一時補不上的 護城河。 AUTH · OAUTH 內建 使用者用「自己的身份」接服務 透過自己的帳號登入 Jira、GitHub、Monday 等 SaaS 不需要提供萬能的 靜態 API Token 對企業關鍵: 一般員工無法自行管理 API 金鑰 OAUTH 2.1 前面整個 Part 04 做的就是這件事 做對的事 CONTEXT BLOAT 工具一多,schema 塞爆 context 接多個 Server 後 所有工具說明全載入 ,用不到也吃掉大量 token 解法 lazy loading :開場只載輕量索引,需要時才抓工具 schema GitHub MCP 初始化從約 55,000 → ~1,000 tokens ,呼叫時才補載 已落地 · GA MCP Tool Search · 2026.01 GA · ~85% token↓ 已解 43
44. O U T L O O K · S K I L L S 這一邊 Skills 做對的是引導與輕量——但 Auth 是硬傷 Skills 給模型「怎麼用工具的步驟說明」,而且只載精簡 metadata——可是一放進企業環境,馬上撞牆。 vs ! Skills 解了「會不會用」,沒解「能不能安全地連」——而後者正是 MCP 的主場。 GUIDANCE · 輕量 教模型「怎麼做」,而不是丟一堆工具 附上使用步驟與流程說明, 模型不用自己摸索 只傳精簡描述與 metadata, 不會肥大 context MARKDOWN 寫一份文件就能上線 做對的事 三個硬傷 沒有 Auth、會過時、難窮舉 沒有內建 Auth ——多數要全域 API Key,對非開發者幾乎不可行 本質仍是技術文件—— 文件一出就開始過時 工具多、場景複雜時,難為每個情境寫完整說明 NO AUTH 在企業環境, 這是致命傷 未解的題 44
45. O U T L O O K · 未來走向 終局不是誰取代誰——Skills 管知識,MCP 管連線 兩邊都在往對方的優勢補課,最佳解是一起搭配使用。 MCP 已補上 · LAZY LOADING Tool Search 已 GA(2026.01) 需要時才載入工具 schema,context 肥大已從根本解 掉。 SKILLS 補課 · NATIVE OAUTH 加入原生 OAuth 支援 讓 Skill 也能以使用者身份安全連 SaaS,擺脫全域 API Key。 一句話:MCP 贏在 Auth,Skills 贏在引導——最佳解是整合,不是取代。 MCP × SKILLS BETTER TOGETHER Skills 給說明,MCP 給連線 Skills 提供使用知識與流程;MCP 負責安全連線與驗證 ——互補共存。 搭配方式 45
46. 46 T H A N K Y O U · D E V O P S D A Y S T A I P E I 2 0 2 6 感謝各位參與聆聽 人幫 AI 建 DevOps,已是日常——歡迎一起把它做得更好。 appleboy · 後端架構工程師　· 　Q & A