昨天最後留下了一個問題：

功能名稱已經留下來了，但 AI 到底怎麼知道這個功能應該怎麼運作？

例如，假設我正在做一個活動網站，而且已經確定「搜尋功能」要放進 Must Have。

這樣 AI 就知道該怎麼做了嗎？

好像還是不知道。

因為「搜尋功能」其實只告訴 AI：

我要搜尋。

但沒有告訴它：

搜尋什麼？

使用者在哪裡輸入？

輸入之後要按按鈕，還是即時搜尋？

比對哪些欄位？

搜尋不到東西怎麼辦？

結果要顯示在哪裡？

也就是說，Scope 幫我決定了一個功能要不要做，但沒有告訴 AI 這個功能應該怎麼運作。

今天就來處理這中間缺少的一層。

Feature 其實比較像一個功能名稱

以前在 Vibe Coding 時，我很常直接列一串功能給 AI。

例如想做活動報名網站：

需要：

- 活動列表
- 活動詳情
- 報名功能
- 搜尋功能
- 收藏功能

乍看之下好像已經很具體。

至少比：

幫我做一個活動網站

完整很多。

但如果仔細看，「報名功能」其實還是只有四個字。

它比較像是在告訴 AI：

系統裡面要存在一個叫做「報名」的東西。

至於真正怎麼運作，還是留下很多空白。

AI 接下來只能自己補。

例如它可能決定：

點擊報名
↓
跳出 Modal
↓
輸入資料
↓
送出
↓
顯示成功訊息

另一個 AI 也可能做成：

進入獨立 Registration Page
↓
填寫資料
↓
確認頁
↓
再次確認
↓
報名完成

兩個版本都不能直接說是錯的。

問題在於：

這些原本應該由需求決定的事情，又重新變成 AI 的猜測。

所以 Feature 和 Requirement 還是不太一樣

這也是我今天重新整理 ClarifyBuild 時很重要的一個發現。

假設我寫：

Feature：搜尋活動

它主要是在說：

這個產品具有搜尋活動的能力。

但如果往下一層整理，可以變成：

FR-01
使用者可以在活動列表頁輸入關鍵字搜尋活動。

FR-02
系統根據使用者輸入的關鍵字，比對活動名稱並更新搜尋結果。

FR-03
當沒有符合條件的活動時，系統應顯示無搜尋結果的狀態。

到了這裡，AI 可以自行猜測的空間就少很多了。

同樣都是「搜尋功能」，但前者只有 Feature Name，後者已經開始描述：

誰
↓
做什麼
↓
系統怎麼回應
↓
最後會發生什麼

這就是我今天想加入 ClarifyBuild 的下一層：

Functional Requirement。

但我不想把 Functional Requirement 做成另一份複雜表單

問題又來了。

ClarifyBuild 的使用者本來就不一定懂 Requirement Engineering。

如果最後要求使用者自己填：

Requirement ID：
Actor：
Trigger：
Precondition：
Input：
System Behavior：
Output：
Exception：
Postcondition：

那好像又回到一開始我不想做的事情。

ClarifyBuild 原本就是希望：

使用者不需要先學會怎麼寫需求文件，系統再協助他把需求整理出來。

所以 Functional Requirement 不應該變成另一張巨大表格。

比較合理的方式應該還是延續前幾天確定的 Clarification Flow。

例如使用者只說：

我希望使用者可以搜尋活動。

ClarifyBuild 發現其中還有重要資訊尚未確認：

搜尋的對象是什麼？

使用者回答：

活動名稱。

接著可能還需要確認：

搜尋結果要即時更新，還是按下搜尋後才顯示？

使用者回答：

即時更新。

隨著 Requirement State 逐漸補完整，ClarifyBuild 就可以整理出：

Feature
搜尋活動

Functional Requirement
使用者可以在活動列表輸入關鍵字，
系統會根據活動名稱即時過濾並顯示符合的活動。

換句話說，我希望 ClarifyBuild 做的依然不是：

請使用者自己寫 Functional Requirement。

而是：

從使用者的回答中，把 Functional Requirement 整理出來。

我先替 Functional Requirement 找出幾個基本元素

如果 ClarifyBuild 未來要自動整理需求，我就需要知道：

一條 Functional Requirement 最少需要哪些資訊？

今天我先不追求非常正式的 Requirement Specification 格式，而是回到 ClarifyBuild 的使用情境。

對 Vibe Coding 來說，我目前比較在意的是下面這幾件事：

例如：

Feature
收藏活動

Actor
使用者

Trigger / Input
使用者在活動詳情頁點擊「收藏」

System Behavior
系統將該活動加入收藏清單

Result / State
該活動出現在收藏頁面中

Important Rule
同一活動不可重複加入收藏

最後才整理成比較適合交給 Coding Agent 的需求：

FR-04
當使用者在活動詳情頁點擊「收藏」時，
系統應將該活動加入使用者的收藏清單，
且同一活動不得重複加入。

這種形式對我來說比只有：

收藏功能

清楚太多。

一個 Feature 也不一定只會有一條 Requirement

這裡還有另一個以前容易忽略的地方。

我原本會很自然地把：

Search
Save
Login
Export

看成四個 Requirement。

但實際開始拆解之後才發現，一個 Feature 通常可能包含好幾個不同的系統行為。

例如：

Feature：搜尋活動

至少可能拆成：

FR-01
使用者可以輸入活動搜尋關鍵字。

FR-02
系統根據活動名稱過濾活動。

FR-03
清除搜尋內容後，系統重新顯示完整活動列表。

FR-04
沒有符合結果時，系統顯示 Empty State。

