前兩天先確定了系列目標,也整理了 ChatGPT 和 Codex 在開發流程中的分工。
接下來要正式聊 Prompt。
如果想請 AI 幫忙做網站,最直覺的說法可能是:
幫我寫一個網站。
這句話有錯嗎?其實沒有。
如果只是想看看 AI 會做出什麼,這樣的短 Prompt 完全可以使用。但如果我心裡已經期待某一種網站、某一套技術和某些功能,卻只提供這一句話,最後得到不符合需求的結果也不意外。
看到「幫我寫一個網站」時,AI 還不知道:
AI 必須選擇一種方式繼續:向我追問,或根據常見情境自行補上答案。
如果它選擇追問,我還是需要把缺少的資訊補回去;如果它直接動手,那些沒有經過確認的決定就會變成隱藏假設。
例如,它可能自行決定使用 React、產生一個 Todo List、把資料放在記憶體,並套用一套自己選擇的畫面風格。結果看起來很完整,但那些選擇不一定是我要的。
先從最模糊的版本開始:
幫我寫一個任務管理網站。
這個版本給 AI 很大的發揮空間,所以可能很適合快速看概念。但它不適合直接拿來當開發規格,因為沒有辦法分辨哪些是需求、哪些只是 AI 的猜測。
接著加入技術限制:
請使用 TypeScript、React、Node.js 和 SQLite,幫我寫一個任務管理網站。
這次 AI 不需要猜測主要技術,答案應該會更接近這個系列預定的方向。
但技術棧清楚,不代表產品需求已經清楚。
它仍然不知道任務有哪些欄位、狀態如何改變、哪些資料必填、誰可以修改任務,也不知道這次究竟要完成整個網站,還是只建立第一個可執行版本。
這個版本可能產生更多程式碼,卻不一定減少返工。因為只決定了「用什麼做」,還沒有說明「要解決什麼問題」。
這個版本把目標、範圍與完成條件補進 Prompt:
我要建立一個給個人開發者使用的 Issue Tracker,讓使用者可以記錄並追蹤開發工作。
第一版只需要:
- 顯示 Issue 清單
- 新增 Issue
- 將 Issue 標記為待處理、進行中或已完成
- 重新整理頁面後保留資料
技術方向使用 TypeScript、React、Node.js 和 SQLite。
成功條件:
- Issue 標題為必填
- 新增成功後會出現在清單中
- 新增 Issue 的預設狀態為待處理
- 空白標題不會送出,畫面會顯示提示
- 核心行為要有自動化測試
目前先分析需求是否還有缺口,並提出開發階段。
不要建立專案或撰寫程式;不確定的產品規則請列為待確認,不要自行決定。
這個版本沒有把每個實作步驟都寫死,但已經提供幾個重要邊界:
AI 仍然可以指出遺漏的需求,也有空間提出開發順序;但它不必從零猜測我要做的是什麼。
| 版本 | 提供的資訊 | 適合的用途 | 主要風險 |
|---|---|---|---|
| 幫我寫一個任務管理網站 | 只有大方向 | 發想、快速看可能性 | 大量需求由 AI 猜測 |
| 指定 TypeScript、React、Node.js、SQLite | 大方向與技術棧 | 討論技術做法 | 產品範圍仍不清楚 |
| 加入使用者、範圍與成功條件 | 目標、限制與驗收方式 | 規劃可執行工作 | 仍需確認尚未決定的產品規則 |
這裡最明顯的差異,不一定是第三個版本會產生比較漂亮的答案,而是它比較容易被檢查。
第一個版本如果產生五個功能,我不知道哪幾個是必要的,第三個版本則可以逐項核對,確認 AI 的規劃有沒有涵蓋清單、狀態、資料保存、輸入驗證和測試。
AI 很擅長把答案整理得有條理。它可能會提供漂亮的目錄結構、完整的程式碼區塊,甚至順便加上深色模式。
但格式完整只代表答案看起來完整,不代表它符合真正需求。
檢查 AI 結果時,我會先問:
如果這幾個問題都答不出來,就算 AI 一次產生了很多程式碼,也不代表開發真的往前走了。
之後準備把任務交給 AI 時,我會先快速檢查:
不需要每次都寫成很長的規格,但任務越重要、修改範圍越大,這些資訊就越不能省略。
當需求沒有說清楚時,AI 只能追問或自行補上空白。它補得越完整,那些未經確認的假設也可能藏得越深。