一個「簡單」的會員生日券

那天的需求會議標題是：「會員生日券，需求說明」。

需求方PM 走進會議室，臉上帶著「這個很簡單，應該 30 分鐘搞定」的表情。我跟工程團隊的同事對望一眼，內心同時亮起紅燈：所有講「這個很簡單」的需求，最後都不會很簡單，沒有例外。

需求方PM 開場：「就是會員生日當天，自動發一張優惠券給他。完成。」

工程師問：「請問是發送哪種優惠券？」

需求方PM：「就...一般的折價券吧。」

「一般的折價券有滿千折一百、單品 79 折、生日蛋糕半價，請問是哪一種？」

「呃……我問過行銷後再回你。」

「沒問題，下次會議再討論。」

我看著行事曆，新增了一個會議邀請。心想：簡單的需求，五次會議，這次紀錄又要被刷新了。

五次會議簡史

第一次會議：「就生日當天發券」

問題清單：

• 哪一種券？
• 發送管道是 App 推播、Email、簡訊還是站內信？
• 如果使用者沒裝 App 怎麼辦？
• 券的有效期多久？
• 一張還是多張？
• 當天的幾點要發？

需求方PM 全部回：「我再確認。」

第二次會議：「跨月跨年怎麼算？」

需求方PM 帶著行銷部的答覆回來：「滿千折一百，App 推播 + Email，有效期 7 天。」

我們以為要結束了。工程師突然問：

「請問如果使用者生日是 12/31，券有效期 7 天，那這張券會跨年。跨年的營業額算 12 月還是 1 月？財務認列怎麼處理？」

需求方PM：「呃……」

工程師繼續：「另外，閏年 2/29 出生的使用者，平年要在哪一天發？2/28 還是 3/1？」

我抬頭看了一眼天花板，啊，我晚餐吃什麼好。

第三次會議：「假生日問題」

行銷部回覆完財務認列，需求方PM 興沖沖地回來，覺得這次應該可以收尾了。

工程師：「請問如果使用者改生日，要怎麼處理？」

需求方PM：「啊？使用者會改生日嗎？」

「會。我們去年統計過，每年大概有 0.3% 的會員會改生日，而且時間集中在每個月的 15 號、20 號、25 號這幾天，原因不明，但很有規律。」

需求方PM 沉默了 10 秒：「為什麼我們連這個都有統計……」

「因為以前有人鑽漏洞，把生日改成下個月，領完券再改回來。」

「那、那我們要怎麼防？」

「這就是我們要請教你的。」

會議室陷入沉默。我們又新增了一個會議邀請。

第四次會議：「通知怎麼處理」

需求方PM 帶著「假生日防呆機制」回來。一年只能改一次、改完 30 天內不發券、改回去要扣分。看起來很完美。

工程師：「請問如果 App 推播失敗，要不要 fallback 到 Email？」

「要。」

「如果 Email 也失敗呢？」

「呃……簡訊？」

「簡訊有成本，要不要設預算上限？」

「……我再問行銷。」

「另外，如果使用者把 App 解除安裝、Email 退信、手機號碼換了，但仍然是有效會員，要不要寄實體信？」

需求方PM 把筆放下，深吸一口氣：「我們真的只是要發一張生日券。」

工程師也深吸一口氣：「對，這就是我們在討論的。」

第五次會議：「我們不做這個了」

兩週後，需求方PM 在群組丟了一句：「會員生日券先擱置，主管想換一個方向，改做『新會員首購禮』。」

工程團隊集體沉默。

打開那份還沒寫完的 PRD 草稿，看著上面 47 條 TBD、23 個風險備註、和一張畫了一半的流程圖，按下刪除。

疲勞的想著：問題不在會員生日券。問題在於每次新需求，我們都要從零開始走這條痛苦的路徑。

我發現的事

這五次會議裡，工程師問的問題其實都不難：

• 跨月跨年怎麼算 → 任何做過時間相關功能的工程師都會問
• 閏年 2/29 → 月經題，每個寫排程的人都被坑過
• 假生日漏洞 → 任何處理過個資編輯的人都會想到
• 通知失敗 fallback → 通知系統的基本盤
• 預算上限 → 跟錢有關的功能必問

