Dopamine Agent Lab
0/47
学习地图 阶段 2
Stage 02 · Models & Prompts

模型与提示：能力边界从哪来

不神秘化模型：它本质是在预测下一个 token。理解这一点，就能解释幻觉、上下文窗口、 为什么提示词有用，以及为什么多模态「看图」并不等于「理解」。

5 节 约 2 小时 前置：阶段 1 含 2 个动手实验
本阶段进度 0 / 5
2.1

AI 底层架构：把概念放进五层

约 20 分钟 概念 对照原文 ↗

学习目标

把 LLM、Token、Prompt、RAG、MCP、Agent、Skill 这些词放进同一张分层图，并说明每一层「坏了下层能不能补救」。

前置知识

阶段 1 的组件与术语。

核心要点

  • 从下到上：基础模型（推理）→ 上下文（提示/记忆）→ 知识（RAG）→ 工具（MCP/Skill）→ Agent（编排）→ 应用。
  • 上层依赖下层，但不能弥补下层的根本缺陷：模型不会推理，堆再多工具也只是更快地犯错。
  • MCP 是「接口标准」，不是模型能力；接上 MCP 不等于 Agent 会正确使用工具。
  • Skill 是封装好的能力单元，通常包含说明 + 脚本 + 资源；它的可维护性取决于文档质量。
  • 选型时按层定位问题：答非所问查提示/模型；不知道私有知识查 RAG；不能执行查工具层。

动手任务（20 分钟）

画一张自己的技术栈五层图，每层填 1 个「已经用过或准备用」的具体东西（例如知识层写「本地 markdown + 向量库」）。再用箭头标出你当前项目的瓶颈层。

自检

RAG 属于哪一层？它能不能解决模型幻觉？
属于知识层。它能显著降低「不知道却编造」的概率，但无法根除：检索可能错、拼接可能误导、模型仍可能忽略证据。需要配合引用、阈值和拒答策略。
为什么说「接上 MCP 就拥有能力」是误解？
MCP 只统一了「如何暴露工具与资源」。工具是否安全、参数是否被正确填写、返回结果是否被正确理解，仍取决于实现与模型。协议解决连接，不解决正确性。
进度保存在本机浏览器
2.2

大语言模型基础：预测下一个 token

约 30 分钟 原理 对照原文 ↗

学习目标

用「根据前文预测下一个 token」解释三件事：为什么会有幻觉、为什么提示词影响输出、为什么上下文有上限。

前置知识

2.1；知道「模型参数」「训练」大概是什么。

核心要点

  • 生成是自回归的：每次采样一个 token 并接回输入，所以「一次生成」其实是很多次前向计算。
  • 训练大致分预训练（学语言与世界知识）、后训练（指令跟随）、对齐（偏好与安全）；能力与风格来自不同阶段。
  • 温度 / top-p 控制采样随机性：低温更稳定，高温更多样，但都不等于「更正确」。
  • 幻觉的根源是「流畅优先」而非「事实优先」；检索、工具、校验是外部补丁，不是提示词能根治的。
  • 上下文窗口是硬限制，且「能放下」不等于「能用好」：长上下文存在注意力衰减与成本问题。

动手任务（30 分钟）

同一个问题写 3 个版本：①直接问；②加角色 + 输出格式；③加角色 + 1 个示例（few-shot）。分别运行并记录：输出结构差异、事实错误数量、长度。最后写 3 行结论：哪种约束真正起了作用。

自检

温度设为 0 就一定是确定性输出吗？
不一定。它通常等价于贪心解码，但服务端实现、并行计算、模型版本更新都可能导致差异。需要可复现时，记录模型版本、参数与随机种子，并接受工程上的近似。
为什么「让模型不要幻觉」通常无效？
因为幻觉是生成机制的副产物，不是态度问题。有效做法是提供可验证的证据（检索/工具）、要求引用、设置拒答条件，并在系统层校验关键字段。
进度保存在本机浏览器
2.3

大模型多模态：能看图 ≠ 看懂图

约 25 分钟 原理 + 实验 对照原文 ↗

学习目标

说清 LLM、VLM、原生多模态三阶段的差别，并解释为什么「截图问答」在图表和密集文字上容易出错。

前置知识

2.2 的 token 与上下文概念。

