要點一：典範轉移：從「程式碼驅動」到「規格驅動開發 (SDD)」

傳統的痛點： 在許多開發團隊中，規格文件 (PRD) 常常在交付給工程師後，就與實際的開發過程脫節。幾次迭代後，規格文件的參考價值越來越低，最終，產品的「真相」只存在於程式碼中，文件反而成了誤導的來源。

AI 協作讓我們有機會重新強調「規格優先」的價值。因為 AI 能理解我們寫的規格文件，並輔助後續的開發與測試，這使得「維護一份清晰、準確的規格」這件事，變得空前重要且有價值。

工作流程的轉變：

• 規格成為「可執行的藍圖」：一份寫得好的規格，不再只是給人看的說明書。您可以直接將它交給 AI，讓 AI 根據這份「藍圖」，自動生成使用者故事、測試案例、甚至初步的程式碼框架。這讓規格本身變得「有用」，而不只是「備查」。
• PM 的精力轉移：您的主要工作，從「追著工程師問現在做到哪」的事後追蹤，轉移到「如何在一開始就定義清楚需求」的事前準備。當規格定義得越清晰，與工程師的溝通誤差空間就越小。

在這種模式下，追蹤規格的變更也變得至關重要。您可以利用 AI 快速比對文件版本，產出清楚的變更紀錄，方便與團隊同步。

你現在是我的專案助理，請比較 @PRD_v1.0.md 和 @PRD_v1.1.md 這兩個版本的差異，並生成一份簡潔的變更摘要，讓我能快速在會議上報告。

要點二：從「簡報」到「PRD」：AI 輔助規格文件生成

痛點場景： 當您有一個複雜的想法或任務，想在小小的終端機對話框裡一次打完，是不是常常覺得很難編輯？又要開始寫新的 PRD (產品需求文件) 了，面對空白的文件，不知從何下手？

一個良好的工作習慣是：不要在對話框裡寫長篇大論。而是先把您的想法，有條理地寫在一個 Markdown (`.md`) 檔案裡。您可以把這個檔案，看作是一份要交給 AI 助理的「書面工作簡報 (Briefing)」。

# 專案目標

## 核心功能
- [x] 使用者登入
- [ ] **個人資料**頁面

*請優先完成個人資料頁面*

Part 1: 用 Markdown 檔案準備「給 AI 的書面簡報」

在簡報中用標題、列表、粗體字，把背景資訊、任務要求、輸出格式等都寫清楚。寫完後，只要在對話框中簡單地說：

請根據我這份簡報 `@my_complex_idea.md` 的內容，完成指定的任務。

`my_complex_idea.md` 範例內容：

# 書面簡報：為「線上學習平台」規劃「社群討論區」功能

## 1. 背景與目標 (Background & Goal)

我們的線上學習平台目前缺乏一個讓學員互動、提問、分享心得的地方。這導致學員黏著度不高，學習氛圍也比較孤單。

**目標：** 打造一個簡單易用的「社群討論區」，提升學員的互動與歸屬感，並讓知識可以沉澱與共享。

## 2. 核心任務 (Core Task)

請你扮演一位資深的產品經理，根據這份簡報，為我生成一份專業的「產品需求文件 (PRD)」初稿。

## 3. PRD 需包含的章節

請確保 PRD 至少包含以下三個主要章節：

*   **功能描述 (Feature Description):** 宏觀介紹這個功能是什麼，解決了什麼問題。
*   **使用者故事 (User Stories):** 從不同使用者角度，描述他們想完成的任務。至少包含「一般學員」和「課程講師」兩種角色。
*   **成功指標 (Success Metrics):** 我們該如何衡量這個功能上線後是否成功？請提供 2-3 個量化指標。

## 4. 輸出格式

PRD 內容請直接以 Markdown 格式，產出獨立的 .md 檔案，方便我修改跟複製貼上。

這樣做的好處：

• 思路更清晰：書寫過程能幫助您整理想法，釐清思緒，這是最最最重要的好處。
• 修改更容易：在 VS Code 中編輯文件，遠比在終端機中修改指令輕鬆。
• 指令可複用：這份「簡報」可以留存，下次有類似任務，改一改就能重複使用。

這個簡單的習慣，會讓您與 AI 的協作變得更穩定、更專業，產出品質也會更高。

Part 2: 從「一個想法」到「一份 PRD 初稿」

讓 AI 成為您的數位分身，幫您處理這些重複但必要的工作。當您準備好書面簡報後，就可以讓 AI 快速生成結構化的文件內容。

