掌握VS Code 第17讲——提示与上下文工程：在编辑器里喂对上下文

访问DeepWrite

排版设置

在这里统一调整字体、字号、目录停靠位置和正文显示方式，不挤占右上角工具条。

字体

字号

目录层级

目录停靠位置

决定目录固定在左侧还是右侧，方便按手势习惯或演示场景调整。

正文显示方式

决定正文是否保留独立阅读卡片背景；关闭后正文会更贴近整页背景。

中文长文先试中文经典；英文长文先试 English Essay。目录默认显示到 H2，可按需要扩到 H4；目录位置和正文显示方式也可以在这里统一调整。

朗读菜单

直接在 HTML 页面内朗读，下载文件和独立分享页都可使用。这里只保留最少功能。

当前状态：未开始

语音

语速 0.82x

高亮级别

浏览器支持时会记住上次朗读位置。

全屏专注式阅读说明

这页优先保留鼠标与触摸操作，让阅读、选词、点击链接和查看目录互不打扰。

单击正文空白区：同时显示或隐藏主题区和目录。
开始滚动正文：自动进入专注态，减少阅读时的视觉干扰。
双击正文空白区：进入或退出全屏专注式阅读状态。
全屏专注时，按 Esc 或点击“退出全屏专注”：退出全屏。

掌握VS Code 第17讲——提示与上下文工程：在编辑器里喂对上下文

一、场景钩子

上一讲我们说：Agent 失控的一大原因是"它不懂你的项目约定，于是自作主张"。那怎么让它懂？答案不在"写一段更华丽的 prompt"，而在你喂给它的上下文对不对。

先想一个画面。你让 AI"按项目规范重构这个函数"，它生成了一版——但风格和项目里其他地方完全两样，因为它根本不知道你们项目长什么样。你又试了一次，把整个相关文件复制进对话框，贴了三百行，它还是在错误的文件上改，因为那三百行里噪音太多、重点被淹。两次失败，不是你 prompt 写得不好，是你喂的上下文要么太少、要么太乱。

核心问题由此而来：在编辑器里，怎么把"AI 需要的正确信息"喂进它的上下文窗口？@workspace、@file、@vscode、指令文件这些机制分别解决什么？为什么"喂对上下文"比"写长 prompt"重要得多？本讲处理三件事：第一，上下文工程的机制——它本质不是"调 prompt 话术"，而是"把结构化信息接进模型窗口"；第二，它从哪来——从"把代码复制进聊天框"到"编辑器自动注入引用"；第三，也是重头戏——怎么用编辑器的上下文机制，把对的文件、对的约定、对的意图喂给 AI，让它改得对、不乱改。

二、机制讲透：上下文工程是"把对的信源接进窗口"，不是"写漂亮话"

先确立一件事：模型的质量上限，卡在它看得见什么。你给它错的、少的、乱的上下文，它再聪明也产出错的。所谓上下文工程，不是研究"怎么把 prompt 写得像诗"，而是把 AI 需要的正确信息，以结构化方式接进它的上下文窗口。

编辑器提供了一组"引用机制"，让这件事不用你手动搬运：

@file：直接引用某个文件（或某个符号），把它作为上下文注入。你不用把文件内容复制粘贴，只需说"参考 @file:utils.ts"，编辑器把那个文件喂进去。
@workspace：让 AI 在整个工程里搜索相关代码，把"相关片段"自动纳入上下文。它解决"相关代码在哪我也不知道"的场景——AI 先搜，再把搜到的喂给自己。
@vscode：引用编辑器当前状态（当前打开的文件、选中、报错、终端输出），让 AI 基于"你此刻在干什么"来答。
指令文件（instruction files）：项目级或个人的"系统指令"——你写下"本项目用 TypeScript 严格模式、禁止 any、测试用 vitest"，AI 每次对话都带着这条约定。它是持久化的上下文，不是每次手敲。

机制落点由此清晰：上下文工程的核心动作是"引用"而非"搬运"——编辑器把文件、工程、你的意图变成可引用的锚点，AI 直接读锚点指向的真实内容，你不必把整个文件粘进对话。这和第6讲跳转（靠 LSP 索引定位符号）、第12讲调试（靠 DAP 读运行时）完全同构：都是"平台把信息结构化，工具直接消费结构化信息"，而不是让你在文本流里手动找。可塑性在这里体现为：你配置指令文件、用引用机制组织上下文，平台把"对的信源"精准喂给 AI——AI 看到什么，由你组织。

