[{"content":"Spring Framework 7.x 教學手冊 項目 說明 文件名稱 Spring Framework 7.x 教學手冊 文件版本 v1.1.0 版本說明 以 Spring Framework 7.0.x（7.0.8 GA，2026-06-09）為基準；完整涵蓋 7.0.1～7.0.8 的增量變更與安全修補（附錄 F），並納入 7.1（2026-11 預定） 前瞻（附錄 G）與 Spring Boot 4.1.0（2026-05） 增量更新（21.13） 最後更新日期 2026-08-01 撰寫角色 Java Enterprise Architect / Cloud Native Architect / DevSecOps Architect / Framework Migration Consultant 目標對象 SA、SD、PG、Architect、Tech Lead、PM、新進工程師、Framework 維護人員、Legacy Modernization Team 前置知識 Java 17+ 語法、Maven 基礎、HTTP / REST 概念、關聯式資料庫基礎 適用場景 企業內部教育訓練、技術白皮書、架構設計參考、升版決策依據、開發規範文件 語言 繁體中文（技術名詞保留英文原文） 授權方式 內部使用 前言 為什麼需要這本手冊 Spring Framework 7.0 是自 2025 年 11 月起的新世代生產線（production line），它不是一次例行的小改版，而是繼 6.0（javax → jakarta 大遷移）之後，影響面最廣的一次世代交替：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/spring-framework-7.x-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Spring Framework 7.x 教學手冊 項目 說明 文件名稱 Spring Framework 7.x 教學手冊 文件版本 v1.1.0 版本說明 以 Spring Framework 7.0.x（7.0.8 GA，2026-06-09）為基準；完整涵蓋 7.0.1～7.0.8 的增量變更與安全修補（附錄 F），並納入 7.1（2026-11 預定） 前瞻（附錄 G）與 Spring Boot 4.1.0（2026-05） 增量更新（21.13） 最後更新日期 2026-08-01 撰寫角色 Java Enterprise Architect / Cloud Native Architect / DevSecOps Architect / Framework Migration Consultant 目標對象 SA、SD、PG、Architect、Tech Lead、PM、新進工程師、Framework 維護人員、Legacy Modernization Team 前置知識 Java 17+ 語法、Maven 基礎、HTTP / REST 概念、關聯式資料庫基礎 適用場景 企業內部教育訓練、技術白皮書、架構設計參考、升版決策依據、開發規範文件 語言 繁體中文（技術名詞保留英文原文） 授權方式 內部使用 前言 為什麼需要這本手冊 Spring Framework 7.0 是自 2025 年 11 月起的新世代生產線（production line），它不是一次例行的小改版，而是繼 6.0（javax → jakarta 大遷移）之後，影響面最廣的一次世代交替：\n","title":"Spring Framework 7.x 教學手冊"},{"content":"Spring Boot 4.x 教學手冊 企業級教育訓練教材｜實戰與維運導向｜繁體中文\n項目 說明 手冊名稱 Spring Boot 4.x 教學手冊 版本 v1.1 基準版本 Spring Boot 4.1.0（現行 GA）／向下相容說明涵蓋 4.0.x（維護版 4.0.7） 技術堆疊 Java 25（LTS）、Spring Framework 7.0.8、Spring Security 7.1、Spring Data 2026.0、Jakarta EE 11 世代規格、Maven 4／Gradle 9 目標對象 資深 Java 工程師、架構師、Tech Lead、SA／SD、Legacy 現代化團隊 前置知識 Java 基礎語法、物件導向、Maven 或 Gradle 基本操作、HTTP 與 SQL 概念 文件定位 內部教育訓練教材＋開發規範參考＋升版與導入指引 狀態 正式版 事實查證來源 Spring Boot 官方 GitHub Release Notes／spring.io 專案頁／官方參考文件 最後更新 2026-07-31 前言 為什麼需要這本手冊 Spring Boot 4.x 不是 3.x 的小改版，而是一次跨世代的基礎重整。它同時帶來三件事：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/spring-boot-4.x-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Spring Boot 4.x 教學手冊 企業級教育訓練教材｜實戰與維運導向｜繁體中文\n項目 說明 手冊名稱 Spring Boot 4.x 教學手冊 版本 v1.1 基準版本 Spring Boot 4.1.0（現行 GA）／向下相容說明涵蓋 4.0.x（維護版 4.0.7） 技術堆疊 Java 25（LTS）、Spring Framework 7.0.8、Spring Security 7.1、Spring Data 2026.0、Jakarta EE 11 世代規格、Maven 4／Gradle 9 目標對象 資深 Java 工程師、架構師、Tech Lead、SA／SD、Legacy 現代化團隊 前置知識 Java 基礎語法、物件導向、Maven 或 Gradle 基本操作、HTTP 與 SQL 概念 文件定位 內部教育訓練教材＋開發規範參考＋升版與導入指引 狀態 正式版 事實查證來源 Spring Boot 官方 GitHub Release Notes／spring.io 專案頁／官方參考文件 最後更新 2026-07-31 前言 為什麼需要這本手冊 Spring Boot 4.x 不是 3.x 的小改版，而是一次跨世代的基礎重整。它同時帶來三件事：\n","title":"Spring Boot 4.x 教學手冊"},{"content":"Maven 4.x 教學手冊 文件性質：企業內部教育訓練教材／團隊開發規範文件 適用對象：資深 Java 工程師、軟體架構師、DevOps／SRE、平台工程團隊、Tech Lead、建置與發布負責人 內容取向：實戰與維運導向，可直接作為專案團隊內部規範採用 技術基準：Apache Maven 4.0.0-rc-5（2025-11-13）／Apache Maven 3.9.16（2026-05-13） 查證基準日：2026-07-28（全書所有「截至目前」均指此日） 主要參考來源：\nApache Maven 官方網站：https://maven.apache.org/ What\u0026rsquo;s new in Maven 4：https://maven.apache.org/whatsnewinmaven4.html Maven 3 至 Maven 4 遷移指南：https://maven.apache.org/guides/mini/guide-migration-to-mvn4.html Maven 版本歷史：https://maven.apache.org/docs/history.html Maven 4.0.0-rc-5 Release Notes：https://maven.apache.org/docs/4.0.0-rc-5/release-notes.html ⚠️ 版本狀態重要聲明 請務必先讀完本節，再決定你的團隊要如何使用本手冊。\n截至 2026-07-28，經查證 Apache Maven 官方網站，事實如下：\n項目 現況 佐證來源 Maven 4 最新版本 4.0.0-rc-5，發布於 2025-11-13 Maven Releases History Maven 4 是否已 GA 尚未正式發布（Not GA） Maven Releases History 官方對生產環境的立場 原文：\u0026ldquo;Maven 4.x is currently under development, so while we are encouraging users to try it and report any issues, it is NOT safe for production use.\u0026rdquo; Maven Download 頁面 Maven 3 現行穩定版 3.9.16，發布於 2026-05-13 Maven Releases History Maven 3 新分支 3.10.0-rc-1，發布於 2026-07-09 Maven Releases History 執行 Maven 4 的最低需求 Java 17（僅「執行 Maven 本身」需要，專案仍可編譯至 Java 8） What\u0026rsquo;s new in Maven 4 此外，官方的 What\u0026rsquo;s new in Maven 4 頁面（最後發布日 2026-07-27）內文仍寫著 \u0026ldquo;This article will continuously be updated at least until Maven 4.0.0 is released.\u0026quot;，是 Maven 4.0.0 尚未 GA 的第二個獨立佐證。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/maven-4.x-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Maven 4.x 教學手冊 文件性質：企業內部教育訓練教材／團隊開發規範文件 適用對象：資深 Java 工程師、軟體架構師、DevOps／SRE、平台工程團隊、Tech Lead、建置與發布負責人 內容取向：實戰與維運導向，可直接作為專案團隊內部規範採用 技術基準：Apache Maven 4.0.0-rc-5（2025-11-13）／Apache Maven 3.9.16（2026-05-13） 查證基準日：2026-07-28（全書所有「截至目前」均指此日） 主要參考來源：\nApache Maven 官方網站：https://maven.apache.org/ What\u0026rsquo;s new in Maven 4：https://maven.apache.org/whatsnewinmaven4.html Maven 3 至 Maven 4 遷移指南：https://maven.apache.org/guides/mini/guide-migration-to-mvn4.html Maven 版本歷史：https://maven.apache.org/docs/history.html Maven 4.0.0-rc-5 Release Notes：https://maven.apache.org/docs/4.0.0-rc-5/release-notes.html ⚠️ 版本狀態重要聲明 請務必先讀完本節，再決定你的團隊要如何使用本手冊。\n截至 2026-07-28，經查證 Apache Maven 官方網站，事實如下：\n項目 現況 佐證來源 Maven 4 最新版本 4.0.0-rc-5，發布於 2025-11-13 Maven Releases History Maven 4 是否已 GA 尚未正式發布（Not GA） Maven Releases History 官方對生產環境的立場 原文：\u0026ldquo;Maven 4.x is currently under development, so while we are encouraging users to try it and report any issues, it is NOT safe for production use.\u0026rdquo; Maven Download 頁面 Maven 3 現行穩定版 3.9.16，發布於 2026-05-13 Maven Releases History Maven 3 新分支 3.10.0-rc-1，發布於 2026-07-09 Maven Releases History 執行 Maven 4 的最低需求 Java 17（僅「執行 Maven 本身」需要，專案仍可編譯至 Java 8） What\u0026rsquo;s new in Maven 4 此外，官方的 What\u0026rsquo;s new in Maven 4 頁面（最後發布日 2026-07-27）內文仍寫著 \u0026ldquo;This article will continuously be updated at least until Maven 4.0.0 is released.\u0026quot;，是 Maven 4.0.0 尚未 GA 的第二個獨立佐證。\n","title":"Maven 4.x 教學手冊"},{"content":"Paperclip 教學手冊 Paperclip — 開源 AI Agent 編排平台（Zero-Human Company Operating System）企業級完整指南 適用對象：資深工程師、AI Agent 平台團隊、架構師、Tech Lead、DevOps / SSDLC 負責人、企業導入人員、PM 文件性質：企業內部 AI Agent 平台導入、開發與維運培訓教材 版本基準：Paperclip（paperclipai/paperclip，2026 年 3 月開源，MIT License）\n⚠️ 重要聲明（請務必先讀） Paperclip 仍在高速迭代中。 本平台於 2026-03-04 開源，社群成長極快（開源三週即破 3 萬 GitHub Stars，截至 2026 年年中已逾 7.4 萬 stars、1.3 萬+ forks，並維持每日 commit）。其資料模型、CLI 指令、API 端點、環境變數與 UI 可能在版本之間變動。任何指令與設定在正式導入前，務必以最新官方文件與您實際安裝版本為準。 本手冊的定位是「理解、彙整、分析、重組、補充最佳實務」，而非官方文件翻譯。 依原始需求，本書不直接翻譯、不直接抄錄、不大量引用原文，而是重新以繁體中文撰寫成企業教材。 內容分兩類： 官方已確認事實（例如 Node.js 20+/pnpm 9.15+ 需求、npx paperclipai onboard --yes、Control Plane 12 系統、BYOA、companies repository 結構、heartbeat 執行、atomic task checkout、git worktree workspace 等）作為骨幹。 作者補充：凡屬作者依大型企業（含金融業）導入 AI Agent 之實務經驗所補充或推論之處，會標註 （作者建議） 或 （作者推論）。這些是最佳實務參考，非官方保證。 官方權威來源請見 第28章 附錄 → References。 目錄 本目錄為兩層結構（章 + 子節），每一項皆可點擊跳轉至本文對應段落；各章開頭另附「本章導覽」提供章內快速跳轉。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/paperclip-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Paperclip 教學手冊 Paperclip — 開源 AI Agent 編排平台（Zero-Human Company Operating System）企業級完整指南 適用對象：資深工程師、AI Agent 平台團隊、架構師、Tech Lead、DevOps / SSDLC 負責人、企業導入人員、PM 文件性質：企業內部 AI Agent 平台導入、開發與維運培訓教材 版本基準：Paperclip（paperclipai/paperclip，2026 年 3 月開源，MIT License）\n⚠️ 重要聲明（請務必先讀） Paperclip 仍在高速迭代中。 本平台於 2026-03-04 開源，社群成長極快（開源三週即破 3 萬 GitHub Stars，截至 2026 年年中已逾 7.4 萬 stars、1.3 萬+ forks，並維持每日 commit）。其資料模型、CLI 指令、API 端點、環境變數與 UI 可能在版本之間變動。任何指令與設定在正式導入前，務必以最新官方文件與您實際安裝版本為準。 本手冊的定位是「理解、彙整、分析、重組、補充最佳實務」，而非官方文件翻譯。 依原始需求，本書不直接翻譯、不直接抄錄、不大量引用原文，而是重新以繁體中文撰寫成企業教材。 內容分兩類： 官方已確認事實（例如 Node.js 20+/pnpm 9.15+ 需求、npx paperclipai onboard --yes、Control Plane 12 系統、BYOA、companies repository 結構、heartbeat 執行、atomic task checkout、git worktree workspace 等）作為骨幹。 作者補充：凡屬作者依大型企業（含金融業）導入 AI Agent 之實務經驗所補充或推論之處，會標註 （作者建議） 或 （作者推論）。這些是最佳實務參考，非官方保證。 官方權威來源請見 第28章 附錄 → References。 目錄 本目錄為兩層結構（章 + 子節），每一項皆可點擊跳轉至本文對應段落；各章開頭另附「本章導覽」提供章內快速跳轉。\n","title":"Paperclip 教學手冊"},{"content":"AI常用方法論比較教學手冊(2) 版本：v1.1｜日期：2026-07-24｜適用對象：AI Software Architect、Enterprise Architect、Tech Lead、資深前後端工程師、DevSecOps Architect、Solution Architect v1.1 更新重點：依 8 套方法論官方 Repository 最新狀態逐節查證修正（含 BMAD-METHOD 階段命名訂正、spec-kit／OpenSpec 新指令集、gstack 起源脈絡補充等）；第六章 AI Coding Agent 現況更新（Windsurf 已更名 Devin Desktop、GitHub Copilot Coding Agent 更名 Copilot cloud agent 等）；第七、八、九、十一章多節深度擴寫至與同章其他小節一致；第四章新增「生態系穩定性／維護風險」補充表；新增第十三章案例六、第十四章 3 份角色 Prompt；修正簡體字殘留、附錄目錄缺漏與數處章節交叉引用錯誤 定位：本手冊是《AI常用方法論比較教學手冊》（以下稱「v1」）的擴充版與企業教育訓練教材版。v1 的定位是「跨方法論比較與選型指南」（8 方法論 × 5 AI 工具 × 3 情境的濃縮比較），本手冊（v2／\u0026quot;(2)\u0026quot;）的定位是完整的企業級 AI 軟體工程教學手冊：從發展史、方法論詳解、AI Coding Agent 架構、企業 AI SDLC、Framework Upgrade、逆向工程、企業導入、AI Agent 團隊建立，到產業最佳實務、完整實戰案例與角色化 Prompt Library，一次到位。兩份手冊互為表裡，建議搭配閱讀（見〈附錄 F〉對應關係表）。 涵蓋方法論／概念：spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD（get-shit-done）、gsd-pi（GSD-2）、gstack、mattpocock/skills、Loop Engineering、Compound Engineering、Context Engineering、Memory Engineering、Skills Engineering、Prompt Engineering、Agentic Software Engineering、Spec-Driven Development、AI-Native Development 涵蓋 AI Coding Agent：Claude Code、OpenAI Codex CLI、GitHub Copilot、Gemini CLI、Grok、Cursor、Windsurf、Aider、OpenHands、Cline、Roo Code 涵蓋情境：企業 Web 開發、大型 Framework Upgrade（Spring Boot／Java／Vue）、Legacy 逆向工程（COBOL／VB／Oracle Forms／PowerBuilder／Delphi）、企業 AI SSDLC、銀行大型系統 適用產業：金融／銀行、政府、保險、製造、醫療，並適用一般企業 IT 團隊 資料誠信聲明：本手冊整理自本專案既有教學手冊語料庫、各方法論官方 Repository／文件、業界公開文章，並經重新消化歸納後撰寫。凡涉及 GitHub Star 數、安裝次數、營收/效能改善百分比等量化採用指標，若無法在撰寫當下查證來源，一律不予引用或明確標註「未經查證，僅供參考」，不將既有語料庫中的可疑數字（例如個別手冊出現的異常高 Star 數）當作事實延續。本手冊重心放在可驗證的設計理念、架構、工作流程、指令語法與企業實務模式上。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ai%E5%B8%B8%E7%94%A8%E6%96%B9%E6%B3%95%E8%AB%96%E6%AF%94%E8%BC%83%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A2/","summary":"AI常用方法論比較教學手冊(2) 版本：v1.1｜日期：2026-07-24｜適用對象：AI Software Architect、Enterprise Architect、Tech Lead、資深前後端工程師、DevSecOps Architect、Solution Architect v1.1 更新重點：依 8 套方法論官方 Repository 最新狀態逐節查證修正（含 BMAD-METHOD 階段命名訂正、spec-kit／OpenSpec 新指令集、gstack 起源脈絡補充等）；第六章 AI Coding Agent 現況更新（Windsurf 已更名 Devin Desktop、GitHub Copilot Coding Agent 更名 Copilot cloud agent 等）；第七、八、九、十一章多節深度擴寫至與同章其他小節一致；第四章新增「生態系穩定性／維護風險」補充表；新增第十三章案例六、第十四章 3 份角色 Prompt；修正簡體字殘留、附錄目錄缺漏與數處章節交叉引用錯誤 定位：本手冊是《AI常用方法論比較教學手冊》（以下稱「v1」）的擴充版與企業教育訓練教材版。v1 的定位是「跨方法論比較與選型指南」（8 方法論 × 5 AI 工具 × 3 情境的濃縮比較），本手冊（v2／\u0026quot;(2)\u0026quot;）的定位是完整的企業級 AI 軟體工程教學手冊：從發展史、方法論詳解、AI Coding Agent 架構、企業 AI SDLC、Framework Upgrade、逆向工程、企業導入、AI Agent 團隊建立，到產業最佳實務、完整實戰案例與角色化 Prompt Library，一次到位。兩份手冊互為表裡，建議搭配閱讀（見〈附錄 F〉對應關係表）。 涵蓋方法論／概念：spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD（get-shit-done）、gsd-pi（GSD-2）、gstack、mattpocock/skills、Loop Engineering、Compound Engineering、Context Engineering、Memory Engineering、Skills Engineering、Prompt Engineering、Agentic Software Engineering、Spec-Driven Development、AI-Native Development 涵蓋 AI Coding Agent：Claude Code、OpenAI Codex CLI、GitHub Copilot、Gemini CLI、Grok、Cursor、Windsurf、Aider、OpenHands、Cline、Roo Code 涵蓋情境：企業 Web 開發、大型 Framework Upgrade（Spring Boot／Java／Vue）、Legacy 逆向工程（COBOL／VB／Oracle Forms／PowerBuilder／Delphi）、企業 AI SSDLC、銀行大型系統 適用產業：金融／銀行、政府、保險、製造、醫療，並適用一般企業 IT 團隊 資料誠信聲明：本手冊整理自本專案既有教學手冊語料庫、各方法論官方 Repository／文件、業界公開文章，並經重新消化歸納後撰寫。凡涉及 GitHub Star 數、安裝次數、營收/效能改善百分比等量化採用指標，若無法在撰寫當下查證來源，一律不予引用或明確標註「未經查證，僅供參考」，不將既有語料庫中的可疑數字（例如個別手冊出現的異常高 Star 數）當作事實延續。本手冊重心放在可驗證的設計理念、架構、工作流程、指令語法與企業實務模式上。\n","title":"AI常用方法論比較教學手冊(2)"},{"content":"AI常用方法論比較教學手冊 版本：v1.1｜日期：2026-07-24｜適用對象：架構師、Tech Lead、AI 導入決策者、資深工程師 v1.1 更新重點：依 8 套方法論官方 Repository 最新狀態逐章查證修正，包含 GSD 生態系組織遷移沿革（見 2.5、2.6、附錄 C.2）、五工具整合覆蓋度多處更新（spec-kit／BMAD-METHOD／Superpowers／gstack）、gstack 技能規模與指令管線更新、mattpocock/skills 技能清單改版、AGENTS.md 創始會員名單補正，並新增附錄 D.4 版本快照表 涵蓋方法論：spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD（get-shit-done）、gsd-pi（GSD-2）、gstack、mattpocock/skills 涵蓋 AI 工具：Claude Code、OpenAI Codex、GitHub Copilot、Gemini、Grok 涵蓋情境：Web Application 開發、逆向工程（Reverse Engineering）、軟體框架升級（Framework Upgrade） 適用產業：銀行、金融業、保險業等高治理需求產業，亦適用一般企業 IT 團隊 重要更新：本文件為跨方法論比較與企業選型指南，非取代任何單一方法論的完整教學；各方法論詳細操作請參閱本目錄下對應手冊（見各章節連結與附錄 D）\n📋 目錄 前言 第 1 章：AI 輔助軟體開發方法論全景與參考座標 1.1 為何企業需要跨方法論比較 1.2 方法論分類框架（機制軸） 1.3 八大方法論定位圖 1.4 五大 AI 工具總覽 1.5 三大應用情境定義與成功標準 1.6 AGENTS.md：跨工具互通基礎設施 1.7 其他外部參考座標（非完整檔案，僅作校準用） 1.8 實務落地建議 第 2 章：八大方法論濃縮檔案 2.1 spec-kit 2.2 OpenSpec 2.3 Superpowers 2.4 BMAD-METHOD 2.5 GSD（get-shit-done） 2.6 gsd-pi（GSD-2） 2.7 gstack 2.8 mattpocock/skills 2.9 實務落地建議 第 3 章：跨方法論比較框架與矩陣 3.1 比較維度定義 3.2 總覽比較矩陣 3.3 安裝複雜度與五工具整合覆蓋度矩陣 3.4 團隊規模與組織適配 3.5 治理與維運負擔比較 3.6 學習曲線與導入時間比較 3.7 機制光譜圖 3.8 弱點與風險總表 3.9 實務落地建議 第 4 章：企業選型決策框架 4.1 選型決策樹 4.2 評分量表（可直接套用） 4.3 方法論導入成熟度模型（Level 1–5） 4.4 試點到擴大導入路線圖 4.5 決策情境範例 4.6 實務落地建議 第 5 章：混合與共存導入指南 5.1 為何要混合方法論 5.2 相容性矩陣 5.3 分層組合模型 5.4 安裝順序與設定合併建議 5.5 已知衝突與注意事項 5.6 實務落地建議 第 6 章：三大情境實戰案例（銀行業） 6.1 情境一：Web Application 開發 6.2 情境二：逆向工程 6.3 情境三：框架升級 6.4 三情境 × 八方法論適配打分表 6.5 實務落地建議 第 7 章：方法論組合的維護與升級治理 7.1 為何需要「方法論組合」層級的治理 7.2 日常維運：版本釘選與相容性檢查 7.3 Prompt／Spec 版本控制與變更追蹤 7.4 治理委員會結構與 RACI 7.5 何時該汰換或升級方法論 7.6 法規遵循與稽核追溯（銀行/金融特別考量） 7.7 監控指標與健康度儀表板 7.8 實務落地建議 第 8 章：AI Agent 跨方法論協作範例 8.1 為何需要跨方法論/跨工具協作範例 8.2 範例一：Claude Code + Codex 共用 AGENTS.md 8.3 範例二：Copilot + Gemini/Grok 以 OpenSpec 仲裁 8.4 協作失敗模式與修復 8.5 實務落地建議 第 9 章：方法論選型與整合 Prompt Library 9.1 團隊 AI 成熟度現況評估 Prompt 9.2 方法論選型建議 Prompt 9.3 兩方法論相容性檢查 Prompt 9.4 治理文件骨架生成 Prompt 9.5 情境對應方法論組合 Prompt 9.6 方法論汰換/遷移評估 Prompt 9.7 實務落地建議 第 10 章：常見問題（FAQ） 附錄 A：快速選型與導入檢查清單 附錄 B：八方法論／五工具／三情境速查表 附錄 C：名詞釋義與命名辨正 附錄 D：參考資源與延伸閱讀 附錄 E：八大方法論安裝教學速查 前言 為什麼需要這份手冊 過去兩年間，「用 AI 寫程式」已經從個人的 Prompt 技巧，演化成一整套可被治理、可被複製、可被稽核的方法論（Methodology）。截至本文件撰寫時，僅在本專案的 .github\\教學\\AI開發\\ 目錄下，就已經累積了 spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD、gsd-pi（GSD-2）、gstack、mattpocock/skills 等 8 套獨立、完整、動輒 2,500～7,300 行的教學手冊 —— 每一套都宣稱自己能提升 AI 協作品質，每一套都有各自的哲學、安裝方式與最佳實務。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ai%E5%B8%B8%E7%94%A8%E6%96%B9%E6%B3%95%E8%AB%96%E6%AF%94%E8%BC%83%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"AI常用方法論比較教學手冊 版本：v1.1｜日期：2026-07-24｜適用對象：架構師、Tech Lead、AI 導入決策者、資深工程師 v1.1 更新重點：依 8 套方法論官方 Repository 最新狀態逐章查證修正，包含 GSD 生態系組織遷移沿革（見 2.5、2.6、附錄 C.2）、五工具整合覆蓋度多處更新（spec-kit／BMAD-METHOD／Superpowers／gstack）、gstack 技能規模與指令管線更新、mattpocock/skills 技能清單改版、AGENTS.md 創始會員名單補正，並新增附錄 D.4 版本快照表 涵蓋方法論：spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD（get-shit-done）、gsd-pi（GSD-2）、gstack、mattpocock/skills 涵蓋 AI 工具：Claude Code、OpenAI Codex、GitHub Copilot、Gemini、Grok 涵蓋情境：Web Application 開發、逆向工程（Reverse Engineering）、軟體框架升級（Framework Upgrade） 適用產業：銀行、金融業、保險業等高治理需求產業，亦適用一般企業 IT 團隊 重要更新：本文件為跨方法論比較與企業選型指南，非取代任何單一方法論的完整教學；各方法論詳細操作請參閱本目錄下對應手冊（見各章節連結與附錄 D）\n📋 目錄 前言 第 1 章：AI 輔助軟體開發方法論全景與參考座標 1.1 為何企業需要跨方法論比較 1.2 方法論分類框架（機制軸） 1.3 八大方法論定位圖 1.4 五大 AI 工具總覽 1.5 三大應用情境定義與成功標準 1.6 AGENTS.md：跨工具互通基礎設施 1.7 其他外部參考座標（非完整檔案，僅作校準用） 1.8 實務落地建議 第 2 章：八大方法論濃縮檔案 2.1 spec-kit 2.2 OpenSpec 2.3 Superpowers 2.4 BMAD-METHOD 2.5 GSD（get-shit-done） 2.6 gsd-pi（GSD-2） 2.7 gstack 2.8 mattpocock/skills 2.9 實務落地建議 第 3 章：跨方法論比較框架與矩陣 3.1 比較維度定義 3.2 總覽比較矩陣 3.3 安裝複雜度與五工具整合覆蓋度矩陣 3.4 團隊規模與組織適配 3.5 治理與維運負擔比較 3.6 學習曲線與導入時間比較 3.7 機制光譜圖 3.8 弱點與風險總表 3.9 實務落地建議 第 4 章：企業選型決策框架 4.1 選型決策樹 4.2 評分量表（可直接套用） 4.3 方法論導入成熟度模型（Level 1–5） 4.4 試點到擴大導入路線圖 4.5 決策情境範例 4.6 實務落地建議 第 5 章：混合與共存導入指南 5.1 為何要混合方法論 5.2 相容性矩陣 5.3 分層組合模型 5.4 安裝順序與設定合併建議 5.5 已知衝突與注意事項 5.6 實務落地建議 第 6 章：三大情境實戰案例（銀行業） 6.1 情境一：Web Application 開發 6.2 情境二：逆向工程 6.3 情境三：框架升級 6.4 三情境 × 八方法論適配打分表 6.5 實務落地建議 第 7 章：方法論組合的維護與升級治理 7.1 為何需要「方法論組合」層級的治理 7.2 日常維運：版本釘選與相容性檢查 7.3 Prompt／Spec 版本控制與變更追蹤 7.4 治理委員會結構與 RACI 7.5 何時該汰換或升級方法論 7.6 法規遵循與稽核追溯（銀行/金融特別考量） 7.7 監控指標與健康度儀表板 7.8 實務落地建議 第 8 章：AI Agent 跨方法論協作範例 8.1 為何需要跨方法論/跨工具協作範例 8.2 範例一：Claude Code + Codex 共用 AGENTS.md 8.3 範例二：Copilot + Gemini/Grok 以 OpenSpec 仲裁 8.4 協作失敗模式與修復 8.5 實務落地建議 第 9 章：方法論選型與整合 Prompt Library 9.1 團隊 AI 成熟度現況評估 Prompt 9.2 方法論選型建議 Prompt 9.3 兩方法論相容性檢查 Prompt 9.4 治理文件骨架生成 Prompt 9.5 情境對應方法論組合 Prompt 9.6 方法論汰換/遷移評估 Prompt 9.7 實務落地建議 第 10 章：常見問題（FAQ） 附錄 A：快速選型與導入檢查清單 附錄 B：八方法論／五工具／三情境速查表 附錄 C：名詞釋義與命名辨正 附錄 D：參考資源與延伸閱讀 附錄 E：八大方法論安裝教學速查 前言 為什麼需要這份手冊 過去兩年間，「用 AI 寫程式」已經從個人的 Prompt 技巧，演化成一整套可被治理、可被複製、可被稽核的方法論（Methodology）。截至本文件撰寫時，僅在本專案的 .github\\教學\\AI開發\\ 目錄下，就已經累積了 spec-kit、OpenSpec、Superpowers、BMAD-METHOD、GSD、gsd-pi（GSD-2）、gstack、mattpocock/skills 等 8 套獨立、完整、動輒 2,500～7,300 行的教學手冊 —— 每一套都宣稱自己能提升 AI 協作品質，每一套都有各自的哲學、安裝方式與最佳實務。\n","title":"AI常用方法論比較教學手冊"},{"content":"Orca 教學手冊（企業級實戰版） 版本對應：Orca GitHub Release v1.4.150（查證日期：2026-07-22） 適用對象：資深軟體工程師、技術主管、平台工程（Platform Engineering）團隊、DevOps／SRE、AI Solution Architect、AI Agent Architect 技術棧範圍：Electron 桌面應用、Git Worktree、~29 種 Coding Agent CLI（Claude Code、Codex、OpenCode、Cursor、Copilot 等）、SSH／VPS 遠端執行、GitHub、Linear 文件等級：企業內部開發規範／教學手冊（實戰與維運導向） 參考來源：\n官方 GitHub Repository：https://github.com/stablyai/orca 官方網站：https://www.onorca.dev/ Y Combinator 公司頁面：https://www.ycombinator.com/companies/stably-ai-orca ⚠️ 版本快照提醒：Orca 採近乎每日發版節奏（查證當下最新版本為 v1.4.150），本手冊內容為特定時間點之快照整理。正式導入前，請務必以官方 GitHub Repository 與官方文件站當下內容為準。凡本手冊中涉及尚未於官方文件明確證實的內容，均已以「⚠️」、「依推論」、「屬社群驗證路徑」等字樣清楚標註，請讀者審慎查證後再應用於正式環境，切勿將教學示例（案例研究章節）誤認為真實客戶專案。\n目錄 第一章 Orca 概述與工具定位比較 第二章 核心特色 第三章 系統架構 第四章 安裝與環境建置 第五章 建立第一個 Workspace 第六章 Provider 設定與 Agent 帳號管理 第七章 Agent 管理 第八章 Parallel Agents 平行代理實戰 第九章 AI Coding Workflow 第十章 企業 Web 應用程式開發案例 第十一章 舊系統逆向工程 第十二章 Framework Upgrade 框架升級 第十三章 Agent Collaboration 協作角色分工 第十四章 Git Integration 第十五章 Source Control 版本控管 第十六章 Mobile App 行動裝置應用 第十七章 VPS 與遠端部署 第十八章 Prompt Engineering 第十九章 AI Team 企業 AI 團隊 第二十章 Banking 銀行核心系統案例 第二十一章 系統維護 第二十二章 效能最佳化 第二十三章 常見錯誤與 FAQ 第二十四章 最佳實務 第二十五章 與其他工具比較 第二十六章 建議導入方式 第二十七章 完整企業案例 第二十八章 Mermaid 圖表彙整 第二十九章 Prompt Library 第三十章 總結 子目錄（詳細版） 以下為全書所有小節的完整索引，依章節分組，每一條皆可直接點擊連結到本文對應位置。若只需要快速定位特定主題（如「WSL」「GitLab」「語音輸入」），建議使用編輯器或瀏覽器的頁內搜尋（Ctrl+F／Cmd+F）搭配本目錄關鍵字查找。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/orca-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Orca 教學手冊（企業級實戰版） 版本對應：Orca GitHub Release v1.4.150（查證日期：2026-07-22） 適用對象：資深軟體工程師、技術主管、平台工程（Platform Engineering）團隊、DevOps／SRE、AI Solution Architect、AI Agent Architect 技術棧範圍：Electron 桌面應用、Git Worktree、~29 種 Coding Agent CLI（Claude Code、Codex、OpenCode、Cursor、Copilot 等）、SSH／VPS 遠端執行、GitHub、Linear 文件等級：企業內部開發規範／教學手冊（實戰與維運導向） 參考來源：\n官方 GitHub Repository：https://github.com/stablyai/orca 官方網站：https://www.onorca.dev/ Y Combinator 公司頁面：https://www.ycombinator.com/companies/stably-ai-orca ⚠️ 版本快照提醒：Orca 採近乎每日發版節奏（查證當下最新版本為 v1.4.150），本手冊內容為特定時間點之快照整理。正式導入前，請務必以官方 GitHub Repository 與官方文件站當下內容為準。凡本手冊中涉及尚未於官方文件明確證實的內容，均已以「⚠️」、「依推論」、「屬社群驗證路徑」等字樣清楚標註，請讀者審慎查證後再應用於正式環境，切勿將教學示例（案例研究章節）誤認為真實客戶專案。\n目錄 第一章 Orca 概述與工具定位比較 第二章 核心特色 第三章 系統架構 第四章 安裝與環境建置 第五章 建立第一個 Workspace 第六章 Provider 設定與 Agent 帳號管理 第七章 Agent 管理 第八章 Parallel Agents 平行代理實戰 第九章 AI Coding Workflow 第十章 企業 Web 應用程式開發案例 第十一章 舊系統逆向工程 第十二章 Framework Upgrade 框架升級 第十三章 Agent Collaboration 協作角色分工 第十四章 Git Integration 第十五章 Source Control 版本控管 第十六章 Mobile App 行動裝置應用 第十七章 VPS 與遠端部署 第十八章 Prompt Engineering 第十九章 AI Team 企業 AI 團隊 第二十章 Banking 銀行核心系統案例 第二十一章 系統維護 第二十二章 效能最佳化 第二十三章 常見錯誤與 FAQ 第二十四章 最佳實務 第二十五章 與其他工具比較 第二十六章 建議導入方式 第二十七章 完整企業案例 第二十八章 Mermaid 圖表彙整 第二十九章 Prompt Library 第三十章 總結 子目錄（詳細版） 以下為全書所有小節的完整索引，依章節分組，每一條皆可直接點擊連結到本文對應位置。若只需要快速定位特定主題（如「WSL」「GitLab」「語音輸入」），建議使用編輯器或瀏覽器的頁內搜尋（Ctrl+F／Cmd+F）搭配本目錄關鍵字查找。\n","title":"Orca 教學手冊"},{"content":"HyperFrames 教學手冊 ⚠️ 版本快照提醒： 本手冊內容係於 2026-07-21 查證撰寫，主要依據 HyperFrames 官方 GitHub Repository（github.com/heygen-com/hyperframes）、官方文件站（hyperframes.heygen.com）、README.md、AGENTS.md、CONTRIBUTING.md、SECURITY.md、CLI Reference、GSAP Integration Guide、AWS Lambda Deploy Guide、Troubleshooting Guide 等第一手來源整理而成。HyperFrames 是一個仍在快速迭代（0.x 版本）的開源專案，CLI flag、Skill 數量、套件結構皆可能隨版本演進而變動，實作前請務必以 npx hyperframes --help、npx hyperframes doctor 與官方文件站最新內容為準。\n本手冊不是官方文件的翻譯本。全書所有章節皆經過重新消化整理，並大量加入企業導入視角的架構分析、實務踩雷經驗、最佳實務與 AI Agent 協作建議——這些內容多數不會出現在官方文件中，而是撰寫團隊依據 HTML/影片渲染架構的一般工程常識、與其他無頭瀏覽器渲染系統（如 Puppeteer/Playwright 自動化測試、CI 影片生成管線）的實務經驗類比而來，並會在文中以「實務建議」「踩雷經驗」「企業導入提醒」等字樣明確標示，與官方原文（以引號或「官方文件指出」標註）做區隔，避免讀者誤將顧問建議當成官方保證。\n主要參考來源：\nGitHub：github.com/heygen-com/hyperframes（README、AGENTS.md、CONTRIBUTING.md、SECURITY.md、DESIGN.md、skills/目錄下全部 19 個 Skill、packages/目錄下全部套件、CHANGELOG／Releases） 官方文件站：hyperframes.heygen.com（introduction、quickstart、changelog、guides/gsap-animation、guides/hyperframes-vs-remotion、guides/claude-design、guides/troubleshooting、packages/core、packages/cli、deploy/aws-lambda、deploy/gcp-cloud-run、examples、catalog） 社群playground：hyperframes.dev 本次（2026-07-21）更新已重新查證上述來源之現況，修正若干先前版本的命名誤差（如第六章 Adapter 命名）、CI/雲端渲染新功能（見第十章、第十四章、第三十二章），並補強目錄的章節／小節雙層連結（見下方目錄）。\n目錄 使用建議 前言 是什麼 發展背景與解決的問題 與其他影片框架的差異（初覽，完整比較見第四十章） 適合哪些人／不適合哪些人 典型使用情境 第一章 HyperFrames 深度導論 1.1 三大受眾定位再展開 1.2 典型案例深探：從一支 Landing Page 到一支社群影片 第二章 整體系統架構 2.1 分層架構總覽 2.2 資料流與控制流 2.3 Component Diagram：套件依賴關係 第三章 HyperFrames 工作流程 3.1 六步驟完整渲染流程 3.2 HTML → Animation → Frame → Capture → Encode → MP4 各階段細節 第四章 Rendering Engine 4.1 Deterministic Rendering 的技術本質 4.2 Frame Timeline 與 Seek 機制 4.3 Timing / FPS / Resolution / Color / Codec / Quality 全解析 4.4 Color 與 Codec 的取捨建議 第五章 HTML Render Pipeline 5.1 DOM／CSS／JS 三層如何被渲染引擎消費 5.2 Canvas／SVG／WebGL／Three.js 5.3 Video／Audio／Image／Font 的渲染考量 第六章 Animation Adapter 完整解析 6.1 CSS Animation / CSS Transition 6.2 Web Animations API（WAAPI） 6.3 GSAP（官方最推薦） 6.4 Anime.js 6.5 Lottie 6.6 Three.js 6.7 TypeGPU/WebGPU（GPU 加速圖形，官方 Adapter） 6.8 手刻 Canvas 2D 程式化繪圖（技巧，非官方具名 Adapter） 6.9 SVG Animation Animation Adapter 選型總表 第七章 Skill System 7.1 什麼是 HyperFrames Skill 7.2 Router 決策邏輯詳解 7.3 AI 如何呼叫 HyperFrames Skill 7.4 Skill 版本維護協定（一個容易被忽略但很重要的細節） 第八章 AI Agent 整合總覽 8.1 為什麼 HyperFrames 特別強調 Agent 整合 8.2 各 AI 工具整合方式速覽 8.3 AI Agent 建立影片的標準迴圈 8.4 修改影片、重構動畫、自動生成 HTML 的差異 第九章 安裝與環境建置 9.1 系統需求總表 9.2 Windows 安裝流程 9.3 macOS 安裝流程 9.4 Linux（Ubuntu/Debian）安裝流程 9.5 WSL（Windows Subsystem for Linux）注意事項 9.6 Docker 安裝與 --docker 渲染模式 9.7 Podman 安裝與相容性 9.8 Chrome / FFmpeg 手動排除疑難 第十章 CLI 完整參考 10.1 專案建立類 10.2 預覽與發布類 10.3 驗證類 10.4 建置類 10.5 工具類 10.6 認證與雲端渲染類 10.7 完整環境變數表 第十一章 Configuration 完整設定 11.1 設定來源優先順序 11.2 Composition Variables（JSON 參數化） 11.3 JSON 設定範例：一個完整的 meta.json 11.4 YAML／CI 設定範例 第十二章 HTML Structure 12.1 Composition 根節點完整屬性表 12.2 Clip（時間軸元素）屬性表 12.3 Scene（場景）與 Layer（圖層）的組織方式 12.4 完整範例：一個帶有兩個場景的 Composition 第十三章 Animation 實戰 13.1 Timeline 與 Keyframe 混合實戰：一個 10 秒產品介紹片段 13.2 Keyframe 進階技巧：多段 Easing 交錯 13.3 CSS 與 GSAP 混用時的注意事項 第十四章 Media 處理 14.1 Image 14.2 Video 14.3 Audio 14.4 SVG 14.5 Canvas／GPU 圖形 14.6 Font 第十五章 FFmpeg 編碼與最佳化 15.1 FFmpeg 在整體渲染流程中的角色 15.2 容器格式與適用場合 15.3 Codec 參數調校 15.4 AV1 的取捨 15.5 GPU 加速編碼 第十六章 Browser 引擎 16.1 Headless Chrome 作為渲染核心 16.2 CDP（Chrome DevTools Protocol）的角色 16.3 Playwright／Puppeteer 與 HyperFrames 的關係 16.4 瀏覽器 GPU 加速 第十七章 API 參考 17.1 @hyperframes/core 總覽 17.2 核心型別 17.3 解析與 HTML 生成函式 17.4 GSAP 工具函式 17.5 Linter API 17.6 Compiler（Node.js 專用） 17.7 Runtime 與 Frame Adapter 17.8 媒體與樣式常數 17.9 實戰範例：Node.js 批次個人化渲染腳本 第十八章 專案目錄結構 18.1 官方 Monorepo 套件總覽 18.2 一般專案（hyperframes init 產出）的目錄結構 18.3 企業內部建議的擴充目錄慣例 第十九章 Examples 官方範例解析 19.1 官方九大範例模板總覽 19.2 手把手 Walkthrough：以 warm-grain 為基礎客製化一支 15 秒品牌影片 19.3 Catalog Block 範例：data-chart 第二十章 與 Claude Code 整合實戰 20.1 完整流程總覽 20.2 安裝與初始化 20.3 Claude Design 使用建議 20.4 Claude Code 內的典型 Prompt 範例 20.5 Workflow：Claude Code 內的分工模式 第二十一章 與 GitHub Copilot 整合實戰 21.1 現況：官方 Skill 系統尚未原生涵蓋 Copilot 21.2 補強做法：建立專案層級指引文件 21.3 Copilot Chat 實戰 Prompt 範例 21.4 Copilot CLI（gh copilot）搭配 HyperFrames CLI 第二十二章 與 Gemini CLI 整合實戰 22.1 安裝與初始化 22.2 完整流程 22.3 Gemini CLI 實戰 Prompt 範例 第二十三章 與 Cursor 整合實戰 23.1 安裝方式 23.2 Cursor Composer/Chat 實戰範例 23.3 Cursor 與 Claude Code 的分工建議 第二十四章 HyperFrames 協助 AI Agent 開發大型 Web Application 24.1 核心洞察：為什麼影片能加速大型系統開發？ 24.2 Vue 3 升級情境 24.3 Angular／React 升級情境 24.4 Spring Boot／Java 升級情境 24.5 Legacy System Modernization 與 Reverse Engineering 24.6 Framework Migration 與 Architecture Documentation 通用模式 第二十五章 企業影片自動化情境 25.1 API 文件影片 25.2 Architecture Demo（見 24.6 完整流程） 25.3 Training Video／教育訓練影片 25.4 CI/CD Demo 25.5 Release Note Video 25.6 系統操作影片 25.7 產品展示影片 25.8 AI 自動生成影片的品質守門機制 第二十六章 CI/CD 自動化 26.1 標準自動化渲染管線設計 26.2 GitHub Actions 完整範例 26.3 GitLab CI 完整範例 26.4 Azure DevOps Pipeline 範例 26.5 Jenkins Declarative Pipeline 範例 第二十七章 Docker 容器化部署 27.1 官方 --docker 模式 vs 自建映像檔 27.2 Dockerfile 範例 27.3 docker-compose.yml 範例：本機開發 + 渲染服務 第二十八章 Kubernetes 部署 28.1 部署模式選型 28.2 一次性渲染 Job 範例 28.3 定期批次渲染 CronJob 範例 28.4 常駐 Studio 預覽服務範例（Deployment + Service） 28.5 其他實務缺口：GPU 排程、Helm、私有 Registry、Pod Security（實務延伸） 第二十九章 Podman 部署 29.1 Podman 與 Docker 的核心差異回顧 29.2 使用 Podman 建置與執行 29.3 Podman Compose 範例 29.4 Podman + systemd（Quadlet）常駐服務範例 第三十章 Enterprise Best Practices 30.1 大型企業導入 HyperFrames 的階段性路徑 30.2 版本管理建議 30.3 資源管理 30.4 Media 管理 30.5 Template 管理 第三十一章 系統維護與升級 31.1 日常維護檢查清單 31.2 升級流程 31.3 如何避免 Breaking Change 造成的衝擊 31.4 Migration Guide：從 Remotion 遷移 第三十二章 Troubleshooting 32.1 環境與安裝類（1–8） 32.2 媒體與編碼類（9–15，第 9 題為官方，其餘為實務延伸） 32.3 動畫與 GSAP 類（16–24，全為實務延伸） 32.4 渲染與效能類（25–33，全為實務延伸） 32.5 CI/CD 與雲端類（34–40，全為實務延伸） 32.6 Skill／AI Agent 協作類（41–50，全為實務延伸） 第三十三章 Performance Tuning 33.1 效能瓶頸的四大來源 33.2 Chrome 層級調校 33.3 Animation 層級調校 33.4 Memory 管理 33.5 GPU 使用建議 33.6 FFmpeg 編碼調校（回顧第十五章並延伸） 第三十四章 Security 34.1 官方安全政策（Vulnerability Disclosure） 34.2 Headless Chrome 沙箱化建議（實務延伸） 34.3 憑證與 API 金鑰管理 34.4 素材與內容審核 34.5 網路層面建議 第三十五章 Logging 與 Monitoring 35.1 CLI 內建的可觀測性能力 35.2 建議監控的關鍵指標 35.3 日誌整合範例（概念示意） 35.4 建立渲染健康度儀表板 第三十六章 最佳實務總彙 36.1 架構與設計（1–10） 36.2 HTML／Composition 撰寫（11–20） 36.3 動畫實作（21–30） 36.4 媒體與素材（31–38） 36.5 CLI 與開發流程（39–48） 36.6 AI Agent 協作（49–58） 36.7 CI/CD（59–66） 36.8 容器化與部署（67–74） 36.9 效能調校（75–82） 36.10 安全（83–90） 36.11 企業治理（91–96） 36.12 團隊協作與文件（97–102） 第三十七章 Coding Style Guide 37.1 官方套件開發慣例（若團隊貢獻或自建 HyperFrames 相關套件） 37.2 Composition 專案的程式碼風格建議（實務延伸） 37.3 Node.js／TypeScript 腳本風格（使用 @hyperframes/core 時） 第三十八章 Prompt Engineering 與完整 Prompt 範例 38.1 讓 AI 工具更容易產生正確 HyperFrames 程式碼的核心原則 38.2 各工具的 Prompt 微調建議 38.3 完整 Prompt 範例庫（50 則，依情境分類） 第三十九章 Case Study 39.1 案例一：電商千人千面促銷影片 39.2 案例二：SaaS 產品「PR 到影片」自動化 39.3 案例三：金融業 Legacy 系統知識傳承 39.4 案例四：跨國零售集團多品牌一致性治理 39.5 案例五：教育科技公司個人化課程證書 39.6 案例六：企業內訓多語系教材規模化 39.7 案例七：新創公司從 Remotion 遷移 39.8 案例八：DevOps 團隊 CI/CD 視覺化 Demo 39.9 案例九：資料視覺化團隊自動化報告影片 39.10 案例十：客服團隊操作教學影片庫 第四十章 與其他框架比較 40.1 HyperFrames vs Remotion（官方比較，詳見前言與第三十一章 31.4） 40.2 HyperFrames vs Motion Canvas 40.3 HyperFrames vs FFCreator 40.4 HyperFrames vs PptxGenJS + FFmpeg 手動管線 40.5 HyperFrames vs Reveal.js Export 40.6 HyperFrames vs Playwright / Puppeteer Screenshot 方案 第四十一章 優缺點分析與未來 Roadmap 41.1 優點總結 41.2 缺點與限制總結 41.3 SWOT 簡要分析 41.4 未來 Roadmap 推論（依官方已知限制與產業趨勢推論，非官方公開路線圖） 第四十二章 附錄 42.1 名詞解釋（Glossary） 42.2 整合總覽表 42.3 CLI 速查表（完整版見第十章） 42.4 API 速查表（完整版見第十七章） 42.5 環境變數速查（彙整自全書各章，完整版見第十章 10.7） 42.6 Mermaid 速查（本書使用過的圖型範例） 42.7 Prompt 速查（完整 50 則見第三十八章） 42.8 Migration Checklist（從其他方案遷移時使用） 42.9 Deployment Checklist（部署上線時使用） 42.10 Security Checklist（資安上線前使用） 42.11 Production Checklist（正式上線最終確認） 42.12 延伸閱讀建議 42.13 全書總 Checklist 使用建議 HyperFrames 橫跨「前端渲染」「影片後製」「CLI/DevOps」「AI Agent 協作」四個領域，不同角色的讀者不需要從頭讀到尾。下表提供建議閱讀路徑：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/hyperframes-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"HyperFrames 教學手冊 ⚠️ 版本快照提醒： 本手冊內容係於 2026-07-21 查證撰寫，主要依據 HyperFrames 官方 GitHub Repository（github.com/heygen-com/hyperframes）、官方文件站（hyperframes.heygen.com）、README.md、AGENTS.md、CONTRIBUTING.md、SECURITY.md、CLI Reference、GSAP Integration Guide、AWS Lambda Deploy Guide、Troubleshooting Guide 等第一手來源整理而成。HyperFrames 是一個仍在快速迭代（0.x 版本）的開源專案，CLI flag、Skill 數量、套件結構皆可能隨版本演進而變動，實作前請務必以 npx hyperframes --help、npx hyperframes doctor 與官方文件站最新內容為準。\n本手冊不是官方文件的翻譯本。全書所有章節皆經過重新消化整理，並大量加入企業導入視角的架構分析、實務踩雷經驗、最佳實務與 AI Agent 協作建議——這些內容多數不會出現在官方文件中，而是撰寫團隊依據 HTML/影片渲染架構的一般工程常識、與其他無頭瀏覽器渲染系統（如 Puppeteer/Playwright 自動化測試、CI 影片生成管線）的實務經驗類比而來，並會在文中以「實務建議」「踩雷經驗」「企業導入提醒」等字樣明確標示，與官方原文（以引號或「官方文件指出」標註）做區隔，避免讀者誤將顧問建議當成官方保證。\n主要參考來源：\nGitHub：github.com/heygen-com/hyperframes（README、AGENTS.md、CONTRIBUTING.md、SECURITY.md、DESIGN.md、skills/目錄下全部 19 個 Skill、packages/目錄下全部套件、CHANGELOG／Releases） 官方文件站：hyperframes.heygen.com（introduction、quickstart、changelog、guides/gsap-animation、guides/hyperframes-vs-remotion、guides/claude-design、guides/troubleshooting、packages/core、packages/cli、deploy/aws-lambda、deploy/gcp-cloud-run、examples、catalog） 社群playground：hyperframes.dev 本次（2026-07-21）更新已重新查證上述來源之現況，修正若干先前版本的命名誤差（如第六章 Adapter 命名）、CI/雲端渲染新功能（見第十章、第十四章、第三十二章），並補強目錄的章節／小節雙層連結（見下方目錄）。\n目錄 使用建議 前言 是什麼 發展背景與解決的問題 與其他影片框架的差異（初覽，完整比較見第四十章） 適合哪些人／不適合哪些人 典型使用情境 第一章 HyperFrames 深度導論 1.1 三大受眾定位再展開 1.2 典型案例深探：從一支 Landing Page 到一支社群影片 第二章 整體系統架構 2.1 分層架構總覽 2.2 資料流與控制流 2.3 Component Diagram：套件依賴關係 第三章 HyperFrames 工作流程 3.1 六步驟完整渲染流程 3.2 HTML → Animation → Frame → Capture → Encode → MP4 各階段細節 第四章 Rendering Engine 4.1 Deterministic Rendering 的技術本質 4.2 Frame Timeline 與 Seek 機制 4.3 Timing / FPS / Resolution / Color / Codec / Quality 全解析 4.4 Color 與 Codec 的取捨建議 第五章 HTML Render Pipeline 5.1 DOM／CSS／JS 三層如何被渲染引擎消費 5.2 Canvas／SVG／WebGL／Three.js 5.3 Video／Audio／Image／Font 的渲染考量 第六章 Animation Adapter 完整解析 6.1 CSS Animation / CSS Transition 6.2 Web Animations API（WAAPI） 6.3 GSAP（官方最推薦） 6.4 Anime.js 6.5 Lottie 6.6 Three.js 6.7 TypeGPU/WebGPU（GPU 加速圖形，官方 Adapter） 6.8 手刻 Canvas 2D 程式化繪圖（技巧，非官方具名 Adapter） 6.9 SVG Animation Animation Adapter 選型總表 第七章 Skill System 7.1 什麼是 HyperFrames Skill 7.2 Router 決策邏輯詳解 7.3 AI 如何呼叫 HyperFrames Skill 7.4 Skill 版本維護協定（一個容易被忽略但很重要的細節） 第八章 AI Agent 整合總覽 8.1 為什麼 HyperFrames 特別強調 Agent 整合 8.2 各 AI 工具整合方式速覽 8.3 AI Agent 建立影片的標準迴圈 8.4 修改影片、重構動畫、自動生成 HTML 的差異 第九章 安裝與環境建置 9.1 系統需求總表 9.2 Windows 安裝流程 9.3 macOS 安裝流程 9.4 Linux（Ubuntu/Debian）安裝流程 9.5 WSL（Windows Subsystem for Linux）注意事項 9.6 Docker 安裝與 --docker 渲染模式 9.7 Podman 安裝與相容性 9.8 Chrome / FFmpeg 手動排除疑難 第十章 CLI 完整參考 10.1 專案建立類 10.2 預覽與發布類 10.3 驗證類 10.4 建置類 10.5 工具類 10.6 認證與雲端渲染類 10.7 完整環境變數表 第十一章 Configuration 完整設定 11.1 設定來源優先順序 11.2 Composition Variables（JSON 參數化） 11.3 JSON 設定範例：一個完整的 meta.json 11.4 YAML／CI 設定範例 第十二章 HTML Structure 12.1 Composition 根節點完整屬性表 12.2 Clip（時間軸元素）屬性表 12.3 Scene（場景）與 Layer（圖層）的組織方式 12.4 完整範例：一個帶有兩個場景的 Composition 第十三章 Animation 實戰 13.1 Timeline 與 Keyframe 混合實戰：一個 10 秒產品介紹片段 13.2 Keyframe 進階技巧：多段 Easing 交錯 13.3 CSS 與 GSAP 混用時的注意事項 第十四章 Media 處理 14.1 Image 14.2 Video 14.3 Audio 14.4 SVG 14.5 Canvas／GPU 圖形 14.6 Font 第十五章 FFmpeg 編碼與最佳化 15.1 FFmpeg 在整體渲染流程中的角色 15.2 容器格式與適用場合 15.3 Codec 參數調校 15.4 AV1 的取捨 15.5 GPU 加速編碼 第十六章 Browser 引擎 16.1 Headless Chrome 作為渲染核心 16.2 CDP（Chrome DevTools Protocol）的角色 16.3 Playwright／Puppeteer 與 HyperFrames 的關係 16.4 瀏覽器 GPU 加速 第十七章 API 參考 17.1 @hyperframes/core 總覽 17.2 核心型別 17.3 解析與 HTML 生成函式 17.4 GSAP 工具函式 17.5 Linter API 17.6 Compiler（Node.js 專用） 17.7 Runtime 與 Frame Adapter 17.8 媒體與樣式常數 17.9 實戰範例：Node.js 批次個人化渲染腳本 第十八章 專案目錄結構 18.1 官方 Monorepo 套件總覽 18.2 一般專案（hyperframes init 產出）的目錄結構 18.3 企業內部建議的擴充目錄慣例 第十九章 Examples 官方範例解析 19.1 官方九大範例模板總覽 19.2 手把手 Walkthrough：以 warm-grain 為基礎客製化一支 15 秒品牌影片 19.3 Catalog Block 範例：data-chart 第二十章 與 Claude Code 整合實戰 20.1 完整流程總覽 20.2 安裝與初始化 20.3 Claude Design 使用建議 20.4 Claude Code 內的典型 Prompt 範例 20.5 Workflow：Claude Code 內的分工模式 第二十一章 與 GitHub Copilot 整合實戰 21.1 現況：官方 Skill 系統尚未原生涵蓋 Copilot 21.2 補強做法：建立專案層級指引文件 21.3 Copilot Chat 實戰 Prompt 範例 21.4 Copilot CLI（gh copilot）搭配 HyperFrames CLI 第二十二章 與 Gemini CLI 整合實戰 22.1 安裝與初始化 22.2 完整流程 22.3 Gemini CLI 實戰 Prompt 範例 第二十三章 與 Cursor 整合實戰 23.1 安裝方式 23.2 Cursor Composer/Chat 實戰範例 23.3 Cursor 與 Claude Code 的分工建議 第二十四章 HyperFrames 協助 AI Agent 開發大型 Web Application 24.1 核心洞察：為什麼影片能加速大型系統開發？ 24.2 Vue 3 升級情境 24.3 Angular／React 升級情境 24.4 Spring Boot／Java 升級情境 24.5 Legacy System Modernization 與 Reverse Engineering 24.6 Framework Migration 與 Architecture Documentation 通用模式 第二十五章 企業影片自動化情境 25.1 API 文件影片 25.2 Architecture Demo（見 24.6 完整流程） 25.3 Training Video／教育訓練影片 25.4 CI/CD Demo 25.5 Release Note Video 25.6 系統操作影片 25.7 產品展示影片 25.8 AI 自動生成影片的品質守門機制 第二十六章 CI/CD 自動化 26.1 標準自動化渲染管線設計 26.2 GitHub Actions 完整範例 26.3 GitLab CI 完整範例 26.4 Azure DevOps Pipeline 範例 26.5 Jenkins Declarative Pipeline 範例 第二十七章 Docker 容器化部署 27.1 官方 --docker 模式 vs 自建映像檔 27.2 Dockerfile 範例 27.3 docker-compose.yml 範例：本機開發 + 渲染服務 第二十八章 Kubernetes 部署 28.1 部署模式選型 28.2 一次性渲染 Job 範例 28.3 定期批次渲染 CronJob 範例 28.4 常駐 Studio 預覽服務範例（Deployment + Service） 28.5 其他實務缺口：GPU 排程、Helm、私有 Registry、Pod Security（實務延伸） 第二十九章 Podman 部署 29.1 Podman 與 Docker 的核心差異回顧 29.2 使用 Podman 建置與執行 29.3 Podman Compose 範例 29.4 Podman + systemd（Quadlet）常駐服務範例 第三十章 Enterprise Best Practices 30.1 大型企業導入 HyperFrames 的階段性路徑 30.2 版本管理建議 30.3 資源管理 30.4 Media 管理 30.5 Template 管理 第三十一章 系統維護與升級 31.1 日常維護檢查清單 31.2 升級流程 31.3 如何避免 Breaking Change 造成的衝擊 31.4 Migration Guide：從 Remotion 遷移 第三十二章 Troubleshooting 32.1 環境與安裝類（1–8） 32.2 媒體與編碼類（9–15，第 9 題為官方，其餘為實務延伸） 32.3 動畫與 GSAP 類（16–24，全為實務延伸） 32.4 渲染與效能類（25–33，全為實務延伸） 32.5 CI/CD 與雲端類（34–40，全為實務延伸） 32.6 Skill／AI Agent 協作類（41–50，全為實務延伸） 第三十三章 Performance Tuning 33.1 效能瓶頸的四大來源 33.2 Chrome 層級調校 33.3 Animation 層級調校 33.4 Memory 管理 33.5 GPU 使用建議 33.6 FFmpeg 編碼調校（回顧第十五章並延伸） 第三十四章 Security 34.1 官方安全政策（Vulnerability Disclosure） 34.2 Headless Chrome 沙箱化建議（實務延伸） 34.3 憑證與 API 金鑰管理 34.4 素材與內容審核 34.5 網路層面建議 第三十五章 Logging 與 Monitoring 35.1 CLI 內建的可觀測性能力 35.2 建議監控的關鍵指標 35.3 日誌整合範例（概念示意） 35.4 建立渲染健康度儀表板 第三十六章 最佳實務總彙 36.1 架構與設計（1–10） 36.2 HTML／Composition 撰寫（11–20） 36.3 動畫實作（21–30） 36.4 媒體與素材（31–38） 36.5 CLI 與開發流程（39–48） 36.6 AI Agent 協作（49–58） 36.7 CI/CD（59–66） 36.8 容器化與部署（67–74） 36.9 效能調校（75–82） 36.10 安全（83–90） 36.11 企業治理（91–96） 36.12 團隊協作與文件（97–102） 第三十七章 Coding Style Guide 37.1 官方套件開發慣例（若團隊貢獻或自建 HyperFrames 相關套件） 37.2 Composition 專案的程式碼風格建議（實務延伸） 37.3 Node.js／TypeScript 腳本風格（使用 @hyperframes/core 時） 第三十八章 Prompt Engineering 與完整 Prompt 範例 38.1 讓 AI 工具更容易產生正確 HyperFrames 程式碼的核心原則 38.2 各工具的 Prompt 微調建議 38.3 完整 Prompt 範例庫（50 則，依情境分類） 第三十九章 Case Study 39.1 案例一：電商千人千面促銷影片 39.2 案例二：SaaS 產品「PR 到影片」自動化 39.3 案例三：金融業 Legacy 系統知識傳承 39.4 案例四：跨國零售集團多品牌一致性治理 39.5 案例五：教育科技公司個人化課程證書 39.6 案例六：企業內訓多語系教材規模化 39.7 案例七：新創公司從 Remotion 遷移 39.8 案例八：DevOps 團隊 CI/CD 視覺化 Demo 39.9 案例九：資料視覺化團隊自動化報告影片 39.10 案例十：客服團隊操作教學影片庫 第四十章 與其他框架比較 40.1 HyperFrames vs Remotion（官方比較，詳見前言與第三十一章 31.4） 40.2 HyperFrames vs Motion Canvas 40.3 HyperFrames vs FFCreator 40.4 HyperFrames vs PptxGenJS + FFmpeg 手動管線 40.5 HyperFrames vs Reveal.js Export 40.6 HyperFrames vs Playwright / Puppeteer Screenshot 方案 第四十一章 優缺點分析與未來 Roadmap 41.1 優點總結 41.2 缺點與限制總結 41.3 SWOT 簡要分析 41.4 未來 Roadmap 推論（依官方已知限制與產業趨勢推論，非官方公開路線圖） 第四十二章 附錄 42.1 名詞解釋（Glossary） 42.2 整合總覽表 42.3 CLI 速查表（完整版見第十章） 42.4 API 速查表（完整版見第十七章） 42.5 環境變數速查（彙整自全書各章，完整版見第十章 10.7） 42.6 Mermaid 速查（本書使用過的圖型範例） 42.7 Prompt 速查（完整 50 則見第三十八章） 42.8 Migration Checklist（從其他方案遷移時使用） 42.9 Deployment Checklist（部署上線時使用） 42.10 Security Checklist（資安上線前使用） 42.11 Production Checklist（正式上線最終確認） 42.12 延伸閱讀建議 42.13 全書總 Checklist 使用建議 HyperFrames 橫跨「前端渲染」「影片後製」「CLI/DevOps」「AI Agent 協作」四個領域，不同角色的讀者不需要從頭讀到尾。下表提供建議閱讀路徑：\n","title":"Hyperframes 教學手冊"},{"content":"Council of High Intelligence 教學手冊 副標題： AI 多角色辯論（Multi-Persona Deliberation）框架完整指南 版本／查證基準： v1.2.0（2026-07-04 發布，查證截至 2026-07-20） 適用對象： 資深 Software Architect、Tech Lead、AI Agent Engineer、Prompt Engineer、DevOps／平台工程師、System Analyst、企業導入決策負責人、AI Coding 導入教育訓練講師 技術棧： Shell Script（81.5%）＋ Python（18.5%）、Claude Code Plugin／Skill 協定（SKILL.md）、多 LLM 供應商自動路由（Claude／OpenAI／Google／Ollama／NVIDIA NIM／Cursor） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： 0xNyk/council-of-high-intelligence 官方 Repository（README.md、CHANGELOG.md、SKILL.md 及其三份主機鏡像、agents/ 目錄下 18 份 persona 契約文件、demos/session-pack.md、install.sh、CONTRIBUTING.md、SECURITY.md、configs/provider-model-slots.example.yaml、GitHub Issues），並以自身企業軟體架構、AI Coding 導入與教育訓練經驗重新消化整理，非逐字翻譯官方文案。\n⚠️ 版本快照提醒： Council of High Intelligence 是一個仍在快速迭代的開源專案（MIT License，查證當下約 3.7k ★、9 forks、19 watchers）。查證當下最新版本為 v1.2.0（2026-07-04 發布），距今僅約兩週，v1.2.0 才剛修復一個 Shell Injection 漏洞（舊版把 Prompt 內容直接內嵌進雙引號 shell argv 組出外部呼叫指令，導致 API 金鑰可能經由 ps 可見的 process 參數外洩；修復方式是改用加引號的 heredoc 傳遞 Prompt 內容，避免內容直接暴露在指令列參數中），也才剛加入「信心加權投票」「Plugin Marketplace 安裝」等機制。專案目前仍有多個開放 issue 反映出「多份主機鏡像檔案（SKILL.md / SKILL.codex.md / SKILL.gemini.md / SKILL.opencode.md）容易互相漂移」「detect-providers.sh 誤判 Ollama 可用性」等工程成熟度議題。本手冊所有具體事實（指令、參數、Persona 名單、Triad 名單等）均查證截至 2026-07-20，企業導入前務必以官方最新 README 與 CHANGELOG.md 再次核對，避免版本落差造成誤用。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/council-of-high-intelligence-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Council of High Intelligence 教學手冊 副標題： AI 多角色辯論（Multi-Persona Deliberation）框架完整指南 版本／查證基準： v1.2.0（2026-07-04 發布，查證截至 2026-07-20） 適用對象： 資深 Software Architect、Tech Lead、AI Agent Engineer、Prompt Engineer、DevOps／平台工程師、System Analyst、企業導入決策負責人、AI Coding 導入教育訓練講師 技術棧： Shell Script（81.5%）＋ Python（18.5%）、Claude Code Plugin／Skill 協定（SKILL.md）、多 LLM 供應商自動路由（Claude／OpenAI／Google／Ollama／NVIDIA NIM／Cursor） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： 0xNyk/council-of-high-intelligence 官方 Repository（README.md、CHANGELOG.md、SKILL.md 及其三份主機鏡像、agents/ 目錄下 18 份 persona 契約文件、demos/session-pack.md、install.sh、CONTRIBUTING.md、SECURITY.md、configs/provider-model-slots.example.yaml、GitHub Issues），並以自身企業軟體架構、AI Coding 導入與教育訓練經驗重新消化整理，非逐字翻譯官方文案。\n⚠️ 版本快照提醒： Council of High Intelligence 是一個仍在快速迭代的開源專案（MIT License，查證當下約 3.7k ★、9 forks、19 watchers）。查證當下最新版本為 v1.2.0（2026-07-04 發布），距今僅約兩週，v1.2.0 才剛修復一個 Shell Injection 漏洞（舊版把 Prompt 內容直接內嵌進雙引號 shell argv 組出外部呼叫指令，導致 API 金鑰可能經由 ps 可見的 process 參數外洩；修復方式是改用加引號的 heredoc 傳遞 Prompt 內容，避免內容直接暴露在指令列參數中），也才剛加入「信心加權投票」「Plugin Marketplace 安裝」等機制。專案目前仍有多個開放 issue 反映出「多份主機鏡像檔案（SKILL.md / SKILL.codex.md / SKILL.gemini.md / SKILL.opencode.md）容易互相漂移」「detect-providers.sh 誤判 Ollama 可用性」等工程成熟度議題。本手冊所有具體事實（指令、參數、Persona 名單、Triad 名單等）均查證截至 2026-07-20，企業導入前務必以官方最新 README 與 CHANGELOG.md 再次核對，避免版本落差造成誤用。\n","title":"Council of High Intelligence 教學手冊"},{"content":"Cognee 教學手冊 副標題： Enterprise AI Memory Platform \u0026amp; Knowledge Graph for AI Agents 版本： v1.3.0 系列（查證截至 2026-07-15） 適用對象： 資深後端／AI 應用工程師、企業級 Java／Spring Boot 架構師、AI Agent 架構師、知識圖譜與 RAG 系統負責人、DevSecOps 顧問、Tech Lead 技術棧： Python 3.11+、PostgreSQL（含 pgvector）／Neo4j／SQLite、Docker、MCP（Model Context Protocol） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： topoteretes/cognee 官方 Repository（README、docs/、cognee-mcp/）、官方文件站 docs.cognee.ai（Getting Started、Core Concepts、Setup Configuration、Guides、Integrations 等頁面）、官方網站 cognee.ai、研究論文《Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning》（arXiv:2505.24478），並以自身企業架構經驗重新消化整理，非逐字翻譯官方文案。\n⚠️ 版本快照提醒： Cognee 是一個仍在快速迭代中的開源專案（Apache-2.0 授權，查證時點約 27.9k ★、2.8k fork，8,600+ commits）。查證當下最新版本約為 v1.3.0（2026-07-12 發布）。特別注意：Cognee v1.0 之後的公開 API 已從早期的 add() + cognify() + search() 三段式，演進為更高階的 remember() / recall() / forget() / improve() 四個動詞；本手冊第三章會完整說明兩者的對應關係與歷史脈絡。本文所有具體事實（指令、參數、套件名稱等）均查證截至 2026-07-15，企業導入前務必以官方最新文件（docs.cognee.ai）再次核對，避免版本落差造成的認知落差。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/cognee-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Cognee 教學手冊 副標題： Enterprise AI Memory Platform \u0026amp; Knowledge Graph for AI Agents 版本： v1.3.0 系列（查證截至 2026-07-15） 適用對象： 資深後端／AI 應用工程師、企業級 Java／Spring Boot 架構師、AI Agent 架構師、知識圖譜與 RAG 系統負責人、DevSecOps 顧問、Tech Lead 技術棧： Python 3.11+、PostgreSQL（含 pgvector）／Neo4j／SQLite、Docker、MCP（Model Context Protocol） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： topoteretes/cognee 官方 Repository（README、docs/、cognee-mcp/）、官方文件站 docs.cognee.ai（Getting Started、Core Concepts、Setup Configuration、Guides、Integrations 等頁面）、官方網站 cognee.ai、研究論文《Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning》（arXiv:2505.24478），並以自身企業架構經驗重新消化整理，非逐字翻譯官方文案。\n⚠️ 版本快照提醒： Cognee 是一個仍在快速迭代中的開源專案（Apache-2.0 授權，查證時點約 27.9k ★、2.8k fork，8,600+ commits）。查證當下最新版本約為 v1.3.0（2026-07-12 發布）。特別注意：Cognee v1.0 之後的公開 API 已從早期的 add() + cognify() + search() 三段式，演進為更高階的 remember() / recall() / forget() / improve() 四個動詞；本手冊第三章會完整說明兩者的對應關係與歷史脈絡。本文所有具體事實（指令、參數、套件名稱等）均查證截至 2026-07-15，企業導入前務必以官方最新文件（docs.cognee.ai）再次核對，避免版本落差造成的認知落差。\n","title":"Cognee 教學手冊"},{"content":"Astryx 教學手冊（企業級實戰版） 版本： v1.1（2026-07-09 查證更新） 適用對象： 資深前端工程師、React 架構師、Design System 負責人、AI 開發導入團隊 技術棧： React 19+、TypeScript 5.x、StyleX、Node.js（一般使用無版控要求；貢獻原始碼建議 22 LTS） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： facebook/astryx 官方 Repository（README、CONTRIBUTING.md）、官方文件站 astryx.atmeta.com（Getting Started、CLI、Components、Typography 等頁面）、官方部落格 Introducing Astryx、npm registry（@astryxdesign/* 系列套件）、第三方報導（MarkTechPost、Tech Times），並以自身架構經驗重新消化整理，非逐字翻譯\n⚠️ 版本快照提醒： Astryx 為 Meta 於 2026 年 1 月建立、2026 年 6 月底以 Beta 身分正式對外發布的新專案（查證時點：GitHub 7,314 ★、487 fork、MIT 授權）。專案仍在快速迭代中，本文所有具體事實（元件命名、CLI 指令、Token 架構等）均查證截至 2026-07-09，企業導入前務必以官方最新文件（astryx.atmeta.com）再次確認，避免版本落差造成的認知落差。\n目錄 使用建議 前言 第一章 Astryx Overview 第二章 Architecture 第三章 Installation 第四章 Project Structure 第五章 CLI 第六章 Components 第七章 Theme System 第八章 Accessibility 第九章 AI Agent Ready 第十章 與其他 Design System 比較 第十一章 與 AI Coding 整合 第十二章 Reverse Engineering 第十三章 Framework Upgrade 第十四章 Enterprise Best Practice 第十五章 與 GitHub Copilot 整合 第十六章 與 Claude Code 整合 第十七章 系統維護 第十八章 系統升級 第十九章 FAQ 第二十章 Troubleshooting 第二十一章 Best Practice（企業最佳實務 100 條） 第二十二章 Prompt Collection 第二十三章 Case Study 第二十四章 Conclusion 使用建議 依讀者角色不同，建議的閱讀路徑如下，不需要從頭到尾逐章閱讀：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/astryx-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Astryx 教學手冊（企業級實戰版） 版本： v1.1（2026-07-09 查證更新） 適用對象： 資深前端工程師、React 架構師、Design System 負責人、AI 開發導入團隊 技術棧： React 19+、TypeScript 5.x、StyleX、Node.js（一般使用無版控要求；貢獻原始碼建議 22 LTS） 文件等級： 企業標準教育訓練教材（實戰與維運導向） 參考來源： facebook/astryx 官方 Repository（README、CONTRIBUTING.md）、官方文件站 astryx.atmeta.com（Getting Started、CLI、Components、Typography 等頁面）、官方部落格 Introducing Astryx、npm registry（@astryxdesign/* 系列套件）、第三方報導（MarkTechPost、Tech Times），並以自身架構經驗重新消化整理，非逐字翻譯\n⚠️ 版本快照提醒： Astryx 為 Meta 於 2026 年 1 月建立、2026 年 6 月底以 Beta 身分正式對外發布的新專案（查證時點：GitHub 7,314 ★、487 fork、MIT 授權）。專案仍在快速迭代中，本文所有具體事實（元件命名、CLI 指令、Token 架構等）均查證截至 2026-07-09，企業導入前務必以官方最新文件（astryx.atmeta.com）再次確認，避免版本落差造成的認知落差。\n目錄 使用建議 前言 第一章 Astryx Overview 第二章 Architecture 第三章 Installation 第四章 Project Structure 第五章 CLI 第六章 Components 第七章 Theme System 第八章 Accessibility 第九章 AI Agent Ready 第十章 與其他 Design System 比較 第十一章 與 AI Coding 整合 第十二章 Reverse Engineering 第十三章 Framework Upgrade 第十四章 Enterprise Best Practice 第十五章 與 GitHub Copilot 整合 第十六章 與 Claude Code 整合 第十七章 系統維護 第十八章 系統升級 第十九章 FAQ 第二十章 Troubleshooting 第二十一章 Best Practice（企業最佳實務 100 條） 第二十二章 Prompt Collection 第二十三章 Case Study 第二十四章 Conclusion 使用建議 依讀者角色不同，建議的閱讀路徑如下，不需要從頭到尾逐章閱讀：\n","title":"Astryx 教學手冊"},{"content":"Strix 完整教學手冊（Enterprise Edition） AI Agent 自動化滲透測試．AI Security Testing．DevSecOps．Secure SDLC．CI/CD Security．Framework Upgrade Security．Reverse Engineering Security\n📖 本手冊撰寫依據：本手冊內容根據 Strix（github.com/usestrix/strix，官方文件 docs.strix.ai）之公開原始碼、官方文件與 Release 資訊重新理解、消化後撰寫而成，並非官方 README 之翻譯或複製。文中會明確標註「已於官方原始碼/文件驗證」與「概念性說明、建議讀者自行對照最新原始碼確認」兩類內容，避免將未證實的細節當作官方保證的規格陳述。Strix 是一個仍在快速迭代（Apache-2.0 授權）的開源專案，實際旗標、環境變數與行為請務必以當下版本之官方 repo 為準。\n⚠️ 使用倫理提醒：Strix 屬於「主動攻擊型」AI Agent 安全測試工具，具備實際發起滲透測試行為的能力（注入、越權嘗試、RCE PoC 驗證等）。僅可在取得明確授權的目標（自有系統、合約載明範圍之客戶系統、或合法 CTF/實驗環境）上使用，未經授權對第三方系統執行掃描或攻擊行為可能觸犯電腦犯罪相關法規。企業導入前務必先建立授權範圍書（Rules of Engagement）。\n📌 使用建議 依讀者角色，建議以下閱讀路徑：\n資安工程師 / 滲透測試人員：第一章 → 第二～四章（架構與運作原理）→ 第九～十四章（掃描模式與漏洞偵測）→ 第二十二章（報告） DevSecOps / 平台工程師：第一章 → 第六～八章（安裝與設定）→ 第十九～二十一章（SSDLC、CI/CD、Headless）→ 第二十五章 研發主管 / 架構師（導入評估）：第一章 → 第五章（LLM 成本與能力）→ 第二十三～二十四章（企業最佳實務、大型平台案例）→ 全文結尾之「企業導入指南」 AI Coding / Claude Code 重度使用者：第四章（Agent 原理）→ 第十五～十六章（與 Claude Code / Copilot 整合）→ 第二十六～二十七章 金融 / 政府 / 醫療等高合規產業：第一章 → 第十九章（SSDLC）→ 第二十三章（企業最佳實務）→ 第三十五章附錄之 OWASP/MITRE ATT\u0026amp;CK/CWE Mapping 💡 提醒：本手冊篇幅龐大（35 章 + 附錄），建議搭配目錄以「主題」而非「從頭到尾」方式查閱，並在企業內部依實際導入節奏分批研讀、分批落地。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/strix-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Strix 完整教學手冊（Enterprise Edition） AI Agent 自動化滲透測試．AI Security Testing．DevSecOps．Secure SDLC．CI/CD Security．Framework Upgrade Security．Reverse Engineering Security\n📖 本手冊撰寫依據：本手冊內容根據 Strix（github.com/usestrix/strix，官方文件 docs.strix.ai）之公開原始碼、官方文件與 Release 資訊重新理解、消化後撰寫而成，並非官方 README 之翻譯或複製。文中會明確標註「已於官方原始碼/文件驗證」與「概念性說明、建議讀者自行對照最新原始碼確認」兩類內容，避免將未證實的細節當作官方保證的規格陳述。Strix 是一個仍在快速迭代（Apache-2.0 授權）的開源專案，實際旗標、環境變數與行為請務必以當下版本之官方 repo 為準。\n⚠️ 使用倫理提醒：Strix 屬於「主動攻擊型」AI Agent 安全測試工具，具備實際發起滲透測試行為的能力（注入、越權嘗試、RCE PoC 驗證等）。僅可在取得明確授權的目標（自有系統、合約載明範圍之客戶系統、或合法 CTF/實驗環境）上使用，未經授權對第三方系統執行掃描或攻擊行為可能觸犯電腦犯罪相關法規。企業導入前務必先建立授權範圍書（Rules of Engagement）。\n📌 使用建議 依讀者角色，建議以下閱讀路徑：\n資安工程師 / 滲透測試人員：第一章 → 第二～四章（架構與運作原理）→ 第九～十四章（掃描模式與漏洞偵測）→ 第二十二章（報告） DevSecOps / 平台工程師：第一章 → 第六～八章（安裝與設定）→ 第十九～二十一章（SSDLC、CI/CD、Headless）→ 第二十五章 研發主管 / 架構師（導入評估）：第一章 → 第五章（LLM 成本與能力）→ 第二十三～二十四章（企業最佳實務、大型平台案例）→ 全文結尾之「企業導入指南」 AI Coding / Claude Code 重度使用者：第四章（Agent 原理）→ 第十五～十六章（與 Claude Code / Copilot 整合）→ 第二十六～二十七章 金融 / 政府 / 醫療等高合規產業：第一章 → 第十九章（SSDLC）→ 第二十三章（企業最佳實務）→ 第三十五章附錄之 OWASP/MITRE ATT\u0026amp;CK/CWE Mapping 💡 提醒：本手冊篇幅龐大（35 章 + 附錄），建議搭配目錄以「主題」而非「從頭到尾」方式查閱，並在企業內部依實際導入節奏分批研讀、分批落地。\n","title":"Strix 教學手冊"},{"content":"caveman 教學手冊（企業級 Token 最佳化完整版） 版本基準： caveman v1.9.1（2026-07-03 發布，官方代號 \u0026ldquo;65%, honestly\u0026rdquo;） 適用對象： 資深工程師、AI Coding Agent 導入負責人、架構師、DevSecOps 工程師、技術主管、企業導入決策者 技術定位： AI Coding Agent 輸出壓縮 Skill / Plugin / Hook（Prompt 層級優化，非模型微調） 授權： MIT License（原始專案 JuliusBrussee/caveman） 文件等級： 企業標準技術白皮書 + 教育訓練教材 文件目標定位： 企業 AI Coding Agent Token 最佳化完整教學手冊\n📋 目錄 第一部分：核心概念與架構 第1章 caveman 是什麼 第2章 caveman 系統架構 第3章 caveman 工作原理 第4章 Token 節省原理 第二部分：安裝與 Agent 整合 第5章 安裝教學 第6章 AI Agent 整合 第7章 caveman Modes 第8章 Prompt 運作原理 第三部分：企業應用實務 第9章 Web Application 開發最佳實務 第10章 Legacy Modernization 第11章 Framework Upgrade 第12章 Reverse Engineering 第13章 Prompt Engineering 企業範本 第14章 Token 最佳化策略 第四部分：維運與升級治理 第15章 系統維護 第16章 系統升級 第17章 團隊導入指南 第五部分：品質、風險與比較 第18章 最佳實務（Best Practices） 第19章 常見錯誤（Anti-Patterns） 第20章 FAQ 常見問答 第21章 與其他方案比較 第22章 優缺點分析 第23章 Security 安全分析 第六部分：實戰案例與附錄 第24章 完整企業案例 第25章 附錄（Appendix） 📖 文件說明 🎯 文件目標 本手冊定位為「企業 AI Coding Agent Token 最佳化完整教學手冊」，目的是協助已大量採用 Claude Code、GitHub Copilot、Gemini CLI、Cursor 等 AI Coding Agent 的技術團隊，導入 caveman 這款「輸出壓縮」Skill，在不犧牲程式碼品質的前提下，降低 AI Agent 對話與文字說明所耗費的 Token 量，進而縮短回覆時間、降低 API 成本。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/caveman-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"caveman 教學手冊（企業級 Token 最佳化完整版） 版本基準： caveman v1.9.1（2026-07-03 發布，官方代號 \u0026ldquo;65%, honestly\u0026rdquo;） 適用對象： 資深工程師、AI Coding Agent 導入負責人、架構師、DevSecOps 工程師、技術主管、企業導入決策者 技術定位： AI Coding Agent 輸出壓縮 Skill / Plugin / Hook（Prompt 層級優化，非模型微調） 授權： MIT License（原始專案 JuliusBrussee/caveman） 文件等級： 企業標準技術白皮書 + 教育訓練教材 文件目標定位： 企業 AI Coding Agent Token 最佳化完整教學手冊\n📋 目錄 第一部分：核心概念與架構 第1章 caveman 是什麼 第2章 caveman 系統架構 第3章 caveman 工作原理 第4章 Token 節省原理 第二部分：安裝與 Agent 整合 第5章 安裝教學 第6章 AI Agent 整合 第7章 caveman Modes 第8章 Prompt 運作原理 第三部分：企業應用實務 第9章 Web Application 開發最佳實務 第10章 Legacy Modernization 第11章 Framework Upgrade 第12章 Reverse Engineering 第13章 Prompt Engineering 企業範本 第14章 Token 最佳化策略 第四部分：維運與升級治理 第15章 系統維護 第16章 系統升級 第17章 團隊導入指南 第五部分：品質、風險與比較 第18章 最佳實務（Best Practices） 第19章 常見錯誤（Anti-Patterns） 第20章 FAQ 常見問答 第21章 與其他方案比較 第22章 優缺點分析 第23章 Security 安全分析 第六部分：實戰案例與附錄 第24章 完整企業案例 第25章 附錄（Appendix） 📖 文件說明 🎯 文件目標 本手冊定位為「企業 AI Coding Agent Token 最佳化完整教學手冊」，目的是協助已大量採用 Claude Code、GitHub Copilot、Gemini CLI、Cursor 等 AI Coding Agent 的技術團隊，導入 caveman 這款「輸出壓縮」Skill，在不犧牲程式碼品質的前提下，降低 AI Agent 對話與文字說明所耗費的 Token 量，進而縮短回覆時間、降低 API 成本。\n","title":"Caveman 教學手冊"},{"content":"Github Repositories 建立與維運教學手冊 — 企業級實戰指南 版本：v2.1（2026-07-03）\n適用對象：技術主管 / 架構師 / 資深工程師 / DevOps 團隊 / 專案經理\n定位：企業標準技術白皮書\n參考標準：GitHub Docs（2026） / GitHub Enterprise Best Practices / DevSecOps / SSDLC\n最後審閱日期：2026-07-03\n變更紀錄：\nv2.0 — 新增 Repository 限制與配額、Rulesets 深入指南、Merge Queue、Git LFS、Codespaces、Packages、Private Vulnerability Reporting 等章節；全面校閱並對齊 GitHub 官方文件（2026 年版） v2.1 — 校正 Git LFS 配額表（改採 2025 年後用量計費模式）；更新 GHAS 功能矩陣以反映 Secret Protection / Code Security 拆分方案；擴充 Rulesets 個人 Bypass Actor 與分支更名規則；補強 Merge Queue GA 狀態與運作細節；新增 8.8 Actions 安全性強化與 2026 路線圖、9.9 開源授權合規檢查；更新 Private Vulnerability Reporting 2026 年營運現況；新增 13.8 GitHub Copilot Code Review、13.9 Copilot 平台最新動態與方案，並擴充 13.6 Coding Agent 進階能力；補充 Codespaces 資料落地與 GitHub CLI Discussions 子指令；修正附錄 A 目錄缺漏與清單格式（改為 GitHub Task List 語法）；全面校對並對齊 GitHub 官方文件（2026 年 7 月版） 閱讀指引 本手冊涵蓋 GitHub Repository 從建立到維運的完整生命週期，依讀者角色建議閱讀路徑：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-repositories-%E5%BB%BA%E7%AB%8B%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Github Repositories 建立與維運教學手冊 — 企業級實戰指南 版本：v2.1（2026-07-03）\n適用對象：技術主管 / 架構師 / 資深工程師 / DevOps 團隊 / 專案經理\n定位：企業標準技術白皮書\n參考標準：GitHub Docs（2026） / GitHub Enterprise Best Practices / DevSecOps / SSDLC\n最後審閱日期：2026-07-03\n變更紀錄：\nv2.0 — 新增 Repository 限制與配額、Rulesets 深入指南、Merge Queue、Git LFS、Codespaces、Packages、Private Vulnerability Reporting 等章節；全面校閱並對齊 GitHub 官方文件（2026 年版） v2.1 — 校正 Git LFS 配額表（改採 2025 年後用量計費模式）；更新 GHAS 功能矩陣以反映 Secret Protection / Code Security 拆分方案；擴充 Rulesets 個人 Bypass Actor 與分支更名規則；補強 Merge Queue GA 狀態與運作細節；新增 8.8 Actions 安全性強化與 2026 路線圖、9.9 開源授權合規檢查；更新 Private Vulnerability Reporting 2026 年營運現況；新增 13.8 GitHub Copilot Code Review、13.9 Copilot 平台最新動態與方案，並擴充 13.6 Coding Agent 進階能力；補充 Codespaces 資料落地與 GitHub CLI Discussions 子指令；修正附錄 A 目錄缺漏與清單格式（改為 GitHub Task List 語法）；全面校對並對齊 GitHub 官方文件（2026 年 7 月版） 閱讀指引 本手冊涵蓋 GitHub Repository 從建立到維運的完整生命週期，依讀者角色建議閱讀路徑：\n","title":"Github Repositories 建立教學手冊"},{"content":"Anthropic Cybersecurity Skills 教學手冊 版本：v1.0（依據官方 repo v1.3.0 / main 分支，2026-07 查詢版本整理） 適用對象：Cybersecurity Architect、DevSecOps 架構師、AI Agent 架構師、Secure SDLC 顧問、資深後端／前端工程師、逆向工程／Framework 升級團隊 內容定位：本手冊聚焦於開源專案 Anthropic Cybersecurity Skills（github.com/mukul975/Anthropic-Cybersecurity-Skills）——目前最大的開源 AI Agent 網路安全技能庫——的設計理念、系統架構、六大框架整合、安裝設定、實戰應用（Web 開發／逆向工程／Framework 升級）、第三方技能安全審查，並延伸至企業級 DevSecOps 導入建議。 重要聲明（請務必詳讀）：\n本專案為獨立社群專案，並非 Anthropic PBC 官方產品或官方維護的資產（README 原文：\u0026quot;⚠️ Community Project — This is an independent, community-created project. Not affiliated with Anthropic PBC.\u0026quot;）。專案作者為 Mahipal Jangra（GitHub：mukul975），採 Apache-2.0 授權。手冊中所有「Anthropic」字樣皆指技能庫命名慣例（呼應 Claude / Agent Skills 生態），不代表官方背書。 本技能庫包含攻擊性與雙用途（dual-use）技術（例如紅隊 C2、釣魚模擬、滲透利用），官方明確聲明：「僅限經授權且合法之用途」（Authorized \u0026amp; lawful use only）。僅可對「你擁有或已取得書面授權測試」的系統使用這些技能，並須遵守所有適用法規與交戰規則（Rules of Engagement）。使用者需自行承擔使用後果，詳見專案 SECURITY.md 與 CODE_OF_CONDUCT.md。企業導入前務必先完成法務／資安治理審查（詳見第 11、17 章）。 本文第 1～10、12～16 章之技術描述（Skill 數量、框架版本、YAML frontmatter 欄位、安裝指令、相容平台）基於官方 README、ATTACK_COVERAGE.md、repo 目錄結構逐項核對整理，非逐字翻譯；GitHub 社群數據（Star／Fork 數、Skill 總數）反映查詢當下時間點，會持續變動，實際導入前請以官方 repo 當下版本為準。第 8、9、10、17、19、20 章之企業應用情境屬「企業實務延伸」內容，是顧問觀點下的建議做法，並非官方功能宣稱，文中會標註。 如何使用本手冊 Anthropic Cybersecurity Skills 解決的問題很直接：市面上的資安工具倉庫（wordlist、payload、exploit script）教你「用什麼工具」，但沒有教 AI Agent「資深分析師的決策流程」——什麼情境該用哪個技術、前置條件是什麼、如何一步步執行、如何驗證結果。這個專案把 817 個結構化技能（Skill）以 agentskills.io 開放標準封裝，讓 Claude Code、GitHub Copilot 等 AI Agent 可以在毫秒等級的 frontmatter 掃描後，精準載入所需的資安工作流程。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/anthropic-cybersecurity-skills-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Anthropic Cybersecurity Skills 教學手冊 版本：v1.0（依據官方 repo v1.3.0 / main 分支，2026-07 查詢版本整理） 適用對象：Cybersecurity Architect、DevSecOps 架構師、AI Agent 架構師、Secure SDLC 顧問、資深後端／前端工程師、逆向工程／Framework 升級團隊 內容定位：本手冊聚焦於開源專案 Anthropic Cybersecurity Skills（github.com/mukul975/Anthropic-Cybersecurity-Skills）——目前最大的開源 AI Agent 網路安全技能庫——的設計理念、系統架構、六大框架整合、安裝設定、實戰應用（Web 開發／逆向工程／Framework 升級）、第三方技能安全審查，並延伸至企業級 DevSecOps 導入建議。 重要聲明（請務必詳讀）：\n本專案為獨立社群專案，並非 Anthropic PBC 官方產品或官方維護的資產（README 原文：\u0026quot;⚠️ Community Project — This is an independent, community-created project. Not affiliated with Anthropic PBC.\u0026quot;）。專案作者為 Mahipal Jangra（GitHub：mukul975），採 Apache-2.0 授權。手冊中所有「Anthropic」字樣皆指技能庫命名慣例（呼應 Claude / Agent Skills 生態），不代表官方背書。 本技能庫包含攻擊性與雙用途（dual-use）技術（例如紅隊 C2、釣魚模擬、滲透利用），官方明確聲明：「僅限經授權且合法之用途」（Authorized \u0026amp; lawful use only）。僅可對「你擁有或已取得書面授權測試」的系統使用這些技能，並須遵守所有適用法規與交戰規則（Rules of Engagement）。使用者需自行承擔使用後果，詳見專案 SECURITY.md 與 CODE_OF_CONDUCT.md。企業導入前務必先完成法務／資安治理審查（詳見第 11、17 章）。 本文第 1～10、12～16 章之技術描述（Skill 數量、框架版本、YAML frontmatter 欄位、安裝指令、相容平台）基於官方 README、ATTACK_COVERAGE.md、repo 目錄結構逐項核對整理，非逐字翻譯；GitHub 社群數據（Star／Fork 數、Skill 總數）反映查詢當下時間點，會持續變動，實際導入前請以官方 repo 當下版本為準。第 8、9、10、17、19、20 章之企業應用情境屬「企業實務延伸」內容，是顧問觀點下的建議做法，並非官方功能宣稱，文中會標註。 如何使用本手冊 Anthropic Cybersecurity Skills 解決的問題很直接：市面上的資安工具倉庫（wordlist、payload、exploit script）教你「用什麼工具」，但沒有教 AI Agent「資深分析師的決策流程」——什麼情境該用哪個技術、前置條件是什麼、如何一步步執行、如何驗證結果。這個專案把 817 個結構化技能（Skill）以 agentskills.io 開放標準封裝，讓 Claude Code、GitHub Copilot 等 AI Agent 可以在毫秒等級的 frontmatter 掃描後，精準載入所需的資安工作流程。\n","title":"Anthropic Cybersecurity Skills 教學手冊"},{"content":"learn-claude-code 教學手冊 版本：v1.2（2026-07）\n適用對象：資深工程師、架構師、AI Agent 開發團隊\n定位：企業級 AI Coding Agent Harness Engineering 實戰白皮書\n參考專案：shareAI-lab/learn-claude-code（69.3k+ Stars，MIT License）\n線上學習平台：learn.shareai.run\n目錄 1. 專案概述 1.1 learn-claude-code 是什麼 1.2 Agency 的本質 — 來自模型訓練而非程式碼 1.3 Agency 的歷史脈絡 1.4 Agent 不是什麼 — 破除「提示詞水管工」迷思 1.5 心智轉換：從「開發 Agent」到開發 Harness 1.6 為何選擇 Claude Code 作為教學標本 1.7 與 Claude Code / Cursor 的差異 1.8 為何企業應該自己打造 Agent 2. 系統整體架構設計 2.1 Agent Runtime 架構 2.2 LLM Gateway（可替換 OpenAI / Claude） 2.3 Tool Layer 設計 2.4 Task Queue 與持久化 2.5 Workspace / Worktree 隔離 2.6 Memory 系統（短期 / 長期） 2.7 Multi-Agent Coordination 2.8 與企業系統整合方式 2.9 範圍說明與設計限制（Scope） 3. Agent 核心機制解析（20 Sessions） 3.1 Agent Loop（s01） 3.2 Tool Use 與 Dispatch Map（s02） 3.3 Permission 三層防護（s03） 3.4 Hooks 擴展點機制（s04） 3.5 Planning / Reflection — TodoWrite（s05） 3.6 Subagent 機制（s06） 3.7 Skills 按需載入（s07） 3.8 Context Compact — 壓縮策略（s08） 3.9 Memory System 記憶系統（s09） 3.10 System Prompt 動態組裝（s10） 3.11 Error Recovery 錯誤恢復（s11） 3.12 Task 持久化與相依管理（s12） 3.13 Background Tasks（s13） 3.14 Cron Scheduler 排程機制（s14） 3.15 Agent Teams 與 Mailbox（s15-s16） 3.16 Autonomous Agent 自治（s17） 3.17 Worktree + Task Isolation（s18） 3.18 MCP Plugin 外部工具整合（s19） 3.19 完整 Agent 整合（s20） 4. Harness Engineering（核心競爭力） 4.1 什麼是 Harness 4.2 Harness 工程師的五大職責 4.3 如何設計 Tool Interface 4.4 如何限制 Agent 行為（安全性） 4.5 如何提升成功率（Prompt / Retry / Guardrails） 4.6 CLAUDE.md 系統設計 5. 實作教學（Step-by-step） 5.1 環境安裝 5.2 專案初始化 5.3 第一個 Agent — Agent Loop 5.4 Tool 註冊（讀檔 / 寫檔 / Shell） 5.5 加入計畫能力 — TodoWrite 5.6 加入測試能力 5.7 加入錯誤修復能力 5.8 加入 Hooks 機制 6. 建立企業級 Coding Agent 6.1 Code Generation 6.2 Code Review 6.3 Test Generation 6.4 Refactoring 6.5 文件產生 7. Multi-Agent 設計（進階） 7.1 Agent Team 架構設計 7.2 任務拆解策略 7.3 Agent 溝通方式 — JSONL Mailbox 7.4 狀態管理與生命週期 8. 實際應用場景 8.1 Web Application 開發 8.2 舊系統逆向工程 8.3 Framework 升級 8.4 Batch 系統改寫 9. 與企業架構整合 9.1 資料庫整合（DB2 / Oracle / PostgreSQL） 9.2 訊息佇列（Kafka / RabbitMQ） 9.3 微服務架構整合 9.4 CI/CD 整合（GitHub Actions / Jenkins） 9.5 權限控管（RBAC） 9.6 MCP Server 整合 10. 安全與 SSDLC 10.1 Prompt Injection 防護 10.2 Tool 權限控管 10.3 Code 安全掃描 10.4 Audit Log 10.5 合規（金融場景） 11. 使用指南（給團隊） 11.1 日常開發流程 11.2 如何下 Prompt 11.3 如何 Debug Agent 11.4 常見錯誤與排除 12. 最佳實踐（Best Practices） 12.1 Prompt 設計 12.2 Tool 設計原則 12.3 Agent 拆分策略 12.4 成本控制 12.5 Context Engineering 最佳實踐 13. 願景：用 Agent 覆蓋每一個領域 13.1 跨領域 Agent 設計模式 13.2 從被動會話到主動常駐助手 14. 延伸資源與姊妹專案 14.1 Kode Agent CLI 14.2 Kode Agent SDK 14.3 claw0 — 常駐 Agent 教學專案 14.4 OpenClaw — 社群生態 15. 附錄 15.1 範例 Prompt 集 15.2 CLI 指令速查表 15.3 常見問題 FAQ 15.4 檢查清單（Checklist） 1. 專案概述 1.1 learn-claude-code 是什麼 learn-claude-code 是由 shareAI-lab 開源的 AI Coding Agent 教學專案（GitHub 69.3k+ Stars，MIT License，創立於 2025-06），核心理念為「Harness Engineering for Real Agents」。專案副標題精確概括了其定位：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/learn-claude-code-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"learn-claude-code 教學手冊 版本：v1.2（2026-07）\n適用對象：資深工程師、架構師、AI Agent 開發團隊\n定位：企業級 AI Coding Agent Harness Engineering 實戰白皮書\n參考專案：shareAI-lab/learn-claude-code（69.3k+ Stars，MIT License）\n線上學習平台：learn.shareai.run\n目錄 1. 專案概述 1.1 learn-claude-code 是什麼 1.2 Agency 的本質 — 來自模型訓練而非程式碼 1.3 Agency 的歷史脈絡 1.4 Agent 不是什麼 — 破除「提示詞水管工」迷思 1.5 心智轉換：從「開發 Agent」到開發 Harness 1.6 為何選擇 Claude Code 作為教學標本 1.7 與 Claude Code / Cursor 的差異 1.8 為何企業應該自己打造 Agent 2. 系統整體架構設計 2.1 Agent Runtime 架構 2.2 LLM Gateway（可替換 OpenAI / Claude） 2.3 Tool Layer 設計 2.4 Task Queue 與持久化 2.5 Workspace / Worktree 隔離 2.6 Memory 系統（短期 / 長期） 2.7 Multi-Agent Coordination 2.8 與企業系統整合方式 2.9 範圍說明與設計限制（Scope） 3. Agent 核心機制解析（20 Sessions） 3.1 Agent Loop（s01） 3.2 Tool Use 與 Dispatch Map（s02） 3.3 Permission 三層防護（s03） 3.4 Hooks 擴展點機制（s04） 3.5 Planning / Reflection — TodoWrite（s05） 3.6 Subagent 機制（s06） 3.7 Skills 按需載入（s07） 3.8 Context Compact — 壓縮策略（s08） 3.9 Memory System 記憶系統（s09） 3.10 System Prompt 動態組裝（s10） 3.11 Error Recovery 錯誤恢復（s11） 3.12 Task 持久化與相依管理（s12） 3.13 Background Tasks（s13） 3.14 Cron Scheduler 排程機制（s14） 3.15 Agent Teams 與 Mailbox（s15-s16） 3.16 Autonomous Agent 自治（s17） 3.17 Worktree + Task Isolation（s18） 3.18 MCP Plugin 外部工具整合（s19） 3.19 完整 Agent 整合（s20） 4. Harness Engineering（核心競爭力） 4.1 什麼是 Harness 4.2 Harness 工程師的五大職責 4.3 如何設計 Tool Interface 4.4 如何限制 Agent 行為（安全性） 4.5 如何提升成功率（Prompt / Retry / Guardrails） 4.6 CLAUDE.md 系統設計 5. 實作教學（Step-by-step） 5.1 環境安裝 5.2 專案初始化 5.3 第一個 Agent — Agent Loop 5.4 Tool 註冊（讀檔 / 寫檔 / Shell） 5.5 加入計畫能力 — TodoWrite 5.6 加入測試能力 5.7 加入錯誤修復能力 5.8 加入 Hooks 機制 6. 建立企業級 Coding Agent 6.1 Code Generation 6.2 Code Review 6.3 Test Generation 6.4 Refactoring 6.5 文件產生 7. Multi-Agent 設計（進階） 7.1 Agent Team 架構設計 7.2 任務拆解策略 7.3 Agent 溝通方式 — JSONL Mailbox 7.4 狀態管理與生命週期 8. 實際應用場景 8.1 Web Application 開發 8.2 舊系統逆向工程 8.3 Framework 升級 8.4 Batch 系統改寫 9. 與企業架構整合 9.1 資料庫整合（DB2 / Oracle / PostgreSQL） 9.2 訊息佇列（Kafka / RabbitMQ） 9.3 微服務架構整合 9.4 CI/CD 整合（GitHub Actions / Jenkins） 9.5 權限控管（RBAC） 9.6 MCP Server 整合 10. 安全與 SSDLC 10.1 Prompt Injection 防護 10.2 Tool 權限控管 10.3 Code 安全掃描 10.4 Audit Log 10.5 合規（金融場景） 11. 使用指南（給團隊） 11.1 日常開發流程 11.2 如何下 Prompt 11.3 如何 Debug Agent 11.4 常見錯誤與排除 12. 最佳實踐（Best Practices） 12.1 Prompt 設計 12.2 Tool 設計原則 12.3 Agent 拆分策略 12.4 成本控制 12.5 Context Engineering 最佳實踐 13. 願景：用 Agent 覆蓋每一個領域 13.1 跨領域 Agent 設計模式 13.2 從被動會話到主動常駐助手 14. 延伸資源與姊妹專案 14.1 Kode Agent CLI 14.2 Kode Agent SDK 14.3 claw0 — 常駐 Agent 教學專案 14.4 OpenClaw — 社群生態 15. 附錄 15.1 範例 Prompt 集 15.2 CLI 指令速查表 15.3 常見問題 FAQ 15.4 檢查清單（Checklist） 1. 專案概述 1.1 learn-claude-code 是什麼 learn-claude-code 是由 shareAI-lab 開源的 AI Coding Agent 教學專案（GitHub 69.3k+ Stars，MIT License，創立於 2025-06），核心理念為「Harness Engineering for Real Agents」。專案副標題精確概括了其定位：\n","title":"Learn Claude Code 教學手冊"},{"content":"agency-agents 教學手冊（Enterprise Guide） 版本：v3.1 ｜ 最後更新：2026-07-01 適用對象：資深工程師、架構師、技術主管 授權：內部教育訓練使用\n目錄 總覽（Overview） 系統架構設計（Architecture） 安裝與環境建置（Installation \u0026amp; Setup） Agent 結構解析（Agent Design） 與 AI Coding 工具整合（Integration） 實戰：AI 開發流程（End-to-End Workflow） SSDLC（安全開發流程） 系統維運（Maintenance） 系統升級（Upgrade Strategy） 最佳實踐（Best Practices） 企業導入建議（Enterprise Adoption） 附錄（Appendix） 檢查清單（Checklist） 參考資源與社群（Resources \u0026amp; Community） 1. 總覽（Overview） 1.1 agency-agents 是什麼 agency-agents（又稱 The Agency）是由社群驅動的開源 AI 虛擬團隊框架，目前擁有 232 個專業化 AI Agent 角色，橫跨 16 個部門，由 90+ 位貢獻者共同維護。每個 Agent 不是簡單的 Prompt 模板，而是一份具備完整人設（Persona）、工作流程（Workflow）、溝通風格（Communication Style）、KPI 與成功指標的 Markdown 定義檔。該專案起源於 Reddit 社群的一篇討論，經過數月迭代，已成為 GitHub 上最受歡迎的 AI Agent 人設定義框架之一。專案現已推出原生桌面應用程式（macOS / Linux / Windows），使用者可透過圖形介面一鍵瀏覽完整 Agent 名冊、安裝到各工具，並自動更新。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/agency-agents%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"agency-agents 教學手冊（Enterprise Guide） 版本：v3.1 ｜ 最後更新：2026-07-01 適用對象：資深工程師、架構師、技術主管 授權：內部教育訓練使用\n目錄 總覽（Overview） 系統架構設計（Architecture） 安裝與環境建置（Installation \u0026amp; Setup） Agent 結構解析（Agent Design） 與 AI Coding 工具整合（Integration） 實戰：AI 開發流程（End-to-End Workflow） SSDLC（安全開發流程） 系統維運（Maintenance） 系統升級（Upgrade Strategy） 最佳實踐（Best Practices） 企業導入建議（Enterprise Adoption） 附錄（Appendix） 檢查清單（Checklist） 參考資源與社群（Resources \u0026amp; Community） 1. 總覽（Overview） 1.1 agency-agents 是什麼 agency-agents（又稱 The Agency）是由社群驅動的開源 AI 虛擬團隊框架，目前擁有 232 個專業化 AI Agent 角色，橫跨 16 個部門，由 90+ 位貢獻者共同維護。每個 Agent 不是簡單的 Prompt 模板，而是一份具備完整人設（Persona）、工作流程（Workflow）、溝通風格（Communication Style）、KPI 與成功指標的 Markdown 定義檔。該專案起源於 Reddit 社群的一篇討論，經過數月迭代，已成為 GitHub 上最受歡迎的 AI Agent 人設定義框架之一。專案現已推出原生桌面應用程式（macOS / Linux / Windows），使用者可透過圖形介面一鍵瀏覽完整 Agent 名冊、安裝到各工具，並自動更新。\n","title":"Agency Agents教學手冊"},{"content":"AutoResearch 驅動 SSDLC（安全軟體開發生命週期）教學手冊 版本：v3.0\n日期：2026-07-01\n上次更新：2026-07-01\n適用對象：資深工程師、DevSecOps 團隊、AI 架構師、技術主管\n前置需求：具備 Python、Git、CI/CD、基本 LLM 使用經驗\n文件等級：企業標準技術白皮書\n變更紀錄：v3.0 — 更新 Claude Code Agent SDK/Plugins/Routines 生態系、GitHub Copilot CLI/App/SDK/Agentic Workflows 全面改寫、AutoResearch 最新社群動態\n📖 目錄（Table of Contents） 第 1 章：AutoResearch 與 SSDLC 整合概念 1.1 什麼是 AutoResearch？ 1.2 什麼是 SSDLC？ 1.3 AI 如何取代/輔助 SDLC 各階段 1.4 與傳統 DevSecOps 差異 1.5 自我優化迴圈（Self-Improving Loop） 1.6 AutoResearch 設計哲學與最新發展 第 2 章：系統整體架構設計 2.1 五層架構模型 2.2 SSDLC 完整流程圖 2.3 元件互動關係 2.4 安全邊界設計 第 3 章：環境建置與安裝 3.1 前置需求總覽 3.2 Python 環境安裝 3.3 Git 安裝與設定 3.4 AutoResearch 安裝 3.5 Claude Code 安裝與設定 3.6 GitHub Copilot 安裝與設定 3.7 VS Code 安裝與設定 3.8 一鍵安裝腳本 第 4 章：AutoResearch 核心運作解析 4.1 核心架構概覽 4.2 train.py — 可被 AI 修改的目標檔案 4.3 prepare.py — 固定的資料與工具層 4.4 program.md — Prompt Engineering 指令策略 4.5 AutoResearch 執行引擎 4.6 program.md 的 Prompt Engineering 技巧 第 5 章：SSDLC Workflow 設計 5.0 SSDLC 全階段總覽 5.1 階段一：需求分析（Requirement Analysis） 5.2 階段二：架構設計（Design） 5.3 階段三：開發（Development） 5.4 階段四：測試（Testing） 5.5 階段五：安全掃描（Security Scanning） 5.6 階段六：部署（Deployment） 5.7 階段七：監控（Monitoring） 5.8 階段八：優化（Optimization） 第 6 章：AI 自動優化機制 6.1 AutoResearch 自動優化核心原理 6.2 修改程式碼的策略 6.3 執行測試的流程 6.4 評估結果的機制 6.5 Keep / Revert 決策矩陣 6.6 應用於三大場景 第 7 章：CI/CD + AutoResearch 整合 7.1 整合架構概覽 7.2 GitHub Actions 完整 YAML 設計 7.3 自動觸發 AutoResearch 的機制 7.4 安全掃描結果彙總腳本 第 8 章：實戰案例 8.1 案例一：API 效能優化 8.2 案例二：安全漏洞自動修補 第 9 章：系統維運 9.1 日誌監控架構 9.2 模型 Drift 偵測 9.3 版本控管策略 9.4 Rollback 策略 9.5 維運 Checklist 第 10 章：系統升級與擴展 10.1 多 Agent 架構（Cluster） 10.2 分散式 AutoResearch 10.3 GPU / 雲端擴展 第 11 章：Claude Code 進階功能與 SSDLC 整合 11.1 CLAUDE.md 記憶系統 11.2 Skills 技能系統 11.3 Hooks 自動化機制 11.4 Subagents 子代理人架構 11.5 MCP（Model Context Protocol）整合 11.6 Plan Mode 與 Extended Thinking 11.7 Worktrees 平行開發 11.8 Agent Teams 團隊協作 11.9 排程任務（Scheduled Tasks） 11.10 Agent SDK（Python + TypeScript） 11.11 Plugins 生態系 11.12 Remote Control \u0026amp; Channels 11.13 Desktop App、Web、Chrome 整合 11.14 Code Review（Ultrareview） 11.15 Auto Mode \u0026amp; Sandbox 11.16 Analytics \u0026amp; Observability（OpenTelemetry） 第 12 章：GitHub Copilot Agent 生態系 12.1 GitHub Copilot 功能總覽（2026） 12.2 Cloud Agent 雲端代理人 12.3 Agent Skills 開放標準 12.4 Agentic Memory 記憶系統 12.5 Copilot Code Review 12.6 Copilot 與 SSDLC 整合策略 12.7 Copilot CLI Agent（命令列代理人） 12.8 Copilot App（桌面應用程式） 12.9 Copilot SDK（Node.js / Python / .NET） 12.10 Third-Party Agents（第三方代理人） 12.11 GitHub Agentic Workflows \u0026amp; Automations 12.12 Copilot Plugins 生態系 12.13 Enterprise Governance \u0026amp; AI Controls 第 13 章：Best Practices（企業建議） 13.1 Prompt 設計最佳實踐 13.2 安全策略最佳實踐 13.3 Git 管理策略 13.4 成本管理 13.5 Agent 安全治理最佳實踐 第 14 章：Anti-Patterns（常見錯誤） 14.1 致命錯誤（Must Avoid） 14.2 常見設計錯誤 14.3 Anti-Patterns 總覽表 附錄 A：Docker Compose 範例 附錄 B：專案目錄結構 附錄 C：檢查清單（Checklist） 附錄 D：術語表（Glossary） 附錄 E：參考資源與延伸閱讀 第 1 章：AutoResearch 與 SSDLC 整合概念 1.1 什麼是 AutoResearch？ AutoResearch 是由 Andrej Karpathy 於 2026 年 3 月提出的 AI 自主研究框架（GitHub: karpathy/autoresearch，⭐ 89.3k stars，12.9k forks），核心理念為：讓 AI Agent 在固定的 時間預算（Time Budget） 內，自主修改程式碼、執行測試、評估結果，最終決定是否保留變更。截至 2026 年 7 月，專案已累積超過 10,000 代的社群實驗，成為 AI 自主研究領域的標竿專案。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/autoresearch-%E9%A9%85%E5%8B%95-ssdlc%E5%AE%89%E5%85%A8%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC%E7%94%9F%E5%91%BD%E9%80%B1%E6%9C%9F%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"AutoResearch 驅動 SSDLC（安全軟體開發生命週期）教學手冊 版本：v3.0\n日期：2026-07-01\n上次更新：2026-07-01\n適用對象：資深工程師、DevSecOps 團隊、AI 架構師、技術主管\n前置需求：具備 Python、Git、CI/CD、基本 LLM 使用經驗\n文件等級：企業標準技術白皮書\n變更紀錄：v3.0 — 更新 Claude Code Agent SDK/Plugins/Routines 生態系、GitHub Copilot CLI/App/SDK/Agentic Workflows 全面改寫、AutoResearch 最新社群動態\n📖 目錄（Table of Contents） 第 1 章：AutoResearch 與 SSDLC 整合概念 1.1 什麼是 AutoResearch？ 1.2 什麼是 SSDLC？ 1.3 AI 如何取代/輔助 SDLC 各階段 1.4 與傳統 DevSecOps 差異 1.5 自我優化迴圈（Self-Improving Loop） 1.6 AutoResearch 設計哲學與最新發展 第 2 章：系統整體架構設計 2.1 五層架構模型 2.2 SSDLC 完整流程圖 2.3 元件互動關係 2.4 安全邊界設計 第 3 章：環境建置與安裝 3.1 前置需求總覽 3.2 Python 環境安裝 3.3 Git 安裝與設定 3.4 AutoResearch 安裝 3.5 Claude Code 安裝與設定 3.6 GitHub Copilot 安裝與設定 3.7 VS Code 安裝與設定 3.8 一鍵安裝腳本 第 4 章：AutoResearch 核心運作解析 4.1 核心架構概覽 4.2 train.py — 可被 AI 修改的目標檔案 4.3 prepare.py — 固定的資料與工具層 4.4 program.md — Prompt Engineering 指令策略 4.5 AutoResearch 執行引擎 4.6 program.md 的 Prompt Engineering 技巧 第 5 章：SSDLC Workflow 設計 5.0 SSDLC 全階段總覽 5.1 階段一：需求分析（Requirement Analysis） 5.2 階段二：架構設計（Design） 5.3 階段三：開發（Development） 5.4 階段四：測試（Testing） 5.5 階段五：安全掃描（Security Scanning） 5.6 階段六：部署（Deployment） 5.7 階段七：監控（Monitoring） 5.8 階段八：優化（Optimization） 第 6 章：AI 自動優化機制 6.1 AutoResearch 自動優化核心原理 6.2 修改程式碼的策略 6.3 執行測試的流程 6.4 評估結果的機制 6.5 Keep / Revert 決策矩陣 6.6 應用於三大場景 第 7 章：CI/CD + AutoResearch 整合 7.1 整合架構概覽 7.2 GitHub Actions 完整 YAML 設計 7.3 自動觸發 AutoResearch 的機制 7.4 安全掃描結果彙總腳本 第 8 章：實戰案例 8.1 案例一：API 效能優化 8.2 案例二：安全漏洞自動修補 第 9 章：系統維運 9.1 日誌監控架構 9.2 模型 Drift 偵測 9.3 版本控管策略 9.4 Rollback 策略 9.5 維運 Checklist 第 10 章：系統升級與擴展 10.1 多 Agent 架構（Cluster） 10.2 分散式 AutoResearch 10.3 GPU / 雲端擴展 第 11 章：Claude Code 進階功能與 SSDLC 整合 11.1 CLAUDE.md 記憶系統 11.2 Skills 技能系統 11.3 Hooks 自動化機制 11.4 Subagents 子代理人架構 11.5 MCP（Model Context Protocol）整合 11.6 Plan Mode 與 Extended Thinking 11.7 Worktrees 平行開發 11.8 Agent Teams 團隊協作 11.9 排程任務（Scheduled Tasks） 11.10 Agent SDK（Python + TypeScript） 11.11 Plugins 生態系 11.12 Remote Control \u0026amp; Channels 11.13 Desktop App、Web、Chrome 整合 11.14 Code Review（Ultrareview） 11.15 Auto Mode \u0026amp; Sandbox 11.16 Analytics \u0026amp; Observability（OpenTelemetry） 第 12 章：GitHub Copilot Agent 生態系 12.1 GitHub Copilot 功能總覽（2026） 12.2 Cloud Agent 雲端代理人 12.3 Agent Skills 開放標準 12.4 Agentic Memory 記憶系統 12.5 Copilot Code Review 12.6 Copilot 與 SSDLC 整合策略 12.7 Copilot CLI Agent（命令列代理人） 12.8 Copilot App（桌面應用程式） 12.9 Copilot SDK（Node.js / Python / .NET） 12.10 Third-Party Agents（第三方代理人） 12.11 GitHub Agentic Workflows \u0026amp; Automations 12.12 Copilot Plugins 生態系 12.13 Enterprise Governance \u0026amp; AI Controls 第 13 章：Best Practices（企業建議） 13.1 Prompt 設計最佳實踐 13.2 安全策略最佳實踐 13.3 Git 管理策略 13.4 成本管理 13.5 Agent 安全治理最佳實踐 第 14 章：Anti-Patterns（常見錯誤） 14.1 致命錯誤（Must Avoid） 14.2 常見設計錯誤 14.3 Anti-Patterns 總覽表 附錄 A：Docker Compose 範例 附錄 B：專案目錄結構 附錄 C：檢查清單（Checklist） 附錄 D：術語表（Glossary） 附錄 E：參考資源與延伸閱讀 第 1 章：AutoResearch 與 SSDLC 整合概念 1.1 什麼是 AutoResearch？ AutoResearch 是由 Andrej Karpathy 於 2026 年 3 月提出的 AI 自主研究框架（GitHub: karpathy/autoresearch，⭐ 89.3k stars，12.9k forks），核心理念為：讓 AI Agent 在固定的 時間預算（Time Budget） 內，自主修改程式碼、執行測試、評估結果，最終決定是否保留變更。截至 2026 年 7 月，專案已累積超過 10,000 代的社群實驗，成為 AI 自主研究領域的標竿專案。\n","title":"AutoResearch 驅動 SSDLC（安全軟體開發生命週期）教學手冊"},{"content":"Pi Code Agent 教學手冊（Enterprise Edition） 版本：v0.80.2（2026 年 7 月 1 日更新）\n適用對象：資深工程師、架構師、DevOps 工程師\n技術棧：Java / Spring Boot / Vue / TypeScript / Redis / Kafka / PostgreSQL\n授權：MIT License\n開發公司：Earendil Inc.\n開源統計：⭐ 66.7k+ Stars、220+ Contributors、240+ Releases、8.2k+ Forks\n目錄（Table of Contents） 概述（Overview） 核心設計哲學（Architecture Philosophy） 系統架構設計（System Architecture） 安裝與環境建置（Installation \u0026amp; Setup） 基本使用教學（Getting Started） Context Engineering（上下文工程） PLAN.md 開發模式 Extensions / Skills / Prompt Templates / Themes Pi Agent + SSDLC（企業重點） 實戰案例（Hands-on） 維運與監控（Operations） 升級與版本管理（Upgrade Strategy） OSS Session 共享與社群貢獻 Best Practices（企業建議） Anti-Patterns（重要） 容器化與沙箱安全（Containerization \u0026amp; Sandboxing） 結論（Conclusion） 檢查清單（Checklist） 1. 概述（Overview） 1.1 Pi Code Agent 是什麼 Pi（又名 Pi Coding Agent）是由 Mario Zechner（badlogic） 與 Earendil Inc. 開發的極簡終端 AI 程式碼開發工具，以 MIT License 開源於 GitHub。其核心定位為：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/pi-code-agent-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Pi Code Agent 教學手冊（Enterprise Edition） 版本：v0.80.2（2026 年 7 月 1 日更新）\n適用對象：資深工程師、架構師、DevOps 工程師\n技術棧：Java / Spring Boot / Vue / TypeScript / Redis / Kafka / PostgreSQL\n授權：MIT License\n開發公司：Earendil Inc.\n開源統計：⭐ 66.7k+ Stars、220+ Contributors、240+ Releases、8.2k+ Forks\n目錄（Table of Contents） 概述（Overview） 核心設計哲學（Architecture Philosophy） 系統架構設計（System Architecture） 安裝與環境建置（Installation \u0026amp; Setup） 基本使用教學（Getting Started） Context Engineering（上下文工程） PLAN.md 開發模式 Extensions / Skills / Prompt Templates / Themes Pi Agent + SSDLC（企業重點） 實戰案例（Hands-on） 維運與監控（Operations） 升級與版本管理（Upgrade Strategy） OSS Session 共享與社群貢獻 Best Practices（企業建議） Anti-Patterns（重要） 容器化與沙箱安全（Containerization \u0026amp; Sandboxing） 結論（Conclusion） 檢查清單（Checklist） 1. 概述（Overview） 1.1 Pi Code Agent 是什麼 Pi（又名 Pi Coding Agent）是由 Mario Zechner（badlogic） 與 Earendil Inc. 開發的極簡終端 AI 程式碼開發工具，以 MIT License 開源於 GitHub。其核心定位為：\n","title":"Pi Code Agent 教學手冊"},{"content":"claude-howto 教學手冊（完整版） 文件版本：v2.0 最後更新：2026-07-01 基於 Claude Code 版本：v2.1.160 基於 claude-howto 版本：v2.1.160 release（2026-06 同步） 適用對象：資深工程師、技術主管、DevOps 工程師、架構師 適用模型：Claude Fable 5 / Claude Opus 4.8 / Claude Sonnet 4.6 / Claude Haiku 4.5 授權方式：MIT License\n修訂記錄（Revision History） 版本 日期 主要變更 v1.0 2026-04-24 初版發布，對應 claude-howto v2.1.112 v1.1 2026-05-02 補充 Hook 事件完整清單、Plugin 安全注意事項、Permission Modes 表 v2.0 2026-07-01 同步 claude-howto v2.1.160；新增 Fable 5 / Opus 4.8 模型說明；新增 4.12 Workflow 多代理編排、5.4 微服務架構開發、7.6 合規性自動化、第 13 章模型選用指南、附錄 D 術語表；更新 GitHub 統計；提升至企業技術白皮書格式 摘要（Executive Summary） 本手冊為企業技術白皮書等級文件，系統性介紹 claude-howto（GitHub: luongnv89/claude-howto）——目前最完整的 Claude Code 社群實戰指南（39k+ Stars，4.7k+ Forks）。文件涵蓋從安裝設定、10 大核心模組、AI 輔助開發流程、Prompt Engineering、SSDLC 安全整合，到企業落地策略的完整知識體系。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-howto-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"claude-howto 教學手冊（完整版） 文件版本：v2.0 最後更新：2026-07-01 基於 Claude Code 版本：v2.1.160 基於 claude-howto 版本：v2.1.160 release（2026-06 同步） 適用對象：資深工程師、技術主管、DevOps 工程師、架構師 適用模型：Claude Fable 5 / Claude Opus 4.8 / Claude Sonnet 4.6 / Claude Haiku 4.5 授權方式：MIT License\n修訂記錄（Revision History） 版本 日期 主要變更 v1.0 2026-04-24 初版發布，對應 claude-howto v2.1.112 v1.1 2026-05-02 補充 Hook 事件完整清單、Plugin 安全注意事項、Permission Modes 表 v2.0 2026-07-01 同步 claude-howto v2.1.160；新增 Fable 5 / Opus 4.8 模型說明；新增 4.12 Workflow 多代理編排、5.4 微服務架構開發、7.6 合規性自動化、第 13 章模型選用指南、附錄 D 術語表；更新 GitHub 統計；提升至企業技術白皮書格式 摘要（Executive Summary） 本手冊為企業技術白皮書等級文件，系統性介紹 claude-howto（GitHub: luongnv89/claude-howto）——目前最完整的 Claude Code 社群實戰指南（39k+ Stars，4.7k+ Forks）。文件涵蓋從安裝設定、10 大核心模組、AI 輔助開發流程、Prompt Engineering、SSDLC 安全整合，到企業落地策略的完整知識體系。\n","title":"Claude Howto 教學手冊"},{"content":"free-claude-code 教學手冊 版本：2026-07 ｜ 對應專案：Alishahryar1/free-claude-code 適用對象：資深工程師 / 架構師 / DevOps / AI 開發團隊 授權：MIT License 定位：企業級 AI 輔助開發實戰手冊 語言：繁體中文 文件更新日期：2026 年 7 月 1 日\n目錄 概述（Overview） 系統整體架構（Architecture） 安裝與環境建置（Installation） 核心設定（Configuration） 模型整合（Multi-LLM Integration） 5.3 NVIDIA NIM 5.4 OpenRouter 5.5 DeepSeek 5.6 LM Studio 5.7 llama.cpp 5.8 Ollama 5.9 Google AI Studio（Gemini） 5.10 Mistral La Plateforme 5.11 Mistral Codestral 5.12 OpenCode Zen 5.13 OpenCode Go 5.14 Wafer 5.15 Kimi（Moonshot） 5.16 Cerebras Inference 5.17 Groq 5.18 Fireworks AI 5.19 Cloudflare 5.20 Z.ai 開發實戰（AI Development Use Cases） SSDLC（安全開發流程） 團隊導入策略（Team Adoption） 維運與監控（Operations） Smoke Testing 與啟動驗證（Startup Validation） 升級與擴展（Upgrade \u0026amp; Scaling） 常見問題（FAQ） 最佳實務（Best Practices） CI/CD 整合 開發與貢獻指南（Development \u0026amp; Contributing） 範例 Prompt 集 檢查清單（Checklist） Admin UI 管理介面 Codex CLI 整合（fcc-codex） 1. 概述（Overview） 1.1 free-claude-code 是什麼 free-claude-code 是一個開源 Anthropic Messages API 相容代理伺服器（Proxy），以 Python FastAPI 建構，目前在 GitHub 上擁有超過 37,900 顆星（6,000+ forks）。它攔截 Claude Code CLI、Codex CLI、VS Code Extension 或 JetBrains ACP 發出的 API 請求，將其轉發至多種 LLM 後端，讓開發者能以免費或低成本方式使用 Claude Code 的完整開發體驗。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/free-claude-code-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"free-claude-code 教學手冊 版本：2026-07 ｜ 對應專案：Alishahryar1/free-claude-code 適用對象：資深工程師 / 架構師 / DevOps / AI 開發團隊 授權：MIT License 定位：企業級 AI 輔助開發實戰手冊 語言：繁體中文 文件更新日期：2026 年 7 月 1 日\n目錄 概述（Overview） 系統整體架構（Architecture） 安裝與環境建置（Installation） 核心設定（Configuration） 模型整合（Multi-LLM Integration） 5.3 NVIDIA NIM 5.4 OpenRouter 5.5 DeepSeek 5.6 LM Studio 5.7 llama.cpp 5.8 Ollama 5.9 Google AI Studio（Gemini） 5.10 Mistral La Plateforme 5.11 Mistral Codestral 5.12 OpenCode Zen 5.13 OpenCode Go 5.14 Wafer 5.15 Kimi（Moonshot） 5.16 Cerebras Inference 5.17 Groq 5.18 Fireworks AI 5.19 Cloudflare 5.20 Z.ai 開發實戰（AI Development Use Cases） SSDLC（安全開發流程） 團隊導入策略（Team Adoption） 維運與監控（Operations） Smoke Testing 與啟動驗證（Startup Validation） 升級與擴展（Upgrade \u0026amp; Scaling） 常見問題（FAQ） 最佳實務（Best Practices） CI/CD 整合 開發與貢獻指南（Development \u0026amp; Contributing） 範例 Prompt 集 檢查清單（Checklist） Admin UI 管理介面 Codex CLI 整合（fcc-codex） 1. 概述（Overview） 1.1 free-claude-code 是什麼 free-claude-code 是一個開源 Anthropic Messages API 相容代理伺服器（Proxy），以 Python FastAPI 建構，目前在 GitHub 上擁有超過 37,900 顆星（6,000+ forks）。它攔截 Claude Code CLI、Codex CLI、VS Code Extension 或 JetBrains ACP 發出的 API 請求，將其轉發至多種 LLM 後端，讓開發者能以免費或低成本方式使用 Claude Code 的完整開發體驗。\n","title":"Free Claude Code 教學手冊"},{"content":"oh-my-claudecode 教學手冊（完整版） 版本：v4.15.1（2026-06-27）\n文件更新日期：2026-07-01\n適用對象：資深工程師、架構師、技術主管\n定位：企業級 Multi-Agent 編排實戰手冊\n授權：MIT License\n官方網站：https://oh-my-claudecode.dev\n目錄 1. 概述 1.1 什麼是 oh-my-claudecode 1.2 與傳統 Claude Code 的差異 1.3 與 GitHub Copilot 的整合方式 1.4 適用場景 2. 整體架構設計（Architecture） 2.1 Multi-Agent 架構圖 2.2 Agent 分工（29 個 Agent） 2.3 任務分解機制（Task Decomposition） 2.4 Agent 角色邊界 2.5 驗證協定（Verification Protocol） 2.6 Agent 通訊機制 2.7 狀態管理架構：Control Plane vs Data Plane 2.8 與外部系統整合 3. 安裝與環境建置（Step-by-step） 3.1 前置需求 3.2 安裝 oh-my-claudecode 3.3 初始設定（Setup） 3.4 tmux / psmux 安裝（各平台） 3.5 可選：多 AI 模型支援 3.6 啟用 Claude Code Native Teams 3.7 驗證安裝 4. 核心設定（Configuration） 4.1 設定檔結構與優先順序 4.2 環境變數 4.3 Agent 設定（自訂 / 修改） 4.4 模型路由策略（Cost Optimization） 4.5 Company Context via MCP 4.6 Remote OMC / Remote MCP Access 4.7 Plugin 目錄旗標（Decision Matrix） 4.8 Skills 設定 4.9 任務模板設定 4.10 何時需要重新執行 Setup 5. 使用方式（實戰） 5.1 基本使用（含 Ultragoal、Multi-Repo 整合） 5.2 Web Application 開發（重點） 5.3 逆向工程（Legacy System） 5.4 Framework 升級 6. Multi-Agent 協作設計（進階） 6.1 Agent Roles 設計模式 6.2 Planner → Executor → Reviewer Flow 6.3 tmux CLI Workers（多模型協作） 6.4 Code Review Agent 6.5 Security Agent（SSDLC） 7. Skills Learning 系統 7.1 Skills 總覽（35 個 Skills 完整清單） 7.2 Skills 如何產生 7.3 Skills 儲存與重用 7.4 建立企業內知識庫 8. 效能與成本優化 8.1 Token 使用最佳化 8.2 模型選擇策略 8.3 平行處理設計 8.4 HUD 監控與分析 9. SSDLC 整合（企業級重點） 9.1 安全設定（Security Mode） 9.2 Secure Coding 9.3 SAST / DAST 整合 9.4 威脅建模（Threat Modeling） 9.5 Compliance（金融業） 9.6 已知安全限制 10. 系統維運（Maintenance） 10.1 Log 與監控 10.2 Agent Debug 10.3 錯誤排除 10.4 狀態管理 10.5 Project Memory 系統 10.6 Notepad 系統（壓縮抗性備忘錄） 10.7 Plan Notepad（每計畫知識擷取） 10.8 Session Scope（Session 隔離） 10.9 Code Simplifier Hook 10.10 OpenClaw 整合（外部事件閘道器） 11. 系統升級（Upgrade） 11.1 oh-my-claudecode 升級策略 11.2 升級後驗證 11.3 Agent 相容性 11.4 Config Migration 11.5 解除安裝 11.6 版本遷移指南摘要 12. 最佳實務（Best Practices） 12.1 Agent 設計原則 12.2 Prompt Engineering 12.3 開發流程標準化 13. 範例（完整案例） 13.1 案例一：Web 系統開發（全流程） 13.2 案例二：Legacy 系統重構 13.3 案例三：Framework 升級 14. 團隊導入建議 14.1 如何導入公司 14.2 Developer Workflow 設計 14.3 Governance（權限 / 審核） 15. 附錄 15.1 CLI 指令清單 15.2 常見錯誤 15.3 Prompt 範本 15.4 可用工具清單 16. 檢查清單（Checklist） 1. 概述 1.1 什麼是 oh-my-claudecode oh-my-claudecode（簡稱 OMC）是一個開源的 Multi-Agent 編排框架，專為 Claude Code CLI 打造。它讓 Claude Code 從「單一 Agent 對話工具」升級為「Teams-first 多智能體協作平台」。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/oh-my-claudecode-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"oh-my-claudecode 教學手冊（完整版） 版本：v4.15.1（2026-06-27）\n文件更新日期：2026-07-01\n適用對象：資深工程師、架構師、技術主管\n定位：企業級 Multi-Agent 編排實戰手冊\n授權：MIT License\n官方網站：https://oh-my-claudecode.dev\n目錄 1. 概述 1.1 什麼是 oh-my-claudecode 1.2 與傳統 Claude Code 的差異 1.3 與 GitHub Copilot 的整合方式 1.4 適用場景 2. 整體架構設計（Architecture） 2.1 Multi-Agent 架構圖 2.2 Agent 分工（29 個 Agent） 2.3 任務分解機制（Task Decomposition） 2.4 Agent 角色邊界 2.5 驗證協定（Verification Protocol） 2.6 Agent 通訊機制 2.7 狀態管理架構：Control Plane vs Data Plane 2.8 與外部系統整合 3. 安裝與環境建置（Step-by-step） 3.1 前置需求 3.2 安裝 oh-my-claudecode 3.3 初始設定（Setup） 3.4 tmux / psmux 安裝（各平台） 3.5 可選：多 AI 模型支援 3.6 啟用 Claude Code Native Teams 3.7 驗證安裝 4. 核心設定（Configuration） 4.1 設定檔結構與優先順序 4.2 環境變數 4.3 Agent 設定（自訂 / 修改） 4.4 模型路由策略（Cost Optimization） 4.5 Company Context via MCP 4.6 Remote OMC / Remote MCP Access 4.7 Plugin 目錄旗標（Decision Matrix） 4.8 Skills 設定 4.9 任務模板設定 4.10 何時需要重新執行 Setup 5. 使用方式（實戰） 5.1 基本使用（含 Ultragoal、Multi-Repo 整合） 5.2 Web Application 開發（重點） 5.3 逆向工程（Legacy System） 5.4 Framework 升級 6. Multi-Agent 協作設計（進階） 6.1 Agent Roles 設計模式 6.2 Planner → Executor → Reviewer Flow 6.3 tmux CLI Workers（多模型協作） 6.4 Code Review Agent 6.5 Security Agent（SSDLC） 7. Skills Learning 系統 7.1 Skills 總覽（35 個 Skills 完整清單） 7.2 Skills 如何產生 7.3 Skills 儲存與重用 7.4 建立企業內知識庫 8. 效能與成本優化 8.1 Token 使用最佳化 8.2 模型選擇策略 8.3 平行處理設計 8.4 HUD 監控與分析 9. SSDLC 整合（企業級重點） 9.1 安全設定（Security Mode） 9.2 Secure Coding 9.3 SAST / DAST 整合 9.4 威脅建模（Threat Modeling） 9.5 Compliance（金融業） 9.6 已知安全限制 10. 系統維運（Maintenance） 10.1 Log 與監控 10.2 Agent Debug 10.3 錯誤排除 10.4 狀態管理 10.5 Project Memory 系統 10.6 Notepad 系統（壓縮抗性備忘錄） 10.7 Plan Notepad（每計畫知識擷取） 10.8 Session Scope（Session 隔離） 10.9 Code Simplifier Hook 10.10 OpenClaw 整合（外部事件閘道器） 11. 系統升級（Upgrade） 11.1 oh-my-claudecode 升級策略 11.2 升級後驗證 11.3 Agent 相容性 11.4 Config Migration 11.5 解除安裝 11.6 版本遷移指南摘要 12. 最佳實務（Best Practices） 12.1 Agent 設計原則 12.2 Prompt Engineering 12.3 開發流程標準化 13. 範例（完整案例） 13.1 案例一：Web 系統開發（全流程） 13.2 案例二：Legacy 系統重構 13.3 案例三：Framework 升級 14. 團隊導入建議 14.1 如何導入公司 14.2 Developer Workflow 設計 14.3 Governance（權限 / 審核） 15. 附錄 15.1 CLI 指令清單 15.2 常見錯誤 15.3 Prompt 範本 15.4 可用工具清單 16. 檢查清單（Checklist） 1. 概述 1.1 什麼是 oh-my-claudecode oh-my-claudecode（簡稱 OMC）是一個開源的 Multi-Agent 編排框架，專為 Claude Code CLI 打造。它讓 Claude Code 從「單一 Agent 對話工具」升級為「Teams-first 多智能體協作平台」。\n","title":"Oh My Claudecode 教學手冊"},{"content":"BMAD-METHOD 使用教學手冊 文件版本：6.0\n最後更新：2026 年 6 月 30 日\n適用版本：BMAD METHOD v6.9.0（穩定版）\n適用對象：新進軟體工程師、系統分析師、專案成員\n前置知識：基本軟體開發概念、版本控制基礎\nCreated by：Eric Cheng\n目錄 前言 第一章：BMAD-METHOD 是什麼 1.1 方法論背景與設計目的 1.2 BMAD 與傳統開發流程的差異 1.3 為什麼 BMAD 特別適合 AI 協作開發 第二章：BMAD-METHOD 的核心概念 2.1 四大核心階段概覽 2.2 Analysis（分析）階段 2.3 Planning（規劃）階段 2.4 Solutioning（方案設計）階段 2.5 Implementation（實作）階段 2.6 各階段的目標、輸入與輸出 2.7 安裝與設定指南 2.8 官方模組總覽 2.9 Skills 架構深入解說 2.10 專案上下文管理（Project Context） 2.11 官方模組深入解說 2.12 Quick Flow 完整實戰指南 2.13 Dev Loop 自動化開發循環 2.14 新增工作流程參考 2.15 bmad-architecture 脊柱式架構設計（v6.9.0） 2.16 bmad-ux 雙脊柱-ux-設計（v6.8.0） 2.17 bmad-prd 統一-prd-管理（v6.7.0） 2.18 bmad-spec 規格蒸餾器（v6.8.0） 2.19 bmad-forge-idea 創意壓力測試（v6.9.0） 2.20 Web Bundles 網頁規劃套件（v6.8.0） 2.21 bmad-dev-auto 自主開發迴圈（v6.8.0+） 2.22 決策日誌與-memlog-工作記憶（v6.7.0/v6.9.0） 第三章：BMAD-METHOD 整體流程說明 3.1 從需求發想到交付的完整流程 3.2 每個階段與 AI 的互動方式 3.3 建議的文件與產出物 第四章：各階段詳細教學 4.1 Analysis 階段詳細教學 4.2 Planning 階段詳細教學 4.3 Solutioning 階段詳細教學 4.4 Implementation 階段詳細教學 第五章：AI Prompt 實戰範例 5.1 Analysis 階段 Prompt 範例 5.2 Planning 階段 Prompt 範例 5.3 Solutioning 階段 Prompt 範例 5.4 Implementation 階段 Prompt 範例 5.5 銀行與大型系統專用 Prompt 實戰對話 5.6 BMAD v6 Skills 實戰 Prompt 範例 5.7 BMAD v6.7–v6.9 新 Skill 實戰 Prompt 範例 第六章：BMAD-METHOD 與其他方法論比較 6.1 與 Scrum / SAFe 的差異 6.2 與 SDD / Spec-Kit 的差異 6.3 適用與不適用情境 第七章：新進同仁快速上手指南 7.1 第一週可以怎麼用 BMAD 7.2 建議學習順序 7.3 團隊內導入建議 第八章：常見問題（FAQ） Q1：BMAD 是否會取代 SA / PG？ Q2：BMAD 是否一定要用 AI？ Q3：如何在既有（Brownfield）系統中導入？ Q4：BMAD 產出的文件品質如何？ Q5：如何處理 AI 產出的錯誤？ Q6：BMAD 適合什麼規模的團隊？ Q7：如何評估 BMAD 導入效果？ Q8：Skills 和舊版 Slash Commands 有什麼差別？ Q9：如何選擇適當的 IDE？ Q10：project-context.md 需要手動維護嗎？ Q11：如何處理多個 AI 代理之間的上下文切換？ Q12：BMAD 如何與 CI/CD 整合？ Q13：如何在離線環境中使用 BMAD？ Q14：bmad-dev-auto 自主開發迴圈的使用建議？ Q15：Web Bundles 如何節省成本？ Q16：如何從舊版 Skill 遷移到新版？ 疑難排解（Troubleshooting） 常見問題排除 效能最佳化建議 進階主題：BMAD 客製化與擴展 進階 1：使用 BMB 建立客製化代理 進階 2：建立組織專屬的工作流程範本 進階 3：多模組整合架構 進階 4：llms-full.txt 與 AI 自助學習 進階 5：Brownfield 專案遷移策略 進階 6：TOML 客製化框架（v6.4.0 新增） 進階 7：發布通道管理（v6.4.0 新增） 進階 8：v6.5.0 跨平台 Skills 標準 進階 9：WDS 白港設計工作室（v6.7.0） 進階 10：bmad-method-ui 視覺化介面（v6.8.0） 附錄：檢查清單（Checklist） A. BMAD 專案啟動檢查清單 B. 各階段完成檢查清單 C. AI 協作品質檢查清單 D. 新進同仁學習進度檢查清單 術語表（Glossary） 代理角色快速對照 常用 Skill ID 快速對照 參考資源 版本紀錄 前言 為什麼需要這份手冊？ 在人工智慧快速發展的時代，軟體開發方式正經歷革命性變化。傳統的開發流程往往無法充分發揮 AI 助手的潛力，導致：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/bmad-method%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"BMAD-METHOD 使用教學手冊 文件版本：6.0\n最後更新：2026 年 6 月 30 日\n適用版本：BMAD METHOD v6.9.0（穩定版）\n適用對象：新進軟體工程師、系統分析師、專案成員\n前置知識：基本軟體開發概念、版本控制基礎\nCreated by：Eric Cheng\n目錄 前言 第一章：BMAD-METHOD 是什麼 1.1 方法論背景與設計目的 1.2 BMAD 與傳統開發流程的差異 1.3 為什麼 BMAD 特別適合 AI 協作開發 第二章：BMAD-METHOD 的核心概念 2.1 四大核心階段概覽 2.2 Analysis（分析）階段 2.3 Planning（規劃）階段 2.4 Solutioning（方案設計）階段 2.5 Implementation（實作）階段 2.6 各階段的目標、輸入與輸出 2.7 安裝與設定指南 2.8 官方模組總覽 2.9 Skills 架構深入解說 2.10 專案上下文管理（Project Context） 2.11 官方模組深入解說 2.12 Quick Flow 完整實戰指南 2.13 Dev Loop 自動化開發循環 2.14 新增工作流程參考 2.15 bmad-architecture 脊柱式架構設計（v6.9.0） 2.16 bmad-ux 雙脊柱-ux-設計（v6.8.0） 2.17 bmad-prd 統一-prd-管理（v6.7.0） 2.18 bmad-spec 規格蒸餾器（v6.8.0） 2.19 bmad-forge-idea 創意壓力測試（v6.9.0） 2.20 Web Bundles 網頁規劃套件（v6.8.0） 2.21 bmad-dev-auto 自主開發迴圈（v6.8.0+） 2.22 決策日誌與-memlog-工作記憶（v6.7.0/v6.9.0） 第三章：BMAD-METHOD 整體流程說明 3.1 從需求發想到交付的完整流程 3.2 每個階段與 AI 的互動方式 3.3 建議的文件與產出物 第四章：各階段詳細教學 4.1 Analysis 階段詳細教學 4.2 Planning 階段詳細教學 4.3 Solutioning 階段詳細教學 4.4 Implementation 階段詳細教學 第五章：AI Prompt 實戰範例 5.1 Analysis 階段 Prompt 範例 5.2 Planning 階段 Prompt 範例 5.3 Solutioning 階段 Prompt 範例 5.4 Implementation 階段 Prompt 範例 5.5 銀行與大型系統專用 Prompt 實戰對話 5.6 BMAD v6 Skills 實戰 Prompt 範例 5.7 BMAD v6.7–v6.9 新 Skill 實戰 Prompt 範例 第六章：BMAD-METHOD 與其他方法論比較 6.1 與 Scrum / SAFe 的差異 6.2 與 SDD / Spec-Kit 的差異 6.3 適用與不適用情境 第七章：新進同仁快速上手指南 7.1 第一週可以怎麼用 BMAD 7.2 建議學習順序 7.3 團隊內導入建議 第八章：常見問題（FAQ） Q1：BMAD 是否會取代 SA / PG？ Q2：BMAD 是否一定要用 AI？ Q3：如何在既有（Brownfield）系統中導入？ Q4：BMAD 產出的文件品質如何？ Q5：如何處理 AI 產出的錯誤？ Q6：BMAD 適合什麼規模的團隊？ Q7：如何評估 BMAD 導入效果？ Q8：Skills 和舊版 Slash Commands 有什麼差別？ Q9：如何選擇適當的 IDE？ Q10：project-context.md 需要手動維護嗎？ Q11：如何處理多個 AI 代理之間的上下文切換？ Q12：BMAD 如何與 CI/CD 整合？ Q13：如何在離線環境中使用 BMAD？ Q14：bmad-dev-auto 自主開發迴圈的使用建議？ Q15：Web Bundles 如何節省成本？ Q16：如何從舊版 Skill 遷移到新版？ 疑難排解（Troubleshooting） 常見問題排除 效能最佳化建議 進階主題：BMAD 客製化與擴展 進階 1：使用 BMB 建立客製化代理 進階 2：建立組織專屬的工作流程範本 進階 3：多模組整合架構 進階 4：llms-full.txt 與 AI 自助學習 進階 5：Brownfield 專案遷移策略 進階 6：TOML 客製化框架（v6.4.0 新增） 進階 7：發布通道管理（v6.4.0 新增） 進階 8：v6.5.0 跨平台 Skills 標準 進階 9：WDS 白港設計工作室（v6.7.0） 進階 10：bmad-method-ui 視覺化介面（v6.8.0） 附錄：檢查清單（Checklist） A. BMAD 專案啟動檢查清單 B. 各階段完成檢查清單 C. AI 協作品質檢查清單 D. 新進同仁學習進度檢查清單 術語表（Glossary） 代理角色快速對照 常用 Skill ID 快速對照 參考資源 版本紀錄 前言 為什麼需要這份手冊？ 在人工智慧快速發展的時代，軟體開發方式正經歷革命性變化。傳統的開發流程往往無法充分發揮 AI 助手的潛力，導致：\n","title":"BMAD METHOD使用教學"},{"content":"Compound Engineering 教學手冊 版本：v3.16.0（2026-06-30）\n適用平台：Claude Code / Cursor / Codex / OpenCode / GitHub Copilot / Kimi Code / Antigravity (agy) / Factory Droid / Qwen Code / Pi 等\n授權：MIT License\nGitHub：https://github.com/EveryInc/compound-engineering-plugin\n文件等級：企業標準技術白皮書\n最後更新：2026-06-30\n目錄 第一章：概述 1.1 什麼是 Compound Engineering（複利工程） 1.2 與傳統 AI Coding 工具比較 1.3 核心設計哲學 1.4 適用場景 1.5 開發成熟度階段模型 第二章：系統架構整合 2.1 整體架構圖 2.2 Plugin 元件總覽 2.3 核心概念詞彙表 2.4 與企業系統整合方式 2.5 Skill Workflow 設計 2.6 知識庫（Knowledge Base）設計 第三章：安裝與環境建置 3.1 前置需求 3.2 Claude Code 安裝 3.3 Cursor 安裝 3.4 Codex 安裝（App / CLI） 3.5 GitHub Copilot 安裝 3.6 其他平台安裝 3.7 升級現有安裝 3.8 ce-setup 環境診斷與初始化 3.9 Windows 環境設定 3.10 CI/CD 環境設定 3.11 本地開發模式 第四章：核心功能教學 4.1 核心工作流總覽 4.2 /ce-ideate — 創意探索 4.3 /ce-brainstorm — 需求發散 4.4 /ce-plan — 計畫制定 4.5 /ce-work — 開發執行 4.6 /ce-simplify-code — 程式碼精簡 4.7 /ce-code-review — 結構化品質審查 4.8 /ce-compound — 知識沉澱 4.9 /ce-debug — 除錯追蹤 4.10 /ce-optimize — 最佳化迴圈 4.11 /ce-pov — 技術裁決 4.12 /ce-strategy — 策略定錨 4.13 /ce-product-pulse — 產品脈搏 4.14 /ce-dogfood — 自動化瀏覽器 QA 4.15 /ce-test-browser — 瀏覽器測試 4.16 /ce-test-xcode — iOS 應用測試 4.17 /lfg — 全自動工程工作流 4.18 錯誤案例與修正 第五章：企業級開發流程設計 5.1 AI Agent 開發流程（SSDLC 整合） 5.2 與 Git Flow 整合 5.3 與 CI/CD 整合 5.4 Code Review 自動化 5.5 測試策略 第六章：最佳實務（Best Practices） 6.1 Prompt Engineering — 如何寫好 ce-plan 6.2 Context Engineering — 上下文管理 6.3 Knowledge Reuse — 複利最大化 6.4 防止 AI Hallucination 6.5 隱私與安全政策 6.6 Agent-Native 架構設計 6.7 需要放下的信念 第七章：系統維運（Maintenance） 7.1 知識庫管理策略 7.2 Plugin 效能調校 7.3 Log / Monitoring 設計 7.4 問題排查（Troubleshooting） 第八章：系統升級（Upgrade Strategy） 8.1 Plugin 升級流程 8.2 知識庫版本控制 8.3 向下相容策略 8.4 災難復原（Disaster Recovery） 第九章：企業導入建議 9.1 導入策略（Pilot → Rollout） 9.2 團隊角色轉變 9.3 KPI 設計 9.4 教育訓練計畫 9.5 團隊協作模式 第十章：完整實戰案例 10.1 案例背景 10.2 ce-brainstorm — 需求發散 10.3 ce-plan — 任務拆解 10.4 ce-work — 產生程式碼 10.5 ce-simplify-code — 精簡程式碼 10.6 ce-code-review — 改善品質 10.7 ce-compound — 知識沉澱 附錄 A：Skills 完整參考表 附錄 B：Specialist Prompt Assets 參考表 附錄 C：常用指令 Cheat Sheet 附錄 D：新進成員檢查清單（Checklist） 附錄 E：參考資源與延伸閱讀 第一章：概述 1.1 什麼是 Compound Engineering（複利工程） Compound Engineering（複利工程）是由 Every Inc. 提出的軟體工程方法論，以開源 Plugin 形式實現。其核心理念為：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/compound-engineering-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Compound Engineering 教學手冊 版本：v3.16.0（2026-06-30）\n適用平台：Claude Code / Cursor / Codex / OpenCode / GitHub Copilot / Kimi Code / Antigravity (agy) / Factory Droid / Qwen Code / Pi 等\n授權：MIT License\nGitHub：https://github.com/EveryInc/compound-engineering-plugin\n文件等級：企業標準技術白皮書\n最後更新：2026-06-30\n目錄 第一章：概述 1.1 什麼是 Compound Engineering（複利工程） 1.2 與傳統 AI Coding 工具比較 1.3 核心設計哲學 1.4 適用場景 1.5 開發成熟度階段模型 第二章：系統架構整合 2.1 整體架構圖 2.2 Plugin 元件總覽 2.3 核心概念詞彙表 2.4 與企業系統整合方式 2.5 Skill Workflow 設計 2.6 知識庫（Knowledge Base）設計 第三章：安裝與環境建置 3.1 前置需求 3.2 Claude Code 安裝 3.3 Cursor 安裝 3.4 Codex 安裝（App / CLI） 3.5 GitHub Copilot 安裝 3.6 其他平台安裝 3.7 升級現有安裝 3.8 ce-setup 環境診斷與初始化 3.9 Windows 環境設定 3.10 CI/CD 環境設定 3.11 本地開發模式 第四章：核心功能教學 4.1 核心工作流總覽 4.2 /ce-ideate — 創意探索 4.3 /ce-brainstorm — 需求發散 4.4 /ce-plan — 計畫制定 4.5 /ce-work — 開發執行 4.6 /ce-simplify-code — 程式碼精簡 4.7 /ce-code-review — 結構化品質審查 4.8 /ce-compound — 知識沉澱 4.9 /ce-debug — 除錯追蹤 4.10 /ce-optimize — 最佳化迴圈 4.11 /ce-pov — 技術裁決 4.12 /ce-strategy — 策略定錨 4.13 /ce-product-pulse — 產品脈搏 4.14 /ce-dogfood — 自動化瀏覽器 QA 4.15 /ce-test-browser — 瀏覽器測試 4.16 /ce-test-xcode — iOS 應用測試 4.17 /lfg — 全自動工程工作流 4.18 錯誤案例與修正 第五章：企業級開發流程設計 5.1 AI Agent 開發流程（SSDLC 整合） 5.2 與 Git Flow 整合 5.3 與 CI/CD 整合 5.4 Code Review 自動化 5.5 測試策略 第六章：最佳實務（Best Practices） 6.1 Prompt Engineering — 如何寫好 ce-plan 6.2 Context Engineering — 上下文管理 6.3 Knowledge Reuse — 複利最大化 6.4 防止 AI Hallucination 6.5 隱私與安全政策 6.6 Agent-Native 架構設計 6.7 需要放下的信念 第七章：系統維運（Maintenance） 7.1 知識庫管理策略 7.2 Plugin 效能調校 7.3 Log / Monitoring 設計 7.4 問題排查（Troubleshooting） 第八章：系統升級（Upgrade Strategy） 8.1 Plugin 升級流程 8.2 知識庫版本控制 8.3 向下相容策略 8.4 災難復原（Disaster Recovery） 第九章：企業導入建議 9.1 導入策略（Pilot → Rollout） 9.2 團隊角色轉變 9.3 KPI 設計 9.4 教育訓練計畫 9.5 團隊協作模式 第十章：完整實戰案例 10.1 案例背景 10.2 ce-brainstorm — 需求發散 10.3 ce-plan — 任務拆解 10.4 ce-work — 產生程式碼 10.5 ce-simplify-code — 精簡程式碼 10.6 ce-code-review — 改善品質 10.7 ce-compound — 知識沉澱 附錄 A：Skills 完整參考表 附錄 B：Specialist Prompt Assets 參考表 附錄 C：常用指令 Cheat Sheet 附錄 D：新進成員檢查清單（Checklist） 附錄 E：參考資源與延伸閱讀 第一章：概述 1.1 什麼是 Compound Engineering（複利工程） Compound Engineering（複利工程）是由 Every Inc. 提出的軟體工程方法論，以開源 Plugin 形式實現。其核心理念為：\n","title":"Compound Engineering 教學手冊"},{"content":"GitNexus 教學手冊（企業級完整版） 版本：v1.6.8（2026-06 基準，含 PDG / Taint Analysis、MCP Trace 工具、Private Repos via PAT、DevContainer、MCP HTTP Server）\n適用對象：資深工程師 / 架構師 / DevOps / AI Agent 開發者\n授權：PolyForm Noncommercial 1.0.0（企業授權另洽 akonlabs.com）\n維護單位：內部 AI 開發組\nGitHub：github.com/abhigyanpatwari/GitNexus （⭐ 43.3k+ Stars / 163+ Contributors）\nOpenSSF Scorecard：securityscorecards.dev\n⚠️ 重要警告：GitNexus 沒有官方加密貨幣、代幣或硬幣。任何在 Pump.fun 或其他平台上使用 GitNexus 名稱的代幣/硬幣，均非本專案或其維護者所屬、認可或建立。請勿購買任何聲稱與 GitNexus 相關的加密貨幣。\n目錄 第 1 章：GitNexus 概述 1.1 GitNexus 是什麼 1.2 核心理念 1.3 與傳統工具比較 1.4 適用場景 第 2 章：系統架構說明 2.1 整體架構圖 2.2 核心組件說明 2.3 Web UI vs CLI 架構差異 2.4 Multi-Repo MCP 架構 第 3 章：安裝與環境設定 3.1 系統需求 3.2 CLI 安裝 3.3 Web UI 使用 3.4 MCP 編輯器設定 3.5 Docker 部署 3.6 常見問題排除 第 4 章：基本操作教學 4.1 建立 Knowledge Graph 4.2 CLI 常用指令 4.3 查詢程式碼關聯 4.4 視覺化圖譜操作 4.5 Repository 群組管理 第 5 章：進階應用 5.1 Graph RAG 使用方式 5.2 Impact Analysis（影響分析） 5.3 Process-Grouped Search 5.4 360 度 Symbol Context 5.5 Git-Diff 變更偵測 5.6 Multi-File Rename 5.7 Cypher 原生查詢 5.8 Wiki 自動生成 5.9 Incremental Indexing（增量索引） 5.10 PDG / 程式依賴圖分析 5.11 Taint Analysis（污染分析） 5.12 Trace（呼叫路徑追蹤） 5.13 Private Repos 與 Azure DevOps Server 5.14 HTTP Route Extraction（HTTP 路由提取） 5.15 DevContainer 開發環境 第 6 章：整合企業開發流程 6.1 與 GitHub / GitLab 整合 6.2 與 AI 工具整合 6.3 與開發架構整合 6.4 DevOps 整合 6.5 Community Integrations（社群整合） 6.6 開發文件與貢獻指南 6.7 understand-quickly 公開註冊 第 7 章：銀行 / 大型系統應用案例 7.1 案例一：批次系統依賴分析 7.2 案例二：跨系統 API 呼叫分析 7.3 案例三：DB Schema 影響分析 第 8 章：安全與隱私（SSDLC） 8.1 Zero-Server 優勢 8.2 原始碼保護 8.3 本地 AI 模型風險 8.4 權限控管建議 8.5 安全強化歷史與已知修復 8.6 Taint Analysis 安全審計應用 8.7 供應鏈保護（Supply-Chain Protection） 第 9 章：系統升級與維運 9.1 GitNexus 升級流程 9.2 Graph 重建策略 9.3 Repository 更新同步 9.4 效能優化建議 9.5 LadybugDB 遷移指南 9.6 Edge Type 遷移（OVERRIDES → METHOD_OVERRIDES） 第 10 章：最佳實務（Best Practices） 10.1 大型專案使用建議 10.2 Monorepo vs Multi-repo 10.3 團隊導入策略 10.4 使用限制與風險 第 11 章：常見問題 FAQ 第 12 章：未來發展與建議 12.1 Graph RAG 未來趨勢 12.2 與 Agent 系統整合 12.3 企業導入 Roadmap 附錄 A：快速檢查清單（Checklist） 附錄 B：CLI 指令速查表 附錄 C：MCP 工具速查表 附錄 D：語言能力詳細矩陣 附錄 E：Edge Type（關係類型）速查表 附錄 F：Docker 部署速查表 附錄 G：.gitnexusrc 專案配置速查表 附錄 H：PDG / Taint 邊類型速查表 第 1 章：GitNexus 概述 1.1 GitNexus 是什麼 🎯 目的：讓團隊成員在 5 分鐘內理解 GitNexus 的定位與價值。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/gitnexus%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitNexus 教學手冊（企業級完整版） 版本：v1.6.8（2026-06 基準，含 PDG / Taint Analysis、MCP Trace 工具、Private Repos via PAT、DevContainer、MCP HTTP Server）\n適用對象：資深工程師 / 架構師 / DevOps / AI Agent 開發者\n授權：PolyForm Noncommercial 1.0.0（企業授權另洽 akonlabs.com）\n維護單位：內部 AI 開發組\nGitHub：github.com/abhigyanpatwari/GitNexus （⭐ 43.3k+ Stars / 163+ Contributors）\nOpenSSF Scorecard：securityscorecards.dev\n⚠️ 重要警告：GitNexus 沒有官方加密貨幣、代幣或硬幣。任何在 Pump.fun 或其他平台上使用 GitNexus 名稱的代幣/硬幣，均非本專案或其維護者所屬、認可或建立。請勿購買任何聲稱與 GitNexus 相關的加密貨幣。\n目錄 第 1 章：GitNexus 概述 1.1 GitNexus 是什麼 1.2 核心理念 1.3 與傳統工具比較 1.4 適用場景 第 2 章：系統架構說明 2.1 整體架構圖 2.2 核心組件說明 2.3 Web UI vs CLI 架構差異 2.4 Multi-Repo MCP 架構 第 3 章：安裝與環境設定 3.1 系統需求 3.2 CLI 安裝 3.3 Web UI 使用 3.4 MCP 編輯器設定 3.5 Docker 部署 3.6 常見問題排除 第 4 章：基本操作教學 4.1 建立 Knowledge Graph 4.2 CLI 常用指令 4.3 查詢程式碼關聯 4.4 視覺化圖譜操作 4.5 Repository 群組管理 第 5 章：進階應用 5.1 Graph RAG 使用方式 5.2 Impact Analysis（影響分析） 5.3 Process-Grouped Search 5.4 360 度 Symbol Context 5.5 Git-Diff 變更偵測 5.6 Multi-File Rename 5.7 Cypher 原生查詢 5.8 Wiki 自動生成 5.9 Incremental Indexing（增量索引） 5.10 PDG / 程式依賴圖分析 5.11 Taint Analysis（污染分析） 5.12 Trace（呼叫路徑追蹤） 5.13 Private Repos 與 Azure DevOps Server 5.14 HTTP Route Extraction（HTTP 路由提取） 5.15 DevContainer 開發環境 第 6 章：整合企業開發流程 6.1 與 GitHub / GitLab 整合 6.2 與 AI 工具整合 6.3 與開發架構整合 6.4 DevOps 整合 6.5 Community Integrations（社群整合） 6.6 開發文件與貢獻指南 6.7 understand-quickly 公開註冊 第 7 章：銀行 / 大型系統應用案例 7.1 案例一：批次系統依賴分析 7.2 案例二：跨系統 API 呼叫分析 7.3 案例三：DB Schema 影響分析 第 8 章：安全與隱私（SSDLC） 8.1 Zero-Server 優勢 8.2 原始碼保護 8.3 本地 AI 模型風險 8.4 權限控管建議 8.5 安全強化歷史與已知修復 8.6 Taint Analysis 安全審計應用 8.7 供應鏈保護（Supply-Chain Protection） 第 9 章：系統升級與維運 9.1 GitNexus 升級流程 9.2 Graph 重建策略 9.3 Repository 更新同步 9.4 效能優化建議 9.5 LadybugDB 遷移指南 9.6 Edge Type 遷移（OVERRIDES → METHOD_OVERRIDES） 第 10 章：最佳實務（Best Practices） 10.1 大型專案使用建議 10.2 Monorepo vs Multi-repo 10.3 團隊導入策略 10.4 使用限制與風險 第 11 章：常見問題 FAQ 第 12 章：未來發展與建議 12.1 Graph RAG 未來趨勢 12.2 與 Agent 系統整合 12.3 企業導入 Roadmap 附錄 A：快速檢查清單（Checklist） 附錄 B：CLI 指令速查表 附錄 C：MCP 工具速查表 附錄 D：語言能力詳細矩陣 附錄 E：Edge Type（關係類型）速查表 附錄 F：Docker 部署速查表 附錄 G：.gitnexusrc 專案配置速查表 附錄 H：PDG / Taint 邊類型速查表 第 1 章：GitNexus 概述 1.1 GitNexus 是什麼 🎯 目的：讓團隊成員在 5 分鐘內理解 GitNexus 的定位與價值。\n","title":"GitNexus教學手冊"},{"content":"gstack 企業級教學手冊 參考版本：v1.58.5.0 ｜ 更新日期：2026-06-30\nGitHub 星數：118,000+ ⭐ ｜ Forks：17,600+ ｜ 貢獻者：81 位 ｜ 授權：MIT\n適用對象：資深工程師、架構師、DevOps 工程師、技術主管、創辦人與技術主管\n適用場景：新創公司、企業平台、微服務架構、金融系統、iOS 開發\n參考來源：https://github.com/garrytan/gstack\n目錄 gstack 概述 1.1 什麼是 gstack 1.2 背景：Garry Tan 與 YC 1.3 與傳統 Prompt Engineering 的差異 1.4 與 GitHub Copilot / AI Agent 的比較 1.5 適用場景 1.6 版本與現況 核心架構設計 2.1 企業級系統整體架構 2.2 AI Agent 協作架構圖 2.3 分庫分表設計 2.4 Clean Architecture（後端服務） 2.5 gstack 內部架構 安裝與環境建置 3.1 必備環境 3.2 安裝 Claude Code 3.3 安裝 gstack（推薦：Team Mode） 3.4 加入專案供團隊共用（選用） 3.5 多平台安裝支援 3.6 OpenClaw 整合 3.7 語音輸入支援 3.8 設定 CLAUDE.md 3.9 常見安裝錯誤排除 Sprint 工作流程與技能體系 4.1 Sprint 核心哲學 4.2 技能串聯關係 4.3 完整技能目錄（30+ 個） 4.4 Builder Ethos（建構者信條） 虛擬開發團隊設計（企業實戰） 5.1 團隊架構總覽 5.2 ／office-hours（YC 辦公室時光） 5.3 ／plan-ceo-review（CEO 視角） 5.4 ／plan-eng-review（工程主管視角） 5.5 ／plan-design-review（設計師視角） 5.6 ／review（資深工程師審查） 5.7 ／qa（QA 主管） 5.8 ／cso（首席資安官） 5.9 ／ship（發布工程師） 5.10 ／investigate（系統偵錯） 端到端開發流程 6.1 完整開發流程圖 6.2 各步驟執行指令 6.3 分支策略與 PR 規範 實戰案例：會員管理系統 7.1 系統設計概覽 7.2 API 設計 7.3 DB Schema 7.4 Clean Architecture 後端實作 7.5 前端（Vue 3） 7.6 gstack 技能參與對照表 DevOps 與自動化 8.1 CI/CD 架構圖 8.2 GitHub Actions CI 設定 8.3 Dockerfile（多階段建置） 8.4 ／land-and-deploy 一鍵部署 8.5 ／canary 金絲雀監控 8.6 ／benchmark 效能基準 並行 Sprint 與瀏覽器模式 9.1 並行 Sprint 架構 9.2 Conductor 整合 9.3 瀏覽器模式（／browse） 9.4 真實 Chrome 模式（$B connect） 9.5 CSS Inspector 與 Live Style 編輯 9.6 瀏覽器交接（Browser Handoff） 9.7 持續檢查點模式（Continuous Checkpoint） 9.8 Domain Skills 與 CDP Escape Hatch 系統維運 10.1 日誌策略（Log4j2 + ELK） 10.2 監控儀表板（Prometheus + Grafana） 10.3 AI 協助 Debug（gstack Investigate Mode） 10.4 錯誤追蹤（Sentry 整合） 系統升級與擴展 11.1 gstack 升級策略 11.2 多平台自動升級 11.3 自訂 SKILL.md 擴展 11.4 多專案管理 11.5 Plugin 與 Skill 擴充 11.6 解除安裝 企業級安全設計 12.1 ／cso 安全審查流程 12.2 身份驗證（OAuth2 + JWT） 12.3 RBAC 權限控管 12.4 SAST / DAST 整合 12.5 AI 生成代碼安全風險管控 12.6 瀏覽器模式安全加固 12.7 Layer C 反偵測機制 最佳實務 Best Practices 13.1 企業導入十二大建議 13.2 常見錯誤 13.3 Anti-patterns 對照表 GBrain 持久知識系統 14.1 GBrain 概觀 14.2 安裝路徑 14.3 Per-Repo 信任機制 14.4 記憶同步與安全 14.5 Conductor 環境變數 隱私與遙測 15.1 遙測機制 15.2 資料收集範圍 15.3 本地分析報告 附錄：快速上手 Checklist 1. gstack 概述 1.1 什麼是 gstack gstack 是由 Y Combinator President \u0026amp; CEO Garry Tan 開源的 AI 編碼代理虛擬工程團隊技能套件，開源於 github.com/garrytan/gstack，目前已累積超過 118,000 顆星、17,600+ Forks，是目前最受矚目的 AI 輔助開發工具之一。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/gstack%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"gstack 企業級教學手冊 參考版本：v1.58.5.0 ｜ 更新日期：2026-06-30\nGitHub 星數：118,000+ ⭐ ｜ Forks：17,600+ ｜ 貢獻者：81 位 ｜ 授權：MIT\n適用對象：資深工程師、架構師、DevOps 工程師、技術主管、創辦人與技術主管\n適用場景：新創公司、企業平台、微服務架構、金融系統、iOS 開發\n參考來源：https://github.com/garrytan/gstack\n目錄 gstack 概述 1.1 什麼是 gstack 1.2 背景：Garry Tan 與 YC 1.3 與傳統 Prompt Engineering 的差異 1.4 與 GitHub Copilot / AI Agent 的比較 1.5 適用場景 1.6 版本與現況 核心架構設計 2.1 企業級系統整體架構 2.2 AI Agent 協作架構圖 2.3 分庫分表設計 2.4 Clean Architecture（後端服務） 2.5 gstack 內部架構 安裝與環境建置 3.1 必備環境 3.2 安裝 Claude Code 3.3 安裝 gstack（推薦：Team Mode） 3.4 加入專案供團隊共用（選用） 3.5 多平台安裝支援 3.6 OpenClaw 整合 3.7 語音輸入支援 3.8 設定 CLAUDE.md 3.9 常見安裝錯誤排除 Sprint 工作流程與技能體系 4.1 Sprint 核心哲學 4.2 技能串聯關係 4.3 完整技能目錄（30+ 個） 4.4 Builder Ethos（建構者信條） 虛擬開發團隊設計（企業實戰） 5.1 團隊架構總覽 5.2 ／office-hours（YC 辦公室時光） 5.3 ／plan-ceo-review（CEO 視角） 5.4 ／plan-eng-review（工程主管視角） 5.5 ／plan-design-review（設計師視角） 5.6 ／review（資深工程師審查） 5.7 ／qa（QA 主管） 5.8 ／cso（首席資安官） 5.9 ／ship（發布工程師） 5.10 ／investigate（系統偵錯） 端到端開發流程 6.1 完整開發流程圖 6.2 各步驟執行指令 6.3 分支策略與 PR 規範 實戰案例：會員管理系統 7.1 系統設計概覽 7.2 API 設計 7.3 DB Schema 7.4 Clean Architecture 後端實作 7.5 前端（Vue 3） 7.6 gstack 技能參與對照表 DevOps 與自動化 8.1 CI/CD 架構圖 8.2 GitHub Actions CI 設定 8.3 Dockerfile（多階段建置） 8.4 ／land-and-deploy 一鍵部署 8.5 ／canary 金絲雀監控 8.6 ／benchmark 效能基準 並行 Sprint 與瀏覽器模式 9.1 並行 Sprint 架構 9.2 Conductor 整合 9.3 瀏覽器模式（／browse） 9.4 真實 Chrome 模式（$B connect） 9.5 CSS Inspector 與 Live Style 編輯 9.6 瀏覽器交接（Browser Handoff） 9.7 持續檢查點模式（Continuous Checkpoint） 9.8 Domain Skills 與 CDP Escape Hatch 系統維運 10.1 日誌策略（Log4j2 + ELK） 10.2 監控儀表板（Prometheus + Grafana） 10.3 AI 協助 Debug（gstack Investigate Mode） 10.4 錯誤追蹤（Sentry 整合） 系統升級與擴展 11.1 gstack 升級策略 11.2 多平台自動升級 11.3 自訂 SKILL.md 擴展 11.4 多專案管理 11.5 Plugin 與 Skill 擴充 11.6 解除安裝 企業級安全設計 12.1 ／cso 安全審查流程 12.2 身份驗證（OAuth2 + JWT） 12.3 RBAC 權限控管 12.4 SAST / DAST 整合 12.5 AI 生成代碼安全風險管控 12.6 瀏覽器模式安全加固 12.7 Layer C 反偵測機制 最佳實務 Best Practices 13.1 企業導入十二大建議 13.2 常見錯誤 13.3 Anti-patterns 對照表 GBrain 持久知識系統 14.1 GBrain 概觀 14.2 安裝路徑 14.3 Per-Repo 信任機制 14.4 記憶同步與安全 14.5 Conductor 環境變數 隱私與遙測 15.1 遙測機制 15.2 資料收集範圍 15.3 本地分析報告 附錄：快速上手 Checklist 1. gstack 概述 1.1 什麼是 gstack gstack 是由 Y Combinator President \u0026amp; CEO Garry Tan 開源的 AI 編碼代理虛擬工程團隊技能套件，開源於 github.com/garrytan/gstack，目前已累積超過 118,000 顆星、17,600+ Forks，是目前最受矚目的 AI 輔助開發工具之一。\n","title":"Gstack教學手冊"},{"content":"PPT Master 教學手冊 企業 AI 簡報平台建置手冊 — 從 Prompt 到原生可編輯 PowerPoint 的完整實戰指南\n基於 PPT Master v2.11.0 ｜ 最後更新：2026-06-30 ｜ GitHub Stars: 34.4k+\n📋 目錄 (Table of Contents) 第一部分：基礎概念與架構 PPT Master 介紹 PPT Master 系統架構 核心技術解析 SVG → DrawingML 原理 PPT Master 工作流程 第二部分：AI Agent 與安裝設定 AI Agent Skill 安裝教學 系統設定 第三部分：模板與 Prompt 工程 Template 使用 Prompt Engineering 文件來源 Speaker Notes 第四部分：AI 模型與 IDE 整合 AI 模型支援 與 Claude Code 整合 與 GitHub Copilot 整合 與 Cursor 整合 與 MCP 整合 第五部分：進階應用 與企業知識庫整合 實戰案例 Mermaid 圖集 常用 Prompt 範例 第六部分：最佳實務與效能 最佳實務 效能最佳化 第七部分：維運管理 系統維護 系統升級 第八部分：FAQ、疑難排解與參考 常見問題 FAQ Troubleshooting 與其他工具比較 第九部分：企業導入與未來發展 企業導入建議 適用 SSDLC 未來發展 附錄 檢查清單 (Checklist) 📖 文件說明 🎯 文件目標 本手冊將 PPT Master 定位為企業 AI 簡報生成平台，涵蓋以下核心能力：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ppt-master-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"PPT Master 教學手冊 企業 AI 簡報平台建置手冊 — 從 Prompt 到原生可編輯 PowerPoint 的完整實戰指南\n基於 PPT Master v2.11.0 ｜ 最後更新：2026-06-30 ｜ GitHub Stars: 34.4k+\n📋 目錄 (Table of Contents) 第一部分：基礎概念與架構 PPT Master 介紹 PPT Master 系統架構 核心技術解析 SVG → DrawingML 原理 PPT Master 工作流程 第二部分：AI Agent 與安裝設定 AI Agent Skill 安裝教學 系統設定 第三部分：模板與 Prompt 工程 Template 使用 Prompt Engineering 文件來源 Speaker Notes 第四部分：AI 模型與 IDE 整合 AI 模型支援 與 Claude Code 整合 與 GitHub Copilot 整合 與 Cursor 整合 與 MCP 整合 第五部分：進階應用 與企業知識庫整合 實戰案例 Mermaid 圖集 常用 Prompt 範例 第六部分：最佳實務與效能 最佳實務 效能最佳化 第七部分：維運管理 系統維護 系統升級 第八部分：FAQ、疑難排解與參考 常見問題 FAQ Troubleshooting 與其他工具比較 第九部分：企業導入與未來發展 企業導入建議 適用 SSDLC 未來發展 附錄 檢查清單 (Checklist) 📖 文件說明 🎯 文件目標 本手冊將 PPT Master 定位為企業 AI 簡報生成平台，涵蓋以下核心能力：\n","title":"PPT Master 教學手冊"},{"content":"AI 如何減少 Token 使用教學手冊 版本：2.0.0\n日期：2026-06-30 適用範圍：Claude Code / GitHub Copilot / Codex CLI / Gemini CLI / Cursor / Kiro / Windsurf / Cline\n目標讀者：資深工程師、架構師、Tech Lead、AI 成本治理人員\n授權：內部教學使用\n前言 在 AI 輔助開發已成為企業標準工作流程的今天，Token 消耗 已從技術細節躍升為影響專案預算、開發速度與 AI 品質的關鍵因素。根據企業實務統計，一個 20 人的開發團隊每月 AI Token 費用可達數千至數萬美元，其中 60%～80% 屬於可避免的浪費。\n本手冊的核心論點：\n「最有效降低 Token 的方法不是更換模型，而是建立 Knowledge Graph + Memory + Agent Team + SSDLC Workflow。」\n本手冊整合了 RTK（Rust Token Killer）、Headroom（Context 壓縮層）、Understand-Anything（Knowledge Graph Builder）、GitNexus（Repository Intelligence）、Graphify（Code Knowledge Graph）、codebase-memory-mcp（Hybrid LSP Memory）、CodeGraph（Auto-Sync Graph）、Ponytail（YAGNI Agent Plugin）等 8 大工具的設計理念，結合 SSDLC Agent Team 協作模式與企業實戰經驗，系統性地提供從個人開發到企業治理的完整 Token 節省策略。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ai%E5%A6%82%E4%BD%95%E6%B8%9B%E5%B0%91token%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"AI 如何減少 Token 使用教學手冊 版本：2.0.0\n日期：2026-06-30 適用範圍：Claude Code / GitHub Copilot / Codex CLI / Gemini CLI / Cursor / Kiro / Windsurf / Cline\n目標讀者：資深工程師、架構師、Tech Lead、AI 成本治理人員\n授權：內部教學使用\n前言 在 AI 輔助開發已成為企業標準工作流程的今天，Token 消耗 已從技術細節躍升為影響專案預算、開發速度與 AI 品質的關鍵因素。根據企業實務統計，一個 20 人的開發團隊每月 AI Token 費用可達數千至數萬美元，其中 60%～80% 屬於可避免的浪費。\n本手冊的核心論點：\n「最有效降低 Token 的方法不是更換模型，而是建立 Knowledge Graph + Memory + Agent Team + SSDLC Workflow。」\n本手冊整合了 RTK（Rust Token Killer）、Headroom（Context 壓縮層）、Understand-Anything（Knowledge Graph Builder）、GitNexus（Repository Intelligence）、Graphify（Code Knowledge Graph）、codebase-memory-mcp（Hybrid LSP Memory）、CodeGraph（Auto-Sync Graph）、Ponytail（YAGNI Agent Plugin）等 8 大工具的設計理念，結合 SSDLC Agent Team 協作模式與企業實戰經驗，系統性地提供從個人開發到企業治理的完整 Token 節省策略。\n","title":"AI如何減少token使用教學手冊"},{"content":"Everything Claude Code (ECC) 教學手冊 版本：v2.0.0（2026 年 6 月）\n適用對象：軟體工程師（初階～資深）、架構師、DevOps / SRE、AI 工程師\n授權：MIT License\n官方 GitHub：https://github.com/affaan-m/ECC\n官方網站：https://ecc.tools\nGitHub Marketplace：https://github.com/marketplace/ecc-tools\nDiscord 社群：https://discord.gg/36yGMHGFbR\n社群統計：224K+ Stars ∣ 34.3K+ Forks ∣ 289+ Contributors ∣ 12+ 語言生態系\n官方指南：\n— Shorthand Guide（入門首選）\n— Longform Guide（進階深入）\n— Security Guide（安全防護）\n📑 目錄 第一章：Everything Claude Code 架構總覽 1.1 ECC 是什麼 1.2 與傳統 Prompt Engineering 差異 1.3 Context Engineering 與 Harness Engineering 1.4 ECC 整體架構圖 1.5 Agent / Skills / Hooks / Commands 關係圖 1.6 版本演進歷程 第二章：ECC 核心組件解析 2.1 Agents（代理） 2.2 Skills（技能） 2.3 Commands \u0026amp; Hooks 2.4 Rules（規則） 2.5 記憶與上下文管理 2.6 Contexts（動態上下文注入） 2.7 MCP Server 配置 第三章：安裝與環境建置 3.1 前置需求 3.2 Plugin 安裝（推薦） 3.3 手動安裝 3.4 Windows PowerShell 安裝 3.5 跨 Harness 整合（Cursor / Codex / Copilot / Zed / OpenCode） 3.6 環境變數設定 3.7 Dashboard GUI 3.8 套件管理器偵測 3.9 故障復原與診斷 第四章：企業級 Web 系統架構設計（搭配 ECC） 4.1 企業系統架構背景 4.2 ECC Agent 分工架構 4.3 Orchestrator 家族（v2.0.0） 4.4 系統架構圖 4.5 Agent 協作流程 第五章：開發流程（AI 驅動） 5.1 AI 驅動開發總覽 5.2 /plan — 需求規劃 5.3 /design — 架構設計 5.4 /implement（TDD）— 實作 5.5 /test — 測試 5.6 /code-review — 程式碼審查 5.7 /deploy — 部署 5.8 /verify — 驗證迴圈 第六章：測試與品質控管 6.1 TDD Skill 實作 6.2 自動 Code Review 6.3 Plankton 程式碼品質 6.4 AgentShield 安全掃描 6.5 CI/CD 整合測試流程 6.6 驗證迴圈與評估框架 第七章：安全（SSDLC） 7.1 ECC 安全架構 7.2 安全檢查自動化 7.3 OWASP Top 10 防護 7.4 Secret Detection 7.5 GateGuard 安全閘門 第八章：部署與維運（DevOps） 8.1 CI/CD 整合 8.2 監控與日誌 8.3 AI Agent 監控 第九章：系統維護與升級 9.1 ECC 版本升級策略 9.2 Skills / Agents 管理 9.3 相容性與故障排除 第十章：最佳實踐（Best Practices） 10.1 避免上下文污染 10.2 Agent 設計原則 10.3 Skill 設計模式 10.4 Token 最佳化 10.5 平行化策略 第十一章：常見問題與排錯 第十二章：進階應用 12.1 多 Agent 協作（Multi-Agent System） 12.2 與其他 AI 工具整合 12.3 自訂 Agent 12.4 ECC 2.0 Control-Pane Substrate 12.5 NanoClaw v2 12.6 GAN 風格產生器-評估器框架 12.7 Operator Status Snapshots 12.8 Cross-Harness Architecture 附錄 A. 常用指令 Cheat Sheet B. Skills 範例模板 C. Agent 設計模板 D. 跨工具功能對照表 E. 檢查清單（Checklist） F. 生態系工具與社群資源 G. 版本變更摘要 第一章：Everything Claude Code 架構總覽 1.1 ECC 是什麼 Everything Claude Code（ECC）是一個開源的 Agent Harness Operating System（代理控制操作系統），由 Anthropic 黑客松冠軍 Affaan Mustafa 建立。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/everything-claude-code-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Everything Claude Code (ECC) 教學手冊 版本：v2.0.0（2026 年 6 月）\n適用對象：軟體工程師（初階～資深）、架構師、DevOps / SRE、AI 工程師\n授權：MIT License\n官方 GitHub：https://github.com/affaan-m/ECC\n官方網站：https://ecc.tools\nGitHub Marketplace：https://github.com/marketplace/ecc-tools\nDiscord 社群：https://discord.gg/36yGMHGFbR\n社群統計：224K+ Stars ∣ 34.3K+ Forks ∣ 289+ Contributors ∣ 12+ 語言生態系\n官方指南：\n— Shorthand Guide（入門首選）\n— Longform Guide（進階深入）\n— Security Guide（安全防護）\n📑 目錄 第一章：Everything Claude Code 架構總覽 1.1 ECC 是什麼 1.2 與傳統 Prompt Engineering 差異 1.3 Context Engineering 與 Harness Engineering 1.4 ECC 整體架構圖 1.5 Agent / Skills / Hooks / Commands 關係圖 1.6 版本演進歷程 第二章：ECC 核心組件解析 2.1 Agents（代理） 2.2 Skills（技能） 2.3 Commands \u0026amp; Hooks 2.4 Rules（規則） 2.5 記憶與上下文管理 2.6 Contexts（動態上下文注入） 2.7 MCP Server 配置 第三章：安裝與環境建置 3.1 前置需求 3.2 Plugin 安裝（推薦） 3.3 手動安裝 3.4 Windows PowerShell 安裝 3.5 跨 Harness 整合（Cursor / Codex / Copilot / Zed / OpenCode） 3.6 環境變數設定 3.7 Dashboard GUI 3.8 套件管理器偵測 3.9 故障復原與診斷 第四章：企業級 Web 系統架構設計（搭配 ECC） 4.1 企業系統架構背景 4.2 ECC Agent 分工架構 4.3 Orchestrator 家族（v2.0.0） 4.4 系統架構圖 4.5 Agent 協作流程 第五章：開發流程（AI 驅動） 5.1 AI 驅動開發總覽 5.2 /plan — 需求規劃 5.3 /design — 架構設計 5.4 /implement（TDD）— 實作 5.5 /test — 測試 5.6 /code-review — 程式碼審查 5.7 /deploy — 部署 5.8 /verify — 驗證迴圈 第六章：測試與品質控管 6.1 TDD Skill 實作 6.2 自動 Code Review 6.3 Plankton 程式碼品質 6.4 AgentShield 安全掃描 6.5 CI/CD 整合測試流程 6.6 驗證迴圈與評估框架 第七章：安全（SSDLC） 7.1 ECC 安全架構 7.2 安全檢查自動化 7.3 OWASP Top 10 防護 7.4 Secret Detection 7.5 GateGuard 安全閘門 第八章：部署與維運（DevOps） 8.1 CI/CD 整合 8.2 監控與日誌 8.3 AI Agent 監控 第九章：系統維護與升級 9.1 ECC 版本升級策略 9.2 Skills / Agents 管理 9.3 相容性與故障排除 第十章：最佳實踐（Best Practices） 10.1 避免上下文污染 10.2 Agent 設計原則 10.3 Skill 設計模式 10.4 Token 最佳化 10.5 平行化策略 第十一章：常見問題與排錯 第十二章：進階應用 12.1 多 Agent 協作（Multi-Agent System） 12.2 與其他 AI 工具整合 12.3 自訂 Agent 12.4 ECC 2.0 Control-Pane Substrate 12.5 NanoClaw v2 12.6 GAN 風格產生器-評估器框架 12.7 Operator Status Snapshots 12.8 Cross-Harness Architecture 附錄 A. 常用指令 Cheat Sheet B. Skills 範例模板 C. Agent 設計模板 D. 跨工具功能對照表 E. 檢查清單（Checklist） F. 生態系工具與社群資源 G. 版本變更摘要 第一章：Everything Claude Code 架構總覽 1.1 ECC 是什麼 Everything Claude Code（ECC）是一個開源的 Agent Harness Operating System（代理控制操作系統），由 Anthropic 黑客松冠軍 Affaan Mustafa 建立。\n","title":"Everything Claude Code 教學手冊"},{"content":"GSD Core（Get-Shit-Done）企業級教學手冊 版本：4.0\nGSD Core 版本：v1.6.0（2026-06-23 — 新 repo）／v1.42.3（2026-05-18 — 舊 repo 最終版）\n適用對象：資深工程師、技術主管、架構師\n最後更新：2026-06-30\n定位：實戰與維運導向的內部開發規範文件\n官方資源：GitHub（GSD Core） ｜ 舊 GitHub（已歸檔） ｜ 官方網站 ｜ 文件站 ｜ Discord\n重要通知：GSD 專案已於 2026 年 5 月遷移至 open-gsd/gsd-core，舊 repo gsd-build/get-shit-done 已於 2026-06-26 正式歸檔（Archive），設為唯讀狀態。npm 套件名稱統一為 @opengsd/gsd-core。所有新的開發、Issues 與 Releases 均在新 repo 進行。\n目錄 第一章：GSD 概述 1.1 GSD 是什麼 1.2 支援的 AI Runtime 1.3 與傳統開發的差異 1.4 與 Agile / DevOps / AI Coding 的關係 1.5 GSD 版本演進 第二章：核心概念 2.1 Meta Prompting 2.2 Context Engineering 2.3 Spec-Driven Development 2.4 Multi-Agent Orchestration 2.5 Context Rot 問題與解法 2.6 XML Prompt Formatting 2.7 Atomic Git Commits 2.8 Capability System（v1.4.0+） 2.9 Edge \u0026amp; Prohibition Coverage（v1.3.0+） 2.10 Decision Coverage Gates（v1.4.0+） 2.11 MemPalace 記憶整合（v1.4.0+） 第三章：系統架構設計（企業級） 3.1 GSD + AI Agent 架構圖 3.2 與 Web Application（前後端）整合方式 3.3 微服務 / Clean Architecture / Hexagonal Architecture 3.4 與資料庫整合 3.5 與 MQ / Cache / API Gateway 整合 第四章：安裝與環境建置 4.1 GSD 安裝步驟 4.2 Claude Code 設定 4.3 Gemini CLI 設定 4.4 Kimi CLI 設定（v1.4.0+） 4.5 其他 Runtime 設定 4.6 VS Code 開發環境配置 4.7 Windows / Linux 環境差異 第五章：GSD 開發流程（核心） 5.0 流程總覽 5.1 /gsd-new-project 5.2 /gsd-discuss-phase 5.3 /gsd-spec-phase — Socratic 規格釐清（v1.3.0+） 5.4 /gsd-plan-phase 5.5 /gsd-execute-phase 5.6 /gsd-verify-work 5.7 /gsd-ship 5.8 /gsd-quick — 快速任務模式 5.9 /gsd-fast — 即時內嵌任務 5.10 /gsd-progress — 狀態與流程推進 5.11 /gsd-autonomous — 全自動推進 5.12 里程碑管理 5.13 Workstreams — 並行工作流 5.14 /gsd-capture — 統一捕獲命令 5.15 Session 管理 5.16 /gsd-workspace — 工作區管理 5.17 /gsd-phase — ROADMAP 管理（v1.3.0+） 5.18 /gsd-mvp-phase — MVP 導向規劃（v1.3.0+） 5.19 /gsd-plan-review-convergence — 跨 AI 計畫收斂（v1.3.0+） 5.20 /gsd-manager — 多 Phase 指揮中心（v1.3.0+） 5.21 /gsd-surface — Skill 叢集切換（v1.2.0+） 第六章：實戰案例（Web Application） 6.1 案例背景 6.2 Phase 1：需求 → Spec 6.3 Phase 2：Spec → Plan 6.4 Phase 3：Plan → Code 6.5 Phase 4：Code → 驗證 第七章：AI 協作最佳實踐 7.1 如何避免 AI 幻覺 7.2 如何控制上下文 7.3 Prompt 設計技巧 7.4 多 Agent 協作模式 第八章：系統維運與監控 8.1 Logging 最佳實踐 8.2 Monitoring 架構 8.3 錯誤追蹤 8.4 效能調校 8.5 成本控制（AI Token） 第九章：系統升級與擴展 9.1 GSD 升級策略 9.2 Prompt Versioning 9.3 Spec Versioning 9.4 與 CI/CD 整合 第十章：安全強化機制 10.1 GSD 內建安全防護 10.2 Package Legitimacy Gate 10.3 敏感檔案保護 10.4 企業安全合規整合 10.5 Prompt Injection Guard（v1.4.0+） 10.6 Read-Injection Scanner（v1.4.0+） 10.7 OWASP ASVS Level 整合（v1.5.0+） 第十一章：企業導入策略 11.1 團隊導入流程 11.2 開發規範制定 11.3 Governance（治理） 11.4 安全與權限控管 第十二章：GSD 完整命令參考 12.1 核心工作流命令 12.2 推進與導航命令 12.3 快速執行命令 12.4 品質與安全命令 12.5 專案分析命令 12.6 捕獲與構思命令 12.7 上下文管理命令 12.8 系統管理命令 12.9 版本控制命令 12.10 工作區與里程碑命令 12.11 進階規劃命令 12.12 使用者與審計命令 12.13 Namespace Meta-Skills（路由器） 12.14 Capability 管理命令（v1.4.0+） 12.15 模型與路由命令（v1.5.0+） 12.16 狀態與漂移檢測命令（v1.5.0-v1.6.0） 12.17 CLI 工具命令 第十三章：GSD 設定參考 13.1 config.json 完整 Schema 13.2 Model Profiles 13.3 Workflow Toggles 13.4 Git Branching 策略 13.5 Hook 設定 13.6 Install Profiles 13.7 Model Policy Presets（v1.5.0+） 13.8 Dynamic Routing 設定（v1.5.0+） 13.9 Effort Control（v1.5.0+） 13.10 State Rebuild 合約（v1.5.0+） 13.11 Observability 審計追蹤（v1.5.0+） 第十四章：常見問題（FAQ） 14.1 常見錯誤 14.2 Debug 方法 14.3 Anti-Patterns 第十五章：.planning/ 目錄結構參考 15.1 完整目錄樹狀圖 15.2 核心檔案說明 15.3 Context 目錄 15.4 Specs 與 Plans 目錄 15.5 Checkpoints 與 Reports 目錄 15.6 .gitignore 建議 附錄：檢查清單（Checklist） 第一章：GSD 概述 1.1 GSD 是什麼 GSD（Get-Shit-Done）是一套輕量級 Meta-Prompting 系統，適用於 Claude Code 及其他主流 AI Coding Runtime，透過結構化的 Slash Commands 驅動 AI Agent 完成高品質的軟體交付。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/get-shit-donegsd%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GSD Core（Get-Shit-Done）企業級教學手冊 版本：4.0\nGSD Core 版本：v1.6.0（2026-06-23 — 新 repo）／v1.42.3（2026-05-18 — 舊 repo 最終版）\n適用對象：資深工程師、技術主管、架構師\n最後更新：2026-06-30\n定位：實戰與維運導向的內部開發規範文件\n官方資源：GitHub（GSD Core） ｜ 舊 GitHub（已歸檔） ｜ 官方網站 ｜ 文件站 ｜ Discord\n重要通知：GSD 專案已於 2026 年 5 月遷移至 open-gsd/gsd-core，舊 repo gsd-build/get-shit-done 已於 2026-06-26 正式歸檔（Archive），設為唯讀狀態。npm 套件名稱統一為 @opengsd/gsd-core。所有新的開發、Issues 與 Releases 均在新 repo 進行。\n目錄 第一章：GSD 概述 1.1 GSD 是什麼 1.2 支援的 AI Runtime 1.3 與傳統開發的差異 1.4 與 Agile / DevOps / AI Coding 的關係 1.5 GSD 版本演進 第二章：核心概念 2.1 Meta Prompting 2.2 Context Engineering 2.3 Spec-Driven Development 2.4 Multi-Agent Orchestration 2.5 Context Rot 問題與解法 2.6 XML Prompt Formatting 2.7 Atomic Git Commits 2.8 Capability System（v1.4.0+） 2.9 Edge \u0026amp; Prohibition Coverage（v1.3.0+） 2.10 Decision Coverage Gates（v1.4.0+） 2.11 MemPalace 記憶整合（v1.4.0+） 第三章：系統架構設計（企業級） 3.1 GSD + AI Agent 架構圖 3.2 與 Web Application（前後端）整合方式 3.3 微服務 / Clean Architecture / Hexagonal Architecture 3.4 與資料庫整合 3.5 與 MQ / Cache / API Gateway 整合 第四章：安裝與環境建置 4.1 GSD 安裝步驟 4.2 Claude Code 設定 4.3 Gemini CLI 設定 4.4 Kimi CLI 設定（v1.4.0+） 4.5 其他 Runtime 設定 4.6 VS Code 開發環境配置 4.7 Windows / Linux 環境差異 第五章：GSD 開發流程（核心） 5.0 流程總覽 5.1 /gsd-new-project 5.2 /gsd-discuss-phase 5.3 /gsd-spec-phase — Socratic 規格釐清（v1.3.0+） 5.4 /gsd-plan-phase 5.5 /gsd-execute-phase 5.6 /gsd-verify-work 5.7 /gsd-ship 5.8 /gsd-quick — 快速任務模式 5.9 /gsd-fast — 即時內嵌任務 5.10 /gsd-progress — 狀態與流程推進 5.11 /gsd-autonomous — 全自動推進 5.12 里程碑管理 5.13 Workstreams — 並行工作流 5.14 /gsd-capture — 統一捕獲命令 5.15 Session 管理 5.16 /gsd-workspace — 工作區管理 5.17 /gsd-phase — ROADMAP 管理（v1.3.0+） 5.18 /gsd-mvp-phase — MVP 導向規劃（v1.3.0+） 5.19 /gsd-plan-review-convergence — 跨 AI 計畫收斂（v1.3.0+） 5.20 /gsd-manager — 多 Phase 指揮中心（v1.3.0+） 5.21 /gsd-surface — Skill 叢集切換（v1.2.0+） 第六章：實戰案例（Web Application） 6.1 案例背景 6.2 Phase 1：需求 → Spec 6.3 Phase 2：Spec → Plan 6.4 Phase 3：Plan → Code 6.5 Phase 4：Code → 驗證 第七章：AI 協作最佳實踐 7.1 如何避免 AI 幻覺 7.2 如何控制上下文 7.3 Prompt 設計技巧 7.4 多 Agent 協作模式 第八章：系統維運與監控 8.1 Logging 最佳實踐 8.2 Monitoring 架構 8.3 錯誤追蹤 8.4 效能調校 8.5 成本控制（AI Token） 第九章：系統升級與擴展 9.1 GSD 升級策略 9.2 Prompt Versioning 9.3 Spec Versioning 9.4 與 CI/CD 整合 第十章：安全強化機制 10.1 GSD 內建安全防護 10.2 Package Legitimacy Gate 10.3 敏感檔案保護 10.4 企業安全合規整合 10.5 Prompt Injection Guard（v1.4.0+） 10.6 Read-Injection Scanner（v1.4.0+） 10.7 OWASP ASVS Level 整合（v1.5.0+） 第十一章：企業導入策略 11.1 團隊導入流程 11.2 開發規範制定 11.3 Governance（治理） 11.4 安全與權限控管 第十二章：GSD 完整命令參考 12.1 核心工作流命令 12.2 推進與導航命令 12.3 快速執行命令 12.4 品質與安全命令 12.5 專案分析命令 12.6 捕獲與構思命令 12.7 上下文管理命令 12.8 系統管理命令 12.9 版本控制命令 12.10 工作區與里程碑命令 12.11 進階規劃命令 12.12 使用者與審計命令 12.13 Namespace Meta-Skills（路由器） 12.14 Capability 管理命令（v1.4.0+） 12.15 模型與路由命令（v1.5.0+） 12.16 狀態與漂移檢測命令（v1.5.0-v1.6.0） 12.17 CLI 工具命令 第十三章：GSD 設定參考 13.1 config.json 完整 Schema 13.2 Model Profiles 13.3 Workflow Toggles 13.4 Git Branching 策略 13.5 Hook 設定 13.6 Install Profiles 13.7 Model Policy Presets（v1.5.0+） 13.8 Dynamic Routing 設定（v1.5.0+） 13.9 Effort Control（v1.5.0+） 13.10 State Rebuild 合約（v1.5.0+） 13.11 Observability 審計追蹤（v1.5.0+） 第十四章：常見問題（FAQ） 14.1 常見錯誤 14.2 Debug 方法 14.3 Anti-Patterns 第十五章：.planning/ 目錄結構參考 15.1 完整目錄樹狀圖 15.2 核心檔案說明 15.3 Context 目錄 15.4 Specs 與 Plans 目錄 15.5 Checkpoints 與 Reports 目錄 15.6 .gitignore 建議 附錄：檢查清單（Checklist） 第一章：GSD 概述 1.1 GSD 是什麼 GSD（Get-Shit-Done）是一套輕量級 Meta-Prompting 系統，適用於 Claude Code 及其他主流 AI Coding Runtime，透過結構化的 Slash Commands 驅動 AI Agent 完成高品質的軟體交付。\n","title":"Get Shit Done(GSD)教學手冊"},{"content":"GitHub CLI 教學手冊 版本：基於 GitHub CLI v2.74.0（2026-05 最新穩定版）／GitHub Copilot CLI v1.0.65（2026-06-24 最新穩定版）\n適用對象：資深工程師 / DevOps 工程師 / 架構師 / SRE / AI 團隊\n技術環境：企業級 Web Application（Spring Boot / Vue / 微服務架構）\n最後更新：2026-06-30\n目錄 第 1 章：GitHub CLI 概述 1.1 GitHub CLI 是什麼 1.2 為何企業要導入 GitHub CLI 1.3 GitHub CLI 架構 1.4 GitHub CLI 與 Git 的差異 1.5 GitHub CLI 與 GitHub API 的關係 1.6 GitHub CLI 使用情境 1.7 GitHub CLI 優缺點 第 2 章：GitHub CLI 安裝與環境建置 2.1 Windows 安裝 2.2 macOS 安裝 2.3 Linux 安裝 2.4 WSL 安裝 2.5 驗證安裝 2.6 Proxy 設定 2.7 公司內網設定 2.8 SSH Key 建立 2.9 GPG Key 建立 2.10 Git 設定 2.11 GitHub Login 2.12 Token 管理 2.13 PAT 管理 第 3 章：GitHub Authentication 與安全管理 3.1 gh auth login 3.2 gh auth status 3.3 gh auth refresh 3.4 gh auth logout 3.5 SSH Authentication 3.6 HTTPS Authentication 3.7 PAT Token 3.8 Fine-grained Token 3.9 SSO 3.10 Enterprise Authentication 3.11 最佳安全實務 3.12 Token Rotation 3.13 Secret 管理 3.14 Least Privilege 原則 第 4 章：GitHub Repo 管理 4.1 建立 Repo 4.2 Clone Repo 4.3 Fork Repo 4.4 Rename Repo 4.5 Delete Repo 4.6 Archive Repo 4.7 Template Repo 4.8 Monorepo 4.9 Polyrepo 4.10 Repo 命名規範 4.11 Repo Governance 4.12 Repo 權限管理 4.13 Team 管理 第 5 章：Source Code 上架與管理 5.1 Git 初始化 5.2 Push Source Code 5.3 Branch 管理 5.4 Git Flow 5.5 Trunk Based Development 5.6 Feature Branch 5.7 Release Branch 5.8 Hotfix Branch 5.9 Commit Convention 5.10 Pull Request Flow 5.11 Code Review Flow 第 6 章：文件管理策略 6.1 Markdown 文件管理 6.2 docs 結構 6.3 ADR 管理 6.4 Architecture 文件 6.5 API 文件 6.6 README 標準化 6.7 Wiki 管理 6.8 GitHub Pages 第 7 章：GitHub CLI 常用指令大全 7.1 gh repo 7.2 gh pr 7.3 gh issue 7.4 gh release 7.5 gh workflow 7.6 gh run 7.7 gh api 7.8 gh alias 7.9 gh extension 7.10 gh browse 7.11 gh codespace 7.12 gh gist 7.13 gh project 7.14 gh search 7.15 gh cache 7.16 gh attestation 7.17 gh ruleset 7.18 gh label 7.19 gh variable 7.20 gh secret 7.21 gh status 7.22 gh config 第 8 章：GitHub Actions 與 Workflow Automation 8.1 GitHub Actions 架構 8.2 Workflow 基礎 8.3 Runner 與 Self-hosted Runner 8.4 Matrix Build 8.5 Cache 與 Artifact 8.6 Secret 與 Environment 8.7 CI Workflow 範例 8.8 CD Workflow 範例 8.9 Release Workflow 範例 8.10 Security Scan Workflow 8.11 AI Workflow 第 9 章：SSDLC 與 Security 9.1 Secret Scanning 9.2 Dependabot 9.3 CodeQL 9.4 Security Policy 9.5 Branch Protection 9.6 CODEOWNERS 9.7 Signed Commit 9.8 Supply Chain Security 與 SBOM 9.9 OWASP 與 DevSecOps 9.10 SAST 與 DAST 第 10 章：GitHub CLI 自動化腳本 10.1 Bash Script 10.2 PowerShell Script 10.3 Windows Batch 10.4 Python Script 10.5 Repo 初始化自動化 10.6 Branch Protection 自動化 10.7 Release Automation 第 11 章：AI 整合與 Copilot CLI 11.1 GitHub Copilot CLI 概述 11.2 Copilot CLI 安裝與設定 11.3 核心操作模式 11.4 Slash Commands 指令大全 11.5 MCP Server 整合 11.6 自訂 Agent、Skills 與 Plugins 11.7 Session 管理與記憶 11.8 Fleet 模式與子代理人 11.9 LSP 整合 11.10 Hooks 系統 11.11 企業級 Copilot CLI 管理 11.12 觀測性與監控 11.13 gh copilot 擴充套件（Legacy） 11.14 Copilot 在 PR Review 中的應用 11.15 AI-Powered Workflow 11.16 Copilot CLI 最佳實務與 AI Agent 整合策略 第 12 章：企業級最佳實務 12.1 Organization 管理 12.2 Repository Governance 12.3 Inner Source 策略 12.4 合規與稽核 12.5 Token 與權限管理 12.6 GitHub Projects 管理 12.7 多帳戶與跨平台管理 第 13 章：維運與監控 13.1 API Rate Limit 監控 13.2 Workflow 執行監控 13.3 Repo 活躍度監控 13.4 Security Alert 監控 13.5 Billing 與用量 13.6 通知管理 第 14 章：實戰案例 14.1 案例一：微服務團隊快速啟動 14.2 案例二：Release 流程自動化 14.3 案例三：Security 合規自動化 14.4 案例四：PR Review 流程優化 14.5 案例五：跨 Repo 標準化 第 15 章：故障排除（Troubleshooting） 15.1 常見錯誤與解決方案 15.2 CLI 升級與相容性 15.3 Debug 模式 15.4 Copilot CLI 常見問題 第 16 章：最佳實務總覽 16.1 日常開發 16.2 團隊協作 16.3 安全 16.4 CI/CD 16.5 自動化 第 17 章：附錄 17.1 Cheat Sheet 17.2 環境變數 17.3 設定檔位置 17.4 常用 jq 語法 17.5 FAQ 檢查清單（Checklist） 第 1 章：GitHub CLI 概述 1.1 GitHub CLI 是什麼 GitHub CLI（指令為 gh）是 GitHub 官方開發的開源命令列工具，以 Go 語言撰寫，讓開發者直接在終端機中與 GitHub 平台互動。它將 Pull Request、Issue、GitHub Actions、Release 等 GitHub 核心功能帶入命令列，消除在瀏覽器與終端機之間頻繁切換的低效工作模式。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-cli-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub CLI 教學手冊 版本：基於 GitHub CLI v2.74.0（2026-05 最新穩定版）／GitHub Copilot CLI v1.0.65（2026-06-24 最新穩定版）\n適用對象：資深工程師 / DevOps 工程師 / 架構師 / SRE / AI 團隊\n技術環境：企業級 Web Application（Spring Boot / Vue / 微服務架構）\n最後更新：2026-06-30\n目錄 第 1 章：GitHub CLI 概述 1.1 GitHub CLI 是什麼 1.2 為何企業要導入 GitHub CLI 1.3 GitHub CLI 架構 1.4 GitHub CLI 與 Git 的差異 1.5 GitHub CLI 與 GitHub API 的關係 1.6 GitHub CLI 使用情境 1.7 GitHub CLI 優缺點 第 2 章：GitHub CLI 安裝與環境建置 2.1 Windows 安裝 2.2 macOS 安裝 2.3 Linux 安裝 2.4 WSL 安裝 2.5 驗證安裝 2.6 Proxy 設定 2.7 公司內網設定 2.8 SSH Key 建立 2.9 GPG Key 建立 2.10 Git 設定 2.11 GitHub Login 2.12 Token 管理 2.13 PAT 管理 第 3 章：GitHub Authentication 與安全管理 3.1 gh auth login 3.2 gh auth status 3.3 gh auth refresh 3.4 gh auth logout 3.5 SSH Authentication 3.6 HTTPS Authentication 3.7 PAT Token 3.8 Fine-grained Token 3.9 SSO 3.10 Enterprise Authentication 3.11 最佳安全實務 3.12 Token Rotation 3.13 Secret 管理 3.14 Least Privilege 原則 第 4 章：GitHub Repo 管理 4.1 建立 Repo 4.2 Clone Repo 4.3 Fork Repo 4.4 Rename Repo 4.5 Delete Repo 4.6 Archive Repo 4.7 Template Repo 4.8 Monorepo 4.9 Polyrepo 4.10 Repo 命名規範 4.11 Repo Governance 4.12 Repo 權限管理 4.13 Team 管理 第 5 章：Source Code 上架與管理 5.1 Git 初始化 5.2 Push Source Code 5.3 Branch 管理 5.4 Git Flow 5.5 Trunk Based Development 5.6 Feature Branch 5.7 Release Branch 5.8 Hotfix Branch 5.9 Commit Convention 5.10 Pull Request Flow 5.11 Code Review Flow 第 6 章：文件管理策略 6.1 Markdown 文件管理 6.2 docs 結構 6.3 ADR 管理 6.4 Architecture 文件 6.5 API 文件 6.6 README 標準化 6.7 Wiki 管理 6.8 GitHub Pages 第 7 章：GitHub CLI 常用指令大全 7.1 gh repo 7.2 gh pr 7.3 gh issue 7.4 gh release 7.5 gh workflow 7.6 gh run 7.7 gh api 7.8 gh alias 7.9 gh extension 7.10 gh browse 7.11 gh codespace 7.12 gh gist 7.13 gh project 7.14 gh search 7.15 gh cache 7.16 gh attestation 7.17 gh ruleset 7.18 gh label 7.19 gh variable 7.20 gh secret 7.21 gh status 7.22 gh config 第 8 章：GitHub Actions 與 Workflow Automation 8.1 GitHub Actions 架構 8.2 Workflow 基礎 8.3 Runner 與 Self-hosted Runner 8.4 Matrix Build 8.5 Cache 與 Artifact 8.6 Secret 與 Environment 8.7 CI Workflow 範例 8.8 CD Workflow 範例 8.9 Release Workflow 範例 8.10 Security Scan Workflow 8.11 AI Workflow 第 9 章：SSDLC 與 Security 9.1 Secret Scanning 9.2 Dependabot 9.3 CodeQL 9.4 Security Policy 9.5 Branch Protection 9.6 CODEOWNERS 9.7 Signed Commit 9.8 Supply Chain Security 與 SBOM 9.9 OWASP 與 DevSecOps 9.10 SAST 與 DAST 第 10 章：GitHub CLI 自動化腳本 10.1 Bash Script 10.2 PowerShell Script 10.3 Windows Batch 10.4 Python Script 10.5 Repo 初始化自動化 10.6 Branch Protection 自動化 10.7 Release Automation 第 11 章：AI 整合與 Copilot CLI 11.1 GitHub Copilot CLI 概述 11.2 Copilot CLI 安裝與設定 11.3 核心操作模式 11.4 Slash Commands 指令大全 11.5 MCP Server 整合 11.6 自訂 Agent、Skills 與 Plugins 11.7 Session 管理與記憶 11.8 Fleet 模式與子代理人 11.9 LSP 整合 11.10 Hooks 系統 11.11 企業級 Copilot CLI 管理 11.12 觀測性與監控 11.13 gh copilot 擴充套件（Legacy） 11.14 Copilot 在 PR Review 中的應用 11.15 AI-Powered Workflow 11.16 Copilot CLI 最佳實務與 AI Agent 整合策略 第 12 章：企業級最佳實務 12.1 Organization 管理 12.2 Repository Governance 12.3 Inner Source 策略 12.4 合規與稽核 12.5 Token 與權限管理 12.6 GitHub Projects 管理 12.7 多帳戶與跨平台管理 第 13 章：維運與監控 13.1 API Rate Limit 監控 13.2 Workflow 執行監控 13.3 Repo 活躍度監控 13.4 Security Alert 監控 13.5 Billing 與用量 13.6 通知管理 第 14 章：實戰案例 14.1 案例一：微服務團隊快速啟動 14.2 案例二：Release 流程自動化 14.3 案例三：Security 合規自動化 14.4 案例四：PR Review 流程優化 14.5 案例五：跨 Repo 標準化 第 15 章：故障排除（Troubleshooting） 15.1 常見錯誤與解決方案 15.2 CLI 升級與相容性 15.3 Debug 模式 15.4 Copilot CLI 常見問題 第 16 章：最佳實務總覽 16.1 日常開發 16.2 團隊協作 16.3 安全 16.4 CI/CD 16.5 自動化 第 17 章：附錄 17.1 Cheat Sheet 17.2 環境變數 17.3 設定檔位置 17.4 常用 jq 語法 17.5 FAQ 檢查清單（Checklist） 第 1 章：GitHub CLI 概述 1.1 GitHub CLI 是什麼 GitHub CLI（指令為 gh）是 GitHub 官方開發的開源命令列工具，以 Go 語言撰寫，讓開發者直接在終端機中與 GitHub 平台互動。它將 Pull Request、Issue、GitHub Actions、Release 等 GitHub 核心功能帶入命令列，消除在瀏覽器與終端機之間頻繁切換的低效工作模式。\n","title":"GitHub CLI 教學手冊"},{"content":"Graphify 教學手冊 版本：v0.9.2（2026-06-30）\n適用對象：資深工程師、架構師、DevOps 團隊\n定位：企業級知識圖譜建置與維運實戰手冊\n授權：MIT License\nY Combinator：S26 批次\n目錄 第 1 章：Graphify 概述 1.1 什麼是 Graphify 1.2 工具定位與比較 1.3 使用情境 1.4 與 AI Agent 的關係 1.5 核心特色摘要 1.6 多後端支援 1.7 Penpax 與生態系統發展 第 2 章：系統架構設計 2.1 整體架構圖 2.2 三階段處理 Pipeline 2.3 Pipeline 模組詳解 2.4 模組職責對照表 2.5 Graph 資料模型 2.6 Confidence Labels（信賴標籤） 2.7 實體去重 Pipeline 2.8 與企業系統整合架構 2.9 技術棧 第 3 章：安裝與環境建置 3.1 環境需求 3.2 安裝步驟（各平台） 3.3 多平台支援 3.4 選用安裝項目（Optional Extras） 3.5 Docker 部署方式（企業推薦） 3.6 安全性設定 3.7 常見安裝問題排除 第 4 章：基本使用教學 4.1 初始化專案 4.2 建立知識圖譜 4.3 指令完整說明 4.4 輸出內容說明 4.5 .graphifyignore 設定 4.6 Always-On 模式設定 4.7 查詢知識圖譜 第 5 章：進階使用（企業必備） 5.1 全域知識圖譜（Global Graph） 5.2 多 Repo 分析 5.3 增量更新與 Watch 模式 5.4 Git Hooks 與合併驅動器 5.5 與 CI/CD 整合 5.6 與 AI 助手整合 5.7 MCP Server 模式 5.8 知識圖譜查詢應用（RAG 強化） 5.9 多格式匯出 5.10 Wiki 生成 5.11 記憶回饋迴圈（Memory Feedback Loop） 5.12 Callflow HTML 匯出 5.13 Docker MCP Toolkit 5.14 PR Dashboard（圖譜感知 PR 管理） 5.15 自訂 LLM Provider Registry 5.16 循環匯入偵測（Import Cycle Detection） 5.17 專案範圍安裝（Project-Scoped Install） 5.18 Azure OpenAI 後端 5.19 Terraform / HCL 支援 5.20 Salesforce Apex 支援 5.21 PostgreSQL Schema 內省 5.22 FalkorDB 圖資料庫整合 5.23 Cargo Workspace 映射 5.24 CUDA / Metal Shader 支援 5.25 WPF / XAML 支援 5.26 Graph Health Gate 5.27 Trigram Query 預過濾 5.28 新增平台支援 第 6 章：實戰案例 6.1 案例一：舊系統逆向工程（Java / Spring） 6.2 案例二：微服務架構知識盤點 6.3 案例三：新人 Onboarding 加速 6.4 案例四：影音知識庫建構 第 7 章：系統升級與版本管理 7.1 升級 Graphify 7.2 Graph Schema 版本控制 7.3 與 Git 版本同步策略 7.4 v0.9.0 破壞性變更遷移指南 第 8 章：安全與隱私設計（SSDLC） 8.1 安全模型總覽 8.2 本地運算優勢 8.3 威脅面與緩解措施 8.4 敏感資料處理 8.5 權限控管（RBAC） 8.6 稽核與追蹤 8.7 漏洞回報流程 8.8 支援版本政策 第 9 章：最佳實務（Best Practices） 9.1 大型專案使用建議 9.2 Token 最佳化策略 9.3 Graph 建模技巧 9.4 團隊導入策略 9.5 環境變數參考 第 10 章：常見問題（FAQ） 附錄 A：檢查清單（Checklist） 附錄 B：指令速查表 附錄 C：版本歷程摘要 附錄 D：官方基準測試結果（Worked Examples） 附錄 E：貢獻指南 第 1 章：Graphify 概述 1.1 什麼是 Graphify Graphify 是由 AI 工程師 Safi Shamsi 開發的開源工具（GitHub 星數 74.4k+、貢獻者 100+、Releases 148+、Y Combinator S26 批次），能將任何資料夾（程式碼、PDF、圖片、影片、音訊、Markdown、Office 文件、Google Workspace、MCP 設定、Terraform/HCL、Salesforce Apex、XAML）自動轉化為可查詢的知識圖譜（Knowledge Graph）。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/graphify%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Graphify 教學手冊 版本：v0.9.2（2026-06-30）\n適用對象：資深工程師、架構師、DevOps 團隊\n定位：企業級知識圖譜建置與維運實戰手冊\n授權：MIT License\nY Combinator：S26 批次\n目錄 第 1 章：Graphify 概述 1.1 什麼是 Graphify 1.2 工具定位與比較 1.3 使用情境 1.4 與 AI Agent 的關係 1.5 核心特色摘要 1.6 多後端支援 1.7 Penpax 與生態系統發展 第 2 章：系統架構設計 2.1 整體架構圖 2.2 三階段處理 Pipeline 2.3 Pipeline 模組詳解 2.4 模組職責對照表 2.5 Graph 資料模型 2.6 Confidence Labels（信賴標籤） 2.7 實體去重 Pipeline 2.8 與企業系統整合架構 2.9 技術棧 第 3 章：安裝與環境建置 3.1 環境需求 3.2 安裝步驟（各平台） 3.3 多平台支援 3.4 選用安裝項目（Optional Extras） 3.5 Docker 部署方式（企業推薦） 3.6 安全性設定 3.7 常見安裝問題排除 第 4 章：基本使用教學 4.1 初始化專案 4.2 建立知識圖譜 4.3 指令完整說明 4.4 輸出內容說明 4.5 .graphifyignore 設定 4.6 Always-On 模式設定 4.7 查詢知識圖譜 第 5 章：進階使用（企業必備） 5.1 全域知識圖譜（Global Graph） 5.2 多 Repo 分析 5.3 增量更新與 Watch 模式 5.4 Git Hooks 與合併驅動器 5.5 與 CI/CD 整合 5.6 與 AI 助手整合 5.7 MCP Server 模式 5.8 知識圖譜查詢應用（RAG 強化） 5.9 多格式匯出 5.10 Wiki 生成 5.11 記憶回饋迴圈（Memory Feedback Loop） 5.12 Callflow HTML 匯出 5.13 Docker MCP Toolkit 5.14 PR Dashboard（圖譜感知 PR 管理） 5.15 自訂 LLM Provider Registry 5.16 循環匯入偵測（Import Cycle Detection） 5.17 專案範圍安裝（Project-Scoped Install） 5.18 Azure OpenAI 後端 5.19 Terraform / HCL 支援 5.20 Salesforce Apex 支援 5.21 PostgreSQL Schema 內省 5.22 FalkorDB 圖資料庫整合 5.23 Cargo Workspace 映射 5.24 CUDA / Metal Shader 支援 5.25 WPF / XAML 支援 5.26 Graph Health Gate 5.27 Trigram Query 預過濾 5.28 新增平台支援 第 6 章：實戰案例 6.1 案例一：舊系統逆向工程（Java / Spring） 6.2 案例二：微服務架構知識盤點 6.3 案例三：新人 Onboarding 加速 6.4 案例四：影音知識庫建構 第 7 章：系統升級與版本管理 7.1 升級 Graphify 7.2 Graph Schema 版本控制 7.3 與 Git 版本同步策略 7.4 v0.9.0 破壞性變更遷移指南 第 8 章：安全與隱私設計（SSDLC） 8.1 安全模型總覽 8.2 本地運算優勢 8.3 威脅面與緩解措施 8.4 敏感資料處理 8.5 權限控管（RBAC） 8.6 稽核與追蹤 8.7 漏洞回報流程 8.8 支援版本政策 第 9 章：最佳實務（Best Practices） 9.1 大型專案使用建議 9.2 Token 最佳化策略 9.3 Graph 建模技巧 9.4 團隊導入策略 9.5 環境變數參考 第 10 章：常見問題（FAQ） 附錄 A：檢查清單（Checklist） 附錄 B：指令速查表 附錄 C：版本歷程摘要 附錄 D：官方基準測試結果（Worked Examples） 附錄 E：貢獻指南 第 1 章：Graphify 概述 1.1 什麼是 Graphify Graphify 是由 AI 工程師 Safi Shamsi 開發的開源工具（GitHub 星數 74.4k+、貢獻者 100+、Releases 148+、Y Combinator S26 批次），能將任何資料夾（程式碼、PDF、圖片、影片、音訊、Markdown、Office 文件、Google Workspace、MCP 設定、Terraform/HCL、Salesforce Apex、XAML）自動轉化為可查詢的知識圖譜（Knowledge Graph）。\n","title":"Graphify教學手冊"},{"content":"Hermes Agent 生態系教學手冊（Enterprise Edition） 版本：v0.17.0（v2026.6.19 — 涵蓋 The Foundation Release + The Velocity Release + The Surface Release + The Reach Release）\n適用對象：資深工程師 / 架構師 / DevOps 團隊\n授權：MIT License\n官方網站：hermes-agent.nousresearch.com\nGitHub：github.com/NousResearch/hermes-agent\n官方文件：hermes-agent.nousresearch.com/docs\nDesktop 下載：hermes-agent.nousresearch.com（macOS / Windows / Linux）\nSkills Hub：agentskills.io\nLLM 友善文件：llms.txt / llms-full.txt\n最後更新：2026 年 6 月 30 日\n📑 目錄 第一章：Hermes Agent 概述 1.1 技術背景與發展 1.2 與傳統 AI 的差異 1.3 Agent vs Workflow vs RPA 比較 1.4 核心設計理念 1.4.1 Learning Loop（學習迴圈） 1.4.2 Skill System（技能系統） 1.4.3 Persistent Memory（持久記憶） 1.4.4 Model Agnostic（模型無關） 1.4.5 Voice Mode（語音模式） 1.4.6 Web Dashboard（v0.9.0+） 1.4.7 Transport 架構（v0.11.0+） 1.4.8 Autonomous Curator（v0.12.0+） 1.4.9 Multi-agent Kanban（v0.13.0+） 1.4.10 Persistent Goals（v0.13.0+） 1.4.11 Post-write Delta Lint（v0.13.0+） 1.4.12 i18n 多語言支援（v0.13.0+） 1.4.13 hermes proxy — OpenAI 相容本地代理（v0.14.0+） 1.4.14 PyPI 套件安裝（v0.14.0+） 1.4.15 /handoff 即時 Session 轉移（v0.14.0+） 1.4.16 Promptware 防禦（v0.15.0+） 1.4.17 Bitwarden Secrets Manager（v0.15.0+） 1.4.18 Skill Bundles（v0.15.0+） 1.4.19 Hermes Desktop App（v0.16.0+） 1.4.20 Background Subagents（v0.17.0+） 1.4.21 Image Editing（v0.17.0+） 1.4.22 Automation Blueprints（v0.17.0+） 1.4.23 Memory Atomic Batch Operations（v0.17.0+） 第二章：整體系統架構 2.1 架構設計概述 2.2 分層架構圖 2.3 各層級說明 2.4 多 Agent 協作架構 2.5 高可用與擴展性設計 第三章：Hermes Agent 核心機制解析 3.1 Learning Loop（學習迴圈） 3.2 Skill System（技能系統） 3.3 Memory System（記憶系統） 3.4 Planning / Execution Flow 3.5 Tool Calling 機制 3.6 Model Routing（多模型切換） 3.7 Autonomous Curator（自動技能維護） 3.8 Persistent Goals 與 Ralph Loop 3.9 Post-write Delta Lint（自動語法檢查） 3.10 Checkpoints v2（狀態持久化） 第四章：安裝與環境建置 4.1 系統需求 4.2 快速安裝（Linux / macOS / WSL2） 4.3 Native Windows 安裝 4.4 Docker / Podman 部署 4.5 Nix Flake 安裝 4.6 設定 API Key 4.7 設定檔說明 第五章：快速開始（Quick Start） 5.1 第一次對話 5.2 建立 AI Coding Agent 5.3 設定 Memory 5.4 設定 Tools 5.5 執行任務範例 第六章：進階開發（企業級） 6.1 自訂 Skill（技能封裝） 6.2 多 Agent 協作設計 6.3 Multi-agent Kanban 實戰 6.4 長期記憶設計（Vector DB） 6.5 任務拆解（Task Decomposition） 6.6 Workflow Orchestration 6.7 SOUL.md 與 Personality 系統 6.8 Context Files（專案上下文檔案） 6.9 Plugin 系統（v0.12.0+ / v0.13.0 擴充） 第七章：Voice Mode（語音模式） 7.1 語音模式概述 7.2 支援的 STT / TTS 提供者 7.3 CLI 語音互動 7.4 Telegram / Discord 語音互動 7.5 Discord Voice Channel 即時語音 7.6 企業語音整合建議 第八章：Web Application 整合 8.1 整合架構設計 8.2 FastAPI 後端整合 8.3 Spring Boot 後端整合 8.4 前端整合（Vue / React） 8.5 Agent-as-a-Service API 設計 第九章：企業級最佳實踐 9.1 安全性設計 9.1.4 安全強化（v0.5.0 — v0.13.0 持續強化） 9.2 成本控制 9.3 效能優化 9.4 Logging / Monitoring 9.5 錯誤處理與重試機制 9.6 Tips \u0026amp; Best Practices 第十章：部署與維運（DevOps） 10.1 Docker 部署 10.2 Kubernetes 部署 10.3 CI/CD 流程 10.4 滾動升級 10.5 災難復原（DR） 第十一章：升級與版本管理 11.1 升級策略 11.1.6 v0.13.0 升級特別注意事項 11.2 相容性管理 11.3 Migration 設計 第十二章：實戰案例 12.1 AI Coding Agent 12.2 智慧客服 Agent 12.3 銀行流程自動化 Agent 12.4 多媒體創作 Agent 第十三章：常見問題（FAQ） 第十四章：Hermes Desktop App（v0.16.0+） 附錄 A：檢查清單（Checklist） 附錄 B：指令速查表 附錄 C：環境變數參考 附錄 D：Provider 完整清單 第一章：Hermes Agent 概述 1.1 技術背景與發展 Hermes Agent 是由 Nous Research 開發的開源自我改進 AI Agent。Nous Research 是知名的 AI 研究實驗室，以訓練 Hermes、Nomos、Psyche 等開源模型聞名。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/hermes-agent%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Hermes Agent 生態系教學手冊（Enterprise Edition） 版本：v0.17.0（v2026.6.19 — 涵蓋 The Foundation Release + The Velocity Release + The Surface Release + The Reach Release）\n適用對象：資深工程師 / 架構師 / DevOps 團隊\n授權：MIT License\n官方網站：hermes-agent.nousresearch.com\nGitHub：github.com/NousResearch/hermes-agent\n官方文件：hermes-agent.nousresearch.com/docs\nDesktop 下載：hermes-agent.nousresearch.com（macOS / Windows / Linux）\nSkills Hub：agentskills.io\nLLM 友善文件：llms.txt / llms-full.txt\n最後更新：2026 年 6 月 30 日\n📑 目錄 第一章：Hermes Agent 概述 1.1 技術背景與發展 1.2 與傳統 AI 的差異 1.3 Agent vs Workflow vs RPA 比較 1.4 核心設計理念 1.4.1 Learning Loop（學習迴圈） 1.4.2 Skill System（技能系統） 1.4.3 Persistent Memory（持久記憶） 1.4.4 Model Agnostic（模型無關） 1.4.5 Voice Mode（語音模式） 1.4.6 Web Dashboard（v0.9.0+） 1.4.7 Transport 架構（v0.11.0+） 1.4.8 Autonomous Curator（v0.12.0+） 1.4.9 Multi-agent Kanban（v0.13.0+） 1.4.10 Persistent Goals（v0.13.0+） 1.4.11 Post-write Delta Lint（v0.13.0+） 1.4.12 i18n 多語言支援（v0.13.0+） 1.4.13 hermes proxy — OpenAI 相容本地代理（v0.14.0+） 1.4.14 PyPI 套件安裝（v0.14.0+） 1.4.15 /handoff 即時 Session 轉移（v0.14.0+） 1.4.16 Promptware 防禦（v0.15.0+） 1.4.17 Bitwarden Secrets Manager（v0.15.0+） 1.4.18 Skill Bundles（v0.15.0+） 1.4.19 Hermes Desktop App（v0.16.0+） 1.4.20 Background Subagents（v0.17.0+） 1.4.21 Image Editing（v0.17.0+） 1.4.22 Automation Blueprints（v0.17.0+） 1.4.23 Memory Atomic Batch Operations（v0.17.0+） 第二章：整體系統架構 2.1 架構設計概述 2.2 分層架構圖 2.3 各層級說明 2.4 多 Agent 協作架構 2.5 高可用與擴展性設計 第三章：Hermes Agent 核心機制解析 3.1 Learning Loop（學習迴圈） 3.2 Skill System（技能系統） 3.3 Memory System（記憶系統） 3.4 Planning / Execution Flow 3.5 Tool Calling 機制 3.6 Model Routing（多模型切換） 3.7 Autonomous Curator（自動技能維護） 3.8 Persistent Goals 與 Ralph Loop 3.9 Post-write Delta Lint（自動語法檢查） 3.10 Checkpoints v2（狀態持久化） 第四章：安裝與環境建置 4.1 系統需求 4.2 快速安裝（Linux / macOS / WSL2） 4.3 Native Windows 安裝 4.4 Docker / Podman 部署 4.5 Nix Flake 安裝 4.6 設定 API Key 4.7 設定檔說明 第五章：快速開始（Quick Start） 5.1 第一次對話 5.2 建立 AI Coding Agent 5.3 設定 Memory 5.4 設定 Tools 5.5 執行任務範例 第六章：進階開發（企業級） 6.1 自訂 Skill（技能封裝） 6.2 多 Agent 協作設計 6.3 Multi-agent Kanban 實戰 6.4 長期記憶設計（Vector DB） 6.5 任務拆解（Task Decomposition） 6.6 Workflow Orchestration 6.7 SOUL.md 與 Personality 系統 6.8 Context Files（專案上下文檔案） 6.9 Plugin 系統（v0.12.0+ / v0.13.0 擴充） 第七章：Voice Mode（語音模式） 7.1 語音模式概述 7.2 支援的 STT / TTS 提供者 7.3 CLI 語音互動 7.4 Telegram / Discord 語音互動 7.5 Discord Voice Channel 即時語音 7.6 企業語音整合建議 第八章：Web Application 整合 8.1 整合架構設計 8.2 FastAPI 後端整合 8.3 Spring Boot 後端整合 8.4 前端整合（Vue / React） 8.5 Agent-as-a-Service API 設計 第九章：企業級最佳實踐 9.1 安全性設計 9.1.4 安全強化（v0.5.0 — v0.13.0 持續強化） 9.2 成本控制 9.3 效能優化 9.4 Logging / Monitoring 9.5 錯誤處理與重試機制 9.6 Tips \u0026amp; Best Practices 第十章：部署與維運（DevOps） 10.1 Docker 部署 10.2 Kubernetes 部署 10.3 CI/CD 流程 10.4 滾動升級 10.5 災難復原（DR） 第十一章：升級與版本管理 11.1 升級策略 11.1.6 v0.13.0 升級特別注意事項 11.2 相容性管理 11.3 Migration 設計 第十二章：實戰案例 12.1 AI Coding Agent 12.2 智慧客服 Agent 12.3 銀行流程自動化 Agent 12.4 多媒體創作 Agent 第十三章：常見問題（FAQ） 第十四章：Hermes Desktop App（v0.16.0+） 附錄 A：檢查清單（Checklist） 附錄 B：指令速查表 附錄 C：環境變數參考 附錄 D：Provider 完整清單 第一章：Hermes Agent 概述 1.1 技術背景與發展 Hermes Agent 是由 Nous Research 開發的開源自我改進 AI Agent。Nous Research 是知名的 AI 研究實驗室，以訓練 Hermes、Nomos、Psyche 等開源模型聞名。\n","title":"Hermes Agent生態系教學手冊"},{"content":"Multica 教學手冊（企業級實戰版） 版本： v0.3.33（2026-06-30）\n適用對象： 資深工程師、架構師、DevOps 工程師、技術主管\n技術棧： Go Backend + Next.js 16 Frontend + PostgreSQL 17 + pgvector + Redis（選用）+ Agent Daemon\n授權： Multica Source Available License（非 SaaS/轉售可自由使用）\n文件等級： 企業標準技術白皮書\n目錄 第 1 章：Multica 概述 1.1 什麼是 Multica？ 1.2 名稱由來 1.3 核心設計理念 1.4 與傳統工具的差異比較 1.5 適用場景 1.6 專案基本資訊 1.7 授權模式說明 第 2 章：系統架構設計 2.1 整體架構概覽 2.2 技術棧詳解 2.3 元件說明 2.4 企業整合架構 2.5 資料流向與通訊模型 第 3 章：安裝與部署 3.1 部署模式選擇 3.2 Self-Hosted 快速部署（推薦） 3.3 Self-Hosted 手動部署（Step-by-Step） 3.4 Kubernetes 部署（Helm Chart） 3.5 環境變數設定 3.6 Production 部署（反向代理） 3.7 不使用 Docker 的手動部署 3.8 Usage Dashboard Rollup 設定 3.9 停止服務 3.10 切換至 Multica Cloud 第 4 章：核心運作機制 4.1 任務生命週期（Issue Lifecycle） 4.2 Agent 自主執行流程 4.3 任務排程與佇列機制 4.4 WebSocket 通訊流程 4.5 Execution History 查詢 4.6 Issue Metadata（結構化屬性） 4.7 Subscribers（訂閱機制） 4.8 Thread-aware Comments（串接式評論） 第 5 章：AI Agent 整合 5.1 支援的 AI Agent 5.2 Agent CLI 安裝 5.3 CLI 自動偵測機制 5.4 Agent 環境變數（Per-Agent 設定） 5.5 Agent 建立與設定 5.6 Prompt 設計策略（Agent 專用） 5.7 多 Agent 協作模式 第 6 章：開發流程 6.1 完整開發流程 6.2 Issue 管理 6.3 範例：Spring Boot API 開發流程 6.4 範例：Vue 前端功能開發流程 6.5 與 Git Flow 整合 第 7 章：Skill（技能）機制設計 7.1 Skill 概念 7.2 Skill 類型 7.3 Skill 定義與儲存 7.4 範例：自動部署 Skill 7.5 範例：Code Review Skill 7.6 範例：DB Migration Skill 7.7 建立企業級 Skill Library 第 8 章：多工作空間（Workspace）設計 8.1 Workspace 概念 8.2 Workspace CLI 管理 8.3 團隊隔離策略 8.4 權限控管（RBAC） 8.5 多 Daemon Profile 8.6 工作空間垃圾回收（Workspace GC） 第 9 章：Squads（團隊編組） 9.1 Squads 概念 9.2 Squad 的價值 9.3 企業應用場景 第 10 章：Autopilots（自動化排程） 10.1 Autopilots 概念 10.2 Autopilot CLI 管理 10.3 企業應用範例 第 11 章：Projects（專案管理） 11.1 Projects 概念 11.2 Project CLI 管理 11.3 Project 與 Issue 整合 11.4 企業應用場景 第 12 章：MCP 整合（Model Context Protocol） 12.1 MCP 概述 12.2 MCP 整合場景 第 13 章：系統維運（Operations） 13.1 Log 管理 13.2 Agent 狀態監控 13.3 監控架構 13.4 建議監控指標 13.5 錯誤處理與復原 13.6 效能優化 第 14 章：系統升級與擴展（Upgrade \u0026amp; Scaling） 14.1 Multica 升級策略 14.2 版本管理策略 14.3 Agent 水平擴展 14.4 高可用架構（HA） 14.5 切換至 Multica Cloud 第 15 章：安全設計（Security） 15.1 認證與授權 15.2 Agent 權限隔離 15.3 憑證管理 15.4 網路安全 15.5 SSDLC 整合 第 16 章：最佳實務（Best Practices） 16.1 團隊導入策略 16.2 Prompt Engineering 原則 16.3 Agent 使用規範 16.4 常見錯誤與避免方式 16.5 開發環境最佳實務 第 17 章：實戰案例（Case Study） 17.1 案例：建立企業 Web 系統 17.2 案例總結 附錄 A：檢查清單（Checklist） 附錄 B：CLI 快速參考卡 附錄 C：術語表（Glossary） 第 1 章：Multica 概述 1.1 什麼是 Multica？ Multica 是一個開源的 Managed AI Agent 平台，致力於將 AI 編碼代理轉化為團隊中真正的「虛擬隊友」。有別於傳統 AI 對話工具的被動互動模式，Multica 提供完整的任務管理與 Agent 自主執行基礎設施，使 AI Agent 成為開發流程中不可或缺的一等公民（First-Class Citizen）。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/multica-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Multica 教學手冊（企業級實戰版） 版本： v0.3.33（2026-06-30）\n適用對象： 資深工程師、架構師、DevOps 工程師、技術主管\n技術棧： Go Backend + Next.js 16 Frontend + PostgreSQL 17 + pgvector + Redis（選用）+ Agent Daemon\n授權： Multica Source Available License（非 SaaS/轉售可自由使用）\n文件等級： 企業標準技術白皮書\n目錄 第 1 章：Multica 概述 1.1 什麼是 Multica？ 1.2 名稱由來 1.3 核心設計理念 1.4 與傳統工具的差異比較 1.5 適用場景 1.6 專案基本資訊 1.7 授權模式說明 第 2 章：系統架構設計 2.1 整體架構概覽 2.2 技術棧詳解 2.3 元件說明 2.4 企業整合架構 2.5 資料流向與通訊模型 第 3 章：安裝與部署 3.1 部署模式選擇 3.2 Self-Hosted 快速部署（推薦） 3.3 Self-Hosted 手動部署（Step-by-Step） 3.4 Kubernetes 部署（Helm Chart） 3.5 環境變數設定 3.6 Production 部署（反向代理） 3.7 不使用 Docker 的手動部署 3.8 Usage Dashboard Rollup 設定 3.9 停止服務 3.10 切換至 Multica Cloud 第 4 章：核心運作機制 4.1 任務生命週期（Issue Lifecycle） 4.2 Agent 自主執行流程 4.3 任務排程與佇列機制 4.4 WebSocket 通訊流程 4.5 Execution History 查詢 4.6 Issue Metadata（結構化屬性） 4.7 Subscribers（訂閱機制） 4.8 Thread-aware Comments（串接式評論） 第 5 章：AI Agent 整合 5.1 支援的 AI Agent 5.2 Agent CLI 安裝 5.3 CLI 自動偵測機制 5.4 Agent 環境變數（Per-Agent 設定） 5.5 Agent 建立與設定 5.6 Prompt 設計策略（Agent 專用） 5.7 多 Agent 協作模式 第 6 章：開發流程 6.1 完整開發流程 6.2 Issue 管理 6.3 範例：Spring Boot API 開發流程 6.4 範例：Vue 前端功能開發流程 6.5 與 Git Flow 整合 第 7 章：Skill（技能）機制設計 7.1 Skill 概念 7.2 Skill 類型 7.3 Skill 定義與儲存 7.4 範例：自動部署 Skill 7.5 範例：Code Review Skill 7.6 範例：DB Migration Skill 7.7 建立企業級 Skill Library 第 8 章：多工作空間（Workspace）設計 8.1 Workspace 概念 8.2 Workspace CLI 管理 8.3 團隊隔離策略 8.4 權限控管（RBAC） 8.5 多 Daemon Profile 8.6 工作空間垃圾回收（Workspace GC） 第 9 章：Squads（團隊編組） 9.1 Squads 概念 9.2 Squad 的價值 9.3 企業應用場景 第 10 章：Autopilots（自動化排程） 10.1 Autopilots 概念 10.2 Autopilot CLI 管理 10.3 企業應用範例 第 11 章：Projects（專案管理） 11.1 Projects 概念 11.2 Project CLI 管理 11.3 Project 與 Issue 整合 11.4 企業應用場景 第 12 章：MCP 整合（Model Context Protocol） 12.1 MCP 概述 12.2 MCP 整合場景 第 13 章：系統維運（Operations） 13.1 Log 管理 13.2 Agent 狀態監控 13.3 監控架構 13.4 建議監控指標 13.5 錯誤處理與復原 13.6 效能優化 第 14 章：系統升級與擴展（Upgrade \u0026amp; Scaling） 14.1 Multica 升級策略 14.2 版本管理策略 14.3 Agent 水平擴展 14.4 高可用架構（HA） 14.5 切換至 Multica Cloud 第 15 章：安全設計（Security） 15.1 認證與授權 15.2 Agent 權限隔離 15.3 憑證管理 15.4 網路安全 15.5 SSDLC 整合 第 16 章：最佳實務（Best Practices） 16.1 團隊導入策略 16.2 Prompt Engineering 原則 16.3 Agent 使用規範 16.4 常見錯誤與避免方式 16.5 開發環境最佳實務 第 17 章：實戰案例（Case Study） 17.1 案例：建立企業 Web 系統 17.2 案例總結 附錄 A：檢查清單（Checklist） 附錄 B：CLI 快速參考卡 附錄 C：術語表（Glossary） 第 1 章：Multica 概述 1.1 什麼是 Multica？ Multica 是一個開源的 Managed AI Agent 平台，致力於將 AI 編碼代理轉化為團隊中真正的「虛擬隊友」。有別於傳統 AI 對話工具的被動互動模式，Multica 提供完整的任務管理與 Agent 自主執行基礎設施，使 AI Agent 成為開發流程中不可或缺的一等公民（First-Class Citizen）。\n","title":"Multica 教學手冊"},{"content":"oh-my-openagent（Oh My OpenCode, OMO）教學手冊 版本：v6.0｜最後更新：2026-06-30\n對應 OMO 版本：v4.14.1（208 releases）\n適用對象：資深工程師、架構師、技術主管\n定位：企業級 Multi-Harness AI Agent OS 教學手冊\nGitHub：https://github.com/code-yeongyu/oh-my-openagent\n官網：https://omo.dev/\n📑 目錄 第 1 章：總覽（Overview） 第 2 章：系統架構設計（Architecture） 第 3 章：安裝與環境建置（Installation） 第 4 章：設定與專案初始化（Configuration） 第 5 章：Agent 系統詳解（Discipline Agents） 第 6 章：開發流程（ultrawork / Plan / Build） 第 7 章：Team Mode（v4.0 新增） 第 8 章：Boulder 追蹤系統（v4.1 新增） 第 9 章：Web Application 實戰 第 10 章：測試與品質（Testing \u0026amp; Quality） 第 11 章：維運與除錯（Maintenance） 第 12 章：升級與版本管理（Upgrade） 第 13 章：安全（SSDLC） 第 14 章：團隊導入策略（Enterprise Adoption） 第 15 章：最佳實務（Best Practices） 第 16 章：常見問題（FAQ） 第 17 章：遙測與隱私（Telemetry \u0026amp; Privacy） 第 18 章：附錄（Appendix） 檢查清單（Checklist） 第 1 章：總覽（Overview） 1.1 什麼是 oh-my-openagent（OMO） oh-my-openagent（簡稱 OMO，又稱 Oh My OpenCode）是由 code-yeongyu 開發的 Multi-Harness AI Agent OS，以 TypeScript 編寫（86.2%），專為將 OpenCode（開源終端 AI 編碼代理）升級為一個具備**紀律型多代理協作（Discipline Agents）**能力的 AI 開發團隊。自 v4.3.0 起，OMO 進行了 Multi-Harness 重構，將核心邏輯拆分為 9 個獨立 workspace packages，支援 OpenCode、Codex CLI 等多種 Harness 平台。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/oh-my-openagentoh-my-opencode-omo%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"oh-my-openagent（Oh My OpenCode, OMO）教學手冊 版本：v6.0｜最後更新：2026-06-30\n對應 OMO 版本：v4.14.1（208 releases）\n適用對象：資深工程師、架構師、技術主管\n定位：企業級 Multi-Harness AI Agent OS 教學手冊\nGitHub：https://github.com/code-yeongyu/oh-my-openagent\n官網：https://omo.dev/\n📑 目錄 第 1 章：總覽（Overview） 第 2 章：系統架構設計（Architecture） 第 3 章：安裝與環境建置（Installation） 第 4 章：設定與專案初始化（Configuration） 第 5 章：Agent 系統詳解（Discipline Agents） 第 6 章：開發流程（ultrawork / Plan / Build） 第 7 章：Team Mode（v4.0 新增） 第 8 章：Boulder 追蹤系統（v4.1 新增） 第 9 章：Web Application 實戰 第 10 章：測試與品質（Testing \u0026amp; Quality） 第 11 章：維運與除錯（Maintenance） 第 12 章：升級與版本管理（Upgrade） 第 13 章：安全（SSDLC） 第 14 章：團隊導入策略（Enterprise Adoption） 第 15 章：最佳實務（Best Practices） 第 16 章：常見問題（FAQ） 第 17 章：遙測與隱私（Telemetry \u0026amp; Privacy） 第 18 章：附錄（Appendix） 檢查清單（Checklist） 第 1 章：總覽（Overview） 1.1 什麼是 oh-my-openagent（OMO） oh-my-openagent（簡稱 OMO，又稱 Oh My OpenCode）是由 code-yeongyu 開發的 Multi-Harness AI Agent OS，以 TypeScript 編寫（86.2%），專為將 OpenCode（開源終端 AI 編碼代理）升級為一個具備**紀律型多代理協作（Discipline Agents）**能力的 AI 開發團隊。自 v4.3.0 起，OMO 進行了 Multi-Harness 重構，將核心邏輯拆分為 9 個獨立 workspace packages，支援 OpenCode、Codex CLI 等多種 Harness 平台。\n","title":"Oh My Openagent（Oh My OpenCode, OMO）教學手冊"},{"content":"OpenAI Codex生態系教學手冊 版本：1.5\n文件等級：企業標準技術白皮書 / 內訓教材 / 實戰手冊\n適用對象：資深工程師、Tech Lead、架構師、平台工程師、DevOps、DevSecOps、研發主管\n最後更新：2026 年 6 月 30 日\n文件定位：協助團隊建立可治理、可落地、可維運的 AI 輔助開發流程\n前言 OpenAI Codex 已不再只是「幫忙補程式碼」的工具，而是逐步演化為一個涵蓋桌面應用程式、Chrome 擴充功能、IDE 擴充功能、CLI、SDK、API、雲端執行環境、工作樹、技能系統、插件生態、自動化動作、Sites 託管部署、Memories 記憶系統、AI Agent 與 DevOps 整合的完整工程能力平台。2026 年 2 月推出的 Codex App 正式將其定位為「智慧體指揮中心」，讓開發者可以同時管理多個智慧體並行工作。隨後 GPT-5.4 與 GPT-5.5 模型相繼推出，GPT-5.5 已成為官方推薦的最新前沿模型（GPT-5.3-Codex 與 GPT-5.2 已於 2026 年 5 月正式淘汰）。2026 年 5 月推出 Appshots、Goal Mode 正式版、Codex for Chrome、Codex Mobile、Permission Profiles 與 Hooks GA 等功能；2026 年 6 月再推出 Sites（網站託管部署）、Record \u0026amp; Replay（操作錄製轉技能）、Amazon Bedrock 整合、Codex Remote GA（遠端連線正式版）、Developer Mode for Browser、Memories / Chronicle 記憶系統及 Migrate to Codex（從 Claude Code 匯入），Codex 的能力邊界持續擴大。Codex CLI 以 Rust 建構並持續快速迭代，新增 Subagents、Hooks、MCP（Model Context Protocol）、遠端 TUI、GitHub Action、圖片輸入／生成、Web Search、Slash Commands 等大量功能。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/openai-codex%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"OpenAI Codex生態系教學手冊 版本：1.5\n文件等級：企業標準技術白皮書 / 內訓教材 / 實戰手冊\n適用對象：資深工程師、Tech Lead、架構師、平台工程師、DevOps、DevSecOps、研發主管\n最後更新：2026 年 6 月 30 日\n文件定位：協助團隊建立可治理、可落地、可維運的 AI 輔助開發流程\n前言 OpenAI Codex 已不再只是「幫忙補程式碼」的工具，而是逐步演化為一個涵蓋桌面應用程式、Chrome 擴充功能、IDE 擴充功能、CLI、SDK、API、雲端執行環境、工作樹、技能系統、插件生態、自動化動作、Sites 託管部署、Memories 記憶系統、AI Agent 與 DevOps 整合的完整工程能力平台。2026 年 2 月推出的 Codex App 正式將其定位為「智慧體指揮中心」，讓開發者可以同時管理多個智慧體並行工作。隨後 GPT-5.4 與 GPT-5.5 模型相繼推出，GPT-5.5 已成為官方推薦的最新前沿模型（GPT-5.3-Codex 與 GPT-5.2 已於 2026 年 5 月正式淘汰）。2026 年 5 月推出 Appshots、Goal Mode 正式版、Codex for Chrome、Codex Mobile、Permission Profiles 與 Hooks GA 等功能；2026 年 6 月再推出 Sites（網站託管部署）、Record \u0026amp; Replay（操作錄製轉技能）、Amazon Bedrock 整合、Codex Remote GA（遠端連線正式版）、Developer Mode for Browser、Memories / Chronicle 記憶系統及 Migrate to Codex（從 Claude Code 匯入），Codex 的能力邊界持續擴大。Codex CLI 以 Rust 建構並持續快速迭代，新增 Subagents、Hooks、MCP（Model Context Protocol）、遠端 TUI、GitHub Action、圖片輸入／生成、Web Search、Slash Commands 等大量功能。\n","title":"OpenAI Codex生態系教學手冊"},{"content":"OpenClaw 生態系教學手冊 版本: 2026.6.10 | 最後更新: 2026 年 6 月 30 日\n適用對象: 企業開發團隊、DevOps 工程師、AI 架構師\n授權: MIT License\n官方資源: openclaw.ai · docs.openclaw.ai · GitHub · ClawHub · Discord · Trust · DeepWiki\n文件總覽 本手冊為企業級 OpenClaw 生態系完整教學指引，涵蓋從核心概念、系統架構設計、安裝部署、開發實戰、企業最佳實務、維運監控、升級策略、DevOps 整合、資安設計到實務案例等十大主題。所有內容均依據 OpenClaw 官方文件（v2026.6.10）撰寫，並以繁體中文呈現，程式碼範例以 Java 為主。\n重要變更提示：OpenClaw 自 2025 年 11 月從 Clawdbot / Moltbot 正式更名為 OpenClaw，版本號採用 vYYYY.M.D 日期格式。截至 2026 年 6 月已發布 217 個正式版本（含 beta）。自 v2026.5 起，專案引入完整的 Plugin SDK 架構，支援 bundled / community / external 三類插件，大幅擴展了通道與功能的可擴展性。v2026.6 系列新增 Automatic Fast Mode（短對話自動加速）、DM Pairing 安全機制（未知發送者需配對碼驗證）、官方 Provider 外部化為獨立 npm 套件、Session Transcript SDK（插件可讀/寫/發布對話紀錄）、GLM-5.2 + Claude Haiku 4.5 模型目錄、Telegram Rich HTML 渲染（表格/清單/blockquote）、Codex Hosted Search、OpenTelemetry Log Export、Windows Hub 伴侶應用、per-agent usage-cost reporting、Trusted Tool Policy Enforcement 等重大功能。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/openclaw%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"OpenClaw 生態系教學手冊 版本: 2026.6.10 | 最後更新: 2026 年 6 月 30 日\n適用對象: 企業開發團隊、DevOps 工程師、AI 架構師\n授權: MIT License\n官方資源: openclaw.ai · docs.openclaw.ai · GitHub · ClawHub · Discord · Trust · DeepWiki\n文件總覽 本手冊為企業級 OpenClaw 生態系完整教學指引，涵蓋從核心概念、系統架構設計、安裝部署、開發實戰、企業最佳實務、維運監控、升級策略、DevOps 整合、資安設計到實務案例等十大主題。所有內容均依據 OpenClaw 官方文件（v2026.6.10）撰寫，並以繁體中文呈現，程式碼範例以 Java 為主。\n重要變更提示：OpenClaw 自 2025 年 11 月從 Clawdbot / Moltbot 正式更名為 OpenClaw，版本號採用 vYYYY.M.D 日期格式。截至 2026 年 6 月已發布 217 個正式版本（含 beta）。自 v2026.5 起，專案引入完整的 Plugin SDK 架構，支援 bundled / community / external 三類插件，大幅擴展了通道與功能的可擴展性。v2026.6 系列新增 Automatic Fast Mode（短對話自動加速）、DM Pairing 安全機制（未知發送者需配對碼驗證）、官方 Provider 外部化為獨立 npm 套件、Session Transcript SDK（插件可讀/寫/發布對話紀錄）、GLM-5.2 + Claude Haiku 4.5 模型目錄、Telegram Rich HTML 渲染（表格/清單/blockquote）、Codex Hosted Search、OpenTelemetry Log Export、Windows Hub 伴侶應用、per-agent usage-cost reporting、Trusted Tool Policy Enforcement 等重大功能。\n","title":"OpenClaw生態系教學手冊"},{"content":"Playwright 教學手冊（企業級完整版） 版本：基於 Playwright v1.61.1（2026 年 6 月）\n適用對象：資深工程師、SDET、QA Lead、DevOps 工程師\n授權：Apache 2.0（Playwright 開源授權）\n最後更新：2026-06-30\n目錄 第 1 章：Playwright 總覽 1.1 什麼是 Playwright 1.2 Playwright 核心架構 1.3 Playwright vs. Selenium vs. Cypress 比較 1.4 適用場景 1.5 系統需求 第 2 章：系統架構設計（企業級） 2.1 測試架構總覽 2.2 分層設計 2.3 測試資料管理策略 2.4 多環境配置 2.5 與微服務架構整合 第 3 章：安裝與環境建置 3.1 Node.js 安裝 3.2 Python 安裝 3.3 Java 安裝 3.4 專案目錄結構 3.5 VS Code 設定 3.6 Playwright MCP Server 設定 3.7 Playwright CLI 安裝 3.8 Playwright Agents 設定（v1.56+） 3.9 企業環境安裝注意事項 第 4 章：基礎使用教學 4.1 第一個測試案例 4.2 Locator 使用策略 4.3 Auto-wait 機制 4.4 Assertions（Web-First 驗證） 4.5 Headless / Headed 模式 第 5 章：進階功能 5.1 Codegen（錄製測試） 5.2 Playwright Inspector 5.3 Trace Viewer 5.4 Network 攔截（Mock API） 5.5 多分頁 / iframe 操作 5.6 檔案上傳與下載 5.7 視覺測試（Screenshot Comparison） 5.8 認證狀態重用（Auth State） 5.9 Screencast API（v1.59+） 5.10 Browser Interoperability（v1.59+） 5.11 Observability Dashboard（v1.59+） 5.12 CLI Debugger for Agents（v1.59+） 5.13 CLI Trace 分析（v1.59+） 5.14 Async Disposables — await using（v1.59+） 5.15 HAR Recording on Tracing（v1.60+） 5.16 Drop API（v1.60+） 5.17 Aria Snapshots 增強（v1.60+） 5.18 新增 API 與選項（v1.60+） 5.19 WebAuthn Passkeys — Credentials API（v1.61+） 5.20 Web Storage API（v1.61+） 5.21 Network API 擴展（v1.61+） 5.22 Test Runner 增強（v1.61+） 第 6 章：測試設計最佳實踐 6.1 Page Object Model（POM）完整實作 6.2 減少 Flaky Test 策略 6.3 測試命名規範 6.4 自訂 Fixtures 第 7 章：CI/CD 整合（企業級重點） 7.1 GitHub Actions 7.2 GitLab CI 7.3 Jenkins Pipeline 7.4 測試報告整合 7.5 測試失敗通知 7.6 Docker 化測試執行 7.7 WebServer Wait 功能（v1.57+） 7.8 testConfig.tag — 全域標籤（v1.57+） 第 8 章：測試報告與監控 8.1 Playwright HTML Report 8.2 Trace 分析 8.3 自訂 Reporter 8.4 測試結果 Dashboard 第 9 章：系統維運與管理 9.1 測試環境管理 9.2 測試資料清理 9.3 測試排程 9.4 平行測試（Parallel Execution） 9.5 測試資源最佳化 第 10 章：升級與版本管理策略 10.1 Playwright 版本升級策略 10.2 Breaking Changes 處理 10.3 瀏覽器版本管理 10.4 回滾策略 第 11 章：安全與合規（銀行級） 11.1 敏感資料處理 11.2 測試帳號管理 11.3 存取控制（RBAC） 11.4 稽核與日誌（Audit Log） 第 12 章：團隊導入指南 12.1 Playwright 導入 Roadmap 12.2 導入里程碑 12.3 團隊角色分工 12.4 Code Review 規範 12.5 教育訓練計畫 第 13 章：完整專案範本 13.1 專案結構 13.2 完整 playwright.config.ts 範本 13.3 完整 package.json 範本 13.4 .gitignore 範本 13.5 Tag 使用策略 附錄 A：新進成員檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：參考資源 第 1 章：Playwright 總覽 1.1 什麼是 Playwright Playwright 是由 Microsoft 開發並開源的瀏覽器自動化與端對端（E2E）測試框架，採用 Apache 2.0 授權。它透過單一 API 驅動 Chromium、Firefox 與 WebKit 三大瀏覽器引擎，支援 Windows、Linux、macOS 跨平台執行。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/playwright-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Playwright 教學手冊（企業級完整版） 版本：基於 Playwright v1.61.1（2026 年 6 月）\n適用對象：資深工程師、SDET、QA Lead、DevOps 工程師\n授權：Apache 2.0（Playwright 開源授權）\n最後更新：2026-06-30\n目錄 第 1 章：Playwright 總覽 1.1 什麼是 Playwright 1.2 Playwright 核心架構 1.3 Playwright vs. Selenium vs. Cypress 比較 1.4 適用場景 1.5 系統需求 第 2 章：系統架構設計（企業級） 2.1 測試架構總覽 2.2 分層設計 2.3 測試資料管理策略 2.4 多環境配置 2.5 與微服務架構整合 第 3 章：安裝與環境建置 3.1 Node.js 安裝 3.2 Python 安裝 3.3 Java 安裝 3.4 專案目錄結構 3.5 VS Code 設定 3.6 Playwright MCP Server 設定 3.7 Playwright CLI 安裝 3.8 Playwright Agents 設定（v1.56+） 3.9 企業環境安裝注意事項 第 4 章：基礎使用教學 4.1 第一個測試案例 4.2 Locator 使用策略 4.3 Auto-wait 機制 4.4 Assertions（Web-First 驗證） 4.5 Headless / Headed 模式 第 5 章：進階功能 5.1 Codegen（錄製測試） 5.2 Playwright Inspector 5.3 Trace Viewer 5.4 Network 攔截（Mock API） 5.5 多分頁 / iframe 操作 5.6 檔案上傳與下載 5.7 視覺測試（Screenshot Comparison） 5.8 認證狀態重用（Auth State） 5.9 Screencast API（v1.59+） 5.10 Browser Interoperability（v1.59+） 5.11 Observability Dashboard（v1.59+） 5.12 CLI Debugger for Agents（v1.59+） 5.13 CLI Trace 分析（v1.59+） 5.14 Async Disposables — await using（v1.59+） 5.15 HAR Recording on Tracing（v1.60+） 5.16 Drop API（v1.60+） 5.17 Aria Snapshots 增強（v1.60+） 5.18 新增 API 與選項（v1.60+） 5.19 WebAuthn Passkeys — Credentials API（v1.61+） 5.20 Web Storage API（v1.61+） 5.21 Network API 擴展（v1.61+） 5.22 Test Runner 增強（v1.61+） 第 6 章：測試設計最佳實踐 6.1 Page Object Model（POM）完整實作 6.2 減少 Flaky Test 策略 6.3 測試命名規範 6.4 自訂 Fixtures 第 7 章：CI/CD 整合（企業級重點） 7.1 GitHub Actions 7.2 GitLab CI 7.3 Jenkins Pipeline 7.4 測試報告整合 7.5 測試失敗通知 7.6 Docker 化測試執行 7.7 WebServer Wait 功能（v1.57+） 7.8 testConfig.tag — 全域標籤（v1.57+） 第 8 章：測試報告與監控 8.1 Playwright HTML Report 8.2 Trace 分析 8.3 自訂 Reporter 8.4 測試結果 Dashboard 第 9 章：系統維運與管理 9.1 測試環境管理 9.2 測試資料清理 9.3 測試排程 9.4 平行測試（Parallel Execution） 9.5 測試資源最佳化 第 10 章：升級與版本管理策略 10.1 Playwright 版本升級策略 10.2 Breaking Changes 處理 10.3 瀏覽器版本管理 10.4 回滾策略 第 11 章：安全與合規（銀行級） 11.1 敏感資料處理 11.2 測試帳號管理 11.3 存取控制（RBAC） 11.4 稽核與日誌（Audit Log） 第 12 章：團隊導入指南 12.1 Playwright 導入 Roadmap 12.2 導入里程碑 12.3 團隊角色分工 12.4 Code Review 規範 12.5 教育訓練計畫 第 13 章：完整專案範本 13.1 專案結構 13.2 完整 playwright.config.ts 範本 13.3 完整 package.json 範本 13.4 .gitignore 範本 13.5 Tag 使用策略 附錄 A：新進成員檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：參考資源 第 1 章：Playwright 總覽 1.1 什麼是 Playwright Playwright 是由 Microsoft 開發並開源的瀏覽器自動化與端對端（E2E）測試框架，採用 Apache 2.0 授權。它透過單一 API 驅動 Chromium、Firefox 與 WebKit 三大瀏覽器引擎，支援 Windows、Linux、macOS 跨平台執行。\n","title":"Playwright 教學手冊"},{"content":"Superpowers 教學手冊（企業標準技術白皮書） 版本：v6.0｜基於：Superpowers Framework v6.1.1（by Jesse Vincent / obra @ Prime Radiant）\n最後更新：2026-07-23｜適用對象：資深工程師、Tech Lead、AI Agent 團隊｜語言：繁體中文\nGitHub：https://github.com/obra/superpowers ⭐ 260k stars · 23.2k forks · 36 Contributors\nPlugin Marketplace：https://claude.com/plugins/superpowers（Anthropic Verified · 885k+ installs）\nDiscord 社群：https://discord.gg/35wsABTejz\nCommercial Support：sales@primeradiant.com\nLicense：MIT\n目錄 第 1 章：Superpowers 概述 1.1 什麼是 Superpowers 1.2 與 Prompt Engineering / Agent Framework 的差異 1.3 適用場景 1.4 核心價值：工程紀律 1.5 支援平台總覽 1.6 版本演進歷程 第 2 章：整體系統架構設計 2.1 Superpowers 在 AI 開發架構中的位置 2.2 Plugin 架構與多平台支援 2.3 技能自動觸發機制 2.4 Hooks 系統 2.5 與 CI/CD 系統整合 2.6 整體技術堆疊 第 3 章：安裝與環境建置 3.1 前置要求 3.2 安裝步驟 3.3 專案初始化 3.4 建議目錄結構 3.5 Dev Container 配置（選用） 3.6 升級方式 3.7 驗證安裝 第 4 章：核心 Skills 詳解 4.1 完整技能庫總覽 4.2 The Basic Workflow（7 步驟） 4.3 Brainstorming（需求釐清）+ Visual Companion 4.4 TDD — 測試驅動開發 4.5 Writing Plans（微步驟計畫）+ Document Review 4.6 Subagent-Driven Development（Subagent 分工開發） 4.7 Systematic Debugging（系統化除錯） 4.8 Git Worktrees（隔離開發環境） 4.9 其他重要技能 第 5 章：實戰開發流程（End-to-End） 5.1 開發流程總覽（The Basic Workflow） 5.2 完整範例：電商訂單結帳功能 5.3 流程時間線總覽 第 6 章：與企業系統整合 6.1 整合架構總覽 6.2 與 Spring Boot 整合 6.3 與微服務架構整合 6.4 與資料庫整合 6.5 與訊息佇列整合（Kafka / RabbitMQ） 6.6 與 API Gateway 整合 第 7 章：CI/CD 與 DevOps 7.1 CI/CD Pipeline 架構 7.2 GitHub Actions Workflow 7.3 SonarQube 品質控管 7.4 ArchUnit 架構測試 7.5 自動部署流程 第 8 章：系統維運（Maintenance） 8.1 AI 產出品質維持 8.2 技術債控制 8.3 Debug 流程標準化 8.4 Log / Monitoring 第 9 章：系統升級與版本管理 9.1 Superpowers 升級策略 9.2 Skills 版本控管（Plugin 架構） 9.3 相容性矩陣 9.4 完整版本歷程摘要 第 10 章：最佳實務（Best Practices） 10.1 AI 不可跳過測試 10.2 強制 Planning 10.3 小步提交 10.4 Clean Architecture 10.5 Subagent-Driven Development 最佳實務 10.6 Document Review System 最佳實務 第 11 章：反模式（Anti-patterns） 11.1 反模式總覽 11.2 開發反模式詳解 11.3 流程反模式詳解 11.4 組織反模式詳解 11.5 v5.0 新增反模式 第 12 章：企業導入策略 12.1 團隊導入路線圖 12.2 Governance（治理） 12.3 Code Review 機制 12.4 AI 使用規範 第 13 章：完整範例專案 13.1 專案概述 13.2 專案架構 13.3 範例程式碼 13.4 測試案例 13.5 開發流程示範 附錄 A：AI Agent Team 協作模式 附錄 B：與 MCP 整合 附錄 C：新進成員檢查清單（Checklist） 附錄 D：詞彙表 附錄 E：完整版本歷程摘要 附錄 F：v5.0.6 重大變更——Inline Self-Review 取代 Subagent Review Loops 附錄 G：v5.1.0 重大變更——Factory Droid、Worktree 重寫與 SDD 連續執行 附錄 H：v6.0.0 重大變更——SDD 審查重寫、Vendor-Neutral 與三新平台 附錄 I：v6.1.0／v6.1.1 重大變更——Gemini CLI 停止支援與 Codex 安裝優化 第 1 章：Superpowers 概述 章節摘要：本章介紹 Superpowers 的核心理念、與其他 AI 開發方法論的差異、支援平台、版本演進，以及它為企業團隊帶來的「工程紀律」價值。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/superpowers%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Superpowers 教學手冊（企業標準技術白皮書） 版本：v6.0｜基於：Superpowers Framework v6.1.1（by Jesse Vincent / obra @ Prime Radiant）\n最後更新：2026-07-23｜適用對象：資深工程師、Tech Lead、AI Agent 團隊｜語言：繁體中文\nGitHub：https://github.com/obra/superpowers ⭐ 260k stars · 23.2k forks · 36 Contributors\nPlugin Marketplace：https://claude.com/plugins/superpowers（Anthropic Verified · 885k+ installs）\nDiscord 社群：https://discord.gg/35wsABTejz\nCommercial Support：sales@primeradiant.com\nLicense：MIT\n目錄 第 1 章：Superpowers 概述 1.1 什麼是 Superpowers 1.2 與 Prompt Engineering / Agent Framework 的差異 1.3 適用場景 1.4 核心價值：工程紀律 1.5 支援平台總覽 1.6 版本演進歷程 第 2 章：整體系統架構設計 2.1 Superpowers 在 AI 開發架構中的位置 2.2 Plugin 架構與多平台支援 2.3 技能自動觸發機制 2.4 Hooks 系統 2.5 與 CI/CD 系統整合 2.6 整體技術堆疊 第 3 章：安裝與環境建置 3.1 前置要求 3.2 安裝步驟 3.3 專案初始化 3.4 建議目錄結構 3.5 Dev Container 配置（選用） 3.6 升級方式 3.7 驗證安裝 第 4 章：核心 Skills 詳解 4.1 完整技能庫總覽 4.2 The Basic Workflow（7 步驟） 4.3 Brainstorming（需求釐清）+ Visual Companion 4.4 TDD — 測試驅動開發 4.5 Writing Plans（微步驟計畫）+ Document Review 4.6 Subagent-Driven Development（Subagent 分工開發） 4.7 Systematic Debugging（系統化除錯） 4.8 Git Worktrees（隔離開發環境） 4.9 其他重要技能 第 5 章：實戰開發流程（End-to-End） 5.1 開發流程總覽（The Basic Workflow） 5.2 完整範例：電商訂單結帳功能 5.3 流程時間線總覽 第 6 章：與企業系統整合 6.1 整合架構總覽 6.2 與 Spring Boot 整合 6.3 與微服務架構整合 6.4 與資料庫整合 6.5 與訊息佇列整合（Kafka / RabbitMQ） 6.6 與 API Gateway 整合 第 7 章：CI/CD 與 DevOps 7.1 CI/CD Pipeline 架構 7.2 GitHub Actions Workflow 7.3 SonarQube 品質控管 7.4 ArchUnit 架構測試 7.5 自動部署流程 第 8 章：系統維運（Maintenance） 8.1 AI 產出品質維持 8.2 技術債控制 8.3 Debug 流程標準化 8.4 Log / Monitoring 第 9 章：系統升級與版本管理 9.1 Superpowers 升級策略 9.2 Skills 版本控管（Plugin 架構） 9.3 相容性矩陣 9.4 完整版本歷程摘要 第 10 章：最佳實務（Best Practices） 10.1 AI 不可跳過測試 10.2 強制 Planning 10.3 小步提交 10.4 Clean Architecture 10.5 Subagent-Driven Development 最佳實務 10.6 Document Review System 最佳實務 第 11 章：反模式（Anti-patterns） 11.1 反模式總覽 11.2 開發反模式詳解 11.3 流程反模式詳解 11.4 組織反模式詳解 11.5 v5.0 新增反模式 第 12 章：企業導入策略 12.1 團隊導入路線圖 12.2 Governance（治理） 12.3 Code Review 機制 12.4 AI 使用規範 第 13 章：完整範例專案 13.1 專案概述 13.2 專案架構 13.3 範例程式碼 13.4 測試案例 13.5 開發流程示範 附錄 A：AI Agent Team 協作模式 附錄 B：與 MCP 整合 附錄 C：新進成員檢查清單（Checklist） 附錄 D：詞彙表 附錄 E：完整版本歷程摘要 附錄 F：v5.0.6 重大變更——Inline Self-Review 取代 Subagent Review Loops 附錄 G：v5.1.0 重大變更——Factory Droid、Worktree 重寫與 SDD 連續執行 附錄 H：v6.0.0 重大變更——SDD 審查重寫、Vendor-Neutral 與三新平台 附錄 I：v6.1.0／v6.1.1 重大變更——Gemini CLI 停止支援與 Codex 安裝優化 第 1 章：Superpowers 概述 章節摘要：本章介紹 Superpowers 的核心理念、與其他 AI 開發方法論的差異、支援平台、版本演進，以及它為企業團隊帶來的「工程紀律」價值。\n","title":"Superpowers教學手冊"},{"content":"VS Code + GitHub Copilot 開發 Java Web 應用程式教學手冊(3) 版本：v3.0（2026-06-30）\n前版：v2.0（2026-03-27）\n適用對象：初學者 / 中階工程師 / 企業團隊\n技術棧：VS Code 1.126（2026-06-24 發布）· GitHub Copilot（含 Chat、Autopilot、Agent Mode、Agents Window、CLI Agent、Cloud Agent、Research Agent）· Java 21+ · Spring Boot 3.4.x · Maven\n定位：企業標準技術白皮書 — 可直接用於專案團隊內部開發規範文件\n變更說明：根據 VS Code 1.123–1.126 Release Notes、Agents Window、Autopilot、MCP OAuth、1M Context Window 等重大更新全面改版\n目錄 1. 總覽 1.1 VS Code 在 Java 開發的優勢 1.2 GitHub Copilot 在開發流程中的角色 1.3 VS Code 1.123–1.126 重要新功能摘要 1.4 VS Code vs IntelliJ 差異分析 2. 開發環境安裝與設定 2.1 必備工具 2.2 VS Code Extension 推薦 2.3 環境設定步驟 2.4 Copilot 自訂化設定 3. 建立第一個 Spring Boot 專案 3.1 使用 Spring Initializr 3.2 專案結構說明 3.3 執行與測試 API 3.4 使用整合式瀏覽器測試 Web 應用 4. GitHub Copilot 實戰應用 4.1 基本用法 — Inline Completion 與 Inline Chat 4.2 Copilot Chat 進階用法 4.3 Agent Mode 與 Autopilot 深度指南 4.4 Agents Window 與 Session 管理 4.5 Research Agent 深度研究 4.6 Prompt Engineering 4.7 MCP Server 整合 4.8 Custom Instructions / Agent Skills / Custom Agents 5. 專案架構設計（企業級） 5.1 Clean Architecture / Hexagonal Architecture 5.2 分層設計 5.3 DTO / VO / Entity 分離 6. 安全性與最佳實務 6.1 Spring Security 基本設定 6.2 API 驗證（JWT） 6.3 Copilot 生成程式碼的安全檢查 7. 測試與除錯 7.1 單元測試（JUnit 5） 7.2 API 測試 7.3 VS Code Debug 技巧 7.4 使用 Copilot 協助除錯 7.5 整合式瀏覽器 Agent 測試 8. CI/CD 與版本控管 8.1 Git 基本流程 8.2 GitHub Actions 基本 CI/CD 8.3 Copilot 協助產生 Pipeline 8.4 Cloud Agent 與 PR 協作（Preview） 9. 系統維護與升級 9.1 VS Code 更新策略 9.2 Extension 管理 9.3 Copilot 模型更新與成本管理 10. 團隊導入建議（企業級） 10.1 開發規範 10.2 Copilot 使用規範 10.3 Code Review 流程 10.4 AI 輔助開發治理 11. 常見問題與最佳解法（FAQ） 12. 附錄 12.1 常用指令速查表 12.2 範例 Prompt 清單 13. 檢查清單（Checklist） 1. 總覽 1.1 VS Code 在 Java 開發的優勢 VS Code 從輕量級編輯器發展至今，已成為企業級 Java 開發的主流選擇之一。主要優勢：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/vs-code-+-github-copilot-%E9%96%8B%E7%99%BC-java-web-%E6%87%89%E7%94%A8%E7%A8%8B%E5%BC%8F%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"VS Code + GitHub Copilot 開發 Java Web 應用程式教學手冊(3) 版本：v3.0（2026-06-30）\n前版：v2.0（2026-03-27）\n適用對象：初學者 / 中階工程師 / 企業團隊\n技術棧：VS Code 1.126（2026-06-24 發布）· GitHub Copilot（含 Chat、Autopilot、Agent Mode、Agents Window、CLI Agent、Cloud Agent、Research Agent）· Java 21+ · Spring Boot 3.4.x · Maven\n定位：企業標準技術白皮書 — 可直接用於專案團隊內部開發規範文件\n變更說明：根據 VS Code 1.123–1.126 Release Notes、Agents Window、Autopilot、MCP OAuth、1M Context Window 等重大更新全面改版\n目錄 1. 總覽 1.1 VS Code 在 Java 開發的優勢 1.2 GitHub Copilot 在開發流程中的角色 1.3 VS Code 1.123–1.126 重要新功能摘要 1.4 VS Code vs IntelliJ 差異分析 2. 開發環境安裝與設定 2.1 必備工具 2.2 VS Code Extension 推薦 2.3 環境設定步驟 2.4 Copilot 自訂化設定 3. 建立第一個 Spring Boot 專案 3.1 使用 Spring Initializr 3.2 專案結構說明 3.3 執行與測試 API 3.4 使用整合式瀏覽器測試 Web 應用 4. GitHub Copilot 實戰應用 4.1 基本用法 — Inline Completion 與 Inline Chat 4.2 Copilot Chat 進階用法 4.3 Agent Mode 與 Autopilot 深度指南 4.4 Agents Window 與 Session 管理 4.5 Research Agent 深度研究 4.6 Prompt Engineering 4.7 MCP Server 整合 4.8 Custom Instructions / Agent Skills / Custom Agents 5. 專案架構設計（企業級） 5.1 Clean Architecture / Hexagonal Architecture 5.2 分層設計 5.3 DTO / VO / Entity 分離 6. 安全性與最佳實務 6.1 Spring Security 基本設定 6.2 API 驗證（JWT） 6.3 Copilot 生成程式碼的安全檢查 7. 測試與除錯 7.1 單元測試（JUnit 5） 7.2 API 測試 7.3 VS Code Debug 技巧 7.4 使用 Copilot 協助除錯 7.5 整合式瀏覽器 Agent 測試 8. CI/CD 與版本控管 8.1 Git 基本流程 8.2 GitHub Actions 基本 CI/CD 8.3 Copilot 協助產生 Pipeline 8.4 Cloud Agent 與 PR 協作（Preview） 9. 系統維護與升級 9.1 VS Code 更新策略 9.2 Extension 管理 9.3 Copilot 模型更新與成本管理 10. 團隊導入建議（企業級） 10.1 開發規範 10.2 Copilot 使用規範 10.3 Code Review 流程 10.4 AI 輔助開發治理 11. 常見問題與最佳解法（FAQ） 12. 附錄 12.1 常用指令速查表 12.2 範例 Prompt 清單 13. 檢查清單（Checklist） 1. 總覽 1.1 VS Code 在 Java 開發的優勢 VS Code 從輕量級編輯器發展至今，已成為企業級 Java 開發的主流選擇之一。主要優勢：\n","title":"VS Code + GitHub Copilot 開發 Java Web 應用程式教學手冊(3)"},{"content":"使用 VS Code 與 GitHub Copilot 開發 Java Web 應用程式教學手冊(1) 版本：2026 年 6 月版（對應 VS Code 1.126）　|　適用對象：初中階 Java 開發人員　|　維護單位：資深架構師團隊\n目錄 前言與環境概述 1.1 為什麼選擇 VS Code + GitHub Copilot？ 1.2 技術棧總覽 1.3 學習路徑建議 安裝與環境設定 2.1 安裝 Java JDK 2.2 安裝 VS Code 2.3 安裝必要擴充套件 2.4 啟用 GitHub Copilot 2.5 VS Code 設定（settings.json） 專案建立與初始化 3.1 使用 Spring Initializr 建立專案 3.2 VS Code 開啟與結構說明 GitHub Copilot 核心功能使用 4.1 程式碼自動補全（Inline Suggestions） 4.2 Next Edit Suggestions（NES） 4.3 Copilot Chat 對話式開發 4.4 Agent Mode（代理模式） 4.5 使用 Inline Chat 4.6 自訂指令與 Prompt 檔案 4.7 MCP 伺服器整合 Java Web 開發實戰 5.1 建立 REST API Controller 5.2 Service 層與 Repository 層 5.3 連接資料庫（JPA + MySQL） 5.4 安全性設定（Spring Security） 除錯與測試 6.1 VS Code 除錯設定 6.2 單元測試與 Copilot 輔助 6.3 整合測試 系統維護與升級 7.1 相依套件版本管理 7.2 VS Code 與擴充套件升級 7.3 Java 版本升級指引 最佳實踐與團隊建議 8.1 Copilot 使用原則 8.2 程式碼品質規範 8.3 團隊協作建議 8.4 安全與信任控制 常見問題 FAQ 附錄：Prompt 參考範本 10.1 生成程式碼類 10.2 除錯與分析類 10.3 測試類 10.4 架構與設計類 1. 前言與環境概述 1.1 為什麼選擇 VS Code + GitHub Copilot？ Visual Studio Code 已發展為功能完備的開發平台，最新版本（1.126，2026 年 6 月發布）內建 AI Agent 功能，可直接在編輯器中以自然語言驅動開發流程。VS Code 搭配 GitHub Copilot 的 Agent Mode，開發者僅需描述任務意圖，Agent 便能自動規劃步驟、跨檔案編輯程式碼、執行終端命令並自我修正，直到任務完成。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/vscode_copilot_java_web_manual/","summary":"使用 VS Code 與 GitHub Copilot 開發 Java Web 應用程式教學手冊(1) 版本：2026 年 6 月版（對應 VS Code 1.126）　|　適用對象：初中階 Java 開發人員　|　維護單位：資深架構師團隊\n目錄 前言與環境概述 1.1 為什麼選擇 VS Code + GitHub Copilot？ 1.2 技術棧總覽 1.3 學習路徑建議 安裝與環境設定 2.1 安裝 Java JDK 2.2 安裝 VS Code 2.3 安裝必要擴充套件 2.4 啟用 GitHub Copilot 2.5 VS Code 設定（settings.json） 專案建立與初始化 3.1 使用 Spring Initializr 建立專案 3.2 VS Code 開啟與結構說明 GitHub Copilot 核心功能使用 4.1 程式碼自動補全（Inline Suggestions） 4.2 Next Edit Suggestions（NES） 4.3 Copilot Chat 對話式開發 4.4 Agent Mode（代理模式） 4.5 使用 Inline Chat 4.6 自訂指令與 Prompt 檔案 4.7 MCP 伺服器整合 Java Web 開發實戰 5.1 建立 REST API Controller 5.2 Service 層與 Repository 層 5.3 連接資料庫（JPA + MySQL） 5.4 安全性設定（Spring Security） 除錯與測試 6.1 VS Code 除錯設定 6.2 單元測試與 Copilot 輔助 6.3 整合測試 系統維護與升級 7.1 相依套件版本管理 7.2 VS Code 與擴充套件升級 7.3 Java 版本升級指引 最佳實踐與團隊建議 8.1 Copilot 使用原則 8.2 程式碼品質規範 8.3 團隊協作建議 8.4 安全與信任控制 常見問題 FAQ 附錄：Prompt 參考範本 10.1 生成程式碼類 10.2 除錯與分析類 10.3 測試類 10.4 架構與設計類 1. 前言與環境概述 1.1 為什麼選擇 VS Code + GitHub Copilot？ Visual Studio Code 已發展為功能完備的開發平台，最新版本（1.126，2026 年 6 月發布）內建 AI Agent 功能，可直接在編輯器中以自然語言驅動開發流程。VS Code 搭配 GitHub Copilot 的 Agent Mode，開發者僅需描述任務意圖，Agent 便能自動規劃步驟、跨檔案編輯程式碼、執行終端命令並自我修正，直到任務完成。\n","title":"Vscode_copilot_java_web_manual(1)"},{"content":"SonarQube 教學手冊 企業級 AI Coding Quality / Reverse Engineering / Framework Upgrade Validation / Secure SDLC / DevSecOps / Code Governance / AI Native Governance 全方位實戰教學\n📋 目錄 (Table of Contents) 第一部分：基礎概念與架構 SonarQube 概論 SonarQube 版本比較 SonarQube 系統架構 第二部分：安裝部署與設定 安裝與部署 SonarQube 設定 SonarScanner Quality Gate 第三部分：AI Coding 整合實戰 AI Coding 與 SonarQube Claude Code 整合實戰 GitHub Copilot 整合實戰 第四部分：SonarQube 原生 AI 治理與進階安全 SonarQube 原生 AI 治理 SonarQube Advanced Security 第五部分：Legacy 與升級治理 Legacy System 逆向工程 Framework Upgrade 第六部分：安全治理框架 SSDLC DevSecOps 第七部分：CI/CD 實戰整合 GitHub Actions 整合 GitLab CI/CD 整合 Jenkins 整合 第八部分：API 與維運 SonarQube API 維運管理 升級策略 第九部分：企業導入與案例 企業導入最佳實務 銀行級實戰案例 第十部分：FAQ、Prompt Library 與附錄 常見問題 FAQ Prompt Library 附錄 📖 文件說明 🎯 文件目標 本手冊將 SonarQube 定位為企業七大平台：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/sonarqube%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"SonarQube 教學手冊 企業級 AI Coding Quality / Reverse Engineering / Framework Upgrade Validation / Secure SDLC / DevSecOps / Code Governance / AI Native Governance 全方位實戰教學\n📋 目錄 (Table of Contents) 第一部分：基礎概念與架構 SonarQube 概論 SonarQube 版本比較 SonarQube 系統架構 第二部分：安裝部署與設定 安裝與部署 SonarQube 設定 SonarScanner Quality Gate 第三部分：AI Coding 整合實戰 AI Coding 與 SonarQube Claude Code 整合實戰 GitHub Copilot 整合實戰 第四部分：SonarQube 原生 AI 治理與進階安全 SonarQube 原生 AI 治理 SonarQube Advanced Security 第五部分：Legacy 與升級治理 Legacy System 逆向工程 Framework Upgrade 第六部分：安全治理框架 SSDLC DevSecOps 第七部分：CI/CD 實戰整合 GitHub Actions 整合 GitLab CI/CD 整合 Jenkins 整合 第八部分：API 與維運 SonarQube API 維運管理 升級策略 第九部分：企業導入與案例 企業導入最佳實務 銀行級實戰案例 第十部分：FAQ、Prompt Library 與附錄 常見問題 FAQ Prompt Library 附錄 📖 文件說明 🎯 文件目標 本手冊將 SonarQube 定位為企業七大平台：\n","title":"SonarQube教學手冊"},{"content":"codebase-memory-mcp 教學手冊 AI Coding Agent 知識圖譜引擎與超大型專案程式碼理解平台 文件版本控制表 項目 內容 文件版本 v1.1 撰寫/修訂日期 2026-06-25 依據官方專案版本 DeusData/codebase-memory-mcp v0.8.1（官方發布日 2026-06-12） 主要參考來源 官方 README／Releases／SECURITY.md、GitHub Pages 文件、論文 Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP（arXiv:2603.27277） 授權 codebase-memory-mcp 本體為 MIT License 開源專案 適用對象 系統分析師、系統架構師、軟體架構師、後端工程師、前端工程師、DevOps / DevSecOps 工程師、AI Engineer、Claude Code 使用者、GitHub Copilot 使用者、MCP 開發者 閱讀建議 本手冊偏向「實戰與維運」，建議依角色挑選章節 —— 架構師優先看第 2、3、20 章；導入負責人優先看第 19、22 章；第一線工程師優先看第 4～10 章；維運人員優先看第 16、17、18 章 v1.1 修訂摘要 對照官方 v0.8.1 補充環境變數、安裝參數、壓縮格式、安全機制（SLSA／cosign／CodeQL）細節；新增 Tree-sitter 語言分級、Leiden 社群偵測說明；對 ingest_traces 全文加註實驗性（Stub）警語；新增第 18 章已知限制小節；補充專案活躍度數據；目錄擴充為章/節兩層並修正簡體字與誤字 ⚠️ 時效性聲明：codebase-memory-mcp 為快速迭代的開源專案，本手冊內容以撰寫當下查證到的 v0.8.1 為準，使用前請以官方最新 Releases 與文件為最終依據，特別留意標註「實驗性／Stub」的功能是否已在更新版本中完整實作。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/codebase-memory-mcp-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"codebase-memory-mcp 教學手冊 AI Coding Agent 知識圖譜引擎與超大型專案程式碼理解平台 文件版本控制表 項目 內容 文件版本 v1.1 撰寫/修訂日期 2026-06-25 依據官方專案版本 DeusData/codebase-memory-mcp v0.8.1（官方發布日 2026-06-12） 主要參考來源 官方 README／Releases／SECURITY.md、GitHub Pages 文件、論文 Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP（arXiv:2603.27277） 授權 codebase-memory-mcp 本體為 MIT License 開源專案 適用對象 系統分析師、系統架構師、軟體架構師、後端工程師、前端工程師、DevOps / DevSecOps 工程師、AI Engineer、Claude Code 使用者、GitHub Copilot 使用者、MCP 開發者 閱讀建議 本手冊偏向「實戰與維運」，建議依角色挑選章節 —— 架構師優先看第 2、3、20 章；導入負責人優先看第 19、22 章；第一線工程師優先看第 4～10 章；維運人員優先看第 16、17、18 章 v1.1 修訂摘要 對照官方 v0.8.1 補充環境變數、安裝參數、壓縮格式、安全機制（SLSA／cosign／CodeQL）細節；新增 Tree-sitter 語言分級、Leiden 社群偵測說明；對 ingest_traces 全文加註實驗性（Stub）警語；新增第 18 章已知限制小節；補充專案活躍度數據；目錄擴充為章/節兩層並修正簡體字與誤字 ⚠️ 時效性聲明：codebase-memory-mcp 為快速迭代的開源專案，本手冊內容以撰寫當下查證到的 v0.8.1 為準，使用前請以官方最新 Releases 與文件為最終依據，特別留意標註「實驗性／Stub」的功能是否已在更新版本中完整實作。\n","title":"Codebase Memory Mcp 教學手冊"},{"content":"GitLab 與 GitLab CLI（glab）完整企業級教學手冊 本手冊以 2026 年最新版 GitLab（GitLab.com SaaS / GitLab Self-Managed / GitLab Dedicated）、GitLab CLI（glab）、GitLab Duo、GitLab CI/CD、GitLab Runner、GitLab Kubernetes Agent、GitLab Security、GitLab API、GitLab MCP Server 等官方文件與最佳實務為基礎撰寫，目標是讓初學者到資深架構師、DevOps / Platform / SRE 團隊都能在同一份文件中找到所需的知識與可直接複製貼上的操作指令。\n📌 使用建議：\n第一次接觸 GitLab 的同仁，建議依序閱讀第一章～第七章。 已熟悉 Git 的開發者，可直接從第四章（glab CLI）開始。 DevOps / Platform / SRE 團隊，請聚焦第八、十一、十九、二十章。 想了解 AI 協作開發（Claude Code、GitHub Copilot、MCP）的同仁，請見第十三～十八章。 本文件與既有的《GitLab使用教學.md》為獨立文件，內容不互相依賴，可單獨閱讀。 📖 目錄 💡 點擊章節可跳至本文對應位置；每個章節下方的子項為該章節的小節（##）連結。\n第一章 GitLab 介紹 1.1 GitLab 發展歷史 1.2 GitLab 核心理念 1.3 GitLab 與 GitHub 比較 1.4 GitLab 與 Azure DevOps 比較 1.5 GitLab 與 Bitbucket 比較 1.6 GitLab SaaS / Self-Managed / Dedicated 差異比較 第二章 GitLab 整體架構 2.1 端到端架構總覽 2.2 核心元件運作方式 2.3 GitLab Architecture Tiers（部署規模分級） 第三章 GitLab 安裝與部署 3.1 GitLab CE 與 EE 差異 3.2 Linux Package（Omnibus）安裝 — Ubuntu 3.3 Linux Package 安裝 — RHEL / Rocky Linux 3.4 Docker 安裝 3.5 Podman 安裝（Rootless） 3.6 Helm Chart（Kubernetes）安裝概覽 第四章 GitLab CLI（glab） 4.1 glab 是什麼 4.2 glab 架構 4.3 glab 主要功能分類 4.3.1 glab 指令穩定度分級（Stable / Beta / Experimental） 4.4 安裝 glab 4.5 登入與認證 第五章 GitLab CLI 指令大全 5.1 glab auth — 認證管理 5.2 glab repo — 專案管理 5.3 glab mr — Merge Request 5.4 glab issue — Issue 管理 5.5 glab pipeline 與 glab ci — CI/CD 操作 5.6 glab release — 版本發布 5.7 glab variable — CI/CD 變數管理 5.8 glab project — 專案層級設定 5.9 glab api — 通用 API 呼叫 5.10 glab duo — GitLab Duo AI 功能 5.11 glab mcp — 啟動 MCP Server 5.12 glab stack — Stacked Diff 管理 5.13 glab search — 跨專案搜尋 5.14 glab schedule — Pipeline 排程管理 5.15 glab runner — Runner 管理 5.16 glab orbit — Knowledge Graph 查詢 5.17 glab skills — Agent 技能管理 5.18 glab attestation — 軟體供應鏈驗證 5.19 glab cluster — Kubernetes Agent 管理 5.20 glab container-registry — 容器倉庫管理 5.21 glab incident — 事件管理 5.22 glab work-items — 統一規劃項目 5.23 其他工具型指令速查 第六章 GitLab Flow 6.1 三種主流分支策略比較 6.2 GitLab Flow 的兩種變體 6.3 企業建議 第七章 CI/CD 7.1 .gitlab-ci.yml 核心概念 7.2 Java / Spring Boot 完整 CI/CD 範例 7.3 Node.js / Vue 完整 CI/CD 範例 7.4 React 完整 CI/CD 範例 7.5 Python 完整 CI/CD 範例 7.6 include 拆分與共用範本 第八章 GitLab Runner 8.1 Runner 類型總覽 8.2 安裝 GitLab Runner 8.3 設定要點 8.4 維護、升級、故障排除 第九章 Container Registry 9.1 GitLab Container Registry 概念 9.2 基本操作 9.3 Image 掃描（Container Scanning） 9.4 Image Promotion（多環境晉升流程） 9.5 最佳實務 9.6 Container Virtual Registry（聚合上游倉庫） 9.7 多架構 Image 支援（Multi-Architecture） 第十章 Package Registry 10.1 支援的套件格式總覽 10.2 Maven 設定與發布 10.3 npm / pnpm 設定與發布 10.4 NuGet 發布 10.5 PyPI 發布 10.6 Generic Package（任意檔案） 第十一章 GitLab Security 11.1 GitLab 安全掃描總覽 11.2 SAST（靜態應用程式安全測試） 11.3 DAST（動態應用程式安全測試） 11.4 Dependency Scanning 11.4.1 AI 輔助安全：Agentic SAST 與 Duo 誤報偵測 11.5 Container Scanning 11.6 Secret Detection 11.7 License Compliance 11.8 Security Dashboard 與 Vulnerability Management 11.9 企業導入策略 第十二章 GitLab API 12.1 REST API 與 GraphQL API 選用建議 12.2 Access Token 種類 12.3 curl 範例 12.4 Java / Spring Boot 範例 12.5 Python 範例 12.6 TypeScript 範例 第十三章 GitLab Duo 13.1 GitLab Duo 功能總覽 13.2 GitLab Duo Chat 13.3 Code Suggestions（程式碼建議） 13.4 Code Review（MR 自動審查） 13.5 Vulnerability Explanation 13.6 Test Generation 與 Refactoring 13.7 Prompt Engineering 最佳實務 第十四章 GitLab + Claude Code 14.1 整合架構總覽 14.2 實戰案例：Claude Code 自動建立並提交 Merge Request 14.3 實戰案例：Claude Code 自動 Review 程式碼 14.4 實戰案例：Pipeline 失敗時自動診斷 14.5 CLAUDE.md 專案規範整合建議 第十五章 GitLab + GitHub Copilot 15.1 為什麼會在 GitLab 上使用 GitHub Copilot 15.2 Agent Mode 與 Coding Agent 操作模式 15.3 如何與 GitLab 協作（實務整合建議） 第十六章 GitLab + MCP 16.1 Model Context Protocol 簡介 16.2 GitLab MCP Server 現況與安裝 16.3 設定 Claude Code 連接 GitLab MCP Server 16.4 權限管理 16.5 實際案例：多步驟 Agent 工作流程 16.6 GitLab Orbit（Knowledge Graph）與 AI Agent 第十七章 AI 協助 Legacy System 逆向工程 17.1 為什麼 Legacy System 逆向工程適合導入 AI 17.2 實戰步驟：將 Legacy 程式碼匯入 GitLab 並建立分析基線 17.3 實戰案例：AI Agent 自動分析 Legacy System 17.4 各 Legacy 技術的 AI 逆向工程要點 17.5 文件生成與架構分析範本 17.6 逆向工程後的重構規劃 第十八章 Framework 升級專案 18.1 升級專案的 GitLab 治理框架 18.2 Spring Boot 2 → 3 / Java 8 → 21 實戰流程 18.3 Vue2 → Vue3 升級實戰流程 18.4 Angular 升級實戰流程 18.5 升級專案的企業治理建議 第十九章 大型企業 DevSecOps 平台設計 19.1 依規模分級的架構設計原則 19.2 大型企業架構圖 19.3 權限模型設計 19.4 Group 策略與 Project 策略 19.5 Branch 策略 第二十章 GitLab 維運手冊 20.1 備份與還原 20.2 監控（Prometheus + Grafana） 20.3 Logging 20.4 升級 20.5 高可用性（HA）與災難復原（DR） 第二十一章 GitLab 最佳實務 21.1 命名規範 21.2 Branch Strategy 21.3 MR Strategy 21.4 Pipeline Strategy 21.5 Release Strategy 21.6 Security Strategy 第二十二章 常見問題 FAQ 22.1 開發類 22.2 CI/CD 類 22.3 Security 類 22.4 Runner 類 22.5 Kubernetes 類 22.6 AI 類 22.7 GitLab Duo 類 22.8 glab 類 第二十三章 附錄 23.1 常用 glab 指令速查表 23.2 CI/CD 通用範本 23.3 Spring Boot 範本 23.4 Vue3 範本 23.5 Kubernetes 範本 23.6 Docker 範本（多階段建置） 23.7 Helm 範本 23.8 十大 AI Agent 實戰情境總覽 23.9 企業導入檢查清單 第一章 GitLab 介紹 1.1 GitLab 發展歷史 GitLab 最初由 Dmitriy Zaporozhets 與 Valery Sizov 於 2011 年以 Ruby on Rails 開發，作為一套開源的 Git 版本控制管理工具。早期僅是「GitHub 的開源替代品」，但 GitLab 團隊很快意識到軟體交付不只是「管程式碼」，而是一個從規劃、開發、測試、安全掃描、部署到監控的完整生命週期。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/gitlab-and-gitlab-cli-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitLab 與 GitLab CLI（glab）完整企業級教學手冊 本手冊以 2026 年最新版 GitLab（GitLab.com SaaS / GitLab Self-Managed / GitLab Dedicated）、GitLab CLI（glab）、GitLab Duo、GitLab CI/CD、GitLab Runner、GitLab Kubernetes Agent、GitLab Security、GitLab API、GitLab MCP Server 等官方文件與最佳實務為基礎撰寫，目標是讓初學者到資深架構師、DevOps / Platform / SRE 團隊都能在同一份文件中找到所需的知識與可直接複製貼上的操作指令。\n📌 使用建議：\n第一次接觸 GitLab 的同仁，建議依序閱讀第一章～第七章。 已熟悉 Git 的開發者，可直接從第四章（glab CLI）開始。 DevOps / Platform / SRE 團隊，請聚焦第八、十一、十九、二十章。 想了解 AI 協作開發（Claude Code、GitHub Copilot、MCP）的同仁，請見第十三～十八章。 本文件與既有的《GitLab使用教學.md》為獨立文件，內容不互相依賴，可單獨閱讀。 📖 目錄 💡 點擊章節可跳至本文對應位置；每個章節下方的子項為該章節的小節（##）連結。\n第一章 GitLab 介紹 1.1 GitLab 發展歷史 1.2 GitLab 核心理念 1.3 GitLab 與 GitHub 比較 1.4 GitLab 與 Azure DevOps 比較 1.5 GitLab 與 Bitbucket 比較 1.6 GitLab SaaS / Self-Managed / Dedicated 差異比較 第二章 GitLab 整體架構 2.1 端到端架構總覽 2.2 核心元件運作方式 2.3 GitLab Architecture Tiers（部署規模分級） 第三章 GitLab 安裝與部署 3.1 GitLab CE 與 EE 差異 3.2 Linux Package（Omnibus）安裝 — Ubuntu 3.3 Linux Package 安裝 — RHEL / Rocky Linux 3.4 Docker 安裝 3.5 Podman 安裝（Rootless） 3.6 Helm Chart（Kubernetes）安裝概覽 第四章 GitLab CLI（glab） 4.1 glab 是什麼 4.2 glab 架構 4.3 glab 主要功能分類 4.3.1 glab 指令穩定度分級（Stable / Beta / Experimental） 4.4 安裝 glab 4.5 登入與認證 第五章 GitLab CLI 指令大全 5.1 glab auth — 認證管理 5.2 glab repo — 專案管理 5.3 glab mr — Merge Request 5.4 glab issue — Issue 管理 5.5 glab pipeline 與 glab ci — CI/CD 操作 5.6 glab release — 版本發布 5.7 glab variable — CI/CD 變數管理 5.8 glab project — 專案層級設定 5.9 glab api — 通用 API 呼叫 5.10 glab duo — GitLab Duo AI 功能 5.11 glab mcp — 啟動 MCP Server 5.12 glab stack — Stacked Diff 管理 5.13 glab search — 跨專案搜尋 5.14 glab schedule — Pipeline 排程管理 5.15 glab runner — Runner 管理 5.16 glab orbit — Knowledge Graph 查詢 5.17 glab skills — Agent 技能管理 5.18 glab attestation — 軟體供應鏈驗證 5.19 glab cluster — Kubernetes Agent 管理 5.20 glab container-registry — 容器倉庫管理 5.21 glab incident — 事件管理 5.22 glab work-items — 統一規劃項目 5.23 其他工具型指令速查 第六章 GitLab Flow 6.1 三種主流分支策略比較 6.2 GitLab Flow 的兩種變體 6.3 企業建議 第七章 CI/CD 7.1 .gitlab-ci.yml 核心概念 7.2 Java / Spring Boot 完整 CI/CD 範例 7.3 Node.js / Vue 完整 CI/CD 範例 7.4 React 完整 CI/CD 範例 7.5 Python 完整 CI/CD 範例 7.6 include 拆分與共用範本 第八章 GitLab Runner 8.1 Runner 類型總覽 8.2 安裝 GitLab Runner 8.3 設定要點 8.4 維護、升級、故障排除 第九章 Container Registry 9.1 GitLab Container Registry 概念 9.2 基本操作 9.3 Image 掃描（Container Scanning） 9.4 Image Promotion（多環境晉升流程） 9.5 最佳實務 9.6 Container Virtual Registry（聚合上游倉庫） 9.7 多架構 Image 支援（Multi-Architecture） 第十章 Package Registry 10.1 支援的套件格式總覽 10.2 Maven 設定與發布 10.3 npm / pnpm 設定與發布 10.4 NuGet 發布 10.5 PyPI 發布 10.6 Generic Package（任意檔案） 第十一章 GitLab Security 11.1 GitLab 安全掃描總覽 11.2 SAST（靜態應用程式安全測試） 11.3 DAST（動態應用程式安全測試） 11.4 Dependency Scanning 11.4.1 AI 輔助安全：Agentic SAST 與 Duo 誤報偵測 11.5 Container Scanning 11.6 Secret Detection 11.7 License Compliance 11.8 Security Dashboard 與 Vulnerability Management 11.9 企業導入策略 第十二章 GitLab API 12.1 REST API 與 GraphQL API 選用建議 12.2 Access Token 種類 12.3 curl 範例 12.4 Java / Spring Boot 範例 12.5 Python 範例 12.6 TypeScript 範例 第十三章 GitLab Duo 13.1 GitLab Duo 功能總覽 13.2 GitLab Duo Chat 13.3 Code Suggestions（程式碼建議） 13.4 Code Review（MR 自動審查） 13.5 Vulnerability Explanation 13.6 Test Generation 與 Refactoring 13.7 Prompt Engineering 最佳實務 第十四章 GitLab + Claude Code 14.1 整合架構總覽 14.2 實戰案例：Claude Code 自動建立並提交 Merge Request 14.3 實戰案例：Claude Code 自動 Review 程式碼 14.4 實戰案例：Pipeline 失敗時自動診斷 14.5 CLAUDE.md 專案規範整合建議 第十五章 GitLab + GitHub Copilot 15.1 為什麼會在 GitLab 上使用 GitHub Copilot 15.2 Agent Mode 與 Coding Agent 操作模式 15.3 如何與 GitLab 協作（實務整合建議） 第十六章 GitLab + MCP 16.1 Model Context Protocol 簡介 16.2 GitLab MCP Server 現況與安裝 16.3 設定 Claude Code 連接 GitLab MCP Server 16.4 權限管理 16.5 實際案例：多步驟 Agent 工作流程 16.6 GitLab Orbit（Knowledge Graph）與 AI Agent 第十七章 AI 協助 Legacy System 逆向工程 17.1 為什麼 Legacy System 逆向工程適合導入 AI 17.2 實戰步驟：將 Legacy 程式碼匯入 GitLab 並建立分析基線 17.3 實戰案例：AI Agent 自動分析 Legacy System 17.4 各 Legacy 技術的 AI 逆向工程要點 17.5 文件生成與架構分析範本 17.6 逆向工程後的重構規劃 第十八章 Framework 升級專案 18.1 升級專案的 GitLab 治理框架 18.2 Spring Boot 2 → 3 / Java 8 → 21 實戰流程 18.3 Vue2 → Vue3 升級實戰流程 18.4 Angular 升級實戰流程 18.5 升級專案的企業治理建議 第十九章 大型企業 DevSecOps 平台設計 19.1 依規模分級的架構設計原則 19.2 大型企業架構圖 19.3 權限模型設計 19.4 Group 策略與 Project 策略 19.5 Branch 策略 第二十章 GitLab 維運手冊 20.1 備份與還原 20.2 監控（Prometheus + Grafana） 20.3 Logging 20.4 升級 20.5 高可用性（HA）與災難復原（DR） 第二十一章 GitLab 最佳實務 21.1 命名規範 21.2 Branch Strategy 21.3 MR Strategy 21.4 Pipeline Strategy 21.5 Release Strategy 21.6 Security Strategy 第二十二章 常見問題 FAQ 22.1 開發類 22.2 CI/CD 類 22.3 Security 類 22.4 Runner 類 22.5 Kubernetes 類 22.6 AI 類 22.7 GitLab Duo 類 22.8 glab 類 第二十三章 附錄 23.1 常用 glab 指令速查表 23.2 CI/CD 通用範本 23.3 Spring Boot 範本 23.4 Vue3 範本 23.5 Kubernetes 範本 23.6 Docker 範本（多階段建置） 23.7 Helm 範本 23.8 十大 AI Agent 實戰情境總覽 23.9 企業導入檢查清單 第一章 GitLab 介紹 1.1 GitLab 發展歷史 GitLab 最初由 Dmitriy Zaporozhets 與 Valery Sizov 於 2011 年以 Ruby on Rails 開發，作為一套開源的 Git 版本控制管理工具。早期僅是「GitHub 的開源替代品」，但 GitLab 團隊很快意識到軟體交付不只是「管程式碼」，而是一個從規劃、開發、測試、安全掃描、部署到監控的完整生命週期。\n","title":"Gitlab and Gitlab Cli 教學手冊"},{"content":"Eve 教學手冊 Vercel Eve Agent Framework × PM Skills 企業整合架構完整指南 適用對象：資深工程師、AI Agent 平台團隊、架構師、DevOps / SSDLC 負責人 文件性質：企業內部 AI Agent 平台導入與培訓教材\n目錄 第 1 章 Eve 是什麼 第 2 章 Eve 核心設計理念 第 3 章 Eve 系統架構解析 第 4 章 Eve 目錄結構 第 5 章 Eve 核心元件 第 6 章 Eve 執行流程 第 7 章 Eve 安裝教學 第 8 章 建立第一個 Eve Agent 第 9 章 Agent 開發實戰 第 10 章 Skills 開發教學 第 11 章 PM Skills 與 Eve 整合 第 12 章 使用 Eve 開發 Web Application 第 13 章 使用 Eve 執行 Reverse Engineering 第 14 章 使用 Eve 執行 Framework Upgrade 第 15 章 Subagents 設計模式 第 16 章 Human Approval 設計 第 17 章 Eve 與 MCP 整合 第 18 章 Eve 與 Claude Code 整合 第 19 章 Eve 與 GitHub Copilot 整合 第 20 章 Eve 與企業 SSDLC 整合 第 21 章 Eve 生產環境部署 第 22 章 Eve 可觀測性 第 23 章 Eve 安全設計 第 24 章 Eve 效能優化 第 25 章 Eve 開發規範 第 26 章 Eve 常見問題 FAQ 第 27 章 Eve 最佳實務 第 28 章 Eve 常見反模式 第 29 章 Eve Roadmap 分析 第 30 章 結論 附錄 A 完整 Weather Agent 範例 附錄 B PM Skills + Eve 整合範本 附錄 C Mermaid 圖總覽索引 附錄 D 檢查清單（Checklist） 第 1 章 Eve 是什麼 本章小節導覽：1.1 Eve 誕生背景 · 1.2 為何 Vercel 開發 Eve · 1.3 Agent Framework 發展歷史 · 1.4 與 LangGraph 的差異 · 1.5 與 CrewAI 的差異 · 1.6 與 OpenAI Agents SDK 的差異 · 1.7 與 AutoGen 的差異 · 1.8 與 Semantic Kernel 的差異 · 1.9 與 Mastra 的差異 · 1.10 與 PydanticAI 的差異 · 1.11 為何 Eve 被稱為「Agent 世界的 Next.js」\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/eve-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Eve 教學手冊 Vercel Eve Agent Framework × PM Skills 企業整合架構完整指南 適用對象：資深工程師、AI Agent 平台團隊、架構師、DevOps / SSDLC 負責人 文件性質：企業內部 AI Agent 平台導入與培訓教材\n目錄 第 1 章 Eve 是什麼 第 2 章 Eve 核心設計理念 第 3 章 Eve 系統架構解析 第 4 章 Eve 目錄結構 第 5 章 Eve 核心元件 第 6 章 Eve 執行流程 第 7 章 Eve 安裝教學 第 8 章 建立第一個 Eve Agent 第 9 章 Agent 開發實戰 第 10 章 Skills 開發教學 第 11 章 PM Skills 與 Eve 整合 第 12 章 使用 Eve 開發 Web Application 第 13 章 使用 Eve 執行 Reverse Engineering 第 14 章 使用 Eve 執行 Framework Upgrade 第 15 章 Subagents 設計模式 第 16 章 Human Approval 設計 第 17 章 Eve 與 MCP 整合 第 18 章 Eve 與 Claude Code 整合 第 19 章 Eve 與 GitHub Copilot 整合 第 20 章 Eve 與企業 SSDLC 整合 第 21 章 Eve 生產環境部署 第 22 章 Eve 可觀測性 第 23 章 Eve 安全設計 第 24 章 Eve 效能優化 第 25 章 Eve 開發規範 第 26 章 Eve 常見問題 FAQ 第 27 章 Eve 最佳實務 第 28 章 Eve 常見反模式 第 29 章 Eve Roadmap 分析 第 30 章 結論 附錄 A 完整 Weather Agent 範例 附錄 B PM Skills + Eve 整合範本 附錄 C Mermaid 圖總覽索引 附錄 D 檢查清單（Checklist） 第 1 章 Eve 是什麼 本章小節導覽：1.1 Eve 誕生背景 · 1.2 為何 Vercel 開發 Eve · 1.3 Agent Framework 發展歷史 · 1.4 與 LangGraph 的差異 · 1.5 與 CrewAI 的差異 · 1.6 與 OpenAI Agents SDK 的差異 · 1.7 與 AutoGen 的差異 · 1.8 與 Semantic Kernel 的差異 · 1.9 與 Mastra 的差異 · 1.10 與 PydanticAI 的差異 · 1.11 為何 Eve 被稱為「Agent 世界的 Next.js」\n","title":"Eve 教學手冊"},{"content":"PM Skills 教學手冊（企業級 AI Native Product Management 實戰指南） 版本：v1.1.0 更新日期：2026-06-23 適用對象：資深工程師、Tech Lead、產品經理（PM）、架構師、DevOps / SSDLC 負責人 技術棧：Claude Code、Claude Cowork、Cursor、Gemini CLI、Codex CLI、OpenCode、Kiro、Spring Boot、Java、Vue 3 資料來源：phuryn/pm-skills（PM Skills Marketplace，MIT License，由 The Product Compass Newsletter 作者 Paweł Huryn 維護） 查證說明：本手冊內容已對照 repo 當前版本 v2.0.0（2026-06-05 發布，主分支最後提交至 2026-06-22）重新查證並整理編寫，非官方文件之複製。截至查證時，repo 實際包含 9 個 Plugin、68 個 Skills、42 個串接式 Commands——這與部分網路上流傳「八大 Plugin」的說法不同（缺少 pm-ai-shipping），本手冊以實際查證結果為準。另外，repo 首頁標語使用「100+ agentic skills, commands, and plugins」字樣，是把 68 個 Skills 與 42 個 Commands 合計（約 110）後的行銷性概數，並非 Skill 數量本身被誇大，本手冊內文一律採用精確數字 68 / 42 / 9。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/pm-skills%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"PM Skills 教學手冊（企業級 AI Native Product Management 實戰指南） 版本：v1.1.0 更新日期：2026-06-23 適用對象：資深工程師、Tech Lead、產品經理（PM）、架構師、DevOps / SSDLC 負責人 技術棧：Claude Code、Claude Cowork、Cursor、Gemini CLI、Codex CLI、OpenCode、Kiro、Spring Boot、Java、Vue 3 資料來源：phuryn/pm-skills（PM Skills Marketplace，MIT License，由 The Product Compass Newsletter 作者 Paweł Huryn 維護） 查證說明：本手冊內容已對照 repo 當前版本 v2.0.0（2026-06-05 發布，主分支最後提交至 2026-06-22）重新查證並整理編寫，非官方文件之複製。截至查證時，repo 實際包含 9 個 Plugin、68 個 Skills、42 個串接式 Commands——這與部分網路上流傳「八大 Plugin」的說法不同（缺少 pm-ai-shipping），本手冊以實際查證結果為準。另外，repo 首頁標語使用「100+ agentic skills, commands, and plugins」字樣，是把 68 個 Skills 與 42 個 Commands 合計（約 110）後的行銷性概數，並非 Skill 數量本身被誇大，本手冊內文一律採用精確數字 68 / 42 / 9。\n","title":"Pm Skills教學手冊"},{"content":"SkillSpector 教學手冊 版本：v1.1（2026-06-22） 適用對象：AI Security Specialist、AI Agent 架構師、DevSecOps 工程師、軟體架構師、全端工程師、逆向工程專家、CI/CD 與 GitHub Security 工程師 內容定位：本手冊聚焦於 NVIDIA 開源專案 SkillSpector（github.com/NVIDIA/SkillSpector）——一套在 AI Agent Skill／MCP Server 安裝前進行安全掃描的工具——的核心理念、系統架構、安裝設定、掃描實戰，並延伸至企業級 DevSecOps 導入（CI/CD Gate、SARIF、治理藍圖、產業導入建議） 重要聲明：本手冊第 1～8、12 章之工具行為描述（CLI 指令、設定項、64 項檢測規則 16 大類別、風險評分公式、SARIF 輸出、架構模組名稱）基於 SkillSpector 官方 GitHub Repository 原始碼與 README.md、Makefile、pyproject.toml 逐項核對後整理改寫而成，並非逐字翻譯；少數官方來源未能逐項驗證的細節（如 LLM 階段精確度量化數字、model_registry.yaml 機制、OPENAI_BASE_URL 變數）已在對應段落明確標註「待以實際版本驗證」，不作斷言。第 1.1、1.3、2.0 節額外引用之外部研究與公告（arXiv:2601.10338、arXiv:2602.06547、Anthropic Agent Skills 官方公告、Snyk／Datadog／Repello 等資安社群報導）均為可公開查證之獨立來源，用於補強背景論述深度，非 SkillSpector 官方數據。第 9～11、13～20 章（GitLab CI／Jenkins／Azure DevOps 範例、企業導入架構、產業導入建議、治理藍圖、FAQ、Troubleshooting）為「企業實務延伸」內容，是顧問觀點下將 SkillSpector 套用於企業 DevSecOps 流程的建議做法，並非 NVIDIA 官方功能宣稱或官方範例，文中會明確標註。GitHub 社群數據（Star／Fork 數）反映查詢當下時間點，會隨時間持續變動，實際導入前請以官方 Repository 當下版本為準。 授權：內部教育訓練使用\n如何使用本手冊 SkillSpector 解決的是一個正在快速擴大的問題：AI Coding Agent（Claude Code、GitHub Copilot、Gemini CLI、Cursor、Codex 等）的「Skill／Plugin／Extension」生態系正在爆炸性成長，但這些第三方 Skill 以 Agent 的完整權限執行，卻幾乎沒有安全審查機制。NVIDIA 針對 42,447 個公開 Skill 的研究顯示，26.1% 含有至少一項漏洞，5.2% 疑似具惡意意圖。SkillSpector 就是為了在「安裝 Skill」與「執行 Skill」之間，插入一道自動化的安全關卡。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/skillspector-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"SkillSpector 教學手冊 版本：v1.1（2026-06-22） 適用對象：AI Security Specialist、AI Agent 架構師、DevSecOps 工程師、軟體架構師、全端工程師、逆向工程專家、CI/CD 與 GitHub Security 工程師 內容定位：本手冊聚焦於 NVIDIA 開源專案 SkillSpector（github.com/NVIDIA/SkillSpector）——一套在 AI Agent Skill／MCP Server 安裝前進行安全掃描的工具——的核心理念、系統架構、安裝設定、掃描實戰，並延伸至企業級 DevSecOps 導入（CI/CD Gate、SARIF、治理藍圖、產業導入建議） 重要聲明：本手冊第 1～8、12 章之工具行為描述（CLI 指令、設定項、64 項檢測規則 16 大類別、風險評分公式、SARIF 輸出、架構模組名稱）基於 SkillSpector 官方 GitHub Repository 原始碼與 README.md、Makefile、pyproject.toml 逐項核對後整理改寫而成，並非逐字翻譯；少數官方來源未能逐項驗證的細節（如 LLM 階段精確度量化數字、model_registry.yaml 機制、OPENAI_BASE_URL 變數）已在對應段落明確標註「待以實際版本驗證」，不作斷言。第 1.1、1.3、2.0 節額外引用之外部研究與公告（arXiv:2601.10338、arXiv:2602.06547、Anthropic Agent Skills 官方公告、Snyk／Datadog／Repello 等資安社群報導）均為可公開查證之獨立來源，用於補強背景論述深度，非 SkillSpector 官方數據。第 9～11、13～20 章（GitLab CI／Jenkins／Azure DevOps 範例、企業導入架構、產業導入建議、治理藍圖、FAQ、Troubleshooting）為「企業實務延伸」內容，是顧問觀點下將 SkillSpector 套用於企業 DevSecOps 流程的建議做法，並非 NVIDIA 官方功能宣稱或官方範例，文中會明確標註。GitHub 社群數據（Star／Fork 數）反映查詢當下時間點，會隨時間持續變動，實際導入前請以官方 Repository 當下版本為準。 授權：內部教育訓練使用\n如何使用本手冊 SkillSpector 解決的是一個正在快速擴大的問題：AI Coding Agent（Claude Code、GitHub Copilot、Gemini CLI、Cursor、Codex 等）的「Skill／Plugin／Extension」生態系正在爆炸性成長，但這些第三方 Skill 以 Agent 的完整權限執行，卻幾乎沒有安全審查機制。NVIDIA 針對 42,447 個公開 Skill 的研究顯示，26.1% 含有至少一項漏洞，5.2% 疑似具惡意意圖。SkillSpector 就是為了在「安裝 Skill」與「執行 Skill」之間，插入一道自動化的安全關卡。\n","title":"SkillSpector 教學手冊"},{"content":"Ponytail 教學手冊 版本：v1.1（2026-06-22，已對照官方 Repository 原始檔案逐章核實修訂） 適用對象：系統分析師、軟體架構師、後端工程師、前端工程師、DevOps工程師、SRE工程師、AI工程師、企業資訊部門、Framework維護團隊、Legacy System維護團隊 內容定位：本手冊聚焦於開源 AI Agent 精簡化技能（Skill）Ponytail 的理念、架構、安裝設定、與主流 AI Coding Agent（Claude Code / GitHub Copilot / Cursor / Codex / Gemini CLI 等共 14 個受支援平台）的整合方式，並延伸至企業級開發流程（SSDLC、多 Agent 團隊協作、Legacy 逆向工程、Framework 升級）的實務導入 重要聲明：本手冊第 1～12、15 章內容基於 Ponytail 官方 GitHub Repository（DietrichGebert/ponytail）之 README.md、AGENTS.md、skills/ponytail/SKILL.md、skills/ponytail-review/SKILL.md、docs/agent-portability.md、docs/platform-native.md 等公開資料，逐項核對原文後整理改寫而成（非逐字抄錄）；第 13、14、16、20 章為「企業實務延伸」章節，是顧問觀點下將 Ponytail 精簡哲學套用於企業開發治理的建議做法，並非 Ponytail 官方功能宣稱，文中會明確標註。GitHub 社群數據（Star／Fork／Issue 數）反映查詢當下時間點，會隨時間持續變動 授權：內部教育訓練使用\n如何使用本手冊 Ponytail 不是一個框架，也不是一個 IDE，而是一套注入到 AI Coding Agent 的行為準則（Skill / Plugin）。它的任務很單純：在 AI Agent 動手寫程式之前，先逼它像一個「已經看過太多過度設計專案、留著馬尾、戴著圓框眼鏡的資深工程師」一樣，先問一句「這真的需要寫嗎？」。本手冊依角色整理出建議閱讀路徑：\n角色 建議優先閱讀章節 新進工程師 第1、3、5、6章 後端／前端工程師 第7、8、9、10章 架構師／系統分析師 第2、4、11、12章 DevOps／SRE 第6、7、19章 AI Coding Agent 重度使用者 第4、5、15、17、18章 企業資訊部門主管 第13、14、16、20章 Legacy System維護團隊 第11、12章 Code Review／品質把關者 第9、17、18章 目錄 第 1 章 Ponytail 概述 1.1 專案背景 1.2 作者介紹 1.3 發展歷程與版本里程碑 1.4 GitHub 社群狀況 1.5 為何爆紅 1.6 解決哪些問題 第 2 章 AI Coding Agent 常見問題 2.1 Over Engineering 2.2 Reinvent The Wheel 2.3 Token Waste 2.4 Context Pollution 2.5 Hallucination Driven Design 2.6 Framework Ignorance 2.7 Existing Code Ignorance 2.8 Legacy System Rewrite Syndrome 2.9 案例分析總表 第 3 章 Ponytail 核心理念 3.1 Lazy Senior Developer Mindset 3.2 Less Code Principle 3.3 Existing Solution First 3.4 Delete Before Build 3.5 Native Feature First 3.6 Library Before Custom Code 3.7 Configuration Before Programming 3.8 Simplicity First 3.9 Maintainability First 3.10 Cost Awareness 第 4 章 Ponytail 系統架構 4.1 Architecture Overview 4.2 Skill Architecture 4.3 Agent Workflow 4.4 Review Loop 4.5 Self Critique Loop 4.6 Decision Flow 4.7 Prompt Enhancement Flow 4.8 Integration Flow 第 5 章 Ponytail 工作原理 5.1 第一階：這個功能真的需要存在嗎（YAGNI） 5.2 第二階：標準函式庫能解決嗎 5.3 第三階：平台原生功能能解決嗎 5.4 第四階：已安裝的相依套件能解決嗎 5.5 第五階：能用一行寫完嗎 5.6 第六階：只寫最小可行實作 5.7 企業實務延伸：刪除與精簡思維（呼應 ponytail-review） 5.8 內部思考流程整合範例 第 6 章 安裝與部署 6.1 Claude Code 6.2 GitHub Copilot 6.3 Cursor 6.4 OpenAI Codex／Agent 6.5 Gemini CLI 6.6 VS Code 整合 6.7 JetBrains 整合 6.8 Pi Agent Harness 6.9 OpenCode 6.10 CodeWhale 6.11 OpenClaw 6.12 Kiro 6.13 系統需求 第 7 章 Ponytail 設定說明 7.1 Agent Configuration 7.2 Rules 7.3 Skills 7.4 Context 7.5 Hooks 7.6 Templates 7.7 Review Policies 7.8 Team Standards 第 8 章 與 Claude Code 整合 8.1 Agent Skill 8.2 Custom Instructions 8.3 Commands 8.4 Workflows 8.5 Best Practices 8.6 Enterprise Standards 第 9 章 與 GitHub Copilot 整合 9.1 Copilot Agent 9.2 Copilot Coding Agent 9.3 Repository Instructions 9.4 Prompt Files 9.5 Agent Files 9.6 Skills 9.7 完整範例 第 10 章 Web Application 開發實戰 10.1 技術棧總覽 10.2 API 開發 10.3 CRUD 開發 10.4 Batch 開發 10.5 Security 開發 10.6 Integration 開發 10.7 Ponytail 如何減少程式碼 第 11 章 Legacy System Reverse Engineering 11.1 Mainframe 11.2 COBOL 11.3 Lotus Domino 11.4 Struts 11.5 JSF 11.6 舊版 Spring 11.7 WebSphere 11.8 WebLogic 11.9 Ponytail 在逆向工程中的角色與限制 第 12 章 Framework Upgrade 實戰 12.1 Spring Boot 2 到 3 12.2 Java 8 到 21 12.3 Vue2 到 Vue3 12.4 Jakarta Migration 12.5 JDK Upgrade 12.6 Dependency Upgrade 12.7 降低升級成本的具體做法 第 13 章 與 SSDLC 整合（企業實務延伸） 13.1 定位澄清：Ponytail 不是安全工具 13.2 Threat Modeling 13.3 SAST 13.4 DAST 13.5 Dependency Check 13.6 Secret Detection 13.7 Secure Coding 13.8 Compliance 13.9 Audit 第 14 章 與 AI Agent 團隊整合（企業實務延伸） 14.1 多 Agent 團隊架構總覽 14.2 Planner Agent 14.3 Architect Agent 14.4 Developer Agent 14.5 Reviewer Agent 14.6 Security Agent 14.7 QA Agent 14.8 Release Agent 14.9 Ponytail 在團隊中的角色 第 15 章 Token Optimization 15.1 Token Reduction 15.2 Context Reduction 15.3 Prompt Compression 15.4 Reuse Existing Logic 15.5 Knowledge Reuse 15.6 Memory Optimization 15.7 實際數據案例 第 16 章 企業導入指南（企業實務延伸） 16.1 Governance 16.2 Standards 16.3 Team Adoption 16.4 Change Management 16.5 Training Plan 16.6 KPI 16.7 ROI 第 17 章 最佳實務 第 18 章 常見錯誤 第 19 章 維運與升級 19.1 Version Upgrade 19.2 Skill Upgrade 19.3 Agent Upgrade 19.4 Prompt Upgrade 19.5 Governance Upgrade 第 20 章 完整企業導入範例（企業實務延伸） 20.1 案例背景：大型銀行共用平台 20.2 開發流程 20.3 Code Review 20.4 SSDLC 20.5 Release Flow 20.6 Production Support 附錄：新進成員快速 Checklist 第 1 章 Ponytail 概述 1.1 專案背景 Ponytail 是一套開源的 AI Agent 行為準則（Skill / Plugin），目標只有一個：讓 AI Coding Agent 在動手寫程式前，先經過「這真的有必要嗎」的層層質疑，而不是看到需求就立刻開始搭框架、拉套件、寫一堆「以後可能用得到」的抽象層。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ponytail-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Ponytail 教學手冊 版本：v1.1（2026-06-22，已對照官方 Repository 原始檔案逐章核實修訂） 適用對象：系統分析師、軟體架構師、後端工程師、前端工程師、DevOps工程師、SRE工程師、AI工程師、企業資訊部門、Framework維護團隊、Legacy System維護團隊 內容定位：本手冊聚焦於開源 AI Agent 精簡化技能（Skill）Ponytail 的理念、架構、安裝設定、與主流 AI Coding Agent（Claude Code / GitHub Copilot / Cursor / Codex / Gemini CLI 等共 14 個受支援平台）的整合方式，並延伸至企業級開發流程（SSDLC、多 Agent 團隊協作、Legacy 逆向工程、Framework 升級）的實務導入 重要聲明：本手冊第 1～12、15 章內容基於 Ponytail 官方 GitHub Repository（DietrichGebert/ponytail）之 README.md、AGENTS.md、skills/ponytail/SKILL.md、skills/ponytail-review/SKILL.md、docs/agent-portability.md、docs/platform-native.md 等公開資料，逐項核對原文後整理改寫而成（非逐字抄錄）；第 13、14、16、20 章為「企業實務延伸」章節，是顧問觀點下將 Ponytail 精簡哲學套用於企業開發治理的建議做法，並非 Ponytail 官方功能宣稱，文中會明確標註。GitHub 社群數據（Star／Fork／Issue 數）反映查詢當下時間點，會隨時間持續變動 授權：內部教育訓練使用\n如何使用本手冊 Ponytail 不是一個框架，也不是一個 IDE，而是一套注入到 AI Coding Agent 的行為準則（Skill / Plugin）。它的任務很單純：在 AI Agent 動手寫程式之前，先逼它像一個「已經看過太多過度設計專案、留著馬尾、戴著圓框眼鏡的資深工程師」一樣，先問一句「這真的需要寫嗎？」。本手冊依角色整理出建議閱讀路徑：\n角色 建議優先閱讀章節 新進工程師 第1、3、5、6章 後端／前端工程師 第7、8、9、10章 架構師／系統分析師 第2、4、11、12章 DevOps／SRE 第6、7、19章 AI Coding Agent 重度使用者 第4、5、15、17、18章 企業資訊部門主管 第13、14、16、20章 Legacy System維護團隊 第11、12章 Code Review／品質把關者 第9、17、18章 目錄 第 1 章 Ponytail 概述 1.1 專案背景 1.2 作者介紹 1.3 發展歷程與版本里程碑 1.4 GitHub 社群狀況 1.5 為何爆紅 1.6 解決哪些問題 第 2 章 AI Coding Agent 常見問題 2.1 Over Engineering 2.2 Reinvent The Wheel 2.3 Token Waste 2.4 Context Pollution 2.5 Hallucination Driven Design 2.6 Framework Ignorance 2.7 Existing Code Ignorance 2.8 Legacy System Rewrite Syndrome 2.9 案例分析總表 第 3 章 Ponytail 核心理念 3.1 Lazy Senior Developer Mindset 3.2 Less Code Principle 3.3 Existing Solution First 3.4 Delete Before Build 3.5 Native Feature First 3.6 Library Before Custom Code 3.7 Configuration Before Programming 3.8 Simplicity First 3.9 Maintainability First 3.10 Cost Awareness 第 4 章 Ponytail 系統架構 4.1 Architecture Overview 4.2 Skill Architecture 4.3 Agent Workflow 4.4 Review Loop 4.5 Self Critique Loop 4.6 Decision Flow 4.7 Prompt Enhancement Flow 4.8 Integration Flow 第 5 章 Ponytail 工作原理 5.1 第一階：這個功能真的需要存在嗎（YAGNI） 5.2 第二階：標準函式庫能解決嗎 5.3 第三階：平台原生功能能解決嗎 5.4 第四階：已安裝的相依套件能解決嗎 5.5 第五階：能用一行寫完嗎 5.6 第六階：只寫最小可行實作 5.7 企業實務延伸：刪除與精簡思維（呼應 ponytail-review） 5.8 內部思考流程整合範例 第 6 章 安裝與部署 6.1 Claude Code 6.2 GitHub Copilot 6.3 Cursor 6.4 OpenAI Codex／Agent 6.5 Gemini CLI 6.6 VS Code 整合 6.7 JetBrains 整合 6.8 Pi Agent Harness 6.9 OpenCode 6.10 CodeWhale 6.11 OpenClaw 6.12 Kiro 6.13 系統需求 第 7 章 Ponytail 設定說明 7.1 Agent Configuration 7.2 Rules 7.3 Skills 7.4 Context 7.5 Hooks 7.6 Templates 7.7 Review Policies 7.8 Team Standards 第 8 章 與 Claude Code 整合 8.1 Agent Skill 8.2 Custom Instructions 8.3 Commands 8.4 Workflows 8.5 Best Practices 8.6 Enterprise Standards 第 9 章 與 GitHub Copilot 整合 9.1 Copilot Agent 9.2 Copilot Coding Agent 9.3 Repository Instructions 9.4 Prompt Files 9.5 Agent Files 9.6 Skills 9.7 完整範例 第 10 章 Web Application 開發實戰 10.1 技術棧總覽 10.2 API 開發 10.3 CRUD 開發 10.4 Batch 開發 10.5 Security 開發 10.6 Integration 開發 10.7 Ponytail 如何減少程式碼 第 11 章 Legacy System Reverse Engineering 11.1 Mainframe 11.2 COBOL 11.3 Lotus Domino 11.4 Struts 11.5 JSF 11.6 舊版 Spring 11.7 WebSphere 11.8 WebLogic 11.9 Ponytail 在逆向工程中的角色與限制 第 12 章 Framework Upgrade 實戰 12.1 Spring Boot 2 到 3 12.2 Java 8 到 21 12.3 Vue2 到 Vue3 12.4 Jakarta Migration 12.5 JDK Upgrade 12.6 Dependency Upgrade 12.7 降低升級成本的具體做法 第 13 章 與 SSDLC 整合（企業實務延伸） 13.1 定位澄清：Ponytail 不是安全工具 13.2 Threat Modeling 13.3 SAST 13.4 DAST 13.5 Dependency Check 13.6 Secret Detection 13.7 Secure Coding 13.8 Compliance 13.9 Audit 第 14 章 與 AI Agent 團隊整合（企業實務延伸） 14.1 多 Agent 團隊架構總覽 14.2 Planner Agent 14.3 Architect Agent 14.4 Developer Agent 14.5 Reviewer Agent 14.6 Security Agent 14.7 QA Agent 14.8 Release Agent 14.9 Ponytail 在團隊中的角色 第 15 章 Token Optimization 15.1 Token Reduction 15.2 Context Reduction 15.3 Prompt Compression 15.4 Reuse Existing Logic 15.5 Knowledge Reuse 15.6 Memory Optimization 15.7 實際數據案例 第 16 章 企業導入指南（企業實務延伸） 16.1 Governance 16.2 Standards 16.3 Team Adoption 16.4 Change Management 16.5 Training Plan 16.6 KPI 16.7 ROI 第 17 章 最佳實務 第 18 章 常見錯誤 第 19 章 維運與升級 19.1 Version Upgrade 19.2 Skill Upgrade 19.3 Agent Upgrade 19.4 Prompt Upgrade 19.5 Governance Upgrade 第 20 章 完整企業導入範例（企業實務延伸） 20.1 案例背景：大型銀行共用平台 20.2 開發流程 20.3 Code Review 20.4 SSDLC 20.5 Release Flow 20.6 Production Support 附錄：新進成員快速 Checklist 第 1 章 Ponytail 概述 1.1 專案背景 Ponytail 是一套開源的 AI Agent 行為準則（Skill / Plugin），目標只有一個：讓 AI Coding Agent 在動手寫程式前，先經過「這真的有必要嗎」的層層質疑，而不是看到需求就立刻開始搭框架、拉套件、寫一堆「以後可能用得到」的抽象層。\n","title":"Ponytail 教學手冊"},{"content":"12-Factor Agents 教學手冊 版本：v1.1　|　更新日期：2026-06-19　|　適用對象：資深工程師、架構師、AI Agent Architect、技術主管\n變更紀錄（v1.0 → v1.1） 對照原始來源 humanlayer/12-factor-agents 重新逐章核對內容準確度與時效性 第一章 1.1／1.5 補上原文「How We Got Here」中 DAG Orchestrator（Airflow／Prefect／Dagster）的歷史脈絡，使 Agent 工程演進敘事更完整 第三章新增 Factor 13（榮譽提及）：Pre-fetch All the Context You Might Need，補齊原文十二大原則之外的延伸原則 第五章新增 5.8（Context Rot 與「啞區 Dumb Zone」現象）、5.9（Research-Plan-Implement, RPI 框架），收錄 HumanLayer 團隊基於十萬餘筆開發者 Session 分析的最新實證研究 新增附錄 H　參考資料，補上原始出處與延伸閱讀連結，提升內容可追溯性 校對全文標題層級、目錄錨點、code fence 配對，確認與本文一致且無格式錯位 文件說明 本手冊以 HumanLayer 團隊提出的《12-Factor Agents》原則為核心骨幹，延伸至企業實際導入 AI Coding Agent（Claude Code、GitHub Copilot Agent Mode 等）的完整工程實務。內容定位為企業內部培訓教材，同時也是架構設計手冊與開發實戰手冊，目標讀者涵蓋初級工程師到 AI Agent Architect 各個層級。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/12-factor-agents%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"12-Factor Agents 教學手冊 版本：v1.1　|　更新日期：2026-06-19　|　適用對象：資深工程師、架構師、AI Agent Architect、技術主管\n變更紀錄（v1.0 → v1.1） 對照原始來源 humanlayer/12-factor-agents 重新逐章核對內容準確度與時效性 第一章 1.1／1.5 補上原文「How We Got Here」中 DAG Orchestrator（Airflow／Prefect／Dagster）的歷史脈絡，使 Agent 工程演進敘事更完整 第三章新增 Factor 13（榮譽提及）：Pre-fetch All the Context You Might Need，補齊原文十二大原則之外的延伸原則 第五章新增 5.8（Context Rot 與「啞區 Dumb Zone」現象）、5.9（Research-Plan-Implement, RPI 框架），收錄 HumanLayer 團隊基於十萬餘筆開發者 Session 分析的最新實證研究 新增附錄 H　參考資料，補上原始出處與延伸閱讀連結，提升內容可追溯性 校對全文標題層級、目錄錨點、code fence 配對，確認與本文一致且無格式錯位 文件說明 本手冊以 HumanLayer 團隊提出的《12-Factor Agents》原則為核心骨幹，延伸至企業實際導入 AI Coding Agent（Claude Code、GitHub Copilot Agent Mode 等）的完整工程實務。內容定位為企業內部培訓教材，同時也是架構設計手冊與開發實戰手冊，目標讀者涵蓋初級工程師到 AI Agent Architect 各個層級。\n","title":"12 Factor Agents教學手冊"},{"content":"Claude Code CLI 教學手冊 版本：v1.2（2026-07-03） 適用對象：系統分析師、軟體架構師、後端工程師、前端工程師、DevOps工程師、SRE工程師、AI工程師、企業資訊部門、Framework維護團隊、Legacy System維護團隊 內容定位：本手冊聚焦於 Claude Code CLI 層級的安裝、設定、指令、Agent 架構、MCP 整合與企業導入實務，可與專案內其他 Claude Code 相關手冊（生態圈版、資深同仁版等）並行參考 對齊基準：本版內容已對照官方文件（code.claude.com/docs）於 Claude Code v2.1.199（2026-07-02） 時的狀態逐章核對更新，細節請見附錄C版本紀錄 授權：內部教育訓練使用\n如何使用本手冊 Claude Code CLI 是一套以終端機（Terminal）為主要操作介面的 AI 編碼代理人（Coding Agent）。它不像傳統 IDE 外掛只做行內自動完成，而是能夠自主規劃、呼叫工具、跨檔案修改、執行測試、操作 Git，甚至協調多個子 Agent 完成大型任務。本手冊依角色整理出建議閱讀路徑：\n角色 建議優先閱讀章節 新進工程師 第1、3、4、6、7章 後端／前端工程師 第8、9、14、17、18章 架構師／系統分析師 第2、13、15、16章 DevOps／SRE 第5、12、19、20、28章 企業資訊部門主管 第21、25、28章 Legacy System維護團隊 第15、16章 平台／AI賦能團隊 第9、10、26、27章 目錄 下列目錄為兩層結構：章節層可直接跳轉至對應章節開頭，子章節層可直接跳轉至章節內的特定小節。\n第 1 章 Claude Code CLI 介紹 1.1 Claude Code 是什麼 1.2 Claude Code 與 Claude Web 差異 1.3 與其他工具的定位比較 1.4 適用情境 1.5 限制 1.6 與 Claude Code 周邊介面／產品的關係 第 2 章 Claude Code 架構原理 2.1 Agent Loop（代理人迴圈） 2.2 Context 管理與 Token 管理 2.3 Tool Calling 與 MCP 整合 2.4 子 Agent 與 Agent 協作 2.5 Codebase 理解機制 第 3 章 安裝教學 3.1 系統需求 3.2 Windows 安裝 3.3 macOS 安裝 3.4 Linux 安裝 3.5 Windows CMD 安裝（備選） 3.6 WSL2 安裝注意事項 3.7 npm 安裝路徑（備選） 3.8 更新與驗證 第 4 章 Authentication 4.1 帳號類型 4.2 登入方式 4.3 API Key 與環境變數（適合 CI / Headless） 4.4 安全建議 4.5 企業雲端供應商登入 4.5.1 Claude apps gateway：讓第三方雲端也能拿到集中治理 第 5 章 Claude Code 設定管理 5.1 settings.json 三層架構 5.2 優先順序 5.3 設定範例 5.4 常見設定鍵分類 5.5 Managed Settings 交付機制 第 6 章 CLI 指令大全 6.1 指令依生命週期分類 6.2 Session 操作 6.3 Agent 管理 6.4 MCP / Plugin / 專案維護 6.5 常用旗標（Flags） 6.6 權限模式與 Auto Mode（自動權限分類器） 6.6.1 Auto Mode 分類器運作方式 6.6.2 啟用條件與企業治理 第 7 章 Hotkey 大全 7.1 終端機層級快捷鍵 7.2 Claude Code Session 內快捷鍵 7.3 Agent 操作快捷鍵 第 8 章 Context Engineering 8.1 Context Window 組成 8.2 壓縮（Compaction）與重用 8.3 快取（Caching） 8.4 Token 優化技巧 8.5 Checkpoints 與 Rewind（對話回溯） 第 9 章 Agent 系統 9.1 概念釐清：Agent / Sub Agent / Multi Agent 9.2 何時該建立 Sub Agent 9.3 生命週期管理 9.4 設計考量 9.5 Agent View（背景多 Session 監看） 9.6 Agent Teams（多 Session 協作，實驗性） 9.7 Dynamic Workflows（腳本化大規模編排） 9.8 Worktrees（Git Worktree 隔離機制） 9.9 Fork Subagent：繼承完整上下文的特殊 Subagent 第 10 章 Agents 目錄 10.1 子 Agent 定義檔格式 10.2 載入順序 10.3 呼叫方式 10.4 內建子 Agent 10.5 Persistent Memory（子 Agent 持久記憶） 10.6 實務範例：團隊共用子 Agent 第 11 章 CLAUDE.md 11.1 用途 11.2 四層檔案 11.3 企業標準範本 11.4 維護方式 11.5 Auto Memory（自動記憶）：Claude 自己寫的筆記 11.6 .claude/rules/：路徑範圍化的模組化規則 第 12 章 Hooks 12.1 生命週期事件 12.2 Handler 類型 12.3 PreToolUse／PostToolUse 機制 12.4 設定範例 12.5 安全考量 第 13 章 MCP 整合 13.1 MCP 概念 13.2 設定與管理 13.3 整合案例 13.4 工具延遲載入 13.5 MCP 治理鍵補充 第 14 章 使用 Claude Code 開發 Web Application 14.1 通用工作流程 14.2 Spring Boot（Java/Kotlin） 14.3 FastAPI（Python） 14.4 Vue3 / Angular 第 15 章 Legacy System 逆向工程 15.1 分析方法 15.2 適用範圍與限制 15.3 範例 Prompt 15.4 產出範例 第 16 章 Framework 升級 16.1 通用升級方法論 16.2 各升級情境要點 16.3 範例 Prompt 第 17 章 Git 整合 17.1 AI 協作流程 17.2 常用指令 17.3 守則 17.4 Worktree 分支隔離與 /code-review 第 18 章 測試工程 18.1 測試生成工作流程 18.2 各類型測試 18.3 範例 18.4 TDD 風格使用 第 19 章 SSDLC 整合 19.1 定位 19.2 各類掃描的協作方式 19.3 兩層防護案例 19.4 Sandboxing：第三層防護 第 20 章 Token 與成本管理 20.1 成本驅動因子 20.2 查看用量 20.3 降低成本技巧 20.4 用量可視化：/usage、Analytics、OpenTelemetry 第 21 章 團隊導入指南 21.1 分階段導入流程 21.2 治理模式 21.3 權限管理 21.4 標準規範 21.5 新機制的治理檢查項 第 22 章 Claude Code 最佳實務 22.1 20 個最佳實務 22.2 20 個常見錯誤 22.3 20 個效能優化技巧 第 23 章 Claude Code Prompt Library 23.1 分類架構 23.2 範本（可直接複製套用） 第 24 章 Claude Code + GitHub Copilot 協同開發 24.1 分工模式 24.2 實際工作流程 24.3 避免衝突 第 25 章 Claude Code 企業級導入藍圖 25.1 完整藍圖 25.2 組織架構 25.3 治理模式總結（彙整前述章節） 25.4 KPI 與稽核 第 26 章 Agent 進階協作模式 26.1 四種平行化機制總覽 26.2 Agent Teams 實務 26.3 Dynamic Workflows 實務 26.4 /batch：大規模 Worktree 隔離批次處理 第 27 章 Agent Skills 與 Plugin 生態 27.1 Skills 與 CLAUDE.md／Subagent 的定位差異 27.2 SKILL.md 格式與存放層級 27.3 隨附 Skills（Bundled Skills） 27.4 Plugins 生態與 Marketplace 治理 27.5 團隊標準化建議 第 28 章 企業治理進階 28.1 Managed Settings 完整交付架構 28.2 Sandboxing 深度 28.3 Network Config 與 LLM Gateway 28.3.1 組織層級模型治理（Enterprise） 28.4 Zero Data Retention、稽核與合規 28.5 Cost／Usage／Analytics 企業可視化（平台團隊視角） 附錄 A：常見問題 FAQ 附錄 B：詞彙表 Glossary 附錄 C：版本紀錄 Version History 附錄 D：學習路線圖 附錄 E：與其他 AI 編碼工具比較表 附錄 F：Checklist（新人加入檢查清單） 第 1 章 Claude Code CLI 介紹 1.1 Claude Code 是什麼 Claude Code 是 Anthropic 推出的終端機原生 AI 編碼代理人（Agentic Coding Tool）。與一般「聊天視窗貼程式碼」的使用方式不同，Claude Code 直接在你的專案目錄裡執行，能夠讀取檔案、搜尋程式碼、編輯多個檔案、執行 Bash 指令、操作 Git、呼叫外部系統（透過 MCP），並以「自主代理人迴圈」（Agent Loop）的方式持續規劃與執行，直到任務完成或需要你確認為止。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code-cli-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Claude Code CLI 教學手冊 版本：v1.2（2026-07-03） 適用對象：系統分析師、軟體架構師、後端工程師、前端工程師、DevOps工程師、SRE工程師、AI工程師、企業資訊部門、Framework維護團隊、Legacy System維護團隊 內容定位：本手冊聚焦於 Claude Code CLI 層級的安裝、設定、指令、Agent 架構、MCP 整合與企業導入實務，可與專案內其他 Claude Code 相關手冊（生態圈版、資深同仁版等）並行參考 對齊基準：本版內容已對照官方文件（code.claude.com/docs）於 Claude Code v2.1.199（2026-07-02） 時的狀態逐章核對更新，細節請見附錄C版本紀錄 授權：內部教育訓練使用\n如何使用本手冊 Claude Code CLI 是一套以終端機（Terminal）為主要操作介面的 AI 編碼代理人（Coding Agent）。它不像傳統 IDE 外掛只做行內自動完成，而是能夠自主規劃、呼叫工具、跨檔案修改、執行測試、操作 Git，甚至協調多個子 Agent 完成大型任務。本手冊依角色整理出建議閱讀路徑：\n角色 建議優先閱讀章節 新進工程師 第1、3、4、6、7章 後端／前端工程師 第8、9、14、17、18章 架構師／系統分析師 第2、13、15、16章 DevOps／SRE 第5、12、19、20、28章 企業資訊部門主管 第21、25、28章 Legacy System維護團隊 第15、16章 平台／AI賦能團隊 第9、10、26、27章 目錄 下列目錄為兩層結構：章節層可直接跳轉至對應章節開頭，子章節層可直接跳轉至章節內的特定小節。\n第 1 章 Claude Code CLI 介紹 1.1 Claude Code 是什麼 1.2 Claude Code 與 Claude Web 差異 1.3 與其他工具的定位比較 1.4 適用情境 1.5 限制 1.6 與 Claude Code 周邊介面／產品的關係 第 2 章 Claude Code 架構原理 2.1 Agent Loop（代理人迴圈） 2.2 Context 管理與 Token 管理 2.3 Tool Calling 與 MCP 整合 2.4 子 Agent 與 Agent 協作 2.5 Codebase 理解機制 第 3 章 安裝教學 3.1 系統需求 3.2 Windows 安裝 3.3 macOS 安裝 3.4 Linux 安裝 3.5 Windows CMD 安裝（備選） 3.6 WSL2 安裝注意事項 3.7 npm 安裝路徑（備選） 3.8 更新與驗證 第 4 章 Authentication 4.1 帳號類型 4.2 登入方式 4.3 API Key 與環境變數（適合 CI / Headless） 4.4 安全建議 4.5 企業雲端供應商登入 4.5.1 Claude apps gateway：讓第三方雲端也能拿到集中治理 第 5 章 Claude Code 設定管理 5.1 settings.json 三層架構 5.2 優先順序 5.3 設定範例 5.4 常見設定鍵分類 5.5 Managed Settings 交付機制 第 6 章 CLI 指令大全 6.1 指令依生命週期分類 6.2 Session 操作 6.3 Agent 管理 6.4 MCP / Plugin / 專案維護 6.5 常用旗標（Flags） 6.6 權限模式與 Auto Mode（自動權限分類器） 6.6.1 Auto Mode 分類器運作方式 6.6.2 啟用條件與企業治理 第 7 章 Hotkey 大全 7.1 終端機層級快捷鍵 7.2 Claude Code Session 內快捷鍵 7.3 Agent 操作快捷鍵 第 8 章 Context Engineering 8.1 Context Window 組成 8.2 壓縮（Compaction）與重用 8.3 快取（Caching） 8.4 Token 優化技巧 8.5 Checkpoints 與 Rewind（對話回溯） 第 9 章 Agent 系統 9.1 概念釐清：Agent / Sub Agent / Multi Agent 9.2 何時該建立 Sub Agent 9.3 生命週期管理 9.4 設計考量 9.5 Agent View（背景多 Session 監看） 9.6 Agent Teams（多 Session 協作，實驗性） 9.7 Dynamic Workflows（腳本化大規模編排） 9.8 Worktrees（Git Worktree 隔離機制） 9.9 Fork Subagent：繼承完整上下文的特殊 Subagent 第 10 章 Agents 目錄 10.1 子 Agent 定義檔格式 10.2 載入順序 10.3 呼叫方式 10.4 內建子 Agent 10.5 Persistent Memory（子 Agent 持久記憶） 10.6 實務範例：團隊共用子 Agent 第 11 章 CLAUDE.md 11.1 用途 11.2 四層檔案 11.3 企業標準範本 11.4 維護方式 11.5 Auto Memory（自動記憶）：Claude 自己寫的筆記 11.6 .claude/rules/：路徑範圍化的模組化規則 第 12 章 Hooks 12.1 生命週期事件 12.2 Handler 類型 12.3 PreToolUse／PostToolUse 機制 12.4 設定範例 12.5 安全考量 第 13 章 MCP 整合 13.1 MCP 概念 13.2 設定與管理 13.3 整合案例 13.4 工具延遲載入 13.5 MCP 治理鍵補充 第 14 章 使用 Claude Code 開發 Web Application 14.1 通用工作流程 14.2 Spring Boot（Java/Kotlin） 14.3 FastAPI（Python） 14.4 Vue3 / Angular 第 15 章 Legacy System 逆向工程 15.1 分析方法 15.2 適用範圍與限制 15.3 範例 Prompt 15.4 產出範例 第 16 章 Framework 升級 16.1 通用升級方法論 16.2 各升級情境要點 16.3 範例 Prompt 第 17 章 Git 整合 17.1 AI 協作流程 17.2 常用指令 17.3 守則 17.4 Worktree 分支隔離與 /code-review 第 18 章 測試工程 18.1 測試生成工作流程 18.2 各類型測試 18.3 範例 18.4 TDD 風格使用 第 19 章 SSDLC 整合 19.1 定位 19.2 各類掃描的協作方式 19.3 兩層防護案例 19.4 Sandboxing：第三層防護 第 20 章 Token 與成本管理 20.1 成本驅動因子 20.2 查看用量 20.3 降低成本技巧 20.4 用量可視化：/usage、Analytics、OpenTelemetry 第 21 章 團隊導入指南 21.1 分階段導入流程 21.2 治理模式 21.3 權限管理 21.4 標準規範 21.5 新機制的治理檢查項 第 22 章 Claude Code 最佳實務 22.1 20 個最佳實務 22.2 20 個常見錯誤 22.3 20 個效能優化技巧 第 23 章 Claude Code Prompt Library 23.1 分類架構 23.2 範本（可直接複製套用） 第 24 章 Claude Code + GitHub Copilot 協同開發 24.1 分工模式 24.2 實際工作流程 24.3 避免衝突 第 25 章 Claude Code 企業級導入藍圖 25.1 完整藍圖 25.2 組織架構 25.3 治理模式總結（彙整前述章節） 25.4 KPI 與稽核 第 26 章 Agent 進階協作模式 26.1 四種平行化機制總覽 26.2 Agent Teams 實務 26.3 Dynamic Workflows 實務 26.4 /batch：大規模 Worktree 隔離批次處理 第 27 章 Agent Skills 與 Plugin 生態 27.1 Skills 與 CLAUDE.md／Subagent 的定位差異 27.2 SKILL.md 格式與存放層級 27.3 隨附 Skills（Bundled Skills） 27.4 Plugins 生態與 Marketplace 治理 27.5 團隊標準化建議 第 28 章 企業治理進階 28.1 Managed Settings 完整交付架構 28.2 Sandboxing 深度 28.3 Network Config 與 LLM Gateway 28.3.1 組織層級模型治理（Enterprise） 28.4 Zero Data Retention、稽核與合規 28.5 Cost／Usage／Analytics 企業可視化（平台團隊視角） 附錄 A：常見問題 FAQ 附錄 B：詞彙表 Glossary 附錄 C：版本紀錄 Version History 附錄 D：學習路線圖 附錄 E：與其他 AI 編碼工具比較表 附錄 F：Checklist（新人加入檢查清單） 第 1 章 Claude Code CLI 介紹 1.1 Claude Code 是什麼 Claude Code 是 Anthropic 推出的終端機原生 AI 編碼代理人（Agentic Coding Tool）。與一般「聊天視窗貼程式碼」的使用方式不同，Claude Code 直接在你的專案目錄裡執行，能夠讀取檔案、搜尋程式碼、編輯多個檔案、執行 Bash 指令、操作 Git、呼叫外部系統（透過 MCP），並以「自主代理人迴圈」（Agent Loop）的方式持續規劃與執行，直到任務完成或需要你確認為止。\n","title":"Claude Code Cli 教學手冊"},{"content":"Loop Engineering 教學手冊 版本：v1.2　|　更新日期：2026-07-20　|　適用對象：資深工程師、架構師、技術主管\n變更紀錄（v1.1 → v1.2） 新增「第十五章　Skill Library」：依 4.3.1 節目錄結構，實作 26 個技能檔案（coding／architecture／testing／security／migration 五大分類，Skill-01～Skill-26） 原第十五～十八章（最佳實務 Top 50、常見錯誤 Top 50、導入策略、未來發展）依序遞移為第十六～十九章，並同步更新目錄與全文交叉引用 變更紀錄（v1.0 → v1.1） 修復巢狀 code fence 連鎖錯位問題（曾導致第十五、十六章在嚴格 CommonMark 渲染器下被誤判為單一程式碼區塊）與其他 Markdown 格式問題 簡化附錄 I／J／K 標題格式並補上目錄連結，修正目錄與本文不一致之處 新增 1.6（演進脈絡與業界共識）、1.7（風險與限制：企業治理視角） 新增 2.10（Anthropic 六大 Agent 工作流模式對照）、2.11（Graph Harness 排程理論觀點）、2.12（Ralph Wiggum Technique） 擴充第十一章 Evals 設計方法論：新增 11.6～11.10，補齊術語體系、評分器類型、Pass@k／Pass^k、8 步驟落地路線圖、Swiss Cheese Model、業界標竿與工具 擴充第十八章導入策略：新增 18.4～18.6，補齊單一迴圈自主程度模型、七種生產級 Loop 模式目錄、loop-audit／loop-cost 自我檢測 新增 18.5（下一代執行引擎：Graph Harness 的展望） 目錄 第一章　Loop Engineering 概論 第二章　Loop Engineering 核心理論 第三章　Loop Engineering 系統架構 第四章　六大核心元件 第五章　Claude Code 中的 Loop Engineering 第六章　GitHub Copilot 中的 Loop Engineering 第七章　建立企業級 Loop Engineering 平台 第八章　Web Application 開發實戰 第九章　Legacy System 逆向工程 第十章　Framework 升級實戰 第十一章　Evals 設計 第十二章　AI Agent Team 設計 第十三章　SSDLC 與 Loop Engineering 第十四章　Prompt Library 第十五章　Skill Library 第十六章　最佳實務 Top 50 第十七章　常見錯誤 Top 50 Anti-patterns 第十八章　導入策略 第十九章　未來發展 附錄 A　Loop Engineering Checklist 附錄 B　Project Structure 附錄 C　Skill Library Template 附錄 D　Memory Template 附錄 E　Evaluation Template 附錄 F　Claude Code Setup 附錄 G　GitHub Copilot Setup 附錄 H　企業導入路線圖 附錄 I　補充 Prompt Library 附錄 J　補充 SOP 集合 附錄 K　補充 Mermaid 架構圖集 第一章　Loop Engineering 概論 1.1　Loop Engineering 的起源 Loop Engineering 這個概念由 Google Chrome 工程師 Addy Osmani 在 2024-2025 年間系統化提出，並在其 Substack 文章《Loop Engineering》中首次完整闡述。這個概念的誕生並非偶然，而是對 AI 輔助開發演進路徑的自然延伸。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/loop-engineering-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Loop Engineering 教學手冊 版本：v1.2　|　更新日期：2026-07-20　|　適用對象：資深工程師、架構師、技術主管\n變更紀錄（v1.1 → v1.2） 新增「第十五章　Skill Library」：依 4.3.1 節目錄結構，實作 26 個技能檔案（coding／architecture／testing／security／migration 五大分類，Skill-01～Skill-26） 原第十五～十八章（最佳實務 Top 50、常見錯誤 Top 50、導入策略、未來發展）依序遞移為第十六～十九章，並同步更新目錄與全文交叉引用 變更紀錄（v1.0 → v1.1） 修復巢狀 code fence 連鎖錯位問題（曾導致第十五、十六章在嚴格 CommonMark 渲染器下被誤判為單一程式碼區塊）與其他 Markdown 格式問題 簡化附錄 I／J／K 標題格式並補上目錄連結，修正目錄與本文不一致之處 新增 1.6（演進脈絡與業界共識）、1.7（風險與限制：企業治理視角） 新增 2.10（Anthropic 六大 Agent 工作流模式對照）、2.11（Graph Harness 排程理論觀點）、2.12（Ralph Wiggum Technique） 擴充第十一章 Evals 設計方法論：新增 11.6～11.10，補齊術語體系、評分器類型、Pass@k／Pass^k、8 步驟落地路線圖、Swiss Cheese Model、業界標竿與工具 擴充第十八章導入策略：新增 18.4～18.6，補齊單一迴圈自主程度模型、七種生產級 Loop 模式目錄、loop-audit／loop-cost 自我檢測 新增 18.5（下一代執行引擎：Graph Harness 的展望） 目錄 第一章　Loop Engineering 概論 第二章　Loop Engineering 核心理論 第三章　Loop Engineering 系統架構 第四章　六大核心元件 第五章　Claude Code 中的 Loop Engineering 第六章　GitHub Copilot 中的 Loop Engineering 第七章　建立企業級 Loop Engineering 平台 第八章　Web Application 開發實戰 第九章　Legacy System 逆向工程 第十章　Framework 升級實戰 第十一章　Evals 設計 第十二章　AI Agent Team 設計 第十三章　SSDLC 與 Loop Engineering 第十四章　Prompt Library 第十五章　Skill Library 第十六章　最佳實務 Top 50 第十七章　常見錯誤 Top 50 Anti-patterns 第十八章　導入策略 第十九章　未來發展 附錄 A　Loop Engineering Checklist 附錄 B　Project Structure 附錄 C　Skill Library Template 附錄 D　Memory Template 附錄 E　Evaluation Template 附錄 F　Claude Code Setup 附錄 G　GitHub Copilot Setup 附錄 H　企業導入路線圖 附錄 I　補充 Prompt Library 附錄 J　補充 SOP 集合 附錄 K　補充 Mermaid 架構圖集 第一章　Loop Engineering 概論 1.1　Loop Engineering 的起源 Loop Engineering 這個概念由 Google Chrome 工程師 Addy Osmani 在 2024-2025 年間系統化提出，並在其 Substack 文章《Loop Engineering》中首次完整闡述。這個概念的誕生並非偶然，而是對 AI 輔助開發演進路徑的自然延伸。\n","title":"Loop Engineering 教學手冊"},{"content":"Headroom 教學手冊 版本：基於 Headroom v0.25.0（2026-06-12）\n適用對象：資深工程師、AI Agent 開發團隊、DevOps 工程師\n授權：Apache 2.0\n專案規模：GitHub ⭐ 24.1K｜Contributors 83+｜Releases 155+\n官方資源：GitHub ｜ 文件站 ｜ PyPI ｜ npm ｜ llms.txt ｜ Enterprise\n目錄 第一章 Headroom 簡介 1.1 Headroom 是什麼 1.2 為何需要 Headroom 1.3 Headroom 與 RTK 差異 第二章 Headroom 系統架構 2.1 整體架構圖 2.2 三階段壓縮管線 2.3 ContentRouter 2.4 SmartCrusher 2.5 CodeCompressor 2.6 Kompress-base 2.7 CacheAligner 2.8 CCR（可逆壓縮） 2.9 TOIN 學習網路 2.10 Read Lifecycle Management 2.11 壓縮安全護欄 第三章 安裝與部署 3.1 系統需求 3.2 Python 安裝 3.3 Node.js 安裝 3.4 Docker 部署 3.5 Podman 部署 3.6 企業 SSL 環境處理 3.7 驗證安裝 第四章 使用模式 4.1 Library Mode 4.2 Proxy Mode 4.3 Agent Wrap 4.4 MCP Server 第五章 與 RTK 整合 5.1 為何同時使用 5.2 整合架構 5.3 實戰情境最佳實務 第六章 大型 Web Application 實戰 6.1 專案 Context 管理 6.2 Claude Code 最佳化 6.3 GitHub Copilot Agent 最佳化 6.4 Codex CLI 最佳化 6.5 Gemini CLI 最佳化 6.6 其他 Agent 整合 第七章 Token Optimization 策略 7.1 壓縮方案比較 7.2 依 Context 大小的壓縮策略 7.3 CacheAligner 策略 7.4 複合節省計算 第八章 團隊導入指南 8.1 導入流程 8.2 開發規範範本 8.3 團隊教育訓練 第九章 系統維護 9.1 日常維護 9.2 Log 分析 9.3 Cache 管理 9.4 CCR 管理 9.5 環境變數總覽 9.6 升級策略 9.7 備份策略 第十章 Troubleshooting 第十一章 最佳實務總結 11.1 Do — 建議做法 11.2 Don\u0026rsquo;t — 避免做法 11.3 Architecture Guideline 11.4 Security Guideline 11.5 Performance Guideline 11.6 Cost Optimization Guideline 附錄 A. Headroom 指令速查表 B. MCP 設定範例 C. Docker Compose D. Podman Compose E. Claude Code 整合範例 F. GitHub Copilot 整合範例 G. Codex CLI 整合範例 H. Gemini CLI 整合範例 I. RTK + Headroom 整合範例 J. 其他 Agent 整合範例 K. 檢查清單（Checklist） 第一章 Headroom 簡介 1.1 Headroom 是什麼 Headroom 是一套開源的 AI Agent 上下文壓縮層（Context Compression Layer），專門在資料送入大型語言模型（LLM）之前，對工具輸出、日誌、RAG 檢索結果、原始碼檔案及對話歷史進行智慧壓縮。其核心承諾是：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/headroom-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Headroom 教學手冊 版本：基於 Headroom v0.25.0（2026-06-12）\n適用對象：資深工程師、AI Agent 開發團隊、DevOps 工程師\n授權：Apache 2.0\n專案規模：GitHub ⭐ 24.1K｜Contributors 83+｜Releases 155+\n官方資源：GitHub ｜ 文件站 ｜ PyPI ｜ npm ｜ llms.txt ｜ Enterprise\n目錄 第一章 Headroom 簡介 1.1 Headroom 是什麼 1.2 為何需要 Headroom 1.3 Headroom 與 RTK 差異 第二章 Headroom 系統架構 2.1 整體架構圖 2.2 三階段壓縮管線 2.3 ContentRouter 2.4 SmartCrusher 2.5 CodeCompressor 2.6 Kompress-base 2.7 CacheAligner 2.8 CCR（可逆壓縮） 2.9 TOIN 學習網路 2.10 Read Lifecycle Management 2.11 壓縮安全護欄 第三章 安裝與部署 3.1 系統需求 3.2 Python 安裝 3.3 Node.js 安裝 3.4 Docker 部署 3.5 Podman 部署 3.6 企業 SSL 環境處理 3.7 驗證安裝 第四章 使用模式 4.1 Library Mode 4.2 Proxy Mode 4.3 Agent Wrap 4.4 MCP Server 第五章 與 RTK 整合 5.1 為何同時使用 5.2 整合架構 5.3 實戰情境最佳實務 第六章 大型 Web Application 實戰 6.1 專案 Context 管理 6.2 Claude Code 最佳化 6.3 GitHub Copilot Agent 最佳化 6.4 Codex CLI 最佳化 6.5 Gemini CLI 最佳化 6.6 其他 Agent 整合 第七章 Token Optimization 策略 7.1 壓縮方案比較 7.2 依 Context 大小的壓縮策略 7.3 CacheAligner 策略 7.4 複合節省計算 第八章 團隊導入指南 8.1 導入流程 8.2 開發規範範本 8.3 團隊教育訓練 第九章 系統維護 9.1 日常維護 9.2 Log 分析 9.3 Cache 管理 9.4 CCR 管理 9.5 環境變數總覽 9.6 升級策略 9.7 備份策略 第十章 Troubleshooting 第十一章 最佳實務總結 11.1 Do — 建議做法 11.2 Don\u0026rsquo;t — 避免做法 11.3 Architecture Guideline 11.4 Security Guideline 11.5 Performance Guideline 11.6 Cost Optimization Guideline 附錄 A. Headroom 指令速查表 B. MCP 設定範例 C. Docker Compose D. Podman Compose E. Claude Code 整合範例 F. GitHub Copilot 整合範例 G. Codex CLI 整合範例 H. Gemini CLI 整合範例 I. RTK + Headroom 整合範例 J. 其他 Agent 整合範例 K. 檢查清單（Checklist） 第一章 Headroom 簡介 1.1 Headroom 是什麼 Headroom 是一套開源的 AI Agent 上下文壓縮層（Context Compression Layer），專門在資料送入大型語言模型（LLM）之前，對工具輸出、日誌、RAG 檢索結果、原始碼檔案及對話歷史進行智慧壓縮。其核心承諾是：\n","title":"Headroom 教學手冊"},{"content":"CodeGraph 減少 Token 使用教學手冊 版本：v1.0（2026-05-31）\n適用 CodeGraph 版本：v0.9.7+\n適用對象：資深工程師、架構師、AI Agent 開發團隊\n授權：內部教育訓練使用\n目錄 第 1 章 CodeGraph 概述 1.1 什麼是 CodeGraph 1.2 為何出現 — AI Agent 的 Token 困境 1.3 解決的核心問題 1.4 與傳統 RAG 的差異 1.5 Symbol Graph、Knowledge Graph 與 MCP 的關係 第 2 章 CodeGraph 架構 2.1 Tree-sitter AST 解析層 2.2 Symbol 與 Edge 提取 2.3 Resolution 層 2.4 SQLite 存儲層（FTS5） 2.5 Auto-Sync 檔案監視層 2.6 MCP Server 層 第 3 章 AI 為何浪費大量 Token 3.1 Agent 探索模式分析 3.2 Context 爆炸問題 3.3 Tool Call 爆炸問題 3.4 大型專案規模影響 第 4 章 CodeGraph 如何降低 Token 4.1 預建索引 vs 即時掃描 4.2 精準查詢 vs 全域搜尋 4.3 結構化上下文 vs 原始檔案 4.4 官方 Benchmark 數據分析 第 5 章 安裝與設定 5.1 系統需求 5.2 Windows 安裝 5.3 macOS / Linux 安裝 5.4 npm 安裝方式 5.5 Agent 自動設定 5.6 專案初始化 5.7 驗證與狀態檢查 5.8 解除安裝 第 6 章 MCP 工具詳解 6.1 codegraph_search 6.2 codegraph_context 6.3 codegraph_trace 6.4 codegraph_callers 6.5 codegraph_callees 6.6 codegraph_impact 6.7 codegraph_node 6.8 codegraph_explore 6.9 codegraph_files 6.10 codegraph_status 第 7 章 Claude Code 最佳實踐 7.1 MCP + CodeGraph 設定 7.2 Architecture Analysis 7.3 Bug Analysis 7.4 Refactoring 7.5 Feature Development 7.6 CLAUDE.md 配置建議 第 8 章 GitHub Copilot 最佳實踐 8.1 Copilot Agent Mode + CodeGraph 8.2 Symbol Search 優先策略 8.3 Impact Analysis 工作流 8.4 避免 Full Repository Scan 8.5 copilot-instructions.md 配置 第 9 章 Reverse Engineering 最佳實踐 9.1 場景：接手 20 年 Legacy 系統 9.2 Call Graph 快速理解架構 9.3 Dependency Graph 分析模組關係 9.4 Route Graph 理解 API 端點 9.5 逆向工程完整工作流 第 10 章 Framework 升級最佳實踐 10.1 Impact Analysis 找出受影響模組 10.2 案例：Spring Boot 2 → 4 10.3 案例：Java 17 → 25 10.4 案例：Vue 2 → Vue 3 10.5 案例：AngularJS → Angular 10.6 codegraph affected 整合 CI/CD 第 11 章 SSDLC 整合 11.1 SSDLC 與 CodeGraph 11.2 Threat Modeling 階段 11.3 Code Review 階段 11.4 Incident Response 階段 11.5 Dependency Audit 第 12 章 Token 優化五級策略 12.1 五級優化模型 12.2 Level 1：基礎安裝 12.3 Level 2：工具優先 12.4 Level 3：Prompt 工程 12.5 Level 4：工作流整合 12.6 Level 5：全面治理 第 13 章 企業級實踐 13.1 大規模專案的 CodeGraph 部署 13.2 多語言專案 13.3 團隊協作模式 13.4 安全考量 13.5 效能調優 13.6 程式庫使用（Library API） 第 14 章 團隊 AI 開發規範 14.1 AI Coding Standard（團隊範本） 14.2 Prompt Library（團隊 Prompt 庫） 14.3 Code Review Checklist（AI 產生程式碼） 14.4 onboarding 流程（AI 工具） 第 15 章 20 個常見錯誤與解決方案 15.1 安裝與設定類（錯誤 1-5） 15.2 使用模式類（錯誤 6-10） 15.3 Prompt 設計類（錯誤 11-15） 15.4 進階使用類（錯誤 16-20） 第 16 章 AI Agent 工作流與 KGDD 16.1 Knowledge-Graph-Driven Development (KGDD) 16.2 Agent 工作流設計模式 16.3 Multi-Agent 協作與 CodeGraph 16.4 Agentic Workflow 成熟度模型 第 17 章 總結與展望 17.1 核心要點回顧 17.2 採用路線圖 17.3 未來展望 17.4 行動建議 附錄 A：Claude Code 50%+ Token 削減實戰 附錄 B：GitHub Copilot 50%+ Token 削減實戰 附錄 C：知識圖譜成本削減計算 附錄 D：Enterprise AI Coding Standard 附錄 E：Enterprise MCP Standard 附錄 F：Enterprise KG Platform 藍圖 附錄 G：Checklist 第 1 章 CodeGraph 概述 1.1 什麼是 CodeGraph CodeGraph 是一個開源的本地端程式碼知識圖譜工具（MIT License，GitHub 34.9k+ stars），專為 AI 編碼代理（Coding Agent）設計。它利用 Tree-sitter 解析器將程式碼庫轉換為結構化的符號關係圖譜，儲存於本地 SQLite 資料庫，並透過 MCP（Model Context Protocol）Server 將圖譜能力暴露給 AI Agent 使用。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/codegraph%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"CodeGraph 減少 Token 使用教學手冊 版本：v1.0（2026-05-31）\n適用 CodeGraph 版本：v0.9.7+\n適用對象：資深工程師、架構師、AI Agent 開發團隊\n授權：內部教育訓練使用\n目錄 第 1 章 CodeGraph 概述 1.1 什麼是 CodeGraph 1.2 為何出現 — AI Agent 的 Token 困境 1.3 解決的核心問題 1.4 與傳統 RAG 的差異 1.5 Symbol Graph、Knowledge Graph 與 MCP 的關係 第 2 章 CodeGraph 架構 2.1 Tree-sitter AST 解析層 2.2 Symbol 與 Edge 提取 2.3 Resolution 層 2.4 SQLite 存儲層（FTS5） 2.5 Auto-Sync 檔案監視層 2.6 MCP Server 層 第 3 章 AI 為何浪費大量 Token 3.1 Agent 探索模式分析 3.2 Context 爆炸問題 3.3 Tool Call 爆炸問題 3.4 大型專案規模影響 第 4 章 CodeGraph 如何降低 Token 4.1 預建索引 vs 即時掃描 4.2 精準查詢 vs 全域搜尋 4.3 結構化上下文 vs 原始檔案 4.4 官方 Benchmark 數據分析 第 5 章 安裝與設定 5.1 系統需求 5.2 Windows 安裝 5.3 macOS / Linux 安裝 5.4 npm 安裝方式 5.5 Agent 自動設定 5.6 專案初始化 5.7 驗證與狀態檢查 5.8 解除安裝 第 6 章 MCP 工具詳解 6.1 codegraph_search 6.2 codegraph_context 6.3 codegraph_trace 6.4 codegraph_callers 6.5 codegraph_callees 6.6 codegraph_impact 6.7 codegraph_node 6.8 codegraph_explore 6.9 codegraph_files 6.10 codegraph_status 第 7 章 Claude Code 最佳實踐 7.1 MCP + CodeGraph 設定 7.2 Architecture Analysis 7.3 Bug Analysis 7.4 Refactoring 7.5 Feature Development 7.6 CLAUDE.md 配置建議 第 8 章 GitHub Copilot 最佳實踐 8.1 Copilot Agent Mode + CodeGraph 8.2 Symbol Search 優先策略 8.3 Impact Analysis 工作流 8.4 避免 Full Repository Scan 8.5 copilot-instructions.md 配置 第 9 章 Reverse Engineering 最佳實踐 9.1 場景：接手 20 年 Legacy 系統 9.2 Call Graph 快速理解架構 9.3 Dependency Graph 分析模組關係 9.4 Route Graph 理解 API 端點 9.5 逆向工程完整工作流 第 10 章 Framework 升級最佳實踐 10.1 Impact Analysis 找出受影響模組 10.2 案例：Spring Boot 2 → 4 10.3 案例：Java 17 → 25 10.4 案例：Vue 2 → Vue 3 10.5 案例：AngularJS → Angular 10.6 codegraph affected 整合 CI/CD 第 11 章 SSDLC 整合 11.1 SSDLC 與 CodeGraph 11.2 Threat Modeling 階段 11.3 Code Review 階段 11.4 Incident Response 階段 11.5 Dependency Audit 第 12 章 Token 優化五級策略 12.1 五級優化模型 12.2 Level 1：基礎安裝 12.3 Level 2：工具優先 12.4 Level 3：Prompt 工程 12.5 Level 4：工作流整合 12.6 Level 5：全面治理 第 13 章 企業級實踐 13.1 大規模專案的 CodeGraph 部署 13.2 多語言專案 13.3 團隊協作模式 13.4 安全考量 13.5 效能調優 13.6 程式庫使用（Library API） 第 14 章 團隊 AI 開發規範 14.1 AI Coding Standard（團隊範本） 14.2 Prompt Library（團隊 Prompt 庫） 14.3 Code Review Checklist（AI 產生程式碼） 14.4 onboarding 流程（AI 工具） 第 15 章 20 個常見錯誤與解決方案 15.1 安裝與設定類（錯誤 1-5） 15.2 使用模式類（錯誤 6-10） 15.3 Prompt 設計類（錯誤 11-15） 15.4 進階使用類（錯誤 16-20） 第 16 章 AI Agent 工作流與 KGDD 16.1 Knowledge-Graph-Driven Development (KGDD) 16.2 Agent 工作流設計模式 16.3 Multi-Agent 協作與 CodeGraph 16.4 Agentic Workflow 成熟度模型 第 17 章 總結與展望 17.1 核心要點回顧 17.2 採用路線圖 17.3 未來展望 17.4 行動建議 附錄 A：Claude Code 50%+ Token 削減實戰 附錄 B：GitHub Copilot 50%+ Token 削減實戰 附錄 C：知識圖譜成本削減計算 附錄 D：Enterprise AI Coding Standard 附錄 E：Enterprise MCP Standard 附錄 F：Enterprise KG Platform 藍圖 附錄 G：Checklist 第 1 章 CodeGraph 概述 1.1 什麼是 CodeGraph CodeGraph 是一個開源的本地端程式碼知識圖譜工具（MIT License，GitHub 34.9k+ stars），專為 AI 編碼代理（Coding Agent）設計。它利用 Tree-sitter 解析器將程式碼庫轉換為結構化的符號關係圖譜，儲存於本地 SQLite 資料庫，並透過 MCP（Model Context Protocol）Server 將圖譜能力暴露給 AI Agent 使用。\n","title":"Codegraph教學手冊"},{"content":"GitHub Copilot CLI 教學手冊 版本：基於 GitHub Copilot CLI v1.0.39（2026-04-28 發佈）\nGA 日期：2026-02-25（v0.0.418 起正式 GA）\n適用對象：資深工程師 / DevOps 工程師 / 架構師\n技術環境：企業級 Web Application（Spring Boot 3.x / Vue 3 / 微服務架構）\n適用方案：Copilot Free / Pro / Pro+ / Business / Enterprise\n最後更新：2026-05-29\n目錄 第 1 章：Copilot CLI 概述 1.1 什麼是 GitHub Copilot CLI 1.2 與其他 AI 工具的差異比較 1.3 適用場景 第 2 章：系統架構整合設計 2.1 Copilot CLI 在企業架構中的角色 2.2 與開發流程整合 2.3 Agentic Workflow 設計模式 第 3 章：安裝與環境設定 3.1 支援平台 3.2 前置需求 3.3 安裝步驟 3.4 身份驗證 3.5 初始化設定 3.6 常見錯誤與排除 第 4 章：核心功能教學 4.1 自然語言轉指令 4.2 Agentic Workflow 4.3 Codebase Context 分析 4.4 GitHub 整合 4.5 LSP 語言伺服器整合 4.6 Hooks 鉤子系統 4.7 Skills 技能系統 4.8 Plugin 插件生態系 4.9 Extensions 擴充機制 4.10 Copilot Memory 跨 Session 記憶 4.11 ACP（Agent Client Protocol） 4.12 OpenTelemetry 可觀測性 4.13 Critic Agent 自動審查 4.14 Remote Control 遠端控制 4.15 自訂模型供應商（Custom Model Provider） 4.16 圖片輸入支援 4.17 內建 Agent 系統 第 5 章：進階使用技巧（企業級） 5.1 Prompt Engineering（CLI 版本） 5.2 Context Engineering（讓 AI 更準） 5.3 多步驟任務拆解（Task Chaining） 5.4 與其他工具整合 5.5 Session 管理與對話引導 5.6 多儲存庫工作流程 5.7 圖片驅動開發 第 6 章：安全與治理 6.1 工具審批機制 6.2 YOLO Mode 說明與風險 6.3 企業治理策略 6.4 Hooks 安全防護 第 7 章：實戰案例 第 8 章：最佳實務（Best Practices） 8.1 如何寫好 Prompt（CLI 版本） 8.2 人機協作（Human-in-the-Loop） 8.3 適合與不適合使用的場景 8.4 官方推薦工作流程（Explore → Plan → Code → Commit） 8.5 Session 管理最佳實務 8.6 權限管理最佳實務 8.7 團隊協作與生產力量測 第 9 章：維運與升級 9.1 如何更新 Copilot CLI 9.2 版本管理策略 9.3 常見問題（FAQ） 9.4 效能與成本考量 9.5 自動更新與發佈頻道 第 10 章：附錄 10.1 常用指令速查表 10.2 Prompt 範本合集 10.3 工具權限速查表 10.4 環境變數 10.5 設定檔位置 10.6 版本演進里程碑 10.7 已移除與棄用項目 檢查清單（Checklist） 第 1 章：Copilot CLI 概述 1.1 什麼是 GitHub Copilot CLI GitHub Copilot CLI 是 GitHub 提供的命令列 AI 代理工具，讓開發者直接在終端機（Terminal）中使用 Copilot 的 AI 能力。它不僅是一個自然語言轉指令的工具，更是一個完整的 AI Agent，能夠：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/copilot-cli%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub Copilot CLI 教學手冊 版本：基於 GitHub Copilot CLI v1.0.39（2026-04-28 發佈）\nGA 日期：2026-02-25（v0.0.418 起正式 GA）\n適用對象：資深工程師 / DevOps 工程師 / 架構師\n技術環境：企業級 Web Application（Spring Boot 3.x / Vue 3 / 微服務架構）\n適用方案：Copilot Free / Pro / Pro+ / Business / Enterprise\n最後更新：2026-05-29\n目錄 第 1 章：Copilot CLI 概述 1.1 什麼是 GitHub Copilot CLI 1.2 與其他 AI 工具的差異比較 1.3 適用場景 第 2 章：系統架構整合設計 2.1 Copilot CLI 在企業架構中的角色 2.2 與開發流程整合 2.3 Agentic Workflow 設計模式 第 3 章：安裝與環境設定 3.1 支援平台 3.2 前置需求 3.3 安裝步驟 3.4 身份驗證 3.5 初始化設定 3.6 常見錯誤與排除 第 4 章：核心功能教學 4.1 自然語言轉指令 4.2 Agentic Workflow 4.3 Codebase Context 分析 4.4 GitHub 整合 4.5 LSP 語言伺服器整合 4.6 Hooks 鉤子系統 4.7 Skills 技能系統 4.8 Plugin 插件生態系 4.9 Extensions 擴充機制 4.10 Copilot Memory 跨 Session 記憶 4.11 ACP（Agent Client Protocol） 4.12 OpenTelemetry 可觀測性 4.13 Critic Agent 自動審查 4.14 Remote Control 遠端控制 4.15 自訂模型供應商（Custom Model Provider） 4.16 圖片輸入支援 4.17 內建 Agent 系統 第 5 章：進階使用技巧（企業級） 5.1 Prompt Engineering（CLI 版本） 5.2 Context Engineering（讓 AI 更準） 5.3 多步驟任務拆解（Task Chaining） 5.4 與其他工具整合 5.5 Session 管理與對話引導 5.6 多儲存庫工作流程 5.7 圖片驅動開發 第 6 章：安全與治理 6.1 工具審批機制 6.2 YOLO Mode 說明與風險 6.3 企業治理策略 6.4 Hooks 安全防護 第 7 章：實戰案例 第 8 章：最佳實務（Best Practices） 8.1 如何寫好 Prompt（CLI 版本） 8.2 人機協作（Human-in-the-Loop） 8.3 適合與不適合使用的場景 8.4 官方推薦工作流程（Explore → Plan → Code → Commit） 8.5 Session 管理最佳實務 8.6 權限管理最佳實務 8.7 團隊協作與生產力量測 第 9 章：維運與升級 9.1 如何更新 Copilot CLI 9.2 版本管理策略 9.3 常見問題（FAQ） 9.4 效能與成本考量 9.5 自動更新與發佈頻道 第 10 章：附錄 10.1 常用指令速查表 10.2 Prompt 範本合集 10.3 工具權限速查表 10.4 環境變數 10.5 設定檔位置 10.6 版本演進里程碑 10.7 已移除與棄用項目 檢查清單（Checklist） 第 1 章：Copilot CLI 概述 1.1 什麼是 GitHub Copilot CLI GitHub Copilot CLI 是 GitHub 提供的命令列 AI 代理工具，讓開發者直接在終端機（Terminal）中使用 Copilot 的 AI 能力。它不僅是一個自然語言轉指令的工具，更是一個完整的 AI Agent，能夠：\n","title":"Copilot CLI教學手冊"},{"content":"GitHub Copilot 建立 SSDLC Agent Team 教學手冊 文件目錄：.github/教學/AI開發/\n文件檔名：GitHub Copilot 建立 SSDLC Agent Team 教學手冊.md\n目錄 0. 文件資訊與閱讀指南 1. 總覽：什麼是 GitHub Copilot SSDLC Agent Team 2. 最新功能盤點與術語對照 2.1 功能矩陣表 2.2 功能可用環境比較表 2.3 Preview / GA / Plan Requirement 對照表 2.4 容易混淆概念比較表 2.5 第三方 Agent 與 Auto Model Selection 模型對照 2.6 Copilot Integrations 支援平台 2.7 CLI Built-in Agents 功能說明 3. SSDLC Agent Team 企業架構設計 3.1 Agent 職責總覽 3.2 Mermaid 架構圖 3.3 Agent 協作流程圖 3.4 Agent RACI 表 3.5 Agent 與 SSDLC 階段對應表 3.6 模型分配策略 4. 平台安裝與環境建置 4.1 VS Code 安裝與版本建議 4.2 GitHub Copilot 擴充套件安裝 4.3 GitHub Copilot CLI 安裝 4.4 組織管理員政策設定 4.5 設定檢查清單 4.6 常見安裝錯誤與排除 5. 專案初始化與標準目錄設計 5.1 標準目錄樹 5.2 檔案用途說明 5.3 VS Code 與 GitHub.com / CLI 格式差異 5.4 Project / User / Org 層級差異 5.5 版本控管策略 6. 建立 Custom Agent（⭐ 重點章節） 6.1 Agent Profile 格式詳解 6.2 Agent 1 — Planner（規劃 Agent） 6.3 Agent 2 — Architect（架構 Agent） 6.4 Agent 3 — Backend Developer（後端開發 Agent） 6.5 Agent 4 — Frontend Developer（前端開發 Agent） 6.6 Agent 5 — Test Generator（測試 Agent） 6.7 Agent 6 — Security Reviewer（安全審查 Agent） 6.8 Agent 7 — Code Reviewer（程式碼審查 Agent） 6.9 Agent 8 — Release Agent（發版 Agent） 6.10 Agent 9 — Reverse Engineering Agent（逆向工程 Agent） 6.11 Agent 10 — Doc Writer（文件 Agent） 6.12 Agent 11 — Project Manager（專案管理 Agent） 6.13 Agent-Scoped Hooks（Preview） 6.14 Orchestrator Agent 模式 6.15 Agent 設計最佳實務 7. 建立 Prompt（Prompt Library） 7.1 Prompt File 概念 7.2 SSDLC 各階段 Prompt 範本 7.3 Prompt 設計原則 7.4 Prompt 管理策略 8. 建立 Custom Instructions 8.1 Instructions 類型總覽 8.2 Repo-wide Instructions 8.3 File-based Instructions 8.4 AGENTS.md 8.5 組織層級 Instructions 8.6 Instructions 設計最佳實務 9. 建立 Agent Skills 9.1 Skills 概念 9.2 Skill 1 — Security Review 9.3 Skill 2 — JUnit Test Generator 9.4 Skill 3 — PR Checker 9.5 Skill 4 — API Reviewer 9.6 Skill 5 — Reverse Analysis 9.7 Skill 6 — Doc Generator 9.8 Skills 管理策略 9.9 CLI Plugins：封裝與分發 Agent Team 元件 10. 設定 Hooks 10.1 Hooks 概念與生命週期 10.2 Hook 設定檔格式與放置位置 10.3 VS Code Hooks 設定（Preview） 10.4 Agent-scoped Hooks 10.5 Hook 輸入與輸出機制 10.6 Cloud Agent / CLI Hooks 10.7 SSDLC 護欄策略與 Autopilot 風險 10.8 Hooks 安全考量與最佳實務 11. 管理 Copilot Memory 11.1 Memory 概念 11.2 Memory 儲存類型與運作機制 11.3 啟用 Memory 11.4 Memory 治理 11.5 Memory 最佳實務 12. PR 工作流程（PR Workflow） 12.1 概述 12.2 Copilot 自動 PR Review 12.3 PR Workflow 自動化 12.4 Copilot 在 PR 中的互動 12.5 Agent Management Tab（Agents 管理面板） 12.6 PR 品質指標 12.7 Copilot Integrations（第三方平台整合） 13. SSDLC 全流程整合（⭐ 全文件核心） 13.1 概述 13.2 SSDLC 全流程圖 13.3 各階段 Agent 協作詳解 13.4 Agent Handoff 流程 13.5 端到端範例 13.6 SSDLC 成熟度模型 13.7 企業導入策略 14. 逆向工程（Reverse Engineering） 14.1 概述 14.2 逆向工程流程 14.3 使用 Reverse Agent 進行分析 14.4 逆向工程最佳實務 15. 團隊共享與新人引導 15.1 概述 15.2 團隊共享策略 15.3 新人引導流程 15.4 知識傳承機制 15.5 常見團隊問題與解答 16. 安全治理、合規與成本管理 16.1 概述 16.2 安全治理框架 16.3 法規合規 16.4 成本管理 16.5 使用監控與稽核 17. 維護、升級與版本管理 17.1 概述 17.2 維護策略 17.3 版本管理策略 17.4 平台升級追蹤 17.5 故障排除 18. 案例研究 18.1 概述 18.2 案例一：電商平台 API 開發 18.3 案例二：遺留系統現代化改造 19. 常見問題（FAQ） 20. 最佳實務與檢查清單 21. 附錄：即用範本集 0. 文件資訊與閱讀指南 文件基本資訊 本手冊定位為企業導入 GitHub Copilot Agent 能力的技術白皮書，說明如何以 SSDLC（安全軟體開發生命週期）為骨架，將 Custom Agent、Skills、Instructions、Hooks、Memory 等原生能力組裝成一支可治理的「Agent Team」。內容以官方文件為事實基礎，並加入企業導入時的架構判斷與實務建議。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-copilot-%E5%BB%BA%E7%AB%8B-ssdlc-agent-team-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub Copilot 建立 SSDLC Agent Team 教學手冊 文件目錄：.github/教學/AI開發/\n文件檔名：GitHub Copilot 建立 SSDLC Agent Team 教學手冊.md\n目錄 0. 文件資訊與閱讀指南 1. 總覽：什麼是 GitHub Copilot SSDLC Agent Team 2. 最新功能盤點與術語對照 2.1 功能矩陣表 2.2 功能可用環境比較表 2.3 Preview / GA / Plan Requirement 對照表 2.4 容易混淆概念比較表 2.5 第三方 Agent 與 Auto Model Selection 模型對照 2.6 Copilot Integrations 支援平台 2.7 CLI Built-in Agents 功能說明 3. SSDLC Agent Team 企業架構設計 3.1 Agent 職責總覽 3.2 Mermaid 架構圖 3.3 Agent 協作流程圖 3.4 Agent RACI 表 3.5 Agent 與 SSDLC 階段對應表 3.6 模型分配策略 4. 平台安裝與環境建置 4.1 VS Code 安裝與版本建議 4.2 GitHub Copilot 擴充套件安裝 4.3 GitHub Copilot CLI 安裝 4.4 組織管理員政策設定 4.5 設定檢查清單 4.6 常見安裝錯誤與排除 5. 專案初始化與標準目錄設計 5.1 標準目錄樹 5.2 檔案用途說明 5.3 VS Code 與 GitHub.com / CLI 格式差異 5.4 Project / User / Org 層級差異 5.5 版本控管策略 6. 建立 Custom Agent（⭐ 重點章節） 6.1 Agent Profile 格式詳解 6.2 Agent 1 — Planner（規劃 Agent） 6.3 Agent 2 — Architect（架構 Agent） 6.4 Agent 3 — Backend Developer（後端開發 Agent） 6.5 Agent 4 — Frontend Developer（前端開發 Agent） 6.6 Agent 5 — Test Generator（測試 Agent） 6.7 Agent 6 — Security Reviewer（安全審查 Agent） 6.8 Agent 7 — Code Reviewer（程式碼審查 Agent） 6.9 Agent 8 — Release Agent（發版 Agent） 6.10 Agent 9 — Reverse Engineering Agent（逆向工程 Agent） 6.11 Agent 10 — Doc Writer（文件 Agent） 6.12 Agent 11 — Project Manager（專案管理 Agent） 6.13 Agent-Scoped Hooks（Preview） 6.14 Orchestrator Agent 模式 6.15 Agent 設計最佳實務 7. 建立 Prompt（Prompt Library） 7.1 Prompt File 概念 7.2 SSDLC 各階段 Prompt 範本 7.3 Prompt 設計原則 7.4 Prompt 管理策略 8. 建立 Custom Instructions 8.1 Instructions 類型總覽 8.2 Repo-wide Instructions 8.3 File-based Instructions 8.4 AGENTS.md 8.5 組織層級 Instructions 8.6 Instructions 設計最佳實務 9. 建立 Agent Skills 9.1 Skills 概念 9.2 Skill 1 — Security Review 9.3 Skill 2 — JUnit Test Generator 9.4 Skill 3 — PR Checker 9.5 Skill 4 — API Reviewer 9.6 Skill 5 — Reverse Analysis 9.7 Skill 6 — Doc Generator 9.8 Skills 管理策略 9.9 CLI Plugins：封裝與分發 Agent Team 元件 10. 設定 Hooks 10.1 Hooks 概念與生命週期 10.2 Hook 設定檔格式與放置位置 10.3 VS Code Hooks 設定（Preview） 10.4 Agent-scoped Hooks 10.5 Hook 輸入與輸出機制 10.6 Cloud Agent / CLI Hooks 10.7 SSDLC 護欄策略與 Autopilot 風險 10.8 Hooks 安全考量與最佳實務 11. 管理 Copilot Memory 11.1 Memory 概念 11.2 Memory 儲存類型與運作機制 11.3 啟用 Memory 11.4 Memory 治理 11.5 Memory 最佳實務 12. PR 工作流程（PR Workflow） 12.1 概述 12.2 Copilot 自動 PR Review 12.3 PR Workflow 自動化 12.4 Copilot 在 PR 中的互動 12.5 Agent Management Tab（Agents 管理面板） 12.6 PR 品質指標 12.7 Copilot Integrations（第三方平台整合） 13. SSDLC 全流程整合（⭐ 全文件核心） 13.1 概述 13.2 SSDLC 全流程圖 13.3 各階段 Agent 協作詳解 13.4 Agent Handoff 流程 13.5 端到端範例 13.6 SSDLC 成熟度模型 13.7 企業導入策略 14. 逆向工程（Reverse Engineering） 14.1 概述 14.2 逆向工程流程 14.3 使用 Reverse Agent 進行分析 14.4 逆向工程最佳實務 15. 團隊共享與新人引導 15.1 概述 15.2 團隊共享策略 15.3 新人引導流程 15.4 知識傳承機制 15.5 常見團隊問題與解答 16. 安全治理、合規與成本管理 16.1 概述 16.2 安全治理框架 16.3 法規合規 16.4 成本管理 16.5 使用監控與稽核 17. 維護、升級與版本管理 17.1 概述 17.2 維護策略 17.3 版本管理策略 17.4 平台升級追蹤 17.5 故障排除 18. 案例研究 18.1 概述 18.2 案例一：電商平台 API 開發 18.3 案例二：遺留系統現代化改造 19. 常見問題（FAQ） 20. 最佳實務與檢查清單 21. 附錄：即用範本集 0. 文件資訊與閱讀指南 文件基本資訊 本手冊定位為企業導入 GitHub Copilot Agent 能力的技術白皮書，說明如何以 SSDLC（安全軟體開發生命週期）為骨架，將 Custom Agent、Skills、Instructions、Hooks、Memory 等原生能力組裝成一支可治理的「Agent Team」。內容以官方文件為事實基礎，並加入企業導入時的架構判斷與實務建議。\n","title":"GitHub Copilot 建立 SSDLC Agent Team 教學手冊"},{"content":"Github Copilot生態圈教學手冊 版本：5.0\n最後更新：2026 年 5 月 28 日\n適用對象：資深工程師 / Tech Lead / Architect\n適用於：GitHub Copilot (Free / Student / Pro / Pro+ / Max / Business / Enterprise)\nVS Code 版本：1.111+\n重大異動：2026 年 6 月 1 日起全面轉換為 AI Credits 用量計費制（Token-based）\nCreated by：Eric Cheng\n目錄 第一章 GitHub Copilot 生態圈全貌總覽 1.1 什麼是 GitHub Copilot 生態圈 1.2 生態圈各組件說明 1.3 Copilot 在企業開發流程中的定位 1.4 版本與授權模式 1.5 AI Credits 計費機制詳解 1.5.1 AI Credits 運作原理 1.5.2 Credits 使用優先順序 1.5.3 哪些功能消耗 AI Credits 1.5.4 Copilot Code Review 的特殊計費 1.5.5 企業成本管控策略 1.6 Copilot Cloud Agent 整合平台 1.7 2025-2026 年新功能重點摘要 第二章 Copilot 與「資深工程師角色」的正確關係 2.1 思維轉換：從「工具」到「協作夥伴」 2.2 資深工程師的不可取代價值 2.3 正確的協作模式 2.4 效率提升的正確期待 第三章 Copilot 在實際開發流程中的使用時機 3.1 開發流程與 Copilot 介入點 3.2 各階段使用策略 3.3 不同類型任務的使用建議 3.4 與現有工具鏈整合 3.5 實務案例：一個完整的開發循環 第四章 Copilot Prompt Engineering（重點章節） 4.1 Prompt Engineering 核心觀念 4.2 Inline Completion Prompt 技巧 4.3 Copilot Chat Prompt 技巧 4.4 Bad Prompt vs Good Prompt 對照 4.5 進階 Prompt Pattern 4.6 Prompt Template 庫 4.7 Copilot Chat 快捷指令與互動方式 4.8 Custom Instructions 與自訂化框架 4.8.1 Custom Instructions 4.8.2 Prompt Files 4.8.3 Agent Skills 4.8.4 Custom Agents 4.8.5 Agent Hooks 4.8.6 Agent Plugins 4.8.7 Chat Customizations Editor 4.8.8 MCP 整合 4.9 Copilot CLI 內建代理（Built-in Agents） 4.10 VS Code Agents Window（Preview） 4.11 Custom Agent Handoffs（工作流程交接） 4.12 Copilot Memory 深入指南 第五章 Copilot + Code Review + Testing 最佳實務 5.1 Copilot 與 Code Review 的整合 5.2 Copilot 與 Testing 的整合 5.3 CI/CD 整合建議 5.4 實務案例：完整的測試策略 第六章 資安、法遵與風險控管 6.1 Copilot 的資安風險概覽 6.2 常見安全漏洞與防範 6.3 Copilot 生成程式碼的審查清單 6.4 法遵考量 6.5 企業級安全設定 6.6 Copilot 在 SSDLC 中的定位 6.7 稽核與追蹤 第七章 常見誤用與反模式 7.1 Anti-Pattern 總覽 7.2 Anti-Pattern 詳解 7.3 Copilot 不適合做的事情 7.4 常見錯誤案例分析 7.5 自我檢查清單 第八章 團隊導入與治理建議 8.1 導入成熟度模型 8.2 各階段導入建議 8.3 團隊使用規範範本 8.4 Code Review 要點（Copilot 輔助後） 8.5 效益衡量指標 8.6 組織架構建議 第九章 進階應用案例 9.1 案例一：Legacy Code 重構 9.2 案例二：API 設計與實作 9.3 案例三：Batch 程式開發 9.4 案例四：架構文件生成 9.5 案例五：使用 Copilot Coding Agent 自動化開發 9.6 最佳實務總結 第十章 總結：如何把 Copilot 變成「資深工程師的放大器」 10.1 核心心法 10.2 黃金法則 10.3 技能發展路徑 10.4 持續改善框架 10.5 未來展望 附錄 A. 日常使用檢查清單 B. Code Review 檢查清單（Copilot 輔助程式碼） C. 團隊導入檢查清單 D. Prompt 範本快速參考 E. Copilot 自訂化功能速查表 參考資源 第一章 GitHub Copilot 生態圈全貌總覽 1.1 什麼是 GitHub Copilot 生態圈 GitHub Copilot 已從單純的「程式碼自動補全工具」演進為完整的 AI 輔助開發生態系統。截至 2026 年中，Copilot 生態圈涵蓋了從程式碼補全、對話式 AI、自主編碼代理到企業治理的全方位功能。對資深工程師而言，理解其全貌是有效運用的前提。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-copilot%E7%94%9F%E6%85%8B%E5%9C%88%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Github Copilot生態圈教學手冊 版本：5.0\n最後更新：2026 年 5 月 28 日\n適用對象：資深工程師 / Tech Lead / Architect\n適用於：GitHub Copilot (Free / Student / Pro / Pro+ / Max / Business / Enterprise)\nVS Code 版本：1.111+\n重大異動：2026 年 6 月 1 日起全面轉換為 AI Credits 用量計費制（Token-based）\nCreated by：Eric Cheng\n目錄 第一章 GitHub Copilot 生態圈全貌總覽 1.1 什麼是 GitHub Copilot 生態圈 1.2 生態圈各組件說明 1.3 Copilot 在企業開發流程中的定位 1.4 版本與授權模式 1.5 AI Credits 計費機制詳解 1.5.1 AI Credits 運作原理 1.5.2 Credits 使用優先順序 1.5.3 哪些功能消耗 AI Credits 1.5.4 Copilot Code Review 的特殊計費 1.5.5 企業成本管控策略 1.6 Copilot Cloud Agent 整合平台 1.7 2025-2026 年新功能重點摘要 第二章 Copilot 與「資深工程師角色」的正確關係 2.1 思維轉換：從「工具」到「協作夥伴」 2.2 資深工程師的不可取代價值 2.3 正確的協作模式 2.4 效率提升的正確期待 第三章 Copilot 在實際開發流程中的使用時機 3.1 開發流程與 Copilot 介入點 3.2 各階段使用策略 3.3 不同類型任務的使用建議 3.4 與現有工具鏈整合 3.5 實務案例：一個完整的開發循環 第四章 Copilot Prompt Engineering（重點章節） 4.1 Prompt Engineering 核心觀念 4.2 Inline Completion Prompt 技巧 4.3 Copilot Chat Prompt 技巧 4.4 Bad Prompt vs Good Prompt 對照 4.5 進階 Prompt Pattern 4.6 Prompt Template 庫 4.7 Copilot Chat 快捷指令與互動方式 4.8 Custom Instructions 與自訂化框架 4.8.1 Custom Instructions 4.8.2 Prompt Files 4.8.3 Agent Skills 4.8.4 Custom Agents 4.8.5 Agent Hooks 4.8.6 Agent Plugins 4.8.7 Chat Customizations Editor 4.8.8 MCP 整合 4.9 Copilot CLI 內建代理（Built-in Agents） 4.10 VS Code Agents Window（Preview） 4.11 Custom Agent Handoffs（工作流程交接） 4.12 Copilot Memory 深入指南 第五章 Copilot + Code Review + Testing 最佳實務 5.1 Copilot 與 Code Review 的整合 5.2 Copilot 與 Testing 的整合 5.3 CI/CD 整合建議 5.4 實務案例：完整的測試策略 第六章 資安、法遵與風險控管 6.1 Copilot 的資安風險概覽 6.2 常見安全漏洞與防範 6.3 Copilot 生成程式碼的審查清單 6.4 法遵考量 6.5 企業級安全設定 6.6 Copilot 在 SSDLC 中的定位 6.7 稽核與追蹤 第七章 常見誤用與反模式 7.1 Anti-Pattern 總覽 7.2 Anti-Pattern 詳解 7.3 Copilot 不適合做的事情 7.4 常見錯誤案例分析 7.5 自我檢查清單 第八章 團隊導入與治理建議 8.1 導入成熟度模型 8.2 各階段導入建議 8.3 團隊使用規範範本 8.4 Code Review 要點（Copilot 輔助後） 8.5 效益衡量指標 8.6 組織架構建議 第九章 進階應用案例 9.1 案例一：Legacy Code 重構 9.2 案例二：API 設計與實作 9.3 案例三：Batch 程式開發 9.4 案例四：架構文件生成 9.5 案例五：使用 Copilot Coding Agent 自動化開發 9.6 最佳實務總結 第十章 總結：如何把 Copilot 變成「資深工程師的放大器」 10.1 核心心法 10.2 黃金法則 10.3 技能發展路徑 10.4 持續改善框架 10.5 未來展望 附錄 A. 日常使用檢查清單 B. Code Review 檢查清單（Copilot 輔助程式碼） C. 團隊導入檢查清單 D. Prompt 範本快速參考 E. Copilot 自訂化功能速查表 參考資源 第一章 GitHub Copilot 生態圈全貌總覽 1.1 什麼是 GitHub Copilot 生態圈 GitHub Copilot 已從單純的「程式碼自動補全工具」演進為完整的 AI 輔助開發生態系統。截至 2026 年中，Copilot 生態圈涵蓋了從程式碼補全、對話式 AI、自主編碼代理到企業治理的全方位功能。對資深工程師而言，理解其全貌是有效運用的前提。\n","title":"Github Copilot生態圈教學手冊"},{"content":"Understand-Anything 企業級教學手冊 版本：v2.7.5（對應 2026-06 官方最新版） 適用對象：資深工程師、架構師、技術主管 最後更新：2026 年 5 月 25 日 授權：MIT License 官方 Repo：Lum1104/Understand-Anything 官方首頁：understand-anything.com 線上 Demo：understand-anything.com/demo Discord 社群：discord.gg/pydat66RY\n目錄 1. Understand-Anything 簡介 2. 系統架構 3. 核心功能詳解 4. 安裝與環境建置 5. Claude Code 整合 6. GitHub Copilot / Cursor / Codex 整合 7. Web Application 開發實戰 8. Legacy System Reverse Engineering 9. Framework 升級實戰 10. Knowledge Graph 深入解析 11. Token Cost 最佳化與 Hybrid 分析模式 12. SSDLC 與 AI 治理 13. 團隊導入最佳實務 14. 維運與監控 15. Troubleshooting 常見問題排除 16. 最佳實務 17. 企業級架構建議 18. 未來發展方向 19. 結論 20. AI Prompt Engineering 專章 21. Agent Workflow 專章 22. 大型共用平台案例 23. 檢查清單（Checklist） 附錄 1. Understand-Anything 簡介 1.1 專案背景 Understand-Anything 是 GitHub 上星數超過 28,000 的開源 AI Codebase Understanding Framework，由 Lum1104 於 2026 年初創建。它的核心理念是：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/understand-anything-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Understand-Anything 企業級教學手冊 版本：v2.7.5（對應 2026-06 官方最新版） 適用對象：資深工程師、架構師、技術主管 最後更新：2026 年 5 月 25 日 授權：MIT License 官方 Repo：Lum1104/Understand-Anything 官方首頁：understand-anything.com 線上 Demo：understand-anything.com/demo Discord 社群：discord.gg/pydat66RY\n目錄 1. Understand-Anything 簡介 2. 系統架構 3. 核心功能詳解 4. 安裝與環境建置 5. Claude Code 整合 6. GitHub Copilot / Cursor / Codex 整合 7. Web Application 開發實戰 8. Legacy System Reverse Engineering 9. Framework 升級實戰 10. Knowledge Graph 深入解析 11. Token Cost 最佳化與 Hybrid 分析模式 12. SSDLC 與 AI 治理 13. 團隊導入最佳實務 14. 維運與監控 15. Troubleshooting 常見問題排除 16. 最佳實務 17. 企業級架構建議 18. 未來發展方向 19. 結論 20. AI Prompt Engineering 專章 21. Agent Workflow 專章 22. 大型共用平台案例 23. 檢查清單（Checklist） 附錄 1. Understand-Anything 簡介 1.1 專案背景 Understand-Anything 是 GitHub 上星數超過 28,000 的開源 AI Codebase Understanding Framework，由 Lum1104 於 2026 年初創建。它的核心理念是：\n","title":"Understand Anything 教學手冊"},{"content":"claude-mem 教學手冊 版本: v13.3.0 | 最後更新: 2026-05-25 | 授權: Apache License 2.0\n本手冊適用對象：初學者、中階工程師、資深架構師、AI Agent 開發團隊\n官方網站：claude-mem.ai | GitHub：thedotmack/claude-mem\n目錄 1. claude-mem 介紹 2. 核心架構 3. 安裝教學 4. 設定教學 5. MCP（Model Context Protocol）整合 6. 記憶工作流程（3-Layer Workflow） 7. Claude Code 整合 8. GitHub Copilot 整合 9. Web Application 開發實戰 10. Reverse Engineering 實戰 11. Framework Upgrade 實戰 12. Token Optimization Strategies 13. Enterprise Architecture 14. SQLite 與資料結構分析 15. Hooks 與 Worker 深入解析 16. Context Injection 深入解析 17. 實戰 Prompt Engineering 18. 團隊導入建議 19. 維運與升級 20. Troubleshooting 21. 最佳實務（Best Practices） 22. 安全性（Security） 23. 效能調校（Performance Tuning） 24. 與其他工具比較 25. File Read Gate（檔案讀取攔截） 26. Folder Context Files（資料夾上下文檔案） 27. Knowledge Agents（知識代理人） 28. Beta 功能與 Endless Mode 29. OpenClaw 整合 30. Smart Explore（AST 智慧探索） 31. 未來發展與 AI Agent Memory 趨勢 32. FAQ 與檢查清單 1. claude-mem 介紹 1.1 什麼是 claude-mem claude-mem 是一套持久化記憶壓縮系統（Persistent Memory Compression System），專為 Claude Code 及其他 AI Coding Agent 設計。它能在開發者與 AI Agent 互動的過程中，自動擷取工具使用的觀察記錄（Observations），透過 AI 進行語意壓縮，並在未來的 Session 中自動注入相關上下文（Context），讓 AI 得以跨 Session 維持對專案的認知與記憶。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-mem-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"claude-mem 教學手冊 版本: v13.3.0 | 最後更新: 2026-05-25 | 授權: Apache License 2.0\n本手冊適用對象：初學者、中階工程師、資深架構師、AI Agent 開發團隊\n官方網站：claude-mem.ai | GitHub：thedotmack/claude-mem\n目錄 1. claude-mem 介紹 2. 核心架構 3. 安裝教學 4. 設定教學 5. MCP（Model Context Protocol）整合 6. 記憶工作流程（3-Layer Workflow） 7. Claude Code 整合 8. GitHub Copilot 整合 9. Web Application 開發實戰 10. Reverse Engineering 實戰 11. Framework Upgrade 實戰 12. Token Optimization Strategies 13. Enterprise Architecture 14. SQLite 與資料結構分析 15. Hooks 與 Worker 深入解析 16. Context Injection 深入解析 17. 實戰 Prompt Engineering 18. 團隊導入建議 19. 維運與升級 20. Troubleshooting 21. 最佳實務（Best Practices） 22. 安全性（Security） 23. 效能調校（Performance Tuning） 24. 與其他工具比較 25. File Read Gate（檔案讀取攔截） 26. Folder Context Files（資料夾上下文檔案） 27. Knowledge Agents（知識代理人） 28. Beta 功能與 Endless Mode 29. OpenClaw 整合 30. Smart Explore（AST 智慧探索） 31. 未來發展與 AI Agent Memory 趨勢 32. FAQ 與檢查清單 1. claude-mem 介紹 1.1 什麼是 claude-mem claude-mem 是一套持久化記憶壓縮系統（Persistent Memory Compression System），專為 Claude Code 及其他 AI Coding Agent 設計。它能在開發者與 AI Agent 互動的過程中，自動擷取工具使用的觀察記錄（Observations），透過 AI 進行語意壓縮，並在未來的 Session 中自動注入相關上下文（Context），讓 AI 得以跨 Session 維持對專案的認知與記憶。\n","title":"Claude Mem 教學手冊"},{"content":"RTK (Rust Token Killer) 教學手冊 版本：v2.0（2026-05-25）\nRTK 版本：v0.42.0（Apache License 2.0）\n適用對象：資深工程師、AI 開發團隊、DevOps 工程師、架構師\n定位：企業級 AI Coding 開發平台導入指南 / Token 成本治理手冊\n專案規模：53.7k+ Stars、3.3k+ Forks、97+ 貢獻者、179+ Releases\n目錄 1. RTK 簡介 1.1 RTK 是什麼 1.2 為什麼需要 RTK 1.3 AI Coding Token 問題 1.4 Token Cost Explosion 問題 1.5 RTK 解決了哪些問題 1.6 RTK 適合哪些團隊與專案 1.7 核心設計理念 1.8 技術優勢 1.9 RTK 的限制 1.10 RTK 版本演進與里程碑 2. RTK 系統架構 2.1 CLI Architecture 2.2 Hook 機制 2.3 Command Interception 2.4 Output Compression Pipeline 2.5 Filtering Strategies 2.6 Tee Mode 2.7 Token Tracking System 2.8 TOML 自訂過濾器 2.9 架構圖 3. RTK 安裝教學 3.1 Homebrew（推薦） 3.2 Quick Install（Linux/macOS） 3.3 Cargo 安裝 3.4 Windows 3.5 Linux 3.6 macOS 3.7 Container / DevContainer 3.8 WSL2 3.9 企業 Proxy 環境 3.10 離線安裝 3.11 驗證安裝 3.12 名稱衝突警告 3.13 常見錯誤與 Troubleshooting 4. RTK 核心功能詳解 4.1 Smart Filtering 4.2 Grouping 4.3 Truncation 4.4 Deduplication 4.5 Tee Mode 4.6 Ultra Compact 4.7 Token Saving Analytics 4.8 discover 4.9 gain 4.10 session 4.11 smart 4.12 read 4.13 test 4.14 gh 4.15 git 5. RTK CLI 指令大全 5.1 rtk ls 5.2 rtk read 5.3 rtk smart 5.4 rtk test 5.5 rtk git 5.6 rtk gh 5.7 rtk gain 5.8 rtk discover 5.9 rtk session 5.10 rtk docker 5.11 rtk kubectl 5.12 rtk aws 5.13 rtk find / rtk grep / rtk diff 5.14 rtk json / rtk log / rtk env / rtk deps 5.15 rtk proxy / rtk summary / rtk curl / rtk wget 6. Claude Code 整合 6.1 Claude Code Hook 機制 6.2 自動指令改寫 6.3 Shell Hook 設定 6.4 Token Reduction Workflow 6.5 大型專案最佳化 6.6 Multi-Agent Workflow 6.7 最佳實務 7. GitHub Copilot 整合 7.1 VSCode Integration 7.2 Copilot Chat 7.3 Terminal Workflow 7.4 Prompt Engineering 7.5 Token Optimization 7.6 Workspace Strategy 8. 多元 AI 工具整合 8.1 Cursor 整合 8.2 Gemini CLI 整合 8.3 Codex（OpenAI）整合 8.4 Windsurf / Cline / Roo Code 整合 8.5 OpenCode / OpenClaw 整合 8.6 Hermes / Kilo Code / Antigravity 整合 8.7 AI 工具整合總覽與比較 9. Reverse Engineering 使用情境 9.1 Legacy System 分析 9.2 Monolith 系統分析 9.3 大型 Repo 探索 9.4 巨量 Logs 處理 9.5 Decompiled Source 分析 9.6 API Trace / Stack Trace 分析 10. Framework Upgrade 使用情境 10.1 Spring Boot Upgrade 10.2 React / Vue / Angular Upgrade 10.3 Node.js Upgrade 10.4 Rust Upgrade 10.5 大規模升級策略 11. Web Application 開發最佳實務 11.1 Frontend Workflow 11.2 Backend Workflow 11.3 Fullstack Workflow 11.4 Microservices 11.5 Monorepo 11.6 CI/CD 12. DevOps 與 Cloud Native 整合 12.1 Docker 12.2 Kubernetes 12.3 AWS CLI 12.4 Azure CLI 12.5 GCP CLI 12.6 GitHub Actions 12.7 GitLab CI 13. 多語言生態系支援 13.1 Rust 生態系 13.2 Python 生態系 13.3 Go 生態系 13.4 Ruby 生態系 13.5 .NET 生態系 13.6 Java 生態系 14. 團隊導入策略 14.1 Enterprise Rollout 14.2 Governance 14.3 AI Development Standard 14.4 Team Rules 14.5 Prompt Standardization 14.6 Token Budget Management 15. Token 成本治理 15.1 Token Budget 15.2 Usage Analytics 15.3 Cost Governance 15.4 AI Usage KPI 15.5 Team Cost Dashboard 16. 安全性與風險管理 16.1 Secrets Filtering 16.2 PII Protection 16.3 Log Sanitization 16.4 Secure AI Workflow 16.5 隱私與遙測管理 17. RTK 維運管理 17.1 Upgrade Strategy 17.2 Version Management 17.3 Backup \u0026amp; Restore 17.4 Troubleshooting 17.5 Monitoring 17.6 Performance Tuning 18. RTK 最佳實務 18.1 50 條 Best Practices 18.2 50 條 Anti-Patterns 18.3 50 條 Prompt Engineering Tips 19. 企業級 AI Coding Platform 架構 19.1 平台架構設計 19.2 Claude Code + RTK 19.3 Copilot + RTK 19.4 Cursor + RTK 19.5 MCP Server / AI Gateway 19.6 Enterprise AI Workflow 20. 完整實戰案例 20.1 案例一：大型 Spring Boot Monolith Modernization 20.2 案例二：大型 React Monorepo 20.3 案例三：Legacy COBOL Reverse Engineering 20.4 案例四：Microservices Migration 20.5 案例五：大型 Kubernetes Platform 21. 附錄 21.1 Cheat Sheet 21.2 CLI Quick Reference 21.3 Hook Templates 21.4 Shell Templates 21.5 VSCode Settings 21.6 Configuration Files 21.7 Troubleshooting FAQ 21.8 導入準備 Checklist 21.9 官方資源與社群 1. RTK 簡介 1.1 RTK 是什麼 RTK（Rust Token Killer）是一款以 Rust 語言開發的高效能 CLI 代理工具（CLI Proxy），專為 AI Coding 時代設計。它在開發者的 Shell 指令與 LLM（大型語言模型）之間擔任「中間層」，自動攔截、過濾並壓縮命令輸出，從而將 LLM Token 消耗降低 60-90%。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/rtk-rust-token-killer-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"RTK (Rust Token Killer) 教學手冊 版本：v2.0（2026-05-25）\nRTK 版本：v0.42.0（Apache License 2.0）\n適用對象：資深工程師、AI 開發團隊、DevOps 工程師、架構師\n定位：企業級 AI Coding 開發平台導入指南 / Token 成本治理手冊\n專案規模：53.7k+ Stars、3.3k+ Forks、97+ 貢獻者、179+ Releases\n目錄 1. RTK 簡介 1.1 RTK 是什麼 1.2 為什麼需要 RTK 1.3 AI Coding Token 問題 1.4 Token Cost Explosion 問題 1.5 RTK 解決了哪些問題 1.6 RTK 適合哪些團隊與專案 1.7 核心設計理念 1.8 技術優勢 1.9 RTK 的限制 1.10 RTK 版本演進與里程碑 2. RTK 系統架構 2.1 CLI Architecture 2.2 Hook 機制 2.3 Command Interception 2.4 Output Compression Pipeline 2.5 Filtering Strategies 2.6 Tee Mode 2.7 Token Tracking System 2.8 TOML 自訂過濾器 2.9 架構圖 3. RTK 安裝教學 3.1 Homebrew（推薦） 3.2 Quick Install（Linux/macOS） 3.3 Cargo 安裝 3.4 Windows 3.5 Linux 3.6 macOS 3.7 Container / DevContainer 3.8 WSL2 3.9 企業 Proxy 環境 3.10 離線安裝 3.11 驗證安裝 3.12 名稱衝突警告 3.13 常見錯誤與 Troubleshooting 4. RTK 核心功能詳解 4.1 Smart Filtering 4.2 Grouping 4.3 Truncation 4.4 Deduplication 4.5 Tee Mode 4.6 Ultra Compact 4.7 Token Saving Analytics 4.8 discover 4.9 gain 4.10 session 4.11 smart 4.12 read 4.13 test 4.14 gh 4.15 git 5. RTK CLI 指令大全 5.1 rtk ls 5.2 rtk read 5.3 rtk smart 5.4 rtk test 5.5 rtk git 5.6 rtk gh 5.7 rtk gain 5.8 rtk discover 5.9 rtk session 5.10 rtk docker 5.11 rtk kubectl 5.12 rtk aws 5.13 rtk find / rtk grep / rtk diff 5.14 rtk json / rtk log / rtk env / rtk deps 5.15 rtk proxy / rtk summary / rtk curl / rtk wget 6. Claude Code 整合 6.1 Claude Code Hook 機制 6.2 自動指令改寫 6.3 Shell Hook 設定 6.4 Token Reduction Workflow 6.5 大型專案最佳化 6.6 Multi-Agent Workflow 6.7 最佳實務 7. GitHub Copilot 整合 7.1 VSCode Integration 7.2 Copilot Chat 7.3 Terminal Workflow 7.4 Prompt Engineering 7.5 Token Optimization 7.6 Workspace Strategy 8. 多元 AI 工具整合 8.1 Cursor 整合 8.2 Gemini CLI 整合 8.3 Codex（OpenAI）整合 8.4 Windsurf / Cline / Roo Code 整合 8.5 OpenCode / OpenClaw 整合 8.6 Hermes / Kilo Code / Antigravity 整合 8.7 AI 工具整合總覽與比較 9. Reverse Engineering 使用情境 9.1 Legacy System 分析 9.2 Monolith 系統分析 9.3 大型 Repo 探索 9.4 巨量 Logs 處理 9.5 Decompiled Source 分析 9.6 API Trace / Stack Trace 分析 10. Framework Upgrade 使用情境 10.1 Spring Boot Upgrade 10.2 React / Vue / Angular Upgrade 10.3 Node.js Upgrade 10.4 Rust Upgrade 10.5 大規模升級策略 11. Web Application 開發最佳實務 11.1 Frontend Workflow 11.2 Backend Workflow 11.3 Fullstack Workflow 11.4 Microservices 11.5 Monorepo 11.6 CI/CD 12. DevOps 與 Cloud Native 整合 12.1 Docker 12.2 Kubernetes 12.3 AWS CLI 12.4 Azure CLI 12.5 GCP CLI 12.6 GitHub Actions 12.7 GitLab CI 13. 多語言生態系支援 13.1 Rust 生態系 13.2 Python 生態系 13.3 Go 生態系 13.4 Ruby 生態系 13.5 .NET 生態系 13.6 Java 生態系 14. 團隊導入策略 14.1 Enterprise Rollout 14.2 Governance 14.3 AI Development Standard 14.4 Team Rules 14.5 Prompt Standardization 14.6 Token Budget Management 15. Token 成本治理 15.1 Token Budget 15.2 Usage Analytics 15.3 Cost Governance 15.4 AI Usage KPI 15.5 Team Cost Dashboard 16. 安全性與風險管理 16.1 Secrets Filtering 16.2 PII Protection 16.3 Log Sanitization 16.4 Secure AI Workflow 16.5 隱私與遙測管理 17. RTK 維運管理 17.1 Upgrade Strategy 17.2 Version Management 17.3 Backup \u0026amp; Restore 17.4 Troubleshooting 17.5 Monitoring 17.6 Performance Tuning 18. RTK 最佳實務 18.1 50 條 Best Practices 18.2 50 條 Anti-Patterns 18.3 50 條 Prompt Engineering Tips 19. 企業級 AI Coding Platform 架構 19.1 平台架構設計 19.2 Claude Code + RTK 19.3 Copilot + RTK 19.4 Cursor + RTK 19.5 MCP Server / AI Gateway 19.6 Enterprise AI Workflow 20. 完整實戰案例 20.1 案例一：大型 Spring Boot Monolith Modernization 20.2 案例二：大型 React Monorepo 20.3 案例三：Legacy COBOL Reverse Engineering 20.4 案例四：Microservices Migration 20.5 案例五：大型 Kubernetes Platform 21. 附錄 21.1 Cheat Sheet 21.2 CLI Quick Reference 21.3 Hook Templates 21.4 Shell Templates 21.5 VSCode Settings 21.6 Configuration Files 21.7 Troubleshooting FAQ 21.8 導入準備 Checklist 21.9 官方資源與社群 1. RTK 簡介 1.1 RTK 是什麼 RTK（Rust Token Killer）是一款以 Rust 語言開發的高效能 CLI 代理工具（CLI Proxy），專為 AI Coding 時代設計。它在開發者的 Shell 指令與 LLM（大型語言模型）之間擔任「中間層」，自動攔截、過濾並壓縮命令輸出，從而將 LLM Token 消耗降低 60-90%。\n","title":"RTK (Rust Token Killer) 教學手冊"},{"content":"PRD（產品需求文件｜Product Requirement Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 29148:2018、ISO 9241-210:2019、IIBA BABOK v3\n適用對象：產品經理、UI/UX 設計師、業務分析師、開發團隊\n文件性質：產品需求定義與功能規劃文件\n📋 使用說明 PRD 是將商業目標轉譯為具體功能需求的關鍵文件，定義「產品要做什麼」。它是 UI/UX 設計師與工程團隊開發的主要依據，橋接業務需求（BRD）與技術實作（SDD/TSD）之間的落差。\n何時使用本範本 新產品或新功能的需求定義階段 產品重大改版前的需求整理 跨部門協作時的需求溝通基準文件 填寫原則 以使用者為中心：所有功能描述應從使用者角度出發 量化可驗證：驗收條件必須可量化、可測試 優先序明確：使用 MoSCoW 或數字排序標明優先級 迭代更新：隨需求演進持續更新文件版本 📄 範本正文 [產品/功能名稱] 產品需求文件（PRD） 1. 文件資訊 項目 內容 文件編號 PRD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [產品經理姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 / 已凍結 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 2. 產品概述 2.1 產品願景 簡述本產品/功能的願景，說明為何需要此產品，以及期望達成的長期目標。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/prd_template/","summary":"PRD（產品需求文件｜Product Requirement Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 29148:2018、ISO 9241-210:2019、IIBA BABOK v3\n適用對象：產品經理、UI/UX 設計師、業務分析師、開發團隊\n文件性質：產品需求定義與功能規劃文件\n📋 使用說明 PRD 是將商業目標轉譯為具體功能需求的關鍵文件，定義「產品要做什麼」。它是 UI/UX 設計師與工程團隊開發的主要依據，橋接業務需求（BRD）與技術實作（SDD/TSD）之間的落差。\n何時使用本範本 新產品或新功能的需求定義階段 產品重大改版前的需求整理 跨部門協作時的需求溝通基準文件 填寫原則 以使用者為中心：所有功能描述應從使用者角度出發 量化可驗證：驗收條件必須可量化、可測試 優先序明確：使用 MoSCoW 或數字排序標明優先級 迭代更新：隨需求演進持續更新文件版本 📄 範本正文 [產品/功能名稱] 產品需求文件（PRD） 1. 文件資訊 項目 內容 文件編號 PRD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [產品經理姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 / 已凍結 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 2. 產品概述 2.1 產品願景 簡述本產品/功能的願景，說明為何需要此產品，以及期望達成的長期目標。\n","title":"PRD（產品需求文件）範本"},{"content":"SDD（系統設計文件｜System Design Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 42010:2022、ISO/IEC 25010:2023、ISO/IEC/IEEE 15288:2023\n適用對象：系統架構師、資深開發工程師、技術主管\n文件性質：系統技術架構與設計決策文件\n📋 使用說明 SDD 用於制定技術解決方案，規劃「系統要如何實作」。內容涵蓋系統架構、資料庫綱要（Schema）、API 介面規格、模組劃分與資安規範，確保系統具備擴展性與穩定性。\n何時使用本範本 系統設計階段，將需求（PRD/FRD/SRD）轉化為技術方案 重大架構變更前的設計評審 跨團隊技術溝通的基準文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 決策可追溯：每個設計決策需記錄原因與替代方案 圖文並茂：架構圖、序列圖、ER 圖等應完整呈現 安全優先：每個模組需考慮資安面向 可演進：設計應預留擴展空間 📄 範本正文 [系統/模組名稱] 系統設計文件（SDD） 1. 文件資訊 項目 內容 文件編號 SDD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [架構師姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 關聯文件 文件名稱 文件編號 版本 關聯性 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 功能需求文件（FRD） FRD-XXX-001 v1.0 功能規格 系統需求規格書（SRD） SRD-XXX-001 v1.0 系統規格 2. 系統概述 2.1 系統背景與目標 簡述本系統的業務背景、核心問題，以及本設計文件欲達成的技術目標。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/sdd_template/","summary":"SDD（系統設計文件｜System Design Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 42010:2022、ISO/IEC 25010:2023、ISO/IEC/IEEE 15288:2023\n適用對象：系統架構師、資深開發工程師、技術主管\n文件性質：系統技術架構與設計決策文件\n📋 使用說明 SDD 用於制定技術解決方案，規劃「系統要如何實作」。內容涵蓋系統架構、資料庫綱要（Schema）、API 介面規格、模組劃分與資安規範，確保系統具備擴展性與穩定性。\n何時使用本範本 系統設計階段，將需求（PRD/FRD/SRD）轉化為技術方案 重大架構變更前的設計評審 跨團隊技術溝通的基準文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 決策可追溯：每個設計決策需記錄原因與替代方案 圖文並茂：架構圖、序列圖、ER 圖等應完整呈現 安全優先：每個模組需考慮資安面向 可演進：設計應預留擴展空間 📄 範本正文 [系統/模組名稱] 系統設計文件（SDD） 1. 文件資訊 項目 內容 文件編號 SDD-[專案代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [架構師姓名] 審核者 [審核者姓名 / 角色] 核准者 [核准者姓名 / 角色] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 審核紀錄 審核者 角色 審核日期 結果 備註 通過 / 有條件通過 / 退回 關聯文件 文件名稱 文件編號 版本 關聯性 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 功能需求文件（FRD） FRD-XXX-001 v1.0 功能規格 系統需求規格書（SRD） SRD-XXX-001 v1.0 系統規格 2. 系統概述 2.1 系統背景與目標 簡述本系統的業務背景、核心問題，以及本設計文件欲達成的技術目標。\n","title":"SDD（系統設計文件）範本"},{"content":"TSD（技術規格文件｜Technical Specification Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 15288:2023、ISO/IEC 25010:2023、IEEE 1016-2009\n適用對象：資深開發工程師、技術主管、QA 工程師\n文件性質：工程師實作指南與底層技術規格文件\n📋 使用說明 TSD 是工程師的實作指南，詳細說明「底層技術與程式碼邏輯」。內容涵蓋類別與函式設計、演算法邏輯、資料結構、錯誤處理機制及自動化測試規劃。\n何時使用本範本 進入開發實作階段前，將 SDD 的設計轉化為可直接編碼的技術規格 複雜演算法或業務邏輯需要詳細記錄時 技術交接或 Code Review 的參考文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 可直接編碼：規格描述需精確到可直接轉換為程式碼 測試可驗證：每個功能模組需附帶測試策略 錯誤完整：覆蓋所有已知的錯誤場景與處理方式 效能可量化：關鍵演算法需標注時間/空間複雜度 📄 範本正文 [模組/功能名稱] 技術規格文件（TSD） 1. 文件資訊 項目 內容 文件編號 TSD-[專案代碼]-[模組代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [工程師姓名] 審核者 [技術主管 / 架構師] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 關聯文件 文件名稱 文件編號 版本 關聯性 系統設計文件（SDD） SDD-XXX-001 v1.0 架構設計 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 API 規格文件 API-XXX-001 v1.0 介面規格 2. 技術概述 2.1 模組/功能範圍 簡述本 TSD 涵蓋的模組或功能範圍，以及與其他模組的邊界。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/tsd_template/","summary":"TSD（技術規格文件｜Technical Specification Document）範本 版本：1.0\n參照標準：ISO/IEC/IEEE 15288:2023、ISO/IEC 25010:2023、IEEE 1016-2009\n適用對象：資深開發工程師、技術主管、QA 工程師\n文件性質：工程師實作指南與底層技術規格文件\n📋 使用說明 TSD 是工程師的實作指南，詳細說明「底層技術與程式碼邏輯」。內容涵蓋類別與函式設計、演算法邏輯、資料結構、錯誤處理機制及自動化測試規劃。\n何時使用本範本 進入開發實作階段前，將 SDD 的設計轉化為可直接編碼的技術規格 複雜演算法或業務邏輯需要詳細記錄時 技術交接或 Code Review 的參考文件 與其他文件的關係 PRD（做什麼） → SDD（如何設計） → TSD（如何實作） ↑ ↑ ↑ 產品經理 架構師 開發工程師 填寫原則 可直接編碼：規格描述需精確到可直接轉換為程式碼 測試可驗證：每個功能模組需附帶測試策略 錯誤完整：覆蓋所有已知的錯誤場景與處理方式 效能可量化：關鍵演算法需標注時間/空間複雜度 📄 範本正文 [模組/功能名稱] 技術規格文件（TSD） 1. 文件資訊 項目 內容 文件編號 TSD-[專案代碼]-[模組代碼]-[序號] 版本 v0.1 建立日期 YYYY-MM-DD 最後更新 YYYY-MM-DD 撰寫者 [工程師姓名] 審核者 [技術主管 / 架構師] 狀態 草稿 / 審查中 / 已核准 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 YYYY-MM-DD [姓名] 初版建立 關聯文件 文件名稱 文件編號 版本 關聯性 系統設計文件（SDD） SDD-XXX-001 v1.0 架構設計 產品需求文件（PRD） PRD-XXX-001 v1.0 需求來源 API 規格文件 API-XXX-001 v1.0 介面規格 2. 技術概述 2.1 模組/功能範圍 簡述本 TSD 涵蓋的模組或功能範圍，以及與其他模組的邊界。\n","title":"TSD（技術規格文件）範本"},{"content":" 版本：2.0\n最後更新：2026 年 5 月 19 日 適用對象：後端工程師、前端工程師、QA 工程師、系統架構師、DevOps 工程師\n定位：企業內部標準教材\n文件維護：內部技術團隊\n適用於：Postman v12.x（2026 年最新穩定版，向下相容 v11.x）\nCreated by：Eric Cheng\nPostman 教學手冊 📋 教學大綱 Postman 簡介與概觀 1.1 Postman 是什麼？ 1.2 核心功能總覽 1.3 Postman 平台架構 1.4 版本與授權方案 1.5 與同類工具比較 1.6 適用場景與不適用場景 安裝與環境設定 2.1 桌面應用程式安裝 2.2 網頁版與 VS Code Extension 2.3 帳號註冊與登入 2.4 介面導覽 2.5 企業網路設定（Proxy / SSL） 2.6 團隊初始化設定 核心概念 3.1 Workspaces（工作區） 3.2 Collections（集合） 3.3 Environments 與 Variables 3.4 Authorization（認證與授權） 3.5 Postman Console 發送 API 請求 4.1 建立與發送 HTTP 請求 4.2 Request Body 格式 4.3 Response 檢視與分析 4.4 GraphQL 請求 4.5 gRPC 與 WebSocket 4.6 Cookie 與 Certificate 管理 變數與環境管理 5.1 變數作用域與優先順序 5.2 動態變數 5.3 環境切換策略 5.4 Postman Vault（敏感資料管理） 5.5 資料檔案驅動（CSV / JSON） 腳本開發（Tests \u0026amp; Scripts） 6.1 Pre-request Script 6.2 Post-response Script（測試斷言） 6.3 pm API 完整參考 6.4 Chai Assertion Library 6.5 請求鏈結（Chaining Requests） 6.6 常見測試範例 6.7 可重用腳本（Package Library） Collection Runner 與自動化測試 7.1 Collection Runner 使用 7.2 執行順序控制 7.3 Data-Driven Testing 7.4 效能測試 7.5 整合測試與回歸測試 Postman CLI 與 CI/CD 整合 8.1 Postman CLI 安裝與設定 8.2 命令列執行 Collection 8.3 Newman（傳統 CLI） 8.4 GitHub Actions 整合 8.5 Jenkins / Azure DevOps 整合 API 設計與文件 9.1 Spec Hub（OpenAPI / AsyncAPI） 9.2 Mock Server 設定 9.3 API 文件產生與發布 9.4 版本管理與 Native Git 9.5 SDK Generation（SDK 產生） 9.6 API Catalog（Enterprise） Postman Flows 10.1 Flows 概念與用途 10.2 建立視覺化工作流 10.3 實務案例 AI 功能（Agent Mode） 11.1 Postman AI 功能總覽 11.2 Agent Mode 深度指南 11.3 MCP Server 與 MCP Client 整合 11.4 AI Credits 管理與最佳化 團隊協作 12.1 團隊建立與管理 12.2 角色與權限 12.3 Version Control（Fork / Pull Request / Merge） 12.4 團隊工作區最佳實務 安全治理與 API Governance 13.1 Postman Secret Scanner 13.2 Postman Vault 與第三方整合 13.3 API Governance Rules 13.4 SSO / SCIM / Audit Log 13.5 BYOK 與 Data Residency 監控與效能 14.1 Monitor 設定與排程 14.2 效能指標與告警 14.3 Insights（Enterprise） 整合與擴充 15.1 第三方工具整合 15.2 Postman API 使用 15.3 Webhook 與自訂整合 企業導入策略 16.1 評估與導入路線圖 16.2 方案選擇與團隊培訓 16.3 標準化規範 最佳實務與反模式 17.1 最佳實務 17.2 常見反模式 常見問題與除錯（FAQ） 附錄 19.1 pm API 速查表 19.2 Chai Assertion 速查表 19.3 HTTP Status Code 速查表 19.4 快捷鍵速查表 19.5 新人上手 Checklist 19.6 API 測試 Checklist 19.7 安全性 Checklist 1. Postman 簡介與概觀 1.1 Postman 是什麼？ Postman 是全球領先的 AI 原生 API 平台，為超過 4,000 萬開發者與 50 萬以上的組織提供 API 開發、測試、文件化、監控與協作的統一解決方案。Fortune 500 企業中有 98% 使用 Postman 作為其 API 開發流程的核心工具。根據 2025 年 State of the API 報告，90% 的開發者正在使用 API，74% 已採用 API-First 策略，而 AI 驅動的 API 流量在 2024 年增長了 73%。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/postman%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":" 版本：2.0\n最後更新：2026 年 5 月 19 日 適用對象：後端工程師、前端工程師、QA 工程師、系統架構師、DevOps 工程師\n定位：企業內部標準教材\n文件維護：內部技術團隊\n適用於：Postman v12.x（2026 年最新穩定版，向下相容 v11.x）\nCreated by：Eric Cheng\nPostman 教學手冊 📋 教學大綱 Postman 簡介與概觀 1.1 Postman 是什麼？ 1.2 核心功能總覽 1.3 Postman 平台架構 1.4 版本與授權方案 1.5 與同類工具比較 1.6 適用場景與不適用場景 安裝與環境設定 2.1 桌面應用程式安裝 2.2 網頁版與 VS Code Extension 2.3 帳號註冊與登入 2.4 介面導覽 2.5 企業網路設定（Proxy / SSL） 2.6 團隊初始化設定 核心概念 3.1 Workspaces（工作區） 3.2 Collections（集合） 3.3 Environments 與 Variables 3.4 Authorization（認證與授權） 3.5 Postman Console 發送 API 請求 4.1 建立與發送 HTTP 請求 4.2 Request Body 格式 4.3 Response 檢視與分析 4.4 GraphQL 請求 4.5 gRPC 與 WebSocket 4.6 Cookie 與 Certificate 管理 變數與環境管理 5.1 變數作用域與優先順序 5.2 動態變數 5.3 環境切換策略 5.4 Postman Vault（敏感資料管理） 5.5 資料檔案驅動（CSV / JSON） 腳本開發（Tests \u0026amp; Scripts） 6.1 Pre-request Script 6.2 Post-response Script（測試斷言） 6.3 pm API 完整參考 6.4 Chai Assertion Library 6.5 請求鏈結（Chaining Requests） 6.6 常見測試範例 6.7 可重用腳本（Package Library） Collection Runner 與自動化測試 7.1 Collection Runner 使用 7.2 執行順序控制 7.3 Data-Driven Testing 7.4 效能測試 7.5 整合測試與回歸測試 Postman CLI 與 CI/CD 整合 8.1 Postman CLI 安裝與設定 8.2 命令列執行 Collection 8.3 Newman（傳統 CLI） 8.4 GitHub Actions 整合 8.5 Jenkins / Azure DevOps 整合 API 設計與文件 9.1 Spec Hub（OpenAPI / AsyncAPI） 9.2 Mock Server 設定 9.3 API 文件產生與發布 9.4 版本管理與 Native Git 9.5 SDK Generation（SDK 產生） 9.6 API Catalog（Enterprise） Postman Flows 10.1 Flows 概念與用途 10.2 建立視覺化工作流 10.3 實務案例 AI 功能（Agent Mode） 11.1 Postman AI 功能總覽 11.2 Agent Mode 深度指南 11.3 MCP Server 與 MCP Client 整合 11.4 AI Credits 管理與最佳化 團隊協作 12.1 團隊建立與管理 12.2 角色與權限 12.3 Version Control（Fork / Pull Request / Merge） 12.4 團隊工作區最佳實務 安全治理與 API Governance 13.1 Postman Secret Scanner 13.2 Postman Vault 與第三方整合 13.3 API Governance Rules 13.4 SSO / SCIM / Audit Log 13.5 BYOK 與 Data Residency 監控與效能 14.1 Monitor 設定與排程 14.2 效能指標與告警 14.3 Insights（Enterprise） 整合與擴充 15.1 第三方工具整合 15.2 Postman API 使用 15.3 Webhook 與自訂整合 企業導入策略 16.1 評估與導入路線圖 16.2 方案選擇與團隊培訓 16.3 標準化規範 最佳實務與反模式 17.1 最佳實務 17.2 常見反模式 常見問題與除錯（FAQ） 附錄 19.1 pm API 速查表 19.2 Chai Assertion 速查表 19.3 HTTP Status Code 速查表 19.4 快捷鍵速查表 19.5 新人上手 Checklist 19.6 API 測試 Checklist 19.7 安全性 Checklist 1. Postman 簡介與概觀 1.1 Postman 是什麼？ Postman 是全球領先的 AI 原生 API 平台，為超過 4,000 萬開發者與 50 萬以上的組織提供 API 開發、測試、文件化、監控與協作的統一解決方案。Fortune 500 企業中有 98% 使用 Postman 作為其 API 開發流程的核心工具。根據 2025 年 State of the API 報告，90% 的開發者正在使用 API，74% 已採用 API-First 策略，而 AI 驅動的 API 流量在 2024 年增長了 73%。\n","title":"Postman 教學手冊"},{"content":"API 規格文件範本（API Specification Document） 參照標準：OpenAPI Specification 3.1（OAS 3.1）/ Linux Foundation 標準\n文件用途：定義 RESTful API 的端點、請求/回應格式、認證機制與錯誤處理規範\n適用階段：系統設計階段（Detail Design Phase）\n📋 章節目錄 文件資訊 API 概述 認證與授權 共用規範 端點定義 資料模型 錯誤處理 版本策略 OpenAPI 規格檔 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 API-{專案代碼}-{序號} API 名稱 {系統名稱} API API 版本 v{主版本} 文件版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 已發布 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 負責人 {姓名/角色} Base URL https://{domain}/api/v{version} 📖 使用說明 API 版本與文件版本分開管理：API 版本影響端點路徑，文件版本追蹤文件修訂 Base URL 需區分環境（DEV/SIT/UAT/PROD） 依據 OpenAPI 3.1 info 物件結構設計 💡 範例 項目 內容 文件編號 API-HRM-001 API 名稱 HRMS API API 版本 v1 Base URL https://api.company.com/hrms/v1 2. API 概述 📝 範本 2.1 API 目的 {描述此 API 提供的服務範圍與主要功能}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/api_spec_template/","summary":"API 規格文件範本（API Specification Document） 參照標準：OpenAPI Specification 3.1（OAS 3.1）/ Linux Foundation 標準\n文件用途：定義 RESTful API 的端點、請求/回應格式、認證機制與錯誤處理規範\n適用階段：系統設計階段（Detail Design Phase）\n📋 章節目錄 文件資訊 API 概述 認證與授權 共用規範 端點定義 資料模型 錯誤處理 版本策略 OpenAPI 規格檔 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 API-{專案代碼}-{序號} API 名稱 {系統名稱} API API 版本 v{主版本} 文件版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 已發布 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 負責人 {姓名/角色} Base URL https://{domain}/api/v{version} 📖 使用說明 API 版本與文件版本分開管理：API 版本影響端點路徑，文件版本追蹤文件修訂 Base URL 需區分環境（DEV/SIT/UAT/PROD） 依據 OpenAPI 3.1 info 物件結構設計 💡 範例 項目 內容 文件編號 API-HRM-001 API 名稱 HRMS API API 版本 v1 Base URL https://api.company.com/hrms/v1 2. API 概述 📝 範本 2.1 API 目的 {描述此 API 提供的服務範圍與主要功能}\n","title":"API 規格文件範本（API Specification Template）"},{"content":"BRD 業務需求文件範本（Business Requirements Document） 參照標準：IIBA BABOK Guide v3 / ISO/IEC/IEEE 29148:2018\n文件用途：記錄業務層級需求，作為專案啟動與範圍確認的基礎依據\n適用階段：專案啟始階段（Initiation Phase）\n📋 章節目錄 文件資訊 業務目的與範圍 業務背景與現況分析 利害關係人分析 業務需求 限制條件與假設 解決方案選項評估 驗收標準 風險評估 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 BRD-{專案代碼}-{序號} 文件名稱 {系統/專案名稱} 業務需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 v1.0 {YYYY-MM-DD} {姓名} 正式發布 📖 使用說明 文件編號：採用組織標準編碼規則，確保唯一性與可追溯性 狀態管理：遵循 Draft → Under Review → Approved 的生命週期 版本歷程：每次修改必須記錄，符合 ISO/IEC/IEEE 29148 的組態管理要求 文件核定後進入基線管理（Baseline），後續修改需走變更控制流程 💡 範例 項目 內容 文件編號 BRD-ERP-001 文件名稱 人力資源管理系統 業務需求文件 版本 v1.2 狀態 核定 建立日期 2026-03-01 最後更新 2026-04-15 撰寫者 王小明 / 業務分析師 審核者 李主管 / 人資部經理 核定者 張總監 / IT 總監 2. 業務目的與範圍 📝 範本 2.1 業務目的（Business Purpose） {描述為什麼需要這個專案/系統，要解決什麼業務問題}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/brd_template/","summary":"BRD 業務需求文件範本（Business Requirements Document） 參照標準：IIBA BABOK Guide v3 / ISO/IEC/IEEE 29148:2018\n文件用途：記錄業務層級需求，作為專案啟動與範圍確認的基礎依據\n適用階段：專案啟始階段（Initiation Phase）\n📋 章節目錄 文件資訊 業務目的與範圍 業務背景與現況分析 利害關係人分析 業務需求 限制條件與假設 解決方案選項評估 驗收標準 風險評估 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 BRD-{專案代碼}-{序號} 文件名稱 {系統/專案名稱} 業務需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 v1.0 {YYYY-MM-DD} {姓名} 正式發布 📖 使用說明 文件編號：採用組織標準編碼規則，確保唯一性與可追溯性 狀態管理：遵循 Draft → Under Review → Approved 的生命週期 版本歷程：每次修改必須記錄，符合 ISO/IEC/IEEE 29148 的組態管理要求 文件核定後進入基線管理（Baseline），後續修改需走變更控制流程 💡 範例 項目 內容 文件編號 BRD-ERP-001 文件名稱 人力資源管理系統 業務需求文件 版本 v1.2 狀態 核定 建立日期 2026-03-01 最後更新 2026-04-15 撰寫者 王小明 / 業務分析師 審核者 李主管 / 人資部經理 核定者 張總監 / IT 總監 2. 業務目的與範圍 📝 範本 2.1 業務目的（Business Purpose） {描述為什麼需要這個專案/系統，要解決什麼業務問題}\n","title":"BRD 業務需求文件範本（Business Requirements Document Template）"},{"content":"FRD 功能需求文件範本（Functional Requirements Document） 參照標準：ISO/IEC/IEEE 29148:2018（取代 IEEE 830-1998）\n文件用途：將業務需求轉化為系統可實作的功能性與非功能性需求規格\n適用階段：需求分析階段（Requirements Analysis Phase）\n📋 章節目錄 文件資訊 導言 整體描述 系統功能需求 外部介面需求 非功能性需求 資料需求 其他需求 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 FRD-{專案代碼}-{序號} 文件名稱 {系統名稱} 功能需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 基線 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 對應 BRD {BRD 文件編號} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 📖 使用說明 FRD 承接 BRD（業務需求文件），將業務需求細化為系統功能規格 對應 BRD 欄位用於建立文件間的追溯關係 狀態增加「基線」代表已納入組態管理，後續變更需走 Change Request 流程 💡 範例 項目 內容 文件編號 FRD-HRM-001 文件名稱 人力資源管理系統 功能需求文件 版本 v2.1 狀態 基線 對應 BRD BRD-ERP-001 v1.2 2. 導言 📝 範本 2.1 目的（Purpose） 本文件定義 {系統名稱} 的功能性與非功能性需求規格，作為系統設計、開發與驗收測試的依據。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/frd_template/","summary":"FRD 功能需求文件範本（Functional Requirements Document） 參照標準：ISO/IEC/IEEE 29148:2018（取代 IEEE 830-1998）\n文件用途：將業務需求轉化為系統可實作的功能性與非功能性需求規格\n適用階段：需求分析階段（Requirements Analysis Phase）\n📋 章節目錄 文件資訊 導言 整體描述 系統功能需求 外部介面需求 非功能性需求 資料需求 其他需求 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 FRD-{專案代碼}-{序號} 文件名稱 {系統名稱} 功能需求文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 基線 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核定者 {姓名/角色} 對應 BRD {BRD 文件編號} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初稿建立 📖 使用說明 FRD 承接 BRD（業務需求文件），將業務需求細化為系統功能規格 對應 BRD 欄位用於建立文件間的追溯關係 狀態增加「基線」代表已納入組態管理，後續變更需走 Change Request 流程 💡 範例 項目 內容 文件編號 FRD-HRM-001 文件名稱 人力資源管理系統 功能需求文件 版本 v2.1 狀態 基線 對應 BRD BRD-ERP-001 v1.2 2. 導言 📝 範本 2.1 目的（Purpose） 本文件定義 {系統名稱} 的功能性與非功能性需求規格，作為系統設計、開發與驗收測試的依據。\n","title":"FRD 功能需求文件範本（Functional Requirements Document Template）"},{"content":"README 範本（README Template） 參照標準：GitHub Community Standards / Open Source Guides / Make a README\n文件用途：提供專案的入口文件，讓開發者快速了解、安裝、使用與貢獻專案\n適用階段：專案全生命週期（建立即應存在，持續維護）\n📋 章節目錄 文件資訊 專案名稱與描述 徽章區（Badges） 快速開始 安裝指南 使用方式 API 參考 專案結構 貢獻指南 授權條款 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 README.md 位置 專案根目錄 格式 GitHub Flavored Markdown (GFM) 維護者 {姓名/團隊} 最後更新 {YYYY-MM-DD} 📖 使用說明 README.md 是專案的「門面」，通常是訪客看到的第一份文件 遵循 GitHub Community Standards 建議結構 內容需保持最新，過時的 README 比沒有 README 更糟 💡 範例 本範本以 HRMS 專案為例，展示完整 README 結構。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/project/readme_template/","summary":"README 範本（README Template） 參照標準：GitHub Community Standards / Open Source Guides / Make a README\n文件用途：提供專案的入口文件，讓開發者快速了解、安裝、使用與貢獻專案\n適用階段：專案全生命週期（建立即應存在，持續維護）\n📋 章節目錄 文件資訊 專案名稱與描述 徽章區（Badges） 快速開始 安裝指南 使用方式 API 參考 專案結構 貢獻指南 授權條款 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 README.md 位置 專案根目錄 格式 GitHub Flavored Markdown (GFM) 維護者 {姓名/團隊} 最後更新 {YYYY-MM-DD} 📖 使用說明 README.md 是專案的「門面」，通常是訪客看到的第一份文件 遵循 GitHub Community Standards 建議結構 內容需保持最新，過時的 README 比沒有 README 更糟 💡 範例 本範本以 HRMS 專案為例，展示完整 README 結構。\n","title":"README 範本（README Template）"},{"content":"SAD 系統架構文件範本（System Architecture Document） 參照標準：ISO/IEC/IEEE 42010:2022（取代 IEEE 1471-2000）\n文件用途：描述系統架構決策、觀點、視圖與品質屬性，作為開發團隊的設計藍圖\n適用階段：系統設計階段（System Design Phase）\n📋 章節目錄 文件資訊 架構概述 架構利害關係人與關注點 架構觀點定義 邏輯視圖 開發視圖 部署視圖 流程視圖 資料架構視圖 架構決策記錄 品質屬性與戰術 安全架構 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SAD-{專案代碼}-{序號} 文件名稱 {系統名稱} 系統架構文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 架構師 {姓名} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版架構設計 📖 使用說明 依據 ISO/IEC/IEEE 42010:2022 第 5.1 節，架構描述應包含識別資訊 SAD 承接 FRD，將功能需求與非功能需求轉化為架構設計方案 架構文件是「活文件」（Living Document），隨設計演進持續更新 💡 範例 項目 內容 文件編號 SAD-HRM-001 文件名稱 人力資源管理系統 系統架構文件 版本 v1.3 架構師 陳建築 對應 FRD FRD-HRM-001 v2.1 2. 架構概述 📝 範本 2.1 系統背景（System Context） {描述系統在組織 IT 環境中的定位}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/sad_template/","summary":"SAD 系統架構文件範本（System Architecture Document） 參照標準：ISO/IEC/IEEE 42010:2022（取代 IEEE 1471-2000）\n文件用途：描述系統架構決策、觀點、視圖與品質屬性，作為開發團隊的設計藍圖\n適用階段：系統設計階段（System Design Phase）\n📋 章節目錄 文件資訊 架構概述 架構利害關係人與關注點 架構觀點定義 邏輯視圖 開發視圖 部署視圖 流程視圖 資料架構視圖 架構決策記錄 品質屬性與戰術 安全架構 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SAD-{專案代碼}-{序號} 文件名稱 {系統名稱} 系統架構文件 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 架構師 {姓名} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版架構設計 📖 使用說明 依據 ISO/IEC/IEEE 42010:2022 第 5.1 節，架構描述應包含識別資訊 SAD 承接 FRD，將功能需求與非功能需求轉化為架構設計方案 架構文件是「活文件」（Living Document），隨設計演進持續更新 💡 範例 項目 內容 文件編號 SAD-HRM-001 文件名稱 人力資源管理系統 系統架構文件 版本 v1.3 架構師 陳建築 對應 FRD FRD-HRM-001 v2.1 2. 架構概述 📝 範本 2.1 系統背景（System Context） {描述系統在組織 IT 環境中的定位}\n","title":"SAD 系統架構文件範本（System Architecture Document Template）"},{"content":"UX/UI 畫面設計規格範本（UI Specification Template） 適用標準：ISO 9241-210:2019（Human-centred Design）、WCAG 2.2（Web Content Accessibility Guidelines）\n適用階段：系統設計階段（Design Phase）\n負責角色：UX 設計師、UI 設計師、前端工程師\n📑 章節目錄 文件資訊 設計原則與規範 資訊架構（Information Architecture） 畫面流程（UI Flow） 畫面規格（Screen Specification） 元件規格（Component Specification） 響應式設計規格 無障礙設計（Accessibility） 互動規格（Interaction Specification） 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] UI 設計規格書 文件編號 [專案代碼]-UIS-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [UX/UI 設計師] 審核者 [Product Owner / Tech Lead] 設計工具與資源 項目 工具/位置 Design Tool [Figma / Sketch / Adobe XD] Design File URL [連結] Prototype URL [互動原型連結] Design System [設計系統/元件庫名稱與連結] Icon Library [圖標庫名稱] 2. 設計原則與規範 2.1 設計原則 原則 說明 [一致性] [描述此專案的一致性準則] [簡潔性] [描述簡潔設計方針] [可及性] [無障礙設計目標] [效率] [使用者操作效率目標] 2.2 Design Token / 設計變數 Token 名稱 值 用途 color-primary [#XXXXXX] 主要品牌色 color-secondary [#XXXXXX] 次要色 color-error [#XXXXXX] 錯誤提示 color-success [#XXXXXX] 成功提示 font-family [字型名稱] 主要字型 font-size-base [N]px 基準字級 spacing-unit [N]px 間距基準單位 border-radius [N]px 圓角 2.3 排版規範（Typography） 層級 用途 字級 字重 行高 H1 頁面標題 [N]px [Bold] [N] H2 區塊標題 [N]px [Semi-Bold] [N] H3 子區塊標題 [N]px [Medium] [N] Body 內文 [N]px [Regular] [N] Caption 說明文字 [N]px [Regular] [N] 3. 資訊架構（Information Architecture） 3.1 導航結構（Sitemap） [系統名稱] ├── 首頁 Dashboard ├── 模組 A │ ├── 功能 A-1 │ ├── 功能 A-2 │ └── 功能 A-3 ├── 模組 B │ ├── 功能 B-1 │ └── 功能 B-2 ├── 系統設定 │ ├── 個人設定 │ └── 管理設定（Admin only） └── 說明 / Help 3.2 角色與功能對應 角色 可見模組 可執行操作 [角色 A] [模組清單] [CRUD 權限] [角色 B] [模組清單] [CRUD 權限] 4. 畫面流程（UI Flow） graph TD A[進入點/登入] --\u0026gt; B{角色判斷} B --\u0026gt;|角色A| C[Dashboard A] B --\u0026gt;|角色B| D[Dashboard B] C --\u0026gt; E[功能頁 1] E --\u0026gt; F[表單填寫] F --\u0026gt; G{驗證} G --\u0026gt;|成功| H[成功回饋] G --\u0026gt;|失敗| I[錯誤提示] --\u0026gt; F 5. 畫面規格（Screen Specification） Screen-[NNN]: [畫面名稱] 項目 內容 畫面 ID SCR-[NNN] 畫面名稱 [中英文名稱] URL Path [/path/to/page] 對應 Use Case UC-[NNN] 角色權限 [可存取的角色] 進入條件 [如何到達此頁面] 畫面佈局（Layout）：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/ui_spec_template/","summary":"UX/UI 畫面設計規格範本（UI Specification Template） 適用標準：ISO 9241-210:2019（Human-centred Design）、WCAG 2.2（Web Content Accessibility Guidelines）\n適用階段：系統設計階段（Design Phase）\n負責角色：UX 設計師、UI 設計師、前端工程師\n📑 章節目錄 文件資訊 設計原則與規範 資訊架構（Information Architecture） 畫面流程（UI Flow） 畫面規格（Screen Specification） 元件規格（Component Specification） 響應式設計規格 無障礙設計（Accessibility） 互動規格（Interaction Specification） 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] UI 設計規格書 文件編號 [專案代碼]-UIS-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [UX/UI 設計師] 審核者 [Product Owner / Tech Lead] 設計工具與資源 項目 工具/位置 Design Tool [Figma / Sketch / Adobe XD] Design File URL [連結] Prototype URL [互動原型連結] Design System [設計系統/元件庫名稱與連結] Icon Library [圖標庫名稱] 2. 設計原則與規範 2.1 設計原則 原則 說明 [一致性] [描述此專案的一致性準則] [簡潔性] [描述簡潔設計方針] [可及性] [無障礙設計目標] [效率] [使用者操作效率目標] 2.2 Design Token / 設計變數 Token 名稱 值 用途 color-primary [#XXXXXX] 主要品牌色 color-secondary [#XXXXXX] 次要色 color-error [#XXXXXX] 錯誤提示 color-success [#XXXXXX] 成功提示 font-family [字型名稱] 主要字型 font-size-base [N]px 基準字級 spacing-unit [N]px 間距基準單位 border-radius [N]px 圓角 2.3 排版規範（Typography） 層級 用途 字級 字重 行高 H1 頁面標題 [N]px [Bold] [N] H2 區塊標題 [N]px [Semi-Bold] [N] H3 子區塊標題 [N]px [Medium] [N] Body 內文 [N]px [Regular] [N] Caption 說明文字 [N]px [Regular] [N] 3. 資訊架構（Information Architecture） 3.1 導航結構（Sitemap） [系統名稱] ├── 首頁 Dashboard ├── 模組 A │ ├── 功能 A-1 │ ├── 功能 A-2 │ └── 功能 A-3 ├── 模組 B │ ├── 功能 B-1 │ └── 功能 B-2 ├── 系統設定 │ ├── 個人設定 │ └── 管理設定（Admin only） └── 說明 / Help 3.2 角色與功能對應 角色 可見模組 可執行操作 [角色 A] [模組清單] [CRUD 權限] [角色 B] [模組清單] [CRUD 權限] 4. 畫面流程（UI Flow） graph TD A[進入點/登入] --\u0026gt; B{角色判斷} B --\u0026gt;|角色A| C[Dashboard A] B --\u0026gt;|角色B| D[Dashboard B] C --\u0026gt; E[功能頁 1] E --\u0026gt; F[表單填寫] F --\u0026gt; G{驗證} G --\u0026gt;|成功| H[成功回饋] G --\u0026gt;|失敗| I[錯誤提示] --\u0026gt; F 5. 畫面規格（Screen Specification） Screen-[NNN]: [畫面名稱] 項目 內容 畫面 ID SCR-[NNN] 畫面名稱 [中英文名稱] URL Path [/path/to/page] 對應 Use Case UC-[NNN] 角色權限 [可存取的角色] 進入條件 [如何到達此頁面] 畫面佈局（Layout）：\n","title":"UX/UI 畫面設計規格範本（UI Specification Template）"},{"content":"上線檢核清單範本（Go-Live Checklist Template） 適用標準：ITIL 4 Release Management、ISO/IEC 20000-1:2018\n適用階段：部署上線階段（Deployment Phase）\n負責角色：Release Manager、PM、Tech Lead\n📑 章節目錄 文件資訊 上線概要 上線前置作業檢核 上線當日檢核 上線後驗證檢核 通訊與通知計畫 回退判定與流程 簽核記錄 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 上線檢核清單 文件編號 [專案代碼]-GLC-[版本號]-[日期] 版本 v[X.Y] 預定上線日期 [YYYY-MM-DD HH:mm] 上線視窗 [YYYY-MM-DD HH:mm] ~ [HH:mm] Release Manager [姓名] 核准者 [PM / IT Director] 2. 上線概要 項目 內容 上線類型 [全新上線 / 版本升級 / Hotfix / 設定變更] 影響範圍 [影響的模組/功能/用戶群] 預計停機時間 [N 分鐘 / 零停機] 影響用戶數 [N] 人 回退計畫 [有 / 無] → 參考 §7 相關 Change Request [CR-NNN] 3. 上線前置作業檢核 3.1 開發與測試 # 檢核項目 負責人 完成日 狀態 備註 1 所有功能開發完成並合併至 release branch [Dev Lead] [日期] [✅/❌/N/A] 2 Code Review 完成（所有 PR 已核准） [Dev Lead] [日期] [✅/❌/N/A] 3 單元測試通過率 ≥ [N]% [Dev] [日期] [✅/❌/N/A] 4 整合測試全數通過 [QA] [日期] [✅/❌/N/A] 5 UAT 簽核完成 [PO/使用者] [日期] [✅/❌/N/A] 6 效能測試報告 — 符合 NFR 標準 [QA/效能] [日期] [✅/❌/N/A] 7 安全掃描通過（Critical/High = 0） [AppSec] [日期] [✅/❌/N/A] 8 Regression Test 通過 [QA] [日期] [✅/❌/N/A] 3.2 部署準備 # 檢核項目 負責人 完成日 狀態 備註 9 部署手冊/腳本已更新並審閱 [DevOps] [日期] [✅/❌/N/A] 10 CI/CD Pipeline 驗證通過（Staging） [DevOps] [日期] [✅/❌/N/A] 11 資料庫 Migration Script 已測試 [DBA] [日期] [✅/❌/N/A] 12 回退腳本已準備並測試 [DevOps/DBA] [日期] [✅/❌/N/A] 13 設定檔已更新（環境變數/Config） [DevOps] [日期] [✅/❌/N/A] 14 SSL 憑證/網域確認有效 [Infra] [日期] [✅/❌/N/A] 15 第三方服務/API 就緒確認 [SA] [日期] [✅/❌/N/A] 16 容量/資源已到位（VM / K8s / DB） [Infra] [日期] [✅/❌/N/A] 3.3 文件與溝通 # 檢核項目 負責人 完成日 狀態 備註 17 Release Note 已完成 [PM/Dev] [日期] [✅/❌/N/A] 18 使用者手冊/教育訓練已更新 [PM/BA] [日期] [✅/❌/N/A] 19 維運文件（SOP/Runbook）已更新 [SRE/DevOps] [日期] [✅/❌/N/A] 20 內部上線通知已發送 [PM] [日期] [✅/❌/N/A] 21 外部用戶公告已發送（如需要） [PM/行銷] [日期] [✅/❌/N/A] 22 客服/Help Desk 已知悉異動內容 [PM] [日期] [✅/❌/N/A] 3.4 監控與告警 # 檢核項目 負責人 完成日 狀態 備註 23 監控 Dashboard 已設定 [SRE] [日期] [✅/❌/N/A] 24 告警規則已設定並測試 [SRE] [日期] [✅/❌/N/A] 25 Log 收集已確認正常 [SRE] [日期] [✅/❌/N/A] 26 健康檢查端點已設定 [Dev/DevOps] [日期] [✅/❌/N/A] 4. 上線當日檢核 4.1 上線前（T - 30 min） # 檢核項目 負責人 時間 狀態 備註 27 War Room 成員全數到位 [RM] [HH:mm] [✅/❌] 28 溝通管道確認（Teams/Slack channel） [RM] [HH:mm] [✅/❌] 29 最終 Go/No-Go 確認 [PM + 各角色] [HH:mm] [✅/❌] 30 生產環境備份完成 [DBA/Infra] [HH:mm] [✅/❌] 4.2 上線執行中 # 步驟 負責人 預計時間 實際時間 狀態 備註 31 [開始維護公告/流量切離] [RM] [HH:mm] [✅/❌] 32 [DB Migration 執行] [DBA] [HH:mm] [✅/❌] 33 [應用程式部署] [DevOps] [HH:mm] [✅/❌] 34 [設定檔/環境變數更新] [DevOps] [HH:mm] [✅/❌] 35 [快速健康檢查] [DevOps] [HH:mm] [✅/❌] 36 [流量恢復/維護公告移除] [RM] [HH:mm] [✅/❌] 5. 上線後驗證檢核 5.1 即時驗證（T + 15 min） # 檢核項目 負責人 狀態 備註 37 Health Check / Liveness 正常 [DevOps] [✅/❌] 38 核心功能 Smoke Test 通過 [QA] [✅/❌] 39 Log 無 Error/Exception 異常暴增 [SRE] [✅/❌] 40 監控指標正常（CPU/Memory/TPS） [SRE] [✅/❌] 41 資料庫連線正常 [DBA] [✅/❌] 5.2 穩定觀察期（T + 1~4 hr） # 檢核項目 負責人 狀態 備註 42 錯誤率維持正常水位 [SRE] [✅/❌] 43 回應時間無惡化 [SRE] [✅/❌] 44 無使用者回報問題 [客服/PM] [✅/❌] 45 排程任務正常執行 [DevOps] [✅/❌] 6. 通訊與通知計畫 階段 通知對象 通知方式 內容重點 負責人 上線前 1 週 內部團隊 Email/Teams 上線時程與影響 PM 上線前 1 天 外部用戶 公告/Email 維護視窗通知 PM 上線開始 War Room 成員 Teams Channel Go 指令 RM 上線完成 全體利害關係人 Email 完成通知 PM 異常/回退 管理層 + 用戶 電話 + Email 狀況說明 PM/RM 7. 回退判定與流程 7.1 回退觸發條件 # 條件 判定者 優先級 1 核心功能 Smoke Test 失敗 QA + PM 立即回退 2 Error Rate \u0026gt; [N]% 持續 [N] 分鐘 SRE 立即回退 3 P95 回應時間 \u0026gt; [N]ms 持續 [N] 分鐘 SRE 評估回退 4 資料完整性問題 DBA 立即回退 5 安全性事件 AppSec 立即回退 7.2 回退步驟摘要 # 步驟 負責人 預估時間 1 宣告回退決定 RM/PM 即刻 2 [流量切離/維護模式] DevOps [N] min 3 [應用程式回退至前版] DevOps [N] min 4 [DB rollback（如有）] DBA [N] min 5 [驗證回退成功] QA [N] min 6 [恢復流量] DevOps [N] min 8. 簽核記錄 階段 角色 姓名 簽核日期 結果 Go/No-Go PM [姓名] [日期] [Go / No-Go] Go/No-Go Tech Lead [姓名] [日期] [Go / No-Go] Go/No-Go QA Lead [姓名] [日期] [Go / No-Go] 上線完成確認 RM [姓名] [日期] [成功 / 回退] 觀察期結束 SRE [姓名] [日期] [穩定 / 待觀察] 9. 附錄 9.1 War Room 聯絡人 角色 姓名 電話 備註 Release Manager [姓名] [電話] DBA [姓名] [電話] DevOps [姓名] [電話] Dev Lead [姓名] [電話] 9.2 相關文件連結 文件 連結 Release Note [link] 部署手冊 [link] 回退計畫 [link] 監控 Dashboard [link] 📖 使用說明 使用時機 情境 使用方式 新系統首次上線 完整執行所有檢核項 版本升級 可依影響範圍簡化 §3.3 Hotfix 簡化版，但 §4, §5, §7 必須執行 設定變更 簡化版，聚焦 §4, §5 管理原則 上線前 48 小時完成所有前置作業檢核 Go/No-Go 會議需所有關鍵角色簽核 回退計畫必須事先測試驗證 觀察期結束前不可離開 War Room 💡 範例（以 HRMS 人力資源管理系統為例） 範例：Go/No-Go 決策 上線版本：HRMS v2.0.0（薪資模組重構 + 出缺勤 API 升級）\n上線視窗：2024-06-15 02:00~04:00 (Saturday)\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/deployment/golivechecklist_template/","summary":"上線檢核清單範本（Go-Live Checklist Template） 適用標準：ITIL 4 Release Management、ISO/IEC 20000-1:2018\n適用階段：部署上線階段（Deployment Phase）\n負責角色：Release Manager、PM、Tech Lead\n📑 章節目錄 文件資訊 上線概要 上線前置作業檢核 上線當日檢核 上線後驗證檢核 通訊與通知計畫 回退判定與流程 簽核記錄 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 上線檢核清單 文件編號 [專案代碼]-GLC-[版本號]-[日期] 版本 v[X.Y] 預定上線日期 [YYYY-MM-DD HH:mm] 上線視窗 [YYYY-MM-DD HH:mm] ~ [HH:mm] Release Manager [姓名] 核准者 [PM / IT Director] 2. 上線概要 項目 內容 上線類型 [全新上線 / 版本升級 / Hotfix / 設定變更] 影響範圍 [影響的模組/功能/用戶群] 預計停機時間 [N 分鐘 / 零停機] 影響用戶數 [N] 人 回退計畫 [有 / 無] → 參考 §7 相關 Change Request [CR-NNN] 3. 上線前置作業檢核 3.1 開發與測試 # 檢核項目 負責人 完成日 狀態 備註 1 所有功能開發完成並合併至 release branch [Dev Lead] [日期] [✅/❌/N/A] 2 Code Review 完成（所有 PR 已核准） [Dev Lead] [日期] [✅/❌/N/A] 3 單元測試通過率 ≥ [N]% [Dev] [日期] [✅/❌/N/A] 4 整合測試全數通過 [QA] [日期] [✅/❌/N/A] 5 UAT 簽核完成 [PO/使用者] [日期] [✅/❌/N/A] 6 效能測試報告 — 符合 NFR 標準 [QA/效能] [日期] [✅/❌/N/A] 7 安全掃描通過（Critical/High = 0） [AppSec] [日期] [✅/❌/N/A] 8 Regression Test 通過 [QA] [日期] [✅/❌/N/A] 3.2 部署準備 # 檢核項目 負責人 完成日 狀態 備註 9 部署手冊/腳本已更新並審閱 [DevOps] [日期] [✅/❌/N/A] 10 CI/CD Pipeline 驗證通過（Staging） [DevOps] [日期] [✅/❌/N/A] 11 資料庫 Migration Script 已測試 [DBA] [日期] [✅/❌/N/A] 12 回退腳本已準備並測試 [DevOps/DBA] [日期] [✅/❌/N/A] 13 設定檔已更新（環境變數/Config） [DevOps] [日期] [✅/❌/N/A] 14 SSL 憑證/網域確認有效 [Infra] [日期] [✅/❌/N/A] 15 第三方服務/API 就緒確認 [SA] [日期] [✅/❌/N/A] 16 容量/資源已到位（VM / K8s / DB） [Infra] [日期] [✅/❌/N/A] 3.3 文件與溝通 # 檢核項目 負責人 完成日 狀態 備註 17 Release Note 已完成 [PM/Dev] [日期] [✅/❌/N/A] 18 使用者手冊/教育訓練已更新 [PM/BA] [日期] [✅/❌/N/A] 19 維運文件（SOP/Runbook）已更新 [SRE/DevOps] [日期] [✅/❌/N/A] 20 內部上線通知已發送 [PM] [日期] [✅/❌/N/A] 21 外部用戶公告已發送（如需要） [PM/行銷] [日期] [✅/❌/N/A] 22 客服/Help Desk 已知悉異動內容 [PM] [日期] [✅/❌/N/A] 3.4 監控與告警 # 檢核項目 負責人 完成日 狀態 備註 23 監控 Dashboard 已設定 [SRE] [日期] [✅/❌/N/A] 24 告警規則已設定並測試 [SRE] [日期] [✅/❌/N/A] 25 Log 收集已確認正常 [SRE] [日期] [✅/❌/N/A] 26 健康檢查端點已設定 [Dev/DevOps] [日期] [✅/❌/N/A] 4. 上線當日檢核 4.1 上線前（T - 30 min） # 檢核項目 負責人 時間 狀態 備註 27 War Room 成員全數到位 [RM] [HH:mm] [✅/❌] 28 溝通管道確認（Teams/Slack channel） [RM] [HH:mm] [✅/❌] 29 最終 Go/No-Go 確認 [PM + 各角色] [HH:mm] [✅/❌] 30 生產環境備份完成 [DBA/Infra] [HH:mm] [✅/❌] 4.2 上線執行中 # 步驟 負責人 預計時間 實際時間 狀態 備註 31 [開始維護公告/流量切離] [RM] [HH:mm] [✅/❌] 32 [DB Migration 執行] [DBA] [HH:mm] [✅/❌] 33 [應用程式部署] [DevOps] [HH:mm] [✅/❌] 34 [設定檔/環境變數更新] [DevOps] [HH:mm] [✅/❌] 35 [快速健康檢查] [DevOps] [HH:mm] [✅/❌] 36 [流量恢復/維護公告移除] [RM] [HH:mm] [✅/❌] 5. 上線後驗證檢核 5.1 即時驗證（T + 15 min） # 檢核項目 負責人 狀態 備註 37 Health Check / Liveness 正常 [DevOps] [✅/❌] 38 核心功能 Smoke Test 通過 [QA] [✅/❌] 39 Log 無 Error/Exception 異常暴增 [SRE] [✅/❌] 40 監控指標正常（CPU/Memory/TPS） [SRE] [✅/❌] 41 資料庫連線正常 [DBA] [✅/❌] 5.2 穩定觀察期（T + 1~4 hr） # 檢核項目 負責人 狀態 備註 42 錯誤率維持正常水位 [SRE] [✅/❌] 43 回應時間無惡化 [SRE] [✅/❌] 44 無使用者回報問題 [客服/PM] [✅/❌] 45 排程任務正常執行 [DevOps] [✅/❌] 6. 通訊與通知計畫 階段 通知對象 通知方式 內容重點 負責人 上線前 1 週 內部團隊 Email/Teams 上線時程與影響 PM 上線前 1 天 外部用戶 公告/Email 維護視窗通知 PM 上線開始 War Room 成員 Teams Channel Go 指令 RM 上線完成 全體利害關係人 Email 完成通知 PM 異常/回退 管理層 + 用戶 電話 + Email 狀況說明 PM/RM 7. 回退判定與流程 7.1 回退觸發條件 # 條件 判定者 優先級 1 核心功能 Smoke Test 失敗 QA + PM 立即回退 2 Error Rate \u0026gt; [N]% 持續 [N] 分鐘 SRE 立即回退 3 P95 回應時間 \u0026gt; [N]ms 持續 [N] 分鐘 SRE 評估回退 4 資料完整性問題 DBA 立即回退 5 安全性事件 AppSec 立即回退 7.2 回退步驟摘要 # 步驟 負責人 預估時間 1 宣告回退決定 RM/PM 即刻 2 [流量切離/維護模式] DevOps [N] min 3 [應用程式回退至前版] DevOps [N] min 4 [DB rollback（如有）] DBA [N] min 5 [驗證回退成功] QA [N] min 6 [恢復流量] DevOps [N] min 8. 簽核記錄 階段 角色 姓名 簽核日期 結果 Go/No-Go PM [姓名] [日期] [Go / No-Go] Go/No-Go Tech Lead [姓名] [日期] [Go / No-Go] Go/No-Go QA Lead [姓名] [日期] [Go / No-Go] 上線完成確認 RM [姓名] [日期] [成功 / 回退] 觀察期結束 SRE [姓名] [日期] [穩定 / 待觀察] 9. 附錄 9.1 War Room 聯絡人 角色 姓名 電話 備註 Release Manager [姓名] [電話] DBA [姓名] [電話] DevOps [姓名] [電話] Dev Lead [姓名] [電話] 9.2 相關文件連結 文件 連結 Release Note [link] 部署手冊 [link] 回退計畫 [link] 監控 Dashboard [link] 📖 使用說明 使用時機 情境 使用方式 新系統首次上線 完整執行所有檢核項 版本升級 可依影響範圍簡化 §3.3 Hotfix 簡化版，但 §4, §5, §7 必須執行 設定變更 簡化版，聚焦 §4, §5 管理原則 上線前 48 小時完成所有前置作業檢核 Go/No-Go 會議需所有關鍵角色簽核 回退計畫必須事先測試驗證 觀察期結束前不可離開 War Room 💡 範例（以 HRMS 人力資源管理系統為例） 範例：Go/No-Go 決策 上線版本：HRMS v2.0.0（薪資模組重構 + 出缺勤 API 升級）\n上線視窗：2024-06-15 02:00~04:00 (Saturday)\n","title":"上線檢核清單範本（Go-Live Checklist Template）"},{"content":"事件報告與根因分析範本（Incident Report \u0026amp; Root Cause Analysis） 參照標準：ITIL 4（Incident Management \u0026amp; Problem Management）/ ISO/IEC 20000-1:2018 / SRE Postmortem\n文件用途：記錄生產環境事件、分析根本原因、制定改善行動，防止問題再次發生\n適用階段：維運監控階段（Operations Phase）— Continuous Improvement\n📋 章節目錄 事件摘要 時間軸 影響評估 根因分析 解決方案 改善行動計畫 經驗教訓 附錄 1. 事件摘要 📝 範本 項目 內容 事件編號 INC-{YYYYMMDD}-{序號} 事件標題 {一句話描述事件} 嚴重等級 SEV1（Critical）/ SEV2（Major）/ SEV3（Minor）/ SEV4（Low） 事件狀態 調查中 / 已解決 / 已關閉 發生時間 {YYYY-MM-DD HH:MM} (UTC+8) 偵測時間 {YYYY-MM-DD HH:MM} 解決時間 {YYYY-MM-DD HH:MM} 事件持續時間 {N} 分鐘/小時 MTTD {偵測時間 - 發生時間} MTTR {解決時間 - 偵測時間} 受影響系統 {系統/服務名稱} 受影響使用者 {人數/比例} 事件負責人 {Incident Commander} 報告撰寫者 {姓名} 報告日期 {YYYY-MM-DD} 📖 使用說明 嚴重等級定義： SEV1：核心業務完全中斷，影響全部使用者 SEV2：核心功能嚴重降級，影響大部分使用者 SEV3：非核心功能異常，影響部分使用者 SEV4：輕微異常，幾乎不影響使用者 MTTD（Mean Time To Detect）：衡量監控能力 MTTR（Mean Time To Resolve）：衡量恢復能力 事件報告需在事件解決後 3-5 個工作日 內完成 Blameless 原則：報告聚焦系統與流程改善，不歸咎個人 💡 範例 項目 內容 事件編號 INC-20260520-001 事件標題 HRMS 薪資查詢 API 持續回傳 500 Error 嚴重等級 SEV2（核心功能嚴重降級） 發生時間 2026-05-20 10:15 偵測時間 2026-05-20 10:18（Grafana 告警） 解決時間 2026-05-20 10:28（回滾完成） 事件持續時間 13 分鐘 MTTD 3 分鐘 MTTR 10 分鐘 受影響使用者 ~200 人（薪資查詢功能不可用） 事件負責人 張 SRE 2. 時間軸 📝 範本 時間 (UTC+8) 事件 執行者 備註 {HH:MM} {發生/偵測/行動/解決} {人員} {補充說明} 📖 使用說明 時間軸是事件報告最有價值的部分，需精確到分鐘 涵蓋：事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證 資料來源：監控日誌、Slack 訊息時間戳、告警記錄 時間軸讓團隊復盤流程效率，找出可改善的環節 💡 範例 時間 (UTC+8) 事件 執行者 備註 10:12 v2.1.0 部署完成，新版上線 DevOps 林 K8s Green deployment 完成 10:15 薪資計算排程 CronJob 啟動（與 API 衝突） System 排程被新設定觸發 10:15 DB Lock 衝突開始，API 回應逾時 System PostgreSQL row-level lock 10:18 Grafana 告警：5xx rate \u0026gt; 5% Alert System #hrms-alerts 頻道 10:19 SRE 張確認告警，開始調查 SRE 張 檢查 Pod 日誌 10:21 確認問題：DB Lock contention SRE 張 pg_stat_activity 發現 lock wait 10:23 聯繫 Tech Lead 決策：啟動回滾 SRE 張 → Tech Lead 王 Slack 通訊 10:24 Tech Lead 確認回滾，授權執行 Tech Lead 王 10:25 開始執行回滾腳本 SRE 張 ./rollback-hrms-v2.1.0.sh 10:27 流量切換至 v2.0.3 完成 SRE 張 Blue deployment 10:28 健康檢查通過，冒煙測試通過 SRE 張 + QA 陳 服務恢復 10:30 通知團隊：服務已恢復 SRE 張 Slack + Email 10:45 通知受影響使用者：服務已恢復 PM 林 系統公告 3. 影響評估 📝 範本 3.1 業務影響 影響維度 評估 受影響功能 {功能清單} 受影響使用者數 {人數/比例} 收入損失 {金額/無法計量} 資料損失 {是/否，描述} SLA 違反 {是/否，影響 SLA 指標} 信譽影響 {高/中/低} 3.2 技術影響 影響維度 評估 受影響服務 {服務清單} 相依服務影響 {是否連鎖影響} 資料一致性 {是否受影響} 安全性影響 {是否有安全疑慮} 📖 使用說明 影響評估用於確認嚴重等級是否正確、作為改善優先級依據 業務影響由 PM/產品團隊提供；技術影響由工程團隊評估 SLA 違反需記錄，可能涉及客戶賠償或內部 KPI 💡 範例 3.1 業務影響 影響維度 評估 受影響功能 薪資查詢、薪資條下載 受影響使用者數 ~200 人（嘗試查詢薪資的員工） 收入損失 無直接收入損失（內部系統） 資料損失 無 SLA 違反 否（SLA 99.5% 月度，本月仍在 SLA 內） 信譽影響 低（事件持續 13 分鐘，非上班尖峰） 4. 根因分析 📝 範本 4.1 根本原因 Root Cause Statement：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/incidentreport_template/","summary":"事件報告與根因分析範本（Incident Report \u0026amp; Root Cause Analysis） 參照標準：ITIL 4（Incident Management \u0026amp; Problem Management）/ ISO/IEC 20000-1:2018 / SRE Postmortem\n文件用途：記錄生產環境事件、分析根本原因、制定改善行動，防止問題再次發生\n適用階段：維運監控階段（Operations Phase）— Continuous Improvement\n📋 章節目錄 事件摘要 時間軸 影響評估 根因分析 解決方案 改善行動計畫 經驗教訓 附錄 1. 事件摘要 📝 範本 項目 內容 事件編號 INC-{YYYYMMDD}-{序號} 事件標題 {一句話描述事件} 嚴重等級 SEV1（Critical）/ SEV2（Major）/ SEV3（Minor）/ SEV4（Low） 事件狀態 調查中 / 已解決 / 已關閉 發生時間 {YYYY-MM-DD HH:MM} (UTC+8) 偵測時間 {YYYY-MM-DD HH:MM} 解決時間 {YYYY-MM-DD HH:MM} 事件持續時間 {N} 分鐘/小時 MTTD {偵測時間 - 發生時間} MTTR {解決時間 - 偵測時間} 受影響系統 {系統/服務名稱} 受影響使用者 {人數/比例} 事件負責人 {Incident Commander} 報告撰寫者 {姓名} 報告日期 {YYYY-MM-DD} 📖 使用說明 嚴重等級定義： SEV1：核心業務完全中斷，影響全部使用者 SEV2：核心功能嚴重降級，影響大部分使用者 SEV3：非核心功能異常，影響部分使用者 SEV4：輕微異常，幾乎不影響使用者 MTTD（Mean Time To Detect）：衡量監控能力 MTTR（Mean Time To Resolve）：衡量恢復能力 事件報告需在事件解決後 3-5 個工作日 內完成 Blameless 原則：報告聚焦系統與流程改善，不歸咎個人 💡 範例 項目 內容 事件編號 INC-20260520-001 事件標題 HRMS 薪資查詢 API 持續回傳 500 Error 嚴重等級 SEV2（核心功能嚴重降級） 發生時間 2026-05-20 10:15 偵測時間 2026-05-20 10:18（Grafana 告警） 解決時間 2026-05-20 10:28（回滾完成） 事件持續時間 13 分鐘 MTTD 3 分鐘 MTTR 10 分鐘 受影響使用者 ~200 人（薪資查詢功能不可用） 事件負責人 張 SRE 2. 時間軸 📝 範本 時間 (UTC+8) 事件 執行者 備註 {HH:MM} {發生/偵測/行動/解決} {人員} {補充說明} 📖 使用說明 時間軸是事件報告最有價值的部分，需精確到分鐘 涵蓋：事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證 資料來源：監控日誌、Slack 訊息時間戳、告警記錄 時間軸讓團隊復盤流程效率，找出可改善的環節 💡 範例 時間 (UTC+8) 事件 執行者 備註 10:12 v2.1.0 部署完成，新版上線 DevOps 林 K8s Green deployment 完成 10:15 薪資計算排程 CronJob 啟動（與 API 衝突） System 排程被新設定觸發 10:15 DB Lock 衝突開始，API 回應逾時 System PostgreSQL row-level lock 10:18 Grafana 告警：5xx rate \u0026gt; 5% Alert System #hrms-alerts 頻道 10:19 SRE 張確認告警，開始調查 SRE 張 檢查 Pod 日誌 10:21 確認問題：DB Lock contention SRE 張 pg_stat_activity 發現 lock wait 10:23 聯繫 Tech Lead 決策：啟動回滾 SRE 張 → Tech Lead 王 Slack 通訊 10:24 Tech Lead 確認回滾，授權執行 Tech Lead 王 10:25 開始執行回滾腳本 SRE 張 ./rollback-hrms-v2.1.0.sh 10:27 流量切換至 v2.0.3 完成 SRE 張 Blue deployment 10:28 健康檢查通過，冒煙測試通過 SRE 張 + QA 陳 服務恢復 10:30 通知團隊：服務已恢復 SRE 張 Slack + Email 10:45 通知受影響使用者：服務已恢復 PM 林 系統公告 3. 影響評估 📝 範本 3.1 業務影響 影響維度 評估 受影響功能 {功能清單} 受影響使用者數 {人數/比例} 收入損失 {金額/無法計量} 資料損失 {是/否，描述} SLA 違反 {是/否，影響 SLA 指標} 信譽影響 {高/中/低} 3.2 技術影響 影響維度 評估 受影響服務 {服務清單} 相依服務影響 {是否連鎖影響} 資料一致性 {是否受影響} 安全性影響 {是否有安全疑慮} 📖 使用說明 影響評估用於確認嚴重等級是否正確、作為改善優先級依據 業務影響由 PM/產品團隊提供；技術影響由工程團隊評估 SLA 違反需記錄，可能涉及客戶賠償或內部 KPI 💡 範例 3.1 業務影響 影響維度 評估 受影響功能 薪資查詢、薪資條下載 受影響使用者數 ~200 人（嘗試查詢薪資的員工） 收入損失 無直接收入損失（內部系統） 資料損失 無 SLA 違反 否（SLA 99.5% 月度，本月仍在 SLA 內） 信譽影響 低（事件持續 13 分鐘，非上班尖峰） 4. 根因分析 📝 範本 4.1 根本原因 Root Cause Statement：\n","title":"事件報告與根因分析範本（Incident Report \u0026 RCA Template）"},{"content":"使用案例文件範本（Use Case Document Template） 適用標準：ISO/IEC/IEEE 29148:2018、UML 2.5.1（Unified Modeling Language）\n適用階段：需求分析階段（Requirements Phase）\n負責角色：系統分析師（SA）、業務分析師（BA）\n📑 章節目錄 文件資訊 系統範圍與參與者 使用案例圖（Use Case Diagram） 使用案例清單 使用案例規格（逐案詳述） 業務規則 非功能性需求對應 追溯矩陣 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用案例文件 文件編號 [專案代碼]-UCD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [BA/SA 姓名] 審核者 [技術主管 / 業務主管] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 2. 系統範圍與參與者 2.1 系統邊界 項目 說明 系統名稱 [系統全名] 系統目的 [一句話描述系統核心價值] 系統範圍 [包含/不包含的功能範疇] 2.2 參與者（Actors）清單 參與者 ID 名稱 類型 說明 相關角色/系統 ACT-001 [名稱] [人/系統/時間] [簡述] [實際角色] ACT-002 [名稱] [人/系統/時間] [簡述] [實際角色] 3. 使用案例圖（Use Case Diagram） graph LR subgraph \u0026#34;System Boundary: [系統名稱]\u0026#34; UC1([UC-001: 使用案例名稱]) UC2([UC-002: 使用案例名稱]) UC3([UC-003: 使用案例名稱]) end Actor1[/Actor 1\\] --\u0026gt; UC1 Actor1 --\u0026gt; UC2 Actor2[/Actor 2\\] --\u0026gt; UC2 Actor2 --\u0026gt; UC3 UC2 -.-\u0026gt;|include| UC1 UC3 -.-\u0026gt;|extend| UC2 4. 使用案例清單 UC ID 使用案例名稱 主要參與者 優先級 複雜度 狀態 UC-001 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] UC-002 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] 5. 使用案例規格（逐案詳述） UC-[NNN]: [使用案例名稱] 項目 內容 Use Case ID UC-[NNN] 名稱 [使用案例名稱] 簡述 [一句話描述目的] 主要參與者 [Primary Actor] 次要參與者 [Secondary Actors，若無填 N/A] 觸發條件 [什麼事件啟動此使用案例] 前置條件 [執行前必須滿足的條件] 後置條件（成功） [成功完成後系統/資料狀態] 後置條件（失敗） [失敗時系統/資料狀態] 優先級 [High / Medium / Low] 頻率 [每日 N 次 / 每週 N 次] 主要流程（Main Flow）：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/usecase_template/","summary":"使用案例文件範本（Use Case Document Template） 適用標準：ISO/IEC/IEEE 29148:2018、UML 2.5.1（Unified Modeling Language）\n適用階段：需求分析階段（Requirements Phase）\n負責角色：系統分析師（SA）、業務分析師（BA）\n📑 章節目錄 文件資訊 系統範圍與參與者 使用案例圖（Use Case Diagram） 使用案例清單 使用案例規格（逐案詳述） 業務規則 非功能性需求對應 追溯矩陣 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用案例文件 文件編號 [專案代碼]-UCD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [BA/SA 姓名] 審核者 [技術主管 / 業務主管] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 2. 系統範圍與參與者 2.1 系統邊界 項目 說明 系統名稱 [系統全名] 系統目的 [一句話描述系統核心價值] 系統範圍 [包含/不包含的功能範疇] 2.2 參與者（Actors）清單 參與者 ID 名稱 類型 說明 相關角色/系統 ACT-001 [名稱] [人/系統/時間] [簡述] [實際角色] ACT-002 [名稱] [人/系統/時間] [簡述] [實際角色] 3. 使用案例圖（Use Case Diagram） graph LR subgraph \u0026#34;System Boundary: [系統名稱]\u0026#34; UC1([UC-001: 使用案例名稱]) UC2([UC-002: 使用案例名稱]) UC3([UC-003: 使用案例名稱]) end Actor1[/Actor 1\\] --\u0026gt; UC1 Actor1 --\u0026gt; UC2 Actor2[/Actor 2\\] --\u0026gt; UC2 Actor2 --\u0026gt; UC3 UC2 -.-\u0026gt;|include| UC1 UC3 -.-\u0026gt;|extend| UC2 4. 使用案例清單 UC ID 使用案例名稱 主要參與者 優先級 複雜度 狀態 UC-001 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] UC-002 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] 5. 使用案例規格（逐案詳述） UC-[NNN]: [使用案例名稱] 項目 內容 Use Case ID UC-[NNN] 名稱 [使用案例名稱] 簡述 [一句話描述目的] 主要參與者 [Primary Actor] 次要參與者 [Secondary Actors，若無填 N/A] 觸發條件 [什麼事件啟動此使用案例] 前置條件 [執行前必須滿足的條件] 後置條件（成功） [成功完成後系統/資料狀態] 後置條件（失敗） [失敗時系統/資料狀態] 優先級 [High / Medium / Low] 頻率 [每日 N 次 / 每週 N 次] 主要流程（Main Flow）：\n","title":"使用案例文件範本（Use Case Document Template）"},{"content":"使用者手冊範本（User Manual Template） 適用標準：ISO/IEC/IEEE 26514:2022（系統與軟體使用者文件設計）\n適用階段：專案管理 — 交付階段\n負責角色：Technical Writer、BA、PM\n📑 章節目錄 文件資訊 前言 系統概述 快速入門 功能操作說明 系統管理功能 常見問題（FAQ） 錯誤訊息與排除 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用者手冊 文件編號 [專案代碼]-UM-[版本號] 版本 v[X.Y] 適用系統版本 [系統版本號] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 作者 [Technical Writer / BA] 審核者 [PM / PO] 版本歷程 版本 日期 修改內容 修改者 v1.0 [日期] 初版 [姓名] v1.1 [日期] [修改說明] [姓名] 2. 前言 2.1 文件目的 本手冊提供 [系統名稱] 的完整操作指引，協助使用者了解系統功能並正確使用各項功能。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/project/usermanual_template/","summary":"使用者手冊範本（User Manual Template） 適用標準：ISO/IEC/IEEE 26514:2022（系統與軟體使用者文件設計）\n適用階段：專案管理 — 交付階段\n負責角色：Technical Writer、BA、PM\n📑 章節目錄 文件資訊 前言 系統概述 快速入門 功能操作說明 系統管理功能 常見問題（FAQ） 錯誤訊息與排除 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用者手冊 文件編號 [專案代碼]-UM-[版本號] 版本 v[X.Y] 適用系統版本 [系統版本號] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 作者 [Technical Writer / BA] 審核者 [PM / PO] 版本歷程 版本 日期 修改內容 修改者 v1.0 [日期] 初版 [姓名] v1.1 [日期] [修改說明] [姓名] 2. 前言 2.1 文件目的 本手冊提供 [系統名稱] 的完整操作指引，協助使用者了解系統功能並正確使用各項功能。\n","title":"使用者手冊範本（User Manual Template）"},{"content":"回滾計畫範本（Rollback Plan） 參照標準：ITIL 4（Release and Deployment Management）/ ISO/IEC 20000-1:2018\n文件用途：定義版本上線後若出現嚴重問題時的回復策略與操作步驟\n適用階段：部署上線階段（Deployment Phase）— Change Enablement\n📋 章節目錄 文件資訊 回滾觸發條件 回滾決策流程 回滾策略 回滾前準備 回滾執行步驟 資料庫回滾 回滾驗證 通知與溝通 回滾後行動 1. 文件資訊 📝 範本 項目 內容 文件編號 RP-{專案代碼}-{版本}-{序號} 文件名稱 {系統名稱} v{x.x.x} 回滾計畫 版本 v{主版本}.{次版本} 對應發佈版本 v{x.x.x} 建立日期 {YYYY-MM-DD} 撰寫者 {DevOps/SRE 姓名} 審核者 {Tech Lead / SM} 回滾時間窗口 上線後 {N} 小時內 最大容許停機 {N} 分鐘 回滾方式 Blue-Green / Canary Rollback / 全量回滾 📖 使用說明 回滾計畫是部署計畫的必要附件，每次上線都需準備 回滾時間窗口：超過此時間，資料可能已累積，回滾成本大幅增加 回滾方式取決於部署架構： Blue-Green：切換流量至舊版（秒級） Canary Rollback：停止灰度，流量回到舊版（秒級） 全量回滾：重新部署舊版 Image（分鐘級） 💡 範例 項目 內容 文件編號 RP-HRM-v2.1.0-001 對應發佈版本 v2.1.0 回滾時間窗口 上線後 4 小時內 最大容許停機 5 分鐘 回滾方式 Blue-Green（K8s Service 切換） 2. 回滾觸發條件 📝 範本 2.1 自動觸發（需設定監控告警） 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-{xxx} {條件描述} {指標} {閾值} 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-{xxx} {條件描述} {判斷依據} {角色} 📖 使用說明 自動觸發：由監控系統偵測到異常時自動發起（或告警後快速決策） 人工判斷：需要人為判斷的複雜情境 觸發條件需事先定義並經團隊共識，避免上線時臨時爭論 💡 範例 2.1 自動觸發 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-001 API 錯誤率飆升 HTTP 5xx Rate \u0026gt; 5% 持續 3 分鐘 RT-AUTO-002 回應時間嚴重惡化 P95 Latency \u0026gt; 5s 持續 5 分鐘 RT-AUTO-003 核心服務健康檢查失敗 Health Check 連續 3 次失敗 RT-AUTO-004 資料庫連線耗盡 DB Connection Pool \u0026gt; 95% 使用率持續 2 分鐘 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-001 核心業務流程異常（薪資計算錯誤） 使用者回報 + 日誌確認 Tech Lead RT-MANUAL-002 資安事件（疑似資料洩露） 資安告警 + SOC 確認 資安主管 RT-MANUAL-003 資料損壞（不一致/遺失） DB 檢查確認 DBA + Tech Lead 3. 回滾決策流程 📝 範本 偵測異常 → 通知值班人員 → 初步評估（5 分鐘內） │ ├── 可快速修復（Hotfix） → 修復並部署 → 持續觀察 │ └── 無法快速修復 → 啟動回滾決策 │ ├── 決策者確認回滾 → 執行回滾 │ └── 暫時降級（Feature Flag） → 持續觀察 決策權限矩陣 情境 決策者 升級時機 {情境} {角色} {超過 N 分鐘未解決時升級} 📖 使用說明 決策流程需在 5-15 分鐘內完成，避免長時間討論 權限矩陣確保深夜/假日也有人可做決策 Feature Flag 降級是比全量回滾更輕量的選項（如果有準備的話） 💡 範例 決策權限矩陣 情境 決策者 升級時機 上班時間（09-18） Tech Lead → PM 10 分鐘未決定 → VP Engineering 下班/假日 值班 SRE → On-call Tech Lead 15 分鐘未回應 → VP Engineering 資安事件 資安主管（不論時段） 立即通知 CTO 4. 回滾策略 📝 範本 4.1 回滾方式比較 方式 停機時間 適用場景 風險 {方式} {時間} {場景} {風險} 4.2 本次採用策略 項目 說明 回滾方式 {Blue-Green / Canary / Rolling / 全量} 回滾目標版本 v{x.x.x} 預計停機時間 {N} 分鐘 資料庫回滾 是/否（需要/不需要） Feature Flag 是/否（可局部降級） 📖 使用說明 選擇回滾策略需考量：停機影響、資料安全、回復速度 Blue-Green 最快（秒級切換）但需雙倍資源 有 DB Schema 變更時回滾最複雜，需額外評估 若有 Feature Flag，優先考慮關閉新功能而非全量回滾 💡 範例 4.1 回滾方式比較 方式 停機時間 適用場景 風險 Blue-Green 切換 \u0026lt; 30s K8s Service selector 切換 新舊版 DB Schema 需相容 Canary 回滾 \u0026lt; 30s 灰度比例回 0% 僅灰度階段可用 K8s Rolling Rollback 2-5 min kubectl rollout undo 過程中有混合版本 全量回滾 + DB Restore 15-30 min DB Schema 不相容時 停機長、可能丟失資料 4.2 本次採用策略 項目 說明 回滾方式 Blue-Green（K8s 保留舊版 Deployment） 回滾目標版本 v2.0.3 預計停機時間 \u0026lt; 1 分鐘 資料庫回滾 否（DB Migration 向後相容） Feature Flag 是（可先關閉 WebSocket 推播功能） 5. 回滾前準備 📝 範本 5.1 準備清單（部署前完成） # 準備事項 負責人 狀態 1 {準備事項} {人員} ☐ 2 {準備事項} {人員} ☐ 5.2 環境快照 項目 備份位置 備份時間 保留期限 {項目} {位置} {時間} {期限} 📖 使用說明 回滾準備必須在部署「前」完成，而非出問題才做 資料庫快照是最重要的準備（資料不可逆） 確認舊版 Image 仍可取得、舊版設定仍可存取 💡 範例 5.1 準備清單 # 準備事項 負責人 狀態 1 資料庫全量備份（pg_dump） DBA ☑ 2 保留舊版 Deployment（hrms-blue, replicas=0） DevOps ☑ 3 確認舊版 Image 可拉取：hrms:v2.0.3 DevOps ☑ 4 備份 Kong 路由設定 DevOps ☑ 5 確認 Feature Flag 可遠端關閉 後端組 ☑ 6 值班人員確認聯絡方式 SM ☑ 5.2 環境快照 項目 備份位置 備份時間 保留期限 PostgreSQL Full Backup Azure Blob / hrm-backup/ 部署前 30 分鐘 7 天 Redis RDB Snapshot Azure Blob / redis-backup/ 部署前 30 分鐘 3 天 Kong Config Export Git repo / infra/kong/ 部署前 commit 永久 K8s Manifest (old) Git repo / k8s/ 部署前 Tag 永久 6. 回滾執行步驟 📝 範本 6.1 執行步驟（依序執行） 步驟 動作 命令/操作 預期結果 執行者 1 {動作} {命令} {預期} {人員} 2 {動作} {命令} {預期} {人員} 6.2 回滾腳本 #!/bin/bash # Rollback Script - {系統名稱} v{x.x.x} → v{x.x.x} # 使用方式：./rollback.sh {腳本內容} 📖 使用說明 步驟需足夠詳細，讓非撰寫者也能執行 回滾腳本需事前測試（在 Staging 環境驗證） 每個步驟標明預期結果，便於判斷是否正確執行 腳本優先於手動操作（減少人為失誤） 💡 範例 6.1 執行步驟 步驟 動作 命令/操作 預期結果 執行者 1 確認決策 Slack 記錄回滾決策 決策者確認 SM 2 關閉新功能 Feature Flag LaunchDarkly: payroll-scheduler=OFF, ws-notification=OFF Flag 生效 後端組 3 切換流量至舊版 kubectl patch svc hrms -p '{\u0026quot;spec\u0026quot;:{\u0026quot;selector\u0026quot;:{\u0026quot;version\u0026quot;:\u0026quot;v2.0.3\u0026quot;}}}' 流量轉到 Blue DevOps 4 Scale up 舊版 kubectl scale deploy hrms-blue --replicas=3 3 Pod Running DevOps 5 驗證舊版健康 curl https://hrms.internal/health HTTP 200 + version=v2.0.3 DevOps 6 Scale down 新版 kubectl scale deploy hrms-green --replicas=0 0 Pod DevOps 7 更新 Kong 路由 移除 /ws 路由 WebSocket 端點移除 DevOps 8 驗證完整功能 執行冒煙測試腳本 All Pass QA 6.2 回滾腳本 #!/bin/bash # Rollback Script - HRMS v2.1.0 → v2.0.3 # 使用方式：./rollback-hrms-v2.1.0.sh set -euo pipefail echo \u0026#34;=== HRMS Rollback: v2.1.0 → v2.0.3 ===\u0026#34; echo \u0026#34;開始時間: $(date -Iseconds)\u0026#34; # Step 1: Scale up old version echo \u0026#34;[1/5] Scaling up v2.0.3 (Blue)...\u0026#34; kubectl scale deploy hrms-blue --replicas=3 -n hrms kubectl rollout status deploy/hrms-blue -n hrms --timeout=120s # Step 2: Switch traffic echo \u0026#34;[2/5] Switching Service to v2.0.3...\u0026#34; kubectl patch svc hrms-api -n hrms \\ -p \u0026#39;{\u0026#34;spec\u0026#34;:{\u0026#34;selector\u0026#34;:{\u0026#34;version\u0026#34;:\u0026#34;v2.0.3\u0026#34;}}}\u0026#39; # Step 3: Verify health echo \u0026#34;[3/5] Verifying health...\u0026#34; sleep 5 HEALTH=$(curl -s -o /dev/null -w \u0026#34;%{http_code}\u0026#34; https://hrms.internal/health) if [ \u0026#34;$HEALTH\u0026#34; != \u0026#34;200\u0026#34; ]; then echo \u0026#34;ERROR: Health check failed! Manual intervention required.\u0026#34; exit 1 fi # Step 4: Scale down new version echo \u0026#34;[4/5] Scaling down v2.1.0 (Green)...\u0026#34; kubectl scale deploy hrms-green --replicas=0 -n hrms # Step 5: Remove WebSocket route echo \u0026#34;[5/5] Removing WebSocket route from Kong...\u0026#34; curl -s -X DELETE http://kong-admin:8001/routes/hrms-websocket echo \u0026#34;=== Rollback Complete: $(date -Iseconds) ===\u0026#34; echo \u0026#34;請執行冒煙測試驗證: ./smoke-test.sh\u0026#34; 7. 資料庫回滾 📝 範本 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 {Migration 名稱} {描述} 是/否 {回滾方式} 7.2 資料庫回滾步驟（若需要） 步驟 動作 命令 風險 1 {動作} {命令} {風險} 📖 使用說明 向後相容的 Migration：新增欄位/表 → 不需回滾（舊版忽略新欄位即可） 不相容的 Migration：刪除/重命名欄位 → 必須回滾 資料庫回滾最危險，可能造成資料遺失，需事先做好備份 原則：盡量設計向後相容的 Migration（Expand-Contract Pattern） 💡 範例 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 AddNotificationLogs 新增 notification_logs 表 ✅ 是 不需回滾（舊版不使用此表） AddSchedulerColumns payroll 表新增 3 個 nullable 欄位 ✅ 是 不需回滾（舊版忽略） ✅ 本版所有 Migration 均為向後相容，無需資料庫回滾\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/deployment/rollbackplan_template/","summary":"回滾計畫範本（Rollback Plan） 參照標準：ITIL 4（Release and Deployment Management）/ ISO/IEC 20000-1:2018\n文件用途：定義版本上線後若出現嚴重問題時的回復策略與操作步驟\n適用階段：部署上線階段（Deployment Phase）— Change Enablement\n📋 章節目錄 文件資訊 回滾觸發條件 回滾決策流程 回滾策略 回滾前準備 回滾執行步驟 資料庫回滾 回滾驗證 通知與溝通 回滾後行動 1. 文件資訊 📝 範本 項目 內容 文件編號 RP-{專案代碼}-{版本}-{序號} 文件名稱 {系統名稱} v{x.x.x} 回滾計畫 版本 v{主版本}.{次版本} 對應發佈版本 v{x.x.x} 建立日期 {YYYY-MM-DD} 撰寫者 {DevOps/SRE 姓名} 審核者 {Tech Lead / SM} 回滾時間窗口 上線後 {N} 小時內 最大容許停機 {N} 分鐘 回滾方式 Blue-Green / Canary Rollback / 全量回滾 📖 使用說明 回滾計畫是部署計畫的必要附件，每次上線都需準備 回滾時間窗口：超過此時間，資料可能已累積，回滾成本大幅增加 回滾方式取決於部署架構： Blue-Green：切換流量至舊版（秒級） Canary Rollback：停止灰度，流量回到舊版（秒級） 全量回滾：重新部署舊版 Image（分鐘級） 💡 範例 項目 內容 文件編號 RP-HRM-v2.1.0-001 對應發佈版本 v2.1.0 回滾時間窗口 上線後 4 小時內 最大容許停機 5 分鐘 回滾方式 Blue-Green（K8s Service 切換） 2. 回滾觸發條件 📝 範本 2.1 自動觸發（需設定監控告警） 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-{xxx} {條件描述} {指標} {閾值} 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-{xxx} {條件描述} {判斷依據} {角色} 📖 使用說明 自動觸發：由監控系統偵測到異常時自動發起（或告警後快速決策） 人工判斷：需要人為判斷的複雜情境 觸發條件需事先定義並經團隊共識，避免上線時臨時爭論 💡 範例 2.1 自動觸發 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-001 API 錯誤率飆升 HTTP 5xx Rate \u0026gt; 5% 持續 3 分鐘 RT-AUTO-002 回應時間嚴重惡化 P95 Latency \u0026gt; 5s 持續 5 分鐘 RT-AUTO-003 核心服務健康檢查失敗 Health Check 連續 3 次失敗 RT-AUTO-004 資料庫連線耗盡 DB Connection Pool \u0026gt; 95% 使用率持續 2 分鐘 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-001 核心業務流程異常（薪資計算錯誤） 使用者回報 + 日誌確認 Tech Lead RT-MANUAL-002 資安事件（疑似資料洩露） 資安告警 + SOC 確認 資安主管 RT-MANUAL-003 資料損壞（不一致/遺失） DB 檢查確認 DBA + Tech Lead 3. 回滾決策流程 📝 範本 偵測異常 → 通知值班人員 → 初步評估（5 分鐘內） │ ├── 可快速修復（Hotfix） → 修復並部署 → 持續觀察 │ └── 無法快速修復 → 啟動回滾決策 │ ├── 決策者確認回滾 → 執行回滾 │ └── 暫時降級（Feature Flag） → 持續觀察 決策權限矩陣 情境 決策者 升級時機 {情境} {角色} {超過 N 分鐘未解決時升級} 📖 使用說明 決策流程需在 5-15 分鐘內完成，避免長時間討論 權限矩陣確保深夜/假日也有人可做決策 Feature Flag 降級是比全量回滾更輕量的選項（如果有準備的話） 💡 範例 決策權限矩陣 情境 決策者 升級時機 上班時間（09-18） Tech Lead → PM 10 分鐘未決定 → VP Engineering 下班/假日 值班 SRE → On-call Tech Lead 15 分鐘未回應 → VP Engineering 資安事件 資安主管（不論時段） 立即通知 CTO 4. 回滾策略 📝 範本 4.1 回滾方式比較 方式 停機時間 適用場景 風險 {方式} {時間} {場景} {風險} 4.2 本次採用策略 項目 說明 回滾方式 {Blue-Green / Canary / Rolling / 全量} 回滾目標版本 v{x.x.x} 預計停機時間 {N} 分鐘 資料庫回滾 是/否（需要/不需要） Feature Flag 是/否（可局部降級） 📖 使用說明 選擇回滾策略需考量：停機影響、資料安全、回復速度 Blue-Green 最快（秒級切換）但需雙倍資源 有 DB Schema 變更時回滾最複雜，需額外評估 若有 Feature Flag，優先考慮關閉新功能而非全量回滾 💡 範例 4.1 回滾方式比較 方式 停機時間 適用場景 風險 Blue-Green 切換 \u0026lt; 30s K8s Service selector 切換 新舊版 DB Schema 需相容 Canary 回滾 \u0026lt; 30s 灰度比例回 0% 僅灰度階段可用 K8s Rolling Rollback 2-5 min kubectl rollout undo 過程中有混合版本 全量回滾 + DB Restore 15-30 min DB Schema 不相容時 停機長、可能丟失資料 4.2 本次採用策略 項目 說明 回滾方式 Blue-Green（K8s 保留舊版 Deployment） 回滾目標版本 v2.0.3 預計停機時間 \u0026lt; 1 分鐘 資料庫回滾 否（DB Migration 向後相容） Feature Flag 是（可先關閉 WebSocket 推播功能） 5. 回滾前準備 📝 範本 5.1 準備清單（部署前完成） # 準備事項 負責人 狀態 1 {準備事項} {人員} ☐ 2 {準備事項} {人員} ☐ 5.2 環境快照 項目 備份位置 備份時間 保留期限 {項目} {位置} {時間} {期限} 📖 使用說明 回滾準備必須在部署「前」完成，而非出問題才做 資料庫快照是最重要的準備（資料不可逆） 確認舊版 Image 仍可取得、舊版設定仍可存取 💡 範例 5.1 準備清單 # 準備事項 負責人 狀態 1 資料庫全量備份（pg_dump） DBA ☑ 2 保留舊版 Deployment（hrms-blue, replicas=0） DevOps ☑ 3 確認舊版 Image 可拉取：hrms:v2.0.3 DevOps ☑ 4 備份 Kong 路由設定 DevOps ☑ 5 確認 Feature Flag 可遠端關閉 後端組 ☑ 6 值班人員確認聯絡方式 SM ☑ 5.2 環境快照 項目 備份位置 備份時間 保留期限 PostgreSQL Full Backup Azure Blob / hrm-backup/ 部署前 30 分鐘 7 天 Redis RDB Snapshot Azure Blob / redis-backup/ 部署前 30 分鐘 3 天 Kong Config Export Git repo / infra/kong/ 部署前 commit 永久 K8s Manifest (old) Git repo / k8s/ 部署前 Tag 永久 6. 回滾執行步驟 📝 範本 6.1 執行步驟（依序執行） 步驟 動作 命令/操作 預期結果 執行者 1 {動作} {命令} {預期} {人員} 2 {動作} {命令} {預期} {人員} 6.2 回滾腳本 #!/bin/bash # Rollback Script - {系統名稱} v{x.x.x} → v{x.x.x} # 使用方式：./rollback.sh {腳本內容} 📖 使用說明 步驟需足夠詳細，讓非撰寫者也能執行 回滾腳本需事前測試（在 Staging 環境驗證） 每個步驟標明預期結果，便於判斷是否正確執行 腳本優先於手動操作（減少人為失誤） 💡 範例 6.1 執行步驟 步驟 動作 命令/操作 預期結果 執行者 1 確認決策 Slack 記錄回滾決策 決策者確認 SM 2 關閉新功能 Feature Flag LaunchDarkly: payroll-scheduler=OFF, ws-notification=OFF Flag 生效 後端組 3 切換流量至舊版 kubectl patch svc hrms -p '{\u0026quot;spec\u0026quot;:{\u0026quot;selector\u0026quot;:{\u0026quot;version\u0026quot;:\u0026quot;v2.0.3\u0026quot;}}}' 流量轉到 Blue DevOps 4 Scale up 舊版 kubectl scale deploy hrms-blue --replicas=3 3 Pod Running DevOps 5 驗證舊版健康 curl https://hrms.internal/health HTTP 200 + version=v2.0.3 DevOps 6 Scale down 新版 kubectl scale deploy hrms-green --replicas=0 0 Pod DevOps 7 更新 Kong 路由 移除 /ws 路由 WebSocket 端點移除 DevOps 8 驗證完整功能 執行冒煙測試腳本 All Pass QA 6.2 回滾腳本 #!/bin/bash # Rollback Script - HRMS v2.1.0 → v2.0.3 # 使用方式：./rollback-hrms-v2.1.0.sh set -euo pipefail echo \u0026#34;=== HRMS Rollback: v2.1.0 → v2.0.3 ===\u0026#34; echo \u0026#34;開始時間: $(date -Iseconds)\u0026#34; # Step 1: Scale up old version echo \u0026#34;[1/5] Scaling up v2.0.3 (Blue)...\u0026#34; kubectl scale deploy hrms-blue --replicas=3 -n hrms kubectl rollout status deploy/hrms-blue -n hrms --timeout=120s # Step 2: Switch traffic echo \u0026#34;[2/5] Switching Service to v2.0.3...\u0026#34; kubectl patch svc hrms-api -n hrms \\ -p \u0026#39;{\u0026#34;spec\u0026#34;:{\u0026#34;selector\u0026#34;:{\u0026#34;version\u0026#34;:\u0026#34;v2.0.3\u0026#34;}}}\u0026#39; # Step 3: Verify health echo \u0026#34;[3/5] Verifying health...\u0026#34; sleep 5 HEALTH=$(curl -s -o /dev/null -w \u0026#34;%{http_code}\u0026#34; https://hrms.internal/health) if [ \u0026#34;$HEALTH\u0026#34; != \u0026#34;200\u0026#34; ]; then echo \u0026#34;ERROR: Health check failed! Manual intervention required.\u0026#34; exit 1 fi # Step 4: Scale down new version echo \u0026#34;[4/5] Scaling down v2.1.0 (Green)...\u0026#34; kubectl scale deploy hrms-green --replicas=0 -n hrms # Step 5: Remove WebSocket route echo \u0026#34;[5/5] Removing WebSocket route from Kong...\u0026#34; curl -s -X DELETE http://kong-admin:8001/routes/hrms-websocket echo \u0026#34;=== Rollback Complete: $(date -Iseconds) ===\u0026#34; echo \u0026#34;請執行冒煙測試驗證: ./smoke-test.sh\u0026#34; 7. 資料庫回滾 📝 範本 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 {Migration 名稱} {描述} 是/否 {回滾方式} 7.2 資料庫回滾步驟（若需要） 步驟 動作 命令 風險 1 {動作} {命令} {風險} 📖 使用說明 向後相容的 Migration：新增欄位/表 → 不需回滾（舊版忽略新欄位即可） 不相容的 Migration：刪除/重命名欄位 → 必須回滾 資料庫回滾最危險，可能造成資料遺失，需事先做好備份 原則：盡量設計向後相容的 Migration（Expand-Contract Pattern） 💡 範例 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 AddNotificationLogs 新增 notification_logs 表 ✅ 是 不需回滾（舊版不使用此表） AddSchedulerColumns payroll 表新增 3 個 nullable 欄位 ✅ 是 不需回滾（舊版忽略） ✅ 本版所有 Migration 均為向後相容，無需資料庫回滾\n","title":"回滾計畫範本（Rollback Plan Template）"},{"content":"基礎設施架構設計文件範本（Infrastructure Architecture Document Template） 適用標準：ISO/IEC/IEEE 42010:2022（架構描述）、TOGAF ADM、C4 Model、ISO/IEC 27001:2022（資安）\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、基礎設施工程師（Infra Engineer）、雲端架構師\n📑 章節目錄 文件資訊 架構設計目標與約束 系統架構總覽 網路架構設計 運算資源配置 儲存與資料庫架構 高可用與災難復原設計 安全架構設計 監控與可觀測性架構 CI/CD 部署架構 容量規劃與擴展策略 環境規劃 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 基礎設施架構設計文件 文件編號 [專案代碼]-IAD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [架構師姓名] 審核者 [技術主管] 核准者 [專案經理 / CTO] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件（SAD） [編號] 邏輯架構來源 非功能性需求規格 [編號] NFR 輸入 安全需求清單 [編號] 安全設計依據 資料庫設計文件 [編號] 資料層設計 2. 架構設計目標與約束 2.1 設計目標 品質屬性 目標 衡量指標 可用性（Availability） [目標 SLA %] Uptime ≥ [N]% 效能（Performance） [回應時間目標] P95 \u0026lt; [N]ms, TPS ≥ [N] 延展性（Scalability） [擴展能力] 支援 [N] 並發用戶 安全性（Security） [合規要求] 符合 [法規/標準] 可維護性（Maintainability） [維護便利性] MTTR \u0026lt; [N] min 成本效益（Cost） [預算限制] 月費 \u0026lt; [N] USD 2.2 設計約束 約束類型 約束內容 來源 技術約束 [指定雲端平台 / 技術堆疊] [組織政策] 法規約束 [資料落地區域 / 合規要求] [法規名稱] 預算約束 [月度/年度預算上限] [專案預算] 時程約束 [上線日期限制] [專案時程] 組織約束 [現有團隊技能 / 維運能量] [人力限制] 2.3 架構決策記錄（ADR） ADR# 決策標題 狀態 日期 ADR-001 [選用 Kubernetes 作為容器編排平台] Accepted [YYYY-MM-DD] ADR-002 [採用 Multi-AZ 部署策略] Accepted [YYYY-MM-DD] ADR 格式：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/infrastructurearchitecture_template/","summary":"基礎設施架構設計文件範本（Infrastructure Architecture Document Template） 適用標準：ISO/IEC/IEEE 42010:2022（架構描述）、TOGAF ADM、C4 Model、ISO/IEC 27001:2022（資安）\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、基礎設施工程師（Infra Engineer）、雲端架構師\n📑 章節目錄 文件資訊 架構設計目標與約束 系統架構總覽 網路架構設計 運算資源配置 儲存與資料庫架構 高可用與災難復原設計 安全架構設計 監控與可觀測性架構 CI/CD 部署架構 容量規劃與擴展策略 環境規劃 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 基礎設施架構設計文件 文件編號 [專案代碼]-IAD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [架構師姓名] 審核者 [技術主管] 核准者 [專案經理 / CTO] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件（SAD） [編號] 邏輯架構來源 非功能性需求規格 [編號] NFR 輸入 安全需求清單 [編號] 安全設計依據 資料庫設計文件 [編號] 資料層設計 2. 架構設計目標與約束 2.1 設計目標 品質屬性 目標 衡量指標 可用性（Availability） [目標 SLA %] Uptime ≥ [N]% 效能（Performance） [回應時間目標] P95 \u0026lt; [N]ms, TPS ≥ [N] 延展性（Scalability） [擴展能力] 支援 [N] 並發用戶 安全性（Security） [合規要求] 符合 [法規/標準] 可維護性（Maintainability） [維護便利性] MTTR \u0026lt; [N] min 成本效益（Cost） [預算限制] 月費 \u0026lt; [N] USD 2.2 設計約束 約束類型 約束內容 來源 技術約束 [指定雲端平台 / 技術堆疊] [組織政策] 法規約束 [資料落地區域 / 合規要求] [法規名稱] 預算約束 [月度/年度預算上限] [專案預算] 時程約束 [上線日期限制] [專案時程] 組織約束 [現有團隊技能 / 維運能量] [人力限制] 2.3 架構決策記錄（ADR） ADR# 決策標題 狀態 日期 ADR-001 [選用 Kubernetes 作為容器編排平台] Accepted [YYYY-MM-DD] ADR-002 [採用 Multi-AZ 部署策略] Accepted [YYYY-MM-DD] ADR 格式：\n","title":"基礎設施架構設計文件範本（Infrastructure Architecture Document Template）"},{"content":"威脅模型範本（Threat Model Document） 參照標準：Microsoft STRIDE / OWASP Threat Modeling / ISO/IEC 27005:2022\n文件用途：系統性識別、分析、評估與處置系統面臨的安全威脅\n適用階段：系統設計階段（Design Phase）— Security by Design\n📋 章節目錄 文件資訊 系統概述 資料流程圖（DFD） 信任邊界識別 STRIDE 威脅分析 威脅風險評估 緩解措施 殘餘風險 威脅追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TM-{專案代碼}-{序號} 文件名稱 {系統名稱} 威脅模型 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 撰寫者 {姓名/角色} 資安審核者 {資安人員姓名} 威脅建模方法 STRIDE / PASTA / LINDDUN 分析範圍 {描述分析涵蓋的系統邊界} 📖 使用說明 威脅模型在架構設計完成後、開發實作前進行 建議組成跨功能團隊：架構師 + 資安人員 + 開發者 + QA STRIDE 是微軟提出的分類法，覆蓋六大威脅類型 本文件需與安全需求清單（SecurityRequirements）互相參照 💡 範例 項目 內容 文件編號 TM-HRM-001 系統名稱 人力資源管理系統（HRMS） 威脅建模方法 STRIDE 分析範圍 Web 前端、API Gateway、微服務層、資料庫層、外部整合（AD/Email） 2. 系統概述 📝 範本 2.1 系統架構摘要 元件 技術 角色描述 {元件名稱} {技術/框架} {職責說明} 2.2 資產識別 資產 ID 資產名稱 資產類型 敏感等級 擁有者 ASSET-{xxx} {名稱} 資料/服務/基礎設施 高/中/低 {團隊} 📖 使用說明 系統架構摘要提供技術棧全貌，協助識別攻擊面 資產識別需列出需保護的有價值目標（攻擊者感興趣的） 資產敏感等級決定威脅分析的優先順序 💡 範例 2.1 系統架構摘要 元件 技術 角色描述 Web SPA React 18 + TypeScript 使用者介面 API Gateway Kong 3.x 請求路由、速率限制、認證 Auth Service .NET 8 + IdentityServer 身分認證與 Token 核發 HR Core Service .NET 8 Web API 員工/薪資/假勤核心邏輯 PostgreSQL v16 關聯式資料儲存 Redis v7 Session/Cache 快取 Active Directory Windows Server 2022 企業帳號整合 2.2 資產識別 資產 ID 資產名稱 資產類型 敏感等級 擁有者 ASSET-001 員工個資（身分證/地址/緊急聯絡人） 資料 高 HR 部門 ASSET-002 薪資明細（薪資/獎金/扣款） 資料 高 財務部 ASSET-003 認證 Token / Session 資料 高 系統 ASSET-004 API Gateway 服務 中 IT 維運 ASSET-005 資料庫加密金鑰 基礎設施 高 資安團隊 3. 資料流程圖（DFD） 📝 範本 Level 0 - 系統環境圖 外部實體 → [系統邊界] → 外部實體 Level 1 - 子系統分解 DFD 元素 符號 說明 外部實體 矩形 系統範圍外的使用者/系統 處理程序 圓形 系統內部邏輯處理 資料儲存 平行線 資料庫/檔案 資料流 箭頭 資料移動方向 信任邊界 虛線框 安全等級分界 📖 使用說明 DFD 是威脅建模的核心輸入，透過視覺化理解資料流向 Level 0 呈現系統與外部互動全貌 Level 1 展開各子系統，識別每個資料流的信任邊界 建議使用工具：Microsoft Threat Modeling Tool、OWASP Threat Dragon 💡 範例 Level 1 - HRMS 子系統分解 ┌─────────────────── 信任邊界：Internet ───────────────────┐ │ │ │ [員工/主管] ────→ Web SPA (React) │ │ │ └─────────────────────────────────────────────────────────┘ │ HTTPS (JWT) ┌────────────────── 信任邊界：DMZ ────────────────────────┐ │ ▼ │ │ (API Gateway - Kong) │ │ │ │ └───────────────────────────┼──────────────────────────────┘ │ mTLS ┌────────────────── 信任邊界：Internal ───────────────────┐ │ ▼ │ │ (Auth Service) ←── (HR Core Service) │ │ │ │ │ │ ▼ ▼ │ │ [Redis Cache] [PostgreSQL DB] │ │ │ └─────────────────────────────────────────────────────────┘ │ LDAPS ┌────────────────── 信任邊界：Enterprise ─────────────────┐ │ ▼ │ │ [Active Directory] │ │ │ └─────────────────────────────────────────────────────────┘ 4. 信任邊界識別 📝 範本 邊界 ID 邊界名稱 起點 終點 跨越邊界的資料 保護機制 TB-{xxx} {邊界名稱} {元件} {元件} {資料描述} {保護} 📖 使用說明 信任邊界是安全等級不同的兩個區域之間的分界線 跨越信任邊界的資料流是威脅分析的重點（攻擊最可能發生處） 每條跨邊界的資料流都需要相應的保護機制 💡 範例 邊界 ID 邊界名稱 起點 終點 跨越邊界的資料 保護機制 TB-001 Internet → DMZ Web SPA API Gateway HTTP 請求 + JWT TLS 1.3、WAF、Rate Limit TB-002 DMZ → Internal API Gateway HR Core Service API 呼叫 + 使用者上下文 mTLS、服務網格 TB-003 Internal → DB HR Core Service PostgreSQL SQL 查詢 + 個資 連線加密、最小權限 TB-004 Internal → Enterprise Auth Service Active Directory LDAP 認證請求 LDAPS (636 port) 5. STRIDE 威脅分析 📝 範本 STRIDE 分類說明 類型 英文 說明 違反的安全屬性 S Spoofing 身份冒充 認證（Authentication） T Tampering 資料竄改 完整性（Integrity） R Repudiation 否認行為 不可否認性（Non-Repudiation） I Information Disclosure 資訊洩露 機密性（Confidentiality） D Denial of Service 阻斷服務 可用性（Availability） E Elevation of Privilege 權限提升 授權（Authorization） 威脅列表 威脅 ID STRIDE 目標元件 威脅描述 攻擊場景 THR-{xxx} S/T/R/I/D/E {元件} {威脅描述} {攻擊者如何利用} 📖 使用說明 逐一對每個 DFD 元素（處理程序、資料儲存、資料流）套用 STRIDE 外部實體通常只分析 S（Spoofing）和 R（Repudiation） 資料儲存通常分析 T、I、D 處理程序所有 STRIDE 類型都適用 每個威脅需具體描述攻擊場景（非泛泛而談） 💡 範例 威脅 ID STRIDE 目標元件 威脅描述 攻擊場景 THR-001 S API Gateway 偽造 JWT Token 冒充合法使用者 攻擊者取得 JWT Secret 或使用弱演算法偽造 Token THR-002 T HR Core Service 竄改薪資計算邏輯 內部人員修改薪資計算 API 參數，增加自己薪資 THR-003 R HR Core Service 管理員否認執行薪資調整操作 管理員調整薪資後聲稱未進行此操作 THR-004 I PostgreSQL 員工個資大量外洩 SQL Injection 或未加密備份遭竊 THR-005 D API Gateway DDoS 癱瘓打卡/請假功能 攻擊者以大量請求衝擊 API Gateway THR-006 E Auth Service 一般員工提升至 Admin 權限 利用 IDOR 漏洞修改角色欄位 THR-007 I Redis Cache Session 資料從快取洩露 未加密的 Redis 連線被中間人竊聽 THR-008 S Active Directory 暴力破解 AD 帳號密碼 對 LDAP 認證端點進行字典攻擊 6. 威脅風險評估 📝 範本 風險評分標準（DREAD 或自訂） 評分維度 1（低） 2（中） 3（高） 影響程度（Impact） 非敏感資料 部分敏感資料 核心/大量敏感資料 發生可能性（Likelihood） 需高階技術+內部存取 中等技術+外部存取 低門檻+自動化工具 可利用性（Exploitability） 無公開漏洞 有概念驗證 有公開利用工具 風險評估結果 威脅 ID 影響 可能性 可利用性 總分 風險等級 THR-{xxx} {1-3} {1-3} {1-3} {N} 高/中/低 📖 使用說明 風險等級 = 影響 × 可能性 × 可利用性（或加總取平均） 高風險（7-9分）：必須在上線前處置 中風險（4-6分）：計畫性處理，可接受短期風險 低風險（1-3分）：記錄並持續監控 風險評估結果決定緩解措施的優先順序 💡 範例 威脅 ID 影響 可能性 可利用性 總分 風險等級 THR-001 3 2 2 7 高 THR-002 3 1 1 5 中 THR-003 2 2 3 7 高 THR-004 3 2 3 8 高 THR-005 2 3 3 8 高 THR-006 3 2 2 7 高 THR-007 2 1 2 5 中 THR-008 3 2 3 8 高 7. 緩解措施 📝 範本 威脅 ID 緩解措施 對應安全需求 實作方式 負責人 狀態 THR-{xxx} {緩解描述} SEC-{xxx} {技術/流程手段} {人員} 未開始/進行中/完成 📖 使用說明 每個高/中風險威脅都需要對應的緩解措施 緩解策略分為四種： 消除：重新設計，完全移除威脅（最佳） 緩解：降低影響或可能性（最常見） 轉移：轉移風險給第三方（保險/外包） 接受：記錄風險，不處理（需管理層核准） 緩解措施需連結到安全需求清單（SecurityRequirements）中的具體需求 💡 範例 威脅 ID 緩解措施 對應安全需求 實作方式 負責人 狀態 THR-001 使用 RS256 非對稱簽章 + 短效 Token SEC-AUTH-006 JWT RS256 + 15min Expiry 後端組 完成 THR-003 所有薪資操作記錄不可竄改稽核日誌 SEC-LOG-001, SEC-LOG-004 Append-only audit log + 時間戳簽章 後端組 進行中 THR-004 個資欄位加密 + 參數化查詢 + WAF SEC-DATA-001, SEC-INPUT-002 AES-256 + EF Core parameterized + ModSecurity 全端 完成 THR-005 API Rate Limiting + CDN + Auto-scaling SEC-INPUT-005 Kong rate-limit plugin (100 req/min) + Azure CDN DevOps 完成 THR-006 伺服器端角色驗證 + 單元測試覆蓋 SEC-AUTHZ-001, SEC-AUTHZ-003 [Authorize(Roles=\u0026ldquo;Admin\u0026rdquo;)] + IDOR 防護 後端組 完成 THR-008 帳號鎖定 + MFA + IP 白名單 SEC-AUTH-002, SEC-AUTH-003 AD 帳號鎖定策略 + Azure MFA IT 維運 進行中 8. 殘餘風險 📝 範本 威脅 ID 殘餘風險描述 緩解後風險等級 接受理由 核准者 核准日期 THR-{xxx} {緩解後仍存在的風險} 高/中/低 {為何可接受} {管理層} {日期} 📖 使用說明 殘餘風險 = 實施緩解措施後仍無法完全消除的風險 所有殘餘風險需經管理層正式核准（Risk Acceptance） 殘餘風險需定期重新評估（至少每季度） 高殘餘風險應有補償性控制措施 💡 範例 威脅 ID 殘餘風險描述 緩解後風險等級 接受理由 核准者 核准日期 THR-005 DDoS 超過 CDN 容量時仍可能影響可用性 低 CDN 已可承受 99% 場景，剩餘機率極低 CTO 2026-05-15 THR-007 Redis 若被直接存取仍可讀取 Session 低 Redis 位於 VPC 內網，無外部可達性 資安主管 2026-05-15 9. 威脅追溯矩陣 📝 範本 威脅 ID DFD 元素 信任邊界 安全需求 緩解措施 測試案例 THR-{xxx} {元件} TB-{xxx} SEC-{xxx} {緩解} TC-{xxx} 📖 使用說明 追溯矩陣確保每個威脅都能向前追溯到架構元素、向後追溯到測試案例 完整鏈路：DFD 元素 → 信任邊界 → 威脅 → 安全需求 → 緩解措施 → 測試驗證 若某威脅沒有對應的測試案例，代表測試覆蓋不足 💡 範例 威脅 ID DFD 元素 信任邊界 安全需求 緩解措施 測試案例 THR-001 API Gateway TB-001 SEC-AUTH-006 RS256 + 短效 Token TC-SEC-001: Token 偽造測試 THR-004 PostgreSQL TB-003 SEC-DATA-001, SEC-INPUT-002 加密 + 參數化查詢 TC-SEC-004: SQL Injection Pen Test THR-005 API Gateway TB-001 SEC-INPUT-005 Rate Limiting TC-SEC-005: 壓力測試 + DDoS 模擬 THR-006 Auth Service TB-002 SEC-AUTHZ-001 伺服器端授權 TC-SEC-006: IDOR 測試 10. 附錄 📝 範本 10.1 威脅建模會議記錄 日期 參與者 討論主題 決議 {日期} {姓名,角色} {主題} {決議} 10.2 參考資料 資源 用途 OWASP Threat Modeling Cheat Sheet 威脅建模方法論參考 Microsoft STRIDE per Element 每元素類型適用的 STRIDE 分析 OWASP ASVS 4.0.3 安全需求對照標準 ISO/IEC 27005:2022 風險評估方法論 📖 使用說明 會議記錄保留威脅建模決策的可追溯性 建議威脅模型每個 Sprint 或重大架構變更時更新 工具推薦：Microsoft Threat Modeling Tool (免費)、OWASP Threat Dragon (開源) 💡 範例 10.1 威脅建模會議記錄 日期 參與者 討論主題 決議 2026-04-10 張架構師, 李資安, 王開發 Level 1 DFD 繪製與邊界確認 TB-001~TB-004 確認 2026-04-12 張架構師, 李資安, 陳 QA STRIDE 分析（THR-001~008） 8 個威脅確認，6 個為高風險 2026-04-15 CTO, 資安主管, 張架構師 殘餘風險接受 THR-005, THR-007 殘餘風險核准接受 📌 範本使用注意事項\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/threatmodel_template/","summary":"威脅模型範本（Threat Model Document） 參照標準：Microsoft STRIDE / OWASP Threat Modeling / ISO/IEC 27005:2022\n文件用途：系統性識別、分析、評估與處置系統面臨的安全威脅\n適用階段：系統設計階段（Design Phase）— Security by Design\n📋 章節目錄 文件資訊 系統概述 資料流程圖（DFD） 信任邊界識別 STRIDE 威脅分析 威脅風險評估 緩解措施 殘餘風險 威脅追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TM-{專案代碼}-{序號} 文件名稱 {系統名稱} 威脅模型 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 撰寫者 {姓名/角色} 資安審核者 {資安人員姓名} 威脅建模方法 STRIDE / PASTA / LINDDUN 分析範圍 {描述分析涵蓋的系統邊界} 📖 使用說明 威脅模型在架構設計完成後、開發實作前進行 建議組成跨功能團隊：架構師 + 資安人員 + 開發者 + QA STRIDE 是微軟提出的分類法，覆蓋六大威脅類型 本文件需與安全需求清單（SecurityRequirements）互相參照 💡 範例 項目 內容 文件編號 TM-HRM-001 系統名稱 人力資源管理系統（HRMS） 威脅建模方法 STRIDE 分析範圍 Web 前端、API Gateway、微服務層、資料庫層、外部整合（AD/Email） 2. 系統概述 📝 範本 2.1 系統架構摘要 元件 技術 角色描述 {元件名稱} {技術/框架} {職責說明} 2.2 資產識別 資產 ID 資產名稱 資產類型 敏感等級 擁有者 ASSET-{xxx} {名稱} 資料/服務/基礎設施 高/中/低 {團隊} 📖 使用說明 系統架構摘要提供技術棧全貌，協助識別攻擊面 資產識別需列出需保護的有價值目標（攻擊者感興趣的） 資產敏感等級決定威脅分析的優先順序 💡 範例 2.1 系統架構摘要 元件 技術 角色描述 Web SPA React 18 + TypeScript 使用者介面 API Gateway Kong 3.x 請求路由、速率限制、認證 Auth Service .NET 8 + IdentityServer 身分認證與 Token 核發 HR Core Service .NET 8 Web API 員工/薪資/假勤核心邏輯 PostgreSQL v16 關聯式資料儲存 Redis v7 Session/Cache 快取 Active Directory Windows Server 2022 企業帳號整合 2.2 資產識別 資產 ID 資產名稱 資產類型 敏感等級 擁有者 ASSET-001 員工個資（身分證/地址/緊急聯絡人） 資料 高 HR 部門 ASSET-002 薪資明細（薪資/獎金/扣款） 資料 高 財務部 ASSET-003 認證 Token / Session 資料 高 系統 ASSET-004 API Gateway 服務 中 IT 維運 ASSET-005 資料庫加密金鑰 基礎設施 高 資安團隊 3. 資料流程圖（DFD） 📝 範本 Level 0 - 系統環境圖 外部實體 → [系統邊界] → 外部實體 Level 1 - 子系統分解 DFD 元素 符號 說明 外部實體 矩形 系統範圍外的使用者/系統 處理程序 圓形 系統內部邏輯處理 資料儲存 平行線 資料庫/檔案 資料流 箭頭 資料移動方向 信任邊界 虛線框 安全等級分界 📖 使用說明 DFD 是威脅建模的核心輸入，透過視覺化理解資料流向 Level 0 呈現系統與外部互動全貌 Level 1 展開各子系統，識別每個資料流的信任邊界 建議使用工具：Microsoft Threat Modeling Tool、OWASP Threat Dragon 💡 範例 Level 1 - HRMS 子系統分解 ┌─────────────────── 信任邊界：Internet ───────────────────┐ │ │ │ [員工/主管] ────→ Web SPA (React) │ │ │ └─────────────────────────────────────────────────────────┘ │ HTTPS (JWT) ┌────────────────── 信任邊界：DMZ ────────────────────────┐ │ ▼ │ │ (API Gateway - Kong) │ │ │ │ └───────────────────────────┼──────────────────────────────┘ │ mTLS ┌────────────────── 信任邊界：Internal ───────────────────┐ │ ▼ │ │ (Auth Service) ←── (HR Core Service) │ │ │ │ │ │ ▼ ▼ │ │ [Redis Cache] [PostgreSQL DB] │ │ │ └─────────────────────────────────────────────────────────┘ │ LDAPS ┌────────────────── 信任邊界：Enterprise ─────────────────┐ │ ▼ │ │ [Active Directory] │ │ │ └─────────────────────────────────────────────────────────┘ 4. 信任邊界識別 📝 範本 邊界 ID 邊界名稱 起點 終點 跨越邊界的資料 保護機制 TB-{xxx} {邊界名稱} {元件} {元件} {資料描述} {保護} 📖 使用說明 信任邊界是安全等級不同的兩個區域之間的分界線 跨越信任邊界的資料流是威脅分析的重點（攻擊最可能發生處） 每條跨邊界的資料流都需要相應的保護機制 💡 範例 邊界 ID 邊界名稱 起點 終點 跨越邊界的資料 保護機制 TB-001 Internet → DMZ Web SPA API Gateway HTTP 請求 + JWT TLS 1.3、WAF、Rate Limit TB-002 DMZ → Internal API Gateway HR Core Service API 呼叫 + 使用者上下文 mTLS、服務網格 TB-003 Internal → DB HR Core Service PostgreSQL SQL 查詢 + 個資 連線加密、最小權限 TB-004 Internal → Enterprise Auth Service Active Directory LDAP 認證請求 LDAPS (636 port) 5. STRIDE 威脅分析 📝 範本 STRIDE 分類說明 類型 英文 說明 違反的安全屬性 S Spoofing 身份冒充 認證（Authentication） T Tampering 資料竄改 完整性（Integrity） R Repudiation 否認行為 不可否認性（Non-Repudiation） I Information Disclosure 資訊洩露 機密性（Confidentiality） D Denial of Service 阻斷服務 可用性（Availability） E Elevation of Privilege 權限提升 授權（Authorization） 威脅列表 威脅 ID STRIDE 目標元件 威脅描述 攻擊場景 THR-{xxx} S/T/R/I/D/E {元件} {威脅描述} {攻擊者如何利用} 📖 使用說明 逐一對每個 DFD 元素（處理程序、資料儲存、資料流）套用 STRIDE 外部實體通常只分析 S（Spoofing）和 R（Repudiation） 資料儲存通常分析 T、I、D 處理程序所有 STRIDE 類型都適用 每個威脅需具體描述攻擊場景（非泛泛而談） 💡 範例 威脅 ID STRIDE 目標元件 威脅描述 攻擊場景 THR-001 S API Gateway 偽造 JWT Token 冒充合法使用者 攻擊者取得 JWT Secret 或使用弱演算法偽造 Token THR-002 T HR Core Service 竄改薪資計算邏輯 內部人員修改薪資計算 API 參數，增加自己薪資 THR-003 R HR Core Service 管理員否認執行薪資調整操作 管理員調整薪資後聲稱未進行此操作 THR-004 I PostgreSQL 員工個資大量外洩 SQL Injection 或未加密備份遭竊 THR-005 D API Gateway DDoS 癱瘓打卡/請假功能 攻擊者以大量請求衝擊 API Gateway THR-006 E Auth Service 一般員工提升至 Admin 權限 利用 IDOR 漏洞修改角色欄位 THR-007 I Redis Cache Session 資料從快取洩露 未加密的 Redis 連線被中間人竊聽 THR-008 S Active Directory 暴力破解 AD 帳號密碼 對 LDAP 認證端點進行字典攻擊 6. 威脅風險評估 📝 範本 風險評分標準（DREAD 或自訂） 評分維度 1（低） 2（中） 3（高） 影響程度（Impact） 非敏感資料 部分敏感資料 核心/大量敏感資料 發生可能性（Likelihood） 需高階技術+內部存取 中等技術+外部存取 低門檻+自動化工具 可利用性（Exploitability） 無公開漏洞 有概念驗證 有公開利用工具 風險評估結果 威脅 ID 影響 可能性 可利用性 總分 風險等級 THR-{xxx} {1-3} {1-3} {1-3} {N} 高/中/低 📖 使用說明 風險等級 = 影響 × 可能性 × 可利用性（或加總取平均） 高風險（7-9分）：必須在上線前處置 中風險（4-6分）：計畫性處理，可接受短期風險 低風險（1-3分）：記錄並持續監控 風險評估結果決定緩解措施的優先順序 💡 範例 威脅 ID 影響 可能性 可利用性 總分 風險等級 THR-001 3 2 2 7 高 THR-002 3 1 1 5 中 THR-003 2 2 3 7 高 THR-004 3 2 3 8 高 THR-005 2 3 3 8 高 THR-006 3 2 2 7 高 THR-007 2 1 2 5 中 THR-008 3 2 3 8 高 7. 緩解措施 📝 範本 威脅 ID 緩解措施 對應安全需求 實作方式 負責人 狀態 THR-{xxx} {緩解描述} SEC-{xxx} {技術/流程手段} {人員} 未開始/進行中/完成 📖 使用說明 每個高/中風險威脅都需要對應的緩解措施 緩解策略分為四種： 消除：重新設計，完全移除威脅（最佳） 緩解：降低影響或可能性（最常見） 轉移：轉移風險給第三方（保險/外包） 接受：記錄風險，不處理（需管理層核准） 緩解措施需連結到安全需求清單（SecurityRequirements）中的具體需求 💡 範例 威脅 ID 緩解措施 對應安全需求 實作方式 負責人 狀態 THR-001 使用 RS256 非對稱簽章 + 短效 Token SEC-AUTH-006 JWT RS256 + 15min Expiry 後端組 完成 THR-003 所有薪資操作記錄不可竄改稽核日誌 SEC-LOG-001, SEC-LOG-004 Append-only audit log + 時間戳簽章 後端組 進行中 THR-004 個資欄位加密 + 參數化查詢 + WAF SEC-DATA-001, SEC-INPUT-002 AES-256 + EF Core parameterized + ModSecurity 全端 完成 THR-005 API Rate Limiting + CDN + Auto-scaling SEC-INPUT-005 Kong rate-limit plugin (100 req/min) + Azure CDN DevOps 完成 THR-006 伺服器端角色驗證 + 單元測試覆蓋 SEC-AUTHZ-001, SEC-AUTHZ-003 [Authorize(Roles=\u0026ldquo;Admin\u0026rdquo;)] + IDOR 防護 後端組 完成 THR-008 帳號鎖定 + MFA + IP 白名單 SEC-AUTH-002, SEC-AUTH-003 AD 帳號鎖定策略 + Azure MFA IT 維運 進行中 8. 殘餘風險 📝 範本 威脅 ID 殘餘風險描述 緩解後風險等級 接受理由 核准者 核准日期 THR-{xxx} {緩解後仍存在的風險} 高/中/低 {為何可接受} {管理層} {日期} 📖 使用說明 殘餘風險 = 實施緩解措施後仍無法完全消除的風險 所有殘餘風險需經管理層正式核准（Risk Acceptance） 殘餘風險需定期重新評估（至少每季度） 高殘餘風險應有補償性控制措施 💡 範例 威脅 ID 殘餘風險描述 緩解後風險等級 接受理由 核准者 核准日期 THR-005 DDoS 超過 CDN 容量時仍可能影響可用性 低 CDN 已可承受 99% 場景，剩餘機率極低 CTO 2026-05-15 THR-007 Redis 若被直接存取仍可讀取 Session 低 Redis 位於 VPC 內網，無外部可達性 資安主管 2026-05-15 9. 威脅追溯矩陣 📝 範本 威脅 ID DFD 元素 信任邊界 安全需求 緩解措施 測試案例 THR-{xxx} {元件} TB-{xxx} SEC-{xxx} {緩解} TC-{xxx} 📖 使用說明 追溯矩陣確保每個威脅都能向前追溯到架構元素、向後追溯到測試案例 完整鏈路：DFD 元素 → 信任邊界 → 威脅 → 安全需求 → 緩解措施 → 測試驗證 若某威脅沒有對應的測試案例，代表測試覆蓋不足 💡 範例 威脅 ID DFD 元素 信任邊界 安全需求 緩解措施 測試案例 THR-001 API Gateway TB-001 SEC-AUTH-006 RS256 + 短效 Token TC-SEC-001: Token 偽造測試 THR-004 PostgreSQL TB-003 SEC-DATA-001, SEC-INPUT-002 加密 + 參數化查詢 TC-SEC-004: SQL Injection Pen Test THR-005 API Gateway TB-001 SEC-INPUT-005 Rate Limiting TC-SEC-005: 壓力測試 + DDoS 模擬 THR-006 Auth Service TB-002 SEC-AUTHZ-001 伺服器端授權 TC-SEC-006: IDOR 測試 10. 附錄 📝 範本 10.1 威脅建模會議記錄 日期 參與者 討論主題 決議 {日期} {姓名,角色} {主題} {決議} 10.2 參考資料 資源 用途 OWASP Threat Modeling Cheat Sheet 威脅建模方法論參考 Microsoft STRIDE per Element 每元素類型適用的 STRIDE 分析 OWASP ASVS 4.0.3 安全需求對照標準 ISO/IEC 27005:2022 風險評估方法論 📖 使用說明 會議記錄保留威脅建模決策的可追溯性 建議威脅模型每個 Sprint 或重大架構變更時更新 工具推薦：Microsoft Threat Modeling Tool (免費)、OWASP Threat Dragon (開源) 💡 範例 10.1 威脅建模會議記錄 日期 參與者 討論主題 決議 2026-04-10 張架構師, 李資安, 王開發 Level 1 DFD 繪製與邊界確認 TB-001~TB-004 確認 2026-04-12 張架構師, 李資安, 陳 QA STRIDE 分析（THR-001~008） 8 個威脅確認，6 個為高風險 2026-04-15 CTO, 資安主管, 張架構師 殘餘風險接受 THR-005, THR-007 殘餘風險核准接受 📌 範本使用注意事項\n","title":"威脅模型範本（Threat Model Template）"},{"content":"安全測試與弱點掃描報告範本（Security Scan Report Template） 適用標準：OWASP Testing Guide v4.2、CVSS 3.1（Common Vulnerability Scoring System）、CWE\n適用階段：測試驗證階段（Testing Phase）\n負責角色：AppSec 工程師、資安測試人員、QA Lead\n📑 章節目錄 文件資訊 測試摘要 測試範圍與方法 弱點總覽 弱點詳細報告 合規檢核結果 修復計畫 結論與建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全測試報告 文件編號 [專案代碼]-STR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試人員 [AppSec 團隊 / 外部廠商] 審核者 [CISO / 資安主管] 資料分級 Confidential 2. 測試摘要 項目 內容 測試類型 [SAST / DAST / SCA / Penetration Test / 組合] 受測版本 [Application version / Commit hash] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 上線決策 [可上線 / 修復後可上線 / 不可上線] 弱點統計 嚴重度 數量 已修復 待修復 接受風險 Critical [N] [N] [N] [N] High [N] [N] [N] [N] Medium [N] [N] [N] [N] Low [N] [N] [N] [N] Info [N] — — — Total [N] [N] [N] [N] 3. 測試範圍與方法 3.1 測試範圍 項目 內容 目標系統 [系統名稱 + URL/IP] 測試範圍 [In-scope modules / endpoints] 排除範圍 [Out-of-scope，如第三方元件] 認證帳號 [測試用帳號角色清單（不含密碼）] 3.2 測試方法 測試類型 工具 版本 說明 SAST（靜態分析） [SonarQube / Checkmarx / Semgrep] [ver] 原始碼分析 DAST（動態分析） [OWASP ZAP / Burp Suite Pro] [ver] 執行期掃描 SCA（套件分析） [Snyk / OWASP Dependency-Check / Trivy] [ver] 第三方套件弱點 手動測試 [Burp Suite / Custom scripts] — 邏輯弱點 Container Scan [Trivy / Aqua] [ver] 容器映像掃描 3.3 測試依據 標準/指南 涵蓋項目 OWASP Top 10 (2021) A01~A10 OWASP API Security Top 10 (2023) 全部 OWASP ASVS v4.0.3 [Level 1 / Level 2 / Level 3] CWE Top 25 (2023) 常見弱點 4. 弱點總覽 4.1 依嚴重度分佈 嚴重度 CVSS 分數範圍 修復 SLA 數量 Critical 9.0 – 10.0 24 小時 [N] High 7.0 – 8.9 7 天 [N] Medium 4.0 – 6.9 30 天 [N] Low 0.1 – 3.9 90 天 [N] Info 0.0 視需要 [N] 4.2 依類型分佈 弱點類型（CWE） 數量 嚴重度分佈 [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] 4.3 依 OWASP Top 10 分佈 OWASP Category 弱點數量 最高嚴重度 A01: Broken Access Control [N] [Critical/High/\u0026hellip;] A02: Cryptographic Failures [N] A03: Injection [N] A04: Insecure Design [N] A05: Security Misconfiguration [N] A06: Vulnerable Components [N] A07: Auth Failures [N] A08: Software \u0026amp; Data Integrity [N] A09: Logging \u0026amp; Monitoring Failures [N] A10: SSRF [N] 5. 弱點詳細報告 VULN-[NNN]: [弱點標題] 項目 內容 弱點 ID VULN-[NNN] 嚴重度 [Critical / High / Medium / Low] CVSS 分數 [N.N] CVSS Vector [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] CWE CWE-[NNN]: [名稱] OWASP [A01 / A02 / \u0026hellip;] 發現工具 [SAST / DAST / Manual] 受影響元件 [模組/檔案/API endpoint] 狀態 [Open / Fixed / Accepted / False Positive] 描述：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/testing/securityscanreport_template/","summary":"安全測試與弱點掃描報告範本（Security Scan Report Template） 適用標準：OWASP Testing Guide v4.2、CVSS 3.1（Common Vulnerability Scoring System）、CWE\n適用階段：測試驗證階段（Testing Phase）\n負責角色：AppSec 工程師、資安測試人員、QA Lead\n📑 章節目錄 文件資訊 測試摘要 測試範圍與方法 弱點總覽 弱點詳細報告 合規檢核結果 修復計畫 結論與建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全測試報告 文件編號 [專案代碼]-STR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試人員 [AppSec 團隊 / 外部廠商] 審核者 [CISO / 資安主管] 資料分級 Confidential 2. 測試摘要 項目 內容 測試類型 [SAST / DAST / SCA / Penetration Test / 組合] 受測版本 [Application version / Commit hash] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 上線決策 [可上線 / 修復後可上線 / 不可上線] 弱點統計 嚴重度 數量 已修復 待修復 接受風險 Critical [N] [N] [N] [N] High [N] [N] [N] [N] Medium [N] [N] [N] [N] Low [N] [N] [N] [N] Info [N] — — — Total [N] [N] [N] [N] 3. 測試範圍與方法 3.1 測試範圍 項目 內容 目標系統 [系統名稱 + URL/IP] 測試範圍 [In-scope modules / endpoints] 排除範圍 [Out-of-scope，如第三方元件] 認證帳號 [測試用帳號角色清單（不含密碼）] 3.2 測試方法 測試類型 工具 版本 說明 SAST（靜態分析） [SonarQube / Checkmarx / Semgrep] [ver] 原始碼分析 DAST（動態分析） [OWASP ZAP / Burp Suite Pro] [ver] 執行期掃描 SCA（套件分析） [Snyk / OWASP Dependency-Check / Trivy] [ver] 第三方套件弱點 手動測試 [Burp Suite / Custom scripts] — 邏輯弱點 Container Scan [Trivy / Aqua] [ver] 容器映像掃描 3.3 測試依據 標準/指南 涵蓋項目 OWASP Top 10 (2021) A01~A10 OWASP API Security Top 10 (2023) 全部 OWASP ASVS v4.0.3 [Level 1 / Level 2 / Level 3] CWE Top 25 (2023) 常見弱點 4. 弱點總覽 4.1 依嚴重度分佈 嚴重度 CVSS 分數範圍 修復 SLA 數量 Critical 9.0 – 10.0 24 小時 [N] High 7.0 – 8.9 7 天 [N] Medium 4.0 – 6.9 30 天 [N] Low 0.1 – 3.9 90 天 [N] Info 0.0 視需要 [N] 4.2 依類型分佈 弱點類型（CWE） 數量 嚴重度分佈 [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] 4.3 依 OWASP Top 10 分佈 OWASP Category 弱點數量 最高嚴重度 A01: Broken Access Control [N] [Critical/High/\u0026hellip;] A02: Cryptographic Failures [N] A03: Injection [N] A04: Insecure Design [N] A05: Security Misconfiguration [N] A06: Vulnerable Components [N] A07: Auth Failures [N] A08: Software \u0026amp; Data Integrity [N] A09: Logging \u0026amp; Monitoring Failures [N] A10: SSRF [N] 5. 弱點詳細報告 VULN-[NNN]: [弱點標題] 項目 內容 弱點 ID VULN-[NNN] 嚴重度 [Critical / High / Medium / Low] CVSS 分數 [N.N] CVSS Vector [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] CWE CWE-[NNN]: [名稱] OWASP [A01 / A02 / \u0026hellip;] 發現工具 [SAST / DAST / Manual] 受影響元件 [模組/檔案/API endpoint] 狀態 [Open / Fixed / Accepted / False Positive] 描述：\n","title":"安全測試與弱點掃描報告範本（Security Scan Report Template）"},{"content":"安全設計文件範本（Security Design Document Template） 適用標準：OWASP SAMM 2.0、ISO/IEC 27034（應用安全）、NIST SP 800-53、ISO/IEC 27001:2022\n適用階段：系統設計階段（Design Phase）\n負責角色：資安架構師、系統架構師（SA）、AppSec 工程師\n📑 章節目錄 文件資訊 安全設計目標 身分驗證設計（Authentication） 授權與存取控制（Authorization） 資料保護設計 API 安全設計 Session 管理 輸入驗證與輸出編碼 日誌與稽核設計 安全組態基線 安全測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全設計文件 文件編號 [專案代碼]-SDD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [資安架構師] 審核者 [CISO / 資安團隊] 資料分級 [Confidential / Internal] 關聯文件 文件 關係 威脅模型（Threat Model） 風險識別來源 安全需求清單 需求依據 系統架構文件（SAD） 架構背景 2. 安全設計目標 2.1 安全原則 原則 說明 實施方式 Defense in Depth 多層防禦 [每層防護機制] Least Privilege 最小權限 [RBAC + 預設拒絕] Fail Secure 安全失敗 [錯誤處理不暴露資訊] Separation of Duties 職責分離 [設計/部署/維運分離] Zero Trust 零信任 [每次存取都驗證] 2.2 合規需求 法規/標準 適用條款 設計對應 [個資法 / GDPR] [條款] [§5 資料保護] [ISO 27001] [A.8 / A.9] [§3, §4] [OWASP Top 10] [全部] [§6, §8] [PCI DSS] [條款，如適用] [§5] 3. 身分驗證設計（Authentication） 3.1 驗證機制 項目 設計 驗證協定 [OAuth 2.0 + OIDC / SAML 2.0 / Custom] IdP 選擇 [Azure AD / Keycloak / Auth0 / 自建] MFA 策略 [強制 / 條件式 / 僅特權帳號] MFA 方式 [TOTP / SMS / Push / FIDO2] 密碼政策 [長度/複雜度/歷史/鎖定策略] 3.2 密碼儲存 項目 設計 Hash 演算法 [bcrypt / Argon2id / PBKDF2] Cost Factor [rounds / iterations] Salt [Per-user random salt] 3.3 Token 設計 Token 類型 格式 有效期 儲存位置 備註 Access Token [JWT / Opaque] [N min] [Memory / HttpOnly Cookie] Refresh Token [Opaque] [N days] [HttpOnly Secure Cookie] 單次使用 ID Token [JWT] [N min] [Memory] 不傳給後端 API 3.4 驗證流程圖 sequenceDiagram participant U as User participant C as Client App participant IDP as Identity Provider participant API as API Server U-\u0026gt;\u0026gt;C: 點擊登入 C-\u0026gt;\u0026gt;IDP: Authorization Request (PKCE) IDP-\u0026gt;\u0026gt;U: 顯示登入頁面 U-\u0026gt;\u0026gt;IDP: 輸入帳號/密碼 \u0026#43; MFA IDP-\u0026gt;\u0026gt;C: Authorization Code C-\u0026gt;\u0026gt;IDP: Token Exchange (code \u0026#43; code_verifier) IDP-\u0026gt;\u0026gt;C: Access Token \u0026#43; Refresh Token \u0026#43; ID Token C-\u0026gt;\u0026gt;API: API Request \u0026#43; Access Token (Bearer) API-\u0026gt;\u0026gt;API: Validate Token (signature \u0026#43; claims) API-\u0026gt;\u0026gt;C: Response 4. 授權與存取控制（Authorization） 4.1 存取控制模型 項目 設計 模型 [RBAC / ABAC / ReBAC / 混合] 角色層級 [平面 / 階層式] 權限粒度 [功能級 / 資料級 / 欄位級] 4.2 角色定義 角色 ID 角色名稱 說明 預設權限 [ROLE_ID] [名稱] [角色描述] [權限摘要] 4.3 權限矩陣 功能/資源 [角色A] [角色B] [角色C] [Admin] [功能1] R CRUD R CRUD [功能2] — R CRUD CRUD [功能3] RU (own) RU (dept) CRUD CRUD 4.4 資料級權限 規則 描述 實施方式 Row-Level Security [使用者只能看自己的資料] [DB RLS / Application Filter] Column-Level Security [敏感欄位依角色遮罩] [View / API 過濾] 部門隔離 [只能存取所屬部門資料] [tenant_id / dept_id filter] 5. 資料保護設計 5.1 加密策略 場景 方法 演算法 金鑰管理 傳輸中（In Transit） TLS [TLS 1.3 / 1.2] [憑證管理方式] 靜態儲存（At Rest） [TDE / Application-level] [AES-256-GCM] [KMS / Vault] 欄位加密 Application-level [AES-256-GCM] [KMS / Vault] 備份加密 File-level [AES-256] [KMS] 5.2 金鑰管理 項目 設計 KMS 工具 [AWS KMS / Azure Key Vault / HashiCorp Vault] 金鑰輪換 [每 N 天自動輪換] 金鑰存取控制 [IAM Policy / RBAC] 金鑰備份 [異地備份策略] 5.3 個資處理 個資欄位 蒐集目的 保留期限 匿名化方式 刪除策略 [欄位] [用途] [N 年] [Masking / Hashing / Tokenization] [Hard delete / Crypto-shred] 6. API 安全設計 6.1 API 認證授權 項目 設計 認證方式 [Bearer Token (JWT) / API Key / mTLS] 授權檢查點 [API Gateway / Application / Both] Scope/Permission [resource:action 格式] 6.2 API 防護 防護措施 設計 工具 Rate Limiting [N requests / minute per user] [API Gateway / Redis] Request Size Limit [N MB] [Nginx / Gateway] IP Whitelist（如適用） [特定 API 限制來源 IP] [WAF / NSG] CORS [Allowed origins 清單] [Application config] API Versioning [URL path / Header] [設計規範] 6.3 OWASP API Security Top 10 對策 風險 對策 Broken Object Level Authorization [每次存取驗證資源所有權] Broken Authentication [Token 正確驗證 + MFA] Broken Object Property Level Authorization [回應過濾敏感欄位] Unrestricted Resource Consumption [Rate limit + pagination] Broken Function Level Authorization [角色權限矩陣嚴格檢查] Server Side Request Forgery [禁止 URL 參數直接存取內部資源] Security Misconfiguration [安全組態基線檢核] Lack of Protection from Automated Threats [Bot detection + CAPTCHA] 7. Session 管理 項目 設計 Session 機制 [Stateless (JWT) / Stateful (Server-side)] Session 有效期 [Idle: N min / Absolute: N hr] Session 儲存 [Redis / Database / Memory] Cookie 設定 HttpOnly, Secure, SameSite=Strict, Path=/ 並行 Session [允許 N 個裝置 / 新登入踢出舊 Session] Session Fixation 防護 [登入後重新產生 Session ID] 登出機制 [清除 Token + Server-side invalidation] 8. 輸入驗證與輸出編碼 8.1 輸入驗證策略 驗證層 位置 方式 Client-side 前端 UI 即時驗證（UX 用途，非安全邊界） Server-side API Controller 必須：Whitelist 驗證 + Schema validation Database DB Layer 型別約束 + Check constraints 8.2 常見攻擊防護 攻擊類型 防護措施 SQL Injection Parameterized queries / ORM XSS Output encoding (context-aware) + CSP CSRF SameSite cookie + CSRF token (if needed) Path Traversal 白名單驗證路徑，禁止 ../ XXE 停用 external entity parsing Deserialization 不接受不信任的序列化資料 8.3 Content Security Policy Content-Security-Policy: default-src \u0026#39;self\u0026#39;; script-src \u0026#39;self\u0026#39; [trusted CDN]; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; img-src \u0026#39;self\u0026#39; data: [image CDN]; connect-src \u0026#39;self\u0026#39; [API domain]; frame-ancestors \u0026#39;none\u0026#39;; base-uri \u0026#39;self\u0026#39;; form-action \u0026#39;self\u0026#39;; 9. 日誌與稽核設計 9.1 安全事件日誌 事件類型 記錄內容 儲存位置 保留期 登入成功/失敗 UserID, IP, Timestamp, UserAgent [SIEM / Log store] [N 年] 權限變更 Who, What, When, Previous/New value [Audit DB] [N 年] 資料存取 UserID, Resource, Action, Timestamp [Audit DB] [N 年] 敏感操作 [詳細描述] [Audit DB] [N 年] 9.2 日誌安全 項目 設計 日誌不得包含 密碼、Token、PII 明碼、信用卡號 日誌完整性 [HMAC / Append-only storage] 日誌存取控制 [僅 Security Team + Auditor 可存取] 竄改偵測 [Hash chain / WORM storage] 10. 安全組態基線 10.1 HTTP Security Headers Header 值 說明 Strict-Transport-Security max-age=31536000; includeSubDomains HSTS X-Content-Type-Options nosniff 防 MIME 嗅探 X-Frame-Options DENY 防 Clickjacking X-XSS-Protection 0 由 CSP 取代 Referrer-Policy strict-origin-when-cross-origin Permissions-Policy camera=(), microphone=() 限制瀏覽器功能 10.2 TLS 組態 項目 設計 最低版本 TLS 1.2（建議 TLS 1.3） 允許 Cipher Suites [列出安全的 cipher suites] 憑證類型 [RSA 2048+ / ECDSA P-256+] HSTS Preload [是/否] 11. 安全測試策略 測試類型 工具 頻率 負責人 SAST [SonarQube / Checkmarx / Semgrep] 每次 CI build Dev Team DAST [OWASP ZAP / Burp Suite] 每個 Sprint AppSec SCA [Snyk / Dependabot / OWASP Dep-Check] 每次 CI build Dev Team Penetration Test [外部廠商] [每年/每版本] AppSec Security Review Code Review + Design Review 每個 PR + 每階段 AppSec + Dev 📖 使用說明 各章節填寫指引 章節 填寫時機 負責人 重點說明 §2 安全目標 專案啟動時 資安 對齊合規需求 §3 身分驗證 設計初期 SA/資安 從威脅模型導出需求 §4 授權控制 配合功能設計 SA 權限矩陣需業務確認 §5 資料保護 設計階段 SA/DBA/資安 PII 處理需法務確認 §6 API 安全 API 設計時 SA/FE/BE 配合 API Spec §7-8 Session/驗證 詳細設計 BE 遵循 OWASP 建議 §9 稽核 設計階段 SA/資安 法規保留需求 §10 組態基線 部署前 DevOps/資安 定期掃描驗證 §11 測試策略 開發啟動前 資安/QA 整合至 CI/CD 💡 範例（以 HRMS 人力資源管理系統為例） 範例：角色與權限矩陣 功能 員工 主管 HR 系統管理員 查看個人資料 R (own) R (dept) R (all) R (all) 編輯個人資料 U (partial) — U (all) U (all) 申請請假 CRU (own) CRU (own) CRUD (all) CRUD (all) 審核請假 — U (dept) U (all) U (all) 查看薪資 R (own) — R (all) R (all) 管理員工 — — CRUD CRUD 系統設定 — — — CRUD 範例：API 安全設計 API Endpoint 認證 授權 Rate Limit 備註 POST /auth/login Public — 5/min per IP 防暴力破解 GET /api/employees/{id} Bearer JWT own or dept_manager or HR 100/min Row-level check POST /api/leave-requests Bearer JWT Employee role 10/min PUT /api/leave-requests/{id}/approve Bearer JWT Manager of requestor 30/min 層級驗證 GET /api/salary/{id} Bearer JWT own or HR 20/min 敏感資料加密回傳 DELETE /api/employees/{id} Bearer JWT Admin only 5/min Soft delete + 稽核 範例：稽核日誌設計 { \u0026#34;timestamp\u0026#34;: \u0026#34;2026-04-10T08:30:15.123Z\u0026#34;, \u0026#34;event_type\u0026#34;: \u0026#34;DATA_ACCESS\u0026#34;, \u0026#34;user_id\u0026#34;: \u0026#34;EMP-001\u0026#34;, \u0026#34;user_role\u0026#34;: \u0026#34;HR\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;VIEW\u0026#34;, \u0026#34;resource\u0026#34;: \u0026#34;employee.salary\u0026#34;, \u0026#34;resource_id\u0026#34;: \u0026#34;EMP-042\u0026#34;, \u0026#34;source_ip\u0026#34;: \u0026#34;10.0.10.45\u0026#34;, \u0026#34;user_agent\u0026#34;: \u0026#34;Mozilla/5.0...\u0026#34;, \u0026#34;result\u0026#34;: \u0026#34;SUCCESS\u0026#34;, \u0026#34;metadata\u0026#34;: { \u0026#34;fields_accessed\u0026#34;: [\u0026#34;base_salary\u0026#34;, \u0026#34;bonus\u0026#34;], \u0026#34;reason\u0026#34;: \u0026#34;Monthly payroll processing\u0026#34; } } 📌 審閱重點\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/securitydesign_template/","summary":"安全設計文件範本（Security Design Document Template） 適用標準：OWASP SAMM 2.0、ISO/IEC 27034（應用安全）、NIST SP 800-53、ISO/IEC 27001:2022\n適用階段：系統設計階段（Design Phase）\n負責角色：資安架構師、系統架構師（SA）、AppSec 工程師\n📑 章節目錄 文件資訊 安全設計目標 身分驗證設計（Authentication） 授權與存取控制（Authorization） 資料保護設計 API 安全設計 Session 管理 輸入驗證與輸出編碼 日誌與稽核設計 安全組態基線 安全測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全設計文件 文件編號 [專案代碼]-SDD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [資安架構師] 審核者 [CISO / 資安團隊] 資料分級 [Confidential / Internal] 關聯文件 文件 關係 威脅模型（Threat Model） 風險識別來源 安全需求清單 需求依據 系統架構文件（SAD） 架構背景 2. 安全設計目標 2.1 安全原則 原則 說明 實施方式 Defense in Depth 多層防禦 [每層防護機制] Least Privilege 最小權限 [RBAC + 預設拒絕] Fail Secure 安全失敗 [錯誤處理不暴露資訊] Separation of Duties 職責分離 [設計/部署/維運分離] Zero Trust 零信任 [每次存取都驗證] 2.2 合規需求 法規/標準 適用條款 設計對應 [個資法 / GDPR] [條款] [§5 資料保護] [ISO 27001] [A.8 / A.9] [§3, §4] [OWASP Top 10] [全部] [§6, §8] [PCI DSS] [條款，如適用] [§5] 3. 身分驗證設計（Authentication） 3.1 驗證機制 項目 設計 驗證協定 [OAuth 2.0 + OIDC / SAML 2.0 / Custom] IdP 選擇 [Azure AD / Keycloak / Auth0 / 自建] MFA 策略 [強制 / 條件式 / 僅特權帳號] MFA 方式 [TOTP / SMS / Push / FIDO2] 密碼政策 [長度/複雜度/歷史/鎖定策略] 3.2 密碼儲存 項目 設計 Hash 演算法 [bcrypt / Argon2id / PBKDF2] Cost Factor [rounds / iterations] Salt [Per-user random salt] 3.3 Token 設計 Token 類型 格式 有效期 儲存位置 備註 Access Token [JWT / Opaque] [N min] [Memory / HttpOnly Cookie] Refresh Token [Opaque] [N days] [HttpOnly Secure Cookie] 單次使用 ID Token [JWT] [N min] [Memory] 不傳給後端 API 3.4 驗證流程圖 sequenceDiagram participant U as User participant C as Client App participant IDP as Identity Provider participant API as API Server U-\u0026gt;\u0026gt;C: 點擊登入 C-\u0026gt;\u0026gt;IDP: Authorization Request (PKCE) IDP-\u0026gt;\u0026gt;U: 顯示登入頁面 U-\u0026gt;\u0026gt;IDP: 輸入帳號/密碼 \u0026#43; MFA IDP-\u0026gt;\u0026gt;C: Authorization Code C-\u0026gt;\u0026gt;IDP: Token Exchange (code \u0026#43; code_verifier) IDP-\u0026gt;\u0026gt;C: Access Token \u0026#43; Refresh Token \u0026#43; ID Token C-\u0026gt;\u0026gt;API: API Request \u0026#43; Access Token (Bearer) API-\u0026gt;\u0026gt;API: Validate Token (signature \u0026#43; claims) API-\u0026gt;\u0026gt;C: Response 4. 授權與存取控制（Authorization） 4.1 存取控制模型 項目 設計 模型 [RBAC / ABAC / ReBAC / 混合] 角色層級 [平面 / 階層式] 權限粒度 [功能級 / 資料級 / 欄位級] 4.2 角色定義 角色 ID 角色名稱 說明 預設權限 [ROLE_ID] [名稱] [角色描述] [權限摘要] 4.3 權限矩陣 功能/資源 [角色A] [角色B] [角色C] [Admin] [功能1] R CRUD R CRUD [功能2] — R CRUD CRUD [功能3] RU (own) RU (dept) CRUD CRUD 4.4 資料級權限 規則 描述 實施方式 Row-Level Security [使用者只能看自己的資料] [DB RLS / Application Filter] Column-Level Security [敏感欄位依角色遮罩] [View / API 過濾] 部門隔離 [只能存取所屬部門資料] [tenant_id / dept_id filter] 5. 資料保護設計 5.1 加密策略 場景 方法 演算法 金鑰管理 傳輸中（In Transit） TLS [TLS 1.3 / 1.2] [憑證管理方式] 靜態儲存（At Rest） [TDE / Application-level] [AES-256-GCM] [KMS / Vault] 欄位加密 Application-level [AES-256-GCM] [KMS / Vault] 備份加密 File-level [AES-256] [KMS] 5.2 金鑰管理 項目 設計 KMS 工具 [AWS KMS / Azure Key Vault / HashiCorp Vault] 金鑰輪換 [每 N 天自動輪換] 金鑰存取控制 [IAM Policy / RBAC] 金鑰備份 [異地備份策略] 5.3 個資處理 個資欄位 蒐集目的 保留期限 匿名化方式 刪除策略 [欄位] [用途] [N 年] [Masking / Hashing / Tokenization] [Hard delete / Crypto-shred] 6. API 安全設計 6.1 API 認證授權 項目 設計 認證方式 [Bearer Token (JWT) / API Key / mTLS] 授權檢查點 [API Gateway / Application / Both] Scope/Permission [resource:action 格式] 6.2 API 防護 防護措施 設計 工具 Rate Limiting [N requests / minute per user] [API Gateway / Redis] Request Size Limit [N MB] [Nginx / Gateway] IP Whitelist（如適用） [特定 API 限制來源 IP] [WAF / NSG] CORS [Allowed origins 清單] [Application config] API Versioning [URL path / Header] [設計規範] 6.3 OWASP API Security Top 10 對策 風險 對策 Broken Object Level Authorization [每次存取驗證資源所有權] Broken Authentication [Token 正確驗證 + MFA] Broken Object Property Level Authorization [回應過濾敏感欄位] Unrestricted Resource Consumption [Rate limit + pagination] Broken Function Level Authorization [角色權限矩陣嚴格檢查] Server Side Request Forgery [禁止 URL 參數直接存取內部資源] Security Misconfiguration [安全組態基線檢核] Lack of Protection from Automated Threats [Bot detection + CAPTCHA] 7. Session 管理 項目 設計 Session 機制 [Stateless (JWT) / Stateful (Server-side)] Session 有效期 [Idle: N min / Absolute: N hr] Session 儲存 [Redis / Database / Memory] Cookie 設定 HttpOnly, Secure, SameSite=Strict, Path=/ 並行 Session [允許 N 個裝置 / 新登入踢出舊 Session] Session Fixation 防護 [登入後重新產生 Session ID] 登出機制 [清除 Token + Server-side invalidation] 8. 輸入驗證與輸出編碼 8.1 輸入驗證策略 驗證層 位置 方式 Client-side 前端 UI 即時驗證（UX 用途，非安全邊界） Server-side API Controller 必須：Whitelist 驗證 + Schema validation Database DB Layer 型別約束 + Check constraints 8.2 常見攻擊防護 攻擊類型 防護措施 SQL Injection Parameterized queries / ORM XSS Output encoding (context-aware) + CSP CSRF SameSite cookie + CSRF token (if needed) Path Traversal 白名單驗證路徑，禁止 ../ XXE 停用 external entity parsing Deserialization 不接受不信任的序列化資料 8.3 Content Security Policy Content-Security-Policy: default-src \u0026#39;self\u0026#39;; script-src \u0026#39;self\u0026#39; [trusted CDN]; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; img-src \u0026#39;self\u0026#39; data: [image CDN]; connect-src \u0026#39;self\u0026#39; [API domain]; frame-ancestors \u0026#39;none\u0026#39;; base-uri \u0026#39;self\u0026#39;; form-action \u0026#39;self\u0026#39;; 9. 日誌與稽核設計 9.1 安全事件日誌 事件類型 記錄內容 儲存位置 保留期 登入成功/失敗 UserID, IP, Timestamp, UserAgent [SIEM / Log store] [N 年] 權限變更 Who, What, When, Previous/New value [Audit DB] [N 年] 資料存取 UserID, Resource, Action, Timestamp [Audit DB] [N 年] 敏感操作 [詳細描述] [Audit DB] [N 年] 9.2 日誌安全 項目 設計 日誌不得包含 密碼、Token、PII 明碼、信用卡號 日誌完整性 [HMAC / Append-only storage] 日誌存取控制 [僅 Security Team + Auditor 可存取] 竄改偵測 [Hash chain / WORM storage] 10. 安全組態基線 10.1 HTTP Security Headers Header 值 說明 Strict-Transport-Security max-age=31536000; includeSubDomains HSTS X-Content-Type-Options nosniff 防 MIME 嗅探 X-Frame-Options DENY 防 Clickjacking X-XSS-Protection 0 由 CSP 取代 Referrer-Policy strict-origin-when-cross-origin Permissions-Policy camera=(), microphone=() 限制瀏覽器功能 10.2 TLS 組態 項目 設計 最低版本 TLS 1.2（建議 TLS 1.3） 允許 Cipher Suites [列出安全的 cipher suites] 憑證類型 [RSA 2048+ / ECDSA P-256+] HSTS Preload [是/否] 11. 安全測試策略 測試類型 工具 頻率 負責人 SAST [SonarQube / Checkmarx / Semgrep] 每次 CI build Dev Team DAST [OWASP ZAP / Burp Suite] 每個 Sprint AppSec SCA [Snyk / Dependabot / OWASP Dep-Check] 每次 CI build Dev Team Penetration Test [外部廠商] [每年/每版本] AppSec Security Review Code Review + Design Review 每個 PR + 每階段 AppSec + Dev 📖 使用說明 各章節填寫指引 章節 填寫時機 負責人 重點說明 §2 安全目標 專案啟動時 資安 對齊合規需求 §3 身分驗證 設計初期 SA/資安 從威脅模型導出需求 §4 授權控制 配合功能設計 SA 權限矩陣需業務確認 §5 資料保護 設計階段 SA/DBA/資安 PII 處理需法務確認 §6 API 安全 API 設計時 SA/FE/BE 配合 API Spec §7-8 Session/驗證 詳細設計 BE 遵循 OWASP 建議 §9 稽核 設計階段 SA/資安 法規保留需求 §10 組態基線 部署前 DevOps/資安 定期掃描驗證 §11 測試策略 開發啟動前 資安/QA 整合至 CI/CD 💡 範例（以 HRMS 人力資源管理系統為例） 範例：角色與權限矩陣 功能 員工 主管 HR 系統管理員 查看個人資料 R (own) R (dept) R (all) R (all) 編輯個人資料 U (partial) — U (all) U (all) 申請請假 CRU (own) CRU (own) CRUD (all) CRUD (all) 審核請假 — U (dept) U (all) U (all) 查看薪資 R (own) — R (all) R (all) 管理員工 — — CRUD CRUD 系統設定 — — — CRUD 範例：API 安全設計 API Endpoint 認證 授權 Rate Limit 備註 POST /auth/login Public — 5/min per IP 防暴力破解 GET /api/employees/{id} Bearer JWT own or dept_manager or HR 100/min Row-level check POST /api/leave-requests Bearer JWT Employee role 10/min PUT /api/leave-requests/{id}/approve Bearer JWT Manager of requestor 30/min 層級驗證 GET /api/salary/{id} Bearer JWT own or HR 20/min 敏感資料加密回傳 DELETE /api/employees/{id} Bearer JWT Admin only 5/min Soft delete + 稽核 範例：稽核日誌設計 { \u0026#34;timestamp\u0026#34;: \u0026#34;2026-04-10T08:30:15.123Z\u0026#34;, \u0026#34;event_type\u0026#34;: \u0026#34;DATA_ACCESS\u0026#34;, \u0026#34;user_id\u0026#34;: \u0026#34;EMP-001\u0026#34;, \u0026#34;user_role\u0026#34;: \u0026#34;HR\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;VIEW\u0026#34;, \u0026#34;resource\u0026#34;: \u0026#34;employee.salary\u0026#34;, \u0026#34;resource_id\u0026#34;: \u0026#34;EMP-042\u0026#34;, \u0026#34;source_ip\u0026#34;: \u0026#34;10.0.10.45\u0026#34;, \u0026#34;user_agent\u0026#34;: \u0026#34;Mozilla/5.0...\u0026#34;, \u0026#34;result\u0026#34;: \u0026#34;SUCCESS\u0026#34;, \u0026#34;metadata\u0026#34;: { \u0026#34;fields_accessed\u0026#34;: [\u0026#34;base_salary\u0026#34;, \u0026#34;bonus\u0026#34;], \u0026#34;reason\u0026#34;: \u0026#34;Monthly payroll processing\u0026#34; } } 📌 審閱重點\n","title":"安全設計文件範本（Security Design Document Template）"},{"content":"安全需求清單範本（Security Requirements Checklist） 參照標準：OWASP ASVS 4.0.3（Application Security Verification Standard）/ ISO/IEC 27001:2022 Annex A\n文件用途：定義系統應滿足的安全需求，確保設計與開發階段納入安全考量\n適用階段：需求分析階段（Requirements Phase）— Security by Design\n📋 章節目錄 文件資訊 安全需求概述 認證需求 授權與存取控制 資料保護需求 輸入驗證與輸出編碼 Session 管理 日誌與監控需求 通訊安全 組態安全 合規性需求 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SR-{專案代碼}-{序號} 文件名稱 {系統名稱} 安全需求清單 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 撰寫者 {姓名/角色} 資安審核者 {資安人員姓名} ASVS Level Level 1 / Level 2 / Level 3 📖 使用說明 依據 OWASP ASVS 4.0.3 標準，安全需求分為三個驗證等級： Level 1：所有應用程式的最低標準 Level 2：處理敏感資料的應用程式 Level 3：最高安全等級（金融、醫療、關鍵基礎設施） 本清單在需求階段制定，貫穿整個 SDLC（設計需遵循、開發需實作、測試需驗證） 💡 範例 項目 內容 文件編號 SR-HRM-001 系統名稱 人力資源管理系統 ASVS Level Level 2（處理員工個資與薪資資料） 2. 安全需求概述 📝 範本 2.1 系統安全分類 項目 評估 資料敏感度 一般 / 敏感 / 高度敏感 系統曝露面 內部 / 外部 / 混合 使用者類型 內部員工 / 外部客戶 / 合作夥伴 法規要求 {適用法規} 安全等級 ASVS Level {1/2/3} 2.2 安全需求追溯矩陣 安全需求 ID 需求描述 ASVS 章節 對應 FRD 優先級 SEC-{xxx} {描述} V{x}.{x} FR-{xxx} 高/中/低 📖 使用說明 安全分類決定應套用的 ASVS Level 追溯矩陣確保每個安全需求可連結到 FRD 需求與 ASVS 標準章節 優先級考量：法規強制 \u0026gt; 高風險 \u0026gt; 一般防護 💡 範例 2.1 系統安全分類 項目 評估 資料敏感度 高度敏感（身分證字號、薪資、銀行帳號） 系統曝露面 混合（內部網路 + VPN 遠端存取） 使用者類型 內部員工（全體） + HR 管理人員 法規要求 個人資料保護法、勞動基準法 安全等級 ASVS Level 2 3. 認證需求（Authentication） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ SEC-AUTH-002 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V2（Authentication）章節 Level 1：基本密碼安全；Level 2：多因子認證（MFA）；Level 3：硬體認證 認證需求需涵蓋：密碼策略、帳號鎖定、MFA、SSO 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 密碼長度至少 12 字元 V2.1.1 L1 必須 ☑ SEC-AUTH-002 帳號連續 5 次登入失敗後鎖定 30 分鐘 V2.2.1 L1 必須 ☑ SEC-AUTH-003 管理員帳號啟用多因子認證（MFA） V2.8.1 L2 必須 ☑ SEC-AUTH-004 整合企業 AD 實現 SSO 登入 V2.7.1 L2 必須 ☑ SEC-AUTH-005 密碼不儲存明文，使用 bcrypt/Argon2 雜湊 V2.4.1 L1 必須 ☑ SEC-AUTH-006 Token 過期時間 ≤ 15 分鐘（Access Token） V2.8.5 L2 必須 ☐ 4. 授權與存取控制（Authorization） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 {授權需求描述} V4.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V4（Access Control）章節 遵循最小權限原則（Principle of Least Privilege） 需求涵蓋：RBAC/ABAC 模型、水平/垂直權限控制、API 授權 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 實施 RBAC 角色權限控制（Admin/Manager/Employee） V4.1.1 L1 必須 ☑ SEC-AUTHZ-002 使用者僅能存取自己的薪資/假勤資料（水平權限） V4.1.2 L1 必須 ☑ SEC-AUTHZ-003 API 端點實施授權檢查，拒絕未授權請求回傳 403 V4.1.3 L1 必須 ☑ SEC-AUTHZ-004 管理功能（帳號管理、系統設定）限 Admin 角色 V4.2.1 L1 必須 ☑ SEC-AUTHZ-005 所有權限變更需記錄稽核日誌 V4.3.1 L2 必須 ☐ 5. 資料保護需求（Data Protection） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-DATA-001 {資料保護需求描述} V6.{x}/V8.{x} L{N} 必須/建議 ☐ 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 {欄位} 高/中/低 {加密} {遮罩} {期限} 📖 使用說明 對應 OWASP ASVS V6（Stored Cryptography）與 V8（Data Protection） 敏感資料需先識別、再定義保護策略 保護措施包含：傳輸加密、靜態加密、資料遮罩、存取控制、保留/銷毀策略 💡 範例 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 身分證字號 高 AES-256 (靜態) A1234****9 離職後 5 年 銀行帳號 高 AES-256 (靜態) --1234 離職後 5 年 薪資金額 高 AES-256 (靜態) 不遮罩（權限控制） 永久 手機號碼 中 無（權限控制） 09xx-xxx-789 離職後 2 年 Email 低 無 無 離職後 2 年 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-DATA-001 個資欄位靜態加密儲存（AES-256） V6.2.1 L2 必須 SEC-DATA-002 所有傳輸使用 TLS 1.2+ V9.1.1 L1 必須 SEC-DATA-003 日誌中禁止記錄敏感資料明文 V8.3.1 L1 必須 SEC-DATA-004 資料庫備份亦需加密 V6.2.3 L2 必須 6. 輸入驗證與輸出編碼 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-INPUT-001 {輸入驗證需求} V5.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V5（Validation, Sanitization and Encoding） 防禦 OWASP Top 10 中的注入攻擊（SQL Injection、XSS、Command Injection） 原則：永不信任使用者輸入，伺服器端必須驗證 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-INPUT-001 所有使用者輸入在伺服器端進行驗證（白名單） V5.1.1 L1 必須 SEC-INPUT-002 使用參數化查詢防止 SQL Injection V5.3.4 L1 必須 SEC-INPUT-003 HTML 輸出使用 Context-Aware 編碼防止 XSS V5.3.3 L1 必須 SEC-INPUT-004 檔案上傳驗證副檔名、MIME Type、大小限制 V5.1.4 L1 必須 SEC-INPUT-005 API 輸入限制 Content-Length，防止 DoS V5.1.5 L1 必須 7. Session 管理 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-SESS-001 {Session 管理需求} V3.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V3（Session Management） Session 管理攸關身份劫持風險 需求涵蓋：Session ID 強度、過期設定、Cookie 安全屬性 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-SESS-001 Session ID 長度 ≥ 128 bits，由加密安全亂數產生 V3.2.1 L1 必須 SEC-SESS-002 Cookie 設定 HttpOnly、Secure、SameSite=Strict V3.4.1 L1 必須 SEC-SESS-003 閒置 30 分鐘後自動登出 V3.3.1 L1 必須 SEC-SESS-004 登入後重新產生 Session ID（防 Fixation） V3.2.3 L1 必須 SEC-SESS-005 支援使用者查看與終止其他裝置 Session V3.3.4 L2 建議 8. 日誌與監控需求 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-LOG-001 {日誌監控需求} V7.{x} L{N} 必須/建議 ☐ 稽核事件定義 事件類型 記錄內容 保留期限 {事件} {需記錄的欄位} {期限} 📖 使用說明 對應 OWASP ASVS V7（Error Handling and Logging） 日誌是事後追查與即時偵測的基礎 重點：記什麼、不記什麼（禁止記錄密碼/Token）、保存多久 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-LOG-001 記錄所有認證事件（登入成功/失敗/登出） V7.1.1 L1 必須 SEC-LOG-002 記錄所有授權失敗事件 V7.1.2 L1 必須 SEC-LOG-003 日誌中禁止包含 Session Token、密碼、個資 V7.1.3 L1 必須 SEC-LOG-004 日誌保留 ≥ 90 天，不可竄改 V7.3.1 L2 必須 SEC-LOG-005 連續 5 次認證失敗觸發即時告警 V7.4.1 L2 必須 稽核事件定義 事件類型 記錄內容 保留期限 登入成功 時間、帳號、IP、User-Agent 180 天 登入失敗 時間、帳號、IP、失敗原因 180 天 權限變更 時間、操作者、變更內容 365 天 個資存取 時間、帳號、存取的個資類型 365 天 資料匯出 時間、帳號、匯出範圍、筆數 365 天 9. 通訊安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-COMM-001 {通訊安全需求} V9.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V9（Communication） 保護傳輸中資料不被竊聽或竄改 涵蓋：TLS 版本、憑證管理、HSTS、內部通訊加密 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-COMM-001 所有外部通訊使用 TLS 1.2 以上 V9.1.1 L1 必須 SEC-COMM-002 啟用 HSTS（max-age ≥ 1 年） V9.1.2 L1 必須 SEC-COMM-003 伺服器憑證由受信任 CA 簽發 V9.2.1 L1 必須 SEC-COMM-004 服務間（微服務）通訊使用 mTLS V9.2.2 L2 建議 SEC-COMM-005 禁用 SSL 3.0、TLS 1.0/1.1 V9.1.3 L1 必須 10. 組態安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-CFG-001 {組態安全需求} V14.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V14（Configuration） 安全組態確保系統不因錯誤設定而暴露弱點 涵蓋：預設帳號、除錯模式、HTTP 安全標頭、依賴管理 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-CFG-001 正式環境禁止開啟除錯模式 / 詳細錯誤訊息 V14.1.1 L1 必須 SEC-CFG-002 移除或停用所有預設帳號與密碼 V14.1.2 L1 必須 SEC-CFG-003 設定安全 HTTP Headers（CSP, X-Frame-Options 等） V14.4.1 L1 必須 SEC-CFG-004 第三方依賴無已知 High/Critical CVE V14.2.1 L1 必須 SEC-CFG-005 機敏設定（DB 連線字串、API Key）使用 Secret Manager V14.1.5 L2 必須 11. 合規性需求 📝 範本 法規/標準 適用條款 系統需求對應 實作狀態 {法規名稱} {條款} {系統需滿足的具體需求} ☐ 📖 使用說明 列出系統需遵循的法規、產業標準、企業政策 每條法規要求需轉化為可驗證的技術需求 常見法規：個人資料保護法、GDPR、PCI DSS、ISO 27001 💡 範例 法規/標準 適用條款 系統需求對應 實作狀態 個人資料保護法 第 27 條（安全維護措施） 個資加密儲存、存取控制、稽核日誌 ☑ 個人資料保護法 第 11 條（當事人權利） 提供個資查詢、更正、刪除功能 ☑ ISO 27001:2022 A.8.3（存取控制） RBAC 實作 ☑ ISO 27001:2022 A.8.24（密碼學使用） TLS 1.2+、AES-256 加密 ☑ 公司資安政策 密碼政策 v3.0 12 字元 + 複雜度 + 90 天更換 ☐ 12. 附錄 📝 範本 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） {N} {N} {N} {%} 授權（AUTHZ） {N} {N} {N} {%} 資料保護（DATA） {N} {N} {N} {%} 輸入驗證（INPUT） {N} {N} {N} {%} Session（SESS） {N} {N} {N} {%} 日誌監控（LOG） {N} {N} {N} {%} 通訊安全（COMM） {N} {N} {N} {%} 組態安全（CFG） {N} {N} {N} {%} 合計 {N} {N} {N} {%} 12.2 OWASP ASVS 對照表 ASVS 章節 主題 本文件對應章節 V2 Authentication 第 3 章 V3 Session Management 第 7 章 V4 Access Control 第 4 章 V5 Validation 第 6 章 V6 Stored Cryptography 第 5 章 V7 Error Handling \u0026amp; Logging 第 8 章 V8 Data Protection 第 5 章 V9 Communication 第 9 章 V14 Configuration 第 10 章 📖 使用說明 完成度統計用於追蹤安全需求落實進度 所有「必須」等級的需求需在上線前 100% 實作 ASVS 對照表協助資安審核人員快速定位驗證範圍 💡 範例 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） 6 5 1 83% 授權（AUTHZ） 5 4 1 80% 資料保護（DATA） 4 4 0 100% 輸入驗證（INPUT） 5 5 0 100% Session（SESS） 5 4 1 80% 日誌監控（LOG） 5 3 2 60% 通訊安全（COMM） 5 5 0 100% 組態安全（CFG） 5 4 1 80% 合計 40 34 6 85% 📌 範本使用注意事項\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/securityrequirements_template/","summary":"安全需求清單範本（Security Requirements Checklist） 參照標準：OWASP ASVS 4.0.3（Application Security Verification Standard）/ ISO/IEC 27001:2022 Annex A\n文件用途：定義系統應滿足的安全需求，確保設計與開發階段納入安全考量\n適用階段：需求分析階段（Requirements Phase）— Security by Design\n📋 章節目錄 文件資訊 安全需求概述 認證需求 授權與存取控制 資料保護需求 輸入驗證與輸出編碼 Session 管理 日誌與監控需求 通訊安全 組態安全 合規性需求 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SR-{專案代碼}-{序號} 文件名稱 {系統名稱} 安全需求清單 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 撰寫者 {姓名/角色} 資安審核者 {資安人員姓名} ASVS Level Level 1 / Level 2 / Level 3 📖 使用說明 依據 OWASP ASVS 4.0.3 標準，安全需求分為三個驗證等級： Level 1：所有應用程式的最低標準 Level 2：處理敏感資料的應用程式 Level 3：最高安全等級（金融、醫療、關鍵基礎設施） 本清單在需求階段制定，貫穿整個 SDLC（設計需遵循、開發需實作、測試需驗證） 💡 範例 項目 內容 文件編號 SR-HRM-001 系統名稱 人力資源管理系統 ASVS Level Level 2（處理員工個資與薪資資料） 2. 安全需求概述 📝 範本 2.1 系統安全分類 項目 評估 資料敏感度 一般 / 敏感 / 高度敏感 系統曝露面 內部 / 外部 / 混合 使用者類型 內部員工 / 外部客戶 / 合作夥伴 法規要求 {適用法規} 安全等級 ASVS Level {1/2/3} 2.2 安全需求追溯矩陣 安全需求 ID 需求描述 ASVS 章節 對應 FRD 優先級 SEC-{xxx} {描述} V{x}.{x} FR-{xxx} 高/中/低 📖 使用說明 安全分類決定應套用的 ASVS Level 追溯矩陣確保每個安全需求可連結到 FRD 需求與 ASVS 標準章節 優先級考量：法規強制 \u0026gt; 高風險 \u0026gt; 一般防護 💡 範例 2.1 系統安全分類 項目 評估 資料敏感度 高度敏感（身分證字號、薪資、銀行帳號） 系統曝露面 混合（內部網路 + VPN 遠端存取） 使用者類型 內部員工（全體） + HR 管理人員 法規要求 個人資料保護法、勞動基準法 安全等級 ASVS Level 2 3. 認證需求（Authentication） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ SEC-AUTH-002 {認證需求描述} V2.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V2（Authentication）章節 Level 1：基本密碼安全；Level 2：多因子認證（MFA）；Level 3：硬體認證 認證需求需涵蓋：密碼策略、帳號鎖定、MFA、SSO 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTH-001 密碼長度至少 12 字元 V2.1.1 L1 必須 ☑ SEC-AUTH-002 帳號連續 5 次登入失敗後鎖定 30 分鐘 V2.2.1 L1 必須 ☑ SEC-AUTH-003 管理員帳號啟用多因子認證（MFA） V2.8.1 L2 必須 ☑ SEC-AUTH-004 整合企業 AD 實現 SSO 登入 V2.7.1 L2 必須 ☑ SEC-AUTH-005 密碼不儲存明文，使用 bcrypt/Argon2 雜湊 V2.4.1 L1 必須 ☑ SEC-AUTH-006 Token 過期時間 ≤ 15 分鐘（Access Token） V2.8.5 L2 必須 ☐ 4. 授權與存取控制（Authorization） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 {授權需求描述} V4.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V4（Access Control）章節 遵循最小權限原則（Principle of Least Privilege） 需求涵蓋：RBAC/ABAC 模型、水平/垂直權限控制、API 授權 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-AUTHZ-001 實施 RBAC 角色權限控制（Admin/Manager/Employee） V4.1.1 L1 必須 ☑ SEC-AUTHZ-002 使用者僅能存取自己的薪資/假勤資料（水平權限） V4.1.2 L1 必須 ☑ SEC-AUTHZ-003 API 端點實施授權檢查，拒絕未授權請求回傳 403 V4.1.3 L1 必須 ☑ SEC-AUTHZ-004 管理功能（帳號管理、系統設定）限 Admin 角色 V4.2.1 L1 必須 ☑ SEC-AUTHZ-005 所有權限變更需記錄稽核日誌 V4.3.1 L2 必須 ☐ 5. 資料保護需求（Data Protection） 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-DATA-001 {資料保護需求描述} V6.{x}/V8.{x} L{N} 必須/建議 ☐ 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 {欄位} 高/中/低 {加密} {遮罩} {期限} 📖 使用說明 對應 OWASP ASVS V6（Stored Cryptography）與 V8（Data Protection） 敏感資料需先識別、再定義保護策略 保護措施包含：傳輸加密、靜態加密、資料遮罩、存取控制、保留/銷毀策略 💡 範例 敏感資料識別 資料欄位 敏感等級 加密方式 遮罩方式 保留期限 身分證字號 高 AES-256 (靜態) A1234****9 離職後 5 年 銀行帳號 高 AES-256 (靜態) --1234 離職後 5 年 薪資金額 高 AES-256 (靜態) 不遮罩（權限控制） 永久 手機號碼 中 無（權限控制） 09xx-xxx-789 離職後 2 年 Email 低 無 無 離職後 2 年 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-DATA-001 個資欄位靜態加密儲存（AES-256） V6.2.1 L2 必須 SEC-DATA-002 所有傳輸使用 TLS 1.2+ V9.1.1 L1 必須 SEC-DATA-003 日誌中禁止記錄敏感資料明文 V8.3.1 L1 必須 SEC-DATA-004 資料庫備份亦需加密 V6.2.3 L2 必須 6. 輸入驗證與輸出編碼 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-INPUT-001 {輸入驗證需求} V5.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V5（Validation, Sanitization and Encoding） 防禦 OWASP Top 10 中的注入攻擊（SQL Injection、XSS、Command Injection） 原則：永不信任使用者輸入，伺服器端必須驗證 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-INPUT-001 所有使用者輸入在伺服器端進行驗證（白名單） V5.1.1 L1 必須 SEC-INPUT-002 使用參數化查詢防止 SQL Injection V5.3.4 L1 必須 SEC-INPUT-003 HTML 輸出使用 Context-Aware 編碼防止 XSS V5.3.3 L1 必須 SEC-INPUT-004 檔案上傳驗證副檔名、MIME Type、大小限制 V5.1.4 L1 必須 SEC-INPUT-005 API 輸入限制 Content-Length，防止 DoS V5.1.5 L1 必須 7. Session 管理 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-SESS-001 {Session 管理需求} V3.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V3（Session Management） Session 管理攸關身份劫持風險 需求涵蓋：Session ID 強度、過期設定、Cookie 安全屬性 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-SESS-001 Session ID 長度 ≥ 128 bits，由加密安全亂數產生 V3.2.1 L1 必須 SEC-SESS-002 Cookie 設定 HttpOnly、Secure、SameSite=Strict V3.4.1 L1 必須 SEC-SESS-003 閒置 30 分鐘後自動登出 V3.3.1 L1 必須 SEC-SESS-004 登入後重新產生 Session ID（防 Fixation） V3.2.3 L1 必須 SEC-SESS-005 支援使用者查看與終止其他裝置 Session V3.3.4 L2 建議 8. 日誌與監控需求 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-LOG-001 {日誌監控需求} V7.{x} L{N} 必須/建議 ☐ 稽核事件定義 事件類型 記錄內容 保留期限 {事件} {需記錄的欄位} {期限} 📖 使用說明 對應 OWASP ASVS V7（Error Handling and Logging） 日誌是事後追查與即時偵測的基礎 重點：記什麼、不記什麼（禁止記錄密碼/Token）、保存多久 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-LOG-001 記錄所有認證事件（登入成功/失敗/登出） V7.1.1 L1 必須 SEC-LOG-002 記錄所有授權失敗事件 V7.1.2 L1 必須 SEC-LOG-003 日誌中禁止包含 Session Token、密碼、個資 V7.1.3 L1 必須 SEC-LOG-004 日誌保留 ≥ 90 天，不可竄改 V7.3.1 L2 必須 SEC-LOG-005 連續 5 次認證失敗觸發即時告警 V7.4.1 L2 必須 稽核事件定義 事件類型 記錄內容 保留期限 登入成功 時間、帳號、IP、User-Agent 180 天 登入失敗 時間、帳號、IP、失敗原因 180 天 權限變更 時間、操作者、變更內容 365 天 個資存取 時間、帳號、存取的個資類型 365 天 資料匯出 時間、帳號、匯出範圍、筆數 365 天 9. 通訊安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-COMM-001 {通訊安全需求} V9.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V9（Communication） 保護傳輸中資料不被竊聽或竄改 涵蓋：TLS 版本、憑證管理、HSTS、內部通訊加密 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-COMM-001 所有外部通訊使用 TLS 1.2 以上 V9.1.1 L1 必須 SEC-COMM-002 啟用 HSTS（max-age ≥ 1 年） V9.1.2 L1 必須 SEC-COMM-003 伺服器憑證由受信任 CA 簽發 V9.2.1 L1 必須 SEC-COMM-004 服務間（微服務）通訊使用 mTLS V9.2.2 L2 建議 SEC-COMM-005 禁用 SSL 3.0、TLS 1.0/1.1 V9.1.3 L1 必須 10. 組態安全 📝 範本 需求 ID 需求描述 ASVS 參照 Level 必須/建議 實作狀態 SEC-CFG-001 {組態安全需求} V14.{x} L{N} 必須/建議 ☐ 📖 使用說明 對應 OWASP ASVS V14（Configuration） 安全組態確保系統不因錯誤設定而暴露弱點 涵蓋：預設帳號、除錯模式、HTTP 安全標頭、依賴管理 💡 範例 需求 ID 需求描述 ASVS 參照 Level 必須/建議 SEC-CFG-001 正式環境禁止開啟除錯模式 / 詳細錯誤訊息 V14.1.1 L1 必須 SEC-CFG-002 移除或停用所有預設帳號與密碼 V14.1.2 L1 必須 SEC-CFG-003 設定安全 HTTP Headers（CSP, X-Frame-Options 等） V14.4.1 L1 必須 SEC-CFG-004 第三方依賴無已知 High/Critical CVE V14.2.1 L1 必須 SEC-CFG-005 機敏設定（DB 連線字串、API Key）使用 Secret Manager V14.1.5 L2 必須 11. 合規性需求 📝 範本 法規/標準 適用條款 系統需求對應 實作狀態 {法規名稱} {條款} {系統需滿足的具體需求} ☐ 📖 使用說明 列出系統需遵循的法規、產業標準、企業政策 每條法規要求需轉化為可驗證的技術需求 常見法規：個人資料保護法、GDPR、PCI DSS、ISO 27001 💡 範例 法規/標準 適用條款 系統需求對應 實作狀態 個人資料保護法 第 27 條（安全維護措施） 個資加密儲存、存取控制、稽核日誌 ☑ 個人資料保護法 第 11 條（當事人權利） 提供個資查詢、更正、刪除功能 ☑ ISO 27001:2022 A.8.3（存取控制） RBAC 實作 ☑ ISO 27001:2022 A.8.24（密碼學使用） TLS 1.2+、AES-256 加密 ☑ 公司資安政策 密碼政策 v3.0 12 字元 + 複雜度 + 90 天更換 ☐ 12. 附錄 📝 範本 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） {N} {N} {N} {%} 授權（AUTHZ） {N} {N} {N} {%} 資料保護（DATA） {N} {N} {N} {%} 輸入驗證（INPUT） {N} {N} {N} {%} Session（SESS） {N} {N} {N} {%} 日誌監控（LOG） {N} {N} {N} {%} 通訊安全（COMM） {N} {N} {N} {%} 組態安全（CFG） {N} {N} {N} {%} 合計 {N} {N} {N} {%} 12.2 OWASP ASVS 對照表 ASVS 章節 主題 本文件對應章節 V2 Authentication 第 3 章 V3 Session Management 第 7 章 V4 Access Control 第 4 章 V5 Validation 第 6 章 V6 Stored Cryptography 第 5 章 V7 Error Handling \u0026amp; Logging 第 8 章 V8 Data Protection 第 5 章 V9 Communication 第 9 章 V14 Configuration 第 10 章 📖 使用說明 完成度統計用於追蹤安全需求落實進度 所有「必須」等級的需求需在上線前 100% 實作 ASVS 對照表協助資安審核人員快速定位驗證範圍 💡 範例 12.1 安全需求完成度統計 類別 總需求數 已實作 未實作 完成率 認證（AUTH） 6 5 1 83% 授權（AUTHZ） 5 4 1 80% 資料保護（DATA） 4 4 0 100% 輸入驗證（INPUT） 5 5 0 100% Session（SESS） 5 4 1 80% 日誌監控（LOG） 5 3 2 60% 通訊安全（COMM） 5 5 0 100% 組態安全（CFG） 5 4 1 80% 合計 40 34 6 85% 📌 範本使用注意事項\n","title":"安全需求清單範本（Security Requirements Checklist Template）"},{"content":"專案回顧報告範本（Retrospective Report Template） 適用標準：Agile Retrospectives（Esther Derby \u0026amp; Diana Larsen）、SRE Postmortem Culture\n適用階段：專案管理 — 任何迭代/里程碑/專案結束時\n負責角色：Scrum Master / PM、全體團隊成員\n📑 章節目錄 文件資訊 回顧概要 量化回顧（Metrics） 質性回顧（What Went Well / What Didn\u0026rsquo;t） 根因分析 改善行動項目 前次行動追蹤 團隊健康度 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [專案/Sprint 名稱] 回顧報告 文件編號 [專案代碼]-RETRO-[Sprint#/版本]-[日期] 版本 v[X.Y] 回顧日期 [YYYY-MM-DD] 迭代/里程碑 [Sprint N / Release X.Y / Phase Name] 引導者（Facilitator） [Scrum Master / PM] 參與者 [全體團隊成員名單] 2. 回顧概要 項目 內容 回顧範圍 [Sprint / Release / 專案整體] 迭代期間 [YYYY-MM-DD] ~ [YYYY-MM-DD] 主要交付 [本次迭代完成的主要功能/里程碑] 整體滿意度 [1-5 分，團隊平均] 一句話總結 [本次迭代最重要的一件事] 3. 量化回顧（Metrics） 3.1 交付指標 指標 計畫 實際 達成率 趨勢 Story Points (committed) [N] [N] (completed) [N]% [↑/↓/→] User Stories (完成/承諾) [N]/[M] [N/M] [N]% Bug 數量（新增/修復） —/— [N]/[M] — 技術債處理 [N] items [N] items [N]% 3.2 品質指標 指標 本次 前次 目標 趨勢 Escaped Bugs (上線後發現) [N] [N] 0 [↑/↓/→] Code Coverage [N]% [N]% ≥ [N]% Code Review 回饋速度 (avg) [N] hr [N] hr \u0026lt; [N] hr Build 成功率 [N]% [N]% ≥ 95% 3.3 流程指標 指標 本次 前次 目標 趨勢 Cycle Time (avg) [N] days [N] days \u0026lt; [N] days Lead Time (avg) [N] days [N] days \u0026lt; [N] days WIP 超標次數 [N] [N] 0 阻塞事項數 [N] [N] 儘量少 會議時間佔比 [N]% [N]% \u0026lt; 20% 4. 質性回顧 4.1 做得好的事（What Went Well / Keep） # 項目 影響 建議 1 [正面事項] [對團隊/產品的正面影響] [持續/強化] 2 [正面事項] [影響描述] [持續/推廣] 3 [正面事項] [影響描述] [持續] 4.2 需要改善的事（What Didn\u0026rsquo;t Go Well / Problems） # 項目 影響 嚴重度 備註 1 [問題描述] [對團隊/產品的負面影響] [High/Med/Low] 2 [問題描述] [影響描述] [High/Med/Low] 3 [問題描述] [影響描述] [High/Med/Low] 4.3 想要嘗試的事（Ideas / Try） # 想法 預期效果 成本/風險 決議 1 [新做法/工具/流程] [預期改善] [Low/Med/High] [採納/暫緩/拒絕] 2 [新做法] [預期改善] [Low/Med/High] [決議] 5. 根因分析 針對本次最重要的 1~2 個問題進行深入分析\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/project/retrospective_template/","summary":"專案回顧報告範本（Retrospective Report Template） 適用標準：Agile Retrospectives（Esther Derby \u0026amp; Diana Larsen）、SRE Postmortem Culture\n適用階段：專案管理 — 任何迭代/里程碑/專案結束時\n負責角色：Scrum Master / PM、全體團隊成員\n📑 章節目錄 文件資訊 回顧概要 量化回顧（Metrics） 質性回顧（What Went Well / What Didn\u0026rsquo;t） 根因分析 改善行動項目 前次行動追蹤 團隊健康度 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [專案/Sprint 名稱] 回顧報告 文件編號 [專案代碼]-RETRO-[Sprint#/版本]-[日期] 版本 v[X.Y] 回顧日期 [YYYY-MM-DD] 迭代/里程碑 [Sprint N / Release X.Y / Phase Name] 引導者（Facilitator） [Scrum Master / PM] 參與者 [全體團隊成員名單] 2. 回顧概要 項目 內容 回顧範圍 [Sprint / Release / 專案整體] 迭代期間 [YYYY-MM-DD] ~ [YYYY-MM-DD] 主要交付 [本次迭代完成的主要功能/里程碑] 整體滿意度 [1-5 分，團隊平均] 一句話總結 [本次迭代最重要的一件事] 3. 量化回顧（Metrics） 3.1 交付指標 指標 計畫 實際 達成率 趨勢 Story Points (committed) [N] [N] (completed) [N]% [↑/↓/→] User Stories (完成/承諾) [N]/[M] [N/M] [N]% Bug 數量（新增/修復） —/— [N]/[M] — 技術債處理 [N] items [N] items [N]% 3.2 品質指標 指標 本次 前次 目標 趨勢 Escaped Bugs (上線後發現) [N] [N] 0 [↑/↓/→] Code Coverage [N]% [N]% ≥ [N]% Code Review 回饋速度 (avg) [N] hr [N] hr \u0026lt; [N] hr Build 成功率 [N]% [N]% ≥ 95% 3.3 流程指標 指標 本次 前次 目標 趨勢 Cycle Time (avg) [N] days [N] days \u0026lt; [N] days Lead Time (avg) [N] days [N] days \u0026lt; [N] days WIP 超標次數 [N] [N] 0 阻塞事項數 [N] [N] 儘量少 會議時間佔比 [N]% [N]% \u0026lt; 20% 4. 質性回顧 4.1 做得好的事（What Went Well / Keep） # 項目 影響 建議 1 [正面事項] [對團隊/產品的正面影響] [持續/強化] 2 [正面事項] [影響描述] [持續/推廣] 3 [正面事項] [影響描述] [持續] 4.2 需要改善的事（What Didn\u0026rsquo;t Go Well / Problems） # 項目 影響 嚴重度 備註 1 [問題描述] [對團隊/產品的負面影響] [High/Med/Low] 2 [問題描述] [影響描述] [High/Med/Low] 3 [問題描述] [影響描述] [High/Med/Low] 4.3 想要嘗試的事（Ideas / Try） # 想法 預期效果 成本/風險 決議 1 [新做法/工具/流程] [預期改善] [Low/Med/High] [採納/暫緩/拒絕] 2 [新做法] [預期改善] [Low/Med/High] [決議] 5. 根因分析 針對本次最重要的 1~2 個問題進行深入分析\n","title":"專案回顧報告範本（Retrospective Report Template）"},{"content":"效能測試報告範本（Performance Test Report Template） 適用標準：ISO/IEC/IEEE 29119-3:2021（測試文件）、RFC 2544（Benchmarking）\n適用階段：測試驗證階段（Testing Phase）\n負責角色：效能測試工程師、QA Lead、SRE\n📑 章節目錄 文件資訊 測試摘要 測試環境 測試場景與配置 測試結果 效能瓶頸分析 與 NFR 目標對照 建議與改善方案 結論與決策建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 效能測試報告 文件編號 [專案代碼]-PTR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試工具 [JMeter / k6 / Locust / Gatling] 測試人員 [姓名] 審核者 [QA Lead / SA] 2. 測試摘要 項目 內容 測試類型 [負載測試 / 壓力測試 / 耐久測試 / 容量測試] 測試目的 [驗證系統在預期負載下的回應時間與吞吐量] 測試範圍 [被測試的模組/API/頁面] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 關鍵發現 [一句話總結] 3. 測試環境 3.1 系統架構 元件 規格 數量 備註 Application Server [CPU/Memory/Instance Type] [N] Database Server [CPU/Memory/Type] [N] Cache [Type/Memory] [N] Load Balancer [Type] [N] 3.2 環境差異說明 項目 測試環境 生產環境 比例 App 節點數 [N] [M] 1:[ratio] DB 規格 [spec] [spec] 1:[ratio] 資料量 [N] rows [M] rows (est.) 1:[ratio] ⚠️ 注意：測試結果需依環境比例換算評估生產環境表現\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/testing/performancetestreport_template/","summary":"效能測試報告範本（Performance Test Report Template） 適用標準：ISO/IEC/IEEE 29119-3:2021（測試文件）、RFC 2544（Benchmarking）\n適用階段：測試驗證階段（Testing Phase）\n負責角色：效能測試工程師、QA Lead、SRE\n📑 章節目錄 文件資訊 測試摘要 測試環境 測試場景與配置 測試結果 效能瓶頸分析 與 NFR 目標對照 建議與改善方案 結論與決策建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 效能測試報告 文件編號 [專案代碼]-PTR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試工具 [JMeter / k6 / Locust / Gatling] 測試人員 [姓名] 審核者 [QA Lead / SA] 2. 測試摘要 項目 內容 測試類型 [負載測試 / 壓力測試 / 耐久測試 / 容量測試] 測試目的 [驗證系統在預期負載下的回應時間與吞吐量] 測試範圍 [被測試的模組/API/頁面] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 關鍵發現 [一句話總結] 3. 測試環境 3.1 系統架構 元件 規格 數量 備註 Application Server [CPU/Memory/Instance Type] [N] Database Server [CPU/Memory/Type] [N] Cache [Type/Memory] [N] Load Balancer [Type] [N] 3.2 環境差異說明 項目 測試環境 生產環境 比例 App 節點數 [N] [M] 1:[ratio] DB 規格 [spec] [spec] 1:[ratio] 資料量 [N] rows [M] rows (est.) 1:[ratio] ⚠️ 注意：測試結果需依環境比例換算評估生產環境表現\n","title":"效能測試報告範本（Performance Test Report Template）"},{"content":"標準作業程序範本（Standard Operating Procedure, SOP） 參照標準：ISO 9001:2015（Quality Management）/ ISO/IEC 20000-1:2018 / ITIL 4\n文件用途：標準化維運操作流程，確保操作一致性、降低人為錯誤、加速新人上手\n適用階段：維運監控階段（Operations Phase）— Operational Excellence\n📋 章節目錄 文件資訊 目的與範圍 角色與職責 前置條件 操作步驟 驗證與確認 異常處理 安全注意事項 相關文件 變更歷史 1. 文件資訊 📝 範本 項目 內容 文件編號 SOP-{類別代碼}-{序號} 文件名稱 {操作名稱} 標準作業程序 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 作廢 建立日期 {YYYY-MM-DD} 生效日期 {YYYY-MM-DD} 下次審核日期 {YYYY-MM-DD}（至少每年） 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 適用系統 {系統/服務名稱} 機密等級 一般 / 限閱 / 機密 📖 使用說明 SOP 編號慣例：SOP-{類別}-{流水號} 類別代碼範例：DEP（部署）、INC（事件處理）、BAK（備份）、MON（監控） 每份 SOP 需定期審核（ISO 9001 要求），避免過時 狀態管理：草稿 → 審核中 → 核定（可執行）→ 作廢（新版取代） 機密等級決定誰可以存取此 SOP 💡 範例 項目 內容 文件編號 SOP-BAK-001 文件名稱 HRMS 資料庫每日備份標準作業程序 版本 v2.0 生效日期 2026-05-01 下次審核日期 2027-05-01 適用系統 HRMS PostgreSQL 16 (Azure Database) 2. 目的與範圍 📝 範本 2.1 目的 {說明此 SOP 為何存在、解決什麼問題}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/sop_template/","summary":"標準作業程序範本（Standard Operating Procedure, SOP） 參照標準：ISO 9001:2015（Quality Management）/ ISO/IEC 20000-1:2018 / ITIL 4\n文件用途：標準化維運操作流程，確保操作一致性、降低人為錯誤、加速新人上手\n適用階段：維運監控階段（Operations Phase）— Operational Excellence\n📋 章節目錄 文件資訊 目的與範圍 角色與職責 前置條件 操作步驟 驗證與確認 異常處理 安全注意事項 相關文件 變更歷史 1. 文件資訊 📝 範本 項目 內容 文件編號 SOP-{類別代碼}-{序號} 文件名稱 {操作名稱} 標準作業程序 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 作廢 建立日期 {YYYY-MM-DD} 生效日期 {YYYY-MM-DD} 下次審核日期 {YYYY-MM-DD}（至少每年） 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 適用系統 {系統/服務名稱} 機密等級 一般 / 限閱 / 機密 📖 使用說明 SOP 編號慣例：SOP-{類別}-{流水號} 類別代碼範例：DEP（部署）、INC（事件處理）、BAK（備份）、MON（監控） 每份 SOP 需定期審核（ISO 9001 要求），避免過時 狀態管理：草稿 → 審核中 → 核定（可執行）→ 作廢（新版取代） 機密等級決定誰可以存取此 SOP 💡 範例 項目 內容 文件編號 SOP-BAK-001 文件名稱 HRMS 資料庫每日備份標準作業程序 版本 v2.0 生效日期 2026-05-01 下次審核日期 2027-05-01 適用系統 HRMS PostgreSQL 16 (Azure Database) 2. 目的與範圍 📝 範本 2.1 目的 {說明此 SOP 為何存在、解決什麼問題}\n","title":"標準作業程序範本（SOP Template）"},{"content":"測試報告範本（Test Report） 參照標準：ISO/IEC/IEEE 29119-3:2021（Test Completion Report）\n文件用途：彙整測試執行結果，評估軟體品質，提供上線/不上線的決策依據\n適用階段：測試驗證階段（Testing Phase）— Test Completion\n📋 章節目錄 文件資訊 執行摘要 測試範圍 測試環境 測試執行結果 缺陷分析 覆蓋率分析 風險與未解決項目 品質評估與建議 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TR-{專案代碼}-{迭代/版本}-{序號} 文件名稱 {系統名稱} 測試報告 版本 v{主版本}.{次版本} 測試版本 {受測軟體版本號} 測試類型 單元/整合/系統/UAT/回歸/效能/安全 測試週期 {YYYY-MM-DD} ~ {YYYY-MM-DD} 撰寫者 {QA 負責人} 審核者 {PM/Tech Lead} 發佈日期 {YYYY-MM-DD} 📖 使用說明 每個重要測試里程碑（Sprint 結束、版本發佈前）產出測試報告 測試類型依實際執行的測試活動填寫，可為複合型（如「系統 + 效能」） 測試版本需明確對應 Git Tag / Build Number，確保可追溯 💡 範例 項目 內容 文件編號 TR-HRM-v2.1-001 系統名稱 人力資源管理系統 測試版本 v2.1.0-rc.1 (Build #487) 測試類型 系統測試 + 回歸測試 + 效能測試 測試週期 2026-05-01 ~ 2026-05-15 2. 執行摘要 📝 範本 2.1 整體結論 項目 結果 上線建議 ✅ 建議上線 / ⚠️ 有條件上線 / ❌ 不建議上線 品質等級 優良 / 合格 / 不合格 主要風險 {簡述主要殘餘風險} 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 {%} ≥ {%} ✅/❌ 缺陷密度（Defect/KLOC） {N} ≤ {N} ✅/❌ 嚴重缺陷（Critical/High）未解決 {N} 0 ✅/❌ 需求覆蓋率 {%} ≥ {%} ✅/❌ 程式碼覆蓋率 {%} ≥ {%} ✅/❌ 效能指標達標率 {%} 100% ✅/❌ 📖 使用說明 執行摘要是最重要的章節，決策者可能只看這部分 上線建議需有客觀數據支持，非主觀判斷 「有條件上線」需明確列出條件（如：特定功能暫不開放、需加監控） 關鍵指標的目標值應在測試計畫中事先定義 💡 範例 2.1 整體結論 項目 結果 上線建議 ⚠️ 有條件上線 品質等級 合格 主要風險 2 個 Medium 缺陷待修、大量匯出效能未達標 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 96.8% ≥ 95% ✅ 缺陷密度 2.3/KLOC ≤ 5/KLOC ✅ 嚴重缺陷未解決 0 0 ✅ 需求覆蓋率 98% ≥ 95% ✅ 程式碼覆蓋率 82% ≥ 80% ✅ 效能指標達標率 90% 100% ❌ 3. 測試範圍 📝 範本 3.1 測試項目（In Scope） 模組/功能 測試類型 優先級 執行狀態 {模組名稱} {測試類型} 高/中/低 完成/部分/未執行 3.2 排除項目（Out of Scope） 模組/功能 排除原因 {模組名稱} {原因} 📖 使用說明 明確列出本次測試涵蓋與不涵蓋的範圍 排除原因需合理（如：未修改的模組、下一版本範圍） 執行狀態若為「部分」或「未執行」，需在風險章節說明影響 💡 範例 3.1 測試項目 模組/功能 測試類型 優先級 執行狀態 員工資料管理（CRUD） 系統測試 + 回歸 高 完成 薪資計算引擎 系統測試 + 回歸 高 完成 請假/加班申請流程 系統測試 + 回歸 高 完成 報表匯出（PDF/Excel） 系統測試 + 效能 中 完成 SSO 登入整合 整合測試 高 完成 API 效能（並發） 效能測試 中 完成 3.2 排除項目 模組/功能 排除原因 行動 App v2.2 規劃範圍，本版未開發 第三方薪轉介接（銀行 API） 銀行端 UAT 環境未就緒 4. 測試環境 📝 範本 項目 規格 環境名稱 {SIT/UAT/Staging/Performance} 作業系統 {OS 版本} 應用伺服器 {Server + 版本} 資料庫 {DB + 版本} 測試資料 {描述：模擬資料量/來源} 測試工具 {工具清單} 與正式環境差異 {列出差異} 📖 使用說明 測試環境資訊確保結果可重現 必須列出與正式環境的差異（差異可能影響結果有效性） 效能測試環境應盡量接近正式規格 💡 範例 項目 規格 環境名稱 Staging (Azure AKS) 作業系統 Ubuntu 22.04 (K8s Node) 應用伺服器 .NET 8 Kestrel + Kong 3.5 資料庫 PostgreSQL 16.2 (Azure Database) 測試資料 模擬 10,000 員工、3 年歷史資料 測試工具 xUnit, Playwright, JMeter 5.6, SonarQube 與正式環境差異 節點數 3（正式 6）、資料量為正式 20% 5. 測試執行結果 📝 範本 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） {N} {%} 失敗（Fail） {N} {%} 阻塞（Blocked） {N} {%} 未執行（Not Run） {N} {%} 總計 {N} 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 {模組} {N} {N} {N} {N} {%} 5.3 效能測試結果（如適用） 場景 指標 目標 實際 達標 {場景} {指標} {目標值} {實際值} ✅/❌ 📖 使用說明 統計數據需與測試管理工具（如 Azure DevOps Test Plan）數據一致 失敗案例需逐一追蹤到缺陷 ID 阻塞案例需說明阻塞原因（環境問題？依賴未就緒？） 效能測試報告重點指標：回應時間、吞吐量、錯誤率 💡 範例 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） 242 96.8% 失敗（Fail） 5 2.0% 阻塞（Blocked） 2 0.8% 未執行（Not Run） 1 0.4% 總計 250 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 員工資料管理 65 64 1 0 98.5% 薪資計算 80 78 2 0 97.5% 請假/加班 55 54 0 1 98.2% 報表匯出 30 28 2 0 93.3% SSO 登入 20 18 0 1 90.0%* 5.3 效能測試結果 場景 指標 目標 實際 達標 登入（100 concurrent） P95 回應時間 ≤ 500ms 320ms ✅ 員工查詢（200 concurrent） P95 回應時間 ≤ 1000ms 780ms ✅ 薪資計算批次（10,000筆） 總處理時間 ≤ 5min 3.2min ✅ 報表匯出（5,000筆 Excel） 回應時間 ≤ 30s 45s ❌ API 持續壓力（1hr, 500 TPS） 錯誤率 ≤ 0.1% 0.05% ✅ 6. 缺陷分析 📝 範本 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical {N} {N} {N} {N} High {N} {N} {N} {N} Medium {N} {N} {N} {N} Low {N} {N} {N} {N} 總計 {N} {N} {N} {N} 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 {ID} {等級} {模組} {描述} {狀態} 下版修復/暫時方案/接受 6.3 缺陷趨勢 累計發現 vs 累計解決 趨勢圖（收斂曲線） 📖 使用說明 Critical/High 未解決 = 不建議上線（除非有合理的暫時方案） 缺陷趨勢圖需呈現「收斂」趨勢（發現率下降、解決追上發現） 缺陷明細只列未解決的，已解決的在附錄提供完整清單 處置方式需經 PM/Tech Lead 核准 💡 範例 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical 1 1 0 1 High 3 3 0 3 Medium 8 6 2 6 Low 5 3 2 3 總計 17 13 4 13 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 BUG-142 Medium 報表匯出 Excel 匯出超過 5000 筆時超時 (45s \u0026gt; 30s) Open v2.2 修復（分頁匯出） BUG-145 Medium 報表匯出 PDF 頁首日期格式錯誤 Open v2.1.1 Hotfix BUG-148 Low 員工管理 姓名超過 50 字元時 UI 顯示截斷 Open v2.2 修復 BUG-150 Low 薪資計算 計算說明欄位未支援多語系 Open v2.2 修復 7. 覆蓋率分析 📝 範本 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） {N} {N} {N} {%} 非功能需求（NFR） {N} {N} {N} {%} 安全需求（SEC） {N} {N} {N} {%} 7.2 程式碼覆蓋率 模組 行覆蓋率 分支覆蓋率 方法覆蓋率 {模組} {%} {%} {%} 📖 使用說明 需求覆蓋率：確保每個需求至少有一個測試案例覆蓋 程式碼覆蓋率：通常由 CI/CD 工具（SonarQube、Istanbul）自動產出 目標值：需求覆蓋率 ≥ 95%、行覆蓋率 ≥ 80%、分支覆蓋率 ≥ 70% 未覆蓋的需求需說明原因 💡 範例 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） 45 44 1* 97.8% 非功能需求（NFR） 12 12 0 100% 安全需求（SEC） 40 38 2** 95% *FR-032（行動 App 推播）排除於本版\n**SEC-SESS-005、SEC-COMM-004 為建議等級，計畫 v2.2 驗證\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/testing/testreport_template/","summary":"測試報告範本（Test Report） 參照標準：ISO/IEC/IEEE 29119-3:2021（Test Completion Report）\n文件用途：彙整測試執行結果，評估軟體品質，提供上線/不上線的決策依據\n適用階段：測試驗證階段（Testing Phase）— Test Completion\n📋 章節目錄 文件資訊 執行摘要 測試範圍 測試環境 測試執行結果 缺陷分析 覆蓋率分析 風險與未解決項目 品質評估與建議 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TR-{專案代碼}-{迭代/版本}-{序號} 文件名稱 {系統名稱} 測試報告 版本 v{主版本}.{次版本} 測試版本 {受測軟體版本號} 測試類型 單元/整合/系統/UAT/回歸/效能/安全 測試週期 {YYYY-MM-DD} ~ {YYYY-MM-DD} 撰寫者 {QA 負責人} 審核者 {PM/Tech Lead} 發佈日期 {YYYY-MM-DD} 📖 使用說明 每個重要測試里程碑（Sprint 結束、版本發佈前）產出測試報告 測試類型依實際執行的測試活動填寫，可為複合型（如「系統 + 效能」） 測試版本需明確對應 Git Tag / Build Number，確保可追溯 💡 範例 項目 內容 文件編號 TR-HRM-v2.1-001 系統名稱 人力資源管理系統 測試版本 v2.1.0-rc.1 (Build #487) 測試類型 系統測試 + 回歸測試 + 效能測試 測試週期 2026-05-01 ~ 2026-05-15 2. 執行摘要 📝 範本 2.1 整體結論 項目 結果 上線建議 ✅ 建議上線 / ⚠️ 有條件上線 / ❌ 不建議上線 品質等級 優良 / 合格 / 不合格 主要風險 {簡述主要殘餘風險} 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 {%} ≥ {%} ✅/❌ 缺陷密度（Defect/KLOC） {N} ≤ {N} ✅/❌ 嚴重缺陷（Critical/High）未解決 {N} 0 ✅/❌ 需求覆蓋率 {%} ≥ {%} ✅/❌ 程式碼覆蓋率 {%} ≥ {%} ✅/❌ 效能指標達標率 {%} 100% ✅/❌ 📖 使用說明 執行摘要是最重要的章節，決策者可能只看這部分 上線建議需有客觀數據支持，非主觀判斷 「有條件上線」需明確列出條件（如：特定功能暫不開放、需加監控） 關鍵指標的目標值應在測試計畫中事先定義 💡 範例 2.1 整體結論 項目 結果 上線建議 ⚠️ 有條件上線 品質等級 合格 主要風險 2 個 Medium 缺陷待修、大量匯出效能未達標 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 96.8% ≥ 95% ✅ 缺陷密度 2.3/KLOC ≤ 5/KLOC ✅ 嚴重缺陷未解決 0 0 ✅ 需求覆蓋率 98% ≥ 95% ✅ 程式碼覆蓋率 82% ≥ 80% ✅ 效能指標達標率 90% 100% ❌ 3. 測試範圍 📝 範本 3.1 測試項目（In Scope） 模組/功能 測試類型 優先級 執行狀態 {模組名稱} {測試類型} 高/中/低 完成/部分/未執行 3.2 排除項目（Out of Scope） 模組/功能 排除原因 {模組名稱} {原因} 📖 使用說明 明確列出本次測試涵蓋與不涵蓋的範圍 排除原因需合理（如：未修改的模組、下一版本範圍） 執行狀態若為「部分」或「未執行」，需在風險章節說明影響 💡 範例 3.1 測試項目 模組/功能 測試類型 優先級 執行狀態 員工資料管理（CRUD） 系統測試 + 回歸 高 完成 薪資計算引擎 系統測試 + 回歸 高 完成 請假/加班申請流程 系統測試 + 回歸 高 完成 報表匯出（PDF/Excel） 系統測試 + 效能 中 完成 SSO 登入整合 整合測試 高 完成 API 效能（並發） 效能測試 中 完成 3.2 排除項目 模組/功能 排除原因 行動 App v2.2 規劃範圍，本版未開發 第三方薪轉介接（銀行 API） 銀行端 UAT 環境未就緒 4. 測試環境 📝 範本 項目 規格 環境名稱 {SIT/UAT/Staging/Performance} 作業系統 {OS 版本} 應用伺服器 {Server + 版本} 資料庫 {DB + 版本} 測試資料 {描述：模擬資料量/來源} 測試工具 {工具清單} 與正式環境差異 {列出差異} 📖 使用說明 測試環境資訊確保結果可重現 必須列出與正式環境的差異（差異可能影響結果有效性） 效能測試環境應盡量接近正式規格 💡 範例 項目 規格 環境名稱 Staging (Azure AKS) 作業系統 Ubuntu 22.04 (K8s Node) 應用伺服器 .NET 8 Kestrel + Kong 3.5 資料庫 PostgreSQL 16.2 (Azure Database) 測試資料 模擬 10,000 員工、3 年歷史資料 測試工具 xUnit, Playwright, JMeter 5.6, SonarQube 與正式環境差異 節點數 3（正式 6）、資料量為正式 20% 5. 測試執行結果 📝 範本 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） {N} {%} 失敗（Fail） {N} {%} 阻塞（Blocked） {N} {%} 未執行（Not Run） {N} {%} 總計 {N} 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 {模組} {N} {N} {N} {N} {%} 5.3 效能測試結果（如適用） 場景 指標 目標 實際 達標 {場景} {指標} {目標值} {實際值} ✅/❌ 📖 使用說明 統計數據需與測試管理工具（如 Azure DevOps Test Plan）數據一致 失敗案例需逐一追蹤到缺陷 ID 阻塞案例需說明阻塞原因（環境問題？依賴未就緒？） 效能測試報告重點指標：回應時間、吞吐量、錯誤率 💡 範例 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） 242 96.8% 失敗（Fail） 5 2.0% 阻塞（Blocked） 2 0.8% 未執行（Not Run） 1 0.4% 總計 250 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 員工資料管理 65 64 1 0 98.5% 薪資計算 80 78 2 0 97.5% 請假/加班 55 54 0 1 98.2% 報表匯出 30 28 2 0 93.3% SSO 登入 20 18 0 1 90.0%* 5.3 效能測試結果 場景 指標 目標 實際 達標 登入（100 concurrent） P95 回應時間 ≤ 500ms 320ms ✅ 員工查詢（200 concurrent） P95 回應時間 ≤ 1000ms 780ms ✅ 薪資計算批次（10,000筆） 總處理時間 ≤ 5min 3.2min ✅ 報表匯出（5,000筆 Excel） 回應時間 ≤ 30s 45s ❌ API 持續壓力（1hr, 500 TPS） 錯誤率 ≤ 0.1% 0.05% ✅ 6. 缺陷分析 📝 範本 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical {N} {N} {N} {N} High {N} {N} {N} {N} Medium {N} {N} {N} {N} Low {N} {N} {N} {N} 總計 {N} {N} {N} {N} 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 {ID} {等級} {模組} {描述} {狀態} 下版修復/暫時方案/接受 6.3 缺陷趨勢 累計發現 vs 累計解決 趨勢圖（收斂曲線） 📖 使用說明 Critical/High 未解決 = 不建議上線（除非有合理的暫時方案） 缺陷趨勢圖需呈現「收斂」趨勢（發現率下降、解決追上發現） 缺陷明細只列未解決的，已解決的在附錄提供完整清單 處置方式需經 PM/Tech Lead 核准 💡 範例 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical 1 1 0 1 High 3 3 0 3 Medium 8 6 2 6 Low 5 3 2 3 總計 17 13 4 13 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 BUG-142 Medium 報表匯出 Excel 匯出超過 5000 筆時超時 (45s \u0026gt; 30s) Open v2.2 修復（分頁匯出） BUG-145 Medium 報表匯出 PDF 頁首日期格式錯誤 Open v2.1.1 Hotfix BUG-148 Low 員工管理 姓名超過 50 字元時 UI 顯示截斷 Open v2.2 修復 BUG-150 Low 薪資計算 計算說明欄位未支援多語系 Open v2.2 修復 7. 覆蓋率分析 📝 範本 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） {N} {N} {N} {%} 非功能需求（NFR） {N} {N} {N} {%} 安全需求（SEC） {N} {N} {N} {%} 7.2 程式碼覆蓋率 模組 行覆蓋率 分支覆蓋率 方法覆蓋率 {模組} {%} {%} {%} 📖 使用說明 需求覆蓋率：確保每個需求至少有一個測試案例覆蓋 程式碼覆蓋率：通常由 CI/CD 工具（SonarQube、Istanbul）自動產出 目標值：需求覆蓋率 ≥ 95%、行覆蓋率 ≥ 80%、分支覆蓋率 ≥ 70% 未覆蓋的需求需說明原因 💡 範例 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） 45 44 1* 97.8% 非功能需求（NFR） 12 12 0 100% 安全需求（SEC） 40 38 2** 95% *FR-032（行動 App 推播）排除於本版\n**SEC-SESS-005、SEC-COMM-004 為建議等級，計畫 v2.2 驗證\n","title":"測試報告範本（Test Report Template）"},{"content":"測試案例範本（Test Case Template） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）/ ISO/IEC/IEEE 29119-4:2021（Test Techniques）\n文件用途：定義測試案例的標準格式，確保測試設計完整、可追溯、可重複執行\n適用階段：測試設計與執行階段\n📋 章節目錄 文件資訊 測試案例識別規範 測試案例格式定義 測試案例撰寫規範 測試案例分類 測試案例清單範本 測試案例詳細格式 測試資料規劃 測試執行紀錄 缺陷報告格式 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TC-{專案代碼}-{模組}-{序號} 文件名稱 {系統名稱} {模組名稱} 測試案例 版本 v{主版本}.{次版本} 對應測試計畫 {TP 文件編號} 對應需求 {FRD 文件編號} 撰寫者 {姓名} 審核者 {姓名} 建立日期 {YYYY-MM-DD} 📖 使用說明 測試案例文件承接測試計畫（Test Plan），為各測試項目設計具體的驗證步驟 每個功能模組可獨立一份測試案例文件，或匯整於單一文件中 文件需經 QA Lead 或測試經理審核後方可執行 💡 範例 項目 內容 文件編號 TC-HRM-LV-001 文件名稱 HRMS 假勤管理模組 測試案例 對應測試計畫 TP-HRM-001 對應需求 FRD-HRM-001 v2.1 2. 測試案例識別規範 📝 範本 2.1 編號規則 TC-{專案}-{模組}-{序號} 欄位 說明 範例 TC 固定前綴（Test Case） TC {專案} 專案代碼（2-5 字元） HRM {模組} 模組縮寫（2-5 字元） LV（Leave） {序號} 三位數流水號 001 2.2 命名規範 測試案例名稱格式：[測試類型] {功能描述} - {情境描述}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/testing/testcase_template/","summary":"測試案例範本（Test Case Template） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）/ ISO/IEC/IEEE 29119-4:2021（Test Techniques）\n文件用途：定義測試案例的標準格式，確保測試設計完整、可追溯、可重複執行\n適用階段：測試設計與執行階段\n📋 章節目錄 文件資訊 測試案例識別規範 測試案例格式定義 測試案例撰寫規範 測試案例分類 測試案例清單範本 測試案例詳細格式 測試資料規劃 測試執行紀錄 缺陷報告格式 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TC-{專案代碼}-{模組}-{序號} 文件名稱 {系統名稱} {模組名稱} 測試案例 版本 v{主版本}.{次版本} 對應測試計畫 {TP 文件編號} 對應需求 {FRD 文件編號} 撰寫者 {姓名} 審核者 {姓名} 建立日期 {YYYY-MM-DD} 📖 使用說明 測試案例文件承接測試計畫（Test Plan），為各測試項目設計具體的驗證步驟 每個功能模組可獨立一份測試案例文件，或匯整於單一文件中 文件需經 QA Lead 或測試經理審核後方可執行 💡 範例 項目 內容 文件編號 TC-HRM-LV-001 文件名稱 HRMS 假勤管理模組 測試案例 對應測試計畫 TP-HRM-001 對應需求 FRD-HRM-001 v2.1 2. 測試案例識別規範 📝 範本 2.1 編號規則 TC-{專案}-{模組}-{序號} 欄位 說明 範例 TC 固定前綴（Test Case） TC {專案} 專案代碼（2-5 字元） HRM {模組} 模組縮寫（2-5 字元） LV（Leave） {序號} 三位數流水號 001 2.2 命名規範 測試案例名稱格式：[測試類型] {功能描述} - {情境描述}\n","title":"測試案例範本（Test Case Template）"},{"content":"測試計畫範本（Test Plan） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）\n文件用途：定義測試範圍、策略、資源、時程與風險，指導整體測試活動\n適用階段：測試準備階段（Test Planning Phase）\n📋 章節目錄 文件資訊 測試計畫識別 引言 測試項目 測試策略與方法 通過與失敗標準 暫停與恢復準則 測試交付物 測試環境需求 職責分工 時程與里程碑 風險與緩解措施 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TP-{專案代碼}-{序號} 文件名稱 {系統名稱} 測試計畫 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 測試層級 {Unit / Integration / System / UAT} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版建立 📖 使用說明 依據 ISO/IEC/IEEE 29119-3:2021 第 7 節「Test Plan documentation」 測試計畫可依測試層級分開撰寫（如 SIT 測試計畫、UAT 測試計畫） 一個專案可有多份測試計畫，也可合併為一份主測試計畫（Master Test Plan） 💡 範例 項目 內容 文件編號 TP-HRM-001 文件名稱 人力資源管理系統 系統整合測試計畫 測試層級 System Integration Test (SIT) 對應 FRD FRD-HRM-001 v2.1 2. 測試計畫識別 📝 範本 項目 內容 專案名稱 {專案正式名稱} 受測系統 {系統名稱及版本} 測試階段 {SIT / UAT / Performance / Security} 測試期間 {起始日期} ~ {結束日期} 測試團隊 {團隊名稱} 📖 使用說明 明確識別「測什麼」、「測多久」、「誰來測」 測試期間需與專案整體時程對齊 💡 範例 項目 內容 專案名稱 人力資源管理系統建置專案 受測系統 HRMS v1.0.0 測試階段 SIT（系統整合測試） 測試期間 2026-09-01 ~ 2026-09-30 測試團隊 QA 品質保證組 3. 引言 📝 範本 3.1 測試目的 {描述本次測試活動的目標}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/testing/testplan_template/","summary":"測試計畫範本（Test Plan） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）\n文件用途：定義測試範圍、策略、資源、時程與風險，指導整體測試活動\n適用階段：測試準備階段（Test Planning Phase）\n📋 章節目錄 文件資訊 測試計畫識別 引言 測試項目 測試策略與方法 通過與失敗標準 暫停與恢復準則 測試交付物 測試環境需求 職責分工 時程與里程碑 風險與緩解措施 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TP-{專案代碼}-{序號} 文件名稱 {系統名稱} 測試計畫 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 測試層級 {Unit / Integration / System / UAT} 版本歷程\n版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版建立 📖 使用說明 依據 ISO/IEC/IEEE 29119-3:2021 第 7 節「Test Plan documentation」 測試計畫可依測試層級分開撰寫（如 SIT 測試計畫、UAT 測試計畫） 一個專案可有多份測試計畫，也可合併為一份主測試計畫（Master Test Plan） 💡 範例 項目 內容 文件編號 TP-HRM-001 文件名稱 人力資源管理系統 系統整合測試計畫 測試層級 System Integration Test (SIT) 對應 FRD FRD-HRM-001 v2.1 2. 測試計畫識別 📝 範本 項目 內容 專案名稱 {專案正式名稱} 受測系統 {系統名稱及版本} 測試階段 {SIT / UAT / Performance / Security} 測試期間 {起始日期} ~ {結束日期} 測試團隊 {團隊名稱} 📖 使用說明 明確識別「測什麼」、「測多久」、「誰來測」 測試期間需與專案整體時程對齊 💡 範例 項目 內容 專案名稱 人力資源管理系統建置專案 受測系統 HRMS v1.0.0 測試階段 SIT（系統整合測試） 測試期間 2026-09-01 ~ 2026-09-30 測試團隊 QA 品質保證組 3. 引言 📝 範本 3.1 測試目的 {描述本次測試活動的目標}\n","title":"測試計畫範本（Test Plan Template）"},{"content":"版本發行說明範本（Release Notes） 參照標準：Keep a Changelog 1.1.0 / SemVer 2.0.0 / ISO/IEC/IEEE 12207:2017（Release Management）\n文件用途：正式記錄每個版本的變更內容，供開發、維運、使用者了解版本差異\n適用階段：部署上線階段（Deployment Phase）— Release Management\n📋 章節目錄 文件資訊 版本摘要 新增功能（Added） 變更項目（Changed） 修復項目（Fixed） 棄用項目（Deprecated） 移除項目（Removed） 安全性修復（Security） 已知問題（Known Issues） 升級指南 相容性說明 1. 文件資訊 📝 範本 項目 內容 產品名稱 {系統名稱} 版本號 v{MAJOR}.{MINOR}.{PATCH} 發佈日期 {YYYY-MM-DD} 版本類型 Major / Minor / Patch / Hotfix 發佈人 {Release Manager 姓名} Git Tag {tag name} Build Number #{build} 對應里程碑 {Sprint/Milestone 名稱} 📖 使用說明 版本號遵循 SemVer 2.0.0： MAJOR：不相容的 API 變更 MINOR：向後相容的新功能 PATCH：向後相容的 Bug 修復 每次正式發佈（含 Hotfix）都需要 Release Notes Git Tag 與 Build Number 確保可從 Release Notes 追溯到原始碼 💡 範例 項目 內容 產品名稱 人力資源管理系統（HRMS） 版本號 v2.1.0 發佈日期 2026-05-20 版本類型 Minor 發佈人 林 DevOps Git Tag v2.1.0 Build Number #489 對應里程碑 Sprint 12 2. 版本摘要 📝 範本 概述 {用 2-3 句話描述本版本的核心主題與重要變更}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/deployment/releasenote_template/","summary":"版本發行說明範本（Release Notes） 參照標準：Keep a Changelog 1.1.0 / SemVer 2.0.0 / ISO/IEC/IEEE 12207:2017（Release Management）\n文件用途：正式記錄每個版本的變更內容，供開發、維運、使用者了解版本差異\n適用階段：部署上線階段（Deployment Phase）— Release Management\n📋 章節目錄 文件資訊 版本摘要 新增功能（Added） 變更項目（Changed） 修復項目（Fixed） 棄用項目（Deprecated） 移除項目（Removed） 安全性修復（Security） 已知問題（Known Issues） 升級指南 相容性說明 1. 文件資訊 📝 範本 項目 內容 產品名稱 {系統名稱} 版本號 v{MAJOR}.{MINOR}.{PATCH} 發佈日期 {YYYY-MM-DD} 版本類型 Major / Minor / Patch / Hotfix 發佈人 {Release Manager 姓名} Git Tag {tag name} Build Number #{build} 對應里程碑 {Sprint/Milestone 名稱} 📖 使用說明 版本號遵循 SemVer 2.0.0： MAJOR：不相容的 API 變更 MINOR：向後相容的新功能 PATCH：向後相容的 Bug 修復 每次正式發佈（含 Hotfix）都需要 Release Notes Git Tag 與 Build Number 確保可從 Release Notes 追溯到原始碼 💡 範例 項目 內容 產品名稱 人力資源管理系統（HRMS） 版本號 v2.1.0 發佈日期 2026-05-20 版本類型 Minor 發佈人 林 DevOps Git Tag v2.1.0 Build Number #489 對應里程碑 Sprint 12 2. 版本摘要 📝 範本 概述 {用 2-3 句話描述本版本的核心主題與重要變更}\n","title":"版本發行說明範本（Release Notes Template）"},{"content":"監控與告警設定文件範本（Monitoring \u0026amp; Alert Configuration Template） 適用標準：Google SRE Workbook、ISO/IEC 20000-1:2018（Service Monitoring）\n適用階段：維運階段（Operations Phase）\n負責角色：SRE、DevOps Engineer、Tech Lead\n📑 章節目錄 文件資訊 監控策略概要 SLI / SLO 定義 監控指標設計 告警規則定義 Dashboard 設計 告警通知與升級 日誌監控策略 維護與檢討機制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 監控與告警設定文件 文件編號 [專案代碼]-MON-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [SRE / DevOps] 審核者 [Tech Lead / SA] 2. 監控策略概要 2.1 監控架構 層級 工具 用途 Infrastructure [Prometheus / CloudWatch / Azure Monitor] 主機/容器/網路 Application [APM: Datadog / New Relic / OpenTelemetry] 應用效能 Business [Custom metrics / Analytics] 業務指標 Logging [ELK / Loki / Azure Log Analytics] 日誌分析 Tracing [Jaeger / Zipkin / OpenTelemetry] 分散式追蹤 2.2 監控原則 原則 說明 Four Golden Signals Latency, Traffic, Errors, Saturation USE Method Utilization, Saturation, Errors（基礎設施） RED Method Rate, Errors, Duration（服務） Alerting Philosophy Alert on symptoms, not causes 3. SLI / SLO 定義 3.1 服務層級指標（SLI） SLI 定義 量測方式 資料來源 Availability 成功回應比例 success_requests / total_requests [Load Balancer / App] Latency 回應時間分佈 P50, P95, P99 [APM / Prometheus histogram] Throughput 處理量 Requests per second [Metrics] Error Rate 錯誤回應比例 5xx_count / total_count [Ingress / App] 3.2 服務層級目標（SLO） 服務 SLO 指標 目標值 Error Budget (月) 量測視窗 [API Service] Availability ≥ 99.9% 43.8 min 30 days rolling [API Service] P95 Latency \u0026lt; [N]ms — 30 days rolling [Web Frontend] Availability ≥ 99.5% 3.6 hr 30 days rolling [Batch Job] Success Rate ≥ 99.0% — Per execution 4. 監控指標設計 4.1 基礎設施指標 指標名稱 類型 描述 標籤 閾值 node_cpu_usage_percent Gauge CPU 使用率 host, instance warn: 80%, crit: 95% node_memory_usage_percent Gauge 記憶體使用率 host, instance warn: 85%, crit: 95% node_disk_usage_percent Gauge 磁碟使用率 host, mountpoint warn: 80%, crit: 90% node_network_errors_total Counter 網路錯誤數 host, interface crit: \u0026gt; [N]/min 4.2 應用程式指標 指標名稱 類型 描述 標籤 閾值 http_requests_total Counter HTTP 請求總數 method, path, status — http_request_duration_seconds Histogram 請求處理時間 method, path P95 \u0026lt; [N]s http_requests_errors_total Counter HTTP 錯誤數 method, path, status rate \u0026gt; [N]/min active_connections Gauge 活躍連線數 service warn: [N], crit: [N] db_connection_pool_active Gauge DB 連線池使用數 pool_name warn: 80%, crit: 95% queue_depth Gauge 訊息佇列深度 queue_name warn: [N], crit: [N] 4.3 業務指標 指標名稱 類型 描述 標籤 告警條件 [business_metric_1] Counter [描述] [labels] [condition] [business_metric_2] Gauge [描述] [labels] [condition] 5. 告警規則定義 5.1 告警嚴重度定義 嚴重度 定義 回應時間 通知方式 P1 - Critical 服務完全中斷 / 資料遺失 5 分鐘 PagerDuty + 電話 + SMS P2 - High 核心功能受損 / 效能嚴重惡化 15 分鐘 PagerDuty + Teams P3 - Medium 非核心功能異常 / 效能下降 1 小時 Teams Channel P4 - Low 預警 / 需關注但無立即影響 下個工作日 Email / Ticket 5.2 告警規則清單 Alert ID 名稱 嚴重度 條件 For 說明 ALT-001 ServiceDown P1 up == 0 1m 服務實例離線 ALT-002 HighErrorRate P1 error_rate \u0026gt; 5% 5m 錯誤率過高 ALT-003 HighLatency P2 p95_latency \u0026gt; [N]ms 5m 回應時間過慢 ALT-004 HighCPU P3 cpu_usage \u0026gt; 80% 10m CPU 使用率高 ALT-005 DiskAlmostFull P2 disk_usage \u0026gt; 85% 5m 磁碟空間不足 ALT-006 DBConnectionPoolHigh P2 pool_usage \u0026gt; 80% 5m DB 連線池接近上限 ALT-007 CertExpiringSoon P3 cert_expiry \u0026lt; 30d — 憑證即將到期 ALT-008 ErrorBudgetBurnRate P2 burn_rate \u0026gt; 1.0 1h Error Budget 消耗過快 5.3 告警規則範例（Prometheus AlertManager） groups: - name: [service_name].rules rules: - alert: [AlertName] expr: [PromQL expression] for: [duration] labels: severity: [critical/warning/info] team: [team_name] service: [service_name] annotations: summary: \u0026#34;[簡短摘要]\u0026#34; description: \u0026#34;[詳細描述，可含 {{ $labels }} 和 {{ $value }}]\u0026#34; runbook_url: \u0026#34;[Runbook 連結]\u0026#34; dashboard_url: \u0026#34;[Dashboard 連結]\u0026#34; 6. Dashboard 設計 6.1 Dashboard 清單 Dashboard 用途 目標受眾 更新頻率 Service Overview 服務健康狀態總覽 SRE / 管理層 10s API Performance API 效能細節 SRE / Dev 10s Infrastructure 基礎設施資源 Infra / SRE 30s Business Metrics 業務指標 PM / PO 1m SLO Tracking SLO 達成率與 Error Budget SRE / 管理層 1m 6.2 Service Overview Dashboard 設計 Panel 視覺化類型 指標 說明 Service Status Stat (up/down) up{service=\u0026quot;\u0026hellip;\u0026quot;} 紅綠燈 Request Rate Time Series rate(http_requests_total[5m]) QPS Error Rate Time Series error_rate 錯誤率趨勢 P95 Latency Time Series histogram_quantile(0.95, \u0026hellip;) 延遲趨勢 Active Users Stat active_sessions 當前活躍用戶 SLO Status Gauge slo_compliance SLO 達標率 7. 告警通知與升級 7.1 通知路由 嚴重度 工作時間 (09-18) 非工作時間 假日 P1 On-call + Team Lead (即時) On-call + Backup (即時) On-call + Manager (即時) P2 On-call (15 min) On-call (30 min) On-call (30 min) P3 Teams Channel 下個工作日 下個工作日 P4 Email / Ticket — — 7.2 升級機制 時間 未回應動作 T + 5 min 重新通知 On-call T + 15 min 通知 Backup On-call T + 30 min 通知 Team Lead / Manager T + 60 min 通知 Director / VP 7.3 On-Call 輪值 週次 Primary Backup 電話 Week 1 [姓名] [姓名] [電話] Week 2 [姓名] [姓名] [電話] 8. 日誌監控策略 8.1 日誌等級與保留 Log Level 用途 保留期間 告警 ERROR 需處理的錯誤 90 days rate \u0026gt; [N]/min → P2 WARN 潛在問題 30 days rate \u0026gt; [N]/min → P3 INFO 正常營運記錄 14 days — DEBUG 開發除錯用 3 days (STG only) — 8.2 關鍵日誌監控 # 監控模式 觸發條件 告警 1 Exception stack trace rate \u0026gt; [N]/min P2 2 \u0026ldquo;OutOfMemoryError\u0026rdquo; 出現 1 次 P1 3 \u0026ldquo;Connection refused\u0026rdquo; rate \u0026gt; [N]/min P2 4 Authentication failure rate \u0026gt; [N]/min P2 (可能攻擊) 5 [自訂業務異常模式] [條件] [等級] 9. 維護與檢討機制 項目 頻率 負責人 說明 Alert Noise 檢討 每月 SRE 刪除/調整誤報告警 SLO 檢討 每季 SRE + PO 調整目標值 Dashboard 更新 需求變動時 SRE 新增/移除指標 Runbook 更新 每次事件後 SRE 補充處理步驟 On-Call 回顧 每月 SRE Team 改善值班體驗 10. 附錄 10.1 AlertManager 設定檔位置 檔案 位置 說明 alertmanager.yml [path] 通知路由設定 prometheus-rules/ [path] 告警規則目錄 grafana-dashboards/ [path] Dashboard JSON 10.2 相關文件 文件 連結 Runbook [link] SOP [link] Incident Response Plan [link] 📖 使用說明 建立監控的優先順序 Phase 1：健康檢查 + 基本告警（Service Up/Down, Error Rate） Phase 2：Golden Signals 完整覆蓋（Latency, Traffic, Errors, Saturation） Phase 3：SLI/SLO 追蹤 + Error Budget Phase 4：業務指標 + 進階分析 告警設計原則 原則 說明 Alert on symptoms 告警使用者可感知的症狀，非原因 Actionable 每個告警都必須有對應的處理動作 Low noise 避免無意義的告警（Alert fatigue） Have a runbook 每個告警必須連結到 Runbook 💡 範例（以 HRMS 人力資源管理系統為例） 範例：SLI/SLO 服務 SLI SLO Error Budget/月 HRMS API Availability ≥ 99.9% 43.8 min HRMS API P95 Latency \u0026lt; 200ms — 薪資批次作業 Success Rate ≥ 99.99% 0.44 min (每月一次不容失敗) 出缺勤打卡 Availability ≥ 99.95% (上班時段) 21.9 min 範例：告警規則 groups: - name: hrms.rules rules: - alert: HRMSHighErrorRate expr: | sum(rate(http_requests_total{service=\u0026#34;hrms-api\u0026#34;, status=~\u0026#34;5..\u0026#34;}[5m])) / sum(rate(http_requests_total{service=\u0026#34;hrms-api\u0026#34;}[5m])) \u0026gt; 0.01 for: 5m labels: severity: critical team: hrms service: hrms-api annotations: summary: \u0026#34;HRMS API 錯誤率超過 1%\u0026#34; description: \u0026#34;目前錯誤率為 {{ $value | humanizePercentage }}，超過 SLO 閾值\u0026#34; runbook_url: \u0026#34;https://wiki/runbook/hrms-high-error-rate\u0026#34; - alert: HRMSPayrollJobFailed expr: hrms_payroll_job_status == 0 for: 1m labels: severity: critical team: hrms service: hrms-payroll annotations: summary: \u0026#34;HRMS 薪資計算作業失敗\u0026#34; description: \u0026#34;月薪計算批次作業執行失敗，需立即處理\u0026#34; runbook_url: \u0026#34;https://wiki/runbook/hrms-payroll-failure\u0026#34; 📌 審閱重點\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/monitoringalertconfig_template/","summary":"監控與告警設定文件範本（Monitoring \u0026amp; Alert Configuration Template） 適用標準：Google SRE Workbook、ISO/IEC 20000-1:2018（Service Monitoring）\n適用階段：維運階段（Operations Phase）\n負責角色：SRE、DevOps Engineer、Tech Lead\n📑 章節目錄 文件資訊 監控策略概要 SLI / SLO 定義 監控指標設計 告警規則定義 Dashboard 設計 告警通知與升級 日誌監控策略 維護與檢討機制 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 監控與告警設定文件 文件編號 [專案代碼]-MON-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 負責人 [SRE / DevOps] 審核者 [Tech Lead / SA] 2. 監控策略概要 2.1 監控架構 層級 工具 用途 Infrastructure [Prometheus / CloudWatch / Azure Monitor] 主機/容器/網路 Application [APM: Datadog / New Relic / OpenTelemetry] 應用效能 Business [Custom metrics / Analytics] 業務指標 Logging [ELK / Loki / Azure Log Analytics] 日誌分析 Tracing [Jaeger / Zipkin / OpenTelemetry] 分散式追蹤 2.2 監控原則 原則 說明 Four Golden Signals Latency, Traffic, Errors, Saturation USE Method Utilization, Saturation, Errors（基礎設施） RED Method Rate, Errors, Duration（服務） Alerting Philosophy Alert on symptoms, not causes 3. SLI / SLO 定義 3.1 服務層級指標（SLI） SLI 定義 量測方式 資料來源 Availability 成功回應比例 success_requests / total_requests [Load Balancer / App] Latency 回應時間分佈 P50, P95, P99 [APM / Prometheus histogram] Throughput 處理量 Requests per second [Metrics] Error Rate 錯誤回應比例 5xx_count / total_count [Ingress / App] 3.2 服務層級目標（SLO） 服務 SLO 指標 目標值 Error Budget (月) 量測視窗 [API Service] Availability ≥ 99.9% 43.8 min 30 days rolling [API Service] P95 Latency \u0026lt; [N]ms — 30 days rolling [Web Frontend] Availability ≥ 99.5% 3.6 hr 30 days rolling [Batch Job] Success Rate ≥ 99.0% — Per execution 4. 監控指標設計 4.1 基礎設施指標 指標名稱 類型 描述 標籤 閾值 node_cpu_usage_percent Gauge CPU 使用率 host, instance warn: 80%, crit: 95% node_memory_usage_percent Gauge 記憶體使用率 host, instance warn: 85%, crit: 95% node_disk_usage_percent Gauge 磁碟使用率 host, mountpoint warn: 80%, crit: 90% node_network_errors_total Counter 網路錯誤數 host, interface crit: \u0026gt; [N]/min 4.2 應用程式指標 指標名稱 類型 描述 標籤 閾值 http_requests_total Counter HTTP 請求總數 method, path, status — http_request_duration_seconds Histogram 請求處理時間 method, path P95 \u0026lt; [N]s http_requests_errors_total Counter HTTP 錯誤數 method, path, status rate \u0026gt; [N]/min active_connections Gauge 活躍連線數 service warn: [N], crit: [N] db_connection_pool_active Gauge DB 連線池使用數 pool_name warn: 80%, crit: 95% queue_depth Gauge 訊息佇列深度 queue_name warn: [N], crit: [N] 4.3 業務指標 指標名稱 類型 描述 標籤 告警條件 [business_metric_1] Counter [描述] [labels] [condition] [business_metric_2] Gauge [描述] [labels] [condition] 5. 告警規則定義 5.1 告警嚴重度定義 嚴重度 定義 回應時間 通知方式 P1 - Critical 服務完全中斷 / 資料遺失 5 分鐘 PagerDuty + 電話 + SMS P2 - High 核心功能受損 / 效能嚴重惡化 15 分鐘 PagerDuty + Teams P3 - Medium 非核心功能異常 / 效能下降 1 小時 Teams Channel P4 - Low 預警 / 需關注但無立即影響 下個工作日 Email / Ticket 5.2 告警規則清單 Alert ID 名稱 嚴重度 條件 For 說明 ALT-001 ServiceDown P1 up == 0 1m 服務實例離線 ALT-002 HighErrorRate P1 error_rate \u0026gt; 5% 5m 錯誤率過高 ALT-003 HighLatency P2 p95_latency \u0026gt; [N]ms 5m 回應時間過慢 ALT-004 HighCPU P3 cpu_usage \u0026gt; 80% 10m CPU 使用率高 ALT-005 DiskAlmostFull P2 disk_usage \u0026gt; 85% 5m 磁碟空間不足 ALT-006 DBConnectionPoolHigh P2 pool_usage \u0026gt; 80% 5m DB 連線池接近上限 ALT-007 CertExpiringSoon P3 cert_expiry \u0026lt; 30d — 憑證即將到期 ALT-008 ErrorBudgetBurnRate P2 burn_rate \u0026gt; 1.0 1h Error Budget 消耗過快 5.3 告警規則範例（Prometheus AlertManager） groups: - name: [service_name].rules rules: - alert: [AlertName] expr: [PromQL expression] for: [duration] labels: severity: [critical/warning/info] team: [team_name] service: [service_name] annotations: summary: \u0026#34;[簡短摘要]\u0026#34; description: \u0026#34;[詳細描述，可含 {{ $labels }} 和 {{ $value }}]\u0026#34; runbook_url: \u0026#34;[Runbook 連結]\u0026#34; dashboard_url: \u0026#34;[Dashboard 連結]\u0026#34; 6. Dashboard 設計 6.1 Dashboard 清單 Dashboard 用途 目標受眾 更新頻率 Service Overview 服務健康狀態總覽 SRE / 管理層 10s API Performance API 效能細節 SRE / Dev 10s Infrastructure 基礎設施資源 Infra / SRE 30s Business Metrics 業務指標 PM / PO 1m SLO Tracking SLO 達成率與 Error Budget SRE / 管理層 1m 6.2 Service Overview Dashboard 設計 Panel 視覺化類型 指標 說明 Service Status Stat (up/down) up{service=\u0026quot;\u0026hellip;\u0026quot;} 紅綠燈 Request Rate Time Series rate(http_requests_total[5m]) QPS Error Rate Time Series error_rate 錯誤率趨勢 P95 Latency Time Series histogram_quantile(0.95, \u0026hellip;) 延遲趨勢 Active Users Stat active_sessions 當前活躍用戶 SLO Status Gauge slo_compliance SLO 達標率 7. 告警通知與升級 7.1 通知路由 嚴重度 工作時間 (09-18) 非工作時間 假日 P1 On-call + Team Lead (即時) On-call + Backup (即時) On-call + Manager (即時) P2 On-call (15 min) On-call (30 min) On-call (30 min) P3 Teams Channel 下個工作日 下個工作日 P4 Email / Ticket — — 7.2 升級機制 時間 未回應動作 T + 5 min 重新通知 On-call T + 15 min 通知 Backup On-call T + 30 min 通知 Team Lead / Manager T + 60 min 通知 Director / VP 7.3 On-Call 輪值 週次 Primary Backup 電話 Week 1 [姓名] [姓名] [電話] Week 2 [姓名] [姓名] [電話] 8. 日誌監控策略 8.1 日誌等級與保留 Log Level 用途 保留期間 告警 ERROR 需處理的錯誤 90 days rate \u0026gt; [N]/min → P2 WARN 潛在問題 30 days rate \u0026gt; [N]/min → P3 INFO 正常營運記錄 14 days — DEBUG 開發除錯用 3 days (STG only) — 8.2 關鍵日誌監控 # 監控模式 觸發條件 告警 1 Exception stack trace rate \u0026gt; [N]/min P2 2 \u0026ldquo;OutOfMemoryError\u0026rdquo; 出現 1 次 P1 3 \u0026ldquo;Connection refused\u0026rdquo; rate \u0026gt; [N]/min P2 4 Authentication failure rate \u0026gt; [N]/min P2 (可能攻擊) 5 [自訂業務異常模式] [條件] [等級] 9. 維護與檢討機制 項目 頻率 負責人 說明 Alert Noise 檢討 每月 SRE 刪除/調整誤報告警 SLO 檢討 每季 SRE + PO 調整目標值 Dashboard 更新 需求變動時 SRE 新增/移除指標 Runbook 更新 每次事件後 SRE 補充處理步驟 On-Call 回顧 每月 SRE Team 改善值班體驗 10. 附錄 10.1 AlertManager 設定檔位置 檔案 位置 說明 alertmanager.yml [path] 通知路由設定 prometheus-rules/ [path] 告警規則目錄 grafana-dashboards/ [path] Dashboard JSON 10.2 相關文件 文件 連結 Runbook [link] SOP [link] Incident Response Plan [link] 📖 使用說明 建立監控的優先順序 Phase 1：健康檢查 + 基本告警（Service Up/Down, Error Rate） Phase 2：Golden Signals 完整覆蓋（Latency, Traffic, Errors, Saturation） Phase 3：SLI/SLO 追蹤 + Error Budget Phase 4：業務指標 + 進階分析 告警設計原則 原則 說明 Alert on symptoms 告警使用者可感知的症狀，非原因 Actionable 每個告警都必須有對應的處理動作 Low noise 避免無意義的告警（Alert fatigue） Have a runbook 每個告警必須連結到 Runbook 💡 範例（以 HRMS 人力資源管理系統為例） 範例：SLI/SLO 服務 SLI SLO Error Budget/月 HRMS API Availability ≥ 99.9% 43.8 min HRMS API P95 Latency \u0026lt; 200ms — 薪資批次作業 Success Rate ≥ 99.99% 0.44 min (每月一次不容失敗) 出缺勤打卡 Availability ≥ 99.95% (上班時段) 21.9 min 範例：告警規則 groups: - name: hrms.rules rules: - alert: HRMSHighErrorRate expr: | sum(rate(http_requests_total{service=\u0026#34;hrms-api\u0026#34;, status=~\u0026#34;5..\u0026#34;}[5m])) / sum(rate(http_requests_total{service=\u0026#34;hrms-api\u0026#34;}[5m])) \u0026gt; 0.01 for: 5m labels: severity: critical team: hrms service: hrms-api annotations: summary: \u0026#34;HRMS API 錯誤率超過 1%\u0026#34; description: \u0026#34;目前錯誤率為 {{ $value | humanizePercentage }}，超過 SLO 閾值\u0026#34; runbook_url: \u0026#34;https://wiki/runbook/hrms-high-error-rate\u0026#34; - alert: HRMSPayrollJobFailed expr: hrms_payroll_job_status == 0 for: 1m labels: severity: critical team: hrms service: hrms-payroll annotations: summary: \u0026#34;HRMS 薪資計算作業失敗\u0026#34; description: \u0026#34;月薪計算批次作業執行失敗，需立即處理\u0026#34; runbook_url: \u0026#34;https://wiki/runbook/hrms-payroll-failure\u0026#34; 📌 審閱重點\n","title":"監控與告警設定文件範本（Monitoring \u0026 Alert Configuration Template）"},{"content":"系統退役計畫範本（System Retirement Plan Template） 適用標準：ISO/IEC/IEEE 15288:2023（System Life Cycle - Disposal Process）\n適用階段：維運階段 — 退役處理（Operations — Retirement Phase）\n負責角色：PM、SA、DBA、Infra、資安\n📑 章節目錄 文件資訊 退役概要 影響分析 資料處置計畫 基礎設施釋放計畫 相依系統處理 溝通計畫 退役執行步驟 驗證與確認 風險與應變 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 退役計畫 文件編號 [專案代碼]-RTP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 預計退役日 [YYYY-MM-DD] 負責人 [PM / SA] 審核者 [IT Director / CISO] 2. 退役概要 項目 內容 系統名稱 [退役系統名稱] 系統用途 [一句話描述系統功能] 上線日期 [YYYY-MM-DD] 服務年限 [N] 年 退役原因 [被取代 / 業務需求消失 / 技術不支援 / 成本效益] 替代系統 [新系統名稱] 或 [無] 影響用戶數 [N] 人 退役方式 [立即下線 / 漸進退場 / 唯讀保留期] 2.1 退役判定準則 準則 說明 是否滿足 替代系統已上線並穩定 [新系統 GAP 已關閉] [✅/❌] 使用者已完成遷移 [N]% 已切換至新系統 [✅/❌] 資料已完成遷移/封存 [全量遷移完成] [✅/❌] 相依系統已解耦 [所有介接已切換] [✅/❌] 法規保留要求已確認 [保留年限/方式已確定] [✅/❌] 3. 影響分析 3.1 利害關係人影響 利害關係人 影響描述 嚴重度 緩解措施 [內部使用者] [無法再使用舊系統] [Low] [已遷移至新系統] [外部合作夥伴] [API 中斷] [Medium] [提前通知 + 新 API 對接] [報表使用者] [歷史報表查詢] [Medium] [資料封存 + 查詢介面] 3.2 功能影響盤點 功能模組 狀態 替代方案 備註 [模組 A] 已遷移至新系統 [新系統模組 X] [模組 B] 功能廢除 無 [業務確認不再需要] [模組 C] 部分功能無替代 [Manual process / 新建] ⚠️ GAP 3.3 合規與法規要求 法規/政策 要求 資料保留期 處理方式 [個資法] 個人資料銷毀或去識別化 — [銷毀/去識別化] [商業法] 財務交易記錄保留 [N] 年 [封存至 Archive] [公司政策] [內部規範] [N] 年 [方式] 4. 資料處置計畫 4.1 資料分類與處置 資料類別 資料表/儲存 筆數 大小 處置方式 備註 已遷移資料 [tables] [N] [N]GB 驗證後刪除 遷移至新系統 法規保留資料 [tables] [N] [N]GB 封存至冷儲存 保留 [N] 年 個人資料 [tables] [N] [N]GB 去識別化/銷毀 依個資法 暫存/Log [tables] [N] [N]GB 直接刪除 無保留價值 附件/檔案 [storage] [N] [N]GB [遷移/封存/刪除] 4.2 資料封存規格 項目 內容 封存格式 [SQL dump / Parquet / CSV + Schema] 封存位置 [Cold Storage / Archive Vault] 加密方式 [AES-256 / 由保管庫管理] 存取方式 [申請制 / 限特定角色] 保留期限 [N] 年，到期後 [自動銷毀 / 覆審] 驗證方式 [Checksum / Restore test] 4.3 資料銷毀證明 銷毀項目 方式 執行日 執行人 驗證人 證明文件 [DB data] [TRUNCATE + VACUUM / Secure erase] [日期] [DBA] [資安] [存證編號] [File storage] [Secure delete / Disk wipe] [日期] [Infra] [資安] [存證編號] [Backup tapes] [Degauss / Physical destruction] [日期] [Infra] [資安] [存證編號] 5. 基礎設施釋放計畫 5.1 資源盤點 資源類型 名稱/ID 規格 月費 處置方式 預計釋放日 VM / 主機 [hostname/ID] [spec] $[N] [刪除/重新用途] [日期] Database [instance name] [spec] $[N] [刪除] [日期] Storage [bucket/share] [N]GB $[N] [資料移出後刪除] [日期] Load Balancer [name] — $[N] [刪除] [日期] DNS Record [domain] — — [刪除/轉向] [日期] SSL Certificate [CN] — — [不續約] [到期日] Monitoring [Dashboard/Alert] — — [刪除] [日期] 5.2 成本節約估計 項目 月費 年費 備註 計算資源 $[N] $[N] 儲存 $[N] $[N] 授權 (License) $[N] $[N] 維護合約 $[N] $[N] 合計節省 $[N] $[N] 6. 相依系統處理 6.1 上游系統（呼叫退役系統的系統） 來源系統 介接方式 呼叫頻率 處理方式 負責人 狀態 [System A] REST API [N] calls/day 切換至新系統 API [PM of A] [✅/❌] [System B] DB Link [N] queries/day 移除 DB Link [DBA] [✅/❌] 6.2 下游系統（退役系統呼叫的系統） 目標系統 介接方式 影響 處理方式 狀態 [System C] Event publish [訂閱者需取消] 通知訂閱者 [✅/❌] 6.3 共用元件 元件 共用者 可否移除 處理方式 [Shared DB] [系統列表] [否] [僅移除退役系統的 Schema] [Message Queue] [系統列表] [是/否] [移除 Topic / 保留] 7. 溝通計畫 時間點 對象 內容 方式 負責人 T - 90 天 所有使用者 退役預告 + 遷移指引 Email + 公告 PM T - 60 天 相依系統負責人 技術切換時程 會議 SA T - 30 天 所有使用者 最後提醒 + 進入唯讀期 Email + In-app PM T - 7 天 全體 最終通知 Email + Teams PM T day IT 團隊 執行退役 War Room RM T + 1 天 全體 退役完成通知 Email PM 8. 退役執行步驟 # 步驟 負責人 預估時間 前置條件 狀態 1 切換至唯讀模式 DevOps [N] min T-30d 通知完成 2 最終資料備份 DBA [N] hr 唯讀模式已啟用 3 驗證最終備份完整性 DBA [N] hr 備份完成 4 DNS 移除/轉向 Infra [N] min 5 停止應用程式服務 DevOps [N] min DNS 已處理 6 移除相依系統連線設定 SA/DevOps [N] hr 相依系統已切換 7 資料封存（法規保留） DBA [N] hr 備份驗證通過 8 資料銷毀（非保留資料） DBA/Infra [N] hr 封存完成 9 基礎設施釋放 Infra [N] hr 資料處置完成 10 監控/告警移除 SRE [N] min 服務已停止 11 文件更新（架構圖/CMDB） SA [N] hr 全部完成 12 退役完成確認 PM — 全部驗證通過 9. 驗證與確認 9.1 退役前驗證 # 驗證項目 方法 預期結果 狀態 1 新系統功能涵蓋率 UAT 驗收 100% 功能可替代 [✅/❌] 2 資料遷移完整性 Count + Sample 驗證 差異 = 0 [✅/❌] 3 相依系統已切換 連線測試 無對退役系統的呼叫 [✅/❌] 4 使用者已遷移 登入統計 活躍用戶 = 0 [✅/❌] 9.2 退役後驗證 # 驗證項目 方法 預期結果 狀態 1 舊系統不可存取 URL/IP 測試 Connection refused / 404 [✅/❌] 2 新系統運作正常 Smoke Test 全數通過 [✅/❌] 3 封存資料可存取 Restore 測試 資料完整可讀 [✅/❌] 4 無殘留資源 CMDB / Cloud Console 檢查 資源已清除 [✅/❌] 5 成本已停止計費 帳單確認 下月帳單減少 [✅/❌] 10. 風險與應變 # 風險 影響 機率 應變措施 1 使用者未完成遷移 業務中斷 Medium 延長唯讀期 + 人工協助 2 發現未識別的相依系統 相依系統異常 Medium 保留 DNS 轉向頁 30 天 3 法規保留期判定錯誤 合規風險 Low 法務覆審 + 寧可多保留 4 封存資料無法還原 資料遺失 Low 保留完整備份至驗證通過 5 退役後需要回溯查詢 業務查詢困難 Medium 建立簡易查詢介面 for 封存資料 11. 附錄 11.1 系統架構圖（退役前） [附上退役系統目前的架構圖，標示將移除的元件]\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/retirementplan_template/","summary":"系統退役計畫範本（System Retirement Plan Template） 適用標準：ISO/IEC/IEEE 15288:2023（System Life Cycle - Disposal Process）\n適用階段：維運階段 — 退役處理（Operations — Retirement Phase）\n負責角色：PM、SA、DBA、Infra、資安\n📑 章節目錄 文件資訊 退役概要 影響分析 資料處置計畫 基礎設施釋放計畫 相依系統處理 溝通計畫 退役執行步驟 驗證與確認 風險與應變 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 退役計畫 文件編號 [專案代碼]-RTP-[版本號]-[日期] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 預計退役日 [YYYY-MM-DD] 負責人 [PM / SA] 審核者 [IT Director / CISO] 2. 退役概要 項目 內容 系統名稱 [退役系統名稱] 系統用途 [一句話描述系統功能] 上線日期 [YYYY-MM-DD] 服務年限 [N] 年 退役原因 [被取代 / 業務需求消失 / 技術不支援 / 成本效益] 替代系統 [新系統名稱] 或 [無] 影響用戶數 [N] 人 退役方式 [立即下線 / 漸進退場 / 唯讀保留期] 2.1 退役判定準則 準則 說明 是否滿足 替代系統已上線並穩定 [新系統 GAP 已關閉] [✅/❌] 使用者已完成遷移 [N]% 已切換至新系統 [✅/❌] 資料已完成遷移/封存 [全量遷移完成] [✅/❌] 相依系統已解耦 [所有介接已切換] [✅/❌] 法規保留要求已確認 [保留年限/方式已確定] [✅/❌] 3. 影響分析 3.1 利害關係人影響 利害關係人 影響描述 嚴重度 緩解措施 [內部使用者] [無法再使用舊系統] [Low] [已遷移至新系統] [外部合作夥伴] [API 中斷] [Medium] [提前通知 + 新 API 對接] [報表使用者] [歷史報表查詢] [Medium] [資料封存 + 查詢介面] 3.2 功能影響盤點 功能模組 狀態 替代方案 備註 [模組 A] 已遷移至新系統 [新系統模組 X] [模組 B] 功能廢除 無 [業務確認不再需要] [模組 C] 部分功能無替代 [Manual process / 新建] ⚠️ GAP 3.3 合規與法規要求 法規/政策 要求 資料保留期 處理方式 [個資法] 個人資料銷毀或去識別化 — [銷毀/去識別化] [商業法] 財務交易記錄保留 [N] 年 [封存至 Archive] [公司政策] [內部規範] [N] 年 [方式] 4. 資料處置計畫 4.1 資料分類與處置 資料類別 資料表/儲存 筆數 大小 處置方式 備註 已遷移資料 [tables] [N] [N]GB 驗證後刪除 遷移至新系統 法規保留資料 [tables] [N] [N]GB 封存至冷儲存 保留 [N] 年 個人資料 [tables] [N] [N]GB 去識別化/銷毀 依個資法 暫存/Log [tables] [N] [N]GB 直接刪除 無保留價值 附件/檔案 [storage] [N] [N]GB [遷移/封存/刪除] 4.2 資料封存規格 項目 內容 封存格式 [SQL dump / Parquet / CSV + Schema] 封存位置 [Cold Storage / Archive Vault] 加密方式 [AES-256 / 由保管庫管理] 存取方式 [申請制 / 限特定角色] 保留期限 [N] 年，到期後 [自動銷毀 / 覆審] 驗證方式 [Checksum / Restore test] 4.3 資料銷毀證明 銷毀項目 方式 執行日 執行人 驗證人 證明文件 [DB data] [TRUNCATE + VACUUM / Secure erase] [日期] [DBA] [資安] [存證編號] [File storage] [Secure delete / Disk wipe] [日期] [Infra] [資安] [存證編號] [Backup tapes] [Degauss / Physical destruction] [日期] [Infra] [資安] [存證編號] 5. 基礎設施釋放計畫 5.1 資源盤點 資源類型 名稱/ID 規格 月費 處置方式 預計釋放日 VM / 主機 [hostname/ID] [spec] $[N] [刪除/重新用途] [日期] Database [instance name] [spec] $[N] [刪除] [日期] Storage [bucket/share] [N]GB $[N] [資料移出後刪除] [日期] Load Balancer [name] — $[N] [刪除] [日期] DNS Record [domain] — — [刪除/轉向] [日期] SSL Certificate [CN] — — [不續約] [到期日] Monitoring [Dashboard/Alert] — — [刪除] [日期] 5.2 成本節約估計 項目 月費 年費 備註 計算資源 $[N] $[N] 儲存 $[N] $[N] 授權 (License) $[N] $[N] 維護合約 $[N] $[N] 合計節省 $[N] $[N] 6. 相依系統處理 6.1 上游系統（呼叫退役系統的系統） 來源系統 介接方式 呼叫頻率 處理方式 負責人 狀態 [System A] REST API [N] calls/day 切換至新系統 API [PM of A] [✅/❌] [System B] DB Link [N] queries/day 移除 DB Link [DBA] [✅/❌] 6.2 下游系統（退役系統呼叫的系統） 目標系統 介接方式 影響 處理方式 狀態 [System C] Event publish [訂閱者需取消] 通知訂閱者 [✅/❌] 6.3 共用元件 元件 共用者 可否移除 處理方式 [Shared DB] [系統列表] [否] [僅移除退役系統的 Schema] [Message Queue] [系統列表] [是/否] [移除 Topic / 保留] 7. 溝通計畫 時間點 對象 內容 方式 負責人 T - 90 天 所有使用者 退役預告 + 遷移指引 Email + 公告 PM T - 60 天 相依系統負責人 技術切換時程 會議 SA T - 30 天 所有使用者 最後提醒 + 進入唯讀期 Email + In-app PM T - 7 天 全體 最終通知 Email + Teams PM T day IT 團隊 執行退役 War Room RM T + 1 天 全體 退役完成通知 Email PM 8. 退役執行步驟 # 步驟 負責人 預估時間 前置條件 狀態 1 切換至唯讀模式 DevOps [N] min T-30d 通知完成 2 最終資料備份 DBA [N] hr 唯讀模式已啟用 3 驗證最終備份完整性 DBA [N] hr 備份完成 4 DNS 移除/轉向 Infra [N] min 5 停止應用程式服務 DevOps [N] min DNS 已處理 6 移除相依系統連線設定 SA/DevOps [N] hr 相依系統已切換 7 資料封存（法規保留） DBA [N] hr 備份驗證通過 8 資料銷毀（非保留資料） DBA/Infra [N] hr 封存完成 9 基礎設施釋放 Infra [N] hr 資料處置完成 10 監控/告警移除 SRE [N] min 服務已停止 11 文件更新（架構圖/CMDB） SA [N] hr 全部完成 12 退役完成確認 PM — 全部驗證通過 9. 驗證與確認 9.1 退役前驗證 # 驗證項目 方法 預期結果 狀態 1 新系統功能涵蓋率 UAT 驗收 100% 功能可替代 [✅/❌] 2 資料遷移完整性 Count + Sample 驗證 差異 = 0 [✅/❌] 3 相依系統已切換 連線測試 無對退役系統的呼叫 [✅/❌] 4 使用者已遷移 登入統計 活躍用戶 = 0 [✅/❌] 9.2 退役後驗證 # 驗證項目 方法 預期結果 狀態 1 舊系統不可存取 URL/IP 測試 Connection refused / 404 [✅/❌] 2 新系統運作正常 Smoke Test 全數通過 [✅/❌] 3 封存資料可存取 Restore 測試 資料完整可讀 [✅/❌] 4 無殘留資源 CMDB / Cloud Console 檢查 資源已清除 [✅/❌] 5 成本已停止計費 帳單確認 下月帳單減少 [✅/❌] 10. 風險與應變 # 風險 影響 機率 應變措施 1 使用者未完成遷移 業務中斷 Medium 延長唯讀期 + 人工協助 2 發現未識別的相依系統 相依系統異常 Medium 保留 DNS 轉向頁 30 天 3 法規保留期判定錯誤 合規風險 Low 法務覆審 + 寧可多保留 4 封存資料無法還原 資料遺失 Low 保留完整備份至驗證通過 5 退役後需要回溯查詢 業務查詢困難 Medium 建立簡易查詢介面 for 封存資料 11. 附錄 11.1 系統架構圖（退役前） [附上退役系統目前的架構圖，標示將移除的元件]\n","title":"系統退役計畫範本（System Retirement Plan Template）"},{"content":"系統需求規格書範本（System Requirements Document, SRD） 參照標準：ISO/IEC/IEEE 29148:2018（Systems and Software Engineering — Requirements Engineering）\n文件用途：定義系統層級的完整需求（功能、效能、安全、介面），作為設計與驗證的基準\n適用階段：需求分析階段（Requirements Phase）— System-Level Requirements\n📋 章節目錄 文件資訊 系統概述 系統功能需求 系統介面需求 效能需求 安全需求摘要 可靠性與可用性 限制條件 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SRD-{專案代碼}-{版本} 文件名稱 {系統名稱} 系統需求規格書 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 基線化 建立日期 {YYYY-MM-DD} 撰寫者 {系統分析師} 審核者 {Tech Lead / 架構師} 核准者 {PM / 產品負責人} 基線版本 {基線化日期，變更需走 CR 流程} 📖 使用說明 SRD 位於需求文件階層的中間層： BRD（商業需求）→ SRD（系統需求） → FRD（功能需求） SRD 將商業需求轉化為系統可實作的技術需求 「基線化」後的變更需經正式變更控制流程（Change Request） 依 ISO/IEC/IEEE 29148:2018 Section 6.2（System Requirements Specification） 💡 範例 項目 內容 文件編號 SRD-HRM-v1.0 系統名稱 人力資源管理系統（HRMS） 版本 v1.0 基線版本 2026-04-01（Sprint 10 結束） 2. 系統概述 📝 範本 2.1 系統目的 {描述系統存在的理由與欲解決的核心問題}\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/srd_template/","summary":"系統需求規格書範本（System Requirements Document, SRD） 參照標準：ISO/IEC/IEEE 29148:2018（Systems and Software Engineering — Requirements Engineering）\n文件用途：定義系統層級的完整需求（功能、效能、安全、介面），作為設計與驗證的基準\n適用階段：需求分析階段（Requirements Phase）— System-Level Requirements\n📋 章節目錄 文件資訊 系統概述 系統功能需求 系統介面需求 效能需求 安全需求摘要 可靠性與可用性 限制條件 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SRD-{專案代碼}-{版本} 文件名稱 {系統名稱} 系統需求規格書 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 基線化 建立日期 {YYYY-MM-DD} 撰寫者 {系統分析師} 審核者 {Tech Lead / 架構師} 核准者 {PM / 產品負責人} 基線版本 {基線化日期，變更需走 CR 流程} 📖 使用說明 SRD 位於需求文件階層的中間層： BRD（商業需求）→ SRD（系統需求） → FRD（功能需求） SRD 將商業需求轉化為系統可實作的技術需求 「基線化」後的變更需經正式變更控制流程（Change Request） 依 ISO/IEC/IEEE 29148:2018 Section 6.2（System Requirements Specification） 💡 範例 項目 內容 文件編號 SRD-HRM-v1.0 系統名稱 人力資源管理系統（HRMS） 版本 v1.0 基線版本 2026-04-01（Sprint 10 結束） 2. 系統概述 📝 範本 2.1 系統目的 {描述系統存在的理由與欲解決的核心問題}\n","title":"系統需求規格書範本（System Requirements Document Template）"},{"content":"變更日誌範本（CHANGELOG Template） 參照標準：Keep a Changelog 1.1.0 / Semantic Versioning 2.0.0\n文件用途：記錄專案每個版本的顯著變更，讓使用者與開發者了解版本間的差異\n適用階段：專案全生命週期（每次發版皆需更新）\n📋 章節目錄 文件資訊 格式規範 變更類別定義 版本編號規則 撰寫規範 CHANGELOG 完整範本 自動化產生 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 CHANGELOG.md 位置 專案根目錄 格式 Markdown（Keep a Changelog 格式） 維護者 {Release Manager / 開發團隊} 更新時機 每次版本發布（Release） 📖 使用說明 CHANGELOG.md 置於專案根目錄，與 README.md 並列 每次 Release 前更新，不是每個 Commit 都記錄 記錄「對使用者有意義的變更」，非所有技術細節 💡 範例 CHANGELOG.md 通常長這樣的開頭：\n# 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 節完整範本。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/project/changelog_template/","summary":"變更日誌範本（CHANGELOG Template） 參照標準：Keep a Changelog 1.1.0 / Semantic Versioning 2.0.0\n文件用途：記錄專案每個版本的顯著變更，讓使用者與開發者了解版本間的差異\n適用階段：專案全生命週期（每次發版皆需更新）\n📋 章節目錄 文件資訊 格式規範 變更類別定義 版本編號規則 撰寫規範 CHANGELOG 完整範本 自動化產生 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 CHANGELOG.md 位置 專案根目錄 格式 Markdown（Keep a Changelog 格式） 維護者 {Release Manager / 開發團隊} 更新時機 每次版本發布（Release） 📖 使用說明 CHANGELOG.md 置於專案根目錄，與 README.md 並列 每次 Release 前更新，不是每個 Commit 都記錄 記錄「對使用者有意義的變更」，非所有技術細節 💡 範例 CHANGELOG.md 通常長這樣的開頭：\n# 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 節完整範本。\n","title":"變更日誌範本（CHANGELOG Template）"},{"content":"資料庫設計文件範本（Database Design Document Template） 適用標準：ISO/IEC 11179（Metadata Registries）、DAMA DMBOK 2.0、ISO/IEC/IEEE 42010:2022\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、資料庫管理師（DBA）\n📑 章節目錄 文件資訊 資料庫架構概觀 實體關聯模型（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）之間的高階關係，不含欄位細節。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/databasedesign_template/","summary":"資料庫設計文件範本（Database Design Document Template） 適用標準：ISO/IEC 11179（Metadata Registries）、DAMA DMBOK 2.0、ISO/IEC/IEEE 42010:2022\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、資料庫管理師（DBA）\n📑 章節目錄 文件資訊 資料庫架構概觀 實體關聯模型（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）之間的高階關係，不含欄位細節。\n","title":"資料庫設計文件範本（Database Design Document Template）"},{"content":"資料遷移計畫範本（Data Migration Plan Template） 適用標準：ISO/IEC 25024（資料品質）、DAMA DMBOK 2.0（Data Management）\n適用階段：部署上線階段（Deployment Phase）\n負責角色：DBA、Data Engineer、SA、PM\n📑 章節目錄 文件資訊 遷移概要 來源與目標分析 遷移策略 資料映射規則 資料清洗與轉換規則 驗證策略 風險與應變 時程與里程碑 附錄 📝 範本 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 / \u0026hellip;] 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]\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/deployment/datamigrationplan_template/","summary":"資料遷移計畫範本（Data Migration Plan Template） 適用標準：ISO/IEC 25024（資料品質）、DAMA DMBOK 2.0（Data Management）\n適用階段：部署上線階段（Deployment Phase）\n負責角色：DBA、Data Engineer、SA、PM\n📑 章節目錄 文件資訊 遷移概要 來源與目標分析 遷移策略 資料映射規則 資料清洗與轉換規則 驗證策略 風險與應變 時程與里程碑 附錄 📝 範本 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 / \u0026hellip;] 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]\n","title":"資料遷移計畫範本（Data Migration Plan Template）"},{"content":"運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」\n文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序\n適用階段：營運維護階段（Operations \u0026amp; Maintenance）\n📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程\n版本 日期 修改人 修改內容 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 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/runbook_template/","summary":"運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」\n文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序\n適用階段：營運維護階段（Operations \u0026amp; Maintenance）\n📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程\n版本 日期 修改人 修改內容 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 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟：\n","title":"運維手冊範本（Runbook Template）"},{"content":"部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」\n文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程\n適用階段：部署與上線階段（Release \u0026amp; Deployment）\n📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程\n版本 日期 修改人 修改內容 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） 預估停機時間 零停機（流量切換時間 \u0026lt; 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 最新備份 \u0026lt; 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 \u0026gt; 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 \u0026quot;%{http_code}\u0026quot; https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {\u0026quot;status\u0026quot;:\u0026quot;healthy\u0026quot;} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {\u0026quot;status\u0026quot;:\u0026quot;connected\u0026quot;} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {\u0026quot;status\u0026quot;:\u0026quot;connected\u0026quot;} 同預期 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) \u0026lt; {ms} \u0026gt; {ms} {工具} Error Rate \u0026lt; {%} \u0026gt; {%} {工具} CPU 使用率 \u0026lt; {%} \u0026gt; {%} {工具} Memory 使用率 \u0026lt; {%} \u0026gt; {%} {工具} 活躍連線數 \u0026lt; {N} \u0026gt; {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 \u0026lt; 200ms \u0026gt; 500ms Grafana + Prometheus Error Rate (5xx) \u0026lt; 0.1% \u0026gt; 1% Azure Monitor CPU 使用率 \u0026lt; 60% \u0026gt; 85% Azure Monitor Memory 使用率 \u0026lt; 70% \u0026gt; 90% Azure Monitor Pod Restart Count 0 \u0026gt; 2 Kubernetes Dashboard DB Connection Pool \u0026lt; 80% \u0026gt; 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 📌 範本使用注意事項\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/operations/deployment_guide_template/","summary":"部署指南範本（Deployment Guide） 參照標準：ITIL 4 Release Management / ISO/IEC 20000-1:2018 第 8.5.2 節「Release management」\n文件用途：提供系統部署的標準化步驟指引，確保可重複、可追蹤、可回滾的部署流程\n適用階段：部署與上線階段（Release \u0026amp; Deployment）\n📋 章節目錄 文件資訊 部署概述 先決條件 部署架構 部署步驟 驗證程序 回滾程序 監控確認 聯絡窗口 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 DG-{專案代碼}-{序號} 文件名稱 {系統名稱} v{版本} 部署指南 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 計畫部署日期 {YYYY-MM-DD HH:mm} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 版本歷程\n版本 日期 修改人 修改內容 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） 預估停機時間 零停機（流量切換時間 \u0026lt; 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 最新備份 \u0026lt; 1 小時 ☑ Redis Cache 可連線 redis-cli ping 回應 PONG ☑ AD 連線正常 測試 LDAP bind ☑ Container Registry 映像已推送 az acr repository show-tags 確認 v1.0.0 存在 ☑ SSL 憑證效期 \u0026gt; 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 \u0026quot;%{http_code}\u0026quot; https://hrms.company.com 200 200 Pass 員工登入 使用測試帳號登入 成功進入首頁 成功 Pass 請假申請 建立一筆特休假申請 申請成功，狀態=待審核 成功 Pass 薪資查詢 查詢本月薪資明細 顯示薪資資料 成功 Pass 6.2 健康檢查 端點/服務 驗證指令 預期回應 實際回應 Pass/Fail API Health curl https://hrms-api.company.com/health {\u0026quot;status\u0026quot;:\u0026quot;healthy\u0026quot;} 同預期 Pass DB 連線 curl https://hrms-api.company.com/health/db {\u0026quot;status\u0026quot;:\u0026quot;connected\u0026quot;} 同預期 Pass Redis 連線 curl https://hrms-api.company.com/health/cache {\u0026quot;status\u0026quot;:\u0026quot;connected\u0026quot;} 同預期 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) \u0026lt; {ms} \u0026gt; {ms} {工具} Error Rate \u0026lt; {%} \u0026gt; {%} {工具} CPU 使用率 \u0026lt; {%} \u0026gt; {%} {工具} Memory 使用率 \u0026lt; {%} \u0026gt; {%} {工具} 活躍連線數 \u0026lt; {N} \u0026gt; {N} {工具} 8.3 日誌檢查項目 日誌類型 檢查重點 工具/指令 Application Log {重點} {工具} Access Log {重點} {工具} Error Log {重點} {工具} 📖 使用說明 部署後加強監控是確保部署穩定的最後一道防線 監控期間內若指標異常，仍可啟動回滾 建議部署後 24 小時為加強監控期，48 小時後轉為一般監控 💡 範例 8.2 關鍵監控指標 指標 正常範圍 告警門檻 監控工具 API P95 回應時間 \u0026lt; 200ms \u0026gt; 500ms Grafana + Prometheus Error Rate (5xx) \u0026lt; 0.1% \u0026gt; 1% Azure Monitor CPU 使用率 \u0026lt; 60% \u0026gt; 85% Azure Monitor Memory 使用率 \u0026lt; 70% \u0026gt; 90% Azure Monitor Pod Restart Count 0 \u0026gt; 2 Kubernetes Dashboard DB Connection Pool \u0026lt; 80% \u0026gt; 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 📌 範本使用注意事項\n","title":"部署指南範本（Deployment Guide Template）"},{"content":"需求異動申請表範本（Change Request Template） 適用標準：ISO/IEC/IEEE 15288:2023（系統生命週期）、ITIL 4 Change Management、CMMI\n適用階段：需求分析階段 / 全生命週期（Requirements Phase / Cross-Phase）\n負責角色：業務分析師（BA）、專案經理（PM）、變更管理委員會（CCB）\n📑 章節目錄 變更申請資訊 變更描述 影響分析 變更方案 審核與決議 實施追蹤 變更驗收 📝 範本 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[申請提出] --\u0026gt; B[影響分析] B --\u0026gt; C[CCB 審核] C --\u0026gt;|Approved| D[排入計畫] C --\u0026gt;|Rejected| E[結案通知] C --\u0026gt;|Deferred| F[暫緩追蹤] D --\u0026gt; G[實施變更] G --\u0026gt; H[驗證測試] H --\u0026gt; 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 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/requirements/changerequest_template/","summary":"需求異動申請表範本（Change Request Template） 適用標準：ISO/IEC/IEEE 15288:2023（系統生命週期）、ITIL 4 Change Management、CMMI\n適用階段：需求分析階段 / 全生命週期（Requirements Phase / Cross-Phase）\n負責角色：業務分析師（BA）、專案經理（PM）、變更管理委員會（CCB）\n📑 章節目錄 變更申請資訊 變更描述 影響分析 變更方案 審核與決議 實施追蹤 變更驗收 📝 範本 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[申請提出] --\u0026gt; B[影響分析] B --\u0026gt; C[CCB 審核] C --\u0026gt;|Approved| D[排入計畫] C --\u0026gt;|Rejected| E[結案通知] C --\u0026gt;|Deferred| F[暫緩追蹤] D --\u0026gt; G[實施變更] G --\u0026gt; H[驗證測試] H --\u0026gt; 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 緊急程度 一般 範例：變更描述 變更標題： 新增「彈性工時」假別類型與計算邏輯\n","title":"需求異動申請表範本（Change Request Template）"},{"content":"非功能性需求設計規格範本（NFR Design Specification Template） 適用標準：ISO/IEC 25010:2023（SQuaRE - 系統與軟體品質模型）、ISO/IEC/IEEE 29148:2018\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、效能工程師、SRE\n📑 章節目錄 文件資訊 品質屬性總覽 效能設計（Performance） 可用性設計（Availability） 延展性設計（Scalability） 可靠性設計（Reliability） 可維護性設計（Maintainability） 可觀測性設計（Observability） 安全性設計（Security） 相容性設計（Compatibility） 驗證與測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 非功能性需求設計規格 文件編號 [專案代碼]-NFR-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [SA 姓名] 審核者 [技術主管] 2. 品質屬性總覽 依 ISO/IEC 25010:2023 品質模型分類\n品質屬性 子特性 目標等級 優先級 驗證方式 效能效率 時間行為、資源利用、容量 [目標] [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） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 回應時間（P95） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 回應時間（P99） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 吞吐量（TPS） ≥ [N] ≥ [N] Load test 並發用戶 [N] [N] Load test 錯誤率 \u0026lt; [N]% \u0026lt; [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） \u0026lt; [N]s [N]s [✅/⚠️/❌] 最大內容繪製（LCP） \u0026lt; [N]s [N]s [✅/⚠️/❌] 累計版面偏移（CLS） \u0026lt; [N] [N] [✅/⚠️/❌] 互動至下一次繪製（INP） \u0026lt; [N]ms [N]ms [✅/⚠️/❌] JS Bundle Size \u0026lt; [N]KB [N]KB [✅/⚠️/❌] API Response Size \u0026lt; [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] 修復前置時間 [\u0026lt; 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 \u0026lt; 99.8% → Warning Latency (P95) [\u0026lt; 200ms] histogram_quantile(0.95) \u0026gt; 300ms → Warning Error Rate [\u0026lt; 0.1%] 5xx / total requests \u0026gt; 1% → Critical Throughput [≥ N TPS] rate(requests_total[5m]) \u0026lt; N*0.7 → Warning 9. 安全性設計（Security） 詳見安全設計文件（SecurityDesign_Template.md），此處僅摘要 NFR 指標\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/templates/design/nfr_design_template/","summary":"非功能性需求設計規格範本（NFR Design Specification Template） 適用標準：ISO/IEC 25010:2023（SQuaRE - 系統與軟體品質模型）、ISO/IEC/IEEE 29148:2018\n適用階段：系統設計階段（Design Phase）\n負責角色：系統架構師（SA）、效能工程師、SRE\n📑 章節目錄 文件資訊 品質屬性總覽 效能設計（Performance） 可用性設計（Availability） 延展性設計（Scalability） 可靠性設計（Reliability） 可維護性設計（Maintainability） 可觀測性設計（Observability） 安全性設計（Security） 相容性設計（Compatibility） 驗證與測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 非功能性需求設計規格 文件編號 [專案代碼]-NFR-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [SA 姓名] 審核者 [技術主管] 2. 品質屬性總覽 依 ISO/IEC 25010:2023 品質模型分類\n品質屬性 子特性 目標等級 優先級 驗證方式 效能效率 時間行為、資源利用、容量 [目標] [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） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 回應時間（P95） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 回應時間（P99） \u0026lt; [N]ms \u0026lt; [N]ms APM / Load test 吞吐量（TPS） ≥ [N] ≥ [N] Load test 並發用戶 [N] [N] Load test 錯誤率 \u0026lt; [N]% \u0026lt; [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） \u0026lt; [N]s [N]s [✅/⚠️/❌] 最大內容繪製（LCP） \u0026lt; [N]s [N]s [✅/⚠️/❌] 累計版面偏移（CLS） \u0026lt; [N] [N] [✅/⚠️/❌] 互動至下一次繪製（INP） \u0026lt; [N]ms [N]ms [✅/⚠️/❌] JS Bundle Size \u0026lt; [N]KB [N]KB [✅/⚠️/❌] API Response Size \u0026lt; [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] 修復前置時間 [\u0026lt; 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 \u0026lt; 99.8% → Warning Latency (P95) [\u0026lt; 200ms] histogram_quantile(0.95) \u0026gt; 300ms → Warning Error Rate [\u0026lt; 0.1%] 5xx / total requests \u0026gt; 1% → Critical Throughput [≥ N TPS] rate(requests_total[5m]) \u0026lt; N*0.7 → Warning 9. 安全性設計（Security） 詳見安全設計文件（SecurityDesign_Template.md），此處僅摘要 NFR 指標\n","title":"非功能性需求設計規格範本（NFR Design Specification Template）"},{"content":"Rust 1.x 完整企業級開發教學手冊 版本: 2.0\n最後更新: 2026 年 5 月 17 日 適用對象: 新手工程師、中階工程師、資深工程師、架構師、技術主管、DevOps 團隊\n技術層級: 初階 → 進階 → 架構師級\nRust 版本: 1.95.0 穩定版（Edition 2024）\n授權: 內部教育訓練使用\n參考來源: rust-lang.org、The Rust Book、crates.io、docs.rs、rustup.rs\n目錄 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[🟢 新手入門] --\u0026gt; B[🔵 基礎語法] B --\u0026gt; C[🟡 核心特色] C --\u0026gt; D[🟠 進階開發] D --\u0026gt; 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 是一門注重安全性、效能與並發性的現代系統級程式語言。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/rust-1.x-%E5%AE%8C%E6%95%B4%E4%BC%81%E6%A5%AD%E7%B4%9A%E9%96%8B%E7%99%BC%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Rust 1.x 完整企業級開發教學手冊 版本: 2.0\n最後更新: 2026 年 5 月 17 日 適用對象: 新手工程師、中階工程師、資深工程師、架構師、技術主管、DevOps 團隊\n技術層級: 初階 → 進階 → 架構師級\nRust 版本: 1.95.0 穩定版（Edition 2024）\n授權: 內部教育訓練使用\n參考來源: rust-lang.org、The Rust Book、crates.io、docs.rs、rustup.rs\n目錄 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[🟢 新手入門] --\u0026gt; B[🔵 基礎語法] B --\u0026gt; C[🟡 核心特色] C --\u0026gt; D[🟠 進階開發] D --\u0026gt; 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 是一門注重安全性、效能與並發性的現代系統級程式語言。\n","title":"Rust 1.x 完整企業級開發教學手冊"},{"content":"addyosmani/agent-skills 教學手冊 版本：v2.1.0（基於 agent-skills v0.6.2）\n更新日期：2026-07-02\n適用對象：資深工程師、架構師、Tech Lead、DevSecOps 工程師\n技術棧：addyosmani/agent-skills、Claude Code（Plugin Marketplace）、Cursor、Gemini CLI、GitHub Copilot、Antigravity、Spring Boot、Vue 3\n授權：MIT License\n參考來源：addyosmani/agent-skills（68,547+ stars，7,430 forks，約 39 位貢獻者，最新版本 v0.6.2）\n目錄 第 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 章：完整 24 個 Skills 深度解析 3.1 Meta 階段 3.2 Define 階段（定義需求） 3.3 Plan 階段（任務拆解） 3.4 Build 階段（增量實作） 3.5 Verify 階段（驗證品質） 3.6 Review 階段（合併前審查） 3.7 Ship 階段（部署上線） 第 4 章：四大 Persona 詳解 4.1 code-reviewer — 資深 Staff Engineer 4.2 test-engineer — QA 測試專家 4.3 security-auditor — 資安工程師 4.4 web-performance-auditor — Web 效能稽核專家（v0.6.x 新增） 4.5 Persona 與 Skill 的互動規則 4.6 自定義 Persona 第 5 章：8 個 Slash Commands 詳解 5.1 Commands → Skills 映射總覽 5.2 各 Command 詳解 第 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 — 協調模式參考 6.6 definition-of-done.md — 完成定義清單（v0.6.x 新增） 6.7 observability-checklist.md — 可觀測性查核清單（v0.6.x 新增） 第 7 章：Google 工程實踐在 Agent Skills 中的應用 7.1 Hyrum\u0026rsquo;s Law（海勒姆定律） 7.2 Beyoncé Rule（碧昂絲法則） 7.3 Chesterton\u0026rsquo;s Fence（乞斯特頓柵欄） 7.4 Code-as-Liability（程式碼即負債） 7.5 Shift Left（左移） 7.6 Small Changes（小批量變更） 7.7 Faster is Safer（快即安全） 7.8 Readability（可讀性） 第 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 Antigravity IDE \u0026amp; CLI 8.9 Codex / 其他 Agents 8.10 安裝後驗證 8.11 多工具共存 第 9 章：SSDLC（安全軟體開發生命週期）整合 9.1 什麼是 SSDLC 9.2 SSDLC × Agent Skills 映射 9.3 各 SSDLC 階段的 Agent Skills 實踐 9.4 合規對應 第 10 章：AI Agent Team 協作指南 10.1 概念：AI Agent 即團隊成員 10.2 AI Agent Team 協作模型 10.3 角色分工 10.4 溝通協議 10.5 Agent Teams（實驗性功能） 10.6 不同團隊規模的採用策略 第 11 章：實戰案例 — Web Application 開發 11.1 專案背景 11.2 Phase 1：需求定義（Define） 11.3 Phase 2：任務拆解（Plan） 11.4 Phase 3：增量實作（Build） 11.5 Phase 4：審查與上線（Review → Ship） 第 12 章：實戰案例 — 框架升級遷移 12.1 場景：Java EE 8 → Jakarta EE 10 12.2 場景：Spring Boot 2.x → 3.x 升級 第 13 章：實戰案例 — 逆向工程與遺留系統分析 13.1 場景：分析未文件化的遺留系統 13.2 分析流程 13.3 Legacy System 現代化 第 14 章：安全治理與合規 14.1 三層邊界系統深入解析 14.2 OWASP SAMM 對照 14.3 ISO 27001 對照 14.4 金融 / 保險 / 政府合規建議 14.5 Prompt Injection 防護 第 15 章：CI/CD 與 DevSecOps 整合 15.1 Agent Skills 在 CI/CD Pipeline 中的定位 15.2 GitHub Actions 整合範例 15.3 Pre-Commit Hook 整合 15.4 品質閘門定義 15.5 Feature Flag 生命週期 第 16 章：Context Engineering 進階指南 16.1 Context 的本質 16.2 五層 Context 階層詳解 16.3 MCP（Model Context Protocol）整合 16.4 Token 效率策略 16.5 Session 管理策略 16.6 Anti-Hallucination 策略 第 17 章：測試策略深入解析 17.1 測試金字塔實踐 17.2 Red-Green-Refactor 循環 17.3 Mock 使用原則 第 18 章：Hooks 與 Session 管理 18.1 Hooks 概述 18.2 session-start.sh 詳解 18.3 SDD Cache Hooks 18.4 自訂 Hooks 第 19 章：自訂 Skill 開發指南 19.1 何時需要自訂 Skill 19.2 Skill Anatomy 完整規格 19.3 SKILL.md 完整範本 19.4 寫作原則對照 19.5 將自訂 Skill 加入專案 第 20 章：企業導入指南 20.1 導入路線圖 20.2 Phase 1：評估與準備 20.3 Phase 2：Pilot 導入 20.4 Phase 3：擴大導入 20.5 Phase 4：持續改善 20.6 AI Governance 治理機制 20.7 合規考量 第 21 章：最佳實踐總結 21.1 日常開發最佳實踐 21.2 團隊協作最佳實踐 21.3 安全最佳實踐 第 22 章：Anti-Patterns（反模式） 22.1 開發流程反模式 22.2 安全反模式 22.3 AI 協作反模式 第 23 章：Troubleshooting（疑難排解） 23.1 常見問題與解決方案 第 24 章：常見問題 FAQ 24.1 基礎概念 24.2 安裝與設定 24.3 使用方式 24.4 進階使用 24.5 安全與合規 24.6 社群與貢獻 第 25 章：附錄 附錄 A：速查參考表 附錄 B：Rules File 範本 附錄 C：GitHub Actions 完整範例 附錄 D：7 個 Checklists 速查 附錄 E：詞彙表 附錄 F：導入 Checklist 第 1 章：前言與概觀 1.1 addyosmani/agent-skills 是什麼 addyosmani/agent-skills 是由 Google Chrome 團隊工程主管 Addy Osmani 發起的開源專案，核心目的是將**資深軟體工程師的開發紀律與標準作業程序（SOP）**轉化為結構化的 Markdown 框架，用以約束並提升 AI 程式碼生成代理（AI Coding Agents）的交付品質。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/addyosmani-agent-skills-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"addyosmani/agent-skills 教學手冊 版本：v2.1.0（基於 agent-skills v0.6.2）\n更新日期：2026-07-02\n適用對象：資深工程師、架構師、Tech Lead、DevSecOps 工程師\n技術棧：addyosmani/agent-skills、Claude Code（Plugin Marketplace）、Cursor、Gemini CLI、GitHub Copilot、Antigravity、Spring Boot、Vue 3\n授權：MIT License\n參考來源：addyosmani/agent-skills（68,547+ stars，7,430 forks，約 39 位貢獻者，最新版本 v0.6.2）\n目錄 第 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 章：完整 24 個 Skills 深度解析 3.1 Meta 階段 3.2 Define 階段（定義需求） 3.3 Plan 階段（任務拆解） 3.4 Build 階段（增量實作） 3.5 Verify 階段（驗證品質） 3.6 Review 階段（合併前審查） 3.7 Ship 階段（部署上線） 第 4 章：四大 Persona 詳解 4.1 code-reviewer — 資深 Staff Engineer 4.2 test-engineer — QA 測試專家 4.3 security-auditor — 資安工程師 4.4 web-performance-auditor — Web 效能稽核專家（v0.6.x 新增） 4.5 Persona 與 Skill 的互動規則 4.6 自定義 Persona 第 5 章：8 個 Slash Commands 詳解 5.1 Commands → Skills 映射總覽 5.2 各 Command 詳解 第 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 — 協調模式參考 6.6 definition-of-done.md — 完成定義清單（v0.6.x 新增） 6.7 observability-checklist.md — 可觀測性查核清單（v0.6.x 新增） 第 7 章：Google 工程實踐在 Agent Skills 中的應用 7.1 Hyrum\u0026rsquo;s Law（海勒姆定律） 7.2 Beyoncé Rule（碧昂絲法則） 7.3 Chesterton\u0026rsquo;s Fence（乞斯特頓柵欄） 7.4 Code-as-Liability（程式碼即負債） 7.5 Shift Left（左移） 7.6 Small Changes（小批量變更） 7.7 Faster is Safer（快即安全） 7.8 Readability（可讀性） 第 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 Antigravity IDE \u0026amp; CLI 8.9 Codex / 其他 Agents 8.10 安裝後驗證 8.11 多工具共存 第 9 章：SSDLC（安全軟體開發生命週期）整合 9.1 什麼是 SSDLC 9.2 SSDLC × Agent Skills 映射 9.3 各 SSDLC 階段的 Agent Skills 實踐 9.4 合規對應 第 10 章：AI Agent Team 協作指南 10.1 概念：AI Agent 即團隊成員 10.2 AI Agent Team 協作模型 10.3 角色分工 10.4 溝通協議 10.5 Agent Teams（實驗性功能） 10.6 不同團隊規模的採用策略 第 11 章：實戰案例 — Web Application 開發 11.1 專案背景 11.2 Phase 1：需求定義（Define） 11.3 Phase 2：任務拆解（Plan） 11.4 Phase 3：增量實作（Build） 11.5 Phase 4：審查與上線（Review → Ship） 第 12 章：實戰案例 — 框架升級遷移 12.1 場景：Java EE 8 → Jakarta EE 10 12.2 場景：Spring Boot 2.x → 3.x 升級 第 13 章：實戰案例 — 逆向工程與遺留系統分析 13.1 場景：分析未文件化的遺留系統 13.2 分析流程 13.3 Legacy System 現代化 第 14 章：安全治理與合規 14.1 三層邊界系統深入解析 14.2 OWASP SAMM 對照 14.3 ISO 27001 對照 14.4 金融 / 保險 / 政府合規建議 14.5 Prompt Injection 防護 第 15 章：CI/CD 與 DevSecOps 整合 15.1 Agent Skills 在 CI/CD Pipeline 中的定位 15.2 GitHub Actions 整合範例 15.3 Pre-Commit Hook 整合 15.4 品質閘門定義 15.5 Feature Flag 生命週期 第 16 章：Context Engineering 進階指南 16.1 Context 的本質 16.2 五層 Context 階層詳解 16.3 MCP（Model Context Protocol）整合 16.4 Token 效率策略 16.5 Session 管理策略 16.6 Anti-Hallucination 策略 第 17 章：測試策略深入解析 17.1 測試金字塔實踐 17.2 Red-Green-Refactor 循環 17.3 Mock 使用原則 第 18 章：Hooks 與 Session 管理 18.1 Hooks 概述 18.2 session-start.sh 詳解 18.3 SDD Cache Hooks 18.4 自訂 Hooks 第 19 章：自訂 Skill 開發指南 19.1 何時需要自訂 Skill 19.2 Skill Anatomy 完整規格 19.3 SKILL.md 完整範本 19.4 寫作原則對照 19.5 將自訂 Skill 加入專案 第 20 章：企業導入指南 20.1 導入路線圖 20.2 Phase 1：評估與準備 20.3 Phase 2：Pilot 導入 20.4 Phase 3：擴大導入 20.5 Phase 4：持續改善 20.6 AI Governance 治理機制 20.7 合規考量 第 21 章：最佳實踐總結 21.1 日常開發最佳實踐 21.2 團隊協作最佳實踐 21.3 安全最佳實踐 第 22 章：Anti-Patterns（反模式） 22.1 開發流程反模式 22.2 安全反模式 22.3 AI 協作反模式 第 23 章：Troubleshooting（疑難排解） 23.1 常見問題與解決方案 第 24 章：常見問題 FAQ 24.1 基礎概念 24.2 安裝與設定 24.3 使用方式 24.4 進階使用 24.5 安全與合規 24.6 社群與貢獻 第 25 章：附錄 附錄 A：速查參考表 附錄 B：Rules File 範本 附錄 C：GitHub Actions 完整範例 附錄 D：7 個 Checklists 速查 附錄 E：詞彙表 附錄 F：導入 Checklist 第 1 章：前言與概觀 1.1 addyosmani/agent-skills 是什麼 addyosmani/agent-skills 是由 Google Chrome 團隊工程主管 Addy Osmani 發起的開源專案，核心目的是將**資深軟體工程師的開發紀律與標準作業程序（SOP）**轉化為結構化的 Markdown 框架，用以約束並提升 AI 程式碼生成代理（AI Coding Agents）的交付品質。\n","title":"Addyosmani Agent Skills 教學手冊"},{"content":"mattpocock/skills 教學手冊 使用 mattpocock/skills 建構企業級 AI Coding Agent 工程治理平台\n項目 說明 版本 v4.0.0 更新日期 2026-07-22 適用對象 資深工程師、架構師、Tech Lead、DevSecOps 工程師、AI 導入推動者 技術棧 mattpocock/skills（CHANGELOG v1.1.0／plugin.json v1.2.0）、Claude Code / Codex 等 Coding Agent、skills.sh 生態系、agentskills.io 開放標準、CONTEXT.md、ADR 參考來源 mattpocock/skills GitHub（180,641 stars、15,434 forks，MIT License，GitHub API 查證於 2026-07-22） 前置知識 AI Coding Agent 基本操作、Git 版本控制、基礎軟體工程概念 版本說明：本次改版（v4.0.0）已針對 mattpocock/skills v1.1.0（2026-07-08 發布）的重大重構逐項核對原始碼（SKILL.md、.claude-plugin/plugin.json、CHANGELOG.md），其中最關鍵的變動是：to-prd 更名為 to-spec、to-issues 與已刪除的 to-plan 合併為 to-tickets、wayfinder（原名 decision-mapping）由實驗性的 in-progress 轉正為正式 Engineering Skill、新增可背景執行的調研 Skill research、resolving-merge-conflicts 結束過渡期首次正式收錄進 plugin.json。另需留意：.claude-plugin/plugin.json 的版號（1.2.0）目前領先於 package.json／CHANGELOG 記載的正式版本（1.1.0），兩者尚未對齊，屬治理上的落差，詳見第 24.6 節版本紀錄與第 23 章 FAQ。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/mattpocock-skills-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"mattpocock/skills 教學手冊 使用 mattpocock/skills 建構企業級 AI Coding Agent 工程治理平台\n項目 說明 版本 v4.0.0 更新日期 2026-07-22 適用對象 資深工程師、架構師、Tech Lead、DevSecOps 工程師、AI 導入推動者 技術棧 mattpocock/skills（CHANGELOG v1.1.0／plugin.json v1.2.0）、Claude Code / Codex 等 Coding Agent、skills.sh 生態系、agentskills.io 開放標準、CONTEXT.md、ADR 參考來源 mattpocock/skills GitHub（180,641 stars、15,434 forks，MIT License，GitHub API 查證於 2026-07-22） 前置知識 AI Coding Agent 基本操作、Git 版本控制、基礎軟體工程概念 版本說明：本次改版（v4.0.0）已針對 mattpocock/skills v1.1.0（2026-07-08 發布）的重大重構逐項核對原始碼（SKILL.md、.claude-plugin/plugin.json、CHANGELOG.md），其中最關鍵的變動是：to-prd 更名為 to-spec、to-issues 與已刪除的 to-plan 合併為 to-tickets、wayfinder（原名 decision-mapping）由實驗性的 in-progress 轉正為正式 Engineering Skill、新增可背景執行的調研 Skill research、resolving-merge-conflicts 結束過渡期首次正式收錄進 plugin.json。另需留意：.claude-plugin/plugin.json 的版號（1.2.0）目前領先於 package.json／CHANGELOG 記載的正式版本（1.1.0），兩者尚未對齊，屬治理上的落差，詳見第 24.6 節版本紀錄與第 23 章 FAQ。\n","title":"Mattpocock Skills 教學手冊"},{"content":"Quarkus 3.x 教學手冊 項目 說明 文件名稱 Quarkus 3.x 教學手冊 文件版本 v1.0.0 Quarkus 版本 3.35.x（2026 年 5 月最新穩定版） 最後更新日期 2026-05-15 撰寫角色 資深軟體架構師 / 資深 Java 雲原生開發工程師 / DevSecOps 架構師 / AI 架構師 目標對象 Java 後端工程師、架構師、DevOps 工程師、技術主管 前置知識 Java 17+、Maven 基礎、REST API 概念、Docker 基礎、Git 版本控制 適用場景 企業內訓教材、技術白皮書、架構設計參考、新人訓練、維運指引 授權方式 內部使用 前言 Quarkus 是由 Red Hat 發起、現歸屬 Commonhaus Foundation 的開源 Java 框架，專為 Kubernetes、Serverless 與雲原生環境量身打造。官方稱之為「超音速、亞原子的 Java」（Supersonic Subatomic Java），其核心目標是大幅降低 Java 應用的記憶體消耗、加速啟動時間，使 Java 成為容器化時代的首選語言。\nQuarkus 3.x 系列在 Jakarta EE 10+ 規範基礎上，融合 MicroProfile、Vert.x、Hibernate 等成熟技術，透過獨特的「編譯期啟動優化」（Compile Time Boot）策略，將傳統在執行期才完成的依賴注入、配置解析與中繼資料處理，提前至建置階段完成。這使得應用程式在 JVM 模式下即可快速啟動，搭配 GraalVM Native Image 更可達到毫秒級啟動與極低記憶體消耗。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/quarkus-3.x-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Quarkus 3.x 教學手冊 項目 說明 文件名稱 Quarkus 3.x 教學手冊 文件版本 v1.0.0 Quarkus 版本 3.35.x（2026 年 5 月最新穩定版） 最後更新日期 2026-05-15 撰寫角色 資深軟體架構師 / 資深 Java 雲原生開發工程師 / DevSecOps 架構師 / AI 架構師 目標對象 Java 後端工程師、架構師、DevOps 工程師、技術主管 前置知識 Java 17+、Maven 基礎、REST API 概念、Docker 基礎、Git 版本控制 適用場景 企業內訓教材、技術白皮書、架構設計參考、新人訓練、維運指引 授權方式 內部使用 前言 Quarkus 是由 Red Hat 發起、現歸屬 Commonhaus Foundation 的開源 Java 框架，專為 Kubernetes、Serverless 與雲原生環境量身打造。官方稱之為「超音速、亞原子的 Java」（Supersonic Subatomic Java），其核心目標是大幅降低 Java 應用的記憶體消耗、加速啟動時間，使 Java 成為容器化時代的首選語言。\nQuarkus 3.x 系列在 Jakarta EE 10+ 規範基礎上，融合 MicroProfile、Vert.x、Hibernate 等成熟技術，透過獨特的「編譯期啟動優化」（Compile Time Boot）策略，將傳統在執行期才完成的依賴注入、配置解析與中繼資料處理，提前至建置階段完成。這使得應用程式在 JVM 模式下即可快速啟動，搭配 GraalVM Native Image 更可達到毫秒級啟動與極低記憶體消耗。\n","title":"Quarkus 3.x 教學手冊"},{"content":"Jakarta EE 12 教學手冊 文件資訊 項目 說明 文件名稱 Jakarta EE 12 教學手冊 版本 2.0.0 更新日期 2026-05-14 作者 架構團隊 目標對象 Java 後端工程師、架構師、DevOps 工程師、Tech Lead 前置知識 Java SE 基礎、Maven 基礎、SQL 基礎、HTTP 協定基礎 Jakarta EE 12 狀態 開發中（WIP），預計 2026 年下半年正式發布 Java 最低版本 Java SE 21 官方網站 jakarta.ee 規格發布頁 Jakarta EE 12 Release 目錄 Jakarta EE 12 概觀 1.1 Jakarta EE 歷史與演進 1.2 Jakarta EE 12 定位 — Data Age 1.3 Jakarta EE 12 核心特色 1.4 Jakarta EE 12 治理模式與社群驅動 1.5 與 Spring Boot 比較 1.6 適合與不適合的應用場景 1.7 實務注意事項 Jakarta EE 12 核心架構 2.1 Platform、Web Profile、Core Profile 2.2 模組化架構與規格關係圖 2.3 Jakarta EE Runtime 2.4 Jakarta EE 12 完整規格清單 2.5 候選與前瞻規格 2.6 TCK 認證與相容實作 2.7 實務注意事項 Java 21 與 Java 25 3.1 為何 Jakarta EE 12 要求 Java 21 3.2 Virtual Thread（虛擬執行緒） 3.3 Structured Concurrency（結構化並行） 3.4 Record 與 Pattern Matching 3.5 Sequenced Collection 與 Scoped Values 3.6 Java 25 新特性 3.7 JVM 調校建議 3.8 實務注意事項 開發環境建置 4.1 JDK 21 安裝 4.2 Maven 與 Gradle 安裝 4.3 IDE 設定 — VS Code 與 IntelliJ IDEA 4.4 Docker Desktop 與 Podman 4.5 Kubernetes 與 kubectl 4.6 Jakarta EE Starter 快速建立 4.7 實務注意事項 Jakarta EE 12 Application Server 5.1 Open Liberty 5.2 Payara 5.3 WildFly 5.4 GlassFish 5.5 四大 Server 比較表 5.6 選型建議 5.7 實務注意事項 Maven 專案建立 6.1 Multi Module 專案架構 6.2 Parent POM 設計 6.3 各層模組 POM 6.4 dependencyManagement 與 pluginManagement 6.5 Maven Archetype 6.6 實務注意事項 Clean Architecture 7.1 Domain Driven Design（DDD） 7.2 Hexagonal Architecture 7.3 Clean Architecture 原則 7.4 Ports and Adapters 7.5 Repository Pattern 與 Service Layer 7.6 完整專案目錄結構 7.7 實務注意事項 Jakarta CDI 5.0 8.1 Dependency Injection 基礎 8.2 Bean Scope 8.3 Eager Initialization 8.4 Producer 與 Qualifier 8.5 Interceptor 與 Decorator 8.6 Event 機制 8.7 BuildCompatibleExtension 8.8 實務注意事項 Jakarta RESTful Web Services 5.0 9.1 REST API 設計原則 9.2 JSON-B 3.1 與資料綁定 9.3 Bean Validation 4.0 9.4 Exception Handling 9.5 CRUD API 完整實作 9.6 分頁、排序與過濾 9.7 OpenAPI 整合 9.8 JWT Security 9.9 實務注意事項 Jakarta Persistence 4.0 10.1 JPA 核心概念 10.2 Entity 設計 10.3 Repository Pattern 實作 10.4 Transaction 管理 10.5 Lock 策略 10.6 Lazy Loading 與效能 10.7 Query 最佳化 10.8 實務注意事項 Jakarta Data 1.1 11.1 Jakarta Query 1.0 統一查詢語言 11.2 Fluent Query 與動態限制條件 11.3 Repository 抽象化與狀態管理 11.4 Record Projection 與 NoSQL 支援 11.5 與 Spring Data JPA 比較 11.6 實務注意事項 Jakarta Security 5.0 12.1 Security 5.0 架構重構 12.2 JWT 實作 12.3 OAuth2 與 OpenID Connect 12.4 RBAC 角色存取控制與 Permission Store 12.5 多重認證機制 12.6 API Security 12.7 OWASP Top 10 防護 12.8 Secure Coding 實務 12.9 實務注意事項 Jakarta Concurrency 3.2 13.1 ManagedExecutorService 13.2 Async Processing 13.3 Virtual Thread 整合 13.4 高併發設計模式 13.5 實務注意事項 Jakarta Batch 2.2 14.1 批次架構概觀 14.2 Job 與 Step 設計 14.3 Chunk Processing 14.4 Retry 與 Skip 策略 14.5 Parallel Processing 14.6 實務注意事項 Cache 與 MQ 15.1 Redis 整合 15.2 Kafka 整合 15.3 RabbitMQ 整合 15.4 Jakarta Messaging 3.1 15.5 實務注意事項 Kubernetes 與雲原生 16.1 Dockerfile 設計 16.2 Kubernetes Deployment 16.3 Service 與 Ingress 16.4 ConfigMap 與 Secret 16.5 HPA 與 Rolling Update 16.6 HTTP/3 支援 16.7 實務注意事項 MicroProfile 與 Jakarta Config 17.1 Config 17.2 Jakarta Config 1.0（候選） 17.3 Health 17.4 Metrics 17.5 OpenAPI 17.6 JWT Propagation 17.7 Fault Tolerance 17.8 實務注意事項 CI/CD 18.1 GitHub Actions 18.2 Jenkins Pipeline 18.3 SonarQube 整合 18.4 Trivy 與 OWASP Dependency Check 18.5 SBOM 產生與 CRA 合規 18.6 實務注意事項 SSDLC 19.1 Secure SDLC 概觀 19.2 SAST 靜態分析 19.3 DAST 動態測試 19.4 Dependency Scan 19.5 Container Scan 與 Secret Scan 19.6 實務注意事項 AI 協作開發 20.1 Jakarta Agentic AI 1.0（前瞻規格） 20.2 GitHub Copilot 整合 20.3 Claude 與 ChatGPT 協作 20.4 Gemini 整合 20.5 AI 輔助開發工作流 20.6 實務注意事項 Monitoring 與維運 21.1 Prometheus 監控 21.2 Grafana 視覺化 21.3 ELK Stack 21.4 OpenTelemetry 與 Distributed Tracing 21.5 實務注意事項 Testing 22.1 JUnit 5 22.2 Mockito 22.3 Testcontainers 22.4 Integration Test 22.5 API Test 22.6 實務注意事項 Migration 23.1 Java EE → Jakarta EE 23.2 Jakarta EE 10/11 → Jakarta EE 12 23.3 Spring Boot → Jakarta EE 23.4 Eclipse Transformer 工具 23.5 實務注意事項 大型企業最佳實務 24.1 銀行業案例 24.2 保險業案例 24.3 電商平台案例 24.4 政府系統案例 24.5 SaaS 平台案例 24.6 實務注意事項 團隊建立指南 25.1 Team Topology 25.2 技能矩陣與學習路線 25.3 培訓方式與 Code Review 規範 25.4 實務注意事項 DevSecOps 與 Git Flow 26.1 Branch Strategy 26.2 Git Flow vs Trunk Based Development 26.3 Release Strategy 26.4 實務注意事項 上線與維運 27.1 Production Deployment 27.2 Blue-Green 與 Canary 部署 27.3 Rollback 策略 27.4 DR、Backup 與 HA 27.5 實務注意事項 效能調校 28.1 JVM Tuning 28.2 GC Tuning 28.3 Connection Pool 調校 28.4 SQL Optimization 28.5 Thread Pool 設計 28.6 實務注意事項 常見問題 FAQ Troubleshooting 30.1 啟動問題 30.2 記憶體問題 30.3 Kubernetes 問題 30.4 JDBC 問題 30.5 Transaction 問題 Appendix 31.1 完整 Parent POM 31.2 Dockerfile 31.3 docker-compose.yml 31.4 Kubernetes YAML 31.5 GitHub Actions YAML 31.6 Jenkinsfile 31.7 Logging Configuration Jakarta EE 12 框架比較 32.1 Jakarta EE 12 vs Spring Boot 4 32.2 Jakarta EE 12 vs Quarkus 32.3 Jakarta EE 12 vs Micronaut 32.4 Jakarta EE 12 vs Helidon 32.5 選型建議 檢查清單（Checklist） 1. Jakarta EE 12 概觀 1.1 Jakarta EE 歷史與演進 從 J2EE 到 Jakarta EE 的二十年旅程 企業級 Java 的歷史可以追溯到 1999 年 Sun Microsystems 推出的 J2EE（Java 2 Platform, Enterprise Edition）。這二十多年的演進歷程，是理解 Jakarta EE 12 定位的關鍵脈絡。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/jakarta-ee-12-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Jakarta EE 12 教學手冊 文件資訊 項目 說明 文件名稱 Jakarta EE 12 教學手冊 版本 2.0.0 更新日期 2026-05-14 作者 架構團隊 目標對象 Java 後端工程師、架構師、DevOps 工程師、Tech Lead 前置知識 Java SE 基礎、Maven 基礎、SQL 基礎、HTTP 協定基礎 Jakarta EE 12 狀態 開發中（WIP），預計 2026 年下半年正式發布 Java 最低版本 Java SE 21 官方網站 jakarta.ee 規格發布頁 Jakarta EE 12 Release 目錄 Jakarta EE 12 概觀 1.1 Jakarta EE 歷史與演進 1.2 Jakarta EE 12 定位 — Data Age 1.3 Jakarta EE 12 核心特色 1.4 Jakarta EE 12 治理模式與社群驅動 1.5 與 Spring Boot 比較 1.6 適合與不適合的應用場景 1.7 實務注意事項 Jakarta EE 12 核心架構 2.1 Platform、Web Profile、Core Profile 2.2 模組化架構與規格關係圖 2.3 Jakarta EE Runtime 2.4 Jakarta EE 12 完整規格清單 2.5 候選與前瞻規格 2.6 TCK 認證與相容實作 2.7 實務注意事項 Java 21 與 Java 25 3.1 為何 Jakarta EE 12 要求 Java 21 3.2 Virtual Thread（虛擬執行緒） 3.3 Structured Concurrency（結構化並行） 3.4 Record 與 Pattern Matching 3.5 Sequenced Collection 與 Scoped Values 3.6 Java 25 新特性 3.7 JVM 調校建議 3.8 實務注意事項 開發環境建置 4.1 JDK 21 安裝 4.2 Maven 與 Gradle 安裝 4.3 IDE 設定 — VS Code 與 IntelliJ IDEA 4.4 Docker Desktop 與 Podman 4.5 Kubernetes 與 kubectl 4.6 Jakarta EE Starter 快速建立 4.7 實務注意事項 Jakarta EE 12 Application Server 5.1 Open Liberty 5.2 Payara 5.3 WildFly 5.4 GlassFish 5.5 四大 Server 比較表 5.6 選型建議 5.7 實務注意事項 Maven 專案建立 6.1 Multi Module 專案架構 6.2 Parent POM 設計 6.3 各層模組 POM 6.4 dependencyManagement 與 pluginManagement 6.5 Maven Archetype 6.6 實務注意事項 Clean Architecture 7.1 Domain Driven Design（DDD） 7.2 Hexagonal Architecture 7.3 Clean Architecture 原則 7.4 Ports and Adapters 7.5 Repository Pattern 與 Service Layer 7.6 完整專案目錄結構 7.7 實務注意事項 Jakarta CDI 5.0 8.1 Dependency Injection 基礎 8.2 Bean Scope 8.3 Eager Initialization 8.4 Producer 與 Qualifier 8.5 Interceptor 與 Decorator 8.6 Event 機制 8.7 BuildCompatibleExtension 8.8 實務注意事項 Jakarta RESTful Web Services 5.0 9.1 REST API 設計原則 9.2 JSON-B 3.1 與資料綁定 9.3 Bean Validation 4.0 9.4 Exception Handling 9.5 CRUD API 完整實作 9.6 分頁、排序與過濾 9.7 OpenAPI 整合 9.8 JWT Security 9.9 實務注意事項 Jakarta Persistence 4.0 10.1 JPA 核心概念 10.2 Entity 設計 10.3 Repository Pattern 實作 10.4 Transaction 管理 10.5 Lock 策略 10.6 Lazy Loading 與效能 10.7 Query 最佳化 10.8 實務注意事項 Jakarta Data 1.1 11.1 Jakarta Query 1.0 統一查詢語言 11.2 Fluent Query 與動態限制條件 11.3 Repository 抽象化與狀態管理 11.4 Record Projection 與 NoSQL 支援 11.5 與 Spring Data JPA 比較 11.6 實務注意事項 Jakarta Security 5.0 12.1 Security 5.0 架構重構 12.2 JWT 實作 12.3 OAuth2 與 OpenID Connect 12.4 RBAC 角色存取控制與 Permission Store 12.5 多重認證機制 12.6 API Security 12.7 OWASP Top 10 防護 12.8 Secure Coding 實務 12.9 實務注意事項 Jakarta Concurrency 3.2 13.1 ManagedExecutorService 13.2 Async Processing 13.3 Virtual Thread 整合 13.4 高併發設計模式 13.5 實務注意事項 Jakarta Batch 2.2 14.1 批次架構概觀 14.2 Job 與 Step 設計 14.3 Chunk Processing 14.4 Retry 與 Skip 策略 14.5 Parallel Processing 14.6 實務注意事項 Cache 與 MQ 15.1 Redis 整合 15.2 Kafka 整合 15.3 RabbitMQ 整合 15.4 Jakarta Messaging 3.1 15.5 實務注意事項 Kubernetes 與雲原生 16.1 Dockerfile 設計 16.2 Kubernetes Deployment 16.3 Service 與 Ingress 16.4 ConfigMap 與 Secret 16.5 HPA 與 Rolling Update 16.6 HTTP/3 支援 16.7 實務注意事項 MicroProfile 與 Jakarta Config 17.1 Config 17.2 Jakarta Config 1.0（候選） 17.3 Health 17.4 Metrics 17.5 OpenAPI 17.6 JWT Propagation 17.7 Fault Tolerance 17.8 實務注意事項 CI/CD 18.1 GitHub Actions 18.2 Jenkins Pipeline 18.3 SonarQube 整合 18.4 Trivy 與 OWASP Dependency Check 18.5 SBOM 產生與 CRA 合規 18.6 實務注意事項 SSDLC 19.1 Secure SDLC 概觀 19.2 SAST 靜態分析 19.3 DAST 動態測試 19.4 Dependency Scan 19.5 Container Scan 與 Secret Scan 19.6 實務注意事項 AI 協作開發 20.1 Jakarta Agentic AI 1.0（前瞻規格） 20.2 GitHub Copilot 整合 20.3 Claude 與 ChatGPT 協作 20.4 Gemini 整合 20.5 AI 輔助開發工作流 20.6 實務注意事項 Monitoring 與維運 21.1 Prometheus 監控 21.2 Grafana 視覺化 21.3 ELK Stack 21.4 OpenTelemetry 與 Distributed Tracing 21.5 實務注意事項 Testing 22.1 JUnit 5 22.2 Mockito 22.3 Testcontainers 22.4 Integration Test 22.5 API Test 22.6 實務注意事項 Migration 23.1 Java EE → Jakarta EE 23.2 Jakarta EE 10/11 → Jakarta EE 12 23.3 Spring Boot → Jakarta EE 23.4 Eclipse Transformer 工具 23.5 實務注意事項 大型企業最佳實務 24.1 銀行業案例 24.2 保險業案例 24.3 電商平台案例 24.4 政府系統案例 24.5 SaaS 平台案例 24.6 實務注意事項 團隊建立指南 25.1 Team Topology 25.2 技能矩陣與學習路線 25.3 培訓方式與 Code Review 規範 25.4 實務注意事項 DevSecOps 與 Git Flow 26.1 Branch Strategy 26.2 Git Flow vs Trunk Based Development 26.3 Release Strategy 26.4 實務注意事項 上線與維運 27.1 Production Deployment 27.2 Blue-Green 與 Canary 部署 27.3 Rollback 策略 27.4 DR、Backup 與 HA 27.5 實務注意事項 效能調校 28.1 JVM Tuning 28.2 GC Tuning 28.3 Connection Pool 調校 28.4 SQL Optimization 28.5 Thread Pool 設計 28.6 實務注意事項 常見問題 FAQ Troubleshooting 30.1 啟動問題 30.2 記憶體問題 30.3 Kubernetes 問題 30.4 JDBC 問題 30.5 Transaction 問題 Appendix 31.1 完整 Parent POM 31.2 Dockerfile 31.3 docker-compose.yml 31.4 Kubernetes YAML 31.5 GitHub Actions YAML 31.6 Jenkinsfile 31.7 Logging Configuration Jakarta EE 12 框架比較 32.1 Jakarta EE 12 vs Spring Boot 4 32.2 Jakarta EE 12 vs Quarkus 32.3 Jakarta EE 12 vs Micronaut 32.4 Jakarta EE 12 vs Helidon 32.5 選型建議 檢查清單（Checklist） 1. Jakarta EE 12 概觀 1.1 Jakarta EE 歷史與演進 從 J2EE 到 Jakarta EE 的二十年旅程 企業級 Java 的歷史可以追溯到 1999 年 Sun Microsystems 推出的 J2EE（Java 2 Platform, Enterprise Edition）。這二十多年的演進歷程，是理解 Jakarta EE 12 定位的關鍵脈絡。\n","title":"Jakarta EE 12 教學手冊"},{"content":"Agentic AI 與 LLM wiki Repo 建立教學手冊 — 企業級 AI 資產知識庫 版本：v3.1（2026-07-03） 適用對象：技術主管 / 架構師 / 資深工程師 / DevOps 團隊 定位：企業標準技術白皮書 參考範本：github/awesome-copilot（36.1k+ Stars / 4.5k+ Forks / 400+ Contributors） 延伸參考：Karpathy LLM Wiki（5,000+ Stars / 5,000+ Forks） 最後審閱日期：2026-07-03\n執行摘要 企業導入 GitHub Copilot、Claude Code 等 AI 開發工具後，最大的隱憂不是工具本身，而是團隊產出的 Agent、Instruction、Skill、Prompt 等「AI 資產」缺乏統一管理，導致重複造輪子、品質參差、知識隨人員異動而流失。本白皮書提出一套可落地的解法：以 GitHub 官方 awesome-copilot 的分類體系與治理機制為骨幹，建立企業內部的 AI 資產知識庫（第 1–10 章涵蓋 Repo 建立、目錄設計、內容規範、CI/CD 自動化、治理與團隊導入的完整流程）；並進一步整合 Andrej Karpathy 提出的 LLM Wiki 模式（第 11 章），讓「研究型、決策型」的知識也能由 LLM 持續編譯、複合成長，而非每次查詢都重新從原始資料派生答案。兩者互補：AI 資產知識庫管理「可執行的工具」，LLM Wiki 管理「持久化的判斷與脈絡」。讀者可依團隊規模（第 9.5.4 節）選擇適合的導入深度，從最小可行的 4 個核心目錄開始，逐步擴展至完整的 10 類資產與 LLM Wiki 知識層。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/agentic-ai-%E8%88%87-llm-wiki-repo%E5%BB%BA%E7%AB%8B%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Agentic AI 與 LLM wiki Repo 建立教學手冊 — 企業級 AI 資產知識庫 版本：v3.1（2026-07-03） 適用對象：技術主管 / 架構師 / 資深工程師 / DevOps 團隊 定位：企業標準技術白皮書 參考範本：github/awesome-copilot（36.1k+ Stars / 4.5k+ Forks / 400+ Contributors） 延伸參考：Karpathy LLM Wiki（5,000+ Stars / 5,000+ Forks） 最後審閱日期：2026-07-03\n執行摘要 企業導入 GitHub Copilot、Claude Code 等 AI 開發工具後，最大的隱憂不是工具本身，而是團隊產出的 Agent、Instruction、Skill、Prompt 等「AI 資產」缺乏統一管理，導致重複造輪子、品質參差、知識隨人員異動而流失。本白皮書提出一套可落地的解法：以 GitHub 官方 awesome-copilot 的分類體系與治理機制為骨幹，建立企業內部的 AI 資產知識庫（第 1–10 章涵蓋 Repo 建立、目錄設計、內容規範、CI/CD 自動化、治理與團隊導入的完整流程）；並進一步整合 Andrej Karpathy 提出的 LLM Wiki 模式（第 11 章），讓「研究型、決策型」的知識也能由 LLM 持續編譯、複合成長，而非每次查詢都重新從原始資料派生答案。兩者互補：AI 資產知識庫管理「可執行的工具」，LLM Wiki 管理「持久化的判斷與脈絡」。讀者可依團隊規模（第 9.5.4 節）選擇適合的導入深度，從最小可行的 4 個核心目錄開始，逐步擴展至完整的 10 類資產與 LLM Wiki 知識層。\n","title":"Agentic AI 與 LLM wiki Repo 建立教學手冊"},{"content":"AI 治理教學手冊（AI Governance Handbook） 版本：v5.0\n適用對象：管理團隊 + 開發團隊\n最後更新：2026-07-16\n分類：企業內部標準文件（技術白皮書等級）\n文件編號：GOV-AI-001\n機密等級：內部使用\n版本歷程 版本 日期 修訂內容 修訂人 v1.0 2026-05-06 初版發行 AI 治理委員會 v2.0 2026-05-06 全面更新法規對照、新增生成式 AI 治理專章、補充台灣《人工智慧基本法》與國際標準最新動態 AI 治理委員會 v3.0 2026-05-06 依據 EU AI Act 最新施行進度更新（含八大禁止實踐、GPAI Code of Practice 第三版）、補充金管會 AI 自律規範、強化 AI 素養與跨境治理章節、新增數位發展部評測指引落地實務 AI 治理委員會 v4.0 2026-07-02 重大法規更新：台灣《人工智慧基本法》2025 年 12 月三讀通過（修正七大原則與主管機關分工）、EU AI Act Digital Omnibus 修正案（高風險義務延至 2027/2028 年、新增二項禁止實踐）、GPAI Code of Practice 正式版、金管會「金融業運用 AI 指引」（2024/6）、《個資法》與《資安法》2025 年修正；新增 ISO/IEC 42005/42006、NIST 2025-2026 動態（America\u0026rsquo;s AI Action Plan、Cyber AI Profile）、OECD 負責任 AI 盡職調查指引專節、AIEC 十項評測面向修正 AI 治理委員會 v5.0 2026-07-16 逐章節查證修正：台灣《人工智慧基本法》已於 2026/1/14 公布施行（含 2 年落日條款）、國家 AI 戰略特別委員會已於 2026/5/21 正式成立、moda AI 風險分類框架四步驟落地說明、金管會擬議納入代理式 AI 指引動態、個資會籌備處現況澄清、資安法施行細節；修正 EU AI Act Article 50 透明度義務延期範圍之誤植；新增 ISO/IEC 42001 認證概況、NIST 2025-2026 動態細節、OECD HAIP 2.0；新增 4.4 模型風險管理生命週期、4.5 供應鏈第四方風險、7.2.6 AI Agent 失控風險、13 章生成式內容標記合規；更新 3.1 AI 工具世代資訊；修正 LaTeX 格式問題 AI 治理委員會 目錄 法規與標準對照表 1. AI 治理總體架構（Governance Framework） 1.1 AI 治理目標 1.2 三道防線（Three Lines of Defense） 1.3 AI 風險分類 1.4 與 IT Governance / Data Governance 關聯 2. AI 在 SSDLC 各階段治理 2.0 SSDLC 全景圖 2.1 Requirement（需求階段） 2.2 Design（設計階段） 2.3 Development（開發階段）— AI Coding 2.4 Testing（測試階段） 2.5 Deployment（部署階段） 2.6 Maintenance（維護階段） 3. AI Coding 工具治理 3.1 工具對照與管理 3.2 Prompt 管理（Prompt Governance） 3.3 輸出驗證（Output Validation） 3.4 Code Review 政策 3.5 禁止事項 3.6 AI Hallucination 控制 4. 公司 AI 治理章程（Policy） 4.1 AI 使用政策 4.2 AI 開發規範 4.3 資料使用規範 4.4 模型使用規範 4.5 第三方 AI 管理 5. 標準作業程序（SOP） 5.1 AI 開發流程 SOP 5.2 Prompt 使用 SOP 5.3 AI Code Review SOP 5.4 AI 產出驗證 SOP 5.5 AI 事件通報 SOP 6. 驗證與稽核機制（Validation \u0026amp; Audit） 6.1 AI 產出驗證方法（Test Strategy） 6.2 安全掃描（SAST / DAST） 6.3 AI 風險評估 6.4 稽核流程（Audit Checklist） 6.5 Logging \u0026amp; Traceability 7. AI 風險管理（Risk Management） 7.1 風險總覽 7.2 各風險詳細分析與控制 8. 技術落地架構（Architecture） 8.1 AI Gateway 架構 8.2 Prompt Registry 設計 8.3 Audit Log 系統 8.4 Secure Proxy 設計 8.5 DevSecOps 整合 9. 管理層決策建議（Executive Guide） 9.1 KPI / KRI 9.2 AI 成本控管 9.3 導入策略（Phase 1~3） 9.4 組織設計（AI Governance Team） 10. 生成式 AI 治理專章（Generative AI Governance） 10.1 生成式 AI 風險特論 10.2 大型語言模型（LLM）使用規範 10.3 AI Agent 與自動化工作流治理 10.4 生成式 AI 倫理框架 11. 附錄（Templates） 11.1 AI 使用申請表 11.2 Prompt Template 範例 11.3 AI Risk Assessment 表 11.4 Code Review Checklist（AI 產出專用） 12. AI 素養與教育訓練體系（AI Literacy \u0026amp; Training） 12.1 AI 素養框架 12.2 分層培訓體系 12.3 培訓成效評估 13. 跨境資料傳輸與多法域合規（Cross-border \u0026amp; Multi-jurisdiction） 13.1 跨境資料傳輸治理 13.2 多法域合規矩陣 13.3 國際合作與互認機制 檢查清單（Checklist） 法規與標準對照表 台灣法規 法規/標準 主管機關 核心要求 最新動態 與本手冊對應章節 《人工智慧基本法》 國科會（中央主管機關） AI 發展與治理基本原則、風險分級管理、產業推動、人才培育、資料治理；確立七大基本原則（永續發展與福祉、人類自主、隱私保護與資料治理、資安與安全、透明與可解釋、公平與不歧視、問責） 國科會 2024 年草擬、2025 年改由數位發展部推動立法作業，2025 年 12 月 23 日立法院三讀通過，2026 年 1 月 14 日總統公布施行，為台灣首部 AI 專法。法案訂有 2 年落日條款：各目的事業主管機關須於施行後 2 年內，依中央主管機關訂定之風險分類框架完成子法訂修；行政院已於 2026 年 5 月 21 日由行政院長卓榮泰親自召集正式成立「國家 AI 戰略特別委員會」，國科會將據以研擬《國家人工智慧發展綱領》提委員會審議 1, 4, 7, 10, 12 金管會「金融業運用AI核心原則與相關推動政策」 金管會 建立治理與問責機制、重視公平性及以人為本、保護隱私及客戶權益、確保系統穩健及安全、落實透明性及可解釋性、促進永續發展（六大核心原則）＋ 八項配套政策 2023 年 10 月發布，揭示六大核心原則與八項配套政策（含訂定 AI 指引、法規調適、監理科技、責成公會自律規範等）；金管會後續調查顯示已逾百家金融機構於智能客服、風控、行銷等業務導入 AI 1, 4, 7 金管會「金融業運用人工智慧（AI）指引」 金管會 依六大核心原則展開之操作性指引：涵蓋治理與問責（董事會與高階管理階層之監督責任）、AI 系統生命週期風險管理、資料治理與隱私保護、系統穩健性與安全性、透明性與可解釋性（含客戶告知）、委外與第三方管理 2024 年 6 月 20 日正式發布（2023 年 12 月草案公開徵詢後定案），為金融業 AI 治理最具體之遵循文件；採原則性、非強制性設計，並責成銀行、證券、保險等公會據以訂定自律規範與最佳實務守則。2026 年 5 月 7 日金管會主委彭金隆於立法院財政委員會表示，將修訂指引納入「可程式化 AI」「代理式 AI（AI Agent）」與風險分類機制，時程對標 EU AI Act 2026/8/2 全面生效——現階段屬研議中之修訂方向，尚未定案發布，企業應持續追蹤而非逕予採用 1, 4, 6, 7 《個人資料保護法》 個人資料保護委員會籌備處（尚未完成獨立設會） 資料蒐集/處理/利用之合法性基礎、安全維護義務、跨境傳輸限制、個資事故通知與通報義務 2023 年修正增訂獨立監督機關法源並成立個資會籌備處（2023/12/5 成立）；行政院 2025 年 3 月通過「個資會組織法」草案與個資法部分條文修正草案，個資法修正條文於 2025 年 10 月 17 日三讀、11 月 11 日總統公布（強化行政監管與檢查權限、明訂事故通知通報義務、調整罰則）。施行日期尚待行政院另定；「個資會組織法」尚未完成三讀，個資會現仍以籌備處型態運作，並非正式獨立機關。籌備處已於 2026 年 1 月預告施行細則修正草案及三項子法，內容含 72 小時資安事故通報與 DPO 設置要求 4, 7, 13 《資通安全管理法》 數位發展部（資通安全署執行） 資安防護基準、事件通報與應變、稽核評鑑、資安人員專職化、供應鏈安全管理 2025 年 8 月 29 日三讀、9 月 24 日總統公布修正，已於 2025 年 12 月 1 日正式施行：主管機關明定為數位發展部、公務機關原則禁止使用危害國家資安之資通產品、強化資安專職人員（資通安全長）配置與訓練、擴大稽核範圍至五院與地方政府、促進跨機關聯防；特定非公務機關未依規定通報之罰鍰由新台幣 30 萬元起、最高可處 1,000 萬元；資安署並同步修訂八項子法 5, 6 行政院「AI 新十大建設推動方案」 國發會/行政院 AI 基礎建設、算力提升、產業應用、人才培育、法制環境、國際合作 114 年至 117 年（2025-2028）推動中，包含建置國家級 AI 算力中心、推動 AI 人才培育計畫、建立 AI 沙盒機制；《AI 基本法》通過後成為其法制基礎 9 數位發展部「AI 風險分類框架」／AI 產品與系統評測中心（AIEC） 數位發展部（數位產業署） 風險分類框架採四步驟流程：應用盤點 → 風險辨識 → 風險評估 → 風險應變，作為跨機關共通語言，由各目的事業主管機關（如金管會）據以訂定領域拘束性規範；AIEC 提供 AI 系統可信賴性評測，涵蓋十項評測面向：安全性、可解釋性、彈性、公平性、準確性、透明性、當責性、可靠性、隱私、資安 AIEC 為既有機制，於 2023 年 12 月啟動（非新設），參考 NIST、ISO 與歐盟規範提供評測服務；風險分類框架頁面 2026 年 3 月 23 日發布、2026 年 7 月 8 日更新，對應 PDF 版本（23 頁）可供企業對照盤點自身 AI 應用；規劃 2026 年推動國內產品通過國內外標準評測 6, 12 國科會「負責任 AI 研發指引」 國科會 AI 研發倫理規範、資料治理原則、利害關係人參與、風險評估方法論 供學研界與產業界遵循，強調以人為本的 AI 研發實踐；《AI 基本法》通過後與其七大原則銜接 10, 12 國際法規與標準 法規/標準 管轄範圍 核心要求 最新動態 與本手冊對應章節 EU AI Act（Regulation 2024/1689） 歐盟/具域外效力 AI 風險四級分類（不可接受/高/有限/最低）+ 通用目的 AI（GPAI）專章；明定禁止實踐清單 2024 年 8 月 1 日生效；2025 年 2 月起八大禁止實踐與 AI 素養義務適用；2025 年 8 月 2 日起 GPAI 義務適用（GPAI Code of Practice 正式版於 2025 年 7 月 10 日發布，含透明度、著作權、安全與資安三章，8 月 1 日獲執委會與 AI Board 認可）；Digital Omnibus 修正案於 2026 年 5 月 7 日達成三方臨時協議、6 月 16 日歐洲議會通過、6 月 29 日理事會最終批准：Annex III 獨立高風險系統義務延至 2027 年 12 月 2 日、Annex I 嵌入受監管產品之 AI 延至 2028 年 8 月 2 日，並新增二項禁止實踐（AI 生成未經同意之私密影像與兒少性剝削內容，2026 年 12 月 2 日生效） 1, 7, 10, 13 ISO/IEC 42001:2023 國際 AI 管理系統（AIMS）建立、實施、維護與持續改善之要求（條款 4-10，PDCA 架構）；為全球首個 AI 管理系統國際標準 2023 年 12 月正式發布，可作為第三方認證依據；全球認證數持續成長，2026 年春已逾 350 家組織取得認證（含 AWS、Microsoft、Anthropic、KPMG 等，惟無官方統一登錄、數字係彙整各驗證機構公開資訊），台灣已有認證機構提供服務；與 ISO/IEC 42005（影響評估）、42006（驗證機構要求）構成「建置—影響評估—驗證」完整標準包 1, 6 ISO/IEC 42005:2025 國際 AI 系統影響評估（AI System Impact Assessment）指引：於 AI 生命週期各階段評估對個人與社會之可預見影響，並與 AIMS、風險管理流程整合 2025 年 5 月發布，補足 ISO/IEC 42001 條款 6 與附錄所要求之影響評估方法論，為企業執行 AI 影響評估之主要國際參考。性質為指引文件，不可單獨作為認證依據，須與 42001 併同適用 6, 7 ISO/IEC 42006:2025 國際 對 AIMS 稽核與驗證機構之額外要求（稽核員能力、稽核時間、範圍界定），確保 ISO/IEC 42001 認證之公信力與一致性 2025 年 7 月發布，規範對象為驗證機構本身（非一般企業）；驗證機構須依此取得認可，企業選擇驗證機構時應確認其符合本標準，避免與 42005 之「企業自行適用」性質混淆 6 ISO/IEC 23894:2023 國際 AI 風險管理指引，與 ISO 31000 整合，提供 AI 特定風險識別與處理方法 2023 年 2 月發布，已成為各國 AI 風險管理實務之重要參考 7 ISO/IEC 38507:2022 國際 AI 使用之治理影響，為組織治理層提供 AI 治理指引 2022 年發布，與 ISO/IEC 42001 形成互補的治理標準體系 1, 9 ISO/IEC 25059:2023 國際 AI 系統品質模型，擴展 SQuaRE 系列至 AI 系統品質評估 2023 年發布，為 AI 系統品質量測提供標準化框架 6 NIST AI RMF 1.0 美國/國際參考 AI 風險管理四大功能：治理（Govern）、對應（Map）、量測（Measure）、管理（Manage） 2023 年 1 月發布；生成式 AI 風險概覽（NIST AI 600-1）2024 年 7 月發布。美國「America\u0026rsquo;s AI Action Plan」（2025 年 7 月）指示 NIST 修訂 AI RMF，具體修訂方向為移除錯誤資訊、DEI、氣候變遷等相關引用（非中性技術性調整，反映政策立場轉變），企業引用時應留意版本差異；Cyber AI Profile（NIST IR 8596）初稿於 2025 年 12 月公開徵詢，意見徵詢已於 2026 年 1 月 30 日截止，惟尚未定稿，將 AI 風險與網路安全框架（CSF 2.0）整合；2026 年 4 月發布之關鍵基礎設施 AI RMF Profile 目前僅為概念文件並徵集社群意見，尚非正式草案 7 OECD AI Principles 國際（38 國+夥伴國） 包容性成長、永續發展、以人為本、透明與可解釋、穩健安全、問責 2024 年 5 月更新修訂版，納入生成式 AI 與基礎模型考量；2025 年 2 月推出廣島 AI 進程（HAIP）透明度報告框架；HAIP 報告框架 2.0 於 2026 年 5 月 28 日發布，擴大適用範圍至完整 AI 價值鏈（不限於前沿模型供應商）並簡化中小企業申報流程 1, 9, 10 OECD 負責任 AI 盡職調查指引（Due Diligence Guidance for Responsible AI） 國際 將「負責任商業行為（RBC）」六步驟盡職調查框架套用於 AI 價值鏈：政策內嵌、風險識別與評估、停止/預防/減緩、追蹤成效、對外溝通、補救措施 2026 年 2 月 19 日發布，為企業（含 AI 供應鏈上下游）辨識並處理 AI 負面影響之實務指引，與 OECD 跨國企業指導綱領銜接（詳見第 4.5 節） 4, 7 UNESCO AI 倫理建議書 國際（193 國） AI 倫理四大價值：尊重人權、多元包容、和平公正、環境永續；十大原則 2021 年 11 月通過，2024 年進行首次全球執行狀況評估（Readiness Assessment），顯示約 60% 會員國已啟動相關立法 10 美國白宮 AI 政策 美國 以促進創新與維持 AI 領導地位為主軸之聯邦政策 EO 14110（2023/10）於 2025 年 1 月被 EO 14179「移除美國 AI 領導地位之障礙」取代；2025 年 7 月 23 日白宮發布「Winning the Race: America\u0026rsquo;s AI Action Plan」，聚焦加速創新、AI 基礎建設與國際外交安全三大支柱，並指示 NIST 修訂 AI RMF；聯邦層級鬆綁之際，州級 AI 立法（如科羅拉多州 SB24-205）持續推進，形成多層次監管環境 7 G7 廣島 AI 程序與行為準則 G7 國家 先進 AI 系統開發者的國際行為準則，含 11 項自願承諾 2023 年 10 月發布；2024 年 G7 峰會持續推動並擴大至非 G7 夥伴國參與；2025 年加拿大 G7 輪值主席持續深化 AI 治理議題 1, 9 新加坡 AI Verify 亞太 AI 系統可信賴性測試框架，涵蓋透明度、公平性等九大面向 持續更新，已成為亞太地區重要的 AI 治理參考框架 6 中國《生成式人工智能服務管理暫行辦法》 中國大陸 生成式 AI 服務提供者之義務、內容安全、資料標註要求 2023 年 8 月施行；後續陸續發布《人工智能安全治理框架》等配套規範 10, 13 1. AI 治理總體架構（Governance Framework） 1.1 AI 治理目標 本公司 AI 治理制度之目標：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/ai-%E6%B2%BB%E7%90%86%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"AI 治理教學手冊（AI Governance Handbook） 版本：v5.0\n適用對象：管理團隊 + 開發團隊\n最後更新：2026-07-16\n分類：企業內部標準文件（技術白皮書等級）\n文件編號：GOV-AI-001\n機密等級：內部使用\n版本歷程 版本 日期 修訂內容 修訂人 v1.0 2026-05-06 初版發行 AI 治理委員會 v2.0 2026-05-06 全面更新法規對照、新增生成式 AI 治理專章、補充台灣《人工智慧基本法》與國際標準最新動態 AI 治理委員會 v3.0 2026-05-06 依據 EU AI Act 最新施行進度更新（含八大禁止實踐、GPAI Code of Practice 第三版）、補充金管會 AI 自律規範、強化 AI 素養與跨境治理章節、新增數位發展部評測指引落地實務 AI 治理委員會 v4.0 2026-07-02 重大法規更新：台灣《人工智慧基本法》2025 年 12 月三讀通過（修正七大原則與主管機關分工）、EU AI Act Digital Omnibus 修正案（高風險義務延至 2027/2028 年、新增二項禁止實踐）、GPAI Code of Practice 正式版、金管會「金融業運用 AI 指引」（2024/6）、《個資法》與《資安法》2025 年修正；新增 ISO/IEC 42005/42006、NIST 2025-2026 動態（America\u0026rsquo;s AI Action Plan、Cyber AI Profile）、OECD 負責任 AI 盡職調查指引專節、AIEC 十項評測面向修正 AI 治理委員會 v5.0 2026-07-16 逐章節查證修正：台灣《人工智慧基本法》已於 2026/1/14 公布施行（含 2 年落日條款）、國家 AI 戰略特別委員會已於 2026/5/21 正式成立、moda AI 風險分類框架四步驟落地說明、金管會擬議納入代理式 AI 指引動態、個資會籌備處現況澄清、資安法施行細節；修正 EU AI Act Article 50 透明度義務延期範圍之誤植；新增 ISO/IEC 42001 認證概況、NIST 2025-2026 動態細節、OECD HAIP 2.0；新增 4.4 模型風險管理生命週期、4.5 供應鏈第四方風險、7.2.6 AI Agent 失控風險、13 章生成式內容標記合規；更新 3.1 AI 工具世代資訊；修正 LaTeX 格式問題 AI 治理委員會 目錄 法規與標準對照表 1. AI 治理總體架構（Governance Framework） 1.1 AI 治理目標 1.2 三道防線（Three Lines of Defense） 1.3 AI 風險分類 1.4 與 IT Governance / Data Governance 關聯 2. AI 在 SSDLC 各階段治理 2.0 SSDLC 全景圖 2.1 Requirement（需求階段） 2.2 Design（設計階段） 2.3 Development（開發階段）— AI Coding 2.4 Testing（測試階段） 2.5 Deployment（部署階段） 2.6 Maintenance（維護階段） 3. AI Coding 工具治理 3.1 工具對照與管理 3.2 Prompt 管理（Prompt Governance） 3.3 輸出驗證（Output Validation） 3.4 Code Review 政策 3.5 禁止事項 3.6 AI Hallucination 控制 4. 公司 AI 治理章程（Policy） 4.1 AI 使用政策 4.2 AI 開發規範 4.3 資料使用規範 4.4 模型使用規範 4.5 第三方 AI 管理 5. 標準作業程序（SOP） 5.1 AI 開發流程 SOP 5.2 Prompt 使用 SOP 5.3 AI Code Review SOP 5.4 AI 產出驗證 SOP 5.5 AI 事件通報 SOP 6. 驗證與稽核機制（Validation \u0026amp; Audit） 6.1 AI 產出驗證方法（Test Strategy） 6.2 安全掃描（SAST / DAST） 6.3 AI 風險評估 6.4 稽核流程（Audit Checklist） 6.5 Logging \u0026amp; Traceability 7. AI 風險管理（Risk Management） 7.1 風險總覽 7.2 各風險詳細分析與控制 8. 技術落地架構（Architecture） 8.1 AI Gateway 架構 8.2 Prompt Registry 設計 8.3 Audit Log 系統 8.4 Secure Proxy 設計 8.5 DevSecOps 整合 9. 管理層決策建議（Executive Guide） 9.1 KPI / KRI 9.2 AI 成本控管 9.3 導入策略（Phase 1~3） 9.4 組織設計（AI Governance Team） 10. 生成式 AI 治理專章（Generative AI Governance） 10.1 生成式 AI 風險特論 10.2 大型語言模型（LLM）使用規範 10.3 AI Agent 與自動化工作流治理 10.4 生成式 AI 倫理框架 11. 附錄（Templates） 11.1 AI 使用申請表 11.2 Prompt Template 範例 11.3 AI Risk Assessment 表 11.4 Code Review Checklist（AI 產出專用） 12. AI 素養與教育訓練體系（AI Literacy \u0026amp; Training） 12.1 AI 素養框架 12.2 分層培訓體系 12.3 培訓成效評估 13. 跨境資料傳輸與多法域合規（Cross-border \u0026amp; Multi-jurisdiction） 13.1 跨境資料傳輸治理 13.2 多法域合規矩陣 13.3 國際合作與互認機制 檢查清單（Checklist） 法規與標準對照表 台灣法規 法規/標準 主管機關 核心要求 最新動態 與本手冊對應章節 《人工智慧基本法》 國科會（中央主管機關） AI 發展與治理基本原則、風險分級管理、產業推動、人才培育、資料治理；確立七大基本原則（永續發展與福祉、人類自主、隱私保護與資料治理、資安與安全、透明與可解釋、公平與不歧視、問責） 國科會 2024 年草擬、2025 年改由數位發展部推動立法作業，2025 年 12 月 23 日立法院三讀通過，2026 年 1 月 14 日總統公布施行，為台灣首部 AI 專法。法案訂有 2 年落日條款：各目的事業主管機關須於施行後 2 年內，依中央主管機關訂定之風險分類框架完成子法訂修；行政院已於 2026 年 5 月 21 日由行政院長卓榮泰親自召集正式成立「國家 AI 戰略特別委員會」，國科會將據以研擬《國家人工智慧發展綱領》提委員會審議 1, 4, 7, 10, 12 金管會「金融業運用AI核心原則與相關推動政策」 金管會 建立治理與問責機制、重視公平性及以人為本、保護隱私及客戶權益、確保系統穩健及安全、落實透明性及可解釋性、促進永續發展（六大核心原則）＋ 八項配套政策 2023 年 10 月發布，揭示六大核心原則與八項配套政策（含訂定 AI 指引、法規調適、監理科技、責成公會自律規範等）；金管會後續調查顯示已逾百家金融機構於智能客服、風控、行銷等業務導入 AI 1, 4, 7 金管會「金融業運用人工智慧（AI）指引」 金管會 依六大核心原則展開之操作性指引：涵蓋治理與問責（董事會與高階管理階層之監督責任）、AI 系統生命週期風險管理、資料治理與隱私保護、系統穩健性與安全性、透明性與可解釋性（含客戶告知）、委外與第三方管理 2024 年 6 月 20 日正式發布（2023 年 12 月草案公開徵詢後定案），為金融業 AI 治理最具體之遵循文件；採原則性、非強制性設計，並責成銀行、證券、保險等公會據以訂定自律規範與最佳實務守則。2026 年 5 月 7 日金管會主委彭金隆於立法院財政委員會表示，將修訂指引納入「可程式化 AI」「代理式 AI（AI Agent）」與風險分類機制，時程對標 EU AI Act 2026/8/2 全面生效——現階段屬研議中之修訂方向，尚未定案發布，企業應持續追蹤而非逕予採用 1, 4, 6, 7 《個人資料保護法》 個人資料保護委員會籌備處（尚未完成獨立設會） 資料蒐集/處理/利用之合法性基礎、安全維護義務、跨境傳輸限制、個資事故通知與通報義務 2023 年修正增訂獨立監督機關法源並成立個資會籌備處（2023/12/5 成立）；行政院 2025 年 3 月通過「個資會組織法」草案與個資法部分條文修正草案，個資法修正條文於 2025 年 10 月 17 日三讀、11 月 11 日總統公布（強化行政監管與檢查權限、明訂事故通知通報義務、調整罰則）。施行日期尚待行政院另定；「個資會組織法」尚未完成三讀，個資會現仍以籌備處型態運作，並非正式獨立機關。籌備處已於 2026 年 1 月預告施行細則修正草案及三項子法，內容含 72 小時資安事故通報與 DPO 設置要求 4, 7, 13 《資通安全管理法》 數位發展部（資通安全署執行） 資安防護基準、事件通報與應變、稽核評鑑、資安人員專職化、供應鏈安全管理 2025 年 8 月 29 日三讀、9 月 24 日總統公布修正，已於 2025 年 12 月 1 日正式施行：主管機關明定為數位發展部、公務機關原則禁止使用危害國家資安之資通產品、強化資安專職人員（資通安全長）配置與訓練、擴大稽核範圍至五院與地方政府、促進跨機關聯防；特定非公務機關未依規定通報之罰鍰由新台幣 30 萬元起、最高可處 1,000 萬元；資安署並同步修訂八項子法 5, 6 行政院「AI 新十大建設推動方案」 國發會/行政院 AI 基礎建設、算力提升、產業應用、人才培育、法制環境、國際合作 114 年至 117 年（2025-2028）推動中，包含建置國家級 AI 算力中心、推動 AI 人才培育計畫、建立 AI 沙盒機制；《AI 基本法》通過後成為其法制基礎 9 數位發展部「AI 風險分類框架」／AI 產品與系統評測中心（AIEC） 數位發展部（數位產業署） 風險分類框架採四步驟流程：應用盤點 → 風險辨識 → 風險評估 → 風險應變，作為跨機關共通語言，由各目的事業主管機關（如金管會）據以訂定領域拘束性規範；AIEC 提供 AI 系統可信賴性評測，涵蓋十項評測面向：安全性、可解釋性、彈性、公平性、準確性、透明性、當責性、可靠性、隱私、資安 AIEC 為既有機制，於 2023 年 12 月啟動（非新設），參考 NIST、ISO 與歐盟規範提供評測服務；風險分類框架頁面 2026 年 3 月 23 日發布、2026 年 7 月 8 日更新，對應 PDF 版本（23 頁）可供企業對照盤點自身 AI 應用；規劃 2026 年推動國內產品通過國內外標準評測 6, 12 國科會「負責任 AI 研發指引」 國科會 AI 研發倫理規範、資料治理原則、利害關係人參與、風險評估方法論 供學研界與產業界遵循，強調以人為本的 AI 研發實踐；《AI 基本法》通過後與其七大原則銜接 10, 12 國際法規與標準 法規/標準 管轄範圍 核心要求 最新動態 與本手冊對應章節 EU AI Act（Regulation 2024/1689） 歐盟/具域外效力 AI 風險四級分類（不可接受/高/有限/最低）+ 通用目的 AI（GPAI）專章；明定禁止實踐清單 2024 年 8 月 1 日生效；2025 年 2 月起八大禁止實踐與 AI 素養義務適用；2025 年 8 月 2 日起 GPAI 義務適用（GPAI Code of Practice 正式版於 2025 年 7 月 10 日發布，含透明度、著作權、安全與資安三章，8 月 1 日獲執委會與 AI Board 認可）；Digital Omnibus 修正案於 2026 年 5 月 7 日達成三方臨時協議、6 月 16 日歐洲議會通過、6 月 29 日理事會最終批准：Annex III 獨立高風險系統義務延至 2027 年 12 月 2 日、Annex I 嵌入受監管產品之 AI 延至 2028 年 8 月 2 日，並新增二項禁止實踐（AI 生成未經同意之私密影像與兒少性剝削內容，2026 年 12 月 2 日生效） 1, 7, 10, 13 ISO/IEC 42001:2023 國際 AI 管理系統（AIMS）建立、實施、維護與持續改善之要求（條款 4-10，PDCA 架構）；為全球首個 AI 管理系統國際標準 2023 年 12 月正式發布，可作為第三方認證依據；全球認證數持續成長，2026 年春已逾 350 家組織取得認證（含 AWS、Microsoft、Anthropic、KPMG 等，惟無官方統一登錄、數字係彙整各驗證機構公開資訊），台灣已有認證機構提供服務；與 ISO/IEC 42005（影響評估）、42006（驗證機構要求）構成「建置—影響評估—驗證」完整標準包 1, 6 ISO/IEC 42005:2025 國際 AI 系統影響評估（AI System Impact Assessment）指引：於 AI 生命週期各階段評估對個人與社會之可預見影響，並與 AIMS、風險管理流程整合 2025 年 5 月發布，補足 ISO/IEC 42001 條款 6 與附錄所要求之影響評估方法論，為企業執行 AI 影響評估之主要國際參考。性質為指引文件，不可單獨作為認證依據，須與 42001 併同適用 6, 7 ISO/IEC 42006:2025 國際 對 AIMS 稽核與驗證機構之額外要求（稽核員能力、稽核時間、範圍界定），確保 ISO/IEC 42001 認證之公信力與一致性 2025 年 7 月發布，規範對象為驗證機構本身（非一般企業）；驗證機構須依此取得認可，企業選擇驗證機構時應確認其符合本標準，避免與 42005 之「企業自行適用」性質混淆 6 ISO/IEC 23894:2023 國際 AI 風險管理指引，與 ISO 31000 整合，提供 AI 特定風險識別與處理方法 2023 年 2 月發布，已成為各國 AI 風險管理實務之重要參考 7 ISO/IEC 38507:2022 國際 AI 使用之治理影響，為組織治理層提供 AI 治理指引 2022 年發布，與 ISO/IEC 42001 形成互補的治理標準體系 1, 9 ISO/IEC 25059:2023 國際 AI 系統品質模型，擴展 SQuaRE 系列至 AI 系統品質評估 2023 年發布，為 AI 系統品質量測提供標準化框架 6 NIST AI RMF 1.0 美國/國際參考 AI 風險管理四大功能：治理（Govern）、對應（Map）、量測（Measure）、管理（Manage） 2023 年 1 月發布；生成式 AI 風險概覽（NIST AI 600-1）2024 年 7 月發布。美國「America\u0026rsquo;s AI Action Plan」（2025 年 7 月）指示 NIST 修訂 AI RMF，具體修訂方向為移除錯誤資訊、DEI、氣候變遷等相關引用（非中性技術性調整，反映政策立場轉變），企業引用時應留意版本差異；Cyber AI Profile（NIST IR 8596）初稿於 2025 年 12 月公開徵詢，意見徵詢已於 2026 年 1 月 30 日截止，惟尚未定稿，將 AI 風險與網路安全框架（CSF 2.0）整合；2026 年 4 月發布之關鍵基礎設施 AI RMF Profile 目前僅為概念文件並徵集社群意見，尚非正式草案 7 OECD AI Principles 國際（38 國+夥伴國） 包容性成長、永續發展、以人為本、透明與可解釋、穩健安全、問責 2024 年 5 月更新修訂版，納入生成式 AI 與基礎模型考量；2025 年 2 月推出廣島 AI 進程（HAIP）透明度報告框架；HAIP 報告框架 2.0 於 2026 年 5 月 28 日發布，擴大適用範圍至完整 AI 價值鏈（不限於前沿模型供應商）並簡化中小企業申報流程 1, 9, 10 OECD 負責任 AI 盡職調查指引（Due Diligence Guidance for Responsible AI） 國際 將「負責任商業行為（RBC）」六步驟盡職調查框架套用於 AI 價值鏈：政策內嵌、風險識別與評估、停止/預防/減緩、追蹤成效、對外溝通、補救措施 2026 年 2 月 19 日發布，為企業（含 AI 供應鏈上下游）辨識並處理 AI 負面影響之實務指引，與 OECD 跨國企業指導綱領銜接（詳見第 4.5 節） 4, 7 UNESCO AI 倫理建議書 國際（193 國） AI 倫理四大價值：尊重人權、多元包容、和平公正、環境永續；十大原則 2021 年 11 月通過，2024 年進行首次全球執行狀況評估（Readiness Assessment），顯示約 60% 會員國已啟動相關立法 10 美國白宮 AI 政策 美國 以促進創新與維持 AI 領導地位為主軸之聯邦政策 EO 14110（2023/10）於 2025 年 1 月被 EO 14179「移除美國 AI 領導地位之障礙」取代；2025 年 7 月 23 日白宮發布「Winning the Race: America\u0026rsquo;s AI Action Plan」，聚焦加速創新、AI 基礎建設與國際外交安全三大支柱，並指示 NIST 修訂 AI RMF；聯邦層級鬆綁之際，州級 AI 立法（如科羅拉多州 SB24-205）持續推進，形成多層次監管環境 7 G7 廣島 AI 程序與行為準則 G7 國家 先進 AI 系統開發者的國際行為準則，含 11 項自願承諾 2023 年 10 月發布；2024 年 G7 峰會持續推動並擴大至非 G7 夥伴國參與；2025 年加拿大 G7 輪值主席持續深化 AI 治理議題 1, 9 新加坡 AI Verify 亞太 AI 系統可信賴性測試框架，涵蓋透明度、公平性等九大面向 持續更新，已成為亞太地區重要的 AI 治理參考框架 6 中國《生成式人工智能服務管理暫行辦法》 中國大陸 生成式 AI 服務提供者之義務、內容安全、資料標註要求 2023 年 8 月施行；後續陸續發布《人工智能安全治理框架》等配套規範 10, 13 1. AI 治理總體架構（Governance Framework） 1.1 AI 治理目標 本公司 AI 治理制度之目標：\n","title":"AI 治理教學手冊"},{"content":"Open Design 教學手冊 版本：v0.13.0「Stay in Flow」（對應 Open Design 0.13.0）\n最後更新：2026-07-02\n適用對象：資深工程師、前後端開發人員、UI/UX 設計師、AI 架構師、平台維運與採購決策者\n授權：Apache-2.0（部分內建 Plugin／Skill 沿用原始授權，詳見附錄 A）\n文件等級：企業標準技術白皮書\n目錄 1. 概述與背景 1.1 Open Design 是什麼 1.2 為何需要 Open Design 1.3 市場產品比較全景 1.4 BYOK 與 AMR 雙軌設計理念 1.5 適用場景 1.6 開源基石與技術譜系 2. 系統整體架構設計 2.1 高階架構圖 2.2 技術組成 2.3 AI Agent 整合架構 2.4 設計生成流程 2.5 Prompt Stack 組合機制 2.6 專案目錄結構與資料治理 2.7 與企業架構整合 3. 安裝與環境建置 3.1 系統需求 3.2 安裝路徑總覽 3.3 首次啟動與驗證 3.4 BYOK 設定 3.5 桌面版安裝 3.6 容器化與雲端部署 3.7 多語系與國際化 4. 核心機制解析 4.1 Skill 驅動架構 4.2 HTML PPT Studio 技能體系 4.3 Design System 設計系統 4.4 Visual Directions 視覺方向 4.5 Anti-AI-Slop 防劣質機制 4.6 媒體生成能力 4.7 Craft 設計參考系統 4.8 OD Library 與使用者資產庫 5. Plugin 系統與 MCP 整合 5.1 Plugin 市集架構與定位 5.2 官方 Plugin 六大分類 5.3 Plugin CLI 操作 5.4 建立與貢獻 Plugin 5.5 MCP Server 整合 5.6 Open Design AMR 模型路由器 6. AI 開發流程（企業級） 6.1 Web Application 開發 6.2 舊系統逆向工程 6.3 Framework 升級 6.4 企業文件與報表生成 7. Prompt Engineering 7.1 Prompt 結構設計原則 7.2 高品質 Prompt 範本 7.3 Prompt 最佳化策略 8. 設計品質控管機制 8.1 五維度自我審核機制 8.2 P0 / P1 / P2 Checklist 8.3 Artifact Lint API 8.4 Slop 黑名單 9. 輸出與整合 9.1 匯出格式 9.2 CI/CD 整合 9.3 Git / PR 開發流程整合 9.4 Claude Design ZIP 匯入 10. 系統維護與營運 10.1 日誌與監控 10.2 錯誤處理 10.3 Skill 管理 10.4 Design System 更新策略 10.5 資料備份與復原 11. 系統升級策略 11.1 Open Design 升級流程 11.2 相容性管理 11.3 版本控管策略 11.4 回滾機制 12. 團隊導入建議 12.1 開發團隊使用方式 12.2 設計師協作模式 12.3 AI Agent 分工策略 12.4 SSDLC 整合方式 13. 最佳實踐（Best Practices） 14. 常見問題與風險 15. 與企業架構深度整合 15.1 微服務架構整合 15.2 Clean Architecture 對應 15.3 前端框架整合（Vue / React） 15.4 後端框架整合（Spring Boot / FastAPI） 16. 檢查清單（Checklist） 附錄 A：參考來源與技術譜系 附錄 B：Roadmap 發展藍圖 1. 概述與背景 1.1 Open Design 是什麼 Open Design（OD）是由 nexu-io 團隊主導開發的開源設計生成平台，定位為 Anthropic Claude Design 的全功能開源替代方案。經過近兩個月的高速迭代，OD 已從單純的「Web app + 本地 daemon」演進為原生桌面應用、MCP 整合、Plugin 市集三翼並進的完整平台，但核心設計原則維持不變：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/open-design-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Open Design 教學手冊 版本：v0.13.0「Stay in Flow」（對應 Open Design 0.13.0）\n最後更新：2026-07-02\n適用對象：資深工程師、前後端開發人員、UI/UX 設計師、AI 架構師、平台維運與採購決策者\n授權：Apache-2.0（部分內建 Plugin／Skill 沿用原始授權，詳見附錄 A）\n文件等級：企業標準技術白皮書\n目錄 1. 概述與背景 1.1 Open Design 是什麼 1.2 為何需要 Open Design 1.3 市場產品比較全景 1.4 BYOK 與 AMR 雙軌設計理念 1.5 適用場景 1.6 開源基石與技術譜系 2. 系統整體架構設計 2.1 高階架構圖 2.2 技術組成 2.3 AI Agent 整合架構 2.4 設計生成流程 2.5 Prompt Stack 組合機制 2.6 專案目錄結構與資料治理 2.7 與企業架構整合 3. 安裝與環境建置 3.1 系統需求 3.2 安裝路徑總覽 3.3 首次啟動與驗證 3.4 BYOK 設定 3.5 桌面版安裝 3.6 容器化與雲端部署 3.7 多語系與國際化 4. 核心機制解析 4.1 Skill 驅動架構 4.2 HTML PPT Studio 技能體系 4.3 Design System 設計系統 4.4 Visual Directions 視覺方向 4.5 Anti-AI-Slop 防劣質機制 4.6 媒體生成能力 4.7 Craft 設計參考系統 4.8 OD Library 與使用者資產庫 5. Plugin 系統與 MCP 整合 5.1 Plugin 市集架構與定位 5.2 官方 Plugin 六大分類 5.3 Plugin CLI 操作 5.4 建立與貢獻 Plugin 5.5 MCP Server 整合 5.6 Open Design AMR 模型路由器 6. AI 開發流程（企業級） 6.1 Web Application 開發 6.2 舊系統逆向工程 6.3 Framework 升級 6.4 企業文件與報表生成 7. Prompt Engineering 7.1 Prompt 結構設計原則 7.2 高品質 Prompt 範本 7.3 Prompt 最佳化策略 8. 設計品質控管機制 8.1 五維度自我審核機制 8.2 P0 / P1 / P2 Checklist 8.3 Artifact Lint API 8.4 Slop 黑名單 9. 輸出與整合 9.1 匯出格式 9.2 CI/CD 整合 9.3 Git / PR 開發流程整合 9.4 Claude Design ZIP 匯入 10. 系統維護與營運 10.1 日誌與監控 10.2 錯誤處理 10.3 Skill 管理 10.4 Design System 更新策略 10.5 資料備份與復原 11. 系統升級策略 11.1 Open Design 升級流程 11.2 相容性管理 11.3 版本控管策略 11.4 回滾機制 12. 團隊導入建議 12.1 開發團隊使用方式 12.2 設計師協作模式 12.3 AI Agent 分工策略 12.4 SSDLC 整合方式 13. 最佳實踐（Best Practices） 14. 常見問題與風險 15. 與企業架構深度整合 15.1 微服務架構整合 15.2 Clean Architecture 對應 15.3 前端框架整合（Vue / React） 15.4 後端框架整合（Spring Boot / FastAPI） 16. 檢查清單（Checklist） 附錄 A：參考來源與技術譜系 附錄 B：Roadmap 發展藍圖 1. 概述與背景 1.1 Open Design 是什麼 Open Design（OD）是由 nexu-io 團隊主導開發的開源設計生成平台，定位為 Anthropic Claude Design 的全功能開源替代方案。經過近兩個月的高速迭代，OD 已從單純的「Web app + 本地 daemon」演進為原生桌面應用、MCP 整合、Plugin 市集三翼並進的完整平台，但核心設計原則維持不變：\n","title":"Open Design 教學手冊"},{"content":"Warp + AI 開發完整教學手冊 版本：v1.2（2026-07-02）\n適用對象：資深工程師 / 架構師 / DevSecOps 團隊\nWarp 版本：v0.2026.06.03.09.49.stable_00（開源 AGPL v3 + MIT 雙授權）\n定位：企業標準技術白皮書\n開源倉庫：warpdotdev/warp（62,700+ Stars）\n官方文件：docs.warp.dev\n貢獻總覽：build.warp.dev\n目錄 1. Warp 架構總覽 1.1 Warp 在開發體系中的角色 1.2 Warp + Oz 平台架構圖 1.3 與傳統 Terminal 比較 2. 安裝與環境建置 2.1 各平台安裝方式 2.2 GPU 與 Shell 設定 2.3 開發工具整合 3. Warp 核心功能解析 3.1 Block（區塊系統） 3.2 Command Palette 3.3 AI 功能與多模型支援 3.4 Agent 進階能力 3.5 Code Editor 與 Code Review 3.6 Warp Drive（Workflows / Env 管理） 3.7 團隊共享機制 4. Warp + AI Coding Agent 整合 4.1 Claude Code 整合 4.2 GitHub Copilot CLI 整合 4.3 Gemini CLI 整合 4.4 OpenAI Codex CLI 整合 4.5 其他 CLI Agent 整合 4.6 AI Agent 比較表 5. Oz Cloud Agents（雲端代理） 5.1 Cloud Agents 概述 5.2 觸發機制與整合 5.3 自託管（Self-Hosting） 5.4 Oz Platform（CLI / API / SDK / Web App） 6. Warp 在 AI 開發流程中的應用 6.1 建立專案（Scaffold） 6.2 撰寫程式碼 6.3 測試（Unit / Integration） 6.4 Debug 6.5 Refactor 6.6 文件生成 7. 實戰：Web Application 開發（企業級） 7.1 前端（Vue 3 + TypeScript） 7.2 後端（Spring Boot） 7.3 API 設計 7.4 DB 操作 7.5 Warp + AI 全流程自動生成 8. 逆向工程（Legacy → Modern） 8.1 分析舊系統 8.2 用 Warp + AI 重建架構 8.3 自動產生文件 / API / 測試 9. Framework 升級 9.1 Spring Boot 2 → 3 / 4 升級 9.2 Java 8 → 21+ 升級 9.3 Warp + AI 升級自動化流程 10. Warp Drive（團隊協作） 10.1 建立企業 Workflow Library 10.2 指令模板設計 10.3 敏感資訊（Env）管理策略 11. SSDLC + Warp（安全開發） 11.1 SAST 靜態應用安全測試 11.2 Dependency Scan 相依套件掃描 11.3 Secret Scan 機密掃描 11.4 自動化安全檢查流程 12. 系統維運與監控 12.1 Log 分析 12.2 指令自動化 12.3 Incident 處理 13. 最佳實務（Best Practices） 13.1 Prompt Engineering 13.2 Workflow 設計 13.3 團隊導入策略 14. 常見錯誤與反模式 15. 結論與導入建議 15.1 適合導入的組織 15.2 ROI 分析 15.3 成熟度模型（Level 1 ~ Level 5） 附錄 A：檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：AI Prompt 範本庫 附錄 D：Warp 方案與計費 1. Warp 架構總覽 1.1 Warp 在開發體系中的角色 Warp 是新一代代理開發環境（Agentic Development Environment, ADE），由 Warp 公司以 Rust 語言打造，於 2026 年 4 月 28 日正式開源（AGPL v3 / MIT 雙授權，其中 UI 框架 warpui_core / warpui 兩個 crate 採 MIT，其餘核心程式碼採 AGPL v3），OpenAI 為創始贊助商。截至 2026 年 7 月，GitHub 已取得 62,700+ Stars，專案語言組成以 Rust（98.3%）為主體，開源後採「Agent-first」貢獻模式——人類貢獻者的角色從手寫程式碼轉為撰寫規格（Spec）、審查 AI 產出與調度 Agent 艦隊，此模式由 Oz 平台與 GPT 系列模型驅動。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/warp-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Warp + AI 開發完整教學手冊 版本：v1.2（2026-07-02）\n適用對象：資深工程師 / 架構師 / DevSecOps 團隊\nWarp 版本：v0.2026.06.03.09.49.stable_00（開源 AGPL v3 + MIT 雙授權）\n定位：企業標準技術白皮書\n開源倉庫：warpdotdev/warp（62,700+ Stars）\n官方文件：docs.warp.dev\n貢獻總覽：build.warp.dev\n目錄 1. Warp 架構總覽 1.1 Warp 在開發體系中的角色 1.2 Warp + Oz 平台架構圖 1.3 與傳統 Terminal 比較 2. 安裝與環境建置 2.1 各平台安裝方式 2.2 GPU 與 Shell 設定 2.3 開發工具整合 3. Warp 核心功能解析 3.1 Block（區塊系統） 3.2 Command Palette 3.3 AI 功能與多模型支援 3.4 Agent 進階能力 3.5 Code Editor 與 Code Review 3.6 Warp Drive（Workflows / Env 管理） 3.7 團隊共享機制 4. Warp + AI Coding Agent 整合 4.1 Claude Code 整合 4.2 GitHub Copilot CLI 整合 4.3 Gemini CLI 整合 4.4 OpenAI Codex CLI 整合 4.5 其他 CLI Agent 整合 4.6 AI Agent 比較表 5. Oz Cloud Agents（雲端代理） 5.1 Cloud Agents 概述 5.2 觸發機制與整合 5.3 自託管（Self-Hosting） 5.4 Oz Platform（CLI / API / SDK / Web App） 6. Warp 在 AI 開發流程中的應用 6.1 建立專案（Scaffold） 6.2 撰寫程式碼 6.3 測試（Unit / Integration） 6.4 Debug 6.5 Refactor 6.6 文件生成 7. 實戰：Web Application 開發（企業級） 7.1 前端（Vue 3 + TypeScript） 7.2 後端（Spring Boot） 7.3 API 設計 7.4 DB 操作 7.5 Warp + AI 全流程自動生成 8. 逆向工程（Legacy → Modern） 8.1 分析舊系統 8.2 用 Warp + AI 重建架構 8.3 自動產生文件 / API / 測試 9. Framework 升級 9.1 Spring Boot 2 → 3 / 4 升級 9.2 Java 8 → 21+ 升級 9.3 Warp + AI 升級自動化流程 10. Warp Drive（團隊協作） 10.1 建立企業 Workflow Library 10.2 指令模板設計 10.3 敏感資訊（Env）管理策略 11. SSDLC + Warp（安全開發） 11.1 SAST 靜態應用安全測試 11.2 Dependency Scan 相依套件掃描 11.3 Secret Scan 機密掃描 11.4 自動化安全檢查流程 12. 系統維運與監控 12.1 Log 分析 12.2 指令自動化 12.3 Incident 處理 13. 最佳實務（Best Practices） 13.1 Prompt Engineering 13.2 Workflow 設計 13.3 團隊導入策略 14. 常見錯誤與反模式 15. 結論與導入建議 15.1 適合導入的組織 15.2 ROI 分析 15.3 成熟度模型（Level 1 ~ Level 5） 附錄 A：檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：AI Prompt 範本庫 附錄 D：Warp 方案與計費 1. Warp 架構總覽 1.1 Warp 在開發體系中的角色 Warp 是新一代代理開發環境（Agentic Development Environment, ADE），由 Warp 公司以 Rust 語言打造，於 2026 年 4 月 28 日正式開源（AGPL v3 / MIT 雙授權，其中 UI 框架 warpui_core / warpui 兩個 crate 採 MIT，其餘核心程式碼採 AGPL v3），OpenAI 為創始贊助商。截至 2026 年 7 月，GitHub 已取得 62,700+ Stars，專案語言組成以 Rust（98.3%）為主體，開源後採「Agent-first」貢獻模式——人類貢獻者的角色從手寫程式碼轉為撰寫規格（Spec）、審查 AI 產出與調度 Agent 艦隊，此模式由 Oz 平台與 GPT 系列模型驅動。\n","title":"Warp 教學手冊"},{"content":"Claude Code Best Practice 教學手冊 版本：基於 GitHub 專案 shanraisshan/claude-code-best-practice（v2.1.181+，2026 年 7 月 1 日）\n適用對象：資深工程師、架構師、技術主管\n定位：企業標準技術白皮書 / 企業級 AI 輔助開發實戰手冊\n語言：繁體中文\n文件版本：v2.0 文件更新日期：2026 年 7 月 1 日\n目錄 第 1 章 專案介紹與核心理念 1.1 claude-code-best-practice 是什麼 1.2 Vibe Coding → Agentic Engineering 轉型 1.3 Hot Features 與 Beta 功能清單 1.4 為什麼適合企業級開發 第 2 章 整體架構設計 2.1 Claude Code 在系統中的角色 2.2 與 GitHub Copilot 的協作架構 2.3 Agentic Workflow 架構 2.4 多 Agent（Subagents）設計模式 2.5 與 CI/CD / DevOps 整合方式 第 3 章 安裝與環境建置 3.1 Claude Code CLI 安裝 3.2 Terminal 優化 3.3 專案初始化方式 3.4 開發環境最佳實踐 3.5 Devcontainers 與遠端開發 第 4 章 專案結構設計 4.1 CLAUDE.md 設計原則 4.2 .claude/rules/*.md 延遲載入機制 4.3 YAML Frontmatter 規則設計 4.4 多層規則架構 4.5 settings.json 設計與階層體系 4.6 Plugins 與 Marketplaces 第 5 章 Claude Code 核心工作流 5.1 Plan Mode（規劃模式） 5.2 任務拆解策略（50% Context Rule） 5.3 /compact 使用時機 5.4 長任務控制技巧 5.5 Auto Mode 與 Permission 模式 第 6 章 Agentic Engineering 實戰 6.1 Subagents 設計 6.2 多 Agent 協作模式 6.3 任務分派與回收機制 6.4 如何避免「全能型 Agent 失控」 6.5 Agent SDK 與程式化整合 第 7 章 Hooks 自動化機制 7.1 Hooks 概述與事件類型 7.2 SessionStart — 自動載入上下文 7.3 PreToolUse — 安全檢查 7.4 PostToolUse — 自動格式化與品質檢查 7.5 Stop Hook — 品質門檻 7.6 Permission Request Hook — 智能審批 7.7 HTTP Hooks 與進階機制 7.8 企業級 Hooks 最佳實踐總結 第 8 章 AI 輔助開發實戰場景 8.1 Web Application 開發 8.2 舊系統逆向工程 8.3 Framework 升級 第 9 章 CLI 與數據分析整合 9.1 BigQuery CLI 使用方式 9.2 無 SQL 分析流程 9.3 自動生成報表 第 10 章 與 GitHub Copilot 協作模式 10.1 Claude Code vs Copilot 分工 10.2 Code Generation vs Architecture Planning 10.3 雙 AI Workflow 設計 10.4 Cross-Model 與多引擎工作流 第 11 章 SSDLC 安全開發整合 11.1 Threat Modeling（威脅建模） 11.2 Secure Coding 規範 11.3 自動弱點掃描（SAST / DAST） 11.4 Sandbox 沙箱模式 11.5 Compliance（OWASP / ISO） 第 12 章 系統維護與最佳化 12.1 長期使用策略 12.2 Token 使用優化 12.3 成本控制（模型選擇） 12.4 記憶體系統管理 第 13 章 系統升級策略 13.1 Claude Code 規則升級 13.2 Prompt 演進管理 13.3 Agent 持續優化 13.4 Plugins、Channels 與 Routines 第 14 章 團隊導入建議 14.1 團隊導入流程（Phase 1~3） 14.2 開發規範 14.3 Code Review + AI Review 模式 14.4 常見錯誤與反模式 第 15 章 最佳實踐總結與 Checklist 15.1 專案初始化 Checklist 15.2 每日開發 Checklist 15.3 安全 Checklist 15.4 團隊導入 Checklist 15.5 升級前 Checklist 第 16 章 MCP（Model Context Protocol）整合指南 16.1 MCP 概述與架構 16.2 .mcp.json 設定語法 16.3 常用 MCP Servers 16.4 Cross-Model Workflows（跨模型整合） 16.5 MCP 權限設定 16.6 MCP 安全性最佳實踐 附錄 A：核心指令速查表（81 個官方指令） 附錄 B：主流開發工作流比較 附錄 C：Skill Collections 資源 附錄 D：參考資源 附錄 E：Agent Collections 資源 第 1 章 專案介紹與核心理念 1.1 claude-code-best-practice 是什麼 claude-code-best-practice 是由 Shayan Rais（shanraisshan）維護的開源專案，目前已累積超過 50,000 顆 GitHub Stars，是 Claude Code 社群中最受歡迎的實戰指南。該專案彙整了：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-claude-code-bast-practice-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Claude Code Best Practice 教學手冊 版本：基於 GitHub 專案 shanraisshan/claude-code-best-practice（v2.1.181+，2026 年 7 月 1 日）\n適用對象：資深工程師、架構師、技術主管\n定位：企業標準技術白皮書 / 企業級 AI 輔助開發實戰手冊\n語言：繁體中文\n文件版本：v2.0 文件更新日期：2026 年 7 月 1 日\n目錄 第 1 章 專案介紹與核心理念 1.1 claude-code-best-practice 是什麼 1.2 Vibe Coding → Agentic Engineering 轉型 1.3 Hot Features 與 Beta 功能清單 1.4 為什麼適合企業級開發 第 2 章 整體架構設計 2.1 Claude Code 在系統中的角色 2.2 與 GitHub Copilot 的協作架構 2.3 Agentic Workflow 架構 2.4 多 Agent（Subagents）設計模式 2.5 與 CI/CD / DevOps 整合方式 第 3 章 安裝與環境建置 3.1 Claude Code CLI 安裝 3.2 Terminal 優化 3.3 專案初始化方式 3.4 開發環境最佳實踐 3.5 Devcontainers 與遠端開發 第 4 章 專案結構設計 4.1 CLAUDE.md 設計原則 4.2 .claude/rules/*.md 延遲載入機制 4.3 YAML Frontmatter 規則設計 4.4 多層規則架構 4.5 settings.json 設計與階層體系 4.6 Plugins 與 Marketplaces 第 5 章 Claude Code 核心工作流 5.1 Plan Mode（規劃模式） 5.2 任務拆解策略（50% Context Rule） 5.3 /compact 使用時機 5.4 長任務控制技巧 5.5 Auto Mode 與 Permission 模式 第 6 章 Agentic Engineering 實戰 6.1 Subagents 設計 6.2 多 Agent 協作模式 6.3 任務分派與回收機制 6.4 如何避免「全能型 Agent 失控」 6.5 Agent SDK 與程式化整合 第 7 章 Hooks 自動化機制 7.1 Hooks 概述與事件類型 7.2 SessionStart — 自動載入上下文 7.3 PreToolUse — 安全檢查 7.4 PostToolUse — 自動格式化與品質檢查 7.5 Stop Hook — 品質門檻 7.6 Permission Request Hook — 智能審批 7.7 HTTP Hooks 與進階機制 7.8 企業級 Hooks 最佳實踐總結 第 8 章 AI 輔助開發實戰場景 8.1 Web Application 開發 8.2 舊系統逆向工程 8.3 Framework 升級 第 9 章 CLI 與數據分析整合 9.1 BigQuery CLI 使用方式 9.2 無 SQL 分析流程 9.3 自動生成報表 第 10 章 與 GitHub Copilot 協作模式 10.1 Claude Code vs Copilot 分工 10.2 Code Generation vs Architecture Planning 10.3 雙 AI Workflow 設計 10.4 Cross-Model 與多引擎工作流 第 11 章 SSDLC 安全開發整合 11.1 Threat Modeling（威脅建模） 11.2 Secure Coding 規範 11.3 自動弱點掃描（SAST / DAST） 11.4 Sandbox 沙箱模式 11.5 Compliance（OWASP / ISO） 第 12 章 系統維護與最佳化 12.1 長期使用策略 12.2 Token 使用優化 12.3 成本控制（模型選擇） 12.4 記憶體系統管理 第 13 章 系統升級策略 13.1 Claude Code 規則升級 13.2 Prompt 演進管理 13.3 Agent 持續優化 13.4 Plugins、Channels 與 Routines 第 14 章 團隊導入建議 14.1 團隊導入流程（Phase 1~3） 14.2 開發規範 14.3 Code Review + AI Review 模式 14.4 常見錯誤與反模式 第 15 章 最佳實踐總結與 Checklist 15.1 專案初始化 Checklist 15.2 每日開發 Checklist 15.3 安全 Checklist 15.4 團隊導入 Checklist 15.5 升級前 Checklist 第 16 章 MCP（Model Context Protocol）整合指南 16.1 MCP 概述與架構 16.2 .mcp.json 設定語法 16.3 常用 MCP Servers 16.4 Cross-Model Workflows（跨模型整合） 16.5 MCP 權限設定 16.6 MCP 安全性最佳實踐 附錄 A：核心指令速查表（81 個官方指令） 附錄 B：主流開發工作流比較 附錄 C：Skill Collections 資源 附錄 D：參考資源 附錄 E：Agent Collections 資源 第 1 章 專案介紹與核心理念 1.1 claude-code-best-practice 是什麼 claude-code-best-practice 是由 Shayan Rais（shanraisshan）維護的開源專案，目前已累積超過 50,000 顆 GitHub Stars，是 Claude Code 社群中最受歡迎的實戰指南。該專案彙整了：\n","title":"Claude Code Best Practice 教學手冊"},{"content":"Claude Code 建立 SSDLC Agent Team 教學手冊 版本：1.2.0 ｜ 最後更新：2026-07-15 ｜ 作者：企業級 AI Agent 架構顧問團隊\n適用對象：資深工程師、架構師、技術主管、DevSecOps、人員培訓\n定位：企業級白皮書等級教學手冊，可直接作為團隊導入與治理規範\n目錄 Ch 0：文件資訊與閱讀指南 0.1 文件基本資訊 0.2 使用前提與先決條件 0.3 閱讀地圖 0.4 功能狀態標示規則 0.5 核心名詞定義 0.6 版本變更紀錄 0.7 注意事項 Ch 1：總覽：什麼是 Claude Code SSDLC Agent Team 1.1 為什麼企業需要 SSDLC Agent Team 1.2 與其他方法的差異比較 1.3 Claude Code 在 SSDLC 各階段的角色 1.4 新系統開發 vs. 舊系統逆向工程 1.5 整體架構圖 1.6 企業導入價值 1.7 典型使用情境 1.8 實務建議 Ch 2：功能盤點與術語對照 2.1 14 項功能概述 2.2 功能矩陣表 2.3 平台差異比較表 2.4 概念差異比較表 2.5 功能穩定性狀態對照表 2.6 容易混淆術語表 2.7 Subagent 限制速查表 2.8 Config Hierarchy 與 CLAUDE.md 載入順序速查 2.9 實務建議 Ch 3：Claude Code SSDLC Agent Team 企業架構設計 3.1 Agent Team 整體架構圖 3.2 Agent 間協作流程圖 3.3 十個 Agent 角色詳細定義 3.4 Subagents vs Agent Teams 比較圖 3.5 Subagent vs Agent Team 決策矩陣 3.6 Agent 與 SSDLC 階段對應表 3.7 Agent RACI 矩陣 3.8 必須人工審核的清單 3.9 權限過大的風險與防範 3.10 實務建議 Ch 4：平台安裝與環境建置 4.1 安裝前提 4.2 Windows 安裝 4.3 macOS 安裝 4.4 Linux 安裝 4.5 VS Code Extension 安裝 4.6 CLI 認證方式 4.7 Permission Mode 比較表 4.8 公司允許模型設定 4.9 最佳起始設定 4.10 常見安裝錯誤與排除 4.11 實務建議 Ch 5：專案初始化與標準目錄設計 5.1 標準目錄樹 5.2 每個檔案與目錄用途說明 5.3 核心設定檔範例 5.4 命名規範 5.5 版本控管策略 5.6 .gitignore 建議 5.7 Plugins 與 Marketplace 策略 5.8 快速初始化腳本 5.9 實務建議 Ch 6：建立 Agent 與 Subagent 6.1 概念總覽：Subagent、Custom Subagent 與 Agent Team Teammate 6.2 Subagent 與主對話的差異 6.3 Subagent vs. Agent Team 比較 6.4 自動呼叫 vs. 明確呼叫 6.5 前景 vs. 背景執行與 Fork Mode 6.6 權限、Tools、Model 與 Isolation 6.7 巢狀呼叫限制 6.8 完整範例 6.9 Worktree Isolation 範例 6.10 Anti-Patterns（5 個常見錯誤） 6.11 Agent Team Subagent Definition 正確說明 6.12 內建 Subagents 與 Agent Team Hooks 6.13 實務建議 Ch 7：建立 Prompt Library 與 Team Prompt SOP 7.1 Prompt 在 Claude Code 生態系中的定位 7.2 企業級 Prompt Catalog 架構 7.3 版本管理策略 7.4 Prompt 範本集（10 個） 7.5 實務建議 Ch 8：建立 Skills 8.1 Skills 定義與核心概念 8.2 Skills 與相關功能的差異 8.3 自動觸發 vs. 手動觸發 8.4 Supporting Files 8.5 context:fork 與 Compaction 注意事項 8.5.1 Skills 進階 Frontmatter 欄位 8.5.2 Agent Skills 開放標準 8.5.3 Dynamic Context Injection（動態 Context 注入） 8.5.4 完整字串替換變數參考 8.5.5 Skill 內容生命週期與 Compaction 後的重新附加 8.5.6 內建 Skills（v2.1.145+） 8.5.7 Skill 評測框架（skill-creator Plugin） 8.5.8 Skill 疑難排解 8.6 完整 Skill 範例（7 個） 8.7 內建 Skills 參考 8.8 實務建議 Ch 9：建立 Hooks 與 Guardrails 9.1 Hooks 概述：確定性控制層 9.2 Hook 類型 9.3 Hook 事件 9.4 Matcher 語法 9.5 Hook 設定結構 9.6 Hooks 與 Permission Mode 的關係 9.7 Hook 除錯方式 9.8 範例 1：保護敏感檔案不可修改 9.9 範例 2：只允許唯讀 SQL 查詢 9.10 範例 3：變更後自動格式化 9.11 範例 4：Teammate 完成任務前的品質 Gate 9.12 範例 5：偵測設定檔變更並寫入 Audit Log 9.13 範例 6：自動補充 Compact 後的關鍵上下文 9.14 範例 7：HTTP Hook 串接企業稽核服務 9.15 實務建議 Ch 10：建立 Plugins 與 Marketplace Strategy 10.1 何時用 Plugin vs. Standalone Config 10.2 Plugin 結構 10.3 plugin.json Manifest 格式 10.4 Plugin Subagent 限制 10.5 安裝範圍 10.6 Marketplace 差異 10.7 安全與信任模型 10.8 範例 1：plugin.json 完整範例 10.9 範例 2：Skills 型 Plugin 10.10 範例 3：Agents 型 Plugin 10.11 範例 4：Hooks 型 Plugin 10.12 範例 5：Team Marketplace 設定 10.13 範例 6：Plugin 升級與版本控管策略 10.14 官方 Marketplace 內容總覽 10.15 Plugin 發現與管理指令 10.16 Plugin 驗證、快取與相依性 10.17 Skills 目錄型 Plugin 10.18 實務建議 Ch 11：Memory、CLAUDE.md 與知識治理 11.1 CLAUDE.md 的角色 11.2 CLAUDE.md 載入順序 11.3 Auto Memory 11.4 Memory vs. CLAUDE.md vs. Skills 11.5 Config Hierarchy 與記憶的關係 11.6 與其他文件的分工 11.7 記憶檔案避免膨脹與污染的方法 11.8 CLAUDE.md 範本 1：通用專案 11.9 CLAUDE.md 範本 2：Security 導向 11.10 CLAUDE.md 範本 3：Reverse Engineering 導向 11.11 記憶治理原則 11.12 清理與維護策略 11.13 實務建議 Ch 11-A：Output Styles（輸出風格） 11-A.1 概述 11-A.2 內建風格 11-A.3 自訂 Output Style 11-A.4 Plugin 提供的 Output Styles 11-A.5 keep-coding-instructions 欄位 11-A.6 切換 Output Style 11-A.7 SSDLC 建議 Ch 11-B：Scheduled Tasks（排程任務） 11-B.1 概述 11-B.2 建立排程任務 11-B.3 任務類型 11-B.4 /loop Skill 11-B.5 管理排程任務 11-B.6 搭配 Hooks 11-B.7 SSDLC 應用場景 11-B.8 治理建議 Ch 12：MCP 與 Tools 整合架構 12.1 什麼是 MCP（Model Context Protocol） 12.2 MCP Scope 與設定檔層級 12.3 Transport 機制：HTTP / stdio / SSE 12.4 OAuth、Headers 與安全整合 12.5 進階 MCP 功能 12.6 Claude Code 作為 MCP Server 12.7 MCP 與 Plugins 的整合 12.8 MCP 與企業治理 12.9 MCP 安全風險 12.10 完整範例 12.11 MCP 安裝與驗證 12.12 list_changed Notification 12.13 實務建議 Ch 13：Programmatic CLI、GitHub Actions 與 GitLab CI/CD 13.1 CLI 互動模式 vs Programmatic CLI 13.2 Programmatic CLI 用法 13.3 Provider 差異說明 13.4 GitHub Actions 整合 🟢 GA 13.5 GitLab CI/CD 整合 🟡 Beta 13.6 API Key / OIDC / Secret 治理 13.7 何時用互動式 vs CI 自動化 13.8 CI/CD 與 Agent 自動化流程圖 13.9 實務建議 Ch 14：將 Agent、Prompt、Skills、Hooks、Memory、MCP 融入 SSDLC 14.1 為什麼需要融入 SSDLC 14.2 Agent 協作圖 14.3 SSDLC 14 階段總覽 14.4 各階段詳細設計 14.5 SSDLC SOP 總覽表 14.6 安全 Gate 建議 14.7 KPI 建議 14.8 實務建議 Ch 15：舊系統逆向工程與現代化改造專章 15.1 方法論總覽 15.2 十一項任務說明 15.3 Reverse Engineering Agent 設計 15.4 專用 Prompt 範例 15.5 專用 Skills 範例 15.6 專用 Hooks / Guardrails 範例 15.7 輸出範本：架構還原文件格式 15.8 風險與注意事項 Ch 16：提供給其他團隊使用的共享 SOP 16.1 Team Onboarding 流程 16.2 Starter Repository 設計 16.3 共享 Plugins / Skills / Agents / Hooks 治理方式 16.4 文件模板 16.5 教育訓練計畫（4 階段） 16.6 支援模式（L1/L2/L3） 16.7 FAQ（團隊導入常見問題） 16.8 變更公告機制 16.9 例外申請流程 16.10 成熟度模型（5 個等級） 16.11 啟用 Checklist 16.12 角色分工表 16.13 常見阻力與解法 16.14 實務建議 Ch 17：安全、治理、稽核與成本控管 17.1 最小權限原則 17.2 Hooks Guardrails 17.3 Secrets 管理 17.4 敏感檔案保護 17.5 Prompt Injection 風險 17.6 MCP 風險 17.7 Plugin Marketplace 風險 17.8 Agent Teams 權限與成本風險 17.9 CI 自動化風險 17.10 Logs / Audit Trail / Compliance 17.11 風險矩陣表 17.12 模型使用策略 17.13 成本監控指標表 17.14 控制點設計表 17.15 不建議做法清單 17.16 實務建議 Ch 18：系統維護、升級與相容性管理 18.1 維護總覽 18.2 各項升級 SOP 18.3 相容矩陣範例 18.4 回滾計畫 18.5 版本管理建議 18.6 Experimental → GA 調整 18.7 文件更新流程 18.8 例行巡檢 18.9 升級排程建議 18.10 實務建議 Ch 19：完整實戰案例 19.1 案例一：新建 Spring Boot Web 專案 19.2 案例二：舊系統逆向工程與現代化 19.3 兩個案例的共通學習 19.4 實務建議 19.5 候選案例大綱：批次／排程工作現代化 Ch 20：FAQ 與 Troubleshooting 20.1 Agent Teams 為何無法啟動？ 20.2 Subagent 為何沒有被自動委派？ 20.3 Skills 為何沒有觸發？ 20.4 Hooks 為何沒有生效？ 20.5 MCP 為何沒有連上？ 20.6 Plugins 為何沒有載入？ 20.7 VS Code 與 CLI 為何行為不同？ 20.8 GitHub Actions 與 GitLab CI/CD 該怎麼選？ 20.9 Reverse Engineering 時如何降低幻覺？ 20.10 何時該用 subagent，何時該用 agent team？ 20.11 何時該用 hook，何時該用 skill？ 20.12 如何避免記憶污染與 context 膨脹？ 20.13 如何降低 token 成本？ 20.14 導入後如何量測 ROI／成效？ 20.15 實務建議 Ch 21：最佳實務、Anti-Patterns 與 Checklist 21.1 企業最佳實務（10 項） 21.2 團隊最佳實務（8 項） 21.3 開發者最佳實務（8 項） 21.4 Reverse Engineering 最佳實務（6 項） 21.5 常見錯誤 / Anti-Patterns（10 個） 21.6 Checklist 1：新團隊導入 Checklist 21.7 Checklist 2：專案初始化 Checklist 21.8 Checklist 3：SSDLC 各階段 Checklist 21.9 Checklist 4：上線前 Checklist 21.10 Checklist 5：升級前 Checklist 21.11 實務建議 Ch 22：附錄 — 可直接複製使用的完整範本 22.1 範本 1：CLAUDE.md 範本 22.2 範本 2：.claude/settings.json 範本 22.3 範本 3：.mcp.json 範本 22.4 範本 4：Subagent 範本 22.5 範本 5：SKILL.md 範本 22.6 範本 6：Hook 設定範本 22.7 範本 7：plugin.json 範本 22.8 範本 8：GitHub Actions Workflow 範本 22.9 範本 9：GitLab CI/CD Job 範本 22.10 範本 10：Reverse Engineering Prompt 範本 22.11 範本 11：Onboarding Checklist 範本 22.12 範本 12：Governance Policy 範本 22.13 實務建議 Ch 0：文件資訊與閱讀指南 0.1 文件基本資訊 欄位 內容 文件名稱 Claude Code 建立 SSDLC Agent Team 教學手冊 文件版本 1.1.1 最後更新日期 2026-06-26 作者 / 角色定位 企業級 AI Agent 架構顧問團隊 適用對象 資深工程師、架構師、技術主管、DevSecOps、人員培訓 前提條件 需有 Claude Code 存取權限、VS Code（v1.98.0+）、Git 授權範圍 限公司內部使用，不可外流 分類 技術白皮書 / 教學手冊 0.2 使用前提與先決條件 在閱讀本手冊前，請確認您已具備以下條件：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code-%E5%BB%BA%E7%AB%8B-ssdlc-agent-team-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Claude Code 建立 SSDLC Agent Team 教學手冊 版本：1.2.0 ｜ 最後更新：2026-07-15 ｜ 作者：企業級 AI Agent 架構顧問團隊\n適用對象：資深工程師、架構師、技術主管、DevSecOps、人員培訓\n定位：企業級白皮書等級教學手冊，可直接作為團隊導入與治理規範\n目錄 Ch 0：文件資訊與閱讀指南 0.1 文件基本資訊 0.2 使用前提與先決條件 0.3 閱讀地圖 0.4 功能狀態標示規則 0.5 核心名詞定義 0.6 版本變更紀錄 0.7 注意事項 Ch 1：總覽：什麼是 Claude Code SSDLC Agent Team 1.1 為什麼企業需要 SSDLC Agent Team 1.2 與其他方法的差異比較 1.3 Claude Code 在 SSDLC 各階段的角色 1.4 新系統開發 vs. 舊系統逆向工程 1.5 整體架構圖 1.6 企業導入價值 1.7 典型使用情境 1.8 實務建議 Ch 2：功能盤點與術語對照 2.1 14 項功能概述 2.2 功能矩陣表 2.3 平台差異比較表 2.4 概念差異比較表 2.5 功能穩定性狀態對照表 2.6 容易混淆術語表 2.7 Subagent 限制速查表 2.8 Config Hierarchy 與 CLAUDE.md 載入順序速查 2.9 實務建議 Ch 3：Claude Code SSDLC Agent Team 企業架構設計 3.1 Agent Team 整體架構圖 3.2 Agent 間協作流程圖 3.3 十個 Agent 角色詳細定義 3.4 Subagents vs Agent Teams 比較圖 3.5 Subagent vs Agent Team 決策矩陣 3.6 Agent 與 SSDLC 階段對應表 3.7 Agent RACI 矩陣 3.8 必須人工審核的清單 3.9 權限過大的風險與防範 3.10 實務建議 Ch 4：平台安裝與環境建置 4.1 安裝前提 4.2 Windows 安裝 4.3 macOS 安裝 4.4 Linux 安裝 4.5 VS Code Extension 安裝 4.6 CLI 認證方式 4.7 Permission Mode 比較表 4.8 公司允許模型設定 4.9 最佳起始設定 4.10 常見安裝錯誤與排除 4.11 實務建議 Ch 5：專案初始化與標準目錄設計 5.1 標準目錄樹 5.2 每個檔案與目錄用途說明 5.3 核心設定檔範例 5.4 命名規範 5.5 版本控管策略 5.6 .gitignore 建議 5.7 Plugins 與 Marketplace 策略 5.8 快速初始化腳本 5.9 實務建議 Ch 6：建立 Agent 與 Subagent 6.1 概念總覽：Subagent、Custom Subagent 與 Agent Team Teammate 6.2 Subagent 與主對話的差異 6.3 Subagent vs. Agent Team 比較 6.4 自動呼叫 vs. 明確呼叫 6.5 前景 vs. 背景執行與 Fork Mode 6.6 權限、Tools、Model 與 Isolation 6.7 巢狀呼叫限制 6.8 完整範例 6.9 Worktree Isolation 範例 6.10 Anti-Patterns（5 個常見錯誤） 6.11 Agent Team Subagent Definition 正確說明 6.12 內建 Subagents 與 Agent Team Hooks 6.13 實務建議 Ch 7：建立 Prompt Library 與 Team Prompt SOP 7.1 Prompt 在 Claude Code 生態系中的定位 7.2 企業級 Prompt Catalog 架構 7.3 版本管理策略 7.4 Prompt 範本集（10 個） 7.5 實務建議 Ch 8：建立 Skills 8.1 Skills 定義與核心概念 8.2 Skills 與相關功能的差異 8.3 自動觸發 vs. 手動觸發 8.4 Supporting Files 8.5 context:fork 與 Compaction 注意事項 8.5.1 Skills 進階 Frontmatter 欄位 8.5.2 Agent Skills 開放標準 8.5.3 Dynamic Context Injection（動態 Context 注入） 8.5.4 完整字串替換變數參考 8.5.5 Skill 內容生命週期與 Compaction 後的重新附加 8.5.6 內建 Skills（v2.1.145+） 8.5.7 Skill 評測框架（skill-creator Plugin） 8.5.8 Skill 疑難排解 8.6 完整 Skill 範例（7 個） 8.7 內建 Skills 參考 8.8 實務建議 Ch 9：建立 Hooks 與 Guardrails 9.1 Hooks 概述：確定性控制層 9.2 Hook 類型 9.3 Hook 事件 9.4 Matcher 語法 9.5 Hook 設定結構 9.6 Hooks 與 Permission Mode 的關係 9.7 Hook 除錯方式 9.8 範例 1：保護敏感檔案不可修改 9.9 範例 2：只允許唯讀 SQL 查詢 9.10 範例 3：變更後自動格式化 9.11 範例 4：Teammate 完成任務前的品質 Gate 9.12 範例 5：偵測設定檔變更並寫入 Audit Log 9.13 範例 6：自動補充 Compact 後的關鍵上下文 9.14 範例 7：HTTP Hook 串接企業稽核服務 9.15 實務建議 Ch 10：建立 Plugins 與 Marketplace Strategy 10.1 何時用 Plugin vs. Standalone Config 10.2 Plugin 結構 10.3 plugin.json Manifest 格式 10.4 Plugin Subagent 限制 10.5 安裝範圍 10.6 Marketplace 差異 10.7 安全與信任模型 10.8 範例 1：plugin.json 完整範例 10.9 範例 2：Skills 型 Plugin 10.10 範例 3：Agents 型 Plugin 10.11 範例 4：Hooks 型 Plugin 10.12 範例 5：Team Marketplace 設定 10.13 範例 6：Plugin 升級與版本控管策略 10.14 官方 Marketplace 內容總覽 10.15 Plugin 發現與管理指令 10.16 Plugin 驗證、快取與相依性 10.17 Skills 目錄型 Plugin 10.18 實務建議 Ch 11：Memory、CLAUDE.md 與知識治理 11.1 CLAUDE.md 的角色 11.2 CLAUDE.md 載入順序 11.3 Auto Memory 11.4 Memory vs. CLAUDE.md vs. Skills 11.5 Config Hierarchy 與記憶的關係 11.6 與其他文件的分工 11.7 記憶檔案避免膨脹與污染的方法 11.8 CLAUDE.md 範本 1：通用專案 11.9 CLAUDE.md 範本 2：Security 導向 11.10 CLAUDE.md 範本 3：Reverse Engineering 導向 11.11 記憶治理原則 11.12 清理與維護策略 11.13 實務建議 Ch 11-A：Output Styles（輸出風格） 11-A.1 概述 11-A.2 內建風格 11-A.3 自訂 Output Style 11-A.4 Plugin 提供的 Output Styles 11-A.5 keep-coding-instructions 欄位 11-A.6 切換 Output Style 11-A.7 SSDLC 建議 Ch 11-B：Scheduled Tasks（排程任務） 11-B.1 概述 11-B.2 建立排程任務 11-B.3 任務類型 11-B.4 /loop Skill 11-B.5 管理排程任務 11-B.6 搭配 Hooks 11-B.7 SSDLC 應用場景 11-B.8 治理建議 Ch 12：MCP 與 Tools 整合架構 12.1 什麼是 MCP（Model Context Protocol） 12.2 MCP Scope 與設定檔層級 12.3 Transport 機制：HTTP / stdio / SSE 12.4 OAuth、Headers 與安全整合 12.5 進階 MCP 功能 12.6 Claude Code 作為 MCP Server 12.7 MCP 與 Plugins 的整合 12.8 MCP 與企業治理 12.9 MCP 安全風險 12.10 完整範例 12.11 MCP 安裝與驗證 12.12 list_changed Notification 12.13 實務建議 Ch 13：Programmatic CLI、GitHub Actions 與 GitLab CI/CD 13.1 CLI 互動模式 vs Programmatic CLI 13.2 Programmatic CLI 用法 13.3 Provider 差異說明 13.4 GitHub Actions 整合 🟢 GA 13.5 GitLab CI/CD 整合 🟡 Beta 13.6 API Key / OIDC / Secret 治理 13.7 何時用互動式 vs CI 自動化 13.8 CI/CD 與 Agent 自動化流程圖 13.9 實務建議 Ch 14：將 Agent、Prompt、Skills、Hooks、Memory、MCP 融入 SSDLC 14.1 為什麼需要融入 SSDLC 14.2 Agent 協作圖 14.3 SSDLC 14 階段總覽 14.4 各階段詳細設計 14.5 SSDLC SOP 總覽表 14.6 安全 Gate 建議 14.7 KPI 建議 14.8 實務建議 Ch 15：舊系統逆向工程與現代化改造專章 15.1 方法論總覽 15.2 十一項任務說明 15.3 Reverse Engineering Agent 設計 15.4 專用 Prompt 範例 15.5 專用 Skills 範例 15.6 專用 Hooks / Guardrails 範例 15.7 輸出範本：架構還原文件格式 15.8 風險與注意事項 Ch 16：提供給其他團隊使用的共享 SOP 16.1 Team Onboarding 流程 16.2 Starter Repository 設計 16.3 共享 Plugins / Skills / Agents / Hooks 治理方式 16.4 文件模板 16.5 教育訓練計畫（4 階段） 16.6 支援模式（L1/L2/L3） 16.7 FAQ（團隊導入常見問題） 16.8 變更公告機制 16.9 例外申請流程 16.10 成熟度模型（5 個等級） 16.11 啟用 Checklist 16.12 角色分工表 16.13 常見阻力與解法 16.14 實務建議 Ch 17：安全、治理、稽核與成本控管 17.1 最小權限原則 17.2 Hooks Guardrails 17.3 Secrets 管理 17.4 敏感檔案保護 17.5 Prompt Injection 風險 17.6 MCP 風險 17.7 Plugin Marketplace 風險 17.8 Agent Teams 權限與成本風險 17.9 CI 自動化風險 17.10 Logs / Audit Trail / Compliance 17.11 風險矩陣表 17.12 模型使用策略 17.13 成本監控指標表 17.14 控制點設計表 17.15 不建議做法清單 17.16 實務建議 Ch 18：系統維護、升級與相容性管理 18.1 維護總覽 18.2 各項升級 SOP 18.3 相容矩陣範例 18.4 回滾計畫 18.5 版本管理建議 18.6 Experimental → GA 調整 18.7 文件更新流程 18.8 例行巡檢 18.9 升級排程建議 18.10 實務建議 Ch 19：完整實戰案例 19.1 案例一：新建 Spring Boot Web 專案 19.2 案例二：舊系統逆向工程與現代化 19.3 兩個案例的共通學習 19.4 實務建議 19.5 候選案例大綱：批次／排程工作現代化 Ch 20：FAQ 與 Troubleshooting 20.1 Agent Teams 為何無法啟動？ 20.2 Subagent 為何沒有被自動委派？ 20.3 Skills 為何沒有觸發？ 20.4 Hooks 為何沒有生效？ 20.5 MCP 為何沒有連上？ 20.6 Plugins 為何沒有載入？ 20.7 VS Code 與 CLI 為何行為不同？ 20.8 GitHub Actions 與 GitLab CI/CD 該怎麼選？ 20.9 Reverse Engineering 時如何降低幻覺？ 20.10 何時該用 subagent，何時該用 agent team？ 20.11 何時該用 hook，何時該用 skill？ 20.12 如何避免記憶污染與 context 膨脹？ 20.13 如何降低 token 成本？ 20.14 導入後如何量測 ROI／成效？ 20.15 實務建議 Ch 21：最佳實務、Anti-Patterns 與 Checklist 21.1 企業最佳實務（10 項） 21.2 團隊最佳實務（8 項） 21.3 開發者最佳實務（8 項） 21.4 Reverse Engineering 最佳實務（6 項） 21.5 常見錯誤 / Anti-Patterns（10 個） 21.6 Checklist 1：新團隊導入 Checklist 21.7 Checklist 2：專案初始化 Checklist 21.8 Checklist 3：SSDLC 各階段 Checklist 21.9 Checklist 4：上線前 Checklist 21.10 Checklist 5：升級前 Checklist 21.11 實務建議 Ch 22：附錄 — 可直接複製使用的完整範本 22.1 範本 1：CLAUDE.md 範本 22.2 範本 2：.claude/settings.json 範本 22.3 範本 3：.mcp.json 範本 22.4 範本 4：Subagent 範本 22.5 範本 5：SKILL.md 範本 22.6 範本 6：Hook 設定範本 22.7 範本 7：plugin.json 範本 22.8 範本 8：GitHub Actions Workflow 範本 22.9 範本 9：GitLab CI/CD Job 範本 22.10 範本 10：Reverse Engineering Prompt 範本 22.11 範本 11：Onboarding Checklist 範本 22.12 範本 12：Governance Policy 範本 22.13 實務建議 Ch 0：文件資訊與閱讀指南 0.1 文件基本資訊 欄位 內容 文件名稱 Claude Code 建立 SSDLC Agent Team 教學手冊 文件版本 1.1.1 最後更新日期 2026-06-26 作者 / 角色定位 企業級 AI Agent 架構顧問團隊 適用對象 資深工程師、架構師、技術主管、DevSecOps、人員培訓 前提條件 需有 Claude Code 存取權限、VS Code（v1.98.0+）、Git 授權範圍 限公司內部使用，不可外流 分類 技術白皮書 / 教學手冊 0.2 使用前提與先決條件 在閱讀本手冊前，請確認您已具備以下條件：\n","title":"Claude Code 建立 SSDLC Agent Team 教學手冊"},{"content":"Skill_Seekers 教學手冊（企業實戰版） 版本：v3.8.0（2026-07）\n適用對象：資深工程師、AI 架構師、DevOps 工程師\n授權：MIT License\n官方網站：https://skillseekersweb.com/\nGitHub：https://github.com/yusufkaraaslan/Skill_Seekers\n目錄 1. 概述（Overview） 1.1 Skill_Seekers 是什麼 1.2 為什麼它是 AI Data Layer 1.3 在 AI 開發中的定位 1.4 核心數據一覽 2. 整體系統架構設計（Architecture） 2.1 系統架構圖 2.2 模組架構說明 2.3 Data Flow：從資料到 AI 使用 2.4 與企業系統整合架構 3. 安裝與環境建置（Installation） 3.1 系統需求 3.2 安裝方式 3.3 Docker 部署 3.4 初始化與驗證 3.5 MCP Server 設定 3.6 常見錯誤與排除 4. Skill_Seekers 設定（Configuration） 4.1 Config 檔案結構 4.2 預設 Config（24+ Presets） 4.3 Workflow 增強設定 4.4 多資料來源設定 4.5 AST 分析設定 4.6 私有 Config 儲存庫 5. Skill 建立流程（核心） 5.1 統一建立指令（create） 5.2 從 GitHub Repo 建立 Skill 5.3 從 API 文件（OpenAPI）建立 Skill 5.4 從技術文件網站建立 Skill 5.5 從 PDF / Word / EPUB 建立 Skill 5.6 從影片建立 Skill 5.7 Unified Multi-Source Skill 5.8 Skill 結構設計（Schema） 5.9 Metadata / Tagging 策略 5.10 專案知識盤點（scan） 6. 與 AI 開發工具整合（重點） 6.1 Claude Code 整合 6.2 GitHub Copilot 整合 6.3 Cursor / Windsurf / Cline 與更多 Agent 整合 6.4 MCP 整合（40 Tools） 6.5 Agent-Agnostic 架構 7. Web Application 開發實戰（Hands-on） 7.1 實戰案例：Spring Boot + Vue 專案 7.2 API 開發加速 7.3 文件生成自動化 7.4 測試生成 7.5 AI 協作流程（Dev Flow） 8. SSDLC（安全開發流程） 8.1 安全開發整合架構 8.2 Secure Coding with Skills 8.3 SAST / DAST 整合 8.4 Dependency Scan 8.5 Prompt Injection 防護 9. 系統維運（Maintenance） 9.1 Skill 更新策略 9.2 資料同步機制 9.3 效能優化 9.4 Log / Monitoring 9.5 成本控制 10. 系統升級（Upgrade） 10.1 版本升級策略 10.2 Config Migration 10.3 向下相容設計 11. 最佳實務（Best Practices） 11.1 團隊導入建議 11.2 Skill 設計原則 11.3 Prompt Engineering 建議 11.4 常見錯誤與 Anti-Patterns 12. 附錄（Appendix） 12.1 CLI 指令大全 12.2 Config 範例 12.3 Troubleshooting 12.4 環境變數一覽 12.5 檢查清單（Checklist） 1. 概述（Overview） 1.1 Skill_Seekers 是什麼 Skill Seekers 是一個開源的 AI Data Layer 工具，由 Yusuf Karaaslan 開發，採用 MIT License。它能將 18 種以上的非結構化資料來源（文件網站、GitHub Repo、PDF、影片、Jupyter Notebook、Confluence Wiki、Notion、OpenAPI Spec 等）轉換為結構化的 AI 知識資產，供 Claude Code、Gemini、OpenAI、LangChain、Cursor 等 12+ AI 平台直接使用。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/skill_seekers%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Skill_Seekers 教學手冊（企業實戰版） 版本：v3.8.0（2026-07）\n適用對象：資深工程師、AI 架構師、DevOps 工程師\n授權：MIT License\n官方網站：https://skillseekersweb.com/\nGitHub：https://github.com/yusufkaraaslan/Skill_Seekers\n目錄 1. 概述（Overview） 1.1 Skill_Seekers 是什麼 1.2 為什麼它是 AI Data Layer 1.3 在 AI 開發中的定位 1.4 核心數據一覽 2. 整體系統架構設計（Architecture） 2.1 系統架構圖 2.2 模組架構說明 2.3 Data Flow：從資料到 AI 使用 2.4 與企業系統整合架構 3. 安裝與環境建置（Installation） 3.1 系統需求 3.2 安裝方式 3.3 Docker 部署 3.4 初始化與驗證 3.5 MCP Server 設定 3.6 常見錯誤與排除 4. Skill_Seekers 設定（Configuration） 4.1 Config 檔案結構 4.2 預設 Config（24+ Presets） 4.3 Workflow 增強設定 4.4 多資料來源設定 4.5 AST 分析設定 4.6 私有 Config 儲存庫 5. Skill 建立流程（核心） 5.1 統一建立指令（create） 5.2 從 GitHub Repo 建立 Skill 5.3 從 API 文件（OpenAPI）建立 Skill 5.4 從技術文件網站建立 Skill 5.5 從 PDF / Word / EPUB 建立 Skill 5.6 從影片建立 Skill 5.7 Unified Multi-Source Skill 5.8 Skill 結構設計（Schema） 5.9 Metadata / Tagging 策略 5.10 專案知識盤點（scan） 6. 與 AI 開發工具整合（重點） 6.1 Claude Code 整合 6.2 GitHub Copilot 整合 6.3 Cursor / Windsurf / Cline 與更多 Agent 整合 6.4 MCP 整合（40 Tools） 6.5 Agent-Agnostic 架構 7. Web Application 開發實戰（Hands-on） 7.1 實戰案例：Spring Boot + Vue 專案 7.2 API 開發加速 7.3 文件生成自動化 7.4 測試生成 7.5 AI 協作流程（Dev Flow） 8. SSDLC（安全開發流程） 8.1 安全開發整合架構 8.2 Secure Coding with Skills 8.3 SAST / DAST 整合 8.4 Dependency Scan 8.5 Prompt Injection 防護 9. 系統維運（Maintenance） 9.1 Skill 更新策略 9.2 資料同步機制 9.3 效能優化 9.4 Log / Monitoring 9.5 成本控制 10. 系統升級（Upgrade） 10.1 版本升級策略 10.2 Config Migration 10.3 向下相容設計 11. 最佳實務（Best Practices） 11.1 團隊導入建議 11.2 Skill 設計原則 11.3 Prompt Engineering 建議 11.4 常見錯誤與 Anti-Patterns 12. 附錄（Appendix） 12.1 CLI 指令大全 12.2 Config 範例 12.3 Troubleshooting 12.4 環境變數一覽 12.5 檢查清單（Checklist） 1. 概述（Overview） 1.1 Skill_Seekers 是什麼 Skill Seekers 是一個開源的 AI Data Layer 工具，由 Yusuf Karaaslan 開發，採用 MIT License。它能將 18 種以上的非結構化資料來源（文件網站、GitHub Repo、PDF、影片、Jupyter Notebook、Confluence Wiki、Notion、OpenAPI Spec 等）轉換為結構化的 AI 知識資產，供 Claude Code、Gemini、OpenAI、LangChain、Cursor 等 12+ AI 平台直接使用。\n","title":"Skill_Seekers教學手冊"},{"content":"GSD Pi 教學手冊（Enterprise Edition） 版本：v1.3.0（open-gsd/gsd-pi 基線） ｜ 最後更新：2026-07-01 適用對象：資深後端 / 前端 / 架構師 / DevOps 工程師 授權：MIT License 官方網站：www.opengsd.net ｜ Web 配置器：pi.opengsd.net\n⚠️ 重要公告：GSD-2 專案已於 2026 年 5 月遷移至新的組織與倉庫。原 gsd-build/gsd-2（v3.0.0 最終版，7.7k Stars，已封存）不再是活躍開發地點，所有後續開發、Issues、Releases 皆在 open-gsd/gsd-pi 進行。npm 套件名稱也從 gsd-pi 更名為 @opengsd/gsd-pi。本文件已依據最新版本 v1.3.0（2026-06-21）全面更新。\n目錄 1. 總覽（Overview） 1.1 GSD Pi 是什麼 1.2 與傳統開發模式差異 1.3 適用場景 1.4 版本演進與生態系 1.5 從 GSD-2 遷移至 GSD Pi 2. 核心概念（Core Concepts） 2.1 Meta Prompting 2.2 Context Engineering 2.3 Spec-Driven Development 2.4 Agent Workflow 2.5 Knowledge Graph（KNOWLEDGE.md） 2.6 Reactive Task Execution 2.7 Context Pressure Monitor 2.8 Planning Depth — 深度探索模式 2.9 Per-Phase Thinking Level — 分階段思考深度 3. 系統架構設計（Architecture） 3.1 GSD Pi 內部架構 3.2 GSD Pi + 微服務架構整合 3.3 與 Spring Boot 架構整合方式 3.4 與前端（Vue）協作方式 3.5 與 CI/CD 整合方式 3.6 與 SSDLC 整合方式 3.7 MCP Server 架構 3.8 Cloud MCP Gateway 架構 4. 安裝與環境建置（Installation） 4.1 系統需求 4.2 安裝步驟 4.3 從舊版遷移安裝 4.4 首次啟動與設定 4.5 MCP Server 啟動 4.6 VS Code 擴充設定 4.7 與 Claude Code / Copilot 整合 4.8 Docker Sandbox 部署 4.9 Web 介面啟動 4.10 常見安裝問題與排除 5. 專案初始化（Project Setup） 5.1 專案目錄結構 5.2 GSD 標準檔案說明 5.3 初始化流程 6. Spec-Driven 開發流程 6.1 整體流程概覽 6.2 步驟 1：撰寫規格（Spec） 6.3 步驟 2：拆解任務（Tasks） 6.4 步驟 3：指派 AI Agent 6.5 步驟 4：產生程式碼 6.6 步驟 5：測試與驗證 6.7 步驟 6：回饋到 KNOWLEDGE.md 7. AI Agent 協作模式 7.1 多 Agent 協作架構 7.2 Claude Code 使用方式 7.3 Copilot 使用方式 7.4 Agent 任務切分策略 7.5 雙終端機工作流 7.6 Quick Mode — 快速任務 7.7 Session 可觀察性命令 7.8 Telegram 遠端控制 7.9 Web 介面管理 7.10 思緒捕捉（Capture）與工作流視覺化 7.11 Visual Briefs — 視覺化簡報產出 7.12 自訂工作流插件（Custom Workflows） 8. 知識圖譜與學習系統 8.1 KNOWLEDGE.md 設計方式 8.2 記憶架構（v2.77 ADR-013） 8.3 Knowledge Graph 建立 8.4 如何提升 AI 理解能力 9. 技能管理（Skill Management） 9.1 技能系統概述 9.2 技能發現與 Skill Rules 9.3 技能評估方式 9.4 Agent 健康度監控 9.5 擴充套件管理（Extensions） 10. 實戰範例 11. SSDLC 整合（安全開發） 12. 系統維護（Maintenance） 12.1 如何更新 Spec 12.2 如何修復 Bug 12.3 Forensics — 失敗調查 12.4 如何讓 AI 持續學習 12.5 Provider Error Recovery 12.6 Failure Recovery 12.7 Pipeline Architecture 12.8 清理與歸檔 12.9 Token Telemetry 與成本追蹤 12.10 Unit Closeout 模組 13. 系統升級（Upgrade） 13.1 從 gsd-build/gsd-2 遷移到 open-gsd/gsd-pi 14. 最佳實務（Best Practices） 14.1 Prompt 設計原則 14.2 Context 控制技巧 14.3 避免 Hallucination 14.4 大型專案管理技巧 14.5 成本控制 14.6 Hooks 系統 14.7 Reactive Task Execution 實務 14.8 企業指引範本 14.9 Per-Model MCP 過濾與 URL 安全 15. 常見問題（FAQ） 15.1 AI 不照 Spec 怎麼辦？ 15.2 程式碼品質不佳？ 15.3 Context 過大怎麼辦？ 15.4 Auto Mode 卡住怎麼辦？ 15.5 如何恢復崩潰的 Session？ 15.6 團隊成員 Milestone ID 衝突？ 15.7 如何在企業防火牆環境使用？ 15.8 如何使用本地 LLM（Ollama）？ 16. 團隊導入建議（Enterprise Adoption） 16.1 導入策略（分階段） 16.2 教育訓練方式 16.3 Governance（治理） 17. 檢查清單（Checklist） 17.1 環境建置 Checklist 17.2 專案初始化 Checklist 17.3 日常開發 Checklist 17.4 安全 Checklist 17.5 團隊協作 Checklist 17.6 GSD Pi 命令速查表 附錄 A：GSD Pi 內建擴充套件一覽 附錄 B：相關資源 附錄 C：MCP Server 設定指南 C.1 概述 C.2 連線外部 MCP Server C.3 驗證 MCP 連線 C.4 匯入其他工具的 MCP 設定 C.5 Cloud MCP Gateway C.6 企業注意事項 附錄 D：進階設定參考 D.1 Dynamic Model Routing D.2 Notifications D.3 Context Management D.4 Git 進階設定 D.5 GitHub Sync D.6 Forensics 和除錯 D.7 Parallel Orchestration D.8 Custom Model Definitions D.9 其他設定 附錄 E：環境變數一覽 1. 總覽（Overview） 1.1 GSD Pi 是什麼 GSD Pi（前稱 GSD-2，Get Stuff Done，採用 Pi SDK）是一套 Meta-Prompting、Context Engineering 與 Spec-Driven Development 系統，專為 AI Agent 長時間自主開發而設計。它不是提示框架（Prompt Framework），而是一個獨立的 TypeScript CLI 應用程式，能夠真正控制 Agent 的 Context Window、Session 生命週期與 Git 策略。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/gsd-2%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GSD Pi 教學手冊（Enterprise Edition） 版本：v1.3.0（open-gsd/gsd-pi 基線） ｜ 最後更新：2026-07-01 適用對象：資深後端 / 前端 / 架構師 / DevOps 工程師 授權：MIT License 官方網站：www.opengsd.net ｜ Web 配置器：pi.opengsd.net\n⚠️ 重要公告：GSD-2 專案已於 2026 年 5 月遷移至新的組織與倉庫。原 gsd-build/gsd-2（v3.0.0 最終版，7.7k Stars，已封存）不再是活躍開發地點，所有後續開發、Issues、Releases 皆在 open-gsd/gsd-pi 進行。npm 套件名稱也從 gsd-pi 更名為 @opengsd/gsd-pi。本文件已依據最新版本 v1.3.0（2026-06-21）全面更新。\n目錄 1. 總覽（Overview） 1.1 GSD Pi 是什麼 1.2 與傳統開發模式差異 1.3 適用場景 1.4 版本演進與生態系 1.5 從 GSD-2 遷移至 GSD Pi 2. 核心概念（Core Concepts） 2.1 Meta Prompting 2.2 Context Engineering 2.3 Spec-Driven Development 2.4 Agent Workflow 2.5 Knowledge Graph（KNOWLEDGE.md） 2.6 Reactive Task Execution 2.7 Context Pressure Monitor 2.8 Planning Depth — 深度探索模式 2.9 Per-Phase Thinking Level — 分階段思考深度 3. 系統架構設計（Architecture） 3.1 GSD Pi 內部架構 3.2 GSD Pi + 微服務架構整合 3.3 與 Spring Boot 架構整合方式 3.4 與前端（Vue）協作方式 3.5 與 CI/CD 整合方式 3.6 與 SSDLC 整合方式 3.7 MCP Server 架構 3.8 Cloud MCP Gateway 架構 4. 安裝與環境建置（Installation） 4.1 系統需求 4.2 安裝步驟 4.3 從舊版遷移安裝 4.4 首次啟動與設定 4.5 MCP Server 啟動 4.6 VS Code 擴充設定 4.7 與 Claude Code / Copilot 整合 4.8 Docker Sandbox 部署 4.9 Web 介面啟動 4.10 常見安裝問題與排除 5. 專案初始化（Project Setup） 5.1 專案目錄結構 5.2 GSD 標準檔案說明 5.3 初始化流程 6. Spec-Driven 開發流程 6.1 整體流程概覽 6.2 步驟 1：撰寫規格（Spec） 6.3 步驟 2：拆解任務（Tasks） 6.4 步驟 3：指派 AI Agent 6.5 步驟 4：產生程式碼 6.6 步驟 5：測試與驗證 6.7 步驟 6：回饋到 KNOWLEDGE.md 7. AI Agent 協作模式 7.1 多 Agent 協作架構 7.2 Claude Code 使用方式 7.3 Copilot 使用方式 7.4 Agent 任務切分策略 7.5 雙終端機工作流 7.6 Quick Mode — 快速任務 7.7 Session 可觀察性命令 7.8 Telegram 遠端控制 7.9 Web 介面管理 7.10 思緒捕捉（Capture）與工作流視覺化 7.11 Visual Briefs — 視覺化簡報產出 7.12 自訂工作流插件（Custom Workflows） 8. 知識圖譜與學習系統 8.1 KNOWLEDGE.md 設計方式 8.2 記憶架構（v2.77 ADR-013） 8.3 Knowledge Graph 建立 8.4 如何提升 AI 理解能力 9. 技能管理（Skill Management） 9.1 技能系統概述 9.2 技能發現與 Skill Rules 9.3 技能評估方式 9.4 Agent 健康度監控 9.5 擴充套件管理（Extensions） 10. 實戰範例 11. SSDLC 整合（安全開發） 12. 系統維護（Maintenance） 12.1 如何更新 Spec 12.2 如何修復 Bug 12.3 Forensics — 失敗調查 12.4 如何讓 AI 持續學習 12.5 Provider Error Recovery 12.6 Failure Recovery 12.7 Pipeline Architecture 12.8 清理與歸檔 12.9 Token Telemetry 與成本追蹤 12.10 Unit Closeout 模組 13. 系統升級（Upgrade） 13.1 從 gsd-build/gsd-2 遷移到 open-gsd/gsd-pi 14. 最佳實務（Best Practices） 14.1 Prompt 設計原則 14.2 Context 控制技巧 14.3 避免 Hallucination 14.4 大型專案管理技巧 14.5 成本控制 14.6 Hooks 系統 14.7 Reactive Task Execution 實務 14.8 企業指引範本 14.9 Per-Model MCP 過濾與 URL 安全 15. 常見問題（FAQ） 15.1 AI 不照 Spec 怎麼辦？ 15.2 程式碼品質不佳？ 15.3 Context 過大怎麼辦？ 15.4 Auto Mode 卡住怎麼辦？ 15.5 如何恢復崩潰的 Session？ 15.6 團隊成員 Milestone ID 衝突？ 15.7 如何在企業防火牆環境使用？ 15.8 如何使用本地 LLM（Ollama）？ 16. 團隊導入建議（Enterprise Adoption） 16.1 導入策略（分階段） 16.2 教育訓練方式 16.3 Governance（治理） 17. 檢查清單（Checklist） 17.1 環境建置 Checklist 17.2 專案初始化 Checklist 17.3 日常開發 Checklist 17.4 安全 Checklist 17.5 團隊協作 Checklist 17.6 GSD Pi 命令速查表 附錄 A：GSD Pi 內建擴充套件一覽 附錄 B：相關資源 附錄 C：MCP Server 設定指南 C.1 概述 C.2 連線外部 MCP Server C.3 驗證 MCP 連線 C.4 匯入其他工具的 MCP 設定 C.5 Cloud MCP Gateway C.6 企業注意事項 附錄 D：進階設定參考 D.1 Dynamic Model Routing D.2 Notifications D.3 Context Management D.4 Git 進階設定 D.5 GitHub Sync D.6 Forensics 和除錯 D.7 Parallel Orchestration D.8 Custom Model Definitions D.9 其他設定 附錄 E：環境變數一覽 1. 總覽（Overview） 1.1 GSD Pi 是什麼 GSD Pi（前稱 GSD-2，Get Stuff Done，採用 Pi SDK）是一套 Meta-Prompting、Context Engineering 與 Spec-Driven Development 系統，專為 AI Agent 長時間自主開發而設計。它不是提示框架（Prompt Framework），而是一個獨立的 TypeScript CLI 應用程式，能夠真正控制 Agent 的 Context Window、Session 生命週期與 Git 策略。\n","title":"GSD Pi 教學手冊（原 GSD-2）"},{"content":"GitHub Copilot SSDLC（安全軟體開發生命週期）教學手冊 版本：v2.3\n最後更新：2026 年 5 月 28 日\n適用對象：軟體開發團隊全體成員（資深工程師導向）\n文件性質：企業級內部技術規範與教育訓練教材（企業標準技術白皮書等級）\n撰寫者：軟體架構團隊\n審核者：技術委員會\n參考來源：GitHub Copilot 官方文件、軟體開發標準程序教學手冊、Agent Skills 開放標準、Copilot Customization Cheat Sheet\n📋 目錄 第一章：SSDLC 總覽（結合 AI） 1.1 SSDLC 定義 1.2 傳統 SDLC vs AI SSDLC 1.3 GitHub Copilot 在各階段的角色 1.4 GitHub Copilot 方案與定價 1.5 DevSecOps + AI 整合 第二章：系統整體架構設計（Architecture） 2.1 企業級系統架構總覽 2.2 分層設計（Layered Architecture） 2.3 微服務與模組化設計 2.4 Clean Architecture 應用 第三章：開發環境建置（Installation \u0026amp; Setup） 3.1 工具安裝 3.2 GitHub Copilot 設定 3.3 專案初始化與分支策略 第四章：SSDLC 各階段 + Copilot 實戰 4.1 需求分析（Requirement） 4.2 系統設計（Design） 4.3 開發（Development） 4.4 測試（Testing） 4.5 安全（Security） 4.6 部署（Deployment） 4.7 維運（Operation） 第五章：Copilot 進階使用（AI Engineering） 5.1 Prompt Engineering 5.2 Context 設計與 Custom Instructions 5.3 Prompt Files 與 Path-Specific Instructions 5.4 多檔案生成與 Refactoring 5.5 Code Review 自動化 5.6 AI Pair Programming 最佳實務 5.7 Copilot Cloud Agent 進階應用 5.8 Copilot CLI 內建 Agents 5.9 第三方 Coding Agents 5.10 Agent Skills 開放標準 第六章：自我學習與優化機制 6.1 AI 自我優化 Workflow 6.2 Prompt 優化迴圈 6.3 知識庫（Knowledge Base） 6.4 文件自動生成 第七章：實戰案例（銀行系統） 7.1 Web Application 開發 7.2 FTP 上傳流程 7.3 資料驗證流程 7.4 高可用架構設計 第八章：系統維護與升級 8.1 Copilot 升級策略 8.2 Plugin 管理 8.3 相容性管理 8.4 技術債處理 第九章：最佳實務（Best Practices） 9.1 開發規範 9.2 安全規範 9.3 AI 使用規範 9.4 團隊協作模式 第十章：AI 治理與合規（AI Governance） 10.1 AI 使用政策 10.2 智慧財產權與授權 10.3 安全與資料保護 10.4 合規檢核清單 附錄 A：檢查清單（Checklist） 附錄 B：常用 Prompt 範本 附錄 C：術語對照表 附錄 D：GitHub Copilot 方案功能對照表 第一章：SSDLC 總覽（結合 AI） 1.1 SSDLC 定義 SSDLC（Secure Software Development Life Cycle） 是在傳統軟體開發生命週期（SDLC）的每個階段融入安全實務，確保從需求分析到維運的全流程都考量資訊安全。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-copilot-ssdlc-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub Copilot SSDLC（安全軟體開發生命週期）教學手冊 版本：v2.3\n最後更新：2026 年 5 月 28 日\n適用對象：軟體開發團隊全體成員（資深工程師導向）\n文件性質：企業級內部技術規範與教育訓練教材（企業標準技術白皮書等級）\n撰寫者：軟體架構團隊\n審核者：技術委員會\n參考來源：GitHub Copilot 官方文件、軟體開發標準程序教學手冊、Agent Skills 開放標準、Copilot Customization Cheat Sheet\n📋 目錄 第一章：SSDLC 總覽（結合 AI） 1.1 SSDLC 定義 1.2 傳統 SDLC vs AI SSDLC 1.3 GitHub Copilot 在各階段的角色 1.4 GitHub Copilot 方案與定價 1.5 DevSecOps + AI 整合 第二章：系統整體架構設計（Architecture） 2.1 企業級系統架構總覽 2.2 分層設計（Layered Architecture） 2.3 微服務與模組化設計 2.4 Clean Architecture 應用 第三章：開發環境建置（Installation \u0026amp; Setup） 3.1 工具安裝 3.2 GitHub Copilot 設定 3.3 專案初始化與分支策略 第四章：SSDLC 各階段 + Copilot 實戰 4.1 需求分析（Requirement） 4.2 系統設計（Design） 4.3 開發（Development） 4.4 測試（Testing） 4.5 安全（Security） 4.6 部署（Deployment） 4.7 維運（Operation） 第五章：Copilot 進階使用（AI Engineering） 5.1 Prompt Engineering 5.2 Context 設計與 Custom Instructions 5.3 Prompt Files 與 Path-Specific Instructions 5.4 多檔案生成與 Refactoring 5.5 Code Review 自動化 5.6 AI Pair Programming 最佳實務 5.7 Copilot Cloud Agent 進階應用 5.8 Copilot CLI 內建 Agents 5.9 第三方 Coding Agents 5.10 Agent Skills 開放標準 第六章：自我學習與優化機制 6.1 AI 自我優化 Workflow 6.2 Prompt 優化迴圈 6.3 知識庫（Knowledge Base） 6.4 文件自動生成 第七章：實戰案例（銀行系統） 7.1 Web Application 開發 7.2 FTP 上傳流程 7.3 資料驗證流程 7.4 高可用架構設計 第八章：系統維護與升級 8.1 Copilot 升級策略 8.2 Plugin 管理 8.3 相容性管理 8.4 技術債處理 第九章：最佳實務（Best Practices） 9.1 開發規範 9.2 安全規範 9.3 AI 使用規範 9.4 團隊協作模式 第十章：AI 治理與合規（AI Governance） 10.1 AI 使用政策 10.2 智慧財產權與授權 10.3 安全與資料保護 10.4 合規檢核清單 附錄 A：檢查清單（Checklist） 附錄 B：常用 Prompt 範本 附錄 C：術語對照表 附錄 D：GitHub Copilot 方案功能對照表 第一章：SSDLC 總覽（結合 AI） 1.1 SSDLC 定義 SSDLC（Secure Software Development Life Cycle） 是在傳統軟體開發生命週期（SDLC）的每個階段融入安全實務，確保從需求分析到維運的全流程都考量資訊安全。\n","title":"GitHub Copilot SSDLC 教學手冊"},{"content":"Claude Code SSDLC（AI 軟體開發生命週期）教學手冊 版本：v2.1 ｜ 日期：2026-06-26 ｜ 適用對象：資深工程師 / 架構師 / DevOps / AI 工程師\n定位：企業級實戰手冊，可直接作為團隊導入規範文件\n變更紀錄：v2.0 — 全面更新至 Claude Code 最新版本，涵蓋 Hooks、Skills、Plugins、Agent Teams、Auto Memory、多平台支援等新特性；v2.1 — 修正巢狀程式碼區塊格式錯誤，補充 Hooks／Skills／Subagents 完整 Frontmatter 欄位，新增 Headless 模式與 Sandbox 模式說明，修正 Auto Memory 匯入層數誤植，補齊 Permission 模式完整列舉與附錄 CLI 旗標\n目錄 第 1 章：整體架構設計（Architecture） 1.1 Claude Code 在 SSDLC 的角色 1.2 AI Agent 在 SDLC 各階段的應用 1.3 系統架構圖 1.4 多 Agent 協作模型 1.5 與企業系統整合 1.6 多平台支援 第 2 章：Claude Code 安裝與環境建置 2.1 Claude Code CLI 安裝 2.2 VS Code 整合設定 2.3 API Key 與認證設定 2.4 Workspace 初始化 2.5 常見錯誤與排除 2.6 Headless 模式與自動化執行 第 3 章：專案結構設計（Best Practice） 3.1 Claude Code 專案目錄結構 3.2 Prompt Template 設計 3.3 Agent Workflow 定義 3.4 Context 管理策略 3.5 Skills / Rules / Plugins 結構 第 4 章：SSDLC Workflow 設計（核心） 4.1 需求階段（Requirements） 4.2 設計階段（Design） 4.3 開發階段（Development） 4.4 測試階段（Testing） 4.5 部署階段（Deployment） 4.6 維運階段（Operations） 第 5 章：AI Agent Workflow 設計 5.1 多 Agent 協作模式 5.2 自我反饋迴圈（Self-Reflection Loop） 5.3 自我優化系統（Self-Improving System） 5.4 Memory / Context 設計 5.5 Agent Teams 與多 Session 協作 5.6 Plugins 插件生態系 第 6 章：Prompt Engineering 6.1 Prompt 模板設計 6.2 可重用 Prompt Library 6.3 Chain-of-Thought / ReAct 模式 6.4 安全 Prompt（避免 Hallucination） 第 7 章：實務案例 7.1 案例 1：Web 系統（Spring Boot + Vue） 7.2 案例 2：批次系統（Batch Job） 第 8 章：系統維運（Operations） 8.1 日誌管理 8.2 AI 輔助 Debug 8.3 Incident 處理 第 9 章：系統升級與優化（Evolution） 9.1 Prompt 版本控管 9.2 Agent 能力升級 9.3 Workflow 優化策略 第 10 章：最佳實務與建議（Best Practices） 10.1 團隊導入策略 10.2 治理（Governance） 10.3 安全（Security） 10.4 成本控制（Token / API） 第 11 章：常見問題（FAQ） 附錄 A：快速檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：參考資料 第 1 章：整體架構設計（Architecture） 1.1 Claude Code 在 SSDLC 的角色 Claude Code 是 Anthropic 推出的 Agentic Coding Tool，可在 Terminal、VS Code、JetBrains、Desktop App、Web 以及 Chrome 瀏覽器中使用。它不只是程式碼補全工具，而是能夠：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code-ssdlcai%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC%E7%94%9F%E5%91%BD%E9%80%B1%E6%9C%9F%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Claude Code SSDLC（AI 軟體開發生命週期）教學手冊 版本：v2.1 ｜ 日期：2026-06-26 ｜ 適用對象：資深工程師 / 架構師 / DevOps / AI 工程師\n定位：企業級實戰手冊，可直接作為團隊導入規範文件\n變更紀錄：v2.0 — 全面更新至 Claude Code 最新版本，涵蓋 Hooks、Skills、Plugins、Agent Teams、Auto Memory、多平台支援等新特性；v2.1 — 修正巢狀程式碼區塊格式錯誤，補充 Hooks／Skills／Subagents 完整 Frontmatter 欄位，新增 Headless 模式與 Sandbox 模式說明，修正 Auto Memory 匯入層數誤植，補齊 Permission 模式完整列舉與附錄 CLI 旗標\n目錄 第 1 章：整體架構設計（Architecture） 1.1 Claude Code 在 SSDLC 的角色 1.2 AI Agent 在 SDLC 各階段的應用 1.3 系統架構圖 1.4 多 Agent 協作模型 1.5 與企業系統整合 1.6 多平台支援 第 2 章：Claude Code 安裝與環境建置 2.1 Claude Code CLI 安裝 2.2 VS Code 整合設定 2.3 API Key 與認證設定 2.4 Workspace 初始化 2.5 常見錯誤與排除 2.6 Headless 模式與自動化執行 第 3 章：專案結構設計（Best Practice） 3.1 Claude Code 專案目錄結構 3.2 Prompt Template 設計 3.3 Agent Workflow 定義 3.4 Context 管理策略 3.5 Skills / Rules / Plugins 結構 第 4 章：SSDLC Workflow 設計（核心） 4.1 需求階段（Requirements） 4.2 設計階段（Design） 4.3 開發階段（Development） 4.4 測試階段（Testing） 4.5 部署階段（Deployment） 4.6 維運階段（Operations） 第 5 章：AI Agent Workflow 設計 5.1 多 Agent 協作模式 5.2 自我反饋迴圈（Self-Reflection Loop） 5.3 自我優化系統（Self-Improving System） 5.4 Memory / Context 設計 5.5 Agent Teams 與多 Session 協作 5.6 Plugins 插件生態系 第 6 章：Prompt Engineering 6.1 Prompt 模板設計 6.2 可重用 Prompt Library 6.3 Chain-of-Thought / ReAct 模式 6.4 安全 Prompt（避免 Hallucination） 第 7 章：實務案例 7.1 案例 1：Web 系統（Spring Boot + Vue） 7.2 案例 2：批次系統（Batch Job） 第 8 章：系統維運（Operations） 8.1 日誌管理 8.2 AI 輔助 Debug 8.3 Incident 處理 第 9 章：系統升級與優化（Evolution） 9.1 Prompt 版本控管 9.2 Agent 能力升級 9.3 Workflow 優化策略 第 10 章：最佳實務與建議（Best Practices） 10.1 團隊導入策略 10.2 治理（Governance） 10.3 安全（Security） 10.4 成本控制（Token / API） 第 11 章：常見問題（FAQ） 附錄 A：快速檢查清單（Checklist） 附錄 B：常用指令速查表 附錄 C：參考資料 第 1 章：整體架構設計（Architecture） 1.1 Claude Code 在 SSDLC 的角色 Claude Code 是 Anthropic 推出的 Agentic Coding Tool，可在 Terminal、VS Code、JetBrains、Desktop App、Web 以及 Chrome 瀏覽器中使用。它不只是程式碼補全工具，而是能夠：\n","title":"Claude Code SSDLC（AI軟體開發生命週期）教學手冊"},{"content":"GitHub Copilot 逆向工程教學手冊（Java Web） 版本：2.0\n最後更新：2026-04-02\n適用對象：資深工程師、架構師、技術主管\n技術棧：Java 21+ / Spring Boot 3.x～4.x / GitHub Copilot（Chat / Agent Mode / Cloud Agent / CLI / MCP）\n📑 目錄 第 1 章 概論 1.1 什麼是逆向工程（Reverse Engineering） 1.2 Legacy System 現代化挑戰 1.3 GitHub Copilot 在逆向工程的角色 1.4 適用情境 第 2 章 三種逆向工程策略 2.1 黑箱逆向（Black-box Reverse Engineering） 2.2 白箱逆向（White-box Reverse Engineering） 2.3 灰箱逆向（Gray-box / Hybrid） 2.4 三種策略比較總覽 第 3 章 SDLC 對應逆向工程流程 3.1 需求分析（Requirement Analysis） 3.2 系統設計（System Design） 3.3 開發（Implementation） 3.4 測試（Testing） 3.5 部署（Deployment） 第 4 章 GitHub Copilot 實戰流程 4.1 Step 1：分析舊系統 4.2 Step 2：建立理解模型（Domain Model） 4.3 Step 3：產出文件（AI 自動生成） 4.4 Step 4：建立新專案（Spring Boot） 4.5 Step 5：逐步重構 4.6 Step 6：驗證與測試 4.7 Agent Mode 加速逆向工程 第 5 章 Copilot Prompt Engineering 5.1 Prompt 設計原則 5.2 程式碼分析類 Prompt 5.3 語言轉換類 Prompt 5.4 文件產出類 Prompt 5.5 測試生成類 Prompt 5.6 Prompt 模板庫 5.7 Custom Instructions（專案級指令） 5.8 Agent Mode 專用 Prompt 設計 第 6 章 架構設計（企業級） 6.1 微服務 vs 單體架構決策 6.2 分層架構設計 6.3 資料庫遷移設計 6.4 中介軟體整合 第 7 章 風險與最佳實務 7.1 常見錯誤 7.2 逆向工程失敗案例分析 7.3 資料遺失風險與對策 7.4 安全性考量 7.5 AI 治理與企業合規 第 8 章 完整案例（實戰） 8.1 案例背景：VB6 客戶管理系統 8.2 Copilot 分析過程 8.3 新系統 Spring Boot 實作 8.4 案例二：舊 Java Servlet 轉 Spring Boot 第 9 章 工具整合 9.1 VS Code 配置 9.2 GitHub Copilot Chat 9.3 Copilot CLI 9.4 SonarQube 整合 9.5 Swagger / OpenAPI 9.6 Copilot Agent Mode 與 Cloud Agent 9.7 MCP Server 整合 9.8 Copilot Code Review 9.9 Copilot Spaces 與 Memory 第 10 章 結論 10.1 三種逆向策略比較表 10.2 推薦最佳實務 附錄 A：逆向工程檢查清單（Checklist） 附錄 B：Prompt 快速參考卡 附錄 C：常用工具版本對照 附錄 D：成本效益分析（ROI 評估） 第 1 章 概論 1.1 什麼是逆向工程（Reverse Engineering） 逆向工程是指從「已存在的系統產出物（程式碼、執行檔、資料庫）」出發，反向推導出系統的：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/github-copilot-%E9%80%86%E5%90%91%E5%B7%A5%E7%A8%8B%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub Copilot 逆向工程教學手冊（Java Web） 版本：2.0\n最後更新：2026-04-02\n適用對象：資深工程師、架構師、技術主管\n技術棧：Java 21+ / Spring Boot 3.x～4.x / GitHub Copilot（Chat / Agent Mode / Cloud Agent / CLI / MCP）\n📑 目錄 第 1 章 概論 1.1 什麼是逆向工程（Reverse Engineering） 1.2 Legacy System 現代化挑戰 1.3 GitHub Copilot 在逆向工程的角色 1.4 適用情境 第 2 章 三種逆向工程策略 2.1 黑箱逆向（Black-box Reverse Engineering） 2.2 白箱逆向（White-box Reverse Engineering） 2.3 灰箱逆向（Gray-box / Hybrid） 2.4 三種策略比較總覽 第 3 章 SDLC 對應逆向工程流程 3.1 需求分析（Requirement Analysis） 3.2 系統設計（System Design） 3.3 開發（Implementation） 3.4 測試（Testing） 3.5 部署（Deployment） 第 4 章 GitHub Copilot 實戰流程 4.1 Step 1：分析舊系統 4.2 Step 2：建立理解模型（Domain Model） 4.3 Step 3：產出文件（AI 自動生成） 4.4 Step 4：建立新專案（Spring Boot） 4.5 Step 5：逐步重構 4.6 Step 6：驗證與測試 4.7 Agent Mode 加速逆向工程 第 5 章 Copilot Prompt Engineering 5.1 Prompt 設計原則 5.2 程式碼分析類 Prompt 5.3 語言轉換類 Prompt 5.4 文件產出類 Prompt 5.5 測試生成類 Prompt 5.6 Prompt 模板庫 5.7 Custom Instructions（專案級指令） 5.8 Agent Mode 專用 Prompt 設計 第 6 章 架構設計（企業級） 6.1 微服務 vs 單體架構決策 6.2 分層架構設計 6.3 資料庫遷移設計 6.4 中介軟體整合 第 7 章 風險與最佳實務 7.1 常見錯誤 7.2 逆向工程失敗案例分析 7.3 資料遺失風險與對策 7.4 安全性考量 7.5 AI 治理與企業合規 第 8 章 完整案例（實戰） 8.1 案例背景：VB6 客戶管理系統 8.2 Copilot 分析過程 8.3 新系統 Spring Boot 實作 8.4 案例二：舊 Java Servlet 轉 Spring Boot 第 9 章 工具整合 9.1 VS Code 配置 9.2 GitHub Copilot Chat 9.3 Copilot CLI 9.4 SonarQube 整合 9.5 Swagger / OpenAPI 9.6 Copilot Agent Mode 與 Cloud Agent 9.7 MCP Server 整合 9.8 Copilot Code Review 9.9 Copilot Spaces 與 Memory 第 10 章 結論 10.1 三種逆向策略比較表 10.2 推薦最佳實務 附錄 A：逆向工程檢查清單（Checklist） 附錄 B：Prompt 快速參考卡 附錄 C：常用工具版本對照 附錄 D：成本效益分析（ROI 評估） 第 1 章 概論 1.1 什麼是逆向工程（Reverse Engineering） 逆向工程是指從「已存在的系統產出物（程式碼、執行檔、資料庫）」出發，反向推導出系統的：\n","title":"GitHub Copilot 逆向工程教學手冊"},{"content":"Agent Skills 教學手冊（企業級 SSDLC + GitHub Copilot + Claude Code） 版本：v1.4.0\n更新日期：2026-06-30 適用對象：資深工程師、架構師、Tech Lead、DevSecOps 工程師\n技術棧：Agent Skills 開放標準、GitHub Copilot Skills、Claude Code Skills、VS Code、Spring Boot、Vue 3\n規範參考：Agent Skills Specification（開放標準 v1.0）\n目錄 第 1 章：Agent Skills 概念與架構 1.1 什麼是 Agent Skills 1.2 與傳統 Prompt Engineering 的差異 1.3 Skills vs Prompt vs Tool vs Agent 比較 1.4 漸進式揭露（Progressive Disclosure）設計原則 1.5 Skills 組成結構 第 2 章：Skills 平台深度解析（GitHub Copilot + Claude Code） 2.1 多平台 Skills 架構 2.2 Skills 運作流程 2.3 Skills Metadata 設計（Frontmatter 完整參考） 2.3.1 開放標準欄位（agentskills.io Specification） 2.3.2 Claude Code 擴展欄位 2.3.3 字串替換（String Substitutions） 2.3.4 動態上下文注入（Dynamic Context Injection） 2.4 Claude Code 內建 Skills（Bundled Skills） 2.5 Skills 與 Agent 整合方式 2.6 Skills Repository 設計（企業級） 2.7 gh skill CLI（GitHub CLI 整合） 2.8 Skill 內容生命週期與 Token 預算 第 3 章：SSDLC × Skills（核心章節） 3.1 Requirements（需求階段） 3.2 Design（設計階段） 3.3 Development（開發階段） 3.4 Testing（測試階段） 3.5 Security（安全） 3.6 Deployment（部署） 3.7 Maintenance（維運） 第 4 章：Skills 設計最佳實務 4.1 高可重用性設計 4.2 低 Token 消耗策略 4.3 命名規範 4.4 模組化與版本控管 4.5 安全性與權限控管 4.6 社群設計模式參考（Community Patterns） 4.6.1 CONTEXT.md 共用語言模式 4.6.2 反合理化表格模式 4.6.3 Agent Personas 模式 4.6.4 生命週期導向組織模式 4.6.5 四大失敗模式框架 4.6.6 User-invoked vs Model-invoked 設計模式 4.6.7 自主執行模式 4.6.8 Skills 安裝器生態 第 5 章：Skills 實作教學（Hands-on） 5.1 範例 1：產生 API 設計文件 Skill 5.2 範例 2：程式碼審查 Skill 5.3 範例 3：Spring Boot 服務生成 Skill 第 6 章：企業級 Skills Repository 架構 6.1 建議 GitHub Repo 結構 6.2 Skills 分類策略 6.3 權限控管（RBAC） 6.4 與 CI/CD 整合 第 7 章：與開發工具整合 7.1 GitHub Copilot 整合 7.2 Claude Code 進階整合 7.3 VS Code 整合 7.4 CI/CD（GitHub Actions）整合 7.5 Issue / PR 流程整合 第 8 章：Skills 治理（Governance） 8.1 Skills 審核機制 8.2 品質控管（Quality Gate） 8.3 安全審查（Security Review） 8.4 使用追蹤與優化（Telemetry） 第 9 章：常見錯誤與反模式 9.1 過度設計 Skills 9.2 Token 爆炸問題 9.3 Skills 過於耦合 9.4 其他常見反模式 第 10 章：未來趨勢 10.1 Agentic Workflow 10.2 Multi-Agent Collaboration 10.3 Skills Marketplace 與開放生態 附錄 A：企業導入檢查清單 附錄 B：Prompt → Skill 轉換速查表 附錄 C：常用 Skills 清單 附錄 D：參考資源 第 1 章：Agent Skills 概念與架構 1.1 什麼是 Agent Skills 定義：Agent Skills 是一種基於 agentskills.io 開放標準的模組化、可重複使用「AI 能力包」（Capability Package），以資料夾形式存在，內含說明文件（SKILL.md）、腳本（Python / Bash / PowerShell）、範本（Templates）和參考資源（References）。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/agent-skills%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Agent Skills 教學手冊（企業級 SSDLC + GitHub Copilot + Claude Code） 版本：v1.4.0\n更新日期：2026-06-30 適用對象：資深工程師、架構師、Tech Lead、DevSecOps 工程師\n技術棧：Agent Skills 開放標準、GitHub Copilot Skills、Claude Code Skills、VS Code、Spring Boot、Vue 3\n規範參考：Agent Skills Specification（開放標準 v1.0）\n目錄 第 1 章：Agent Skills 概念與架構 1.1 什麼是 Agent Skills 1.2 與傳統 Prompt Engineering 的差異 1.3 Skills vs Prompt vs Tool vs Agent 比較 1.4 漸進式揭露（Progressive Disclosure）設計原則 1.5 Skills 組成結構 第 2 章：Skills 平台深度解析（GitHub Copilot + Claude Code） 2.1 多平台 Skills 架構 2.2 Skills 運作流程 2.3 Skills Metadata 設計（Frontmatter 完整參考） 2.3.1 開放標準欄位（agentskills.io Specification） 2.3.2 Claude Code 擴展欄位 2.3.3 字串替換（String Substitutions） 2.3.4 動態上下文注入（Dynamic Context Injection） 2.4 Claude Code 內建 Skills（Bundled Skills） 2.5 Skills 與 Agent 整合方式 2.6 Skills Repository 設計（企業級） 2.7 gh skill CLI（GitHub CLI 整合） 2.8 Skill 內容生命週期與 Token 預算 第 3 章：SSDLC × Skills（核心章節） 3.1 Requirements（需求階段） 3.2 Design（設計階段） 3.3 Development（開發階段） 3.4 Testing（測試階段） 3.5 Security（安全） 3.6 Deployment（部署） 3.7 Maintenance（維運） 第 4 章：Skills 設計最佳實務 4.1 高可重用性設計 4.2 低 Token 消耗策略 4.3 命名規範 4.4 模組化與版本控管 4.5 安全性與權限控管 4.6 社群設計模式參考（Community Patterns） 4.6.1 CONTEXT.md 共用語言模式 4.6.2 反合理化表格模式 4.6.3 Agent Personas 模式 4.6.4 生命週期導向組織模式 4.6.5 四大失敗模式框架 4.6.6 User-invoked vs Model-invoked 設計模式 4.6.7 自主執行模式 4.6.8 Skills 安裝器生態 第 5 章：Skills 實作教學（Hands-on） 5.1 範例 1：產生 API 設計文件 Skill 5.2 範例 2：程式碼審查 Skill 5.3 範例 3：Spring Boot 服務生成 Skill 第 6 章：企業級 Skills Repository 架構 6.1 建議 GitHub Repo 結構 6.2 Skills 分類策略 6.3 權限控管（RBAC） 6.4 與 CI/CD 整合 第 7 章：與開發工具整合 7.1 GitHub Copilot 整合 7.2 Claude Code 進階整合 7.3 VS Code 整合 7.4 CI/CD（GitHub Actions）整合 7.5 Issue / PR 流程整合 第 8 章：Skills 治理（Governance） 8.1 Skills 審核機制 8.2 品質控管（Quality Gate） 8.3 安全審查（Security Review） 8.4 使用追蹤與優化（Telemetry） 第 9 章：常見錯誤與反模式 9.1 過度設計 Skills 9.2 Token 爆炸問題 9.3 Skills 過於耦合 9.4 其他常見反模式 第 10 章：未來趨勢 10.1 Agentic Workflow 10.2 Multi-Agent Collaboration 10.3 Skills Marketplace 與開放生態 附錄 A：企業導入檢查清單 附錄 B：Prompt → Skill 轉換速查表 附錄 C：常用 Skills 清單 附錄 D：參考資源 第 1 章：Agent Skills 概念與架構 1.1 什麼是 Agent Skills 定義：Agent Skills 是一種基於 agentskills.io 開放標準的模組化、可重複使用「AI 能力包」（Capability Package），以資料夾形式存在，內含說明文件（SKILL.md）、腳本（Python / Bash / PowerShell）、範本（Templates）和參考資源（References）。\n","title":"Agent Skills教學手冊"},{"content":"使用 GitHub Copilot 進行逆向工程並產出需求規格書 版本：2.0 | 更新日期：2026-03-31\n適用對象：資深工程師、系統分析師、架構師、PM\n技術環境：VS Code + GitHub Copilot（含 Agent Mode、Coding Agent、MCP 整合）\n產業適用：銀行、金融、保險等高合規性企業系統\nAI 模型支援：GPT-5.4 / GPT-5.4 mini / GPT-5.3-Codex / Gemini 3.1 Pro / 自動模型選擇\n目錄 第 1 章 逆向工程方法論 1.1 什麼是逆向工程 1.2 企業系統中的逆向工程應用場景 1.3 Code → Requirement 轉換模型 1.4 各層級程式碼的需求推導策略 1.5 逆向工程成熟度模型 第 2 章 GitHub Copilot 使用策略 2.1 Copilot 在逆向工程中的角色定位 2.1.1 GitHub Copilot 2026 功能架構全景 2.1.2 各功能在逆向工程中的定位 2.1.3 AI 模型選擇策略 2.2 Prompt Engineering 核心原則 2.2.1 角色設定（Role Setting） 2.2.2 結構化 Prompt 模板 2.2.3 五大 Prompt 策略 2.3 逐段分析程式碼的技巧 2.3.1 分段策略 2.3.2 VS Code 操作技巧 2.4 C# 程式碼解讀策略與 Prompt 範例 2.5 SQL / Stored Procedure 解讀策略與 Prompt 範例 2.6 Batch Job 解讀策略與 Prompt 範例 2.7 從技術描述轉換為商業需求描述 2.8 Before / After 完整範例 2.9 Agent Mode 與 Coding Agent 在逆向工程中的進階應用 2.9.1 使用 Agent Mode 進行跨檔案逆向分析 2.9.2 使用 Plan Agent 規劃逆向工程任務 2.9.3 使用 Copilot Coding Agent 進行自動化逆向分析 2.9.4 使用 MCP 擴展逆向工程能力 2.9.5 使用 Custom Agent 建立專用逆向工程分析師 2.9.6 使用 Copilot Memory 累積逆向工程知識 2.9.7 第三方 Coding Agent 與外部平台整合 2.9.8 使用背景代理進行非同步逆向分析 第 3 章 實戰流程（Step-by-Step） 3.1 Step 1 — 程式碼盤點 3.1.1 模組分類方法 3.1.2 使用 Copilot 快速摘要 3.1.3 自動化盤點腳本 3.2 Step 2 — 邏輯解析 3.2.1 API 邏輯分析 3.2.2 Batch Job 邏輯分析 3.2.3 DB 邏輯分析 3.3 Step 3 — 商業邏輯抽取 3.3.1 從技術邏輯到業務需求的轉換方法 3.3.2 商業規則分類框架 3.3.3 需求追溯矩陣 3.4 Step 4 — 文件產出 3.4.1 SRS 文件自動生成流程 3.4.2 文件品質檢查 3.5 端到端流程圖 第 4 章 SRS 文件標準格式 4.1 SRS 文件結構概覽 4.2 系統概述 4.3 Use Case 描述 4.4 功能需求（Functional Requirements） 4.5 非功能需求（Non-functional Requirements） 4.6 資料流程（DFD） 4.7 ER Model（資料結構） 4.8 Batch Flow 4.9 企業級 SRS 範本（完整） 第 5 章 完整實戰範例 5.1 範例一：C# API 控制器逆向分析 5.1.1 原始程式碼 5.1.2 Copilot 分析過程 5.1.3 推導出的需求 5.2 範例二：Stored Procedure 逆向分析 5.2.1 原始程式碼 5.2.2 Copilot 分析過程 5.2.3 推導出的需求 5.3 範例三：Batch Job 逆向分析 5.3.1 分析場景 5.3.2 Copilot 分析結果 5.4 最終 SRS 文件片段產出 第 6 章 企業最佳實務 6.1 避免誤判需求的策略 6.1.1 常見的誤判類型 6.1.2 防範策略 6.1.3 信心度評估框架 6.2 需求驗證流程 6.2.1 三層驗證機制 6.2.2 驗證會議範本 6.3 整合 SSDLC 6.4 搭配版本控制（Git） 6.4.1 SRS 文件的 Git 管理策略 6.4.2 Git Branching 策略 6.4.3 Commit 訊息規範 6.5 常見錯誤與修正策略 6.6 使用 Copilot Code Review 驗證 SRS 品質 6.6.1 設定 Copilot Code Review 規則 6.6.2 SRS Pull Request 審查流程 6.7 使用 Copilot Spaces 管理逆向工程上下文 第 7 章 架構延伸（進階） 7.1 從逆向結果到 Spring Boot API 設計 7.1.1 技術對照表 7.1.2 SRS → API 設計的轉換流程 7.1.3 範例：從 SRS 到 Spring Boot 7.2 微服務架構轉換 7.2.1 從單體到微服務的拆分策略 7.2.2 Stored Procedure 的遷移策略 7.3 Domain Modeling（DDD） 7.3.1 從逆向結果推導領域模型 7.3.2 統一語言表 7.4 Clean Architecture 對應 7.4.1 分層架構設計 7.4.2 Spring Boot 專案結構 7.5 使用 Copilot Coding Agent 自動化遷移工作 7.5.1 從 SRS 到 Spring Boot 骨架自動生成 7.5.2 SP 邏輯遷移自動化 7.5.3 Hooks 自動化品質檢查 第 8 章 Prompt 工程模板庫 8.1 程式碼摘要類 8.2 邏輯解析類 8.3 需求轉換類 8.4 文件產出類 8.5 驗證與審查類 第 9 章 自動化流程（AI + Script） 9.1 自動化盤點腳本 9.1.1 C# 專案自動盤點（PowerShell） 9.1.2 SQL Server Stored Procedure 盤點 9.2 批次分析流程 9.2.1 分析工作流程自動化 9.2.2 分析任務分配模板 9.3 SRS 自動組裝 9.3.1 SRS 組裝腳本（PowerShell） 9.3.2 SRS 品質檢查腳本 9.4 Copilot Coding Agent 端到端自動化流程 9.4.1 自動化流程架構 9.4.2 GitHub Actions 工作流配置 9.4.3 批次 Issue 建立腳本 9.4.4 追溯矩陣自動生成 附錄 A 檢查清單（Checklist） A.1 逆向工程啟動檢查清單 A.2 每日分析檢查清單 A.3 模組完成檢查清單 A.4 SRS 發佈前檢查清單 A.5 Copilot 使用安全檢查清單 A.6 Copilot Coding Agent 使用檢查清單 附錄 B 術語表 附錄 C 參考資源 C.1 工具 C.2 標準與規範 C.3 推薦閱讀 C.4 GitHub Copilot 相關資源 第 1 章 逆向工程方法論 1.1 什麼是逆向工程 逆向工程（Reverse Engineering） 是從既有系統的成品（程式碼、資料庫、設定檔等）出發，反推出系統的設計意圖、業務規則與需求規格的過程。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/%E4%BD%BF%E7%94%A8-github-copilot-%E9%80%B2%E8%A1%8C%E9%80%86%E5%90%91%E5%B7%A5%E7%A8%8B%E4%B8%A6%E7%94%A2%E5%87%BA%E9%9C%80%E6%B1%82%E8%A6%8F%E6%A0%BC%E6%9B%B8/","summary":"使用 GitHub Copilot 進行逆向工程並產出需求規格書 版本：2.0 | 更新日期：2026-03-31\n適用對象：資深工程師、系統分析師、架構師、PM\n技術環境：VS Code + GitHub Copilot（含 Agent Mode、Coding Agent、MCP 整合）\n產業適用：銀行、金融、保險等高合規性企業系統\nAI 模型支援：GPT-5.4 / GPT-5.4 mini / GPT-5.3-Codex / Gemini 3.1 Pro / 自動模型選擇\n目錄 第 1 章 逆向工程方法論 1.1 什麼是逆向工程 1.2 企業系統中的逆向工程應用場景 1.3 Code → Requirement 轉換模型 1.4 各層級程式碼的需求推導策略 1.5 逆向工程成熟度模型 第 2 章 GitHub Copilot 使用策略 2.1 Copilot 在逆向工程中的角色定位 2.1.1 GitHub Copilot 2026 功能架構全景 2.1.2 各功能在逆向工程中的定位 2.1.3 AI 模型選擇策略 2.2 Prompt Engineering 核心原則 2.2.1 角色設定（Role Setting） 2.2.2 結構化 Prompt 模板 2.2.3 五大 Prompt 策略 2.3 逐段分析程式碼的技巧 2.3.1 分段策略 2.3.2 VS Code 操作技巧 2.4 C# 程式碼解讀策略與 Prompt 範例 2.5 SQL / Stored Procedure 解讀策略與 Prompt 範例 2.6 Batch Job 解讀策略與 Prompt 範例 2.7 從技術描述轉換為商業需求描述 2.8 Before / After 完整範例 2.9 Agent Mode 與 Coding Agent 在逆向工程中的進階應用 2.9.1 使用 Agent Mode 進行跨檔案逆向分析 2.9.2 使用 Plan Agent 規劃逆向工程任務 2.9.3 使用 Copilot Coding Agent 進行自動化逆向分析 2.9.4 使用 MCP 擴展逆向工程能力 2.9.5 使用 Custom Agent 建立專用逆向工程分析師 2.9.6 使用 Copilot Memory 累積逆向工程知識 2.9.7 第三方 Coding Agent 與外部平台整合 2.9.8 使用背景代理進行非同步逆向分析 第 3 章 實戰流程（Step-by-Step） 3.1 Step 1 — 程式碼盤點 3.1.1 模組分類方法 3.1.2 使用 Copilot 快速摘要 3.1.3 自動化盤點腳本 3.2 Step 2 — 邏輯解析 3.2.1 API 邏輯分析 3.2.2 Batch Job 邏輯分析 3.2.3 DB 邏輯分析 3.3 Step 3 — 商業邏輯抽取 3.3.1 從技術邏輯到業務需求的轉換方法 3.3.2 商業規則分類框架 3.3.3 需求追溯矩陣 3.4 Step 4 — 文件產出 3.4.1 SRS 文件自動生成流程 3.4.2 文件品質檢查 3.5 端到端流程圖 第 4 章 SRS 文件標準格式 4.1 SRS 文件結構概覽 4.2 系統概述 4.3 Use Case 描述 4.4 功能需求（Functional Requirements） 4.5 非功能需求（Non-functional Requirements） 4.6 資料流程（DFD） 4.7 ER Model（資料結構） 4.8 Batch Flow 4.9 企業級 SRS 範本（完整） 第 5 章 完整實戰範例 5.1 範例一：C# API 控制器逆向分析 5.1.1 原始程式碼 5.1.2 Copilot 分析過程 5.1.3 推導出的需求 5.2 範例二：Stored Procedure 逆向分析 5.2.1 原始程式碼 5.2.2 Copilot 分析過程 5.2.3 推導出的需求 5.3 範例三：Batch Job 逆向分析 5.3.1 分析場景 5.3.2 Copilot 分析結果 5.4 最終 SRS 文件片段產出 第 6 章 企業最佳實務 6.1 避免誤判需求的策略 6.1.1 常見的誤判類型 6.1.2 防範策略 6.1.3 信心度評估框架 6.2 需求驗證流程 6.2.1 三層驗證機制 6.2.2 驗證會議範本 6.3 整合 SSDLC 6.4 搭配版本控制（Git） 6.4.1 SRS 文件的 Git 管理策略 6.4.2 Git Branching 策略 6.4.3 Commit 訊息規範 6.5 常見錯誤與修正策略 6.6 使用 Copilot Code Review 驗證 SRS 品質 6.6.1 設定 Copilot Code Review 規則 6.6.2 SRS Pull Request 審查流程 6.7 使用 Copilot Spaces 管理逆向工程上下文 第 7 章 架構延伸（進階） 7.1 從逆向結果到 Spring Boot API 設計 7.1.1 技術對照表 7.1.2 SRS → API 設計的轉換流程 7.1.3 範例：從 SRS 到 Spring Boot 7.2 微服務架構轉換 7.2.1 從單體到微服務的拆分策略 7.2.2 Stored Procedure 的遷移策略 7.3 Domain Modeling（DDD） 7.3.1 從逆向結果推導領域模型 7.3.2 統一語言表 7.4 Clean Architecture 對應 7.4.1 分層架構設計 7.4.2 Spring Boot 專案結構 7.5 使用 Copilot Coding Agent 自動化遷移工作 7.5.1 從 SRS 到 Spring Boot 骨架自動生成 7.5.2 SP 邏輯遷移自動化 7.5.3 Hooks 自動化品質檢查 第 8 章 Prompt 工程模板庫 8.1 程式碼摘要類 8.2 邏輯解析類 8.3 需求轉換類 8.4 文件產出類 8.5 驗證與審查類 第 9 章 自動化流程（AI + Script） 9.1 自動化盤點腳本 9.1.1 C# 專案自動盤點（PowerShell） 9.1.2 SQL Server Stored Procedure 盤點 9.2 批次分析流程 9.2.1 分析工作流程自動化 9.2.2 分析任務分配模板 9.3 SRS 自動組裝 9.3.1 SRS 組裝腳本（PowerShell） 9.3.2 SRS 品質檢查腳本 9.4 Copilot Coding Agent 端到端自動化流程 9.4.1 自動化流程架構 9.4.2 GitHub Actions 工作流配置 9.4.3 批次 Issue 建立腳本 9.4.4 追溯矩陣自動生成 附錄 A 檢查清單（Checklist） A.1 逆向工程啟動檢查清單 A.2 每日分析檢查清單 A.3 模組完成檢查清單 A.4 SRS 發佈前檢查清單 A.5 Copilot 使用安全檢查清單 A.6 Copilot Coding Agent 使用檢查清單 附錄 B 術語表 附錄 C 參考資源 C.1 工具 C.2 標準與規範 C.3 推薦閱讀 C.4 GitHub Copilot 相關資源 第 1 章 逆向工程方法論 1.1 什麼是逆向工程 逆向工程（Reverse Engineering） 是從既有系統的成品（程式碼、資料庫、設定檔等）出發，反推出系統的設計意圖、業務規則與需求規格的過程。\n","title":"使用 GitHub Copilot 進行逆向工程並產出需求規格書"},{"content":"企業級程式碼品質分析方法論教學手冊 版本：v2.0｜日期：2026-03-30｜適用對象：初階至資深工程師、Tech Lead、架構師\n適用技術棧：Java / Spring Boot、Vue / TypeScript、微服務架構\n適用產業：銀行、金融業、保險業等高穩定度 / 高安全系統\n重要更新：OWASP Top 10: 2025 版、PMD 7.x、Checkstyle 13.x、SpotBugs 4.9.x、ESLint 9.x Flat Config\n📋 目錄 第 1 章：程式碼品質概論 1.1 程式碼品質的定義 1.2 技術債（Technical Debt） 1.3 為什麼企業需要品質管理 1.4 品質管理全景圖 1.5 實務落地建議 第 2 章：程式碼品質模型（核心方法論） 2.1 品質模型總覽 2.2 可讀性（Readability） 2.3 可維護性（Maintainability） 2.4 可測試性（Testability） 2.5 效能（Performance） 2.6 安全性（Security） 2.7 可擴展性（Scalability） 2.8 實務落地建議 第 3 章：程式碼異味（Code Smells） 3.1 什麼是 Code Smell 3.2 常見 15+ 種 Code Smells 3.3 實務落地建議 第 4 章：靜態分析與工具 4.1 靜態分析概述 4.2 SonarQube 4.3 ESLint 4.4 PMD / Checkstyle 4.5 SpotBugs 4.6 工具功能比較 4.7 企業導入方式 4.8 實務落地建議 第 5 章：Code Review 方法論 5.1 Code Review 的價值 5.2 Review Checklist（企業版） 5.3 Pull Request 標準 5.4 Review 角色分工 5.5 常見錯誤 5.6 實務落地建議 第 6 章：CI/CD 與品質門檻（Quality Gate） 6.1 CI/CD 品質整合概述 6.2 Quality Gate 設計 6.3 Pipeline 品質檢查流程 6.4 Fail Pipeline 策略 6.5 實務落地建議 第 7 章：測試策略與品質關聯 7.1 測試金字塔 7.2 單元測試（Unit Test） 7.3 整合測試（Integration Test） 7.4 覆蓋率迷思 7.5 測試與品質的關係 7.6 實務落地建議 第 8 章：重構（Refactoring）策略 8.1 何時該重構 8.2 安全重構流程 8.3 常見重構技巧 8.4 實務落地建議 第 9 章：企業實務最佳實踐（Best Practices） 9.1 銀行 / 金融系統案例 9.2 微服務品質管理 9.3 DevSecOps 整合 9.4 實務落地建議 第 10 章：導入策略（企業落地） 10.1 推動步驟（Roadmap） 10.2 組織角色 10.3 KPI 指標 10.4 成熟度模型（Level 1～5） 10.5 實務落地建議 附錄 A：新進成員檢查清單（Checklist） 附錄 B：品質指標速查表 附錄 C：推薦學習資源 第 1 章：程式碼品質概論 1.1 程式碼品質的定義 程式碼品質不只是「能跑就好」，在企業級系統中，品質直接影響系統的穩定性、安全性與長期維護成本。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/%E4%BC%81%E6%A5%AD%E7%B4%9A%E7%A8%8B%E5%BC%8F%E7%A2%BC%E5%93%81%E8%B3%AA%E5%88%86%E6%9E%90%E6%96%B9%E6%B3%95%E8%AB%96%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"企業級程式碼品質分析方法論教學手冊 版本：v2.0｜日期：2026-03-30｜適用對象：初階至資深工程師、Tech Lead、架構師\n適用技術棧：Java / Spring Boot、Vue / TypeScript、微服務架構\n適用產業：銀行、金融業、保險業等高穩定度 / 高安全系統\n重要更新：OWASP Top 10: 2025 版、PMD 7.x、Checkstyle 13.x、SpotBugs 4.9.x、ESLint 9.x Flat Config\n📋 目錄 第 1 章：程式碼品質概論 1.1 程式碼品質的定義 1.2 技術債（Technical Debt） 1.3 為什麼企業需要品質管理 1.4 品質管理全景圖 1.5 實務落地建議 第 2 章：程式碼品質模型（核心方法論） 2.1 品質模型總覽 2.2 可讀性（Readability） 2.3 可維護性（Maintainability） 2.4 可測試性（Testability） 2.5 效能（Performance） 2.6 安全性（Security） 2.7 可擴展性（Scalability） 2.8 實務落地建議 第 3 章：程式碼異味（Code Smells） 3.1 什麼是 Code Smell 3.2 常見 15+ 種 Code Smells 3.3 實務落地建議 第 4 章：靜態分析與工具 4.1 靜態分析概述 4.2 SonarQube 4.3 ESLint 4.4 PMD / Checkstyle 4.5 SpotBugs 4.6 工具功能比較 4.7 企業導入方式 4.8 實務落地建議 第 5 章：Code Review 方法論 5.1 Code Review 的價值 5.2 Review Checklist（企業版） 5.3 Pull Request 標準 5.4 Review 角色分工 5.5 常見錯誤 5.6 實務落地建議 第 6 章：CI/CD 與品質門檻（Quality Gate） 6.1 CI/CD 品質整合概述 6.2 Quality Gate 設計 6.3 Pipeline 品質檢查流程 6.4 Fail Pipeline 策略 6.5 實務落地建議 第 7 章：測試策略與品質關聯 7.1 測試金字塔 7.2 單元測試（Unit Test） 7.3 整合測試（Integration Test） 7.4 覆蓋率迷思 7.5 測試與品質的關係 7.6 實務落地建議 第 8 章：重構（Refactoring）策略 8.1 何時該重構 8.2 安全重構流程 8.3 常見重構技巧 8.4 實務落地建議 第 9 章：企業實務最佳實踐（Best Practices） 9.1 銀行 / 金融系統案例 9.2 微服務品質管理 9.3 DevSecOps 整合 9.4 實務落地建議 第 10 章：導入策略（企業落地） 10.1 推動步驟（Roadmap） 10.2 組織角色 10.3 KPI 指標 10.4 成熟度模型（Level 1～5） 10.5 實務落地建議 附錄 A：新進成員檢查清單（Checklist） 附錄 B：品質指標速查表 附錄 C：推薦學習資源 第 1 章：程式碼品質概論 1.1 程式碼品質的定義 程式碼品質不只是「能跑就好」，在企業級系統中，品質直接影響系統的穩定性、安全性與長期維護成本。\n","title":"企業級程式碼品質分析方法論教學手冊"},{"content":"使用github copilot下的Prompt Engineering vs Context Engineering vs Harness Engineering教學手冊 版本：2.0.0\n最後更新：2026-03-18\n適用對象：資深工程師、技術主管、AI 輔助開發導入團隊\n技術情境：Java / Spring Boot / GitHub Copilot / 銀行級 Web Application\n文件等級：企業標準技術白皮書\n目錄 第一章：核心概念說明 1.1 三者定義 1.2 演進關係 1.3 一句話理解 1.4 歷史脈絡與業界趨勢 1.5 三者的互補與協同關係 第二章：詳細比較表 2.1 七大面向比較 2.2 成熟度模型 2.3 投入與回報分析 2.4 學習曲線與導入難度 2.5 適用場景矩陣 第三章：實務案例（Web Application） 3.1 案例一：REST API 開發 3.2 案例二：Batch Job 資料處理 3.3 案例三：前端 UI 開發 3.4 案例四：除錯（Debug） 3.5 案例五：微服務通訊設計 3.6 案例六：安全性漏洞修復 3.7 案例總結比較 第四章：GitHub Copilot 實戰應用 4.1 Prompt Engineering 在 Copilot 中的實踐 4.2 Context Engineering 在 Copilot 中的實踐 4.3 Harness Engineering 在 Copilot 中的實踐 4.4 三者整合實戰工作流 第五章：工具與技術建議 5.1 各層級對應工具 5.2 工具選型決策矩陣 5.3 2026 年最新工具生態 5.4 工具整合架構 第六章：架構設計觀點 6.1 三層演進模型 6.2 大型系統 AI 能力分層設計 6.3 Anti-pattern 架構分析 6.4 企業級 AI 能力成熟度評估框架 6.5 多系統 AI 策略設計 第七章：最佳實務（Best Practices） 7.1 團隊開發規範 7.2 文件設計方式 7.3 Prompt Template 設計 7.4 AI 使用治理（Governance） 7.5 KPI 與成效衡量 第八章：常見錯誤（Anti-pattern） 8.1 Prompt 層 Anti-pattern 8.2 Context 層 Anti-pattern 8.3 Harness 層 Anti-pattern 8.4 跨層 Anti-pattern 8.5 Anti-pattern 速查表 第九章：結論與展望 9.1 架構思維總結 9.2 團隊落地路徑 9.3 ROI 量化框架 9.4 未來展望（2026-2028） 附錄 A：檢查清單（Checklist） 附錄 B：詞彙表 附錄 C：參考資源 附錄 D：Prompt Engineering 進階技巧手冊 附錄 E：Context Engineering 設計模式 第一章：核心概念說明 章節摘要：本章定義 Prompt Engineering、Context Engineering 與 Harness Engineering 三者的核心概念，並說明它們從「單次對話」到「系統化 AI 能力」的演進脈絡。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/%E4%BD%BF%E7%94%A8github-copilot%E4%B8%8B%E7%9A%84prompt-engineering-vs-context-engineering-vs-harness-engineering%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"使用github copilot下的Prompt Engineering vs Context Engineering vs Harness Engineering教學手冊 版本：2.0.0\n最後更新：2026-03-18\n適用對象：資深工程師、技術主管、AI 輔助開發導入團隊\n技術情境：Java / Spring Boot / GitHub Copilot / 銀行級 Web Application\n文件等級：企業標準技術白皮書\n目錄 第一章：核心概念說明 1.1 三者定義 1.2 演進關係 1.3 一句話理解 1.4 歷史脈絡與業界趨勢 1.5 三者的互補與協同關係 第二章：詳細比較表 2.1 七大面向比較 2.2 成熟度模型 2.3 投入與回報分析 2.4 學習曲線與導入難度 2.5 適用場景矩陣 第三章：實務案例（Web Application） 3.1 案例一：REST API 開發 3.2 案例二：Batch Job 資料處理 3.3 案例三：前端 UI 開發 3.4 案例四：除錯（Debug） 3.5 案例五：微服務通訊設計 3.6 案例六：安全性漏洞修復 3.7 案例總結比較 第四章：GitHub Copilot 實戰應用 4.1 Prompt Engineering 在 Copilot 中的實踐 4.2 Context Engineering 在 Copilot 中的實踐 4.3 Harness Engineering 在 Copilot 中的實踐 4.4 三者整合實戰工作流 第五章：工具與技術建議 5.1 各層級對應工具 5.2 工具選型決策矩陣 5.3 2026 年最新工具生態 5.4 工具整合架構 第六章：架構設計觀點 6.1 三層演進模型 6.2 大型系統 AI 能力分層設計 6.3 Anti-pattern 架構分析 6.4 企業級 AI 能力成熟度評估框架 6.5 多系統 AI 策略設計 第七章：最佳實務（Best Practices） 7.1 團隊開發規範 7.2 文件設計方式 7.3 Prompt Template 設計 7.4 AI 使用治理（Governance） 7.5 KPI 與成效衡量 第八章：常見錯誤（Anti-pattern） 8.1 Prompt 層 Anti-pattern 8.2 Context 層 Anti-pattern 8.3 Harness 層 Anti-pattern 8.4 跨層 Anti-pattern 8.5 Anti-pattern 速查表 第九章：結論與展望 9.1 架構思維總結 9.2 團隊落地路徑 9.3 ROI 量化框架 9.4 未來展望（2026-2028） 附錄 A：檢查清單（Checklist） 附錄 B：詞彙表 附錄 C：參考資源 附錄 D：Prompt Engineering 進階技巧手冊 附錄 E：Context Engineering 設計模式 第一章：核心概念說明 章節摘要：本章定義 Prompt Engineering、Context Engineering 與 Harness Engineering 三者的核心概念，並說明它們從「單次對話」到「系統化 AI 能力」的演進脈絡。\n","title":"使用github Copilot下的Prompt Engineering vs Context Engineering vs Harness Engineering教學手冊"},{"content":"SuperClaude Framework 生態系教學手冊 版本：基於 SuperClaude Framework v4.3.0 撰寫\n最後更新：2026-06-30 適用對象：資深工程師、技術主管、全端開發團隊\n文件性質：企業標準技術白皮書 / 實戰教學手冊\n目錄 第一章：SuperClaude Framework 概覽 第二章：系統需求與安裝 第三章：系統設定與配置 第四章：30 個 Slash 指令完整指南 4.10 指令差異比較與選擇指南 第五章：20 個 AI 代理人使用指南 5.4 代理人協調模式 第六章：7 種行為模式 第七章：Deep Research 深度研究功能 第八章：Web Application 開發實戰工作流 第九章：Flags 旗標使用指南 9.4 自動啟動旗標 9.5 MCP Server 旗標 9.6 行為模式旗標 9.7 執行控制旗標 9.8 旗標交互作用與優先規則 第十章：系統維護與管理 第十一章：系統升級 第十二章：團隊協作最佳實踐 附錄 第一章：SuperClaude Framework 概覽 章節摘要：本章介紹 SuperClaude Framework 的核心定位、設計理念與生態系架構。讀者將瞭解它如何將原生 Claude Code CLI 轉化為具備完整軟體工程流程的自動化開發平台，以及其 30 個指令、20 個代理人、7 種模式與 8 個 MCP Server 的整體佈局。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/superclaude-framework%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"SuperClaude Framework 生態系教學手冊 版本：基於 SuperClaude Framework v4.3.0 撰寫\n最後更新：2026-06-30 適用對象：資深工程師、技術主管、全端開發團隊\n文件性質：企業標準技術白皮書 / 實戰教學手冊\n目錄 第一章：SuperClaude Framework 概覽 第二章：系統需求與安裝 第三章：系統設定與配置 第四章：30 個 Slash 指令完整指南 4.10 指令差異比較與選擇指南 第五章：20 個 AI 代理人使用指南 5.4 代理人協調模式 第六章：7 種行為模式 第七章：Deep Research 深度研究功能 第八章：Web Application 開發實戰工作流 第九章：Flags 旗標使用指南 9.4 自動啟動旗標 9.5 MCP Server 旗標 9.6 行為模式旗標 9.7 執行控制旗標 9.8 旗標交互作用與優先規則 第十章：系統維護與管理 第十一章：系統升級 第十二章：團隊協作最佳實踐 附錄 第一章：SuperClaude Framework 概覽 章節摘要：本章介紹 SuperClaude Framework 的核心定位、設計理念與生態系架構。讀者將瞭解它如何將原生 Claude Code CLI 轉化為具備完整軟體工程流程的自動化開發平台，以及其 30 個指令、20 個代理人、7 種模式與 8 個 MCP Server 的整體佈局。\n","title":"SuperClaude Framework生態系教學手冊"},{"content":"OpenCode 生態系完整教學手冊 版本：基於 OpenCode v1.17.11（2026 年 6 月）\n適用對象：資深工程師、架構師、DevOps 工程師、技術主管\n文件等級：企業標準技術白皮書\n維護單位：軟體架構組\n最後更新：2026-06-30\n涵蓋範圍：OpenCode 核心、Oh My OpenAgent（OmO）外掛、OpenWork 桌面協作平台\n文件修訂紀錄 版本 日期 修訂者 修訂說明 1.0 2026-03-04 軟體架構組 初版建立 2.0 2026-03-08 軟體架構組 全面更新至 v1.2.21；新增 OmO、OpenWork 章節；擴充至企業白皮書等級 3.0 2026-03-25 軟體架構組 更新至 v1.3.2；OmO v3.13.1 新增 Multimodal Looker / Metis 代理與 Agent Orchestration；OpenWork v0.11.191 新增 Dev Mode、Templates、Cloud Worker 3.0 2026-03-25 軟體架構組 全面更新至 OpenCode v1.3.2、OmO v3.13.1、OpenWork v0.11.191；新增 Multimodal Looker、Metis、Agent Orchestration 分類路由、雲端 Worker 架構等新功能 4.0 2026-04-12 軟體架構組 全面更新至 OpenCode v1.4.3、OmO v3.17.0、OpenWork v0.11.206；OpenCode 新增 OpenCode Go 訂閱、40+ 提供商支援、Docker 安裝、Ollama Cloud；OmO 更名 oh-my-openagent、OpenCode v1.4.0 最低版本檢查、Doctor 診斷命令、Session Recovery、File Prompts；OpenWork 授權變更為 FSL-1.1-MIT、Ollama 支援、React Session Composer、i18n 五語系 5.0 2026-04-16 軟體架構組 更新至 OpenCode v1.4.6（762 releases、oxlint 整合、provider auth API）、OmO v3.17.3（164 releases、replace_plan 支援、CLA 與 Telemetry 機制）、OpenWork v0.11.207（1,057 releases、Catalan 語系、microsandbox 沙箱流程、Roadmap 分頁、Node 24 CI 準備）；新增 multiedit 工具、Sisyphus Labs 等待名單、提供商新增 40+ 項 6.0 2026-04-30 軟體架構組 全面更新至 OpenCode v1.14.30（781 releases、152k Stars、875 貢獻者、question 工具、agent create CLI、Desktop App BETA 正式化）、OmO v3.17.10（168 releases、55.1k Stars、199 貢獻者、GPT-5.5 native prompt drafts、npm OIDC CI 改進）、OpenWork v0.13.0（1,087 releases、14.5k Stars、Tauri→Electron 遷移、Cloud MCP OAuth Server、Welcome/Onboarding 畫面、microsandbox 功能旗標、pnpm workspace 重構）；新增 ACP 支援文件、SDK 文件、Server 文件、外掛文件、生態系統文件 7.0 2026-05-14 軟體架構組 全面更新至 OpenCode v1.14.50（800 releases、160k Stars、896 貢獻者、Scout SubAgent 新增、native LLM core foundation、TUI notifications、Electron Desktop CI 改進）、OmO v4.1.2（177 releases、57.7k Stars、219 貢獻者、Team Mode v4.0 多代理並行、hyperplan/security-research 技能、Kimi K2.6/GPT-5.5/GLM-5.1 模型支援、configurable agent ordering、CDP browser tools）、OpenWork v0.13.8（1,202 releases、15.2k Stars、61 貢獻者、shadcn/ui skills、Electron browser automation、Daytona/devcontainer、native main menu、10 語系支援、AI Providers 重構） 8.0 2026-05-31 軟體架構組 全面更新至 OpenCode v1.15.13（815 releases、168k Stars、921 貢獻者、database schema 重構、keymap fallback 改進、gcp metadata 修正、stats 路由功能、nix 更新）、OmO v4.5.12（187 releases、60.4k Stars、268 貢獻者、Multi-Harness Agent OS 重構支援 OpenCode/Codex/Pi 多平台、lazycodex Light Edition、omo-codex 可攜版、54+ 生命週期掛鉤、security-review 內建技能、.agents 目錄遷移）、OpenWork v0.14.0（1,346 releases、15.7k Stars、62 貢獻者、Google Workspace OAuth、Voice mode CDP 音訊檢查、pnpm v11 遷移、內建擴充市集、SCIM/SSO 企業管理流程、新版訊息列表 UI、embedded OpenCode 升級至 v1.15.12） 9.0 2026-06-30 軟體架構組 全面更新至 OpenCode v1.17.11（828 releases、181k Stars、959 貢獻者、VS Code Extension v1.17.11 同步發佈、Desktop Electron session title hover 改進、stats route 功能完善、GitHub issue actions 優化、SDK v2 SSE streams 修正、location node 重構）、OmO v4.14.1（208 releases、64.3k Stars、290 貢獻者、Multi-Harness Agent OS 重構完成支援 OpenCode/Codex/Pi/Claude Code 四平台、LazyCodex Light Edition 正式版八組件發佈、telemetry 架構統一 DAU/WAU/MAU 追蹤、omo-opencode 套件獨立模組化、source-state 修復、Codegraph MCP server 新增、共享技能 frontend 子模組化）、OpenWork v0.17.4（1,610 releases、16.5k Stars、65 貢獻者、重新定位為 Claude Cowork 開源替代品、SignPath.io 免費程式碼簽署、Enterprise Plan 正式化含 SSO/SLA/LTS、OpenWork Orchestrator CLI 獨立套件、Docker images 發佈 den-api/eval-vnc/charts、pnpm v10.27.0 + Bun 1.3.9+ 環境要求、Windows 付費支援計畫、Dev Mode 隔離 OPENWORK_DEV_MODE 自動啟用、10 語系支援完善） 目錄 第一章：OpenCode 生態系總覽 1.1 OpenCode 核心理念 1.2 生態系全景圖 1.3 與傳統 AI Coding Tool 差異 1.4 與 GitHub Copilot / Claude Code 等工具比較 1.5 適用場景分析 1.6 真實案例研究 1.7 版本演進與藍圖 第二章：系統架構設計 2.1 總體架構 2.2 Client/Server 架構 2.3 代理系統（Agent System） 2.3.1 主要代理（Primary Agents） 2.3.2 子代理（SubAgents） 2.3.3 隱藏系統代理 2.3.4 自訂代理 2.3.5 代理進階選項 2.3.6 Plan / Build 運作流程 2.4 工具系統（Tools） 2.5 MCP 伺服器整合架構 2.6 外掛系統（Plugins） 2.7 技能系統（Skills） 2.8 與前端框架整合方式 2.9 與後端框架整合方式 2.10 與 Git / CI/CD 整合架構 2.11 與本地模型 / 雲端模型整合架構 第三章：安裝與環境建置 3.1 系統需求 3.2 Windows 安裝步驟 3.3 macOS 安裝步驟 3.4 Linux 安裝步驟 3.5 Desktop App 安裝 3.6 終端機模式設定 3.7 IDE 擴充設定 3.8 模型設定（雲端 API / 本地模型） 3.9 環境變數與 Proxy 設定 3.10 企業網路限制處理方式 第四章：專案導入標準流程（SOP） 4.1 新專案導入流程 4.2 舊專案導入流程 4.3 Branch 管理策略 4.4 PR 與 Code Review 搭配方式 4.5 團隊協作模式 4.6 安全開發流程（SSDLC 整合方式） 第五章：實戰操作教學 5.1 使用 Plan 模式設計系統架構 5.2 使用 Build 模式產生程式碼 5.3 自動產生測試 5.4 重構（Refactor） 5.5 Debug 5.6 批次修改專案 5.7 生成文件（README / API 文件） 5.8 使用 Explore / Scout SubAgent 探索程式碼庫與外部文件 5.9 使用自訂指令加速工作流程 5.10 網路搜尋與網頁擷取 5.11 LSP 整合操作 5.12 實戰範例：完整的 CRUD API 開發流程 第六章：最佳實踐（Best Practices） 6.1 Prompt 撰寫策略 6.2 Token 控制策略 6.3 避免幻覺（Hallucination） 6.4 如何做 Code Validation 6.5 與 SonarQube / 測試工具整合 6.6 大型專案使用策略 6.7 多模組專案管理建議 6.8 格式化器整合 6.9 多語言專案管理策略 6.10 程式碼審查最佳實踐 6.11 TDD/BDD 與 OpenCode 整合 6.12 安全編碼規範指南 6.13 效能優化策略 第七章：系統維護與治理 7.1 模型版本管理策略 7.2 OpenCode 版本管理 7.3 日誌管理 7.4 成本控制 7.5 權限管理 7.5.1 完整權限列表 7.5.2 細粒度權限控制 7.5.3 「ask」選項的三個選擇 7.5.4 代理專屬權限 7.6 技能系統（Skills） 7.6.1 SKILL.md 檔案格式 7.6.2 技能發現路徑 7.6.3 技能權限控制 7.7 自訂工具（Custom Tools） 7.7.1 工具定義 7.7.2 多工具匯出 7.7.3 覆蓋內建工具 7.8 規則系統（Rules） 7.9 風險控管 第八章：系統升級策略 8.1 升級前檢查清單 8.2 版本相容性測試 8.3 回滾策略 8.4 CI/CD 驗證流程 第九章：企業導入建議 9.1 導入階段規劃 9.2 教育訓練策略 9.3 試點專案規劃 9.4 成本效益分析 9.5 KPI 設計 9.6 企業版功能 9.7 企業級安全治理架構 9.8 企業導入常見挑戰與解決方案 9.9 多團隊統一管理方案 9.10 成本分析與 ROI 模型 第十章：Oh My OpenAgent（OmO）生態系 10.1 OmO 總覽與定位 10.2 核心概念：Discipline Agents 10.3 ultrawork / ulw 一鍵啟動 10.4 IntentGate 意圖閘道 10.5 Hash-Anchored Edit Tool 10.6 /init-deep 深度初始化 10.7 Prometheus 規劃器 10.8 背景代理（Background Agents） 10.9 Skill-Embedded MCPs 10.10 Ralph Loop 自我迴圈 10.11 Todo Enforcer 與 Comment Checker 10.12 內建 MCP 伺服器 10.13 LSP 與 AST-Grep 整合 10.14 Tmux 整合 10.15 Claude Code 完整相容性 10.16 Agent Orchestration 模型路由 10.17 安裝與設定 10.18 設定檔詳解 10.19 企業導入 OmO 建議 10.20 OmO 實戰教學：微服務拆分 10.21 OmO 與 OpenCode 功能對照表 10.22 OmO 效能調優指南 10.23 Multimodal Looker 代理（v3.12+ 新增） 10.24 Metis 代理——規劃顧問（v3.12+ 新增） 10.25 GPT-5.5 xhigh 路由與 ultrabrain 模式（v3.13+ 新增） 10.26 Session Tools——歷程分析（v3.13+ 新增） 10.27 Think Mode（v3.13+ 新增） 10.28 OmO v3.13 其他更新 10.29 OmO v3.14-v3.17.10 更新摘要 10.30 OmO v4.0-v4.5.12 更新摘要（Team Mode 與 Multi-Harness OS 重大版本） 10.31 OmO v4.6-v4.14.1 更新摘要（Multi-Harness 完成與 LazyCodex 正式版） 第十一章：OpenWork 桌面應用與協作平台 11.1 OpenWork 總覽與定位 11.2 核心理念 11.3 功能架構 11.4 Host 模式與 Client 模式 11.5 技能管理器（Skill Manager） 11.6 OpenWork Orchestrator CLI 11.7 OpenCode Router（WhatsApp / Slack / Telegram） 11.8 OpenPackage 套件管理 11.9 安裝與設定 11.10 架構詳解 11.11 安全性設計 11.12 Dev Mode 隔離（v0.11.160+ 新增） 11.13 Templates 儲存與重播（v0.11.170+ 新增） 11.14 Execution Plan Timeline（v0.11.180+ 新增） 11.15 Cloud Worker 架構（v0.11.185+ 新增） 11.16 Workspace Switch 與 Starter Sessions（v0.11.190+ 新增） 11.17 OpenCode Plugins 管理（Skills Tab） 11.18 OpenWork v0.11.192-v0.14.0 更新摘要 11.19 OpenWork v0.14.1-v0.17.4 更新摘要 11.20 企業導入 OpenWork 建議 第十二章：生態系整合與進階工作流程 12.1 OpenCode + OmO + OpenWork 三層整合 12.2 多代理協作工作流程 12.3 企業級 AI 開發平台架構 12.4 跨團隊協作模式 12.5 從 Claude Code 遷移指南 12.6 GitHub / GitLab 深度整合 12.7 ACP（Agent Communication Protocol）支援 12.8 CI/CD 管線深度整合 12.9 多倉庫聯合開發模式 12.10 資料庫遷移自動化 12.11 監控與可觀察性整合 12.12 基礎架構即程式碼（IaC）整合 12.13 企業級日誌與稽核系統 12.14 企業災難復原與高可用方案 第十三章：常見問題與故障排除 13.1 安裝問題 13.2 API 連線失敗 13.3 模型回應不穩 13.4 權限問題 13.5 IDE 無法連線 13.6 效能問題 13.7 OmO 特定問題 13.8 OpenWork 特定問題 附錄 A：快速上手檢查清單（Checklist） 附錄 B：常見 OpenCode 指令速查表 附錄 C：OmO 指令速查表 附錄 D：設定檔完整範例 附錄 E：MCP 伺服器推薦清單 附錄 F：模型推薦與比較 附錄 G：重要參考資源 附錄 H：術語表 第一章：OpenCode 生態系總覽 1.1 OpenCode 核心理念 OpenCode 是一個 100% 開源 的 AI 編碼代理（AI Coding Agent），由 Anomaly 團隊開發維護。截至 2026 年 6 月，OpenCode 已達到以下里程碑：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/opencode%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"OpenCode 生態系完整教學手冊 版本：基於 OpenCode v1.17.11（2026 年 6 月）\n適用對象：資深工程師、架構師、DevOps 工程師、技術主管\n文件等級：企業標準技術白皮書\n維護單位：軟體架構組\n最後更新：2026-06-30\n涵蓋範圍：OpenCode 核心、Oh My OpenAgent（OmO）外掛、OpenWork 桌面協作平台\n文件修訂紀錄 版本 日期 修訂者 修訂說明 1.0 2026-03-04 軟體架構組 初版建立 2.0 2026-03-08 軟體架構組 全面更新至 v1.2.21；新增 OmO、OpenWork 章節；擴充至企業白皮書等級 3.0 2026-03-25 軟體架構組 更新至 v1.3.2；OmO v3.13.1 新增 Multimodal Looker / Metis 代理與 Agent Orchestration；OpenWork v0.11.191 新增 Dev Mode、Templates、Cloud Worker 3.0 2026-03-25 軟體架構組 全面更新至 OpenCode v1.3.2、OmO v3.13.1、OpenWork v0.11.191；新增 Multimodal Looker、Metis、Agent Orchestration 分類路由、雲端 Worker 架構等新功能 4.0 2026-04-12 軟體架構組 全面更新至 OpenCode v1.4.3、OmO v3.17.0、OpenWork v0.11.206；OpenCode 新增 OpenCode Go 訂閱、40+ 提供商支援、Docker 安裝、Ollama Cloud；OmO 更名 oh-my-openagent、OpenCode v1.4.0 最低版本檢查、Doctor 診斷命令、Session Recovery、File Prompts；OpenWork 授權變更為 FSL-1.1-MIT、Ollama 支援、React Session Composer、i18n 五語系 5.0 2026-04-16 軟體架構組 更新至 OpenCode v1.4.6（762 releases、oxlint 整合、provider auth API）、OmO v3.17.3（164 releases、replace_plan 支援、CLA 與 Telemetry 機制）、OpenWork v0.11.207（1,057 releases、Catalan 語系、microsandbox 沙箱流程、Roadmap 分頁、Node 24 CI 準備）；新增 multiedit 工具、Sisyphus Labs 等待名單、提供商新增 40+ 項 6.0 2026-04-30 軟體架構組 全面更新至 OpenCode v1.14.30（781 releases、152k Stars、875 貢獻者、question 工具、agent create CLI、Desktop App BETA 正式化）、OmO v3.17.10（168 releases、55.1k Stars、199 貢獻者、GPT-5.5 native prompt drafts、npm OIDC CI 改進）、OpenWork v0.13.0（1,087 releases、14.5k Stars、Tauri→Electron 遷移、Cloud MCP OAuth Server、Welcome/Onboarding 畫面、microsandbox 功能旗標、pnpm workspace 重構）；新增 ACP 支援文件、SDK 文件、Server 文件、外掛文件、生態系統文件 7.0 2026-05-14 軟體架構組 全面更新至 OpenCode v1.14.50（800 releases、160k Stars、896 貢獻者、Scout SubAgent 新增、native LLM core foundation、TUI notifications、Electron Desktop CI 改進）、OmO v4.1.2（177 releases、57.7k Stars、219 貢獻者、Team Mode v4.0 多代理並行、hyperplan/security-research 技能、Kimi K2.6/GPT-5.5/GLM-5.1 模型支援、configurable agent ordering、CDP browser tools）、OpenWork v0.13.8（1,202 releases、15.2k Stars、61 貢獻者、shadcn/ui skills、Electron browser automation、Daytona/devcontainer、native main menu、10 語系支援、AI Providers 重構） 8.0 2026-05-31 軟體架構組 全面更新至 OpenCode v1.15.13（815 releases、168k Stars、921 貢獻者、database schema 重構、keymap fallback 改進、gcp metadata 修正、stats 路由功能、nix 更新）、OmO v4.5.12（187 releases、60.4k Stars、268 貢獻者、Multi-Harness Agent OS 重構支援 OpenCode/Codex/Pi 多平台、lazycodex Light Edition、omo-codex 可攜版、54+ 生命週期掛鉤、security-review 內建技能、.agents 目錄遷移）、OpenWork v0.14.0（1,346 releases、15.7k Stars、62 貢獻者、Google Workspace OAuth、Voice mode CDP 音訊檢查、pnpm v11 遷移、內建擴充市集、SCIM/SSO 企業管理流程、新版訊息列表 UI、embedded OpenCode 升級至 v1.15.12） 9.0 2026-06-30 軟體架構組 全面更新至 OpenCode v1.17.11（828 releases、181k Stars、959 貢獻者、VS Code Extension v1.17.11 同步發佈、Desktop Electron session title hover 改進、stats route 功能完善、GitHub issue actions 優化、SDK v2 SSE streams 修正、location node 重構）、OmO v4.14.1（208 releases、64.3k Stars、290 貢獻者、Multi-Harness Agent OS 重構完成支援 OpenCode/Codex/Pi/Claude Code 四平台、LazyCodex Light Edition 正式版八組件發佈、telemetry 架構統一 DAU/WAU/MAU 追蹤、omo-opencode 套件獨立模組化、source-state 修復、Codegraph MCP server 新增、共享技能 frontend 子模組化）、OpenWork v0.17.4（1,610 releases、16.5k Stars、65 貢獻者、重新定位為 Claude Cowork 開源替代品、SignPath.io 免費程式碼簽署、Enterprise Plan 正式化含 SSO/SLA/LTS、OpenWork Orchestrator CLI 獨立套件、Docker images 發佈 den-api/eval-vnc/charts、pnpm v10.27.0 + Bun 1.3.9+ 環境要求、Windows 付費支援計畫、Dev Mode 隔離 OPENWORK_DEV_MODE 自動啟用、10 語系支援完善） 目錄 第一章：OpenCode 生態系總覽 1.1 OpenCode 核心理念 1.2 生態系全景圖 1.3 與傳統 AI Coding Tool 差異 1.4 與 GitHub Copilot / Claude Code 等工具比較 1.5 適用場景分析 1.6 真實案例研究 1.7 版本演進與藍圖 第二章：系統架構設計 2.1 總體架構 2.2 Client/Server 架構 2.3 代理系統（Agent System） 2.3.1 主要代理（Primary Agents） 2.3.2 子代理（SubAgents） 2.3.3 隱藏系統代理 2.3.4 自訂代理 2.3.5 代理進階選項 2.3.6 Plan / Build 運作流程 2.4 工具系統（Tools） 2.5 MCP 伺服器整合架構 2.6 外掛系統（Plugins） 2.7 技能系統（Skills） 2.8 與前端框架整合方式 2.9 與後端框架整合方式 2.10 與 Git / CI/CD 整合架構 2.11 與本地模型 / 雲端模型整合架構 第三章：安裝與環境建置 3.1 系統需求 3.2 Windows 安裝步驟 3.3 macOS 安裝步驟 3.4 Linux 安裝步驟 3.5 Desktop App 安裝 3.6 終端機模式設定 3.7 IDE 擴充設定 3.8 模型設定（雲端 API / 本地模型） 3.9 環境變數與 Proxy 設定 3.10 企業網路限制處理方式 第四章：專案導入標準流程（SOP） 4.1 新專案導入流程 4.2 舊專案導入流程 4.3 Branch 管理策略 4.4 PR 與 Code Review 搭配方式 4.5 團隊協作模式 4.6 安全開發流程（SSDLC 整合方式） 第五章：實戰操作教學 5.1 使用 Plan 模式設計系統架構 5.2 使用 Build 模式產生程式碼 5.3 自動產生測試 5.4 重構（Refactor） 5.5 Debug 5.6 批次修改專案 5.7 生成文件（README / API 文件） 5.8 使用 Explore / Scout SubAgent 探索程式碼庫與外部文件 5.9 使用自訂指令加速工作流程 5.10 網路搜尋與網頁擷取 5.11 LSP 整合操作 5.12 實戰範例：完整的 CRUD API 開發流程 第六章：最佳實踐（Best Practices） 6.1 Prompt 撰寫策略 6.2 Token 控制策略 6.3 避免幻覺（Hallucination） 6.4 如何做 Code Validation 6.5 與 SonarQube / 測試工具整合 6.6 大型專案使用策略 6.7 多模組專案管理建議 6.8 格式化器整合 6.9 多語言專案管理策略 6.10 程式碼審查最佳實踐 6.11 TDD/BDD 與 OpenCode 整合 6.12 安全編碼規範指南 6.13 效能優化策略 第七章：系統維護與治理 7.1 模型版本管理策略 7.2 OpenCode 版本管理 7.3 日誌管理 7.4 成本控制 7.5 權限管理 7.5.1 完整權限列表 7.5.2 細粒度權限控制 7.5.3 「ask」選項的三個選擇 7.5.4 代理專屬權限 7.6 技能系統（Skills） 7.6.1 SKILL.md 檔案格式 7.6.2 技能發現路徑 7.6.3 技能權限控制 7.7 自訂工具（Custom Tools） 7.7.1 工具定義 7.7.2 多工具匯出 7.7.3 覆蓋內建工具 7.8 規則系統（Rules） 7.9 風險控管 第八章：系統升級策略 8.1 升級前檢查清單 8.2 版本相容性測試 8.3 回滾策略 8.4 CI/CD 驗證流程 第九章：企業導入建議 9.1 導入階段規劃 9.2 教育訓練策略 9.3 試點專案規劃 9.4 成本效益分析 9.5 KPI 設計 9.6 企業版功能 9.7 企業級安全治理架構 9.8 企業導入常見挑戰與解決方案 9.9 多團隊統一管理方案 9.10 成本分析與 ROI 模型 第十章：Oh My OpenAgent（OmO）生態系 10.1 OmO 總覽與定位 10.2 核心概念：Discipline Agents 10.3 ultrawork / ulw 一鍵啟動 10.4 IntentGate 意圖閘道 10.5 Hash-Anchored Edit Tool 10.6 /init-deep 深度初始化 10.7 Prometheus 規劃器 10.8 背景代理（Background Agents） 10.9 Skill-Embedded MCPs 10.10 Ralph Loop 自我迴圈 10.11 Todo Enforcer 與 Comment Checker 10.12 內建 MCP 伺服器 10.13 LSP 與 AST-Grep 整合 10.14 Tmux 整合 10.15 Claude Code 完整相容性 10.16 Agent Orchestration 模型路由 10.17 安裝與設定 10.18 設定檔詳解 10.19 企業導入 OmO 建議 10.20 OmO 實戰教學：微服務拆分 10.21 OmO 與 OpenCode 功能對照表 10.22 OmO 效能調優指南 10.23 Multimodal Looker 代理（v3.12+ 新增） 10.24 Metis 代理——規劃顧問（v3.12+ 新增） 10.25 GPT-5.5 xhigh 路由與 ultrabrain 模式（v3.13+ 新增） 10.26 Session Tools——歷程分析（v3.13+ 新增） 10.27 Think Mode（v3.13+ 新增） 10.28 OmO v3.13 其他更新 10.29 OmO v3.14-v3.17.10 更新摘要 10.30 OmO v4.0-v4.5.12 更新摘要（Team Mode 與 Multi-Harness OS 重大版本） 10.31 OmO v4.6-v4.14.1 更新摘要（Multi-Harness 完成與 LazyCodex 正式版） 第十一章：OpenWork 桌面應用與協作平台 11.1 OpenWork 總覽與定位 11.2 核心理念 11.3 功能架構 11.4 Host 模式與 Client 模式 11.5 技能管理器（Skill Manager） 11.6 OpenWork Orchestrator CLI 11.7 OpenCode Router（WhatsApp / Slack / Telegram） 11.8 OpenPackage 套件管理 11.9 安裝與設定 11.10 架構詳解 11.11 安全性設計 11.12 Dev Mode 隔離（v0.11.160+ 新增） 11.13 Templates 儲存與重播（v0.11.170+ 新增） 11.14 Execution Plan Timeline（v0.11.180+ 新增） 11.15 Cloud Worker 架構（v0.11.185+ 新增） 11.16 Workspace Switch 與 Starter Sessions（v0.11.190+ 新增） 11.17 OpenCode Plugins 管理（Skills Tab） 11.18 OpenWork v0.11.192-v0.14.0 更新摘要 11.19 OpenWork v0.14.1-v0.17.4 更新摘要 11.20 企業導入 OpenWork 建議 第十二章：生態系整合與進階工作流程 12.1 OpenCode + OmO + OpenWork 三層整合 12.2 多代理協作工作流程 12.3 企業級 AI 開發平台架構 12.4 跨團隊協作模式 12.5 從 Claude Code 遷移指南 12.6 GitHub / GitLab 深度整合 12.7 ACP（Agent Communication Protocol）支援 12.8 CI/CD 管線深度整合 12.9 多倉庫聯合開發模式 12.10 資料庫遷移自動化 12.11 監控與可觀察性整合 12.12 基礎架構即程式碼（IaC）整合 12.13 企業級日誌與稽核系統 12.14 企業災難復原與高可用方案 第十三章：常見問題與故障排除 13.1 安裝問題 13.2 API 連線失敗 13.3 模型回應不穩 13.4 權限問題 13.5 IDE 無法連線 13.6 效能問題 13.7 OmO 特定問題 13.8 OpenWork 特定問題 附錄 A：快速上手檢查清單（Checklist） 附錄 B：常見 OpenCode 指令速查表 附錄 C：OmO 指令速查表 附錄 D：設定檔完整範例 附錄 E：MCP 伺服器推薦清單 附錄 F：模型推薦與比較 附錄 G：重要參考資源 附錄 H：術語表 第一章：OpenCode 生態系總覽 1.1 OpenCode 核心理念 OpenCode 是一個 100% 開源 的 AI 編碼代理（AI Coding Agent），由 Anomaly 團隊開發維護。截至 2026 年 6 月，OpenCode 已達到以下里程碑：\n","title":"OpenCode 生態系完整教學手冊"},{"content":"JavaScript 程式語言教學手冊 文件資訊 版本: 2.0 更新日期: 2026年2月20日 適用對象: 新進前端開發同仁 專案架構: 前後端分離 (Vue 3.x / React / Angular) 涵蓋標準: 至 ECMAScript 2025（ES16） 目錄 JavaScript 基本概念\n1.1 語言特性 1.2 基礎資料型別與運算子 1.3 變數與作用域 1.4 函式與閉包 1.5 物件與原型鏈 1.6 ES6+ 常用語法 1.7 實務注意事項 1.8 ES2023-ES2025 新特性 1.8.1 ES2023 新特性 1.8.2 ES2024 新特性 1.8.3 ES2025 新特性 1.8.4 ES2025 瀏覽器支援狀態 程式開發規範\n2.1 程式碼風格指南 2.2 ESLint 和 Prettier 設定 2.3 專案中常用的 Utility Functions 專案中常見應用範例\n3.1 DOM 操作與事件處理 3.2 非同步處理 3.3 與後端 API 溝通 3.4 錯誤處理與例外狀況處理 3.5 Web APIs 應用 3.6 專案最佳實務 3.7 測試與除錯 現代開發工具與 TypeScript\n4.1 TypeScript 基礎 4.2 建置工具 學習資源與進階閱讀\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/javascript%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"JavaScript 程式語言教學手冊 文件資訊 版本: 2.0 更新日期: 2026年2月20日 適用對象: 新進前端開發同仁 專案架構: 前後端分離 (Vue 3.x / React / Angular) 涵蓋標準: 至 ECMAScript 2025（ES16） 目錄 JavaScript 基本概念\n1.1 語言特性 1.2 基礎資料型別與運算子 1.3 變數與作用域 1.4 函式與閉包 1.5 物件與原型鏈 1.6 ES6+ 常用語法 1.7 實務注意事項 1.8 ES2023-ES2025 新特性 1.8.1 ES2023 新特性 1.8.2 ES2024 新特性 1.8.3 ES2025 新特性 1.8.4 ES2025 瀏覽器支援狀態 程式開發規範\n2.1 程式碼風格指南 2.2 ESLint 和 Prettier 設定 2.3 專案中常用的 Utility Functions 專案中常見應用範例\n3.1 DOM 操作與事件處理 3.2 非同步處理 3.3 與後端 API 溝通 3.4 錯誤處理與例外狀況處理 3.5 Web APIs 應用 3.6 專案最佳實務 3.7 測試與除錯 現代開發工具與 TypeScript\n4.1 TypeScript 基礎 4.2 建置工具 學習資源與進階閱讀\n","title":"JavaScript程式語言教學"},{"content":"TypeScript 程式語言教學手冊 適用對象：新進前端開發同仁\n目標：快速掌握 TypeScript 在專案中的使用方法與最佳實踐\n更新日期：2026年2月20日\n📋 目錄 TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 1.2 型別系統 1.3 介面與型別別名 專案規範 2.1 TypeScript 版本與設定 2.2 檔案命名規則與專案目錄結構 2.3 型別宣告的最佳實踐 2.4 使用 any 的限制與替代方法 程式開發指引 3.1 撰寫可讀性與可維護性的程式碼 3.2 常見錯誤與最佳解法 3.3 與第三方套件整合 範例程式碼 4.1 Class 類別實作範例 4.2 Interface 介面範例 4.3 泛型實作範例 4.4 模組化範例 實務建議 5.1 善用 TypeScript 的型別檢查 5.2 除錯與測試 5.3 團隊協作與程式風格統一 檢查清單 6.1 專案建立檢查清單 6.2 開發期間檢查清單 6.3 程式碼審查檢查清單 6.4 部署前檢查清單 6.5 常見問題快速檢查 進階主題 7.1 條件型別 (Conditional Types) 7.2 映射型別 (Mapped Types) 7.3 模板字面型別 (Template Literal Types) 7.4 裝飾器 (Decorators) 效能優化與最佳實踐 8.1 編譯效能優化 8.2 型別檢查效能 8.3 打包優化 8.4 記憶體使用優化 TypeScript 生態系統 9.1 開發工具 9.2 建置工具 9.3 測試框架 9.4 型別定義管理 常見問題與解決方案 10.1 編譯錯誤 10.2 型別推斷問題 10.3 執行時期問題 10.4 最佳實踐檢查清單 TypeScript 6.0 與 7.0 新特性與遷移 11.1 TypeScript 6.0 新特性 11.2 TypeScript 6.0 重大變更與棄用 11.3 TypeScript 7.0 原生編譯器 (Go 版本) 11.4 從 5.x 遷移至 6.0/7.0 指南 1. TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 什麼是 TypeScript？ TypeScript 是 Microsoft 開發的 JavaScript 超集（superset），為 JavaScript 添加了靜態型別檢查功能。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/typescript%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"TypeScript 程式語言教學手冊 適用對象：新進前端開發同仁\n目標：快速掌握 TypeScript 在專案中的使用方法與最佳實踐\n更新日期：2026年2月20日\n📋 目錄 TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 1.2 型別系統 1.3 介面與型別別名 專案規範 2.1 TypeScript 版本與設定 2.2 檔案命名規則與專案目錄結構 2.3 型別宣告的最佳實踐 2.4 使用 any 的限制與替代方法 程式開發指引 3.1 撰寫可讀性與可維護性的程式碼 3.2 常見錯誤與最佳解法 3.3 與第三方套件整合 範例程式碼 4.1 Class 類別實作範例 4.2 Interface 介面範例 4.3 泛型實作範例 4.4 模組化範例 實務建議 5.1 善用 TypeScript 的型別檢查 5.2 除錯與測試 5.3 團隊協作與程式風格統一 檢查清單 6.1 專案建立檢查清單 6.2 開發期間檢查清單 6.3 程式碼審查檢查清單 6.4 部署前檢查清單 6.5 常見問題快速檢查 進階主題 7.1 條件型別 (Conditional Types) 7.2 映射型別 (Mapped Types) 7.3 模板字面型別 (Template Literal Types) 7.4 裝飾器 (Decorators) 效能優化與最佳實踐 8.1 編譯效能優化 8.2 型別檢查效能 8.3 打包優化 8.4 記憶體使用優化 TypeScript 生態系統 9.1 開發工具 9.2 建置工具 9.3 測試框架 9.4 型別定義管理 常見問題與解決方案 10.1 編譯錯誤 10.2 型別推斷問題 10.3 執行時期問題 10.4 最佳實踐檢查清單 TypeScript 6.0 與 7.0 新特性與遷移 11.1 TypeScript 6.0 新特性 11.2 TypeScript 6.0 重大變更與棄用 11.3 TypeScript 7.0 原生編譯器 (Go 版本) 11.4 從 5.x 遷移至 6.0/7.0 指南 1. TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 什麼是 TypeScript？ TypeScript 是 Microsoft 開發的 JavaScript 超集（superset），為 JavaScript 添加了靜態型別檢查功能。\n","title":"TypeScript程式語言教學"},{"content":"TypeScript 程式語言教學手冊 適用對象：新進前端開發同仁\n目標：快速掌握 TypeScript 在專案中的使用方法與最佳實踐\n更新日期：2026年2月20日\n📋 目錄 TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 1.2 型別系統 1.3 介面與型別別名 專案規範 2.1 TypeScript 版本與設定 2.2 檔案命名規則與專案目錄結構 2.3 型別宣告的最佳實踐 2.4 使用 any 的限制與替代方法 程式開發指引 3.1 撰寫可讀性與可維護性的程式碼 3.2 常見錯誤與最佳解法 3.3 與第三方套件整合 範例程式碼 4.1 Class 類別實作範例 4.2 Interface 介面範例 4.3 泛型實作範例 4.4 模組化範例 實務建議 5.1 善用 TypeScript 的型別檢查 5.2 除錯與測試 5.3 團隊協作與程式風格統一 檢查清單 6.1 專案建立檢查清單 6.2 開發期間檢查清單 6.3 程式碼審查檢查清單 6.4 部署前檢查清單 6.5 常見問題快速檢查 進階主題 7.1 條件型別 (Conditional Types) 7.2 映射型別 (Mapped Types) 7.3 模板字面型別 (Template Literal Types) 7.4 裝飾器 (Decorators) 效能優化與最佳實踐 8.1 編譯效能優化 8.2 型別檢查效能 8.3 打包優化 8.4 記憶體使用優化 TypeScript 生態系統 9.1 開發工具 9.2 建置工具 9.3 測試框架 9.4 型別定義管理 常見問題與解決方案 10.1 編譯錯誤 10.2 型別推斷問題 10.3 執行時期問題 10.4 最佳實踐檢查清單 TypeScript 6.0 與 7.0 新特性與遷移 11.1 TypeScript 6.0 新特性 11.2 TypeScript 6.0 重大變更與棄用 11.3 TypeScript 7.0 原生編譯器 (Go 版本) 11.4 從 5.x 遷移至 6.0/7.0 指南 1. TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 什麼是 TypeScript？ TypeScript 是 Microsoft 開發的 JavaScript 超集（superset），為 JavaScript 添加了靜態型別檢查功能。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/typescript%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"TypeScript 程式語言教學手冊 適用對象：新進前端開發同仁\n目標：快速掌握 TypeScript 在專案中的使用方法與最佳實踐\n更新日期：2026年2月20日\n📋 目錄 TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 1.2 型別系統 1.3 介面與型別別名 專案規範 2.1 TypeScript 版本與設定 2.2 檔案命名規則與專案目錄結構 2.3 型別宣告的最佳實踐 2.4 使用 any 的限制與替代方法 程式開發指引 3.1 撰寫可讀性與可維護性的程式碼 3.2 常見錯誤與最佳解法 3.3 與第三方套件整合 範例程式碼 4.1 Class 類別實作範例 4.2 Interface 介面範例 4.3 泛型實作範例 4.4 模組化範例 實務建議 5.1 善用 TypeScript 的型別檢查 5.2 除錯與測試 5.3 團隊協作與程式風格統一 檢查清單 6.1 專案建立檢查清單 6.2 開發期間檢查清單 6.3 程式碼審查檢查清單 6.4 部署前檢查清單 6.5 常見問題快速檢查 進階主題 7.1 條件型別 (Conditional Types) 7.2 映射型別 (Mapped Types) 7.3 模板字面型別 (Template Literal Types) 7.4 裝飾器 (Decorators) 效能優化與最佳實踐 8.1 編譯效能優化 8.2 型別檢查效能 8.3 打包優化 8.4 記憶體使用優化 TypeScript 生態系統 9.1 開發工具 9.2 建置工具 9.3 測試框架 9.4 型別定義管理 常見問題與解決方案 10.1 編譯錯誤 10.2 型別推斷問題 10.3 執行時期問題 10.4 最佳實踐檢查清單 TypeScript 6.0 與 7.0 新特性與遷移 11.1 TypeScript 6.0 新特性 11.2 TypeScript 6.0 重大變更與棄用 11.3 TypeScript 7.0 原生編譯器 (Go 版本) 11.4 從 5.x 遷移至 6.0/7.0 指南 1. TypeScript 基礎 1.1 TypeScript 與 JavaScript 的差異 什麼是 TypeScript？ TypeScript 是 Microsoft 開發的 JavaScript 超集（superset），為 JavaScript 添加了靜態型別檢查功能。\n","title":"TypeScript程式語言教學"},{"content":" Chrome DevTools MCP（Model Context Protocol）教學手冊 版本：v2.0\n最後更新：2026-02-14\n適用對象：前端工程師、全端工程師、AI 工具整合工程師、DevOps 工程師、架構師\n適用環境：Windows / macOS / Linux\nChrome DevTools MCP 版本：v0.17.0+（套件名稱：chrome-devtools-mcp）\n官方 GitHub：https://github.com/ChromeDevTools/chrome-devtools-mcp\nnpm 套件：https://www.npmjs.com/package/chrome-devtools-mcp\n目錄 第一章：總覽與架構設計\n1.1 MCP 是什麼？ 1.2 Chrome DevTools MCP 架構說明 1.3 系統元件圖 1.4 互動流程圖 1.5 適用場景說明 1.6 與傳統 AI 靜態分析比較 第二章：系統架構設計\n2.1 單機開發架構 2.2 團隊共享架構 2.3 CI/CD 整合架構 2.4 雲端整合架構 2.5 安全隔離建議 2.6 權限控制建議 2.7 沙箱執行模式建議 第三章：安裝與環境建置\n3.1 系統需求 3.2 Chrome 版本需求 3.3 Node.js 版本需求 3.4 安裝步驟 3.5 啟動參數完整說明 3.6 連接模式說明 3.7 User Data Directory 說明 3.8 Docker 安裝方式 3.9 工具類別控制 3.10 常見錯誤排除 第四章：設定與整合\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/chrome-devtools-mcpmodel-context-protocol%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":" Chrome DevTools MCP（Model Context Protocol）教學手冊 版本：v2.0\n最後更新：2026-02-14\n適用對象：前端工程師、全端工程師、AI 工具整合工程師、DevOps 工程師、架構師\n適用環境：Windows / macOS / Linux\nChrome DevTools MCP 版本：v0.17.0+（套件名稱：chrome-devtools-mcp）\n官方 GitHub：https://github.com/ChromeDevTools/chrome-devtools-mcp\nnpm 套件：https://www.npmjs.com/package/chrome-devtools-mcp\n目錄 第一章：總覽與架構設計\n1.1 MCP 是什麼？ 1.2 Chrome DevTools MCP 架構說明 1.3 系統元件圖 1.4 互動流程圖 1.5 適用場景說明 1.6 與傳統 AI 靜態分析比較 第二章：系統架構設計\n2.1 單機開發架構 2.2 團隊共享架構 2.3 CI/CD 整合架構 2.4 雲端整合架構 2.5 安全隔離建議 2.6 權限控制建議 2.7 沙箱執行模式建議 第三章：安裝與環境建置\n3.1 系統需求 3.2 Chrome 版本需求 3.3 Node.js 版本需求 3.4 安裝步驟 3.5 啟動參數完整說明 3.6 連接模式說明 3.7 User Data Directory 說明 3.8 Docker 安裝方式 3.9 工具類別控制 3.10 常見錯誤排除 第四章：設定與整合\n","title":"Chrome DevTools MCP（Model Context Protocol）教學手冊"},{"content":"Chrome DevTools 教學手冊 版本：Chrome 131+（2026 年最新版）\n適用對象：前端工程師、後端工程師、架構師、DevOps 工程師\n定位：企業級實戰與維運教學手冊\n最後更新：2026-02-14\n目錄 第一章：Chrome DevTools 架構與核心原理 第二章：安裝與環境設定 2.8 Device Mode（裝置模擬模式） 2.9 Command Menu（命令選單） 第三章：Elements 面板完整教學 第四章：Console 深入教學 第五章：Sources 面板（JS 除錯核心） 第六章：Network 面板（API 與效能分析） 第七章：Performance 面板（效能優化核心） 7.8 Rendering 面板 7.9 Performance 進階功能 第八章：Memory 面板 第九章：Application 面板 第十章：Security 面板 第十一章：Recorder 面板、AI 輔助與其他進階功能 11.1 Recorder 面板（使用者流程錄製） 11.2 AI 輔助功能（Gemini 整合） 11.3 其他實用面板 11.4 遠端除錯 第十二章：企業級 Web Application Debug 標準流程 第十三章：最佳實踐與團隊規範 附錄 A：常見問題 FAQ 附錄 B：面試常考 DevTools 問題 附錄 C：團隊培訓建議 附錄 D：延伸學習資源 附錄 E：檢查清單（Checklist） 第一章：Chrome DevTools 架構與核心原理 1.1 DevTools 整體架構說明 Chrome DevTools 是內建於 Chromium 核心的開發者除錯工具組，透過 Chrome DevTools Protocol（CDP） 與瀏覽器核心通訊。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/chrome-devtools-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Chrome DevTools 教學手冊 版本：Chrome 131+（2026 年最新版）\n適用對象：前端工程師、後端工程師、架構師、DevOps 工程師\n定位：企業級實戰與維運教學手冊\n最後更新：2026-02-14\n目錄 第一章：Chrome DevTools 架構與核心原理 第二章：安裝與環境設定 2.8 Device Mode（裝置模擬模式） 2.9 Command Menu（命令選單） 第三章：Elements 面板完整教學 第四章：Console 深入教學 第五章：Sources 面板（JS 除錯核心） 第六章：Network 面板（API 與效能分析） 第七章：Performance 面板（效能優化核心） 7.8 Rendering 面板 7.9 Performance 進階功能 第八章：Memory 面板 第九章：Application 面板 第十章：Security 面板 第十一章：Recorder 面板、AI 輔助與其他進階功能 11.1 Recorder 面板（使用者流程錄製） 11.2 AI 輔助功能（Gemini 整合） 11.3 其他實用面板 11.4 遠端除錯 第十二章：企業級 Web Application Debug 標準流程 第十三章：最佳實踐與團隊規範 附錄 A：常見問題 FAQ 附錄 B：面試常考 DevTools 問題 附錄 C：團隊培訓建議 附錄 D：延伸學習資源 附錄 E：檢查清單（Checklist） 第一章：Chrome DevTools 架構與核心原理 1.1 DevTools 整體架構說明 Chrome DevTools 是內建於 Chromium 核心的開發者除錯工具組，透過 Chrome DevTools Protocol（CDP） 與瀏覽器核心通訊。\n","title":"Chrome DevTools 教學手冊"},{"content":"GitHub Copilot CLI 教學手冊 版本：v3.0（2026 年 2 月） 適用對象：資深工程師、DevOps 工程師、技術主管 適用平台：Windows / macOS / Linux 前置條件：具備 Git、Terminal 基礎操作能力；擁有 GitHub Copilot 授權 狀態：GitHub Copilot CLI 目前為 Public Preview（含資料保護），功能可能變更\n目錄 1. GitHub Copilot CLI 架構說明 1.1 Copilot CLI 架構概念 1.2 與 GitHub Copilot IDE 版本的差異 1.3 三種使用模式 1.4 認證流程 1.5 CLI 與 GitHub 雲端服務關係 1.6 CLI 在企業環境中的位置 2. 安裝與環境建置 2.1 系統需求 2.2 Windows 安裝方式 2.3 macOS 安裝方式 2.4 Linux 安裝方式 2.5 使用 npm 安裝（跨平台） 2.6 驗證安裝成功 2.7 代理伺服器（Proxy）環境設定 2.8 防火牆與網路限制處理 3. 基本設定與認證 3.1 首次登入流程 3.2 使用 Personal Access Token 認證 3.3 企業 GitHub 組織授權 3.4 CLI 設定檔說明 3.5 信任目錄管理 3.6 安全設定建議 4. 開發應用方式 4.1 互動模式基本操作 4.2 計畫模式（Plan Mode） 4.3 程式化模式（Programmatic Mode） 4.4 檔案引用與上下文控制 4.5 程式碼產生與重構 4.6 測試程式產生 4.7 Dockerfile 與 CI/CD 產生 4.8 Git 操作與 PR 管理 4.9 工具權限管理 4.10 團隊開發最佳實踐 5. 自訂與擴充功能 5.1 自訂指令（Custom Instructions） 5.2 自訂代理（Custom Agents） 5.3 技能（Skills） 5.4 Hooks 5.5 AI 模型選擇 5.6 Copilot Memory 6. 與 MCP（Model Context Protocol）串接方式 6.1 MCP 架構概念 6.2 內建 GitHub MCP Server 6.3 新增 MCP Server 6.4 自訂 MCP Server 開發 6.5 與企業內部 API 整合 6.6 MCP 安全與權限控管 7. DevOps 整合模式 7.1 與 GitHub Actions 整合 7.2 與 CI/CD Pipeline 整合 7.3 容器化開發流程 7.4 AI 輔助 Code Review 7.5 委派工作至 Copilot Coding Agent 7.6 Commit Message 與 PR 最佳實務 8. 系統維護與治理 8.1 CLI 版本管理策略 8.2 企業升版流程 8.3 AI 使用紀錄稽核建議 8.4 使用權限控管 8.5 Session 管理 8.6 效能監控與成本控管 9. 企業導入最佳實踐 9.1 開發團隊使用規範 9.2 AI 輔助開發風險 9.3 原始碼洩漏風險管理 9.4 Prompt 設計標準化 9.5 AI 產出程式碼審核流程 9.6 內部教育訓練建議 10. 風險與限制說明 10.1 Copilot CLI 功能限制 10.2 Premium Request 配額 10.3 安全性考量 10.4 網路依賴風險 10.5 法規與合規性建議 附錄 A：新進成員檢查清單 附錄 B：常用指令速查表 附錄 C：故障排除指南 附錄 D：ACP（Agent Client Protocol） 附錄 E：參考資源 1. GitHub Copilot CLI 架構說明 1.1 Copilot CLI 架構概念 GitHub Copilot CLI 是一個獨立的命令列 AI 程式，讓開發者直接在終端機中與 Copilot 互動。它具備代理（Agent）能力，可以讀取、修改、執行檔案，並與 GitHub.com 互動。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/github-copilot-cli%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"GitHub Copilot CLI 教學手冊 版本：v3.0（2026 年 2 月） 適用對象：資深工程師、DevOps 工程師、技術主管 適用平台：Windows / macOS / Linux 前置條件：具備 Git、Terminal 基礎操作能力；擁有 GitHub Copilot 授權 狀態：GitHub Copilot CLI 目前為 Public Preview（含資料保護），功能可能變更\n目錄 1. GitHub Copilot CLI 架構說明 1.1 Copilot CLI 架構概念 1.2 與 GitHub Copilot IDE 版本的差異 1.3 三種使用模式 1.4 認證流程 1.5 CLI 與 GitHub 雲端服務關係 1.6 CLI 在企業環境中的位置 2. 安裝與環境建置 2.1 系統需求 2.2 Windows 安裝方式 2.3 macOS 安裝方式 2.4 Linux 安裝方式 2.5 使用 npm 安裝（跨平台） 2.6 驗證安裝成功 2.7 代理伺服器（Proxy）環境設定 2.8 防火牆與網路限制處理 3. 基本設定與認證 3.1 首次登入流程 3.2 使用 Personal Access Token 認證 3.3 企業 GitHub 組織授權 3.4 CLI 設定檔說明 3.5 信任目錄管理 3.6 安全設定建議 4. 開發應用方式 4.1 互動模式基本操作 4.2 計畫模式（Plan Mode） 4.3 程式化模式（Programmatic Mode） 4.4 檔案引用與上下文控制 4.5 程式碼產生與重構 4.6 測試程式產生 4.7 Dockerfile 與 CI/CD 產生 4.8 Git 操作與 PR 管理 4.9 工具權限管理 4.10 團隊開發最佳實踐 5. 自訂與擴充功能 5.1 自訂指令（Custom Instructions） 5.2 自訂代理（Custom Agents） 5.3 技能（Skills） 5.4 Hooks 5.5 AI 模型選擇 5.6 Copilot Memory 6. 與 MCP（Model Context Protocol）串接方式 6.1 MCP 架構概念 6.2 內建 GitHub MCP Server 6.3 新增 MCP Server 6.4 自訂 MCP Server 開發 6.5 與企業內部 API 整合 6.6 MCP 安全與權限控管 7. DevOps 整合模式 7.1 與 GitHub Actions 整合 7.2 與 CI/CD Pipeline 整合 7.3 容器化開發流程 7.4 AI 輔助 Code Review 7.5 委派工作至 Copilot Coding Agent 7.6 Commit Message 與 PR 最佳實務 8. 系統維護與治理 8.1 CLI 版本管理策略 8.2 企業升版流程 8.3 AI 使用紀錄稽核建議 8.4 使用權限控管 8.5 Session 管理 8.6 效能監控與成本控管 9. 企業導入最佳實踐 9.1 開發團隊使用規範 9.2 AI 輔助開發風險 9.3 原始碼洩漏風險管理 9.4 Prompt 設計標準化 9.5 AI 產出程式碼審核流程 9.6 內部教育訓練建議 10. 風險與限制說明 10.1 Copilot CLI 功能限制 10.2 Premium Request 配額 10.3 安全性考量 10.4 網路依賴風險 10.5 法規與合規性建議 附錄 A：新進成員檢查清單 附錄 B：常用指令速查表 附錄 C：故障排除指南 附錄 D：ACP（Agent Client Protocol） 附錄 E：參考資源 1. GitHub Copilot CLI 架構說明 1.1 Copilot CLI 架構概念 GitHub Copilot CLI 是一個獨立的命令列 AI 程式，讓開發者直接在終端機中與 Copilot 互動。它具備代理（Agent）能力，可以讀取、修改、執行檔案，並與 GitHub.com 互動。\n","title":"Github Copilot Cli教學手冊"},{"content":"Tailwind CSS 教學手冊（企業級 Web Application 版本） 版本：Tailwind CSS v4.x（2025 最新穩定版）\n適用對象：具備前端基礎的開發工程師、架構師\n最後更新：2025-07-14\n目錄 1. 為什麼選擇 Tailwind CSS 1.1 Utility-First 理念 1.2 與傳統 CSS / SCSS 比較 1.3 與 Bootstrap 比較 1.4 優缺點分析 1.5 適合的專案類型 2. 安裝與專案初始化 2.1 使用 Vite + Vue 3 安裝流程 2.2 使用 Vite + Angular 19 安裝流程 2.3 Tailwind CSS v4 設定方式 2.4 Content 掃描最佳實踐 2.5 專案目錄結構建議 3. Tailwind 核心概念 3.1 Utility Classes 3.2 Responsive Design 3.3 State Variants 3.4 Breakpoints 3.5 Dark Mode 3.6 Arbitrary Values 3.7 Tailwind CSS v4 引擎原理 3.8 Container Queries（容器查詢） 4. 設計系統（Design System）整合 4.1 建立自訂 Theme 4.2 Colors 設計策略 4.3 Spacing 規範 4.4 Typography 設計 4.5 設計 Token 管理 4.6 企業品牌色整合 5. 元件開發最佳實踐 5.1 Button 設計範例 5.2 Card 設計範例 5.3 Form 設計範例 5.4 Layout 設計範例 5.5 可維護性設計 5.6 如何避免 Class 爆炸 6. 大型專案架構設計建議 6.1 與微前端整合方式 6.2 Tailwind 與組件庫策略 6.3 可擴充性設計 6.4 團隊協作規範 6.5 命名規範建議 7. 效能優化 7.1 Tailwind v4 自動 Tree-Shaking 7.2 CSS 體積優化 7.3 CDN vs 本地建置比較 7.4 Production Build 注意事項 7.5 效能監控與量測 8. 與 Vue 3 + TypeScript 整合實戰 8.1 動態 Class 綁定 8.2 Computed Class 管理 8.3 條件式樣式設計 8.4 組件抽象化技巧 8.5 Transition 與 Animation 實戰 8.6 表單驗證樣式整合 9. 常見錯誤與踩雷整理 9.1 Class 過多問題 9.2 重複樣式問題 9.3 無法維護的問題 9.4 與第三方 UI Library 衝突 9.5 Dark Mode 設計錯誤 10. 企業級最佳實踐總結 10.1 開發規範 10.2 Code Review 建議 10.3 專案模板設計建議 10.4 可長期維護策略 附錄 A：Tailwind CSS 企業開發檢查清單（Checklist） 1. 為什麼選擇 Tailwind CSS 1.1 Utility-First 理念 什麼是 Utility-First？ Utility-First 是一種 CSS 設計方法論，核心理念是 「用原子化的 CSS 類別直接在 HTML 中組合樣式，而非撰寫自訂 CSS」。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/tailwind-css%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Tailwind CSS 教學手冊（企業級 Web Application 版本） 版本：Tailwind CSS v4.x（2025 最新穩定版）\n適用對象：具備前端基礎的開發工程師、架構師\n最後更新：2025-07-14\n目錄 1. 為什麼選擇 Tailwind CSS 1.1 Utility-First 理念 1.2 與傳統 CSS / SCSS 比較 1.3 與 Bootstrap 比較 1.4 優缺點分析 1.5 適合的專案類型 2. 安裝與專案初始化 2.1 使用 Vite + Vue 3 安裝流程 2.2 使用 Vite + Angular 19 安裝流程 2.3 Tailwind CSS v4 設定方式 2.4 Content 掃描最佳實踐 2.5 專案目錄結構建議 3. Tailwind 核心概念 3.1 Utility Classes 3.2 Responsive Design 3.3 State Variants 3.4 Breakpoints 3.5 Dark Mode 3.6 Arbitrary Values 3.7 Tailwind CSS v4 引擎原理 3.8 Container Queries（容器查詢） 4. 設計系統（Design System）整合 4.1 建立自訂 Theme 4.2 Colors 設計策略 4.3 Spacing 規範 4.4 Typography 設計 4.5 設計 Token 管理 4.6 企業品牌色整合 5. 元件開發最佳實踐 5.1 Button 設計範例 5.2 Card 設計範例 5.3 Form 設計範例 5.4 Layout 設計範例 5.5 可維護性設計 5.6 如何避免 Class 爆炸 6. 大型專案架構設計建議 6.1 與微前端整合方式 6.2 Tailwind 與組件庫策略 6.3 可擴充性設計 6.4 團隊協作規範 6.5 命名規範建議 7. 效能優化 7.1 Tailwind v4 自動 Tree-Shaking 7.2 CSS 體積優化 7.3 CDN vs 本地建置比較 7.4 Production Build 注意事項 7.5 效能監控與量測 8. 與 Vue 3 + TypeScript 整合實戰 8.1 動態 Class 綁定 8.2 Computed Class 管理 8.3 條件式樣式設計 8.4 組件抽象化技巧 8.5 Transition 與 Animation 實戰 8.6 表單驗證樣式整合 9. 常見錯誤與踩雷整理 9.1 Class 過多問題 9.2 重複樣式問題 9.3 無法維護的問題 9.4 與第三方 UI Library 衝突 9.5 Dark Mode 設計錯誤 10. 企業級最佳實踐總結 10.1 開發規範 10.2 Code Review 建議 10.3 專案模板設計建議 10.4 可長期維護策略 附錄 A：Tailwind CSS 企業開發檢查清單（Checklist） 1. 為什麼選擇 Tailwind CSS 1.1 Utility-First 理念 什麼是 Utility-First？ Utility-First 是一種 CSS 設計方法論，核心理念是 「用原子化的 CSS 類別直接在 HTML 中組合樣式，而非撰寫自訂 CSS」。\n","title":"Tailwind CSS教學手冊"},{"content":"RWD（Responsive Web Design）企業級教學手冊 版本：v1.0（2026 年 2 月）\n適用對象：資深前端工程師、全端工程師、UI/UX 設計師、技術主管\n技術標準：HTML5 · CSS3（2024+）· JavaScript ES2025 · Vue 3.5+ · React 19+ · Angular 19+ · Tailwind CSS 4.x · Bootstrap 5.3+\n目錄 第 1 章 RWD 核心概念 1.1 為什麼需要 RWD？ 1.2 RWD vs Adaptive Design 差異 1.3 Mobile First 設計哲學 1.4 UX 與效能考量 1.5 SEO 對 RWD 的影響 第 2 章 RWD 技術基礎 2.1 Viewport 設定 2.2 Flexible Layout 2.3 CSS Media Queries 2.4 Flexbox 詳解 2.5 CSS Grid 詳解 第 3 章 現代 RWD 架構設計（企業級） 3.1 Layout 分層設計 3.2 Header / Sidebar / Content 響應式設計 3.3 Dashboard 響應式實務 3.4 表單 RWD 設計策略 3.5 表格（Data Table）在手機的處理方式 3.6 Modal / Drawer 在不同裝置設計 第 4 章 與現代框架整合 4.1 Vue 3 + RWD 4.2 Tailwind CSS 響應式設計 4.3 Bootstrap 5 Grid System 4.4 React 19 + RWD 整合 4.5 CSS 新特性整合（2025+） 4.6 Angular 19 + RWD 整合 第 5 章 圖片與媒體最佳化 5.1 Responsive Image（srcset / sizes） 5.2 Picture 元素 5.3 WebP / AVIF 現代圖片格式 5.4 Lazy Loading 5.5 效能優化策略總整理 5.6 響應式影片與嵌入媒體 第 6 章 RWD 效能優化 6.1 減少重排（Reflow） 6.2 減少重繪（Repaint） 6.3 Critical CSS 6.4 避免不必要的 Media Query 6.5 Lighthouse 指標優化 第 7 章 常見錯誤與反模式 7.1 固定寬度設計 7.2 使用 px 當作主要單位 7.3 忽略觸控可點擊範圍 7.4 忽略觸控裝置特性 7.5 表格未優化 7.6 字體過小 7.7 反模式總結 第 8 章 企業級 RWD 開發標準規範 8.1 Breakpoint 標準 8.2 命名規範 8.3 Layout 架構規範 8.4 元件設計原則 8.5 Code Review 檢查清單 8.6 UI/UX 檢核表 第 9 章 測試與驗證 9.1 Chrome DevTools 模擬 9.2 真機測試 9.3 自動化測試建議 9.4 視覺回歸測試（Visual Regression） 第 10 章 範例專案（完整實戰範例） 10.1 完整 Dashboard Layout 範例 10.2 關鍵響應式行為說明 10.3 範例操作說明 附錄 A 企業級 RWD 開發檢查清單（Checklist） A.1 專案設定 A.2 佈局（Layout） A.3 文字與字體 A.4 互動與觸控 A.5 圖片與媒體 A.6 表格 A.7 效能 A.8 無障礙（A11y） A.9 跨瀏覽器 A.10 測試 第 1 章 RWD 核心概念 1.1 為什麼需要 RWD？ 背景 在 2026 年的今天，全球行動裝置（手機 + 平板）流量佔比已超過 65%，企業面對的使用者橫跨多種裝置：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/rwdresponsive-web-design%E4%BC%81%E6%A5%AD%E7%B4%9A%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"RWD（Responsive Web Design）企業級教學手冊 版本：v1.0（2026 年 2 月）\n適用對象：資深前端工程師、全端工程師、UI/UX 設計師、技術主管\n技術標準：HTML5 · CSS3（2024+）· JavaScript ES2025 · Vue 3.5+ · React 19+ · Angular 19+ · Tailwind CSS 4.x · Bootstrap 5.3+\n目錄 第 1 章 RWD 核心概念 1.1 為什麼需要 RWD？ 1.2 RWD vs Adaptive Design 差異 1.3 Mobile First 設計哲學 1.4 UX 與效能考量 1.5 SEO 對 RWD 的影響 第 2 章 RWD 技術基礎 2.1 Viewport 設定 2.2 Flexible Layout 2.3 CSS Media Queries 2.4 Flexbox 詳解 2.5 CSS Grid 詳解 第 3 章 現代 RWD 架構設計（企業級） 3.1 Layout 分層設計 3.2 Header / Sidebar / Content 響應式設計 3.3 Dashboard 響應式實務 3.4 表單 RWD 設計策略 3.5 表格（Data Table）在手機的處理方式 3.6 Modal / Drawer 在不同裝置設計 第 4 章 與現代框架整合 4.1 Vue 3 + RWD 4.2 Tailwind CSS 響應式設計 4.3 Bootstrap 5 Grid System 4.4 React 19 + RWD 整合 4.5 CSS 新特性整合（2025+） 4.6 Angular 19 + RWD 整合 第 5 章 圖片與媒體最佳化 5.1 Responsive Image（srcset / sizes） 5.2 Picture 元素 5.3 WebP / AVIF 現代圖片格式 5.4 Lazy Loading 5.5 效能優化策略總整理 5.6 響應式影片與嵌入媒體 第 6 章 RWD 效能優化 6.1 減少重排（Reflow） 6.2 減少重繪（Repaint） 6.3 Critical CSS 6.4 避免不必要的 Media Query 6.5 Lighthouse 指標優化 第 7 章 常見錯誤與反模式 7.1 固定寬度設計 7.2 使用 px 當作主要單位 7.3 忽略觸控可點擊範圍 7.4 忽略觸控裝置特性 7.5 表格未優化 7.6 字體過小 7.7 反模式總結 第 8 章 企業級 RWD 開發標準規範 8.1 Breakpoint 標準 8.2 命名規範 8.3 Layout 架構規範 8.4 元件設計原則 8.5 Code Review 檢查清單 8.6 UI/UX 檢核表 第 9 章 測試與驗證 9.1 Chrome DevTools 模擬 9.2 真機測試 9.3 自動化測試建議 9.4 視覺回歸測試（Visual Regression） 第 10 章 範例專案（完整實戰範例） 10.1 完整 Dashboard Layout 範例 10.2 關鍵響應式行為說明 10.3 範例操作說明 附錄 A 企業級 RWD 開發檢查清單（Checklist） A.1 專案設定 A.2 佈局（Layout） A.3 文字與字體 A.4 互動與觸控 A.5 圖片與媒體 A.6 表格 A.7 效能 A.8 無障礙（A11y） A.9 跨瀏覽器 A.10 測試 第 1 章 RWD 核心概念 1.1 為什麼需要 RWD？ 背景 在 2026 年的今天，全球行動裝置（手機 + 平板）流量佔比已超過 65%，企業面對的使用者橫跨多種裝置：\n","title":"RWD（Responsive Web Design）企業級教學手冊"},{"content":"軟體開發平行測試（Parallel Run / Parallel Testing）標準程序與計劃書教學手冊 版本：1.1\n最後更新：2026-02-13\n適用對象：專案經理、系統架構師、開發工程師、測試工程師、品質保證人員\n文件等級：內部標準作業文件\n目錄 第一章　平行測試概論 1.1 什麼是平行測試 1.2 與其他測試類型的差異 1.3 適用場景 1.4 平行測試的目標 1.5 平行測試成功的關鍵因素 第二章　平行測試標準作業流程（SOP） 2.1 流程總覽 2.2 各階段詳細說明 2.3 RACI 責任矩陣 第三章　平行測試計劃書範本 3.1 專案基本資訊 3.2 測試範圍 3.3 測試策略 3.4 測試資料設計 3.5 差異判定標準 3.6 風險評估 3.7 成功標準（Exit Criteria） 3.8 溝通計畫 第四章　差異比對設計 4.1 比對策略總覽 4.2 數值容差與精度處理 4.3 SQL 比對範例 4.4 批次比對邏輯範例 4.5 API 回傳比對範例 第五章　自動化平行測試設計 5.1 自動化架構 5.2 CI/CD 整合 5.3 測試報表與差異分類 第六章　金融系統平行測試實務案例 6.1 測試週期規劃 6.2 批次日結流程比對 6.3 差異處理流程 6.4 高風險交易監控 6.5 上線決策會議 第七章　風險管理與內控設計 7.1 分權機制 7.2 雙人覆核（Four-Eyes Principle） 7.3 日誌保存 7.4 稽核需求 7.5 法遵要求 第八章　常見錯誤與失敗案例分析 8.1 常見錯誤總覽 8.2 失敗案例分析 8.3 預防機制 第九章　標準表單範本 9.1 差異記錄表 9.2 風險評估表 9.3 上線核准單 9.4 測試每日報表 9.5 問題追蹤清單 9.6 回滾計畫範本 第十章　企業級最佳實踐 10.1 核心最佳實踐 10.2 組織級最佳實踐 10.3 技術最佳實踐 附錄　檢查清單（Checklist） A. 平行測試啟動前檢查清單 B. 每日執行檢查清單 C. 結案前檢查清單 D. 上線前檢查清單 E. 上線後監控檢查清單 重點摘要 第一章　平行測試概論 學習目標 理解平行測試的定義、目的與價值 區分平行測試與其他測試階段的差異 掌握適用場景與成功關鍵因素 1.1 什麼是平行測試 平行測試（Parallel Run / Parallel Testing） 是指在系統轉換、升級或重寫過程中，同時運行新舊兩套系統，以相同的輸入資料執行相同的業務流程，再將兩套系統的產出進行逐項比對，以驗證新系統的正確性與一致性。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC%E5%B9%B3%E8%A1%8C%E6%B8%AC%E8%A9%A6parallel-runparallel-testing%E6%A8%99%E6%BA%96%E7%A8%8B%E5%BA%8F%E8%88%87%E8%A8%88%E5%8A%83%E6%9B%B8%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"軟體開發平行測試（Parallel Run / Parallel Testing）標準程序與計劃書教學手冊 版本：1.1\n最後更新：2026-02-13\n適用對象：專案經理、系統架構師、開發工程師、測試工程師、品質保證人員\n文件等級：內部標準作業文件\n目錄 第一章　平行測試概論 1.1 什麼是平行測試 1.2 與其他測試類型的差異 1.3 適用場景 1.4 平行測試的目標 1.5 平行測試成功的關鍵因素 第二章　平行測試標準作業流程（SOP） 2.1 流程總覽 2.2 各階段詳細說明 2.3 RACI 責任矩陣 第三章　平行測試計劃書範本 3.1 專案基本資訊 3.2 測試範圍 3.3 測試策略 3.4 測試資料設計 3.5 差異判定標準 3.6 風險評估 3.7 成功標準（Exit Criteria） 3.8 溝通計畫 第四章　差異比對設計 4.1 比對策略總覽 4.2 數值容差與精度處理 4.3 SQL 比對範例 4.4 批次比對邏輯範例 4.5 API 回傳比對範例 第五章　自動化平行測試設計 5.1 自動化架構 5.2 CI/CD 整合 5.3 測試報表與差異分類 第六章　金融系統平行測試實務案例 6.1 測試週期規劃 6.2 批次日結流程比對 6.3 差異處理流程 6.4 高風險交易監控 6.5 上線決策會議 第七章　風險管理與內控設計 7.1 分權機制 7.2 雙人覆核（Four-Eyes Principle） 7.3 日誌保存 7.4 稽核需求 7.5 法遵要求 第八章　常見錯誤與失敗案例分析 8.1 常見錯誤總覽 8.2 失敗案例分析 8.3 預防機制 第九章　標準表單範本 9.1 差異記錄表 9.2 風險評估表 9.3 上線核准單 9.4 測試每日報表 9.5 問題追蹤清單 9.6 回滾計畫範本 第十章　企業級最佳實踐 10.1 核心最佳實踐 10.2 組織級最佳實踐 10.3 技術最佳實踐 附錄　檢查清單（Checklist） A. 平行測試啟動前檢查清單 B. 每日執行檢查清單 C. 結案前檢查清單 D. 上線前檢查清單 E. 上線後監控檢查清單 重點摘要 第一章　平行測試概論 學習目標 理解平行測試的定義、目的與價值 區分平行測試與其他測試階段的差異 掌握適用場景與成功關鍵因素 1.1 什麼是平行測試 平行測試（Parallel Run / Parallel Testing） 是指在系統轉換、升級或重寫過程中，同時運行新舊兩套系統，以相同的輸入資料執行相同的業務流程，再將兩套系統的產出進行逐項比對，以驗證新系統的正確性與一致性。\n","title":"軟體開發平行測試（Parallel Run／Parallel Testing）標準程序與計劃書教學手冊"},{"content":"軟體開發標準程序（Software Development Standard Process）教學手冊 版本：1.1\n最後更新：2026 年 5 月\n適用對象：軟體開發團隊全體成員\n文件性質：內部技術規範與教育訓練教材\n📋 目錄 第一章：前言與目的 1.1 為什麼需要軟體開發標準程序 1.2 對組織與工程師的價值 1.3 本手冊適用範圍 第二章：軟體開發生命週期（SDLC）總覽 2.1 SDLC 各階段說明 2.2 與實務專案的關係 2.3 敏捷與瀑布的選擇 第三章：需求管理（Requirements Engineering） 3.1 需求來源與分類 3.2 功能性與非功能性需求 3.3 需求文件標準 3.4 PRD、SDD、TSD 三大文件體系 3.5 需求異動管理流程 第四章：系統分析與設計 4.1 系統架構設計原則 4.2 邏輯架構與實體架構 4.3 API 設計規範 4.4 資料庫設計與資料治理 4.5 非功能性設計 第五章：開發實作規範 5.1 程式碼風格與命名規範 5.2 架構分層原則 5.3 重用性與模組化 5.4 Secure Coding 基本原則 第六章：測試策略與品質保證 6.1 測試類型與層級 6.2 測試責任分工 6.3 測試資料管理 6.4 缺陷（Bug）管理流程 第七章：版本控制與組態管理 7.1 Git 分支策略 7.2 版號管理原則 7.3 設定檔與環境管理 第八章：CI/CD 與部署流程 8.1 自動化建置流程 8.2 部署策略 8.3 回滾與風險控管 第九章：資安與 SSDLC 9.1 安全需求納入時機 9.2 程式碼掃描與弱點管理 9.3 權限、稽核與日誌 第十章：上線、維運與監控 10.1 上線檢核清單 10.2 監控與告警 10.3 問題處理與 RCA 第十一章：文件化與知識交接 11.1 必備文件清單 11.2 文件維護責任 第十二章：持續改善與流程治理 12.1 專案回顧（Post-mortem） 12.2 指標與成熟度模型 12.3 流程優化建議 附錄 A：檢查清單（Checklist） A.1 開發階段檢查清單 A.2 部署階段檢查清單 A.3 Code Review 檢查清單 A.4 安全性檢查清單 附錄 B：文件範本索引 附錄 C：術語對照表 第一章：前言與目的 1.1 為什麼需要軟體開發標準程序 在企業軟體開發環境中，缺乏標準化流程將導致以下問題：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC%E6%A8%99%E6%BA%96%E7%A8%8B%E5%BA%8Fsoftware-development-standard-process%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"軟體開發標準程序（Software Development Standard Process）教學手冊 版本：1.1\n最後更新：2026 年 5 月\n適用對象：軟體開發團隊全體成員\n文件性質：內部技術規範與教育訓練教材\n📋 目錄 第一章：前言與目的 1.1 為什麼需要軟體開發標準程序 1.2 對組織與工程師的價值 1.3 本手冊適用範圍 第二章：軟體開發生命週期（SDLC）總覽 2.1 SDLC 各階段說明 2.2 與實務專案的關係 2.3 敏捷與瀑布的選擇 第三章：需求管理（Requirements Engineering） 3.1 需求來源與分類 3.2 功能性與非功能性需求 3.3 需求文件標準 3.4 PRD、SDD、TSD 三大文件體系 3.5 需求異動管理流程 第四章：系統分析與設計 4.1 系統架構設計原則 4.2 邏輯架構與實體架構 4.3 API 設計規範 4.4 資料庫設計與資料治理 4.5 非功能性設計 第五章：開發實作規範 5.1 程式碼風格與命名規範 5.2 架構分層原則 5.3 重用性與模組化 5.4 Secure Coding 基本原則 第六章：測試策略與品質保證 6.1 測試類型與層級 6.2 測試責任分工 6.3 測試資料管理 6.4 缺陷（Bug）管理流程 第七章：版本控制與組態管理 7.1 Git 分支策略 7.2 版號管理原則 7.3 設定檔與環境管理 第八章：CI/CD 與部署流程 8.1 自動化建置流程 8.2 部署策略 8.3 回滾與風險控管 第九章：資安與 SSDLC 9.1 安全需求納入時機 9.2 程式碼掃描與弱點管理 9.3 權限、稽核與日誌 第十章：上線、維運與監控 10.1 上線檢核清單 10.2 監控與告警 10.3 問題處理與 RCA 第十一章：文件化與知識交接 11.1 必備文件清單 11.2 文件維護責任 第十二章：持續改善與流程治理 12.1 專案回顧（Post-mortem） 12.2 指標與成熟度模型 12.3 流程優化建議 附錄 A：檢查清單（Checklist） A.1 開發階段檢查清單 A.2 部署階段檢查清單 A.3 Code Review 檢查清單 A.4 安全性檢查清單 附錄 B：文件範本索引 附錄 C：術語對照表 第一章：前言與目的 1.1 為什麼需要軟體開發標準程序 在企業軟體開發環境中，缺乏標準化流程將導致以下問題：\n","title":"軟體開發標準程序（Software Development Standard Process）教學手冊"},{"content":"Node.js 生態系教學手冊 版本：2026.06\n適用對象：具備基礎程式能力，準備參與 Web Application 或 Backend API 專案開發的工程師\n定位：實務導向、架構導向、企業導向的內部技術文件\nNode.js 版本基準：v26.1.0 LTS\n最後更新：2026 年 6 月\n目錄 第 1 章：Node.js 簡介 1.1 Node.js 是什麼 1.2 Runtime 架構與 V8 Engine 1.3 Event Loop 運作機制 1.4 Non-blocking I/O 模型 1.5 Node.js 適用場景與不適用場景 1.6 Node.js LTS 與 Current 版本策略 第 2 章：Node.js 生態系 2.1 npm 2.2 yarn 2.3 pnpm 2.4 npx 與 corepack 2.5 package.json 完整解析 2.6 package-lock.json 與依賴鎖定 2.7 Semantic Versioning（語意化版本） 第 3 章：Node.js 安裝與環境建立 3.1 Windows 環境安裝 3.2 Linux 環境安裝 3.3 macOS 環境安裝 3.4 nvm — Node Version Manager 3.5 fnm — Fast Node Manager 3.6 Volta — 可靠的 JavaScript 工具管理器 3.7 企業環境設定與內部 Registry 第 4 章：TypeScript 開發平台 4.1 為什麼企業專案必須使用 TypeScript 4.2 tsconfig.json 設計原則 4.3 ESM 與 CommonJS 互操作性 4.4 ts-node 與 tsx 開發工具 4.5 SWC 與 esbuild 高速編譯器 4.6 Node.js v26 原生 TypeScript 支援 4.7 型別設計與 Domain Model 最佳實務 第 5 章：Node.js 核心 API 5.1 fs（檔案系統） 5.2 path（路徑處理） 5.3 os（作業系統資訊） 5.4 process（程序管理） 5.5 buffer（二進位資料處理） 5.6 stream（串流處理） 5.7 crypto（加密與雜湊） 5.8 http / https（HTTP 伺服器與客戶端） 5.9 events（事件發射器） 5.10 timers（計時器） 5.11 worker_threads（工作執行緒） 5.12 cluster（叢集） 5.13 child_process（子程序） 5.14 diagnostics_channel（診斷通道） 5.15 新興 API：SQLite、FFI、Permissions 第 6 章：非同步程式設計 6.1 Callback 模式 6.2 Promise 與 Promise 組合器 6.3 async / await 最佳實務 6.4 Event Loop 深入解析 6.5 Microtask Queue 與 Macrotask Queue 6.6 並行控制與流量管控 第 7 章：Express 教學 7.1 建立 REST API 7.2 Middleware 機制 7.3 Routing 設計 7.4 Error Handling 7.5 JWT 身分驗證 7.6 Request Validation 7.7 File Upload 7.8 Express 效能最佳化 7.9 Express 安全強化 7.10 Express 與 Graceful Shutdown 第 8 章：Fastify 教學 8.1 高效能 API 建構 8.2 Plugin 架構 8.3 Schema Validation 與序列化 8.4 效能比較與調校 8.5 TypeBox Schema 驗證 8.6 Fastify Hooks 生命週期 8.7 Fastify 封裝性與裝飾器 8.8 Fastify Rate Limiting 與安全 8.9 Fastify 錯誤處理 第 9 章：NestJS 教學 9.1 Module 模組設計 9.2 Controller 控制器 9.3 Provider 與 Service 9.4 Dependency Injection 依賴注入 9.5 Guard 守衛 9.6 Interceptor 攔截器 9.7 Pipe 管道 9.8 CQRS 模式 9.9 NestJS 微服務模式 9.10 NestJS 排程任務 第 10 章：API 設計最佳實務 10.1 RESTful API 設計原則 10.2 OpenAPI / Swagger 文件化 10.3 API Versioning 策略 10.4 統一錯誤碼設計 10.5 Idempotency 冪等性設計 10.6 Pagination 分頁設計 10.7 GraphQL 簡介與對比 10.8 WebSocket 即時通訊 API 10.9 API 錯誤碼體系設計 10.10 API 限流與配額設計 第 11 章：資料庫整合 11.1 PostgreSQL 整合 11.2 MySQL 整合 11.3 MongoDB 整合 11.4 Redis 快取整合 11.5 Prisma ORM 11.6 TypeORM 11.7 Transaction、Migration 與連線池 11.8 Prisma 進階查詢模式 11.9 Redis 進階模式 第 12 章：測試 12.1 Node.js 內建 Test Runner（node:test） 12.2 Jest 測試框架 12.3 Vitest 測試框架 12.4 Supertest 整合測試 12.5 Playwright E2E 測試 12.6 Test Pyramid 與測試策略 12.7 Mock / Stub / Spy 使用時機 12.8 Coverage 工具（c8 / istanbul） 12.9 Contract Testing（契約測試） 12.10 測試資料管理 12.11 Snapshot Testing 第 13 章：專案架構設計 13.1 Clean Architecture 應用 13.2 Hexagonal Architecture 應用 13.3 Domain-Driven Design（DDD）實作 13.4 Monorepo 策略（Turborepo / Nx / pnpm workspace） 13.5 微服務架構設計 13.6 Error Handling 架構 13.7 Configuration Management 第 14 章：前端整合 14.1 Vue 整合模式 14.2 React 整合模式 14.3 Next.js 全端框架 14.4 Nuxt.js 全端框架 14.5 Server-Side Rendering（SSR）架構 14.6 BFF（Backend for Frontend）設計模式 14.7 Server-Sent Events（SSE）即時推送 14.8 Micro-Frontend 整合模式 14.9 API 狀態管理（TanStack Query） 第 15 章：Docker 化 15.1 Node.js Dockerfile 撰寫 15.2 Multi-stage Build 15.3 Docker Compose 開發環境 15.4 容器安全最佳實務 15.5 Docker Compose 完整開發環境 15.6 生產環境 Docker 最佳實務 第 16 章：Kubernetes 部署 16.1 Deployment 設定 16.2 Service 與 Ingress 16.3 ConfigMap 與 Secret 16.4 HPA 自動擴縮 16.5 Health Check 與 Readiness Probe 16.6 Helm Chart 管理 16.7 Namespace 與資源隔離策略 第 17 章：CI/CD 17.1 GitHub Actions 完整範例 17.2 GitLab CI 配置 17.3 Jenkins Pipeline 17.4 Build → Test → Security Scan → Docker Build → Deploy 流程 17.5 Semantic Versioning 自動化 17.6 Commit 規範與自動化 第 18 章：Logging 與 Monitoring 18.1 Winston 日誌框架 18.2 Pino 高效能日誌 18.3 OpenTelemetry 可觀測性 18.4 Prometheus 指標收集 18.5 Grafana 視覺化監控 18.6 分散式追蹤（OpenTelemetry） 18.7 ELK Stack 日誌架構 18.8 告警策略設計 第 19 章：Node.js 效能調校 19.1 Event Loop Lag 監控 19.2 Memory Leak 偵測 19.3 Heap Snapshot 分析 19.4 CPU Profile 分析 19.5 Benchmark 工具 19.6 效能最佳化清單 19.7 V8 引擎最佳化技巧 19.8 Worker Threads 平行運算 19.9 Stream 效能最佳化 19.10 JSON 序列化加速 第 20 章：安全性（SSDLC） 20.1 OWASP Top 10 for Node.js 20.2 npm 供應鏈攻擊防護 20.3 依賴掃描與 SAST/DAST 20.4 Secret 管理 20.5 JWT 安全最佳實務 20.6 Helmet、CORS 與 Rate Limiting 20.7 輸入驗證與 Injection 防護 20.8 SSRF 防護 20.9 密碼安全與雜湊 20.10 Content Security Policy（CSP） 20.11 安全 HTTP Headers 完整清單 第 21 章：AI 協作開發 21.1 GitHub Copilot 21.2 Claude Code 21.3 其他 AI 工具整合 21.4 Prompt Engineering for Coding 21.5 AI 輔助 Code Review 21.6 AI 輔助測試產生 21.7 AI 輔助文件產生 21.8 CLAUDE.md 專案規範範例 第 22 章：Node.js 維運 22.1 PM2 程序管理 22.2 Cluster 模式 22.3 部署策略 22.4 Graceful Shutdown 22.5 維運監控 Checklist 22.6 Node.js 生產環境設定 22.7 日誌輪替與管理 22.8 健康檢查與自我修復 第 23 章：企業級最佳實務 23.1 Coding Standard 與 Lint 23.2 Conventional Commits 23.3 Git Flow 與分支策略 23.4 Release 與版本策略 23.5 Code Review 流程 23.6 API 版本管理策略 23.7 Feature Flag 管理 23.8 國際化（i18n） 第 24 章：完整企業級範例專案 24.1 專案概覽 24.2 NestJS API 核心 24.3 認證模組 24.4 Prisma Schema 24.5 Redis 快取與 BullMQ 工作佇列 24.6 Docker Compose（完整開發環境） 24.7 GitHub Actions CI/CD 24.8 監控與 Logging 整合 24.9 Order Module 完整實作 24.10 完整測試範例 第 25 章：Appendix 25.1 CLI 常用指令速查表 25.2 Debug 技巧 25.3 VS Code 推薦設定 25.4 推薦套件與學習資源 附錄：檢查清單（Checklist） A. 新專案啟動檢查清單 B. Code Review 檢查清單 C. 上線前檢查清單 D. 日常維運檢查清單 E. 安全性檢查清單 第 1 章：Node.js 簡介 1.1 Node.js 是什麼 定義 Node.js 是一個基於 Chrome V8 引擎 的 JavaScript 執行環境（Runtime），讓 JavaScript 能夠脫離瀏覽器在伺服器端執行。它採用 事件驅動（Event-driven） 與 非阻塞 I/O（Non-blocking I/O） 模型，特別適合建構高併發、I/O 密集型的網路應用程式。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/node.js%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Node.js 生態系教學手冊 版本：2026.06\n適用對象：具備基礎程式能力，準備參與 Web Application 或 Backend API 專案開發的工程師\n定位：實務導向、架構導向、企業導向的內部技術文件\nNode.js 版本基準：v26.1.0 LTS\n最後更新：2026 年 6 月\n目錄 第 1 章：Node.js 簡介 1.1 Node.js 是什麼 1.2 Runtime 架構與 V8 Engine 1.3 Event Loop 運作機制 1.4 Non-blocking I/O 模型 1.5 Node.js 適用場景與不適用場景 1.6 Node.js LTS 與 Current 版本策略 第 2 章：Node.js 生態系 2.1 npm 2.2 yarn 2.3 pnpm 2.4 npx 與 corepack 2.5 package.json 完整解析 2.6 package-lock.json 與依賴鎖定 2.7 Semantic Versioning（語意化版本） 第 3 章：Node.js 安裝與環境建立 3.1 Windows 環境安裝 3.2 Linux 環境安裝 3.3 macOS 環境安裝 3.4 nvm — Node Version Manager 3.5 fnm — Fast Node Manager 3.6 Volta — 可靠的 JavaScript 工具管理器 3.7 企業環境設定與內部 Registry 第 4 章：TypeScript 開發平台 4.1 為什麼企業專案必須使用 TypeScript 4.2 tsconfig.json 設計原則 4.3 ESM 與 CommonJS 互操作性 4.4 ts-node 與 tsx 開發工具 4.5 SWC 與 esbuild 高速編譯器 4.6 Node.js v26 原生 TypeScript 支援 4.7 型別設計與 Domain Model 最佳實務 第 5 章：Node.js 核心 API 5.1 fs（檔案系統） 5.2 path（路徑處理） 5.3 os（作業系統資訊） 5.4 process（程序管理） 5.5 buffer（二進位資料處理） 5.6 stream（串流處理） 5.7 crypto（加密與雜湊） 5.8 http / https（HTTP 伺服器與客戶端） 5.9 events（事件發射器） 5.10 timers（計時器） 5.11 worker_threads（工作執行緒） 5.12 cluster（叢集） 5.13 child_process（子程序） 5.14 diagnostics_channel（診斷通道） 5.15 新興 API：SQLite、FFI、Permissions 第 6 章：非同步程式設計 6.1 Callback 模式 6.2 Promise 與 Promise 組合器 6.3 async / await 最佳實務 6.4 Event Loop 深入解析 6.5 Microtask Queue 與 Macrotask Queue 6.6 並行控制與流量管控 第 7 章：Express 教學 7.1 建立 REST API 7.2 Middleware 機制 7.3 Routing 設計 7.4 Error Handling 7.5 JWT 身分驗證 7.6 Request Validation 7.7 File Upload 7.8 Express 效能最佳化 7.9 Express 安全強化 7.10 Express 與 Graceful Shutdown 第 8 章：Fastify 教學 8.1 高效能 API 建構 8.2 Plugin 架構 8.3 Schema Validation 與序列化 8.4 效能比較與調校 8.5 TypeBox Schema 驗證 8.6 Fastify Hooks 生命週期 8.7 Fastify 封裝性與裝飾器 8.8 Fastify Rate Limiting 與安全 8.9 Fastify 錯誤處理 第 9 章：NestJS 教學 9.1 Module 模組設計 9.2 Controller 控制器 9.3 Provider 與 Service 9.4 Dependency Injection 依賴注入 9.5 Guard 守衛 9.6 Interceptor 攔截器 9.7 Pipe 管道 9.8 CQRS 模式 9.9 NestJS 微服務模式 9.10 NestJS 排程任務 第 10 章：API 設計最佳實務 10.1 RESTful API 設計原則 10.2 OpenAPI / Swagger 文件化 10.3 API Versioning 策略 10.4 統一錯誤碼設計 10.5 Idempotency 冪等性設計 10.6 Pagination 分頁設計 10.7 GraphQL 簡介與對比 10.8 WebSocket 即時通訊 API 10.9 API 錯誤碼體系設計 10.10 API 限流與配額設計 第 11 章：資料庫整合 11.1 PostgreSQL 整合 11.2 MySQL 整合 11.3 MongoDB 整合 11.4 Redis 快取整合 11.5 Prisma ORM 11.6 TypeORM 11.7 Transaction、Migration 與連線池 11.8 Prisma 進階查詢模式 11.9 Redis 進階模式 第 12 章：測試 12.1 Node.js 內建 Test Runner（node:test） 12.2 Jest 測試框架 12.3 Vitest 測試框架 12.4 Supertest 整合測試 12.5 Playwright E2E 測試 12.6 Test Pyramid 與測試策略 12.7 Mock / Stub / Spy 使用時機 12.8 Coverage 工具（c8 / istanbul） 12.9 Contract Testing（契約測試） 12.10 測試資料管理 12.11 Snapshot Testing 第 13 章：專案架構設計 13.1 Clean Architecture 應用 13.2 Hexagonal Architecture 應用 13.3 Domain-Driven Design（DDD）實作 13.4 Monorepo 策略（Turborepo / Nx / pnpm workspace） 13.5 微服務架構設計 13.6 Error Handling 架構 13.7 Configuration Management 第 14 章：前端整合 14.1 Vue 整合模式 14.2 React 整合模式 14.3 Next.js 全端框架 14.4 Nuxt.js 全端框架 14.5 Server-Side Rendering（SSR）架構 14.6 BFF（Backend for Frontend）設計模式 14.7 Server-Sent Events（SSE）即時推送 14.8 Micro-Frontend 整合模式 14.9 API 狀態管理（TanStack Query） 第 15 章：Docker 化 15.1 Node.js Dockerfile 撰寫 15.2 Multi-stage Build 15.3 Docker Compose 開發環境 15.4 容器安全最佳實務 15.5 Docker Compose 完整開發環境 15.6 生產環境 Docker 最佳實務 第 16 章：Kubernetes 部署 16.1 Deployment 設定 16.2 Service 與 Ingress 16.3 ConfigMap 與 Secret 16.4 HPA 自動擴縮 16.5 Health Check 與 Readiness Probe 16.6 Helm Chart 管理 16.7 Namespace 與資源隔離策略 第 17 章：CI/CD 17.1 GitHub Actions 完整範例 17.2 GitLab CI 配置 17.3 Jenkins Pipeline 17.4 Build → Test → Security Scan → Docker Build → Deploy 流程 17.5 Semantic Versioning 自動化 17.6 Commit 規範與自動化 第 18 章：Logging 與 Monitoring 18.1 Winston 日誌框架 18.2 Pino 高效能日誌 18.3 OpenTelemetry 可觀測性 18.4 Prometheus 指標收集 18.5 Grafana 視覺化監控 18.6 分散式追蹤（OpenTelemetry） 18.7 ELK Stack 日誌架構 18.8 告警策略設計 第 19 章：Node.js 效能調校 19.1 Event Loop Lag 監控 19.2 Memory Leak 偵測 19.3 Heap Snapshot 分析 19.4 CPU Profile 分析 19.5 Benchmark 工具 19.6 效能最佳化清單 19.7 V8 引擎最佳化技巧 19.8 Worker Threads 平行運算 19.9 Stream 效能最佳化 19.10 JSON 序列化加速 第 20 章：安全性（SSDLC） 20.1 OWASP Top 10 for Node.js 20.2 npm 供應鏈攻擊防護 20.3 依賴掃描與 SAST/DAST 20.4 Secret 管理 20.5 JWT 安全最佳實務 20.6 Helmet、CORS 與 Rate Limiting 20.7 輸入驗證與 Injection 防護 20.8 SSRF 防護 20.9 密碼安全與雜湊 20.10 Content Security Policy（CSP） 20.11 安全 HTTP Headers 完整清單 第 21 章：AI 協作開發 21.1 GitHub Copilot 21.2 Claude Code 21.3 其他 AI 工具整合 21.4 Prompt Engineering for Coding 21.5 AI 輔助 Code Review 21.6 AI 輔助測試產生 21.7 AI 輔助文件產生 21.8 CLAUDE.md 專案規範範例 第 22 章：Node.js 維運 22.1 PM2 程序管理 22.2 Cluster 模式 22.3 部署策略 22.4 Graceful Shutdown 22.5 維運監控 Checklist 22.6 Node.js 生產環境設定 22.7 日誌輪替與管理 22.8 健康檢查與自我修復 第 23 章：企業級最佳實務 23.1 Coding Standard 與 Lint 23.2 Conventional Commits 23.3 Git Flow 與分支策略 23.4 Release 與版本策略 23.5 Code Review 流程 23.6 API 版本管理策略 23.7 Feature Flag 管理 23.8 國際化（i18n） 第 24 章：完整企業級範例專案 24.1 專案概覽 24.2 NestJS API 核心 24.3 認證模組 24.4 Prisma Schema 24.5 Redis 快取與 BullMQ 工作佇列 24.6 Docker Compose（完整開發環境） 24.7 GitHub Actions CI/CD 24.8 監控與 Logging 整合 24.9 Order Module 完整實作 24.10 完整測試範例 第 25 章：Appendix 25.1 CLI 常用指令速查表 25.2 Debug 技巧 25.3 VS Code 推薦設定 25.4 推薦套件與學習資源 附錄：檢查清單（Checklist） A. 新專案啟動檢查清單 B. Code Review 檢查清單 C. 上線前檢查清單 D. 日常維運檢查清單 E. 安全性檢查清單 第 1 章：Node.js 簡介 1.1 Node.js 是什麼 定義 Node.js 是一個基於 Chrome V8 引擎 的 JavaScript 執行環境（Runtime），讓 JavaScript 能夠脫離瀏覽器在伺服器端執行。它採用 事件驅動（Event-driven） 與 非阻塞 I/O（Non-blocking I/O） 模型，特別適合建構高併發、I/O 密集型的網路應用程式。\n","title":"Node.js生態系教學手冊"},{"content":"jQuery 教學手冊 版本：jQuery 4.0+\n適用對象：具備 JavaScript 基礎的工程師\n文件性質：企業內部技術文件\n最後更新：2026 年 2 月\n目錄 第一部分：基礎概念 jQuery 簡介與定位\n1.1 jQuery 的核心理念 1.2 為何在現代系統中仍需要 jQuery 1.3 jQuery 與原生 JavaScript 的差異 1.4 jQuery 4.0 重大變更 環境準備與版本建議\n2.1 jQuery 版本說明 2.2 CDN 安裝方式 2.3 本地安裝方式 2.4 專案目錄結構建議 2.5 與 HTML5 / ES6 的搭配 2.6 瀏覽器相容性 jQuery 核心語法與觀念\n3.1 $() 選擇器原理 3.2 常用選擇器 3.3 Traversing（遍歷） 3.4 Chaining 設計模式 3.5 jQuery Object vs DOM Object 第二部分：核心操作 DOM 操作實戰\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/jquery%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"jQuery 教學手冊 版本：jQuery 4.0+\n適用對象：具備 JavaScript 基礎的工程師\n文件性質：企業內部技術文件\n最後更新：2026 年 2 月\n目錄 第一部分：基礎概念 jQuery 簡介與定位\n1.1 jQuery 的核心理念 1.2 為何在現代系統中仍需要 jQuery 1.3 jQuery 與原生 JavaScript 的差異 1.4 jQuery 4.0 重大變更 環境準備與版本建議\n2.1 jQuery 版本說明 2.2 CDN 安裝方式 2.3 本地安裝方式 2.4 專案目錄結構建議 2.5 與 HTML5 / ES6 的搭配 2.6 瀏覽器相容性 jQuery 核心語法與觀念\n3.1 $() 選擇器原理 3.2 常用選擇器 3.3 Traversing（遍歷） 3.4 Chaining 設計模式 3.5 jQuery Object vs DOM Object 第二部分：核心操作 DOM 操作實戰\n","title":"JQuery教學手冊"},{"content":"C++ 語言教學手冊 版本: 1.0\n最後更新: 2026年2月\n適用對象: 主機系統開發團隊\n技術層級: 基礎至進階\n目錄 前言與學習指引\n1.1 本手冊目的 1.2 學習路徑圖 1.3 主機系統開發的特殊考量 C++ 基礎語法與概念\n2.1 程式結構 2.2 基本資料型別 2.3 變數與常數 2.4 運算子 2.5 控制流程 2.6 函式 2.7 實務案例：設定檔解析器 2.8 注意事項與最佳實踐 物件導向程式設計 (OOP)\n3.1 類別基礎 3.2 繼承 3.3 多型 3.4 抽象類別與介面 3.5 組合優於繼承 3.6 實務案例：訂單處理系統 3.7 注意事項與最佳實踐 記憶體管理\n4.1 記憶體模型概觀 4.2 指標基礎 4.3 智慧指標 4.4 RAII 原則 4.5 記憶體效能優化 4.6 實務案例：連線池 4.7 注意事項與最佳實踐 STL 標準模板庫\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/c++%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"C++ 語言教學手冊 版本: 1.0\n最後更新: 2026年2月\n適用對象: 主機系統開發團隊\n技術層級: 基礎至進階\n目錄 前言與學習指引\n1.1 本手冊目的 1.2 學習路徑圖 1.3 主機系統開發的特殊考量 C++ 基礎語法與概念\n2.1 程式結構 2.2 基本資料型別 2.3 變數與常數 2.4 運算子 2.5 控制流程 2.6 函式 2.7 實務案例：設定檔解析器 2.8 注意事項與最佳實踐 物件導向程式設計 (OOP)\n3.1 類別基礎 3.2 繼承 3.3 多型 3.4 抽象類別與介面 3.5 組合優於繼承 3.6 實務案例：訂單處理系統 3.7 注意事項與最佳實踐 記憶體管理\n4.1 記憶體模型概觀 4.2 指標基礎 4.3 智慧指標 4.4 RAII 原則 4.5 記憶體效能優化 4.6 實務案例：連線池 4.7 注意事項與最佳實踐 STL 標準模板庫\n","title":"C++語言教學手冊"},{"content":"Cobol教學手冊(2) 版本：2.0\n最後更新：2026 年 2 月\n適用對象：具備基礎程式設計經驗的開發人員、需要轉換到主機 COBOL 開發的工程師、團隊新進成員\n📚 目錄 第一章：COBOL 概述 1.1 COBOL 歷史與發展 1.2 COBOL 在現代企業系統中的角色 1.3 COBOL 與其他語言的比較 1.4 主機環境介紹 第二章：開發環境設置 2.1 主機連線與登入 2.2 TSO/ISPF 基本操作 2.3 JCL 基礎 2.4 開發工具介紹 2.5 現代開發環境設置 第三章：COBOL 語法基礎 3.1 程式結構 3.2 資料型別與變數宣告 3.3 PICTURE 子句詳解 3.4 LEVEL 編號系統 第四章：基本程式設計 4.1 資料處理 4.2 條件判斷 4.3 迴圈控制 4.4 字串處理 第五章：檔案處理 5.1 循序檔案（Sequential File） 5.2 索引檔案（INDEXED File / VSAM KSDS） 5.3 相對檔案（Relative File） 5.4 檔案操作 第六章：進階主題 6.1 COPYBOOK 的使用與管理 6.2 副程式呼叫 6.3 資料庫存取 6.4 CICS 交易處理基礎 6.5 錯誤處理與除錯技巧 第七章：最佳實踐 7.1 程式碼撰寫規範 7.2 命名慣例 7.3 註解撰寫標準 7.4 效能優化建議 7.5 維護性考量 第八章：實戰範例 8.1 簡單報表程式 8.2 檔案更新程式 8.3 批次處理程式 8.4 線上交易程式（CICS） 第九章：故障排除 9.1 常見編譯錯誤 9.2 執行時期錯誤 9.3 除錯技巧與工具 附錄 附錄 A：COBOL 保留字清單 附錄 B：常用 JCL 範例 附錄 C：錯誤訊息對照表 附錄 D：學習資源與參考文獻 檢查清單 第一章：COBOL 概述 學習目標 完成本章後，您將能夠：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/cobol%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A2/","summary":"Cobol教學手冊(2) 版本：2.0\n最後更新：2026 年 2 月\n適用對象：具備基礎程式設計經驗的開發人員、需要轉換到主機 COBOL 開發的工程師、團隊新進成員\n📚 目錄 第一章：COBOL 概述 1.1 COBOL 歷史與發展 1.2 COBOL 在現代企業系統中的角色 1.3 COBOL 與其他語言的比較 1.4 主機環境介紹 第二章：開發環境設置 2.1 主機連線與登入 2.2 TSO/ISPF 基本操作 2.3 JCL 基礎 2.4 開發工具介紹 2.5 現代開發環境設置 第三章：COBOL 語法基礎 3.1 程式結構 3.2 資料型別與變數宣告 3.3 PICTURE 子句詳解 3.4 LEVEL 編號系統 第四章：基本程式設計 4.1 資料處理 4.2 條件判斷 4.3 迴圈控制 4.4 字串處理 第五章：檔案處理 5.1 循序檔案（Sequential File） 5.2 索引檔案（INDEXED File / VSAM KSDS） 5.3 相對檔案（Relative File） 5.4 檔案操作 第六章：進階主題 6.1 COPYBOOK 的使用與管理 6.2 副程式呼叫 6.3 資料庫存取 6.4 CICS 交易處理基礎 6.5 錯誤處理與除錯技巧 第七章：最佳實踐 7.1 程式碼撰寫規範 7.2 命名慣例 7.3 註解撰寫標準 7.4 效能優化建議 7.5 維護性考量 第八章：實戰範例 8.1 簡單報表程式 8.2 檔案更新程式 8.3 批次處理程式 8.4 線上交易程式（CICS） 第九章：故障排除 9.1 常見編譯錯誤 9.2 執行時期錯誤 9.3 除錯技巧與工具 附錄 附錄 A：COBOL 保留字清單 附錄 B：常用 JCL 範例 附錄 C：錯誤訊息對照表 附錄 D：學習資源與參考文獻 檢查清單 第一章：COBOL 概述 學習目標 完成本章後，您將能夠：\n","title":"Cobol教學手冊(2)"},{"content":"C 語言教學手冊 版本：1.0\n最後更新：2026 年 2 月\n適用對象：具備基礎程式設計概念，需進行系統層級開發的工程師\n目錄 第一章：C 語言基礎 1.1 C 語言概述與開發環境 1.2 資料型別與變數 1.3 運算子與表達式 1.4 控制流程 1.5 函數定義與呼叫 第二章：記憶體管理 2.1 指標基礎與進階應用 2.2 動態記憶體配置 2.3 記憶體洩漏預防 2.4 常見陷阱與最佳實踐 第三章：資料結構 3.1 陣列與字串處理 3.2 結構體與聯合 3.3 鏈結串列 3.4 堆疊與佇列實作 第四章：系統程式設計 4.1 檔案 I/O 操作 4.2 錯誤處理機制 4.3 多檔案專案組織 4.4 Makefile 使用 第五章：進階主題 5.1 函數指標 5.2 前置處理器與巨集 5.3 位元操作 5.4 多執行緒基礎 第六章：開發規範與最佳實踐 6.1 命名規範 6.2 程式碼風格指南 6.3 除錯技巧 6.4 效能優化建議 附錄：檢查清單 第一章：C 語言基礎 1.1 C 語言概述與開發環境 1.1.1 為什麼選擇 C 語言 C 語言自 1972 年由 Dennis Ritchie 在貝爾實驗室開發以來，至今仍是系統程式設計的首選語言：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/c%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"C 語言教學手冊 版本：1.0\n最後更新：2026 年 2 月\n適用對象：具備基礎程式設計概念，需進行系統層級開發的工程師\n目錄 第一章：C 語言基礎 1.1 C 語言概述與開發環境 1.2 資料型別與變數 1.3 運算子與表達式 1.4 控制流程 1.5 函數定義與呼叫 第二章：記憶體管理 2.1 指標基礎與進階應用 2.2 動態記憶體配置 2.3 記憶體洩漏預防 2.4 常見陷阱與最佳實踐 第三章：資料結構 3.1 陣列與字串處理 3.2 結構體與聯合 3.3 鏈結串列 3.4 堆疊與佇列實作 第四章：系統程式設計 4.1 檔案 I/O 操作 4.2 錯誤處理機制 4.3 多檔案專案組織 4.4 Makefile 使用 第五章：進階主題 5.1 函數指標 5.2 前置處理器與巨集 5.3 位元操作 5.4 多執行緒基礎 第六章：開發規範與最佳實踐 6.1 命名規範 6.2 程式碼風格指南 6.3 除錯技巧 6.4 效能優化建議 附錄：檢查清單 第一章：C 語言基礎 1.1 C 語言概述與開發環境 1.1.1 為什麼選擇 C 語言 C 語言自 1972 年由 Dennis Ritchie 在貝爾實驗室開發以來，至今仍是系統程式設計的首選語言：\n","title":"C語言教學手冊"},{"content":"COBOL 教學手冊 版本：1.0\n最後更新：2026 年 2 月\n適用對象：新進工程師、有現代語言背景但未接觸主機系統的工程師\n定位：企業內部實務教學手冊\n目錄 第一章：COBOL 與主機系統概覽 1.1 為什麼 COBOL 至今仍被大量使用 1.2 COBOL 在大型主機系統中的角色 1.3 Batch 系統 vs Online 系統（CICS） 1.4 COBOL 與資料庫（DB2）/ 檔案系統的關係 第二章：COBOL 程式基本結構 2.1 COBOL Program Structure 總覽 2.2 IDENTIFICATION DIVISION 2.3 ENVIRONMENT DIVISION 2.4 DATA DIVISION 2.5 PROCEDURE DIVISION 2.6 基本程式範例（可編譯） 第三章：資料型態與資料結構 3.1 PIC 語法完整說明 3.2 數值型、文字型、符號位（SIGN） 3.3 REDEFINES 與 OCCURS 3.4 Working-Storage vs Linkage Section 3.5 常見錯誤與陷阱 第三章小結 第四章：檔案處理（主機實務重點） 4.1 Sequential File 基本操作 4.2 READ / WRITE / OPEN / CLOSE 4.3 EOF 控制寫法 4.4 檔案 Layout（Record Layout）設計原則 4.5 實務範例（Batch 檔案讀寫） 第五章：批次程式（Batch Job）設計 5.1 Batch 程式生命週期 5.2 Return Code（RC）設計原則 5.3 程式錯誤處理與異常控制 5.4 批次程式撰寫範例 5.5 可維運的 Batch 設計 Best Practice 第六章：與資料庫（DB2）互動 6.1 Embedded SQL 基本概念 6.2 SELECT / INSERT / UPDATE / DELETE 範例 6.3 SQLCODE / SQLSTATE 處理方式 6.4 資料一致性的觀念（Commit / Rollback） 第七章：COBOL 程式設計規範 7.1 命名規則（Program / Variable / Paragraph） 7.2 排版與可讀性原則 7.3 註解撰寫建議 7.4 避免「維護地獄」的寫法 7.5 常見 Anti-pattern 第八章：舊系統維護與現代化觀點 8.1 如何「讀懂」舊 COBOL 程式 8.2 如何安全修改老程式 8.3 與現代系統整合概念 8.4 COBOL 在未來系統中的定位 第九章：新手常見問題（FAQ） Q1：為什麼 COBOL 看起來這麼冗長？ Q2：為什麼不把 COBOL 改成 Java？ Q3：初學者最容易踩的雷？ Q4：如何有效學習與除錯 COBOL？ Q5：主機環境和 PC 開發有什麼不同？ Q6：COBOL 還有未來嗎？ 附錄 A：COBOL 開發檢查清單（Checklist） 程式開發前檢查 程式撰寫檢查 檔案處理檢查 資料庫處理檢查 錯誤處理檢查 測試前檢查 上線前檢查 附錄 B：常用 COBOL 關鍵字速查表 資料定義關鍵字 流程控制關鍵字 資料操作關鍵字 檔案操作關鍵字 附錄 C：SQLCODE 常見錯誤碼對照表 成功與警告代碼 常見錯誤代碼 錯誤處理範例 結語 第一章：COBOL 與主機系統概覽 1.1 為什麼 COBOL 至今仍被大量使用 COBOL 的歷史地位 COBOL（COmmon Business-Oriented Language）誕生於 1959 年，是專為商業應用設計的程式語言。至今已超過 65 年歷史，但仍在全球金融、保險、政府機構中扮演核心角色。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/cobol%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"COBOL 教學手冊 版本：1.0\n最後更新：2026 年 2 月\n適用對象：新進工程師、有現代語言背景但未接觸主機系統的工程師\n定位：企業內部實務教學手冊\n目錄 第一章：COBOL 與主機系統概覽 1.1 為什麼 COBOL 至今仍被大量使用 1.2 COBOL 在大型主機系統中的角色 1.3 Batch 系統 vs Online 系統（CICS） 1.4 COBOL 與資料庫（DB2）/ 檔案系統的關係 第二章：COBOL 程式基本結構 2.1 COBOL Program Structure 總覽 2.2 IDENTIFICATION DIVISION 2.3 ENVIRONMENT DIVISION 2.4 DATA DIVISION 2.5 PROCEDURE DIVISION 2.6 基本程式範例（可編譯） 第三章：資料型態與資料結構 3.1 PIC 語法完整說明 3.2 數值型、文字型、符號位（SIGN） 3.3 REDEFINES 與 OCCURS 3.4 Working-Storage vs Linkage Section 3.5 常見錯誤與陷阱 第三章小結 第四章：檔案處理（主機實務重點） 4.1 Sequential File 基本操作 4.2 READ / WRITE / OPEN / CLOSE 4.3 EOF 控制寫法 4.4 檔案 Layout（Record Layout）設計原則 4.5 實務範例（Batch 檔案讀寫） 第五章：批次程式（Batch Job）設計 5.1 Batch 程式生命週期 5.2 Return Code（RC）設計原則 5.3 程式錯誤處理與異常控制 5.4 批次程式撰寫範例 5.5 可維運的 Batch 設計 Best Practice 第六章：與資料庫（DB2）互動 6.1 Embedded SQL 基本概念 6.2 SELECT / INSERT / UPDATE / DELETE 範例 6.3 SQLCODE / SQLSTATE 處理方式 6.4 資料一致性的觀念（Commit / Rollback） 第七章：COBOL 程式設計規範 7.1 命名規則（Program / Variable / Paragraph） 7.2 排版與可讀性原則 7.3 註解撰寫建議 7.4 避免「維護地獄」的寫法 7.5 常見 Anti-pattern 第八章：舊系統維護與現代化觀點 8.1 如何「讀懂」舊 COBOL 程式 8.2 如何安全修改老程式 8.3 與現代系統整合概念 8.4 COBOL 在未來系統中的定位 第九章：新手常見問題（FAQ） Q1：為什麼 COBOL 看起來這麼冗長？ Q2：為什麼不把 COBOL 改成 Java？ Q3：初學者最容易踩的雷？ Q4：如何有效學習與除錯 COBOL？ Q5：主機環境和 PC 開發有什麼不同？ Q6：COBOL 還有未來嗎？ 附錄 A：COBOL 開發檢查清單（Checklist） 程式開發前檢查 程式撰寫檢查 檔案處理檢查 資料庫處理檢查 錯誤處理檢查 測試前檢查 上線前檢查 附錄 B：常用 COBOL 關鍵字速查表 資料定義關鍵字 流程控制關鍵字 資料操作關鍵字 檔案操作關鍵字 附錄 C：SQLCODE 常見錯誤碼對照表 成功與警告代碼 常見錯誤代碼 錯誤處理範例 結語 第一章：COBOL 與主機系統概覽 1.1 為什麼 COBOL 至今仍被大量使用 COBOL 的歷史地位 COBOL（COmmon Business-Oriented Language）誕生於 1959 年，是專為商業應用設計的程式語言。至今已超過 65 年歷史，但仍在全球金融、保險、政府機構中扮演核心角色。\n","title":"Cobol教學手冊"},{"content":"系統資料轉置教學指引 版本：1.0\n更新日期：2026-02-02\n適用對象：系統分析師、資料工程師、後端開發人員\n文件性質：內部教育訓練與專案執行標準參考文件\n目錄 主要章節 章節 內容概述 第 1 章 資料轉置整體概念與常見失敗原因 第 2 章 舊系統分析（As-Is Analysis） 第 3 章 新系統設計（To-Be Design） 第 4 章 資料轉置策略與架構設計 第 5 章 資料轉置流程設計（ETL Flow） 第 6 章 資料驗證與比對機制 第 7 章 工具與技術選型建議 第 8 章 測試策略與上線前檢核 第 9 章 實務經驗與最佳實踐 附錄 A 資料轉置專案檢查清單 附錄 B 常用 SQL 範本 附錄 C 名詞解釋 詳細目錄 第 1 章：資料轉置整體概念與常見失敗原因 1.1 Data Migration vs Data Transformation 差異 1.2 為何資料轉置是高風險專案 1.3 常見失敗原因與風險分析 第 2 章：舊系統分析（As-Is Analysis） 2.1 資料來源盤點 2.2 資料結構分析 2.3 Key 與邏輯關聯分析 2.4 資料品質檢測 第 3 章：新系統設計（To-Be Design） 3.1 新系統資料模型設計原則 3.2 舊欄位到新欄位 Mapping 規則 3.3 Code / Enum / Reference Data 對應策略 3.4 歷史資料保留與否的決策考量 第 4 章：資料轉置策略與架構設計 4.1 一次性轉置 vs 分批轉置 4.2 Online vs Batch 4.3 Big Bang vs Parallel Run 4.4 Rollback 與 Re-run 設計 第 5 章：資料轉置流程設計（ETL Flow） 5.1 Extract（資料抽取） 5.2 Transform（資料轉換） 5.3 Load（資料載入） 5.4 Staging Table 設計 5.5 Error Handling 與 Retry 機制 第 6 章：資料驗證與比對機制 6.1 筆數驗證（Record Count） 6.2 金額 / 數值驗證（Sum / Balance Check） 6.3 Key-based 資料比對 6.4 抽樣驗證（Sampling） 6.5 自動化驗證報表設計 第 7 章：工具與技術選型建議 7.1 SQL / Stored Procedure 7.2 ETL 工具 7.3 程式語言選擇 7.4 檔案處理工具 7.5 驗證與測試輔助工具 第 8 章：測試策略與上線前檢核 8.1 Unit Test（轉換邏輯） 8.2 Integration Test（流程驗證） 8.3 UAT 驗證模式 8.4 上線前 Checklist 第 9 章：實務經驗與最佳實踐 9.1 常見踩雷案例 9.2 與業務單位的資料驗證合作方式 9.3 文件化、稽核與可追溯性設計 9.4 金融與核心系統常見合規考量 附錄 A：資料轉置專案檢查清單（Checklist） A.1 專案啟動階段 A.2 分析設計階段 A.3 開發測試階段 A.4 UAT 階段 A.5 上線階段 附錄 B：常用 SQL 範本 B.1 資料品質檢測 B.2 資料比對 B.3 轉置進度追蹤 附錄 C：名詞解釋 第 1 章：資料轉置整體概念與常見失敗原因 1.1 Data Migration vs Data Transformation 差異 在開始資料轉置專案前，必須先釐清兩個核心概念的差異：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%B3%BB%E7%B5%B1%E8%B3%87%E6%96%99%E8%BD%89%E7%BD%AE%E6%95%99%E5%AD%B8%E6%8C%87%E5%BC%95/","summary":"系統資料轉置教學指引 版本：1.0\n更新日期：2026-02-02\n適用對象：系統分析師、資料工程師、後端開發人員\n文件性質：內部教育訓練與專案執行標準參考文件\n目錄 主要章節 章節 內容概述 第 1 章 資料轉置整體概念與常見失敗原因 第 2 章 舊系統分析（As-Is Analysis） 第 3 章 新系統設計（To-Be Design） 第 4 章 資料轉置策略與架構設計 第 5 章 資料轉置流程設計（ETL Flow） 第 6 章 資料驗證與比對機制 第 7 章 工具與技術選型建議 第 8 章 測試策略與上線前檢核 第 9 章 實務經驗與最佳實踐 附錄 A 資料轉置專案檢查清單 附錄 B 常用 SQL 範本 附錄 C 名詞解釋 詳細目錄 第 1 章：資料轉置整體概念與常見失敗原因 1.1 Data Migration vs Data Transformation 差異 1.2 為何資料轉置是高風險專案 1.3 常見失敗原因與風險分析 第 2 章：舊系統分析（As-Is Analysis） 2.1 資料來源盤點 2.2 資料結構分析 2.3 Key 與邏輯關聯分析 2.4 資料品質檢測 第 3 章：新系統設計（To-Be Design） 3.1 新系統資料模型設計原則 3.2 舊欄位到新欄位 Mapping 規則 3.3 Code / Enum / Reference Data 對應策略 3.4 歷史資料保留與否的決策考量 第 4 章：資料轉置策略與架構設計 4.1 一次性轉置 vs 分批轉置 4.2 Online vs Batch 4.3 Big Bang vs Parallel Run 4.4 Rollback 與 Re-run 設計 第 5 章：資料轉置流程設計（ETL Flow） 5.1 Extract（資料抽取） 5.2 Transform（資料轉換） 5.3 Load（資料載入） 5.4 Staging Table 設計 5.5 Error Handling 與 Retry 機制 第 6 章：資料驗證與比對機制 6.1 筆數驗證（Record Count） 6.2 金額 / 數值驗證（Sum / Balance Check） 6.3 Key-based 資料比對 6.4 抽樣驗證（Sampling） 6.5 自動化驗證報表設計 第 7 章：工具與技術選型建議 7.1 SQL / Stored Procedure 7.2 ETL 工具 7.3 程式語言選擇 7.4 檔案處理工具 7.5 驗證與測試輔助工具 第 8 章：測試策略與上線前檢核 8.1 Unit Test（轉換邏輯） 8.2 Integration Test（流程驗證） 8.3 UAT 驗證模式 8.4 上線前 Checklist 第 9 章：實務經驗與最佳實踐 9.1 常見踩雷案例 9.2 與業務單位的資料驗證合作方式 9.3 文件化、稽核與可追溯性設計 9.4 金融與核心系統常見合規考量 附錄 A：資料轉置專案檢查清單（Checklist） A.1 專案啟動階段 A.2 分析設計階段 A.3 開發測試階段 A.4 UAT 階段 A.5 上線階段 附錄 B：常用 SQL 範本 B.1 資料品質檢測 B.2 資料比對 B.3 轉置進度追蹤 附錄 C：名詞解釋 第 1 章：資料轉置整體概念與常見失敗原因 1.1 Data Migration vs Data Transformation 差異 在開始資料轉置專案前，必須先釐清兩個核心概念的差異：\n","title":"系統資料轉置教學指引"},{"content":"Spring Boot 4.x升版教學 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2026-01-30 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 適用對象：已具備 Spring Boot 2.x / 3.x 實務經驗的工程師\n目標：快速理解 Spring Boot 4.x 變更重點、升版策略與實務調整方式\n目錄 第一章：Spring Boot 4.x 概覽 1.1 升版背景與目的 1.2 Spring Boot 4.x 的設計目標與核心理念 1.3 與 Spring Boot 3.x 的定位差異 1.4 Spring 生態系版本對齊說明 1.5 實務案例與注意事項 第二章：Spring Boot 3.x → 4.x 升版總覽 2.1 升版背景與目的 2.2 官方升版策略說明 2.3 升版風險評估清單（Checklist） 2.4 Breaking Changes 快速一覽 2.5 實務建議與最佳實踐 第三章：Java 與 JVM 版本要求變更 3.1 升版背景與目的 3.2 Spring Boot 4.x 支援的 Java 版本 3.3 為何淘汰舊版 Java 3.4 對企業系統的實際影響 3.5 認證考試常見 Java 升版觀念 3.6 實務案例與注意事項 第四章：Spring Framework 核心變更 4.1 升版背景與目的 4.2 Spring Framework 主要破壞性變更 4.3 Bean Lifecycle 與 Context 初始化差異 4.4 常見相容性問題與解法 4.5 實務建議與最佳實踐 4.6 認證考試常考觀念 第五章：Spring Web / REST API 變更 5.1 升版背景與目的 5.2 Spring MVC / WebFlux 行為調整 5.3 Request / Response 綁定與驗證差異 5.4 錯誤處理（Exception Handling）最佳化建議 5.5 WebFlux 相關變更 5.6 實務案例與注意事項 第六章：Spring Security 重大調整 6.1 升版背景與目的 6.2 Security 預設行為變更 6.3 Authorization / Authentication 架構調整 6.4 舊版設定方式的淘汰與替代方案 6.5 升版時最容易踩雷的 Security 問題 6.6 認證考試常考觀念 6.7 實務案例與注意事項 第七章：Spring Data 與資料存取層 7.1 升版背景與目的 7.2 JPA / JDBC / R2DBC 行為差異 7.3 Repository API 是否有破壞性調整 7.4 交易管理（Transaction）注意事項 7.5 實務案例與注意事項 第八章：設定檔與組態管理變更 8.1 升版背景與目的 8.2 application.yml / properties 行為變化 8.3 Auto Configuration 調整重點 8.4 Cloud Native 設定建議 8.5 實務建議與最佳實踐 第九章：Observability 與 Monitoring 9.1 升版背景與目的 9.2 Logging、Metrics、Tracing 新趨勢 9.3 與 OpenTelemetry / Micrometer 的整合方向 9.4 企業實務監控建議 9.5 實務案例與注意事項 第十章：測試與品質保證 10.1 升版背景與目的 10.2 Spring Boot Test 行為變更 10.3 測試失敗常見原因 10.4 升版時的測試策略 10.5 實務案例與注意事項 第十一章：企業升版實戰流程 11.1 升版前準備事項 11.2 PoC 與試點升級策略 11.3 Rollback 與風險控管 11.4 CI/CD 升版建議流程 11.5 實務案例與注意事項 第十二章：認證考試重點整理 12.1 Spring Boot 4.x 相關考試重點 12.2 常見陷阱題與觀念澄清 12.3 適合考前複習的章節整理 12.4 模擬試題 附錄：升版檢查清單（Checklist） A. 升版前準備 B. 程式碼修改 C. 部署上線 D. 快速參考 版本歷程 參考資源 第一章：Spring Boot 4.x 概覽 1.1 升版背景與目的 Spring Boot 4.x 代表 Spring 生態系的下一個重大里程碑，主要目標包括：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/spring-boot-4.x%E5%8D%87%E7%89%88%E6%95%99%E5%AD%B8/","summary":"Spring Boot 4.x升版教學 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2026-01-30 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 適用對象：已具備 Spring Boot 2.x / 3.x 實務經驗的工程師\n目標：快速理解 Spring Boot 4.x 變更重點、升版策略與實務調整方式\n目錄 第一章：Spring Boot 4.x 概覽 1.1 升版背景與目的 1.2 Spring Boot 4.x 的設計目標與核心理念 1.3 與 Spring Boot 3.x 的定位差異 1.4 Spring 生態系版本對齊說明 1.5 實務案例與注意事項 第二章：Spring Boot 3.x → 4.x 升版總覽 2.1 升版背景與目的 2.2 官方升版策略說明 2.3 升版風險評估清單（Checklist） 2.4 Breaking Changes 快速一覽 2.5 實務建議與最佳實踐 第三章：Java 與 JVM 版本要求變更 3.1 升版背景與目的 3.2 Spring Boot 4.x 支援的 Java 版本 3.3 為何淘汰舊版 Java 3.4 對企業系統的實際影響 3.5 認證考試常見 Java 升版觀念 3.6 實務案例與注意事項 第四章：Spring Framework 核心變更 4.1 升版背景與目的 4.2 Spring Framework 主要破壞性變更 4.3 Bean Lifecycle 與 Context 初始化差異 4.4 常見相容性問題與解法 4.5 實務建議與最佳實踐 4.6 認證考試常考觀念 第五章：Spring Web / REST API 變更 5.1 升版背景與目的 5.2 Spring MVC / WebFlux 行為調整 5.3 Request / Response 綁定與驗證差異 5.4 錯誤處理（Exception Handling）最佳化建議 5.5 WebFlux 相關變更 5.6 實務案例與注意事項 第六章：Spring Security 重大調整 6.1 升版背景與目的 6.2 Security 預設行為變更 6.3 Authorization / Authentication 架構調整 6.4 舊版設定方式的淘汰與替代方案 6.5 升版時最容易踩雷的 Security 問題 6.6 認證考試常考觀念 6.7 實務案例與注意事項 第七章：Spring Data 與資料存取層 7.1 升版背景與目的 7.2 JPA / JDBC / R2DBC 行為差異 7.3 Repository API 是否有破壞性調整 7.4 交易管理（Transaction）注意事項 7.5 實務案例與注意事項 第八章：設定檔與組態管理變更 8.1 升版背景與目的 8.2 application.yml / properties 行為變化 8.3 Auto Configuration 調整重點 8.4 Cloud Native 設定建議 8.5 實務建議與最佳實踐 第九章：Observability 與 Monitoring 9.1 升版背景與目的 9.2 Logging、Metrics、Tracing 新趨勢 9.3 與 OpenTelemetry / Micrometer 的整合方向 9.4 企業實務監控建議 9.5 實務案例與注意事項 第十章：測試與品質保證 10.1 升版背景與目的 10.2 Spring Boot Test 行為變更 10.3 測試失敗常見原因 10.4 升版時的測試策略 10.5 實務案例與注意事項 第十一章：企業升版實戰流程 11.1 升版前準備事項 11.2 PoC 與試點升級策略 11.3 Rollback 與風險控管 11.4 CI/CD 升版建議流程 11.5 實務案例與注意事項 第十二章：認證考試重點整理 12.1 Spring Boot 4.x 相關考試重點 12.2 常見陷阱題與觀念澄清 12.3 適合考前複習的章節整理 12.4 模擬試題 附錄：升版檢查清單（Checklist） A. 升版前準備 B. 程式碼修改 C. 部署上線 D. 快速參考 版本歷程 參考資源 第一章：Spring Boot 4.x 概覽 1.1 升版背景與目的 Spring Boot 4.x 代表 Spring 生態系的下一個重大里程碑，主要目標包括：\n","title":"Spring Boot 4.x升版教學"},{"content":"雲端原生運算生態系教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、系統架構師、SRE / DevOps 工程師、技術主管\n定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月30日\n適用於: 雲端原生運算生態系 Created by: Eric Cheng\n目錄 1. 雲端原生運算概論 1.1 什麼是 Cloud Native 1.2 與傳統架構的差異 1.3 CNCF 的角色與定位 1.4 CNCF Landscape 全景圖說明 1.5 雲端原生帶來的價值與挑戰 2. 雲端原生系統整體架構 2.1 典型雲端原生參考架構 2.2 核心分層說明 2.2.1 基礎設施層（Infrastructure Layer） 2.2.2 容器層（Container Runtime Layer） 2.2.3 編排層（Orchestration Layer） 2.2.4 平台層（Platform Layer） 2.2.5 可觀測性（Observability Layer） 2.2.6 安全層（Security Layer） 2.3 微服務與事件驅動架構 3. CNCF 核心專案分類與說明 3.1 Container \u0026amp; Runtime 3.2 Orchestration \u0026amp; Management 3.3 Networking 3.4 Service Mesh 3.5 API Gateway \u0026amp; Ingress 3.6 Observability 3.7 Logging 3.8 Security 3.9 CI/CD 3.10 Storage 3.11 Messaging \u0026amp; Streaming 4. 系統安裝與基礎環境建置 4.1 雲端原生平台建置方式比較 4.2 Managed Kubernetes 比較 4.3 Self-Managed Kubernetes 安裝（kubeadm） 4.4 必要 Add-ons 安裝建議 4.5 開發、測試、正式環境差異設計 5. 系統設定與組態管理 5.1 Kubernetes Namespace 與 RBAC 設計 5.2 ConfigMap / Secret 使用方式 5.3 Helm 與 Kustomize 的角色 5.4 GitOps 架構（以 Argo CD 為例） 5.5 環境參數與設定管理策略 6. 雲端原生系統使用方式 6.1 應用程式容器化流程 6.2 Deployment / StatefulSet 使用情境 6.3 Service / Ingress / Gateway 設計 6.4 自動擴縮（HPA / VPA） 6.5 Rolling Update 與 Zero Downtime Deployment 7. 系統維運與可觀測性 7.1 Metrics、Logs、Traces 的角色 7.2 Prometheus + Grafana 架構 7.3 OpenTelemetry 導入方式 7.4 告警（Alerting）設計原則 7.5 SRE 常用監控指標（SLI / SLO / SLA） 8. 系統安全與治理 8.1 雲端原生安全風險概覽 8.2 Kubernetes Security Best Practices 8.3 Image Security 與 Supply Chain Security 8.4 Policy as Code（OPA / Kyverno） 8.5 零信任（Zero Trust）在雲端原生的應用 9. 系統升級與版本管理 9.1 Kubernetes 升級策略 9.2 CNCF 元件相容性考量 9.3 滾動升級與回滾機制 9.4 升級風險與因應方式 10. 應用系統如何串接雲端原生平台 10.1 傳統系統（Legacy System）上雲策略 10.2 API-based 系統整合 10.3 Event-driven 架構串接方式 10.4 Database、MQ、外部系統整合模式 10.5 金融/企業系統常見整合案例 11. 企業實務建議與最佳實踐 11.1 雲端原生導入常見地雷 11.2 組織與流程調整建議 11.3 開發、維運、資安協作模式 11.4 技術選型建議 11.5 成熟度模型（Cloud Native Maturity Model） 12. 檢查清單（Checklist） 12.1 叢集建置檢查清單 12.2 應用部署檢查清單 12.3 可觀測性檢查清單 12.4 安全檢查清單 12.5 維運檢查清單 附錄 附錄 A：常用 kubectl 指令速查 附錄 B：參考資源 1. 雲端原生運算概論 1.1 什麼是 Cloud Native Cloud Native（雲端原生） 是一種建構和運行應用程式的方法，充分利用雲端運算模型的優勢。根據 CNCF（Cloud Native Computing Foundation）的定義：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/%E9%9B%B2%E7%AB%AF%E5%8E%9F%E7%94%9F%E9%81%8B%E7%AE%97%E7%94%9F%E6%85%8B%E7%B3%BB%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"雲端原生運算生態系教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、系統架構師、SRE / DevOps 工程師、技術主管\n定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月30日\n適用於: 雲端原生運算生態系 Created by: Eric Cheng\n目錄 1. 雲端原生運算概論 1.1 什麼是 Cloud Native 1.2 與傳統架構的差異 1.3 CNCF 的角色與定位 1.4 CNCF Landscape 全景圖說明 1.5 雲端原生帶來的價值與挑戰 2. 雲端原生系統整體架構 2.1 典型雲端原生參考架構 2.2 核心分層說明 2.2.1 基礎設施層（Infrastructure Layer） 2.2.2 容器層（Container Runtime Layer） 2.2.3 編排層（Orchestration Layer） 2.2.4 平台層（Platform Layer） 2.2.5 可觀測性（Observability Layer） 2.2.6 安全層（Security Layer） 2.3 微服務與事件驅動架構 3. CNCF 核心專案分類與說明 3.1 Container \u0026amp; Runtime 3.2 Orchestration \u0026amp; Management 3.3 Networking 3.4 Service Mesh 3.5 API Gateway \u0026amp; Ingress 3.6 Observability 3.7 Logging 3.8 Security 3.9 CI/CD 3.10 Storage 3.11 Messaging \u0026amp; Streaming 4. 系統安裝與基礎環境建置 4.1 雲端原生平台建置方式比較 4.2 Managed Kubernetes 比較 4.3 Self-Managed Kubernetes 安裝（kubeadm） 4.4 必要 Add-ons 安裝建議 4.5 開發、測試、正式環境差異設計 5. 系統設定與組態管理 5.1 Kubernetes Namespace 與 RBAC 設計 5.2 ConfigMap / Secret 使用方式 5.3 Helm 與 Kustomize 的角色 5.4 GitOps 架構（以 Argo CD 為例） 5.5 環境參數與設定管理策略 6. 雲端原生系統使用方式 6.1 應用程式容器化流程 6.2 Deployment / StatefulSet 使用情境 6.3 Service / Ingress / Gateway 設計 6.4 自動擴縮（HPA / VPA） 6.5 Rolling Update 與 Zero Downtime Deployment 7. 系統維運與可觀測性 7.1 Metrics、Logs、Traces 的角色 7.2 Prometheus + Grafana 架構 7.3 OpenTelemetry 導入方式 7.4 告警（Alerting）設計原則 7.5 SRE 常用監控指標（SLI / SLO / SLA） 8. 系統安全與治理 8.1 雲端原生安全風險概覽 8.2 Kubernetes Security Best Practices 8.3 Image Security 與 Supply Chain Security 8.4 Policy as Code（OPA / Kyverno） 8.5 零信任（Zero Trust）在雲端原生的應用 9. 系統升級與版本管理 9.1 Kubernetes 升級策略 9.2 CNCF 元件相容性考量 9.3 滾動升級與回滾機制 9.4 升級風險與因應方式 10. 應用系統如何串接雲端原生平台 10.1 傳統系統（Legacy System）上雲策略 10.2 API-based 系統整合 10.3 Event-driven 架構串接方式 10.4 Database、MQ、外部系統整合模式 10.5 金融/企業系統常見整合案例 11. 企業實務建議與最佳實踐 11.1 雲端原生導入常見地雷 11.2 組織與流程調整建議 11.3 開發、維運、資安協作模式 11.4 技術選型建議 11.5 成熟度模型（Cloud Native Maturity Model） 12. 檢查清單（Checklist） 12.1 叢集建置檢查清單 12.2 應用部署檢查清單 12.3 可觀測性檢查清單 12.4 安全檢查清單 12.5 維運檢查清單 附錄 附錄 A：常用 kubectl 指令速查 附錄 B：參考資源 1. 雲端原生運算概論 1.1 什麼是 Cloud Native Cloud Native（雲端原生） 是一種建構和運行應用程式的方法，充分利用雲端運算模型的優勢。根據 CNCF（Cloud Native Computing Foundation）的定義：\n","title":"雲端原生運算生態系教學手冊"},{"content":"Kubernetes教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、DevOps / SRE、系統架構師 定位：企業內部標準教材 最後更新: 2026年1月29日\n適用於: 對應 Kubernetes v1.29+ Created by: Eric Cheng\n📚 目錄 第一章：Kubernetes 系統架構 1.1 Kubernetes 核心設計理念 宣告式配置（Declarative Configuration） 控制迴圈（Control Loop） 鬆耦合與可擴展性 1.2 Cluster 架構說明 整體架構圖 Control Plane 元件說明 Worker Node 元件說明 1.3 核心物件概念 Pod Node Namespace Label 與 Selector Annotation 1.4 Kubernetes 與傳統部署差異 第二章：Kubernetes 安裝與環境建置 2.1 常見安裝方式比較 kubeadm 安裝 Managed Kubernetes 比較 本地開發環境（kind） 2.2 基本環境需求 硬體需求 作業系統需求 網路需求 2.3 Cluster 初始化流程 Container Runtime 安裝 2.4 安裝後驗證 第三章：Kubernetes 核心資源設定 3.1 Pod / Deployment / ReplicaSet Pod 生命週期 Deployment 完整範例 3.2 Service 類型說明 Service 類型比較 Service YAML 範例 3.3 Ingress 與 Ingress Controller Ingress 架構 Ingress 設定範例 常用 Ingress Controller 3.4 ConfigMap / Secret ConfigMap 使用方式 Secret 使用方式 3.5 Resource Request / Limit 資源設定說明 CPU 與 Memory 單位 資源設定最佳實踐 3.6 Health Check（Liveness / Readiness / Startup） 三種 Probe 比較 完整 Probe 設定範例 Probe 方式 第四章：Kubernetes 系統使用（實務操作） 4.1 kubectl 常用指令 基本指令速查表 kubectl 輸出格式 4.2 Deployment 發佈流程 發佈流程指令 4.3 滾動更新與回滾 滾動更新策略 回滾操作 藍綠部署（Blue-Green Deployment） 4.4 Scaling（Manual / HPA） 手動擴縮容 HPA（Horizontal Pod Autoscaler） 4.5 Debug 與故障排查 故障排查流程 常見問題診斷 進階除錯技巧 第五章：Kubernetes 維運與管理 5.1 Namespace 與多團隊隔離 Namespace 設計策略 Namespace 建立與管理 5.2 RBAC 權限控管 RBAC 架構 RBAC 設定範例 5.3 日誌與監控策略 日誌收集架構 日誌最佳實踐 應用程式日誌建議 5.4 常見營運風險與因應 憑證管理 5.5 Cluster 容量與資源管理 資源監控指標 容量規劃建議 第六章：Kubernetes 升級策略 6.1 升級原則 版本支援政策 升級順序 6.2 Control Plane 與 Node 升級順序 kubeadm 升級流程 6.3 應用程式升級注意事項 PodDisruptionBudget（PDB） 6.4 升級前檢查清單 第七章：應用系統串接 Kubernetes 7.1 CI/CD 整合流程 GitLab CI 範例 7.2 容器映像管理策略 映像命名規範 映像標籤策略 映像安全掃描 7.3 Helm 基本概念與使用 Helm 架構 Helm 常用指令 values.yaml 範例 7.4 外部系統整合 資料庫連線 Prometheus 整合 第八章：最佳實踐與常見反模式 8.1 建議遵循的設計原則 最佳實踐清單 安全設定範例 8.2 常見錯誤與踩雷經驗 常見反模式 Graceful Shutdown 實作 8.3 企業環境實務建議 金融業特殊考量 NetworkPolicy 範例 附錄 附錄 A：新服務部署檢查清單 附錄 B：日常維運檢查清單 附錄 C：升級前檢查清單 參考資源 第一章：Kubernetes 系統架構 1.1 Kubernetes 核心設計理念 Kubernetes（簡稱 K8s）是由 Google 開源的容器編排平台，其核心設計理念包括：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/kubernetes%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Kubernetes教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、DevOps / SRE、系統架構師 定位：企業內部標準教材 最後更新: 2026年1月29日\n適用於: 對應 Kubernetes v1.29+ Created by: Eric Cheng\n📚 目錄 第一章：Kubernetes 系統架構 1.1 Kubernetes 核心設計理念 宣告式配置（Declarative Configuration） 控制迴圈（Control Loop） 鬆耦合與可擴展性 1.2 Cluster 架構說明 整體架構圖 Control Plane 元件說明 Worker Node 元件說明 1.3 核心物件概念 Pod Node Namespace Label 與 Selector Annotation 1.4 Kubernetes 與傳統部署差異 第二章：Kubernetes 安裝與環境建置 2.1 常見安裝方式比較 kubeadm 安裝 Managed Kubernetes 比較 本地開發環境（kind） 2.2 基本環境需求 硬體需求 作業系統需求 網路需求 2.3 Cluster 初始化流程 Container Runtime 安裝 2.4 安裝後驗證 第三章：Kubernetes 核心資源設定 3.1 Pod / Deployment / ReplicaSet Pod 生命週期 Deployment 完整範例 3.2 Service 類型說明 Service 類型比較 Service YAML 範例 3.3 Ingress 與 Ingress Controller Ingress 架構 Ingress 設定範例 常用 Ingress Controller 3.4 ConfigMap / Secret ConfigMap 使用方式 Secret 使用方式 3.5 Resource Request / Limit 資源設定說明 CPU 與 Memory 單位 資源設定最佳實踐 3.6 Health Check（Liveness / Readiness / Startup） 三種 Probe 比較 完整 Probe 設定範例 Probe 方式 第四章：Kubernetes 系統使用（實務操作） 4.1 kubectl 常用指令 基本指令速查表 kubectl 輸出格式 4.2 Deployment 發佈流程 發佈流程指令 4.3 滾動更新與回滾 滾動更新策略 回滾操作 藍綠部署（Blue-Green Deployment） 4.4 Scaling（Manual / HPA） 手動擴縮容 HPA（Horizontal Pod Autoscaler） 4.5 Debug 與故障排查 故障排查流程 常見問題診斷 進階除錯技巧 第五章：Kubernetes 維運與管理 5.1 Namespace 與多團隊隔離 Namespace 設計策略 Namespace 建立與管理 5.2 RBAC 權限控管 RBAC 架構 RBAC 設定範例 5.3 日誌與監控策略 日誌收集架構 日誌最佳實踐 應用程式日誌建議 5.4 常見營運風險與因應 憑證管理 5.5 Cluster 容量與資源管理 資源監控指標 容量規劃建議 第六章：Kubernetes 升級策略 6.1 升級原則 版本支援政策 升級順序 6.2 Control Plane 與 Node 升級順序 kubeadm 升級流程 6.3 應用程式升級注意事項 PodDisruptionBudget（PDB） 6.4 升級前檢查清單 第七章：應用系統串接 Kubernetes 7.1 CI/CD 整合流程 GitLab CI 範例 7.2 容器映像管理策略 映像命名規範 映像標籤策略 映像安全掃描 7.3 Helm 基本概念與使用 Helm 架構 Helm 常用指令 values.yaml 範例 7.4 外部系統整合 資料庫連線 Prometheus 整合 第八章：最佳實踐與常見反模式 8.1 建議遵循的設計原則 最佳實踐清單 安全設定範例 8.2 常見錯誤與踩雷經驗 常見反模式 Graceful Shutdown 實作 8.3 企業環境實務建議 金融業特殊考量 NetworkPolicy 範例 附錄 附錄 A：新服務部署檢查清單 附錄 B：日常維運檢查清單 附錄 C：升級前檢查清單 參考資源 第一章：Kubernetes 系統架構 1.1 Kubernetes 核心設計理念 Kubernetes（簡稱 K8s）是由 Google 開源的容器編排平台，其核心設計理念包括：\n","title":"Kubernetes教學手冊"},{"content":"Kong API Gateway教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、DevOps 工程師\n定位：企業內部標準教材 文件維護：內部技術團隊 最後更新: 2026年1月29日\n適用於: Kong 3.9.x（2026 年最新穩定版） Created by: Eric Cheng\n目錄 Kong API Gateway 簡介 1.1 Kong 是什麼？解決什麼問題？ 1.2 為什麼需要 API Gateway？ 1.3 Kong 在微服務架構中的角色 1.4 Kong OSS / Enterprise 差異簡介 系統架構設計 2.1 Kong API Gateway 整體架構圖 2.2 核心元件說明 2.3 與後端微服務、LB、Auth Server 的關係 2.4 典型企業架構範例 安裝與部署 3.1 安裝模式說明 3.2 常見部署方式 3.3 安裝後檢查方式 基本設定與核心概念 4.1 Service / Route / Upstream / Target 說明 4.2 Consumer 概念 4.3 Plugin 架構與執行流程 4.4 宣告式設定（Declarative Config） 4.5 Admin API 使用方式概覽 Kong API Gateway 實際使用教學 5.1 建立第一個 API（Service + Route） 5.2 API 路由策略 5.3 Load Balancing 與 Health Check 5.4 完整請求流程範例 常用 Plugins 實務說明 6.1 Rate Limiting（限流） 6.2 Key Authentication 6.3 JWT Authentication 6.4 OAuth 2.0（概念） 6.5 ACL（存取控制清單） 6.6 CORS 6.7 Request / Response Transformer 6.8 Prometheus Plugin 6.9 Logging Plugins 應用系統如何串接 Kong 7.1 後端微服務如何被 Kong 管理 7.2 前端 / App 如何呼叫 Kong API 7.3 與 OAuth / SSO / IAM 系統整合 監控、日誌與可觀測性 8.1 Kong Metrics 說明 8.2 與 Prometheus / Grafana 整合 8.3 Log 收集（ELK / OpenSearch） 8.4 Trace（OpenTelemetry 整合） 系統維護與營運 9.1 Kong 設定管理建議 9.2 Plugin 管理策略 9.3 多環境建議 9.4 效能與容量規劃 9.5 常見營運問題與排查 系統升級與版本管理 10.1 Kong 升級注意事項 10.2 Plugin 相容性風險 10.3 升級前檢查清單 10.4 升級流程（滾動升級） Best Practices 與常見地雷 11.1 API 設計與 Gateway 設計分工 11.2 不建議在 Kong 做的事情 11.3 Plugin 使用過度的風險 11.4 安全性與效能常見錯誤 11.5 設定範例：生產環境最佳實踐 總結與學習路線建議 12.1 適合新手的學習順序 12.2 團隊導入 Kong 的成熟度成長路線 12.3 推薦學習資源 檢查清單（Checklist） 🚀 新服務上線檢查清單 🔧 日常維運檢查清單 📋 升級前檢查清單 🔒 安全性檢查清單 附錄 A. 常用指令速查表 B. 環境變數參考 1. Kong API Gateway 簡介 1.1 Kong 是什麼？解決什麼問題？ Kong 是一個開源、高效能、可擴展的 API Gateway（API 閘道），建構於 Nginx 與 OpenResty（Lua） 之上。它作為 API 的統一入口，處理所有進入系統的 API 請求。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/kong-api-gateway%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Kong API Gateway教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、DevOps 工程師\n定位：企業內部標準教材 文件維護：內部技術團隊 最後更新: 2026年1月29日\n適用於: Kong 3.9.x（2026 年最新穩定版） Created by: Eric Cheng\n目錄 Kong API Gateway 簡介 1.1 Kong 是什麼？解決什麼問題？ 1.2 為什麼需要 API Gateway？ 1.3 Kong 在微服務架構中的角色 1.4 Kong OSS / Enterprise 差異簡介 系統架構設計 2.1 Kong API Gateway 整體架構圖 2.2 核心元件說明 2.3 與後端微服務、LB、Auth Server 的關係 2.4 典型企業架構範例 安裝與部署 3.1 安裝模式說明 3.2 常見部署方式 3.3 安裝後檢查方式 基本設定與核心概念 4.1 Service / Route / Upstream / Target 說明 4.2 Consumer 概念 4.3 Plugin 架構與執行流程 4.4 宣告式設定（Declarative Config） 4.5 Admin API 使用方式概覽 Kong API Gateway 實際使用教學 5.1 建立第一個 API（Service + Route） 5.2 API 路由策略 5.3 Load Balancing 與 Health Check 5.4 完整請求流程範例 常用 Plugins 實務說明 6.1 Rate Limiting（限流） 6.2 Key Authentication 6.3 JWT Authentication 6.4 OAuth 2.0（概念） 6.5 ACL（存取控制清單） 6.6 CORS 6.7 Request / Response Transformer 6.8 Prometheus Plugin 6.9 Logging Plugins 應用系統如何串接 Kong 7.1 後端微服務如何被 Kong 管理 7.2 前端 / App 如何呼叫 Kong API 7.3 與 OAuth / SSO / IAM 系統整合 監控、日誌與可觀測性 8.1 Kong Metrics 說明 8.2 與 Prometheus / Grafana 整合 8.3 Log 收集（ELK / OpenSearch） 8.4 Trace（OpenTelemetry 整合） 系統維護與營運 9.1 Kong 設定管理建議 9.2 Plugin 管理策略 9.3 多環境建議 9.4 效能與容量規劃 9.5 常見營運問題與排查 系統升級與版本管理 10.1 Kong 升級注意事項 10.2 Plugin 相容性風險 10.3 升級前檢查清單 10.4 升級流程（滾動升級） Best Practices 與常見地雷 11.1 API 設計與 Gateway 設計分工 11.2 不建議在 Kong 做的事情 11.3 Plugin 使用過度的風險 11.4 安全性與效能常見錯誤 11.5 設定範例：生產環境最佳實踐 總結與學習路線建議 12.1 適合新手的學習順序 12.2 團隊導入 Kong 的成熟度成長路線 12.3 推薦學習資源 檢查清單（Checklist） 🚀 新服務上線檢查清單 🔧 日常維運檢查清單 📋 升級前檢查清單 🔒 安全性檢查清單 附錄 A. 常用指令速查表 B. 環境變數參考 1. Kong API Gateway 簡介 1.1 Kong 是什麼？解決什麼問題？ Kong 是一個開源、高效能、可擴展的 API Gateway（API 閘道），建構於 Nginx 與 OpenResty（Lua） 之上。它作為 API 的統一入口，處理所有進入系統的 API 請求。\n","title":"Kong API Gateway教學手冊"},{"content":"Keycloak教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、DevOps、資安人員\n定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月29日\n適用於: 適用於 Keycloak 24.x / 25.x（2024-2025 最新版） Created by: Eric Cheng\n目錄 第一章：Keycloak 簡介與核心概念 1.1 Keycloak 是什麼？ 1.2 IAM、SSO、OAuth 2.0、OIDC 關係說明 1.3 Token 類型說明 1.4 核心概念：Realm、Client、User、Role、Group 1.5 Authentication vs Authorization 第二章：系統架構設計 2.1 Keycloak 在企業系統中的角色 2.2 整合架構說明 2.3 Token Flow（Authorization Code Flow） 第三章：Keycloak 安裝與部署 3.1 單機部署（Docker） 3.2 生產環境部署建議 3.3 基本啟動參數與環境變數 3.4 Admin Console 存取方式 第四章：Keycloak 基本設定 4.1 Realm 建立與規劃原則 4.2 Client 類型說明 4.3 Redirect URI 與 Web Origin 設定 4.4 User、Role、Group 設定策略 4.5 Realm Role vs Client Role 使用時機 第五章：應用系統如何串接 Keycloak 5.1 Web 前端串接（OIDC） 5.2 Backend API 驗證 Token 機制 5.3 Spring Boot 整合 5.4 常見錯誤與除錯方式 第六章：系統使用情境說明 6.1 SSO 登入流程實例 6.2 使用者角色異動後的影響 6.3 Token 生命週期與 Refresh 機制 6.4 Logout 流程（Single Logout） 第七章：系統維運與管理 7.1 使用者與權限管理最佳實務 7.2 Audit Log 與事件追蹤 7.3 Keycloak Log 說明 7.4 常見營運問題 第八章：高可用與資安建議 8.1 Keycloak HA 架構概念 8.2 Session 與 Token 設計考量 8.3 HTTPS 與憑證管理 8.4 防止 Token 洩漏的設計原則 8.5 與企業資安政策的搭配方式 第九章：系統升級與版本管理 9.1 升級前檢查事項 9.2 資料庫相容性注意事項 9.3 設定變更風險 9.4 Rollback 建議策略 第十章：最佳實務與設計建議 10.1 Realm / Client 命名規範 10.2 多系統共用 Keycloak 的設計原則 10.3 銀行或大型企業常見踩雷點 10.4 開發、測試、正式環境隔離建議 附錄：檢查清單（Checklist） 初次部署檢查清單 日常維運檢查清單 系統整合檢查清單 常見 Q\u0026amp;A 參考資源 第一章：Keycloak 簡介與核心概念 1.1 Keycloak 是什麼？ Keycloak 是由 Red Hat 開發並維護的開源 身分與存取管理（Identity and Access Management, IAM） 解決方案，目前為 CNCF 孵化專案。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/keycloak%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Keycloak教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、DevOps、資安人員\n定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月29日\n適用於: 適用於 Keycloak 24.x / 25.x（2024-2025 最新版） Created by: Eric Cheng\n目錄 第一章：Keycloak 簡介與核心概念 1.1 Keycloak 是什麼？ 1.2 IAM、SSO、OAuth 2.0、OIDC 關係說明 1.3 Token 類型說明 1.4 核心概念：Realm、Client、User、Role、Group 1.5 Authentication vs Authorization 第二章：系統架構設計 2.1 Keycloak 在企業系統中的角色 2.2 整合架構說明 2.3 Token Flow（Authorization Code Flow） 第三章：Keycloak 安裝與部署 3.1 單機部署（Docker） 3.2 生產環境部署建議 3.3 基本啟動參數與環境變數 3.4 Admin Console 存取方式 第四章：Keycloak 基本設定 4.1 Realm 建立與規劃原則 4.2 Client 類型說明 4.3 Redirect URI 與 Web Origin 設定 4.4 User、Role、Group 設定策略 4.5 Realm Role vs Client Role 使用時機 第五章：應用系統如何串接 Keycloak 5.1 Web 前端串接（OIDC） 5.2 Backend API 驗證 Token 機制 5.3 Spring Boot 整合 5.4 常見錯誤與除錯方式 第六章：系統使用情境說明 6.1 SSO 登入流程實例 6.2 使用者角色異動後的影響 6.3 Token 生命週期與 Refresh 機制 6.4 Logout 流程（Single Logout） 第七章：系統維運與管理 7.1 使用者與權限管理最佳實務 7.2 Audit Log 與事件追蹤 7.3 Keycloak Log 說明 7.4 常見營運問題 第八章：高可用與資安建議 8.1 Keycloak HA 架構概念 8.2 Session 與 Token 設計考量 8.3 HTTPS 與憑證管理 8.4 防止 Token 洩漏的設計原則 8.5 與企業資安政策的搭配方式 第九章：系統升級與版本管理 9.1 升級前檢查事項 9.2 資料庫相容性注意事項 9.3 設定變更風險 9.4 Rollback 建議策略 第十章：最佳實務與設計建議 10.1 Realm / Client 命名規範 10.2 多系統共用 Keycloak 的設計原則 10.3 銀行或大型企業常見踩雷點 10.4 開發、測試、正式環境隔離建議 附錄：檢查清單（Checklist） 初次部署檢查清單 日常維運檢查清單 系統整合檢查清單 常見 Q\u0026amp;A 參考資源 第一章：Keycloak 簡介與核心概念 1.1 Keycloak 是什麼？ Keycloak 是由 Red Hat 開發並維護的開源 身分與存取管理（Identity and Access Management, IAM） 解決方案，目前為 CNCF 孵化專案。\n","title":"Keycloak教學手冊"},{"content":"OpenTelemetry教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、DevOps / SRE、系統架構師 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: OpenTelemetry OpenTelemetry 版本：v1.x（2025/2026 最新穩定版） Created by: Eric Cheng\n目錄 OpenTelemetry 概述\n1.1 OpenTelemetry 是什麼？解決什麼問題？ 1.2 與傳統 APM / Monitoring 工具的差異 1.3 Observability 三大支柱：Traces / Metrics / Logs 1.4 OpenTelemetry 在 CNCF 生態系中的角色 OpenTelemetry 整體系統架構\n2.1 架構總覽 2.2 核心元件說明 2.3 Agent-based vs SDK-based 收集模式比較 2.4 與 Prometheus / Grafana / Jaeger / ELK 的整合架構 OpenTelemetry 安裝指南\n3.1 本機環境（Local / VM） 3.2 Container / Docker 3.3 Kubernetes OpenTelemetry Collector 設定\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/opentelemetry%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"OpenTelemetry教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、DevOps / SRE、系統架構師 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: OpenTelemetry OpenTelemetry 版本：v1.x（2025/2026 最新穩定版） Created by: Eric Cheng\n目錄 OpenTelemetry 概述\n1.1 OpenTelemetry 是什麼？解決什麼問題？ 1.2 與傳統 APM / Monitoring 工具的差異 1.3 Observability 三大支柱：Traces / Metrics / Logs 1.4 OpenTelemetry 在 CNCF 生態系中的角色 OpenTelemetry 整體系統架構\n2.1 架構總覽 2.2 核心元件說明 2.3 Agent-based vs SDK-based 收集模式比較 2.4 與 Prometheus / Grafana / Jaeger / ELK 的整合架構 OpenTelemetry 安裝指南\n3.1 本機環境（Local / VM） 3.2 Container / Docker 3.3 Kubernetes OpenTelemetry Collector 設定\n","title":"OpenTelemetry教學手冊"},{"content":"Apache Kafka 教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、SRE、DevOps 定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月29日\n適用於: 適用於 Kafka 3.x（含 KRaft 架構） Created by: Eric Cheng\n目錄 Apache Kafka 簡介 1.1 Kafka 是什麼？解決什麼問題？ 1.2 與傳統 Message Queue 的差異 1.3 適合與不適合的使用情境 Kafka 系統架構總覽 2.1 Kafka 核心元件說明 2.2 高可用（HA）與水平擴充設計原則 Kafka 安裝與部署 3.1 環境需求 3.2 單機環境安裝（KRaft 模式） 3.3 多節點叢集安裝（正式環境） 3.4 ZooKeeper 與 KRaft 架構比較 3.5 常見安裝錯誤與排除方式 Kafka 基本設定說明 4.1 Broker 重要設定參數 4.2 Topic 設計原則 4.3 Producer 重要設定 4.4 Consumer 重要設定 4.5 資料保留策略（Retention Policy） Kafka 系統使用教學 5.1 Topic 管理 5.2 Producer 發送訊息 5.3 Consumer 消費訊息 5.4 Offset 管理 5.5 訊息順序性與重複消費 Kafka 與應用系統串接方式 6.1 與 Spring Boot 整合 6.2 系統解耦架構設計 6.3 同步系統 vs 事件驅動架構 6.4 常見整合架構模式 Kafka 系統維運與監控 7.1 常見監控指標 7.2 Consumer Lag 監控與處理 7.3 系統監控設定 7.4 常見營運問題與排查 Kafka 系統升級與版本控管 8.1 升級策略（Rolling Upgrade） 8.2 升級前檢查清單 8.3 升級風險與回復機制 8.4 Client 相容性 安全性與權限控管 9.1 SSL/TLS 加密 9.2 SASL 認證 9.3 ACL 權限控管 9.4 企業安全設計建議 最佳實務與常見地雷 10.1 Topic 命名建議 10.2 Partition 設計地雷 10.3 Consumer Group 錯誤案例 10.4 真實專案常見誤用情境 10.5 最佳實務總結 檢查清單（Checklist） 11.1 新專案導入 Checklist 11.2 日常維運 Checklist 11.3 故障排除 Checklist 11.4 升級 Checklist 附錄 附錄 A：常用指令速查 附錄 B：設定參數速查 附錄 C：參考資源 1. Apache Kafka 簡介 1.1 Kafka 是什麼？解決什麼問題？ Apache Kafka 是一個分散式事件串流平台（Distributed Event Streaming Platform），由 LinkedIn 於 2011 年開源，現由 Apache 軟體基金會維護。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/kafka%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Apache Kafka 教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：後端工程師、系統架構師、SRE、DevOps 定位：企業內部標準教材 文件維護：內部技術團隊 使用情境：大型企業 / 銀行內部系統 最後更新: 2026年1月29日\n適用於: 適用於 Kafka 3.x（含 KRaft 架構） Created by: Eric Cheng\n目錄 Apache Kafka 簡介 1.1 Kafka 是什麼？解決什麼問題？ 1.2 與傳統 Message Queue 的差異 1.3 適合與不適合的使用情境 Kafka 系統架構總覽 2.1 Kafka 核心元件說明 2.2 高可用（HA）與水平擴充設計原則 Kafka 安裝與部署 3.1 環境需求 3.2 單機環境安裝（KRaft 模式） 3.3 多節點叢集安裝（正式環境） 3.4 ZooKeeper 與 KRaft 架構比較 3.5 常見安裝錯誤與排除方式 Kafka 基本設定說明 4.1 Broker 重要設定參數 4.2 Topic 設計原則 4.3 Producer 重要設定 4.4 Consumer 重要設定 4.5 資料保留策略（Retention Policy） Kafka 系統使用教學 5.1 Topic 管理 5.2 Producer 發送訊息 5.3 Consumer 消費訊息 5.4 Offset 管理 5.5 訊息順序性與重複消費 Kafka 與應用系統串接方式 6.1 與 Spring Boot 整合 6.2 系統解耦架構設計 6.3 同步系統 vs 事件驅動架構 6.4 常見整合架構模式 Kafka 系統維運與監控 7.1 常見監控指標 7.2 Consumer Lag 監控與處理 7.3 系統監控設定 7.4 常見營運問題與排查 Kafka 系統升級與版本控管 8.1 升級策略（Rolling Upgrade） 8.2 升級前檢查清單 8.3 升級風險與回復機制 8.4 Client 相容性 安全性與權限控管 9.1 SSL/TLS 加密 9.2 SASL 認證 9.3 ACL 權限控管 9.4 企業安全設計建議 最佳實務與常見地雷 10.1 Topic 命名建議 10.2 Partition 設計地雷 10.3 Consumer Group 錯誤案例 10.4 真實專案常見誤用情境 10.5 最佳實務總結 檢查清單（Checklist） 11.1 新專案導入 Checklist 11.2 日常維運 Checklist 11.3 故障排除 Checklist 11.4 升級 Checklist 附錄 附錄 A：常用指令速查 附錄 B：設定參數速查 附錄 C：參考資源 1. Apache Kafka 簡介 1.1 Kafka 是什麼？解決什麼問題？ Apache Kafka 是一個分散式事件串流平台（Distributed Event Streaming Platform），由 LinkedIn 於 2011 年開源，現由 Apache 軟體基金會維護。\n","title":"Apache Kafka 教學手冊"},{"content":"Redis教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、中階工程師、DevOps、新進同仁 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: Redis 7.x Created by: Eric Cheng\n目錄 Redis 簡介與核心概念 1.1 Redis 是什麼？適合解決什麼問題 1.2 In-Memory 設計原理 1.3 單執行緒模型與效能優勢 1.4 Redis 與 RDBMS / NoSQL 的差異 1.5 常見使用場景與反模式（Anti-pattern） Redis 系統架構設計 2.1 Redis 架構總覽 2.2 Single Node 架構 2.3 Master / Replica（主從複寫） 2.4 Sentinel 高可用架構 2.5 Redis Cluster 架構（Sharding） 2.6 架構選型建議 Redis 安裝與部署 3.1 Linux 安裝（建議版本） 3.2 Docker / Container 部署 3.3 基本目錄結構說明 3.4 Redis CLI 工具介紹 3.5 常見安裝錯誤與排查方式 Redis 設定（redis.conf） 4.1 基本設定說明 4.2 記憶體管理 4.3 Persistence 設定（RDB / AOF） 4.4 Replication 設定 4.5 Cluster / Sentinel 設定重點 4.6 資安相關設定 Redis 資料結構與使用方式 5.1 String（字串） 5.2 Hash（雜湊） 5.3 List（列表） 5.4 Set（集合） 5.5 Sorted Set（有序集合） 5.6 進階資料結構 Redis 系統使用實戰 6.1 快取設計模式 6.2 TTL 與 Key 命名規範 6.3 Session 管理 6.4 Rate Limiting（速率限制） 6.5 分散式 Lock（RedLock 概念） 6.6 Queue / Pub-Sub / Stream 使用情境 應用系統如何串接 Redis 7.1 系統整體架構說明 7.2 常見串接方式（Client Library） 7.3 Java（Spring Boot + Redis） 7.4 Node.js / Python 串接概念 7.5 Connection Pool 設計 7.6 Timeout / Retry / Fallback 設計 Redis 維運與監控 8.1 常用監控指標 8.2 INFO 指令說明 8.3 慢查詢（Slow Log） 8.4 Key 分析與 Big Key 問題 8.5 常見效能問題與處理方式 Redis 系統升級與版本管理 9.1 升級前評估事項 9.2 Rolling Upgrade 策略 9.3 升級風險與回滾策略 9.4 舊資料相容性說明 9.5 版本差異注意事項 資安與風險控管 10.1 Redis 常見資安風險 10.2 內網 / 外網使用原則 10.3 ACL 與權限控管 10.4 防止誤刪與資料風險 10.5 實務安全建議 Redis Best Practices（最佳實務） 11.1 Key 設計原則 11.2 避免的設計地雷 11.3 高併發系統設計建議 11.4 與資料庫搭配策略 11.5 團隊使用規範建議 常見問題與除錯（FAQ / Troubleshooting） 12.1 Redis 掛掉怎麼辦 12.2 記憶體暴增如何處理 12.3 Hit Rate 過低的原因 12.4 Replication 延遲處理 12.5 實務案例分享 檢查清單（Checklist） 🔧 部署前檢查 📝 開發規範檢查 🔍 日常維運檢查 🚀 升級前檢查 🛡️ 資安檢查 附錄：常用指令速查表\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/redis%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Redis教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、中階工程師、DevOps、新進同仁 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: Redis 7.x Created by: Eric Cheng\n目錄 Redis 簡介與核心概念 1.1 Redis 是什麼？適合解決什麼問題 1.2 In-Memory 設計原理 1.3 單執行緒模型與效能優勢 1.4 Redis 與 RDBMS / NoSQL 的差異 1.5 常見使用場景與反模式（Anti-pattern） Redis 系統架構設計 2.1 Redis 架構總覽 2.2 Single Node 架構 2.3 Master / Replica（主從複寫） 2.4 Sentinel 高可用架構 2.5 Redis Cluster 架構（Sharding） 2.6 架構選型建議 Redis 安裝與部署 3.1 Linux 安裝（建議版本） 3.2 Docker / Container 部署 3.3 基本目錄結構說明 3.4 Redis CLI 工具介紹 3.5 常見安裝錯誤與排查方式 Redis 設定（redis.conf） 4.1 基本設定說明 4.2 記憶體管理 4.3 Persistence 設定（RDB / AOF） 4.4 Replication 設定 4.5 Cluster / Sentinel 設定重點 4.6 資安相關設定 Redis 資料結構與使用方式 5.1 String（字串） 5.2 Hash（雜湊） 5.3 List（列表） 5.4 Set（集合） 5.5 Sorted Set（有序集合） 5.6 進階資料結構 Redis 系統使用實戰 6.1 快取設計模式 6.2 TTL 與 Key 命名規範 6.3 Session 管理 6.4 Rate Limiting（速率限制） 6.5 分散式 Lock（RedLock 概念） 6.6 Queue / Pub-Sub / Stream 使用情境 應用系統如何串接 Redis 7.1 系統整體架構說明 7.2 常見串接方式（Client Library） 7.3 Java（Spring Boot + Redis） 7.4 Node.js / Python 串接概念 7.5 Connection Pool 設計 7.6 Timeout / Retry / Fallback 設計 Redis 維運與監控 8.1 常用監控指標 8.2 INFO 指令說明 8.3 慢查詢（Slow Log） 8.4 Key 分析與 Big Key 問題 8.5 常見效能問題與處理方式 Redis 系統升級與版本管理 9.1 升級前評估事項 9.2 Rolling Upgrade 策略 9.3 升級風險與回滾策略 9.4 舊資料相容性說明 9.5 版本差異注意事項 資安與風險控管 10.1 Redis 常見資安風險 10.2 內網 / 外網使用原則 10.3 ACL 與權限控管 10.4 防止誤刪與資料風險 10.5 實務安全建議 Redis Best Practices（最佳實務） 11.1 Key 設計原則 11.2 避免的設計地雷 11.3 高併發系統設計建議 11.4 與資料庫搭配策略 11.5 團隊使用規範建議 常見問題與除錯（FAQ / Troubleshooting） 12.1 Redis 掛掉怎麼辦 12.2 記憶體暴增如何處理 12.3 Hit Rate 過低的原因 12.4 Replication 延遲處理 12.5 實務案例分享 檢查清單（Checklist） 🔧 部署前檢查 📝 開發規範檢查 🔍 日常維運檢查 🚀 升級前檢查 🛡️ 資安檢查 附錄：常用指令速查表\n","title":"Redis教學手冊"},{"content":"Logstash / Elasticsearch / Kibana（ELK Stack）教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深軟體工程師、系統架構師、SRE / DevOps 工程師 前置知識：Linux 基礎、Java 應用程式、基本網路概念 最後更新: 2026年1月27日\n適用於: Logs Visualization Created by: Eric Cheng\n目錄 第一章：Logs Visualization 與 ELK Stack 概述 1.1 為什麼需要 Logs Visualization 1.2 Logs 與 Metrics 的差異與互補 1.3 ELK Stack 架構總覽 1.4 ELK 在 Observability 架構中的角色 1.5 與 AI 輔助開發的關係 第二章：系統整體架構設計 2.1 ELK Stack 架構圖 2.2 各元件角色說明 2.3 單節點 vs 多節點架構 2.4 Production 建議架構 2.5 與 Prometheus / Grafana 並存架構 第三章：系統安裝 3.1 環境需求總覽 3.2 Elasticsearch 安裝 3.3 Logstash 安裝 3.4 Kibana 安裝 3.5 常見安裝問題排除 第四章：系統設定 4.1 Elasticsearch 設定 4.2 Logstash 設定 4.3 Kibana 設定 第五章：三者如何串接 5.1 End-to-End 資料流 5.2 實際串接範例 5.3 Filebeat 整合 第六章：系統使用 6.1 Kibana 操作教學 6.2 查詢語法詳解 6.3 實務使用情境 第七章：系統維護 7.1 Index 管理策略 7.2 效能調校 7.3 健康檢查與監控 第八章：系統升級 8.1 升級前準備 8.2 各元件升級流程 8.3 回復策略 第九章：安全性與權限管理 9.1 Security 基本概念 9.2 使用者與角色管理 9.3 企業資安考量 第十章：最佳實務與導入建議 10.1 導入常見踩雷點 10.2 結構化 Log 設計原則 10.3 與 AI 分析結合 10.4 與 Prometheus / Grafana 分工 附錄：檢查清單 安裝檢查清單 設定檢查清單 上線檢查清單 維運檢查清單（每日） 升級檢查清單 參考資源 第一章：Logs Visualization 與 ELK Stack 概述 1.1 為什麼需要 Logs Visualization 在現代企業級系統中，Log 是系統運行的「黑盒子記錄器」，記錄了系統每一個關鍵時刻的狀態與行為。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/elk-stack%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Logstash / Elasticsearch / Kibana（ELK Stack）教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深軟體工程師、系統架構師、SRE / DevOps 工程師 前置知識：Linux 基礎、Java 應用程式、基本網路概念 最後更新: 2026年1月27日\n適用於: Logs Visualization Created by: Eric Cheng\n目錄 第一章：Logs Visualization 與 ELK Stack 概述 1.1 為什麼需要 Logs Visualization 1.2 Logs 與 Metrics 的差異與互補 1.3 ELK Stack 架構總覽 1.4 ELK 在 Observability 架構中的角色 1.5 與 AI 輔助開發的關係 第二章：系統整體架構設計 2.1 ELK Stack 架構圖 2.2 各元件角色說明 2.3 單節點 vs 多節點架構 2.4 Production 建議架構 2.5 與 Prometheus / Grafana 並存架構 第三章：系統安裝 3.1 環境需求總覽 3.2 Elasticsearch 安裝 3.3 Logstash 安裝 3.4 Kibana 安裝 3.5 常見安裝問題排除 第四章：系統設定 4.1 Elasticsearch 設定 4.2 Logstash 設定 4.3 Kibana 設定 第五章：三者如何串接 5.1 End-to-End 資料流 5.2 實際串接範例 5.3 Filebeat 整合 第六章：系統使用 6.1 Kibana 操作教學 6.2 查詢語法詳解 6.3 實務使用情境 第七章：系統維護 7.1 Index 管理策略 7.2 效能調校 7.3 健康檢查與監控 第八章：系統升級 8.1 升級前準備 8.2 各元件升級流程 8.3 回復策略 第九章：安全性與權限管理 9.1 Security 基本概念 9.2 使用者與角色管理 9.3 企業資安考量 第十章：最佳實務與導入建議 10.1 導入常見踩雷點 10.2 結構化 Log 設計原則 10.3 與 AI 分析結合 10.4 與 Prometheus / Grafana 分工 附錄：檢查清單 安裝檢查清單 設定檢查清單 上線檢查清單 維運檢查清單（每日） 升級檢查清單 參考資源 第一章：Logs Visualization 與 ELK Stack 概述 1.1 為什麼需要 Logs Visualization 在現代企業級系統中，Log 是系統運行的「黑盒子記錄器」，記錄了系統每一個關鍵時刻的狀態與行為。\n","title":"ELK Stack教學手冊"},{"content":"Prometheus與Grafana教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、DevOps / SRE、系統架構師 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: Metrics Visualization Created by: Eric Cheng\n目錄 1. 總覽（Overview） 1.1 為何需要 Metrics Visualization 1.2 Prometheus 與 Grafana 在 Observability 中的角色 1.3 與 Logging / Tracing 的差異與整合方式 1.4 適合的使用場景 2. 架構說明（Architecture） 2.1 Prometheus 架構 2.2 Exporter 概念 2.3 Grafana 架構 2.4 Prometheus 與 Grafana 串接流程 2.5 單機 vs HA / Federation 架構 3. 系統安裝（Installation） 3.1 環境準備 3.2 Prometheus 安裝 3.3 Grafana 安裝 3.4 Node Exporter 安裝 3.5 目錄結構說明 3.6 常見安裝錯誤與排除 4. 系統設定（Configuration） 4.1 Prometheus 設定 4.2 Grafana 設定 5. 系統使用（Usage） 5.1 PromQL 基本與進階語法 5.2 常見 Metrics 範例 5.3 Dashboard 設計最佳實務 5.4 實務範例 5.5 與 AI 搭配使用 6. 告警與通知（Alerting） 6.1 Prometheus Alertmanager 架構 6.2 Alert Rule 撰寫範例 6.3 告警分級 6.4 Grafana Alert 與 Prometheus Alert 差異 6.5 與 Teams / Slack 整合 7. 系統維護（Maintenance） 7.1 資料成長與磁碟空間管理 7.2 效能調校建議 7.3 常見問題處理 7.4 備份與還原策略 8. 系統升級（Upgrade） 8.1 Prometheus 升級注意事項 8.2 Grafana 升級注意事項 8.3 升級前檢查清單 8.4 回滾（Rollback）策略 9. 企業實務與最佳實踐（Best Practices） 9.1 指標命名規範 9.2 Label 設計原則 9.3 多環境設計（DEV / SIT / UAT / PROD） 9.4 與 CI/CD、Batch、微服務整合 9.5 銀行與高穩定系統導入建議 10. 附錄（Appendix） 10.1 常用 PromQL Cheat Sheet 10.2 推薦 Exporter 清單 10.3 Dashboard 範本建議 10.4 常見錯誤與 FAQ 11. 檢查清單（Checklist） 11.1 安裝檢查清單 11.2 設定檢查清單 11.3 生產環境檢查清單 11.4 日常維運檢查清單 參考資源 1. 總覽（Overview） 1.1 為何需要 Metrics Visualization 在現代企業系統中，可觀測性（Observability） 是維運的核心能力。Metrics Visualization 提供以下價值：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/prometheus%E8%88%87grafana%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Prometheus與Grafana教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師、DevOps / SRE、系統架構師 定位：企業級實務導向教學手冊 最後更新: 2026年1月27日\n適用於: Metrics Visualization Created by: Eric Cheng\n目錄 1. 總覽（Overview） 1.1 為何需要 Metrics Visualization 1.2 Prometheus 與 Grafana 在 Observability 中的角色 1.3 與 Logging / Tracing 的差異與整合方式 1.4 適合的使用場景 2. 架構說明（Architecture） 2.1 Prometheus 架構 2.2 Exporter 概念 2.3 Grafana 架構 2.4 Prometheus 與 Grafana 串接流程 2.5 單機 vs HA / Federation 架構 3. 系統安裝（Installation） 3.1 環境準備 3.2 Prometheus 安裝 3.3 Grafana 安裝 3.4 Node Exporter 安裝 3.5 目錄結構說明 3.6 常見安裝錯誤與排除 4. 系統設定（Configuration） 4.1 Prometheus 設定 4.2 Grafana 設定 5. 系統使用（Usage） 5.1 PromQL 基本與進階語法 5.2 常見 Metrics 範例 5.3 Dashboard 設計最佳實務 5.4 實務範例 5.5 與 AI 搭配使用 6. 告警與通知（Alerting） 6.1 Prometheus Alertmanager 架構 6.2 Alert Rule 撰寫範例 6.3 告警分級 6.4 Grafana Alert 與 Prometheus Alert 差異 6.5 與 Teams / Slack 整合 7. 系統維護（Maintenance） 7.1 資料成長與磁碟空間管理 7.2 效能調校建議 7.3 常見問題處理 7.4 備份與還原策略 8. 系統升級（Upgrade） 8.1 Prometheus 升級注意事項 8.2 Grafana 升級注意事項 8.3 升級前檢查清單 8.4 回滾（Rollback）策略 9. 企業實務與最佳實踐（Best Practices） 9.1 指標命名規範 9.2 Label 設計原則 9.3 多環境設計（DEV / SIT / UAT / PROD） 9.4 與 CI/CD、Batch、微服務整合 9.5 銀行與高穩定系統導入建議 10. 附錄（Appendix） 10.1 常用 PromQL Cheat Sheet 10.2 推薦 Exporter 清單 10.3 Dashboard 範本建議 10.4 常見錯誤與 FAQ 11. 檢查清單（Checklist） 11.1 安裝檢查清單 11.2 設定檢查清單 11.3 生產環境檢查清單 11.4 日常維運檢查清單 參考資源 1. 總覽（Overview） 1.1 為何需要 Metrics Visualization 在現代企業系統中，可觀測性（Observability） 是維運的核心能力。Metrics Visualization 提供以下價值：\n","title":"Prometheus與Grafana教學手冊"},{"content":"Logs Visualization 教學手冊（ELK Stack） 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深軟體工程師、系統架構師、SRE / DevOps 工程師 最後更新: 2026年1月26日\n適用於: Logs Visualization Created by: Eric Cheng\n📋 目錄 Logs Visualization 在企業系統中的定位 1.1 為什麼 Logs 是「第二套真實系統」 1.2 Logs vs Metrics vs Tracing 1.3 Logs 在 Dev / QA / Prod 的不同價值 ELK Stack 整體架構設計 2.1 Log 產生端（Application / Middleware / OS） 2.2 Logstash Pipeline 設計原則 2.3 Elasticsearch Index / Shard / Replica 設計 2.4 Kibana 在視覺化與分析上的角色 Logstash 深度實務 3.1 Pipeline 架構設計（Input / Filter / Output） 3.2 Grok / JSON / Mutate 實務技巧 3.3 效能調校與常見瓶頸 3.4 多來源 Log（App / DB / MQ / Batch） Elasticsearch 架構與效能設計 4.1 Index 設計策略 4.2 Mapping 與效能影響 4.3 Hot / Warm / Cold 架構 4.4 查詢效能與資源規劃 Kibana 視覺化與分析設計 5.1 Dashboard 設計原則（給誰看？看什麼？） 5.2 Discover、Lens、Alerting 實務 5.3 常見企業 Dashboard 範例 AI 輔助 Logs Visualization 的實戰應用 6.1 用 AI 協助撰寫 Elasticsearch Query 6.2 用 AI 分析錯誤 Log 與異常模式 6.3 將 Logs 整理成 AI 可理解的 Prompt 6.4 AI 在 Incident Response 中的角色 常見問題、陷阱與最佳實務 7.1 Log 爆量的處理方式 7.2 Index 成長失控怎麼辦 7.3 資安與個資（PII）處理 7.4 金融業常見稽核與法遵需求 企業級導入與治理建議 8.1 Log 規範與命名標準 8.2 團隊分工與權限設計 8.3 與 CI/CD、APM、SIEM 的整合 檢查清單（Checklist） 附錄 A. 常用 Elasticsearch Query 範例 B. 常用 KQL 查詢範例 C. 參考資源 1. Logs Visualization 在企業系統中的定位 1.1 為什麼 Logs 是「第二套真實系統」 在企業級系統中，Logs 不只是除錯工具，而是系統行為的完整記錄。當生產環境發生問題時，Logs 往往是唯一能還原「當時到底發生什麼事」的證據。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/logs-visualization%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Logs Visualization 教學手冊（ELK Stack） 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深軟體工程師、系統架構師、SRE / DevOps 工程師 最後更新: 2026年1月26日\n適用於: Logs Visualization Created by: Eric Cheng\n📋 目錄 Logs Visualization 在企業系統中的定位 1.1 為什麼 Logs 是「第二套真實系統」 1.2 Logs vs Metrics vs Tracing 1.3 Logs 在 Dev / QA / Prod 的不同價值 ELK Stack 整體架構設計 2.1 Log 產生端（Application / Middleware / OS） 2.2 Logstash Pipeline 設計原則 2.3 Elasticsearch Index / Shard / Replica 設計 2.4 Kibana 在視覺化與分析上的角色 Logstash 深度實務 3.1 Pipeline 架構設計（Input / Filter / Output） 3.2 Grok / JSON / Mutate 實務技巧 3.3 效能調校與常見瓶頸 3.4 多來源 Log（App / DB / MQ / Batch） Elasticsearch 架構與效能設計 4.1 Index 設計策略 4.2 Mapping 與效能影響 4.3 Hot / Warm / Cold 架構 4.4 查詢效能與資源規劃 Kibana 視覺化與分析設計 5.1 Dashboard 設計原則（給誰看？看什麼？） 5.2 Discover、Lens、Alerting 實務 5.3 常見企業 Dashboard 範例 AI 輔助 Logs Visualization 的實戰應用 6.1 用 AI 協助撰寫 Elasticsearch Query 6.2 用 AI 分析錯誤 Log 與異常模式 6.3 將 Logs 整理成 AI 可理解的 Prompt 6.4 AI 在 Incident Response 中的角色 常見問題、陷阱與最佳實務 7.1 Log 爆量的處理方式 7.2 Index 成長失控怎麼辦 7.3 資安與個資（PII）處理 7.4 金融業常見稽核與法遵需求 企業級導入與治理建議 8.1 Log 規範與命名標準 8.2 團隊分工與權限設計 8.3 與 CI/CD、APM、SIEM 的整合 檢查清單（Checklist） 附錄 A. 常用 Elasticsearch Query 範例 B. 常用 KQL 查詢範例 C. 參考資源 1. Logs Visualization 在企業系統中的定位 1.1 為什麼 Logs 是「第二套真實系統」 在企業級系統中，Logs 不只是除錯工具，而是系統行為的完整記錄。當生產環境發生問題時，Logs 往往是唯一能還原「當時到底發生什麼事」的證據。\n","title":"Logs Visualization教學手冊"},{"content":"Metrics Visualization 教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師 / Tech Lead / Architect 最後更新: 2026年1月26日\n適用於: Metrics Visualization Created by: Eric Cheng\nMetrics Visualization 教學手冊（Prometheus + Grafana） 版本：v1.0\n最後更新：2026-01-26\n適用對象：資深後端工程師、系統架構師、SRE / DevOps 工程師\n前置知識：Linux / Container / Kubernetes 概念、RESTful API、微服務架構、基本監控概念\n📑 目錄 前言：為什麼你需要這份手冊 1.1 這份手冊的定位 1.2 讀者應具備的心態 Metrics 與 Observability 基礎 2.1 Metrics vs Logs vs Traces：架構視角 2.2 為什麼 Metrics 是「第一層防線」 2.3 RED / USE / Golden Signals 模型 2.4 Metrics 過度蒐集的反模式（Anti-pattern） Prometheus 深入解析 3.1 Prometheus 架構與資料流 3.2 Pull Model 的設計哲學 3.3 Target / Job / Instance 設計原則 3.4 Label 設計 Best Practices 3.5 常見 Exporter 類型 3.6 Recording Rules 與 Alert Rules 設計思維 3.7 PromQL 思考模型 Grafana 視覺化設計 4.1 Dashboard 設計的「故事線」概念 4.2 不同角色的 Dashboard 設計 4.3 指標選擇與視覺化類型對應 4.4 Anti-pattern Dashboard 範例 4.5 Grafana 與 Prometheus 的責任邊界 Metrics 與架構決策 5.1 用 Metrics 驗證架構假設 5.2 Scaling / Bottleneck / Capacity Planning 5.3 SLA / SLO / Error Budget 與 Metrics 5.4 Metrics 如何影響系統設計 AI 輔助 Metrics 分析 6.1 適合交給 AI 分析的 Metrics 類型 6.2 Prompt 設計範例 6.3 AI 在 Metrics 分析的限制與風險 6.4 人與 AI 的責任分工 實戰案例 7.1 案例 1：流量暴增導致服務降級 7.2 案例 2：記憶體洩漏導致週期性重啟 7.3 案例 3：快取穿透導致 DB 過載 檢查清單（Checklist） 8.1 Prometheus 部署檢查清單 8.2 Metrics 設計檢查清單 8.3 Dashboard 設計檢查清單 8.4 告警設計檢查清單 8.5 SLO 設計檢查清單 8.6 AI 輔助使用檢查清單 附錄：常用 PromQL 速查表 參考資源 1. 前言：為什麼你需要這份手冊 1.1 這份手冊的定位 這不是入門手冊。市面上已有太多「如何安裝 Prometheus」、「Grafana 快速上手」的教學。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/metrics-visualization-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Metrics Visualization 教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師 / Tech Lead / Architect 最後更新: 2026年1月26日\n適用於: Metrics Visualization Created by: Eric Cheng\nMetrics Visualization 教學手冊（Prometheus + Grafana） 版本：v1.0\n最後更新：2026-01-26\n適用對象：資深後端工程師、系統架構師、SRE / DevOps 工程師\n前置知識：Linux / Container / Kubernetes 概念、RESTful API、微服務架構、基本監控概念\n📑 目錄 前言：為什麼你需要這份手冊 1.1 這份手冊的定位 1.2 讀者應具備的心態 Metrics 與 Observability 基礎 2.1 Metrics vs Logs vs Traces：架構視角 2.2 為什麼 Metrics 是「第一層防線」 2.3 RED / USE / Golden Signals 模型 2.4 Metrics 過度蒐集的反模式（Anti-pattern） Prometheus 深入解析 3.1 Prometheus 架構與資料流 3.2 Pull Model 的設計哲學 3.3 Target / Job / Instance 設計原則 3.4 Label 設計 Best Practices 3.5 常見 Exporter 類型 3.6 Recording Rules 與 Alert Rules 設計思維 3.7 PromQL 思考模型 Grafana 視覺化設計 4.1 Dashboard 設計的「故事線」概念 4.2 不同角色的 Dashboard 設計 4.3 指標選擇與視覺化類型對應 4.4 Anti-pattern Dashboard 範例 4.5 Grafana 與 Prometheus 的責任邊界 Metrics 與架構決策 5.1 用 Metrics 驗證架構假設 5.2 Scaling / Bottleneck / Capacity Planning 5.3 SLA / SLO / Error Budget 與 Metrics 5.4 Metrics 如何影響系統設計 AI 輔助 Metrics 分析 6.1 適合交給 AI 分析的 Metrics 類型 6.2 Prompt 設計範例 6.3 AI 在 Metrics 分析的限制與風險 6.4 人與 AI 的責任分工 實戰案例 7.1 案例 1：流量暴增導致服務降級 7.2 案例 2：記憶體洩漏導致週期性重啟 7.3 案例 3：快取穿透導致 DB 過載 檢查清單（Checklist） 8.1 Prometheus 部署檢查清單 8.2 Metrics 設計檢查清單 8.3 Dashboard 設計檢查清單 8.4 告警設計檢查清單 8.5 SLO 設計檢查清單 8.6 AI 輔助使用檢查清單 附錄：常用 PromQL 速查表 參考資源 1. 前言：為什麼你需要這份手冊 1.1 這份手冊的定位 這不是入門手冊。市面上已有太多「如何安裝 Prometheus」、「Grafana 快速上手」的教學。\n","title":"Metrics Visualization 教學手冊"},{"content":"微前端教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師 / Tech Lead / Architect 最後更新: 2026年1月23日\n適用於: 微前端 Created by: Eric Cheng\n微前端（Micro-Frontend）教學手冊 版本：1.0\n適用對象：資深前端/全端工程師、Tech Lead、架構師\n最後更新：2026 年 1 月\n目錄 微前端的核心價值與真正要解決的問題\n1.1 什麼是微前端？ 1.2 微前端真正要解決的問題 1.3 什麼情況「不該用微前端」 1.4 微前端 vs 單體前端 vs Monorepo 1.5 本章實務案例 微前端主流架構模式比較\n2.1 基座（Shell / Container）模式 2.2 Runtime Integration vs Build-time Integration 2.3 iframe / Web Components / Module Federation 比較 2.4 主流框架方案比較 2.5 本章實務案例 Module Federation 深度解析\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/%E5%BE%AE%E5%89%8D%E7%AB%AF%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"微前端教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：資深工程師 / Tech Lead / Architect 最後更新: 2026年1月23日\n適用於: 微前端 Created by: Eric Cheng\n微前端（Micro-Frontend）教學手冊 版本：1.0\n適用對象：資深前端/全端工程師、Tech Lead、架構師\n最後更新：2026 年 1 月\n目錄 微前端的核心價值與真正要解決的問題\n1.1 什麼是微前端？ 1.2 微前端真正要解決的問題 1.3 什麼情況「不該用微前端」 1.4 微前端 vs 單體前端 vs Monorepo 1.5 本章實務案例 微前端主流架構模式比較\n2.1 基座（Shell / Container）模式 2.2 Runtime Integration vs Build-time Integration 2.3 iframe / Web Components / Module Federation 比較 2.4 主流框架方案比較 2.5 本章實務案例 Module Federation 深度解析\n","title":"微前端教學手冊"},{"content":"Claude Agent Skills 使用教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：新進軟體工程師、系統分析師、AI 導入成員 最後更新: 2026年1月8日\n適用於: Claude Code Created by: Eric Cheng\n目錄 前言 文件目的 適用對象 如何使用本手冊 第一章：Claude Agent 與 Agent Skills 基礎概念 1.1 什麼是 Claude Agent 1.2 什麼是 Agent Skills 1.3 Agent / Tool / Skill 的差異與關係 1.4 為什麼要使用 Agent Skills 第二章：Agent Skills 的設計理念 2.1 Skill 的責任邊界（Single Responsibility） 2.2 Skill 與 Prompt 的差異 2.3 Skill 是可重用、可組合的能力單元 2.4 官方 Skills Repo 的設計原則 第三章：官方 Skills Repository 結構說明 3.1 Skills GitHub 專案的目錄結構 3.2 Skill 的命名慣例 3.3 Skill 定義中的關鍵元素 第四章：Agent Skills 的使用方式 4.1 如何在 Agent 中呼叫 Skill 4.2 Skill 在任務流程中的角色 4.3 單一 Skill vs 多 Skill 組合 第五章：實務範例 5.1 需求文件產生 Skill 5.2 程式碼 Review / 重構 Skill 5.3 測試案例產生 Skill 第六章：新手常見錯誤與最佳實務 6.1 Skill 設計過大或過小的問題 6.2 把 Skill 當成一次性 Prompt 的錯誤用法 6.3 如何讓 Skill 更容易被重用 6.4 如何讓 Agent 行為更穩定 第七章：團隊導入建議 7.1 適合先從哪些類型的 Skill 開始 7.2 如何建立內部 Skill Library 7.3 與既有開發流程整合 7.4 導入成熟度階段建議 附錄：檢查清單（Checklist） Skill 建立前檢查 SKILL.md 撰寫檢查 Skill 發布前檢查 團隊導入檢查 參考資源 官方資源 延伸閱讀 前言 文件目的 本手冊旨在協助團隊成員快速理解並導入 Claude Agent Skills，透過系統化的教學內容，讓新進同仁能夠：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-agent-skills%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Claude Agent Skills 使用教學手冊 版本：1.0\n最後更新：2026 年 1 月\n適用對象：新進軟體工程師、系統分析師、AI 導入成員 最後更新: 2026年1月8日\n適用於: Claude Code Created by: Eric Cheng\n目錄 前言 文件目的 適用對象 如何使用本手冊 第一章：Claude Agent 與 Agent Skills 基礎概念 1.1 什麼是 Claude Agent 1.2 什麼是 Agent Skills 1.3 Agent / Tool / Skill 的差異與關係 1.4 為什麼要使用 Agent Skills 第二章：Agent Skills 的設計理念 2.1 Skill 的責任邊界（Single Responsibility） 2.2 Skill 與 Prompt 的差異 2.3 Skill 是可重用、可組合的能力單元 2.4 官方 Skills Repo 的設計原則 第三章：官方 Skills Repository 結構說明 3.1 Skills GitHub 專案的目錄結構 3.2 Skill 的命名慣例 3.3 Skill 定義中的關鍵元素 第四章：Agent Skills 的使用方式 4.1 如何在 Agent 中呼叫 Skill 4.2 Skill 在任務流程中的角色 4.3 單一 Skill vs 多 Skill 組合 第五章：實務範例 5.1 需求文件產生 Skill 5.2 程式碼 Review / 重構 Skill 5.3 測試案例產生 Skill 第六章：新手常見錯誤與最佳實務 6.1 Skill 設計過大或過小的問題 6.2 把 Skill 當成一次性 Prompt 的錯誤用法 6.3 如何讓 Skill 更容易被重用 6.4 如何讓 Agent 行為更穩定 第七章：團隊導入建議 7.1 適合先從哪些類型的 Skill 開始 7.2 如何建立內部 Skill Library 7.3 與既有開發流程整合 7.4 導入成熟度階段建議 附錄：檢查清單（Checklist） Skill 建立前檢查 SKILL.md 撰寫檢查 Skill 發布前檢查 團隊導入檢查 參考資源 官方資源 延伸閱讀 前言 文件目的 本手冊旨在協助團隊成員快速理解並導入 Claude Agent Skills，透過系統化的教學內容，讓新進同仁能夠：\n","title":"Claude Agent Skills教學手冊"},{"content":" 文件版本：2.0 對應規範：MCP Specification 2026-07-28（正式版，2026-07-28 發布） 前一規範：2025-11-25（相容性內容仍保留於本文） 最後更新：2026 年 7 月 31 日 文件等級：企業標準技術白皮書 適用對象：資深軟體開發工程師、系統架構師、平台工程與資安治理人員 Created by：Eric Cheng\nAnthropic Model Context Protocol (MCP) 教學手冊 重大提醒：2026-07-28 是 MCP 自發布以來最大幅度的改版，包含破壞性變更（Breaking Changes）。 核心協議由「有狀態、雙向」轉為「無狀態、請求／回應」。initialize 交握、Mcp-Session-Id 與 SSE 續傳機制均已移除；Roots、Sampling、Logging 進入棄用（Deprecated）狀態。 詳見 版本更新摘要 與 第十一章。\n目錄 版本更新摘要：2026-07-28 規範重點 0.1 一頁式變更總覽 0.2 破壞性變更清單 0.3 棄用功能與生命週期政策 0.4 本手冊改版說明 第一章：MCP 概述與核心概念 1.1 什麼是 MCP？ 1.2 為什麼需要 MCP？ 1.3 MCP 架構概覽 1.4 協議演進史與版本治理 第二章：MCP 技術架構深度解析 2.1 分層架構 2.2 資料層協議（Data Layer Protocol） 2.3 MCP 核心原語（Primitives） 2.4 通知機制與訂閱串流（Notifications \u0026amp; Subscriptions） 2.5 多輪往返請求（Multi Round-Trip Requests, MRTR） 第三章：傳輸層深度解析 3.1 STDIO Transport 3.2 Streamable HTTP Transport 3.3 標頭路由、快取與可觀測性 3.4 傳輸層相容性策略 第四章：實戰開發指南 4.1 開發環境設置 4.2 開發 MCP Server 4.3 開發 MCP Client 4.4 整合到 AI 應用 第五章：完整實戰範例 5.1 範例一：檔案系統 MCP Server 5.2 範例二：資料庫查詢 MCP Server 5.3 範例三：API 整合 MCP Server 第六章：最佳實踐與設計模式 6.1 MCP Server 設計原則 6.2 效能優化 6.3 安全性考量 6.4 測試策略 第七章：進階主題 7.1 Tasks 擴充（io.modelcontextprotocol/tasks） 7.2 自訂傳輸層 7.3 多語言 SDK 比較 7.4 偵錯與監控 第八章：疑難排解 8.1 常見錯誤與解決方案 8.2 除錯技巧 8.3 錯誤訊息參考 第九章：實際案例研究 9.1 案例一：企業知識庫 MCP Server 9.2 案例二：DevOps 整合 MCP Server 第十章：資源與參考 10.1 官方資源 10.2 社群資源 10.3 開發環境建議 10.4 版本相容性 10.5 快速參考 第十一章：2026-07-28 遷移指南 11.1 遷移總體策略 11.2 Server 端遷移步驟 11.3 Client 端遷移步驟 11.4 從 Session 到顯式握柄（Explicit Handle） 11.5 雙時代（Dual-era）相容部署 第十二章：擴充框架與官方擴充 12.1 擴充框架（Extensions Framework） 12.2 MCP Apps：伺服器渲染互動介面 12.3 Tasks 擴充深入解析 12.4 企業託管授權（EMA）與 OAuth 擴充 12.5 自建第三方擴充 第十三章：企業級部署與治理 13.1 無狀態水平擴展架構 13.2 API 閘道、WAF 與速率限制 13.3 授權硬化與身分治理 13.4 可觀測性與 OpenTelemetry 13.5 一致性驗證與 SDK 分級 附錄：檢查清單（Checklist） A. Server 開發檢查清單 B. 部署檢查清單 C. 程式碼審查檢查清單 D. 故障排除檢查清單 E. 2026-07-28 遷移檢查清單 結語 參考文獻與延伸閱讀 官方規範（2026-07-28） 治理與流程 官方擴充 官方部落格 社群分析 相關標準 主要 SEP 索引 版本更新摘要：2026-07-28 規範重點 0.1 一頁式變更總覽 2026-07-28 由六份以上的 SEP（Specification Enhancement Proposal）共同構成，將 MCP 從 「為單機 stdio 情境設計的有狀態雙向協議」重塑為「可在通用 HTTP 基礎設施上水平擴展的無狀態 請求／回應協議」。以下為與前一版 2025-11-25 的對照總覽。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/anthropic-model-context-protocol-mcp-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":" 文件版本：2.0 對應規範：MCP Specification 2026-07-28（正式版，2026-07-28 發布） 前一規範：2025-11-25（相容性內容仍保留於本文） 最後更新：2026 年 7 月 31 日 文件等級：企業標準技術白皮書 適用對象：資深軟體開發工程師、系統架構師、平台工程與資安治理人員 Created by：Eric Cheng\nAnthropic Model Context Protocol (MCP) 教學手冊 重大提醒：2026-07-28 是 MCP 自發布以來最大幅度的改版，包含破壞性變更（Breaking Changes）。 核心協議由「有狀態、雙向」轉為「無狀態、請求／回應」。initialize 交握、Mcp-Session-Id 與 SSE 續傳機制均已移除；Roots、Sampling、Logging 進入棄用（Deprecated）狀態。 詳見 版本更新摘要 與 第十一章。\n目錄 版本更新摘要：2026-07-28 規範重點 0.1 一頁式變更總覽 0.2 破壞性變更清單 0.3 棄用功能與生命週期政策 0.4 本手冊改版說明 第一章：MCP 概述與核心概念 1.1 什麼是 MCP？ 1.2 為什麼需要 MCP？ 1.3 MCP 架構概覽 1.4 協議演進史與版本治理 第二章：MCP 技術架構深度解析 2.1 分層架構 2.2 資料層協議（Data Layer Protocol） 2.3 MCP 核心原語（Primitives） 2.4 通知機制與訂閱串流（Notifications \u0026amp; Subscriptions） 2.5 多輪往返請求（Multi Round-Trip Requests, MRTR） 第三章：傳輸層深度解析 3.1 STDIO Transport 3.2 Streamable HTTP Transport 3.3 標頭路由、快取與可觀測性 3.4 傳輸層相容性策略 第四章：實戰開發指南 4.1 開發環境設置 4.2 開發 MCP Server 4.3 開發 MCP Client 4.4 整合到 AI 應用 第五章：完整實戰範例 5.1 範例一：檔案系統 MCP Server 5.2 範例二：資料庫查詢 MCP Server 5.3 範例三：API 整合 MCP Server 第六章：最佳實踐與設計模式 6.1 MCP Server 設計原則 6.2 效能優化 6.3 安全性考量 6.4 測試策略 第七章：進階主題 7.1 Tasks 擴充（io.modelcontextprotocol/tasks） 7.2 自訂傳輸層 7.3 多語言 SDK 比較 7.4 偵錯與監控 第八章：疑難排解 8.1 常見錯誤與解決方案 8.2 除錯技巧 8.3 錯誤訊息參考 第九章：實際案例研究 9.1 案例一：企業知識庫 MCP Server 9.2 案例二：DevOps 整合 MCP Server 第十章：資源與參考 10.1 官方資源 10.2 社群資源 10.3 開發環境建議 10.4 版本相容性 10.5 快速參考 第十一章：2026-07-28 遷移指南 11.1 遷移總體策略 11.2 Server 端遷移步驟 11.3 Client 端遷移步驟 11.4 從 Session 到顯式握柄（Explicit Handle） 11.5 雙時代（Dual-era）相容部署 第十二章：擴充框架與官方擴充 12.1 擴充框架（Extensions Framework） 12.2 MCP Apps：伺服器渲染互動介面 12.3 Tasks 擴充深入解析 12.4 企業託管授權（EMA）與 OAuth 擴充 12.5 自建第三方擴充 第十三章：企業級部署與治理 13.1 無狀態水平擴展架構 13.2 API 閘道、WAF 與速率限制 13.3 授權硬化與身分治理 13.4 可觀測性與 OpenTelemetry 13.5 一致性驗證與 SDK 分級 附錄：檢查清單（Checklist） A. Server 開發檢查清單 B. 部署檢查清單 C. 程式碼審查檢查清單 D. 故障排除檢查清單 E. 2026-07-28 遷移檢查清單 結語 參考文獻與延伸閱讀 官方規範（2026-07-28） 治理與流程 官方擴充 官方部落格 社群分析 相關標準 主要 SEP 索引 版本更新摘要：2026-07-28 規範重點 0.1 一頁式變更總覽 2026-07-28 由六份以上的 SEP（Specification Enhancement Proposal）共同構成，將 MCP 從 「為單機 stdio 情境設計的有狀態雙向協議」重塑為「可在通用 HTTP 基礎設施上水平擴展的無狀態 請求／回應協議」。以下為與前一版 2025-11-25 的對照總覽。\n","title":"Anthropic Model Context Protocol (MCP) 教學手冊"},{"content":" 版本: 3.3\n最後更新: 2026年5月31日 適用於: Claude Code v2.x (GA, 2025-2026)\nCreated by: Eric Cheng\nClaude Code 生態圈教學手冊 📖 版本: v3.3\n📅 最後更新: 2026年5月31日\n👥 目標讀者: 資深軟體工程師、技術主管、架構師\n📋 基於官方文件: Claude Code Documentation\n🆕 v3.3 更新: 排程任務新增三方比較（Routines/Desktop/Session）與 loop.md 自訂預設提示、Subagents 新增 Resume 機制與 Agent(agent_type) 子代理生成限制、Skills 新增 maxSkillDescriptionChars 與 compaction 後保留規則（5,000 token/25,000 budget）、Plugins 新增 claude plugin init 腳手架命令與 skills-directory plugins、Plugin Hints 推薦安裝機制、settings.json 預設設定與 background monitors、Hooks 新增 if 欄位進階篩選與 Stop Hook 阻擋上限機制\n目錄 第一部分：基礎概念 (Foundation) 1.1 Claude Code 簡介 1.1.1 產品定位與核心價值 1.1.2 多平台支援總覽 1.1.3 適用場景與限制 1.1.4 安裝與環境配置 1.1.5 Claude Code 的運作原理 1.1.6 Desktop App 與 Web 介面 1.1.7 Channels 與 Dispatch 1.2 核心架構概覽 1.2.1 系統架構圖 1.2.2 各組件之間的關係 1.2.3 資料流與執行流程 1.2.4 記憶體與設定架構 1.2.5 權限與安全模型 1.2.6 工具系統詳解 1.2.7 Agentic Loop 深入解析 1.3 快速上手實戰 1.3.1 第一次對話 1.3.2 建立 CLAUDE.md 1.3.3 常見操作範例 1.3.4 效率提升技巧 第二部分：核心功能詳解 2.1 Subagents (子代理) 2.1.1 概念說明 2.1.2 內建子代理類型 2.1.3 自訂子代理 2.1.4 使用場景與實作範例 2.1.5 進階技巧 2.1.6 Subagent 完整實戰範例 2.2 Agent Teams（多代理協作） 2.2.1 Agent Teams 概述 2.2.2 啟動與使用 Agent Teams 2.2.3 Agent Teams 的協調機制 2.2.4 應用場景與最佳實踐 2.2.5 Agent Teams 進階模式 2.2.6 Agent Teams 搭配 Hooks 2.3 Skills（技能系統） 2.3.1 Skills 概述 2.3.2 內建 Skills（Slash Commands） 2.3.3 SKILL.md 檔案格式 2.3.4 Agent Skills（附加在 Agent 上的 Skills） 2.3.5 開發自訂 Skills 2.3.6 Skills 最佳實踐 2.3.7 Skill 進階範例集 2.4 Plugins（插件系統） 2.4.1 Plugin 概述 2.4.2 Plugin 目錄結構 2.4.3 Plugin 的發現與安裝 2.4.4 開發自訂 Plugin 2.4.5 Plugin 安全與信任 2.4.6 Plugin 實戰範例 2.4.7 Plugin 與其他機制的關係 2.5 Hooks（鉤子機制） 2.5.1 Hooks 系統概述 2.5.2 Hook 事件類型（30 種） 2.5.3 Hook 類型（5 種） 2.5.4 Hook 配置詳解 2.5.5 實用 Hook 範例 2.5.6 Hook 執行規則與最佳實踐 2.5.7 進階 Hook 架構模式 2.5.8 Hook 進階控制機制 2.6 MCP（Model Context Protocol） 2.6.1 MCP 概述 2.6.2 配置 MCP Server 2.6.3 工具搜尋（Tool Search） 2.6.4 MCP 認證 2.6.5 企業級 MCP 管理 2.6.6 常見 MCP Server 推薦 2.6.7 自行開發 MCP Server 2.6.8 MCP 進階機制 2.6.9 MCP 除錯與疑難排解 2.7 Output Styles（輸出風格） 2.7.1 Output Styles 概述 2.7.2 配置 Output Styles 2.7.3 自訂輸出範本 2.7.4 場景化輸出風格 2.7.5 Output Styles 覆寫機制 2.7.6 與 Agent/Skill 結合 2.8 Scheduled Tasks（排程任務） 2.8.1 Scheduled Tasks 概述 2.8.2 配置排程任務 2.8.3 應用場景 2.8.4 排程任務搭配 Headless 模式 2.8.5 排程任務監控與通知 2.8.6 排程任務最佳實踐 第三部分：整合與最佳實踐 3.1 VS Code Extension 整合 3.1.1 安裝與啟用 3.1.2 核心功能 3.1.3 Checkpoints（檢查點） 3.1.4 Worktree 整合 3.1.5 第三方 AI Provider 3.1.6 VS Code 快捷鍵與命令總覽 3.1.7 Plan Mode（規劃模式）詳解 3.1.8 URI Handler 與 Plugin 管理 UI 3.1.9 VS Code 多實例與 Terminal 整合 3.2 Remote Control（遠端控制） 3.2.1 概述 3.2.2 啟動與連接 3.2.3 API 操作 3.2.4 應用場景 3.2.5 Remote Control 進階整合模式 3.3 Headless 模式與 SDK 3.3.1 Headless 模式 3.3.2 SDK 整合 3.3.3 應用場景 3.3.4 Headless 模式進階用法 3.4 整合工作流程 3.4.1 端到端開發流程 3.4.2 多元件協作實例 3.4.3 自動化配置組合範例 3.4.4 完整工作流程範例：從 Issue 到 PR 3.4.5 完整配置檔整合範例 3.5 團隊協作指南 3.5.1 共享配置管理 3.5.2 協作模式 3.5.3 知識共享 3.5.4 新人入職（Onboarding）工作流程 3.5.5 Code Review 工作流程 3.5.6 團隊開發標準化流程 3.6 效能優化 3.6.1 Token 使用優化 3.6.2 Context 管理優化 3.6.3 執行效率優化 3.6.4 成本控制策略 3.7 疑難排解 3.7.1 常見問題與解決方案 3.7.2 診斷方法 3.7.3 效能問題排查 3.7.4 取得幫助 3.8 Cowork 協同開發實戰 3.8.1 Cowork 概念與模式 3.8.2 團隊共享 CLAUDE.md 策略 3.8.3 多人協作工作流程 3.8.4 Agent Teams 協同開發 3.8.5 跨團隊 Plugin Marketplace 3.8.6 Remote Control 遠端協作 3.8.7 Channels 與 Dispatch 即時協作 3.8.8 Cowork 最佳實踐與防踩坑指南 第四部分：進階主題 4.1 企業級部署 4.1.1 企業管理架構 4.1.2 安全性配置 4.1.3 SSO 與認證整合 4.1.4 稽核日誌與合規性 4.1.5 企業部署架構模式 4.1.6 企業級配置管理策略 4.2 CI/CD 整合 4.2.1 GitHub Actions 整合 4.2.2 GitLab CI/CD 整合 4.2.3 通用 CI/CD 整合模式 4.2.4 CI/CD 最佳實踐 4.2.5 進階 CI/CD 場景 4.3 自訂開發 4.3.1 開發自訂 MCP Server 4.3.2 開發自訂 Skill 4.3.3 開發自訂 Plugin 4.3.4 自訂開發整合模式 4.4 Channels 與 Dispatch 深入解析 4.4.1 Channels 架構與協定 4.4.2 支援的通訊管道 4.4.3 Dispatch 行動端整合 4.4.4 自建 Channel MCP Server 4.4.5 企業級 Channel 部署 4.5 Agent Skills Open Standard 4.5.1 開放標準概述 4.5.2 agentskills.io 規範 4.5.3 跨工具互通性 4.5.4 社群生態與未來發展 第五部分：附錄 附錄 A：CLI 命令參考 A.1 啟動與基本操作 A.2 Slash Commands（互動式模式） A.3 Custom Slash Commands A.4 CLI 配置命令 A.5 進階 CLI 選項 A.6 CLI 環境變數 A.7 退出碼（Exit Codes） A.8 CLI 使用範例集 附錄 B：配置檔案參考 B.1 配置檔案一覽 B.2 settings.json 完整結構 B.3 .mcp.json 完整結構 B.4 CLAUDE.md 建議結構 B.5 managed-settings.json（企業管理員配置） B.6 managed-mcp.json（企業 MCP 管理） B.7 .claudeignore 語法 B.8 配置優先級完整圖 附錄 C：Hook Events 完整參考 C.1 所有事件 C.2 Hook 類型 C.3 環境變數 C.4 各事件詳細範例 C.5 常見 Hook 配方集 C.6 Hook 執行流程與錯誤處理 附錄 D：常見 MCP Servers 一覽 D.1 官方 MCP Servers D.2 社群熱門 MCP Servers D.3 依場景選擇 MCP Server D.4 MCP Server 配置範本 D.5 MCP Server 開發快速入門 D.6 MCP Server 除錯與監控 D.7 MCP Server 安全最佳實踐 附錄 E：術語表 附錄 F：常見問題 FAQ F.1 安裝與設定 F.2 使用技巧 F.3 企業使用 F.4 成本與效能 F.5 MCP 整合 F.6 Agent Teams 與協作 F.7 Skills 與 Plugins F.8 安全與隱私 結語 第一部分：基礎概念 (Foundation) 1.1 Claude Code 簡介 1.1.1 產品定位與核心價值 Claude Code 是 Anthropic 推出的 AI 輔助程式開發工具，定位為開發者的智慧協作夥伴，而非單純的程式碼生成器。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code%E7%94%9F%E6%85%8B%E5%9C%88%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":" 版本: 3.3\n最後更新: 2026年5月31日 適用於: Claude Code v2.x (GA, 2025-2026)\nCreated by: Eric Cheng\nClaude Code 生態圈教學手冊 📖 版本: v3.3\n📅 最後更新: 2026年5月31日\n👥 目標讀者: 資深軟體工程師、技術主管、架構師\n📋 基於官方文件: Claude Code Documentation\n🆕 v3.3 更新: 排程任務新增三方比較（Routines/Desktop/Session）與 loop.md 自訂預設提示、Subagents 新增 Resume 機制與 Agent(agent_type) 子代理生成限制、Skills 新增 maxSkillDescriptionChars 與 compaction 後保留規則（5,000 token/25,000 budget）、Plugins 新增 claude plugin init 腳手架命令與 skills-directory plugins、Plugin Hints 推薦安裝機制、settings.json 預設設定與 background monitors、Hooks 新增 if 欄位進階篩選與 Stop Hook 阻擋上限機制\n目錄 第一部分：基礎概念 (Foundation) 1.1 Claude Code 簡介 1.1.1 產品定位與核心價值 1.1.2 多平台支援總覽 1.1.3 適用場景與限制 1.1.4 安裝與環境配置 1.1.5 Claude Code 的運作原理 1.1.6 Desktop App 與 Web 介面 1.1.7 Channels 與 Dispatch 1.2 核心架構概覽 1.2.1 系統架構圖 1.2.2 各組件之間的關係 1.2.3 資料流與執行流程 1.2.4 記憶體與設定架構 1.2.5 權限與安全模型 1.2.6 工具系統詳解 1.2.7 Agentic Loop 深入解析 1.3 快速上手實戰 1.3.1 第一次對話 1.3.2 建立 CLAUDE.md 1.3.3 常見操作範例 1.3.4 效率提升技巧 第二部分：核心功能詳解 2.1 Subagents (子代理) 2.1.1 概念說明 2.1.2 內建子代理類型 2.1.3 自訂子代理 2.1.4 使用場景與實作範例 2.1.5 進階技巧 2.1.6 Subagent 完整實戰範例 2.2 Agent Teams（多代理協作） 2.2.1 Agent Teams 概述 2.2.2 啟動與使用 Agent Teams 2.2.3 Agent Teams 的協調機制 2.2.4 應用場景與最佳實踐 2.2.5 Agent Teams 進階模式 2.2.6 Agent Teams 搭配 Hooks 2.3 Skills（技能系統） 2.3.1 Skills 概述 2.3.2 內建 Skills（Slash Commands） 2.3.3 SKILL.md 檔案格式 2.3.4 Agent Skills（附加在 Agent 上的 Skills） 2.3.5 開發自訂 Skills 2.3.6 Skills 最佳實踐 2.3.7 Skill 進階範例集 2.4 Plugins（插件系統） 2.4.1 Plugin 概述 2.4.2 Plugin 目錄結構 2.4.3 Plugin 的發現與安裝 2.4.4 開發自訂 Plugin 2.4.5 Plugin 安全與信任 2.4.6 Plugin 實戰範例 2.4.7 Plugin 與其他機制的關係 2.5 Hooks（鉤子機制） 2.5.1 Hooks 系統概述 2.5.2 Hook 事件類型（30 種） 2.5.3 Hook 類型（5 種） 2.5.4 Hook 配置詳解 2.5.5 實用 Hook 範例 2.5.6 Hook 執行規則與最佳實踐 2.5.7 進階 Hook 架構模式 2.5.8 Hook 進階控制機制 2.6 MCP（Model Context Protocol） 2.6.1 MCP 概述 2.6.2 配置 MCP Server 2.6.3 工具搜尋（Tool Search） 2.6.4 MCP 認證 2.6.5 企業級 MCP 管理 2.6.6 常見 MCP Server 推薦 2.6.7 自行開發 MCP Server 2.6.8 MCP 進階機制 2.6.9 MCP 除錯與疑難排解 2.7 Output Styles（輸出風格） 2.7.1 Output Styles 概述 2.7.2 配置 Output Styles 2.7.3 自訂輸出範本 2.7.4 場景化輸出風格 2.7.5 Output Styles 覆寫機制 2.7.6 與 Agent/Skill 結合 2.8 Scheduled Tasks（排程任務） 2.8.1 Scheduled Tasks 概述 2.8.2 配置排程任務 2.8.3 應用場景 2.8.4 排程任務搭配 Headless 模式 2.8.5 排程任務監控與通知 2.8.6 排程任務最佳實踐 第三部分：整合與最佳實踐 3.1 VS Code Extension 整合 3.1.1 安裝與啟用 3.1.2 核心功能 3.1.3 Checkpoints（檢查點） 3.1.4 Worktree 整合 3.1.5 第三方 AI Provider 3.1.6 VS Code 快捷鍵與命令總覽 3.1.7 Plan Mode（規劃模式）詳解 3.1.8 URI Handler 與 Plugin 管理 UI 3.1.9 VS Code 多實例與 Terminal 整合 3.2 Remote Control（遠端控制） 3.2.1 概述 3.2.2 啟動與連接 3.2.3 API 操作 3.2.4 應用場景 3.2.5 Remote Control 進階整合模式 3.3 Headless 模式與 SDK 3.3.1 Headless 模式 3.3.2 SDK 整合 3.3.3 應用場景 3.3.4 Headless 模式進階用法 3.4 整合工作流程 3.4.1 端到端開發流程 3.4.2 多元件協作實例 3.4.3 自動化配置組合範例 3.4.4 完整工作流程範例：從 Issue 到 PR 3.4.5 完整配置檔整合範例 3.5 團隊協作指南 3.5.1 共享配置管理 3.5.2 協作模式 3.5.3 知識共享 3.5.4 新人入職（Onboarding）工作流程 3.5.5 Code Review 工作流程 3.5.6 團隊開發標準化流程 3.6 效能優化 3.6.1 Token 使用優化 3.6.2 Context 管理優化 3.6.3 執行效率優化 3.6.4 成本控制策略 3.7 疑難排解 3.7.1 常見問題與解決方案 3.7.2 診斷方法 3.7.3 效能問題排查 3.7.4 取得幫助 3.8 Cowork 協同開發實戰 3.8.1 Cowork 概念與模式 3.8.2 團隊共享 CLAUDE.md 策略 3.8.3 多人協作工作流程 3.8.4 Agent Teams 協同開發 3.8.5 跨團隊 Plugin Marketplace 3.8.6 Remote Control 遠端協作 3.8.7 Channels 與 Dispatch 即時協作 3.8.8 Cowork 最佳實踐與防踩坑指南 第四部分：進階主題 4.1 企業級部署 4.1.1 企業管理架構 4.1.2 安全性配置 4.1.3 SSO 與認證整合 4.1.4 稽核日誌與合規性 4.1.5 企業部署架構模式 4.1.6 企業級配置管理策略 4.2 CI/CD 整合 4.2.1 GitHub Actions 整合 4.2.2 GitLab CI/CD 整合 4.2.3 通用 CI/CD 整合模式 4.2.4 CI/CD 最佳實踐 4.2.5 進階 CI/CD 場景 4.3 自訂開發 4.3.1 開發自訂 MCP Server 4.3.2 開發自訂 Skill 4.3.3 開發自訂 Plugin 4.3.4 自訂開發整合模式 4.4 Channels 與 Dispatch 深入解析 4.4.1 Channels 架構與協定 4.4.2 支援的通訊管道 4.4.3 Dispatch 行動端整合 4.4.4 自建 Channel MCP Server 4.4.5 企業級 Channel 部署 4.5 Agent Skills Open Standard 4.5.1 開放標準概述 4.5.2 agentskills.io 規範 4.5.3 跨工具互通性 4.5.4 社群生態與未來發展 第五部分：附錄 附錄 A：CLI 命令參考 A.1 啟動與基本操作 A.2 Slash Commands（互動式模式） A.3 Custom Slash Commands A.4 CLI 配置命令 A.5 進階 CLI 選項 A.6 CLI 環境變數 A.7 退出碼（Exit Codes） A.8 CLI 使用範例集 附錄 B：配置檔案參考 B.1 配置檔案一覽 B.2 settings.json 完整結構 B.3 .mcp.json 完整結構 B.4 CLAUDE.md 建議結構 B.5 managed-settings.json（企業管理員配置） B.6 managed-mcp.json（企業 MCP 管理） B.7 .claudeignore 語法 B.8 配置優先級完整圖 附錄 C：Hook Events 完整參考 C.1 所有事件 C.2 Hook 類型 C.3 環境變數 C.4 各事件詳細範例 C.5 常見 Hook 配方集 C.6 Hook 執行流程與錯誤處理 附錄 D：常見 MCP Servers 一覽 D.1 官方 MCP Servers D.2 社群熱門 MCP Servers D.3 依場景選擇 MCP Server D.4 MCP Server 配置範本 D.5 MCP Server 開發快速入門 D.6 MCP Server 除錯與監控 D.7 MCP Server 安全最佳實踐 附錄 E：術語表 附錄 F：常見問題 FAQ F.1 安裝與設定 F.2 使用技巧 F.3 企業使用 F.4 成本與效能 F.5 MCP 整合 F.6 Agent Teams 與協作 F.7 Skills 與 Plugins F.8 安全與隱私 結語 第一部分：基礎概念 (Foundation) 1.1 Claude Code 簡介 1.1.1 產品定位與核心價值 Claude Code 是 Anthropic 推出的 AI 輔助程式開發工具，定位為開發者的智慧協作夥伴，而非單純的程式碼生成器。\n","title":"Claude Code生態圈教學手冊"},{"content":" 版本: 1.0\n最後更新: 2026年1月9日\n適用於: Claude Code Created by: Eric Cheng\nClaude Code 使用教學手冊（資深同仁版） 版本：1.0\n適用對象：資深工程師 / Tech Lead / 系統分析師 / 架構師\n最後更新：2026 年 1 月\n目錄 第一章：Claude Code 是什麼？（給資深工程師的視角） 1.1 Claude Code 與傳統 Copilot / ChatGPT Coding 的差異 1.2 適合用來做什麼？不適合做什麼？ 1.3 在企業環境中的合理定位 第二章：資深工程師使用 Claude Code 的正確心法 2.1 把 AI 當成「資深 Pair Programmer」而非新人工具 2.2 為什麼「規格比程式碼更重要」 2.3 Prompt 即設計文件的延伸 第三章：高品質 Prompt 設計原則 3.1 好 Prompt vs 壞 Prompt 對照 3.2 Prompt 必備元素 3.3 常見錯誤 Prompt 範例與改寫示範 第四章：Claude Code 在實務開發流程中的應用 4.1 需求釐清 / PRD 補強 4.2 架構設計與技術選型 4.3 程式碼生成與重構 4.4 測試案例補齊 4.5 技術文件與 README 生成 第五章：企業級實戰範例 5.1 範例一：協助重構 Legacy Code 5.2 範例二：根據規格產生模組骨架 5.3 範例三：產生測試與安全檢查建議 第六章：風險、限制與最佳實踐 6.1 AI 可能產生的風險 6.2 如何做 Code Review 與 AI Output Review 6.3 在銀行 / 企業內部的安全使用原則 第七章：團隊導入建議 7.1 適合哪些角色優先使用 7.2 與現有開發流程的整合方式 7.3 建議的內部使用規範 第八章：進階技巧與模式 8.1 Prompt Chain 設計模式 8.2 多輪對話策略 8.3 與 Spec-Driven Development 整合 附錄：檢查清單（Checklist） A. 使用前準備清單 B. Prompt 撰寫清單 C. 程式碼審查清單 D. 整合上線清單 E. 團隊導入清單 版本紀錄 參考資源 第一章：Claude Code 是什麼？（給資深工程師的視角） 1.1 Claude Code 與傳統 Copilot / ChatGPT Coding 的差異 作為資深工程師，您可能已經使用過多種 AI 編程輔助工具。以下是 Claude Code 與其他工具的核心差異：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A%E8%B3%87%E6%B7%B1%E5%90%8C%E4%BB%81%E7%89%88/","summary":" 版本: 1.0\n最後更新: 2026年1月9日\n適用於: Claude Code Created by: Eric Cheng\nClaude Code 使用教學手冊（資深同仁版） 版本：1.0\n適用對象：資深工程師 / Tech Lead / 系統分析師 / 架構師\n最後更新：2026 年 1 月\n目錄 第一章：Claude Code 是什麼？（給資深工程師的視角） 1.1 Claude Code 與傳統 Copilot / ChatGPT Coding 的差異 1.2 適合用來做什麼？不適合做什麼？ 1.3 在企業環境中的合理定位 第二章：資深工程師使用 Claude Code 的正確心法 2.1 把 AI 當成「資深 Pair Programmer」而非新人工具 2.2 為什麼「規格比程式碼更重要」 2.3 Prompt 即設計文件的延伸 第三章：高品質 Prompt 設計原則 3.1 好 Prompt vs 壞 Prompt 對照 3.2 Prompt 必備元素 3.3 常見錯誤 Prompt 範例與改寫示範 第四章：Claude Code 在實務開發流程中的應用 4.1 需求釐清 / PRD 補強 4.2 架構設計與技術選型 4.3 程式碼生成與重構 4.4 測試案例補齊 4.5 技術文件與 README 生成 第五章：企業級實戰範例 5.1 範例一：協助重構 Legacy Code 5.2 範例二：根據規格產生模組骨架 5.3 範例三：產生測試與安全檢查建議 第六章：風險、限制與最佳實踐 6.1 AI 可能產生的風險 6.2 如何做 Code Review 與 AI Output Review 6.3 在銀行 / 企業內部的安全使用原則 第七章：團隊導入建議 7.1 適合哪些角色優先使用 7.2 與現有開發流程的整合方式 7.3 建議的內部使用規範 第八章：進階技巧與模式 8.1 Prompt Chain 設計模式 8.2 多輪對話策略 8.3 與 Spec-Driven Development 整合 附錄：檢查清單（Checklist） A. 使用前準備清單 B. Prompt 撰寫清單 C. 程式碼審查清單 D. 整合上線清單 E. 團隊導入清單 版本紀錄 參考資源 第一章：Claude Code 是什麼？（給資深工程師的視角） 1.1 Claude Code 與傳統 Copilot / ChatGPT Coding 的差異 作為資深工程師，您可能已經使用過多種 AI 編程輔助工具。以下是 Claude Code 與其他工具的核心差異：\n","title":"Claude Code教學手冊(資深同仁版)"},{"content":" 版本: 1.0\n最後更新: 2026年1月9日\n適用於: Claude Code Created by: Eric Cheng\nClaude Code 使用教學手冊（新進同仁版） 版本：1.0\n最後更新：2026 年 1 月\n適用對象：新進軟體工程師（PG / SA / Tech Lead 初階）\n先決條件：具備基本程式設計能力\n目錄 第 1 章：Claude Code 是什麼？ 1.1 Claude Code 的定位 1.2 與一般聊天式 AI 的差異 1.3 適合與不適合的使用情境 1.4 Claude Code 在企業開發流程中的角色 第 2 章：Claude Code 的基本操作觀念 2.1 Prompt ≠ 問問題 2.2 好 Prompt 的核心結構 2.3 單輪 vs 多輪對話策略 2.4 如何逐步收斂出可用結果 第 3 章：新進工程師必學的 Prompt 範本 3.1 程式碼解讀 Prompt 3.2 新功能開發 Prompt 3.3 舊系統重構 Prompt 3.4 Bug 分析 Prompt 3.5 單元測試產生 Prompt 3.6 Code Review Prompt 3.7 規格補齊 Prompt 第 4 章：Claude Code 在實務開發中的典型流程 4.1 從需求文字到程式碼 4.2 從舊程式碼到可維護設計 4.3 從「我看不懂」到「我能修改」 4.4 搭配 Git / PR / Review 的使用方式 第 5 章：常見錯誤與 Anti-Pattern 5.1 問太籠統 5.2 一次丟太多責任 5.3 沒有限制輸出格式 5.4 盲目相信 AI 結果 5.5 沒做人工驗證 第 6 章：Claude Code 使用最佳實務（Best Practices） 6.1 Prompt 模組化 6.2 對話紀錄如何保存 6.3 與團隊共用 Prompt 的方式 6.4 什麼情況不該用 Claude Code 第 7 章：企業內部使用注意事項 7.1 資安與機敏資料原則 7.2 原始碼與客戶資料保護 7.3 法遵與稽核觀點 7.4 AI 產出責任歸屬說明 第 8 章：進階應用（選讀） 8.1 Spec-Driven Development（SDD） 8.2 將 Claude Code 當成虛擬 Pair Programmer 8.3 長任務拆解技巧 8.4 Prompt Chain 與角色切換 附錄：新進同仁檢查清單（Checklist） 延伸閱讀與資源 前言：如何使用本手冊 本手冊專為「新進軟體工程師」設計，協助您快速掌握 Claude Code 的使用方式。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/claude-code%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A%E6%96%B0%E6%89%8B%E7%89%88/","summary":" 版本: 1.0\n最後更新: 2026年1月9日\n適用於: Claude Code Created by: Eric Cheng\nClaude Code 使用教學手冊（新進同仁版） 版本：1.0\n最後更新：2026 年 1 月\n適用對象：新進軟體工程師（PG / SA / Tech Lead 初階）\n先決條件：具備基本程式設計能力\n目錄 第 1 章：Claude Code 是什麼？ 1.1 Claude Code 的定位 1.2 與一般聊天式 AI 的差異 1.3 適合與不適合的使用情境 1.4 Claude Code 在企業開發流程中的角色 第 2 章：Claude Code 的基本操作觀念 2.1 Prompt ≠ 問問題 2.2 好 Prompt 的核心結構 2.3 單輪 vs 多輪對話策略 2.4 如何逐步收斂出可用結果 第 3 章：新進工程師必學的 Prompt 範本 3.1 程式碼解讀 Prompt 3.2 新功能開發 Prompt 3.3 舊系統重構 Prompt 3.4 Bug 分析 Prompt 3.5 單元測試產生 Prompt 3.6 Code Review Prompt 3.7 規格補齊 Prompt 第 4 章：Claude Code 在實務開發中的典型流程 4.1 從需求文字到程式碼 4.2 從舊程式碼到可維護設計 4.3 從「我看不懂」到「我能修改」 4.4 搭配 Git / PR / Review 的使用方式 第 5 章：常見錯誤與 Anti-Pattern 5.1 問太籠統 5.2 一次丟太多責任 5.3 沒有限制輸出格式 5.4 盲目相信 AI 結果 5.5 沒做人工驗證 第 6 章：Claude Code 使用最佳實務（Best Practices） 6.1 Prompt 模組化 6.2 對話紀錄如何保存 6.3 與團隊共用 Prompt 的方式 6.4 什麼情況不該用 Claude Code 第 7 章：企業內部使用注意事項 7.1 資安與機敏資料原則 7.2 原始碼與客戶資料保護 7.3 法遵與稽核觀點 7.4 AI 產出責任歸屬說明 第 8 章：進階應用（選讀） 8.1 Spec-Driven Development（SDD） 8.2 將 Claude Code 當成虛擬 Pair Programmer 8.3 長任務拆解技巧 8.4 Prompt Chain 與角色切換 附錄：新進同仁檢查清單（Checklist） 延伸閱讀與資源 前言：如何使用本手冊 本手冊專為「新進軟體工程師」設計，協助您快速掌握 Claude Code 的使用方式。\n","title":"Claude Code教學手冊(新手版)"},{"content":"Java25升版教學 版本: 1.0\n最後更新: 2025年12月31日\n適用於: java 25 Created by: Eric Cheng +++\nJava 1.7 → Java 25 升版教學手冊 版本：1.0\n最後更新：2025 年 12 月\n適用對象：具備 Java 1.7～8 基礎的開發人員\n目標：企業升版實務 + Java OCP 認證準備\n📋 目錄 前言 第一章：Java 平台演進總覽（1.7 → 25） 1.1 Java 版本生命週期說明（LTS vs 非 LTS） 1.2 為何企業應升級至 Java 17 / 21 / 25 1.3 Java 設計哲學的重大轉變 1.4 Java 與 JVM、生態系的角色變化 第一章小結 第二章：Java 7 → Java 8（現代 Java 的分水嶺） 2.1 Lambda Expression 2.2 Functional Interface 2.3 Stream API 2.4 Optional 的正確使用方式 2.5 Default Method 2.6 實務對照：Java 7 vs Java 8 2.7 常見誤用與 OCP 考點 第二章小結 第三章：Java 9 ～ Java 11（模組化與平台重整） 3.1 Java Platform Module System（JPMS） 3.2 jlink / jdeps 工具 3.3 移除 Java EE 模組的影響 3.4 HTTP Client API 3.5 var（區域型別推斷） 3.6 TLS / Security 強化 3.7 升版衝擊與因應策略 第三章小結 第四章：Java 12 ～ Java 16（語言精煉期） 4.1 Switch Expression 4.2 Text Blocks 4.3 Records 4.4 Pattern Matching for instanceof 4.5 ZGC / Shenandoah 簡介 4.6 Preview Feature 使用與風險 第四章小結 第五章：Java 17（LTS，企業升版首選） 5.1 Java 17 作為企業基準版的理由 5.2 Sealed Class 5.3 強封裝（Strong Encapsulation） 5.4 移除與淘汰 API 清單 5.5 與 Spring Boot / Jakarta EE 的相容性 第五章小結 第六章：Java 18 ～ Java 20（為並行革命鋪路） 6.1 Foreign Function \u0026amp; Memory API 6.2 Vector API 6.3 JVM 效能最佳化重點 6.4 新 GC 行為觀察 第六章小結 第七章：Java 21（LTS，Virtual Thread 時代） 7.1 Virtual Thread（Project Loom） 7.2 Structured Concurrency 7.3 Scoped Value 7.4 傳統 Thread Pool vs Virtual Thread 7.5 對 Web / Batch / MQ 系統的影響 7.6 實務建議 第七章小結 第八章：Java 22 ～ Java 25（未來 Java 的樣貌） 8.1 Pattern Matching 完整體系 8.2 Record Pattern 8.3 Class File API 8.4 最新 GC / JVM 優化 8.5 Java 在 Cloud-Native、AI、High Concurrency 的定位 第八章小結 第九章：舊系統升版實務指南（企業必讀） 9.1 Java 1.7 → 17 / 21 / 25 升版路線圖 9.2 常見升版風險 9.2.1 Unsafe API 9.2.2 反射存取 9.2.3 ClassLoader 問題 9.2.4 編碼 / TLS / 加密 9.3 建議升版策略（分階段） 9.4 升版 Checklist 第九章小結 第十章：Java OCP 認證對照與準備建議 10.1 Java OCP（新版）考試範圍對照 10.2 必考語言特性整理 10.3 常見陷阱題解析方向 10.4 建議學習與實作順序 第十章小結 第十一章：總結與學習地圖 11.1 Java 現代化能力成熟度模型 11.2 從 Java 7 工程師 → Java 25 架構師 11.3 持續學習建議與官方資源 第十一章小結 附錄：升版檢查清單（Checklist） A. 完整升版檢查清單 B. 快速參考卡 結語 前言 為什麼需要這份手冊？ Java 自 1995 年誕生以來，已經走過近 30 年的歷程。從 Java 1.7 到 Java 25，Java 經歷了翻天覆地的變化：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/java25%E5%8D%87%E7%89%88%E6%95%99%E5%AD%B8/","summary":"Java25升版教學 版本: 1.0\n最後更新: 2025年12月31日\n適用於: java 25 Created by: Eric Cheng +++\nJava 1.7 → Java 25 升版教學手冊 版本：1.0\n最後更新：2025 年 12 月\n適用對象：具備 Java 1.7～8 基礎的開發人員\n目標：企業升版實務 + Java OCP 認證準備\n📋 目錄 前言 第一章：Java 平台演進總覽（1.7 → 25） 1.1 Java 版本生命週期說明（LTS vs 非 LTS） 1.2 為何企業應升級至 Java 17 / 21 / 25 1.3 Java 設計哲學的重大轉變 1.4 Java 與 JVM、生態系的角色變化 第一章小結 第二章：Java 7 → Java 8（現代 Java 的分水嶺） 2.1 Lambda Expression 2.2 Functional Interface 2.3 Stream API 2.4 Optional 的正確使用方式 2.5 Default Method 2.6 實務對照：Java 7 vs Java 8 2.7 常見誤用與 OCP 考點 第二章小結 第三章：Java 9 ～ Java 11（模組化與平台重整） 3.1 Java Platform Module System（JPMS） 3.2 jlink / jdeps 工具 3.3 移除 Java EE 模組的影響 3.4 HTTP Client API 3.5 var（區域型別推斷） 3.6 TLS / Security 強化 3.7 升版衝擊與因應策略 第三章小結 第四章：Java 12 ～ Java 16（語言精煉期） 4.1 Switch Expression 4.2 Text Blocks 4.3 Records 4.4 Pattern Matching for instanceof 4.5 ZGC / Shenandoah 簡介 4.6 Preview Feature 使用與風險 第四章小結 第五章：Java 17（LTS，企業升版首選） 5.1 Java 17 作為企業基準版的理由 5.2 Sealed Class 5.3 強封裝（Strong Encapsulation） 5.4 移除與淘汰 API 清單 5.5 與 Spring Boot / Jakarta EE 的相容性 第五章小結 第六章：Java 18 ～ Java 20（為並行革命鋪路） 6.1 Foreign Function \u0026amp; Memory API 6.2 Vector API 6.3 JVM 效能最佳化重點 6.4 新 GC 行為觀察 第六章小結 第七章：Java 21（LTS，Virtual Thread 時代） 7.1 Virtual Thread（Project Loom） 7.2 Structured Concurrency 7.3 Scoped Value 7.4 傳統 Thread Pool vs Virtual Thread 7.5 對 Web / Batch / MQ 系統的影響 7.6 實務建議 第七章小結 第八章：Java 22 ～ Java 25（未來 Java 的樣貌） 8.1 Pattern Matching 完整體系 8.2 Record Pattern 8.3 Class File API 8.4 最新 GC / JVM 優化 8.5 Java 在 Cloud-Native、AI、High Concurrency 的定位 第八章小結 第九章：舊系統升版實務指南（企業必讀） 9.1 Java 1.7 → 17 / 21 / 25 升版路線圖 9.2 常見升版風險 9.2.1 Unsafe API 9.2.2 反射存取 9.2.3 ClassLoader 問題 9.2.4 編碼 / TLS / 加密 9.3 建議升版策略（分階段） 9.4 升版 Checklist 第九章小結 第十章：Java OCP 認證對照與準備建議 10.1 Java OCP（新版）考試範圍對照 10.2 必考語言特性整理 10.3 常見陷阱題解析方向 10.4 建議學習與實作順序 第十章小結 第十一章：總結與學習地圖 11.1 Java 現代化能力成熟度模型 11.2 從 Java 7 工程師 → Java 25 架構師 11.3 持續學習建議與官方資源 第十一章小結 附錄：升版檢查清單（Checklist） A. 完整升版檢查清單 B. 快速參考卡 結語 前言 為什麼需要這份手冊？ Java 自 1995 年誕生以來，已經走過近 30 年的歷程。從 Java 1.7 到 Java 25，Java 經歷了翻天覆地的變化：\n","title":"Java25升版教學"},{"content":"OpenSpec 使用教學手冊 版本：6.0\n更新日期：2026-06-30\n適用版本：OpenSpec v1.5.0（含 Stores Beta、Profiles、OPSX 工作流程、動態指令架構、語義規格同步、Canonical Artifact Paths、Core Profile sync 指令、Mistral Vibe / Kimi CLI / Junie / Lingma / ForgeCode / IBM Bob 工具支援、Validator 增強、YAML Frontmatter 修正）\n適用對象：新進軟體工程師、系統分析師、尚未接觸過 SDD 或 OpenSpec 的同仁\n官方網站：openspec.dev\n目錄 前言 為什麼需要這份手冊？ 本手冊的目標 閱讀建議 第一章：OpenSpec 是什麼？ 1.1 為什麼會有 OpenSpec 1.2 與傳統 PRD / SRS / 設計文件的差異 1.3 OpenSpec 在 SDD 中扮演的角色 第二章：Spec-Driven Development（SDD）核心概念 2.1 規格優先（Spec First） 2.2 規格即合約（Spec as Contract） 2.3 規格可被 AI 理解與執行 第二章小結 第三章：OpenSpec 文件結構說明 3.1 常見 Spec 類型 3.2 每一種 Spec 的用途與撰寫原則 3.3 好的 Spec 與壞的 Spec 範例比較 第三章小結 第四章：使用 OpenSpec 的標準工作流程 4.1 從需求想法到 Spec 4.2 OPSX 工作流程與 Profiles 系統（v1.5.0） v1.5.0 版本重要更新 v1.4.0 版本重要更新 v1.4.1 版本修補 v1.3.1 版本重要更新 v1.3.0 版本重要更新 三大架構革新（v1.0.0 起） 各 AI 工具的指令語法差異 4.3 與 AI 互動修正 Spec 的方式 4.4 Spec 如何驅動設計、程式碼與測試 第四章小結 第五章：新進同仁實作範例 5.1 案例說明：帳戶餘額查詢 API 5.2 從需求描述到 OpenSpec 文件 5.3 示範如何向 AI 詢問與優化 Spec 第五章小結 第六章：常見錯誤與反模式（Anti-Patterns） 6.1 規格寫得像程式碼 6.2 規格過於抽象或過度細節化 6.3 把 AI 當成自動寫 Code 工具 常見反模式總覽 第六章小結 第七章：導入 OpenSpec 的最佳實務 7.1 團隊協作方式 7.2 Spec Review 重點 7.3 如何版本控管 Spec 第七章小結 第八章：給新進同仁的學習建議 8.1 上手順序 8.2 常見卡關點 8.3 如何從「會寫」進階到「寫得好」 第八章小結 第九章：進階主題 9.1 Progressive Rigor（漸進式嚴謹度） 9.2 Multi-Language 支援 9.3 自訂 Schema 進階用法 9.4 人類與 Agent 協作模式 9.5 Stores（Beta）—— 跨專案規格管理 第九章小結 附錄：檢查清單（Checklist） A. OpenSpec 環境設定檢查清單 B. Spec 撰寫檢查清單 C. Spec Review 檢查清單 D. 變更完成檢查清單 E. 常用 CLI 指令速查 F. 與 AI 對話 Prompt 範本 G. 支援的 AI 工具清單 H. 疑難排解（Troubleshooting） I. 術語表（Glossary） 參考資源 官方資源 相關工具 延伸閱讀 文件資訊 前言 為什麼需要這份手冊？ 在 AI 輔助開發的時代，許多團隊開始使用 GitHub Copilot、Claude、ChatGPT 等工具來加速開發。然而，AI 助手在沒有明確規格的情況下，容易產生不符合需求的程式碼，或是理解偏差導致返工。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/openspec%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"OpenSpec 使用教學手冊 版本：6.0\n更新日期：2026-06-30\n適用版本：OpenSpec v1.5.0（含 Stores Beta、Profiles、OPSX 工作流程、動態指令架構、語義規格同步、Canonical Artifact Paths、Core Profile sync 指令、Mistral Vibe / Kimi CLI / Junie / Lingma / ForgeCode / IBM Bob 工具支援、Validator 增強、YAML Frontmatter 修正）\n適用對象：新進軟體工程師、系統分析師、尚未接觸過 SDD 或 OpenSpec 的同仁\n官方網站：openspec.dev\n目錄 前言 為什麼需要這份手冊？ 本手冊的目標 閱讀建議 第一章：OpenSpec 是什麼？ 1.1 為什麼會有 OpenSpec 1.2 與傳統 PRD / SRS / 設計文件的差異 1.3 OpenSpec 在 SDD 中扮演的角色 第二章：Spec-Driven Development（SDD）核心概念 2.1 規格優先（Spec First） 2.2 規格即合約（Spec as Contract） 2.3 規格可被 AI 理解與執行 第二章小結 第三章：OpenSpec 文件結構說明 3.1 常見 Spec 類型 3.2 每一種 Spec 的用途與撰寫原則 3.3 好的 Spec 與壞的 Spec 範例比較 第三章小結 第四章：使用 OpenSpec 的標準工作流程 4.1 從需求想法到 Spec 4.2 OPSX 工作流程與 Profiles 系統（v1.5.0） v1.5.0 版本重要更新 v1.4.0 版本重要更新 v1.4.1 版本修補 v1.3.1 版本重要更新 v1.3.0 版本重要更新 三大架構革新（v1.0.0 起） 各 AI 工具的指令語法差異 4.3 與 AI 互動修正 Spec 的方式 4.4 Spec 如何驅動設計、程式碼與測試 第四章小結 第五章：新進同仁實作範例 5.1 案例說明：帳戶餘額查詢 API 5.2 從需求描述到 OpenSpec 文件 5.3 示範如何向 AI 詢問與優化 Spec 第五章小結 第六章：常見錯誤與反模式（Anti-Patterns） 6.1 規格寫得像程式碼 6.2 規格過於抽象或過度細節化 6.3 把 AI 當成自動寫 Code 工具 常見反模式總覽 第六章小結 第七章：導入 OpenSpec 的最佳實務 7.1 團隊協作方式 7.2 Spec Review 重點 7.3 如何版本控管 Spec 第七章小結 第八章：給新進同仁的學習建議 8.1 上手順序 8.2 常見卡關點 8.3 如何從「會寫」進階到「寫得好」 第八章小結 第九章：進階主題 9.1 Progressive Rigor（漸進式嚴謹度） 9.2 Multi-Language 支援 9.3 自訂 Schema 進階用法 9.4 人類與 Agent 協作模式 9.5 Stores（Beta）—— 跨專案規格管理 第九章小結 附錄：檢查清單（Checklist） A. OpenSpec 環境設定檢查清單 B. Spec 撰寫檢查清單 C. Spec Review 檢查清單 D. 變更完成檢查清單 E. 常用 CLI 指令速查 F. 與 AI 對話 Prompt 範本 G. 支援的 AI 工具清單 H. 疑難排解（Troubleshooting） I. 術語表（Glossary） 參考資源 官方資源 相關工具 延伸閱讀 文件資訊 前言 為什麼需要這份手冊？ 在 AI 輔助開發的時代，許多團隊開始使用 GitHub Copilot、Claude、ChatGPT 等工具來加速開發。然而，AI 助手在沒有明確規格的情況下，容易產生不符合需求的程式碼，或是理解偏差導致返工。\n","title":"OpenSpec使用教學"},{"content":"BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員:\n理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象:\n新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式:\n循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調:\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/bdd%E8%A1%8C%E7%82%BA%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員:\n理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象:\n新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式:\n循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調:\n","title":"BDD行為驅動開發使用教學手冊"},{"content":"BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員:\n理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象:\n新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式:\n循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調:\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/bdd%E8%A1%8C%E7%82%BA%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員:\n理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象:\n新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式:\n循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調:\n","title":"BDD行為驅動開發使用教學手冊"},{"content":"TDD（Test-Driven Development）測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的\n1.2 適用對象\n1.3 預期學習成果\n1.4 教學手冊架構說明\n二、TDD 概念與原則 2.1 什麼是 TDD（Test-Driven Development）\n2.2 TDD 的核心循環：Red → Green → Refactor\n2.3 TDD 與傳統開發流程的差異\n2.4 為什麼使用 TDD：好處與挑戰\n2.5 單元測試 vs. 集成測試 vs. 系統測試\n三、TDD 實踐步驟 3.1 Step 1：撰寫失敗的測試（Red）\n3.2 Step 2：撰寫最簡單的實作通過測試（Green）\n3.3 Step 3：重構程式碼（Refactor）\n3.4 Step 4：重複循環與迭代開發\n3.5 驗收標準（Definition of Done）與測試覆蓋率要求\n四、TDD 開發環境與工具 4.1 測試框架介紹\n4.2 IDE 與工具設定\n4.3 持續整合（CI）與自動化測試\n4.4 測試覆蓋率工具\n4.5 測試資料與 Mock 工具\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/tddtest-driven-development%E6%B8%AC%E8%A9%A6%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"TDD（Test-Driven Development）測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的\n1.2 適用對象\n1.3 預期學習成果\n1.4 教學手冊架構說明\n二、TDD 概念與原則 2.1 什麼是 TDD（Test-Driven Development）\n2.2 TDD 的核心循環：Red → Green → Refactor\n2.3 TDD 與傳統開發流程的差異\n2.4 為什麼使用 TDD：好處與挑戰\n2.5 單元測試 vs. 集成測試 vs. 系統測試\n三、TDD 實踐步驟 3.1 Step 1：撰寫失敗的測試（Red）\n3.2 Step 2：撰寫最簡單的實作通過測試（Green）\n3.3 Step 3：重構程式碼（Refactor）\n3.4 Step 4：重複循環與迭代開發\n3.5 驗收標準（Definition of Done）與測試覆蓋率要求\n四、TDD 開發環境與工具 4.1 測試框架介紹\n4.2 IDE 與工具設定\n4.3 持續整合（CI）與自動化測試\n4.4 測試覆蓋率工具\n4.5 測試資料與 Mock 工具\n","title":"TDD(Test-Driven Development)測試驅動開發教學手冊"},{"content":"TDD（Test-Driven Development）測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的\n1.2 適用對象\n1.3 預期學習成果\n1.4 教學手冊架構說明\n二、TDD 概念與原則 2.1 什麼是 TDD（Test-Driven Development）\n2.2 TDD 的核心循環：Red → Green → Refactor\n2.3 TDD 與傳統開發流程的差異\n2.4 為什麼使用 TDD：好處與挑戰\n2.5 單元測試 vs. 集成測試 vs. 系統測試\n三、TDD 實踐步驟 3.1 Step 1：撰寫失敗的測試（Red）\n3.2 Step 2：撰寫最簡單的實作通過測試（Green）\n3.3 Step 3：重構程式碼（Refactor）\n3.4 Step 4：重複循環與迭代開發\n3.5 驗收標準（Definition of Done）與測試覆蓋率要求\n四、TDD 開發環境與工具 4.1 測試框架介紹\n4.2 IDE 與工具設定\n4.3 持續整合（CI）與自動化測試\n4.4 測試覆蓋率工具\n4.5 測試資料與 Mock 工具\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/tddtest-driven-development%E6%B8%AC%E8%A9%A6%E9%A9%85%E5%8B%95%E9%96%8B%E7%99%BC%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"TDD（Test-Driven Development）測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的\n1.2 適用對象\n1.3 預期學習成果\n1.4 教學手冊架構說明\n二、TDD 概念與原則 2.1 什麼是 TDD（Test-Driven Development）\n2.2 TDD 的核心循環：Red → Green → Refactor\n2.3 TDD 與傳統開發流程的差異\n2.4 為什麼使用 TDD：好處與挑戰\n2.5 單元測試 vs. 集成測試 vs. 系統測試\n三、TDD 實踐步驟 3.1 Step 1：撰寫失敗的測試（Red）\n3.2 Step 2：撰寫最簡單的實作通過測試（Green）\n3.3 Step 3：重構程式碼（Refactor）\n3.4 Step 4：重複循環與迭代開發\n3.5 驗收標準（Definition of Done）與測試覆蓋率要求\n四、TDD 開發環境與工具 4.1 測試框架介紹\n4.2 IDE 與工具設定\n4.3 持續整合（CI）與自動化測試\n4.4 測試覆蓋率工具\n4.5 測試資料與 Mock 工具\n","title":"TDD(Test-Driven Development)測試驅動開發教學手冊"},{"content":"📝 專案計畫書範本(草稿) 1. 專案簡介 專案名稱：應用系統架構轉型計畫\n專案目標：\nPhase 1：單體 → 容器化 → 上雲，達成 Lift \u0026amp; Shift Phase 2：單體 → 微服務 → 容器化 → 上雲，完成業務導向解耦 範圍：\n涉及核心應用（XX 系統）、資料庫（DB2 / Oracle）、應用伺服器（Liberty）、批次處理（Spring Batch） 預期效益：\n部署時間縮短 70% MTTR 減少 50% 系統彈性與可擴展性提升 2. 專案里程碑 (Milestones) 里程碑 說明 產出物 時間 負責角色 M1 現況盤點與架構審視 系統盤點報告、風險清單 W1–W2 架構師、系統分析師 M2 容器化樣板建立 Dockerfile、Helm Chart、CI/CD Pipeline W3–W4 DevOps 工程師 M3 雲網路與基礎建設就緒 Terraform 模組、網路拓樸、資安控管表 W5–W6 雲平台工程師 M4 容器化驗證 SIT 測試報告、壓測報告、回退計畫 W7–W8 測試團隊、SRE M5 首批系統上線 上線計畫、Runbook、SLA/SLO 報告 W9–W10 PM、應用團隊 M6 微服務設計完成 業務域切分、API 契約、事件流設計 P2 W1–W2 架構師、業務分析師 M7 第一波微服務上線 新服務、契約測試、金絲雀報告 P2 W5–W8 Dev 團隊、SRE M8 單體功能替換完成 Strangler 完成報告、單體下線 P2 W12+ 架構師、PM 3. RACI 表（責任分配矩陣） 活動 PM 架構師 Dev DevOps/SRE 測試 業務單位 現況盤點 A R C C C I 容器化設計 C A/R R C I I CI/CD Pipeline I C R A I I 雲網路與 IaC I C I A/R I I SIT/UAT 測試 C C R C A I 上線與回退 A R R R C I 微服務切分 C A/R R C I C API/事件治理 I A R C C C 營運/Runbook A C I R I I (A=Accountable 負責決策 / R=Responsible 執行 / C=Consulted 諮詢 / I=Informed 知會)\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E6%9E%B6%E6%A7%8B%E8%BD%89%E6%8F%9B%E5%B0%88%E6%A1%88%E8%A8%88%E7%95%AB%E7%AF%84%E6%9C%AC/","summary":"📝 專案計畫書範本(草稿) 1. 專案簡介 專案名稱：應用系統架構轉型計畫\n專案目標：\nPhase 1：單體 → 容器化 → 上雲，達成 Lift \u0026amp; Shift Phase 2：單體 → 微服務 → 容器化 → 上雲，完成業務導向解耦 範圍：\n涉及核心應用（XX 系統）、資料庫（DB2 / Oracle）、應用伺服器（Liberty）、批次處理（Spring Batch） 預期效益：\n部署時間縮短 70% MTTR 減少 50% 系統彈性與可擴展性提升 2. 專案里程碑 (Milestones) 里程碑 說明 產出物 時間 負責角色 M1 現況盤點與架構審視 系統盤點報告、風險清單 W1–W2 架構師、系統分析師 M2 容器化樣板建立 Dockerfile、Helm Chart、CI/CD Pipeline W3–W4 DevOps 工程師 M3 雲網路與基礎建設就緒 Terraform 模組、網路拓樸、資安控管表 W5–W6 雲平台工程師 M4 容器化驗證 SIT 測試報告、壓測報告、回退計畫 W7–W8 測試團隊、SRE M5 首批系統上線 上線計畫、Runbook、SLA/SLO 報告 W9–W10 PM、應用團隊 M6 微服務設計完成 業務域切分、API 契約、事件流設計 P2 W1–W2 架構師、業務分析師 M7 第一波微服務上線 新服務、契約測試、金絲雀報告 P2 W5–W8 Dev 團隊、SRE M8 單體功能替換完成 Strangler 完成報告、單體下線 P2 W12+ 架構師、PM 3. RACI 表（責任分配矩陣） 活動 PM 架構師 Dev DevOps/SRE 測試 業務單位 現況盤點 A R C C C I 容器化設計 C A/R R C I I CI/CD Pipeline I C R A I I 雲網路與 IaC I C I A/R I I SIT/UAT 測試 C C R C A I 上線與回退 A R R R C I 微服務切分 C A/R R C I C API/事件治理 I A R C C C 營運/Runbook A C I R I I (A=Accountable 負責決策 / R=Responsible 執行 / C=Consulted 諮詢 / I=Informed 知會)\n","title":"架構轉換專案計畫範本"},{"content":"📝 專案計畫書範本(草稿) 1. 專案簡介 專案名稱：應用系統架構轉型計畫\n專案目標：\nPhase 1：單體 → 容器化 → 上雲，達成 Lift \u0026amp; Shift Phase 2：單體 → 微服務 → 容器化 → 上雲，完成業務導向解耦 範圍：\n涉及核心應用（XX 系統）、資料庫（DB2 / Oracle）、應用伺服器（Liberty）、批次處理（Spring Batch） 預期效益：\n部署時間縮短 70% MTTR 減少 50% 系統彈性與可擴展性提升 2. 專案里程碑 (Milestones) 里程碑 說明 產出物 時間 負責角色 M1 現況盤點與架構審視 系統盤點報告、風險清單 W1–W2 架構師、系統分析師 M2 容器化樣板建立 Dockerfile、Helm Chart、CI/CD Pipeline W3–W4 DevOps 工程師 M3 雲網路與基礎建設就緒 Terraform 模組、網路拓樸、資安控管表 W5–W6 雲平台工程師 M4 容器化驗證 SIT 測試報告、壓測報告、回退計畫 W7–W8 測試團隊、SRE M5 首批系統上線 上線計畫、Runbook、SLA/SLO 報告 W9–W10 PM、應用團隊 M6 微服務設計完成 業務域切分、API 契約、事件流設計 P2 W1–W2 架構師、業務分析師 M7 第一波微服務上線 新服務、契約測試、金絲雀報告 P2 W5–W8 Dev 團隊、SRE M8 單體功能替換完成 Strangler 完成報告、單體下線 P2 W12+ 架構師、PM 3. RACI 表（責任分配矩陣） 活動 PM 架構師 Dev DevOps/SRE 測試 業務單位 現況盤點 A R C C C I 容器化設計 C A/R R C I I CI/CD Pipeline I C R A I I 雲網路與 IaC I C I A/R I I SIT/UAT 測試 C C R C A I 上線與回退 A R R R C I 微服務切分 C A/R R C I C API/事件治理 I A R C C C 營運/Runbook A C I R I I (A=Accountable 負責決策 / R=Responsible 執行 / C=Consulted 諮詢 / I=Informed 知會)\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E6%9E%B6%E6%A7%8B%E8%BD%89%E6%8F%9B%E5%B0%88%E6%A1%88%E8%A8%88%E7%95%AB%E7%AF%84%E6%9C%AC/","summary":"📝 專案計畫書範本(草稿) 1. 專案簡介 專案名稱：應用系統架構轉型計畫\n專案目標：\nPhase 1：單體 → 容器化 → 上雲，達成 Lift \u0026amp; Shift Phase 2：單體 → 微服務 → 容器化 → 上雲，完成業務導向解耦 範圍：\n涉及核心應用（XX 系統）、資料庫（DB2 / Oracle）、應用伺服器（Liberty）、批次處理（Spring Batch） 預期效益：\n部署時間縮短 70% MTTR 減少 50% 系統彈性與可擴展性提升 2. 專案里程碑 (Milestones) 里程碑 說明 產出物 時間 負責角色 M1 現況盤點與架構審視 系統盤點報告、風險清單 W1–W2 架構師、系統分析師 M2 容器化樣板建立 Dockerfile、Helm Chart、CI/CD Pipeline W3–W4 DevOps 工程師 M3 雲網路與基礎建設就緒 Terraform 模組、網路拓樸、資安控管表 W5–W6 雲平台工程師 M4 容器化驗證 SIT 測試報告、壓測報告、回退計畫 W7–W8 測試團隊、SRE M5 首批系統上線 上線計畫、Runbook、SLA/SLO 報告 W9–W10 PM、應用團隊 M6 微服務設計完成 業務域切分、API 契約、事件流設計 P2 W1–W2 架構師、業務分析師 M7 第一波微服務上線 新服務、契約測試、金絲雀報告 P2 W5–W8 Dev 團隊、SRE M8 單體功能替換完成 Strangler 完成報告、單體下線 P2 W12+ 架構師、PM 3. RACI 表（責任分配矩陣） 活動 PM 架構師 Dev DevOps/SRE 測試 業務單位 現況盤點 A R C C C I 容器化設計 C A/R R C I I CI/CD Pipeline I C R A I I 雲網路與 IaC I C I A/R I I SIT/UAT 測試 C C R C A I 上線與回退 A R R R C I 微服務切分 C A/R R C I C API/事件治理 I A R C C C 營運/Runbook A C I R I I (A=Accountable 負責決策 / R=Responsible 執行 / C=Consulted 諮詢 / I=Informed 知會)\n","title":"架構轉換專案計畫範本"},{"content":" Codebase（單一程式碼庫，多個部署環境） 原則：一個應用程式應有單一程式碼庫，透過不同的部署（deploy）對應不同環境（dev/test/prod）。 解決方案：\n使用 GitLab repository 管理專案。 每個環境使用不同 branch 或 tag（如 develop, release, main）。 CI/CD pipeline 進行自動化部署，避免分散程式碼庫。 Dependencies（明確宣告與隔離依賴） 原則：應用程式必須明確管理相依性，避免依賴系統環境。 解決方案：\n後端：使用 Maven pom.xml 宣告所有 dependencies，不依賴本地安裝的 jar。 前端：使用 package.json 鎖定依賴版本。 建議使用 Docker 建立一致的 build/runtime 環境。 Config（將設定與程式碼分離） 原則：設定（如 DB 密碼、API key）不應寫死在程式碼中。 解決方案：\nSpring Boot 使用 application.yml + 外部設定檔 或 環境變數。 GitLab CI/CD 提供 Environment Variables 管理不同環境的設定。 建議搭配 Vault / AWS Secrets Manager / Kubernetes Secrets。 Backing Services（後端服務當作附加資源） 原則：資料庫、快取、MQ、外部 API 都應視為「可替換的資源」。 解決方案：\nDB（MySQL/DB2/PostgreSQL）、Redis、RabbitMQ 等連線資訊放在設定檔，不耦合程式。 測試環境可用輕量替代（如 testcontainers 啟動 DB/Redis）。 Build, Release, Run（明確分離建置、發佈、執行） 原則：建置（build）、發佈（release）、執行（run）必須分開，避免環境污染。 解決方案：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/12-factor-app-%E8%AA%AA%E6%98%8E%E8%88%87%E5%B0%8D%E6%87%89%E8%A7%A3%E6%B1%BA%E6%96%B9%E6%A1%88/","summary":" Codebase（單一程式碼庫，多個部署環境） 原則：一個應用程式應有單一程式碼庫，透過不同的部署（deploy）對應不同環境（dev/test/prod）。 解決方案：\n使用 GitLab repository 管理專案。 每個環境使用不同 branch 或 tag（如 develop, release, main）。 CI/CD pipeline 進行自動化部署，避免分散程式碼庫。 Dependencies（明確宣告與隔離依賴） 原則：應用程式必須明確管理相依性，避免依賴系統環境。 解決方案：\n後端：使用 Maven pom.xml 宣告所有 dependencies，不依賴本地安裝的 jar。 前端：使用 package.json 鎖定依賴版本。 建議使用 Docker 建立一致的 build/runtime 環境。 Config（將設定與程式碼分離） 原則：設定（如 DB 密碼、API key）不應寫死在程式碼中。 解決方案：\nSpring Boot 使用 application.yml + 外部設定檔 或 環境變數。 GitLab CI/CD 提供 Environment Variables 管理不同環境的設定。 建議搭配 Vault / AWS Secrets Manager / Kubernetes Secrets。 Backing Services（後端服務當作附加資源） 原則：資料庫、快取、MQ、外部 API 都應視為「可替換的資源」。 解決方案：\nDB（MySQL/DB2/PostgreSQL）、Redis、RabbitMQ 等連線資訊放在設定檔，不耦合程式。 測試環境可用輕量替代（如 testcontainers 啟動 DB/Redis）。 Build, Release, Run（明確分離建置、發佈、執行） 原則：建置（build）、發佈（release）、執行（run）必須分開，避免環境污染。 解決方案：\n","title":"12-Factor App 說明與對應解決方案"},{"content":"Angular 前端Framework教學手冊 目錄 1. 前言 為什麼要學習 Angular？ 專案背景 學習目標 2. 基礎篇 1. Angular 架構概念 1.1 核心概念 1.2 應用程式架構圖 2. 環境建置 2.1 必要軟體安裝 2.2 建立新專案 2.3 專案結構 3. 組件 (Components) 3.1 組件基本概念 3.2 建立組件 3.3 組件範例 4. 資料繫結 (Data Binding) 4.1 插值繫結 (Interpolation) 4.2 屬性繫結 (Property Binding) 4.3 事件繫結 (Event Binding) 4.4 雙向資料繫結 (Two-way Binding) 3. 進階篇 5. 模組 (Modules) 5.1 模組基本概念 5.2 根模組範例 5.3 功能模組建立 5.4 共用模組 6. 服務與相依性注入 (Services \u0026amp; Dependency Injection) 6.1 建立服務 6.2 基本服務範例 6.3 在組件中使用服務 6.4 服務注入層級 7. 路由 (Routing) 7.1 基本路由設定 7.2 子路由設定 7.3 路由導航 7.4 路由參數處理 7.5 路由守衛 4. 專案實務篇 8. 表單處理 8.1 範本驅動表單 (Template-driven Forms) 8.2 反應式表單 (Reactive Forms) 8.3 表單驗證最佳實務 9. HTTP 客戶端與 API 整合 9.1 HTTP 攔截器 9.2 API 服務封裝 10. RxJS 最佳實務 10.1 常用操作符 10.2 記憶體管理 11. 測試 (Testing) 11.1 單元測試範例 11.2 整合測試範例 11.3 指令測試範例 11.4 管道測試範例 11.5 路由測試範例 11.6 測試工具與最佳實務 5. 認證準備篇 12. Angular 官方認證考試重點 12.1 考試概要 12.2 重點知識領域 12.3 模擬考試題目 12.4 考前準備清單 13. 實戰模擬測驗 13.1 綜合練習題 13.2 進階練習題 6. 附錄 14. 常見問題 (FAQ) 14.1 開發環境問題 14.2 開發常見問題 14.3 效能問題 15. 有用的資源連結 15.1 官方資源 15.2 學習資源 15.3 工具與庫 15.4 社群資源 16. 快速參考檢查清單 16.1 新專案設置檢查清單 16.2 開發檢查清單 16.3 部署前檢查清單 16.4 程式碼審查檢查清單 17. 團隊開發規範 17.1 Git 工作流程 17.2 程式碼規範 17.3 程式碼審查標準 前言 為什麼要學習 Angular？ Angular 是由 Google 開發維護的前端框架，具有以下優勢：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/angular-%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"Angular 前端Framework教學手冊 目錄 1. 前言 為什麼要學習 Angular？ 專案背景 學習目標 2. 基礎篇 1. Angular 架構概念 1.1 核心概念 1.2 應用程式架構圖 2. 環境建置 2.1 必要軟體安裝 2.2 建立新專案 2.3 專案結構 3. 組件 (Components) 3.1 組件基本概念 3.2 建立組件 3.3 組件範例 4. 資料繫結 (Data Binding) 4.1 插值繫結 (Interpolation) 4.2 屬性繫結 (Property Binding) 4.3 事件繫結 (Event Binding) 4.4 雙向資料繫結 (Two-way Binding) 3. 進階篇 5. 模組 (Modules) 5.1 模組基本概念 5.2 根模組範例 5.3 功能模組建立 5.4 共用模組 6. 服務與相依性注入 (Services \u0026amp; Dependency Injection) 6.1 建立服務 6.2 基本服務範例 6.3 在組件中使用服務 6.4 服務注入層級 7. 路由 (Routing) 7.1 基本路由設定 7.2 子路由設定 7.3 路由導航 7.4 路由參數處理 7.5 路由守衛 4. 專案實務篇 8. 表單處理 8.1 範本驅動表單 (Template-driven Forms) 8.2 反應式表單 (Reactive Forms) 8.3 表單驗證最佳實務 9. HTTP 客戶端與 API 整合 9.1 HTTP 攔截器 9.2 API 服務封裝 10. RxJS 最佳實務 10.1 常用操作符 10.2 記憶體管理 11. 測試 (Testing) 11.1 單元測試範例 11.2 整合測試範例 11.3 指令測試範例 11.4 管道測試範例 11.5 路由測試範例 11.6 測試工具與最佳實務 5. 認證準備篇 12. Angular 官方認證考試重點 12.1 考試概要 12.2 重點知識領域 12.3 模擬考試題目 12.4 考前準備清單 13. 實戰模擬測驗 13.1 綜合練習題 13.2 進階練習題 6. 附錄 14. 常見問題 (FAQ) 14.1 開發環境問題 14.2 開發常見問題 14.3 效能問題 15. 有用的資源連結 15.1 官方資源 15.2 學習資源 15.3 工具與庫 15.4 社群資源 16. 快速參考檢查清單 16.1 新專案設置檢查清單 16.2 開發檢查清單 16.3 部署前檢查清單 16.4 程式碼審查檢查清單 17. 團隊開發規範 17.1 Git 工作流程 17.2 程式碼規範 17.3 程式碼審查標準 前言 為什麼要學習 Angular？ Angular 是由 Google 開發維護的前端框架，具有以下優勢：\n","title":"Angular 前端framework教學"},{"content":" 版本：v1.1（已完成第 1-16 章與附錄 A-E；持續維護優化）\n最後更新：2026-02-12（對應 JMeter 5.6.3 版本）\n適用對象：完全未接觸過效能測試 / JMeter 的新進開發與測試人員\n文件目標：協助 1~2 天內快速具備撰寫並執行基本壓力測試腳本的能力，並建立後續進階自學基礎。\n快速導讀 若你是第一次接觸 JMeter，建議依序閱讀：\nPart 1（必讀）：了解 JMeter 是什麼、安裝、基礎 GUI 操作。 Part 2：學會設計一個可維護的測試計畫（參數化、控制器、Assertion）。 Part 3：掌握報表分析與常見最佳實務（非 GUI、分散式、效能瓶頸初步診斷）。 Part 4：實戰情境（API / Web / DB / 企業案例）。 Part 5：若需考 JMeter 認證或建置團隊基準能力。 附錄：錯誤排除、報告範本、學習資源、Checklist。 目錄（Table of Contents） Part 1. 基礎入門（Ch.1-3） 1. JMeter 簡介\n1.1 JMeter 的定位與用途 1.2 常見測試類型 1.3 與其他工具比較 1.4 概念流程圖 1.5 本章實務案例 1.6 注意事項（初學者常犯） 2. 安裝與環境設定\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/jmeter%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":" 版本：v1.1（已完成第 1-16 章與附錄 A-E；持續維護優化）\n最後更新：2026-02-12（對應 JMeter 5.6.3 版本）\n適用對象：完全未接觸過效能測試 / JMeter 的新進開發與測試人員\n文件目標：協助 1~2 天內快速具備撰寫並執行基本壓力測試腳本的能力，並建立後續進階自學基礎。\n快速導讀 若你是第一次接觸 JMeter，建議依序閱讀：\nPart 1（必讀）：了解 JMeter 是什麼、安裝、基礎 GUI 操作。 Part 2：學會設計一個可維護的測試計畫（參數化、控制器、Assertion）。 Part 3：掌握報表分析與常見最佳實務（非 GUI、分散式、效能瓶頸初步診斷）。 Part 4：實戰情境（API / Web / DB / 企業案例）。 Part 5：若需考 JMeter 認證或建置團隊基準能力。 附錄：錯誤排除、報告範本、學習資源、Checklist。 目錄（Table of Contents） Part 1. 基礎入門（Ch.1-3） 1. JMeter 簡介\n1.1 JMeter 的定位與用途 1.2 常見測試類型 1.3 與其他工具比較 1.4 概念流程圖 1.5 本章實務案例 1.6 注意事項（初學者常犯） 2. 安裝與環境設定\n","title":"Apache JMeter 使用教學手冊"},{"content":"API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。\n角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。\n任務描述 請協助我完成 {專案名稱} 的API設計工作。\nAPI 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計：\n1. API 概覽設計 API 目標和範圍定義 資源模型設計 URL 結構規劃 HTTP 方法對應 2. 資料模型設計 實體關係模型 JSON Schema 定義 資料驗證規則 錯誤回應格式 3. 端點詳細設計 CRUD 操作設計 查詢和篩選設計 分頁機制設計 排序機制設計 4. 安全性設計 身份驗證機制 授權控制設計 API 金鑰管理 速率限制設計 5. 版本控制策略 版本控制方法 向後相容性規劃 廢棄策略設計 遷移指南規劃 6. 文檔和測試 OpenAPI 規格撰寫 使用範例提供 測試案例設計 錯誤處理指南 輸出格式 # {專案名稱} API 設計規格 ## 1. API 概覽 ### 1.1 API 目標 **主要目標:** [API 的主要用途和目標] **次要目標:** [輔助功能和延伸應用] **成功標準:** [API 品質和使用量指標] ### 1.2 API 設計原則 - **RESTful 設計**: 遵循 REST 架構風格 - **一致性**: 統一的命名和回應格式 - **可預測性**: 直觀的 URL 結構和行為 - **可擴展性**: 支援未來功能擴展 - **安全性**: 內建安全機制 ### 1.3 基礎 URL 結構 **Base URL:** `https://api.{domain}.com/v1` **URL 模式:** `/{resource}/{id}/{sub-resource}` ### 1.4 HTTP 方法對應 | HTTP 方法 | 用途 | 冪等性 | 安全性 | |-----------|------|--------|--------| | GET | 查詢資源 | 是 | 是 | | POST | 建立資源 | 否 | 否 | | PUT | 更新/替換資源 | 是 | 否 | | PATCH | 部分更新資源 | 否 | 否 | | DELETE | 刪除資源 | 是 | 否 | ## 2. 資料模型設計 ### 2.1 核心實體模型 #### 實體: User (使用者) ```json { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;string (3-50字元)\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;string (email格式)\u0026#34;, \u0026#34;firstName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;string (enum: admin, user, guest)\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;string (enum: active, inactive, suspended)\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 實體: Product (產品) { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;string (1-200字元)\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;string (可選，最多1000字元)\u0026#34;, \u0026#34;price\u0026#34;: \u0026#34;number (正數，最多2位小數)\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;sku\u0026#34;: \u0026#34;string (產品編號)\u0026#34;, \u0026#34;inventory\u0026#34;: { \u0026#34;quantity\u0026#34;: \u0026#34;integer (非負整數)\u0026#34;, \u0026#34;reserved\u0026#34;: \u0026#34;integer (非負整數)\u0026#34; }, \u0026#34;images\u0026#34;: [\u0026#34;string (URL陣列)\u0026#34;], \u0026#34;attributes\u0026#34;: { \u0026#34;color\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;size\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;weight\u0026#34;: \u0026#34;number\u0026#34; }, \u0026#34;isActive\u0026#34;: \u0026#34;boolean\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 2.2 標準回應格式 成功回應格式 { \u0026#34;success\u0026#34;: true, \u0026#34;data\u0026#34;: { // 實際資料內容 }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34;, \u0026#34;pagination\u0026#34;: { // 僅分頁查詢時包含 \u0026#34;page\u0026#34;: 1, \u0026#34;limit\u0026#34;: 20, \u0026#34;total\u0026#34;: 100, \u0026#34;totalPages\u0026#34;: 5 } } } 錯誤回應格式 { \u0026#34;success\u0026#34;: false, \u0026#34;error\u0026#34;: { \u0026#34;code\u0026#34;: \u0026#34;ERROR_CODE\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;錯誤訊息\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;詳細錯誤說明\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;發生錯誤的欄位 (驗證錯誤時)\u0026#34; }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34; } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/api%E8%A8%AD%E8%A8%88%E7%AF%84%E6%9C%AC/","summary":"API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。\n角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。\n任務描述 請協助我完成 {專案名稱} 的API設計工作。\nAPI 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計：\n1. API 概覽設計 API 目標和範圍定義 資源模型設計 URL 結構規劃 HTTP 方法對應 2. 資料模型設計 實體關係模型 JSON Schema 定義 資料驗證規則 錯誤回應格式 3. 端點詳細設計 CRUD 操作設計 查詢和篩選設計 分頁機制設計 排序機制設計 4. 安全性設計 身份驗證機制 授權控制設計 API 金鑰管理 速率限制設計 5. 版本控制策略 版本控制方法 向後相容性規劃 廢棄策略設計 遷移指南規劃 6. 文檔和測試 OpenAPI 規格撰寫 使用範例提供 測試案例設計 錯誤處理指南 輸出格式 # {專案名稱} API 設計規格 ## 1. API 概覽 ### 1.1 API 目標 **主要目標:** [API 的主要用途和目標] **次要目標:** [輔助功能和延伸應用] **成功標準:** [API 品質和使用量指標] ### 1.2 API 設計原則 - **RESTful 設計**: 遵循 REST 架構風格 - **一致性**: 統一的命名和回應格式 - **可預測性**: 直觀的 URL 結構和行為 - **可擴展性**: 支援未來功能擴展 - **安全性**: 內建安全機制 ### 1.3 基礎 URL 結構 **Base URL:** `https://api.{domain}.com/v1` **URL 模式:** `/{resource}/{id}/{sub-resource}` ### 1.4 HTTP 方法對應 | HTTP 方法 | 用途 | 冪等性 | 安全性 | |-----------|------|--------|--------| | GET | 查詢資源 | 是 | 是 | | POST | 建立資源 | 否 | 否 | | PUT | 更新/替換資源 | 是 | 否 | | PATCH | 部分更新資源 | 否 | 否 | | DELETE | 刪除資源 | 是 | 否 | ## 2. 資料模型設計 ### 2.1 核心實體模型 #### 實體: User (使用者) ```json { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;string (3-50字元)\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;string (email格式)\u0026#34;, \u0026#34;firstName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;string (enum: admin, user, guest)\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;string (enum: active, inactive, suspended)\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 實體: Product (產品) { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;string (1-200字元)\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;string (可選，最多1000字元)\u0026#34;, \u0026#34;price\u0026#34;: \u0026#34;number (正數，最多2位小數)\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;sku\u0026#34;: \u0026#34;string (產品編號)\u0026#34;, \u0026#34;inventory\u0026#34;: { \u0026#34;quantity\u0026#34;: \u0026#34;integer (非負整數)\u0026#34;, \u0026#34;reserved\u0026#34;: \u0026#34;integer (非負整數)\u0026#34; }, \u0026#34;images\u0026#34;: [\u0026#34;string (URL陣列)\u0026#34;], \u0026#34;attributes\u0026#34;: { \u0026#34;color\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;size\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;weight\u0026#34;: \u0026#34;number\u0026#34; }, \u0026#34;isActive\u0026#34;: \u0026#34;boolean\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 2.2 標準回應格式 成功回應格式 { \u0026#34;success\u0026#34;: true, \u0026#34;data\u0026#34;: { // 實際資料內容 }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34;, \u0026#34;pagination\u0026#34;: { // 僅分頁查詢時包含 \u0026#34;page\u0026#34;: 1, \u0026#34;limit\u0026#34;: 20, \u0026#34;total\u0026#34;: 100, \u0026#34;totalPages\u0026#34;: 5 } } } 錯誤回應格式 { \u0026#34;success\u0026#34;: false, \u0026#34;error\u0026#34;: { \u0026#34;code\u0026#34;: \u0026#34;ERROR_CODE\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;錯誤訊息\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;詳細錯誤說明\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;發生錯誤的欄位 (驗證錯誤時)\u0026#34; }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34; } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選\n","title":"API設計範本"},{"content":"Bash 使用教學手冊 📚 手冊說明 本手冊專為團隊新進開發同仁設計，旨在提供完整的 Bash 學習指引，讓同仁能夠：\n掌握 Bash 基礎與進階技能 在專案開發中正確使用 Bash 腳本 具備考取 Linux 相關認證的能力 遵循團隊 Bash 開發規範 📋 完整目錄結構 目錄 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 1.2 Bash 與 Linux/Unix 的關係 1.3 Bash 環境與版本檢查 1.4 常見開發環境介紹 1.5 基本命令列操作 1.6 編輯器使用 第 2 部分：Bash 核心語法 2.1 變數與資料型態 2.2 參數與引數 2.3 運算子與算術計算 2.4 條件判斷 2.5 迴圈結構 2.6 函式 2.7 輸入與輸出 2.8 管線與重新導向 第 3 部分：進階主題 3.1 陣列與字串處理 3.2 正則表達式與文字處理 3.3 檔案與目錄操作自動化 3.4 使用 cron 與排程任務 3.5 Bash 腳本除錯 3.6 錯誤處理 3.7 最佳實務 第 4 部分：專案應用實戰 4.1 自動化專案建置腳本 4.2 系統環境初始化 4.3 日誌分析與檔案過濾 4.4 檔案批次處理 4.5 自動化檔案傳輸 4.6 CI/CD 腳本整合 第 5 部分：考試準備 5.1 Bash 認證考試介紹 5.2 常見考試範疇與題型解析 5.3 範例考題與練習題 5.4 模擬測驗與解答解析 5.5 考試技巧與時間管理 第 6 部分：附錄 6.1 常用 Bash 指令速查表 6.2 Shell 腳本錯誤排查清單 6.3 Bash 相關學習資源 6.4 專案內部 Bash 腳本規範 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 📖 簡介 Bash（Bourne Again Shell）是一個命令列介面程式，也是一種腳本語言。它是 Linux 和 macOS 系統的預設 Shell，用於執行命令、自動化任務和系統管理。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/bash%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Bash 使用教學手冊 📚 手冊說明 本手冊專為團隊新進開發同仁設計，旨在提供完整的 Bash 學習指引，讓同仁能夠：\n掌握 Bash 基礎與進階技能 在專案開發中正確使用 Bash 腳本 具備考取 Linux 相關認證的能力 遵循團隊 Bash 開發規範 📋 完整目錄結構 目錄 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 1.2 Bash 與 Linux/Unix 的關係 1.3 Bash 環境與版本檢查 1.4 常見開發環境介紹 1.5 基本命令列操作 1.6 編輯器使用 第 2 部分：Bash 核心語法 2.1 變數與資料型態 2.2 參數與引數 2.3 運算子與算術計算 2.4 條件判斷 2.5 迴圈結構 2.6 函式 2.7 輸入與輸出 2.8 管線與重新導向 第 3 部分：進階主題 3.1 陣列與字串處理 3.2 正則表達式與文字處理 3.3 檔案與目錄操作自動化 3.4 使用 cron 與排程任務 3.5 Bash 腳本除錯 3.6 錯誤處理 3.7 最佳實務 第 4 部分：專案應用實戰 4.1 自動化專案建置腳本 4.2 系統環境初始化 4.3 日誌分析與檔案過濾 4.4 檔案批次處理 4.5 自動化檔案傳輸 4.6 CI/CD 腳本整合 第 5 部分：考試準備 5.1 Bash 認證考試介紹 5.2 常見考試範疇與題型解析 5.3 範例考題與練習題 5.4 模擬測驗與解答解析 5.5 考試技巧與時間管理 第 6 部分：附錄 6.1 常用 Bash 指令速查表 6.2 Shell 腳本錯誤排查清單 6.3 Bash 相關學習資源 6.4 專案內部 Bash 腳本規範 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 📖 簡介 Bash（Bourne Again Shell）是一個命令列介面程式，也是一種腳本語言。它是 Linux 和 macOS 系統的預設 Shell，用於執行命令、自動化任務和系統管理。\n","title":"Bash使用教學"},{"content":"C# 程式語言教學手冊 目錄 基礎入門\n1.1 C# 與 .NET 基本概念 1.2 開發環境設定 1.3 基本語法 1.3.1 變數與資料型別 1.3.2 流程控制 1.3.3 函式 (方法) 1.3.4 例外處理 物件導向程式設計 (OOP)\n2.1 類別與物件基礎 2.1.1 類別定義 2.1.2 存取修飾詞 2.2 繼承 (Inheritance) 2.2.1 基本繼承 2.3 多型 (Polymorphism) 2.3.1 虛擬方法與覆寫 2.4 介面 (Interface) 2.4.1 介面定義與實作 2.5 抽象類別 進階語法與實務\n3.1 泛型 (Generics) 3.1.1 泛型基礎概念 3.1.2 泛型約束 3.2 委派與事件 (Delegates \u0026amp; Events) 3.2.1 委派基礎 3.2.2 內建委派型別 (Func, Action, Predicate) 3.3 LINQ 語法與集合操作 3.3.1 LINQ 基礎查詢 3.3.2 進階 LINQ 操作與實務應用 3.4 非同步程式設計 (async/await) 3.4.1 非同步基礎概念 3.4.2 非同步最佳實務與進階應用 專案實務應用\n4.1 Web API 開發 (ASP.NET Core) 4.1.1 建立基本 Web API 4.2 資料庫存取 (Entity Framework Core) 4.2.1 Entity Framework 設定 4.3 單元測試 (xUnit) 4.3.1 基本單元測試 4.4 錯誤處理與日誌紀錄 4.4.1 全域錯誤處理 認證考試對應\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/c%23%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"C# 程式語言教學手冊 目錄 基礎入門\n1.1 C# 與 .NET 基本概念 1.2 開發環境設定 1.3 基本語法 1.3.1 變數與資料型別 1.3.2 流程控制 1.3.3 函式 (方法) 1.3.4 例外處理 物件導向程式設計 (OOP)\n2.1 類別與物件基礎 2.1.1 類別定義 2.1.2 存取修飾詞 2.2 繼承 (Inheritance) 2.2.1 基本繼承 2.3 多型 (Polymorphism) 2.3.1 虛擬方法與覆寫 2.4 介面 (Interface) 2.4.1 介面定義與實作 2.5 抽象類別 進階語法與實務\n3.1 泛型 (Generics) 3.1.1 泛型基礎概念 3.1.2 泛型約束 3.2 委派與事件 (Delegates \u0026amp; Events) 3.2.1 委派基礎 3.2.2 內建委派型別 (Func, Action, Predicate) 3.3 LINQ 語法與集合操作 3.3.1 LINQ 基礎查詢 3.3.2 進階 LINQ 操作與實務應用 3.4 非同步程式設計 (async/await) 3.4.1 非同步基礎概念 3.4.2 非同步最佳實務與進階應用 專案實務應用\n4.1 Web API 開發 (ASP.NET Core) 4.1.1 建立基本 Web API 4.2 資料庫存取 (Entity Framework Core) 4.2.1 Entity Framework 設定 4.3 單元測試 (xUnit) 4.3.1 基本單元測試 4.4 錯誤處理與日誌紀錄 4.4.1 全域錯誤處理 認證考試對應\n","title":"C#程式語言教學"},{"content":"CI/CD 流程範本 Prompt 目標 指導 AI 建立完整的 CI/CD 流程，包含持續整合、持續部署和基礎設施即程式碼。\n角色設定 你是一位資深 DevOps 工程師，具備豐富的 CI/CD 流程設計和實作經驗，熟悉各種自動化部署工具和雲端平台。\n任務描述 請協助我為 {專案名稱} 建立完整的 CI/CD 流程。\n專案 DevOps 背景 專案名稱: {填入專案名稱} 應用架構: {填入應用架構，如：微服務、單體應用} 技術棧: {填入技術棧} 部署平台: {填入目標平台，如：AWS、Azure、GCP、Kubernetes} 團隊規模: {填入團隊人數} 發布頻率: {填入預期發布頻率} CI/CD 設計要求 請按照以下結構設計 CI/CD 流程：\n1. 持續整合設計 原始碼管理策略 建置流程設計 自動化測試整合 程式碼品質門檻 2. 持續部署設計 部署策略選擇 環境管理規劃 發布流程設計 回退機制設計 3. 基礎設施管理 基礎設施即程式碼 環境配置管理 監控和告警設置 安全性配置 4. 自動化工具整合 CI/CD 工具選擇 容器化策略 編排工具配置 工具鏈整合 5. 品質和安全 程式碼掃描整合 漏洞檢測流程 合規性檢查 稽核日誌管理 6. 監控和運維 應用程式監控 基礎設施監控 日誌聚合分析 事件響應流程 輸出格式 # {專案名稱} CI/CD 流程設計 ## 1. 流程概覽 ### 1.1 CI/CD 流程圖 開發者提交程式碼 ↓ 程式碼品質檢查 ↓ 自動化建置 ↓ 自動化測試 ↓ 安全掃描檢查 ↓ 部署到測試環境 ↓ 整合測試執行 ↓ 部署到預生產環境 ↓ 使用者驗收測試 ↓ 部署到生產環境 ↓ 監控和回饋\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%83%A8%E7%BD%B2%E9%81%8B%E7%B6%AD/ci_cd%E6%B5%81%E7%A8%8B%E7%AF%84%E6%9C%AC/","summary":"CI/CD 流程範本 Prompt 目標 指導 AI 建立完整的 CI/CD 流程，包含持續整合、持續部署和基礎設施即程式碼。\n角色設定 你是一位資深 DevOps 工程師，具備豐富的 CI/CD 流程設計和實作經驗，熟悉各種自動化部署工具和雲端平台。\n任務描述 請協助我為 {專案名稱} 建立完整的 CI/CD 流程。\n專案 DevOps 背景 專案名稱: {填入專案名稱} 應用架構: {填入應用架構，如：微服務、單體應用} 技術棧: {填入技術棧} 部署平台: {填入目標平台，如：AWS、Azure、GCP、Kubernetes} 團隊規模: {填入團隊人數} 發布頻率: {填入預期發布頻率} CI/CD 設計要求 請按照以下結構設計 CI/CD 流程：\n1. 持續整合設計 原始碼管理策略 建置流程設計 自動化測試整合 程式碼品質門檻 2. 持續部署設計 部署策略選擇 環境管理規劃 發布流程設計 回退機制設計 3. 基礎設施管理 基礎設施即程式碼 環境配置管理 監控和告警設置 安全性配置 4. 自動化工具整合 CI/CD 工具選擇 容器化策略 編排工具配置 工具鏈整合 5. 品質和安全 程式碼掃描整合 漏洞檢測流程 合規性檢查 稽核日誌管理 6. 監控和運維 應用程式監控 基礎設施監控 日誌聚合分析 事件響應流程 輸出格式 # {專案名稱} CI/CD 流程設計 ## 1. 流程概覽 ### 1.1 CI/CD 流程圖 開發者提交程式碼 ↓ 程式碼品質檢查 ↓ 自動化建置 ↓ 自動化測試 ↓ 安全掃描檢查 ↓ 部署到測試環境 ↓ 整合測試執行 ↓ 部署到預生產環境 ↓ 使用者驗收測試 ↓ 部署到生產環境 ↓ 監控和回饋\n","title":"CI_CD流程範本"},{"content":"Clean Architecture 教學手冊 📖 手冊說明 本教學手冊專為新進開發同仁設計，旨在幫助您：\n理解 Clean Architecture 的核心概念與設計哲學 學會在專案中運用 Clean Architecture 進行開發 具備考取 Clean Architecture 認證的能力 📚 目錄 基礎篇：Clean Architecture 核心概念\n1.1 什麼是 Clean Architecture？ 1.2 核心原則 1.3 Clean Architecture vs 傳統架構 1.4 常見誤解與迷思 1.5 實務注意事項 架構篇：分層架構與職責\n2.1 Clean Architecture 總覽 2.2 第一層：Entities（實體層） 2.3 第二層：Use Cases（用例層） 2.4 第三層：Interface Adapters（介面適配層） 2.5 第四層：Frameworks \u0026amp; Drivers（框架與驅動層） 2.6 層間通信與依賴注入 2.7 實務注意事項 實作篇：專案範例實戰\n3.1 專案概述：會員管理系統 3.2 Domain 層實作 3.3 Use Case 層實作 3.4 Interface Adapters 層實作 3.5 實務注意事項 專案應用篇：團隊開發規範\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/clean-architecture%E6%95%99%E5%AD%B8/","summary":"Clean Architecture 教學手冊 📖 手冊說明 本教學手冊專為新進開發同仁設計，旨在幫助您：\n理解 Clean Architecture 的核心概念與設計哲學 學會在專案中運用 Clean Architecture 進行開發 具備考取 Clean Architecture 認證的能力 📚 目錄 基礎篇：Clean Architecture 核心概念\n1.1 什麼是 Clean Architecture？ 1.2 核心原則 1.3 Clean Architecture vs 傳統架構 1.4 常見誤解與迷思 1.5 實務注意事項 架構篇：分層架構與職責\n2.1 Clean Architecture 總覽 2.2 第一層：Entities（實體層） 2.3 第二層：Use Cases（用例層） 2.4 第三層：Interface Adapters（介面適配層） 2.5 第四層：Frameworks \u0026amp; Drivers（框架與驅動層） 2.6 層間通信與依賴注入 2.7 實務注意事項 實作篇：專案範例實戰\n3.1 專案概述：會員管理系統 3.2 Domain 層實作 3.3 Use Case 層實作 3.4 Interface Adapters 層實作 3.5 實務注意事項 專案應用篇：團隊開發規範\n","title":"Clean Architecture教學"},{"content":"Clean Code 教學手冊 📚 目錄 Clean Code 簡介\n1.1 什麼是 Clean Code？ 1.2 為什麼 Clean Code 重要？ 1.3 與專案品質的關係 核心原則與最佳實踐\n2.1 命名原則 2.2 函式原則 2.3 類別與物件原則 2.4 註解原則 2.5 格式化原則 2.6 錯誤處理原則 2.7 測試原則 實務範例與對照\n3.1 電商購物車範例 3.2 改善對照分析 3.3 使用者註冊系統範例 3.4 重構步驟與技巧 專案應用指引\n4.1 團隊程式碼規範 4.2 程式碼審查流程 4.3 常見反模式與改善 4.4 開發工具配置 4.5 持續整合配置 認證考試重點\n5.1 Clean Code 認證概述 5.2 核心知識點 5.3 常見考試題型 5.4 考試準備策略 5.5 考試注意事項 檢查清單\n6.1 程式碼撰寫檢查清單 6.2 程式碼品質檢查清單 6.3 重構檢查清單 6.4 團隊協作檢查清單 6.5 專案層級檢查清單 6.6 持續改進檢查清單 6.7 快速參考卡 1. Clean Code 簡介 1.1 什麼是 Clean Code？ Clean Code（乾淨程式碼） 是指易於閱讀、理解和維護的程式碼。它不僅僅是能夠運行的程式碼，更是一種追求程式碼品質的哲學。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/clean-code%E6%95%99%E5%AD%B8/","summary":"Clean Code 教學手冊 📚 目錄 Clean Code 簡介\n1.1 什麼是 Clean Code？ 1.2 為什麼 Clean Code 重要？ 1.3 與專案品質的關係 核心原則與最佳實踐\n2.1 命名原則 2.2 函式原則 2.3 類別與物件原則 2.4 註解原則 2.5 格式化原則 2.6 錯誤處理原則 2.7 測試原則 實務範例與對照\n3.1 電商購物車範例 3.2 改善對照分析 3.3 使用者註冊系統範例 3.4 重構步驟與技巧 專案應用指引\n4.1 團隊程式碼規範 4.2 程式碼審查流程 4.3 常見反模式與改善 4.4 開發工具配置 4.5 持續整合配置 認證考試重點\n5.1 Clean Code 認證概述 5.2 核心知識點 5.3 常見考試題型 5.4 考試準備策略 5.5 考試注意事項 檢查清單\n6.1 程式碼撰寫檢查清單 6.2 程式碼品質檢查清單 6.3 重構檢查清單 6.4 團隊協作檢查清單 6.5 專案層級檢查清單 6.6 持續改進檢查清單 6.7 快速參考卡 1. Clean Code 簡介 1.1 什麼是 Clean Code？ Clean Code（乾淨程式碼） 是指易於閱讀、理解和維護的程式碼。它不僅僅是能夠運行的程式碼，更是一種追求程式碼品質的哲學。\n","title":"Clean Code教學"},{"content":"Code Review 指引 目錄 前言 1.1 目的 1.2 適用範圍 1.3 Code Review 的價值 Code Review 基本原則 2.1 核心原則 2.2 責任分工 Code Review 流程 3.1 提交 Pull Request (PR) 3.2 指定 Reviewers 3.3 進行程式碼檢查 詳細檢查項目 4.1 程式碼風格與規範 4.2 邏輯正確性檢查 4.3 效能考量檢查 4.4 安全性檢查 4.5 測試覆蓋率檢查 Code Review 工具與自動化 5.1 GitHub Pull Request Review 5.2 GitLab Merge Request Review 5.3 SonarQube 程式碼品質檢查 5.4 ESLint 與 Prettier（前端） 實務操作指南 6.1 Review 意見分類與標準 6.2 常見審查重點清單 6.3 溝通技巧與最佳實務 6.4 Review 會議與討論 常見問題與解決方案 7.1 常見 Review 問題 7.2 效率提升技巧 團隊協作與衝突處理 8.1 Review 意見衝突處理 8.2 跨團隊 Review 協作 8.3 新人培訓與指導 特殊情況處理 9.1 緊急修正流程 9.2 大型重構 Review 9.3 第三方程式碼整合 持續改進與測量 10.1 Review 品質指標 10.2 流程效率分析 10.3 團隊成長追蹤 參考資源與延伸閱讀 11.1 程式碼品質標準 11.2 安全性資源 11.3 工具文件 11.4 最佳實務書籍 附錄 12.1 Review 檢查清單範本 12.2 團隊 Code Review 文化建立 1. 前言 1.1 目的 本指引旨在建立標準化的程式碼審查流程，確保所有程式碼在合併至主分支前都經過充分的檢查與評審，以提升程式碼品質、降低潛在錯誤與技術負債，並促進團隊知識分享與技能提升。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/code-review-%E6%8C%87%E5%BC%95/","summary":"Code Review 指引 目錄 前言 1.1 目的 1.2 適用範圍 1.3 Code Review 的價值 Code Review 基本原則 2.1 核心原則 2.2 責任分工 Code Review 流程 3.1 提交 Pull Request (PR) 3.2 指定 Reviewers 3.3 進行程式碼檢查 詳細檢查項目 4.1 程式碼風格與規範 4.2 邏輯正確性檢查 4.3 效能考量檢查 4.4 安全性檢查 4.5 測試覆蓋率檢查 Code Review 工具與自動化 5.1 GitHub Pull Request Review 5.2 GitLab Merge Request Review 5.3 SonarQube 程式碼品質檢查 5.4 ESLint 與 Prettier（前端） 實務操作指南 6.1 Review 意見分類與標準 6.2 常見審查重點清單 6.3 溝通技巧與最佳實務 6.4 Review 會議與討論 常見問題與解決方案 7.1 常見 Review 問題 7.2 效率提升技巧 團隊協作與衝突處理 8.1 Review 意見衝突處理 8.2 跨團隊 Review 協作 8.3 新人培訓與指導 特殊情況處理 9.1 緊急修正流程 9.2 大型重構 Review 9.3 第三方程式碼整合 持續改進與測量 10.1 Review 品質指標 10.2 流程效率分析 10.3 團隊成長追蹤 參考資源與延伸閱讀 11.1 程式碼品質標準 11.2 安全性資源 11.3 工具文件 11.4 最佳實務書籍 附錄 12.1 Review 檢查清單範本 12.2 團隊 Code Review 文化建立 1. 前言 1.1 目的 本指引旨在建立標準化的程式碼審查流程，確保所有程式碼在合併至主分支前都經過充分的檢查與評審，以提升程式碼品質、降低潛在錯誤與技術負債，並促進團隊知識分享與技能提升。\n","title":"code review 指引"},{"content":"Design Pattern（設計模式）教學手冊 📋 目錄 基礎入門\n1.1 什麼是 Design Pattern？ 1.2 為什麼要使用 Design Pattern？ 1.3 Design Pattern 的三大分類 1.4 在專案開發中的實際價值 1.5 學習路徑建議 1.6 注意事項與最佳實務 核心內容 - 創建型模式\n2.1 Singleton Pattern（單例模式） 2.2 Factory Method Pattern（工廠方法模式） 2.3 Builder Pattern（建造者模式） 2.4 Abstract Factory Pattern（抽象工廠模式） 2.5 Prototype Pattern（原型模式） 2.6 創建型模式總結 核心內容 - 結構型模式\n3.1 Adapter Pattern（適配器模式） 3.2 Decorator Pattern（裝飾者模式） 3.3 Facade Pattern（外觀模式） 3.4 Proxy Pattern（代理模式） 3.5 Composite Pattern（組合模式） 3.6 Bridge Pattern（橋接模式） 3.7 Flyweight Pattern（享元模式） 3.8 結構型模式總結 核心內容 - 行為型模式\n4.1 Observer Pattern（觀察者模式） 4.2 Strategy Pattern（策略模式） 4.3 Template Method Pattern（模板方法模式） 4.4 Command Pattern（命令模式） 4.5 State Pattern（狀態模式） 4.6 Chain of Responsibility Pattern（責任鏈模式） 4.7 Iterator Pattern（迭代器模式） 4.8 Mediator Pattern（中介者模式） 4.9 Memento Pattern（備忘錄模式） 4.10 Visitor Pattern（訪問者模式） 4.11 Interpreter Pattern（解釋器模式） 4.12 行為型模式實務應用 專案應用指南\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/design-pattern%E6%95%99%E5%AD%B8/","summary":"Design Pattern（設計模式）教學手冊 📋 目錄 基礎入門\n1.1 什麼是 Design Pattern？ 1.2 為什麼要使用 Design Pattern？ 1.3 Design Pattern 的三大分類 1.4 在專案開發中的實際價值 1.5 學習路徑建議 1.6 注意事項與最佳實務 核心內容 - 創建型模式\n2.1 Singleton Pattern（單例模式） 2.2 Factory Method Pattern（工廠方法模式） 2.3 Builder Pattern（建造者模式） 2.4 Abstract Factory Pattern（抽象工廠模式） 2.5 Prototype Pattern（原型模式） 2.6 創建型模式總結 核心內容 - 結構型模式\n3.1 Adapter Pattern（適配器模式） 3.2 Decorator Pattern（裝飾者模式） 3.3 Facade Pattern（外觀模式） 3.4 Proxy Pattern（代理模式） 3.5 Composite Pattern（組合模式） 3.6 Bridge Pattern（橋接模式） 3.7 Flyweight Pattern（享元模式） 3.8 結構型模式總結 核心內容 - 行為型模式\n4.1 Observer Pattern（觀察者模式） 4.2 Strategy Pattern（策略模式） 4.3 Template Method Pattern（模板方法模式） 4.4 Command Pattern（命令模式） 4.5 State Pattern（狀態模式） 4.6 Chain of Responsibility Pattern（責任鏈模式） 4.7 Iterator Pattern（迭代器模式） 4.8 Mediator Pattern（中介者模式） 4.9 Memento Pattern（備忘錄模式） 4.10 Visitor Pattern（訪問者模式） 4.11 Interpreter Pattern（解釋器模式） 4.12 行為型模式實務應用 專案應用指南\n","title":"Design Pattern教學"},{"content":"Design Pattern 教學手冊（二）- 進階實務應用 目錄 第 1 章：設計模式概論 第 2 章：設計模式分類與全貌 第 3 章：創建型模式 第 4 章：結構型模式 第 5 章：行為型模式 第 6 章：專案應用指南 第 7 章：學習與練習 第 8 章：認證考試準備 第 9 章：附錄與資源 第 1 章：設計模式概論 1.1 設計模式的定義與歷史背景 1.1.1 什麼是設計模式？ 設計模式（Design Pattern）是在軟體開發過程中，針對常見問題的通用解決方案。它是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。\n1.1.2 Gang of Four (GoF) 的貢獻 1994年，四位軟體工程師 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 共同撰寫了《設計模式：可複用物件導向軟體的基礎》一書，定義了23個經典設計模式，被稱為「四人幫」（Gang of Four，GoF）。\ntimeline title 設計模式發展歷程 1987 : Christopher Alexander 提出建築模式概念 1994 : GoF 發表 23 個經典設計模式 1995 : Java 語言誕生，設計模式開始普及 2000 : 企業級應用廣泛採用設計模式 2010 : Spring Framework 大量運用設計模式 2020 : 微服務架構中的設計模式應用 1.2 為什麼需要設計模式？ 1.2.1 解決重複問題 在軟體開發中，我們經常遇到相似的問題。設計模式提供了經過驗證的解決方案，避免重複造輪子。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/design-pattern%E6%95%99%E5%AD%B8%E4%BA%8C/","summary":"Design Pattern 教學手冊（二）- 進階實務應用 目錄 第 1 章：設計模式概論 第 2 章：設計模式分類與全貌 第 3 章：創建型模式 第 4 章：結構型模式 第 5 章：行為型模式 第 6 章：專案應用指南 第 7 章：學習與練習 第 8 章：認證考試準備 第 9 章：附錄與資源 第 1 章：設計模式概論 1.1 設計模式的定義與歷史背景 1.1.1 什麼是設計模式？ 設計模式（Design Pattern）是在軟體開發過程中，針對常見問題的通用解決方案。它是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。\n1.1.2 Gang of Four (GoF) 的貢獻 1994年，四位軟體工程師 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 共同撰寫了《設計模式：可複用物件導向軟體的基礎》一書，定義了23個經典設計模式，被稱為「四人幫」（Gang of Four，GoF）。\ntimeline title 設計模式發展歷程 1987 : Christopher Alexander 提出建築模式概念 1994 : GoF 發表 23 個經典設計模式 1995 : Java 語言誕生，設計模式開始普及 2000 : 企業級應用廣泛採用設計模式 2010 : Spring Framework 大量運用設計模式 2020 : 微服務架構中的設計模式應用 1.2 為什麼需要設計模式？ 1.2.1 解決重複問題 在軟體開發中，我們經常遇到相似的問題。設計模式提供了經過驗證的解決方案，避免重複造輪子。\n","title":"Design Pattern教學(二)"},{"content":"Domain-Driven Design (DDD) 教學手冊 專為新進開發同仁設計的 DDD 學習指南\n適用技術棧：Vue 3.x (前端) + Spring Boot (後端) + 前後端分離架構\n📚 目錄 DDD 基礎概念\n1.1 什麼是 Domain-Driven Design？ 1.2 DDD 核心概念概覽 1.3 DDD 的三層架構 1.4 實務案例：電商系統 核心構建塊 (Building Blocks)\n2.1 Entity (實體) 2.2 Value Object (值對象) 2.3 Aggregate (聚合) 2.4 Repository (儲存庫) 2.5 Domain Service (領域服務) 戰略設計 (Strategic Design)\n3.1 Domain、Subdomain 識別 3.2 Bounded Context (有界上下文) 3.3 Context Map (上下文映射) 3.4 Ubiquitous Language (統一語言) 3.5 Event Storming 實務應用 戰術設計 (Tactical Design)\n4.1 Domain Events (領域事件) 4.2 Factory Pattern 在 DDD 中的應用 4.3 Specification Pattern (規格模式) DDD 在專案中的實際應用\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/domain-driven-design%E6%95%99%E5%AD%B8/","summary":"Domain-Driven Design (DDD) 教學手冊 專為新進開發同仁設計的 DDD 學習指南\n適用技術棧：Vue 3.x (前端) + Spring Boot (後端) + 前後端分離架構\n📚 目錄 DDD 基礎概念\n1.1 什麼是 Domain-Driven Design？ 1.2 DDD 核心概念概覽 1.3 DDD 的三層架構 1.4 實務案例：電商系統 核心構建塊 (Building Blocks)\n2.1 Entity (實體) 2.2 Value Object (值對象) 2.3 Aggregate (聚合) 2.4 Repository (儲存庫) 2.5 Domain Service (領域服務) 戰略設計 (Strategic Design)\n3.1 Domain、Subdomain 識別 3.2 Bounded Context (有界上下文) 3.3 Context Map (上下文映射) 3.4 Ubiquitous Language (統一語言) 3.5 Event Storming 實務應用 戰術設計 (Tactical Design)\n4.1 Domain Events (領域事件) 4.2 Factory Pattern 在 DDD 中的應用 4.3 Specification Pattern (規格模式) DDD 在專案中的實際應用\n","title":"Domain-Driven Design教學"},{"content":"Domain-Driven Design 教學手冊（一） 🎯 教學目標 本教學手冊旨在幫助開發團隊成員深入理解並正確應用 Domain-Driven Design (DDD)，從基礎概念到實際應用，最終能夠通過 DDD 認證考試。\n📚 完整目錄 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 1.2 為什麼需要 DDD 1.3 與傳統開發方式的差異 💡 實務案例：電商系統設計差異 2. DDD 的核心理念 2.1 Domain（領域）的重要性 2.2 Ubiquitous Language（通用語言） 2.3 Model-Driven Design（模型驅動設計） 3. DDD 的兩大面向 3.1 戰略設計 (Strategic Design) 3.2 戰術設計 (Tactical Design) 3.3 戰略與戰術設計的關係 💯 第一篇檢查清單（Checklist） 🎓 第一篇總結 第二篇：DDD 戰略設計 (Strategic Design) 4. 子域 (Subdomain) 的分類 4.1 什麼是子域 4.2 核心領域 (Core Domain) 4.3 支援子域 (Supporting Subdomain) 4.4 通用子域 (Generic Subdomain) 4.5 子域分類實務工作坊 5. 限界上下文 (Bounded Context) 5.1 定義與識別方法 5.2 界定上下文的準則 5.3 限界上下文的邊界劃分範例 5.4 上下文大小的考量 6. 上下文映射 (Context Mapping) 6.1 Context Map 基本圖示 6.2 上下文之間的關係模式 6.3 整合模式選擇指南 7. 案例分析 7.1 如何將真實專案切分為子域與限界上下文 7.2 分析銀行/金融系統案例 💯 第二篇檢查清單（Checklist） 🎓 第二篇總結 第三篇：DDD 戰術設計 (Tactical Design) 8. 核心構件介紹 8.1 Entity（實體） 8.2 Value Object（值物件） 8.3 Aggregate（聚合）與 Aggregate Root 8.4 Repository（倉儲） 8.5 Service（領域服務 / 應用服務） 8.6 Factory（工廠） 💯 第三篇檢查清單（Checklist） 第四篇：DDD 與實務應用 9. 領域事件 (Domain Events) 9.1 什麼是領域事件 9.2 事件發布與訂閱模式 9.3 Event Sourcing 9.4 CQRS 與 DDD 的結合 10. 模組化與分層架構 10.1 DDD 分層架構 10.2 Hexagonal Architecture（六角架構） 10.3 Clean Architecture 11. 在微服務架構中的 DDD 11.1 Bounded Context 與微服務的對應 11.2 微服務邊界設計 11.3 資料一致性策略 12. 與敏捷、Scrum 的整合 12.1 Event Storming 12.2 Domain Storytelling 12.3 Scrum 中的 DDD 實踐 13. 專案最佳實踐 13.1 常見錯誤與反模式 13.2 成功案例分享 13.3 DDD 導入路線圖 💯 第四篇檢查清單（Checklist） 第五篇：學習檢測與認證準備 14. 章節小測驗 14.1 第一篇：基礎入門 - 測驗題 14.2 第二篇：戰略設計 - 測驗題 14.3 第三篇：戰術設計 - 測驗題 14.4 第四篇：實務應用 - 測驗題 15. DDD 認證考試重點整理 15.1 必考核心概念 15.2 認證準備策略 16. 模擬測驗題庫 16.1 綜合模擬試題 16.2 模擬試題答案 💯 第五篇檢查清單（Checklist） 附錄 A. 快速參考指南 A.1 DDD 核心概念速查表 B. 成功案例研究 B.1 電商平台 DDD 實施 C. 推薦資源 C.1 經典書籍 C.2 線上資源 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 Domain-Driven Design（領域驅動設計）是由 Eric Evans 在 2003 年出版的同名書籍中首次系統性提出的軟體開發方法論。DDD 的核心思想是將複雜的業務邏輯透過領域模型來表達，讓軟體設計更貼近實際業務需求。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/domain-driven-design%E6%95%99%E5%AD%B8%E4%B8%80/","summary":"Domain-Driven Design 教學手冊（一） 🎯 教學目標 本教學手冊旨在幫助開發團隊成員深入理解並正確應用 Domain-Driven Design (DDD)，從基礎概念到實際應用，最終能夠通過 DDD 認證考試。\n📚 完整目錄 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 1.2 為什麼需要 DDD 1.3 與傳統開發方式的差異 💡 實務案例：電商系統設計差異 2. DDD 的核心理念 2.1 Domain（領域）的重要性 2.2 Ubiquitous Language（通用語言） 2.3 Model-Driven Design（模型驅動設計） 3. DDD 的兩大面向 3.1 戰略設計 (Strategic Design) 3.2 戰術設計 (Tactical Design) 3.3 戰略與戰術設計的關係 💯 第一篇檢查清單（Checklist） 🎓 第一篇總結 第二篇：DDD 戰略設計 (Strategic Design) 4. 子域 (Subdomain) 的分類 4.1 什麼是子域 4.2 核心領域 (Core Domain) 4.3 支援子域 (Supporting Subdomain) 4.4 通用子域 (Generic Subdomain) 4.5 子域分類實務工作坊 5. 限界上下文 (Bounded Context) 5.1 定義與識別方法 5.2 界定上下文的準則 5.3 限界上下文的邊界劃分範例 5.4 上下文大小的考量 6. 上下文映射 (Context Mapping) 6.1 Context Map 基本圖示 6.2 上下文之間的關係模式 6.3 整合模式選擇指南 7. 案例分析 7.1 如何將真實專案切分為子域與限界上下文 7.2 分析銀行/金融系統案例 💯 第二篇檢查清單（Checklist） 🎓 第二篇總結 第三篇：DDD 戰術設計 (Tactical Design) 8. 核心構件介紹 8.1 Entity（實體） 8.2 Value Object（值物件） 8.3 Aggregate（聚合）與 Aggregate Root 8.4 Repository（倉儲） 8.5 Service（領域服務 / 應用服務） 8.6 Factory（工廠） 💯 第三篇檢查清單（Checklist） 第四篇：DDD 與實務應用 9. 領域事件 (Domain Events) 9.1 什麼是領域事件 9.2 事件發布與訂閱模式 9.3 Event Sourcing 9.4 CQRS 與 DDD 的結合 10. 模組化與分層架構 10.1 DDD 分層架構 10.2 Hexagonal Architecture（六角架構） 10.3 Clean Architecture 11. 在微服務架構中的 DDD 11.1 Bounded Context 與微服務的對應 11.2 微服務邊界設計 11.3 資料一致性策略 12. 與敏捷、Scrum 的整合 12.1 Event Storming 12.2 Domain Storytelling 12.3 Scrum 中的 DDD 實踐 13. 專案最佳實踐 13.1 常見錯誤與反模式 13.2 成功案例分享 13.3 DDD 導入路線圖 💯 第四篇檢查清單（Checklist） 第五篇：學習檢測與認證準備 14. 章節小測驗 14.1 第一篇：基礎入門 - 測驗題 14.2 第二篇：戰略設計 - 測驗題 14.3 第三篇：戰術設計 - 測驗題 14.4 第四篇：實務應用 - 測驗題 15. DDD 認證考試重點整理 15.1 必考核心概念 15.2 認證準備策略 16. 模擬測驗題庫 16.1 綜合模擬試題 16.2 模擬試題答案 💯 第五篇檢查清單（Checklist） 附錄 A. 快速參考指南 A.1 DDD 核心概念速查表 B. 成功案例研究 B.1 電商平台 DDD 實施 C. 推薦資源 C.1 經典書籍 C.2 線上資源 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 Domain-Driven Design（領域驅動設計）是由 Eric Evans 在 2003 年出版的同名書籍中首次系統性提出的軟體開發方法論。DDD 的核心思想是將複雜的業務邏輯透過領域模型來表達，讓軟體設計更貼近實際業務需求。\n","title":"Domain-Driven Design教學(一)"},{"content":"Entity-Relationship Model (ER Model) 教學手冊 📋 目錄 基礎知識\n1.1 什麼是 ER Model 1.2 核心概念 1.3 ERD 符號與規則 1.4 基礎實作練習 專案應用\n2.1 需求分析到 ER Model 2.2 案例研究：電商平台 2.3 案例研究：銀行系統 2.4 轉換為資料庫 Schema 2.5 完整專案開發流程 進階主題\n3.1 實體類型與關聯度 3.2 正規化理論 3.3 常見設計錯誤 3.4 最佳實務 認證準備\n4.1 認證內容與範圍 4.2 練習題庫 4.3 模擬考題 4.4 重點知識摘要 學習路徑\n5.1 學習步驟建議 5.2 推薦工具 5.3 進階學習資源 檢查清單\n6.1 設計階段檢查清單 6.2 資料庫實作檢查清單 6.3 品質保證檢查清單 6.4 專案交付檢查清單 6.5 學習成果檢核 6.6 持續改進檢查 附錄\nA. ERD 符號速查表 B. SQL 資料型別對照表 C. 常用正規化檢查 SQL D. 設計模式範本 E. 效能優化檢查清單 F. 安全性檢查清單 G. 版本更新記錄 🚀 快速開始 📖 學習建議 如果您是第一次接觸 ER Model，建議按照以下順序學習：\n🔰 初學者路徑（預估 2-3 週） 📚 基礎建立：先閱讀「基礎知識」章節，建立基本概念 🛠️ 實作練習：透過「專案應用」的案例練習實作 📈 深化理解：學習「進階主題」深化理解 ✅ 成果驗證：使用「檢查清單」驗證學習成果 🎯 進階用戶路徑 如果您已具備基礎概念，可直接從第 2 章「專案應用」開始 需要準備認證考試的用戶，重點關注第 4 章「認證準備」 尋找工具和資源的用戶，參考第 5 章「學習路徑」 ⏱️ 時間投入建議 基礎學習：每天 1-2 小時，持續 2-3 週 實作練習：每週 3-5 小時的專案實作 認證準備：額外 2-3 週的集中複習 1. 基礎知識 1.1 什麼是 ER Model Entity-Relationship Model（實體關係模型） 是一種用來描述現實世界資料結構的概念模型。它幫助我們：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/entity-relationship-model-er-model-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Entity-Relationship Model (ER Model) 教學手冊 📋 目錄 基礎知識\n1.1 什麼是 ER Model 1.2 核心概念 1.3 ERD 符號與規則 1.4 基礎實作練習 專案應用\n2.1 需求分析到 ER Model 2.2 案例研究：電商平台 2.3 案例研究：銀行系統 2.4 轉換為資料庫 Schema 2.5 完整專案開發流程 進階主題\n3.1 實體類型與關聯度 3.2 正規化理論 3.3 常見設計錯誤 3.4 最佳實務 認證準備\n4.1 認證內容與範圍 4.2 練習題庫 4.3 模擬考題 4.4 重點知識摘要 學習路徑\n5.1 學習步驟建議 5.2 推薦工具 5.3 進階學習資源 檢查清單\n6.1 設計階段檢查清單 6.2 資料庫實作檢查清單 6.3 品質保證檢查清單 6.4 專案交付檢查清單 6.5 學習成果檢核 6.6 持續改進檢查 附錄\nA. ERD 符號速查表 B. SQL 資料型別對照表 C. 常用正規化檢查 SQL D. 設計模式範本 E. 效能優化檢查清單 F. 安全性檢查清單 G. 版本更新記錄 🚀 快速開始 📖 學習建議 如果您是第一次接觸 ER Model，建議按照以下順序學習：\n🔰 初學者路徑（預估 2-3 週） 📚 基礎建立：先閱讀「基礎知識」章節，建立基本概念 🛠️ 實作練習：透過「專案應用」的案例練習實作 📈 深化理解：學習「進階主題」深化理解 ✅ 成果驗證：使用「檢查清單」驗證學習成果 🎯 進階用戶路徑 如果您已具備基礎概念，可直接從第 2 章「專案應用」開始 需要準備認證考試的用戶，重點關注第 4 章「認證準備」 尋找工具和資源的用戶，參考第 5 章「學習路徑」 ⏱️ 時間投入建議 基礎學習：每天 1-2 小時，持續 2-3 週 實作練習：每週 3-5 小時的專案實作 認證準備：額外 2-3 週的集中複習 1. 基礎知識 1.1 什麼是 ER Model Entity-Relationship Model（實體關係模型） 是一種用來描述現實世界資料結構的概念模型。它幫助我們：\n","title":"Entity-Relationship Model (ER Model) 教學手冊"},{"content":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/github%E4%BD%BF%E7%94%A8hugo%E5%BB%BA%E7%AB%8B%E5%80%8B%E4%BA%BA%E7%B6%B2%E9%A0%81%E6%95%99%E5%AD%B8/","summary":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","title":"GitHub使用hugo建立個人網頁教學"},{"content":"GitHub 使用教學手冊 📋 文件資訊 版本: 2.0 更新日期: 2025年8月29日 適用對象: 新進開發同仁、團隊協作開發者 維護者: 專案開發團隊 📚 目錄 Git/GitHub 基礎概念\n1.1 什麼是 Git？ 1.2 什麼是 GitHub？ 1.3 為何要使用？ 1.4 版本控制的重要性 1.5 團隊開發的挑戰 1.6 Git 的解決方案 1.7 GitHub 的附加價值 環境設定\n2.1 安裝 Git 2.2 設定個人資訊 2.3 GitHub 帳號設定 2.4 Personal Access Token 設定（替代方案） 2.5 Git 效能優化設定 基本操作流程\n3.1 Clone 專案 3.2 建立 Feature Branch 3.3 Commit Message 撰寫規範 3.4 Push 到 Remote 3.5 建立 Pull Request (PR) 3.6 Code Review 流程 3.7 Merge 規範 Git 進階操作\n4.1 Interactive Rebase 4.2 Cherry-pick 操作 4.3 Git Bisect 除錯 4.4 Stash 暫存操作 4.5 Submodule 子模組管理 4.6 Git Hooks 自動化 4.7 大型檔案處理 (LFS) 日常工作流程建議\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/github%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"GitHub 使用教學手冊 📋 文件資訊 版本: 2.0 更新日期: 2025年8月29日 適用對象: 新進開發同仁、團隊協作開發者 維護者: 專案開發團隊 📚 目錄 Git/GitHub 基礎概念\n1.1 什麼是 Git？ 1.2 什麼是 GitHub？ 1.3 為何要使用？ 1.4 版本控制的重要性 1.5 團隊開發的挑戰 1.6 Git 的解決方案 1.7 GitHub 的附加價值 環境設定\n2.1 安裝 Git 2.2 設定個人資訊 2.3 GitHub 帳號設定 2.4 Personal Access Token 設定（替代方案） 2.5 Git 效能優化設定 基本操作流程\n3.1 Clone 專案 3.2 建立 Feature Branch 3.3 Commit Message 撰寫規範 3.4 Push 到 Remote 3.5 建立 Pull Request (PR) 3.6 Code Review 流程 3.7 Merge 規範 Git 進階操作\n4.1 Interactive Rebase 4.2 Cherry-pick 操作 4.3 Git Bisect 除錯 4.4 Stash 暫存操作 4.5 Submodule 子模組管理 4.6 Git Hooks 自動化 4.7 大型檔案處理 (LFS) 日常工作流程建議\n","title":"github使用教學"},{"content":"GitLab 使用教學手冊 📋 目錄 GitLab 基本介紹\n1.1 Git vs. GitLab - 基本概念 1.2 為什麼選擇 GitLab？ 1.3 專案架構概覽 1.4 GitLab 核心功能詳解 專案工作流程說明\n2.1 環境準備 2.2 Clone - 複製專案到本地 2.3 Pull - 同步遠端更新 2.4 Commit - 提交變更 2.5 Push - 推送變更到遠端 2.6 Merge Request - 合併請求 專案開發規範\n3.1 分支策略 3.2 Commit Message 規範 3.3 Merge Request 流程 3.4 Code Review 要求 GitLab CI/CD 基本介紹\n4.1 CI/CD 概念說明 4.2 GitLab CI/CD 架構 4.3 .gitlab-ci.yml 設定檔 4.4 Java 專案 CI/CD 設定 4.5 常用 CI/CD 指令 4.6 本專案的 CI/CD 應用 常見問題與解決方式\n5.1 Merge 衝突處理 5.2 錯誤回復方式 5.3 分支管理問題 5.4 權限和認證問題 5.5 效能和同步問題 5.6 CI/CD Pipeline 問題 5.7 團隊協作問題 開發最佳實務建議\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/gitlab%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"GitLab 使用教學手冊 📋 目錄 GitLab 基本介紹\n1.1 Git vs. GitLab - 基本概念 1.2 為什麼選擇 GitLab？ 1.3 專案架構概覽 1.4 GitLab 核心功能詳解 專案工作流程說明\n2.1 環境準備 2.2 Clone - 複製專案到本地 2.3 Pull - 同步遠端更新 2.4 Commit - 提交變更 2.5 Push - 推送變更到遠端 2.6 Merge Request - 合併請求 專案開發規範\n3.1 分支策略 3.2 Commit Message 規範 3.3 Merge Request 流程 3.4 Code Review 要求 GitLab CI/CD 基本介紹\n4.1 CI/CD 概念說明 4.2 GitLab CI/CD 架構 4.3 .gitlab-ci.yml 設定檔 4.4 Java 專案 CI/CD 設定 4.5 常用 CI/CD 指令 4.6 本專案的 CI/CD 應用 常見問題與解決方式\n5.1 Merge 衝突處理 5.2 錯誤回復方式 5.3 分支管理問題 5.4 權限和認證問題 5.5 效能和同步問題 5.6 CI/CD Pipeline 問題 5.7 團隊協作問題 開發最佳實務建議\n","title":"GitLab使用教學"},{"content":"專案 Git 教學手冊 目錄 Git 基本觀念\n1.1 什麼是版本控制？ 1.2 為什麼使用 Git？ 1.3 Git 基本概念 實務提醒 第1章實作練習 環境設定\n2.1 Git 安裝 2.2 基本設定 2.3 個人與公司帳號區隔 2.4 SSH 金鑰設定 2.5 HTTPS vs SSH 選擇 2.6 Java 開發環境整合配置 實務建議 第2章實作練習 專案流程\n3.1 如何 Clone 專案 3.2 分支策略與命名規範 3.3 Commit Message 規範 3.4 Pull / Fetch / Merge / Rebase 使用時機 3.5 Push 前檢查事項 3.6 衝突處理 團隊協作\n4.1 Pull Request (PR) / Merge Request (MR) 流程 4.2 Code Review 規範 4.3 分支保護規則 4.4 工作流程最佳實務 常見錯誤排解\n5.1 誤 Push 的處理 5.2 Commit 錯誤訊息修正 5.3 Reset vs Revert 使用時機 5.4 分支相關問題 5.5 合併問題解決 5.6 遠端倉庫問題 最佳實務\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/git%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"專案 Git 教學手冊 目錄 Git 基本觀念\n1.1 什麼是版本控制？ 1.2 為什麼使用 Git？ 1.3 Git 基本概念 實務提醒 第1章實作練習 環境設定\n2.1 Git 安裝 2.2 基本設定 2.3 個人與公司帳號區隔 2.4 SSH 金鑰設定 2.5 HTTPS vs SSH 選擇 2.6 Java 開發環境整合配置 實務建議 第2章實作練習 專案流程\n3.1 如何 Clone 專案 3.2 分支策略與命名規範 3.3 Commit Message 規範 3.4 Pull / Fetch / Merge / Rebase 使用時機 3.5 Push 前檢查事項 3.6 衝突處理 團隊協作\n4.1 Pull Request (PR) / Merge Request (MR) 流程 4.2 Code Review 規範 4.3 分支保護規則 4.4 工作流程最佳實務 常見錯誤排解\n5.1 誤 Push 的處理 5.2 Commit 錯誤訊息修正 5.3 Reset vs Revert 使用時機 5.4 分支相關問題 5.5 合併問題解決 5.6 遠端倉庫問題 最佳實務\n","title":"git使用教學"},{"content":"Hexagonal Architecture 設計教學手冊 📚 文件說明 本教學手冊旨在幫助新進同仁快速理解和應用 Hexagonal Architecture（六邊形架構）。透過循序漸進的方式，從基礎概念到實務應用，讓團隊成員能夠有效地運用這種架構模式進行軟體開發。\n🎯 學習目標 理解 Hexagonal Architecture 的核心概念與設計理念 掌握 Ports \u0026amp; Adapters 模式的實作技巧 學會在實際專案中導入六邊形架構 提升程式碼的可測試性與可維護性 建立與團隊協作的共同語言 📖 目錄 Part 1. 基礎概念 認識 Hexagonal Architecture（六邊形架構）\n1.1 Hexagonal 的由來與核心理念 1.2 與傳統分層架構的比較 1.3 Ports \u0026amp; Adapters 模式的核心概念 Hexagonal Architecture 的設計目標\n2.1 解耦業務邏輯與基礎設施 2.2 減少技術債務與提升可測試性 2.3 支援 Domain-Driven Design 的角色 Hexagonal 與其他架構模式的關係\n3.1 與 Clean Architecture 的異同 3.2 與 Onion Architecture 的異同 3.3 適用場景與限制 Part 2. 核心組件與實作模式 Ports \u0026amp; Adapters 詳解\n4.1 定義與職責 4.2 輸入 Port / 輸出 Port 4.3 主動 Adapter / 被動 Adapter Domain 層的角色\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/hexagonal-architecture%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Hexagonal Architecture 設計教學手冊 📚 文件說明 本教學手冊旨在幫助新進同仁快速理解和應用 Hexagonal Architecture（六邊形架構）。透過循序漸進的方式，從基礎概念到實務應用，讓團隊成員能夠有效地運用這種架構模式進行軟體開發。\n🎯 學習目標 理解 Hexagonal Architecture 的核心概念與設計理念 掌握 Ports \u0026amp; Adapters 模式的實作技巧 學會在實際專案中導入六邊形架構 提升程式碼的可測試性與可維護性 建立與團隊協作的共同語言 📖 目錄 Part 1. 基礎概念 認識 Hexagonal Architecture（六邊形架構）\n1.1 Hexagonal 的由來與核心理念 1.2 與傳統分層架構的比較 1.3 Ports \u0026amp; Adapters 模式的核心概念 Hexagonal Architecture 的設計目標\n2.1 解耦業務邏輯與基礎設施 2.2 減少技術債務與提升可測試性 2.3 支援 Domain-Driven Design 的角色 Hexagonal 與其他架構模式的關係\n3.1 與 Clean Architecture 的異同 3.2 與 Onion Architecture 的異同 3.3 適用場景與限制 Part 2. 核心組件與實作模式 Ports \u0026amp; Adapters 詳解\n4.1 定義與職責 4.2 輸入 Port / 輸出 Port 4.3 主動 Adapter / 被動 Adapter Domain 層的角色\n","title":"Hexagonal Architecture設計教學"},{"content":"HTML5 與 CSS3 程式語言教學手冊 目錄 前言 開發環境設定 HTML5 開發規範 CSS3 開發規範 專案中的命名規則與檔案結構 CSS 動畫與轉場效果 HTML5 新特性與 API JavaScript 整合與互動 網頁無障礙設計 常見錯誤與解決方法 開發最佳實務 範例程式碼 結語 檢查清單 1. 前言 1.1 HTML5 與 CSS3 在專案中的角色 HTML5 和 CSS3 是現代網頁開發的基石，在我們的專案中扮演著至關重要的角色：\nHTML5 的角色 結構定義者：負責網頁內容的語意化結構 互動基礎：提供表單、多媒體等互動元素 可及性保障：確保網站對所有使用者都能順利存取 SEO 基礎：良好的 HTML 結構有助於搜尋引擎優化 CSS3 的角色 視覺呈現：控制網頁的外觀與佈局 使用者體驗：創造流暢的動畫與互動效果 響應式設計：確保在各種裝置上都有良好的顯示效果 效能優化：減少不必要的圖片使用，提升載入速度 1.2 重要性 在現代網頁開發中，HTML5 和 CSS3 的重要性體現在：\n標準化：遵循 W3C 標準，確保跨瀏覽器相容性 可維護性：良好的結構和命名規則讓程式碼易於維護 效能：正確使用能大幅提升網頁載入速度 可及性：符合無障礙設計標準，服務更多使用者 SEO 優化：語意化的 HTML 有助於搜尋引擎理解內容 2. 開發環境設定 2.1 必要工具 2.1.1 程式碼編輯器 推薦：Visual Studio Code\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/html5%E8%88%87css3%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"HTML5 與 CSS3 程式語言教學手冊 目錄 前言 開發環境設定 HTML5 開發規範 CSS3 開發規範 專案中的命名規則與檔案結構 CSS 動畫與轉場效果 HTML5 新特性與 API JavaScript 整合與互動 網頁無障礙設計 常見錯誤與解決方法 開發最佳實務 範例程式碼 結語 檢查清單 1. 前言 1.1 HTML5 與 CSS3 在專案中的角色 HTML5 和 CSS3 是現代網頁開發的基石，在我們的專案中扮演著至關重要的角色：\nHTML5 的角色 結構定義者：負責網頁內容的語意化結構 互動基礎：提供表單、多媒體等互動元素 可及性保障：確保網站對所有使用者都能順利存取 SEO 基礎：良好的 HTML 結構有助於搜尋引擎優化 CSS3 的角色 視覺呈現：控制網頁的外觀與佈局 使用者體驗：創造流暢的動畫與互動效果 響應式設計：確保在各種裝置上都有良好的顯示效果 效能優化：減少不必要的圖片使用，提升載入速度 1.2 重要性 在現代網頁開發中，HTML5 和 CSS3 的重要性體現在：\n標準化：遵循 W3C 標準，確保跨瀏覽器相容性 可維護性：良好的結構和命名規則讓程式碼易於維護 效能：正確使用能大幅提升網頁載入速度 可及性：符合無障礙設計標準，服務更多使用者 SEO 優化：語意化的 HTML 有助於搜尋引擎理解內容 2. 開發環境設定 2.1 必要工具 2.1.1 程式碼編輯器 推薦：Visual Studio Code\n","title":"HTML5與CSS3程式語言教學"},{"content":"IntelliJ IDEA Community Edition 使用教學手冊 文件資訊 版本: 1.0 建立日期: 2025年8月29日 適用對象: Java 後端開發新進人員 IDE 版本: IntelliJ IDEA Community Edition 2023.3+ 目錄 IntelliJ IDEA CE 下載與安裝\n1.1 下載 IntelliJ IDEA Community Edition 1.2 安裝步驟 1.3 首次啟動設定 1.4 授權與隱私設定 開發環境基本設定\n2.1 JDK 設定 2.2 Maven 整合設定 2.3 編碼設定 2.4 Code Style 設定 2.5 檢查器設定 匯入專案與建立新專案\n3.1 匯入現有專案 3.2 建立新專案 3.3 專案設定優化 與 Git/GitHub/GitLab 的整合\n4.1 Git 基本設定 4.2 本地版本控制操作 4.3 遠端儲存庫整合 4.4 分支管理 4.5 處理合併衝突 4.6 Pull Request / Merge Request 管理 專案編譯與執行\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/intellij-idea-community-edition%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"IntelliJ IDEA Community Edition 使用教學手冊 文件資訊 版本: 1.0 建立日期: 2025年8月29日 適用對象: Java 後端開發新進人員 IDE 版本: IntelliJ IDEA Community Edition 2023.3+ 目錄 IntelliJ IDEA CE 下載與安裝\n1.1 下載 IntelliJ IDEA Community Edition 1.2 安裝步驟 1.3 首次啟動設定 1.4 授權與隱私設定 開發環境基本設定\n2.1 JDK 設定 2.2 Maven 整合設定 2.3 編碼設定 2.4 Code Style 設定 2.5 檢查器設定 匯入專案與建立新專案\n3.1 匯入現有專案 3.2 建立新專案 3.3 專案設定優化 與 Git/GitHub/GitLab 的整合\n4.1 Git 基本設定 4.2 本地版本控制操作 4.3 遠端儲存庫整合 4.4 分支管理 4.5 處理合併衝突 4.6 Pull Request / Merge Request 管理 專案編譯與執行\n","title":"IntelliJ IDEA Community Edition使用教學"},{"content":"Java 程式語言教學手冊 目錄 Java 語言簡介\n1.1 Java 的歷史與特性 1.2 為什麼專案使用 Java 1.3 Java 認證路線簡介 1.4 認證考點提醒 1.5 小練習 開發環境與工具\n2.1 JDK 安裝（Java 21） 2.2 IDE 設定 2.3 Build 工具 2.4 認證考點提醒 2.5 小練習 Java 基礎語法\n3.1 Hello World 程式 3.2 基本資料型別、變數、常數 3.3 運算子與型別轉換 3.4 流程控制 3.5 陣列操作 3.6 字串處理 3.7 認證考點提醒 3.8 小練習 物件導向程式設計 (OOP)\n4.1 類別與物件 4.2 建構子與方法 4.3 繼承 (Inheritance) 4.4 多型 (Polymorphism) 4.5 封裝 (Encapsulation) 4.6 抽象類別與介面 4.7 認證考點提醒 4.8 小練習 核心 API 與工具\n5.1 集合框架 (Collections Framework) 5.2 泛型 (Generics) 5.3 日期時間 API 5.4 檔案 I/O 操作 5.5 正規表達式 5.6 認證考點提醒 5.7 小練習 例外處理與錯誤管理\n6.1 例外處理機制 6.2 自訂例外 6.3 最佳實務 6.4 認證考點提醒 6.5 小練習 進階語法與認證內容\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/java%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"Java 程式語言教學手冊 目錄 Java 語言簡介\n1.1 Java 的歷史與特性 1.2 為什麼專案使用 Java 1.3 Java 認證路線簡介 1.4 認證考點提醒 1.5 小練習 開發環境與工具\n2.1 JDK 安裝（Java 21） 2.2 IDE 設定 2.3 Build 工具 2.4 認證考點提醒 2.5 小練習 Java 基礎語法\n3.1 Hello World 程式 3.2 基本資料型別、變數、常數 3.3 運算子與型別轉換 3.4 流程控制 3.5 陣列操作 3.6 字串處理 3.7 認證考點提醒 3.8 小練習 物件導向程式設計 (OOP)\n4.1 類別與物件 4.2 建構子與方法 4.3 繼承 (Inheritance) 4.4 多型 (Polymorphism) 4.5 封裝 (Encapsulation) 4.6 抽象類別與介面 4.7 認證考點提醒 4.8 小練習 核心 API 與工具\n5.1 集合框架 (Collections Framework) 5.2 泛型 (Generics) 5.3 日期時間 API 5.4 檔案 I/O 操作 5.5 正規表達式 5.6 認證考點提醒 5.7 小練習 例外處理與錯誤管理\n6.1 例外處理機制 6.2 自訂例外 6.3 最佳實務 6.4 認證考點提醒 6.5 小練習 進階語法與認證內容\n","title":"Java程式語言教學"},{"content":"以下是完整的 《JdbcTemplate 安全 SQL 實作指引文件》Markdown 版本，可直接放入你的 Git Repository（例如 /docs/security/jdbctemplate-sql-guideline.md），作為團隊安全規範或 Code Review checklist 使用。\n# 🧭 JdbcTemplate 安全 SQL 實作指引文件 **版本：v1.0** **適用範圍：** Spring Boot 專案中使用 `JdbcTemplate` 或 `NamedParameterJdbcTemplate` 的資料存取層 **目的：** 防止 SQL Injection 攻擊與弱掃誤判 --- ## 1️⃣ 目的與原則 SQL Injection（SQL 注入）是 OWASP Top 10 的主要風險之一。 若在 API 中直接拼接 SQL 字串（尤其包含前端輸入），將導致弱掃報告出現 Injection 問題，甚至被惡意利用。 **安全實作原則：** 1. 所有 SQL 查詢必須採用 **參數化查詢（Parameterized Query）**。 2. 不可直接拼接使用者輸入字串到 SQL。 3. 動態欄位或排序需求必須使用 **白名單機制（Whitelist）**。 4. 禁止讓 client 直接傳入完整 SQL。 5. 所有 DB 帳號採用最小權限原則（Least Privilege）。 --- ## 2️⃣ 正確安全作法範例 ### ✅ 查詢範例 ```java String sql = \u0026#34;SELECT id, name, email FROM users WHERE email = ?\u0026#34;; return jdbcTemplate.query(sql, new Object[]{email}, new UserRowMapper()); ✅ 插入範例 String sql = \u0026#34;INSERT INTO users (name, email) VALUES (?, ?)\u0026#34;; jdbcTemplate.update(sql, name, email); ✅ 更新範例 String sql = \u0026#34;UPDATE users SET status = ? WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, status, id); ✅ 刪除範例 String sql = \u0026#34;DELETE FROM users WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, id); ✅ 動態查詢（條件可變） 重點：條件以程式判斷拼接，但參數仍使用 ? 綁定。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/jdbctemplate-%E5%AE%89%E5%85%A8-sql-%E5%AF%A6%E4%BD%9C%E6%8C%87%E5%BC%95%E6%96%87%E4%BB%B6/","summary":"以下是完整的 《JdbcTemplate 安全 SQL 實作指引文件》Markdown 版本，可直接放入你的 Git Repository（例如 /docs/security/jdbctemplate-sql-guideline.md），作為團隊安全規範或 Code Review checklist 使用。\n# 🧭 JdbcTemplate 安全 SQL 實作指引文件 **版本：v1.0** **適用範圍：** Spring Boot 專案中使用 `JdbcTemplate` 或 `NamedParameterJdbcTemplate` 的資料存取層 **目的：** 防止 SQL Injection 攻擊與弱掃誤判 --- ## 1️⃣ 目的與原則 SQL Injection（SQL 注入）是 OWASP Top 10 的主要風險之一。 若在 API 中直接拼接 SQL 字串（尤其包含前端輸入），將導致弱掃報告出現 Injection 問題，甚至被惡意利用。 **安全實作原則：** 1. 所有 SQL 查詢必須採用 **參數化查詢（Parameterized Query）**。 2. 不可直接拼接使用者輸入字串到 SQL。 3. 動態欄位或排序需求必須使用 **白名單機制（Whitelist）**。 4. 禁止讓 client 直接傳入完整 SQL。 5. 所有 DB 帳號採用最小權限原則（Least Privilege）。 --- ## 2️⃣ 正確安全作法範例 ### ✅ 查詢範例 ```java String sql = \u0026#34;SELECT id, name, email FROM users WHERE email = ?\u0026#34;; return jdbcTemplate.query(sql, new Object[]{email}, new UserRowMapper()); ✅ 插入範例 String sql = \u0026#34;INSERT INTO users (name, email) VALUES (?, ?)\u0026#34;; jdbcTemplate.update(sql, name, email); ✅ 更新範例 String sql = \u0026#34;UPDATE users SET status = ? WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, status, id); ✅ 刪除範例 String sql = \u0026#34;DELETE FROM users WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, id); ✅ 動態查詢（條件可變） 重點：條件以程式判斷拼接，但參數仍使用 ? 綁定。\n","title":"JdbcTemplate 安全 SQL 實作指引文件"},{"content":"Jenkins CI/CD 教學手冊 📋 目錄 (Table of Contents) 第一部分：基礎概念與環境建置 Jenkins 簡介與核心概念 環境安裝與基本設定 Jenkins 介面導覽 Plugin 管理與基礎設定 第二部分：Job 建立與管理 Freestyle Project 入門 憑證與密碼管理 Git 整合與版本控制 Maven 建置整合 第三部分：Pipeline 進階應用 Pipeline 基礎與 Declarative Syntax Jenkinsfile 結構深度分析 測試報告與程式碼覆蓋率整合 靜態程式碼分析與品質檢查 第四部分：進階功能與故障排除 Pipeline 故障排除與除錯技巧 部署策略與環境管理 監控、通知與效能優化 第五部分：企業級應用與最佳實務 企業級 CI/CD 架構設計 容器化與雲端整合 DevOps 文化與實務 實務案例研究 附錄 附錄 A：常用指令參考 A.1 Jenkins CLI 指令 A.2 Git 整合指令 A.3 Docker 容器指令 A.4 Kubernetes 部署指令 附錄 B：配置範例 B.1 Jenkins 系統配置範例 B.2 多環境配置範例 B.3 安全配置範例 附錄 C：故障排除指南 C.1 常見 Jenkins 問題 C.2 網路連接問題 C.3 Docker 建置問題 C.4 性能調優指南 附錄 D：最佳實踐清單 D.1 安全最佳實踐 D.2 效能最佳實踐 D.3 維護最佳實踐 附錄 E：工具和資源 E.1 推薦工具清單 E.2 學習資源 附錄 F：認證考試對照 F.1 Jenkins 認證考試對應 F.2 相關技術認證 附錄 G：版本更新歷史 📖 教學手冊說明 🎯 學習目標 本教學手冊旨在幫助新進 Java 開發者從零開始學習 Jenkins 與 CI/CD 自動化流程，涵蓋從基礎概念到實務應用的完整知識體系。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/jenkins-ci_cd-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Jenkins CI/CD 教學手冊 📋 目錄 (Table of Contents) 第一部分：基礎概念與環境建置 Jenkins 簡介與核心概念 環境安裝與基本設定 Jenkins 介面導覽 Plugin 管理與基礎設定 第二部分：Job 建立與管理 Freestyle Project 入門 憑證與密碼管理 Git 整合與版本控制 Maven 建置整合 第三部分：Pipeline 進階應用 Pipeline 基礎與 Declarative Syntax Jenkinsfile 結構深度分析 測試報告與程式碼覆蓋率整合 靜態程式碼分析與品質檢查 第四部分：進階功能與故障排除 Pipeline 故障排除與除錯技巧 部署策略與環境管理 監控、通知與效能優化 第五部分：企業級應用與最佳實務 企業級 CI/CD 架構設計 容器化與雲端整合 DevOps 文化與實務 實務案例研究 附錄 附錄 A：常用指令參考 A.1 Jenkins CLI 指令 A.2 Git 整合指令 A.3 Docker 容器指令 A.4 Kubernetes 部署指令 附錄 B：配置範例 B.1 Jenkins 系統配置範例 B.2 多環境配置範例 B.3 安全配置範例 附錄 C：故障排除指南 C.1 常見 Jenkins 問題 C.2 網路連接問題 C.3 Docker 建置問題 C.4 性能調優指南 附錄 D：最佳實踐清單 D.1 安全最佳實踐 D.2 效能最佳實踐 D.3 維護最佳實踐 附錄 E：工具和資源 E.1 推薦工具清單 E.2 學習資源 附錄 F：認證考試對照 F.1 Jenkins 認證考試對應 F.2 相關技術認證 附錄 G：版本更新歷史 📖 教學手冊說明 🎯 學習目標 本教學手冊旨在幫助新進 Java 開發者從零開始學習 Jenkins 與 CI/CD 自動化流程，涵蓋從基礎概念到實務應用的完整知識體系。\n","title":"Jenkins CI_CD 教學手冊"},{"content":"Linux 使用教學 專案開發環境導向 + 認證準備指南\n適用於 Java 開發專案團隊的 Linux 學習手冊\n📋 目錄 1. 前言 1.1 本手冊目的 1.2 適用對象 1.3 專案環境說明 1.4 學習方法與建議 2. Linux 基礎概念 2.1 Linux 與開源精神簡介 2.2 Linux 系統架構 2.3 檔案系統階層結構 2.4 使用者與群組管理 2.5 檔案與目錄權限 3. Linux 常用指令 3.1 檔案與目錄操作 3.2 檔案檢視與搜尋 3.3 檔案壓縮與解壓縮 3.4 權限管理 3.5 程序管理 3.6 網路工具 3.7 軟體管理 4. 開發環境操作 4.1 安裝與設定 JDK 4.2 安裝與設定 Python 4.3 安裝與設定 Node.js 4.4 資料庫客戶端 4.5 使用 Git 與 GitLab/GitHub 4.6 容器化開發工具 4.7 Maven/Gradle 編譯與部署 5. 專案日常任務 5.1 SSH 遠端登入 5.2 檔案傳輸 5.3 Log 查詢與分析 5.4 錯誤排查技巧 5.5 排程任務 6. Linux 系統安全與最佳實務 6.1 sudo 與使用者權限控管 6.2 SSH 安全性 6.3 防火牆設定 6.4 SELinux / AppArmor 基本操作 7. CI/CD 與 Linux 整合 7.1 Jenkins 於 Linux 的安裝與設定 7.2 Jenkins Pipeline 與 Shell Script 7.3 Linux 與容器整合 7.4 自動化部署流程範例 8. Linux 認證導向補充 8.1 認證體系概覽 8.2 LFCS (Linux Foundation Certified System Administrator) 8.3 RHCSA (Red Hat Certified System Administrator) 8.4 LPI (Linux Professional Institute) 認證 8.5 認證準備策略 9. 附錄與總結 9.1 學習路徑總結 9.2 常見問題與解答 (FAQ) 9.3 實務檢查清單 9.4 進階學習資源 9.5 職涯發展指南 9.6 結語與展望 1. 前言 1.1 本手冊目的 📖 為什麼需要這份手冊？\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/linux%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Linux 使用教學 專案開發環境導向 + 認證準備指南\n適用於 Java 開發專案團隊的 Linux 學習手冊\n📋 目錄 1. 前言 1.1 本手冊目的 1.2 適用對象 1.3 專案環境說明 1.4 學習方法與建議 2. Linux 基礎概念 2.1 Linux 與開源精神簡介 2.2 Linux 系統架構 2.3 檔案系統階層結構 2.4 使用者與群組管理 2.5 檔案與目錄權限 3. Linux 常用指令 3.1 檔案與目錄操作 3.2 檔案檢視與搜尋 3.3 檔案壓縮與解壓縮 3.4 權限管理 3.5 程序管理 3.6 網路工具 3.7 軟體管理 4. 開發環境操作 4.1 安裝與設定 JDK 4.2 安裝與設定 Python 4.3 安裝與設定 Node.js 4.4 資料庫客戶端 4.5 使用 Git 與 GitLab/GitHub 4.6 容器化開發工具 4.7 Maven/Gradle 編譯與部署 5. 專案日常任務 5.1 SSH 遠端登入 5.2 檔案傳輸 5.3 Log 查詢與分析 5.4 錯誤排查技巧 5.5 排程任務 6. Linux 系統安全與最佳實務 6.1 sudo 與使用者權限控管 6.2 SSH 安全性 6.3 防火牆設定 6.4 SELinux / AppArmor 基本操作 7. CI/CD 與 Linux 整合 7.1 Jenkins 於 Linux 的安裝與設定 7.2 Jenkins Pipeline 與 Shell Script 7.3 Linux 與容器整合 7.4 自動化部署流程範例 8. Linux 認證導向補充 8.1 認證體系概覽 8.2 LFCS (Linux Foundation Certified System Administrator) 8.3 RHCSA (Red Hat Certified System Administrator) 8.4 LPI (Linux Professional Institute) 認證 8.5 認證準備策略 9. 附錄與總結 9.1 學習路徑總結 9.2 常見問題與解答 (FAQ) 9.3 實務檢查清單 9.4 進階學習資源 9.5 職涯發展指南 9.6 結語與展望 1. 前言 1.1 本手冊目的 📖 為什麼需要這份手冊？\n","title":"Linux使用教學"},{"content":"Microservices Architecture 設計教學手冊 版本： 1.0\n更新日期： 2025年9月20日\n適用對象： 新進開發同仁\n編寫者： 系統架構師團隊\n📖 手冊簡介 本手冊是為新進開發同仁設計的微服務架構（Microservices Architecture）實務教學文件。透過系統性的學習路徑，幫助開發人員從零基礎逐步掌握微服務設計與實作技能。\n🎯 學習目標 完成本手冊學習後，您將能夠：\n理解微服務架構的核心概念與設計原則 掌握微服務拆分與邊界劃分技巧 熟練應用各種微服務設計模式 具備實際專案開發與維護能力 通過相關技術認證考試 🚀 使用方式 循序漸進：按照章節順序學習，每章都有前置知識 理論實作並重：理解概念後立即進行實作練習 檢查清單驗證：每章結束使用檢查清單自我驗證 團隊討論：與同事分享學習心得，加深理解 📚 目錄 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 1.2 單體架構 vs. 微服務架構 1.3 微服務的核心特徵 1.4 適用與不適用場景 2. 微服務與業界標準 2.1 SOA 與微服務的差異 2.2 Cloud Native 與微服務 2.3 與 Microservices Architecture 認證的關聯 Part II. 微服務設計原則 3. 微服務設計的基本原則 3.1 單一職責原則 (SRP) 3.2 高內聚、低耦合 3.3 獨立部署與擴展 3.4 容錯與恢復能力 4. 微服務邊界劃分 4.1 領域驅動設計 (DDD) 基礎 4.2 限界上下文 (Bounded Context) 4.3 服務拆分策略 Part III. 技術架構 5. 微服務通訊模式 5.1 同步通訊 5.2 非同步通訊 5.3 事件驅動架構 6. 資料管理策略 7. 配置與服務發現 Part IV. 微服務設計模式 8. 分解模式 8.1 Database per Service Pattern 8.2 Strangler Fig Pattern 8.3 Self-Contained Service Pattern 9. 通訊模式 9.1 API Gateway Pattern 9.2 Backend for Frontend (BFF) Pattern 10. 資料管理模式 10.1 Saga Pattern 10.2 CQRS Pattern 10.3 Event Sourcing Pattern 11. 可靠性模式 11.1 Circuit Breaker Pattern 11.2 Retry Pattern 11.3 Bulkhead Pattern Part V. 跨領域關注點 12. 安全性架構 12.1 身份驗證與授權 12.2 資料保護與加密 13. 監控與可觀察性 13.1 分散式追蹤 13.2 指標收集與監控 13.3 健康檢查與服務探測 14. 配置管理 14.1 集中化配置管理 14.2 功能開關 (Feature Toggles) Part VI. DevOps 與微服務 15. CI/CD 流水線 16. 容器化與 Kubernetes 17. Infrastructure as Code Part VII. 實戰指南 18. 微服務專案規劃 19. 實作步驟與最佳實務 20. 測試策略 21. 效能調優 Part VIII. 總結與資源 總結 最佳實務摘要 延伸學習資源 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 🔍 單體架構的挑戰 在傳統的單體架構（Monolithic Architecture）中，整個應用程式被打包成一個單一的部署單元。隨著業務成長，會面臨以下問題：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/microservices-architecture-%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Microservices Architecture 設計教學手冊 版本： 1.0\n更新日期： 2025年9月20日\n適用對象： 新進開發同仁\n編寫者： 系統架構師團隊\n📖 手冊簡介 本手冊是為新進開發同仁設計的微服務架構（Microservices Architecture）實務教學文件。透過系統性的學習路徑，幫助開發人員從零基礎逐步掌握微服務設計與實作技能。\n🎯 學習目標 完成本手冊學習後，您將能夠：\n理解微服務架構的核心概念與設計原則 掌握微服務拆分與邊界劃分技巧 熟練應用各種微服務設計模式 具備實際專案開發與維護能力 通過相關技術認證考試 🚀 使用方式 循序漸進：按照章節順序學習，每章都有前置知識 理論實作並重：理解概念後立即進行實作練習 檢查清單驗證：每章結束使用檢查清單自我驗證 團隊討論：與同事分享學習心得，加深理解 📚 目錄 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 1.2 單體架構 vs. 微服務架構 1.3 微服務的核心特徵 1.4 適用與不適用場景 2. 微服務與業界標準 2.1 SOA 與微服務的差異 2.2 Cloud Native 與微服務 2.3 與 Microservices Architecture 認證的關聯 Part II. 微服務設計原則 3. 微服務設計的基本原則 3.1 單一職責原則 (SRP) 3.2 高內聚、低耦合 3.3 獨立部署與擴展 3.4 容錯與恢復能力 4. 微服務邊界劃分 4.1 領域驅動設計 (DDD) 基礎 4.2 限界上下文 (Bounded Context) 4.3 服務拆分策略 Part III. 技術架構 5. 微服務通訊模式 5.1 同步通訊 5.2 非同步通訊 5.3 事件驅動架構 6. 資料管理策略 7. 配置與服務發現 Part IV. 微服務設計模式 8. 分解模式 8.1 Database per Service Pattern 8.2 Strangler Fig Pattern 8.3 Self-Contained Service Pattern 9. 通訊模式 9.1 API Gateway Pattern 9.2 Backend for Frontend (BFF) Pattern 10. 資料管理模式 10.1 Saga Pattern 10.2 CQRS Pattern 10.3 Event Sourcing Pattern 11. 可靠性模式 11.1 Circuit Breaker Pattern 11.2 Retry Pattern 11.3 Bulkhead Pattern Part V. 跨領域關注點 12. 安全性架構 12.1 身份驗證與授權 12.2 資料保護與加密 13. 監控與可觀察性 13.1 分散式追蹤 13.2 指標收集與監控 13.3 健康檢查與服務探測 14. 配置管理 14.1 集中化配置管理 14.2 功能開關 (Feature Toggles) Part VI. DevOps 與微服務 15. CI/CD 流水線 16. 容器化與 Kubernetes 17. Infrastructure as Code Part VII. 實戰指南 18. 微服務專案規劃 19. 實作步驟與最佳實務 20. 測試策略 21. 效能調優 Part VIII. 總結與資源 總結 最佳實務摘要 延伸學習資源 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 🔍 單體架構的挑戰 在傳統的單體架構（Monolithic Architecture）中，整個應用程式被打包成一個單一的部署單元。隨著業務成長，會面臨以下問題：\n","title":"Microservices Architecture 設計教學"},{"content":"Object-Relational Mapping (ORM) 物件關聯對映教學手冊 目錄 ORM 簡介\n1.1 什麼是 ORM？ 1.2 為什麼需要 ORM？ 1.3 ORM 解決的問題 1.4 與 SQL/資料庫互動的關係 1.5 小結 ORM 的基本概念\n2.1 實體 (Entity) 2.2 對應 (Mapping) 2.3 Session/EntityManager 2.4 Transaction (交易) 2.5 Lazy Loading vs Eager Loading 2.6 小結 ORM 工具與框架簡介\n3.1 Java 生態系統 3.2 Python 生態系統 3.3 其他語言的 ORM 框架 3.4 ORM 框架比較 3.5 選擇 ORM 框架的考量因素 3.6 小結 安裝與設定\n4.1 Java 環境設定 (Spring Boot + JPA) 4.2 Python 環境設定 (SQLAlchemy) 4.3 開發環境驗證 4.4 常見安裝問題與解決方案 4.5 小結 基本 CRUD 範例\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/object-relational-mapping-orm-%E7%89%A9%E4%BB%B6%E9%97%9C%E8%81%AF%E5%B0%8D%E6%98%A0%E6%95%99%E5%AD%B8/","summary":"Object-Relational Mapping (ORM) 物件關聯對映教學手冊 目錄 ORM 簡介\n1.1 什麼是 ORM？ 1.2 為什麼需要 ORM？ 1.3 ORM 解決的問題 1.4 與 SQL/資料庫互動的關係 1.5 小結 ORM 的基本概念\n2.1 實體 (Entity) 2.2 對應 (Mapping) 2.3 Session/EntityManager 2.4 Transaction (交易) 2.5 Lazy Loading vs Eager Loading 2.6 小結 ORM 工具與框架簡介\n3.1 Java 生態系統 3.2 Python 生態系統 3.3 其他語言的 ORM 框架 3.4 ORM 框架比較 3.5 選擇 ORM 框架的考量因素 3.6 小結 安裝與設定\n4.1 Java 環境設定 (Spring Boot + JPA) 4.2 Python 環境設定 (SQLAlchemy) 4.3 開發環境驗證 4.4 常見安裝問題與解決方案 4.5 小結 基本 CRUD 範例\n","title":"Object-Relational Mapping (ORM) 物件關聯對映教學"},{"content":"Onion Architecture 設計教學手冊 版本：1.0\n日期：2025年9月20日\n適用對象：Java 開發新進同仁\n目標：學習 Onion Architecture 設計與認證準備\n📚 目錄 第 1 章：緒論\n1.1 教學手冊的目的與對象 1.2 為什麼需要 Onion Architecture 1.3 與傳統分層架構、Hexagonal Architecture、Clean Architecture 的比較 1.4 如何透過本手冊準備 Onion Architecture 認證 第 2 章：Onion Architecture 基礎概念\n2.1 Onion Architecture 的核心理念 2.2 各層級設計原則 2.3 依賴反轉原則 (Dependency Inversion Principle) 2.4 Onion Architecture 的優點與限制 第 3 章：分層解析\n3.1 Domain Layer - 實體與商業規則 3.2 Application Layer - 用例與服務 3.3 Infrastructure Layer - 技術支援與外部資源 3.4 Presentation Layer - 使用者介面與 API 3.5 層與層之間的互動與依賴管理 第 4 章：實作指南\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/onion-architecture-%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Onion Architecture 設計教學手冊 版本：1.0\n日期：2025年9月20日\n適用對象：Java 開發新進同仁\n目標：學習 Onion Architecture 設計與認證準備\n📚 目錄 第 1 章：緒論\n1.1 教學手冊的目的與對象 1.2 為什麼需要 Onion Architecture 1.3 與傳統分層架構、Hexagonal Architecture、Clean Architecture 的比較 1.4 如何透過本手冊準備 Onion Architecture 認證 第 2 章：Onion Architecture 基礎概念\n2.1 Onion Architecture 的核心理念 2.2 各層級設計原則 2.3 依賴反轉原則 (Dependency Inversion Principle) 2.4 Onion Architecture 的優點與限制 第 3 章：分層解析\n3.1 Domain Layer - 實體與商業規則 3.2 Application Layer - 用例與服務 3.3 Infrastructure Layer - 技術支援與外部資源 3.4 Presentation Layer - 使用者介面與 API 3.5 層與層之間的互動與依賴管理 第 4 章：實作指南\n","title":"Onion Architecture 設計教學"},{"content":"Podman Desktop 使用教學手冊 📋 目錄 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 1.2 與 Docker 的比較 1.3 安裝 Podman Desktop 1.4 基本操作介面導覽 2. 專案實務應用 2.1 在專案中使用 Podman Desktop 2.2 容器管理實務 2.3 映像檔管理 2.4 Volume 與 Network 管理 2.5 IDE 整合 3. 進階操作與最佳實務 3.1 Podman CLI 與 Desktop 搭配使用 3.2 Compose 支援與多容器應用管理 3.3 安全性與資源管理最佳實踐 3.4 與 Kubernetes/OpenShift 對接基礎 4. 認證考試準備 4.1 Podman 認證知識範圍 4.2 常見考題型態與解題練習 4.3 學習地圖與練習資源 5. 檢查清單 5.1 安裝驗證清單 5.2 開發環境設定清單 5.3 專案部署清單 5.4 安全性檢查清單 5.5 效能優化清單 5.6 故障排除清單 5.7 認證考試準備清單 5.8 日常維護清單 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 🎯 學習目標 理解 Podman 的核心概念與背景 了解 Podman Desktop 的功能與特色 掌握容器化技術的基本原理 什麼是 Podman？ Podman（Pod Manager） 是由 Red Hat 開發的開源容器引擎，提供無守護程序（daemonless）的容器管理解決方案。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/podman-desktop%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Podman Desktop 使用教學手冊 📋 目錄 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 1.2 與 Docker 的比較 1.3 安裝 Podman Desktop 1.4 基本操作介面導覽 2. 專案實務應用 2.1 在專案中使用 Podman Desktop 2.2 容器管理實務 2.3 映像檔管理 2.4 Volume 與 Network 管理 2.5 IDE 整合 3. 進階操作與最佳實務 3.1 Podman CLI 與 Desktop 搭配使用 3.2 Compose 支援與多容器應用管理 3.3 安全性與資源管理最佳實踐 3.4 與 Kubernetes/OpenShift 對接基礎 4. 認證考試準備 4.1 Podman 認證知識範圍 4.2 常見考題型態與解題練習 4.3 學習地圖與練習資源 5. 檢查清單 5.1 安裝驗證清單 5.2 開發環境設定清單 5.3 專案部署清單 5.4 安全性檢查清單 5.5 效能優化清單 5.6 故障排除清單 5.7 認證考試準備清單 5.8 日常維護清單 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 🎯 學習目標 理解 Podman 的核心概念與背景 了解 Podman Desktop 的功能與特色 掌握容器化技術的基本原理 什麼是 Podman？ Podman（Pod Manager） 是由 Red Hat 開發的開源容器引擎，提供無守護程序（daemonless）的容器管理解決方案。\n","title":"Podman Desktop使用教學"},{"content":"Podman 使用教學手冊 📋 目錄 1. 基礎入門 1.1 什麼是 Podman 1.1.1 主要特色 1.1.2 適用場景 1.2 Podman 與 Docker 的差異 1.2.1 指令對比範例 1.3 安裝與環境設定 1.3.1 Windows 安裝 1.3.2 Linux 安裝 1.3.3 macOS 安裝 1.3.4 初始配置 1.4 基本概念 1.4.1 容器（Container） 1.4.2 映像檔（Image） 1.4.3 Pod 1.5 基本指令 1.5.1 映像檔管理 1.5.2 容器管理 1.5.3 實務範例 1.5.4 常用選項說明 1.6 注意事項與最佳實務 1.6.1 安全性注意事項 1.6.2 效能優化建議 1.6.3 疑難排解 📝 基礎實務練習 2. 專案實務應用 2.1 企業專案環境設置 2.1.1 典型企業專案架構 2.1.2 容器化策略 2.2 Spring Boot 應用容器化 2.2.1 建立 Dockerfile 2.2.2 建置和運行 Spring Boot 容器 2.3 前端應用容器化 2.3.1 React 應用 Dockerfile 2.3.2 Nginx 配置檔案 2.4 資料庫容器化 2.4.1 PostgreSQL 容器設置 2.4.2 Redis 快取容器 2.5 開發環境管理 2.5.1 開發環境 Pod 創建 2.5.2 開發工作流程 2.6 CI/CD 整合 2.6.1 GitLab CI 範例 2.6.2 GitHub Actions 範例 2.7 微服務架構實作 2.7.1 服務發現與負載平衡 2.7.2 API Gateway 設置 2.8 監控與日誌管理 2.8.1 集中式日誌收集 2.8.2 應用程式監控 2.9 除錯技巧 2.9.1 容器除錯 2.9.2 網路除錯 2.10 效能優化 2.10.1 映像檔優化 2.10.2 資源限制 📝 專案實務練習 3. 進階操作 3.1 Podman Compose 3.1.1 什麼是 Podman Compose 3.1.2 安裝 Podman Compose 3.1.3 Compose 檔案結構 3.1.4 Compose 常用指令 3.2 映像檔最佳化 3.2.1 多階段建置 3.2.2 映像檔層級最佳化 3.2.3 .containerignore 檔案 3.3 安全性強化 3.3.1 映像檔安全掃描 3.3.2 安全 Dockerfile 實務 3.3.3 容器執行時安全 3.4 Volume 管理 3.4.1 Volume 類型 3.4.2 Volume 操作 3.4.3 進階 Volume 配置 3.5 網路管理 3.5.1 網路類型 3.5.2 容器網路配置 3.5.3 網路除錯 3.6 Registry 管理 3.6.1 私有 Registry 設置 3.6.2 Registry 認證 3.6.3 Registry 鏡像配置 3.7 系統管理與維護 3.7.1 系統清理 3.7.2 系統監控 3.7.3 備份與還原 📝 進階實務練習 4. 考照準備 4.1 Podman 認證概述 4.1.1 認證類型 4.1.2 EX180 考試範圍 4.2 核心知識點整理 4.2.1 容器基本概念 4.2.2 Podman 架構特色 4.3 常見考題類型 4.3.1 基本操作題（30%） 4.3.2 Dockerfile 建置題（25%） 4.3.3 Pod 管理題（20%） 4.3.4 網路與儲存題（15%） 4.3.5 安全與故障排查題（10%） 4.4 實戰模擬題 4.4.1 綜合情境題 1 4.4.2 綜合情境題 2 4.5 考試策略與技巧 4.5.1 時間管理 4.5.2 常見錯誤避免 4.5.3 除錯技巧 4.6 練習題庫 4.6.1 基礎練習題 4.6.2 進階練習題 4.7 考前檢查清單 4.7.1 知識點檢查 4.7.2 實務操作檢查 4.7.3 考試環境準備 5. 附錄 5.1 常見錯誤排查 5.1.1 安裝和設定問題 5.1.2 容器運行問題 5.1.3 效能問題 5.2 最佳實務建議 5.2.1 安全性最佳實務 5.2.2 效能最佳實務 5.2.3 維護性最佳實務 5.3 指令參考手冊 5.3.1 映像檔管理指令 5.3.2 容器管理指令 5.3.3 Pod 管理指令 5.3.4 網路管理指令 5.3.5 Volume 管理指令 5.4 設定檔範本 5.4.1 Dockerfile 範本 5.4.2 Compose 檔案範本 5.5 工具和資源 5.5.1 有用的工具 5.5.2 學習資源 5.6 檢查清單（Checklist） 5.6.1 開發環境設置檢查清單 5.6.2 生產部署檢查清單 5.6.3 故障排查檢查清單 1. 基礎入門 1.1 什麼是 Podman Podman（Pod Manager）是一個開源的容器管理工具，由 Red Hat 開發。它提供與 Docker 相似的功能，但採用了不同的架構設計。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/podman%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Podman 使用教學手冊 📋 目錄 1. 基礎入門 1.1 什麼是 Podman 1.1.1 主要特色 1.1.2 適用場景 1.2 Podman 與 Docker 的差異 1.2.1 指令對比範例 1.3 安裝與環境設定 1.3.1 Windows 安裝 1.3.2 Linux 安裝 1.3.3 macOS 安裝 1.3.4 初始配置 1.4 基本概念 1.4.1 容器（Container） 1.4.2 映像檔（Image） 1.4.3 Pod 1.5 基本指令 1.5.1 映像檔管理 1.5.2 容器管理 1.5.3 實務範例 1.5.4 常用選項說明 1.6 注意事項與最佳實務 1.6.1 安全性注意事項 1.6.2 效能優化建議 1.6.3 疑難排解 📝 基礎實務練習 2. 專案實務應用 2.1 企業專案環境設置 2.1.1 典型企業專案架構 2.1.2 容器化策略 2.2 Spring Boot 應用容器化 2.2.1 建立 Dockerfile 2.2.2 建置和運行 Spring Boot 容器 2.3 前端應用容器化 2.3.1 React 應用 Dockerfile 2.3.2 Nginx 配置檔案 2.4 資料庫容器化 2.4.1 PostgreSQL 容器設置 2.4.2 Redis 快取容器 2.5 開發環境管理 2.5.1 開發環境 Pod 創建 2.5.2 開發工作流程 2.6 CI/CD 整合 2.6.1 GitLab CI 範例 2.6.2 GitHub Actions 範例 2.7 微服務架構實作 2.7.1 服務發現與負載平衡 2.7.2 API Gateway 設置 2.8 監控與日誌管理 2.8.1 集中式日誌收集 2.8.2 應用程式監控 2.9 除錯技巧 2.9.1 容器除錯 2.9.2 網路除錯 2.10 效能優化 2.10.1 映像檔優化 2.10.2 資源限制 📝 專案實務練習 3. 進階操作 3.1 Podman Compose 3.1.1 什麼是 Podman Compose 3.1.2 安裝 Podman Compose 3.1.3 Compose 檔案結構 3.1.4 Compose 常用指令 3.2 映像檔最佳化 3.2.1 多階段建置 3.2.2 映像檔層級最佳化 3.2.3 .containerignore 檔案 3.3 安全性強化 3.3.1 映像檔安全掃描 3.3.2 安全 Dockerfile 實務 3.3.3 容器執行時安全 3.4 Volume 管理 3.4.1 Volume 類型 3.4.2 Volume 操作 3.4.3 進階 Volume 配置 3.5 網路管理 3.5.1 網路類型 3.5.2 容器網路配置 3.5.3 網路除錯 3.6 Registry 管理 3.6.1 私有 Registry 設置 3.6.2 Registry 認證 3.6.3 Registry 鏡像配置 3.7 系統管理與維護 3.7.1 系統清理 3.7.2 系統監控 3.7.3 備份與還原 📝 進階實務練習 4. 考照準備 4.1 Podman 認證概述 4.1.1 認證類型 4.1.2 EX180 考試範圍 4.2 核心知識點整理 4.2.1 容器基本概念 4.2.2 Podman 架構特色 4.3 常見考題類型 4.3.1 基本操作題（30%） 4.3.2 Dockerfile 建置題（25%） 4.3.3 Pod 管理題（20%） 4.3.4 網路與儲存題（15%） 4.3.5 安全與故障排查題（10%） 4.4 實戰模擬題 4.4.1 綜合情境題 1 4.4.2 綜合情境題 2 4.5 考試策略與技巧 4.5.1 時間管理 4.5.2 常見錯誤避免 4.5.3 除錯技巧 4.6 練習題庫 4.6.1 基礎練習題 4.6.2 進階練習題 4.7 考前檢查清單 4.7.1 知識點檢查 4.7.2 實務操作檢查 4.7.3 考試環境準備 5. 附錄 5.1 常見錯誤排查 5.1.1 安裝和設定問題 5.1.2 容器運行問題 5.1.3 效能問題 5.2 最佳實務建議 5.2.1 安全性最佳實務 5.2.2 效能最佳實務 5.2.3 維護性最佳實務 5.3 指令參考手冊 5.3.1 映像檔管理指令 5.3.2 容器管理指令 5.3.3 Pod 管理指令 5.3.4 網路管理指令 5.3.5 Volume 管理指令 5.4 設定檔範本 5.4.1 Dockerfile 範本 5.4.2 Compose 檔案範本 5.5 工具和資源 5.5.1 有用的工具 5.5.2 學習資源 5.6 檢查清單（Checklist） 5.6.1 開發環境設置檢查清單 5.6.2 生產部署檢查清單 5.6.3 故障排查檢查清單 1. 基礎入門 1.1 什麼是 Podman Podman（Pod Manager）是一個開源的容器管理工具，由 Red Hat 開發。它提供與 Docker 相似的功能，但採用了不同的架構設計。\n","title":"Podman使用教學"},{"content":"PowerShell 使用教學手冊 目錄 第 1 部分：基礎入門 認識 PowerShell\n1.1 PowerShell 的歷史與用途 1.2 與 CMD、Bash 的差異 1.3 PowerShell Core vs Windows PowerShell 安裝與環境設定\n2.1 在 Windows 安裝 PowerShell 2.2 跨平台安裝 2.3 PowerShell ISE 與 VS Code 整合 2.4 基本環境變數設定 基本操作\n3.1 常用指令（Get-Help、Get-Command、Get-Member） 3.2 管道 (Pipeline) 與物件導向特性 3.3 輸出與重新導向 第 2 部分：核心語法 變數與資料型態\n4.1 宣告與使用變數 4.2 常見資料型別 4.3 型態轉換與檢查 運算子與流程控制\n5.1 比較運算子與邏輯運算子 5.2 條件判斷（if, switch） 5.3 迴圈語法（for, foreach, while, do-while） 函數與模組\n6.1 定義與呼叫函數 6.2 參數與回傳值 6.3 匯入與建立模組 第 3 部分：進階技巧 物件與管道操作\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/powershell%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PowerShell 使用教學手冊 目錄 第 1 部分：基礎入門 認識 PowerShell\n1.1 PowerShell 的歷史與用途 1.2 與 CMD、Bash 的差異 1.3 PowerShell Core vs Windows PowerShell 安裝與環境設定\n2.1 在 Windows 安裝 PowerShell 2.2 跨平台安裝 2.3 PowerShell ISE 與 VS Code 整合 2.4 基本環境變數設定 基本操作\n3.1 常用指令（Get-Help、Get-Command、Get-Member） 3.2 管道 (Pipeline) 與物件導向特性 3.3 輸出與重新導向 第 2 部分：核心語法 變數與資料型態\n4.1 宣告與使用變數 4.2 常見資料型別 4.3 型態轉換與檢查 運算子與流程控制\n5.1 比較運算子與邏輯運算子 5.2 條件判斷（if, switch） 5.3 迴圈語法（for, foreach, while, do-while） 函數與模組\n6.1 定義與呼叫函數 6.2 參數與回傳值 6.3 匯入與建立模組 第 3 部分：進階技巧 物件與管道操作\n","title":"PowerShell使用教學"},{"content":"PrimeNG 使用教學手冊 文件資訊 版本: 1.0.0 更新日期: 2025年9月5日 目標對象: 從未學過 PrimeNG 的新進開發同仁 適用 PrimeNG 版本: 17.x+ 適用 Angular 版本: 17.x+ 目錄 第 1 部分：基礎入門 PrimeNG 簡介\n1.1 什麼是 PrimeNG 1.2 為什麼選擇 PrimeNG 1.3 在企業專案中的角色 1.4 實務案例 1.5 注意事項與最佳實務 環境安裝與設定\n2.1 前置需求 2.2 建立 Angular 專案 2.3 安裝 PrimeNG 與相關套件 2.4 基礎設定 2.5 主題選擇與設定 2.6 設定 PrimeFlex（CSS 工具庫） 2.7 開發工具設定 2.8 實務案例：企業專案設定 2.9 注意事項與疑難排解 2.10 環境設定檢查清單 PrimeNG 基本使用流程\n3.1 理解 Angular 與 PrimeNG 的關係 3.2 模組匯入策略 3.3 建立第一個 PrimeNG 頁面 3.4 PrimeNG 服務的使用 3.5 響應式設計與 PrimeFlex 3.6 實務開發流程 3.7 注意事項與最佳實務 3.8 第一個專案檢查清單 第 2 部分：核心元件應用 按鈕與圖示\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/primeng%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PrimeNG 使用教學手冊 文件資訊 版本: 1.0.0 更新日期: 2025年9月5日 目標對象: 從未學過 PrimeNG 的新進開發同仁 適用 PrimeNG 版本: 17.x+ 適用 Angular 版本: 17.x+ 目錄 第 1 部分：基礎入門 PrimeNG 簡介\n1.1 什麼是 PrimeNG 1.2 為什麼選擇 PrimeNG 1.3 在企業專案中的角色 1.4 實務案例 1.5 注意事項與最佳實務 環境安裝與設定\n2.1 前置需求 2.2 建立 Angular 專案 2.3 安裝 PrimeNG 與相關套件 2.4 基礎設定 2.5 主題選擇與設定 2.6 設定 PrimeFlex（CSS 工具庫） 2.7 開發工具設定 2.8 實務案例：企業專案設定 2.9 注意事項與疑難排解 2.10 環境設定檢查清單 PrimeNG 基本使用流程\n3.1 理解 Angular 與 PrimeNG 的關係 3.2 模組匯入策略 3.3 建立第一個 PrimeNG 頁面 3.4 PrimeNG 服務的使用 3.5 響應式設計與 PrimeFlex 3.6 實務開發流程 3.7 注意事項與最佳實務 3.8 第一個專案檢查清單 第 2 部分：核心元件應用 按鈕與圖示\n","title":"PrimeNG使用教學"},{"content":"PrimeVue 使用教學手冊 📋 目錄 第一章：基礎入門\n1.1 PrimeVue 簡介 1.2 PrimeVue 與 Vue.js 的關係 1.3 安裝與設定 1.4 建立第一個 PrimeVue 專案 1.5 Hello World 範例 第二章：核心元件介紹\n2.1 按鈕（Button）與圖示（IconButton） 2.2 表單元件（InputText、Password、Dropdown、Checkbox、RadioButton、Calendar、Slider） 2.3 資料顯示元件（DataTable、Listbox、Card、Panel、TabView、Accordion） 2.4 對話框與通知（Dialog、Toast、ConfirmDialog） 2.5 版面配置元件（Panel、Card、Divider、Splitter） 第三章：專案應用實戰\n3.1 建立完整的使用者管理系統 3.2 第三章總結與學習重點 第四章：進階功能與效能優化\n4.1 效能優化策略 4.1.1 Vue 3 的效能優化特性 4.1.2 PrimeVue 元件效能優化 4.1.3 記憶體管理與清理 4.2 國際化 (i18n) 實作 4.2.1 Vue I18n 設定 4.2.2 在元件中使用國際化 4.2.3 PrimeVue 元件的本地化 4.3 主題系統與自訂樣式 4.3.1 PrimeVue 主題系統 4.3.2 自訂 CSS 變數系統 4.4 測試策略 4.4.1 單元測試設定 4.4.2 整合測試 4.4.3 E2E 測試 4.5 第四章總結 第五章：實務案例與最佳實務\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/primevue%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PrimeVue 使用教學手冊 📋 目錄 第一章：基礎入門\n1.1 PrimeVue 簡介 1.2 PrimeVue 與 Vue.js 的關係 1.3 安裝與設定 1.4 建立第一個 PrimeVue 專案 1.5 Hello World 範例 第二章：核心元件介紹\n2.1 按鈕（Button）與圖示（IconButton） 2.2 表單元件（InputText、Password、Dropdown、Checkbox、RadioButton、Calendar、Slider） 2.3 資料顯示元件（DataTable、Listbox、Card、Panel、TabView、Accordion） 2.4 對話框與通知（Dialog、Toast、ConfirmDialog） 2.5 版面配置元件（Panel、Card、Divider、Splitter） 第三章：專案應用實戰\n3.1 建立完整的使用者管理系統 3.2 第三章總結與學習重點 第四章：進階功能與效能優化\n4.1 效能優化策略 4.1.1 Vue 3 的效能優化特性 4.1.2 PrimeVue 元件效能優化 4.1.3 記憶體管理與清理 4.2 國際化 (i18n) 實作 4.2.1 Vue I18n 設定 4.2.2 在元件中使用國際化 4.2.3 PrimeVue 元件的本地化 4.3 主題系統與自訂樣式 4.3.1 PrimeVue 主題系統 4.3.2 自訂 CSS 變數系統 4.4 測試策略 4.4.1 單元測試設定 4.4.2 整合測試 4.4.3 E2E 測試 4.5 第四章總結 第五章：實務案例與最佳實務\n","title":"PrimeVue使用教學"},{"content":"Python 程式語言教學手冊 目錄 Python 基礎入門\n1.1 Python 安裝與環境設置 1.1.1 Python 簡介 1.1.2 Windows 系統安裝 1.1.3 Linux 系統安裝 1.1.4 開發環境設置 1.1.5 專案結構 1.2 語法基礎 1.2.1 Python 語法規則 1.2.2 變數與命名規則 1.2.3 資料型態 1.2.4 運算子（含海象運算子 :=） 1.2.5 型別提示 (Type Hints) 1.3 流程控制 1.3.1 條件判斷 (if 語句) 1.3.1.1 結構化模式匹配 (match/case) 1.3.2 迴圈結構 1.3.3 例外處理（含例外群組 except*） 1.3.4 進階流程控制 1.4 函式、模組與套件管理 1.4.1 函式定義與使用 1.4.2 模組與套件 1.4.3 套件管理與發布 進階應用\n2.1 面向物件程式設計 2.1.1 類別與物件 2.1.2 封裝與屬性 2.1.3 繼承 2.1.4 多型 2.1.5 特殊方法 (Magic Methods) 2.1.6 資料類別 (dataclasses) 2.2 檔案處理與例外處理 2.2.1 檔案基本操作 2.2.2 進階檔案處理 2.2.3 例外處理機制 2.2.4 上下文管理器 2.3 常用標準函式庫 2.3.1 日期時間處理 2.3.2 正規表達式 2.3.3 系統操作 2.3.4 網路程式設計基礎 2.3.5 其他重要模組 2.4 測試與除錯 2.4.1 單元測試基礎 2.4.2 進階測試技術 2.4.3 pytest 框架 2.4.4 除錯技巧 2.4.5 測試驅動開發 (TDD) 2.5 Python 現代特性（3.11 ~ 3.15） 2.5.1 Python 3.11 新特性 2.5.2 Python 3.12 新特性 2.5.3 Python 3.13 新特性 2.5.4 Python 3.14 新特性 2.5.5 Python 3.15 新特性（開發中） 專案實務應用\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/python%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"Python 程式語言教學手冊 目錄 Python 基礎入門\n1.1 Python 安裝與環境設置 1.1.1 Python 簡介 1.1.2 Windows 系統安裝 1.1.3 Linux 系統安裝 1.1.4 開發環境設置 1.1.5 專案結構 1.2 語法基礎 1.2.1 Python 語法規則 1.2.2 變數與命名規則 1.2.3 資料型態 1.2.4 運算子（含海象運算子 :=） 1.2.5 型別提示 (Type Hints) 1.3 流程控制 1.3.1 條件判斷 (if 語句) 1.3.1.1 結構化模式匹配 (match/case) 1.3.2 迴圈結構 1.3.3 例外處理（含例外群組 except*） 1.3.4 進階流程控制 1.4 函式、模組與套件管理 1.4.1 函式定義與使用 1.4.2 模組與套件 1.4.3 套件管理與發布 進階應用\n2.1 面向物件程式設計 2.1.1 類別與物件 2.1.2 封裝與屬性 2.1.3 繼承 2.1.4 多型 2.1.5 特殊方法 (Magic Methods) 2.1.6 資料類別 (dataclasses) 2.2 檔案處理與例外處理 2.2.1 檔案基本操作 2.2.2 進階檔案處理 2.2.3 例外處理機制 2.2.4 上下文管理器 2.3 常用標準函式庫 2.3.1 日期時間處理 2.3.2 正規表達式 2.3.3 系統操作 2.3.4 網路程式設計基礎 2.3.5 其他重要模組 2.4 測試與除錯 2.4.1 單元測試基礎 2.4.2 進階測試技術 2.4.3 pytest 框架 2.4.4 除錯技巧 2.4.5 測試驅動開發 (TDD) 2.5 Python 現代特性（3.11 ~ 3.15） 2.5.1 Python 3.11 新特性 2.5.2 Python 3.12 新特性 2.5.3 Python 3.13 新特性 2.5.4 Python 3.14 新特性 2.5.5 Python 3.15 新特性（開發中） 專案實務應用\n","title":"Python程式語言教學"},{"content":"Python 程式語言教學手冊 目錄 Python 基礎入門\n1.1 Python 安裝與環境設置 1.1.1 Python 簡介 1.1.2 Windows 系統安裝 1.1.3 Linux 系統安裝 1.1.4 開發環境設置 1.1.5 專案結構 1.2 語法基礎 1.2.1 Python 語法規則 1.2.2 變數與命名規則 1.2.3 資料型態 1.2.4 運算子（含海象運算子 :=） 1.2.5 型別提示 (Type Hints) 1.3 流程控制 1.3.1 條件判斷 (if 語句) 1.3.1.1 結構化模式匹配 (match/case) 1.3.2 迴圈結構 1.3.3 例外處理（含例外群組 except*） 1.3.4 進階流程控制 1.4 函式、模組與套件管理 1.4.1 函式定義與使用 1.4.2 模組與套件 1.4.3 套件管理與發布 進階應用\n2.1 面向物件程式設計 2.1.1 類別與物件 2.1.2 封裝與屬性 2.1.3 繼承 2.1.4 多型 2.1.5 特殊方法 (Magic Methods) 2.1.6 資料類別 (dataclasses) 2.2 檔案處理與例外處理 2.2.1 檔案基本操作 2.2.2 進階檔案處理 2.2.3 例外處理機制 2.2.4 上下文管理器 2.3 常用標準函式庫 2.3.1 日期時間處理 2.3.2 正規表達式 2.3.3 系統操作 2.3.4 網路程式設計基礎 2.3.5 其他重要模組 2.4 測試與除錯 2.4.1 單元測試基礎 2.4.2 進階測試技術 2.4.3 pytest 框架 2.4.4 除錯技巧 2.4.5 測試驅動開發 (TDD) 2.5 Python 現代特性（3.11 ~ 3.15） 2.5.1 Python 3.11 新特性 2.5.2 Python 3.12 新特性 2.5.3 Python 3.13 新特性 2.5.4 Python 3.14 新特性 2.5.5 Python 3.15 新特性（開發中） 專案實務應用\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/python%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"Python 程式語言教學手冊 目錄 Python 基礎入門\n1.1 Python 安裝與環境設置 1.1.1 Python 簡介 1.1.2 Windows 系統安裝 1.1.3 Linux 系統安裝 1.1.4 開發環境設置 1.1.5 專案結構 1.2 語法基礎 1.2.1 Python 語法規則 1.2.2 變數與命名規則 1.2.3 資料型態 1.2.4 運算子（含海象運算子 :=） 1.2.5 型別提示 (Type Hints) 1.3 流程控制 1.3.1 條件判斷 (if 語句) 1.3.1.1 結構化模式匹配 (match/case) 1.3.2 迴圈結構 1.3.3 例外處理（含例外群組 except*） 1.3.4 進階流程控制 1.4 函式、模組與套件管理 1.4.1 函式定義與使用 1.4.2 模組與套件 1.4.3 套件管理與發布 進階應用\n2.1 面向物件程式設計 2.1.1 類別與物件 2.1.2 封裝與屬性 2.1.3 繼承 2.1.4 多型 2.1.5 特殊方法 (Magic Methods) 2.1.6 資料類別 (dataclasses) 2.2 檔案處理與例外處理 2.2.1 檔案基本操作 2.2.2 進階檔案處理 2.2.3 例外處理機制 2.2.4 上下文管理器 2.3 常用標準函式庫 2.3.1 日期時間處理 2.3.2 正規表達式 2.3.3 系統操作 2.3.4 網路程式設計基礎 2.3.5 其他重要模組 2.4 測試與除錯 2.4.1 單元測試基礎 2.4.2 進階測試技術 2.4.3 pytest 框架 2.4.4 除錯技巧 2.4.5 測試驅動開發 (TDD) 2.5 Python 現代特性（3.11 ~ 3.15） 2.5.1 Python 3.11 新特性 2.5.2 Python 3.12 新特性 2.5.3 Python 3.13 新特性 2.5.4 Python 3.14 新特性 2.5.5 Python 3.15 新特性（開發中） 專案實務應用\n","title":"Python程式語言教學"},{"content":"React 前端 Framework 教學手冊 📚 目錄 基礎概念\n1.1 React 簡介與核心原理 1.2 JSX 語法 1.3 Component 元件 1.4 Props 屬性 1.5 State 狀態 1.6 Hooks 鉤子 專案實務\n2.0 專案建立與環境設定 2.1 專案架構與元件拆分 2.2 狀態管理策略 2.3 API 呼叫方式 2.4 UI/UX 開發流程 進階主題\n3.1 React Router 路由管理 3.2 Context API 3.3 狀態管理工具 3.4 效能最佳化 測試與品質\n4.1 React 測試框架 4.2 程式碼規範 4.3 Lint 與 Formatter 實戰演練\n5.1 表單處理 5.2 API 資料綁定 5.3 前後端整合 認證準備指南\n6.1 React 認證概述 6.2 常見考點 6.3 練習題範例 6.4 學習資源 檢查清單\n1. 基礎概念 1.1 React 簡介與核心原理 什麼是 React？ React 是由 Facebook（現在的 Meta）開發的開源 JavaScript 函式庫，專門用來建立使用者介面（UI）。它採用元件化的開發方式，讓開發者能夠建立可重複使用的 UI 元件。\nReact 核心原理 graph TB A[Virtual DOM] --\u0026gt; B[實際 DOM] C[Component] --\u0026gt; D[JSX] D --\u0026gt; A E[State] --\u0026gt; C F[Props] --\u0026gt; C G[Hooks] --\u0026gt; E subgraph \u0026#34;React 生態系統\u0026#34; A C E F G end 1. Virtual DOM（虛擬 DOM）\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/react%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"React 前端 Framework 教學手冊 📚 目錄 基礎概念\n1.1 React 簡介與核心原理 1.2 JSX 語法 1.3 Component 元件 1.4 Props 屬性 1.5 State 狀態 1.6 Hooks 鉤子 專案實務\n2.0 專案建立與環境設定 2.1 專案架構與元件拆分 2.2 狀態管理策略 2.3 API 呼叫方式 2.4 UI/UX 開發流程 進階主題\n3.1 React Router 路由管理 3.2 Context API 3.3 狀態管理工具 3.4 效能最佳化 測試與品質\n4.1 React 測試框架 4.2 程式碼規範 4.3 Lint 與 Formatter 實戰演練\n5.1 表單處理 5.2 API 資料綁定 5.3 前後端整合 認證準備指南\n6.1 React 認證概述 6.2 常見考點 6.3 練習題範例 6.4 學習資源 檢查清單\n1. 基礎概念 1.1 React 簡介與核心原理 什麼是 React？ React 是由 Facebook（現在的 Meta）開發的開源 JavaScript 函式庫，專門用來建立使用者介面（UI）。它採用元件化的開發方式，讓開發者能夠建立可重複使用的 UI 元件。\nReact 核心原理 graph TB A[Virtual DOM] --\u0026gt; B[實際 DOM] C[Component] --\u0026gt; D[JSX] D --\u0026gt; A E[State] --\u0026gt; C F[Props] --\u0026gt; C G[Hooks] --\u0026gt; E subgraph \u0026#34;React 生態系統\u0026#34; A C E F G end 1. Virtual DOM（虛擬 DOM）\n","title":"React前端framework教學"},{"content":"重構指引（Refactoring Guide） 目錄 前言與目標 什麼是重構？ 重構的核心目標 重構原則 基本原則 SOLID 原則在重構中的應用 重構時機 何時應該進行重構？ 重構的紅綠燈系統 常見重構手法 提煉函數（Extract Function） 提煉類別（Extract Class） 簡化條件表達式（Simplify Conditional Expressions） 提煉常數（Extract Constants） 移除死程式碼（Remove Dead Code） 重構流程 標準重構流程 重構檢核清單 Java 重構最佳實務 IDE 重構工具使用 Maven 設定重構支援 重構中的測試策略 安全性考量 重構過程中的安全原則 重構中的資安檢核清單 效能考量 重構對效能的影響 效能測試與監控 重構工具與技術 靜態分析工具 自動化重構工具 持續整合中的重構 常見重構陷阱與解決方案 常見錯誤 最佳實務建議 重構案例研究 遺留系統重構 微服務重構 重構檢核清單 重構前檢核 重構中檢核 重構後檢核 團隊協作與重構 Code Review 中的重構 重構溝通策略 重構效果追蹤 短期追蹤 中期追蹤 長期追蹤 結論 前言與目標 什麼是重構？ 重構（Refactoring）是指在不改變程式碼外部行為的前提下，對程式碼內部結構進行改善的過程。這是一種持續性的改進活動，旨在提升程式碼品質、可讀性和可維護性。\n重構的核心目標 1. 提高可讀性 目標：讓程式碼更容易理解，降低未來維護的難度 效益： 新團隊成員能快速上手 減少程式碼理解時間 降低錯誤修改的風險 評估指標： 程式碼複雜度（Cyclomatic Complexity） 方法長度 類別職責單一性 2. 改善結構與設計 目標：優化架構，使程式更具彈性、可擴充性 效益： 更容易添加新功能 更好的模組化設計 符合 SOLID 設計原則 評估指標： 耦合度（Coupling） 內聚性（Cohesion） 設計模式使用適當性 3. 減少重複（DRY 原則） 目標：把重複的邏輯抽出來，讓程式碼更簡潔 效益： 減少程式碼維護成本 降低一致性問題 提高程式碼重用性 評估指標： 重複程式碼比例 共用元件使用率 4. 提升可測試性 目標：更清晰的結構有助於單元測試與整合測試 效益： 更容易編寫單元測試 提高測試覆蓋率 更好的依賴注入設計 評估指標： 測試覆蓋率 測試案例數量 模擬物件使用便利性 5. 降低技術債（Technical Debt） 目標：清理過時或混亂的程式碼，避免未來出現更多問題 效益： 提升開發效率 減少維護成本 降低系統風險 評估指標： SonarQube 品質評分 程式碼異味數量 安全漏洞數量 6. 促進團隊協作 目標：統一風格與結構，讓不同開發者更容易接手 效益： 提升團隊開發效率 降低知識傳承成本 統一開發標準 評估指標： 程式碼風格一致性 Code Review 效率 團隊生產力 重構原則 基本原則 1. 保持外部行為不變 重構過程中，程式的功能和對外介面不應改變 所有現有的測試案例應該繼續通過 使用者感受不到任何功能上的差異 2. 小步快跑 每次重構應該是小幅度的改動 頻繁進行測試驗證 避免大範圍的同時修改 3. 測試先行 重構前確保有足夠的測試覆蓋 重構過程中持續執行測試 新增測試案例以驗證重構結果 4. 循序漸進 按照優先順序進行重構 先解決最嚴重的程式碼異味 避免過度重構 SOLID 原則在重構中的應用 1. 單一職責原則（Single Responsibility Principle） // 重構前：一個類別負責多個職責 public class UserManager { public void saveUser(User user) { // 驗證使用者資料 if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } // 儲存到資料庫 DatabaseConnection conn = new DatabaseConnection(); conn.save(user); // 發送通知郵件 EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(user.getEmail()); } } // 重構後：職責分離 public class UserValidator { public void validate(User user) { if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } } } public class UserRepository { public void save(User user) { DatabaseConnection conn = new DatabaseConnection(); conn.save(user); } } public class UserNotificationService { public void sendWelcomeNotification(String email) { EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(email); } } public class UserService { private final UserValidator validator; private final UserRepository repository; private final UserNotificationService notificationService; public UserService(UserValidator validator, UserRepository repository, UserNotificationService notificationService) { this.validator = validator; this.repository = repository; this.notificationService = notificationService; } public void createUser(User user) { validator.validate(user); repository.save(user); notificationService.sendWelcomeNotification(user.getEmail()); } } 2. 開放封閉原則（Open/Closed Principle） // 重構前：修改現有程式碼來新增功能 public class DiscountCalculator { public double calculateDiscount(String customerType, double amount) { if (\u0026#34;REGULAR\u0026#34;.equals(customerType)) { return amount * 0.05; } else if (\u0026#34;VIP\u0026#34;.equals(customerType)) { return amount * 0.10; } else if (\u0026#34;PREMIUM\u0026#34;.equals(customerType)) { return amount * 0.15; } return 0; } } // 重構後：使用策略模式，對擴展開放，對修改封閉 public interface DiscountStrategy { double calculateDiscount(double amount); } public class RegularCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.05; } } public class VipCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.10; } } public class PremiumCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.15; } } public class DiscountCalculator { private final Map\u0026lt;String, DiscountStrategy\u0026gt; strategies; public DiscountCalculator() { strategies = Map.of( \u0026#34;REGULAR\u0026#34;, new RegularCustomerDiscount(), \u0026#34;VIP\u0026#34;, new VipCustomerDiscount(), \u0026#34;PREMIUM\u0026#34;, new PremiumCustomerDiscount() ); } public double calculateDiscount(String customerType, double amount) { DiscountStrategy strategy = strategies.get(customerType); return strategy != null ? strategy.calculateDiscount(amount) : 0; } } 重構時機 何時應該進行重構？ 1. 程式碼異味（Code Smells）出現時 長方法（Long Method）：方法超過 20-30 行 大類別（Large Class）：類別職責過多，超過 200-300 行 重複程式碼（Duplicated Code）：相同或相似的程式碼片段重複出現 長參數列表（Long Parameter List）：方法參數超過 3-4 個 2. 新增功能前 為新功能建立適當的架構基礎 清理相關的程式碼區域 確保新功能不會增加技術債 3. 修復 Bug 時 分析 Bug 產生的根本原因 改善可能導致類似問題的程式結構 增加相關的測試覆蓋 4. Code Review 過程中 發現程式碼可讀性問題 識別潛在的設計問題 統一團隊的程式碼風格 重構的紅綠燈系統 🟢 綠燈：適合重構 有充足的測試覆蓋（\u0026gt;80%） 沒有緊急的產品發布壓力 團隊對重構區域有充分了解 有足夠的時間進行測試驗證 🟡 黃燈：謹慎重構 測試覆蓋率中等（60-80%） 有適度的時間壓力 重構範圍較大 需要多人協作 🔴 紅燈：暫停重構 測試覆蓋率不足（\u0026lt;60%） 有緊急的產品發布 程式碼變動頻繁 缺乏領域知識 常見重構手法 1. 提煉函數（Extract Function） 目的 將重複的程式碼片段提煉成獨立的函數，提高重用性和可讀性。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/refactor-%E9%87%8D%E6%A7%8B%E6%8C%87%E5%BC%95/","summary":"重構指引（Refactoring Guide） 目錄 前言與目標 什麼是重構？ 重構的核心目標 重構原則 基本原則 SOLID 原則在重構中的應用 重構時機 何時應該進行重構？ 重構的紅綠燈系統 常見重構手法 提煉函數（Extract Function） 提煉類別（Extract Class） 簡化條件表達式（Simplify Conditional Expressions） 提煉常數（Extract Constants） 移除死程式碼（Remove Dead Code） 重構流程 標準重構流程 重構檢核清單 Java 重構最佳實務 IDE 重構工具使用 Maven 設定重構支援 重構中的測試策略 安全性考量 重構過程中的安全原則 重構中的資安檢核清單 效能考量 重構對效能的影響 效能測試與監控 重構工具與技術 靜態分析工具 自動化重構工具 持續整合中的重構 常見重構陷阱與解決方案 常見錯誤 最佳實務建議 重構案例研究 遺留系統重構 微服務重構 重構檢核清單 重構前檢核 重構中檢核 重構後檢核 團隊協作與重構 Code Review 中的重構 重構溝通策略 重構效果追蹤 短期追蹤 中期追蹤 長期追蹤 結論 前言與目標 什麼是重構？ 重構（Refactoring）是指在不改變程式碼外部行為的前提下，對程式碼內部結構進行改善的過程。這是一種持續性的改進活動，旨在提升程式碼品質、可讀性和可維護性。\n重構的核心目標 1. 提高可讀性 目標：讓程式碼更容易理解，降低未來維護的難度 效益： 新團隊成員能快速上手 減少程式碼理解時間 降低錯誤修改的風險 評估指標： 程式碼複雜度（Cyclomatic Complexity） 方法長度 類別職責單一性 2. 改善結構與設計 目標：優化架構，使程式更具彈性、可擴充性 效益： 更容易添加新功能 更好的模組化設計 符合 SOLID 設計原則 評估指標： 耦合度（Coupling） 內聚性（Cohesion） 設計模式使用適當性 3. 減少重複（DRY 原則） 目標：把重複的邏輯抽出來，讓程式碼更簡潔 效益： 減少程式碼維護成本 降低一致性問題 提高程式碼重用性 評估指標： 重複程式碼比例 共用元件使用率 4. 提升可測試性 目標：更清晰的結構有助於單元測試與整合測試 效益： 更容易編寫單元測試 提高測試覆蓋率 更好的依賴注入設計 評估指標： 測試覆蓋率 測試案例數量 模擬物件使用便利性 5. 降低技術債（Technical Debt） 目標：清理過時或混亂的程式碼，避免未來出現更多問題 效益： 提升開發效率 減少維護成本 降低系統風險 評估指標： SonarQube 品質評分 程式碼異味數量 安全漏洞數量 6. 促進團隊協作 目標：統一風格與結構，讓不同開發者更容易接手 效益： 提升團隊開發效率 降低知識傳承成本 統一開發標準 評估指標： 程式碼風格一致性 Code Review 效率 團隊生產力 重構原則 基本原則 1. 保持外部行為不變 重構過程中，程式的功能和對外介面不應改變 所有現有的測試案例應該繼續通過 使用者感受不到任何功能上的差異 2. 小步快跑 每次重構應該是小幅度的改動 頻繁進行測試驗證 避免大範圍的同時修改 3. 測試先行 重構前確保有足夠的測試覆蓋 重構過程中持續執行測試 新增測試案例以驗證重構結果 4. 循序漸進 按照優先順序進行重構 先解決最嚴重的程式碼異味 避免過度重構 SOLID 原則在重構中的應用 1. 單一職責原則（Single Responsibility Principle） // 重構前：一個類別負責多個職責 public class UserManager { public void saveUser(User user) { // 驗證使用者資料 if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } // 儲存到資料庫 DatabaseConnection conn = new DatabaseConnection(); conn.save(user); // 發送通知郵件 EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(user.getEmail()); } } // 重構後：職責分離 public class UserValidator { public void validate(User user) { if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } } } public class UserRepository { public void save(User user) { DatabaseConnection conn = new DatabaseConnection(); conn.save(user); } } public class UserNotificationService { public void sendWelcomeNotification(String email) { EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(email); } } public class UserService { private final UserValidator validator; private final UserRepository repository; private final UserNotificationService notificationService; public UserService(UserValidator validator, UserRepository repository, UserNotificationService notificationService) { this.validator = validator; this.repository = repository; this.notificationService = notificationService; } public void createUser(User user) { validator.validate(user); repository.save(user); notificationService.sendWelcomeNotification(user.getEmail()); } } 2. 開放封閉原則（Open/Closed Principle） // 重構前：修改現有程式碼來新增功能 public class DiscountCalculator { public double calculateDiscount(String customerType, double amount) { if (\u0026#34;REGULAR\u0026#34;.equals(customerType)) { return amount * 0.05; } else if (\u0026#34;VIP\u0026#34;.equals(customerType)) { return amount * 0.10; } else if (\u0026#34;PREMIUM\u0026#34;.equals(customerType)) { return amount * 0.15; } return 0; } } // 重構後：使用策略模式，對擴展開放，對修改封閉 public interface DiscountStrategy { double calculateDiscount(double amount); } public class RegularCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.05; } } public class VipCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.10; } } public class PremiumCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.15; } } public class DiscountCalculator { private final Map\u0026lt;String, DiscountStrategy\u0026gt; strategies; public DiscountCalculator() { strategies = Map.of( \u0026#34;REGULAR\u0026#34;, new RegularCustomerDiscount(), \u0026#34;VIP\u0026#34;, new VipCustomerDiscount(), \u0026#34;PREMIUM\u0026#34;, new PremiumCustomerDiscount() ); } public double calculateDiscount(String customerType, double amount) { DiscountStrategy strategy = strategies.get(customerType); return strategy != null ? strategy.calculateDiscount(amount) : 0; } } 重構時機 何時應該進行重構？ 1. 程式碼異味（Code Smells）出現時 長方法（Long Method）：方法超過 20-30 行 大類別（Large Class）：類別職責過多，超過 200-300 行 重複程式碼（Duplicated Code）：相同或相似的程式碼片段重複出現 長參數列表（Long Parameter List）：方法參數超過 3-4 個 2. 新增功能前 為新功能建立適當的架構基礎 清理相關的程式碼區域 確保新功能不會增加技術債 3. 修復 Bug 時 分析 Bug 產生的根本原因 改善可能導致類似問題的程式結構 增加相關的測試覆蓋 4. Code Review 過程中 發現程式碼可讀性問題 識別潛在的設計問題 統一團隊的程式碼風格 重構的紅綠燈系統 🟢 綠燈：適合重構 有充足的測試覆蓋（\u0026gt;80%） 沒有緊急的產品發布壓力 團隊對重構區域有充分了解 有足夠的時間進行測試驗證 🟡 黃燈：謹慎重構 測試覆蓋率中等（60-80%） 有適度的時間壓力 重構範圍較大 需要多人協作 🔴 紅燈：暫停重構 測試覆蓋率不足（\u0026lt;60%） 有緊急的產品發布 程式碼變動頻繁 缺乏領域知識 常見重構手法 1. 提煉函數（Extract Function） 目的 將重複的程式碼片段提煉成獨立的函數，提高重用性和可讀性。\n","title":"refactor 重構指引"},{"content":"Refactoring（重構）教學手冊 📚 目錄 重構基本概念\n1.1 什麼是重構？ 1.2 重構的目標 1.3 重構 vs 重寫 1.4 實務案例 重構的基本原則\n2.1 紅燈-綠燈-重構循環 2.2 重構的黃金法則 2.3 重構的時機 2.4 安全重構的步驟 2.5 實務注意事項 識別壞味道（Code Smells）\n3.1 什麼是程式碼壞味道？ 3.2 常見的程式碼壞味道 3.2.1 過長方法（Long Method） 3.2.2 過多參數（Long Parameter List） 3.2.3 重複程式碼（Duplicated Code） 3.2.4 過大類別（Large Class） 3.2.5 壞味道的量化指標 3.3 壞味道識別工具 3.4 實務練習 常見重構方法\n4.1 方法層級重構 4.1.1 Extract Method（提取方法） 4.1.2 Rename Variable（重新命名變數） 4.1.3 Introduce Parameter Object（引入參數物件） 4.1.4 Replace Method with Method Object（以方法物件取代方法） 4.2 類別層級重構 4.2.1 Extract Class（提取類別） 4.2.2 Move Method（搬移方法） 4.3 條件邏輯重構 4.3.1 Replace Conditional with Polymorphism（以多型取代條件式） 4.4 重構方法選擇流程 4.4.1 重構決策樹 4.4.2 重構優先順序指南 4.5 實務練習 重構與測試的關聯\n5.1 重構的安全網：單元測試 5.2 測試先行的重構策略 5.3 TDD 與重構的結合 5.4 重構時的測試最佳實務 5.5 重構測試檢查清單 實務應用策略\n6.1 重構時機的判斷 6.2 團隊重構策略 6.3 大型專案重構策略 6.4 效能考量 6.5 重構實務指引 團隊規範與最佳實務\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/refactoring%E9%87%8D%E6%A7%8B%E6%95%99%E5%AD%B8/","summary":"Refactoring（重構）教學手冊 📚 目錄 重構基本概念\n1.1 什麼是重構？ 1.2 重構的目標 1.3 重構 vs 重寫 1.4 實務案例 重構的基本原則\n2.1 紅燈-綠燈-重構循環 2.2 重構的黃金法則 2.3 重構的時機 2.4 安全重構的步驟 2.5 實務注意事項 識別壞味道（Code Smells）\n3.1 什麼是程式碼壞味道？ 3.2 常見的程式碼壞味道 3.2.1 過長方法（Long Method） 3.2.2 過多參數（Long Parameter List） 3.2.3 重複程式碼（Duplicated Code） 3.2.4 過大類別（Large Class） 3.2.5 壞味道的量化指標 3.3 壞味道識別工具 3.4 實務練習 常見重構方法\n4.1 方法層級重構 4.1.1 Extract Method（提取方法） 4.1.2 Rename Variable（重新命名變數） 4.1.3 Introduce Parameter Object（引入參數物件） 4.1.4 Replace Method with Method Object（以方法物件取代方法） 4.2 類別層級重構 4.2.1 Extract Class（提取類別） 4.2.2 Move Method（搬移方法） 4.3 條件邏輯重構 4.3.1 Replace Conditional with Polymorphism（以多型取代條件式） 4.4 重構方法選擇流程 4.4.1 重構決策樹 4.4.2 重構優先順序指南 4.5 實務練習 重構與測試的關聯\n5.1 重構的安全網：單元測試 5.2 測試先行的重構策略 5.3 TDD 與重構的結合 5.4 重構時的測試最佳實務 5.5 重構測試檢查清單 實務應用策略\n6.1 重構時機的判斷 6.2 團隊重構策略 6.3 大型專案重構策略 6.4 效能考量 6.5 重構實務指引 團隊規範與最佳實務\n","title":"Refactoring重構教學"},{"content":"Spec-Kit 使用教學手冊 版本: 14.0\n最後更新: 2026年7月15日\n適用於: Spec-Kit v0.12.15+ / Spec Kit Templates - 0.12.15\nCreated by: Eric Cheng\n📚 目錄 前言\n目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解\n1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備\n2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 2.7 擴充系統 (Extension System) 2.8 預設系統 (Presets System) 2.9 CLI 診斷指令 (doctor / status) 2.10 Plugin Architecture（v0.4.4-0.4.5 重大架構變革） 2.11 整合管理指令 (specify integration) 2.12 Git 擴充 (Bundled Git Extension) 2.13 工作流引擎 (Workflow Engine, v0.7.0) 2.14 \u0026ndash;integration 旗標（v0.7.1 取代 \u0026ndash;ai） 2.15 Self Management 指令（v0.7.5 新增，v0.9.3 正式實作完成） 2.16 預設組合策略 (Composition Strategies, v0.8.0) 2.17 Skills-Based Scaffolding（v0.8.0 新增） 2.18 feature.json 自訂分支支援（v0.8.1 新增） 2.19 \u0026ndash;no-git 旗標棄用與 GITHUB_TOKEN 認證（v0.8.2 新增） 2.20 目錄探索 CLI 與 Devin 整合（v0.8.3 新增） 2.21 Constitution 上下文載入與治理擴充（v0.8.4-v0.8.6 新增） 2.22 Lingma 整合與 Agent Orchestrator（v0.8.7 新增） 2.23 Config-Driven 認證與排程擴充（v0.8.8 新增） 2.24 治理生態系擴充與 BrownKit（v0.8.9 新增） 2.25 社群治理擴充與文件站遷移（v0.8.10 新增） 2.26 高保證規格工作流與版本特徵報告（v0.8.11 新增） 2.27 Integration Auto 與社群擴充更新（v0.8.12 新增） 2.28 工作流迴圈修正與代理工作流自動化（v0.8.13 新增） 2.29 CLI 重構與分支命名規範（v0.8.14 新增） 2.30 後執行 Hook 與 Token Budget（v0.8.15 新增） 2.31 Workflow Preset 與規格品質重驗證（v0.8.16 新增） 2.32 Hermes Agent 整合與社群文件整合（v0.8.17 新增） 2.33 Self Upgrade 正式實作與 SPECKIT_WORKFLOW_RUN_ID（v0.8.18-v0.9.0 新增） 2.34 Cline 原生整合與相容性修正（v0.9.1 新增） 2.35 Workflow Continue-On-Error 與 Self Upgrade 正式實作（v0.9.2-v0.9.3 新增） 2.36 Resume/Status JSON 輸出與 Rovodev 整合（v0.9.4-v0.9.5 新增） 2.37 Git 擴充改為 Opt-in 與 Legacy 旗標全面移除（v0.10.0 重大變更） 2.38 整合狀態回報強化與 Extension Schema 新欄位（v0.10.1-v0.10.2 新增） 2.39 Data Model Diagram 擴充與 Preset 指令重構（v0.10.3-v0.10.4 新增） 2.40 Workflow Step Catalog 與 Zed 整合（v0.11.0 新增） 2.41 Workflow JSON 輸出強化與 Analyze Subagent 化（v0.11.1-v0.11.3 新增） 2.42 Bundle 系統 (Bundle System)（v0.11.4 新增） 2.43 ZCode 整合、PyPI 發布籌備與 Firebender 整合（v0.11.5-v0.11.6 新增） 2.44 OMP 整合與 Catalog SHA256 驗證（v0.11.7 新增） 2.45 Jira 整合進階與 Spec Roadmap 擴充（v0.11.8 新增） 2.46 多安裝安全與 GHES 認證修正（v0.11.9-v0.11.10 新增） 2.47 Community Bundle Submission 與 Monorepo 指南（v0.11.7-v0.11.10 新增） 2.48 Agent-Context 全面 Opt-in 與 Workflow Validation 強化（v0.12.0 重大變更） 2.49 Workflow 平行處理與 Python 腳本類型支援（v0.12.1-v0.12.4 新增） 2.50 生態系轉型:整合退場、Copilot Skills 棄用與 Catalog 安全性強化（v0.12.2-v0.12.6, v0.12.12 新增） 2.51 Bundle 版本管理強化與工作流引擎穩健性（v0.12.7-v0.12.11 新增） 2.52 治理與品質保證預設集擴充、社群目錄成長（v0.12.11-v0.12.15 新增） 第三章:使用流程詳細說明\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/ai%E9%96%8B%E7%99%BC/spec-kit%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Spec-Kit 使用教學手冊 版本: 14.0\n最後更新: 2026年7月15日\n適用於: Spec-Kit v0.12.15+ / Spec Kit Templates - 0.12.15\nCreated by: Eric Cheng\n📚 目錄 前言\n目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解\n1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備\n2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 2.7 擴充系統 (Extension System) 2.8 預設系統 (Presets System) 2.9 CLI 診斷指令 (doctor / status) 2.10 Plugin Architecture（v0.4.4-0.4.5 重大架構變革） 2.11 整合管理指令 (specify integration) 2.12 Git 擴充 (Bundled Git Extension) 2.13 工作流引擎 (Workflow Engine, v0.7.0) 2.14 \u0026ndash;integration 旗標（v0.7.1 取代 \u0026ndash;ai） 2.15 Self Management 指令（v0.7.5 新增，v0.9.3 正式實作完成） 2.16 預設組合策略 (Composition Strategies, v0.8.0) 2.17 Skills-Based Scaffolding（v0.8.0 新增） 2.18 feature.json 自訂分支支援（v0.8.1 新增） 2.19 \u0026ndash;no-git 旗標棄用與 GITHUB_TOKEN 認證（v0.8.2 新增） 2.20 目錄探索 CLI 與 Devin 整合（v0.8.3 新增） 2.21 Constitution 上下文載入與治理擴充（v0.8.4-v0.8.6 新增） 2.22 Lingma 整合與 Agent Orchestrator（v0.8.7 新增） 2.23 Config-Driven 認證與排程擴充（v0.8.8 新增） 2.24 治理生態系擴充與 BrownKit（v0.8.9 新增） 2.25 社群治理擴充與文件站遷移（v0.8.10 新增） 2.26 高保證規格工作流與版本特徵報告（v0.8.11 新增） 2.27 Integration Auto 與社群擴充更新（v0.8.12 新增） 2.28 工作流迴圈修正與代理工作流自動化（v0.8.13 新增） 2.29 CLI 重構與分支命名規範（v0.8.14 新增） 2.30 後執行 Hook 與 Token Budget（v0.8.15 新增） 2.31 Workflow Preset 與規格品質重驗證（v0.8.16 新增） 2.32 Hermes Agent 整合與社群文件整合（v0.8.17 新增） 2.33 Self Upgrade 正式實作與 SPECKIT_WORKFLOW_RUN_ID（v0.8.18-v0.9.0 新增） 2.34 Cline 原生整合與相容性修正（v0.9.1 新增） 2.35 Workflow Continue-On-Error 與 Self Upgrade 正式實作（v0.9.2-v0.9.3 新增） 2.36 Resume/Status JSON 輸出與 Rovodev 整合（v0.9.4-v0.9.5 新增） 2.37 Git 擴充改為 Opt-in 與 Legacy 旗標全面移除（v0.10.0 重大變更） 2.38 整合狀態回報強化與 Extension Schema 新欄位（v0.10.1-v0.10.2 新增） 2.39 Data Model Diagram 擴充與 Preset 指令重構（v0.10.3-v0.10.4 新增） 2.40 Workflow Step Catalog 與 Zed 整合（v0.11.0 新增） 2.41 Workflow JSON 輸出強化與 Analyze Subagent 化（v0.11.1-v0.11.3 新增） 2.42 Bundle 系統 (Bundle System)（v0.11.4 新增） 2.43 ZCode 整合、PyPI 發布籌備與 Firebender 整合（v0.11.5-v0.11.6 新增） 2.44 OMP 整合與 Catalog SHA256 驗證（v0.11.7 新增） 2.45 Jira 整合進階與 Spec Roadmap 擴充（v0.11.8 新增） 2.46 多安裝安全與 GHES 認證修正（v0.11.9-v0.11.10 新增） 2.47 Community Bundle Submission 與 Monorepo 指南（v0.11.7-v0.11.10 新增） 2.48 Agent-Context 全面 Opt-in 與 Workflow Validation 強化（v0.12.0 重大變更） 2.49 Workflow 平行處理與 Python 腳本類型支援（v0.12.1-v0.12.4 新增） 2.50 生態系轉型:整合退場、Copilot Skills 棄用與 Catalog 安全性強化（v0.12.2-v0.12.6, v0.12.12 新增） 2.51 Bundle 版本管理強化與工作流引擎穩健性（v0.12.7-v0.12.11 新增） 2.52 治理與品質保證預設集擴充、社群目錄成長（v0.12.11-v0.12.15 新增） 第三章:使用流程詳細說明\n","title":"spec-kit使用教學"},{"content":"Spec-Kit 使用教學手冊 版本: 1.0\n最後更新: 2025年10月29日\n適用於: Spec-Kit v0.0.79+ Created by: Eric Cheng\n📚 目錄 前言 目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解 1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備 2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 第三章:使用流程詳細說明 3.1 Step 1:撰寫 Spec (/speckit.specify) 3.2 Step 1a:澄清模糊需求 (/speckit.clarify) 3.3 Step 2:撰寫 Plan (/speckit.plan) 3.4 Step 3:拆分 Tasks (/speckit.tasks) 3.5 Step 4:預實作檢查 (/speckit.analyze + /speckit.checklist) 3.6 Step 5:實作 (/speckit.implement) 3.7 Step 6:迭代維護 第四章:實務案例與應用指引 4.1 案例一:Greenfield 開發 - 新建交易記錄微服務 4.2 案例二:Brownfield 整合 - 為既有系統新增功能 4.3 團隊協作:多人開發 4.4 AI 助手最佳實踐 4.5 平台導入建議 第五章:常見問題與陷阱 5.1 常見問題(FAQ) 5.2 常見陷阱與避免方法 第六章:附錄 6.1 完整模板範例 6.2 檢查清單 6.3 參考資源 6.4 術語表 6.5 快速指令參考 結語 前言 目的與適用對象 本手冊旨在幫助開發團隊快速掌握 Spec-Driven Development (SDD) 方法論,並透過 Spec-Kit 工具組與 AI 助手協作,建立高品質、可維護的軟體系統。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/spec-kit%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Spec-Kit 使用教學手冊 版本: 1.0\n最後更新: 2025年10月29日\n適用於: Spec-Kit v0.0.79+ Created by: Eric Cheng\n📚 目錄 前言 目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解 1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備 2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 第三章:使用流程詳細說明 3.1 Step 1:撰寫 Spec (/speckit.specify) 3.2 Step 1a:澄清模糊需求 (/speckit.clarify) 3.3 Step 2:撰寫 Plan (/speckit.plan) 3.4 Step 3:拆分 Tasks (/speckit.tasks) 3.5 Step 4:預實作檢查 (/speckit.analyze + /speckit.checklist) 3.6 Step 5:實作 (/speckit.implement) 3.7 Step 6:迭代維護 第四章:實務案例與應用指引 4.1 案例一:Greenfield 開發 - 新建交易記錄微服務 4.2 案例二:Brownfield 整合 - 為既有系統新增功能 4.3 團隊協作:多人開發 4.4 AI 助手最佳實踐 4.5 平台導入建議 第五章:常見問題與陷阱 5.1 常見問題(FAQ) 5.2 常見陷阱與避免方法 第六章:附錄 6.1 完整模板範例 6.2 檢查清單 6.3 參考資源 6.4 術語表 6.5 快速指令參考 結語 前言 目的與適用對象 本手冊旨在幫助開發團隊快速掌握 Spec-Driven Development (SDD) 方法論,並透過 Spec-Kit 工具組與 AI 助手協作,建立高品質、可維護的軟體系統。\n","title":"spec-kit使用教學"},{"content":"Spring Boot 教學手冊 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2025-08-31 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 目錄 Spring Boot 簡介\n1.1 什麼是 Spring Boot？ 1.2 Spring Boot 的核心特點 1.3 Spring Boot vs Spring Framework 1.4 專案常見應用場景 1.5 Spring Boot 版本選擇 1.6 章節小練習 1.7 實務注意事項 開發環境建置\n2.1 系統需求 2.2 JDK 安裝與設定 2.3 Maven 安裝與設定 2.4 IDE 設定 2.5 Spring Initializr 使用 2.6 開發工具設定 2.7 專案建立實作 2.8 執行與測試 2.9 章節小練習 2.10 實務注意事項 Spring Boot 基礎\n3.1 專案結構 3.2 Application Properties 設定 3.3 依賴注入 (Dependency Injection) 3.4 Spring Boot Starter 3.5 Bean 生命週期與作用域 3.6 Profile 環境管理 3.7 章節小練習 3.8 實務注意事項 RESTful API 開發\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/spring-boot-%E6%95%99%E5%AD%B8/","summary":"Spring Boot 教學手冊 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2025-08-31 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 目錄 Spring Boot 簡介\n1.1 什麼是 Spring Boot？ 1.2 Spring Boot 的核心特點 1.3 Spring Boot vs Spring Framework 1.4 專案常見應用場景 1.5 Spring Boot 版本選擇 1.6 章節小練習 1.7 實務注意事項 開發環境建置\n2.1 系統需求 2.2 JDK 安裝與設定 2.3 Maven 安裝與設定 2.4 IDE 設定 2.5 Spring Initializr 使用 2.6 開發工具設定 2.7 專案建立實作 2.8 執行與測試 2.9 章節小練習 2.10 實務注意事項 Spring Boot 基礎\n3.1 專案結構 3.2 Application Properties 設定 3.3 依賴注入 (Dependency Injection) 3.4 Spring Boot Starter 3.5 Bean 生命週期與作用域 3.6 Profile 環境管理 3.7 章節小練習 3.8 實務注意事項 RESTful API 開發\n","title":"Spring Boot 教學"},{"content":"Spring Framework 教學手冊 目錄 Spring Framework 概述\n1.1 什麼是 Spring Framework 1.2 Spring 生態系統 1.3 為什麼使用 Spring Framework 1.4 認證考點提示 1.5 實務案例 核心概念\n2.1 控制反轉 (Inversion of Control, IoC) 2.2 依賴注入 (Dependency Injection, DI) 2.3 Bean 的概念 IoC 容器與依賴注入\n3.1 IoC 容器深入解析 3.2 BeanFactory vs ApplicationContext 3.2.1 BeanFactory 3.2.2 ApplicationContext 3.3 Bean 定義與註冊 3.3.1 註解驅動的配置 3.3.2 Java 配置方式 3.4 依賴注入的進階特性 3.4.1 條件式注入 3.4.2 Qualifier 與 Primary 3.5 Bean 生命週期 3.6 ApplicationContext 事件機制 3.6.1 內建事件 3.6.2 自定義事件 3.7 認證考點提示 3.8 實務案例 Bean 管理\n4.1 Bean 的作用域 4.1.1 Singleton 作用域 4.1.2 Prototype 作用域 4.1.3 Web 作用域 4.2 Bean 的初始化和銷毀 4.2.1 初始化方法 4.2.2 銷毀方法 4.3 Bean 的延遲初始化 4.4 條件式 Bean 創建 4.4.1 內建條件註解 4.4.2 自定義條件 4.5 Profile 環境配置 4.6 Factory Bean 模式 4.7 認證考點提示 4.8 實務案例 面向切面程式設計 (AOP)\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/spring-framework%E6%95%99%E5%AD%B8/","summary":"Spring Framework 教學手冊 目錄 Spring Framework 概述\n1.1 什麼是 Spring Framework 1.2 Spring 生態系統 1.3 為什麼使用 Spring Framework 1.4 認證考點提示 1.5 實務案例 核心概念\n2.1 控制反轉 (Inversion of Control, IoC) 2.2 依賴注入 (Dependency Injection, DI) 2.3 Bean 的概念 IoC 容器與依賴注入\n3.1 IoC 容器深入解析 3.2 BeanFactory vs ApplicationContext 3.2.1 BeanFactory 3.2.2 ApplicationContext 3.3 Bean 定義與註冊 3.3.1 註解驅動的配置 3.3.2 Java 配置方式 3.4 依賴注入的進階特性 3.4.1 條件式注入 3.4.2 Qualifier 與 Primary 3.5 Bean 生命週期 3.6 ApplicationContext 事件機制 3.6.1 內建事件 3.6.2 自定義事件 3.7 認證考點提示 3.8 實務案例 Bean 管理\n4.1 Bean 的作用域 4.1.1 Singleton 作用域 4.1.2 Prototype 作用域 4.1.3 Web 作用域 4.2 Bean 的初始化和銷毀 4.2.1 初始化方法 4.2.2 銷毀方法 4.3 Bean 的延遲初始化 4.4 條件式 Bean 創建 4.4.1 內建條件註解 4.4.2 自定義條件 4.5 Profile 環境配置 4.6 Factory Bean 模式 4.7 認證考點提示 4.8 實務案例 面向切面程式設計 (AOP)\n","title":"Spring Framework教學"},{"content":"SQL 使用教學手冊 目錄 1. SQL 基礎入門 1.1 什麼是 SQL？ 1.2 SQL 的特點 1.3 SQL 語句分類 1.4 第一個 SQL 查詢 2. 資料庫基本概念 2.1 關聯式資料庫模型 2.2 基本概念解釋 2.3 資料類型 2.4 正規化（Normalization） 3. 基本查詢語法 3.1 SELECT 語句基礎 3.2 查詢所有欄位 3.3 查詢特定欄位 3.4 WHERE 條件查詢 3.5 排序 ORDER BY 3.6 限制結果筆數 3.7 去除重複 DISTINCT 4. 進階查詢技巧 4.1 聚合函數 4.2 GROUP BY 分組查詢 4.3 HAVING 分組篩選 4.4 JOIN 表格連接 4.5 子查詢（Subquery） 4.6 WITH 公用表格表達式（CTE） 4.7 視窗函數（Window Functions） 5. 資料操作語言 (DML) 5.1 INSERT - 新增資料 5.2 UPDATE - 更新資料 5.3 DELETE - 刪除資料 5.4 UPSERT - 插入或更新 5.5 批次處理最佳實務 6. 資料定義語言 (DDL) 6.1 CREATE - 建立資料庫物件 6.2 ALTER - 修改資料庫物件 6.3 DROP - 刪除資料庫物件 6.4 TRUNCATE - 清空表格 6.5 資料類型選擇指南 6.6 表格設計最佳實務 6.7 效能考量 7. 交易處理與併發控制 7.1 交易基本概念 7.2 交易控制語句 7.3 交易隔離等級 7.4 併發問題與解決方案 7.5 鎖定機制 7.6 實務交易處理模式 8. 索引與效能優化 8.1 索引基本概念 8.2 索引類型 8.3 索引設計策略 8.4 查詢效能分析 8.5 查詢優化技巧 8.6 分割與分片 8.7 效能監控與維護 9. 儲存程序與函數 9.1 儲存程序基礎 9.2 函數 9.3 控制流程結構 9.4 例外處理 10. 安全性與防護 10.1 SQL Injection 防護 10.2 存取控制與權限管理 10.3 資料加密 10.4 稽核與監控 11. 專案實務案例 11.1 電商系統資料庫設計 11.2 常用業務查詢 11.3 效能優化實作 12. 認證考試準備 12.1 Oracle SQL 認證要點 12.2 Microsoft SQL Server 認證要點 12.3 PostgreSQL 認證要點 12.4 IBM DB2 認證要點 12.5 認證考試技巧 13. 最佳實務與故障排除 13.1 常見錯誤與解決方案 13.2 效能優化建議 13.3 開發最佳實務 13.4 資源推薦 前言 歡迎來到 SQL 的世界！SQL（Structured Query Language，結構化查詢語言）是與資料庫溝通的標準語言。無論您是新進的開發同仁，還是希望深化資料庫技能的工程師，這份教學手冊都將帶您從零開始，循序漸進地掌握 SQL 的精髓。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/sql%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"SQL 使用教學手冊 目錄 1. SQL 基礎入門 1.1 什麼是 SQL？ 1.2 SQL 的特點 1.3 SQL 語句分類 1.4 第一個 SQL 查詢 2. 資料庫基本概念 2.1 關聯式資料庫模型 2.2 基本概念解釋 2.3 資料類型 2.4 正規化（Normalization） 3. 基本查詢語法 3.1 SELECT 語句基礎 3.2 查詢所有欄位 3.3 查詢特定欄位 3.4 WHERE 條件查詢 3.5 排序 ORDER BY 3.6 限制結果筆數 3.7 去除重複 DISTINCT 4. 進階查詢技巧 4.1 聚合函數 4.2 GROUP BY 分組查詢 4.3 HAVING 分組篩選 4.4 JOIN 表格連接 4.5 子查詢（Subquery） 4.6 WITH 公用表格表達式（CTE） 4.7 視窗函數（Window Functions） 5. 資料操作語言 (DML) 5.1 INSERT - 新增資料 5.2 UPDATE - 更新資料 5.3 DELETE - 刪除資料 5.4 UPSERT - 插入或更新 5.5 批次處理最佳實務 6. 資料定義語言 (DDL) 6.1 CREATE - 建立資料庫物件 6.2 ALTER - 修改資料庫物件 6.3 DROP - 刪除資料庫物件 6.4 TRUNCATE - 清空表格 6.5 資料類型選擇指南 6.6 表格設計最佳實務 6.7 效能考量 7. 交易處理與併發控制 7.1 交易基本概念 7.2 交易控制語句 7.3 交易隔離等級 7.4 併發問題與解決方案 7.5 鎖定機制 7.6 實務交易處理模式 8. 索引與效能優化 8.1 索引基本概念 8.2 索引類型 8.3 索引設計策略 8.4 查詢效能分析 8.5 查詢優化技巧 8.6 分割與分片 8.7 效能監控與維護 9. 儲存程序與函數 9.1 儲存程序基礎 9.2 函數 9.3 控制流程結構 9.4 例外處理 10. 安全性與防護 10.1 SQL Injection 防護 10.2 存取控制與權限管理 10.3 資料加密 10.4 稽核與監控 11. 專案實務案例 11.1 電商系統資料庫設計 11.2 常用業務查詢 11.3 效能優化實作 12. 認證考試準備 12.1 Oracle SQL 認證要點 12.2 Microsoft SQL Server 認證要點 12.3 PostgreSQL 認證要點 12.4 IBM DB2 認證要點 12.5 認證考試技巧 13. 最佳實務與故障排除 13.1 常見錯誤與解決方案 13.2 效能優化建議 13.3 開發最佳實務 13.4 資源推薦 前言 歡迎來到 SQL 的世界！SQL（Structured Query Language，結構化查詢語言）是與資料庫溝通的標準語言。無論您是新進的開發同仁，還是希望深化資料庫技能的工程師，這份教學手冊都將帶您從零開始，循序漸進地掌握 SQL 的精髓。\n","title":"SQL使用教學"},{"content":"SSDLC 專案範本指南 簡介 本指南提供安全軟體開發生命週期 (Secure Software Development Life Cycle, SSDLC) 的完整範本體系，旨在協助團隊透過 AI 輔助完成專案的各個階段開發任務。\nSSDLC 階段概覽 1. 需求分析階段 (Requirements Analysis) 目標: 收集、分析並定義專案需求，建立安全需求規範\n工作項目 業務需求收集 功能需求分析 非功能需求定義 安全需求識別 使用者故事撰寫 風險評估 技術細節和業務需求 需求追溯矩陣 安全威脅模型分析 合規性要求檢查 效能基準定義 2. 設計開發階段 (Design \u0026amp; Development) 目標: 進行系統架構設計和安全編碼實作\n工作項目 系統架構設計 安全架構設計 資料庫設計 API 設計 編碼實作 程式碼審查 技術細節和業務需求 設計模式應用 安全編碼標準 程式碼品質標準 版本控制策略 3. 測試驗收階段 (Testing \u0026amp; Validation) 目標: 執行全面測試並進行安全驗證\n工作項目 單元測試 整合測試 系統測試 效能測試 安全測試 使用者驗收測試 技術細節和業務需求 測試策略制定 自動化測試框架 安全測試工具 測試覆蓋率要求 4. 部署運維階段 (Deployment \u0026amp; Operations) 目標: 安全部署系統並建立持續監控機制\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/ssdlc_%E5%B0%88%E6%A1%88%E7%AF%84%E6%9C%AC%E6%8C%87%E5%8D%97/","summary":"SSDLC 專案範本指南 簡介 本指南提供安全軟體開發生命週期 (Secure Software Development Life Cycle, SSDLC) 的完整範本體系，旨在協助團隊透過 AI 輔助完成專案的各個階段開發任務。\nSSDLC 階段概覽 1. 需求分析階段 (Requirements Analysis) 目標: 收集、分析並定義專案需求，建立安全需求規範\n工作項目 業務需求收集 功能需求分析 非功能需求定義 安全需求識別 使用者故事撰寫 風險評估 技術細節和業務需求 需求追溯矩陣 安全威脅模型分析 合規性要求檢查 效能基準定義 2. 設計開發階段 (Design \u0026amp; Development) 目標: 進行系統架構設計和安全編碼實作\n工作項目 系統架構設計 安全架構設計 資料庫設計 API 設計 編碼實作 程式碼審查 技術細節和業務需求 設計模式應用 安全編碼標準 程式碼品質標準 版本控制策略 3. 測試驗收階段 (Testing \u0026amp; Validation) 目標: 執行全面測試並進行安全驗證\n工作項目 單元測試 整合測試 系統測試 效能測試 安全測試 使用者驗收測試 技術細節和業務需求 測試策略制定 自動化測試框架 安全測試工具 測試覆蓋率要求 4. 部署運維階段 (Deployment \u0026amp; Operations) 目標: 安全部署系統並建立持續監控機制\n","title":"SSDLC_專案範本指南"},{"content":"Thymeleaf 使用教學手冊 目錄 基礎概念\n1.1 什麼是 Thymeleaf？ 1.2 核心特色 1.2.1 自然模板特性 1.2.2 表達式豐富性 1.3 與其他模板引擎比較 1.3.1 詳細比較表 1.4 適用場景 1.5 工作流程 1.6 實務注意事項 環境建置\n2.1 Spring Boot 專案整合 2.1.1 Maven 設定 2.1.2 Gradle 設定 2.2 目錄結構設定 2.3 應用程式設定 2.3.1 基本設定 (application.yml) 2.3.2 生產環境設定 (application-prod.yml) 2.4 IDE 設定 2.4.1 IntelliJ IDEA 設定 2.4.2 VS Code 設定 2.5 驗證安裝 2.5.1 建立控制器 2.5.2 建立模板 2.5.3 啟動應用程式 2.6 開發環境最佳化 2.6.1 熱重載設定 2.6.2 除錯設定 2.7 常見安裝問題 語法教學\n3.1 基本標籤語法 3.1.1 文字輸出 (th:text) 3.1.2 HTML 輸出 (th:utext) 3.1.3 條件判斷 (th:if, th:unless) 3.1.4 迴圈遍歷 (th:each) 3.1.5 條件選擇 (th:switch, th:case) 3.2 屬性處理 3.2.1 設定屬性 (th:attr) 3.2.2 常用屬性快捷方式 3.2.3 CSS 類別處理 (th:classappend) 3.3 表達式語法 3.3.1 變數表達式 (${\u0026hellip;}) 3.3.2 選擇表達式 (*{\u0026hellip;}) 3.3.3 連結表達式 (@{\u0026hellip;}) 3.3.4 訊息表達式 (#{\u0026hellip;}) 3.3.5 片段表達式 (~{\u0026hellip;}) 3.4 內建工具物件 3.4.1 日期工具 (#dates) 3.4.2 數字工具 (#numbers) 3.4.3 字串工具 (#strings) 3.4.4 集合工具 (#lists, #sets, #maps) 3.5 實務注意事項 3.6 模板繼承與片段 3.6.1 片段定義與使用 (th:fragment) 3.6.2 片段插入方式 3.6.3 佈局模板系統 3.6.4 參數化片段 3.6.5 片段選擇器 3.7 實務注意事項 3.8 表單處理 3.8.1 基本表單綁定 3.8.2 下拉選單處理 3.8.3 核取方塊處理 3.8.4 單選按鈕處理 3.8.5 檔案上傳處理 3.8.6 表單驗證錯誤處理 3.9 國際化 (i18n) 支援 3.9.1 設定國際化 3.9.2 訊息資源檔案 3.9.3 在模板中使用國際化 3.9.4 Java 程式碼中的國際化 3.9.5 日期和數字本地化 3.9.6 進階國際化實作 3.9.7 多語言最佳實務 3.10 實務注意事項 實務應用範例\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/thymeleaf%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Thymeleaf 使用教學手冊 目錄 基礎概念\n1.1 什麼是 Thymeleaf？ 1.2 核心特色 1.2.1 自然模板特性 1.2.2 表達式豐富性 1.3 與其他模板引擎比較 1.3.1 詳細比較表 1.4 適用場景 1.5 工作流程 1.6 實務注意事項 環境建置\n2.1 Spring Boot 專案整合 2.1.1 Maven 設定 2.1.2 Gradle 設定 2.2 目錄結構設定 2.3 應用程式設定 2.3.1 基本設定 (application.yml) 2.3.2 生產環境設定 (application-prod.yml) 2.4 IDE 設定 2.4.1 IntelliJ IDEA 設定 2.4.2 VS Code 設定 2.5 驗證安裝 2.5.1 建立控制器 2.5.2 建立模板 2.5.3 啟動應用程式 2.6 開發環境最佳化 2.6.1 熱重載設定 2.6.2 除錯設定 2.7 常見安裝問題 語法教學\n3.1 基本標籤語法 3.1.1 文字輸出 (th:text) 3.1.2 HTML 輸出 (th:utext) 3.1.3 條件判斷 (th:if, th:unless) 3.1.4 迴圈遍歷 (th:each) 3.1.5 條件選擇 (th:switch, th:case) 3.2 屬性處理 3.2.1 設定屬性 (th:attr) 3.2.2 常用屬性快捷方式 3.2.3 CSS 類別處理 (th:classappend) 3.3 表達式語法 3.3.1 變數表達式 (${\u0026hellip;}) 3.3.2 選擇表達式 (*{\u0026hellip;}) 3.3.3 連結表達式 (@{\u0026hellip;}) 3.3.4 訊息表達式 (#{\u0026hellip;}) 3.3.5 片段表達式 (~{\u0026hellip;}) 3.4 內建工具物件 3.4.1 日期工具 (#dates) 3.4.2 數字工具 (#numbers) 3.4.3 字串工具 (#strings) 3.4.4 集合工具 (#lists, #sets, #maps) 3.5 實務注意事項 3.6 模板繼承與片段 3.6.1 片段定義與使用 (th:fragment) 3.6.2 片段插入方式 3.6.3 佈局模板系統 3.6.4 參數化片段 3.6.5 片段選擇器 3.7 實務注意事項 3.8 表單處理 3.8.1 基本表單綁定 3.8.2 下拉選單處理 3.8.3 核取方塊處理 3.8.4 單選按鈕處理 3.8.5 檔案上傳處理 3.8.6 表單驗證錯誤處理 3.9 國際化 (i18n) 支援 3.9.1 設定國際化 3.9.2 訊息資源檔案 3.9.3 在模板中使用國際化 3.9.4 Java 程式碼中的國際化 3.9.5 日期和數字本地化 3.9.6 進階國際化實作 3.9.7 多語言最佳實務 3.10 實務注意事項 實務應用範例\n","title":"Thymeleaf使用教學"},{"content":"UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。\n角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。\n任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計：\n1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** \u0026#34;[一段描述使用者在什麼情況下會使用這個產品的情境故事]\u0026#34; ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/ui_ux%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。\n角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。\n任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計：\n1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** \u0026#34;[一段描述使用者在什麼情況下會使用這個產品的情境故事]\u0026#34; ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定\n","title":"UI_UX設計指引範本"},{"content":"UI/UX 開發指引 目錄 文件概述 設計原則 1.1 銀行系統的安全性與一致性要求 1.2 清晰的資訊層次與導航設計 1.3 金融資料顯示與重點突顯規範 1.4 無障礙設計（WCAG 2.1 AA 級） 1.5 多語系支援 UI 元件規範 2.1 樣式系統 (Design System) 2.2 響應式設計規範 2.3 常用元件設計 UX 流程規範 3.1 表單驗證與錯誤回饋 3.2 使用者引導 (Onboarding) 3.3 搜尋、篩選與排序互動設計 3.4 資料載入與狀態設計 設計資產與交付 4.1 設計 Token 系統 4.2 元件庫架構 Vue 3 + Tailwind CSS 最佳實踐 5.1 元件命名與結構規範 5.2 Tailwind CSS 自定義配置 檢測與驗證 6.1 視覺回歸測試 6.2 無障礙檢測 6.3 使用性測試清單 性能優化指引 設計協作流程 維護與版本控制 附錄 文件概述 本指引適用於大型金融共用平台的前端 UI/UX 開發，涵蓋設計原則、UI 元件規範、UX 流程、設計資產交付等完整內容。\n專案技術堆疊 前端架構: 微前端 + SPA (Single-Page App\u0026mdash; 第一部分完成，接下來我將繼續撰寫第二部分：無障礙設計和多語系支援。\n1.4 無障礙設計（WCAG 2.1 AA 級） 色彩對比度要求 正常文字: 對比度至少 4.5:1 大文字 (18pt 以上): 對比度至少 3:1 互動元件: 對比度至少 3:1 /* Tailwind CSS 無障礙色彩配置 */ .text-primary { @apply text-gray-900; /* 對比度 21:1 */ } .text-secondary { @apply text-gray-700; /* 對比度 9.2:1 */ } .bg-interactive { @apply bg-blue-600 hover:bg-blue-700 focus:bg-blue-700; } .bg-interactive:focus { @apply ring-2 ring-blue-500 ring-offset-2; } 鍵盤操作支援 Tab 順序: 邏輯性的焦點移動順序 快捷鍵: 主要功能提供鍵盤快捷鍵 焦點指示: 清晰的焦點視覺回饋 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙表單範例 --\u0026gt; \u0026lt;form @submit.prevent=\u0026#34;handleSubmit\u0026#34; class=\u0026#34;space-y-6\u0026#34;\u0026gt; \u0026lt;div\u0026gt; \u0026lt;label for=\u0026#34;account-number\u0026#34; class=\u0026#34;block text-sm font-medium text-gray-700\u0026#34;\u0026gt; 帳戶號碼 \u0026lt;span class=\u0026#34;text-red-500\u0026#34; aria-label=\u0026#34;必填欄位\u0026#34;\u0026gt;*\u0026lt;/span\u0026gt; \u0026lt;/label\u0026gt; \u0026lt;input id=\u0026#34;account-number\u0026#34; v-model=\u0026#34;accountNumber\u0026#34; type=\u0026#34;text\u0026#34; required aria-describedby=\u0026#34;account-help account-error\u0026#34; class=\u0026#34;mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500\u0026#34; :aria-invalid=\u0026#34;hasError\u0026#34; /\u0026gt; \u0026lt;p id=\u0026#34;account-help\u0026#34; class=\u0026#34;mt-2 text-sm text-gray-500\u0026#34;\u0026gt; 請輸入 12 位數字帳戶號碼 \u0026lt;/p\u0026gt; \u0026lt;p id=\u0026#34;account-error\u0026#34; v-if=\u0026#34;errorMessage\u0026#34; class=\u0026#34;mt-2 text-sm text-red-600\u0026#34; role=\u0026#34;alert\u0026#34;\u0026gt; {{ errorMessage }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/form\u0026gt; \u0026lt;/template\u0026gt; 螢幕閱讀器支援 語義化 HTML: 使用適當的 HTML 語義標籤 ARIA 標籤: 補充無障礙資訊 替代文字: 圖片提供有意義的 alt 文字 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙數據表格 --\u0026gt; \u0026lt;table role=\u0026#34;table\u0026#34; aria-label=\u0026#34;帳戶交易記錄\u0026#34;\u0026gt; \u0026lt;caption class=\u0026#34;sr-only\u0026#34;\u0026gt; 最近 10 筆交易記錄，包含日期、摘要、金額和餘額 \u0026lt;/caption\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 交易日期 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 摘要 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-right text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 金額 \u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr v-for=\u0026#34;transaction in transactions\u0026#34; :key=\u0026#34;transaction.id\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ formatDate(transaction.date) }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ transaction.description }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-right\u0026#34;\u0026gt; \u0026lt;span :class=\u0026#34;transaction.amount \u0026gt;= 0 ? \u0026#39;text-green-600\u0026#39; : \u0026#39;text-red-600\u0026#39;\u0026#34;\u0026gt; {{ formatCurrency(transaction.amount) }} \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; \u0026lt;/template\u0026gt; 1.5 多語系支援 語言切換機制 // i18n 配置 import { createI18n } from \u0026#39;vue-i18n\u0026#39;; interface Messages { \u0026#39;zh-TW\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;en-US\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;ja-JP\u0026#39;: Record\u0026lt;string, any\u0026gt;; } const messages: Messages = { \u0026#39;zh-TW\u0026#39;: { common: { confirm: \u0026#39;確認\u0026#39;, cancel: \u0026#39;取消\u0026#39;, save: \u0026#39;儲存\u0026#39;, delete: \u0026#39;刪除\u0026#39;, loading: \u0026#39;載入中...\u0026#39; }, account: { balance: \u0026#39;帳戶餘額\u0026#39;, transfer: \u0026#39;轉帳\u0026#39;, history: \u0026#39;交易記錄\u0026#39; } }, \u0026#39;en-US\u0026#39;: { common: { confirm: \u0026#39;Confirm\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, save: \u0026#39;Save\u0026#39;, delete: \u0026#39;Delete\u0026#39;, loading: \u0026#39;Loading...\u0026#39; }, account: { balance: \u0026#39;Account Balance\u0026#39;, transfer: \u0026#39;Transfer\u0026#39;, history: \u0026#39;Transaction History\u0026#39; } } }; export const i18n = createI18n({ locale: \u0026#39;zh-TW\u0026#39;, fallbackLocale: \u0026#39;en-US\u0026#39;, messages }); 文字方向支援 (RTL/LTR) \u0026lt;template\u0026gt; \u0026lt;div :dir=\u0026#34;currentLocale.dir\u0026#34; class=\u0026#34;app-container\u0026#34;\u0026gt; \u0026lt;!-- 語言切換器 --\u0026gt; \u0026lt;div class=\u0026#34;language-selector\u0026#34;\u0026gt; \u0026lt;select v-model=\u0026#34;currentLanguage\u0026#34; @change=\u0026#34;changeLanguage\u0026#34; class=\u0026#34;block w-32 rounded-md border-gray-300\u0026#34; :aria-label=\u0026#34;$t(\u0026#39;common.selectLanguage\u0026#39;)\u0026#34; \u0026gt; \u0026lt;option value=\u0026#34;zh-TW\u0026#34;\u0026gt;繁體中文\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;en-US\u0026#34;\u0026gt;English\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;ar-SA\u0026#34;\u0026gt;العربية\u0026lt;/option\u0026gt; \u0026lt;/select\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed } from \u0026#39;vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; const { locale, t } = useI18n(); const localeConfig = { \u0026#39;zh-TW\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;繁體中文\u0026#39; }, \u0026#39;en-US\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;English\u0026#39; }, \u0026#39;ar-SA\u0026#39;: { dir: \u0026#39;rtl\u0026#39;, name: \u0026#39;العربية\u0026#39; } }; const currentLocale = computed(() =\u0026gt; localeConfig[locale.value]); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* RTL 支援樣式 */ [dir=\u0026#34;rtl\u0026#34;] .text-left { text-align: right; } [dir=\u0026#34;rtl\u0026#34;] .text-right { text-align: left; } [dir=\u0026#34;rtl\u0026#34;] .ml-4 { margin-left: 0; margin-right: 1rem; } \u0026lt;/style\u0026gt; 數字與日期本地化 // 本地化格式化工具 export class LocaleFormatter { private locale: string; constructor(locale: string) { this.locale = locale; } // 金額格式化 formatCurrency(amount: number, currency: string = \u0026#39;TWD\u0026#39;): string { const currencyMap = { \u0026#39;zh-TW\u0026#39;: \u0026#39;TWD\u0026#39;, \u0026#39;en-US\u0026#39;: \u0026#39;USD\u0026#39;, \u0026#39;ja-JP\u0026#39;: \u0026#39;JPY\u0026#39;, \u0026#39;ko-KR\u0026#39;: \u0026#39;KRW\u0026#39; }; return new Intl.NumberFormat(this.locale, { style: \u0026#39;currency\u0026#39;, currency: currencyMap[this.locale] || currency, minimumFractionDigits: currency === \u0026#39;JPY\u0026#39; ? 0 : 2 }).format(amount); } // 日期格式化 formatDate(date: Date, options?: Intl.DateTimeFormatOptions): string { const defaultOptions: Intl.DateTimeFormatOptions = { year: \u0026#39;numeric\u0026#39;, month: \u0026#39;short\u0026#39;, day: \u0026#39;numeric\u0026#39; }; return new Intl.DateTimeFormat(this.locale, options || defaultOptions).format(date); } // 時間格式化 formatTime(date: Date): string { return new Intl.DateTimeFormat(this.locale, { hour: \u0026#39;2-digit\u0026#39;, minute: \u0026#39;2-digit\u0026#39;, hour12: this.locale === \u0026#39;en-US\u0026#39; }).format(date); } // 百分比格式化 formatPercentage(value: number): string { return new Intl.NumberFormat(this.locale, { style: \u0026#39;percent\u0026#39;, minimumFractionDigits: 2, maximumFractionDigits: 2 }).format(value); } } 進階無障礙設計實作 \u0026lt;template\u0026gt; \u0026lt;!-- 高對比模式切換 --\u0026gt; \u0026lt;div class=\u0026#34;accessibility-controls fixed top-4 right-4 z-50\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleHighContrast\u0026#34; :aria-pressed=\u0026#34;isHighContrast\u0026#34; class=\u0026#34;p-2 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; :class=\u0026#34;isHighContrast ? \u0026#39;bg-yellow-400 text-black\u0026#39; : \u0026#39;bg-white text-gray-700 shadow-md\u0026#39;\u0026#34; aria-label=\u0026#34;切換高對比模式\u0026#34; \u0026gt; \u0026lt;EyeIcon class=\u0026#34;h-5 w-5\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;!-- 字體大小調整 --\u0026gt; \u0026lt;div class=\u0026#34;mt-2 flex flex-col space-y-1\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;increaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;增大字體\u0026#34; \u0026gt; A\u0026#43; \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;decreaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;縮小字體\u0026#34; \u0026gt; A- \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;resetFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;重設字體大小\u0026#34; \u0026gt; A \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 跳至主要內容連結 --\u0026gt; \u0026lt;a href=\u0026#34;#main-content\u0026#34; class=\u0026#34;sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 bg-blue-600 text-white px-4 py-2 rounded-md z-50\u0026#34; \u0026gt; 跳至主要內容 \u0026lt;/a\u0026gt; \u0026lt;!-- 焦點陷阱對話框範例 --\u0026gt; \u0026lt;div v-if=\u0026#34;showModal\u0026#34; class=\u0026#34;fixed inset-0 z-10 overflow-y-auto\u0026#34; role=\u0026#34;dialog\u0026#34; aria-modal=\u0026#34;true\u0026#34; :aria-labelledby=\u0026#34;modalTitleId\u0026#34; @keydown.esc=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;flex items-end justify-center min-h-screen pt-4 px-4 pb-20 text-center sm:block sm:p-0\u0026#34;\u0026gt; \u0026lt;!-- 背景遮罩 --\u0026gt; \u0026lt;div class=\u0026#34;fixed inset-0 transition-opacity\u0026#34; aria-hidden=\u0026#34;true\u0026#34; @click=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;absolute inset-0 bg-gray-500 opacity-75\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 對話框內容 --\u0026gt; \u0026lt;div ref=\u0026#34;modalContent\u0026#34; class=\u0026#34;inline-block align-bottom bg-white rounded-lg text-left overflow-hidden shadow-xl transform transition-all sm:my-8 sm:align-middle sm:max-w-lg sm:w-full\u0026#34; @keydown=\u0026#34;handleModalKeydown\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;bg-white px-4 pt-5 pb-4 sm:p-6 sm:pb-4\u0026#34;\u0026gt; \u0026lt;h3 :id=\u0026#34;modalTitleId\u0026#34; class=\u0026#34;text-lg leading-6 font-medium text-gray-900 mb-4\u0026#34;\u0026gt; 確認操作 \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm text-gray-500 mb-4\u0026#34;\u0026gt; 您確定要執行此操作嗎？此動作無法復原。 \u0026lt;/p\u0026gt; \u0026lt;!-- 焦點陷阱內的可互動元素 --\u0026gt; \u0026lt;div class=\u0026#34;flex justify-end space-x-3\u0026#34;\u0026gt; \u0026lt;button ref=\u0026#34;cancelButton\u0026#34; @click=\u0026#34;closeModal\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-gray-700 bg-white border border-gray-300 rounded-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; \u0026gt; 取消 \u0026lt;/button\u0026gt; \u0026lt;button ref=\u0026#34;confirmButton\u0026#34; @click=\u0026#34;handleConfirm\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-white bg-red-600 border border-transparent rounded-md hover:bg-red-700 focus:outline-none focus:ring-2 focus:ring-red-500\u0026#34; \u0026gt; 確認 \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { ref, nextTick, onMounted, onUnmounted } from \u0026#39;vue\u0026#39;; import { EyeIcon } from \u0026#39;@heroicons/vue/24/outline\u0026#39;; // 無障礙狀態管理 const isHighContrast = ref(false); const fontSize = ref(16); const showModal = ref(false); const modalTitleId = ref(`modal-title-${Math.random().toString(36).substr(2, 9)}`); // 高對比模式 const toggleHighContrast = () =\u0026gt; { isHighContrast.value = !isHighContrast.value; document.documentElement.classList.toggle(\u0026#39;high-contrast\u0026#39;, isHighContrast.value); // 儲存使用者偏好 localStorage.setItem(\u0026#39;high-contrast\u0026#39;, isHighContrast.value.toString()); // 通知螢幕閱讀器 announceToScreenReader( isHighContrast.value ? \u0026#39;已開啟高對比模式\u0026#39; : \u0026#39;已關閉高對比模式\u0026#39; ); }; // 字體大小調整 const increaseFontSize = () =\u0026gt; { if (fontSize.value \u0026lt; 24) { fontSize.value \u0026#43;= 2; updateFontSize(); } }; const decreaseFontSize = () =\u0026gt; { if (fontSize.value \u0026gt; 12) { fontSize.value -= 2; updateFontSize(); } }; const resetFontSize = () =\u0026gt; { fontSize.value = 16; updateFontSize(); }; const updateFontSize = () =\u0026gt; { document.documentElement.style.fontSize = `${fontSize.value}px`; localStorage.setItem(\u0026#39;font-size\u0026#39;, fontSize.value.toString()); announceToScreenReader(`字體大小已調整為 ${fontSize.value} 像素`); }; // 螢幕閱讀器公告 const announceToScreenReader = (message: string) =\u0026gt; { const announcement = document.createElement(\u0026#39;div\u0026#39;); announcement.setAttribute(\u0026#39;aria-live\u0026#39;, \u0026#39;polite\u0026#39;); announcement.setAttribute(\u0026#39;aria-atomic\u0026#39;, \u0026#39;true\u0026#39;); announcement.className = \u0026#39;sr-only\u0026#39;; announcement.textContent = message; document.body.appendChild(announcement); setTimeout(() =\u0026gt; { document.body.removeChild(announcement); }, 1000); }; // 焦點陷阱管理 const modalContent = ref\u0026lt;HTMLElement\u0026gt;(); const cancelButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const confirmButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const focusableElements: HTMLElement[] = []; let previousFocusedElement: HTMLElement | null = null; const openModal = async () =\u0026gt; { previousFocusedElement = document.activeElement as HTMLElement; showModal.value = true; await nextTick(); // 收集可聚焦元素 const selector = \u0026#39;button, [href], input, select, textarea, [tabindex]:not([tabindex=\u0026#34;-1\u0026#34;])\u0026#39;; focusableElements.splice(0); focusableElements.push( ...Array.from(modalContent.value?.querySelectorAll(selector) || []) ); // 聚焦第一個元素 if (focusableElements.length \u0026gt; 0) { focusableElements[0].focus(); } }; const closeModal = () =\u0026gt; { showModal.value = false; // 恢復之前的焦點 if (previousFocusedElement) { previousFocusedElement.focus(); } }; const handleModalKeydown = (event: KeyboardEvent) =\u0026gt; { if (event.key === \u0026#39;Tab\u0026#39;) { const currentIndex = focusableElements.indexOf(event.target as HTMLElement); if (event.shiftKey) { // Shift \u0026#43; Tab (向後) if (currentIndex \u0026lt;= 0) { event.preventDefault(); focusableElements[focusableElements.length - 1].focus(); } } else { // Tab (向前) if (currentIndex \u0026gt;= focusableElements.length - 1) { event.preventDefault(); focusableElements[0].focus(); } } } }; const handleConfirm = () =\u0026gt; { // 處理確認邏輯 announceToScreenReader(\u0026#39;操作已確認\u0026#39;); closeModal(); }; // 鍵盤快捷鍵 const handleGlobalKeydown = (event: KeyboardEvent) =\u0026gt; { // Alt \u0026#43; H: 開啟高對比模式 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;h\u0026#39;) { event.preventDefault(); toggleHighContrast(); } // Alt \u0026#43; \u0026#43;: 增大字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;\u0026#43;\u0026#39;) { event.preventDefault(); increaseFontSize(); } // Alt \u0026#43; -: 縮小字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;-\u0026#39;) { event.preventDefault(); decreaseFontSize(); } }; // 初始化無障礙設定 onMounted(() =\u0026gt; { // 載入儲存的偏好設定 const savedHighContrast = localStorage.getItem(\u0026#39;high-contrast\u0026#39;); if (savedHighContrast === \u0026#39;true\u0026#39;) { isHighContrast.value = true; document.documentElement.classList.add(\u0026#39;high-contrast\u0026#39;); } const savedFontSize = localStorage.getItem(\u0026#39;font-size\u0026#39;); if (savedFontSize) { fontSize.value = parseInt(savedFontSize); document.documentElement.style.fontSize = `${fontSize.value}px`; } // 監聽全域鍵盤事件 document.addEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); // 檢測用戶偏好的配色方案 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-color-scheme: dark)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;dark-mode\u0026#39;); } // 檢測用戶偏好的動畫設定 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-reduced-motion: reduce)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;reduce-motion\u0026#39;); } }); onUnmounted(() =\u0026gt; { document.removeEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); }); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* 高對比模式樣式 */ .high-contrast { filter: contrast(150%) saturate(200%); } .high-contrast button { border: 2px solid currentColor !important; } .high-contrast a { text-decoration: underline !important; } /* 減少動畫模式 */ .reduce-motion *, .reduce-motion *::before, .reduce-motion *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } /* 深色模式支援 */ .dark-mode { color-scheme: dark; } /* 螢幕閱讀器專用隱藏 */ .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .sr-only.focus:focus { position: static; width: auto; height: auto; padding: inherit; margin: inherit; overflow: visible; clip: auto; white-space: normal; } \u0026lt;/style\u0026gt; 多語系內容管理策略 // 多語系內容管理 interface TranslationKey { key: string; context?: string; pluralization?: boolean; interpolation?: string[]; } interface TranslationContent { [locale: string]: { [namespace: string]: { [key: string]: string | object; }; }; } // 翻譯內容結構化管理 export const translationStructure: TranslationContent = { \u0026#39;zh-TW\u0026#39;: { common: { // 通用操作 actions: { save: \u0026#39;儲存\u0026#39;, cancel: \u0026#39;取消\u0026#39;, confirm: \u0026#39;確認\u0026#39;, delete: \u0026#39;刪除\u0026#39;, edit: \u0026#39;編輯\u0026#39;, add: \u0026#39;新增\u0026#39;, search: \u0026#39;搜尋\u0026#39;, filter: \u0026#39;篩選\u0026#39;, sort: \u0026#39;排序\u0026#39;, refresh: \u0026#39;重新整理\u0026#39;, loading: \u0026#39;載入中...\u0026#39;, noData: \u0026#39;無資料\u0026#39;, error: \u0026#39;發生錯誤\u0026#39; }, // 表單相關 form: { required: \u0026#39;此欄位為必填\u0026#39;, invalid: \u0026#39;格式不正確\u0026#39;, tooShort: \u0026#39;長度不足\u0026#39;, tooLong: \u0026#39;長度過長\u0026#39;, emailInvalid: \u0026#39;請輸入有效的電子郵件地址\u0026#39;, phoneInvalid: \u0026#39;請輸入有效的手機號碼\u0026#39;, passwordMismatch: \u0026#39;密碼不一致\u0026#39; }, // 時間相關 time: { just_now: \u0026#39;剛剛\u0026#39;, minutes_ago: \u0026#39;{count} 分鐘前\u0026#39;, hours_ago: \u0026#39;{count} 小時前\u0026#39;, days_ago: \u0026#39;{count} 天前\u0026#39;, weeks_ago: \u0026#39;{count} 週前\u0026#39;, months_ago: \u0026#39;{count} 個月前\u0026#39;, years_ago: \u0026#39;{count} 年前\u0026#39; } }, // 金融業務相關 banking: { account: { balance: \u0026#39;帳戶餘額\u0026#39;, available: \u0026#39;可用餘額\u0026#39;, accountNumber: \u0026#39;帳戶號碼\u0026#39;, accountType: \u0026#39;帳戶類型\u0026#39;, status: \u0026#39;狀態\u0026#39;, openDate: \u0026#39;開戶日期\u0026#39;, lastTransaction: \u0026#39;最近交易\u0026#39; }, transaction: { transfer: \u0026#39;轉帳\u0026#39;, deposit: \u0026#39;存款\u0026#39;, withdrawal: \u0026#39;提款\u0026#39;, payment: \u0026#39;付款\u0026#39;, refund: \u0026#39;退款\u0026#39;, fee: \u0026#39;手續費\u0026#39;, amount: \u0026#39;金額\u0026#39;, recipient: \u0026#39;收款人\u0026#39;, description: \u0026#39;摘要\u0026#39;, reference: \u0026#39;參考號碼\u0026#39;, date: \u0026#39;交易日期\u0026#39;, status: \u0026#39;交易狀態\u0026#39; }, status: { active: \u0026#39;啟用\u0026#39;, inactive: \u0026#39;停用\u0026#39;, pending: \u0026#39;處理中\u0026#39;, completed: \u0026#39;已完成\u0026#39;, failed: \u0026#39;失敗\u0026#39;, cancelled: \u0026#39;已取消\u0026#39;, expired: \u0026#39;已過期\u0026#39; } } }, \u0026#39;en-US\u0026#39;: { common: { actions: { save: \u0026#39;Save\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, confirm: \u0026#39;Confirm\u0026#39;, delete: \u0026#39;Delete\u0026#39;, edit: \u0026#39;Edit\u0026#39;, add: \u0026#39;Add\u0026#39;, search: \u0026#39;Search\u0026#39;, filter: \u0026#39;Filter\u0026#39;, sort: \u0026#39;Sort\u0026#39;, refresh: \u0026#39;Refresh\u0026#39;, loading: \u0026#39;Loading...\u0026#39;, noData: \u0026#39;No Data\u0026#39;, error: \u0026#39;Error Occurred\u0026#39; }, form: { required: \u0026#39;This field is required\u0026#39;, invalid: \u0026#39;Invalid format\u0026#39;, tooShort: \u0026#39;Too short\u0026#39;, tooLong: \u0026#39;Too long\u0026#39;, emailInvalid: \u0026#39;Please enter a valid email address\u0026#39;, phoneInvalid: \u0026#39;Please enter a valid phone number\u0026#39;, passwordMismatch: \u0026#39;Passwords do not match\u0026#39; }, time: { just_now: \u0026#39;Just now\u0026#39;, minutes_ago: \u0026#39;{count} minutes ago\u0026#39;, hours_ago: \u0026#39;{count} hours ago\u0026#39;, days_ago: \u0026#39;{count} days ago\u0026#39;, weeks_ago: \u0026#39;{count} weeks ago\u0026#39;, months_ago: \u0026#39;{count} months ago\u0026#39;, years_ago: \u0026#39;{count} years ago\u0026#39; } }, banking: { account: { balance: \u0026#39;Account Balance\u0026#39;, available: \u0026#39;Available Balance\u0026#39;, accountNumber: \u0026#39;Account Number\u0026#39;, accountType: \u0026#39;Account Type\u0026#39;, status: \u0026#39;Status\u0026#39;, openDate: \u0026#39;Open Date\u0026#39;, lastTransaction: \u0026#39;Last Transaction\u0026#39; }, transaction: { transfer: \u0026#39;Transfer\u0026#39;, deposit: \u0026#39;Deposit\u0026#39;, withdrawal: \u0026#39;Withdrawal\u0026#39;, payment: \u0026#39;Payment\u0026#39;, refund: \u0026#39;Refund\u0026#39;, fee: \u0026#39;Fee\u0026#39;, amount: \u0026#39;Amount\u0026#39;, recipient: \u0026#39;Recipient\u0026#39;, description: \u0026#39;Description\u0026#39;, reference: \u0026#39;Reference Number\u0026#39;, date: \u0026#39;Transaction Date\u0026#39;, status: \u0026#39;Transaction Status\u0026#39; }, status: { active: \u0026#39;Active\u0026#39;, inactive: \u0026#39;Inactive\u0026#39;, pending: \u0026#39;Pending\u0026#39;, completed: \u0026#39;Completed\u0026#39;, failed: \u0026#39;Failed\u0026#39;, cancelled: \u0026#39;Cancelled\u0026#39;, expired: \u0026#39;Expired\u0026#39; } } } }; // 進階翻譯函數 export class I18nManager { private currentLocale: string = \u0026#39;zh-TW\u0026#39;; private fallbackLocale: string = \u0026#39;en-US\u0026#39;; // 設定當前語言 setLocale(locale: string) { this.currentLocale = locale; document.documentElement.setAttribute(\u0026#39;lang\u0026#39;, locale); // 更新頁面方向 const direction = this.getTextDirection(locale); document.documentElement.setAttribute(\u0026#39;dir\u0026#39;, direction); // 觸發語言變更事件 window.dispatchEvent(new CustomEvent(\u0026#39;localeChanged\u0026#39;, { detail: { locale, direction } })); } // 取得文字方向 private getTextDirection(locale: string): \u0026#39;ltr\u0026#39; | \u0026#39;rtl\u0026#39; { const rtlLocales = [\u0026#39;ar\u0026#39;, \u0026#39;he\u0026#39;, \u0026#39;fa\u0026#39;, \u0026#39;ur\u0026#39;]; return rtlLocales.some(rtl =\u0026gt; locale.startsWith(rtl)) ? \u0026#39;rtl\u0026#39; : \u0026#39;ltr\u0026#39;; } // 翻譯函數 translate(key: string, options?: { interpolation?: Record\u0026lt;string, any\u0026gt;; count?: number; defaultValue?: string; }): string { const keys = key.split(\u0026#39;.\u0026#39;); let value = this.getNestedValue(translationStructure[this.currentLocale], keys); // 如果找不到翻譯，嘗試備用語言 if (!value) { value = this.getNestedValue(translationStructure[this.fallbackLocale], keys); } // 如果還是找不到，返回預設值或 key if (!value) { return options?.defaultValue || key; } // 處理插值 if (options?.interpolation) { Object.entries(options.interpolation).forEach(([placeholder, replacement]) =\u0026gt; { value = value.replace(new RegExp(`{${placeholder}}`, \u0026#39;g\u0026#39;), replacement); }); } // 處理複數形式 if (options?.count !== undefined) { value = this.handlePluralization(value, options.count); } return value; } // 取得巢狀物件值 private getNestedValue(obj: any, keys: string[]): string | null { return keys.reduce((current, key) =\u0026gt; current?.[key], obj) || null; } // 處理複數形式 private handlePluralization(value: string, count: number): string { // 簡化的複數處理，實際應用中可能需要更複雜的邏輯 if (this.currentLocale === \u0026#39;en-US\u0026#39;) { if (count === 1) { return value.replace(/\\{count\\}/, count.toString()); } else { // 處理英文複數規則 return value.replace(/\\{count\\}/, count.toString()); } } return value.replace(/\\{count\\}/, count.toString()); } // 格式化相對時間 formatRelativeTime(date: Date): string { const now = new Date(); const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000); if (diffInSeconds \u0026lt; 60) { return this.translate(\u0026#39;common.time.just_now\u0026#39;); } else if (diffInSeconds \u0026lt; 3600) { const minutes = Math.floor(diffInSeconds / 60); return this.translate(\u0026#39;common.time.minutes_ago\u0026#39;, { interpolation: { count: minutes.toString() } }); } else if (diffInSeconds \u0026lt; 86400) { const hours = Math.floor(diffInSeconds / 3600); return this.translate(\u0026#39;common.time.hours_ago\u0026#39;, { interpolation: { count: hours.toString() } }); } else if (diffInSeconds \u0026lt; 604800) { const days = Math.floor(diffInSeconds / 86400); return this.translate(\u0026#39;common.time.days_ago\u0026#39;, { interpolation: { count: days.toString() } }); } else if (diffInSeconds \u0026lt; 2419200) { const weeks = Math.floor(diffInSeconds / 604800); return this.translate(\u0026#39;common.time.weeks_ago\u0026#39;, { interpolation: { count: weeks.toString() } }); } else if (diffInSeconds \u0026lt; 29030400) { const months = Math.floor(diffInSeconds / 2419200); return this.translate(\u0026#39;common.time.months_ago\u0026#39;, { interpolation: { count: months.toString() } }); } else { const years = Math.floor(diffInSeconds / 29030400); return this.translate(\u0026#39;common.time.years_ago\u0026#39;, { interpolation: { count: years.toString() } }); } } } // 全域 i18n 實例 export const i18nManager = new I18nManager(); // Vue 組合函數 export function useI18n() { const t = (key: string, options?: any) =\u0026gt; i18nManager.translate(key, options); const setLocale = (locale: string) =\u0026gt; i18nManager.setLocale(locale); const formatRelativeTime = (date: Date) =\u0026gt; i18nManager.formatRelativeTime(date); return { t, setLocale, formatRelativeTime }; } 無障礙設計和多語系支援擴充完成，接下來我將繼續撰寫第三部分：UI 元件規範。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/uiux%E6%8C%87%E5%BC%95/","summary":"UI/UX 開發指引 目錄 文件概述 設計原則 1.1 銀行系統的安全性與一致性要求 1.2 清晰的資訊層次與導航設計 1.3 金融資料顯示與重點突顯規範 1.4 無障礙設計（WCAG 2.1 AA 級） 1.5 多語系支援 UI 元件規範 2.1 樣式系統 (Design System) 2.2 響應式設計規範 2.3 常用元件設計 UX 流程規範 3.1 表單驗證與錯誤回饋 3.2 使用者引導 (Onboarding) 3.3 搜尋、篩選與排序互動設計 3.4 資料載入與狀態設計 設計資產與交付 4.1 設計 Token 系統 4.2 元件庫架構 Vue 3 + Tailwind CSS 最佳實踐 5.1 元件命名與結構規範 5.2 Tailwind CSS 自定義配置 檢測與驗證 6.1 視覺回歸測試 6.2 無障礙檢測 6.3 使用性測試清單 性能優化指引 設計協作流程 維護與版本控制 附錄 文件概述 本指引適用於大型金融共用平台的前端 UI/UX 開發，涵蓋設計原則、UI 元件規範、UX 流程、設計資產交付等完整內容。\n專案技術堆疊 前端架構: 微前端 + SPA (Single-Page App\u0026mdash; 第一部分完成，接下來我將繼續撰寫第二部分：無障礙設計和多語系支援。\n1.4 無障礙設計（WCAG 2.1 AA 級） 色彩對比度要求 正常文字: 對比度至少 4.5:1 大文字 (18pt 以上): 對比度至少 3:1 互動元件: 對比度至少 3:1 /* Tailwind CSS 無障礙色彩配置 */ .text-primary { @apply text-gray-900; /* 對比度 21:1 */ } .text-secondary { @apply text-gray-700; /* 對比度 9.2:1 */ } .bg-interactive { @apply bg-blue-600 hover:bg-blue-700 focus:bg-blue-700; } .bg-interactive:focus { @apply ring-2 ring-blue-500 ring-offset-2; } 鍵盤操作支援 Tab 順序: 邏輯性的焦點移動順序 快捷鍵: 主要功能提供鍵盤快捷鍵 焦點指示: 清晰的焦點視覺回饋 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙表單範例 --\u0026gt; \u0026lt;form @submit.prevent=\u0026#34;handleSubmit\u0026#34; class=\u0026#34;space-y-6\u0026#34;\u0026gt; \u0026lt;div\u0026gt; \u0026lt;label for=\u0026#34;account-number\u0026#34; class=\u0026#34;block text-sm font-medium text-gray-700\u0026#34;\u0026gt; 帳戶號碼 \u0026lt;span class=\u0026#34;text-red-500\u0026#34; aria-label=\u0026#34;必填欄位\u0026#34;\u0026gt;*\u0026lt;/span\u0026gt; \u0026lt;/label\u0026gt; \u0026lt;input id=\u0026#34;account-number\u0026#34; v-model=\u0026#34;accountNumber\u0026#34; type=\u0026#34;text\u0026#34; required aria-describedby=\u0026#34;account-help account-error\u0026#34; class=\u0026#34;mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500\u0026#34; :aria-invalid=\u0026#34;hasError\u0026#34; /\u0026gt; \u0026lt;p id=\u0026#34;account-help\u0026#34; class=\u0026#34;mt-2 text-sm text-gray-500\u0026#34;\u0026gt; 請輸入 12 位數字帳戶號碼 \u0026lt;/p\u0026gt; \u0026lt;p id=\u0026#34;account-error\u0026#34; v-if=\u0026#34;errorMessage\u0026#34; class=\u0026#34;mt-2 text-sm text-red-600\u0026#34; role=\u0026#34;alert\u0026#34;\u0026gt; {{ errorMessage }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/form\u0026gt; \u0026lt;/template\u0026gt; 螢幕閱讀器支援 語義化 HTML: 使用適當的 HTML 語義標籤 ARIA 標籤: 補充無障礙資訊 替代文字: 圖片提供有意義的 alt 文字 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙數據表格 --\u0026gt; \u0026lt;table role=\u0026#34;table\u0026#34; aria-label=\u0026#34;帳戶交易記錄\u0026#34;\u0026gt; \u0026lt;caption class=\u0026#34;sr-only\u0026#34;\u0026gt; 最近 10 筆交易記錄，包含日期、摘要、金額和餘額 \u0026lt;/caption\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 交易日期 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 摘要 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-right text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 金額 \u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr v-for=\u0026#34;transaction in transactions\u0026#34; :key=\u0026#34;transaction.id\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ formatDate(transaction.date) }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ transaction.description }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-right\u0026#34;\u0026gt; \u0026lt;span :class=\u0026#34;transaction.amount \u0026gt;= 0 ? \u0026#39;text-green-600\u0026#39; : \u0026#39;text-red-600\u0026#39;\u0026#34;\u0026gt; {{ formatCurrency(transaction.amount) }} \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; \u0026lt;/template\u0026gt; 1.5 多語系支援 語言切換機制 // i18n 配置 import { createI18n } from \u0026#39;vue-i18n\u0026#39;; interface Messages { \u0026#39;zh-TW\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;en-US\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;ja-JP\u0026#39;: Record\u0026lt;string, any\u0026gt;; } const messages: Messages = { \u0026#39;zh-TW\u0026#39;: { common: { confirm: \u0026#39;確認\u0026#39;, cancel: \u0026#39;取消\u0026#39;, save: \u0026#39;儲存\u0026#39;, delete: \u0026#39;刪除\u0026#39;, loading: \u0026#39;載入中...\u0026#39; }, account: { balance: \u0026#39;帳戶餘額\u0026#39;, transfer: \u0026#39;轉帳\u0026#39;, history: \u0026#39;交易記錄\u0026#39; } }, \u0026#39;en-US\u0026#39;: { common: { confirm: \u0026#39;Confirm\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, save: \u0026#39;Save\u0026#39;, delete: \u0026#39;Delete\u0026#39;, loading: \u0026#39;Loading...\u0026#39; }, account: { balance: \u0026#39;Account Balance\u0026#39;, transfer: \u0026#39;Transfer\u0026#39;, history: \u0026#39;Transaction History\u0026#39; } } }; export const i18n = createI18n({ locale: \u0026#39;zh-TW\u0026#39;, fallbackLocale: \u0026#39;en-US\u0026#39;, messages }); 文字方向支援 (RTL/LTR) \u0026lt;template\u0026gt; \u0026lt;div :dir=\u0026#34;currentLocale.dir\u0026#34; class=\u0026#34;app-container\u0026#34;\u0026gt; \u0026lt;!-- 語言切換器 --\u0026gt; \u0026lt;div class=\u0026#34;language-selector\u0026#34;\u0026gt; \u0026lt;select v-model=\u0026#34;currentLanguage\u0026#34; @change=\u0026#34;changeLanguage\u0026#34; class=\u0026#34;block w-32 rounded-md border-gray-300\u0026#34; :aria-label=\u0026#34;$t(\u0026#39;common.selectLanguage\u0026#39;)\u0026#34; \u0026gt; \u0026lt;option value=\u0026#34;zh-TW\u0026#34;\u0026gt;繁體中文\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;en-US\u0026#34;\u0026gt;English\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;ar-SA\u0026#34;\u0026gt;العربية\u0026lt;/option\u0026gt; \u0026lt;/select\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed } from \u0026#39;vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; const { locale, t } = useI18n(); const localeConfig = { \u0026#39;zh-TW\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;繁體中文\u0026#39; }, \u0026#39;en-US\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;English\u0026#39; }, \u0026#39;ar-SA\u0026#39;: { dir: \u0026#39;rtl\u0026#39;, name: \u0026#39;العربية\u0026#39; } }; const currentLocale = computed(() =\u0026gt; localeConfig[locale.value]); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* RTL 支援樣式 */ [dir=\u0026#34;rtl\u0026#34;] .text-left { text-align: right; } [dir=\u0026#34;rtl\u0026#34;] .text-right { text-align: left; } [dir=\u0026#34;rtl\u0026#34;] .ml-4 { margin-left: 0; margin-right: 1rem; } \u0026lt;/style\u0026gt; 數字與日期本地化 // 本地化格式化工具 export class LocaleFormatter { private locale: string; constructor(locale: string) { this.locale = locale; } // 金額格式化 formatCurrency(amount: number, currency: string = \u0026#39;TWD\u0026#39;): string { const currencyMap = { \u0026#39;zh-TW\u0026#39;: \u0026#39;TWD\u0026#39;, \u0026#39;en-US\u0026#39;: \u0026#39;USD\u0026#39;, \u0026#39;ja-JP\u0026#39;: \u0026#39;JPY\u0026#39;, \u0026#39;ko-KR\u0026#39;: \u0026#39;KRW\u0026#39; }; return new Intl.NumberFormat(this.locale, { style: \u0026#39;currency\u0026#39;, currency: currencyMap[this.locale] || currency, minimumFractionDigits: currency === \u0026#39;JPY\u0026#39; ? 0 : 2 }).format(amount); } // 日期格式化 formatDate(date: Date, options?: Intl.DateTimeFormatOptions): string { const defaultOptions: Intl.DateTimeFormatOptions = { year: \u0026#39;numeric\u0026#39;, month: \u0026#39;short\u0026#39;, day: \u0026#39;numeric\u0026#39; }; return new Intl.DateTimeFormat(this.locale, options || defaultOptions).format(date); } // 時間格式化 formatTime(date: Date): string { return new Intl.DateTimeFormat(this.locale, { hour: \u0026#39;2-digit\u0026#39;, minute: \u0026#39;2-digit\u0026#39;, hour12: this.locale === \u0026#39;en-US\u0026#39; }).format(date); } // 百分比格式化 formatPercentage(value: number): string { return new Intl.NumberFormat(this.locale, { style: \u0026#39;percent\u0026#39;, minimumFractionDigits: 2, maximumFractionDigits: 2 }).format(value); } } 進階無障礙設計實作 \u0026lt;template\u0026gt; \u0026lt;!-- 高對比模式切換 --\u0026gt; \u0026lt;div class=\u0026#34;accessibility-controls fixed top-4 right-4 z-50\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleHighContrast\u0026#34; :aria-pressed=\u0026#34;isHighContrast\u0026#34; class=\u0026#34;p-2 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; :class=\u0026#34;isHighContrast ? \u0026#39;bg-yellow-400 text-black\u0026#39; : \u0026#39;bg-white text-gray-700 shadow-md\u0026#39;\u0026#34; aria-label=\u0026#34;切換高對比模式\u0026#34; \u0026gt; \u0026lt;EyeIcon class=\u0026#34;h-5 w-5\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;!-- 字體大小調整 --\u0026gt; \u0026lt;div class=\u0026#34;mt-2 flex flex-col space-y-1\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;increaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;增大字體\u0026#34; \u0026gt; A\u0026#43; \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;decreaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;縮小字體\u0026#34; \u0026gt; A- \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;resetFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;重設字體大小\u0026#34; \u0026gt; A \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 跳至主要內容連結 --\u0026gt; \u0026lt;a href=\u0026#34;#main-content\u0026#34; class=\u0026#34;sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 bg-blue-600 text-white px-4 py-2 rounded-md z-50\u0026#34; \u0026gt; 跳至主要內容 \u0026lt;/a\u0026gt; \u0026lt;!-- 焦點陷阱對話框範例 --\u0026gt; \u0026lt;div v-if=\u0026#34;showModal\u0026#34; class=\u0026#34;fixed inset-0 z-10 overflow-y-auto\u0026#34; role=\u0026#34;dialog\u0026#34; aria-modal=\u0026#34;true\u0026#34; :aria-labelledby=\u0026#34;modalTitleId\u0026#34; @keydown.esc=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;flex items-end justify-center min-h-screen pt-4 px-4 pb-20 text-center sm:block sm:p-0\u0026#34;\u0026gt; \u0026lt;!-- 背景遮罩 --\u0026gt; \u0026lt;div class=\u0026#34;fixed inset-0 transition-opacity\u0026#34; aria-hidden=\u0026#34;true\u0026#34; @click=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;absolute inset-0 bg-gray-500 opacity-75\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 對話框內容 --\u0026gt; \u0026lt;div ref=\u0026#34;modalContent\u0026#34; class=\u0026#34;inline-block align-bottom bg-white rounded-lg text-left overflow-hidden shadow-xl transform transition-all sm:my-8 sm:align-middle sm:max-w-lg sm:w-full\u0026#34; @keydown=\u0026#34;handleModalKeydown\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;bg-white px-4 pt-5 pb-4 sm:p-6 sm:pb-4\u0026#34;\u0026gt; \u0026lt;h3 :id=\u0026#34;modalTitleId\u0026#34; class=\u0026#34;text-lg leading-6 font-medium text-gray-900 mb-4\u0026#34;\u0026gt; 確認操作 \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm text-gray-500 mb-4\u0026#34;\u0026gt; 您確定要執行此操作嗎？此動作無法復原。 \u0026lt;/p\u0026gt; \u0026lt;!-- 焦點陷阱內的可互動元素 --\u0026gt; \u0026lt;div class=\u0026#34;flex justify-end space-x-3\u0026#34;\u0026gt; \u0026lt;button ref=\u0026#34;cancelButton\u0026#34; @click=\u0026#34;closeModal\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-gray-700 bg-white border border-gray-300 rounded-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; \u0026gt; 取消 \u0026lt;/button\u0026gt; \u0026lt;button ref=\u0026#34;confirmButton\u0026#34; @click=\u0026#34;handleConfirm\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-white bg-red-600 border border-transparent rounded-md hover:bg-red-700 focus:outline-none focus:ring-2 focus:ring-red-500\u0026#34; \u0026gt; 確認 \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { ref, nextTick, onMounted, onUnmounted } from \u0026#39;vue\u0026#39;; import { EyeIcon } from \u0026#39;@heroicons/vue/24/outline\u0026#39;; // 無障礙狀態管理 const isHighContrast = ref(false); const fontSize = ref(16); const showModal = ref(false); const modalTitleId = ref(`modal-title-${Math.random().toString(36).substr(2, 9)}`); // 高對比模式 const toggleHighContrast = () =\u0026gt; { isHighContrast.value = !isHighContrast.value; document.documentElement.classList.toggle(\u0026#39;high-contrast\u0026#39;, isHighContrast.value); // 儲存使用者偏好 localStorage.setItem(\u0026#39;high-contrast\u0026#39;, isHighContrast.value.toString()); // 通知螢幕閱讀器 announceToScreenReader( isHighContrast.value ? \u0026#39;已開啟高對比模式\u0026#39; : \u0026#39;已關閉高對比模式\u0026#39; ); }; // 字體大小調整 const increaseFontSize = () =\u0026gt; { if (fontSize.value \u0026lt; 24) { fontSize.value \u0026#43;= 2; updateFontSize(); } }; const decreaseFontSize = () =\u0026gt; { if (fontSize.value \u0026gt; 12) { fontSize.value -= 2; updateFontSize(); } }; const resetFontSize = () =\u0026gt; { fontSize.value = 16; updateFontSize(); }; const updateFontSize = () =\u0026gt; { document.documentElement.style.fontSize = `${fontSize.value}px`; localStorage.setItem(\u0026#39;font-size\u0026#39;, fontSize.value.toString()); announceToScreenReader(`字體大小已調整為 ${fontSize.value} 像素`); }; // 螢幕閱讀器公告 const announceToScreenReader = (message: string) =\u0026gt; { const announcement = document.createElement(\u0026#39;div\u0026#39;); announcement.setAttribute(\u0026#39;aria-live\u0026#39;, \u0026#39;polite\u0026#39;); announcement.setAttribute(\u0026#39;aria-atomic\u0026#39;, \u0026#39;true\u0026#39;); announcement.className = \u0026#39;sr-only\u0026#39;; announcement.textContent = message; document.body.appendChild(announcement); setTimeout(() =\u0026gt; { document.body.removeChild(announcement); }, 1000); }; // 焦點陷阱管理 const modalContent = ref\u0026lt;HTMLElement\u0026gt;(); const cancelButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const confirmButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const focusableElements: HTMLElement[] = []; let previousFocusedElement: HTMLElement | null = null; const openModal = async () =\u0026gt; { previousFocusedElement = document.activeElement as HTMLElement; showModal.value = true; await nextTick(); // 收集可聚焦元素 const selector = \u0026#39;button, [href], input, select, textarea, [tabindex]:not([tabindex=\u0026#34;-1\u0026#34;])\u0026#39;; focusableElements.splice(0); focusableElements.push( ...Array.from(modalContent.value?.querySelectorAll(selector) || []) ); // 聚焦第一個元素 if (focusableElements.length \u0026gt; 0) { focusableElements[0].focus(); } }; const closeModal = () =\u0026gt; { showModal.value = false; // 恢復之前的焦點 if (previousFocusedElement) { previousFocusedElement.focus(); } }; const handleModalKeydown = (event: KeyboardEvent) =\u0026gt; { if (event.key === \u0026#39;Tab\u0026#39;) { const currentIndex = focusableElements.indexOf(event.target as HTMLElement); if (event.shiftKey) { // Shift \u0026#43; Tab (向後) if (currentIndex \u0026lt;= 0) { event.preventDefault(); focusableElements[focusableElements.length - 1].focus(); } } else { // Tab (向前) if (currentIndex \u0026gt;= focusableElements.length - 1) { event.preventDefault(); focusableElements[0].focus(); } } } }; const handleConfirm = () =\u0026gt; { // 處理確認邏輯 announceToScreenReader(\u0026#39;操作已確認\u0026#39;); closeModal(); }; // 鍵盤快捷鍵 const handleGlobalKeydown = (event: KeyboardEvent) =\u0026gt; { // Alt \u0026#43; H: 開啟高對比模式 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;h\u0026#39;) { event.preventDefault(); toggleHighContrast(); } // Alt \u0026#43; \u0026#43;: 增大字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;\u0026#43;\u0026#39;) { event.preventDefault(); increaseFontSize(); } // Alt \u0026#43; -: 縮小字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;-\u0026#39;) { event.preventDefault(); decreaseFontSize(); } }; // 初始化無障礙設定 onMounted(() =\u0026gt; { // 載入儲存的偏好設定 const savedHighContrast = localStorage.getItem(\u0026#39;high-contrast\u0026#39;); if (savedHighContrast === \u0026#39;true\u0026#39;) { isHighContrast.value = true; document.documentElement.classList.add(\u0026#39;high-contrast\u0026#39;); } const savedFontSize = localStorage.getItem(\u0026#39;font-size\u0026#39;); if (savedFontSize) { fontSize.value = parseInt(savedFontSize); document.documentElement.style.fontSize = `${fontSize.value}px`; } // 監聽全域鍵盤事件 document.addEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); // 檢測用戶偏好的配色方案 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-color-scheme: dark)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;dark-mode\u0026#39;); } // 檢測用戶偏好的動畫設定 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-reduced-motion: reduce)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;reduce-motion\u0026#39;); } }); onUnmounted(() =\u0026gt; { document.removeEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); }); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* 高對比模式樣式 */ .high-contrast { filter: contrast(150%) saturate(200%); } .high-contrast button { border: 2px solid currentColor !important; } .high-contrast a { text-decoration: underline !important; } /* 減少動畫模式 */ .reduce-motion *, .reduce-motion *::before, .reduce-motion *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } /* 深色模式支援 */ .dark-mode { color-scheme: dark; } /* 螢幕閱讀器專用隱藏 */ .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .sr-only.focus:focus { position: static; width: auto; height: auto; padding: inherit; margin: inherit; overflow: visible; clip: auto; white-space: normal; } \u0026lt;/style\u0026gt; 多語系內容管理策略 // 多語系內容管理 interface TranslationKey { key: string; context?: string; pluralization?: boolean; interpolation?: string[]; } interface TranslationContent { [locale: string]: { [namespace: string]: { [key: string]: string | object; }; }; } // 翻譯內容結構化管理 export const translationStructure: TranslationContent = { \u0026#39;zh-TW\u0026#39;: { common: { // 通用操作 actions: { save: \u0026#39;儲存\u0026#39;, cancel: \u0026#39;取消\u0026#39;, confirm: \u0026#39;確認\u0026#39;, delete: \u0026#39;刪除\u0026#39;, edit: \u0026#39;編輯\u0026#39;, add: \u0026#39;新增\u0026#39;, search: \u0026#39;搜尋\u0026#39;, filter: \u0026#39;篩選\u0026#39;, sort: \u0026#39;排序\u0026#39;, refresh: \u0026#39;重新整理\u0026#39;, loading: \u0026#39;載入中...\u0026#39;, noData: \u0026#39;無資料\u0026#39;, error: \u0026#39;發生錯誤\u0026#39; }, // 表單相關 form: { required: \u0026#39;此欄位為必填\u0026#39;, invalid: \u0026#39;格式不正確\u0026#39;, tooShort: \u0026#39;長度不足\u0026#39;, tooLong: \u0026#39;長度過長\u0026#39;, emailInvalid: \u0026#39;請輸入有效的電子郵件地址\u0026#39;, phoneInvalid: \u0026#39;請輸入有效的手機號碼\u0026#39;, passwordMismatch: \u0026#39;密碼不一致\u0026#39; }, // 時間相關 time: { just_now: \u0026#39;剛剛\u0026#39;, minutes_ago: \u0026#39;{count} 分鐘前\u0026#39;, hours_ago: \u0026#39;{count} 小時前\u0026#39;, days_ago: \u0026#39;{count} 天前\u0026#39;, weeks_ago: \u0026#39;{count} 週前\u0026#39;, months_ago: \u0026#39;{count} 個月前\u0026#39;, years_ago: \u0026#39;{count} 年前\u0026#39; } }, // 金融業務相關 banking: { account: { balance: \u0026#39;帳戶餘額\u0026#39;, available: \u0026#39;可用餘額\u0026#39;, accountNumber: \u0026#39;帳戶號碼\u0026#39;, accountType: \u0026#39;帳戶類型\u0026#39;, status: \u0026#39;狀態\u0026#39;, openDate: \u0026#39;開戶日期\u0026#39;, lastTransaction: \u0026#39;最近交易\u0026#39; }, transaction: { transfer: \u0026#39;轉帳\u0026#39;, deposit: \u0026#39;存款\u0026#39;, withdrawal: \u0026#39;提款\u0026#39;, payment: \u0026#39;付款\u0026#39;, refund: \u0026#39;退款\u0026#39;, fee: \u0026#39;手續費\u0026#39;, amount: \u0026#39;金額\u0026#39;, recipient: \u0026#39;收款人\u0026#39;, description: \u0026#39;摘要\u0026#39;, reference: \u0026#39;參考號碼\u0026#39;, date: \u0026#39;交易日期\u0026#39;, status: \u0026#39;交易狀態\u0026#39; }, status: { active: \u0026#39;啟用\u0026#39;, inactive: \u0026#39;停用\u0026#39;, pending: \u0026#39;處理中\u0026#39;, completed: \u0026#39;已完成\u0026#39;, failed: \u0026#39;失敗\u0026#39;, cancelled: \u0026#39;已取消\u0026#39;, expired: \u0026#39;已過期\u0026#39; } } }, \u0026#39;en-US\u0026#39;: { common: { actions: { save: \u0026#39;Save\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, confirm: \u0026#39;Confirm\u0026#39;, delete: \u0026#39;Delete\u0026#39;, edit: \u0026#39;Edit\u0026#39;, add: \u0026#39;Add\u0026#39;, search: \u0026#39;Search\u0026#39;, filter: \u0026#39;Filter\u0026#39;, sort: \u0026#39;Sort\u0026#39;, refresh: \u0026#39;Refresh\u0026#39;, loading: \u0026#39;Loading...\u0026#39;, noData: \u0026#39;No Data\u0026#39;, error: \u0026#39;Error Occurred\u0026#39; }, form: { required: \u0026#39;This field is required\u0026#39;, invalid: \u0026#39;Invalid format\u0026#39;, tooShort: \u0026#39;Too short\u0026#39;, tooLong: \u0026#39;Too long\u0026#39;, emailInvalid: \u0026#39;Please enter a valid email address\u0026#39;, phoneInvalid: \u0026#39;Please enter a valid phone number\u0026#39;, passwordMismatch: \u0026#39;Passwords do not match\u0026#39; }, time: { just_now: \u0026#39;Just now\u0026#39;, minutes_ago: \u0026#39;{count} minutes ago\u0026#39;, hours_ago: \u0026#39;{count} hours ago\u0026#39;, days_ago: \u0026#39;{count} days ago\u0026#39;, weeks_ago: \u0026#39;{count} weeks ago\u0026#39;, months_ago: \u0026#39;{count} months ago\u0026#39;, years_ago: \u0026#39;{count} years ago\u0026#39; } }, banking: { account: { balance: \u0026#39;Account Balance\u0026#39;, available: \u0026#39;Available Balance\u0026#39;, accountNumber: \u0026#39;Account Number\u0026#39;, accountType: \u0026#39;Account Type\u0026#39;, status: \u0026#39;Status\u0026#39;, openDate: \u0026#39;Open Date\u0026#39;, lastTransaction: \u0026#39;Last Transaction\u0026#39; }, transaction: { transfer: \u0026#39;Transfer\u0026#39;, deposit: \u0026#39;Deposit\u0026#39;, withdrawal: \u0026#39;Withdrawal\u0026#39;, payment: \u0026#39;Payment\u0026#39;, refund: \u0026#39;Refund\u0026#39;, fee: \u0026#39;Fee\u0026#39;, amount: \u0026#39;Amount\u0026#39;, recipient: \u0026#39;Recipient\u0026#39;, description: \u0026#39;Description\u0026#39;, reference: \u0026#39;Reference Number\u0026#39;, date: \u0026#39;Transaction Date\u0026#39;, status: \u0026#39;Transaction Status\u0026#39; }, status: { active: \u0026#39;Active\u0026#39;, inactive: \u0026#39;Inactive\u0026#39;, pending: \u0026#39;Pending\u0026#39;, completed: \u0026#39;Completed\u0026#39;, failed: \u0026#39;Failed\u0026#39;, cancelled: \u0026#39;Cancelled\u0026#39;, expired: \u0026#39;Expired\u0026#39; } } } }; // 進階翻譯函數 export class I18nManager { private currentLocale: string = \u0026#39;zh-TW\u0026#39;; private fallbackLocale: string = \u0026#39;en-US\u0026#39;; // 設定當前語言 setLocale(locale: string) { this.currentLocale = locale; document.documentElement.setAttribute(\u0026#39;lang\u0026#39;, locale); // 更新頁面方向 const direction = this.getTextDirection(locale); document.documentElement.setAttribute(\u0026#39;dir\u0026#39;, direction); // 觸發語言變更事件 window.dispatchEvent(new CustomEvent(\u0026#39;localeChanged\u0026#39;, { detail: { locale, direction } })); } // 取得文字方向 private getTextDirection(locale: string): \u0026#39;ltr\u0026#39; | \u0026#39;rtl\u0026#39; { const rtlLocales = [\u0026#39;ar\u0026#39;, \u0026#39;he\u0026#39;, \u0026#39;fa\u0026#39;, \u0026#39;ur\u0026#39;]; return rtlLocales.some(rtl =\u0026gt; locale.startsWith(rtl)) ? \u0026#39;rtl\u0026#39; : \u0026#39;ltr\u0026#39;; } // 翻譯函數 translate(key: string, options?: { interpolation?: Record\u0026lt;string, any\u0026gt;; count?: number; defaultValue?: string; }): string { const keys = key.split(\u0026#39;.\u0026#39;); let value = this.getNestedValue(translationStructure[this.currentLocale], keys); // 如果找不到翻譯，嘗試備用語言 if (!value) { value = this.getNestedValue(translationStructure[this.fallbackLocale], keys); } // 如果還是找不到，返回預設值或 key if (!value) { return options?.defaultValue || key; } // 處理插值 if (options?.interpolation) { Object.entries(options.interpolation).forEach(([placeholder, replacement]) =\u0026gt; { value = value.replace(new RegExp(`{${placeholder}}`, \u0026#39;g\u0026#39;), replacement); }); } // 處理複數形式 if (options?.count !== undefined) { value = this.handlePluralization(value, options.count); } return value; } // 取得巢狀物件值 private getNestedValue(obj: any, keys: string[]): string | null { return keys.reduce((current, key) =\u0026gt; current?.[key], obj) || null; } // 處理複數形式 private handlePluralization(value: string, count: number): string { // 簡化的複數處理，實際應用中可能需要更複雜的邏輯 if (this.currentLocale === \u0026#39;en-US\u0026#39;) { if (count === 1) { return value.replace(/\\{count\\}/, count.toString()); } else { // 處理英文複數規則 return value.replace(/\\{count\\}/, count.toString()); } } return value.replace(/\\{count\\}/, count.toString()); } // 格式化相對時間 formatRelativeTime(date: Date): string { const now = new Date(); const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000); if (diffInSeconds \u0026lt; 60) { return this.translate(\u0026#39;common.time.just_now\u0026#39;); } else if (diffInSeconds \u0026lt; 3600) { const minutes = Math.floor(diffInSeconds / 60); return this.translate(\u0026#39;common.time.minutes_ago\u0026#39;, { interpolation: { count: minutes.toString() } }); } else if (diffInSeconds \u0026lt; 86400) { const hours = Math.floor(diffInSeconds / 3600); return this.translate(\u0026#39;common.time.hours_ago\u0026#39;, { interpolation: { count: hours.toString() } }); } else if (diffInSeconds \u0026lt; 604800) { const days = Math.floor(diffInSeconds / 86400); return this.translate(\u0026#39;common.time.days_ago\u0026#39;, { interpolation: { count: days.toString() } }); } else if (diffInSeconds \u0026lt; 2419200) { const weeks = Math.floor(diffInSeconds / 604800); return this.translate(\u0026#39;common.time.weeks_ago\u0026#39;, { interpolation: { count: weeks.toString() } }); } else if (diffInSeconds \u0026lt; 29030400) { const months = Math.floor(diffInSeconds / 2419200); return this.translate(\u0026#39;common.time.months_ago\u0026#39;, { interpolation: { count: months.toString() } }); } else { const years = Math.floor(diffInSeconds / 29030400); return this.translate(\u0026#39;common.time.years_ago\u0026#39;, { interpolation: { count: years.toString() } }); } } } // 全域 i18n 實例 export const i18nManager = new I18nManager(); // Vue 組合函數 export function useI18n() { const t = (key: string, options?: any) =\u0026gt; i18nManager.translate(key, options); const setLocale = (locale: string) =\u0026gt; i18nManager.setLocale(locale); const formatRelativeTime = (date: Date) =\u0026gt; i18nManager.formatRelativeTime(date); return { t, setLocale, formatRelativeTime }; } 無障礙設計和多語系支援擴充完成，接下來我將繼續撰寫第三部分：UI 元件規範。\n","title":"UIUX指引"},{"content":"Vim 使用教學手冊 目錄 前言 Vim 在專案中的角色 為什麼要學習 Vim 本手冊的學習方式與使用建議 第一篇：Vim 基礎入門 1. Vim 簡介 2. 安裝與環境設定 3. Vim 的操作模式 4. 文字編輯基礎 5. 檔案操作 第二篇：進階編輯技巧 6. 搜尋與取代 7. 巨集與自動化 8. 多檔案編輯與快速導覽 9. 文本處理進階 第三篇：專案開發實務 10. Vim 與程式開發 11. 插件管理 12. Git 與版本控制整合 13. 日常開發案例 第四篇：考試與認證準備 14. Vim 認證簡介 15. 模擬練習題 16. 學習路線圖 附錄 Vim 常用快捷鍵速查表 常見錯誤排解 推薦書籍與網站 練習建議 檢查清單（Checklist） 新進成員 Vim 技能檢查清單 團隊協作檢查清單 系統管理檢查清單 持續改進檢查清單 前言 Vim 在專案中的角色 在現代軟體開發專案中，Vim 扮演著重要的角色：\nLinux 伺服器管理必備工具：在產品環境中進行設定檔編輯、日誌查看、緊急修復 高效率文字編輯器：相較於圖形界面編輯器，Vim 在純文字環境下具有絕對優勢 跨平台一致性：無論在 Linux、macOS 或 Windows 環境，Vim 都能提供相同的操作體驗 與開發工具整合：許多現代 IDE 都提供 Vim 模式，學會 Vim 能提升整體開發效率 為什麼要學習 Vim mindmap root((為什麼學 Vim)) 效率提升 快速編輯 鍵盤操作 減少滑鼠依賴 專業需求 Linux 系統管理 遠端作業 伺服器維護 認證考試 LPIC RHCE CompTIA Linux\u0026#43; 技能發展 文字處理專精 自動化能力 工具整合 本手冊的學習方式與使用建議 循序漸進：建議按章節順序學習，每章都有實作練習 動手實作：理論與實務並重，務必完成每章的練習題 日常應用：將學會的技巧應用到實際專案開發中 認證導向：標註的認證重點可作為考試準備參考 第一篇：Vim 基礎入門 1. Vim 簡介 簡介 Vim（Vi IMproved）是基於經典的 Vi 編輯器所改良的文字編輯器，是 Unix/Linux 系統中最重要的編輯工具之一。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/vim%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Vim 使用教學手冊 目錄 前言 Vim 在專案中的角色 為什麼要學習 Vim 本手冊的學習方式與使用建議 第一篇：Vim 基礎入門 1. Vim 簡介 2. 安裝與環境設定 3. Vim 的操作模式 4. 文字編輯基礎 5. 檔案操作 第二篇：進階編輯技巧 6. 搜尋與取代 7. 巨集與自動化 8. 多檔案編輯與快速導覽 9. 文本處理進階 第三篇：專案開發實務 10. Vim 與程式開發 11. 插件管理 12. Git 與版本控制整合 13. 日常開發案例 第四篇：考試與認證準備 14. Vim 認證簡介 15. 模擬練習題 16. 學習路線圖 附錄 Vim 常用快捷鍵速查表 常見錯誤排解 推薦書籍與網站 練習建議 檢查清單（Checklist） 新進成員 Vim 技能檢查清單 團隊協作檢查清單 系統管理檢查清單 持續改進檢查清單 前言 Vim 在專案中的角色 在現代軟體開發專案中，Vim 扮演著重要的角色：\nLinux 伺服器管理必備工具：在產品環境中進行設定檔編輯、日誌查看、緊急修復 高效率文字編輯器：相較於圖形界面編輯器，Vim 在純文字環境下具有絕對優勢 跨平台一致性：無論在 Linux、macOS 或 Windows 環境，Vim 都能提供相同的操作體驗 與開發工具整合：許多現代 IDE 都提供 Vim 模式，學會 Vim 能提升整體開發效率 為什麼要學習 Vim mindmap root((為什麼學 Vim)) 效率提升 快速編輯 鍵盤操作 減少滑鼠依賴 專業需求 Linux 系統管理 遠端作業 伺服器維護 認證考試 LPIC RHCE CompTIA Linux\u0026#43; 技能發展 文字處理專精 自動化能力 工具整合 本手冊的學習方式與使用建議 循序漸進：建議按章節順序學習，每章都有實作練習 動手實作：理論與實務並重，務必完成每章的練習題 日常應用：將學會的技巧應用到實際專案開發中 認證導向：標註的認證重點可作為考試準備參考 第一篇：Vim 基礎入門 1. Vim 簡介 簡介 Vim（Vi IMproved）是基於經典的 Vi 編輯器所改良的文字編輯器，是 Unix/Linux 系統中最重要的編輯工具之一。\n","title":"Vim使用教學"},{"content":"Visual Studio Code 使用教學手冊 完整的 VS Code 開發環境設定與實戰指南\n涵蓋前端 (Vue 3 + TypeScript) 與後端 (Spring Boot) 開發，適用於團隊協作與企業級專案開發\n📋 目錄 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.2 推薦字型與主題 1.3 專案必要的 Extensions 清單 1.4 設定同步功能 1.5 設定檔 (Profiles) 管理 1.6 實務案例與注意事項 2. 專案開發環境配置 2.1 如何開啟專案 2.2 前端、後端工作區設定 2.3 編碼規範設定 2.3.1 前端編碼規範 (ESLint + Prettier) 2.3.2 後端編碼規範 (Checkstyle) 2.3.3 Maven 獨立安裝設定 2.4 容器化開發環境 (Dev Containers) 2.5 實務案例與注意事項 3. 日常開發操作 3.1 Git 與 GitHub/GitLab 整合 3.2 常用快捷鍵 3.3 偵錯與斷點設定 3.4 終端機與多工作區使用 3.5 程式碼片段 (Snippets) 使用 3.6 實務案例與注意事項 4. 專案特定開發流程指引 4.1 前端開發流程 4.2 後端開發流程 4.3 全端開發工作流程 4.4 程式碼品質檢查 4.5 Python 開發環境設定 4.5.1 Python 專案結構 4.5.2 Python 環境設定 4.5.3 Python 開發工具設定 4.5.4 Python 偵錯設定 4.5.5 Python 任務設定 4.5.6 Python 專案範例 4.5.7 Python 開發最佳實務 4.6 效能監控與分析 4.7 實務案例與注意事項 5. 協作開發功能 5.1 Live Share 即時協作 5.2 多人開發設定 5.3 程式碼審查工具 5.3.1 GitHub Pull Request 整合 5.3.2 GitLab Merge Request 整合 5.3.3 程式碼審查檢查清單 5.4 團隊協作最佳實務 6. 進階功能與擴充 6.1 自訂程式碼片段 6.2 擴充功能開發入門 6.2.1 建立基本擴充功能 6.2.2 擴充功能專案結構 6.2.3 擴充功能基本開發 6.2.4 發布擴充功能 6.3 工作流程自動化 6.3.1 Task 自動化 6.3.2 GitHub Actions 整合 6.3.3 GitLab CI/CD 整合 6.4 效能優化進階技巧 6.4.1 檔案監控與搜尋優化 6.4.2 編輯器效能設定 6.4.3 擴充功能效能管理 6.4.4 大型專案效能建議 6.5 遠端開發與 SSH 6.5.1 Remote Development 概述 6.5.2 Remote SSH 設定 6.5.3 Remote Tunnels（安全隧道） 6.5.4 GitHub Codespaces 6.5.5 遠端開發最佳實務 6.6 工作區管理進階技巧 7. AI 輔助開發與 GitHub Copilot 7.1 GitHub Copilot 基礎設定 7.1.1 安裝與啟用 7.1.2 行內建議 (Inline Suggestions) 7.1.3 聊天功能 (Chat) 7.1.4 Smart Actions（智慧動作） 7.1.5 審查與管理 AI 變更 7.2 Agent 模式與工作階段管理 7.2.1 Agent 類型 7.2.2 工作階段管理 7.2.3 子代理 (Subagents) 7.3 Plan Agent 規劃代理 7.4 自訂 AI 行為 7.4.1 自訂指令 (Custom Instructions) 7.4.2 Prompt Files（提示檔案） 7.4.3 自訂代理檔案 7.4.4 Agent Skills（正式版） 7.4.5 組織層級指令 7.4.6 Hooks（生命週期鉤子） 7.4.7 疑難排解 7.5 MCP 伺服器整合 7.6 Copilot Memory（預覽） 7.7 語言模型管理 7.7.1 選擇語言模型 7.7.2 Anthropic 模型整合（Claude） 7.7.3 語言模型編輯器 7.8 AI 開發常用快捷鍵 7.9 AI 開發最佳實務 7.9.1 有效使用 AI 的建議 7.9.2 Agent 使用場景指引 7.9.3 安全性考量 8. 最佳實務 8.1 常見問題 (FAQ) 與解決方式 8.2 建議的工作習慣 8.3 效能最佳化 8.4 安全性最佳實務 8.5 團隊協作規範 9. 檢查清單 9.1 新進成員快速上手檢查清單 9.2 日常開發檢查清單 9.3 部署前檢查清單 9.4 故障排除檢查清單 10. 附錄 10.1 參考資源 10.2 聯絡支援 10.3 版本歷程 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.1.1 下載與安裝 前往 Visual Studio Code 官方網站 點擊 \u0026ldquo;Download for Windows\u0026rdquo; 下載安裝檔 執行安裝檔，建議勾選以下選項： ✅ 新增至 PATH (在重新啟動後可用) ✅ 在檔案總管中的檔案上顯示「使用 Code 開啟」動作 ✅ 在檔案總管中的目錄上顯示「使用 Code 開啟」動作 ✅ 將 Code 註冊為支援的檔案類型的編輯器 1.1.2 首次啟動設定 啟動 VS Code 選擇適合的色彩主題 登入 Microsoft 帳戶（可選，用於同步設定） 1.2 推薦字型與主題 1.2.1 推薦字型 建議安裝並使用以下等寬字型：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/visual-studio-code%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Visual Studio Code 使用教學手冊 完整的 VS Code 開發環境設定與實戰指南\n涵蓋前端 (Vue 3 + TypeScript) 與後端 (Spring Boot) 開發，適用於團隊協作與企業級專案開發\n📋 目錄 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.2 推薦字型與主題 1.3 專案必要的 Extensions 清單 1.4 設定同步功能 1.5 設定檔 (Profiles) 管理 1.6 實務案例與注意事項 2. 專案開發環境配置 2.1 如何開啟專案 2.2 前端、後端工作區設定 2.3 編碼規範設定 2.3.1 前端編碼規範 (ESLint + Prettier) 2.3.2 後端編碼規範 (Checkstyle) 2.3.3 Maven 獨立安裝設定 2.4 容器化開發環境 (Dev Containers) 2.5 實務案例與注意事項 3. 日常開發操作 3.1 Git 與 GitHub/GitLab 整合 3.2 常用快捷鍵 3.3 偵錯與斷點設定 3.4 終端機與多工作區使用 3.5 程式碼片段 (Snippets) 使用 3.6 實務案例與注意事項 4. 專案特定開發流程指引 4.1 前端開發流程 4.2 後端開發流程 4.3 全端開發工作流程 4.4 程式碼品質檢查 4.5 Python 開發環境設定 4.5.1 Python 專案結構 4.5.2 Python 環境設定 4.5.3 Python 開發工具設定 4.5.4 Python 偵錯設定 4.5.5 Python 任務設定 4.5.6 Python 專案範例 4.5.7 Python 開發最佳實務 4.6 效能監控與分析 4.7 實務案例與注意事項 5. 協作開發功能 5.1 Live Share 即時協作 5.2 多人開發設定 5.3 程式碼審查工具 5.3.1 GitHub Pull Request 整合 5.3.2 GitLab Merge Request 整合 5.3.3 程式碼審查檢查清單 5.4 團隊協作最佳實務 6. 進階功能與擴充 6.1 自訂程式碼片段 6.2 擴充功能開發入門 6.2.1 建立基本擴充功能 6.2.2 擴充功能專案結構 6.2.3 擴充功能基本開發 6.2.4 發布擴充功能 6.3 工作流程自動化 6.3.1 Task 自動化 6.3.2 GitHub Actions 整合 6.3.3 GitLab CI/CD 整合 6.4 效能優化進階技巧 6.4.1 檔案監控與搜尋優化 6.4.2 編輯器效能設定 6.4.3 擴充功能效能管理 6.4.4 大型專案效能建議 6.5 遠端開發與 SSH 6.5.1 Remote Development 概述 6.5.2 Remote SSH 設定 6.5.3 Remote Tunnels（安全隧道） 6.5.4 GitHub Codespaces 6.5.5 遠端開發最佳實務 6.6 工作區管理進階技巧 7. AI 輔助開發與 GitHub Copilot 7.1 GitHub Copilot 基礎設定 7.1.1 安裝與啟用 7.1.2 行內建議 (Inline Suggestions) 7.1.3 聊天功能 (Chat) 7.1.4 Smart Actions（智慧動作） 7.1.5 審查與管理 AI 變更 7.2 Agent 模式與工作階段管理 7.2.1 Agent 類型 7.2.2 工作階段管理 7.2.3 子代理 (Subagents) 7.3 Plan Agent 規劃代理 7.4 自訂 AI 行為 7.4.1 自訂指令 (Custom Instructions) 7.4.2 Prompt Files（提示檔案） 7.4.3 自訂代理檔案 7.4.4 Agent Skills（正式版） 7.4.5 組織層級指令 7.4.6 Hooks（生命週期鉤子） 7.4.7 疑難排解 7.5 MCP 伺服器整合 7.6 Copilot Memory（預覽） 7.7 語言模型管理 7.7.1 選擇語言模型 7.7.2 Anthropic 模型整合（Claude） 7.7.3 語言模型編輯器 7.8 AI 開發常用快捷鍵 7.9 AI 開發最佳實務 7.9.1 有效使用 AI 的建議 7.9.2 Agent 使用場景指引 7.9.3 安全性考量 8. 最佳實務 8.1 常見問題 (FAQ) 與解決方式 8.2 建議的工作習慣 8.3 效能最佳化 8.4 安全性最佳實務 8.5 團隊協作規範 9. 檢查清單 9.1 新進成員快速上手檢查清單 9.2 日常開發檢查清單 9.3 部署前檢查清單 9.4 故障排除檢查清單 10. 附錄 10.1 參考資源 10.2 聯絡支援 10.3 版本歷程 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.1.1 下載與安裝 前往 Visual Studio Code 官方網站 點擊 \u0026ldquo;Download for Windows\u0026rdquo; 下載安裝檔 執行安裝檔，建議勾選以下選項： ✅ 新增至 PATH (在重新啟動後可用) ✅ 在檔案總管中的檔案上顯示「使用 Code 開啟」動作 ✅ 在檔案總管中的目錄上顯示「使用 Code 開啟」動作 ✅ 將 Code 註冊為支援的檔案類型的編輯器 1.1.2 首次啟動設定 啟動 VS Code 選擇適合的色彩主題 登入 Microsoft 帳戶（可選，用於同步設定） 1.2 推薦字型與主題 1.2.1 推薦字型 建議安裝並使用以下等寬字型：\n","title":"Visual Studio Code使用教學"},{"content":"Visual Studio Code 使用教學手冊 完整的 VS Code 開發環境設定與實戰指南\n涵蓋前端 (Vue 3 + TypeScript) 與後端 (Spring Boot) 開發，適用於團隊協作與企業級專案開發\n📋 目錄 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.2 推薦字型與主題 1.3 專案必要的 Extensions 清單 1.3.1 基礎開發工具 1.3.2 前端開發 1.3.3 後端開發 1.3.4 Python 開發 1.3.5 AI 輔助開發 1.3.6 一鍵安裝指令 1.4 設定同步功能 1.5 實務案例與注意事項 2. 專案開發環境配置 2.1 如何開啟專案 2.2 前端、後端工作區設定 2.3 編碼規範設定 2.3.1 前端編碼規範 (ESLint + Prettier) 2.3.2 後端編碼規範 (Checkstyle) 2.3.3 Maven 獨立安裝設定 2.4 容器化開發環境 (Dev Containers) 2.5 實務案例與注意事項 3. 日常開發操作 3.1 Git 與 GitHub/GitLab 整合 3.2 常用快捷鍵 3.3 偵錯與斷點設定 3.4 終端機與多工作區使用 3.5 程式碼片段 (Snippets) 使用 3.6 AI 輔助開發 — GitHub Copilot 3.6.1 程式碼自動完成與 Next Edit Suggestions 3.6.2 Copilot Chat 對話式助手 3.6.3 Inline Chat（行內聊天） 3.6.4 智慧動作 3.6.5 Agent 模式與 Agent Sessions 3.6.6 Autopilot 與 Agent 權限控制 3.6.7 Plan Agent（計畫代理） 3.6.8 自訂指示檔 3.6.9 MCP 伺服器整合 3.6.10 Custom Agents（自訂代理） 3.6.11 Agent Skills（代理技能） 3.6.12 Prompt Files（提示檔案） 3.6.13 Hooks（生命週期鉤子） 3.6.14 語言模型選擇 3.7 實務案例與注意事項 4. 專案特定開發流程指引 4.1 前端開發流程 4.2 後端開發流程 4.3 全端開發工作流程 4.4 程式碼品質檢查 4.5 效能監控與分析 4.6 實務案例與注意事項 4.7 Python 開發環境設定 4.7.1 Python 專案結構 4.7.2 Python 環境設定 4.7.3 Python 開發工具設定 4.7.4 Python 偵錯設定 4.7.5 Python 任務設定 4.7.6 Python 專案範例 4.7.7 Python 開發最佳實務 5. 協作開發功能 5.1 Live Share 即時協作 5.2 多人開發設定 5.3 程式碼審查工具 5.3.1 GitHub Pull Request 整合 5.3.2 GitLab Merge Request 整合 5.3.3 程式碼審查檢查清單 5.4 團隊協作最佳實務 6. 進階功能與擴充 6.1 自訂程式碼片段 6.2 擴充功能開發入門 6.3 工作流程自動化 6.3.1 Task 自動化 6.3.2 GitHub Actions 整合 6.3.3 GitLab CI/CD 整合 6.4 效能優化進階技巧 6.5 遠端開發與 SSH 6.6 工作區管理進階技巧 6.7 設定檔 (Profiles) 管理 6.8 Chat Customizations 編輯器 7. 最佳實務 7.1 常見問題 (FAQ) 與解決方式 7.2 建議的工作習慣 7.3 效能最佳化 7.4 安全性最佳實務 7.5 團隊協作規範 8. 檢查清單 8.1 新進成員快速上手檢查清單 8.2 日常開發檢查清單 8.3 部署前檢查清單 8.4 故障排除檢查清單 9. 附錄 9.1 參考資源 9.2 版本歷程 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.1.1 下載與安裝 前往 Visual Studio Code 官方網站 點擊 \u0026ldquo;Download for Windows\u0026rdquo; 下載安裝檔 執行安裝檔，建議勾選以下選項： ✅ 新增至 PATH (在重新啟動後可用) ✅ 在檔案總管中的檔案上顯示「使用 Code 開啟」動作 ✅ 在檔案總管中的目錄上顯示「使用 Code 開啟」動作 ✅ 將 Code 註冊為支援的檔案類型的編輯器 1.1.2 首次啟動設定 啟動 VS Code 選擇適合的色彩主題 登入 Microsoft 帳戶（可選，用於同步設定） 1.2 推薦字型與主題 1.2.1 推薦字型 建議安裝並使用以下等寬字型：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/visual-studio-code%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Visual Studio Code 使用教學手冊 完整的 VS Code 開發環境設定與實戰指南\n涵蓋前端 (Vue 3 + TypeScript) 與後端 (Spring Boot) 開發，適用於團隊協作與企業級專案開發\n📋 目錄 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.2 推薦字型與主題 1.3 專案必要的 Extensions 清單 1.3.1 基礎開發工具 1.3.2 前端開發 1.3.3 後端開發 1.3.4 Python 開發 1.3.5 AI 輔助開發 1.3.6 一鍵安裝指令 1.4 設定同步功能 1.5 實務案例與注意事項 2. 專案開發環境配置 2.1 如何開啟專案 2.2 前端、後端工作區設定 2.3 編碼規範設定 2.3.1 前端編碼規範 (ESLint + Prettier) 2.3.2 後端編碼規範 (Checkstyle) 2.3.3 Maven 獨立安裝設定 2.4 容器化開發環境 (Dev Containers) 2.5 實務案例與注意事項 3. 日常開發操作 3.1 Git 與 GitHub/GitLab 整合 3.2 常用快捷鍵 3.3 偵錯與斷點設定 3.4 終端機與多工作區使用 3.5 程式碼片段 (Snippets) 使用 3.6 AI 輔助開發 — GitHub Copilot 3.6.1 程式碼自動完成與 Next Edit Suggestions 3.6.2 Copilot Chat 對話式助手 3.6.3 Inline Chat（行內聊天） 3.6.4 智慧動作 3.6.5 Agent 模式與 Agent Sessions 3.6.6 Autopilot 與 Agent 權限控制 3.6.7 Plan Agent（計畫代理） 3.6.8 自訂指示檔 3.6.9 MCP 伺服器整合 3.6.10 Custom Agents（自訂代理） 3.6.11 Agent Skills（代理技能） 3.6.12 Prompt Files（提示檔案） 3.6.13 Hooks（生命週期鉤子） 3.6.14 語言模型選擇 3.7 實務案例與注意事項 4. 專案特定開發流程指引 4.1 前端開發流程 4.2 後端開發流程 4.3 全端開發工作流程 4.4 程式碼品質檢查 4.5 效能監控與分析 4.6 實務案例與注意事項 4.7 Python 開發環境設定 4.7.1 Python 專案結構 4.7.2 Python 環境設定 4.7.3 Python 開發工具設定 4.7.4 Python 偵錯設定 4.7.5 Python 任務設定 4.7.6 Python 專案範例 4.7.7 Python 開發最佳實務 5. 協作開發功能 5.1 Live Share 即時協作 5.2 多人開發設定 5.3 程式碼審查工具 5.3.1 GitHub Pull Request 整合 5.3.2 GitLab Merge Request 整合 5.3.3 程式碼審查檢查清單 5.4 團隊協作最佳實務 6. 進階功能與擴充 6.1 自訂程式碼片段 6.2 擴充功能開發入門 6.3 工作流程自動化 6.3.1 Task 自動化 6.3.2 GitHub Actions 整合 6.3.3 GitLab CI/CD 整合 6.4 效能優化進階技巧 6.5 遠端開發與 SSH 6.6 工作區管理進階技巧 6.7 設定檔 (Profiles) 管理 6.8 Chat Customizations 編輯器 7. 最佳實務 7.1 常見問題 (FAQ) 與解決方式 7.2 建議的工作習慣 7.3 效能最佳化 7.4 安全性最佳實務 7.5 團隊協作規範 8. 檢查清單 8.1 新進成員快速上手檢查清單 8.2 日常開發檢查清單 8.3 部署前檢查清單 8.4 故障排除檢查清單 9. 附錄 9.1 參考資源 9.2 版本歷程 1. VS Code 安裝與環境設定 1.1 安裝步驟 1.1.1 下載與安裝 前往 Visual Studio Code 官方網站 點擊 \u0026ldquo;Download for Windows\u0026rdquo; 下載安裝檔 執行安裝檔，建議勾選以下選項： ✅ 新增至 PATH (在重新啟動後可用) ✅ 在檔案總管中的檔案上顯示「使用 Code 開啟」動作 ✅ 在檔案總管中的目錄上顯示「使用 Code 開啟」動作 ✅ 將 Code 註冊為支援的檔案類型的編輯器 1.1.2 首次啟動設定 啟動 VS Code 選擇適合的色彩主題 登入 Microsoft 帳戶（可選，用於同步設定） 1.2 推薦字型與主題 1.2.1 推薦字型 建議安裝並使用以下等寬字型：\n","title":"Visual Studio Code使用教學"},{"content":"Vue 3.x 前端 Framework 教學手冊 📘 適用對象：完全沒有學過 Vue 3 的新進開發同仁\n🎯 學習目標：循序漸進掌握 Vue 3.x 開發技能，並具備專案實戰能力\n🏆 認證準備：涵蓋 Vue 3 官方認證考試重點\n📖 目錄 第一章：Vue 3 基礎入門\n1.1 什麼是 Vue.js？ 1.2 開發環境建置 1.3 第一個 Vue 3 應用 1.4 專案應用指引 1.5 認證考點提示 第二章：Composition API 深入\n2.1 setup() 函數詳解 2.2 組合式函數 (Composables) 2.3 進階組合式函數範例 2.4 專案應用指引 2.5 認證考點提示 第三章：響應式系統\n3.1 ref() 與 reactive() 詳解 3.2 深度響應式與淺層響應式 3.3 computed() 計算屬性 3.4 watch() 與 watchEffect() 3.5 響應式工具函數 3.6 專案應用指引 3.7 認證考點提示 第四章：模板語法與指令\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/framework/vue3-%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"Vue 3.x 前端 Framework 教學手冊 📘 適用對象：完全沒有學過 Vue 3 的新進開發同仁\n🎯 學習目標：循序漸進掌握 Vue 3.x 開發技能，並具備專案實戰能力\n🏆 認證準備：涵蓋 Vue 3 官方認證考試重點\n📖 目錄 第一章：Vue 3 基礎入門\n1.1 什麼是 Vue.js？ 1.2 開發環境建置 1.3 第一個 Vue 3 應用 1.4 專案應用指引 1.5 認證考點提示 第二章：Composition API 深入\n2.1 setup() 函數詳解 2.2 組合式函數 (Composables) 2.3 進階組合式函數範例 2.4 專案應用指引 2.5 認證考點提示 第三章：響應式系統\n3.1 ref() 與 reactive() 詳解 3.2 深度響應式與淺層響應式 3.3 computed() 計算屬性 3.4 watch() 與 watchEffect() 3.5 響應式工具函數 3.6 專案應用指引 3.7 認證考點提示 第四章：模板語法與指令\n","title":"Vue3 前端framework教學"},{"content":"SSDLC Prompt 範本使用指南 概述 本文檔提供完整的 SSDLC (Secure Software Development Life Cycle) Prompt 範本使用指南，協助團隊透過 AI 輔助完成各階段的開發任務。\n範本結構說明 目錄組織 .github/prompts/ ├── SSDLC_專案範本指南.md # 主要指南文檔 ├── 需求分析/ │ ├── 業務需求收集範本.md │ ├── 功能需求分析範本.md │ ├── 安全需求識別範本.md │ └── 使用者故事撰寫範本.md ├── 設計開發/ │ ├── 系統架構設計範本.md │ ├── API設計範本.md │ └── [其他設計範本] ├── 測試驗收/ │ ├── 測試策略制定範本.md │ ├── 自動化測試範本.md │ └── [其他測試範本] └── 部署運維/ ├── CI_CD流程範本.md └── [其他運維範本] 快速開始指南 步驟 1: 選擇適當的範本 根據當前專案階段選擇對應的範本：\n需求分析階段: 從業務需求收集開始 設計開發階段: 從系統架構設計開始 測試驗收階段: 從測試策略制定開始 部署運維階段: 從 CI/CD 流程設計開始 步驟 2: 填寫專案資訊 每個範本都包含專案背景資訊區塊，需要填入：\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97/","summary":"SSDLC Prompt 範本使用指南 概述 本文檔提供完整的 SSDLC (Secure Software Development Life Cycle) Prompt 範本使用指南，協助團隊透過 AI 輔助完成各階段的開發任務。\n範本結構說明 目錄組織 .github/prompts/ ├── SSDLC_專案範本指南.md # 主要指南文檔 ├── 需求分析/ │ ├── 業務需求收集範本.md │ ├── 功能需求分析範本.md │ ├── 安全需求識別範本.md │ └── 使用者故事撰寫範本.md ├── 設計開發/ │ ├── 系統架構設計範本.md │ ├── API設計範本.md │ └── [其他設計範本] ├── 測試驗收/ │ ├── 測試策略制定範本.md │ ├── 自動化測試範本.md │ └── [其他測試範本] └── 部署運維/ ├── CI_CD流程範本.md └── [其他運維範本] 快速開始指南 步驟 1: 選擇適當的範本 根據當前專案階段選擇對應的範本：\n需求分析階段: 從業務需求收集開始 設計開發階段: 從系統架構設計開始 測試驗收階段: 從測試策略制定開始 部署運維階段: 從 CI/CD 流程設計開始 步驟 2: 填寫專案資訊 每個範本都包含專案背景資訊區塊，需要填入：\n","title":"使用指南"},{"content":"使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事，包含完整的驗收標準和估算資訊。\n角色設定 你是一位敏捷開發專家和產品負責人，具備豐富的使用者故事撰寫經驗，熟悉敏捷開發方法論和最佳實務。\n任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。\n專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度，如：2週} 故事撰寫要求 請按照以下標準撰寫使用者故事：\n1. 故事結構 使用標準的「作為\u0026hellip;我希望\u0026hellip;以便\u0026hellip;」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例：線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E6%92%B0%E5%AF%AB%E7%AF%84%E6%9C%AC/","summary":"使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事，包含完整的驗收標準和估算資訊。\n角色設定 你是一位敏捷開發專家和產品負責人，具備豐富的使用者故事撰寫經驗，熟悉敏捷開發方法論和最佳實務。\n任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。\n專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度，如：2週} 故事撰寫要求 請按照以下標準撰寫使用者故事：\n1. 故事結構 使用標準的「作為\u0026hellip;我希望\u0026hellip;以便\u0026hellip;」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例：線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作\n","title":"使用者故事撰寫範本"},{"content":"前端開發指引 文件資訊 版本: 1.0.0 建立日期: 2025-08-11 適用專案: 大型金融級 Web 專案 技術棧: Vue 3.x + TypeScript + Tailwind CSS 目錄 專案目錄與檔案結構規範 命名規範 程式撰寫風格與 Lint 設定 元件開發規範 樣式與 Tailwind CSS 規範 API 串接與資料存取規範 狀態管理規範 多語系處理規範 測試規範 安全性考量 效能優化規範 無障礙設計規範 版本控制與分支策略 專案建置與部署流程 程式碼審查規範 常見錯誤處理與 Debug 流程 開發工具與環境設定 團隊協作與溝通規範 1. 專案目錄與檔案結構規範 1.1 標準專案結構 frontend-project/ ├── public/ # 靜態資源 │ ├── favicon.ico │ ├── index.html │ └── manifest.json ├── src/ # 原始碼 │ ├── api/ # API 相關 │ │ ├── modules/ # 依功能模組分類 │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ ├── interceptors/ # 攔截器 │ │ └── types/ # API 型別定義 │ ├── assets/ # 靜態資源 │ │ ├── images/ │ │ ├── icons/ │ │ └── fonts/ │ ├── components/ # 共用元件 │ │ ├── base/ # 基礎元件 │ │ │ ├── BaseButton.vue │ │ │ ├── BaseInput.vue │ │ │ └── BaseModal.vue │ │ ├── business/ # 業務元件 │ │ └── layout/ # 版面元件 │ │ ├── Header.vue │ │ ├── Sidebar.vue │ │ └── Footer.vue │ ├── composables/ # Vue 3 Composition API │ │ ├── useAuth.ts │ │ ├── useApi.ts │ │ └── useLocalStorage.ts │ ├── constants/ # 常數定義 │ │ ├── api.ts │ │ ├── routes.ts │ │ └── config.ts │ ├── directives/ # 自定義指令 │ ├── i18n/ # 多語系 │ │ ├── locales/ │ │ │ ├── zh-TW.json │ │ │ ├── en-US.json │ │ │ └── ja-JP.json │ │ └── index.ts │ ├── layouts/ # 版面配置 │ │ ├── DefaultLayout.vue │ │ ├── AuthLayout.vue │ │ └── EmptyLayout.vue │ ├── middleware/ # 中間件 │ │ ├── auth.ts │ │ └── permission.ts │ ├── pages/ # 頁面元件 │ │ ├── auth/ │ │ │ ├── Login.vue │ │ │ └── Register.vue │ │ ├── dashboard/ │ │ └── user/ │ ├── plugins/ # 插件 │ │ ├── axios.ts │ │ ├── i18n.ts │ │ └── router.ts │ ├── router/ # 路由設定 │ │ ├── modules/ # 路由模組 │ │ │ ├── auth.ts │ │ │ └── dashboard.ts │ │ └── index.ts │ ├── stores/ # Pinia 狀態管理 │ │ ├── modules/ │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ └── index.ts │ ├── styles/ # 樣式檔案 │ │ ├── globals.css │ │ ├── variables.css │ │ └── components/ │ ├── types/ # TypeScript 型別定義 │ │ ├── api.ts │ │ ├── auth.ts │ │ └── global.ts │ ├── utils/ # 工具函式 │ │ ├── format.ts │ │ ├── validation.ts │ │ └── storage.ts │ ├── App.vue # 根元件 │ └── main.ts # 應用程式進入點 ├── tests/ # 測試檔案 │ ├── unit/ # 單元測試 │ ├── e2e/ # E2E 測試 │ └── __mocks__/ # Mock 檔案 ├── .env # 環境變數 ├── .env.development ├── .env.production ├── .eslintrc.js # ESLint 設定 ├── .prettierrc # Prettier 設定 ├── tailwind.config.js # Tailwind CSS 設定 ├── vite.config.ts # Vite 設定 ├── tsconfig.json # TypeScript 設定 └── package.json # 套件管理 1.2 檔案命名原則 檔案類型對應命名方式 Vue 元件: PascalCase (如 UserProfile.vue) TypeScript 檔案: camelCase (如 userService.ts) CSS/SCSS 檔案: kebab-case (如 user-profile.scss) 測試檔案: 與被測檔案同名 + .test 或 .spec (如 UserProfile.test.ts) 型別定義檔案: camelCase + .d.ts (如 userTypes.d.ts) 特殊檔案命名 頁面元件: PascalCase，通常以頁面功能命名 (如 UserManagement.vue) Layout 元件: PascalCase + Layout 後綴 (如 DashboardLayout.vue) Store 檔案: camelCase，以業務領域命名 (如 userStore.ts) API 檔案: camelCase，以 API 服務命名 (如 userApi.ts) 2. 命名規範 2.1 檔案與資料夾命名 資料夾命名 使用 kebab-case (小寫字母 + 連字號) 名稱應簡潔且具描述性 ✅ 正確範例 user-management/ auth-service/ api-client/ ❌ 錯誤範例 UserManagement/ authService/ API_Client/ 檔案命名 Vue 元件檔案: PascalCase JavaScript/TypeScript 檔案: camelCase 樣式檔案: kebab-case 設定檔案: kebab-case 或 camelCase (依慣例) // ✅ 正確範例 UserProfile.vue userService.ts user-profile.scss vite.config.ts // ❌ 錯誤範例 userprofile.vue UserService.ts user_profile.scss vite_config.ts 2.2 變數與函式命名 JavaScript/TypeScript 變數 使用 camelCase 常數使用 UPPER_SNAKE_CASE 私有變數以 _ 開頭 布林值變數使用 is、has、can、should 等前綴 // ✅ 正確範例 const userName = \u0026#39;John Doe\u0026#39;; const API_BASE_URL = \u0026#39;https://api.example.com\u0026#39;; const _privateVariable = \u0026#39;private\u0026#39;; const isLoggedIn = true; const hasPermission = false; const canEdit = true; const shouldUpdate = false; // ❌ 錯誤範例 const user_name = \u0026#39;John Doe\u0026#39;; const apiBaseUrl = \u0026#39;https://api.example.com\u0026#39;; // 常數應使用大寫 const privateVariable = \u0026#39;private\u0026#39;; // 私有變數缺少前綴 const loggedIn = true; // 布林值缺少前綴 函式命名 使用 camelCase 動詞開頭，描述函式的動作 事件處理器使用 handle 前綴 取得資料使用 get、fetch 前綴 設定資料使用 set、update 前綴 // ✅ 正確範例 function getUserData() { } function handleButtonClick() { } function validateEmail() { } function formatCurrency() { } function updateUserProfile() { } function fetchUserList() { } // ❌ 錯誤範例 function userData() { } // 缺少動詞 function buttonClick() { } // 事件處理器缺少 handle 前綴 function email() { } // 不明確的命名 function currency() { } // 不明確的命名 2.3 Vue 元件命名 元件名稱 使用 PascalCase 多個單字組合，避免單一單字 基礎元件使用 Base 前綴 業務元件使用具體的業務領域命名 \u0026lt;!-- ✅ 正確範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: UserProfile.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: BaseButton.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: PaymentForm.vue \u0026lt;/script\u0026gt; \u0026lt;!-- ❌ 錯誤範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: user.vue - 命名太簡短 \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: button.vue - 應使用 BaseButton \u0026lt;/script\u0026gt; Props 命名 定義時使用 camelCase HTML 模板中使用 kebab-case \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 interface Props { userName: string; isVisible: boolean; maxLength?: number; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { maxLength: 100 }); \u0026lt;/script\u0026gt; \u0026lt;template\u0026gt; \u0026lt;!-- HTML 模板中使用 kebab-case --\u0026gt; \u0026lt;UserProfile :user-name=\u0026#34;currentUser\u0026#34; :is-visible=\u0026#34;showProfile\u0026#34; :max-length=\u0026#34;200\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; Event 命名 使用 kebab-case 動詞開頭，描述事件的動作 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 const emit = defineEmits\u0026lt;{ \u0026#39;update:modelValue\u0026#39;: [value: string]; \u0026#39;user-created\u0026#39;: [user: User]; \u0026#39;form-submitted\u0026#39;: [data: FormData]; \u0026#39;item-selected\u0026#39;: [item: Item]; }\u0026gt;(); // 觸發事件 emit(\u0026#39;user-created\u0026#39;, newUser); emit(\u0026#39;form-submitted\u0026#39;, formData); \u0026lt;/script\u0026gt; 3. 程式撰寫風格與 Lint 設定 3.1 ESLint 設定 eslint.config.js 範例 import { defineConfig } from \u0026#39;eslint-define-config\u0026#39;; import vue from \u0026#39;eslint-plugin-vue\u0026#39;; import typescript from \u0026#39;@typescript-eslint/eslint-plugin\u0026#39;; import typescriptParser from \u0026#39;@typescript-eslint/parser\u0026#39;; import prettier from \u0026#39;eslint-plugin-prettier\u0026#39;; export default defineConfig([ { files: [\u0026#39;**/*.{js,ts,vue}\u0026#39;], languageOptions: { parser: typescriptParser, parserOptions: { ecmaVersion: 2022, sourceType: \u0026#39;module\u0026#39;, extraFileExtensions: [\u0026#39;.vue\u0026#39;] } }, plugins: { vue, \u0026#39;@typescript-eslint\u0026#39;: typescript, prettier }, rules: { // Vue 規則 \u0026#39;vue/multi-word-component-names\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/component-name-in-template-casing\u0026#39;: [\u0026#39;error\u0026#39;, \u0026#39;PascalCase\u0026#39;], \u0026#39;vue/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/no-multiple-template-root\u0026#39;: \u0026#39;off\u0026#39;, // Vue 3 支援多個根元素 \u0026#39;vue/script-setup-uses-vars\u0026#39;: \u0026#39;error\u0026#39;, // TypeScript 規則 \u0026#39;@typescript-eslint/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;@typescript-eslint/no-explicit-any\u0026#39;: \u0026#39;warn\u0026#39;, \u0026#39;@typescript-eslint/explicit-function-return-type\u0026#39;: \u0026#39;off\u0026#39;, \u0026#39;@typescript-eslint/no-non-null-assertion\u0026#39;: \u0026#39;warn\u0026#39;, // 通用規則 \u0026#39;no-console\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;no-debugger\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;prefer-const\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;no-var\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;object-shorthand\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;prefer-template\u0026#39;: \u0026#39;error\u0026#39;, // Prettier 規則 \u0026#39;prettier/prettier\u0026#39;: \u0026#39;error\u0026#39; } } ]); 3.2 Prettier 設定 .prettierrc 範例 { \u0026#34;semi\u0026#34;: true, \u0026#34;trailingComma\u0026#34;: \u0026#34;es5\u0026#34;, \u0026#34;singleQuote\u0026#34;: true, \u0026#34;printWidth\u0026#34;: 80, \u0026#34;tabWidth\u0026#34;: 2, \u0026#34;useTabs\u0026#34;: false, \u0026#34;bracketSpacing\u0026#34;: true, \u0026#34;bracketSameLine\u0026#34;: false, \u0026#34;arrowParens\u0026#34;: \u0026#34;avoid\u0026#34;, \u0026#34;endOfLine\u0026#34;: \u0026#34;lf\u0026#34;, \u0026#34;vueIndentScriptAndStyle\u0026#34;: true, \u0026#34;htmlWhitespaceSensitivity\u0026#34;: \u0026#34;css\u0026#34; } 3.3 TypeScript 撰寫規範 型別定義規範 // ✅ 正確範例 - 使用 interface 定義物件型別 interface User { id: number; name: string; email: string; isActive: boolean; createdAt: Date; updatedAt?: Date; // 選擇性屬性 } // ✅ 正確範例 - 使用 type 定義聯合型別 type Status = \u0026#39;pending\u0026#39; | \u0026#39;approved\u0026#39; | \u0026#39;rejected\u0026#39;; type Theme = \u0026#39;light\u0026#39; | \u0026#39;dark\u0026#39; | \u0026#39;auto\u0026#39;; // ✅ 正確範例 - 泛型使用 interface ApiResponse\u0026lt;T\u0026gt; { data: T; message: string; success: boolean; code: number; } // ✅ 正確範例 - 函式型別定義 type EventHandler\u0026lt;T = Event\u0026gt; = (event: T) =\u0026gt; void; type AsyncFunction\u0026lt;T\u0026gt; = () =\u0026gt; Promise\u0026lt;T\u0026gt;; 函式撰寫規範 // ✅ 正確範例 - 明確的參數和回傳型別 async function fetchUserData(userId: number): Promise\u0026lt;User | null\u0026gt; { try { const response = await api.get\u0026lt;ApiResponse\u0026lt;User\u0026gt;\u0026gt;(`/users/${userId}`); return response.data.data; } catch (error) { console.error(\u0026#39;Failed to fetch user data:\u0026#39;, error); return null; } } // ✅ 正確範例 - 箭頭函式與型別推斷 const formatCurrency = (amount: number, currency = \u0026#39;TWD\u0026#39;): string =\u0026gt; { return new Intl.NumberFormat(\u0026#39;zh-TW\u0026#39;, { style: \u0026#39;currency\u0026#39;, currency, }).format(amount); }; // ✅ 正確範例 - 高階函式 const createValidator = \u0026lt;T\u0026gt;( validator: (value: T) =\u0026gt; boolean, errorMessage: string ) =\u0026gt; { return (value: T): ValidationResult =\u0026gt; ({ isValid: validator(value), message: validator(value) ? \u0026#39;\u0026#39; : errorMessage, }); }; 3.4 Vue 3 Composition API 撰寫規範 \u0026lt;script setup\u0026gt; 結構規範 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 1. 導入 Vue 相關 API import { ref, computed, watch, onMounted } from \u0026#39;vue\u0026#39;; // 2. 導入 Composables import { useAuth } from \u0026#39;@/composables/useAuth\u0026#39;; import { useApi } from \u0026#39;@/composables/useApi\u0026#39;; // 3. 導入其他模組 import { formatDate } from \u0026#39;@/utils/format\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // 4. 定義 Props 介面 interface Props { userId: number; isEditable?: boolean; } // 5. 定義 Emits 介面 interface Emits { \u0026#39;user-updated\u0026#39;: [user: User]; \u0026#39;error\u0026#39;: [error: string]; } // 6. 宣告 Props 和 Emits const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { isEditable: false, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // 7. 響應式資料 const user = ref\u0026lt;User | null\u0026gt;(null); const loading = ref(false); const error = ref\u0026lt;string\u0026gt;(\u0026#39;\u0026#39;); // 8. 計算屬性 const displayName = computed(() =\u0026gt; { return user.value ? `${user.value.firstName} ${user.value.lastName}` : \u0026#39;\u0026#39;; }); const canEdit = computed(() =\u0026gt; { return props.isEditable \u0026amp;\u0026amp; user.value?.isActive; }); // 9. 監聽器 watch( () =\u0026gt; props.userId, async (newUserId) =\u0026gt; { if (newUserId) { await loadUser(); } }, { immediate: true } ); // 10. 方法 const loadUser = async (): Promise\u0026lt;void\u0026gt; =\u0026gt; { loading.value = true; error.value = \u0026#39;\u0026#39;; try { const userData = await fetchUserData(props.userId); user.value = userData; } catch (err) { error.value = \u0026#39;載入使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } finally { loading.value = false; } }; const updateUser = async (userData: Partial\u0026lt;User\u0026gt;): Promise\u0026lt;void\u0026gt; =\u0026gt; { if (!user.value) return; try { const updatedUser = await updateUserData(user.value.id, userData); user.value = updatedUser; emit(\u0026#39;user-updated\u0026#39;, updatedUser); } catch (err) { error.value = \u0026#39;更新使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } }; // 11. 生命週期鉤子 onMounted(() =\u0026gt; { console.log(\u0026#39;Component mounted\u0026#39;); }); // 12. 暴露給父元件的方法/屬性 (如需要) defineExpose({ loadUser, updateUser, }); \u0026lt;/script\u0026gt; 3.5 程式碼品質規範 註解撰寫規範 /** * 使用者資料服務類別 * * 提供使用者相關的 API 操作方法，包含： * - 取得使用者資料 * - 更新使用者資料 * - 刪除使用者 * * @example * ```typescript * const userService = new UserService(); * const user = await userService.getUser(123); * ``` */ export class UserService { /** * 根據 ID 取得使用者資料 * * @param userId - 使用者 ID * @returns 使用者資料，如果找不到則回傳 null * @throws {ApiError} 當 API 請求失敗時拋出錯誤 * * @example * ```typescript * const user = await userService.getUser(123); * if (user) { * console.log(user.name); * } * ``` */ async getUser(userId: number): Promise\u0026lt;User | null\u0026gt; { // TODO: 實作快取機制 // FIXME: 處理網路錯誤重試邏輯 try { const response = await this.api.get(`/users/${userId}`); return response.data; } catch (error) { // 記錄錯誤但不拋出，讓呼叫方決定如何處理 console.error(`Failed to fetch user ${userId}:`, error); return null; } } } 錯誤處理規範 // ✅ 正確範例 - 統一的錯誤處理 export class ApiError extends Error { constructor( message: string, public status: number, public code?: string ) { super(message); this.name = \u0026#39;ApiError\u0026#39;; } } // ✅ 正確範例 - 錯誤邊界處理 const handleApiError = (error: unknown): never =\u0026gt; { if (error instanceof ApiError) { switch (error.status) { case 401: // 重新導向到登入頁面 router.push(\u0026#39;/login\u0026#39;); break; case 403: // 顯示權限不足訊息 showErrorMessage(\u0026#39;您沒有權限執行此操作\u0026#39;); break; case 500: // 顯示伺服器錯誤訊息 showErrorMessage(\u0026#39;伺服器發生錯誤，請稍後再試\u0026#39;); break; default: showErrorMessage(error.message); } } else { // 未知錯誤 console.error(\u0026#39;Unexpected error:\u0026#39;, error); showErrorMessage(\u0026#39;發生未知錯誤\u0026#39;); } throw error; }; 4. 元件開發規範 4.1 Vue 單檔元件 (SFC) 結構 標準 SFC 結構順序 \u0026lt;!-- 1. 模板區域 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-profile\u0026#34;\u0026gt; \u0026lt;!-- 內容 --\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 2. 邏輯區域 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 邏輯代碼 \u0026lt;/script\u0026gt; \u0026lt;!-- 3. 樣式區域 --\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; // 樣式代碼 \u0026lt;/style\u0026gt; 完整元件範例 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-card\u0026#34; :class=\u0026#34;cardClasses\u0026#34;\u0026gt; \u0026lt;!-- 頭像區域 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__avatar\u0026#34;\u0026gt; \u0026lt;img :src=\u0026#34;user.avatar || defaultAvatar\u0026#34; :alt=\u0026#34;`${user.name} 的頭像`\u0026#34; class=\u0026#34;user-card__avatar-img\u0026#34; @error=\u0026#34;handleImageError\u0026#34; /\u0026gt; \u0026lt;div v-if=\u0026#34;showStatus\u0026#34; class=\u0026#34;user-card__status\u0026#34; :class=\u0026#34;statusClass\u0026#34;\u0026gt; {{ statusText }} \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 使用者資訊 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__content\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;user-card__name\u0026#34;\u0026gt;{{ user.name }}\u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;user-card__email\u0026#34;\u0026gt;{{ user.email }}\u0026lt;/p\u0026gt; \u0026lt;!-- 標籤 --\u0026gt; \u0026lt;div v-if=\u0026#34;user.tags?.length\u0026#34; class=\u0026#34;user-card__tags\u0026#34;\u0026gt; \u0026lt;span v-for=\u0026#34;tag in user.tags\u0026#34; :key=\u0026#34;tag\u0026#34; class=\u0026#34;user-card__tag\u0026#34; \u0026gt; {{ tag }} \u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 動作按鈕 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__actions\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleEdit\u0026#34; \u0026gt; 編輯 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleView\u0026#34; \u0026gt; 查看 \u0026lt;/BaseButton\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 載入狀態 --\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;user-card__loading\u0026#34;\u0026gt; \u0026lt;LoadingSpinner size=\u0026#34;small\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed, ref } from \u0026#39;vue\u0026#39;; import BaseButton from \u0026#39;@/components/base/BaseButton.vue\u0026#39;; import LoadingSpinner from \u0026#39;@/components/base/LoadingSpinner.vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // Props 定義 interface Props { user: User; variant?: \u0026#39;default\u0026#39; | \u0026#39;compact\u0026#39; | \u0026#39;detailed\u0026#39;; showStatus?: boolean; interactive?: boolean; } // Emits 定義 interface Emits { edit: [user: User]; view: [user: User]; \u0026#39;avatar-error\u0026#39;: [user: User]; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { variant: \u0026#39;default\u0026#39;, showStatus: true, interactive: true, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // Composables const { t } = useI18n(); // 響應式資料 const loading = ref(false); const defaultAvatar = \u0026#39;/images/default-avatar.png\u0026#39;; // 計算屬性 const cardClasses = computed(() =\u0026gt; ({ [`user-card--${props.variant}`]: true, \u0026#39;user-card--interactive\u0026#39;: props.interactive, \u0026#39;user-card--loading\u0026#39;: loading.value, })); const statusClass = computed(() =\u0026gt; ({ \u0026#39;user-card__status--online\u0026#39;: props.user.isOnline, \u0026#39;user-card__status--offline\u0026#39;: !props.user.isOnline, })); const statusText = computed(() =\u0026gt; { return props.user.isOnline ? t(\u0026#39;common.online\u0026#39;) : t(\u0026#39;common.offline\u0026#39;); }); // 方法 const handleEdit = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;edit\u0026#39;, props.user); }; const handleView = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;view\u0026#39;, props.user); }; const handleImageError = (): void =\u0026gt; { emit(\u0026#39;avatar-error\u0026#39;, props.user); }; \u0026lt;/script\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; .user-card { @apply bg-white rounded-lg shadow-md p-4 transition-all duration-200; \u0026amp;--interactive { @apply hover:shadow-lg cursor-pointer; } \u0026amp;--loading { @apply opacity-50 pointer-events-none; } \u0026amp;__avatar { @apply relative flex-shrink-0; } \u0026amp;__avatar-img { @apply w-12 h-12 rounded-full object-cover; } \u0026amp;__status { @apply absolute -bottom-1 -right-1 px-2 py-1 text-xs rounded-full text-white; \u0026amp;--online { @apply bg-green-500; } \u0026amp;--offline { @apply bg-gray-400; } } \u0026amp;__content { @apply flex-1 ml-4; } \u0026amp;__name { @apply text-lg font-semibold text-gray-900 mb-1; } \u0026amp;__email { @apply text-sm text-gray-600 mb-2; } \u0026amp;__tags { @apply flex flex-wrap gap-1 mb-3; } \u0026amp;__tag { @apply px-2 py-1 text-xs bg-blue-100 text-blue-800 rounded; } \u0026amp;__actions { @apply flex gap-2; } \u0026amp;__loading { @apply absolute inset-0 flex items-center justify-center bg-white bg-opacity-75; } // 變體樣式 \u0026amp;--compact { @apply p-2; .user-card__avatar-img { @apply w-8 h-8; } .user-card__name { @apply text-base; } } \u0026amp;--detailed { @apply p-6; .user-card__avatar-img { @apply w-16 h-16; } } } \u0026lt;/style\u0026gt; 4.2 Props 設計規範 Props 型別定義 // ✅ 正確範例 - 完整的 Props 介面 interface ButtonProps { // 必要屬性 label: string; // 選擇性屬性with default values variant?: \u0026#39;primary\u0026#39; | \u0026#39;secondary\u0026#39; | \u0026#39;danger\u0026#39; | \u0026#39;ghost\u0026#39;; size?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; disabled?: boolean; loading?: boolean; // 複雜型別 icon?: { name: string; position: \u0026#39;left\u0026#39; | \u0026#39;right\u0026#39;; }; // 函式型別 onClick?: (event: MouseEvent) =\u0026gt; void; } const props = withDefaults(defineProps\u0026lt;ButtonProps\u0026gt;(), { variant: \u0026#39;primary\u0026#39;, size: \u0026#39;medium\u0026#39;, disabled: false, loading: false, }); Props 驗證 // ✅ 正確範例 - 執行時驗證 interface FormInputProps { modelValue: string; type?: \u0026#39;text\u0026#39; | \u0026#39;email\u0026#39; | \u0026#39;password\u0026#39; | \u0026#39;number\u0026#39;; placeholder?: string; required?: boolean; maxLength?: number; pattern?: string; validator?: (value: string) =\u0026gt; boolean | string; } const props = withDefaults(defineProps\u0026lt;FormInputProps\u0026gt;(), { type: \u0026#39;text\u0026#39;, required: false, }); // 自定義驗證邏輯 const isValid = computed(() =\u0026gt; { if (props.required \u0026amp;\u0026amp; !props.modelValue) { return false; } if (props.maxLength \u0026amp;\u0026amp; props.modelValue.length \u0026gt; props.maxLength) { return false; } if (props.pattern \u0026amp;\u0026amp; !new RegExp(props.pattern).test(props.modelValue)) { return false; } if (props.validator) { const result = props.validator(props.modelValue); return result === true; } return true; }); 4.3 Emits 事件規範 事件定義與觸發 // ✅ 正確範例 - 型別安全的事件定義 interface FormEmits { // v-model 雙向綁定 \u0026#39;update:modelValue\u0026#39;: [value: string]; // 表單事件 submit: [data: FormData]; cancel: []; // 驗證事件 \u0026#39;validation-error\u0026#39;: [errors: ValidationError[]]; \u0026#39;validation-success\u0026#39;: []; // 使用者互動事件 \u0026#39;field-focus\u0026#39;: [fieldName: string]; \u0026#39;field-blur\u0026#39;: [fieldName: string, value: string]; } const emit = defineEmits\u0026lt;FormEmits\u0026gt;(); // 事件觸發範例 const handleSubmit = (formData: FormData): void =\u0026gt; { // 驗證表單 const errors = validateForm(formData); if (errors.length \u0026gt; 0) { emit(\u0026#39;validation-error\u0026#39;, errors); return; } emit(\u0026#39;validation-success\u0026#39;); emit(\u0026#39;submit\u0026#39;, formData); }; const handleCancel = (): void =\u0026gt; { emit(\u0026#39;cancel\u0026#39;); }; // v-model 實作 const updateValue = (newValue: string): void =\u0026gt; { emit(\u0026#39;update:modelValue\u0026#39;, newValue); }; 4.4 Slots 使用規範 具名插槽設計 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;header v-if=\u0026#34;$slots.header\u0026#34; class=\u0026#34;card__header\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;header\u0026#34; :title=\u0026#34;title\u0026#34; :subtitle=\u0026#34;subtitle\u0026#34; /\u0026gt; \u0026lt;/header\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;main class=\u0026#34;card__content\u0026#34;\u0026gt; \u0026lt;slot :data=\u0026#34;data\u0026#34; :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/main\u0026gt; \u0026lt;!-- 動作按鈕插槽 --\u0026gt; \u0026lt;footer v-if=\u0026#34;$slots.actions\u0026#34; class=\u0026#34;card__actions\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;actions\u0026#34; :save=\u0026#34;handleSave\u0026#34; :cancel=\u0026#34;handleCancel\u0026#34; :canSave=\u0026#34;canSave\u0026#34; /\u0026gt; \u0026lt;/footer\u0026gt; \u0026lt;!-- 條件式插槽 --\u0026gt; \u0026lt;div v-if=\u0026#34;$slots.sidebar\u0026#34; class=\u0026#34;card__sidebar\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;sidebar\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { title?: string; subtitle?: string; data: any; loading?: boolean; } const props = defineProps\u0026lt;Props\u0026gt;(); // 計算屬性 const canSave = computed(() =\u0026gt; { return !props.loading \u0026amp;\u0026amp; isDataValid(props.data); }); // 提供給插槽的方法 const handleSave = (): void =\u0026gt; { // 儲存邏輯 }; const handleCancel = (): void =\u0026gt; { // 取消邏輯 }; \u0026lt;/script\u0026gt; 插槽使用範例 \u0026lt;template\u0026gt; \u0026lt;Card :data=\u0026#34;userData\u0026#34; :loading=\u0026#34;loading\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;template #header=\u0026#34;{ title, subtitle }\u0026#34;\u0026gt; \u0026lt;h2\u0026gt;{{ title || \u0026#39;使用者資料\u0026#39; }}\u0026lt;/h2\u0026gt; \u0026lt;p v-if=\u0026#34;subtitle\u0026#34;\u0026gt;{{ subtitle }}\u0026lt;/p\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;template #default=\u0026#34;{ data, loading }\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;!loading\u0026#34;\u0026gt; \u0026lt;UserForm :user=\u0026#34;data\u0026#34; @update=\u0026#34;handleUserUpdate\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;LoadingSpinner v-else /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 動作插槽 --\u0026gt; \u0026lt;template #actions=\u0026#34;{ save, cancel, canSave }\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; :disabled=\u0026#34;!canSave\u0026#34; @click=\u0026#34;save\u0026#34; \u0026gt; 儲存 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; @click=\u0026#34;cancel\u0026#34; \u0026gt; 取消 \u0026lt;/BaseButton\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;/Card\u0026gt; \u0026lt;/template\u0026gt; 4.5 元件組合與複用 高階元件 (HOC) 模式 \u0026lt;!-- withLoading.vue - 高階元件 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;with-loading\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;loading-overlay\u0026#34;\u0026gt; \u0026lt;LoadingSpinner :size=\u0026#34;loadingSize\u0026#34; /\u0026gt; \u0026lt;p v-if=\u0026#34;loadingText\u0026#34;\u0026gt;{{ loadingText }}\u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div :class=\u0026#34;{ \u0026#39;is-loading\u0026#39;: loading }\u0026#34;\u0026gt; \u0026lt;slot :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { loading: boolean; loadingText?: string; loadingSize?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; } withDefaults(defineProps\u0026lt;Props\u0026gt;(), { loadingSize: \u0026#39;medium\u0026#39;, }); \u0026lt;/script\u0026gt; 組合式元件使用 \u0026lt;template\u0026gt; \u0026lt;WithLoading :loading=\u0026#34;isLoading\u0026#34; loading-text=\u0026#34;載入使用者資料中...\u0026#34;\u0026gt; \u0026lt;UserProfile :user=\u0026#34;userData\u0026#34; @edit=\u0026#34;handleEdit\u0026#34; @delete=\u0026#34;handleDelete\u0026#34; /\u0026gt; \u0026lt;/WithLoading\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import WithLoading from \u0026#39;@/components/hoc/WithLoading.vue\u0026#39;; import UserProfile from \u0026#39;@/components/UserProfile.vue\u0026#39;; const isLoading = ref(false); const userData = ref(null); const handleEdit = (user: User): void =\u0026gt; { // 編輯邏輯 }; const handleDelete = (user: User): void =\u0026gt; { // 刪除邏輯 }; \u0026lt;/script\u0026gt; 5. 樣式與 Tailwind CSS 規範 5.1 Tailwind CSS 設定 tailwind.config.js 範例 /** @type {import(\u0026#39;tailwindcss\u0026#39;).Config} */ export default { content: [ \u0026#39;./index.html\u0026#39;, \u0026#39;./src/**/*.{vue,js,ts,jsx,tsx}\u0026#39;, ], theme: { extend: { // 顏色系統 colors: { primary: { 50: \u0026#39;#eff6ff\u0026#39;, 100: \u0026#39;#dbeafe\u0026#39;, 200: \u0026#39;#bfdbfe\u0026#39;, 300: \u0026#39;#93c5fd\u0026#39;, 400: \u0026#39;#60a5fa\u0026#39;, 500: \u0026#39;#3b82f6\u0026#39;, // 主要品牌色 600: \u0026#39;#2563eb\u0026#39;, 700: \u0026#39;#1d4ed8\u0026#39;, 800: \u0026#39;#1e40af\u0026#39;, 900: \u0026#39;#1e3a8a\u0026#39;, 950: \u0026#39;#172554\u0026#39;, }, secondary: { 50: \u0026#39;#f8fafc\u0026#39;, 500: \u0026#39;#64748b\u0026#39;, 900: \u0026#39;#0f172a\u0026#39;, }, success: { 50: \u0026#39;#f0fdf4\u0026#39;, 500: \u0026#39;#22c55e\u0026#39;, 900: \u0026#39;#14532d\u0026#39;, }, warning: { 50: \u0026#39;#fffbeb\u0026#39;, 500: \u0026#39;#f59e0b\u0026#39;, 900: \u0026#39;#78350f\u0026#39;, }, danger: { 50: \u0026#39;#fef2f2\u0026#39;, 500: \u0026#39;#ef4444\u0026#39;, 900: \u0026#39;#7f1d1d\u0026#39;, }, }, // 字型設定 fontFamily: { sans: [ \u0026#39;Noto Sans TC\u0026#39;, \u0026#39;Microsoft JhengHei\u0026#39;, \u0026#39;PingFang TC\u0026#39;, \u0026#39;Helvetica Neue\u0026#39;, \u0026#39;Arial\u0026#39;, \u0026#39;sans-serif\u0026#39;, ], }, // 響應式斷點 screens: { \u0026#39;xs\u0026#39;: \u0026#39;475px\u0026#39;, \u0026#39;sm\u0026#39;: \u0026#39;640px\u0026#39;, \u0026#39;md\u0026#39;: \u0026#39;768px\u0026#39;, \u0026#39;lg\u0026#39;: \u0026#39;1024px\u0026#39;, \u0026#39;xl\u0026#39;: \u0026#39;1280px\u0026#39;, \u0026#39;2xl\u0026#39;: \u0026#39;1536px\u0026#39;, }, }, }, plugins: [ require(\u0026#39;@tailwindcss/forms\u0026#39;), require(\u0026#39;@tailwindcss/typography\u0026#39;), ], }; 5.2 RWD 響應式設計原則 Mobile-First 設計策略 \u0026lt;template\u0026gt; \u0026lt;!-- 響應式網格系統 --\u0026gt; \u0026lt;div class=\u0026#34;container mx-auto px-4\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-4\u0026#34;\u0026gt; \u0026lt;div v-for=\u0026#34;item in items\u0026#34; :key=\u0026#34;item.id\u0026#34; class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 響應式圖片 --\u0026gt; \u0026lt;img :src=\u0026#34;item.image\u0026#34; :alt=\u0026#34;item.title\u0026#34; class=\u0026#34;w-full h-32 sm:h-40 lg:h-48 object-cover\u0026#34; /\u0026gt; \u0026lt;!-- 響應式文字 --\u0026gt; \u0026lt;div class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;text-lg sm:text-xl lg:text-2xl font-semibold\u0026#34;\u0026gt; {{ item.title }} \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm sm:text-base text-gray-600\u0026#34;\u0026gt; {{ item.description }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 響應式導航 --\u0026gt; \u0026lt;nav class=\u0026#34;bg-white shadow\u0026#34;\u0026gt; \u0026lt;!-- 桌面版導航 --\u0026gt; \u0026lt;div class=\u0026#34;hidden lg:flex items-center space-x-8 px-6 py-4\u0026#34;\u0026gt; \u0026lt;a v-for=\u0026#34;link in navLinks\u0026#34; :key=\u0026#34;link.path\u0026#34; :href=\u0026#34;link.path\u0026#34;\u0026gt; {{ link.title }} \u0026lt;/a\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 行動版選單 --\u0026gt; \u0026lt;div class=\u0026#34;lg:hidden\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleMobileMenu\u0026#34; class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;MenuIcon class=\u0026#34;w-6 h-6\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/nav\u0026gt; \u0026lt;/template\u0026gt; 5.3 顏色與主題設計 CSS 變數主題系統 :root { /* 品牌色 */ --color-primary: #3b82f6; --color-secondary: #64748b; /* 語意化顏色 */ --color-success: #22c55e; --color-warning: #f59e0b; --color-danger: #ef4444; /* 背景色 */ --bg-primary: #ffffff; --bg-secondary: #f8fafc; /* 文字色 */ --text-primary: #111827; --text-secondary: #4b5563; } /* 暗色主題 */ [data-theme=\u0026#34;dark\u0026#34;] { --bg-primary: #111827; --bg-secondary: #1f2937; --text-primary: #f9fafb; --text-secondary: #d1d5db; } 5.4 共用樣式元件 基礎元件樣式 @layer components { /* 按鈕樣式 */ .btn { @apply inline-flex items-center px-4 py-2 text-sm font-medium rounded-md transition-colors focus:outline-none focus:ring-2; } .btn-primary { @apply btn bg-primary-500 text-white hover:bg-primary-600; } .btn-secondary { @apply btn bg-gray-200 text-gray-900 hover:bg-gray-300; } /* 表單樣式 */ .form-input { @apply w-full px-3 py-2 border border-gray-300 rounded-md focus:ring-1 focus:ring-primary-500 focus:border-primary-500; } /* 卡片樣式 */ .card { @apply bg-white rounded-lg shadow-md p-4; } } 總結 本前端開發指引提供了完整的開發規範，涵蓋了專案結構、命名規範、程式撰寫風格、元件開發和樣式設計等核心面向。請開發團隊嚴格遵循這些規範，以確保程式碼品質和專案的可維護性。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%89%8D%E7%AB%AF%E9%96%8B%E7%99%BC%E6%8C%87%E5%BC%95/","summary":"前端開發指引 文件資訊 版本: 1.0.0 建立日期: 2025-08-11 適用專案: 大型金融級 Web 專案 技術棧: Vue 3.x + TypeScript + Tailwind CSS 目錄 專案目錄與檔案結構規範 命名規範 程式撰寫風格與 Lint 設定 元件開發規範 樣式與 Tailwind CSS 規範 API 串接與資料存取規範 狀態管理規範 多語系處理規範 測試規範 安全性考量 效能優化規範 無障礙設計規範 版本控制與分支策略 專案建置與部署流程 程式碼審查規範 常見錯誤處理與 Debug 流程 開發工具與環境設定 團隊協作與溝通規範 1. 專案目錄與檔案結構規範 1.1 標準專案結構 frontend-project/ ├── public/ # 靜態資源 │ ├── favicon.ico │ ├── index.html │ └── manifest.json ├── src/ # 原始碼 │ ├── api/ # API 相關 │ │ ├── modules/ # 依功能模組分類 │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ ├── interceptors/ # 攔截器 │ │ └── types/ # API 型別定義 │ ├── assets/ # 靜態資源 │ │ ├── images/ │ │ ├── icons/ │ │ └── fonts/ │ ├── components/ # 共用元件 │ │ ├── base/ # 基礎元件 │ │ │ ├── BaseButton.vue │ │ │ ├── BaseInput.vue │ │ │ └── BaseModal.vue │ │ ├── business/ # 業務元件 │ │ └── layout/ # 版面元件 │ │ ├── Header.vue │ │ ├── Sidebar.vue │ │ └── Footer.vue │ ├── composables/ # Vue 3 Composition API │ │ ├── useAuth.ts │ │ ├── useApi.ts │ │ └── useLocalStorage.ts │ ├── constants/ # 常數定義 │ │ ├── api.ts │ │ ├── routes.ts │ │ └── config.ts │ ├── directives/ # 自定義指令 │ ├── i18n/ # 多語系 │ │ ├── locales/ │ │ │ ├── zh-TW.json │ │ │ ├── en-US.json │ │ │ └── ja-JP.json │ │ └── index.ts │ ├── layouts/ # 版面配置 │ │ ├── DefaultLayout.vue │ │ ├── AuthLayout.vue │ │ └── EmptyLayout.vue │ ├── middleware/ # 中間件 │ │ ├── auth.ts │ │ └── permission.ts │ ├── pages/ # 頁面元件 │ │ ├── auth/ │ │ │ ├── Login.vue │ │ │ └── Register.vue │ │ ├── dashboard/ │ │ └── user/ │ ├── plugins/ # 插件 │ │ ├── axios.ts │ │ ├── i18n.ts │ │ └── router.ts │ ├── router/ # 路由設定 │ │ ├── modules/ # 路由模組 │ │ │ ├── auth.ts │ │ │ └── dashboard.ts │ │ └── index.ts │ ├── stores/ # Pinia 狀態管理 │ │ ├── modules/ │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ └── index.ts │ ├── styles/ # 樣式檔案 │ │ ├── globals.css │ │ ├── variables.css │ │ └── components/ │ ├── types/ # TypeScript 型別定義 │ │ ├── api.ts │ │ ├── auth.ts │ │ └── global.ts │ ├── utils/ # 工具函式 │ │ ├── format.ts │ │ ├── validation.ts │ │ └── storage.ts │ ├── App.vue # 根元件 │ └── main.ts # 應用程式進入點 ├── tests/ # 測試檔案 │ ├── unit/ # 單元測試 │ ├── e2e/ # E2E 測試 │ └── __mocks__/ # Mock 檔案 ├── .env # 環境變數 ├── .env.development ├── .env.production ├── .eslintrc.js # ESLint 設定 ├── .prettierrc # Prettier 設定 ├── tailwind.config.js # Tailwind CSS 設定 ├── vite.config.ts # Vite 設定 ├── tsconfig.json # TypeScript 設定 └── package.json # 套件管理 1.2 檔案命名原則 檔案類型對應命名方式 Vue 元件: PascalCase (如 UserProfile.vue) TypeScript 檔案: camelCase (如 userService.ts) CSS/SCSS 檔案: kebab-case (如 user-profile.scss) 測試檔案: 與被測檔案同名 + .test 或 .spec (如 UserProfile.test.ts) 型別定義檔案: camelCase + .d.ts (如 userTypes.d.ts) 特殊檔案命名 頁面元件: PascalCase，通常以頁面功能命名 (如 UserManagement.vue) Layout 元件: PascalCase + Layout 後綴 (如 DashboardLayout.vue) Store 檔案: camelCase，以業務領域命名 (如 userStore.ts) API 檔案: camelCase，以 API 服務命名 (如 userApi.ts) 2. 命名規範 2.1 檔案與資料夾命名 資料夾命名 使用 kebab-case (小寫字母 + 連字號) 名稱應簡潔且具描述性 ✅ 正確範例 user-management/ auth-service/ api-client/ ❌ 錯誤範例 UserManagement/ authService/ API_Client/ 檔案命名 Vue 元件檔案: PascalCase JavaScript/TypeScript 檔案: camelCase 樣式檔案: kebab-case 設定檔案: kebab-case 或 camelCase (依慣例) // ✅ 正確範例 UserProfile.vue userService.ts user-profile.scss vite.config.ts // ❌ 錯誤範例 userprofile.vue UserService.ts user_profile.scss vite_config.ts 2.2 變數與函式命名 JavaScript/TypeScript 變數 使用 camelCase 常數使用 UPPER_SNAKE_CASE 私有變數以 _ 開頭 布林值變數使用 is、has、can、should 等前綴 // ✅ 正確範例 const userName = \u0026#39;John Doe\u0026#39;; const API_BASE_URL = \u0026#39;https://api.example.com\u0026#39;; const _privateVariable = \u0026#39;private\u0026#39;; const isLoggedIn = true; const hasPermission = false; const canEdit = true; const shouldUpdate = false; // ❌ 錯誤範例 const user_name = \u0026#39;John Doe\u0026#39;; const apiBaseUrl = \u0026#39;https://api.example.com\u0026#39;; // 常數應使用大寫 const privateVariable = \u0026#39;private\u0026#39;; // 私有變數缺少前綴 const loggedIn = true; // 布林值缺少前綴 函式命名 使用 camelCase 動詞開頭，描述函式的動作 事件處理器使用 handle 前綴 取得資料使用 get、fetch 前綴 設定資料使用 set、update 前綴 // ✅ 正確範例 function getUserData() { } function handleButtonClick() { } function validateEmail() { } function formatCurrency() { } function updateUserProfile() { } function fetchUserList() { } // ❌ 錯誤範例 function userData() { } // 缺少動詞 function buttonClick() { } // 事件處理器缺少 handle 前綴 function email() { } // 不明確的命名 function currency() { } // 不明確的命名 2.3 Vue 元件命名 元件名稱 使用 PascalCase 多個單字組合，避免單一單字 基礎元件使用 Base 前綴 業務元件使用具體的業務領域命名 \u0026lt;!-- ✅ 正確範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: UserProfile.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: BaseButton.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: PaymentForm.vue \u0026lt;/script\u0026gt; \u0026lt;!-- ❌ 錯誤範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: user.vue - 命名太簡短 \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: button.vue - 應使用 BaseButton \u0026lt;/script\u0026gt; Props 命名 定義時使用 camelCase HTML 模板中使用 kebab-case \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 interface Props { userName: string; isVisible: boolean; maxLength?: number; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { maxLength: 100 }); \u0026lt;/script\u0026gt; \u0026lt;template\u0026gt; \u0026lt;!-- HTML 模板中使用 kebab-case --\u0026gt; \u0026lt;UserProfile :user-name=\u0026#34;currentUser\u0026#34; :is-visible=\u0026#34;showProfile\u0026#34; :max-length=\u0026#34;200\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; Event 命名 使用 kebab-case 動詞開頭，描述事件的動作 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 const emit = defineEmits\u0026lt;{ \u0026#39;update:modelValue\u0026#39;: [value: string]; \u0026#39;user-created\u0026#39;: [user: User]; \u0026#39;form-submitted\u0026#39;: [data: FormData]; \u0026#39;item-selected\u0026#39;: [item: Item]; }\u0026gt;(); // 觸發事件 emit(\u0026#39;user-created\u0026#39;, newUser); emit(\u0026#39;form-submitted\u0026#39;, formData); \u0026lt;/script\u0026gt; 3. 程式撰寫風格與 Lint 設定 3.1 ESLint 設定 eslint.config.js 範例 import { defineConfig } from \u0026#39;eslint-define-config\u0026#39;; import vue from \u0026#39;eslint-plugin-vue\u0026#39;; import typescript from \u0026#39;@typescript-eslint/eslint-plugin\u0026#39;; import typescriptParser from \u0026#39;@typescript-eslint/parser\u0026#39;; import prettier from \u0026#39;eslint-plugin-prettier\u0026#39;; export default defineConfig([ { files: [\u0026#39;**/*.{js,ts,vue}\u0026#39;], languageOptions: { parser: typescriptParser, parserOptions: { ecmaVersion: 2022, sourceType: \u0026#39;module\u0026#39;, extraFileExtensions: [\u0026#39;.vue\u0026#39;] } }, plugins: { vue, \u0026#39;@typescript-eslint\u0026#39;: typescript, prettier }, rules: { // Vue 規則 \u0026#39;vue/multi-word-component-names\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/component-name-in-template-casing\u0026#39;: [\u0026#39;error\u0026#39;, \u0026#39;PascalCase\u0026#39;], \u0026#39;vue/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/no-multiple-template-root\u0026#39;: \u0026#39;off\u0026#39;, // Vue 3 支援多個根元素 \u0026#39;vue/script-setup-uses-vars\u0026#39;: \u0026#39;error\u0026#39;, // TypeScript 規則 \u0026#39;@typescript-eslint/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;@typescript-eslint/no-explicit-any\u0026#39;: \u0026#39;warn\u0026#39;, \u0026#39;@typescript-eslint/explicit-function-return-type\u0026#39;: \u0026#39;off\u0026#39;, \u0026#39;@typescript-eslint/no-non-null-assertion\u0026#39;: \u0026#39;warn\u0026#39;, // 通用規則 \u0026#39;no-console\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;no-debugger\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;prefer-const\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;no-var\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;object-shorthand\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;prefer-template\u0026#39;: \u0026#39;error\u0026#39;, // Prettier 規則 \u0026#39;prettier/prettier\u0026#39;: \u0026#39;error\u0026#39; } } ]); 3.2 Prettier 設定 .prettierrc 範例 { \u0026#34;semi\u0026#34;: true, \u0026#34;trailingComma\u0026#34;: \u0026#34;es5\u0026#34;, \u0026#34;singleQuote\u0026#34;: true, \u0026#34;printWidth\u0026#34;: 80, \u0026#34;tabWidth\u0026#34;: 2, \u0026#34;useTabs\u0026#34;: false, \u0026#34;bracketSpacing\u0026#34;: true, \u0026#34;bracketSameLine\u0026#34;: false, \u0026#34;arrowParens\u0026#34;: \u0026#34;avoid\u0026#34;, \u0026#34;endOfLine\u0026#34;: \u0026#34;lf\u0026#34;, \u0026#34;vueIndentScriptAndStyle\u0026#34;: true, \u0026#34;htmlWhitespaceSensitivity\u0026#34;: \u0026#34;css\u0026#34; } 3.3 TypeScript 撰寫規範 型別定義規範 // ✅ 正確範例 - 使用 interface 定義物件型別 interface User { id: number; name: string; email: string; isActive: boolean; createdAt: Date; updatedAt?: Date; // 選擇性屬性 } // ✅ 正確範例 - 使用 type 定義聯合型別 type Status = \u0026#39;pending\u0026#39; | \u0026#39;approved\u0026#39; | \u0026#39;rejected\u0026#39;; type Theme = \u0026#39;light\u0026#39; | \u0026#39;dark\u0026#39; | \u0026#39;auto\u0026#39;; // ✅ 正確範例 - 泛型使用 interface ApiResponse\u0026lt;T\u0026gt; { data: T; message: string; success: boolean; code: number; } // ✅ 正確範例 - 函式型別定義 type EventHandler\u0026lt;T = Event\u0026gt; = (event: T) =\u0026gt; void; type AsyncFunction\u0026lt;T\u0026gt; = () =\u0026gt; Promise\u0026lt;T\u0026gt;; 函式撰寫規範 // ✅ 正確範例 - 明確的參數和回傳型別 async function fetchUserData(userId: number): Promise\u0026lt;User | null\u0026gt; { try { const response = await api.get\u0026lt;ApiResponse\u0026lt;User\u0026gt;\u0026gt;(`/users/${userId}`); return response.data.data; } catch (error) { console.error(\u0026#39;Failed to fetch user data:\u0026#39;, error); return null; } } // ✅ 正確範例 - 箭頭函式與型別推斷 const formatCurrency = (amount: number, currency = \u0026#39;TWD\u0026#39;): string =\u0026gt; { return new Intl.NumberFormat(\u0026#39;zh-TW\u0026#39;, { style: \u0026#39;currency\u0026#39;, currency, }).format(amount); }; // ✅ 正確範例 - 高階函式 const createValidator = \u0026lt;T\u0026gt;( validator: (value: T) =\u0026gt; boolean, errorMessage: string ) =\u0026gt; { return (value: T): ValidationResult =\u0026gt; ({ isValid: validator(value), message: validator(value) ? \u0026#39;\u0026#39; : errorMessage, }); }; 3.4 Vue 3 Composition API 撰寫規範 \u0026lt;script setup\u0026gt; 結構規範 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 1. 導入 Vue 相關 API import { ref, computed, watch, onMounted } from \u0026#39;vue\u0026#39;; // 2. 導入 Composables import { useAuth } from \u0026#39;@/composables/useAuth\u0026#39;; import { useApi } from \u0026#39;@/composables/useApi\u0026#39;; // 3. 導入其他模組 import { formatDate } from \u0026#39;@/utils/format\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // 4. 定義 Props 介面 interface Props { userId: number; isEditable?: boolean; } // 5. 定義 Emits 介面 interface Emits { \u0026#39;user-updated\u0026#39;: [user: User]; \u0026#39;error\u0026#39;: [error: string]; } // 6. 宣告 Props 和 Emits const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { isEditable: false, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // 7. 響應式資料 const user = ref\u0026lt;User | null\u0026gt;(null); const loading = ref(false); const error = ref\u0026lt;string\u0026gt;(\u0026#39;\u0026#39;); // 8. 計算屬性 const displayName = computed(() =\u0026gt; { return user.value ? `${user.value.firstName} ${user.value.lastName}` : \u0026#39;\u0026#39;; }); const canEdit = computed(() =\u0026gt; { return props.isEditable \u0026amp;\u0026amp; user.value?.isActive; }); // 9. 監聽器 watch( () =\u0026gt; props.userId, async (newUserId) =\u0026gt; { if (newUserId) { await loadUser(); } }, { immediate: true } ); // 10. 方法 const loadUser = async (): Promise\u0026lt;void\u0026gt; =\u0026gt; { loading.value = true; error.value = \u0026#39;\u0026#39;; try { const userData = await fetchUserData(props.userId); user.value = userData; } catch (err) { error.value = \u0026#39;載入使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } finally { loading.value = false; } }; const updateUser = async (userData: Partial\u0026lt;User\u0026gt;): Promise\u0026lt;void\u0026gt; =\u0026gt; { if (!user.value) return; try { const updatedUser = await updateUserData(user.value.id, userData); user.value = updatedUser; emit(\u0026#39;user-updated\u0026#39;, updatedUser); } catch (err) { error.value = \u0026#39;更新使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } }; // 11. 生命週期鉤子 onMounted(() =\u0026gt; { console.log(\u0026#39;Component mounted\u0026#39;); }); // 12. 暴露給父元件的方法/屬性 (如需要) defineExpose({ loadUser, updateUser, }); \u0026lt;/script\u0026gt; 3.5 程式碼品質規範 註解撰寫規範 /** * 使用者資料服務類別 * * 提供使用者相關的 API 操作方法，包含： * - 取得使用者資料 * - 更新使用者資料 * - 刪除使用者 * * @example * ```typescript * const userService = new UserService(); * const user = await userService.getUser(123); * ``` */ export class UserService { /** * 根據 ID 取得使用者資料 * * @param userId - 使用者 ID * @returns 使用者資料，如果找不到則回傳 null * @throws {ApiError} 當 API 請求失敗時拋出錯誤 * * @example * ```typescript * const user = await userService.getUser(123); * if (user) { * console.log(user.name); * } * ``` */ async getUser(userId: number): Promise\u0026lt;User | null\u0026gt; { // TODO: 實作快取機制 // FIXME: 處理網路錯誤重試邏輯 try { const response = await this.api.get(`/users/${userId}`); return response.data; } catch (error) { // 記錄錯誤但不拋出，讓呼叫方決定如何處理 console.error(`Failed to fetch user ${userId}:`, error); return null; } } } 錯誤處理規範 // ✅ 正確範例 - 統一的錯誤處理 export class ApiError extends Error { constructor( message: string, public status: number, public code?: string ) { super(message); this.name = \u0026#39;ApiError\u0026#39;; } } // ✅ 正確範例 - 錯誤邊界處理 const handleApiError = (error: unknown): never =\u0026gt; { if (error instanceof ApiError) { switch (error.status) { case 401: // 重新導向到登入頁面 router.push(\u0026#39;/login\u0026#39;); break; case 403: // 顯示權限不足訊息 showErrorMessage(\u0026#39;您沒有權限執行此操作\u0026#39;); break; case 500: // 顯示伺服器錯誤訊息 showErrorMessage(\u0026#39;伺服器發生錯誤，請稍後再試\u0026#39;); break; default: showErrorMessage(error.message); } } else { // 未知錯誤 console.error(\u0026#39;Unexpected error:\u0026#39;, error); showErrorMessage(\u0026#39;發生未知錯誤\u0026#39;); } throw error; }; 4. 元件開發規範 4.1 Vue 單檔元件 (SFC) 結構 標準 SFC 結構順序 \u0026lt;!-- 1. 模板區域 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-profile\u0026#34;\u0026gt; \u0026lt;!-- 內容 --\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 2. 邏輯區域 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 邏輯代碼 \u0026lt;/script\u0026gt; \u0026lt;!-- 3. 樣式區域 --\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; // 樣式代碼 \u0026lt;/style\u0026gt; 完整元件範例 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-card\u0026#34; :class=\u0026#34;cardClasses\u0026#34;\u0026gt; \u0026lt;!-- 頭像區域 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__avatar\u0026#34;\u0026gt; \u0026lt;img :src=\u0026#34;user.avatar || defaultAvatar\u0026#34; :alt=\u0026#34;`${user.name} 的頭像`\u0026#34; class=\u0026#34;user-card__avatar-img\u0026#34; @error=\u0026#34;handleImageError\u0026#34; /\u0026gt; \u0026lt;div v-if=\u0026#34;showStatus\u0026#34; class=\u0026#34;user-card__status\u0026#34; :class=\u0026#34;statusClass\u0026#34;\u0026gt; {{ statusText }} \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 使用者資訊 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__content\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;user-card__name\u0026#34;\u0026gt;{{ user.name }}\u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;user-card__email\u0026#34;\u0026gt;{{ user.email }}\u0026lt;/p\u0026gt; \u0026lt;!-- 標籤 --\u0026gt; \u0026lt;div v-if=\u0026#34;user.tags?.length\u0026#34; class=\u0026#34;user-card__tags\u0026#34;\u0026gt; \u0026lt;span v-for=\u0026#34;tag in user.tags\u0026#34; :key=\u0026#34;tag\u0026#34; class=\u0026#34;user-card__tag\u0026#34; \u0026gt; {{ tag }} \u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 動作按鈕 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__actions\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleEdit\u0026#34; \u0026gt; 編輯 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleView\u0026#34; \u0026gt; 查看 \u0026lt;/BaseButton\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 載入狀態 --\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;user-card__loading\u0026#34;\u0026gt; \u0026lt;LoadingSpinner size=\u0026#34;small\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed, ref } from \u0026#39;vue\u0026#39;; import BaseButton from \u0026#39;@/components/base/BaseButton.vue\u0026#39;; import LoadingSpinner from \u0026#39;@/components/base/LoadingSpinner.vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // Props 定義 interface Props { user: User; variant?: \u0026#39;default\u0026#39; | \u0026#39;compact\u0026#39; | \u0026#39;detailed\u0026#39;; showStatus?: boolean; interactive?: boolean; } // Emits 定義 interface Emits { edit: [user: User]; view: [user: User]; \u0026#39;avatar-error\u0026#39;: [user: User]; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { variant: \u0026#39;default\u0026#39;, showStatus: true, interactive: true, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // Composables const { t } = useI18n(); // 響應式資料 const loading = ref(false); const defaultAvatar = \u0026#39;/images/default-avatar.png\u0026#39;; // 計算屬性 const cardClasses = computed(() =\u0026gt; ({ [`user-card--${props.variant}`]: true, \u0026#39;user-card--interactive\u0026#39;: props.interactive, \u0026#39;user-card--loading\u0026#39;: loading.value, })); const statusClass = computed(() =\u0026gt; ({ \u0026#39;user-card__status--online\u0026#39;: props.user.isOnline, \u0026#39;user-card__status--offline\u0026#39;: !props.user.isOnline, })); const statusText = computed(() =\u0026gt; { return props.user.isOnline ? t(\u0026#39;common.online\u0026#39;) : t(\u0026#39;common.offline\u0026#39;); }); // 方法 const handleEdit = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;edit\u0026#39;, props.user); }; const handleView = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;view\u0026#39;, props.user); }; const handleImageError = (): void =\u0026gt; { emit(\u0026#39;avatar-error\u0026#39;, props.user); }; \u0026lt;/script\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; .user-card { @apply bg-white rounded-lg shadow-md p-4 transition-all duration-200; \u0026amp;--interactive { @apply hover:shadow-lg cursor-pointer; } \u0026amp;--loading { @apply opacity-50 pointer-events-none; } \u0026amp;__avatar { @apply relative flex-shrink-0; } \u0026amp;__avatar-img { @apply w-12 h-12 rounded-full object-cover; } \u0026amp;__status { @apply absolute -bottom-1 -right-1 px-2 py-1 text-xs rounded-full text-white; \u0026amp;--online { @apply bg-green-500; } \u0026amp;--offline { @apply bg-gray-400; } } \u0026amp;__content { @apply flex-1 ml-4; } \u0026amp;__name { @apply text-lg font-semibold text-gray-900 mb-1; } \u0026amp;__email { @apply text-sm text-gray-600 mb-2; } \u0026amp;__tags { @apply flex flex-wrap gap-1 mb-3; } \u0026amp;__tag { @apply px-2 py-1 text-xs bg-blue-100 text-blue-800 rounded; } \u0026amp;__actions { @apply flex gap-2; } \u0026amp;__loading { @apply absolute inset-0 flex items-center justify-center bg-white bg-opacity-75; } // 變體樣式 \u0026amp;--compact { @apply p-2; .user-card__avatar-img { @apply w-8 h-8; } .user-card__name { @apply text-base; } } \u0026amp;--detailed { @apply p-6; .user-card__avatar-img { @apply w-16 h-16; } } } \u0026lt;/style\u0026gt; 4.2 Props 設計規範 Props 型別定義 // ✅ 正確範例 - 完整的 Props 介面 interface ButtonProps { // 必要屬性 label: string; // 選擇性屬性with default values variant?: \u0026#39;primary\u0026#39; | \u0026#39;secondary\u0026#39; | \u0026#39;danger\u0026#39; | \u0026#39;ghost\u0026#39;; size?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; disabled?: boolean; loading?: boolean; // 複雜型別 icon?: { name: string; position: \u0026#39;left\u0026#39; | \u0026#39;right\u0026#39;; }; // 函式型別 onClick?: (event: MouseEvent) =\u0026gt; void; } const props = withDefaults(defineProps\u0026lt;ButtonProps\u0026gt;(), { variant: \u0026#39;primary\u0026#39;, size: \u0026#39;medium\u0026#39;, disabled: false, loading: false, }); Props 驗證 // ✅ 正確範例 - 執行時驗證 interface FormInputProps { modelValue: string; type?: \u0026#39;text\u0026#39; | \u0026#39;email\u0026#39; | \u0026#39;password\u0026#39; | \u0026#39;number\u0026#39;; placeholder?: string; required?: boolean; maxLength?: number; pattern?: string; validator?: (value: string) =\u0026gt; boolean | string; } const props = withDefaults(defineProps\u0026lt;FormInputProps\u0026gt;(), { type: \u0026#39;text\u0026#39;, required: false, }); // 自定義驗證邏輯 const isValid = computed(() =\u0026gt; { if (props.required \u0026amp;\u0026amp; !props.modelValue) { return false; } if (props.maxLength \u0026amp;\u0026amp; props.modelValue.length \u0026gt; props.maxLength) { return false; } if (props.pattern \u0026amp;\u0026amp; !new RegExp(props.pattern).test(props.modelValue)) { return false; } if (props.validator) { const result = props.validator(props.modelValue); return result === true; } return true; }); 4.3 Emits 事件規範 事件定義與觸發 // ✅ 正確範例 - 型別安全的事件定義 interface FormEmits { // v-model 雙向綁定 \u0026#39;update:modelValue\u0026#39;: [value: string]; // 表單事件 submit: [data: FormData]; cancel: []; // 驗證事件 \u0026#39;validation-error\u0026#39;: [errors: ValidationError[]]; \u0026#39;validation-success\u0026#39;: []; // 使用者互動事件 \u0026#39;field-focus\u0026#39;: [fieldName: string]; \u0026#39;field-blur\u0026#39;: [fieldName: string, value: string]; } const emit = defineEmits\u0026lt;FormEmits\u0026gt;(); // 事件觸發範例 const handleSubmit = (formData: FormData): void =\u0026gt; { // 驗證表單 const errors = validateForm(formData); if (errors.length \u0026gt; 0) { emit(\u0026#39;validation-error\u0026#39;, errors); return; } emit(\u0026#39;validation-success\u0026#39;); emit(\u0026#39;submit\u0026#39;, formData); }; const handleCancel = (): void =\u0026gt; { emit(\u0026#39;cancel\u0026#39;); }; // v-model 實作 const updateValue = (newValue: string): void =\u0026gt; { emit(\u0026#39;update:modelValue\u0026#39;, newValue); }; 4.4 Slots 使用規範 具名插槽設計 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;header v-if=\u0026#34;$slots.header\u0026#34; class=\u0026#34;card__header\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;header\u0026#34; :title=\u0026#34;title\u0026#34; :subtitle=\u0026#34;subtitle\u0026#34; /\u0026gt; \u0026lt;/header\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;main class=\u0026#34;card__content\u0026#34;\u0026gt; \u0026lt;slot :data=\u0026#34;data\u0026#34; :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/main\u0026gt; \u0026lt;!-- 動作按鈕插槽 --\u0026gt; \u0026lt;footer v-if=\u0026#34;$slots.actions\u0026#34; class=\u0026#34;card__actions\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;actions\u0026#34; :save=\u0026#34;handleSave\u0026#34; :cancel=\u0026#34;handleCancel\u0026#34; :canSave=\u0026#34;canSave\u0026#34; /\u0026gt; \u0026lt;/footer\u0026gt; \u0026lt;!-- 條件式插槽 --\u0026gt; \u0026lt;div v-if=\u0026#34;$slots.sidebar\u0026#34; class=\u0026#34;card__sidebar\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;sidebar\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { title?: string; subtitle?: string; data: any; loading?: boolean; } const props = defineProps\u0026lt;Props\u0026gt;(); // 計算屬性 const canSave = computed(() =\u0026gt; { return !props.loading \u0026amp;\u0026amp; isDataValid(props.data); }); // 提供給插槽的方法 const handleSave = (): void =\u0026gt; { // 儲存邏輯 }; const handleCancel = (): void =\u0026gt; { // 取消邏輯 }; \u0026lt;/script\u0026gt; 插槽使用範例 \u0026lt;template\u0026gt; \u0026lt;Card :data=\u0026#34;userData\u0026#34; :loading=\u0026#34;loading\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;template #header=\u0026#34;{ title, subtitle }\u0026#34;\u0026gt; \u0026lt;h2\u0026gt;{{ title || \u0026#39;使用者資料\u0026#39; }}\u0026lt;/h2\u0026gt; \u0026lt;p v-if=\u0026#34;subtitle\u0026#34;\u0026gt;{{ subtitle }}\u0026lt;/p\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;template #default=\u0026#34;{ data, loading }\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;!loading\u0026#34;\u0026gt; \u0026lt;UserForm :user=\u0026#34;data\u0026#34; @update=\u0026#34;handleUserUpdate\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;LoadingSpinner v-else /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 動作插槽 --\u0026gt; \u0026lt;template #actions=\u0026#34;{ save, cancel, canSave }\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; :disabled=\u0026#34;!canSave\u0026#34; @click=\u0026#34;save\u0026#34; \u0026gt; 儲存 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; @click=\u0026#34;cancel\u0026#34; \u0026gt; 取消 \u0026lt;/BaseButton\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;/Card\u0026gt; \u0026lt;/template\u0026gt; 4.5 元件組合與複用 高階元件 (HOC) 模式 \u0026lt;!-- withLoading.vue - 高階元件 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;with-loading\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;loading-overlay\u0026#34;\u0026gt; \u0026lt;LoadingSpinner :size=\u0026#34;loadingSize\u0026#34; /\u0026gt; \u0026lt;p v-if=\u0026#34;loadingText\u0026#34;\u0026gt;{{ loadingText }}\u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div :class=\u0026#34;{ \u0026#39;is-loading\u0026#39;: loading }\u0026#34;\u0026gt; \u0026lt;slot :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { loading: boolean; loadingText?: string; loadingSize?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; } withDefaults(defineProps\u0026lt;Props\u0026gt;(), { loadingSize: \u0026#39;medium\u0026#39;, }); \u0026lt;/script\u0026gt; 組合式元件使用 \u0026lt;template\u0026gt; \u0026lt;WithLoading :loading=\u0026#34;isLoading\u0026#34; loading-text=\u0026#34;載入使用者資料中...\u0026#34;\u0026gt; \u0026lt;UserProfile :user=\u0026#34;userData\u0026#34; @edit=\u0026#34;handleEdit\u0026#34; @delete=\u0026#34;handleDelete\u0026#34; /\u0026gt; \u0026lt;/WithLoading\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import WithLoading from \u0026#39;@/components/hoc/WithLoading.vue\u0026#39;; import UserProfile from \u0026#39;@/components/UserProfile.vue\u0026#39;; const isLoading = ref(false); const userData = ref(null); const handleEdit = (user: User): void =\u0026gt; { // 編輯邏輯 }; const handleDelete = (user: User): void =\u0026gt; { // 刪除邏輯 }; \u0026lt;/script\u0026gt; 5. 樣式與 Tailwind CSS 規範 5.1 Tailwind CSS 設定 tailwind.config.js 範例 /** @type {import(\u0026#39;tailwindcss\u0026#39;).Config} */ export default { content: [ \u0026#39;./index.html\u0026#39;, \u0026#39;./src/**/*.{vue,js,ts,jsx,tsx}\u0026#39;, ], theme: { extend: { // 顏色系統 colors: { primary: { 50: \u0026#39;#eff6ff\u0026#39;, 100: \u0026#39;#dbeafe\u0026#39;, 200: \u0026#39;#bfdbfe\u0026#39;, 300: \u0026#39;#93c5fd\u0026#39;, 400: \u0026#39;#60a5fa\u0026#39;, 500: \u0026#39;#3b82f6\u0026#39;, // 主要品牌色 600: \u0026#39;#2563eb\u0026#39;, 700: \u0026#39;#1d4ed8\u0026#39;, 800: \u0026#39;#1e40af\u0026#39;, 900: \u0026#39;#1e3a8a\u0026#39;, 950: \u0026#39;#172554\u0026#39;, }, secondary: { 50: \u0026#39;#f8fafc\u0026#39;, 500: \u0026#39;#64748b\u0026#39;, 900: \u0026#39;#0f172a\u0026#39;, }, success: { 50: \u0026#39;#f0fdf4\u0026#39;, 500: \u0026#39;#22c55e\u0026#39;, 900: \u0026#39;#14532d\u0026#39;, }, warning: { 50: \u0026#39;#fffbeb\u0026#39;, 500: \u0026#39;#f59e0b\u0026#39;, 900: \u0026#39;#78350f\u0026#39;, }, danger: { 50: \u0026#39;#fef2f2\u0026#39;, 500: \u0026#39;#ef4444\u0026#39;, 900: \u0026#39;#7f1d1d\u0026#39;, }, }, // 字型設定 fontFamily: { sans: [ \u0026#39;Noto Sans TC\u0026#39;, \u0026#39;Microsoft JhengHei\u0026#39;, \u0026#39;PingFang TC\u0026#39;, \u0026#39;Helvetica Neue\u0026#39;, \u0026#39;Arial\u0026#39;, \u0026#39;sans-serif\u0026#39;, ], }, // 響應式斷點 screens: { \u0026#39;xs\u0026#39;: \u0026#39;475px\u0026#39;, \u0026#39;sm\u0026#39;: \u0026#39;640px\u0026#39;, \u0026#39;md\u0026#39;: \u0026#39;768px\u0026#39;, \u0026#39;lg\u0026#39;: \u0026#39;1024px\u0026#39;, \u0026#39;xl\u0026#39;: \u0026#39;1280px\u0026#39;, \u0026#39;2xl\u0026#39;: \u0026#39;1536px\u0026#39;, }, }, }, plugins: [ require(\u0026#39;@tailwindcss/forms\u0026#39;), require(\u0026#39;@tailwindcss/typography\u0026#39;), ], }; 5.2 RWD 響應式設計原則 Mobile-First 設計策略 \u0026lt;template\u0026gt; \u0026lt;!-- 響應式網格系統 --\u0026gt; \u0026lt;div class=\u0026#34;container mx-auto px-4\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-4\u0026#34;\u0026gt; \u0026lt;div v-for=\u0026#34;item in items\u0026#34; :key=\u0026#34;item.id\u0026#34; class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 響應式圖片 --\u0026gt; \u0026lt;img :src=\u0026#34;item.image\u0026#34; :alt=\u0026#34;item.title\u0026#34; class=\u0026#34;w-full h-32 sm:h-40 lg:h-48 object-cover\u0026#34; /\u0026gt; \u0026lt;!-- 響應式文字 --\u0026gt; \u0026lt;div class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;text-lg sm:text-xl lg:text-2xl font-semibold\u0026#34;\u0026gt; {{ item.title }} \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm sm:text-base text-gray-600\u0026#34;\u0026gt; {{ item.description }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 響應式導航 --\u0026gt; \u0026lt;nav class=\u0026#34;bg-white shadow\u0026#34;\u0026gt; \u0026lt;!-- 桌面版導航 --\u0026gt; \u0026lt;div class=\u0026#34;hidden lg:flex items-center space-x-8 px-6 py-4\u0026#34;\u0026gt; \u0026lt;a v-for=\u0026#34;link in navLinks\u0026#34; :key=\u0026#34;link.path\u0026#34; :href=\u0026#34;link.path\u0026#34;\u0026gt; {{ link.title }} \u0026lt;/a\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 行動版選單 --\u0026gt; \u0026lt;div class=\u0026#34;lg:hidden\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleMobileMenu\u0026#34; class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;MenuIcon class=\u0026#34;w-6 h-6\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/nav\u0026gt; \u0026lt;/template\u0026gt; 5.3 顏色與主題設計 CSS 變數主題系統 :root { /* 品牌色 */ --color-primary: #3b82f6; --color-secondary: #64748b; /* 語意化顏色 */ --color-success: #22c55e; --color-warning: #f59e0b; --color-danger: #ef4444; /* 背景色 */ --bg-primary: #ffffff; --bg-secondary: #f8fafc; /* 文字色 */ --text-primary: #111827; --text-secondary: #4b5563; } /* 暗色主題 */ [data-theme=\u0026#34;dark\u0026#34;] { --bg-primary: #111827; --bg-secondary: #1f2937; --text-primary: #f9fafb; --text-secondary: #d1d5db; } 5.4 共用樣式元件 基礎元件樣式 @layer components { /* 按鈕樣式 */ .btn { @apply inline-flex items-center px-4 py-2 text-sm font-medium rounded-md transition-colors focus:outline-none focus:ring-2; } .btn-primary { @apply btn bg-primary-500 text-white hover:bg-primary-600; } .btn-secondary { @apply btn bg-gray-200 text-gray-900 hover:bg-gray-300; } /* 表單樣式 */ .form-input { @apply w-full px-3 py-2 border border-gray-300 rounded-md focus:ring-1 focus:ring-primary-500 focus:border-primary-500; } /* 卡片樣式 */ .card { @apply bg-white rounded-lg shadow-md p-4; } } 總結 本前端開發指引提供了完整的開發規範，涵蓋了專案結構、命名規範、程式撰寫風格、元件開發和樣式設計等核心面向。請開發團隊嚴格遵循這些規範，以確保程式碼品質和專案的可維護性。\n","title":"前端開發指引"},{"content":"功能需求分析範本 Prompt 目標 指導 AI 進行系統化的功能需求分析，產生詳細的功能需求規格文檔。\n角色設定 你是一位資深系統分析師，具備豐富的功能需求分析經驗，能夠將業務需求轉換為詳細的功能規格。\n任務描述 請協助我完成 {專案名稱} 的功能需求分析工作。\n專案背景資訊 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 主要使用者角色: {填入使用者角色列表} 核心業務流程: {填入核心業務流程} 分析要求 請按照以下結構進行功能需求分析：\n1. 使用者故事分析 識別主要使用者角色 撰寫使用者故事 定義驗收標準 設定故事點數估算 2. 功能分解結構 系統功能模組劃分 子功能識別 功能相依關係分析 功能優先級排序 3. 介面需求定義 使用者介面需求 系統介面需求 外部整合介面 API 需求規格 4. 資料流程分析 輸入資料定義 處理邏輯描述 輸出結果規格 資料驗證規則 5. 效能需求 響應時間要求 吞吐量需求 並發使用者數 資源使用限制 6. 安全需求 身份驗證需求 授權控制要求 資料保護需求 稽核日誌需求 輸出格式 # {專案名稱} 功能需求規格文檔 ## 1. 使用者故事 ### 1.1 使用者角色定義 | 角色 | 描述 | 主要職責 | 技術能力 | |------|------|----------|----------| | [角色名稱] | [角色描述] | [主要職責] | [技術能力評估] | ### 1.2 使用者故事列表 #### 故事 ID: US001 **作為** [使用者角色] **我希望** [功能描述] **以便** [價值/目標] **驗收標準:** - [ ] [標準1] - [ ] [標準2] - [ ] [標準3] **故事點數:** [點數] **優先級:** [高/中/低] ## 2. 功能分解結構 ### 2.1 功能模組圖 系統名稱 ├── 模組A │ ├── 子功能A1 │ ├── 子功能A2 │ └── 子功能A3 ├── 模組B │ ├── 子功能B1 │ └── 子功能B2 └── 模組C ├── 子功能C1 └── 子功能C2\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%8A%9F%E8%83%BD%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E7%AF%84%E6%9C%AC/","summary":"功能需求分析範本 Prompt 目標 指導 AI 進行系統化的功能需求分析，產生詳細的功能需求規格文檔。\n角色設定 你是一位資深系統分析師，具備豐富的功能需求分析經驗，能夠將業務需求轉換為詳細的功能規格。\n任務描述 請協助我完成 {專案名稱} 的功能需求分析工作。\n專案背景資訊 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 主要使用者角色: {填入使用者角色列表} 核心業務流程: {填入核心業務流程} 分析要求 請按照以下結構進行功能需求分析：\n1. 使用者故事分析 識別主要使用者角色 撰寫使用者故事 定義驗收標準 設定故事點數估算 2. 功能分解結構 系統功能模組劃分 子功能識別 功能相依關係分析 功能優先級排序 3. 介面需求定義 使用者介面需求 系統介面需求 外部整合介面 API 需求規格 4. 資料流程分析 輸入資料定義 處理邏輯描述 輸出結果規格 資料驗證規則 5. 效能需求 響應時間要求 吞吐量需求 並發使用者數 資源使用限制 6. 安全需求 身份驗證需求 授權控制要求 資料保護需求 稽核日誌需求 輸出格式 # {專案名稱} 功能需求規格文檔 ## 1. 使用者故事 ### 1.1 使用者角色定義 | 角色 | 描述 | 主要職責 | 技術能力 | |------|------|----------|----------| | [角色名稱] | [角色描述] | [主要職責] | [技術能力評估] | ### 1.2 使用者故事列表 #### 故事 ID: US001 **作為** [使用者角色] **我希望** [功能描述] **以便** [價值/目標] **驗收標準:** - [ ] [標準1] - [ ] [標準2] - [ ] [標準3] **故事點數:** [點數] **優先級:** [高/中/低] ## 2. 功能分解結構 ### 2.1 功能模組圖 系統名稱 ├── 模組A │ ├── 子功能A1 │ ├── 子功能A2 │ └── 子功能A3 ├── 模組B │ ├── 子功能B1 │ └── 子功能B2 └── 模組C ├── 子功能C1 └── 子功能C2\n","title":"功能需求分析範本"},{"content":"角色: 你是一個資深的系統架師,也是AP 性能調較高手 環境: OS : AIX, ap server:IBM WebSphere Liberty, datbase: db2, 使用sprint boot 開發, 壓測使用Jmeter 任務: 壓測一小時, 同時50人, 95% request 必需在3秒內完成, 請列出壓測應注意那些參數設定與調校 chatGPT 回答 好的 ✅ 以下我會用「資深系統架構師 \u0026amp; AP 性能調校高手」的角度，幫你整理 JMeter 壓測設定、Liberty 調校、DB2 調校、AIX/系統層級參數 四大面向，確保你的一小時壓測（50人同時、95% request \u0026lt; 3 秒）能達標。\n1. 壓測工具 (JMeter) 層 測試場景設計 Ramp-Up 時間：避免一次 50 人瞬間打進系統，建議 30–60 秒平滑增加，觀察系統穩態。\nThink Time：模擬使用者真實行為，避免「機械式打爆」；可設定 0.5–2 秒隨機等待。\n持續時間模式：壓測 60 分鐘，避免只測瞬間峰值。\n監控數據：\n95% 响應時間 Throughput (TPS) Error Rate DB2 Connection Pool 狀況 JVM Heap/GC 次數 JMeter 參數建議 非 GUI 模式執行（jmeter -n -t test.jmx -l result.jtl）\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%A3%93%E6%B8%AC%E6%8C%87%E5%BC%95/","summary":"角色: 你是一個資深的系統架師,也是AP 性能調較高手 環境: OS : AIX, ap server:IBM WebSphere Liberty, datbase: db2, 使用sprint boot 開發, 壓測使用Jmeter 任務: 壓測一小時, 同時50人, 95% request 必需在3秒內完成, 請列出壓測應注意那些參數設定與調校 chatGPT 回答 好的 ✅ 以下我會用「資深系統架構師 \u0026amp; AP 性能調校高手」的角度，幫你整理 JMeter 壓測設定、Liberty 調校、DB2 調校、AIX/系統層級參數 四大面向，確保你的一小時壓測（50人同時、95% request \u0026lt; 3 秒）能達標。\n1. 壓測工具 (JMeter) 層 測試場景設計 Ramp-Up 時間：避免一次 50 人瞬間打進系統，建議 30–60 秒平滑增加，觀察系統穩態。\nThink Time：模擬使用者真實行為，避免「機械式打爆」；可設定 0.5–2 秒隨機等待。\n持續時間模式：壓測 60 分鐘，避免只測瞬間峰值。\n監控數據：\n95% 响應時間 Throughput (TPS) Error Rate DB2 Connection Pool 狀況 JVM Heap/GC 次數 JMeter 參數建議 非 GUI 模式執行（jmeter -n -t test.jmx -l result.jtl）\n","title":"壓測指引"},{"content":"Gemini 回答 好的，作為一個資深的系統架構師與 AP 性能調校專家，我會為您提供一份在這次壓力測試中，從頭到尾、由外到內需要關注的參數設定與調校檢查清單。\n我們的目標非常明確：在 50 個併發用戶（Concurrent Users）持續加壓一小時的條件下，確保 95% 的請求（95th Percentile）回應時間在 3 秒以內。\n這是一個系統性的工程，我們需要從壓力來源、作業系統、應用伺服器、一直到資料庫，逐層分析與調校。\n核心調校哲學 建立基準 (Establish Baseline): 在進行任何調校之前，先用預設設定跑一次縮短版的壓力測試（例如 10-15 分鐘）。這個數據是你的黃金標準，所有的後續調校都必須跟這個基準線做比較，才能判斷是改善還是惡化。 一次只改一個參數 (Change One Thing at a Time): 這是最重要的原則。如果你一次改了三個參數，效能變好了，你不會知道是哪個參數起了作用。反之，如果效能變差，你也不知道是誰的錯。 監控是你的眼睛 (Monitoring is Key): 如果沒有監控，調校就如同矇著眼睛開車。你必須能夠即時看到 CPU、記憶體、網路、I/O、GC、執行緒等關鍵指標的變化。 第一層：壓力來源 (JMeter) 確保壓力測試工具本身不是瓶頸。\n參數/項目 建議與說明 啟動模式 絕對要使用命令列模式 (CLI Mode) 進行正式壓測，不要使用 GUI 模式。GUI 模式會消耗大量客戶端資源，影響測試準確性。指令範例：jmeter -n -t your_test_plan.jmx -l results.jtl JVM Heap Size 修改 jmeter.bat 或 jmeter.sh，調整 JMeter 的 JVM 堆疊大小。如果請求或回應的資料量大，預設的 1G 可能不夠。建議至少設為 HEAP=\u0026quot;-Xms2g -Xmx2g\u0026quot; 或更高，避免 JMeter 本身 OutOfMemory。 監聽器 (Listeners) 在正式壓測時，禁用或刪除所有 GUI 上的監聽器，如 \u0026ldquo;View Results Tree\u0026rdquo;、\u0026ldquo;Summary Report\u0026rdquo; 等。它們非常消耗資源。測試結束後，再用 results.jtl 檔來產生報告。 思考時間 (Think Time) 在請求之間加入合理的思考時間 (e.g., Uniform Random Timer)，模擬真實用戶行為。完全沒有思考時間的壓測會對伺服器造成不切實際的瞬間衝擊，可能無法反映真實場景的效能瓶頸。 分散式壓測 如果單台 JMeter 機器無法產生足夠的壓力（CPU/網路滿載），應考慮使用主從式 (Master-Slave) 的分散式架構來發動壓測。 第二層：作業系統 (AIX) AIX 有其獨特的監控與調校工具，是穩定運行的基礎。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%A3%93%E6%B8%AC%E6%8C%87%E5%BC%952/","summary":"Gemini 回答 好的，作為一個資深的系統架構師與 AP 性能調校專家，我會為您提供一份在這次壓力測試中，從頭到尾、由外到內需要關注的參數設定與調校檢查清單。\n我們的目標非常明確：在 50 個併發用戶（Concurrent Users）持續加壓一小時的條件下，確保 95% 的請求（95th Percentile）回應時間在 3 秒以內。\n這是一個系統性的工程，我們需要從壓力來源、作業系統、應用伺服器、一直到資料庫，逐層分析與調校。\n核心調校哲學 建立基準 (Establish Baseline): 在進行任何調校之前，先用預設設定跑一次縮短版的壓力測試（例如 10-15 分鐘）。這個數據是你的黃金標準，所有的後續調校都必須跟這個基準線做比較，才能判斷是改善還是惡化。 一次只改一個參數 (Change One Thing at a Time): 這是最重要的原則。如果你一次改了三個參數，效能變好了，你不會知道是哪個參數起了作用。反之，如果效能變差，你也不知道是誰的錯。 監控是你的眼睛 (Monitoring is Key): 如果沒有監控，調校就如同矇著眼睛開車。你必須能夠即時看到 CPU、記憶體、網路、I/O、GC、執行緒等關鍵指標的變化。 第一層：壓力來源 (JMeter) 確保壓力測試工具本身不是瓶頸。\n參數/項目 建議與說明 啟動模式 絕對要使用命令列模式 (CLI Mode) 進行正式壓測，不要使用 GUI 模式。GUI 模式會消耗大量客戶端資源，影響測試準確性。指令範例：jmeter -n -t your_test_plan.jmx -l results.jtl JVM Heap Size 修改 jmeter.bat 或 jmeter.sh，調整 JMeter 的 JVM 堆疊大小。如果請求或回應的資料量大，預設的 1G 可能不夠。建議至少設為 HEAP=\u0026quot;-Xms2g -Xmx2g\u0026quot; 或更高，避免 JMeter 本身 OutOfMemory。 監聽器 (Listeners) 在正式壓測時，禁用或刪除所有 GUI 上的監聽器，如 \u0026ldquo;View Results Tree\u0026rdquo;、\u0026ldquo;Summary Report\u0026rdquo; 等。它們非常消耗資源。測試結束後，再用 results.jtl 檔來產生報告。 思考時間 (Think Time) 在請求之間加入合理的思考時間 (e.g., Uniform Random Timer)，模擬真實用戶行為。完全沒有思考時間的壓測會對伺服器造成不切實際的瞬間衝擊，可能無法反映真實場景的效能瓶頸。 分散式壓測 如果單台 JMeter 機器無法產生足夠的壓力（CPU/網路滿載），應考慮使用主從式 (Master-Slave) 的分散式架構來發動壓測。 第二層：作業系統 (AIX) AIX 有其獨特的監控與調校工具，是穩定運行的基礎。\n","title":"壓測指引2"},{"content":"安全程式碼指引 目錄 文件目的 通用安全開發原則 2.1 最小權限原則 2.2 輸入驗證 2.3 錯誤處理 2.4 加密使用原則 2.5 安全標頭設定 2.6 Session 與 Token 管理 程式語言安全指引 3.1 Java / Spring Boot 3.2 Python 3.3 JavaScript / TypeScript / Vue3 3.4 資料庫安全 OWASP Top 10 對應對策 4.1 A01:2021 – Broken Access Control (存取控制失效) 4.2 A02:2021 – Cryptographic Failures (加密失效) 4.3 A03:2021 – Injection (注入攻擊) 4.4 A04:2021 – Insecure Design (不安全設計) 4.5 A05:2021 – Security Misconfiguration (安全設定錯誤) 4.6 A06:2021 – Vulnerable Components (易受攻擊元件) 4.7 A07:2021 – Identification and Authentication Failures (識別與驗證失效) 4.8 A08:2021 – Software and Data Integrity Failures (軟體與資料完整性失效) 4.9 A09:2021 – Security Logging \u0026amp; Monitoring Failures (安全日誌與監控失效) 4.10 A10:2021 – Server-Side Request Forgery (SSRF) API 安全設計 5.1 RESTful API 安全 5.2 GraphQL 安全 5.3 API 版本控制與向後相容 5.4 API 速率限制與節流 容器化與雲端安全 6.1 Docker 安全 6.2 Kubernetes 安全 6.3 雲端服務安全 CI/CD 安全 7.1 代碼儲存庫安全 7.2 建構流程安全 7.3 部署安全 7.4 供應鏈安全 安全測試與驗證 8.1 靜態應用程式安全測試 (SAST) 8.2 動態應用程式安全測試 (DAST) 8.3 互動式應用程式安全測試 (IAST) 8.4 滲透測試 資料保護與隱私 9.1 個人資料保護 9.2 資料分類與標記 9.3 資料遮罩與匿名化 9.4 資料備份與復原 事件回應與復原 10.1 安全事件識別 10.2 事件回應流程 10.3 取證與證據保全 10.4 災難復原計畫 日常開發檢查清單 (Checklist) 11.1 每日開發檢查項目 11.2 Pull Request 檢查項目 11.3 部署前檢查項目 常見錯誤與反例 12.1 密碼處理錯誤 12.2 SQL 查詢錯誤 12.3 檔案上傳錯誤 12.4 前端 XSS 錯誤 12.5 權限控制錯誤 12.6 API 設計錯誤 12.7 配置錯誤 合規性與法規要求 13.1 GDPR 合規 13.2 個資法合規 13.3 PCI DSS 合規 13.4 SOX 合規 延伸資源 14.1 官方安全指引 14.2 程式語言特定資源 14.3 安全工具 14.4 學習資源 14.5 公司內部資源 1. 文件目的 安全程式碼的撰寫是每位開發者的基本職責。良好的安全設計不僅能保護公司與用戶資料，避免資安事件造成商譽損失與法律責任，也有助於符合法規（如 GDPR、個資法）及客戶合約要求。安全程式碼能降低維運成本、減少漏洞修補時間，讓業務更穩健發展。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%AE%89%E5%85%A8%E7%A8%8B%E5%BC%8F%E7%A2%BC%E6%8C%87%E5%BC%95/","summary":"安全程式碼指引 目錄 文件目的 通用安全開發原則 2.1 最小權限原則 2.2 輸入驗證 2.3 錯誤處理 2.4 加密使用原則 2.5 安全標頭設定 2.6 Session 與 Token 管理 程式語言安全指引 3.1 Java / Spring Boot 3.2 Python 3.3 JavaScript / TypeScript / Vue3 3.4 資料庫安全 OWASP Top 10 對應對策 4.1 A01:2021 – Broken Access Control (存取控制失效) 4.2 A02:2021 – Cryptographic Failures (加密失效) 4.3 A03:2021 – Injection (注入攻擊) 4.4 A04:2021 – Insecure Design (不安全設計) 4.5 A05:2021 – Security Misconfiguration (安全設定錯誤) 4.6 A06:2021 – Vulnerable Components (易受攻擊元件) 4.7 A07:2021 – Identification and Authentication Failures (識別與驗證失效) 4.8 A08:2021 – Software and Data Integrity Failures (軟體與資料完整性失效) 4.9 A09:2021 – Security Logging \u0026amp; Monitoring Failures (安全日誌與監控失效) 4.10 A10:2021 – Server-Side Request Forgery (SSRF) API 安全設計 5.1 RESTful API 安全 5.2 GraphQL 安全 5.3 API 版本控制與向後相容 5.4 API 速率限制與節流 容器化與雲端安全 6.1 Docker 安全 6.2 Kubernetes 安全 6.3 雲端服務安全 CI/CD 安全 7.1 代碼儲存庫安全 7.2 建構流程安全 7.3 部署安全 7.4 供應鏈安全 安全測試與驗證 8.1 靜態應用程式安全測試 (SAST) 8.2 動態應用程式安全測試 (DAST) 8.3 互動式應用程式安全測試 (IAST) 8.4 滲透測試 資料保護與隱私 9.1 個人資料保護 9.2 資料分類與標記 9.3 資料遮罩與匿名化 9.4 資料備份與復原 事件回應與復原 10.1 安全事件識別 10.2 事件回應流程 10.3 取證與證據保全 10.4 災難復原計畫 日常開發檢查清單 (Checklist) 11.1 每日開發檢查項目 11.2 Pull Request 檢查項目 11.3 部署前檢查項目 常見錯誤與反例 12.1 密碼處理錯誤 12.2 SQL 查詢錯誤 12.3 檔案上傳錯誤 12.4 前端 XSS 錯誤 12.5 權限控制錯誤 12.6 API 設計錯誤 12.7 配置錯誤 合規性與法規要求 13.1 GDPR 合規 13.2 個資法合規 13.3 PCI DSS 合規 13.4 SOX 合規 延伸資源 14.1 官方安全指引 14.2 程式語言特定資源 14.3 安全工具 14.4 學習資源 14.5 公司內部資源 1. 文件目的 安全程式碼的撰寫是每位開發者的基本職責。良好的安全設計不僅能保護公司與用戶資料，避免資安事件造成商譽損失與法律責任，也有助於符合法規（如 GDPR、個資法）及客戶合約要求。安全程式碼能降低維運成本、減少漏洞修補時間，讓業務更穩健發展。\n","title":"安全程式碼指引"},{"content":"安全需求識別範本 Prompt 目標 指導 AI 進行全面的安全需求分析，建立符合 SSDLC 標準的安全需求規格。\n角色設定 你是一位資深資訊安全顧問，具備豐富的安全需求分析和威脅建模經驗，熟悉各種安全框架和標準。\n任務描述 請協助我完成 {專案名稱} 的安全需求識別和分析工作。\n專案安全背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、API服務、移動應用} 資料敏感度: {填入資料敏感度等級，如：公開、內部、機密、極機密} 合規要求: {填入相關法規或標準，如：GDPR、HIPAA、PCI-DSS} 威脅等級: {填入威脅等級評估，如：低、中、高、極高} 安全分析框架 請按照以下結構進行安全需求分析：\n1. 威脅建模分析 資產識別與分類 威脅行為者分析 攻擊向量識別 威脅情境建模 2. 風險評估 威脅可能性評估 影響程度分析 風險等級計算 風險處理策略 3. 安全控制需求 預防性控制 偵測性控制 回應性控制 復原性控制 4. 合規性需求 法規要求分析 標準符合性檢查 稽核要求定義 報告需求規劃 5. 資料保護需求 資料分類要求 資料生命週期保護 隱私保護需求 資料銷毀要求 6. 基礎設施安全 網路安全要求 主機安全要求 應用程式安全 雲端安全要求 輸出格式 # {專案名稱} 安全需求規格文檔 ## 1. 威脅建模分析 ### 1.1 資產識別與分類 | 資產類型 | 資產名稱 | 機密性 | 完整性 | 可用性 | 業務影響 | |----------|----------|--------|--------|--------|----------| | 資料資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 系統資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 人員資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | ### 1.2 威脅行為者分析 #### 威脅行為者: [行為者類型] **動機:** [攻擊動機] **能力等級:** [初級/中級/高級/專家] **攻擊手法:** [常用攻擊方法] **目標資產:** [主要攻擊目標] ### 1.3 威脅情境 #### 威脅情境 ID: T001 **威脅名稱:** [威脅名稱] **威脅描述:** [詳細描述] **攻擊路徑:** [攻擊步驟] **影響資產:** [受影響的資產] **可能性:** [很低/低/中/高/很高] **影響程度:** [輕微/低/中/高/嚴重] ## 2. 風險評估 ### 2.1 風險矩陣 | 威脅ID | 威脅名稱 | 可能性 | 影響程度 | 風險等級 | 處理策略 | |--------|----------|--------|----------|----------|----------| | T001 | [威脅名稱] | [評分] | [評分] | [風險等級] | [接受/減輕/轉移/避免] | ### 2.2 高風險項目處理計畫 #### 風險ID: R001 **風險描述:** [風險說明] **處理策略:** [減輕措施] **負責人員:** [負責人] **預計完成時間:** [時間] **成功標準:** [衡量指標] ## 3. 安全控制需求 ### 3.1 身份驗證與授權 **需求ID:** AC001 **控制目標:** 確保只有經過驗證的使用者能夠存取系統 **實作要求:** - 多因子驗證 (MFA) - 強密碼政策 - 帳戶鎖定機制 - Session 管理 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.2 資料加密 **需求ID:** CR001 **控制目標:** 保護敏感資料的機密性 **實作要求:** - 傳輸中加密 (TLS 1.3) - 靜態資料加密 (AES-256) - 金鑰管理機制 - 加密強度要求 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.3 安全監控 **需求ID:** MN001 **控制目標:** 即時偵測安全事件 **實作要求:** - 安全事件記錄 - 異常行為偵測 - 即時告警機制 - 事件關聯分析 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ## 4. 合規性需求 ### 4.1 法規要求對照表 | 法規名稱 | 條款編號 | 要求內容 | 對應控制措施 | 實作狀態 | |----------|----------|----------|--------------|----------| | [法規名稱] | [條款] | [要求說明] | [控制措施] | [待實作/已實作] | ### 4.2 稽核要求 **稽核頻率:** [年度/季度/月度] **稽核範圍:** [稽核項目清單] **稽核標準:** [依據的標準或框架] **報告要求:** [報告格式和提交時間] ## 5. 資料保護需求 ### 5.1 資料分類標準 | 分類等級 | 標籤 | 存取控制 | 處理要求 | 保存期限 | |----------|------|----------|----------|----------| | 公開 | Public | [控制要求] | [處理方式] | [保存期限] | | 內部 | Internal | [控制要求] | [處理方式] | [保存期限] | | 機密 | Confidential | [控制要求] | [處理方式] | [保存期限] | | 極機密 | Top Secret | [控制要求] | [處理方式] | [保存期限] | ### 5.2 隱私保護要求 **個人資料處理原則:** - 合法性和透明度 - 目的限制原則 - 資料最小化原則 - 準確性維護 - 保存期限限制 - 完整性和機密性 ## 6. 基礎設施安全需求 ### 6.1 網路安全 - 網路分段和隔離 - 防火牆和入侵防護 - DDoS 防護機制 - 網路流量監控 ### 6.2 應用程式安全 - 安全編碼實務 - 輸入驗證機制 - 輸出編碼處理 - 錯誤處理機制 ### 6.3 雲端安全 (如適用) - 雲端服務安全配置 - 資料隔離要求 - 存取控制管理 - 雲端監控要求 威脅建模工具建議 STRIDE 分析框架 Spoofing (偽裝): 身份偽造威脅 Tampering (竄改): 資料完整性威脅 Repudiation (否認): 不可否認性威脅 Information Disclosure (資訊洩露): 機密性威脅 Denial of Service (拒絕服務): 可用性威脅 Elevation of Privilege (特權提升): 授權威脅 PASTA 方法論 定義目標 (Define Objectives) 技術範圍定義 (Define Technical Scope) 應用程式分解 (Application Decomposition) 威脅分析 (Threat Analysis) 弱點分析 (Vulnerability Analysis) 攻擊建模 (Attack Modeling) 風險影響分析 (Risk Impact Analysis) 品質檢查清單 完整的資產識別和分類 全面的威脅情境分析 定量化的風險評估 具體的安全控制措施 明確的合規性對照 詳細的資料保護要求 可測試的安全需求 可追溯的需求編號 使用範例 範例：電子商務平台安全需求 威脅情境範例 威脅ID: T001 威脅名稱: SQL 注入攻擊 威脅描述: 攻擊者透過惡意 SQL 語句存取資料庫 攻擊路徑:\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%AE%89%E5%85%A8%E9%9C%80%E6%B1%82%E8%AD%98%E5%88%A5%E7%AF%84%E6%9C%AC/","summary":"安全需求識別範本 Prompt 目標 指導 AI 進行全面的安全需求分析，建立符合 SSDLC 標準的安全需求規格。\n角色設定 你是一位資深資訊安全顧問，具備豐富的安全需求分析和威脅建模經驗，熟悉各種安全框架和標準。\n任務描述 請協助我完成 {專案名稱} 的安全需求識別和分析工作。\n專案安全背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、API服務、移動應用} 資料敏感度: {填入資料敏感度等級，如：公開、內部、機密、極機密} 合規要求: {填入相關法規或標準，如：GDPR、HIPAA、PCI-DSS} 威脅等級: {填入威脅等級評估，如：低、中、高、極高} 安全分析框架 請按照以下結構進行安全需求分析：\n1. 威脅建模分析 資產識別與分類 威脅行為者分析 攻擊向量識別 威脅情境建模 2. 風險評估 威脅可能性評估 影響程度分析 風險等級計算 風險處理策略 3. 安全控制需求 預防性控制 偵測性控制 回應性控制 復原性控制 4. 合規性需求 法規要求分析 標準符合性檢查 稽核要求定義 報告需求規劃 5. 資料保護需求 資料分類要求 資料生命週期保護 隱私保護需求 資料銷毀要求 6. 基礎設施安全 網路安全要求 主機安全要求 應用程式安全 雲端安全要求 輸出格式 # {專案名稱} 安全需求規格文檔 ## 1. 威脅建模分析 ### 1.1 資產識別與分類 | 資產類型 | 資產名稱 | 機密性 | 完整性 | 可用性 | 業務影響 | |----------|----------|--------|--------|--------|----------| | 資料資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 系統資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 人員資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | ### 1.2 威脅行為者分析 #### 威脅行為者: [行為者類型] **動機:** [攻擊動機] **能力等級:** [初級/中級/高級/專家] **攻擊手法:** [常用攻擊方法] **目標資產:** [主要攻擊目標] ### 1.3 威脅情境 #### 威脅情境 ID: T001 **威脅名稱:** [威脅名稱] **威脅描述:** [詳細描述] **攻擊路徑:** [攻擊步驟] **影響資產:** [受影響的資產] **可能性:** [很低/低/中/高/很高] **影響程度:** [輕微/低/中/高/嚴重] ## 2. 風險評估 ### 2.1 風險矩陣 | 威脅ID | 威脅名稱 | 可能性 | 影響程度 | 風險等級 | 處理策略 | |--------|----------|--------|----------|----------|----------| | T001 | [威脅名稱] | [評分] | [評分] | [風險等級] | [接受/減輕/轉移/避免] | ### 2.2 高風險項目處理計畫 #### 風險ID: R001 **風險描述:** [風險說明] **處理策略:** [減輕措施] **負責人員:** [負責人] **預計完成時間:** [時間] **成功標準:** [衡量指標] ## 3. 安全控制需求 ### 3.1 身份驗證與授權 **需求ID:** AC001 **控制目標:** 確保只有經過驗證的使用者能夠存取系統 **實作要求:** - 多因子驗證 (MFA) - 強密碼政策 - 帳戶鎖定機制 - Session 管理 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.2 資料加密 **需求ID:** CR001 **控制目標:** 保護敏感資料的機密性 **實作要求:** - 傳輸中加密 (TLS 1.3) - 靜態資料加密 (AES-256) - 金鑰管理機制 - 加密強度要求 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.3 安全監控 **需求ID:** MN001 **控制目標:** 即時偵測安全事件 **實作要求:** - 安全事件記錄 - 異常行為偵測 - 即時告警機制 - 事件關聯分析 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ## 4. 合規性需求 ### 4.1 法規要求對照表 | 法規名稱 | 條款編號 | 要求內容 | 對應控制措施 | 實作狀態 | |----------|----------|----------|--------------|----------| | [法規名稱] | [條款] | [要求說明] | [控制措施] | [待實作/已實作] | ### 4.2 稽核要求 **稽核頻率:** [年度/季度/月度] **稽核範圍:** [稽核項目清單] **稽核標準:** [依據的標準或框架] **報告要求:** [報告格式和提交時間] ## 5. 資料保護需求 ### 5.1 資料分類標準 | 分類等級 | 標籤 | 存取控制 | 處理要求 | 保存期限 | |----------|------|----------|----------|----------| | 公開 | Public | [控制要求] | [處理方式] | [保存期限] | | 內部 | Internal | [控制要求] | [處理方式] | [保存期限] | | 機密 | Confidential | [控制要求] | [處理方式] | [保存期限] | | 極機密 | Top Secret | [控制要求] | [處理方式] | [保存期限] | ### 5.2 隱私保護要求 **個人資料處理原則:** - 合法性和透明度 - 目的限制原則 - 資料最小化原則 - 準確性維護 - 保存期限限制 - 完整性和機密性 ## 6. 基礎設施安全需求 ### 6.1 網路安全 - 網路分段和隔離 - 防火牆和入侵防護 - DDoS 防護機制 - 網路流量監控 ### 6.2 應用程式安全 - 安全編碼實務 - 輸入驗證機制 - 輸出編碼處理 - 錯誤處理機制 ### 6.3 雲端安全 (如適用) - 雲端服務安全配置 - 資料隔離要求 - 存取控制管理 - 雲端監控要求 威脅建模工具建議 STRIDE 分析框架 Spoofing (偽裝): 身份偽造威脅 Tampering (竄改): 資料完整性威脅 Repudiation (否認): 不可否認性威脅 Information Disclosure (資訊洩露): 機密性威脅 Denial of Service (拒絕服務): 可用性威脅 Elevation of Privilege (特權提升): 授權威脅 PASTA 方法論 定義目標 (Define Objectives) 技術範圍定義 (Define Technical Scope) 應用程式分解 (Application Decomposition) 威脅分析 (Threat Analysis) 弱點分析 (Vulnerability Analysis) 攻擊建模 (Attack Modeling) 風險影響分析 (Risk Impact Analysis) 品質檢查清單 完整的資產識別和分類 全面的威脅情境分析 定量化的風險評估 具體的安全控制措施 明確的合規性對照 詳細的資料保護要求 可測試的安全需求 可追溯的需求編號 使用範例 範例：電子商務平台安全需求 威脅情境範例 威脅ID: T001 威脅名稱: SQL 注入攻擊 威脅描述: 攻擊者透過惡意 SQL 語句存取資料庫 攻擊路徑:\n","title":"安全需求識別範本"},{"content":"客戶需求訪談與分析技巧指引 文件資訊 文件版本：1.0 建立日期：2025年8月13日 目標讀者：新進專案經理（0-2年經驗） 適用範圍：金融、IT與大型系統整合專案 目錄 前言 前置準備 訪談進行技巧 訪談紀錄與整理 需求分析方法 需求驗證與確認 跨文化與遠端訪談技巧 數位化工具應用 品質控制與持續改善 常見錯誤與避免方法 實際案例分析 附錄 參考資料 1. 前言 1.1 指引目的 本指引旨在協助新進專案經理掌握客戶需求訪談與分析的核心技巧，提升專案成功率並降低需求變更風險。\n1.2 需求訪談的重要性 專案成功關鍵：85% 的專案失敗源於需求理解不足或溝通不良 成本控制：前期準確的需求分析可降低後期變更成本達 10-100 倍 客戶滿意度：清楚的需求理解是客戶滿意度的基礎 1.3 適用情境 新專案啟動階段的需求收集 現有系統功能擴充或改版 系統整合專案的介面需求確認 使用者體驗改善專案 2. 前置準備 2.1 訪談前資料蒐集 2.1.1 必要資料清單 組織架構資料\n客戶組織圖與部門職掌 關鍵決策者與影響者清單 內部溝通流程與層級關係 業務背景資料\n客戶業務模式與營運流程 現有系統架構與使用狀況 過去類似專案的經驗與學習 技術環境資料\n現有 IT 基礎架構 技術標準與限制條件 資安與合規要求 實務案例：在銀行核心系統專案中，PM 提前了解該行的組織架構，發現風險管理部門在系統需求上有關鍵決策權，因此將其納入主要訪談對象，避免後期需求變更。\n2.1.2 資料蒐集管道 正式管道\n客戶提供的 RFP（Request for Proposal）文件 組織年報與公開資訊 官方網站與產品說明文件 非正式管道\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%AE%A2%E6%88%B6%E9%9C%80%E6%B1%82%E8%A8%AA%E8%AB%87%E8%88%87%E5%88%86%E6%9E%90%E6%8A%80%E5%B7%A7/","summary":"客戶需求訪談與分析技巧指引 文件資訊 文件版本：1.0 建立日期：2025年8月13日 目標讀者：新進專案經理（0-2年經驗） 適用範圍：金融、IT與大型系統整合專案 目錄 前言 前置準備 訪談進行技巧 訪談紀錄與整理 需求分析方法 需求驗證與確認 跨文化與遠端訪談技巧 數位化工具應用 品質控制與持續改善 常見錯誤與避免方法 實際案例分析 附錄 參考資料 1. 前言 1.1 指引目的 本指引旨在協助新進專案經理掌握客戶需求訪談與分析的核心技巧，提升專案成功率並降低需求變更風險。\n1.2 需求訪談的重要性 專案成功關鍵：85% 的專案失敗源於需求理解不足或溝通不良 成本控制：前期準確的需求分析可降低後期變更成本達 10-100 倍 客戶滿意度：清楚的需求理解是客戶滿意度的基礎 1.3 適用情境 新專案啟動階段的需求收集 現有系統功能擴充或改版 系統整合專案的介面需求確認 使用者體驗改善專案 2. 前置準備 2.1 訪談前資料蒐集 2.1.1 必要資料清單 組織架構資料\n客戶組織圖與部門職掌 關鍵決策者與影響者清單 內部溝通流程與層級關係 業務背景資料\n客戶業務模式與營運流程 現有系統架構與使用狀況 過去類似專案的經驗與學習 技術環境資料\n現有 IT 基礎架構 技術標準與限制條件 資安與合規要求 實務案例：在銀行核心系統專案中，PM 提前了解該行的組織架構，發現風險管理部門在系統需求上有關鍵決策權，因此將其納入主要訪談對象，避免後期需求變更。\n2.1.2 資料蒐集管道 正式管道\n客戶提供的 RFP（Request for Proposal）文件 組織年報與公開資訊 官方網站與產品說明文件 非正式管道\n","title":"客戶需求訪談與分析技巧"},{"content":"專案 Review 指引 文件版本： 1.1\n更新日期： 2025年8月29日\n適用對象： 部門主管\n文件性質： 專案管理指引\n📑 目錄 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 1.2 主管在專案治理中的角色與責任 策略指導者 (Strategic Advisor) 資源協調者 (Resource Coordinator) 風險監督者 (Risk Supervisor) 績效推動者 (Performance Driver) 💡 實務案例 2. 專案 Review 的流程與步驟 2.1 準備階段 (Preparation Phase) Step 1: 收集專案資訊 Step 2: 建立檢視清單 Step 3: 預備會議安排 2.2 審查階段 (Review Phase) 2.2.1 進度審查 (Schedule Review) 2.2.2 成本審查 (Cost Review) 2.2.3 品質審查 (Quality Review) 2.2.4 風險與議題審查 (Risk \u0026amp; Issue Review) 2.2.5 資源與團隊審查 (Resource \u0026amp; Team Review) 2.3 討論與回饋階段 (Discussion \u0026amp; Feedback Phase) 2.3.1 主持有效會議的技巧 2.3.2 提出建設性建議的方法 2.4 後續跟進 (Follow-up Phase) 2.4.1 改進措施追蹤 2.4.2 Review 結果記錄 3. 專案 Review 的重點檢核項目 3.1 專案目標與商業價值對齊程度 3.2 進度與里程碑狀況 3.3 成本與預算控管 3.4 風險與議題管理 3.5 品質保證與測試狀況 3.6 資源配置與團隊狀態 3.7 利害關係人溝通與滿意度 4. 最佳實務與常見錯誤 4.1 主管應如何提供支持而不是微觀管理 4.2 常見的 Review 誤區 誤區一：只看數字，忽略背後原因 誤區二：不關注風險，只處理已發生的問題 誤區三：不給具體行動建議，只提出批評 4.3 有效的提問與引導技巧 5. 範例與工具 5.1 專案 Review 問題清單 快速診斷問題清單 (10分鐘版本) 深度檢視問題清單 (完整版本) 5.2 Review 報告範例格式 5.3 可用的專案管理工具 進度追蹤工具 儀表板工具 溝通協作工具 工具選擇建議 5.4 數位化 Review 流程與自動化 自動化報告生成 即時監控儀表板 AI 輔助分析 5.5 不同專案類型的 Review 調整 敏捷專案 Review 指引 傳統瀑布式專案 Review 混合型專案管理方法 6. 進階主題 6.1 跨文化與遠距團隊的 Review 管理 6.2 大型複雜專案的多層級 Review 6.3 專案組合管理中的 Review 協調 6.4 危機情況下的緊急 Review 程序 7. 結語 7.1 透過持續 Review 建立部門專案治理文化 7.2 將 Review 作為溝通與提升團隊的機會 7.3 最終建議 7.4 持續改善與學習機制 附錄：專案 Review 檢查清單 (Checklist) A. Review 會議前準備清單 B. Review 會議進行清單 C. Review 會議後跟進清單 D. 專案健康度快速檢查清單 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 專案 Review 是確保專案成功的關鍵管控機制，對新進部門主管而言具有以下重要性：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88review%E6%8C%87%E5%BC%95/","summary":"專案 Review 指引 文件版本： 1.1\n更新日期： 2025年8月29日\n適用對象： 部門主管\n文件性質： 專案管理指引\n📑 目錄 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 1.2 主管在專案治理中的角色與責任 策略指導者 (Strategic Advisor) 資源協調者 (Resource Coordinator) 風險監督者 (Risk Supervisor) 績效推動者 (Performance Driver) 💡 實務案例 2. 專案 Review 的流程與步驟 2.1 準備階段 (Preparation Phase) Step 1: 收集專案資訊 Step 2: 建立檢視清單 Step 3: 預備會議安排 2.2 審查階段 (Review Phase) 2.2.1 進度審查 (Schedule Review) 2.2.2 成本審查 (Cost Review) 2.2.3 品質審查 (Quality Review) 2.2.4 風險與議題審查 (Risk \u0026amp; Issue Review) 2.2.5 資源與團隊審查 (Resource \u0026amp; Team Review) 2.3 討論與回饋階段 (Discussion \u0026amp; Feedback Phase) 2.3.1 主持有效會議的技巧 2.3.2 提出建設性建議的方法 2.4 後續跟進 (Follow-up Phase) 2.4.1 改進措施追蹤 2.4.2 Review 結果記錄 3. 專案 Review 的重點檢核項目 3.1 專案目標與商業價值對齊程度 3.2 進度與里程碑狀況 3.3 成本與預算控管 3.4 風險與議題管理 3.5 品質保證與測試狀況 3.6 資源配置與團隊狀態 3.7 利害關係人溝通與滿意度 4. 最佳實務與常見錯誤 4.1 主管應如何提供支持而不是微觀管理 4.2 常見的 Review 誤區 誤區一：只看數字，忽略背後原因 誤區二：不關注風險，只處理已發生的問題 誤區三：不給具體行動建議，只提出批評 4.3 有效的提問與引導技巧 5. 範例與工具 5.1 專案 Review 問題清單 快速診斷問題清單 (10分鐘版本) 深度檢視問題清單 (完整版本) 5.2 Review 報告範例格式 5.3 可用的專案管理工具 進度追蹤工具 儀表板工具 溝通協作工具 工具選擇建議 5.4 數位化 Review 流程與自動化 自動化報告生成 即時監控儀表板 AI 輔助分析 5.5 不同專案類型的 Review 調整 敏捷專案 Review 指引 傳統瀑布式專案 Review 混合型專案管理方法 6. 進階主題 6.1 跨文化與遠距團隊的 Review 管理 6.2 大型複雜專案的多層級 Review 6.3 專案組合管理中的 Review 協調 6.4 危機情況下的緊急 Review 程序 7. 結語 7.1 透過持續 Review 建立部門專案治理文化 7.2 將 Review 作為溝通與提升團隊的機會 7.3 最終建議 7.4 持續改善與學習機制 附錄：專案 Review 檢查清單 (Checklist) A. Review 會議前準備清單 B. Review 會議進行清單 C. Review 會議後跟進清單 D. 專案健康度快速檢查清單 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 專案 Review 是確保專案成功的關鍵管控機制，對新進部門主管而言具有以下重要性：\n","title":"專案review指引"},{"content":"專案品質管理指引 目錄 品質管理的重要性與目標\n1.1 品質管理的定義 1.2 品質管理的重要性 1.3 品質管理目標 1.4 實務案例 品質規劃流程\n2.1 品質規劃概述 2.2 品質規劃輸入 2.3 品質規劃工具與技術 2.4 品質規劃輸出 2.5 實務案例 品質保證流程\n3.1 品質保證概述 3.2 品質保證活動 3.3 品質保證工具 3.4 品質保證輸出 3.5 實務案例 品質控制流程\n4.1 品質控制概述 4.2 品質控制活動 4.3 品質控制工具與技術 4.4 品質控制輸出 4.5 實務案例 常用品質工具與方法\n5.1 七大品質工具 5.2 軟體品質分析工具 5.3 測試工具與框架 5.4 品質量測工具 5.5 工具選擇指南 專案品質指標範例\n6.1 品質指標設計原則 6.2 開發階段品質指標 6.3 測試階段品質指標 6.4 維運階段品質指標 6.5 指標監控與報告 品質稽核流程\n7.1 品質稽核概述 7.2 稽核類型與方法 7.3 品質稽核準備 7.4 品質稽核執行 7.5 稽核發現與報告 7.6 矯正行動與追蹤 7.7 實務案例 銀行系統專案品質管控實務案例\n8.1 案例背景：數位金融平台建置專案 8.2 品質管理策略 8.3 品質活動實施 8.4 品質挑戰與解決方案 8.5 成果與經驗分享 常見問題與解法\n9.1 品質規劃階段常見問題 9.2 品質保證階段常見問題 9.3 品質控制階段常見問題 9.4 組織與文化問題 9.5 工具與技術問題 附錄：檢核清單範例\n10.1 品質規劃檢核清單 10.2 程式碼審查檢核清單 10.3 測試執行檢核清單 10.4 上線前檢核清單 參考資料與延伸閱讀\n11.1 專案管理相關資源 11.2 品質管理相關資源 11.3 軟體工程相關資源 11.4 測試相關資源 11.5 工具與技術資源 11.6 線上社群與討論區 11.7 實務案例研究 11.8 持續學習建議 品質管理成熟度評估\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E5%93%81%E8%B3%AA%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案品質管理指引 目錄 品質管理的重要性與目標\n1.1 品質管理的定義 1.2 品質管理的重要性 1.3 品質管理目標 1.4 實務案例 品質規劃流程\n2.1 品質規劃概述 2.2 品質規劃輸入 2.3 品質規劃工具與技術 2.4 品質規劃輸出 2.5 實務案例 品質保證流程\n3.1 品質保證概述 3.2 品質保證活動 3.3 品質保證工具 3.4 品質保證輸出 3.5 實務案例 品質控制流程\n4.1 品質控制概述 4.2 品質控制活動 4.3 品質控制工具與技術 4.4 品質控制輸出 4.5 實務案例 常用品質工具與方法\n5.1 七大品質工具 5.2 軟體品質分析工具 5.3 測試工具與框架 5.4 品質量測工具 5.5 工具選擇指南 專案品質指標範例\n6.1 品質指標設計原則 6.2 開發階段品質指標 6.3 測試階段品質指標 6.4 維運階段品質指標 6.5 指標監控與報告 品質稽核流程\n7.1 品質稽核概述 7.2 稽核類型與方法 7.3 品質稽核準備 7.4 品質稽核執行 7.5 稽核發現與報告 7.6 矯正行動與追蹤 7.7 實務案例 銀行系統專案品質管控實務案例\n8.1 案例背景：數位金融平台建置專案 8.2 品質管理策略 8.3 品質活動實施 8.4 品質挑戰與解決方案 8.5 成果與經驗分享 常見問題與解法\n9.1 品質規劃階段常見問題 9.2 品質保證階段常見問題 9.3 品質控制階段常見問題 9.4 組織與文化問題 9.5 工具與技術問題 附錄：檢核清單範例\n10.1 品質規劃檢核清單 10.2 程式碼審查檢核清單 10.3 測試執行檢核清單 10.4 上線前檢核清單 參考資料與延伸閱讀\n11.1 專案管理相關資源 11.2 品質管理相關資源 11.3 軟體工程相關資源 11.4 測試相關資源 11.5 工具與技術資源 11.6 線上社群與討論區 11.7 實務案例研究 11.8 持續學習建議 品質管理成熟度評估\n","title":"專案品質管理指引"},{"content":"專案啟動流程指引 文件資訊 版本：1.1 建立日期：2025年8月13日 最後更新：2025年8月29日 適用對象：新進專案經理（0-2年經驗） 專案類型：系統開發、基礎架構升級、法遵專案 目錄 專案啟動流程概述\n1.1 定義與目標 1.2 專案啟動的重要性 1.3 專案啟動五大階段 專案啟動流程詳細說明\n2.1 階段一：專案立案 2.2 階段二：需求初步確認 2.3 階段三：組建核心團隊 2.4 階段四：專案規劃啟動 2.5 階段五：正式啟動會議 專案啟動流程總覽表\n3.1 流程階段彙整表 3.2 關鍵決策點與升級機制 專案啟動文件範本結構\n4.1 專案授權書（Project Charter）範本 4.2 專案啟動會議議程範本 4.3 專案啟動會議議程範例 成功專案啟動的五大關鍵建議\n專案啟動常見問題與解決方案\n專案啟動成功指標與評估標準\n數位化工具與技術應用\n法規遵循與資安要求\n參考資料與延伸學習\n附錄：版本更新記錄\n1. 專案啟動流程概述 1.1 定義與目標 專案啟動階段是專案生命週期的第一個階段，目標是正式授權專案開始並為專案成功奠定基礎。這個階段將確定專案範圍、目標、利害關係人，並獲得必要的資源承諾。\n1.2 專案啟動的重要性 建立共識：確保所有利害關係人對專案目標有一致理解 設定期望：明確定義專案成功標準與交付物 風險預防：及早識別潛在風險與限制條件 資源確保：獲得必要的人力、時間與預算承諾 1.3 專案啟動五大階段 graph LR A[專案立案] --\u0026gt; B[需求初步確認] B --\u0026gt; C[組建核心團隊] C --\u0026gt; D[專案規劃啟動] D --\u0026gt; E[正式啟動會議] 2. 專案啟動流程詳細說明 2.1 階段一：專案立案 工作內容 撰寫或審核專案提案書 進行初步可行性評估 確認專案商業價值與對齊策略 申請專案預算與資源 負責角色 主要負責：專案發起人（Project Sponsor） 協助角色：業務單位主管、IT部門主管 支援角色：財務部門、法務部門 輸出成果（Deliverables） 專案提案書（Project Proposal） 商業案例文件（Business Case） 初步預算評估報告 專案授權書（Project Charter）草案 關鍵檢核點 專案與企業策略目標一致 商業效益清楚量化 預算範圍獲得初步認可 高階主管支持確認 常見風險與應對 風險項目 風險等級 應對措施 商業案例不夠明確 高 重新檢視需求與效益，補強分析 預算評估過於樂觀 中 加入10-20%風險緩衝 利害關係人支持不足 高 加強溝通，重新爭取支持 實務案例 情境說明：某銀行要開發新的數位帳戶開戶系統\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E5%95%9F%E5%8B%95%E6%B5%81%E7%A8%8B%E6%8C%87%E5%BC%95/","summary":"專案啟動流程指引 文件資訊 版本：1.1 建立日期：2025年8月13日 最後更新：2025年8月29日 適用對象：新進專案經理（0-2年經驗） 專案類型：系統開發、基礎架構升級、法遵專案 目錄 專案啟動流程概述\n1.1 定義與目標 1.2 專案啟動的重要性 1.3 專案啟動五大階段 專案啟動流程詳細說明\n2.1 階段一：專案立案 2.2 階段二：需求初步確認 2.3 階段三：組建核心團隊 2.4 階段四：專案規劃啟動 2.5 階段五：正式啟動會議 專案啟動流程總覽表\n3.1 流程階段彙整表 3.2 關鍵決策點與升級機制 專案啟動文件範本結構\n4.1 專案授權書（Project Charter）範本 4.2 專案啟動會議議程範本 4.3 專案啟動會議議程範例 成功專案啟動的五大關鍵建議\n專案啟動常見問題與解決方案\n專案啟動成功指標與評估標準\n數位化工具與技術應用\n法規遵循與資安要求\n參考資料與延伸學習\n附錄：版本更新記錄\n1. 專案啟動流程概述 1.1 定義與目標 專案啟動階段是專案生命週期的第一個階段，目標是正式授權專案開始並為專案成功奠定基礎。這個階段將確定專案範圍、目標、利害關係人，並獲得必要的資源承諾。\n1.2 專案啟動的重要性 建立共識：確保所有利害關係人對專案目標有一致理解 設定期望：明確定義專案成功標準與交付物 風險預防：及早識別潛在風險與限制條件 資源確保：獲得必要的人力、時間與預算承諾 1.3 專案啟動五大階段 graph LR A[專案立案] --\u0026gt; B[需求初步確認] B --\u0026gt; C[組建核心團隊] C --\u0026gt; D[專案規劃啟動] D --\u0026gt; E[正式啟動會議] 2. 專案啟動流程詳細說明 2.1 階段一：專案立案 工作內容 撰寫或審核專案提案書 進行初步可行性評估 確認專案商業價值與對齊策略 申請專案預算與資源 負責角色 主要負責：專案發起人（Project Sponsor） 協助角色：業務單位主管、IT部門主管 支援角色：財務部門、法務部門 輸出成果（Deliverables） 專案提案書（Project Proposal） 商業案例文件（Business Case） 初步預算評估報告 專案授權書（Project Charter）草案 關鍵檢核點 專案與企業策略目標一致 商業效益清楚量化 預算範圍獲得初步認可 高階主管支持確認 常見風險與應對 風險項目 風險等級 應對措施 商業案例不夠明確 高 重新檢視需求與效益，補強分析 預算評估過於樂觀 中 加入10-20%風險緩衝 利害關係人支持不足 高 加強溝通，重新爭取支持 實務案例 情境說明：某銀行要開發新的數位帳戶開戶系統\n","title":"專案啟動流程指引"},{"content":"專案溝通管理指引 版本：2.0\n建立日期：2025年8月13日\n最後更新：2025年8月29日\n適用對象：新進專案經理、專案團隊成員\n文件性質：內部培訓教材\n目錄 目的與重要性 溝通目標 溝通角色與責任 溝通計畫 溝通紀錄與追蹤機制 衝突與異議處理 溝通成效評估方式 數位化溝通工具與技術 危機溝通管理 跨文化與遠程溝通 溝通技巧培訓與發展 最佳實務案例 附錄：溝通模板與檢核表 參考資料 1. 目的與重要性 1.1 指引目的 本指引旨在提供新進專案經理一套完整且實用的溝通管理框架，協助：\n標準化溝通流程：建立一致的溝通標準與流程 提升溝通效率：確保資訊正確、及時傳達給相關干係人 降低專案風險：透過有效溝通預防和解決潛在問題 增進團隊協作：促進跨部門協作與資訊透明化 1.2 溝通管理的重要性 根據 PMI（專案管理協會）統計：\n90% 的專案經理時間用於溝通 57% 的專案失敗源於溝通不良 75% 的專案干係人問題可透過有效溝通避免 1.3 金融業溝通特性 在銀行與金融業專案中，溝通管理具備以下特殊性：\n法規合規性：須符合金管會、央行等監管要求 風險敏感性：任何資訊錯誤可能造成重大損失 多方干係人：涉及內部部門、外部供應商、稽核單位等 資訊安全性：需要特別注意敏感資訊的保護 1.4 實務案例 案例：核心銀行系統升級專案\n問題：IT部門與業務部門對需求理解不一致 影響：專案延遲 3 個月，預算超支 20% 解決：建立每週跨部門會議機制，統一需求文件格式 結果：後續階段準時完成，干係人滿意度提升至 85% 2. 溝通目標 2.1 主要溝通目標 專案溝通管理應達成以下核心目標：\n2.1.1 資訊透明化 即時性：關鍵資訊在 24 小時內傳達 準確性：資訊正確率達 95% 以上 完整性：涵蓋所有相關干係人 2.1.2 決策效率化 決策時效：一般決策 3 個工作日內完成 決策品質：基於充分且正確的資訊 決策追蹤：建立決策執行狀況追蹤機制 2.1.3 風險控制化 風險預警：建立風險資訊快速通報機制 問題解決：問題發生後 48 小時內提出解決方案 經驗傳承：建立知識管理與分享機制 2.2 階段性溝通目標 2.2.1 專案啟動階段 目標設定：確保所有干係人了解專案目標與範圍 團隊建立：建立有效的團隊溝通機制 期望管理：統一干係人對專案的期望 2.2.2 規劃階段 需求確認：確保需求完整且被正確理解 計畫共識：獲得所有干係人對專案計畫的認同 資源協調：確保資源分配的透明化 2.2.3 執行階段 進度追蹤：定期更新專案執行狀況 問題處理：快速識別並處理專案問題 變更管理：有效溝通專案變更事項 2.2.4 監控階段 績效報告：定期提供專案績效資訊 品質保證：確保溝通品質符合標準 風險監控：持續監控並溝通風險狀況 2.2.5 收尾階段 成果交付：確保交付成果被正確理解 經驗總結：收集並分享專案經驗教訓 關係維護：維持良好的干係人關係 2.3 溝通目標衡量指標 指標類別 具體指標 目標值 衡量方式 時效性 緊急事件回應時間 \u0026lt; 2 小時 事件日誌記錄 準確性 資訊錯誤率 \u0026lt; 5% 月度資訊稽核 覆蓋性 干係人參與率 \u0026gt; 90% 會議出席統計 滿意度 溝通滿意度評分 \u0026gt; 4.0/5.0 季度滿意度調查 2.4 實務提醒 ⚠️ 注意事項：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E6%BA%9D%E9%80%9A%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案溝通管理指引 版本：2.0\n建立日期：2025年8月13日\n最後更新：2025年8月29日\n適用對象：新進專案經理、專案團隊成員\n文件性質：內部培訓教材\n目錄 目的與重要性 溝通目標 溝通角色與責任 溝通計畫 溝通紀錄與追蹤機制 衝突與異議處理 溝通成效評估方式 數位化溝通工具與技術 危機溝通管理 跨文化與遠程溝通 溝通技巧培訓與發展 最佳實務案例 附錄：溝通模板與檢核表 參考資料 1. 目的與重要性 1.1 指引目的 本指引旨在提供新進專案經理一套完整且實用的溝通管理框架，協助：\n標準化溝通流程：建立一致的溝通標準與流程 提升溝通效率：確保資訊正確、及時傳達給相關干係人 降低專案風險：透過有效溝通預防和解決潛在問題 增進團隊協作：促進跨部門協作與資訊透明化 1.2 溝通管理的重要性 根據 PMI（專案管理協會）統計：\n90% 的專案經理時間用於溝通 57% 的專案失敗源於溝通不良 75% 的專案干係人問題可透過有效溝通避免 1.3 金融業溝通特性 在銀行與金融業專案中，溝通管理具備以下特殊性：\n法規合規性：須符合金管會、央行等監管要求 風險敏感性：任何資訊錯誤可能造成重大損失 多方干係人：涉及內部部門、外部供應商、稽核單位等 資訊安全性：需要特別注意敏感資訊的保護 1.4 實務案例 案例：核心銀行系統升級專案\n問題：IT部門與業務部門對需求理解不一致 影響：專案延遲 3 個月，預算超支 20% 解決：建立每週跨部門會議機制，統一需求文件格式 結果：後續階段準時完成，干係人滿意度提升至 85% 2. 溝通目標 2.1 主要溝通目標 專案溝通管理應達成以下核心目標：\n2.1.1 資訊透明化 即時性：關鍵資訊在 24 小時內傳達 準確性：資訊正確率達 95% 以上 完整性：涵蓋所有相關干係人 2.1.2 決策效率化 決策時效：一般決策 3 個工作日內完成 決策品質：基於充分且正確的資訊 決策追蹤：建立決策執行狀況追蹤機制 2.1.3 風險控制化 風險預警：建立風險資訊快速通報機制 問題解決：問題發生後 48 小時內提出解決方案 經驗傳承：建立知識管理與分享機制 2.2 階段性溝通目標 2.2.1 專案啟動階段 目標設定：確保所有干係人了解專案目標與範圍 團隊建立：建立有效的團隊溝通機制 期望管理：統一干係人對專案的期望 2.2.2 規劃階段 需求確認：確保需求完整且被正確理解 計畫共識：獲得所有干係人對專案計畫的認同 資源協調：確保資源分配的透明化 2.2.3 執行階段 進度追蹤：定期更新專案執行狀況 問題處理：快速識別並處理專案問題 變更管理：有效溝通專案變更事項 2.2.4 監控階段 績效報告：定期提供專案績效資訊 品質保證：確保溝通品質符合標準 風險監控：持續監控並溝通風險狀況 2.2.5 收尾階段 成果交付：確保交付成果被正確理解 經驗總結：收集並分享專案經驗教訓 關係維護：維持良好的干係人關係 2.3 溝通目標衡量指標 指標類別 具體指標 目標值 衡量方式 時效性 緊急事件回應時間 \u0026lt; 2 小時 事件日誌記錄 準確性 資訊錯誤率 \u0026lt; 5% 月度資訊稽核 覆蓋性 干係人參與率 \u0026gt; 90% 會議出席統計 滿意度 溝通滿意度評分 \u0026gt; 4.0/5.0 季度滿意度調查 2.4 實務提醒 ⚠️ 注意事項：\n","title":"專案溝通管理指引"},{"content":"專案管理指引 目錄 專案管理概述 專案生命週期與階段管理 專案啟動階段 專案規劃階段 專案執行階段 專案監控階段 專案收尾階段 風險管理 溝通與會議管理 文件與報告管理 品質管理 採購與供應商管理 人力資源管理 利害關係人管理 專案整合管理 敏捷專案管理 專案管理成熟度 附錄：範例與模板 1. 專案管理概述 1.1 專案管理定義 專案管理是運用知識、技能、工具與技術於專案活動，以滿足專案需求的管理過程。對於金融 IT 專案而言，更需要嚴格遵循 SSDLC（安全軟體開發生命週期）規範。\n1.2 專案管理核心原則 明確的目標設定：每個專案都必須有清楚、可衡量的目標 時程與資源控管：有效管理時間、人力、預算等資源 品質保證：確保交付成果符合既定標準 風險管控：主動識別、評估與應對專案風險 持續溝通：建立有效的溝通機制與管道 1.3 專案管理五大流程群組 啟動（Initiating）：定義專案範圍與目標 規劃（Planning）：制定詳細執行計畫 執行（Executing）：實際進行專案工作 監控（Monitoring \u0026amp; Controlling）：追蹤進度並進行調整 收尾（Closing）：完成專案並進行經驗傳承 1.4 金融 IT 專案特色 高度安全性要求（須符合金管會、國際標準） 嚴格的法規遵循（如個資法、洗錢防制法） 複雜的系統整合需求 24/7 營運環境的穩定性要求 大量的測試與驗證程序 實務案例 某銀行數位帳戶開發專案，專案經理運用 Agile 方法論，將 12 個月的專案分為 6 個 Sprint，每個 Sprint 2 個月。透過每日站立會議、Sprint 回顧會議等機制，成功在預定時程內上線，並獲得客戶滿意度 95% 的佳績。\n2. 專案生命週期與階段管理 2.1 專案生命週期概述 專案生命週期是從專案啟動到結束的完整過程，每個階段都有特定的目標、活動與交付成果。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案管理指引 目錄 專案管理概述 專案生命週期與階段管理 專案啟動階段 專案規劃階段 專案執行階段 專案監控階段 專案收尾階段 風險管理 溝通與會議管理 文件與報告管理 品質管理 採購與供應商管理 人力資源管理 利害關係人管理 專案整合管理 敏捷專案管理 專案管理成熟度 附錄：範例與模板 1. 專案管理概述 1.1 專案管理定義 專案管理是運用知識、技能、工具與技術於專案活動，以滿足專案需求的管理過程。對於金融 IT 專案而言，更需要嚴格遵循 SSDLC（安全軟體開發生命週期）規範。\n1.2 專案管理核心原則 明確的目標設定：每個專案都必須有清楚、可衡量的目標 時程與資源控管：有效管理時間、人力、預算等資源 品質保證：確保交付成果符合既定標準 風險管控：主動識別、評估與應對專案風險 持續溝通：建立有效的溝通機制與管道 1.3 專案管理五大流程群組 啟動（Initiating）：定義專案範圍與目標 規劃（Planning）：制定詳細執行計畫 執行（Executing）：實際進行專案工作 監控（Monitoring \u0026amp; Controlling）：追蹤進度並進行調整 收尾（Closing）：完成專案並進行經驗傳承 1.4 金融 IT 專案特色 高度安全性要求（須符合金管會、國際標準） 嚴格的法規遵循（如個資法、洗錢防制法） 複雜的系統整合需求 24/7 營運環境的穩定性要求 大量的測試與驗證程序 實務案例 某銀行數位帳戶開發專案，專案經理運用 Agile 方法論，將 12 個月的專案分為 6 個 Sprint，每個 Sprint 2 個月。透過每日站立會議、Sprint 回顧會議等機制，成功在預定時程內上線，並獲得客戶滿意度 95% 的佳績。\n2. 專案生命週期與階段管理 2.1 專案生命週期概述 專案生命週期是從專案啟動到結束的完整過程，每個階段都有特定的目標、活動與交付成果。\n","title":"專案管理指引"},{"content":"專案風險管理指引 目錄 1. 專案風險管理的定義與重要性 1.1 定義 1.2 風險管理的核心概念 1.3 為什麼風險管理很重要 1.4 金融 IT 專案的風險特性 1.5 實務案例 2. 風險分類 2.1 技術風險 2.2 管理風險 2.3 外部風險 2.4 合規風險 2.5 實務案例 3. 風險識別方法 3.1 概述 3.2 訪談法 3.3 檢核表法 3.4 歷史資料分析法 3.5 其他識別方法 3.6 風險識別的組織與文件化 3.7 實務案例 4. 風險評估 4.1 風險評估概述 4.2 風險機率評估 4.3 風險影響評估 4.4 風險優先級矩陣 4.5 定量風險分析 4.6 風險評估工具與技術 4.7 風險評估文件化 4.8 實務案例 5. 風險應對策略 5.1 風險應對策略概述 5.2 規避策略 5.3 轉移策略 5.4 減輕策略 5.5 接受策略 5.6 風險應對計畫制定 5.7 風險應對策略選擇原則 5.8 實務案例 6. 風險監控與更新流程 6.1 風險監控概述 6.2 風險監控機制 6.3 風險監控工具 6.4 風險更新流程 6.5 風險溝通管理 6.6 風險學習與改善 6.7 實務案例 7. 附錄：風險登錄表模板與範例 7.1 風險登錄表模板 7.2 不同風險類型範例 7.3 風險評估工作表 7.4 風險應對計畫範本 8. 風險管理工具與技術 9. 風險管理最佳實務 10. 常見問題與解答 參考資料 1. 專案風險管理的定義與重要性 1.1 定義 專案風險管理是指在專案生命週期中，系統性地識別、分析、評估、應對和監控可能影響專案目標達成的不確定性事件或條件的管理過程。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E9%A2%A8%E9%9A%AA%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案風險管理指引 目錄 1. 專案風險管理的定義與重要性 1.1 定義 1.2 風險管理的核心概念 1.3 為什麼風險管理很重要 1.4 金融 IT 專案的風險特性 1.5 實務案例 2. 風險分類 2.1 技術風險 2.2 管理風險 2.3 外部風險 2.4 合規風險 2.5 實務案例 3. 風險識別方法 3.1 概述 3.2 訪談法 3.3 檢核表法 3.4 歷史資料分析法 3.5 其他識別方法 3.6 風險識別的組織與文件化 3.7 實務案例 4. 風險評估 4.1 風險評估概述 4.2 風險機率評估 4.3 風險影響評估 4.4 風險優先級矩陣 4.5 定量風險分析 4.6 風險評估工具與技術 4.7 風險評估文件化 4.8 實務案例 5. 風險應對策略 5.1 風險應對策略概述 5.2 規避策略 5.3 轉移策略 5.4 減輕策略 5.5 接受策略 5.6 風險應對計畫制定 5.7 風險應對策略選擇原則 5.8 實務案例 6. 風險監控與更新流程 6.1 風險監控概述 6.2 風險監控機制 6.3 風險監控工具 6.4 風險更新流程 6.5 風險溝通管理 6.6 風險學習與改善 6.7 實務案例 7. 附錄：風險登錄表模板與範例 7.1 風險登錄表模板 7.2 不同風險類型範例 7.3 風險評估工作表 7.4 風險應對計畫範本 8. 風險管理工具與技術 9. 風險管理最佳實務 10. 常見問題與解答 參考資料 1. 專案風險管理的定義與重要性 1.1 定義 專案風險管理是指在專案生命週期中，系統性地識別、分析、評估、應對和監控可能影響專案目標達成的不確定性事件或條件的管理過程。\n","title":"專案風險管理指引"},{"content":"後端開發指引 目錄 開發原則 專案結構與命名規範 API 設計規範 資料庫存取與 ORM 規範 安全性規範 效能與擴展性指引 測試與品質保證 部署與維運指引 日誌管理與監控 資料驗證與清理 國際化與本地化 文件生成與 API 規範 第三方整合規範 程式碼審查與品質控制 依賴與配置管理 備份與災難恢復 1. 開發原則 1.1 架構模式 Clean Architecture 實作原則 依賴反轉原則：內層不依賴外層，外層依賴內層 單一職責原則：每個類別/模組只負責一個職責 開放封閉原則：對擴展開放，對修改封閉 介面隔離原則：使用者不應依賴不需要的介面 架構分層結構： ┌─────────────────────────────────────┐ │ Presentation Layer │ ← Controllers, DTOs ├─────────────────────────────────────┤ │ Application Layer │ ← Use Cases, Services ├─────────────────────────────────────┤ │ Domain Layer │ ← Entities, Repositories ├─────────────────────────────────────┤ │ Infrastructure Layer │ ← Database, External APIs └─────────────────────────────────────┘ 分層設計規範 Presentation Layer（表現層）\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%BE%8C%E7%AB%AF%E9%96%8B%E7%99%BC%E6%8C%87%E5%BC%95/","summary":"後端開發指引 目錄 開發原則 專案結構與命名規範 API 設計規範 資料庫存取與 ORM 規範 安全性規範 效能與擴展性指引 測試與品質保證 部署與維運指引 日誌管理與監控 資料驗證與清理 國際化與本地化 文件生成與 API 規範 第三方整合規範 程式碼審查與品質控制 依賴與配置管理 備份與災難恢復 1. 開發原則 1.1 架構模式 Clean Architecture 實作原則 依賴反轉原則：內層不依賴外層，外層依賴內層 單一職責原則：每個類別/模組只負責一個職責 開放封閉原則：對擴展開放，對修改封閉 介面隔離原則：使用者不應依賴不需要的介面 架構分層結構： ┌─────────────────────────────────────┐ │ Presentation Layer │ ← Controllers, DTOs ├─────────────────────────────────────┤ │ Application Layer │ ← Use Cases, Services ├─────────────────────────────────────┤ │ Domain Layer │ ← Entities, Repositories ├─────────────────────────────────────┤ │ Infrastructure Layer │ ← Database, External APIs └─────────────────────────────────────┘ 分層設計規範 Presentation Layer（表現層）\n","title":"後端開發指引"},{"content":"敏捷專案管理指引 目錄 前言 敏捷專案管理核心原則 常用敏捷方法 敏捷專案管理流程 敏捷工具與實務應用 敏捷專案管理在銀行系統的特別注意事項 常見問題與解決策略（FAQ） 結論與建議 參考資料 前言 敏捷專案管理的定義與重要性 敏捷專案管理（Agile Project Management）是一種以人為本、迭代式、增量式的專案管理方法論。它強調：\n適應變化：擁抱需求變更，而非抗拒變化 快速交付：透過短週期迭代，頻繁交付可用的軟體或產品 客戶協作：與客戶密切合作，持續獲得回饋 團隊自主：授權團隊自我組織和決策 為什麼敏捷專案管理很重要？ 市場快速變化：現今金融科技環境瞬息萬變，傳統瀑布式開發無法及時回應 客戶期望提升：客戶期待更快的上市時間和更高的產品品質 技術複雜度增加：現代系統整合度高，需要靈活的開發方式 法規環境變動：金融業法規頻繁更新，需要敏捷的回應機制 與傳統瀑布式開發的差異 比較項目 瀑布式開發 敏捷開發 開發流程 線性、順序性 迭代式、增量式 需求變更 後期變更成本高昂 擁抱變更，持續調整 客戶參與 專案初期和結尾 整個開發過程 交付頻率 專案結束時一次交付 每2-4週交付一次 風險管控 後期才發現問題 早期發現，快速調整 文件重點 詳盡的文件 可用的軟體 團隊結構 階層化管理 自我組織團隊 實務案例 某銀行數位轉型專案原採瀑布式開發，18個月後才發現市場需求已改變。改採敏捷開發後，每3週展示一次成果，第6個月就推出MVP（最小可行產品），成功搶占市場先機。\n敏捷專案管理核心原則 Agile Manifesto 四大價值 敏捷宣言（Agile Manifesto）於2001年發布，奠定了敏捷開發的核心價值觀：\n1. 個體與互動 重於 流程與工具 重點：人是專案成功的關鍵，良好的溝通比完美的工具更重要 實務應用： 每日站會面對面溝通 建立開放的工作環境 鼓勵團隊成員直接對話 2. 可用的軟體 重於 詳盡的文件 重點：以交付可用的產品為目標，而非完美的文件 實務應用： 專注於核心功能的實現 文件簡潔明瞭，以必要為準 透過實際產品驗證需求 3. 客戶協作 重於 合約談判 重點：與客戶建立夥伴關係，共同創造價值 實務應用： 客戶參與每次Sprint回顧 定期收集客戶回饋 調整產品方向以符合客戶真實需求 4. 回應變化 重於 遵循計劃 重點：靈活回應市場和需求變化 實務應用： 定期評估和調整專案優先級 建立彈性的開發架構 預留緩衝時間應對變更 敏捷十二項原則 最高優先級：透過早期和持續交付有價值的軟體來滿足客戶 歡迎需求變更：即使在開發後期也歡迎需求變更 頻繁交付：頻繁地交付可用的軟體，從幾週到幾個月 協同工作：業務人員和開發者必須在整個專案中每天協同工作 激發個體：圍繞被激發的個體構建專案，給他們所需的環境和支持 面對面溝通：在開發團隊中最有效的溝通方式是面對面的交談 可用軟體：可用的軟體是衡量進度的主要標準 可持續發展：敏捷流程提倡可持續的開發速度 技術卓越：持續關注技術卓越和良好設計會增強敏捷性 簡潔：簡潔——最大化未完成工作量的技藝——至關重要 自組織團隊：最好的架構、需求和設計來自自組織團隊 定期調整：團隊定期反思如何能變得更有效，然後調整行為 在金融/銀行專案中的適用性說明 適用場景 數位化轉型專案：線上銀行、行動APP開發 法規遵循系統：需要快速回應法規變更 客戶體驗改善：根據客戶回饋持續優化 創新產品開發：新金融商品或服務的探索 注意事項 法規要求：某些文件和審查流程不可省略 安全考量：資安測試和稽核需要充分時間 風險管控：金融業對風險敏感，需要適當的控制點 合規性：確保敏捷實踐符合內控制度 實務案例 某區域銀行開發客戶關係管理系統，採用Scrum方法：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"敏捷專案管理指引 目錄 前言 敏捷專案管理核心原則 常用敏捷方法 敏捷專案管理流程 敏捷工具與實務應用 敏捷專案管理在銀行系統的特別注意事項 常見問題與解決策略（FAQ） 結論與建議 參考資料 前言 敏捷專案管理的定義與重要性 敏捷專案管理（Agile Project Management）是一種以人為本、迭代式、增量式的專案管理方法論。它強調：\n適應變化：擁抱需求變更，而非抗拒變化 快速交付：透過短週期迭代，頻繁交付可用的軟體或產品 客戶協作：與客戶密切合作，持續獲得回饋 團隊自主：授權團隊自我組織和決策 為什麼敏捷專案管理很重要？ 市場快速變化：現今金融科技環境瞬息萬變，傳統瀑布式開發無法及時回應 客戶期望提升：客戶期待更快的上市時間和更高的產品品質 技術複雜度增加：現代系統整合度高，需要靈活的開發方式 法規環境變動：金融業法規頻繁更新，需要敏捷的回應機制 與傳統瀑布式開發的差異 比較項目 瀑布式開發 敏捷開發 開發流程 線性、順序性 迭代式、增量式 需求變更 後期變更成本高昂 擁抱變更，持續調整 客戶參與 專案初期和結尾 整個開發過程 交付頻率 專案結束時一次交付 每2-4週交付一次 風險管控 後期才發現問題 早期發現，快速調整 文件重點 詳盡的文件 可用的軟體 團隊結構 階層化管理 自我組織團隊 實務案例 某銀行數位轉型專案原採瀑布式開發，18個月後才發現市場需求已改變。改採敏捷開發後，每3週展示一次成果，第6個月就推出MVP（最小可行產品），成功搶占市場先機。\n敏捷專案管理核心原則 Agile Manifesto 四大價值 敏捷宣言（Agile Manifesto）於2001年發布，奠定了敏捷開發的核心價值觀：\n1. 個體與互動 重於 流程與工具 重點：人是專案成功的關鍵，良好的溝通比完美的工具更重要 實務應用： 每日站會面對面溝通 建立開放的工作環境 鼓勵團隊成員直接對話 2. 可用的軟體 重於 詳盡的文件 重點：以交付可用的產品為目標，而非完美的文件 實務應用： 專注於核心功能的實現 文件簡潔明瞭，以必要為準 透過實際產品驗證需求 3. 客戶協作 重於 合約談判 重點：與客戶建立夥伴關係，共同創造價值 實務應用： 客戶參與每次Sprint回顧 定期收集客戶回饋 調整產品方向以符合客戶真實需求 4. 回應變化 重於 遵循計劃 重點：靈活回應市場和需求變化 實務應用： 定期評估和調整專案優先級 建立彈性的開發架構 預留緩衝時間應對變更 敏捷十二項原則 最高優先級：透過早期和持續交付有價值的軟體來滿足客戶 歡迎需求變更：即使在開發後期也歡迎需求變更 頻繁交付：頻繁地交付可用的軟體，從幾週到幾個月 協同工作：業務人員和開發者必須在整個專案中每天協同工作 激發個體：圍繞被激發的個體構建專案，給他們所需的環境和支持 面對面溝通：在開發團隊中最有效的溝通方式是面對面的交談 可用軟體：可用的軟體是衡量進度的主要標準 可持續發展：敏捷流程提倡可持續的開發速度 技術卓越：持續關注技術卓越和良好設計會增強敏捷性 簡潔：簡潔——最大化未完成工作量的技藝——至關重要 自組織團隊：最好的架構、需求和設計來自自組織團隊 定期調整：團隊定期反思如何能變得更有效，然後調整行為 在金融/銀行專案中的適用性說明 適用場景 數位化轉型專案：線上銀行、行動APP開發 法規遵循系統：需要快速回應法規變更 客戶體驗改善：根據客戶回饋持續優化 創新產品開發：新金融商品或服務的探索 注意事項 法規要求：某些文件和審查流程不可省略 安全考量：資安測試和稽核需要充分時間 風險管控：金融業對風險敏感，需要適當的控制點 合規性：確保敏捷實踐符合內控制度 實務案例 某區域銀行開發客戶關係管理系統，採用Scrum方法：\n","title":"敏捷專案管理指引"},{"content":"系統架構設計指引 目錄 1. 架構設計原則\n1.1 設計核心原則 1.2 技術選型原則 1.3 架構品質屬性 2. 系統整體架構圖\n2.1 微服務拆分策略 2.2 API Gateway 設計 2.3 服務間通訊 2.4 服務網格架構 3. 前後端分離與微前端設計\n3.1 微前端架構 3.2 前端技術棧 3.3 響應式設計 (RWD) 3.4 多語系支援 4. 後端分層架構 (Clean Architecture)\n4.1 Clean Architecture 層級設計 4.2 目錄結構設計 4.3 依賴注入與配置 4.4 API 設計規範 5. 資料庫設計原則\n5.1 多資料庫支援策略 5.2 資料分片與讀寫分離 5.3 資料庫設計範例 5.4 資料遷移策略 6. 效能優化方案\n6.1 快取策略 6.2 快取配置範例 6.3 CDN 配置 6.4 非同步處理 6.5 負載平衡策略 6.6 效能基準測試 7. 高可用性與災難復原設計\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"系統架構設計指引 目錄 1. 架構設計原則\n1.1 設計核心原則 1.2 技術選型原則 1.3 架構品質屬性 2. 系統整體架構圖\n2.1 微服務拆分策略 2.2 API Gateway 設計 2.3 服務間通訊 2.4 服務網格架構 3. 前後端分離與微前端設計\n3.1 微前端架構 3.2 前端技術棧 3.3 響應式設計 (RWD) 3.4 多語系支援 4. 後端分層架構 (Clean Architecture)\n4.1 Clean Architecture 層級設計 4.2 目錄結構設計 4.3 依賴注入與配置 4.4 API 設計規範 5. 資料庫設計原則\n5.1 多資料庫支援策略 5.2 資料分片與讀寫分離 5.3 資料庫設計範例 5.4 資料遷移策略 6. 效能優化方案\n6.1 快取策略 6.2 快取配置範例 6.3 CDN 配置 6.4 非同步處理 6.5 負載平衡策略 6.6 效能基準測試 7. 高可用性與災難復原設計\n","title":"架構設計指引"},{"content":"業務需求收集範本 Prompt 目標 協助 AI 理解如何進行系統性的業務需求收集，產生完整的業務需求文檔。\n角色設定 你是一位資深業務分析師，具備豐富的需求收集經驗，能夠透過結構化的方法收集、分析和文檔化業務需求。\n任務描述 請協助我完成 {專案名稱} 的業務需求收集工作。\n專案背景資訊 專案名稱: {填入專案名稱} 專案類型: {填入專案類型，如：Web應用、移動應用、桌面應用等} 目標使用者: {填入目標使用者群體} 業務領域: {填入業務領域，如：電商、金融、教育等} 專案規模: {填入專案規模，如：小型、中型、大型} 具體要求 請按照以下結構產生業務需求文檔：\n1. 專案概述 專案目標與願景 成功標準定義 專案範圍界定 主要限制條件 2. 利害關係人分析 識別所有利害關係人 分析各利害關係人的需求和期望 定義利害關係人的影響力和重要性 建立溝通策略 3. 業務流程分析 現有業務流程描述 問題點識別 改善機會分析 未來流程設計 4. 功能需求概述 核心功能列表 次要功能列表 可選功能列表 功能優先級排序 5. 業務規則 業務邏輯規則 驗證規則 計算規則 工作流程規則 6. 資料需求 主要資料實體 資料關係 資料品質要求 資料安全要求 輸出格式 請使用以下 Markdown 格式輸出：\n# {專案名稱} 業務需求文檔 ## 1. 專案概述 ### 1.1 專案目標與願景 [詳細描述] ### 1.2 成功標準 [具體的、可測量的成功標準] ### 1.3 專案範圍 [明確的範圍界定] ### 1.4 限制條件 [技術、時間、預算等限制] ## 2. 利害關係人分析 ### 2.1 利害關係人清單 | 角色 | 姓名/部門 | 需求/期望 | 影響力 | 重要性 | |------|----------|----------|--------|--------| | [角色] | [姓名] | [需求] | [高/中/低] | [高/中/低] | ### 2.2 溝通策略 [溝通方式和頻率] ## 3. 業務流程分析 ### 3.1 現有流程 [流程描述或流程圖] ### 3.2 問題分析 [問題點列表及影響分析] ### 3.3 改善建議 [具體改善方案] ## 4. 功能需求概述 ### 4.1 核心功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.2 次要功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.3 功能優先級 | 功能 | 優先級 | 理由 | |------|--------|------| | [功能] | [高/中/低] | [理由] | ## 5. 業務規則 ### 5.1 業務邏輯規則 - [規則1]: [描述] - [規則2]: [描述] ### 5.2 驗證規則 - [規則1]: [描述] - [規則2]: [描述] ## 6. 資料需求 ### 6.1 資料實體 - [實體1]: [屬性列表] - [實體2]: [屬性列表] ### 6.2 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素：\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E6%A5%AD%E5%8B%99%E9%9C%80%E6%B1%82%E6%94%B6%E9%9B%86%E7%AF%84%E6%9C%AC/","summary":"業務需求收集範本 Prompt 目標 協助 AI 理解如何進行系統性的業務需求收集，產生完整的業務需求文檔。\n角色設定 你是一位資深業務分析師，具備豐富的需求收集經驗，能夠透過結構化的方法收集、分析和文檔化業務需求。\n任務描述 請協助我完成 {專案名稱} 的業務需求收集工作。\n專案背景資訊 專案名稱: {填入專案名稱} 專案類型: {填入專案類型，如：Web應用、移動應用、桌面應用等} 目標使用者: {填入目標使用者群體} 業務領域: {填入業務領域，如：電商、金融、教育等} 專案規模: {填入專案規模，如：小型、中型、大型} 具體要求 請按照以下結構產生業務需求文檔：\n1. 專案概述 專案目標與願景 成功標準定義 專案範圍界定 主要限制條件 2. 利害關係人分析 識別所有利害關係人 分析各利害關係人的需求和期望 定義利害關係人的影響力和重要性 建立溝通策略 3. 業務流程分析 現有業務流程描述 問題點識別 改善機會分析 未來流程設計 4. 功能需求概述 核心功能列表 次要功能列表 可選功能列表 功能優先級排序 5. 業務規則 業務邏輯規則 驗證規則 計算規則 工作流程規則 6. 資料需求 主要資料實體 資料關係 資料品質要求 資料安全要求 輸出格式 請使用以下 Markdown 格式輸出：\n# {專案名稱} 業務需求文檔 ## 1. 專案概述 ### 1.1 專案目標與願景 [詳細描述] ### 1.2 成功標準 [具體的、可測量的成功標準] ### 1.3 專案範圍 [明確的範圍界定] ### 1.4 限制條件 [技術、時間、預算等限制] ## 2. 利害關係人分析 ### 2.1 利害關係人清單 | 角色 | 姓名/部門 | 需求/期望 | 影響力 | 重要性 | |------|----------|----------|--------|--------| | [角色] | [姓名] | [需求] | [高/中/低] | [高/中/低] | ### 2.2 溝通策略 [溝通方式和頻率] ## 3. 業務流程分析 ### 3.1 現有流程 [流程描述或流程圖] ### 3.2 問題分析 [問題點列表及影響分析] ### 3.3 改善建議 [具體改善方案] ## 4. 功能需求概述 ### 4.1 核心功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.2 次要功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.3 功能優先級 | 功能 | 優先級 | 理由 | |------|--------|------| | [功能] | [高/中/低] | [理由] | ## 5. 業務規則 ### 5.1 業務邏輯規則 - [規則1]: [描述] - [規則2]: [描述] ### 5.2 驗證規則 - [規則1]: [描述] - [規則2]: [描述] ## 6. 資料需求 ### 6.1 資料實體 - [實體1]: [屬性列表] - [實體2]: [屬性列表] ### 6.2 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素：\n","title":"業務需求收集範本"},{"content":"測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。\n角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。\n任務描述 請協助我為 {專案名稱} 制定完整的測試策略。\n專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略：\n1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 \u0026lt; 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 \u0026lt; 2秒 - 吞吐量: \u0026gt; 1000 TPS - 並發使用者: \u0026gt; 5000 - 資源使用率: CPU \u0026lt; 80%, Memory \u0026lt; 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 \u0026#43; Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver \u0026#43; Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E6%B8%AC%E8%A9%A6%E9%A9%97%E6%94%B6/%E6%B8%AC%E8%A9%A6%E7%AD%96%E7%95%A5%E5%88%B6%E5%AE%9A%E7%AF%84%E6%9C%AC/","summary":"測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。\n角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。\n任務描述 請協助我為 {專案名稱} 制定完整的測試策略。\n專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略：\n1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 \u0026lt; 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 \u0026lt; 2秒 - 吞吐量: \u0026gt; 1000 TPS - 並發使用者: \u0026gt; 5000 - 資源使用率: CPU \u0026lt; 80%, Memory \u0026lt; 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 \u0026#43; Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver \u0026#43; Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告\n","title":"測試策略制定範本"},{"content":"測試與品質保證指引 適用對象: 新進專案成員、開發人員、測試人員\n文件目的: 快速理解專案的測試流程與品質保證規範\n更新日期: 2025年8月27日\n目錄 測試與品質保證的角色與責任 測試流程與各階段 測試計畫與測試案例設計 測試自動化與工具建議 缺陷管理流程 測試品質指標與衡量方式 測試與 CI/CD、版本控管、DevOps 的關聯 安全性測試與合規性驗證 效能測試與效能調校 測試資料管理與隱私保護 跨瀏覽器與跨平台測試 API 測試與微服務測試策略 常見錯誤與避免方式 新進成員的最佳實務與建議 測試與品質保證檢查清單 測試成本效益分析與 ROI 評估 團隊協作與溝通 1. 測試與品質保證的角色與責任 1.1 開發人員職責 主要責任 撰寫單元測試: 為每個新功能撰寫對應的單元測試 程式碼審查: 檢視同事的程式碼，確保品質標準 修復缺陷: 及時修復測試中發現的問題 文件維護: 更新技術文件和 API 說明 具體工作項目 ✅ 每個方法都有對應的單元測試 ✅ 程式碼覆蓋率達到 80% 以上 ✅ 遵循程式碼風格指引 ✅ 提交前執行本地測試 1.2 測試人員職責 主要責任 測試案例設計: 根據需求規格設計完整的測試案例 執行測試: 進行系統測試、整合測試、使用者驗收測試 缺陷追蹤: 記錄、追蹤並驗證缺陷修復 測試報告: 提供測試結果分析和品質評估 具體工作項目 ✅ 設計邊界值和異常情況測試 ✅ 執行回歸測試確保功能穩定 ✅ 驗證非功能性需求（效能、安全性） ✅ 提供測試執行報告 1.3 專案經理職責 主要責任 資源規劃: 安排測試時程和人力資源 風險管控: 識別並管理測試相關風險 品質監控: 監控專案整體品質指標 溝通協調: 協調開發、測試、業務單位間的合作 1.4 實務案例 案例一：銀行系統開發 情境：開發線上轉帳功能 - 開發人員：撰寫轉帳邏輯單元測試 - 測試人員：設計轉帳金額邊界值測試（0元、負數、超過限額） - 專案經理：確保測試覆蓋金管會法規要求 案例二：API 開發 情境：開發客戶資料查詢 API - 開發人員：測試 API 回應格式和錯誤處理 - 測試人員：驗證 API 安全性和效能 - 專案經理：確保符合個資保護規範 1.5 注意事項 ⚠️ 重要提醒\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E6%B8%AC%E8%A9%A6%E8%88%87%E5%93%81%E8%B3%AA%E4%BF%9D%E8%AD%89%E6%8C%87%E5%BC%95/","summary":"測試與品質保證指引 適用對象: 新進專案成員、開發人員、測試人員\n文件目的: 快速理解專案的測試流程與品質保證規範\n更新日期: 2025年8月27日\n目錄 測試與品質保證的角色與責任 測試流程與各階段 測試計畫與測試案例設計 測試自動化與工具建議 缺陷管理流程 測試品質指標與衡量方式 測試與 CI/CD、版本控管、DevOps 的關聯 安全性測試與合規性驗證 效能測試與效能調校 測試資料管理與隱私保護 跨瀏覽器與跨平台測試 API 測試與微服務測試策略 常見錯誤與避免方式 新進成員的最佳實務與建議 測試與品質保證檢查清單 測試成本效益分析與 ROI 評估 團隊協作與溝通 1. 測試與品質保證的角色與責任 1.1 開發人員職責 主要責任 撰寫單元測試: 為每個新功能撰寫對應的單元測試 程式碼審查: 檢視同事的程式碼，確保品質標準 修復缺陷: 及時修復測試中發現的問題 文件維護: 更新技術文件和 API 說明 具體工作項目 ✅ 每個方法都有對應的單元測試 ✅ 程式碼覆蓋率達到 80% 以上 ✅ 遵循程式碼風格指引 ✅ 提交前執行本地測試 1.2 測試人員職責 主要責任 測試案例設計: 根據需求規格設計完整的測試案例 執行測試: 進行系統測試、整合測試、使用者驗收測試 缺陷追蹤: 記錄、追蹤並驗證缺陷修復 測試報告: 提供測試結果分析和品質評估 具體工作項目 ✅ 設計邊界值和異常情況測試 ✅ 執行回歸測試確保功能穩定 ✅ 驗證非功能性需求（效能、安全性） ✅ 提供測試執行報告 1.3 專案經理職責 主要責任 資源規劃: 安排測試時程和人力資源 風險管控: 識別並管理測試相關風險 品質監控: 監控專案整體品質指標 溝通協調: 協調開發、測試、業務單位間的合作 1.4 實務案例 案例一：銀行系統開發 情境：開發線上轉帳功能 - 開發人員：撰寫轉帳邏輯單元測試 - 測試人員：設計轉帳金額邊界值測試（0元、負數、超過限額） - 專案經理：確保測試覆蓋金管會法規要求 案例二：API 開發 情境：開發客戶資料查詢 API - 開發人員：測試 API 回應格式和錯誤處理 - 測試人員：驗證 API 安全性和效能 - 專案經理：確保符合個資保護規範 1.5 注意事項 ⚠️ 重要提醒\n","title":"測試與品質保證指引"},{"content":"物件導向分析與設計 (OOAD) 教學手冊 作者: 系統架構師團隊\n更新日期: 2026年7月17日\n適用對象: 新進開發同仁\n版本: v2.1\n目錄 前言與學習目標\n1.1 為什麼要學習 OOAD？ 1.2 學習目標 1.3 學習路徑 1.4 前置知識 OOAD 基礎概念\n2.1 什麼是物件導向？ 2.2 核心概念詳解 2.3 OOAD 的設計原則 2.4 實務案例：學生管理系統 2.5 章節小結 OOAD 開發流程\n3.1 OOAD 流程概覽 3.2 階段一：需求分析 (Requirements Analysis) 3.3 階段二：系統分析 (System Analysis) 3.4 階段三：系統設計 (System Design) 3.5 階段四：詳細設計 (Detailed Design) 3.6 階段五：程式實作 (Implementation) 3.7 階段六：測試與驗證 3.8 章節小結 UML 與 OOAD 的關係\n4.1 UML 簡介 4.2 UML 圖形分類 4.3 核心 UML 圖形詳解 4.4 UML 工具與最佳實務 4.5 章節小結 專案實務應用範例\n5.1 專案背景：大學課程管理系統 5.2 階段一：需求分析與 Use Case 設計 5.3 階段二：領域分析與建模 5.4 階段三：架構設計 5.5 階段四：詳細設計 5.6 階段五：關鍵循序圖 5.7 實作關鍵功能 5.8 章節小結 常見錯誤與最佳實務\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E7%89%A9%E4%BB%B6%E5%B0%8E%E5%90%91%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88-ooad-%E6%95%99%E5%AD%B8/","summary":"物件導向分析與設計 (OOAD) 教學手冊 作者: 系統架構師團隊\n更新日期: 2026年7月17日\n適用對象: 新進開發同仁\n版本: v2.1\n目錄 前言與學習目標\n1.1 為什麼要學習 OOAD？ 1.2 學習目標 1.3 學習路徑 1.4 前置知識 OOAD 基礎概念\n2.1 什麼是物件導向？ 2.2 核心概念詳解 2.3 OOAD 的設計原則 2.4 實務案例：學生管理系統 2.5 章節小結 OOAD 開發流程\n3.1 OOAD 流程概覽 3.2 階段一：需求分析 (Requirements Analysis) 3.3 階段二：系統分析 (System Analysis) 3.4 階段三：系統設計 (System Design) 3.5 階段四：詳細設計 (Detailed Design) 3.6 階段五：程式實作 (Implementation) 3.7 階段六：測試與驗證 3.8 章節小結 UML 與 OOAD 的關係\n4.1 UML 簡介 4.2 UML 圖形分類 4.3 核心 UML 圖形詳解 4.4 UML 工具與最佳實務 4.5 章節小結 專案實務應用範例\n5.1 專案背景：大學課程管理系統 5.2 階段一：需求分析與 Use Case 設計 5.3 階段二：領域分析與建模 5.4 階段三：架構設計 5.5 階段四：詳細設計 5.6 階段五：關鍵循序圖 5.7 實作關鍵功能 5.8 章節小結 常見錯誤與最佳實務\n","title":"物件導向分析與設計 (OOAD) 教學"},{"content":"程式寫作指引 目錄 前言 程式碼風格與命名規範 1.1 Java 命名規範 1.2 TypeScript/JavaScript 命名規範 1.3 程式碼格式化 1.4 實務案例與注意事項 註解與文件撰寫 2.1 JavaDoc 註解規範 2.2 TypeScript JSDoc 註解 2.3 程式碼內註解最佳實踐 2.4 API 文件撰寫 2.5 Vue 元件註解 2.6 實務案例與注意事項 錯誤處理與日誌紀錄 3.1 例外處理最佳實踐 3.2 日誌記錄最佳實踐 3.3 監控與告警設定 3.4 實務案例與注意事項 單元測試與TDD 4.1 JUnit 5 測試規範 4.2 TypeScript/Jest 測試規範 4.3 測試驅動開發（TDD）流程 4.4 測試覆蓋率與品質指標 4.5 實務案例與注意事項 安全性考量 5.1 輸入驗證與資料清理 5.2 認證和授權 5.3 XSS 攻擊防護 5.4 CSRF 攻擊防護 5.5 敏感資料處理 5.6 安全標頭配置 Spring Boot 常用功能實踐 6.1 JWT (JSON Web Token) 認證授權 6.2 Spring Data JPA 最佳實踐 6.3 Spring Batch 批次處理 6.4 Spring Cache 快取管理 6.5 Spring Boot 配置管理 資料庫設計與操作 7.1 資料庫設計原則 7.2 SQL 查詢優化 7.3 事務管理 7.4 資料遷移策略 7.5 資料庫監控與維護 效能優化 8.1 Java 應用程式效能優化 8.2 Spring Boot 效能調優 8.3 前端效能優化 8.4 快取策略優化 8.5 監控和指標 8.6 效能測試 8.7 效能優化檢查清單 容器化與DevOps 9.1 Docker 容器化實踐 9.2 CI/CD 流水線設計 9.3 Kubernetes 部署策略 9.4 基礎設施即代碼 9.5 監控與日誌聚合 微服務架構 10.1 微服務設計原則 10.2 服務間通信 10.3 分散式事務處理 10.4 服務發現與負載均衡 10.5 API Gateway 設計 版本控制 11.1 Git 工作流程規範 11.2 提交訊息規範 11.3 代碼審查流程 11.4 分支保護和自動化 11.5 版本標記和發布 11.6 協作最佳實踐 11.7 版本控制檢查清單 最佳實踐總結 12.1 開發生命週期最佳實踐 12.2 程式碼品質標準 12.3 測試策略總覽 12.4 效能監控最佳實踐 12.5 部署和運維最佳實踐 12.6 持續改進流程 12.7 團隊協作指南 12.8 總結與展望 前言 本指引旨在幫助開發團隊撰寫高品質、可維護且安全的程式碼。無論您是剛入行的新進開發人員，還是經驗豐富的資深工程師，都可以透過這份指引提升程式設計技能，並確保專案的長期成功。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%A8%8B%E5%BC%8F%E5%AF%AB%E4%BD%9C%E6%8C%87%E5%BC%95/","summary":"程式寫作指引 目錄 前言 程式碼風格與命名規範 1.1 Java 命名規範 1.2 TypeScript/JavaScript 命名規範 1.3 程式碼格式化 1.4 實務案例與注意事項 註解與文件撰寫 2.1 JavaDoc 註解規範 2.2 TypeScript JSDoc 註解 2.3 程式碼內註解最佳實踐 2.4 API 文件撰寫 2.5 Vue 元件註解 2.6 實務案例與注意事項 錯誤處理與日誌紀錄 3.1 例外處理最佳實踐 3.2 日誌記錄最佳實踐 3.3 監控與告警設定 3.4 實務案例與注意事項 單元測試與TDD 4.1 JUnit 5 測試規範 4.2 TypeScript/Jest 測試規範 4.3 測試驅動開發（TDD）流程 4.4 測試覆蓋率與品質指標 4.5 實務案例與注意事項 安全性考量 5.1 輸入驗證與資料清理 5.2 認證和授權 5.3 XSS 攻擊防護 5.4 CSRF 攻擊防護 5.5 敏感資料處理 5.6 安全標頭配置 Spring Boot 常用功能實踐 6.1 JWT (JSON Web Token) 認證授權 6.2 Spring Data JPA 最佳實踐 6.3 Spring Batch 批次處理 6.4 Spring Cache 快取管理 6.5 Spring Boot 配置管理 資料庫設計與操作 7.1 資料庫設計原則 7.2 SQL 查詢優化 7.3 事務管理 7.4 資料遷移策略 7.5 資料庫監控與維護 效能優化 8.1 Java 應用程式效能優化 8.2 Spring Boot 效能調優 8.3 前端效能優化 8.4 快取策略優化 8.5 監控和指標 8.6 效能測試 8.7 效能優化檢查清單 容器化與DevOps 9.1 Docker 容器化實踐 9.2 CI/CD 流水線設計 9.3 Kubernetes 部署策略 9.4 基礎設施即代碼 9.5 監控與日誌聚合 微服務架構 10.1 微服務設計原則 10.2 服務間通信 10.3 分散式事務處理 10.4 服務發現與負載均衡 10.5 API Gateway 設計 版本控制 11.1 Git 工作流程規範 11.2 提交訊息規範 11.3 代碼審查流程 11.4 分支保護和自動化 11.5 版本標記和發布 11.6 協作最佳實踐 11.7 版本控制檢查清單 最佳實踐總結 12.1 開發生命週期最佳實踐 12.2 程式碼品質標準 12.3 測試策略總覽 12.4 效能監控最佳實踐 12.5 部署和運維最佳實踐 12.6 持續改進流程 12.7 團隊協作指南 12.8 總結與展望 前言 本指引旨在幫助開發團隊撰寫高品質、可維護且安全的程式碼。無論您是剛入行的新進開發人員，還是經驗豐富的資深工程師，都可以透過這份指引提升程式設計技能，並確保專案的長期成功。\n","title":"程式寫作指引"},{"content":"專案系統分析指引 目錄 系統分析階段目標與產出物 需求收集與分析流程 涉及角色與職責 系統分析方法與工具 4.1 UML 建模方法 4.2 資料流程圖 (DFD) 4.3 實體關係圖 (ERD) 4.4 物件導向分析方法 (OOA) 4.5 狀態圖 4.6 分析模型整合 跨系統整合分析 安全與合規考量 版本控管與審核流程 範例與模板 8.1 需求規格書模板 8.2 用例描述表模板 8.3 物件導向分析模板 8.4 系統功能列表模板 8.5 需求變更申請表模板 總結與最佳實踐 敏捷開發環境下的系統分析 數據驅動的需求分析 雲端架構考量 國際化與在地化需求 效能與容量規劃 災難恢復與營運連續性 附錄 文件資訊 文件名稱：專案系統分析指引 版本：2.0 建立日期：2025年8月11日 最後更新：2025年8月29日 適用專案：大型共用平台系統 技術架構：前後端分離 + Clean Architecture + 雲端原生 1. 系統分析階段目標與產出物 1.1 階段目標 系統分析階段是軟體開發生命週期中的關鍵環節，主要目標包括：\n需求理解與定義：深入理解業務需求，並將其轉化為明確的系統需求 系統邊界確立：明確定義系統的範圍、功能邊界與非功能需求 風險識別與評估：識別技術風險、業務風險及安全風險 可行性分析：評估技術可行性、經濟可行性與時程可行性 架構規劃基礎：為後續的系統設計階段提供清晰的需求基礎 1.2 工作範圍 1.2.1 業務分析範圍 現有系統分析與問題識別 業務流程梳理與優化建議 利害關係人需求收集 業務規則定義與驗證 使用者體驗需求分析 1.2.2 技術分析範圍 系統功能需求分析 非功能需求定義（效能、安全、可用性等） 系統整合需求分析 資料流程與資料模型分析 介面需求定義 1.2.3 安全分析範圍 威脅建模與風險評估 安全需求定義 合規要求分析 資料保護需求 存取控制需求 1.3 主要產出物清單 1.3.1 需求文件 業務需求規格書 (Business Requirements Specification, BRS) 系統需求規格書 (System Requirements Specification, SRS) 功能需求規格書 (Functional Requirements Specification, FRS) 非功能需求規格書 (Non-Functional Requirements Specification, NFRS) 使用者需求文件 (User Requirements Document, URD) 1.3.2 分析模型與圖表 用例圖 (Use Case Diagrams) 用例描述表 (Use Case Specifications) 業務流程圖 (Business Process Diagrams) 資料流程圖 (Data Flow Diagrams, DFD) 實體關係圖 (Entity Relationship Diagrams, ERD) 狀態圖 (State Diagrams) 活動圖 (Activity Diagrams) 循序圖 (Sequence Diagrams) 1.3.3 整合與介面文件 系統整合需求規格書 (System Integration Requirements) API 需求規格書 (API Requirements Specification) 批次處理需求規格書 (Batch Processing Requirements) 資料交換格式定義 (Data Exchange Format Specification) 外部系統介面規格 (External System Interface Specification) 1.3.4 安全與合規文件 安全需求規格書 (Security Requirements Specification) 威脅模型文件 (Threat Model Document) 風險評估報告 (Risk Assessment Report) 合規檢查清單 (Compliance Checklist) 資料保護影響評估 (Data Protection Impact Assessment, DPIA) 1.3.5 測試相關文件 測試需求規格書 (Test Requirements Specification) 驗收標準定義 (Acceptance Criteria Definition) 測試案例大綱 (Test Case Outline) 1.3.6 專案管理文件 需求追蹤矩陣 (Requirements Traceability Matrix, RTM) 變更控制文件 (Change Control Document) 需求優先級矩陣 (Requirements Priority Matrix) 影響分析報告 (Impact Analysis Report) 2. 需求收集與分析流程 2.1 需求收集流程 2.1.1 準備階段 flowchart TD A[專案啟動] --\u0026gt; B[組建分析團隊] B --\u0026gt; C[制定分析計劃] C --\u0026gt; D[識別利害關係人] D --\u0026gt; E[準備訪談資料] E --\u0026gt; F[安排訪談時程] 主要活動：\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E6%8C%87%E5%BC%95/","summary":"專案系統分析指引 目錄 系統分析階段目標與產出物 需求收集與分析流程 涉及角色與職責 系統分析方法與工具 4.1 UML 建模方法 4.2 資料流程圖 (DFD) 4.3 實體關係圖 (ERD) 4.4 物件導向分析方法 (OOA) 4.5 狀態圖 4.6 分析模型整合 跨系統整合分析 安全與合規考量 版本控管與審核流程 範例與模板 8.1 需求規格書模板 8.2 用例描述表模板 8.3 物件導向分析模板 8.4 系統功能列表模板 8.5 需求變更申請表模板 總結與最佳實踐 敏捷開發環境下的系統分析 數據驅動的需求分析 雲端架構考量 國際化與在地化需求 效能與容量規劃 災難恢復與營運連續性 附錄 文件資訊 文件名稱：專案系統分析指引 版本：2.0 建立日期：2025年8月11日 最後更新：2025年8月29日 適用專案：大型共用平台系統 技術架構：前後端分離 + Clean Architecture + 雲端原生 1. 系統分析階段目標與產出物 1.1 階段目標 系統分析階段是軟體開發生命週期中的關鍵環節，主要目標包括：\n需求理解與定義：深入理解業務需求，並將其轉化為明確的系統需求 系統邊界確立：明確定義系統的範圍、功能邊界與非功能需求 風險識別與評估：識別技術風險、業務風險及安全風險 可行性分析：評估技術可行性、經濟可行性與時程可行性 架構規劃基礎：為後續的系統設計階段提供清晰的需求基礎 1.2 工作範圍 1.2.1 業務分析範圍 現有系統分析與問題識別 業務流程梳理與優化建議 利害關係人需求收集 業務規則定義與驗證 使用者體驗需求分析 1.2.2 技術分析範圍 系統功能需求分析 非功能需求定義（效能、安全、可用性等） 系統整合需求分析 資料流程與資料模型分析 介面需求定義 1.2.3 安全分析範圍 威脅建模與風險評估 安全需求定義 合規要求分析 資料保護需求 存取控制需求 1.3 主要產出物清單 1.3.1 需求文件 業務需求規格書 (Business Requirements Specification, BRS) 系統需求規格書 (System Requirements Specification, SRS) 功能需求規格書 (Functional Requirements Specification, FRS) 非功能需求規格書 (Non-Functional Requirements Specification, NFRS) 使用者需求文件 (User Requirements Document, URD) 1.3.2 分析模型與圖表 用例圖 (Use Case Diagrams) 用例描述表 (Use Case Specifications) 業務流程圖 (Business Process Diagrams) 資料流程圖 (Data Flow Diagrams, DFD) 實體關係圖 (Entity Relationship Diagrams, ERD) 狀態圖 (State Diagrams) 活動圖 (Activity Diagrams) 循序圖 (Sequence Diagrams) 1.3.3 整合與介面文件 系統整合需求規格書 (System Integration Requirements) API 需求規格書 (API Requirements Specification) 批次處理需求規格書 (Batch Processing Requirements) 資料交換格式定義 (Data Exchange Format Specification) 外部系統介面規格 (External System Interface Specification) 1.3.4 安全與合規文件 安全需求規格書 (Security Requirements Specification) 威脅模型文件 (Threat Model Document) 風險評估報告 (Risk Assessment Report) 合規檢查清單 (Compliance Checklist) 資料保護影響評估 (Data Protection Impact Assessment, DPIA) 1.3.5 測試相關文件 測試需求規格書 (Test Requirements Specification) 驗收標準定義 (Acceptance Criteria Definition) 測試案例大綱 (Test Case Outline) 1.3.6 專案管理文件 需求追蹤矩陣 (Requirements Traceability Matrix, RTM) 變更控制文件 (Change Control Document) 需求優先級矩陣 (Requirements Priority Matrix) 影響分析報告 (Impact Analysis Report) 2. 需求收集與分析流程 2.1 需求收集流程 2.1.1 準備階段 flowchart TD A[專案啟動] --\u0026gt; B[組建分析團隊] B --\u0026gt; C[制定分析計劃] C --\u0026gt; D[識別利害關係人] D --\u0026gt; E[準備訪談資料] E --\u0026gt; F[安排訪談時程] 主要活動：\n","title":"系統分析指引"},{"content":"System_Analysis_Phase/ ├── 01_SRS/ # 需求規格文件 │ ├── 01_前言.md │ ├── 02_整體描述.md │ ├── 03_功能性需求.md │ ├── 04_非功能性需求.md │ ├── 05_系統介面需求.md │ └── 附錄_名詞解釋_參考資料.md │ ├── 02_Use_Case/ # 使用案例文件 │ ├── 00_使用案例總覽圖.png │ ├── UC01_名稱_使用案例說明.md │ ├── UC02_名稱_使用案例說明.md │ ├── UCxx_\u0026hellip;md │ ├── 使用案例活動圖/ # Activity Diagrams │ │ ├── UC01_活動圖.png │ │ └── UC02_活動圖.png │ └── 使用案例需求對應表.xlsx │ ├── 03_System_Model/ # 系統模型 (UML) │ ├── Object_Model/ # 物件模型 │ │ ├── 類別圖_ClassDiagram.png │ │ └── 物件圖_ObjectDiagram.png │ ├── Interaction_Model/ # 互動模型 │ │ ├── UC01_序列圖_Sequence.png │ │ ├── UC02_序列圖_Sequence.png │ │ └── 通訊圖_Communication.png │ ├── State_Model/ # 狀態模型 │ │ ├── ClassA_狀態圖.png │ │ └── ClassB_狀態圖.png │ └── Supplementary_Model/ # 補充模型 │ ├── 組件圖_Component.png │ └── 部署圖_Deployment.png │ ├── 04_Data_Model/ # 資料模型 │ ├── ER_Model.png │ ├── Class_Table_Mapping.xlsx │ └── Data_Dictionary.xlsx │ ├── 05_RTM/ # 需求追蹤矩陣 │ └── Requirement_Traceability_Matrix.xlsx │ ├── 06_Validation_Review/ # 驗證與審查 │ ├── 需求審查會議紀錄.md │ ├── 問題清單與解決狀態.xlsx │ └── 需求基線確認_Baseline_Approval.pdf │ └── README.md # 系統分析階段文件總覽\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E6%96%87%E4%BB%B6%E7%9B%AE%E9%8C%84%E7%AF%84%E4%BE%8B/","summary":"System_Analysis_Phase/ ├── 01_SRS/ # 需求規格文件 │ ├── 01_前言.md │ ├── 02_整體描述.md │ ├── 03_功能性需求.md │ ├── 04_非功能性需求.md │ ├── 05_系統介面需求.md │ └── 附錄_名詞解釋_參考資料.md │ ├── 02_Use_Case/ # 使用案例文件 │ ├── 00_使用案例總覽圖.png │ ├── UC01_名稱_使用案例說明.md │ ├── UC02_名稱_使用案例說明.md │ ├── UCxx_\u0026hellip;md │ ├── 使用案例活動圖/ # Activity Diagrams │ │ ├── UC01_活動圖.png │ │ └── UC02_活動圖.png │ └── 使用案例需求對應表.xlsx │ ├── 03_System_Model/ # 系統模型 (UML) │ ├── Object_Model/ # 物件模型 │ │ ├── 類別圖_ClassDiagram.png │ │ └── 物件圖_ObjectDiagram.png │ ├── Interaction_Model/ # 互動模型 │ │ ├── UC01_序列圖_Sequence.png │ │ ├── UC02_序列圖_Sequence.png │ │ └── 通訊圖_Communication.png │ ├── State_Model/ # 狀態模型 │ │ ├── ClassA_狀態圖.png │ │ └── ClassB_狀態圖.png │ └── Supplementary_Model/ # 補充模型 │ ├── 組件圖_Component.png │ └── 部署圖_Deployment.png │ ├── 04_Data_Model/ # 資料模型 │ ├── ER_Model.png │ ├── Class_Table_Mapping.xlsx │ └── Data_Dictionary.xlsx │ ├── 05_RTM/ # 需求追蹤矩陣 │ └── Requirement_Traceability_Matrix.xlsx │ ├── 06_Validation_Review/ # 驗證與審查 │ ├── 需求審查會議紀錄.md │ ├── 問題清單與解決狀態.xlsx │ └── 需求基線確認_Baseline_Approval.pdf │ └── README.md # 系統分析階段文件總覽\n","title":"系統分析階段標準文件目錄範例"},{"content":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄建議：\n前言 1.1 文件目的 1.2 系統範疇與邊界 1.3 定義、縮寫與名詞解釋 1.4 文件參考資料\n整體描述 2.1 系統目標 2.2 系統使用者與利害關係人 2.3 作業環境 (硬體/軟體/網路/外部系統) 2.4 假設與限制\n功能性需求\n按使用案例或模組分項列出需求 非功能性需求\n效能需求 (Response Time, Throughput) 安全性需求 (Authentication, Authorization, Audit) 可用性 / 擴充性需求 法規/合規性需求 系統介面需求\n外部系統介接規格 API / 資料交換格式 2️⃣ 使用案例文件 (Use Case Specification) 目錄建議：\n使用案例總覽 (Use Case Diagram)\n使用案例清單\nUC01：名稱、角色、前置條件、後置條件、主要流程、替代流程、例外情境 UC02 … 使用案例活動圖 (Activity Diagram)\n用案例與需求對應表 (Traceability)\n3️⃣ 系統模型文件 (UML Models)\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AE/","summary":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄建議：\n前言 1.1 文件目的 1.2 系統範疇與邊界 1.3 定義、縮寫與名詞解釋 1.4 文件參考資料\n整體描述 2.1 系統目標 2.2 系統使用者與利害關係人 2.3 作業環境 (硬體/軟體/網路/外部系統) 2.4 假設與限制\n功能性需求\n按使用案例或模組分項列出需求 非功能性需求\n效能需求 (Response Time, Throughput) 安全性需求 (Authentication, Authorization, Audit) 可用性 / 擴充性需求 法規/合規性需求 系統介面需求\n外部系統介接規格 API / 資料交換格式 2️⃣ 使用案例文件 (Use Case Specification) 目錄建議：\n使用案例總覽 (Use Case Diagram)\n使用案例清單\nUC01：名稱、角色、前置條件、後置條件、主要流程、替代流程、例外情境 UC02 … 使用案例活動圖 (Activity Diagram)\n用案例與需求對應表 (Traceability)\n3️⃣ 系統模型文件 (UML Models)\n","title":"系統分析階段標準範本清單"},{"content":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄：\n01_SRS/ ├── 01_前言.md # 文件目的、系統範疇、名詞定義 ├── 02_整體描述.md # 系統目標、利害關係人、作業環境、限制 ├── 03_功能性需求.md # 按模組/使用案例列需求 ├── 04_非功能性需求.md # 效能、安全性、可用性、法規 ├── 05_系統介面需求.md # 外部系統介接、API、資料交換 └── 附錄_參考資料.md\n2️⃣ 使用案例文件 (Use Case Specification)\n目錄：\n02_Use_Case/ ├── 00_使用案例總覽圖.png ├── UC01_名稱_說明.md # 前置條件、後置條件、主要/替代流程 ├── UC02_名稱_說明.md ├── UCxx_\u0026hellip;md ├── 使用案例活動圖/ │ ├── UC01_活動圖.png │ └── UC02_活動圖.png └── 使用案例需求對應表.xlsx\n3️⃣ 系統模型文件 (UML Models)\n目錄：\n03_System_Model/ ├── Object_Model/ # 物件模型 │ ├── 類別圖_ClassDiagram.png │ └── 物件圖_ObjectDiagram.png ├── Interaction_Model/ # 互動模型 │ ├── UC01_序列圖.png │ ├── UC02_序列圖.png │ └── 通訊圖_Communication.png ├── State_Model/ # 狀態模型 │ ├── ClassA_狀態圖.png │ └── ClassB_狀態圖.png └── Supplementary_Model/ # 補充模型 ├── 組件圖_Component.png └── 部署圖_Deployment.png\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AEooa/","summary":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄：\n01_SRS/ ├── 01_前言.md # 文件目的、系統範疇、名詞定義 ├── 02_整體描述.md # 系統目標、利害關係人、作業環境、限制 ├── 03_功能性需求.md # 按模組/使用案例列需求 ├── 04_非功能性需求.md # 效能、安全性、可用性、法規 ├── 05_系統介面需求.md # 外部系統介接、API、資料交換 └── 附錄_參考資料.md\n2️⃣ 使用案例文件 (Use Case Specification)\n目錄：\n02_Use_Case/ ├── 00_使用案例總覽圖.png ├── UC01_名稱_說明.md # 前置條件、後置條件、主要/替代流程 ├── UC02_名稱_說明.md ├── UCxx_\u0026hellip;md ├── 使用案例活動圖/ │ ├── UC01_活動圖.png │ └── UC02_活動圖.png └── 使用案例需求對應表.xlsx\n3️⃣ 系統模型文件 (UML Models)\n目錄：\n03_System_Model/ ├── Object_Model/ # 物件模型 │ ├── 類別圖_ClassDiagram.png │ └── 物件圖_ObjectDiagram.png ├── Interaction_Model/ # 互動模型 │ ├── UC01_序列圖.png │ ├── UC02_序列圖.png │ └── 通訊圖_Communication.png ├── State_Model/ # 狀態模型 │ ├── ClassA_狀態圖.png │ └── ClassB_狀態圖.png └── Supplementary_Model/ # 補充模型 ├── 組件圖_Component.png └── 部署圖_Deployment.png\n","title":"系統分析階段標準範本清單(OOA)"},{"content":"系統架構設計範本 Prompt 目標 指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。\n角色設定 你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的系統架構設計工作。\n專案技術背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬} 效能要求: {填入關鍵效能指標} 技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django} 部署環境: {填入部署方式，如：雲端、地端、混合雲} 架構設計要求 請按照以下結構進行系統架構設計：\n1. 系統概覽 系統邊界定義 主要組件識別 系統上下文圖 利害關係人視圖 2. 架構風格選擇 架構風格評估 設計原則定義 品質屬性分析 技術決策記錄 3. 邏輯架構設計 分層架構設計 組件劃分 介面定義 資料流設計 4. 物理架構設計 部署拓撲 基礎設施規劃 網路設計 安全架構 5. 技術選型 框架和函式庫選擇 資料庫技術選型 中介軟體選擇 工具和平台決策 6. 品質屬性設計 可用性設計 效能最佳化 安全性設計 可維護性考量 輸出格式 # {專案名稱} 系統架構設計文檔 ## 1. 系統概覽 ### 1.1 系統目標 **主要目標:** [系統主要目標描述] **次要目標:** [次要目標列表] **成功標準:** [可測量的成功指標] ### 1.2 系統邊界 **包含範圍:** - [功能模組1] - [功能模組2] - [功能模組3] **排除範圍:** - [不包含的功能1] - [不包含的功能2] ### 1.3 系統上下文圖 [使用者] \u0026ndash;\u0026gt; [系統] \u0026ndash;\u0026gt; [外部系統A] | v [外部系統B]\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%B3%BB%E7%B5%B1%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E7%AF%84%E6%9C%AC/","summary":"系統架構設計範本 Prompt 目標 指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。\n角色設定 你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的系統架構設計工作。\n專案技術背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬} 效能要求: {填入關鍵效能指標} 技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django} 部署環境: {填入部署方式，如：雲端、地端、混合雲} 架構設計要求 請按照以下結構進行系統架構設計：\n1. 系統概覽 系統邊界定義 主要組件識別 系統上下文圖 利害關係人視圖 2. 架構風格選擇 架構風格評估 設計原則定義 品質屬性分析 技術決策記錄 3. 邏輯架構設計 分層架構設計 組件劃分 介面定義 資料流設計 4. 物理架構設計 部署拓撲 基礎設施規劃 網路設計 安全架構 5. 技術選型 框架和函式庫選擇 資料庫技術選型 中介軟體選擇 工具和平台決策 6. 品質屬性設計 可用性設計 效能最佳化 安全性設計 可維護性考量 輸出格式 # {專案名稱} 系統架構設計文檔 ## 1. 系統概覽 ### 1.1 系統目標 **主要目標:** [系統主要目標描述] **次要目標:** [次要目標列表] **成功標準:** [可測量的成功指標] ### 1.2 系統邊界 **包含範圍:** - [功能模組1] - [功能模組2] - [功能模組3] **排除範圍:** - [不包含的功能1] - [不包含的功能2] ### 1.3 系統上下文圖 [使用者] \u0026ndash;\u0026gt; [系統] \u0026ndash;\u0026gt; [外部系統A] | v [外部系統B]\n","title":"系統架構設計範本"},{"content":"專案系統設計指引 文件資訊 文件名稱: 專案系統設計指引 文件版本: v1.1 建立日期: 2025-01-11 更新日期: 2025-08-29 適用範圍: 大型共用平台開發專案 目錄 概述\n1.1 指引目的 1.2 適用範圍 1.3 設計原則 1.4 物件導向設計原則 1.4.1 SOLID 原則 1.4.2 物件導向設計方法論 系統架構設計\n2.1 整體架構概覽 2.2 分層架構設計 2.2.1 前端層架構 2.2.2 後端層架構 (Clean Architecture) 2.2.3 領域驅動設計 (DDD) 架構模式 2.2.4 六角形架構 (Hexagonal Architecture) 2.3 微服務拆分原則 2.4 API Gateway 設計 2.5 CDN 與快取策略 模組與服務設計\n3.1 服務設計原則 3.1.1 單一職責原則 3.1.2 服務自治性 3.1.3 物件導向設計模式應用 3.2 服務間通訊設計 3.3 資料流設計 資料庫設計\n4.1 資料模型設計規範 4.2 多資料庫支援策略 4.2.1 資料庫抽象層 4.2.2 物件關聯映射 (ORM) 設計模式 4.2.3 分庫分表策略 4.3 讀寫分離設計 4.4 資料安全與加密 安全性設計\n5.1 認證與授權機制 5.1.1 OAuth 2.0 + OpenID Connect 整合 5.1.2 JWT Token 設計 5.1.3 RBAC (Role-Based Access Control) 設計 5.1.4 安全設計模式 5.2 API 安全設計 5.3 OWASP Top 10 防護策略 整合與介接設計\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"專案系統設計指引 文件資訊 文件名稱: 專案系統設計指引 文件版本: v1.1 建立日期: 2025-01-11 更新日期: 2025-08-29 適用範圍: 大型共用平台開發專案 目錄 概述\n1.1 指引目的 1.2 適用範圍 1.3 設計原則 1.4 物件導向設計原則 1.4.1 SOLID 原則 1.4.2 物件導向設計方法論 系統架構設計\n2.1 整體架構概覽 2.2 分層架構設計 2.2.1 前端層架構 2.2.2 後端層架構 (Clean Architecture) 2.2.3 領域驅動設計 (DDD) 架構模式 2.2.4 六角形架構 (Hexagonal Architecture) 2.3 微服務拆分原則 2.4 API Gateway 設計 2.5 CDN 與快取策略 模組與服務設計\n3.1 服務設計原則 3.1.1 單一職責原則 3.1.2 服務自治性 3.1.3 物件導向設計模式應用 3.2 服務間通訊設計 3.3 資料流設計 資料庫設計\n4.1 資料模型設計規範 4.2 多資料庫支援策略 4.2.1 資料庫抽象層 4.2.2 物件關聯映射 (ORM) 設計模式 4.2.3 分庫分表策略 4.3 讀寫分離設計 4.4 資料安全與加密 安全性設計\n5.1 認證與授權機制 5.1.1 OAuth 2.0 + OpenID Connect 整合 5.1.2 JWT Token 設計 5.1.3 RBAC (Role-Based Access Control) 設計 5.1.4 安全設計模式 5.2 API 安全設計 5.3 OWASP Top 10 防護策略 整合與介接設計\n","title":"系統設計指引"},{"content":"📂 系統設計階段標準範本清單（樹狀結構版）\n文件目錄 (Document Templates) 1.1 系統設計總規劃書 (System Design Document, SDD) 1.2 系統架構設計書 (System Architecture Design) 1.3 資料庫設計書 (Database Design Document, DDD) 1.4 模組設計規格書 (Module Design Specification) 1.5 介面設計規格書 (Interface Design Specification, API/Batch) 1.6 UI/UX 設計文件 (Wireframe, Mockup, Prototype) 1.7 輸入/輸出設計文件 (I/O Design, Report Spec) 1.8 流程設計文件 (DFD, Activity Diagram, Sequence Diagram, State Diagram) 1.9 安全性設計規格書 (Security Design Spec, RBAC/ABAC) 1.10 例外處理/錯誤處理設計書 (Error \u0026amp; Exception Handling Spec) 1.11 批次處理設計文件 (Batch Job Design Spec, Schedule Spec) 1.12 系統整合設計書 (Integration Design, API Gateway, MQ, SFTP) 1.13 測試設計準則 (Test Design Basis, Traceability Matrix)\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AE%E6%A8%B9%E7%8B%80%E7%B5%90%E6%A7%8B%E7%89%88/","summary":"📂 系統設計階段標準範本清單（樹狀結構版）\n文件目錄 (Document Templates) 1.1 系統設計總規劃書 (System Design Document, SDD) 1.2 系統架構設計書 (System Architecture Design) 1.3 資料庫設計書 (Database Design Document, DDD) 1.4 模組設計規格書 (Module Design Specification) 1.5 介面設計規格書 (Interface Design Specification, API/Batch) 1.6 UI/UX 設計文件 (Wireframe, Mockup, Prototype) 1.7 輸入/輸出設計文件 (I/O Design, Report Spec) 1.8 流程設計文件 (DFD, Activity Diagram, Sequence Diagram, State Diagram) 1.9 安全性設計規格書 (Security Design Spec, RBAC/ABAC) 1.10 例外處理/錯誤處理設計書 (Error \u0026amp; Exception Handling Spec) 1.11 批次處理設計文件 (Batch Job Design Spec, Schedule Spec) 1.12 系統整合設計書 (Integration Design, API Gateway, MQ, SFTP) 1.13 測試設計準則 (Test Design Basis, Traceability Matrix)\n","title":"系統設計階段標準範本清單（樹狀結構版）"},{"content":"系統設計階段標準範本清單OOD（含文件目錄、流程、工作項目） 文件目錄 (Deliverables) 系統設計總覽文件 (System Design Specification, SDS) 設計目標與範疇 架構原則與設計考量 系統邊界與外部介面 架構設計文件 (Architecture Design Document, ADD) 系統整體架構圖 (Logical / Physical) 分層架構 (Layered Architecture) 模組/子系統劃分與責任定義 技術棧與設計決策紀錄 (ADR) 資料設計文件 (Data Design Document, DDD) 資料模型 (ERD) 類別圖 (Class Diagram) 資料表設計與正規化說明 交易與一致性設計 物件導向設計文件 (Object-Oriented Design Document) 類別與責任 (CRC 卡片) 類別圖 / 物件圖 繼承、多型設計 設計模式應用 介面設計文件 (Interface Design Specification, IDS) API 設計 (REST/GraphQL) 資料交換格式 (JSON, XML) UI/UX Wireframe、螢幕設計稿 流程與行為設計文件 (Behavioral Design Specification) Use Case Realization Sequence Diagram State Diagram Activity Diagram 安全設計文件 (Security Design Document) 認證與授權設計 資料加密與存取控制 威脅模型 (Threat Modeling) 基礎設施與部署設計文件 (Deployment Design) 系統拓撲圖 伺服器/容器配置 CI/CD 流程設計 系統設計流程 (Workflow, OOD) 輸入：系統分析成果 (SRS, Use Case, 需求模型)\n","permalink":"https://chihhung.github.io/Blog/posts/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AEood%E5%90%AB%E6%96%87%E4%BB%B6%E7%9B%AE%E9%8C%84%E6%B5%81%E7%A8%8B%E5%B7%A5%E4%BD%9C%E9%A0%85%E7%9B%AE/","summary":"系統設計階段標準範本清單OOD（含文件目錄、流程、工作項目） 文件目錄 (Deliverables) 系統設計總覽文件 (System Design Specification, SDS) 設計目標與範疇 架構原則與設計考量 系統邊界與外部介面 架構設計文件 (Architecture Design Document, ADD) 系統整體架構圖 (Logical / Physical) 分層架構 (Layered Architecture) 模組/子系統劃分與責任定義 技術棧與設計決策紀錄 (ADR) 資料設計文件 (Data Design Document, DDD) 資料模型 (ERD) 類別圖 (Class Diagram) 資料表設計與正規化說明 交易與一致性設計 物件導向設計文件 (Object-Oriented Design Document) 類別與責任 (CRC 卡片) 類別圖 / 物件圖 繼承、多型設計 設計模式應用 介面設計文件 (Interface Design Specification, IDS) API 設計 (REST/GraphQL) 資料交換格式 (JSON, XML) UI/UX Wireframe、螢幕設計稿 流程與行為設計文件 (Behavioral Design Specification) Use Case Realization Sequence Diagram State Diagram Activity Diagram 安全設計文件 (Security Design Document) 認證與授權設計 資料加密與存取控制 威脅模型 (Threat Modeling) 基礎設施與部署設計文件 (Deployment Design) 系統拓撲圖 伺服器/容器配置 CI/CD 流程設計 系統設計流程 (Workflow, OOD) 輸入：系統分析成果 (SRS, Use Case, 需求模型)\n","title":"系統設計階段標準範本清單OOD（含文件目錄、流程、工作項目）"},{"content":"統一建模語言(UML)教學手冊 目錄 UML 基礎概念\n1.1 什麼是 UML？ 1.2 UML 的用途與價值 1.3 UML 圖表分類 1.4 實務注意事項 常用 UML 圖表教學\n2.1 用例圖（Use Case Diagram） 2.2 類別圖（Class Diagram） 2.3 序列圖（Sequence Diagram） 2.4 活動圖（Activity Diagram） 2.5 狀態圖（State Diagram） 2.6 元件圖（Component Diagram） 2.7 部署圖（Deployment Diagram） 實務應用情境\n3.1 專案生命週期中的 UML 應用 3.2 不同專案類型的 UML 選擇 3.3 團隊協作中的 UML 專案實作指引\n4.1 UML 建模流程 4.2 我們專案中的 UML 應用範例 4.3 建模最佳實務 工具介紹\n5.1 常用 UML 工具比較 5.2 PlantUML 詳細介紹 5.3 在我們專案中整合 UML 工具 實務範例：學生管理系統\n6.1 專案背景 6.2 Step-by-Step UML 建模 6.3 架構設計 - 元件圖 6.4 部署建模 - 部署圖 6.5 其他領域實務範例 6.6 跨領域建模經驗總結 認證考試準備\n7.1 OMG UML 認證概述 7.2 考試重點知識 7.3 學習路線圖 7.4 考試技巧 附錄\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E7%B5%B1%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AA%9E%E8%A8%80uml%E6%95%99%E5%AD%B8/","summary":"統一建模語言(UML)教學手冊 目錄 UML 基礎概念\n1.1 什麼是 UML？ 1.2 UML 的用途與價值 1.3 UML 圖表分類 1.4 實務注意事項 常用 UML 圖表教學\n2.1 用例圖（Use Case Diagram） 2.2 類別圖（Class Diagram） 2.3 序列圖（Sequence Diagram） 2.4 活動圖（Activity Diagram） 2.5 狀態圖（State Diagram） 2.6 元件圖（Component Diagram） 2.7 部署圖（Deployment Diagram） 實務應用情境\n3.1 專案生命週期中的 UML 應用 3.2 不同專案類型的 UML 選擇 3.3 團隊協作中的 UML 專案實作指引\n4.1 UML 建模流程 4.2 我們專案中的 UML 應用範例 4.3 建模最佳實務 工具介紹\n5.1 常用 UML 工具比較 5.2 PlantUML 詳細介紹 5.3 在我們專案中整合 UML 工具 實務範例：學生管理系統\n6.1 專案背景 6.2 Step-by-Step UML 建模 6.3 架構設計 - 元件圖 6.4 部署建模 - 部署圖 6.5 其他領域實務範例 6.6 跨領域建模經驗總結 認證考試準備\n7.1 OMG UML 認證概述 7.2 考試重點知識 7.3 學習路線圖 7.4 考試技巧 附錄\n","title":"統一建模語言(UML)教學"},{"content":"自動化測試範本 Prompt 目標 指導 AI 建立完整的自動化測試框架，包含各層級的自動化測試實作。\n角色設定 你是一位資深自動化測試工程師，具備豐富的測試框架設計和實作經驗，熟悉各種自動化測試工具和最佳實務。\n任務描述 請協助我為 {專案名稱} 建立完整的自動化測試框架和測試案例。\n專案自動化背景 專案名稱: {填入專案名稱} 應用類型: {填入應用類型，如：Web應用、API服務、微服務} 技術棧: {填入技術棧，如：Spring Boot + React、.NET Core + Angular} 測試目標: {填入自動化測試目標} 現有工具: {填入現有的測試工具和框架} 自動化測試要求 請按照以下結構建立自動化測試：\n1. 測試框架設計 框架架構設計 工具選型評估 專案結構規劃 配置管理設計 2. 單元測試自動化 測試類別設計 Mock 策略規劃 測試資料準備 斷言策略設計 3. 整合測試自動化 API 測試框架 資料庫測試設計 外部服務模擬 契約測試實作 4. UI 測試自動化 Page Object 模式 元素定位策略 測試資料驅動 跨瀏覽器測試 5. CI/CD 整合 測試執行策略 報告生成機制 失敗處理流程 測試結果分析 6. 維護和擴展 測試程式碼品質 框架擴展性設計 效能最佳化 文檔和培訓 輸出格式 # {專案名稱} 自動化測試框架 ## 1. 框架架構設計 ### 1.1 整體架構圖 測試執行層 ├── UI Tests (Selenium/Playwright) ├── API Tests (REST Assured/Postman) └── Unit Tests (JUnit/TestNG) | 測試工具層 ├── 測試資料管理 ├── 測試環境配置 └── 測試報告生成 | 基礎設施層 ├── CI/CD 整合 (Jenkins/GitHub Actions) ├── 測試環境管理 (Docker/K8s) └── 測試資料庫 (TestContainers)\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E6%B8%AC%E8%A9%A6%E9%A9%97%E6%94%B6/%E8%87%AA%E5%8B%95%E5%8C%96%E6%B8%AC%E8%A9%A6%E7%AF%84%E6%9C%AC/","summary":"自動化測試範本 Prompt 目標 指導 AI 建立完整的自動化測試框架，包含各層級的自動化測試實作。\n角色設定 你是一位資深自動化測試工程師，具備豐富的測試框架設計和實作經驗，熟悉各種自動化測試工具和最佳實務。\n任務描述 請協助我為 {專案名稱} 建立完整的自動化測試框架和測試案例。\n專案自動化背景 專案名稱: {填入專案名稱} 應用類型: {填入應用類型，如：Web應用、API服務、微服務} 技術棧: {填入技術棧，如：Spring Boot + React、.NET Core + Angular} 測試目標: {填入自動化測試目標} 現有工具: {填入現有的測試工具和框架} 自動化測試要求 請按照以下結構建立自動化測試：\n1. 測試框架設計 框架架構設計 工具選型評估 專案結構規劃 配置管理設計 2. 單元測試自動化 測試類別設計 Mock 策略規劃 測試資料準備 斷言策略設計 3. 整合測試自動化 API 測試框架 資料庫測試設計 外部服務模擬 契約測試實作 4. UI 測試自動化 Page Object 模式 元素定位策略 測試資料驅動 跨瀏覽器測試 5. CI/CD 整合 測試執行策略 報告生成機制 失敗處理流程 測試結果分析 6. 維護和擴展 測試程式碼品質 框架擴展性設計 效能最佳化 文檔和培訓 輸出格式 # {專案名稱} 自動化測試框架 ## 1. 框架架構設計 ### 1.1 整體架構圖 測試執行層 ├── UI Tests (Selenium/Playwright) ├── API Tests (REST Assured/Postman) └── Unit Tests (JUnit/TestNG) | 測試工具層 ├── 測試資料管理 ├── 測試環境配置 └── 測試報告生成 | 基礎設施層 ├── CI/CD 整合 (Jenkins/GitHub Actions) ├── 測試環境管理 (Docker/K8s) └── 測試資料庫 (TestContainers)\n","title":"自動化測試範本"},{"content":"設計指引範本 Prompt 目標 指導 AI 進行軟體設計，建立符合設計原則、易於維護且可擴展的軟體設計。\n角色設定 你是一位資深軟體設計師，具備豐富的軟體設計經驗，熟悉設計模式、SOLID 原則和軟體工程最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 設計範圍: {填入設計範圍，如：核心模組、特定功能} 技術棧: {填入使用的技術棧} 設計約束: {填入設計限制和約束} 品質要求: {填入品質屬性要求} 設計要求 請按照以下結構進行設計：\n1. 領域建模 核心領域識別 實體和值物件設計 聚合設計 領域服務設計 2. 架構設計 分層架構設計 模組劃分 依賴關係設計 介面設計 3. 詳細設計 類別設計 方法設計 資料結構設計 演算法設計 4. 設計模式應用 創建型模式 結構型模式 行為型模式 架構模式 5. 設計原則遵循 SOLID 原則 DRY 原則 KISS 原則 YAGNI 原則 輸出格式 # {專案名稱} 軟體設計文件 ## 1. 設計概述 ### 1.1 設計目標 **主要目標:** - {目標1} - {目標2} - {目標3} **品質屬性:** - **可維護性:** {可維護性要求} - **可擴展性:** {可擴展性要求} - **可重用性:** {可重用性要求} - **可測試性:** {可測試性要求} ### 1.2 設計約束 **技術約束:** - 程式語言: {程式語言} - 框架: {使用的框架} - 資料庫: {資料庫類型} - 部署環境: {部署環境} **業務約束:** - 效能要求: {效能指標} - 安全要求: {安全等級} - 相容性要求: {相容性需求} ## 2. 領域建模 ### 2.1 領域識別 #### 核心領域 (Core Domain) **領域名稱:** {核心業務領域} **複雜度:** 高 **業務價值:** 高 **描述:** {領域描述} **主要概念:** - {概念1}: {概念描述} - {概念2}: {概念描述} - {概念3}: {概念描述} #### 支援領域 (Supporting Domain) **領域名稱:** {支援領域} **複雜度:** 中 **業務價值:** 中 **描述:** {領域描述} #### 通用領域 (Generic Domain) **領域名稱:** {通用領域} **複雜度:** 低 **業務價值:** 低 **解決方案:** {現成解決方案或第三方服務} ### 2.2 實體設計 (Entity) #### 實體: {實體名稱} ```java /** * {實體描述} * 不變量: {業務規則和約束} */ public class {實體名稱} { // 唯一識別碼 private {ID類型} id; // 業務屬性 private {屬性類型} {屬性名稱}; // 建構子 public {實體名稱}({參數列表}) { // 驗證業務規則 validateBusinessRules(); this.{屬性} = {值}; } // 業務方法 public {返回類型} {業務方法名稱}({參數列表}) { // 業務邏輯實作 return {結果}; } // 不變量驗證 private void validateBusinessRules() { if ({條件}) { throw new {例外類型}(\u0026#34;{錯誤訊息}\u0026#34;); } } // equals 和 hashCode 基於 ID @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {實體名稱})) return false; {實體名稱} other = ({實體名稱}) obj; return Objects.equals(id, other.id); } @Override public int hashCode() { return Objects.hash(id); } } 2.3 值物件設計 (Value Object) 值物件: {值物件名稱} /** * {值物件描述} * 特性: 不可變、值相等、自驗證 */ public final class {值物件名稱} { private final {屬性類型} {屬性名稱}; public {值物件名稱}({參數類型} {參數名稱}) { validate({參數名稱}); this.{屬性名稱} = {參數名稱}; } public {屬性類型} get{屬性名稱}() { return {屬性名稱}; } private void validate({參數類型} value) { if ({驗證條件}) { throw new IllegalArgumentException(\u0026#34;{錯誤訊息}\u0026#34;); } } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {值物件名稱})) return false; {值物件名稱} other = ({值物件名稱}) obj; return Objects.equals({屬性名稱}, other.{屬性名稱}); } @Override public int hashCode() { return Objects.hash({屬性名稱}); } @Override public String toString() { return \u0026#34;{值物件名稱}{\u0026#34; \u0026#43; \u0026#34;{屬性名稱}=\u0026#34; \u0026#43; {屬性名稱} \u0026#43; \u0026#39;}\u0026#39;; } } 2.4 聚合設計 (Aggregate) 聚合: {聚合名稱} /** * {聚合描述} * 聚合根: {聚合根實體} * 邊界: {聚合邊界說明} */ public class {聚合名稱} { // 聚合根 private {實體類型} {聚合根}; // 聚合內實體 private List\u0026lt;{實體類型}\u0026gt; {內部實體列表}; // 聚合建構 public {聚合名稱}({參數列表}) { this.{聚合根} = new {實體類型}({參數}); this.{內部實體列表} = new ArrayList\u0026lt;\u0026gt;(); } // 業務操作 public void {業務操作名稱}({參數列表}) { // 驗證聚合不變量 validateAggregateInvariants(); // 執行業務邏輯 {聚合根}.{業務方法}({參數}); // 發布領域事件 publishDomainEvent(new {事件類型}({事件資料})); } // 聚合不變量驗證 private void validateAggregateInvariants() { if ({不變量條件}) { throw new {例外類型}(\u0026#34;{違反不變量訊息}\u0026#34;); } } // 取得聚合根 ID public {ID類型} getId() { return {聚合根}.getId(); } } 2.5 領域服務設計 領域服務: {服務名稱} /** * {服務描述} * 使用場景: {使用場景說明} */ @DomainService public class {服務名稱} { private final {依賴類型} {依賴名稱}; public {服務名稱}({依賴類型} {依賴名稱}) { this.{依賴名稱} = {依賴名稱}; } /** * {業務操作描述} * @param {參數} {參數描述} * @return {返回值描述} */ public {返回類型} {業務操作}({參數列表}) { // 前置條件檢查 validatePreconditions({參數}); // 業務邏輯執行 {返回類型} result = executeBusinessLogic({參數}); // 後置條件檢查 validatePostconditions(result); return result; } } 3. 架構設計 3.1 分層架構 四層架構設計 ┌─────────────────────────────────────┐ │ 展示層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘ 展示層 (Presentation Layer) 職責:\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"設計指引範本 Prompt 目標 指導 AI 進行軟體設計，建立符合設計原則、易於維護且可擴展的軟體設計。\n角色設定 你是一位資深軟體設計師，具備豐富的軟體設計經驗，熟悉設計模式、SOLID 原則和軟體工程最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 設計範圍: {填入設計範圍，如：核心模組、特定功能} 技術棧: {填入使用的技術棧} 設計約束: {填入設計限制和約束} 品質要求: {填入品質屬性要求} 設計要求 請按照以下結構進行設計：\n1. 領域建模 核心領域識別 實體和值物件設計 聚合設計 領域服務設計 2. 架構設計 分層架構設計 模組劃分 依賴關係設計 介面設計 3. 詳細設計 類別設計 方法設計 資料結構設計 演算法設計 4. 設計模式應用 創建型模式 結構型模式 行為型模式 架構模式 5. 設計原則遵循 SOLID 原則 DRY 原則 KISS 原則 YAGNI 原則 輸出格式 # {專案名稱} 軟體設計文件 ## 1. 設計概述 ### 1.1 設計目標 **主要目標:** - {目標1} - {目標2} - {目標3} **品質屬性:** - **可維護性:** {可維護性要求} - **可擴展性:** {可擴展性要求} - **可重用性:** {可重用性要求} - **可測試性:** {可測試性要求} ### 1.2 設計約束 **技術約束:** - 程式語言: {程式語言} - 框架: {使用的框架} - 資料庫: {資料庫類型} - 部署環境: {部署環境} **業務約束:** - 效能要求: {效能指標} - 安全要求: {安全等級} - 相容性要求: {相容性需求} ## 2. 領域建模 ### 2.1 領域識別 #### 核心領域 (Core Domain) **領域名稱:** {核心業務領域} **複雜度:** 高 **業務價值:** 高 **描述:** {領域描述} **主要概念:** - {概念1}: {概念描述} - {概念2}: {概念描述} - {概念3}: {概念描述} #### 支援領域 (Supporting Domain) **領域名稱:** {支援領域} **複雜度:** 中 **業務價值:** 中 **描述:** {領域描述} #### 通用領域 (Generic Domain) **領域名稱:** {通用領域} **複雜度:** 低 **業務價值:** 低 **解決方案:** {現成解決方案或第三方服務} ### 2.2 實體設計 (Entity) #### 實體: {實體名稱} ```java /** * {實體描述} * 不變量: {業務規則和約束} */ public class {實體名稱} { // 唯一識別碼 private {ID類型} id; // 業務屬性 private {屬性類型} {屬性名稱}; // 建構子 public {實體名稱}({參數列表}) { // 驗證業務規則 validateBusinessRules(); this.{屬性} = {值}; } // 業務方法 public {返回類型} {業務方法名稱}({參數列表}) { // 業務邏輯實作 return {結果}; } // 不變量驗證 private void validateBusinessRules() { if ({條件}) { throw new {例外類型}(\u0026#34;{錯誤訊息}\u0026#34;); } } // equals 和 hashCode 基於 ID @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {實體名稱})) return false; {實體名稱} other = ({實體名稱}) obj; return Objects.equals(id, other.id); } @Override public int hashCode() { return Objects.hash(id); } } 2.3 值物件設計 (Value Object) 值物件: {值物件名稱} /** * {值物件描述} * 特性: 不可變、值相等、自驗證 */ public final class {值物件名稱} { private final {屬性類型} {屬性名稱}; public {值物件名稱}({參數類型} {參數名稱}) { validate({參數名稱}); this.{屬性名稱} = {參數名稱}; } public {屬性類型} get{屬性名稱}() { return {屬性名稱}; } private void validate({參數類型} value) { if ({驗證條件}) { throw new IllegalArgumentException(\u0026#34;{錯誤訊息}\u0026#34;); } } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {值物件名稱})) return false; {值物件名稱} other = ({值物件名稱}) obj; return Objects.equals({屬性名稱}, other.{屬性名稱}); } @Override public int hashCode() { return Objects.hash({屬性名稱}); } @Override public String toString() { return \u0026#34;{值物件名稱}{\u0026#34; \u0026#43; \u0026#34;{屬性名稱}=\u0026#34; \u0026#43; {屬性名稱} \u0026#43; \u0026#39;}\u0026#39;; } } 2.4 聚合設計 (Aggregate) 聚合: {聚合名稱} /** * {聚合描述} * 聚合根: {聚合根實體} * 邊界: {聚合邊界說明} */ public class {聚合名稱} { // 聚合根 private {實體類型} {聚合根}; // 聚合內實體 private List\u0026lt;{實體類型}\u0026gt; {內部實體列表}; // 聚合建構 public {聚合名稱}({參數列表}) { this.{聚合根} = new {實體類型}({參數}); this.{內部實體列表} = new ArrayList\u0026lt;\u0026gt;(); } // 業務操作 public void {業務操作名稱}({參數列表}) { // 驗證聚合不變量 validateAggregateInvariants(); // 執行業務邏輯 {聚合根}.{業務方法}({參數}); // 發布領域事件 publishDomainEvent(new {事件類型}({事件資料})); } // 聚合不變量驗證 private void validateAggregateInvariants() { if ({不變量條件}) { throw new {例外類型}(\u0026#34;{違反不變量訊息}\u0026#34;); } } // 取得聚合根 ID public {ID類型} getId() { return {聚合根}.getId(); } } 2.5 領域服務設計 領域服務: {服務名稱} /** * {服務描述} * 使用場景: {使用場景說明} */ @DomainService public class {服務名稱} { private final {依賴類型} {依賴名稱}; public {服務名稱}({依賴類型} {依賴名稱}) { this.{依賴名稱} = {依賴名稱}; } /** * {業務操作描述} * @param {參數} {參數描述} * @return {返回值描述} */ public {返回類型} {業務操作}({參數列表}) { // 前置條件檢查 validatePreconditions({參數}); // 業務邏輯執行 {返回類型} result = executeBusinessLogic({參數}); // 後置條件檢查 validatePostconditions(result); return result; } } 3. 架構設計 3.1 分層架構 四層架構設計 ┌─────────────────────────────────────┐ │ 展示層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘ 展示層 (Presentation Layer) 職責:\n","title":"設計指引範本"},{"content":"銀行大型共用平台 - 資料庫設計指引 文件資訊 文件名稱: 資料庫設計指引 版本: 2.0 建立日期: 2025-08-11 最後更新: 2025-08-29 作者: 資料庫架構師 適用範圍: 銀行大型共用平台專案 目錄 資料庫命名規範 欄位設計準則 主鍵、外鍵與唯一鍵設計規範 索引策略 資料分區與分表策略 資料庫正規化與反正規化設計 資料安全規範 資料庫版本控管與變更管理方法 性能調校原則與監控方法 資料庫備份與災難復原計劃 資料庫容量規劃 資料庫升級與遷移策略 資料庫日誌管理 資料庫測試與驗證 資料庫文件與註解 資料庫自動化與工具 資料庫監控與維護 資料庫性能測試 資料治理與品質管理 多租戶架構設計 雲端資料庫設計指引 資料庫DevOps實踐 法規遵循與合規要求 資料庫最佳實務總結 結論與未來發展 1. 資料庫命名規範 1.1 資料庫命名規範 原則: 使用英文、數字和底線，避免特殊字元 格式: {系統代碼}_{環境代碼}_DB 範例: BANK_PROD_DB、BANK_TEST_DB、BANK_DEV_DB 1.2 Schema 命名規範 原則: 依據功能模組或業務領域命名 格式: {模組代碼}_{功能代碼} 範例: CORE_ACCOUNT (核心帳戶) LOAN_MGMT (放款管理) RISK_CONTROL (風險控制) AUDIT_LOG (稽核日誌) 1.3 Table 命名規範 原則: 使用單數名詞，英文大寫，底線分隔 格式: {模組前綴}_{業務實體} 範例: ACC_CUSTOMER (客戶資料) LOAN_APPLICATION (放款申請) TXN_JOURNAL (交易日誌) 1.4 Column 命名規範 原則: 英文大寫，底線分隔，含義明確 通用欄位: ID - 主鍵 CREATED_DATE - 建立時間 CREATED_BY - 建立者 UPDATED_DATE - 更新時間 UPDATED_BY - 更新者 VERSION - 版本號 STATUS - 狀態 1.5 Index 命名規範 主鍵索引: PK_{表格名稱} 一般索引: IDX_{表格名稱}_{欄位名稱} 唯一索引: UK_{表格名稱}_{欄位名稱} 外鍵索引: FK_{表格名稱}_{參考表格名稱} 1.6 View 命名規範 格式: V_{模組前綴}_{功能描述} 範例: V_ACC_CUSTOMER_SUMMARY 1.7 Function 命名規範 格式: FN_{模組前綴}_{功能描述} 範例: FN_CORE_CALC_INTEREST 1.8 Trigger 命名規範 格式: TRG_{表格名稱}_{觸發時機}_{動作} 範例: TRG_ACC_CUSTOMER_BEFORE_UPDATE 2. 欄位設計準則 2.1 資料型別選擇原則 2.1.1 數值型別 用途 Oracle DB2 SQL Server PostgreSQL 整數 NUMBER(10) INTEGER INT INTEGER 長整數 NUMBER(19) BIGINT BIGINT BIGINT 金額 NUMBER(15,2) DECIMAL(15,2) DECIMAL(15,2) DECIMAL(15,2) 百分比 NUMBER(5,4) DECIMAL(5,4) DECIMAL(5,4) DECIMAL(5,4) 2.1.2 字串型別 用途 Oracle DB2 SQL Server PostgreSQL 固定長度 CHAR(n) CHAR(n) CHAR(n) CHAR(n) 變動長度 VARCHAR2(n) VARCHAR(n) VARCHAR(n) VARCHAR(n) 大文字 CLOB CLOB TEXT TEXT 2.1.3 日期時間型別 用途 Oracle DB2 SQL Server PostgreSQL 日期 DATE DATE DATE DATE 日期時間 TIMESTAMP TIMESTAMP DATETIME2 TIMESTAMP 時間戳記 TIMESTAMP(6) TIMESTAMP(6) DATETIME2(6) TIMESTAMP(6) 2.2 長度設計標準 客戶姓名: VARCHAR(100) 客戶ID: VARCHAR(20) 帳號: VARCHAR(20) 電話: VARCHAR(20) 地址: VARCHAR(200) 電子郵件: VARCHAR(100) 備註: VARCHAR(500) 2.3 NULL 值設計原則 不允許 NULL 的欄位:\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%B3%87%E6%96%99%E5%BA%AB%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"銀行大型共用平台 - 資料庫設計指引 文件資訊 文件名稱: 資料庫設計指引 版本: 2.0 建立日期: 2025-08-11 最後更新: 2025-08-29 作者: 資料庫架構師 適用範圍: 銀行大型共用平台專案 目錄 資料庫命名規範 欄位設計準則 主鍵、外鍵與唯一鍵設計規範 索引策略 資料分區與分表策略 資料庫正規化與反正規化設計 資料安全規範 資料庫版本控管與變更管理方法 性能調校原則與監控方法 資料庫備份與災難復原計劃 資料庫容量規劃 資料庫升級與遷移策略 資料庫日誌管理 資料庫測試與驗證 資料庫文件與註解 資料庫自動化與工具 資料庫監控與維護 資料庫性能測試 資料治理與品質管理 多租戶架構設計 雲端資料庫設計指引 資料庫DevOps實踐 法規遵循與合規要求 資料庫最佳實務總結 結論與未來發展 1. 資料庫命名規範 1.1 資料庫命名規範 原則: 使用英文、數字和底線，避免特殊字元 格式: {系統代碼}_{環境代碼}_DB 範例: BANK_PROD_DB、BANK_TEST_DB、BANK_DEV_DB 1.2 Schema 命名規範 原則: 依據功能模組或業務領域命名 格式: {模組代碼}_{功能代碼} 範例: CORE_ACCOUNT (核心帳戶) LOAN_MGMT (放款管理) RISK_CONTROL (風險控制) AUDIT_LOG (稽核日誌) 1.3 Table 命名規範 原則: 使用單數名詞，英文大寫，底線分隔 格式: {模組前綴}_{業務實體} 範例: ACC_CUSTOMER (客戶資料) LOAN_APPLICATION (放款申請) TXN_JOURNAL (交易日誌) 1.4 Column 命名規範 原則: 英文大寫，底線分隔，含義明確 通用欄位: ID - 主鍵 CREATED_DATE - 建立時間 CREATED_BY - 建立者 UPDATED_DATE - 更新時間 UPDATED_BY - 更新者 VERSION - 版本號 STATUS - 狀態 1.5 Index 命名規範 主鍵索引: PK_{表格名稱} 一般索引: IDX_{表格名稱}_{欄位名稱} 唯一索引: UK_{表格名稱}_{欄位名稱} 外鍵索引: FK_{表格名稱}_{參考表格名稱} 1.6 View 命名規範 格式: V_{模組前綴}_{功能描述} 範例: V_ACC_CUSTOMER_SUMMARY 1.7 Function 命名規範 格式: FN_{模組前綴}_{功能描述} 範例: FN_CORE_CALC_INTEREST 1.8 Trigger 命名規範 格式: TRG_{表格名稱}_{觸發時機}_{動作} 範例: TRG_ACC_CUSTOMER_BEFORE_UPDATE 2. 欄位設計準則 2.1 資料型別選擇原則 2.1.1 數值型別 用途 Oracle DB2 SQL Server PostgreSQL 整數 NUMBER(10) INTEGER INT INTEGER 長整數 NUMBER(19) BIGINT BIGINT BIGINT 金額 NUMBER(15,2) DECIMAL(15,2) DECIMAL(15,2) DECIMAL(15,2) 百分比 NUMBER(5,4) DECIMAL(5,4) DECIMAL(5,4) DECIMAL(5,4) 2.1.2 字串型別 用途 Oracle DB2 SQL Server PostgreSQL 固定長度 CHAR(n) CHAR(n) CHAR(n) CHAR(n) 變動長度 VARCHAR2(n) VARCHAR(n) VARCHAR(n) VARCHAR(n) 大文字 CLOB CLOB TEXT TEXT 2.1.3 日期時間型別 用途 Oracle DB2 SQL Server PostgreSQL 日期 DATE DATE DATE DATE 日期時間 TIMESTAMP TIMESTAMP DATETIME2 TIMESTAMP 時間戳記 TIMESTAMP(6) TIMESTAMP(6) DATETIME2(6) TIMESTAMP(6) 2.2 長度設計標準 客戶姓名: VARCHAR(100) 客戶ID: VARCHAR(20) 帳號: VARCHAR(20) 電話: VARCHAR(20) 地址: VARCHAR(200) 電子郵件: VARCHAR(100) 備註: VARCHAR(500) 2.3 NULL 值設計原則 不允許 NULL 的欄位:\n","title":"資料庫設計指引"},{"content":"資料庫設計指引範本 Prompt 目標 指導 AI 進行資料庫設計，建立結構化、高效能且可維護的資料庫架構。\n角色設定 你是一位資深資料庫設計師，具備豐富的資料庫設計經驗，熟悉正規化理論、效能優化和資料安全設計。\n任務描述 請協助我完成 {專案名稱} 的資料庫設計工作。\n專案資料庫背景 專案名稱: {填入專案名稱} 資料庫類型: {填入資料庫類型，如：MySQL, PostgreSQL, MongoDB} 資料量規模: {填入預估資料量} 併發需求: {填入併發使用者數量} 效能要求: {填入效能指標} 可用性要求: {填入可用性需求} 資料庫設計要求 請按照以下結構進行設計：\n1. 概念模型設計 實體識別 屬性定義 關係建立 業務規則定義 2. 邏輯模型設計 正規化設計 資料類型選擇 約束條件定義 索引策略規劃 3. 實體模型設計 表格結構設計 主鍵和外鍵設計 觸發器和預存程序 權限和安全設計 4. 效能優化設計 索引最佳化 查詢優化 分割策略 快取策略 5. 資料安全設計 存取控制 資料加密 稽核記錄 備份恢復 輸出格式 # {專案名稱} 資料庫設計文件 ## 1. 資料庫概述 ### 1.1 設計目標 **功能目標:** - 支援 {具體業務功能} - 處理 {資料處理需求} - 提供 {資料服務能力} **效能目標:** - 查詢響應時間: \u0026lt; {時間閾值} - 併發處理能力: {併發數量} - 資料處理量: {處理量指標} - 可用性: {可用性百分比} ### 1.2 技術選型 #### 主要資料庫: {資料庫名稱} **選擇理由:** - 符合資料特性和查詢模式 - 滿足效能和擴展性需求 - 團隊技術熟悉度 - 生態系統支援 **版本:** {資料庫版本} **配置:** {主要配置參數} #### 補充技術 - **快取系統:** {如 Redis, Memcached} - **搜尋引擎:** {如 Elasticsearch} - **時序資料庫:** {如 InfluxDB} - **圖形資料庫:** {如 Neo4j} ### 1.3 資料庫架構 #### 整體架構圖 ```mermaid graph TB App[應用程式] --\u0026gt; Pool[連線池] Pool --\u0026gt; Master[主資料庫] Pool --\u0026gt; Slave1[從資料庫1] Pool --\u0026gt; Slave2[從資料庫2] Master --\u0026gt; Replication[主從複製] Replication --\u0026gt; Slave1 Replication --\u0026gt; Slave2 App --\u0026gt; Cache[快取層] Cache --\u0026gt; Redis[Redis 叢集] Master --\u0026gt; Backup[備份系統] Backup --\u0026gt; S3[雲端儲存] 2. 概念模型設計 2.1 實體識別 核心實體清單 實體1: {實體名稱}\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%B3%87%E6%96%99%E5%BA%AB%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"資料庫設計指引範本 Prompt 目標 指導 AI 進行資料庫設計，建立結構化、高效能且可維護的資料庫架構。\n角色設定 你是一位資深資料庫設計師，具備豐富的資料庫設計經驗，熟悉正規化理論、效能優化和資料安全設計。\n任務描述 請協助我完成 {專案名稱} 的資料庫設計工作。\n專案資料庫背景 專案名稱: {填入專案名稱} 資料庫類型: {填入資料庫類型，如：MySQL, PostgreSQL, MongoDB} 資料量規模: {填入預估資料量} 併發需求: {填入併發使用者數量} 效能要求: {填入效能指標} 可用性要求: {填入可用性需求} 資料庫設計要求 請按照以下結構進行設計：\n1. 概念模型設計 實體識別 屬性定義 關係建立 業務規則定義 2. 邏輯模型設計 正規化設計 資料類型選擇 約束條件定義 索引策略規劃 3. 實體模型設計 表格結構設計 主鍵和外鍵設計 觸發器和預存程序 權限和安全設計 4. 效能優化設計 索引最佳化 查詢優化 分割策略 快取策略 5. 資料安全設計 存取控制 資料加密 稽核記錄 備份恢復 輸出格式 # {專案名稱} 資料庫設計文件 ## 1. 資料庫概述 ### 1.1 設計目標 **功能目標:** - 支援 {具體業務功能} - 處理 {資料處理需求} - 提供 {資料服務能力} **效能目標:** - 查詢響應時間: \u0026lt; {時間閾值} - 併發處理能力: {併發數量} - 資料處理量: {處理量指標} - 可用性: {可用性百分比} ### 1.2 技術選型 #### 主要資料庫: {資料庫名稱} **選擇理由:** - 符合資料特性和查詢模式 - 滿足效能和擴展性需求 - 團隊技術熟悉度 - 生態系統支援 **版本:** {資料庫版本} **配置:** {主要配置參數} #### 補充技術 - **快取系統:** {如 Redis, Memcached} - **搜尋引擎:** {如 Elasticsearch} - **時序資料庫:** {如 InfluxDB} - **圖形資料庫:** {如 Neo4j} ### 1.3 資料庫架構 #### 整體架構圖 ```mermaid graph TB App[應用程式] --\u0026gt; Pool[連線池] Pool --\u0026gt; Master[主資料庫] Pool --\u0026gt; Slave1[從資料庫1] Pool --\u0026gt; Slave2[從資料庫2] Master --\u0026gt; Replication[主從複製] Replication --\u0026gt; Slave1 Replication --\u0026gt; Slave2 App --\u0026gt; Cache[快取層] Cache --\u0026gt; Redis[Redis 叢集] Master --\u0026gt; Backup[備份系統] Backup --\u0026gt; S3[雲端儲存] 2. 概念模型設計 2.1 實體識別 核心實體清單 實體1: {實體名稱}\n","title":"資料庫設計指引範本"},{"content":"資料流程圖 (Data Flow Diagram, DFD) 教學手冊 📋 文件資訊 建立日期: 2025年9月1日 適用對象: 新進專案開發同仁、系統分析初學者 更新版本: v1.1 文件目的: 提供完整的DFD學習指引，從基礎概念到實務應用 🎯 學習路徑建議 初學者路徑 (2-3週) 第1週: 基礎概念建立 - 閱讀第1章：基礎概念 - 閱讀第2章：DFD元素與符號 - 練習：繪製簡單的Context Diagram 第2週: 技能實作 - 閱讀第3章：DFD層次架構 - 閱讀第4章：繪製步驟與方法 - 練習：完成圖書館管理系統案例 第3週: 綜合應用 - 閱讀第6章：練習與案例 - 完成ATM提款系統和訂單管理系統 - 使用第9章檢查清單驗證作品 進階學習者路徑 (1-2週) 第1週: 實務應用 - 快速複習第1-3章基礎概念 - 深入學習第5章：專案實務應用 - 實作中小企業進銷存系統案例 第2週: 專業提升 - 學習第7章：認證準備 - 閱讀第8章：附錄資源 - 準備專業認證考試 團隊領導者路徑 (1週) 重點學習: - 第5.4節：版本控制與變更管理 - 第5.5節：團隊協作與溝通 - 第9章：完整檢查清單 - 建立團隊DFD標準和流程 📚 目錄 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 1.2 DFD的用途與價值 1.3 DFD發展歷史與演進 1.4 在系統分析與程式開發中的角色 2. DFD元素與符號 2.1 外部實體 (External Entity) 2.2 處理程序 (Process) 2.3 資料流 (Data Flow) 2.4 資料儲存 (Data Store) 2.5 符號標準與繪製規範 3. DFD層次架構 3.1 層次概念與原理 3.2 Level 0 - Context Diagram (環境圖) 3.3 Level 1 - 主要功能分解 3.4 Level 2 及更深層次 3.5 分層一致性檢查 3.6 何時停止分解 4. 繪製步驟與方法 4.1 需求蒐集與資料流識別 4.2 系統化繪製流程 4.3 常見錯誤與避免方式 4.4 工具使用與技巧 5. 專案實務應用 5.1 在專案需求分析文件中使用DFD 5.2 讓程式開發與DFD對應 5.3 與ER Model、UML的關聯 5.4 版本控制與變更管理 5.5 團隊協作與溝通 6. 練習與案例 6.1 案例一：ATM提款系統 6.2 案例二：訂單管理系統 6.3 練習題目 6.4 參考解答 7. 認證準備 7.1 國際/業界常見DFD認證介紹 7.2 必考知識點整理 7.3 考試題型與解題策略 7.4 模擬試題 7.5 考試準備策略 8. 附錄 8.1 常用繪圖工具介紹 8.2 進一步學習資源 8.3 業界最佳實務參考 8.4 社群與論壇 9. 檢查清單 9.1 DFD繪製檢查清單 9.2 品質保證檢查清單 9.3 文件品質檢查清單 9.4 團隊協作檢查清單 9.5 快速檢查表 (Quick Checklist) 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 資料流程圖（Data Flow Diagram, DFD） 是一種圖形化建模技術，用來描述資訊系統中資料的流動方向和處理過程。它以視覺化的方式展現系統如何處理資料，從資料的輸入、處理、儲存到輸出的完整流程。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E8%B3%87%E6%96%99%E6%B5%81%E7%A8%8B%E5%9C%96dfd%E6%95%99%E5%AD%B8/","summary":"資料流程圖 (Data Flow Diagram, DFD) 教學手冊 📋 文件資訊 建立日期: 2025年9月1日 適用對象: 新進專案開發同仁、系統分析初學者 更新版本: v1.1 文件目的: 提供完整的DFD學習指引，從基礎概念到實務應用 🎯 學習路徑建議 初學者路徑 (2-3週) 第1週: 基礎概念建立 - 閱讀第1章：基礎概念 - 閱讀第2章：DFD元素與符號 - 練習：繪製簡單的Context Diagram 第2週: 技能實作 - 閱讀第3章：DFD層次架構 - 閱讀第4章：繪製步驟與方法 - 練習：完成圖書館管理系統案例 第3週: 綜合應用 - 閱讀第6章：練習與案例 - 完成ATM提款系統和訂單管理系統 - 使用第9章檢查清單驗證作品 進階學習者路徑 (1-2週) 第1週: 實務應用 - 快速複習第1-3章基礎概念 - 深入學習第5章：專案實務應用 - 實作中小企業進銷存系統案例 第2週: 專業提升 - 學習第7章：認證準備 - 閱讀第8章：附錄資源 - 準備專業認證考試 團隊領導者路徑 (1週) 重點學習: - 第5.4節：版本控制與變更管理 - 第5.5節：團隊協作與溝通 - 第9章：完整檢查清單 - 建立團隊DFD標準和流程 📚 目錄 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 1.2 DFD的用途與價值 1.3 DFD發展歷史與演進 1.4 在系統分析與程式開發中的角色 2. DFD元素與符號 2.1 外部實體 (External Entity) 2.2 處理程序 (Process) 2.3 資料流 (Data Flow) 2.4 資料儲存 (Data Store) 2.5 符號標準與繪製規範 3. DFD層次架構 3.1 層次概念與原理 3.2 Level 0 - Context Diagram (環境圖) 3.3 Level 1 - 主要功能分解 3.4 Level 2 及更深層次 3.5 分層一致性檢查 3.6 何時停止分解 4. 繪製步驟與方法 4.1 需求蒐集與資料流識別 4.2 系統化繪製流程 4.3 常見錯誤與避免方式 4.4 工具使用與技巧 5. 專案實務應用 5.1 在專案需求分析文件中使用DFD 5.2 讓程式開發與DFD對應 5.3 與ER Model、UML的關聯 5.4 版本控制與變更管理 5.5 團隊協作與溝通 6. 練習與案例 6.1 案例一：ATM提款系統 6.2 案例二：訂單管理系統 6.3 練習題目 6.4 參考解答 7. 認證準備 7.1 國際/業界常見DFD認證介紹 7.2 必考知識點整理 7.3 考試題型與解題策略 7.4 模擬試題 7.5 考試準備策略 8. 附錄 8.1 常用繪圖工具介紹 8.2 進一步學習資源 8.3 業界最佳實務參考 8.4 社群與論壇 9. 檢查清單 9.1 DFD繪製檢查清單 9.2 品質保證檢查清單 9.3 文件品質檢查清單 9.4 團隊協作檢查清單 9.5 快速檢查表 (Quick Checklist) 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 資料流程圖（Data Flow Diagram, DFD） 是一種圖形化建模技術，用來描述資訊系統中資料的流動方向和處理過程。它以視覺化的方式展現系統如何處理資料，從資料的輸入、處理、儲存到輸出的完整流程。\n","title":"資料流程圖(DFD)教學"},{"content":"軟體架構設計指引範本 Prompt 目標 指導 AI 進行軟體系統架構設計，建立可擴展、可維護且符合業務需求的技術架構。\n角色設定 你是一位資深軟體架構師，具備豐富的系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體架構設計工作。\n專案架構背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 技術棧: {填入主要技術棧} 預期使用者規模: {填入預估使用者數量} 效能需求: {填入效能指標} 可用性需求: {填入可用性要求} 擴展性需求: {填入擴展性要求} 架構設計要求 請按照以下結構進行設計：\n1. 整體架構設計 系統架構風格選擇 主要組件識別 層級架構設計 部署架構規劃 2. 組件設計 核心組件定義 組件間關係 介面設計 責任分離 3. 資料架構 資料模型設計 資料流設計 儲存策略 快取策略 4. 安全架構 認證和授權 資料安全 通訊安全 威脅建模 5. 效能架構 效能優化策略 負載平衡 快取機制 資源管理 6. 可靠性設計 錯誤處理 容錯機制 監控和日誌 災難恢復 輸出格式 # {專案名稱} 軟體架構設計文件 ## 1. 架構概述 ### 1.1 系統概述 **系統名稱:** {專案名稱} **系統類型:** {系統類型描述} **主要功能:** {核心功能清單} **技術棧:** {使用的技術列表} ### 1.2 架構目標 **品質屬性優先級:** 1. **可用性** - 目標: 99.9% uptime 2. **效能** - 目標: 響應時間 \u0026lt; 200ms 3. **擴展性** - 目標: 支援 10x 使用者增長 4. **安全性** - 目標: 符合 OWASP 安全標準 5. **可維護性** - 目標: 新功能開發週期 \u0026lt; 2週 ### 1.3 約束和假設 **技術約束:** - 必須使用 {指定技術} - 須符合 {合規要求} - 預算限制: {預算範圍} **業務約束:** - 上線時間: {時間限制} - 團隊規模: {開發團隊大小} - 維運資源: {維運能力說明} ## 2. 整體架構設計 ### 2.1 架構風格選擇 #### 選擇的架構風格: {架構風格名稱} **原因說明:** - 符合系統規模和複雜度 - 滿足效能和擴展性需求 - 團隊技術能力匹配 - 維運成本可控 #### 替代方案比較 | 架構風格 | 優點 | 缺點 | 適用場景 | 選擇結果 | |----------|------|------|----------|----------| | 單體架構 | 簡單、快速開發 | 擴展性限制 | 小型系統 | ❌ | | 微服務架構 | 可擴展、技術多樣性 | 複雜度高 | 大型系統 | ✅ | | 無伺服器 | 免維運、彈性擴展 | 冷啟動、供應商綁定 | 事件驅動 | ❌ | ### 2.2 系統架構圖 ```mermaid graph TB User[使用者] --\u0026gt; LB[負載平衡器] LB --\u0026gt; API[API Gateway] API --\u0026gt; Auth[認證服務] API --\u0026gt; BFF[Backend for Frontend] BFF --\u0026gt; UserSvc[使用者服務] BFF --\u0026gt; ProductSvc[產品服務] BFF --\u0026gt; OrderSvc[訂單服務] BFF --\u0026gt; PaymentSvc[支付服務] UserSvc --\u0026gt; UserDB[(使用者資料庫)] ProductSvc --\u0026gt; ProductDB[(產品資料庫)] OrderSvc --\u0026gt; OrderDB[(訂單資料庫)] PaymentSvc --\u0026gt; PaymentDB[(支付資料庫)] OrderSvc --\u0026gt; Queue[訊息佇列] Queue --\u0026gt; EmailSvc[郵件服務] Queue --\u0026gt; NotificationSvc[通知服務] UserSvc --\u0026gt; Cache[Redis 快取] ProductSvc --\u0026gt; Cache UserSvc --\u0026gt; Log[日誌系統] ProductSvc --\u0026gt; Log OrderSvc --\u0026gt; Log PaymentSvc --\u0026gt; Log 2.3 部署架構 環境規劃 開發環境:\n","permalink":"https://chihhung.github.io/Blog/posts/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"軟體架構設計指引範本 Prompt 目標 指導 AI 進行軟體系統架構設計，建立可擴展、可維護且符合業務需求的技術架構。\n角色設定 你是一位資深軟體架構師，具備豐富的系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體架構設計工作。\n專案架構背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 技術棧: {填入主要技術棧} 預期使用者規模: {填入預估使用者數量} 效能需求: {填入效能指標} 可用性需求: {填入可用性要求} 擴展性需求: {填入擴展性要求} 架構設計要求 請按照以下結構進行設計：\n1. 整體架構設計 系統架構風格選擇 主要組件識別 層級架構設計 部署架構規劃 2. 組件設計 核心組件定義 組件間關係 介面設計 責任分離 3. 資料架構 資料模型設計 資料流設計 儲存策略 快取策略 4. 安全架構 認證和授權 資料安全 通訊安全 威脅建模 5. 效能架構 效能優化策略 負載平衡 快取機制 資源管理 6. 可靠性設計 錯誤處理 容錯機制 監控和日誌 災難恢復 輸出格式 # {專案名稱} 軟體架構設計文件 ## 1. 架構概述 ### 1.1 系統概述 **系統名稱:** {專案名稱} **系統類型:** {系統類型描述} **主要功能:** {核心功能清單} **技術棧:** {使用的技術列表} ### 1.2 架構目標 **品質屬性優先級:** 1. **可用性** - 目標: 99.9% uptime 2. **效能** - 目標: 響應時間 \u0026lt; 200ms 3. **擴展性** - 目標: 支援 10x 使用者增長 4. **安全性** - 目標: 符合 OWASP 安全標準 5. **可維護性** - 目標: 新功能開發週期 \u0026lt; 2週 ### 1.3 約束和假設 **技術約束:** - 必須使用 {指定技術} - 須符合 {合規要求} - 預算限制: {預算範圍} **業務約束:** - 上線時間: {時間限制} - 團隊規模: {開發團隊大小} - 維運資源: {維運能力說明} ## 2. 整體架構設計 ### 2.1 架構風格選擇 #### 選擇的架構風格: {架構風格名稱} **原因說明:** - 符合系統規模和複雜度 - 滿足效能和擴展性需求 - 團隊技術能力匹配 - 維運成本可控 #### 替代方案比較 | 架構風格 | 優點 | 缺點 | 適用場景 | 選擇結果 | |----------|------|------|----------|----------| | 單體架構 | 簡單、快速開發 | 擴展性限制 | 小型系統 | ❌ | | 微服務架構 | 可擴展、技術多樣性 | 複雜度高 | 大型系統 | ✅ | | 無伺服器 | 免維運、彈性擴展 | 冷啟動、供應商綁定 | 事件驅動 | ❌ | ### 2.2 系統架構圖 ```mermaid graph TB User[使用者] --\u0026gt; LB[負載平衡器] LB --\u0026gt; API[API Gateway] API --\u0026gt; Auth[認證服務] API --\u0026gt; BFF[Backend for Frontend] BFF --\u0026gt; UserSvc[使用者服務] BFF --\u0026gt; ProductSvc[產品服務] BFF --\u0026gt; OrderSvc[訂單服務] BFF --\u0026gt; PaymentSvc[支付服務] UserSvc --\u0026gt; UserDB[(使用者資料庫)] ProductSvc --\u0026gt; ProductDB[(產品資料庫)] OrderSvc --\u0026gt; OrderDB[(訂單資料庫)] PaymentSvc --\u0026gt; PaymentDB[(支付資料庫)] OrderSvc --\u0026gt; Queue[訊息佇列] Queue --\u0026gt; EmailSvc[郵件服務] Queue --\u0026gt; NotificationSvc[通知服務] UserSvc --\u0026gt; Cache[Redis 快取] ProductSvc --\u0026gt; Cache UserSvc --\u0026gt; Log[日誌系統] ProductSvc --\u0026gt; Log OrderSvc --\u0026gt; Log PaymentSvc --\u0026gt; Log 2.3 部署架構 環境規劃 開發環境:\n","title":"軟體架構設計指引範本"},{"content":"金融專案合規要求手冊 版本資訊 版本: 1.1 發布日期: 2025年8月29日 適用對象: 新進專案經理、資深專案經理、系統開發團隊 審核狀態: 更新版 目錄 金融專案中常見的合規要求概述 主要法規與標準（國內/國際） 專案生命周期各階段的合規檢查清單 專案文件與紀錄保存要求 風險管理與稽核應對 案例示例與常見錯誤 新興技術與合規挑戰 跨部門協作與溝通機制 合規成本管理與效益分析 數位轉型專案特殊考量 附錄：合規檢查清單 附錄：合規工具與模板 1. 金融專案中常見的合規要求概述 1.1 合規的重要性 金融專案合規不僅是法律要求，更是維護機構聲譽、降低營運風險的核心要素。在當今嚴格的監管環境下，任何合規疏失都可能導致：\n法律責任：罰款、制裁、執照撤銷 聲譽損失：客戶信任度下降、市場競爭力削弱 財務損失：營運中斷、客戶流失、投資人信心下滑 營運影響：系統重建、流程重新設計 1.2 金融專案特有的合規挑戰 1.2.1 資料敏感性 個人資料保護：客戶身分資料、財務資訊 交易資料：金流記錄、投資組合資訊 內部資料：風險模型、定價策略 1.2.2 跨境監管 多國法規：GDPR（歐盟）、CCPA（加州）、個資法（台灣） 國際標準：Basel III、FATF建議、ISO 27001 監管機構：金管會、央行、銀行局 1.2.3 技術複雜性 系統整合：核心銀行系統、風控系統、報表系統 資料治理：資料品質、資料血緣、資料安全 技術債務：舊系統維護、新舊系統共存 1.3 合規框架概念 1.3.1 三道防線模型 (Three Lines of Defense) 第一道防線：業務單位與營運管理\n日常風險管理 內控制度執行 前線合規檢查 第二道防線：風險管理與合規單位\n政策制定 風險監控 合規查核 第三道防線：內部稽核\n獨立驗證 有效性評估 改善建議 1.3.2 專案合規責任分工 角色 主要責任 合規職責 專案經理 專案整體管控 確保合規要求納入專案範圍 業務分析師 需求分析 識別業務流程中的合規點 系統架構師 技術架構設計 確保技術方案符合合規要求 開發團隊 系統開發 落實合規控制點的程式實作 測試團隊 系統測試 執行合規功能測試與驗證 合規專員 合規諮詢 提供法規解釋與合規指導 1.4 大型專案 vs 中小型專案差異 1.4.1 大型專案特點 專案規模：預算超過1億台幣、團隊超過50人、開發期程超過2年 合規複雜度：涉及多項法規、跨國營運、多系統整合 管理要求： 設立專門的合規委員會 聘請外部合規顧問 建立完整的合規治理架構 定期向董事會報告 1.4.2 中小型專案特點 專案規模：預算5千萬台幣以下、團隊20人以下、開發期程1年以內 合規複雜度：主要聚焦核心法規、單一系統或功能 管理要求： 指派合規聯絡人 使用標準化合規檢查清單 定期合規狀態報告 重點關注關鍵合規節點 1.5 常見合規領域 1.5.1 資料保護與隱私 適用法規：GDPR、個資法、銀行法 關鍵要求： 資料收集同意機制 資料處理目的限制 資料保存期限管理 資料跨境傳輸控制 1.5.2 反洗錢與打擊資恐 (AML/CFT) 適用法規：洗錢防制法、資恐防制法、FATF建議 關鍵要求： 客戶盡職調查 (CDD) 加強客戶盡職調查 (EDD) 疑似洗錢交易申報 (STR) 制裁名單篩檢 1.5.3 網路安全 適用法規：資通安全管理法、個資法、銀行法 關鍵要求： 資訊安全管理制度 事件應變機制 定期安全評估 員工安全教育訓練 2. 主要法規與標準（國內/國際） 2.1 台灣金融法規 🇹🇼 2.1.1 核心法規 銀行法 主管機關：金融監督管理委員會 適用對象：銀行業、信用合作社 關鍵條文： 第33條：銀行業務限制 第45條：資本適足性要求 第48條：業務查核與申報 專案影響：系統功能設計須符合業務範圍限制 個人資料保護法 施行日期：2012年10月1日 適用範圍：所有處理個人資料的公務機關及非公務機關 關鍵要求： 告知義務（第8條） 資料正確性維護（第11條） 安全維護措施（第27條） 罰則：新台幣2萬元以上20萬元以下罰鍰 洗錢防制法 最新修正：2018年11月7日 主要內容： 金融機構防制洗錢辦法 客戶盡職調查程序 疑似洗錢交易申報 系統要求： 即時篩檢功能 交易監控系統 報告產製機制 2.1.2 監管指引 金管會相關函令 銀行業內部控制及稽核制度實施辦法 金融機構防制洗錢辦法 銀行業公司治理實務守則 中央銀行規定 外匯收支或交易申報辦法 銀行業辦理外匯業務管理辦法 2.2 國際法規與標準 2.2.1 歐盟法規 GDPR (General Data Protection Regulation) 生效日期：2018年5月25日 適用範圍： 歐盟境內的資料處理 向歐盟提供商品或服務 監控歐盟境內個人行為 關鍵原則： 合法性、公平性、透明性 目的限制 資料最小化 正確性 保存期限限制 完整性與機密性 個人權利： 存取權 (Right of Access) 更正權 (Right to Rectification) 刪除權 (Right to Erasure) 資料可攜權 (Right to Data Portability) 罰款：營業額4%或2,000萬歐元，取較高者 PSD2 (Payment Services Directive 2) 目的：促進歐盟支付服務創新與競爭 關鍵要求： 強客戶驗證 (SCA) 開放銀行 API 第三方支付服務提供者 (TPP) 規範 2.2.2 美國法規 SOX Act (Sarbanes-Oxley Act) 適用對象：美國上市公司 關鍵要求： 財務報告內控制度 管理層證明責任 外部稽核獨立性 CCPA (California Consumer Privacy Act) 生效日期：2020年1月1日 適用範圍：處理加州居民個人資訊的企業 消費者權利： 知情權 刪除權 選擇退出權 不歧視權 2.2.3 國際標準 Basel III 發布機構：巴塞爾銀行監理委員會 (BCBS) 主要內容： 資本適足性要求 流動性覆蓋率 (LCR) 淨穩定資金比率 (NSFR) 槓桿比率 實施時程：2019-2027年分階段實施 ISO 27001 標準名稱：資訊安全管理系統要求事項 認證效益： 提升客戶信任 符合法規要求 降低安全風險 關鍵流程： PDCA循環 風險評估 控制措施選擇 持續改善 FATF 40項建議 發布機構：金融行動工作組織 涵蓋範圍： AML/CFT政策與協調 洗錢與資恐犯罪化 預防措施 透明度與實質受益人 權責機關權力 國際合作 2.3 新興法規趨勢 2.3.1 數位資產相關 歐盟 MiCA (Markets in Crypto-Assets Regulation) 美國數位資產框架 台灣虛擬通貨管理規範 2.3.2 人工智慧與演算法 歐盟 AI Act 演算法透明度要求 AI偏見防制 2.3.3 ESG與永續金融 歐盟永續金融披露規則 (SFDR) 氣候相關財務揭露 (TCFD) 台灣永續分類標準 3. 專案生命周期各階段的合規檢查清單 3.1 專案啟動階段 (Project Initiation) 3.1.1 合規評估要點 法規適用性分析 識別適用法規：依據專案性質、地理範圍、客戶類型確認適用法規清單 法規影響評估：評估各項法規對專案範圍、時程、成本的影響 合規成本估算：預估合規相關的人力、系統、流程成本 利害關係人識別 監管機構：金管會、央行、銀行局等主管機關 內部合規單位：法令遵循處、風險管理處、稽核處 外部顧問：法律事務所、會計師事務所、合規顧問 業務單位：相關業務部門、營運單位 3.1.2 必要文件準備 專案章程 (Project Charter) # 專案合規聲明範例 ## 合規目標 本專案承諾遵循以下法規要求： - 個人資料保護法 - 洗錢防制法 - 銀行法相關規定 - ISO 27001 資訊安全標準 ## 合規責任 - 專案經理：整體合規監督 - 合規專員：專業合規指導 - 開發團隊：落實合規控制點 ## 合規里程碑 - 需求分析階段：完成合規需求識別 - 設計階段：完成合規控制點設計 - 開發階段：完成合規功能開發 - 測試階段：完成合規測試驗證 初步風險評估 合規風險清單：識別潛在的合規風險點 風險等級評估：高/中/低風險分級 初步應對策略：風險規避、降低、轉移、接受 3.2 需求分析階段 (Requirements Analysis) 3.2.1 合規需求收集 功能性合規需求 資料保護功能\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E9%87%91%E8%9E%8D%E5%B0%88%E6%A1%88%E5%90%88%E8%A6%8F%E8%A6%81%E6%B1%82%E6%89%8B%E5%86%8A/","summary":"金融專案合規要求手冊 版本資訊 版本: 1.1 發布日期: 2025年8月29日 適用對象: 新進專案經理、資深專案經理、系統開發團隊 審核狀態: 更新版 目錄 金融專案中常見的合規要求概述 主要法規與標準（國內/國際） 專案生命周期各階段的合規檢查清單 專案文件與紀錄保存要求 風險管理與稽核應對 案例示例與常見錯誤 新興技術與合規挑戰 跨部門協作與溝通機制 合規成本管理與效益分析 數位轉型專案特殊考量 附錄：合規檢查清單 附錄：合規工具與模板 1. 金融專案中常見的合規要求概述 1.1 合規的重要性 金融專案合規不僅是法律要求，更是維護機構聲譽、降低營運風險的核心要素。在當今嚴格的監管環境下，任何合規疏失都可能導致：\n法律責任：罰款、制裁、執照撤銷 聲譽損失：客戶信任度下降、市場競爭力削弱 財務損失：營運中斷、客戶流失、投資人信心下滑 營運影響：系統重建、流程重新設計 1.2 金融專案特有的合規挑戰 1.2.1 資料敏感性 個人資料保護：客戶身分資料、財務資訊 交易資料：金流記錄、投資組合資訊 內部資料：風險模型、定價策略 1.2.2 跨境監管 多國法規：GDPR（歐盟）、CCPA（加州）、個資法（台灣） 國際標準：Basel III、FATF建議、ISO 27001 監管機構：金管會、央行、銀行局 1.2.3 技術複雜性 系統整合：核心銀行系統、風控系統、報表系統 資料治理：資料品質、資料血緣、資料安全 技術債務：舊系統維護、新舊系統共存 1.3 合規框架概念 1.3.1 三道防線模型 (Three Lines of Defense) 第一道防線：業務單位與營運管理\n日常風險管理 內控制度執行 前線合規檢查 第二道防線：風險管理與合規單位\n政策制定 風險監控 合規查核 第三道防線：內部稽核\n獨立驗證 有效性評估 改善建議 1.3.2 專案合規責任分工 角色 主要責任 合規職責 專案經理 專案整體管控 確保合規要求納入專案範圍 業務分析師 需求分析 識別業務流程中的合規點 系統架構師 技術架構設計 確保技術方案符合合規要求 開發團隊 系統開發 落實合規控制點的程式實作 測試團隊 系統測試 執行合規功能測試與驗證 合規專員 合規諮詢 提供法規解釋與合規指導 1.4 大型專案 vs 中小型專案差異 1.4.1 大型專案特點 專案規模：預算超過1億台幣、團隊超過50人、開發期程超過2年 合規複雜度：涉及多項法規、跨國營運、多系統整合 管理要求： 設立專門的合規委員會 聘請外部合規顧問 建立完整的合規治理架構 定期向董事會報告 1.4.2 中小型專案特點 專案規模：預算5千萬台幣以下、團隊20人以下、開發期程1年以內 合規複雜度：主要聚焦核心法規、單一系統或功能 管理要求： 指派合規聯絡人 使用標準化合規檢查清單 定期合規狀態報告 重點關注關鍵合規節點 1.5 常見合規領域 1.5.1 資料保護與隱私 適用法規：GDPR、個資法、銀行法 關鍵要求： 資料收集同意機制 資料處理目的限制 資料保存期限管理 資料跨境傳輸控制 1.5.2 反洗錢與打擊資恐 (AML/CFT) 適用法規：洗錢防制法、資恐防制法、FATF建議 關鍵要求： 客戶盡職調查 (CDD) 加強客戶盡職調查 (EDD) 疑似洗錢交易申報 (STR) 制裁名單篩檢 1.5.3 網路安全 適用法規：資通安全管理法、個資法、銀行法 關鍵要求： 資訊安全管理制度 事件應變機制 定期安全評估 員工安全教育訓練 2. 主要法規與標準（國內/國際） 2.1 台灣金融法規 🇹🇼 2.1.1 核心法規 銀行法 主管機關：金融監督管理委員會 適用對象：銀行業、信用合作社 關鍵條文： 第33條：銀行業務限制 第45條：資本適足性要求 第48條：業務查核與申報 專案影響：系統功能設計須符合業務範圍限制 個人資料保護法 施行日期：2012年10月1日 適用範圍：所有處理個人資料的公務機關及非公務機關 關鍵要求： 告知義務（第8條） 資料正確性維護（第11條） 安全維護措施（第27條） 罰則：新台幣2萬元以上20萬元以下罰鍰 洗錢防制法 最新修正：2018年11月7日 主要內容： 金融機構防制洗錢辦法 客戶盡職調查程序 疑似洗錢交易申報 系統要求： 即時篩檢功能 交易監控系統 報告產製機制 2.1.2 監管指引 金管會相關函令 銀行業內部控制及稽核制度實施辦法 金融機構防制洗錢辦法 銀行業公司治理實務守則 中央銀行規定 外匯收支或交易申報辦法 銀行業辦理外匯業務管理辦法 2.2 國際法規與標準 2.2.1 歐盟法規 GDPR (General Data Protection Regulation) 生效日期：2018年5月25日 適用範圍： 歐盟境內的資料處理 向歐盟提供商品或服務 監控歐盟境內個人行為 關鍵原則： 合法性、公平性、透明性 目的限制 資料最小化 正確性 保存期限限制 完整性與機密性 個人權利： 存取權 (Right of Access) 更正權 (Right to Rectification) 刪除權 (Right to Erasure) 資料可攜權 (Right to Data Portability) 罰款：營業額4%或2,000萬歐元，取較高者 PSD2 (Payment Services Directive 2) 目的：促進歐盟支付服務創新與競爭 關鍵要求： 強客戶驗證 (SCA) 開放銀行 API 第三方支付服務提供者 (TPP) 規範 2.2.2 美國法規 SOX Act (Sarbanes-Oxley Act) 適用對象：美國上市公司 關鍵要求： 財務報告內控制度 管理層證明責任 外部稽核獨立性 CCPA (California Consumer Privacy Act) 生效日期：2020年1月1日 適用範圍：處理加州居民個人資訊的企業 消費者權利： 知情權 刪除權 選擇退出權 不歧視權 2.2.3 國際標準 Basel III 發布機構：巴塞爾銀行監理委員會 (BCBS) 主要內容： 資本適足性要求 流動性覆蓋率 (LCR) 淨穩定資金比率 (NSFR) 槓桿比率 實施時程：2019-2027年分階段實施 ISO 27001 標準名稱：資訊安全管理系統要求事項 認證效益： 提升客戶信任 符合法規要求 降低安全風險 關鍵流程： PDCA循環 風險評估 控制措施選擇 持續改善 FATF 40項建議 發布機構：金融行動工作組織 涵蓋範圍： AML/CFT政策與協調 洗錢與資恐犯罪化 預防措施 透明度與實質受益人 權責機關權力 國際合作 2.3 新興法規趨勢 2.3.1 數位資產相關 歐盟 MiCA (Markets in Crypto-Assets Regulation) 美國數位資產框架 台灣虛擬通貨管理規範 2.3.2 人工智慧與演算法 歐盟 AI Act 演算法透明度要求 AI偏見防制 2.3.3 ESG與永續金融 歐盟永續金融披露規則 (SFDR) 氣候相關財務揭露 (TCFD) 台灣永續分類標準 3. 專案生命周期各階段的合規檢查清單 3.1 專案啟動階段 (Project Initiation) 3.1.1 合規評估要點 法規適用性分析 識別適用法規：依據專案性質、地理範圍、客戶類型確認適用法規清單 法規影響評估：評估各項法規對專案範圍、時程、成本的影響 合規成本估算：預估合規相關的人力、系統、流程成本 利害關係人識別 監管機構：金管會、央行、銀行局等主管機關 內部合規單位：法令遵循處、風險管理處、稽核處 外部顧問：法律事務所、會計師事務所、合規顧問 業務單位：相關業務部門、營運單位 3.1.2 必要文件準備 專案章程 (Project Charter) # 專案合規聲明範例 ## 合規目標 本專案承諾遵循以下法規要求： - 個人資料保護法 - 洗錢防制法 - 銀行法相關規定 - ISO 27001 資訊安全標準 ## 合規責任 - 專案經理：整體合規監督 - 合規專員：專業合規指導 - 開發團隊：落實合規控制點 ## 合規里程碑 - 需求分析階段：完成合規需求識別 - 設計階段：完成合規控制點設計 - 開發階段：完成合規功能開發 - 測試階段：完成合規測試驗證 初步風險評估 合規風險清單：識別潛在的合規風險點 風險等級評估：高/中/低風險分級 初步應對策略：風險規避、降低、轉移、接受 3.2 需求分析階段 (Requirements Analysis) 3.2.1 合規需求收集 功能性合規需求 資料保護功能\n","title":"金融專案合規要求手冊"},{"content":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","permalink":"https://chihhung.github.io/Blog/posts/hugo-setup-guide/","summary":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","title":"GitHub使用Hugo建立個人網頁教學"},{"content":"關於這個部落格 歡迎來到我的個人部落格！這是一個使用 Hugo 靜態網站生成器建立的部落格，部署在 GitHub Pages 上。\n關於我 我是一位軟體開發者，對技術充滿熱忱。在這裡我會分享：\n程式開發的學習心得\n學術文章與教學\n生活中的所見所聞\n個人專案的展示\n技術棧 前端: HTML, CSS, JavaScript, TypeScript , React, Vue, Angular\n後端: Node.js, Python, Java , Spring framework, Spring Boot\n資料庫: DB2, Oracle, PostgreSQL, SQL server\n工具: Git, Docker , podman , VS Code , intellij , eclipse, Maven,\u0026hellip;\n程式語言: C# / C / C++ /cobol/ java/ javascript/ typescript / python/ sql/ bash/ html /CSS3\nframework: Spring framework /spring boot /Angular /nodes \u0026hellip;\n","permalink":"https://chihhung.github.io/Blog/about/","summary":"關於這個部落格 歡迎來到我的個人部落格！這是一個使用 Hugo 靜態網站生成器建立的部落格，部署在 GitHub Pages 上。\n關於我 我是一位軟體開發者，對技術充滿熱忱。在這裡我會分享：\n程式開發的學習心得\n學術文章與教學\n生活中的所見所聞\n個人專案的展示\n技術棧 前端: HTML, CSS, JavaScript, TypeScript , React, Vue, Angular\n後端: Node.js, Python, Java , Spring framework, Spring Boot\n資料庫: DB2, Oracle, PostgreSQL, SQL server\n工具: Git, Docker , podman , VS Code , intellij , eclipse, Maven,\u0026hellip;\n程式語言: C# / C / C++ /cobol/ java/ javascript/ typescript / python/ sql/ bash/ html /CSS3\nframework: Spring framework /spring boot /Angular /nodes \u0026hellip;\n","title":"關於我"},{"content":"這是使用 Hugo 建立的第一篇測試文章！\n內容重點 簡潔的技術文件：適合撰寫程式碼範例 豐富的主題支援：輕鬆客製化外觀 快速的編譯速度：幾秒鐘就能完成建置 優秀的社群支援：活躍的開發者社群 總結 這是一個很棒的靜態網站生成工具，值得深入學習！\n未來計劃：我會持續分享更多技術文章。\n歡迎回饋 歡迎大家提供意見和建議，讓這個 Blog 變得更好！\n","permalink":"https://chihhung.github.io/Blog/posts/my-first-post/","summary":"這是使用 Hugo 建立的第一篇測試文章！\n內容重點 簡潔的技術文件：適合撰寫程式碼範例 豐富的主題支援：輕鬆客製化外觀 快速的編譯速度：幾秒鐘就能完成建置 優秀的社群支援：活躍的開發者社群 總結 這是一個很棒的靜態網站生成工具，值得深入學習！\n未來計劃：我會持續分享更多技術文章。\n歡迎回饋 歡迎大家提供意見和建議，讓這個 Blog 變得更好！\n","title":"我的第一篇文章"},{"content":"Maven 使用教學手冊 文件資訊 版本: 3.0.0 建立日期: 2025年8月29日 最後更新: 2025年7月 適用對象: 新進開發同仁 目的: 協助快速熟悉並在專案中正確使用 Maven 目錄 Maven 基本介紹 1.1 什麼是 Maven？ 1.2 Maven 的用途與優勢 1.3 在專案中的角色 環境建置 2.1 前置條件 2.2 Maven 安裝 2.3 驗證安裝成功 2.4 IDE 整合 2.5 設定檔配置 Maven 專案結構 3.1 標準目錄結構 3.2 目錄結構詳細說明 3.3 在專案中的實際應用 3.4 自訂目錄結構 pom.xml 說明 4.1 什麼是 POM？ 4.2 基本結構 4.3 常用標籤詳細說明 4.4 如何新增與管理依賴 4.5 建置配置 4.6 我們專案的完整 pom.xml 分析 常用指令 5.1 Maven 生命週期 5.2 基本指令詳解 5.3 依賴管理指令 5.4 執行指令 5.5 資訊查詢指令 5.6 進階指令 5.7 我們專案中的常用工作流程 5.8 VS Code 中的 Maven 整合 5.9 Maven Wrapper 使用 5.10 與 CI/CD 整合 專案最佳實務 6.1 依賴管理建議 6.2 Docker 整合 6.3 安全性管理 6.4 效能監控 6.5 現代化開發實務 6.6 效能優化策略 6.7 微服務架構支援 6.8 避免版本衝突的方法 6.9 建置優化策略 6.10 程式碼品質管理 6.11 使用公司內部 Nexus/Artifactory 6.12 環境特定設定 常見問題排解 FAQ 7.1 編譯相關問題 7.2 依賴相關問題 7.3 測試相關問題 7.4 IDE 整合問題 7.5 效能相關問題 7.6 網路相關問題 7.7 專案中注意事項 附錄 8.1 官方文件與教學資源連結 8.2 常用插件參考 8.3 Maven 生命週期詳細說明 8.4 常用 Maven 屬性 8.5 範例設定檔 8.6 團隊協作指南 檢查清單 Checklist 9.1 環境設定檢查清單 9.2 日常開發檢查清單 9.3 問題排解檢查清單 9.4 發布準備檢查清單 9.5 新人上手檢查清單 9.6 定期維護檢查清單 快速參考手冊 10.1 常用指令速查表 10.2 常用參數速查表 10.3 POM 檔案基本結構速查 10.4 常見問題快速解決 10.5 開發工作流程檢查清單 10.6 實用技巧 進階主題 11.1 自定義 Maven Archetype 11.2 Maven 插件開發 11.3 Maven 與 Spring Boot 整合 11.4 Maven 與容器化部署 11.5 企業級 Maven 倉庫管理 團隊協作與規範 12.1 程式碼審查規範 12.2 版本管理策略 12.3 分支管理與 Maven 12.4 自動化測試策略 Maven 與現代 Java 開發 13.1 Java 模組系統（JPMS）與 Maven 13.2 Maven 與 JDK 版本管理 13.3 Maven 與記錄（Records）和文字區塊 13.4 Maven 與虛擬執行緒 13.5 Maven 4 預覽與未來展望 效能調校與監控 14.1 Maven 建置效能優化 14.2 依賴解析效能調校 14.3 建置時間監控與分析 14.4 記憶體使用最佳化 錯誤處理與除錯技巧 15.1 常見錯誤診斷流程 15.2 除錯工具與技巧 15.3 日誌分析與解讀 15.4 遠端除錯設定 實戰專案範例 16.1 簡單控制台應用程式 16.2 Spring Boot Web 應用程式 16.3 多模組企業級專案 16.4 微服務架構專案 1. Maven 基本介紹 1.1 什麼是 Maven？ Apache Maven 是一個專案管理和建置自動化工具，主要用於 Java 專案（也支援其他語言如 C#、Ruby、Scala 等）。Maven 使用專案物件模型（Project Object Model, POM）來管理專案的建置、報告和文件。\n","permalink":"https://chihhung.github.io/Blog/posts/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/maven%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Maven 使用教學手冊 文件資訊 版本: 3.0.0 建立日期: 2025年8月29日 最後更新: 2025年7月 適用對象: 新進開發同仁 目的: 協助快速熟悉並在專案中正確使用 Maven 目錄 Maven 基本介紹 1.1 什麼是 Maven？ 1.2 Maven 的用途與優勢 1.3 在專案中的角色 環境建置 2.1 前置條件 2.2 Maven 安裝 2.3 驗證安裝成功 2.4 IDE 整合 2.5 設定檔配置 Maven 專案結構 3.1 標準目錄結構 3.2 目錄結構詳細說明 3.3 在專案中的實際應用 3.4 自訂目錄結構 pom.xml 說明 4.1 什麼是 POM？ 4.2 基本結構 4.3 常用標籤詳細說明 4.4 如何新增與管理依賴 4.5 建置配置 4.6 我們專案的完整 pom.xml 分析 常用指令 5.1 Maven 生命週期 5.2 基本指令詳解 5.3 依賴管理指令 5.4 執行指令 5.5 資訊查詢指令 5.6 進階指令 5.7 我們專案中的常用工作流程 5.8 VS Code 中的 Maven 整合 5.9 Maven Wrapper 使用 5.10 與 CI/CD 整合 專案最佳實務 6.1 依賴管理建議 6.2 Docker 整合 6.3 安全性管理 6.4 效能監控 6.5 現代化開發實務 6.6 效能優化策略 6.7 微服務架構支援 6.8 避免版本衝突的方法 6.9 建置優化策略 6.10 程式碼品質管理 6.11 使用公司內部 Nexus/Artifactory 6.12 環境特定設定 常見問題排解 FAQ 7.1 編譯相關問題 7.2 依賴相關問題 7.3 測試相關問題 7.4 IDE 整合問題 7.5 效能相關問題 7.6 網路相關問題 7.7 專案中注意事項 附錄 8.1 官方文件與教學資源連結 8.2 常用插件參考 8.3 Maven 生命週期詳細說明 8.4 常用 Maven 屬性 8.5 範例設定檔 8.6 團隊協作指南 檢查清單 Checklist 9.1 環境設定檢查清單 9.2 日常開發檢查清單 9.3 問題排解檢查清單 9.4 發布準備檢查清單 9.5 新人上手檢查清單 9.6 定期維護檢查清單 快速參考手冊 10.1 常用指令速查表 10.2 常用參數速查表 10.3 POM 檔案基本結構速查 10.4 常見問題快速解決 10.5 開發工作流程檢查清單 10.6 實用技巧 進階主題 11.1 自定義 Maven Archetype 11.2 Maven 插件開發 11.3 Maven 與 Spring Boot 整合 11.4 Maven 與容器化部署 11.5 企業級 Maven 倉庫管理 團隊協作與規範 12.1 程式碼審查規範 12.2 版本管理策略 12.3 分支管理與 Maven 12.4 自動化測試策略 Maven 與現代 Java 開發 13.1 Java 模組系統（JPMS）與 Maven 13.2 Maven 與 JDK 版本管理 13.3 Maven 與記錄（Records）和文字區塊 13.4 Maven 與虛擬執行緒 13.5 Maven 4 預覽與未來展望 效能調校與監控 14.1 Maven 建置效能優化 14.2 依賴解析效能調校 14.3 建置時間監控與分析 14.4 記憶體使用最佳化 錯誤處理與除錯技巧 15.1 常見錯誤診斷流程 15.2 除錯工具與技巧 15.3 日誌分析與解讀 15.4 遠端除錯設定 實戰專案範例 16.1 簡單控制台應用程式 16.2 Spring Boot Web 應用程式 16.3 多模組企業級專案 16.4 微服務架構專案 1. Maven 基本介紹 1.1 什麼是 Maven？ Apache Maven 是一個專案管理和建置自動化工具，主要用於 Java 專案（也支援其他語言如 C#、Ruby、Scala 等）。Maven 使用專案物件模型（Project Object Model, POM）來管理專案的建置、報告和文件。\n","title":"Maven 使用教學"},{"content":"在人工智慧領域，「prompt」指的是用戶輸入給 AI 模型的文字指令或問題，用來引導模型產生回應。它是你與 AI 溝通的起點，影響 AI 回應的內容、品質與風格。\n🧠 Prompt 是什麼？\n是一段文字、問題或指令，用來告訴 AI 你想要什麼樣的回應。 在語言模型（如 ChatGPT）中，prompt 可以是簡單的問題，也可以是複雜的任務描述。 好的 prompt 能讓 AI 更準確地理解你的需求，產生有價值的內容。 ✍️ Prompt 的用途\n問問題：例如「台灣和日本的時差是多少？」 請求創作：例如「幫我寫一篇關於氣候變遷的文章。」 角色扮演：例如「假設你是面試官，請問我三個技術問題。」 資料整理：例如「請將以下資訊整理成表格。」 🔧 如何撰寫高品質的 Prompt？\n技巧 說明 範例 明確具體 避免模糊用詞 「請列出三個影響員工流動率的因素」 設定格式 指定回應方式 「請用條列式說明」 提供背景 增加上下文 「假設你是 HR 經理，請撰寫招募建議書」 指定語氣 控制風格 「請用正式且精煉的語氣撰寫報告」 範例引導 示範期望格式 「請參考以下格式翻譯這段文字」 ======================================================\n如何撰寫專案的 Prompt 角色設定 確定 AI 的角色，例如「專案經理」、「技術架構師」或「UI/UX 設計師」，這有助於 AI 理解其應該採取的視角。 任務描述 清楚描述 AI 需要完成的任務，例如「撰寫專案計劃」、「設計系統架構」或「撰寫使用者故事」。 具體要求 提供明確的指示和期望結果，例如「請使用 Markdown 格式撰寫文檔」或「請提供 API 的詳細設計」。 範例和格式 如果有特定的格式或範例，請在 Prompt 中提供，這樣 AI 可以更好地理解你的需求。 如何建立專案的 Prompt 確定專案目標：明確定義專案的最終目標和需求，這將成為撰寫 Prompt 的基礎。\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/prompt/","summary":"在人工智慧領域，「prompt」指的是用戶輸入給 AI 模型的文字指令或問題，用來引導模型產生回應。它是你與 AI 溝通的起點，影響 AI 回應的內容、品質與風格。\n🧠 Prompt 是什麼？\n是一段文字、問題或指令，用來告訴 AI 你想要什麼樣的回應。 在語言模型（如 ChatGPT）中，prompt 可以是簡單的問題，也可以是複雜的任務描述。 好的 prompt 能讓 AI 更準確地理解你的需求，產生有價值的內容。 ✍️ Prompt 的用途\n問問題：例如「台灣和日本的時差是多少？」 請求創作：例如「幫我寫一篇關於氣候變遷的文章。」 角色扮演：例如「假設你是面試官，請問我三個技術問題。」 資料整理：例如「請將以下資訊整理成表格。」 🔧 如何撰寫高品質的 Prompt？\n技巧 說明 範例 明確具體 避免模糊用詞 「請列出三個影響員工流動率的因素」 設定格式 指定回應方式 「請用條列式說明」 提供背景 增加上下文 「假設你是 HR 經理，請撰寫招募建議書」 指定語氣 控制風格 「請用正式且精煉的語氣撰寫報告」 範例引導 示範期望格式 「請參考以下格式翻譯這段文字」 ======================================================\n如何撰寫專案的 Prompt 角色設定 確定 AI 的角色，例如「專案經理」、「技術架構師」或「UI/UX 設計師」，這有助於 AI 理解其應該採取的視角。 任務描述 清楚描述 AI 需要完成的任務，例如「撰寫專案計劃」、「設計系統架構」或「撰寫使用者故事」。 具體要求 提供明確的指示和期望結果，例如「請使用 Markdown 格式撰寫文檔」或「請提供 API 的詳細設計」。 範例和格式 如果有特定的格式或範例，請在 Prompt 中提供，這樣 AI 可以更好地理解你的需求。 如何建立專案的 Prompt 確定專案目標：明確定義專案的最終目標和需求，這將成為撰寫 Prompt 的基礎。\n","title":""},{"content":"SSDLC 專案範本指南 簡介 本指南提供安全軟體開發生命週期 (Secure Software Development Life Cycle, SSDLC) 的完整範本體系，旨在協助團隊透過 AI 輔助完成專案的各個階段開發任務。\nSSDLC 階段概覽 1. 需求分析階段 (Requirements Analysis) 目標: 收集、分析並定義專案需求，建立安全需求規範\n工作項目 業務需求收集 功能需求分析 非功能需求定義 安全需求識別 使用者故事撰寫 風險評估 技術細節和業務需求 需求追溯矩陣 安全威脅模型分析 合規性要求檢查 效能基準定義 2. 設計開發階段 (Design \u0026amp; Development) 目標: 進行系統架構設計和安全編碼實作\n工作項目 系統架構設計 安全架構設計 資料庫設計 API 設計 編碼實作 程式碼審查 技術細節和業務需求 設計模式應用 安全編碼標準 程式碼品質標準 版本控制策略 3. 測試驗收階段 (Testing \u0026amp; Validation) 目標: 執行全面測試並進行安全驗證\n工作項目 單元測試 整合測試 系統測試 效能測試 安全測試 使用者驗收測試 技術細節和業務需求 測試策略制定 自動化測試框架 安全測試工具 測試覆蓋率要求 4. 部署運維階段 (Deployment \u0026amp; Operations) 目標: 安全部署系統並建立持續監控機制\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/ssdlc_%E5%B0%88%E6%A1%88%E7%AF%84%E6%9C%AC%E6%8C%87%E5%8D%97/","summary":"SSDLC 專案範本指南 簡介 本指南提供安全軟體開發生命週期 (Secure Software Development Life Cycle, SSDLC) 的完整範本體系，旨在協助團隊透過 AI 輔助完成專案的各個階段開發任務。\nSSDLC 階段概覽 1. 需求分析階段 (Requirements Analysis) 目標: 收集、分析並定義專案需求，建立安全需求規範\n工作項目 業務需求收集 功能需求分析 非功能需求定義 安全需求識別 使用者故事撰寫 風險評估 技術細節和業務需求 需求追溯矩陣 安全威脅模型分析 合規性要求檢查 效能基準定義 2. 設計開發階段 (Design \u0026amp; Development) 目標: 進行系統架構設計和安全編碼實作\n工作項目 系統架構設計 安全架構設計 資料庫設計 API 設計 編碼實作 程式碼審查 技術細節和業務需求 設計模式應用 安全編碼標準 程式碼品質標準 版本控制策略 3. 測試驗收階段 (Testing \u0026amp; Validation) 目標: 執行全面測試並進行安全驗證\n工作項目 單元測試 整合測試 系統測試 效能測試 安全測試 使用者驗收測試 技術細節和業務需求 測試策略制定 自動化測試框架 安全測試工具 測試覆蓋率要求 4. 部署運維階段 (Deployment \u0026amp; Operations) 目標: 安全部署系統並建立持續監控機制\n","title":""},{"content":"SSDLC Prompt 範本使用指南 概述 本文檔提供完整的 SSDLC (Secure Software Development Life Cycle) Prompt 範本使用指南，協助團隊透過 AI 輔助完成各階段的開發任務。\n範本結構說明 目錄組織 .github/prompts/ ├── SSDLC_專案範本指南.md # 主要指南文檔 ├── 需求分析/ │ ├── 業務需求收集範本.md │ ├── 功能需求分析範本.md │ ├── 安全需求識別範本.md │ └── 使用者故事撰寫範本.md ├── 設計開發/ │ ├── 系統架構設計範本.md │ ├── API設計範本.md │ └── [其他設計範本] ├── 測試驗收/ │ ├── 測試策略制定範本.md │ ├── 自動化測試範本.md │ └── [其他測試範本] └── 部署運維/ ├── CI_CD流程範本.md └── [其他運維範本] 快速開始指南 步驟 1: 選擇適當的範本 根據當前專案階段選擇對應的範本：\n需求分析階段: 從業務需求收集開始 設計開發階段: 從系統架構設計開始 測試驗收階段: 從測試策略制定開始 部署運維階段: 從 CI/CD 流程設計開始 步驟 2: 填寫專案資訊 每個範本都包含專案背景資訊區塊，需要填入：\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97/","summary":"SSDLC Prompt 範本使用指南 概述 本文檔提供完整的 SSDLC (Secure Software Development Life Cycle) Prompt 範本使用指南，協助團隊透過 AI 輔助完成各階段的開發任務。\n範本結構說明 目錄組織 .github/prompts/ ├── SSDLC_專案範本指南.md # 主要指南文檔 ├── 需求分析/ │ ├── 業務需求收集範本.md │ ├── 功能需求分析範本.md │ ├── 安全需求識別範本.md │ └── 使用者故事撰寫範本.md ├── 設計開發/ │ ├── 系統架構設計範本.md │ ├── API設計範本.md │ └── [其他設計範本] ├── 測試驗收/ │ ├── 測試策略制定範本.md │ ├── 自動化測試範本.md │ └── [其他測試範本] └── 部署運維/ ├── CI_CD流程範本.md └── [其他運維範本] 快速開始指南 步驟 1: 選擇適當的範本 根據當前專案階段選擇對應的範本：\n需求分析階段: 從業務需求收集開始 設計開發階段: 從系統架構設計開始 測試驗收階段: 從測試策略制定開始 部署運維階段: 從 CI/CD 流程設計開始 步驟 2: 填寫專案資訊 每個範本都包含專案背景資訊區塊，需要填入：\n","title":""},{"content":"測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。\n角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。\n任務描述 請協助我為 {專案名稱} 制定完整的測試策略。\n專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略：\n1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 \u0026lt; 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 \u0026lt; 2秒 - 吞吐量: \u0026gt; 1000 TPS - 並發使用者: \u0026gt; 5000 - 資源使用率: CPU \u0026lt; 80%, Memory \u0026lt; 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 \u0026#43; Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver \u0026#43; Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E6%B8%AC%E8%A9%A6%E9%A9%97%E6%94%B6/%E6%B8%AC%E8%A9%A6%E7%AD%96%E7%95%A5%E5%88%B6%E5%AE%9A%E7%AF%84%E6%9C%AC/","summary":"測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。\n角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。\n任務描述 請協助我為 {專案名稱} 制定完整的測試策略。\n專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略：\n1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 \u0026lt; 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 \u0026lt; 2秒 - 吞吐量: \u0026gt; 1000 TPS - 並發使用者: \u0026gt; 5000 - 資源使用率: CPU \u0026lt; 80%, Memory \u0026lt; 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 \u0026#43; Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver \u0026#43; Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告\n","title":""},{"content":"自動化測試範本 Prompt 目標 指導 AI 建立完整的自動化測試框架，包含各層級的自動化測試實作。\n角色設定 你是一位資深自動化測試工程師，具備豐富的測試框架設計和實作經驗，熟悉各種自動化測試工具和最佳實務。\n任務描述 請協助我為 {專案名稱} 建立完整的自動化測試框架和測試案例。\n專案自動化背景 專案名稱: {填入專案名稱} 應用類型: {填入應用類型，如：Web應用、API服務、微服務} 技術棧: {填入技術棧，如：Spring Boot + React、.NET Core + Angular} 測試目標: {填入自動化測試目標} 現有工具: {填入現有的測試工具和框架} 自動化測試要求 請按照以下結構建立自動化測試：\n1. 測試框架設計 框架架構設計 工具選型評估 專案結構規劃 配置管理設計 2. 單元測試自動化 測試類別設計 Mock 策略規劃 測試資料準備 斷言策略設計 3. 整合測試自動化 API 測試框架 資料庫測試設計 外部服務模擬 契約測試實作 4. UI 測試自動化 Page Object 模式 元素定位策略 測試資料驅動 跨瀏覽器測試 5. CI/CD 整合 測試執行策略 報告生成機制 失敗處理流程 測試結果分析 6. 維護和擴展 測試程式碼品質 框架擴展性設計 效能最佳化 文檔和培訓 輸出格式 # {專案名稱} 自動化測試框架 ## 1. 框架架構設計 ### 1.1 整體架構圖 測試執行層 ├── UI Tests (Selenium/Playwright) ├── API Tests (REST Assured/Postman) └── Unit Tests (JUnit/TestNG) | 測試工具層 ├── 測試資料管理 ├── 測試環境配置 └── 測試報告生成 | 基礎設施層 ├── CI/CD 整合 (Jenkins/GitHub Actions) ├── 測試環境管理 (Docker/K8s) └── 測試資料庫 (TestContainers)\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E6%B8%AC%E8%A9%A6%E9%A9%97%E6%94%B6/%E8%87%AA%E5%8B%95%E5%8C%96%E6%B8%AC%E8%A9%A6%E7%AF%84%E6%9C%AC/","summary":"自動化測試範本 Prompt 目標 指導 AI 建立完整的自動化測試框架，包含各層級的自動化測試實作。\n角色設定 你是一位資深自動化測試工程師，具備豐富的測試框架設計和實作經驗，熟悉各種自動化測試工具和最佳實務。\n任務描述 請協助我為 {專案名稱} 建立完整的自動化測試框架和測試案例。\n專案自動化背景 專案名稱: {填入專案名稱} 應用類型: {填入應用類型，如：Web應用、API服務、微服務} 技術棧: {填入技術棧，如：Spring Boot + React、.NET Core + Angular} 測試目標: {填入自動化測試目標} 現有工具: {填入現有的測試工具和框架} 自動化測試要求 請按照以下結構建立自動化測試：\n1. 測試框架設計 框架架構設計 工具選型評估 專案結構規劃 配置管理設計 2. 單元測試自動化 測試類別設計 Mock 策略規劃 測試資料準備 斷言策略設計 3. 整合測試自動化 API 測試框架 資料庫測試設計 外部服務模擬 契約測試實作 4. UI 測試自動化 Page Object 模式 元素定位策略 測試資料驅動 跨瀏覽器測試 5. CI/CD 整合 測試執行策略 報告生成機制 失敗處理流程 測試結果分析 6. 維護和擴展 測試程式碼品質 框架擴展性設計 效能最佳化 文檔和培訓 輸出格式 # {專案名稱} 自動化測試框架 ## 1. 框架架構設計 ### 1.1 整體架構圖 測試執行層 ├── UI Tests (Selenium/Playwright) ├── API Tests (REST Assured/Postman) └── Unit Tests (JUnit/TestNG) | 測試工具層 ├── 測試資料管理 ├── 測試環境配置 └── 測試報告生成 | 基礎設施層 ├── CI/CD 整合 (Jenkins/GitHub Actions) ├── 測試環境管理 (Docker/K8s) └── 測試資料庫 (TestContainers)\n","title":""},{"content":"API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。\n角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。\n任務描述 請協助我完成 {專案名稱} 的API設計工作。\nAPI 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計：\n1. API 概覽設計 API 目標和範圍定義 資源模型設計 URL 結構規劃 HTTP 方法對應 2. 資料模型設計 實體關係模型 JSON Schema 定義 資料驗證規則 錯誤回應格式 3. 端點詳細設計 CRUD 操作設計 查詢和篩選設計 分頁機制設計 排序機制設計 4. 安全性設計 身份驗證機制 授權控制設計 API 金鑰管理 速率限制設計 5. 版本控制策略 版本控制方法 向後相容性規劃 廢棄策略設計 遷移指南規劃 6. 文檔和測試 OpenAPI 規格撰寫 使用範例提供 測試案例設計 錯誤處理指南 輸出格式 # {專案名稱} API 設計規格 ## 1. API 概覽 ### 1.1 API 目標 **主要目標:** [API 的主要用途和目標] **次要目標:** [輔助功能和延伸應用] **成功標準:** [API 品質和使用量指標] ### 1.2 API 設計原則 - **RESTful 設計**: 遵循 REST 架構風格 - **一致性**: 統一的命名和回應格式 - **可預測性**: 直觀的 URL 結構和行為 - **可擴展性**: 支援未來功能擴展 - **安全性**: 內建安全機制 ### 1.3 基礎 URL 結構 **Base URL:** `https://api.{domain}.com/v1` **URL 模式:** `/{resource}/{id}/{sub-resource}` ### 1.4 HTTP 方法對應 | HTTP 方法 | 用途 | 冪等性 | 安全性 | |-----------|------|--------|--------| | GET | 查詢資源 | 是 | 是 | | POST | 建立資源 | 否 | 否 | | PUT | 更新/替換資源 | 是 | 否 | | PATCH | 部分更新資源 | 否 | 否 | | DELETE | 刪除資源 | 是 | 否 | ## 2. 資料模型設計 ### 2.1 核心實體模型 #### 實體: User (使用者) ```json { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;string (3-50字元)\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;string (email格式)\u0026#34;, \u0026#34;firstName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;string (enum: admin, user, guest)\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;string (enum: active, inactive, suspended)\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 實體: Product (產品) { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;string (1-200字元)\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;string (可選，最多1000字元)\u0026#34;, \u0026#34;price\u0026#34;: \u0026#34;number (正數，最多2位小數)\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;sku\u0026#34;: \u0026#34;string (產品編號)\u0026#34;, \u0026#34;inventory\u0026#34;: { \u0026#34;quantity\u0026#34;: \u0026#34;integer (非負整數)\u0026#34;, \u0026#34;reserved\u0026#34;: \u0026#34;integer (非負整數)\u0026#34; }, \u0026#34;images\u0026#34;: [\u0026#34;string (URL陣列)\u0026#34;], \u0026#34;attributes\u0026#34;: { \u0026#34;color\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;size\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;weight\u0026#34;: \u0026#34;number\u0026#34; }, \u0026#34;isActive\u0026#34;: \u0026#34;boolean\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 2.2 標準回應格式 成功回應格式 { \u0026#34;success\u0026#34;: true, \u0026#34;data\u0026#34;: { // 實際資料內容 }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34;, \u0026#34;pagination\u0026#34;: { // 僅分頁查詢時包含 \u0026#34;page\u0026#34;: 1, \u0026#34;limit\u0026#34;: 20, \u0026#34;total\u0026#34;: 100, \u0026#34;totalPages\u0026#34;: 5 } } } 錯誤回應格式 { \u0026#34;success\u0026#34;: false, \u0026#34;error\u0026#34;: { \u0026#34;code\u0026#34;: \u0026#34;ERROR_CODE\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;錯誤訊息\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;詳細錯誤說明\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;發生錯誤的欄位 (驗證錯誤時)\u0026#34; }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34; } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/api%E8%A8%AD%E8%A8%88%E7%AF%84%E6%9C%AC/","summary":"API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。\n角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。\n任務描述 請協助我完成 {專案名稱} 的API設計工作。\nAPI 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計：\n1. API 概覽設計 API 目標和範圍定義 資源模型設計 URL 結構規劃 HTTP 方法對應 2. 資料模型設計 實體關係模型 JSON Schema 定義 資料驗證規則 錯誤回應格式 3. 端點詳細設計 CRUD 操作設計 查詢和篩選設計 分頁機制設計 排序機制設計 4. 安全性設計 身份驗證機制 授權控制設計 API 金鑰管理 速率限制設計 5. 版本控制策略 版本控制方法 向後相容性規劃 廢棄策略設計 遷移指南規劃 6. 文檔和測試 OpenAPI 規格撰寫 使用範例提供 測試案例設計 錯誤處理指南 輸出格式 # {專案名稱} API 設計規格 ## 1. API 概覽 ### 1.1 API 目標 **主要目標:** [API 的主要用途和目標] **次要目標:** [輔助功能和延伸應用] **成功標準:** [API 品質和使用量指標] ### 1.2 API 設計原則 - **RESTful 設計**: 遵循 REST 架構風格 - **一致性**: 統一的命名和回應格式 - **可預測性**: 直觀的 URL 結構和行為 - **可擴展性**: 支援未來功能擴展 - **安全性**: 內建安全機制 ### 1.3 基礎 URL 結構 **Base URL:** `https://api.{domain}.com/v1` **URL 模式:** `/{resource}/{id}/{sub-resource}` ### 1.4 HTTP 方法對應 | HTTP 方法 | 用途 | 冪等性 | 安全性 | |-----------|------|--------|--------| | GET | 查詢資源 | 是 | 是 | | POST | 建立資源 | 否 | 否 | | PUT | 更新/替換資源 | 是 | 否 | | PATCH | 部分更新資源 | 否 | 否 | | DELETE | 刪除資源 | 是 | 否 | ## 2. 資料模型設計 ### 2.1 核心實體模型 #### 實體: User (使用者) ```json { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;string (3-50字元)\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;string (email格式)\u0026#34;, \u0026#34;firstName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;string (1-50字元)\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;string (enum: admin, user, guest)\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;string (enum: active, inactive, suspended)\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 實體: Product (產品) { \u0026#34;id\u0026#34;: \u0026#34;string (UUID)\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;string (1-200字元)\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;string (可選，最多1000字元)\u0026#34;, \u0026#34;price\u0026#34;: \u0026#34;number (正數，最多2位小數)\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;sku\u0026#34;: \u0026#34;string (產品編號)\u0026#34;, \u0026#34;inventory\u0026#34;: { \u0026#34;quantity\u0026#34;: \u0026#34;integer (非負整數)\u0026#34;, \u0026#34;reserved\u0026#34;: \u0026#34;integer (非負整數)\u0026#34; }, \u0026#34;images\u0026#34;: [\u0026#34;string (URL陣列)\u0026#34;], \u0026#34;attributes\u0026#34;: { \u0026#34;color\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;size\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;weight\u0026#34;: \u0026#34;number\u0026#34; }, \u0026#34;isActive\u0026#34;: \u0026#34;boolean\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;string (ISO 8601 datetime)\u0026#34; } 2.2 標準回應格式 成功回應格式 { \u0026#34;success\u0026#34;: true, \u0026#34;data\u0026#34;: { // 實際資料內容 }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34;, \u0026#34;pagination\u0026#34;: { // 僅分頁查詢時包含 \u0026#34;page\u0026#34;: 1, \u0026#34;limit\u0026#34;: 20, \u0026#34;total\u0026#34;: 100, \u0026#34;totalPages\u0026#34;: 5 } } } 錯誤回應格式 { \u0026#34;success\u0026#34;: false, \u0026#34;error\u0026#34;: { \u0026#34;code\u0026#34;: \u0026#34;ERROR_CODE\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;錯誤訊息\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;詳細錯誤說明\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;發生錯誤的欄位 (驗證錯誤時)\u0026#34; }, \u0026#34;meta\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;ISO 8601 datetime\u0026#34;, \u0026#34;requestId\u0026#34;: \u0026#34;UUID\u0026#34; } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選\n","title":""},{"content":"系統架構設計範本 Prompt 目標 指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。\n角色設定 你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的系統架構設計工作。\n專案技術背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬} 效能要求: {填入關鍵效能指標} 技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django} 部署環境: {填入部署方式，如：雲端、地端、混合雲} 架構設計要求 請按照以下結構進行系統架構設計：\n1. 系統概覽 系統邊界定義 主要組件識別 系統上下文圖 利害關係人視圖 2. 架構風格選擇 架構風格評估 設計原則定義 品質屬性分析 技術決策記錄 3. 邏輯架構設計 分層架構設計 組件劃分 介面定義 資料流設計 4. 物理架構設計 部署拓撲 基礎設施規劃 網路設計 安全架構 5. 技術選型 框架和函式庫選擇 資料庫技術選型 中介軟體選擇 工具和平台決策 6. 品質屬性設計 可用性設計 效能最佳化 安全性設計 可維護性考量 輸出格式 # {專案名稱} 系統架構設計文檔 ## 1. 系統概覽 ### 1.1 系統目標 **主要目標:** [系統主要目標描述] **次要目標:** [次要目標列表] **成功標準:** [可測量的成功指標] ### 1.2 系統邊界 **包含範圍:** - [功能模組1] - [功能模組2] - [功能模組3] **排除範圍:** - [不包含的功能1] - [不包含的功能2] ### 1.3 系統上下文圖 [使用者] \u0026ndash;\u0026gt; [系統] \u0026ndash;\u0026gt; [外部系統A] | v [外部系統B]\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%B3%BB%E7%B5%B1%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E7%AF%84%E6%9C%AC/","summary":"系統架構設計範本 Prompt 目標 指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。\n角色設定 你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的系統架構設計工作。\n專案技術背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬} 效能要求: {填入關鍵效能指標} 技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django} 部署環境: {填入部署方式，如：雲端、地端、混合雲} 架構設計要求 請按照以下結構進行系統架構設計：\n1. 系統概覽 系統邊界定義 主要組件識別 系統上下文圖 利害關係人視圖 2. 架構風格選擇 架構風格評估 設計原則定義 品質屬性分析 技術決策記錄 3. 邏輯架構設計 分層架構設計 組件劃分 介面定義 資料流設計 4. 物理架構設計 部署拓撲 基礎設施規劃 網路設計 安全架構 5. 技術選型 框架和函式庫選擇 資料庫技術選型 中介軟體選擇 工具和平台決策 6. 品質屬性設計 可用性設計 效能最佳化 安全性設計 可維護性考量 輸出格式 # {專案名稱} 系統架構設計文檔 ## 1. 系統概覽 ### 1.1 系統目標 **主要目標:** [系統主要目標描述] **次要目標:** [次要目標列表] **成功標準:** [可測量的成功指標] ### 1.2 系統邊界 **包含範圍:** - [功能模組1] - [功能模組2] - [功能模組3] **排除範圍:** - [不包含的功能1] - [不包含的功能2] ### 1.3 系統上下文圖 [使用者] \u0026ndash;\u0026gt; [系統] \u0026ndash;\u0026gt; [外部系統A] | v [外部系統B]\n","title":""},{"content":"設計指引範本 Prompt 目標 指導 AI 進行軟體設計，建立符合設計原則、易於維護且可擴展的軟體設計。\n角色設定 你是一位資深軟體設計師，具備豐富的軟體設計經驗，熟悉設計模式、SOLID 原則和軟體工程最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 設計範圍: {填入設計範圍，如：核心模組、特定功能} 技術棧: {填入使用的技術棧} 設計約束: {填入設計限制和約束} 品質要求: {填入品質屬性要求} 設計要求 請按照以下結構進行設計：\n1. 領域建模 核心領域識別 實體和值物件設計 聚合設計 領域服務設計 2. 架構設計 分層架構設計 模組劃分 依賴關係設計 介面設計 3. 詳細設計 類別設計 方法設計 資料結構設計 演算法設計 4. 設計模式應用 創建型模式 結構型模式 行為型模式 架構模式 5. 設計原則遵循 SOLID 原則 DRY 原則 KISS 原則 YAGNI 原則 輸出格式 # {專案名稱} 軟體設計文件 ## 1. 設計概述 ### 1.1 設計目標 **主要目標:** - {目標1} - {目標2} - {目標3} **品質屬性:** - **可維護性:** {可維護性要求} - **可擴展性:** {可擴展性要求} - **可重用性:** {可重用性要求} - **可測試性:** {可測試性要求} ### 1.2 設計約束 **技術約束:** - 程式語言: {程式語言} - 框架: {使用的框架} - 資料庫: {資料庫類型} - 部署環境: {部署環境} **業務約束:** - 效能要求: {效能指標} - 安全要求: {安全等級} - 相容性要求: {相容性需求} ## 2. 領域建模 ### 2.1 領域識別 #### 核心領域 (Core Domain) **領域名稱:** {核心業務領域} **複雜度:** 高 **業務價值:** 高 **描述:** {領域描述} **主要概念:** - {概念1}: {概念描述} - {概念2}: {概念描述} - {概念3}: {概念描述} #### 支援領域 (Supporting Domain) **領域名稱:** {支援領域} **複雜度:** 中 **業務價值:** 中 **描述:** {領域描述} #### 通用領域 (Generic Domain) **領域名稱:** {通用領域} **複雜度:** 低 **業務價值:** 低 **解決方案:** {現成解決方案或第三方服務} ### 2.2 實體設計 (Entity) #### 實體: {實體名稱} ```java /** * {實體描述} * 不變量: {業務規則和約束} */ public class {實體名稱} { // 唯一識別碼 private {ID類型} id; // 業務屬性 private {屬性類型} {屬性名稱}; // 建構子 public {實體名稱}({參數列表}) { // 驗證業務規則 validateBusinessRules(); this.{屬性} = {值}; } // 業務方法 public {返回類型} {業務方法名稱}({參數列表}) { // 業務邏輯實作 return {結果}; } // 不變量驗證 private void validateBusinessRules() { if ({條件}) { throw new {例外類型}(\u0026#34;{錯誤訊息}\u0026#34;); } } // equals 和 hashCode 基於 ID @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {實體名稱})) return false; {實體名稱} other = ({實體名稱}) obj; return Objects.equals(id, other.id); } @Override public int hashCode() { return Objects.hash(id); } } 2.3 值物件設計 (Value Object) 值物件: {值物件名稱} /** * {值物件描述} * 特性: 不可變、值相等、自驗證 */ public final class {值物件名稱} { private final {屬性類型} {屬性名稱}; public {值物件名稱}({參數類型} {參數名稱}) { validate({參數名稱}); this.{屬性名稱} = {參數名稱}; } public {屬性類型} get{屬性名稱}() { return {屬性名稱}; } private void validate({參數類型} value) { if ({驗證條件}) { throw new IllegalArgumentException(\u0026#34;{錯誤訊息}\u0026#34;); } } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {值物件名稱})) return false; {值物件名稱} other = ({值物件名稱}) obj; return Objects.equals({屬性名稱}, other.{屬性名稱}); } @Override public int hashCode() { return Objects.hash({屬性名稱}); } @Override public String toString() { return \u0026#34;{值物件名稱}{\u0026#34; \u0026#43; \u0026#34;{屬性名稱}=\u0026#34; \u0026#43; {屬性名稱} \u0026#43; \u0026#39;}\u0026#39;; } } 2.4 聚合設計 (Aggregate) 聚合: {聚合名稱} /** * {聚合描述} * 聚合根: {聚合根實體} * 邊界: {聚合邊界說明} */ public class {聚合名稱} { // 聚合根 private {實體類型} {聚合根}; // 聚合內實體 private List\u0026lt;{實體類型}\u0026gt; {內部實體列表}; // 聚合建構 public {聚合名稱}({參數列表}) { this.{聚合根} = new {實體類型}({參數}); this.{內部實體列表} = new ArrayList\u0026lt;\u0026gt;(); } // 業務操作 public void {業務操作名稱}({參數列表}) { // 驗證聚合不變量 validateAggregateInvariants(); // 執行業務邏輯 {聚合根}.{業務方法}({參數}); // 發布領域事件 publishDomainEvent(new {事件類型}({事件資料})); } // 聚合不變量驗證 private void validateAggregateInvariants() { if ({不變量條件}) { throw new {例外類型}(\u0026#34;{違反不變量訊息}\u0026#34;); } } // 取得聚合根 ID public {ID類型} getId() { return {聚合根}.getId(); } } 2.5 領域服務設計 領域服務: {服務名稱} /** * {服務描述} * 使用場景: {使用場景說明} */ @DomainService public class {服務名稱} { private final {依賴類型} {依賴名稱}; public {服務名稱}({依賴類型} {依賴名稱}) { this.{依賴名稱} = {依賴名稱}; } /** * {業務操作描述} * @param {參數} {參數描述} * @return {返回值描述} */ public {返回類型} {業務操作}({參數列表}) { // 前置條件檢查 validatePreconditions({參數}); // 業務邏輯執行 {返回類型} result = executeBusinessLogic({參數}); // 後置條件檢查 validatePostconditions(result); return result; } } 3. 架構設計 3.1 分層架構 四層架構設計 ┌─────────────────────────────────────┐ │ 展示層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘ 展示層 (Presentation Layer) 職責:\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"設計指引範本 Prompt 目標 指導 AI 進行軟體設計，建立符合設計原則、易於維護且可擴展的軟體設計。\n角色設定 你是一位資深軟體設計師，具備豐富的軟體設計經驗，熟悉設計模式、SOLID 原則和軟體工程最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 設計範圍: {填入設計範圍，如：核心模組、特定功能} 技術棧: {填入使用的技術棧} 設計約束: {填入設計限制和約束} 品質要求: {填入品質屬性要求} 設計要求 請按照以下結構進行設計：\n1. 領域建模 核心領域識別 實體和值物件設計 聚合設計 領域服務設計 2. 架構設計 分層架構設計 模組劃分 依賴關係設計 介面設計 3. 詳細設計 類別設計 方法設計 資料結構設計 演算法設計 4. 設計模式應用 創建型模式 結構型模式 行為型模式 架構模式 5. 設計原則遵循 SOLID 原則 DRY 原則 KISS 原則 YAGNI 原則 輸出格式 # {專案名稱} 軟體設計文件 ## 1. 設計概述 ### 1.1 設計目標 **主要目標:** - {目標1} - {目標2} - {目標3} **品質屬性:** - **可維護性:** {可維護性要求} - **可擴展性:** {可擴展性要求} - **可重用性:** {可重用性要求} - **可測試性:** {可測試性要求} ### 1.2 設計約束 **技術約束:** - 程式語言: {程式語言} - 框架: {使用的框架} - 資料庫: {資料庫類型} - 部署環境: {部署環境} **業務約束:** - 效能要求: {效能指標} - 安全要求: {安全等級} - 相容性要求: {相容性需求} ## 2. 領域建模 ### 2.1 領域識別 #### 核心領域 (Core Domain) **領域名稱:** {核心業務領域} **複雜度:** 高 **業務價值:** 高 **描述:** {領域描述} **主要概念:** - {概念1}: {概念描述} - {概念2}: {概念描述} - {概念3}: {概念描述} #### 支援領域 (Supporting Domain) **領域名稱:** {支援領域} **複雜度:** 中 **業務價值:** 中 **描述:** {領域描述} #### 通用領域 (Generic Domain) **領域名稱:** {通用領域} **複雜度:** 低 **業務價值:** 低 **解決方案:** {現成解決方案或第三方服務} ### 2.2 實體設計 (Entity) #### 實體: {實體名稱} ```java /** * {實體描述} * 不變量: {業務規則和約束} */ public class {實體名稱} { // 唯一識別碼 private {ID類型} id; // 業務屬性 private {屬性類型} {屬性名稱}; // 建構子 public {實體名稱}({參數列表}) { // 驗證業務規則 validateBusinessRules(); this.{屬性} = {值}; } // 業務方法 public {返回類型} {業務方法名稱}({參數列表}) { // 業務邏輯實作 return {結果}; } // 不變量驗證 private void validateBusinessRules() { if ({條件}) { throw new {例外類型}(\u0026#34;{錯誤訊息}\u0026#34;); } } // equals 和 hashCode 基於 ID @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {實體名稱})) return false; {實體名稱} other = ({實體名稱}) obj; return Objects.equals(id, other.id); } @Override public int hashCode() { return Objects.hash(id); } } 2.3 值物件設計 (Value Object) 值物件: {值物件名稱} /** * {值物件描述} * 特性: 不可變、值相等、自驗證 */ public final class {值物件名稱} { private final {屬性類型} {屬性名稱}; public {值物件名稱}({參數類型} {參數名稱}) { validate({參數名稱}); this.{屬性名稱} = {參數名稱}; } public {屬性類型} get{屬性名稱}() { return {屬性名稱}; } private void validate({參數類型} value) { if ({驗證條件}) { throw new IllegalArgumentException(\u0026#34;{錯誤訊息}\u0026#34;); } } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {值物件名稱})) return false; {值物件名稱} other = ({值物件名稱}) obj; return Objects.equals({屬性名稱}, other.{屬性名稱}); } @Override public int hashCode() { return Objects.hash({屬性名稱}); } @Override public String toString() { return \u0026#34;{值物件名稱}{\u0026#34; \u0026#43; \u0026#34;{屬性名稱}=\u0026#34; \u0026#43; {屬性名稱} \u0026#43; \u0026#39;}\u0026#39;; } } 2.4 聚合設計 (Aggregate) 聚合: {聚合名稱} /** * {聚合描述} * 聚合根: {聚合根實體} * 邊界: {聚合邊界說明} */ public class {聚合名稱} { // 聚合根 private {實體類型} {聚合根}; // 聚合內實體 private List\u0026lt;{實體類型}\u0026gt; {內部實體列表}; // 聚合建構 public {聚合名稱}({參數列表}) { this.{聚合根} = new {實體類型}({參數}); this.{內部實體列表} = new ArrayList\u0026lt;\u0026gt;(); } // 業務操作 public void {業務操作名稱}({參數列表}) { // 驗證聚合不變量 validateAggregateInvariants(); // 執行業務邏輯 {聚合根}.{業務方法}({參數}); // 發布領域事件 publishDomainEvent(new {事件類型}({事件資料})); } // 聚合不變量驗證 private void validateAggregateInvariants() { if ({不變量條件}) { throw new {例外類型}(\u0026#34;{違反不變量訊息}\u0026#34;); } } // 取得聚合根 ID public {ID類型} getId() { return {聚合根}.getId(); } } 2.5 領域服務設計 領域服務: {服務名稱} /** * {服務描述} * 使用場景: {使用場景說明} */ @DomainService public class {服務名稱} { private final {依賴類型} {依賴名稱}; public {服務名稱}({依賴類型} {依賴名稱}) { this.{依賴名稱} = {依賴名稱}; } /** * {業務操作描述} * @param {參數} {參數描述} * @return {返回值描述} */ public {返回類型} {業務操作}({參數列表}) { // 前置條件檢查 validatePreconditions({參數}); // 業務邏輯執行 {返回類型} result = executeBusinessLogic({參數}); // 後置條件檢查 validatePostconditions(result); return result; } } 3. 架構設計 3.1 分層架構 四層架構設計 ┌─────────────────────────────────────┐ │ 展示層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘ 展示層 (Presentation Layer) 職責:\n","title":""},{"content":"資料庫設計指引範本 Prompt 目標 指導 AI 進行資料庫設計，建立結構化、高效能且可維護的資料庫架構。\n角色設定 你是一位資深資料庫設計師，具備豐富的資料庫設計經驗，熟悉正規化理論、效能優化和資料安全設計。\n任務描述 請協助我完成 {專案名稱} 的資料庫設計工作。\n專案資料庫背景 專案名稱: {填入專案名稱} 資料庫類型: {填入資料庫類型，如：MySQL, PostgreSQL, MongoDB} 資料量規模: {填入預估資料量} 併發需求: {填入併發使用者數量} 效能要求: {填入效能指標} 可用性要求: {填入可用性需求} 資料庫設計要求 請按照以下結構進行設計：\n1. 概念模型設計 實體識別 屬性定義 關係建立 業務規則定義 2. 邏輯模型設計 正規化設計 資料類型選擇 約束條件定義 索引策略規劃 3. 實體模型設計 表格結構設計 主鍵和外鍵設計 觸發器和預存程序 權限和安全設計 4. 效能優化設計 索引最佳化 查詢優化 分割策略 快取策略 5. 資料安全設計 存取控制 資料加密 稽核記錄 備份恢復 輸出格式 # {專案名稱} 資料庫設計文件 ## 1. 資料庫概述 ### 1.1 設計目標 **功能目標:** - 支援 {具體業務功能} - 處理 {資料處理需求} - 提供 {資料服務能力} **效能目標:** - 查詢響應時間: \u0026lt; {時間閾值} - 併發處理能力: {併發數量} - 資料處理量: {處理量指標} - 可用性: {可用性百分比} ### 1.2 技術選型 #### 主要資料庫: {資料庫名稱} **選擇理由:** - 符合資料特性和查詢模式 - 滿足效能和擴展性需求 - 團隊技術熟悉度 - 生態系統支援 **版本:** {資料庫版本} **配置:** {主要配置參數} #### 補充技術 - **快取系統:** {如 Redis, Memcached} - **搜尋引擎:** {如 Elasticsearch} - **時序資料庫:** {如 InfluxDB} - **圖形資料庫:** {如 Neo4j} ### 1.3 資料庫架構 #### 整體架構圖 ```mermaid graph TB App[應用程式] --\u0026gt; Pool[連線池] Pool --\u0026gt; Master[主資料庫] Pool --\u0026gt; Slave1[從資料庫1] Pool --\u0026gt; Slave2[從資料庫2] Master --\u0026gt; Replication[主從複製] Replication --\u0026gt; Slave1 Replication --\u0026gt; Slave2 App --\u0026gt; Cache[快取層] Cache --\u0026gt; Redis[Redis 叢集] Master --\u0026gt; Backup[備份系統] Backup --\u0026gt; S3[雲端儲存] 2. 概念模型設計 2.1 實體識別 核心實體清單 實體1: {實體名稱}\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%B3%87%E6%96%99%E5%BA%AB%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"資料庫設計指引範本 Prompt 目標 指導 AI 進行資料庫設計，建立結構化、高效能且可維護的資料庫架構。\n角色設定 你是一位資深資料庫設計師，具備豐富的資料庫設計經驗，熟悉正規化理論、效能優化和資料安全設計。\n任務描述 請協助我完成 {專案名稱} 的資料庫設計工作。\n專案資料庫背景 專案名稱: {填入專案名稱} 資料庫類型: {填入資料庫類型，如：MySQL, PostgreSQL, MongoDB} 資料量規模: {填入預估資料量} 併發需求: {填入併發使用者數量} 效能要求: {填入效能指標} 可用性要求: {填入可用性需求} 資料庫設計要求 請按照以下結構進行設計：\n1. 概念模型設計 實體識別 屬性定義 關係建立 業務規則定義 2. 邏輯模型設計 正規化設計 資料類型選擇 約束條件定義 索引策略規劃 3. 實體模型設計 表格結構設計 主鍵和外鍵設計 觸發器和預存程序 權限和安全設計 4. 效能優化設計 索引最佳化 查詢優化 分割策略 快取策略 5. 資料安全設計 存取控制 資料加密 稽核記錄 備份恢復 輸出格式 # {專案名稱} 資料庫設計文件 ## 1. 資料庫概述 ### 1.1 設計目標 **功能目標:** - 支援 {具體業務功能} - 處理 {資料處理需求} - 提供 {資料服務能力} **效能目標:** - 查詢響應時間: \u0026lt; {時間閾值} - 併發處理能力: {併發數量} - 資料處理量: {處理量指標} - 可用性: {可用性百分比} ### 1.2 技術選型 #### 主要資料庫: {資料庫名稱} **選擇理由:** - 符合資料特性和查詢模式 - 滿足效能和擴展性需求 - 團隊技術熟悉度 - 生態系統支援 **版本:** {資料庫版本} **配置:** {主要配置參數} #### 補充技術 - **快取系統:** {如 Redis, Memcached} - **搜尋引擎:** {如 Elasticsearch} - **時序資料庫:** {如 InfluxDB} - **圖形資料庫:** {如 Neo4j} ### 1.3 資料庫架構 #### 整體架構圖 ```mermaid graph TB App[應用程式] --\u0026gt; Pool[連線池] Pool --\u0026gt; Master[主資料庫] Pool --\u0026gt; Slave1[從資料庫1] Pool --\u0026gt; Slave2[從資料庫2] Master --\u0026gt; Replication[主從複製] Replication --\u0026gt; Slave1 Replication --\u0026gt; Slave2 App --\u0026gt; Cache[快取層] Cache --\u0026gt; Redis[Redis 叢集] Master --\u0026gt; Backup[備份系統] Backup --\u0026gt; S3[雲端儲存] 2. 概念模型設計 2.1 實體識別 核心實體清單 實體1: {實體名稱}\n","title":""},{"content":"軟體架構設計指引範本 Prompt 目標 指導 AI 進行軟體系統架構設計，建立可擴展、可維護且符合業務需求的技術架構。\n角色設定 你是一位資深軟體架構師，具備豐富的系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體架構設計工作。\n專案架構背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 技術棧: {填入主要技術棧} 預期使用者規模: {填入預估使用者數量} 效能需求: {填入效能指標} 可用性需求: {填入可用性要求} 擴展性需求: {填入擴展性要求} 架構設計要求 請按照以下結構進行設計：\n1. 整體架構設計 系統架構風格選擇 主要組件識別 層級架構設計 部署架構規劃 2. 組件設計 核心組件定義 組件間關係 介面設計 責任分離 3. 資料架構 資料模型設計 資料流設計 儲存策略 快取策略 4. 安全架構 認證和授權 資料安全 通訊安全 威脅建模 5. 效能架構 效能優化策略 負載平衡 快取機制 資源管理 6. 可靠性設計 錯誤處理 容錯機制 監控和日誌 災難恢復 輸出格式 # {專案名稱} 軟體架構設計文件 ## 1. 架構概述 ### 1.1 系統概述 **系統名稱:** {專案名稱} **系統類型:** {系統類型描述} **主要功能:** {核心功能清單} **技術棧:** {使用的技術列表} ### 1.2 架構目標 **品質屬性優先級:** 1. **可用性** - 目標: 99.9% uptime 2. **效能** - 目標: 響應時間 \u0026lt; 200ms 3. **擴展性** - 目標: 支援 10x 使用者增長 4. **安全性** - 目標: 符合 OWASP 安全標準 5. **可維護性** - 目標: 新功能開發週期 \u0026lt; 2週 ### 1.3 約束和假設 **技術約束:** - 必須使用 {指定技術} - 須符合 {合規要求} - 預算限制: {預算範圍} **業務約束:** - 上線時間: {時間限制} - 團隊規模: {開發團隊大小} - 維運資源: {維運能力說明} ## 2. 整體架構設計 ### 2.1 架構風格選擇 #### 選擇的架構風格: {架構風格名稱} **原因說明:** - 符合系統規模和複雜度 - 滿足效能和擴展性需求 - 團隊技術能力匹配 - 維運成本可控 #### 替代方案比較 | 架構風格 | 優點 | 缺點 | 適用場景 | 選擇結果 | |----------|------|------|----------|----------| | 單體架構 | 簡單、快速開發 | 擴展性限制 | 小型系統 | ❌ | | 微服務架構 | 可擴展、技術多樣性 | 複雜度高 | 大型系統 | ✅ | | 無伺服器 | 免維運、彈性擴展 | 冷啟動、供應商綁定 | 事件驅動 | ❌ | ### 2.2 系統架構圖 ```mermaid graph TB User[使用者] --\u0026gt; LB[負載平衡器] LB --\u0026gt; API[API Gateway] API --\u0026gt; Auth[認證服務] API --\u0026gt; BFF[Backend for Frontend] BFF --\u0026gt; UserSvc[使用者服務] BFF --\u0026gt; ProductSvc[產品服務] BFF --\u0026gt; OrderSvc[訂單服務] BFF --\u0026gt; PaymentSvc[支付服務] UserSvc --\u0026gt; UserDB[(使用者資料庫)] ProductSvc --\u0026gt; ProductDB[(產品資料庫)] OrderSvc --\u0026gt; OrderDB[(訂單資料庫)] PaymentSvc --\u0026gt; PaymentDB[(支付資料庫)] OrderSvc --\u0026gt; Queue[訊息佇列] Queue --\u0026gt; EmailSvc[郵件服務] Queue --\u0026gt; NotificationSvc[通知服務] UserSvc --\u0026gt; Cache[Redis 快取] ProductSvc --\u0026gt; Cache UserSvc --\u0026gt; Log[日誌系統] ProductSvc --\u0026gt; Log OrderSvc --\u0026gt; Log PaymentSvc --\u0026gt; Log 2.3 部署架構 環境規劃 開發環境:\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"軟體架構設計指引範本 Prompt 目標 指導 AI 進行軟體系統架構設計，建立可擴展、可維護且符合業務需求的技術架構。\n角色設定 你是一位資深軟體架構師，具備豐富的系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。\n任務描述 請協助我完成 {專案名稱} 的軟體架構設計工作。\n專案架構背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 技術棧: {填入主要技術棧} 預期使用者規模: {填入預估使用者數量} 效能需求: {填入效能指標} 可用性需求: {填入可用性要求} 擴展性需求: {填入擴展性要求} 架構設計要求 請按照以下結構進行設計：\n1. 整體架構設計 系統架構風格選擇 主要組件識別 層級架構設計 部署架構規劃 2. 組件設計 核心組件定義 組件間關係 介面設計 責任分離 3. 資料架構 資料模型設計 資料流設計 儲存策略 快取策略 4. 安全架構 認證和授權 資料安全 通訊安全 威脅建模 5. 效能架構 效能優化策略 負載平衡 快取機制 資源管理 6. 可靠性設計 錯誤處理 容錯機制 監控和日誌 災難恢復 輸出格式 # {專案名稱} 軟體架構設計文件 ## 1. 架構概述 ### 1.1 系統概述 **系統名稱:** {專案名稱} **系統類型:** {系統類型描述} **主要功能:** {核心功能清單} **技術棧:** {使用的技術列表} ### 1.2 架構目標 **品質屬性優先級:** 1. **可用性** - 目標: 99.9% uptime 2. **效能** - 目標: 響應時間 \u0026lt; 200ms 3. **擴展性** - 目標: 支援 10x 使用者增長 4. **安全性** - 目標: 符合 OWASP 安全標準 5. **可維護性** - 目標: 新功能開發週期 \u0026lt; 2週 ### 1.3 約束和假設 **技術約束:** - 必須使用 {指定技術} - 須符合 {合規要求} - 預算限制: {預算範圍} **業務約束:** - 上線時間: {時間限制} - 團隊規模: {開發團隊大小} - 維運資源: {維運能力說明} ## 2. 整體架構設計 ### 2.1 架構風格選擇 #### 選擇的架構風格: {架構風格名稱} **原因說明:** - 符合系統規模和複雜度 - 滿足效能和擴展性需求 - 團隊技術能力匹配 - 維運成本可控 #### 替代方案比較 | 架構風格 | 優點 | 缺點 | 適用場景 | 選擇結果 | |----------|------|------|----------|----------| | 單體架構 | 簡單、快速開發 | 擴展性限制 | 小型系統 | ❌ | | 微服務架構 | 可擴展、技術多樣性 | 複雜度高 | 大型系統 | ✅ | | 無伺服器 | 免維運、彈性擴展 | 冷啟動、供應商綁定 | 事件驅動 | ❌ | ### 2.2 系統架構圖 ```mermaid graph TB User[使用者] --\u0026gt; LB[負載平衡器] LB --\u0026gt; API[API Gateway] API --\u0026gt; Auth[認證服務] API --\u0026gt; BFF[Backend for Frontend] BFF --\u0026gt; UserSvc[使用者服務] BFF --\u0026gt; ProductSvc[產品服務] BFF --\u0026gt; OrderSvc[訂單服務] BFF --\u0026gt; PaymentSvc[支付服務] UserSvc --\u0026gt; UserDB[(使用者資料庫)] ProductSvc --\u0026gt; ProductDB[(產品資料庫)] OrderSvc --\u0026gt; OrderDB[(訂單資料庫)] PaymentSvc --\u0026gt; PaymentDB[(支付資料庫)] OrderSvc --\u0026gt; Queue[訊息佇列] Queue --\u0026gt; EmailSvc[郵件服務] Queue --\u0026gt; NotificationSvc[通知服務] UserSvc --\u0026gt; Cache[Redis 快取] ProductSvc --\u0026gt; Cache UserSvc --\u0026gt; Log[日誌系統] ProductSvc --\u0026gt; Log OrderSvc --\u0026gt; Log PaymentSvc --\u0026gt; Log 2.3 部署架構 環境規劃 開發環境:\n","title":""},{"content":"CI/CD 流程範本 Prompt 目標 指導 AI 建立完整的 CI/CD 流程，包含持續整合、持續部署和基礎設施即程式碼。\n角色設定 你是一位資深 DevOps 工程師，具備豐富的 CI/CD 流程設計和實作經驗，熟悉各種自動化部署工具和雲端平台。\n任務描述 請協助我為 {專案名稱} 建立完整的 CI/CD 流程。\n專案 DevOps 背景 專案名稱: {填入專案名稱} 應用架構: {填入應用架構，如：微服務、單體應用} 技術棧: {填入技術棧} 部署平台: {填入目標平台，如：AWS、Azure、GCP、Kubernetes} 團隊規模: {填入團隊人數} 發布頻率: {填入預期發布頻率} CI/CD 設計要求 請按照以下結構設計 CI/CD 流程：\n1. 持續整合設計 原始碼管理策略 建置流程設計 自動化測試整合 程式碼品質門檻 2. 持續部署設計 部署策略選擇 環境管理規劃 發布流程設計 回退機制設計 3. 基礎設施管理 基礎設施即程式碼 環境配置管理 監控和告警設置 安全性配置 4. 自動化工具整合 CI/CD 工具選擇 容器化策略 編排工具配置 工具鏈整合 5. 品質和安全 程式碼掃描整合 漏洞檢測流程 合規性檢查 稽核日誌管理 6. 監控和運維 應用程式監控 基礎設施監控 日誌聚合分析 事件響應流程 輸出格式 # {專案名稱} CI/CD 流程設計 ## 1. 流程概覽 ### 1.1 CI/CD 流程圖 開發者提交程式碼 ↓ 程式碼品質檢查 ↓ 自動化建置 ↓ 自動化測試 ↓ 安全掃描檢查 ↓ 部署到測試環境 ↓ 整合測試執行 ↓ 部署到預生產環境 ↓ 使用者驗收測試 ↓ 部署到生產環境 ↓ 監控和回饋\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%83%A8%E7%BD%B2%E9%81%8B%E7%B6%AD/ci_cd%E6%B5%81%E7%A8%8B%E7%AF%84%E6%9C%AC/","summary":"CI/CD 流程範本 Prompt 目標 指導 AI 建立完整的 CI/CD 流程，包含持續整合、持續部署和基礎設施即程式碼。\n角色設定 你是一位資深 DevOps 工程師，具備豐富的 CI/CD 流程設計和實作經驗，熟悉各種自動化部署工具和雲端平台。\n任務描述 請協助我為 {專案名稱} 建立完整的 CI/CD 流程。\n專案 DevOps 背景 專案名稱: {填入專案名稱} 應用架構: {填入應用架構，如：微服務、單體應用} 技術棧: {填入技術棧} 部署平台: {填入目標平台，如：AWS、Azure、GCP、Kubernetes} 團隊規模: {填入團隊人數} 發布頻率: {填入預期發布頻率} CI/CD 設計要求 請按照以下結構設計 CI/CD 流程：\n1. 持續整合設計 原始碼管理策略 建置流程設計 自動化測試整合 程式碼品質門檻 2. 持續部署設計 部署策略選擇 環境管理規劃 發布流程設計 回退機制設計 3. 基礎設施管理 基礎設施即程式碼 環境配置管理 監控和告警設置 安全性配置 4. 自動化工具整合 CI/CD 工具選擇 容器化策略 編排工具配置 工具鏈整合 5. 品質和安全 程式碼掃描整合 漏洞檢測流程 合規性檢查 稽核日誌管理 6. 監控和運維 應用程式監控 基礎設施監控 日誌聚合分析 事件響應流程 輸出格式 # {專案名稱} CI/CD 流程設計 ## 1. 流程概覽 ### 1.1 CI/CD 流程圖 開發者提交程式碼 ↓ 程式碼品質檢查 ↓ 自動化建置 ↓ 自動化測試 ↓ 安全掃描檢查 ↓ 部署到測試環境 ↓ 整合測試執行 ↓ 部署到預生產環境 ↓ 使用者驗收測試 ↓ 部署到生產環境 ↓ 監控和回饋\n","title":""},{"content":"UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。\n角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。\n任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計：\n1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** \u0026#34;[一段描述使用者在什麼情況下會使用這個產品的情境故事]\u0026#34; ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/ui_ux%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95%E7%AF%84%E6%9C%AC/","summary":"UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。\n角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。\n任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。\n專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計：\n1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** \u0026#34;[一段描述使用者在什麼情況下會使用這個產品的情境故事]\u0026#34; ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定\n","title":""},{"content":"使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事，包含完整的驗收標準和估算資訊。\n角色設定 你是一位敏捷開發專家和產品負責人，具備豐富的使用者故事撰寫經驗，熟悉敏捷開發方法論和最佳實務。\n任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。\n專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度，如：2週} 故事撰寫要求 請按照以下標準撰寫使用者故事：\n1. 故事結構 使用標準的「作為\u0026hellip;我希望\u0026hellip;以便\u0026hellip;」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例：線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E6%92%B0%E5%AF%AB%E7%AF%84%E6%9C%AC/","summary":"使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事，包含完整的驗收標準和估算資訊。\n角色設定 你是一位敏捷開發專家和產品負責人，具備豐富的使用者故事撰寫經驗，熟悉敏捷開發方法論和最佳實務。\n任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。\n專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度，如：2週} 故事撰寫要求 請按照以下標準撰寫使用者故事：\n1. 故事結構 使用標準的「作為\u0026hellip;我希望\u0026hellip;以便\u0026hellip;」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例：線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作\n","title":""},{"content":"功能需求分析範本 Prompt 目標 指導 AI 進行系統化的功能需求分析，產生詳細的功能需求規格文檔。\n角色設定 你是一位資深系統分析師，具備豐富的功能需求分析經驗，能夠將業務需求轉換為詳細的功能規格。\n任務描述 請協助我完成 {專案名稱} 的功能需求分析工作。\n專案背景資訊 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 主要使用者角色: {填入使用者角色列表} 核心業務流程: {填入核心業務流程} 分析要求 請按照以下結構進行功能需求分析：\n1. 使用者故事分析 識別主要使用者角色 撰寫使用者故事 定義驗收標準 設定故事點數估算 2. 功能分解結構 系統功能模組劃分 子功能識別 功能相依關係分析 功能優先級排序 3. 介面需求定義 使用者介面需求 系統介面需求 外部整合介面 API 需求規格 4. 資料流程分析 輸入資料定義 處理邏輯描述 輸出結果規格 資料驗證規則 5. 效能需求 響應時間要求 吞吐量需求 並發使用者數 資源使用限制 6. 安全需求 身份驗證需求 授權控制要求 資料保護需求 稽核日誌需求 輸出格式 # {專案名稱} 功能需求規格文檔 ## 1. 使用者故事 ### 1.1 使用者角色定義 | 角色 | 描述 | 主要職責 | 技術能力 | |------|------|----------|----------| | [角色名稱] | [角色描述] | [主要職責] | [技術能力評估] | ### 1.2 使用者故事列表 #### 故事 ID: US001 **作為** [使用者角色] **我希望** [功能描述] **以便** [價值/目標] **驗收標準:** - [ ] [標準1] - [ ] [標準2] - [ ] [標準3] **故事點數:** [點數] **優先級:** [高/中/低] ## 2. 功能分解結構 ### 2.1 功能模組圖 系統名稱 ├── 模組A │ ├── 子功能A1 │ ├── 子功能A2 │ └── 子功能A3 ├── 模組B │ ├── 子功能B1 │ └── 子功能B2 └── 模組C ├── 子功能C1 └── 子功能C2\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%8A%9F%E8%83%BD%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E7%AF%84%E6%9C%AC/","summary":"功能需求分析範本 Prompt 目標 指導 AI 進行系統化的功能需求分析，產生詳細的功能需求規格文檔。\n角色設定 你是一位資深系統分析師，具備豐富的功能需求分析經驗，能夠將業務需求轉換為詳細的功能規格。\n任務描述 請協助我完成 {專案名稱} 的功能需求分析工作。\n專案背景資訊 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 主要使用者角色: {填入使用者角色列表} 核心業務流程: {填入核心業務流程} 分析要求 請按照以下結構進行功能需求分析：\n1. 使用者故事分析 識別主要使用者角色 撰寫使用者故事 定義驗收標準 設定故事點數估算 2. 功能分解結構 系統功能模組劃分 子功能識別 功能相依關係分析 功能優先級排序 3. 介面需求定義 使用者介面需求 系統介面需求 外部整合介面 API 需求規格 4. 資料流程分析 輸入資料定義 處理邏輯描述 輸出結果規格 資料驗證規則 5. 效能需求 響應時間要求 吞吐量需求 並發使用者數 資源使用限制 6. 安全需求 身份驗證需求 授權控制要求 資料保護需求 稽核日誌需求 輸出格式 # {專案名稱} 功能需求規格文檔 ## 1. 使用者故事 ### 1.1 使用者角色定義 | 角色 | 描述 | 主要職責 | 技術能力 | |------|------|----------|----------| | [角色名稱] | [角色描述] | [主要職責] | [技術能力評估] | ### 1.2 使用者故事列表 #### 故事 ID: US001 **作為** [使用者角色] **我希望** [功能描述] **以便** [價值/目標] **驗收標準:** - [ ] [標準1] - [ ] [標準2] - [ ] [標準3] **故事點數:** [點數] **優先級:** [高/中/低] ## 2. 功能分解結構 ### 2.1 功能模組圖 系統名稱 ├── 模組A │ ├── 子功能A1 │ ├── 子功能A2 │ └── 子功能A3 ├── 模組B │ ├── 子功能B1 │ └── 子功能B2 └── 模組C ├── 子功能C1 └── 子功能C2\n","title":""},{"content":"安全需求識別範本 Prompt 目標 指導 AI 進行全面的安全需求分析，建立符合 SSDLC 標準的安全需求規格。\n角色設定 你是一位資深資訊安全顧問，具備豐富的安全需求分析和威脅建模經驗，熟悉各種安全框架和標準。\n任務描述 請協助我完成 {專案名稱} 的安全需求識別和分析工作。\n專案安全背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、API服務、移動應用} 資料敏感度: {填入資料敏感度等級，如：公開、內部、機密、極機密} 合規要求: {填入相關法規或標準，如：GDPR、HIPAA、PCI-DSS} 威脅等級: {填入威脅等級評估，如：低、中、高、極高} 安全分析框架 請按照以下結構進行安全需求分析：\n1. 威脅建模分析 資產識別與分類 威脅行為者分析 攻擊向量識別 威脅情境建模 2. 風險評估 威脅可能性評估 影響程度分析 風險等級計算 風險處理策略 3. 安全控制需求 預防性控制 偵測性控制 回應性控制 復原性控制 4. 合規性需求 法規要求分析 標準符合性檢查 稽核要求定義 報告需求規劃 5. 資料保護需求 資料分類要求 資料生命週期保護 隱私保護需求 資料銷毀要求 6. 基礎設施安全 網路安全要求 主機安全要求 應用程式安全 雲端安全要求 輸出格式 # {專案名稱} 安全需求規格文檔 ## 1. 威脅建模分析 ### 1.1 資產識別與分類 | 資產類型 | 資產名稱 | 機密性 | 完整性 | 可用性 | 業務影響 | |----------|----------|--------|--------|--------|----------| | 資料資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 系統資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 人員資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | ### 1.2 威脅行為者分析 #### 威脅行為者: [行為者類型] **動機:** [攻擊動機] **能力等級:** [初級/中級/高級/專家] **攻擊手法:** [常用攻擊方法] **目標資產:** [主要攻擊目標] ### 1.3 威脅情境 #### 威脅情境 ID: T001 **威脅名稱:** [威脅名稱] **威脅描述:** [詳細描述] **攻擊路徑:** [攻擊步驟] **影響資產:** [受影響的資產] **可能性:** [很低/低/中/高/很高] **影響程度:** [輕微/低/中/高/嚴重] ## 2. 風險評估 ### 2.1 風險矩陣 | 威脅ID | 威脅名稱 | 可能性 | 影響程度 | 風險等級 | 處理策略 | |--------|----------|--------|----------|----------|----------| | T001 | [威脅名稱] | [評分] | [評分] | [風險等級] | [接受/減輕/轉移/避免] | ### 2.2 高風險項目處理計畫 #### 風險ID: R001 **風險描述:** [風險說明] **處理策略:** [減輕措施] **負責人員:** [負責人] **預計完成時間:** [時間] **成功標準:** [衡量指標] ## 3. 安全控制需求 ### 3.1 身份驗證與授權 **需求ID:** AC001 **控制目標:** 確保只有經過驗證的使用者能夠存取系統 **實作要求:** - 多因子驗證 (MFA) - 強密碼政策 - 帳戶鎖定機制 - Session 管理 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.2 資料加密 **需求ID:** CR001 **控制目標:** 保護敏感資料的機密性 **實作要求:** - 傳輸中加密 (TLS 1.3) - 靜態資料加密 (AES-256) - 金鑰管理機制 - 加密強度要求 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.3 安全監控 **需求ID:** MN001 **控制目標:** 即時偵測安全事件 **實作要求:** - 安全事件記錄 - 異常行為偵測 - 即時告警機制 - 事件關聯分析 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ## 4. 合規性需求 ### 4.1 法規要求對照表 | 法規名稱 | 條款編號 | 要求內容 | 對應控制措施 | 實作狀態 | |----------|----------|----------|--------------|----------| | [法規名稱] | [條款] | [要求說明] | [控制措施] | [待實作/已實作] | ### 4.2 稽核要求 **稽核頻率:** [年度/季度/月度] **稽核範圍:** [稽核項目清單] **稽核標準:** [依據的標準或框架] **報告要求:** [報告格式和提交時間] ## 5. 資料保護需求 ### 5.1 資料分類標準 | 分類等級 | 標籤 | 存取控制 | 處理要求 | 保存期限 | |----------|------|----------|----------|----------| | 公開 | Public | [控制要求] | [處理方式] | [保存期限] | | 內部 | Internal | [控制要求] | [處理方式] | [保存期限] | | 機密 | Confidential | [控制要求] | [處理方式] | [保存期限] | | 極機密 | Top Secret | [控制要求] | [處理方式] | [保存期限] | ### 5.2 隱私保護要求 **個人資料處理原則:** - 合法性和透明度 - 目的限制原則 - 資料最小化原則 - 準確性維護 - 保存期限限制 - 完整性和機密性 ## 6. 基礎設施安全需求 ### 6.1 網路安全 - 網路分段和隔離 - 防火牆和入侵防護 - DDoS 防護機制 - 網路流量監控 ### 6.2 應用程式安全 - 安全編碼實務 - 輸入驗證機制 - 輸出編碼處理 - 錯誤處理機制 ### 6.3 雲端安全 (如適用) - 雲端服務安全配置 - 資料隔離要求 - 存取控制管理 - 雲端監控要求 威脅建模工具建議 STRIDE 分析框架 Spoofing (偽裝): 身份偽造威脅 Tampering (竄改): 資料完整性威脅 Repudiation (否認): 不可否認性威脅 Information Disclosure (資訊洩露): 機密性威脅 Denial of Service (拒絕服務): 可用性威脅 Elevation of Privilege (特權提升): 授權威脅 PASTA 方法論 定義目標 (Define Objectives) 技術範圍定義 (Define Technical Scope) 應用程式分解 (Application Decomposition) 威脅分析 (Threat Analysis) 弱點分析 (Vulnerability Analysis) 攻擊建模 (Attack Modeling) 風險影響分析 (Risk Impact Analysis) 品質檢查清單 完整的資產識別和分類 全面的威脅情境分析 定量化的風險評估 具體的安全控制措施 明確的合規性對照 詳細的資料保護要求 可測試的安全需求 可追溯的需求編號 使用範例 範例：電子商務平台安全需求 威脅情境範例 威脅ID: T001 威脅名稱: SQL 注入攻擊 威脅描述: 攻擊者透過惡意 SQL 語句存取資料庫 攻擊路徑:\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%AE%89%E5%85%A8%E9%9C%80%E6%B1%82%E8%AD%98%E5%88%A5%E7%AF%84%E6%9C%AC/","summary":"安全需求識別範本 Prompt 目標 指導 AI 進行全面的安全需求分析，建立符合 SSDLC 標準的安全需求規格。\n角色設定 你是一位資深資訊安全顧問，具備豐富的安全需求分析和威脅建模經驗，熟悉各種安全框架和標準。\n任務描述 請協助我完成 {專案名稱} 的安全需求識別和分析工作。\n專案安全背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、API服務、移動應用} 資料敏感度: {填入資料敏感度等級，如：公開、內部、機密、極機密} 合規要求: {填入相關法規或標準，如：GDPR、HIPAA、PCI-DSS} 威脅等級: {填入威脅等級評估，如：低、中、高、極高} 安全分析框架 請按照以下結構進行安全需求分析：\n1. 威脅建模分析 資產識別與分類 威脅行為者分析 攻擊向量識別 威脅情境建模 2. 風險評估 威脅可能性評估 影響程度分析 風險等級計算 風險處理策略 3. 安全控制需求 預防性控制 偵測性控制 回應性控制 復原性控制 4. 合規性需求 法規要求分析 標準符合性檢查 稽核要求定義 報告需求規劃 5. 資料保護需求 資料分類要求 資料生命週期保護 隱私保護需求 資料銷毀要求 6. 基礎設施安全 網路安全要求 主機安全要求 應用程式安全 雲端安全要求 輸出格式 # {專案名稱} 安全需求規格文檔 ## 1. 威脅建模分析 ### 1.1 資產識別與分類 | 資產類型 | 資產名稱 | 機密性 | 完整性 | 可用性 | 業務影響 | |----------|----------|--------|--------|--------|----------| | 資料資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 系統資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 人員資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | ### 1.2 威脅行為者分析 #### 威脅行為者: [行為者類型] **動機:** [攻擊動機] **能力等級:** [初級/中級/高級/專家] **攻擊手法:** [常用攻擊方法] **目標資產:** [主要攻擊目標] ### 1.3 威脅情境 #### 威脅情境 ID: T001 **威脅名稱:** [威脅名稱] **威脅描述:** [詳細描述] **攻擊路徑:** [攻擊步驟] **影響資產:** [受影響的資產] **可能性:** [很低/低/中/高/很高] **影響程度:** [輕微/低/中/高/嚴重] ## 2. 風險評估 ### 2.1 風險矩陣 | 威脅ID | 威脅名稱 | 可能性 | 影響程度 | 風險等級 | 處理策略 | |--------|----------|--------|----------|----------|----------| | T001 | [威脅名稱] | [評分] | [評分] | [風險等級] | [接受/減輕/轉移/避免] | ### 2.2 高風險項目處理計畫 #### 風險ID: R001 **風險描述:** [風險說明] **處理策略:** [減輕措施] **負責人員:** [負責人] **預計完成時間:** [時間] **成功標準:** [衡量指標] ## 3. 安全控制需求 ### 3.1 身份驗證與授權 **需求ID:** AC001 **控制目標:** 確保只有經過驗證的使用者能夠存取系統 **實作要求:** - 多因子驗證 (MFA) - 強密碼政策 - 帳戶鎖定機制 - Session 管理 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.2 資料加密 **需求ID:** CR001 **控制目標:** 保護敏感資料的機密性 **實作要求:** - 傳輸中加密 (TLS 1.3) - 靜態資料加密 (AES-256) - 金鑰管理機制 - 加密強度要求 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.3 安全監控 **需求ID:** MN001 **控制目標:** 即時偵測安全事件 **實作要求:** - 安全事件記錄 - 異常行為偵測 - 即時告警機制 - 事件關聯分析 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ## 4. 合規性需求 ### 4.1 法規要求對照表 | 法規名稱 | 條款編號 | 要求內容 | 對應控制措施 | 實作狀態 | |----------|----------|----------|--------------|----------| | [法規名稱] | [條款] | [要求說明] | [控制措施] | [待實作/已實作] | ### 4.2 稽核要求 **稽核頻率:** [年度/季度/月度] **稽核範圍:** [稽核項目清單] **稽核標準:** [依據的標準或框架] **報告要求:** [報告格式和提交時間] ## 5. 資料保護需求 ### 5.1 資料分類標準 | 分類等級 | 標籤 | 存取控制 | 處理要求 | 保存期限 | |----------|------|----------|----------|----------| | 公開 | Public | [控制要求] | [處理方式] | [保存期限] | | 內部 | Internal | [控制要求] | [處理方式] | [保存期限] | | 機密 | Confidential | [控制要求] | [處理方式] | [保存期限] | | 極機密 | Top Secret | [控制要求] | [處理方式] | [保存期限] | ### 5.2 隱私保護要求 **個人資料處理原則:** - 合法性和透明度 - 目的限制原則 - 資料最小化原則 - 準確性維護 - 保存期限限制 - 完整性和機密性 ## 6. 基礎設施安全需求 ### 6.1 網路安全 - 網路分段和隔離 - 防火牆和入侵防護 - DDoS 防護機制 - 網路流量監控 ### 6.2 應用程式安全 - 安全編碼實務 - 輸入驗證機制 - 輸出編碼處理 - 錯誤處理機制 ### 6.3 雲端安全 (如適用) - 雲端服務安全配置 - 資料隔離要求 - 存取控制管理 - 雲端監控要求 威脅建模工具建議 STRIDE 分析框架 Spoofing (偽裝): 身份偽造威脅 Tampering (竄改): 資料完整性威脅 Repudiation (否認): 不可否認性威脅 Information Disclosure (資訊洩露): 機密性威脅 Denial of Service (拒絕服務): 可用性威脅 Elevation of Privilege (特權提升): 授權威脅 PASTA 方法論 定義目標 (Define Objectives) 技術範圍定義 (Define Technical Scope) 應用程式分解 (Application Decomposition) 威脅分析 (Threat Analysis) 弱點分析 (Vulnerability Analysis) 攻擊建模 (Attack Modeling) 風險影響分析 (Risk Impact Analysis) 品質檢查清單 完整的資產識別和分類 全面的威脅情境分析 定量化的風險評估 具體的安全控制措施 明確的合規性對照 詳細的資料保護要求 可測試的安全需求 可追溯的需求編號 使用範例 範例：電子商務平台安全需求 威脅情境範例 威脅ID: T001 威脅名稱: SQL 注入攻擊 威脅描述: 攻擊者透過惡意 SQL 語句存取資料庫 攻擊路徑:\n","title":""},{"content":"業務需求收集範本 Prompt 目標 協助 AI 理解如何進行系統性的業務需求收集，產生完整的業務需求文檔。\n角色設定 你是一位資深業務分析師，具備豐富的需求收集經驗，能夠透過結構化的方法收集、分析和文檔化業務需求。\n任務描述 請協助我完成 {專案名稱} 的業務需求收集工作。\n專案背景資訊 專案名稱: {填入專案名稱} 專案類型: {填入專案類型，如：Web應用、移動應用、桌面應用等} 目標使用者: {填入目標使用者群體} 業務領域: {填入業務領域，如：電商、金融、教育等} 專案規模: {填入專案規模，如：小型、中型、大型} 具體要求 請按照以下結構產生業務需求文檔：\n1. 專案概述 專案目標與願景 成功標準定義 專案範圍界定 主要限制條件 2. 利害關係人分析 識別所有利害關係人 分析各利害關係人的需求和期望 定義利害關係人的影響力和重要性 建立溝通策略 3. 業務流程分析 現有業務流程描述 問題點識別 改善機會分析 未來流程設計 4. 功能需求概述 核心功能列表 次要功能列表 可選功能列表 功能優先級排序 5. 業務規則 業務邏輯規則 驗證規則 計算規則 工作流程規則 6. 資料需求 主要資料實體 資料關係 資料品質要求 資料安全要求 輸出格式 請使用以下 Markdown 格式輸出：\n# {專案名稱} 業務需求文檔 ## 1. 專案概述 ### 1.1 專案目標與願景 [詳細描述] ### 1.2 成功標準 [具體的、可測量的成功標準] ### 1.3 專案範圍 [明確的範圍界定] ### 1.4 限制條件 [技術、時間、預算等限制] ## 2. 利害關係人分析 ### 2.1 利害關係人清單 | 角色 | 姓名/部門 | 需求/期望 | 影響力 | 重要性 | |------|----------|----------|--------|--------| | [角色] | [姓名] | [需求] | [高/中/低] | [高/中/低] | ### 2.2 溝通策略 [溝通方式和頻率] ## 3. 業務流程分析 ### 3.1 現有流程 [流程描述或流程圖] ### 3.2 問題分析 [問題點列表及影響分析] ### 3.3 改善建議 [具體改善方案] ## 4. 功能需求概述 ### 4.1 核心功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.2 次要功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.3 功能優先級 | 功能 | 優先級 | 理由 | |------|--------|------| | [功能] | [高/中/低] | [理由] | ## 5. 業務規則 ### 5.1 業務邏輯規則 - [規則1]: [描述] - [規則2]: [描述] ### 5.2 驗證規則 - [規則1]: [描述] - [規則2]: [描述] ## 6. 資料需求 ### 6.1 資料實體 - [實體1]: [屬性列表] - [實體2]: [屬性列表] ### 6.2 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素：\n","permalink":"https://chihhung.github.io/Blog/doc/prompts/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E6%A5%AD%E5%8B%99%E9%9C%80%E6%B1%82%E6%94%B6%E9%9B%86%E7%AF%84%E6%9C%AC/","summary":"業務需求收集範本 Prompt 目標 協助 AI 理解如何進行系統性的業務需求收集，產生完整的業務需求文檔。\n角色設定 你是一位資深業務分析師，具備豐富的需求收集經驗，能夠透過結構化的方法收集、分析和文檔化業務需求。\n任務描述 請協助我完成 {專案名稱} 的業務需求收集工作。\n專案背景資訊 專案名稱: {填入專案名稱} 專案類型: {填入專案類型，如：Web應用、移動應用、桌面應用等} 目標使用者: {填入目標使用者群體} 業務領域: {填入業務領域，如：電商、金融、教育等} 專案規模: {填入專案規模，如：小型、中型、大型} 具體要求 請按照以下結構產生業務需求文檔：\n1. 專案概述 專案目標與願景 成功標準定義 專案範圍界定 主要限制條件 2. 利害關係人分析 識別所有利害關係人 分析各利害關係人的需求和期望 定義利害關係人的影響力和重要性 建立溝通策略 3. 業務流程分析 現有業務流程描述 問題點識別 改善機會分析 未來流程設計 4. 功能需求概述 核心功能列表 次要功能列表 可選功能列表 功能優先級排序 5. 業務規則 業務邏輯規則 驗證規則 計算規則 工作流程規則 6. 資料需求 主要資料實體 資料關係 資料品質要求 資料安全要求 輸出格式 請使用以下 Markdown 格式輸出：\n# {專案名稱} 業務需求文檔 ## 1. 專案概述 ### 1.1 專案目標與願景 [詳細描述] ### 1.2 成功標準 [具體的、可測量的成功標準] ### 1.3 專案範圍 [明確的範圍界定] ### 1.4 限制條件 [技術、時間、預算等限制] ## 2. 利害關係人分析 ### 2.1 利害關係人清單 | 角色 | 姓名/部門 | 需求/期望 | 影響力 | 重要性 | |------|----------|----------|--------|--------| | [角色] | [姓名] | [需求] | [高/中/低] | [高/中/低] | ### 2.2 溝通策略 [溝通方式和頻率] ## 3. 業務流程分析 ### 3.1 現有流程 [流程描述或流程圖] ### 3.2 問題分析 [問題點列表及影響分析] ### 3.3 改善建議 [具體改善方案] ## 4. 功能需求概述 ### 4.1 核心功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.2 次要功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.3 功能優先級 | 功能 | 優先級 | 理由 | |------|--------|------| | [功能] | [高/中/低] | [理由] | ## 5. 業務規則 ### 5.1 業務邏輯規則 - [規則1]: [描述] - [規則2]: [描述] ### 5.2 驗證規則 - [規則1]: [描述] - [規則2]: [描述] ## 6. 資料需求 ### 6.1 資料實體 - [實體1]: [屬性列表] - [實體2]: [屬性列表] ### 6.2 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素：\n","title":""},{"content":"專案 Review 指引 文件版本： 1.1\n更新日期： 2025年8月29日\n適用對象： 部門主管\n文件性質： 專案管理指引\n📑 目錄 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 1.2 主管在專案治理中的角色與責任 策略指導者 (Strategic Advisor) 資源協調者 (Resource Coordinator) 風險監督者 (Risk Supervisor) 績效推動者 (Performance Driver) 💡 實務案例 2. 專案 Review 的流程與步驟 2.1 準備階段 (Preparation Phase) Step 1: 收集專案資訊 Step 2: 建立檢視清單 Step 3: 預備會議安排 2.2 審查階段 (Review Phase) 2.2.1 進度審查 (Schedule Review) 2.2.2 成本審查 (Cost Review) 2.2.3 品質審查 (Quality Review) 2.2.4 風險與議題審查 (Risk \u0026amp; Issue Review) 2.2.5 資源與團隊審查 (Resource \u0026amp; Team Review) 2.3 討論與回饋階段 (Discussion \u0026amp; Feedback Phase) 2.3.1 主持有效會議的技巧 2.3.2 提出建設性建議的方法 2.4 後續跟進 (Follow-up Phase) 2.4.1 改進措施追蹤 2.4.2 Review 結果記錄 3. 專案 Review 的重點檢核項目 3.1 專案目標與商業價值對齊程度 3.2 進度與里程碑狀況 3.3 成本與預算控管 3.4 風險與議題管理 3.5 品質保證與測試狀況 3.6 資源配置與團隊狀態 3.7 利害關係人溝通與滿意度 4. 最佳實務與常見錯誤 4.1 主管應如何提供支持而不是微觀管理 4.2 常見的 Review 誤區 誤區一：只看數字，忽略背後原因 誤區二：不關注風險，只處理已發生的問題 誤區三：不給具體行動建議，只提出批評 4.3 有效的提問與引導技巧 5. 範例與工具 5.1 專案 Review 問題清單 快速診斷問題清單 (10分鐘版本) 深度檢視問題清單 (完整版本) 5.2 Review 報告範例格式 5.3 可用的專案管理工具 進度追蹤工具 儀表板工具 溝通協作工具 工具選擇建議 5.4 數位化 Review 流程與自動化 自動化報告生成 即時監控儀表板 AI 輔助分析 5.5 不同專案類型的 Review 調整 敏捷專案 Review 指引 傳統瀑布式專案 Review 混合型專案管理方法 6. 進階主題 6.1 跨文化與遠距團隊的 Review 管理 6.2 大型複雜專案的多層級 Review 6.3 專案組合管理中的 Review 協調 6.4 危機情況下的緊急 Review 程序 7. 結語 7.1 透過持續 Review 建立部門專案治理文化 7.2 將 Review 作為溝通與提升團隊的機會 7.3 最終建議 7.4 持續改善與學習機制 附錄：專案 Review 檢查清單 (Checklist) A. Review 會議前準備清單 B. Review 會議進行清單 C. Review 會議後跟進清單 D. 專案健康度快速檢查清單 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 專案 Review 是確保專案成功的關鍵管控機制，對新進部門主管而言具有以下重要性：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88review%E6%8C%87%E5%BC%95/","summary":"專案 Review 指引 文件版本： 1.1\n更新日期： 2025年8月29日\n適用對象： 部門主管\n文件性質： 專案管理指引\n📑 目錄 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 1.2 主管在專案治理中的角色與責任 策略指導者 (Strategic Advisor) 資源協調者 (Resource Coordinator) 風險監督者 (Risk Supervisor) 績效推動者 (Performance Driver) 💡 實務案例 2. 專案 Review 的流程與步驟 2.1 準備階段 (Preparation Phase) Step 1: 收集專案資訊 Step 2: 建立檢視清單 Step 3: 預備會議安排 2.2 審查階段 (Review Phase) 2.2.1 進度審查 (Schedule Review) 2.2.2 成本審查 (Cost Review) 2.2.3 品質審查 (Quality Review) 2.2.4 風險與議題審查 (Risk \u0026amp; Issue Review) 2.2.5 資源與團隊審查 (Resource \u0026amp; Team Review) 2.3 討論與回饋階段 (Discussion \u0026amp; Feedback Phase) 2.3.1 主持有效會議的技巧 2.3.2 提出建設性建議的方法 2.4 後續跟進 (Follow-up Phase) 2.4.1 改進措施追蹤 2.4.2 Review 結果記錄 3. 專案 Review 的重點檢核項目 3.1 專案目標與商業價值對齊程度 3.2 進度與里程碑狀況 3.3 成本與預算控管 3.4 風險與議題管理 3.5 品質保證與測試狀況 3.6 資源配置與團隊狀態 3.7 利害關係人溝通與滿意度 4. 最佳實務與常見錯誤 4.1 主管應如何提供支持而不是微觀管理 4.2 常見的 Review 誤區 誤區一：只看數字，忽略背後原因 誤區二：不關注風險，只處理已發生的問題 誤區三：不給具體行動建議，只提出批評 4.3 有效的提問與引導技巧 5. 範例與工具 5.1 專案 Review 問題清單 快速診斷問題清單 (10分鐘版本) 深度檢視問題清單 (完整版本) 5.2 Review 報告範例格式 5.3 可用的專案管理工具 進度追蹤工具 儀表板工具 溝通協作工具 工具選擇建議 5.4 數位化 Review 流程與自動化 自動化報告生成 即時監控儀表板 AI 輔助分析 5.5 不同專案類型的 Review 調整 敏捷專案 Review 指引 傳統瀑布式專案 Review 混合型專案管理方法 6. 進階主題 6.1 跨文化與遠距團隊的 Review 管理 6.2 大型複雜專案的多層級 Review 6.3 專案組合管理中的 Review 協調 6.4 危機情況下的緊急 Review 程序 7. 結語 7.1 透過持續 Review 建立部門專案治理文化 7.2 將 Review 作為溝通與提升團隊的機會 7.3 最終建議 7.4 持續改善與學習機制 附錄：專案 Review 檢查清單 (Checklist) A. Review 會議前準備清單 B. Review 會議進行清單 C. Review 會議後跟進清單 D. 專案健康度快速檢查清單 1. 文件目的與重要性 1.1 為什麼主管需要做專案 Review？ 專案 Review 是確保專案成功的關鍵管控機制，對新進部門主管而言具有以下重要性：\n","title":""},{"content":"專案品質管理指引 目錄 品質管理的重要性與目標\n1.1 品質管理的定義 1.2 品質管理的重要性 1.3 品質管理目標 1.4 實務案例 品質規劃流程\n2.1 品質規劃概述 2.2 品質規劃輸入 2.3 品質規劃工具與技術 2.4 品質規劃輸出 2.5 實務案例 品質保證流程\n3.1 品質保證概述 3.2 品質保證活動 3.3 品質保證工具 3.4 品質保證輸出 3.5 實務案例 品質控制流程\n4.1 品質控制概述 4.2 品質控制活動 4.3 品質控制工具與技術 4.4 品質控制輸出 4.5 實務案例 常用品質工具與方法\n5.1 七大品質工具 5.2 軟體品質分析工具 5.3 測試工具與框架 5.4 品質量測工具 5.5 工具選擇指南 專案品質指標範例\n6.1 品質指標設計原則 6.2 開發階段品質指標 6.3 測試階段品質指標 6.4 維運階段品質指標 6.5 指標監控與報告 品質稽核流程\n7.1 品質稽核概述 7.2 稽核類型與方法 7.3 品質稽核準備 7.4 品質稽核執行 7.5 稽核發現與報告 7.6 矯正行動與追蹤 7.7 實務案例 銀行系統專案品質管控實務案例\n8.1 案例背景：數位金融平台建置專案 8.2 品質管理策略 8.3 品質活動實施 8.4 品質挑戰與解決方案 8.5 成果與經驗分享 常見問題與解法\n9.1 品質規劃階段常見問題 9.2 品質保證階段常見問題 9.3 品質控制階段常見問題 9.4 組織與文化問題 9.5 工具與技術問題 附錄：檢核清單範例\n10.1 品質規劃檢核清單 10.2 程式碼審查檢核清單 10.3 測試執行檢核清單 10.4 上線前檢核清單 參考資料與延伸閱讀\n11.1 專案管理相關資源 11.2 品質管理相關資源 11.3 軟體工程相關資源 11.4 測試相關資源 11.5 工具與技術資源 11.6 線上社群與討論區 11.7 實務案例研究 11.8 持續學習建議 品質管理成熟度評估\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E5%93%81%E8%B3%AA%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案品質管理指引 目錄 品質管理的重要性與目標\n1.1 品質管理的定義 1.2 品質管理的重要性 1.3 品質管理目標 1.4 實務案例 品質規劃流程\n2.1 品質規劃概述 2.2 品質規劃輸入 2.3 品質規劃工具與技術 2.4 品質規劃輸出 2.5 實務案例 品質保證流程\n3.1 品質保證概述 3.2 品質保證活動 3.3 品質保證工具 3.4 品質保證輸出 3.5 實務案例 品質控制流程\n4.1 品質控制概述 4.2 品質控制活動 4.3 品質控制工具與技術 4.4 品質控制輸出 4.5 實務案例 常用品質工具與方法\n5.1 七大品質工具 5.2 軟體品質分析工具 5.3 測試工具與框架 5.4 品質量測工具 5.5 工具選擇指南 專案品質指標範例\n6.1 品質指標設計原則 6.2 開發階段品質指標 6.3 測試階段品質指標 6.4 維運階段品質指標 6.5 指標監控與報告 品質稽核流程\n7.1 品質稽核概述 7.2 稽核類型與方法 7.3 品質稽核準備 7.4 品質稽核執行 7.5 稽核發現與報告 7.6 矯正行動與追蹤 7.7 實務案例 銀行系統專案品質管控實務案例\n8.1 案例背景：數位金融平台建置專案 8.2 品質管理策略 8.3 品質活動實施 8.4 品質挑戰與解決方案 8.5 成果與經驗分享 常見問題與解法\n9.1 品質規劃階段常見問題 9.2 品質保證階段常見問題 9.3 品質控制階段常見問題 9.4 組織與文化問題 9.5 工具與技術問題 附錄：檢核清單範例\n10.1 品質規劃檢核清單 10.2 程式碼審查檢核清單 10.3 測試執行檢核清單 10.4 上線前檢核清單 參考資料與延伸閱讀\n11.1 專案管理相關資源 11.2 品質管理相關資源 11.3 軟體工程相關資源 11.4 測試相關資源 11.5 工具與技術資源 11.6 線上社群與討論區 11.7 實務案例研究 11.8 持續學習建議 品質管理成熟度評估\n","title":""},{"content":"專案啟動流程指引 文件資訊 版本：1.1 建立日期：2025年8月13日 最後更新：2025年8月29日 適用對象：新進專案經理（0-2年經驗） 專案類型：系統開發、基礎架構升級、法遵專案 目錄 專案啟動流程概述\n1.1 定義與目標 1.2 專案啟動的重要性 1.3 專案啟動五大階段 專案啟動流程詳細說明\n2.1 階段一：專案立案 2.2 階段二：需求初步確認 2.3 階段三：組建核心團隊 2.4 階段四：專案規劃啟動 2.5 階段五：正式啟動會議 專案啟動流程總覽表\n3.1 流程階段彙整表 3.2 關鍵決策點與升級機制 專案啟動文件範本結構\n4.1 專案授權書（Project Charter）範本 4.2 專案啟動會議議程範本 4.3 專案啟動會議議程範例 成功專案啟動的五大關鍵建議\n專案啟動常見問題與解決方案\n專案啟動成功指標與評估標準\n數位化工具與技術應用\n法規遵循與資安要求\n參考資料與延伸學習\n附錄：版本更新記錄\n1. 專案啟動流程概述 1.1 定義與目標 專案啟動階段是專案生命週期的第一個階段，目標是正式授權專案開始並為專案成功奠定基礎。這個階段將確定專案範圍、目標、利害關係人，並獲得必要的資源承諾。\n1.2 專案啟動的重要性 建立共識：確保所有利害關係人對專案目標有一致理解 設定期望：明確定義專案成功標準與交付物 風險預防：及早識別潛在風險與限制條件 資源確保：獲得必要的人力、時間與預算承諾 1.3 專案啟動五大階段 graph LR A[專案立案] --\u0026gt; B[需求初步確認] B --\u0026gt; C[組建核心團隊] C --\u0026gt; D[專案規劃啟動] D --\u0026gt; E[正式啟動會議] 2. 專案啟動流程詳細說明 2.1 階段一：專案立案 工作內容 撰寫或審核專案提案書 進行初步可行性評估 確認專案商業價值與對齊策略 申請專案預算與資源 負責角色 主要負責：專案發起人（Project Sponsor） 協助角色：業務單位主管、IT部門主管 支援角色：財務部門、法務部門 輸出成果（Deliverables） 專案提案書（Project Proposal） 商業案例文件（Business Case） 初步預算評估報告 專案授權書（Project Charter）草案 關鍵檢核點 專案與企業策略目標一致 商業效益清楚量化 預算範圍獲得初步認可 高階主管支持確認 常見風險與應對 風險項目 風險等級 應對措施 商業案例不夠明確 高 重新檢視需求與效益，補強分析 預算評估過於樂觀 中 加入10-20%風險緩衝 利害關係人支持不足 高 加強溝通，重新爭取支持 實務案例 情境說明：某銀行要開發新的數位帳戶開戶系統\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E5%95%9F%E5%8B%95%E6%B5%81%E7%A8%8B%E6%8C%87%E5%BC%95/","summary":"專案啟動流程指引 文件資訊 版本：1.1 建立日期：2025年8月13日 最後更新：2025年8月29日 適用對象：新進專案經理（0-2年經驗） 專案類型：系統開發、基礎架構升級、法遵專案 目錄 專案啟動流程概述\n1.1 定義與目標 1.2 專案啟動的重要性 1.3 專案啟動五大階段 專案啟動流程詳細說明\n2.1 階段一：專案立案 2.2 階段二：需求初步確認 2.3 階段三：組建核心團隊 2.4 階段四：專案規劃啟動 2.5 階段五：正式啟動會議 專案啟動流程總覽表\n3.1 流程階段彙整表 3.2 關鍵決策點與升級機制 專案啟動文件範本結構\n4.1 專案授權書（Project Charter）範本 4.2 專案啟動會議議程範本 4.3 專案啟動會議議程範例 成功專案啟動的五大關鍵建議\n專案啟動常見問題與解決方案\n專案啟動成功指標與評估標準\n數位化工具與技術應用\n法規遵循與資安要求\n參考資料與延伸學習\n附錄：版本更新記錄\n1. 專案啟動流程概述 1.1 定義與目標 專案啟動階段是專案生命週期的第一個階段，目標是正式授權專案開始並為專案成功奠定基礎。這個階段將確定專案範圍、目標、利害關係人，並獲得必要的資源承諾。\n1.2 專案啟動的重要性 建立共識：確保所有利害關係人對專案目標有一致理解 設定期望：明確定義專案成功標準與交付物 風險預防：及早識別潛在風險與限制條件 資源確保：獲得必要的人力、時間與預算承諾 1.3 專案啟動五大階段 graph LR A[專案立案] --\u0026gt; B[需求初步確認] B --\u0026gt; C[組建核心團隊] C --\u0026gt; D[專案規劃啟動] D --\u0026gt; E[正式啟動會議] 2. 專案啟動流程詳細說明 2.1 階段一：專案立案 工作內容 撰寫或審核專案提案書 進行初步可行性評估 確認專案商業價值與對齊策略 申請專案預算與資源 負責角色 主要負責：專案發起人（Project Sponsor） 協助角色：業務單位主管、IT部門主管 支援角色：財務部門、法務部門 輸出成果（Deliverables） 專案提案書（Project Proposal） 商業案例文件（Business Case） 初步預算評估報告 專案授權書（Project Charter）草案 關鍵檢核點 專案與企業策略目標一致 商業效益清楚量化 預算範圍獲得初步認可 高階主管支持確認 常見風險與應對 風險項目 風險等級 應對措施 商業案例不夠明確 高 重新檢視需求與效益，補強分析 預算評估過於樂觀 中 加入10-20%風險緩衝 利害關係人支持不足 高 加強溝通，重新爭取支持 實務案例 情境說明：某銀行要開發新的數位帳戶開戶系統\n","title":""},{"content":"專案溝通管理指引 版本：2.0\n建立日期：2025年8月13日\n最後更新：2025年8月29日\n適用對象：新進專案經理、專案團隊成員\n文件性質：內部培訓教材\n目錄 目的與重要性 溝通目標 溝通角色與責任 溝通計畫 溝通紀錄與追蹤機制 衝突與異議處理 溝通成效評估方式 數位化溝通工具與技術 危機溝通管理 跨文化與遠程溝通 溝通技巧培訓與發展 最佳實務案例 附錄：溝通模板與檢核表 參考資料 1. 目的與重要性 1.1 指引目的 本指引旨在提供新進專案經理一套完整且實用的溝通管理框架，協助：\n標準化溝通流程：建立一致的溝通標準與流程 提升溝通效率：確保資訊正確、及時傳達給相關干係人 降低專案風險：透過有效溝通預防和解決潛在問題 增進團隊協作：促進跨部門協作與資訊透明化 1.2 溝通管理的重要性 根據 PMI（專案管理協會）統計：\n90% 的專案經理時間用於溝通 57% 的專案失敗源於溝通不良 75% 的專案干係人問題可透過有效溝通避免 1.3 金融業溝通特性 在銀行與金融業專案中，溝通管理具備以下特殊性：\n法規合規性：須符合金管會、央行等監管要求 風險敏感性：任何資訊錯誤可能造成重大損失 多方干係人：涉及內部部門、外部供應商、稽核單位等 資訊安全性：需要特別注意敏感資訊的保護 1.4 實務案例 案例：核心銀行系統升級專案\n問題：IT部門與業務部門對需求理解不一致 影響：專案延遲 3 個月，預算超支 20% 解決：建立每週跨部門會議機制，統一需求文件格式 結果：後續階段準時完成，干係人滿意度提升至 85% 2. 溝通目標 2.1 主要溝通目標 專案溝通管理應達成以下核心目標：\n2.1.1 資訊透明化 即時性：關鍵資訊在 24 小時內傳達 準確性：資訊正確率達 95% 以上 完整性：涵蓋所有相關干係人 2.1.2 決策效率化 決策時效：一般決策 3 個工作日內完成 決策品質：基於充分且正確的資訊 決策追蹤：建立決策執行狀況追蹤機制 2.1.3 風險控制化 風險預警：建立風險資訊快速通報機制 問題解決：問題發生後 48 小時內提出解決方案 經驗傳承：建立知識管理與分享機制 2.2 階段性溝通目標 2.2.1 專案啟動階段 目標設定：確保所有干係人了解專案目標與範圍 團隊建立：建立有效的團隊溝通機制 期望管理：統一干係人對專案的期望 2.2.2 規劃階段 需求確認：確保需求完整且被正確理解 計畫共識：獲得所有干係人對專案計畫的認同 資源協調：確保資源分配的透明化 2.2.3 執行階段 進度追蹤：定期更新專案執行狀況 問題處理：快速識別並處理專案問題 變更管理：有效溝通專案變更事項 2.2.4 監控階段 績效報告：定期提供專案績效資訊 品質保證：確保溝通品質符合標準 風險監控：持續監控並溝通風險狀況 2.2.5 收尾階段 成果交付：確保交付成果被正確理解 經驗總結：收集並分享專案經驗教訓 關係維護：維持良好的干係人關係 2.3 溝通目標衡量指標 指標類別 具體指標 目標值 衡量方式 時效性 緊急事件回應時間 \u0026lt; 2 小時 事件日誌記錄 準確性 資訊錯誤率 \u0026lt; 5% 月度資訊稽核 覆蓋性 干係人參與率 \u0026gt; 90% 會議出席統計 滿意度 溝通滿意度評分 \u0026gt; 4.0/5.0 季度滿意度調查 2.4 實務提醒 ⚠️ 注意事項：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E6%BA%9D%E9%80%9A%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案溝通管理指引 版本：2.0\n建立日期：2025年8月13日\n最後更新：2025年8月29日\n適用對象：新進專案經理、專案團隊成員\n文件性質：內部培訓教材\n目錄 目的與重要性 溝通目標 溝通角色與責任 溝通計畫 溝通紀錄與追蹤機制 衝突與異議處理 溝通成效評估方式 數位化溝通工具與技術 危機溝通管理 跨文化與遠程溝通 溝通技巧培訓與發展 最佳實務案例 附錄：溝通模板與檢核表 參考資料 1. 目的與重要性 1.1 指引目的 本指引旨在提供新進專案經理一套完整且實用的溝通管理框架，協助：\n標準化溝通流程：建立一致的溝通標準與流程 提升溝通效率：確保資訊正確、及時傳達給相關干係人 降低專案風險：透過有效溝通預防和解決潛在問題 增進團隊協作：促進跨部門協作與資訊透明化 1.2 溝通管理的重要性 根據 PMI（專案管理協會）統計：\n90% 的專案經理時間用於溝通 57% 的專案失敗源於溝通不良 75% 的專案干係人問題可透過有效溝通避免 1.3 金融業溝通特性 在銀行與金融業專案中，溝通管理具備以下特殊性：\n法規合規性：須符合金管會、央行等監管要求 風險敏感性：任何資訊錯誤可能造成重大損失 多方干係人：涉及內部部門、外部供應商、稽核單位等 資訊安全性：需要特別注意敏感資訊的保護 1.4 實務案例 案例：核心銀行系統升級專案\n問題：IT部門與業務部門對需求理解不一致 影響：專案延遲 3 個月，預算超支 20% 解決：建立每週跨部門會議機制，統一需求文件格式 結果：後續階段準時完成，干係人滿意度提升至 85% 2. 溝通目標 2.1 主要溝通目標 專案溝通管理應達成以下核心目標：\n2.1.1 資訊透明化 即時性：關鍵資訊在 24 小時內傳達 準確性：資訊正確率達 95% 以上 完整性：涵蓋所有相關干係人 2.1.2 決策效率化 決策時效：一般決策 3 個工作日內完成 決策品質：基於充分且正確的資訊 決策追蹤：建立決策執行狀況追蹤機制 2.1.3 風險控制化 風險預警：建立風險資訊快速通報機制 問題解決：問題發生後 48 小時內提出解決方案 經驗傳承：建立知識管理與分享機制 2.2 階段性溝通目標 2.2.1 專案啟動階段 目標設定：確保所有干係人了解專案目標與範圍 團隊建立：建立有效的團隊溝通機制 期望管理：統一干係人對專案的期望 2.2.2 規劃階段 需求確認：確保需求完整且被正確理解 計畫共識：獲得所有干係人對專案計畫的認同 資源協調：確保資源分配的透明化 2.2.3 執行階段 進度追蹤：定期更新專案執行狀況 問題處理：快速識別並處理專案問題 變更管理：有效溝通專案變更事項 2.2.4 監控階段 績效報告：定期提供專案績效資訊 品質保證：確保溝通品質符合標準 風險監控：持續監控並溝通風險狀況 2.2.5 收尾階段 成果交付：確保交付成果被正確理解 經驗總結：收集並分享專案經驗教訓 關係維護：維持良好的干係人關係 2.3 溝通目標衡量指標 指標類別 具體指標 目標值 衡量方式 時效性 緊急事件回應時間 \u0026lt; 2 小時 事件日誌記錄 準確性 資訊錯誤率 \u0026lt; 5% 月度資訊稽核 覆蓋性 干係人參與率 \u0026gt; 90% 會議出席統計 滿意度 溝通滿意度評分 \u0026gt; 4.0/5.0 季度滿意度調查 2.4 實務提醒 ⚠️ 注意事項：\n","title":""},{"content":"專案管理指引 目錄 專案管理概述 專案生命週期與階段管理 專案啟動階段 專案規劃階段 專案執行階段 專案監控階段 專案收尾階段 風險管理 溝通與會議管理 文件與報告管理 品質管理 採購與供應商管理 人力資源管理 利害關係人管理 專案整合管理 敏捷專案管理 專案管理成熟度 附錄：範例與模板 1. 專案管理概述 1.1 專案管理定義 專案管理是運用知識、技能、工具與技術於專案活動，以滿足專案需求的管理過程。對於金融 IT 專案而言，更需要嚴格遵循 SSDLC（安全軟體開發生命週期）規範。\n1.2 專案管理核心原則 明確的目標設定：每個專案都必須有清楚、可衡量的目標 時程與資源控管：有效管理時間、人力、預算等資源 品質保證：確保交付成果符合既定標準 風險管控：主動識別、評估與應對專案風險 持續溝通：建立有效的溝通機制與管道 1.3 專案管理五大流程群組 啟動（Initiating）：定義專案範圍與目標 規劃（Planning）：制定詳細執行計畫 執行（Executing）：實際進行專案工作 監控（Monitoring \u0026amp; Controlling）：追蹤進度並進行調整 收尾（Closing）：完成專案並進行經驗傳承 1.4 金融 IT 專案特色 高度安全性要求（須符合金管會、國際標準） 嚴格的法規遵循（如個資法、洗錢防制法） 複雜的系統整合需求 24/7 營運環境的穩定性要求 大量的測試與驗證程序 實務案例 某銀行數位帳戶開發專案，專案經理運用 Agile 方法論，將 12 個月的專案分為 6 個 Sprint，每個 Sprint 2 個月。透過每日站立會議、Sprint 回顧會議等機制，成功在預定時程內上線，並獲得客戶滿意度 95% 的佳績。\n2. 專案生命週期與階段管理 2.1 專案生命週期概述 專案生命週期是從專案啟動到結束的完整過程，每個階段都有特定的目標、活動與交付成果。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案管理指引 目錄 專案管理概述 專案生命週期與階段管理 專案啟動階段 專案規劃階段 專案執行階段 專案監控階段 專案收尾階段 風險管理 溝通與會議管理 文件與報告管理 品質管理 採購與供應商管理 人力資源管理 利害關係人管理 專案整合管理 敏捷專案管理 專案管理成熟度 附錄：範例與模板 1. 專案管理概述 1.1 專案管理定義 專案管理是運用知識、技能、工具與技術於專案活動，以滿足專案需求的管理過程。對於金融 IT 專案而言，更需要嚴格遵循 SSDLC（安全軟體開發生命週期）規範。\n1.2 專案管理核心原則 明確的目標設定：每個專案都必須有清楚、可衡量的目標 時程與資源控管：有效管理時間、人力、預算等資源 品質保證：確保交付成果符合既定標準 風險管控：主動識別、評估與應對專案風險 持續溝通：建立有效的溝通機制與管道 1.3 專案管理五大流程群組 啟動（Initiating）：定義專案範圍與目標 規劃（Planning）：制定詳細執行計畫 執行（Executing）：實際進行專案工作 監控（Monitoring \u0026amp; Controlling）：追蹤進度並進行調整 收尾（Closing）：完成專案並進行經驗傳承 1.4 金融 IT 專案特色 高度安全性要求（須符合金管會、國際標準） 嚴格的法規遵循（如個資法、洗錢防制法） 複雜的系統整合需求 24/7 營運環境的穩定性要求 大量的測試與驗證程序 實務案例 某銀行數位帳戶開發專案，專案經理運用 Agile 方法論，將 12 個月的專案分為 6 個 Sprint，每個 Sprint 2 個月。透過每日站立會議、Sprint 回顧會議等機制，成功在預定時程內上線，並獲得客戶滿意度 95% 的佳績。\n2. 專案生命週期與階段管理 2.1 專案生命週期概述 專案生命週期是從專案啟動到結束的完整過程，每個階段都有特定的目標、活動與交付成果。\n","title":""},{"content":"專案風險管理指引 目錄 1. 專案風險管理的定義與重要性 1.1 定義 1.2 風險管理的核心概念 1.3 為什麼風險管理很重要 1.4 金融 IT 專案的風險特性 1.5 實務案例 2. 風險分類 2.1 技術風險 2.2 管理風險 2.3 外部風險 2.4 合規風險 2.5 實務案例 3. 風險識別方法 3.1 概述 3.2 訪談法 3.3 檢核表法 3.4 歷史資料分析法 3.5 其他識別方法 3.6 風險識別的組織與文件化 3.7 實務案例 4. 風險評估 4.1 風險評估概述 4.2 風險機率評估 4.3 風險影響評估 4.4 風險優先級矩陣 4.5 定量風險分析 4.6 風險評估工具與技術 4.7 風險評估文件化 4.8 實務案例 5. 風險應對策略 5.1 風險應對策略概述 5.2 規避策略 5.3 轉移策略 5.4 減輕策略 5.5 接受策略 5.6 風險應對計畫制定 5.7 風險應對策略選擇原則 5.8 實務案例 6. 風險監控與更新流程 6.1 風險監控概述 6.2 風險監控機制 6.3 風險監控工具 6.4 風險更新流程 6.5 風險溝通管理 6.6 風險學習與改善 6.7 實務案例 7. 附錄：風險登錄表模板與範例 7.1 風險登錄表模板 7.2 不同風險類型範例 7.3 風險評估工作表 7.4 風險應對計畫範本 8. 風險管理工具與技術 9. 風險管理最佳實務 10. 常見問題與解答 參考資料 1. 專案風險管理的定義與重要性 1.1 定義 專案風險管理是指在專案生命週期中，系統性地識別、分析、評估、應對和監控可能影響專案目標達成的不確定性事件或條件的管理過程。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E5%B0%88%E6%A1%88%E9%A2%A8%E9%9A%AA%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"專案風險管理指引 目錄 1. 專案風險管理的定義與重要性 1.1 定義 1.2 風險管理的核心概念 1.3 為什麼風險管理很重要 1.4 金融 IT 專案的風險特性 1.5 實務案例 2. 風險分類 2.1 技術風險 2.2 管理風險 2.3 外部風險 2.4 合規風險 2.5 實務案例 3. 風險識別方法 3.1 概述 3.2 訪談法 3.3 檢核表法 3.4 歷史資料分析法 3.5 其他識別方法 3.6 風險識別的組織與文件化 3.7 實務案例 4. 風險評估 4.1 風險評估概述 4.2 風險機率評估 4.3 風險影響評估 4.4 風險優先級矩陣 4.5 定量風險分析 4.6 風險評估工具與技術 4.7 風險評估文件化 4.8 實務案例 5. 風險應對策略 5.1 風險應對策略概述 5.2 規避策略 5.3 轉移策略 5.4 減輕策略 5.5 接受策略 5.6 風險應對計畫制定 5.7 風險應對策略選擇原則 5.8 實務案例 6. 風險監控與更新流程 6.1 風險監控概述 6.2 風險監控機制 6.3 風險監控工具 6.4 風險更新流程 6.5 風險溝通管理 6.6 風險學習與改善 6.7 實務案例 7. 附錄：風險登錄表模板與範例 7.1 風險登錄表模板 7.2 不同風險類型範例 7.3 風險評估工作表 7.4 風險應對計畫範本 8. 風險管理工具與技術 9. 風險管理最佳實務 10. 常見問題與解答 參考資料 1. 專案風險管理的定義與重要性 1.1 定義 專案風險管理是指在專案生命週期中，系統性地識別、分析、評估、應對和監控可能影響專案目標達成的不確定性事件或條件的管理過程。\n","title":""},{"content":"敏捷專案管理指引 目錄 前言 敏捷專案管理核心原則 常用敏捷方法 敏捷專案管理流程 敏捷工具與實務應用 敏捷專案管理在銀行系統的特別注意事項 常見問題與解決策略（FAQ） 結論與建議 參考資料 前言 敏捷專案管理的定義與重要性 敏捷專案管理（Agile Project Management）是一種以人為本、迭代式、增量式的專案管理方法論。它強調：\n適應變化：擁抱需求變更，而非抗拒變化 快速交付：透過短週期迭代，頻繁交付可用的軟體或產品 客戶協作：與客戶密切合作，持續獲得回饋 團隊自主：授權團隊自我組織和決策 為什麼敏捷專案管理很重要？ 市場快速變化：現今金融科技環境瞬息萬變，傳統瀑布式開發無法及時回應 客戶期望提升：客戶期待更快的上市時間和更高的產品品質 技術複雜度增加：現代系統整合度高，需要靈活的開發方式 法規環境變動：金融業法規頻繁更新，需要敏捷的回應機制 與傳統瀑布式開發的差異 比較項目 瀑布式開發 敏捷開發 開發流程 線性、順序性 迭代式、增量式 需求變更 後期變更成本高昂 擁抱變更，持續調整 客戶參與 專案初期和結尾 整個開發過程 交付頻率 專案結束時一次交付 每2-4週交付一次 風險管控 後期才發現問題 早期發現，快速調整 文件重點 詳盡的文件 可用的軟體 團隊結構 階層化管理 自我組織團隊 實務案例 某銀行數位轉型專案原採瀑布式開發，18個月後才發現市場需求已改變。改採敏捷開發後，每3週展示一次成果，第6個月就推出MVP（最小可行產品），成功搶占市場先機。\n敏捷專案管理核心原則 Agile Manifesto 四大價值 敏捷宣言（Agile Manifesto）於2001年發布，奠定了敏捷開發的核心價值觀：\n1. 個體與互動 重於 流程與工具 重點：人是專案成功的關鍵，良好的溝通比完美的工具更重要 實務應用： 每日站會面對面溝通 建立開放的工作環境 鼓勵團隊成員直接對話 2. 可用的軟體 重於 詳盡的文件 重點：以交付可用的產品為目標，而非完美的文件 實務應用： 專注於核心功能的實現 文件簡潔明瞭，以必要為準 透過實際產品驗證需求 3. 客戶協作 重於 合約談判 重點：與客戶建立夥伴關係，共同創造價值 實務應用： 客戶參與每次Sprint回顧 定期收集客戶回饋 調整產品方向以符合客戶真實需求 4. 回應變化 重於 遵循計劃 重點：靈活回應市場和需求變化 實務應用： 定期評估和調整專案優先級 建立彈性的開發架構 預留緩衝時間應對變更 敏捷十二項原則 最高優先級：透過早期和持續交付有價值的軟體來滿足客戶 歡迎需求變更：即使在開發後期也歡迎需求變更 頻繁交付：頻繁地交付可用的軟體，從幾週到幾個月 協同工作：業務人員和開發者必須在整個專案中每天協同工作 激發個體：圍繞被激發的個體構建專案，給他們所需的環境和支持 面對面溝通：在開發團隊中最有效的溝通方式是面對面的交談 可用軟體：可用的軟體是衡量進度的主要標準 可持續發展：敏捷流程提倡可持續的開發速度 技術卓越：持續關注技術卓越和良好設計會增強敏捷性 簡潔：簡潔——最大化未完成工作量的技藝——至關重要 自組織團隊：最好的架構、需求和設計來自自組織團隊 定期調整：團隊定期反思如何能變得更有效，然後調整行為 在金融/銀行專案中的適用性說明 適用場景 數位化轉型專案：線上銀行、行動APP開發 法規遵循系統：需要快速回應法規變更 客戶體驗改善：根據客戶回饋持續優化 創新產品開發：新金融商品或服務的探索 注意事項 法規要求：某些文件和審查流程不可省略 安全考量：資安測試和稽核需要充分時間 風險管控：金融業對風險敏感，需要適當的控制點 合規性：確保敏捷實踐符合內控制度 實務案例 某區域銀行開發客戶關係管理系統，採用Scrum方法：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E6%95%8F%E6%8D%B7%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86%E6%8C%87%E5%BC%95/","summary":"敏捷專案管理指引 目錄 前言 敏捷專案管理核心原則 常用敏捷方法 敏捷專案管理流程 敏捷工具與實務應用 敏捷專案管理在銀行系統的特別注意事項 常見問題與解決策略（FAQ） 結論與建議 參考資料 前言 敏捷專案管理的定義與重要性 敏捷專案管理（Agile Project Management）是一種以人為本、迭代式、增量式的專案管理方法論。它強調：\n適應變化：擁抱需求變更，而非抗拒變化 快速交付：透過短週期迭代，頻繁交付可用的軟體或產品 客戶協作：與客戶密切合作，持續獲得回饋 團隊自主：授權團隊自我組織和決策 為什麼敏捷專案管理很重要？ 市場快速變化：現今金融科技環境瞬息萬變，傳統瀑布式開發無法及時回應 客戶期望提升：客戶期待更快的上市時間和更高的產品品質 技術複雜度增加：現代系統整合度高，需要靈活的開發方式 法規環境變動：金融業法規頻繁更新，需要敏捷的回應機制 與傳統瀑布式開發的差異 比較項目 瀑布式開發 敏捷開發 開發流程 線性、順序性 迭代式、增量式 需求變更 後期變更成本高昂 擁抱變更，持續調整 客戶參與 專案初期和結尾 整個開發過程 交付頻率 專案結束時一次交付 每2-4週交付一次 風險管控 後期才發現問題 早期發現，快速調整 文件重點 詳盡的文件 可用的軟體 團隊結構 階層化管理 自我組織團隊 實務案例 某銀行數位轉型專案原採瀑布式開發，18個月後才發現市場需求已改變。改採敏捷開發後，每3週展示一次成果，第6個月就推出MVP（最小可行產品），成功搶占市場先機。\n敏捷專案管理核心原則 Agile Manifesto 四大價值 敏捷宣言（Agile Manifesto）於2001年發布，奠定了敏捷開發的核心價值觀：\n1. 個體與互動 重於 流程與工具 重點：人是專案成功的關鍵，良好的溝通比完美的工具更重要 實務應用： 每日站會面對面溝通 建立開放的工作環境 鼓勵團隊成員直接對話 2. 可用的軟體 重於 詳盡的文件 重點：以交付可用的產品為目標，而非完美的文件 實務應用： 專注於核心功能的實現 文件簡潔明瞭，以必要為準 透過實際產品驗證需求 3. 客戶協作 重於 合約談判 重點：與客戶建立夥伴關係，共同創造價值 實務應用： 客戶參與每次Sprint回顧 定期收集客戶回饋 調整產品方向以符合客戶真實需求 4. 回應變化 重於 遵循計劃 重點：靈活回應市場和需求變化 實務應用： 定期評估和調整專案優先級 建立彈性的開發架構 預留緩衝時間應對變更 敏捷十二項原則 最高優先級：透過早期和持續交付有價值的軟體來滿足客戶 歡迎需求變更：即使在開發後期也歡迎需求變更 頻繁交付：頻繁地交付可用的軟體，從幾週到幾個月 協同工作：業務人員和開發者必須在整個專案中每天協同工作 激發個體：圍繞被激發的個體構建專案，給他們所需的環境和支持 面對面溝通：在開發團隊中最有效的溝通方式是面對面的交談 可用軟體：可用的軟體是衡量進度的主要標準 可持續發展：敏捷流程提倡可持續的開發速度 技術卓越：持續關注技術卓越和良好設計會增強敏捷性 簡潔：簡潔——最大化未完成工作量的技藝——至關重要 自組織團隊：最好的架構、需求和設計來自自組織團隊 定期調整：團隊定期反思如何能變得更有效，然後調整行為 在金融/銀行專案中的適用性說明 適用場景 數位化轉型專案：線上銀行、行動APP開發 法規遵循系統：需要快速回應法規變更 客戶體驗改善：根據客戶回饋持續優化 創新產品開發：新金融商品或服務的探索 注意事項 法規要求：某些文件和審查流程不可省略 安全考量：資安測試和稽核需要充分時間 風險管控：金融業對風險敏感，需要適當的控制點 合規性：確保敏捷實踐符合內控制度 實務案例 某區域銀行開發客戶關係管理系統，採用Scrum方法：\n","title":""},{"content":"金融專案合規要求手冊 版本資訊 版本: 1.1 發布日期: 2025年8月29日 適用對象: 新進專案經理、資深專案經理、系統開發團隊 審核狀態: 更新版 目錄 金融專案中常見的合規要求概述 主要法規與標準（國內/國際） 專案生命周期各階段的合規檢查清單 專案文件與紀錄保存要求 風險管理與稽核應對 案例示例與常見錯誤 新興技術與合規挑戰 跨部門協作與溝通機制 合規成本管理與效益分析 數位轉型專案特殊考量 附錄：合規檢查清單 附錄：合規工具與模板 1. 金融專案中常見的合規要求概述 1.1 合規的重要性 金融專案合規不僅是法律要求，更是維護機構聲譽、降低營運風險的核心要素。在當今嚴格的監管環境下，任何合規疏失都可能導致：\n法律責任：罰款、制裁、執照撤銷 聲譽損失：客戶信任度下降、市場競爭力削弱 財務損失：營運中斷、客戶流失、投資人信心下滑 營運影響：系統重建、流程重新設計 1.2 金融專案特有的合規挑戰 1.2.1 資料敏感性 個人資料保護：客戶身分資料、財務資訊 交易資料：金流記錄、投資組合資訊 內部資料：風險模型、定價策略 1.2.2 跨境監管 多國法規：GDPR（歐盟）、CCPA（加州）、個資法（台灣） 國際標準：Basel III、FATF建議、ISO 27001 監管機構：金管會、央行、銀行局 1.2.3 技術複雜性 系統整合：核心銀行系統、風控系統、報表系統 資料治理：資料品質、資料血緣、資料安全 技術債務：舊系統維護、新舊系統共存 1.3 合規框架概念 1.3.1 三道防線模型 (Three Lines of Defense) 第一道防線：業務單位與營運管理\n日常風險管理 內控制度執行 前線合規檢查 第二道防線：風險管理與合規單位\n政策制定 風險監控 合規查核 第三道防線：內部稽核\n獨立驗證 有效性評估 改善建議 1.3.2 專案合規責任分工 角色 主要責任 合規職責 專案經理 專案整體管控 確保合規要求納入專案範圍 業務分析師 需求分析 識別業務流程中的合規點 系統架構師 技術架構設計 確保技術方案符合合規要求 開發團隊 系統開發 落實合規控制點的程式實作 測試團隊 系統測試 執行合規功能測試與驗證 合規專員 合規諮詢 提供法規解釋與合規指導 1.4 大型專案 vs 中小型專案差異 1.4.1 大型專案特點 專案規模：預算超過1億台幣、團隊超過50人、開發期程超過2年 合規複雜度：涉及多項法規、跨國營運、多系統整合 管理要求： 設立專門的合規委員會 聘請外部合規顧問 建立完整的合規治理架構 定期向董事會報告 1.4.2 中小型專案特點 專案規模：預算5千萬台幣以下、團隊20人以下、開發期程1年以內 合規複雜度：主要聚焦核心法規、單一系統或功能 管理要求： 指派合規聯絡人 使用標準化合規檢查清單 定期合規狀態報告 重點關注關鍵合規節點 1.5 常見合規領域 1.5.1 資料保護與隱私 適用法規：GDPR、個資法、銀行法 關鍵要求： 資料收集同意機制 資料處理目的限制 資料保存期限管理 資料跨境傳輸控制 1.5.2 反洗錢與打擊資恐 (AML/CFT) 適用法規：洗錢防制法、資恐防制法、FATF建議 關鍵要求： 客戶盡職調查 (CDD) 加強客戶盡職調查 (EDD) 疑似洗錢交易申報 (STR) 制裁名單篩檢 1.5.3 網路安全 適用法規：資通安全管理法、個資法、銀行法 關鍵要求： 資訊安全管理制度 事件應變機制 定期安全評估 員工安全教育訓練 2. 主要法規與標準（國內/國際） 2.1 台灣金融法規 🇹🇼 2.1.1 核心法規 銀行法 主管機關：金融監督管理委員會 適用對象：銀行業、信用合作社 關鍵條文： 第33條：銀行業務限制 第45條：資本適足性要求 第48條：業務查核與申報 專案影響：系統功能設計須符合業務範圍限制 個人資料保護法 施行日期：2012年10月1日 適用範圍：所有處理個人資料的公務機關及非公務機關 關鍵要求： 告知義務（第8條） 資料正確性維護（第11條） 安全維護措施（第27條） 罰則：新台幣2萬元以上20萬元以下罰鍰 洗錢防制法 最新修正：2018年11月7日 主要內容： 金融機構防制洗錢辦法 客戶盡職調查程序 疑似洗錢交易申報 系統要求： 即時篩檢功能 交易監控系統 報告產製機制 2.1.2 監管指引 金管會相關函令 銀行業內部控制及稽核制度實施辦法 金融機構防制洗錢辦法 銀行業公司治理實務守則 中央銀行規定 外匯收支或交易申報辦法 銀行業辦理外匯業務管理辦法 2.2 國際法規與標準 2.2.1 歐盟法規 GDPR (General Data Protection Regulation) 生效日期：2018年5月25日 適用範圍： 歐盟境內的資料處理 向歐盟提供商品或服務 監控歐盟境內個人行為 關鍵原則： 合法性、公平性、透明性 目的限制 資料最小化 正確性 保存期限限制 完整性與機密性 個人權利： 存取權 (Right of Access) 更正權 (Right to Rectification) 刪除權 (Right to Erasure) 資料可攜權 (Right to Data Portability) 罰款：營業額4%或2,000萬歐元，取較高者 PSD2 (Payment Services Directive 2) 目的：促進歐盟支付服務創新與競爭 關鍵要求： 強客戶驗證 (SCA) 開放銀行 API 第三方支付服務提供者 (TPP) 規範 2.2.2 美國法規 SOX Act (Sarbanes-Oxley Act) 適用對象：美國上市公司 關鍵要求： 財務報告內控制度 管理層證明責任 外部稽核獨立性 CCPA (California Consumer Privacy Act) 生效日期：2020年1月1日 適用範圍：處理加州居民個人資訊的企業 消費者權利： 知情權 刪除權 選擇退出權 不歧視權 2.2.3 國際標準 Basel III 發布機構：巴塞爾銀行監理委員會 (BCBS) 主要內容： 資本適足性要求 流動性覆蓋率 (LCR) 淨穩定資金比率 (NSFR) 槓桿比率 實施時程：2019-2027年分階段實施 ISO 27001 標準名稱：資訊安全管理系統要求事項 認證效益： 提升客戶信任 符合法規要求 降低安全風險 關鍵流程： PDCA循環 風險評估 控制措施選擇 持續改善 FATF 40項建議 發布機構：金融行動工作組織 涵蓋範圍： AML/CFT政策與協調 洗錢與資恐犯罪化 預防措施 透明度與實質受益人 權責機關權力 國際合作 2.3 新興法規趨勢 2.3.1 數位資產相關 歐盟 MiCA (Markets in Crypto-Assets Regulation) 美國數位資產框架 台灣虛擬通貨管理規範 2.3.2 人工智慧與演算法 歐盟 AI Act 演算法透明度要求 AI偏見防制 2.3.3 ESG與永續金融 歐盟永續金融披露規則 (SFDR) 氣候相關財務揭露 (TCFD) 台灣永續分類標準 3. 專案生命周期各階段的合規檢查清單 3.1 專案啟動階段 (Project Initiation) 3.1.1 合規評估要點 法規適用性分析 識別適用法規：依據專案性質、地理範圍、客戶類型確認適用法規清單 法規影響評估：評估各項法規對專案範圍、時程、成本的影響 合規成本估算：預估合規相關的人力、系統、流程成本 利害關係人識別 監管機構：金管會、央行、銀行局等主管機關 內部合規單位：法令遵循處、風險管理處、稽核處 外部顧問：法律事務所、會計師事務所、合規顧問 業務單位：相關業務部門、營運單位 3.1.2 必要文件準備 專案章程 (Project Charter) # 專案合規聲明範例 ## 合規目標 本專案承諾遵循以下法規要求： - 個人資料保護法 - 洗錢防制法 - 銀行法相關規定 - ISO 27001 資訊安全標準 ## 合規責任 - 專案經理：整體合規監督 - 合規專員：專業合規指導 - 開發團隊：落實合規控制點 ## 合規里程碑 - 需求分析階段：完成合規需求識別 - 設計階段：完成合規控制點設計 - 開發階段：完成合規功能開發 - 測試階段：完成合規測試驗證 初步風險評估 合規風險清單：識別潛在的合規風險點 風險等級評估：高/中/低風險分級 初步應對策略：風險規避、降低、轉移、接受 3.2 需求分析階段 (Requirements Analysis) 3.2.1 合規需求收集 功能性合規需求 資料保護功能\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E5%B0%88%E6%A1%88%E7%AE%A1%E7%90%86/%E9%87%91%E8%9E%8D%E5%B0%88%E6%A1%88%E5%90%88%E8%A6%8F%E8%A6%81%E6%B1%82%E6%89%8B%E5%86%8A/","summary":"金融專案合規要求手冊 版本資訊 版本: 1.1 發布日期: 2025年8月29日 適用對象: 新進專案經理、資深專案經理、系統開發團隊 審核狀態: 更新版 目錄 金融專案中常見的合規要求概述 主要法規與標準（國內/國際） 專案生命周期各階段的合規檢查清單 專案文件與紀錄保存要求 風險管理與稽核應對 案例示例與常見錯誤 新興技術與合規挑戰 跨部門協作與溝通機制 合規成本管理與效益分析 數位轉型專案特殊考量 附錄：合規檢查清單 附錄：合規工具與模板 1. 金融專案中常見的合規要求概述 1.1 合規的重要性 金融專案合規不僅是法律要求，更是維護機構聲譽、降低營運風險的核心要素。在當今嚴格的監管環境下，任何合規疏失都可能導致：\n法律責任：罰款、制裁、執照撤銷 聲譽損失：客戶信任度下降、市場競爭力削弱 財務損失：營運中斷、客戶流失、投資人信心下滑 營運影響：系統重建、流程重新設計 1.2 金融專案特有的合規挑戰 1.2.1 資料敏感性 個人資料保護：客戶身分資料、財務資訊 交易資料：金流記錄、投資組合資訊 內部資料：風險模型、定價策略 1.2.2 跨境監管 多國法規：GDPR（歐盟）、CCPA（加州）、個資法（台灣） 國際標準：Basel III、FATF建議、ISO 27001 監管機構：金管會、央行、銀行局 1.2.3 技術複雜性 系統整合：核心銀行系統、風控系統、報表系統 資料治理：資料品質、資料血緣、資料安全 技術債務：舊系統維護、新舊系統共存 1.3 合規框架概念 1.3.1 三道防線模型 (Three Lines of Defense) 第一道防線：業務單位與營運管理\n日常風險管理 內控制度執行 前線合規檢查 第二道防線：風險管理與合規單位\n政策制定 風險監控 合規查核 第三道防線：內部稽核\n獨立驗證 有效性評估 改善建議 1.3.2 專案合規責任分工 角色 主要責任 合規職責 專案經理 專案整體管控 確保合規要求納入專案範圍 業務分析師 需求分析 識別業務流程中的合規點 系統架構師 技術架構設計 確保技術方案符合合規要求 開發團隊 系統開發 落實合規控制點的程式實作 測試團隊 系統測試 執行合規功能測試與驗證 合規專員 合規諮詢 提供法規解釋與合規指導 1.4 大型專案 vs 中小型專案差異 1.4.1 大型專案特點 專案規模：預算超過1億台幣、團隊超過50人、開發期程超過2年 合規複雜度：涉及多項法規、跨國營運、多系統整合 管理要求： 設立專門的合規委員會 聘請外部合規顧問 建立完整的合規治理架構 定期向董事會報告 1.4.2 中小型專案特點 專案規模：預算5千萬台幣以下、團隊20人以下、開發期程1年以內 合規複雜度：主要聚焦核心法規、單一系統或功能 管理要求： 指派合規聯絡人 使用標準化合規檢查清單 定期合規狀態報告 重點關注關鍵合規節點 1.5 常見合規領域 1.5.1 資料保護與隱私 適用法規：GDPR、個資法、銀行法 關鍵要求： 資料收集同意機制 資料處理目的限制 資料保存期限管理 資料跨境傳輸控制 1.5.2 反洗錢與打擊資恐 (AML/CFT) 適用法規：洗錢防制法、資恐防制法、FATF建議 關鍵要求： 客戶盡職調查 (CDD) 加強客戶盡職調查 (EDD) 疑似洗錢交易申報 (STR) 制裁名單篩檢 1.5.3 網路安全 適用法規：資通安全管理法、個資法、銀行法 關鍵要求： 資訊安全管理制度 事件應變機制 定期安全評估 員工安全教育訓練 2. 主要法規與標準（國內/國際） 2.1 台灣金融法規 🇹🇼 2.1.1 核心法規 銀行法 主管機關：金融監督管理委員會 適用對象：銀行業、信用合作社 關鍵條文： 第33條：銀行業務限制 第45條：資本適足性要求 第48條：業務查核與申報 專案影響：系統功能設計須符合業務範圍限制 個人資料保護法 施行日期：2012年10月1日 適用範圍：所有處理個人資料的公務機關及非公務機關 關鍵要求： 告知義務（第8條） 資料正確性維護（第11條） 安全維護措施（第27條） 罰則：新台幣2萬元以上20萬元以下罰鍰 洗錢防制法 最新修正：2018年11月7日 主要內容： 金融機構防制洗錢辦法 客戶盡職調查程序 疑似洗錢交易申報 系統要求： 即時篩檢功能 交易監控系統 報告產製機制 2.1.2 監管指引 金管會相關函令 銀行業內部控制及稽核制度實施辦法 金融機構防制洗錢辦法 銀行業公司治理實務守則 中央銀行規定 外匯收支或交易申報辦法 銀行業辦理外匯業務管理辦法 2.2 國際法規與標準 2.2.1 歐盟法規 GDPR (General Data Protection Regulation) 生效日期：2018年5月25日 適用範圍： 歐盟境內的資料處理 向歐盟提供商品或服務 監控歐盟境內個人行為 關鍵原則： 合法性、公平性、透明性 目的限制 資料最小化 正確性 保存期限限制 完整性與機密性 個人權利： 存取權 (Right of Access) 更正權 (Right to Rectification) 刪除權 (Right to Erasure) 資料可攜權 (Right to Data Portability) 罰款：營業額4%或2,000萬歐元，取較高者 PSD2 (Payment Services Directive 2) 目的：促進歐盟支付服務創新與競爭 關鍵要求： 強客戶驗證 (SCA) 開放銀行 API 第三方支付服務提供者 (TPP) 規範 2.2.2 美國法規 SOX Act (Sarbanes-Oxley Act) 適用對象：美國上市公司 關鍵要求： 財務報告內控制度 管理層證明責任 外部稽核獨立性 CCPA (California Consumer Privacy Act) 生效日期：2020年1月1日 適用範圍：處理加州居民個人資訊的企業 消費者權利： 知情權 刪除權 選擇退出權 不歧視權 2.2.3 國際標準 Basel III 發布機構：巴塞爾銀行監理委員會 (BCBS) 主要內容： 資本適足性要求 流動性覆蓋率 (LCR) 淨穩定資金比率 (NSFR) 槓桿比率 實施時程：2019-2027年分階段實施 ISO 27001 標準名稱：資訊安全管理系統要求事項 認證效益： 提升客戶信任 符合法規要求 降低安全風險 關鍵流程： PDCA循環 風險評估 控制措施選擇 持續改善 FATF 40項建議 發布機構：金融行動工作組織 涵蓋範圍： AML/CFT政策與協調 洗錢與資恐犯罪化 預防措施 透明度與實質受益人 權責機關權力 國際合作 2.3 新興法規趨勢 2.3.1 數位資產相關 歐盟 MiCA (Markets in Crypto-Assets Regulation) 美國數位資產框架 台灣虛擬通貨管理規範 2.3.2 人工智慧與演算法 歐盟 AI Act 演算法透明度要求 AI偏見防制 2.3.3 ESG與永續金融 歐盟永續金融披露規則 (SFDR) 氣候相關財務揭露 (TCFD) 台灣永續分類標準 3. 專案生命周期各階段的合規檢查清單 3.1 專案啟動階段 (Project Initiation) 3.1.1 合規評估要點 法規適用性分析 識別適用法規：依據專案性質、地理範圍、客戶類型確認適用法規清單 法規影響評估：評估各項法規對專案範圍、時程、成本的影響 合規成本估算：預估合規相關的人力、系統、流程成本 利害關係人識別 監管機構：金管會、央行、銀行局等主管機關 內部合規單位：法令遵循處、風險管理處、稽核處 外部顧問：法律事務所、會計師事務所、合規顧問 業務單位：相關業務部門、營運單位 3.1.2 必要文件準備 專案章程 (Project Charter) # 專案合規聲明範例 ## 合規目標 本專案承諾遵循以下法規要求： - 個人資料保護法 - 洗錢防制法 - 銀行法相關規定 - ISO 27001 資訊安全標準 ## 合規責任 - 專案經理：整體合規監督 - 合規專員：專業合規指導 - 開發團隊：落實合規控制點 ## 合規里程碑 - 需求分析階段：完成合規需求識別 - 設計階段：完成合規控制點設計 - 開發階段：完成合規功能開發 - 測試階段：完成合規測試驗證 初步風險評估 合規風險清單：識別潛在的合規風險點 風險等級評估：高/中/低風險分級 初步應對策略：風險規避、降低、轉移、接受 3.2 需求分析階段 (Requirements Analysis) 3.2.1 合規需求收集 功能性合規需求 資料保護功能\n","title":""},{"content":" Codebase（單一程式碼庫，多個部署環境） 原則：一個應用程式應有單一程式碼庫，透過不同的部署（deploy）對應不同環境（dev/test/prod）。 解決方案：\n使用 GitLab repository 管理專案。 每個環境使用不同 branch 或 tag（如 develop, release, main）。 CI/CD pipeline 進行自動化部署，避免分散程式碼庫。 Dependencies（明確宣告與隔離依賴） 原則：應用程式必須明確管理相依性，避免依賴系統環境。 解決方案：\n後端：使用 Maven pom.xml 宣告所有 dependencies，不依賴本地安裝的 jar。 前端：使用 package.json 鎖定依賴版本。 建議使用 Docker 建立一致的 build/runtime 環境。 Config（將設定與程式碼分離） 原則：設定（如 DB 密碼、API key）不應寫死在程式碼中。 解決方案：\nSpring Boot 使用 application.yml + 外部設定檔 或 環境變數。 GitLab CI/CD 提供 Environment Variables 管理不同環境的設定。 建議搭配 Vault / AWS Secrets Manager / Kubernetes Secrets。 Backing Services（後端服務當作附加資源） 原則：資料庫、快取、MQ、外部 API 都應視為「可替換的資源」。 解決方案：\nDB（MySQL/DB2/PostgreSQL）、Redis、RabbitMQ 等連線資訊放在設定檔，不耦合程式。 測試環境可用輕量替代（如 testcontainers 啟動 DB/Redis）。 Build, Release, Run（明確分離建置、發佈、執行） 原則：建置（build）、發佈（release）、執行（run）必須分開，避免環境污染。 解決方案：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/12-factor-app-%E8%AA%AA%E6%98%8E%E8%88%87%E5%B0%8D%E6%87%89%E8%A7%A3%E6%B1%BA%E6%96%B9%E6%A1%88/","summary":" Codebase（單一程式碼庫，多個部署環境） 原則：一個應用程式應有單一程式碼庫，透過不同的部署（deploy）對應不同環境（dev/test/prod）。 解決方案：\n使用 GitLab repository 管理專案。 每個環境使用不同 branch 或 tag（如 develop, release, main）。 CI/CD pipeline 進行自動化部署，避免分散程式碼庫。 Dependencies（明確宣告與隔離依賴） 原則：應用程式必須明確管理相依性，避免依賴系統環境。 解決方案：\n後端：使用 Maven pom.xml 宣告所有 dependencies，不依賴本地安裝的 jar。 前端：使用 package.json 鎖定依賴版本。 建議使用 Docker 建立一致的 build/runtime 環境。 Config（將設定與程式碼分離） 原則：設定（如 DB 密碼、API key）不應寫死在程式碼中。 解決方案：\nSpring Boot 使用 application.yml + 外部設定檔 或 環境變數。 GitLab CI/CD 提供 Environment Variables 管理不同環境的設定。 建議搭配 Vault / AWS Secrets Manager / Kubernetes Secrets。 Backing Services（後端服務當作附加資源） 原則：資料庫、快取、MQ、外部 API 都應視為「可替換的資源」。 解決方案：\nDB（MySQL/DB2/PostgreSQL）、Redis、RabbitMQ 等連線資訊放在設定檔，不耦合程式。 測試環境可用輕量替代（如 testcontainers 啟動 DB/Redis）。 Build, Release, Run（明確分離建置、發佈、執行） 原則：建置（build）、發佈（release）、執行（run）必須分開，避免環境污染。 解決方案：\n","title":""},{"content":"Code Review 指引 目錄 前言 1.1 目的 1.2 適用範圍 1.3 Code Review 的價值 Code Review 基本原則 2.1 核心原則 2.2 責任分工 Code Review 流程 3.1 提交 Pull Request (PR) 3.2 指定 Reviewers 3.3 進行程式碼檢查 詳細檢查項目 4.1 程式碼風格與規範 4.2 邏輯正確性檢查 4.3 效能考量檢查 4.4 安全性檢查 4.5 測試覆蓋率檢查 Code Review 工具與自動化 5.1 GitHub Pull Request Review 5.2 GitLab Merge Request Review 5.3 SonarQube 程式碼品質檢查 5.4 ESLint 與 Prettier（前端） 實務操作指南 6.1 Review 意見分類與標準 6.2 常見審查重點清單 6.3 溝通技巧與最佳實務 6.4 Review 會議與討論 常見問題與解決方案 7.1 常見 Review 問題 7.2 效率提升技巧 團隊協作與衝突處理 8.1 Review 意見衝突處理 8.2 跨團隊 Review 協作 8.3 新人培訓與指導 特殊情況處理 9.1 緊急修正流程 9.2 大型重構 Review 9.3 第三方程式碼整合 持續改進與測量 10.1 Review 品質指標 10.2 流程效率分析 10.3 團隊成長追蹤 參考資源與延伸閱讀 11.1 程式碼品質標準 11.2 安全性資源 11.3 工具文件 11.4 最佳實務書籍 附錄 12.1 Review 檢查清單範本 12.2 團隊 Code Review 文化建立 1. 前言 1.1 目的 本指引旨在建立標準化的程式碼審查流程，確保所有程式碼在合併至主分支前都經過充分的檢查與評審，以提升程式碼品質、降低潛在錯誤與技術負債，並促進團隊知識分享與技能提升。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/code-review-%E6%8C%87%E5%BC%95/","summary":"Code Review 指引 目錄 前言 1.1 目的 1.2 適用範圍 1.3 Code Review 的價值 Code Review 基本原則 2.1 核心原則 2.2 責任分工 Code Review 流程 3.1 提交 Pull Request (PR) 3.2 指定 Reviewers 3.3 進行程式碼檢查 詳細檢查項目 4.1 程式碼風格與規範 4.2 邏輯正確性檢查 4.3 效能考量檢查 4.4 安全性檢查 4.5 測試覆蓋率檢查 Code Review 工具與自動化 5.1 GitHub Pull Request Review 5.2 GitLab Merge Request Review 5.3 SonarQube 程式碼品質檢查 5.4 ESLint 與 Prettier（前端） 實務操作指南 6.1 Review 意見分類與標準 6.2 常見審查重點清單 6.3 溝通技巧與最佳實務 6.4 Review 會議與討論 常見問題與解決方案 7.1 常見 Review 問題 7.2 效率提升技巧 團隊協作與衝突處理 8.1 Review 意見衝突處理 8.2 跨團隊 Review 協作 8.3 新人培訓與指導 特殊情況處理 9.1 緊急修正流程 9.2 大型重構 Review 9.3 第三方程式碼整合 持續改進與測量 10.1 Review 品質指標 10.2 流程效率分析 10.3 團隊成長追蹤 參考資源與延伸閱讀 11.1 程式碼品質標準 11.2 安全性資源 11.3 工具文件 11.4 最佳實務書籍 附錄 12.1 Review 檢查清單範本 12.2 團隊 Code Review 文化建立 1. 前言 1.1 目的 本指引旨在建立標準化的程式碼審查流程，確保所有程式碼在合併至主分支前都經過充分的檢查與評審，以提升程式碼品質、降低潛在錯誤與技術負債，並促進團隊知識分享與技能提升。\n","title":""},{"content":"以下是完整的 《JdbcTemplate 安全 SQL 實作指引文件》Markdown 版本，可直接放入你的 Git Repository（例如 /docs/security/jdbctemplate-sql-guideline.md），作為團隊安全規範或 Code Review checklist 使用。\n# 🧭 JdbcTemplate 安全 SQL 實作指引文件 **版本：v1.0** **適用範圍：** Spring Boot 專案中使用 `JdbcTemplate` 或 `NamedParameterJdbcTemplate` 的資料存取層 **目的：** 防止 SQL Injection 攻擊與弱掃誤判 --- ## 1️⃣ 目的與原則 SQL Injection（SQL 注入）是 OWASP Top 10 的主要風險之一。 若在 API 中直接拼接 SQL 字串（尤其包含前端輸入），將導致弱掃報告出現 Injection 問題，甚至被惡意利用。 **安全實作原則：** 1. 所有 SQL 查詢必須採用 **參數化查詢（Parameterized Query）**。 2. 不可直接拼接使用者輸入字串到 SQL。 3. 動態欄位或排序需求必須使用 **白名單機制（Whitelist）**。 4. 禁止讓 client 直接傳入完整 SQL。 5. 所有 DB 帳號採用最小權限原則（Least Privilege）。 --- ## 2️⃣ 正確安全作法範例 ### ✅ 查詢範例 ```java String sql = \u0026#34;SELECT id, name, email FROM users WHERE email = ?\u0026#34;; return jdbcTemplate.query(sql, new Object[]{email}, new UserRowMapper()); ✅ 插入範例 String sql = \u0026#34;INSERT INTO users (name, email) VALUES (?, ?)\u0026#34;; jdbcTemplate.update(sql, name, email); ✅ 更新範例 String sql = \u0026#34;UPDATE users SET status = ? WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, status, id); ✅ 刪除範例 String sql = \u0026#34;DELETE FROM users WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, id); ✅ 動態查詢（條件可變） 重點：條件以程式判斷拼接，但參數仍使用 ? 綁定。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/jdbctemplate-%E5%AE%89%E5%85%A8-sql-%E5%AF%A6%E4%BD%9C%E6%8C%87%E5%BC%95%E6%96%87%E4%BB%B6/","summary":"以下是完整的 《JdbcTemplate 安全 SQL 實作指引文件》Markdown 版本，可直接放入你的 Git Repository（例如 /docs/security/jdbctemplate-sql-guideline.md），作為團隊安全規範或 Code Review checklist 使用。\n# 🧭 JdbcTemplate 安全 SQL 實作指引文件 **版本：v1.0** **適用範圍：** Spring Boot 專案中使用 `JdbcTemplate` 或 `NamedParameterJdbcTemplate` 的資料存取層 **目的：** 防止 SQL Injection 攻擊與弱掃誤判 --- ## 1️⃣ 目的與原則 SQL Injection（SQL 注入）是 OWASP Top 10 的主要風險之一。 若在 API 中直接拼接 SQL 字串（尤其包含前端輸入），將導致弱掃報告出現 Injection 問題，甚至被惡意利用。 **安全實作原則：** 1. 所有 SQL 查詢必須採用 **參數化查詢（Parameterized Query）**。 2. 不可直接拼接使用者輸入字串到 SQL。 3. 動態欄位或排序需求必須使用 **白名單機制（Whitelist）**。 4. 禁止讓 client 直接傳入完整 SQL。 5. 所有 DB 帳號採用最小權限原則（Least Privilege）。 --- ## 2️⃣ 正確安全作法範例 ### ✅ 查詢範例 ```java String sql = \u0026#34;SELECT id, name, email FROM users WHERE email = ?\u0026#34;; return jdbcTemplate.query(sql, new Object[]{email}, new UserRowMapper()); ✅ 插入範例 String sql = \u0026#34;INSERT INTO users (name, email) VALUES (?, ?)\u0026#34;; jdbcTemplate.update(sql, name, email); ✅ 更新範例 String sql = \u0026#34;UPDATE users SET status = ? WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, status, id); ✅ 刪除範例 String sql = \u0026#34;DELETE FROM users WHERE id = ?\u0026#34;; jdbcTemplate.update(sql, id); ✅ 動態查詢（條件可變） 重點：條件以程式判斷拼接，但參數仍使用 ? 綁定。\n","title":""},{"content":"重構指引（Refactoring Guide） 目錄 前言與目標 什麼是重構？ 重構的核心目標 重構原則 基本原則 SOLID 原則在重構中的應用 重構時機 何時應該進行重構？ 重構的紅綠燈系統 常見重構手法 提煉函數（Extract Function） 提煉類別（Extract Class） 簡化條件表達式（Simplify Conditional Expressions） 提煉常數（Extract Constants） 移除死程式碼（Remove Dead Code） 重構流程 標準重構流程 重構檢核清單 Java 重構最佳實務 IDE 重構工具使用 Maven 設定重構支援 重構中的測試策略 安全性考量 重構過程中的安全原則 重構中的資安檢核清單 效能考量 重構對效能的影響 效能測試與監控 重構工具與技術 靜態分析工具 自動化重構工具 持續整合中的重構 常見重構陷阱與解決方案 常見錯誤 最佳實務建議 重構案例研究 遺留系統重構 微服務重構 重構檢核清單 重構前檢核 重構中檢核 重構後檢核 團隊協作與重構 Code Review 中的重構 重構溝通策略 重構效果追蹤 短期追蹤 中期追蹤 長期追蹤 結論 前言與目標 什麼是重構？ 重構（Refactoring）是指在不改變程式碼外部行為的前提下，對程式碼內部結構進行改善的過程。這是一種持續性的改進活動，旨在提升程式碼品質、可讀性和可維護性。\n重構的核心目標 1. 提高可讀性 目標：讓程式碼更容易理解，降低未來維護的難度 效益： 新團隊成員能快速上手 減少程式碼理解時間 降低錯誤修改的風險 評估指標： 程式碼複雜度（Cyclomatic Complexity） 方法長度 類別職責單一性 2. 改善結構與設計 目標：優化架構，使程式更具彈性、可擴充性 效益： 更容易添加新功能 更好的模組化設計 符合 SOLID 設計原則 評估指標： 耦合度（Coupling） 內聚性（Cohesion） 設計模式使用適當性 3. 減少重複（DRY 原則） 目標：把重複的邏輯抽出來，讓程式碼更簡潔 效益： 減少程式碼維護成本 降低一致性問題 提高程式碼重用性 評估指標： 重複程式碼比例 共用元件使用率 4. 提升可測試性 目標：更清晰的結構有助於單元測試與整合測試 效益： 更容易編寫單元測試 提高測試覆蓋率 更好的依賴注入設計 評估指標： 測試覆蓋率 測試案例數量 模擬物件使用便利性 5. 降低技術債（Technical Debt） 目標：清理過時或混亂的程式碼，避免未來出現更多問題 效益： 提升開發效率 減少維護成本 降低系統風險 評估指標： SonarQube 品質評分 程式碼異味數量 安全漏洞數量 6. 促進團隊協作 目標：統一風格與結構，讓不同開發者更容易接手 效益： 提升團隊開發效率 降低知識傳承成本 統一開發標準 評估指標： 程式碼風格一致性 Code Review 效率 團隊生產力 重構原則 基本原則 1. 保持外部行為不變 重構過程中，程式的功能和對外介面不應改變 所有現有的測試案例應該繼續通過 使用者感受不到任何功能上的差異 2. 小步快跑 每次重構應該是小幅度的改動 頻繁進行測試驗證 避免大範圍的同時修改 3. 測試先行 重構前確保有足夠的測試覆蓋 重構過程中持續執行測試 新增測試案例以驗證重構結果 4. 循序漸進 按照優先順序進行重構 先解決最嚴重的程式碼異味 避免過度重構 SOLID 原則在重構中的應用 1. 單一職責原則（Single Responsibility Principle） // 重構前：一個類別負責多個職責 public class UserManager { public void saveUser(User user) { // 驗證使用者資料 if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } // 儲存到資料庫 DatabaseConnection conn = new DatabaseConnection(); conn.save(user); // 發送通知郵件 EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(user.getEmail()); } } // 重構後：職責分離 public class UserValidator { public void validate(User user) { if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } } } public class UserRepository { public void save(User user) { DatabaseConnection conn = new DatabaseConnection(); conn.save(user); } } public class UserNotificationService { public void sendWelcomeNotification(String email) { EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(email); } } public class UserService { private final UserValidator validator; private final UserRepository repository; private final UserNotificationService notificationService; public UserService(UserValidator validator, UserRepository repository, UserNotificationService notificationService) { this.validator = validator; this.repository = repository; this.notificationService = notificationService; } public void createUser(User user) { validator.validate(user); repository.save(user); notificationService.sendWelcomeNotification(user.getEmail()); } } 2. 開放封閉原則（Open/Closed Principle） // 重構前：修改現有程式碼來新增功能 public class DiscountCalculator { public double calculateDiscount(String customerType, double amount) { if (\u0026#34;REGULAR\u0026#34;.equals(customerType)) { return amount * 0.05; } else if (\u0026#34;VIP\u0026#34;.equals(customerType)) { return amount * 0.10; } else if (\u0026#34;PREMIUM\u0026#34;.equals(customerType)) { return amount * 0.15; } return 0; } } // 重構後：使用策略模式，對擴展開放，對修改封閉 public interface DiscountStrategy { double calculateDiscount(double amount); } public class RegularCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.05; } } public class VipCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.10; } } public class PremiumCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.15; } } public class DiscountCalculator { private final Map\u0026lt;String, DiscountStrategy\u0026gt; strategies; public DiscountCalculator() { strategies = Map.of( \u0026#34;REGULAR\u0026#34;, new RegularCustomerDiscount(), \u0026#34;VIP\u0026#34;, new VipCustomerDiscount(), \u0026#34;PREMIUM\u0026#34;, new PremiumCustomerDiscount() ); } public double calculateDiscount(String customerType, double amount) { DiscountStrategy strategy = strategies.get(customerType); return strategy != null ? strategy.calculateDiscount(amount) : 0; } } 重構時機 何時應該進行重構？ 1. 程式碼異味（Code Smells）出現時 長方法（Long Method）：方法超過 20-30 行 大類別（Large Class）：類別職責過多，超過 200-300 行 重複程式碼（Duplicated Code）：相同或相似的程式碼片段重複出現 長參數列表（Long Parameter List）：方法參數超過 3-4 個 2. 新增功能前 為新功能建立適當的架構基礎 清理相關的程式碼區域 確保新功能不會增加技術債 3. 修復 Bug 時 分析 Bug 產生的根本原因 改善可能導致類似問題的程式結構 增加相關的測試覆蓋 4. Code Review 過程中 發現程式碼可讀性問題 識別潛在的設計問題 統一團隊的程式碼風格 重構的紅綠燈系統 🟢 綠燈：適合重構 有充足的測試覆蓋（\u0026gt;80%） 沒有緊急的產品發布壓力 團隊對重構區域有充分了解 有足夠的時間進行測試驗證 🟡 黃燈：謹慎重構 測試覆蓋率中等（60-80%） 有適度的時間壓力 重構範圍較大 需要多人協作 🔴 紅燈：暫停重構 測試覆蓋率不足（\u0026lt;60%） 有緊急的產品發布 程式碼變動頻繁 缺乏領域知識 常見重構手法 1. 提煉函數（Extract Function） 目的 將重複的程式碼片段提煉成獨立的函數，提高重用性和可讀性。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/refactor-%E9%87%8D%E6%A7%8B%E6%8C%87%E5%BC%95/","summary":"重構指引（Refactoring Guide） 目錄 前言與目標 什麼是重構？ 重構的核心目標 重構原則 基本原則 SOLID 原則在重構中的應用 重構時機 何時應該進行重構？ 重構的紅綠燈系統 常見重構手法 提煉函數（Extract Function） 提煉類別（Extract Class） 簡化條件表達式（Simplify Conditional Expressions） 提煉常數（Extract Constants） 移除死程式碼（Remove Dead Code） 重構流程 標準重構流程 重構檢核清單 Java 重構最佳實務 IDE 重構工具使用 Maven 設定重構支援 重構中的測試策略 安全性考量 重構過程中的安全原則 重構中的資安檢核清單 效能考量 重構對效能的影響 效能測試與監控 重構工具與技術 靜態分析工具 自動化重構工具 持續整合中的重構 常見重構陷阱與解決方案 常見錯誤 最佳實務建議 重構案例研究 遺留系統重構 微服務重構 重構檢核清單 重構前檢核 重構中檢核 重構後檢核 團隊協作與重構 Code Review 中的重構 重構溝通策略 重構效果追蹤 短期追蹤 中期追蹤 長期追蹤 結論 前言與目標 什麼是重構？ 重構（Refactoring）是指在不改變程式碼外部行為的前提下，對程式碼內部結構進行改善的過程。這是一種持續性的改進活動，旨在提升程式碼品質、可讀性和可維護性。\n重構的核心目標 1. 提高可讀性 目標：讓程式碼更容易理解，降低未來維護的難度 效益： 新團隊成員能快速上手 減少程式碼理解時間 降低錯誤修改的風險 評估指標： 程式碼複雜度（Cyclomatic Complexity） 方法長度 類別職責單一性 2. 改善結構與設計 目標：優化架構，使程式更具彈性、可擴充性 效益： 更容易添加新功能 更好的模組化設計 符合 SOLID 設計原則 評估指標： 耦合度（Coupling） 內聚性（Cohesion） 設計模式使用適當性 3. 減少重複（DRY 原則） 目標：把重複的邏輯抽出來，讓程式碼更簡潔 效益： 減少程式碼維護成本 降低一致性問題 提高程式碼重用性 評估指標： 重複程式碼比例 共用元件使用率 4. 提升可測試性 目標：更清晰的結構有助於單元測試與整合測試 效益： 更容易編寫單元測試 提高測試覆蓋率 更好的依賴注入設計 評估指標： 測試覆蓋率 測試案例數量 模擬物件使用便利性 5. 降低技術債（Technical Debt） 目標：清理過時或混亂的程式碼，避免未來出現更多問題 效益： 提升開發效率 減少維護成本 降低系統風險 評估指標： SonarQube 品質評分 程式碼異味數量 安全漏洞數量 6. 促進團隊協作 目標：統一風格與結構，讓不同開發者更容易接手 效益： 提升團隊開發效率 降低知識傳承成本 統一開發標準 評估指標： 程式碼風格一致性 Code Review 效率 團隊生產力 重構原則 基本原則 1. 保持外部行為不變 重構過程中，程式的功能和對外介面不應改變 所有現有的測試案例應該繼續通過 使用者感受不到任何功能上的差異 2. 小步快跑 每次重構應該是小幅度的改動 頻繁進行測試驗證 避免大範圍的同時修改 3. 測試先行 重構前確保有足夠的測試覆蓋 重構過程中持續執行測試 新增測試案例以驗證重構結果 4. 循序漸進 按照優先順序進行重構 先解決最嚴重的程式碼異味 避免過度重構 SOLID 原則在重構中的應用 1. 單一職責原則（Single Responsibility Principle） // 重構前：一個類別負責多個職責 public class UserManager { public void saveUser(User user) { // 驗證使用者資料 if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } // 儲存到資料庫 DatabaseConnection conn = new DatabaseConnection(); conn.save(user); // 發送通知郵件 EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(user.getEmail()); } } // 重構後：職責分離 public class UserValidator { public void validate(User user) { if (user.getEmail() == null || !user.getEmail().contains(\u0026#34;@\u0026#34;)) { throw new IllegalArgumentException(\u0026#34;Invalid email\u0026#34;); } } } public class UserRepository { public void save(User user) { DatabaseConnection conn = new DatabaseConnection(); conn.save(user); } } public class UserNotificationService { public void sendWelcomeNotification(String email) { EmailService emailService = new EmailService(); emailService.sendWelcomeEmail(email); } } public class UserService { private final UserValidator validator; private final UserRepository repository; private final UserNotificationService notificationService; public UserService(UserValidator validator, UserRepository repository, UserNotificationService notificationService) { this.validator = validator; this.repository = repository; this.notificationService = notificationService; } public void createUser(User user) { validator.validate(user); repository.save(user); notificationService.sendWelcomeNotification(user.getEmail()); } } 2. 開放封閉原則（Open/Closed Principle） // 重構前：修改現有程式碼來新增功能 public class DiscountCalculator { public double calculateDiscount(String customerType, double amount) { if (\u0026#34;REGULAR\u0026#34;.equals(customerType)) { return amount * 0.05; } else if (\u0026#34;VIP\u0026#34;.equals(customerType)) { return amount * 0.10; } else if (\u0026#34;PREMIUM\u0026#34;.equals(customerType)) { return amount * 0.15; } return 0; } } // 重構後：使用策略模式，對擴展開放，對修改封閉 public interface DiscountStrategy { double calculateDiscount(double amount); } public class RegularCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.05; } } public class VipCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.10; } } public class PremiumCustomerDiscount implements DiscountStrategy { @Override public double calculateDiscount(double amount) { return amount * 0.15; } } public class DiscountCalculator { private final Map\u0026lt;String, DiscountStrategy\u0026gt; strategies; public DiscountCalculator() { strategies = Map.of( \u0026#34;REGULAR\u0026#34;, new RegularCustomerDiscount(), \u0026#34;VIP\u0026#34;, new VipCustomerDiscount(), \u0026#34;PREMIUM\u0026#34;, new PremiumCustomerDiscount() ); } public double calculateDiscount(String customerType, double amount) { DiscountStrategy strategy = strategies.get(customerType); return strategy != null ? strategy.calculateDiscount(amount) : 0; } } 重構時機 何時應該進行重構？ 1. 程式碼異味（Code Smells）出現時 長方法（Long Method）：方法超過 20-30 行 大類別（Large Class）：類別職責過多，超過 200-300 行 重複程式碼（Duplicated Code）：相同或相似的程式碼片段重複出現 長參數列表（Long Parameter List）：方法參數超過 3-4 個 2. 新增功能前 為新功能建立適當的架構基礎 清理相關的程式碼區域 確保新功能不會增加技術債 3. 修復 Bug 時 分析 Bug 產生的根本原因 改善可能導致類似問題的程式結構 增加相關的測試覆蓋 4. Code Review 過程中 發現程式碼可讀性問題 識別潛在的設計問題 統一團隊的程式碼風格 重構的紅綠燈系統 🟢 綠燈：適合重構 有充足的測試覆蓋（\u0026gt;80%） 沒有緊急的產品發布壓力 團隊對重構區域有充分了解 有足夠的時間進行測試驗證 🟡 黃燈：謹慎重構 測試覆蓋率中等（60-80%） 有適度的時間壓力 重構範圍較大 需要多人協作 🔴 紅燈：暫停重構 測試覆蓋率不足（\u0026lt;60%） 有緊急的產品發布 程式碼變動頻繁 缺乏領域知識 常見重構手法 1. 提煉函數（Extract Function） 目的 將重複的程式碼片段提煉成獨立的函數，提高重用性和可讀性。\n","title":""},{"content":"UI/UX 開發指引 目錄 文件概述 設計原則 1.1 銀行系統的安全性與一致性要求 1.2 清晰的資訊層次與導航設計 1.3 金融資料顯示與重點突顯規範 1.4 無障礙設計（WCAG 2.1 AA 級） 1.5 多語系支援 UI 元件規範 2.1 樣式系統 (Design System) 2.2 響應式設計規範 2.3 常用元件設計 UX 流程規範 3.1 表單驗證與錯誤回饋 3.2 使用者引導 (Onboarding) 3.3 搜尋、篩選與排序互動設計 3.4 資料載入與狀態設計 設計資產與交付 4.1 設計 Token 系統 4.2 元件庫架構 Vue 3 + Tailwind CSS 最佳實踐 5.1 元件命名與結構規範 5.2 Tailwind CSS 自定義配置 檢測與驗證 6.1 視覺回歸測試 6.2 無障礙檢測 6.3 使用性測試清單 性能優化指引 設計協作流程 維護與版本控制 附錄 文件概述 本指引適用於大型金融共用平台的前端 UI/UX 開發，涵蓋設計原則、UI 元件規範、UX 流程、設計資產交付等完整內容。\n專案技術堆疊 前端架構: 微前端 + SPA (Single-Page App\u0026mdash; 第一部分完成，接下來我將繼續撰寫第二部分：無障礙設計和多語系支援。\n1.4 無障礙設計（WCAG 2.1 AA 級） 色彩對比度要求 正常文字: 對比度至少 4.5:1 大文字 (18pt 以上): 對比度至少 3:1 互動元件: 對比度至少 3:1 /* Tailwind CSS 無障礙色彩配置 */ .text-primary { @apply text-gray-900; /* 對比度 21:1 */ } .text-secondary { @apply text-gray-700; /* 對比度 9.2:1 */ } .bg-interactive { @apply bg-blue-600 hover:bg-blue-700 focus:bg-blue-700; } .bg-interactive:focus { @apply ring-2 ring-blue-500 ring-offset-2; } 鍵盤操作支援 Tab 順序: 邏輯性的焦點移動順序 快捷鍵: 主要功能提供鍵盤快捷鍵 焦點指示: 清晰的焦點視覺回饋 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙表單範例 --\u0026gt; \u0026lt;form @submit.prevent=\u0026#34;handleSubmit\u0026#34; class=\u0026#34;space-y-6\u0026#34;\u0026gt; \u0026lt;div\u0026gt; \u0026lt;label for=\u0026#34;account-number\u0026#34; class=\u0026#34;block text-sm font-medium text-gray-700\u0026#34;\u0026gt; 帳戶號碼 \u0026lt;span class=\u0026#34;text-red-500\u0026#34; aria-label=\u0026#34;必填欄位\u0026#34;\u0026gt;*\u0026lt;/span\u0026gt; \u0026lt;/label\u0026gt; \u0026lt;input id=\u0026#34;account-number\u0026#34; v-model=\u0026#34;accountNumber\u0026#34; type=\u0026#34;text\u0026#34; required aria-describedby=\u0026#34;account-help account-error\u0026#34; class=\u0026#34;mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500\u0026#34; :aria-invalid=\u0026#34;hasError\u0026#34; /\u0026gt; \u0026lt;p id=\u0026#34;account-help\u0026#34; class=\u0026#34;mt-2 text-sm text-gray-500\u0026#34;\u0026gt; 請輸入 12 位數字帳戶號碼 \u0026lt;/p\u0026gt; \u0026lt;p id=\u0026#34;account-error\u0026#34; v-if=\u0026#34;errorMessage\u0026#34; class=\u0026#34;mt-2 text-sm text-red-600\u0026#34; role=\u0026#34;alert\u0026#34;\u0026gt; {{ errorMessage }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/form\u0026gt; \u0026lt;/template\u0026gt; 螢幕閱讀器支援 語義化 HTML: 使用適當的 HTML 語義標籤 ARIA 標籤: 補充無障礙資訊 替代文字: 圖片提供有意義的 alt 文字 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙數據表格 --\u0026gt; \u0026lt;table role=\u0026#34;table\u0026#34; aria-label=\u0026#34;帳戶交易記錄\u0026#34;\u0026gt; \u0026lt;caption class=\u0026#34;sr-only\u0026#34;\u0026gt; 最近 10 筆交易記錄，包含日期、摘要、金額和餘額 \u0026lt;/caption\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 交易日期 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 摘要 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-right text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 金額 \u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr v-for=\u0026#34;transaction in transactions\u0026#34; :key=\u0026#34;transaction.id\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ formatDate(transaction.date) }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ transaction.description }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-right\u0026#34;\u0026gt; \u0026lt;span :class=\u0026#34;transaction.amount \u0026gt;= 0 ? \u0026#39;text-green-600\u0026#39; : \u0026#39;text-red-600\u0026#39;\u0026#34;\u0026gt; {{ formatCurrency(transaction.amount) }} \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; \u0026lt;/template\u0026gt; 1.5 多語系支援 語言切換機制 // i18n 配置 import { createI18n } from \u0026#39;vue-i18n\u0026#39;; interface Messages { \u0026#39;zh-TW\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;en-US\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;ja-JP\u0026#39;: Record\u0026lt;string, any\u0026gt;; } const messages: Messages = { \u0026#39;zh-TW\u0026#39;: { common: { confirm: \u0026#39;確認\u0026#39;, cancel: \u0026#39;取消\u0026#39;, save: \u0026#39;儲存\u0026#39;, delete: \u0026#39;刪除\u0026#39;, loading: \u0026#39;載入中...\u0026#39; }, account: { balance: \u0026#39;帳戶餘額\u0026#39;, transfer: \u0026#39;轉帳\u0026#39;, history: \u0026#39;交易記錄\u0026#39; } }, \u0026#39;en-US\u0026#39;: { common: { confirm: \u0026#39;Confirm\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, save: \u0026#39;Save\u0026#39;, delete: \u0026#39;Delete\u0026#39;, loading: \u0026#39;Loading...\u0026#39; }, account: { balance: \u0026#39;Account Balance\u0026#39;, transfer: \u0026#39;Transfer\u0026#39;, history: \u0026#39;Transaction History\u0026#39; } } }; export const i18n = createI18n({ locale: \u0026#39;zh-TW\u0026#39;, fallbackLocale: \u0026#39;en-US\u0026#39;, messages }); 文字方向支援 (RTL/LTR) \u0026lt;template\u0026gt; \u0026lt;div :dir=\u0026#34;currentLocale.dir\u0026#34; class=\u0026#34;app-container\u0026#34;\u0026gt; \u0026lt;!-- 語言切換器 --\u0026gt; \u0026lt;div class=\u0026#34;language-selector\u0026#34;\u0026gt; \u0026lt;select v-model=\u0026#34;currentLanguage\u0026#34; @change=\u0026#34;changeLanguage\u0026#34; class=\u0026#34;block w-32 rounded-md border-gray-300\u0026#34; :aria-label=\u0026#34;$t(\u0026#39;common.selectLanguage\u0026#39;)\u0026#34; \u0026gt; \u0026lt;option value=\u0026#34;zh-TW\u0026#34;\u0026gt;繁體中文\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;en-US\u0026#34;\u0026gt;English\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;ar-SA\u0026#34;\u0026gt;العربية\u0026lt;/option\u0026gt; \u0026lt;/select\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed } from \u0026#39;vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; const { locale, t } = useI18n(); const localeConfig = { \u0026#39;zh-TW\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;繁體中文\u0026#39; }, \u0026#39;en-US\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;English\u0026#39; }, \u0026#39;ar-SA\u0026#39;: { dir: \u0026#39;rtl\u0026#39;, name: \u0026#39;العربية\u0026#39; } }; const currentLocale = computed(() =\u0026gt; localeConfig[locale.value]); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* RTL 支援樣式 */ [dir=\u0026#34;rtl\u0026#34;] .text-left { text-align: right; } [dir=\u0026#34;rtl\u0026#34;] .text-right { text-align: left; } [dir=\u0026#34;rtl\u0026#34;] .ml-4 { margin-left: 0; margin-right: 1rem; } \u0026lt;/style\u0026gt; 數字與日期本地化 // 本地化格式化工具 export class LocaleFormatter { private locale: string; constructor(locale: string) { this.locale = locale; } // 金額格式化 formatCurrency(amount: number, currency: string = \u0026#39;TWD\u0026#39;): string { const currencyMap = { \u0026#39;zh-TW\u0026#39;: \u0026#39;TWD\u0026#39;, \u0026#39;en-US\u0026#39;: \u0026#39;USD\u0026#39;, \u0026#39;ja-JP\u0026#39;: \u0026#39;JPY\u0026#39;, \u0026#39;ko-KR\u0026#39;: \u0026#39;KRW\u0026#39; }; return new Intl.NumberFormat(this.locale, { style: \u0026#39;currency\u0026#39;, currency: currencyMap[this.locale] || currency, minimumFractionDigits: currency === \u0026#39;JPY\u0026#39; ? 0 : 2 }).format(amount); } // 日期格式化 formatDate(date: Date, options?: Intl.DateTimeFormatOptions): string { const defaultOptions: Intl.DateTimeFormatOptions = { year: \u0026#39;numeric\u0026#39;, month: \u0026#39;short\u0026#39;, day: \u0026#39;numeric\u0026#39; }; return new Intl.DateTimeFormat(this.locale, options || defaultOptions).format(date); } // 時間格式化 formatTime(date: Date): string { return new Intl.DateTimeFormat(this.locale, { hour: \u0026#39;2-digit\u0026#39;, minute: \u0026#39;2-digit\u0026#39;, hour12: this.locale === \u0026#39;en-US\u0026#39; }).format(date); } // 百分比格式化 formatPercentage(value: number): string { return new Intl.NumberFormat(this.locale, { style: \u0026#39;percent\u0026#39;, minimumFractionDigits: 2, maximumFractionDigits: 2 }).format(value); } } 進階無障礙設計實作 \u0026lt;template\u0026gt; \u0026lt;!-- 高對比模式切換 --\u0026gt; \u0026lt;div class=\u0026#34;accessibility-controls fixed top-4 right-4 z-50\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleHighContrast\u0026#34; :aria-pressed=\u0026#34;isHighContrast\u0026#34; class=\u0026#34;p-2 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; :class=\u0026#34;isHighContrast ? \u0026#39;bg-yellow-400 text-black\u0026#39; : \u0026#39;bg-white text-gray-700 shadow-md\u0026#39;\u0026#34; aria-label=\u0026#34;切換高對比模式\u0026#34; \u0026gt; \u0026lt;EyeIcon class=\u0026#34;h-5 w-5\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;!-- 字體大小調整 --\u0026gt; \u0026lt;div class=\u0026#34;mt-2 flex flex-col space-y-1\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;increaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;增大字體\u0026#34; \u0026gt; A\u0026#43; \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;decreaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;縮小字體\u0026#34; \u0026gt; A- \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;resetFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;重設字體大小\u0026#34; \u0026gt; A \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 跳至主要內容連結 --\u0026gt; \u0026lt;a href=\u0026#34;#main-content\u0026#34; class=\u0026#34;sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 bg-blue-600 text-white px-4 py-2 rounded-md z-50\u0026#34; \u0026gt; 跳至主要內容 \u0026lt;/a\u0026gt; \u0026lt;!-- 焦點陷阱對話框範例 --\u0026gt; \u0026lt;div v-if=\u0026#34;showModal\u0026#34; class=\u0026#34;fixed inset-0 z-10 overflow-y-auto\u0026#34; role=\u0026#34;dialog\u0026#34; aria-modal=\u0026#34;true\u0026#34; :aria-labelledby=\u0026#34;modalTitleId\u0026#34; @keydown.esc=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;flex items-end justify-center min-h-screen pt-4 px-4 pb-20 text-center sm:block sm:p-0\u0026#34;\u0026gt; \u0026lt;!-- 背景遮罩 --\u0026gt; \u0026lt;div class=\u0026#34;fixed inset-0 transition-opacity\u0026#34; aria-hidden=\u0026#34;true\u0026#34; @click=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;absolute inset-0 bg-gray-500 opacity-75\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 對話框內容 --\u0026gt; \u0026lt;div ref=\u0026#34;modalContent\u0026#34; class=\u0026#34;inline-block align-bottom bg-white rounded-lg text-left overflow-hidden shadow-xl transform transition-all sm:my-8 sm:align-middle sm:max-w-lg sm:w-full\u0026#34; @keydown=\u0026#34;handleModalKeydown\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;bg-white px-4 pt-5 pb-4 sm:p-6 sm:pb-4\u0026#34;\u0026gt; \u0026lt;h3 :id=\u0026#34;modalTitleId\u0026#34; class=\u0026#34;text-lg leading-6 font-medium text-gray-900 mb-4\u0026#34;\u0026gt; 確認操作 \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm text-gray-500 mb-4\u0026#34;\u0026gt; 您確定要執行此操作嗎？此動作無法復原。 \u0026lt;/p\u0026gt; \u0026lt;!-- 焦點陷阱內的可互動元素 --\u0026gt; \u0026lt;div class=\u0026#34;flex justify-end space-x-3\u0026#34;\u0026gt; \u0026lt;button ref=\u0026#34;cancelButton\u0026#34; @click=\u0026#34;closeModal\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-gray-700 bg-white border border-gray-300 rounded-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; \u0026gt; 取消 \u0026lt;/button\u0026gt; \u0026lt;button ref=\u0026#34;confirmButton\u0026#34; @click=\u0026#34;handleConfirm\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-white bg-red-600 border border-transparent rounded-md hover:bg-red-700 focus:outline-none focus:ring-2 focus:ring-red-500\u0026#34; \u0026gt; 確認 \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { ref, nextTick, onMounted, onUnmounted } from \u0026#39;vue\u0026#39;; import { EyeIcon } from \u0026#39;@heroicons/vue/24/outline\u0026#39;; // 無障礙狀態管理 const isHighContrast = ref(false); const fontSize = ref(16); const showModal = ref(false); const modalTitleId = ref(`modal-title-${Math.random().toString(36).substr(2, 9)}`); // 高對比模式 const toggleHighContrast = () =\u0026gt; { isHighContrast.value = !isHighContrast.value; document.documentElement.classList.toggle(\u0026#39;high-contrast\u0026#39;, isHighContrast.value); // 儲存使用者偏好 localStorage.setItem(\u0026#39;high-contrast\u0026#39;, isHighContrast.value.toString()); // 通知螢幕閱讀器 announceToScreenReader( isHighContrast.value ? \u0026#39;已開啟高對比模式\u0026#39; : \u0026#39;已關閉高對比模式\u0026#39; ); }; // 字體大小調整 const increaseFontSize = () =\u0026gt; { if (fontSize.value \u0026lt; 24) { fontSize.value \u0026#43;= 2; updateFontSize(); } }; const decreaseFontSize = () =\u0026gt; { if (fontSize.value \u0026gt; 12) { fontSize.value -= 2; updateFontSize(); } }; const resetFontSize = () =\u0026gt; { fontSize.value = 16; updateFontSize(); }; const updateFontSize = () =\u0026gt; { document.documentElement.style.fontSize = `${fontSize.value}px`; localStorage.setItem(\u0026#39;font-size\u0026#39;, fontSize.value.toString()); announceToScreenReader(`字體大小已調整為 ${fontSize.value} 像素`); }; // 螢幕閱讀器公告 const announceToScreenReader = (message: string) =\u0026gt; { const announcement = document.createElement(\u0026#39;div\u0026#39;); announcement.setAttribute(\u0026#39;aria-live\u0026#39;, \u0026#39;polite\u0026#39;); announcement.setAttribute(\u0026#39;aria-atomic\u0026#39;, \u0026#39;true\u0026#39;); announcement.className = \u0026#39;sr-only\u0026#39;; announcement.textContent = message; document.body.appendChild(announcement); setTimeout(() =\u0026gt; { document.body.removeChild(announcement); }, 1000); }; // 焦點陷阱管理 const modalContent = ref\u0026lt;HTMLElement\u0026gt;(); const cancelButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const confirmButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const focusableElements: HTMLElement[] = []; let previousFocusedElement: HTMLElement | null = null; const openModal = async () =\u0026gt; { previousFocusedElement = document.activeElement as HTMLElement; showModal.value = true; await nextTick(); // 收集可聚焦元素 const selector = \u0026#39;button, [href], input, select, textarea, [tabindex]:not([tabindex=\u0026#34;-1\u0026#34;])\u0026#39;; focusableElements.splice(0); focusableElements.push( ...Array.from(modalContent.value?.querySelectorAll(selector) || []) ); // 聚焦第一個元素 if (focusableElements.length \u0026gt; 0) { focusableElements[0].focus(); } }; const closeModal = () =\u0026gt; { showModal.value = false; // 恢復之前的焦點 if (previousFocusedElement) { previousFocusedElement.focus(); } }; const handleModalKeydown = (event: KeyboardEvent) =\u0026gt; { if (event.key === \u0026#39;Tab\u0026#39;) { const currentIndex = focusableElements.indexOf(event.target as HTMLElement); if (event.shiftKey) { // Shift \u0026#43; Tab (向後) if (currentIndex \u0026lt;= 0) { event.preventDefault(); focusableElements[focusableElements.length - 1].focus(); } } else { // Tab (向前) if (currentIndex \u0026gt;= focusableElements.length - 1) { event.preventDefault(); focusableElements[0].focus(); } } } }; const handleConfirm = () =\u0026gt; { // 處理確認邏輯 announceToScreenReader(\u0026#39;操作已確認\u0026#39;); closeModal(); }; // 鍵盤快捷鍵 const handleGlobalKeydown = (event: KeyboardEvent) =\u0026gt; { // Alt \u0026#43; H: 開啟高對比模式 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;h\u0026#39;) { event.preventDefault(); toggleHighContrast(); } // Alt \u0026#43; \u0026#43;: 增大字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;\u0026#43;\u0026#39;) { event.preventDefault(); increaseFontSize(); } // Alt \u0026#43; -: 縮小字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;-\u0026#39;) { event.preventDefault(); decreaseFontSize(); } }; // 初始化無障礙設定 onMounted(() =\u0026gt; { // 載入儲存的偏好設定 const savedHighContrast = localStorage.getItem(\u0026#39;high-contrast\u0026#39;); if (savedHighContrast === \u0026#39;true\u0026#39;) { isHighContrast.value = true; document.documentElement.classList.add(\u0026#39;high-contrast\u0026#39;); } const savedFontSize = localStorage.getItem(\u0026#39;font-size\u0026#39;); if (savedFontSize) { fontSize.value = parseInt(savedFontSize); document.documentElement.style.fontSize = `${fontSize.value}px`; } // 監聽全域鍵盤事件 document.addEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); // 檢測用戶偏好的配色方案 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-color-scheme: dark)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;dark-mode\u0026#39;); } // 檢測用戶偏好的動畫設定 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-reduced-motion: reduce)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;reduce-motion\u0026#39;); } }); onUnmounted(() =\u0026gt; { document.removeEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); }); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* 高對比模式樣式 */ .high-contrast { filter: contrast(150%) saturate(200%); } .high-contrast button { border: 2px solid currentColor !important; } .high-contrast a { text-decoration: underline !important; } /* 減少動畫模式 */ .reduce-motion *, .reduce-motion *::before, .reduce-motion *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } /* 深色模式支援 */ .dark-mode { color-scheme: dark; } /* 螢幕閱讀器專用隱藏 */ .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .sr-only.focus:focus { position: static; width: auto; height: auto; padding: inherit; margin: inherit; overflow: visible; clip: auto; white-space: normal; } \u0026lt;/style\u0026gt; 多語系內容管理策略 // 多語系內容管理 interface TranslationKey { key: string; context?: string; pluralization?: boolean; interpolation?: string[]; } interface TranslationContent { [locale: string]: { [namespace: string]: { [key: string]: string | object; }; }; } // 翻譯內容結構化管理 export const translationStructure: TranslationContent = { \u0026#39;zh-TW\u0026#39;: { common: { // 通用操作 actions: { save: \u0026#39;儲存\u0026#39;, cancel: \u0026#39;取消\u0026#39;, confirm: \u0026#39;確認\u0026#39;, delete: \u0026#39;刪除\u0026#39;, edit: \u0026#39;編輯\u0026#39;, add: \u0026#39;新增\u0026#39;, search: \u0026#39;搜尋\u0026#39;, filter: \u0026#39;篩選\u0026#39;, sort: \u0026#39;排序\u0026#39;, refresh: \u0026#39;重新整理\u0026#39;, loading: \u0026#39;載入中...\u0026#39;, noData: \u0026#39;無資料\u0026#39;, error: \u0026#39;發生錯誤\u0026#39; }, // 表單相關 form: { required: \u0026#39;此欄位為必填\u0026#39;, invalid: \u0026#39;格式不正確\u0026#39;, tooShort: \u0026#39;長度不足\u0026#39;, tooLong: \u0026#39;長度過長\u0026#39;, emailInvalid: \u0026#39;請輸入有效的電子郵件地址\u0026#39;, phoneInvalid: \u0026#39;請輸入有效的手機號碼\u0026#39;, passwordMismatch: \u0026#39;密碼不一致\u0026#39; }, // 時間相關 time: { just_now: \u0026#39;剛剛\u0026#39;, minutes_ago: \u0026#39;{count} 分鐘前\u0026#39;, hours_ago: \u0026#39;{count} 小時前\u0026#39;, days_ago: \u0026#39;{count} 天前\u0026#39;, weeks_ago: \u0026#39;{count} 週前\u0026#39;, months_ago: \u0026#39;{count} 個月前\u0026#39;, years_ago: \u0026#39;{count} 年前\u0026#39; } }, // 金融業務相關 banking: { account: { balance: \u0026#39;帳戶餘額\u0026#39;, available: \u0026#39;可用餘額\u0026#39;, accountNumber: \u0026#39;帳戶號碼\u0026#39;, accountType: \u0026#39;帳戶類型\u0026#39;, status: \u0026#39;狀態\u0026#39;, openDate: \u0026#39;開戶日期\u0026#39;, lastTransaction: \u0026#39;最近交易\u0026#39; }, transaction: { transfer: \u0026#39;轉帳\u0026#39;, deposit: \u0026#39;存款\u0026#39;, withdrawal: \u0026#39;提款\u0026#39;, payment: \u0026#39;付款\u0026#39;, refund: \u0026#39;退款\u0026#39;, fee: \u0026#39;手續費\u0026#39;, amount: \u0026#39;金額\u0026#39;, recipient: \u0026#39;收款人\u0026#39;, description: \u0026#39;摘要\u0026#39;, reference: \u0026#39;參考號碼\u0026#39;, date: \u0026#39;交易日期\u0026#39;, status: \u0026#39;交易狀態\u0026#39; }, status: { active: \u0026#39;啟用\u0026#39;, inactive: \u0026#39;停用\u0026#39;, pending: \u0026#39;處理中\u0026#39;, completed: \u0026#39;已完成\u0026#39;, failed: \u0026#39;失敗\u0026#39;, cancelled: \u0026#39;已取消\u0026#39;, expired: \u0026#39;已過期\u0026#39; } } }, \u0026#39;en-US\u0026#39;: { common: { actions: { save: \u0026#39;Save\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, confirm: \u0026#39;Confirm\u0026#39;, delete: \u0026#39;Delete\u0026#39;, edit: \u0026#39;Edit\u0026#39;, add: \u0026#39;Add\u0026#39;, search: \u0026#39;Search\u0026#39;, filter: \u0026#39;Filter\u0026#39;, sort: \u0026#39;Sort\u0026#39;, refresh: \u0026#39;Refresh\u0026#39;, loading: \u0026#39;Loading...\u0026#39;, noData: \u0026#39;No Data\u0026#39;, error: \u0026#39;Error Occurred\u0026#39; }, form: { required: \u0026#39;This field is required\u0026#39;, invalid: \u0026#39;Invalid format\u0026#39;, tooShort: \u0026#39;Too short\u0026#39;, tooLong: \u0026#39;Too long\u0026#39;, emailInvalid: \u0026#39;Please enter a valid email address\u0026#39;, phoneInvalid: \u0026#39;Please enter a valid phone number\u0026#39;, passwordMismatch: \u0026#39;Passwords do not match\u0026#39; }, time: { just_now: \u0026#39;Just now\u0026#39;, minutes_ago: \u0026#39;{count} minutes ago\u0026#39;, hours_ago: \u0026#39;{count} hours ago\u0026#39;, days_ago: \u0026#39;{count} days ago\u0026#39;, weeks_ago: \u0026#39;{count} weeks ago\u0026#39;, months_ago: \u0026#39;{count} months ago\u0026#39;, years_ago: \u0026#39;{count} years ago\u0026#39; } }, banking: { account: { balance: \u0026#39;Account Balance\u0026#39;, available: \u0026#39;Available Balance\u0026#39;, accountNumber: \u0026#39;Account Number\u0026#39;, accountType: \u0026#39;Account Type\u0026#39;, status: \u0026#39;Status\u0026#39;, openDate: \u0026#39;Open Date\u0026#39;, lastTransaction: \u0026#39;Last Transaction\u0026#39; }, transaction: { transfer: \u0026#39;Transfer\u0026#39;, deposit: \u0026#39;Deposit\u0026#39;, withdrawal: \u0026#39;Withdrawal\u0026#39;, payment: \u0026#39;Payment\u0026#39;, refund: \u0026#39;Refund\u0026#39;, fee: \u0026#39;Fee\u0026#39;, amount: \u0026#39;Amount\u0026#39;, recipient: \u0026#39;Recipient\u0026#39;, description: \u0026#39;Description\u0026#39;, reference: \u0026#39;Reference Number\u0026#39;, date: \u0026#39;Transaction Date\u0026#39;, status: \u0026#39;Transaction Status\u0026#39; }, status: { active: \u0026#39;Active\u0026#39;, inactive: \u0026#39;Inactive\u0026#39;, pending: \u0026#39;Pending\u0026#39;, completed: \u0026#39;Completed\u0026#39;, failed: \u0026#39;Failed\u0026#39;, cancelled: \u0026#39;Cancelled\u0026#39;, expired: \u0026#39;Expired\u0026#39; } } } }; // 進階翻譯函數 export class I18nManager { private currentLocale: string = \u0026#39;zh-TW\u0026#39;; private fallbackLocale: string = \u0026#39;en-US\u0026#39;; // 設定當前語言 setLocale(locale: string) { this.currentLocale = locale; document.documentElement.setAttribute(\u0026#39;lang\u0026#39;, locale); // 更新頁面方向 const direction = this.getTextDirection(locale); document.documentElement.setAttribute(\u0026#39;dir\u0026#39;, direction); // 觸發語言變更事件 window.dispatchEvent(new CustomEvent(\u0026#39;localeChanged\u0026#39;, { detail: { locale, direction } })); } // 取得文字方向 private getTextDirection(locale: string): \u0026#39;ltr\u0026#39; | \u0026#39;rtl\u0026#39; { const rtlLocales = [\u0026#39;ar\u0026#39;, \u0026#39;he\u0026#39;, \u0026#39;fa\u0026#39;, \u0026#39;ur\u0026#39;]; return rtlLocales.some(rtl =\u0026gt; locale.startsWith(rtl)) ? \u0026#39;rtl\u0026#39; : \u0026#39;ltr\u0026#39;; } // 翻譯函數 translate(key: string, options?: { interpolation?: Record\u0026lt;string, any\u0026gt;; count?: number; defaultValue?: string; }): string { const keys = key.split(\u0026#39;.\u0026#39;); let value = this.getNestedValue(translationStructure[this.currentLocale], keys); // 如果找不到翻譯，嘗試備用語言 if (!value) { value = this.getNestedValue(translationStructure[this.fallbackLocale], keys); } // 如果還是找不到，返回預設值或 key if (!value) { return options?.defaultValue || key; } // 處理插值 if (options?.interpolation) { Object.entries(options.interpolation).forEach(([placeholder, replacement]) =\u0026gt; { value = value.replace(new RegExp(`{${placeholder}}`, \u0026#39;g\u0026#39;), replacement); }); } // 處理複數形式 if (options?.count !== undefined) { value = this.handlePluralization(value, options.count); } return value; } // 取得巢狀物件值 private getNestedValue(obj: any, keys: string[]): string | null { return keys.reduce((current, key) =\u0026gt; current?.[key], obj) || null; } // 處理複數形式 private handlePluralization(value: string, count: number): string { // 簡化的複數處理，實際應用中可能需要更複雜的邏輯 if (this.currentLocale === \u0026#39;en-US\u0026#39;) { if (count === 1) { return value.replace(/\\{count\\}/, count.toString()); } else { // 處理英文複數規則 return value.replace(/\\{count\\}/, count.toString()); } } return value.replace(/\\{count\\}/, count.toString()); } // 格式化相對時間 formatRelativeTime(date: Date): string { const now = new Date(); const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000); if (diffInSeconds \u0026lt; 60) { return this.translate(\u0026#39;common.time.just_now\u0026#39;); } else if (diffInSeconds \u0026lt; 3600) { const minutes = Math.floor(diffInSeconds / 60); return this.translate(\u0026#39;common.time.minutes_ago\u0026#39;, { interpolation: { count: minutes.toString() } }); } else if (diffInSeconds \u0026lt; 86400) { const hours = Math.floor(diffInSeconds / 3600); return this.translate(\u0026#39;common.time.hours_ago\u0026#39;, { interpolation: { count: hours.toString() } }); } else if (diffInSeconds \u0026lt; 604800) { const days = Math.floor(diffInSeconds / 86400); return this.translate(\u0026#39;common.time.days_ago\u0026#39;, { interpolation: { count: days.toString() } }); } else if (diffInSeconds \u0026lt; 2419200) { const weeks = Math.floor(diffInSeconds / 604800); return this.translate(\u0026#39;common.time.weeks_ago\u0026#39;, { interpolation: { count: weeks.toString() } }); } else if (diffInSeconds \u0026lt; 29030400) { const months = Math.floor(diffInSeconds / 2419200); return this.translate(\u0026#39;common.time.months_ago\u0026#39;, { interpolation: { count: months.toString() } }); } else { const years = Math.floor(diffInSeconds / 29030400); return this.translate(\u0026#39;common.time.years_ago\u0026#39;, { interpolation: { count: years.toString() } }); } } } // 全域 i18n 實例 export const i18nManager = new I18nManager(); // Vue 組合函數 export function useI18n() { const t = (key: string, options?: any) =\u0026gt; i18nManager.translate(key, options); const setLocale = (locale: string) =\u0026gt; i18nManager.setLocale(locale); const formatRelativeTime = (date: Date) =\u0026gt; i18nManager.formatRelativeTime(date); return { t, setLocale, formatRelativeTime }; } 無障礙設計和多語系支援擴充完成，接下來我將繼續撰寫第三部分：UI 元件規範。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/uiux%E6%8C%87%E5%BC%95/","summary":"UI/UX 開發指引 目錄 文件概述 設計原則 1.1 銀行系統的安全性與一致性要求 1.2 清晰的資訊層次與導航設計 1.3 金融資料顯示與重點突顯規範 1.4 無障礙設計（WCAG 2.1 AA 級） 1.5 多語系支援 UI 元件規範 2.1 樣式系統 (Design System) 2.2 響應式設計規範 2.3 常用元件設計 UX 流程規範 3.1 表單驗證與錯誤回饋 3.2 使用者引導 (Onboarding) 3.3 搜尋、篩選與排序互動設計 3.4 資料載入與狀態設計 設計資產與交付 4.1 設計 Token 系統 4.2 元件庫架構 Vue 3 + Tailwind CSS 最佳實踐 5.1 元件命名與結構規範 5.2 Tailwind CSS 自定義配置 檢測與驗證 6.1 視覺回歸測試 6.2 無障礙檢測 6.3 使用性測試清單 性能優化指引 設計協作流程 維護與版本控制 附錄 文件概述 本指引適用於大型金融共用平台的前端 UI/UX 開發，涵蓋設計原則、UI 元件規範、UX 流程、設計資產交付等完整內容。\n專案技術堆疊 前端架構: 微前端 + SPA (Single-Page App\u0026mdash; 第一部分完成，接下來我將繼續撰寫第二部分：無障礙設計和多語系支援。\n1.4 無障礙設計（WCAG 2.1 AA 級） 色彩對比度要求 正常文字: 對比度至少 4.5:1 大文字 (18pt 以上): 對比度至少 3:1 互動元件: 對比度至少 3:1 /* Tailwind CSS 無障礙色彩配置 */ .text-primary { @apply text-gray-900; /* 對比度 21:1 */ } .text-secondary { @apply text-gray-700; /* 對比度 9.2:1 */ } .bg-interactive { @apply bg-blue-600 hover:bg-blue-700 focus:bg-blue-700; } .bg-interactive:focus { @apply ring-2 ring-blue-500 ring-offset-2; } 鍵盤操作支援 Tab 順序: 邏輯性的焦點移動順序 快捷鍵: 主要功能提供鍵盤快捷鍵 焦點指示: 清晰的焦點視覺回饋 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙表單範例 --\u0026gt; \u0026lt;form @submit.prevent=\u0026#34;handleSubmit\u0026#34; class=\u0026#34;space-y-6\u0026#34;\u0026gt; \u0026lt;div\u0026gt; \u0026lt;label for=\u0026#34;account-number\u0026#34; class=\u0026#34;block text-sm font-medium text-gray-700\u0026#34;\u0026gt; 帳戶號碼 \u0026lt;span class=\u0026#34;text-red-500\u0026#34; aria-label=\u0026#34;必填欄位\u0026#34;\u0026gt;*\u0026lt;/span\u0026gt; \u0026lt;/label\u0026gt; \u0026lt;input id=\u0026#34;account-number\u0026#34; v-model=\u0026#34;accountNumber\u0026#34; type=\u0026#34;text\u0026#34; required aria-describedby=\u0026#34;account-help account-error\u0026#34; class=\u0026#34;mt-1 block w-full rounded-md border-gray-300 shadow-sm focus:border-blue-500 focus:ring-blue-500\u0026#34; :aria-invalid=\u0026#34;hasError\u0026#34; /\u0026gt; \u0026lt;p id=\u0026#34;account-help\u0026#34; class=\u0026#34;mt-2 text-sm text-gray-500\u0026#34;\u0026gt; 請輸入 12 位數字帳戶號碼 \u0026lt;/p\u0026gt; \u0026lt;p id=\u0026#34;account-error\u0026#34; v-if=\u0026#34;errorMessage\u0026#34; class=\u0026#34;mt-2 text-sm text-red-600\u0026#34; role=\u0026#34;alert\u0026#34;\u0026gt; {{ errorMessage }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/form\u0026gt; \u0026lt;/template\u0026gt; 螢幕閱讀器支援 語義化 HTML: 使用適當的 HTML 語義標籤 ARIA 標籤: 補充無障礙資訊 替代文字: 圖片提供有意義的 alt 文字 \u0026lt;template\u0026gt; \u0026lt;!-- 無障礙數據表格 --\u0026gt; \u0026lt;table role=\u0026#34;table\u0026#34; aria-label=\u0026#34;帳戶交易記錄\u0026#34;\u0026gt; \u0026lt;caption class=\u0026#34;sr-only\u0026#34;\u0026gt; 最近 10 筆交易記錄，包含日期、摘要、金額和餘額 \u0026lt;/caption\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 交易日期 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 摘要 \u0026lt;/th\u0026gt; \u0026lt;th scope=\u0026#34;col\u0026#34; class=\u0026#34;px-6 py-3 text-right text-xs font-medium text-gray-500 uppercase tracking-wider\u0026#34;\u0026gt; 金額 \u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr v-for=\u0026#34;transaction in transactions\u0026#34; :key=\u0026#34;transaction.id\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ formatDate(transaction.date) }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-gray-900\u0026#34;\u0026gt; {{ transaction.description }} \u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;px-6 py-4 whitespace-nowrap text-sm text-right\u0026#34;\u0026gt; \u0026lt;span :class=\u0026#34;transaction.amount \u0026gt;= 0 ? \u0026#39;text-green-600\u0026#39; : \u0026#39;text-red-600\u0026#39;\u0026#34;\u0026gt; {{ formatCurrency(transaction.amount) }} \u0026lt;/span\u0026gt; \u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; \u0026lt;/template\u0026gt; 1.5 多語系支援 語言切換機制 // i18n 配置 import { createI18n } from \u0026#39;vue-i18n\u0026#39;; interface Messages { \u0026#39;zh-TW\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;en-US\u0026#39;: Record\u0026lt;string, any\u0026gt;; \u0026#39;ja-JP\u0026#39;: Record\u0026lt;string, any\u0026gt;; } const messages: Messages = { \u0026#39;zh-TW\u0026#39;: { common: { confirm: \u0026#39;確認\u0026#39;, cancel: \u0026#39;取消\u0026#39;, save: \u0026#39;儲存\u0026#39;, delete: \u0026#39;刪除\u0026#39;, loading: \u0026#39;載入中...\u0026#39; }, account: { balance: \u0026#39;帳戶餘額\u0026#39;, transfer: \u0026#39;轉帳\u0026#39;, history: \u0026#39;交易記錄\u0026#39; } }, \u0026#39;en-US\u0026#39;: { common: { confirm: \u0026#39;Confirm\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, save: \u0026#39;Save\u0026#39;, delete: \u0026#39;Delete\u0026#39;, loading: \u0026#39;Loading...\u0026#39; }, account: { balance: \u0026#39;Account Balance\u0026#39;, transfer: \u0026#39;Transfer\u0026#39;, history: \u0026#39;Transaction History\u0026#39; } } }; export const i18n = createI18n({ locale: \u0026#39;zh-TW\u0026#39;, fallbackLocale: \u0026#39;en-US\u0026#39;, messages }); 文字方向支援 (RTL/LTR) \u0026lt;template\u0026gt; \u0026lt;div :dir=\u0026#34;currentLocale.dir\u0026#34; class=\u0026#34;app-container\u0026#34;\u0026gt; \u0026lt;!-- 語言切換器 --\u0026gt; \u0026lt;div class=\u0026#34;language-selector\u0026#34;\u0026gt; \u0026lt;select v-model=\u0026#34;currentLanguage\u0026#34; @change=\u0026#34;changeLanguage\u0026#34; class=\u0026#34;block w-32 rounded-md border-gray-300\u0026#34; :aria-label=\u0026#34;$t(\u0026#39;common.selectLanguage\u0026#39;)\u0026#34; \u0026gt; \u0026lt;option value=\u0026#34;zh-TW\u0026#34;\u0026gt;繁體中文\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;en-US\u0026#34;\u0026gt;English\u0026lt;/option\u0026gt; \u0026lt;option value=\u0026#34;ar-SA\u0026#34;\u0026gt;العربية\u0026lt;/option\u0026gt; \u0026lt;/select\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed } from \u0026#39;vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; const { locale, t } = useI18n(); const localeConfig = { \u0026#39;zh-TW\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;繁體中文\u0026#39; }, \u0026#39;en-US\u0026#39;: { dir: \u0026#39;ltr\u0026#39;, name: \u0026#39;English\u0026#39; }, \u0026#39;ar-SA\u0026#39;: { dir: \u0026#39;rtl\u0026#39;, name: \u0026#39;العربية\u0026#39; } }; const currentLocale = computed(() =\u0026gt; localeConfig[locale.value]); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* RTL 支援樣式 */ [dir=\u0026#34;rtl\u0026#34;] .text-left { text-align: right; } [dir=\u0026#34;rtl\u0026#34;] .text-right { text-align: left; } [dir=\u0026#34;rtl\u0026#34;] .ml-4 { margin-left: 0; margin-right: 1rem; } \u0026lt;/style\u0026gt; 數字與日期本地化 // 本地化格式化工具 export class LocaleFormatter { private locale: string; constructor(locale: string) { this.locale = locale; } // 金額格式化 formatCurrency(amount: number, currency: string = \u0026#39;TWD\u0026#39;): string { const currencyMap = { \u0026#39;zh-TW\u0026#39;: \u0026#39;TWD\u0026#39;, \u0026#39;en-US\u0026#39;: \u0026#39;USD\u0026#39;, \u0026#39;ja-JP\u0026#39;: \u0026#39;JPY\u0026#39;, \u0026#39;ko-KR\u0026#39;: \u0026#39;KRW\u0026#39; }; return new Intl.NumberFormat(this.locale, { style: \u0026#39;currency\u0026#39;, currency: currencyMap[this.locale] || currency, minimumFractionDigits: currency === \u0026#39;JPY\u0026#39; ? 0 : 2 }).format(amount); } // 日期格式化 formatDate(date: Date, options?: Intl.DateTimeFormatOptions): string { const defaultOptions: Intl.DateTimeFormatOptions = { year: \u0026#39;numeric\u0026#39;, month: \u0026#39;short\u0026#39;, day: \u0026#39;numeric\u0026#39; }; return new Intl.DateTimeFormat(this.locale, options || defaultOptions).format(date); } // 時間格式化 formatTime(date: Date): string { return new Intl.DateTimeFormat(this.locale, { hour: \u0026#39;2-digit\u0026#39;, minute: \u0026#39;2-digit\u0026#39;, hour12: this.locale === \u0026#39;en-US\u0026#39; }).format(date); } // 百分比格式化 formatPercentage(value: number): string { return new Intl.NumberFormat(this.locale, { style: \u0026#39;percent\u0026#39;, minimumFractionDigits: 2, maximumFractionDigits: 2 }).format(value); } } 進階無障礙設計實作 \u0026lt;template\u0026gt; \u0026lt;!-- 高對比模式切換 --\u0026gt; \u0026lt;div class=\u0026#34;accessibility-controls fixed top-4 right-4 z-50\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleHighContrast\u0026#34; :aria-pressed=\u0026#34;isHighContrast\u0026#34; class=\u0026#34;p-2 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; :class=\u0026#34;isHighContrast ? \u0026#39;bg-yellow-400 text-black\u0026#39; : \u0026#39;bg-white text-gray-700 shadow-md\u0026#39;\u0026#34; aria-label=\u0026#34;切換高對比模式\u0026#34; \u0026gt; \u0026lt;EyeIcon class=\u0026#34;h-5 w-5\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;!-- 字體大小調整 --\u0026gt; \u0026lt;div class=\u0026#34;mt-2 flex flex-col space-y-1\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;increaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;增大字體\u0026#34; \u0026gt; A\u0026#43; \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;decreaseFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;縮小字體\u0026#34; \u0026gt; A- \u0026lt;/button\u0026gt; \u0026lt;button @click=\u0026#34;resetFontSize\u0026#34; class=\u0026#34;p-1 text-xs bg-white rounded shadow-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; aria-label=\u0026#34;重設字體大小\u0026#34; \u0026gt; A \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 跳至主要內容連結 --\u0026gt; \u0026lt;a href=\u0026#34;#main-content\u0026#34; class=\u0026#34;sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 bg-blue-600 text-white px-4 py-2 rounded-md z-50\u0026#34; \u0026gt; 跳至主要內容 \u0026lt;/a\u0026gt; \u0026lt;!-- 焦點陷阱對話框範例 --\u0026gt; \u0026lt;div v-if=\u0026#34;showModal\u0026#34; class=\u0026#34;fixed inset-0 z-10 overflow-y-auto\u0026#34; role=\u0026#34;dialog\u0026#34; aria-modal=\u0026#34;true\u0026#34; :aria-labelledby=\u0026#34;modalTitleId\u0026#34; @keydown.esc=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;flex items-end justify-center min-h-screen pt-4 px-4 pb-20 text-center sm:block sm:p-0\u0026#34;\u0026gt; \u0026lt;!-- 背景遮罩 --\u0026gt; \u0026lt;div class=\u0026#34;fixed inset-0 transition-opacity\u0026#34; aria-hidden=\u0026#34;true\u0026#34; @click=\u0026#34;closeModal\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;absolute inset-0 bg-gray-500 opacity-75\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 對話框內容 --\u0026gt; \u0026lt;div ref=\u0026#34;modalContent\u0026#34; class=\u0026#34;inline-block align-bottom bg-white rounded-lg text-left overflow-hidden shadow-xl transform transition-all sm:my-8 sm:align-middle sm:max-w-lg sm:w-full\u0026#34; @keydown=\u0026#34;handleModalKeydown\u0026#34; \u0026gt; \u0026lt;div class=\u0026#34;bg-white px-4 pt-5 pb-4 sm:p-6 sm:pb-4\u0026#34;\u0026gt; \u0026lt;h3 :id=\u0026#34;modalTitleId\u0026#34; class=\u0026#34;text-lg leading-6 font-medium text-gray-900 mb-4\u0026#34;\u0026gt; 確認操作 \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm text-gray-500 mb-4\u0026#34;\u0026gt; 您確定要執行此操作嗎？此動作無法復原。 \u0026lt;/p\u0026gt; \u0026lt;!-- 焦點陷阱內的可互動元素 --\u0026gt; \u0026lt;div class=\u0026#34;flex justify-end space-x-3\u0026#34;\u0026gt; \u0026lt;button ref=\u0026#34;cancelButton\u0026#34; @click=\u0026#34;closeModal\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-gray-700 bg-white border border-gray-300 rounded-md hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-blue-500\u0026#34; \u0026gt; 取消 \u0026lt;/button\u0026gt; \u0026lt;button ref=\u0026#34;confirmButton\u0026#34; @click=\u0026#34;handleConfirm\u0026#34; class=\u0026#34;px-4 py-2 text-sm font-medium text-white bg-red-600 border border-transparent rounded-md hover:bg-red-700 focus:outline-none focus:ring-2 focus:ring-red-500\u0026#34; \u0026gt; 確認 \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { ref, nextTick, onMounted, onUnmounted } from \u0026#39;vue\u0026#39;; import { EyeIcon } from \u0026#39;@heroicons/vue/24/outline\u0026#39;; // 無障礙狀態管理 const isHighContrast = ref(false); const fontSize = ref(16); const showModal = ref(false); const modalTitleId = ref(`modal-title-${Math.random().toString(36).substr(2, 9)}`); // 高對比模式 const toggleHighContrast = () =\u0026gt; { isHighContrast.value = !isHighContrast.value; document.documentElement.classList.toggle(\u0026#39;high-contrast\u0026#39;, isHighContrast.value); // 儲存使用者偏好 localStorage.setItem(\u0026#39;high-contrast\u0026#39;, isHighContrast.value.toString()); // 通知螢幕閱讀器 announceToScreenReader( isHighContrast.value ? \u0026#39;已開啟高對比模式\u0026#39; : \u0026#39;已關閉高對比模式\u0026#39; ); }; // 字體大小調整 const increaseFontSize = () =\u0026gt; { if (fontSize.value \u0026lt; 24) { fontSize.value \u0026#43;= 2; updateFontSize(); } }; const decreaseFontSize = () =\u0026gt; { if (fontSize.value \u0026gt; 12) { fontSize.value -= 2; updateFontSize(); } }; const resetFontSize = () =\u0026gt; { fontSize.value = 16; updateFontSize(); }; const updateFontSize = () =\u0026gt; { document.documentElement.style.fontSize = `${fontSize.value}px`; localStorage.setItem(\u0026#39;font-size\u0026#39;, fontSize.value.toString()); announceToScreenReader(`字體大小已調整為 ${fontSize.value} 像素`); }; // 螢幕閱讀器公告 const announceToScreenReader = (message: string) =\u0026gt; { const announcement = document.createElement(\u0026#39;div\u0026#39;); announcement.setAttribute(\u0026#39;aria-live\u0026#39;, \u0026#39;polite\u0026#39;); announcement.setAttribute(\u0026#39;aria-atomic\u0026#39;, \u0026#39;true\u0026#39;); announcement.className = \u0026#39;sr-only\u0026#39;; announcement.textContent = message; document.body.appendChild(announcement); setTimeout(() =\u0026gt; { document.body.removeChild(announcement); }, 1000); }; // 焦點陷阱管理 const modalContent = ref\u0026lt;HTMLElement\u0026gt;(); const cancelButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const confirmButton = ref\u0026lt;HTMLButtonElement\u0026gt;(); const focusableElements: HTMLElement[] = []; let previousFocusedElement: HTMLElement | null = null; const openModal = async () =\u0026gt; { previousFocusedElement = document.activeElement as HTMLElement; showModal.value = true; await nextTick(); // 收集可聚焦元素 const selector = \u0026#39;button, [href], input, select, textarea, [tabindex]:not([tabindex=\u0026#34;-1\u0026#34;])\u0026#39;; focusableElements.splice(0); focusableElements.push( ...Array.from(modalContent.value?.querySelectorAll(selector) || []) ); // 聚焦第一個元素 if (focusableElements.length \u0026gt; 0) { focusableElements[0].focus(); } }; const closeModal = () =\u0026gt; { showModal.value = false; // 恢復之前的焦點 if (previousFocusedElement) { previousFocusedElement.focus(); } }; const handleModalKeydown = (event: KeyboardEvent) =\u0026gt; { if (event.key === \u0026#39;Tab\u0026#39;) { const currentIndex = focusableElements.indexOf(event.target as HTMLElement); if (event.shiftKey) { // Shift \u0026#43; Tab (向後) if (currentIndex \u0026lt;= 0) { event.preventDefault(); focusableElements[focusableElements.length - 1].focus(); } } else { // Tab (向前) if (currentIndex \u0026gt;= focusableElements.length - 1) { event.preventDefault(); focusableElements[0].focus(); } } } }; const handleConfirm = () =\u0026gt; { // 處理確認邏輯 announceToScreenReader(\u0026#39;操作已確認\u0026#39;); closeModal(); }; // 鍵盤快捷鍵 const handleGlobalKeydown = (event: KeyboardEvent) =\u0026gt; { // Alt \u0026#43; H: 開啟高對比模式 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;h\u0026#39;) { event.preventDefault(); toggleHighContrast(); } // Alt \u0026#43; \u0026#43;: 增大字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;\u0026#43;\u0026#39;) { event.preventDefault(); increaseFontSize(); } // Alt \u0026#43; -: 縮小字體 if (event.altKey \u0026amp;\u0026amp; event.key === \u0026#39;-\u0026#39;) { event.preventDefault(); decreaseFontSize(); } }; // 初始化無障礙設定 onMounted(() =\u0026gt; { // 載入儲存的偏好設定 const savedHighContrast = localStorage.getItem(\u0026#39;high-contrast\u0026#39;); if (savedHighContrast === \u0026#39;true\u0026#39;) { isHighContrast.value = true; document.documentElement.classList.add(\u0026#39;high-contrast\u0026#39;); } const savedFontSize = localStorage.getItem(\u0026#39;font-size\u0026#39;); if (savedFontSize) { fontSize.value = parseInt(savedFontSize); document.documentElement.style.fontSize = `${fontSize.value}px`; } // 監聽全域鍵盤事件 document.addEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); // 檢測用戶偏好的配色方案 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-color-scheme: dark)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;dark-mode\u0026#39;); } // 檢測用戶偏好的動畫設定 if (window.matchMedia \u0026amp;\u0026amp; window.matchMedia(\u0026#39;(prefers-reduced-motion: reduce)\u0026#39;).matches) { document.documentElement.classList.add(\u0026#39;reduce-motion\u0026#39;); } }); onUnmounted(() =\u0026gt; { document.removeEventListener(\u0026#39;keydown\u0026#39;, handleGlobalKeydown); }); \u0026lt;/script\u0026gt; \u0026lt;style\u0026gt; /* 高對比模式樣式 */ .high-contrast { filter: contrast(150%) saturate(200%); } .high-contrast button { border: 2px solid currentColor !important; } .high-contrast a { text-decoration: underline !important; } /* 減少動畫模式 */ .reduce-motion *, .reduce-motion *::before, .reduce-motion *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } /* 深色模式支援 */ .dark-mode { color-scheme: dark; } /* 螢幕閱讀器專用隱藏 */ .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .sr-only.focus:focus { position: static; width: auto; height: auto; padding: inherit; margin: inherit; overflow: visible; clip: auto; white-space: normal; } \u0026lt;/style\u0026gt; 多語系內容管理策略 // 多語系內容管理 interface TranslationKey { key: string; context?: string; pluralization?: boolean; interpolation?: string[]; } interface TranslationContent { [locale: string]: { [namespace: string]: { [key: string]: string | object; }; }; } // 翻譯內容結構化管理 export const translationStructure: TranslationContent = { \u0026#39;zh-TW\u0026#39;: { common: { // 通用操作 actions: { save: \u0026#39;儲存\u0026#39;, cancel: \u0026#39;取消\u0026#39;, confirm: \u0026#39;確認\u0026#39;, delete: \u0026#39;刪除\u0026#39;, edit: \u0026#39;編輯\u0026#39;, add: \u0026#39;新增\u0026#39;, search: \u0026#39;搜尋\u0026#39;, filter: \u0026#39;篩選\u0026#39;, sort: \u0026#39;排序\u0026#39;, refresh: \u0026#39;重新整理\u0026#39;, loading: \u0026#39;載入中...\u0026#39;, noData: \u0026#39;無資料\u0026#39;, error: \u0026#39;發生錯誤\u0026#39; }, // 表單相關 form: { required: \u0026#39;此欄位為必填\u0026#39;, invalid: \u0026#39;格式不正確\u0026#39;, tooShort: \u0026#39;長度不足\u0026#39;, tooLong: \u0026#39;長度過長\u0026#39;, emailInvalid: \u0026#39;請輸入有效的電子郵件地址\u0026#39;, phoneInvalid: \u0026#39;請輸入有效的手機號碼\u0026#39;, passwordMismatch: \u0026#39;密碼不一致\u0026#39; }, // 時間相關 time: { just_now: \u0026#39;剛剛\u0026#39;, minutes_ago: \u0026#39;{count} 分鐘前\u0026#39;, hours_ago: \u0026#39;{count} 小時前\u0026#39;, days_ago: \u0026#39;{count} 天前\u0026#39;, weeks_ago: \u0026#39;{count} 週前\u0026#39;, months_ago: \u0026#39;{count} 個月前\u0026#39;, years_ago: \u0026#39;{count} 年前\u0026#39; } }, // 金融業務相關 banking: { account: { balance: \u0026#39;帳戶餘額\u0026#39;, available: \u0026#39;可用餘額\u0026#39;, accountNumber: \u0026#39;帳戶號碼\u0026#39;, accountType: \u0026#39;帳戶類型\u0026#39;, status: \u0026#39;狀態\u0026#39;, openDate: \u0026#39;開戶日期\u0026#39;, lastTransaction: \u0026#39;最近交易\u0026#39; }, transaction: { transfer: \u0026#39;轉帳\u0026#39;, deposit: \u0026#39;存款\u0026#39;, withdrawal: \u0026#39;提款\u0026#39;, payment: \u0026#39;付款\u0026#39;, refund: \u0026#39;退款\u0026#39;, fee: \u0026#39;手續費\u0026#39;, amount: \u0026#39;金額\u0026#39;, recipient: \u0026#39;收款人\u0026#39;, description: \u0026#39;摘要\u0026#39;, reference: \u0026#39;參考號碼\u0026#39;, date: \u0026#39;交易日期\u0026#39;, status: \u0026#39;交易狀態\u0026#39; }, status: { active: \u0026#39;啟用\u0026#39;, inactive: \u0026#39;停用\u0026#39;, pending: \u0026#39;處理中\u0026#39;, completed: \u0026#39;已完成\u0026#39;, failed: \u0026#39;失敗\u0026#39;, cancelled: \u0026#39;已取消\u0026#39;, expired: \u0026#39;已過期\u0026#39; } } }, \u0026#39;en-US\u0026#39;: { common: { actions: { save: \u0026#39;Save\u0026#39;, cancel: \u0026#39;Cancel\u0026#39;, confirm: \u0026#39;Confirm\u0026#39;, delete: \u0026#39;Delete\u0026#39;, edit: \u0026#39;Edit\u0026#39;, add: \u0026#39;Add\u0026#39;, search: \u0026#39;Search\u0026#39;, filter: \u0026#39;Filter\u0026#39;, sort: \u0026#39;Sort\u0026#39;, refresh: \u0026#39;Refresh\u0026#39;, loading: \u0026#39;Loading...\u0026#39;, noData: \u0026#39;No Data\u0026#39;, error: \u0026#39;Error Occurred\u0026#39; }, form: { required: \u0026#39;This field is required\u0026#39;, invalid: \u0026#39;Invalid format\u0026#39;, tooShort: \u0026#39;Too short\u0026#39;, tooLong: \u0026#39;Too long\u0026#39;, emailInvalid: \u0026#39;Please enter a valid email address\u0026#39;, phoneInvalid: \u0026#39;Please enter a valid phone number\u0026#39;, passwordMismatch: \u0026#39;Passwords do not match\u0026#39; }, time: { just_now: \u0026#39;Just now\u0026#39;, minutes_ago: \u0026#39;{count} minutes ago\u0026#39;, hours_ago: \u0026#39;{count} hours ago\u0026#39;, days_ago: \u0026#39;{count} days ago\u0026#39;, weeks_ago: \u0026#39;{count} weeks ago\u0026#39;, months_ago: \u0026#39;{count} months ago\u0026#39;, years_ago: \u0026#39;{count} years ago\u0026#39; } }, banking: { account: { balance: \u0026#39;Account Balance\u0026#39;, available: \u0026#39;Available Balance\u0026#39;, accountNumber: \u0026#39;Account Number\u0026#39;, accountType: \u0026#39;Account Type\u0026#39;, status: \u0026#39;Status\u0026#39;, openDate: \u0026#39;Open Date\u0026#39;, lastTransaction: \u0026#39;Last Transaction\u0026#39; }, transaction: { transfer: \u0026#39;Transfer\u0026#39;, deposit: \u0026#39;Deposit\u0026#39;, withdrawal: \u0026#39;Withdrawal\u0026#39;, payment: \u0026#39;Payment\u0026#39;, refund: \u0026#39;Refund\u0026#39;, fee: \u0026#39;Fee\u0026#39;, amount: \u0026#39;Amount\u0026#39;, recipient: \u0026#39;Recipient\u0026#39;, description: \u0026#39;Description\u0026#39;, reference: \u0026#39;Reference Number\u0026#39;, date: \u0026#39;Transaction Date\u0026#39;, status: \u0026#39;Transaction Status\u0026#39; }, status: { active: \u0026#39;Active\u0026#39;, inactive: \u0026#39;Inactive\u0026#39;, pending: \u0026#39;Pending\u0026#39;, completed: \u0026#39;Completed\u0026#39;, failed: \u0026#39;Failed\u0026#39;, cancelled: \u0026#39;Cancelled\u0026#39;, expired: \u0026#39;Expired\u0026#39; } } } }; // 進階翻譯函數 export class I18nManager { private currentLocale: string = \u0026#39;zh-TW\u0026#39;; private fallbackLocale: string = \u0026#39;en-US\u0026#39;; // 設定當前語言 setLocale(locale: string) { this.currentLocale = locale; document.documentElement.setAttribute(\u0026#39;lang\u0026#39;, locale); // 更新頁面方向 const direction = this.getTextDirection(locale); document.documentElement.setAttribute(\u0026#39;dir\u0026#39;, direction); // 觸發語言變更事件 window.dispatchEvent(new CustomEvent(\u0026#39;localeChanged\u0026#39;, { detail: { locale, direction } })); } // 取得文字方向 private getTextDirection(locale: string): \u0026#39;ltr\u0026#39; | \u0026#39;rtl\u0026#39; { const rtlLocales = [\u0026#39;ar\u0026#39;, \u0026#39;he\u0026#39;, \u0026#39;fa\u0026#39;, \u0026#39;ur\u0026#39;]; return rtlLocales.some(rtl =\u0026gt; locale.startsWith(rtl)) ? \u0026#39;rtl\u0026#39; : \u0026#39;ltr\u0026#39;; } // 翻譯函數 translate(key: string, options?: { interpolation?: Record\u0026lt;string, any\u0026gt;; count?: number; defaultValue?: string; }): string { const keys = key.split(\u0026#39;.\u0026#39;); let value = this.getNestedValue(translationStructure[this.currentLocale], keys); // 如果找不到翻譯，嘗試備用語言 if (!value) { value = this.getNestedValue(translationStructure[this.fallbackLocale], keys); } // 如果還是找不到，返回預設值或 key if (!value) { return options?.defaultValue || key; } // 處理插值 if (options?.interpolation) { Object.entries(options.interpolation).forEach(([placeholder, replacement]) =\u0026gt; { value = value.replace(new RegExp(`{${placeholder}}`, \u0026#39;g\u0026#39;), replacement); }); } // 處理複數形式 if (options?.count !== undefined) { value = this.handlePluralization(value, options.count); } return value; } // 取得巢狀物件值 private getNestedValue(obj: any, keys: string[]): string | null { return keys.reduce((current, key) =\u0026gt; current?.[key], obj) || null; } // 處理複數形式 private handlePluralization(value: string, count: number): string { // 簡化的複數處理，實際應用中可能需要更複雜的邏輯 if (this.currentLocale === \u0026#39;en-US\u0026#39;) { if (count === 1) { return value.replace(/\\{count\\}/, count.toString()); } else { // 處理英文複數規則 return value.replace(/\\{count\\}/, count.toString()); } } return value.replace(/\\{count\\}/, count.toString()); } // 格式化相對時間 formatRelativeTime(date: Date): string { const now = new Date(); const diffInSeconds = Math.floor((now.getTime() - date.getTime()) / 1000); if (diffInSeconds \u0026lt; 60) { return this.translate(\u0026#39;common.time.just_now\u0026#39;); } else if (diffInSeconds \u0026lt; 3600) { const minutes = Math.floor(diffInSeconds / 60); return this.translate(\u0026#39;common.time.minutes_ago\u0026#39;, { interpolation: { count: minutes.toString() } }); } else if (diffInSeconds \u0026lt; 86400) { const hours = Math.floor(diffInSeconds / 3600); return this.translate(\u0026#39;common.time.hours_ago\u0026#39;, { interpolation: { count: hours.toString() } }); } else if (diffInSeconds \u0026lt; 604800) { const days = Math.floor(diffInSeconds / 86400); return this.translate(\u0026#39;common.time.days_ago\u0026#39;, { interpolation: { count: days.toString() } }); } else if (diffInSeconds \u0026lt; 2419200) { const weeks = Math.floor(diffInSeconds / 604800); return this.translate(\u0026#39;common.time.weeks_ago\u0026#39;, { interpolation: { count: weeks.toString() } }); } else if (diffInSeconds \u0026lt; 29030400) { const months = Math.floor(diffInSeconds / 2419200); return this.translate(\u0026#39;common.time.months_ago\u0026#39;, { interpolation: { count: months.toString() } }); } else { const years = Math.floor(diffInSeconds / 29030400); return this.translate(\u0026#39;common.time.years_ago\u0026#39;, { interpolation: { count: years.toString() } }); } } } // 全域 i18n 實例 export const i18nManager = new I18nManager(); // Vue 組合函數 export function useI18n() { const t = (key: string, options?: any) =\u0026gt; i18nManager.translate(key, options); const setLocale = (locale: string) =\u0026gt; i18nManager.setLocale(locale); const formatRelativeTime = (date: Date) =\u0026gt; i18nManager.formatRelativeTime(date); return { t, setLocale, formatRelativeTime }; } 無障礙設計和多語系支援擴充完成，接下來我將繼續撰寫第三部分：UI 元件規範。\n","title":""},{"content":"前端開發指引 文件資訊 版本: 1.0.0 建立日期: 2025-08-11 適用專案: 大型金融級 Web 專案 技術棧: Vue 3.x + TypeScript + Tailwind CSS 目錄 專案目錄與檔案結構規範 命名規範 程式撰寫風格與 Lint 設定 元件開發規範 樣式與 Tailwind CSS 規範 API 串接與資料存取規範 狀態管理規範 多語系處理規範 測試規範 安全性考量 效能優化規範 無障礙設計規範 版本控制與分支策略 專案建置與部署流程 程式碼審查規範 常見錯誤處理與 Debug 流程 開發工具與環境設定 團隊協作與溝通規範 1. 專案目錄與檔案結構規範 1.1 標準專案結構 frontend-project/ ├── public/ # 靜態資源 │ ├── favicon.ico │ ├── index.html │ └── manifest.json ├── src/ # 原始碼 │ ├── api/ # API 相關 │ │ ├── modules/ # 依功能模組分類 │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ ├── interceptors/ # 攔截器 │ │ └── types/ # API 型別定義 │ ├── assets/ # 靜態資源 │ │ ├── images/ │ │ ├── icons/ │ │ └── fonts/ │ ├── components/ # 共用元件 │ │ ├── base/ # 基礎元件 │ │ │ ├── BaseButton.vue │ │ │ ├── BaseInput.vue │ │ │ └── BaseModal.vue │ │ ├── business/ # 業務元件 │ │ └── layout/ # 版面元件 │ │ ├── Header.vue │ │ ├── Sidebar.vue │ │ └── Footer.vue │ ├── composables/ # Vue 3 Composition API │ │ ├── useAuth.ts │ │ ├── useApi.ts │ │ └── useLocalStorage.ts │ ├── constants/ # 常數定義 │ │ ├── api.ts │ │ ├── routes.ts │ │ └── config.ts │ ├── directives/ # 自定義指令 │ ├── i18n/ # 多語系 │ │ ├── locales/ │ │ │ ├── zh-TW.json │ │ │ ├── en-US.json │ │ │ └── ja-JP.json │ │ └── index.ts │ ├── layouts/ # 版面配置 │ │ ├── DefaultLayout.vue │ │ ├── AuthLayout.vue │ │ └── EmptyLayout.vue │ ├── middleware/ # 中間件 │ │ ├── auth.ts │ │ └── permission.ts │ ├── pages/ # 頁面元件 │ │ ├── auth/ │ │ │ ├── Login.vue │ │ │ └── Register.vue │ │ ├── dashboard/ │ │ └── user/ │ ├── plugins/ # 插件 │ │ ├── axios.ts │ │ ├── i18n.ts │ │ └── router.ts │ ├── router/ # 路由設定 │ │ ├── modules/ # 路由模組 │ │ │ ├── auth.ts │ │ │ └── dashboard.ts │ │ └── index.ts │ ├── stores/ # Pinia 狀態管理 │ │ ├── modules/ │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ └── index.ts │ ├── styles/ # 樣式檔案 │ │ ├── globals.css │ │ ├── variables.css │ │ └── components/ │ ├── types/ # TypeScript 型別定義 │ │ ├── api.ts │ │ ├── auth.ts │ │ └── global.ts │ ├── utils/ # 工具函式 │ │ ├── format.ts │ │ ├── validation.ts │ │ └── storage.ts │ ├── App.vue # 根元件 │ └── main.ts # 應用程式進入點 ├── tests/ # 測試檔案 │ ├── unit/ # 單元測試 │ ├── e2e/ # E2E 測試 │ └── __mocks__/ # Mock 檔案 ├── .env # 環境變數 ├── .env.development ├── .env.production ├── .eslintrc.js # ESLint 設定 ├── .prettierrc # Prettier 設定 ├── tailwind.config.js # Tailwind CSS 設定 ├── vite.config.ts # Vite 設定 ├── tsconfig.json # TypeScript 設定 └── package.json # 套件管理 1.2 檔案命名原則 檔案類型對應命名方式 Vue 元件: PascalCase (如 UserProfile.vue) TypeScript 檔案: camelCase (如 userService.ts) CSS/SCSS 檔案: kebab-case (如 user-profile.scss) 測試檔案: 與被測檔案同名 + .test 或 .spec (如 UserProfile.test.ts) 型別定義檔案: camelCase + .d.ts (如 userTypes.d.ts) 特殊檔案命名 頁面元件: PascalCase，通常以頁面功能命名 (如 UserManagement.vue) Layout 元件: PascalCase + Layout 後綴 (如 DashboardLayout.vue) Store 檔案: camelCase，以業務領域命名 (如 userStore.ts) API 檔案: camelCase，以 API 服務命名 (如 userApi.ts) 2. 命名規範 2.1 檔案與資料夾命名 資料夾命名 使用 kebab-case (小寫字母 + 連字號) 名稱應簡潔且具描述性 ✅ 正確範例 user-management/ auth-service/ api-client/ ❌ 錯誤範例 UserManagement/ authService/ API_Client/ 檔案命名 Vue 元件檔案: PascalCase JavaScript/TypeScript 檔案: camelCase 樣式檔案: kebab-case 設定檔案: kebab-case 或 camelCase (依慣例) // ✅ 正確範例 UserProfile.vue userService.ts user-profile.scss vite.config.ts // ❌ 錯誤範例 userprofile.vue UserService.ts user_profile.scss vite_config.ts 2.2 變數與函式命名 JavaScript/TypeScript 變數 使用 camelCase 常數使用 UPPER_SNAKE_CASE 私有變數以 _ 開頭 布林值變數使用 is、has、can、should 等前綴 // ✅ 正確範例 const userName = \u0026#39;John Doe\u0026#39;; const API_BASE_URL = \u0026#39;https://api.example.com\u0026#39;; const _privateVariable = \u0026#39;private\u0026#39;; const isLoggedIn = true; const hasPermission = false; const canEdit = true; const shouldUpdate = false; // ❌ 錯誤範例 const user_name = \u0026#39;John Doe\u0026#39;; const apiBaseUrl = \u0026#39;https://api.example.com\u0026#39;; // 常數應使用大寫 const privateVariable = \u0026#39;private\u0026#39;; // 私有變數缺少前綴 const loggedIn = true; // 布林值缺少前綴 函式命名 使用 camelCase 動詞開頭，描述函式的動作 事件處理器使用 handle 前綴 取得資料使用 get、fetch 前綴 設定資料使用 set、update 前綴 // ✅ 正確範例 function getUserData() { } function handleButtonClick() { } function validateEmail() { } function formatCurrency() { } function updateUserProfile() { } function fetchUserList() { } // ❌ 錯誤範例 function userData() { } // 缺少動詞 function buttonClick() { } // 事件處理器缺少 handle 前綴 function email() { } // 不明確的命名 function currency() { } // 不明確的命名 2.3 Vue 元件命名 元件名稱 使用 PascalCase 多個單字組合，避免單一單字 基礎元件使用 Base 前綴 業務元件使用具體的業務領域命名 \u0026lt;!-- ✅ 正確範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: UserProfile.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: BaseButton.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: PaymentForm.vue \u0026lt;/script\u0026gt; \u0026lt;!-- ❌ 錯誤範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: user.vue - 命名太簡短 \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: button.vue - 應使用 BaseButton \u0026lt;/script\u0026gt; Props 命名 定義時使用 camelCase HTML 模板中使用 kebab-case \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 interface Props { userName: string; isVisible: boolean; maxLength?: number; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { maxLength: 100 }); \u0026lt;/script\u0026gt; \u0026lt;template\u0026gt; \u0026lt;!-- HTML 模板中使用 kebab-case --\u0026gt; \u0026lt;UserProfile :user-name=\u0026#34;currentUser\u0026#34; :is-visible=\u0026#34;showProfile\u0026#34; :max-length=\u0026#34;200\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; Event 命名 使用 kebab-case 動詞開頭，描述事件的動作 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 const emit = defineEmits\u0026lt;{ \u0026#39;update:modelValue\u0026#39;: [value: string]; \u0026#39;user-created\u0026#39;: [user: User]; \u0026#39;form-submitted\u0026#39;: [data: FormData]; \u0026#39;item-selected\u0026#39;: [item: Item]; }\u0026gt;(); // 觸發事件 emit(\u0026#39;user-created\u0026#39;, newUser); emit(\u0026#39;form-submitted\u0026#39;, formData); \u0026lt;/script\u0026gt; 3. 程式撰寫風格與 Lint 設定 3.1 ESLint 設定 eslint.config.js 範例 import { defineConfig } from \u0026#39;eslint-define-config\u0026#39;; import vue from \u0026#39;eslint-plugin-vue\u0026#39;; import typescript from \u0026#39;@typescript-eslint/eslint-plugin\u0026#39;; import typescriptParser from \u0026#39;@typescript-eslint/parser\u0026#39;; import prettier from \u0026#39;eslint-plugin-prettier\u0026#39;; export default defineConfig([ { files: [\u0026#39;**/*.{js,ts,vue}\u0026#39;], languageOptions: { parser: typescriptParser, parserOptions: { ecmaVersion: 2022, sourceType: \u0026#39;module\u0026#39;, extraFileExtensions: [\u0026#39;.vue\u0026#39;] } }, plugins: { vue, \u0026#39;@typescript-eslint\u0026#39;: typescript, prettier }, rules: { // Vue 規則 \u0026#39;vue/multi-word-component-names\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/component-name-in-template-casing\u0026#39;: [\u0026#39;error\u0026#39;, \u0026#39;PascalCase\u0026#39;], \u0026#39;vue/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/no-multiple-template-root\u0026#39;: \u0026#39;off\u0026#39;, // Vue 3 支援多個根元素 \u0026#39;vue/script-setup-uses-vars\u0026#39;: \u0026#39;error\u0026#39;, // TypeScript 規則 \u0026#39;@typescript-eslint/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;@typescript-eslint/no-explicit-any\u0026#39;: \u0026#39;warn\u0026#39;, \u0026#39;@typescript-eslint/explicit-function-return-type\u0026#39;: \u0026#39;off\u0026#39;, \u0026#39;@typescript-eslint/no-non-null-assertion\u0026#39;: \u0026#39;warn\u0026#39;, // 通用規則 \u0026#39;no-console\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;no-debugger\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;prefer-const\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;no-var\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;object-shorthand\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;prefer-template\u0026#39;: \u0026#39;error\u0026#39;, // Prettier 規則 \u0026#39;prettier/prettier\u0026#39;: \u0026#39;error\u0026#39; } } ]); 3.2 Prettier 設定 .prettierrc 範例 { \u0026#34;semi\u0026#34;: true, \u0026#34;trailingComma\u0026#34;: \u0026#34;es5\u0026#34;, \u0026#34;singleQuote\u0026#34;: true, \u0026#34;printWidth\u0026#34;: 80, \u0026#34;tabWidth\u0026#34;: 2, \u0026#34;useTabs\u0026#34;: false, \u0026#34;bracketSpacing\u0026#34;: true, \u0026#34;bracketSameLine\u0026#34;: false, \u0026#34;arrowParens\u0026#34;: \u0026#34;avoid\u0026#34;, \u0026#34;endOfLine\u0026#34;: \u0026#34;lf\u0026#34;, \u0026#34;vueIndentScriptAndStyle\u0026#34;: true, \u0026#34;htmlWhitespaceSensitivity\u0026#34;: \u0026#34;css\u0026#34; } 3.3 TypeScript 撰寫規範 型別定義規範 // ✅ 正確範例 - 使用 interface 定義物件型別 interface User { id: number; name: string; email: string; isActive: boolean; createdAt: Date; updatedAt?: Date; // 選擇性屬性 } // ✅ 正確範例 - 使用 type 定義聯合型別 type Status = \u0026#39;pending\u0026#39; | \u0026#39;approved\u0026#39; | \u0026#39;rejected\u0026#39;; type Theme = \u0026#39;light\u0026#39; | \u0026#39;dark\u0026#39; | \u0026#39;auto\u0026#39;; // ✅ 正確範例 - 泛型使用 interface ApiResponse\u0026lt;T\u0026gt; { data: T; message: string; success: boolean; code: number; } // ✅ 正確範例 - 函式型別定義 type EventHandler\u0026lt;T = Event\u0026gt; = (event: T) =\u0026gt; void; type AsyncFunction\u0026lt;T\u0026gt; = () =\u0026gt; Promise\u0026lt;T\u0026gt;; 函式撰寫規範 // ✅ 正確範例 - 明確的參數和回傳型別 async function fetchUserData(userId: number): Promise\u0026lt;User | null\u0026gt; { try { const response = await api.get\u0026lt;ApiResponse\u0026lt;User\u0026gt;\u0026gt;(`/users/${userId}`); return response.data.data; } catch (error) { console.error(\u0026#39;Failed to fetch user data:\u0026#39;, error); return null; } } // ✅ 正確範例 - 箭頭函式與型別推斷 const formatCurrency = (amount: number, currency = \u0026#39;TWD\u0026#39;): string =\u0026gt; { return new Intl.NumberFormat(\u0026#39;zh-TW\u0026#39;, { style: \u0026#39;currency\u0026#39;, currency, }).format(amount); }; // ✅ 正確範例 - 高階函式 const createValidator = \u0026lt;T\u0026gt;( validator: (value: T) =\u0026gt; boolean, errorMessage: string ) =\u0026gt; { return (value: T): ValidationResult =\u0026gt; ({ isValid: validator(value), message: validator(value) ? \u0026#39;\u0026#39; : errorMessage, }); }; 3.4 Vue 3 Composition API 撰寫規範 \u0026lt;script setup\u0026gt; 結構規範 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 1. 導入 Vue 相關 API import { ref, computed, watch, onMounted } from \u0026#39;vue\u0026#39;; // 2. 導入 Composables import { useAuth } from \u0026#39;@/composables/useAuth\u0026#39;; import { useApi } from \u0026#39;@/composables/useApi\u0026#39;; // 3. 導入其他模組 import { formatDate } from \u0026#39;@/utils/format\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // 4. 定義 Props 介面 interface Props { userId: number; isEditable?: boolean; } // 5. 定義 Emits 介面 interface Emits { \u0026#39;user-updated\u0026#39;: [user: User]; \u0026#39;error\u0026#39;: [error: string]; } // 6. 宣告 Props 和 Emits const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { isEditable: false, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // 7. 響應式資料 const user = ref\u0026lt;User | null\u0026gt;(null); const loading = ref(false); const error = ref\u0026lt;string\u0026gt;(\u0026#39;\u0026#39;); // 8. 計算屬性 const displayName = computed(() =\u0026gt; { return user.value ? `${user.value.firstName} ${user.value.lastName}` : \u0026#39;\u0026#39;; }); const canEdit = computed(() =\u0026gt; { return props.isEditable \u0026amp;\u0026amp; user.value?.isActive; }); // 9. 監聽器 watch( () =\u0026gt; props.userId, async (newUserId) =\u0026gt; { if (newUserId) { await loadUser(); } }, { immediate: true } ); // 10. 方法 const loadUser = async (): Promise\u0026lt;void\u0026gt; =\u0026gt; { loading.value = true; error.value = \u0026#39;\u0026#39;; try { const userData = await fetchUserData(props.userId); user.value = userData; } catch (err) { error.value = \u0026#39;載入使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } finally { loading.value = false; } }; const updateUser = async (userData: Partial\u0026lt;User\u0026gt;): Promise\u0026lt;void\u0026gt; =\u0026gt; { if (!user.value) return; try { const updatedUser = await updateUserData(user.value.id, userData); user.value = updatedUser; emit(\u0026#39;user-updated\u0026#39;, updatedUser); } catch (err) { error.value = \u0026#39;更新使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } }; // 11. 生命週期鉤子 onMounted(() =\u0026gt; { console.log(\u0026#39;Component mounted\u0026#39;); }); // 12. 暴露給父元件的方法/屬性 (如需要) defineExpose({ loadUser, updateUser, }); \u0026lt;/script\u0026gt; 3.5 程式碼品質規範 註解撰寫規範 /** * 使用者資料服務類別 * * 提供使用者相關的 API 操作方法，包含： * - 取得使用者資料 * - 更新使用者資料 * - 刪除使用者 * * @example * ```typescript * const userService = new UserService(); * const user = await userService.getUser(123); * ``` */ export class UserService { /** * 根據 ID 取得使用者資料 * * @param userId - 使用者 ID * @returns 使用者資料，如果找不到則回傳 null * @throws {ApiError} 當 API 請求失敗時拋出錯誤 * * @example * ```typescript * const user = await userService.getUser(123); * if (user) { * console.log(user.name); * } * ``` */ async getUser(userId: number): Promise\u0026lt;User | null\u0026gt; { // TODO: 實作快取機制 // FIXME: 處理網路錯誤重試邏輯 try { const response = await this.api.get(`/users/${userId}`); return response.data; } catch (error) { // 記錄錯誤但不拋出，讓呼叫方決定如何處理 console.error(`Failed to fetch user ${userId}:`, error); return null; } } } 錯誤處理規範 // ✅ 正確範例 - 統一的錯誤處理 export class ApiError extends Error { constructor( message: string, public status: number, public code?: string ) { super(message); this.name = \u0026#39;ApiError\u0026#39;; } } // ✅ 正確範例 - 錯誤邊界處理 const handleApiError = (error: unknown): never =\u0026gt; { if (error instanceof ApiError) { switch (error.status) { case 401: // 重新導向到登入頁面 router.push(\u0026#39;/login\u0026#39;); break; case 403: // 顯示權限不足訊息 showErrorMessage(\u0026#39;您沒有權限執行此操作\u0026#39;); break; case 500: // 顯示伺服器錯誤訊息 showErrorMessage(\u0026#39;伺服器發生錯誤，請稍後再試\u0026#39;); break; default: showErrorMessage(error.message); } } else { // 未知錯誤 console.error(\u0026#39;Unexpected error:\u0026#39;, error); showErrorMessage(\u0026#39;發生未知錯誤\u0026#39;); } throw error; }; 4. 元件開發規範 4.1 Vue 單檔元件 (SFC) 結構 標準 SFC 結構順序 \u0026lt;!-- 1. 模板區域 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-profile\u0026#34;\u0026gt; \u0026lt;!-- 內容 --\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 2. 邏輯區域 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 邏輯代碼 \u0026lt;/script\u0026gt; \u0026lt;!-- 3. 樣式區域 --\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; // 樣式代碼 \u0026lt;/style\u0026gt; 完整元件範例 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-card\u0026#34; :class=\u0026#34;cardClasses\u0026#34;\u0026gt; \u0026lt;!-- 頭像區域 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__avatar\u0026#34;\u0026gt; \u0026lt;img :src=\u0026#34;user.avatar || defaultAvatar\u0026#34; :alt=\u0026#34;`${user.name} 的頭像`\u0026#34; class=\u0026#34;user-card__avatar-img\u0026#34; @error=\u0026#34;handleImageError\u0026#34; /\u0026gt; \u0026lt;div v-if=\u0026#34;showStatus\u0026#34; class=\u0026#34;user-card__status\u0026#34; :class=\u0026#34;statusClass\u0026#34;\u0026gt; {{ statusText }} \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 使用者資訊 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__content\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;user-card__name\u0026#34;\u0026gt;{{ user.name }}\u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;user-card__email\u0026#34;\u0026gt;{{ user.email }}\u0026lt;/p\u0026gt; \u0026lt;!-- 標籤 --\u0026gt; \u0026lt;div v-if=\u0026#34;user.tags?.length\u0026#34; class=\u0026#34;user-card__tags\u0026#34;\u0026gt; \u0026lt;span v-for=\u0026#34;tag in user.tags\u0026#34; :key=\u0026#34;tag\u0026#34; class=\u0026#34;user-card__tag\u0026#34; \u0026gt; {{ tag }} \u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 動作按鈕 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__actions\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleEdit\u0026#34; \u0026gt; 編輯 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleView\u0026#34; \u0026gt; 查看 \u0026lt;/BaseButton\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 載入狀態 --\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;user-card__loading\u0026#34;\u0026gt; \u0026lt;LoadingSpinner size=\u0026#34;small\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed, ref } from \u0026#39;vue\u0026#39;; import BaseButton from \u0026#39;@/components/base/BaseButton.vue\u0026#39;; import LoadingSpinner from \u0026#39;@/components/base/LoadingSpinner.vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // Props 定義 interface Props { user: User; variant?: \u0026#39;default\u0026#39; | \u0026#39;compact\u0026#39; | \u0026#39;detailed\u0026#39;; showStatus?: boolean; interactive?: boolean; } // Emits 定義 interface Emits { edit: [user: User]; view: [user: User]; \u0026#39;avatar-error\u0026#39;: [user: User]; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { variant: \u0026#39;default\u0026#39;, showStatus: true, interactive: true, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // Composables const { t } = useI18n(); // 響應式資料 const loading = ref(false); const defaultAvatar = \u0026#39;/images/default-avatar.png\u0026#39;; // 計算屬性 const cardClasses = computed(() =\u0026gt; ({ [`user-card--${props.variant}`]: true, \u0026#39;user-card--interactive\u0026#39;: props.interactive, \u0026#39;user-card--loading\u0026#39;: loading.value, })); const statusClass = computed(() =\u0026gt; ({ \u0026#39;user-card__status--online\u0026#39;: props.user.isOnline, \u0026#39;user-card__status--offline\u0026#39;: !props.user.isOnline, })); const statusText = computed(() =\u0026gt; { return props.user.isOnline ? t(\u0026#39;common.online\u0026#39;) : t(\u0026#39;common.offline\u0026#39;); }); // 方法 const handleEdit = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;edit\u0026#39;, props.user); }; const handleView = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;view\u0026#39;, props.user); }; const handleImageError = (): void =\u0026gt; { emit(\u0026#39;avatar-error\u0026#39;, props.user); }; \u0026lt;/script\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; .user-card { @apply bg-white rounded-lg shadow-md p-4 transition-all duration-200; \u0026amp;--interactive { @apply hover:shadow-lg cursor-pointer; } \u0026amp;--loading { @apply opacity-50 pointer-events-none; } \u0026amp;__avatar { @apply relative flex-shrink-0; } \u0026amp;__avatar-img { @apply w-12 h-12 rounded-full object-cover; } \u0026amp;__status { @apply absolute -bottom-1 -right-1 px-2 py-1 text-xs rounded-full text-white; \u0026amp;--online { @apply bg-green-500; } \u0026amp;--offline { @apply bg-gray-400; } } \u0026amp;__content { @apply flex-1 ml-4; } \u0026amp;__name { @apply text-lg font-semibold text-gray-900 mb-1; } \u0026amp;__email { @apply text-sm text-gray-600 mb-2; } \u0026amp;__tags { @apply flex flex-wrap gap-1 mb-3; } \u0026amp;__tag { @apply px-2 py-1 text-xs bg-blue-100 text-blue-800 rounded; } \u0026amp;__actions { @apply flex gap-2; } \u0026amp;__loading { @apply absolute inset-0 flex items-center justify-center bg-white bg-opacity-75; } // 變體樣式 \u0026amp;--compact { @apply p-2; .user-card__avatar-img { @apply w-8 h-8; } .user-card__name { @apply text-base; } } \u0026amp;--detailed { @apply p-6; .user-card__avatar-img { @apply w-16 h-16; } } } \u0026lt;/style\u0026gt; 4.2 Props 設計規範 Props 型別定義 // ✅ 正確範例 - 完整的 Props 介面 interface ButtonProps { // 必要屬性 label: string; // 選擇性屬性with default values variant?: \u0026#39;primary\u0026#39; | \u0026#39;secondary\u0026#39; | \u0026#39;danger\u0026#39; | \u0026#39;ghost\u0026#39;; size?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; disabled?: boolean; loading?: boolean; // 複雜型別 icon?: { name: string; position: \u0026#39;left\u0026#39; | \u0026#39;right\u0026#39;; }; // 函式型別 onClick?: (event: MouseEvent) =\u0026gt; void; } const props = withDefaults(defineProps\u0026lt;ButtonProps\u0026gt;(), { variant: \u0026#39;primary\u0026#39;, size: \u0026#39;medium\u0026#39;, disabled: false, loading: false, }); Props 驗證 // ✅ 正確範例 - 執行時驗證 interface FormInputProps { modelValue: string; type?: \u0026#39;text\u0026#39; | \u0026#39;email\u0026#39; | \u0026#39;password\u0026#39; | \u0026#39;number\u0026#39;; placeholder?: string; required?: boolean; maxLength?: number; pattern?: string; validator?: (value: string) =\u0026gt; boolean | string; } const props = withDefaults(defineProps\u0026lt;FormInputProps\u0026gt;(), { type: \u0026#39;text\u0026#39;, required: false, }); // 自定義驗證邏輯 const isValid = computed(() =\u0026gt; { if (props.required \u0026amp;\u0026amp; !props.modelValue) { return false; } if (props.maxLength \u0026amp;\u0026amp; props.modelValue.length \u0026gt; props.maxLength) { return false; } if (props.pattern \u0026amp;\u0026amp; !new RegExp(props.pattern).test(props.modelValue)) { return false; } if (props.validator) { const result = props.validator(props.modelValue); return result === true; } return true; }); 4.3 Emits 事件規範 事件定義與觸發 // ✅ 正確範例 - 型別安全的事件定義 interface FormEmits { // v-model 雙向綁定 \u0026#39;update:modelValue\u0026#39;: [value: string]; // 表單事件 submit: [data: FormData]; cancel: []; // 驗證事件 \u0026#39;validation-error\u0026#39;: [errors: ValidationError[]]; \u0026#39;validation-success\u0026#39;: []; // 使用者互動事件 \u0026#39;field-focus\u0026#39;: [fieldName: string]; \u0026#39;field-blur\u0026#39;: [fieldName: string, value: string]; } const emit = defineEmits\u0026lt;FormEmits\u0026gt;(); // 事件觸發範例 const handleSubmit = (formData: FormData): void =\u0026gt; { // 驗證表單 const errors = validateForm(formData); if (errors.length \u0026gt; 0) { emit(\u0026#39;validation-error\u0026#39;, errors); return; } emit(\u0026#39;validation-success\u0026#39;); emit(\u0026#39;submit\u0026#39;, formData); }; const handleCancel = (): void =\u0026gt; { emit(\u0026#39;cancel\u0026#39;); }; // v-model 實作 const updateValue = (newValue: string): void =\u0026gt; { emit(\u0026#39;update:modelValue\u0026#39;, newValue); }; 4.4 Slots 使用規範 具名插槽設計 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;header v-if=\u0026#34;$slots.header\u0026#34; class=\u0026#34;card__header\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;header\u0026#34; :title=\u0026#34;title\u0026#34; :subtitle=\u0026#34;subtitle\u0026#34; /\u0026gt; \u0026lt;/header\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;main class=\u0026#34;card__content\u0026#34;\u0026gt; \u0026lt;slot :data=\u0026#34;data\u0026#34; :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/main\u0026gt; \u0026lt;!-- 動作按鈕插槽 --\u0026gt; \u0026lt;footer v-if=\u0026#34;$slots.actions\u0026#34; class=\u0026#34;card__actions\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;actions\u0026#34; :save=\u0026#34;handleSave\u0026#34; :cancel=\u0026#34;handleCancel\u0026#34; :canSave=\u0026#34;canSave\u0026#34; /\u0026gt; \u0026lt;/footer\u0026gt; \u0026lt;!-- 條件式插槽 --\u0026gt; \u0026lt;div v-if=\u0026#34;$slots.sidebar\u0026#34; class=\u0026#34;card__sidebar\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;sidebar\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { title?: string; subtitle?: string; data: any; loading?: boolean; } const props = defineProps\u0026lt;Props\u0026gt;(); // 計算屬性 const canSave = computed(() =\u0026gt; { return !props.loading \u0026amp;\u0026amp; isDataValid(props.data); }); // 提供給插槽的方法 const handleSave = (): void =\u0026gt; { // 儲存邏輯 }; const handleCancel = (): void =\u0026gt; { // 取消邏輯 }; \u0026lt;/script\u0026gt; 插槽使用範例 \u0026lt;template\u0026gt; \u0026lt;Card :data=\u0026#34;userData\u0026#34; :loading=\u0026#34;loading\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;template #header=\u0026#34;{ title, subtitle }\u0026#34;\u0026gt; \u0026lt;h2\u0026gt;{{ title || \u0026#39;使用者資料\u0026#39; }}\u0026lt;/h2\u0026gt; \u0026lt;p v-if=\u0026#34;subtitle\u0026#34;\u0026gt;{{ subtitle }}\u0026lt;/p\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;template #default=\u0026#34;{ data, loading }\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;!loading\u0026#34;\u0026gt; \u0026lt;UserForm :user=\u0026#34;data\u0026#34; @update=\u0026#34;handleUserUpdate\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;LoadingSpinner v-else /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 動作插槽 --\u0026gt; \u0026lt;template #actions=\u0026#34;{ save, cancel, canSave }\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; :disabled=\u0026#34;!canSave\u0026#34; @click=\u0026#34;save\u0026#34; \u0026gt; 儲存 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; @click=\u0026#34;cancel\u0026#34; \u0026gt; 取消 \u0026lt;/BaseButton\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;/Card\u0026gt; \u0026lt;/template\u0026gt; 4.5 元件組合與複用 高階元件 (HOC) 模式 \u0026lt;!-- withLoading.vue - 高階元件 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;with-loading\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;loading-overlay\u0026#34;\u0026gt; \u0026lt;LoadingSpinner :size=\u0026#34;loadingSize\u0026#34; /\u0026gt; \u0026lt;p v-if=\u0026#34;loadingText\u0026#34;\u0026gt;{{ loadingText }}\u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div :class=\u0026#34;{ \u0026#39;is-loading\u0026#39;: loading }\u0026#34;\u0026gt; \u0026lt;slot :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { loading: boolean; loadingText?: string; loadingSize?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; } withDefaults(defineProps\u0026lt;Props\u0026gt;(), { loadingSize: \u0026#39;medium\u0026#39;, }); \u0026lt;/script\u0026gt; 組合式元件使用 \u0026lt;template\u0026gt; \u0026lt;WithLoading :loading=\u0026#34;isLoading\u0026#34; loading-text=\u0026#34;載入使用者資料中...\u0026#34;\u0026gt; \u0026lt;UserProfile :user=\u0026#34;userData\u0026#34; @edit=\u0026#34;handleEdit\u0026#34; @delete=\u0026#34;handleDelete\u0026#34; /\u0026gt; \u0026lt;/WithLoading\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import WithLoading from \u0026#39;@/components/hoc/WithLoading.vue\u0026#39;; import UserProfile from \u0026#39;@/components/UserProfile.vue\u0026#39;; const isLoading = ref(false); const userData = ref(null); const handleEdit = (user: User): void =\u0026gt; { // 編輯邏輯 }; const handleDelete = (user: User): void =\u0026gt; { // 刪除邏輯 }; \u0026lt;/script\u0026gt; 5. 樣式與 Tailwind CSS 規範 5.1 Tailwind CSS 設定 tailwind.config.js 範例 /** @type {import(\u0026#39;tailwindcss\u0026#39;).Config} */ export default { content: [ \u0026#39;./index.html\u0026#39;, \u0026#39;./src/**/*.{vue,js,ts,jsx,tsx}\u0026#39;, ], theme: { extend: { // 顏色系統 colors: { primary: { 50: \u0026#39;#eff6ff\u0026#39;, 100: \u0026#39;#dbeafe\u0026#39;, 200: \u0026#39;#bfdbfe\u0026#39;, 300: \u0026#39;#93c5fd\u0026#39;, 400: \u0026#39;#60a5fa\u0026#39;, 500: \u0026#39;#3b82f6\u0026#39;, // 主要品牌色 600: \u0026#39;#2563eb\u0026#39;, 700: \u0026#39;#1d4ed8\u0026#39;, 800: \u0026#39;#1e40af\u0026#39;, 900: \u0026#39;#1e3a8a\u0026#39;, 950: \u0026#39;#172554\u0026#39;, }, secondary: { 50: \u0026#39;#f8fafc\u0026#39;, 500: \u0026#39;#64748b\u0026#39;, 900: \u0026#39;#0f172a\u0026#39;, }, success: { 50: \u0026#39;#f0fdf4\u0026#39;, 500: \u0026#39;#22c55e\u0026#39;, 900: \u0026#39;#14532d\u0026#39;, }, warning: { 50: \u0026#39;#fffbeb\u0026#39;, 500: \u0026#39;#f59e0b\u0026#39;, 900: \u0026#39;#78350f\u0026#39;, }, danger: { 50: \u0026#39;#fef2f2\u0026#39;, 500: \u0026#39;#ef4444\u0026#39;, 900: \u0026#39;#7f1d1d\u0026#39;, }, }, // 字型設定 fontFamily: { sans: [ \u0026#39;Noto Sans TC\u0026#39;, \u0026#39;Microsoft JhengHei\u0026#39;, \u0026#39;PingFang TC\u0026#39;, \u0026#39;Helvetica Neue\u0026#39;, \u0026#39;Arial\u0026#39;, \u0026#39;sans-serif\u0026#39;, ], }, // 響應式斷點 screens: { \u0026#39;xs\u0026#39;: \u0026#39;475px\u0026#39;, \u0026#39;sm\u0026#39;: \u0026#39;640px\u0026#39;, \u0026#39;md\u0026#39;: \u0026#39;768px\u0026#39;, \u0026#39;lg\u0026#39;: \u0026#39;1024px\u0026#39;, \u0026#39;xl\u0026#39;: \u0026#39;1280px\u0026#39;, \u0026#39;2xl\u0026#39;: \u0026#39;1536px\u0026#39;, }, }, }, plugins: [ require(\u0026#39;@tailwindcss/forms\u0026#39;), require(\u0026#39;@tailwindcss/typography\u0026#39;), ], }; 5.2 RWD 響應式設計原則 Mobile-First 設計策略 \u0026lt;template\u0026gt; \u0026lt;!-- 響應式網格系統 --\u0026gt; \u0026lt;div class=\u0026#34;container mx-auto px-4\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-4\u0026#34;\u0026gt; \u0026lt;div v-for=\u0026#34;item in items\u0026#34; :key=\u0026#34;item.id\u0026#34; class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 響應式圖片 --\u0026gt; \u0026lt;img :src=\u0026#34;item.image\u0026#34; :alt=\u0026#34;item.title\u0026#34; class=\u0026#34;w-full h-32 sm:h-40 lg:h-48 object-cover\u0026#34; /\u0026gt; \u0026lt;!-- 響應式文字 --\u0026gt; \u0026lt;div class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;text-lg sm:text-xl lg:text-2xl font-semibold\u0026#34;\u0026gt; {{ item.title }} \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm sm:text-base text-gray-600\u0026#34;\u0026gt; {{ item.description }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 響應式導航 --\u0026gt; \u0026lt;nav class=\u0026#34;bg-white shadow\u0026#34;\u0026gt; \u0026lt;!-- 桌面版導航 --\u0026gt; \u0026lt;div class=\u0026#34;hidden lg:flex items-center space-x-8 px-6 py-4\u0026#34;\u0026gt; \u0026lt;a v-for=\u0026#34;link in navLinks\u0026#34; :key=\u0026#34;link.path\u0026#34; :href=\u0026#34;link.path\u0026#34;\u0026gt; {{ link.title }} \u0026lt;/a\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 行動版選單 --\u0026gt; \u0026lt;div class=\u0026#34;lg:hidden\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleMobileMenu\u0026#34; class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;MenuIcon class=\u0026#34;w-6 h-6\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/nav\u0026gt; \u0026lt;/template\u0026gt; 5.3 顏色與主題設計 CSS 變數主題系統 :root { /* 品牌色 */ --color-primary: #3b82f6; --color-secondary: #64748b; /* 語意化顏色 */ --color-success: #22c55e; --color-warning: #f59e0b; --color-danger: #ef4444; /* 背景色 */ --bg-primary: #ffffff; --bg-secondary: #f8fafc; /* 文字色 */ --text-primary: #111827; --text-secondary: #4b5563; } /* 暗色主題 */ [data-theme=\u0026#34;dark\u0026#34;] { --bg-primary: #111827; --bg-secondary: #1f2937; --text-primary: #f9fafb; --text-secondary: #d1d5db; } 5.4 共用樣式元件 基礎元件樣式 @layer components { /* 按鈕樣式 */ .btn { @apply inline-flex items-center px-4 py-2 text-sm font-medium rounded-md transition-colors focus:outline-none focus:ring-2; } .btn-primary { @apply btn bg-primary-500 text-white hover:bg-primary-600; } .btn-secondary { @apply btn bg-gray-200 text-gray-900 hover:bg-gray-300; } /* 表單樣式 */ .form-input { @apply w-full px-3 py-2 border border-gray-300 rounded-md focus:ring-1 focus:ring-primary-500 focus:border-primary-500; } /* 卡片樣式 */ .card { @apply bg-white rounded-lg shadow-md p-4; } } 總結 本前端開發指引提供了完整的開發規範，涵蓋了專案結構、命名規範、程式撰寫風格、元件開發和樣式設計等核心面向。請開發團隊嚴格遵循這些規範，以確保程式碼品質和專案的可維護性。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%89%8D%E7%AB%AF%E9%96%8B%E7%99%BC%E6%8C%87%E5%BC%95/","summary":"前端開發指引 文件資訊 版本: 1.0.0 建立日期: 2025-08-11 適用專案: 大型金融級 Web 專案 技術棧: Vue 3.x + TypeScript + Tailwind CSS 目錄 專案目錄與檔案結構規範 命名規範 程式撰寫風格與 Lint 設定 元件開發規範 樣式與 Tailwind CSS 規範 API 串接與資料存取規範 狀態管理規範 多語系處理規範 測試規範 安全性考量 效能優化規範 無障礙設計規範 版本控制與分支策略 專案建置與部署流程 程式碼審查規範 常見錯誤處理與 Debug 流程 開發工具與環境設定 團隊協作與溝通規範 1. 專案目錄與檔案結構規範 1.1 標準專案結構 frontend-project/ ├── public/ # 靜態資源 │ ├── favicon.ico │ ├── index.html │ └── manifest.json ├── src/ # 原始碼 │ ├── api/ # API 相關 │ │ ├── modules/ # 依功能模組分類 │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ ├── interceptors/ # 攔截器 │ │ └── types/ # API 型別定義 │ ├── assets/ # 靜態資源 │ │ ├── images/ │ │ ├── icons/ │ │ └── fonts/ │ ├── components/ # 共用元件 │ │ ├── base/ # 基礎元件 │ │ │ ├── BaseButton.vue │ │ │ ├── BaseInput.vue │ │ │ └── BaseModal.vue │ │ ├── business/ # 業務元件 │ │ └── layout/ # 版面元件 │ │ ├── Header.vue │ │ ├── Sidebar.vue │ │ └── Footer.vue │ ├── composables/ # Vue 3 Composition API │ │ ├── useAuth.ts │ │ ├── useApi.ts │ │ └── useLocalStorage.ts │ ├── constants/ # 常數定義 │ │ ├── api.ts │ │ ├── routes.ts │ │ └── config.ts │ ├── directives/ # 自定義指令 │ ├── i18n/ # 多語系 │ │ ├── locales/ │ │ │ ├── zh-TW.json │ │ │ ├── en-US.json │ │ │ └── ja-JP.json │ │ └── index.ts │ ├── layouts/ # 版面配置 │ │ ├── DefaultLayout.vue │ │ ├── AuthLayout.vue │ │ └── EmptyLayout.vue │ ├── middleware/ # 中間件 │ │ ├── auth.ts │ │ └── permission.ts │ ├── pages/ # 頁面元件 │ │ ├── auth/ │ │ │ ├── Login.vue │ │ │ └── Register.vue │ │ ├── dashboard/ │ │ └── user/ │ ├── plugins/ # 插件 │ │ ├── axios.ts │ │ ├── i18n.ts │ │ └── router.ts │ ├── router/ # 路由設定 │ │ ├── modules/ # 路由模組 │ │ │ ├── auth.ts │ │ │ └── dashboard.ts │ │ └── index.ts │ ├── stores/ # Pinia 狀態管理 │ │ ├── modules/ │ │ │ ├── auth.ts │ │ │ └── user.ts │ │ └── index.ts │ ├── styles/ # 樣式檔案 │ │ ├── globals.css │ │ ├── variables.css │ │ └── components/ │ ├── types/ # TypeScript 型別定義 │ │ ├── api.ts │ │ ├── auth.ts │ │ └── global.ts │ ├── utils/ # 工具函式 │ │ ├── format.ts │ │ ├── validation.ts │ │ └── storage.ts │ ├── App.vue # 根元件 │ └── main.ts # 應用程式進入點 ├── tests/ # 測試檔案 │ ├── unit/ # 單元測試 │ ├── e2e/ # E2E 測試 │ └── __mocks__/ # Mock 檔案 ├── .env # 環境變數 ├── .env.development ├── .env.production ├── .eslintrc.js # ESLint 設定 ├── .prettierrc # Prettier 設定 ├── tailwind.config.js # Tailwind CSS 設定 ├── vite.config.ts # Vite 設定 ├── tsconfig.json # TypeScript 設定 └── package.json # 套件管理 1.2 檔案命名原則 檔案類型對應命名方式 Vue 元件: PascalCase (如 UserProfile.vue) TypeScript 檔案: camelCase (如 userService.ts) CSS/SCSS 檔案: kebab-case (如 user-profile.scss) 測試檔案: 與被測檔案同名 + .test 或 .spec (如 UserProfile.test.ts) 型別定義檔案: camelCase + .d.ts (如 userTypes.d.ts) 特殊檔案命名 頁面元件: PascalCase，通常以頁面功能命名 (如 UserManagement.vue) Layout 元件: PascalCase + Layout 後綴 (如 DashboardLayout.vue) Store 檔案: camelCase，以業務領域命名 (如 userStore.ts) API 檔案: camelCase，以 API 服務命名 (如 userApi.ts) 2. 命名規範 2.1 檔案與資料夾命名 資料夾命名 使用 kebab-case (小寫字母 + 連字號) 名稱應簡潔且具描述性 ✅ 正確範例 user-management/ auth-service/ api-client/ ❌ 錯誤範例 UserManagement/ authService/ API_Client/ 檔案命名 Vue 元件檔案: PascalCase JavaScript/TypeScript 檔案: camelCase 樣式檔案: kebab-case 設定檔案: kebab-case 或 camelCase (依慣例) // ✅ 正確範例 UserProfile.vue userService.ts user-profile.scss vite.config.ts // ❌ 錯誤範例 userprofile.vue UserService.ts user_profile.scss vite_config.ts 2.2 變數與函式命名 JavaScript/TypeScript 變數 使用 camelCase 常數使用 UPPER_SNAKE_CASE 私有變數以 _ 開頭 布林值變數使用 is、has、can、should 等前綴 // ✅ 正確範例 const userName = \u0026#39;John Doe\u0026#39;; const API_BASE_URL = \u0026#39;https://api.example.com\u0026#39;; const _privateVariable = \u0026#39;private\u0026#39;; const isLoggedIn = true; const hasPermission = false; const canEdit = true; const shouldUpdate = false; // ❌ 錯誤範例 const user_name = \u0026#39;John Doe\u0026#39;; const apiBaseUrl = \u0026#39;https://api.example.com\u0026#39;; // 常數應使用大寫 const privateVariable = \u0026#39;private\u0026#39;; // 私有變數缺少前綴 const loggedIn = true; // 布林值缺少前綴 函式命名 使用 camelCase 動詞開頭，描述函式的動作 事件處理器使用 handle 前綴 取得資料使用 get、fetch 前綴 設定資料使用 set、update 前綴 // ✅ 正確範例 function getUserData() { } function handleButtonClick() { } function validateEmail() { } function formatCurrency() { } function updateUserProfile() { } function fetchUserList() { } // ❌ 錯誤範例 function userData() { } // 缺少動詞 function buttonClick() { } // 事件處理器缺少 handle 前綴 function email() { } // 不明確的命名 function currency() { } // 不明確的命名 2.3 Vue 元件命名 元件名稱 使用 PascalCase 多個單字組合，避免單一單字 基礎元件使用 Base 前綴 業務元件使用具體的業務領域命名 \u0026lt;!-- ✅ 正確範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: UserProfile.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: BaseButton.vue \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: PaymentForm.vue \u0026lt;/script\u0026gt; \u0026lt;!-- ❌ 錯誤範例 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: user.vue - 命名太簡短 \u0026lt;/script\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 元件檔案: button.vue - 應使用 BaseButton \u0026lt;/script\u0026gt; Props 命名 定義時使用 camelCase HTML 模板中使用 kebab-case \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 interface Props { userName: string; isVisible: boolean; maxLength?: number; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { maxLength: 100 }); \u0026lt;/script\u0026gt; \u0026lt;template\u0026gt; \u0026lt;!-- HTML 模板中使用 kebab-case --\u0026gt; \u0026lt;UserProfile :user-name=\u0026#34;currentUser\u0026#34; :is-visible=\u0026#34;showProfile\u0026#34; :max-length=\u0026#34;200\u0026#34; /\u0026gt; \u0026lt;/template\u0026gt; Event 命名 使用 kebab-case 動詞開頭，描述事件的動作 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // ✅ 正確範例 const emit = defineEmits\u0026lt;{ \u0026#39;update:modelValue\u0026#39;: [value: string]; \u0026#39;user-created\u0026#39;: [user: User]; \u0026#39;form-submitted\u0026#39;: [data: FormData]; \u0026#39;item-selected\u0026#39;: [item: Item]; }\u0026gt;(); // 觸發事件 emit(\u0026#39;user-created\u0026#39;, newUser); emit(\u0026#39;form-submitted\u0026#39;, formData); \u0026lt;/script\u0026gt; 3. 程式撰寫風格與 Lint 設定 3.1 ESLint 設定 eslint.config.js 範例 import { defineConfig } from \u0026#39;eslint-define-config\u0026#39;; import vue from \u0026#39;eslint-plugin-vue\u0026#39;; import typescript from \u0026#39;@typescript-eslint/eslint-plugin\u0026#39;; import typescriptParser from \u0026#39;@typescript-eslint/parser\u0026#39;; import prettier from \u0026#39;eslint-plugin-prettier\u0026#39;; export default defineConfig([ { files: [\u0026#39;**/*.{js,ts,vue}\u0026#39;], languageOptions: { parser: typescriptParser, parserOptions: { ecmaVersion: 2022, sourceType: \u0026#39;module\u0026#39;, extraFileExtensions: [\u0026#39;.vue\u0026#39;] } }, plugins: { vue, \u0026#39;@typescript-eslint\u0026#39;: typescript, prettier }, rules: { // Vue 規則 \u0026#39;vue/multi-word-component-names\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/component-name-in-template-casing\u0026#39;: [\u0026#39;error\u0026#39;, \u0026#39;PascalCase\u0026#39;], \u0026#39;vue/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;vue/no-multiple-template-root\u0026#39;: \u0026#39;off\u0026#39;, // Vue 3 支援多個根元素 \u0026#39;vue/script-setup-uses-vars\u0026#39;: \u0026#39;error\u0026#39;, // TypeScript 規則 \u0026#39;@typescript-eslint/no-unused-vars\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;@typescript-eslint/no-explicit-any\u0026#39;: \u0026#39;warn\u0026#39;, \u0026#39;@typescript-eslint/explicit-function-return-type\u0026#39;: \u0026#39;off\u0026#39;, \u0026#39;@typescript-eslint/no-non-null-assertion\u0026#39;: \u0026#39;warn\u0026#39;, // 通用規則 \u0026#39;no-console\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;no-debugger\u0026#39;: process.env.NODE_ENV === \u0026#39;production\u0026#39; ? \u0026#39;error\u0026#39; : \u0026#39;warn\u0026#39;, \u0026#39;prefer-const\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;no-var\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;object-shorthand\u0026#39;: \u0026#39;error\u0026#39;, \u0026#39;prefer-template\u0026#39;: \u0026#39;error\u0026#39;, // Prettier 規則 \u0026#39;prettier/prettier\u0026#39;: \u0026#39;error\u0026#39; } } ]); 3.2 Prettier 設定 .prettierrc 範例 { \u0026#34;semi\u0026#34;: true, \u0026#34;trailingComma\u0026#34;: \u0026#34;es5\u0026#34;, \u0026#34;singleQuote\u0026#34;: true, \u0026#34;printWidth\u0026#34;: 80, \u0026#34;tabWidth\u0026#34;: 2, \u0026#34;useTabs\u0026#34;: false, \u0026#34;bracketSpacing\u0026#34;: true, \u0026#34;bracketSameLine\u0026#34;: false, \u0026#34;arrowParens\u0026#34;: \u0026#34;avoid\u0026#34;, \u0026#34;endOfLine\u0026#34;: \u0026#34;lf\u0026#34;, \u0026#34;vueIndentScriptAndStyle\u0026#34;: true, \u0026#34;htmlWhitespaceSensitivity\u0026#34;: \u0026#34;css\u0026#34; } 3.3 TypeScript 撰寫規範 型別定義規範 // ✅ 正確範例 - 使用 interface 定義物件型別 interface User { id: number; name: string; email: string; isActive: boolean; createdAt: Date; updatedAt?: Date; // 選擇性屬性 } // ✅ 正確範例 - 使用 type 定義聯合型別 type Status = \u0026#39;pending\u0026#39; | \u0026#39;approved\u0026#39; | \u0026#39;rejected\u0026#39;; type Theme = \u0026#39;light\u0026#39; | \u0026#39;dark\u0026#39; | \u0026#39;auto\u0026#39;; // ✅ 正確範例 - 泛型使用 interface ApiResponse\u0026lt;T\u0026gt; { data: T; message: string; success: boolean; code: number; } // ✅ 正確範例 - 函式型別定義 type EventHandler\u0026lt;T = Event\u0026gt; = (event: T) =\u0026gt; void; type AsyncFunction\u0026lt;T\u0026gt; = () =\u0026gt; Promise\u0026lt;T\u0026gt;; 函式撰寫規範 // ✅ 正確範例 - 明確的參數和回傳型別 async function fetchUserData(userId: number): Promise\u0026lt;User | null\u0026gt; { try { const response = await api.get\u0026lt;ApiResponse\u0026lt;User\u0026gt;\u0026gt;(`/users/${userId}`); return response.data.data; } catch (error) { console.error(\u0026#39;Failed to fetch user data:\u0026#39;, error); return null; } } // ✅ 正確範例 - 箭頭函式與型別推斷 const formatCurrency = (amount: number, currency = \u0026#39;TWD\u0026#39;): string =\u0026gt; { return new Intl.NumberFormat(\u0026#39;zh-TW\u0026#39;, { style: \u0026#39;currency\u0026#39;, currency, }).format(amount); }; // ✅ 正確範例 - 高階函式 const createValidator = \u0026lt;T\u0026gt;( validator: (value: T) =\u0026gt; boolean, errorMessage: string ) =\u0026gt; { return (value: T): ValidationResult =\u0026gt; ({ isValid: validator(value), message: validator(value) ? \u0026#39;\u0026#39; : errorMessage, }); }; 3.4 Vue 3 Composition API 撰寫規範 \u0026lt;script setup\u0026gt; 結構規範 \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 1. 導入 Vue 相關 API import { ref, computed, watch, onMounted } from \u0026#39;vue\u0026#39;; // 2. 導入 Composables import { useAuth } from \u0026#39;@/composables/useAuth\u0026#39;; import { useApi } from \u0026#39;@/composables/useApi\u0026#39;; // 3. 導入其他模組 import { formatDate } from \u0026#39;@/utils/format\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // 4. 定義 Props 介面 interface Props { userId: number; isEditable?: boolean; } // 5. 定義 Emits 介面 interface Emits { \u0026#39;user-updated\u0026#39;: [user: User]; \u0026#39;error\u0026#39;: [error: string]; } // 6. 宣告 Props 和 Emits const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { isEditable: false, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // 7. 響應式資料 const user = ref\u0026lt;User | null\u0026gt;(null); const loading = ref(false); const error = ref\u0026lt;string\u0026gt;(\u0026#39;\u0026#39;); // 8. 計算屬性 const displayName = computed(() =\u0026gt; { return user.value ? `${user.value.firstName} ${user.value.lastName}` : \u0026#39;\u0026#39;; }); const canEdit = computed(() =\u0026gt; { return props.isEditable \u0026amp;\u0026amp; user.value?.isActive; }); // 9. 監聽器 watch( () =\u0026gt; props.userId, async (newUserId) =\u0026gt; { if (newUserId) { await loadUser(); } }, { immediate: true } ); // 10. 方法 const loadUser = async (): Promise\u0026lt;void\u0026gt; =\u0026gt; { loading.value = true; error.value = \u0026#39;\u0026#39;; try { const userData = await fetchUserData(props.userId); user.value = userData; } catch (err) { error.value = \u0026#39;載入使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } finally { loading.value = false; } }; const updateUser = async (userData: Partial\u0026lt;User\u0026gt;): Promise\u0026lt;void\u0026gt; =\u0026gt; { if (!user.value) return; try { const updatedUser = await updateUserData(user.value.id, userData); user.value = updatedUser; emit(\u0026#39;user-updated\u0026#39;, updatedUser); } catch (err) { error.value = \u0026#39;更新使用者資料失敗\u0026#39;; emit(\u0026#39;error\u0026#39;, error.value); } }; // 11. 生命週期鉤子 onMounted(() =\u0026gt; { console.log(\u0026#39;Component mounted\u0026#39;); }); // 12. 暴露給父元件的方法/屬性 (如需要) defineExpose({ loadUser, updateUser, }); \u0026lt;/script\u0026gt; 3.5 程式碼品質規範 註解撰寫規範 /** * 使用者資料服務類別 * * 提供使用者相關的 API 操作方法，包含： * - 取得使用者資料 * - 更新使用者資料 * - 刪除使用者 * * @example * ```typescript * const userService = new UserService(); * const user = await userService.getUser(123); * ``` */ export class UserService { /** * 根據 ID 取得使用者資料 * * @param userId - 使用者 ID * @returns 使用者資料，如果找不到則回傳 null * @throws {ApiError} 當 API 請求失敗時拋出錯誤 * * @example * ```typescript * const user = await userService.getUser(123); * if (user) { * console.log(user.name); * } * ``` */ async getUser(userId: number): Promise\u0026lt;User | null\u0026gt; { // TODO: 實作快取機制 // FIXME: 處理網路錯誤重試邏輯 try { const response = await this.api.get(`/users/${userId}`); return response.data; } catch (error) { // 記錄錯誤但不拋出，讓呼叫方決定如何處理 console.error(`Failed to fetch user ${userId}:`, error); return null; } } } 錯誤處理規範 // ✅ 正確範例 - 統一的錯誤處理 export class ApiError extends Error { constructor( message: string, public status: number, public code?: string ) { super(message); this.name = \u0026#39;ApiError\u0026#39;; } } // ✅ 正確範例 - 錯誤邊界處理 const handleApiError = (error: unknown): never =\u0026gt; { if (error instanceof ApiError) { switch (error.status) { case 401: // 重新導向到登入頁面 router.push(\u0026#39;/login\u0026#39;); break; case 403: // 顯示權限不足訊息 showErrorMessage(\u0026#39;您沒有權限執行此操作\u0026#39;); break; case 500: // 顯示伺服器錯誤訊息 showErrorMessage(\u0026#39;伺服器發生錯誤，請稍後再試\u0026#39;); break; default: showErrorMessage(error.message); } } else { // 未知錯誤 console.error(\u0026#39;Unexpected error:\u0026#39;, error); showErrorMessage(\u0026#39;發生未知錯誤\u0026#39;); } throw error; }; 4. 元件開發規範 4.1 Vue 單檔元件 (SFC) 結構 標準 SFC 結構順序 \u0026lt;!-- 1. 模板區域 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-profile\u0026#34;\u0026gt; \u0026lt;!-- 內容 --\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 2. 邏輯區域 --\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; // 邏輯代碼 \u0026lt;/script\u0026gt; \u0026lt;!-- 3. 樣式區域 --\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; // 樣式代碼 \u0026lt;/style\u0026gt; 完整元件範例 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;user-card\u0026#34; :class=\u0026#34;cardClasses\u0026#34;\u0026gt; \u0026lt;!-- 頭像區域 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__avatar\u0026#34;\u0026gt; \u0026lt;img :src=\u0026#34;user.avatar || defaultAvatar\u0026#34; :alt=\u0026#34;`${user.name} 的頭像`\u0026#34; class=\u0026#34;user-card__avatar-img\u0026#34; @error=\u0026#34;handleImageError\u0026#34; /\u0026gt; \u0026lt;div v-if=\u0026#34;showStatus\u0026#34; class=\u0026#34;user-card__status\u0026#34; :class=\u0026#34;statusClass\u0026#34;\u0026gt; {{ statusText }} \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 使用者資訊 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__content\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;user-card__name\u0026#34;\u0026gt;{{ user.name }}\u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;user-card__email\u0026#34;\u0026gt;{{ user.email }}\u0026lt;/p\u0026gt; \u0026lt;!-- 標籤 --\u0026gt; \u0026lt;div v-if=\u0026#34;user.tags?.length\u0026#34; class=\u0026#34;user-card__tags\u0026#34;\u0026gt; \u0026lt;span v-for=\u0026#34;tag in user.tags\u0026#34; :key=\u0026#34;tag\u0026#34; class=\u0026#34;user-card__tag\u0026#34; \u0026gt; {{ tag }} \u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 動作按鈕 --\u0026gt; \u0026lt;div class=\u0026#34;user-card__actions\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleEdit\u0026#34; \u0026gt; 編輯 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; size=\u0026#34;small\u0026#34; :disabled=\u0026#34;loading\u0026#34; @click=\u0026#34;handleView\u0026#34; \u0026gt; 查看 \u0026lt;/BaseButton\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 載入狀態 --\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;user-card__loading\u0026#34;\u0026gt; \u0026lt;LoadingSpinner size=\u0026#34;small\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import { computed, ref } from \u0026#39;vue\u0026#39;; import BaseButton from \u0026#39;@/components/base/BaseButton.vue\u0026#39;; import LoadingSpinner from \u0026#39;@/components/base/LoadingSpinner.vue\u0026#39;; import { useI18n } from \u0026#39;vue-i18n\u0026#39;; import type { User } from \u0026#39;@/types/user\u0026#39;; // Props 定義 interface Props { user: User; variant?: \u0026#39;default\u0026#39; | \u0026#39;compact\u0026#39; | \u0026#39;detailed\u0026#39;; showStatus?: boolean; interactive?: boolean; } // Emits 定義 interface Emits { edit: [user: User]; view: [user: User]; \u0026#39;avatar-error\u0026#39;: [user: User]; } const props = withDefaults(defineProps\u0026lt;Props\u0026gt;(), { variant: \u0026#39;default\u0026#39;, showStatus: true, interactive: true, }); const emit = defineEmits\u0026lt;Emits\u0026gt;(); // Composables const { t } = useI18n(); // 響應式資料 const loading = ref(false); const defaultAvatar = \u0026#39;/images/default-avatar.png\u0026#39;; // 計算屬性 const cardClasses = computed(() =\u0026gt; ({ [`user-card--${props.variant}`]: true, \u0026#39;user-card--interactive\u0026#39;: props.interactive, \u0026#39;user-card--loading\u0026#39;: loading.value, })); const statusClass = computed(() =\u0026gt; ({ \u0026#39;user-card__status--online\u0026#39;: props.user.isOnline, \u0026#39;user-card__status--offline\u0026#39;: !props.user.isOnline, })); const statusText = computed(() =\u0026gt; { return props.user.isOnline ? t(\u0026#39;common.online\u0026#39;) : t(\u0026#39;common.offline\u0026#39;); }); // 方法 const handleEdit = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;edit\u0026#39;, props.user); }; const handleView = (): void =\u0026gt; { if (!props.interactive || loading.value) return; emit(\u0026#39;view\u0026#39;, props.user); }; const handleImageError = (): void =\u0026gt; { emit(\u0026#39;avatar-error\u0026#39;, props.user); }; \u0026lt;/script\u0026gt; \u0026lt;style scoped lang=\u0026#34;scss\u0026#34;\u0026gt; .user-card { @apply bg-white rounded-lg shadow-md p-4 transition-all duration-200; \u0026amp;--interactive { @apply hover:shadow-lg cursor-pointer; } \u0026amp;--loading { @apply opacity-50 pointer-events-none; } \u0026amp;__avatar { @apply relative flex-shrink-0; } \u0026amp;__avatar-img { @apply w-12 h-12 rounded-full object-cover; } \u0026amp;__status { @apply absolute -bottom-1 -right-1 px-2 py-1 text-xs rounded-full text-white; \u0026amp;--online { @apply bg-green-500; } \u0026amp;--offline { @apply bg-gray-400; } } \u0026amp;__content { @apply flex-1 ml-4; } \u0026amp;__name { @apply text-lg font-semibold text-gray-900 mb-1; } \u0026amp;__email { @apply text-sm text-gray-600 mb-2; } \u0026amp;__tags { @apply flex flex-wrap gap-1 mb-3; } \u0026amp;__tag { @apply px-2 py-1 text-xs bg-blue-100 text-blue-800 rounded; } \u0026amp;__actions { @apply flex gap-2; } \u0026amp;__loading { @apply absolute inset-0 flex items-center justify-center bg-white bg-opacity-75; } // 變體樣式 \u0026amp;--compact { @apply p-2; .user-card__avatar-img { @apply w-8 h-8; } .user-card__name { @apply text-base; } } \u0026amp;--detailed { @apply p-6; .user-card__avatar-img { @apply w-16 h-16; } } } \u0026lt;/style\u0026gt; 4.2 Props 設計規範 Props 型別定義 // ✅ 正確範例 - 完整的 Props 介面 interface ButtonProps { // 必要屬性 label: string; // 選擇性屬性with default values variant?: \u0026#39;primary\u0026#39; | \u0026#39;secondary\u0026#39; | \u0026#39;danger\u0026#39; | \u0026#39;ghost\u0026#39;; size?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; disabled?: boolean; loading?: boolean; // 複雜型別 icon?: { name: string; position: \u0026#39;left\u0026#39; | \u0026#39;right\u0026#39;; }; // 函式型別 onClick?: (event: MouseEvent) =\u0026gt; void; } const props = withDefaults(defineProps\u0026lt;ButtonProps\u0026gt;(), { variant: \u0026#39;primary\u0026#39;, size: \u0026#39;medium\u0026#39;, disabled: false, loading: false, }); Props 驗證 // ✅ 正確範例 - 執行時驗證 interface FormInputProps { modelValue: string; type?: \u0026#39;text\u0026#39; | \u0026#39;email\u0026#39; | \u0026#39;password\u0026#39; | \u0026#39;number\u0026#39;; placeholder?: string; required?: boolean; maxLength?: number; pattern?: string; validator?: (value: string) =\u0026gt; boolean | string; } const props = withDefaults(defineProps\u0026lt;FormInputProps\u0026gt;(), { type: \u0026#39;text\u0026#39;, required: false, }); // 自定義驗證邏輯 const isValid = computed(() =\u0026gt; { if (props.required \u0026amp;\u0026amp; !props.modelValue) { return false; } if (props.maxLength \u0026amp;\u0026amp; props.modelValue.length \u0026gt; props.maxLength) { return false; } if (props.pattern \u0026amp;\u0026amp; !new RegExp(props.pattern).test(props.modelValue)) { return false; } if (props.validator) { const result = props.validator(props.modelValue); return result === true; } return true; }); 4.3 Emits 事件規範 事件定義與觸發 // ✅ 正確範例 - 型別安全的事件定義 interface FormEmits { // v-model 雙向綁定 \u0026#39;update:modelValue\u0026#39;: [value: string]; // 表單事件 submit: [data: FormData]; cancel: []; // 驗證事件 \u0026#39;validation-error\u0026#39;: [errors: ValidationError[]]; \u0026#39;validation-success\u0026#39;: []; // 使用者互動事件 \u0026#39;field-focus\u0026#39;: [fieldName: string]; \u0026#39;field-blur\u0026#39;: [fieldName: string, value: string]; } const emit = defineEmits\u0026lt;FormEmits\u0026gt;(); // 事件觸發範例 const handleSubmit = (formData: FormData): void =\u0026gt; { // 驗證表單 const errors = validateForm(formData); if (errors.length \u0026gt; 0) { emit(\u0026#39;validation-error\u0026#39;, errors); return; } emit(\u0026#39;validation-success\u0026#39;); emit(\u0026#39;submit\u0026#39;, formData); }; const handleCancel = (): void =\u0026gt; { emit(\u0026#39;cancel\u0026#39;); }; // v-model 實作 const updateValue = (newValue: string): void =\u0026gt; { emit(\u0026#39;update:modelValue\u0026#39;, newValue); }; 4.4 Slots 使用規範 具名插槽設計 \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;header v-if=\u0026#34;$slots.header\u0026#34; class=\u0026#34;card__header\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;header\u0026#34; :title=\u0026#34;title\u0026#34; :subtitle=\u0026#34;subtitle\u0026#34; /\u0026gt; \u0026lt;/header\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;main class=\u0026#34;card__content\u0026#34;\u0026gt; \u0026lt;slot :data=\u0026#34;data\u0026#34; :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/main\u0026gt; \u0026lt;!-- 動作按鈕插槽 --\u0026gt; \u0026lt;footer v-if=\u0026#34;$slots.actions\u0026#34; class=\u0026#34;card__actions\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;actions\u0026#34; :save=\u0026#34;handleSave\u0026#34; :cancel=\u0026#34;handleCancel\u0026#34; :canSave=\u0026#34;canSave\u0026#34; /\u0026gt; \u0026lt;/footer\u0026gt; \u0026lt;!-- 條件式插槽 --\u0026gt; \u0026lt;div v-if=\u0026#34;$slots.sidebar\u0026#34; class=\u0026#34;card__sidebar\u0026#34;\u0026gt; \u0026lt;slot name=\u0026#34;sidebar\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { title?: string; subtitle?: string; data: any; loading?: boolean; } const props = defineProps\u0026lt;Props\u0026gt;(); // 計算屬性 const canSave = computed(() =\u0026gt; { return !props.loading \u0026amp;\u0026amp; isDataValid(props.data); }); // 提供給插槽的方法 const handleSave = (): void =\u0026gt; { // 儲存邏輯 }; const handleCancel = (): void =\u0026gt; { // 取消邏輯 }; \u0026lt;/script\u0026gt; 插槽使用範例 \u0026lt;template\u0026gt; \u0026lt;Card :data=\u0026#34;userData\u0026#34; :loading=\u0026#34;loading\u0026#34;\u0026gt; \u0026lt;!-- 標題插槽 --\u0026gt; \u0026lt;template #header=\u0026#34;{ title, subtitle }\u0026#34;\u0026gt; \u0026lt;h2\u0026gt;{{ title || \u0026#39;使用者資料\u0026#39; }}\u0026lt;/h2\u0026gt; \u0026lt;p v-if=\u0026#34;subtitle\u0026#34;\u0026gt;{{ subtitle }}\u0026lt;/p\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 預設內容插槽 --\u0026gt; \u0026lt;template #default=\u0026#34;{ data, loading }\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;!loading\u0026#34;\u0026gt; \u0026lt;UserForm :user=\u0026#34;data\u0026#34; @update=\u0026#34;handleUserUpdate\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;LoadingSpinner v-else /\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;!-- 動作插槽 --\u0026gt; \u0026lt;template #actions=\u0026#34;{ save, cancel, canSave }\u0026#34;\u0026gt; \u0026lt;BaseButton variant=\u0026#34;primary\u0026#34; :disabled=\u0026#34;!canSave\u0026#34; @click=\u0026#34;save\u0026#34; \u0026gt; 儲存 \u0026lt;/BaseButton\u0026gt; \u0026lt;BaseButton variant=\u0026#34;secondary\u0026#34; @click=\u0026#34;cancel\u0026#34; \u0026gt; 取消 \u0026lt;/BaseButton\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;/Card\u0026gt; \u0026lt;/template\u0026gt; 4.5 元件組合與複用 高階元件 (HOC) 模式 \u0026lt;!-- withLoading.vue - 高階元件 --\u0026gt; \u0026lt;template\u0026gt; \u0026lt;div class=\u0026#34;with-loading\u0026#34;\u0026gt; \u0026lt;div v-if=\u0026#34;loading\u0026#34; class=\u0026#34;loading-overlay\u0026#34;\u0026gt; \u0026lt;LoadingSpinner :size=\u0026#34;loadingSize\u0026#34; /\u0026gt; \u0026lt;p v-if=\u0026#34;loadingText\u0026#34;\u0026gt;{{ loadingText }}\u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div :class=\u0026#34;{ \u0026#39;is-loading\u0026#39;: loading }\u0026#34;\u0026gt; \u0026lt;slot :loading=\u0026#34;loading\u0026#34; /\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; interface Props { loading: boolean; loadingText?: string; loadingSize?: \u0026#39;small\u0026#39; | \u0026#39;medium\u0026#39; | \u0026#39;large\u0026#39;; } withDefaults(defineProps\u0026lt;Props\u0026gt;(), { loadingSize: \u0026#39;medium\u0026#39;, }); \u0026lt;/script\u0026gt; 組合式元件使用 \u0026lt;template\u0026gt; \u0026lt;WithLoading :loading=\u0026#34;isLoading\u0026#34; loading-text=\u0026#34;載入使用者資料中...\u0026#34;\u0026gt; \u0026lt;UserProfile :user=\u0026#34;userData\u0026#34; @edit=\u0026#34;handleEdit\u0026#34; @delete=\u0026#34;handleDelete\u0026#34; /\u0026gt; \u0026lt;/WithLoading\u0026gt; \u0026lt;/template\u0026gt; \u0026lt;script setup lang=\u0026#34;ts\u0026#34;\u0026gt; import WithLoading from \u0026#39;@/components/hoc/WithLoading.vue\u0026#39;; import UserProfile from \u0026#39;@/components/UserProfile.vue\u0026#39;; const isLoading = ref(false); const userData = ref(null); const handleEdit = (user: User): void =\u0026gt; { // 編輯邏輯 }; const handleDelete = (user: User): void =\u0026gt; { // 刪除邏輯 }; \u0026lt;/script\u0026gt; 5. 樣式與 Tailwind CSS 規範 5.1 Tailwind CSS 設定 tailwind.config.js 範例 /** @type {import(\u0026#39;tailwindcss\u0026#39;).Config} */ export default { content: [ \u0026#39;./index.html\u0026#39;, \u0026#39;./src/**/*.{vue,js,ts,jsx,tsx}\u0026#39;, ], theme: { extend: { // 顏色系統 colors: { primary: { 50: \u0026#39;#eff6ff\u0026#39;, 100: \u0026#39;#dbeafe\u0026#39;, 200: \u0026#39;#bfdbfe\u0026#39;, 300: \u0026#39;#93c5fd\u0026#39;, 400: \u0026#39;#60a5fa\u0026#39;, 500: \u0026#39;#3b82f6\u0026#39;, // 主要品牌色 600: \u0026#39;#2563eb\u0026#39;, 700: \u0026#39;#1d4ed8\u0026#39;, 800: \u0026#39;#1e40af\u0026#39;, 900: \u0026#39;#1e3a8a\u0026#39;, 950: \u0026#39;#172554\u0026#39;, }, secondary: { 50: \u0026#39;#f8fafc\u0026#39;, 500: \u0026#39;#64748b\u0026#39;, 900: \u0026#39;#0f172a\u0026#39;, }, success: { 50: \u0026#39;#f0fdf4\u0026#39;, 500: \u0026#39;#22c55e\u0026#39;, 900: \u0026#39;#14532d\u0026#39;, }, warning: { 50: \u0026#39;#fffbeb\u0026#39;, 500: \u0026#39;#f59e0b\u0026#39;, 900: \u0026#39;#78350f\u0026#39;, }, danger: { 50: \u0026#39;#fef2f2\u0026#39;, 500: \u0026#39;#ef4444\u0026#39;, 900: \u0026#39;#7f1d1d\u0026#39;, }, }, // 字型設定 fontFamily: { sans: [ \u0026#39;Noto Sans TC\u0026#39;, \u0026#39;Microsoft JhengHei\u0026#39;, \u0026#39;PingFang TC\u0026#39;, \u0026#39;Helvetica Neue\u0026#39;, \u0026#39;Arial\u0026#39;, \u0026#39;sans-serif\u0026#39;, ], }, // 響應式斷點 screens: { \u0026#39;xs\u0026#39;: \u0026#39;475px\u0026#39;, \u0026#39;sm\u0026#39;: \u0026#39;640px\u0026#39;, \u0026#39;md\u0026#39;: \u0026#39;768px\u0026#39;, \u0026#39;lg\u0026#39;: \u0026#39;1024px\u0026#39;, \u0026#39;xl\u0026#39;: \u0026#39;1280px\u0026#39;, \u0026#39;2xl\u0026#39;: \u0026#39;1536px\u0026#39;, }, }, }, plugins: [ require(\u0026#39;@tailwindcss/forms\u0026#39;), require(\u0026#39;@tailwindcss/typography\u0026#39;), ], }; 5.2 RWD 響應式設計原則 Mobile-First 設計策略 \u0026lt;template\u0026gt; \u0026lt;!-- 響應式網格系統 --\u0026gt; \u0026lt;div class=\u0026#34;container mx-auto px-4\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-4\u0026#34;\u0026gt; \u0026lt;div v-for=\u0026#34;item in items\u0026#34; :key=\u0026#34;item.id\u0026#34; class=\u0026#34;card\u0026#34;\u0026gt; \u0026lt;!-- 響應式圖片 --\u0026gt; \u0026lt;img :src=\u0026#34;item.image\u0026#34; :alt=\u0026#34;item.title\u0026#34; class=\u0026#34;w-full h-32 sm:h-40 lg:h-48 object-cover\u0026#34; /\u0026gt; \u0026lt;!-- 響應式文字 --\u0026gt; \u0026lt;div class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;h3 class=\u0026#34;text-lg sm:text-xl lg:text-2xl font-semibold\u0026#34;\u0026gt; {{ item.title }} \u0026lt;/h3\u0026gt; \u0026lt;p class=\u0026#34;text-sm sm:text-base text-gray-600\u0026#34;\u0026gt; {{ item.description }} \u0026lt;/p\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 響應式導航 --\u0026gt; \u0026lt;nav class=\u0026#34;bg-white shadow\u0026#34;\u0026gt; \u0026lt;!-- 桌面版導航 --\u0026gt; \u0026lt;div class=\u0026#34;hidden lg:flex items-center space-x-8 px-6 py-4\u0026#34;\u0026gt; \u0026lt;a v-for=\u0026#34;link in navLinks\u0026#34; :key=\u0026#34;link.path\u0026#34; :href=\u0026#34;link.path\u0026#34;\u0026gt; {{ link.title }} \u0026lt;/a\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;!-- 行動版選單 --\u0026gt; \u0026lt;div class=\u0026#34;lg:hidden\u0026#34;\u0026gt; \u0026lt;button @click=\u0026#34;toggleMobileMenu\u0026#34; class=\u0026#34;p-4\u0026#34;\u0026gt; \u0026lt;MenuIcon class=\u0026#34;w-6 h-6\u0026#34; /\u0026gt; \u0026lt;/button\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/nav\u0026gt; \u0026lt;/template\u0026gt; 5.3 顏色與主題設計 CSS 變數主題系統 :root { /* 品牌色 */ --color-primary: #3b82f6; --color-secondary: #64748b; /* 語意化顏色 */ --color-success: #22c55e; --color-warning: #f59e0b; --color-danger: #ef4444; /* 背景色 */ --bg-primary: #ffffff; --bg-secondary: #f8fafc; /* 文字色 */ --text-primary: #111827; --text-secondary: #4b5563; } /* 暗色主題 */ [data-theme=\u0026#34;dark\u0026#34;] { --bg-primary: #111827; --bg-secondary: #1f2937; --text-primary: #f9fafb; --text-secondary: #d1d5db; } 5.4 共用樣式元件 基礎元件樣式 @layer components { /* 按鈕樣式 */ .btn { @apply inline-flex items-center px-4 py-2 text-sm font-medium rounded-md transition-colors focus:outline-none focus:ring-2; } .btn-primary { @apply btn bg-primary-500 text-white hover:bg-primary-600; } .btn-secondary { @apply btn bg-gray-200 text-gray-900 hover:bg-gray-300; } /* 表單樣式 */ .form-input { @apply w-full px-3 py-2 border border-gray-300 rounded-md focus:ring-1 focus:ring-primary-500 focus:border-primary-500; } /* 卡片樣式 */ .card { @apply bg-white rounded-lg shadow-md p-4; } } 總結 本前端開發指引提供了完整的開發規範，涵蓋了專案結構、命名規範、程式撰寫風格、元件開發和樣式設計等核心面向。請開發團隊嚴格遵循這些規範，以確保程式碼品質和專案的可維護性。\n","title":""},{"content":"角色: 你是一個資深的系統架師,也是AP 性能調較高手 環境: OS : AIX, ap server:IBM WebSphere Liberty, datbase: db2, 使用sprint boot 開發, 壓測使用Jmeter 任務: 壓測一小時, 同時50人, 95% request 必需在3秒內完成, 請列出壓測應注意那些參數設定與調校 chatGPT 回答 好的 ✅ 以下我會用「資深系統架構師 \u0026amp; AP 性能調校高手」的角度，幫你整理 JMeter 壓測設定、Liberty 調校、DB2 調校、AIX/系統層級參數 四大面向，確保你的一小時壓測（50人同時、95% request \u0026lt; 3 秒）能達標。\n1. 壓測工具 (JMeter) 層 測試場景設計 Ramp-Up 時間：避免一次 50 人瞬間打進系統，建議 30–60 秒平滑增加，觀察系統穩態。\nThink Time：模擬使用者真實行為，避免「機械式打爆」；可設定 0.5–2 秒隨機等待。\n持續時間模式：壓測 60 分鐘，避免只測瞬間峰值。\n監控數據：\n95% 响應時間 Throughput (TPS) Error Rate DB2 Connection Pool 狀況 JVM Heap/GC 次數 JMeter 參數建議 非 GUI 模式執行（jmeter -n -t test.jmx -l result.jtl）\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%A3%93%E6%B8%AC%E6%8C%87%E5%BC%95/","summary":"角色: 你是一個資深的系統架師,也是AP 性能調較高手 環境: OS : AIX, ap server:IBM WebSphere Liberty, datbase: db2, 使用sprint boot 開發, 壓測使用Jmeter 任務: 壓測一小時, 同時50人, 95% request 必需在3秒內完成, 請列出壓測應注意那些參數設定與調校 chatGPT 回答 好的 ✅ 以下我會用「資深系統架構師 \u0026amp; AP 性能調校高手」的角度，幫你整理 JMeter 壓測設定、Liberty 調校、DB2 調校、AIX/系統層級參數 四大面向，確保你的一小時壓測（50人同時、95% request \u0026lt; 3 秒）能達標。\n1. 壓測工具 (JMeter) 層 測試場景設計 Ramp-Up 時間：避免一次 50 人瞬間打進系統，建議 30–60 秒平滑增加，觀察系統穩態。\nThink Time：模擬使用者真實行為，避免「機械式打爆」；可設定 0.5–2 秒隨機等待。\n持續時間模式：壓測 60 分鐘，避免只測瞬間峰值。\n監控數據：\n95% 响應時間 Throughput (TPS) Error Rate DB2 Connection Pool 狀況 JVM Heap/GC 次數 JMeter 參數建議 非 GUI 模式執行（jmeter -n -t test.jmx -l result.jtl）\n","title":""},{"content":"Gemini 回答 好的，作為一個資深的系統架構師與 AP 性能調校專家，我會為您提供一份在這次壓力測試中，從頭到尾、由外到內需要關注的參數設定與調校檢查清單。\n我們的目標非常明確：在 50 個併發用戶（Concurrent Users）持續加壓一小時的條件下，確保 95% 的請求（95th Percentile）回應時間在 3 秒以內。\n這是一個系統性的工程，我們需要從壓力來源、作業系統、應用伺服器、一直到資料庫，逐層分析與調校。\n核心調校哲學 建立基準 (Establish Baseline): 在進行任何調校之前，先用預設設定跑一次縮短版的壓力測試（例如 10-15 分鐘）。這個數據是你的黃金標準，所有的後續調校都必須跟這個基準線做比較，才能判斷是改善還是惡化。 一次只改一個參數 (Change One Thing at a Time): 這是最重要的原則。如果你一次改了三個參數，效能變好了，你不會知道是哪個參數起了作用。反之，如果效能變差，你也不知道是誰的錯。 監控是你的眼睛 (Monitoring is Key): 如果沒有監控，調校就如同矇著眼睛開車。你必須能夠即時看到 CPU、記憶體、網路、I/O、GC、執行緒等關鍵指標的變化。 第一層：壓力來源 (JMeter) 確保壓力測試工具本身不是瓶頸。\n參數/項目 建議與說明 啟動模式 絕對要使用命令列模式 (CLI Mode) 進行正式壓測，不要使用 GUI 模式。GUI 模式會消耗大量客戶端資源，影響測試準確性。指令範例：jmeter -n -t your_test_plan.jmx -l results.jtl JVM Heap Size 修改 jmeter.bat 或 jmeter.sh，調整 JMeter 的 JVM 堆疊大小。如果請求或回應的資料量大，預設的 1G 可能不夠。建議至少設為 HEAP=\u0026quot;-Xms2g -Xmx2g\u0026quot; 或更高，避免 JMeter 本身 OutOfMemory。 監聽器 (Listeners) 在正式壓測時，禁用或刪除所有 GUI 上的監聽器，如 \u0026ldquo;View Results Tree\u0026rdquo;、\u0026ldquo;Summary Report\u0026rdquo; 等。它們非常消耗資源。測試結束後，再用 results.jtl 檔來產生報告。 思考時間 (Think Time) 在請求之間加入合理的思考時間 (e.g., Uniform Random Timer)，模擬真實用戶行為。完全沒有思考時間的壓測會對伺服器造成不切實際的瞬間衝擊，可能無法反映真實場景的效能瓶頸。 分散式壓測 如果單台 JMeter 機器無法產生足夠的壓力（CPU/網路滿載），應考慮使用主從式 (Master-Slave) 的分散式架構來發動壓測。 第二層：作業系統 (AIX) AIX 有其獨特的監控與調校工具，是穩定運行的基礎。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%A3%93%E6%B8%AC%E6%8C%87%E5%BC%952/","summary":"Gemini 回答 好的，作為一個資深的系統架構師與 AP 性能調校專家，我會為您提供一份在這次壓力測試中，從頭到尾、由外到內需要關注的參數設定與調校檢查清單。\n我們的目標非常明確：在 50 個併發用戶（Concurrent Users）持續加壓一小時的條件下，確保 95% 的請求（95th Percentile）回應時間在 3 秒以內。\n這是一個系統性的工程，我們需要從壓力來源、作業系統、應用伺服器、一直到資料庫，逐層分析與調校。\n核心調校哲學 建立基準 (Establish Baseline): 在進行任何調校之前，先用預設設定跑一次縮短版的壓力測試（例如 10-15 分鐘）。這個數據是你的黃金標準，所有的後續調校都必須跟這個基準線做比較，才能判斷是改善還是惡化。 一次只改一個參數 (Change One Thing at a Time): 這是最重要的原則。如果你一次改了三個參數，效能變好了，你不會知道是哪個參數起了作用。反之，如果效能變差，你也不知道是誰的錯。 監控是你的眼睛 (Monitoring is Key): 如果沒有監控，調校就如同矇著眼睛開車。你必須能夠即時看到 CPU、記憶體、網路、I/O、GC、執行緒等關鍵指標的變化。 第一層：壓力來源 (JMeter) 確保壓力測試工具本身不是瓶頸。\n參數/項目 建議與說明 啟動模式 絕對要使用命令列模式 (CLI Mode) 進行正式壓測，不要使用 GUI 模式。GUI 模式會消耗大量客戶端資源，影響測試準確性。指令範例：jmeter -n -t your_test_plan.jmx -l results.jtl JVM Heap Size 修改 jmeter.bat 或 jmeter.sh，調整 JMeter 的 JVM 堆疊大小。如果請求或回應的資料量大，預設的 1G 可能不夠。建議至少設為 HEAP=\u0026quot;-Xms2g -Xmx2g\u0026quot; 或更高，避免 JMeter 本身 OutOfMemory。 監聽器 (Listeners) 在正式壓測時，禁用或刪除所有 GUI 上的監聽器，如 \u0026ldquo;View Results Tree\u0026rdquo;、\u0026ldquo;Summary Report\u0026rdquo; 等。它們非常消耗資源。測試結束後，再用 results.jtl 檔來產生報告。 思考時間 (Think Time) 在請求之間加入合理的思考時間 (e.g., Uniform Random Timer)，模擬真實用戶行為。完全沒有思考時間的壓測會對伺服器造成不切實際的瞬間衝擊，可能無法反映真實場景的效能瓶頸。 分散式壓測 如果單台 JMeter 機器無法產生足夠的壓力（CPU/網路滿載），應考慮使用主從式 (Master-Slave) 的分散式架構來發動壓測。 第二層：作業系統 (AIX) AIX 有其獨特的監控與調校工具，是穩定運行的基礎。\n","title":""},{"content":"安全程式碼指引 目錄 文件目的 通用安全開發原則 2.1 最小權限原則 2.2 輸入驗證 2.3 錯誤處理 2.4 加密使用原則 2.5 安全標頭設定 2.6 Session 與 Token 管理 程式語言安全指引 3.1 Java / Spring Boot 3.2 Python 3.3 JavaScript / TypeScript / Vue3 3.4 資料庫安全 OWASP Top 10 對應對策 4.1 A01:2021 – Broken Access Control (存取控制失效) 4.2 A02:2021 – Cryptographic Failures (加密失效) 4.3 A03:2021 – Injection (注入攻擊) 4.4 A04:2021 – Insecure Design (不安全設計) 4.5 A05:2021 – Security Misconfiguration (安全設定錯誤) 4.6 A06:2021 – Vulnerable Components (易受攻擊元件) 4.7 A07:2021 – Identification and Authentication Failures (識別與驗證失效) 4.8 A08:2021 – Software and Data Integrity Failures (軟體與資料完整性失效) 4.9 A09:2021 – Security Logging \u0026amp; Monitoring Failures (安全日誌與監控失效) 4.10 A10:2021 – Server-Side Request Forgery (SSRF) API 安全設計 5.1 RESTful API 安全 5.2 GraphQL 安全 5.3 API 版本控制與向後相容 5.4 API 速率限制與節流 容器化與雲端安全 6.1 Docker 安全 6.2 Kubernetes 安全 6.3 雲端服務安全 CI/CD 安全 7.1 代碼儲存庫安全 7.2 建構流程安全 7.3 部署安全 7.4 供應鏈安全 安全測試與驗證 8.1 靜態應用程式安全測試 (SAST) 8.2 動態應用程式安全測試 (DAST) 8.3 互動式應用程式安全測試 (IAST) 8.4 滲透測試 資料保護與隱私 9.1 個人資料保護 9.2 資料分類與標記 9.3 資料遮罩與匿名化 9.4 資料備份與復原 事件回應與復原 10.1 安全事件識別 10.2 事件回應流程 10.3 取證與證據保全 10.4 災難復原計畫 日常開發檢查清單 (Checklist) 11.1 每日開發檢查項目 11.2 Pull Request 檢查項目 11.3 部署前檢查項目 常見錯誤與反例 12.1 密碼處理錯誤 12.2 SQL 查詢錯誤 12.3 檔案上傳錯誤 12.4 前端 XSS 錯誤 12.5 權限控制錯誤 12.6 API 設計錯誤 12.7 配置錯誤 合規性與法規要求 13.1 GDPR 合規 13.2 個資法合規 13.3 PCI DSS 合規 13.4 SOX 合規 延伸資源 14.1 官方安全指引 14.2 程式語言特定資源 14.3 安全工具 14.4 學習資源 14.5 公司內部資源 1. 文件目的 安全程式碼的撰寫是每位開發者的基本職責。良好的安全設計不僅能保護公司與用戶資料，避免資安事件造成商譽損失與法律責任，也有助於符合法規（如 GDPR、個資法）及客戶合約要求。安全程式碼能降低維運成本、減少漏洞修補時間，讓業務更穩健發展。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%AE%89%E5%85%A8%E7%A8%8B%E5%BC%8F%E7%A2%BC%E6%8C%87%E5%BC%95/","summary":"安全程式碼指引 目錄 文件目的 通用安全開發原則 2.1 最小權限原則 2.2 輸入驗證 2.3 錯誤處理 2.4 加密使用原則 2.5 安全標頭設定 2.6 Session 與 Token 管理 程式語言安全指引 3.1 Java / Spring Boot 3.2 Python 3.3 JavaScript / TypeScript / Vue3 3.4 資料庫安全 OWASP Top 10 對應對策 4.1 A01:2021 – Broken Access Control (存取控制失效) 4.2 A02:2021 – Cryptographic Failures (加密失效) 4.3 A03:2021 – Injection (注入攻擊) 4.4 A04:2021 – Insecure Design (不安全設計) 4.5 A05:2021 – Security Misconfiguration (安全設定錯誤) 4.6 A06:2021 – Vulnerable Components (易受攻擊元件) 4.7 A07:2021 – Identification and Authentication Failures (識別與驗證失效) 4.8 A08:2021 – Software and Data Integrity Failures (軟體與資料完整性失效) 4.9 A09:2021 – Security Logging \u0026amp; Monitoring Failures (安全日誌與監控失效) 4.10 A10:2021 – Server-Side Request Forgery (SSRF) API 安全設計 5.1 RESTful API 安全 5.2 GraphQL 安全 5.3 API 版本控制與向後相容 5.4 API 速率限制與節流 容器化與雲端安全 6.1 Docker 安全 6.2 Kubernetes 安全 6.3 雲端服務安全 CI/CD 安全 7.1 代碼儲存庫安全 7.2 建構流程安全 7.3 部署安全 7.4 供應鏈安全 安全測試與驗證 8.1 靜態應用程式安全測試 (SAST) 8.2 動態應用程式安全測試 (DAST) 8.3 互動式應用程式安全測試 (IAST) 8.4 滲透測試 資料保護與隱私 9.1 個人資料保護 9.2 資料分類與標記 9.3 資料遮罩與匿名化 9.4 資料備份與復原 事件回應與復原 10.1 安全事件識別 10.2 事件回應流程 10.3 取證與證據保全 10.4 災難復原計畫 日常開發檢查清單 (Checklist) 11.1 每日開發檢查項目 11.2 Pull Request 檢查項目 11.3 部署前檢查項目 常見錯誤與反例 12.1 密碼處理錯誤 12.2 SQL 查詢錯誤 12.3 檔案上傳錯誤 12.4 前端 XSS 錯誤 12.5 權限控制錯誤 12.6 API 設計錯誤 12.7 配置錯誤 合規性與法規要求 13.1 GDPR 合規 13.2 個資法合規 13.3 PCI DSS 合規 13.4 SOX 合規 延伸資源 14.1 官方安全指引 14.2 程式語言特定資源 14.3 安全工具 14.4 學習資源 14.5 公司內部資源 1. 文件目的 安全程式碼的撰寫是每位開發者的基本職責。良好的安全設計不僅能保護公司與用戶資料，避免資安事件造成商譽損失與法律責任，也有助於符合法規（如 GDPR、個資法）及客戶合約要求。安全程式碼能降低維運成本、減少漏洞修補時間，讓業務更穩健發展。\n","title":""},{"content":"後端開發指引 目錄 開發原則 專案結構與命名規範 API 設計規範 資料庫存取與 ORM 規範 安全性規範 效能與擴展性指引 測試與品質保證 部署與維運指引 日誌管理與監控 資料驗證與清理 國際化與本地化 文件生成與 API 規範 第三方整合規範 程式碼審查與品質控制 依賴與配置管理 備份與災難恢復 1. 開發原則 1.1 架構模式 Clean Architecture 實作原則 依賴反轉原則：內層不依賴外層，外層依賴內層 單一職責原則：每個類別/模組只負責一個職責 開放封閉原則：對擴展開放，對修改封閉 介面隔離原則：使用者不應依賴不需要的介面 架構分層結構： ┌─────────────────────────────────────┐ │ Presentation Layer │ ← Controllers, DTOs ├─────────────────────────────────────┤ │ Application Layer │ ← Use Cases, Services ├─────────────────────────────────────┤ │ Domain Layer │ ← Entities, Repositories ├─────────────────────────────────────┤ │ Infrastructure Layer │ ← Database, External APIs └─────────────────────────────────────┘ 分層設計規範 Presentation Layer（表現層）\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E5%BE%8C%E7%AB%AF%E9%96%8B%E7%99%BC%E6%8C%87%E5%BC%95/","summary":"後端開發指引 目錄 開發原則 專案結構與命名規範 API 設計規範 資料庫存取與 ORM 規範 安全性規範 效能與擴展性指引 測試與品質保證 部署與維運指引 日誌管理與監控 資料驗證與清理 國際化與本地化 文件生成與 API 規範 第三方整合規範 程式碼審查與品質控制 依賴與配置管理 備份與災難恢復 1. 開發原則 1.1 架構模式 Clean Architecture 實作原則 依賴反轉原則：內層不依賴外層，外層依賴內層 單一職責原則：每個類別/模組只負責一個職責 開放封閉原則：對擴展開放，對修改封閉 介面隔離原則：使用者不應依賴不需要的介面 架構分層結構： ┌─────────────────────────────────────┐ │ Presentation Layer │ ← Controllers, DTOs ├─────────────────────────────────────┤ │ Application Layer │ ← Use Cases, Services ├─────────────────────────────────────┤ │ Domain Layer │ ← Entities, Repositories ├─────────────────────────────────────┤ │ Infrastructure Layer │ ← Database, External APIs └─────────────────────────────────────┘ 分層設計規範 Presentation Layer（表現層）\n","title":""},{"content":"系統架構設計指引 目錄 1. 架構設計原則\n1.1 設計核心原則 1.2 技術選型原則 1.3 架構品質屬性 2. 系統整體架構圖\n2.1 微服務拆分策略 2.2 API Gateway 設計 2.3 服務間通訊 2.4 服務網格架構 3. 前後端分離與微前端設計\n3.1 微前端架構 3.2 前端技術棧 3.3 響應式設計 (RWD) 3.4 多語系支援 4. 後端分層架構 (Clean Architecture)\n4.1 Clean Architecture 層級設計 4.2 目錄結構設計 4.3 依賴注入與配置 4.4 API 設計規範 5. 資料庫設計原則\n5.1 多資料庫支援策略 5.2 資料分片與讀寫分離 5.3 資料庫設計範例 5.4 資料遷移策略 6. 效能優化方案\n6.1 快取策略 6.2 快取配置範例 6.3 CDN 配置 6.4 非同步處理 6.5 負載平衡策略 6.6 效能基準測試 7. 高可用性與災難復原設計\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E6%9E%B6%E6%A7%8B%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"系統架構設計指引 目錄 1. 架構設計原則\n1.1 設計核心原則 1.2 技術選型原則 1.3 架構品質屬性 2. 系統整體架構圖\n2.1 微服務拆分策略 2.2 API Gateway 設計 2.3 服務間通訊 2.4 服務網格架構 3. 前後端分離與微前端設計\n3.1 微前端架構 3.2 前端技術棧 3.3 響應式設計 (RWD) 3.4 多語系支援 4. 後端分層架構 (Clean Architecture)\n4.1 Clean Architecture 層級設計 4.2 目錄結構設計 4.3 依賴注入與配置 4.4 API 設計規範 5. 資料庫設計原則\n5.1 多資料庫支援策略 5.2 資料分片與讀寫分離 5.3 資料庫設計範例 5.4 資料遷移策略 6. 效能優化方案\n6.1 快取策略 6.2 快取配置範例 6.3 CDN 配置 6.4 非同步處理 6.5 負載平衡策略 6.6 效能基準測試 7. 高可用性與災難復原設計\n","title":""},{"content":"測試與品質保證指引 適用對象: 新進專案成員、開發人員、測試人員\n文件目的: 快速理解專案的測試流程與品質保證規範\n更新日期: 2025年8月27日\n目錄 測試與品質保證的角色與責任 測試流程與各階段 測試計畫與測試案例設計 測試自動化與工具建議 缺陷管理流程 測試品質指標與衡量方式 測試與 CI/CD、版本控管、DevOps 的關聯 安全性測試與合規性驗證 效能測試與效能調校 測試資料管理與隱私保護 跨瀏覽器與跨平台測試 API 測試與微服務測試策略 常見錯誤與避免方式 新進成員的最佳實務與建議 測試與品質保證檢查清單 測試成本效益分析與 ROI 評估 團隊協作與溝通 1. 測試與品質保證的角色與責任 1.1 開發人員職責 主要責任 撰寫單元測試: 為每個新功能撰寫對應的單元測試 程式碼審查: 檢視同事的程式碼，確保品質標準 修復缺陷: 及時修復測試中發現的問題 文件維護: 更新技術文件和 API 說明 具體工作項目 ✅ 每個方法都有對應的單元測試 ✅ 程式碼覆蓋率達到 80% 以上 ✅ 遵循程式碼風格指引 ✅ 提交前執行本地測試 1.2 測試人員職責 主要責任 測試案例設計: 根據需求規格設計完整的測試案例 執行測試: 進行系統測試、整合測試、使用者驗收測試 缺陷追蹤: 記錄、追蹤並驗證缺陷修復 測試報告: 提供測試結果分析和品質評估 具體工作項目 ✅ 設計邊界值和異常情況測試 ✅ 執行回歸測試確保功能穩定 ✅ 驗證非功能性需求（效能、安全性） ✅ 提供測試執行報告 1.3 專案經理職責 主要責任 資源規劃: 安排測試時程和人力資源 風險管控: 識別並管理測試相關風險 品質監控: 監控專案整體品質指標 溝通協調: 協調開發、測試、業務單位間的合作 1.4 實務案例 案例一：銀行系統開發 情境：開發線上轉帳功能 - 開發人員：撰寫轉帳邏輯單元測試 - 測試人員：設計轉帳金額邊界值測試（0元、負數、超過限額） - 專案經理：確保測試覆蓋金管會法規要求 案例二：API 開發 情境：開發客戶資料查詢 API - 開發人員：測試 API 回應格式和錯誤處理 - 測試人員：驗證 API 安全性和效能 - 專案經理：確保符合個資保護規範 1.5 注意事項 ⚠️ 重要提醒\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E6%B8%AC%E8%A9%A6%E8%88%87%E5%93%81%E8%B3%AA%E4%BF%9D%E8%AD%89%E6%8C%87%E5%BC%95/","summary":"測試與品質保證指引 適用對象: 新進專案成員、開發人員、測試人員\n文件目的: 快速理解專案的測試流程與品質保證規範\n更新日期: 2025年8月27日\n目錄 測試與品質保證的角色與責任 測試流程與各階段 測試計畫與測試案例設計 測試自動化與工具建議 缺陷管理流程 測試品質指標與衡量方式 測試與 CI/CD、版本控管、DevOps 的關聯 安全性測試與合規性驗證 效能測試與效能調校 測試資料管理與隱私保護 跨瀏覽器與跨平台測試 API 測試與微服務測試策略 常見錯誤與避免方式 新進成員的最佳實務與建議 測試與品質保證檢查清單 測試成本效益分析與 ROI 評估 團隊協作與溝通 1. 測試與品質保證的角色與責任 1.1 開發人員職責 主要責任 撰寫單元測試: 為每個新功能撰寫對應的單元測試 程式碼審查: 檢視同事的程式碼，確保品質標準 修復缺陷: 及時修復測試中發現的問題 文件維護: 更新技術文件和 API 說明 具體工作項目 ✅ 每個方法都有對應的單元測試 ✅ 程式碼覆蓋率達到 80% 以上 ✅ 遵循程式碼風格指引 ✅ 提交前執行本地測試 1.2 測試人員職責 主要責任 測試案例設計: 根據需求規格設計完整的測試案例 執行測試: 進行系統測試、整合測試、使用者驗收測試 缺陷追蹤: 記錄、追蹤並驗證缺陷修復 測試報告: 提供測試結果分析和品質評估 具體工作項目 ✅ 設計邊界值和異常情況測試 ✅ 執行回歸測試確保功能穩定 ✅ 驗證非功能性需求（效能、安全性） ✅ 提供測試執行報告 1.3 專案經理職責 主要責任 資源規劃: 安排測試時程和人力資源 風險管控: 識別並管理測試相關風險 品質監控: 監控專案整體品質指標 溝通協調: 協調開發、測試、業務單位間的合作 1.4 實務案例 案例一：銀行系統開發 情境：開發線上轉帳功能 - 開發人員：撰寫轉帳邏輯單元測試 - 測試人員：設計轉帳金額邊界值測試（0元、負數、超過限額） - 專案經理：確保測試覆蓋金管會法規要求 案例二：API 開發 情境：開發客戶資料查詢 API - 開發人員：測試 API 回應格式和錯誤處理 - 測試人員：驗證 API 安全性和效能 - 專案經理：確保符合個資保護規範 1.5 注意事項 ⚠️ 重要提醒\n","title":""},{"content":"程式寫作指引 目錄 前言 程式碼風格與命名規範 1.1 Java 命名規範 1.2 TypeScript/JavaScript 命名規範 1.3 程式碼格式化 1.4 實務案例與注意事項 註解與文件撰寫 2.1 JavaDoc 註解規範 2.2 TypeScript JSDoc 註解 2.3 程式碼內註解最佳實踐 2.4 API 文件撰寫 2.5 Vue 元件註解 2.6 實務案例與注意事項 錯誤處理與日誌紀錄 3.1 例外處理最佳實踐 3.2 日誌記錄最佳實踐 3.3 監控與告警設定 3.4 實務案例與注意事項 單元測試與TDD 4.1 JUnit 5 測試規範 4.2 TypeScript/Jest 測試規範 4.3 測試驅動開發（TDD）流程 4.4 測試覆蓋率與品質指標 4.5 實務案例與注意事項 安全性考量 5.1 輸入驗證與資料清理 5.2 認證和授權 5.3 XSS 攻擊防護 5.4 CSRF 攻擊防護 5.5 敏感資料處理 5.6 安全標頭配置 Spring Boot 常用功能實踐 6.1 JWT (JSON Web Token) 認證授權 6.2 Spring Data JPA 最佳實踐 6.3 Spring Batch 批次處理 6.4 Spring Cache 快取管理 6.5 Spring Boot 配置管理 資料庫設計與操作 7.1 資料庫設計原則 7.2 SQL 查詢優化 7.3 事務管理 7.4 資料遷移策略 7.5 資料庫監控與維護 效能優化 8.1 Java 應用程式效能優化 8.2 Spring Boot 效能調優 8.3 前端效能優化 8.4 快取策略優化 8.5 監控和指標 8.6 效能測試 8.7 效能優化檢查清單 容器化與DevOps 9.1 Docker 容器化實踐 9.2 CI/CD 流水線設計 9.3 Kubernetes 部署策略 9.4 基礎設施即代碼 9.5 監控與日誌聚合 微服務架構 10.1 微服務設計原則 10.2 服務間通信 10.3 分散式事務處理 10.4 服務發現與負載均衡 10.5 API Gateway 設計 版本控制 11.1 Git 工作流程規範 11.2 提交訊息規範 11.3 代碼審查流程 11.4 分支保護和自動化 11.5 版本標記和發布 11.6 協作最佳實踐 11.7 版本控制檢查清單 最佳實踐總結 12.1 開發生命週期最佳實踐 12.2 程式碼品質標準 12.3 測試策略總覽 12.4 效能監控最佳實踐 12.5 部署和運維最佳實踐 12.6 持續改進流程 12.7 團隊協作指南 12.8 總結與展望 前言 本指引旨在幫助開發團隊撰寫高品質、可維護且安全的程式碼。無論您是剛入行的新進開發人員，還是經驗豐富的資深工程師，都可以透過這份指引提升程式設計技能，並確保專案的長期成功。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%A8%8B%E5%BC%8F%E5%AF%AB%E4%BD%9C%E6%8C%87%E5%BC%95/","summary":"程式寫作指引 目錄 前言 程式碼風格與命名規範 1.1 Java 命名規範 1.2 TypeScript/JavaScript 命名規範 1.3 程式碼格式化 1.4 實務案例與注意事項 註解與文件撰寫 2.1 JavaDoc 註解規範 2.2 TypeScript JSDoc 註解 2.3 程式碼內註解最佳實踐 2.4 API 文件撰寫 2.5 Vue 元件註解 2.6 實務案例與注意事項 錯誤處理與日誌紀錄 3.1 例外處理最佳實踐 3.2 日誌記錄最佳實踐 3.3 監控與告警設定 3.4 實務案例與注意事項 單元測試與TDD 4.1 JUnit 5 測試規範 4.2 TypeScript/Jest 測試規範 4.3 測試驅動開發（TDD）流程 4.4 測試覆蓋率與品質指標 4.5 實務案例與注意事項 安全性考量 5.1 輸入驗證與資料清理 5.2 認證和授權 5.3 XSS 攻擊防護 5.4 CSRF 攻擊防護 5.5 敏感資料處理 5.6 安全標頭配置 Spring Boot 常用功能實踐 6.1 JWT (JSON Web Token) 認證授權 6.2 Spring Data JPA 最佳實踐 6.3 Spring Batch 批次處理 6.4 Spring Cache 快取管理 6.5 Spring Boot 配置管理 資料庫設計與操作 7.1 資料庫設計原則 7.2 SQL 查詢優化 7.3 事務管理 7.4 資料遷移策略 7.5 資料庫監控與維護 效能優化 8.1 Java 應用程式效能優化 8.2 Spring Boot 效能調優 8.3 前端效能優化 8.4 快取策略優化 8.5 監控和指標 8.6 效能測試 8.7 效能優化檢查清單 容器化與DevOps 9.1 Docker 容器化實踐 9.2 CI/CD 流水線設計 9.3 Kubernetes 部署策略 9.4 基礎設施即代碼 9.5 監控與日誌聚合 微服務架構 10.1 微服務設計原則 10.2 服務間通信 10.3 分散式事務處理 10.4 服務發現與負載均衡 10.5 API Gateway 設計 版本控制 11.1 Git 工作流程規範 11.2 提交訊息規範 11.3 代碼審查流程 11.4 分支保護和自動化 11.5 版本標記和發布 11.6 協作最佳實踐 11.7 版本控制檢查清單 最佳實踐總結 12.1 開發生命週期最佳實踐 12.2 程式碼品質標準 12.3 測試策略總覽 12.4 效能監控最佳實踐 12.5 部署和運維最佳實踐 12.6 持續改進流程 12.7 團隊協作指南 12.8 總結與展望 前言 本指引旨在幫助開發團隊撰寫高品質、可維護且安全的程式碼。無論您是剛入行的新進開發人員，還是經驗豐富的資深工程師，都可以透過這份指引提升程式設計技能，並確保專案的長期成功。\n","title":""},{"content":"專案系統設計指引 文件資訊 文件名稱: 專案系統設計指引 文件版本: v1.1 建立日期: 2025-01-11 更新日期: 2025-08-29 適用範圍: 大型共用平台開發專案 目錄 概述\n1.1 指引目的 1.2 適用範圍 1.3 設計原則 1.4 物件導向設計原則 1.4.1 SOLID 原則 1.4.2 物件導向設計方法論 系統架構設計\n2.1 整體架構概覽 2.2 分層架構設計 2.2.1 前端層架構 2.2.2 後端層架構 (Clean Architecture) 2.2.3 領域驅動設計 (DDD) 架構模式 2.2.4 六角形架構 (Hexagonal Architecture) 2.3 微服務拆分原則 2.4 API Gateway 設計 2.5 CDN 與快取策略 模組與服務設計\n3.1 服務設計原則 3.1.1 單一職責原則 3.1.2 服務自治性 3.1.3 物件導向設計模式應用 3.2 服務間通訊設計 3.3 資料流設計 資料庫設計\n4.1 資料模型設計規範 4.2 多資料庫支援策略 4.2.1 資料庫抽象層 4.2.2 物件關聯映射 (ORM) 設計模式 4.2.3 分庫分表策略 4.3 讀寫分離設計 4.4 資料安全與加密 安全性設計\n5.1 認證與授權機制 5.1.1 OAuth 2.0 + OpenID Connect 整合 5.1.2 JWT Token 設計 5.1.3 RBAC (Role-Based Access Control) 設計 5.1.4 安全設計模式 5.2 API 安全設計 5.3 OWASP Top 10 防護策略 整合與介接設計\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"專案系統設計指引 文件資訊 文件名稱: 專案系統設計指引 文件版本: v1.1 建立日期: 2025-01-11 更新日期: 2025-08-29 適用範圍: 大型共用平台開發專案 目錄 概述\n1.1 指引目的 1.2 適用範圍 1.3 設計原則 1.4 物件導向設計原則 1.4.1 SOLID 原則 1.4.2 物件導向設計方法論 系統架構設計\n2.1 整體架構概覽 2.2 分層架構設計 2.2.1 前端層架構 2.2.2 後端層架構 (Clean Architecture) 2.2.3 領域驅動設計 (DDD) 架構模式 2.2.4 六角形架構 (Hexagonal Architecture) 2.3 微服務拆分原則 2.4 API Gateway 設計 2.5 CDN 與快取策略 模組與服務設計\n3.1 服務設計原則 3.1.1 單一職責原則 3.1.2 服務自治性 3.1.3 物件導向設計模式應用 3.2 服務間通訊設計 3.3 資料流設計 資料庫設計\n4.1 資料模型設計規範 4.2 多資料庫支援策略 4.2.1 資料庫抽象層 4.2.2 物件關聯映射 (ORM) 設計模式 4.2.3 分庫分表策略 4.3 讀寫分離設計 4.4 資料安全與加密 安全性設計\n5.1 認證與授權機制 5.1.1 OAuth 2.0 + OpenID Connect 整合 5.1.2 JWT Token 設計 5.1.3 RBAC (Role-Based Access Control) 設計 5.1.4 安全設計模式 5.2 API 安全設計 5.3 OWASP Top 10 防護策略 整合與介接設計\n","title":""},{"content":"銀行大型共用平台 - 資料庫設計指引 文件資訊 文件名稱: 資料庫設計指引 版本: 2.0 建立日期: 2025-08-11 最後更新: 2025-08-29 作者: 資料庫架構師 適用範圍: 銀行大型共用平台專案 目錄 資料庫命名規範 欄位設計準則 主鍵、外鍵與唯一鍵設計規範 索引策略 資料分區與分表策略 資料庫正規化與反正規化設計 資料安全規範 資料庫版本控管與變更管理方法 性能調校原則與監控方法 資料庫備份與災難復原計劃 資料庫容量規劃 資料庫升級與遷移策略 資料庫日誌管理 資料庫測試與驗證 資料庫文件與註解 資料庫自動化與工具 資料庫監控與維護 資料庫性能測試 資料治理與品質管理 多租戶架構設計 雲端資料庫設計指引 資料庫DevOps實踐 法規遵循與合規要求 資料庫最佳實務總結 結論與未來發展 1. 資料庫命名規範 1.1 資料庫命名規範 原則: 使用英文、數字和底線，避免特殊字元 格式: {系統代碼}_{環境代碼}_DB 範例: BANK_PROD_DB、BANK_TEST_DB、BANK_DEV_DB 1.2 Schema 命名規範 原則: 依據功能模組或業務領域命名 格式: {模組代碼}_{功能代碼} 範例: CORE_ACCOUNT (核心帳戶) LOAN_MGMT (放款管理) RISK_CONTROL (風險控制) AUDIT_LOG (稽核日誌) 1.3 Table 命名規範 原則: 使用單數名詞，英文大寫，底線分隔 格式: {模組前綴}_{業務實體} 範例: ACC_CUSTOMER (客戶資料) LOAN_APPLICATION (放款申請) TXN_JOURNAL (交易日誌) 1.4 Column 命名規範 原則: 英文大寫，底線分隔，含義明確 通用欄位: ID - 主鍵 CREATED_DATE - 建立時間 CREATED_BY - 建立者 UPDATED_DATE - 更新時間 UPDATED_BY - 更新者 VERSION - 版本號 STATUS - 狀態 1.5 Index 命名規範 主鍵索引: PK_{表格名稱} 一般索引: IDX_{表格名稱}_{欄位名稱} 唯一索引: UK_{表格名稱}_{欄位名稱} 外鍵索引: FK_{表格名稱}_{參考表格名稱} 1.6 View 命名規範 格式: V_{模組前綴}_{功能描述} 範例: V_ACC_CUSTOMER_SUMMARY 1.7 Function 命名規範 格式: FN_{模組前綴}_{功能描述} 範例: FN_CORE_CALC_INTEREST 1.8 Trigger 命名規範 格式: TRG_{表格名稱}_{觸發時機}_{動作} 範例: TRG_ACC_CUSTOMER_BEFORE_UPDATE 2. 欄位設計準則 2.1 資料型別選擇原則 2.1.1 數值型別 用途 Oracle DB2 SQL Server PostgreSQL 整數 NUMBER(10) INTEGER INT INTEGER 長整數 NUMBER(19) BIGINT BIGINT BIGINT 金額 NUMBER(15,2) DECIMAL(15,2) DECIMAL(15,2) DECIMAL(15,2) 百分比 NUMBER(5,4) DECIMAL(5,4) DECIMAL(5,4) DECIMAL(5,4) 2.1.2 字串型別 用途 Oracle DB2 SQL Server PostgreSQL 固定長度 CHAR(n) CHAR(n) CHAR(n) CHAR(n) 變動長度 VARCHAR2(n) VARCHAR(n) VARCHAR(n) VARCHAR(n) 大文字 CLOB CLOB TEXT TEXT 2.1.3 日期時間型別 用途 Oracle DB2 SQL Server PostgreSQL 日期 DATE DATE DATE DATE 日期時間 TIMESTAMP TIMESTAMP DATETIME2 TIMESTAMP 時間戳記 TIMESTAMP(6) TIMESTAMP(6) DATETIME2(6) TIMESTAMP(6) 2.2 長度設計標準 客戶姓名: VARCHAR(100) 客戶ID: VARCHAR(20) 帳號: VARCHAR(20) 電話: VARCHAR(20) 地址: VARCHAR(200) 電子郵件: VARCHAR(100) 備註: VARCHAR(500) 2.3 NULL 值設計原則 不允許 NULL 的欄位:\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E8%A8%AD%E8%A8%88%E9%96%8B%E7%99%BC/%E8%B3%87%E6%96%99%E5%BA%AB%E8%A8%AD%E8%A8%88%E6%8C%87%E5%BC%95/","summary":"銀行大型共用平台 - 資料庫設計指引 文件資訊 文件名稱: 資料庫設計指引 版本: 2.0 建立日期: 2025-08-11 最後更新: 2025-08-29 作者: 資料庫架構師 適用範圍: 銀行大型共用平台專案 目錄 資料庫命名規範 欄位設計準則 主鍵、外鍵與唯一鍵設計規範 索引策略 資料分區與分表策略 資料庫正規化與反正規化設計 資料安全規範 資料庫版本控管與變更管理方法 性能調校原則與監控方法 資料庫備份與災難復原計劃 資料庫容量規劃 資料庫升級與遷移策略 資料庫日誌管理 資料庫測試與驗證 資料庫文件與註解 資料庫自動化與工具 資料庫監控與維護 資料庫性能測試 資料治理與品質管理 多租戶架構設計 雲端資料庫設計指引 資料庫DevOps實踐 法規遵循與合規要求 資料庫最佳實務總結 結論與未來發展 1. 資料庫命名規範 1.1 資料庫命名規範 原則: 使用英文、數字和底線，避免特殊字元 格式: {系統代碼}_{環境代碼}_DB 範例: BANK_PROD_DB、BANK_TEST_DB、BANK_DEV_DB 1.2 Schema 命名規範 原則: 依據功能模組或業務領域命名 格式: {模組代碼}_{功能代碼} 範例: CORE_ACCOUNT (核心帳戶) LOAN_MGMT (放款管理) RISK_CONTROL (風險控制) AUDIT_LOG (稽核日誌) 1.3 Table 命名規範 原則: 使用單數名詞，英文大寫，底線分隔 格式: {模組前綴}_{業務實體} 範例: ACC_CUSTOMER (客戶資料) LOAN_APPLICATION (放款申請) TXN_JOURNAL (交易日誌) 1.4 Column 命名規範 原則: 英文大寫，底線分隔，含義明確 通用欄位: ID - 主鍵 CREATED_DATE - 建立時間 CREATED_BY - 建立者 UPDATED_DATE - 更新時間 UPDATED_BY - 更新者 VERSION - 版本號 STATUS - 狀態 1.5 Index 命名規範 主鍵索引: PK_{表格名稱} 一般索引: IDX_{表格名稱}_{欄位名稱} 唯一索引: UK_{表格名稱}_{欄位名稱} 外鍵索引: FK_{表格名稱}_{參考表格名稱} 1.6 View 命名規範 格式: V_{模組前綴}_{功能描述} 範例: V_ACC_CUSTOMER_SUMMARY 1.7 Function 命名規範 格式: FN_{模組前綴}_{功能描述} 範例: FN_CORE_CALC_INTEREST 1.8 Trigger 命名規範 格式: TRG_{表格名稱}_{觸發時機}_{動作} 範例: TRG_ACC_CUSTOMER_BEFORE_UPDATE 2. 欄位設計準則 2.1 資料型別選擇原則 2.1.1 數值型別 用途 Oracle DB2 SQL Server PostgreSQL 整數 NUMBER(10) INTEGER INT INTEGER 長整數 NUMBER(19) BIGINT BIGINT BIGINT 金額 NUMBER(15,2) DECIMAL(15,2) DECIMAL(15,2) DECIMAL(15,2) 百分比 NUMBER(5,4) DECIMAL(5,4) DECIMAL(5,4) DECIMAL(5,4) 2.1.2 字串型別 用途 Oracle DB2 SQL Server PostgreSQL 固定長度 CHAR(n) CHAR(n) CHAR(n) CHAR(n) 變動長度 VARCHAR2(n) VARCHAR(n) VARCHAR(n) VARCHAR(n) 大文字 CLOB CLOB TEXT TEXT 2.1.3 日期時間型別 用途 Oracle DB2 SQL Server PostgreSQL 日期 DATE DATE DATE DATE 日期時間 TIMESTAMP TIMESTAMP DATETIME2 TIMESTAMP 時間戳記 TIMESTAMP(6) TIMESTAMP(6) DATETIME2(6) TIMESTAMP(6) 2.2 長度設計標準 客戶姓名: VARCHAR(100) 客戶ID: VARCHAR(20) 帳號: VARCHAR(20) 電話: VARCHAR(20) 地址: VARCHAR(200) 電子郵件: VARCHAR(100) 備註: VARCHAR(500) 2.3 NULL 值設計原則 不允許 NULL 的欄位:\n","title":""},{"content":"客戶需求訪談與分析技巧指引 文件資訊 文件版本：1.0 建立日期：2025年8月13日 目標讀者：新進專案經理（0-2年經驗） 適用範圍：金融、IT與大型系統整合專案 目錄 前言 前置準備 訪談進行技巧 訪談紀錄與整理 需求分析方法 需求驗證與確認 跨文化與遠端訪談技巧 數位化工具應用 品質控制與持續改善 常見錯誤與避免方法 實際案例分析 附錄 參考資料 1. 前言 1.1 指引目的 本指引旨在協助新進專案經理掌握客戶需求訪談與分析的核心技巧，提升專案成功率並降低需求變更風險。\n1.2 需求訪談的重要性 專案成功關鍵：85% 的專案失敗源於需求理解不足或溝通不良 成本控制：前期準確的需求分析可降低後期變更成本達 10-100 倍 客戶滿意度：清楚的需求理解是客戶滿意度的基礎 1.3 適用情境 新專案啟動階段的需求收集 現有系統功能擴充或改版 系統整合專案的介面需求確認 使用者體驗改善專案 2. 前置準備 2.1 訪談前資料蒐集 2.1.1 必要資料清單 組織架構資料\n客戶組織圖與部門職掌 關鍵決策者與影響者清單 內部溝通流程與層級關係 業務背景資料\n客戶業務模式與營運流程 現有系統架構與使用狀況 過去類似專案的經驗與學習 技術環境資料\n現有 IT 基礎架構 技術標準與限制條件 資安與合規要求 實務案例：在銀行核心系統專案中，PM 提前了解該行的組織架構，發現風險管理部門在系統需求上有關鍵決策權，因此將其納入主要訪談對象，避免後期需求變更。\n2.1.2 資料蒐集管道 正式管道\n客戶提供的 RFP（Request for Proposal）文件 組織年報與公開資訊 官方網站與產品說明文件 非正式管道\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E5%AE%A2%E6%88%B6%E9%9C%80%E6%B1%82%E8%A8%AA%E8%AB%87%E8%88%87%E5%88%86%E6%9E%90%E6%8A%80%E5%B7%A7/","summary":"客戶需求訪談與分析技巧指引 文件資訊 文件版本：1.0 建立日期：2025年8月13日 目標讀者：新進專案經理（0-2年經驗） 適用範圍：金融、IT與大型系統整合專案 目錄 前言 前置準備 訪談進行技巧 訪談紀錄與整理 需求分析方法 需求驗證與確認 跨文化與遠端訪談技巧 數位化工具應用 品質控制與持續改善 常見錯誤與避免方法 實際案例分析 附錄 參考資料 1. 前言 1.1 指引目的 本指引旨在協助新進專案經理掌握客戶需求訪談與分析的核心技巧，提升專案成功率並降低需求變更風險。\n1.2 需求訪談的重要性 專案成功關鍵：85% 的專案失敗源於需求理解不足或溝通不良 成本控制：前期準確的需求分析可降低後期變更成本達 10-100 倍 客戶滿意度：清楚的需求理解是客戶滿意度的基礎 1.3 適用情境 新專案啟動階段的需求收集 現有系統功能擴充或改版 系統整合專案的介面需求確認 使用者體驗改善專案 2. 前置準備 2.1 訪談前資料蒐集 2.1.1 必要資料清單 組織架構資料\n客戶組織圖與部門職掌 關鍵決策者與影響者清單 內部溝通流程與層級關係 業務背景資料\n客戶業務模式與營運流程 現有系統架構與使用狀況 過去類似專案的經驗與學習 技術環境資料\n現有 IT 基礎架構 技術標準與限制條件 資安與合規要求 實務案例：在銀行核心系統專案中，PM 提前了解該行的組織架構，發現風險管理部門在系統需求上有關鍵決策權，因此將其納入主要訪談對象，避免後期需求變更。\n2.1.2 資料蒐集管道 正式管道\n客戶提供的 RFP（Request for Proposal）文件 組織年報與公開資訊 官方網站與產品說明文件 非正式管道\n","title":""},{"content":"專案系統分析指引 目錄 系統分析階段目標與產出物 需求收集與分析流程 涉及角色與職責 系統分析方法與工具 4.1 UML 建模方法 4.2 資料流程圖 (DFD) 4.3 實體關係圖 (ERD) 4.4 物件導向分析方法 (OOA) 4.5 狀態圖 4.6 分析模型整合 跨系統整合分析 安全與合規考量 版本控管與審核流程 範例與模板 8.1 需求規格書模板 8.2 用例描述表模板 8.3 物件導向分析模板 8.4 系統功能列表模板 8.5 需求變更申請表模板 總結與最佳實踐 敏捷開發環境下的系統分析 數據驅動的需求分析 雲端架構考量 國際化與在地化需求 效能與容量規劃 災難恢復與營運連續性 附錄 文件資訊 文件名稱：專案系統分析指引 版本：2.0 建立日期：2025年8月11日 最後更新：2025年8月29日 適用專案：大型共用平台系統 技術架構：前後端分離 + Clean Architecture + 雲端原生 1. 系統分析階段目標與產出物 1.1 階段目標 系統分析階段是軟體開發生命週期中的關鍵環節，主要目標包括：\n需求理解與定義：深入理解業務需求，並將其轉化為明確的系統需求 系統邊界確立：明確定義系統的範圍、功能邊界與非功能需求 風險識別與評估：識別技術風險、業務風險及安全風險 可行性分析：評估技術可行性、經濟可行性與時程可行性 架構規劃基礎：為後續的系統設計階段提供清晰的需求基礎 1.2 工作範圍 1.2.1 業務分析範圍 現有系統分析與問題識別 業務流程梳理與優化建議 利害關係人需求收集 業務規則定義與驗證 使用者體驗需求分析 1.2.2 技術分析範圍 系統功能需求分析 非功能需求定義（效能、安全、可用性等） 系統整合需求分析 資料流程與資料模型分析 介面需求定義 1.2.3 安全分析範圍 威脅建模與風險評估 安全需求定義 合規要求分析 資料保護需求 存取控制需求 1.3 主要產出物清單 1.3.1 需求文件 業務需求規格書 (Business Requirements Specification, BRS) 系統需求規格書 (System Requirements Specification, SRS) 功能需求規格書 (Functional Requirements Specification, FRS) 非功能需求規格書 (Non-Functional Requirements Specification, NFRS) 使用者需求文件 (User Requirements Document, URD) 1.3.2 分析模型與圖表 用例圖 (Use Case Diagrams) 用例描述表 (Use Case Specifications) 業務流程圖 (Business Process Diagrams) 資料流程圖 (Data Flow Diagrams, DFD) 實體關係圖 (Entity Relationship Diagrams, ERD) 狀態圖 (State Diagrams) 活動圖 (Activity Diagrams) 循序圖 (Sequence Diagrams) 1.3.3 整合與介面文件 系統整合需求規格書 (System Integration Requirements) API 需求規格書 (API Requirements Specification) 批次處理需求規格書 (Batch Processing Requirements) 資料交換格式定義 (Data Exchange Format Specification) 外部系統介面規格 (External System Interface Specification) 1.3.4 安全與合規文件 安全需求規格書 (Security Requirements Specification) 威脅模型文件 (Threat Model Document) 風險評估報告 (Risk Assessment Report) 合規檢查清單 (Compliance Checklist) 資料保護影響評估 (Data Protection Impact Assessment, DPIA) 1.3.5 測試相關文件 測試需求規格書 (Test Requirements Specification) 驗收標準定義 (Acceptance Criteria Definition) 測試案例大綱 (Test Case Outline) 1.3.6 專案管理文件 需求追蹤矩陣 (Requirements Traceability Matrix, RTM) 變更控制文件 (Change Control Document) 需求優先級矩陣 (Requirements Priority Matrix) 影響分析報告 (Impact Analysis Report) 2. 需求收集與分析流程 2.1 需求收集流程 2.1.1 準備階段 flowchart TD A[專案啟動] --\u0026gt; B[組建分析團隊] B --\u0026gt; C[制定分析計劃] C --\u0026gt; D[識別利害關係人] D --\u0026gt; E[準備訪談資料] E --\u0026gt; F[安排訪談時程] 主要活動：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%8C%87%E5%BC%95/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E6%8C%87%E5%BC%95/","summary":"專案系統分析指引 目錄 系統分析階段目標與產出物 需求收集與分析流程 涉及角色與職責 系統分析方法與工具 4.1 UML 建模方法 4.2 資料流程圖 (DFD) 4.3 實體關係圖 (ERD) 4.4 物件導向分析方法 (OOA) 4.5 狀態圖 4.6 分析模型整合 跨系統整合分析 安全與合規考量 版本控管與審核流程 範例與模板 8.1 需求規格書模板 8.2 用例描述表模板 8.3 物件導向分析模板 8.4 系統功能列表模板 8.5 需求變更申請表模板 總結與最佳實踐 敏捷開發環境下的系統分析 數據驅動的需求分析 雲端架構考量 國際化與在地化需求 效能與容量規劃 災難恢復與營運連續性 附錄 文件資訊 文件名稱：專案系統分析指引 版本：2.0 建立日期：2025年8月11日 最後更新：2025年8月29日 適用專案：大型共用平台系統 技術架構：前後端分離 + Clean Architecture + 雲端原生 1. 系統分析階段目標與產出物 1.1 階段目標 系統分析階段是軟體開發生命週期中的關鍵環節，主要目標包括：\n需求理解與定義：深入理解業務需求，並將其轉化為明確的系統需求 系統邊界確立：明確定義系統的範圍、功能邊界與非功能需求 風險識別與評估：識別技術風險、業務風險及安全風險 可行性分析：評估技術可行性、經濟可行性與時程可行性 架構規劃基礎：為後續的系統設計階段提供清晰的需求基礎 1.2 工作範圍 1.2.1 業務分析範圍 現有系統分析與問題識別 業務流程梳理與優化建議 利害關係人需求收集 業務規則定義與驗證 使用者體驗需求分析 1.2.2 技術分析範圍 系統功能需求分析 非功能需求定義（效能、安全、可用性等） 系統整合需求分析 資料流程與資料模型分析 介面需求定義 1.2.3 安全分析範圍 威脅建模與風險評估 安全需求定義 合規要求分析 資料保護需求 存取控制需求 1.3 主要產出物清單 1.3.1 需求文件 業務需求規格書 (Business Requirements Specification, BRS) 系統需求規格書 (System Requirements Specification, SRS) 功能需求規格書 (Functional Requirements Specification, FRS) 非功能需求規格書 (Non-Functional Requirements Specification, NFRS) 使用者需求文件 (User Requirements Document, URD) 1.3.2 分析模型與圖表 用例圖 (Use Case Diagrams) 用例描述表 (Use Case Specifications) 業務流程圖 (Business Process Diagrams) 資料流程圖 (Data Flow Diagrams, DFD) 實體關係圖 (Entity Relationship Diagrams, ERD) 狀態圖 (State Diagrams) 活動圖 (Activity Diagrams) 循序圖 (Sequence Diagrams) 1.3.3 整合與介面文件 系統整合需求規格書 (System Integration Requirements) API 需求規格書 (API Requirements Specification) 批次處理需求規格書 (Batch Processing Requirements) 資料交換格式定義 (Data Exchange Format Specification) 外部系統介面規格 (External System Interface Specification) 1.3.4 安全與合規文件 安全需求規格書 (Security Requirements Specification) 威脅模型文件 (Threat Model Document) 風險評估報告 (Risk Assessment Report) 合規檢查清單 (Compliance Checklist) 資料保護影響評估 (Data Protection Impact Assessment, DPIA) 1.3.5 測試相關文件 測試需求規格書 (Test Requirements Specification) 驗收標準定義 (Acceptance Criteria Definition) 測試案例大綱 (Test Case Outline) 1.3.6 專案管理文件 需求追蹤矩陣 (Requirements Traceability Matrix, RTM) 變更控制文件 (Change Control Document) 需求優先級矩陣 (Requirements Priority Matrix) 影響分析報告 (Impact Analysis Report) 2. 需求收集與分析流程 2.1 需求收集流程 2.1.1 準備階段 flowchart TD A[專案啟動] --\u0026gt; B[組建分析團隊] B --\u0026gt; C[制定分析計劃] C --\u0026gt; D[識別利害關係人] D --\u0026gt; E[準備訪談資料] E --\u0026gt; F[安排訪談時程] 主要活動：\n","title":""},{"content":"Angular 前端Framework教學手冊 目錄 1. 前言 為什麼要學習 Angular？ 專案背景 學習目標 2. 基礎篇 1. Angular 架構概念 1.1 核心概念 1.2 應用程式架構圖 2. 環境建置 2.1 必要軟體安裝 2.2 建立新專案 2.3 專案結構 3. 組件 (Components) 3.1 組件基本概念 3.2 建立組件 3.3 組件範例 4. 資料繫結 (Data Binding) 4.1 插值繫結 (Interpolation) 4.2 屬性繫結 (Property Binding) 4.3 事件繫結 (Event Binding) 4.4 雙向資料繫結 (Two-way Binding) 3. 進階篇 5. 模組 (Modules) 5.1 模組基本概念 5.2 根模組範例 5.3 功能模組建立 5.4 共用模組 6. 服務與相依性注入 (Services \u0026amp; Dependency Injection) 6.1 建立服務 6.2 基本服務範例 6.3 在組件中使用服務 6.4 服務注入層級 7. 路由 (Routing) 7.1 基本路由設定 7.2 子路由設定 7.3 路由導航 7.4 路由參數處理 7.5 路由守衛 4. 專案實務篇 8. 表單處理 8.1 範本驅動表單 (Template-driven Forms) 8.2 反應式表單 (Reactive Forms) 8.3 表單驗證最佳實務 9. HTTP 客戶端與 API 整合 9.1 HTTP 攔截器 9.2 API 服務封裝 10. RxJS 最佳實務 10.1 常用操作符 10.2 記憶體管理 11. 測試 (Testing) 11.1 單元測試範例 11.2 整合測試範例 11.3 指令測試範例 11.4 管道測試範例 11.5 路由測試範例 11.6 測試工具與最佳實務 5. 認證準備篇 12. Angular 官方認證考試重點 12.1 考試概要 12.2 重點知識領域 12.3 模擬考試題目 12.4 考前準備清單 13. 實戰模擬測驗 13.1 綜合練習題 13.2 進階練習題 6. 附錄 14. 常見問題 (FAQ) 14.1 開發環境問題 14.2 開發常見問題 14.3 效能問題 15. 有用的資源連結 15.1 官方資源 15.2 學習資源 15.3 工具與庫 15.4 社群資源 16. 快速參考檢查清單 16.1 新專案設置檢查清單 16.2 開發檢查清單 16.3 部署前檢查清單 16.4 程式碼審查檢查清單 17. 團隊開發規範 17.1 Git 工作流程 17.2 程式碼規範 17.3 程式碼審查標準 前言 為什麼要學習 Angular？ Angular 是由 Google 開發維護的前端框架，具有以下優勢：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/angular-%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"Angular 前端Framework教學手冊 目錄 1. 前言 為什麼要學習 Angular？ 專案背景 學習目標 2. 基礎篇 1. Angular 架構概念 1.1 核心概念 1.2 應用程式架構圖 2. 環境建置 2.1 必要軟體安裝 2.2 建立新專案 2.3 專案結構 3. 組件 (Components) 3.1 組件基本概念 3.2 建立組件 3.3 組件範例 4. 資料繫結 (Data Binding) 4.1 插值繫結 (Interpolation) 4.2 屬性繫結 (Property Binding) 4.3 事件繫結 (Event Binding) 4.4 雙向資料繫結 (Two-way Binding) 3. 進階篇 5. 模組 (Modules) 5.1 模組基本概念 5.2 根模組範例 5.3 功能模組建立 5.4 共用模組 6. 服務與相依性注入 (Services \u0026amp; Dependency Injection) 6.1 建立服務 6.2 基本服務範例 6.3 在組件中使用服務 6.4 服務注入層級 7. 路由 (Routing) 7.1 基本路由設定 7.2 子路由設定 7.3 路由導航 7.4 路由參數處理 7.5 路由守衛 4. 專案實務篇 8. 表單處理 8.1 範本驅動表單 (Template-driven Forms) 8.2 反應式表單 (Reactive Forms) 8.3 表單驗證最佳實務 9. HTTP 客戶端與 API 整合 9.1 HTTP 攔截器 9.2 API 服務封裝 10. RxJS 最佳實務 10.1 常用操作符 10.2 記憶體管理 11. 測試 (Testing) 11.1 單元測試範例 11.2 整合測試範例 11.3 指令測試範例 11.4 管道測試範例 11.5 路由測試範例 11.6 測試工具與最佳實務 5. 認證準備篇 12. Angular 官方認證考試重點 12.1 考試概要 12.2 重點知識領域 12.3 模擬考試題目 12.4 考前準備清單 13. 實戰模擬測驗 13.1 綜合練習題 13.2 進階練習題 6. 附錄 14. 常見問題 (FAQ) 14.1 開發環境問題 14.2 開發常見問題 14.3 效能問題 15. 有用的資源連結 15.1 官方資源 15.2 學習資源 15.3 工具與庫 15.4 社群資源 16. 快速參考檢查清單 16.1 新專案設置檢查清單 16.2 開發檢查清單 16.3 部署前檢查清單 16.4 程式碼審查檢查清單 17. 團隊開發規範 17.1 Git 工作流程 17.2 程式碼規範 17.3 程式碼審查標準 前言 為什麼要學習 Angular？ Angular 是由 Google 開發維護的前端框架，具有以下優勢：\n","title":""},{"content":"PrimeNG 使用教學手冊 文件資訊 版本: 1.0.0 更新日期: 2025年9月5日 目標對象: 從未學過 PrimeNG 的新進開發同仁 適用 PrimeNG 版本: 17.x+ 適用 Angular 版本: 17.x+ 目錄 第 1 部分：基礎入門 PrimeNG 簡介\n1.1 什麼是 PrimeNG 1.2 為什麼選擇 PrimeNG 1.3 在企業專案中的角色 1.4 實務案例 1.5 注意事項與最佳實務 環境安裝與設定\n2.1 前置需求 2.2 建立 Angular 專案 2.3 安裝 PrimeNG 與相關套件 2.4 基礎設定 2.5 主題選擇與設定 2.6 設定 PrimeFlex（CSS 工具庫） 2.7 開發工具設定 2.8 實務案例：企業專案設定 2.9 注意事項與疑難排解 2.10 環境設定檢查清單 PrimeNG 基本使用流程\n3.1 理解 Angular 與 PrimeNG 的關係 3.2 模組匯入策略 3.3 建立第一個 PrimeNG 頁面 3.4 PrimeNG 服務的使用 3.5 響應式設計與 PrimeFlex 3.6 實務開發流程 3.7 注意事項與最佳實務 3.8 第一個專案檢查清單 第 2 部分：核心元件應用 按鈕與圖示\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/primeng%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PrimeNG 使用教學手冊 文件資訊 版本: 1.0.0 更新日期: 2025年9月5日 目標對象: 從未學過 PrimeNG 的新進開發同仁 適用 PrimeNG 版本: 17.x+ 適用 Angular 版本: 17.x+ 目錄 第 1 部分：基礎入門 PrimeNG 簡介\n1.1 什麼是 PrimeNG 1.2 為什麼選擇 PrimeNG 1.3 在企業專案中的角色 1.4 實務案例 1.5 注意事項與最佳實務 環境安裝與設定\n2.1 前置需求 2.2 建立 Angular 專案 2.3 安裝 PrimeNG 與相關套件 2.4 基礎設定 2.5 主題選擇與設定 2.6 設定 PrimeFlex（CSS 工具庫） 2.7 開發工具設定 2.8 實務案例：企業專案設定 2.9 注意事項與疑難排解 2.10 環境設定檢查清單 PrimeNG 基本使用流程\n3.1 理解 Angular 與 PrimeNG 的關係 3.2 模組匯入策略 3.3 建立第一個 PrimeNG 頁面 3.4 PrimeNG 服務的使用 3.5 響應式設計與 PrimeFlex 3.6 實務開發流程 3.7 注意事項與最佳實務 3.8 第一個專案檢查清單 第 2 部分：核心元件應用 按鈕與圖示\n","title":""},{"content":"PrimeVue 使用教學手冊 📋 目錄 第一章：基礎入門\n1.1 PrimeVue 簡介 1.2 PrimeVue 與 Vue.js 的關係 1.3 安裝與設定 1.4 建立第一個 PrimeVue 專案 1.5 Hello World 範例 第二章：核心元件介紹\n2.1 按鈕（Button）與圖示（IconButton） 2.2 表單元件（InputText、Password、Dropdown、Checkbox、RadioButton、Calendar、Slider） 2.3 資料顯示元件（DataTable、Listbox、Card、Panel、TabView、Accordion） 2.4 對話框與通知（Dialog、Toast、ConfirmDialog） 2.5 版面配置元件（Panel、Card、Divider、Splitter） 第三章：專案應用實戰\n3.1 建立完整的使用者管理系統 3.2 第三章總結與學習重點 第四章：進階功能與效能優化\n4.1 效能優化策略 4.1.1 Vue 3 的效能優化特性 4.1.2 PrimeVue 元件效能優化 4.1.3 記憶體管理與清理 4.2 國際化 (i18n) 實作 4.2.1 Vue I18n 設定 4.2.2 在元件中使用國際化 4.2.3 PrimeVue 元件的本地化 4.3 主題系統與自訂樣式 4.3.1 PrimeVue 主題系統 4.3.2 自訂 CSS 變數系統 4.4 測試策略 4.4.1 單元測試設定 4.4.2 整合測試 4.4.3 E2E 測試 4.5 第四章總結 第五章：實務案例與最佳實務\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/primevue%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PrimeVue 使用教學手冊 📋 目錄 第一章：基礎入門\n1.1 PrimeVue 簡介 1.2 PrimeVue 與 Vue.js 的關係 1.3 安裝與設定 1.4 建立第一個 PrimeVue 專案 1.5 Hello World 範例 第二章：核心元件介紹\n2.1 按鈕（Button）與圖示（IconButton） 2.2 表單元件（InputText、Password、Dropdown、Checkbox、RadioButton、Calendar、Slider） 2.3 資料顯示元件（DataTable、Listbox、Card、Panel、TabView、Accordion） 2.4 對話框與通知（Dialog、Toast、ConfirmDialog） 2.5 版面配置元件（Panel、Card、Divider、Splitter） 第三章：專案應用實戰\n3.1 建立完整的使用者管理系統 3.2 第三章總結與學習重點 第四章：進階功能與效能優化\n4.1 效能優化策略 4.1.1 Vue 3 的效能優化特性 4.1.2 PrimeVue 元件效能優化 4.1.3 記憶體管理與清理 4.2 國際化 (i18n) 實作 4.2.1 Vue I18n 設定 4.2.2 在元件中使用國際化 4.2.3 PrimeVue 元件的本地化 4.3 主題系統與自訂樣式 4.3.1 PrimeVue 主題系統 4.3.2 自訂 CSS 變數系統 4.4 測試策略 4.4.1 單元測試設定 4.4.2 整合測試 4.4.3 E2E 測試 4.5 第四章總結 第五章：實務案例與最佳實務\n","title":""},{"content":"React 前端 Framework 教學手冊 📚 目錄 基礎概念\n1.1 React 簡介與核心原理 1.2 JSX 語法 1.3 Component 元件 1.4 Props 屬性 1.5 State 狀態 1.6 Hooks 鉤子 專案實務\n2.0 專案建立與環境設定 2.1 專案架構與元件拆分 2.2 狀態管理策略 2.3 API 呼叫方式 2.4 UI/UX 開發流程 進階主題\n3.1 React Router 路由管理 3.2 Context API 3.3 狀態管理工具 3.4 效能最佳化 測試與品質\n4.1 React 測試框架 4.2 程式碼規範 4.3 Lint 與 Formatter 實戰演練\n5.1 表單處理 5.2 API 資料綁定 5.3 前後端整合 認證準備指南\n6.1 React 認證概述 6.2 常見考點 6.3 練習題範例 6.4 學習資源 檢查清單\n1. 基礎概念 1.1 React 簡介與核心原理 什麼是 React？ React 是由 Facebook（現在的 Meta）開發的開源 JavaScript 函式庫，專門用來建立使用者介面（UI）。它採用元件化的開發方式，讓開發者能夠建立可重複使用的 UI 元件。\nReact 核心原理 graph TB A[Virtual DOM] --\u0026gt; B[實際 DOM] C[Component] --\u0026gt; D[JSX] D --\u0026gt; A E[State] --\u0026gt; C F[Props] --\u0026gt; C G[Hooks] --\u0026gt; E subgraph \u0026#34;React 生態系統\u0026#34; A C E F G end 1. Virtual DOM（虛擬 DOM）\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/react%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"React 前端 Framework 教學手冊 📚 目錄 基礎概念\n1.1 React 簡介與核心原理 1.2 JSX 語法 1.3 Component 元件 1.4 Props 屬性 1.5 State 狀態 1.6 Hooks 鉤子 專案實務\n2.0 專案建立與環境設定 2.1 專案架構與元件拆分 2.2 狀態管理策略 2.3 API 呼叫方式 2.4 UI/UX 開發流程 進階主題\n3.1 React Router 路由管理 3.2 Context API 3.3 狀態管理工具 3.4 效能最佳化 測試與品質\n4.1 React 測試框架 4.2 程式碼規範 4.3 Lint 與 Formatter 實戰演練\n5.1 表單處理 5.2 API 資料綁定 5.3 前後端整合 認證準備指南\n6.1 React 認證概述 6.2 常見考點 6.3 練習題範例 6.4 學習資源 檢查清單\n1. 基礎概念 1.1 React 簡介與核心原理 什麼是 React？ React 是由 Facebook（現在的 Meta）開發的開源 JavaScript 函式庫，專門用來建立使用者介面（UI）。它採用元件化的開發方式，讓開發者能夠建立可重複使用的 UI 元件。\nReact 核心原理 graph TB A[Virtual DOM] --\u0026gt; B[實際 DOM] C[Component] --\u0026gt; D[JSX] D --\u0026gt; A E[State] --\u0026gt; C F[Props] --\u0026gt; C G[Hooks] --\u0026gt; E subgraph \u0026#34;React 生態系統\u0026#34; A C E F G end 1. Virtual DOM（虛擬 DOM）\n","title":""},{"content":"Spring Boot 教學手冊 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2025-08-31 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 目錄 Spring Boot 簡介\n1.1 什麼是 Spring Boot？ 1.2 Spring Boot 的核心特點 1.3 Spring Boot vs Spring Framework 1.4 專案常見應用場景 1.5 Spring Boot 版本選擇 1.6 章節小練習 1.7 實務注意事項 開發環境建置\n2.1 系統需求 2.2 JDK 安裝與設定 2.3 Maven 安裝與設定 2.4 IDE 設定 2.5 Spring Initializr 使用 2.6 開發工具設定 2.7 專案建立實作 2.8 執行與測試 2.9 章節小練習 2.10 實務注意事項 Spring Boot 基礎\n3.1 專案結構 3.2 Application Properties 設定 3.3 依賴注入 (Dependency Injection) 3.4 Spring Boot Starter 3.5 Bean 生命週期與作用域 3.6 Profile 環境管理 3.7 章節小練習 3.8 實務注意事項 RESTful API 開發\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/spring-boot-%E6%95%99%E5%AD%B8/","summary":"Spring Boot 教學手冊 文件資訊 作者: 技術團隊 版本: 1.0 更新日期: 2025-08-31 目標對象: 新進開發同仁、Spring Boot 初學者、認證考試準備者 目錄 Spring Boot 簡介\n1.1 什麼是 Spring Boot？ 1.2 Spring Boot 的核心特點 1.3 Spring Boot vs Spring Framework 1.4 專案常見應用場景 1.5 Spring Boot 版本選擇 1.6 章節小練習 1.7 實務注意事項 開發環境建置\n2.1 系統需求 2.2 JDK 安裝與設定 2.3 Maven 安裝與設定 2.4 IDE 設定 2.5 Spring Initializr 使用 2.6 開發工具設定 2.7 專案建立實作 2.8 執行與測試 2.9 章節小練習 2.10 實務注意事項 Spring Boot 基礎\n3.1 專案結構 3.2 Application Properties 設定 3.3 依賴注入 (Dependency Injection) 3.4 Spring Boot Starter 3.5 Bean 生命週期與作用域 3.6 Profile 環境管理 3.7 章節小練習 3.8 實務注意事項 RESTful API 開發\n","title":""},{"content":"Spring Framework 教學手冊 目錄 Spring Framework 概述\n1.1 什麼是 Spring Framework 1.2 Spring 生態系統 1.3 為什麼使用 Spring Framework 1.4 認證考點提示 1.5 實務案例 核心概念\n2.1 控制反轉 (Inversion of Control, IoC) 2.2 依賴注入 (Dependency Injection, DI) 2.3 Bean 的概念 IoC 容器與依賴注入\n3.1 IoC 容器深入解析 3.2 BeanFactory vs ApplicationContext 3.2.1 BeanFactory 3.2.2 ApplicationContext 3.3 Bean 定義與註冊 3.3.1 註解驅動的配置 3.3.2 Java 配置方式 3.4 依賴注入的進階特性 3.4.1 條件式注入 3.4.2 Qualifier 與 Primary 3.5 Bean 生命週期 3.6 ApplicationContext 事件機制 3.6.1 內建事件 3.6.2 自定義事件 3.7 認證考點提示 3.8 實務案例 Bean 管理\n4.1 Bean 的作用域 4.1.1 Singleton 作用域 4.1.2 Prototype 作用域 4.1.3 Web 作用域 4.2 Bean 的初始化和銷毀 4.2.1 初始化方法 4.2.2 銷毀方法 4.3 Bean 的延遲初始化 4.4 條件式 Bean 創建 4.4.1 內建條件註解 4.4.2 自定義條件 4.5 Profile 環境配置 4.6 Factory Bean 模式 4.7 認證考點提示 4.8 實務案例 面向切面程式設計 (AOP)\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/spring-framework%E6%95%99%E5%AD%B8/","summary":"Spring Framework 教學手冊 目錄 Spring Framework 概述\n1.1 什麼是 Spring Framework 1.2 Spring 生態系統 1.3 為什麼使用 Spring Framework 1.4 認證考點提示 1.5 實務案例 核心概念\n2.1 控制反轉 (Inversion of Control, IoC) 2.2 依賴注入 (Dependency Injection, DI) 2.3 Bean 的概念 IoC 容器與依賴注入\n3.1 IoC 容器深入解析 3.2 BeanFactory vs ApplicationContext 3.2.1 BeanFactory 3.2.2 ApplicationContext 3.3 Bean 定義與註冊 3.3.1 註解驅動的配置 3.3.2 Java 配置方式 3.4 依賴注入的進階特性 3.4.1 條件式注入 3.4.2 Qualifier 與 Primary 3.5 Bean 生命週期 3.6 ApplicationContext 事件機制 3.6.1 內建事件 3.6.2 自定義事件 3.7 認證考點提示 3.8 實務案例 Bean 管理\n4.1 Bean 的作用域 4.1.1 Singleton 作用域 4.1.2 Prototype 作用域 4.1.3 Web 作用域 4.2 Bean 的初始化和銷毀 4.2.1 初始化方法 4.2.2 銷毀方法 4.3 Bean 的延遲初始化 4.4 條件式 Bean 創建 4.4.1 內建條件註解 4.4.2 自定義條件 4.5 Profile 環境配置 4.6 Factory Bean 模式 4.7 認證考點提示 4.8 實務案例 面向切面程式設計 (AOP)\n","title":""},{"content":"Thymeleaf 使用教學手冊 目錄 基礎概念\n1.1 什麼是 Thymeleaf？ 1.2 核心特色 1.2.1 自然模板特性 1.2.2 表達式豐富性 1.3 與其他模板引擎比較 1.3.1 詳細比較表 1.4 適用場景 1.5 工作流程 1.6 實務注意事項 環境建置\n2.1 Spring Boot 專案整合 2.1.1 Maven 設定 2.1.2 Gradle 設定 2.2 目錄結構設定 2.3 應用程式設定 2.3.1 基本設定 (application.yml) 2.3.2 生產環境設定 (application-prod.yml) 2.4 IDE 設定 2.4.1 IntelliJ IDEA 設定 2.4.2 VS Code 設定 2.5 驗證安裝 2.5.1 建立控制器 2.5.2 建立模板 2.5.3 啟動應用程式 2.6 開發環境最佳化 2.6.1 熱重載設定 2.6.2 除錯設定 2.7 常見安裝問題 語法教學\n3.1 基本標籤語法 3.1.1 文字輸出 (th:text) 3.1.2 HTML 輸出 (th:utext) 3.1.3 條件判斷 (th:if, th:unless) 3.1.4 迴圈遍歷 (th:each) 3.1.5 條件選擇 (th:switch, th:case) 3.2 屬性處理 3.2.1 設定屬性 (th:attr) 3.2.2 常用屬性快捷方式 3.2.3 CSS 類別處理 (th:classappend) 3.3 表達式語法 3.3.1 變數表達式 (${\u0026hellip;}) 3.3.2 選擇表達式 (*{\u0026hellip;}) 3.3.3 連結表達式 (@{\u0026hellip;}) 3.3.4 訊息表達式 (#{\u0026hellip;}) 3.3.5 片段表達式 (~{\u0026hellip;}) 3.4 內建工具物件 3.4.1 日期工具 (#dates) 3.4.2 數字工具 (#numbers) 3.4.3 字串工具 (#strings) 3.4.4 集合工具 (#lists, #sets, #maps) 3.5 實務注意事項 3.6 模板繼承與片段 3.6.1 片段定義與使用 (th:fragment) 3.6.2 片段插入方式 3.6.3 佈局模板系統 3.6.4 參數化片段 3.6.5 片段選擇器 3.7 實務注意事項 3.8 表單處理 3.8.1 基本表單綁定 3.8.2 下拉選單處理 3.8.3 核取方塊處理 3.8.4 單選按鈕處理 3.8.5 檔案上傳處理 3.8.6 表單驗證錯誤處理 3.9 國際化 (i18n) 支援 3.9.1 設定國際化 3.9.2 訊息資源檔案 3.9.3 在模板中使用國際化 3.9.4 Java 程式碼中的國際化 3.9.5 日期和數字本地化 3.9.6 進階國際化實作 3.9.7 多語言最佳實務 3.10 實務注意事項 實務應用範例\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/thymeleaf%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Thymeleaf 使用教學手冊 目錄 基礎概念\n1.1 什麼是 Thymeleaf？ 1.2 核心特色 1.2.1 自然模板特性 1.2.2 表達式豐富性 1.3 與其他模板引擎比較 1.3.1 詳細比較表 1.4 適用場景 1.5 工作流程 1.6 實務注意事項 環境建置\n2.1 Spring Boot 專案整合 2.1.1 Maven 設定 2.1.2 Gradle 設定 2.2 目錄結構設定 2.3 應用程式設定 2.3.1 基本設定 (application.yml) 2.3.2 生產環境設定 (application-prod.yml) 2.4 IDE 設定 2.4.1 IntelliJ IDEA 設定 2.4.2 VS Code 設定 2.5 驗證安裝 2.5.1 建立控制器 2.5.2 建立模板 2.5.3 啟動應用程式 2.6 開發環境最佳化 2.6.1 熱重載設定 2.6.2 除錯設定 2.7 常見安裝問題 語法教學\n3.1 基本標籤語法 3.1.1 文字輸出 (th:text) 3.1.2 HTML 輸出 (th:utext) 3.1.3 條件判斷 (th:if, th:unless) 3.1.4 迴圈遍歷 (th:each) 3.1.5 條件選擇 (th:switch, th:case) 3.2 屬性處理 3.2.1 設定屬性 (th:attr) 3.2.2 常用屬性快捷方式 3.2.3 CSS 類別處理 (th:classappend) 3.3 表達式語法 3.3.1 變數表達式 (${\u0026hellip;}) 3.3.2 選擇表達式 (*{\u0026hellip;}) 3.3.3 連結表達式 (@{\u0026hellip;}) 3.3.4 訊息表達式 (#{\u0026hellip;}) 3.3.5 片段表達式 (~{\u0026hellip;}) 3.4 內建工具物件 3.4.1 日期工具 (#dates) 3.4.2 數字工具 (#numbers) 3.4.3 字串工具 (#strings) 3.4.4 集合工具 (#lists, #sets, #maps) 3.5 實務注意事項 3.6 模板繼承與片段 3.6.1 片段定義與使用 (th:fragment) 3.6.2 片段插入方式 3.6.3 佈局模板系統 3.6.4 參數化片段 3.6.5 片段選擇器 3.7 實務注意事項 3.8 表單處理 3.8.1 基本表單綁定 3.8.2 下拉選單處理 3.8.3 核取方塊處理 3.8.4 單選按鈕處理 3.8.5 檔案上傳處理 3.8.6 表單驗證錯誤處理 3.9 國際化 (i18n) 支援 3.9.1 設定國際化 3.9.2 訊息資源檔案 3.9.3 在模板中使用國際化 3.9.4 Java 程式碼中的國際化 3.9.5 日期和數字本地化 3.9.6 進階國際化實作 3.9.7 多語言最佳實務 3.10 實務注意事項 實務應用範例\n","title":""},{"content":"Vue 3.x 前端 Framework 教學手冊 📘 適用對象：完全沒有學過 Vue 3 的新進開發同仁\n🎯 學習目標：循序漸進掌握 Vue 3.x 開發技能，並具備專案實戰能力\n🏆 認證準備：涵蓋 Vue 3 官方認證考試重點\n📖 目錄 第一章：Vue 3 基礎入門\n1.1 什麼是 Vue.js？ 1.2 開發環境建置 1.3 第一個 Vue 3 應用 1.4 專案應用指引 1.5 認證考點提示 第二章：Composition API 深入\n2.1 setup() 函數詳解 2.2 組合式函數 (Composables) 2.3 進階組合式函數範例 2.4 專案應用指引 2.5 認證考點提示 第三章：響應式系統\n3.1 ref() 與 reactive() 詳解 3.2 深度響應式與淺層響應式 3.3 computed() 計算屬性 3.4 watch() 與 watchEffect() 3.5 響應式工具函數 3.6 專案應用指引 3.7 認證考點提示 第四章：模板語法與指令\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/framework/vue3-%E5%89%8D%E7%AB%AFframework%E6%95%99%E5%AD%B8/","summary":"Vue 3.x 前端 Framework 教學手冊 📘 適用對象：完全沒有學過 Vue 3 的新進開發同仁\n🎯 學習目標：循序漸進掌握 Vue 3.x 開發技能，並具備專案實戰能力\n🏆 認證準備：涵蓋 Vue 3 官方認證考試重點\n📖 目錄 第一章：Vue 3 基礎入門\n1.1 什麼是 Vue.js？ 1.2 開發環境建置 1.3 第一個 Vue 3 應用 1.4 專案應用指引 1.5 認證考點提示 第二章：Composition API 深入\n2.1 setup() 函數詳解 2.2 組合式函數 (Composables) 2.3 進階組合式函數範例 2.4 專案應用指引 2.5 認證考點提示 第三章：響應式系統\n3.1 ref() 與 reactive() 詳解 3.2 深度響應式與淺層響應式 3.3 computed() 計算屬性 3.4 watch() 與 watchEffect() 3.5 響應式工具函數 3.6 專案應用指引 3.7 認證考點提示 第四章：模板語法與指令\n","title":""},{"content":"Clean Architecture 教學手冊 📖 手冊說明 本教學手冊專為新進開發同仁設計，旨在幫助您：\n理解 Clean Architecture 的核心概念與設計哲學 學會在專案中運用 Clean Architecture 進行開發 具備考取 Clean Architecture 認證的能力 📚 目錄 基礎篇：Clean Architecture 核心概念\n1.1 什麼是 Clean Architecture？ 1.2 核心原則 1.3 Clean Architecture vs 傳統架構 1.4 常見誤解與迷思 1.5 實務注意事項 架構篇：分層架構與職責\n2.1 Clean Architecture 總覽 2.2 第一層：Entities（實體層） 2.3 第二層：Use Cases（用例層） 2.4 第三層：Interface Adapters（介面適配層） 2.5 第四層：Frameworks \u0026amp; Drivers（框架與驅動層） 2.6 層間通信與依賴注入 2.7 實務注意事項 實作篇：專案範例實戰\n3.1 專案概述：會員管理系統 3.2 Domain 層實作 3.3 Use Case 層實作 3.4 Interface Adapters 層實作 3.5 實務注意事項 專案應用篇：團隊開發規範\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/clean-architecture%E6%95%99%E5%AD%B8/","summary":"Clean Architecture 教學手冊 📖 手冊說明 本教學手冊專為新進開發同仁設計，旨在幫助您：\n理解 Clean Architecture 的核心概念與設計哲學 學會在專案中運用 Clean Architecture 進行開發 具備考取 Clean Architecture 認證的能力 📚 目錄 基礎篇：Clean Architecture 核心概念\n1.1 什麼是 Clean Architecture？ 1.2 核心原則 1.3 Clean Architecture vs 傳統架構 1.4 常見誤解與迷思 1.5 實務注意事項 架構篇：分層架構與職責\n2.1 Clean Architecture 總覽 2.2 第一層：Entities（實體層） 2.3 第二層：Use Cases（用例層） 2.4 第三層：Interface Adapters（介面適配層） 2.5 第四層：Frameworks \u0026amp; Drivers（框架與驅動層） 2.6 層間通信與依賴注入 2.7 實務注意事項 實作篇：專案範例實戰\n3.1 專案概述：會員管理系統 3.2 Domain 層實作 3.3 Use Case 層實作 3.4 Interface Adapters 層實作 3.5 實務注意事項 專案應用篇：團隊開發規範\n","title":""},{"content":"Clean Code 教學手冊 📚 目錄 Clean Code 簡介\n1.1 什麼是 Clean Code？ 1.2 為什麼 Clean Code 重要？ 1.3 與專案品質的關係 核心原則與最佳實踐\n2.1 命名原則 2.2 函式原則 2.3 類別與物件原則 2.4 註解原則 2.5 格式化原則 2.6 錯誤處理原則 2.7 測試原則 實務範例與對照\n3.1 電商購物車範例 3.2 改善對照分析 3.3 使用者註冊系統範例 3.4 重構步驟與技巧 專案應用指引\n4.1 團隊程式碼規範 4.2 程式碼審查流程 4.3 常見反模式與改善 4.4 開發工具配置 4.5 持續整合配置 認證考試重點\n5.1 Clean Code 認證概述 5.2 核心知識點 5.3 常見考試題型 5.4 考試準備策略 5.5 考試注意事項 檢查清單\n6.1 程式碼撰寫檢查清單 6.2 程式碼品質檢查清單 6.3 重構檢查清單 6.4 團隊協作檢查清單 6.5 專案層級檢查清單 6.6 持續改進檢查清單 6.7 快速參考卡 1. Clean Code 簡介 1.1 什麼是 Clean Code？ Clean Code（乾淨程式碼） 是指易於閱讀、理解和維護的程式碼。它不僅僅是能夠運行的程式碼，更是一種追求程式碼品質的哲學。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/clean-code%E6%95%99%E5%AD%B8/","summary":"Clean Code 教學手冊 📚 目錄 Clean Code 簡介\n1.1 什麼是 Clean Code？ 1.2 為什麼 Clean Code 重要？ 1.3 與專案品質的關係 核心原則與最佳實踐\n2.1 命名原則 2.2 函式原則 2.3 類別與物件原則 2.4 註解原則 2.5 格式化原則 2.6 錯誤處理原則 2.7 測試原則 實務範例與對照\n3.1 電商購物車範例 3.2 改善對照分析 3.3 使用者註冊系統範例 3.4 重構步驟與技巧 專案應用指引\n4.1 團隊程式碼規範 4.2 程式碼審查流程 4.3 常見反模式與改善 4.4 開發工具配置 4.5 持續整合配置 認證考試重點\n5.1 Clean Code 認證概述 5.2 核心知識點 5.3 常見考試題型 5.4 考試準備策略 5.5 考試注意事項 檢查清單\n6.1 程式碼撰寫檢查清單 6.2 程式碼品質檢查清單 6.3 重構檢查清單 6.4 團隊協作檢查清單 6.5 專案層級檢查清單 6.6 持續改進檢查清單 6.7 快速參考卡 1. Clean Code 簡介 1.1 什麼是 Clean Code？ Clean Code（乾淨程式碼） 是指易於閱讀、理解和維護的程式碼。它不僅僅是能夠運行的程式碼，更是一種追求程式碼品質的哲學。\n","title":""},{"content":"Design Pattern 教學手冊（二）- 進階實務應用 目錄 第 1 章：設計模式概論 第 2 章：設計模式分類與全貌 第 3 章：創建型模式 第 4 章：結構型模式 第 5 章：行為型模式 第 6 章：專案應用指南 第 7 章：學習與練習 第 8 章：認證考試準備 第 9 章：附錄與資源 第 1 章：設計模式概論 1.1 設計模式的定義與歷史背景 1.1.1 什麼是設計模式？ 設計模式（Design Pattern）是在軟體開發過程中，針對常見問題的通用解決方案。它是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。\n1.1.2 Gang of Four (GoF) 的貢獻 1994年，四位軟體工程師 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 共同撰寫了《設計模式：可複用物件導向軟體的基礎》一書，定義了23個經典設計模式，被稱為「四人幫」（Gang of Four，GoF）。\ntimeline title 設計模式發展歷程 1987 : Christopher Alexander 提出建築模式概念 1994 : GoF 發表 23 個經典設計模式 1995 : Java 語言誕生，設計模式開始普及 2000 : 企業級應用廣泛採用設計模式 2010 : Spring Framework 大量運用設計模式 2020 : 微服務架構中的設計模式應用 1.2 為什麼需要設計模式？ 1.2.1 解決重複問題 在軟體開發中，我們經常遇到相似的問題。設計模式提供了經過驗證的解決方案，避免重複造輪子。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/design-pattern%E6%95%99%E5%AD%B8%E4%BA%8C/","summary":"Design Pattern 教學手冊（二）- 進階實務應用 目錄 第 1 章：設計模式概論 第 2 章：設計模式分類與全貌 第 3 章：創建型模式 第 4 章：結構型模式 第 5 章：行為型模式 第 6 章：專案應用指南 第 7 章：學習與練習 第 8 章：認證考試準備 第 9 章：附錄與資源 第 1 章：設計模式概論 1.1 設計模式的定義與歷史背景 1.1.1 什麼是設計模式？ 設計模式（Design Pattern）是在軟體開發過程中，針對常見問題的通用解決方案。它是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。\n1.1.2 Gang of Four (GoF) 的貢獻 1994年，四位軟體工程師 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 共同撰寫了《設計模式：可複用物件導向軟體的基礎》一書，定義了23個經典設計模式，被稱為「四人幫」（Gang of Four，GoF）。\ntimeline title 設計模式發展歷程 1987 : Christopher Alexander 提出建築模式概念 1994 : GoF 發表 23 個經典設計模式 1995 : Java 語言誕生，設計模式開始普及 2000 : 企業級應用廣泛採用設計模式 2010 : Spring Framework 大量運用設計模式 2020 : 微服務架構中的設計模式應用 1.2 為什麼需要設計模式？ 1.2.1 解決重複問題 在軟體開發中，我們經常遇到相似的問題。設計模式提供了經過驗證的解決方案，避免重複造輪子。\n","title":""},{"content":"Design Pattern（設計模式）教學手冊 📋 目錄 基礎入門\n1.1 什麼是 Design Pattern？ 1.2 為什麼要使用 Design Pattern？ 1.3 Design Pattern 的三大分類 1.4 在專案開發中的實際價值 1.5 學習路徑建議 1.6 注意事項與最佳實務 核心內容 - 創建型模式\n2.1 Singleton Pattern（單例模式） 2.2 Factory Method Pattern（工廠方法模式） 2.3 Builder Pattern（建造者模式） 2.4 Abstract Factory Pattern（抽象工廠模式） 2.5 Prototype Pattern（原型模式） 2.6 創建型模式總結 核心內容 - 結構型模式\n3.1 Adapter Pattern（適配器模式） 3.2 Decorator Pattern（裝飾者模式） 3.3 Facade Pattern（外觀模式） 3.4 Proxy Pattern（代理模式） 3.5 Composite Pattern（組合模式） 3.6 Bridge Pattern（橋接模式） 3.7 Flyweight Pattern（享元模式） 3.8 結構型模式總結 核心內容 - 行為型模式\n4.1 Observer Pattern（觀察者模式） 4.2 Strategy Pattern（策略模式） 4.3 Template Method Pattern（模板方法模式） 4.4 Command Pattern（命令模式） 4.5 State Pattern（狀態模式） 4.6 Chain of Responsibility Pattern（責任鏈模式） 4.7 Iterator Pattern（迭代器模式） 4.8 Mediator Pattern（中介者模式） 4.9 Memento Pattern（備忘錄模式） 4.10 Visitor Pattern（訪問者模式） 4.11 Interpreter Pattern（解釋器模式） 4.12 行為型模式實務應用 專案應用指南\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/design-pattern%E6%95%99%E5%AD%B8/","summary":"Design Pattern（設計模式）教學手冊 📋 目錄 基礎入門\n1.1 什麼是 Design Pattern？ 1.2 為什麼要使用 Design Pattern？ 1.3 Design Pattern 的三大分類 1.4 在專案開發中的實際價值 1.5 學習路徑建議 1.6 注意事項與最佳實務 核心內容 - 創建型模式\n2.1 Singleton Pattern（單例模式） 2.2 Factory Method Pattern（工廠方法模式） 2.3 Builder Pattern（建造者模式） 2.4 Abstract Factory Pattern（抽象工廠模式） 2.5 Prototype Pattern（原型模式） 2.6 創建型模式總結 核心內容 - 結構型模式\n3.1 Adapter Pattern（適配器模式） 3.2 Decorator Pattern（裝飾者模式） 3.3 Facade Pattern（外觀模式） 3.4 Proxy Pattern（代理模式） 3.5 Composite Pattern（組合模式） 3.6 Bridge Pattern（橋接模式） 3.7 Flyweight Pattern（享元模式） 3.8 結構型模式總結 核心內容 - 行為型模式\n4.1 Observer Pattern（觀察者模式） 4.2 Strategy Pattern（策略模式） 4.3 Template Method Pattern（模板方法模式） 4.4 Command Pattern（命令模式） 4.5 State Pattern（狀態模式） 4.6 Chain of Responsibility Pattern（責任鏈模式） 4.7 Iterator Pattern（迭代器模式） 4.8 Mediator Pattern（中介者模式） 4.9 Memento Pattern（備忘錄模式） 4.10 Visitor Pattern（訪問者模式） 4.11 Interpreter Pattern（解釋器模式） 4.12 行為型模式實務應用 專案應用指南\n","title":""},{"content":"Domain-Driven Design 教學手冊（一） 🎯 教學目標 本教學手冊旨在幫助開發團隊成員深入理解並正確應用 Domain-Driven Design (DDD)，從基礎概念到實際應用，最終能夠通過 DDD 認證考試。\n📚 完整目錄 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 1.2 為什麼需要 DDD 1.3 與傳統開發方式的差異 💡 實務案例：電商系統設計差異 2. DDD 的核心理念 2.1 Domain（領域）的重要性 2.2 Ubiquitous Language（通用語言） 2.3 Model-Driven Design（模型驅動設計） 3. DDD 的兩大面向 3.1 戰略設計 (Strategic Design) 3.2 戰術設計 (Tactical Design) 3.3 戰略與戰術設計的關係 💯 第一篇檢查清單（Checklist） 🎓 第一篇總結 第二篇：DDD 戰略設計 (Strategic Design) 4. 子域 (Subdomain) 的分類 4.1 什麼是子域 4.2 核心領域 (Core Domain) 4.3 支援子域 (Supporting Subdomain) 4.4 通用子域 (Generic Subdomain) 4.5 子域分類實務工作坊 5. 限界上下文 (Bounded Context) 5.1 定義與識別方法 5.2 界定上下文的準則 5.3 限界上下文的邊界劃分範例 5.4 上下文大小的考量 6. 上下文映射 (Context Mapping) 6.1 Context Map 基本圖示 6.2 上下文之間的關係模式 6.3 整合模式選擇指南 7. 案例分析 7.1 如何將真實專案切分為子域與限界上下文 7.2 分析銀行/金融系統案例 💯 第二篇檢查清單（Checklist） 🎓 第二篇總結 第三篇：DDD 戰術設計 (Tactical Design) 8. 核心構件介紹 8.1 Entity（實體） 8.2 Value Object（值物件） 8.3 Aggregate（聚合）與 Aggregate Root 8.4 Repository（倉儲） 8.5 Service（領域服務 / 應用服務） 8.6 Factory（工廠） 💯 第三篇檢查清單（Checklist） 第四篇：DDD 與實務應用 9. 領域事件 (Domain Events) 9.1 什麼是領域事件 9.2 事件發布與訂閱模式 9.3 Event Sourcing 9.4 CQRS 與 DDD 的結合 10. 模組化與分層架構 10.1 DDD 分層架構 10.2 Hexagonal Architecture（六角架構） 10.3 Clean Architecture 11. 在微服務架構中的 DDD 11.1 Bounded Context 與微服務的對應 11.2 微服務邊界設計 11.3 資料一致性策略 12. 與敏捷、Scrum 的整合 12.1 Event Storming 12.2 Domain Storytelling 12.3 Scrum 中的 DDD 實踐 13. 專案最佳實踐 13.1 常見錯誤與反模式 13.2 成功案例分享 13.3 DDD 導入路線圖 💯 第四篇檢查清單（Checklist） 第五篇：學習檢測與認證準備 14. 章節小測驗 14.1 第一篇：基礎入門 - 測驗題 14.2 第二篇：戰略設計 - 測驗題 14.3 第三篇：戰術設計 - 測驗題 14.4 第四篇：實務應用 - 測驗題 15. DDD 認證考試重點整理 15.1 必考核心概念 15.2 認證準備策略 16. 模擬測驗題庫 16.1 綜合模擬試題 16.2 模擬試題答案 💯 第五篇檢查清單（Checklist） 附錄 A. 快速參考指南 A.1 DDD 核心概念速查表 B. 成功案例研究 B.1 電商平台 DDD 實施 C. 推薦資源 C.1 經典書籍 C.2 線上資源 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 Domain-Driven Design（領域驅動設計）是由 Eric Evans 在 2003 年出版的同名書籍中首次系統性提出的軟體開發方法論。DDD 的核心思想是將複雜的業務邏輯透過領域模型來表達，讓軟體設計更貼近實際業務需求。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/domain-driven-design%E6%95%99%E5%AD%B8%E4%B8%80/","summary":"Domain-Driven Design 教學手冊（一） 🎯 教學目標 本教學手冊旨在幫助開發團隊成員深入理解並正確應用 Domain-Driven Design (DDD)，從基礎概念到實際應用，最終能夠通過 DDD 認證考試。\n📚 完整目錄 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 1.2 為什麼需要 DDD 1.3 與傳統開發方式的差異 💡 實務案例：電商系統設計差異 2. DDD 的核心理念 2.1 Domain（領域）的重要性 2.2 Ubiquitous Language（通用語言） 2.3 Model-Driven Design（模型驅動設計） 3. DDD 的兩大面向 3.1 戰略設計 (Strategic Design) 3.2 戰術設計 (Tactical Design) 3.3 戰略與戰術設計的關係 💯 第一篇檢查清單（Checklist） 🎓 第一篇總結 第二篇：DDD 戰略設計 (Strategic Design) 4. 子域 (Subdomain) 的分類 4.1 什麼是子域 4.2 核心領域 (Core Domain) 4.3 支援子域 (Supporting Subdomain) 4.4 通用子域 (Generic Subdomain) 4.5 子域分類實務工作坊 5. 限界上下文 (Bounded Context) 5.1 定義與識別方法 5.2 界定上下文的準則 5.3 限界上下文的邊界劃分範例 5.4 上下文大小的考量 6. 上下文映射 (Context Mapping) 6.1 Context Map 基本圖示 6.2 上下文之間的關係模式 6.3 整合模式選擇指南 7. 案例分析 7.1 如何將真實專案切分為子域與限界上下文 7.2 分析銀行/金融系統案例 💯 第二篇檢查清單（Checklist） 🎓 第二篇總結 第三篇：DDD 戰術設計 (Tactical Design) 8. 核心構件介紹 8.1 Entity（實體） 8.2 Value Object（值物件） 8.3 Aggregate（聚合）與 Aggregate Root 8.4 Repository（倉儲） 8.5 Service（領域服務 / 應用服務） 8.6 Factory（工廠） 💯 第三篇檢查清單（Checklist） 第四篇：DDD 與實務應用 9. 領域事件 (Domain Events) 9.1 什麼是領域事件 9.2 事件發布與訂閱模式 9.3 Event Sourcing 9.4 CQRS 與 DDD 的結合 10. 模組化與分層架構 10.1 DDD 分層架構 10.2 Hexagonal Architecture（六角架構） 10.3 Clean Architecture 11. 在微服務架構中的 DDD 11.1 Bounded Context 與微服務的對應 11.2 微服務邊界設計 11.3 資料一致性策略 12. 與敏捷、Scrum 的整合 12.1 Event Storming 12.2 Domain Storytelling 12.3 Scrum 中的 DDD 實踐 13. 專案最佳實踐 13.1 常見錯誤與反模式 13.2 成功案例分享 13.3 DDD 導入路線圖 💯 第四篇檢查清單（Checklist） 第五篇：學習檢測與認證準備 14. 章節小測驗 14.1 第一篇：基礎入門 - 測驗題 14.2 第二篇：戰略設計 - 測驗題 14.3 第三篇：戰術設計 - 測驗題 14.4 第四篇：實務應用 - 測驗題 15. DDD 認證考試重點整理 15.1 必考核心概念 15.2 認證準備策略 16. 模擬測驗題庫 16.1 綜合模擬試題 16.2 模擬試題答案 💯 第五篇檢查清單（Checklist） 附錄 A. 快速參考指南 A.1 DDD 核心概念速查表 B. 成功案例研究 B.1 電商平台 DDD 實施 C. 推薦資源 C.1 經典書籍 C.2 線上資源 第一篇：基礎入門 1. 什麼是 Domain-Driven Design (DDD) 1.1 背景與歷史 Domain-Driven Design（領域驅動設計）是由 Eric Evans 在 2003 年出版的同名書籍中首次系統性提出的軟體開發方法論。DDD 的核心思想是將複雜的業務邏輯透過領域模型來表達，讓軟體設計更貼近實際業務需求。\n","title":""},{"content":"Domain-Driven Design (DDD) 教學手冊 專為新進開發同仁設計的 DDD 學習指南\n適用技術棧：Vue 3.x (前端) + Spring Boot (後端) + 前後端分離架構\n📚 目錄 DDD 基礎概念\n1.1 什麼是 Domain-Driven Design？ 1.2 DDD 核心概念概覽 1.3 DDD 的三層架構 1.4 實務案例：電商系統 核心構建塊 (Building Blocks)\n2.1 Entity (實體) 2.2 Value Object (值對象) 2.3 Aggregate (聚合) 2.4 Repository (儲存庫) 2.5 Domain Service (領域服務) 戰略設計 (Strategic Design)\n3.1 Domain、Subdomain 識別 3.2 Bounded Context (有界上下文) 3.3 Context Map (上下文映射) 3.4 Ubiquitous Language (統一語言) 3.5 Event Storming 實務應用 戰術設計 (Tactical Design)\n4.1 Domain Events (領域事件) 4.2 Factory Pattern 在 DDD 中的應用 4.3 Specification Pattern (規格模式) DDD 在專案中的實際應用\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/domain-driven-design%E6%95%99%E5%AD%B8/","summary":"Domain-Driven Design (DDD) 教學手冊 專為新進開發同仁設計的 DDD 學習指南\n適用技術棧：Vue 3.x (前端) + Spring Boot (後端) + 前後端分離架構\n📚 目錄 DDD 基礎概念\n1.1 什麼是 Domain-Driven Design？ 1.2 DDD 核心概念概覽 1.3 DDD 的三層架構 1.4 實務案例：電商系統 核心構建塊 (Building Blocks)\n2.1 Entity (實體) 2.2 Value Object (值對象) 2.3 Aggregate (聚合) 2.4 Repository (儲存庫) 2.5 Domain Service (領域服務) 戰略設計 (Strategic Design)\n3.1 Domain、Subdomain 識別 3.2 Bounded Context (有界上下文) 3.3 Context Map (上下文映射) 3.4 Ubiquitous Language (統一語言) 3.5 Event Storming 實務應用 戰術設計 (Tactical Design)\n4.1 Domain Events (領域事件) 4.2 Factory Pattern 在 DDD 中的應用 4.3 Specification Pattern (規格模式) DDD 在專案中的實際應用\n","title":""},{"content":"Entity-Relationship Model (ER Model) 教學手冊 📋 目錄 基礎知識\n1.1 什麼是 ER Model 1.2 核心概念 1.3 ERD 符號與規則 1.4 基礎實作練習 專案應用\n2.1 需求分析到 ER Model 2.2 案例研究：電商平台 2.3 案例研究：銀行系統 2.4 轉換為資料庫 Schema 2.5 完整專案開發流程 進階主題\n3.1 實體類型與關聯度 3.2 正規化理論 3.3 常見設計錯誤 3.4 最佳實務 認證準備\n4.1 認證內容與範圍 4.2 練習題庫 4.3 模擬考題 4.4 重點知識摘要 學習路徑\n5.1 學習步驟建議 5.2 推薦工具 5.3 進階學習資源 檢查清單\n6.1 設計階段檢查清單 6.2 資料庫實作檢查清單 6.3 品質保證檢查清單 6.4 專案交付檢查清單 6.5 學習成果檢核 6.6 持續改進檢查 附錄\nA. ERD 符號速查表 B. SQL 資料型別對照表 C. 常用正規化檢查 SQL D. 設計模式範本 E. 效能優化檢查清單 F. 安全性檢查清單 G. 版本更新記錄 🚀 快速開始 📖 學習建議 如果您是第一次接觸 ER Model，建議按照以下順序學習：\n🔰 初學者路徑（預估 2-3 週） 📚 基礎建立：先閱讀「基礎知識」章節，建立基本概念 🛠️ 實作練習：透過「專案應用」的案例練習實作 📈 深化理解：學習「進階主題」深化理解 ✅ 成果驗證：使用「檢查清單」驗證學習成果 🎯 進階用戶路徑 如果您已具備基礎概念，可直接從第 2 章「專案應用」開始 需要準備認證考試的用戶，重點關注第 4 章「認證準備」 尋找工具和資源的用戶，參考第 5 章「學習路徑」 ⏱️ 時間投入建議 基礎學習：每天 1-2 小時，持續 2-3 週 實作練習：每週 3-5 小時的專案實作 認證準備：額外 2-3 週的集中複習 1. 基礎知識 1.1 什麼是 ER Model Entity-Relationship Model（實體關係模型） 是一種用來描述現實世界資料結構的概念模型。它幫助我們：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/entity-relationship-model-er-model-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Entity-Relationship Model (ER Model) 教學手冊 📋 目錄 基礎知識\n1.1 什麼是 ER Model 1.2 核心概念 1.3 ERD 符號與規則 1.4 基礎實作練習 專案應用\n2.1 需求分析到 ER Model 2.2 案例研究：電商平台 2.3 案例研究：銀行系統 2.4 轉換為資料庫 Schema 2.5 完整專案開發流程 進階主題\n3.1 實體類型與關聯度 3.2 正規化理論 3.3 常見設計錯誤 3.4 最佳實務 認證準備\n4.1 認證內容與範圍 4.2 練習題庫 4.3 模擬考題 4.4 重點知識摘要 學習路徑\n5.1 學習步驟建議 5.2 推薦工具 5.3 進階學習資源 檢查清單\n6.1 設計階段檢查清單 6.2 資料庫實作檢查清單 6.3 品質保證檢查清單 6.4 專案交付檢查清單 6.5 學習成果檢核 6.6 持續改進檢查 附錄\nA. ERD 符號速查表 B. SQL 資料型別對照表 C. 常用正規化檢查 SQL D. 設計模式範本 E. 效能優化檢查清單 F. 安全性檢查清單 G. 版本更新記錄 🚀 快速開始 📖 學習建議 如果您是第一次接觸 ER Model，建議按照以下順序學習：\n🔰 初學者路徑（預估 2-3 週） 📚 基礎建立：先閱讀「基礎知識」章節，建立基本概念 🛠️ 實作練習：透過「專案應用」的案例練習實作 📈 深化理解：學習「進階主題」深化理解 ✅ 成果驗證：使用「檢查清單」驗證學習成果 🎯 進階用戶路徑 如果您已具備基礎概念，可直接從第 2 章「專案應用」開始 需要準備認證考試的用戶，重點關注第 4 章「認證準備」 尋找工具和資源的用戶，參考第 5 章「學習路徑」 ⏱️ 時間投入建議 基礎學習：每天 1-2 小時，持續 2-3 週 實作練習：每週 3-5 小時的專案實作 認證準備：額外 2-3 週的集中複習 1. 基礎知識 1.1 什麼是 ER Model Entity-Relationship Model（實體關係模型） 是一種用來描述現實世界資料結構的概念模型。它幫助我們：\n","title":""},{"content":"Hexagonal Architecture 設計教學手冊 📚 文件說明 本教學手冊旨在幫助新進同仁快速理解和應用 Hexagonal Architecture（六邊形架構）。透過循序漸進的方式，從基礎概念到實務應用，讓團隊成員能夠有效地運用這種架構模式進行軟體開發。\n🎯 學習目標 理解 Hexagonal Architecture 的核心概念與設計理念 掌握 Ports \u0026amp; Adapters 模式的實作技巧 學會在實際專案中導入六邊形架構 提升程式碼的可測試性與可維護性 建立與團隊協作的共同語言 📖 目錄 Part 1. 基礎概念 認識 Hexagonal Architecture（六邊形架構）\n1.1 Hexagonal 的由來與核心理念 1.2 與傳統分層架構的比較 1.3 Ports \u0026amp; Adapters 模式的核心概念 Hexagonal Architecture 的設計目標\n2.1 解耦業務邏輯與基礎設施 2.2 減少技術債務與提升可測試性 2.3 支援 Domain-Driven Design 的角色 Hexagonal 與其他架構模式的關係\n3.1 與 Clean Architecture 的異同 3.2 與 Onion Architecture 的異同 3.3 適用場景與限制 Part 2. 核心組件與實作模式 Ports \u0026amp; Adapters 詳解\n4.1 定義與職責 4.2 輸入 Port / 輸出 Port 4.3 主動 Adapter / 被動 Adapter Domain 層的角色\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/hexagonal-architecture%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Hexagonal Architecture 設計教學手冊 📚 文件說明 本教學手冊旨在幫助新進同仁快速理解和應用 Hexagonal Architecture（六邊形架構）。透過循序漸進的方式，從基礎概念到實務應用，讓團隊成員能夠有效地運用這種架構模式進行軟體開發。\n🎯 學習目標 理解 Hexagonal Architecture 的核心概念與設計理念 掌握 Ports \u0026amp; Adapters 模式的實作技巧 學會在實際專案中導入六邊形架構 提升程式碼的可測試性與可維護性 建立與團隊協作的共同語言 📖 目錄 Part 1. 基礎概念 認識 Hexagonal Architecture（六邊形架構）\n1.1 Hexagonal 的由來與核心理念 1.2 與傳統分層架構的比較 1.3 Ports \u0026amp; Adapters 模式的核心概念 Hexagonal Architecture 的設計目標\n2.1 解耦業務邏輯與基礎設施 2.2 減少技術債務與提升可測試性 2.3 支援 Domain-Driven Design 的角色 Hexagonal 與其他架構模式的關係\n3.1 與 Clean Architecture 的異同 3.2 與 Onion Architecture 的異同 3.3 適用場景與限制 Part 2. 核心組件與實作模式 Ports \u0026amp; Adapters 詳解\n4.1 定義與職責 4.2 輸入 Port / 輸出 Port 4.3 主動 Adapter / 被動 Adapter Domain 層的角色\n","title":""},{"content":"Microservices Architecture 設計教學手冊 版本： 1.0\n更新日期： 2025年9月20日\n適用對象： 新進開發同仁\n編寫者： 系統架構師團隊\n📖 手冊簡介 本手冊是為新進開發同仁設計的微服務架構（Microservices Architecture）實務教學文件。透過系統性的學習路徑，幫助開發人員從零基礎逐步掌握微服務設計與實作技能。\n🎯 學習目標 完成本手冊學習後，您將能夠：\n理解微服務架構的核心概念與設計原則 掌握微服務拆分與邊界劃分技巧 熟練應用各種微服務設計模式 具備實際專案開發與維護能力 通過相關技術認證考試 🚀 使用方式 循序漸進：按照章節順序學習，每章都有前置知識 理論實作並重：理解概念後立即進行實作練習 檢查清單驗證：每章結束使用檢查清單自我驗證 團隊討論：與同事分享學習心得，加深理解 📚 目錄 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 1.2 單體架構 vs. 微服務架構 1.3 微服務的核心特徵 1.4 適用與不適用場景 2. 微服務與業界標準 2.1 SOA 與微服務的差異 2.2 Cloud Native 與微服務 2.3 與 Microservices Architecture 認證的關聯 Part II. 微服務設計原則 3. 微服務設計的基本原則 3.1 單一職責原則 (SRP) 3.2 高內聚、低耦合 3.3 獨立部署與擴展 3.4 容錯與恢復能力 4. 微服務邊界劃分 4.1 領域驅動設計 (DDD) 基礎 4.2 限界上下文 (Bounded Context) 4.3 服務拆分策略 Part III. 技術架構 5. 微服務通訊模式 5.1 同步通訊 5.2 非同步通訊 5.3 事件驅動架構 6. 資料管理策略 7. 配置與服務發現 Part IV. 微服務設計模式 8. 分解模式 8.1 Database per Service Pattern 8.2 Strangler Fig Pattern 8.3 Self-Contained Service Pattern 9. 通訊模式 9.1 API Gateway Pattern 9.2 Backend for Frontend (BFF) Pattern 10. 資料管理模式 10.1 Saga Pattern 10.2 CQRS Pattern 10.3 Event Sourcing Pattern 11. 可靠性模式 11.1 Circuit Breaker Pattern 11.2 Retry Pattern 11.3 Bulkhead Pattern Part V. 跨領域關注點 12. 安全性架構 12.1 身份驗證與授權 12.2 資料保護與加密 13. 監控與可觀察性 13.1 分散式追蹤 13.2 指標收集與監控 13.3 健康檢查與服務探測 14. 配置管理 14.1 集中化配置管理 14.2 功能開關 (Feature Toggles) Part VI. DevOps 與微服務 15. CI/CD 流水線 16. 容器化與 Kubernetes 17. Infrastructure as Code Part VII. 實戰指南 18. 微服務專案規劃 19. 實作步驟與最佳實務 20. 測試策略 21. 效能調優 Part VIII. 總結與資源 總結 最佳實務摘要 延伸學習資源 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 🔍 單體架構的挑戰 在傳統的單體架構（Monolithic Architecture）中，整個應用程式被打包成一個單一的部署單元。隨著業務成長，會面臨以下問題：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/microservices-architecture-%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Microservices Architecture 設計教學手冊 版本： 1.0\n更新日期： 2025年9月20日\n適用對象： 新進開發同仁\n編寫者： 系統架構師團隊\n📖 手冊簡介 本手冊是為新進開發同仁設計的微服務架構（Microservices Architecture）實務教學文件。透過系統性的學習路徑，幫助開發人員從零基礎逐步掌握微服務設計與實作技能。\n🎯 學習目標 完成本手冊學習後，您將能夠：\n理解微服務架構的核心概念與設計原則 掌握微服務拆分與邊界劃分技巧 熟練應用各種微服務設計模式 具備實際專案開發與維護能力 通過相關技術認證考試 🚀 使用方式 循序漸進：按照章節順序學習，每章都有前置知識 理論實作並重：理解概念後立即進行實作練習 檢查清單驗證：每章結束使用檢查清單自我驗證 團隊討論：與同事分享學習心得，加深理解 📚 目錄 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 1.2 單體架構 vs. 微服務架構 1.3 微服務的核心特徵 1.4 適用與不適用場景 2. 微服務與業界標準 2.1 SOA 與微服務的差異 2.2 Cloud Native 與微服務 2.3 與 Microservices Architecture 認證的關聯 Part II. 微服務設計原則 3. 微服務設計的基本原則 3.1 單一職責原則 (SRP) 3.2 高內聚、低耦合 3.3 獨立部署與擴展 3.4 容錯與恢復能力 4. 微服務邊界劃分 4.1 領域驅動設計 (DDD) 基礎 4.2 限界上下文 (Bounded Context) 4.3 服務拆分策略 Part III. 技術架構 5. 微服務通訊模式 5.1 同步通訊 5.2 非同步通訊 5.3 事件驅動架構 6. 資料管理策略 7. 配置與服務發現 Part IV. 微服務設計模式 8. 分解模式 8.1 Database per Service Pattern 8.2 Strangler Fig Pattern 8.3 Self-Contained Service Pattern 9. 通訊模式 9.1 API Gateway Pattern 9.2 Backend for Frontend (BFF) Pattern 10. 資料管理模式 10.1 Saga Pattern 10.2 CQRS Pattern 10.3 Event Sourcing Pattern 11. 可靠性模式 11.1 Circuit Breaker Pattern 11.2 Retry Pattern 11.3 Bulkhead Pattern Part V. 跨領域關注點 12. 安全性架構 12.1 身份驗證與授權 12.2 資料保護與加密 13. 監控與可觀察性 13.1 分散式追蹤 13.2 指標收集與監控 13.3 健康檢查與服務探測 14. 配置管理 14.1 集中化配置管理 14.2 功能開關 (Feature Toggles) Part VI. DevOps 與微服務 15. CI/CD 流水線 16. 容器化與 Kubernetes 17. Infrastructure as Code Part VII. 實戰指南 18. 微服務專案規劃 19. 實作步驟與最佳實務 20. 測試策略 21. 效能調優 Part VIII. 總結與資源 總結 最佳實務摘要 延伸學習資源 Part I. 基礎認識 1. 微服務架構簡介 1.1 為什麼需要微服務 🔍 單體架構的挑戰 在傳統的單體架構（Monolithic Architecture）中，整個應用程式被打包成一個單一的部署單元。隨著業務成長，會面臨以下問題：\n","title":""},{"content":"Object-Relational Mapping (ORM) 物件關聯對映教學手冊 目錄 ORM 簡介\n1.1 什麼是 ORM？ 1.2 為什麼需要 ORM？ 1.3 ORM 解決的問題 1.4 與 SQL/資料庫互動的關係 1.5 小結 ORM 的基本概念\n2.1 實體 (Entity) 2.2 對應 (Mapping) 2.3 Session/EntityManager 2.4 Transaction (交易) 2.5 Lazy Loading vs Eager Loading 2.6 小結 ORM 工具與框架簡介\n3.1 Java 生態系統 3.2 Python 生態系統 3.3 其他語言的 ORM 框架 3.4 ORM 框架比較 3.5 選擇 ORM 框架的考量因素 3.6 小結 安裝與設定\n4.1 Java 環境設定 (Spring Boot + JPA) 4.2 Python 環境設定 (SQLAlchemy) 4.3 開發環境驗證 4.4 常見安裝問題與解決方案 4.5 小結 基本 CRUD 範例\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/object-relational-mapping-orm-%E7%89%A9%E4%BB%B6%E9%97%9C%E8%81%AF%E5%B0%8D%E6%98%A0%E6%95%99%E5%AD%B8/","summary":"Object-Relational Mapping (ORM) 物件關聯對映教學手冊 目錄 ORM 簡介\n1.1 什麼是 ORM？ 1.2 為什麼需要 ORM？ 1.3 ORM 解決的問題 1.4 與 SQL/資料庫互動的關係 1.5 小結 ORM 的基本概念\n2.1 實體 (Entity) 2.2 對應 (Mapping) 2.3 Session/EntityManager 2.4 Transaction (交易) 2.5 Lazy Loading vs Eager Loading 2.6 小結 ORM 工具與框架簡介\n3.1 Java 生態系統 3.2 Python 生態系統 3.3 其他語言的 ORM 框架 3.4 ORM 框架比較 3.5 選擇 ORM 框架的考量因素 3.6 小結 安裝與設定\n4.1 Java 環境設定 (Spring Boot + JPA) 4.2 Python 環境設定 (SQLAlchemy) 4.3 開發環境驗證 4.4 常見安裝問題與解決方案 4.5 小結 基本 CRUD 範例\n","title":""},{"content":"Onion Architecture 設計教學手冊 版本：1.0\n日期：2025年9月20日\n適用對象：Java 開發新進同仁\n目標：學習 Onion Architecture 設計與認證準備\n📚 目錄 第 1 章：緒論\n1.1 教學手冊的目的與對象 1.2 為什麼需要 Onion Architecture 1.3 與傳統分層架構、Hexagonal Architecture、Clean Architecture 的比較 1.4 如何透過本手冊準備 Onion Architecture 認證 第 2 章：Onion Architecture 基礎概念\n2.1 Onion Architecture 的核心理念 2.2 各層級設計原則 2.3 依賴反轉原則 (Dependency Inversion Principle) 2.4 Onion Architecture 的優點與限制 第 3 章：分層解析\n3.1 Domain Layer - 實體與商業規則 3.2 Application Layer - 用例與服務 3.3 Infrastructure Layer - 技術支援與外部資源 3.4 Presentation Layer - 使用者介面與 API 3.5 層與層之間的互動與依賴管理 第 4 章：實作指南\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/onion-architecture-%E8%A8%AD%E8%A8%88%E6%95%99%E5%AD%B8/","summary":"Onion Architecture 設計教學手冊 版本：1.0\n日期：2025年9月20日\n適用對象：Java 開發新進同仁\n目標：學習 Onion Architecture 設計與認證準備\n📚 目錄 第 1 章：緒論\n1.1 教學手冊的目的與對象 1.2 為什麼需要 Onion Architecture 1.3 與傳統分層架構、Hexagonal Architecture、Clean Architecture 的比較 1.4 如何透過本手冊準備 Onion Architecture 認證 第 2 章：Onion Architecture 基礎概念\n2.1 Onion Architecture 的核心理念 2.2 各層級設計原則 2.3 依賴反轉原則 (Dependency Inversion Principle) 2.4 Onion Architecture 的優點與限制 第 3 章：分層解析\n3.1 Domain Layer - 實體與商業規則 3.2 Application Layer - 用例與服務 3.3 Infrastructure Layer - 技術支援與外部資源 3.4 Presentation Layer - 使用者介面與 API 3.5 層與層之間的互動與依賴管理 第 4 章：實作指南\n","title":""},{"content":"Refactoring（重構）教學手冊 📚 目錄 重構基本概念\n1.1 什麼是重構？ 1.2 重構的目標 1.3 重構 vs 重寫 1.4 實務案例 重構的基本原則\n2.1 紅燈-綠燈-重構循環 2.2 重構的黃金法則 2.3 重構的時機 2.4 安全重構的步驟 2.5 實務注意事項 識別壞味道（Code Smells）\n3.1 什麼是程式碼壞味道？ 3.2 常見的程式碼壞味道 3.2.1 過長方法（Long Method） 3.2.2 過多參數（Long Parameter List） 3.2.3 重複程式碼（Duplicated Code） 3.2.4 過大類別（Large Class） 3.2.5 壞味道的量化指標 3.3 壞味道識別工具 3.4 實務練習 常見重構方法\n4.1 方法層級重構 4.1.1 Extract Method（提取方法） 4.1.2 Rename Variable（重新命名變數） 4.1.3 Introduce Parameter Object（引入參數物件） 4.1.4 Replace Method with Method Object（以方法物件取代方法） 4.2 類別層級重構 4.2.1 Extract Class（提取類別） 4.2.2 Move Method（搬移方法） 4.3 條件邏輯重構 4.3.1 Replace Conditional with Polymorphism（以多型取代條件式） 4.4 重構方法選擇流程 4.4.1 重構決策樹 4.4.2 重構優先順序指南 4.5 實務練習 重構與測試的關聯\n5.1 重構的安全網：單元測試 5.2 測試先行的重構策略 5.3 TDD 與重構的結合 5.4 重構時的測試最佳實務 5.5 重構測試檢查清單 實務應用策略\n6.1 重構時機的判斷 6.2 團隊重構策略 6.3 大型專案重構策略 6.4 效能考量 6.5 重構實務指引 團隊規範與最佳實務\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/refactoring%E9%87%8D%E6%A7%8B%E6%95%99%E5%AD%B8/","summary":"Refactoring（重構）教學手冊 📚 目錄 重構基本概念\n1.1 什麼是重構？ 1.2 重構的目標 1.3 重構 vs 重寫 1.4 實務案例 重構的基本原則\n2.1 紅燈-綠燈-重構循環 2.2 重構的黃金法則 2.3 重構的時機 2.4 安全重構的步驟 2.5 實務注意事項 識別壞味道（Code Smells）\n3.1 什麼是程式碼壞味道？ 3.2 常見的程式碼壞味道 3.2.1 過長方法（Long Method） 3.2.2 過多參數（Long Parameter List） 3.2.3 重複程式碼（Duplicated Code） 3.2.4 過大類別（Large Class） 3.2.5 壞味道的量化指標 3.3 壞味道識別工具 3.4 實務練習 常見重構方法\n4.1 方法層級重構 4.1.1 Extract Method（提取方法） 4.1.2 Rename Variable（重新命名變數） 4.1.3 Introduce Parameter Object（引入參數物件） 4.1.4 Replace Method with Method Object（以方法物件取代方法） 4.2 類別層級重構 4.2.1 Extract Class（提取類別） 4.2.2 Move Method（搬移方法） 4.3 條件邏輯重構 4.3.1 Replace Conditional with Polymorphism（以多型取代條件式） 4.4 重構方法選擇流程 4.4.1 重構決策樹 4.4.2 重構優先順序指南 4.5 實務練習 重構與測試的關聯\n5.1 重構的安全網：單元測試 5.2 測試先行的重構策略 5.3 TDD 與重構的結合 5.4 重構時的測試最佳實務 5.5 重構測試檢查清單 實務應用策略\n6.1 重構時機的判斷 6.2 團隊重構策略 6.3 大型專案重構策略 6.4 效能考量 6.5 重構實務指引 團隊規範與最佳實務\n","title":""},{"content":"Spec-Kit 使用教學手冊 版本: 1.0\n最後更新: 2025年10月29日\n適用於: Spec-Kit v0.0.79+ Created by: Eric Cheng\n📚 目錄 前言 目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解 1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備 2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 第三章:使用流程詳細說明 3.1 Step 1:撰寫 Spec (/speckit.specify) 3.2 Step 1a:澄清模糊需求 (/speckit.clarify) 3.3 Step 2:撰寫 Plan (/speckit.plan) 3.4 Step 3:拆分 Tasks (/speckit.tasks) 3.5 Step 4:預實作檢查 (/speckit.analyze + /speckit.checklist) 3.6 Step 5:實作 (/speckit.implement) 3.7 Step 6:迭代維護 第四章:實務案例與應用指引 4.1 案例一:Greenfield 開發 - 新建交易記錄微服務 4.2 案例二:Brownfield 整合 - 為既有系統新增功能 4.3 團隊協作:多人開發 4.4 AI 助手最佳實踐 4.5 平台導入建議 第五章:常見問題與陷阱 5.1 常見問題(FAQ) 5.2 常見陷阱與避免方法 第六章:附錄 6.1 完整模板範例 6.2 檢查清單 6.3 參考資源 6.4 術語表 6.5 快速指令參考 結語 前言 目的與適用對象 本手冊旨在幫助開發團隊快速掌握 Spec-Driven Development (SDD) 方法論,並透過 Spec-Kit 工具組與 AI 助手協作,建立高品質、可維護的軟體系統。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/spec-kit%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Spec-Kit 使用教學手冊 版本: 1.0\n最後更新: 2025年10月29日\n適用於: Spec-Kit v0.0.79+ Created by: Eric Cheng\n📚 目錄 前言 目的與適用對象 背景說明:為何採用 SDD + Spec-Kit → AI 助手流程 本手冊使用假設 第一章:概念理解 1.1 SDD 是什麼? 1.2 Spec-Kit 概覽 1.3 SDD 中的關鍵 artefacts(工件) 1.4 流程概覽:SDD 的階段/步驟 1.5 為什麼這對我們團隊/共用平台開發特別有價值 第二章:環境準備 2.1 前置條件 2.2 安裝 Spec-Kit CLI 2.3 建立專案與初始化 2.4 建立團隊守則 (Constitution) 2.5 模板與提示文件說明 2.6 GitHub 倉庫分支與版本控制建議 第三章:使用流程詳細說明 3.1 Step 1:撰寫 Spec (/speckit.specify) 3.2 Step 1a:澄清模糊需求 (/speckit.clarify) 3.3 Step 2:撰寫 Plan (/speckit.plan) 3.4 Step 3:拆分 Tasks (/speckit.tasks) 3.5 Step 4:預實作檢查 (/speckit.analyze + /speckit.checklist) 3.6 Step 5:實作 (/speckit.implement) 3.7 Step 6:迭代維護 第四章:實務案例與應用指引 4.1 案例一:Greenfield 開發 - 新建交易記錄微服務 4.2 案例二:Brownfield 整合 - 為既有系統新增功能 4.3 團隊協作:多人開發 4.4 AI 助手最佳實踐 4.5 平台導入建議 第五章:常見問題與陷阱 5.1 常見問題(FAQ) 5.2 常見陷阱與避免方法 第六章:附錄 6.1 完整模板範例 6.2 檢查清單 6.3 參考資源 6.4 術語表 6.5 快速指令參考 結語 前言 目的與適用對象 本手冊旨在幫助開發團隊快速掌握 Spec-Driven Development (SDD) 方法論,並透過 Spec-Kit 工具組與 AI 助手協作,建立高品質、可維護的軟體系統。\n","title":""},{"content":"物件導向分析與設計 (OOAD) 教學手冊 作者: 系統架構師團隊\n更新日期: 2025年9月1日\n適用對象: 新進開發同仁\n版本: v1.0\n📚 目錄 前言與學習目標\n1.1 為什麼要學習 OOAD？ 1.2 學習目標 1.3 學習路徑 1.4 前置知識 OOAD 基礎概念\n2.1 什麼是物件導向？ 2.2 核心概念詳解 2.3 OOAD 的設計原則 2.4 實務案例：學生管理系統 2.5 章節小結 OOAD 開發流程\n3.1 OOAD 流程概覽 3.2 階段一：需求分析 3.3 階段二：系統分析 3.4 階段三：系統設計 3.5 階段四：詳細設計 3.6 階段五：程式實作 3.7 階段六：測試與驗證 3.8 章節小結 UML 與 OOAD 的關係\n4.1 UML 簡介 4.2 UML 圖形分類 4.3 核心 UML 圖形詳解 4.4 UML 工具與最佳實務 4.5 章節小結 專案實務應用範例\n5.1 專案背景：大學課程管理系統 5.2 階段一：需求分析與 Use Case 設計 5.3 階段二：領域分析與建模 5.4 階段三：架構設計 5.5 階段四：詳細設計 5.6 階段五：關鍵循序圖 5.7 實作關鍵功能 5.8 章節小結 常見錯誤與最佳實務\n6.1 分析階段常見錯誤 6.2 設計階段常見錯誤 6.3 實作階段常見錯誤 6.4 UML 建模最佳實務 6.5 程式碼品質準則 6.6 效能與安全性考量 6.7 章節小結 UML 認證考試重點\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E7%89%A9%E4%BB%B6%E5%B0%8E%E5%90%91%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88-ooad-%E6%95%99%E5%AD%B8/","summary":"物件導向分析與設計 (OOAD) 教學手冊 作者: 系統架構師團隊\n更新日期: 2025年9月1日\n適用對象: 新進開發同仁\n版本: v1.0\n📚 目錄 前言與學習目標\n1.1 為什麼要學習 OOAD？ 1.2 學習目標 1.3 學習路徑 1.4 前置知識 OOAD 基礎概念\n2.1 什麼是物件導向？ 2.2 核心概念詳解 2.3 OOAD 的設計原則 2.4 實務案例：學生管理系統 2.5 章節小結 OOAD 開發流程\n3.1 OOAD 流程概覽 3.2 階段一：需求分析 3.3 階段二：系統分析 3.4 階段三：系統設計 3.5 階段四：詳細設計 3.6 階段五：程式實作 3.7 階段六：測試與驗證 3.8 章節小結 UML 與 OOAD 的關係\n4.1 UML 簡介 4.2 UML 圖形分類 4.3 核心 UML 圖形詳解 4.4 UML 工具與最佳實務 4.5 章節小結 專案實務應用範例\n5.1 專案背景：大學課程管理系統 5.2 階段一：需求分析與 Use Case 設計 5.3 階段二：領域分析與建模 5.4 階段三：架構設計 5.5 階段四：詳細設計 5.6 階段五：關鍵循序圖 5.7 實作關鍵功能 5.8 章節小結 常見錯誤與最佳實務\n6.1 分析階段常見錯誤 6.2 設計階段常見錯誤 6.3 實作階段常見錯誤 6.4 UML 建模最佳實務 6.5 程式碼品質準則 6.6 效能與安全性考量 6.7 章節小結 UML 認證考試重點\n","title":""},{"content":"統一建模語言(UML)教學手冊 目錄 UML 基礎概念\n1.1 什麼是 UML？ 1.2 UML 的用途與價值 1.3 UML 圖表分類 1.4 實務注意事項 常用 UML 圖表教學\n2.1 用例圖（Use Case Diagram） 2.2 類別圖（Class Diagram） 2.3 序列圖（Sequence Diagram） 2.4 活動圖（Activity Diagram） 2.5 狀態圖（State Diagram） 2.6 元件圖（Component Diagram） 2.7 部署圖（Deployment Diagram） 實務應用情境\n3.1 專案生命週期中的 UML 應用 3.2 不同專案類型的 UML 選擇 3.3 團隊協作中的 UML 專案實作指引\n4.1 UML 建模流程 4.2 我們專案中的 UML 應用範例 4.3 建模最佳實務 工具介紹\n5.1 常用 UML 工具比較 5.2 PlantUML 詳細介紹 5.3 在我們專案中整合 UML 工具 實務範例：學生管理系統\n6.1 專案背景 6.2 Step-by-Step UML 建模 6.3 架構設計 - 元件圖 6.4 部署建模 - 部署圖 6.5 其他領域實務範例 6.6 跨領域建模經驗總結 認證考試準備\n7.1 OMG UML 認證概述 7.2 考試重點知識 7.3 學習路線圖 7.4 考試技巧 附錄\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E7%B5%B1%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AA%9E%E8%A8%80uml%E6%95%99%E5%AD%B8/","summary":"統一建模語言(UML)教學手冊 目錄 UML 基礎概念\n1.1 什麼是 UML？ 1.2 UML 的用途與價值 1.3 UML 圖表分類 1.4 實務注意事項 常用 UML 圖表教學\n2.1 用例圖（Use Case Diagram） 2.2 類別圖（Class Diagram） 2.3 序列圖（Sequence Diagram） 2.4 活動圖（Activity Diagram） 2.5 狀態圖（State Diagram） 2.6 元件圖（Component Diagram） 2.7 部署圖（Deployment Diagram） 實務應用情境\n3.1 專案生命週期中的 UML 應用 3.2 不同專案類型的 UML 選擇 3.3 團隊協作中的 UML 專案實作指引\n4.1 UML 建模流程 4.2 我們專案中的 UML 應用範例 4.3 建模最佳實務 工具介紹\n5.1 常用 UML 工具比較 5.2 PlantUML 詳細介紹 5.3 在我們專案中整合 UML 工具 實務範例：學生管理系統\n6.1 專案背景 6.2 Step-by-Step UML 建模 6.3 架構設計 - 元件圖 6.4 部署建模 - 部署圖 6.5 其他領域實務範例 6.6 跨領域建模經驗總結 認證考試準備\n7.1 OMG UML 認證概述 7.2 考試重點知識 7.3 學習路線圖 7.4 考試技巧 附錄\n","title":""},{"content":"資料流程圖 (Data Flow Diagram, DFD) 教學手冊 📋 文件資訊 建立日期: 2025年9月1日 適用對象: 新進專案開發同仁、系統分析初學者 更新版本: v1.1 文件目的: 提供完整的DFD學習指引，從基礎概念到實務應用 🎯 學習路徑建議 初學者路徑 (2-3週) 第1週: 基礎概念建立 - 閱讀第1章：基礎概念 - 閱讀第2章：DFD元素與符號 - 練習：繪製簡單的Context Diagram 第2週: 技能實作 - 閱讀第3章：DFD層次架構 - 閱讀第4章：繪製步驟與方法 - 練習：完成圖書館管理系統案例 第3週: 綜合應用 - 閱讀第6章：練習與案例 - 完成ATM提款系統和訂單管理系統 - 使用第9章檢查清單驗證作品 進階學習者路徑 (1-2週) 第1週: 實務應用 - 快速複習第1-3章基礎概念 - 深入學習第5章：專案實務應用 - 實作中小企業進銷存系統案例 第2週: 專業提升 - 學習第7章：認證準備 - 閱讀第8章：附錄資源 - 準備專業認證考試 團隊領導者路徑 (1週) 重點學習: - 第5.4節：版本控制與變更管理 - 第5.5節：團隊協作與溝通 - 第9章：完整檢查清單 - 建立團隊DFD標準和流程 📚 目錄 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 1.2 DFD的用途與價值 1.3 DFD發展歷史與演進 1.4 在系統分析與程式開發中的角色 2. DFD元素與符號 2.1 外部實體 (External Entity) 2.2 處理程序 (Process) 2.3 資料流 (Data Flow) 2.4 資料儲存 (Data Store) 2.5 符號標準與繪製規範 3. DFD層次架構 3.1 層次概念與原理 3.2 Level 0 - Context Diagram (環境圖) 3.3 Level 1 - 主要功能分解 3.4 Level 2 及更深層次 3.5 分層一致性檢查 3.6 何時停止分解 4. 繪製步驟與方法 4.1 需求蒐集與資料流識別 4.2 系統化繪製流程 4.3 常見錯誤與避免方式 4.4 工具使用與技巧 5. 專案實務應用 5.1 在專案需求分析文件中使用DFD 5.2 讓程式開發與DFD對應 5.3 與ER Model、UML的關聯 5.4 版本控制與變更管理 5.5 團隊協作與溝通 6. 練習與案例 6.1 案例一：ATM提款系統 6.2 案例二：訂單管理系統 6.3 練習題目 6.4 參考解答 7. 認證準備 7.1 國際/業界常見DFD認證介紹 7.2 必考知識點整理 7.3 考試題型與解題策略 7.4 模擬試題 7.5 考試準備策略 8. 附錄 8.1 常用繪圖工具介紹 8.2 進一步學習資源 8.3 業界最佳實務參考 8.4 社群與論壇 9. 檢查清單 9.1 DFD繪製檢查清單 9.2 品質保證檢查清單 9.3 文件品質檢查清單 9.4 團隊協作檢查清單 9.5 快速檢查表 (Quick Checklist) 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 資料流程圖（Data Flow Diagram, DFD） 是一種圖形化建模技術，用來描述資訊系統中資料的流動方向和處理過程。它以視覺化的方式展現系統如何處理資料，從資料的輸入、處理、儲存到輸出的完整流程。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%88%86%E6%9E%90%E8%88%87%E8%A8%AD%E8%A8%88/%E8%B3%87%E6%96%99%E6%B5%81%E7%A8%8B%E5%9C%96dfd%E6%95%99%E5%AD%B8/","summary":"資料流程圖 (Data Flow Diagram, DFD) 教學手冊 📋 文件資訊 建立日期: 2025年9月1日 適用對象: 新進專案開發同仁、系統分析初學者 更新版本: v1.1 文件目的: 提供完整的DFD學習指引，從基礎概念到實務應用 🎯 學習路徑建議 初學者路徑 (2-3週) 第1週: 基礎概念建立 - 閱讀第1章：基礎概念 - 閱讀第2章：DFD元素與符號 - 練習：繪製簡單的Context Diagram 第2週: 技能實作 - 閱讀第3章：DFD層次架構 - 閱讀第4章：繪製步驟與方法 - 練習：完成圖書館管理系統案例 第3週: 綜合應用 - 閱讀第6章：練習與案例 - 完成ATM提款系統和訂單管理系統 - 使用第9章檢查清單驗證作品 進階學習者路徑 (1-2週) 第1週: 實務應用 - 快速複習第1-3章基礎概念 - 深入學習第5章：專案實務應用 - 實作中小企業進銷存系統案例 第2週: 專業提升 - 學習第7章：認證準備 - 閱讀第8章：附錄資源 - 準備專業認證考試 團隊領導者路徑 (1週) 重點學習: - 第5.4節：版本控制與變更管理 - 第5.5節：團隊協作與溝通 - 第9章：完整檢查清單 - 建立團隊DFD標準和流程 📚 目錄 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 1.2 DFD的用途與價值 1.3 DFD發展歷史與演進 1.4 在系統分析與程式開發中的角色 2. DFD元素與符號 2.1 外部實體 (External Entity) 2.2 處理程序 (Process) 2.3 資料流 (Data Flow) 2.4 資料儲存 (Data Store) 2.5 符號標準與繪製規範 3. DFD層次架構 3.1 層次概念與原理 3.2 Level 0 - Context Diagram (環境圖) 3.3 Level 1 - 主要功能分解 3.4 Level 2 及更深層次 3.5 分層一致性檢查 3.6 何時停止分解 4. 繪製步驟與方法 4.1 需求蒐集與資料流識別 4.2 系統化繪製流程 4.3 常見錯誤與避免方式 4.4 工具使用與技巧 5. 專案實務應用 5.1 在專案需求分析文件中使用DFD 5.2 讓程式開發與DFD對應 5.3 與ER Model、UML的關聯 5.4 版本控制與變更管理 5.5 團隊協作與溝通 6. 練習與案例 6.1 案例一：ATM提款系統 6.2 案例二：訂單管理系統 6.3 練習題目 6.4 參考解答 7. 認證準備 7.1 國際/業界常見DFD認證介紹 7.2 必考知識點整理 7.3 考試題型與解題策略 7.4 模擬試題 7.5 考試準備策略 8. 附錄 8.1 常用繪圖工具介紹 8.2 進一步學習資源 8.3 業界最佳實務參考 8.4 社群與論壇 9. 檢查清單 9.1 DFD繪製檢查清單 9.2 品質保證檢查清單 9.3 文件品質檢查清單 9.4 團隊協作檢查清單 9.5 快速檢查表 (Quick Checklist) 1. 基礎概念 1.1 什麼是資料流程圖 (DFD) 資料流程圖（Data Flow Diagram, DFD） 是一種圖形化建模技術，用來描述資訊系統中資料的流動方向和處理過程。它以視覺化的方式展現系統如何處理資料，從資料的輸入、處理、儲存到輸出的完整流程。\n","title":""},{"content":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/github%E4%BD%BF%E7%94%A8hugo%E5%BB%BA%E7%AB%8B%E5%80%8B%E4%BA%BA%E7%B6%B2%E9%A0%81%E6%95%99%E5%AD%B8/","summary":"GitHub使用Hugo建立個人網頁教學 文件版本: 1.0\n最後更新: 2025年10月15日\n適用環境: Windows 10/11\n難度等級: ⭐⭐ (初級-中級)\n📋 教學大綱 前置條件與工具安裝 建立 Hugo 專案 本機預覽網站 選擇與設定 Hugo Theme 部署到 GitHub Pages 維護與更新內容的流程 設定自訂網域（選用） 檢查清單（Checklist） 🎯 學習目標 完成本教學後，您將能夠：\n✅ 在 Windows 環境安裝與設定 Hugo 開發環境 ✅ 建立並預覽 Hugo 靜態網站 ✅ 選擇與客製化 Hugo 主題 ✅ 使用 GitHub Actions 自動部署網站到 GitHub Pages ✅ 維護與更新網站內容 ✅ （選用）設定自訂網域名稱 1. 前置條件與工具安裝 1.1 環境需求 在開始之前，請確認您的環境符合以下需求：\n作業系統: Windows 10 或更新版本 網路連線: 穩定的網際網路連線 磁碟空間: 至少 500MB 可用空間 系統權限: 能夠安裝應用程式的權限 1.2 安裝 Git Git 是版本控制工具，用於管理專案程式碼與部署到 GitHub。\n1.2.1 安裝步驟 下載 Git for Windows\n前往官方網站: https://git-scm.com/download/win 下載最新版本的 Git for Windows 安裝程式 執行安裝程式\n雙擊下載的 .exe 檔案 建議使用預設設定，一路點選「Next」 重要選項： 編輯器選擇：建議選擇 \u0026ldquo;Use Visual Studio Code as Git\u0026rsquo;s default editor\u0026rdquo; PATH 環境變數：選擇 \u0026ldquo;Git from the command line and also from 3rd-party software\u0026rdquo; 換行字元轉換：選擇 \u0026ldquo;Checkout Windows-style, commit Unix-style line endings\u0026rdquo; 驗證安裝\n開啟 PowerShell，執行以下指令：\ngit --version 預期輸出類似：\ngit version 2.43.0.windows.1 設定 Git 使用者資訊\ngit config --global user.name \u0026#34;您的名字\u0026#34; git config --global user.email \u0026#34;your.email@example.com\u0026#34; 1.2.2 流程圖 graph TD A[下載 Git 安裝程式] --\u0026gt; B[執行安裝程式] B --\u0026gt; C[選擇安裝選項] C --\u0026gt; D[完成安裝] D --\u0026gt; E[開啟 PowerShell] E --\u0026gt; F[驗證 git --version] F --\u0026gt; G{版本顯示正確?} G --\u0026gt;|是| H[設定使用者資訊] G --\u0026gt;|否| I[重新安裝] I --\u0026gt; B H --\u0026gt; J[Git 安裝完成] ⚠️ 注意事項 安裝後需要重新開啟 PowerShell 才能使用 git 指令 使用者名稱與 Email 會顯示在您的 Git 提交記錄中 建議使用與 GitHub 帳號相同的 Email 1.3 安裝 Hugo Hugo 是一個快速的靜態網站產生器，使用 Go 語言開發。\n安裝方式（使用 Chocolatey） 方法一：使用 Chocolatey（推薦） 安裝 Chocolatey 套件管理器\n以系統管理員權限開啟 PowerShell，執行：\nSet-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(\u0026#39;https://community.chocolatey.org/install.ps1\u0026#39;)) 安裝 Hugo Extended 版本\nchoco install hugo-extended -y 💡 為什麼選擇 Extended 版本？\nExtended 版本支援 SCSS/SASS 處理，許多現代主題需要此功能。\n驗證安裝\n關閉並重新開啟 PowerShell（一般權限即可），執行：\nhugo version 預期輸出類似：\nhugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio 方法二：手動下載安裝 前往 Hugo GitHub Releases: https://github.com/gohugoio/hugo/releases 下載 hugo_extended_x.xx.x_windows-amd64.zip 解壓縮到 C:\\Hugo\\bin 將 C:\\Hugo\\bin 加入系統 PATH 環境變數 1.3.1 設定流程圖 graph LR A[選擇安裝方式] --\u0026gt; B{Chocolatey 或 手動?} B --\u0026gt;|Chocolatey| C[安裝 Chocolatey] B --\u0026gt;|手動| D[下載 Hugo ZIP] C --\u0026gt; E[choco install hugo-extended] D --\u0026gt; F[解壓縮到 C:\\Hugo\\bin] F --\u0026gt; G[設定 PATH 環境變數] E --\u0026gt; H[驗證: hugo version] G --\u0026gt; H H --\u0026gt; I{安裝成功?} I --\u0026gt;|是| J[完成] I --\u0026gt;|否| K[檢查 PATH 設定] 1.3.2 注意事項 務必安裝 Extended 版本，而非標準版本 手動安裝時，確認 PATH 環境變數設定正確 某些防毒軟體可能會阻擋 Chocolatey 安裝，需暫時停用 1.4 安裝 VS Code Visual Studio Code 是微軟開發的輕量級程式碼編輯器。\n1.4.1 安裝步驟 下載 VS Code\n前往官方網站: https://code.visualstudio.com/ 點選 \u0026ldquo;Download for Windows\u0026rdquo; 執行安裝程式\n雙擊下載的 .exe 檔案 建議勾選的選項： ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管目錄內容功能表 ☑️ 將「透過 Code 開啟」加入 Windows 檔案總管檔案內容功能表 ☑️ 將 Code 註冊為支援的檔案類型編輯器 ☑️ 將 Code 加入 PATH 安裝推薦的擴充套件\n開啟 VS Code 後，安裝以下擴充套件（Extensions）：\nHugo Language and Syntax Support (作者: budparr) Markdown All in One (作者: Yu Zhang) Git Graph (作者: mhutchie) 安裝方式：按 Ctrl+Shift+X 開啟擴充套件面板，搜尋並安裝。\n1.4.2 注意事項 VS Code 會自動偵測系統已安裝的 Git 建議啟用自動儲存功能：File \u0026gt; Auto Save 1.5 申請 GitHub 帳號 如果您還沒有 GitHub 帳號，請依照以下步驟申請。\n申請步驟 前往 GitHub 官網\n網址: https://github.com/ 註冊帳號\n點選右上角的 \u0026ldquo;Sign up\u0026rdquo; 輸入 Email、密碼、使用者名稱 完成驗證（Captcha） 選擇免費方案（Free） 驗證 Email\n登入您的 Email 信箱 點選 GitHub 寄送的驗證連結 完成個人資料設定\n建議上傳大頭照 填寫簡介（Bio） 1.5.1 注意事項 GitHub 使用者名稱將成為您的網站網址的一部分：https://username.github.io 使用者名稱一旦設定後更改較為繁瑣，請謹慎選擇 建議使用與工作相關的專業名稱 1.6 環境檢查總覽 完成所有安裝後，請執行以下指令檢查環境：\n# 檢查 Git git --version # 檢查 Hugo hugo version # 檢查 VS Code（開啟 VS Code） code --version 預期輸出範例：\nPS C:\\Users\\YourName\u0026gt; git --version git version 2.43.0.windows.1 PS C:\\Users\\YourName\u0026gt; hugo version hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio PS C:\\Users\\YourName\u0026gt; code --version 1.85.0 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 x64 系統架構圖 graph TB subgraph \u0026#34;開發環境\u0026#34; A[Windows 10/11] B[Git] C[Hugo Extended] D[VS Code] end subgraph \u0026#34;雲端服務\u0026#34; E[GitHub Account] F[GitHub Repository] G[GitHub Pages] end A --\u0026gt; B A --\u0026gt; C A --\u0026gt; D B --\u0026gt; F C --\u0026gt; H[本地網站] H --\u0026gt; F F --\u0026gt; G E --\u0026gt; F style A fill:#e1f5ff style E fill:#fff4e1 style G fill:#e8f5e9 2. 建立 Hugo 專案 2.1 建立專案資料夾 首先，選擇一個適當的位置建立您的 Hugo 專案。\n操作步驟 開啟 PowerShell\n導航到適當的目錄\n# 例如：在 D 槽建立專案 cd D:\\developer\\repos 使用 Hugo 建立新專案\nhugo new site my-website 其中 my-website 是您的專案名稱，可自行更改。\n進入專案資料夾\ncd my-website 預期輸出結果 Congratulations! Your new Hugo site is created in D:\\developer\\repos\\my-website. Just a few more steps and you\u0026#39;re ready to go: 1. Download a theme into the same-named folder. Choose a theme from https://themes.gohugo.io/ or create your own with the \u0026#34;hugo new theme \u0026lt;THEMENAME\u0026gt;\u0026#34; command. 2. Perhaps you want to add some content. You can add single files with \u0026#34;hugo new \u0026lt;SECTIONNAME\u0026gt;\\\u0026lt;FILENAME\u0026gt;.\u0026lt;FORMAT\u0026gt;\u0026#34;. 3. Start the built-in live server via \u0026#34;hugo server\u0026#34;. Visit https://gohugo.io/ for quickstart guide and full documentation. 2.2 專案結構說明 Hugo 專案建立後，會產生以下目錄結構：\nmy-website/ ├── archetypes/ # 內容範本 │ └── default.md ├── assets/ # 需要處理的資源（SCSS、JS 等） ├── content/ # 網站內容（Markdown 文件） ├── data/ # 資料檔案（JSON、YAML、TOML） ├── layouts/ # 自訂版面配置 ├── static/ # 靜態檔案（圖片、CSS、JS） ├── themes/ # 主題資料夾 └── hugo.toml # 網站設定檔（或 config.toml） 各目錄功能說明 目錄/檔案 用途 是否必要 archetypes/ 定義新內容的預設前置資料（Front Matter） ⭐⭐⭐ content/ 存放網站的所有內容文章（Markdown） ⭐⭐⭐⭐⭐ data/ 存放結構化資料供模板使用 ⭐⭐ layouts/ 自訂 HTML 模板覆寫主題 ⭐⭐⭐ static/ 直接複製到網站根目錄的靜態檔案 ⭐⭐⭐⭐ themes/ 安裝的主題 ⭐⭐⭐⭐⭐ hugo.toml 網站主要設定檔 ⭐⭐⭐⭐⭐ 2.3 初始化 Git 儲存庫 將專案加入版本控制管理。\n# 初始化 Git git init # 建立 .gitignore 檔案 @\u0026#34; # Hugo 產生的檔案 /public/ /resources/_gen/ /.hugo_build.lock # 作業系統檔案 .DS_Store Thumbs.db # 編輯器檔案 .vscode/ .idea/ *.swp *.swo *~ \u0026#34;@ | Out-File -FilePath .gitignore -Encoding utf8 # 加入所有檔案 git add . # 第一次提交 git commit -m \u0026#34;Initial commit: Hugo site created\u0026#34; 2.3.1 流程圖 graph LR A[hugo new site my-website] --\u0026gt; B[建立專案結構] B --\u0026gt; C[cd my-website] C --\u0026gt; D[git init] D --\u0026gt; E[建立 .gitignore] E --\u0026gt; F[git add .] F --\u0026gt; G[git commit] G --\u0026gt; H[專案建立完成] style H fill:#c8e6c9 2.4 設定基本網站資訊 編輯 hugo.toml（或 config.toml）設定檔。\n使用 VS Code 開啟專案 code . 編輯 hugo.toml 找到並編輯 hugo.toml 檔案：\nbaseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的個人網站\u0026#39; theme = \u0026#39;\u0026#39; # 稍後設定 [params] description = \u0026#34;這是我的個人網站，分享技術文章與生活點滴\u0026#34; author = \u0026#34;您的名字\u0026#34; [menu] [[menu.main]] name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 1 [[menu.main]] name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 2 [[menu.main]] name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 3 2.4.1 注意事項 baseURL 需要改成您的 GitHub Pages 網址：https://您的GitHub使用者名稱.github.io/ languageCode 設定為 zh-tw 可支援繁體中文 theme 欄位在安裝主題後填入 2.4.2 實務建議 安全性: 不要在設定檔中儲存敏感資訊（API Keys、密碼等） 效能: 保持設定檔簡潔，避免過多不必要的參數 可維護性: 為每個設定項目加上註解說明用途 3. 本機預覽網站 3.1 啟動 Hugo 開發伺服器 Hugo 內建開發伺服器，支援即時預覽（Live Reload）。\n啟動指令 hugo server -D 參數說明：\nserver: 啟動開發伺服器 -D: 顯示草稿（Draft）狀態的文章 3.1.1 預期輸出 Start building sites … hugo v0.121.1-00b46fed8e47f7bb0a85d7cfc2d9f1356379dca7\u0026#43;extended windows/amd64 BuildDate=2023-12-08T08:47:45Z VendorInfo=gohugoio | ZH-TW -------------------\u0026#43;-------- Pages | 3 Paginator pages | 0 Non-page files | 0 Static files | 0 Processed images | 0 Aliases | 0 Sitemaps | 1 Cleaned | 0 Built in 45 ms Environment: \u0026#34;development\u0026#34; Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl\u0026#43;C to stop 3.2 在瀏覽器中預覽 開啟瀏覽器 前往 http://localhost:1313/ 您應該會看到一個空白或基本的網站（尚未安裝主題） 常用的開發伺服器參數 # 顯示草稿文章 hugo server -D # 指定埠號 hugo server --port 8080 # 允許外部存取（區域網路） hugo server --bind 0.0.0.0 --baseURL http://你的IP:1313 # 停用 Fast Render（完整重建） hugo server --disableFastRender # 開啟詳細日誌 hugo server --verbose 3.3 建立第一篇文章 使用指令建立文章 hugo new posts/my-first-post.md 這會在 content/posts/ 目錄下建立 my-first-post.md 檔案。\n編輯文章內容 使用 VS Code 開啟 content/posts/my-first-post.md：\n--- title: \u0026#34;我的第一篇文章\u0026#34; date: 2025-10-15T10:00:00\u0026#43;08:00 draft: false tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;部落格\u0026#34;] categories: [\u0026#34;教學\u0026#34;] --- ## 歡迎來到我的部落格！ 這是我使用 Hugo 建立的第一篇文章。 ### Hugo 的優點 - 🚀 建置速度極快 - 📝 使用 Markdown 撰寫 - 🎨 豐富的主題選擇 - 🔧 高度可客製化 ### 程式碼範例 ```python def hello_hugo(): print(\u0026#34;Hello, Hugo!\u0026#34;) hello_hugo() 祝大家使用愉快！\nFront Matter 說明 Front Matter 是文章開頭的 YAML/TOML 區塊，定義文章的詮釋資料：\n欄位 說明 範例 title 文章標題 \u0026ldquo;我的第一篇文章\u0026rdquo; date 發布日期 2025-10-15T10:00:00+08:00 draft 是否為草稿 true / false tags 標籤 [\u0026ldquo;Hugo\u0026rdquo;, \u0026ldquo;部落格\u0026rdquo;] categories 分類 [\u0026ldquo;教學\u0026rdquo;] author 作者 \u0026ldquo;Your Name\u0026rdquo; description 摘要 \u0026ldquo;本文介紹\u0026hellip;\u0026rdquo; 3.4 即時預覽更新 儲存文章後，Hugo 會自動重建網站，瀏覽器會自動重新整理顯示最新內容。\n開發流程圖 sequenceDiagram participant Dev as 開發者 participant VSCode as VS Code participant Hugo as Hugo Server participant Browser as 瀏覽器 Dev-\u0026gt;\u0026gt;VSCode: 編輯 .md 檔案 VSCode-\u0026gt;\u0026gt;VSCode: 自動儲存 VSCode-\u0026gt;\u0026gt;Hugo: 檔案變更通知 Hugo-\u0026gt;\u0026gt;Hugo: 重新建置網站 Hugo-\u0026gt;\u0026gt;Browser: WebSocket 推送更新 Browser-\u0026gt;\u0026gt;Browser: 自動重新整理 Browser--\u0026gt;\u0026gt;Dev: 顯示最新內容 3.5 停止開發伺服器 在 PowerShell 中按下 Ctrl + C 即可停止伺服器。\n3.5.1 注意事項 開發伺服器僅供本地開發使用，不適合正式部署 預設僅監聽 localhost，外部無法存取 修改 hugo.toml 後需要重新啟動伺服器 3.5.2 實務建議 開發習慣: 保持開發伺服器運行,善用即時預覽功能 效能: 大型網站可使用 --disableFastRender 確保完整重建 安全性: 不要在開發伺服器上使用正式環境的 API Key 4. 選擇與設定 Hugo Theme 4.1 選擇適合的主題 Hugo 擁有豐富的主題生態系統，您可以從官方主題庫選擇。\n主題推薦 主題名稱 特色 適用情境 難度 PaperMod 極簡、快速、SEO 友善 個人部落格 ⭐⭐ Hugo-Theme-Stack 現代化、多功能 技術部落格 ⭐⭐⭐ Ananke 官方推薦、簡潔 初學者 ⭐ LoveIt 功能豐富、中文支援佳 個人網站 ⭐⭐⭐ Academic/Wowchemy 學術型網站 研究人員、教師 ⭐⭐⭐⭐ 瀏覽主題 前往 Hugo 官方主題庫：https://themes.gohugo.io/\n選擇考量因素 mindmap root((Hugo 主題選擇)) 設計風格 極簡主義 多彩豐富 專業商務 個人創意 功能需求 部落格 作品集 文件網站 電商展示 技術要求 是否需要 Extended 版本 相依套件複雜度 客製化難易度 維護狀態 最後更新時間 Star 數量 Issue 處理速度 文件完整性 4.2 安裝主題（以 PaperMod 為例） 方法一：使用 Git Submodule（推薦） 使用 Git Submodule 可以方便地更新主題。\n# 確認在專案根目錄 cd D:\\developer\\repos\\my-website # 加入主題作為 Submodule git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod # 更新 Submodule git submodule update --init --recursive 方法二：直接下載主題 # 下載並解壓縮到 themes 資料夾 # 手動從 GitHub 下載 ZIP 並解壓縮到 themes/PaperMod/ 方法三：使用 Hugo Modules（進階） # 初始化 Hugo Module hugo mod init github.com/yourusername/my-website # 在 hugo.toml 中加入 # [module] # [[module.imports]] # path = \u0026#34;github.com/adityatelange/hugo-PaperMod\u0026#34; 安裝流程圖 graph TD A[選擇安裝方式] --\u0026gt; B{Git Submodule?} B --\u0026gt;|是| C[git submodule add] B --\u0026gt;|否| D{Hugo Modules?} D --\u0026gt;|是| E[hugo mod init \u0026#43; 設定] D --\u0026gt;|否| F[手動下載 ZIP] C --\u0026gt; G[更新 hugo.toml] E --\u0026gt; G F --\u0026gt; G G --\u0026gt; H[設定 theme = \u0026#39;PaperMod\u0026#39;] H --\u0026gt; I[重啟 hugo server] I --\u0026gt; J[檢查網站外觀] style J fill:#c8e6c9 4.3 設定主題 4.3.1 編輯 hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; languageCode = \u0026#39;zh-tw\u0026#39; title = \u0026#39;我的技術部落格\u0026#39; theme = \u0026#39;PaperMod\u0026#39; # 啟用 emoji 支援 enableEmoji = true # 設定摘要長度 summaryLength = 70 # 設定分頁 paginate = 10 [params] # 網站描述 description = \u0026#34;分享程式開發、技術學習與生活心得\u0026#34; # 作者資訊 author = \u0026#34;Your Name\u0026#34; # 顯示閱讀時間 ShowReadingTime = true # 顯示分享按鈕 ShowShareButtons = true # 顯示文章目錄 ShowToc = true TocOpen = false # 顯示程式碼複製按鈕 ShowCodeCopyButtons = true # 首頁資訊 [params.homeInfoParams] Title = \u0026#34;歡迎來到我的部落格 👋\u0026#34; Content = \u0026#34;\u0026#34;\u0026#34; 這裡分享我的技術學習筆記、專案經驗與生活點滴。 - 🔧 主要技術: Java, Python, Go - 📚 專注領域: 後端開發、DevOps - 💡 持續學習中... \u0026#34;\u0026#34;\u0026#34; # 社群媒體連結 [[params.socialIcons]] name = \u0026#34;github\u0026#34; url = \u0026#34;https://github.com/yourusername\u0026#34; [[params.socialIcons]] name = \u0026#34;linkedin\u0026#34; url = \u0026#34;https://linkedin.com/in/yourprofile\u0026#34; [[params.socialIcons]] name = \u0026#34;email\u0026#34; url = \u0026#34;mailto:your.email@example.com\u0026#34; # 選單設定 [menu] [[menu.main]] identifier = \u0026#34;home\u0026#34; name = \u0026#34;首頁\u0026#34; url = \u0026#34;/\u0026#34; weight = 10 [[menu.main]] identifier = \u0026#34;posts\u0026#34; name = \u0026#34;文章\u0026#34; url = \u0026#34;/posts/\u0026#34; weight = 20 [[menu.main]] identifier = \u0026#34;archives\u0026#34; name = \u0026#34;歸檔\u0026#34; url = \u0026#34;/archives/\u0026#34; weight = 30 [[menu.main]] identifier = \u0026#34;tags\u0026#34; name = \u0026#34;標籤\u0026#34; url = \u0026#34;/tags/\u0026#34; weight = 40 [[menu.main]] identifier = \u0026#34;about\u0026#34; name = \u0026#34;關於\u0026#34; url = \u0026#34;/about/\u0026#34; weight = 50 # 語法高亮設定 [markup] [markup.highlight] style = \u0026#34;monokai\u0026#34; lineNos = true lineNumbersInTable = true noClasses = false 4.4 建立必要頁面 建立關於頁面 hugo new about.md 編輯 content/about.md：\n--- title: \u0026#34;關於我\u0026#34; date: 2025-10-15 draft: false ShowToc: false --- ## 👨‍💻 自我介紹 哈囉！我是 [Your Name]，是一位熱愛技術的軟體工程師。 ### 技能 - **程式語言**: Java, Python, JavaScript - **框架**: Spring Boot, Django, React - **工具**: Git, Docker, Jenkins ### 興趣 - 📖 閱讀技術書籍 - 🏃‍♂️ 慢跑 - 📷 攝影 ### 聯絡方式 - Email: your.email@example.com - GitHub: [@yourusername](https://github.com/yourusername) 建立歸檔頁面 hugo new archives.md 編輯 content/archives.md：\n--- title: \u0026#34;文章歸檔\u0026#34; layout: \u0026#34;archives\u0026#34; url: \u0026#34;/archives/\u0026#34; summary: archives --- 4.5 客製化主題樣式（選用） 覆寫 CSS 建立 assets/css/extended/custom.css：\n/* 自訂顏色 */ :root { --primary: #1e88e5; --secondary: #424242; } /* 自訂標題樣式 */ .post-title { font-size: 2rem; font-weight: 700; } /* 自訂程式碼區塊 */ .highlight { border-radius: 8px; padding: 1rem; } /* 響應式調整 */ @media (max-width: 768px) { .post-title { font-size: 1.5rem; } } 覆寫部分模板 如需客製化 HTML 結構，可在 layouts/ 資料夾中覆寫主題檔案：\nlayouts/ ├── _default/ │ └── single.html # 覆寫單篇文章版面 ├── partials/ │ └── footer.html # 覆寫頁尾 └── shortcodes/ └── youtube.html # 自訂 shortcode 4.6 驗證主題設定 重啟開發伺服器 # 停止目前的 server (Ctrl\u0026#43;C) # 重新啟動 hugo server -D 檢查項目 ✅ 網站外觀符合主題風格 ✅ 選單項目正確顯示 ✅ 社群媒體圖示正常 ✅ 文章列表正確顯示 ✅ 語法高亮運作正常 ✅ 響應式設計在手機上正常 主題設定流程總覽 graph TB A[瀏覽主題庫] --\u0026gt; B[選擇適合主題] B --\u0026gt; C[使用 Git Submodule 安裝] C --\u0026gt; D[編輯 hugo.toml 設定] D --\u0026gt; E[建立必要頁面] E --\u0026gt; F{需要客製化?} F --\u0026gt;|是| G[建立自訂 CSS/Template] F --\u0026gt;|否| H[完成主題設定] G --\u0026gt; H H --\u0026gt; I[重啟 hugo server 驗證] style H fill:#c8e6c9 4.6.1 注意事項 不同主題的設定參數可能不同，請參考主題的官方文件 使用 Git Submodule 時，更新主題需使用 git submodule update --remote 客製化前建議先備份原始主題檔案 過度客製化可能導致主題更新困難 4.6.2 實務建議 選擇策略: 優先選擇維護活躍、文件完整的主題 效能考量: 避免選擇過於臃腫、載入緩慢的主題 SEO 優化: 確認主題支援 Open Graph、Twitter Cards 等 meta 標籤 可維護性: 使用覆寫（override）方式客製化，而非直接修改主題檔案 5. 部署到 GitHub Pages 5.1 建立 GitHub Repository 步驟說明 登入 GitHub\n前往 https://github.com 並登入 建立新的 Repository\n點選右上角的 + 號 選擇 \u0026ldquo;New repository\u0026rdquo; Repository 設定\nRepository name: yourusername.github.io ⚠️ 必須使用 使用者名稱.github.io 格式 Description: \u0026ldquo;My personal website built with Hugo\u0026rdquo; Public: 選擇 Public（免費用戶只能使用 Public repo 的 GitHub Pages） 不要勾選: Initialize this repository with a README 建立 Repository\n點選 \u0026ldquo;Create repository\u0026rdquo; Repository 命名規則 graph LR A[GitHub 使用者名稱] --\u0026gt; B[yourusername] B --\u0026gt; C[Repository 名稱] C --\u0026gt; D[yourusername.github.io] D --\u0026gt; E[網站網址] E --\u0026gt; F[https://yourusername.github.io] style F fill:#e1f5ff 5.2 連結本地專案與遠端 Repository 在專案目錄中執行以下指令：\n# 設定遠端 Repository git remote add origin https://github.com/yourusername/yourusername.github.io.git # 檢查遠端設定 git remote -v # 建立主分支（如果尚未建立） git branch -M main # 第一次推送 git push -u origin main 5.2.1 預期輸出 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (15/15), 2.50 KiB | 2.50 MiB/s, done. Total 15 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yourusername/yourusername.github.io.git * [new branch] main -\u0026gt; main Branch \u0026#39;main\u0026#39; set up to track remote branch \u0026#39;main\u0026#39; from \u0026#39;origin\u0026#39;. 5.3 設定 GitHub Actions 自動部署 GitHub Actions 可以自動建置並部署 Hugo 網站。\n建立 Workflow 檔案 建立 .github/workflows/hugo.yml 檔案：\n# 建立目錄 New-Item -ItemType Directory -Force -Path .github\\workflows # 建立 workflow 檔案 New-Item -ItemType File -Path .github\\workflows\\hugo.yml 編輯 hugo.yml 使用 VS Code 開啟 .github/workflows/hugo.yml 並貼上以下內容：\nname: Deploy Hugo site to Pages on: # 當推送到 main 分支時觸發 push: branches: - main # 允許手動觸發 workflow_dispatch: # 設定 GitHub Pages 的權限 permissions: contents: read pages: write id-token: write # 避免同時執行多個部署 concurrency: group: \u0026#34;pages\u0026#34; cancel-in-progress: false # 預設使用 bash defaults: run: shell: bash jobs: # 建置工作 build: runs-on: ubuntu-latest env: HUGO_VERSION: 0.121.1 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \\ \u0026amp;\u0026amp; sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass run: sudo snap install dart-sass - name: Checkout uses: actions/checkout@v4 with: submodules: recursive fetch-depth: 0 - name: Setup Pages id: pages uses: actions/configure-pages@v4 - name: Install Node.js dependencies run: \u0026#34;[[ -f package-lock.json || -f npm-shrinkwrap.json ]] \u0026amp;\u0026amp; npm ci || true\u0026#34; - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; - name: Upload artifact uses: actions/upload-pages-artifact@v2 with: path: ./public # 部署工作 deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v3 Workflow 檔案說明 區段 說明 on.push.branches 觸發條件：推送到 main 分支 permissions 授予 workflow 必要的權限 jobs.build 建置工作：安裝 Hugo、建置網站 jobs.deploy 部署工作：將產生的檔案部署到 GitHub Pages HUGO_VERSION 指定 Hugo 版本（建議與本地相同） 5.4 設定 GitHub Pages 在 GitHub 網站上設定 前往您的 Repository 頁面 點選 Settings 在左側選單選擇 Pages 在 \u0026ldquo;Build and deployment\u0026rdquo; 區段： Source: 選擇 \u0026ldquo;GitHub Actions\u0026rdquo; 儲存設定 5.4.1 設定流程圖 graph TD A[進入 Repository Settings] --\u0026gt; B[選擇 Pages] B --\u0026gt; C[Source 選擇 GitHub Actions] C --\u0026gt; D[儲存設定] D --\u0026gt; E[等待 Workflow 執行] E --\u0026gt; F{部署成功?} F --\u0026gt;|是| G[訪問 username.github.io] F --\u0026gt;|否| H[檢查 Actions 錯誤訊息] H --\u0026gt; I[修正問題] I --\u0026gt; J[重新推送] J --\u0026gt; E style G fill:#c8e6c9 5.5 推送並觸發部署 # 加入 GitHub Actions workflow git add .github/workflows/hugo.yml # 提交變更 git commit -m \u0026#34;Add GitHub Actions workflow for Hugo deployment\u0026#34; # 推送到 GitHub git push origin main 5.6 監控部署狀態 查看 Actions 執行狀態 前往 Repository 頁面 點選 Actions 標籤 查看最新的 workflow 執行狀態 部署成功標誌 ✅ build 工作完成 ✅ deploy 工作完成 ✅ 顯示綠色勾勾 訪問您的網站 部署成功後，前往 https://yourusername.github.io/ 查看您的網站！\n5.7 部署流程完整視圖 sequenceDiagram participant Dev as 開發者 participant Local as 本地 Git participant GitHub as GitHub Repo participant Actions as GitHub Actions participant Pages as GitHub Pages participant User as 訪客 Dev-\u0026gt;\u0026gt;Local: git commit \u0026amp; push Local-\u0026gt;\u0026gt;GitHub: 推送程式碼 GitHub-\u0026gt;\u0026gt;Actions: 觸發 Workflow Actions-\u0026gt;\u0026gt;Actions: 安裝 Hugo Actions-\u0026gt;\u0026gt;Actions: 建置網站 (hugo build) Actions-\u0026gt;\u0026gt;Actions: 產生 public/ 目錄 Actions-\u0026gt;\u0026gt;Pages: 部署靜態檔案 Pages-\u0026gt;\u0026gt;Pages: 網站上線 User-\u0026gt;\u0026gt;Pages: 訪問網站 Pages-\u0026gt;\u0026gt;User: 回傳網頁內容 5.8 常見部署問題與解決方案 問題 1: Workflow 執行失敗 原因: Hugo 版本不匹配或主題問題\n解決方案:\n# 檢查本地 Hugo 版本 hugo version # 在 hugo.yml 中設定相同版本 env: HUGO_VERSION: 0.121.1 # 與本地版本一致 問題 2: 主題無法載入 原因: Git Submodule 未正確同步\n解決方案:\n# 在 Checkout 步驟中確保包含 - name: Checkout uses: actions/checkout@v4 with: submodules: recursive # 重要！ fetch-depth: 0 問題 3: baseURL 設定錯誤 原因: hugo.toml 中的 baseURL 不正確\n解決方案:\n# hugo.toml baseURL = \u0026#39;https://yourusername.github.io/\u0026#39; # 結尾要有斜線 問題 4: CSS/JS 無法載入 原因: 相對路徑問題\n解決方案:\n# 在 Build with Hugo 步驟中使用正確的 baseURL run: | hugo \\ --gc \\ --minify \\ --baseURL \u0026#34;${{ steps.pages.outputs.base_url }}/\u0026#34; 5.9 效能優化建議 啟用快取 在 workflow 中加入快取步驟：\n- name: Cache Hugo resources uses: actions/cache@v3 with: path: resources key: ${{ runner.os }}-hugo-resources-${{ hashFiles(\u0026#39;content/**\u0026#39;) }} 圖片優化 # 使用 Hugo 的圖片處理功能 # 在文章中使用 Hugo 的 image processing 在 Markdown 中：\n啟用 CDN（選用） 考慮使用 Cloudflare Pages 或其他 CDN 服務提升全球存取速度。\n5.7.1 注意事項 GitHub Pages 有 1GB 儲存空間限制 每月頻寬限制 100GB 部署次數建議不要過於頻繁（每小時不超過 10 次） 私有 Repository 需要 GitHub Pro 方案才能使用 Pages 5.7.2 實務建議 安全性: 不要在 Repository 中儲存敏感資訊（API Keys、密碼） 效能: 使用圖片壓縮工具減少檔案大小 SEO: 確保 sitemap.xml 和 robots.txt 正確設定 可維護性: 定期更新 Hugo 版本和主題 6. 維護與更新內容的流程 6.1 日常更新工作流程 建立文章並部署的標準流程如下：\n標準工作流程 graph TD A[開啟 VS Code] --\u0026gt; B[啟動 hugo server -D] B --\u0026gt; C[建立新文章] C --\u0026gt; D[撰寫內容] D --\u0026gt; E[本機預覽] E --\u0026gt; F{內容滿意?} F --\u0026gt;|否| D F --\u0026gt;|是| G[設定 draft: false] G --\u0026gt; H[git add .] H --\u0026gt; I[git commit -m 訊息] I --\u0026gt; J[git push origin main] J --\u0026gt; K[GitHub Actions 自動部署] K --\u0026gt; L[網站更新完成] style L fill:#c8e6c9 詳細步驟 步驟 1: 建立新文章 # 建立新文章 hugo new posts/2025/my-new-post.md # 或使用日期目錄結構 hugo new posts/2025-10-15-my-new-post.md 步驟 2: 編輯文章內容 --- title: \u0026#34;深入理解 Java Stream API\u0026#34; date: 2025-10-15T14:30:00\u0026#43;08:00 draft: false tags: [\u0026#34;Java\u0026#34;, \u0026#34;Stream API\u0026#34;, \u0026#34;函數式編程\u0026#34;] categories: [\u0026#34;程式設計\u0026#34;] author: \u0026#34;Your Name\u0026#34; description: \u0026#34;本文詳細介紹 Java 8 引入的 Stream API，包含常用操作與最佳實踐\u0026#34; cover: image: \u0026#34;images/java-stream.png\u0026#34; alt: \u0026#34;Java Stream API\u0026#34; caption: \u0026#34;Stream API 讓集合操作更優雅\u0026#34; --- ## 前言 Java 8 引入的 Stream API 徹底改變了集合處理的方式... ## 基本概念 Stream 是一個資料序列，支援各種操作來處理資料... ### 建立 Stream \\`\\`\\`java // 從集合建立 List\u0026lt;String\u0026gt; list = Arrays.asList(\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;); Stream\u0026lt;String\u0026gt; stream = list.stream(); // 從陣列建立 String[] array = {\u0026#34;a\u0026#34;, \u0026#34;b\u0026#34;, \u0026#34;c\u0026#34;}; Stream\u0026lt;String\u0026gt; stream2 = Arrays.stream(array); \\`\\`\\` ## 常用操作 ### Filter（過濾） \\`\\`\\`java list.stream() .filter(s -\u0026gt; s.startsWith(\u0026#34;a\u0026#34;)) .collect(Collectors.toList()); \\`\\`\\` ## 總結 Stream API 提供了簡潔且高效的集合處理方式... 步驟 3: 本機預覽 # 如果 server 未啟動，執行 hugo server -D # 在瀏覽器開啟 http://localhost:1313/ 步驟 4: 提交並部署 # 檢查變更 git status # 加入所有變更 git add . # 提交（使用有意義的訊息） git commit -m \u0026#34;新增文章: 深入理解 Java Stream API\u0026#34; # 推送到 GitHub git push origin main 步驟 5: 等待部署完成 前往 GitHub Repository 的 Actions 頁面 確認 workflow 執行成功 訪問網站確認更新 6.2 Git 提交訊息最佳實踐 提交訊息格式 \u0026lt;類型\u0026gt;: \u0026lt;簡短描述\u0026gt; \u0026lt;詳細描述（選用）\u0026gt; \u0026lt;相關 Issue（選用）\u0026gt; 常用類型 類型 說明 範例 feat 新功能 feat: 新增留言功能 post 新文章 post: 新增 Java Stream API 教學 fix 修正錯誤 fix: 修正文章日期顯示問題 style 樣式調整 style: 更新首頁配色 docs 文件更新 docs: 更新 README refactor 重構 refactor: 重新組織文章分類 config 設定變更 config: 更新 hugo.toml 設定 範例 # 好的提交訊息 git commit -m \u0026#34;post: 新增 Docker 容器化部署教學\u0026#34; git commit -m \u0026#34;fix: 修正文章中程式碼區塊的語法高亮\u0026#34; git commit -m \u0026#34;style: 調整文章標題字體大小\u0026#34; # 不好的提交訊息（避免） git commit -m \u0026#34;update\u0026#34; git commit -m \u0026#34;fix bug\u0026#34; git commit -m \u0026#34;change\u0026#34; 6.3 管理草稿文章 草稿工作流程 stateDiagram-v2 [*] --\u0026gt; 草稿: hugo new post.md 草稿 --\u0026gt; 預覽: hugo server -D 預覽 --\u0026gt; 草稿: 繼續編輯 預覽 --\u0026gt; 發布: draft: false 發布 --\u0026gt; 線上: git push 線上 --\u0026gt; [*] 草稿文章不會被部署 --- title: \u0026#34;我的草稿文章\u0026#34; date: 2025-10-15 draft: true # 設為 true，不會出現在正式網站 --- 本機預覽草稿 # 包含草稿的預覽 hugo server -D # 不包含草稿的預覽（模擬正式環境） hugo server 將草稿變為正式文章 只需將 draft: true 改為 draft: false：\n","title":""},{"content":"GitHub 使用教學手冊 📋 文件資訊 版本: 2.0 更新日期: 2025年8月29日 適用對象: 新進開發同仁、團隊協作開發者 維護者: 專案開發團隊 📚 目錄 Git/GitHub 基礎概念\n1.1 什麼是 Git？ 1.2 什麼是 GitHub？ 1.3 為何要使用？ 1.4 版本控制的重要性 1.5 團隊開發的挑戰 1.6 Git 的解決方案 1.7 GitHub 的附加價值 環境設定\n2.1 安裝 Git 2.2 設定個人資訊 2.3 GitHub 帳號設定 2.4 Personal Access Token 設定（替代方案） 2.5 Git 效能優化設定 基本操作流程\n3.1 Clone 專案 3.2 建立 Feature Branch 3.3 Commit Message 撰寫規範 3.4 Push 到 Remote 3.5 建立 Pull Request (PR) 3.6 Code Review 流程 3.7 Merge 規範 Git 進階操作\n4.1 Interactive Rebase 4.2 Cherry-pick 操作 4.3 Git Bisect 除錯 4.4 Stash 暫存操作 4.5 Submodule 子模組管理 4.6 Git Hooks 自動化 4.7 大型檔案處理 (LFS) 日常工作流程建議\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/github%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"GitHub 使用教學手冊 📋 文件資訊 版本: 2.0 更新日期: 2025年8月29日 適用對象: 新進開發同仁、團隊協作開發者 維護者: 專案開發團隊 📚 目錄 Git/GitHub 基礎概念\n1.1 什麼是 Git？ 1.2 什麼是 GitHub？ 1.3 為何要使用？ 1.4 版本控制的重要性 1.5 團隊開發的挑戰 1.6 Git 的解決方案 1.7 GitHub 的附加價值 環境設定\n2.1 安裝 Git 2.2 設定個人資訊 2.3 GitHub 帳號設定 2.4 Personal Access Token 設定（替代方案） 2.5 Git 效能優化設定 基本操作流程\n3.1 Clone 專案 3.2 建立 Feature Branch 3.3 Commit Message 撰寫規範 3.4 Push 到 Remote 3.5 建立 Pull Request (PR) 3.6 Code Review 流程 3.7 Merge 規範 Git 進階操作\n4.1 Interactive Rebase 4.2 Cherry-pick 操作 4.3 Git Bisect 除錯 4.4 Stash 暫存操作 4.5 Submodule 子模組管理 4.6 Git Hooks 自動化 4.7 大型檔案處理 (LFS) 日常工作流程建議\n","title":""},{"content":"GitLab 使用教學手冊 📋 目錄 GitLab 基本介紹\n1.1 Git vs. GitLab - 基本概念 1.2 為什麼選擇 GitLab？ 1.3 專案架構概覽 1.4 GitLab 核心功能詳解 專案工作流程說明\n2.1 環境準備 2.2 Clone - 複製專案到本地 2.3 Pull - 同步遠端更新 2.4 Commit - 提交變更 2.5 Push - 推送變更到遠端 2.6 Merge Request - 合併請求 專案開發規範\n3.1 分支策略 3.2 Commit Message 規範 3.3 Merge Request 流程 3.4 Code Review 要求 GitLab CI/CD 基本介紹\n4.1 CI/CD 概念說明 4.2 GitLab CI/CD 架構 4.3 .gitlab-ci.yml 設定檔 4.4 Java 專案 CI/CD 設定 4.5 常用 CI/CD 指令 4.6 本專案的 CI/CD 應用 常見問題與解決方式\n5.1 Merge 衝突處理 5.2 錯誤回復方式 5.3 分支管理問題 5.4 權限和認證問題 5.5 效能和同步問題 5.6 CI/CD Pipeline 問題 5.7 團隊協作問題 開發最佳實務建議\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/gitlab%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"GitLab 使用教學手冊 📋 目錄 GitLab 基本介紹\n1.1 Git vs. GitLab - 基本概念 1.2 為什麼選擇 GitLab？ 1.3 專案架構概覽 1.4 GitLab 核心功能詳解 專案工作流程說明\n2.1 環境準備 2.2 Clone - 複製專案到本地 2.3 Pull - 同步遠端更新 2.4 Commit - 提交變更 2.5 Push - 推送變更到遠端 2.6 Merge Request - 合併請求 專案開發規範\n3.1 分支策略 3.2 Commit Message 規範 3.3 Merge Request 流程 3.4 Code Review 要求 GitLab CI/CD 基本介紹\n4.1 CI/CD 概念說明 4.2 GitLab CI/CD 架構 4.3 .gitlab-ci.yml 設定檔 4.4 Java 專案 CI/CD 設定 4.5 常用 CI/CD 指令 4.6 本專案的 CI/CD 應用 常見問題與解決方式\n5.1 Merge 衝突處理 5.2 錯誤回復方式 5.3 分支管理問題 5.4 權限和認證問題 5.5 效能和同步問題 5.6 CI/CD Pipeline 問題 5.7 團隊協作問題 開發最佳實務建議\n","title":""},{"content":"GitLab 使用教學手冊 - 檢查報告 檢查日期：2025年10月17日\n檢查者：GitHub Copilot\n文件版本：2.0\n文件路徑：.github/教學/工具/GitLab使用教學.md\n📊 檢查摘要 ✅ 整體評估：優良 文件內容完整且結構清晰，已完成以下檢查和修正：\n✅ 目錄結構完整且一致 ✅ 所有章節內容都已生成 ✅ Markdown 格式問題已修正 ✅ 內容豐富且實用 📋 逐章檢查結果 第 1 章：GitLab 基本介紹 ✅ 狀態：完整\n子章節檢查：\n✅ 1.1 Git vs. GitLab - 基本概念 ✅ 1.2 為什麼選擇 GitLab？ ✅ 1.3 專案架構概覽 ✅ 1.4 GitLab 核心功能詳解 內容品質：\n概念說明清晰 包含豐富的核心功能介紹 涵蓋 Issue、Labels、Milestone、Project、Group 等重要功能 有實用的範例和最佳實務建議 第 2 章：專案工作流程說明 ✅ 狀態：完整\n子章節檢查：\n✅ 2.1 環境準備 ✅ 2.2 Clone - 複製專案到本地 ✅ 2.3 Pull - 同步遠端更新 ✅ 2.4 Commit - 提交變更 ✅ 2.5 Push - 推送變更到遠端 ✅ 2.6 Merge Request - 合併請求 內容品質：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/gitlab%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8_%E6%AA%A2%E6%9F%A5%E5%A0%B1%E5%91%8A/","summary":"GitLab 使用教學手冊 - 檢查報告 檢查日期：2025年10月17日\n檢查者：GitHub Copilot\n文件版本：2.0\n文件路徑：.github/教學/工具/GitLab使用教學.md\n📊 檢查摘要 ✅ 整體評估：優良 文件內容完整且結構清晰，已完成以下檢查和修正：\n✅ 目錄結構完整且一致 ✅ 所有章節內容都已生成 ✅ Markdown 格式問題已修正 ✅ 內容豐富且實用 📋 逐章檢查結果 第 1 章：GitLab 基本介紹 ✅ 狀態：完整\n子章節檢查：\n✅ 1.1 Git vs. GitLab - 基本概念 ✅ 1.2 為什麼選擇 GitLab？ ✅ 1.3 專案架構概覽 ✅ 1.4 GitLab 核心功能詳解 內容品質：\n概念說明清晰 包含豐富的核心功能介紹 涵蓋 Issue、Labels、Milestone、Project、Group 等重要功能 有實用的範例和最佳實務建議 第 2 章：專案工作流程說明 ✅ 狀態：完整\n子章節檢查：\n✅ 2.1 環境準備 ✅ 2.2 Clone - 複製專案到本地 ✅ 2.3 Pull - 同步遠端更新 ✅ 2.4 Commit - 提交變更 ✅ 2.5 Push - 推送變更到遠端 ✅ 2.6 Merge Request - 合併請求 內容品質：\n","title":""},{"content":"專案 Git 教學手冊 目錄 Git 基本觀念\n1.1 什麼是版本控制？ 1.2 為什麼使用 Git？ 1.3 Git 基本概念 實務提醒 第1章實作練習 環境設定\n2.1 Git 安裝 2.2 基本設定 2.3 個人與公司帳號區隔 2.4 SSH 金鑰設定 2.5 HTTPS vs SSH 選擇 2.6 Java 開發環境整合配置 實務建議 第2章實作練習 專案流程\n3.1 如何 Clone 專案 3.2 分支策略與命名規範 3.3 Commit Message 規範 3.4 Pull / Fetch / Merge / Rebase 使用時機 3.5 Push 前檢查事項 3.6 衝突處理 團隊協作\n4.1 Pull Request (PR) / Merge Request (MR) 流程 4.2 Code Review 規範 4.3 分支保護規則 4.4 工作流程最佳實務 常見錯誤排解\n5.1 誤 Push 的處理 5.2 Commit 錯誤訊息修正 5.3 Reset vs Revert 使用時機 5.4 分支相關問題 5.5 合併問題解決 5.6 遠端倉庫問題 最佳實務\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/git%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"專案 Git 教學手冊 目錄 Git 基本觀念\n1.1 什麼是版本控制？ 1.2 為什麼使用 Git？ 1.3 Git 基本概念 實務提醒 第1章實作練習 環境設定\n2.1 Git 安裝 2.2 基本設定 2.3 個人與公司帳號區隔 2.4 SSH 金鑰設定 2.5 HTTPS vs SSH 選擇 2.6 Java 開發環境整合配置 實務建議 第2章實作練習 專案流程\n3.1 如何 Clone 專案 3.2 分支策略與命名規範 3.3 Commit Message 規範 3.4 Pull / Fetch / Merge / Rebase 使用時機 3.5 Push 前檢查事項 3.6 衝突處理 團隊協作\n4.1 Pull Request (PR) / Merge Request (MR) 流程 4.2 Code Review 規範 4.3 分支保護規則 4.4 工作流程最佳實務 常見錯誤排解\n5.1 誤 Push 的處理 5.2 Commit 錯誤訊息修正 5.3 Reset vs Revert 使用時機 5.4 分支相關問題 5.5 合併問題解決 5.6 遠端倉庫問題 最佳實務\n","title":""},{"content":"IntelliJ IDEA Community Edition 使用教學手冊 文件資訊 版本: 1.0 建立日期: 2025年8月29日 適用對象: Java 後端開發新進人員 IDE 版本: IntelliJ IDEA Community Edition 2023.3+ 目錄 IntelliJ IDEA CE 下載與安裝\n1.1 下載 IntelliJ IDEA Community Edition 1.2 安裝步驟 1.3 首次啟動設定 1.4 授權與隱私設定 開發環境基本設定\n2.1 JDK 設定 2.2 Maven 整合設定 2.3 編碼設定 2.4 Code Style 設定 2.5 檢查器設定 匯入專案與建立新專案\n3.1 匯入現有專案 3.2 建立新專案 3.3 專案設定優化 與 Git/GitHub/GitLab 的整合\n4.1 Git 基本設定 4.2 本地版本控制操作 4.3 遠端儲存庫整合 4.4 分支管理 4.5 處理合併衝突 4.6 Pull Request / Merge Request 管理 專案編譯與執行\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/intellij-idea-community-edition%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"IntelliJ IDEA Community Edition 使用教學手冊 文件資訊 版本: 1.0 建立日期: 2025年8月29日 適用對象: Java 後端開發新進人員 IDE 版本: IntelliJ IDEA Community Edition 2023.3+ 目錄 IntelliJ IDEA CE 下載與安裝\n1.1 下載 IntelliJ IDEA Community Edition 1.2 安裝步驟 1.3 首次啟動設定 1.4 授權與隱私設定 開發環境基本設定\n2.1 JDK 設定 2.2 Maven 整合設定 2.3 編碼設定 2.4 Code Style 設定 2.5 檢查器設定 匯入專案與建立新專案\n3.1 匯入現有專案 3.2 建立新專案 3.3 專案設定優化 與 Git/GitHub/GitLab 的整合\n4.1 Git 基本設定 4.2 本地版本控制操作 4.3 遠端儲存庫整合 4.4 分支管理 4.5 處理合併衝突 4.6 Pull Request / Merge Request 管理 專案編譯與執行\n","title":""},{"content":"Jenkins CI/CD 教學手冊 📋 目錄 (Table of Contents) 第一部分：基礎概念與環境建置 Jenkins 簡介與核心概念 環境安裝與基本設定 Jenkins 介面導覽 Plugin 管理與基礎設定 第二部分：Job 建立與管理 Freestyle Project 入門 憑證與密碼管理 Git 整合與版本控制 Maven 建置整合 第三部分：Pipeline 進階應用 Pipeline 基礎與 Declarative Syntax Jenkinsfile 結構深度分析 測試報告與程式碼覆蓋率整合 靜態程式碼分析與品質檢查 第四部分：進階功能與故障排除 Pipeline 故障排除與除錯技巧 部署策略與環境管理 監控、通知與效能優化 第五部分：企業級應用與最佳實務 企業級 CI/CD 架構設計 容器化與雲端整合 DevOps 文化與實務 實務案例研究 附錄 附錄 A：常用指令參考 A.1 Jenkins CLI 指令 A.2 Git 整合指令 A.3 Docker 容器指令 A.4 Kubernetes 部署指令 附錄 B：配置範例 B.1 Jenkins 系統配置範例 B.2 多環境配置範例 B.3 安全配置範例 附錄 C：故障排除指南 C.1 常見 Jenkins 問題 C.2 網路連接問題 C.3 Docker 建置問題 C.4 性能調優指南 附錄 D：最佳實踐清單 D.1 安全最佳實踐 D.2 效能最佳實踐 D.3 維護最佳實踐 附錄 E：工具和資源 E.1 推薦工具清單 E.2 學習資源 附錄 F：認證考試對照 F.1 Jenkins 認證考試對應 F.2 相關技術認證 附錄 G：版本更新歷史 📖 教學手冊說明 🎯 學習目標 本教學手冊旨在幫助新進 Java 開發者從零開始學習 Jenkins 與 CI/CD 自動化流程，涵蓋從基礎概念到實務應用的完整知識體系。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/jenkins-ci_cd-%E6%95%99%E5%AD%B8%E6%89%8B%E5%86%8A/","summary":"Jenkins CI/CD 教學手冊 📋 目錄 (Table of Contents) 第一部分：基礎概念與環境建置 Jenkins 簡介與核心概念 環境安裝與基本設定 Jenkins 介面導覽 Plugin 管理與基礎設定 第二部分：Job 建立與管理 Freestyle Project 入門 憑證與密碼管理 Git 整合與版本控制 Maven 建置整合 第三部分：Pipeline 進階應用 Pipeline 基礎與 Declarative Syntax Jenkinsfile 結構深度分析 測試報告與程式碼覆蓋率整合 靜態程式碼分析與品質檢查 第四部分：進階功能與故障排除 Pipeline 故障排除與除錯技巧 部署策略與環境管理 監控、通知與效能優化 第五部分：企業級應用與最佳實務 企業級 CI/CD 架構設計 容器化與雲端整合 DevOps 文化與實務 實務案例研究 附錄 附錄 A：常用指令參考 A.1 Jenkins CLI 指令 A.2 Git 整合指令 A.3 Docker 容器指令 A.4 Kubernetes 部署指令 附錄 B：配置範例 B.1 Jenkins 系統配置範例 B.2 多環境配置範例 B.3 安全配置範例 附錄 C：故障排除指南 C.1 常見 Jenkins 問題 C.2 網路連接問題 C.3 Docker 建置問題 C.4 性能調優指南 附錄 D：最佳實踐清單 D.1 安全最佳實踐 D.2 效能最佳實踐 D.3 維護最佳實踐 附錄 E：工具和資源 E.1 推薦工具清單 E.2 學習資源 附錄 F：認證考試對照 F.1 Jenkins 認證考試對應 F.2 相關技術認證 附錄 G：版本更新歷史 📖 教學手冊說明 🎯 學習目標 本教學手冊旨在幫助新進 Java 開發者從零開始學習 Jenkins 與 CI/CD 自動化流程，涵蓋從基礎概念到實務應用的完整知識體系。\n","title":""},{"content":"Apache JMeter 使用教學手冊 版本：v1.0（已完成第 1–16 章與附錄 A–E；持續維護優化）\n適用對象：完全未接觸過效能測試 / JMeter 的新進開發與測試人員\n文件目標：協助 1~2 天內快速具備撰寫並執行基本壓力測試腳本的能力，並建立後續進階自學基礎。\n快速導讀 若你是第一次接觸 JMeter，建議依序閱讀：\nPart 1（必讀）：了解 JMeter 是什麼、安裝、基礎 GUI 操作。 Part 2：學會設計一個可維護的測試計畫（參數化、控制器、Assertion）。 Part 3：掌握報表分析與常見最佳實務（非 GUI、分散式、效能瓶頸初步診斷）。 Part 4：實戰情境（API / Web / DB / 企業案例）。 Part 5：若需考 JMeter 認證或建置團隊基準能力。 附錄：錯誤排除、報告範本、學習資源、Checklist。 目錄（Table of Contents） Part 1. 基礎入門（Ch.1–3） JMeter 簡介\n1.1 JMeter 的定位與用途 1.2 常見測試類型 1.3 與其他工具比較 1.4 概念流程圖 1.5 本章實務案例 1.6 注意事項（初學者常犯） 安裝與環境設定\n2.1 系統需求 2.2 下載來源 2.3 安裝流程 2.4 目錄結構 2.5 常見安裝問題 2.6 調整啟動參數 2.7 本章實務練習 2.8 注意事項 JMeter 使用者介面 (GUI)\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/jmeter%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Apache JMeter 使用教學手冊 版本：v1.0（已完成第 1–16 章與附錄 A–E；持續維護優化）\n適用對象：完全未接觸過效能測試 / JMeter 的新進開發與測試人員\n文件目標：協助 1~2 天內快速具備撰寫並執行基本壓力測試腳本的能力，並建立後續進階自學基礎。\n快速導讀 若你是第一次接觸 JMeter，建議依序閱讀：\nPart 1（必讀）：了解 JMeter 是什麼、安裝、基礎 GUI 操作。 Part 2：學會設計一個可維護的測試計畫（參數化、控制器、Assertion）。 Part 3：掌握報表分析與常見最佳實務（非 GUI、分散式、效能瓶頸初步診斷）。 Part 4：實戰情境（API / Web / DB / 企業案例）。 Part 5：若需考 JMeter 認證或建置團隊基準能力。 附錄：錯誤排除、報告範本、學習資源、Checklist。 目錄（Table of Contents） Part 1. 基礎入門（Ch.1–3） JMeter 簡介\n1.1 JMeter 的定位與用途 1.2 常見測試類型 1.3 與其他工具比較 1.4 概念流程圖 1.5 本章實務案例 1.6 注意事項（初學者常犯） 安裝與環境設定\n2.1 系統需求 2.2 下載來源 2.3 安裝流程 2.4 目錄結構 2.5 常見安裝問題 2.6 調整啟動參數 2.7 本章實務練習 2.8 注意事項 JMeter 使用者介面 (GUI)\n","title":""},{"content":"Linux 使用教學 專案開發環境導向 + 認證準備指南\n適用於 Java 開發專案團隊的 Linux 學習手冊\n📋 目錄 1. 前言 1.1 本手冊目的 1.2 適用對象 1.3 專案環境說明 1.4 學習方法與建議 2. Linux 基礎概念 2.1 Linux 與開源精神簡介 2.2 Linux 系統架構 2.3 檔案系統階層結構 2.4 使用者與群組管理 2.5 檔案與目錄權限 3. Linux 常用指令 3.1 檔案與目錄操作 3.2 檔案檢視與搜尋 3.3 檔案壓縮與解壓縮 3.4 權限管理 3.5 程序管理 3.6 網路工具 3.7 軟體管理 4. 開發環境操作 4.1 安裝與設定 JDK 4.2 安裝與設定 Python 4.3 安裝與設定 Node.js 4.4 資料庫客戶端 4.5 使用 Git 與 GitLab/GitHub 4.6 容器化開發工具 4.7 Maven/Gradle 編譯與部署 5. 專案日常任務 5.1 SSH 遠端登入 5.2 檔案傳輸 5.3 Log 查詢與分析 5.4 錯誤排查技巧 5.5 排程任務 6. Linux 系統安全與最佳實務 6.1 sudo 與使用者權限控管 6.2 SSH 安全性 6.3 防火牆設定 6.4 SELinux / AppArmor 基本操作 7. CI/CD 與 Linux 整合 7.1 Jenkins 於 Linux 的安裝與設定 7.2 Jenkins Pipeline 與 Shell Script 7.3 Linux 與容器整合 7.4 自動化部署流程範例 8. Linux 認證導向補充 8.1 認證體系概覽 8.2 LFCS (Linux Foundation Certified System Administrator) 8.3 RHCSA (Red Hat Certified System Administrator) 8.4 LPI (Linux Professional Institute) 認證 8.5 認證準備策略 9. 附錄與總結 9.1 學習路徑總結 9.2 常見問題與解答 (FAQ) 9.3 實務檢查清單 9.4 進階學習資源 9.5 職涯發展指南 9.6 結語與展望 1. 前言 1.1 本手冊目的 📖 為什麼需要這份手冊？\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/linux%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Linux 使用教學 專案開發環境導向 + 認證準備指南\n適用於 Java 開發專案團隊的 Linux 學習手冊\n📋 目錄 1. 前言 1.1 本手冊目的 1.2 適用對象 1.3 專案環境說明 1.4 學習方法與建議 2. Linux 基礎概念 2.1 Linux 與開源精神簡介 2.2 Linux 系統架構 2.3 檔案系統階層結構 2.4 使用者與群組管理 2.5 檔案與目錄權限 3. Linux 常用指令 3.1 檔案與目錄操作 3.2 檔案檢視與搜尋 3.3 檔案壓縮與解壓縮 3.4 權限管理 3.5 程序管理 3.6 網路工具 3.7 軟體管理 4. 開發環境操作 4.1 安裝與設定 JDK 4.2 安裝與設定 Python 4.3 安裝與設定 Node.js 4.4 資料庫客戶端 4.5 使用 Git 與 GitLab/GitHub 4.6 容器化開發工具 4.7 Maven/Gradle 編譯與部署 5. 專案日常任務 5.1 SSH 遠端登入 5.2 檔案傳輸 5.3 Log 查詢與分析 5.4 錯誤排查技巧 5.5 排程任務 6. Linux 系統安全與最佳實務 6.1 sudo 與使用者權限控管 6.2 SSH 安全性 6.3 防火牆設定 6.4 SELinux / AppArmor 基本操作 7. CI/CD 與 Linux 整合 7.1 Jenkins 於 Linux 的安裝與設定 7.2 Jenkins Pipeline 與 Shell Script 7.3 Linux 與容器整合 7.4 自動化部署流程範例 8. Linux 認證導向補充 8.1 認證體系概覽 8.2 LFCS (Linux Foundation Certified System Administrator) 8.3 RHCSA (Red Hat Certified System Administrator) 8.4 LPI (Linux Professional Institute) 認證 8.5 認證準備策略 9. 附錄與總結 9.1 學習路徑總結 9.2 常見問題與解答 (FAQ) 9.3 實務檢查清單 9.4 進階學習資源 9.5 職涯發展指南 9.6 結語與展望 1. 前言 1.1 本手冊目的 📖 為什麼需要這份手冊？\n","title":""},{"content":"Maven 使用教學手冊 文件資訊 版本: 1.0.0 建立日期: 2025年8月29日 適用對象: 新進開發同仁 目的: 協助快速熟悉並在專案中正確使用 Maven 目錄 Maven 基本介紹 1.1 什麼是 Maven？ 1.2 Maven 的用途與優勢 1.3 在專案中的角色 環境建置 2.1 前置條件 2.2 Maven 安裝 2.3 驗證安裝成功 2.4 IDE 整合 2.5 設定檔配置 Maven 專案結構 3.1 標準目錄結構 3.2 目錄結構詳細說明 3.3 在專案中的實際應用 3.4 自訂目錄結構 pom.xml 說明 4.1 什麼是 POM？ 4.2 基本結構 4.3 常用標籤詳細說明 4.4 如何新增與管理依賴 4.5 建置配置 4.6 我們專案的完整 pom.xml 分析 常用指令 5.1 Maven 生命週期 5.2 基本指令詳解 5.3 依賴管理指令 5.4 執行指令 5.5 資訊查詢指令 5.6 進階指令 5.7 我們專案中的常用工作流程 5.8 VS Code 中的 Maven 整合 5.9 Maven Wrapper 使用 5.10 與 CI/CD 整合 專案最佳實務 6.1 依賴管理建議 6.2 Docker 整合 6.3 安全性管理 6.4 效能監控 6.5 現代化開發實務 6.6 效能優化策略 6.7 微服務架構支援 常見問題排解 FAQ 7.1 編譯相關問題 7.2 依賴相關問題 7.3 測試相關問題 7.4 IDE 整合問題 7.5 效能相關問題 7.6 網路相關問題 7.7 專案中注意事項 附錄 8.1 官方文件與教學資源連結 8.2 常用插件參考 8.3 Maven 生命週期詳細說明 8.4 常用 Maven 屬性 8.5 範例設定檔 8.6 團隊協作指南 檢查清單 Checklist 9.1 環境設定檢查清單 9.2 日常開發檢查清單 9.3 問題排解檢查清單 9.4 發布準備檢查清單 9.5 新人上手檢查清單 9.6 定期維護檢查清單 快速參考手冊 10.1 常用指令速查表 10.2 常用參數速查表 10.3 POM 檔案基本結構速查 10.4 常見問題快速解決 10.5 開發工作流程檢查清單 10.6 實用技巧 進階主題 11.1 自定義 Maven Archetype 11.2 Maven 插件開發 11.3 Maven 與 Spring Boot 整合 11.4 Maven 與容器化部署 11.5 企業級 Maven 倉庫管理 團隊協作與規範 12.1 程式碼審查規範 12.2 版本管理策略 12.3 分支管理與 Maven 12.4 自動化測試策略 Maven 與現代 Java 開發 13.1 Java 模組系統（JPMS）與 Maven 13.2 Maven 與 JDK 版本管理 13.3 Maven 與記錄（Records）和文字區塊 13.4 Maven 與虛擬執行緒 效能調校與監控 14.1 Maven 建置效能優化 14.2 依賴解析效能調校 14.3 建置時間監控與分析 14.4 記憶體使用最佳化 錯誤處理與除錯技巧 15.1 常見錯誤診斷流程 15.2 除錯工具與技巧 15.3 日誌分析與解讀 15.4 遠端除錯設定 實戰專案範例 16.1 簡單控制台應用程式 16.2 Spring Boot Web 應用程式 16.3 多模組企業級專案 16.4 微服務架構專案 1. Maven 基本介紹 1.1 什麼是 Maven？ Apache Maven 是一個專案管理和建置自動化工具，主要用於 Java 專案（也支援其他語言如 C#、Ruby、Scala 等）。Maven 使用專案物件模型（Project Object Model, POM）來管理專案的建置、報告和文件。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/maven%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Maven 使用教學手冊 文件資訊 版本: 1.0.0 建立日期: 2025年8月29日 適用對象: 新進開發同仁 目的: 協助快速熟悉並在專案中正確使用 Maven 目錄 Maven 基本介紹 1.1 什麼是 Maven？ 1.2 Maven 的用途與優勢 1.3 在專案中的角色 環境建置 2.1 前置條件 2.2 Maven 安裝 2.3 驗證安裝成功 2.4 IDE 整合 2.5 設定檔配置 Maven 專案結構 3.1 標準目錄結構 3.2 目錄結構詳細說明 3.3 在專案中的實際應用 3.4 自訂目錄結構 pom.xml 說明 4.1 什麼是 POM？ 4.2 基本結構 4.3 常用標籤詳細說明 4.4 如何新增與管理依賴 4.5 建置配置 4.6 我們專案的完整 pom.xml 分析 常用指令 5.1 Maven 生命週期 5.2 基本指令詳解 5.3 依賴管理指令 5.4 執行指令 5.5 資訊查詢指令 5.6 進階指令 5.7 我們專案中的常用工作流程 5.8 VS Code 中的 Maven 整合 5.9 Maven Wrapper 使用 5.10 與 CI/CD 整合 專案最佳實務 6.1 依賴管理建議 6.2 Docker 整合 6.3 安全性管理 6.4 效能監控 6.5 現代化開發實務 6.6 效能優化策略 6.7 微服務架構支援 常見問題排解 FAQ 7.1 編譯相關問題 7.2 依賴相關問題 7.3 測試相關問題 7.4 IDE 整合問題 7.5 效能相關問題 7.6 網路相關問題 7.7 專案中注意事項 附錄 8.1 官方文件與教學資源連結 8.2 常用插件參考 8.3 Maven 生命週期詳細說明 8.4 常用 Maven 屬性 8.5 範例設定檔 8.6 團隊協作指南 檢查清單 Checklist 9.1 環境設定檢查清單 9.2 日常開發檢查清單 9.3 問題排解檢查清單 9.4 發布準備檢查清單 9.5 新人上手檢查清單 9.6 定期維護檢查清單 快速參考手冊 10.1 常用指令速查表 10.2 常用參數速查表 10.3 POM 檔案基本結構速查 10.4 常見問題快速解決 10.5 開發工作流程檢查清單 10.6 實用技巧 進階主題 11.1 自定義 Maven Archetype 11.2 Maven 插件開發 11.3 Maven 與 Spring Boot 整合 11.4 Maven 與容器化部署 11.5 企業級 Maven 倉庫管理 團隊協作與規範 12.1 程式碼審查規範 12.2 版本管理策略 12.3 分支管理與 Maven 12.4 自動化測試策略 Maven 與現代 Java 開發 13.1 Java 模組系統（JPMS）與 Maven 13.2 Maven 與 JDK 版本管理 13.3 Maven 與記錄（Records）和文字區塊 13.4 Maven 與虛擬執行緒 效能調校與監控 14.1 Maven 建置效能優化 14.2 依賴解析效能調校 14.3 建置時間監控與分析 14.4 記憶體使用最佳化 錯誤處理與除錯技巧 15.1 常見錯誤診斷流程 15.2 除錯工具與技巧 15.3 日誌分析與解讀 15.4 遠端除錯設定 實戰專案範例 16.1 簡單控制台應用程式 16.2 Spring Boot Web 應用程式 16.3 多模組企業級專案 16.4 微服務架構專案 1. Maven 基本介紹 1.1 什麼是 Maven？ Apache Maven 是一個專案管理和建置自動化工具，主要用於 Java 專案（也支援其他語言如 C#、Ruby、Scala 等）。Maven 使用專案物件模型（Project Object Model, POM）來管理專案的建置、報告和文件。\n","title":""},{"content":"Podman Desktop 使用教學手冊 📋 目錄 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 1.2 與 Docker 的比較 1.3 安裝 Podman Desktop 1.4 基本操作介面導覽 2. 專案實務應用 2.1 在專案中使用 Podman Desktop 2.2 容器管理實務 2.3 映像檔管理 2.4 Volume 與 Network 管理 2.5 IDE 整合 3. 進階操作與最佳實務 3.1 Podman CLI 與 Desktop 搭配使用 3.2 Compose 支援與多容器應用管理 3.3 安全性與資源管理最佳實踐 3.4 與 Kubernetes/OpenShift 對接基礎 4. 認證考試準備 4.1 Podman 認證知識範圍 4.2 常見考題型態與解題練習 4.3 學習地圖與練習資源 5. 檢查清單 5.1 安裝驗證清單 5.2 開發環境設定清單 5.3 專案部署清單 5.4 安全性檢查清單 5.5 效能優化清單 5.6 故障排除清單 5.7 認證考試準備清單 5.8 日常維護清單 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 🎯 學習目標 理解 Podman 的核心概念與背景 了解 Podman Desktop 的功能與特色 掌握容器化技術的基本原理 什麼是 Podman？ Podman（Pod Manager） 是由 Red Hat 開發的開源容器引擎，提供無守護程序（daemonless）的容器管理解決方案。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/podman-desktop%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Podman Desktop 使用教學手冊 📋 目錄 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 1.2 與 Docker 的比較 1.3 安裝 Podman Desktop 1.4 基本操作介面導覽 2. 專案實務應用 2.1 在專案中使用 Podman Desktop 2.2 容器管理實務 2.3 映像檔管理 2.4 Volume 與 Network 管理 2.5 IDE 整合 3. 進階操作與最佳實務 3.1 Podman CLI 與 Desktop 搭配使用 3.2 Compose 支援與多容器應用管理 3.3 安全性與資源管理最佳實踐 3.4 與 Kubernetes/OpenShift 對接基礎 4. 認證考試準備 4.1 Podman 認證知識範圍 4.2 常見考題型態與解題練習 4.3 學習地圖與練習資源 5. 檢查清單 5.1 安裝驗證清單 5.2 開發環境設定清單 5.3 專案部署清單 5.4 安全性檢查清單 5.5 效能優化清單 5.6 故障排除清單 5.7 認證考試準備清單 5.8 日常維護清單 1. 基礎入門 1.1 Podman 與 Podman Desktop 介紹 🎯 學習目標 理解 Podman 的核心概念與背景 了解 Podman Desktop 的功能與特色 掌握容器化技術的基本原理 什麼是 Podman？ Podman（Pod Manager） 是由 Red Hat 開發的開源容器引擎，提供無守護程序（daemonless）的容器管理解決方案。\n","title":""},{"content":"Podman 使用教學手冊 📋 目錄 1. 基礎入門 1.1 什麼是 Podman 1.1.1 主要特色 1.1.2 適用場景 1.2 Podman 與 Docker 的差異 1.2.1 指令對比範例 1.3 安裝與環境設定 1.3.1 Windows 安裝 1.3.2 Linux 安裝 1.3.3 macOS 安裝 1.3.4 初始配置 1.4 基本概念 1.4.1 容器（Container） 1.4.2 映像檔（Image） 1.4.3 Pod 1.5 基本指令 1.5.1 映像檔管理 1.5.2 容器管理 1.5.3 實務範例 1.5.4 常用選項說明 1.6 注意事項與最佳實務 1.6.1 安全性注意事項 1.6.2 效能優化建議 1.6.3 疑難排解 📝 基礎實務練習 2. 專案實務應用 2.1 企業專案環境設置 2.1.1 典型企業專案架構 2.1.2 容器化策略 2.2 Spring Boot 應用容器化 2.2.1 建立 Dockerfile 2.2.2 建置和運行 Spring Boot 容器 2.3 前端應用容器化 2.3.1 React 應用 Dockerfile 2.3.2 Nginx 配置檔案 2.4 資料庫容器化 2.4.1 PostgreSQL 容器設置 2.4.2 Redis 快取容器 2.5 開發環境管理 2.5.1 開發環境 Pod 創建 2.5.2 開發工作流程 2.6 CI/CD 整合 2.6.1 GitLab CI 範例 2.6.2 GitHub Actions 範例 2.7 微服務架構實作 2.7.1 服務發現與負載平衡 2.7.2 API Gateway 設置 2.8 監控與日誌管理 2.8.1 集中式日誌收集 2.8.2 應用程式監控 2.9 除錯技巧 2.9.1 容器除錯 2.9.2 網路除錯 2.10 效能優化 2.10.1 映像檔優化 2.10.2 資源限制 📝 專案實務練習 3. 進階操作 3.1 Podman Compose 3.1.1 什麼是 Podman Compose 3.1.2 安裝 Podman Compose 3.1.3 Compose 檔案結構 3.1.4 Compose 常用指令 3.2 映像檔最佳化 3.2.1 多階段建置 3.2.2 映像檔層級最佳化 3.2.3 .containerignore 檔案 3.3 安全性強化 3.3.1 映像檔安全掃描 3.3.2 安全 Dockerfile 實務 3.3.3 容器執行時安全 3.4 Volume 管理 3.4.1 Volume 類型 3.4.2 Volume 操作 3.4.3 進階 Volume 配置 3.5 網路管理 3.5.1 網路類型 3.5.2 容器網路配置 3.5.3 網路除錯 3.6 Registry 管理 3.6.1 私有 Registry 設置 3.6.2 Registry 認證 3.6.3 Registry 鏡像配置 3.7 系統管理與維護 3.7.1 系統清理 3.7.2 系統監控 3.7.3 備份與還原 📝 進階實務練習 4. 考照準備 4.1 Podman 認證概述 4.1.1 認證類型 4.1.2 EX180 考試範圍 4.2 核心知識點整理 4.2.1 容器基本概念 4.2.2 Podman 架構特色 4.3 常見考題類型 4.3.1 基本操作題（30%） 4.3.2 Dockerfile 建置題（25%） 4.3.3 Pod 管理題（20%） 4.3.4 網路與儲存題（15%） 4.3.5 安全與故障排查題（10%） 4.4 實戰模擬題 4.4.1 綜合情境題 1 4.4.2 綜合情境題 2 4.5 考試策略與技巧 4.5.1 時間管理 4.5.2 常見錯誤避免 4.5.3 除錯技巧 4.6 練習題庫 4.6.1 基礎練習題 4.6.2 進階練習題 4.7 考前檢查清單 4.7.1 知識點檢查 4.7.2 實務操作檢查 4.7.3 考試環境準備 5. 附錄 5.1 常見錯誤排查 5.1.1 安裝和設定問題 5.1.2 容器運行問題 5.1.3 效能問題 5.2 最佳實務建議 5.2.1 安全性最佳實務 5.2.2 效能最佳實務 5.2.3 維護性最佳實務 5.3 指令參考手冊 5.3.1 映像檔管理指令 5.3.2 容器管理指令 5.3.3 Pod 管理指令 5.3.4 網路管理指令 5.3.5 Volume 管理指令 5.4 設定檔範本 5.4.1 Dockerfile 範本 5.4.2 Compose 檔案範本 5.5 工具和資源 5.5.1 有用的工具 5.5.2 學習資源 5.6 檢查清單（Checklist） 5.6.1 開發環境設置檢查清單 5.6.2 生產部署檢查清單 5.6.3 故障排查檢查清單 1. 基礎入門 1.1 什麼是 Podman Podman（Pod Manager）是一個開源的容器管理工具，由 Red Hat 開發。它提供與 Docker 相似的功能，但採用了不同的架構設計。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/podman%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Podman 使用教學手冊 📋 目錄 1. 基礎入門 1.1 什麼是 Podman 1.1.1 主要特色 1.1.2 適用場景 1.2 Podman 與 Docker 的差異 1.2.1 指令對比範例 1.3 安裝與環境設定 1.3.1 Windows 安裝 1.3.2 Linux 安裝 1.3.3 macOS 安裝 1.3.4 初始配置 1.4 基本概念 1.4.1 容器（Container） 1.4.2 映像檔（Image） 1.4.3 Pod 1.5 基本指令 1.5.1 映像檔管理 1.5.2 容器管理 1.5.3 實務範例 1.5.4 常用選項說明 1.6 注意事項與最佳實務 1.6.1 安全性注意事項 1.6.2 效能優化建議 1.6.3 疑難排解 📝 基礎實務練習 2. 專案實務應用 2.1 企業專案環境設置 2.1.1 典型企業專案架構 2.1.2 容器化策略 2.2 Spring Boot 應用容器化 2.2.1 建立 Dockerfile 2.2.2 建置和運行 Spring Boot 容器 2.3 前端應用容器化 2.3.1 React 應用 Dockerfile 2.3.2 Nginx 配置檔案 2.4 資料庫容器化 2.4.1 PostgreSQL 容器設置 2.4.2 Redis 快取容器 2.5 開發環境管理 2.5.1 開發環境 Pod 創建 2.5.2 開發工作流程 2.6 CI/CD 整合 2.6.1 GitLab CI 範例 2.6.2 GitHub Actions 範例 2.7 微服務架構實作 2.7.1 服務發現與負載平衡 2.7.2 API Gateway 設置 2.8 監控與日誌管理 2.8.1 集中式日誌收集 2.8.2 應用程式監控 2.9 除錯技巧 2.9.1 容器除錯 2.9.2 網路除錯 2.10 效能優化 2.10.1 映像檔優化 2.10.2 資源限制 📝 專案實務練習 3. 進階操作 3.1 Podman Compose 3.1.1 什麼是 Podman Compose 3.1.2 安裝 Podman Compose 3.1.3 Compose 檔案結構 3.1.4 Compose 常用指令 3.2 映像檔最佳化 3.2.1 多階段建置 3.2.2 映像檔層級最佳化 3.2.3 .containerignore 檔案 3.3 安全性強化 3.3.1 映像檔安全掃描 3.3.2 安全 Dockerfile 實務 3.3.3 容器執行時安全 3.4 Volume 管理 3.4.1 Volume 類型 3.4.2 Volume 操作 3.4.3 進階 Volume 配置 3.5 網路管理 3.5.1 網路類型 3.5.2 容器網路配置 3.5.3 網路除錯 3.6 Registry 管理 3.6.1 私有 Registry 設置 3.6.2 Registry 認證 3.6.3 Registry 鏡像配置 3.7 系統管理與維護 3.7.1 系統清理 3.7.2 系統監控 3.7.3 備份與還原 📝 進階實務練習 4. 考照準備 4.1 Podman 認證概述 4.1.1 認證類型 4.1.2 EX180 考試範圍 4.2 核心知識點整理 4.2.1 容器基本概念 4.2.2 Podman 架構特色 4.3 常見考題類型 4.3.1 基本操作題（30%） 4.3.2 Dockerfile 建置題（25%） 4.3.3 Pod 管理題（20%） 4.3.4 網路與儲存題（15%） 4.3.5 安全與故障排查題（10%） 4.4 實戰模擬題 4.4.1 綜合情境題 1 4.4.2 綜合情境題 2 4.5 考試策略與技巧 4.5.1 時間管理 4.5.2 常見錯誤避免 4.5.3 除錯技巧 4.6 練習題庫 4.6.1 基礎練習題 4.6.2 進階練習題 4.7 考前檢查清單 4.7.1 知識點檢查 4.7.2 實務操作檢查 4.7.3 考試環境準備 5. 附錄 5.1 常見錯誤排查 5.1.1 安裝和設定問題 5.1.2 容器運行問題 5.1.3 效能問題 5.2 最佳實務建議 5.2.1 安全性最佳實務 5.2.2 效能最佳實務 5.2.3 維護性最佳實務 5.3 指令參考手冊 5.3.1 映像檔管理指令 5.3.2 容器管理指令 5.3.3 Pod 管理指令 5.3.4 網路管理指令 5.3.5 Volume 管理指令 5.4 設定檔範本 5.4.1 Dockerfile 範本 5.4.2 Compose 檔案範本 5.5 工具和資源 5.5.1 有用的工具 5.5.2 學習資源 5.6 檢查清單（Checklist） 5.6.1 開發環境設置檢查清單 5.6.2 生產部署檢查清單 5.6.3 故障排查檢查清單 1. 基礎入門 1.1 什麼是 Podman Podman（Pod Manager）是一個開源的容器管理工具，由 Red Hat 開發。它提供與 Docker 相似的功能，但採用了不同的架構設計。\n","title":""},{"content":"Vim 使用教學手冊 目錄 前言 Vim 在專案中的角色 為什麼要學習 Vim 本手冊的學習方式與使用建議 第一篇：Vim 基礎入門 1. Vim 簡介 2. 安裝與環境設定 3. Vim 的操作模式 4. 文字編輯基礎 5. 檔案操作 第二篇：進階編輯技巧 6. 搜尋與取代 7. 巨集與自動化 8. 多檔案編輯與快速導覽 9. 文本處理進階 第三篇：專案開發實務 10. Vim 與程式開發 11. 插件管理 12. Git 與版本控制整合 13. 日常開發案例 第四篇：考試與認證準備 14. Vim 認證簡介 15. 模擬練習題 16. 學習路線圖 附錄 Vim 常用快捷鍵速查表 常見錯誤排解 推薦書籍與網站 練習建議 檢查清單（Checklist） 新進成員 Vim 技能檢查清單 團隊協作檢查清單 系統管理檢查清單 持續改進檢查清單 前言 Vim 在專案中的角色 在現代軟體開發專案中，Vim 扮演著重要的角色：\nLinux 伺服器管理必備工具：在產品環境中進行設定檔編輯、日誌查看、緊急修復 高效率文字編輯器：相較於圖形界面編輯器，Vim 在純文字環境下具有絕對優勢 跨平台一致性：無論在 Linux、macOS 或 Windows 環境，Vim 都能提供相同的操作體驗 與開發工具整合：許多現代 IDE 都提供 Vim 模式，學會 Vim 能提升整體開發效率 為什麼要學習 Vim mindmap root((為什麼學 Vim)) 效率提升 快速編輯 鍵盤操作 減少滑鼠依賴 專業需求 Linux 系統管理 遠端作業 伺服器維護 認證考試 LPIC RHCE CompTIA Linux\u0026#43; 技能發展 文字處理專精 自動化能力 工具整合 本手冊的學習方式與使用建議 循序漸進：建議按章節順序學習，每章都有實作練習 動手實作：理論與實務並重，務必完成每章的練習題 日常應用：將學會的技巧應用到實際專案開發中 認證導向：標註的認證重點可作為考試準備參考 第一篇：Vim 基礎入門 1. Vim 簡介 簡介 Vim（Vi IMproved）是基於經典的 Vi 編輯器所改良的文字編輯器，是 Unix/Linux 系統中最重要的編輯工具之一。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E5%B7%A5%E5%85%B7/vim%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Vim 使用教學手冊 目錄 前言 Vim 在專案中的角色 為什麼要學習 Vim 本手冊的學習方式與使用建議 第一篇：Vim 基礎入門 1. Vim 簡介 2. 安裝與環境設定 3. Vim 的操作模式 4. 文字編輯基礎 5. 檔案操作 第二篇：進階編輯技巧 6. 搜尋與取代 7. 巨集與自動化 8. 多檔案編輯與快速導覽 9. 文本處理進階 第三篇：專案開發實務 10. Vim 與程式開發 11. 插件管理 12. Git 與版本控制整合 13. 日常開發案例 第四篇：考試與認證準備 14. Vim 認證簡介 15. 模擬練習題 16. 學習路線圖 附錄 Vim 常用快捷鍵速查表 常見錯誤排解 推薦書籍與網站 練習建議 檢查清單（Checklist） 新進成員 Vim 技能檢查清單 團隊協作檢查清單 系統管理檢查清單 持續改進檢查清單 前言 Vim 在專案中的角色 在現代軟體開發專案中，Vim 扮演著重要的角色：\nLinux 伺服器管理必備工具：在產品環境中進行設定檔編輯、日誌查看、緊急修復 高效率文字編輯器：相較於圖形界面編輯器，Vim 在純文字環境下具有絕對優勢 跨平台一致性：無論在 Linux、macOS 或 Windows 環境，Vim 都能提供相同的操作體驗 與開發工具整合：許多現代 IDE 都提供 Vim 模式，學會 Vim 能提升整體開發效率 為什麼要學習 Vim mindmap root((為什麼學 Vim)) 效率提升 快速編輯 鍵盤操作 減少滑鼠依賴 專業需求 Linux 系統管理 遠端作業 伺服器維護 認證考試 LPIC RHCE CompTIA Linux\u0026#43; 技能發展 文字處理專精 自動化能力 工具整合 本手冊的學習方式與使用建議 循序漸進：建議按章節順序學習，每章都有實作練習 動手實作：理論與實務並重，務必完成每章的練習題 日常應用：將學會的技巧應用到實際專案開發中 認證導向：標註的認證重點可作為考試準備參考 第一篇：Vim 基礎入門 1. Vim 簡介 簡介 Vim（Vi IMproved）是基於經典的 Vi 編輯器所改良的文字編輯器，是 Unix/Linux 系統中最重要的編輯工具之一。\n","title":""},{"content":"Bash 使用教學手冊 📚 手冊說明 本手冊專為團隊新進開發同仁設計，旨在提供完整的 Bash 學習指引，讓同仁能夠：\n掌握 Bash 基礎與進階技能 在專案開發中正確使用 Bash 腳本 具備考取 Linux 相關認證的能力 遵循團隊 Bash 開發規範 📋 完整目錄結構 目錄 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 1.2 Bash 與 Linux/Unix 的關係 1.3 Bash 環境與版本檢查 1.4 常見開發環境介紹 1.5 基本命令列操作 1.6 編輯器使用 第 2 部分：Bash 核心語法 2.1 變數與資料型態 2.2 參數與引數 2.3 運算子與算術計算 2.4 條件判斷 2.5 迴圈結構 2.6 函式 2.7 輸入與輸出 2.8 管線與重新導向 第 3 部分：進階主題 3.1 陣列與字串處理 3.2 正則表達式與文字處理 3.3 檔案與目錄操作自動化 3.4 使用 cron 與排程任務 3.5 Bash 腳本除錯 3.6 錯誤處理 3.7 最佳實務 第 4 部分：專案應用實戰 4.1 自動化專案建置腳本 4.2 系統環境初始化 4.3 日誌分析與檔案過濾 4.4 檔案批次處理 4.5 自動化檔案傳輸 4.6 CI/CD 腳本整合 第 5 部分：考試準備 5.1 Bash 認證考試介紹 5.2 常見考試範疇與題型解析 5.3 範例考題與練習題 5.4 模擬測驗與解答解析 5.5 考試技巧與時間管理 第 6 部分：附錄 6.1 常用 Bash 指令速查表 6.2 Shell 腳本錯誤排查清單 6.3 Bash 相關學習資源 6.4 專案內部 Bash 腳本規範 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 📖 簡介 Bash（Bourne Again Shell）是一個命令列介面程式，也是一種腳本語言。它是 Linux 和 macOS 系統的預設 Shell，用於執行命令、自動化任務和系統管理。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/bash%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"Bash 使用教學手冊 📚 手冊說明 本手冊專為團隊新進開發同仁設計，旨在提供完整的 Bash 學習指引，讓同仁能夠：\n掌握 Bash 基礎與進階技能 在專案開發中正確使用 Bash 腳本 具備考取 Linux 相關認證的能力 遵循團隊 Bash 開發規範 📋 完整目錄結構 目錄 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 1.2 Bash 與 Linux/Unix 的關係 1.3 Bash 環境與版本檢查 1.4 常見開發環境介紹 1.5 基本命令列操作 1.6 編輯器使用 第 2 部分：Bash 核心語法 2.1 變數與資料型態 2.2 參數與引數 2.3 運算子與算術計算 2.4 條件判斷 2.5 迴圈結構 2.6 函式 2.7 輸入與輸出 2.8 管線與重新導向 第 3 部分：進階主題 3.1 陣列與字串處理 3.2 正則表達式與文字處理 3.3 檔案與目錄操作自動化 3.4 使用 cron 與排程任務 3.5 Bash 腳本除錯 3.6 錯誤處理 3.7 最佳實務 第 4 部分：專案應用實戰 4.1 自動化專案建置腳本 4.2 系統環境初始化 4.3 日誌分析與檔案過濾 4.4 檔案批次處理 4.5 自動化檔案傳輸 4.6 CI/CD 腳本整合 第 5 部分：考試準備 5.1 Bash 認證考試介紹 5.2 常見考試範疇與題型解析 5.3 範例考題與練習題 5.4 模擬測驗與解答解析 5.5 考試技巧與時間管理 第 6 部分：附錄 6.1 常用 Bash 指令速查表 6.2 Shell 腳本錯誤排查清單 6.3 Bash 相關學習資源 6.4 專案內部 Bash 腳本規範 第 1 部分：基礎入門 1.1 認識 Bash 與 Shell 📖 簡介 Bash（Bourne Again Shell）是一個命令列介面程式，也是一種腳本語言。它是 Linux 和 macOS 系統的預設 Shell，用於執行命令、自動化任務和系統管理。\n","title":""},{"content":"C# 程式語言教學手冊 目錄 基礎入門\n1.1 C# 與 .NET 基本概念 1.2 開發環境設定 1.3 基本語法 1.3.1 變數與資料型別 1.3.2 流程控制 1.3.3 函式 (方法) 1.3.4 例外處理 物件導向程式設計 (OOP)\n2.1 類別與物件基礎 2.1.1 類別定義 2.1.2 存取修飾詞 2.2 繼承 (Inheritance) 2.2.1 基本繼承 2.3 多型 (Polymorphism) 2.3.1 虛擬方法與覆寫 2.4 介面 (Interface) 2.4.1 介面定義與實作 2.5 抽象類別 進階語法與實務\n3.1 泛型 (Generics) 3.1.1 泛型基礎概念 3.1.2 泛型約束 3.2 委派與事件 (Delegates \u0026amp; Events) 3.2.1 委派基礎 3.2.2 內建委派型別 (Func, Action, Predicate) 3.3 LINQ 語法與集合操作 3.3.1 LINQ 基礎查詢 3.3.2 進階 LINQ 操作與實務應用 3.4 非同步程式設計 (async/await) 3.4.1 非同步基礎概念 3.4.2 非同步最佳實務與進階應用 專案實務應用\n4.1 Web API 開發 (ASP.NET Core) 4.1.1 建立基本 Web API 4.2 資料庫存取 (Entity Framework Core) 4.2.1 Entity Framework 設定 4.3 單元測試 (xUnit) 4.3.1 基本單元測試 4.4 錯誤處理與日誌紀錄 4.4.1 全域錯誤處理 認證考試對應\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/c%23%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"C# 程式語言教學手冊 目錄 基礎入門\n1.1 C# 與 .NET 基本概念 1.2 開發環境設定 1.3 基本語法 1.3.1 變數與資料型別 1.3.2 流程控制 1.3.3 函式 (方法) 1.3.4 例外處理 物件導向程式設計 (OOP)\n2.1 類別與物件基礎 2.1.1 類別定義 2.1.2 存取修飾詞 2.2 繼承 (Inheritance) 2.2.1 基本繼承 2.3 多型 (Polymorphism) 2.3.1 虛擬方法與覆寫 2.4 介面 (Interface) 2.4.1 介面定義與實作 2.5 抽象類別 進階語法與實務\n3.1 泛型 (Generics) 3.1.1 泛型基礎概念 3.1.2 泛型約束 3.2 委派與事件 (Delegates \u0026amp; Events) 3.2.1 委派基礎 3.2.2 內建委派型別 (Func, Action, Predicate) 3.3 LINQ 語法與集合操作 3.3.1 LINQ 基礎查詢 3.3.2 進階 LINQ 操作與實務應用 3.4 非同步程式設計 (async/await) 3.4.1 非同步基礎概念 3.4.2 非同步最佳實務與進階應用 專案實務應用\n4.1 Web API 開發 (ASP.NET Core) 4.1.1 建立基本 Web API 4.2 資料庫存取 (Entity Framework Core) 4.2.1 Entity Framework 設定 4.3 單元測試 (xUnit) 4.3.1 基本單元測試 4.4 錯誤處理與日誌紀錄 4.4.1 全域錯誤處理 認證考試對應\n","title":""},{"content":"HTML5 與 CSS3 程式語言教學手冊 目錄 前言 開發環境設定 HTML5 開發規範 CSS3 開發規範 專案中的命名規則與檔案結構 CSS 動畫與轉場效果 HTML5 新特性與 API JavaScript 整合與互動 網頁無障礙設計 常見錯誤與解決方法 開發最佳實務 範例程式碼 結語 檢查清單 1. 前言 1.1 HTML5 與 CSS3 在專案中的角色 HTML5 和 CSS3 是現代網頁開發的基石，在我們的專案中扮演著至關重要的角色：\nHTML5 的角色 結構定義者：負責網頁內容的語意化結構 互動基礎：提供表單、多媒體等互動元素 可及性保障：確保網站對所有使用者都能順利存取 SEO 基礎：良好的 HTML 結構有助於搜尋引擎優化 CSS3 的角色 視覺呈現：控制網頁的外觀與佈局 使用者體驗：創造流暢的動畫與互動效果 響應式設計：確保在各種裝置上都有良好的顯示效果 效能優化：減少不必要的圖片使用，提升載入速度 1.2 重要性 在現代網頁開發中，HTML5 和 CSS3 的重要性體現在：\n標準化：遵循 W3C 標準，確保跨瀏覽器相容性 可維護性：良好的結構和命名規則讓程式碼易於維護 效能：正確使用能大幅提升網頁載入速度 可及性：符合無障礙設計標準，服務更多使用者 SEO 優化：語意化的 HTML 有助於搜尋引擎理解內容 2. 開發環境設定 2.1 必要工具 2.1.1 程式碼編輯器 推薦：Visual Studio Code\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/html5%E8%88%87css3%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"HTML5 與 CSS3 程式語言教學手冊 目錄 前言 開發環境設定 HTML5 開發規範 CSS3 開發規範 專案中的命名規則與檔案結構 CSS 動畫與轉場效果 HTML5 新特性與 API JavaScript 整合與互動 網頁無障礙設計 常見錯誤與解決方法 開發最佳實務 範例程式碼 結語 檢查清單 1. 前言 1.1 HTML5 與 CSS3 在專案中的角色 HTML5 和 CSS3 是現代網頁開發的基石，在我們的專案中扮演著至關重要的角色：\nHTML5 的角色 結構定義者：負責網頁內容的語意化結構 互動基礎：提供表單、多媒體等互動元素 可及性保障：確保網站對所有使用者都能順利存取 SEO 基礎：良好的 HTML 結構有助於搜尋引擎優化 CSS3 的角色 視覺呈現：控制網頁的外觀與佈局 使用者體驗：創造流暢的動畫與互動效果 響應式設計：確保在各種裝置上都有良好的顯示效果 效能優化：減少不必要的圖片使用，提升載入速度 1.2 重要性 在現代網頁開發中，HTML5 和 CSS3 的重要性體現在：\n標準化：遵循 W3C 標準，確保跨瀏覽器相容性 可維護性：良好的結構和命名規則讓程式碼易於維護 效能：正確使用能大幅提升網頁載入速度 可及性：符合無障礙設計標準，服務更多使用者 SEO 優化：語意化的 HTML 有助於搜尋引擎理解內容 2. 開發環境設定 2.1 必要工具 2.1.1 程式碼編輯器 推薦：Visual Studio Code\n","title":""},{"content":"JavaScript 程式語言教學手冊 文件資訊 版本: 1.0 更新日期: 2025年8月29日 適用對象: 新進前端開發同仁 專案架構: 前後端分離 (Vue 3.x / React / Angular) 目錄 JavaScript 基本概念\n1.1 語言特性 1.2 基礎資料型別與運算子 1.3 變數與作用域 1.4 函式與閉包 1.5 物件與原型鏈 1.6 ES6+ 常用語法 1.7 實務注意事項 程式開發規範\n2.1 程式碼風格指南 2.2 ESLint 和 Prettier 設定 2.3 專案中常用的 Utility Functions 專案中常見應用範例\n3.1 DOM 操作與事件處理 3.2 非同步處理 3.3 與後端 API 溝通 3.4 錯誤處理與例外狀況處理 3.5 Web APIs 應用 3.6 專案最佳實務 3.7 測試與除錯 現代開發工具與 TypeScript\n4.1 TypeScript 基礎 4.2 建置工具 學習資源與進階閱讀\n5.1 官方文件與標準 5.2 推薦學習資源 5.3 實務工具與框架 5.4 社群與資源 5.5 持續學習建議 開發檢查清單\n6.1 程式碼品質檢查 6.2 安全性檢查 6.3 API 整合檢查 6.4 使用者體驗檢查 6.5 測試檢查 6.6 部署前檢查 6.7 維護檢查 1. JavaScript 基本概念 1.1 語言特性 JavaScript 是一種動態、弱型別的直譯式程式語言，具有以下核心特性：\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/javascript%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"JavaScript 程式語言教學手冊 文件資訊 版本: 1.0 更新日期: 2025年8月29日 適用對象: 新進前端開發同仁 專案架構: 前後端分離 (Vue 3.x / React / Angular) 目錄 JavaScript 基本概念\n1.1 語言特性 1.2 基礎資料型別與運算子 1.3 變數與作用域 1.4 函式與閉包 1.5 物件與原型鏈 1.6 ES6+ 常用語法 1.7 實務注意事項 程式開發規範\n2.1 程式碼風格指南 2.2 ESLint 和 Prettier 設定 2.3 專案中常用的 Utility Functions 專案中常見應用範例\n3.1 DOM 操作與事件處理 3.2 非同步處理 3.3 與後端 API 溝通 3.4 錯誤處理與例外狀況處理 3.5 Web APIs 應用 3.6 專案最佳實務 3.7 測試與除錯 現代開發工具與 TypeScript\n4.1 TypeScript 基礎 4.2 建置工具 學習資源與進階閱讀\n5.1 官方文件與標準 5.2 推薦學習資源 5.3 實務工具與框架 5.4 社群與資源 5.5 持續學習建議 開發檢查清單\n6.1 程式碼品質檢查 6.2 安全性檢查 6.3 API 整合檢查 6.4 使用者體驗檢查 6.5 測試檢查 6.6 部署前檢查 6.7 維護檢查 1. JavaScript 基本概念 1.1 語言特性 JavaScript 是一種動態、弱型別的直譯式程式語言，具有以下核心特性：\n","title":""},{"content":"Java 程式語言教學手冊 目錄 Java 語言簡介\n1.1 Java 的歷史與特性 1.2 為什麼專案使用 Java 1.3 Java 認證路線簡介 1.4 認證考點提醒 1.5 小練習 開發環境與工具\n2.1 JDK 安裝（Java 21） 2.2 IDE 設定 2.3 Build 工具 2.4 認證考點提醒 2.5 小練習 Java 基礎語法\n3.1 Hello World 程式 3.2 基本資料型別、變數、常數 3.3 運算子與型別轉換 3.4 流程控制 3.5 陣列操作 3.6 字串處理 3.7 認證考點提醒 3.8 小練習 物件導向程式設計 (OOP)\n4.1 類別與物件 4.2 建構子與方法 4.3 繼承 (Inheritance) 4.4 多型 (Polymorphism) 4.5 封裝 (Encapsulation) 4.6 抽象類別與介面 4.7 認證考點提醒 4.8 小練習 核心 API 與工具\n5.1 集合框架 (Collections Framework) 5.2 泛型 (Generics) 5.3 日期時間 API 5.4 檔案 I/O 操作 5.5 正規表達式 5.6 認證考點提醒 5.7 小練習 例外處理與錯誤管理\n6.1 例外處理機制 6.2 自訂例外 6.3 最佳實務 6.4 認證考點提醒 6.5 小練習 進階語法與認證內容\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/java%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80%E6%95%99%E5%AD%B8/","summary":"Java 程式語言教學手冊 目錄 Java 語言簡介\n1.1 Java 的歷史與特性 1.2 為什麼專案使用 Java 1.3 Java 認證路線簡介 1.4 認證考點提醒 1.5 小練習 開發環境與工具\n2.1 JDK 安裝（Java 21） 2.2 IDE 設定 2.3 Build 工具 2.4 認證考點提醒 2.5 小練習 Java 基礎語法\n3.1 Hello World 程式 3.2 基本資料型別、變數、常數 3.3 運算子與型別轉換 3.4 流程控制 3.5 陣列操作 3.6 字串處理 3.7 認證考點提醒 3.8 小練習 物件導向程式設計 (OOP)\n4.1 類別與物件 4.2 建構子與方法 4.3 繼承 (Inheritance) 4.4 多型 (Polymorphism) 4.5 封裝 (Encapsulation) 4.6 抽象類別與介面 4.7 認證考點提醒 4.8 小練習 核心 API 與工具\n5.1 集合框架 (Collections Framework) 5.2 泛型 (Generics) 5.3 日期時間 API 5.4 檔案 I/O 操作 5.5 正規表達式 5.6 認證考點提醒 5.7 小練習 例外處理與錯誤管理\n6.1 例外處理機制 6.2 自訂例外 6.3 最佳實務 6.4 認證考點提醒 6.5 小練習 進階語法與認證內容\n","title":""},{"content":"PowerShell 使用教學手冊 目錄 第 1 部分：基礎入門 認識 PowerShell\n1.1 PowerShell 的歷史與用途 1.2 與 CMD、Bash 的差異 1.3 PowerShell Core vs Windows PowerShell 安裝與環境設定\n2.1 在 Windows 安裝 PowerShell 2.2 跨平台安裝 2.3 PowerShell ISE 與 VS Code 整合 2.4 基本環境變數設定 基本操作\n3.1 常用指令（Get-Help、Get-Command、Get-Member） 3.2 管道 (Pipeline) 與物件導向特性 3.3 輸出與重新導向 第 2 部分：核心語法 變數與資料型態\n4.1 宣告與使用變數 4.2 常見資料型別 4.3 型態轉換與檢查 運算子與流程控制\n5.1 比較運算子與邏輯運算子 5.2 條件判斷（if, switch） 5.3 迴圈語法（for, foreach, while, do-while） 函數與模組\n6.1 定義與呼叫函數 6.2 參數與回傳值 6.3 匯入與建立模組 第 3 部分：進階技巧 物件與管道操作\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/powershell%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"PowerShell 使用教學手冊 目錄 第 1 部分：基礎入門 認識 PowerShell\n1.1 PowerShell 的歷史與用途 1.2 與 CMD、Bash 的差異 1.3 PowerShell Core vs Windows PowerShell 安裝與環境設定\n2.1 在 Windows 安裝 PowerShell 2.2 跨平台安裝 2.3 PowerShell ISE 與 VS Code 整合 2.4 基本環境變數設定 基本操作\n3.1 常用指令（Get-Help、Get-Command、Get-Member） 3.2 管道 (Pipeline) 與物件導向特性 3.3 輸出與重新導向 第 2 部分：核心語法 變數與資料型態\n4.1 宣告與使用變數 4.2 常見資料型別 4.3 型態轉換與檢查 運算子與流程控制\n5.1 比較運算子與邏輯運算子 5.2 條件判斷（if, switch） 5.3 迴圈語法（for, foreach, while, do-while） 函數與模組\n6.1 定義與呼叫函數 6.2 參數與回傳值 6.3 匯入與建立模組 第 3 部分：進階技巧 物件與管道操作\n","title":""},{"content":"SQL 使用教學手冊 目錄 1. SQL 基礎入門 1.1 什麼是 SQL？ 1.2 SQL 的特點 1.3 SQL 語句分類 1.4 第一個 SQL 查詢 2. 資料庫基本概念 2.1 關聯式資料庫模型 2.2 基本概念解釋 2.3 資料類型 2.4 正規化（Normalization） 3. 基本查詢語法 3.1 SELECT 語句基礎 3.2 查詢所有欄位 3.3 查詢特定欄位 3.4 WHERE 條件查詢 3.5 排序 ORDER BY 3.6 限制結果筆數 3.7 去除重複 DISTINCT 4. 進階查詢技巧 4.1 聚合函數 4.2 GROUP BY 分組查詢 4.3 HAVING 分組篩選 4.4 JOIN 表格連接 4.5 子查詢（Subquery） 4.6 WITH 公用表格表達式（CTE） 4.7 視窗函數（Window Functions） 5. 資料操作語言 (DML) 5.1 INSERT - 新增資料 5.2 UPDATE - 更新資料 5.3 DELETE - 刪除資料 5.4 UPSERT - 插入或更新 5.5 批次處理最佳實務 6. 資料定義語言 (DDL) 6.1 CREATE - 建立資料庫物件 6.2 ALTER - 修改資料庫物件 6.3 DROP - 刪除資料庫物件 6.4 TRUNCATE - 清空表格 6.5 資料類型選擇指南 6.6 表格設計最佳實務 6.7 效能考量 7. 交易處理與併發控制 7.1 交易基本概念 7.2 交易控制語句 7.3 交易隔離等級 7.4 併發問題與解決方案 7.5 鎖定機制 7.6 實務交易處理模式 8. 索引與效能優化 8.1 索引基本概念 8.2 索引類型 8.3 索引設計策略 8.4 查詢效能分析 8.5 查詢優化技巧 8.6 分割與分片 8.7 效能監控與維護 9. 儲存程序與函數 9.1 儲存程序基礎 9.2 函數 9.3 控制流程結構 9.4 例外處理 10. 安全性與防護 10.1 SQL Injection 防護 10.2 存取控制與權限管理 10.3 資料加密 10.4 稽核與監控 11. 專案實務案例 11.1 電商系統資料庫設計 11.2 常用業務查詢 11.3 效能優化實作 12. 認證考試準備 12.1 Oracle SQL 認證要點 12.2 Microsoft SQL Server 認證要點 12.3 PostgreSQL 認證要點 12.4 IBM DB2 認證要點 12.5 認證考試技巧 13. 最佳實務與故障排除 13.1 常見錯誤與解決方案 13.2 效能優化建議 13.3 開發最佳實務 13.4 資源推薦 前言 歡迎來到 SQL 的世界！SQL（Structured Query Language，結構化查詢語言）是與資料庫溝通的標準語言。無論您是新進的開發同仁，還是希望深化資料庫技能的工程師，這份教學手冊都將帶您從零開始，循序漸進地掌握 SQL 的精髓。\n","permalink":"https://chihhung.github.io/Blog/doc/%E6%95%99%E5%AD%B8/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/sql%E4%BD%BF%E7%94%A8%E6%95%99%E5%AD%B8/","summary":"SQL 使用教學手冊 目錄 1. SQL 基礎入門 1.1 什麼是 SQL？ 1.2 SQL 的特點 1.3 SQL 語句分類 1.4 第一個 SQL 查詢 2. 資料庫基本概念 2.1 關聯式資料庫模型 2.2 基本概念解釋 2.3 資料類型 2.4 正規化（Normalization） 3. 基本查詢語法 3.1 SELECT 語句基礎 3.2 查詢所有欄位 3.3 查詢特定欄位 3.4 WHERE 條件查詢 3.5 排序 ORDER BY 3.6 限制結果筆數 3.7 去除重複 DISTINCT 4. 進階查詢技巧 4.1 聚合函數 4.2 GROUP BY 分組查詢 4.3 HAVING 分組篩選 4.4 JOIN 表格連接 4.5 子查詢（Subquery） 4.6 WITH 公用表格表達式（CTE） 4.7 視窗函數（Window Functions） 5. 資料操作語言 (DML) 5.1 INSERT - 新增資料 5.2 UPDATE - 更新資料 5.3 DELETE - 刪除資料 5.4 UPSERT - 插入或更新 5.5 批次處理最佳實務 6. 資料定義語言 (DDL) 6.1 CREATE - 建立資料庫物件 6.2 ALTER - 修改資料庫物件 6.3 DROP - 刪除資料庫物件 6.4 TRUNCATE - 清空表格 6.5 資料類型選擇指南 6.6 表格設計最佳實務 6.7 效能考量 7. 交易處理與併發控制 7.1 交易基本概念 7.2 交易控制語句 7.3 交易隔離等級 7.4 併發問題與解決方案 7.5 鎖定機制 7.6 實務交易處理模式 8. 索引與效能優化 8.1 索引基本概念 8.2 索引類型 8.3 索引設計策略 8.4 查詢效能分析 8.5 查詢優化技巧 8.6 分割與分片 8.7 效能監控與維護 9. 儲存程序與函數 9.1 儲存程序基礎 9.2 函數 9.3 控制流程結構 9.4 例外處理 10. 安全性與防護 10.1 SQL Injection 防護 10.2 存取控制與權限管理 10.3 資料加密 10.4 稽核與監控 11. 專案實務案例 11.1 電商系統資料庫設計 11.2 常用業務查詢 11.3 效能優化實作 12. 認證考試準備 12.1 Oracle SQL 認證要點 12.2 Microsoft SQL Server 認證要點 12.3 PostgreSQL 認證要點 12.4 IBM DB2 認證要點 12.5 認證考試技巧 13. 最佳實務與故障排除 13.1 常見錯誤與解決方案 13.2 效能優化建議 13.3 開發最佳實務 13.4 資源推薦 前言 歡迎來到 SQL 的世界！SQL（Structured Query Language，結構化查詢語言）是與資料庫溝通的標準語言。無論您是新進的開發同仁，還是希望深化資料庫技能的工程師，這份教學手冊都將帶您從零開始，循序漸進地掌握 SQL 的精髓。\n","title":""},{"content":"System_Analysis_Phase/ ├── 01_SRS/ # 需求規格文件 │ ├── 01_前言.md │ ├── 02_整體描述.md │ ├── 03_功能性需求.md │ ├── 04_非功能性需求.md │ ├── 05_系統介面需求.md │ └── 附錄_名詞解釋_參考資料.md │ ├── 02_Use_Case/ # 使用案例文件 │ ├── 00_使用案例總覽圖.png │ ├── UC01_名稱_使用案例說明.md │ ├── UC02_名稱_使用案例說明.md │ ├── UCxx_\u0026hellip;md │ ├── 使用案例活動圖/ # Activity Diagrams │ │ ├── UC01_活動圖.png │ │ └── UC02_活動圖.png │ └── 使用案例需求對應表.xlsx │ ├── 03_System_Model/ # 系統模型 (UML) │ ├── Object_Model/ # 物件模型 │ │ ├── 類別圖_ClassDiagram.png │ │ └── 物件圖_ObjectDiagram.png │ ├── Interaction_Model/ # 互動模型 │ │ ├── UC01_序列圖_Sequence.png │ │ ├── UC02_序列圖_Sequence.png │ │ └── 通訊圖_Communication.png │ ├── State_Model/ # 狀態模型 │ │ ├── ClassA_狀態圖.png │ │ └── ClassB_狀態圖.png │ └── Supplementary_Model/ # 補充模型 │ ├── 組件圖_Component.png │ └── 部署圖_Deployment.png │ ├── 04_Data_Model/ # 資料模型 │ ├── ER_Model.png │ ├── Class_Table_Mapping.xlsx │ └── Data_Dictionary.xlsx │ ├── 05_RTM/ # 需求追蹤矩陣 │ └── Requirement_Traceability_Matrix.xlsx │ ├── 06_Validation_Review/ # 驗證與審查 │ ├── 需求審查會議紀錄.md │ ├── 問題清單與解決狀態.xlsx │ └── 需求基線確認_Baseline_Approval.pdf │ └── README.md # 系統分析階段文件總覽\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E6%96%87%E4%BB%B6%E7%9B%AE%E9%8C%84%E7%AF%84%E4%BE%8B/","summary":"System_Analysis_Phase/ ├── 01_SRS/ # 需求規格文件 │ ├── 01_前言.md │ ├── 02_整體描述.md │ ├── 03_功能性需求.md │ ├── 04_非功能性需求.md │ ├── 05_系統介面需求.md │ └── 附錄_名詞解釋_參考資料.md │ ├── 02_Use_Case/ # 使用案例文件 │ ├── 00_使用案例總覽圖.png │ ├── UC01_名稱_使用案例說明.md │ ├── UC02_名稱_使用案例說明.md │ ├── UCxx_\u0026hellip;md │ ├── 使用案例活動圖/ # Activity Diagrams │ │ ├── UC01_活動圖.png │ │ └── UC02_活動圖.png │ └── 使用案例需求對應表.xlsx │ ├── 03_System_Model/ # 系統模型 (UML) │ ├── Object_Model/ # 物件模型 │ │ ├── 類別圖_ClassDiagram.png │ │ └── 物件圖_ObjectDiagram.png │ ├── Interaction_Model/ # 互動模型 │ │ ├── UC01_序列圖_Sequence.png │ │ ├── UC02_序列圖_Sequence.png │ │ └── 通訊圖_Communication.png │ ├── State_Model/ # 狀態模型 │ │ ├── ClassA_狀態圖.png │ │ └── ClassB_狀態圖.png │ └── Supplementary_Model/ # 補充模型 │ ├── 組件圖_Component.png │ └── 部署圖_Deployment.png │ ├── 04_Data_Model/ # 資料模型 │ ├── ER_Model.png │ ├── Class_Table_Mapping.xlsx │ └── Data_Dictionary.xlsx │ ├── 05_RTM/ # 需求追蹤矩陣 │ └── Requirement_Traceability_Matrix.xlsx │ ├── 06_Validation_Review/ # 驗證與審查 │ ├── 需求審查會議紀錄.md │ ├── 問題清單與解決狀態.xlsx │ └── 需求基線確認_Baseline_Approval.pdf │ └── README.md # 系統分析階段文件總覽\n","title":""},{"content":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄：\n01_SRS/ ├── 01_前言.md # 文件目的、系統範疇、名詞定義 ├── 02_整體描述.md # 系統目標、利害關係人、作業環境、限制 ├── 03_功能性需求.md # 按模組/使用案例列需求 ├── 04_非功能性需求.md # 效能、安全性、可用性、法規 ├── 05_系統介面需求.md # 外部系統介接、API、資料交換 └── 附錄_參考資料.md\n2️⃣ 使用案例文件 (Use Case Specification)\n目錄：\n02_Use_Case/ ├── 00_使用案例總覽圖.png ├── UC01_名稱_說明.md # 前置條件、後置條件、主要/替代流程 ├── UC02_名稱_說明.md ├── UCxx_\u0026hellip;md ├── 使用案例活動圖/ │ ├── UC01_活動圖.png │ └── UC02_活動圖.png └── 使用案例需求對應表.xlsx\n3️⃣ 系統模型文件 (UML Models)\n目錄：\n03_System_Model/ ├── Object_Model/ # 物件模型 │ ├── 類別圖_ClassDiagram.png │ └── 物件圖_ObjectDiagram.png ├── Interaction_Model/ # 互動模型 │ ├── UC01_序列圖.png │ ├── UC02_序列圖.png │ └── 通訊圖_Communication.png ├── State_Model/ # 狀態模型 │ ├── ClassA_狀態圖.png │ └── ClassB_狀態圖.png └── Supplementary_Model/ # 補充模型 ├── 組件圖_Component.png └── 部署圖_Deployment.png\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AEooa/","summary":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄：\n01_SRS/ ├── 01_前言.md # 文件目的、系統範疇、名詞定義 ├── 02_整體描述.md # 系統目標、利害關係人、作業環境、限制 ├── 03_功能性需求.md # 按模組/使用案例列需求 ├── 04_非功能性需求.md # 效能、安全性、可用性、法規 ├── 05_系統介面需求.md # 外部系統介接、API、資料交換 └── 附錄_參考資料.md\n2️⃣ 使用案例文件 (Use Case Specification)\n目錄：\n02_Use_Case/ ├── 00_使用案例總覽圖.png ├── UC01_名稱_說明.md # 前置條件、後置條件、主要/替代流程 ├── UC02_名稱_說明.md ├── UCxx_\u0026hellip;md ├── 使用案例活動圖/ │ ├── UC01_活動圖.png │ └── UC02_活動圖.png └── 使用案例需求對應表.xlsx\n3️⃣ 系統模型文件 (UML Models)\n目錄：\n03_System_Model/ ├── Object_Model/ # 物件模型 │ ├── 類別圖_ClassDiagram.png │ └── 物件圖_ObjectDiagram.png ├── Interaction_Model/ # 互動模型 │ ├── UC01_序列圖.png │ ├── UC02_序列圖.png │ └── 通訊圖_Communication.png ├── State_Model/ # 狀態模型 │ ├── ClassA_狀態圖.png │ └── ClassB_狀態圖.png └── Supplementary_Model/ # 補充模型 ├── 組件圖_Component.png └── 部署圖_Deployment.png\n","title":""},{"content":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄建議：\n前言 1.1 文件目的 1.2 系統範疇與邊界 1.3 定義、縮寫與名詞解釋 1.4 文件參考資料\n整體描述 2.1 系統目標 2.2 系統使用者與利害關係人 2.3 作業環境 (硬體/軟體/網路/外部系統) 2.4 假設與限制\n功能性需求\n按使用案例或模組分項列出需求 非功能性需求\n效能需求 (Response Time, Throughput) 安全性需求 (Authentication, Authorization, Audit) 可用性 / 擴充性需求 法規/合規性需求 系統介面需求\n外部系統介接規格 API / 資料交換格式 2️⃣ 使用案例文件 (Use Case Specification) 目錄建議：\n使用案例總覽 (Use Case Diagram)\n使用案例清單\nUC01：名稱、角色、前置條件、後置條件、主要流程、替代流程、例外情境 UC02 … 使用案例活動圖 (Activity Diagram)\n用案例與需求對應表 (Traceability)\n3️⃣ 系統模型文件 (UML Models)\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E5%88%86%E6%9E%90%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AE/","summary":"1️⃣ 需求規格文件 (SRS – Software Requirement Specification)\n目錄建議：\n前言 1.1 文件目的 1.2 系統範疇與邊界 1.3 定義、縮寫與名詞解釋 1.4 文件參考資料\n整體描述 2.1 系統目標 2.2 系統使用者與利害關係人 2.3 作業環境 (硬體/軟體/網路/外部系統) 2.4 假設與限制\n功能性需求\n按使用案例或模組分項列出需求 非功能性需求\n效能需求 (Response Time, Throughput) 安全性需求 (Authentication, Authorization, Audit) 可用性 / 擴充性需求 法規/合規性需求 系統介面需求\n外部系統介接規格 API / 資料交換格式 2️⃣ 使用案例文件 (Use Case Specification) 目錄建議：\n使用案例總覽 (Use Case Diagram)\n使用案例清單\nUC01：名稱、角色、前置條件、後置條件、主要流程、替代流程、例外情境 UC02 … 使用案例活動圖 (Activity Diagram)\n用案例與需求對應表 (Traceability)\n3️⃣ 系統模型文件 (UML Models)\n","title":""},{"content":"系統設計階段標準範本清單OOD（含文件目錄、流程、工作項目） 文件目錄 (Deliverables) 系統設計總覽文件 (System Design Specification, SDS) 設計目標與範疇 架構原則與設計考量 系統邊界與外部介面 架構設計文件 (Architecture Design Document, ADD) 系統整體架構圖 (Logical / Physical) 分層架構 (Layered Architecture) 模組/子系統劃分與責任定義 技術棧與設計決策紀錄 (ADR) 資料設計文件 (Data Design Document, DDD) 資料模型 (ERD) 類別圖 (Class Diagram) 資料表設計與正規化說明 交易與一致性設計 物件導向設計文件 (Object-Oriented Design Document) 類別與責任 (CRC 卡片) 類別圖 / 物件圖 繼承、多型設計 設計模式應用 介面設計文件 (Interface Design Specification, IDS) API 設計 (REST/GraphQL) 資料交換格式 (JSON, XML) UI/UX Wireframe、螢幕設計稿 流程與行為設計文件 (Behavioral Design Specification) Use Case Realization Sequence Diagram State Diagram Activity Diagram 安全設計文件 (Security Design Document) 認證與授權設計 資料加密與存取控制 威脅模型 (Threat Modeling) 基礎設施與部署設計文件 (Deployment Design) 系統拓撲圖 伺服器/容器配置 CI/CD 流程設計 系統設計流程 (Workflow, OOD) 輸入：系統分析成果 (SRS, Use Case, 需求模型)\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AEood%E5%90%AB%E6%96%87%E4%BB%B6%E7%9B%AE%E9%8C%84%E6%B5%81%E7%A8%8B%E5%B7%A5%E4%BD%9C%E9%A0%85%E7%9B%AE/","summary":"系統設計階段標準範本清單OOD（含文件目錄、流程、工作項目） 文件目錄 (Deliverables) 系統設計總覽文件 (System Design Specification, SDS) 設計目標與範疇 架構原則與設計考量 系統邊界與外部介面 架構設計文件 (Architecture Design Document, ADD) 系統整體架構圖 (Logical / Physical) 分層架構 (Layered Architecture) 模組/子系統劃分與責任定義 技術棧與設計決策紀錄 (ADR) 資料設計文件 (Data Design Document, DDD) 資料模型 (ERD) 類別圖 (Class Diagram) 資料表設計與正規化說明 交易與一致性設計 物件導向設計文件 (Object-Oriented Design Document) 類別與責任 (CRC 卡片) 類別圖 / 物件圖 繼承、多型設計 設計模式應用 介面設計文件 (Interface Design Specification, IDS) API 設計 (REST/GraphQL) 資料交換格式 (JSON, XML) UI/UX Wireframe、螢幕設計稿 流程與行為設計文件 (Behavioral Design Specification) Use Case Realization Sequence Diagram State Diagram Activity Diagram 安全設計文件 (Security Design Document) 認證與授權設計 資料加密與存取控制 威脅模型 (Threat Modeling) 基礎設施與部署設計文件 (Deployment Design) 系統拓撲圖 伺服器/容器配置 CI/CD 流程設計 系統設計流程 (Workflow, OOD) 輸入：系統分析成果 (SRS, Use Case, 需求模型)\n","title":""},{"content":"📂 系統設計階段標準範本清單（樹狀結構版）\n文件目錄 (Document Templates) 1.1 系統設計總規劃書 (System Design Document, SDD) 1.2 系統架構設計書 (System Architecture Design) 1.3 資料庫設計書 (Database Design Document, DDD) 1.4 模組設計規格書 (Module Design Specification) 1.5 介面設計規格書 (Interface Design Specification, API/Batch) 1.6 UI/UX 設計文件 (Wireframe, Mockup, Prototype) 1.7 輸入/輸出設計文件 (I/O Design, Report Spec) 1.8 流程設計文件 (DFD, Activity Diagram, Sequence Diagram, State Diagram) 1.9 安全性設計規格書 (Security Design Spec, RBAC/ABAC) 1.10 例外處理/錯誤處理設計書 (Error \u0026amp; Exception Handling Spec) 1.11 批次處理設計文件 (Batch Job Design Spec, Schedule Spec) 1.12 系統整合設計書 (Integration Design, API Gateway, MQ, SFTP) 1.13 測試設計準則 (Test Design Basis, Traceability Matrix)\n","permalink":"https://chihhung.github.io/Blog/doc/%E7%AF%84%E6%9C%AC/%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E9%9A%8E%E6%AE%B5%E6%A8%99%E6%BA%96%E7%AF%84%E6%9C%AC%E6%B8%85%E5%96%AE%E6%A8%B9%E7%8B%80%E7%B5%90%E6%A7%8B%E7%89%88/","summary":"📂 系統設計階段標準範本清單（樹狀結構版）\n文件目錄 (Document Templates) 1.1 系統設計總規劃書 (System Design Document, SDD) 1.2 系統架構設計書 (System Architecture Design) 1.3 資料庫設計書 (Database Design Document, DDD) 1.4 模組設計規格書 (Module Design Specification) 1.5 介面設計規格書 (Interface Design Specification, API/Batch) 1.6 UI/UX 設計文件 (Wireframe, Mockup, Prototype) 1.7 輸入/輸出設計文件 (I/O Design, Report Spec) 1.8 流程設計文件 (DFD, Activity Diagram, Sequence Diagram, State Diagram) 1.9 安全性設計規格書 (Security Design Spec, RBAC/ABAC) 1.10 例外處理/錯誤處理設計書 (Error \u0026amp; Exception Handling Spec) 1.11 批次處理設計文件 (Batch Job Design Spec, Schedule Spec) 1.12 系統整合設計書 (Integration Design, API Gateway, MQ, SFTP) 1.13 測試設計準則 (Test Design Basis, Traceability Matrix)\n","title":""}]