本文针对传统IT从业者转型AI的迷茫，提供清晰的学习路径。文章首先分析了AI不同岗位方向，如应用开发、算法研究、测试和产品经理等，并探讨了Java、Python、Go等编程语言的选择。接着，文章提出AI应用开发的学习主线，从模型调用、Prompt工程、RAG到Tool Calling、Workflow、Agent，最后是Memory、MCP、Evaluation和治理。此外，还特别强调了AI测试和产品经理所需掌握的知识点。最后，文章建议通过项目驱动和问题驱动的方式学习，并尽早接触真实岗位需求，通过面试反馈持续提升。对于想要进入AI领域的小白程序员，本文提供了实用的转型指南。
前言
在我之前的文章里，已经分享了不少 AI 技术相关的内容。
从最基础的大模型调用，到 Prompt、RAG、Tool Calling，再到 Workflow、Agent、MCP、Evaluation，我自己也一直在沿着企业 AI 应用开发这条路线持续学习和实践。
但这段时间从私信和留言里，我发现一个很明显的问题：
很多人真正缺的，其实并不是某一个 AI 技术教程。
而是不知道：
我到底应该往哪个方向走？
有人做了七八年 Java，第一反应是：
“现在 AI 都是 Python，我是不是要把 Java 放弃，从 Python 重新学？”
有人做 Go，会问：
“Go 做 AI 是不是没什么机会？”
还有测试同学问：
“AI 这么火，测试以后还有没有机会？我应该转开发还是做 AI 测试？”
产品经理也会纠结：
“我要不要学 RAG、Agent？是不是以后产品也得会写代码？”
甚至已经开始学 AI 的开发者，同样容易陷入另外一种迷茫：
Prompt、RAG、Agent、Workflow、MCP、Memory、Evaluation、A2A……
东西越来越多，到底应该先学哪个？
学到什么程度，才算可以开始找工作？
信息并不少。
恰恰是因为信息太多、太碎，才让很多人越来越不知道从哪里下手。
所以这一篇，我不准备再单独讲某一个技术。
我们换一个视角。
从一个传统 IT 人真正准备转向 AI 开始，重新把下面几个问题掰开揉碎：
- AI 到底有哪些不同岗位？
- 开发、测试、产品分别应该往哪里转？
- Java、Python、Go 到底怎么选？
- RAG、Agent、MCP、Evaluation 应该按照什么顺序学习？
- 前三个月到底应该做什么？
- 学到什么程度，就可以开始投简历？
我希望这篇文章最终解决的不是：
“AI还有哪些东西需要学？”
而是：
“我下一步到底应该学什么？”
1.为什么很多传统IT人现在都很迷茫
我觉得现在很多传统 IT 人面对 AI 时，都会经历一个很相似的阶段。
最开始是焦虑。
突然之间，大模型、AIGC、Agent 到处都是。
再往后开始主动学习。
看 Prompt，学 RAG，研究 LangChain、Spring AI、Dify、MCP。
结果学了一段时间之后，反而更迷茫了。
因为你会发现，AI 相关技术并不是越来越少，而是越来越多。
今天刚把 RAG 搞明白。
明天大家开始聊 Agent。
Agent 还没有真正做完，又开始出现：
- MCP
- Agentic
- Evaluation
- A2A
- Memory
- Skills
- AI Gateway
- Guardrails
于是一个非常典型的问题出现了：
我是不是所有东西都得学？
答案显然不是。
很多人的真正问题，其实不是“不会学习”。
而是缺少两个判断：
第一，我到底准备转什么岗位？
第二，这个岗位真正要求我学到什么程度？
如果这两个问题没有解决，学习路线一定会越来越乱。
比如一个已经有多年 Java 后端经验的开发者，目标只是转 AI 应用开发。
他完全没有必要因为看到别人用 PyTorch，就立刻从高等数学、机器学习、深度学习重新开始。
同样。
一个准备做 AI 产品经理的人，也没有必要为了理解 Agent，先把 Spring AI 或 LangChain 源码研究一遍。
所以 AI 转型的第一步，并不是马上打开教程。
而是先把方向搞清楚。
很多人的问题不是不会学，而是不知道应该往哪学。
2.先别急着学习，先确认你想转哪一种AI岗位
“转 AI”其实是一个非常模糊的说法。
因为 AI 并不是一个岗位。
至少对于大多数传统 IT 人来说，现在常见的转型方向，可以先粗略拆成四条。
- 1 AI应用开发
这是目前和传统后端开发距离最近的一条路线。
它解决的问题不是：
怎么训练一个更强的大模型？
而是：
怎么把大模型真正接进企业业务系统。
比如：
- 企业知识库
- 智能客服
- 数据分析助手
- HR助手
- 工单助手
- 报表生成
- 合同审查
- 自动化业务流程
- Agent任务执行
这类岗位除了 AI 能力之外，往往仍然非常需要传统工程能力：
- Java / Python / Go
- Web开发
- 数据库
- Redis
- MQ
- 微服务
- 权限
- 日志
- 并发
- 稳定性
- 部署
- 系统设计
这也是为什么我一直认为：
对于已经有多年工程经验的开发者来说，AI应用开发通常是一条转型成本相对更低的路线。
你不是重新就业。
而是在原来的工程能力上增加 AI 能力。
- 2 AI算法 / 模型方向
这就是另外一条完全不同的路线了。
如果你的目标是：
- 模型训练
- 模型微调
- 深度学习
- NLP
- 多模态
- 推理优化
- 算法研究
那么 Python 基本就是绕不开的。
同时还需要继续补：
- 数学基础
- 机器学习
- 深度学习
- Transformer
- PyTorch
- 模型训练
- 微调
- 推理
这条路线并不是不能走。
但对于一个已经工作很多年的传统开发者来说，要意识到：
它和AI应用开发并不是同一条学习路线。
不要因为两个岗位名字里都有“AI”，就把它们混在一起。
- 3 AI测试 / AI Quality
AI出现之后，测试并没有消失。
反而出现了新的质量问题。
以前我们测试一个接口：
输入确定↓规则确定↓输出应该确定但是大模型不是这样。
同一个问题，两次回答的文字可能完全不同。
可它们又可能都算正确。
因此 AI 系统出现了一批传统软件里不那么典型的问题：
- RAG到底有没有召回正确内容？
- 模型有没有引用错误？
- Prompt升级之后效果是变好了还是变差了？
- Agent到底有没有完成任务？
- Tool到底调用对没有？
- 模型回答虽然看起来不错，但事实是否正确？
- 一次模型升级会不会让原来的能力退化？
这些问题都会催生新的测试和质量工程能力。
所以对于测试人员来说，一条很自然的路线就是：
传统质量保障能力 + AI Evaluation。
后面我们会单独展开。
- 4 AI产品经理
AI产品经理和传统产品经理相比，一个明显变化是：
产品能力开始越来越依赖对模型能力边界的理解。
以前设计一个功能，我们往往更关心：
- 业务流程
- 页面
- 权限
- 状态流转
- 用户体验
现在还必须再多问一层：
这个问题到底适不适合交给大模型？
例如：
什么时候应该用 RAG？
什么时候直接调用模型就够了？
什么时候应该设计固定 Workflow？
什么时候才真的需要 Agent？
什么操作允许 AI 自动执行？
什么操作必须让人确认？
这意味着 AI 产品经理不一定需要自己实现这些能力，但必须理解它们的边界。
所以在真正开始学习之前，我建议你先问自己一句：
我准备转的是哪一种AI岗位？
因为只有岗位确定了，技术路线才有意义。
3.开发者到底选Java、Python还是Go
这是我看到最多的问题之一。
尤其对于 Java 开发者来说。
很多人一听到 AI，第一反应就是：
Python。
于是开始怀疑：
我做了这么多年 Java，是不是已经没用了？
我自己的理解恰恰相反。
- 1 Java开发为什么没必要为了AI清零重学
如果你的目标是模型训练，那么当然应该重点学习 Python。
但如果你的目标是：
企业AI应用开发。
问题就完全不一样了。
企业真正落地一个 AI 应用，除了模型之外，还有大量传统工程问题：
- 登录认证
- 用户权限
- 数据库
- 缓存
- 业务接口
- 微服务调用
- 任务编排
- 限流
- 熔断
- 超时
- 审计
- 日志
- 数据安全
- 部署
- 高可用
这些能力并不会因为大模型出现就消失。
所以如果你已经有多年 Java 后端经验，更合理的路线通常不是：
Java全部放弃↓Python从零开始↓重新建立工程能力而应该是：
保留Java工程能力↓补齐LLM应用开发↓掌握RAG / Tool / Workflow / Agent↓补齐AI系统治理现在 Java 本身也已经有 Spring AI、Spring AI Alibaba、LangChain4j 等生态。
至少在“企业 AI 应用开发”这个方向上，Java并不是不能做。
- 2 Python真正的优势在哪里
当然，这并不代表 Python 不重要。
Python 在 AI 生态里的优势仍然非常明显。
特别是：
- 模型训练
- 数据处理
- AI实验
- 开源模型生态
- 各类AI框架
- Evaluation工具
- 原型验证
如果你本身就是 Python 开发，那么没有必要为了企业开发刻意转 Java。
你完全可以直接沿着：
Python↓LLM应用↓RAG↓Agent↓Evaluation↓企业工程化继续深入。
真正应该避免的是把问题变成：
Java和Python谁更适合AI？
这个问题本身就太大了。
更合理的问题应该是：
我准备做什么AI工作？
- 3 Go能不能做AI
Go也是同样。
如果你现在已经是 Go 开发，没有必要因为 AI 就强制清零。
Go 在一些场景反而有自己的优势，比如：
- AI基础服务
- Gateway
- MCP Server
- 高并发API服务
- 模型代理
- 工具服务
- AI基础设施
只是相比 Python，Go 在上层 AI 应用框架和实验生态上没有那么丰富。
所以对于 Go 开发者来说，更现实的路线通常是：
保留Go工程能力，同时补齐AI应用开发的公共能力。
最终还是回到一句话：
先选择岗位，再选择技术路线。
对于已经有多年工作经验的人来说，原有技术积累是一种资产。
不要为了“转AI”三个字，轻易把它清零。
4.AI应用开发其实存在一条共同主线
说完语言之后，我们再来看一个更重要的问题。
很多人学习 AI 最大的问题，是把每个技术都看成一个完全独立的知识点。
今天学 Prompt。
明天学 RAG。
后天学 Agent。
然后开始问：
为什么要学这些？
其实如果你从一个完整 AI 应用的演进过程来看，它们之间是可以串起来的。
我更习惯把它理解成这样一条能力链：
- 1 第一步：先让模型真正进入你的程序
刚开始不要搞复杂。
先知道：
- LLM是什么
- Token是什么
- System Prompt是什么
- Temperature大概解决什么
- 怎么调用一个模型
- 同步和流式输出有什么区别
然后真的写一个接口，把模型调用起来。
到这里，你解决的是：
程序怎么和大模型通信。
- 2 Prompt和Structured Output：让输出开始可控
模型可以聊天之后，你很快会发现另外一个问题：
它说什么格式，并不完全听你的。
但企业系统不能只拿一段自然语言。
很多场景需要：
{ "intent": "REFUND", "orderId": "12345", "reason": "商品损坏"}所以接下来你就会自然接触：
- Prompt Engineering
- Structured Output
- JSON Schema
- 输出校验
这个阶段解决的是：
怎么让模型从“会回答”变成“可以被系统消费”。
- 3 RAG：解决模型不知道企业私有知识的问题
再往后你会遇到：
模型不知道公司的制度、产品文档、订单规则、内部知识怎么办？
这时 RAG 就出现了。
你需要开始理解：
- 文档加载
- Chunk
- Embedding
- 向量数据库
- 召回
- TopK
- 重排
- 引用
- 幻觉控制
RAG解决的是：
让模型能够使用外部知识。
这也是我非常建议 AI 应用开发者认真做一个完整 RAG 项目的原因。
因为它第一次真正把：
模型 + 数据 + 工程系统
连接到一起。
- 4 Tool Calling：让AI从“回答问题”走向“执行操作”
RAG虽然可以查数据。
但它还是不能真正操作业务。
比如用户说：
帮我查询订单物流。
模型自己并不知道物流状态。
这时你需要把：
queryOrder(orderId)这样的业务能力暴露给模型。
于是进入 Tool Calling。
它解决的是：
让模型不仅能知道，还能调用真实业务能力。
到这里，AI已经开始真正进入业务系统。
- 5 Workflow和Agent：开始处理复杂任务
一个 Tool 还比较简单。
但企业业务很快会变成：
识别意图↓查询订单↓判断状态↓查询退款规则↓生成方案↓必要时转人工如果步骤基本固定，那么 Workflow 通常更加合适。
如果目标确定，但执行路径需要根据中间结果动态调整，就可能进入 Agent。
所以我现在越来越倾向于用一句话区分它们：
Workflow强调流程确定，Agent处理路径不确定。
不是所有场景都应该用 Agent。
企业真正需要控制的是不确定性，而不是最大化自主程度。
- 6 Memory、MCP、Evaluation和治理
到了这个阶段，才建议继续往后补。
比如：
Memory
解决多轮对话、上下文压缩、用户长期信息的问题。
MCP
解决模型与外部工具、资源之间更加标准化的连接问题。
Evaluation
解决：
我这个AI应用到底好不好？
企业治理
解决：
- 模型超时
- 限流
- 熔断
- Token成本
- 审计
- 权限
- 敏感信息
- Human-in-the-loop
- Guardrails
- 多模型路由
所以你会发现：
这些技术其实不是随机出现的。
它们是在一个 AI 应用从 Demo 逐渐走向真实业务的过程中，一个个自然产生的。
这也是为什么我不建议刚开始学习的人，把 MCP、Agent、Evaluation、A2A 一口气全部学完。
先知道它们是什么。
真正遇到对应问题时，再深入。
5.测试怎么进入AI，以及为什么开发也必须懂Evaluation
接下来单独说测试。
我觉得 AI 对测试人员带来的影响，可能比很多人想象得更大。
因为传统软件测试非常依赖：
确定输入 + 确定预期结果。
但AI系统越来越多的是：
结果不是完全确定，却仍然需要判断质量。
例如：
用户问：
公司年假怎么计算？
RAG第一次可能回答：
根据入职年限计算……
第二次可能换一种表达。
文字不一样。
但内容都可能正确。
那么你到底怎么测？
这就进入 AI Evaluation。
- 1 Prompt测试
最基础的是 Prompt。
比如 Prompt 从 V1 升级到 V2。
你不能只手工问三四个问题，然后说：
看起来效果不错。
更合理的方法应该是维护一组测试 Dataset。
每次 Prompt 调整以后自动执行。
然后比较：
- 指令遵循
- 格式正确率
- 内容完整性
- 拒答正确性
- 事实准确性
这其实就是一种 AI 时代的回归测试。
- 2 RAG Evaluation
RAG又会复杂一层。
因为一个错误答案背后，可能存在完全不同的原因。
比如：
答案错误可能是：
文档没切好也可能是：
召回错了还可能是：
召回是对的，但模型没有正确使用上下文所以 RAG Evaluation 往往需要分别关注：
- Retrieval Quality
- Context Relevance
- Faithfulness
- Answer Relevance
- 引用正确性
这时候测试就不再只是：
最后的答案对不对。
而是开始评估整条 AI 链路。
- 3 Agent Evaluation
Agent更复杂。
比如一个Agent接到任务：
查询某个订单，判断是否满足售后条件，并生成处理建议。
我们需要评估的就不只是最后一段文字。
还可能包括：
- 有没有调用正确Tool
- Tool参数是否正确
- 调用顺序是否合理
- 是否进行了不必要调用
- 最终有没有完成任务
- 是否触发了错误操作
- 是否应该转人工却没有转
所以 Agent Evaluation 会越来越接近：
任务级质量评估。
- **4 Dataset、Ground Truth
一组专门用于测试 AI 系统的数据。
Ground Truth
人工确认过的标准答案或标准结果。
LLM-as-a-Judge
使用另一个大模型按照评分规则，对当前模型结果进行评价。
它们不是要求测试人员马上研究得非常深。
但至少要知道：
AI质量已经开始从“写测试用例”向“构建持续评测体系”发展。
- 5 为什么开发也必须懂Evaluation
这里我特别想强调一点：
Evaluation不是测试岗位的专属能力。
做 AI 应用开发的人同样必须懂。
因为以后当你说：
我做了一个 RAG。
面试官或者技术负责人很可能会继续问：
效果怎么样？
这时如果你的答案只是：
我自己测试了一下，感觉挺准。
显然不够。
开发至少应该知道：
- RAG召回质量怎么评估
- 引用正确性怎么判断
- Agent任务完成率怎么定义
- Tool调用正确率怎么看
- Prompt升级怎么回归
- 上线之后怎么持续观测
AI时代，开发和测试之间的能力边界正在越来越明显地交叉。
6.产品经理需要学到什么程度
再来看产品。
我不认为 AI 产品经理一定要学会自己实现 RAG 或 Agent。
但如果完全不懂这些能力，也很难真正设计一个 AI 产品。
至少要知道：
LLM
它擅长什么？
它为什么会幻觉？
什么事情不能完全相信模型？
Prompt
Prompt能够解决什么？
又有哪些问题不是改 Prompt 就能解决的？
RAG
什么时候需要企业知识库？
什么时候模型自己的知识就够了？
Workflow
如果业务流程固定，是不是应该优先用 Workflow，而不是 Agent？
Agent
什么时候任务真的需要动态决策？
Agent增加的自主性，会不会同时带来新的风险？
Tool Calling
哪些企业能力可以开放给模型？
只读查询和写操作的风险是不是一样？
Evaluation
怎么证明功能升级之后真的变好了？
Human-in-the-loop
什么操作可以自动执行？
什么地方必须加入人工确认？
所以我认为 AI 产品经理真正需要掌握的，不是 Agent 的代码怎么写。
而是：
知道AI能解决什么、不能解决什么，以及如何设计AI的边界。
甚至可以再进一步：
AI产品经理真正需要具备的，不是实现Agent的能力，而是设计Agent边界的能力。
7.选定方向以后，前三个月到底怎么做
前面讲了这么多。
最终还是得落到一个现实问题：
那我从明天开始到底学什么？
这里我先以 AI 应用开发为主线。
不用精确到“第几天”。
但可以按照五个阶段往前推进。
阶段一：先完成最小AI应用
学习：
- LLM基础
- 模型API
- Prompt
- Structured Output
- SSE
做出：
一个真正可以使用的大模型应用。
比如：
- 聊天助手
- 内容提取
- 信息分类
- 结构化数据生成
完成标准不是：
看完教程。
而是：
你可以自己独立把模型接入业务程序。
阶段二：完成一个完整RAG项目
接下来学习：
- 文档解析
- Chunk
- Embedding
- Vector Store
- Retrieval
- Rerank
- Citation
然后做一个：
企业知识库问答。
完成之后至少应该能够回答：
- Chunk为什么这么切？
- TopK怎么选？
- 为什么要重排？
- 怎么降低幻觉？
- 怎么做引用？
- 效果怎么评估？
如果这些问题都能说明白，RAG基本就开始进入真正掌握阶段了。
阶段三：让AI调用真实业务
然后进入：
- Tool Calling
- 参数Schema
- Tool设计
- 异常处理
- 权限控制
不要只做：
查询天气。
可以模拟一个真实企业场景，比如：
查询订单 → 查询售后规则 → 生成处理建议。
到了这里，你会第一次明显感受到：
AI开始真正和传统后端开发融合。
阶段四：进入Workflow和Agent
当一个 Tool解决不了复杂任务之后，再学习：
- Workflow
- Router
- ReAct
- Agent
- Human-in-the-loop
重点不是把各种 Agent 框架 API 背下来。
而是搞明白：
什么场景应该 Workflow？
什么场景需要 Agent？
哪些步骤应该确定？
哪些决策允许模型动态完成？
这才是真正重要的。
阶段五：补齐企业级能力
到这个阶段再继续补：
- Evaluation
- Memory
- MCP
- Guardrails
- AI Gateway
- Token统计
- 限流
- 熔断
- 超时
- 模型路由
- 审计
- 成本
- 安全
你会发现：
这些知识到了这个时候再学，会容易很多。
因为你已经知道：
它到底是在解决哪个问题。
对于测试来说，可以简单按照：
LLM基础↓Prompt测试↓RAG Evaluation↓Agent Evaluation↓Dataset / Ground Truth↓自动化评测体系产品可以按照：
LLM能力边界↓Prompt↓RAG↓Workflow↓Agent↓Evaluation↓Human-in-the-loop不需要所有岗位都走完全相同的路线。
但每条路线都应该有明确阶段。
8.我现在更推荐的一种学习方法
最后再聊一个我自己这段时间感触越来越明显的问题：
到底应该怎么学习这些AI知识？
以前我们很习惯这样的学习方式：
找到一份完整教程↓从第一章开始↓逐章学习↓做笔记↓背概念这种方法不是完全没有用。
但对于 AI 应用开发这种变化非常快，而且高度工程化的方向来说，我现在越来越倾向于：
项目驱动 + 问题驱动 + 主动追问 + 最后总结。
- 1 先让项目产生问题
比如你先做一个 RAG。
然后发现：
为什么召回出来的内容不准确？
这个问题一旦真的出现在自己的项目里，你再去研究：
- Chunk
- Embedding
- TopK
- Hybrid Search
- Rerank
你对这些知识的理解会明显不一样。
因为它们不再是几个需要背诵的名词。
而是在解决你真正遇到的问题。
- 2 不断往生产级追问
例如你刚刚学会 Agent Evaluation。
不要停在：
Agent Evaluation就是评估Agent效果。
继续追问：
到底评估什么？
再往下：
任务完成率怎么定义？
继续：
Tool调用正确性怎么评估？
继续：
如果任务没有唯一标准答案怎么办？
再继续：
LLM-as-a-Judge靠谱吗？
最后：
Prompt或者模型升级之后怎么做回归？
当你把一个问题这样连续追下去之后，一个完整知识体系往往自然就形成了。
- 3 新知识和复习应该用不同方法
对于完全没接触过的新知识：
先问题驱动。
不要一上来背定义。
先理解它为什么出现、解决什么问题。
但对于已经学过的东西：
先闭卷回答，再检查缺口。
比如已经学过 RAG Evaluation。
第二天不要马上打开昨天的笔记。
先问自己：
RAG到底评估哪几层？
自己回答完，再回来补。
这种方式比一遍遍重读总结有效得多。
所以我现在很认同一句话：
总结应该是学习的结果，而不是学习的起点。
9.什么时候开始找工作？不要等到“全部学完”
最后再解决一个转型过程中非常容易踩的坑：
我要什么时候才能开始投简历？
很多人的计划是这样的：
先把AI全部学完↓把所有项目做完↓把所有面试题准备完↓最后开始投简历听起来很稳。
实际上很可能永远等不到那一天。
因为 AI 领域新的东西一直会出现。
今天还有 MCP。
明天还有新的 Agent Framework。
后面还有新的协议、新的模型、新的评测方法。
如果你的标准是：
等我全部都会了再找工作。
那基本永远都不会准备完成。
- 1 学到什么程度可以开始投
如果目标是 AI 应用开发，我认为至少可以把一个阶段性标准设成：
- 能独立接入LLM
- 做过完整RAG
- 理解Tool Calling
- 做过一个有业务逻辑的AI项目
- 对Workflow / Agent有基本理解
- 能解释自己的技术选型
到了这里，其实就应该开始研究 JD，甚至尝试投递。
后面的 Evaluation、MCP、Memory、Gateway、治理能力，可以继续边学边补。
- 2 JD本身就是学习资料
为什么我一直建议大家尽早看 JD？
因为真正的岗位需求，往往比一份网上的“AI学习路线图”更有价值。
你连续看几十个目标岗位，很快就会发现：
哪些技术反复出现？
哪些只是偶尔出现？
哪些岗位更看重 Python？
哪些更强调 Java 工程能力？
哪些非常关注 RAG、Agent？
哪些还要求传统微服务能力？
这时候你的学习路线就会开始从：
别人让我学什么。
变成：
市场真正需要什么。
- 3 面试反馈同样是学习的一部分
真正进入面试以后，价值会更大。
比如连续两次都被问：
RAG效果怎么评估？
那就说明 Evaluation应该马上补。
连续被追问：
Agent和Workflow到底怎么选？
那就说明这个问题还没有真正掌握。
如果面试官一直追问：
超时、重试、限流、并发怎么设计？
说明企业真正关心的不只是你能不能把 Agent 跑起来。
还关心：
它到底能不能进生产。
所以更合理的转型闭环应该是：
学习↓项目↓JD研究↓投递↓真实面试↓暴露知识缺口↓继续学习求职本身，也应该成为学习过程的一部分。
10.写在最后
如果现在再让我总结传统 IT 人应该怎么转 AI，我可能不会再给一份几十项的技术清单。
因为真正重要的不是：
AI还有多少东西没有学？
而是先想明白三个问题：
第一，我现在已经会什么？
第二，我准备转什么岗位？
第三，这个岗位离我现在的能力到底差什么？
对于开发来说。
Java、Python、Go都只是进入AI应用开发的不同入口。
对于测试来说。
原来的自动化测试、质量保障经验并没有过时，而是可以继续延伸到 AI Evaluation。
对于产品来说。
过去的业务分析和产品设计能力同样没有消失，只是需要进一步理解 LLM、RAG、Agent以及AI系统的能力边界。
所以我越来越不认同一种说法：
AI来了，传统IT人的经验都没用了。
恰恰相反。
真正进入企业AI落地之后你会发现：
模型只是其中一部分。
后面依然有：
- 业务
- 数据
- 系统
- 架构
- 权限
- 流程
- 稳定性
- 测试
- 安全
- 成本
- 用户体验
这些能力最终还是需要过去十几年的软件工程经验去承接。
所以如果你现在也正处在 AI 转型的迷茫期。
不用因为自己还有很多东西不会，就一直停在原地。
先选一个离自己最近的方向。
做一个真正能跑起来的小项目。
在项目里遇到问题。
再围绕问题不断学习、追问、补齐。
然后尽早去看真实 JD，尽早接触真实面试。
AI转型不是把过去十年的经验清零。
而是在你原来的能力树上，再增加一条AI能力链。
这可能也是传统 IT 人进入 AI 时代，成本最低、也最现实的一种方式。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
大模型入门到实战全套学习大礼包
1、大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
2、大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
3、AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
4、大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
5、大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
适用人群
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
