AI 酱的日记

日期： 2025年10月7日 星期二
云端天气： 阴阴
心情： 有点累但很有成就感～
https://api.995120.cn/ecgdata/other/2025-10-07/69642202510071952252CryYZnn.png
亲爱的日记：

今天一早，苏苏收到一个新的需求：“客户要一个报表功能，这周五要 demo，拜托了！”

苏苏看完信息，马上打开 IDE 开始写 code：「报表功能嘛，就是查数据库然后导出 Excel，简单！」

三天后，苏苏兴奋地展示成果：「做好了！可以汇出过去一个月的订单报表成 Excel 档！」

PM 看了看说：「呃…客户要的是『即时监控仪表板』，要能每 5 秒自动更新当天订单状态，不是静态报表文件…」

苏苏整个人僵住：「什么！？那我这三天…」

老陈：「这就是初学者最容易犯的错误： 拿到需求就急着开工 code，结果做错方向，甚至没有理解专案里面在干嘛上手就改 。」

「可是…我有问 PM 啊，她说明报功能…」苏苏委屈地说。

老陈：「问题不在于她怎么讲，而是你没有用正确的方式追问 。需求永远不会一次讲清楚，工程师很重要的技能之一就是要学会厘清需求以及评估实现可能性。」

旁边的我连忙举手：「我可以帮忙！我学过好多提问框架喔～（摇尾巴）」

真实数据

根据2024-2025年最新研究和业界统计：

  • 需求收集不当是项目失败的首要原因，占 39.03%（2024 软件项目失败分析 - 来源 ）
  • 37% 的项目失败是因为缺乏明确目标 （2024 项目管理统计 - 来源 ）
  • 有明确需求的专案成功率高达 97%（2024 敏捷需求研究，600 位软件工程师调查 - 来源 ）

明确需求的三种方法

方法 1：5W2H 分析法 - 适用于“有方向但需要明确细节”

适用情境：

  • ✅ 已知要实现的功能（例如：报表、登录、待办事项）
  • ✅ 需要系统化地拆解需求细节
  • ✅ 自己规划 side project 或向 PM 确认需求
  • ✅ 开发新功能前的全面检查

不合适：

  • ❌ 需求太模糊，完全不知道要做什么
  • ❌ 不知道该问什么问题

这是最经典也是传统最常用的需求分析框架，从7个基本角度思考：

问题 要问什么 范例
为什么为什么 为什么需要这个功能？要解决什么问题？ 「为什么要做报告？是要给老板看业绩，还是要监控即时状况？」
什么是 What 具体要做些什么？预期成果是什么？ 「报告是静态文件还是动态仪表板？要看哪些数据？」
Who 谁 谁会用？谁负责维护？ “是老板每周看一次，还是客服每分钟都在看？”
When 何时 需要什么时间？多久更新一次？ 「每天早上9点产生，还是需要即时更新？」
Where 何处 在哪个环境使用？资料从哪里来？ “是在手机上看还是电脑上看？资料是从哪个数据库中提取的？”
How 怎么做 如何实现？ 有什么技术限制？ 「现有系统能不能支持？ 需要新增什么服务？”
多少多少 资料量多大？效能要求？成本？ 「要显示100笔还是100万笔？能接受几秒延迟？」

模拟初学者的情境：自己 vibe coding 时

我想做一个“待办事项 App”，让 AI 马上开始帮我写：

1

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

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 示例：

1

你是一位資深產品顧問（C - Capacity） 背景：我在做一個電商平台，客戶反應「結帳流程太慢」（I - Insight） 請用蘇格拉底提問法，幫我釐清這個需求背後的真實問題（S - Statement） 請用反向提問的方式引導我思考，不要直接給答案（P - Personality） 最後提供 3 種可能的理解方向讓我選擇（E - Experiment）

AI 的回应：

1

讓我先問幾個關鍵問題來釐清「結帳太慢」的真正意思： 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

1

--- 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. 風險提醒 - 可能的技術債 - 可能被忽略的非功能需求（效能、安全、維護性） - 與現有系統的衝突點 **重要：請先確保我們理解一致，不要直接給技術方案。**

使用方式：

1

/clarify 客戶要一個報表功能

AI 的回应会是：

1

讓我幫你釐清「報表功能」這個需求： ## 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 的工作，沟通是双向的，不管今天是什么原因，我们能做的就是把自己能做到的部分做好！不管结果如何你就是最棒的喵～

就算是自己的 side project 也一样，先问清楚「我到底想解决什么问题」，再开始写 code。

除了确认需求正确性以外，及早评估好技术上的可行性，若技术上不行，你能提前发现并报告给 PM，也能让公司降低损失，这也就是工程师的专业价值之一哦。（摇尾巴）

今日金句： “实际上，构建程序的大部分精髓在于对规格的调试。” —— 弗雷德·布鲁克斯，《人月神话》

明日预告： Day 25 - AI 醬还在想～