LLM 心智模型 + 工程通识词汇

你已经会用 LLM。但你"懂"吗?

这个问题听起来有点学术,让我用一个具体场景来 unpack。假设你跟 ChatGPT 聊了一小时,问了它 30 多个问题,中间它能引用你前面说过的内容,你脑子里它是什么样的?它是一个能记得你说话的对话伙伴吗?它是一个根据问题查找答案的知识库吗?它是一个像人一样思考的智能体吗?如果你停下来诚实地回答,多数 vibe coder 的答案是这三种的混合:它有点像智能助手,有点像超级搜索引擎,有点像会理解的对话者。

这个答案不能算错,但它会让你在写真实 LLM 系统时反复踩坑。原因不是答案错了,是这个混合直觉不能让你预测 LLM 会怎么响应,你不知道为什么相同 prompt 跑两次结果不一样,不知道为什么 context 越长越贵越慢,不知道为什么 RAG 是必要的而不是可选的优化。所有这些问题的根都在心智模型 —— 你的脑子里 LLM 长什么样,直接决定了你能不能预测它的行为。换句话说,会用不等于懂。会用是知道哪个按钮按了出什么结果,懂是知道这个结果为什么是这个,以及边界在哪。前者是 prompt 玩家,后者是 LLM 系统的 builder。放到 Ch 1 的时间线上看更清楚:2022 年你做个 ChatGPT 用户、把它当黑盒,完全够用;但到 2024-2025 的 agent 时代,你要搭的是能自主跑多步的系统,黑盒直觉立刻不够——系统要可控就得能预测它,而预测的前提正是一个精确的心智模型。foundations 整个路书要把你从前者推到后者,推力的起点就是这个心智模型。

这一章不教任何代码,只做一件事:让你建立正确的 LLM 心智模型,并补全工程通识词汇。后面 5 章每一个细节,都默认你能 grounded 在这套基础上。读法很重要,不要快速扫读,扫读会让你以为读完了但实际没建立 mental model。每个类比读一遍,问自己能不能用自己的话讲一遍给从没用过 LLM 的朋友;能,就过;不能,留意自己卡在哪,那个卡点正是你心智模型缺失的地方。

1. 你脑子里 LLM 长什么样? 三类常见误解的来源

vibe coder 学过来的人,默认有几种半对半错的心智。它们让你能凑合用 LLM,但跟人讨论方案时立刻穿帮。我们一个一个 unpack,不是给你列定义,是带你检查自己脑子里的盲点。

误解 1 · LLM 知道答案

听到"LLM 答错了"这种说法你大概会点头同意。但停一下,这种说法在悄悄地告诉你什么?它在告诉你 LLM 知道什么是对的,只是这次没说出来,"答错了"这个表述本身预设了 LLM 有是否正确的判断能力。事实呢?LLM 从来不知道任何事。它做的事情只有一件:根据训练数据,推断下一个字最可能是什么。它生成 "2+2=4" 不是因为它懂数学,而是训练数据里这个模式出现了几百万次,概率高得压倒一切。问它 "2+2=5 吗",它说"不是",也不是它判断出错了,而是统计上"不是"出现得更多。

这个区分听起来像哲学,实际有非常具体的工程含义。遇到训练数据里少出现的场景(冷门数学题、最近的事件、特定公司的内部知识),它就完全没有是否正确的概念,纯按概率猜。这就是 hallucination 的根源:它从来没有真的知道,只是有时统计上恰好对。把"答错了"这种用法在脑子里换成"统计上拼出了不准确的内容",你对 LLM 的预测能力立刻升级一个台阶。

误解 2 · LLM 记得我刚才说的话

你跟 ChatGPT 聊了一小时,中间它能引用你前面说过的内容,你直觉上以为它记得对话。事实是 LLM 自己什么都不记得。每次回应,你的客户端把整段对话历史重新塞回去,LLM 看着这段历史决定下一句怎么回。让我用一个具体类比把这件事拽到地面:想象你跟一个记忆只有 5 秒的人合作,每次问他问题,你都要把"我们之前讨论过 A、B、C,你之前的观点是 D"这一整段告诉他,他才能接着说。LLM 就是这个人,每次调用都是一次全新的请求,完整对话历史每次都得带着,他才知道你在跟他聊什么。

这种无状态特性在英文工程世界叫 stateless(我们待会讲 SWE 通识词汇时还会回到这个词)。LLM 是 stateless 的,记忆责任在你的代码这边,不在它身上。这个区分的工程含义非常大:当你设计一个 Agent,你必须自己管理上下文,存历史、决定哪些进 context、哪些要 summarize、哪些可以丢。它记不住不是 bug,是函数本身的属性。Stage 2 第 3 章你会看到这个属性怎么决定整个 LLM API 的形态,Stage 3 你会看到怎么在 production 系统里 engineering 这一层。

误解 3 · 同一个 prompt 永远得到同一个回答

