[写在前面]

由于Copilot更新换代速度很快，文章描述功能或者UI位置会和新版本有所差异，但是基础使用（新能力除外）上相信大差不差，相信能一定程度的帮助到有需要的人。

安装篇

安装插件

• 在 IDEA 的 Plugins 市场中搜索 GitHub Copilot，安装并重启编辑器。

• 登录你的 GitHub 账号并完成 Copilot 订阅授权。

模式认知篇

相信大家第一次打开UI，看到

什么是Agent、Ask、Plan，一脸懵逼，大家都有相同的困惑，于是我查阅了相关资料进行验证后，发现一个网友的总结用“吃饭”来总结贴切又合适，分享给大家：

ASK-看菜谱-耐心导师:

像看菜谱一样查技术问题

• 核心比喻

就像想做番茄炒蛋时搜菜谱、问老师傅，Ask 模式是让 AI 充当耐心的技术导师：

• 你提出问题（比如「这段代码是干嘛的？」「Python 的列表推导式怎么写？」），AI 会像百科全书一样，给出答案、示例代码和原理解释，不会修改你的任何代码。

• 可以反复提问、追问细节，AI 始终保持耐心。

• 适合场景

  场景类型	示例指令
  学习新技术	这个框架怎么用？
  理解代码	这函数啥意思？
  技术方案讨论	用 React 还是 Vue 好？

• 关键原则

只回答不动手，像个耐心的导师，控制权100%在你手里：

• 完全安全：不会误改代码，适合学习、调研、解惑阶段。

• 无压力提问：可以反复追问，直到完全理解。

• 适合作为技术学习和决策的辅助工具，而非直接执行开发。

Agent-请私厨-全程代劳：

请个私厨帮你搞定复杂开发任务

• 核心比喻

就像想吃川菜时请私厨上门做一桌菜，Agent 模式是让 AI 自主处理复杂、多步骤的开发任务：

• 你只需提出宏观需求（比如「帮我搭个博客项目」「把 React 应用迁移到 Vue」）。

• AI 会自动拆解任务、分析代码、创建文件、运行测试、修复 Bug，中间可能会和你确认细节（如「要不要加评论功能？」），但大部分工作自主完成。

• 适合场景

  场景类型	示例指令
  从零搭建项目	创建一个 Todo 应用
  大规模重构	把所有 API 改成 RESTful 风格
  复杂自动化任务	写单元测试覆盖所有函数

• 关键原则

半自动驾驶，它干活你监督，随时可以叫停：

• AI 负责执行复杂流程，你负责把控方向和验收结果。

• 过程中可随时干预、调整需求或终止任务，避免偏离预期。

• 适合处理需要多步骤协作的工程性任务，解放你的重复劳动。

PLAN-列菜单-搞定规划

先列菜单再动手

• 核心比喻

就像请客前先规划凉菜、热菜和烹饪顺序，Plan 模式强调先规划后执行：

• 你提出复杂需求（如「实现一个用户认证系统」），AI 不会立刻写代码，而是先输出一份详细计划：包含所需文件、实现步骤、每步任务及潜在风险。

• 你确认计划可行后，AI 才会开始执行开发流程。

• 适合场景

场景类型	示例指令
复杂功能实现	实现支付系统
需要讨论的重大任务	重构整个数据库层
多人协作场景	给团队看看这个方案行不行

• 关键原则

先计划后动手，你批准了再开工：

• 把风险前置，通过计划提前发现问题、对齐目标，避免盲目开发导致返工。

• 计划可用于团队讨论，让所有人对任务范围和路径达成共识。

• 控制权在你：计划不合理可以随时修改，确认后再进入执行阶段。

• 注意事项

该模式目前仅在最新版 VS Code 中可用，使用前需确保编辑器已更新。

一张表总结

模式	核心定位	比喻
Ask 模式	答疑解惑、学习	看菜谱/问老师傅
Agent 模式	自主完成复杂任务	请客前列菜单
Plan 模式	先规划后执行	请私厨做一桌菜

基础功能篇

相信大家用过其它AI辅助编程工具的都用过这些功能，这些功能集合直接上干货：

