Reddit 上一篇高赞 AI Engineer 学习路线,放到今天已经不够用了 最近看到 Reddit 上一篇高赞帖子。作者分享了自己花了一年半从 Web 后端开发转型 AI Engineer 的经历学习路线大概是Python ↓ 机器学习ML ↓ 深度学习DL ↓ LLM ↓ MLOps如果放在一年前这几乎就是最标准的一条 AI 学习路线。但放到今天我觉得已经不太够用了。不是因为它写错了而是企业真正需要的 AI 工程能力已经发生了变化。路线没有问题问题是行业已经变了这条路线默认有一个前提先理解机器学习和深度学习再进入 LLM最后学习部署。对于想做算法或者模型方向的人来说这条路依然成立。但对于绝大多数软件开发者来说现实并不是这样。今天大部分公司并不会训练自己的模型。每天真正做的事情更像是调用模型 API设计 Workflow开发 Agent对接业务系统部署上线持续迭代真正需要自己训练模型的岗位比很多学习路线里描述的要少得多。如果按照今天企业的需求来看一条更贴近实际工作的路线大概会是这样软件工程 ↓ AI API ↓ Workflow ↓ Agent ↓ MCP ↓ AI 产品这里最大的变化是软件工程能力重新回到了整个学习路线的中心。LLM 已经不是终点了原帖后半部分重点介绍了 RAG、Fine-tuning、多模态等项目。这些内容今天依然值得学。但它们已经更像是基础能力而不是终点。现在很多团队讨论更多的是Tool CallingWorkflowMCPAgentEvaluation成本优化原因很简单。模型越来越强也越来越便宜。真正难的不再是能不能调用模型而是怎么把模型稳定地用起来。很多团队每天讨论的问题其实都是这些为什么 Agent 总是在某一步失败为什么 Token 成本越来越高为什么 RAG 命中了文档回答还是不准确为什么用户用了两次就不用了这些问题本质上已经不是模型问题而是工程问题。学习路线不等于真实工作评论区有一句话我很喜欢Roadmaps are useful for orientation, but they rarely show what the work actually looks like inside a team.学习路线告诉你应该学什么。但它不会告诉你公司每天到底在讨论什么。很多学习路线都是按照知识点排列Python → ML → DL → LLM。看起来很完整。真正进入团队之后你会发现每天讨论的内容完全不同。大家讨论的是这个需求真的需要 AI 吗Workflow 应该怎么拆Agent 为什么一直失败Token 成本还能不能再降用户为什么不用这个功能AI 产品最后拼的从来都不是模型。而是需求、工程和产品。模型正在越来越同质化。真正形成竞争力的已经是模型之外的部分。工程能力的重要性比半年前更高了评论区还有一句话也很认同APIs, deployment, and debugging matter more than heavy math.很多人的 AI 学习还停留在 Notebook。模型跑通了。项目结束了。但企业真正需要的是模型 ↓ API ↓ Docker ↓ 服务器 ↓ 业务系统 ↓ 监控 ↓ 日志 ↓ 持续迭代模型只是整个系统中的一个环节。真正决定项目能不能上线、能不能稳定运行的是后面的工程能力。包括API 设计Docker 部署权限管理日志系统服务监控异常处理成本控制这些能力很少出现在学习路线里却几乎每天都会遇到。如果今天重新设计一条学习路线如果让我按照现在企业的需求重新设计我会更倾向于下面这条路线。第一阶段软件工程不用重新学编程。把已有的软件工程能力打牢。Python、Git、Linux、Docker、数据库、API 开发这些依然是所有 AI 项目的基础。第二阶段AI 基础不用钻数学。理解基本概念即可。重点包括机器学习深度学习EmbeddingPrompt EngineeringRAG目标不是自己训练模型而是知道模型为什么这样工作。第三阶段AI 应用开发开始真正做项目。重点学习Structured OutputFunction CallingTool CallingWorkflow把一个项目完整做出来。从数据处理到模型调用再到接口开发和部署上线每一步都真正走一遍。第四阶段Agent这是未来几年最值得投入的方向之一。包括MCPLangGraphOpenAI Agents SDK多 Agent 协作Agent 状态管理到这一步思考的不再只是聊天而是如何让 AI 完成任务。第五阶段AI 工程化把 AI 做成真正可以运行的系统。需要掌握FastAPIRedis消息队列DockerCI/CD云部署服务监控很多企业真正缺的就是这一层能力。第六阶段AI 产品思维最后也是最容易被忽略的一层。开始思考用户真正需要什么什么场景应该用 AI什么场景其实没必要用 AIWorkflow 怎么设计Agent 应该承担哪些工作如何控制成本如何持续迭代到了这里关注的已经不是模型而是产品。写在最后我并不觉得 Reddit 这篇文章已经过时。相反它现在依然是一篇不错的入门分享。只是 AI 行业的发展速度比学习路线更新得更快。过去大家讨论的是谁更懂模型。今天企业更关心的是谁能把 AI 做成真正可落地、可维护、可持续迭代的产品。如果把前几年看作 AI 的模型时代那么从现在开始它正在进入工程时代。未来真正稀缺的人不一定是最懂模型的人。而是最懂如何把模型、工程和业务连接起来的人。这也是为什么我越来越倾向于把未来的软件开发者转型方向理解为AI Application EngineerAI 应用工程师。它不一定是一个官方职位名称但我认为它代表的是未来几年越来越重要的一种能力模型懂软件工程、懂 AI 能力也懂产品和业务。模型能力决定下限。工程能力决定上限。产品思维决定最终价值。

