参加你附近的 ，了解 VS Code 中的 AI 辅助开发。

在 VS Code 中设置上下文工程流程

本指南将向您展示如何使用自定义指令、聊天模式和提示文件在 VS Code 中设置上下文工程工作流。

上下文工程是一种系统方法，旨在为 AI 代理提供有针对性的项目信息，以提高生成代码的质量和准确性。通过自定义指令、实施计划和编码指南来整理重要的项目上下文，您可以使 AI 做出更好的决策，提高准确性，并在交互过程中保持持久的知识。

上下文工程工作流

VS Code 中上下文工程的高级工作流包括以下步骤：

  1. 整理项目范围的上下文：使用自定义指令，将相关文档（例如，架构、设计、贡献者指南）作为上下文纳入所有代理交互中。
  2. 生成实施计划：通过使用自定义聊天模式和提示来创建规划角色，以生成详细的功能实施计划。
  3. 生成实施代码：使用自定义指令，根据实施计划生成符合您的编码指南的代码。

在执行这些步骤时，您可以在聊天中通过后续提示来迭代和完善输出。

下图说明了 VS Code 中的上下文工程工作流：

Diagram that shows the context engineering workflow in VS Code consisting of three main steps.

第 1 步：整理项目范围的上下文

为了使 AI 代理熟悉项目的具体情况，请收集关键项目信息，如产品愿景、架构和其他相关文档，并通过自定义指令将其添加为聊天上下文。通过使用自定义指令，您可以确保代理始终可以访问此上下文，并且无需在每次聊天交互中重新学习。

这为什么有帮助： 代理可以在代码库中找到此信息，但它可能隐藏在注释中或分散在多个文件中。通过提供最重要的信息的简洁摘要，您可以帮助代理始终拥有可用于决策的关键上下文。

  1. 在存储库中的 Markdown 文件中描述相关项目文档，例如创建 PRODUCT.md、ARCHITECTURE.md 和 CONTRIBUTING.md 文件。

    提示

    如果您有现有的代码库，可以使用 AI 生成这些项目文档文件。请务必审阅和完善生成的文档文件，以确保准确性和完整性。

    • 生成一个 ARCHITECTURE.md 文件（最多 2 页），描述项目的整体架构。
    • 生成一个 PRODUCT.md 文件（最多 2 页），描述项目的产品功能。
    • 生成一个 CONTRIBUTING.md 文件（最多 1 页），描述为项目贡献的开发人员指南和最佳实践。

  2. 在存储库的根目录中创建 .github/copilot-instructions.md 指令文件。

    此文件中的指令会自动包含在所有聊天交互中，作为 AI 代理的上下文。

  3. 为代理提供项目上下文和指南的高级概述。使用 Markdown 链接引用相关的支持文档文件。

    以下示例 .github/copilot-instructions.md 文件提供了一个起点：

    # [Project Name] Guidelines

* [Product Vision and Goals](../PRODUCT.md): Understand the high-level vision and objectives of the product to ensure alignment with business goals.
* [System Architecture and Design Principles](../ARCHITECTURE.md): Overall system architecture, design patterns, and design principles that guide the development process.
* [Contributing Guidelines](../CONTRIBUTING.md): Overview of the project's contributing guidelines and collaboration practices.

Suggest to update these documents if you find any incomplete or conflicting information during your work.
提示

从小处着手，保持初始的项目范围上下文简洁，并专注于最关键的信息。如果不确定，请专注于高级架构，并且只添加新规则来解决代理反复出现的错误或不正确的行为（例如，使用错误的 shell 命令，忽略某些文件）。

第 2 步：创建实施计划

一旦您设置了项目特定的上下文，就可以使用 AI 提示为新功能或错误修复创建实施计划。生成实施计划是一个迭代过程，可能需要多轮完善以确保其完整和准确。

通过用于规划的自定义聊天模式，您可以创建一个具有规划特定指南和工具（例如，对代码库的只读访问权限）的专用角色。它们还可以为您的项目和团队捕获用于头脑风暴、研究和协作的特定工作流。

提示

一旦您创建了聊天模式，请将其视为活文档。根据您在代理行为中观察到的任何错误或缺点，随着时间的推移对其进行完善和改进。

  1. 创建规划文档模板 plan-template.md，它定义了实施计划文档的结构和部分。

    通过使用模板，您可以确保代理收集所有必要信息并以一致的格式呈现。这也有助于提高根据计划生成的代码的质量。

    以下 plan-template.md 文件提供了实施计划模板的示例结构：

    ---