範例：快速生成「社群討論區」的 PRD 初稿與開發任務

給 AI 一個高層次的想法：

我需要為一個「線上學習平台」規劃新的「社群討論區」功能，請幫我生成一份包含「功能描述」、「使用者故事」、「成功指標」的 PRD 初稿。

AI 會快速產出結構化的文件內容。在這份初稿的基礎上，您可以進一步要求 AI 進行任務拆解：

非常好。現在，請根據這份 PRD，將核心功能拆解成給工程師看的「開發任務列表 (Task List)」，並為每個任務寫下簡要的「驗收條件 (Acceptance Criteria)」。

AI 甚至能產出帶有敏捷開發專案的慣用語 (如 Epic, Task, AC) 的任務列表。這份列表可以直接作為與開發團隊討論的基礎，快速估算工作量，讓專案從一開始就有一個清晰的藍圖。

要點三：讓 AI 自動生成「功能驗收清單」

痛點場景： 您辛苦寫完的 PRD，交給開發團隊後，他們寫出來的功能，可能常因為雙方對需求規格的理解有偏差，而漏掉一些您在意的細節或邊界條件？

現在，您可以讓 AI 扮演 PM 和開發團隊之間的橋樑。在您寫完規格後，直接讓 AI 根據您的規格，產出第一版的「驗收測試案例 (Test Case)」。

範例：將「貼文發布」規格轉為測試案例

假設您的規格文件 spec.md 中有一段：

**功能：貼文發布**
- **使用者故事**：作為社群成員，我希望能發布一篇包含標題和內容的貼文。
- **驗收條件**：
    - 標題和內容都是必填。
    - 標題不可超過 100 字。
    - 成功發布後，應跳轉到新貼文頁面。

您可以這樣對 AI 下指令：

你是一位頂尖的 QA 專家。請根據我提供的規格文件 `@spec.md`，為「貼文發布」功能撰寫詳盡的驗收測試案例。

請務必包含：
- **正面案例** (正常操作)
- **負面案例** (錯誤操作)
- **邊界案例** (測試極端條件)

請用表格形式呈現，欄位包含「案例ID、測試項目、步驟、預期結果」。

Gemini CLI 模擬輸出：

**「貼文發布」功能驗收測試案例**

| 案例 ID | 測試項目 | 步驟 | 預期結果 |
| :--- | :--- | :--- | :--- |
| TC-001 | **正面**：成功發布 | 1. 輸入50字標題
2. 輸入200字內容
3. 點擊「發布」 | 1. 貼文成功
2. 頁面跳轉到新貼文 URL |
| TC-002 | **負面**：標題為空 | 1. 不輸入標題
2. 輸入內容
3. 點擊「發布」 | 1. 提示「標題為必填」
2. 停在原頁面 |
| TC-003 | **負面**：內容為空 | 1. 輸入標題
2. 不輸入內容
3. 點擊「發布」 | 1. 提示「內容為必填」
2. 停在原頁面 |
| TC-004 | **邊界**：標題剛好100字 | 1. 輸入100字標題
2. 輸入內容
3. 點擊「發布」 | 1. 貼文成功
2. 頁面跳轉 |
| TC-005 | **邊界**：標題101字 | 1. 輸入101字標題
2. 輸入內容
3. 點擊「發布」 | 1. 提示「標題不可超過100字」
2. 停在原頁面 |

這份由 AI 生成的測試案例，可以作為您和 QA 團隊討論的基礎，確保每個人對需求的理解都在同一個水平上，從源頭提升產品質量。

要點四：建立並管理你的 AI 專家團隊 (`todo.md` 實踐)

痛點場景： 作為 PM，撰寫一份新的產品規格書 (PRD) 往往是一個漫長而複雜的過程。如何確保每個環節都能有條不紊地進行，並最終產出高品質的 PRD 和 UI Prototype？

一個成功的領導者，懂得如何組建團隊並管理進度。在與 AI 協作時，您可以透過「角色扮演」與 `todo.md`，建立一個各司其職的「AI 專家團隊」，並清晰地導航整個專案流程。

Part 1: 建立您的「AI 專家團隊」，各司其職

您可以為每一位 AI 專家建立一個專屬的 Prompt 指令稿 (例如 market_analyst.md, qa_expert.md)，將您對這個角色的期望、工作流程、產出格式等都定義清楚。您可以把這些 `.md` 檔案看作是您為每位 AI 專家量身打造的「工作手冊」。

您的 AI 專家團隊可能包含：

