过去两年，大模型的使用范式正悄悄从「提示词（Prompt）工程」过渡到「上下文（Context）工程」。前者解决“如何向模型下达一次性指令”的问题，后者关注“如何在整条信息管道里持续喂养模型最有价值的内容”。本文结合一线实践，对两种范式的异同与演进做一次梳理。
二、大模型真的有“记忆”吗？
- 短期“记忆”=上下文窗口 笔者应该算是国内比较早的一批开始使用ChatGPT的从业者，第一次的使用可以用“惊掉下巴”来形容都不过分，用过“智能音箱”的朋友应该都有体会，一个问题如果描述的不准确，“智能音箱”秒变智障音箱，根本听不懂你想表达的意思，但是ChatGPT太强了，他完全能理解你的意思，还能多轮对话，简直像个真人。 当然如果我们深入了解过ChatGPT这类ChatBot的技术原理后，我们会发现一个扎心的事实，就是背后的大模型其实没有“记忆”。 现在的 ChatGPT、元宝、『豆包』、『DeepSeek』 等聊天『机器人』️之所以能连贯对话，并不是模型主动记住了你，而是工程层提前把历史对话拼接在每次请求里。模型能“看到”的字数由其 上下文窗口 决定。早期 ChatGPT 只有约 4 k tokens，如今 OpenAI GPT‑4.1 已在研究环境下把上限推到 100 万 tokens（官方实验数据）(OpenAI)，Anthropic Claude 3.5 Sonnet 也提供了 20 万 tokens 的商用窗口(Anthropic)。 参考折算：1 token ≈ 0.75 个汉字，100 万 tokens 约合 75 万汉字（近 500 页 A4）。
- 窗口再大也是有限值当对话轮数激增、附件动辄上 MB，超出上限后就会触发截断或报错。这也是为什么有时模型忽然“忘记”前文。
三、普通用户的两条小贴士
3.1 一次只聊一个主题——把“旅行攻略”和“写周报”拆成两条会话，可显著减少上下文污染。
3.2 对话质量下降就“刷新”——发现回答跑偏，不妨新开窗口重问，常有意想不到的提升。
四、『工程师』视角：从“单节管道”到“多节管道”
4.1 「提示词工程」：单点优化
下面是一个提示词的例子：需要提取『抖音』短视频的文案，用于后续的爆款短视频分析，这个需求可以用自然语言写，例如：
“我需要提取短视频标题、作者、视频文案，并且需要通过JSON格式输出，其中视频文案需要原始内容，不要总结”
这个提示词本身没有问题，但是如果我自己尝试的话，会发现每次使用总会有这样那样的问题，提取的不够稳定，但是如果我们使用的是如下这种XML+JSON的格式，提取对的结果就会非常稳定，并且很方便后续的代码对数据进行进一步处理。
https://www.douyin.com/user/MS4wLjABAAAAjb1juHnK9tygA0nuoGgSEMW7ZuJzXNnTMx9XwaQh19k?from_tab_name=main&modal_id=7429767354541788468
『抖音』视频链接
当然，这种语言已经非常偏向于伪代码了，写起来有一些挑战。
自然语言是简单的，但是往往不够精简和准确，代码语言足够简洁也足够精准，但是不容易写，算是有利有弊。
如果是个人使用，使用自然语言就够了，但是如果是放在系统工程里，稳定性就至关重要的，所以「提示词」也非常重要。
4.2 「上下文工程」：系统级优化
当业务链路不止一步、甚至需要多轮调用 LLM 时，仅靠单条提示不可持续。
- 多节管道：每个环节（检索 → 摘要 → 过滤 → 生成）既可以串行也可以并行；下游节点看到的是多个上游产物的「拼装上下文」。
- 全局视角：要判断哪些步骤让 代码来做（如正则清洗、批量重排），哪些必须 让大模型发挥推理或文本生成优势。
- 迭代闭环：复杂需求通常拆成多次调用+结果回写，再交给后续步骤复用。
学术界已把这套方法论正式命名为 Context Engineering，并给出了“检索‑处理‑管理”三层框架（Mei et al., 2025）(arXiv)。业内文章也普遍强调：有效上下文管理能显著降低幻觉率与 token 成本(Medium)。
五、结语与展望
- 提示词工程 解决“把问题说清楚”（推荐一本很好的书：《关于说话的一切》）；
- 上下文工程 则关注“让整条流水线始终喂给模型最有价值的信息”。
随着 100 万 token 级窗口逐渐普及，信息筛选与组织的重要性只会上升。这篇文章对于「上下文工程」的具体实现先不做具体展开了，后续我们可以专门拿一篇文章来讨论下GEO工程中的一些「上下文工程」的实现方式，抛砖引玉给到大家一些参考，希望今天的一些思考能给到大家一点启发。
