很多人使用 AI 用到一半卡住，不是因為不夠努力，也不是因為工具不夠強，而是因為一開始只有想法與段落，沒有把需求整理成可執行的規格。
你可能看過這種狀況
- 需求寫成一段很長的描述，看起來很完整，但無法開工
- 只有功能清單，沒有流程、資料欄位、頁面狀態
- 想到哪做到哪，做到一半才發現缺前提或撞到邊界條件
- 最後變成改不完、做不下去、一直重寫
這篇文章會給你一套簡單的規格骨架，讓你把一堆想法變成能落地的執行稿，任何工具都適用。
為什麼你 AI 用到一半卡住：因為你寫的是想法，不是規格
想法常長這樣
- 我想做一個會員系統
- 我希望使用者可以更方便下單
- 我想讓首頁更有質感
這些都很好，但它們缺少一件事
如何驗證已經做對，以及工程要怎麼開始切工作。
真正能推動開發的規格，至少要做到兩件事
- 可被拆成任務並排進優先順序
- 可被測試與驗收，知道什麼叫完成
在敏捷的語境裡，常用的做法是把需求寫成使用者故事，再用驗收條件定義完成標準。(Atlassian)
可執行的規格必備 6 件事
只要缺其中幾項，就很容易做到一半撞牆。
1 流程
使用者從哪裡進來，做哪些步驟，哪裡結束
不需要畫得很漂亮，但要能一眼看懂順序與分支
2 頁面與狀態
每個頁面至少要有狀態
- 初始狀態
- 載入中
- 成功
- 失敗
- 空資料
- 權限不足或未登入
3 資料欄位與規則
每個資料要說清楚
- 欄位名稱
- 類型
- 必填或選填
- 長度或格式限制
- 例外處理
4 邊界條件
只要你沒寫，做到後面一定會被問
例如
- 重複提交怎麼辦
- 斷線怎麼辦
- 兩個人同時操作怎麼辦
- 超過限制怎麼辦
5 非功能需求
你不一定要用專有名詞，但你要把要求講清楚
例如
- 速度要快到什麼程度
- 哪些資料要保護
- 哪些操作要留紀錄
Microsoft 的工程指南也強調，要把這類非功能需求系統性地整理成可落地的要求。(Microsoft GitHub)
6 驗收條件
驗收條件就是完成的定義，必須可檢查、可測試
Atlassian 對驗收條件的定義很直接：它是一組清楚、精簡、可測試的完成條件。(Atlassian)
一頁式可執行規格模板
你可以把下面這份直接貼到 Notion 或 WordPress 草稿裡使用。
A 目標與範圍
- 目標：這次要解決什麼問題
- 受眾：誰會用
- 範圍內：這次要做哪些事
- 範圍外：這次先不做哪些事
B 主要流程
- 入口：使用者從哪裡開始
- 步驟 1
- 步驟 2
- 分支：如果發生某狀況就走另一條
- 結束：成功或失敗各自回到哪裡
C 頁面清單與狀態
| 頁面 | 初始 | 載入中 | 成功 | 失敗 | 空資料 | 權限 |
|---|---|---|---|---|---|---|
| 例：訂單頁 | 顯示列表 | 顯示載入 | 顯示成功提示 | 顯示錯誤提示 | 顯示空狀態 | 提示登入 |
D 資料欄位表
| 欄位 | 類型 | 必填 | 規則 | 範例 |
|---|---|---|---|---|
| 例：email | 文字 | 是 | 必須符合格式 | name@mail.com |
E 邊界條件清單
- 重複提交：按兩次送出如何處理
- 同時操作：兩個人同時修改怎麼處理
- 失敗重試：失敗後可否重試，重試上限
- 限制：數量上限、字數上限、頻率上限
F 驗收條件
用可測試句子寫
- 當使用者未登入，點進頁面會看到提示並導向登入
- 當表單缺必填欄位，會顯示明確錯誤訊息且不可送出
- 當送出成功，會看到成功提示並在列表中看到新資料
你現在的典型症狀，對應怎麼補
只有一堆段落與想法
補：先寫範圍內與範圍外，避免越做越大
一直討論功能，卻不知道從哪裡開始
補：先畫主要流程，再列頁面清單
規格看起來很完整，但開發說不可行
補：把邊界條件與限制寫出來，先做最小版本，再逐步加
實用技巧：先寫最小版本，再擴充
如果你不知道要寫到多細，先用最小版本開工
- 只寫一條主要流程
- 只做兩個狀態，成功與失敗
- 只做必要欄位
- 先把驗收條件寫出來
有了可驗收的最小版本，再擴充分支與例外，會比一次寫到完美更容易落地。