Devops

📅 活動時間：2026-10-29 📊 投影片：Platform Engineering 的 AI 實際落地案例 📘 聯繫我 Facebook Title Platform Engineering 的 AI 實際落地案例 Outline AI 導入 Platform Engineering 真正困難的是：如何把 AI 放進工程師每天使用的 platform、workflow 與 operation 中，同時維持權限、安全、可觀測性與可維運性。 這場分享從實際工程案例出發，說明 AI 如何協助平台團隊處理重複性工作、跨系統整合與知識分散問題，也會討論哪些工作適合交給 AI，哪些工作仍然需要明確的程式流程與人工決策。 在 AI 時代，所有規格固定的工作流程都該 100% 自動化。當輸入、處理方式與輸出都可以被清楚定義，就不應該繼續依賴人工重複操作；Platform Engineering 的價值，就是把這些流程轉成可靠、可驗證、可持續維護的 automation。 Platform Engineering 為什麼需要 AI AI 如何進入 developer platform 與內部工具 案例一：用 AI 降低平台維運成本 案例二：用 AI 整合跨系統的工程流程 案例三：用 AI 建立可追蹤、可評估的 automation workflow 從 Vibe Coding、Coding Agent 到 AI Platform 的技術選擇 權限、資料安全、成本與治理的實務限制 Target group 負責 Developer Platform、Internal Developer Platform 或 DevOps tooling 的工程師 正在評估 AI automation、AIOps 或 Coding Agent 的平台與 SRE 團隊 想把 AI 導入工程流程、但關心安全性與長期維運成本的技術主管 主要收穫 你將能從 Platform Engineering 的角度理解 AI 的實際使用情境，辨識適合自動化與不適合交給 LLM 的工作，並學會從需求範圍、系統複雜度、權限風險與維運成本出發，選擇合適的 AI workflow。 ...

📅 活動時間：2026-10-15 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title AI Gateway：AI 治理的第一步 Outline 當團隊開始使用多個 LLM provider 與模型，API Key、模型路由、成本控管、權限與 tracing 很快就會分散在各個應用程式中。AI Gateway 提供一個統一入口，讓團隊能集中管理模型存取與應用流量，也讓後續的觀測、評估與治理更容易落地。 本次分享將從實務問題出發，介紹 AI Gateway 的核心能力與導入方式，並討論它能解決什麼、不能解決什麼，以及如何與 observability、evaluation 和 AI application workflow 整合。 為什麼團隊需要 AI Gateway 統一模型存取、路由與 fallback API Key、權限與成本治理 串接 tracing、logging 與 LLM observability 以實務情境設計 AI Gateway workflow 導入限制、風險與後續演進 Target group 正在導入 LLM 或 AI application 的後端與平台工程師 負責 API、雲端基礎設施與開發維運的 DevOps / SRE 想建立模型治理、成本控管與 observability 的技術主管與架構師 主要收穫 你將能理解 AI Gateway 在 LLM application architecture 中的角色，掌握模型路由、權限、成本與 tracing 的基本設計，並具備評估團隊是否適合導入 AI Gateway 的實務判斷依據。 ...

規格驅動的 AI 強化 DevOps 演講逐字稿 開場 今天要分享的主題是「規格驅動的 AI 強化 DevOps」，副標是「篩選適合的情境，SDD 成為你的平台開發神器」。我是 Che-Chia Chang。 議程概述 在這場議程中，我會告訴各位三個重點： 第一，Spec-kit 跑起來是什麼樣子。我會用實際的例子展示工作流程。 第二，我會提供四個實務情境，說明哪些任務適合 SDD，哪些不適合。 第三，Spec-kit 帶來的代價是什麼，以及我們如何應對。 情境 1：跨平台，稽核內部平台帳號 讓我們從第一個情境開始。在許多企業中，都有一個共同的痛點：所有內部帳號需要定期稽核，確保沒有過期離職的帳號存在。 面對這類需求，有幾個重要的考量： 首先，如果有現成工具就直接用工具，不用閉門造車。但如果現成工具需求不符合，用 AI 閉門造車現在非常的快又便宜。 但這裡出現了一個大哉問——後續維護是否好維護？這個疑問很關鍵。 實際 Spec-kit 工作流程展示 讓我們看一下，實際的 Spec-kit 會長怎樣。假設我們在 VSCode Chat（Copilot）中啟用 spec-kit，流程會是這樣： 第一步：產生 Spec 使用 /speckit.specify 命令，我們描述需求： 寫一個工具，列出所有內部平台帳號 工具需要根據條件檢查帳號狀態與權限 包含單元測試，模擬帳號的整合測試 還要有 e2e 測試，產出符合稽核格式的結果 第二步：釐清 Spec 然後使用 /speckit.clarify 命令，不斷釐清模糊的地方，直到沒有歧義： 平台包含 AWS、GitHub、Jenkins 等 帳號狀態包含 active、expired、pending 權限包含 admin、write、read-only 這個過程非常重要，因為清楚的規格是後續成功的基礎。 第三步：規劃實作 使用 /speckit.plan 根據 Spec 產生 Plan，列出實作步驟，檢查相依性，準備 checklist。 ...