要分清边界：上下文工程解决"AI 看见什么"，它不解决"AI 能不能做对"——喂对了上下文，AI 仍可能逻辑错，那要回阶段四验收。上下文工程是把"地基"铺对，地基对了，上层才稳。

三、来龙去脉：从"复制粘贴进聊天框"到"编辑器自动注入引用"

最早用 AI 写代码，流程是割裂的：在编辑器里看代码，切到聊天网页，把相关片段复制进去，贴一大段，再等回答，再复制回来。上下文靠"人肉搬运"——既累又容易漏（你贴的往往不是最相关的那块），还容易超窗口（贴太多反而淹没重点）。

引用机制的出现，把"搬运"变成"注入"：你不再把代码从编辑器"搬"到对话，而是用 @file 指一下、用 @workspace 让它自己搜，编辑器自动把真实内容接进模型窗口。范式转折在于：上下文从"手动搬运的文本"变成"编辑器维护的结构化引用"。这和第13讲 tasks.json（命令变成可引用动作）、第14讲 launch.json（入口变成可声明配置）是同一种思路在 AI 维度的延伸——你不再每次手工拼，而是用机制把"对的信源"固化下来。可塑性在这里兑现：指令文件由你写、提交仓库，团队共享同一套 AI 行为约定——AI 看到的"项目规范"，从某人的口头交代变成仓库里的文件。

四、破除误解：四个关于上下文工程的错觉

误解一："prompt 越长越好，信息越多 AI 越聪明。" 恰恰相反。上下文窗口是有限的，你堆一堆无关代码，真正相关的那块反而被稀释、被淹没，模型还可能被噪音带偏。判断：精准引用胜过堆字数——用 @file 指向那一个关键文件，比把十个文件糊进去强。上下文工程是"做减法"：只留最相关的。

误解二："@workspace 万能，让它自己搜就行。" 它是利器，但不是魔法。@workspace 的搜索基于文本/语义相似，可能引入"看起来相关其实无关"的文件，也可能漏掉"逻辑相关但字面不沾边"的文件。判断：用 @workspace 探索"相关代码在哪"很好，但它选出来的文件你要过目——别把"它搜到的"当成"该看的"全部，关键文件该用 @file 显式点名。

误解三："指令文件是玄学/提示词技巧，没用。" 太小看它了。指令文件是"团队 AI 行为契约"——你把编码规范、架构约定、验收要求写进去，AI 每次都带着走，新人用 AI 时也自动遵守团队习惯。判断：凡团队有规范，就写进指令文件提交仓库——它是 AI 维度的"代码规范文档"，比在群里反复叮嘱稳得多。

误解四："上下文工程就是调 prompt 话术。" 这是把"工程"降格成"修辞"。上下文工程是信息组织——你决定哪些文件、哪些约定、哪些约束进入窗口，以及以什么方式进入（引用 vs 粘贴、持久指令 vs 临时说）。判断：凡"AI 答非所问"，先查上下文是不是喂错了源，而不是怪 prompt 没写好——前者是工程问题，后者是修辞幻觉。

五、实践影响（重头戏）：用编辑器的引用机制，把对的上下文喂给 AI

下面按"配置—效率—工程—风险"四路给具体决策。

实践落点一：用 @file 显式引用"要改的那个文件"，别全粘。 这是最常用的落点。场景：让 AI 改 utils.ts 里的一个函数。直接 @file:utils.ts 再下指令，比把文件内容复制进对话框干净、且保证它读的是真实最新内容。判断：凡要改特定文件，先用 @file 点名——可塑性在这里体现为：你用引用机制精准控制 AI 的"视觉焦点"，不靠搬运、不靠它猜。

实践落点二：用 @workspace 探索"相关代码在哪"，但逐条审它选的文件。 场景：你不知道"处理订单状态"的逻辑散在哪些文件。让 AI 用 @workspace 搜，它列出相关文件，你过目后把关键那几个用 @file 显式加入。判断：@workspace 是"侦察兵"不是"裁决者"——它帮你找，你来决定哪些真相关，避免噪音灌进窗口。

实践落点三：把项目规范写进指令文件，提交仓库，团队共享。 具体：建一个项目级指令文件，写明"语言与版本、禁止的写法、目录约定、测试框架、验收步骤"。AI 每次对话自动带这条约定，生成的代码天然贴着团队习惯。判断：凡团队有约定，固化成指令文件——这和第4讲"工作区设置提交仓库"、第13讲"tasks.json 共享"同构：把"环境怎么跑、怎么验、怎么写"从个人记忆变成仓库资产。可塑性让你配置 AI 的行为边界。

