前言

今天開始我們差不多要來準備動工了，畢竟前面已經把 AI 相關觀念以及 Claude Code 的一些操作小細節都搞清楚了，那當然就是準備介入實作階段啦～

但！雖然是準備進入實作階段，只是我們目前還是一行程式都不會寫，因為 Vibe Coding 的第一步並不是叫 AI 寫程式，而是先學會把需求講清楚。

透過把 「需求」 講清楚這件事情，我們可以把腦中模糊的想法，轉化成一份具體的規格文件 SPEC.md，可是該怎麼把需求講清楚卻又是另外一回事了，所以這一篇將會介紹一些技巧方式，讓你可以盡可能把腦中模糊的想法逼成一份具體的規格文件 SPEC.md，AI 才不會自己腦補，最後做出一個方向不明的成品。

AI 會放大你的模糊

首先，我認為你必須要先認知道一件事情：

儘管 AI 非常方便，但如果沒有把需求講清楚，隨著模型差異就會有明顯腦補差異。

Note
模型隨著訓練資料、訓練方式、模型大小、參數不同，對於同一個 prompt 的理解就會有差異，甚至同一個模型在不同時間點的表現也會有差異。

這邊我們就舉例一個後面要製作的記帳小工具（預計專案資料夾會叫 money-note）吧！

假設你只是跟 AI 說「幫我做一個記帳 App」，那麼你是否有想過 AI 會怎麼理解？

• 需要轉帳功能嗎？
• 需要雲端共用嗎？
• 資料要存在哪？
• 要不要登入功能？
• 需不需要儲存使用者資料？

儘管 AI 遇到不確定的需求時，就會跳出像下面這種選擇題畫面來反問你：

而會出現這些選擇題就代表著 AI 它對於這個需求感到非常不明確，所以 AI 就會問自己「我覺得我應該要問一下使用者的需求」，然後就拋出了這些選擇題給你，讓你去選擇你想要的功能。

如果你留給它腦補的空間越大，那麼最後的成品絕對會跟你想像的差很多，甚至可能會出現你根本不想要的功能，這就是為什麼我們要先把需求講清楚，讓 AI 不要自己腦補。

就跟你在跟工程師溝通一樣，如果你只是說「幫我做一個記帳 App」，那麼工程師也會問你很多問題，因為他們也不清楚你的需求。

讓 AI 引導你建立規格

講了那麼多，不知道你有沒有想過 「規格」 到底是什麼呢？

所謂的規格簡單來講就是一份 產品規格文件 ，裡面會詳盡列出你想要做的功能、你不想要做的功能，以及怎麼驗收這個專案才算是結案。

但問題來了，對於我這種小新手來講，規格到底該怎麼寫呢？畢竟我們又不是相關背景，甚至不是 Product Manager（產品經理/產品管理人），對於這些需求的釐清，肯定是會感覺到吃力。

所以這邊我們就需要利用與 AI 協作的能力，讓它來協助幫助我們把腦中模糊的想法，轉化成一份具體的規格文件 SPEC.md。

首先，請你先打開終端機，並輸入以下指令來建立專案資料夾（跟之前的 claude-playground 一樣：

mkdir money-note # 建立專案資料夾
cd money-note # 進入專案資料夾
claude # 啟動 Claude Code

進入 Claude Code 之後（別忘記先切換到 Shift+ Tab 切換到 manual mode，預設模式），我們要用的方式是我稱為 「訪談式 prompt」 的問法，這個 Prompt 的重點有三個：

1. 明確告訴 AI 先不要寫程式，避免它太雞婆直接動工。
2. 一次只問你一個問題，避免它一次丟十個問題問倒你，相信我，這樣真的比較好(過來人經驗，菸...)。
3. 問到 AI 覺得足夠具體之後，再請它整理成 SPEC.md。

所以接下來，請你把下方 Prompt 複製貼上到 Claude Code 的輸入框，並按下 Enter：

