模块 1 — LLM 基础 (LLM Foundations)

目标：建立对大语言模型工作机制的架构师级直觉。本模块不讲数学推导，讲的是每一个概念如何影响你设计 Claude 应用时的决策：成本、延迟、上下文管理、可靠性。 📚 模块 01 重要英文词汇表

1. Token 与分词 (Tokenization)

🎯 学习重点：必考 Token 的四重角色——模型处理、上下文容量、API 计费与 ITPM/OTPM 限速；字符数只能粗估。

Token 是模型处理文本的最小单位，也是 API 计费 (billing) 与速率限制 (rate limiting) 的计量单位。Anthropic 官方文档明确说明："Anthropic's API bills and rate-limits by token counts, as tokens represent the underlying cost to our systems."（来源: https://platform.claude.com/docs/en/api/messages（访问于 2026-08-30））

1.1 Token 不是字符，也不是单词

分词器 (tokenizer) 把文本切分成子词单元 (subword units)。经验规律：

英文：1 token ≈ 3.5–4 个字符 ≈ 0.75 个单词
中文：常见汉字通常 1 字 ≈ 1–2 token（不同 tokenizer 差异大）
代码：缩进、符号密集，token 效率低于自然语言

官方文档给出的换算参考（截至 2026-08-30）：当前 tokenizer（随 Claude Opus 4.7 引入）下，1M token 约等于 55.5 万英文单词或 250 万 Unicode 字符；旧 tokenizer约 75 万单词/1M token；200K token 约 15 万单词。（来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））

⚠️ Gotcha：上面的字符/单词换算是语料级参考，不是 SLA。中文、代码、JSON、空白与特殊符号的密度不同；模型 tokenizer 版本变化还会让旧估算失效。容量规划可用启发式，提交报价或做硬性窗口判断前必须调用 Token Counting API。

1.2 图片也是 token

Claude 以 28×28 像素的 patch（视觉 token） 理解图片：一张图片消耗 ⌈宽/28⌉ × ⌈高/28⌉ 个视觉 token。例如 1000×1000 像素的图片约 1,296 token。（来源: https://platform.claude.com/docs/en/build-with-claude/vision（访问于 2026-08-30））

公式先对两个维度分别向上取整：1000 像素不是 1000/28 后四舍五入，而是 36×36=1,296。但它只适用于送入模型的有效尺寸；超过视觉档位上限的原图会先自动缩放，因此不能直接拿 4K 原始宽高套公式做最终账单。模块实验给出的边界是：Claude 4.7+ 高分辨率档长边最多 2576px、最多 4,784 视觉 token；标准档长边 1568px、最多 1,568 token（同上来源）。

1.3 架构师视角

决策点	Token 的影响
成本估算	输入/输出单价按每百万 token (MTok) 计费，报价前必须先估 token 量
上下文预算	system prompt + 历史 + 工具定义 + 输出全部计入 token
延迟	输入 token 越多，首 token 延迟 (TTFT) 越高；输出 token 越多，总延迟越长
速率限制	ITPM（每分钟输入 token）/ OTPM（每分钟输出 token）按 token 计量

发送请求前可用 Token Counting API（POST /v1/messages/count_tokens）预估 token，见模块 3。（来源: https://platform.claude.com/docs/en/api/overview（访问于 2026-08-30））

预算不等式（应能默写）：

system + messages + tools + images/documents + thinking + visible output ≤ context window

其中 max_tokens 是本轮输出的上限，不是窗口之外的额外空间。工程上应先为输出预留预算，再决定可注入多少历史与检索材料；反过来把输入塞满后再设一个很大的 max_tokens，是典型的截断式失败 (truncation failure) 反模式。

2. Transformer 与注意力机制 (Attention) 直觉

🎯 学习重点：高频考法是解释 Attention 为何既能利用上下文、又不等于持久存储，并据此拒绝“窗口越大越准”。

Claude 是基于 Transformer 架构 的大语言模型（官方描述："Claude is a family of state-of-the-art large language models"，来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））。架构师需要知道的直觉：

注意力 = 动态加权的信息检索。生成每个 token 时，模型对上下文中所有 token 计算相关性权重，再加权汇总信息。这解释了为什么上下文开头与结尾的内容通常被"记得"更牢，而中部信息容易弱化。
注意力对位置敏感但不等于存储。上下文窗口是"工作记忆"，不是数据库；对话内容不会写进模型权重（见 §9 训练 vs 推理）。
每个输出 token 都要"重读"整个上下文，这就是长上下文成本与延迟随长度增长的根源。

