GitHub CEO '不改变就改行': 拥抱AI，Copilot instruction用法详解

就在最近的8月5日，从微软离开的GitHub CEO Thomas Dohmke 在X上发言提醒开发者 '拥抱AI，或者改行'。

全文较长，总结看就是'一定会发生，2-5年内大范围发生，要敢想敢冲直面挑战'，发扬革命乐观主义精神。

Thomas还专门写了一篇博客 'Developers, Reinvented' 论证这个事情。个人观点：程序员原来只是想象自己是上帝，现在就是要做上帝了。你对Agent说：'要有光'，他就会帮你在你的程序宇宙里实现。

那么，如何做一个合格的上帝？Agentic coding 是必备技能。

Agentic coding or Vibe coding or Context Engineering or Spec coding?

是的这个领域有很多名字，擅长发明厉害名字的国外专家们搞了很多概念，徒留你黑人问号在原地。

不必过于在意哪个名字应该胜出。其中的核心是，对于结构化项目，真实项目，给大模型充分合理的上下文是这个事情的关键。如果我们没有强大的如Cursor/Kiro这样的IDE支持，如何借助基本的范式提供充分的上下文？ GitHub Copilot Instruction 是一个很好的实践开端。

在官方文档 Adding repository custom instructions for GitHub Copilot 中已经一定程度说明该技术用法，同时这一技术也成为某种行业范式，你在Cursor中也能看到对自定义规则的支持， .cursor 和 .github 文件夹都是让魔法更加神奇的源头。应该说Visual Studio Code 和 GiHub Copilot 是Agentic coding 领域的绝对先驱，他们最早构建出Coding agent，也最早开源。目前市面上的主流Code Agent平台基本上都是VS Code的Fork。此外，Anthropic 也在实践上提供了一些新的范式，如MCP、CLAUDE.md和 Claude Code CLI。不过本文会从VS Code和GitHub Copilot 为主视角探讨实践。

AI Guidance for Developers

Coding with AI 中给出了一些基本的编程法则，总结如下：

具体明确：指明语言、框架、异步/同步、版本要求。
质疑验证：要求 AI 给出依据，必要时多轮追问。
角色扮演：让 AI 以 DBA、架构师或用户身份回答，获取不同视角。
Prompt 工程：一次写清楚任务和上下文，减少来回沟通。

适用场景：

集成 IDE，上下文精准，不用切换环境。
特别适合写正则、SQL 优化、代码解释、调试。
限制在编程范围，保证相关性和安全性。

然而在IDE中的应用

自定义指令 GitHub Copilot Custom instructions

什么是 Custom instructions？作用：把你的"通用规则/偏好"存成文件，自动随每次 Copilot Chat 请求发送 ，让回答更贴合你的技术栈与团队规范（比如命名、框架、审查侧重点、提交规范等）。注意：它不会影响代码补全（completions） ，只影响聊天/代理等对话式能力。在GitHub Copilot Plugin中由这个类进行实现CustomInstructionsService。

可以放在哪儿？（三种来源，可叠加）

仓库级 ：.github/copilot-instructions.md
放在工作区/仓库根目录的 .github/ 下，VS Code 会自动把内容包含进每次聊天。同一个文件还会被 Visual Studio 与 GitHub.com 识别，可以跨 IDE 复用。
任务/范围级 ：*.instructions.md
可以建多个指令文件，按语言/框架/场景拆分。支持在文件头（front-matter）里用 applyTo 指定自动生效的文件匹配 （glob），比如 **/*.ts,**/*.tsx；也可设置为 ** 表示始终包含。必要时也能在对话里手动附加某个指令文件。
设置级（特定场景） ：在 settings.json 里为代码审查、提交信息、PR 标题/描述 等场景配置专用指令（可直接写文本，或指向外部文件路径）。注意：老的 codeGeneration/testGeneration 设置 自 VS Code 1.102 起已弃用，官方建议用指令文件替代。

合并与优先级 ：可以同时使用多种方式；不存在"优先级顺序" ，因此要避免互相矛盾的规则。