我想做一個記帳的小工具，先不要寫任何程式。
請你當我的產品顧問，一次問我一個問題，把需求釐清。
問到你覺得足夠具體之後，跟我說可以整理成 SPEC.md，並請我確認。

Note
請記住 AI 具有隨機性，你的畫面內容跟選項可能會跟我這邊的畫面不一樣，但大致上都會圍繞在「使用者、功能範圍、資料保存」這三個面向。

接下來大概就是一大串的拷問時間，大致上範圍可能會涵蓋這些

• 動機是什麼？（我想要快速記帳，並隨時知道這個月花了多少）
• 誰用？（就我自己，單人）
• 記收入還是支出？（我當下回答「只記支出就好」，先記住這個回答，Day 10 它會回來咬我一口）
• 需要哪些欄位？（金額、分類、日期、備註）
• 資料要存哪？換裝置要同步嗎？（存本機就好，不用同步）
• 想看什麼統計？（這個月花多少、各分類占比）

...等等。

這個過程你應該會發現有某些問題你可能連想都沒想過，而這就是「訪談式」的價值存在。

透過訪談式 Prompt 可以把你腦中那些還沒成形的決定一個一個逼出來，最後你會得到一份完整的需求摘要，這時候如果你看一看沒問題就可以請它整理成 SPEC.md 並儲存下來。

這時候你應該會覺得很好奇，「訪談式 Prompt」 跟 Plan Mode 有什麼差別呢？其實兩者的差別在於：

• Plan Mode： 是以規劃完畢就開工為導向，它會產出一份實作計畫（要動哪些檔案、步驟怎麼走），然後問你要不要照著做，雖然遇到模糊的地方也會反問你，但問的目的都是「為了把計畫定下來並開始實作」所需要的事。
• 訪談式 Prompt： 是以 釐清需求 為導向，它不以動工為目標，所以主要是產出一份需求規格書，先搞清楚 what（要做什麼） 就好，至於 how（怎麼做） 那是之後 Plan Mode 的事，而且這個提問的節奏是在你手上的，畢竟你規定它一次一題慢慢挖，而不是讓它自己決定問夠了沒。

那實際上產出來是如何呢？底下這邊也給你看一下我產出的 SPEC.md：

• GitHub 專案連結：day-8#SPEC.md

那這一份 SPEC.md 裡面有幾個重要的點，分別是「明確不做」跟「要做的功能」，這兩個是非常重要的範圍界定，如果沒有這個範圍界定，你有很高的機會範圍爆炸，導致系統永遠都無法搶第一上線。

Note
所謂的範圍爆炸意思是避免想到什麼就做什麼，第一版還沒出來之前就胎死腹中了，做產品最需要的就是搶 「市場先機」。

最後這邊還是要提醒一下

規格不是聖旨、也不是一成不變的。

它是一份活的文件，隨著開發過程中你對專案的理解越來越清楚，這份文件也會跟著更新，但基本上會控制在既定的範圍內，如果有想要增加或刪除的功能就先放到未來擴充中，然後同時更新 SPEC.md，讓文件跟現實保持同步。

開工前做一次範圍核對

接下來，請你不要急著拿這一份 SPEC.md 去請 AI 開發，因為目前這個 SPEC.md 只是你跟 AI 一問一答生出來的，這個過程其實你們兩個都建立在 「趕快收斂」 的情緒上，這種時候直接實作的話，非常很容易漏掉東西，所以我們還要另外請 AI 做一次「範圍核對」。

這時候我們要輸入 /clear or /new 清空前面的對話內容，把它頭上原本戴的 「產品顧問」 帽子換成 「檢查員」 帽子，從第三者的角度把這份規格掃一遍，檢查三件事：

請讀 SPEC.md，先不要改任何檔案，幫我檢查三件事：

1. 「要做」清單裡有沒有哪一條寫得太模糊、沒辦法驗收的？
2. 「要做」跟「不做」有沒有互相矛盾或重疊的項目？
3. 有沒有哪個功能是內文提到、但沒出現在要做清單裡的？

