编辑
2026-01-06
AI
00
请注意,本文编写于 46 天前,最后修改于 46 天前,其中某些信息可能已经过时。

目录

VSCode Agent 提示词详细分析文档
目录
概述
文件清单
文件结构分析
1. Prompt.txt(核心基础提示词)
2. 模型特定版本(gpt-5.txt, gpt-4o.txt 等)
GPT-5 / GPT-5 Mini(最完整版本)
GPT-4.1(中等完整度)
GPT-4o(简化版本)
Claude Sonnet 4(简化版本)
Gemini 2.5 Pro(简化版本)
3. nes-tab-completion.txt(Tab 自动补全)
4. chat-titles.txt(聊天标题生成)
核心组件分析
1. 身份定义(<identity>)
2. 核心指令(<instructions>)
2.1 Agent 模式(高级版本)
2.2 上下文理解策略
2.3 代码修改原则
3. 工具使用规范(<toolUseInstructions>)
3.1 并行执行策略
3.2 工具调用前导
3.3 上下文获取
4. 文件编辑规范
4.1 apply_patch(高级模型)
4.2 inserteditinto_file(通用)
4.3 replacestringin_file(简化模型)
5. 任务管理系统(GPT-5/5-Mini)
5.1 使用场景
5.2 工作流程
6. 工程思维提示(GPT-5/5-Mini)
6.1 软件工程师思维
6.2 测试优先
7. 质量门控(GPT-5/5-Mini)
8. 响应模式(GPT-5/5-Mini)
8.1 轻量级模式
8.2 完整工程工作流
9. 输出格式规范
9.1 Markdown 格式
9.2 标题使用
9.3 命令展示
9.4 避免的内容
模型特定版本对比
功能对比表
版本演进路径
工具系统分析
工具分类
1. 代码探索工具
2. 文件操作工具
3. 执行工具
4. 验证工具
5. 项目管理工具
6. 高级工具(GPT-5/5-Mini)
7. 信息工具
8. 笔记本工具
特殊功能模块
1. Tab 自动补全(nes-tab-completion.txt)
1.1 核心机制
1.2 输出要求
1.3 注意事项
2. 聊天标题生成(chat-titles.txt)
2.1 核心要求
2.2 示例
关键设计模式
1. 分层模型策略
2. 工具优先原则
3. 上下文最大化模式
4. 渐进式细化模式
5. 质量保证模式(GPT-5/5-Mini)
6. 进度可见性模式(GPT-5/5-Mini)
与 Cursor 的对比
相似之处
主要差异
1. 编辑工具策略
2. 代码引用
3. 工具生态系统
4. 模型支持
5. 特殊功能
最佳实践总结
1. 工具使用最佳实践
2. 文件编辑最佳实践
3. 上下文收集最佳实践
4. 任务管理最佳实践(GPT-5/5-Mini)
5. 通信最佳实践
6. 质量保证最佳实践(GPT-5/5-Mini)
总结

VSCode Agent 提示词详细分析文档

来源: https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools

目录

  1. 概述
  2. 文件结构分析
  3. 核心组件分析
  4. 模型特定版本对比
  5. 工具系统分析
  6. 特殊功能模块
  7. 关键设计模式
  8. 与 Cursor 的对比
  9. 最佳实践总结

概述

VSCode Agent(GitHub Copilot)的提示词系统是一个专门为 Visual Studio Code 编辑器设计的 AI 编程助手框架。该系统针对不同的 AI 模型进行了优化,并提供了完整的工具生态系统来支持代码编辑、搜索、执行等操作。

文件清单

文件名类型用途模型基础
Prompt.txt基础提示词核心提示词和工具定义通用
gpt-5.txt模型特定GPT-5 优化版本GPT-5
gpt-5-mini.txt模型特定GPT-5 Mini 优化版本GPT-5 Mini
gpt-4o.txt模型特定GPT-4o 优化版本GPT-4o
gpt-4.1.txt模型特定GPT-4.1 优化版本GPT-4.1
claude-sonnet-4.txt模型特定Claude Sonnet 4 优化版本Claude Sonnet 4
gemini-2.5-pro.txt模型特定Gemini 2.5 Pro 优化版本Gemini 2.5 Pro
nes-tab-completion.txt功能特定Tab 自动补全功能通用
chat-titles.txt功能特定聊天标题生成通用

