變更日誌範本（CHANGELOG Template） 參照標準：Keep a Changelog 1.1.0 / Semantic Versioning 2.0.0 文件用途：記錄專案每個版本的顯著變更，讓使用者與開發者了解版本間的差異 適用階段：專案全生命週期（每次發版皆需更新） 📋 章節目錄 文件資訊 格式規範 變更類別定義 版本編號規則 撰寫規範 CHANGELOG 完整範本 自動化產生 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 CHANGELOG.md 位置 專案根目錄 格式 Markdown（Keep a Changelog 格式） 維護者 {Release Manager / 開發團隊} 更新時機 每次版本發布（Release） 📖 使用說明 CHANGELOG.md 置於專案根目錄，與 README.md 並列 每次 Release 前更新，不是每個 Commit 都記錄 記錄「對使用者有意義的變更」，非所有技術細節 💡 範例 CHANGELOG.md 通常長這樣的開頭： # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). 2. 格式規範 📝 範本 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - {新功能描述} ## [{版本號}] - {YYYY-MM-DD} ### Added - {新增功能} ### Changed - {變更項目} ### Deprecated - {即將移除的功能} ### Removed - {已移除的功能} ### Fixed - {修復的問題} ### Security - {安全性修復} [Unreleased]: {repo-url}/compare/v{版本}...HEAD [{版本號}]: {repo-url}/compare/v{前版本}...v{版本} 📖 使用說明 [Unreleased] 區塊永遠在最上方，收集尚未發布的變更 發版時將 [Unreleased] 內容移至新版本區塊 版本由新到舊排列（最新在最上面） 底部的連結區塊提供版本間的 diff 比較連結 💡 範例 見第 6 節完整範本。 ...

資料庫設計文件範本（Database Design Document Template） 適用標準：ISO/IEC 11179（Metadata Registries）、DAMA DMBOK 2.0、ISO/IEC/IEEE 42010:2022 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、資料庫管理師（DBA） 📑 章節目錄 文件資訊 資料庫架構概觀 實體關聯模型（ER Diagram） 資料表設計 索引設計策略 資料關聯與完整性約束 命名規範 資料治理與安全 效能設計考量 資料遷移與版本控制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料庫設計文件 文件編號 [專案代碼]-DBD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [SA/DBA 姓名] 審核者 [技術主管/架構師] 核准者 [專案經理] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件（SAD） [編號] 上游輸入 功能需求文件（FRD） [編號] 需求來源 API 規格文件 [編號] 介面對應 2. 資料庫架構概觀 2.1 資料庫技術選型 項目 選擇 說明 RDBMS [PostgreSQL / SQL Server / MySQL] [選型原因] 版本 [版本號] 部署模式 [Single / Primary-Replica / Cluster] [HA 需求] 字元集 [UTF-8 / UTF-16] 排序規則 [Collation] 2.2 資料庫實例配置 實例名稱 用途 主機 連接埠 備註 [DB_MAIN] 主要業務資料 [hostname] [port] Primary [DB_READ] 讀取副本 [hostname] [port] Read Replica [DB_ARCHIVE] 歷史資料歸檔 [hostname] [port] Archive 2.3 Schema 架構 [Database] ├── schema: core -- 核心業務資料表 ├── schema: auth -- 認證授權相關 ├── schema: audit -- 稽核軌跡 ├── schema: staging -- ETL 暫存區 └── schema: archive -- 歷史歸檔 3. 實體關聯模型（ER Diagram） 3.1 概念層 ERD（Conceptual ER Diagram） 呈現主要實體（Entity）之間的高階關係，不含欄位細節。 ...

資料遷移計畫範本（Data Migration Plan Template） 適用標準：ISO/IEC 25024（資料品質）、DAMA DMBOK 2.0（Data Management） 適用階段：部署上線階段（Deployment Phase） 負責角色：DBA、Data Engineer、SA、PM 📑 章節目錄 文件資訊 遷移概要 來源與目標分析 遷移策略 資料映射規則 資料清洗與轉換規則 驗證策略 風險與應變 時程與里程碑 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 資料遷移計畫 文件編號 [專案代碼]-DMP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [DBA / Data Engineer] 審核者 [SA / PM] 2. 遷移概要 項目 內容 遷移類型 [全量遷移 / 增量遷移 / 混合式] 來源系統 [舊系統名稱 + 版本] 目標系統 [新系統名稱 + 版本] 遷移目的 [系統升級 / 平台轉換 / 整併 / 雲遷移] 資料量估計 [N] GB / [N] 筆記錄 停機視窗 [YYYY-MM-DD HH:mm ~ HH:mm] 遷移方式 [Big Bang / Phased / Parallel Run] 3. 來源與目標分析 3.1 來源系統 項目 內容 資料庫類型 [RDBMS: SQL Server / Oracle / PostgreSQL / NoSQL] 版本 [ver] Schema 數量 [N] Table 數量 [N] 總資料量 [N] GB 編碼 [UTF-8 / Big5 / …] 3.2 目標系統 項目 內容 資料庫類型 [RDBMS / NoSQL / Data Lake] 版本 [ver] Schema 設計 [New / Modified / Same] 字元編碼 [UTF-8] 3.3 遷移範圍 資料分類 資料表 筆數(估) 大小(估) 優先級 備註 Master Data [table list] [N] [N]MB P1 Transaction Data [table list] [N] [N]GB P1 Historical Data [table list] [N] [N]GB P2 Config/Lookup [table list] [N] [N]KB P1 Attachments/BLOB [storage] [N] [N]GB P2 3.4 排除範圍 資料類型 排除原因 [暫存資料/Log] [無業務價值] [超過 N 年的歷史資料] [封存處理] 4. 遷移策略 4.1 遷移方式比較 方式 說明 優點 缺點 適用場景 Big Bang 一次性全量搬遷 簡單明確 停機時間長 資料量小/可停機 Phased 分批搬遷 降低風險 需處理雙寫 資料可分割 Parallel Run 新舊並行 最安全 成本最高 核心業務系統 選定策略：[Big Bang / Phased / Parallel Run] ...

