写文献综述，AI列的参考文献一查DOI就404？5类AI工具横评+找文献到成稿搭配方案直接抄
2026/9/9 2:07:38
经常有朋友跑来问我：“LLM 到底该怎么入门？”问的人里有刚转行做 AI 的产品经理，有写过几年代码但没碰过大模型的程序员，也有完全没学过编程、纯粹想知道 ChatGPT 为什么这么聪明的学生。这个问题其实不好回答——不是难，而是网上的信息实在太乱了。有人让你先啃三个月深度学习，有人让你直接上手 LangChain，还有人告诉你“不需要懂原理，会调 API 就行”。结果很多人收藏了几十篇教程，真正自己要动手的时候还是一脸懵。
这篇文章我想用尽量朴素的方式，把需要知道的 LLM 入门知识一次性讲清楚。不堆公式，不抄文档，从“它到底是什么”到“我怎么真正用起来”，尽量把这几年的实践体会都说透。如果你正处于“听说过很多名词但串不起来”的阶段，这篇文章应该能帮你把散落的概念串成一条线，并且给你一条真正能落地的行动路径。
1. 先搞清楚：LLM 到底是什么，以及它为什么值得你入门
1.1 AI、机器学习、深度学习与 LLM 的关系
很多新手一上来就被“人工智能”“机器学习”“深度学习”“大语言模型”这几个词砸晕。我先用一句话把它们的关系捋清楚：AI 是一个很大的目标，让机器表现出智能；机器学习是实现这个目标的一类方法，核心是“从数据里学规律”；深度学习是机器学习里目前最成功的一个分支，靠多层神经网络来学；而 LLM，也就是 Large Language Model（大语言模型），是深度学习在语言这个领域里杀出来的明星路线。
所以你会看到，聊 LLM 的时候经常提到 Transformer、神经网络、预训练，这些词本质上都属于深度学习的技术范畴。而“大语言模型”之所以特别，在于它专门针对“语言”做了极致优化——它吃进去的是海量的文本，学出来的是语言的规律。
打个比方：AI 像是“让机器变聪明”的宏大愿望，机器学习是一套“从经验中进步”的方法，深度学习是这套方法里最锋利的武器，而 LLM 则是用这把武器在“理解语言和生成语言”这件事上打出的王牌。搞明白了这个层级，你就不会被各种名词绕晕了。
1.2 “大”在哪里：参数、数据与算力的量级概念
很多人会有个疑问：以前的聊天机器人也有，为什么偏偏这两年 LLM 爆发了？答案就在这个“大”字上。它不是指功能多、界面炫，而是指三个物理层面的东西呈指数级膨胀。
- 参数规模：模型的“脑容量”。从早期 BERT 时代的 1 亿级别，到 GPT-3 的 1750 亿，再到后来各家开源模型的 70B、上百 B，参数的膨胀速度非常夸张。
- 训练数据：模型“读过的书”。现在的先进模型几乎把互联网上高质量的公开文本都读了个遍，训练数据量级是以万亿 token 计算的。
- 算力成本：消化这些数据需要大量 GPU 并行计算，一次完整的预训练成本从几百万美元到上亿不等。
当这三样东西堆到某个临界点之后，模型突然表现出很多“小模型”不具备的能力——比如上下文理解、多步推理、代码生成、角色扮演，这些被称为“涌现能力”。这也是为什么 LLM 不是简单的“更大号的聊天机器人”，而是被看作一条通往通用人工智能（AGI）的可能路径。热词里有人搜“llm agi 模型端 推理端”，其实就是在关注这个方向。
1.3 大模型“会”什么，“不会”什么
入门阶段最重要的一件事：建立对 LLM 能力的正确预期。我见过太多人把 ChatGPT 一类产品当成“万能神器”，结果发现它数学题都能算错，或者一本正经地编造不存在的文献，就大失所望。
LLM 擅长的是：语言理解与生成、摘要、翻译、改写、代码编写与解释、头脑风暴、知识问答（基于训练数据范围内的常识性知识）、把复杂概念讲成人话。它在这些事上的表现，已经接近甚至超过普通人的平均水平。
LLM 目前搞不定的：没有持久记忆，对话窗口一关，它就不记得你这个人了；知识有截止日期，训练完之后发生的事情它不知道；会产生幻觉，不确定答案时会编一个听起来很合理的；精确计算和多步逻辑依然不稳定，数数、复杂推理偶尔翻车；缺乏真实世界的感知，没有手没有眼睛，不知道苹果咬一口是什么口感。
所以把它当“博学但偶尔会胡扯、记忆力很差的朋友”最合适。理解了这个定位，后面学 Prompt、RAG、Agent 的时候，才明白这些技术到底在解决什么问题。
2. 预测下一个词：LLM 最底层的运行逻辑
2.1 核心机制：它一直在玩“接龙游戏”
如果你只记住一个原理，那就记住这句：LLM 的核心任务就是“预测下一个词”。给它一串文字，它根据自己从海量文本里学到的统计规律，计算下一个最可能出现的词是什么，然后把这个词拼到原来的内容后面，再预测下一个。如此反复，整段话就出来了。
举个直观的例子。你输入“今天天气”，模型内部会估算下一个词的概率分布：可能是“真”（今天天气真好），可能是“怎么样”（今天天气怎么样），也可能是“预报”（今天天气预报说）。它按概率采样选一个，把结果接上去，接着预测下一个 token。
但这里有个细节常被忽略：模型实际处理的不是“字”，而是 token。token 可以理解为“语言片段”，一个英文单词可能被切成几个 token，一个汉字可能是一个 token。所以你在看上下文窗口、计费、模型长度限制的时候，单位都是 token 而不是“字”。理解这一点，后面就不会被“为什么这个模型说能处理 128K，我却只能放进去几万字”这类问题困扰。
2.2 训练三步走：预训练、SFT、RLHF
LLM 的能力不是天生就有，也不是靠人类一条条写规则写出来的。它的训练大致分三步：
| 阶段 | 目标 | 数据 | 产出 |
|---|---|---|---|
| 预训练 | 学会预测下一个词，掌握语言规律和世界知识 | 互联网海量文本，万亿 token 级 | 一个底子很厚但“不太会聊天”的基座模型 |
| 监督微调 SFT | 学会“好好说话”，按人类习惯问答 | 人工编写的高质量指令-回答对 | 一个能理解指令、能回答问题的基础助手 |
| 人类反馈强化学习 RLHF / DPO | 对齐人类偏好，让回答更有用、更无害 | 人类对多个回答的排序/评分 | 一个真正可用的聊天助手 |
你会发现，模型的底层知识几乎全部来自第一步预训练，后面两步更多是在“调教它的表达方式和行为”。这也是为什么很多开源基座模型（比如没有经过 SFT 的原始权重）用起来“智商在线但不会聊天”，逻辑就在这。
2.3 实战必须懂的几个参数与概念
不管你用 API 还是本地部署，以下几组概念是每天都要打交道的：
temperature：控制回答的“冒险程度”。范围一般是 0 到 2。越低越保守稳定，适合代码、结构化输出；越高越发散有创意，适合文案、头脑风暴。日常对话我常用 0.7。如果你发现模型老是胡说八道，先看看是不是 temperature 调太高了。
top_p：另一种采样控制方式，保留累计概率达到 p 的候选 token。一般和 temperature 二选一调。新手建议固定 top_p=1，只调 temperature。
上下文窗口：模型一次能“看到”的 token 数量上限。这就像一个工作台，你放的 system prompt、历史对话、参考文档，全都占用这张台子的空间。超出的部分会被截断或遗忘，这直接决定了 RAG 的 Chunk 设计策略。
system prompt：在对话开始前给模型设定角色、规则和风格，优先级高于普通对话。很多所谓的“完美提示词”，本质就是把 system prompt 写清楚了。它是最便宜的“模型调教”手段，也是入门者最值得练的基本功。
2.4 模型端与推理端：别再傻傻分不清了
热词里有人搜“llm agi 模型端 推理端”，说明很多人被这两个词卡住了。其实很好理解：
模型端负责“生产模型”。它涵盖数据收集、预训练、微调、评估、发布权重这几个环节。你听到的“训练一个 70B 模型”“用 LoRA 微调”“模型开源了”都属于模型端的事。模型端产出的是“权重文件”，就像一本写满了知识点的书。
推理端负责“使用模型”。把训练好的权重加载起来，部署成服务，接收用户的输入，通过前向计算输出结果。你调 API、用 Ollama 跑本地模型、把模型部署到线上，都是推理端的事。推理端不更新模型参数，只是“照着书里的内容回答问题”。
类比一下：模型端是培养厨师、给厨师写菜谱的烹饪学校；推理端是餐厅后厨，按照菜谱把菜做出来端给客人。你作为普通开发者在本地搞的环境搭建，绝大部分属于推理端。搞清楚这个边界，你在查资料时就不会再被“训练”和“推理”两个词反复绕晕。
3. 入门者的三条动手路线：对话、API、本地部署，从哪条开始最划算
3.1 路线一：先用聊天产品建立手感
很多人一上来就想着“我要部署一个模型到本地”，其实最容易犯的错误是跳过了“和模型交朋友”的阶段。我建议你先花几天时间，和市面上主流的聊天类产品好好相处——聊学习、让它写方案、让它解释代码，甚至故意让它犯错。
这个阶段的目标不是完成任务，而是建立“模型直觉”：它擅长什么、在什么场景下容易翻车、什么样的指令它听得懂、什么样的指令它理解偏。这种直觉是后面所有工程的底座。没有它，你写 Prompt 时不知道怎么描述需求，做 RAG 时不知道怎么设计检索问题，根本调不好效果。
3.2 路线二：调 API，性价比最高的开发起点
如果你想做点实际的东西，但暂时没有足够好的显卡，调 API 是目前性价比最高的路线。不用买硬件，不用管部署，花几块钱甚至几毛钱就能把主流模型的能力接入自己的程序。
以 DeepSeek 这类国内可直接使用的 API 为例，一个最小可用的 Python 调用大概长这样：
from openai import OpenAI client = OpenAI( api_key="你的API Key", base_url="https://api.deepseek.com" ) response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个乐于助人的技术助手。"}, {"role": "user", "content": "用一句话解释什么是向量数据库？"} ], temperature=0.7, stream=True # 流式输出，体验更接近真实对话 ) for chunk in response: print(chunk.choices[0].delta.content or "", end="")这段代码本身没什么难度，但它背后有四个细节值得你反复体会：第一，API 的调用方式其实都长得差不多，换模型只需要改 base_url 和 model 名；第二，system prompt 是控制回答质量性价比最高的杠杆；第三，stream=True 能大幅改善交互体验；第四，temperature 等参数要按场景动态调整，而不是一路用默认值。这些看起来是小事，但在真实项目里都是决定体验的关键点。
3.3 路线三：本地部署，自己动手跑一个模型
隐私敏感或想折腾一下的话，完全可以在本地跑模型。目前最友好的方式就是 Ollama，一条命令就能把模型拉下来跑起来：
# 安装 Ollama 后，下载并运行 7B 级模型 ollama run qwen2.5:7b跑起来之后默认会监听本机 11434 端口，提供 OpenAI 兼容的接口，你可以用 3.2 那一节同样的代码调用本地模型，只需要把 base_url 改成http://localhost:11434/v1。这就是为什么我建议你先了解 API 再玩本地——你会发现其中逻辑是相通的。
光有命令行其实不够舒服，可以再装一个 AnythingLLM 或者 Open WebUI 做可视化界面。尤其 AnythingLLM，很多人搜“anything llm 知识库”，就是因为在本地快速搭一个知识库问答应用，它几乎是零门槛的选择。这个我在后面工具链的章节还会展开。
3.4 本地部署前，先估算你的硬件能跑什么
本地部署最大的门槛是硬件，而新手最容易忽略的是：模型占用资源不只看参数量，还看精度和量化方式。粗略估算法则：需要的内存（GB）≈ 参数量（B）× 每个参数占用的字节数。以 7B 模型为例，FP16 精度下大约需要 14GB，但经过 4bit 量化（常见文件名里的 Q4_K_M）之后，只需要 4-5GB 左右，体验上损失也不算大。
我自己实测下来的感受是：8GB 显卡或 16GB 内存的电脑，跑 7B/8B 量化模型是比较舒服的，日常问答、写作、简单分析完全够用；想跑 70B 级别的模型，基本需要两张 24GB 显存的卡，或者直接用内存硬撑（速度会很感人）。所以入门阶段别好高骛远，一台普通笔记本 + 7B 量化模型足够你跑通整个流程了。
4. 从“会聊天”到“能落地”：Prompt、RAG、Agent 的分工与取舍
4.1 Prompt：你的第一项 LLM 工程能力
把 LLM 能力变成真实生产力，第一步就是写好 Prompt。很多人以为 Prompt 就是“说人话”，其实一个高质量的 Prompt 是有结构的。我的常用模板包括四个部分：
- 角色：你是一位资深 Python 后端工程师；
- 任务：请审查下面这段代码的并发安全问题；
- 要求：指出问题、给出修改后的代码、解释修改理由，如果没有问题就明确说“没问题”；
- 补充：代码/背景/限制条件。
在此基础上，还有两个很实用的技巧。一个是Few-shot 示例，给模型几个“问题-答案”的例子，它会模仿示例的格式和深度来回答，比干巴巴的“你要输出高质量内容”有效得多。另一个是链式思考，让模型“一步一步想”，在需要推理的场景下能显著降低错误率。但注意不要迷信网上那些“万能 Prompt 模板”，Prompt 必须结合你的具体场景反复调，谁也没法给你一个放之四海而皆准的句子。
4.2 RAG：让模型学会用你的知识库
Prompt 能改的只是“表达方式”，但模型不知道你公司内部的规章制度、不知道你私有文档里的内容、也不知道训练截止日期之后发生的事。要解决这个问题，主流方案就是 RAG（Retrieval-Augmented Generation，检索增强生成）。热词里很多人搜“rag增强llm”，方向完全正确。
RAG 的核心流程可以拆成四步：
- 切块（Chunking）：把长文档按语义切成若干小段。Chunk 太大，塞不进上下文且检索精度低；Chunk 太小，上下文碎片化、丢失语义。实践经验是普通文档 300-500 字一个 Chunk，并设置适当重叠。
- 向量化（Embedding）：把每个 Chunk 转成一组向量（一串数字），让语义相近的文本在向量空间里距离相近。
- 检索（Retrieval）：用户提问时，把问题也转成向量，在向量数据库里找最相似的 Top-K 个 Chunk。
- 生成（Generation）：把检索到的 Chunk 拼到 Prompt 里，让模型基于这些资料回答。
RAG 的价值不只是“给模型补充知识”，它还能大幅缓解幻觉，因为模型只需基于给定的参考资料回答，而不是凭空编造；同时知识可以随时更新，换一批文档就等于换了一套知识库，不用重新训练模型。对于大多数企业场景和数据敏感场景，RAG 是短期内最实用的落地方式。
4.3 Agent：让模型学会“干活”而不是“说话”
如果说 RAG 解决的是“知识不够”，Agent 解决的是“能力不够”。LLM 本质上只是个文本生成器，它不会查天气、不会订机票、不会操作你的数据库。但 Agent 给了它“手和脚”——让它能调用工具、能做规划、能根据工具返回的结果决定下一步行动。
比较经典的框架是 ReAct 模式：思考（Thought）→ 行动（Action）→ 观察（Observation）→ 循环，直到任务完成。比如你问“帮我查一下杭州下周的天气”，Agent 会先生成“需要调用天气查询工具，参数是杭州、下周”，然后调用工具获得结果，再把这个结果组织成自然语言回复给你。
实际项目中用 Agent 要注意一个坑：它并不是越“聪明”越好，而是可控性更重要。我给新手的建议是，先用最简单的方式（比如一个功能节点里只绑一个工具）把链路跑通，再逐步增加工具数量和任务复杂度，否则很容易出现模型反复调用错误工具、在死循环里打转的情况。
4.4 三种模式的选型判断
很多人一上来就想搞 Agent，但要我说，90% 的场景先用 Prompt 和 RAG 就够用了。把它们放在一起对比，思路就清楚了：
| 模式 | 解决的问题 | 技术门槛 | 适合场景 |
|---|---|---|---|
| Prompt | 让模型“好好回答” | 最低 | 通用问答、文案撰写、代码辅助、头脑风暴 |
| RAG | 让模型“知道你的私有知识” | 中等 | 企业知识库、产品文档问答、私有数据洞察 |
| Agent | 让模型“自己动手完成任务” | 较高 | 自动化流程、多步骤任务、工具编排 |
我的经验是：先用 Prompt 把模型的“说法”调好，然后看是否需要引入知识（RAG），最后才考虑让它自己动手（Agent）。次序反了，调试成本会成倍上升。
5. 工具链选型：从 LangChain 到 Dify，再到 Codex CLI
5.1 为什么 LLM 工具链一直在变
入门者最容易困惑的一件事：框架太多了，今天学 LangChain，明天又冒出 Dify，后天还有一堆新工具，感觉永远学不完。我想先说一个判断：工具变化快是正常的，因为 LLM 这个领域本身就在高速演化。早期大家想的是“怎么用代码把模型包起来”，所以 LangChain 这类编排框架火了一阵；后来大家发现“可视化拖拽 + 配置化”更好用，于是 Dify、Coze 这类低代码平台起来了；再后来，模型能力越来越强，工具链又开始往“原生集成”走，比如 Codex CLI 直接让模型接管命令行。
你不需要追着每个工具跑。工具是技能不是知识，用的时候学，比囤教程重要得多。真正的核心竞争力是你对模型能力边界、RAG 流程、Prompt 设计的理解，这些换哪个工具都不变。
5.2 知识库场景：AnythingLLM 与 Dify 的定位差异
如果你想快速搭一个知识库问答，我建议根据使用场景选择工具。热词里“anything llm 知识库”和“dify里的llm怎么设置”都有不少人搜，说明这两个是入门者的高频选择。
AnythingLLM更适合个人、小团队，它主打的是“本地优先”：下载安装、把文档拖进去、选一个本地模型（比如上面说的 Ollama），几分钟就能用起来。它的优势是简单直接，适合不想折腾代码的人。
Dify偏工程化一些，支持更完整的编排能力：可视化搭建工作流、配置多个模型供应商、做 RAG 管道、发布成 API 给其他系统调用。如果你的知识库要做成面向多人的服务，或者需要和现有系统集成，Dify 更合适。
5.3 工程化方向的新趋势：Codex CLI 这类工具的启发
还有一类工具正在改变 LLM 的使用方式，那就是 Codex CLI 这类“命令行/IDE 原生化”的工具。它们把 LLM 直接嵌入到开发者的日常工作流里——你在终端里描述需求，模型帮你写代码、跑测试、甚至修复报错。热词里有人搜“codex cli 接入llm”，本质上就是在探索“把 LLM 当成同事，而不是聊天对象”。
这类工具给我最大的启发是：LLM 能力的释放方式正在从“对话框”转向“接口化、流程化”。以后好的应用可能不再是一个聊天窗口，而是把 LLM 拆成各种能力组件，嵌入到具体业务流里。这也是为什么我反复强调：入门 LLM 别只盯着聊天，多想想你在做的事情有没有哪个环节可以被“文本输入-文本输出”的组件替代。
5.4 一个实测细节：Dify 里怎么让模型不输出思考过程
最后说一个很多人在 Dify 里会遇到的实测问题——为什么模型回答前输出一大段“思考过程”？这类问题主要出现两种场景：一是用了 DeepSeek-R1、QwQ 这类推理型模型，它们在最终回答前会先进行长串推理；二是模型服务端把 reasoning_content 字段和 content 拼接在了一起。
我的处理思路是分三步排查：
- 看模型服务端：如果用 OpenAI 兼容接口接入了推理模型，检查返回结果里是不是多了一个 reasoning_content 字段。这是“思考过程”的真正来源。
- 看 Dify 编排节点：在 Dify 的 LLM 节点里，确认输出的变量只引用了 content 字段，没有引用 reasoning_content。很多情况下，模型把思维链作为正常内容输出了，只需要在提示词里明确要求“直接给出最终答案，不要展示推理过程”。
- 换模型版本：如果业务场景不需要深度推理，直接用不带思考过程的普通对话模型更省心，比如 DeepSeek-chat 而不是 deepseek-reasoner。省 token，响应也更快。
这类问题看似很小，但非常影响用户体验。排查思路比具体操作更值得记下来：先分清“模型的输出”和“产品层的展示”，再定位是在哪一层需要处理。
老实说，LLM 入门最大的坑不是资料不够，而是永远在“看教程”和“收藏工具”的路上，迟迟不真正动手。我自己见过太多人花了一个月逛论坛、对比框架、刷视频，最后连一个最小 Demo 都没跑通。我的建议非常朴素：今天先注册一个 API 或者本地装一个 Ollama，写一个 20 行的脚本让它帮你总结一段文字。哪怕这东西丑得不行、逻辑简陋，你也已经迈出了最难的那一步。后面所有的进阶知识，都会在你真正用起来之后，变得顺理成章。