把模糊需求改寫成可驗證結果

「幫我換框架」、「做漂亮一點」都可以是工作的起點，但不能直接當成交付條件。它們說出了方向，沒有說清楚讀者最後會看到什麼、要在哪裡檢查，以及哪些事情不在這次範圍內。

需求不必一開始就像完整規格書。比較重要的是，在開始大量實作以前，先把一句模糊的話改寫成可以被觀察、討論和驗收的結果。好的需求不是增加更多術語，而是讓不同的人能用同一個結果判斷有沒有做對。

先把「想要什麼」和「怎麼判斷」拆開

一個可以交付的需求，至少要回答四件事：

1. 結果是什麼？ 使用者會看到什麼內容，或完成什麼操作？
2. 在哪裡看？ 是某個公開網址、初始 HTML、瀏覽器操作，還是建置後的檔案？
3. 這次不包含什麼？ 哪些看似相關的功能、效果或成果不要順便推導出來？
4. 誰做最後判斷？ 可以由工具確認的部分，和需要人決定的部分要分開。

例如，「把網站做得更好」可以先改寫成這樣：

原本的說法	可驗證的結果	明確限制
幫我換框架	直接打開公開網址時，頁面已有主要內容；導覽使用真實連結；需要瀏覽器行為的部分才由局部腳本處理	不要求把舊框架的整套 App 外殼原樣搬過來，也不由此宣稱效能或 SEO 已改善
做漂亮一點	手機上的標題、說明和操作有清楚順序；內容不因固定高度被截斷；控制可以用鍵盤操作	色彩氣氛和整體是否符合期待，仍需要視覺驗收；不宣稱所有裝置都已通過檢查

表格裡的「結果」和「限制」同樣重要。沒有限制時，實作者很容易替需求補上看似合理的功能；沒有檢查位置時，驗收就只能回到「感覺差不多」。

「幫我換框架」不是驗收條件

這個專案原本使用 Vue，後來改成原生 Astro。若只留下「換框架」四個字，至少有幾種完全不同的做法都可能被算成完成：在 Astro 外面包一層舊 App、逐頁搬移 Vue 元件，或重新用 Astro 路由和內容資料安排頁面。

真正需要確認的是網站行為，而不是框架名稱。這次需求被改寫成幾個能直接檢查的結果：

• 直接打開公開網址，初始 HTML 就有標題和主要內容，不依賴一個空的瀏覽器掛載點。
• 導覽使用真實連結，讀者可以直接前往其他頁面。
• 既有的內容、圖片和語言網址保留；舊元件的形式不被當成必須延續的理由。
• 簡單的頁面結構先由 Astro、HTML 和 CSS 承擔，需要瀏覽器狀態的互動才另外使用局部 TypeScript。

這些條件比「幫我從 Vue 換到 Astro」更接近真正的交付內容。它們也讓取捨變得可討論：如果有人提出要保留整個舊 App，就能回頭問這是否有助於上述結果，而不是因為元件已經存在就照單全收。

驗收時可以直接檢查頁面 HTML、深層網址、連結和無 JavaScript 時的主要內容。這些檢查能證明目前輸出的頁面符合條件，但不能順便證明網站更快、搜尋排名更好，或所有視覺細節都已經完成。

「做漂亮」要先縮小成介面行為

「漂亮」不是沒有用的需求，只是它需要再往下拆。若只拿一張參考圖說「照這個做」，實作者可能會把圖片裡的文字、日期、按鈕甚至不存在的功能一起當成規格；這些都不一定是原本想要的結果。

可以先把它改寫成讀者能觀察的條件：

• 手機先看到標題、說明，再看到主要操作，不靠 CSS order 製造和閱讀順序不同的畫面。
• 文章正文保持可讀寬度，程式碼和寬表格只在自己的容器捲動，不讓整頁一起溢出。
• 沒有封面或精選文章時，依真實數量呈現，不複製示意卡片填滿版面。
• 互動控制有可見的 focus 狀態，停用 JavaScript 時仍能讀到主要文案。

這些條件可以透過 DOM、CSS、鍵盤操作和不同寬度檢查；「整體氣氛對不對」、「層級是否舒服」則仍然要由有決定權的人看過。開發規格列出的 320、390、768、1024、1440 CSS px 與 200% zoom，可以作為檢查範圍，但不是「所有裝置都沒有問題」的證明。

把視覺需求改寫成行為，不是要把設計變成一張冷冰冰的測試清單，而是先把會影響實作的部分說清楚。剩下的主觀判斷保留下來，才不會假裝它可以由一個 build 結果代替。

每個需求都補一個「不做什麼」

模糊需求最容易在兩個地方膨脹：實作者替它補功能，或驗收時把原本沒說過的成果算進來。因此，需求卡最好同時寫出排除項目。

以這個網站為例：

• 「保留原站」不等於保留每一個舊檔案；要先確認哪些內容和行為真的有公開入口。
• 「通過檢查」不等於視覺、效能、SEO、流量或商業成果已經成立。
• 「可以開始討論」不等於已經承諾固定服務、功能範圍或發布日期。

排除項目不是消極地縮小工作，而是讓下一個決定有邊界。當需求需要擴張時，可以明確新增條件；不必讓每一次合理猜測都悄悄變成產品規格。

一張可以重複使用的需求卡

如果還不知道怎麼開始，可以先用下面的格式整理，不必等到所有細節都確定：

想解決的問題：
使用者最後要看到或完成的結果：
可以在哪裡觀察：
這次明確不包含：
由工具檢查的部分：
需要人做最後判斷的部分：

「需求還沒整理好，也可以先把問題帶來」仍然成立。這張卡的作用不是要求對方先寫完規格，而是讓討論有一個可以逐步補充的形狀。先寫結果，再決定要不要保留某段程式；先寫限制，再決定是否值得增加功能。

真正能降低誤解的，不是讓需求看起來很專業，而是讓下一個人知道要改變什麼、到哪裡看結果，以及哪些事情目前不能直接宣稱。