实践落点四：用个人指令文件沉淀你的偏好，不与项目约定冲突。 你在项目规范之外，还有自己的习惯（比如"解释时代码用中文注释""先给思路再给代码"）。写成个人级指令文件，它叠加在项目指令之上。判断：项目约定管"团队一致"，个人指令管"你的手感"——两层分开，前者提交共享、后者本地留存，互不覆盖却协同。

实践落点五：把"验证方式"写进指令，让 AI 自带验收意识（呼应阶段四）。 场景：在项目指令里写"生成代码后，说明如何在第13讲的任务里跑测试验证"。AI 产出时会主动提示验证路径，而不是甩一段代码就完。判断：验收闸门（第12/13/14讲）既然必须过，就把它写进上下文，让 AI 从"产出即结束"变成"产出并指验"——可塑性在这里体现为：你用指令把"可控性要求"前置进 AI 的上下文。

实践落点六：治理上下文噪音——排除无关文件、控制引用范围。 场景：你的工程里有一大堆生成的代码、第三方副本，@workspace 容易把它们当相关。用编辑器排除规则（类似第6讲 files.exclude 的思路）让搜索跳过噪音目录。判断：上下文窗口是稀缺资源，凡"搜到的十有八九是噪音"，先治理信源范围——这和第6讲"让跳转更准"是同一种治理直觉：喂给工具的信息越干净，工具越准。

实践落点七：指令文件要版本化、要评审，它是代码资产。 指令文件会随项目演进——今天禁止 any，明天放宽到允许 unknown。把它当代码评审：改指令要提、要别人看，避免某人悄悄写进"一律用 any"把团队规范带偏。判断：凡把约定写进文件，就按文件的纪律管它——可塑性给的配置权，要用评审兜住，避免"配置漂移"变成"团队行为悄悄变质"。

实践落点八：指令文件 + 任务 + 配置，构成 AI 的"受控跑道"（接阶段四/18讲）。 把这几讲串起来看：指令文件告诉 AI"怎么写、怎么验"（本讲），tasks.json 把"怎么跑、怎么验"固化成动作（第13讲），launch.json 把"怎么起、挂调试"固化成入口（第14讲），下一讲 MCP 把"外部工具"接进来（第18讲）。四者合起来，AI 不是在一个空白聊天框里裸奔，而是在"约定清晰、动作可跑、入口可验、工具可达"的受控跑道上工作。判断：凡要把 AI 接进团队工作流，别只教它写——把指令、任务、配置一起配齐，才是"可控性"的完整落地。

实践落点九：把"组织上下文"当成给 AI 写 brief 的硬技能，重要任务前花两分钟，回报远超时间。 场景：你要让 AI 做一件涉及多模块的大事。别上来就扔一句指令，先花两分钟：用 @file 点名核心两三个文件、用 @workspace 侦察相关代码并你过目、在指令里写明约束与验收。这两分钟的"写 brief"，往往决定 AI 产出是对是歪——和第15讲"Chat 先给上下文再指令"、第16讲"喂饱上下文 Agent 才不乱改"是同一原则。判断：凡任务重要、牵涉广，上下文工程值得前置投入；它不像写代码那样显眼，却是"AI 改得对"的地基。可塑性在这里体现为：你用引用机制和指令文件，把"对的信源"精准组织进窗口——AI 的视野由你配，地基你铺，楼才稳。把这两分钟当成"给 AI 的开工 briefing"，比事后改它跑偏的产出省下的是十倍时间。

六、承前启后：一句话记住

回到开头那个画面。你让 AI 按规范重构，它生成了一版完全不贴项目的风格——根源不是 prompt 没写好，是你喂的上下文要么太少、要么太乱。上下文工程不是"写漂亮话"，是"把对的信源接进窗口"：@file 显式点名关键文件、@workspace 先侦察再你裁决、指令文件把团队规范变成 AI 每次自带的约定。它和第6讲跳转、第12讲调试同构——平台把信息结构化，工具直接消费，而不是你手动搬运。可塑性在这里体现得实在：你用引用机制和指令文件组织 AI 看到什么，AI 的视野由你配，不是它瞎猜。

这一讲把"喂对上下文"讲透了。下一讲进入扩展生态与 MCP——上下文再对，AI 若接触不到真实工具和数据（数据库 schema、内部 API、文档），它仍只能"猜"。MCP 怎么把外部能力接进编辑循环，正是让 AI 从"猜"变"查"的关键一跃。

能带走的一句话：上下文工程不是写长 prompt，是把对的信源接进窗口——@file 点名关键文件、@workspace 先侦察你裁决、指令文件把团队约定变 AI 自带规范；喂对上下文，AI 才改得对、不乱改。