運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」 文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序 適用階段：營運維護階段（Operations & Maintenance） 📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 Runbook 為活文件，需隨系統變更持續更新 任何維運操作變更需同步更新本文件 建議每季審閱一次，確保內容與現況一致 💡 範例 項目 內容 文件編號 RB-HRM-001 文件名稱 HRMS 運維手冊 維護者 DevOps 團隊 — 周維運 適用環境 Production 2. 系統概述 📝 範本 2.1 系統架構 {架構圖 — 包含所有元件與連接關係} 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 {元件} {技術} {位置} {URL/IP} {說明} 2.3 相依服務 外部服務 用途 端點 擁有者 SLA {服務} {用途} {端點} {團隊} {SLA} 2.4 存取方式 環境 入口 認證方式 備註 {環境} {URL/方式} {認證} {備註} 📖 使用說明 系統概述幫助值班人員快速了解系統全貌 元件清單需包含所有運行中的服務（含背景 Worker、排程任務等） 相依服務標明擁有者，出問題時知道找誰 💡 範例 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 hrms-api .NET 8 Web API AKS hrms-prod ns https://hrms-api.internal:443 後端 API hrms-web React 18 + Nginx AKS hrms-prod ns https://hrms.company.com 前端 SPA hrms-worker .NET 8 Worker Service AKS hrms-prod ns N/A（內部處理） 背景排程任務 PostgreSQL v16 Azure DB for PostgreSQL hrms-db.postgres.database.azure.com:5432 主資料庫 Redis v7 Azure Cache for Redis hrms-cache.redis.cache.windows.net:6380 Session + Cache 3. 常見操作程序 📝 範本 3.1 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟： ...

部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」 文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程 適用階段：部署與上線階段（Release & Deployment） 📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 依據 ITIL 4 Release Management 實務，每次部署需有正式的部署指南 文件需在部署前完成審核，未經核准不得執行部署 適用於所有環境（SIT / UAT / Staging / Production）部署 💡 範例 項目 內容 文件編號 DG-HRM-003 文件名稱 HRMS v1.0.0 正式環境部署指南 計畫部署日期 2026-10-15 22:00（維護窗口） 核准者 IT 副總 — 黃資訊 2. 部署概述 📝 範本 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 / 版本升級 / Hotfix / 組態變更 部署版本 {Application Version} 目標環境 {環境名稱} 部署方式 全量部署 / 滾動更新 / 藍綠部署 / 金絲雀部署 預估停機時間 {分鐘/小時} / 零停機 影響範圍 {受影響的服務/使用者} 維護窗口 {起始時間} ~ {結束時間} 2.2 變更內容摘要 變更編號 類型 描述 {CR/JIRA 編號} 功能/修復/組態 {簡述} 2.3 部署風險評估 風險等級 說明 高/中/低 {為何此等級} 📖 使用說明 部署類型決定所需的審核層級與流程嚴格度 Hotfix 可簡化流程但仍需記錄 預估停機時間需告知業務方，以便安排使用者通知 💡 範例 2.1 部署資訊摘要 項目 內容 部署類型 新系統上線 部署版本 HRMS v1.0.0 (Build #2026.10.12.1) 目標環境 Production (Azure AKS - hrms-prod) 部署方式 藍綠部署（Blue-Green Deployment） 預估停機時間 零停機（流量切換時間 < 30 秒） 影響範圍 全公司員工（約 2,000 人） 維護窗口 2026-10-15 22:00 ~ 2026-10-16 02:00 3. 先決條件 📝 範本 3.1 核准與簽核 項目 狀態 確認人 日期 變更審核委員會（CAB）核准 ☐ {姓名} {日期} 測試報告簽核 ☐ {姓名} {日期} 業務方確認上線同意 ☐ {姓名} {日期} 回滾計畫審核 ☐ {姓名} {日期} 3.2 技術先決條件 項目 驗證方式 狀態 {基礎設施就緒} {驗證命令/方式} ☐ {相依服務可用} {驗證命令/方式} ☐ {資料庫備份完成} {驗證命令/方式} ☐ {SSL 憑證有效} {驗證命令/方式} ☐ {DNS 設定確認} {驗證命令/方式} ☐ 3.3 部署所需權限 系統/資源 所需權限 帳號 {系統} {權限} {帳號} 📖 使用說明 所有先決條件需在部署開始前全部確認（Checklist 全部打勾） 任何一項未完成則不得啟動部署 資料庫備份是最關鍵的先決條件，未備份禁止部署 💡 範例 3.2 技術先決條件 項目 驗證方式 狀態 AKS 叢集節點 ≥ 4 kubectl get nodes 確認 Ready ☑ PostgreSQL 資料庫完整備份 確認 Azure Backup 最新備份 < 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 > 30 天 openssl s_client 確認到期日 ☑ 4. 部署架構 📝 範本 4.1 目標環境架構圖 {架構圖或 Mermaid 圖} 4.2 環境資訊 元件 主機/端點 規格 備註 Application Server {Host/IP} {CPU/RAM} {說明} Database {Host/IP:Port} {版本/規格} {說明} Cache {Host/IP:Port} {版本/規格} {說明} Load Balancer {Host/IP} {類型} {說明} Storage {Host/Path} {容量} {說明} 4.3 網路與防火牆規則 來源 目的 Port Protocol 用途 {來源} {目的} {Port} TCP/UDP {用途} 📖 使用說明 架構圖幫助部署人員理解全貌，建議使用 Mermaid 或繪製圖示 網路規則需在部署前確認已開通，避免部署後才發現連線失敗 機敏資訊（密碼、連線字串）不寫入文件，使用 Secret Manager 或變數引用 💡 範例 4.1 目標環境架構圖 Internet → Azure Front Door → AKS Ingress → Service ├── hrms-api (3 replicas) ├── hrms-worker (2 replicas) └── hrms-web (3 replicas) ↓ PostgreSQL (Azure DB for PostgreSQL) Redis (Azure Cache for Redis) Azure Blob Storage 5. 部署步驟 📝 範本 5.0 部署前通知 時間 對象 通知方式 內容 部署前 {N} 小時 {對象} {方式} {內容} 5.1 資料庫變更 步驟 指令/操作 預期結果 確認者 1 {SQL / Migration 指令} {預期輸出} {姓名} 2 {SQL / Migration 指令} {預期輸出} {姓名} 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 {部署指令} {預期輸出} {姓名} 2 {部署指令} {預期輸出} {姓名} 5.3 組態更新 步驟 指令/操作 預期結果 確認者 1 {組態變更指令} {預期結果} {姓名} 5.4 流量切換 步驟 指令/操作 預期結果 確認者 1 {切換指令} {預期結果} {姓名} 📖 使用說明 步驟需按執行順序排列，不可跳步 每步驟需有具體指令（可複製貼上執行）與預期結果 「確認者」在部署時簽名確認該步驟已完成 資料庫變更必須先於應用程式部署（確保 schema 相容） 機敏值（密碼）用環境變數或 Secret 引用，不寫死 💡 範例 5.2 應用程式部署 步驟 指令/操作 預期結果 確認者 1 kubectl set image deployment/hrms-api hrms-api=hrmacr.azurecr.io/hrms-api:v1.0.0 -n hrms-prod deployment.apps/hrms-api image updated DevOps 2 kubectl rollout status deployment/hrms-api -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 3 kubectl set image deployment/hrms-web hrms-web=hrmacr.azurecr.io/hrms-web:v1.0.0 -n hrms-prod deployment.apps/hrms-web image updated DevOps 4 kubectl rollout status deployment/hrms-web -n hrms-prod --timeout=300s deployment successfully rolled out DevOps 5 確認所有 Pod 狀態正常：kubectl get pods -n hrms-prod 所有 Pod 狀態為 Running，READY 1/1 DevOps 6. 驗證程序 📝 範本 6.1 Smoke Test（冒煙測試） 測試項目 驗證方式 預期結果 實際結果 Pass/Fail {基本功能 1} {驗證方式} {預期} {實際} {基本功能 2} {驗證方式} {預期} {實際} 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail {端點} {指令} {預期} {實際} 6.3 整合驗證 驗證項目 驗證方式 預期結果 實際結果 Pass/Fail {外部系統連接} {指令/操作} {預期} {實際} 6.4 部署成功判定標準 標準 說明 所有 Smoke Test 通過 — 健康檢查端點回應 200 持續 5 分鐘 無 Critical/High Alert 部署後 15 分鐘內 日誌無異常 Error 抽查近 100 條 Log 📖 使用說明 驗證程序在部署完成後立即執行，決定是否接受本次部署 Smoke Test 覆蓋核心業務路徑（如登入、主要功能），不需全面測試 若任何 P1 驗證失敗，立即啟動回滾程序 💡 範例 6.1 Smoke Test 測試項目 驗證方式 預期結果 實際結果 Pass/Fail 首頁可存取 curl -s -o /dev/null -w "%{http_code}" https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {"status":"healthy"} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {"status":"connected"} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {"status":"connected"} 同預期 Pass 7. 回滾程序 📝 範本 7.1 回滾觸發條件 條件 決策者 {觸發條件 1} {角色} {觸發條件 2} {角色} 7.2 回滾步驟 步驟 指令/操作 預期結果 確認者 1 {回滾指令} {預期} {姓名} 2 {回滾指令} {預期} {姓名} 7.3 資料庫回滾 步驟 指令/操作 預期結果 確認者 1 {DB 回滾指令} {預期} {姓名} 7.4 回滾後驗證 驗證項目 方式 預期結果 {驗證項} {方式} {預期} 7.5 回滾時間預估 項目 預估時間 應用程式回滾 {分鐘} 資料庫回滾 {分鐘} 驗證完成 {分鐘} 總計 {分鐘} 📖 使用說明 每次部署必須有回滾計畫，這是 ITIL 4 Release Management 的核心要求 回滾步驟需預先演練驗證，不可「部署當天第一次嘗試回滾」 資料庫回滾是最複雜的部分（若有 schema 變更），需特別規劃 藍綠部署的回滾最簡單：切回舊版流量即可 💡 範例 7.1 回滾觸發條件 條件 決策者 Smoke Test 失敗 2 項以上 DevOps Lead 部署後 15 分鐘內出現 Critical Alert DevOps Lead 業務方回報核心功能異常 IT 副總 部署超過維護窗口仍未完成 DevOps Lead + PM 7.2 回滾步驟（藍綠部署） 步驟 指令/操作 預期結果 確認者 1 通知團隊啟動回滾 Teams 群組通知已發送 DevOps Lead 2 kubectl rollout undo deployment/hrms-api -n hrms-prod rollback to previous revision DevOps 3 kubectl rollout undo deployment/hrms-web -n hrms-prod rollback to previous revision DevOps 4 kubectl rollout status deployment/hrms-api -n hrms-prod successfully rolled out DevOps 5 執行 Smoke Test 驗證回滾成功 所有項目 Pass QA 6 通知業務方服務已恢復 Email/Teams 通知已發送 PM 8. 監控確認 📝 範本 8.1 部署後監控期間 項目 內容 加強監控期間 部署後 {N} 小時 監控人員 {姓名/值班表} 告警通知管道 {方式} 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API 回應時間 (P95) < {ms} > {ms} {工具} Error Rate < {%} > {%} {工具} CPU 使用率 < {%} > {%} {工具} Memory 使用率 < {%} > {%} {工具} 活躍連線數 < {N} > {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 < 200ms > 500ms Grafana + Prometheus Error Rate (5xx) < 0.1% > 1% Azure Monitor CPU 使用率 < 60% > 85% Azure Monitor Memory 使用率 < 70% > 90% Azure Monitor Pod Restart Count 0 > 2 Kubernetes Dashboard DB Connection Pool < 80% > 95% Application Insights 9. 聯絡窗口 📝 範本 角色 姓名 電話 備用聯絡 職責 部署指揮 {姓名} {電話} {備用} 部署決策、Go/No-Go 判定 DevOps 工程師 {姓名} {電話} {備用} 執行部署操作 DBA {姓名} {電話} {備用} 資料庫變更 開發 Lead {姓名} {電話} {備用} 技術問題排除 QA {姓名} {電話} {備用} 部署驗證 業務窗口 {姓名} {電話} {備用} 業務確認 📖 使用說明 部署當天所有窗口需保持電話暢通 部署指揮負責 Go/No-Go 決策與回滾決定 建議建立即時通訊群組（如 Teams/Slack War Room）方便即時溝通 💡 範例 角色 姓名 電話 備用聯絡 職責 部署指揮 黃資訊（IT 副總） 0912-xxx-xxx Teams Go/No-Go 決策 DevOps 周維運 0933-xxx-xxx Teams 執行部署 DBA 趙資料 0922-xxx-xxx Teams DB Migration 開發 Lead 吳開發 0955-xxx-xxx Teams 問題排查 QA 林品質 0966-xxx-xxx Teams Smoke Test 10. 附錄 📝 範本 10.1 部署 Checklist 總表 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☐ 部署前 資料庫備份完成 ☐ 部署前 通知使用者 ☐ 部署中 DB Migration 完成 ☐ 部署中 應用程式部署完成 ☐ 部署後 Smoke Test 通過 ☐ 部署後 健康檢查正常 ☐ 部署後 監控指標正常 ☐ 部署後 通知使用者服務恢復 ☐ 10.2 相關文件 文件 說明 {文件名} {用途} 10.3 術語定義 術語 定義 CAB Change Advisory Board，變更諮詢委員會 Blue-Green 藍綠部署，同時維護兩套環境，透過流量切換完成零停機部署 Smoke Test 冒煙測試，部署後快速驗證核心功能 Rollback 回滾，將系統恢復至部署前的版本 Maintenance Window 維護窗口，預先規劃的系統維護時段 📖 使用說明 Checklist 在部署當天使用，逐項確認並記錄時間 此 Checklist 同時作為部署紀錄保存，不可事後補填 💡 範例 10.1 部署 Checklist（已執行） 階段 檢查項 確認 時間 確認者 部署前 CAB 核准 ☑ 10/13 15:00 黃資訊 部署前 PostgreSQL Full Backup ☑ 10/15 21:30 趙資料 部署前 Email 通知全公司維護 ☑ 10/15 18:00 PM 部署中 DB Migration (3 scripts) ☑ 10/15 22:05 趙資料 部署中 K8s Deployment 更新 ☑ 10/15 22:15 周維運 部署後 Smoke Test (5/5 Pass) ☑ 10/15 22:30 林品質 部署後 監控 15 分鐘無告警 ☑ 10/15 22:45 周維運 部署後 通知服務恢復 ☑ 10/15 22:50 PM 📌 範本使用注意事項 ...

需求異動申請表範本（Change Request Template） 適用標準：ISO/IEC/IEEE 15288:2023（系統生命週期）、ITIL 4 Change Management、CMMI 適用階段：需求分析階段 / 全生命週期（Requirements Phase / Cross-Phase） 負責角色：業務分析師（BA）、專案經理（PM）、變更管理委員會（CCB） 📑 章節目錄 變更申請資訊 變更描述 影響分析 變更方案 審核與決議 實施追蹤 變更驗收 📝 範本 1. 變更申請資訊 項目 內容 變更編號 CR-[YYYY]-[NNN] 申請日期 [YYYY-MM-DD] 申請人 [姓名 / 部門] 專案名稱 [專案名稱] 變更類型 [需求變更 / 設計變更 / 範圍變更 / 缺陷修正] 優先級 [Critical / High / Medium / Low] 緊急程度 [緊急 / 一般] 目前狀態 [Draft / Submitted / Under Review / Approved / Rejected / Implementing / Completed / Cancelled] 2. 變更描述 2.1 變更摘要 項目 內容 變更標題 [一句話描述變更內容] 變更原因 [為什麼需要這個變更] 業務背景 [觸發變更的業務情境或事件] 2.2 現行需求（As-Is） 需求編號 需求描述 文件來源 [REQ-NNN] [目前的需求描述] [BRD/FRD §N.N] 2.3 變更後需求（To-Be） 需求編號 變更後描述 變更差異摘要 [REQ-NNN] [修改後的需求描述] [新增/修改/刪除了什麼] 2.4 相關附件 附件名稱 說明 [附件1] [UI 原型 / 流程圖 / 規格書片段] 3. 影響分析 3.1 影響範圍評估 影響面向 受影響項目 影響程度 說明 功能模組 [受影響的模組清單] [High/Medium/Low] 資料庫 [Schema / Table 異動] [High/Medium/Low] API 介面 [受影響的 API] [High/Medium/Low] UI 畫面 [受影響的頁面] [High/Medium/Low] 外部系統 [受影響的介接系統] [High/Medium/Low] 文件 [需更新的文件] [High/Medium/Low] 測試案例 [需新增/修改的測試] [High/Medium/Low] 3.2 時程影響 項目 原定日期 變更後日期 延遲天數 [里程碑1] [YYYY-MM-DD] [YYYY-MM-DD] [N] days 上線日期 [YYYY-MM-DD] [YYYY-MM-DD] [N] days 3.3 成本影響 成本項目 追加工時（人天） 追加費用 說明 開發 [N] 人天 [金額] 測試 [N] 人天 [金額] 設計 [N] 人天 [金額] 其他 [N] 人天 [金額] 合計 [N] 人天 [金額] 3.4 風險評估 風險 ID 風險描述 發生機率 影響程度 緩解措施 R-1 [風險描述] [High/Med/Low] [High/Med/Low] [措施] 4. 變更方案 4.1 建議方案 項目 內容 方案說明 [概述如何實施此變更] 實施步驟 1. [步驟1]2. [步驟2]3. [步驟3] 需要資源 [人力/環境/工具] 預計工期 [N] 個工作天 測試範圍 [需要回歸測試的範圍] 4.2 替代方案（如有） 方案 說明 工時 優點 缺點 方案 A [說明] [N] 天 [優點] [缺點] 方案 B [說明] [N] 天 [優點] [缺點] 5. 審核與決議 5.1 審核記錄 審核者 角色 審核日期 決議 意見 [姓名] PM [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Tech Lead [YYYY-MM-DD] [Approve/Reject/Defer] [意見] [姓名] Business Owner [YYYY-MM-DD] [Approve/Reject/Defer] [意見] 5.2 CCB 決議 項目 內容 會議日期 [YYYY-MM-DD] 最終決議 [Approved / Rejected / Deferred / Need More Info] 核准條件 [附帶條件，如有] 預計實施版本 [Release / Sprint] 6. 實施追蹤 6.1 實施任務 任務 ID 任務描述 負責人 預計完成 實際完成 狀態 T-1 [修改設計文件] [姓名] [日期] [日期] [Done/In Progress/TODO] T-2 [修改程式碼] [姓名] [日期] [日期] [Done/In Progress/TODO] T-3 [更新測試案例] [姓名] [日期] [日期] [Done/In Progress/TODO] T-4 [執行回歸測試] [姓名] [日期] [日期] [Done/In Progress/TODO] 6.2 文件更新追蹤 文件名稱 更新內容 更新人 更新日期 狀態 [BRD / FRD / SAD] [章節 N.N] [姓名] [日期] [Done/Pending] 7. 變更驗收 項目 內容 驗收日期 [YYYY-MM-DD] 驗收人 [申請人 / Business Owner] 驗收結果 [Pass / Fail / Conditional Pass] 備註 [驗收意見] 📖 使用說明 變更管理流程 graph LR A[申請提出] --> B[影響分析] B --> C[CCB 審核] C -->|Approved| D[排入計畫] C -->|Rejected| E[結案通知] C -->|Deferred| F[暫緩追蹤] D --> G[實施變更] G --> H[驗證測試] H --> I[驗收結案] 各章節填寫指引 章節 填寫時機 負責人 重點說明 §1 申請資訊 提出申請時 申請人 正確分類與設定優先級 §2 變更描述 提出申請時 申請人/BA As-Is / To-Be 需明確對比 §3 影響分析 評估階段 SA/PM 需跨團隊協作評估 §4 變更方案 評估階段 SA/Tech Lead 提供可行方案供 CCB 決策 §5 審核決議 CCB 會議後 PM 記錄完整決議與附帶條件 §6 實施追蹤 實施期間 PM 追蹤每個任務進度 §7 驗收 實施完成後 申請人/QA 確認變更符合預期 優先級與緊急程度定義 優先級 定義 SLA Critical 阻擋上線/嚴重業務影響 24 hr 內決議 High 重大功能缺失 3 工作天內決議 Medium 功能改善/優化 7 工作天內決議 Low 可延後的改善建議 下次 Sprint Planning 討論 💡 範例（以 HRMS 人力資源管理系統為例） 範例：變更申請 項目 內容 變更編號 CR-2026-015 申請日期 2026-04-10 申請人 李美玲 / 人力資源部 專案名稱 HRMS 人力資源管理系統 變更類型 需求變更 優先級 High 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯 ...

非功能性需求設計規格範本（NFR Design Specification Template） 適用標準：ISO/IEC 25010:2023（SQuaRE - 系統與軟體品質模型）、ISO/IEC/IEEE 29148:2018 適用階段：系統設計階段（Design Phase） 負責角色：系統架構師（SA）、效能工程師、SRE 📑 章節目錄 文件資訊 品質屬性總覽 效能設計（Performance） 可用性設計（Availability） 延展性設計（Scalability） 可靠性設計（Reliability） 可維護性設計（Maintainability） 可觀測性設計（Observability） 安全性設計（Security） 相容性設計（Compatibility） 驗證與測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 非功能性需求設計規格 文件編號 [專案代碼]-NFR-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [SA 姓名] 審核者 [技術主管] 2. 品質屬性總覽 依 ISO/IEC 25010:2023 品質模型分類 品質屬性 子特性 目標等級 優先級 驗證方式 效能效率 時間行為、資源利用、容量 [目標] [High/Med/Low] [效能測試] 可用性 成熟度、容錯性、可恢復性 [目標] [High/Med/Low] [HA 測試] 延展性 水平/垂直擴展能力 [目標] [High/Med/Low] [負載測試] 可靠性 容錯、一致性 [目標] [High/Med/Low] [Chaos 測試] 可維護性 模組化、可測試性、可修改性 [目標] [High/Med/Low] [Code Review] 安全性 機密性、完整性、可用性 [目標] [High/Med/Low] [安全測試] 相容性 瀏覽器、裝置、整合 [目標] [High/Med/Low] [相容測試] 3. 效能設計（Performance） 3.1 效能目標 指標 日常目標 尖峰目標 測量方式 回應時間（P50） < [N]ms < [N]ms APM / Load test 回應時間（P95） < [N]ms < [N]ms APM / Load test 回應時間（P99） < [N]ms < [N]ms APM / Load test 吞吐量（TPS） ≥ [N] ≥ [N] Load test 並發用戶 [N] [N] Load test 錯誤率 < [N]% < [N]% Monitoring 3.2 效能設計策略 策略 適用場景 設計方案 快取 [高頻讀取、低頻更新] [快取層級/策略/TTL] 非同步處理 [非即時、耗時任務] [Message Queue + Worker] 連接池 [DB/HTTP 連線] [Pool size + timeout 設定] 分頁查詢 [大量資料列表] [Cursor-based / Offset pagination] 批次處理 [大量寫入] [Batch size + 排程策略] CDN [靜態資源] [CDN provider + cache policy] 3.3 效能預算（Performance Budget） 資源 預算 目前值 狀態 首頁載入（FCP） < [N]s [N]s [✅/⚠️/❌] 最大內容繪製（LCP） < [N]s [N]s [✅/⚠️/❌] 累計版面偏移（CLS） < [N] [N] [✅/⚠️/❌] 互動至下一次繪製（INP） < [N]ms [N]ms [✅/⚠️/❌] JS Bundle Size < [N]KB [N]KB [✅/⚠️/❌] API Response Size < [N]KB (avg) [N]KB [✅/⚠️/❌] 4. 可用性設計（Availability） 4.1 SLA 定義 服務 SLA 目標 允許停機/月 計算方式 [核心服務] [99.9%] [~43.8 min] Uptime / Total time [次要服務] [99.5%] [~3.6 hr] [背景服務] [99.0%] [~7.3 hr] 4.2 高可用設計 元件 HA 模式 Failover 時間 健康檢查 [元件] [Active-Active / Active-Passive / N+1] [N]s [HTTP/TCP/Custom] 4.3 停機策略 停機類型 通知時間 持續時間 影響範圍 核准 計畫性維護 [N 天前] [N hr] [描述] [PM/業務] 緊急修復 [即時] [N hr] [描述] [Tech Lead] 5. 延展性設計（Scalability） 5.1 擴展策略 維度 策略 設計 水平擴展（Scale-Out） [無狀態 + Load Balancer] [Auto-scaling rules] 垂直擴展（Scale-Up） [資料庫 / 特殊運算] [上限與遷移計畫] 資料擴展 [分區 / Sharding] [分區策略] 5.2 容量規劃 時間軸 預估用戶 預估資料量 預估 TPS 對應架構 上線 [N] [N] GB [N] [架構描述] 6 個月 [N] [N] GB [N] [是否需擴展] 1 年 [N] [N] GB [N] [擴展方案] 3 年 [N] [N] GB [N] [重大架構變更?] 6. 可靠性設計（Reliability） 6.1 容錯設計 故障場景 影響 容錯機制 降級方案 [單節點故障] [描述] [自動 failover] [N/A] [DB 連線失敗] [描述] [Circuit Breaker] [顯示快取資料] [外部 API 超時] [描述] [Retry + Timeout] [預設值/離線模式] [整個 AZ 故障] [描述] [Multi-AZ 部署] [部分功能降級] 6.2 Circuit Breaker 設計 服務 Open 條件 Half-Open 條件 Close 條件 Fallback [服務] [N 次失敗 in M 秒] [N 秒後] [N 次成功] [降級方案] 6.3 Retry 策略 場景 最大重試 退避策略 可重試條件 [HTTP call] [N] 次 [Exponential backoff + jitter] [5xx, timeout, network error] [DB operation] [N] 次 [Fixed interval] [Deadlock, connection lost] 7. 可維護性設計（Maintainability） 品質指標 目標 度量方式 程式碼覆蓋率 ≥ [N]% [CI/CD report] 技術債指標 [SQALE ≤ N days] [SonarQube] 模組耦合度 [低耦合] [Architecture fitness test] 部署頻率 [≥ N 次/週] [CI/CD metrics] 修復前置時間 [< N hr] [DORA metrics] 8. 可觀測性設計（Observability） 8.1 三大支柱 支柱 工具 設計 Metrics [Prometheus / CloudWatch] [RED + USE metrics] Logging [ELK / Loki] [Structured JSON, correlation ID] Tracing [Jaeger / Zipkin / OTEL] [Distributed tracing, 100% sampling for errors] 8.2 SLI/SLO 定義 SLI（指標） SLO（目標） 計算方式 告警閾值 Availability [99.9%] successful requests / total requests < 99.8% → Warning Latency (P95) [< 200ms] histogram_quantile(0.95) > 300ms → Warning Error Rate [< 0.1%] 5xx / total requests > 1% → Critical Throughput [≥ N TPS] rate(requests_total[5m]) < N*0.7 → Warning 9. 安全性設計（Security） 詳見安全設計文件（SecurityDesign_Template.md），此處僅摘要 NFR 指標 ...

Rust 1.x 完整企業級開發教學手冊 版本: 2.0 最後更新: 2026 年 5 月 17 日 適用對象: 新手工程師、中階工程師、資深工程師、架構師、技術主管、DevOps 團隊 技術層級: 初階 → 進階 → 架構師級 Rust 版本: 1.95.0 穩定版（Edition 2024） 授權: 內部教育訓練使用 參考來源: rust-lang.org、The Rust Book、crates.io、docs.rs、rustup.rs 目錄 Rust 介紹 1.1 Rust 歷史與發展 1.2 Rust 設計理念 1.3 Rust 與 C/C++ 差異 1.4 Rust 與 Java/Golang 差異 1.5 Rust 適合的應用場景 1.6 Rust 不適合的場景 1.7 Rust 生態系介紹 1.8 Cargo 介紹 1.9 Crates.io 介紹 1.10 docs.rs 介紹 Rust 核心特色 2.1 Ownership（所有權） 2.2 Borrowing（借用） 2.3 Lifetime（生命週期） 2.4 Move Semantics 2.5 Zero-Cost Abstraction 2.6 Pattern Matching 2.7 Traits 2.8 Generics 2.9 Async/Await 2.10 Memory Safety 2.11 Concurrency Safety 開發環境安裝 3.1 Windows 環境安裝 3.2 Linux 環境安裝 3.3 macOS 環境安裝 3.4 VSCode 設定 3.5 IntelliJ Rust 設定 3.6 Toolchain 管理 3.7 nightly / stable / beta 差異 Cargo 完整教學 4.1 專案建立與初始化 4.2 建置與執行 4.3 測試與文件 4.4 程式碼品質工具 4.5 安全性稽核 4.6 發佈與套件管理 4.7 Workspace 管理 4.8 相依性管理與語意版本 Rust 基礎語法 5.1 變數與可變性 5.2 資料型別 5.3 函式 5.4 控制流程 5.5 迴圈 5.6 結構體（Struct） 5.7 列舉（Enum） 5.8 模組系統 5.9 錯誤處理（Result / Option） 5.10 集合（Collections） 5.11 迭代器（Iterators） 5.12 閉包（Closures） Rust 進階教學 6.1 Traits 深入 6.2 Lifetimes 深入 6.3 Smart Pointers 6.4 Rc / Arc 6.5 Mutex / RwLock 6.6 Channels（通道） 6.7 Async Runtime 與 Tokio 6.8 Pin / Unpin 6.9 Unsafe Rust 6.10 Macros（巨集） 6.11 Procedural Macros Rust Web 開發 7.1 Web Framework 比較 7.2 Axum 概觀 7.3 Actix Web 概觀 7.4 Rocket 概觀 7.5 Warp 概觀 7.6 Framework 選型建議 使用 Axum 建立 RESTful API 8.1 專案架構（Clean Architecture） 8.2 DTO 與資料驗證 8.3 Service Layer 8.4 Repository Pattern 8.5 Middleware 8.6 JWT 認證與授權 8.7 OpenAPI / Swagger 8.8 完整 API 範例 8.9 Docker 化 資料庫整合 9.1 SQLx（推薦） 9.2 Diesel 9.3 SeaORM 9.4 ORM 比較表 9.5 Redis 快取 9.6 PostgreSQL 整合實務 9.7 MySQL 整合實務 9.8 SQLite 整合實務 非同步程式設計與高併發 10.1 Tokio Runtime 詳解 10.2 任務產生與管理 10.3 並行模式 10.4 Stream 處理 10.5 限流與背壓 10.6 Graceful Shutdown 10.7 Actor Model 10.8 高併發架構設計 WebAssembly（WASM） 11.1 WASM 概念 11.2 wasm-pack 建置 11.3 在前端使用 WASM 11.4 WASM 使用場景 11.5 Rust + React 整合範例 11.6 WASM 效能優化 系統架構設計 12.1 Clean Architecture 12.2 Hexagonal Architecture（六角架構） 12.3 微服務架構 12.4 事件驅動架構 12.5 CQRS（命令與查詢責任分離） 12.6 架構比較 12.7 模組拆分策略 Docker 與 Kubernetes 13.1 Dockerfile 最佳實務 13.2 Docker Compose 企業配置 13.3 Kubernetes 部署 13.4 Helm Chart 結構 13.5 Service / Ingress / ConfigMap / Secret 13.6 HPA 自動擴展 測試策略 14.1 單元測試 14.2 整合測試 14.3 屬性測試（Property-Based Testing） 14.4 效能測試 14.5 測試金字塔 14.6 Mock Test（mockall） 14.7 Benchmark（criterion） DevSecOps 與 SSDLC 15.1 GitHub Actions CI/CD 15.2 SSDLC 安全開發生命週期 15.3 供應鏈安全 15.4 模糊測試（Fuzzing） 15.5 SBOM 與 Dependency Scan 15.6 Secret Scan 與 Container Scan 可觀測性（Observability） 16.1 日誌（Logging） 16.2 指標（Metrics） 16.3 分散式追蹤（Distributed Tracing） 16.4 可觀測性架構 16.5 健康檢查端點 效能調校 17.1 Profile 工具 17.2 編譯最佳化 17.3 常見效能最佳化技巧 17.4 Async 效能調校 17.5 效能檢查清單 17.6 Lock Contention 分析 團隊建立與治理 18.1 Rust 團隊組建策略 18.2 程式碼規範 18.3 Code Review 檢查清單 18.4 技術債管理 18.5 開發流程（Git Flow / Trunk Based） 18.6 文件治理 18.7 AI 使用規範 AI 協作開發 19.1 GitHub Copilot 與 Rust 19.2 AI 輔助的工作流程 19.3 Prompt 撰寫技巧 19.4 AI Pair Programming 19.5 AI Review 與 Test Generation 19.6 Team Prompt Library 企業級最佳實務 20.1 專案結構最佳實務 20.2 設定管理 20.3 版本管理策略 20.4 錯誤處理最佳實務 20.5 API Versioning 20.6 Security Best Practices 20.7 Scalability 與 High Availability Rust 生態系推薦 21.1 依類別推薦 Crate 21.2 Crate 評估準則 21.3 CLI 與 DevOps 類別 21.4 AI 與 WASM 類別 完整企業級專案實戰 22.1 專案架構 22.2 Cargo.toml 22.3 main.rs 入口 22.4 領域模型 22.5 Repository 層 22.6 Service 層（含 Redis 快取） 22.7 API Handler 22.8 JWT 認證中介層 22.9 路由組裝 22.10 資料庫遷移 22.11 Docker 化部署 常見問題與解答（FAQ） 23.1 編譯相關 23.2 Async 相關 23.3 專案實務 23.4 Async Deadlock 23.5 Memory Leak 排查 23.6 Cargo 問題 學習路線圖 24.1 各階段推薦資源 24.2 初學者路線（0-3 個月） 24.3 中階路線（3-6 個月） 24.4 高階與架構師路線（6-12 個月） 結論 25.1 Rust 在企業中的價值 25.2 導入建議 25.3 技術選型建議 附錄：新進成員檢查清單 26.1 環境建置（第 1 天） 26.2 開發規範熟悉（第 1-2 週） 26.3 進階能力（第 3-4 週） 26.4 獨立作業（第 5-8 週） 版本歷史 Rust 學習路徑總覽 graph LR A[🟢 新手入門] --> B[🔵 基礎語法] B --> C[🟡 核心特色] C --> D[🟠 進階開發] D --> E[🔴 企業實戰] A --- A1[安裝環境] A --- A2[Cargo 基礎] B --- B1[變數/函式/流程控制] B --- B2[Struct/Enum/Module] B --- B3[錯誤處理/集合] C --- C1[Ownership/Borrowing] C --- C2[Lifetime] C --- C3[Traits/Generics] D --- D1[Async/Tokio] D --- D2[Web API/Axum] D --- D3[資料庫整合] E --- E1[架構設計] E --- E2[Docker/K8s] E --- E3[DevSecOps/CI-CD] E --- E4[Observability] 1. Rust 介紹 1.1 Rust 歷史與發展 Rust 是一門注重安全性、效能與並發性的現代系統級程式語言。 ...

addyosmani/agent-skills 教學手冊 版本：v2.0.0（基於 agent-skills v0.6.0） 更新日期：2026-05-17 適用對象：資深工程師、架構師、Tech Lead、DevSecOps 工程師 技術棧：addyosmani/agent-skills、Claude Code（Plugin Marketplace）、Cursor、Gemini CLI、GitHub Copilot、Kiro IDE、Spring Boot、Vue 3 授權：MIT License 參考來源：addyosmani/agent-skills（42.7k+ stars，4.7k forks，26 位貢獻者） 目錄 第 1 章：前言與概觀 1.1 addyosmani/agent-skills 是什麼 1.2 為何需要 Agent Skills 1.3 專案發起背景 1.4 核心理念：將資深工程師紀律轉化為結構化 AI 約束 1.5 Agent Skills 與傳統 Prompt Engineering 的本質差異 1.6 適用場景與不適用場景 1.7 addyosmani/agent-skills 與 mattpocock/skills 比較 1.8 專案資訊 第 2 章：核心架構設計 2.1 三層可組合架構 2.2 組合規則 2.3 SKILL.md 骨架設計 2.4 漸進式揭露策略 2.5 Token 效率設計原則 2.6 完整專案目錄結構 第 3 章：完整 23 個 Skills 深度解析 3.1 Meta 階段 3.2 Define 階段（定義需求） 3.3 Plan 階段（任務拆解） 3.4 Build 階段（增量實作） 3.5 Verify 階段（驗證品質） 3.6 Review 階段（合併前審查） 3.7 Ship 階段（部署上線） 第 4 章：Agent Personas 詳解 4.1 code-reviewer（Senior Staff Engineer） 4.2 test-engineer（QA Specialist） 4.3 security-auditor（Security Engineer） 4.4 Persona 與 Skill 的互動規則 4.5 自定義 Persona 第 5 章：7 個 Slash Commands 詳解 5.1 /spec — 定義要建什麼 5.2 /plan — 規劃如何建造 5.3 /build — 增量式建構 5.4 /test — 證明它可運作 5.5 /review — 合併前審查 5.6 /code-simplify — 簡化程式碼 5.7 /ship — 部署到生產環境 第 6 章：Reference Checklists 詳解 6.1 testing-patterns.md 6.2 security-checklist.md 6.3 performance-checklist.md 6.4 accessibility-checklist.md 6.5 orchestration-patterns.md 第 7 章：融入的頂尖 Google 工程實踐 7.1 Hyrum’s Law 7.2 Beyoncé Rule 7.3 Chesterton’s Fence 7.4 Spec-Driven Development 7.5 測試金字塔 7.6 其他核心原則 第 8 章：安裝與環境設定 8.1 安裝方式總覽 8.2 Claude Code（首要支援平台） 8.3 Cursor 8.4 Gemini CLI 8.5 Windsurf 8.6 OpenCode 8.7 GitHub Copilot 8.8 Kiro IDE & CLI 8.9 Codex / 其他 Agents 8.10 安裝後驗證 8.11 多工具共存 第 9 章：SSDLC 整合實戰 9.1 SSDLC 各階段與 Agent Skills 映射 9.2 需求分析階段 9.3 設計階段 9.4 開發階段 9.5 測試階段 9.6 審查階段 9.7 部署階段 9.8 維運階段 9.9 合規對應 第 10 章：AI Agent Team 建立指南 10.1 Agent Team 角色分配 10.2 Skills 組合配置 10.3 協作模式與 Human-in-the-Loop 10.4 不同規模團隊的導入差異 10.5 Agent Teams（實驗性功能） 10.6 不同規模團隊的採用策略 第 11 章：Web Application 開發實戰案例 11.1 端到端開發流程 11.2 後端案例（Spring Boot） 11.3 前端案例（Vue 3） 11.4 API 設計案例 第 12 章：系統 Framework 升級實戰 12.1 升級流程概覽 12.2 Java EE → Jakarta EE 實戰 12.3 Spring Boot 升級實戰 第 13 章：軟體逆向工程實戰 13.1 逆向工程流程 13.2 Legacy System 現代化 第 14 章：安全性治理 14.1 三層邊界系統 14.2 OWASP Top 10 防護對應 14.3 Auth Patterns 與 Secrets Management 14.4 SAST / DAST 整合 14.5 Prompt Injection 防護 第 15 章：CI/CD 與 DevSecOps 整合 15.1 GitHub Actions 範例 15.2 Quality Gate Pipeline 15.3 Feature Flag 生命週期 第 16 章：Context Engineering 與 Prompt 策略 16.1 五層 Context 階層 16.2 Context Packing 策略 16.3 MCP 整合 16.4 Anti-Hallucination 策略 第 17 章：測試策略 17.1 測試金字塔實踐 17.2 Red-Green-Refactor 流程 17.3 Prove-It Pattern 17.4 Mock 策略 第 18 章：Hooks 與 Session 管理 18.1 Hooks 目錄結構 18.2 Session Lifecycle Hooks 18.3 自定義 Hooks 第 19 章：自定義 Skill 開發指南 19.1 Skill Anatomy 完整規格 19.2 Writing Principles 19.3 完整自定義 Skill 範例 第 20 章：企業導入策略與治理 20.1 導入路線圖 20.2 AI Governance 治理機制 20.3 品質指標 20.4 合規考量 第 21 章：最佳實務 第 22 章：常見反模式 第 23 章：Troubleshooting 第 24 章：FAQ 第 25 章：附錄 附錄 A：23 個 Skills 速查表 附錄 B：7 個 Commands 速查表 附錄 C：3 個 Personas 速查表 附錄 D：Reference Checklists 速查表 附錄 E：設定範例 附錄 F：導入 Checklist 第 1 章：前言與概觀 1.1 addyosmani/agent-skills 是什麼 addyosmani/agent-skills 是由 Google Chrome 團隊工程主管 Addy Osmani 發起的開源專案，核心目的是將**資深軟體工程師的開發紀律與標準作業程序（SOP）**轉化為結構化的 Markdown 框架，用以約束並提升 AI 程式碼生成代理（AI Coding Agents）的交付品質。 ...

mattpocock/skills 教學手冊 使用 mattpocock/skills 建構企業級 AI Coding Agent 工程治理平台 項目 說明 版本 v2.0.0 更新日期 2026-05-15 適用對象 資深工程師、架構師、Tech Lead、DevSecOps 工程師、AI 導入推動者 技術棧 mattpocock/skills、Claude Code / Cursor / Codex / GitHub Copilot 等多 Agent、CONTEXT.md、ADR、skills.sh 參考來源 mattpocock/skills GitHub（84.1k stars、1.3M+ 安裝量、MIT License） 前置知識 AI Coding Agent 基本操作、Git 版本控制、基礎軟體工程概念 延伸閱讀：本手冊專注於 mattpocock/skills 特有生態系。如需了解通用 Agent Skills 開放標準，請參閱同目錄下的《Agent Skills 教學手冊》與《claude agent skills 教學手冊》。 目錄 第 1 章：前言 1.1 mattpocock/skills 是什麼 1.2 解決的四大 AI 失敗模式 1.3 skills.sh 生態系與多 Agent 支援 1.4 適用對象與使用情境 1.5 文件使用方式 第 2 章：mattpocock/skills 架構 2.1 Skills Runtime 與多 Agent 整合 2.2 Context Injection 與 Prompt Pipeline 2.3 Governance Layer 與 Agent Constraints 2.4 ADR Integration 與 Domain Discovery 2.5 Skills 分類體系 第 3 章：安裝與初始化 3.1 前置環境準備 3.2 安裝 mattpocock/skills 3.3 執行 setup-matt-pocock-skills 3.4 初始化建立的檔案與目錄 3.5 Issue Tracker 配置 第 4 章：Skills 工作原理 4.1 SKILL.md 檔案格式與附屬資源 4.2 Plugin 註冊機制 4.3 CONTEXT.md — 領域詞彙表 4.4 ADR（Architecture Decision Records） 4.5 Skill 載入與執行流程 第 5 章：grill-me 與 grill-with-docs — 需求探索與挑戰 5.1 grill-me — 通用計畫挑戰 5.2 grill-with-docs — 結合 Domain 的深度挑戰 5.3 grill-with-docs 的六項會議中行為 5.4 實戰案例：API 設計審查 5.5 最佳實踐與常見錯誤 第 6 章：tdd — 測試驅動開發 6.1 Philosophy — 測試哲學 6.2 Anti-Pattern: Horizontal Slices 6.3 Workflow — 四階段工作流 6.4 Spring Boot TDD 案例 6.5 Vue 3 TDD 案例 6.6 React TDD 案例 6.7 Node.js TDD 案例 6.8 最佳實踐與常見錯誤 第 7 章：to-prd — 產品需求文件產生 7.1 AI 對話轉 PRD 流程 7.2 PRD 模板結構（Deep Module 導向） 7.3 User Stories 撰寫 7.4 實戰案例與最佳實踐 第 8 章：to-issues — 工作任務拆解 8.1 PRD 到 Issue Tracker 8.2 Tracer Bullet Vertical Slice 拆解策略 8.3 HITL 與 AFK 分類 8.4 Issue Body Template 8.5 Label 與 Triage 策略（新版雙軸系統） 8.6 實戰案例與最佳實踐 第 9 章：prototype — 快速原型建立 9.1 Throwaway Prototype 原則 9.2 Logic 分支 — 終端互動原型 9.3 UI 分支 — 多方案視覺原型 9.4 通用規則與實戰案例 第 10 章：diagnose — 結構化除錯 10.1 六階段（Six Phases）除錯流程 10.2 Phase 1 — Build a Feedback Loop（建立回饋迴路） 10.3 Phase 2-4 — 假設與驗證 10.4 Phase 5-6 — 修復與回顧 10.5 實戰案例與最佳實踐 第 11 章：zoom-out — 全局視角 11.1 Repo Discovery 與 System Mapping 11.2 Architecture Understanding 11.3 實戰案例與最佳實踐 第 12 章：improve-codebase-architecture — 架構改善 12.1 Module Depth 理論 12.2 Deletion Test 與 Deepening Opportunities 12.3 三階段改善流程 12.4 實戰案例與最佳實踐 第 13 章：triage — 議題分類與管理 13.1 雙軸角色系統 13.2 AGENT-BRIEF.md 與自動摘要 13.3 Out-of-Scope 知識庫 13.4 AI 評論聲明 13.5 實戰案例與最佳實踐 第 14 章：其他實用 Skills 14.1 caveman — 極簡溝通模式 14.2 handoff — 跨 Agent 交接 14.3 write-a-skill — 自訂 Skill 開發 14.4 git-guardrails-claude-code — Git 安全護欄 14.5 setup-pre-commit — Pre-commit 配置 14.6 開發中的 Skills（In-Progress） 14.7 已棄用的 Skills（Deprecated） 第 15 章：AI Agent Workflow 15.1 端到端工作流程 15.2 Skills 組合策略 15.3 迭代循環與回饋機制 第 16 章：Web Application 實戰案例 16.1 技術棧選型 16.2 專案目錄結構 16.3 Skills 如何限制 AI 16.4 避免 Vibe Coding 與架構污染 16.5 完整開發流程示範 第 17 章：SSDLC — 安全軟體開發生命週期 17.1 Threat Modeling 與 Skills 整合 17.2 SAST / DAST / Dependency Scan 17.3 Prompt Injection 防護 17.4 AI Security Governance 第 18 章：AI Governance — AI 治理 18.1 Human Approval Gate 18.2 ADR Mandatory 與 Architecture Review 18.3 AI Scope Restriction 與 Protected Directories 18.4 Prompt Review 機制 第 19 章：DevSecOps 與 CI/CD 19.1 GitHub Actions 整合 19.2 Security Scan Pipeline 19.3 AI Review Workflow 19.4 Pull Request Governance 第 20 章：Best Practices — 最佳實踐 第 21 章：Anti-patterns — 反模式 第 22 章：Troubleshooting — 故障排除 第 23 章：FAQ — 常見問題 第 24 章：Appendix — 附錄 24.1 CLI 速查表 24.2 Prompt Templates 24.3 新進成員 Checklist 24.4 團隊導入 Checklist 24.5 參考連結 第 1 章：前言 1.1 mattpocock/skills 是什麼 mattpocock/skills 是由知名 TypeScript 專家 Matt Pocock 開發的開源 AI Agent 技能工具庫。最初為 Claude Code 設計，現已擴展為跨 Agent 平台，透過 skills.sh 登錄（Registry）支援十餘種 AI 編碼代理。截至目前，該專案已累計超過 84.1k GitHub Stars 與 1.3M 次安裝，是社群中最受歡迎的 Agent Skills 集合之一。 ...