想转 AI 应用，到底应该先学 Prompt、RAG，还是 Agent？
我的答案是：先别急着学框架，先把大模型调用这件事弄明白。
因为不管后面使用 RAG、Agent 还是 MCP，最终都绕不开一次又一次的模型调用。
●●●问题不一定出在 Prompt
回答不对，继续改 Prompt。还是不对，换一个模型。再不行，就换一个框架。
但真正的问题，可能根本不在 Prompt。
为了让这 12 个问题不变成一份术语清单，全文只使用一个例子：
🧩 贯穿全文的案例
假设我们正在开发一个**“AI 需求分析助手”**。
用户输入一段原始需求，AI 需要自动整理出：功能目标、涉及角色、前置条件、业务规则、待确认问题和验收标准。
看起来只是调用一次模型接口，但真正做下去，很快就会遇到下面这 12 个问题。
Token 到底是什么？
答标准面试回复
Token 是大模型处理内容的基本计量单元，由模型的分词器将文本拆分得到，但它不等同于字符或单词。不同模型的分词方式可能不同，所以同一段内容的 Token 数量也可能不同。Token 会直接影响上下文容量、最大输出长度和模型调用成本。
先看一个最常见的误解：
❌ 常见误解
Token 就是字数。
不完全对。
模型不会直接按照“一个汉字”或“一个英文单词”处理文本，而是先通过分词器，把内容拆成一组可以识别的单元。
●●●一段普通输入
AI应用开发正在改变程序员的工作方式
这句话会被拆成多个 Token。但具体怎样拆、拆出多少个，取决于模型使用的分词器。
●●●不能这样简单换算
一个汉字 ≠ 固定一个 Token一个英文单词 ≠ 固定一个 Token
同一份需求文档，换一个模型，计算出来的 Token 数量也可能不同。
📌 Token 为什么重要？
它至少影响三件事：内容能不能放进上下文、模型还能输出多长、这次调用需要多少钱。
对于需求分析助手来说，用户只输入几十个字时，Token 通常不是问题。
但如果用户一次上传几十页需求文档，再附带项目规则、接口说明和历史对话，Token 数量就会快速增加。
**记住一句话就够了：**Token 不是字数，但会直接影响上下文、输出长度和费用。
上下文窗口到底包含什么？
答标准面试回复
上下文窗口是模型在一次任务中能够处理的信息范围，通常包括系统指令、用户输入、历史消息、检索内容、工具信息和模型输出。上下文越大不代表效果一定越好，内容过多会增加成本与延迟，也可能让重要信息受到无关内容干扰。
可以把上下文窗口理解成模型处理当前任务时能够看到的“工作台”。
🗂️ 一次请求可能包含
系统规则、用户输入的需求、前面的对话记录、项目开发规范、接口说明、工具定义、工具返回结果，以及模型即将生成的内容。
很多人看到模型支持很大的上下文，第一反应是：
🤔 看似省事的做法
那我把所有资料都丢进去不就行了？
实际开发中，这通常不是一个好方案。
上下文很大，只代表“能放进去”，不代表模型能同等准确地使用所有内容。资料过多时，真正重要的信息可能被无关内容淹没，上下文越长，费用和响应时间也通常越高。
📚 官方文档提醒
更大的上下文并不自动等于更好的效果。随着上下文增长，模型对信息的准确利用可能下降。 Anthropic · Context Windows
回到需求分析助手。假设用户只想分析一个“订单批量导出”需求，真正有用的上下文可能只有：
●●●当前任务真正需要的信息
当前需求订单模块规则权限说明导出规范相关接口信息
如果同时把登录模块、地图模块、消息中心和几个月前的历史对话也塞进去，只会增加干扰。
✅ 上下文管理的核心
真正要解决的不是“怎样放入更多内容”，而是“这次任务真正需要哪些内容”。
常见处理方式包括：只保留相关历史、把较早对话压缩成摘要、用 RAG 检索相关资料、把大任务拆成多个阶段，并在接近上限前压缩或开启新会话。
上下文管理的本质，是在有限空间里保留最有价值的信息。
Temperature 是控制模型聪明程度的吗？
答标准面试回复
不是。Temperature 通常用于控制模型输出的随机性和多样性，不代表模型能力或知识水平。较低的值通常让结果更集中，较高的值让结果更多样，但不同模型对 Temperature 的支持方式不同，不能把同一套参数直接用于所有模型。
●●●可以这样粗略理解
Temperature 较低→ 输出更集中、更稳定Temperature 较高→ 输出更多样、更有变化
如果让需求分析助手提取功能名称、用户角色、业务规则、待确认问题和验收标准，我们更希望它稳定，而不是每次都自由发挥。
但如果任务是“为这篇文章生成 10 个不同风格的标题”，就可以允许输出有更多变化。
⚠️ 两个容易踩的坑
第一，Temperature 设得很低，也不能保证每次输出绝对一致。
第二，不是所有模型都支持自由调整 Temperature。部分推理模型会限制传统采样参数，甚至在收到非默认参数时直接返回错误。
所以不能把某个模型的参数配置复制给所有模型。
System Prompt、User Message 和 Assistant Message 有什么区别？
答标准面试回复
System Prompt 用于定义模型的角色、任务和长期约束；User Message 是用户当前提出的问题或提供的数据；Assistant Message 表示模型之前的输出，常用于维持多轮对话。把不同消息分层管理，可以让指令边界更清晰，也便于维护和排查问题。
需求分析助手至少有两类内容。
🧭 系统制定的规则 你是一名需求分析助手。只能基于用户提供的信息进行分析。信息不足时列出待确认问题，不得自行补充业务规则。
📝 用户真正输入的需求 订单列表新增批量导出功能，只有管理员可以操作，导出内容包含订单编号、状态和创建时间。
这两部分不应该混在一起。
SYSTEM PROMPT
用于定义应用中的总体行为：模型扮演什么角色、完成什么任务、必须遵守哪些规则、哪些内容不能自行推测，以及结果采用什么形式。部分平台还提供 Developer Message 等指令层，具体优先级以对应接口为准。
USER MESSAGE
表示用户当前提出的问题或提供的数据。
ASSISTANT MESSAGE
表示模型之前已经输出的内容。多轮对话中，它帮助模型理解前面已经讨论过什么。
如果用户继续补充“最多导出一万条，格式为 Excel”，模型需要看到前面的需求和自己提出的待确认问题，才能知道这一万条限制对应的是什么。
❓ 为什么不要全部拼成一个大字符串？
系统规则和用户内容边界会变得模糊，多轮消息难以管理，出现问题时难以定位，更换模型接口时也不方便适配。
AI 应用开发并不是把一整段文字交给模型。还要明确：谁负责制定规则，谁负责提出任务，哪些内容属于历史。
为什么同一个问题，模型每次回答可能不一样？
答标准面试回复
因为大模型是基于上下文和概率分布生成内容，而不是执行一套结果完全固定的业务规则。即使输入相同，采样过程、上下文、模型版本或推理路径也可能带来差异。因此业务系统不能依赖自然语言完全一致，而应通过结构化输出、Schema 校验和业务规则保证结果可用。
●●●传统接口与大模型接口
传统接口：相同参数 + 相同数据 ≈ 相同结果大模型接口：相同输入 ≈ 方向相近，但内容不一定完全一致
大模型会根据上下文计算接下来各种输出的可能性，再生成最终内容。
所以即使用户输入完全相同，需求分析助手两次生成的措辞、顺序，甚至部分待确认问题，都可能不同。
🔍 差异可能来自
模型生成本身的概率性、调用参数、历史上下文、检索资料、模型版本以及不同的推理路径。
这对程序有什么影响？假设后端需要模型返回：
●●●程序期待的数据结构
{ "featureName": "订单批量导出", "needReview": true, "riskLevel": "medium"}
如果只是告诉模型“请返回 JSON”，它偶尔可能增加说明文字，或者把布尔值、枚举值换成自然语言。给人看没有问题，交给程序解析就可能直接报错。
🧱 程序侧必须补上的约束
结构化输出、JSON Schema、枚举值约束、必填字段校验、解析失败处理，以及必要时的修复或重试。
📚 官方文档核对
结构化输出的重点，是让模型结果遵循指定 JSON Schema，而不只是生成一段“看起来像 JSON”的文本。 OpenAI · Structured Outputs
**这里真正需要建立的意识是：**模型的文字可以有变化，交给程序的数据结构必须稳定。
模型为什么会产生幻觉？
答标准面试回复
幻觉是模型生成了看起来合理、实际上错误或缺少依据的内容。它通常来自信息不足、知识过期、检索错误、上下文冲突或模型的概率生成机制。可以通过可信数据、RAG、引用、拒答、规则校验和人工确认降低风险，但不能保证完全消除。
假设需求里只写了“订单列表新增批量导出”，需求分析助手却补充了一条“单次最多导出 5000 条”。
⚠️ 这就是幻觉
这条规则看起来非常合理，但原始需求里根本没有。模型生成了一个符合常见业务经验，却没有真实依据的内容。
因为模型的目标是根据上下文生成合理内容，而不是自动进入公司的系统核对规则。
🔍 常见原因
用户提供的信息不足、模型不知道真实业务规则、知识已经过期、RAG 检索错误、上下文互相冲突、Prompt 强迫模型给出完整答案，或者模型把其他系统的常见规则套了进来。
需求分析助手遇到没有依据的信息，不应该自行补齐，而应该输出：
●●●更可靠的处理方式
待确认问题：1. 单次最大导出数量是多少？2. 超过上限后是禁止导出，还是改为异步任务？3. 导出文件保存多长时间？
🛡️ 降低幻觉的方法
提供可信业务资料、使用 RAG、要求标注依据、允许拒答或追问、校验关键字段、实时数据通过真实接口获取，并对高风险结果增加人工确认。
但这些方法只能降低幻觉，不能保证模型以后永远不犯错。
📌 必须记住
模型语气坚定，不代表答案有依据。
流式输出到底是怎么实现的？
答标准面试回复
流式输出是服务端在模型生成过程中，通过 SSE、WebSocket 或异步事件流持续返回增量内容，前端收到一段就展示一段。它主要改善首字等待体验，不一定缩短整体生成时间。实现时还要处理完成事件、中途错误、断线、取消和最终状态。
●●●非流式返回
用户提交需求 ↓等待模型生成完整结果 ↓一次性显示全部内容
假设模型需要十秒生成结果，用户就要面对十秒钟的空白页面。
●●●流式返回
用户提交需求 ↓收到第一个内容片段 ↓持续收到后续片段 ↓收到完成事件
前端收到一段，就展示一段。常见实现方式包括 SSE、WebSocket，以及模型 SDK 提供的异步事件流。
⏱️ 它真正改善的是什么？
流式输出主要缩短的是用户看到第一个内容的等待时间。更快看到第一个字，不等于整个任务更快完成。
真正开发时，不能只处理文字。流式接口还可能返回开始事件、文本增量、工具调用、完成事件、Token 统计、错误、心跳，以及后续新增的未知事件。
而且流式请求可能已经返回了一半内容，连接才突然中断。
🧯 前端必须知道
当前结果是否完整、用户能不能重新生成、旧内容应该保留还是清空，以及重复请求会不会产生副作用。
📚 官方文档核对
OpenAI · Streaming Responses Anthropic · Streaming Messages
流式输出不只是一个打字动画。它本质上是一套需要管理状态的长连接交互。
为什么多轮对话会越来越慢、越来越贵？
答标准面试回复
因为模型要理解当前问题，通常需要同时处理必要的历史消息。对话越长，输入 Token 越多，调用成本、延迟和上下文压力也会增加。实际项目应通过历史裁剪、摘要、RAG 和分层记忆，只保留当前任务真正需要的信息。
假设用户第一次提交“订单列表新增批量导出功能”，需求分析助手提出三个待确认问题。用户接着补充“最多导出一万条，格式为 Excel，超过时提示缩小筛选范围”。
为了理解这句话，模型必须知道前面讨论的是哪个功能、提出过哪些问题。最直接的做法，是每次调用都携带前面的消息：
●●●历史消息不断累积
第一次：系统规则 + 问题1第二次：系统规则 + 问题1 + 回答1 + 问题2第三次：系统规则 + 问题1 + 回答1 + 问题2 + 回答2 + 问题3
📈 对话越长，代价越明显
费用增加、首次响应变慢、接近上下文上限、无关历史越来越多，早期重要信息也可能被忽略。
❌ 又一个常见误解
服务端保存会话，解决的是状态管理问题，不代表历史不占 Token，也不代表上下文免费。Prompt Caching 可能降低部分重复内容的费用或延迟，但缓存有自己的适用规则。
实际项目中，不是无限保存聊天记录，而是对信息分类。
必须保留 原始需求、已确认规则、待确认问题。
可以压缩 较早的分析过程和重复讨论。
需要重新查询 实时业务数据和最新项目规范。
不应继续携带 已失效内容和无关对话。
真正可靠的记忆，不是把聊天记录越存越多，而是应用自己决定什么应该保留、什么可以摘要、什么必须重新获取。
模型应该怎样选择？
答标准面试回复
模型选择应基于真实业务任务，综合比较效果、延迟、成本、上下文长度、结构化输出、工具调用、多模态能力和合规要求，而不是只看排行榜或参数规模。通常可以让小模型处理简单任务，强模型处理复杂任务，并通过测试集持续评估。
选模型不能只看排行榜，也不能简单地认为越贵越好。
📊 需求分析助手至少要比较
需求理解是否准确、遗漏问题能否识别、是否会擅自补充规则、结构化输出是否稳定、响应速度、Token 成本、上下文长度、多模态与工具能力，以及数据合规要求。
⚡ 简单任务 判断需求属于前端、后端、数据库还是配置修改，可以优先考虑速度快、成本低的小模型。
🧠 复杂任务 读取长需求文档，识别规则冲突、遗漏边界和接口影响，可能需要能力更强、上下文更大的模型。
最可靠的选择方法，是准备一批真实需求，让候选模型在相同条件下运行。
●●●真正值得比较的指标
需求理解正确率关键规则遗漏率结构化输出通过率无依据内容出现率平均响应时间平均 Token单次平均费用
最后根据业务要求选择，而不是只看公开排行榜。
简单任务 优先尝试小模型
↓
复杂任务 交给能力更强的模型
↓
结果不确定 升级模型或进入人工处理
模型选择不是一次性决定，它应该建立在真实任务和持续评估上。
模型 API 调用失败，应该怎样处理？
答标准面试回复
首先要对错误分类：临时网络故障、超时、限流和部分服务端错误可以采用带随机抖动的指数退避重试；参数、权限、上下文超限和明确拒答不应盲目重试。系统还要设置超时、重试上限、降级方案、用户提示，并用幂等机制保护写操作。
模型 API 也是网络服务，一定会失败。
💥 常见失败
网络中断、请求超时、速率限制、服务端繁忙、上下文超限、参数不支持、API Key 错误、权限不足、安全拒绝、结构不合格，以及流式响应中途断开。
是不是失败后直接重试就行？不是。
✅ 通常可以重试 临时网络错误、部分超时、服务端暂时不可用、速率限制。
⛔ 不适合盲目重试 API Key 错误、访问权限不足、参数错误、上下文超限、模型明确拒绝和业务校验失败。
●●●比较完整的错误处理
发送请求 ↓设置超时时间 ↓判断错误类型 ↓临时错误：退避后重试 ↓参数或权限错误：终止并记录 ↓多次失败：降级或进入兜底流程 ↓向用户返回可以理解的状态
📚 官方建议
对于可以重试的限流和临时错误，通常使用带随机抖动的指数退避，避免所有请求同时再次冲击服务。 OpenAI · Rate Limits
需求分析只生成文字，重复请求风险相对较低。但如果后面加入创建任务、修改工单、发送通知或写数据库，超时后直接重试可能造成重复执行。
🔒 写操作还需要
幂等键、请求唯一标识、工具执行状态、重试前查询上次结果，以及把模型生成与真实写操作分开控制。
怎样估算一次模型调用的成本？
答标准面试回复
最基础的费用由输入 Token 和输出 Token 分别乘以对应单价后相加。实际项目还要考虑缓存 Token、推理 Token、多模态输入、工具调用、失败重试等费用。成本不应只看月度总账单，而要追踪到具体功能、模型、Prompt 版本和有效任务。
●●●最基础的费用公式
输入费用= 输入 Token ÷ 1,000,000 × 输入单价输出费用= 输出 Token ÷ 1,000,000 × 输出单价总费用= 输入费用 + 输出费用
假设某个模型的示例价格为输入每百万 Token 2 元、输出每百万 Token 8 元。一次需求分析使用了 20,000 个输入 Token 和 2,000 个输出 Token。
●●●示例计算
输入费用 = 0.04 元输出费用 = 0.016 元总费用 = 0.056 元
⚠️ 说明
这里的价格只用于演示计算方式，不代表任何真实模型报价。
单次五分钱看起来不多，但如果每天调用十万次，或者每次都携带很长的项目资料和对话历史，成本就会快速放大。
🧾 实际账单可能更复杂
不同平台还可能区分普通输入 Token、缓存输入 Token、输出 Token、推理 Token、批处理、多模态输入、工具调用和不同服务等级。
所以项目里不能只看平台每月总账单，更有价值的是把费用拆到具体功能、模型、Prompt 版本、平均输入输出长度、平均调用费用、失败重试费用，以及完成一次有效任务的成本。
如果只知道“这个月模型花了多少钱”，很难继续优化。
一次模型调用，真正应该记录哪些信息？
答标准面试回复
一次模型调用至少应记录请求标识、业务场景、模型与 Prompt 版本、关键参数、首字时间、总耗时、Token、费用、重试次数、结束原因、结构校验和业务反馈。同时必须对敏感数据脱敏，并控制日志的访问权限和保存周期。
●●●很多 Demo 只做到这里
调用模型 → 获得回答 → 展示给用户
模型回答不对时，只能重新调用一次，然后凭感觉比较。生产环境里，这远远不够。
🪪 请求身份 Trace ID、Request ID、用户或租户标识、会话标识、业务功能和请求时间。
⚙️ 模型配置 模型名称、版本或快照、Prompt 模板版本、关键参数、是否流式输出，以及是否调用外部工具。
📡 调用结果 调用状态、首字响应时间、总耗时、输入输出 Token、重试次数、结束原因、拒答状态、结构校验结果和最终费用。
🎯 业务效果 用户是否采用、是否重新生成、是否修改 AI 输出、是否进入人工处理，以及最终需求是否通过确认。
最后一组数据很重要。模型接口调用成功，只能说明技术请求完成了，不代表这份需求分析真的有用。
🔐 日志也有边界
用户输入可能包含公司内部需求、客户信息、数据库连接、API Key、身份凭证和业务机密。因此日志必须考虑敏感字段脱敏、访问权限、保存周期，并避免记录密钥和完整凭证。
**一个实用原则：**支持问题排查的数据要记录，不应该长期保存的敏感信息不要记录。
把 12 个问题连起来，就是一次完整调用
现在再回头看，会发现这 12 个问题不是互相独立的术语。需求分析助手的一次完整调用，大概会经历：
01 · 选择模型 根据真实任务平衡效果、速度与成本
↓
02 · 组织输入 拆分系统规则、用户需求与必要历史
↓
03 · 检查上下文 统计 Token，避免无关内容和超限
↓
04 · 设置参数 只使用当前模型真正支持的能力
↓
05 · 发送请求 建立超时、限流和重试策略
↓
06 · 接收事件 正确处理流式内容、完成与中途错误
↓
07 · 校验结果 验证结构、字段、枚举和业务边界
↓
08 · 记录效果 保存耗时、Token、费用和业务反馈
↓
09 · 进入业务 把合格结果交给后续流程
看起来只是调用了一个接口，实际上比普通接口多了很多不确定性：输入长度不固定、输出不完全固定、成本随上下文变化、模型可能生成没有依据的内容，不同模型支持的参数也不同。
🎯 真正需要掌握的不是
不是“我会调用某个模型 API”，而是**“我知道这次调用为什么这样设计，出了问题应该从哪里排查。”**
一份大模型基础自查清单
如果你正在准备 AI 应用开发，可以先检查自己能不能回答下面这些问题：
01🧩我能解释 Token 和字符、单词之间的区别
02🧠我知道哪些内容会占用上下文
03🎛️我不会把 Temperature 解释成模型聪明程度
04🧱我能区分系统规则、用户输入和历史消息
05🎲我知道为什么相同输入不一定得到相同输出
06🛡️我知道幻觉为什么不能只靠 Prompt 解决
07⚡我能说明流式输出真正改善的是什么
08💬我知道多轮对话为什么越来越贵
09🎯我会根据真实任务选择模型
10🔁我能区分哪些错误可以重试，哪些不能
11💰我会估算并追踪模型调用成本
12📊我知道一次调用应该记录哪些数据
如果这 12 项都能用自己的话讲清楚，大模型调用这一层才算真正入门。
先理解模型，再选择框架
很多人转 AI 应用，最先学的是框架。
今天学一个 Agent 框架，明天换一套 RAG 方案，后天又开始研究 MCP。
但框架下面，最终还是模型调用。
如果不了解 Token、上下文、流式响应、输出不确定性和失败处理，换再多框架，也只是把问题藏到了更深的一层。
相反，把这些基础弄明白以后，再看 Prompt、RAG、Tool Calling 和 Agent，很多东西会自然连起来。
🌱 最后的判断
AI 应用并不是围绕某一个框架搭出来的。它真正围绕的，是模型、上下文、数据、工具和业务流程之间的关系。
普通人如何抓住AI大模型的风口？
领取方式在文末
2026年入行AI大模型的黄金窗口!!!
AI产业正迎来前所未有的爆发式增长。 从DeepSeek以百万年薪重金招募顶尖研究员，到百度、阿里、腾讯等头部企业加速推进AI Agent商业化布局，再到国家层面持续出台政策，大力扶持数字经济与AI人才培育体系，多重信号清晰指向一个共识：AI的“黄金十年”已全面开启
在产业浪潮的强劲推动下，AI人才争夺战日趋白热化。技术迭代与场景落地双轮驱动，催生海量高价值岗位。放眼未来，AI领域的职业发展前景广阔无垠，正涌现出大量高潜机遇，堪称一片值得深耕的**“人才蓝海”**。
脉脉数据显示📊： 2026年1-2月，AI岗位数量同比增长约12倍，增速远超新经济行业整体增幅；AI岗位在全部新经济岗位中的占比也从2025年同期的2.29%跃升至26.23%，几乎占据新经济招聘市场的四分之一。
与此同时，AI新发岗位平均月薪高达60738元，较新经济行业整体平均月薪48189元高出约26%。
这一切都说明一件事：2026年，正是入行AI大模型的黄金窗口❗️❗️
最佳学习路线
只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！
在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。
真诚无偿分享！！！ vx扫描下方二维码即可 加上后会一个个给大家发 【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】 
大模型全套学习资料展示
自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。
希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！
01 教学内容
-
从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！
-
大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事！
02适学人群
应届毕业生： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。
零基础转型： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界。
业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型。
vx扫描下方二维码即可 【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】 
本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！
03 入门到进阶学习路线图
大模型学习路线图，整体分为5个大的阶段： 
04 视频和书籍PDF合集
从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）
新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用） 
05 行业报告+白皮书合集
收集70+报告与白皮书，了解行业最新动态！ 
06 90+份面试题/经验
AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）
07 deepseek部署包+技巧大全
由于篇幅有限
只展示部分资料
并且还在持续更新中…
人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！
真诚无偿分享！！！ vx扫描下方二维码即可 加上后会一个个给大家发 【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】
![[特殊字符]DeepSeek‑Harness（DSH）小白保姆教程-171主机测评](https://www.171host.com/wp-content/uploads/2026/08/20260816085112-6a817a009aabf-220x150.png)