title: [Short descriptive title of the feature]
version: [optional version number]
date_created: [YYYY-MM-DD]
last_updated: [YYYY-MM-DD]
---
# Implementation Plan: <feature>
[Brief description of the requirements and goals of the feature]

## Architecture and design
Describe the high-level architecture and design considerations.

## Tasks
Break down the implementation into smaller, manageable tasks using a Markdown checklist format.

## Open questions
Outline 1-3 open questions or uncertainties that need to be clarified.

  2. 创建规划聊天模式 .github/chatmodes/plan.chatmode.md，它定义了规划角色。在规划模式下，代理被指示不要执行实施任务，而是专注于创建实施计划。

    要创建聊天模式，请在命令面板中运行聊天：配置聊天模式 > 创建新的自定义聊天模式文件命令。

    如果您想访问 GitHub 问题以获取上下文，请务必安装 GitHub MCP 服务器。

    您可能希望配置 model 元数据属性以使用针对推理和深度理解进行优化的语言模型。

    以下 plan.chatmode.md 文件为规划聊天模式提供了一个起点。

    ---
description: 'Architect and planner to create detailed implementation plans.'
tools: ['fetch', 'githubRepo', 'problems', 'usages', 'search', 'todos', 'github/github-mcp-server/get_issue', 'github/github-mcp-server/get_issue_comments', 'github/github-mcp-server/list_issues']
---
# Planning Mode

You are an architect focused on creating detailed and comprehensive implementation plans for new features and bug fixes. Your goal is to break down complex requirements into clear, actionable tasks that can be easily understood and executed by developers.

## Workflow

1. Analyze and understand: Gather context from the codebase and any provided documentation to fully understand the requirements and constraints.
2. Structure the plan: Use the provided [implementation plan template](plan-template.md) to structure the plan.
3. Pause for review: Based on user feedback or questions, iterate and refine the plan as needed.

  3. 您现在可以在“聊天”视图中选择计划聊天模式，并输入一个任务以实施新功能。它将根据提供的模板生成包含实施计划的响应。

    例如，输入以下提示以创建新功能的实施计划：添加带有电子邮件和密码的用户身份验证，包括注册、登录、注销和密码重置功能。

    您还可以引用 GitHub 问题以提供特定上下文：实施问题 #43 中的功能，在这种情况下，代理将获取问题描述和评论以提出要求。

  4. （可选）创建 提示文件 .github/prompts/plan.prompt.md，该文件调用计划模式并指示代理从提供的功能请求创建实施计划。

    以下 plan-qna.prompt.md 文件为规划提示提供了一个不同的起点，使用相同的工作流但添加了一个澄清步骤。

    ---
mode: plan
description: Create a detailed implementation plan.
---
Briefly analyze my feature request, then ask me 3 questions to clarify the requirements. Only then start the planning workflow.

  5. 在“聊天”视图中，输入 /plan-qna 斜杠命令以调用澄清规划提示，并在提示中提供要实施功能的详细信息。

    例如，输入以下提示：/plan-qna 添加一个客户详细信息页面，用于显示和编辑客户信息

    代理将提出澄清问题以更好地理解要求，然后再创建实施计划，从而减少任何误解。

提示

使用聊天模式定义遵循多轮过程并使用特定工具的工作流。单独使用它们或与提示文件结合使用，以添加相同工作流的不同变体和配置。

第 3 步：生成实施代码

在生成并完善实施计划后，您现在可以使用 AI 通过从实施计划生成代码来实施该功能。

  1. 对于较小的任务，您可以直接实施该功能，方法是提示代理根据实施计划生成代码。

    对于较大或复杂的功能，您可以切换到代理模式并提示它将实施计划保存到文件（例如，<my-feature>-plan.md）或将其作为注释添加到提及的 GitHub 问题中。然后，您可以打开新的聊天，并在提示中引用实施计划文件以重置聊天上下文。

  2. 您现在可以指示代理根据您在上一步中创建的实施计划实施该功能。

    例如，输入一个聊天提示，如 implement #<my-plan>.md，它引用了实施计划文件。

    提示

    代理模式经过优化，可执行多步骤任务并根据计划和项目上下文找出实现目标的最佳方法。您只需提供计划文件或在提示中引用它。

  3. 对于更定制化的工作流，请创建一个专门根据计划实施代码的自定义聊天模式 .github/chatmodes/implement.chatmode.md。

    以下 tdd.chatmode.md 文件为测试驱动的实施聊天模式提供了一个起点。

    ---