這些其實都屬於同一個 Feature。

所以 ClarifyBuild 未來的資料結構，也不能單純假設：

一個 Feature
=
一條 Requirement

比較合理的關係應該是：

Feature
↓
Functional Requirement 1
Functional Requirement 2
Functional Requirement 3
...

這個差異看起來不大，但會直接影響後面的 Specification 怎麼產生。

那 ClarifyBuild 自己呢？

既然我正在設計 ClarifyBuild，我也可以直接拿 ClarifyBuild 自己來測試這套想法。

前幾天我已經確定其中一個核心功能是：

Requirement Clarification

但如果我今天只把這行丟給 Coding Agent：

請做 Requirement Clarification 功能。

幾乎等於什麼都沒有說。

所以我試著開始拆。

第一版可能會接近：

Feature：
Requirement Clarification

接著往下變成：

FR-C01
使用者可以輸入自己想建立的產品 Idea。

FR-C02
系統根據目前已有的 Requirement State，
判斷仍有哪些重要需求資訊尚未確認。

FR-C03
系統針對重要的 Unknown，
向使用者提出相關的 Clarification Question。

FR-C04
使用者回答問題後，
系統將新的 Decision 更新至目前的 Requirement State。

FR-C05
更新 Requirement State 後，
系統再次檢查是否仍存在需要優先釐清的 Unknown。

FR-C06
當目前沒有仍需優先釐清的重要 Unknown 時，
流程可以進入 Scope 定義階段。

這時我才真正感覺到：

前幾天設計的：

Idea
↓
Identify Unknowns
↓
Ask
↓
User Decision
↓
Update Requirement
↓
Check Remaining Unknowns

開始從概念流程，慢慢變成可以交給系統實作的 Requirement。

而且這裡我刻意只寫「系統判斷 Unknown」。

我現在還沒有把它寫成：

呼叫 LLM API 判斷 Unknown。

因為「系統應該完成什麼」和「最後使用什麼技術完成」是兩件事情。

Clarification Engine 最後可能是規則、條件判斷、Heuristic、AI API，甚至混合方式。

目前還沒有必要提前鎖死。

Functional Requirement 也幫我看見新的 Unknown

拆到這裡又出現一個有趣的現象。

Requirement 寫得越具體，我反而越容易發現：

原來這裡我也還沒有決定。

例如剛才有一條：

系統針對重要的 Unknown，
向使用者提出相關的 Clarification Question。

馬上就會出現新的問題：

一次問一題還是多題？

什麼叫「重要」的 Unknown？

什麼情況可以跳過？

使用者可以回答「我不知道」嗎？

哪些 Dimension 一定要完成才能進 Scope？

這些事情現在都還沒有完整答案。

但我覺得這反而是好事。

因為以前這些問題通常要等到開始 Coding、甚至看到 AI 做錯之後才會發現。

現在它們在 Requirement 階段就已經浮出來了。

也更符合 ClarifyBuild 一開始想處理的問題：

Don't start with code.

Start with clarity.

那今天要把需求寫到多細？

這又是一個需要控制的地方。

如果每一個 Button、文字、Hover、動畫、Padding 都先變成 Requirement，最後很可能又會寫出一份巨大規格。

所以我目前先抓一條界線：

Functional Requirement 優先描述會影響產品行為、資料狀態與使用流程的需求。

例如：

點擊 Save 後資料需要被保存

這是 Functional Requirement 很重要的資訊。

但是：

Save Button 使用 12px Border Radius

這就不一定需要在這個階段決定。

除非這個視覺設計本身就是產品的重要要求。

所以 Functional Requirement 也不需要把所有細節寫死。

我現在更想優先找出那些：如果沒有先說清楚，AI 很可能做出另一個同樣合理版本的決策。

這和 Acceptance Criteria 又有什麼不同？

做到這裡，其實已經很容易直接往 Acceptance Criteria 走。

例如：

Given 使用者位於活動列表頁
When 使用者輸入「AI」
Then 系統只顯示名稱包含「AI」的活動

但我今天暫時不往下展開。

因為目前我想先分清楚兩個問題。

Functional Requirement 比較像在回答：

這個功能應該怎麼運作？

Acceptance Criteria 則會更進一步回答：

我要怎麼確認它真的做對了？

這兩層很接近，但用途還是不太一樣。

所以先留到後面再正式處理。

ClarifyBuild 的需求結構又往前走了一步

今天再往下一層看，我發現 Scope 裡確定要做的 Feature，本身還不足以直接拿去 Build。

今天真正補上的關係其實是：

Scope
↓
Feature
↓
Functional Requirement

但這還不是完整的 Specification。

Day 7 小結

今天沒有開始寫很多 Code。

但 ClarifyBuild 又多確定了一層很重要的需求結構：

Feature
↓
Functional Requirements

Scope 負責決定：

這個功能做不做？

而 Functional Requirement 開始處理：

既然要做，它到底要怎麼運作？

我也替 ClarifyBuild 自己初步拆出了 Requirement Clarification 的 Functional Requirements，讓前幾天的 Dynamic Clarification Flow 不再只是一張流程圖，而開始慢慢接近可以實作的規格。

但現在又會碰到下一個問題。

當功能越拆越清楚之後，我們還需要知道：

使用者到底會怎麼走過這些功能？

如果只有一堆獨立 Requirement，Coding Agent 還是不一定知道頁面、操作與功能之間的先後關係。

所以下一篇，我會再把這些 Requirement 接回真正的使用流程，看看 User Flow 到底在 AI Coding 前補上了什麼資訊。

Day 7 完成。

明天見。