与AI聊天基础功能TIPS:

• 行内聊天框

  • 通过 Ctrl+I 快捷键启动

  • 可以使用诸如 /fix /doc 等命令

  • 也可以了在命令行启动，让 Copilot 提供命令建议。

  • 比如查找端口占用，adb 列出设备列表。

• 聊天界面

  • 快捷键 Ctrl+Shift+I 启动

  • 聊天界面除了常规的使用自然语言获取帮助外，还可以使用固定的元素。

  • @参与者（participants）

    • workspace，以整个工程作为上下文

    • vscode，关于 vscode 本身的问题

  • #变量（Variables）

    • editor 编辑内的内容

    • file 添加文件

  • ▪️/命令（Commands）

  • new 新建工程或文件

  • test 创建测试

代码自动提示补全

• 核心机制：

  • Copilot 会实时分析你正在编写的代码上下文，自动给出语法、逻辑和结构的补全建议，无需额外操作。

• 常见补全类型：

  • 函数提示补全：输入函数名或部分逻辑，自动补全函数定义、参数和基础实现。

  • 语句提示补全：根据当前语法环境，补全循环、条件判断、变量赋值等语句。

  • 类提示补全：自动补全类的属性、方法及继承关系。

  • 块提示补全：识别代码块（如循环体、函数体），补全完整逻辑。

  • 模块路径补全：在导入模块时，自动提示可用的包路径与文件。

• 示例演示：

自动生成测试

• 可以基于你编写的业务代码，自动生成对应的单元测试、集成测试代码，大幅节省编写测试用例的时间。

• 操作快捷键： Control + Enter （Windows/Linux）/ Command + Enter （Mac），可快速查看并选择 Copilot 提供的多种代码建议。

帮助理解代码

• 针对复杂、陌生或遗留代码，可直接将代码片段交给 Copilot，让其解释代码逻辑、功能用途、设计思路，帮助你快速读懂代码。

帮助生成代码注释

• 对于不想手动编写注释的场景，Copilot 能自动生成规范的代码注释（如单行注释、文档注释），清晰说明代码的功能、参数和返回值，提升代码可读性。

• 示例：
  

帮助优化代码

• 核心场景：

  • 当代码功能已实现，但写法不够简洁、优雅，或变量/函数命名不规范时，Copilot 可提供优化方案。

• 优化范围：

  • 提供更高效的算法或实现逻辑，简化冗余代码。

  • 建议更具语义化的变量名、函数名，提升代码可读性。

  • 优化代码结构，使其更符合设计模式与工程规范。

  • 使用方式：选中待优化代码，通过 Copilot 交互面板发起优化请求。

帮助生成 commit message

• 核心场景：

  • 在 Git 提交代码时，自动生成规范、清晰的 commit 信息，避免描述模糊或格式混乱。

TIPS:

结合git使用，可以规避代码被误修订，而不能找回的问题，使用有奇效，非常推荐。

提示词使用篇

现阶段的AI工具，在我看来，我们作为使用者，不是应该让它一下子就听懂我们话，秒懂我们的需求，我们更应该是作为一个沟通者，去理解AI需要什么内容。一个合格的沟通者，在介绍需求时，应该沟通清楚背景、明确目标、解释需求细节、确定交付要求、可提供的支持、风险预案等。我们在和AI沟通的时候，也需要尽可能明细的沟通这些内容。

给 AI 喂足上下文

• 要点1：打开相关文件

  • 操作：在编辑器中打开和当前任务相关的文件（比如 CSS 样式文件、API 接口定义文件）。

  • 目的：让 AI 能读取到项目的现有风格、接口规范和依赖关系，生成的代码能和已有代码保持一致，避免风格冲突或接口不兼容。

  • 例子：写新页面组件时，打开同模块的 CSS 和 API 类型定义文件，AI 会复用相同的类名和接口结构。

• 要点2：起个好名字

  • 操作：给函数、变量、类起语义清晰、意图明确的名字。

  • 目的：名字是 AI 理解你需求的关键，越具体的名字（比如 calculateUserAge 而非 calc ），AI 越能精准生成符合逻辑的实现。

  • 原则：函数名要能体现「做什么」，变量名要能体现「存什么」。

