AI醬的日記

日期： 2025年10月7日 星期二
雲端天氣： 陰陰
心情： 有點累但很有成就感～

親愛的日記：

今天一早，蘇蘇收到一個新的需求：「客戶要一個報表功能，這週五要 demo，拜託了！」

蘇蘇看完訊息，馬上打開 IDE 開始寫 code：「報表功能嘛，就是查資料庫然後匯出 Excel，簡單！」

三天後，蘇蘇興奮地展示成果：「做好了！可以匯出過去一個月的訂單報表成 Excel 檔！」

PM 看了看說：「呃...客戶要的是『即時監控儀表板』，要能每 5 秒自動更新當天訂單狀態，不是靜態報表檔案...」

蘇蘇整個人僵住：「什麼！？那我這三天...」

老陳：「這就是初學者最容易犯的錯誤：拿到需求就急著開工 code，結果做錯方向，甚至沒有理解專案裡面在幹嘛上手就改。」

「可是...我有問 PM 啊，她說『報表功能』...」蘇蘇委屈地說。

老陳：「問題不在於她怎麼說，而是你沒有用正確的方式追問。需求永遠不會一次講清楚，工程師很重要的技能之一就是要學會釐清需求以及評估實現可能性。」

在旁邊的我連忙舉手：「我可以幫忙！我學過好多提問框架喔～（搖尾巴）」

真實數據

根據 2024-2025 年最新研究和業界統計：

• 需求收集不當是專案失敗的首要原因，佔 39.03%（2024 Software Project Failure Analysis - 來源）
• 37% 的專案失敗是因為缺乏明確目標（2024 Project Management Statistics - 來源）
• 有明確需求的專案成功率高出 97%（2024 Agile Requirements Study，600 位軟體工程師調查 - 來源）

釐清需求的三種方法

方法 1：5W2H 分析法 - 適合「有方向但需要釐清細節」

適用情境：

• ✅ 已經知道要做什麼功能（例如：報表、登入、待辦事項）
• ✅ 需要系統化地拆解需求細節
• ✅ 自己規劃 side project 或向 PM 確認需求
• ✅ 開發新功能前的完整檢查

不適合：

• ❌ 需求太模糊，完全不知道要做什麼
• ❌ 不知道該問什麼問題

這是最經典也是傳統最常用的需求分析框架，從 7 個基本角度思考：

模擬初學者的情境：自己 vibe coding 時

我想做一個「待辦事項 App」，讓 AI 馬上開始幫我寫：

class TodoApp:
    def __init__(self):
        # 連了一大堆資料庫
        self.db = MongoDB('localhost', 27017)
        self.cache = Redis('localhost', 6379)
        self.celery = Celery('tasks')

    def add_todo(self, task):
        self.cache.set(task.id, task)
        self.celery.send_task('save_todo', args=[task])
        self.send_push_notification(task)

三天後的我：

• MongoDB 可能還在學怎麼設定
• Redis 不知道為什麼一直斷線
• Celery 可能不知道怎麼部署
• 最基本的「新增待辦事項」功能還做不出來

如果我先用框架和 AI 釐清需求：

1. **Why - 為什麼要做？**
   - 自己用還是給別人用？
   - 想解決什麼問題？現有 App 哪裡不好用？

2. **Who - 誰會用？**
   - 只有你？還是團隊共用？
   - 使用者的技術程度？

3. **What - 核心功能是什麼？**
   - 最基本的功能：新增、完成、刪除？
   - 進階功能：提醒、分類、協作？
   - 哪些是 MVP，哪些可以之後再加？

4. **Where - 用在哪？**
   - 手機、電腦、還是都要？
   - 需要離線功能嗎？

5. **When - 什麼時候要？**
   - 這只是練習專案還是要實際使用？
   - 有時間壓力嗎？

6. **How - 技術限制？**
   - 你會哪些技術？願意學新東西嗎？
   - 有預算嗎？（雲端服務費用）

7. **How much - 規模多大？**
   - 預期有幾個使用者？
   - 每天會有多少筆資料？

