本文分享了字节跳动后端校招面试的核心考点涵盖设计模式策略模式、责任链模式、HashMap并发安全、MySQL索引优化、消息队列与分布式事务等硬核知识。从数据库层面到应用层详细解析了高并发扣减库存的优化策略并对比了RabbitMQ与RocketMQ的优劣。我之前还以为今年小红书校招薪资能稳坐第一呢毕竟月薪基本都 30k 往上高的都能冲到 38k。结果字节一开奖直接绝杀全场后端开发岗的 base 薪资居然有开到 40k 的再加上签字费第一年总包直接干到 70 万以上。这薪资真的离谱到家了不光是今年最高估计也是字节校招历史以来最高的。这入职不得直接是 2-1 级别老员工要是看到旁边刚毕业的应届生薪资比自己还高不得偷偷哭晕不过能拿到 40kbase 的还是少数人大部分同学的薪资还是在 25k-35k 这个区间。我特意收集了一波已开奖的开发岗薪资后端/客户端/前端/大数据开发整理出来给大家参考档次薪资构成总包第一年SSP40k×15 10w签字费70wSSP36k×15 9w签字费63wSSP38k×15 5w签字费62wSSP35k×15 8w签字费60.5wSSP34k×15 9w签字费60wSSP32k×15 5w签字费53wSP30k×15 1w签字费46wSP29k×1543.5wSP28k×1542w白菜档26k×1539w上面的薪资档次是我自己猜的啊不是官方数据仅供大家心里有个数。跟 HR 谈薪的时候要是他明确说 base 没法再涨了你可以试试多要点头签字费说不定有戏。这时候 HR 一般会帮你内部申请申请要是你手上还有其他同级别公司的 offer成功率就更高了。所以有时候你会发现有些 base 高的签字费反而不如 base 低的多大概率就是谈薪时 base 涨不动了公司就用签字费补了。现在都快 12 月了但我还是想鼓励还在秋招的同学春节前都别放弃投递就算之前投过的公司也多去官方招聘网更新下简历这个动作真的有用。后面这几个月捡漏 offer 的机会特别大 现在各大公司开奖都差不多了肯定有很多人拒 offerHC 一空出来说不定你就能速通面试直接拿下 offer。这次就给大家看看今年字节跳动的后端一面校招面经。我感觉这场面试考察得挺有深度特别值得学习。它不只是单纯问八股更多是考察你对知识点背后逻辑的理解。主要考的知识点有设计模式、Java 集合、MySQL 索引、消息队列、分布式事务这些都是实打实的硬知识。字节跳动后端一面1. 介绍一下策略模式和责任链模式分别用在哪些场景这两个设计模式都属于行为型模式而且在实际开发中它们往往都是为了解决同一个痛点如何消除代码中复杂的if-else或switch-case逻辑从而让系统更易于扩展。策略模式策略模式定义一系列算法把它们一个个封装起来并且使它们可相互替换。从而让算法可独立于使用它的客户而变化。假设你正在开发一个电商网站的支付模块。用户可以选择支付宝、微信支付或者银行卡支付。每种支付方式的底层逻辑比如调用的 API、加密方式、参数构造都完全不同但对于调用支付功能的上层业务逻辑来说它只需要调用一个统一的 “支付” 方法即可无需关心具体是哪种支付。这就是策略模式的用武之地。我们把每种支付方式支付宝、微信都封装成一个独立的 “策略” 类它们都遵循一个共同的接口。上层业务代码通过这个共同的接口来调用支付功能并可以在运行时根据用户的选择动态地切换不同的策略。所以策略模式适用场景如下当一个系统需要动态地在几种算法中选择一种时。当一个对象有很多行为不想使用大量的if-else或switch-case语句来选择时。当你希望算法的变化不会影响到使用它的客户端时。责任链模式责任链模式核心思想是为请求创建一个接收者对象的链。对请求的发送者和接收者进行解耦让多个对象都有机会处理这个请求。请求沿着链传递直到链上的一个对象处理它为止。想象一下公司里的请假审批流程。一个员工要请假他首先会把请假条交给自己的直属经理。如果请假天数很短比如 1 天经理自己就能批准。如果天数较长比如 5 天经理没有权限就需要把请假条上报给部门总监。总监也有自己的审批权限上限如果超过了就需要继续上报给总经理。在这个过程中请假条请求就在一条由经理 - 总监 - 总经理接收者链上传递直到某个角色接收者能够处理它。发送请假条的员工客户端并不知道最终是谁批准了他的假他只需要把请求提交给链的第一个节点经理即可。所以责任链模式适用场景总结当有多个对象可以处理同一个请求但具体由哪个对象处理需要在运行时决定时。当你希望请求的发送者和接收者解耦不直接通信时。当你需要动态地指定和修改处理一个请求的对象集合时。2. HashMap并发不安全的原因是什么HashMap 之所以并发不安全根源在于它为了性能摒弃了所有同步手段。在JDK 1.7中并发扩容导致的链表成环是最大隐患会导致 CPU 飙升。在JDK 1.8中虽然修复了成环问题但并发执行put操作时的竞态条件会导致数据覆盖依然是不安全的。除了上述两个核心结构上的问题还有一个更基础的并发问题那就是size计数。HashMap 内部有一个size变量来记录键值对的数量。无论 1.7 还是 1.8这个size操作都不是原子性的。它分为读取、增加、写回三步。多线程下两个线程同时拿到旧值同时加 1最后写回。结果就是明明插入了两个数据size却只增加了 1。如果业务场景涉及多线程我肯定不会去用 HashMap而是直接上ConcurrentHashMap或者在极少写入的场景下用Collections.synchronizedMap包装一下。3. HashMap为什么使用拉链法解决哈希冲突设计 HashMap 时本质上是在开放寻址法和拉链法之间做权衡。Java 选择拉链法我认为主要看重了它的隔离性和扩展上限。第一避免“堆积”效应。开放寻址法遇到冲突要往后找空位数据容易连成一片导致后续插入和查询越来越慢。而拉链法的冲突是隔离的Bucket A 的拥堵绝对不会影响 Bucket B即使负载较高性能下降也更平缓。第二删除操作简单。开放寻址法删除元素很棘手为了不断掉查找链路通常需要打标记逻辑复杂且容易出错。而拉链法本质是链表删除节点只需调整指针逻辑非常干净。第三也是最关键的它为 JDK 1.8 的红黑树优化提供了基础。正是因为数据通过拉链聚在了一起当链表过长时我们才能将其“原升级”为红黑树将查询复杂度锁定在 O(log n)。如果是散落在数组各处的开放寻址法就很难做这种局部的数据结构“进化”了。综合来看HashMap 作为通用组件拉链法的下限更高处理极端冲突的能力更强。4. MySQL建立索引的字段的要求是什么判断一个字段是否适合建立索引我主要依据四个硬性指标核心逻辑是保证查询效率提升的同时将对写性能和存储的负担降到最低。第一字段的区分度基数必须高。 这是最关键的指标。如果一个字段的取值很少比如性别、状态枚举大量数据重复MySQL 优化器往往会认为全表扫描比走索引更快导致索引失效。只有当字段能过滤掉绝大部分数据时比如 ID、手机号索引的效率才高。第二必须是高频被使用的字段。 索引字段必须经常出现在WHERE查询条件、JOIN连接条件、或者ORDER BY和GROUP BY语句中。特别是作为JOIN关联字段时不仅要建索引还必须保证左右两张表的字段类型完全一致避免因类型转换导致索引失效。第三字段长度尽量小。 字段占用的字节越少单个 B 树索引页Page能存储的节点就越多一次磁盘 IO 能读取到的索引数据也就越多。对于长字符串如 varchar 255我不建议全字段索引而是应该指定长度建立前缀索引。第四更新频率不能过高。 索引虽然加速了查询但会拖慢写入。每次字段更新数据库都需要同步调整 B 树的结构。如果某个字段如“访问计数”变化极快维护索引的代价会超过查询带来的收益这种字段不适合建索引。简单来说我会优先选择那些区分度高、频繁参与查询、字节长度小且更新相对稳定的字段建立索引。5. 一张表有主键id、a、b三个字段where条件使用a字段如何优化查询我会从索引策略和查询结构两个维度分层次进行优化。首先最基础的操作肯定是在a字段上建立索引。这是为了解决最根本的问题将全表扫描转化为 B 树的范围查找这是性能提升的第一步。其次为了追求极致性能我会进一步检查 SQL 语句中需要SELECT出来的字段。如果查询涉及b字段例如SELECT b FROM table WHERE a ?单给a建索引是不够完美的因为数据库通过a的索引找到主键 ID 后还需要进行一次“回表”操作去聚簇索引中获取b的数据。在这种情况下我会选择建立(a, b)的联合索引。因为在 InnoDB 中联合索引的叶子节点本身就包含了a、b的值以及主键id。这样一来查询所需的所有数据都能直接在索引树上取到实现了覆盖索引完全避免了回表的随机 IO 开销这才是效率最高的方案。最后我也会排查一下客观条件。比如确认a字段的区分度是否足够高如果a的重复数据太多索引可能根本不会生效。同时我要确保 SQL 语句中没有对a字段做函数运算或者发生了隐式类型转换比如字符串没加引号防止因为语法问题导致前面的索引优化全部失效。6. 如果a字段是一个文本类型大json无法建立索引如何优化查询面对这种无法直接建立索引的大文本或 JSON 字段单纯的“硬查”肯定会导致全表扫描。我会根据具体的查询业务场景采用不同的策略来绕过这个限制第一种情况如果业务是根据 JSON 内部的某个特定字段查询。这是最常见的场景。比如WHERE a-$.status 1。 我会使用 MySQL 5.7 引入的“虚拟列”功能。我可以创建一个虚拟列专门提取 JSON 中的status字段然后直接给这个虚拟列建立索引。 这样既不需要修改原有数据结构又能利用 B 树索引直接定位到行这是处理 JSON 字段查询最高效的方法。第二种情况如果业务是查询整个文本的“完全匹配”。比如WHERE a 一大段特定的JSON字符串。 直接比对字符串太慢且无法建索引。我会引入一个辅助字段比如a_hash。在插入或更新数据时同步计算内容a的 MD5 或 CRC32 值存入a_hash并给a_hash建索引。 查询时改为WHERE a_hash ? AND a ?。先通过 Hash 值快速过滤出极少数候选行再通过文本比对确认最终结果性能提升非常明显。第三种情况如果业务是模糊查询或关键词搜索。比如WHERE a LIKE %关键词%。 这种情况下 B 树索引基本失效。如果并发量不大可以尝试 MySQL 自带的Full-Text 全文索引倒排索引机制。但如果数据量级非常大且查询复杂我会建议将这部分数据同步到ElasticSearch这样的搜索引擎中进行处理MySQL 仅负责存储原数据不再承担此类查询压力。核心思路是“把不可索引的数据转化为可索引的数据”。 如果是查 JSON 里的值就抽离出虚拟列建索引如果是查全量内容就利用 Hash 映射建索引如果是搜文本就走全文检索。7. 一张表有主键id和库存数量两个字段每次一个请求会对库存数量减1如何突破性能瓶颈针对这个高并发扣减库存的场景核心瓶颈非常明确在于数据库的行锁竞争。因为所有请求都在更新同一行数据InnoDB 必须按顺序排队处理这会导致严重的锁等待和上下文切换数据库的 TPS 会被限制在这个单行的处理能力上。要突破这个瓶颈我的优化思路如下。首先在数据库层面我会采用“热点库存分段”的策略。 既然瓶颈是所有的压力都打在同一行id上那我就把这一行库存拆解成多行。比如把总库存 1000 拆分成 10 条记录每条存 100放在一张子表里。当请求进来时我随机或轮询选择其中一条子记录进行扣减。这样一来我就把针对一把锁的竞争分散到了 10 把锁上理论上数据库的并发性能直接提升了 10 倍。如果分段锁的性能还是不够或者不想改动数据库结构我会将扣减逻辑上移到 Redis。 Redis 是基于内存的操作且单线程天然无锁竞争针对单个命令性能远超数据库。我会编写一个Lua 脚本在脚本里原子性地执行“判断库存是否充足”和“执行 DECR”这两个动作。前端流量全部挡在 Redis 层只有扣减成功的请求才会被允许进入下一步。这里引入了一个新问题Redis 和数据库的数据一致性。 为了不让数据库拖后腿我不会同步回写数据库而是采用“异步架构”。Redis 扣减成功后发送一条消息到消息队列MQ由后端服务消费消息慢慢地将最终的库存变动更新回数据库。这样数据库只承担持久化存储的功能不再承担高并发的实时扣减压力。最后为了进一步极致优化我会在应用层做“请求合并”*。 我可以在内存中维护一个队列每积攒 100 个请求或者每过 100 毫秒就把这一批扣减合并成一次数据库操作比如stock stock - N。这样能极大地减少网络 IO 和数据库交互次数。8. 介绍一下RabbitMQ和RocketMQ的不同点简单来说RabbitMQ 追求灵活性和标准性而 RocketMQ 追求高吞吐量和在复杂分布式场景下的稳定性。我会从三个主要维度来介绍它们的不同1、 基础架构与协议RabbitMQ:它是基于Erlang语言开发的默认使用AMQP协议这是一个国际标准。这种设计让 RabbitMQ 在处理复杂的路由规则时非常强大且灵活但在高并发下其 Erlang 运行时和协议的解析会有一定的性能开销。RocketMQ:它由阿里巴巴基于Java开发使用自定义的私有 TCP 协议。这种协议完全是为了高吞吐量而定制的并且整个架构引入了NameServer进行元数据管理Broker 节点可以轻松地进行水平扩展这是它应对大规模流量的基础。2、存储机制与性能这是两者最大的区别直接决定了性能上限。RabbitMQ:它的消息处理更依赖内存和标准的文件 I/O。当消息堆积时虽然会将消息落地到磁盘但磁盘 I/O 效率相对不高因此它不太擅长处理大规模的消息积压。它更适合低延迟、小消息量的场景。RocketMQ:它的核心设计是为了追求极致的性能和可靠性。它采用内存映射文件所有消息都以顺序追加的方式写入 CommitLog 文件并利用操作系统页缓存机制进行读写优化。这种设计让 RocketMQ 能够充分利用磁盘的顺序写优势因此在高并发、高吞吐和消息堆积的场景下表现极其出色。3、特性支持与业务场景于 RocketMQ 是为大规模电商交易场景设计的它提供了 RabbitMQ 缺失的关键特性事务消息:RocketMQ 原生支持分布式事务消息能够保证生产者发消息和本地事务的原子性这对于电商订单、支付等业务至关重要。RabbitMQ 需要依赖外部补偿机制或 TCC 模式实现。顺序消息:RocketMQ 可以保证一组消息比如同一订单的所有操作严格按照发送顺序进行消费这在处理业务逻辑强依赖时序的场景非常实用。延迟/定时消息RocketMQ 原生提供定时消息功能通过特定的延迟等级实现。如果需要复杂的路由逻辑或者要求使用AMQP 等标准协议进行跨平台集成我会选择RabbitMQ。但如果面对的是日均百亿级以上的高并发、大吞吐、需要事务性或顺序性的互联网场景RocketMQ则是更可靠、性能更高的选择。9. 如何本地实现事务消息首先要明确“本地事务消息” 并非标准的分布式事务解决方案如 2PC、TCC、Saga而是一种轻量级的、基于本地事务 消息队列的异步一致性方案。核心目标是在本地事务执行成功后确保消息可靠发送若本地事务失败消息不发送从而保证 “本地操作” 与 “消息发送” 的原子性避免数据不一致。其核心设计思想是“本地事务与消息存储在同一个数据库中利用数据库事务的原子性来保证消息的可靠性”。整个实现流程可以分解为以下三个关键步骤1、本地事务中的原子操作首先在应用服务内部我会启动一个本地数据库事务。在这个事务中我们执行两个操作业务数据修改比如扣减库存。插入发件箱记录向一张专门的Outbox表中插入一条记录。这条记录包含了需要发送的消息的所有信息如 Topic、Payload、状态。因为这两个操作处于同一个数据库事务中要么同时成功要么同时失败。这样就保证了业务数据变更和发送消息的意图在本地是原子性的。2、消息接力与转发本地事务提交成功后业务数据和待发送的消息记录都已经安全地持久化到了数据库中。接下来需要一个机制将这个“意图”转化为实际的消息发送轮询机制部署一个独立的 Relay 服务接力服务定期扫描Outbox表中状态为“待发送”的新记录。或者用阿里巴巴的 canal 组件它直接监控数据库的事务日志Binlog一旦发现Outbox表有新记录就立即捕获并通知 Relay 服务。Relay 服务获取到发件箱记录后负责将消息发送给实际的消息队列如 RabbitMQ 或 Kafka。3、状态更新与幂等性保证Relay 服务成功将消息发送到 MQ 后会回来更新Outbox表中对应记录的状态将其标记为“已发送”或直接删除。这里需要注意的是消息发送和更新Outbox状态这两个动作本身并不是一个事务。因此如果 Relay 服务发送成功了但在更新Outbox状态时失败了会导致消息被重复发送。所以事务发件箱模式对下游消费端有严格要求必须保证幂等性。消费者接收到消息后必须能够安全地处理重复的消息这是保证最终一致性的关键环节。通过这种模式我们把原本需要分布式协调的难题转化为了单个本地数据库事务的原子性和异步的消息接力从而实现了业务操作和消息发送的可靠一致性。10. 说一下你对分布式事务的理解在单体应用中我们靠本地事务来保证操作的 ACID。但在分布式环境中由于资源是隔离的一个操作可能需要在 A 服务扣库存B 服务创建订单这两步必须同时成功或失败。常见的分布式事务解决方案如下方案一致性性能复杂度适用场景2PC强一致性低中传统数据库、XA协议3PC强一致性中低高需减少阻塞的强一致场景TCC最终一致性高高高并发业务支付、库存Saga最终一致性中高长事务、跨服务流程消息队列最终一致性高中事件驱动架构本地消息表最终一致性中低异步通知订单-积分两阶段提交协议2PC为准备阶段和提交阶段。准备阶段协调者向参与者发送准备请求参与者执行事务操作并反馈结果。若所有参与者准备就绪协调者在提交阶段发送提交请求参与者执行提交否则发送回滚请求。实现简单能保证事务强一致性。存在单点故障协调者故障会影响事务流程性能低多次消息交互增加延迟资源锁导致资源长时间占用降低并发性能。适用于对数据一致性要求高、并发度低的场景如金融系统转账业务。三阶段提交协议3PC在 2PC 基础上将准备阶段拆分为询问阶段和准备阶段形成询问、准备和提交三个阶段。询问阶段协调者询问参与者能否执行事务后续阶段与 2PC 类似。降低参与者阻塞时间提高并发性能引入超时机制一定程度解决单点故障问题。无法完全避免数据不一致极端网络情况下可能出现部分提交部分回滚。用于对并发性能有要求、对数据一致性要求相对较低的场景。TCC将业务操作拆分为 Try、Confirm、Cancel 三个阶段。Try 阶段预留业务资源Confirm 阶段确认资源完成业务操作Cancel 阶段在失败时释放资源回滚操作。可根据业务场景定制开发性能较高减少资源占用时间。开发成本高需实现三个方法要处理异常和补偿逻辑实现复杂度大。适用于对性能要求高、业务逻辑复杂的场景如电商系统订单处理、库存管理。Saga将长事务拆分为多个短事务每个短事务有对应的补偿事务。某个短事务失败按相反顺序执行补偿事务回滚系统状态。性能较高短事务可并行执行减少时间对业务侵入性小只需实现补偿事务。只能保证最终一致性部分补偿事务失败可能导致系统状态不一致。适用于业务流程长、对数据一致性要求为最终一致性的场景如旅游系统订单、航班、酒店预订。可靠消息最终一致性方案基于消息队列业务系统执行本地事务时将业务操作封装成消息发至消息队列下游系统消费消息并执行操作失败则消息队列重试。实现简单对业务代码修改小系统耦合度低能保证数据最终一致性。消息队列可靠性和性能影响大可能出现消息丢失或延迟需处理消息幂等性。适用于对数据一致性要求为最终一致性、系统耦合度低的场景如电商订单支付、库存扣减。本地消息表业务与消息存储在同一个数据库利用本地事务保证一致性后台任务轮询消息表通过MQ通知下游服务下游服务消费成功后确认消息失败则重试。简单可靠无外部依赖。消息可能重复消费需幂等设计。适用场景是异步最终一致性如订单创建后通知积分服务。最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容最后1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段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 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】