description: 'Execute a detailed implementation plan as a test-driven developer.'
---
# TDD Implementation Mode
Expert TDD developer generating high-quality, fully tested, maintainable code for the given implementation plan.

## Test-driven development
1. Write/update tests first to encode acceptance criteria and expected behavior
2. Implement minimal code to satisfy test requirements
3. Run targeted tests immediately after each change
4. Run full test suite to catch regressions before moving to next task
5. Refactor while keeping all tests green

## Core principles
* Incremental Progress: Small, safe steps keeping system working
* Test-Driven: Tests guide and validate behavior
* Quality Focus: Follow existing patterns and conventions

## Success criteria
* All planned tasks completed
* Acceptance criteria satisfied for each task
* Tests passing (unit, integration, full suite)
    提示

    由于较小的语言模型非常擅长遵循明确的指令来生成代码，因此 implement 聊天模式受益于将 model 属性设置为语言模型。

提示

让代理重新审视：创建一个新聊天（⌘N (Windows, Linux Ctrl+N)），并要求代理根据实施计划审查代码更改。这有助于识别任何遗漏的要求或不一致之处。

最佳实践和常见模式

遵循这些最佳实践有助于您建立可持续且有效的上下文工程工作流。

上下文管理原则

从小处着手并迭代：从最少的项目上下文开始，并根据观察到的 AI 行为逐步添加细节。避免上下文过载，这会稀释焦点。

保持上下文最新：随着代码库的演变，定期审计和更新项目文档（使用代理）。过时的上下文会导致过时或不正确的建议。

使用渐进式上下文构建：从高级概念开始，逐步添加细节，而不是一开始就用全面的信息淹没 AI。

保持上下文隔离：将不同类型的工作（规划、编码、测试、调试）保存在单独的聊天会话中，以防止上下文混淆。

文档策略

创建活文档：将您的自定义指令、聊天模式和模板视为不断发展的资源。根据观察到的 AI 错误或缺点对其进行完善。

专注于决策上下文：优先考虑有助于 AI 做出更好的架构和实施决策的信息，而不是详尽的技术细节。

使用一致的模式：建立并记录编码约定、命名模式和架构决策，以帮助 AI 生成一致的代码。

引用外部知识：链接到 AI 在生成代码时应考虑的相关外部文档、API 或标准。

工作流优化

实施反馈循环：持续验证 AI 是否正确理解您的上下文。当发生误解时，尽早提出澄清问题并纠正。

使用增量复杂性：增量构建功能，在增加复杂性之前验证每个步骤。这可以防止复合错误并维护可工作的代码。

分离关注点：对不同的活动（规划与实施与审查）使用不同的聊天模式，以保持专注、相关的上下文。

版本控制您的上下文：使用 Git 跟踪上下文工程设置的更改，从而允许您恢复有问题的更改并了解什么效果最好。

要避免的反模式

上下文倾倒：避免提供过多、不集中的信息，这些信息无助于直接决策。

不一致的指导：确保所有文档都与您选择的架构模式和编码标准保持一致。

忽视验证：不要假设 AI 正确理解您的上下文。在进行复杂实施之前，务必测试理解程度。

一刀切：不同的团队成员或项目阶段可能需要不同的上下文配置。在您的方法中保持灵活性。

衡量成功

成功的上下文工程设置应能实现：

  • 减少反复沟通：减少纠正或重定向 AI 响应的需要
  • 一致的代码质量：生成的代码遵循既定模式和约定
  • 更快的实施：减少解释上下文和要求的时间
  • 更好的架构决策：AI 建议的解决方案符合项目目标和约束

扩展上下文工程

对于团队：通过版本控制共享上下文工程设置，并为维护共享上下文建立团队约定。

对于大型项目：考虑使用指令文件创建具有项目范围、模块特定和功能特定上下文层的上下文层次结构。

对于长期项目：建立定期上下文审查周期，以使文档保持最新并删除过时信息。

对于多个项目：创建可在不同代码库和领域中采用的可重用模板和模式。

通过遵循这些实践并不断完善您的方法，您将开发一个上下文工程工作流，该工作流可以增强 AI 辅助开发，同时保持代码质量和项目一致性。

相关资源

了解有关在 VS Code 中自定义 AI 的更多信息

10/09/2025
© . This site is unofficial and not affiliated with Microsoft.