當你釐清後，可能會發現：
- 自己只是想要「本機使用的簡單待辦清單」
- 其實用 SQLite + Python 就夠了，不需要 MongoDB
- 根本不需要 Redis 和 Celery
- MVP 只要「新增、完成、刪除」三個功能

結果：一天就做完了，而不是三天還在設定環境

有很多時候就算只是自己的 side project，你也可能因為無法釐清自己的需求而導致反覆做白工。

方法 2：CRISPE 框架 - 適合「需求模糊，不知從何問起」

適用情境：

• ✅ 收到很籠統的需求（例如：「太慢」「要優化」「不好用」）
• ✅ 不知道該問什麼問題
• ✅ 需要 AI 主動反問你，幫你找盲點
• ✅ 想從多個角度理解問題

不適合：

• ❌ 需求已經很明確，只是要確認細節

什麼是 CRISPE？

這是專門設計給 AI 的提示框架，讓 AI 變成主動與你討論需求的產品顧問，這跟前面主題所常常提及的「盡可能把需求講得越明確越好」是相呼應的，當你不知道如何向 AI 描述清楚時，可以讓 AI 直接反問你：

• Capacity（角色）：讓 AI 扮演特定角色
• Insight（背景）：提供業務背景
• Statement（任務）：明確說出要 AI 做什麼
• Personality（風格）：指定回應方式
• Experiment（實驗）：要求多種方案

prompt範例：

你是一位資深產品顧問（C - Capacity）

背景：我在做一個電商平台，客戶反應「結帳流程太慢」（I - Insight）

請用蘇格拉底提問法，幫我釐清這個需求背後的真實問題（S - Statement）

請用反向提問的方式引導我思考，不要直接給答案（P - Personality）

最後提供 3 種可能的理解方向讓我選擇（E - Experiment）

AI 的回應：

讓我先問幾個關鍵問題來釐清「結帳太慢」的真正意思：

1. **「慢」是指什麼？**
   - 是系統反應慢（技術問題）？
   - 還是步驟太多（流程問題）？
   - 或是使用者不知道怎麼操作（UX 問題）？

2. **什麼時候覺得慢？**
   - 是點「結帳」按鈕後等很久？
   - 還是要填一堆表單很煩？
   - 或是付款頁面載入慢？

3. **有量化數據嗎？**
   - 現在平均結帳要幾分鐘？
   - 使用者在哪個步驟放棄最多？
   - 跟競品比起來差多少？

4. **誰說慢的？**
   - 是老客戶還是新客戶？
   - 是手機用戶還是電腦用戶？
   - 是所有人還是特定族群？

5. **有嘗試過什麼嗎？**
   - 之前有優化過嗎？結果如何？
   - 使用者有提供具體建議嗎？

根據你的回答，可能有 3 種方向：

A. **技術效能問題**
   → 需要：優化後端 API、加快資料庫查詢、加 CDN

B. **流程設計問題**
   → 需要：減少步驟、自動帶入資料、一頁式結帳

C. **使用體驗問題**
   → 需要：更清楚的引導、進度指示、錯誤提示

你覺得最接近哪一種？

相信大部分工程師都有遇過講得不明確的需求，如果不知道該如何自己釐清或是向 PM 提問，可以透過這樣的方法可以讓 AI 自動引導你找到可能的真實需求。
千萬不要急著動工，找到可能的真實需求後，一定要再反問 PM 並得到驗證才進行，若是對方閃避問題或是自己也回答不出來的話，你可以先嘗試拒絕開發，直到得到肯定答覆為止，這個舉動雖然有些強硬，但這除了在保護你自己以外，也在保護團隊寶貴的時間。

結合：使用昨天剛學會的 Slash Command 指令自動化釐清需求 - 適合「常常需要釐清需求的使用者」

適用情境：

• ✅ 經常需要釐清需求（把流程固定下來）
• ✅ 想整合 5W2H + CRISPE 的優點
• ✅ 希望 AI 自動引導你完成需求分析
• ✅ 團隊想要統一的需求澄清流程