📅 活動時間：2026-08-09 🔗 活動連結 📘 聯繫我 Facebook 📑 投影片 Title Observe and evaluate LLM Coding Agents Outline 在導入 LLM Coding Agent 到日常開發後，很多團隊會遇到問題：品質不穩、風險難估、模型升級缺少客觀依據。本分享會從實務流程出發，介紹如何觀測 Agent 行為、把評估流程自動化，並建立可持續迭代的 decision system。 為什麼 LLM Coding Agent 需要 O11y 與 Evaluation 從 trace 開始：觀測 agent 任務、工具調用與失敗模式 Observability != Decision System：看得到不代表能決策 LLM-as-a-judge 在 coding 任務中的價值與限制 從 daily coding logs 抽取 dataset 建立 regression evaluation pipeline 與 quality gate 用量化結果比較不同模型與 agent framework 把模型升級與框架切換變成可驗證工程流程 Demo & POC https://github.com/chechiachang/llm-o11y Trace and observe local coding agents Build coding-task evals with LLM-as-a-judge Extract datasets from real developer-agent interactions Run regression tests for model / framework change decisions Target group 正在導入 AI coding workflow 的工程團隊 關心品質、成本、延遲與回歸風險的 Tech Lead / SRE / Platform Team 已有 tracing / logging，但缺少可執行評估與 deployment gate 的團隊 Slides 完整投影片與講稿 Author Che-Chia Chang 是一名專注於後端開發、開發維運、容器化應用及 Kubernetes 開發與管理的技術專家，同時也是 Microsoft 最有價值專業人士（MVP）。 ...

活動時間：2026-07-01 12:00-12:30 活動連結 聯繫我 Facebook 投影片 Title When Not to Vibe 從 Vibe Coding 到 Spec-driven AI Engineering Outline AI 讓「寫 code」變得容易，但實際在開發上，常見現象是一開始很順、越做越亂，LLM 逐步偏離設計，context 越長結果反而越不準。這不是 prompt 不夠強或模型不夠大，而是 LLM 本質上不擅長長時間、持續演進的任務。vibe coding 適合快速探索小範圍任務與短期 context，但長任務會走向失焦（loss of alignment）；context window 也不是越大越好，資訊堆疊會造成 attention 稀釋，且 LLM 沒有真正長期記憶。 這場分享現實：AI 讓寫 code 變快，卻不保證長時間任務不失焦；為何 vibe coding 會在 context 拉長後 drift。並以 SpecKit 補上的結構化上下文價值、並了解其代價，以及從 spec-driven 走向 agent-driven 的實務經驗。 從 Vibe 出發：為何 LLM 在長時間任務中逐漸失焦 LLM 原理：Context 不斷堆疊，為何反而降低準確性 SpecKit 的價值：從 Prompt Chaos 到 Structured Spec 作為 Source of Truth 現實限制：Spec Tax、Drift，以及無法解決的痛點 SDD（Spec-driven Development）適用場景：PoC、Greenfield 等 從 Spec-driven 到 Agent-driven：Speckit 作為過渡形態 你將能清楚辨識 vibe coding 的有效範圍與失效訊號、理解 LLM 在長上下文下準確率下降的原因、評估 SpecKit 在實務上的收益與成本，並帶走一套可用於 PoC、Greenfield 與複雜系統規劃的導入與決策視角。 ...