2.1 为什么这影响架构

上下文越长，上下文衰减 (context rot) 越明显——官方文档明确指出："As token count grows, accuracy and recall degrade, a phenomenon known as context rot."（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows（访问于 2026-08-30））
所以「把所有文档塞进上下文」不是好架构；检索 (retrieval) 与上下文工程 (context engineering) 才是（模块 7 展开）。

⚠️ 边界条件：不要把教科书中的注意力复杂度直接换算成某个 API 延迟数字。服务端实现、缓存、硬件与模型版本均不透明；架构师应通过真实负载测量 TTFT 与总生成时长。可依赖的方向性结论是：输入膨胀通常拉高 TTFT，输出变长通常拉高总时长。

3. 下一词预测 (Next-Token Prediction)

🎯 学习重点：易错点是 max_tokens 只设上限；必须检查 stop_reason，HTTP 200 不代表业务输出完整。

LLM 的本质任务：给定全部已有文本（system + 对话历史 + 当前输入），预测概率分布，采样出下一个 token，重复直到停止。

这个简单机制带来三个架构含义：

输出长度不可精确预知——你只能用 max_tokens 设上限，模型可能提前停（stop_reason: "end_turn"），也可能被截断（stop_reason: "max_tokens"）。
输出是逐 token 生成的——这是流式 (streaming) 的基础：不必等全文生成完就可以开始展示（模块 3）。
同一输入可有多种合理输出——采样是随机的（见 §5 temperature），所以需要确定性输出的场景（如结构化 JSON）要靠约束与校验，而不是指望模型"每次都一样"（模块 5 展开）。

停止原因分流：

`stop_reason`	含义	应用层正确动作
`end_turn`	模型自然结束	进入格式与业务语义校验
`max_tokens`	达到输出上限，可能半句/半个 JSON	不得直接解析入库；按任务决定续写、重试或提高预算
`model_context_window_exceeded`	输入与输出预算触碰模型窗口	压缩/裁剪输入并重算预算，不能原样重试

反模式 vs 正解：只看 HTTP 状态码 → 看 HTTP 状态码 + stop_reason + usage + 业务校验。

4. 上下文窗口 (Context Window) —— 本模块核心

🎯 学习重点：本模块必考核心——窗口是单次请求的工作记忆，输入与本轮输出共享同一总预算，多轮 API 本身无状态。

官方定义（值得背下来）：

The "context window" refers to all the text a language model can reference when generating a response, including the response itself. ... it represents a "working memory" for the model.（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows（访问于 2026-08-30））

4.1 窗口里装了什么（全部都算）

官方明确：请求中的一切都计入上下文窗口（截至 2026-08-30）：

system prompt
messages 中的每一条消息（含 工具结果 (tool result)、图片、文档）
工具定义 (tools 数组)
本轮要生成的输出（含 思考 token (thinking tokens)）

每轮 = 输入（全部历史 + 新消息）→ 输出（成为下一轮输入的一部分）。多轮对话是无状态 API 上的滚动累积：每次请求都要重发全部历史。

如果每轮消息长度近似相同且始终重发全部历史，第 1 到第 n 轮被处理的历史总量会近似按 1+2+…+n 增长，即呈 O(n²) 级累计输入量；这不是模型窗口变大能消除的问题。Prompt caching 可降低重复前缀的计费与多数模型的 ITPM 压力，但缓存命中的 token 仍占上下文窗口，不能把 200K 变成 400K。

4.2 当前窗口大小（截至 2026-08-30）

模型	上下文窗口	最大输出
Claude Fable 5 / Opus 5 / Sonnet 5	1M tokens（默认，无需 beta header）	128K
Claude Haiku 4.5	200K tokens	64K

（来源: https://platform.claude.com/docs/en/models/overview 与 context-windows（访问于 2026-08-30））

⚠️ 容量陷阱：表中的“最大输出”仍受剩余上下文约束。以 Haiku 4.5 为例，64K 是模型输出上限，不表示可以在已经占满 200K 输入后再生成 64K；请求设计必须同时满足窗口总额与模型输出上限。

4.3 上下文窗口的架构含义

