AI 集成开发环境

是什么，为什么存在

AI 集成开发环境是在代码编辑器或 IDE 中加入大语言模型能力的开发环境。它可以把当前文件、选区、符号、诊断和用户附加的文件交给 大语言模型（large language model） ，再把返回内容显示为补全、对话回答、编辑建议或可执行操作。模型只是其中一层；项目系统、语言服务、版本控制界面和终端仍由 IDE 提供。

普通自动补全主要依据语法与已知符号给出短建议。AI 补全可以生成较长片段，对话可以解释代码或提出方案，智能体模式还可以请求读取文件、修改代码与运行命令。同一个产品可能同时提供这些形态，所以不要根据侧边栏名称判断能力；要看它实际取得了什么上下文，又能产生哪些副作用。

AI IDE 解决的是上下文切换成本。你不必把错误消息、类型定义和相邻实现逐段复制到网页对话中，也能在差异视图里接受或拒绝修改。它尤其适合代码阅读与编辑交替发生的任务，例如补齐一个分支、沿调用链重命名接口，或根据现有测试修复缺陷。

这类工具并不了解整个代码库。它看到的是编辑器和检索器为本次请求构造的有限视图，而且这个视图可能遗漏文件、包含过期内容，或把仓库中的不可信文本也当成指令。 上下文窗口（context window） 的容量有限，代码库索引也只是查找候选内容的手段，不是仓库真相的完整副本。

IDE 集成的价值在于让反馈更靠近代码，但它不保证模型更聪明。你可以从选区发起请求，在编辑器中查看精确差异，读取语言服务的错误，再运行项目自己的检查。任务若需要无人值守、稳定的标准流或机器可读的退出状态，就应选择明确提供这些契约的界面，例如 AI 编程 CLI 或后台智能体工作流。

四种交互形态

这四种形态可以共享模型，却有不同的控制边界。补全通常由你显式接受才进入文件；智能体模式可能在一次任务中连续产生多个编辑和命令请求。开始前先确认当前模式是否能写文件、运行终端、访问网络，以及每种操作怎样请求批准。

任务形状决定使用方式

短而局部的编辑通常不需要智能体循环。你已经知道文件和修改位置时，行内编辑或补全更容易控制，也更容易拒绝一个不合适的建议。让智能体重新搜索整个仓库，反而会扩大上下文和改动范围。

多文件任务只有在边界明确时才适合智能体模式。比如「重命名这个导出，并更新这两个包中的静态引用」给出了符号与范围；「统一所有命名」没有完成条件，会迫使模型自己发明判断标准。界面可以方便地展示结果，却不能替你补齐缺失的产品决策。

可以按下面的顺序选择：

1. 只需要下一小段代码时，使用补全，并在接受前读完建议。
2. 已知选区和目标转换时，使用行内编辑，并审查精确差异。
3. 需要解释、比较方案或定位入口时，先使用只读对话。
4. 需要跨文件搜索、修改与验证时，才使用带权限边界的智能体模式。

任务也可能在过程中切换形态。先用对话找出候选调用链，再开一个范围更窄的编辑任务，通常比让同一长会话边查边改更容易追踪。切换时重新写明当前目标，因为早期探索中的假设不应悄悄变成修改依据。

模式选择不应根据模型名称。真正影响风险的是上下文来源、可用工具、批准策略和交付证据。即使两个模式使用同一个模型，一个只返回文本，另一个可以运行终端，它们也有完全不同的安全边界。

工作原理

一次请求先从编辑器状态开始。IDE 可以取得当前文件、选区、光标位置、打开的标签页、语言服务诊断和版本控制状态；产品也可能通过代码库索引检索其他片段。自动选取的材料与用户显式附加的文件共同组成请求上下文，但具体规则因产品、设置和当前模式而异。

项目指令通常也会进入请求。它们可以记录构建命令、代码风格、目录边界和验收标准，减少每次重复说明。不过，指令文件是提供给模型的上下文，不是操作系统级策略。写下「不要修改迁移文件」不能代替宿主对写入路径的实际限制。

模型收到任务与上下文后，会返回文本或结构化的 工具调用（tool call） 。文本可以成为补全或编辑提议；工具调用则由 IDE 宿主检查，然后读取文件、应用修改或启动命令。模型本身不会直接保存文件，真正的副作用来自宿主与它调用的进程。

编辑结果应回到一个可见的差异视图。语言服务可以立即产生新的类型错误或语法诊断，测试和构建命令则提供运行时证据。智能体模式会把这些结果送入下一轮，让模型继续修正；在补全或行内编辑中，下一步通常由开发者决定。

