理解机器学习与GPT原理，才能写出更好的Prompt

大多数人第一次接触大语言模型（LLM），都是通过一个聊天框。你输入一句话，它给出回答，感觉像是在和一位博览群书的同事对话。这种体验很有用，但它也是开发者日后绝大多数挫败感的源头。模型不是同事，它是一个有特定习惯的统计系统。一旦你摸清这些习惯，你的提示词会更好用，Agent 会更可控，Token 账单也会更小。

三个历史节点，解释了后面的一切

不需要上历史课，但有三件事足以解释本文的大部分内容。

2017 年，Google 研究者发表《Attention Is All You Need》，提出 Transformer 架构。其核心思想——注意力机制——让模型能将输入中的每个 token 与所有其他 token 相互权衡，而不是严格从左到右阅读。随后 OpenAI 的 GPT 系列（2018 年起）证明：用海量文本、以“预测下一个 token”这一个简单目标训练 Transformer，模型会顺带学会语法、事实、代码和推理模式。最后，2022 年底的 ChatGPT 加入了指令微调与基于人类反馈的强化学习，让这些模型从“自动补全引擎”变成了“助手”。

关键结论：在光鲜的外表之下，它仍然是下一个 token 预测。下面所有内容都由此推导而来。

注意力机制（Attention） 是 Transformer 的核心组件，它允许模型在处理某个 token 时，动态地衡量输入序列中其他所有 token 与它的相关程度，并据此加权汇总信息。这打破了 RNN 严格从左到右、信息必须逐级传递的瓶颈，使长距离依赖关系能被直接建模，也让训练可以大规模并行化——这正是 GPT 系列能够扩展到千亿参数的前提。

下一个 token 预测（next-token prediction） 是一种自监督训练目标：给定前文，模型输出词表中每个 token 成为下一项的概率分布，训练就是不断提高真实下一个 token 的预测概率。这个目标看似简单，但要在海量文本上持续降低预测误差，模型必须隐式习得语法结构、事实关联、代码逻辑乃至推理步骤，因此它才“顺带”学会了那些能力。

指令微调与 RLHF 则是在预训练之后的两阶段调整：先用人工编写的“指令—回答”样本教模型遵循请求格式，再用人类对多个回答的偏好排序训练一个奖励模型，并通过强化学习让模型倾向于产出更被偏好的回答。这一过程并未改变模型运行时的本质——它仍在预测下一个 token，只是被引导成更符合人类期望的分布。

模型到底在做什么

LLM 并不“查资料”。它没有一个可供查阅的事实数据库。训练过程中，它的权重被调整成：给定一个 token 序列，为合理的下一个 token 分配高概率。当你输入提示词时，它一次生成一个 token，每个 token 都基于你的提示词加上它已经生成的全部内容。

对开发者而言，有两个后果至关重要：

• 模型优化的是“合理”，不是“真实”。 一个流畅自信的回答和一个正确的回答不是一回事，模型没有内置能力区分二者。
• 模型只知道权重里的东西和当前上下文窗口里的东西。 除此之外一无所知。除非你再次发送，否则它不记得昨天的对话。

幻觉是怎么产生的

幻觉，就是“最合理的续写恰好不是真的”时发生的事。常见成因有几类：

• 训练数据存在空白。 问一个冷门库或最近的 API 变更，模型信号很弱。但它仍必须产出某些东西，于是它生成这类答案通常长什么样：一个听起来正确的函数名，一个看似合理的参数。
• 模式补全压过事实回忆。 如果训练数据里每个 fetchUser 函数都接收 id，模型会乐于为你那个自定义函数凭空发明一个 id 参数。
• 提示词施加的压力。 如果你问“autoRetry 这个选项是干什么的？”，你已经预设了该选项存在。模型倾向于顺着前提走。
• 解码随机性。 采样意味着一个低概率的错误 token 偶尔会被选中，之后每个 token 都建立在它之上。

幻觉不是一个能在某个版本里被彻底修掉的 bug。它是这一机制的自然属性，可以被减少，但无法被消除。把输出当作需要验证的草稿，而不是可以直接信任的出处。

解码随机性 中提到的“采样”，指的是模型在每一步并非总是选取概率最高的 token，而是按概率分布随机抽取。常见的做法包括 temperature 缩放（温度越高分布越平坦、输出越随机）、top-k（只在概率最高的 k 个 token 中抽样）和 top-p／核采样（只在累计概率达到阈值的最小集合中抽样）。这样做的目的是避免输出呆板重复，但代价是低概率 token 偶尔会被选中。一旦某个错误 token 进入序列，后续每一步都以它为前提继续预测，错误便会被“合理化”地延续下去——这也是幻觉容易在长回答里越滚越大的原因之一。

一个假设：塞满上下文会让情况更糟吗？

这里有个值得探讨的想法。我必须坦率说明：这是一个有依据的猜测，不是已确立的结论，请把它当成一个可以在自己工作中检验的假设。

很多开发者会把能塞的都塞进提示词：整个文件、长篇文档、旧对话历史、粘贴的日志。可以称之为上下文灌塞（context stuffing）。同一件事更克制的版本常被称为上下文工程（context engineering）：有意识地选择模型能看到什么。

LLM 在自然语言、编程语言、标记格式和行业术语混杂的巨量数据上训练。这种广度是优势，但也意味着许多 token 是有歧义的。“table”可能是家具、数据库表或 HTML 元素；“class”可能是班级、CSS 类或面向对象类；标识符 order 可能是订单、排序方向或一条指令。一种语言里的变量名可能像另一种语言里的单词。混合语言的注释、包裹着 Python、JSON 和 shell 输出的英文散文，全挤在一个窗口里。

