昨天寫到最後，我留下了一個問題：

所謂的「需求沒說清楚」，到底是哪裡沒說清楚？

今天我原本以為，答案可能很簡單。

既然 AI 會猜，那我就把 Prompt 寫詳細一點。

但真的開始拆之後，我發現事情好像沒這麼單純。

Prompt 寫長一點，就夠了嗎？

先從一個很普通的例子開始。

如果我跟 AI 說：

幫我做一個網站。

這當然很模糊。

所以我再補一些資訊：

幫我做一個活動報名網站。

現在至少知道網站要拿來做什麼了。

再詳細一點：

幫我做一個活動報名網站，讓使用者可以查看活動資訊、填寫報名資料，整體介面希望簡單、現代，而且手機也能使用。

這已經很像一個「有認真寫過」的 Prompt。

但如果現在真的把它丟給 AI Coding Agent，問題其實還是一大堆。

例如：

• 這是什麼類型的活動？
• 誰會來報名？
• 一次只有一場活動，還是會有很多場？
• 報名要不要登入？
• 要填哪些資料？
• 有沒有名額限制？
• 額滿之後要怎麼處理？
• 報名成功之後要顯示什麼？
• 需不需要寄確認信？
• 要不要有管理者後台？
• 資料要不要保存？
• 哪些功能第一版一定要有？
• 哪些東西目前可以先不做？

甚至再往下想，還會出現另一類問題：

哪些小細節可以直接交給 AI 決定？

哪些事情如果 AI 自己猜了，反而可能讓整個產品方向跑掉？

這時候我才發現，我缺的好像不只是更多文字。

「需求不清楚」原來不是一個問題

以前聽到「需求沒說清楚」，我的理解很直覺：

可能就是描述得不夠詳細。

所以解決方式也很直覺：

多寫一點。

但今天重新看這個活動報名網站的例子，我開始覺得，「需求不清楚」其實是一個很籠統的說法。

裡面混在一起的，可能是很多不同事情。

我到底想解決什麼問題？

誰會使用？

最重要的事情是什麼？

第一版要做到哪裡？

哪些功能不要現在做？

使用者最後怎樣才算真的完成報名？

還有一些看起來很小、但其實會影響方向的決定。

如果這些事情本來就還沒想過，那就算把 Prompt 寫得很長，也只是用更多句子描述一個還沒有完全決定的產品。

需求清楚，不是把 Prompt 寫得更長，而是把開發前真正需要做的關鍵決定說清楚。

這是我今天最重要的發現。

我原本很自然就開始列功能

想到要做產品時，我第一個反應通常也是功能。

活動報名網站要有：

• 活動介紹
• 報名表單
• 成功頁面
• 後台
• Email 通知
• 名額管理
• 登入
• Dashboard

列功能很有成就感。

因為每多寫一項，就會覺得產品好像更完整了一點。

尤其現在有 AI Coding 之後，這種感覺會更明顯。

以前想到一個新功能，可能還會先考慮：

「這個做起來是不是很麻煩？」

現在比較容易變成：

「這個 AI 應該也做得出來吧？」

然後就加進去了。

可是我列著列著，突然覺得好像跳太快了。

例如「登入」這件事。

為什麼需要登入？

只是因為我習慣很多網站都有登入嗎？

還是這個產品真的有需要辨識使用者？

如果只是一次性的活動報名，也許根本不需要帳號系統。

那 Dashboard 呢？

後台呢？

Email 通知呢？

這些都不是不能做。

只是我以前很容易從：

我想到一個功能。

直接跳到：

那就做。

中間少了一個問題：

它為什麼現在需要存在？

AI 很會填空，但它不知道哪個空格最重要

這也是 Vibe Coding 很有趣的一點。

如果需求裡有空白，AI 通常不會停下來。

它很常會根據常見做法，把空白補起來。

我說「活動報名網站」，它可能自動幫我想出卡片式活動列表。

我說「要可以報名」，它可能幫我設計表單。

我說「現代一點」，它可能自己挑一套常見的版型、圓角、陰影和配色。

很多時候這其實很好用。

因為我不需要每一個 padding、每一個 icon、每一個按鈕位置都自己決定。

問題是，AI 不一定知道：

哪些空白只是實作細節，哪些空白其實是產品決策。

按鈕圓角要 8px 還是 12px，我可能真的不在意。

但「報名需不需要登入」就不是同一個層級的事情。

「成功訊息放在頁面中間還是右上角」，也許可以讓 AI 自己處理。

但「報名資料要不要永久保存」，我就不希望它默默替我做決定。

我現在還不知道這件事最後要怎麼放進 ClarifyBuild。

但我覺得這條線值得留下來：

有些地方可以讓 AI 發揮。

有些地方，應該先停下來問我。

所以「說清楚」可能不是一次寫完

走到這裡，我也開始重新想像 ClarifyBuild 應該長什麼樣子。

如果今天有人只有一句：

我想做一個研究生整理論文的網站。

我不太希望下一個畫面直接出現一張超大的規格表，裡面塞滿各種欄位，要他一次把所有東西填完。

如果是我自己看到，大概也會想直接關掉。

我現在比較能想像的方式，是一步一步來。

先從模糊想法開始。

看到哪裡還沒決定，就處理哪裡。

每次只想幾件事情。

再慢慢把原本的一句話收斂成比較清楚的方向。

至於最後會需要哪些問題、要分成幾步、怎麼問才不會像在填需求工程作業，這些我目前都還沒有答案。

但至少 ClarifyBuild 中間那個原本很模糊的 Clarify，今天開始有一點輪廓了。

今天沒有做功能，但我覺得有往前一步

今天其實完全沒有寫 Code。

甚至連 ClarifyBuild 的畫面都還沒開始設計。

但我反而覺得，這一步不能直接跳過去。

因為如果我現在連「需求沒說清楚」到底代表什麼都還很模糊，就直接開始做一個需求釐清工具，最後很可能只是做出另一個：

輸入短 Prompt → 幫你產生長 Prompt

的工具。

那跟我真正想解決的問題好像不太一樣。

今天至少先釐清了一件事情：

當我說「AI 做出來不是我要的」，問題不一定只是我少寫了幾句描述。

也可能是有些事情，我自己根本還沒有做決定。

Day 3 小結

今天從一個很簡單的問題開始：

需求沒說清楚，到底是哪裡沒說清楚？

我原本以為只是 Prompt 不夠詳細。

但往下拆之後，發現裡面其實藏著很多還沒做出的決定。

要解決什麼？

誰要用？

什麼最重要？

第一版做到哪裡？

怎樣才算完成？

哪些事情可以放心讓 AI 自己處理？

這些問題現在都還沒有要一次回答完。

至少今天，我先看到它們了。

不過這也讓我碰到下一個更直接的問題：

Prompt 跟 Requirement，到底差在哪裡？

下一篇繼續拆這件事。

Day 3 完成。

明天見。