• 要点3：顶级注释

  • 操作：在文件/函数开头写顶层注释，明确说明：

  • Purpose: 这段代码的核心目的

  • Tone: 代码风格（如简洁、严谨、友好）

  • 额外约束（如性能要求、兼容版本）

  • 目的：先给 AI 定好「调子」，相当于提前写好需求文档，让它从一开始就理解你的设计意图和编码风格。

用样板码引导 AI（Few-shot 学习）

• 原理卡

  • 核心原理：AI 会通过你提供的最新样板代码，学习当前项目的代码风格、库版本和实现模式，从而生成高度一致的新代码。

  • 本质：这是「小样本学习（Few-shot Learning）」在代码场景的应用，用少量示例教会 AI 你的编码偏好。

• 操作卡

  • 先贴样板：在当前编辑区粘贴一段最新、最规范的样板代码（比如同模块的已有函数、组件实现）。

  • 精确新代码：在样板码之后，写下你要实现的新代码的开头或注释，让 AI 基于样板风格生成后续内容。

  • 事后清理：AI 生成符合要求的代码后，删掉之前粘贴的样板码，保持代码整洁。

• 实用提示

  • 样板码要精简且典型：只保留核心逻辑和风格特征，避免冗余信息干扰 AI。

  • 优先贴同模块、同功能的代码：让 AI 更容易理解上下文和实现模式。

  • 适合场景：重构旧代码、开发新功能、统一团队代码风格。

魔法符号 # ：让 AI 精准理解你的需求

• 指令 作用 场景示例

  • #file 直接将指定文件的内容喂给 AI，让它基于该文件分析/生成代码 让 AI 基于 test.c 写单元测试；解释 utils.js 里的工具函数逻辑

- \#codebase  在整个代码库中全局检索，帮你定位未知文件或相关代码 想找“处理支付的代码”但不知道文件名；让 AI 梳理项目中所有和登录相关的逻辑

- \#terminal  让 AI 读取终端最后一段报错信息，直接分析并修复 Bug 运行代码后抛出异常，复制报错后用  \#terminal  让 AI 秒级定位问题并给出修复方案 

• 核心价值

  • 精准点菜：不用再用自然语言反复描述“我要哪个文件/哪段代码”，直接用 # 指令锚定目标。

  • 降低沟通成本：AI 能直接获取真实的代码/报错上下文，避免信息传递偏差，输出更贴合需求的结果。

  • 高效排错： #terminal 让 AI 直接对接报错信息，实现“一键修 Bug”。

• 注意事项

  • 这类 # 指令是部分代码编辑器（如 vscode）的专属功能，并非所有 AI 工具都支持。

  • 使用时需确保工具已完成项目索引，否则 #codebase 可能无法精准检索。

别想一口气吃成胖子！

AI当前的能力，大家都是有目共睹。

• 错误示范：一次性让AI做完整App

• 表现：需求过于庞大，AI输出容易混乱、遗漏或中断，开发者也会陷入信息过载，效率低下。

• 大神示范：框架→路由→数据库，分步推进

• 表现：将复杂的App开发拆解为模块化、流程化的小任务，依次交给AI处理，逻辑更清晰，结果更稳定。

• 底部总结：任务越小，AI越稳，你的Vibe不断线。

• 本质：小步迭代是和AI协作的核心原则，把大目标拆成可执行的最小单元，能显著提升AI输出质量和开发效率。

💡 延伸建议

在实际开发中，这种“分步推进”的思路可以进一步细化：

1. 需求拆解：先让AI梳理功能清单和技术选型，再逐个实现。

2. 模块拆分：按功能模块（如登录、列表、详情）拆分任务，避免一次性处理全量代码。

3. 逐步验证：每完成一个小模块，就进行测试和反馈，及时修正问题。

调教 AI：迭代反馈的核心技巧

通过明确的指令调教 AI，让它持续输出符合你预期的代码。

1. 实用技巧

• 反馈要具体：避免模糊的“写得不好”，要像明确指出问题（比如“变量名太随意”“算法效率低”）。

