工作成果與效益摘要

Criz的AI使用方式

以四個方向建立可重用的 AI 工作能力：共用平台、Debug Agent、標準化工作流、維運實務與分享。

簡任伸 Criz Chien · 2026.10.06

四大分類、主要成果與效益

分類主要成果對團隊的效益對公司的價值
1. AI Agent
共用平台		因應一次性 Debug 所需的獨立調查脈絡，設計 Oberon，提供 Agent 接入與部署機制。每起調查從乾淨脈絡開始。
避免沿用多人共用對話的假設，並共用平台基礎能力。		補足既有 AI 助手的場景缺口。
以共用平台支援任務型 Agent，擴充 AI 應用範圍。
2. AI Debug
Agent 建置		建立 Lift／Opicon Debug Agent，訓練調查 Skill、接入資料與查詢權限，並以實際案例反覆驗證。把 Debug 經驗變成可用能力。
依既定方法跨來源取證，產出可檢查的調查結論。		將專案診斷知識資產化。
累積可重用的調查方法，支援故障定位與問題交接。
3. 開發工作流
與知識資產		建立 dev-workflow、JIRA 建單等 Skill，並以 AI-native repo 保留知識、規範與協作脈絡。讓工作有規範、知識可交接。
重複任務沿用既有方法，新工作承接累積經驗。		把工作方法轉為可重用資產。
降低對個人記憶的依賴，支援後續維護與經驗傳承。
4. SRE 應用
與對外分享		將 EKS 升級經驗整理成 8 個 Skill，納入風險評估、人工確認與驗證，並於 KubeSummit 分享。公開案例：30 座 EKS、180 次正式環境升級。讓複雜維運有可遵循的方法。
以分階段檢查與確認點支援操作，供後續升級重用。		將維運經驗資產化，展現實務能力。
形成可傳承的方法，並透過公開分享呈現 AI 落地經驗。

平台設計原因

為什麼需要 Oberon：讓 Debug 有獨立、乾淨的調查脈絡

公司既有的 Genisys（小蝦），使用模式比較接近 OpenClaw：保留記憶，並在同一個 session 中服務多人。這適合持續性的助手與共同協作，但 Debug 通常是針對一個問題的一次性調查，需要從本次任務的事實出發，不應沿用其他人或前一個問題留下的判斷。

因此，我開發 Oberon，讓任務型 Agent 可以在共用平台上運作，並以新的 session 開始每起獨立調查。可重用的是專案知識與調查方法；不應混用的是不同事件的對話、暫時假設與結論。

比較面向Genisys／小蝦的既有使用模式Oberon 支援的 Debug 使用方式
使用目的保留記憶的持續性助手，承接多人互動。聚焦本次問題，取得證據並交付調查結果。
調查脈絡同一個 session 累積多人對話與記憶。不同事件使用新的 session；同一事件才延續原有脈絡。
知識如何重用延續助手既有的互動記憶。載入明確的專案知識與 Skill，再查本次事件的資料。

兩者是互補，而不是替代：小蝦承接持續互動；Oberon 補上需要獨立調查脈絡、專案工具與明確工作範圍的 Agent 場景。

AI Debug Agent 建置

我如何把 Debug 經驗，轉成 Lift／Opicon 的 Agent 能力

不是只給 AI 一句「幫我 Debug」，而是讓它知道專案背景、遵循調查方法、取得必要資料，並以真實案例檢查結果。這裡的 Skill 訓練，是反覆修正調查步驟、工具使用與報告規範，讓 Agent 的行為更符合實務需要。

