同一个 AI有时像资深工程师有时像刚进项目第一天的新人。很多人会把这种差异归因于模型状态、提示词写得好不好或者当天选到的模型版本。但在真实项目里更常见的原因其实是AI 每次拿到的上下文不同。如果只给它一句“帮我改一下分类筛选”它需要自己猜项目结构、业务规则、验收标准和测试方法。它猜对了结果看起来就很惊艳猜错了改动就会迅速偏离目标。所以 AI 编程进入真实项目以后真正需要解决的不是一句提示词怎么写得更长而是如何稳定地把正确的信息交给它。这件事可以叫作上下文工程。提示词解决一次沟通上下文工程解决持续协作Prompt Engineering 当然有价值。它可以让一次任务的目标更清楚让输出格式更稳定也可以提醒 AI 先分析、再修改、最后验证。但提示词很难长期承载一个项目的全部背景。项目规则、目录结构、历史决策、测试命令和风险边界不应该在每次对话中重新解释一遍。如果这些信息只存在聊天记录里就会出现几个问题换一个任务后背景信息容易漏掉换一个会话后AI 又要重新认识项目不同人给出的约束不一致重要决策散落在很长的对话里无法复用上下文工程关注的则是另一组问题AI 做这个任务需要知道什么哪些信息是项目级固定规则哪些信息只属于当前任务哪些信息应该来自测试结果哪些信息需要随着项目变化而更新它不是把提示词写得更复杂而是把信息放到正确的位置。AI 编程需要五层上下文我会把一个真实项目里的上下文分成五层。1. 项目级上下文这一层回答“这个项目是什么”。内容包括技术栈、目录职责、启动命令、测试命令、代码风格、不能随便修改的文件以及生成文件和源文件的区别。它适合放在AGENTS.md、项目 README 或repo-map.md中。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 编程质量 模型能力 × 上下文质量 × 验证反馈模型能力决定它能做什么上下文质量决定它是否知道该做什么验证反馈决定它能不能发现自己做错了什么。Prompt 决定 AI 这一次怎么回答上下文工程决定 AI 能不能在一个真实项目里持续稳定地工作。