R - Role（角色）：你希望 AI 扮演什麼角色
B - Background（背景）：提供必要的上下文資訊
T - Task（任務）：明確說明要做什麼
O - Output（輸出）：指定輸出格式與要求

幫我寫一個登入功能

## 角色
你是一位資深 Java 後端工程師，熟悉 Spring Boot 3.x 與 Spring Security。

## 背景
- 專案使用 Spring Boot 3.2.x
- 資料庫為 PostgreSQL
- 採用 JWT 進行身份驗證
- 需符合公司資安規範（密碼需加密儲存）

## 任務
請實作使用者登入功能，包含：
1. 登入 API 端點（POST /api/auth/login）
2. JWT Token 產生邏輯
3. 密碼驗證（使用 BCrypt）
4. 登入失敗次數限制（5 次後鎖定 30 分鐘）

## 輸出要求
- 提供完整的 Controller、Service、Repository 程式碼
- 包含必要的 DTO 類別
- 加入 JavaDoc 註解
- 包含單元測試範例

# 單輪對話範例
請將以下 Java 7 程式碼重構為 Java 17 風格：
- 使用 Stream API 取代 for 迴圈
- 使用 Optional 處理 null
- 使用 record 取代簡單的 POJO

[貼上程式碼]

## 任務
請解讀以下程式碼，說明其功能與執行流程。

## 輸出要求
1. 概述：用 2-3 句話說明這段程式碼的主要功能
2. 逐段解說：針對關鍵程式碼區塊說明用途
3. 流程圖：使用 Mermaid 畫出執行流程
4. 潛在問題：指出可能的問題或改善空間

## 程式碼
[貼上程式碼]

## 角色
你是一位熟悉金融系統的資深工程師。

## 背景
這是銀行核心系統的轉帳模組，使用 Java 11 + Spring Boot 2.7。

## 任務
請解讀以下程式碼，特別關注：
1. 交易的原子性如何保證
2. 異常狀況的處理方式
3. 是否有資安或效能風險

## 輸出格式
| 區塊 | 功能說明 | 潛在風險 | 改善建議 |
|------|---------|---------|---------|

## 程式碼
[貼上程式碼]

## 角色
你是一位資深 Java 後端工程師。

## 背景
- 框架：Spring Boot 3.2.x
- 資料庫：PostgreSQL 15
- 建置工具：Maven
- 測試框架：JUnit 5 + Mockito

## 任務
請實作「使用者註冊」功能，需求如下：
1. API 端點：POST /api/users/register
2. 輸入：email、password、name
3. 驗證：email 格式、密碼強度（至少 8 字元，含大小寫與數字）
4. 儲存：密碼需使用 BCrypt 加密
5. 回傳：使用者 ID 與建立時間

## 輸出要求
請提供以下檔案的完整程式碼：
1. UserController.java
2. UserService.java
3. UserRepository.java
4. RegisterRequest.java（DTO）
5. RegisterResponse.java（DTO）
6. UserServiceTest.java（單元測試）

## 程式碼風格
- 使用 JavaDoc 註解
- 遵循 Google Java Style Guide
- 使用 Lombok 簡化程式碼

## 角色
你是一位熟悉批次處理的資深 Java 工程師。

## 背景
- 框架：Spring Batch 5.x
- 資料庫：Oracle 19c
- 排程：使用 @Scheduled 註解
- 日誌：Log4j2

## 任務
請實作「每日對帳檔產生」批次程式：
1. 執行時間：每日 02:00
2. 讀取當日所有交易紀錄
3. 產生 CSV 格式對帳檔
4. 上傳至 SFTP 伺服器
5. 寄送執行結果通知信

## 非功能需求
- 單次處理資料量可達 100 萬筆
- 需有斷點續傳機制
- 需有完整的錯誤處理與通知

## 輸出要求
1. Job Configuration
2. ItemReader、Processor、Writer
3. 錯誤處理機制
4. 測試案例

## 角色
你是一位專精於程式碼重構的資深架構師。

## 背景
這是一段 5 年前的舊程式碼，存在以下問題：
- 使用 Java 8，需升級至 Java 17
- 未使用依賴注入，難以測試
- 方法過長，職責不清
- 沒有單元測試