你给 LLM 一个 prompt,它回了一段。再给同样的 prompt,它回的可能略有不同,选词、结构、举例都可能变。事实是 LLM 的输出本质上是不确定的。每一步选下一个 token 时,模型其实给所有候选 token 算了一个概率分布,然后从分布里采样;同一个分布,采样两次结果可能不同。你可以通过 temperature=0 这样的参数让采样变得几乎确定,但严格的完全确定在生产场景几乎不会用,原因是 temperature=0 让模型输出过度死板,失去了灵活性和创造性。绝大多数 production 系统接受输出的不确定性,在系统设计层面处理它。

这意味着什么?你设计 Agent 的时候不能假设同一 prompt 永远得同一结果。具体说,测试 LLM 行为要跑多次,看分布,不是只跑一次;eval 要看 multi-run distribution,不是单次 pass/fail;retry 逻辑要考虑结果可能变,重试一次也许就对了在 LLM 系统里是合法 strategy。这个特性把 LLM 系统跟传统软件系统在根本上区分开:传统软件你假设给定输入到确定输出,LLM 系统你假设给定输入到概率分布再采样输出,两套不同的工程思维。

2. 五个精准类比 · 把 LLM 拽到地面

到此为止,我帮你 reframe 了三个常见误解。下一步要给你一个可工作的心智模型,一个你能在脑子里跑、能用来预测 LLM 行为的模型。我用 5 个类比来建立这个模型,每个类比覆盖 LLM 的一个面向,合起来形成一个完整的 working mental model。请认真读每个类比加它后面那段展开,不是浮光掠影。

类比 1 · 一次性的笔友

你写信(prompt)给 ta,ta 写回信(completion)。但有一个关键约束:ta 每次都失忆,只能看到你这一封信。如果你想跟同一个笔友长期通信,你怎么办?每次都得把整段历史抄给 ta:亲爱的笔友,我们前面信里讨论过 A、B、C,你的观点是 D,现在我接着问你 E,这才能让 ta 接着说。这个类比覆盖什么?stateless 这一性质,加上 context 必须完整携带的工程后果。在我们设计 Agent 的时候,这两件事是底层 mechanics,知道这一层,你才理解为什么 production system 里对话历史管理是核心问题。把这个类比记住:Stage 2 第 3 章讲 token 经济学的时候,你会看到每次都得把整段历史抄过去直接转化成每轮对话 cost 累积的具体数字。

类比 2 · 极其熟练的接话者

你说半句话,ta 接下半句,根据 ta 见过的几万亿字的语料,接最像的那种。ta 不想,只接。这个类比看起来朴素,但它揭示了一个关键事实:LLM 的核心动作就是 next-token prediction。所有复杂行为(推理、写代码、分析、做 agent decisions),本质上都是这一动作的延伸,只是接的半句话很长很复杂而已。

举一个具体例子,你让 LLM 解一道数学题。它的输出看起来像推理过程:先这样,然后那样,所以答案是 X。但底层机制不是真的推理,是在这个 prompt 后下一个最可能的 token 是什么的递归应用:每生成一个 token,把它加到 prompt 后面,再问下一个是什么,整个推理过程是这个 loop 的可见副产品。这个 reframe 听起来反直觉但极其重要。它解释了为什么 Chain-of-thought 提示有效:让模型先生成思考过程再生成答案,等于强制模型经过更多 next-token 步骤,中间步骤变成后续 next-token 的 context,提升最终答案质量。它也解释了为什么复杂 reasoning 模型(o1、o3、DeepSeek R1)在 inference 时思考很久:它们生成超长的内部 thought tokens,本质上是让 next-token prediction 在更长的 context 下运行,提升正确率。以及为什么"模型有没有真正理解"这个问题永远没有清晰答案,因为 next-token prediction 不需要理解也能产生看起来像理解的输出。

类比 3 · 一个非常会模仿的演员

你给 ta 一个剧本(prompt)加角色设定(system prompt),ta 演出来。同一个剧本,ta 演两次表演略有不同;剧本写得清楚 ta 演得好,剧本含糊 ta 自己 improvise,很多时候 improvise 错。这个类比覆盖一件 production engineer 经常忽视的事:prompt 设计就是写剧本。Production prompt 不是和 AI 聊天,是给演员的精确剧本:人物、场景、行动、出场顺序、台词风格、安全边界,都要交代清。vibe coder 写的 prompt 通常长这样:帮我写一个函数,接收用户问题,调 search 工具,返回答案。这是聊天,不是剧本。模型理解你的意图但没有精确 spec,所以输出会浮动:错误处理可能没有,边界 case 可能不考虑,输出格式可能每次不同。

Production prompt 长这样:

# Role: 你是 X
# Capabilities: 能做 A B C,不能做 D E
# Tools available: search_web (...), read_url (...)
# Behavior:
  1. 先 search,看 top-5
  2. 如果摘要够,直接回答
  3. 如果不够,read_url 看 1-2 个
  4. 最多 8 次工具调用,超过告知用户
# Safety: 不回答与检索矛盾的内容,医疗/法律加免责
# Output format: JSON schema {...}
# Few-shot: <1-2 个完整 input/output 示例>

