參加你附近的 ，瞭解 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.