本文的此版本适用于在 GitHub 上使用存储库自定义说明。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的信息。
本文的此版本适用于在 VS Code 中使用存储库自定义说明和提示文件。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的说明。
本文的此版本适用于在 Visual Studio 中使用存储库自定义说明。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的说明。
本文的此版本适用于在 JetBrains IDE 中使用仓库自定义指令。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的说明。
本文的此版本适用于在 Xcode 中使用仓库自定义指令。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的说明。
注意
此功能目前为 公共预览版,可能会更改。
本文的此版本适用于在 Eclipse 中使用存储库自定义说明。 单击上面的选项卡,获取有关在其他环境中使用自定义说明的说明。
关于 Copilot 的存储库自定义说明
通过存储库自定义说明,可以为 Copilot 提供特定于存储库的指导和首选项。
目前以下项支持仓库自定义指令:
- VS Code 中的 Copilot 对话助手****
- Copilot 编码智能体
- Visual Studio、JetBrains IDE、Xcode 中和 GitHub 网站上的 Copilot 对话助手(仅限
copilot-instructions.md
文件)**** - Copilot 代码评审(仅限
copilot-instructions.md
文件)
仓库自定义指令的先决条件
- 必须有自定义指令文件(请参阅以下指令)。
- 关于是否要使用自定义说明的个人选择必须设置为“已启用”。 此项已默认启用。 请参阅本文后面的启用或禁用存储库自定义说明。
- 必须在设置中启用“Use Instruction Files”选项。**** 此项已默认启用。 请参阅本文后面的启用或禁用存储库自定义说明。
- 必须在设置中启用“Enable custom instructions...”选项。**** 此项已默认启用。 请参阅本文后面的启用或禁用存储库自定义说明。
- 必须在 JetBrains IDE 中安装 Copilot 扩展的最新版本。
- 必须在 Xcode 中安装 Copilot 扩展的最新版本。
- 必须在 Eclipse 中安装 Copilot 扩展的最新版本。
创建存储库自定义说明文件
JetBrains IDE 支持存储在存储库中的单个 .github/copilot-instructions.md
自定义说明文件。
可使用 Copilot 设置页在仓库中创建自定义指令文件,也可以手动创建该文件。
系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
使用设置页
- 在 JetBrains IDE 中,单击“文件”**** 菜单 (Windows) 或菜单栏中的应用程序名称 (macOS),然后单击“设置”****。1. 在“语言和框架”下,单击 GitHub Copilot 。
- 在“Copilot Instructions”下,单击“Workspace”或“Global”,选择自定义指令是应用于当前工作区还是适用于所有工作区********。
手动创建工作区自定义指令文件
-
在存储库的根目录中,创建名为
.github/copilot-instructions.md
的文件。如果尚无
.github
目录,则创建该目录。 -
以 Markdown 格式在该文件中添加自然语言说明。
保存后,这些指令将应用于在启用 Copilot 的 JetBrains IDE 中打开的当前工作区。
手动创建全局自定义指令文件
要在 JetBrains IDE 中的所有工作区中应用相同的指令,可以在本地计算机上创建全局自定义指令文件。
-
打开文件资源管理器或终端。
-
导航到操作系统的相应位置:
- macOS:
/Users/YOUR-USERNAME/.config/github-copilot/intellij/
- Windows:
C:\Users\YOUR-USERNAME\AppData\Local\github-copilot\intellij\
- macOS:
-
在此目录中创建名为
global-copilot-instructions.md
的文件。 -
使用 Markdown 格式以自然语言添加自定义指令。
保存后,这些指令将全局应用于你在启用 Copilot 的 JetBrains IDE 中打开的所有工作区。
Xcode 支持存储在存储库中的单个 .github/copilot-instructions.md
自定义说明文件。
可通过 Copilot 设置页在仓库中创建自定义指令文件。
系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
- 打开 GitHub Copilot for Xcode 应用程序。
- 在应用程序窗口顶部的“Settings”下,单击“Advanced”********。
- 在“Custom Instructions”的右侧,单击“Current Workspace”或“Global”,选择自定义指令是应用于当前工作区还是适用于所有工作区********。
Eclipse 支持两种类型的存储库自定义说明:工作区和项目自定义说明。
若要创建工作区自定义说明文件,可使用 Copilot 设置页。 若要创建项目自定义说明文件,可以在项目目录中手动创建该文件。
系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
创建工作区自定义说明文件
- 要打开 Copilot 对话助手 面板,请单击 Eclipse 底部状态栏中的 Copilot 图标 ()。
- 从菜单中选择“Edit preferences”。
- 在左窗格中,展开 GitHub Copilot,然后单击“Custom Instructions”****。
- 选择“Enable workspace instructions”****。
- 在“Workspace”部分的“Set custom instructions to guide Copilot's code suggestions in this workspace”下,以 Markdown 格式向文件添加自然语言说明。
创建项目自定义说明文件
- 在项目根目录中,创建一个名为
.github/copilot-instructions.md
的文件。 - 使用 Markdown 格式以自然语言添加自定义指令。
保存后,这些说明将应用于在启用了 Copilot 的情况下打开的 Eclipse 中的当前项目。
VS Code 支持以下任一项:
- 存储在存储库中的单个
.github/copilot-instructions.md
自定义说明文件 - 存储在存储库中
.github/instructions
内的一个或多个.instructions.md
文件。 每个文件都可以指定applyTo
前辅文,以定义其说明适用的文件或目录。
使用单个 .github/copilot-instructions.md
文件
-
在存储库的根目录中,创建名为
.github/copilot-instructions.md
的文件。如果尚无
.github
目录,则创建该目录。 -
以 Markdown 格式在该文件中添加自然语言说明。
系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
使用一个或多个 .instructions.md
文件
-
如果尚无
.github/instructions
目录,则创建该目录。 -
创建一个或多个
.instructions.md
文件,向(这些)文件添加自然语言说明。系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
-
通过使用 glob 语法将
applyTo
前辅文添加到 Markdown 文件,指定说明适用的文件或目录。--- applyTo: "app/models/**/*.rb" --- Add custom instructions here
若要将说明应用于所有文件,请使用
**
模式。
Visual Studio 支持存储在存储库中的单个 .github/copilot-instructions.md
自定义说明文件。
-
在存储库的根目录中,创建名为
.github/copilot-instructions.md
的文件。如果尚无
.github
目录,则创建该目录。 -
以 Markdown 格式在该文件中添加自然语言说明。
系统会忽略说明信息间的空格,因此可将信息编写为一个段落,每个段落位于一行上,或用空白行分隔,以保持其可读性。
GitHub 网站上的 Copilot 对话助手、Copilot 编码智能体 和 Copilot 代码评审 支持存储在存储库中的单个 .github/copilot-instructions.md
自定义说明文件************。
此外,Copilot 编码智能体 支持****:
- 存储在存储库中
.github/instructions
内的一个或多个.instructions.md
文件。 每个文件都可以指定applyTo
前辅文,以定义其说明适用的文件或目录。 - 存储在存储库内任意位置的一个或多个
AGENTS.md
文件。 当 Copilot 正常工作时,目录树中最接近的AGENTS.md
文件将优先。 - 存储在存储库根目录中的单个
CLAUDE.md
或GEMINI.md
文件。
使用单个 .github/copilot-instructions.md
文件
可以要求 Copilot 编码智能体 生成 .github/copilot-instructions.md
文件,也可以编写自己的说明文件。
要求 Copilot 编码智能体 生成 .github/copilot-instructions.md
文件
注意
Copilot 编码智能体 为 公共预览版,可能会变动。 在预览期间,该功能的使用须遵循“GitHub 预发行许可条款”。
-
导航到 github.com/copilot/agents 处的“Agents”页面。
你也可以通过单击 GitHub 上任何页面搜索栏旁边的 按钮,然后从边栏中选择“Agents”到达此页面。********
-
在提示字段的下拉菜单中,选择希望 Copilot 为其生成自定义说明的存储库。
-
复制以下提示,根据所需对其进行自定义:
Markdown Your task is to "onboard" this repository to Copilot coding agent by adding a .github/copilot-instructions.md file in the repository that contains information describing how a coding agent seeing it for the first time can work most efficiently. You will do this task only one time per repository and doing a good job can SIGNIFICANTLY improve the quality of the agent's work, so take your time, think carefully, and search thoroughly before writing the instructions. <Goals> - Reduce the likelihood of a coding agent pull request getting rejected by the user due to generating code that fails the continuous integration build, fails a validation pipeline, or having misbehavior. - Minimize bash command and build failures. - Allow the agent to complete its task more quickly by minimizing the need for exploration using grep, find, str_replace_editor, and code search tools. </Goals> <Limitations> - Instructions must be no longer than 2 pages. - Instructions must not be task specific. </Limitations> <WhatToAdd> Add the following high level details about the codebase to reduce the amount of searching the agent has to do to understand the codebase each time: <HighLevelDetails> - A summary of what the repository does. - High level repository information, such as the size of the repo, the type of the project, the languages, frameworks, or target runtimes in use. </HighLevelDetails> Add information about how to build and validate changes so the agent does not need to search and find it each time. <BuildInstructions> - For each of bootstrap, build, test, run, lint, and any other scripted step, document the sequence of steps to take to run it successfully as well as the versions of any runtime or build tools used. - Each command should be validated by running it to ensure that it works correctly as well as any preconditions and postconditions. - Try cleaning the repo and environment and running commands in different orders and document errors and and misbehavior observed as well as any steps used to mitigate the problem. - Run the tests and document the order of steps required to run the tests. - Make a change to the codebase. Document any unexpected build issues as well as the workarounds. - Document environment setup steps that seem optional but that you have validated are actually required. - Document the time required for commands that failed due to timing out. - When you find a sequence of commands that work for a particular purpose, document them in detail. - Use language to indicate when something should always be done. For example: "always run npm install before building". - Record any validation steps from documentation. </BuildInstructions> List key facts about the layout and architecture of the codebase to help the agent find where to make changes with minimal searching. <ProjectLayout> - A description of the major architectural elements of the project, including the relative paths to the main project files, the location of configuration files for linting, compilation, testing, and preferences. - A description of the checks run prior to check in, including any GitHub workflows, continuous integration builds, or other validation pipelines. - Document the steps so that the agent can replicate these itself. - Any explicit validation steps that the agent can consider to have further confidence in its changes. - Dependencies that aren't obvious from the layout or file structure. - Finally, fill in any remaining space with detailed lists of the following, in order of priority: the list of files in the repo root, the contents of the README, the contents of any key source files, the list of files in the next level down of directories, giving priority to the more structurally important and snippets of code from key source files, such as the one containing the main method. </ProjectLayout> </WhatToAdd> <StepsToFollow> - Perform a comprehensive inventory of the codebase. Search for and view: - README.md, CONTRIBUTING.md, and all other documentation files. - Search the codebase for build steps and indications of workarounds like 'HACK', 'TODO', etc. - All scripts, particularly those pertaining to build and repo or environment setup. - All build and actions pipelines. - All project files. - All configuration and linting files. - For each file: - think: are the contents or the existence of the file information that the coding agent will need to implement, build, test, validate, or demo a code change? - If yes: - Document the command or information in detail. - Explicitly indicate which commands work and which do not and the order in which commands should be run. - Document any errors encountered as well as the steps taken to workaround them. - Document any other steps or information that the agent can use to reduce time spent exploring or trying and failing to run bash commands. - Finally, explicitly instruct the agent to trust the instructions and only perform a search if the information in the instructions is incomplete or found to be in error. </StepsToFollow> - Document any errors encountered as well as the steps taken to work-around them.
Your task is to "onboard" this repository to Copilot coding agent by adding a .github/copilot-instructions.md file in the repository that contains information describing how a coding agent seeing it for the first time can work most efficiently. You will do this task only one time per repository and doing a good job can SIGNIFICANTLY improve the quality of the agent's work, so take your time, think carefully, and search thoroughly before writing the instructions. <Goals> - Reduce the likelihood of a coding agent pull request getting rejected by the user due to generating code that fails the continuous integration build, fails a validation pipeline, or having misbehavior. - Minimize bash command and build failures. - Allow the agent to complete its task more quickly by minimizing the need for exploration using grep, find, str_replace_editor, and code search tools. </Goals> <Limitations> - Instructions must be no longer than 2 pages. - Instructions must not be task specific. </Limitations> <WhatToAdd> Add the following high level details about the codebase to reduce the amount of searching the agent has to do to understand the codebase each time: <HighLevelDetails> - A summary of what the repository does. - High level repository information, such as the size of the repo, the type of the project, the languages, frameworks, or target runtimes in use. </HighLevelDetails> Add information about how to build and validate changes so the agent does not need to search and find it each time. <BuildInstructions> - For each of bootstrap, build, test, run, lint, and any other scripted step, document the sequence of steps to take to run it successfully as well as the versions of any runtime or build tools used. - Each command should be validated by running it to ensure that it works correctly as well as any preconditions and postconditions. - Try cleaning the repo and environment and running commands in different orders and document errors and and misbehavior observed as well as any steps used to mitigate the problem. - Run the tests and document the order of steps required to run the tests. - Make a change to the codebase. Document any unexpected build issues as well as the workarounds. - Document environment setup steps that seem optional but that you have validated are actually required. - Document the time required for commands that failed due to timing out. - When you find a sequence of commands that work for a particular purpose, document them in detail. - Use language to indicate when something should always be done. For example: "always run npm install before building". - Record any validation steps from documentation. </BuildInstructions> List key facts about the layout and architecture of the codebase to help the agent find where to make changes with minimal searching. <ProjectLayout> - A description of the major architectural elements of the project, including the relative paths to the main project files, the location of configuration files for linting, compilation, testing, and preferences. - A description of the checks run prior to check in, including any GitHub workflows, continuous integration builds, or other validation pipelines. - Document the steps so that the agent can replicate these itself. - Any explicit validation steps that the agent can consider to have further confidence in its changes. - Dependencies that aren't obvious from the layout or file structure. - Finally, fill in any remaining space with detailed lists of the following, in order of priority: the list of files in the repo root, the contents of the README, the contents of any key source files, the list of files in the next level down of directories, giving priority to the more structurally important and snippets of code from key source files, such as the one containing the main method. </ProjectLayout> </WhatToAdd> <StepsToFollow> - Perform a comprehensive inventory of the codebase. Search for and view: - README.md, CONTRIBUTING.md, and all other documentation files. - Search the codebase for build steps and indications of workarounds like 'HACK', 'TODO', etc. - All scripts, particularly those pertaining to build and repo or environment setup. - All build and actions pipelines. - All project files. - All configuration and linting files. - For each file: - think: are the contents or the existence of the file information that the coding agent will need to implement, build, test, validate, or demo a code change? - If yes: - Document the command or information in detail. - Explicitly indicate which commands work and which do not and the order in which commands should be run. - Document any errors encountered as well as the steps taken to workaround them. - Document any other steps or information that the agent can use to reduce time spent exploring or trying and failing to run bash commands. - Finally, explicitly instruct the agent to trust the instructions and only perform a search if the information in the instructions is incomplete or found to be in error. </StepsToFollow> - Document any errors encountered as well as the steps taken to work-around them.
-
Click Send now or press Return.
Copilot will start a new session, which will appear in the list below the prompt box. Copilot will create a draft pull request, write your custom instructions, push them to the branch, then add you as a reviewer when it has finished, triggering a notification.
Writing your own .github/copilot-instructions.md
file
-
In the root of your repository, create a file named
.github/copilot-instructions.md
.Create the
.github
directory if it does not already exist. -
Add natural language instructions to the file, in Markdown format.
Whitespace between instructions is ignored, so the instructions can be written as a single paragraph, each on a new line, or separated by blank lines for legibility.
提示
The first time you create a pull request in a given repository with Copilot 编码智能体, Copilot will leave a comment with a link to automatically generate custom instructions for the repository.
Using one or more .instructions.md
files
-
Create the
.github/instructions
directory if it does not already exist. -
Create one or more
.instructions.md
files, adding natural language instructions to the file(s).Whitespace between instructions is ignored, so the instructions can be written as a single paragraph, each on a new line, or separated by blank lines for legibility.
-
Specify what files or directories the instructions apply to by adding
applyTo
frontmatter to the Markdown files, using glob syntax.--- applyTo: "app/models/**/*.rb" --- Add custom instructions here
若要将说明应用于所有文件,请使用
**
模式。
编写有效的存储库自定义说明
添加到自定义说明文件的说明应是简短的自包含语句,这些语句为 Copilot 提供相关信息,以帮助它在此存储库中工作。 由于这些说明随每个聊天消息一起发送,因此它们应广泛适用于你将在存储库上下文中发出的大多数请求。
用于说明文件的确切结构因项目和需求而异,但以下准则提供了一个很好的起点:
- 提供正在处理的项目的概述,包括其用途、目标和任何相关的背景信息。
- 包括存储库的文件夹结构,包括与项目相关的任何重要目录或文件。
- 指定应遵循的编码标准和约定,例如命名约定、格式规则和最佳做法。
- 包括项目中使用的任何特定工具、库或框架,以及任何相关的版本号或配置。
以下说明文件是这些做法的一个实践示例:
# Project Overview
This project is a web application that allows users to manage their tasks and to-do lists. It is built using React and Node.js, and uses MongoDB for data storage.
## Folder Structure
- `/src`: Contains the source code for the frontend.
- `/server`: Contains the source code for the Node.js backend.
- `/docs`: Contains documentation for the project, including API specifications and user guides.
## Libraries and Frameworks
- React and Tailwind CSS for the frontend.
- Node.js and Express for the backend.
- MongoDB for data storage.
## Coding Standards
- Use semicolons at the end of each statement.
- Use single quotes for strings.
- Use function based components in React.
- Use arrow functions for callbacks.
## UI guidelines
- A toggle is provided to switch between light and dark mode.
- Application should have a modern and clean design.
你还应考虑仓库的大小和复杂度。 以下类型的指令仅适用于只有少数参与者的小型存储库,但对于大型和多样化的存储库,这可能会导致问题****:
- 要求在提供的回答中引用外部资源
- 有关按特定风格回答的说明
- 要求始终以特定详细级别的信息来回答
例如,以下指令可能无法获得预期结果****:
Always conform to the coding styles defined in styleguide.md in repo my-org/my-repo when generating code.
Use @terminal when answering questions about Git.
Answer all questions in the style of a friendly colleague, using informal language.
Answer all questions in less than 1000 characters, and words of no more than 12 characters.
使用中的存储库自定义说明
保存文件后,文件中的说明便可供 Copilot 对话助手 使用。 系统会将完整指令集自动添加到你在该存储库上下文中提交到 Copilot 的请求中。 例如,系统会将它们添加到你提交到 Copilot 对话助手 的提示中。
在 Copilot 对话助手 的沉浸式视图 (github.com/copilot) 中,可以通过附加包含指令文件的存储库来发起使用存储库自定义指令的对话。
每当 Copilot 对话助手 使用存储库自定义指令时,指令文件都将被添加为所生成响应的引用。 要查看是否使用了仓库自定义指令,请展开“Chat”面板中聊天响应顶部的引用列表,检查是否列出了 .github/copilot-instructions.md
文件。
可以单击引用信息来打开该文件。
注意
- 可以向聊天应用多种类型的自定义指令。 个人指令具有最高优先级,存储库指令其次,组织指令的优先级最低。 但是,所有相关指令集仍将被合并并提供给 Copilot 对话助手。
- 请尽可能避免提供冲突的指令集。 如果顾虑响应质量,也可以选择暂时禁用存储库说明。 请参阅“为 GitHub Copilot 添加存储库自定义说明”。
自定义说明在“聊天”视图或内联聊天中不可见,但可以通过查看“聊天”视图中的回复引用列表来验证 Copilot 是否正在使用这些说明。 如果将自定义说明添加到发送到模型的提示中,引用信息中会列出文件 .github/copilot-instructions.md
。 可以单击引用信息来打开该文件。
自定义说明在“聊天”视图或内联聊天中不可见,但可以通过查看“聊天”视图中的回复引用列表来验证 Copilot 是否正在使用这些说明。 如果将自定义说明添加到发送到模型的提示中,引用信息中会列出文件 .github/copilot-instructions.md
。 可以单击引用信息来打开该文件。
自定义说明在“聊天”视图或内联聊天中不可见,但可以通过查看“聊天”视图中的回复引用列表来验证 Copilot 是否正在使用这些说明。 如果将自定义说明添加到发送到模型的提示中,引用信息中会列出文件 .github/copilot-instructions.md
。 可以单击引用信息来打开该文件。
自定义说明在“聊天”视图或内联聊天中不可见,但可以通过查看“聊天”视图中的回复引用列表来验证 Copilot 是否正在使用这些说明。 如果将自定义说明添加到发送到模型的提示中,引用信息中会列出文件 .github/copilot-instructions.md
。 可以单击引用信息来打开该文件。
启用或禁用存储库自定义说明
可以选择是否要让 Copilot 使用基于仓库的自定义指令。
为 Copilot 对话助手 启用或禁用自定义指令
默认情况下,Copilot 对话助手 已启用自定义指令,但你可以随时禁用或重新启用它们。 这适用于你自己的 Copilot 对话助手 使用,不会影响其他用户。
-
在 GitHub.com 上,执行下列操作之一:
- 转到使用自定义指令文件的存储库,打开辅助聊天面板。
- 转到 Copilot 对话助手 (github.com/copilot) 的沉浸式视图,并附加包含自定义指令文件的存储库。
-
单击“Chat”面板顶部或沉浸式页面右上角的 按钮。
-
单击“Disable custom instructions”或“Enable custom instructions”。********
注意
只会在包含自定义指令文件的存储库上下文中看到这些选项。
对于包含自定义指令文件的所有存储库,你的选择将一直保留,直到更改为止。
为 Copilot 代码评审 启用或禁用自定义指令
默认情况下,Copilot 代码评审 已启用自定义指令,但你可以在 GitHub.com 上的仓库设置中禁用或重新启用它们。 这适用于 Copilot 对此仓库中执行的所有代码评审使用自定义指令。
-
在 GitHub 上,导航到存储库的主页面。
-
在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”。
-
在边栏的“Code & automation”部分,单击 Copilot,然后单击“Code review”********。
-
打开或关闭“Use custom instructions when reviewing pull requests”选项。
启用或禁用存储库自定义说明
可以选择是否要让 Copilot 使用基于仓库的自定义指令。
为 Copilot 对话助手 启用或禁用自定义指令
默认情况下,Copilot 对话助手 已启用自定义指令,但你可以随时禁用或重新启用它们。 这适用于你自己的 Copilot 对话助手 使用,不会影响其他用户。
- 使用键盘快捷方式 Command+, (Mac)/Ctrl+, (Linux/Windows) 打开“设置编辑器”。
- 在搜索框中键入
instruction file
。 - 选中或清除“代码生成: 使用说明文件”**** 下的复选框。
为 Copilot 代码评审 启用或禁用自定义指令
默认情况下,Copilot 代码评审 已启用自定义指令,但你可以在 GitHub.com 上的仓库设置中禁用或重新启用它们。 这适用于 Copilot 对此仓库中执行的所有代码评审使用自定义指令。
-
在 GitHub 上,导航到存储库的主页面。
-
在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”。
-
在边栏的“Code & automation”部分,单击 Copilot,然后单击“Code review”********。
-
打开或关闭“Use custom instructions when reviewing pull requests”选项。
启用或禁用存储库自定义说明
可以选择是否要让 Copilot 使用基于仓库的自定义指令。
为 Copilot 对话助手 启用或禁用自定义指令
默认情况下,Copilot 对话助手 已启用自定义指令,但你可以随时禁用或重新启用它们。 这适用于你自己的 Copilot 对话助手 使用,不会影响其他用户。
-
在 Visual Studio 菜单栏中的“工具”下,单击“选项” 。
-
在“Options”对话框的搜索框中键入
custom instructions
,然后单击“Copilot”****。 -
选中或清除复选框“Enable custom instructions to be loaded from .github/copilot-instructions.md files and added to requests”****。
为 Copilot 代码评审 启用或禁用自定义指令
默认情况下,Copilot 代码评审 已启用自定义指令,但你可以在 GitHub.com 上的仓库设置中禁用或重新启用它们。 这适用于 Copilot 对此仓库中执行的所有代码评审使用自定义指令。
-
在 GitHub 上,导航到存储库的主页面。
-
在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”。
-
在边栏的“Code & automation”部分,单击 Copilot,然后单击“Code review”********。
-
打开或关闭“Use custom instructions when reviewing pull requests”选项。
启用并使用提示文件
注意
提示文件为公共预览版,可能会更改。
通过提示文件,你可以使用额外的上下文生成和共享可重用的提示说明。 提示文件是存储在工作区中的 Markdown 文件,它模仿 Copilot 对话助手 中编写提示的现有格式(例如,Rewrite #file:x.ts
)。 你在工作区中可以有多个提示文件,每个提示文件都定义一个用于不同目的的提示。
启用提示文件
若要启用提示文件,请配置工作区设置。
- 按 Ctrl+Shift+P (Windows/Linux) / Command+Shift+P (Mac) 打开命令面板。
- 键入“Open Workspace Settings (JSON)”,然后选择显示的选项。
- 在
settings.json
文件中,添加"chat.promptFiles": true
以启用.github/prompts
文件夹作为提示文件的位置。 如果此文件夹尚不存在,系统将创建它。
创建提示文件
-
按 Ctrl+Shift+P (Windows/Linux) / Command+Shift+P (Mac) 打开命令面板。
-
键入“prompt”并选择“Chat: Create Prompt”****。
-
输入提示文件的名称,不包括
.prompt.md
文件扩展名。 该名称可以包含字母数字字符和空格,且应描述文件将包含的提示信息的目的。 -
使用 Markdown 格式编写提示说明。
可以使用 Markdown 链接(例如
[index](../../web/index.ts)
)或使用#file:../../web/index.ts
语法来引用工作区中的其他文件。 路径是相对于提示文件的。 通过引用其他文件,可以提供其他上下文,例如 API 规范或产品文档。
使用提示文件
-
在 Copilot 对话助手 视图底部,单击“Attach context”图标 ()****。
-
在下拉菜单中,单击“Prompt...”并选择要使用的提示文件****。
-
(可选)附加其他文件(包括提示文件)以提供更多上下文。
-
(可选)在聊天提示框中键入其他信息。
是否需要执行此操作取决于所使用的提示的内容。
-
提交聊天提示。
有关提示文件的详细信息,请参阅 Visual Studio Code 文档中的“VS Code 中 GitHub Copilot 的自定义说明”。