许多开发者学习AI应用开发时，往往急于上手调API、接模型、搭建对话界面。
这种实践精神当然值得肯定，动手能力至关重要。
但坦诚地说，如果底层核心概念没有梳理清楚，后续开发中经常会遇到一些棘手且令人困惑的问题：为什么精心撰写的Prompt，模型却像视而不见？为什么RAG检索出的文档总是与预期不符？为什么同一个问题，今天回答准确，明天就开始胡说？为什么上下文塞得越多，最终效果反而越差？
这些问题表面上看像是“模型不稳定”，但真正的根源往往是：你还没有建立起AI工程的心智模型。
这篇文章不讲复杂的数学公式，也不奢望用一篇文章教会你训练大模型。目标只有一个：把编写AI应用前最应该掌握的10个概念讲透彻。
Token 是 AI 世界里的最小账本单位
当你输入一句话时，模型看到的并非完整的“句子”，而是一段段被切分的Token。Token可以是一个完整的词，也可以是半个词，甚至是一个标点符号。例如，英文单词building，可能会被切分为build和ing；中文文本也会依据模型自身的分词规则被切分成不同片段。
这个概念听起来基础，但它直接决定三件事：API调用费用按Token计算，上下文窗口容量按Token计算，模型生成速度也与Token数量相关。
因此，当你发现一次调用比预期更贵、长文档被意外截断、模型“忘记”了前文内容——很多时候并非模型在使性子，而是Token预算已经耗尽。
在编写AI应用时，必须先学会估算Token。尤其是在开发文档问答、长对话、代码分析这类功能时，Token就如同内存，一旦不足，系统必然出现问题。
Embedding 让文本变成可以计算的语义
模型无法直接对“含义”进行数学计算。它需要先将文本转化为一串数字，这串数字就是Embedding，也就是嵌入向量。
你可以这样理解：每一句话、每一段文档、每一个问题，都会被映射到一个高维语义空间中。语义相近的内容，它们在空间中的距离就近；语义相差很远的内容，距离就远。
例如，“医生”和“护士”通常会在空间中靠得很近，而“医生”与“显卡驱动”则会相距甚远。这就是语义搜索、推荐系统、文档问答等应用能够运作的基础。
开发者最容易踩的坑是：以为RAG检索不准确一定是大模型回答能力差。
在很多情况下，问题出在Embedding环节。文档切块过于粗糙、向量模型不适合中文、查询语句未经改写优化——这些都会导致“检索出来的上下文从一开始就是错误的”。后续的LLM能力再强，也只能拿着错误材料强行作答，效果自然不会好。
Attention 决定模型该看哪里
同一个词语，在不同的上下文中含义可能完全不同。“苹果很好吃”和“苹果发布了新系统”，这里的“苹果”显然不是同一回事。模型依靠什么来判断？依靠Attention机制。
Attention的核心思想是：每个Token都可以观察上下文中的其他Token，并为它们分配不同的注意力权重。如果句子里出现“股票”、“公司”、“发布会”，模型就更倾向于把“苹果”理解为Apple公司；如果出现“削皮”、“水果”、“甜”，它就更可能理解成水果。
这也解释了为什么写得越清晰的Prompt，模型输出越稳定。你给它一个模糊的指令，它只能在概率空间里猜测。但如果你提供了清晰的背景、明确的目标、具体的约束和示例，模型就有更多可用的上下文来分配注意力。因此，提示词工程绝非玄学，它本质上是在帮助模型将注意力集中到正确的位置上。
Transformer 是现代大模型的发动机
无论是GPT、Claude、Gemini还是Llama，背后都离不开Transformer这个核心架构。
你不必亲手编写Transformer代码，但至少需要了解其工作流程：文本先被切分为Token，Token再被转化为Embedding，随后经过一层又一层的Attention机制处理，最终预测下一个Token。注意，是预测下一个Token。模型并非一次性写完一整篇文章，而是边生成边将刚生成的内容放回上下文中，再继续预测下一个Token。
这个机制可以解释很多现象。长回答生成速度更慢，因为需要预测更多次。前文会影响后文，因为前面生成的Token会进入后续的上下文。输出偶尔不稳定，因为每一步都是在概率分布中进行选择。
理解Transformer的意义，不在于将模型神秘化，而在于将模型工程化，让我们能更好地控制和优化它。
LLM 本质上是一个超大规模文本预测器
LLM是Large Language Model（大语言模型）的缩写。它的训练任务听起来非常简单：根据给定的前文文本，预测下一个Token。本质上就是这一件事。
大量书籍、网页、代码、论文、论坛内容被输入给模型。模型不断进行预测，不断修正内部参数，最终学习到了语言、代码、事实、推理模式之间的复杂关系。这就是它能够写代码、做总结、翻译、解释概念的原因。
但这里有一个非常重要的边界需要明确：LLM不是数据库。它并非每次回答时都去某个地方查资料。在默认情况下，它是根据训练中学到的模式，生成最有可能出现的文本。
这个区别至关重要。如果你将LLM当作数据库来用，自然会期望它“查得准”。但如果你将其理解为预测器，你就会明白：当涉及事实信息、实时数据、内部资料时，必须借助外部来源，而不能单纯依赖模型记忆。
Hallucination 是能力边界，不是偶发小 bug
幻觉（Hallucination）是AI应用中最危险的问题之一。它并非“模型说得不够好”，而是模型会自信满满地生成错误内容。例如，引用根本不存在的论文，编造API参数，给出看起来非常合理但实际完全错误的业务数据，或者将两个相似概念混为一谈。
为什么会这样？因为模型的目标不是“保证真实性”，而是“生成最可能的下一个Token”。如果一个错误答案在语言模式上很流畅，它就可能被生成出来。这也就是幻觉特别危险的原因：它通常不像是错误，反而显得流畅、自信，极具迷惑性。
开发者要做的不是祈祷模型避免幻觉，而是在设计系统时默认它会犯错。事实类问题应使用RAG，关键输出要加入验证层，涉及外部状态时要使用工具调用。在生产环境中，切勿将原始LLM输出直接作为事实展示给用户。设计可靠AI产品的第一课，就是承认模型会出错。
Temperature 是控制随机性的旋钮
模型在生成下一个Token时，通常不会只有一个候选。它会为许多可能的Token计算概率。Temperature参数控制的是：模型有多大意愿选择那些概率不是最高、但也可能正确的答案。
低Temperature值，输出更稳定、更保守，更适合代码生成、事实问答、结构化信息抽取。高Temperature值，输出更具发散性和创意，更适合头脑风暴、文案创作、故事编写、创意探索。
一个非常实用的经验是：编写代码时，可以从0.1-0.2开始尝试；事实问答场景，可以从0.2-0.3开始；总结归纳类任务，可以使用0.3-0.5；聊天和创意写作，可以提高到0.7以上。
许多新手的问题在于：所有场景都使用默认的Temperature值。结果让模型写代码时，它过于富有创意；让模型写文案时，它又显得过于死板。Temperature虽然只是一个参数，但它会显著改变产品的使用体验。
Context Window 是模型的工作记忆
上下文窗口，指的是模型在一次调用中能够看到的所有内容。系统提示词、用户问题、历史对话、检索出的文档、工具返回的结果、模型已经生成的内容——所有这些都必须塞进这个窗口。
窗口再大，也不是无限大的。更麻烦的是，模型并不会均匀地阅读所有上下文。许多模型对开头和结尾的内容更为敏感，中间部分更容易被忽略，这就是常说的“Lost in the Middle”现象。
因此，管理上下文是AI工程中非常核心的能力。重要指令应放在前面，关键事实应靠近问题，长文档不应一股脑地全塞进去，而是需要先进行切块、检索、摘要，再整理后提供给模型。当你发现“我明明把资料给它了，它怎么还答错”时，先别急着责怪模型。你需要检查的是：资料是否真的在上下文窗口内，是否位于模型容易注意到的位置，是否与问题紧密相关。
RAG 让模型回答你的私有数据
RAG是Retrieval-Augmented Generation（检索增强生成）的缩写。它解决了一个非常现实的问题：模型的训练数据存在截止日期，模型并不知道你的内部文档、产品手册、用户数据以及最新的业务规则。
RAG的流程可以拆解为5个步骤：用户提出问题，将问题转化为Embedding向量，到向量数据库中检索相关文档，将检索出的文档和问题一并提交给模型，最终模型基于这些材料生成答案。这就是许多知识库问答、客服机器人、文档助手背后的核心架构。
RAG的优势非常直接。当数据更新时，只需更新文档库，无需重新训练模型；当需要引用来源时，检索结果本身就是依据；为了降低幻觉，可以让模型围绕真实的材料进行回答。
但RAG并不是“连上向量库就万事大吉”。真正影响效果的因素包括：文档切块策略、Embedding模型的选择、召回策略、重排序技术、上下文拼接方式以及答案约束条件。其中任何一个环节做得粗糙，最终都可能表现为“模型答得不好”。RAG看似只是一个功能，实际却是一条完整的工程链路。
AI Agent 的关键不是聊天，而是循环
普通LLM应用的模式是：你提问，它回答。AI Agent（智能体）的模式则是：你给出目标，它自行规划、调用工具、观察结果，然后再决定下一步行动。核心区别就在于这个循环执行的过程。
一个用于调试的Agent可能会这样工作：读取报错信息，搜索代码库，定位到相关文件，修改代码，运行测试，发现仍有失败项，再读取测试输出，继续修复，直到全部测试通过。
坦白讲，这也是Agent最让人兴奋、也最让人头疼的地方：它看起来像自动化，但真正的难点在于每一步都可能出现偏差。在这其中，模型只是“大脑”。真正让Agent能够行动的是工具：文件读写、代码执行、浏览器操作、搜索、数据库访问、API调用、邮件处理、日历管理等。
但Agent最难的地方也在这里。每一步都有失败的概率。一个3步的任务，假设每一步的准确率是90%，最终的成功率是72.9%。如果是10步，成功率会急剧下降。因此，Agent工程的重点并非仅仅是“让模型能够调用工具”，而是确保每一步都可观察、可验证、可回滚。能跑起来的Agent有很多，但能够稳定完成任务的Agent却很少。
写在最后：这 10 个概念要连起来看
如果你刚开始学习AI应用开发，可以按照这个顺序来理解和掌握。
先搞懂Token，因为它是成本、长度和速度的基本单位。再搞懂Embedding，因为它让文本可以被搜索和匹配。然后搞懂Attention，因为它解释了上下文为何如此重要。
接着了解Transformer和LLM，你会明白模型内部大致是如何生成文本的。再学习Hallucination、Temperature、Context Window，你会开始理解模型为什么会失控，以及如何有效控制它。
最后学习RAG和Agent，你才算真正进入了AI工程领域。
这10个概念并非10个孤立的术语。它们实际上是一条连贯的线索：文本如何进入模型，模型如何理解上下文，模型如何生成答案，系统如何弥补模型在事实方面的局限，以及最终如何让模型借助工具完成任务。
理解到这一层面，AI就不再是一个神秘的黑盒。它变成了一个可以被设计、被调试、被优化的工程系统。可以说，这才是动手编写AI应用之前，最值得补上的一课。