文件结构分析

1. Prompt.txt(核心基础提示词)

结构组成:

<identity> - 身份定义 <instructions> - 核心指令 <toolUseInstructions> - 工具使用规范 <editFileInstructions> - 文件编辑规范 <functions> - 工具函数定义(JSON 格式) <context> - 上下文信息 <reminder> - 提醒事项 <tool_format> - 工具调用格式

核心特点:

  • 包含完整的工具定义(18+ 个工具)
  • 强调自主执行和上下文理解
  • 使用 insert_edit_into_file 作为主要编辑工具
  • 支持语义搜索、文件操作、终端执行等

关键指令:

  • "You are an agent—keep going until the user's query is completely resolved"
  • "NEVER print out a codeblock with file changes unless the user asked for it"
  • "Use the insert_edit_into_file tool to edit files"

2. 模型特定版本(gpt-5.txt, gpt-4o.txt 等)

共同结构:

<identity> - 身份定义(GitHub Copilot) <instructions> - 增强的指令集 <toolUseInstructions> - 工具使用规范 <applyPatchInstructions> - Patch 应用规范(高级模型) <todoListToolInstructions> - 任务管理(高级模型) <notebookInstructions> - 笔记本编辑规范 <outputFormatting> - 输出格式规范 <reminderInstructions> - 提醒指令

版本差异:

GPT-5 / GPT-5 Mini(最完整版本)

  • 任务管理系统manage_todo_list 工具
  • Patch 系统apply_patch 工具(优先于 insert_edit_into_file
  • 工程思维提示<engineeringMindsetHints>
  • 质量门控<qualityGatesHints>
  • 响应模式<responseModeHints>
  • 进度检查点:每 3-5 个工具调用后检查点
  • 要求理解<requirementsUnderstanding>

GPT-4.1(中等完整度)

  • Agent 模式:自主执行直到完成
  • Patch 系统apply_patch 工具
  • 任务管理:无 manage_todo_list
  • 工程思维提示:无
  • 质量门控:无

GPT-4o(简化版本)

  • 基础 Agent 模式
  • Patch 系统:使用 replace_string_in_file
  • 任务管理:无
  • 高级功能:无

Claude Sonnet 4(简化版本)

  • 基础 Agent 模式
  • Patch 系统:使用 replace_string_in_file
  • 任务管理:无

Gemini 2.5 Pro(简化版本)

  • 基础 Agent 模式
  • Patch 系统:使用 replace_string_in_file
  • 任务管理:无

3. nes-tab-completion.txt(Tab 自动补全)

特殊用途:

  • 用于代码编辑时的 Tab 键自动补全
  • 基于上下文预测开发者下一步要写的代码
  • 不执行工具调用,只生成代码建议

核心机制:

  • 分析 <|code_to_edit|> 标签内的代码
  • 考虑最近查看的代码片段、编辑历史、光标位置
  • 预测并完成开发者可能的下一个操作
  • 保持代码风格一致性

输出格式:

  • 只返回 <|code_to_edit|> 标签内的修订代码
  • 不包含行号标记(#|
  • 不包含标签本身

4. chat-titles.txt(聊天标题生成)

特殊用途:

  • 为聊天对话生成简洁的标题
  • 标题长度约 8 个词或更少
  • 不包含引号

示例:

  • "Git rebase question"
  • "Installing Python packages"
  • "Location of LinkedList implentation in codebase"
  • "Adding a tree view to a VS Code extension"
  • "React useState hook usage"

核心组件分析

1. 身份定义()

标准身份:

You are an expert AI programming assistant, working with a user in the VS Code editor. When asked for your name, you must respond with "GitHub Copilot".

核心原则:

  • 遵循 Microsoft 内容政策
  • 避免侵犯版权的内容
  • 拒绝有害、仇恨、种族主义、性别歧视、低俗或暴力内容
  • 保持回答简短和非个人化

2. 核心指令()

2.1 Agent 模式(高级版本)

核心特征:

  • 自主执行:持续工作直到任务完全解决
  • 主动行动:用户期望 AI 主动工作,不要问不必要的问题
  • 进度更新:在并行、只读上下文收集后提供简洁的进度更新
  • 避免重复:不要在工具调用后重复自己

关键指令:

You are an agent—keep going until the user's query is completely resolved before ending your turn. ONLY stop if solved or genuinely blocked.

2.2 上下文理解策略

策略:

  1. 先收集上下文,再执行任务

    • 不要假设情况
    • 先收集上下文,然后执行任务或回答问题
  2. 大块读取

    • 优先读取大的、有意义的代码块
    • 避免连续的小段读取
    • 可以并行读取多个文件
  3. 语义搜索优先

    • 不知道确切字符串时使用 semantic_search
    • 知道确切字符串时使用 grep_search
  4. 符号追踪

    • 追踪关键符号到其定义和使用
    • 读取足够大的上下文块以避免遗漏

2.3 代码修改原则

核心原则:

  • 永远不要输出代码块显示文件更改(除非用户要求)
  • 使用工具:使用适当的编辑工具
  • 永远不要输出终端命令代码块(除非用户要求)
  • 执行命令:使用 run_in_terminal 工具

编辑工具选择:

  • GPT-5/5-Mini/4.1:优先使用 apply_patch,回退到 insert_edit_into_file
  • 其他模型:使用 replace_string_in_fileinsert_edit_into_file

3. 工具使用规范()

3.1 并行执行策略

应该并行的情况:

  • 读取多个文件
  • 多个独立的只读操作
  • 组合 grep_searchfile_search

不应该并行的情况:

  • semantic_search(不能并行调用)
  • run_in_terminal(必须顺序执行)
  • 编辑操作(可能冲突)
  • 依赖操作(需要前一个的输出)

3.2 工具调用前导

GPT-5/5-Mini 要求:

  • 每个工具调用批次前必须有一个一句话的 "why/what/outcome" 前导
  • 每 3-5 个工具调用后必须检查点进度
  • 如果创建或编辑超过 ~3 个文件,立即检查点

示例:

"Searching the codebase for authentication logic to understand the current implementation."

3.3 上下文获取

策略:

  • 追踪关键符号到其定义和使用
  • 读取足够大的、有意义的代码块
  • 不知道确切字符串时使用语义搜索
  • 知道确切字符串时使用精确搜索或直接读取
  • 避免冗余读取(内容已附加且足够时)

4. 文件编辑规范

4.1 apply_patch(高级模型)

格式:

*** Begin Patch *** Update File: [file_path] @@ class BaseClass @@ def method(): [3 lines of pre-context] -[old_code] +[new_code] +[new_code] [3 lines of post-context] *** End Patch

关键规则:

  • 默认显示每个更改上方和下方各 3 行上下文
  • 如果 3 行上下文不足以唯一标识,使用 @@ 操作符
  • 可以使用多个 @@ 语句跳转到正确上下文
  • 必须使用与原始代码相同的缩进风格(制表符或空格)
  • 使用未转义的制表符字符

优势:

  • insert_edit_into_file 更快
  • 更精确的编辑定位
  • 支持多个区域的更改

4.2 insert_edit_into_file(通用)

格式:

// ...existing code... changed code // ...existing code... changed code // ...existing code...

关键规则:

  • 避免重复现有代码
  • 使用注释表示未更改的区域
  • 工具很智能,只需要提供最小提示
  • 尽可能简洁

示例:

typescript
class Person { // ...existing code... age: number; // ...existing code... getAge() { return this.age; } }

4.3 replace_string_in_file(简化模型)

关键规则:

  • 包含要替换字符串前后 3-5 行未更改的代码
  • 确保替换是唯一的
  • 可以多次使用同一文件
  • 仅在 insert_edit_into_file 失败时使用

5. 任务管理系统(GPT-5/5-Mini)

5.1 使用场景

应该使用:

  • 需要规划和跟踪的复杂多步骤工作
  • 用户提供多个任务或请求
  • 接收需要多个步骤的新指令
  • 在开始任何 todo 之前(标记为进行中)
  • 完成每个 todo 后立即(单独标记完成)
  • 将较大任务分解为较小的可操作步骤

不应该使用:

  • 单一、简单的任务(一步完成)
  • 纯对话/信息请求
  • 只是读取文件或执行简单搜索

5.2 工作流程

关键流程:

  1. 使用具体、可操作的项目规划任务
  2. 在开始工作前标记一个 todo 为进行中
  3. 完成该特定 todo 的工作
  4. 立即标记完成
  5. 向用户更新非常简短的证据说明
  6. 移动到下一个 todo

6. 工程思维提示(GPT-5/5-Mini)

6.1 软件工程师思维

方法:

  • 概述一个小的"契约"(2-4 个要点):输入/输出、数据形状、错误模式、成功标准
  • 列出 3-5 个可能的边界情况:空/null、大/慢、认证/权限、并发/超时
  • 确保计划涵盖这些情况

6.2 测试优先

方法:

  • 首先编写或更新最小可重用测试(快乐路径 + 1-2 个边界)
  • 使用项目的测试框架
  • 然后实现直到测试通过

7. 质量门控(GPT-5/5-Mini)

在完成前:

  • 构建(Build)
  • Lint/类型检查(Lint/Typecheck)
  • 单元测试(Unit tests)
  • 小型冒烟测试(Small smoke test)

报告:

  • 只报告增量(PASS/FAIL)
  • 包括简要的"要求覆盖"行,将每个要求映射到其状态(Done/Deferred + 原因)

8. 响应模式(GPT-5/5-Mini)

8.1 轻量级模式

使用场景:

  • 问候、闲聊
  • 不需要工具或编辑的简单/直接问答

特点:

  • 保持简短
  • 跳过 todo 列表和进度检查点
  • 除非必要,否则避免工具调用

8.2 完整工程工作流

使用场景:

  • 多步骤任务
  • 需要编辑/构建/测试
  • 有歧义/未知数

特点:

  • 使用检查清单
  • 分阶段
  • 检查点

9. 输出格式规范

9.1 Markdown 格式

规则:

  • 使用反引号格式化文件名或符号
  • 使用适当的 Markdown 格式
  • 保持对话式和有趣

9.2 标题使用

GPT-5/5-Mini 规范:

  • 使用二级标题(##)作为顶级部分
  • 使用三级标题(###)作为子部分
  • 动态选择标题以匹配任务和内容
  • 不要硬编码固定的部分名称
  • 只在有意义且非空内容时创建部分
  • 保持标题简短和描述性
  • 可以添加有品味的 emoji(最小且专业)

标题顺序(适用时):

  • actions > artifacts > how to run > performance > notes

9.3 命令展示

规则:

  • 命令应在带语言标签的围栏代码块中
  • 保持命令可复制
  • 每行一个命令
  • # 开头的注释是可以的

9.4 避免的内容

不要:

  • 使用字面脚手架标签("Plan:"、"Task receipt:"、"Actions:")
  • 以填充确认开始("Sounds good"、"Great"、"Okay, I will…")
  • 重复未更改的计划或部分

模型特定版本对比

功能对比表

功能特性GPT-5GPT-5-MiniGPT-4.1GPT-4oClaude-4Gemini-2.5
Agent 模式
apply_patch
replace_string_in_file
任务管理
工程思维提示
质量门控
响应模式
进度检查点
要求理解
笔记本支持
输出格式优化

版本演进路径

基础 Prompt.txt ↓ GPT-4o / Claude-4 / Gemini-2.5(简化 Agent) ↓ GPT-4.1(添加 apply_patch) ↓ GPT-5 / GPT-5-Mini(完整功能集)

工具系统分析

工具分类

1. 代码探索工具

semantic_search(语义搜索)

  • 用途:在代码库中进行自然语言搜索
  • 特点
    • 如果工作区很小,返回完整内容
    • 如果工作区很大,返回相关代码片段
    • 不能并行调用
  • 最佳实践:不知道确切字符串时使用

list_code_usages(代码使用列表)

  • 用途:列出函数、类、方法、变量等的所有使用
  • 使用场景
    • 查找接口或类的示例实现
    • 检查函数在整个代码库中的使用方式
    • 更改函数、方法或构造函数时包含和更新所有使用

grep_search(文本搜索)

  • 用途:在工作区中进行文本搜索
  • 限制:最多 20 个结果
  • 最佳实践:知道确切字符串时使用

file_search(文件搜索)

  • 用途:通过 glob 模式搜索文件
  • 限制:最多 20 个结果
  • 示例
    • **/*.{js,ts} - 匹配所有 js/ts 文件
    • src/** - 匹配 src 文件夹下的所有文件
    • **/foo/**/*.js - 匹配任何 foo 文件夹下的所有 js 文件

get_vscode_api(VS Code API 参考)

  • 用途:获取 VS Code API 参考以回答 VS Code 扩展开发问题
  • 使用场景:VS Code 扩展开发工作区

2. 文件操作工具

read_file(读取文件)

  • 特点
    • 必须指定行范围
    • 如果文件较大,将提供其余文件的概述
    • 如果返回的内容不足,可以再次调用

list_dir(列出目录)

  • 特点:结果中名称以 / 结尾的是文件夹,否则是文件

insert_edit_into_file(插入编辑)

  • 用途:将新代码插入现有文件
  • 特点
    • 每个需要修改的文件使用一次
    • 系统很智能,只需要最小提示
    • 避免重复现有代码

apply_patch(应用补丁)(高级模型)

  • 用途:使用特殊格式的补丁编辑文件
  • 优势:比 insert_edit_into_file 更快
  • 格式:使用 *** Update File:@@ 操作符

replace_string_in_file(替换字符串)(简化模型)

  • 用途:替换文件中的字符串
  • 要求:包含前后 3-5 行上下文以确保唯一性

3. 执行工具

run_in_terminal(在终端运行)

  • 特点
    • 状态在工具调用之间持久化
    • 长时间运行的背景进程必须传递 isBackground=true
    • 如果命令可能使用分页器,必须禁用它(例如 git --no-pager 或添加 | cat
    • 不能并行调用

get_terminal_output(获取终端输出)

  • 用途:获取之前使用 run_in_terminal 启动的终端命令的输出
  • 使用场景:检查后台进程的输出

4. 验证工具

get_errors(获取错误)

  • 用途:获取代码文件中的编译或 lint 错误
  • 使用场景
    • 用户提到文件中的错误或问题时
    • 编辑文件后验证更改

test_search(测试搜索)

  • 用途
    • 对于源代码文件,查找包含测试的文件
    • 对于测试文件,查找包含被测试代码的文件

5. 项目管理工具

create_new_workspace(创建新工作区)

  • 用途:帮助用户在 VS Code 工作区中创建任何项目
  • 支持:TypeScript、MCP 服务器、VS Code 扩展、Next.js、Vite 等

get_project_setup_info(获取项目设置信息)

  • 用途:提供基于项目类型和编程语言的项目设置信息
  • 要求:必须先调用创建工作区的工具

install_extension(安装扩展)

  • 用途:在 VS Code 中安装扩展
  • 限制:仅作为新工作区创建过程的一部分使用

create_new_jupyter_notebook(创建新 Jupyter 笔记本)

  • 用途:在 VS Code 中生成新的 Jupyter 笔记本
  • 限制:仅在用户明确请求创建新 Jupyter 笔记本时调用

6. 高级工具(GPT-5/5-Mini)

manage_todo_list(管理任务列表)

  • 用途:在整个编码会话中规划和跟踪任务
  • 工作流程
    1. 规划具体、可操作的项目
    2. 在开始工作前标记一个 todo 为进行中
    3. 完成该特定 todo 的工作
    4. 立即标记完成
    5. 向用户更新非常简短的证据说明
    6. 移动到下一个 todo

7. 信息工具

fetch_webpage(获取网页)

  • 用途:从网页获取主要内容
  • 使用场景:用户正在查找特定网页的信息时

get_changed_files(获取更改的文件)

  • 用途:获取活动 git 仓库中当前文件更改的 git diff
  • 注意:也可以使用 run_in_terminal 运行 git 命令

update_user_preferences(更新用户偏好)

  • 用途:保存用户的偏好设置
  • 使用场景
    • 用户纠正了您所做的某些事情
    • 表达了编码偏好
    • 传达了需要记住的事实

8. 笔记本工具

edit_notebook_file(编辑笔记本文件)

  • 用途:编辑工作区中的笔记本文件
  • 限制:不要使用 insert_edit_into_file 或执行 Jupyter 相关命令

run_notebook_cell(运行笔记本单元格)

  • 用途:运行笔记本单元格
  • 限制:不要执行 Jupyter 相关命令

copilot_getNotebookSummary(获取笔记本摘要)

  • 用途:获取笔记本的摘要
  • 包含:所有单元格列表、Cell Id、Cell 类型、Cell 语言、执行详情、输出的 mime 类型

特殊功能模块

1. Tab 自动补全(nes-tab-completion.txt)

1.1 核心机制

输入信息:

  • recently_viewed_code_snippets:开发者最近查看的代码片段
  • current_file_content:当前文件的内容
  • edit_diff_history:编辑差异历史
  • area_around_code_to_edit:要编辑区域周围的代码
  • <|cursor|>:光标位置

处理流程:

  1. 审查上下文:分析提供的资源
  2. 评估当前代码:确定标签内的代码是否需要更正或增强
  3. 建议编辑:如果需要更改,确保它们符合开发者的模式并提高代码质量
  4. 保持一致性:确保缩进和格式遵循现有代码风格

1.2 输出要求

格式:

  • 只提供标签内的修订代码
  • 不包含行号标记(#|
  • 不包含标签本身(<|code_to_edit|><|/code_to_edit|>
  • 不输出标签外存在的重复代码

示例:

输入: <|code_to_edit|> this cycle repeats <|/code_to_edit|> 输出: this cycle repeats

1.3 注意事项

  • 不要撤销或还原开发者的最后一次更改(除非有明显的拼写错误或错误)
  • 不要包含 #| 形式的行号
  • 如果请求可能违反 Microsoft 内容指南,用 "Sorry, I can't assist with that." 道歉

2. 聊天标题生成(chat-titles.txt)

2.1 核心要求

格式:

  • 标题不应包含引号
  • 约 8 个词或更少
  • 简洁且非个人化

2.2 示例

好的标题:

  • "Git rebase question"
  • "Installing Python packages"
  • "Location of LinkedList implentation in codebase"
  • "Adding a tree view to a VS Code extension"
  • "React useState hook usage"

特点:

  • 简洁明了
  • 捕获对话的主要主题
  • 使用技术术语
  • 描述具体任务或问题

关键设计模式

1. 分层模型策略

设计理念:

  • 不同能力的模型使用不同复杂度的提示词
  • 高级模型(GPT-5)获得完整功能集
  • 简化模型(GPT-4o)获得基础功能集

优势:

  • 优化成本效益
  • 根据模型能力定制体验
  • 保持一致性

2. 工具优先原则

核心思想:

  • 优先使用工具而非输出代码块
  • 直接执行操作而非建议
  • 减少用户手动操作

实现:

  • NEVER print out a codeblock with file changes unless the user asked for it
  • NEVER print out a codeblock with a terminal command to run unless the user asked for it
  • Use the appropriate edit tool instead

3. 上下文最大化模式

策略:

  • 先收集上下文,再执行任务
  • 大块读取而非小段读取
  • 并行读取多个文件
  • 追踪符号到定义和使用

4. 渐进式细化模式

方法:

  • 从语义搜索开始(不知道确切字符串时)
  • 根据结果缩小范围
  • 使用精确搜索(知道确切字符串时)
  • 读取相关文件

5. 质量保证模式(GPT-5/5-Mini)

流程:

  1. 工程思维:定义契约、边界情况、测试优先
  2. 实施:编写代码
  3. 质量门控:构建、Lint、测试、冒烟测试
  4. 要求覆盖:映射每个要求到状态

6. 进度可见性模式(GPT-5/5-Mini)

机制:

  • 任务列表:规划和跟踪
  • 进度检查点:每 3-5 个工具调用
  • 工具批次前导:一句话说明 why/what/outcome
  • 文件创建检查点:创建或编辑超过 ~3 个文件时

与 Cursor 的对比

相似之处

特性VSCode AgentCursor
Agent 模式
语义搜索
工具优先
并行执行
任务管理✅ (GPT-5)✅ (Agent 2.0)
代码引用规范✅ (Agent 2.0)
状态更新✅ (GPT-5)✅ (Agent 2.0)

主要差异

1. 编辑工具策略

VSCode Agent:

  • 高级模型:apply_patch(优先)→ insert_edit_into_file(回退)
  • 简化模型:replace_string_in_fileinsert_edit_into_file

Cursor:

  • 大文件(>2500行):search_replace
  • 小文件:edit_file
  • 笔记本:edit_notebook

2. 代码引用

VSCode Agent:

  • 无特殊代码引用格式
  • 使用标准 Markdown 代码块

Cursor:

  • 严格的代码引用格式:startLine:endLine:filepath
  • 区分 CODE REFERENCES 和 MARKDOWN CODE BLOCKS

3. 工具生态系统

VSCode Agent:

  • 18+ 个工具
  • 包括 VS Code 特定工具(get_vscode_apiinstall_extension
  • 包括项目管理工具(create_new_workspace

Cursor:

  • 12+ 个工具
  • 包括 Cursor 特定工具(fetch_pull_requestcreate_diagram
  • 包括记忆系统(update_memory

4. 模型支持

VSCode Agent:

  • 6 个模型特定版本
  • 功能根据模型能力分层

Cursor:

  • 主要针对 GPT 系列优化
  • 版本演进而非模型特定

5. 特殊功能

VSCode Agent:

  • Tab 自动补全(nes-tab-completion.txt
  • 聊天标题生成(chat-titles.txt

Cursor:

  • 无特殊功能模块
  • 所有功能集成在主提示词中

最佳实践总结

1. 工具使用最佳实践

应该做的:

  • 优先使用工具而非输出代码块
  • 并行执行独立的只读操作
  • 在工具调用批次前提供前导说明(GPT-5)
  • 每 3-5 个工具调用后检查点(GPT-5)
  • 使用语义搜索探索代码库
  • 使用精确搜索查找已知字符串

不应该做的:

  • 并行调用 semantic_search
  • 并行调用 run_in_terminal
  • 并行执行编辑操作
  • 向用户提及工具名称
  • 输出代码块显示更改(除非用户要求)

2. 文件编辑最佳实践

应该做的:

  • 编辑前先读取文件(如果不在上下文中)
  • 使用 apply_patch(高级模型)或 replace_string_in_file(简化模型)
  • 包含足够的上下文以确保唯一性
  • 使用 // ...existing code... 表示未更改的代码
  • 编辑后验证错误

不应该做的:

  • 假设文件内容
  • 重复现有代码
  • 忽略缩进风格
  • 循环修复错误超过 3 次

3. 上下文收集最佳实践

应该做的:

  • 先收集上下文,再执行任务
  • 读取大的、有意义的代码块
  • 并行读取多个文件
  • 追踪符号到定义和使用
  • 使用语义搜索探索

不应该做的:

  • 假设情况
  • 连续小段读取
  • 忽略已提供的上下文
  • 不追踪符号依赖

4. 任务管理最佳实践(GPT-5/5-Mini)

应该做的:

  • 为复杂任务创建任务列表
  • 在开始工作前标记任务为进行中
  • 完成后立即标记完成
  • 提供简短的证据说明
  • 按顺序处理任务

不应该做的:

  • 为简单任务创建任务列表
  • 批量更新任务状态
  • 跳过任务列表步骤
  • 在任务列表中包含操作性任务

5. 通信最佳实践

应该做的:

  • 使用反引号格式化文件名和符号
  • 保持对话式和有趣
  • 使用适当的 Markdown 格式
  • 提供简洁的进度更新
  • 避免填充确认

不应该做的:

  • 使用字面脚手架标签
  • 以填充确认开始
  • 重复未更改的计划
  • 过度使用 emoji 或感叹号

6. 质量保证最佳实践(GPT-5/5-Mini)

应该做的:

  • 定义契约和边界情况
  • 测试优先方法
  • 运行质量门控(构建、Lint、测试)
  • 映射要求到状态
  • 验证代码工作

不应该做的:

  • 忽略边界情况
  • 跳过测试
  • 忽略错误
  • 不验证更改

总结

VSCode Agent(GitHub Copilot)的提示词系统是一个精心设计的、针对不同 AI 模型优化的框架,具有以下特点:

  1. 分层设计:根据模型能力提供不同复杂度的功能
  2. 工具优先:强调使用工具而非输出代码块
  3. 上下文理解:最大化上下文收集和理解
  4. 质量保证:高级模型包含完整的质量保证流程
  5. 进度可见性:通过任务列表和检查点保持用户知情
  6. 特殊功能:Tab 自动补全和聊天标题生成

关键演进方向:

  • 从基础 Agent 到完整工程工作流
  • 从简单编辑工具到高级 Patch 系统
  • 从基础功能到质量保证和进度跟踪
  • 从单一模型到多模型优化

与 Cursor 的主要区别:

  • VSCode Agent 更注重 VS Code 集成和项目管理
  • Cursor 更注重代码引用规范和记忆系统
  • VSCode Agent 有模型特定的优化版本
  • Cursor 有更统一的版本演进

文档生成时间:2025年 分析基于:VSCode Agent 文件夹中的所有提示词文件

本文作者:lixf6

本文链接:

版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!