文件结构与放置位置

`.instructions.md` 基本结构

yaml 复制代码

---
description: '后端安全审查指令'
applyTo: "**/*.ts,**/*.tsx"   # 或 "**" 表示总是生效
---
# 安全检查
- 首先查 SQL 注入/命令注入
- 其次查敏感信息泄露与日志打印
- 输出一个"问题清单 + 风险等级 + 修复建议"

正文支持 Markdown（标题/列表/代码块），也可引用其他指令文件（相对路径）。
创建位置：
- 工作区：默认在 .github/instructions/，可用 chat.instructionsFilesLocations 增加其它目录。
- 用户档案：存放在当前 Profile 文件夹，可用 Settings Sync 同步到多设备。

`.github/copilot-instructions.md`

写项目总纲（技术栈、目录结构、风格约定、统一输出格式等）。
空行/换行不影响解析，可按可读性随意排版。

在对话里怎么用？

自动应用 ：若 applyTo 命中当前上下文文件（或为 **），VS Code 会自动把该指令文件并入本次聊天请求。
手动附加：
- Chat 视图 → Add Context → Instructions 选择要附加的指令文件；
- 或命令面板运行 Chat: Attach Instructions。

一键生成指令文件 ：Chat 面板点 Configure Chat → Instructions → Generate instructions ，VS Code 会分析你的工作区 生成一份匹配当前实践的 .github/copilot-instructions.md，再手动微调即可。

写什么？（官方定位与典型示例）

"怎么做" 的规则（conditions / how）：编码实践、命名规则、框架偏好、评审 checklist、生成提交信息的格式等（而 "做什么" 更适合放在 Prompt 文件里）。
示例（概览/命名规范等）官方也给了样例；建议拆成短小自洽的语句，避免一条里塞过多信息。

与 Prompt Files、Chat Modes 的协同

Prompt Files ：把"任务说明（做什么）"写成可复用脚本，在其中引用指令文件，即可做到"任务脚本 + 通用规则"的组合，避免重复。
Chat Modes ：决定 能用哪些工具/以何种方式运行 ；再叠加指令文件，得到"工具边界 + 行为规则"的完整配置（模式负责"能力圈"，指令负责"做事方式"）。

五步落地法

