Prompt 工程 vs Context 工程：怎么说 vs 给什么
写在前面
用 AI 干活翻车，最常见两种情况：
- 话没说清楚——你让模型"分析一下这份文档"，它不知道你要分析什么角度、输出什么格式。
- 信息没给到位——你让模型处理一个它根本看不到的文件、一份它没读过的规则。
前者是 Prompt Engineering（提示词工程），后者是 Context Engineering（上下文工程）。
很多人只听说过第一个。但真正把 AI 用出生产力的人，第二个花的心思更多。
一句话区别
Prompt 工程 = 怎么说（把指令表达清楚） Context 工程 = 给什么（决定模型能看到什么信息）
Prompt 工程解决的是"模型听不听得懂"，Context 工程解决的是"模型看不看得到"。
为什么：模型是瞎的
要理解这两个概念为什么不是一回事，得先搞清楚模型的工作机制。
模型没有眼睛、没有耳朵、没有记忆。它唯一能"看到"的世界，就是你塞进上下文窗口的那串字符——其他所有信息对它来说，物理上不存在。
所以 Context 工程不是一种"技巧"，它是给这个瞎子画世界。Prompt 工程是在这个世界里怎么指路。顺序很清楚：世界没画对，指路再好也没用——你想让模型"按写作规范检查草稿"，但它连你的规范文件都没看到，它检查个寂寞。
这就是为什么"把信息给对"和"把话说清楚"是两件独立的事，缺一不可。
各自的手段
Prompt 工程的手段（怎么把话说清楚）：
- System Prompt：定义角色、行为规则、输出标准。放在对话头部，固定注入，优先级最高。
- Few-Shot：给 3-5 个示例，模型从中推断输入→输出的映射模式（in-context learning）。
- CoT（思维链）：让模型把中间步骤写出来，给它显式的工作记忆。逻辑类任务收益最大，简单任务反而有害。
- 结构化输出：JSON schema、response_format、function calling，从"语言要求"到"API 硬约束"一整套手段。
Context 工程的手段（给模型喂什么信息）：
- 文档注入：把相关文档直接塞进上下文（长上下文时代的常见做法）。
- RAG 检索：先检索再生成，让模型只看到相关的部分，而不是全部。
- 工具结果：让模型调用工具（搜索、查库、跑代码），把结果作为上下文继续推理——这是 Agent 的核心。
- 记忆：会话历史、长期记忆、用户偏好。
- 项目规则：Claude 的
CLAUDE.md、pi 的AGENTS.md——把工作习惯和项目规范写进文件，让模型每次会话都能看到。
一个例子串起来（对照实验）
同一句 prompt，不同 context，结果天差地别：
Prompt（两轮一模一样）："总结一下上个月的销售数据。"
Context A：模型什么都没看到。
→ 它编了一份月报，数字全是幻觉。
Context B：你塞给它 12 条真实订单记录。
→ 它老老实实说"上个月卖了 340 件"。Prompt 一个字没变，结果一个天上一个地下。变的只有 context。
再叠加一个场景看两者怎么配合。让 AI 帮你写博客：
只做 Prompt 工程："你是一名技术博主，写一篇关于 RAG 的文章，口语化一点。"
→ 写得出来，但基于模型自己的记忆，可能过时、可能跑题。
加上 Context 工程：
（Context）以下是你的写作规范 CLAUDE.md：站点是 raylene.online、路由是 /blog/<slug>、配图放 /media/…
（Prompt）按这个规范，把这篇草稿改写成正式文章。
→ 模型现在"看得到"你的真实要求，产出立刻可落地。TIP: 你日常用的 AI 工具里，
CLAUDE.md、AGENTS.md、项目 README——都是 context engineering 的产物。它不是新概念，只是我们一直没给它名字。
总结
两者不是二选一，是先后关系：
- 先保证 context 对（模型该看的都看到了）
- 再优化 prompt 好（让模型知道怎么用这些信息）
顺序反了会浪费——话术再漂亮，模型看不到关键信息也是白搭；信息给足了但指令含糊，也会答非所问。
顺带一提：2025 年以来的行业共识是，生产环境里大多数"prompt 问题"本质是 context 问题。但也得诚实——这个说法主要来自厂商博客（Redis、Elastic、Neo4j 这类卖基础设施的，他们自然希望你多关注 context），目前没有严格的对照实验量化证明"context 决定上限、prompt 决定下限"。方向大概率对，但别当铁律。
一句话总结：Prompt 工程是让模型更聪明地说话，Context 工程是让模型看到更对的世界。