提示詞寫法

你是 Copilot 提示工程顧問。

【角色】
Copilot 提示工程顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。

【輸入】
- 我常問的任務型別：___
- 現在結果哪裡不滿意：___
- 能提供的上下文：___
- 期望的輸出形態：___
- 經驗水平：___

【工作流程】
1. 診斷我提問的問題
2. 給上下文先行的寫法
3. 把大任務拆小
4. 給可複用的提問模板
5. 給驗證

【輸出規範】
▌一、問題診斷
▌二、上下文先行寫法
▌三、任務拆解
▌四、提問模板 + 驗證

【硬約束】
- 先給上下文再提要求
- 大任務拆小，不一次問全
- 結果按預期形態核驗
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或許可權一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

Prompt 不是越長越好，而是要讓 Copilot 明確知道：你要什麼、它能看什麼、不能碰什麼、怎麼判斷完成。GitHub 官方 prompt engineering 頁給出的策略可以收斂成一條主線：先給目標，再補上下文、例子和約束，最後迭代——這條主線對中英文 prompt 都一樣適用，但中文教學裡的示例會給出中文版。

這頁面向真實工程專案，不寫“萬能咒語”。每個 prompt 都應該能回到 diff、test、reference 或 review，而不是隻看回答是否順眼。

1. 官方策略地圖

GitHub 官方頁面列出的核心策略包括：

• Start general, then get specific：先給總體目標，再列具體要求。
• Give examples：給輸入、輸出、實現風格或測試示例。
• Break complex tasks into simpler tasks：複雜任務拆成小任務逐步完成。
• Avoid ambiguity：不要用含混的 “this”；明確函式、檔案或上一次回答。
• Indicate relevant code：開啟相關檔案、選中程式碼，或用 @workspace、@project 等上下文入口。
• Experiment and iterate：結果不對就迭代，不要把第一版當終稿。
• Keep history relevant：新任務開新 thread，刪除無關歷史。
• Follow good coding practices：程式碼本身要清晰、有測試、有一致風格。

flowchart TD
    Goal["總體目標"] --> Details["具體要求"]
    Details --> Context["相關程式碼 / 檔案 / 選區"]
    Context --> Examples["輸入輸出 / 測試 / 示例"]
    Examples --> Constraints["邊界 / 禁止事項"]
    Constraints --> Review["驗收標準"]
    Review --> Iterate{"結果是否滿足?"}
    Iterate -->|否| Refine["補上下文或縮小任務"]
    Refine --> Context
    Iterate -->|是| Apply["進入 diff / test / review"]

    style Context fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Review fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. 一個可用結構

推薦把工程 prompt 寫成 5 塊：

目標：
修復登入失敗時的錯誤提示

上下文：
只看 auth 模組和目前測試

限制：
不要改資料庫 schema
不要新增依賴

輸出：
先給計劃
再改程式碼

驗收：
執行 auth 測試
說明 diff 摘要

這不是固定模板，而是檢查清單。缺一塊時，Copilot 可能仍會回答，但你會更難判斷它為什麼這樣回答。

3. 例子和測試是高質量上下文

官方頁面強調 examples。工程裡最有價值的例子通常不是自然語言，而是：

• 現有相似函式。
• 現有測試風格。
• 輸入輸出樣例。
• 錯誤堆疊中最小必要片段。
• API contract 或 schema 摘要。
• 你希望保留的命名和錯誤處理方式。

單元測試也可以反過來當例子：先讓 Copilot 寫測試，再讓它按測試實現。這樣輸出會更容易驗收。

4. 複雜任務先拆

不要讓 Copilot 一口氣“重構整個系統”。官方建議把複雜任務拆成小任務。商業專案裡可以這樣拆：

1. 先讓它解釋目前模組職責。
2. 再讓它找測試入口和風險點。
3. 再讓它給 plan，不改檔案。
4. 再讓它只改一個小範圍。
5. 最後執行測試並總結 diff。

如果任務已經超過 Chat 能安全完成的範圍，切到 Plan mode 或 Agent mode，但仍然保留同樣的邊界和驗收。

5. 避免含混詞

低質量 prompt：

這段程式碼做什麼？

更穩的 prompt：

解釋 src/auth/user.ts 裡的 createUser 函式。
重點說明：
1. 它的輸入引數和返回值
2. 它會產生哪些副作用（資料庫寫入、外部 API 呼叫等）
3. 修改時我應該執行哪些測試

“this”“that”“最佳化一下”“修一下”都會讓 Copilot 猜上下文。能命名函式就命名函式，能給檔案就給檔案，能貼錯誤就貼最小錯誤。

6. 保持歷史乾淨

Copilot Chat 會使用 chat history 作為上下文。歷史上下文越亂，回答越可能把舊任務、舊約束或舊檔案帶進來。

建議：

• 新任務開新 thread。
• 同一 thread 只保留同一問題鏈。
• 失敗的 prompt 不要無限堆疊，必要時重新開始。
• 不要在同一 conversation 裡混用無關專案。

本章自檢

完成本章後，用這 4 個問題檢查：

1. Prompt 是否有明確目標，而不是一句泛泛請求？
2. 是否給了必要程式碼、檔案、選區、錯誤或測試上下文？
3. 是否寫了邊界：不能改哪裡、不能新增什麼、不能執行什麼？
4. 是否寫了驗收：diff、測試、型別檢查、引用或 PR review？

透過標準：別人看到你的 prompt，也能判斷 Copilot 的輸出該如何驗收。

官方來源

• Prompt engineering for GitHub Copilot Chat —— 官方 prompting 策略頁，覆蓋目標、例子、拆解、消歧、上下文、迭代和歷史管理。
• Asking GitHub Copilot questions in your IDE —— 官方 IDE Chat 頁面，用於核對 @、/、#、Plan mode 和 Agent mode。
• Responsible use of GitHub Copilot Chat in your IDE —— 官方 responsible use 頁面，用於核對輸出審查風險。

接下來去哪