版本: 1.0 最後更新: 2026年1月9日 適用於: Claude Code Created by: Eric Cheng Claude Code 使用教學手冊（新進同仁版） 版本：1.0 最後更新：2026 年 1 月 適用對象：新進軟體工程師（PG / SA / Tech Lead 初階） 先決條件：具備基本程式設計能力 目錄 第 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 的使用方式。 ...

Java25升版教學 版本: 1.0 最後更新: 2025年12月31日 適用於: java 25 Created by: Eric Cheng +++ Java 1.7 → Java 25 升版教學手冊 版本：1.0 最後更新：2025 年 12 月 適用對象：具備 Java 1.7～8 基礎的開發人員 目標：企業升版實務 + Java OCP 認證準備 📋 目錄 前言 第一章：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 & 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 經歷了翻天覆地的變化： ...

OpenSpec 使用教學手冊 版本：5.0 更新日期：2026-04-27 適用版本：OpenSpec v1.3.1（含 Profiles、OPSX 工作流程、動態指令架構、語義規格同步、Canonical Artifact Paths、Junie / Lingma / ForgeCode / IBM Bob 新工具支援） 適用對象：新進軟體工程師、系統分析師、尚未接觸過 SDD 或 OpenSpec 的同仁 官方網站：openspec.dev 目錄 前言 為什麼需要這份手冊？ 本手冊的目標 閱讀建議 第一章：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.3.x） 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 協作模式 第九章小結 附錄：檢查清單（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 助手在沒有明確規格的情況下，容易產生不符合需求的程式碼，或是理解偏差導致返工。 ...

BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員: 理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象: 新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式: 循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 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,行為驅動開發) 是一種軟體開發方法論,強調: ...

TDD（Test-Driven Development）測試驅動開發使用教學手冊 📚 目錄 一、前言 1.1 教學目的 1.2 適用對象 1.3 預期學習成果 1.4 教學手冊架構說明 二、TDD 概念與原則 2.1 什麼是 TDD（Test-Driven Development） 2.2 TDD 的核心循環：Red → Green → Refactor 2.3 TDD 與傳統開發流程的差異 2.4 為什麼使用 TDD：好處與挑戰 2.5 單元測試 vs. 集成測試 vs. 系統測試 三、TDD 實踐步驟 3.1 Step 1：撰寫失敗的測試（Red） 3.2 Step 2：撰寫最簡單的實作通過測試（Green） 3.3 Step 3：重構程式碼（Refactor） 3.4 Step 4：重複循環與迭代開發 3.5 驗收標準（Definition of Done）與測試覆蓋率要求 四、TDD 開發環境與工具 4.1 測試框架介紹 4.2 IDE 與工具設定 4.3 持續整合（CI）與自動化測試 4.4 測試覆蓋率工具 4.5 測試資料與 Mock 工具 ...

📝 專案計畫書範本(草稿) 1. 專案簡介 專案名稱：應用系統架構轉型計畫 專案目標： Phase 1：單體 → 容器化 → 上雲，達成 Lift & Shift Phase 2：單體 → 微服務 → 容器化 → 上雲，完成業務導向解耦 範圍： 涉及核心應用（XX 系統）、資料庫（DB2 / Oracle）、應用伺服器（Liberty）、批次處理（Spring Batch） 預期效益： 部署時間縮短 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 知會) ...

Codebase（單一程式碼庫，多個部署環境） 原則：一個應用程式應有單一程式碼庫，透過不同的部署（deploy）對應不同環境（dev/test/prod）。 解決方案： 使用 GitLab repository 管理專案。 每個環境使用不同 branch 或 tag（如 develop, release, main）。 CI/CD pipeline 進行自動化部署，避免分散程式碼庫。 Dependencies（明確宣告與隔離依賴） 原則：應用程式必須明確管理相依性，避免依賴系統環境。 解決方案： 後端：使用 Maven pom.xml 宣告所有 dependencies，不依賴本地安裝的 jar。 前端：使用 package.json 鎖定依賴版本。 建議使用 Docker 建立一致的 build/runtime 環境。 Config（將設定與程式碼分離） 原則：設定（如 DB 密碼、API key）不應寫死在程式碼中。 解決方案： Spring Boot 使用 application.yml + 外部設定檔 或 環境變數。 GitLab CI/CD 提供 Environment Variables 管理不同環境的設定。 建議搭配 Vault / AWS Secrets Manager / Kubernetes Secrets。 Backing Services（後端服務當作附加資源） 原則：資料庫、快取、MQ、外部 API 都應視為「可替換的資源」。 解決方案： DB（MySQL/DB2/PostgreSQL）、Redis、RabbitMQ 等連線資訊放在設定檔，不耦合程式。 測試環境可用輕量替代（如 testcontainers 啟動 DB/Redis）。 Build, Release, Run（明確分離建置、發佈、執行） 原則：建置（build）、發佈（release）、執行（run）必須分開，避免環境污染。 解決方案： ...

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 & 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 開發維護的前端框架，具有以下優勢： ...

版本：v1.1（已完成第 1-16 章與附錄 A-E；持續維護優化） 最後更新：2026-02-12（對應 JMeter 5.6.3 版本） 適用對象：完全未接觸過效能測試 / JMeter 的新進開發與測試人員 文件目標：協助 1~2 天內快速具備撰寫並執行基本壓力測試腳本的能力，並建立後續進階自學基礎。 快速導讀 若你是第一次接觸 JMeter，建議依序閱讀： Part 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 簡介 1.1 JMeter 的定位與用途 1.2 常見測試類型 1.3 與其他工具比較 1.4 概念流程圖 1.5 本章實務案例 1.6 注意事項（初學者常犯） 2. 安裝與環境設定 ...

API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。 角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。 任務描述 請協助我完成 {專案名稱} 的API設計工作。 API 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計： 1. 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 { "id": "string (UUID)", "username": "string (3-50字元)", "email": "string (email格式)", "firstName": "string (1-50字元)", "lastName": "string (1-50字元)", "role": "string (enum: admin, user, guest)", "status": "string (enum: active, inactive, suspended)", "createdAt": "string (ISO 8601 datetime)", "updatedAt": "string (ISO 8601 datetime)" } 實體: Product (產品) { "id": "string (UUID)", "name": "string (1-200字元)", "description": "string (可選，最多1000字元)", "price": "number (正數，最多2位小數)", "category": "string", "sku": "string (產品編號)", "inventory": { "quantity": "integer (非負整數)", "reserved": "integer (非負整數)" }, "images": ["string (URL陣列)"], "attributes": { "color": "string", "size": "string", "weight": "number" }, "isActive": "boolean", "createdAt": "string (ISO 8601 datetime)", "updatedAt": "string (ISO 8601 datetime)" } 2.2 標準回應格式 成功回應格式 { "success": true, "data": { // 實際資料內容 }, "meta": { "timestamp": "ISO 8601 datetime", "requestId": "UUID", "pagination": { // 僅分頁查詢時包含 "page": 1, "limit": 20, "total": 100, "totalPages": 5 } } } 錯誤回應格式 { "success": false, "error": { "code": "ERROR_CODE", "message": "錯誤訊息", "details": "詳細錯誤說明", "field": "發生錯誤的欄位 (驗證錯誤時)" }, "meta": { "timestamp": "ISO 8601 datetime", "requestId": "UUID" } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選 ...