【Copilot配置】—— copilot-instructions.md vs AGENTS.md vs .instructions.md三种指令文件解析与配置

【Copilot配置】—— copilot-instructions.md vs AGENTS.md vs .instructions.md三种指令文件解析与配置

Copilot 指令文件全解析:copilot-instructions.md vs AGENTS.md vs .instructions.md

作为常年和 VS Code 打交道的研发,最近在折腾 Copilot Agent 时,我发现很多同学和我一样,被 .github/copilot-instructions.mdAGENTS.md.instructions.md 这三个文件绕晕了。

明明都是给 Copilot 写的 “指令”,为什么要分三个文件?它们的生效范围有啥区别?什么时候该用哪一个?

带着这些疑问,我翻遍了官方文档,又在自己的 AI Agent 项目里反复实测,终于把这三者的关系理得清清楚楚。这篇文章就用最直白的语言,结合实战配置,帮你彻底搞懂 Copilot 指令文件的使用逻辑。

一、先搞懂核心:三者的定位差异

在讲细节前,我们先用一个通俗的类比定调,这能帮你快速建立认知:

  • .github/copilot-instructions.md项目的 “全局家规”,管整个仓库的所有 Copilot 基础交互;
  • AGENTS.mdCopilot Agent 的 “任务清单”,只服务于 Agent 进阶自动化功能;
  • .instructions.md目录的 “局部特例”,管特定文件夹的 Copilot 基础交互,优先级最高。

简单来说:前两者是 “全局 vs 专属功能” 的区别,后两者是 “全局 vs 局部” 的区别,而 AGENTS.md 则是完全独立的 “进阶功能配置”。

二、三者核心辨析(一张表搞定)

为了方便大家查阅,我把三者的关键差异整理成了表格,这也是我做技术笔记时最常用的形式,一目了然:

表格

特性.github/copilot-instructions.mdAGENTS.md.instructions.md
核心定位项目级全局通用指令文件Copilot Agent 专属任务配置文件目录 / 文件级细粒度指令文件
生效范围整个代码仓库(所有文件、目录)仅 Copilot Agent 功能(手动触发时生效)仅当前文件所在目录及子目录
作用对象Copilot 基础能力(补全、注释、代码解释)仅 Copilot Agent 进阶功能(自动化任务)Copilot 基础能力(同左,仅局部生效)
触发方式被动生效(Copilot 自动读取)主动触发(VS Code 中手动点击「Run Agent」)被动生效(Copilot 自动读取)
存放路径强制:仓库根目录 /.github/(大小写敏感)无强制(建议放 .github/ 或项目根目录)无强制(放在需要生效的目标目录下)
内容风格项目规则、技术栈、业务背景描述具体任务步骤、执行目标、输出要求局部特殊规范、目录专属业务逻辑
优先级高于 Copilot 全局默认,低于 .instructions.md独立优先级(不与其他两者冲突)最高(覆盖全局规则)
典型场景定义全仓库编码规范、技术栈要求代码重构、批量文档生成、漏洞扫描特定模块的特殊命名规则、依赖限制

三、实战配置:手把手教你用对文件

光看理论不够,结合我自己的 AI Agent 项目(基于 Python 开发),给大家写了三个可直接复制的配置示例,对应不同的使用场景。

场景 1:项目全局规范 → 用 copilot-instructions.md

我的项目是一个 AI Agent 工具开发仓库,技术栈为 Python 3.11+、FastAPI,需要全仓库统一编码规范。

存放路径项目根目录/.github/copilot-instructions.md

配置内容

markdown

# Copilot 项目全局指令 ## 1. 技术栈与编码规范 - 编程语言:Python 3.11+,严格遵循 PEP 8 规范 - 命名规则:函数用小驼峰,类用大驼峰,常量全大写加下划线,Agent 相关类名必须以「Agent」结尾 - 注释要求:核心函数必须写中文文档字符串(docstring),包含入参、出参、功能描述 ## 2. 业务背景说明 本项目是一款轻量级 AI Agent 调度工具,核心模块包括:任务解析、技能调度、结果返回。 - 任务解析模块:负责解析用户输入的自然语言任务 - 技能调度模块:调用 OpenCode、Smithery 等第三方技能 - 结果返回模块:将 Agent 执行结果格式化为 Markdown 输出 ## 3. 依赖限制 - 优先使用项目虚拟环境中的依赖,禁止随意引入未在 requirements.txt 中声明的库 - 网络请求统一使用项目封装的 `src/utils/request.py` 中的 Axios 实例 

