---
title: "提示詞寫法"
description: "把 GitHub Copilot Chat 提示詞拆成目標、上下文、例子、約束、迭代和驗收標準。"
verifiedAt: "2026-05-06"
---

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

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

> [!TIP]
> **閱讀目標**：讀完本章，你應該能把一句“幫我最佳化一下”改成可審查、可執行、可驗收的 Copilot prompt。

## 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**：程式碼本身要清晰、有測試、有一致風格。

```mermaid
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 塊：

```text
目标：
修复登录失败时的错误提示

上下文：
只看 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：

```text
这段代码做什么？
```

更穩的 prompt：

```text
解释 src/auth/user.ts 里的 createUser 函数。
重点说明：
1. 它的输入参数和返回值
2. 它会产生哪些副作用（数据库写入、外部 API 调用等）
3. 修改时我应该运行哪些测试
```

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

## 6. 保持歷史乾淨

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

建議：

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

<details>
<summary>深讀：為什麼 prompt 質量和程式碼質量互相影響</summary>

官方頁面提醒：如果程式碼本身命名混亂、結構過長、缺測試，Copilot 更難生成好結果。Prompt 不是補償爛上下文的萬能手段。

更現實的做法是雙向改進：用 Copilot 幫你補註釋、拆函式、補測試，同時讓程式碼庫越來越適合 AI 和人類共同閱讀。
</details>

## 本章自檢

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

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

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

## 官方來源

- [Prompt engineering for GitHub Copilot Chat](https://docs.github.com/en/copilot/concepts/prompting/prompt-engineering) —— 官方 prompting 策略頁，覆蓋目標、例子、拆解、消歧、上下文、迭代和歷史管理。
- [Asking GitHub Copilot questions in your IDE](https://docs.github.com/en/copilot/how-tos/chat-with-copilot/chat-in-ide) —— 官方 IDE Chat 頁面，用於核對 `@`、`/`、`#`、Plan mode 和 Agent mode。
- [Responsible use of GitHub Copilot Chat in your IDE](https://docs.github.com/en/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-chat-in-your-ide) —— 官方 responsible use 頁面，用於核對輸出審查風險。

## 接下來去哪

<Cards>
  <Card title="響應定製" description="把反覆出現的規則沉澱進 instructions，不要每次 prompt 重寫。" href="/zh-Hant/docs/github-copilot/official/02-code-suggestions-and-chat/response-customization" />
  <Card title="VS Code Agent mode" description="任務需要多步驟執行時，繼續學習 agent 的計劃、工具和驗收。" href="/zh-Hant/docs/github-copilot/official/03-vscode-agent-mode/agents-overview" />
</Cards>