這些問題全部存在於工程師的集體記憶裡，是一份腦袋裡的隱形 checklist，但從來沒被寫出來、也沒被交給需求方PM 在會議前先想一遍。

如果在需求方PM 走進會議室之前，他已經被某個工具問過這些題目，會議會不會直接從「跨年認列」開始討論，而不是從「請問是發哪種券」？

那一晚我打開筆電，建了一份 Excel。標題：「會員相關功能需求釐清表 v0.1」。

第一個雛形：失敗的 Excel

Excel 的第一個版本長這樣：

• Q1：你想做的功能是？（簡答）
• Q2：使用者是誰？（簡答）
• Q3：成功指標是什麼？（簡答）
• Q4：可能的例外情境？（簡答）
• ...
• Q47：你希望什麼時候上線？（簡答）

我用一個假需求自己填了一次。填到第 8 題就放棄了。
不會就是不會！

問題很明顯：

1. 靜態問卷不會根據前面的回答動態追問。我寫「使用者是會員」，下一題卻是「請列出成功指標」，沒有引導我把「會員」拆解成「哪一種會員」。
2. 沒有選項範例。每一題都是空白簡答框，就是 Day 1 講的「空白頁焦慮」放大版。
3. 不會挑戰矛盾。我隨便寫「目標是降低客服進線」「不做自助查詢功能」，問卷照單全收，不會問我「那客服進線要怎麼降？」
4. 填完沒有產出。它只會把答案存進 Excel，沒有自動長成 PRD。

我關掉 Excel 的頁面，心想：這個東西需要會動態問答、會給選項、會挑戰回答、會自動產出文件。

那是一個 AI 助手該做的事。

為什麼是 Custom GPT

這就要進到一個很實際的問題：公司能用的 AI 工具是什麼？

答案是：ChatGPT 的 Custom GPT，以及一些尚在評估的內部 LLM。沒有 Claude Projects、沒有 LangChain 自架、沒有 RAG pipeline、沒有 fine-tune 預算。

我沒有資源做一個漂亮的開源專案。我只有一個 ChatGPT 企業帳號、連適合AI開發的PRD雛形都沒有。

於是我選了 Custom GPT。它有三個好處：

1. 0 程式碼：Instructions + Knowledge 檔上傳就能跑
2. 內部同事零學習成本：他們已經會用 ChatGPT
3. 快速迭代：改 Knowledge 重新上傳即可，分鐘級

當然它也有缺點，但對「最快驗證一個想法」這件事來說，它是當時最務實的選擇。

用手上有的工具開始，比等到完美的工具到位再開始更重要。GitHub 上有很多更強的 skill 框架、askme 套件、Agent SDK，但如果公司不能用，那它們對你的價值就是零。我預計明天會把這些工具拿出來一個個比，討論在資源受限下怎麼選。

命名：為什麼叫「鼠勾以」

最後講一下命名。

工具的內部代號一直是「需求釐清助手」，字數正確、立意明確、聽起來也很企業。但每次跟同事介紹「這是需求釐清助手」的時候，對方都會露出禮貌的微笑，然後忘掉。

那為什麼對外叫「鼠勾以」？

說真的，沒什麼深意，就是因為我喜歡勞贖，哈哈哈。

然後它還可以諧音日文「すごい」（厲害的意思），台灣人就是要諧音梗，讚啦！

於是內部代號「需求釐清助手」保留下來，對外暱稱就叫鼠勾以。

小結

這篇講的是動機與發想。Day 3 我會把市面上能解類似問題的工具，商業 PRD 模板、共編文件、通用 ChatGPT、GitHub 上熱門的 skill 與 askme 套件，全部攤開來比，看看為什麼在這麼多選項裡，我仍然覺得需要做一個新的。

大目標是為了讓我的使用者最低門檻的上手，不排斥的來使用

這是 iThome 鐵人賽系列文章。明天見。