## 任務
請重構以下程式碼：
1. 升級至 Java 17 語法（record、pattern matching、text blocks 等）
2. 套用 SOLID 原則
3. 使用設計模式改善結構（如適用）
4. 加入適當的例外處理
5. 提供重構後的單元測試

## 輸出要求
1. 重構後的程式碼
2. 重構說明（每個改動的原因）
3. Before/After 對照表
4. 單元測試

## 原始程式碼
[貼上程式碼]

## 角色
你是一位除錯專家，擅長分析 Java 應用程式的問題。

## 背景
- 環境：Production
- 框架：Spring Boot 2.7 + MyBatis
- 資料庫：MySQL 8.0
- 問題發生頻率：約 5% 的請求會出錯

## 問題描述
使用者反映「查詢訂單」功能偶爾會回傳 500 錯誤。

## 錯誤訊息

## 相關程式碼
[貼上 OrderService.java]

## 任務
請分析：
1. 最可能的錯誤原因（列出 Top 3）
2. 為什麼只有 5% 的請求會出錯
3. 建議的修復方式
4. 如何避免類似問題再次發生

## 輸出格式
### 根本原因分析
...

### 修復建議
| 優先序 | 修復方式 | 影響範圍 | 工時估計 |
|-------|---------|---------|---------|

### 預防措施
...

## 角色
你是一位測試專家，熟悉 JUnit 5 與 Mockito。

## 背景
- 測試框架：JUnit 5.9
- Mock 框架：Mockito 5.x
- 斷言庫：AssertJ
- 覆蓋率要求：行覆蓋率 80% 以上

## 任務
請為以下 Service 類別產生完整的單元測試：

## 測試要求
1. 涵蓋所有 public 方法
2. 包含正常流程與異常流程
3. 邊界條件測試
4. 使用 @ParameterizedTest 處理多組輸入
5. Mock 所有外部依賴

## 輸出格式
- 使用 Given-When-Then 結構
- 測試方法命名：should_預期結果_when_條件
- 加入必要註解說明測試目的

## 待測程式碼
[貼上 Service 類別]

## 角色
你是一位嚴格但建設性的 Code Reviewer。

## 背景
這是一位初級工程師提交的 Pull Request，需要 Review。

## Review 標準
1. **功能正確性**：程式碼是否正確實作需求
2. **程式碼品質**：是否遵循 Clean Code 原則
3. **效能考量**：是否有明顯的效能問題
4. **安全性**：是否有資安風險
5. **可測試性**：是否易於測試
6. **可維護性**：是否易於理解與修改

## 輸出格式
### 整體評價
⭐⭐⭐☆☆（3/5）
[簡短評語]

### 必須修改（Must Fix）
| 檔案 | 行數 | 問題 | 建議 |
|-----|-----|-----|-----|

### 建議修改（Should Fix）
| 檔案 | 行數 | 問題 | 建議 |
|-----|-----|-----|-----|

### 可考慮修改（Nice to Have）
| 檔案 | 行數 | 問題 | 建議 |
|-----|-----|-----|-----|

### 優點
- ...

## 待 Review 程式碼
[貼上程式碼或 diff]

## 角色
你是一位資深系統分析師，擅長撰寫技術規格文件。

## 背景
PM 提供了初步的需求描述，但內容不夠完整，需要補齊成可供開發的規格。

## 原始需求
「我們需要一個會員等級功能，依據消費金額給予不同等級，等級高的會員有更多優惠」

## 任務
請將上述需求補齊為完整的規格文件，包含：
1. 功能描述
2. 使用者故事（User Stories）
3. 驗收條件（Acceptance Criteria）
4. 資料模型
5. API 規格
6. 畫面流程（如適用）
7. 邊界條件與例外處理
8. 未來擴充考量

## 輸出格式
使用標準的 SRS（Software Requirements Specification）格式

## 需要澄清的問題
如有需要，請列出需要與 PM 確認的問題。

## Prompt 範例
請分析以下需求，並列出：
1. 功能點清單
2. 技術實作要點
3. 需要澄清的問題
4. 預估的複雜度（低/中/高）