從工作經驗到可使用 Agent 的五個步驟

  1. 先定義要解決的問題：Lift 聚焦 pipeline、建置與 VM 生命週期等平台問題；Opicon 聚焦 L2 測試失敗、失敗服務與原因。先界定任務，避免變成什麼都做的通用助手。
  2. 把調查經驗整理成 Skill：將「先理解現況、讀取正確版本、收集證據、交叉核對、最後報告」寫成方法；規定何時深入調查、什麼算證據，以及資料不足時如何交接。
  3. 接入工具與相關權限：依專案需求接上程式碼、pipeline、報告、日誌及基礎設施查詢。為需要身分的工具配置帳號、角色與憑證，並限制調查用途，不只在 prompt 裡要求 AI 小心。
  4. 用實際案例反覆驗證：檢查 Agent 實際查了什麼、是否漏掉案例、是否把症狀誤當根因；根據錯誤修正 Skill、Agent 指令或工具，再用相同問題重跑。
  5. 部署後確認並持續改善：將方法與工具接入 Oberon，確認 Agent 真正載入新 Skill、所需資料實際可讀；每起新調查使用新的 session，再把結果回饋到方法與知識。

串接關係：專案經驗 → 調查 Skill → 工具與權限 → 案例驗證 → Oberon 上的 Debug Agent → 使用回饋與下一輪改善。

Lift 與 Opicon：方法相同，接入資料不同

Agent調查能力與資料接入權限與交接界線
Lift Debug讀取 Jenkins 設定、build 資訊與日誌，對照實際執行的程式版本與專案指南；需要時查詢 VMware VM 或 AWS 資源現況。診斷工具以唯讀取證為主。需要修改時提出人工處理步驟；Kubernetes 查詢仍有權限缺口，不能假裝已查過。
Opicon Debug盤點全部失敗案例，對照本次 build 的測試程式、測試端與後端日誌；必要時使用產品知識查詢與 AWS 診斷能力，判斷問題位於哪一層。不更動被測系統；測試程式透過必要的讀取角色取得，AWS 診斷有唯讀護欄。資料缺失或無權限時明確標示，不能推定為沒有問題。

Skill 如何被「訓練」得更實用

實際遇到的問題我如何修正形成的工作能力
簡單問題也被當成完整 DebugLift 原先查一個資源狀態也會追問 shard、build。調整成先判斷「直接查詢／深入調查」，只在需要時載入調查 Skill，並以實際查詢驗證。簡單問題直接回答，複雜問題才展開完整調查，避免不必要的問答。
合併報告後，部分失敗未逐一取證Opicon 改成每個失敗案例都必須有自己的證據錨點；使用同一份失敗報告反覆驗證，不只相信 Agent 自稱「已查證」。根因可以合併說明，但每個案例的歸因仍可被核對；無法歸因的項目必須留下。

調查所需的權限是工具對資料來源的存取能力，不等同於平台已完成使用者身分驗證或逐人授權。接入後仍需驗證可讀範圍與限制。

工作方式的整合

四大方向如何串成完整工作流

以下是我將現有工具、平台與實作整合後的工作方式。不同任務會走不同分支：簡單查詢可以直接回答；功能開發進入開發流程；故障與升級則進入診斷或維運流程，不必每次經過全部步驟。

  1. 01整理需求目標與工作紀錄
  2. 02取得脈絡知識與現況
  3. 03規劃方案步驟與確認點
  4. 04協作執行程式或操作結果
  5. 05審查驗證品質與驗收
  6. 06交付與應用平台與維運
  7. 07沉澱與分享可重用資產
人工確認貫穿全程：需求取捨、方案核准、重要寫入、正式環境變更與最終驗收，由人掌握；AI 協助工作，不把「有輸出」當成「已完成」。

03 / INPUTS, OUTPUTS & HANDOFFS

每一步做什麼，結果如何交給下一步

01

把工作需求整理成可執行的目標

我先說明要解決的問題與期待結果，讓 AI 協助整理需求、補足必要資訊；需要追蹤的工作則轉成 JIRA issue，讓任務有明確範圍與紀錄。

輸入
功能需求、故障現象、升級目標或日常工作。
產出
清楚的任務描述、預期結果；需要時建立工作單與分類。
我的判斷
決定優先順序與範圍，確認後才建立或變更工作紀錄。