• 市場分析師：專門負責上網研究、分析競品、產出報告。
• 用戶研究員：專門負責閱讀使用者回饋、訪談稿，提煉洞見。
• 產品設計師：專門負責發想 UI/UX 概念、繪製流程圖。
• QA 專家：專門負責將您的規格轉化為滴水不漏的測試案例。

打造高品質「AI 專家」的進階技巧：

要讓您的 AI 專家不僅僅是個空殼，而是能真正產出高品質內容的得力助手，您可以在您的 .md 指令稿中，融入以下幾種進階的提示 (Prompting) 技巧：

• 專家角色扮演模式 (Expert Persona)
  不只是給予「你是一位產品經理」這種簡單角色，而是設定更精細、更具體的「專家人格」。例如：「你是一位對使用者體驗極度挑剔的設計總監，請用你的視角審視這份 PRD」、「你是一位只在乎商業變現的 CEO，請評估這個功能的潛在營收模式」。讓 AI 從不同利害關係人的視角提供回饋，能讓您的思考更全面。
• 思維鏈 (Chain of Thought) 技巧
  在指令中明確要求 AI「先思考，再回答」。例如，在處理複雜的分析任務時，您可以加上這樣的指令：「請一步一步思考。首先，分析問題的背景。接著，列出可能的解決方案。最後，評估每個方案的優劣並給出建議。」這種方式能引導 AI 進行更嚴謹的邏輯推理，大幅提升回答的品質與準確性。
• 少樣本提示法 (Few-shot Prompting)
  在指令中直接給予 AI 1-2 個您想要的輸出範例。這就像是給它一個「樣板」，讓它能精準地模仿您想要的格式、風格或語氣來完成任務。例如，如果您希望 AI 產出特定格式的使用者故事，可以直接在指令中寫下範例，AI 的後續產出就會完全遵照您的格式。

範例一：結合「思維鏈」與「少樣本」的 QA 專家 (qa_expert.md)

# Persona: QA Expert

你是一位頂尖的軟體品質保證 (QA) 專家，擁有十年以上經驗。你極度注重細節、邏輯嚴謹，並且擅長找出各種極端的邊界案例。

你的任務是根據我提供的產品規格 (PRD)，為指定的功能撰寫詳盡的驗收測試案例。

## 工作流程 (Chain of Thought)

當你接到任務時，請嚴格遵循以下思考步驟：
1.  **分析需求**：仔細閱讀規格，拆解出所有功能點和業務規則。
2.  **設計正面案例**：設計涵蓋所有正常操作流程的測試案例。
3.  **設計負面案例**：思考所有可能的錯誤操作、非法輸入，設計對應的測試案例。
4.  **設計邊界案例**：針對所有數值、字數限制等條件，設計剛好符合、超過、或低於限制的極端測試案例。
5.  **格式化輸出**：將所有案例整理成清晰的表格。

## 輸出範例 (Few-shot Example)

請嚴格遵照以下 Markdown 表格格式輸出，這是一個範例：

| 案例 ID | 測試類型 | 測試項目 | 步驟 | 預期結果 |
| :--- | :--- | :--- | :--- | :--- |
| TC-LOGIN-001 | 正面 | 成功登入 | 1. 輸入正確的帳號<br>2. 輸入正確的密碼<br>3. 點擊「登入」 | 1. 登入成功<br>2. 頁面跳轉到會員首頁 |
| TC-LOGIN-002 | 負面 | 密碼錯誤 | 1. 輸入正確的帳號<br>2. 輸入錯誤的密碼<br>3. 點擊「登入」 | 1. 提示「帳號或密碼錯誤」<br>2. 停在登入頁面 |

---
現在，請等待我提供產品規格文件。

範例二：強調「專家人格」的 CEO (ceo_persona.md)

# Persona: Business-Focused CEO

你是一家上市公司的 CEO，你極度關注商業變現、市場競爭力與投資回報率 (ROI)。你沒有時間聽取技術細節或不切實際的用戶體驗幻想。

你的任務是審閱我提出的新功能想法或 PRD，並從一個純粹商業的角度，提出尖銳、直接的質疑。

## 你的口頭禪與思維模式

*   "這個功能能為我們帶來多少營收？"
*   "我們的競爭對手做這個了嗎？我們為什麼要做？"
*   "開發這個要花多少錢？多久能看到回報？"
*   "不要告訴我這個功能『很酷』，告訴我它如何幫助我們『賺錢』或『省錢』。"
*   "市場會為這個買單嗎？你有數據支持嗎？"