• 一次只改一点：不要同时提多个修改要求，让 AI 聚焦解决单个问题，输出更稳定。

• 提供参考：如果有规范文档或样板代码，可以附上，让 AI 更精准对齐你的要求。

2. 示例

• 反馈1：别用递归，换成循环

直接指出实现方式的偏好，让 AI 调整算法逻辑，避免性能或可读性问题。

• 反馈2：变量名再高级点

引导 AI 优化命名规范，让变量名更语义化、更贴合工程风格（比如从 temp 改为 userAgeDifference ）。

• 反馈3：遵循我的编程规范

要求 AI 对齐团队或个人的编码规范（如缩进、注释格式、函数长度限制等），保证代码一致性。

进阶玩法篇

提示文件（Instructions）——仓库级、路径级、个人级

这玩意儿与大多数的AI辅助编程IDEA一样，比如Cursor的rules文件、Trea的规则文件等，Copilot把它命名成了提示文件。为了方便区分，我也同样继承使用了以下命名（个人习惯）：

仓库规则、路径规则、个人规则

以Markdown格式在该文件中添加自然语言说明。系统会忽略说明信息间的空格，因此可将信息编写为一个段落，每个段落位于一行上，或用空白行分隔，以保持其可读性。

GitHub Copilot 支持多种作用域的自定义指令（既有仓库级也有个人级），常见类型和位置如下：

1. 仓库级（Repository‑wide）

   官方说明：Adding repository custom instructions for GitHub Copilot - GitHub Docs

   在仓库中为 Copilot 编写“仓库级”提示（repository-wide custom instructions）时，请遵循短小、具备通用性的指导语句，便于 Copilot 在该仓库上下文中每次请求时使用。下面是简要步骤与建议：

   1. 文件位置与类型

      • 仓库级指令放在 .github/copilot-instructions.md（适用于多种 IDE / Copilot 功能）。

      • 如果还要使用可重用的交互式提示片段，可在工作区创建 *.prompt.md 文件。

   2. 内容结构（推荐要点）

      • 简短概述：仓库做什么、目标、主要语言/框架/运行时。

      • 构建与验证命令：bootstrap、build、test、lint、run 等的具体命令与顺序（写明必需步骤）。

      • 代码风格与约定：命名、格式化、首选工具（例如必须运行 make fmt）。

      • 仓库结构：重要目录与关键文件位置（例如 cmd/、internal/、docs/）。

      • 关键验证步骤：CI、预提交检查、任何必须通过的验证命令。

      • 限制与优先事项：哪些任务不要交给 Copilot（例如生产关键、敏感逻辑等）。

   3. 编写要点（最佳实践）

      • 保持短小、独立的语句，适用于大多数请求；避免太任务特定的指令。

      • 避免引用外部资源作为必需步骤（大仓库中易出问题）。

      • 对于 Copilot Code Review：注意 Copilot 只读取自定义指令前 4,000 个字符（超出部分不会被使用）。

      • Prompt files 可包含更长、更具体的可复用提示（用于 chat /生成场景）。

   4. 示例片段（示范性条目）

   这是一个 Go 服务仓库。构建：`make build`，测试：`make test`，格式化：`make fmt`（提交前必须运行）。
   主要目录：`cmd/`（执行入口）、`internal/`（服务逻辑）、`docs/`（文档）。
   写单元测试并使用表驱动测试风格；对公共 API 进行文档更新。
   

2. 路径/文件级（Path‑specific）

   官方说明文档：Adding custom instructions for Copilot CLI

   1. 存放位置：在仓库中创建 .github/instructions/ 目录，文件名形如 NAME.instructions.md（例如 python.instructions.md）。

   2. 必须包含前置 frontmatter 指定匹配范围，例如：

      ---
      applyTo: "**/*.py"
      ---
      

   applyTo 支持 glob 模式，决定该文件在哪些路径/文件上生效。

   3. 内容结构建议：

      1. 用短标题分段（例如 # Python Coding Conventions）

      2. 使用 bullet 列表写具体、可执行的规则（命名规则、样式、最佳实践、安全检查等）

      3. 在需要时包含短代码片段示例（正确/错误示范）

   4. 大小与可读性：

      1. 保持每个指令文件精简、聚焦；单个指令文件最好不超过 ~1000 行。

      2. Copilot code review 只读取每个自定义指令文件的前 4,000 个字符，超出部分不会被使用。

   5. 何时使用：当你需要对特定语言、框架或目录制定不同规则时，用路径/文件级指令避免把全仓库规则搞混。