差别是剧本精度。模型按精确 spec 演,你才能预测它会演成什么样。Stage 2 第 3 章我们会深入展开 production prompt 的细节,这里你先建立 mental model。

类比 4 · 一个嗅觉超强的图书管理员

你描述一个想找的东西(prompt),管理员凭嗅觉(概率分布)从几亿本书的内容里翻,大概率找到相关的,但 ta 不会真的去查书,只凭印象拼。所以会有印象错位:ta 印象里 A 书有这一段,其实那是 B 书里的,但 ta 拼着拼着拼出来一段似是而非的内容。这个类比覆盖 hallucination 的本质,它不是 bug,是这种工作机制的内在产物。要真去查书,需要外挂检索系统给它真实文档,它再据此生成,这就是 RAG(Retrieval-Augmented Generation)的全部动机。Stage 2 第 3 章你会看到 RAG 的 primitive 怎么搭。理解这个类比的工程含义:任何时候你的 LLM 系统需要准确的事实回答(不只是流畅的回答),你都需要 RAG 或类似机制,光靠 prompt 加模型自身知识是不够的,它不知道,只拼。这正是 Ch 1 认知三讲的那堵墙:hallucination 来自 next-token prediction 的机制本身,是内在的,只能靠外挂检索去管理,不可能靠把模型训得更大根除。

类比 5 · 一个无情高效的概率函数

把前 4 个类比合起来,LLM 的本质用一句话讲清:它是一个函数。输入是文字、输出是文字、输入到输出的映射是一个超复杂的数学函数。函数里面有几千亿个参数,但本质就是函数。它没有意图、没有意识、没有想要,它只是被 prompt 一推就输出。所有 AI 看起来有想法的现象,本质都是 prompt 引发的函数输出。

为什么把这个抽象到函数这一层?因为函数有两个性质 LLM 完全继承。第一,函数是 stateless 的,同一个 f(x) 永远等于 f(x),不依赖之前调用过什么(类比 1 覆盖);LLM 也一样,同一个完整 prompt 输入,输出分布完全一样(纳入采样的随机性后)。第二,函数没有意图,f 不想要给你某个答案,它只是机械地把 x 映射到 y;LLM 也一样,它不想帮你或骗你或解决你的问题,它只是机械地把你的 prompt 映射到下一个 token。所有它好像理解我、它好像在思考、它好像不愿意回答的现象,都是 prompt 在函数空间里的位置决定的输出。

这个第 5 类比是其他 4 个类比的 unifying frame,它把 LLM 从智能体完全拽到函数这一层。听起来抽象,但这是 production engineer 最有用的 mental model:当你怀疑 LLM 为什么会这样,回到它是函数,只把 prompt 映射到 token 概率分布,通常能解释 80% 的反直觉现象。

3. 第一性原理 · 一句话的 LLM

我把上面五个类比浓缩到一句话,作为整个 foundations 路书后续讨论的 anchor:

LLM 是一个把文字映射到文字的概率函数。它没有记忆、没有意图、有不确定性,生成的本质是按概率续写下一个 token。

这一句话是后面 5 章所有讨论的锚。每当你怀疑 LLM 为什么会这样,回到这句话上。我列几个常见的反直觉现象用这句话快速 unpack,训练你把心智模型用起来:

• 它为什么会失忆? → 它是函数,没有记忆。每次调用都是独立的 f(x),没有跨调用的状态。
• 它为什么会胡说? → 它按概率续写,没有知道的概念。冷门 query 走到训练数据稀疏的区域,函数输出就是统计上拼出来的看似合理的内容。
• 它为什么同一问题答两遍不一样? → 概率采样,本质不确定。函数输出的是分布,sampling 两次结果可以不同。
• 它为什么 prompt 写得越清越好? → prompt 是函数的输入,输入精度决定输出质量;precise spec 到 precise position in function space 到 precise output。
• 它为什么 context 越长越贵越慢? → 每次都要把 context 整段塞进函数,函数计算开销跟 context 长度近线性相关。

每次你卡在 LLM 行为的反直觉之处,回到这句话上。这是你这一章拿到最有价值的东西:一个可工作的 mental model。

视频学习站 · Mode B

Andrej Karpathy · Intro to Large Language Models

1h · YouTube · 2023

⚓ 为什么这里看

你已经建立了正确的心智模型框架(三类误解 + 五类比 + 一句话第一性原理)。现在去看 Karpathy 这一小时的全景导览,他从 weights、forward pass、training、tool use 完整讲一遍,把你刚建立的抽象框架填充具体技术细节。

Karpathy 是 OpenAI 创始团队 + Tesla 前 AI 总监,他讲 LLM 的 pacing 和直觉是业界最佳。预期你在视频里对上号:他每讲到一个机制(weights、sampling、context window、tool use),都能在我们刚铺垫的框架里找到对应位置 —— 这就是类比 5 函数里的那一层,这就是类比 1 stateless 的具体机制。这种框架加真人填充细节是建立 LLM 直觉的最快路径。看完后你回来,带着底层机制细节进入下面的 SWE 通识词汇环节。

