OpsWiki Agent 年度導入專案企劃書
1 專案摘要與目標 (Executive Summary & Goals)
本專案旨在透過生成式人工智慧技術，建構專屬於企業維運體系的「OpsWiki Agent」。專案核心願景為打破既有系統知識孤島，將靜態文件轉化為具備互動問答、智能檢索與流程引導能力的動態知識引擎，進而大幅提升第一線支援團隊的障礙排除效率。
1.1 總體目標與實施範圍
- 總體目標： 於專案啟動後六個月內，完成「OpsWiki Agent」的核心技術驗證與架構優化，並將其從開發環境（Development）正式推向生產環境（Production）。
- 初期導入範圍： 評估跨部門影響力與系統重要性後，將挑選三個核心部門，各選定一套關鍵系統作為「先鋒系統（Pioneer Systems）」，進行完整資料清理、模型對接並正式上線。
- 次階段推廣範圍： 針對其餘系統，將視現有專案團隊人力頻寬，以及 GitHub Copilot 與 Microsoft Studio Copilot 的企業授權資源分配狀況，分批次啟動前期導入作業（包含文件標準化與資料盤點）。
1.2 核心應用場景
場景一：L1 救援自動化
當第一線支援人員（L1）遭遇系統異常事件時，OpsWiki Agent 將自動檢索 L2 的歷史處理紀錄與知識庫（KB），快速提取並提供精確、可操作的解決步驟，減少對 L2 團隊的依賴。
場景二：SOP 智能查詢
人員可透過自然語言（Natural Language）快速調閱繁複的系統維運手冊、職務輪替指引等標準作業程序（SOP）。系統將直接回覆精華摘要與操作指令，大幅降低傳統關鍵字搜尋的時間成本。
2 基準線評估 (Baseline Assessment)
為確保專案成效可被客觀衡量，本專案將在第一階段初期嚴格執行基準線（Baseline）量測。此評估將聚焦於維運效率與人力資源消耗，作為第六個月專案結案時的比較基準。
| 評估指標 (Metrics) | 測量定義與計算方式 | 預期改善目標 |
|---|---|---|
| MTTR (Mean Time To Recovery) |
L1/L2 接收到異常通報至服務恢復正常的時間總和 ÷ 總異常事件數。（聚焦於常見已知問題） | 縮短 25% - 30% |
| L2 升級率 (Escalation Rate) |
L1 無法自行排除，必須轉交給 L2 團隊處理的案件數量 ÷ 總案件量。 | 降低 20% |
| 單件處理工時 (Average Handling Time) |
人員從開始檢索 SOP/文件到確認解決方案所耗費的平均時間。 | 單次檢索耗時低於 30 秒 |
3 資料來源與問題分析 (Data Sources & Technical Analysis)
3.1 資料來源盤點
- 官方操作文件與 SOP： 現有各單位的標準作業程序。前提是必須先行盤點並確認版本正確性（Version Control Audit）。
- Source Code AI 生成文件： 透過 AI 工具對既有原始碼進行反向工程（Reverse Engineering）產出的技術說明文件。
- 歷史處理紀錄（Use Cases）： 自工單系統（Ticketing System）日常持續收集的真實問題解決紀錄。
3.2 技術與推廣挑戰分析
挑戰一：知識庫品質與 RAG 解析限制
Technical Issue問題描述： 檢索增強生成（RAG）架構極易受到來源文件格式影響，產生 AI 幻覺（Hallucination）。技術實證指出，MS Studio Copilot 與 SharePoint 內建解析器在處理 Markdown 檔案時（特別是包含複雜 Table 與 Flow Chart 的語法），經常發生抽象語法樹（AST）解析失敗，導致 RAG 發生斷點異常，無法召回完整內容。
挑戰二：各單位導入摩擦力 (Adoption Friction)
Process Issue問題描述： 各單位技術棧與文件格式破碎化。目前程式碼生成文件強烈依賴特定環境（需安裝 VS Code、GitHub Copilot、Node.js，並透過 npm 下載公版 Git 模板），過高的技術門檻導致非技術單位或傳統維運部門抗拒導入。
4 執行時程與行動方案 (Execution Roadmap)
前置作業（Prerequisites）
在正式啟動各階段工作前，參與人員須確認已完成以下環境準備，以確保協作流程順暢。
安裝 VS Code
需於本機安裝 Visual Studio Code，作為文件編寫、程式碼審閱及 Copilot 整合的主要 IDE 環境。
擁有 GitHub Copilot 帳號
需具備有效的 GitHub Copilot 企業授權帳號，用於 AI 輔助文件生成、程式碼分析等核心作業。
建議參與角色：本前置作業主要由 系統架構師（SA） 或 程式設計師（PG） 負責確認與協助各單位完成環境建置。
第一階段：文件標準化與原型驗證
第 1 - 2 個月負責人：System Architect (SA), Programmer (PG)
- 建立文件導入模板： 定義 Markdown / PDF / Word 轉換的標準作業規範，開發並實作上述的 Pandoc 自動化轉檔工具。
- 試產驗證： 從三個核心單位各挑選一套小型既有系統，進行標準化文件試產與盤點。
- 基準線確立： 盤點現有系統的 L1/L2 處理時間（MTTR）與升級率，確立成效比較的 Baseline。
第二階段：Agent 對接與封測試運行
第 3 - 4 個月負責人：System Admin, Support Team, SA
- Agent 建置： 於 Microsoft Studio 環境中，建置該三個單位先鋒系統的專屬 Copilot Agent。
- 封測運行： 開放內部 System Admin 與第一線 Support 團隊進行初步試用（Closed Beta）。
- 最佳化調整： 建立反饋迴圈，收集 RAG 檢索失敗或發生 AI 幻覺的實際案例，針對 System Prompt 與源頭文件結構進行迭代優化。
第三階段：正式上線與指標追蹤
第 5 - 6 個月負責人：Project Management Team
- 跨部門推廣： 舉辦 Adoption Workshop，分享先鋒系統的成功經驗，並發布其他系統導入的標準 SOP。
- 正式上線 (Go-Live)： Agent 進入 Production 環境。
- 效益評估： 收集實際問答數據與工單系統資料，對比第一階段建立的基準線，產出正式的投資回報（ROI）與效益評估報告。
5 風險管理 (Risk Management)
專案執行期間潛在風險盤點與緩解計畫（Mitigation Plan）如下：
| 風險項目 | 機率 | 衝擊 | 緩解措施 (Mitigation Plan) |
|---|---|---|---|
| 1. RAG 檢索精準度持續低落 | 中 | 高 | 在 Phase 2 預留兩週的彈性時間進行 Prompt Engineering。必要時限縮回答範圍，強制 Agent 回傳文件連結而非直接生成步驟。 |
| 2. 部門文件梳理意願低落 | 高 | 中 | 由高階主管於專案 Kick-off 時佈達目標。採用「通用導入模板」降低技術門檻，並指派專責 SA 協助前期盤點。 |
| 3. Copilot 授權額度不足 | 中 | 中 | 於 M1 提前盤點可用授權，實施輪替測試機制（Floating License Concept），優先確保 3 個先鋒團隊的開發與測試不受阻礙。 |
6 預期成果與下一階段展望 (Outcomes & Future Scope)
6.1 具體交付物 (Deliverables)
穩定運行的 Agent
部署於生產環境，具備高可用性之問答模型。
結構化跨部門知識庫
完成清洗並優化為 RAG 友善格式之中央文檔庫。
先鋒系統導入實績
3 個關鍵系統成功上線，作為後續擴展的典範。
6.2 下一階段展望 (Future Scope: Phase II)
CI/CD Pipeline 整合與文件自動化
在首年基礎建設穩固後，次年目標為達成「Documentation as Code (DaC)」理念。預計將文件產生流程與既有的 CI/CD Pipeline 深度整合。
- 當工程師提交程式碼合併請求（Pull Request）時，自動觸發 AI 檢視變更並產生/更新 Markdown 文件。
- 自動啟動 Pandoc 轉換 Pipeline 並推送至 SharePoint 知識庫。
- 達成「程式碼與文件版本強制同步」，徹底解決文件陳舊化（Stale Documentation）的營運痛點。