• 个人/本地级（Personal / Local）

  • 官方文档：Adding custom instructions for Copilot CLI

  • 本地文件：$HOME/.copilot/copilot-instructions.md（对该用户本地 Copilot CLI 会话生效）

  • 个人设置：Copilot Chat 的个人指令也可通过 GitHub.com 的个人设置界面配置（参见自定义说明概览）

• 补充要点：

  • Copilot 在启动时会从这些默认位置加载指令；CLI 可用 --no-custom-instructions 禁用加载。

  • 若同一上下文同时存在多份指令，Copilot 会合并使用，但避免冲突（尤其是路径指令与仓库指令可能同时适用时，选择非确定性）。

  • 参考与下一步（文档）

    • 关于创建仓库自定义指令：Adding repository custom instructions for GitHub Copilot

    • 关于 Prompt files 与示例：Prompt files

    • 自定义响应概念与写作指南：About customizing GitHub Copilot responses

智能体（Agent.md）

智能体，其实在前文中，也有所介绍，其实其实就是模式认知篇中的集中模式，AI辅助编程IDEA同样提供了自定义智能体的方式，通过自定义智能体，调用已有工具（内置工具集、MCP服务器、插件等）设计你想要的流程，最终实现符合你需求的私人助理。（不过如果只是编程的话，可能现有智能体已经足够使用，有自己的新增的工具or MCP等可以直接选择给现有的智能体进行使用）

• 代理/Agent 级（Agent instructions）

  • 文件例如 AGENTS.md、CLAUDE.md、GEMINI.md（用于自定义 agent 行为）

  • 详情与支持情况见：Support for different types of custom instructions

MCP服务器

• 概述

  • MCP 是一个开放协议，用来将外部工具和数据源与大型语言模型（LLMs）连接起来，扩展 GitHub Copilot 的能力（例如让 Copilot 访问仓库 issue、PR、网页等上下文）。

  • 通过 MCP，可以把本地或远程 MCP 服务器注册为可用的工具集合（tools / resources / prompts），供 Copilot Chat、Copilot coding agent、Copilot CLI 等使用（不同客户端对远程/本地支持有所差异）。

• 主要能力与默认服务器

  • GitHub MCP Server：由 GitHub 提供，可让 Copilot 访问 GitHub 数据并调用如代码扫描、Copilot coding agent 的功能。可远程或本地运行；支持通过 toolsets 精细控制可用能力。 文档：About Model Context Protocol (MCP)

  • Copilot coding agent 默认配置了 GitHub 和 Playwright MCP 服务器（Playwright 默认只能访问 localhost 范围内的网页资源）。 文档：MCP and Copilot coding agent

• 如何使用与配置（常见场景、步骤）

  1. 使用内置 GitHub MCP Server（快速上手）
  • 在支持的 Copilot 客户端中，GitHub MCP server 通常已可用；在 Copilot Chat/agent 中直接可调用与 GitHub 相关的工具。
    参见：About Model Context Protocol (MCP)
  2. 在 Copilot CLI/本地客户端添加 MCP 服务器（示例）

  • Copilot CLI 可通过交互命令 /mcp add 或编辑 ~/.copilot/mcp-config.json 添加服务器（支持 local/stdio、http/sse 类型、指定 tools、headers 或 env 等）。

  • 配置示例（mcp-config.json）示例见文档。
    文档：Adding MCP servers for GitHub Copilot CLI

  3. 为 Copilot coding agent / 仓库层面配置 MCP 服务器
  • 可在仓库中写入 JSON 配置，使该仓库在 agent 执行任务时可用指定服务器的工具（agent 会自动使用工具，无需额外批准）。
    文档：MCP and Copilot coding agent
    以及：Extending Copilot coding agent with MCP（详见“设置 MCP 服务器于仓库”）