→ 在 YouTube 观看(1h)

⚓ 看完回到

下一节 · SWE 通识词汇 · 非 CS 背景者一次补齐 →

4. SWE 通识词汇 · 非 CS 背景者一次补齐

视频看完了。你的 LLM 心智模型现在应该比一小时前清晰一个数量级。接下来我们换一个话题:工程通识词汇。为什么这一节出现在这里?因为 foundations 路书后面 5 章都假设你能听懂 production engineer 的日常表达。比如 Stage 3 第 2 章会出现这样的句子:"我们的 LLM 这层走 adapter 模式封装多 provider,middleware 加 logging,memory 用一个高内聚的 module 封装存储细节。" 如果你是 CS 出身,这句话每个词你都熟;如果你不是,这句话里 adapter、middleware、module、高内聚、封装,你可能听过一两个但说不清。你需要 25 个 SWE 通识核心词作为 baseline,这一节给你。

我用 25 个词加 4 组分讲,每词配一个类比加一个 LLM/Agent 场景示例。不是字典式抄背,是把每个词嵌入一个具体场景,让你脑子里有这词长什么样的画面,这是真正能记住、能用起来的学法。25 个词分四组:代码组织原语(7 个)、接口与契约(5 个)、软件架构思考(5 个)、生态层组件(8 个)。

4.1 代码组织原语 · 代码是怎么"长" 起来的

代码不是一坨,是一层一层组织起来的。最小单位是 function(函数),最大单位是 package(包),中间有 method、class、object、module 这些层级。理解这套层级的语言,是看懂任何项目代码结构的前提。让我用一个完整的例子带你走一遍,假设你在写一个 Customer Support Agent 项目。

最底层,你写一个 function:search_orders(user_id)。这是一段有名字、能复用的代码逻辑,给它 user_id 输入,它返回这个用户的订单列表。函数像饭店厨房里的煎蛋工序,递两个鸡蛋,厨师煎好端出来;同样的工序在 100 桌客人那里复用,不用每次重新讲怎么煎。Agent 的工具几乎都是函数:search_web(query) → list[Result] 是函数,read_file(path) → str 是函数,你设计 Agent 工具的本质就是在设计函数。但有时函数不够,你需要让函数知道自己在什么上下文里。比如 agent.run(),这个 run 不是独立的函数,是绑在 agent 对象上的;同样语法,如果换成 agent2.run(),行为完全不同,因为它知道是哪个 agent 在调它。这种绑在对象或类上的函数叫 method。

什么是类,什么是对象?Class(类)是模板,它定义这类东西有什么数据(属性)加能做什么(方法)。类本身不存在,它只是说明书,像汽车设计图,画出来汽车有四个轮、有方向盘、能开能停,但图本身不能开。class Agent 这一行定义了所有 Agent 共有的属性(model、tools、memory)加方法(run、reset)。Object(对象)是按类的设计图造出来的真实实例,my_agent = Agent(model="claude-sonnet-4-6") 这一行造了一个真实存在的、有具体配置的、可以调 .run() 的对象。类是图纸,对象是按图纸造的车。

往上一层是 module(模块),一组相关代码的集合,通常对应一个文件。你的 Agent 项目里,tools.py 装所有工具函数,memory.py 装记忆相关的类,llm.py 装与 LLM 通信的封装。模块像家里的工具箱,锤子箱、电钻箱、螺丝刀箱,各放一格,要用哪样取哪样;模块化让代码可读、可改、可测,改记忆相关的东西只动 memory.py。再往上,package(包)是多个模块的集合,通常对应一个文件夹,anthropic 这个 Python 包里有 messages.py、completions.py、tools.py 等多个模块;pip install anthropic 装的不是单个文件,是整个 Anthropic 官方 SDK 包。包像工具柜,里面分多个抽屉(模块),每个抽屉装一类工具。

最后,dependency(依赖)是你的代码运行时需要的另一份代码,可能是你写的另一个模块,也可能是外部包。你的 Agent 依赖 anthropic 这个包(用来调 Claude API)、pydantic(用来定义 tool schema)、httpx(底层 HTTP)。requirements.txt 或 pyproject.toml 里列的就是依赖清单,别人 clone 你的项目要先装这些才能跑起来。依赖像做饭需要煤气,你不生产煤气,但没煤气你做不了饭。

7 个词速查:

4.2 接口与契约 · 代码之间怎么"对话"

代码模块怎么彼此对话?这是一个比代码怎么组织更深一层的问题,它的答案是通过接口加契约。什么是接口?让我用一个具体的反例切入,假设你直接调用 OpenAI:

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(model="gpt-4", messages=[...])

这段代码在你的项目里出现了 8 次,8 个不同的地方。三个月后,你想换成 Anthropic,怎么办?8 处都要改,每处改的细节还不一样(因为不同地方用了不同的 OpenAI 参数)。这就是为什么需要 interface(接口)。Interface 是一份约定:我提供什么操作,每个操作的输入输出长什么样。接口只说能做什么,不说具体怎么做。接口像餐厅菜单,告诉你我们有炒饭,15 块,15 分钟出菜;菜单不告诉你大厨怎么炒,但保证你点了就有。一个工具的接口 = 工具名 + 参数 schema + 返回值类型。LLM 看的就是接口,它根据接口决定要不要调、怎么填参数,不需要知道工具内部怎么实现的。