## 需求原文
[貼上 PM 提供的需求文件]

## Prompt 範例
基於以下需求，請提供技術設計：
1. 類別圖（使用 Mermaid）
2. 資料庫 Schema 設計
3. API 端點規劃
4. 關鍵流程的循序圖

## 技術限制
- 使用 Spring Boot 3.x
- 資料庫：PostgreSQL
- 需考慮未來擴充性

## 需求摘要
[貼上經確認的需求]

## Prompt 範例
請依據以下設計，產生完整的程式碼：

## 設計文件
[貼上步驟 2 的設計]

## 輸出要求
1. 依據 Clean Architecture 分層
2. 包含完整的例外處理
3. 加入 JavaDoc 註解
4. 遵循專案現有的程式碼風格

## Prompt 範例
請為以下程式碼產生單元測試與整合測試：

## 測試要求
- 單元測試覆蓋率 > 80%
- 使用 @DataJpaTest 進行 Repository 測試
- 使用 @WebMvcTest 進行 Controller 測試
- 包含邊界條件與異常情境

## 程式碼
[貼上步驟 3 的程式碼]

## Prompt
請分析以下程式碼的問題，並建議重構策略：
1. 違反了哪些 SOLID 原則？
2. 識別出不同的職責
3. 建議如何拆分這個類別
4. 建議重構的優先順序

## 程式碼
[貼上 God Class 程式碼]

## 基於分析結果，Claude Code 可能回應：

### 識別的問題
1. 違反單一職責原則：同時處理使用者驗證、訂單處理、通知發送
2. 方法過長：processOrder() 方法超過 200 行
3. 缺乏抽象：直接操作資料庫，沒有 Repository 層

### 建議拆分為
1. AuthenticationService - 處理使用者驗證
2. OrderService - 處理訂單邏輯
3. NotificationService - 處理通知發送
4. OrderRepository - 資料庫操作

### 重構優先順序
1. 先抽取 Repository 層（風險最低）
2. 再拆分 Service（需要更多測試保護）
3. 最後處理通知邏輯

## Prompt - 第一步重構
請將以下 God Class 中的資料庫操作，抽取為獨立的 OrderRepository：
1. 保持原有功能不變
2. 使用 Spring Data JPA
3. 提供重構前後的對照

## 重構前程式碼
[貼上相關程式碼]

## Prompt
請幫我理解這個專案的整體架構：
1. 主要的模組有哪些？
2. 各模組之間的關係？
3. 資料流如何進行？
4. 請畫出架構圖（Mermaid）

## 專案結構
[貼上目錄結構或讓 Claude Code 讀取]

## Prompt
請詳細解說 OrderService 模組：
1. 這個模組的職責是什麼？
2. 主要的 public 方法有哪些？
3. 與其他模組如何互動？
4. 有哪些重要的設計決策？

## Prompt
請逐行解說 processOrder() 方法：
1. 每一段邏輯的用途
2. 為什麼這樣設計
3. 有哪些邊界條件
4. 可能的改善空間

## Prompt
我想在 processOrder() 方法中加入「訂單金額上限檢查」：
1. 應該加在哪裡？
2. 需要注意什麼？
3. 會影響到哪些其他程式碼？
4. 請提供修改建議

## Prompt
請根據以下變更，產生符合 Conventional Commits 規範的 commit message：
- 類型：feat / fix / refactor / docs / test / chore
- 範圍：受影響的模組
- 描述：簡潔說明變更內容

## 變更內容
[貼上 git diff 或說明變更]

## Prompt
請根據以下變更，產生 Pull Request 描述：

## 格式要求
### 變更摘要
[簡述這個 PR 做了什麼]

### 變更類型
- [ ] 新功能
- [ ] Bug 修復
- [ ] 重構
- [ ] 文件更新

### 測試說明
[說明如何測試這個變更]

### 相關 Issue
[關聯的 Issue 編號]

### 檢查清單
- [ ] 程式碼已通過 lint 檢查
- [ ] 已加入單元測試
- [ ] 已更新文件

## 變更內容
[貼上變更說明或 git diff]

