大模型入门 · 研发产品共学版
先分清 Tokenizer 的格式转换与 Transformer 的读写模块，再看应用层怎样用 RAG 补证据、用 Tool 与 MCP 连能力，并由 Agent、ReAct 与 Skill 组织成可控的任务系统。
Course Directory · 先选阅读方式
快速浏览适合会前预习；完整培训保留互动、案例与小测。所有讲解卡都已放回对应概念旁边，不需要再跳到页面底部找讲稿。
16 个概念 + 一次 AI 任务链
知道每个概念处在模型、上下文、连接还是编排层。进入本章 →
Tokenizer 格式转换 · Encoder / Decoder 读写
能分清两种“编解码”，再用“读与写”讲清 Transformer 与 GPT。进入本章 →
Token、Context、Prompt、RAG
知道怎样把正确、相关、可追溯的材料交给模型。进入本章 →
Tool、MCP 与权限边界
能区分模型提出调用与系统真正执行动作。进入本章 →
Agent、ReAct 与 Skill
区分固定 Workflow、Agent 与 ReAct 式动态循环。进入本章 →
工程边界、讲解卡与小测
用检查问题验收产品，并能沿页面完整讲给同事听。进入本章 →
能力链全景图
把每个概念当作一位“工种不同的同事”：有的负责拆文字，有的准备资料，有的真正动手，有的围绕目标不断判断下一步。
一句话类比
大语言模型会根据已经看到的内容，计算下一个 Token 的可能性，选出一个，再继续预测。海量训练让它学会语言规律、知识关联和常见的问题解决方式，所以表现得像在理解和思考；但它生成的是“合理的延续”，不天然保证事实正确。
像一位读过海量材料、每次只接一个词的超级接话员。
流畅不等于真实；LLM 不是搜索引擎，也不是训练资料的原文数据库。
答错一次的业务损失有多大？需要检索、工具还是人工复核？
下一句这样接模型并不直接阅读文字，先看入口处的 Tokenizer。
从概念地图，走进一次真实任务
One Request · Five Stages
不再把 16 个术语各背一遍。点击右侧五个阶段，看输入怎样经过模型、拿到证据、调用能力，最后在 Agent 循环里完成目标。
先说清目标、必要背景、边界、成功标准和输出格式，减少模型需要猜测的空间。
Before & After · Transformer 前世今生
入门只记四个节点：以前按顺序读；2017 年 Google 提出 Transformer；2018 年出现偏读的 BERT 与偏写的 GPT；2022 年 OpenAI 发布 ChatGPT。
Google 团队在 2017 年提出 Transformer；OpenAI 沿 Decoder 路线发展 GPT，并在 2022 年发布 ChatGPT。前者是模型架构，后者是在架构之上加入训练、安全、上下文与产品体验的完整系统。
Google 团队发表《Attention Is All You Need》。原始模型为机器翻译设计，左边是 Encoder，右边是 Decoder。
它改变了什么？Attention 从辅助角色变成序列处理的核心。查看原始论文 / 官方材料 ↗
早期序列模型常按顺序传递信息，句子很长时，前面的内容容易被淡化。Google 团队在 2017 年提出 Transformer，让不同位置可以更直接地交换信息。原始模型为机器翻译设计：左边负责读输入，右边负责写输出；GPT 后来主要采用 Decoder 路线。
过去像排队传话；Transformer 像把整份会议记录摆在桌上。
Transformer 不等于 ChatGPT；后者还包含训练、安全、上下文和产品系统。
面对长输入时，哪些位置真正需要互相参考？
下一句这样接先把它拆成两个角色：一个负责读，一个负责写。
Four Steps · 不背公式也能讲清
先说“切、读、选、再写”。听众建立直觉后，再补一句 Attention 就是“当前应该重点参考谁”。
Tokenizer 把输入拆成 Token，并换成模型能计算的编号。
→Transformer 让当前 Token 重点参考句子里真正相关的位置。
→模型比较许多候选，选出下一个最合适的 Token。
→把刚生成的 Token 放回前文，继续预测，直到答案结束。
→Two Meanings · 先分清两种“编解码”
点击三个角色切换。先讲它做什么，再明确 Tokenizer 的 encode / decode 与网络模块 Encoder / Decoder 不是一回事。
文字 ⇄ Token ID，是进出模型时的格式转换。
读取输入 / 逐步生成，是模型内部的网络模块。
进入模型前，encode 把文字切成 Token 并换成编号；离开模型后，decode 把编号还原成文字。它不属于 Transformer 网络层。
举例encode：“大模型入门” → 片段 → 编号；decode：编号 → 片段 → 可见文字
每张卡都放在对应概念旁边，顺着网页向下滚即可继续讲。
模型不能直接接收人类文字。Tokenizer 会先把文字切成片段，再把片段换成整数编号，这一步常叫 encode；模型生成编号后，它又把编号还原成可见文字，这一步常叫 decode。不同模型使用不同规则，所以同一句话的 Token 数量和编号也可能不同。
像双向翻译员：进门时把人话翻成号码，出门时再把号码翻回人话。
这里的 encode / decode 是格式转换，不等于 Transformer 网络里的 Encoder / Decoder。页面切分也只是示意。
同一句话换一个模型，Token 数量和编号会不会变化？
下一句这样接Tokenizer 切出的每一块，就是 Token；接着再看网络里的“读者”和“写作者”。
Encoder 会同时参考输入中的前后内容，为每个 Token 形成结合整段语境后的表示。它不是简单把全文压成一句摘要。原始 Transformer 用 Encoder 阅读源语言；BERT 则是常见的 Encoder-only 模型。
像秘书完整阅读材料，并在每句话旁补上它与前后内容的关系。
不是所有大模型都有独立 Encoder；GPT 主要使用 Decoder 堆栈。
任务更偏理解、分类和抽取，还是开放生成？
下一句这样接Encoder 能读懂前后关系，靠的是“此刻重点看谁”。
处理当前 Token 时，Attention 会给其他可见位置分配不同的重要程度，再汇总有用信息。它会随输入内容动态变化。入门时不必先背公式，只记住一个问题：为了理解或生成当前内容，此刻应该重点参考哪些位置？
像拿着荧光笔阅读：问题不同，圈出的重点也不同。
Attention 权重不是完整的人类解释，也不能保证每个头都有清晰语义。
“它”到底指代前面的哪一个对象？
下一句这样接读懂输入以后，还要把答案一个 Token 一个 Token 写出来。
Decoder 负责逐步生成输出。预测下一个 Token 时，它只能参考已经出现的内容。原始 Transformer 的 Decoder 还会查看 Encoder 读出的输入；GPT 采用 Decoder-only 路线，把提示词和已生成内容放在同一条序列里继续写。
像文字接龙：每写一个词，都重新看前文再决定下一个。
Decoder-only 不是没有理解能力；“读者/写作者”只是入门偏好，不是绝对边界。
为什么生成答案通常仍要一个 Token 接一个 Token？
下一句这样接模型会读会写以后，再看这一次到底能看到哪些材料。
Original Transformer · 原始结构
这张图只保留培训必讲关系；不要在入门阶段先铺 Q、K、V、矩阵和层数。
文字 → Token ID
每个位置结合前后内容，形成一组带语境的“阅读笔记”。
输入：源语言 / 文档 / 句子只能看已经出现的输出；在原始架构中，还会回看 Encoder 的阅读笔记。
输出：译文 / 摘要 / 回答Token ID → 文字
Attention · 只问一个问题
读到“它”时，模型应该重点参考“手机”，而不是水果“苹果”。Attention 做的，就是根据当前内容动态决定重点参考哪些可见位置。
Three Families · 三条常见路线
点击切换即可。英文技术名放在小字里；这些是结构偏好，不是绝对能力边界。
根据前文继续写
同一段内容里的位置互相参考，找出当前相关信息。
Decoder 写答案时，回看 Encoder 读出的输入信息。
每个位置拿到相关信息后，再做一次独立加工。
Decoder 写到当前位置时，遮住还没有生成的未来答案。
不必沿着长句一步步传话，较远的位置也能更直接地交换信息。
同一层的多个位置可以一起计算，更适合现代加速硬件。
训练能并行，不代表整篇回答会一次全部出现。
动手比背定义更有效
以下演示都为教学简化，不模拟任何特定模型。它们的作用是建立直觉，而不是给出精确计费或性能结论。
试着修改输入。中文常常不是严格“一字一 Token”；英文单词也可能被拆成词根、前后缀或符号。
示意切分，不代表具体模型的 Tokenizer 或真实 Token ID。打开 OpenAI 官方 Tokenizer 实测 ↗
Token 是模型处理文字的基本单位。模型收到 Token 编号后，会把它转换成可以计算的表示，再交给网络处理。Token 数直接影响一次能放多少材料、回答速度和调用成本，但字符数不能简单换算成 Token 数。
Tokenizer 是切菜机，Token 是切好后的一块块食材。
Token 不等于一个字或一个单词，Token ID 也不表示语义大小。
产品是否需要在输入前估算、截断或分段？
下一句这样接文字变成积木后，需要一种架构让它们彼此交换信息。
资料之间会争夺注意力与成本。先放真正相关的，再为模型输出预留空间。
行李箱快满了：考虑裁剪历史或只检索最相关片段。
Context 通常包括系统指令、用户问题、对话历史、检索片段、工具说明和工具结果。模型参数像长期训练形成的底子，Context 则是这次临时摊在桌面上的材料；没有放进来的公司文件，模型就看不到。
像会议桌上的任务单、历史记录、参考文件和刚查到的数据。
Context 不等于长期记忆；跨会话记忆通常需要外部存储和检索。
哪些材料必须带入本轮，哪些应该删掉或摘要？
下一句这样接桌面能放多少材料，还受到 Context Window 的限制。
Context Window 表示一次请求能容纳的 Token 总量，需要同时考虑输入和输出空间。窗口大可以处理更长的材料，但成本、延迟和干扰也可能更高。产品重点不是把所有内容塞进去，而是留下相关材料并给回答预留空间。
行李箱变大可以多装，但不保证需要时马上找到正确那件。
上下文窗口不是永久记忆，也不是模型智力的大小。
超限时应该摘要、分段、检索，还是拆成多个任务？
下一句这样接容量有限时，更要把本次任务说清楚。
点击组件，观察任务说明书如何逐步变得可执行、可验收。
目标 + 必要背景 + 边界条件 + 输出格式 + 少量高质量示例
TRAINING BRIEF.md目标：为研发产品同事解释 RAG，并给出一个电商客服场景。
背景：听众懂基本软件概念，但没有机器学习经验。
约束：避免公式和营销话术；明确它不能保证答案正确。实用 Prompt 会说清目标、必要背景、限制条件、成功标准和输出格式，有时再给一个示例。重点不是无限加长，而是明确“什么算完成”。能用程序校验的格式、权限和业务规则，不要只靠语言约束。
给同事一张清楚的需求单，而不是一句“帮我弄一下”。
Prompt 只是 Context 的一部分；更长、更强硬不一定更好。
怎样才能自动判断结果是否合格？
下一句这样接说明再清楚，如果缺少最新资料，仍需要 RAG 把证据找回来。
RAG · 从资料入库到基于证据回答
RAG 是“检索 + 上下文编排 + 生成”的系统模式，不是简单“把 PDF 丢给模型”。是否展示引用是产品选择；引用是否忠实仍需单独评测。
把手册、规则、工单拆成可检索片段，并保留标题、时间、权限等元数据。
用关键词、向量或混合检索建立索引；向量表示语义相似，不等于事实正确。
结合当前问题与对话，把口语问题变成更适合检索的查询。
先找候选，再按相关性、时效、权限和多样性筛出少量证据。
把问题、证据和回答规则交给模型；产品可附引用，并允许在证据不足时明确说明。
RAG 会先从知识库检索与问题相关的内容，再筛选有用片段，把它们放进 Context，最后由模型生成答案。它适合补充企业私有知识和经常变化的信息；若希望用户看到依据，还要额外设计引用展示和核验。
像客服回答制度问题前，先查最新版员工手册。
RAG 不能自动消灭幻觉；检索、原文和生成三个环节都可能出错。
无可靠证据时，系统应该拒答、追问还是转人工？
下一句这样接RAG 主要把资料带回来；真正查询或写入系统，需要 Tool。
Answer → Action · 从回答到行动
沿用差旅任务：模型可以建议查询合规行程，但真正的执行、鉴权、审计与提交确认必须留在确定性的系统里。
这条边界非常重要：鉴权、参数校验、超时、重试、审计，都应由确定性的系统代码兜底。
“查找下周去上海的合规行程，先不要提交。”
→生成 travel.search 与出发地、日期、预算参数。
→校验权限和参数，向差旅行程服务发起只读查询。
→返回结构化数据：班次、价格、退改规则与可用性。
→结合差旅制度证据生成备选方案，并停在提交确认前。
✓应用先把工具及参数说明交给模型；模型返回工具名和结构化参数；应用再校验身份、权限和参数，真正执行查询或写入，并把结果交还给模型。模型本身没有直接进入数据库。
模型像填写申请的顾问，真正查账户和盖章的是有权限的柜台。
模型说“已执行”不等于操作成功，必须以工具的真实返回为准。
哪些动作只读，哪些动作必须让人确认？
下一句这样接工具多起来以后，需要一种统一的连接方式。
从 Tool 到 MCP
统一协议 · 降低连接成本
MCP 规定客户端与服务端如何发现和调用 Tools、读取 Resources、获取 Prompts。它降低协议层的重复适配，但不会消除业务模型、鉴权、数据质量与风险控制工作。
服务端暴露的可调用函数；模型可以提出调用，客户端仍负责授权、确认与执行控制。
服务端以 URI 暴露的数据；宿主应用决定是否以及怎样把它加入 Context。Resource 本身不等于 RAG。
服务端提供的可复用提示模板，通常由用户显式选择；它不是包含工作流与资源的 Agent Skill。
MCP 是 AI 应用连接外部能力的一套协议。服务端可以统一提供 Tools、Resources 和 Prompts，客户端也能统一发现和使用它们，减少重复适配。但身份认证、业务授权、数据质量和高风险确认仍由平台负责。
像 USB-C 统一插口，但设备能访问什么仍由权限决定。
MCP 不是模型、数据库或 Agent，也不是天然安全边界。
谁能发现、读取或执行这些能力？
下一句这样接工具接好了，接下来由谁根据结果决定下一步？
Roots、Sampling 与 Logging 已被弃用，但会在兼容期内继续工作。新实现不应把 Roots 当成权限机制；范围应通过 Tool 参数、Resource URI 或服务端配置传递，并由服务端或操作系统真正强制校验。
查看官方更新 ↗Real MCP Servers · 真实案例
以下均为官方维护或 MCP 官方参考实现；调用故事用于教学演示，不冒充厂商客户案例。
“汇总 issue #128、关联 PR 和失败的 CI，再草拟修复清单。”Agent 可读取仓库与工单；确认后再创建评论或 PR。
先开只读模式或只启用 repos / issues 等必要 toolsets；写操作单独确认。
“在指定项目目录里找出所有支付重试配置，汇总差异，并修改已批准的配置文件。”
只开放明确目录并由服务端或操作系统强制校验；不要把已弃用的 MCP Roots 当成权限机制。
“打开测试站，完成登录后的下单流程，定位失败步骤并留下复现说明。”
网页内容可能不可信；支付、发布、删除等副作用动作必须拦截或人工确认。
“查清 Azure Functions 当前的超时限制，并给出对应版本的官方依据和代码样例。”
它只检索公开资料且无需登录；仍要核对产品版本、区域、预览状态与原文日期。
从回答问题，到完成目标
真正的 Agent 会查看状态、选择行动、读取结果，再决定继续、改计划还是停止。ReAct 是其中一种“判断 → 行动 → 观察 → 再判断”的代表性模式。
这段动画使用预设步骤，不调用真实模型、工具或差旅服务。读取需求：下周上海、合规、先不提交
检索最新版差旅制度与预算上限
查询行程并校验价格、时间与退改规则
生成 3 个备选与报批草稿，等待人工确认
现在四个步骤写在前端代码里，只是帮助理解循环。真实 ReAct 中，模型会根据上一轮工具返回动态选择下一步，失败时也可能换方案、重试或停止。
每张卡都放在对应概念旁边，顺着网页向下滚即可继续讲。
Agent 会查看当前状态、选择下一步、调用工具、读取结果，再判断继续、调整还是停止。它适合多步和动态分支任务，但循环会累积错误、成本和权限风险，因此必须设置工具范围、预算、超时、最大步数和人工确认点。
像会查制度、搜行程、比较方案并在失败后换办法的助理。
画成循环不一定就是 Agent；步骤全由代码写死时更像 Workflow。
什么时候算完成？什么时候必须停下来求助？
下一句这样接Agent 有多种实现方式，ReAct 是其中一种代表性思路。
ReAct 来自 Reasoning and Acting：系统根据当前信息选择行动，读取外部观察结果，再继续决定下一步。现代产品不必展示模型的内部思维文本；真正重要的是，上一轮真实结果会不会改变后续行动。
像导航：走一步、看新路况，再决定下一步。
本页动画步骤预先写好，只是 ReAct-like 教学示意，不是真实 ReAct Agent。
如果工具返回失败，下一步会动态改变，还是仍按预设顺序播放？
下一句这样接循环解决下一步怎么选，Skill 解决成熟做法如何复用。
Progressive Disclosure · 渐进式披露
本页所说的 Agent Skill，指采用 SKILL.md 一类文件式约定的任务方法包：先用发现元数据判断是否匹配，再按需读取详细指令、脚本、模板与参考资料。具体怎样发现和加载，由宿主平台决定。
先用很少的上下文判断：这个 Skill 与当前任务是否相关？
name: report-analysis description: 分析业务报告并输出洞察
点击上方三个层级即可切换；鼠标、键盘 Enter / Space 和触屏均可操作。
Skill 可以把某类任务的说明、步骤、脚本、模板和参考资料组织成方法包。系统先用名称和描述判断是否匹配，匹配后才加载详细说明，执行到具体步骤时再读取所需资源，既节省 Context，也方便团队维护。
像新同事接到任务后，按需打开 SOP、模板和验收清单。
Skill 不会自动运行，也不会自行获得 Tool 权限；第三方内容仍需审核。
触发条件是否清楚？脚本会读写什么？谁负责版本和审核？
下一句这样接把 Skill、Agent、MCP 和 Tool 组合起来，才是一套完整且可控的系统。
序列架构，不负责检索、权限或任务编排。
可以临时或复用，最终进入 Context。
检索、筛选、注入与生成的应用模式。
有输入输出约定的能力，执行权在宿主。
协议；Tool 不必使用 MCP，MCP 也不只有 Tool。
目标驱动的动态决策系统，可组合模型与工具调用。
可发现、按需加载的方法包；不授予权限，也不会自行运行。
A REALISTIC SKILL.md · 最小可用示例
名称和描述负责“什么时候触发”；正文负责“触发后怎么做”；发送或发布属于有副作用动作，必须等待明确授权。
---
name: weekly-project-update
description: 将项目笔记整理为“进展、计划、问题”周报；用户提到周报或项目更新时使用。
---
# Weekly Project Update
1. 只使用用户提供的事实；缺失信息标为“待确认”。
2. 按“进展 / 计划 / 问题与风险 / 需要协助”输出。
3. 每条尽量包含事实、影响、负责人和日期。
4. 未经明确授权，只返回草稿，不发送或发布。
Real Skills · 真实案例
这些案例来自官方预置技能、官方文档示例或公开技能仓库，展示的不是一句提示词，而是完整工作方法。
识别周报、3P 更新、公司通讯或 FAQ 等内部沟通类型，只加载对应示例，再按组织语气和结构起草。
先判断 PDF 是文本、扫描件还是表单；需要填表时再读取 forms.md，调用字段提取与填充脚本，最后逐页核验。
调研目标 API 与最新 MCP 规范，设计工具命名、分页、错误和注解，完成服务端后再用 Inspector 与评测问题验证。
读取 Notion 中的 PRD，提取需求与验收条件，生成实施计划和任务，并在明确授权后回写进度。
从好懂，走向准确
入门培训最怕两件事：全是术语，或者把比喻当成事实。下面这张表把二者接起来。
“为什么 AI 能写草稿，却不该直接提交？”
从核心架构、读文字、装资料讲到开卷回答。
从回答问题升级为安全地完成任务。
回看权限、证据与停止条件，确认不是“听懂了而已”。
3 分钟知识小测
延伸阅读 · 一手资料优先
页面内容结合原始论文、官方规范与真实项目案例整理，并在教学比喻之外补充工程边界。链接会在新窗口打开。