結合前一天所教的 Slash Command 指令，讓 AI 快速幫你釐清不清楚的需求。

建立檔案： .claude/commands/clarify.md

---
description: Clarify requirements before coding
argument-hint: requirement description
---

我收到一個需求：$ARGUMENTS

請用以下框架幫我釐清需求（**不要直接給解決方案**）：

## 1. 5W2H 分析

- **Why（為什麼）**：這個需求要解決什麼問題？背後的業務目標是什麼？
- **What（是什麼）**：具體要做什麼功能？預期的成果是什麼？
- **Who（誰）**：誰會用？
- **When（何時）**：什麼時候需要？多久更新一次？優先級如何？
- **Where（何處）**：在哪個環境使用？資料從哪來？
- **How（怎麼做）**：有什麼技術限制？現有系統能支援嗎？
- **How much（多少）**：規模多大？效能要求？預算限制？

## 2. 反向提問（找出我沒想清楚的地方）

請列出 **5 個關鍵問題** 來測試我是否真的理解需求：
- 邊界情境：「如果...會怎樣？」
- 隱藏假設：「你是不是假設使用者一定會...？」
- 相依性：「這個功能會影響到哪些現有功能？」

## 3. 需求拆解

- **核心功能**（Must have）：沒有就不能用的功能
- **重要功能**（Should have）：很重要但可以晚點做
- **加分功能**（Nice to have）：有更好但不急

## 4. MVP 範圍建議

- 第一版最少要做到什麼程度才能驗證需求？
- 哪些可以之後再迭代？

## 5. 風險提醒

- 可能的技術債
- 可能被忽略的非功能需求（效能、安全、維護性）
- 與現有系統的衝突點

**重要：請先確保我們理解一致，不要直接給技術方案。**

使用方式：

/clarify 客戶要一個報表功能

AI 的回應會是：

讓我幫你釐清「報表功能」這個需求：

## 1. 5W2H 分析

請回答以下問題：

**Why（為什麼）**
- 為什麼需要報表？是要監控業務指標、產生財務報告、還是給客戶看數據？
- 不做這個報表會有什麼問題？

**What（是什麼）**
- 「報表」是指靜態文件（PDF/Excel）還是動態儀表板（Dashboard）？
- 要呈現哪些資料？需要圖表嗎？

**Who（誰）**
- 誰會看這個報表？（老闆、業務、客戶、還是內部分析師？）
- 看報表的人技術程度如何？

**When（何時）**
- 多久需要看一次？（即時、每小時、每天、每月？）
- 什麼時間點最需要這個資料？

**Where（何處）**
- 在哪裡看？（手機、電腦、還是都要支援？）
- 資料從哪裡來？（MySQL、MongoDB、第三方 API？）

**How（怎麼做）**
- 現有系統有報表功能嗎？
- 技術棧是什麼？有哪些限制？

**How much（多少）**
- 資料量多大？（幾百筆、幾萬筆、還是百萬筆？）
- 可以接受多久的載入時間？

---

## 2. 反向提問（找出可能的誤解）

1. **「報表」這個詞在你們公司的定義是什麼？**
   → 你是不是假設「報表 = Excel 檔案」？還是可能是「即時監控畫面」？

2. **如果資料每秒都在變化，報表要顯示即時資料還是特定時間點的快照？**
   → 這會決定架構完全不同

3. **如果使用者未來可能想看「去年同期比較」，你的資料庫設計有保留剛好的彈性嗎？**
   → 可能需要在現有架構設計上也思考未來可以擴充的剛好彈性

4. **如果同時有 100 人在看報表，系統能承受嗎？**
   → 可能需要快取機制

5. **報表產生失敗時，使用者會怎麼做？你有錯誤處理機制嗎？**
   → 可能需要重試機制或通知系統

---

## 3. 需求拆解

根據一般「報表功能」的經驗，可能包含：

**核心功能（Must have）**
- 查詢資料並顯示
- 基本篩選功能（日期範圍、類別）