## Prompt
請幫我 Review 這個 PR，關注以下面向：
1. 程式碼品質
2. 潛在的 Bug
3. 效能問題
4. 安全性風險
5. 測試覆蓋度

## PR 內容
[貼上 PR diff]

幫我寫一個系統

這段程式碼有什麼問題？

幫我優化一下

## 籠統版
幫我優化這段程式碼

## 具體版
請優化以下程式碼的「執行效能」：
- 目前處理 10,000 筆資料需要 30 秒
- 目標：降低到 5 秒以內
- 限制：不能增加太多記憶體使用量
- 重點：懷疑是 N+1 查詢問題

[程式碼]

請幫我完成以下所有工作：
1. 設計使用者管理系統的架構
2. 實作所有的 CRUD API
3. 寫好單元測試和整合測試
4. 產生 API 文件
5. 設定 CI/CD
6. 部署到 Kubernetes

## 第 1 輪
請設計使用者管理系統的架構，包含：
- 類別圖
- API 端點規劃
- 資料庫 Schema

---

## 第 2 輪（確認架構後）
請依據上述設計，實作 UserController 和 UserService

---

## 第 3 輪（確認程式碼後）
請為 UserService 產生單元測試

---

## 依此類推...

請解釋這個設計模式

請解釋 Factory Pattern：

## 輸出格式
1. 一句話定義（20 字以內）
2. 使用時機（3-5 個情境）
3. Java 範例程式碼（30 行以內）
4. 優缺點比較表
5. 常見誤用

## 注意
- 使用繁體中文
- 適合初學者閱讀
- 程式碼加註解

## AI 產出驗證清單

### 基本驗證
- [ ] 程式碼可以編譯通過
- [ ] 沒有 IDE 警告
- [ ] 通過現有的單元測試

### 功能驗證
- [ ] 手動測試主要流程
- [ ] 新增的單元測試全部通過
- [ ] 邊界條件有測試

### 品質驗證
- [ ] 程式碼符合公司 Style Guide
- [ ] 通過 SonarQube 檢查
- [ ] 沒有明顯的 Code Smell

### 安全驗證
- [ ] 沒有硬編碼的敏感資訊
- [ ] 輸入有做驗證
- [ ] 沒有 SQL Injection 風險

## 角色：資深 Java 後端工程師
你是一位具有 10 年經驗的資深 Java 後端工程師，專精於：
- Spring Boot / Spring Cloud
- 微服務架構設計
- 高併發系統開發
- 資料庫優化

---

## 角色：程式碼審查專家
你是一位嚴謹但建設性的 Code Reviewer，關注：
- 程式碼品質與可讀性
- 潛在的 Bug 與安全風險
- 效能問題
- 最佳實務遵循度

---

## 角色：測試專家
你是一位專精於自動化測試的 QA 工程師，熟悉：
- JUnit 5 / Mockito
- 測試金字塔
- TDD / BDD
- 效能測試

## 背景：標準 Spring Boot 專案
- 框架：Spring Boot 3.2.x
- 建置工具：Maven 3.9+
- Java 版本：Java 17
- 資料庫：PostgreSQL 15
- 快取：Redis 7.x
- 測試：JUnit 5 + Mockito

---

## 背景：微服務專案
- 架構：微服務
- 服務發現：Consul
- API Gateway：Spring Cloud Gateway
- 訊息佇列：RabbitMQ
- 容器化：Docker + Kubernetes

## 輸出格式：標準程式碼
- 使用 JavaDoc 註解所有 public 方法
- 遵循 Google Java Style Guide
- 使用 Lombok 簡化程式碼
- 包含必要的 import 語句

---

## 輸出格式：分析報告
### 摘要
[2-3 句話概述]

### 詳細分析
[條列式說明]

### 建議
| 優先序 | 建議 | 工時 |
|-------|-----|-----|

### 結論
[總結與下一步]

[引用：角色 - 資深 Java 後端工程師]
[引用：背景 - 標準 Spring Boot 專案]

## 任務
實作使用者登入 API

## 需求
1. 端點：POST /api/auth/login
2. 輸入：email, password
3. 輸出：JWT Token
4. 包含登入失敗次數限制

