context_first零基础约 55 分钟
第 0-3 课
提示词与 Context 工程：模型每一轮到底看到了什么
参考：来源 D · Anthropic
学完你能做到
- 区分“写一句提示词”和“设计整份上下文”
- 认识系统指令、用户问题、历史、检索证据与工具结果的角色
- 理解为什么资料越多不一定越好
Prompt 工程与 Context 工程不是一回事
先建立直觉
提示词像你给助理说的一句话；上下文像他桌上同时摆着的任务书、公司制度、昨天的进度、查到的资料和可用工具说明。助理做判断时看的是整张桌子，不是只听最后一句。
- 系统指令：稳定规则，例如“只能根据证据回答”。
- 用户问题：本轮目标和限制。
- 状态与历史：已做的步骤、待完成事项、用户已经确认的事实。
- 证据：RAG 找到的原文、数据库返回值、文件片段。
- 工具说明与结果：模型能做什么，以及刚刚实际发生了什么。
- 输出契约：要求 JSON、引用、表格或最终文本；程序再校验是否合格。
常见误解
Context engineering 就是把提示词写得越长越详细。
实际上
长、重复、互相矛盾的内容会稀释注意力，甚至让模型抓错重点。好的上下文工程更像编辑资料包：有来源、有关联、按需取用、可压缩、能区分“指令”和“待处理内容”。
案例推演：同一个模型，为何在两个页面表现完全不同
论文阅读页回答准确，首页悬浮聊天却经常编造。两处使用同一个模型，差异来自系统指令、论文原文、历史消息、检索片段和工具结果的装配方式。
本节追问：模型失败时，应该先换模型，还是先检查它实际看到了什么？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 盘点材料 | 列出系统指令、用户问题、历史、证据和工具定义 | 能打印本次请求的上下文清单 | 只查看前端对话文本 |
| 决定取舍 | 按任务相关性和可信度筛选材料 | 每段内容都有进入上下文的理由 | 把全部历史无差别塞入窗口 |
| 组织顺序 | 把权威规则、当前任务和证据边界分区 | 冲突时能说明哪条规则优先 | 将不可信网页混进系统指令 |
| 观察结果 | 记录上下文版本与回答质量 | 失败可重放并比较不同装配方案 | 每次靠人工猜提示词 |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
无限增加提示词长度
实际上
可观察症状：关键证据被噪声淹没，成本和冲突同时上升。
更可靠的修复：把 Context 当成有限预算：保留任务、证据和必要状态，其余检索或摘要化。
案例工作坊 · 建议真正动手完成
25 分钟- 为论文问答写一张上下文清单，标注来源和优先级。
- 删除三类“看似有用但本轮无关”的内容。
- 设计一条日志，使你能判断模型有没有看到论文原文。
查看参考答案
Prompt 是上下文中的一部分；Context 工程负责选择、组织、隔离和更新模型本轮能看到的全部材料。先观察实际输入，才能区分模型问题与装配问题。
迁移检查：换一个场景还会不会
长历史对话导致答案偏离当前论文，首选措施是？