「幫我做一個漂亮、手機能看、可以接客人的網站。」這句話可以開啟討論，卻還不足以估價或驗收：接客人是顯示電話、寄出表單，還是提供預約時段？不同理解，會做出不同網站。
這篇要完成的成果，是一份能拿來討論的需求草案：六項範圍、待確認問題，以及五個可觀察結果的驗收情境。 適合準備找人做網站，或打算用 AI 建站的個人、工作室與小企業。
準備一段不含私人資料的需求，以及能輸入文字的 AI 對話工具即可。先用下方虛構案例練習，不必上傳客戶合約、帳號密碼或真實聯絡資料。規格整理完成後，可接著看網站製作廠商怎麼比較，把同一份內容交給候選對象。
第一步：保留原話，分清確認與猜測
先不要請 AI 寫程式。把需求原話保留下來，再要求每個整理結果都能對回原文。以下是本篇完整的虛構練習需求：
「我是一間設計工作室，想做首頁、服務介紹、聯絡三個頁面。聯絡表單的姓名、Email、需求說明都要必填，填完寄到我指定的信箱。手機要好閱讀。我之後想自己修改服務說明。這次不要線上付款，希望下個月上線。」
這段原話沒有給收件信箱、圖片素材、確切上線日，也沒有說用哪套後台。AI 可以提出問題，不能自行填完後就當成業主已經同意。
用三個狀態整理會比較清楚：已確認是原文明確說出的需求；待補充是完成評估還缺的資訊；建議、待確認則是 AI 或製作者提出的細節。這裡的「已確認」只表示符合練習原文，不代表真實專案已簽核。
第二步：複製提示詞，要求來源與輸出格式
把下面這段指令貼進一般文字對話，再接上完整原始需求：
請擔任網站需求整理助手。目標是產出可供業主與製作者確認的規格草案，先不要寫程式或選技術。只把原文明確提到的內容列為已確認；缺少的資訊列為待補充；你提出的細節列為建議、待確認。每一項都附對應原句或說明它是建議，並保留原文的排除項目。
請依序輸出：一、網站目的；二、頁面與功能清單，編號 R1、R2 等；三、待補充問題；四、五個驗收情境，各自寫出前置條件、操作、可觀察結果，並標明對應需求編號。最後找出你是否新增了原文沒有的功能或承諾。預算與交期資訊不足時，只列問題，不自行保證。
【原始需求】在這裡貼上第一步的完整需求。
這種寫法把任務、資料、限制與輸出格式交代清楚。Anthropic 的提示撰寫指南也建議明確描述需求、格式和步驟；本文把這些原則用在網站規格整理，並不保證每個模型會產出相同答案。
第三步：對照整理樣本，找出 AI 多加了什麼
以下是本次以 AI 輔助整理、再依原文校對的編輯後示範，不是客戶委託、正式合約，也不是某款免費帳號的原始輸出。
- R1／已確認：三個頁面。 首頁、服務介紹、聯絡；依據是「首頁、服務介紹、聯絡三個頁面」。各頁文案、圖片、是否需要更多內頁仍待補充。
- R2／已確認：三個必填欄位。 姓名、Email、需求說明；依據是「都要必填」。字數限制、提示文字與其他欄位先列為建議，不偷偷加上公司統編或電話必填。
- R3／已確認：需求寄至指定信箱。 依據是「填完寄到我指定的信箱」。實際地址、寄件方式、收件確認與失敗處理待補充。
- R4／已確認：手機好閱讀。 依據是「手機要好閱讀」。要檢查哪些裝置、文字與按鈕如何驗收，需再具體化。
- R5／已確認：業主可自行修改服務說明。 依據是「自己修改服務說明」。可修改哪些內容、操作方式、帳號權限與教學交接待補充。
- R6／已確認：本次不含線上付款。 依據是「這次不要線上付款」。付款串接不能被 AI 當成標準配備加入。
「希望下個月上線」要保留為時程期待，但不能直接變成保證交付日。要再確認具體日期、素材何時備齊，以及由誰確認設計與內容。
這份樣本也沒有直接選 WordPress、會員系統或 LINE 通知。若 AI 提出這些項目，請它指出原文依據；沒有依據，就先移到建議區。需要比較更新方式時，再接著看Wix、WordPress 與客製網站的差異。
第四步：把「完成了」改成五個能檢查的情境
可以借用 Given／When／Then 的寫法，用中文表達成「在什麼情況下／做什麼／應看到什麼」。Cucumber 的Gherkin 文件把它們分別用來描述初始情境、事件與預期結果；重點是結果能被觀察，這裡不需要安裝測試框架。
以下五項是驗收細節建議，仍需雙方確認，不是原文已同意的全部技術規格。範例中的功能尚未建置或實測。
- 必填檢查，對應 R2：在聯絡表單空白時，按下送出；應指出需要補填的欄位，且不能顯示成功。再填入 Email 為 abc 的格式錯誤資料，應能理解哪裡需要修正。
- 正常收件，對應 R3：在雙方已設定測試收件信箱的環境，用標明測試用途的資料送出；除了畫面回覆，還要由收件端核對實際收到的姓名、Email 與需求內容。成功訊息代表伺服器接收，還是通知已送達，必須事先定義。
- 失敗處理，對應 R3：在測試環境模擬請求失敗，再送出已填好的表單；應顯示失敗或待重試狀態，而不是假成功。保留已填內容是本篇提出的建議，需確認後納入範圍。
- 手機閱讀，對應 R4：以 390px 寬度作為一個建議起點，開啟三個頁面並操作導覽、閱讀和填表；內容不應橫向溢出，欄位名稱與錯誤提示能看清楚。仍需共同選定實機與其他尺寸，單一尺寸通過不代表所有手機都通過。
- 自行更新，對應 R5：用預定交付給業主的操作方式，修改一段服務說明並儲存；重新開啟公開頁面後，應看得到正確的新文字。哪些內容能改、是否需要重新發布及如何恢復誤改，都列入待確認問題。
表單驗證也要分層。瀏覽器攔住空白或錯誤格式，不代表伺服器一定會拒絕不合法資料；MDN 表單驗證說明提醒，前端驗證可以被繞過，伺服器仍須驗證輸入。規格中應要求製作者說明兩端的檢查方式。
寫好這些情境，代表你知道之後要怎麼驗收；只有實際操作並保存結果，才能填「通過」。不要把 AI 產出的檢查清單當成測試報告，也不要直接往真實客戶的正式表單送假資料。
第五步：補問問題，再讓 AI 做一次範圍核對
在這個例子裡，最需要補齊的是：收件信箱、公開文案與圖片來源、服務說明可編輯範圍、預算、明確上線日期，以及誰負責最後確認。寄信失敗如何處理、提交資料是否保存及由誰存取，也要問清楚。
回答後，把答案接在原始需求後面，再貼上這段核對指令：
請根據原始需求與補充答案修訂草案。逐項檢查 R1 起的需求與驗收情境：是否有原文依據、是否仍有未回答的問題、是否出現未核准的新功能、是否把建議寫成已確認、是否把預期結果寫成已測試成功。請列出差異，再輸出修訂版，保留尚未確認的標記。
不要只問「這份規格完整嗎」。要求指出哪一項、缺哪個答案，才容易繼續處理。像「聯絡功能正常」應再拆成輸入、送出、接收與錯誤情境；「手機版完成」則需要檢查範圍與可觀察的結果。
免費練習的範圍與工具限制
這個文字練習不需要 API、自動化平台或建站訂閱。查核當天，Claude 官方提供可進行文字對話的Free 方案；也可以使用你已經有可用額度的 AI 工具。免費方案仍有使用限制，本文不承諾固定訊息數或每次都能立即完成。
先用本篇的虛構資料練習；若額度不足，可以等恢復，或先手動完成原文對照。使用付費帳號的人仍依自己的方案計費，這裡沒有要求升級、加購或購買 API 額度。
本次在既有 Codex AI 協作流程中完成示範整理與原文對照，未另外購買額度，未實測 Claude Free 的登入、操作介面或可用次數。工具功能與免費方案依官方文件整理；示範不代表 Claude 的原始回答或不同模型的效果比較。
自己做一次：交出一份可以被追問的草案
先照本篇原始需求做一輪，再把案例換成自己的網站想法。保存原始文字、使用日期、工具名稱、畫面可見的模型或模式，以及修訂後版本；看不到的設定就記為未知。
驗收這份草案時，檢查六件事：每個已確認需求都找得到來源；待補充事項仍有標記；原文的排除項目沒有消失；每個驗收情境都有前置條件、操作與結果；新增建議沒有被當成承諾；沒有實際測試的項目都未標成通過。
預期成果是能讓另一個人看懂並提出具體問題的文件。它還不是網站完成證明，也不是正式報價。整理好後，可用網站製作費用拆解核對頁面、功能與後續維護是否都列入討論。
查核日期：2026-09-13。本文由 AI 輔助整理與撰寫，示範採虛構需求並對照原文校訂；未建立範例網站、寄送測試信或驗證功能、交期與商業成果。來源與實作範圍已於各段標示。