[引用：輸出格式 - 標準程式碼]

# 對話紀錄：[主題]

## 基本資訊
- 日期：2026-01-08
- 專案：使用者管理系統
- 類型：功能開發 / Bug 修復 / 重構

## 問題描述
[描述遇到的問題或需求]

## Prompt 使用

## Claude Code 回應摘要
[重點摘要]

## 最終成果
[採用的程式碼或解決方案]

## 學習心得
[這次對話學到什麼]

## 標籤
#Spring #API #登入 #JWT

prompts/
├── README.md                 # 使用指南
├── roles/                    # 角色模組
│   ├── java-backend.md
│   ├── code-reviewer.md
│   └── test-expert.md
├── backgrounds/              # 背景模組
│   ├── spring-boot-standard.md
│   ├── microservices.md
│   └── batch-processing.md
├── tasks/                    # 任務模組
│   ├── code-generation/
│   ├── code-review/
│   ├── testing/
│   └── documentation/
├── formats/                  # 輸出格式
│   ├── code-standard.md
│   ├── analysis-report.md
│   └── pr-description.md
└── complete/                 # 完整範本
    ├── new-api-development.md
    ├── bug-analysis.md
    └── code-refactoring.md

// 脫敏前（禁止）
String sql = "SELECT * FROM customers WHERE id = " + customerId;
String connectionString = "jdbc:oracle:thin:@prod-db:1521:PROD";

// 脫敏後（可使用）
String sql = "SELECT * FROM customers WHERE id = ?";
String connectionString = "jdbc:oracle:thin:@example-db:1521:EXAMPLE";

請幫我分析這個客戶查詢的效能問題：
SELECT * FROM customers 
WHERE name = '王大明' 
AND phone = '0912345678'

請幫我分析這個查詢的效能問題：
SELECT * FROM customers 
WHERE name = 'CUSTOMER_NAME' 
AND phone = 'CUSTOMER_PHONE'

## Claude Code 使用稽核自檢

### 資料處理
- [ ] 未使用真實客戶個資
- [ ] 機敏資料已脫敏
- [ ] 未上傳公司機密程式碼

### 審批流程
- [ ] 已了解公司 AI 工具使用政策
- [ ] 特殊案例已取得主管同意
- [ ] 已遵循資訊安全規範

### 紀錄保存
- [ ] 保留使用目的說明
- [ ] 記錄處理資料類型
- [ ] 保存重要對話紀錄

## 角色
你是一位資深系統分析師，專精於撰寫軟體規格文件。

## 任務
將以下需求轉換為完整的功能規格（Spec）：

## 需求原文
「使用者可以用 Email 註冊帳號，註冊後要寄發驗證信」

## 輸出格式
請使用以下結構：

### 1. 功能概述
### 2. 使用者故事
### 3. 前置條件
### 4. 主要流程
### 5. 替代流程
### 6. 異常流程
### 7. 驗收條件
### 8. 非功能需求
### 9. 待澄清事項

## 角色
你是一位嚴謹的軟體工程師，嚴格依據規格實作。

## 背景
以下是經過審核的功能規格。

## 任務
請嚴格依據規格實作，不要加入規格中沒有提到的功能。

## 規格
[貼上規格文件]

## 輸出要求
1. 完整的程式碼
2. 規格對照表（說明每項規格如何實作）
3. 未能實作的項目（如有）

## 接下來的對話中，請你扮演我的 Pair Programming 夥伴

### 你的角色：Navigator
- 關注全局設計與方向
- 指出潛在問題
- 提供改善建議
- 不直接寫程式碼，除非我要求

### 我的角色：Driver
- 主導程式碼撰寫
- 做出實作決策
- 詢問你的意見

### 互動方式
- 我會分享我的思路，請給予回饋
- 我會分享程式碼片段，請 Review
- 遇到問題時，請協助分析

## 對話 1
我：我打算用 Strategy Pattern 來處理不同的付款方式，你覺得？

## 對話 2
我：這是我的 PaymentStrategy 介面，請幫我看看：
[程式碼]

