昨天把「幫我寫一個網站」改寫了三次，最後一個版本明顯比較容易檢查，因為它補上了使用者、功能範圍和成功條件。

但每次寫 Prompt 都要重新想一次，很容易漏掉重要資訊。

所以今天要把一個開發任務拆成五個可以重複使用的部分：

目標：
背景：
限制：
驗收條件：
輸出格式：

這不是一個硬性規定，但我覺得拆成這幾個部分很清楚明瞭，因此這是我在這個系列中都會用來檢查 Prompt 的模板。

第一個零件：目標

目標回答的是：

我希望這次工作完成後，發生什麼改變？

例如：

目標：分析 Issue Tracker 的「新增任務」功能，找出需求缺口並整理成可討論的規格草稿。

第二個零件：背景

背景回答的是：

AI 做判斷時，需要知道哪些事情？

例如：

背景：這是一個給個人開發者使用的 Issue Tracker。第一版希望保持簡單，使用者可以記錄並追蹤自己的開發工作。目前還沒有建立 repository，也沒有程式碼。

這段背景提供了三個重要資訊：目標使用者、產品方向和目前進度。

第三個零件：限制

限制回答的是：

哪些事情這次不能做，或不能由 AI 自己決定？

例如：

限制：目前只做需求分析，不要建立專案或產生程式碼。沒有資訊可以確認的產品規則請標記為待確認，不要自行決定。

限制可以控制工作範圍，也能避免 AI 太熱心。

常見的限制包括：

• 不要修改特定檔案
• 不要加入新的套件
• 不要處理這次需求以外的重構
• 只分析，不要直接實作
• 缺少證據時不要猜測

第四個零件：驗收條件

驗收條件回答的是：

我要怎麼知道這次工作真的完成了？

例如：

驗收條件：
- 至少列出新增任務前需要確認的問題
- 每個問題都要說明為什麼會影響實作
- 將可以暫定的行為與必須由我決定的規則分開
- 不出現尚未存在的檔案或程式架構

「請詳細分析」很難驗收，因為每個人對詳細的理解不同。改成可以逐項檢查的條件，就能知道 AI 是否漏掉重要內容。

之後開始寫程式，驗收條件會更加具體，例如：

• 空白標題不能送出
• 新增成功後，Issue 會出現在清單中
• 重新整理頁面後，資料仍然存在
• 相關自動化測試通過

第五個零件：輸出格式

輸出格式回答的是：

我希望用什麼方式閱讀與使用結果？

例如：

輸出格式：使用 Markdown，分成「待確認問題」「暫定驗收條件」與「風險」三節。每項內容保持簡短。

如果下一步要把結果整理成 GitHub Issue，就可以直接要求適合貼進 Issue 的 Markdown，如果只是快速討論的話簡短條列就夠了。

把五個零件組在一起

將前面的內容合起來，就得到這次可以直接使用的 Prompt：

目標：
分析 Issue Tracker 的「新增任務」功能，找出需求缺口並整理成可討論的規格草稿。

背景：
這是一個給個人開發者使用的 Issue Tracker。第一版希望保持簡單，使用者可以記錄並追蹤自己的開發工作。目前還沒有建立 repository，也沒有程式碼。

限制：
目前只做需求分析，不要建立專案或產生程式碼。沒有資訊可以確認的產品規則請標記為待確認，不要自行決定。

驗收條件：
- 至少列出新增任務前需要確認的問題
- 每個問題都要說明為什麼會影響實作
- 將可以暫定的行為與必須由我決定的規則分開
- 不出現尚未存在的檔案或程式架構

輸出格式：
使用 Markdown，分成「待確認問題」「暫定驗收條件」與「風險」三節。每項內容保持簡短。

這段 Prompt 比一句「幫我分析新增任務」長很多，但每一段都有用途：目標說明成果、背景提供判斷依據、限制控制範圍、驗收條件協助檢查、輸出格式方便使用。

五個零件是不是都要寫？

不一定。

例如，我只是問：

SQLite 和 PostgreSQL 的主要差別是什麼？請用表格回答。

這個問題的目標與輸出格式已經很清楚，不需要硬拆成五段。

反過來說，如果我要 AI 修改多個檔案、執行指令，最後還要提供測試證據，那就值得把背景、限制和驗收條件寫清楚。

我會用三個問題判斷要寫多完整：

1. 結果不符合預期時，返工成本有多高？
2. AI 自行做出的假設，會不會改變產品或程式？
3. 完成後，需不需要交給其他人 Review？

今日小結

這五個零件不是一套保證得到完美答案的咒語，而是一份避免遺漏重要資訊的檢查表。

目標說明要去哪裡，背景提供判斷依據，限制畫出邊界，驗收條件定義完成，輸出格式讓結果容易使用。