如何用 AI 規劃 Web App 專案：我們實用的 6 步提示詞鏈（從構想到工作說明書）
在最近的五個客戶專案範圍規劃中，過去需要耗費 12 到 16 小時進行探索會議的部分，現在縮減為大約 3 小時的 AI 作業加上 1 小時的人工審查。我們將整個流程放在單一個 Claude Project 中執行，以便上下文能夠連貫傳遞。但有一個陷阱？AI 每次都會在三件事上出錯。因此，我們在任何內容送交客戶之前，都加入了一道把關機制。
這就是我們實際使用的 6 步提示詞鏈、每個提示詞產生的產出物、一個完整的實作範例，以及你必須親自捕捉的失敗模式。
AI 能規劃 Web App 專案嗎？ 可以。AI 能在幾小時內（而非數天）起草完整的範圍（問題陳述、用戶故事、功能、MoSCoW 優先級以及工作說明書）。但它無法驗證該草稿。AI 會捏造需求並低估工作量，因此在簽署之前，人工把關是絕對必要的。
重點摘要
- AI 能在幾小時內（而非數天）起草完整的 Web App 範圍，但無法驗證其自身的產出。
- 這條鏈包含六個提示詞：問題、用戶故事、功能、MoSCoW 優先級、估算、工作說明書（SOW）。
- AI 會捏造整合項目並低估邊緣情況，因此務必進行人工把關。
- 使用 Claude Projects 或 ChatGPT Projects 來執行此鏈；智能體（Agents）應在範圍確認後再介入。
AI 可以在一個下午寫出你的第一份範圍草稿。但它無法告訴你什麼時候它錯了。
什麼是 AI 輔助範圍規劃（以及它「不是」什麼）？
AI 輔助範圍規劃意味著使用一系列大型語言模型（LLM）提示詞，將粗糙的構想轉化為結構化的範圍產出物：需求、用戶故事、功能清單、優先級和工作說明書。AI 負責起草和建構結構。人類仍然負責決策、與利害關係人溝通以及驗證。
那麼，AI 是在替你思考嗎？不完全是。它在 ai 需求收集 方面速度很快，這部分通常是你盯著空白頁面，試圖將「我想要一個預約應用程式」轉譯成開發人員可以報價的內容。但它不擅長分辨客戶真正需要的是什麼， versus 什麼只是聽起來合理。
AI 輔助範圍規劃 不是 以下幾點：它不是自動化的，不能取代與真實利害關係人的對話，也不能保證準確性。模型會樂於為沒人要求的功能撰寫一份自信且格式良好的規格書。
本文假設你已經了解範圍規劃流程本身。如果你想了解基礎知識，我們的逐步範圍規劃指南詳細介紹了底層的非 AI 流程、7 個步驟以及完整的範圍文件結構。在這裡，我們專注於 AI 層面：哪個提示詞、以什麼順序，以及在哪裡會出錯。
AI 範圍規劃提示詞鏈概覽
這條鏈由六個依序執行的提示詞組成，每個提示詞的輸出都會輸入到下一個提示詞中。順序為：(1) 問題與目標，(2) 用戶故事，(3) 功能清單，(4) MoSCoW 優先級排序，(5) 工作量、成本和時程估算，以及 (6) 工作說明書（SOW）草稿。在單一專案中執行它們，以便保留上下文。
有趣的地方在於：因為每個提示詞都建立在前一個的基礎上，你不需要重複解釋你的應用程式六次。當模型撰寫用戶故事時，它已經知道問題所在；當它優先排序功能時，它已經知道這些故事。
- 問題與目標： 將粗糙構想轉化為問題陳述加上 SMART 目標。
- 用戶故事： 將目標轉換為帶有驗收標準的用戶故事。
- 功能清單： 從故事中推導出具體的功能庫存。
- MoSCoW 優先級排序： 將功能分類為 Must（必須）、Should（應該）、Could（可以）、Won't（不會）。
- 估算： 產生工作量、成本範圍和時程。
- SOW 草稿： 將所有內容組裝成工作說明書。
這也是一套乾淨的通用 ai 專案管理提示詞，但我們已針對 Web App 特別調整了每個提示詞（技術堆疊、整合、邊緣情況）。這種調整正是將可用範圍與通用範圍區分開來的關鍵。
秘訣不在於一個神奇的提示詞。而在於六個相互傳遞輸出的提示詞。
如何一步步執行這條鏈？
你在單一 Claude Project 或 ChatGPT Project 中由上而下執行這條鏈，依序貼上每個提示詞，並讓先前的答案保留在上下文中。以下是六個簡單步驟及我們使用的確切提示詞。每個步驟都特意針對 Web App，因為通用的商業分析提示詞會產生通用的範圍。
開始前請注意：用你自己的細節替換括號中的佔位符，並且永遠不要接受第一次輸出作為最終結果。專業的做法是閱讀每個結果，修正它，然後執行下一個提示詞。
提示詞 1：問題陳述與目標
You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].
Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.這會產生你的概述和目標章節。專業提示：「3 個假設」這一行發揮了重要作用。它揭示了 AI 否則會掩蓋的缺口。
提示詞 2：用戶故事
Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.你現在有了功能需求。這是一個乾淨的 ai 用戶故事生成器 步驟。注意事項：它傾向於忘記管理員和邊緣情況角色，所以再次提示它「現在為管理員、付款失敗和空狀態添加故事」。
提示詞 3：功能清單
Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.這是你的範圍內功能候選清單。密切關注此步驟，因為這是 AI 開始捏造整合項目的地方（稍後詳述）。
提示詞 4：MoSCoW 優先級排序
Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."這會標記你的範圍內和範圍外項目。「毫不留情」的指示很重要；沒有它，模型幾乎會將所有内容標記為 Must（必須）。
提示詞 5：工作量、成本與時程估算
Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.這是你的 ai 工作說明書生成器 用於預算和時程的輸入。始終要求一個範圍和假設，因為單一自信的數字是 AI 給你最危險的輸出。
提示詞 6：SOW 草稿
Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].[REVIEW] 標籤成為你的人類把關檢查清單。此步驟組裝了整條鏈所承諾的從構想到 SOW 的過程。
提示詞 → 範圍章節對應表
每個提示詞不僅僅是回答問題，它填充了你交給客戶的文件中的特定章節。這種對應關係取代了常見的 11 節模板：你不需要記憶骨架，只需執行鏈，文件就會自行組裝。以下是哪個提示詞產生哪個交付成果。
| 提示詞 | 產生內容 | 填充的範圍文件章節 |
|---|---|---|
| 1. 問題與目標 | 問題陳述 + SMART 目標 | 概述、目標與成功指標 |
| 2. 用戶故事 | 用戶故事 + 驗收標準 | 功能需求 |
| 3. 功能清單 | 功能庫存 | 範圍內功能 |
| 4. MoSCoW | 優先排序的 Must/Should/Could/Won't | 範圍內（已標記）+ 範圍外 |
| 5. 估算 | 工作量、成本範圍、時程 | 時程、預算範圍 |
| 6. SOW 草稿 | 組裝後的工作說明書 | 完整 SOW + 交付成果 + 簽署 |
當你完成提示詞 6 時，你擁有了一份客戶實際可以閱讀和簽署的完整初稿文件，而不是一堆分散的筆記。
每個提示詞不僅僅是回答問題。它填充了你將交給客戶的文件中的特定章節。
完整實作範例：規劃預約預約 SaaS
以下是針對一個具體案例端到端執行的鏈：小型牙科連鎖診所的預約預約 SaaS。這是一個說明性範例，並非真實客戶交付成果，是的，我們在 AI 輸出中發現了兩個錯誤，我們將在下面的人類把關章節中修正它們。
提示詞 1 輸出（問題與目標）。 問題：一家擁有三個據點的牙科連鎖診所因電話來回溝通和未到診而損失預約。目標：透過提醒減少 30% 的未到診率，讓患者線上自助預約，並讓前台員工擁有一個共享日曆。標記的假設：單一時區、僅英文、無保險計費。
提示詞 2 輸出（用戶故事範例）。
- 作為患者，我希望能在線上預約，這樣我就不必打電話。
- 作為患者，我希望收到 SMS 提醒，這樣我就不會忘記預約。
- 作為前台員工，我希望能在一個日曆中看到所有三個據點，這樣我就能管理重疊時段。
提示詞 3 輸出（功能清單，精簡版）。 線上預約、日曆同步、SMS 和電子郵件提醒、患者帳戶、多據點管理、基本報表，以及付款步驟（最後一項是捏造的；沒人要求它）。
提示詞 4 輸出（MoSCoW 網格）。
| 優先級 | 功能 |
|---|---|
| Must (必須) | 線上預約、多據點日曆、SMS 提醒、患者帳戶 |
| Should (應該) | 電子郵件提醒、基本報表 |
| Could (可以) | 患者自助重新預約 |
| Won't (v1 不會) | 付款、保險計費、原生移動應用程式 |
提示詞 5 輸出（估算，精簡版）。 假設使用 Next.js、Supabase 和 Twilio，配備兩名開發人員：Must-have 功能大約需要 45 到 60 個開發人天，成本範圍約為 $35K 到 $55K，時程為 8 到 10 週。標記風險最高的估算：多據點日曆邏輯。
提示詞 6 輸出（SOW 摘錄）。 「範圍內：線上預約、多據點共享日曆、SMS 提醒（Twilio）、患者帳戶。範圍外：付款、保險、原生移動應用。時程：8-10 週。預算範圍：$35K-$55K。[REVIEW] 與客戶確認使用 Twilio 還是替代 SMS 供應商。」
瀏覽一下，你可以看到一份真實、可簽署的範圍在一次坐席中就成形了。如果你計劃稍後添加智能功能，我們的為你的應用程式添加 AI 功能指南將從此處接續。
如何用 AI 估算成本和時程？
你提示模型按功能以天為單位分解估算，假設特定的技術堆疊，聲明每個假設，並返回一個範圍而非單一數字。然後，根據已知的市場分級對該範圍進行健全性檢查，因為 AI 幾乎總是在工作量上過於樂觀地錨定。
將 AI 估算視為起點，絕非報價。最有用的單一指令是「標記三個風險最高的估算」，這告訴你需要在哪裡投入自己的判斷力。以下是我們檢查每個 AI 估算的分級。
| Web App 複雜度 | 典型成本範圍 | 典型時程 |
|---|---|---|
| 簡單 MVP | $10K-$50K | 1-3 個月 |
| 中等（認證、付款、儀表板） | $50K-$100K | 3-6 個月 |
| 複雜（多角色、整合、擴展性） | $75K-$150K+ | 6-12 個月 |
這些範圍與發布的代理商和市場基準相符；Clutch 的應用程式開發成本研究是一個合理的公共參考點。如果你的 AI 估算遠低於相關分級，它可能忽略了邊緣情況。這也是詢問更大問題的时刻：自建 vs 購買。超出複雜分級的範圍有時主張購買而非自建。
每項工作該使用哪種 AI 工具？
對於完整鏈，使用 Claude Projects 或 ChatGPT Projects，因為兩者都能在提示詞之間保留上下文，使輸出能夠無需重新貼上而繼續傳遞。僅在範圍簽署後且你正在生成可重複使用的產出物時，才使用獨立智能體。對於一次性範圍規劃，Projects 每次都勝過智能體。
我們在 Claude Projects 中運行長上下文步驟（用戶故事、SOW 組裝），並在想要對估算獲得第二意見時使用 ChatGPT。根據 Anthropic 的 Projects 文件，Project 會在對話中保持共享上下文和指令，這正是六步 claude projects 用於需求分析 工作流程所需要的。OpenAI 的 Projects 也以相同方式運作，適用於 chatgpt prompts 軟體開發。
一個值得借鑑的技巧：每步分割 AI 的角色。告訴它「扮演產品經理」來處理用戶故事，並「扮演資深工程師」來處理估算。角色切換會改變其推理方式，且工程師角色在工作量上明顯更為保守。
一旦範圍發布並開始建置，工具問題就轉向 AI 編碼智能體，這完全是另一個決策。
AI 在哪裡會搞錯範圍規劃？人類驗證把關
AI 以可預測的方式搞錯範圍規劃：它幻想出沒人要求的整合項目，低估邊緣情況和錯誤狀態，並且要么捏造合規要求，要么悄悄遺漏真實的要求。它也將成本估算錨定得過於樂觀。這些都不罕見；它們幾乎在每次運行中都會發生，這就是為什麼人類把關是不可協商的。
無論是由人類還是模型撰寫，糟糕的需求都是昂貴的。PMI 的職業脈搏研究發現，不準確的需求收集是大約 37% 失敗專案的主要原因，因此把關的重點是在這些缺失到達報價之前捕捉它們，而不是之後。
解決方案是人類在任何範圍到達客戶之前運行的簡短檢查清單：
- 刪除捏造的功能： 移除客戶從未要求的任何內容（付款、匯出、整合）。
- 添加缺失的邊緣情況： 付款失敗、空狀態、權限、錯誤處理。
- 驗證每個整合： 確認每個命名的第三方服務是真實的、必要的且已編列預算。
- 檢查合規聲明： 確認或修正 AI 聲稱的任何認證、隱私或監管要求。
- 緩衝估算： 根據你自己的速度調整樂觀的數字，特別是標記為高風險的數字。
AI 會自信地規劃它捏造的付款流程。你的工作是刪除沒人要求的部分。
我們在真實客戶範圍規劃中運行此流程的收穫
在我們最近的幾個客戶範圍規劃中，過去需要大約 12 到 16 小時會議和撰寫的探索過程，現在大約在 2 到 3 小時的 AI 作業加上 1 小時的人工審查後就能產生初稿 SOW。這些是我們自己運行的誠實範圍，並非精確的標題統計數據，而那個人工小時是我們永遠不會削減的。
我們在 Claude Projects 中運行這條鏈，並使用 ChatGPT 作為估算的健全性檢查。節省的時間是真實的，但價值在於每次都捕捉相同的三個失敗：
- 它捏造整合。 牙科範例中沒人要求的付款步驟。幾乎每個範圍都至少有一個幻影功能。
- 它低估邊緣情況。 錯誤狀態、空狀態和管理員流程 consistently 缺失或被低估，這正是真實預算膨脹的地方。
- 它錯誤處理合規和認證。 有時它幻出一個要求，有時它遺漏一個真實的要求。我們在這方面從不信任它。
因此，我們將上述人類把關添加為固定步驟。鏈快速撰寫草稿；把關使其發送變得安全。跳過把關，你只是在發送一個自信、格式良好的猜測。
Techsy 如何進行 AI 輔助範圍規劃
這條鏈加上人類把關正是我們為建置 Web App 的客戶運行的工作流程。我們用 AI 快速起草，然後由一位有實際建置經驗的人員在每一行成為報價之前進行驗證。如果你願意將範圍規劃交給每天這樣做的團隊，這就是我們所做的。你可以獲得一份站得住腳的 SOW，而無需先支付兩週的探索會議費用。
關於作者
Mert Batur Gurbuz 是 Techsy.io 的聯合創始人，該團隊為 B2B 客戶交付 AI 智能體、自動化系統和語音/SDR 管道。他就讀於伯明翰大學，並撰寫關於 Techsy 團隊在生產環境中實際使用的 LLM 工具堆疊的文章。
聯合創始人，Techsy.io — 伯明翰大學。在 LinkedIn 上聯繫。
常見問題
AI 能撰寫專案範圍或工作說明書（SOW）嗎？
是的，AI 可以起草完整的專案範圍或工作說明書，包括問題、用戶故事、功能、優先級、時程和預算範圍。在 Claude 或 ChatGPT Project 中運行六步提示詞鏈。該草稿作為起點是可靠的，但在簽署之前必須由人類驗證。
規劃軟體專案的最佳 AI 工具是什麼？
Claude Projects 和 ChatGPT Projects 是規劃的最佳工具，因為兩者都能在提示詞鏈中保留上下文，使每個輸出都能饋送至下一個。我們使用 Claude Projects 處理長上下文步驟，如用戶故事和 SOW 組裝，並使用 ChatGPT 作為估算的第二意見。智能體更適合範圍後的建置工作。
如何使用 ChatGPT 或 Claude 收集需求？
依序運行提示詞鏈：要求問題陳述和目標，然後是具有驗收標準的用戶故事，接著是功能清單，然後是 MoSCoW 優先級。將所有内容保持在單一 Project 中，以便上下文繼續傳遞。每個提示詞的輸出成為下一個的輸入，這使得 AI 需求收集變得快速。
AI 能估算軟體專案成本和時程嗎？
是的，僅作為起點。提示模型按功能以天為單位分解估算，假設特定堆疊，聲明其假設，並返回一個範圍。然後根據市場分級進行健全性檢查：簡單 MVP 為 $10K-$50K，複雜應用程式高達 $150K+。AI 傾向於過於樂觀地錨定。
AI 生成的範圍真的可靠嗎？
作為初稿可靠，但不適合作為簽署依據。AI 能快速產生結構良好的範圍，但它幾乎在每次運行中都會捏造整合、低估邊緣情況並錯誤處理合規。將輸出視為快速草稿，然後運行人類驗證把關，在任何人簽署之前刪除捏造的功能並添加缺失的邊緣情況。
如何用 AI 將粗糙構想轉化為規格？
從提示詞 1 開始：將你的構想貼上兩到四句話，並要求 AI 撰寫問題陳述、SMART 目標及其做出的假設。然後依序運行接下來的五個提示詞。到提示詞 6 時，你將擁有草稿 SOW。整條鏈只需幾小時而非數天。
AI 輔助範圍規劃會取代探索階段嗎？
不，它壓縮了探索而非取代它。你仍然需要與真實利害關係人對話，以了解客戶真正想要什麼。AI 處理起草和建構結構，在幾小時內將你的筆記轉化為需求和 SOW。人類仍然負責驗證、優先排序並對範圍做出最終決定。
用 AI 規劃 Web App 需要多長時間？
根據我們的經驗，初稿 SOW 大約需要 2 到 3 小時的 AI 作業加上約 1 小時的人工審查，相比之下，手動探索和撰寫需要 12 到 16 小時。AI 時間很快；審查小時是不可協商的，因為這是你捕捉 AI 捏造的功能和它遺漏的邊緣情況的地方。