flowchart LR A[用户消息累积] --> B[上下文接近上限] B --> C{如何管理?} C --> D[截断历史 丢信息但简单] C --> E[摘要/压缩 Compaction 官方推荐的主策略] C --> F[检索式注入 只放相关上下文] D --> G[权衡: 完整性 vs 成本/延迟] E --> G F --> G

官方对长对话/长 agent 任务的主策略是服务端压缩 (server-side compaction)（来源: https://platform.claude.com/docs/en/build-with-claude/compaction（访问于 2026-08-30），模块 8/9 展开）。
部分模型具备上下文感知 (context awareness)：API 自动注入剩余 token 预算信息（如 Sonnet 5、Haiku 4.5），模型可自行管理长任务（来源: https://platform.claude.com/docs/en/build-with-claude/context-windows（访问于 2026-08-30））。
超窗口会得到 stop_reason: "model_context_window_exceeded"（来源: https://platform.claude.com/docs/en/api/messages（访问于 2026-08-30））。

Bad vs Better（上下文管理）：

Bad	Better
把 500 页 PDF 全塞进 1M 窗口"反正装得下"	先检索/分块，只注入相关章节；装得下 ≠ 记得准（context rot）
每轮重发全部历史且不缓存	用 prompt caching 让重复前缀按 0.1x 计费（模块 3）
上下文满了直接截断最旧消息，无提示	摘要压缩 + 保留关键指令与最近轮次；监控 `usage` 逼近阈值

压缩时的不可丢清单：系统/安全约束、用户明确承诺与待办、工具调用结果中的关键事实、最近轮次。摘要本身也是有损转换，应保留原始记录用于审计，并用回归评估验证压缩前后任务成功率。

5. 温度 (Temperature) 与采样

🎯 学习重点：最易错版本题——参数文档仍列出 temperature，但 Claude 4.7+ 对非默认采样参数返回 400；结构可靠性靠 schema。

温度控制采样随机性。Messages API 的 temperature 参数范围 0–1（官方 API 参考；来源: https://platform.claude.com/docs/en/api/messages（访问于 2026-08-30））：

temperature: 0：近似确定性——适合结构化输出 (Structured Output)、分类、抽取、代码
temperature: 1（默认）：更多样——适合头脑风暴、创意写作
相关参数：top_p（核采样）、top_k（前 k 截断）；不要同时调 temperature 与 top_p（官方建议二选一）

架构师视角：温度只能"压缩"随机性，不能保证输出合法。JSON 合法性靠 schema 校验（应用层），不靠 temperature=0。

⚠️ 版本 Gotcha（截至 2026-08-30）：上述参数语义仍适合解释采样直觉，但 Claude Opus 4.7 及之后模型已弃用 temperature/top_p/top_k，设置非默认值会返回 400；新模型应省略这些参数，用 prompting、结构化输出与业务校验控制行为。（来源: https://platform.claude.com/docs/en/about-claude/model-deprecations（访问于 2026-08-30））

反模式 vs 正解：为“稳定 JSON”设置 temperature: 0 → 使用 Structured Output/schema 保证语法，再用确定性代码校验字段范围、跨字段关系与业务权限。约束解码保证“形状”，不保证事实与业务语义正确。

6. 幻觉 (Hallucination)

🎯 学习重点：必考回答不是“写更强 prompt”，而是把幻觉视为系统风险，用接地、工具、评估和人工升级分层控制。

幻觉指模型生成看似合理但不真实的内容。根源是机制性的：next-token prediction 只关心"统计上像不像真的"，不关心"是不是真的"。

官方文档在多处给出定位（如长上下文中准确性随 token 增长而衰减的 context rot；来源: context-windows（访问于 2026-08-30））。架构层面的缓解手段（本仓库后续模块展开）：

手段	模块
接地 (Grounding)：把回答约束在检索到的资料上（RAG）	07
引用与来源标注 (citations)	07
工具获取实时事实，而非依赖参数知识	04
评估集里显式测幻觉率	12
提示层要求"不确定就说不确定"	05

架构师铁律：幻觉是概率系统的固有属性，不是 bug。设计上要把"验证事实"留给确定性代码或人，而不是假设模型永远正确。

可操作的风险分级：低风险文案可接受抽样评估；企业知识问答要求引用并验证引用确实支持结论；价格、库存等易变事实必须实时查工具；付款、合规结论等高影响动作还要确定性规则或 Human-in-the-loop。“有引用”不等于“引用支持结论”，评估必须同时检查引用存在性与蕴含关系。