接到下一步：以同一個任務目標查找資料，避免 AI 解錯問題。

支援工具：create-jira-issue、工作紀錄工具、需求討論與 prompt 整理。

02

讓 AI 先取得知識與現況，而不是憑空作答

我把專案文件、既有決策、操作指南與工作紀錄作為背景；需要調查時，再取得測試報告、日誌或環境資訊，區分已知事實與尚待確認的問題。

輸入
任務目標、repo 知識庫、團隊文件與相關工作資料。
產出
現況整理、可引用的依據、問題原因或待驗證假設。
我的判斷
確認資料是否足夠、是否需要深入調查；不把推測直接當成結論。

接到下一步：把查到的限制與依據納入方案，避免重複踩坑。

支援工具：知識庫查詢、Confluence、專案 Skill、AI-native repo 知識庫、診斷工具。

03

把目標與背景轉成有確認點的方案

開發工作透過 dev-workflow 整理需求與設計，再進入實作；維運工作則透過對應 Skill 先盤點、研究風險與安排操作順序。工作大小不同，採用的流程也不同。

輸入
任務目標、專案背景、現況與風險。
產出
設計或操作方案、預計改動範圍、驗收方式與人工確認點。
我的判斷
選擇方案、調整範圍，決定哪些工作可以交給 AI、哪些需先停下確認。

接到下一步：AI 依已確認的方案工作，而不是邊執行邊擴大任務。

支援工具：dev-workflow、方案討論、EKS 升級評估、專案操作指南。

04

讓 AI 按方法執行，並保留工作脈絡

我讓 AI 在既有規範下協助修改程式、建立 pipeline、分析報告或執行已核准的操作。任務會使用適合的工具與資料；重複性的流程則交給 Skill 或 Agent 承接。

輸入
已確認的方案、必要權限、相關程式與操作資源。
產出
程式與設定改動、產生的文件、診斷結果或操作紀錄。
我的判斷
處理需求變化及風險；不讓 AI 自行決定敏感或不可逆的變更。

接到下一步：交出可檢查的改動與證據，而不只是一段完成說明。

支援工具：開發與 pipeline Skill、Agent、工具連接、操作腳本、專案工作紀錄。

05

審查與驗證，把 AI 產出變成可交付結果

我用 code review、既有驗證流程及實際執行結果檢查產出；Oberon 也配置了多模型 PR 審查與變更驗證機制。發現問題就回到實作或規劃，不以 AI 的自我宣告作為驗收。

輸入
改動內容、驗收條件、審查意見與執行結果。
產出
已核對的結果、需修正項目，以及可供人決策的證據。
我的判斷
判斷是否達到目標；自動審查失敗時由人工或其他檢查補足，不視為通過。

接到下一步：只有經確認的成果才進入交付或下一輪正式操作。

支援工具：多模型 review、PR 流程、變更驗證、預覽環境、升級後檢查。

06

依工作類型，交付成果或形成可呼叫的能力

一般開發交付程式、文件或工作結果；值得重用的 Agent 則透過 Oberon 接入共用平台。SRE 場景依核准步驟完成變更或提出診斷結論，並持續觀察實際結果。

輸入
已確認的成果、Agent 接入設定或核准的維運變更。
產出
可使用的工作成果、Agent 部署設定、維運結果及觀察紀錄。
我的判斷
確認適用範圍、操作權限與風險；是否交付不只看部署或執行狀態。

接到下一步：把使用過程與問題一併回收，作為改善的材料。

支援工具：Oberon、Agent 接入機制、平台部署流程、SRE Skill、結果回傳與觀察。

07

把一次工作的經驗，轉成下一次可以重用的資產

我將架構理解、設計理由、故障原因及操作經驗整理回知識庫；穩定且反覆出現的工作方法再封裝成 Skill，供後續自己或其他人使用。需要溝通的成果則整理成文件、簡報與對外分享。