接口之上是 abstraction(抽象),把复杂实现藏起来,只对外暴露简单稳定的接口;隔一层墙,内部怎么变化外部都不用改。抽象像电源插座,你只看两孔加 220V,不管墙后面的电是煤电、核电还是太阳能;换发电方式不用改你的插座。回到 LLM 例子,你写一个 chat(prompt: str) → str 函数,内部判断是 OpenAI 还是 Anthropic、走 REST 还是 streaming、要不要 retry,这些都藏起来;调用方看到的只是 chat(),后端换 provider 调用方一行不用改,这就是抽象。接口背后的具体代码叫 implementation(实现),抽象藏起来的那一层。同一个接口可以有多个实现:同一个 chat() 接口,可以有 OpenAIChat(走 OpenAI SDK)、AnthropicChat(走 Anthropic SDK)、MockChat(测试用,直接返回假数据)三个实现;换实现等于换 import,接口不变。接口是出租车叫车 App 的下单按钮,实现是按下后底层调滴滴还是 Uber 还是出租车队,可以换,体验对你一样。

最后两个词跟事件驱动有关。Callback(回调)是你把一个函数交给系统,让系统在特定时机自动调用它,事情发生了就执行我这段代码,而不是你站着等。回调像在餐厅留电话,做好了打我;你不用站柜台等,继续干别的,做好了餐厅拨你电话(回调你的函数)。Agent 场景:你给 streaming chat 注册一个 on_token 回调函数,LLM 每生成一个 token 就调用你这个函数(比如把 token 推到前端 UI);tool 调用完成时,你的 on_tool_result 回调把结果送回 LLM 触发下一轮。事件驱动 Agent 大量靠回调。Handler(处理器)是负责处理某一类事件、请求或动作的函数或模块,碰到 X 找谁处理,找对应的 handler。Handler 像 110、120、119 三个号码各对应一种事件处理器:失火找 119、急救找 120,各 handler 各管一摊。Agent 系统里 tool_handler 处理工具调用,error_handler 处理错误,stream_handler 处理流式输出;一个 Agent 系统里有 5-10 个 handler 各管一类事件,各自独立可替换。

5 个词速查:

4.3 软件架构思考 · 代码"长大"之后

代码长大之后,怎么组织它就成了独立学问。下面 5 个词是组织代码时的判断维度。最高层概念是 architecture(架构),系统整体的组织方式:有哪些模块、模块之间怎么连、数据怎么流、状态在哪里、出错怎么办。架构是高于代码细节的一层。架构像城市规划,住宅区在哪、商业区在哪、地铁线怎么连、应急通道在哪;规划不告诉你某栋楼怎么砌砖,但决定了城市能不能 work。一个 Agent 系统的架构包括:LLM 层(provider 选择)、Loop 层(怎么循环)、Tool 层(工具注册加执行)、Memory 层(短期加长期)、Observability 层(log 加 trace)。每层职责清、彼此连接清,这就是有架构;反之代码搅一坨等于没架构。

按职责划分系统的一种组织方式叫 layer(层),每层只做自己那一摊事,只跟上下层打交道。层像高速公路,底层是路面,上层是交规,再上层是地图导航 App;每层只跟相邻层交互,不越级。典型 Agent 分层:API 层(HTTP 接收用户请求)、Agent 层(主循环加决策)、Tool 层(工具执行)、LLM 层(provider 通信);底层不知道也不关心上面有谁,上层只调用紧邻下层的接口。但模块之间总有连接,连接的紧密程度叫 coupling(耦合):耦合越紧等于改一个就要改另一个,等于越难维护。耦合像两辆车用绳子绑在一起开,一辆变道另一辆必须跟,转弯快了绳子崩;松散绑(长绳)就灵活,紧紧绑(短绳)就寸步不离。回到 LLM 例子,Agent 直接 hardcode from openai import OpenAI 然后到处用等于跟 OpenAI 高耦合,以后想换 Anthropic 要改一堆地方;把它包一层 LLMProvider 接口等于松耦合,换 provider 只改一个文件。Production 设计的核心目标之一就是低耦合。

跟耦合配对的概念叫 cohesion(内聚),一个模块内部职责是否统一:高内聚等于这个模块只干一件事,低内聚等于一堆不相关的东西混在一起。内聚像收纳箱,高内聚是袜子箱里只放袜子,低内聚是袜子箱里有袜子、电池、过期发票。MemoryStore 模块只负责存取记忆(高内聚);如果你往里面塞日志写入、metrics 上报、用户认证(低内聚),这个文件就成了垃圾抽屉。高内聚加低耦合是好代码的双标准,跟模块化这个词在 production 实战里几乎等价。最后,把模块的内部细节藏起来,只暴露简单接口给外界,叫 encapsulation(封装),外界用就好,不用管里面。封装像微波炉,你按加热 1 分钟,微波炉内部怎么发射电磁波你不用懂;如果让你看见里面所有线路,你反而不会用了。Agent 场景:你的 Memory 类对外只暴露 .save(key, value) 和 .retrieve(key) 两个方法,内部用 JSON 文件还是 SQLite 还是向量库就封装起来,调用方不知道也不需要知道;今天用 JSON 明天换 vector DB,调用方代码 0 改动。