只回報結果，不要動檔案。

你會發現它抓出了一堆還沒拍板的問題，其中有些是你可能看得懂（吧？），例如這一條：

SPEC.md:112 寫「不限制可切到多久以前或以後」，但畫面上沒有「回到本月」的入口。使用者手滑切到 2019 年，要按 80 幾次 ▶ 才回得來。要嘛加一顆「本月」按鈕，要嘛在規格裡註明接受這個代價。

以我來講，我認為加一顆「本月」按鈕就可以解決了

請你把「月曆切換」加一顆「回到本月」按鈕，並補進「要做」清單跟驗收條件。

這個就是你剛好沒想到，AI 也沒想到的地方，這就是為什麼要做一次範圍核對，因為你們兩個都在趕快收斂的情緒下，很多細節都沒注意到。

解決前面之後，但...如果是有些是你看不懂的呢？該怎麼辦呢？例如：

SPEC.md:54 的範例資料自相矛盾：date: "2026-08-07"，但 createdAt: 1754534400000 換算是 2025-08-07。差一年。這種範例常被直接照抄進測試資料或 seed。

這邊你看不懂沒關係，但千萬不要因為看不懂就跳過假裝沒看到，你可以直接請 AI 解釋：

另外，我看不懂「SPEC.md:54 的範例資料自相矛盾：date: "2026-08-07"，但 createdAt: 1754534400000 換算是 2025-08-07。差一年。」這一條，可以用白話解釋給我聽，並推薦一個正確的範例嗎？

它就會用白話告訴你 createdAt 是「時間戳記」（電腦記時間的一種方式），範例裡那串數字換算回來是 2025 年，跟上面的 2026 年差了一年，接著給你一組修正後的數值。

基本上到這邊為止，我們假設都沒問題了，那麼就會跟 AI 拍板這樣說：

請依照這些結論更新 SPEC.md，其他內容不要動。

最後請在文件末端加一節「決策紀錄」，把這次拍板的結論條列下來。

相信我，保留決策記錄會非常重要，因為幾天後你一定會忘記自己當初為什麼這樣決定，到時候翻這一節就好，不用重新想一遍。

到目前為止，接下來就輪到你自己了，你可以試著反覆跟 AI 討論釐清，體驗一下「訪談式 Prompt」的威力，直到你覺得 SPEC.md 裡面所有的功能都可以被驗收、沒有矛盾、也沒有遺漏的項目。

這樣之後輪到你製作你自己想要的專案時，這些流程都是一樣的：

• 把核對抓到的點逐一拍板
• 請 AI 更新 SPEC.md，更新完再跑一次上面那段核對 prompt

直到三題都回你「沒有」為止，這份規格才算定稿。

這整套流程我也畫成一張圖給你參考：

那麼這邊也出一個功課給你；

• 跟著上面的流程，建立一份 SPEC.md，裡面必須有「要做／不做／驗收」三區塊。
• 登入帳號、預算提醒、雲端同步這些，必須明確列在不做清單。

這個過程其實就是在逼你把事情想清楚，不然等到真的開工後，那些沒想清楚的模糊地帶就會一個一個回來討債，範圍爆炸就是這樣來的（這也是為什麼工程師總是靠北 PM 總是沒有把需求釐清的原因）。

結語

ok，時間差不多了，這邊也來總結一下吧。

雖然今天一行程式碼都沒有寫到，但其實反而我們正在準備最重要的事情，也就是 「把想法變成規格」，這件事情就是所謂的打地基。

從什麼都不知道，到有一個模糊的想法，再到有一份具體的規格文件，在早期我們可能需要花上好幾天，甚至需要找相關人員來幫忙進行需求訪談，但現在有了 AI 的協助，我們可以在短時間內把腦中模糊的想法逼成一份具體的規格文件。

如果看到這邊沒問題的話，我們下一篇見～