> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/15_future/15.4_becoming_expert.md).

# 15.4 成为上下文工程专家

上下文工程专家的标志，不是会背更多框架名称，而是能在真实系统里回答四个问题：什么信息应该进入模型窗口，什么信息应该留在外部系统，什么信息必须被隔离或压缩，以及如何证明这些选择没有让系统退化。

本节把全书的方法收束成可检验的成长路线。读者可以把它当成自我评估表，也可以把它用作团队培养上下文工程能力的标准。

## 15.4.1 能力雷达

上下文工程能力应围绕可交付产物来判断，而不是围绕抽象标签来判断。

| 能力    | 能回答的问题                 | 可验证产物                       |
| ----- | ---------------------- | --------------------------- |
| 任务建模  | 这个任务真正需要模型看到什么？        | 用例边界、失败样例、拒答条件              |
| 信息治理  | 信息从哪里来，谁能看，何时失效？       | 来源清单、权限矩阵、更新策略              |
| 窗口预算  | 哪些内容进入窗口，哪些内容检索、摘要或丢弃？ | Token 预算、分层上下文结构、压缩策略       |
| 检索与记忆 | 如何找到正确材料，并避免错误记忆污染？    | 分块方案、索引版本、召回和重排序评估          |
| 工具边界  | 模型能调用什么，副作用如何受控？       | 工具 allowlist、参数校验、人工确认和审计日志 |
| 质量评估  | 改动是否真的提升了答案质量？         | 评估集、回归门槛、失败样例库              |
| 生产运维  | 系统退化时如何发现、止损和回滚？       | SLO、告警规则、灰度和回滚清单            |

初级工程师通常先关注“怎么把材料塞进提示词”；成熟的上下文工程师会先问“哪些材料不该进入提示词”。后一个问题决定了系统的安全边界、成本边界和可维护性。

## 15.4.2 三阶段成长路线

### 第一阶段：能跑通

目标不是追求复杂架构，而是完整经历一次最小闭环。

1. 选择一个真实但低风险的问题。
2. 整理 10-30 条带来源的知识材料。
3. 建立最小检索、组装、回答和引用流程。
4. 写出 5-10 条评估样例，至少覆盖命中、无证据、越权和相似误召回。
5. 记录每次失败的原因：检索失败、上下文污染、提示不清、权限缺失、模型误判或评估样例不足。

这一阶段的验收标准很简单：别人能在你的说明下复现实验，看到同样的输入、上下文、答案、引用和评估结果。

### 第二阶段：能诊断

当系统可以跑通后，真正的能力来自定位问题。

| 失败现象        | 优先排查                    |
| ----------- | ----------------------- |
| 答案看似正确但无来源  | 引用链、检索结果、答案后处理          |
| 找不到明明存在的材料  | 分块、嵌入、查询改写、同义词和元数据过滤    |
| 引用了相似但错误的材料 | 重排序、领域术语、时间版本、冲突来源      |
| 多轮对话逐渐跑偏    | 会话摘要、状态覆盖、历史截断、角色边界     |
| 成本或延迟突然升高   | 上下文膨胀、重试循环、工具调用、缓存命中率   |
| 低权限用户看到敏感信息 | ACL 过滤、索引元数据、日志脱敏、工具返回值 |

这一阶段的验收标准是：你不仅能修复单个坏例子，还能把它沉淀为评估样例、监控指标或发布门禁。

### 第三阶段：能取舍

专家级能力体现在取舍，而不是堆技术。

* 当任务只需要稳定格式转换时，优先选择短提示词和规则校验，不急着引入 RAG。
* 当知识库小而更新慢时，优先做好来源管理和版本标记，不急着上复杂图谱。
* 当问题需要最新事实时，优先设计实时检索和来源时间戳，而不是依赖长期记忆。
* 当工具有副作用时，优先做权限、沙箱、确认和回滚，而不是扩大模型自主权。
* 当评估集还很弱时，优先补失败样例和人工复核，不急着自动调参。

这一阶段的验收标准是：你能解释为什么没有采用某个热门方案，并能用成本、风险、验证证据和用户价值支撑这个决定。

## 15.4.3 上下文架构评审卡

大型项目启动前，可以用下面的评审卡判断设计是否具备出版级、生产级的完整性。它也可以作为读完本书后的复盘清单。

| 评审项   | 核心问题                    | 不合格信号                |
| ----- | ----------------------- | -------------------- |
| 任务边界  | 系统承诺回答什么，不回答什么？         | 所有问题都尝试回答，没有拒答策略     |
| 信息来源  | 每类上下文来自哪里，可信度如何？        | 文档、日志、记忆和工具结果混在一起    |
| 写入策略  | 哪些信息需要持久化？              | 把临时状态写进长期记忆          |
| 选择策略  | 如何从候选材料中选出当前任务需要的内容？    | 只靠向量相似度，没有元数据和版本约束   |
| 压缩策略  | 压缩后保留了哪些事实和不确定性？        | 摘要丢失来源、时间和责任边界       |
| 隔离策略  | 不同任务、租户、角色和工具结果如何隔离？    | 靠提示词提醒模型“不要泄露”       |
| 权限与来源 | 答案是否能追溯到可访问来源？          | 检索时过滤权限，生成时又拼入未过滤上下文 |
| 预算与性能 | Token、延迟、缓存和工具调用成本是否可控？ | 只有平均延迟，没有长尾和预算告警     |
| 失败模式  | 无证据、冲突证据、越权、工具失败时怎么办？   | 只设计 happy path       |
| 回归评估  | 每次改动如何证明没有退化？           | 没有固定评估集和发布阻断条件       |

如果一张设计图无法回答这些问题，它就还不是上下文工程架构，只是把若干 AI 组件串在了一起。

## 15.4.4 实践作品集

成为专家需要作品集，而不是只读更多资料。一个有说服力的作品集至少包含以下四类产物：

1. **最小可运行系统**：能本地运行，能展示检索、引用、权限过滤和评估结果。
2. **失败样例库**：记录误召回、幻觉、越权、冲突来源、上下文污染和压缩丢失。
3. **评估与门禁**：说明哪些指标会阻断发布，哪些指标只触发观察。
4. **架构复盘**：解释一次取舍，例如为什么不用长上下文、为什么不微调、为什么把某类记忆设为短期。

这些产物比证书和工具清单更能说明能力。它们展示的是工程判断：能否把不确定的模型能力变成可观察、可回滚、可持续改进的系统。

## 15.4.5 学习输入系统

学习上下文工程时，不要把注意力平均分配给所有新框架。更有效的做法是建立稳定的信息输入系统：

* **官方文档**：用于确认 API、模型能力、协议字段、价格和安全约束。
* **论文与技术报告**：用于理解新方法的适用前提、评估集和失败条件。
* **开源实现**：用于观察工程边界，例如缓存、重试、权限、日志和配置管理。
* **事故与复盘**：用于学习哪些风险不会出现在教程里。
* **自己的实验记录**：用于沉淀可复用的参数、坏例子和判断标准。

阅读资料时，始终追问三个问题：这个方法解决了哪个具体失败模式，它引入了什么新的成本或风险，我如何用一个小实验判断它是否适合自己的系统。

## 15.4.6 结语

上下文工程的长期价值，不在于把更多内容交给模型，而在于让模型只看到当前任务真正需要、被授权、可追溯、可评估的信息。

当你能持续设计这种信息环境，并能用证据解释每一次写入、选择、压缩、隔离和回滚决策时，你就已经从“会使用大模型的人”进入了“能构建可靠 AI 系统的人”的行列。