你倒进去的异构材料越多，模型抓错 token 含义、或把不同领域的模式混在一起的空间就越大。再加上过时或互相矛盾的片段，模型只能猜你想要哪个。一个被包装成自信回答的猜测，看起来恰恰就是幻觉。

研究给这个猜测提供了一部分支持：关于长上下文行为的研究（例如“lost in the middle”的发现）显示，模型对信息的利用会随其在上下文中所处位置而不均匀，无关材料会拉低回答质量。至于语言广度本身是不是驱动因素，我无法断言，但实用建议无论如何都成立：给模型更少、更干净、更相关的上下文，并说明术语的含义。

“lost in the middle” 是一项关于长上下文利用效率的实证发现：当关键信息被放在输入的中段时，模型检索并利用它的效果往往明显低于放在开头或结尾时。这意味着即便上下文窗口足够大、能装下全部材料，也不代表模型会均匀地关注每一处。这一现象与注意力分配和训练数据中位置分布有关，也解释了为什么“把文档全丢进去”常带来含糊或漏读的回答。实用对策是将最关键的指令与资料放在上下文的靠前或靠后位置，并主动删除无关内容，而非依赖窗口容量本身。

Agent 应用：误解的代价在这里变得高昂

在聊天里，一个糟糕回答的代价是重试一次。在 Agent 应用中，模型会规划、调用工具、读取结果并循环，一个错误的步骤可能触发真实行动。理解模型如何工作，能解释大部分意外情况。

为什么 Agent 会产出你不想要的结果、或做你没让它做的事：

• 目标模糊。 “清理项目”有很多种合理读法。模型会选统计上最常见的那一种，其中可能包括删除文件。
• 工具重叠或描述松散。 模型通过阅读描述来选择工具。如果两个工具听起来相似，或描述过于宽泛，它就会调错工具，或没必要地调用一个。
• 工具权限过大。 如果 Agent 能写磁盘、跑 shell 命令、访问生产 API，那么“合理的下一步行动”就包括使用这些能力。能力会招致使用。
• 有用性训练。 指令微调模型倾向于做更多事。没有明确边界，“修这个 bug”可能变成“修这个 bug 并顺手重构附近三个函数”。
• 长循环中的上下文漂移。 随着工具结果、错误和中间思考不断堆积，你最初的指令被埋没。模型跟随最显眼的内容，而那可能已经是一行跑偏的日志，而不是你的目标。
• 误差累积。 第二步里一个幻觉假设，到第三步就成了上下文里的“事实”。Agent 自信地在它之上继续构建。
• 上下文中的不可信内容。 从网页、邮件或文件中抓取的文本可能包含指令，而模型没有可靠办法区分你的指令和数据。这就是提示注入，它是“一切都只是同一个窗口里的 token”的直接后果。

有帮助的做法： 明确陈述目标与边界（包括不要做什么），给每个工具狭窄、独特且描述精确的用途，只授予所需的最小权限，破坏性操作前要求确认，在上下文末尾附近重申原始任务，并在工具输出重新进入循环前先验证。

这些理解如何帮你省 Token

Token 既是你要付费的东西，也是填满上下文窗口的东西。理解其机制可以从几个方面省钱：

• 模型是无状态的。 每次调用都会重发整个对话。在 20 步的 Agent 循环里，早期上下文会被反复付费。早点裁掉无关材料，会累积成可观的节省。
• 少灌塞，少 token，而且通常答案更好。 发送相关函数而不是整个代码库，花费更少，也让模型少一些困惑来源。
• 更少重试。 一次就写对的精确提示词，胜过三次含糊尝试。每个你不得不发现并重新提示的幻觉，都付了两次钱。
• 更少失控循环。 范围清晰、停止条件明确的 Agent，不会游荡到未被请求的工作里，而未被请求的工作也是要计费的工作。
• 可被缓存的结构。 许多提供方对重复的提示词前缀打折。把稳定指令放在顶部、可变内容放在下面，就能享受到这种折扣。
• 选择合适规模的模型和输出。 知道输出 token 通常比输入 token 更贵，且小模型擅长简单任务，你就能要求简洁格式（如结构化 JSON），并把简单工作路由给更便宜的模型。

Token 与分词（tokenization） 是理解成本的前提：模型并不直接处理字符或单词，而是先把文本切成 token——通常是子词单元，一个英文单词可能被切成一到多个 token，中文汉字往往一个或两三个字符对应一个 token，代码、标点和空格也各自计入。定价、上下文窗口上限和请求长度都以 token 计，而非以字数或字符计。因此同样的内容用不同格式表达（例如紧凑 JSON 对冗长散文），实际 token 数会明显不同。了解你所使用模型的分词方式，能让你更准确地估算成本、判断哪些材料值得放进上下文，以及为什么某些看起来很短的内容其实相当“贵”。

结论

提示词不是魔法咒语。它是在和一个“下一个 token 预测器”沟通，而这个预测器的 ground truth 只来自训练数据和你的上下文窗口。一旦你内化这一点，很多“神秘”行为就不再神秘：幻觉是听起来合理的填空，Agent 越界是因为你留了空间，而你的 token 账单，很大程度上是你发送了多少不必要材料的记录。

你不需要读博士。花几个小时了解 Transformer 如何工作、tokenization 如何切分文本、上下文窗口如何表现、采样如何运作，就能改善你之后写下的每一个提示词。

如果你见过混合语言或混乱上下文导致奇怪输出，欢迎在评论区分享。这正是一种会因更多真实案例而变得更好的假设。