如果你手头有十几个G的“大模型学习资料”却还是写不出一段能稳定返回 JSON 的业务代码那么大模型学习的问题通常不在资源数量而在学习顺序。这两年我常被问到类似的问题想学 LLM 大模型是不是得先把机器学习、深度学习全部补完Transformer 的 attention 公式还没看懂能不能先上手做应用吴恩达的课那么多到底应该先看哪一个我的看法是如果你走应用开发方向真正高效的学习顺序不是“从数学原理一路推到模型源码”而是“先会用再会调最后理解为什么”。吴恩达和 DeepLearning.AI 推出的 LLM 系列课程之所以能成为很多人的大模型入门首选不在于它把注意力机制讲得多么深而在于它替学习者整理出了一条从提示工程、RAG、Agent 到微调的进阶路线。这篇文章不打算帮你“鉴定哪套资源最神”而是把吴恩达 LLM 课程背后代表的 LLM 大模型学习地图拆开来看概念层、提示工程层、应用开发层、模型选择与微调层、底层原理补全层。每一层我都会给出可运行的最小示例、判断标准和常见误区方便你对照自己的进度。文中如果涉及具体课程名称和内容请以官方页面为准。我的目标是给你一份能照着练习的路线图而不是一份收藏后就吃灰的资料清单。1. 先搞清楚大模型学习缺的不是资料而是地图打开任何一个搜索工具输入“大模型学习路线”你都能找到几十篇内容相似的文章第一阶段学 Python第二阶段学机器学习第三阶段学深度学习第四阶段学 Transformer第五阶段学部署……单看每一步都没问题但合在一起很容易让人劝退。原因很简单这套路线是按“算法研究员”的成长路径设计的不是按“LLM 应用工程师”的成长路径设计的。如果你最终目标是在业务系统里接入大模型让它完成信息抽取、文档问答、代码生成、智能客服这类任务那你不一定需要先花三个月推导反向传播。你更需要先搞清楚模型怎么调用输入输出怎么设计知识库怎么接进去效果怎么评测线上怎么监控。这些能力恰恰是吴恩达课程体系最擅长教的。从公开资料看DeepLearning.AI 上的短课程覆盖了提示工程、LangChain 应用开发、RAG、微调、评估调试等方向设计思路非常明确让已经有基本编程能力的开发者快速体验到“从 API 到完整应用”的完整链路。所以我建议你把注意力从“找一套完美课程”转移到“建立自己的学习地图”上。1.1 学习路径里的三层结构我习惯把 LLM 大模型学习拆成三层层次核心任务典型问题典型岗位应用层调用模型 API处理输入输出做 Prompt 设计和效果调优怎么让模型稳定输出 JSONLLM 应用开发者工程层搭 RAG、Agent、缓存、评测、监控和运维体系知识库检索不准怎么排查AI 应用工程师原理层理解 Transformer、预训练、微调、对齐原理attention 为什么有效微调和预训练有什么区别算法工程师、研究工程师大多数人不需要把三层全部学完才能上手。正确做法是先进入第一层和第二层做应用遇到问题后再向第三层追根因。1.2 为什么吴恩达课程适合作为参照系吴恩达课程真正降低的是“大模型应用开发的起步成本”。过去要做一个大模型应用你需要自己搞定模型部署、GPU、推理框架、微调平台。现在大部分模型都有 API命令行几行代码就能调用。变化发生在工程链路上原来最难的“训练模型”已经不是瓶颈最难的是“怎么把模型接进业务”。在这个背景下课程的价值不再是教你“大模型是什么”而是帮你快速建立一套应用开发的思维框架。2. 入门先解决三件事概念、Token、调用方式不管你看的是哪套 LLM 教程入门阶段的核心内容基本一致。搞清楚下面三件事你就越过了第一道门槛。2.1 LLM、大模型、生成式人工智能的区别很多初学者会把这三个概念混用实际上它们粒度不同。生成式人工智能是一个更大的范畴指能生成文本、图片、音频、视频等内容的人工智能系统。大模型主要指参数规模很大的深度学习模型。LLMLarge Language Model是其中的一个重要分支专门指大规模语言模型核心能力是理解和生成自然语言。通俗理解LLM 是大模型在语言领域的具体形态而生成式人工智能包含了语言、图像、音视频等多个模态。你和 ChatGPT 这类产品对话时背后通常就是一个经过指令微调和对齐的 LLM。2.2 Token 与上下文窗口Token 是模型处理文本的基本单位可以粗略理解成“比单词粒度更小的片段”。中文场景下一个汉字可能对应一个或多个 Token具体要看分词方式。上下文窗口是模型一次能“看到”的最长 Token 数。它决定了你能给模型传入多少历史对话、背景资料和示例。这里有个新手经常忽略的点上下文窗口不是越大越好。窗口越大单次请求的延迟、成本和出错概率都可能上升。很多实际项目不是把整本手册塞进 Prompt而是先检索出最相关的几段资料再交给模型回答。2.3 第一次调用环境变量和最小请求下面这个示例是大模型应用开发最常见的第一步。我用一个统一的 OpenAI 兼容接口风格来写便于你理解通用调用逻辑如果你使用的是国内大模型服务商或本地 Ollama把 base_url、api_key、model 三个值换成你自己的配置即可。# 文件路径demo/01_first_call.py import os import json from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) def ask_llm(user_content: str, system_content: str 你是一个乐于助人的助手。) - str: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: system, content: system_content}, {role: user, content: user_content}, ], temperature0.3, ) return resp.choices[0].message.content if __name__ __main__: result ask_llm(用一句话解释什么是 LLM。) print(result)运行前先设置环境变量export LLM_BASE_URLhttps://api.example.com/v1 export LLM_API_KEY你的密钥 export LLM_MODEL你的模型ID python demo/01_first_call.py注意不要把你的密钥硬编码到代码仓库里。一个常见的稳妥做法是使用 .env 文件并把 .env 加进 .gitignore。2.4 第一个易错点这段代码里最容易出错的地方不是 API 调用本身而是消息结构。Chat 模型的 messages 是一个列表里面通常有 system、user、assistant 三种角色。system 用来描述整体行为user 是用户提问assistant 是模型回答。如果你把 system 内容错放到 user 里模型也能回答但角色约束会出现偏差。3. 第一道坎提示工程不是会聊天吴恩达的《ChatGPT Prompt Engineering for Developers》课程虽然没有被官方长期置顶宣传但它的影响力非常大。很多人是从这门课第一次知道原来同一个模型用不同的 Prompt效果差距能大到像换了一个模型。3.1 Prompt 的本质是“任务说明”很多人以为 Prompt 就是“给模型问问题”这低估了它。Prompt 本质上是你在和模型沟通任务目标、输入格式、输出约束、质量标准。举个例子。你要让模型从一段会议记录里抽取“下周三前必须完成的任务”如果只是写“帮我提取任务”模型很可能给你一段散文式输出。如果你明确告诉它任务字段、日期格式、输出 JSON 结构它就能稳定完成。3.2 结构化输出比“让它写得好”更优先实际业务里大模型返回的内容不是给人读的而是给程序解析的。因此让模型输出结构化 JSON比“这段文字写得通顺”重要得多。最朴素的做法是在 Prompt 里描述 JSON 格式并在代码层面对结果做二次解析和校验。更稳妥的做法是使用模型的 Function Calling / Structured Output 能力或者用 pydantic 定义输出结构。下面是一个最小示例让模型从一段 Git 提交信息中提取结构化字段# 文件路径demo/02_structured_output.py import os import json from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) PROMPT 请从下面的 Git 提交信息中提取结构化信息只输出 JSON { type: 提交类型如 feat/fix/docs/refactor, summary: 一句话简介不超过 20 字, detail: 改动说明不超过 50 字 } 提交信息 {commit_message} .strip() def extract_commit_info(commit_message: str) - dict: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: user, content: PROMPT.format(commit_messagecommit_message)}, ], temperature0.1, ) content resp.choices[0].message.content # 防止模型输出代码块例如 json ... content content.strip() if content.startswith(): content content.split(\n, 1)[1] content content.rsplit(, 1)[0] return json.loads(content) if __name__ __main__: result extract_commit_info(feat: 新增 LLM 接入模块支持流式返回) print(result)3.3 提示工程常规技巧从入门到进阶这些技巧值得逐步内化系统角色先行先用 system 消息写明任务角色、语气、格式。给少量示例Few-shot 示例往往比长段描述更有效。要求分步骤思考遇到复杂推理任务时让模型先列步骤再给结论。明确否定边界告诉它什么不该做比只告诉它该做什么更不容易踩雷。关闭随机性调试时把 temperature 调到 0 附近便于复现。提示工程的真正难点不是“技巧不够”而是“没有建立评测标准”。你改了一版 Prompt觉得效果似乎好了但怎么证明建议从第一次写 Prompt 起就记录输入、输出、失败案例形成一个小数据集。后续每次改动都用同一批用例验证才不会被随机性欺骗。4. 第二道坎把私域知识交给大模型——RAG只靠 Prompt模型只能回答训练时见过的内容。遇到企业内部文档、最新产品说明、私有数据库里的信息模型就会“一本正经地胡说八道”。解决这个问题的主流方案是 RAG。4.1 没有 RAG 时怎么做私域问答过去做一个企业内部知识库问答系统通常需要先对文档做关键词索引再用搜索引擎把相关文档捞出来最后把片段拼给模型。问题在于关键词匹配经常不够智能用户问“报销流程要几天”文档里写“付款周期为七个工作日”两者语义相近但字面差异大关键词检索容易漏检。RAG 的做法是用 Embedding 模型把文档和用户问题都转换成向量然后在向量空间中找语义最相近的内容再把这些内容作为上下文交给 LLM 回答。4.2 RAG 的核心链路一个最小 RAG 系统包含五个环节文档加载与解析文本分块向量化Embedding检索与重排注入上下文并让 LLM 回答很多初学者一上来就搭建完整系统结果跑来就跑挂了。我建议你先在 Jupyter Notebook 里用列表模拟文档库跑通“检索 生成”的链路再考虑接入向量数据库。4.3 一个极简 RAG 演示下面这个示例没有依赖外部向量数据库而是用余弦相似度做简单检索。它能帮助你理解语义检索的核心逻辑# 文件路径demo/03_mini_rag.py import os import numpy as np from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) DOCUMENTS [ 报销流程员工在系统提交申请后部门负责人审批财务复核后打款。, 付款周期供应商付款一般在验收后七个工作日内完成。, 年假规则入职满一年后每年享有 5 天年假。, 加班申请工作日加班需提前在 OA 系统提交申请。, ] def embed_text(text: str): # 这里假设服务商提供 text-embedding 类模型 resp client.embeddings.create( modelos.getenv(EMBEDDING_MODEL, your-embedding-model), inputtext, ) return resp.data[0].embedding def cosine_similarity(a, b): a np.array(a) b np.array(b) return float(a.dot(b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-10)) def search_documents(query: str, top_k: int 2): query_vec embed_text(query) scored [] for doc in DOCUMENTS: doc_vec embed_text(doc) scored.append((cosine_similarity(query_vec, doc_vec), doc)) scored.sort(reverseTrue) return [doc for _, doc in scored[:top_k]] def ask_with_rag(query: str): contexts search_documents(query) context_block \n.join([f- {doc} for doc in contexts]) prompt f请根据下面的资料回答问题。如果资料中没有答案请直接说明资料不足不要编造。 资料 {context_block} 问题{query}.strip() resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content if __name__ __main__: print(ask_with_rag(供应商付款一般要多久))运行这段代码时你需要一个可用的 Embedding 模型。如果不确定服务商支持哪个模型名先去查官方文档。执行pip install openai numpy后再看输出内容是否结合了文档信息。4.4 一个核心判断RAG 项目效果不好问题多数不在模型而在前面的数据链路。如果你把文档切得不合理或者检索回来的片段不相关那么再好的 Prompt 也救不回来。这也是为什么很多高级课程会花大量篇幅讲文档解析、分块策略和检索评估。不要一上来就调 Prompt先检查检索结果。5. 从 RAG 到 Agent大模型从问答走向任务RAG 解决的是“让模型知道更多信息”Agent 解决的是“让模型做成更多事”。二者的边界经常被混淆。5.1 Agent 到底是什么在 LLM 语境里Agent 是“大模型作为决策大脑调用外部工具完成任务”的系统。模型本身不直接执行代码、不直接查数据库而是通过 Function Calling 决定调用哪个工具再把工具返回结果融入下一步推理。举个例子。用户问“帮我查一下订单 OD20250101 的物流状态”Agent 的流程可能是大模型分析出需要调用订单查询工具。程序执行订单接口返回物流信息。大模型根据工具结果整理成自然语言回答。这个过程里模型承担的是“规划”和“串联”工作真正的数据读取由工具完成。5.2 Function Calling 的工程要点Function Calling 的学习并不复杂核心是把函数的名称、描述、参数结构告诉模型模型返回一个它希望调用的函数名和参数然后由你的代码执行。真正容易出错的地方在工程侧工具描述要足够清楚模型才可能正确选择工具。函数参数要做健壮性校验不能直接信任模型生成的参数。调用工具时要设置超时和错误处理防止工具异常阻塞整个链路。对用户敏感数据要遵循最小权限原则不能让模型越权查询无关信息。5.3 Agent 的局限性很多人把 Agent 想得太强以为部署之后就能自动完成所有任务。实际上当前基于 LLM 的 Agent 在长链路任务中仍可能出现规划偏差、工具调用死循环、上下文丢失等问题。生产环境里的 Agent 通常需要任务流程图、人工确认节点、超时熔断和日志回放。越复杂的工具调用越需要把流程设计得简单可控。6. API 还是本地模型开发环境怎么搭真正进入实操阶段你还要决定一件事模型从哪里来。现在基本是两种路线使用云厂商的模型 API或者部署开源模型到本地服务器。6.1 两种方式的对比维度云端 API本地开源模型上手速度快适合学习和业务验证慢需要处理 GPU 或量化部署成本结构按 Token 付费规模大了成本高前期硬件成本高运行成本主要看电费和运维数据合规需要确认数据出网合规性数据不出内网更容易满足敏感数据要求模型能力通常更强迭代快受开源模型版本限制运维复杂度低高判断标准很简单先看你的数据能不能出网、预算和团队运维能力是否支持自建。多数团队的首选是 API 先跑通业务遇到合规或成本瓶颈后再评估开源模型。6.2 本地模型的快速体验如果你想在本地体验开源模型Ollama 是一个常见选择。它把模型下载和调用方式封装得比较简单。# 安装后在终端执行从官方模型库拉取一个开源模型示例为 qwen2.5:7b ollama pull qwen2.5:7b # 启动交互式对话 ollama run qwen2.5:7bOllama 默认会在本地启动一个兼容接口地址通常是http://localhost:11434/v1。这意味着你可以复用前面示例里的OpenAI客户端代码只需修改base_url和api_key。client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # 本地服务默认不校验但这个字段一般也要保留 )开源模型部署容易踩的坑是版本不匹配不同模型对 Prompt 格式的敏感度不同同一个 Prompt 在封闭模型上效果好换到开源模型上可能明显变差。这也是很多本地部署项目“跑是能跑就是用不起来”的原因。因此选择本地模型前先在不同开源模型上做一轮评测不要只看榜单分数。7. 微调什么阶段才需要大多数 LLM 教程走到最后都会讲微调。这给很多初学者一个错觉想做出好应用必须微调模型。我的建议是先别急着微调。微调的定位非常明确当 Prompt、RAG、示例都调优过模型仍然无法稳定满足需求时才考虑微调。它不能凭空让模型学会新知识更适合改变模型的行为风格、输出格式和特定领域术语表达。举个例子如果你的模型总是把客户投诉回复写成学术论文腔而你希望它更口语化微调是有效的。如果你想让模型回答“公司今年 Q3 的销售数据”它训练时不可能知道这些私有事实这时候应该用 RAG而不是微调。从工程实践看LoRA 是当前最常见的微调方案。它只训练一小部分低秩参数显存占用和训练成本远低于全参微调。对于大多数应用团队LoRA 已经足够。但在做任何微调之前你要准备一份高质量的对话数据集并且提前划分训练集、验证集和测试集。没有数据就谈微调基本等于空转。微调的完整流程涉及数据清洗、指令模板、训练配置、权重合并、效果评估等环节建议放到你完整跑通 API 应用之后再学不要在入门阶段投入太多时间。8. 补充底层原理如何从应用开发者往更深处走如果你只看 LLM 应用开发的短课程很快会遇到一个瓶颈模型输出不稳定时你不知道问题是出在 Prompt、采样参数、模型能力还是数据格式。这时候就需要补充底层原理。进入原理层有一条被普遍推荐的起点路线注意力机制和 Transformer 结构预训练与自监督学习指令微调与人类反馈对齐大模型推理与上下文学习Transformer 是当前 LLM 的主流基础架构理解 attention 对理解“模型为什么能关联长距离文本”非常重要。但我不建议你一上来就啃完整数学推导更实际的做法是先看结构图和直觉解释再逐步深入公式。如果一个教程讲清楚了大模型的应用开发和工程链路让你能快速写出 API 调用、RAG 和 Agent那么即使它没有推满一黑板的公式对大多数应用开发者来说也已经创造了足够的价值。9. 一个最小可运行的 LLM 应用完整示例前面讲了很多概念下面用一个完整案例把 API 调用、Prompt 工程、工具函数整合起来。这个示例是一个简化版“任务清单生成器”用户输入一段会议记录程序调用 LLM 抽取任务并输出规范的 Markdown 列表。9.1 项目结构llm-todo-demo/ ├── .env ├── .gitignore ├── requirements.txt └── main.pyrequirements.txtopenai1.0.0 python-dotenv1.0.09.2 主程序# 文件路径llm-todo-demo/main.py import os import json from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) TODO_PROMPT 你是一名研发团队的项目助理。请从下面的会议记录中提取待办任务。 输出 JSON 数组每个任务包含 3 个字段 - owner负责人如果没有明确负责人则为 null - deadline截止时间优先转为 YYYY-MM-DD 格式没有则为 null - task任务描述不超过 30 字 会议记录 {meeting_minutes} .strip() def extract_todos(meeting_minutes: str): resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: user, content: TODO_PROMPT.format(meeting_minutesmeeting_minutes)}, ], temperature0.1, ) content resp.choices[0].message.content.strip() if content.startswith(): content content.split(\n, 1)[1] content content.rsplit(, 1)[0] data json.loads(content) return data def format_tasks(tasks): lines [## 待办任务清单, ] if not tasks: lines.append(本次会议没有提取到明确任务。) for idx, task in enumerate(tasks, 1): owner task.get(owner) or 待定 deadline task.get(deadline) or 待定 lines.append(f{idx}. [{owner}] {task[task]}截止{deadline}) return \n.join(lines) if __name__ __main__: minutes 今天会议讨论了 API 网关升级事项。后端王强负责在 10 月 20 日前完成 接口兼容方案评审。前端李雪负责更新联调文档截止日期是下周五。 测试同学张明需要在发布前补充回归测试用例时间待定。 tasks extract_todos(minutes) print(format_tasks(tasks))9.3 运行和验证cd llm-todo-demo python -m venv venv source venv/bin/activate pip install -r requirements.txt python main.py预期输出是一个 Markdown 列表。你判断成功的标准有两点程序稳定返回 JSON且能被 Python 正确解析。task 字段内容与会议记录中的待办事项一致而不是复述整段会议内容。如果输出不是 JSON 格式先检查服务商的模型是否支持指令遵循能力再把 temperature 调低并在 Prompt 中补充“不要输出解释”的说明。9.4 如何继续扩展这个示例虽然小但它已经包含了 LLM 应用的基本骨架通过 API 访问模型通过 Prompt 约束输出通过代码解析和呈现结果。你可以在此基础上做这些扩展把会议记录从文件读取把提取结果写入数据库加入人工确认环节把错误解析的内容记录到日志形成评测集10. 常见问题与排查方法无论看多少教程真正写代码时都会遇到问题。下面整理的是 LLM 应用开发新手最常见的几类问题每一条几乎都是公开课程讨论区里的高频问题。问题现象可能原因排查方式解决方案返回内容不是 JSONPrompt 约束不够强模型自由发挥打印原始返回内容检查是否出现解释性文字或代码块增加输出格式说明关闭代码块包裹降低 temperature必要时启用结构化输出提示 API Key 错误环境变量没设置或密钥包含空格打印 API Key 的前几位和后几位检查 .env 文件重新生成密钥使用 dotenv 读取不要把密钥写到代码里同一段 Prompt 两次结果不一致采样随机性导致检查 temperature 是否为 0调试阶段把 temperature 调到 0 或 0.1正式业务对随机性做设计RAG 检索结果不相关文档分块过大或过小检索 top_k 不合理把检索到的片段打印出来人工检查是否命中调整分块大小和重叠区间尝试增加重排环节优化 Embedding 模型生成长文本突然中断触发了 max_tokens 限制或输出被拦截查看返回对象里的 finish_reason调大 max_tokens拆解任务或检查内容安全策略本地模型响应非常慢模型太大推理设备性能不足或上下文太长查看 CPU/GPU 占用和日志换更小模型做量化或缩短传入 Prompt复杂任务经常漏步骤一次指令里塞入了过多子任务拆开问题分步骤让模型处理把任务拆成多个串行调用或在 Prompt 中让模型先写计划再执行遇到报错时建议按“先看原始返回再看日志最后改参数”的顺序排查。很多初学者直接改 Prompt 而不看模型实际返回会把问题搞得更难定位。11. 给不同读者的学习路线建议学习路线没有唯一标准但可以根据你的处境做裁剪。11.1 在校生时间充裕建议顺序学习吴恩达《AI For Everyone》或类似公开课建立 AI 和机器学习的基本认知。选一门 LLM 提示工程短课程动手写 API 调用。选一门 RAG 应用开发课程用 Python 实现一个文档问答。了解 Function Calling 和简单 Agent。补机器学习/深度学习基础再深入 Transformer。这个顺序的好处是前两周就能看到成果有利于保持动力。11.2 在职开发时间碎片化建议以项目驱动每学一个技术立刻接到你负责的系统里。第一个小目标是“让大模型在内部工具里完成一个真实任务”比如提交信息规范检查、需求文档摘要、遗留代码注释生成。然后再逐步扩展到 RAG 和 Agent。不要追求把课程全部刷完学完不做等于白学。11.3 算法工程师转 LLM 方向你的优势是底子厚缺的是对现代 LLM 工程链路的熟悉程度。建议压缩概念课直接研究模型调用、微调脚本、推理优化、评测框架。你的重点在于把已有算法能力迁移到 LLM 应用场景。12. 工程建议与长期实践最后说几个长期有效的工程建议。第一从第一天就记录样本。大模型应用开发几乎离不开评测。你可以准备一个 JSONL 文件保存测试输入、模型输出、标注结果。Prompt 改动后用同一批样本做回归验证避免“修好一个例子弄坏十个例子”。第二把 Prompt 当代码管理。Prompt 不是聊天内容而是应用逻辑的一部分建议纳入版本管理。每次修改要有 diff有评审有注释。这也是吴恩达课程反复强调可维护性的意义所在。第三成本意识要提前建立。Token 消耗是可量化的建议在日志里记录每次请求的输入 Token、输出 Token、模型和耗时。上线前先估算每日调用量、Token 单价和预算上限必要时加缓存和限流。第四不要忽视安全边界。大模型应用涉及用户输入时可能存在提示注入风险。不要把不可信内容直接拼进系统 Prompt对外部输入要做隔离和过滤。涉及个人数据或内部资料时遵循最小权限原则并在测试环境验证后再进入生产。第五保持持续学习但不要资料焦虑。LLM 领域更新很快今天流行的框架可能半年后就不是主流。但应用开发的基本功不会过时数据结构设计、Prompt 调试、RAG 链路、评测循环、工程可靠性。这五件事才是你真正应该投入时间的地方。课程只是入口最终能让你和大模型稳定协作的是你自己整理的那套“问题定义、方案选型、效果验证”的工程方法。把每一门课里的小练习扩展成真实系统里的一个功能你的大模型入门才算真正完成。
大模型应用开发学习顺序：从提示工程到RAG与Agent
如果你手头有十几个G的“大模型学习资料”却还是写不出一段能稳定返回 JSON 的业务代码那么大模型学习的问题通常不在资源数量而在学习顺序。这两年我常被问到类似的问题想学 LLM 大模型是不是得先把机器学习、深度学习全部补完Transformer 的 attention 公式还没看懂能不能先上手做应用吴恩达的课那么多到底应该先看哪一个我的看法是如果你走应用开发方向真正高效的学习顺序不是“从数学原理一路推到模型源码”而是“先会用再会调最后理解为什么”。吴恩达和 DeepLearning.AI 推出的 LLM 系列课程之所以能成为很多人的大模型入门首选不在于它把注意力机制讲得多么深而在于它替学习者整理出了一条从提示工程、RAG、Agent 到微调的进阶路线。这篇文章不打算帮你“鉴定哪套资源最神”而是把吴恩达 LLM 课程背后代表的 LLM 大模型学习地图拆开来看概念层、提示工程层、应用开发层、模型选择与微调层、底层原理补全层。每一层我都会给出可运行的最小示例、判断标准和常见误区方便你对照自己的进度。文中如果涉及具体课程名称和内容请以官方页面为准。我的目标是给你一份能照着练习的路线图而不是一份收藏后就吃灰的资料清单。1. 先搞清楚大模型学习缺的不是资料而是地图打开任何一个搜索工具输入“大模型学习路线”你都能找到几十篇内容相似的文章第一阶段学 Python第二阶段学机器学习第三阶段学深度学习第四阶段学 Transformer第五阶段学部署……单看每一步都没问题但合在一起很容易让人劝退。原因很简单这套路线是按“算法研究员”的成长路径设计的不是按“LLM 应用工程师”的成长路径设计的。如果你最终目标是在业务系统里接入大模型让它完成信息抽取、文档问答、代码生成、智能客服这类任务那你不一定需要先花三个月推导反向传播。你更需要先搞清楚模型怎么调用输入输出怎么设计知识库怎么接进去效果怎么评测线上怎么监控。这些能力恰恰是吴恩达课程体系最擅长教的。从公开资料看DeepLearning.AI 上的短课程覆盖了提示工程、LangChain 应用开发、RAG、微调、评估调试等方向设计思路非常明确让已经有基本编程能力的开发者快速体验到“从 API 到完整应用”的完整链路。所以我建议你把注意力从“找一套完美课程”转移到“建立自己的学习地图”上。1.1 学习路径里的三层结构我习惯把 LLM 大模型学习拆成三层层次核心任务典型问题典型岗位应用层调用模型 API处理输入输出做 Prompt 设计和效果调优怎么让模型稳定输出 JSONLLM 应用开发者工程层搭 RAG、Agent、缓存、评测、监控和运维体系知识库检索不准怎么排查AI 应用工程师原理层理解 Transformer、预训练、微调、对齐原理attention 为什么有效微调和预训练有什么区别算法工程师、研究工程师大多数人不需要把三层全部学完才能上手。正确做法是先进入第一层和第二层做应用遇到问题后再向第三层追根因。1.2 为什么吴恩达课程适合作为参照系吴恩达课程真正降低的是“大模型应用开发的起步成本”。过去要做一个大模型应用你需要自己搞定模型部署、GPU、推理框架、微调平台。现在大部分模型都有 API命令行几行代码就能调用。变化发生在工程链路上原来最难的“训练模型”已经不是瓶颈最难的是“怎么把模型接进业务”。在这个背景下课程的价值不再是教你“大模型是什么”而是帮你快速建立一套应用开发的思维框架。2. 入门先解决三件事概念、Token、调用方式不管你看的是哪套 LLM 教程入门阶段的核心内容基本一致。搞清楚下面三件事你就越过了第一道门槛。2.1 LLM、大模型、生成式人工智能的区别很多初学者会把这三个概念混用实际上它们粒度不同。生成式人工智能是一个更大的范畴指能生成文本、图片、音频、视频等内容的人工智能系统。大模型主要指参数规模很大的深度学习模型。LLMLarge Language Model是其中的一个重要分支专门指大规模语言模型核心能力是理解和生成自然语言。通俗理解LLM 是大模型在语言领域的具体形态而生成式人工智能包含了语言、图像、音视频等多个模态。你和 ChatGPT 这类产品对话时背后通常就是一个经过指令微调和对齐的 LLM。2.2 Token 与上下文窗口Token 是模型处理文本的基本单位可以粗略理解成“比单词粒度更小的片段”。中文场景下一个汉字可能对应一个或多个 Token具体要看分词方式。上下文窗口是模型一次能“看到”的最长 Token 数。它决定了你能给模型传入多少历史对话、背景资料和示例。这里有个新手经常忽略的点上下文窗口不是越大越好。窗口越大单次请求的延迟、成本和出错概率都可能上升。很多实际项目不是把整本手册塞进 Prompt而是先检索出最相关的几段资料再交给模型回答。2.3 第一次调用环境变量和最小请求下面这个示例是大模型应用开发最常见的第一步。我用一个统一的 OpenAI 兼容接口风格来写便于你理解通用调用逻辑如果你使用的是国内大模型服务商或本地 Ollama把 base_url、api_key、model 三个值换成你自己的配置即可。# 文件路径demo/01_first_call.py import os import json from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) def ask_llm(user_content: str, system_content: str 你是一个乐于助人的助手。) - str: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: system, content: system_content}, {role: user, content: user_content}, ], temperature0.3, ) return resp.choices[0].message.content if __name__ __main__: result ask_llm(用一句话解释什么是 LLM。) print(result)运行前先设置环境变量export LLM_BASE_URLhttps://api.example.com/v1 export LLM_API_KEY你的密钥 export LLM_MODEL你的模型ID python demo/01_first_call.py注意不要把你的密钥硬编码到代码仓库里。一个常见的稳妥做法是使用 .env 文件并把 .env 加进 .gitignore。2.4 第一个易错点这段代码里最容易出错的地方不是 API 调用本身而是消息结构。Chat 模型的 messages 是一个列表里面通常有 system、user、assistant 三种角色。system 用来描述整体行为user 是用户提问assistant 是模型回答。如果你把 system 内容错放到 user 里模型也能回答但角色约束会出现偏差。3. 第一道坎提示工程不是会聊天吴恩达的《ChatGPT Prompt Engineering for Developers》课程虽然没有被官方长期置顶宣传但它的影响力非常大。很多人是从这门课第一次知道原来同一个模型用不同的 Prompt效果差距能大到像换了一个模型。3.1 Prompt 的本质是“任务说明”很多人以为 Prompt 就是“给模型问问题”这低估了它。Prompt 本质上是你在和模型沟通任务目标、输入格式、输出约束、质量标准。举个例子。你要让模型从一段会议记录里抽取“下周三前必须完成的任务”如果只是写“帮我提取任务”模型很可能给你一段散文式输出。如果你明确告诉它任务字段、日期格式、输出 JSON 结构它就能稳定完成。3.2 结构化输出比“让它写得好”更优先实际业务里大模型返回的内容不是给人读的而是给程序解析的。因此让模型输出结构化 JSON比“这段文字写得通顺”重要得多。最朴素的做法是在 Prompt 里描述 JSON 格式并在代码层面对结果做二次解析和校验。更稳妥的做法是使用模型的 Function Calling / Structured Output 能力或者用 pydantic 定义输出结构。下面是一个最小示例让模型从一段 Git 提交信息中提取结构化字段# 文件路径demo/02_structured_output.py import os import json from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) PROMPT 请从下面的 Git 提交信息中提取结构化信息只输出 JSON { type: 提交类型如 feat/fix/docs/refactor, summary: 一句话简介不超过 20 字, detail: 改动说明不超过 50 字 } 提交信息 {commit_message} .strip() def extract_commit_info(commit_message: str) - dict: resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: user, content: PROMPT.format(commit_messagecommit_message)}, ], temperature0.1, ) content resp.choices[0].message.content # 防止模型输出代码块例如 json ... content content.strip() if content.startswith(): content content.split(\n, 1)[1] content content.rsplit(, 1)[0] return json.loads(content) if __name__ __main__: result extract_commit_info(feat: 新增 LLM 接入模块支持流式返回) print(result)3.3 提示工程常规技巧从入门到进阶这些技巧值得逐步内化系统角色先行先用 system 消息写明任务角色、语气、格式。给少量示例Few-shot 示例往往比长段描述更有效。要求分步骤思考遇到复杂推理任务时让模型先列步骤再给结论。明确否定边界告诉它什么不该做比只告诉它该做什么更不容易踩雷。关闭随机性调试时把 temperature 调到 0 附近便于复现。提示工程的真正难点不是“技巧不够”而是“没有建立评测标准”。你改了一版 Prompt觉得效果似乎好了但怎么证明建议从第一次写 Prompt 起就记录输入、输出、失败案例形成一个小数据集。后续每次改动都用同一批用例验证才不会被随机性欺骗。4. 第二道坎把私域知识交给大模型——RAG只靠 Prompt模型只能回答训练时见过的内容。遇到企业内部文档、最新产品说明、私有数据库里的信息模型就会“一本正经地胡说八道”。解决这个问题的主流方案是 RAG。4.1 没有 RAG 时怎么做私域问答过去做一个企业内部知识库问答系统通常需要先对文档做关键词索引再用搜索引擎把相关文档捞出来最后把片段拼给模型。问题在于关键词匹配经常不够智能用户问“报销流程要几天”文档里写“付款周期为七个工作日”两者语义相近但字面差异大关键词检索容易漏检。RAG 的做法是用 Embedding 模型把文档和用户问题都转换成向量然后在向量空间中找语义最相近的内容再把这些内容作为上下文交给 LLM 回答。4.2 RAG 的核心链路一个最小 RAG 系统包含五个环节文档加载与解析文本分块向量化Embedding检索与重排注入上下文并让 LLM 回答很多初学者一上来就搭建完整系统结果跑来就跑挂了。我建议你先在 Jupyter Notebook 里用列表模拟文档库跑通“检索 生成”的链路再考虑接入向量数据库。4.3 一个极简 RAG 演示下面这个示例没有依赖外部向量数据库而是用余弦相似度做简单检索。它能帮助你理解语义检索的核心逻辑# 文件路径demo/03_mini_rag.py import os import numpy as np from openai import OpenAI client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) DOCUMENTS [ 报销流程员工在系统提交申请后部门负责人审批财务复核后打款。, 付款周期供应商付款一般在验收后七个工作日内完成。, 年假规则入职满一年后每年享有 5 天年假。, 加班申请工作日加班需提前在 OA 系统提交申请。, ] def embed_text(text: str): # 这里假设服务商提供 text-embedding 类模型 resp client.embeddings.create( modelos.getenv(EMBEDDING_MODEL, your-embedding-model), inputtext, ) return resp.data[0].embedding def cosine_similarity(a, b): a np.array(a) b np.array(b) return float(a.dot(b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-10)) def search_documents(query: str, top_k: int 2): query_vec embed_text(query) scored [] for doc in DOCUMENTS: doc_vec embed_text(doc) scored.append((cosine_similarity(query_vec, doc_vec), doc)) scored.sort(reverseTrue) return [doc for _, doc in scored[:top_k]] def ask_with_rag(query: str): contexts search_documents(query) context_block \n.join([f- {doc} for doc in contexts]) prompt f请根据下面的资料回答问题。如果资料中没有答案请直接说明资料不足不要编造。 资料 {context_block} 问题{query}.strip() resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content if __name__ __main__: print(ask_with_rag(供应商付款一般要多久))运行这段代码时你需要一个可用的 Embedding 模型。如果不确定服务商支持哪个模型名先去查官方文档。执行pip install openai numpy后再看输出内容是否结合了文档信息。4.4 一个核心判断RAG 项目效果不好问题多数不在模型而在前面的数据链路。如果你把文档切得不合理或者检索回来的片段不相关那么再好的 Prompt 也救不回来。这也是为什么很多高级课程会花大量篇幅讲文档解析、分块策略和检索评估。不要一上来就调 Prompt先检查检索结果。5. 从 RAG 到 Agent大模型从问答走向任务RAG 解决的是“让模型知道更多信息”Agent 解决的是“让模型做成更多事”。二者的边界经常被混淆。5.1 Agent 到底是什么在 LLM 语境里Agent 是“大模型作为决策大脑调用外部工具完成任务”的系统。模型本身不直接执行代码、不直接查数据库而是通过 Function Calling 决定调用哪个工具再把工具返回结果融入下一步推理。举个例子。用户问“帮我查一下订单 OD20250101 的物流状态”Agent 的流程可能是大模型分析出需要调用订单查询工具。程序执行订单接口返回物流信息。大模型根据工具结果整理成自然语言回答。这个过程里模型承担的是“规划”和“串联”工作真正的数据读取由工具完成。5.2 Function Calling 的工程要点Function Calling 的学习并不复杂核心是把函数的名称、描述、参数结构告诉模型模型返回一个它希望调用的函数名和参数然后由你的代码执行。真正容易出错的地方在工程侧工具描述要足够清楚模型才可能正确选择工具。函数参数要做健壮性校验不能直接信任模型生成的参数。调用工具时要设置超时和错误处理防止工具异常阻塞整个链路。对用户敏感数据要遵循最小权限原则不能让模型越权查询无关信息。5.3 Agent 的局限性很多人把 Agent 想得太强以为部署之后就能自动完成所有任务。实际上当前基于 LLM 的 Agent 在长链路任务中仍可能出现规划偏差、工具调用死循环、上下文丢失等问题。生产环境里的 Agent 通常需要任务流程图、人工确认节点、超时熔断和日志回放。越复杂的工具调用越需要把流程设计得简单可控。6. API 还是本地模型开发环境怎么搭真正进入实操阶段你还要决定一件事模型从哪里来。现在基本是两种路线使用云厂商的模型 API或者部署开源模型到本地服务器。6.1 两种方式的对比维度云端 API本地开源模型上手速度快适合学习和业务验证慢需要处理 GPU 或量化部署成本结构按 Token 付费规模大了成本高前期硬件成本高运行成本主要看电费和运维数据合规需要确认数据出网合规性数据不出内网更容易满足敏感数据要求模型能力通常更强迭代快受开源模型版本限制运维复杂度低高判断标准很简单先看你的数据能不能出网、预算和团队运维能力是否支持自建。多数团队的首选是 API 先跑通业务遇到合规或成本瓶颈后再评估开源模型。6.2 本地模型的快速体验如果你想在本地体验开源模型Ollama 是一个常见选择。它把模型下载和调用方式封装得比较简单。# 安装后在终端执行从官方模型库拉取一个开源模型示例为 qwen2.5:7b ollama pull qwen2.5:7b # 启动交互式对话 ollama run qwen2.5:7bOllama 默认会在本地启动一个兼容接口地址通常是http://localhost:11434/v1。这意味着你可以复用前面示例里的OpenAI客户端代码只需修改base_url和api_key。client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, # 本地服务默认不校验但这个字段一般也要保留 )开源模型部署容易踩的坑是版本不匹配不同模型对 Prompt 格式的敏感度不同同一个 Prompt 在封闭模型上效果好换到开源模型上可能明显变差。这也是很多本地部署项目“跑是能跑就是用不起来”的原因。因此选择本地模型前先在不同开源模型上做一轮评测不要只看榜单分数。7. 微调什么阶段才需要大多数 LLM 教程走到最后都会讲微调。这给很多初学者一个错觉想做出好应用必须微调模型。我的建议是先别急着微调。微调的定位非常明确当 Prompt、RAG、示例都调优过模型仍然无法稳定满足需求时才考虑微调。它不能凭空让模型学会新知识更适合改变模型的行为风格、输出格式和特定领域术语表达。举个例子如果你的模型总是把客户投诉回复写成学术论文腔而你希望它更口语化微调是有效的。如果你想让模型回答“公司今年 Q3 的销售数据”它训练时不可能知道这些私有事实这时候应该用 RAG而不是微调。从工程实践看LoRA 是当前最常见的微调方案。它只训练一小部分低秩参数显存占用和训练成本远低于全参微调。对于大多数应用团队LoRA 已经足够。但在做任何微调之前你要准备一份高质量的对话数据集并且提前划分训练集、验证集和测试集。没有数据就谈微调基本等于空转。微调的完整流程涉及数据清洗、指令模板、训练配置、权重合并、效果评估等环节建议放到你完整跑通 API 应用之后再学不要在入门阶段投入太多时间。8. 补充底层原理如何从应用开发者往更深处走如果你只看 LLM 应用开发的短课程很快会遇到一个瓶颈模型输出不稳定时你不知道问题是出在 Prompt、采样参数、模型能力还是数据格式。这时候就需要补充底层原理。进入原理层有一条被普遍推荐的起点路线注意力机制和 Transformer 结构预训练与自监督学习指令微调与人类反馈对齐大模型推理与上下文学习Transformer 是当前 LLM 的主流基础架构理解 attention 对理解“模型为什么能关联长距离文本”非常重要。但我不建议你一上来就啃完整数学推导更实际的做法是先看结构图和直觉解释再逐步深入公式。如果一个教程讲清楚了大模型的应用开发和工程链路让你能快速写出 API 调用、RAG 和 Agent那么即使它没有推满一黑板的公式对大多数应用开发者来说也已经创造了足够的价值。9. 一个最小可运行的 LLM 应用完整示例前面讲了很多概念下面用一个完整案例把 API 调用、Prompt 工程、工具函数整合起来。这个示例是一个简化版“任务清单生成器”用户输入一段会议记录程序调用 LLM 抽取任务并输出规范的 Markdown 列表。9.1 项目结构llm-todo-demo/ ├── .env ├── .gitignore ├── requirements.txt └── main.pyrequirements.txtopenai1.0.0 python-dotenv1.0.09.2 主程序# 文件路径llm-todo-demo/main.py import os import json from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( base_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.getenv(LLM_API_KEY, your-api-key), ) TODO_PROMPT 你是一名研发团队的项目助理。请从下面的会议记录中提取待办任务。 输出 JSON 数组每个任务包含 3 个字段 - owner负责人如果没有明确负责人则为 null - deadline截止时间优先转为 YYYY-MM-DD 格式没有则为 null - task任务描述不超过 30 字 会议记录 {meeting_minutes} .strip() def extract_todos(meeting_minutes: str): resp client.chat.completions.create( modelos.getenv(LLM_MODEL, your-model-id), messages[ {role: user, content: TODO_PROMPT.format(meeting_minutesmeeting_minutes)}, ], temperature0.1, ) content resp.choices[0].message.content.strip() if content.startswith(): content content.split(\n, 1)[1] content content.rsplit(, 1)[0] data json.loads(content) return data def format_tasks(tasks): lines [## 待办任务清单, ] if not tasks: lines.append(本次会议没有提取到明确任务。) for idx, task in enumerate(tasks, 1): owner task.get(owner) or 待定 deadline task.get(deadline) or 待定 lines.append(f{idx}. [{owner}] {task[task]}截止{deadline}) return \n.join(lines) if __name__ __main__: minutes 今天会议讨论了 API 网关升级事项。后端王强负责在 10 月 20 日前完成 接口兼容方案评审。前端李雪负责更新联调文档截止日期是下周五。 测试同学张明需要在发布前补充回归测试用例时间待定。 tasks extract_todos(minutes) print(format_tasks(tasks))9.3 运行和验证cd llm-todo-demo python -m venv venv source venv/bin/activate pip install -r requirements.txt python main.py预期输出是一个 Markdown 列表。你判断成功的标准有两点程序稳定返回 JSON且能被 Python 正确解析。task 字段内容与会议记录中的待办事项一致而不是复述整段会议内容。如果输出不是 JSON 格式先检查服务商的模型是否支持指令遵循能力再把 temperature 调低并在 Prompt 中补充“不要输出解释”的说明。9.4 如何继续扩展这个示例虽然小但它已经包含了 LLM 应用的基本骨架通过 API 访问模型通过 Prompt 约束输出通过代码解析和呈现结果。你可以在此基础上做这些扩展把会议记录从文件读取把提取结果写入数据库加入人工确认环节把错误解析的内容记录到日志形成评测集10. 常见问题与排查方法无论看多少教程真正写代码时都会遇到问题。下面整理的是 LLM 应用开发新手最常见的几类问题每一条几乎都是公开课程讨论区里的高频问题。问题现象可能原因排查方式解决方案返回内容不是 JSONPrompt 约束不够强模型自由发挥打印原始返回内容检查是否出现解释性文字或代码块增加输出格式说明关闭代码块包裹降低 temperature必要时启用结构化输出提示 API Key 错误环境变量没设置或密钥包含空格打印 API Key 的前几位和后几位检查 .env 文件重新生成密钥使用 dotenv 读取不要把密钥写到代码里同一段 Prompt 两次结果不一致采样随机性导致检查 temperature 是否为 0调试阶段把 temperature 调到 0 或 0.1正式业务对随机性做设计RAG 检索结果不相关文档分块过大或过小检索 top_k 不合理把检索到的片段打印出来人工检查是否命中调整分块大小和重叠区间尝试增加重排环节优化 Embedding 模型生成长文本突然中断触发了 max_tokens 限制或输出被拦截查看返回对象里的 finish_reason调大 max_tokens拆解任务或检查内容安全策略本地模型响应非常慢模型太大推理设备性能不足或上下文太长查看 CPU/GPU 占用和日志换更小模型做量化或缩短传入 Prompt复杂任务经常漏步骤一次指令里塞入了过多子任务拆开问题分步骤让模型处理把任务拆成多个串行调用或在 Prompt 中让模型先写计划再执行遇到报错时建议按“先看原始返回再看日志最后改参数”的顺序排查。很多初学者直接改 Prompt 而不看模型实际返回会把问题搞得更难定位。11. 给不同读者的学习路线建议学习路线没有唯一标准但可以根据你的处境做裁剪。11.1 在校生时间充裕建议顺序学习吴恩达《AI For Everyone》或类似公开课建立 AI 和机器学习的基本认知。选一门 LLM 提示工程短课程动手写 API 调用。选一门 RAG 应用开发课程用 Python 实现一个文档问答。了解 Function Calling 和简单 Agent。补机器学习/深度学习基础再深入 Transformer。这个顺序的好处是前两周就能看到成果有利于保持动力。11.2 在职开发时间碎片化建议以项目驱动每学一个技术立刻接到你负责的系统里。第一个小目标是“让大模型在内部工具里完成一个真实任务”比如提交信息规范检查、需求文档摘要、遗留代码注释生成。然后再逐步扩展到 RAG 和 Agent。不要追求把课程全部刷完学完不做等于白学。11.3 算法工程师转 LLM 方向你的优势是底子厚缺的是对现代 LLM 工程链路的熟悉程度。建议压缩概念课直接研究模型调用、微调脚本、推理优化、评测框架。你的重点在于把已有算法能力迁移到 LLM 应用场景。12. 工程建议与长期实践最后说几个长期有效的工程建议。第一从第一天就记录样本。大模型应用开发几乎离不开评测。你可以准备一个 JSONL 文件保存测试输入、模型输出、标注结果。Prompt 改动后用同一批样本做回归验证避免“修好一个例子弄坏十个例子”。第二把 Prompt 当代码管理。Prompt 不是聊天内容而是应用逻辑的一部分建议纳入版本管理。每次修改要有 diff有评审有注释。这也是吴恩达课程反复强调可维护性的意义所在。第三成本意识要提前建立。Token 消耗是可量化的建议在日志里记录每次请求的输入 Token、输出 Token、模型和耗时。上线前先估算每日调用量、Token 单价和预算上限必要时加缓存和限流。第四不要忽视安全边界。大模型应用涉及用户输入时可能存在提示注入风险。不要把不可信内容直接拼进系统 Prompt对外部输入要做隔离和过滤。涉及个人数据或内部资料时遵循最小权限原则并在测试环境验证后再进入生产。第五保持持续学习但不要资料焦虑。LLM 领域更新很快今天流行的框架可能半年后就不是主流。但应用开发的基本功不会过时数据结构设计、Prompt 调试、RAG 链路、评测循环、工程可靠性。这五件事才是你真正应该投入时间的地方。课程只是入口最终能让你和大模型稳定协作的是你自己整理的那套“问题定义、方案选型、效果验证”的工程方法。把每一门课里的小练习扩展成真实系统里的一个功能你的大模型入门才算真正完成。
