先懂上下文，再学具体技巧
Prompt、检索、微调和工具调用，都会改变模型看到的东西。先理解这个共同机制，才能判断问题是缺上下文、指令不清，还是能力本身有边界。
本页解决的问题
先给结论「先懂上下文，再学具体技巧」要解决的关键问题是什么？
Prompt、检索、微调和工具调用，都会改变模型看到的东西。先理解这个共同机制，才能判断问题是缺上下文、指令不清，还是能力本身有边界。
大多数 AI 技巧，本质都是上下文设计。 先检查消息列表：给了什么、漏了什么、重复了什么，以及哪些内容被要求模型自己猜。
把一个 AI 功能的输入上下文画成五个有名字的模块。
不断改 Prompt，却没发现真正的问题在检索、状态或权限。
AI 所有工程化操作，本质上都是对上下文的高效处理
不管是 Prompt Engineering、RAG、Fine-tuning，还是 Agent 工具调用，所有的花活，基本上都围绕着这个 message list 处理。理解它，你才能真正判断方案好不好、问题出在哪里。
Prompt Engineering
精心构造 messages，让模型看到正确的上下文：系统指令、角色定义、少样本示例，全部是往 message list 里塞内容。
RAG 检索增强生成
从外部知识库取回相关文档片段，拼进 message list 再发给模型，本质是在运行时扩充上下文。
Agent 工具调用
模型输出 function call → 执行工具 → 把结果 append 回 message list → 再次推理。每一轮都是在积累上下文。
Fine-tuning / SFT
把大量理想的 message list 烧进模型权重，让模型默认就能按期望方式处理上下文，省去每次都要在 prompt 里说明的成本。
「Prompt 改了没用」
System Prompt 被截断、历史对话占满窗口，问题根本出在上下文管理，跟 Prompt 写得好不好没有关系。
「RAG 效果差，不知道哪环节坏了」
Chunking 粒度、Embedding 模型、相似度阈值，不了解原理就不知道该查哪里，只能瞎试。
「模型答错了，该改 Prompt 还是 Fine-tune？」
是上下文没给对，还是参数里压根没这个知识？两件事的修复方式完全不同，搞错方向浪费大量时间。
我会花比较大的篇幅讲解这部分，不推荐跳过。
理解了 message list 的处理逻辑，后面所有工程化方案你都能一眼看穿它在做什么，为什么有效，局限在哪。
「AI 所有工程化操作，本质上都是对上下文的高效处理」为什么能找到相关内容
「不管是 Prompt Engineering、RAG、Fine-tuning，还是 Agent 工具调用， 所有的花活，基本上都围绕着这个 message list 处理 。理解它，你才能真正判断方案好不好、问题出在哪里」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「精心构造 messages ，让模型看到正确的上下文：系统指令、角色定义、少样本示例，全部是往 message list 里塞内容」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「我会花 比较大的篇幅 讲解这部分， 不推荐跳过 。」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从这个例子继续往下看
这篇内容先从「不管是 Prompt Engineering、RAG、Fine-tuning，还是 Agent 工具调用， 所有的花活，基本上都围绕着这个 message list 处理 。理解它，你才能真正判断方案好不好、问题出在哪里」展开，再把问题推进到「精心构造 messages ，让模型看到正确的上下文：系统指令、角色定义、少样本示例，全部是往 message list 里塞内容」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「AI 所有工程化操作，本质上都是对上下文的高效处理」：不管是 Prompt Engineering、RAG、Fine-tuning，还是 Agent 工具调用， 所有的花活，基本上都围绕着这个 message list 处理 。理解它，你才能真正判断方案好不好、问题出在哪里
- 「继续往下看」：精心构造 messages ，让模型看到正确的上下文：系统指令、角色定义、少样本示例，全部是往 message list 里塞内容
- 「最后的要点」：是上下文没给对，还是参数里压根没这个知识？ 两件事的修复方式完全不同 ，搞错方向浪费大量时间
最后的「最后的要点」把讨论落到「是上下文没给对，还是参数里压根没这个知识？ 两件事的修复方式完全不同 ，搞错方向浪费大量时间」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。