提示词写法

Prompt 不是越长越好，而是要让 Copilot 明确知道：你要什么、它能看什么、不能碰什么、怎么判断完成。GitHub 官方 prompt engineering 页给出的策略可以收敛成一条主线：先给目标，再补上下文、例子和约束，最后迭代——这条主线对中英文 prompt 都一样适用，但中文教程里的示例会给出中文版。

这页面向真实工程项目，不写“万能咒语”。每个 prompt 都应该能回到 diff、test、reference 或 review，而不是只看回答是否顺眼。

阅读目标：读完本章，你应该能把一句“帮我优化一下”改成可审查、可执行、可验收的 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：代码本身要清晰、有测试、有一致风格。

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 一口气“重构整个系统”。官方建议把复杂任务拆成小任务。商业项目里可以这样拆：

先让它解释当前模块职责。
再让它找测试入口和风险点。
再让它给 plan，不改文件。
再让它只改一个小范围。
最后运行测试并总结 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 里混用无关项目。

深读：为什么 prompt 质量和代码质量互相影响

官方页面提醒：如果代码本身命名混乱、结构过长、缺测试，Copilot 更难生成好结果。Prompt 不是补偿烂上下文的万能手段。

更现实的做法是双向改进：用 Copilot 帮你补注释、拆函数、补测试，同时让代码库越来越适合 AI 和人类共同阅读。

本章自检

完成本章后，用这 4 个问题检查：

Prompt 是否有明确目标，而不是一句泛泛请求？
是否给了必要代码、文件、选区、错误或测试上下文？
是否写了边界：不能改哪里、不能新增什么、不能执行什么？
是否写了验收：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 页面，用于核对输出审查风险。

接下来去哪

响应定制

把反复出现的规则沉淀进 instructions，不要每次 prompt 重写。

VS Code Agent mode

任务需要多步骤执行时，继续学习 agent 的计划、工具和验收。

提示词写法

响应定制

VS Code Agent mode

本页目录