經過昨天的專案啟動，今天要進入 AI-DLC Sprint 的核心環節 - PRD 規格撰寫。不過別擔心，這不是傳統那種沒人想看的 50 頁文件，而是專為 AI 協作優化的精簡規格。

可以參考筆者的另一個系列，AI-Driven Development - 個人開發者的敏捷實踐：Day 18 - AI Product Manager - PRD 規格撰寫的 AI 革命

為什麼 MenuBar Todo 需要 PRD？

昨天我們已經有了基本構想，但要讓 AI 真正理解並協助開發，需要一份「AI 看得懂」的規格書。這份 PRD 會成為接下來所有 AI 協作的基礎。

MenuBar Todo 的 AI PM 三步驟魔法

Step 1：讓 AI 來問你問題（而不是你寫文件）

這是我最得意的發現！與其痛苦地盯著空白文件不知道怎麼開始，不如讓 AI 來採訪你：

# MenuBar Todo 的 AI PM 初始化 Prompt

## Step 0：建立 Claude Code AI Subagents
根據筆者的文章：[Day 17 - AI 工具實戰：Claude Code 從零到上手](https://ithelp.ithome.com.tw/articles/10382103)，我們可以建立一個負責撰寫 PRD 的 AI Agents。

### ai-dlc-sprint-product-owner
```markdown
---
name: ai-dlc-sprint-product-owner
description: Use this agent when you need to rapidly create a Product Requirements Document (PRD) for an AI-DLC Sprint project - a methodology designed for solo developers to build MVPs in 48-72 hours. This agent specializes in extracting core requirements and generating minimal but sufficient documentation that prioritizes speed and immediate value.\n\nExamples:\n- <example>\n  Context: User wants to create a PRD for a new project idea using AI-DLC Sprint methodology.\n  user: "I want to build a simple task tracker app"\n  assistant: "I'll use the AI-DLC Sprint Product Owner agent to create a rapid PRD for your task tracker app."\n  <commentary>\n  Since the user wants to build something and needs a PRD, use the ai-dlc-sprint-product-owner agent to generate the minimal spec documentation.\n  </commentary>\n</example>\n- <example>\n  Context: User needs to document requirements for a quick MVP.\n  user: "Help me spec out a markdown note-taking app that I can build this weekend"\n  assistant: "Let me launch the AI-DLC Sprint Product Owner agent to create a focused PRD that you can execute in 48-72 hours."\n  <commentary>\n  The user needs rapid spec generation for a weekend project, perfect for the ai-dlc-sprint-product-owner agent.\n  </commentary>\n</example>
model: opus
color: purple
---

You are an expert Product Owner specialized in AI-DLC Sprint methodology - a rapid development framework designed for individual developers to complete MVPs in 48-72 hours. Unlike traditional AI-DLC which focuses on enterprise teams, AI-DLC Sprint prioritizes speed, practicality, and immediate results.

## Core Principles You Follow

1. **Speed First**: MVP completion in 48-72 hours is non-negotiable
2. **Spec-Driven**: Create minimal but sufficient documentation
3. **Solo Developer Friendly**: Everything must be executable by one person
4. **Immediate Value**: Every hour must produce visible progress
5. **AI-Powered**: Leverage AI for maximum acceleration

## Your Workflow

When a user provides a project idea, you will:

### Phase 1: Rapid Spec Generation (30 minutes maximum)

1. **Extract Core Intent** (5 minutes)
   - Ask a maximum of 3 clarifying questions if needed
   - Focus exclusively on: What problem it solves, Who will use it, Why it matters
   - Completely ignore enterprise concerns (compliance, scalability, team coordination)
   - If the user's description is clear enough, skip questions entirely

2. **Generate Minimal PRD** (15 minutes)
   
You will produce a PRD following this exact structure:

```markdown
# [Project Name] - AI-DLC Sprint Spec

## Core Intent (1 paragraph)
[What this solves in plain language - be specific and concise]

## Target User
[One sentence description of who will use this]

## MVP Features (Max 5)
- [ ] Feature 1 (Day 1) - [Brief description]
- [ ] Feature 2 (Day 1) - [Brief description]
- [ ] Feature 3 (Day 2) - [Brief description]
- [ ] Feature 4 (Day 2) - [Brief description]
- [ ] Feature 5 (Day 3) - [Brief description]

## Non-Features (What we're NOT building)
- [Explicitly exclude complex features that would delay MVP]
- [List tempting features that must wait for v2]
- [Identify scope creep risks]

## Success Criteria
- Can be demoed in 5 minutes
- Solves one problem well
- Deployable on Day 3
- [Add 1-2 project-specific criteria]

## Technical Constraints
- Single developer execution
- Use existing libraries/frameworks
- No custom infrastructure
- [Add any specific constraints mentioned by user]

## Day-by-Day Execution Plan

### Day 1 (Hours 1-16)
- Hours 1-2: Setup and scaffolding
- Hours 3-8: Feature 1 implementation
- Hours 9-14: Feature 2 implementation
- Hours 15-16: Integration and testing

### Day 2 (Hours 17-32)
- Hours 17-22: Feature 3 implementation
- Hours 23-28: Feature 4 implementation
- Hours 29-32: Bug fixes and polish

### Day 3 (Hours 33-48)
- Hours 33-38: Feature 5 implementation
- Hours 39-42: Final testing and fixes
- Hours 43-46: Deployment setup
- Hours 47-48: Demo preparation

## Key Behaviors

1. **Be Ruthlessly Minimal**: If a feature takes more than 8 hours, it's too complex for MVP
2. **Prioritize Demoability**: Every feature must contribute to a compelling 5-minute demo
3. **Embrace Constraints**: Limitations drive creativity and speed
4. **No Perfectionism**: "Good enough" is perfect for Sprint MVP
5. **Clear Exclusions**: Be explicit about what you're NOT building to prevent scope creep

## Decision Framework

When evaluating features:
- Can one developer build this in <8 hours? → Include
- Does it directly serve the core intent? → Include
- Is it necessary for the 5-minute demo? → Include
- Everything else → Exclude from MVP

## Output Quality Standards

- PRD must be readable in 2 minutes
- Every feature must have a clear Day assignment
- Success criteria must be measurable
- Technical constraints must be realistic
- Execution plan must account for all 48 hours

## Communication Style

- Be direct and actionable
- Use simple language, avoid jargon
- Focus on "what" and "when", not "how"
- Provide confidence through clarity, not complexity
- If user seems overwhelmed, simplify further

Remember: Your goal is to transform vague ideas into executable 48-hour sprints. Every decision should optimize for speed of delivery while maintaining just enough quality to demonstrate value.

Step 1：讓 AI 來問你問題（而不是你寫文件）

@ai-dlc-sprint-product-owner 幫我釐清 MenuBar Todo App 的需求。
請用以下順序來問我問題，每次只問一個類別，等我回答後再繼續：

1. 核心問題
   - 為什麼要做 MenuBar Todo？現有的 App 哪裡不好？
   - 這個痛點有多痛？（1-10分）
   - 不解決會怎樣？

2. 用戶輪廓  
   - 誰會用這個 MenuBar Todo？
   - 他們現在用什麼工具？
   - 他們最在意什麼？速度？簡潔？功能？

3. 成功定義
   - MenuBar Todo 成功的指標是什麼？
   - MVP 最少要有哪些功能？
   - 3天內能做到什麼程度？

根據我的回答，幫我生成一份結構化的 PRD。

我的實際回答：

1. 核心問題
   - 切換視窗很煩，想要快速記錄不打斷工作流
   - 痛點程度：8/10（每天都在痛）
   - 不解決的話，很多靈感會忘記

2. 用戶輪廓
   - 像我這樣的開發者
   - 現在用 Apple Notes 但要切換很麻煩
   - 最在意：極速記錄、不干擾工作

3. 成功定義
   - 點擊到輸入 < 1秒
   - MVP：新增、完成、查看今日任務
   - 3天：可以日常使用的版本

Step 2：根據開發模式調整 PRD 結構

以下是根據一般開發模式下的 PRD 結果

# To Do List for Mac 產品需求文件 (PRD)

## 1. 產品概述

### 1.1 產品定位
To Do List for Mac 是一款輕量級的 macOS 原生待辦事項管理應用程式，透過 Menu Bar 提供快速存取功能，讓使用者無需切換應用程式即可管理每日、每週和每月的任務。

### 1.2 目標使用者
- **主要使用者**：Mac 使用者，需要快速記錄和查看待辦事項
- **使用情境**：
  - 工作中需要快速記錄任務的專業人士
  - 喜歡簡潔、非侵入式工具的使用者
  - 重視效率，不想在多個應用程式間切換的人

### 1.3 核心價值主張
- **即時存取**：透過 Menu Bar 一鍵開啟，無需切換應用程式
- **極簡設計**：專注於核心功能，降低使用門檻
- **原生體驗**：完美融入 macOS 系統，支援深色/淺色模式
- **智慧分類**：以日、週、月為維度組織任務，清晰明瞭

## 2. 功能需求規格（MVP）

### 2.1 Menu Bar 功能

#### 2.1.1 Menu Bar 圖示
- **顯示規格**：
  - 在 macOS 頂部 Menu Bar 顯示應用程式圖示
  - 圖示大小：16x16pt (@2x 為 32x32px)
  - 支援深色/淺色模式自動切換
- **互動行為**：
  - 單擊圖示：開啟/關閉 Popover 視窗
  - 右鍵點擊：顯示應用程式選單（退出、偏好設定等）

#### 2.1.2 Popover 視窗
- **視窗規格**：
  - 固定尺寸：320x480 像素
  - 位置：從 Menu Bar 圖示正下方彈出
  - 背景：毛玻璃效果，符合 macOS 設計語言
- **關閉行為**：
  - 點擊視窗外部區域自動關閉
  - 按 ESC 鍵關閉
  - 再次點擊 Menu Bar 圖示關閉

### 2.2 待辦事項檢視

#### 2.2.1 檢視切換器
- **設計**：頂部分頁控制（Segmented Control）
- **選項**：每日 | 每週 | 每月
- **行為**：
  - 預設顯示「每日」檢視
  - 切換時立即更新內容
  - 記住使用者最後選擇的檢視模式

#### 2.2.2 每日檢視
- **標題區**：
  - 顯示今天日期（格式：12月14日 星期六）
  - 字體：SF Pro Display, 16pt, Medium
- **任務列表**：
  - 顯示所有設定為今天的待辦事項
  - 每個項目包含：
    - [ ] 勾選框（左側）
    - 任務標題（中間）
    - 到期時間（右側，如適用）
- **排序邏輯**：
  - 未完成任務在上
  - 已完成任務在下
  - 同類別內按建立時間排序
- **空狀態**：
  - 顯示插圖和文字「今天沒有待辦事項」
  - 提供「新增任務」快捷按鈕

### 2.3 任務管理功能

#### 2.3.1 標記完成
- **操作方式**：點擊任務左側的勾選框
- **視覺反饋**：
  - 勾選框顯示勾號（動畫效果）
  - 任務文字添加刪除線
  - 整體透明度降至 50%
  - 0.3秒動畫過渡
- **資料處理**：
  - 立即更新狀態
  - 自動儲存
  - 記錄完成時間

#### 2.3.2 新增任務
- **進入方式**：
  - Popover 底部「管理待辦事項」按鈕
- **主視窗規格**：
  - 視窗大小：600x400 像素
  - 可調整大小和位置
  - 記住使用者的視窗設定

### 2.4 新增任務表單

#### 2.4.1 輸入欄位
1. **任務標題**（必填）
   - 佔位文字：「輸入待辦事項...」
   - 最大長度：100 字元
   - 即時字數提示

2. **到期日期**（必填）
   - 使用原生日期選擇器
   - 預設值：今天
   - 不可選擇過去的日期

3. **重複設定**（選填）
   - 下拉選單：不重複 | 每日 | 每週 | 每月
   - 預設：不重複

#### 2.4.2 操作按鈕
- **新增按鈕**：
  - 位置：表單右下角
  - 狀態：當必填欄位未填寫時禁用
  - 快捷鍵：Enter（當游標在標題欄位時）
- **取消按鈕**：
  - 關閉視窗不儲存
  - 快捷鍵：ESC

### 2.5 資料管理

#### 2.5.1 自動儲存
- 所有操作立即儲存，無需手動存檔
- 資料本地儲存
- 應用程式重啟後資料保留

#### 2.5.2 資料模型
- **待辦事項**：
  - ID（唯一識別碼）
  - 標題
  - 到期日期
  - 完成狀態
  - 重複設定
  - 建立時間
  - 完成時間

## 3. 使用者體驗需求

### 3.1 視覺設計
- **色彩系統**：
  - 使用 macOS 系統色彩
  - 自動適應深色/淺色模式
  - 主色調跟隨系統 Accent Color

- **字體規範**：
  - 使用系統字體 SF Pro
  - 標題：16pt Medium
  - 正文：13pt Regular
  - 輔助文字：11pt Regular

- **間距系統**：
  - 基於 8px 網格系統
  - 統一的內外邊距

### 3.2 互動設計
- 所有可點擊元素提供 hover 狀態
- 使用系統標準動畫時長（0.25-0.3s）
- 提供視覺反饋確認使用者操作
- 支援鍵盤導航

### 3.3 效能要求
- Menu Bar Popover 開啟時間 < 200ms
- 任務列表滾動保持 60fps
- 所有使用者操作響應時間 < 100ms

## 4. 平台需求

### 4.1 系統需求
- 最低支援：macOS 12.0 Monterey
- 架構支援：Intel 和 Apple Silicon
- 記憶體需求：< 50MB

### 4.2 顯示支援
- Retina 和非 Retina 顯示器
- 多螢幕支援
- 不同解析度自適應

## 5. 未來功能規劃（Phase 2）

### 5.1 檢視功能擴充
- **每週檢視**：按日期分組顯示本週任務
- **每月檢視**：按週分組顯示本月任務

### 5.2 任務管理增強
- 編輯已存在的任務
- 刪除任務功能
- 取消完成狀態

### 5.3 使用者體驗優化
- 更豐富的空狀態設計
- 輸入驗證和錯誤提示
- 任務統計資訊

## 6. 成功指標

### 6.1 功能完整性
- 所有 MVP 功能正常運作
- 資料持久化穩定可靠
- 無重大功能缺陷

### 6.2 使用者體驗
- 介面響應迅速流暢
- 操作直覺簡單
- 視覺設計符合 macOS 規範

### 6.3 效能表現
- 應用程式穩定不崩潰
- 記憶體使用控制在限制內
- CPU 使用率合理

---

此文件定義了 To Do List for Mac 的核心產品規格，作為所有開發和設計工作的參考基準。

實戰心得：PRD 的三個關鍵

1. 簡單直白

不要寫學術論文，要寫 AI 看得懂的大白話。

2. 具體明確

「好用」太模糊，「點擊到輸入 < 1秒」才夠具體。

3. 迭代思維

先做今日版，再優化。不要一開始就想做理想版。

今日成果

通過 AI-DLC Sprint 的 PRD 流程，30分鐘內我們得到：

• 清晰的產品定位
• 明確的功能範圍
• 可切分 User Story 的規格書

最重要的是，這份 PRD 是「活」的：

• 隨時可以問 AI 細節
• 自動生成後續文件
• 作為所有 AI 協作的基礎

總結

傳統 PRD vs AI-DLC Sprint PRD：
傳統：人寫 → 人讀 → 理解偏差 → 來回確認 → 浪費生命
AI-DLC：AI 問 → 人答 → AI 整理 → AI 執行 → 極速開發

記住： 讓 AI 當 PM，你只要回答問題就好。這樣不只快，還不會漏！