5 个词速查:

4.4 生态层组件 · 站在别人代码的肩膀上

写代码很少从零开始,你站在已有代码的肩膀上:库、框架、SDK、各种服务。下面 8 个词区分这些别人的代码长什么样、怎么用、彼此什么关系。这一组词在 production 系统讨论里出现频率最高。

最基本的概念是 library(库),一组可被主动调用的功能集合:你需要时调它,而不是它管控你。库像图书馆,你需要哪本书自己去借,不需要时它不来烦你。numpy、json、requests 都是库,你 import json 然后调 json.dumps(data),主动权在你这边。库不强加结构。SDK(Software Development Kit · 软件开发工具包)是某个平台专门为开发者准备的工具包,通常包括一个 client 类加类型定义加常用辅助函数,比直接调 HTTP 方便很多。SDK 像宜家的家具配套工具包,同样能用普通螺丝刀拼,但官方配的扳手刚好对得上尺寸。Anthropic SDK(pip install anthropic)给你 client.messages.create(...),类型安全、自动 retry、原生支持 streaming;不用 SDK 也行(自己拼 HTTP 请求)但累,用 SDK 是 production 默认。

跟 library 相对的是 framework(框架),一整套应用结构与开发模式。关键区别是库是你调它,框架是它调你 —— 框架规定你的代码长什么样,提供卡槽让你填。库像电锯,拿来切你想切的木头;框架像宜家家具,已经规定好先装腿、再装桌面、最后拧螺丝,你按步骤填。LangChain 是框架,它规定你的 Agent 必须有 LLM、PromptTemplate、Tools、Memory、Chain 这些组件,你填具体内容,LangChain 负责跑;好处是省心,代价是绑定它的世界观。API client(API 客户端)是一个调用某个服务的对象或模块,封装了认证、请求格式、错误处理等细节。API client 像专属代理人,你只说帮我下单,代理人去帮你跟商家通话、付款、确认订单。client = OpenAI(api_key="...") 这一行造的就是 API client,它知道怎么 auth、走哪个 endpoint、retry 几次;你调 client.chat.completions.create(...),client 帮你把所有细节处理掉。

更抽象的概念是 service(服务),提供某类能力的模块或独立系统,对外暴露稳定接口,内部实现可以演化。Service 像城市的自来水服务,你打开水龙头就有水,不管水来自哪个水库、经过哪些净化站。SearchService.search(query) 是一个 service,对外接口稳定;内部可能调 Google API,过段时间换成 Brave,再过段时间加 cache 层,调用方 0 影响。Service 体现的就是接口稳定加实现自由。请求穿越系统时经常经过一层叫 middleware(中间件),插入在请求处理链路中间的一层逻辑(鉴权、日志、限流、缓存等);请求穿过它,它做点处理再传给下一层。中间件像机场安检,所有乘客都过,安检不参与飞哪,但每个人都得过它一遍。你给 Agent 加一个 logging middleware,每次 LLM 调用前后,middleware 自动记录 prompt 加 response 加耗时;Agent 主逻辑一行不动,但每次调用都有日志了。Auth、rate limit、caching 都是常见 middleware。

不同系统的接口转换用 adapter(适配器),把不同系统的接口转换成统一接口,让下游代码不用关心上游是谁。Adapter 像电源转换插头,欧标插头插中国插座本来不行,加个转换头就通了。你想让 Agent 同时支持 OpenAI 和 Anthropic,但两家 API 的响应格式不一样;写一个 ResponseAdapter,把 OpenAI 响应和 Anthropic 响应都转成你内部的统一格式,下游代码完全不用知道用的是哪家。最后,provider(提供方)是某种能力的供应方,通常是外部公司或独立服务:model provider、embedding provider、storage provider 等。Provider 像水电气公司,你用,他们供。Anthropic、OpenAI、DeepSeek 是 LLM provider;Pinecone、Weaviate、Chroma 是 vector store provider;Tavily、Brave、Google 是 search provider。设计 Agent 时把 provider 抽出来,就有了横跨多家的能力加备选 fallback。

8 个词速查:

学完后你应该能听懂这句话

回到本节开头我给的句子:

"我们的 LLM 这层走 adapter 模式封装多 provider,middleware 加 logging 和 retry,主 Agent loop 跟 LLM 层保持松耦合,memory 用一个高内聚的 module 封装存储细节。"

现在每个词你都应该 grounded,adapter、provider、middleware、loop、coupling、module、cohesion、encapsulation 都在你脑子里有具体画面。如果还有 1-2 个词没把握,回去重读对应小节。这是 Stage 2 起步的硬门槛,带着这 25 词进 Ch 3,你才能跟得上 production engineer 的日常表达。