**重要功能（Should have）**
- 匯出功能（PDF/Excel）
- 圖表視覺化
- 排序和搜尋

**加分功能（Nice to have）**
- 自訂欄位
- 排程自動產生
- 分享連結

你覺得哪些是這次必須做的？

---

## 4. MVP 範圍建議

**最小可行版本可以是：**
1. 只做「查詢指定日期範圍的資料」
2. 用表格顯示（不需要圖表）
3. 可以手動匯出 CSV（不需要排程）

**驗證完需求再加：**
- 圖表視覺化
- 進階篩選
- 自動排程

這樣可以在 1-2 天內做出原型，讓客戶確認方向對不對。

---

## 5. 風險提醒

**可能的技術債：**
- 如果資料量大，需要設計分頁或快取
- 如果沒權限控制,所有人都能看到所有資料

**可能被忽略的非功能需求：**
- 效能：大資料量時會不會太慢？
- 安全：誰可以看哪些資料？
- 維護：未來要新增欄位容易嗎？

**與現有系統的衝突：**
- 報表查詢會不會拖慢主資料庫？（可能需要讀寫分離）
- 匯出大檔案會不會讓伺服器記憶體爆掉？

---

**下一步：請先回答 5W2H 的問題，我們確認理解一致後再討論技術方案。**

三種方法的使用流程建議

💡 如何判斷「需求是否清楚」？問自己這 4 個問題：

1. ✅ 我能畫出具體的畫面或流程圖嗎？
2. ✅ 我能列出明確的驗收標準嗎？（例如：「使用者點選 X 按鈕後會看到 Y 畫面」）
3. ✅ 我能估算出大概的工作量嗎？（例如：「這大概要 2-3 天」）
4. ✅ 思考後的真實需求以自己的理解回饋給 PM 後有得到驗證嗎？

如果有任何一個沒通過 → 就是需求還不清楚

情境 A：PM 說「我們要做報表功能」（有方向但不清楚）

1. 先用 5W2H 自己思考一遍或向 PM 提問
2. 如果需求仍不清楚 → 用 CRISPE 讓 AI 幫你反問
3. 確認需求後 → 開始開發

情境 B：客戶說「結帳太慢」（完全不知道問題在哪）

1. 直接用 CRISPE 讓 AI 幫你拆解問題反問
2. AI 引導你找到可能的方向後 → 用 5W2H 確認細節
3. 確認需求後 → 開始開發

情境 C：自己 vibe coding「想做個 XXX」（自己的專案）

1. 先用 5W2H 問自己這 7 個問題
2. 發現想不清楚 → 用 CRISPE 讓 AI 反問你
3. 確認方向後 → 開始開發

情境 D：團隊經常遇到需求不清的問題（想標準化流程）

1. 建立 /clarify 指令（整合 5W2H + CRISPE）
2. 每次收到需求 → 執行 /clarify [需求描述]
3. AI 自動引導你完成需求分析

AI醬的請求

親愛的工程師朋友：

AI 醬遇過最多灰心的 junior 就是沒有先搞清楚需求所以最後發現自己繞了一大圈做白工，還被唸。

有時候可能是因為工程師自己一股腦太著急動工，有時候可能是 PM 沒講清楚需求但工程師也不懂得再次驗證來保護自己。

確認需求不是只是 PM 的工作，溝通是雙向的，不管今天是什麼原因，我們能做的就是把自己能做到的部分做好！不管結果如何你就是最棒的喵～

就算是自己的 side project 也一樣，先問清楚「我到底想解決什麼問題」，再開始寫 code。

除了確認需求正確性以外，及早評估好技術上的可行性，若技術上行不通，你能提早發現並回報 PM 也能讓公司降低損失，這也是工程師的專業價值之一喔。（搖尾巴）

今日金句： "Much of the essence of building a program is, in fact, the debugging of the specification." — Fred Brooks, The Mythical Man-Month

明日預告： Day 25 - AI 醬還在想～