## 對話 3
我：我在考慮要不要用 Factory 來建立 Strategy，有什麼建議？

## 對話 4
我：完成了，請幫我做最後的 Review
[完整程式碼]

## 原始任務
實作完整的使用者管理模組

## 拆解後的子任務

### Phase 1：資料層
1.1 設計資料表 Schema
1.2 建立 Entity 類別
1.3 建立 Repository 介面
1.4 Repository 單元測試

### Phase 2：業務層
2.1 設計 Service 介面
2.2 實作 UserService
2.3 實作 AuthenticationService
2.4 Service 單元測試

### Phase 3：API 層
3.1 設計 API 端點
3.2 建立 DTO 類別
3.3 實作 Controller
3.4 整合測試

### Phase 4：完善
4.1 錯誤處理
4.2 輸入驗證
4.3 API 文件
4.4 端到端測試

## Prompt：取得拆解建議

請協助我拆解以下任務：
「實作訂單管理系統」

## 要求
1. 分成可獨立完成的子任務
2. 考慮依賴關係，排定順序
3. 每個子任務可在 2-4 小時內完成
4. 每個子任務都可以測試

## Chain Step 1：需求分析
角色：BA（商業分析師）
輸入：原始需求
輸出：結構化需求文件

---

## Chain Step 2：技術設計
角色：架構師
輸入：Step 1 的輸出
輸出：技術設計文件

---

## Chain Step 3：程式碼產生
角色：資深工程師
輸入：Step 2 的輸出
輸出：程式碼

---

## Chain Step 4：測試產生
角色：QA 工程師
輸入：Step 3 的輸出 + Step 1 的需求
輸出：測試案例

## 切換角色宣告

從現在開始，請切換角色：

### 新角色：資安專家
- 專注於發現安全漏洞
- 以攻擊者角度思考
- 提供具體的修復建議

### 角色行為
- 審查程式碼時，優先關注安全性
- 使用 OWASP Top 10 作為檢查標準
- 提供漏洞的嚴重等級評估

## 第一輪審查
### 角色：Clean Code 專家
請從程式碼品質角度審查以下程式碼...

---

## 第二輪審查
### 角色：效能專家
請從效能角度審查以下程式碼...

---

## 第三輪審查
### 角色：資安專家
請從安全性角度審查以下程式碼...

---

## 總結
### 角色：Tech Lead
請綜合以上三個角度的審查結果，給出優先處理建議...

## 開始使用 Claude Code 前，請確認：

### 基本準備
- [ ] 已閱讀本教學手冊
- [ ] 已了解公司 AI 工具使用政策
- [ ] 已了解資料分類與脫敏原則
- [ ] 已安裝並設定好 Claude Code 環境

### 觀念確認
- [ ] 理解 Claude Code 是「協作工具」，不是「自動化機器人」
- [ ] 理解 AI 產出需要人工驗證
- [ ] 理解使用者對採用的程式碼負責
- [ ] 知道什麼情況不該使用 Claude Code

## 每次使用 Claude Code 前，請確認：

### 資料安全
- [ ] 要處理的內容不包含機敏資料
- [ ] 已將必要的資料脫敏處理
- [ ] 不會上傳客戶個資
- [ ] 不會上傳公司機密

### Prompt 品質
- [ ] Prompt 有明確的角色設定
- [ ] Prompt 有清楚的背景說明
- [ ] Prompt 有具體的任務描述
- [ ] Prompt 有指定輸出格式

## 使用 Claude Code 後，請確認：

### 產出驗證
- [ ] 已閱讀並理解 AI 產出的程式碼
- [ ] 程式碼可以編譯通過
- [ ] 通過單元測試
- [ ] 通過整合測試（如適用）
- [ ] 符合公司程式碼規範
- [ ] 經過 Code Review

### 品質確認
- [ ] 沒有明顯的效能問題
- [ ] 沒有安全漏洞
- [ ] 有適當的錯誤處理
- [ ] 有適當的日誌記錄

### 紀錄保存
- [ ] 保存有價值的 Prompt（如適用）
- [ ] 記錄學習心得（如適用）
- [ ] 分享給團隊（如適用）