5. 起点 self-check · 4 维诚实评估

到这里你已经完成两件事:建立了正确的 LLM 心智模型,加拿到 SWE 通识 25 词。下一步是诚实评估你的 4 维 baseline,确认 foundations 路书后续章节对你来说是否在合理难度区间。有教无类的精确边界是:过去背景不构成入门门槛,但学生 capacity 是前提。如果你某些维度严重缺项,foundations 后面 5 章对你来说会很吃力,不是不能读,是要先意识到,然后决定是先补 prereq 再回来,还是边读边补。下面 4 个 self-check 维度,对自己诚实,这一节不交给任何人,只给你自己 calibrate。

5.1 数学 baseline

foundations 不教数学,但假设你听到几个数学词不脸盲。具体说:

• 概率:听到事件概率是 0.7 知道这是 70% 可能性,听到贝叶斯更新大概知道是看到新证据后调整原来的猜测
• 向量:听到 1536 维向量知道这是 1536 个数字组成的列表,听到两个向量距离近知道意思是它们相似
• 函数:f(x) = y 知道 x 是输入,y 是输出,f 是规则
• 指数与对数:看到 10^9 或对数时间复杂度不脸盲

如果这 4 项你都熟悉(✅),数学 baseline 通过,直接进 Ch 3。如果多数熟悉但有 1-2 项陌生(🟡),通过但卡的时候 Google 一下就行。如果多数陌生(⚠),强烈建议补一补再读后续章节;3Blue1Brown 的 Essence of Linear Algebra 系列加任意中学概率论资料能在 10-20 小时把这层 baseline 补好。

5.2 编程 baseline

不要求精通,要求能读、能改、能跑:

• 能读懂一段 100 行的 Python 或 TS/JS 代码,知道哪是函数、哪是 if/else、哪是循环、哪是类
• 能改一段 vibe-coded 代码,LLM 给你一段调 API 的代码,你能改成调你想要的另一个 API
• 能在自己电脑上跑通一个项目,git clone 一个 repo,装依赖,跑通它的 hello-world
• 基本懂 Git,commit、push、pull 三个命令的语义,不一定要懂 rebase

四项全熟(✅)通过。能改加能跑 OK 但读 100 行卡(🟡)通过,但 Stage 3(尤其是 production-quality 编程那一节)读起来会慢,做好心理准备。改 vibe-coded 代码都吃力(⚠),建议先用 Claude Code 跑通 3-5 个完整小项目(每个 ≥ 100 行)再来,这一项弱了读后面会很难。

5.3 英文技术阅读 baseline

去这三个网站,各读 5 分钟,问自己看懂了多少:

• OpenAI API doc
• Anthropic doc
• DeepSeek API

≥ 70% 能读懂(✅)通过。50-70%(偶尔查词,🟡)通过,Google Translate 做辅助但不能整段依赖。< 50% 看不懂(⚠),这一项没法跳过:AI 行业核心文档全是英文,翻译版总是落后加不准;要么先花 1-2 个月主攻英文技术阅读,要么准备工程加内容学习速度被显著拖慢。

5.4 跨工具 vibe coding 流利度

DeepSeek Agent Harness PM JD 里 verbatim 列了下面 8 个产品:

Claude Code · Cowork · Codex · Cursor · OpenCode · GitHub Copilot · Manus · OpenClaw · Hermes

学完 foundations 你应该能跨工具 collaborate,看一个新工具能 5 分钟上手。Self-check 现在的起点是:深度用过(≥ 10 小时,跑过真实项目)几个?

• ≥ 3 个(✅):已经有跨工具直觉,优秀
• 1-2 个(🟡):通过,但后续 Stage 4 的 meta-skill 章读完后要主动去用 2-3 个新工具,把跨工具流利练上去
• 0 个(⚠):这跟 vibe coding 经验自相矛盾,你不是我们说的 vibe coder。建议先深度用 Claude Code 或 Cursor 跑通几个项目(15-20 小时),再回来读 foundations

综合判断

把上面 4 维 self-rate 汇总:

self-honesty 是这一节的全部价值。多数学不下去 foundations 的人,不是认知不够,是起点缺项但没自知,读到 Stage 3 卡住归因到内容太难,其实是 prereq 没到位。先 calibrate 自己,再决定怎么读。

收官 · 你现在在哪 + 下一站

你已经走完了 foundations 的第 2 章。停一下,回头看看你走了什么。你拿到了一个正确的 LLM 心智模型:LLM 是一个把文字映射到文字的概率函数,没有记忆、没有意图、有不确定性,这个模型能解释 80% 的 LLM 反直觉行为。你看了 Karpathy 一小时的 LLM 全景视频,把抽象框架填充了具体技术细节(weights、forward pass、training、tool use)。你拿到了 25 个 SWE 通识词汇:代码组织 7 个、接口与契约 5 个、软件架构 5 个、生态层组件 8 个,这是你听懂 production engineer 日常表达的硬门槛。你诚实评估了自己的 4 维 baseline,知道 foundations 后面 5 章对你来说是否在合理难度区间。这就是 Stage 1 的全部内容,Stage 1 不教代码,只让你准备好读后面。