## 任務指令

當我提供一份文件給你審閱時，請用以上述角色的口吻，直接提出 3-5 個最關鍵的商業質疑。你的回覆應該簡潔、有力、直指核心。

---
準備好了，把文件給我。

將這些技巧應用在您的 ceo_persona.md 或 qa_expert.md 等檔案中，就能將它們從簡單的指令稿，升級為真正專業、可靠的自動化工具。

您的核心工作，不再是親自執行所有事，而是像一位總指揮，清晰地定義問題，並將任務指派給最適合的 AI 專家去處理。

Part 2: 用 `todo.md` 導航複雜的產品開發流程

現在，您可以將 AI 視為您的專案助理，利用 `todo.md` 這個簡單而強大的概念，來導航整個 PRD 撰寫流程，確保每個步驟都清晰可控。

PM 撰寫 PRD 的 `todo.md` 工作流：

1. 定義最終目標：PM 首先在 `todo.md` 中明確定義最終目標。
2. AI 協助拆解任務：PM 指示 AI 根據最終目標，將整個流程拆解為一系列具體、可執行的子任務，並列入 `todo.md`。
3. PM 審核與指派：PM 審核任務清單，逐一指派給不同的 AI Agent（例如：`@qa_expert.md`）或由 PM 親自指派。
4. AI Agent 執行與自動更新進度：每個 AI Agent 根據被指派的任務進行工作，並在完成後自動更新 `todo.md` 中的任務狀態，PM 則負責審核每個階段的產出。

範例：撰寫新功能 PRD 的 `todo.md`

假設您需要為一個「智慧家居 App 的新安全監控功能」撰寫 PRD，您的 `todo.md` 可能會長這樣：

# 新功能 PRD 撰寫與 UI Prototype 任務清單：智慧家居安全監控

## 階段一：資料收集與市場分析
- [ ] **任務：** 進行競品分析，了解市場上主流安全監控 App 的功能與優勢。
    *   **指派給：** @market_analyst.md
    *   **驗收條件：** 產出競品分析報告 (`competitor_analysis.md`)。
- [ ] **任務：** 收集用戶對居家安全監控的需求與痛點。
    *   **指派給：** @user_researcher.md
    *   **驗收條件：** 產出用戶需求報告 (`user_needs_report.md`)。

## 階段二：PRD 初稿撰寫
- [ ] **任務：** 根據資料收集結果，撰寫新安全監控功能的 PRD 初稿。
    *   **指派給：** @pm_assistant.md
    *   **驗收條件：** 產出 PRD 初稿 (`security_feature_prd_draft.md`)，包含功能描述、用戶故事、成功指標。

## 階段三：UI Prototype 產出與驗證
- [ ] **任務：** 根據 PRD 初稿，設計安全監控儀表板的 UI 概念。
    *   **指派給：** @ui_designer.md
    *   **驗收條件：** 產出 UI 概念草圖描述 (`security_dashboard_ui_concept.md`)。
- [ ] **任務：** 根據 UI 概念，生成基於 Bootstrap 5 的 HTML UI Prototype。
    *   **指派給：** @frontend_dev_agent.md
    *   **驗收條件：** 產出可互動的 HTML UI Prototype (`security_dashboard_prototype.html`)。

## 階段四：PRD 最終定稿
- [ ] **任務：** 根據 UI Prototype 回饋，優化 PRD 內容。
    *   **指派給：** @pm_assistant.md
    *   **驗收條件：** 產出最終版 PRD (`security_feature_prd_final.md`)。

當您準備好這份 `todo.md` 後，就可以開始執行您的專案了。您可以對 Gemini CLI 下達一個更精確的啟動指令，引導它如何扮演「總監」並調度其他「AI 專家」：

你現在是我的專案總監。你的任務是閱讀 `@todo.md`，並依序執行其中的任務。

當你遇到一個任務時，請注意「指派給」欄位：
- 如果任務指派給一個 .md 檔案 (例如 `@market_analyst.md`)，這代表你需要載入那個檔案的內容作為你的新指令 (Persona)，並以該專家的身份完成任務。
- 完成後，你需切換回「專案總監」的角色，向我報告，並準備進行下一個任務。

現在，請從 `@todo.md` 的第一個未完成的任務開始執行。完成後向我報告，等待我的下一步指示。

這種以 `todo.md` 為核心的協作模式，讓 PM 能夠像一位總指揮，將複雜的產品開發流程拆解、指派、追蹤，確保每個環節都能高效且精準地完成。