配置完成后,不管我在 src/ 还是 tests/ 目录写代码,Copilot 都会自动遵循这些规则,比如定义 Agent 类时,会自动补全「Agent」后缀。

场景 2:Agent 自动化任务 → 用 AGENTS.md

我需要让 Copilot Agent 自动完成「项目代码质量检查」的任务,包括类型注解检查、异常处理检测,并生成报告。

存放路径项目根目录/.github/AGENTS.md(建议和全局指令放一起,方便管理)

配置内容

markdown

# Copilot Agent 任务指令集 ## 任务1:代码质量检查(核心任务) 1. 执行范围:遍历项目 `src/` 目录下所有 `.py` 文件 2. 检查项: - 所有函数和类方法是否包含完整的类型注解(入参、出参) - 是否存在未处理的异常(无 try-except 包裹的危险操作) - 导入语句是否存在未使用的情况 3. 输出要求: - 以 Markdown 格式生成检查报告,分为「问题清单」和「修复建议」两部分 - 对每个问题,附上具体文件路径、行号和对应的修复代码片段 ## 任务2:API 文档生成 1. 执行范围:`src/api/` 目录下的所有 FastAPI 路由文件 2. 执行要求:提取所有接口的路径、请求方式、入参、出参 3. 输出要求:生成 `API文档.md`,保存到项目根目录 

使用方式:在 VS Code 中打开 Copilot 面板,点击「Run Agent」,选择对应的任务,Copilot 就会按照配置自动执行。

场景 3:局部目录特殊规则 → 用 .instructions.md

我的项目 src/admin/ 目录是后台管理模块,需要和核心模块区分开,组件命名必须以「Admin」为前缀,且禁止使用 FastAPI 的自动文档功能。

存放路径项目根目录/src/admin/.instructions.md

配置内容

markdown

# 后台管理模块专属指令 1. 命名规则:所有类、函数、组件命名必须以「Admin」为前缀(如 AdminUserService、admin_get_user_list) 2. 功能限制:禁止使用 FastAPI 的 `docs_url` 和 `redoc_url` 配置,后台接口无需生成自动文档 3. 业务要求:所有后台接口必须包含权限校验逻辑,需调用 `src/utils/auth.py` 中的 `check_admin_permission` 函数 

此时,即使全局指令要求遵循 FastAPI 文档规范,Copilot 在 src/admin/ 目录下写代码时,也会优先遵循这个局部规则。

四、优先级与协同使用技巧

在实际开发中,这三个文件往往会同时存在,掌握它们的协同逻辑,能让 Copilot 更贴合你的项目需求:

  1. 基础能力优先级.instructions.md(局部) > .github/copilot-instructions.md(全局) > Copilot 官方默认配置;
  2. 功能隔离原则AGENTS.md 只作用于 Agent 功能,和另外两个文件没有优先级冲突,即使你配置了全局指令,Agent 也只会按 AGENTS.md 的要求执行任务;
  3. 实战建议
    • 小型项目:只需要配置 .github/copilot-instructions.md,足够覆盖大部分场景;
    • 中大型项目:全局指令 + 局部指令结合,复杂自动化任务用 AGENTS.md
    • 多人协作:把三个文件都纳入 Git 版本管理,确保团队所有人的 Copilot 行为一致。

五、常见问题排查

最后,整理几个我实测时遇到的坑,帮你避坑:

  1. copilot-instructions.md 不生效:检查路径是否为 .github/ 目录(不是 .vscode/),文件名是否严格匹配(大小写敏感);
  2. Agent 不执行指定任务:确认 AGENTS.md 中任务描述是否清晰,是否手动触发了「Run Agent」功能(不是普通的代码补全);
  3. .instructions.md 覆盖范围异常:该文件会作用于当前目录及所有子目录,若想仅作用于单个文件,可将文件放在单独目录,或在指令中明确指定文件名。

总结

其实 Copilot 的这三个指令文件,核心逻辑就是 “粒度分层” 和 “功能隔离”

  • 按粒度分:全局(copilot-instructions.md)和局部(.instructions.md);
  • 按功能分:基础补全(前两者)和进阶自动化(AGENTS.md)。

搞懂这个逻辑,再结合项目实际需求配置,就能让 Copilot 从 “通用助手” 变成 “专属项目管家”,不管是日常编码补全,还是复杂的 Agent 自动化任务,都能精准贴合你的开发习惯。

