A03: 面向 Claude Code 用户的 LLM 基础原理
相关章节: 第 1 章 安装与首次会话、第 3 章 上下文窗口管理
使用 Claude Code 不需要机器学习博士学位。但理解大语言模型（Large Language Model, LLM）背后的关键概念会让你从一个照搬配方的用户变成一个能预测 Claude 行为、诊断问题原因、并基于模型实际工作方式优化工作流的用户。本附录以实用层面介绍基础知识 -- 心智模型，而非数学。
Transformer 架构：引擎盖下的引擎
全局视角
Claude 是基于 Transformer 架构的大语言模型。Transformer 架构由 2017 年的论文"Attention Is All You Need"（Vaswani 等人）提出，是几乎所有现代 LLM 的基础。
在最高层面上，Transformer 做一件事：给定一个 Token 序列，预测下一个 Token。它通过一系列层处理输入来实现这一点，每层根据每个 Token 与序列中所有其他 Token 的关系来转换其表示。
How Claude generates a response (simplified):
┌─────────────────────────────────────────────────┐
│ Input: "Fix the bug in src/auth/" │
│ │
│ Step 1: Tokenize │
│ ["Fix", " the", " bug", " in", " src", "/", │
│ "auth", "/"] │
│ │
│ Step 2: Embed (convert tokens to vectors) │
│ [0.23, -0.15, ...] [0.81, 0.42, ...] ... │
│ │
│ Step 3: Transformer layers (x96 for Opus) │
│ Each layer: Attention → Feed-forward → Repeat │
│ The representation of each token gets richer │
│ with each layer │
│ │
│ Step 4: Predict next token │
│ "I" (probability 0.35) │
│ "'ll" (probability 0.28) │
│ "Let" (probability 0.15) │
│ → Sample "I" → append → repeat from Step 3 │
│ │
│ Step 5: Keep generating until done │
│ "I'll start by reading the auth module..." │
└─────────────────────────────────────────────────┘关键洞察：一次一个 Token
Claude 生成整个回复的方式是逐 Token、从左到右。当你看到 Claude 输出一段带有代码示例的多段解释时，它并不是"规划"好整个回复后再写出来。它是基于之前的所有内容预测每个 Token。
这有实际影响：
- Claude 无法"回头"：一旦 Token 生成，它会影响所有后续 Token。如果 Claude 走上了错误路径，它倾向于继续而非回溯（除非使用 Extended Thinking 提前规划）。
- 更长的回复更贵：每个生成的 Token 需要模型完整的一次前向传播。1,000 Token 的回复需要 1,000 次前向传播。
- 靠前的 Token 更重要：Claude 回复的头几个 Token 决定了轨迹。这就是为什么"think step by step"这类提示工程技术有效 -- 它们影响了生成的初始轨迹。
注意力机制：为什么上下文窗口有限
注意力做什么
注意力机制（Attention Mechanism）是 Transformer 的核心创新。它允许序列中的每个 Token"查看"其他所有 Token 并确定各自的权重。
可以把它想象成房间里的对话。在传统神经网络（RNN）中，信息像传话游戏一样传递 -- 每个人只能听到前一个人的话，信息随距离递减。在 Transformer 中，每个人都能直接听到其他所有人的话。第 5,000 个 Token 可以直接关注第 3 个 Token，无需信息经过第 4 到第 4,999 个 Token。
Attention as "who looks at whom":
Token: "Fix" "the" "bug" "in" "auth"
│ │ │ │ │
"Fix" ←── ●───────●──────●──────●──────●
"the" ←── ●───────●──────●──────●──────●
"bug" ←── ●───────●──────●──────●──────●
"in" ←── ●───────●──────●──────●──────●
"auth" ←── ●───────●──────●──────●──────●
Each token attends to ALL other tokens.
Connection strength varies (thicker = more attention).二次方缩放：根本约束
这就是上下文窗口有限制的原因。对于 N 个 Token，注意力机制计算 N x N 个注意力分数。这是二次方缩放：
| Token 数 | 注意力计算量 | 相对成本 |
|---|---|---|
| 1,000 | 1,000,000 | 1x |
| 10,000 | 100,000,000 | 100x |
| 100,000 | 10,000,000,000 | 10,000x |
| 200,000 | 40,000,000,000 | 40,000x |
上下文窗口翻倍，计算量翻四倍。这不是一个将来会被补丁修复的软件限制 -- 这是注意力机制的数学性质。FlashAttention、滑动窗口注意力和稀疏注意力等技术降低了常数因子，但根本的缩放关系不变。
实际影响：这就是为什么上下文窗口管理很重要（第 3 章）。虽然 Claude 有 200K Token 的窗口，但使用 200K Token 在计算、延迟和费用上都远比使用 50K Token 昂贵。而且随着窗口填满，模型均匀关注所有信息的能力也会下降。
多头注意力：不同视角
Claude 没有单一的注意力机制 -- 它有许多并行运行的注意力"头"（Head）。每个头学习关注输入的不同方面：
- 一个头可能追踪语法结构（匹配代码中的开闭括号）
- 另一个头可能追踪语义关系（将"bug"与"fix"与"auth"关联）
- 又一个头可能追踪位置模式（关注附近的 Token 以获取局部上下文）
这就是为什么 Claude 能同时理解代码语法、跟随你的对话意图、记住项目约束。不同的注意力头处理不同方面。
"中间遗失"效应
Liu 等人 (2023) 的研究表明，长上下文模型对所有位置的注意力不是均匀的。检索任务的表现呈 U 形曲线：
Retrieval accuracy vs. position in context:
High |● ●●
|●● ●●
| ●● ●●
| ●● ●●
| ●●● ●●
| ●●●● ●●●
| ●●●●●● ●●●●●●
Low | ●●●●●●●●●●●●●
|____________________________________________
Start Middle of context End
Models attend most to the start and end, least to the middle.这不是 bug -- 这是位置编码和注意力交互的自然结果。对 Claude Code 用户来说，这意味着：
- CLAUDE.md（在上下文开头）得到良好的注意力
- 你最近的提示（在上下文末尾）得到良好的注意力
- 30 轮对话中第 10 轮的信息（在中间）可能被忽视
这直接支撑了 A02 上下文工程 中的上下文工程策略。
为什么 Claude 会"幻觉"
什么是幻觉
幻觉（Hallucination）是指 Claude 生成了流畅自信但事实不正确的文本。在 Claude Code 中，这表现为：
- 引用不存在的文件或函数
- 声称测试通过了但实际上没有运行
- 生成使用了库中不存在的 API 的代码
- 陈述关于你代码库的错误"事实"
为什么会发生
幻觉不是 bug -- 这是 LLM 工作方式的自然结果。Claude 是一个下一个 Token 的概率分布。它生成的文本在统计上是给定训练数据和当前上下文下最可能的。当一个句子最可能的延续是一个听起来合理但不正确的事实时，Claude 就会生成它。
几个因素增加幻觉风险：
上下文不足：当 Claude 没有足够信息来准确回答时，它会用来自训练数据的合理补全填充空白。这就是为什么 Claude 可能引用一个流行的 API 模式，但它与你特定的库版本不匹配。
训练导致的过度自信：Claude 在大量文本上训练，这些文本中自信的陈述通常是正确的。它学到了这个模式，即使应该表达不确定性时也会应用。
长上下文退化：如上所述，注意力在长上下文中减弱。Claude 可能"忘记"之前读过的文件并幻觉其内容。
模糊指令：当你的提示模糊时，Claude 在生成中有更多自由度，意味着更多幻觉空间。
工具调用如何减少幻觉
这是 Claude Code 用户最重要的洞察之一：工具调用是 Claude 对抗幻觉的解药。
当 Claude 能在描述文件前先读取它时，就不需要幻觉文件内容。当 Claude 能在报告输出前先运行命令时，就不需要猜测。当 Claude 能在声称函数存在前先搜索代码库时，就能验证而非假设。
Without tools (high hallucination risk):
You: "What does the auth middleware do?"
Claude: "Based on common patterns, it probably validates JWT tokens
and checks for expired sessions..." (may be completely wrong)
With tools (low hallucination risk):
You: "What does the auth middleware do?"
Claude: [Read src/auth/middleware.ts]
Claude: "The auth middleware at src/auth/middleware.ts does three things:
1. Extracts the Bearer token from the Authorization header (line 12)
2. Validates the token signature using the JWT_SECRET (line 18)
3. Checks token expiration (line 24)
It does NOT check for session validity -- that's handled
separately in src/session/check.ts."
(verified by reading the actual file)实用建议：当你需要关于代码库的事实准确性时，用鼓励工具使用而非回忆的方式措辞提示。"Read the auth middleware and explain what it does"会比"Explain how our auth works"产生更准确的结果。
温度与代码生成
什么是温度
温度（Temperature）是控制 Token 选择随机性的参数。在 Transformer 计算出所有可能下一个 Token 的概率后，温度调节该分布的"尖锐"或"平坦"程度：
Next token probabilities for "import { useState } from '"
Temperature 0 (deterministic):
"react" ██████████████████████ 99%
"preact" █ 0.5%
"solid" ░ 0.1%
Other ░ 0.4%
→ Always picks "react"
Temperature 0.5 (low randomness):
"react" ████████████████ 85%
"preact" ██ 8%
"solid" █ 4%
Other █ 3%
→ Usually picks "react", occasionally "preact"
Temperature 1.0 (default):
"react" ████████████ 60%
"preact" ████ 18%
"solid" ███ 12%
Other ██ 10%
→ More variety in outputsClaude Code 中的温度
Claude Code 使用针对 Agent 任务调优的默认温度。你通常不需要调整它，但理解其效果很有用：
- 较低温度产生更可预测、更常规的代码。适合样板代码、标准模式和只有一个正确答案的任务。
- 较高温度产生更有创意、更多样的代码。适合头脑风暴、生成替代方案和注重新颖性的任务。
当 Claude Code 生成工具调用（决定使用哪个工具、传递什么参数）时，它使用较低的有效温度，因为工具调用需要精确且结构良好。当生成解释或创意解决方案时，它可能使用略高的温度。
为什么相同提示给出不同结果：Claude 是一个随机性（概率性）系统。运行相同提示两次可能产生不同输出，因为基于温度的采样。这是正常的、预期的行为。如果你需要确定性结果，必须在应用层面处理（例如通过缓存或以温度设为 0 的模式运行）。
BPE 分词：文本如何变成 Token
什么是 BPE
字节对编码（Byte Pair Encoding, BPE）是将文本转换为 Claude 处理的 Token 的算法。理解 BPE 可以解释：
- 不同文本类型有不同的 Token 成本
- 代码比散文更贵
- 某些语言的 Token 效率比其他语言高
- 某些标识符对 Claude 来说"更便宜"
BPE 如何工作
BPE 从单个字符开始，迭代合并最频繁的字符对：
Training phase (done once, on a large corpus):
Step 0: Start with individual characters
"the" → [t, h, e]
Step 1: Most frequent pair is "t, h" → merge to "th"
"the" → [th, e]
Step 2: Most frequent pair is "th, e" → merge to "the"
"the" → [the]
After thousands of merge steps, the vocabulary contains:
- Common words as single tokens: "the", "function", "return"
- Common subwords: "tion", "ing", "pre"
- Less common words split into subwords: "XMLHttpRequest" → ["XML", "Http", "Request"]
- Rare characters as individual tokens: emoji, unusual Unicode实用 Token 计数
以下是不同内容类型的分词情况（近似值，基于 Claude 的分词器）：
English prose:
"The function validates the authentication token."
→ 7 tokens (~6.5 chars/token)
Python code:
"def validate_token(token: str) -> bool:"
→ 11 tokens (~3.5 chars/token)
JSON:
{"name": "validate", "type": "function"}
→ 13 tokens (~3 chars/token)
Chinese text:
"这个函数验证认证令牌。"
→ 8 tokens (~1.4 chars/token)
Variable names:
"getUserById" → 4 tokens (camelCase splits)
"get_user_by_id" → 7 tokens (snake_case: more tokens)
"x" → 1 token关键要点：代码的 Token 成本是英文散文的 2-3 倍。一个 200 行的 Python 文件可能消耗 2,000-3,000 Token。一个冗长的 JSON 配置文件消耗 Token 的速度令人吃惊。这就是为什么控制工具结果大小（参见 A02 上下文工程）如此重要。
为什么分词对 Claude Code 很重要
成本估算：知道 Token 数有助于你在开始前估算会话成本。一次读取 20 个约 200 行文件的代码库探索仅在文件读取上就消耗约 40,000-60,000 Token。
上下文预算规划：如果你的 CLAUDE.md 是 500 词英文散文，大约 375 Token。如果是 500 行代码示例，可能超过 2,000 Token。明智选择 CLAUDE.md 的内容。
输出效率：Claude 生成 50 行代码文件比生成 5 行解释消耗更多输出 Token。当你要求 Claude"编码前先解释计划"时，解释很便宜，代码生成很贵。
模型大小：Haiku vs Sonnet vs Opus
模型大小意味着什么
Anthropic 提供不同大小的 Claude 模型。"大小"是指参数数量 -- 定义模型行为的学习权重。
| 模型 | 相对大小 | 优势 | 权衡 |
|---|---|---|---|
| Haiku | 最小 | 快速、便宜、适合简单任务 | 复杂推理能力较弱 |
| Sonnet | 中等 | 速度/能力平衡、适合大多数任务 | 比 Haiku 慢、比 Opus 便宜 |
| Opus | 最大 | 最佳推理、最强的复杂任务能力 | 最慢、最贵 |
每种大小的心智模型
Haiku -- 可以想象为"能干的初级开发者"。处理直接任务很快：格式化代码、写样板、简单编辑、运行命令。在复杂多步推理、微妙 bug 和架构决策方面有困难。用于高频率、低复杂度的任务（如 CI/CD 审查、简单格式化）。
Sonnet -- 可以想象为"可靠的中级开发者"。能很好地处理大多数日常任务：功能实现、bug 调查、写测试、代码审查。速度和能力平衡良好。这是大多数 Claude Code 用户应该默认使用的模型。
Opus -- 可以想象为"资深架构师"。擅长复杂推理：理解多文件架构、发现微妙 bug、做架构决策、编写复杂算法。用于质量比速度更重要的任务：困难的重构、安全审查、算法设计。
模型大小如何影响工具调用
更大的模型更擅长：
- 选择正确的工具：Opus 更可靠地为特定情况选择最优工具。Haiku 有时在 grep 就够的时候读取整个文件。
- 构造正确参数：Opus 产生更准确的文件路径、搜索模式和命令标志。
- 从错误中恢复：当工具调用失败时，Opus 更擅长诊断原因并尝试替代方法。
- 多步规划：Opus 能在多次工具调用中保持连贯的计划。Haiku 在几步之后可能失去对计划的追踪。
缩放定律
关于神经缩放定律（Neural Scaling Laws）的研究（Kaplan 等人, 2020; Hoffmann 等人, 2022）表明，模型能力随模型大小、训练数据和计算量可预测地增长。这种关系大致是对数的：要获得明显的能力提升，你需要大约 10 倍的模型大小。
这解释了为什么从 Haiku 到 Sonnet 的跳跃感觉显著，但从 Sonnet 到 Opus 的跳跃在许多任务上可能感觉较小。能力差异是真实的，但集中在最困难的任务上。对于简单任务，三个模型表现相似。
"大海捞针"研究
研究表明什么
"大海捞针"（Needle in a Haystack, NIAH）测试评估模型从大量上下文中检索特定信息的能力。一个"针"（一个独特的事实）被放置在"干草堆"（大量填充文本）中的各个位置，然后要求模型检索它。
跨多个模型的 NIAH 研究关键发现：
模型不是完美的检索器：即使有 100% 的上下文可用，模型也会遗漏信息，尤其是在上下文中间。
位置很重要：检索准确率在上下文的开始和结尾最高，在中间最低（前述 U 形曲线）。
上下文长度很重要：随着干草堆增大，任何给定位置的检索准确率下降。在 10K Token 上下文中完美检索到针的模型在 100K Token 中可能遗漏。
多个针互相干扰：当上下文中散布着多条相关信息时，模型可能检索到一条但遗漏其他的。
对 Claude Code 用户的影响
NIAH 研究直接解释了 Claude Code 的几个行为：
为什么 Claude "忘记"早期指令：你在第 3 轮的约束是 50K Token 文件读取、测试输出和对话历史干草堆中的一根针。不是 Claude 选择忽略它 -- 注意力机制可能只是对它的关注较弱。
为什么 CLAUDE.md 有效：CLAUDE.md 位于上下文的最开头，在高注意力区域。这是最可靠地被关注的位置之一。
为什么重复约束有效：在当前提示中重复关键约束将其放在上下文末尾，另一个高注意力区域。这种"两端策略"利用了 U 形注意力曲线。
为什么 /compact 有帮助：压缩移除干草堆，使剩余的针更容易被找到。压缩后，你的关键指令不再埋没在数万 Token 的文件内容中。
综合理解：Claude Code 的心智模型
这是一个统一的心智模型，连接了所有这些基础知识：
Your prompt Claude's brain Claude's output
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────────────┐ ┌──────────────────┐
│Tokenize│───▶│ 96 Transformer │───▶│ Sample next │
│ your │ │ layers, each │ │ token from │
│ text │ │ with multi-head │ │ probability │──┐
└────────┘ │ attention over │ │ distribution │ │
│ ALL context │ └──────────────────┘ │
│ │ │ │
│ Context: │ ▼ │
│ - System prompt │ ┌──────────────────┐ │
│ - CLAUDE.md │ │ Is it a tool │ │
│ - History │ │ call or text? │ │
│ - Tool results │ └────────┬─────────┘ │
│ - Your prompt │ │ │
└──────────────────┘ Tool call │ Text │
│ │ │
▼ ▼ │
┌────────┐ Output │
│Execute │ to you │
│tool, │ │
│add │ │
│result │◀──────────────┘
│to │ (loop until
│context │ response
└────────┘ complete)本附录中的每个概念都对应图中的一个节点：
- 分词决定每条输入的成本
- 注意力决定 Claude 实际"看到"什么信息
- 上下文窗口是"ALL context"缓冲区的最大容量
- 温度控制下一个 Token 的采样方式
- 模型大小决定每个 Transformer 层的丰富程度
- 幻觉在概率分布偏向合理但不正确的 Token 时发生
- 工具调用将生成建立在真实数据之上，减少幻觉
核心要点
- Claude 一次生成一个 Token。 它不会提前规划（除非使用 Extended Thinking）。理解这一点解释了许多行为。
- 注意力是二次方的。 上下文长度翻倍，成本翻四倍。这是物理学，不是产品限制。
- "中间遗失"效应是真实的。 将关键信息放在上下文的开头（CLAUDE.md）或末尾（你的提示），不要埋在中间。
- 工具调用是幻觉的解药。 鼓励 Claude 读取/验证而非回忆/猜测。
- 代码的 Token 成本很高。 预算应考虑比行数预期高 2-3 倍的 Token 数。
- 模型大小在困难任务上最重要。 对于简单任务，Sonnet 和 Opus 产生相似结果。对于复杂推理，差距显著。
- 温度意味着相同提示可能给出不同结果。 这是设计使然，不是 bug。
另见：A02 上下文工程 了解基于这些基础知识构建的策略，以及 A07 Token 经济学 了解基于分词的详细成本分析。