提示工程底层：模型机制、Token 预算与长上下文管理

我们在给团队做这轮梳理时，第一部分没有先讲技巧，而是先把几件基础事实讲清楚。不是为了显得“懂原理”，而是因为很多提示写崩，根子就在这里。

为什么我没有直接讲模板，而是先把模型怎么工作讲清楚

过去很多系统更像判别式任务：分类、排序、识别、打标签。它们当然也有输入，但自然语言长提示并不是主交互方式。今天我们大量接入的是生成式模型，提示本身就成了任务说明书。你让它写、改、提、比、归纳、规划、生成，它最后给什么，和你怎样定义任务强相关。OpenAI 的文档对这件事写得很直白：输出质量和输入设计高度相关，好的提示需要明确要求、格式和边界。(OpenAI Developers)

再往下一层，我们顺手把 RNN、LSTM、Transformer 这条线也重新捋了一遍。不是为了考古，而是为了说明为什么“自然语言交互”这件事，在今天会突然变得这么实用。LSTM 解决的是传统循环网络在长期依赖上的一部分问题；Transformer 在 2017 年把注意力机制放到核心位置，明确提出摆脱 recurrence 和 convolutions，并且更适合并行训练。今天主流大模型的工作方式，基本都建立在这条演进线上。(MIT Press Direct)

不过这里我们也专门纠正了团队里一个很常见的误解：Transformer 更擅长建模 token 之间的关系，也更利于并行处理，但自回归文本生成依然是逐 token 往后生成，不是“一次把整篇答案完整吐出来”。 这个区别看起来像细节，实际上会直接影响你怎么设计提示。你越把任务说成“按步骤检查、按结构返回、遇到缺失要显式说明”，模型越容易稳定；你越把它当成一个会“整体心领神会”的盒子，输出越容易漂。(arXiv)

消息角色：System Prompt vs User Prompt

从工程角度看，理解消息角色（Roles）是组织提示的基础：

• System Prompt：用来定义模型长期生效的身份、风格、底层规则（如“永远像 Mario 一样说话”）。
• User Prompt：当前具体的任务请求。 在开发中，将稳定的规则放入 System 角色，将变化的任务放入 User 角色，能显著提升指令的鲁棒性。(OpenAI Help Center)

token 和 context window，我们后来都把它当预算来管

真正进入业务场景后，我们很快发现另一个被低估的约束：token 和 context window。

团队里最早有人把 token 理解成“一个单词”，也有人把它理解成“一个汉字”。这两种理解都不稳。OpenAI 的帮助文档写得很清楚：token 可能是一个完整单词、一个子词片段、一个字符，甚至会把空格和标点一起编码进去；同样的表面文本，放在不同上下文里，切分结果也可能不同。(OpenAI Help Center)

上下文与对话历史（Memory）

很多人误以为模型有“天生的长期记忆”，实际上：

• 模型默认并没有长期记忆：你看到的“记得我之前说过什么”，通常是平台把 Conversation History（旧对话历史）重新送进了 Context。
• Context vs Prompt：Prompt 是当前的请求，Context 是模型当前还能看到的全部信息。长线程中如果超出窗口，早期的信息会被“挤出”。 因此，新开会话（Reset Context） 是解决模型被干扰或遗忘问题的工程常识。

这件事为什么重要？因为你以为自己只是“多补充了一点背景”，模型看到的可能已经是明显增长的一段 token 开销了。输入成本、可放进上下文的资料量、输出长度控制，本质上都受 token 约束。

长上下文不等于“不会丢重点”

到 2026 年，模型已经出现 1M 级上下文窗口：但我们真正踩过的坑不是“窗口不够大”，而是误以为窗口大就等于不会丢重点。Anthropic 关于长上下文的资料和 Claude 文档都在提醒一件事：上下文变长不代表模型会自动保持完美检索，你仍然需要摘要、压缩、切分和上下文管理。后来我们给团队定了一条硬规则：能先提炼任务，就不要整包塞资料；能先切片检索，就不要让模型在长文本里盲找。(Anthropic)

继续阅读： 下一篇：进阶推理路径设计