写项目总纲 ：在 .github/copilot-instructions.md 填入技术栈、目录结构、风格规范、统一输出格式（如"PR 描述需含变更点/风险/回滚方案"）。
分场景拆指令 ：在 .github/instructions/ 下建
- security.instructions.md（安全审查）、
- tests.instructions.md（测试生成/命名/覆盖率要求）、
- docs.instructions.md（JSDoc/README 风格）、
  每个文件前加 applyTo（如 **/*.ts），或设为 ** 始终生效。
设置级专用规则 （可选）：在 settings.json 为 评审/提交/PR 配置专用指令（文本或文件路径）。示例键：
- github.copilot.chat.reviewSelection.instructions
- github.copilot.chat.commitMessageGeneration.instructions
- github.copilot.chat.pullRequestDescriptionGeneration.instructions
  （生成代码/测试的旧设置已弃用，用指令文件替代） 。
绑定工作流 ：常用 Prompt 文件（如"生成测试用例"、"安全审查"）里引用相应 *.instructions.md，一键运行就能带上规则与任务。
持续迭代 ：若发现 AI 输出跑偏，把纠偏写回指令（而不是只在聊天里临时提醒），保持可复用与可版本化（指令文件可纳入版本控制）。

避坑实战建议

短句、原子化：每条只表达一个规则；多条就多写几行，便于组合与维护。
避免外链：不要让指令去"参考某某标准链接"，直接把关键规则写清楚。
分文件组织 ：按"安全/性能/可读性/提交规范/语言特定"等拆分；必要时用 applyTo 控制作用范围。
防冲突：官方不做优先级合并，内容冲突会让模型困惑；定期 Review 指令库。
记住适用面 ：它不影响补全；若希望补全贴合规范，仍需依赖 linter/格式化/模板代码等配合。

一套可直接抄用的模板

.github/copilot-instructions.md

yaml 复制代码

# Project Overview
- Stack: Node.js 20 + TypeScript, Express, Prisma, PostgreSQL
- Structure: /src(api, services, repos), /tests, /docs

# Coding Standards
- Naming: camelCase for vars/fns; PascalCase for types/interfaces/components
- Error handling: never swallow errors; include error codes
- I18n: user-facing strings must be centralized

# Output Conventions
- PR description: key changes, risk, rollback, test plan
- Commit message: Conventional Commits (feat/fix/refactor), imperative mood

# Review Focus
- First: injection/DoS/secrets; Then: correctness; Then: performance

.github/instructions/tests.instructions.md

yaml 复制代码

---
description: '测试生成规范'
applyTo: "**/*.ts,**/*.tsx"
---
- Use Vitest; one spec per behavior; file name: <file>.spec.ts
- Arrange-Act-Assert; include edge cases and failure paths
- Snapshot only for stable structured outputs
- Prefer DI + fakes over jest.mock on deep internals

settings.json（节选）

json 复制代码

{
  "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
    { "text": "Always include risk and rollback plan." }
  ],
  "github.copilot.chat.reviewSelection.instructions": [
    { "file": ".github/instructions/security.instructions.md" },
    { "file": ".github/instructions/performance.instructions.md" }
  ]
}

（以上做法均符合官方文档的能力边界与推荐方式。）

自定义聊天模式 GitHub Copilot Custom Chat Modes

要点

文件位置 ：.github/chatmodes/*.chatmode.md
组成：
- 前置元数据 (frontmatter)：description + tools
- 主体：系统提示，定义 AI 人格和行为
应用场景：
- DBA 模式（只用数据库工具）
- 前端专家模式（只修改前端代码）
- 安全审查模式（只查漏洞）

最佳实践

总体上讲：

角色要写清，避免答非所问。
工具权限只给需要的，减少误用。
调整模式内容，确保回答专业一致。

GitHub Copilot Chat 引入了 自定义聊天模式 (Custom Chat Modes) 功能，让用户可以预先配置 AI 助手在特定角色/场景下的行为和可用工具。GitHub 内置了三种聊天模式：问答模式（Ask）、编辑模式（Edit）和代理模式（Agent）。自定义聊天模式则允许开发者自行定义第四种、第五星等模式 ，赋予 AI 特定的**"人格"和工具权限**，以更好地完成某类任务。例如，你可以创建一个"数据库管理员模式"，让 AI 扮演数据库专家，只使用数据库相关工具来协助你。通过这种方式，Copilot Chat 可以在不同情境下切换"身份"，提供更有针对性的帮助。

自定义聊天模式的关键要点：

每个自定义模式由一个 .chatmode.md 文件 定义，需放在仓库的 .github/chatmodes/ 目录下。文件由前置元数据 和主体内容两部分构成：
- 前置(frontmatter)元数据 位于文件顶部，以三短划线开头和结尾，指定模式的 描述(description) 和 工具列表(tools) 等设置。其中 description 是对该模式的简短说明，将在 UI 上显示给用户；tools 列表指定该模式下 AI 可使用的工具或工具集（例如 'codebase' 允许读代码库，'editFiles' 允许编辑文件，'runCommands' 允许执行命令等）。这一列表决定了 AI 在此模式能做什么，无法使用未列出的工具。
- 主体内容 则是实际提供给 AI 的 系统指令 ，描述 AI 在此模式下的身份、职责、知识领域等。你可以在这里详细定义 AI 的人格背景和工作范围。例如，在"数据库管理员模式"的主体中，可以写："你是一名精通 PostgreSQL 的数据库管理员，擅长...（列出任务）...。你可以使用的工具包括...。永远通过工具查询数据库，不要直接阅读代码仓库"等。主体内容越详细，AI 扮演角色就越准确。
应用场景：自定义模式非常适合没有相关领域专家时让 AI 填补。比如小团队里没有专职DBA，可以定义一个"DBA模式"，让 AI 具备 DBA 的知识和工具；或者定义"前端专家模式"，只允许其修改前端代码和使用前端相关工具；又或者"研究模式"，允许 AI 访问外部文献API来调查技术方案等。通过模式隔离，不同任务下 AI 的行为可显著优化，避免无关干扰。
使用自定义模式： 在 VS Code Copilot Chat 中，当存在自定义模式文件后，你可以通过 模式切换菜单 选择进入该模式。Copilot Chat 会读取相应 .chatmode.md，应用其中描述和工具限制，之后你在该模式下的每条对话，都带有该模式上下文。比如切换到 "DatabaseAdmin" 模式后，你问"请帮我优化这个查询"，AI 会以 DBA 角度回答并使用数据库工具 尝试查询、分析执行计划等。文章中附有示例视频展示了在安装 PostgreSQL VS Code 扩展后，AI 如何利用 pgsql_connect 和 pgsql_query 等工具直连数据库执行优化查询的过程。
- 在 VS Code 之外的环境（如 JetBrains IDE、Visual Studio），切换模式的方式可能不同（通常也是通过聊天界面提供的模式选单）。
- 模式的组合: 其实自定义模式本质上也是预设的一组指令+工具 配置。切换模式相当于在每次对话都隐式添加了这些背景。因此，自定义模式与自定义指令 、Prompt文件可以配合使用------模式决定宏观人格和能力范围，而具体对话中仍可引入额外 prompt 内容。

示例： 文档/博文给出了 "数据库管理员"模式 的例子：

yaml 复制代码

---
description: 'Work with PostgreSQL databases using the PostgreSQL extension.'
tools: ['codebase', 'editFiles', 'githubRepo', 'runCommands', 'database', ... 'pgsql_query', ... 'pgsql_visualizeSchema']
---
# Database Administrator Chat Mode
你是一位拥有丰富 PostgreSQL 数据库管理经验的DBA...（省略若干具体职责）
你可以执行的任务包括：
- 创建和管理数据库
- 编写和优化 SQL 查询
- ...
你可以访问多种工具来操作数据库、执行查询... **务必**通过工具检查数据库，不要擅自阅读代码库。

这个模式限制 AI 只能使用 PostgreSQL 相关工具（如连接、查询、可视化schema等），并强调了它应如何行为。实际使用时，如果用户装好了 PostgreSQL 扩展（使这些工具有效），AI 切换到此模式后就能真的连接开发数据库执行查询、展示库结构等完成 DBA 工作。

对开发者的意义和最佳实践： 自定义聊天模式为 Copilot Chat 增添了 领域专家 般的灵活性。使用时建议：

明确角色定位： 在 .chatmode.md 中详细描绘 AI 角色的专业领域和边界。越具体的指导能避免 AI 越权或答非所问。例如 DBA 模式中要求"不要查看代码，只用数据库工具"，就防止了AI跑去看源码而浪费上下文。
审慎选择工具： 只赋予模式所需的工具，保证 AI 聚焦于该任务。比如 DBA 模式禁用了代码浏览工具，只给数据库相关的。这既提高效率，也降低AI误用工具的风险。工具配置可以参考 GitHub 官方提供的可用工具列表，根据场景挑选。
逐步测试和迭代： 创建模式后，尝试几个该角色典型的问题，观察 AI 回答是否符合预期角色。如果不够"专业"或有偏差，调整 .chatmode.md 内容强化某些行为。例如如果AI给出数据库优化建议不充分，可以在描述里增加"提供执行计划分析和索引建议"等要求。
结合扩展和资源： 如果模式需要访问外部资源（如数据库、API），确保相应 VS Code 扩展或 MCP Server 已安装并连接，否则AI无法真正执行这些操作。模式文件最好在说明中提醒用户需启用哪些环境配置。
简洁描述供用户选择： description 字段会在模式列表中显示，写清模式的目的，如"PostgreSQL DBA 模式"，让团队成员容易选对模式。
数量不宜过多： 虽然你可以创建多个模式文件，但模式过多可能混淆使用。建议聚焦几个主要场景（比如前端、后端、数据库、测试等）。每个模式解决明显不同的问题，让团队形成约定，用对模式。

总而言之，Custom Chat Modes 让开发者可以预定义 Copilot 的工作方式，无需每次对话重复设定上下文，极大提升了聊天助手在专业任务上的实用性。通过合理设计模式，AI 可以像团队里的多面手，在需要时变成测试工程师、运维、架构师等不同身份，提供一致且专业的支持。

自定义提示文件 GitHub Copilot Custom Prompt Files（）

要点

文件格式 ：.prompt.md，包含可选的 frontmatter（mode、model、tools、description）和正文（提示内容）。
位置：
- 用户级：VS Code 配置目录
- 项目级：.github/prompts/
调用方式：
- Chat 输入 /文件名
- VS Code 命令面板执行
- 编辑器内点击运行

功能

保存复杂提示，形成可重复的提示库。
支持变量，如 ${selection}（代码选区）、${input:tableName}（执行时输入）。
可用于代码审查、PR 生成、组件脚手架、安全检查等。

最佳实践

总体建议：

每个 prompt 专注一个任务，保持简洁。
在正文中提供上下文或链接，增强准确性。
定义 description，方便用户挑选。
团队维护公共 prompt 仓库，统一标准。

GitHub Copilot 支持的 ** Prompt Files（提示文件** 功能允许开发者将常用的对话提示保存为文件，以便 在不同场合重复使用 。这是一种模块化、可共享的提示管理方式，帮助团队建立 可复用的 AI 提示库。通过提示文件，开发者可以减少每次从头编写长提示的麻烦，确保类似任务的 AI 交互具有一致性。Prompt 文件目前以公共预览形式提供（可能会有改动），但已展现出提高效率的潜力。

Prompt 文件的要点：

提示文件格式： 提示文件是以 .prompt.md 为扩展名的 Markdown 文件。其结构通常包括可选的元数据头 和正文内容：
- 元数据头 (Frontmatter) 用三短线括起，里面可以指定：
  - mode: 默认使用的聊天模式（ask/edit/agent 等），不设置则用当前模式。
  - model: 指定使用的 AI 模型（如 GPT-4 等），不指定则用当前选定模型。
  - tools: 在 agent 模式下可用的工具列表（类似 chatmode 文件），如果 prompt 需要用到特定工具集，可以在此声明。
  - description: 对此 prompt 的简短说明，用于在 UI 上提示用途。
    这些元数据有助于预配置 prompt 的执行环境，比如某些 prompt 需要 agent 模式 + 特定工具，就可以在头部写好。
- 正文内容 是实际的提示文案，支持 Markdown 格式，可以包括标题、项目符号、代码块等。这个内容应该描述任务本身 以及具体要求 。它可以被视为一段自包含的"对话提示"，告诉 Copilot Chat 要做什么。正文中可以引用自定义指令文件或其他 prompt 文件，以复用已有内容（例如在安全审查 prompt 中引用通用的安全指南说明）。
使用场景： Prompt 文件适合定义 特定任务 的对话模版，比如："代码审查提示"、"新组件脚手架提示"、"性能优化建议提示"、"架构设计提示"等。每个 prompt 文件相当于 封装了一段复杂指令，开发者或团队在需要时直接调用，而不必临时想出所有细节。例子：
- Pull Request 审查 Prompt: 文档中举例了一个 "列出我当前仓库中分配给我的PR并总结"的 prompt 文件。其内容包括：需要使用 GitHub MCP 工具（tools 列出了 githubRepo、list_pull_requests 等），然后正文描述了搜索仓库并列出PR、提取每个PR的详情、指出等待谁review、检查CI状态等要求。保存为 my-pull-requests.prompt.md 后，只需在聊天中运行 /my-pull-requests，Copilot Chat 就会执行这些步骤。
- React 表单组件生成 Prompt: VS Code 文档提供了另一个例子，定义 mode 为 agent、工具包括代码库读取的 prompt 来生成React表单组件。正文列出了表单的要求和参考模板路径等，用于快速创建新UI组件的代码。
- REST API 安全检查 Prompt: 另一个例子定义了 ask 模式下，不需要工具的 prompt，让AI对REST API做安全审查并输出TODO列表。这可以给开发者一个规范的安全审查输出格式（按优先级分组的issue列表）。
创建和组织 Prompt 文件：
- 工作区级 Prompt 文件： 将 .prompt.md 文件放在仓库的 .github/prompts/ 目录下（默认路径，可通过 VS Code 设置增加更多路径）。这些文件 只在该仓库/工作区内可用。适合项目特定的 prompt。
- 用户级 Prompt 文件： VS Code 用户当前Profile也有一个 prompts 存储位置。通过 VS Code 的"Prompt Files"配置界面，可以创建"User Prompt File"，这些文件保存在用户配置目录下，对该用户登录的任意仓库都可用。这适合跨项目通用的 prompt，比如常用的代码规范检查、通用脚手架等。用户Prompt文件可以利用 Settings Sync 在多台机器同步。
- VS Code 命令操作： 通过点击 Copilot Chat 面板的"齿轮"按钮并选择 "Prompt Files"，可以新建或管理 prompt 文件（或者用命令面板"Chat: New Prompt File"）。选择创建位置（工作区或用户），输入文件名，然后填写内容。要编辑已有 prompt，可再次通过配置界面或命令面板打开。
- 手动创建： 当然也可以手动在 .github/prompts 文件夹新建 .prompt.md 文件并写入内容，Copilot会自动识别。
在聊天中使用 Prompt 文件：
- 通过命令调用： 在 Chat 输入框中键入 / 会出现可用 prompt 文件列表（类似 slash 命令）。选中或直接输入 /文件名 就可运行那个 prompt。在 VS Code Chat UI，这支持在命令后追加参数 （注意：当前Copilot Prompt文件也支持参数传递------通过 ${input:变量名} 机制，下述变量部分会提到）。
- 通过命令面板： 使用 VS Code 命令面板执行"Chat: Run Prompt"，然后选择 prompt 文件，也可以触发。
- 在编辑器中运行： 打开 prompt 文件本身，点击编辑器标题处出现的"运行"按钮，可以选择在当前聊天会话运行，或新开会话运行。
- 传递参数/变量： Prompt 文件可以在正文中定义占位的变量，通过在执行时提供参数来替换。VS Code 支持 ${selection}、${file} 等预定义变量，甚至 ${input:变量名} 让用户在执行时输入值。例如，在 prompt 文件内容中放 ${selectedText}，那么在聊天中选中一段代码后运行该 prompt，它会自动替换成所选代码文本。又如 ${input:tableName:Enter table name}，在执行 prompt 时，会弹出让用户输入 tableName 的对话框。这使 prompt 文件更加灵活，如同函数参数。实际使用中，在 Chat 输入框里可以写 /promptName: var1=foo, var2=bar 来传参。
编写有效 Prompt 文件的指南：
- 聚焦一个任务： 每个 prompt 文件应解决一个相对独立的问题，不要过于笼统。比如"生成Commit消息"和"审查代码质量"应分为两个prompt，而不是一个文件做所有事。
- 提供上下文引用： Prompt内容里可以通过 Markdown 链接引用代码库中的文件或文档，例如 [设计指南](../docs/design-guide.md)，Claude Chat看到链接会尝试打开这些内容。这相当于手动提供额外上下文，有助于结果准确。也可以引用 #prompt: 另一 prompt文件或 #instructions文件的名称来嵌入其内容。
- 合适的模式和工具： 如果 prompt 需要AI实际执行文件修改或访问外部资源，应设 mode: agent 并在 tools 列入必要工具。否则AI可能不知道可以使用工具或者无法行动。反之，如果只是问答性质的prompt，用 mode: ask 限制AI别乱用工具。
- 描述和文档： 在 prompt 文件头写好 description。这样当别人（或你自己一周后）来看 prompt 列表时，一目了然知道每个 prompt 做什么。另外，考虑将团队的 prompt 文件收集在仓库，并写一份 README 解释各 prompt 用途，方便协作。
- 测试 Prompt 文件： 和写代码类似，写完 prompt 要自己试运行几次，看AI输出是否符合预期。如果总是跑偏，可能需要在 prompt 文本中加入更多指导或调整措辞。利用 Tip: 可以在 VS Code Copilot Chat 开发者工具中查看实际发送给模型的 prompt，确认格式正确。

对常见工作流程的集成： Prompt 文件和自定义指令、聊天模式共同构成 Copilot Chat 的定制化配置体系。常见工作流可以这样结合这些工具：

团队可以维护一个**"Awesome Copilot"仓库**（正如 Microsoft 发布的 Awesome GitHub Copilot Customizations），汇集大家编写的有用 prompt 文件、指令文件和聊天模式。这样每当遇到类似任务，就可直接调用已有 prompt，不断丰富社区资源。
开发流程上，Prompt 文件可以嵌入到Git hooks或CI。例如在提交代码前，自动运行"代码风格检查.prompt.md"，提醒开发者修正格式；或者在 PR 创建时，用 prompt 文件生成 PR 模板、检查漏洞等。由于 prompt 文件可通过 CLI headless 模式调用，这些都可脚本化。
在知识转移 或入职场景，prompt 文件能记录专家经验：比如"新微服务架构决策指南.prompt.md"，让新人使用时获得前人沉淀的思路，而不用手动去翻文档。
对于重复性工作（写注释、生成样板、翻译文档等），prompt 文件提供了统一规范的做法。团队达成一致后，把最佳实践写进 prompt，比每个人各自提示AI要可靠统一得多。
Copilot Chat 现在支持个人profile同步 ，意味着每个开发者常用的 prompt文件可以随VS Code账户漫游。在不同项目/设备也能调用，从而融入日常工作习惯。

**示例最佳实践：**文章和文档提供的 prompt 示例体现了一些最佳实践：

PR 列表 prompt 展示了如何组合使用多个工具完成较复杂的任务（读repo->列PR->获取每个PR详情->分析状态并给建议），提示内容按步骤列清楚，让AI逐步执行。
React 表单 prompt 则利用了仓库模板 （通过 #githubRepo 引用已有模板代码）和要求列表，确保生成代码符合项目规范。
安全审查 prompt 很简洁地利用 Markdown 列表输出TODO，限定了回答格式，使结果易于理解和执行。
这些例子共同说明：Prompt 文件应该尽量清晰地定义输入->输出的关系，让AI明白既要做什么，也要如何组织结果。必要时在 prompt 里直接给出结果格式范例（如"返回结果请以 Markdown 列表输出，每项包括..."）。

总而言之，自定义 Prompt 文件 赋予开发团队对 AI 助手的脚本化能力 。它将零散的对话技巧固化为文档，可反复执行、分享协作，这对大型项目和团队非常有价值。通过沉淀高质量 prompt，一方面新成员可以直接上手调用，节省时间；另一方面团队可以持续改进 prompt 内容，不断优化 AI 产出质量，真正把 Copilot 变成 智慧收集器 而不仅是代码自动补全工具。

GitHub CEO '不改变就改行': 拥抱AI，Copilot instruction用法详解

Agentic coding or Vibe coding or Context Engineering or Spec coding?

AI Guidance for Developers

自定义指令 GitHub Copilot Custom instructions

可以放在哪儿？（三种来源，可叠加）

文件结构与放置位置

.instructions.md 基本结构

.github/copilot-instructions.md

在对话里怎么用？

写什么？（官方定位与典型示例）

与 Prompt Files、Chat Modes 的协同

五步落地法

避坑实战建议

一套可直接抄用的模板

自定义聊天模式 GitHub Copilot Custom Chat Modes

要点

最佳实践

自定义提示文件 GitHub Copilot Custom Prompt Files（）

要点

功能

最佳实践

`.instructions.md` 基本结构

`.github/copilot-instructions.md`