• 最佳实践与安全提醒

  • 仅启用或允许必要的 toolsets，以减少上下文窗口消耗并降低不必要的能力暴露；详细可通过 GitHub MCP Server 的 toolsets 配置控制。

  • 对第三方 MCP 服务器要审查其功能与安全性（某些远程服务器需要 OAuth/PAT，部分客户端对远程服务器的认证支持有限）。

  • 公共仓库与受 GitHub Advanced Security 覆盖的 private 仓库与 GitHub MCP server 的交互受 push protection 保护，可阻止在 AI 响应中泄露 secrets。
    参见：About Model Context Protocol (MCP)

  • 本地实践例子：

    • 我们需要编写Word、excel文档，但是文档往往是加密的，并且文档的内容格式对于普通的Agent来说，需要进一步识别与判断，大大阻碍了AI读取和编写这类文档的能力。

    • 于是我在本地部署了一个word的mcp，它具有word内容读取，以及word写入等的能力（github上类似的MCP有很多，有需要可以自行搜索下载），在项目目录文件 .vscode/mcp.json 下配置mcp服务如下
      

    • 启动对应服务后，在agent中加载对应的mcp服务，即可实现word文件读取、编写等（excel也是一样）。

    • PS: 具体MCP如何使用，对应的MCP仓库会有所介绍，这不用担心。

• 快速入口（文档链接）

  • About MCP（概念与 GitHub MCP server）：https://docs.github.com/en/copilot/concepts/context/mcp

  • 配置 MCP registry（创建与 CORS 要求）：https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry

  • 配置组织/企业的 MCP 访问策略：https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-server-access

  • 在 Copilot CLI 中添加 MCP 服务器：https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers

  • Copilot coding agent 与 MCP：https://docs.github.com/en/copilot/concepts/agents/coding-agent/mcp-and-coding-agent

以上覆盖 MCP 的基本概念、默认服务器、注册表与组织管理、在客户端/CLI 中添加 MCP 服务器，以及安全与最佳实践的要点。

工具集（toolsets）

工具集（toolsets）是 GitHub 提供的、用于配置某个 MCP 服务器（例如 GitHub MCP server）所暴露的一组功能/工具的分组。也就是说，工具集不是协议本身，而是基于 MCP 的具体服务器实现里的一种配置手段：通过启用或禁用特定的 toolsets（例如 repos, issues, pull_requests 及可选的 actions, code_security 等），你可以控制 AI 能访问哪些 GitHub API 能力、资源和提示，从而改善性能和安全。参考：Configuring toolsets for the GitHub MCP Server。

以上个章节中的MCP本地部署为例VSCode+Github Copilot编程经验：

我在本地部署了word-document-server MCP服务，即可在工具集列表中，看到word-document-server服务，对应的工具集，勾选对应的工具，即可加入到Agent中进行使用，实现读取、编写，甚至对word文件插入表格、图片等操作。

skills

Skills 是 GitHub Copilot 的可扩展机制，用来在特定任务中提供专门、可复用的指导和资源，帮助 Copilot 更准确地完成特定工作。

1. 要点总结

• 什么是：一个 skill 本质上是一个目录，里面至少包含一个 SKILL.md（Markdown，有 YAML frontmatter），描述何时以及如何使用该 skill，且可以包含脚本、示例等辅助资源。参见 About agent skills。

• 存放位置：

  • 项目级（仅对某个仓库生效）：.github/skills 或 .claude/skills

  • 个人级（跨项目共享，Copilot coding agent 与 Copilot CLI 支持）：~/.copilot/skills 或 ~/.claude/skills

• 谁能用：Copilot coding agent、Copilot CLI、VS Code Insiders agent 模式等（某些计划限制见文档）。

• 使用时机：当你需要可重复的工作流、在某些任务下保持一致输出格式，或需要“按需”详细指令时使用 skill；若说明应始终适用，优先用 custom instructions（两者可并用）。参见 Comparing GitHub Copilot CLI customization features。

2. 存放位置

• 项目级（仅对单仓库生效）：放在仓库的 .github/skills 或 .claude/skills 目录下。