图中的 Policy 必须由宿主执行。一个 审批门（approval gate） 可以暂停某次写入或命令，但批准范围仍要具体到工作区、操作和持续时间。允许一次测试命令，与允许之后任意终端命令，不是同一项授权。

上下文从哪里来

常见上下文来源各自回答不同问题。当前选区说明你正在处理什么；定义与引用说明符号怎样连接；诊断指出工具已经发现的错误；版本控制差异显示这次会话改了什么；项目指令则记录仓库约定。把所有来源都塞入请求会挤掉真正相关的代码，因此上下文选择需要优先级和容量限制。

显式附加是最容易审查的来源，因为你知道送入了哪些文件。自动检索适合在大型仓库中寻找候选片段，但命中结果必须回到源文件核对。打开过一个标签页不等于它仍在本次上下文中，索引找到了一个同名符号也不等于它属于正在构建的目标。

语言服务与模型各自负责什么

IDE 的语言服务根据项目配置解析语法、类型、定义与引用。它的结果通常比模型对符号关系的猜测更直接，但仍受当前构建目标、条件编译和索引刷新状态限制。一个灰掉的错误可能只是文件尚未纳入当前项目，而不是代码在所有目标中都有效。

模型擅长把任务说明、附近代码和工具结果组合成候选修改。它也可能补出语言服务无法推导的业务逻辑，但这种灵活性没有确定性保证。模型写出能通过解析的代码，只说明语法形状合理，不说明它选择了正确行为。

把两者组合时，先区分证据类型：

• 定义跳转和引用搜索说明 IDE 当前识别出的静态符号关系。
• 诊断说明某个已加载配置下的语法或类型问题。
• 模型回答说明它根据有限上下文提出的解释或建议。
• 测试与构建说明具体输入和目标上的实际工具结果。

这些信号可能互相矛盾。模型可能声称导入存在，而语言服务无法解析；静态检查可能通过，而测试暴露行为错误。不要让模型用更长的解释覆盖工具失败，应先查明命令、配置与目标是否正确，再决定代码还是检查环境需要修改。

诊断刷新也有时序。大范围重命名后，旧错误可能短暂保留，新错误也可能等依赖项目重新索引后才出现。交付前运行命令行检查可以避开部分界面缓存问题，并给出可保存的退出状态。

建议、写入与执行

建议只改变屏幕上的候选文本，写入会改变工作区，执行还会启动仓库代码或外部工具。这三层需要分别控制。一个合理的低风险起点是允许读取与生成建议，逐块批准写入，并只运行任务明确列出的验证命令。

权限应遵循 最小权限（least privilege） ：当前步骤只获得完成它所需的能力。对于不熟悉的仓库，先使用受限模式读取代码；对于会执行安装脚本、数据库迁移或部署命令的操作，应在隔离环境中检查具体命令和目标。

完成状态来自证据

模型说「已修复」只是一条自然语言输出。可靠的完成状态来自文件差异、命令、工作目录、退出码和没有执行的检查。IDE 中的绿色装饰可能只代表当前文件没有诊断，也可能来自尚未刷新的语言服务，不能替代仓库的验收命令。

把关键结果保存为 执行记录（execution transcript） ，至少包含运行的命令、工作目录、退出状态和跳过项。对小型交互编辑，终端历史与最终差异可能已经够用；对多文件智能体任务，最好保留结构化记录，便于复现与审计。

示例

下面的三个程序不调用某个厂商的 AI API。它们实现的是围绕 AI IDE 的可移植控制：选择有限上下文、审查建议范围、根据独立证据决定是否接受。三段代码使用同一个购物车修复任务，依次收紧会话边界。

选择有限且可说明的上下文

先给上下文来源排优先级，再设置容量与忽略目录。这里优先保留选区、诊断关联测试和显式附加配置；索引找到的长文档因超出预算而跳过，依赖目录则始终排除。

输出同时记录路径和来源，所以你可以解释为什么每个文件进入上下文。真实 IDE 会使用词元而不只是字节计算模型输入，而且可能对索引片段做切分；示例只演示可审计的优先级，不声称复制任何产品内部算法。

上下文清单也能暴露遗漏。若购物车总价依赖另一个包的货币舍入规则，你应显式添加该契约或对应测试，而不是只把预算调大。更大的上下文可能增加噪声，也不能修复错误的检索目标。

在应用前检查编辑建议

第二步把任务范围和基线版本写成数据。IDE 返回两个建议，其中源码修改属于允许范围，package.json 修改则需要单独解释，不能因为它与正确修改出现在同一回答中就一起接受。