7. 推理 (Reasoning) 与思考

🎯 学习重点：高频权衡题——thinking 同时占 max_tokens、窗口、输出计费和 OTPM；effort 必须按任务风险分层。

现代 Claude 模型在回答前可进行内部推理：早期通过 extended thinking（thinking.type: "enabled" + budget_tokens），截至 2026-08-30，Opus 5 / Sonnet 5 / Fable 5 采用 自适应思考 (adaptive thinking)——模型自行决定思考多少，由 effort 参数调节（high 为默认）；extended thinking 在 Opus 4.6/Sonnet 4.6 上已弃用、更新的模型不再接受。（来源: https://platform.claude.com/docs/en/models/overview 与 thinking（访问于 2026-08-30））
思考 token 计入 max_tokens、按输出 token 计费、计入上下文窗口与速率限制（来源: context-windows（访问于 2026-08-30））。
架构权衡：更多思考 = 更高质量与更低延迟波动，但成本更高、延迟更长。高 effort 适合复杂分析/agent 规划；简单分类/抽取用低 effort 或快模型。

⚠️ 预算 Gotcha：max_tokens 同时容纳 thinking 与可见输出。预算过紧时，思考可能挤压最终答案；生产监控应把任务成功率、输出 token、TTFT/总时长和成本一起按 model × effort × task_type 分桶，而不是全流量默认高 effort。

8. 训练 vs 推理 (Training vs Inference)

🎯 学习重点：易混点——推理不会更新权重；会话记忆、租户数据与 cutoff 后事实都必须由应用层提供。

	训练 (Training)	推理 (Inference)
发生时机	模型发布前（Anthropic 侧）	你每次调 API 时
改什么	模型权重	什么都不改——权重冻结
你的控制方式	无（除非专门微调项目）	prompt / 上下文 / 工具 / 参数
知识来源	训练数据，截止于 knowledge cutoff	上下文窗口 + 工具结果

两个易混概念（截至 2026-08-30，官方在模型页区分二者，来源: https://platform.claude.com/docs/en/models/overview（访问于 2026-08-30））：

可靠知识截止 (reliable knowledge cutoff)：模型知识最全面可靠的截止日期（如 Opus 5 为 2026-05）
训练数据截止 (training data cutoff)：实际使用数据的更宽范围（如 Opus 5 为 2026-07... 官方表列 Jan/May 2026 等，以模型页为准）

架构含义：截止日期之后的事实必须靠工具（web search、数据库查询）获取，这就是工具使用 (Tool Use) 存在的第一性理由（模块 4）。

截止日期也不是授权边界：即使模型“知道”某个客户或订单，也不能据此访问数据。身份、租户隔离与行级权限必须在工具/数据层强制执行；prompt 中写“只能看自己的数据”不是权限控制。

9. 一图总结：请求的 token 生命周期

🎯 学习重点：能沿图指出哪些 token 占窗口、哪些进入 usage，以及输出如何在下一轮变成重复输入。

flowchart TB subgraph INPUT["输入 (全部计入上下文窗口)"] S[system prompt] M[messages 历史 user/assistant/tool_result] T[tools 工具定义] end INPUT --> P[Transformer 前向计算 逐 token 注意力] P --> N[Next-token prediction + 采样] N --> OUT[输出 token 流 text / thinking / tool_use] OUT -->|成为下一轮输入| M N -.->|计费与限速| U[usage 字段 input_tokens output_tokens cache_read/creation]

审计 usage 时至少区分 input_tokens、output_tokens、cache_read_input_tokens 与 cache_creation_input_tokens；只记录总 token 会掩盖“历史膨胀”“输出失控”和“缓存失效”三类完全不同的事故。

10. Bad vs Better：整体架构对比

🎯 学习重点：场景题要从概率组件出发，给出预算、约束、接地、校验和降级的完整控制面。

Bad（把 LLM 当数据库/确定性服务）：

假设模型记得所有对话（其实每轮都要重发）
假设 temperature=0 就能保证输出格式合法
假设长上下文=完美记忆，不做检索
用 prompt 让模型"不要出错"当作唯一防线

Better（把 LLM 当概率推理组件）：

