昨天規劃了智慧記帳 Web App 的願景，今天正式進入 AI-DLC Sprint 的第一天。與 MenuBar Todo 不同，這次筆者要從零開始，讓你看到一個想法如何在 AI 的協助下變成清晰的需求文檔。

Repository 命名哲學

選名字看似小事，實則重要。好的專案名稱要：

• 簡潔易記
• 表達核心價值
• 避免通用詞彙（SEO 考量）
• 重點是要自己喜歡～

與 AI 的命名對話

我：我要做一個智慧記帳 Web App，主要特色是：

1. 極簡的記帳體驗（3秒記帳）
2. AI 自動分類
3. 支援 Telegram 等擴充
4. 訂閱管理功能
   幫我想 5 個 repository 名稱

AI：基於你的核心特色，我建議：

1. pocketsmart - 暗示口袋（錢包）+ 智慧

   • 簡短好記
   • .com 域名可能可用

2. expenny - expense + penny（支出+便士）

   • 俏皮有趣
   • 暗示小額記帳

3. subtrack - subscription + track

   • 強調訂閱追蹤
   • 發音順暢

4. aikeeper - AI + bookkeeper

   • 直接表達 AI 特色
   • keeper 有保管者的意涵

5. quickledger - quick + ledger

   • 強調快速
   • ledger 是專業記帳術語

我推薦 pocketsmart，因為：

• 不限定在 expense（未來可擴充收入）
• smart 暗示 AI 能力
• 名稱親切不嚴肅

決定：pocketsmart

需求分析：讓 AI 當我的產品經理

建立一個產品經理的 Subagent

你是一位資深產品經理，請針對「PocketSmart - 智慧記帳 Web App」進行需求分析。

## 背景資訊
- 目標用戶：懶得記帳但想理財的年輕人（22-35歲）
- 核心痛點：傳統記帳 App 操作繁環，導致半途而廢
- 競品問題：功能太多、分類太細、操作步驟太多

## 產品定位
一句話描述：最適合懶人的智慧記帳工具
核心價值：用 AI 降低記帳摩擦力

## 功能範圍
1. 快速記帳（自然語言輸入）
2. 訂閱管理（固定支出）
3. 智慧分析（AI 洞察）
4. 擴充能力（Telegram、MCP）

請從以下角度進行需求分析：
1. 用戶場景分析
2. 功能優先級
3. 技術可行性
4. MVP 範圍定義
5. 成功指標

開發模式選擇：DDD + BDD 混合策略

基於 PocketSmart 的特性，我選擇 DDD（領域驅動設計）+ BDD（行為驅動開發） 的混合模式。

為什麼是 DDD？

記帳應用的核心是業務邏輯，不是技術實現：

• 訂閱週期計算
• 支出分類規則
• 預算邏輯
• 報表聚合

這些都是領域知識，適合用 DDD 來建模。

為什麼加入 BDD？

記帳最重要的是用戶行為：

• 「當我輸入『星巴克 120』，應該自動分類為餐飲」
• 「當月支出超過預算，應該收到提醒」
• 「當訂閱到期，應該自動更新下次扣款日」

BDD 讓我們從用戶視角定義系統行為。

與 AI 的開發模式討論

我：PocketSmart 這個記帳應用，你建議用什麼開發模式？
TDD、DDD、BDD、SDD？請分析各自優缺點。

AI：基於 PocketSmart 的特性，我建議 DDD + BDD 混合模式：

## 各模式分析

### TDD（測試驅動開發）
✅ 優點：程式碼品質高、測試覆蓋完整
❌ 缺點：對記帳這種業務邏輯重的應用，過於關注技術細節

### DDD（領域驅動設計）
✅ 優點：
- 完美契合記帳的業務複雜性
- 訂閱、支出、預算都是清晰的領域概念
- 易於擴展（未來加入收入、投資等）
❌ 缺點：初期設計成本較高

### BDD（行為驅動開發）
✅ 優點：
- 從用戶角度定義功能
- Given-When-Then 非常適合記帳場景
- 需求可直接轉成測試
❌ 缺點：需要完整的行為定義

### SDD（規格驅動開發）
✅ 優點：文檔完整、AI 友好
❌ 缺點：對快速迭代的 MVP 過重

## 推薦：DDD + BDD

1. 用 DDD 建立領域模型
2. 用 BDD 定義用戶行為
3. 結果：業務邏輯清晰 + 用戶體驗優秀

結論

今天用了 AI 幫忙選出專案名稱、初步的需求規劃以及適合的開發模式，接下來我們會開始跑 AI-DLC Sprint 一步一步的將這個應用建立起來，敬請期待～