上下文工程
Context Engineering
高级通用上下文工程（Context Engineering）是为一次 AI 任务选择、组织和更新模型可见信息的工作。它解决的是信息缺失、过时或互相冲突导致的答非所问；比如让改代码的 Agent 先看到相关文件、项目约定和验收条件。
你可能会说：「我想让 AI 改这个功能时看懂项目现状，别漏掉约定，也别被旧讨论带偏。」
动手看看改代码前的上下文组装
任务：修复登录失效后的跳转请求返回 401 时，引导用户重新登录。
本次模型可见信息
代码：src/api/client.ts统一请求入口，已有 401 分支。
约定：复用登录导航工具使用 goToLogin，勿硬编码地址。
验收：登录后回到原页面跳转携带 returnTo，并补回跳测试。
示意修改方案
在 client.ts 的 401 分支修改
调用 goToLogin
携带 returnTo，补回跳测试
方案为预设示意，并非实时模型输出
提供相关代码
提供项目约定
提供验收条件
混入过时文档
开关决定这次任务让模型看见什么。试着移除材料或混入旧文档，对比左右两栏；悬停或聚焦信息卡可高亮查看。重点不是塞得多，而是相关、明确且有效。
要点上下文工程在安排什么？
- 1
先判断任务缺少什么信息
你让 Agent 修改结算页时，光说“加优惠码”不够。它还得知道价格在哪里计算、现有接口怎么返回错误，以及什么结果算完成。先找出这些信息，才能减少凭空猜测。
- 2
把相关材料放进当前任务
上下文可以来自你的说明、代码文件、工具查询结果和项目规则。我们会按任务挑选材料，说明哪些是现状、哪些只是参考；因为把整段历史都塞进去，旧决定可能盖过新需求。
- 3
随工作进展更新关键信息
Agent 查完代码后，最初的假设可能已经不成立。让它根据查到的实现调整计划，并保留已确认的约束和未解决的问题，这样后续修改与测试才有共同依据。
容易混淆的地方
提示词通常指你写给模型的指令；上下文工程还关心指令之外，模型能看到哪些文件、历史和工具结果，以及它们何时更新。RAG 是从资料中检索相关内容的一种做法，可以为上下文工程供料，但不能替你判断哪些资料可信、是否适合当前任务。
什么时候用
适合用
- 让 Agent 接手已有网站的功能开发，需要结合当前代码、项目约定和验收条件。
- 做客服 AI 工具时，需要按用户问题取出相关帮助文档，并区分现行规则与旧版本。
- 一次开发任务跨多轮对话和工具调用，需要保留已确认的决定，同时更新被代码证实的事实。
不适合用
- 只是把网页标题改成指定文字，文件和位置都已明确，直接修改并检查结果就够了。
- 按固定公式计算运费且输入字段明确，用普通代码实现和测试，比让模型读取资料再判断可靠。
- 需求是阻止无权限用户读取订单，不靠调整模型上下文解决；先做服务端权限控制。
练一练选一个答案，看看解释
你让 Agent 为已有后台添加导出功能。它读到一年前的讨论说“所有人可导出”，但当前代码按角色限制数据访问。你会怎么安排下一步？
让 AI 帮你做复制给 AI Agent 直接用
请先为这次后台导出功能做上下文工程：查看相关代码和项目规则，列出已确认的权限约束、缺失信息及互相冲突的资料；不要把旧讨论直接当作现行要求。确认导出范围后再给出修改计划和验收点。