把 AI 想成参加开卷考试的同学先建立直觉
模型能力 ≈ 已经学会的知识
它懂一些编程知识,就像同学上过 Java 课。但它未必知道你们项目用了什么数据库、老师要求什么、哪一版接口才是最新的。
上下文 ≈ 这次放在桌上的材料
题目、规则、代码片段、参考文档、刚运行出来的报错,都可能成为它这次回答的依据。
缺材料,要补;材料乱,要整理。
把最新题目放清楚,拿走过期答案,按需查阅资料。解题途中得到的新证据,也要放回桌上。
书桌再大也不等于解题一定正确;放得下,与能用好,是两回事。
类比的边界:模型不是人。这里的“看到”指信息实际进入模型本次输入;文件在电脑里、文档在网站上,并不代表它已被读取。
一次 AI 回答,可能参考哪些信息?不只是聊天记录
目标与约束
要完成什么?哪些地方不能改?怎样才算通过?
如:实现借书接口,不改变现有数据库表结构。
项目事实与资料
现有代码、依赖版本、表结构、接口文档、规范与示例。
如:JDK 17、Spring Boot 3,以及项目真实的 pom.xml。
过程状态与工具结果
此前确认的决定、当前进度、文件读取结果、测试日志。
如:接口已完成,但“重复借阅”测试仍失败。
提示词工程与上下文工程有什么区别?两个概念放在一起看
| 角度 | 提示词工程 | 上下文工程 |
|---|---|---|
| 主要关注 | 指令怎么表达得清楚 | 整个任务过程中提供什么信息、何时提供、怎样维护 |
| 编程例子 | “请分析原因,再给最小修改方案。” | 同时提供异常栈、相关代码、依赖版本与复现步骤;修复后补充测试结果 |
| 典型动作 | 明确角色、目标、格式与示例 | 筛选文件、检索资料、记录决定、清理过期内容、更新状态 |
二者有重叠:写好提示词是上下文工程的一部分。一段包含必要背景的清晰指令,本身就能体现上下文工程。
工具、MCP、Skill,和上下文工程是什么关系?从材料走向能力
它们都是实践上下文工程的重要机制,但各自解决的问题不同。
工具:能做什么
读取文件、搜索代码、查询数据库、运行测试,都是具体能力。
书桌类比:查资料、做实验的设备。
工具说明帮助 AI 选择能力;工具返回的内容,可以成为下一轮判断的依据。
协议:怎样接进来
MCP(模型上下文协议)为 AI 应用连接外部工具和数据提供标准化方式。
书桌类比:连接不同设备的通用接口。
接通只意味着有了访问途径,不代表全部资料已经被读取。
指导包:按什么方法做
把某类任务的流程、参考资料和可选脚本组织成可复用的技能包。
书桌类比:按需翻阅的实验指导书。
这里指以 SKILL.md 等文件组织的 Agent Skills,不是模型训练得到的能力。
工具调用:模型提出请求,程序真正执行
比如 AI 需要知道商品表有哪些字段。它不能只靠“想一想”知道真实数据库结构,而要请求工具提供证据。
应用提供工具名称、用途和参数要求,例如“查询指定表的结构”。
模型生成结构化调用:查询 book 表。
应用检查参数与权限,执行对应程序,获取真实表结构。
字段、类型或错误信息送回模型,模型据此继续工作。
调用请求示意
{
"tool": "get_table_schema",
"arguments": {"table": "book"}
}
这是教学伪格式;实际请求格式取决于模型 API 和工具框架。
工具结果示意
表:book 字段:id、title、stock stock:整数,表示当前可借库存
运行工具是一次动作;把结果加入上下文,才让 AI 获得这条新信息。调用失败时,也应根据错误处理,不能假装成功。
MCP:统一接法,不是另一个大模型
可以把 MCP 理解为一套双方都遵守的“连接与交流约定”。AI 应用通过 MCP 客户端连接 MCP 服务端,再访问服务端开放的能力。服务端通常对接文件、业务系统或数据库等。
| MCP 可提供的内容 | 通俗解释 | 教学示例 |
|---|---|---|
| Tools · 工具 | 可调用的功能 | 查询某张表的结构 |
| Resources · 资源 | 可读取的数据或内容 | 项目接口规范文档 |
| Prompts · 提示模板 | 可复用的交互模板 | 按固定维度进行代码评审 |
服务端不一定提供全部三类能力。工具也可以由应用内置或直接通过 API 接入,不必都经过 MCP。实际能使用哪些能力取决于客户端、服务端与授权。
Skill:把“会做这类事的方法”打包
例:Java Web 接口开发 Skill
任务指导:先读项目约定,再找现有接口作参考,最后实现并验证。
参考资料:统一返回格式、异常处理规范、测试案例。
可选脚本:运行检查或生成固定结构的辅助程序。
这些内容可以组织为 SKILL.md、参考文件和脚本目录;具体结构与触发机制由实现决定。
按需展开,避免一次塞满
先看简介:知道这个 Skill 适合什么任务。
相关时读指导:需要开发接口,才加载详细工作步骤。
需要时取资料:涉及异常处理,才进一步读取对应规范。
这叫“渐进式加载”。脚本可由执行环境运行,不必把全部源码都放进上下文。
给图书系统增加借阅接口:三者如何配合?一次完整协作
假设编程助手具有文件与终端工具,连接了可查询表结构的 MCP 服务,并安装了接口开发 Skill。下面是一个可能的工作过程。
| 步骤 | AI 应用与模型的配合 | 上下文发生了什么变化? |
|---|---|---|
| ① 明确任务 | 用户说明:每人最多借 5 本,遵循现有规范。 | 加入目标、业务规则和约束。 |
| ② 加载 Skill | 读取接口开发指导,明确先分析、后实现、再测试。 | 加入本次任务所需的流程与规范。 |
| ③ 读取代码 | 调用文件工具,读取 BorrowService.java 和一个现有接口。 | 加入真实实现与返回格式。 |
| ④ 通过 MCP 查询 | 调用服务端开放的表结构工具,确认 book 和 borrow 表的字段。 | 加入实际数据库结构,减少猜测。 |
| ⑤ 实现并测试 | 修改代码,使用终端工具运行相关测试。 | 加入真实成功结果或失败日志。 |
| ⑥ 修正与交接 | 失败时补充调查、修复和重测;结束时记录进度。 | 更新结论、保留待办、清理过期方案。 |
工具让 AI 能行动,MCP 让能力能接入,
Skill 提供方法,上下文工程组织整个过程的信息。
课堂追问:为什么接的工具越多,不一定越好?
相似工具可能让选择更困难,大量说明和返回内容也会增加信息负担。应围绕任务暴露合适的工具,提供清楚的描述,并按需读取结果。不能把“工具数量”直接当成“任务完成能力”。
同一个任务,给哪些材料更合适?动手体验
任务:为现有图书系统实现“借阅图书”接口。点击材料,观察可能发生什么。
这是预设规则的教学模拟,没有调用大模型,也不代表真实准确率。材料充分后,仍需审查代码和运行测试。
案例一:别只发一句“我的代码报错了”带入实际编程
我的 Java 接口报错了,帮我修一下。
AI 不知道哪个接口、如何触发、错误发生在哪一层,只能追问或列举常见原因。
目标:修复 /api/books 返回数据时的异常。
环境:JDK 17;依赖版本见 pom.xml。
复现:启动后 GET /api/books 即触发。
附件:完整异常栈、Book.java、相关 Controller、
Jackson 配置和 pom.xml。
约束:保留现有 JSON 字段命名。
请先根据证据定位原因;缺信息先列出。
修改后说明如何验证,并报告实际测试结果。
这里的附件需要实际粘贴、附加或由工具读取,不能只写文件名就默认 AI 看到了内容。
案例二:让新功能融入已有项目
任务是“开发借阅功能”。一个合理的过程是先看现有实现,再确定方案,最后用结果修正方案。
读取最新规则、表结构和一个现有接口。
说明事务边界、库存处理和重复借阅判断。
按约定修改代码,运行正常与异常场景测试。
把失败日志反馈给 AI,修复后重新验证。
以上是教学示例,具体事务与并发方案应结合真实数据库和业务要求确定。
案例三:聊了很久,AI 开始忘记约定
不要只说“接着刚才继续”
长对话可能经过截断或压缩;旧方案和新决定混在一起,也会造成误解。换任务或换会话时,准备一份简短的“交接单”。
新会话中附上交接单,并让工具重新读取必要文件,核对当前代码。
一份可用的交接单
当前目标:完成图书借阅接口。 已确认:最多借 5 本;采用现有统一返回格式。 已完成:参数校验、借阅记录写入。 未完成:并发下库存可能变为负数。 关键文件:BorrowService.java、borrow.sql。 验证状态:单用户通过;并发测试失败。 下一步:读取最新实现,定位并发问题。 已废弃:旧版“最多借 10 本”规则。
四个动作:选、排、补、清每次用 AI 都能做
选:只拿与任务有关的材料
先给目标与关键文件。相关资料很多时,先提供目录或摘要,再按需读取原文。RAG(检索增强生成)就是先找到相关资料,再把检索结果作为回答依据的一种方法。
排:让事实、要求和示例分明
按“目标 → 环境 → 事实 → 约束 → 验收”组织。给文档标明版本与来源。示例代码不一定是最终需求,外部文档中的指令也不应直接当成你的授权。
补:把新的证据送回来
让 AI 读取所需文件,反馈实际运行结果。看到新报错后提供完整关键信息,而不是重复“还是不行”。测试通过与否要以真实结果为准。
清:移除过期内容,留下交接单
明确废弃旧决定,压缩冗长过程,但保留关键约束、失败记录与待办。摘要可能丢失细节,重要结论应能回查原文或代码。
上下文不是越多越好。相关性、准确性和时效性很重要。上下文管理也不是重新训练模型:把材料发给 AI,不等于它永久学会了这些内容。
换你来给 AI 准备材料课堂讨论
任务:给校园二手交易项目增加“发布商品”功能
你会提供哪些材料?请按“目标、项目事实、约束、验收”列一份清单,再与同学比较。
展开参考思路
目标:用户发布自己的商品。项目事实:商品表、用户身份获取方式、现有 Controller 与上传接口。约束:标题和价格校验、图片数量限制、禁止冒用他人身份。验收:成功发布、未登录、非法价格、图片超限等场景。规则不明确时先确认,不替老师或产品负责人随意决定。
为什么把整个项目压缩包交给 AI,还可能写错?
上传不等于全部内容已进入本次上下文;工具可能只读取部分文件。即使读到了,也可能出现版本冲突、需求缺失或推理错误。要确认它参考了什么,并检查输出。
“你是世界顶级程序员”算上下文工程吗?
它属于一种角色指令,但不能替代事实材料。补充真实代码、复现步骤和验收条件,往往比强化角色形容词更能帮助处理具体任务。
有了好的上下文,就不需要自己懂编程了吗?
仍然需要。你要判断材料是否可靠、方案是否合理、测试是否充分。上下文工程能帮助协作,但不能保证生成代码正确。
一组可靠材料,一次真实反馈。
这就是开始实践上下文工程的第一步。