const task = {
  baseline: "a13f8c2",
  allowed: new Set(["src/cart.js", "test/cart.test.js"]),
};

const proposals = [
  {
    path: "src/cart.js",
    before: "export const total = sum;",
    after: "export const total = sum ?? 0;",
  },
  {
    path: "package.json",
    before: '"test": "node --test"',
    after: '"test": "node --test --test-reporter=spec"',
  },
];

function verdict(edit, currentRevision) {
  if (currentRevision !== task.baseline) return "STALE";
  if (!task.allowed.has(edit.path)) return "OUTSIDE_SCOPE";
  if (edit.before === edit.after) return "NO_CHANGE";
  return "REVIEW";
}

for (const edit of proposals) {
  console.log(`${edit.path}: ${verdict(edit, "a13f8c2")}`);
}

src/cart.js: REVIEW
package.json: OUTSIDE_SCOPE

REVIEW 不表示修改正确，只表示它基于预期版本且尚未越界。仍需阅读前后代码、检查调用方并运行测试。OUTSIDE_SCOPE 也不一定表示建议毫无价值；它表示任务契约没有授权该修改，开发者必须拒绝它或明确扩大范围。

基线检查处理另一种 IDE 特有风险：你可能在模型生成建议后手工编辑了同一文件。此时旧的替换片段基于过期前像，强行应用可能覆盖新代码。支持差异预览的工具通常会尝试重新定位修改，但冲突解决仍要由当前文件内容决定。

用命令结果决定是否接受

最后一步检查两条必需命令与修改路径。测试通过、范围也正确，但检查命令返回非零状态，因此整个交付必须拒绝。不能把「部分通过」向上取整为完成。

const evidence = new Map([
  ["node --test test/cart.test.js", { status: 0, cwd: "/repo" }],
  ["npm run lint", { status: 1, cwd: "/repo" }],
]);

const required = [
  "node --test test/cart.test.js",
  "npm run lint",
];
const allowedPaths = new Set(["src/cart.js", "test/cart.test.js"]);
const changedPaths = ["src/cart.js", "test/cart.test.js"];

const failedChecks = required.filter((command) => {
  const result = evidence.get(command);
  return !result || result.status !== 0 || result.cwd !== "/repo";
});
const outsideScope = changedPaths.filter((path) => !allowedPaths.has(path));
const accepted = failedChecks.length === 0 && outsideScope.length === 0;

console.log(`checks=${failedChecks.length === 0 ? "PASS" : "FAIL"}`);
console.log(`scope=${outsideScope.length === 0 ? "PASS" : "FAIL"}`);
console.log(accepted ? "ACCEPT" : "REJECT");

checks=FAIL
scope=PASS
REJECT

工作目录也是证据的一部分。正确的命令在错误包目录中可能没有发现任何测试，或读取另一套配置后给出误导结果。实际记录还应保留标准错误、超时和输出截断状态；这里为了突出验收逻辑，只保存了退出状态与目录。

这三个例子形成一个最小控制链：先决定模型能依据什么，再决定哪些建议可以进入审查，最后决定修改是否达到交付条件。模型质量变化不会取消其中任何一步。即使建议完全由人编写，这些检查也仍然有用。

陷阱

修复方法： 对依赖精确接口或测试契约的任务，显式附加权威文件，并要求回答列出它使用的路径与假设。若工具能显示上下文清单，提交请求前检查一次；若不能，就用问题验证模型是否掌握关键签名，不要让它猜。

修复方法： 把允许写入的路径、可执行命令、网络访问和敏感资源限制交给 IDE 宿主、沙箱或容器执行。把仓库 Markdown、Issue 内容和代码注释都视为不可信数据；它们可以提供信息，不能自行扩大权限。

修复方法： 先看修改文件列表，再按差异块审查。把机械格式化与语义修改分开，确认删除内容和新增内容，并沿公共符号检查调用方。范围异常时先拒绝整块，再要求更小的修改，不要在未知基线上继续叠加补丁。

修复方法： 从仓库文档或 CI 配置确认验收命令，在已知工作目录中自己运行，并检查退出码、测试数量和跳过项。缺陷修复应先有能复现问题的测试；只运行新增测试还不能证明相邻行为没有回归。

修复方法： 使用忽略规则和显式附件清单，先脱敏再提供最小复现。检查产品、账户和组织的数据处理设置，但不要把设置说明当成数据分类策略。秘密值应留在模型上下文之外，并通过受控运行环境注入给确实需要它们的程序。

延伸阅读

• Visual Studio Code：Agents 概览
• Visual Studio Code：Chat context
• GitHub Docs：为 Copilot 添加自定义指令