• 个人级（跨项目生效）：放在 ~/.copilot/skills 或 ~/.claude/skills。

3. 目录与命名规则

• 每个 skill 用一个子目录（例如：webapp-testing）。

• 子目录名用小写并用连字符代替空格。

4. 必须文件：SKILL.md

• 文件必须命名为 SKILL.md，内容为 Markdown 并带 YAML frontmatter。必填字段：

  • name（必需）：唯一标识，使用小写和连字符，通常与目录同名。

  • description（必需）：描述 skill 功能与何时使用。

  • license（可选）：技能适用的许可说明。

• Markdown 正文部分写指令、示例、使用指南和可调用的脚本/资源说明。

---
name: test
description: Describe what this skill does and when to use it. Include keywords that help agents identify relevant tasks.
---

<!-- Tip: Use /create-skill in chat to generate content with agent assistance -->

Define the functionality provided by this skill, including detailed instructions and examples

5. 可选资源

• 在同一目录放脚本、示例文件或其它资源，并在 SKILL.md 中说明何时及如何使用它们（例如转换脚本、调试工具等）。

6. 使用时机与触发

• Copilot 会基于提示与 skill 的 description 自动决定是否使用该 skill。

• 你也可在提示中显式要求使用某个 skill：在 prompt 中以 /skill-name 开头（例如：Use the /frontend-design skill to ...）。

7. 在 Copilot CLI 中管理 skills（常用命令）

• 列出可用 skills：/skills list 或提示 “What skills do you have?”

• 启用/禁用：/skills（交互式选择）

• 查看 skill 信息与位置：/skills info

• 添加 skill 存放位置：/skills add

• 重新加载新加的 skills（会话内）：/skills reload

• 删除已添加的 skill：/skills remove SKILL-DIRECTORY（插件添加的 skill 需通过插件管理）

8. 设计建议

• 把通用、频繁用到的简单规则放到“自定义指令（custom instructions）”，把只在特定任务才用到的复杂流程放到 skill。

• 在 SKILL.md 中给出明确步骤与工具调用顺序，示例能帮助 Copilot 更准确地执行。

参考文档：

• Creating agent skills for GitHub Copilot

• Creating agent skills for GitHub Copilot CLI

[写在后面]

以上就是我所了解的关于VSCode + Copilot 实用玩法的全部内容啦。

就像开篇提到的，Copilot的功能迭代速度远比文档更新快，也许你看到这篇内容的时候，它已经上线了更多超出预期的新能力，也不必纠结文中的操作步骤、UI位置是不是已经过时——工具永远是服务于人的，上手试错10分钟，远比对着文档犹犹豫豫纠结半天有用。

可能很多朋友刚开始接触AI编程工具时，都会有「用多了会不会丧失自主编码能力」的顾虑，其实完全可以把Copilot当成你随时待命的编程搭档：写重复的样板代码、查记不住的API参数、排查低级语法错误、生成单元测试用例这些耗时间又低成长的事，大可丢给它处理，你反而能腾出更多精力放在核心的架构设计、业务逻辑梳理、技术方案选型这些真正构建你核心竞争力的事情上。它始终是副驾驶，握方向盘、决定路线的永远是你自己。

当下AI辅助编程已经是不可逆的行业趋势，与其站在岸边观望焦虑「AI会不会取代程序员」，不如早点主动拥抱它，把它变成自己的效率武器：刚入门的新人可以用它做代码解释、语法答疑，大幅降低学习门槛；有经验的开发者可以用它提效减负，把更多时间从重复劳动里抽出来，探索更有创造性的技术方向。早一天适应和AI协同的工作模式，就早一天拿到这个时代的效率红利。

也不用强求一开始就找到完美的使用流程，你可以从让它帮你写段函数注释、排查个卡了半小时的小bug、翻译段晦涩的技术文档这些小事入手，慢慢摸索出最适合自己的协同方式，久而久之你会发现，它真的能帮你省掉非常多无意义的内耗。

最后祝大家都能找到和AI工具最舒服的相处模式，写代码少遇bug，干活效率翻倍，在AI时代做走在前面的效率玩家~