免费 AI IDE
AI 编程助手答非所问，通常不是“再写长一点提示词”就能解决。更有效的方法是把上下文分成任务、证据、约束三层：先说明本轮只要完成什么，再提供最小必要文件，最后给出可执行的验收标准。
你可能遇到过这种情况：让 AI 修一个金额校验，它顺手重构了无关模块；让它补测试，它却沿用已经废弃的接口。本文用“订单金额允许 0、拒绝负数”这个小任务，演示一套 AI 上下文管理方法。它适用于聊天式助手、IDE Agent 和命令行 Agent，不依赖某个具体产品。
一、先看结论：上下文三层各管什么
| 层级 | 回答的问题 | 包含内容 | 不包含内容 |
|---|---|---|---|
| 任务层 | 要改什么？ | 目标、范围、接口、禁止项、验收 | 无关模块背景、历史设计 |
| 证据层 | 依据是什么？ | 当前代码、调用点、测试、失败日志 | 整个仓库、全部日志 |
| 约束层 | 怎样算完成？ | 测试命令、退出码、边界用例 | “请认真思考”等角色修饰 |
一句话：上下文不是越多越好，而是让模型能回答“要改什么、依据是什么、怎样算完成”。
二、先理解上下文为什么越多不一定越好
上下文窗口是模型本轮可以参考的信息总量。以 GitHub Copilot CLI 为例，官方上下文说明 指出，用户消息、模型回复、工具调用、工具结果和系统规则都会占空间。长会话还可能经过压缩，早期细节被概括后，不会逐字保留。
因此，“把整个仓库、全部日志和十次失败对话都贴进去”并不等于信息更完整。无关内容会稀释当前任务，冲突内容会让模型不知道哪个版本为准，超长工具输出还可能挤掉真正重要的接口约束。
AI 编程上下文的目标不是越多越好，而是让模型能回答三个问题：要改什么、依据是什么、怎样算完成。如果你正在建立基础使用习惯，可以先看 AI编程技能教程 中的任务拆分，再把本文方法用于真实仓库。
| 上下文过多的问题 | 后果 |
|---|---|
| 无关文件太多 | 模型注意力被稀释，改错文件 |
| 新旧版本同时出现 | 模型不知道以哪个为准 |
| 日志过长 | 真正重要的接口约束被挤掉 |
| 重复失败对话 | 模型被错误猜测带偏 |
| 缺少验收命令 | 无法判断是否完成 |
三、第一步：把需求压成一张任务卡
先用五行写清任务，不要从“帮我优化一下项目”开始。下面是一张可直接改写的任务卡：
目标：修改 validateAmount，使 0 合法、负数和非数字输入被拒绝。
范围：只改 src/amount.js 和 test/amount.test.js。
接口：validateAmount(value) 返回 { ok, reason }，字段名不能变。
禁止：不改调用方，不引入新依赖，不重排无关代码。
验收：npm test -- amount.test.js 通过，新增 0、-1、"10" 三个用例。这张卡把“金额校验”从模糊愿望变成可检查任务。每一行的作用如下：
| 任务卡行 | 作用 | 示例 |
|---|---|---|
| 目标 | 描述期望行为 | 0 合法、负数拒绝 |
| 范围 | 控制改动面 | 只改两个文件 |
| 接口 | 防止 AI 自创结构 | 返回 { ok, reason } |
| 禁止 | 保护现有代码 | 不改调用方、不加依赖 |
| 验收 | 负责闭环 | 运行指定测试命令 |
五行已经足够，不必堆“请认真思考”“你是资深工程师”等角色修饰。
如果模型仍然要改范围外文件，先让它复述任务卡，再要求输出“计划修改的文件和原因”，确认后才写代码。这个动作能在生成前发现偏航，比改完几十个文件再回滚便宜。
四、第二步：只给最小证据包，不给仓库大杂烩
任务卡之后再提供证据。这个案例的最小证据包包含四项：
| 证据 | 是否必须 | 说明 |
|---|---|---|
| 当前函数 | 必须 | 暴露真实缺陷，如 !value 误判 0 |
| 直接调用点 | 必须 | 确认接口使用方式 |
| 现有测试 | 必须 | 保持断言风格和测试框架 |
| 失败日志 | 必须 | 给出最小失败输入与堆栈 |
| 配置文件 | 按需 | 只有影响运行命令时才加 |
| 历史设计文档 | 按需 | 只有包含当前接口约束时才加 |
// src/amount.js
export function validateAmount(value) {
// 缺陷：!value 会把数字 0 当成空值
if (!value) return { ok: false, reason: 'required' };
// 非数字类型被拒绝
if (typeof value !== 'number') return { ok: false, reason: 'number' };
// 只允许大于等于 0 的数字
return { ok: value >= 0, reason: value >= 0 ? '' : 'negative' };
}
这里的真实缺陷是 !value 会把数字 0 当成空值。只给报错截图时，AI 可能猜成表单字符串问题；给出这段最小代码后，判断依据就清楚了。你还应贴出现有测试的断言风格，避免模型换测试框架或杜撰 helper。
证据包要带来源标签，例如“当前分支文件”“最新测试输出”“接口文档 2026-09-10 版”。同一个函数若出现两个版本，必须明确哪份生效。需要让 Agent 调用仓库技能时，可以参考 Codex插件说明，但技能只能补充流程，不能替代任务所需的真实文件。
五、第三步：让输出自带验证，而不是只要答案
要求 AI 先写测试、再改实现，最后报告命令与结果。这个案例最小测试至少包含四个边界：0 合法、正数合法、负数拒绝、字符串拒绝。
import test from 'node:test';
import assert from 'node:assert/strict';
import { validateAmount } from './amount.js';
test('amount boundaries', () => {
// 0 应该合法
assert.deepEqual(validateAmount(0), { ok: true, reason: '' });
// 正数应该合法
assert.deepEqual(validateAmount(10), { ok: true, reason: '' });
// 负数应该被拒绝，原因是 negative
assert.deepEqual(validateAmount(-1), { ok: false, reason: 'negative' });
// 字符串应该被拒绝，原因是 number
assert.deepEqual(validateAmount('10'), { ok: false, reason: 'number' });
});预期结果（本示例未在独立项目执行）是 4 个断言全部通过。真正使用时，应让工具执行仓库自己的命令，并贴出退出码、测试总数和失败数。只说“测试已通过”信息不足，因为命令可能没运行、测试可能被跳过，也可能执行了错误目录下的同名文件。
AI 上下文管理到这里才完成闭环：任务卡控制方向，证据包支持推理，验收命令判断结果。下一轮对话只保留最终决定、改动 diff 和最新测试输出；已经证伪的猜测和重复日志可以移出当前会话。
| 验收信息 | 为什么重要 |
|---|---|
| 执行命令 | 确认跑的是正确测试 |
| 退出码 | 确认没有隐藏失败 |
| 测试总数 | 确认没有跳过用例 |
| 失败数 | 确认断言真实执行 |
| 关键输出 | 便于回放和排查 |
六、四种答非所问分别怎么修
| 问题现象 | 修复方法 | 补充材料 |
|---|---|---|
| 改错文件 | 补范围和文件职责 | 目录约定、文件用途 |
| 接口写错 | 贴真实调用点和类型定义 | 接口文档、示例返回值 |
| 逻辑看似正确但测试失败 | 提供最小失败输入与原始堆栈 | 完整错误信息，不只最后一行 |
| 长会话开始遗忘 | 新开一轮任务卡，压成短摘要 | 已确认结论、diff、最新测试 |
| 只给终端截图 | 同时提供文本日志 | 脱敏后的日志与路径 |
| 涉及敏感信息 | 先脱敏 | 密钥、客户数据、内部地址 |
还有一种常见失败：给 AI 一张终端截图。截图适合人看，却不利于搜索符号和复制路径。最好同时提供文本日志，并把无关下载进度、重复警告折叠掉。涉及密钥、客户数据和内部地址时，先脱敏；上下文质量不能以泄露敏感信息为代价。
每轮结束前，让 AI 回答三句话：
- “本轮改了什么”
- “用什么证据判断”
- “还有什么未验证”
如果它答不出，说明上下文闭环还没有建立，不宜继续扩大改动。
总结
减少答非所问的关键，不是把提示词写成长文，而是管理信息结构。任务层定义目标和范围，证据层提供当前代码与失败输入，约束层用测试和禁止项划边界。
执行时记住三步：
- 先写五行任务卡；
- 再给最小证据包；
- 最后要求执行验收命令。
把 AI 编程上下文当作一个会过期的工作台，只保留当前任务所需内容，你会得到更小的 diff、更明确的失败原因和更低的返工成本。
延伸学习
- 初次配置本地 Agent 时，可查 Codex安装指南；
- 需要核对命令行能力时，翻 CodeBuddy CLI参考；
- 想比较不同助手的定位，再读 AI编程助手横向对比，选择前先列清自己的任务类型。
常见问题
Q：一次应该给 AI 多少文件？
A：没有固定数量。先给目标文件、直接调用点、测试和必要配置；模型缺依据时再补。判断标准是每个文件都能解释它与当前任务的关系。
Q：每次都要重新介绍项目吗？
A：不需要。稳定的目录约定、编码规则可放项目指令；本轮目标、当前失败和临时限制仍应写进任务卡，避免旧规则盖过新事实。
Q：上下文满了只能换会话吗？
A：不一定。先删除重复日志并总结已确认结论；如果任务阶段已经切换，开新会话通常更清晰，同时保留必要的决策、diff 与测试结果。
Q：AI 能自己找上下文，为什么还要任务卡？
A：工具能找到文件，不代表知道优先级。任务卡告诉它哪些证据最重要、哪些目录不能改，以及最终要通过什么验收。