輸入
實際結果、審查意見、已驗證的處理方法與尚未解決的問題。
產出
更新的知識與 Skill、操作指南、工作紀錄、分享材料。
我的判斷
決定哪些經驗值得保留，核對內容是否仍符合現況，再推廣可重用的方法。

回到下一輪：新的任務先沿用累積的背景與方法，再依實際情境調整；不是每次從零開始。

支援工具：repo 知識庫、知識發布、Skill 發布與版本管理、知識整理工作流、HTML 簡報與分享。

04 / HOW THE PARTS CONNECT

串接的關鍵是「交接內容」，不是把所有工具強制自動連起來

開發工作流用來建立與改善能力；Debug Skill 定義調查方法，工具與權限讓 Agent 取得實際證據；Oberon 則提供接入與獨立任務的對話脈絡。維運與使用結果再回到知識與 Skill，形成下一輪改善。

組成部分負責什麼如何接上其他部分
需求與工作紀錄保存目標、範圍及需追蹤的工作。成為查資料、規劃與驗收的共同依據；JIRA 不是單純建單，而是讓工作有可交接的描述。
知識庫保存專案背景、決策、SOP 與經驗。提供 Skill 與 Agent 執行時需要的脈絡；工作完成後再把新發現寫回，供下一輪使用。
Skill把一種工作的方法、步驟與確認規則整理成可重用流程。將專案經驗整理為調查方法，透過實際案例驗證與修正，再交由 AI 助手或專案 Agent 使用。
工具與權限取得真實資料、執行必要動作並回報結果。依任務接入資料來源與存取身分。Debug 以唯讀取證為主；資料不可讀時交接缺口，不以猜測補足。
Debug Agent 與 Oberon將專案方法、工具與權限組合成可使用的調查能力。Oberon 提供接入、分派與結果回傳；不同事件使用新的 session，避免混用前一個問題或其他人的調查脈絡。
AI-native repo讓開發工作有持續的脈絡、規範與審查。平台與 Agent 的修改沿用 repo 知識與開發流程；完成後同步更新紀錄，讓後續 AI 協作承接既有理解。
文件與對外分享把經驗整理成他人能理解與使用的方法。從操作紀錄與已驗證的案例形成指南或簡報；分享之後的問題與回饋再成為改善知識、Skill 與平台的材料。

05 / THE WORKFLOW IN PRACTICE

三個工作案例，看同一套方法如何落地

案例 A｜開發或改善一項平台能力

開發 → 驗證 → 知識累積

以 Oberon 的開發方式為例，AI 同時參與「打造平台」與「整理打造平台的經驗」。

  1. 整理需求：先確定功能目標與工作範圍，需要追蹤時建立 JIRA 工作紀錄。
  2. 取得背景與規劃：讀取 repo 中的架構、既有決策和未解問題，再依 dev-workflow 討論設計。
  3. 協作實作：按照檔案規範修改程式與部署設定，將改動交到 PR 流程。
  4. 審查與驗證：結合 AI 審查、變更檢查及適用的預覽環境驗證，再由人判斷能否交付。
  5. 保留經驗：把新的決策、限制與處理方式整理回 repo 知識庫，讓下一次工作承接這次成果。

可確認的交付：Oberon 已有自訂 Agent 接入機制、接入範例、平台服務與部署設定，以及支援 AI 協作的 repo 結構。價值在於同時建立應用能力與後續維護所需的知識。

案例 B｜處理測試失敗或平台異常

調查 → 判讀 → 處理依據

