同一套 AI 模型，有时表现如同资深工程师，有时却像刚入职的新手。这种性能差异，许多人归因于模型状态、提示词编写质量或当日分配的模型版本。然而在真实项目中，更常见的根源在于：AI 每次获取到的上下文信息并不相同。
如果只给 AI 一句“帮我改一下分类筛选”，它需要自行猜测项目结构、业务规则、验收标准以及测试方法。猜对了，输出结果令人惊艳；猜错了，改动就会迅速偏离目标。
因此，AI 编程进入真实项目后，真正的挑战不在于如何写出更长的提示词，而在于如何稳定地将正确的信息传递给 AI。这一过程，可以称为上下文工程。
提示词解决单次沟通，上下文工程实现持续协作
提示词工程（Prompt Engineering）的价值毋庸置疑：它能让单次任务的目标更清晰，输出格式更稳定，还能引导 AI 先分析、再修改、最后验证。然而，提示词很难长期承载一个项目的完整背景。项目规则、目录结构、历史决策、测试命令以及风险边界，这些信息不应当在每次对话中重新解释。
如果这些背景只存在于聊天记录中，便会引发若干问题：
- 切换任务后，背景信息容易遗漏
- 开启新会话后，AI 需要重新熟悉项目
- 不同成员给出的约束不一致
- 重要决策散落在长对话中，无法复用
上下文工程则聚焦于另一组问题：AI 完成当前任务需要知道哪些信息？哪些是项目级的固定规则？哪些只属于当前任务？哪些信息应来自测试结果？哪些需要随项目变化而更新？其核心不是把提示词写得更复杂，而是将信息放置在正确的位置。
AI 编程需要五层上下文
一个真实项目中的上下文，可划分为五个层次。
1. 项目级上下文
这一层回答“这个项目是什么”。内容包括技术栈、目录职责、启动命令、测试命令、代码风格、不可随意修改的文件，以及生成文件与源文件的区别。这些信息适合放在 AGENTS.md、项目 README 或 repo-map.md 中。一旦固定，AI 便无需每次都猜测。
2. 任务级上下文
这一层回答“这次要解决什么问题”。至少应包含目标、范围、不做什么、验收标准以及已知风险。一句“增加筛选功能”通常不够，更明确的任务应说明筛选对象、支持的条件、默认行为、空结果如何展示，以及哪些旧行为不能改变。
3. 文件级上下文
这一层回答“具体从哪里改”。包括相关文件、调用关系、数据流、已有抽象以及修改边界。不要一开始就把整个仓库塞给 AI，先让它根据项目地图定位相关模块，再提供足够完成当前任务的代码，结果通常更容易控制。
4. 验证级上下文
这一层回答“怎么证明改对了”。内容可以是单元测试、接口测试、构建命令、截图检查、人工验收点以及最近一次失败日志。缺少验证上下文，AI 很容易把“代码写完”误认为“任务完成”。
5. 历史级上下文
这一层回答“为什么要这样做”。例如某个接口为何保留旧字段，某个模块为何没有抽象，某个兼容逻辑为何不能删除。这类信息如果不记录，AI 很容易把历史约束当成坏味道，顺手重构出新问题。
一套够用的最小组合
不需要一开始就建立庞大的知识库。一个小项目先准备以下几类文件，已经能解决大部分重复解释问题：
AGENTS.md或 Skill：固定协作规则和安全边界repo-map.md：入口、模块、测试和常见修改路径- issue 模板：目标、范围和验收标准
- 测试矩阵：场景、输入、预期和优先级
- decision log：重要决策和不能违反的历史约束
- 发布检查清单：上线前必须验证的事项
这些文件不必非常冗长，但必须容易找到、容易更新，并且能被任务流程实际使用。
一个具体的任务上下文模板
复制代码## 目标## 不做什么## 相关文件## 已有规则## 验收标准## 必须运行的验证命令## 已知风险
将这份模板放入 issue 或任务卡中，AI 的工作起点便会稳定许多。执行前，可要求 AI 先复述目标、列出影响范围和验证方法；执行后，再要求它对照验收标准逐项检查。这比不断追加“注意一点”“不要改坏别的地方”更有效，因为约束已内化为任务的一部分，而非临时提醒。
上下文也需要维护
上下文工程并非一次性写完文档就结束。项目结构会变，测试命令会变，旧的决策也可能被新方案替代。每次 AI 踩到重复出现的坑，都应判断是否值得写回项目规则；每次发现常见任务都有固定修改路径，也可补进仓库地图。过时的文档则要及时删除或标记失效，否则上下文越多，噪声越大。
高质量的上下文不是“信息最多”，而是“当前任务拿到的信息足够、可信、可验证”。
在记账 App 里怎么落地
以“给交易列表增加分类筛选”为例，实际操作中，不会直接扔需求给 AI，而是先准备一张任务卡：
复制代码## 目标在交易列表中支持按分类筛选，默认显示全部交易。## 不做什么- 本次不修改统计页的统计口径
- 本次不新增自定义分类
- 本次不改动数据库表结构## 相关文件- frontend/src/pages/BillsPage.vue
- frontend/src/components/TransactionList.vue
- backend/app/api/transactions.py
- backend/app/services/transaction_service.py## 验收标准- 选择分类后列表只显示对应账单
- 清除分类后恢复全部账单
- 无结果时显示空状态
- 原有分页和日期筛选不受影响## 验证命令- pytest backend/tests/test_api_integration.py
- npm run build --prefix frontend
然后让 AI 按固定顺序工作：先读 repo-map.md，再检查相关文件，接着列出影响范围和实现计划，等确认后才改代码。修改结束后，必须把每一条验收标准对应到具体测试或人工检查。这个过程比“帮我增加分类筛选”多了几分钟准备时间，却省掉了大量来回纠错。更重要的是，任务完成以后，这张任务卡还可以直接变成 PR 描述和测试记录。
怎么判断上下文是不是过量
上下文也不是越多越好。如果把整个仓库、所有历史聊天和所有日志一起交给 AI，真正重要的信息反而会被淹没。可以问自己三个问题作为筛选：
- 这条信息是否会改变实现方案？
- 这条信息是否能帮助判断边界或风险？
- 这条信息是否能被测试或文件引用验证？
三个问题都答不上来的内容，通常可以先不放进当前任务。把固定规则、当前需求、相关代码和真实验证结果分开存放，比做一个不断增长的“超级上下文”更可靠。
最后
AI 编程从玩具走向真实项目以后，提示词只是入口，上下文才是工程能力。结果可以近似理解为：
复制代码AI 编程质量 = 模型能力 × 上下文质量 × 验证反馈
模型能力决定它能做什么，上下文质量决定它是否知道该做什么，验证反馈决定它能不能发现自己做错了什么。