軟體開發 Prompt：把問題說清楚，為更好的解法留空間

用 AI 開發軟體時，我會先把問題說清楚，再決定怎麼做。Prompt 寫得詳細很有幫助，但如果裡面塞滿自己偏好的技術與介面，也可能太早排除更好的方案。以下是我習慣採用的五個原則。

1. 先找已經存在的解法

通常你想做的東西，已經有人做過，或有套件能涵蓋大部分需求。我會先請 agent 看專案現況、研究現成方案，再比較適用性、維護狀況、授權與整合成本。選擇復用需要理由，決定自己重寫也一樣。

2. 詳細說明目的

描述要讓什麼事情變得可能、為什麼重要，以及如何驗收。除非已經確定某個技術決策，否則先保留作法的選擇空間。例如「使用者能接續中斷的上傳」，就比直接指定資料庫與佇列，更能讓 agent 探索適合的設計。

3. 描述使用體驗

說清楚誰會在什麼情境下使用產品、想完成什麼事，以及出錯時如何恢復。「上傳檔案後，使用者知道是否成功，失敗也能繼續處理」描述了體驗；「右上角放一顆按鈕的儀表板」則已經選定介面。如果真的已經確定要長這樣，就明確標成已確認的限制。

4. 透過提問，挑戰原本的假設

我會使用 Matt Pocock 的 grilling skill 釐清需求。下面的 Prompt 另外指定每次只問一題，提供選項、取捨與建議。前兩步保留下來的設計空間，就能在這裡找出更好的方案，減少自己的技術與介面偏好過早左右設計。在 Claude Code 裡要求使用 AskUserQuestion；其他 agent 則使用當下可用的互動工具，或直接用文字提問。

5. 把決策變成可執行的任務

需求對齊後，請 agent 將設計文件與架構決策紀錄（ADR）放進 docs/。ADR 記錄重要選擇與替代方案，task 則描述實作工作，每項都要有前置條件與驗收方式。所謂的 task dependency tree 可能有共用的前置任務，實際上適合用有向無環圖（DAG）表達，再列出可依序執行的階段。

安裝 grilling

先安裝 Node.js、npm 與 Git，再於終端機執行對應的指令。這裡透過第三方 Skills CLI，將 Matt Pocock 的 grilling skill 安裝到個人帳號。

Codex

npx skills@latest add mattpocock/skills --skill grilling --agent codex --global

Claude Code

npx skills@latest add mattpocock/skills --skill grilling --agent claude-code --global

移除 --global 就會改為安裝到目前專案。Codex 的個人技能目錄是 ~/.agents/skills/，Claude Code 則是 ~/.claude/skills/。若技能未出現，開啟新對話再試。在 Codex 使用 $grilling，在 Claude Code 使用 /grilling。

可以直接複製的通用規劃 Prompt

替換中括號後，整段貼給 agent。新產品、功能開發或既有系統調整都能使用。先透過訪談產生計畫，再另外開始執行。

請協助我規劃以下軟體開發任務，先不要實作。

希望達成的目的與原因：[描述結果]
使用者與使用體驗：[誰、情境、使用流程、成功狀態、失敗與恢復方式]
成功標準：[可觀察或驗收的結果]
限制條件：[既有系統、相容性、時間、預算、安全等]
已確認的決策與原因：[列出，沒有就寫「無」]
可以被挑戰的偏好：[選填]

1. 先調查
檢視相關專案，尋找既有實作、套件或服務。可以查詢時，請研究最新的第一手資料。比較直接復用、調整既有方案與自行開發的適用性、維護、授權和整合成本。附上來源，區分事實與假設；無法查證時，明確標示未驗證的資訊。

2. 先與我對齊，再設計
使用 grilling skill。本次任務請每次只問一題，等我回答後再繼續；先解決前置決策，再問依賴它的問題。能自行查到的事實請先查，選擇與取捨再問我。
每題提供 2–4 個有意義的選項，說明內容與取捨，標註建議選項與原因，並允許自訂回答。在 Claude Code 裡，可用時請使用 AskUserQuestion；在 Codex 或其他 agent 裡，使用當下可用的提問工具，沒有就用文字呈現同樣的選項。不要假設工具一定存在。
聚焦目的、使用體驗、範圍、失敗情境與驗收條件。除非我標註為已確認，否則不要先鎖定實作方式或介面。若可能有更好的方案，請挑戰我的偏好；若與已確認的限制衝突，請提出來。
整理共識與尚未釐清的事項，等我明確確認已達成共同理解，才開始寫計畫或實作。

3. 確認後，將計畫寫成文件
使用 docs/[task-slug]/；若專案已有文件慣例，請配合既有結構：
- design.md：問題、使用者與使用流程、目標與非目標、限制、建議方案、驗收條件、風險與驗證策略。
- adr/NNNN-short-title.md：每個重要架構決策一份 ADR，記錄背景、替代方案、決策、理由、影響與狀態，並連結設計文件。例行步驟不必硬寫成 ADR。
- tasks.md：拆成小而可獨立驗證的任務。每項包含固定 ID、範圍、前置任務（depends_on IDs）、預期產出、驗收條件、驗證步驟、狀態，以及相關設計段落／ADR 的連結。
- dependency-graph.md：以 Mermaid DAG 畫出所有任務，包含沒有相依關係的任務；另外提供文字相依清單，以及依拓撲順序分階段的執行順序。定義 A --> B 為「B 必須等 A 完成」。檢查不存在的 ID 與循環相依，標示可平行及被阻擋的任務。
確認每項驗收條件都有任務涵蓋。任務應實作已確認的設計與決策，不只是改寫 ADR。最後指出第一個可執行的任務與執行方式，先停在實作之前。

每次接續執行一個任務

檢閱文件後，每一步都可以重用這段 Prompt。所有前置任務完成，該任務才算可以開始。

請閱讀 docs/[task-slug]/design.md、adr/、tasks.md 與 dependency-graph.md。
執行 [任務 ID，或「下一個可執行的任務」]，先確認它的所有前置任務都已完成。若尚未滿足，請說明阻擋原因，並列出目前可執行的任務。
在已確認的範圍內完成這項任務，執行相關驗證，將狀態與驗證證據更新到 tasks.md。若新發現會改變設計或 ADR，請先說明影響，與我對齊後才進行該變更。
回報變更內容、驗證結果與接下來可執行的任務，先不要開始下一項。

安裝與工具參考資料

指令與工具說明查證於 2026 年 10 月 17 日。Skill 會持續更新，上方 Prompt 另行明訂了我的訪談偏好。

繼續閱讀

Unknown Known：當監控的建構速度跟不上資源創建

回到所有文章 →