简介这份面向开发者的LLM入门教程合集源自吴恩达大模型系列课程由国内开发者翻译为中文并复现全部示例代码适合希望快速上手大模型应用开发的程序员与AI从业者。资源共469个文件包括176个Markdown文档、74个Jupyter Notebook脚本、116张示意图及15份PDF讲义配套模型参数与数据集文件一应俱全压缩包整体约226MB。已有1301人学习下载内容覆盖Prompt工程、RAG检索增强生成、微调与评估等核心主题代码以中文注释呈现便于对照练习。从环境配置到实战案例均有完整记录可帮助读者系统掌握基于LLM构建应用的关键技能节省搜集整理资料的时间。1. 吴恩达大模型系列中文版为什么它是开发者入门 LLM 的最短路径我见过不少后端工程师第一次碰大模型时第一反应是囤资料夹、买大部头结果一个月后还在「环境准备」里打转。吴恩达大模型系列中文版刚好反着来把 LLM 应用拆成提示词工程、API 构建、LangChain、评估调试、RAG、微调几个可独立上手的模块每个模块用一两段完整空闲时间就能跑通示例中文版又补上了字幕和术语对照门槛很适合每天只能挤出碎片时间的开发者。这门课解决的是「知道大模型是什么」和「能把大模型用在项目里」之间的断层。你不需要先啃完 Transformer 论文再写代码而是先通过可运行代码建立手感再按需补理论。它适合刚转 LLM 应用开发的后端或前端工程师也适合产品和技术负责人快速判断哪些需求值得用模型做。下面按我实际带团队学完整套课的顺序拆一遍模块怎么选、代码怎么跟、参数怎么调、坑在哪里。2. 课程地图与学习顺序按项目方向选模块而不是按发布时间刷课2.1 大模型系列不只一门课先看清模块边界和前置要求吴恩达大模型系列课程在 DeepLearning.AI 上以多个短课程形式发布从开发者视角看可以分成六个核心模块。很多人误以为这是一门几十小时的长课实际是几个一两个小时能学完一个模块的短课组合。这个设计背后的思路是LLM 应用开发的能力不是一条线性知识链而是几组相对独立的技能按项目需要取用就好。模块中文常用名解决什么问题适合角色前置要求Prompt Engineering提示词工程让模型按指定格式、语气稳定输出所有开发者无Building Systems with the ChatGPT API用 API 构建多轮对话系统把单次调用变成有状态的服务后端 / 全栈Python 基础LangChain for LLM Application DevelopmentLangChain 开发 LLM 应用用链、记忆、agent 组装业务逻辑应用开发会调 APIEvaluating and Debugging Generative AI生成式 AI 评估与调试量化回答质量定位失败样例测试 / 质量有调用经验Finetuning Large Language Models大语言模型微调让模型学习领域数据与行为算法 / 模型工程师理解训练基本概念Building and Evaluating Advanced RAG高级 RAG 构建与评估知识库问答的检索质量优化应用 / 算法懂向量库基础这张表不是按课程发布顺序排的而是按「开发者第一次用大模型时最常遇到的决策点」排的。同一个模块里通常会拆成五到十个短视频每个视频结尾有基于 Notebook 的代码可以先跑完再决定要不要深入看理论。因此第一遍过课不要追求每个视频都精读先按表格里的前置要求判断自己目前能碰哪一块。2.2 学习顺序取决于工作角色后端、算法、产品三条路线对后端或全栈工程师我一般建议的顺序是提示词工程 → 用 API 构建系统 → LangChain 应用开发 → 高级 RAG。这个顺序的本质是「先学会让单次调用可控再学会把多次调用串成服务最后加检索让答案有据可依」。每一步都建立在已经亲手跑过上一步代码的基础上跳过任何一环都会在后面报错时无法定位。很多人收藏了各式各样的大模型学习路线图其实这张模块表就是最可靠的路线图。对算法或模型工程师顺序则不同提示词工程仍然要先看但接下来优先微调和模型部署相关模块而不是在 LangChain 链式调用上花太多时间。因为核心问题通常是「底座模型能力不够」而不是「业务链路拼不起来」。对产品和项目负责人先把提示词工程和评估调试看完价值比直接追微调大得多评估模块会告诉你什么样的验收标准才算「大模型真的可用」。不管哪条路线都不要按课程发布时间顺序刷课。早期模块里的示例代码用的是当时最新的库版本它的价值在思路不在版本按项目倒推选模块才能让投入的每一小时都对应到一个具体交付物。2.3 中文版怎么用才不浪费字幕、术语表和代码复现三件套中文版信息通常由三部分组成中文字幕、术语对照表、社区整理的学习笔记。只看字幕是效果最差的方式因为 LLM 应用的难点在「动手」不在「听懂」。我见过不少开发者把视频当背景音刷完什么都能听懂脱离示例代码却一行都写不出来这就是典型的「眼睛会了手不会」。正确姿势是先看视频建立全局印象然后在课程自带的代码仓库里逐行复现最后回到中文笔记里的术语表做一次概念映射。例如 temperature、top_p、context window、fine-tuning 这些词中文笔记和英文字幕会各讲一遍对照着过一遍后以后查英文资料就不会被术语卡住。社区里流传的「吴恩达大模型系列笔记」大多会标出每个模块的代码入口和参数含义可以作为第二遍复习的索引。动手复现时建议不要复制粘贴而是手敲关键行并故意改坏一个参数观察报错。课程示例都是精心调试过的最小可运行代码改坏再修是成本最低的练习机会。核心原则只有一句中文版是降低理解门槛的辅助代码仓库才是真正要投入时间的地方。3. 用提示词工程和 API 搭一个能用的分类系统最小代码与参数怎么调3.1 系统提示与输出约束第一个能复现的分类器代码提示词工程模块最核心的收获不是「把提示词写得更花哨」而是「把输出格式锁死」。下面这段代码是课程里的常见最小示例我按工程习惯改成了环境变量读密钥并加了输出约束import json import os import openai client openai.OpenAI(api_keyos.environ[OPENAI_API_KEY]) system_prompt ( 你是客服工单分类器。 只输出 JSON格式为 {\type\: \投诉|咨询|故障\, \priority\: \高|中|低\}。 不要输出任何解释或前缀。 ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: 昨晚到现在 App 一直登录不上去账单也看不了。} ], temperature0, max_tokens100, ) print(response.choices[0].message.content)这段代码的核心不在模型选择而在system_prompt和temperature。system_prompt划定了模型的行为边界把「客服分类」这个任务从开放对话变成了约束输出temperature0让同样的输入不再抖出不同答案分类这种确定性任务必须锁死max_tokens100是防止极端输出烧掉上下文窗口也给下游解析兜底。如果你用的不是 OpenAI API也不用改思路。国内很多模型 API 都兼容这套messages结构只需替换base_url和api_key同一个提示词就能跑通。课程强调「提示词是可移植资产」就是这个意思——换模型时先改的是system_prompt里的约束而不是业务逻辑。提示直接替换base_url之前先确认目标 API 的模型名和该模型的上下文上限不同模型对同样参数的接受度不完全一致。3.2 从单轮走向多轮把分类、抽取和工具调用串成链路学会了单次调用怎么控构建系统模块就开始带你把多次调用串成服务。一个常见的课堂实践是先判断用户意图再抽取关键参数最后决定要不要调用外部工具。用代码表示大概是def route_user_request(user_text: str) - dict: intent_messages [ {role: system, content: 判断用户意图只输出 refund / tech_support / other 之一。}, {role: user, content: user_text}, ] intent_resp client.chat.completions.create( modelgpt-4o-mini, messagesintent_messages, temperature0, max_tokens10, ) intent intent_resp.choices[0].message.content.strip() if intent tech_support: extract_messages [ {role: system, content: 抽取设备型号和故障现象输出 JSON。}, {role: user, content: user_text}, ] # 第二次调用用结构化输出填充工单字段 extract_resp client.chat.completions.create( modelgpt-4o-mini, messagesextract_messages, temperature0, max_tokens200, ) return {intent: intent, fields: json.loads(extract_resp.choices[0].message.content)} return {intent: intent, fields: {}}这个例子的重点在「分治」不要指望一次调用同时完成意图判断和参数抽取。两次小调用每次只做一件事不仅结果稳定后续排查问题时也能精确知道是哪一步出错。课程里把这个叫「把复杂任务拆成子任务」后来很多 agent 应用包括 LangChain 模块里的链式调用和工具选择本质都是这个模式的系统化。注意第二次调用里的max_tokens200是刻意留的余量。参数抽取不仅产生 JSON字段值本身可能较长余量不足会在末尾被截断但也没必要给得更大结构已知的输出不需要模型自由发挥。判断某次调用的 token 上限是否合理可以先把输出内容手动复制到字数统计工具里量一下再留 30% 余量。3.3 三个必调参数的温度测试temperature、top_p、max_tokens很多新手把temperature调高当作「激发创意」这是整套课程里最常被误用的一对参数。先看一张我实际调参时常用的对照表参数取值范围调低的效果调高的效果适用场景temperature0 到 2输出稳定、重复率上升发散、创意增强但不稳定分类用 0文案 0.7-0.9top_p0 到 1候选词少、输出更确定候选词多、措辞更丰富与 temperature 二选一调max_tokens按模型限制可能截断浪费配额且增加延迟按真实输出量给上限实践建议是需要结构化输出时temperature给 0 或接近 0需要生成营销文案、话术时给 0.7-0.9不要同时调temperature和top_p两者都在控制随机性同时调会让效果互相抵消出了问题也难定位。max_tokens则相反它不控制随机性只控制输出长度上限设太大会在解析失败时默默浪费配额。判断参数是否合适的办法不是看单次输出好不好而是同一提示词在固定参数下跑十次统计输出格式的稳定性。格式稳定度不够时先调temperature到零而不是继续微调提示词。这是评估调试模块的核心方法提前在参数这里练起来后面会顺手很多。4. 从 RAG 到微调落地什么时候该检索什么时候值得让模型动刀4.1 RAG 最小链路切分、向量化与检索参数的取舍如果项目是知识库问答RAG 是首选路线。高级 RAG 模块会带你从最小链路一直走到评估改进最小链路就是加载、切分、向量化、检索四步。下面是我在本地复现时最常用的最小代码from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings loader TextLoader(./sop.txt, encodingutf-8) doc loader.load() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_documents(doc) vectorstore Chroma.from_documents(chunks, OpenAIEmbeddings()) retriever vectorstore.as_retriever(search_kwargs{k: 3}) question 离职交接需要走哪些审批流程 for doc in retriever.invoke(question): print(doc.page_content[:200])切分参数是 RAG 里最值得调的部分。chunk_size500意味着每段约五百个字符对中文来说大约是一百多字刚好覆盖一个「步骤」级别的语义单元chunk_overlap50让相邻片段有重叠避免一条完整规则被从中间切开而读不懂。separators里把中文句号、问号、感叹号放进去是中文文本比英文更需要的配置默认分隔符对英文句子友好对中文段落常常一刀切到无语义。k3这个检索数量是经验值。k 太小答案可能找不到关键段落k 太大会把不相关内容塞进上下文增加回答时的混淆和 token 开销。常见做法是起步用 3测试后往 5 以上调整同时结合评估指标看「检索命中率」到底是多少。知识库类项目包括常见的 llm wiki 形态本质都是这个思路先检索增强再谈模型能力。4.2 微调不是默认选项先确认检索不够再谈实战微调很多初学者一上来就想微调这是成本最高的一条路。微调解决的是「模型的领域行为不对」比如客服模型总把「保修」理解成「退货」或者产品要求模型用固定话术回答。如果你的需求是「模型不知道该答什么、知识不够」那是检索问题不是微调问题。课程里的微调模块会先教诊断方法拿到一批 badcase先人工判断失败原因是「知识缺失」还是「行为不对」。前者走 RAG后者才走微调。确认需要微调后数据集格式是基础指令微调一般用这样的 JSONL 条目{instruction: 请判断以下用户诉求应该分给哪个部门, input: 我昨天买的手机今天充不进电, output: 售后维修}而真正微调时LoRA 是低成本标配。下面是一个常见的配置框架用单卡就能跑通from peft import LoraConfig from transformers import TrainingArguments lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], lora_dropout0.05, ) training_args TrainingArguments( output_dir./finetuned_model, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs1, logging_steps10, save_strategyepoch, )r8和lora_alpha16是 LoRA 的常见起步值意思分别是低秩分解维度 8、缩放系数 16。秩越大模型能学到的行为越复杂但显存占用和过拟合风险同时上升。per_device_train_batch_size1配合gradient_accumulation_steps8等效于每 8 条样本更新一次参数是单卡显存不够时的标准做法。learning_rate2e-4对 LoRA 来说是安全区间调太低收敛慢调太高很容易训飞。4.3 选型判断快速验证用 API数据敏感时再考虑自建部署课程系列整体是 API 优先的思路早期模块甚至不碰部署。实际项目里我习惯按三个问题做选型第一数据是否能出域第二调用频次和单次成本是否可控第三性能瓶颈在模型本身还是在业务链路。验证阶段用云端 API 最划算课程里所有示例都能跑通按量付费的成本通常很低很多平台还提供新用户额度完全够把最小链路跑起来。市面上的知名大模型很多选型时不用追最新最强的那个先看三件事是否兼容messages结构、上下文窗口是否够用、单 token 价格是否在你的业务预算内。一旦数据敏感或调用量稳定上升再考虑私有化部署开源模型这就是「大模型部署」要补的功课也是和课程主线不同的一条分支。这条判断路径和课程安排是一致的先用 API 证明业务价值再决定是否投入部署。直接一开始就在本地部署一个开源模型往往 GPU 和调优成本花了业务价值还没验证这是入门阶段最容易犯的方向性错误。5. 入门阶段的避坑清单5 个高发翻车点与排查思路5.1 课程代码一跑就报错依赖版本才是最大变量现象照着视频里的代码逐行敲Python 解释器直接抛 ImportError 或 AttributeError怀疑自己抄错了。原因课程示例用的是录制当时的依赖版本你本地是最新版。langchain、openai 这些库更新极快同名 API 换了路径或改了参数是常态。解决先固定版本再跑代码。把课程仓库里 requirements.txt 的版本全部锁到指定版本然后建独立虚拟环境如果某个接口明确标了 deprecated优先查库的 release notes 里给的新路径而不是在旧代码上硬调试十几分钟。5.2 把大模型当搜索框用上下文结构比想象中更敏感现象连续追问后模型开始自说自话甚至答出与事实相反的内容新手第一反应是「模型不行」。原因把大模型当搜索引擎一次丢一句大白话上下文没有目标、没有输出格式模型当然往最省事的方向自由发挥。解决所有正式调用都要带system_prompt和三要素——任务、约束、输出格式。提问前先问自己这条回答要给人看还是给程序解析给人看写答案要点给程序解析就锁 JSON 或固定字段。课程里给的提示词模板就是这套思路直接套用比自己临场发挥靠谱得多。5.3 temperature 开太高创意没来翻车先来现象为了「更有创意」把temperature调到 1.2结果模型在金融或医疗场景里输出事实性错误被评审打回。原因temperature控制的是采样的随机性不是创造力。随机性越高越可能在语义边界上跑飞对需要事实准确的任务是灾难。解决事实型任务一律压到 0 或 0.1文案类任务最高给到 0.9 就已经很散。实在需要不同措辞时先改system_prompt里的风格描述再考虑调temperature。这个坑在评估调试模块里有专门案例提前避开能省不少返工。5.4 微调后 loss 降了效果却更差数据质量比算力更值钱现象微调一万条数据训练 loss 正常下降但评测集准确率反而比微调前更低。原因数据集里噪声太多模型把错误规律学到了。loss 下降只代表拟合到训练集不代表学到了你想要的领域行为甚至会把提示词里的格式要求一并覆盖掉。解决微调前做一次数据清洗至少检查三样标签一致性、输入输出对应关系、badcase 比例。一万条高质量数据往往好过五万条自动爬取。课程里特别强调「微调后的评估必须用训练外数据」这条红线不能省。5.5 API Key 泄露安全意识要前置到第一课现象把密钥写在代码里提交到仓库几个小时后发现账户被刷了几百块调用量。原因入门阶段只关心「能跑通」把密钥当成普通配置项放在源码或 .env 里.env 又跟着 push 到了远端仓库。解决三条底线缺一不可。第一密钥一律通过环境变量注入 Python 进程不写进代码文件第二.env 必须进 .gitignore提交前用 git status 检查敏感文件第三云端控制台里给密钥设月度限额真泄露时损失也是可控的。这不会提升模型输出质量但能保证你有后悔药吃。6. 课后怎么验证用最小闭环项目确认你已上手大模型6.1 最小闭环从一份 FAQ 文档到一个能回答的机器人课程全看完后比证书更有说服力的是你自己搭出来的一条闭环输入一份内部 FAQ交付一个能回答问题的命令行机器人。我一般要求团队里这样做把经常被问到的问题存成 markdown用 RAG 最小链路做检索再套一个system_prompt把答案限制在源文档范围内最后用下面这种脚本做回归。test_cases [ (密码忘了怎么找回, 重置密码), (离职交接要过哪些审批, 审批), (发票多久能开出, 三个工作日), ] for question, must_have in test_cases: answer ask_qa_bot(question) assert must_have in answer, f{question} 的回答缺少 {must_have}脚本里的must_have不是验证「模型答得对」而是验证「该有的环节没有漏」。跑不过不一定是模型问题也可能是切分参数或检索结果不对这刚好把课程的评估思路串了起来。6.2 三个通过标准判断自己是否真入门我只看三件事。第一不依赖课程代码能不能独立写出一条带格式约束的提示词第二出了 badcase能不能用温度、分段、检索参数说出改进方向而不是只会换模型第三面对「要不要微调」的提问能不能讲清楚什么时候检索、什么时候微调、什么时候部署。这三个标准都不需要高深算法。它们要的是你把每个模块都亲手跑过、改坏过、修好过。吴恩达大模型系列中文版给的是地图和最小路径剩下的路得靠你手里的 API key 和终端一步步踩出来。我自己的习惯是每学完一个模块就用课程代码仓库里的数据自问自答一遍确保脱离字幕也能说清每个参数在干什么。希望帮到你。本文还有配套的精品资源点击获取