核心要点

  • VLM：图像 + 文本进，文本出；原生多模态：任意模态进、任意模态出，训练与推理更统一。
  • 图像会被切成视觉 token，分辨率越高 token 越多；压缩会丢细节，这是读错小字与坐标的常见原因。
  • OCR、图表理解、界面截图操作是三件不同的事，能力与失败模式都不同。
  • 多模态 Agent 的关键不在「能传图」，而在预处理（裁剪/放大/分帧）、结构化输出与回退路径。
  • 涉及金额、医疗、坐标等高风险读数，必须人工复核或用专用工具二次校验。

动手任务（25 分钟）

找一张带坐标轴的图表截图，让任意多模态模型提取 3 个数据点，再追问「你最不确定的读数是哪一个，为什么」。对比你自己读图的结果，记下偏差来源（分辨率 / 刻度 / 图例）。

自检

为什么模型可能「看见」了图却答错数字？
图像经过缩放与切块后，细小刻度与文字可能丢失；模型也可能依据常识「猜」一个合理值。让它给出读数依据（对齐的刻度、图例）能暴露不确定性。
什么时候不该用多模态模型，而该用专门工具？
需要精确坐标、表格逐格还原、身份证/发票字段抽取等场景，专用 OCR 或文档解析工具更稳定、更便宜，也更容易审计。
进度保存在本机浏览器
2.4

提示词工程：把要求写成可执行的约束

约 30 分钟 动手为主 对照原文 ↗

学习目标

写出一个四段式（角色 / 规则 / 流程 / 输出格式）的系统提示，并用反例测试它的边界。

前置知识

2.2；至少用过一次对话模型。

核心要点

  • 结构比辞藻重要：角色 → 目标 → 规则 → 流程 → 输出格式 → 示例，每块只放一类信息。
  • 用正面表述替代否定堆叠（「回答控制在 3 句内」优于「不要啰嗦」），模型更容易执行。
  • 示例（few-shot）通常比形容词有效；示例要覆盖边界情况，否则会固化错误模式。
  • 用分隔符（XML 标签 / 三引号）隔离用户输入，降低「忽略以上指令」类注入的成功率，但不能根治。
  • 提示不是越长越好：规则越多，冲突概率越高，token 成本也越高。

动手任务（30 分钟）

为「Python 代码审查助手」写系统提示，限制在 300 字内，必须包含：角色、3 条硬规则、审查流程、输出格式（问题 / 严重度 / 建议）。然后故意输入一段含 SQL 注入和硬编码密钥的代码、一段空代码、一段超长代码，记录它是否按格式输出、是否漏掉高危问题。

自检

为什么「不要编造」这类指令效果有限？
它只改变表述倾向，不改变模型的知识边界。更有效的是给出证据来源、要求逐条引用、规定「没有依据时输出不知道」，并在外部做校验。
提示词能防住提示注入吗？
不能。提示层只能降低概率。真正的防线在架构：不把不可信内容当指令、限制工具权限、敏感操作需人工确认、输出做白名单校验。
进度保存在本机浏览器
2.5

Token 与上下文：成本、上限与遗忘

约 20 分钟 概念 + 测算 对照原文 ↗

学习目标

估算一段中文的 token 量级，并解释「上下文窗口」为什么不等于「可用的信息量」。

前置知识

2.2。

核心要点

  • token 是模型处理的最小单位，不等于字或词；中英文、代码、符号的切分差异很大。
  • 中文常见量级约 1 个汉字 ≈ 1–2 token，但不同 tokenizer 差异明显，报价前必须用目标模型的 tokenizer 实测。
  • 上下文 = 系统提示 + 历史 + 检索内容 + 用户输入 + 预留输出，全部共享同一个上限。
  • 「支持 200K」不等于「200K 都有效」：成本线性增长，注意力会稀释，关键约束容易被淹没。
  • 工程上要设「上下文预算」，而不是能塞就塞——这也是阶段 3 上下文工程的核心。

动手任务（20 分钟）

准备一段 200 字左右的中文和一段 200 字符的 Python 代码，分别用目标模型的 tokenizer（或官方用量面板）统计 token 数，计算「字/token」比值。再用这个比值估算你项目里一份 10 页文档的输入成本。

自检

为什么不能用「字数 ÷ 2」来估算成本？
切分规则依赖 tokenizer：中文、英文、代码、emoji 的比例不同，且不同模型版本会换 tokenizer。粗略估算可以，但预算与计费必须以实际统计为准。
长上下文和 RAG 应该怎么选？
数据量小、需要全局理解时可以长上下文；数据量大、更新频繁、要求引用与权限控制时用 RAG。实践中常组合：检索缩小范围，再把必要片段放进上下文。
进度保存在本机浏览器