显式管理上下文预算（system + 历史 + 工具定义 + 预留输出）
结构化输出用 schema 校验兜底
事实性回答接地到检索/工具结果
幻觉、格式错误、超限都有应用层的检测与降级路径

降级路径示例：上下文超预算时先裁剪低相关材料，再压缩历史；输出截断时禁止写入下游，按幂等策略续写/重试；事实无来源时返回“不足以回答”或转人工。降级必须由代码按信号触发，不能让模型自行决定是否绕过控制。

11. 权衡 (Tradeoffs) 速查

🎯 学习重点：考试不只问“选什么”，还问换来了什么、牺牲了什么，以及用哪个指标验证。

选择	得到	付出
更大上下文	装得下更多材料	context rot、更高成本/延迟、ITPM 消耗
更高 temperature	多样性	不可复现、格式更不稳定
开思考/高 effort	推理质量	输出 token 成本与延迟上升
更多 few-shot 示例	格式与行为更稳	输入 token 成本（可用 caching 缓解）
Streaming	更低感知等待、可尽早展示首 token	不减少生成量或总成本；客户端需处理流中错误与中断
Prompt caching	重复前缀更便宜、有效 ITPM 压力更低	前缀仍占窗口；易变内容前置会导致缓存失效

12. 常见错误 (Common Mistakes)

🎯 学习重点：把每条错误改写成“监控信号 + 自动动作”，是架构题从概念分到设计分的关键。

❌ 把 1M 窗口当无限记忆，不做任何摘要或检索
❌ 用字符数估算 token 预算（中英文差异巨大），不用 count_tokens
❌ 忽略工具定义本身占 token（几十个工具可能吃掉数千 token）
❌ 忘记输出（含 thinking）也占上下文，max_tokens 给太小导致截断式失败
❌ 把"模型说了"当"事实对了"，无接地无校验
❌ 把 prompt cache 当窗口扩容，忽略缓存 token 仍占 Context Window
❌ 只处理 HTTP 错误，不处理 stop_reason: "max_tokens" 的业务截断
❌ 把模型最大输出与上下文窗口相加，导致预留预算从一开始就不成立

13. 重要英文术语表

🎯 学习重点：优先掌握容易成对混淆的词：Context Window/Database、Context Rot/超窗、Training/Inference、Grounding/Prompting。

完整的模块级分组词表（含架构师视角说明）：vocabulary-01.md。

英文术语	中文	一句话解释
Token	词元	模型处理与计费的最小文本单元
Tokenization	分词	把文本切分成 token 的过程
Transformer	变换器	基于 attention 的主流 LLM 架构
Attention	注意力	生成时对上下文动态加权聚焦的机制
Next-token prediction	下一词预测	LLM 的核心训练/生成任务
Context Window	上下文窗口	模型单次请求可引用的全部文本的"工作记忆"
Context Rot	上下文衰减	上下文越长，准确率与召回越降
Temperature	温度	采样随机性参数（0 确定 → 1 多样）
Hallucination	幻觉	生成看似合理但不真实的内容
Reasoning / Thinking	推理/思考	回答前的内部推理 token
Training vs Inference	训练 vs 推理	权重更新（预发布）vs 权重冻结的请求期计算
Knowledge Cutoff	知识截止	模型训练数据的可靠截止日期
Grounding	接地	把回答约束在可验证来源上

14. 认证相关性

🎯 学习重点：认证题常把基础机制藏进选型场景；先识别 token、状态、可靠性和版本边界，再选方案。

Claude Certified Architect 认证（CCAR-F/CCAR-P，见 00-certification-current-status/）考察"advising, designing, and building Claude solutions"的能力。本模块对应的基础判断是所有考题的地基：

上下文窗口里什么算 token（消息、工具定义、输出、图片、思考）
为什么需要 streaming / caching / batches（token 生命周期）
幻觉与接地的架构应对
token 计量如何驱动成本与速率限制设计

注：官方 blueprint 域权重尚未公开核验（见 certification-status.md 的 PENDING 项），本仓库不声称任何官方权重映射。

15. 下一步

🎯 学习重点：以 80% 自测正确率为门槛；错题必须能说出反模式为何失败及正确方案的代价。

动手：labs/lab.md（无需 API key 即可完成大部分）
自测：questions/ + flashcards/flashcards-01.csv
下一模块：02-claude-models/——把本模块的通用机制落到 Claude 具体模型家族

📚 目录