相关新闻

最新新闻

IMX258 sensor驱动移植实战:从解包到MTK平台稳定出图

IMX258 sensor驱动移植实战:从解包到MTK平台稳定出图

简介:在嵌入式相机开发中,传感器驱动是连接硬件与图像质量的核心环节。以索尼IMX258为例,这是一颗广泛应用于中端手机的1300万像素CMOS图像传感器,支持PDAF和4K视频。将其适配到MTK平台时,工程师不仅要理解imgsensor驱…

2026/8/27 5:22:43
中医舌象诊断系统:从图像分类到证候推理的工程落地

中医舌象诊断系统:从图像分类到证候推理的工程落地

简介:中医舌诊是‘望诊’核心环节,本质是融合舌色、苔质、分布等多维语义的证候推理过程,而非简单图像分类。其技术难点在于将《中医诊断学》中的辨证规则转化为可计算模型——需解决临床级图像采集(冷白光、标准化舌位、比色卡校…

2026/8/27 5:22:43
扩散式LLM生成速度突破2082 tokens/s,吞吐革命下自回归还够用吗?

扩散式LLM生成速度突破2082 tokens/s,吞吐革命下自回归还够用吗?

最近在看生成式模型的新动态,目光基本都落在推理速度和输出效率上。一个叫 Celeris-1 的 diffusion LLM 引起了我的注意,不是因为它背靠多大的团队或多少融资,而是项目标题里就带着一组数据:output tokens/s 达到 2082。坦白说&am…

2026/8/27 5:22:43
Documan实践指南:AI驱动需求管理工作区的部署与功能验证

Documan实践指南:AI驱动需求管理工作区的部署与功能验证

Show HN 两天前挂出一个叫 Documan 的项目,定位很直接:AI 驱动的需求管理工作区。如果你平时被需求文档、邮件、聊天记录里的零散需求搞到头大,那这个工具可能正好踩在你的痛点上。它不是一个简单的待办清单,也不是传统那种只能填…

2026/8/27 5:22:43
Matlab集成XGBoost:数据回归预测实战与工程化部署指南

Matlab集成XGBoost:数据回归预测实战与工程化部署指南

简介:梯度提升决策树(GBDT)作为一种强大的集成学习算法,通过迭代构建多个弱学习器(通常是决策树)并组合其预测结果,能有效提升模型的预测精度和泛化能力。其核心原理在于每一轮迭代都针对前一轮…

2026/8/27 5:22:43
Codeforces 1971C题解:状态模拟与集合运算在算法竞赛中的应用

Codeforces 1971C题解:状态模拟与集合运算在算法竞赛中的应用

1. 项目概述:一场算法竞赛中的“传球游戏”最近在Codeforces上刷题,又遇到了一个让我眼前一亮的题目,编号是1971C,标题叫“Rudolf and the Ball Game”。乍一看,这像是个简单的模拟题,描述了一个叫Rudolf的…

2026/8/27 5:17:43