上下文工程与提示词工程：差别不在措辞，而在“给什么信息”
近一年讨论 AI 应用时，「上下文工程」被提得越来越多。有人以为它只是提示词工程换了个说法，其实两者的关注点很不一样：提示词工程关心怎么说，上下文工程关心让模型看到什么。本文用应用视角把这个区别讲清楚。
一、一个直观对比
假设你让模型帮忙写一份项目周报：
- 提示词思路：琢磨用「请作为资深项目经理」还是「请分三点输出」，调整措辞和格式；
- 上下文思路：考虑要不要把上周周报、本周任务清单、相关会议记录、术语表一起给它，按什么顺序、截多长。
前者优化表达，后者优化信息供给。实践中，后者的上限往往更高——再漂亮的指令，也补不上缺失的关键材料。
二、上下文工程要解决的四件事
- 选什么：哪些资料与当前任务真正相关，而不是把所有东西都塞进去；
- 怎么组织：定义、事实、示例、限制分别放在哪里，结论性信息是否前置；
- 截多长：长文如何切分，既保留语义完整，又不挤占有效窗口；
- 怎么更新：版本变了、数据过期了，上下文能否被替换而不是越积越乱。
这四件事都不是「话术」问题，而是信息组织问题。
三、和 RAG 的关系
检索增强生成（RAG）可以看作上下文工程的一种典型实现：先从知识库里挑出相关片段，再作为上下文交给模型。检索质量、文档切分方式、资料本身的清晰度，共同决定最终回答的质量。
这类「按主题分册、边界清楚、持续更新」的资料组织，正是 万象云档 这类知识平台擅长的；技术条目「定义—原理—示例—注意点」的写法，则可参考 BackendWiki，答案密度高、歧义少，很适合被检索和引用。
四、给个人用户的实践建议
- 提需求前，先花一分钟列「模型需要知道哪三件事」；
- 把常用背景资料整理成固定片段，每次复用，而不是临时重打；
- 长材料先给结构（目录、要点），再按需展开细节；
- 发现答非所问时，先检查是不是缺了上下文，而不是急着改措辞。
想系统了解提示词侧的写法，前端 Wiki 这类分层教程站的思路也适用：先基础、再进阶、最后实战，别一上来就堆高级技巧。
五、一点判断
模型能力还在进步，但「信息给得对不对」始终是应用方的责任。上下文工程之所以被重视，是因为它把注意力从「怎么哄模型」拉回到「怎么把自己的资料整理清楚」——后者才是长期可控的部分。
结语
措辞会随模型版本失效，结构良好的信息却一直有用。把精力从雕琢一句话，转到组织一份清楚的输入，你会获得更稳定、也更可复用的效果。愿你的每一次提问，都先想清楚该让模型看见什么。