---
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="/docs/github-copilot/official/02-code-suggestions-and-chat/response-customization" />
  <Card title="VS Code Agent mode" description="任务需要多步骤执行时，继续学习 agent 的计划、工具和验收。" href="/docs/github-copilot/official/03-vscode-agent-mode/agents-overview" />
</Cards>