Lift 與 Opicon 的 Agent 帶著已訓練的調查 Skill 與必要的查詢工具，在新的 session 中處理本次事件；一般查詢與深入調查分開。

  1. 先判斷問題類型：簡單事實查詢直接取得資料；原因不明的故障才進入診斷方法。
  2. 結合背景與證據：讀取專案知識，使用已接入的權限查詢 pipeline、測試報告、相關程式與日誌；對照這次真正執行的版本。
  3. 形成可檢查的結論：整理失敗現象、關聯元件與原因依據；Opicon 每個失敗案例都要有交代，無法歸因時明確標示。
  4. 決定後續動作：根據結果選擇進一步調查、建立修正工作或提出處理方案；Debug Agent 不自行變更被調查系統。
  5. 回饋方法：把錯誤判斷、漏查與權限缺口回饋到 Skill 或工具，重新驗證後供下一次調查沿用。

形成的能力：專案知識、調查方法與資料存取不再分散使用，而是組合成 Lift／Opicon Debug Agent，提供有證據、可交接的問題分析。

案例 C｜EKS 升級，從操作經驗走到對外分享

評估 → 確認 → 升級 → 經驗重用

EKS Upgrade Toolkit 將維運方法整理成 8 個 Skill，涵蓋準備、升級、節點遷移、元件評估及驗證。

  1. 升級前先評估：盤點版本與環境，研究已知問題、相容性及升級風險，讓操作前有決策依據。
  2. 按階段執行：依流程完成備份、叢集與元件升級，以及新舊節點切換，不把複雜任務當成單一指令。
  3. 關鍵動作先確認：重要變更由人核准；AI 與腳本依已確認步驟協助執行。
  4. 驗證與觀察：確認變更結果並保留觀察時間；將問題與處理方式寫回 Skill，改善後續升級。
  5. 整理並分享：把正式環境的經驗與人工確認方法，整理成 KubeSummit 的實務分享。

可確認的交付：8 個 EKS 升級 Skill 與操作腳本，以及 KubeSummit 公開分享。這個案例呈現了完整閉環：實務操作產生經驗，經驗變成工具，工具再支援後續工作。

KubeSummit 2026 · 實務分享

30座EKS, 180次升級淬煉的EKS Upgrade Skill 的歷程

2026 年 9 月 10 日，我在 KubeSummit 分享如何將 EKS 升級 Runbook 轉為 AI 可執行的 Skill，以及如何在自動化與人工確認之間設定安全界線。

30EKS 叢集
15AWS 帳號
13Region
180正式環境升級

案例規模來源：KubeSummit 官方議程。

官方議程與分享內容 · 講者頁

06 / COVERAGE ACROSS MY WORK

不只開發與 SRE，也涵蓋測試、協作、知識與溝通

以工作場景看，這套方法可以容納目前查閱到的主要應用。不同工具負責不同段落，共用的是「先取得背景、按方法執行、檢查結果、再累積經驗」的工作原則。

工作面AI 如何參與串接位置與相關能力
平台工程協助平台實作，並把特定 Agent 能力接入共用環境。開發、驗證與交付：Oberon、自訂 Agent 接入、平台部署。
Debug Agent 建置整理專案調查經驗、訓練 Skill，接入工具與查詢權限，再以實際案例檢查與改善。能力建立與回饋：Lift／Opicon Debug Skill、診斷工具、Oberon。
開發與品質整理需求與設計、協助實作、提供審查意見與改動驗證。需求到驗收：dev-workflow、多模型 review、AI-native repo。
測試與自動化協助建立測試 pipeline、提交與查詢測試、分析失敗報告，或整理壓力測試參數。實作到診斷：Lift pipeline、Opicon 操作與分析、AXE 測試工具。
SRE 與環境維運盤點環境、整理風險、診斷異常，並依確認步驟協助升級與變更。調查、操作與驗證：EKS Toolkit、Lift 診斷與專案維運 Skill。
工作與 release 協作將需求轉為工作單；相關工具也涵蓋 release readiness、分派檢查、新平台支援追蹤及 staging 資料更新。需求、追蹤與交付：JIRA 建單、release 與平台支援工作流。
知識管理查詢專案背景、整理工作經驗，讓文件與方法能被下一輪 AI 協作沿用。取得背景與回饋：團隊知識庫、專案指南、決策與工作紀錄。
文件與對外分享將結果與實務經驗整理成文件、HTML 簡報或圖像素材，支援說明與推廣。沉澱與分享：文件生成工具、簡報工具、KubeSummit 案例。