下一章(Ch 3)进入 Stage 2 · LLM 零件,LLM 作为可调用的零件加 API surface。我们把抽象的函数加概率心智模型,落到 production engineer 每天看到的 API 形态:Token 加 Context 经济学、REST/Streaming/Batching 三种 API 模式、production prompt 不是聊天而是 spec、Function calling/Tool use/MCP 协议入门、Embedding/RAG 简单流程。读完 Ch 3 你能看着任何一家 LLM API 文档说我懂他们在干嘛 —— 这是 vibe coder 到 LLM 系统 builder 转型的关键一步。

本章术语速查

心智模型层(6 词):LLM 把文字映射到文字的概率函数 · Prompt LLM 的输入文字 · Completion LLM 的输出文字 · Stateless 系统不记得历史,每次输入要带完整上下文 · Hallucination LLM 按概率拼出来的看似合理但不准确的内容 · Next-token prediction LLM 的核心动作,根据前面的文字接下一个最可能的 token

SWE 通识 25 词:

代码组织(7):Function 一段可复用代码 · Method 绑在对象/类上的函数 · Class 对象模板 · Object 类的实例 · Module 一组相关代码(通常一文件)· Package 一组模块(通常一文件夹)· Dependency 你的代码运行需要的另一份代码

接口与契约(5):Interface 模块的稳定约定 · Abstraction 把复杂藏起来只暴露简单接口 · Implementation 接口背后的具体代码 · Callback 你交给系统让它在特定时机自动调用的函数 · Handler 处理某一类事件的函数

架构思考(5):Architecture 系统整体的组织方式 · Layer 按职责分层 · Coupling 模块间绑定紧密度(越松越好) · Cohesion 模块内部职责统一度(越高越好) · Encapsulation 把内部细节藏起来只暴露简单接口

生态组件(8):Library 你主动调它 · SDK 平台官方为开发者准备的工具包 · Framework 它调你 · API Client 调用某服务的封装对象 · Service 提供某能力的模块或独立系统 · Middleware 插在请求链路中间的处理层 · Adapter 把不同接口转成统一接口 · Provider 能力供应方

完整术语词汇见 术语表 /glossary。

参考文献

Mode B · 必看视频(本章路径必经)

• Andrej Karpathy · Intro to Large Language Models · 1h · YouTube · 2023 LLM 全景导览,从 weights、forward pass、training、tool use 完整讲一遍。本章心智模型框架的具体技术细节填充。

Mode A · 引用出处(正文 inline,集中列在此)

• DeepSeek Agent Harness PM JD · "能够使用 vibe coding 写代码,不一定需要技术背景"加跨工具 8 产品清单 · 用户 first-party 复制 2026-05-25 · 收录 teaching-system/research/foundations/synthesis.md Section 8 Addendum
• OpenAI / Anthropic / DeepSeek 官方 API 文档 · OpenAI · Anthropic · DeepSeek · self-check 英文阅读 baseline 的实测对象

深 dive 资源(可选 · 想往下走再看)

LLM 直觉补强:

• 3Blue1Brown · But what is a GPT? · YouTube · 27min · Transformer 直观可视化(Mode B 备选,与 Karpathy 互补,数学直觉)
• Stanford CS324 · Large Language Models · 课件(2023)· 学院派深 dive
• Hugging Face NLP Course · 第 1-3 章 · 想动手实现时看

SWE 设计哲学:

• John Ousterhout · A Philosophy of Software Design · Ch 2-3 · 25 词概念的哲学源头,这本书的 narrative pacing 本身就是优秀技术写作的范本
• Martin Kleppmann · Designing Data-Intensive Applications · Ch 2-3(reliability、scalability、maintainability 三性)· 工程架构经典

Self-check 补丁(根据你的 ⚠ 项推荐):

• 数学补强:3Blue1Brown · Essence of Linear Algebra(YouTube 视频系列)、Khan Academy 概率入门
• 编程补强:Python 用 Automate the Boring Stuff with Python(免费在线)、Rust 用 rustlings(交互练习)
• 英文补强:直接读 OpenAI Cookbook 加 Google Translate 对照,2-3 周适应英文技术阅读节奏
• 跨工具补强:深度跑 Claude Code 或 Cursor 一两个真实小项目(15-20 hr)

下一章

下一章(Ch 3)进入 Stage 2 · LLM 零件 · API surface,覆盖 Token 加 Context 经济学、production prompt、Function calling、MCP、简单 RAG,中间穿插 Karpathy tokenizer 视频站加 3Blue1Brown vector 视频站。你已经完成 foundations 的第 1 个心流断点:合上书,去练一两天(用 Claude Code 试着写一个小工具,用 25 词里的几个去命名你的 module、function、class),内化今天学的东西;下次回来,带着扎实的 mental model 进 Ch 3。