Phase 1 · 心智模型迁移
为什么 LLM 是概率函数、为什么 Prompt 不是咒语
Phase 1 · 心智模型迁移
这一章没有代码，只有"为什么"。 如果你只读一章节，应该是这一章——因为它决定了你写 Agent 代码时的每一个直觉反应对不对。
本章你将解决什么
读完这一章，你应该能：
- 讲清为什么 LLM 的输出是非确定性的（从注意力机制层面，不是"它就是概率"这种空话）
- 解释为什么 Prompt 不是咒语（理解了这点，你才不会陷入"提示词玄学"）
- 识别自己身上的前端本能，并知道哪些在 Agent 世界里会害你
- 在工程评审时讲清"为什么这个 bug 是模型本质决定的，不是代码 bug"——这是中高级工程师的核心能力
前置知识：读过 Phase 0 · 术语地基。不需要会 Python，不需要调过 API。
为什么这一章重要
Agent 项目里最难判断的不是"怎么写代码"，而是"这个 bug 该归到哪一层"：
- 是模型本质问题？要靠 prompt 重写、few-shot、eval 集解决
- 是工程问题？要靠代码、重试、降级、超时控制解决
- 是数据问题？要靠 RAG、知识库清洗、切块策略解决
判断错了，你会用错工具——比如用 retry 去解决"模型选错工具"（应该改 prompt），或者用 prompt 优化去解决"API 超时"（应该加重试）。
这一章建立的"概率性思维"，是这种判断力的源头。
核心思路：先打破一个幻觉
很多前端转 Agent 的人，第一周会经历这个过程：
Day 1：调通 API，输出 "你好世界" → 惊呼 "AI 真神"
Day 3：同一段 prompt 跑两次，输出不一样 → 困惑
Day 7：改了 prompt 一行字，输出完全跑偏 → 怀疑人生
Day 14：开始迷信"咒语式 prompt"，开始收藏"神奇提示词" → 走错路
我当年就是 Day 14 走偏的那个。那时候我把"让 GPT-3.5 稳定输出 JSON"的某条 prompt 当宝贝一样存在收藏夹里，还顺手转发给同事显摆——直到一周后发现它在另一个模型上完全失效，我才意识到：问题不是 prompt 写得不够好，是我在用写 CSS 的方式去调一个概率系统。
这条路走偏的根因是：你还在用"确定性思维"对待一个"概率性系统"。这一章的目标，是让你跳过 Day 7-14 的弯路，直接建立正确直觉。
Why 1：为什么 LLM 是"概率函数"——从注意力机制讲起
这是最核心的一个 Why。不讲清这个，后面所有内容都建不起来。
表面现象 vs 深层原因
表面：同一段 prompt 跑两次，输出不一样。 深层：这不是"随机数种子"的问题，是模型架构本身就是概率性的。
一个简化的注意力机制故事
LLM 的核心运算叫 self-attention（自注意力）。你可以把它想象成：
模型在生成每个 token 时，会对"前面所有 token"做一次加权平均，权重不是固定的，是模型根据上下文动态算出来的。
具体来说，对于输入序列 [A, B, C]，要预测下一个 token D 时：
D 的概率分布 = f(A, B, C 的某种加权组合)
↑
这个加权组合是模型权重 × 输入 共同决定的
关键事实：输出不是"查表"，是"一次浮点矩阵运算 + 一次 softmax 归一化"。归一化后得到的是词表上每个 token 的概率（比如 "苹果 0.31 / 橘子 0.27 / 桃子 0.18 / ..."），然后从中采样。
这一步非常关键，因为它直接对应了你日常看到的"模型不稳定"。下面这张图把这个"输入 → 分布 → 采样"的过程画出来，看完你就明白为什么同样的输入会跑出不同输出。
"采样"两个字是关键
如果你把 temperature=0（贪婪采样），模型会永远选概率最高的那个，这时输出几乎是确定的。但几乎是确定 ≠ 完全确定，原因有三：
- 浮点运算的精度损失：GPU 上
matmul(A, B)的结果，会因为 batch size、并行度、硬件版本不同而有 1e-6 级别差异。这点差异在 softmax 后偶尔会让排名前两位的概率反转。 - 模型版本漂移：服务方（OpenAI、阿里云）会静默更新模型权重。你的 prompt 没变，但
qwen-plus背后的实际权重可能上个月和这个月不同。 - 分布式推理的批次效应：同一时刻和你一起请求的其他用户的 prompt，会和你共享同一个 batch，理论上影响浮点累加顺序。
这三条你不用记，但你要记住一句话："温度 0"是工程上的近似确定，不是数学上的完全确定。
为什么这件事必须搞清楚
因为它直接决定了你怎么 debug：
| 你以为的问题 | 实际可能是的问题 |
|---|---|
| "我的 prompt 写错了" | 模型本来就有 5% 概率输出这种格式，需要靠 few-shot 或 schema 约束 |
| "我的代码 bug 导致输出不一致" | 这是模型本质，要靠 retry 或 ensemble，不是改代码 |
| "这个模型不行" | 模型没问题，是你没给 example，模型在猜你想要什么 |
真实工作场景：用户反馈"Agent 偶尔答非所问"。新手工程师会说"我加个 retry"或"我改改 prompt"；有经验的工程师会先问"出现频率多高？是温度高导致还是 prompt 缺少约束？是不是上下文超长导致中段被忽略？"——后者的判断力，就是这一章要建立的能力。
Why 2：为什么 Prompt 不是咒语
第二个核心 Why。理解了它能让你避开"提示词玄学"的大坑。
一个观察
OpenAI 官方文档里，Prompt Engineering 章节叫 "Prompt Engineering"，不叫 "Prompt Magic"。Anthropic 的官方指南通篇在讲"clear instructions、examples、structure"。严肃的从业者从不把 prompt 当咒语。
但国内很多自媒体文章会写"震惊！这个 prompt 让 GPT 暴涨 10 倍智商"——这类内容全部是流量垃圾。
那为什么 Prompt 有效？
很多人误以为 "prompt 在'教'模型新东西"。不是的。准确表述是：
Prompt 是在"激活"模型在训练数据里已经学到的能力，让它在这次推理时把这些能力用对地方。
这就是所谓的 In-Context Learning（上下文学习）。模型在 13 万亿 token 的预训练里，已经"见过"了几乎所有可能的输入-输出模式。你的 prompt 不是在创造能力，是在从已有能力里挑出适合当前任务的那一支。
这个区别看似细微，但它能解释你日常遇到的所有困惑。比如"为什么给一个示例，模型就突然会了"——不是它学会了，是那个示例把"该用哪一支能力"这件事说清楚了。
三个推论（直接影响你怎么写 prompt）
推论 1：好 prompt 像好 API 文档
- 清晰的输入输出定义
- 有边界（"只输出 JSON，不要解释"）
- 有示例（few-shot）
- 有错误情况的处理
差的 prompt 像口头嘱托，好的 prompt 像接口契约。
推论 2：few-shot 比指令更稳定 "请用专业语气" 是抽象指令，模型各凭想象；给 3 个专业语气的例子是具体示例，模型直接对齐。为什么？因为模型的注意力机制对"具体的输入-输出对"激活能力，远强于对"抽象形容词"的激活。
推论 3：换模型 = prompt 可能要重写 因为不同模型的"已学能力分布"不同。同样的 prompt 在 GPT-4 上 work，在 Qwen-Plus 上不一定 work。这不是 Qwen 不行，是 prompt 没对齐 Qwen 的能力激活路径。
一个反直觉的事实
很多新人花大量时间"优化 prompt 一行字"。但严肃的工程实践里，prompt 的 80% 价值在前 20% 的设计里就决定了——清晰的指令 + 1-3 个好的示例。剩下的 20% 优化（语序、用词、Chain-of-Thought 触发词）需要靠 eval 集验证，不能靠感觉。
本节核心：把 prompt 当接口设计，不要当咒语吟诵。前者可工程化，后者不可复制。
Why 3：为什么"输入决定输出"的本能会害你
第三个核心 Why，专门给前端工程师的。
前端的确定性本能
写了 3 年以上前端，你已经形成这些本能：
// 本能 1：函数是纯的
expect(add(1, 2)).toBe(3) // 永远成立
expect(add(1, 2)).toBe(3) // 调一万次还是 3
// 本能 2：测试是断言
test("renders correctly", () => {
render(<Button label="OK" />)
expect(screen.getByText("OK")).toBeInTheDocument()
})
// 本能 3：bug 是可复现的
// "我这边复现不了" = 不是 bug
这些本能在传统前端里是对的。在 Agent 开发里，每一个都会让你吃亏。
7 个前端本能 vs Agent 思维对照
下面这张图把那张著名的对照表"图形化"了——左列是写在你肌肉记忆里的前端本能，右列是 Agent 世界里的现实，中间是你要主动切换的思维。
文字版的完整对照（便于回查）：
| # | 前端本能 | Agent 现实 | 改写的思维 |
|---|---|---|---|
| 1 | 同样的输入永远同样的输出 | 同样的输入，输出有方差 | 写代码时预设"输出会漂移"，做容错 |
| 2 | 测试用断言（exact match） | 输出每次不同，断言必失败 | 用评分矩阵 / LLM-as-judge / 语义相似度 |
| 3 | bug 必须能复现才能修 | 同一段 prompt 偶尔出错，无法稳定复现 | 用 eval 集统计出错率，而不是单次复现 |
| 4 | 改一行代码看一行效果 | 改一行 prompt，可能 80% 输出变化 | 每次改完跑 eval 集，不要凭感觉 |
| 5 | 错误是异常（throw / catch） | LLM 不会 throw，它会"自信地输出错误答案" | 主动校验输出 schema，不信任模型自报 |
| 6 | 性能优化看耗时和内存 | LLM 调用看 token、延迟、成本 | 一次用户操作可能触发 10 次 LLM 调用，成本爆炸 |
| 7 | 代码 review 看逻辑 | Agent review 看 prompt + eval 集 | 没 eval 集的 Agent 代码不可 review |
一个真实案例（解释这套思维怎么救场）
假设你做了一个"博客文章自动生成摘要"的 Agent。用户反馈："偶尔摘要里会出现原文没有的内容（幻觉）"。
前端本能反应：
"我去查日志看看是哪次请求出错了。"
Agent 工程师反应：
"幻觉是模型本质问题。我先问：(1) 出错率多少？(2) 是哪些类型的文章出错？(3) 我的 prompt 有没有约束'只基于原文'？(4) 我能不能在 prompt 里加'如果原文没说就回答「无」'？(5) 我能不能在输出后用一个验证 LLM 检查摘要里的事实是否都在原文里？"
后者就是 有经验的 Agent 工程师的本能。这一章的目标是把这个本能装进你脑子里。
debug 决策树：这个 bug 归哪一层
前面讲了三个 Why 和七条本能对照，但真到了线上，你最需要的是一个能立刻用的判断框架：拿到一个 bug，先问什么、再问什么。下面这张图就是为这个场景画的——它是这一章所有理论的"出口"。
这张树不是用来背的，是用来养成"先问稳定性"的肌肉记忆。一旦你习惯了第一句话问"出错率多少、能不能稳定复现"，你就已经超过一半的 Agent 新手了。
思想实验：把"概率性"装进直觉
读完上面几段，你可能"理性上"理解了，但"直觉上"还没。下面这个实验你可以在脑中模拟（不用真的跑），它能把概率性变成你的肌肉记忆。
实验：同一段 prompt 跑 10 次
假设你的 prompt 是：
请用一句话总结：《前端转型 Agent 指南》Phase 0 讲了什么。
把这段 prompt 用 temperature=0.7（默认）跑 10 次。预期结果：
Run 1: 介绍了 Agent 开发的 11 个核心术语。
Run 2: 讲了 LLM、Token、Prompt 等基础概念，配上前端类比。
Run 3: 这是一份术语地基，覆盖了 LLM/Token/Context Window 等 11 个词。
Run 4: 解释了 Agent 开发必学的 11 个名词，用前端视角类比。
Run 5: ...
观察这些输出：
- 意思都对（语义层面收敛）
- 字面都不同（字符层面发散）
- 偶尔有一两个会多带一句无关内容（漂移）
这个实验要建立的直觉：你看到的"模型输出"，是模型对你 prompt 的一个采样，不是"答案"。同一个 prompt 后面是一个分布，你看到的是分布里的一个样本。
这个直觉的实战价值
建立这个直觉后，你会自动做这些事：
- 写代码时：默认假设"输出可能跑偏"，加 schema 校验、加重试
- 看用户反馈时：知道"用户说偶尔出错"是常态，问"出错率多少"
- 优化 prompt 时：跑 eval 集而不是凭感觉
- 设计产品时：UI 上给用户"重新生成"按钮（因为你预期到输出会漂移）
一张图总结这一章
这一章的内容可以浓缩成一张图：左边是你看到的"表面现象"，中间是"深层原因"，右边是"应对方法"。三列读下来，就是这一章的全部逻辑。
常见认知坑
坑 1：把"温度调到 0"当成"确定性输出" 温度 0 是贪婪采样，几乎确定但不是绝对确定。而且温度 0 会牺牲输出多样性，对创意类任务反而更差。生产环境要"确定性"靠 schema 校验和 retry，不靠 temperature=0。
坑 2：相信"Prompt 工程师"这种岗位定位 没有独立的"prompt 工程师"——这是 2023 年的过渡期产物。2026 年的工程实践里，prompt 只是 Agent 工程师技能树的一项。把 prompt 工程当成"特殊技能"会限制你的成长。
坑 3：因为模型幻觉就否定整个模型 所有 LLM 都会幻觉，区别只在频率和领域。Qwen-Plus 可能在中文古诗词上幻觉多，GPT-4 可能在中文政策上幻觉多。用 eval 集测真实表现，不要凭印象判断。
坑 4：用"我的 prompt 在 GPT 上 work"来 push 团队换模型 这违反了 Why 2 的推论 3。换个模型，prompt 大概率需要重新对齐。
本章检查清单
读完这一章，自测一下。每一条都要能说出"为什么"，不是记住结论：
- 我能用一段话讲清 LLM 为什么是非确定性的（至少提到 softmax + 采样 + 浮点精度）
- 我能解释为什么"温度 0"不等于"确定性输出"
- 我能说清 prompt 和"训练"的关系（不是教模型，是激活能力）
- 我能列出 5 个以上"前端本能"在 Agent 里失效的例子
- 我知道为什么 few-shot 比抽象指令更稳定（注意力机制层面）
- 我能解释为什么"prompt 工程师"不是一个独立的工程角色
- 我知道 eval 集是什么，为什么没有它就不能优化 prompt
答案不在本章末尾——你的"为什么"应该能直接对应到上面的 Why 1/2/3。如果对应不上，回去重读对应章节。
下一步
思想地基打完了。接下来进入 Phase 2 · Python 速通（前端工程师版）——因为后续实战章节的代码示例以 Python 为主（Python 是 LLM 生态的主战语言），同时保留 TypeScript 版本作为对照。
如果你已经熟悉 Python，可以跳过 Phase 2，直接到 Phase 3 接入阿里云 Qwen。