后续我会继续分享 Copilot Agent 结合 AI Agent 技术的实战案例,比如用 Agent 自动生成技术博客初稿,感兴趣的同学可以持续关注~

Read more

旧电脑 Win7 复活计划:编译与运行 llama.cpp (Qwen3版)

旧电脑 Win7 复活计划:编译与运行 llama.cpp (Qwen3版)

🦕 旧电脑 Win7 复活计划:编译与运行 llama.cpp (Qwen3版) 这份指南专为不支持新版软件的 Windows 7 设计,通过本地编译实现大模型运行。 手动编译可以获得最好的性能,不想自己手动编译 可以直接使用下面编译好的bin文件,同时包含下面用到的相关软件和替换文件httplib.h 链接:https://pan.quark.cn/s/2c5f627c93d7 提取码:cSJh 📋 0. 软件版本清单 请务必确保使用以下特定版本,以保证在 Win7 下的兼容性: 软件名称文件名 (根据截图)作用备注编译环境w64devkit-x64-2.5.0.7z.exe提供 GCC 编译器核心工具构建工具cmake-3.31.10-windows-x86_64.msi生成编译配置必须安装到默认路径源码工具Git_for_Windows_(64bit)_v2.45.

AI绘画+电商:用图片和视频驱动未来电商

过去三年里,AI绘画从实验室走向大众,从简单模仿到艺术创作。如今,这项技术正悄然改变着一个万亿美元级的行业——电子商务。当AI绘画遇上电商,一场深刻的视觉革命正在拉开帷幕。 视觉冲击力:电商转化的第一道门槛 在电商平台上,消费者无法触摸实物,视觉呈现成为购买决策的关键因素。研究表明: * 高质量产品图能将转化率提升30-50% * 视频展示的商品比仅用图片的商品多获得157%的点击率 * 87%的线上消费者认为产品图片是购物决策的重要因素 然而,高质量视觉内容的制作传统上面临三大挑战:成本高、周期长、创意匮乏。专业摄影、模特拍摄、后期修图,每个环节都需要大量时间和资金投入,对小企业和新兴品牌尤为不友好。 AI绘画技术:视觉内容的民主化革命 AI绘画技术的突破性进展正在改变这一局面。以Midjourney、Stable Diffusion、DALL-E 3为代表的一批AI绘画工具,让高质量视觉内容的创作变得前所未有地简单和高效。 四大核心应用场景: 1. 产品视觉优化与扩展 * 一键生成专业级产品展示图 * 自动扩展产品使用场景(如咖啡机在不同厨房环境中的

用 C# 扩展 Dynamics 365 Copilot:自定义插件与场景

Dynamics 365 Copilot 作为基于 AI 的智能助手,为企业用户提供了自动化流程、智能分析和自然语言交互的能力,但通用功能往往无法满足特定行业或企业的定制化需求。本文将详细介绍如何通过 C# 编写自定义插件,扩展 Dynamics 365 Copilot 的能力,并结合实际业务场景实现定制化 AI 交互。 一、核心基础:Dynamics 365 Copilot 扩展架构 Dynamics 365 Copilot 的扩展主要依赖于 Power Platform 插件框架 和 Copilot Studio 的自定义连接器,核心技术栈包括: * C# (.NET Framework 4.8 或 .NET 6+):编写业务逻辑插件 * Dynamics 365 SDK:

智能创作与优化新时代:【ChatGPT-4o】在【数学建模】、【AI绘画】、【海报设计】与【论文优化】中的创新应用

智能创作与优化新时代:【ChatGPT-4o】在【数学建模】、【AI绘画】、【海报设计】与【论文优化】中的创新应用

目录 1. 引言 什么是ChatGPT4o? 背景与发展历史 2.chatgpt4o数学建模 常见的数学建模专业术语及其简要说明 一个具体的代码例子 问题描述 代码实现  代码说明 运行结果 3.chatgpt4o在论文 1.例如生成基于标签的推荐系统模型及算法研究  1. 摘要 2. 引言 3. 文献综述 4. 模型与算法 5. 实验与分析 6. 结论与展望 7. 参考文献 案例背景 2.具体应用场景 1. 摘要优化 原稿: ChatGPT优化后的版本: 优化点: 2. 引言部分的结构优化 原稿: ChatGPT优化后的版本: 优化点: 3. 方法部分的细化与完善 原稿: ChatGPT优化后的版本: 4. 结论的增强