07 / HUMAN JUDGMENT, AI ASSISTANCE

我不是退出流程，而是把精力放在判斷與驗收

AI 承接的工作

  • 整理需求、查找知識、盤點資料與現況。
  • 依既有規範協助實作、分析、產生文件與執行核准步驟。
  • 彙整結果、提出審查意見與待驗證問題。
  • 把可重用的方法與經驗整理成後續工作的材料。

我保留的責任

  • 決定要解決的問題、工作範圍與優先順序。
  • 選擇方案，核准重要寫入與正式環境變更。
  • 核對依據、觀察結果，判斷是否真正完成。
  • 決定哪些方法值得標準化、接入平台與推廣。

例如：EKS 升級前，AI 可以整理環境狀態與風險；是否進行不可回復的控制平面升級，仍需人工確認。PR 的自動審查未完成，也不能因工作狀態顯示成功就當成已審查。

08 / DELIVERABLES & VALUE

成果不是更多 AI 對話，而是留下可持續使用的工作能力

我運用 AI 的方式，是把一次性的協助逐步轉為
有脈絡、有方法、有驗證、可重用的工作流。

目前已形成的成果包括：因應獨立調查需求的 Oberon 平台、結合調查 Skill 與工具權限的 Lift／Opicon Debug Agent、標準化開發及工作協作 Skill、AI-native repo 知識結構、EKS 升級 Toolkit，以及以正式環境經驗為基礎的對外分享。

讓工作可交接

目標、背景、改動與結果有紀錄，減少只靠單次對話或個人記憶承接工作。

讓方法可重用

把重複的流程與經驗整理成 Skill 或 Agent，不必每次重新說明整套做法。

讓能力可擴充

以共用平台與知識支援新的工作場景，再用實務回饋持續改善。

APPENDIX / EVIDENCE & READING BOUNDARIES

資料依據與閱讀界線

資料來源為五個 repo 的遠端 main、相關提交與執行紀錄，以及 KubeSummit 官方頁面。Genisys／小蝦的使用模式與 Oberon 設計動機，依 Criz 提供的實務背景整理。

Oberon平台架構、Agent 接入、診斷應用、AI-native 知識庫與協作工作流。
barbarians-claude-skills開發工作流、專案知識、pipeline 建立、測試及 release 協作。
barbarian-ai知識查詢與發布、開發工具、新平台支援及 staging 工作流。
criz-claude-skillJIRA 建單、開發輔助、工作紀錄、文件與分享素材工具。
EKS Upgrade Toolkit8 個 EKS 升級 Skill、操作腳本與人工確認原則。
KubeSummit 官方議程演講主題、日期、實務規模與分享重點。
Oberon 任務與 session 設計新對話建立獨立 session，同一事件可續接既有脈絡；並非每個 session 建立獨立容器。
Lift Debug 方法調查步驟、工具對應、唯讀診斷與人工交接。
Opicon Debug 方法案例盤點、證據核對、測試與產品來源，以及未歸因項目的處理。
Lift Skill 修正與驗證紀錄一般查詢與調查分流，並以實際 Agent 呼叫驗證。
Opicon Skill 修正與驗證紀錄每個失敗案例的證據錨點，以及同一案例的反覆驗證。

存取界線：Lift 的 Kubernetes 查詢仍有權限缺口；平台 API 的使用者驗證與逐人授權尚未完成。診斷工具已接入的查詢身分，不代表所有資料來源或使用者權限都已涵蓋。

尚不能寫成已完成或已量測的部分