大厂 Java 面试实录：从音视频内容社区到 AI RAG 与微服务实战

场景：互联网大厂音视频内容社区部门面试现场。严肃的面试官 vs 搞笑的“水货”程序员小 Y，一边“社死”，一边帮你把核心技术点串成体系。

一、人物与业务背景

  • 公司业务线：音视频内容社区 + AIGC 推荐与创作工具
  • 端到端链路：
    • 用户拍摄/上传视频 → 内容审核 → 编码转码 → 内容分发 → 推荐与搜索 → 互动（点赞、评论、弹幕、打赏）
    • 后台有 微服务架构，使用 Spring Cloud + Kubernetes + Kafka + Redis + Elasticsearch + MySQL + Docker + ELK + Prometheus/Grafana 等
    • 最新一条业务线：基于 RAG 的 AI 内容助手 / 智能客服

主角登场：

  • 面试官（I）：技术架构负责人，讲话一针见血，略带冷幽默
  • 小 Y（Y）：嘴上说“音视频、AI 都会一点点”，实际项目经验略显稚嫩

二、第一轮：内容上传与基础服务（3 个问题）

场景：用户上传短视频，后端需要完成鉴权、元数据存储、基础业务处理。

Q1：登录鉴权与接口设计（Spring Boot + Spring Security + JWT）

I：

假设我们的内容社区 App，用户登录后通过 Token 访问上传接口。你怎么基于 Spring Boot + Spring Security + JWT 来设计这个登录和鉴权流程？简单描述下整体流程，以及接口大概怎么设计。

Y（比较有底气）：

这个我会！

  • 登录接口 /api/auth/login 用用户名密码校验
  • 校验成功后生成一个 JWT 返回给前端
  • 前端后续请求都带上 Authorization: Bearer xxx
  • 后端写一个过滤器，从 Header 里解析 JWT，校验通过就放行
  • Spring Security 配一下哪些接口要鉴权，哪些不需要，比如登录和注册放行

大概就这样。

I（点头）：

还不错。要是你能说清楚 JWT 里存什么、如何避免被伪造、如何续期 会更好。

Q2：视频上传接口与大文件处理（Spring MVC / WebFlux，分片上传）

I：

用户上传的是几十 MB 的短视频，甚至几百 MB 的长视频。如果你用 Spring Boot 写上传接口，怎么设计才能支持大文件、断点续传、以及基础的限流？

Y（开始有点虚）：

嗯……就是用 MultipartFile 呗，然后……可以分片上传，每一片传上来我就存一下，最后再合并成一个文件。

限流的话，可以搞个拦截器，控制一下请求频率……具体实现我还没来得及研究，非常多公司都这么做的……

I（眉头微皱）：

好，思路大致对，但对 分片标识、幂等、失败重传、存储位置 这些，你还要补补。

Q3：元数据存储与 ORM（MyBatis / JPA / Spring Data）

I：

视频文件本身进了对象存储（比如 S3、OSS、HDFS），但业务系统要存“视频元数据”，比如标题、封面、时长、所属用户、状态等。你会怎么设计表结构？用 MyBatis 或 JPA 的话，代码层面大致怎么组织？

Y（勉强 hold 住）：

表的话，大概：

CREATE TABLE video (
  id BIGINT PRIMARY KEY,
  user_id BIGINT,
  title VARCHAR(255),
  cover_url VARCHAR(500),
  video_url VARCHAR(500),
  duration INT,
  status TINYINT,
  created_at DATETIME,
  updated_at DATETIME
);

MyBatis 的话，我会写一个 VideoMapper，里面有 insertVideo, selectById 之类，然后对应一个 Video 实体类。JPA 的话就是 @Entity，用 CrudRepository 那套。

I（稍微缓和）：

还可以。表设计算及格，但没提到 索引、冷热数据、分库分表。不过对于初级岗位来说，这个答得还能看。

三、第二轮：推荐流与系统扩展（4 个问题）

场景：用户在首页刷短视频推荐流，需要高性能、低延迟的推荐与互动能力。

Q4：推荐流接口与缓存（Redis + Spring Cache + MyBatis）

I：

首页推荐流：用户打开 App，会请求 /api/feed/stream，返回一个视频列表。我们假设推荐结果已经由推荐系统算好放在 Redis 里。你后端服务用 Spring Boot + Redis + MyBatis 来查和返回这批视频详情，你会怎么设计？

Y（略显得意）：

这个我在项目上“做过类似的”。

  • 推荐系统把每个用户的推荐视频 ID 列表放在 Redis，比如 feed:userId
  • 我们接口里先去 Redis 拿这个列表，然后再用 MyBatis 根据这些 ID 查询视频详情
  • 为了减轻 DB 压力，还可以把视频详情本身也缓存到 Redis，以视频 ID 为 Key……
  • Spring Cache 可以在 getVideoById 上加 @Cacheable

差不多这样。

I：

思路没问题。但你没提如何避免 缓存击穿/雪崩/穿透。后面可以再深入。

Q5：消息队列处理用户行为（Kafka / Spring Cloud Stream）

I：

用户在推荐流里不断刷视频，会产生大量行为日志：曝光、点击、播放、点赞、评论等。这些数据会用于后续推荐和风控。我们会用 Kafka 做行为日志采集。请你描述一下：前端埋点 → 网关 → Kafka → 下游消费 的大概流程，后端 Java 服务在里面干什么？

Y（开始糊）：

呃……前端埋点会把这些事件打到我们的服务器，然后我们 Java 服务收到之后，就发到 Kafka 的 Topic 里……然后别的服务再从 Kafka 里消费，落库或者做推荐……

至于 Spring Cloud Stream 或者怎么配置 Topic、分区啊，这块……嗯，我觉得我学一下就会……

I（沉默两秒）：

至少你说对了“用 Kafka 解耦和削峰”。但 事件 schema、幂等、顺序性、多消费者组 这些关键点你都略过了。

Q6：服务拆分与 Spring Cloud（微服务网关 + 注册发现）

I：

我们推荐流后端是典型微服务：用户服务、视频服务、推荐服务、社交关系服务等等，用了 Spring Cloud。你能说说 服务注册发现 + 统一网关 的整体架构吗？比如：

  • 用什么做注册中心
  • 网关负责什么
  • 服务间调用用什么技术

Y（开始念概念）：

嗯注册中心可以用 Eureka，也可以用 Consul、Nacos。网关的话可以用 Spring Cloud Gateway 或者 Zuul……

网关负责统一入口、路由、鉴权、限流、灰度发布啥的。服务之间可以用 OpenFeign 调用，也可以 RestTemplate，或者 gRPC 那个……

具体我们公司的话，其实我之前用得不太多，都是现成的框架搭好的，我写业务就行。

I（叹气）：

概念背得还行，但缺乏 真实排障经验，比如“服务掉线、注册中心雪崩、网关转发超时”时你怎么排查。

Q7：日志与监控（ELK + Prometheus + Grafana + Zipkin）

I：

你刚才提到很多服务。大厂的一个现实问题是：线上出了问题怎么查？比如用户刷推荐流突然很卡、500 错误暴增。我们用 ELK + Prometheus + Grafana + 链路追踪。你熟悉哪一块？简单说一下你以前是怎么排查问题的？

Y（有点心虚）：

嗯……我们以前有 ELK，可以在 Kibana 里搜日志关键字；还有那个监控图，可以看到 QPS 和错误率……

一般我就是先上 Kibana 搜用户 ID，看日志里有没有报错栈，再不行就看监控有没有报警图形波动，最后再……重启一下试试？

I（扶额）：

至少你承认了会“重启大法”。不过在我们这边，日志规范、TraceId 贯通、指标维度设计 都是必备能力。

四、第三轮：AI 智能助手与 RAG 场景（5 个问题）

场景：公司上线了一个 AI 智能内容助手，帮创作者写标题、生成脚本，还能做企业文档问答、在线客服等。后端使用 Java + Spring Boot + Spring AI，结合向量数据库做 RAG 检索增强生成，并实现简单的 Agent 工作流。

Q8：RAG 基本流程（Spring AI + 向量数据库 Milvus/Redis）

I：

现在我们有一个“AI 内容助手”，用户输入“帮我写一个关于校园恋爱的小短剧脚本”。后端要：

  1. 从我们内容库（以前的爆款脚本）里检索相似案例
  2. 把检索到的内容和用户问题一起发给大模型
  3. 返回生成结果

这就是典型的 RAG（检索增强生成）。你能用自己的话描述一下这个流程，以及 Java 这边大概要用到哪些组件吗？比如 Spring AI、向量数据库之类的。

Y（明显进入“半懂”状态）：

嗯，RAG 我了解一点点，大概就是先检索再生成……

  • 文档要先向量化，存到 Milvus 或者 Redis 里
  • 用户问问题的时候，也做向量，然后算相似度，取 TopN 的文档
  • 再把这些文档和问题一起发给大模型，就能减少幻觉……

至于 Spring AI，我知道是一个方便调用大模型的框架，可以封装 OpenAI 之类的；向量数据库连接的话我还没自己写过 demo，只看过别人代码。

I：

流程描述还算到位，但你没有落地到 具体 Java 代码层面，比如 Embedding 调用、向量查询、Prompt 模板管理等。

Q9：AI 幻觉与企业文档问答（Hallucination + 语义检索）

I：

我们做企业文档问答时，最大的问题是 AI 幻觉：明明知识库里没有的内容，模型却一本正经地瞎编。你觉得在工程上可以用哪些手段去缓解？（不限于 Java 技术，可以从整体架构谈）

Y（开始飘）：

嗯……这个嘛，其实大模型本身就会幻觉，我们也没法完全解决……

降低的话就是 RAG，多检索一些文档给它看，或者让它自己说“我不知道”；再就是提示词写严一点，比如说“如果不知道就说不知道”。

具体怎么评估幻觉，我觉得要做很多 A/B 测试……

I：

回答得比较概括，但还不算错。缺点是缺乏 量化指标与回溯机制 的认识，比如：检索命中率、参考文档可解释性、答案附带引用链接等。

Q10：Agent 与工具调用（Agentic RAG + 工具执行框架）

I：

我们下一步要做“智能运营小助手”：

  • 能理解运营同学的自然语言指令
  • 自动调用内部工具，例如：查某个视频数据、生成并发布一条运营公告、查询某个创作者的结算情况

这其实是一个 Agent + 工具调用 的场景。你能说说你对 Agent 的理解吗？在 Java 这边，大致会怎么设计？

Y（话开始绕圈）：

Agent 我理解就是一个比较智能的机器人（？），它能根据当前的任务自己决定下一步做什么，会调用工具啊什么的，完成一个工作流……

Java 那边的话，可以封装一些工具接口，比如查询服务、下单服务，然后给到大模型使用……再结合 Spring AI 或者类似框架，让模型根据意图去调用这些工具……

具体怎么做，我还没实战过，不过我看一些文章讲得挺清楚的……

I（面无表情）：

概念上你没跑偏，但还是不够工程化，比如 安全边界、幂等和审计日志 都非常关键。

Q11：聊天会话内存与上下文管理（会话记忆 + Redis）

I：

智能助手和用户是一段持续对话，需要“记住”上下文，比如前几轮聊过的话题、用户偏好。你觉得在后端要怎么实现这种会话记忆？你会用什么存储，怎么设计 Key？

Y（继续模糊）：

嗯……可以把对话历史存 Redis，用用户 ID 或者会话 ID 做 Key，比如 chat:sessionId。

每次用户发消息就 append 到一个列表里，然后取最近几条发给模型做上下文……

具体要保留多少、怎么裁剪，我觉得可以根据业务调调参数……

I：

至少这个想法很接地气，Redis 存会话是常用方案。但你没提到 数据隐私、脱敏、上下文长度控制、过期策略 等问题。

Q12：容器化与发布（Docker + Kubernetes + GitLab CI/CD）

I：

不管是内容服务还是 AI 服务，最后都要上线。我们这边是 Docker + Kubernetes，配合 GitLab CI/CD。你之前项目中有实际发版经验吗？简单说说你对这套流程的理解，哪怕是只参与过一部分。

Y（略显诚实）：

发版都是运维同学搞的，我只会在本地用 Docker 跑一下……

GitLab CI/CD 我知道是写 .gitlab-ci.yml，然后 push 之后自动构建镜像，推到镜像仓库，然后部署到 K8s……

但我没有自己写过完整的配置，更多就是改一点变量，重试一下 pipeline。

I（合上电脑）：

好。今天差不多聊到这儿吧。

五、结尾：面试官总结与“回家等通知”

I：

这样，小 Y，你的 Java 基础还可以，对 Spring Boot、Redis、Kafka 这些有一定了解，但在 工程经验、排障能力、AI 实战落地 上比较薄弱。

我们这边还有一些候选人要面，后面会综合评估。你先回去等通知吧，有结果我们会尽快反馈。

Y（苦笑）：

好的……我回去一定好好学 RAG 和 Kubernetes……

六、知识点总结与详细解析（面试题答案精讲）

下面按问题顺序，把涉及的业务场景和技术点系统梳理一遍，方便新手学习。

1. 登录鉴权与 JWT（对应 Q1）

业务场景：

  • 用户打开 App，登录后才能上传视频、点赞、评论等，需要 无状态、高性能 的鉴权机制。

技术点：

  1. Spring Security 基本思路：

    • 定义登录接口 /api/auth/login，使用自定义的 UserDetailsService 根据用户名查询用户信息。
    • 登录成功后，生成 JWT，返回给前端。
    • 在后续请求中，通过 Filter 或 OncePerRequestFilter 从 Header 中解析 JWT，构造 Authentication 注入 SecurityContext。

  2. JWT 的结构：

    • Header.Payload.Signature 三段：
      • Header：算法、类型
      • Payload：用户 ID、角色、过期时间等
      • Signature：使用服务端密钥对前两段签名，防止被篡改

  3. 避免伪造与过期控制：

    • 使用足够复杂的签名密钥，存放在安全的配置中心
    • 设置合理的过期时间，如 30 分钟 + 刷新 Token 机制
    • 可以设计 Refresh Token，用于静默续期

简单接口示例：

@PostMapping("/api/auth/login")
public LoginResponse login(@RequestBody LoginRequest request) {
    User user = userService.authenticate(request.getUsername(), request.getPassword());
    String token = jwtService.generateToken(user);
    return new LoginResponse(token, user.getId());
}

2. 大文件与分片上传（对应 Q2）

业务场景：

  • 音视频平台上传动辄几十 MB，网络不稳定时需要 断点续传、失败重传、限流。

典型方案：

  1. 分片上传：

    • 前端将文件切成多个 Chunk，每个 Chunk 携带：fileId、chunkIndex、totalChunks 等信息。
    • 后端接口如：POST /api/upload/chunk。
    • 每个分片先写到临时存储（本地磁盘或对象存储的临时路径），记录已上传分片。

  2. 分片合并：

    • 前端上传完所有分片后，调用 POST /api/upload/merge。
    • 后端根据 fileId 检查所有分片齐全，再合并成完整文件，生成最终视频 URL。

  3. 幂等与失败重传：

    • 通过 fileId + chunkIndex 唯一标记某个分片，重复上传时可以直接返回“已存在”。
    • 使用数据库或 Redis 记录上传进度。

  4. 限流：

    • 在网关层使用 令牌桶/漏桶算法 对上传接口限流。
    • Spring Cloud Gateway + Redis RateLimiter 是常见组合。

3. 视频元数据与 ORM（对应 Q3）

业务场景：

  • 视频文件存对象存储，业务系统需要管理视频信息、状态流转（上传中 → 转码中 → 审核中 → 已发布）。

表设计要点：

  • 基本字段：user_id, title, cover_url, video_url, duration, status, created_at, updated_at。
  • 推荐增加：
    • category_id / 标签信息，方便推荐与检索
    • like_count, comment_count, play_count（也可以分离到统计表）
    • 索引：user_id、status + created_at 等组合索引

ORM 选择：

  • MyBatis：SQL 可控，适合复杂查询、分库分表。
  • JPA / Spring Data JPA：开发效率高，适合中小型服务快速开发。

示例实体（JPA）：

@Entity
@Table(name = "video")
public class Video {
    @Id
    private Long id;
    private Long userId;
    private String title;
    private String coverUrl;
    private String videoUrl;
    private Integer duration;
    private Integer status;
    private LocalDateTime createdAt;
    private LocalDateTime updatedAt;
}

4. 推荐流与 Redis 缓存（对应 Q4）

业务场景：

  • 首页推荐流 QPS 很高，频繁查 DB 会扛不住，需要用 Redis 做“推荐结果缓存 + 视频详情缓存”。

典型设计：

  1. 用户推荐列表缓存：

    • Key：feed:userId，Value：有序列表或 List，存视频 ID。
    • 推荐系统离线/实时计算后，写入该 Key。

  2. 视频详情缓存：

    • Key：video:{videoId}，Value：视频详情 JSON。
    • 可以通过 Spring Cache：
@Cacheable(cacheNames = "video", key = "#videoId")
public VideoDTO getVideoById(Long videoId) {
    return videoMapper.selectById(videoId);
}
  1. 缓存问题：
    • 穿透：对不存在的数据，加布隆过滤器或缓存空值。
    • 击穿：对热点 Key 加互斥锁，避免同一时间大量请求打到 DB。
    • 雪崩：设置随机过期时间，避免同一时间大量 Key 同时失效。

5. 用户行为日志与 Kafka（对应 Q5）

业务场景：

  • 用户刷视频时的曝光、点击、播放、点赞、分享等行为需要作为推荐、风控和数据分析的基础。

链路拆解：

  1. 前端埋点：

    • 每次行为生成一个事件：eventType, userId, videoId, timestamp, deviceInfo 等。

  2. 日志网关：

    • 收到埋点数据，做基本校验与限流。
    • 将事件写入 Kafka 的 Topic，如 user_behavior_log。

  3. 后端 Java 服务：

    • 使用 Spring Kafka / Spring Cloud Stream 创建消费者。
    • 消费后做：
      • 落库（Hadoop/Hive/ClickHouse）
      • 写实时计算系统（Flink/Spark Streaming）
      • 实时特征更新，供推荐系统使用

  4. 设计重点：

    • Topic 和分区策略：按 userId 或 videoId 进行分区，保证某个Key 的事件有序。
    • 幂等：消费重复消息时不产生重复计算，可用主键、去重表或幂等写入机制。

6. 微服务架构与 Spring Cloud（对应 Q6）

业务场景：

  • 用户、视频、推荐、关系、计费等服务独立部署，需要互相调用，还要统一对外入口。

典型架构：

  1. 注册中心：

    • Eureka / Consul / Nacos
    • 各微服务启动时向注册中心注册自身地址与健康状态。

  2. 网关：

    • Spring Cloud Gateway 或 Zuul
    • 负责：路由转发、统一鉴权、限流、灰度发布、Header 注入（如 TraceId）。

  3. 服务间调用：

    • OpenFeign：声明式 HTTP 客户端，支持负载均衡、熔断（搭配 Resilience4j）。
    • gRPC：在高性能、强类型需求场景使用（比如实时通信、游戏后台）。

  4. 常见问题：

    • 服务雪崩：需要熔断、限流、隔离。
    • 注册中心不可用：准备多副本 + 自我保护机制。

7. 日志与监控体系（对应 Q7）

业务场景：

  • 线上问题必须能快速定位：是网络问题？依赖服务挂了？还是某个版本 Bug？

常用技术栈：

  1. 日志：ELK / EFK

    • Logstash/Fluentd 收集 → Elasticsearch 存储 → Kibana 查询。
    • 要求日志格式统一，包含 TraceId、UserId、接口名等维度。

  2. 指标监控：Prometheus + Grafana

    • Micrometer 集成 Prometheus 对接 Spring Boot 指标：QPS、RT、错误率、JVM 指标等。
    • Grafana 做可视化和告警。

  3. 链路追踪：Zipkin / Jaeger

    • 为每个请求生成 TraceId 和 SpanId。
    • 可视化查看一个请求在多个微服务间的调用链和耗时分布。

8. RAG 检索增强生成（对应 Q8）

业务场景：

  • AI 内容助手：基于历史爆款脚本和运营经验给创作者写脚本、改标题。

完整流程：

  1. 文档加载与切分：

    • 从 MySQL、Elasticsearch、文件系统加载历史内容。
    • 使用文本切分策略（按段落、按字数、按语义）切成 Chunk。

  2. 向量化（Embedding）：

    • 使用 OpenAI、Ollama 等 Embedding 模型生成向量。
    • 存入向量数据库：Milvus / Chroma / Redis Vector。

  3. 在线查询：

    • 用户提问 → 生成 Query 向量 → 向量检索获取相似文档 TopN。

  4. 提示填充（Prompt Filling）：

    • 将检索文档 + 用户问题填入模板：
你是一个资深短视频编剧，请根据【参考脚本】和【用户需求】生成一个脚本。

【参考脚本】
{{retrieved_docs}}

【用户需求】
{{user_query}}
  1. 调用大模型：
    • 使用 Spring AI 封装模型调用，返回结果给前端。

9. AI 幻觉与企业文档问答（对应 Q9）

业务场景：

  • 企业内知识库问答：财务制度、品牌规范、技术方案等。不能乱答，否则后果严重。

缓解幻觉的工程手段：

  1. 提升检索质量：

    • 语义检索 + 关键字检索混合。
    • 对检索结果做阈值过滤（相似度低于阈值则认为“没找到”）。

  2. 答案附带引用：

    • 模型回答时附上参考文档标题与链接，让用户自行校验。

  3. 提示工程：

    • 让模型在不知道时直接回答“不知道”。
    • 要求模型在回答时引用原文，避免臆造规则。

  4. 质检与反馈闭环：

    • 收集用户“踩/赞”反馈。
    • 把有问题的问答记录入库，人工标注后重新训练或调整检索策略。

10. Agent 与工具调用（对应 Q10）

业务场景：

  • 智能运营助手：根据自然语言调用内部系统完成复杂任务，比如“帮我拉取上周 Top10 视频的播放数据并生成一条运营公告草稿”。

Agent 的关键点：

  1. 工具描述：

    • 用标准格式（如 OpenAI Function Calling、MCP 协议）描述工具：名称、参数、返回值。

  2. 决策与规划：

    • 模型根据用户意图制定步骤：先查数据 → 再生成文案 → 再发起审批。

  3. 安全边界：

    • 严格限制可调用的工具和参数范围。
    • 所有执行必须可审计：记录调用时间、参数、结果、发起人。

  4. Java 实现思路：

    • 定义工具接口（Service），用注解或配置暴露给 Agent 框架。
    • 收到模型的“工具调用请求”后，由后端执行实际逻辑，再把结果回传给模型继续对话。

11. 会话内存与上下文（对应 Q11）

业务场景：

  • AI 助手需要“记住”用户之前的问答，才能连续对话，不然每次都从头解释。

实现方案：

  1. 会话 ID 设计：

    • 可以是 userId，也可以是 sessionId（每开启一次新会话生成）。

  2. 存储介质：

    • Redis：读写快，适合在线上下文。
    • 长期历史可以落 MySQL / Elasticsearch 方便审计和搜索。

  3. 上下文裁剪：

    • 只保留最近 N 轮对话（如 10 条），避免上下文过长导致成本高和模型失效。
    • 按 Token 数控制，而不是按条数。

  4. 隐私保护：

    • 对敏感字段（手机号、身份证）做脱敏或不存储。
    • 为企业版提供会话导出和删除能力，符合合规要求。

12. Docker + Kubernetes + CI/CD（对应 Q12）

业务场景：

  • 大厂日常：每天下多次版本，服务要能 快速构建、灰度发布、回滚。

端到端流程：

  1. 提交代码：

    • 开发者 Git 提交到 GitLab，触发 CI Pipeline。

  2. CI 阶段：

    • 运行单元测试（JUnit5/TestNG + Mockito 等）。
    • 使用 Maven/Gradle 构建 Jar。
    • 构建 Docker 镜像，打上版本号和 Git commit ID。
    • 推送到镜像仓库（Harbor/阿里云/私有 Registry）。

  3. CD 阶段：

    • 使用 Helm 或 Kubernetes YAML 部署到 K8s 集群。
    • 先灰度发布到一部分 Pod，监控指标正常再全量发布。

  4. 回滚机制：

    • 保存上一个版本的镜像和配置，一键回滚。

七、给小白的学习建议

  1. 打牢 Java 与 Spring Boot 基础：

    • 熟练使用 Spring MVC、Spring Data、Spring Security。

  2. 补齐工程化能力：

    • Redis、MySQL 调优、Kafka、ELK、Docker/K8s 至少要有一次从 0 到 1 的实践。

  3. 理解至少一个业务场景端到端：

    • 例如本文的“音视频内容社区”：从上传、审核、推荐、互动到监控与发布。

  4. 跟上 AI 与 RAG 的趋势：

    • 用 Java + Spring AI 做一个简单的 RAG Demo：文档问答或智能客服。

把这些点真正做过一遍，再去大厂面试，你就不会像小 Y 一样“嘴上都懂，手上不会”了。

# 微服务
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

基于STM32的全屋环境智能监测与预警终端设计

avatar 亚马逊云科技技术品牌专区

Keras：面向人类的深度学习库

Keras3支持多后端（TensorFlow、PyTorch、JAX），通过设置环境变量切换，兼容指定版本。pip安装后可用Sequential API快速构建CNN模型，如MNIST分类示例，实

avatar 亚马逊云科技技术品牌专区

AI行业日报｜2026-09-25：5个热点事件

本期行业动态聚焦于端侧算力重构、自主智能体工作流、开发工具经济模型、网络隔离架构设计与公共部门合规审查。以下结合一线技术场景进行结构化梳理，供 AI 研究员与软件工程团队参考。 PrismML 正将其轻量级语言模型适配至搭载高通处理器的智能眼镜终端 1 。该平台的核心战略指向开源权重模型的本地化运行，旨在最大化挖掘穿戴设备现有算力的利用效率 1 。对于嵌入式与边缘计算开发者而言，此类微型模型向低功

avatar 亚马逊云科技技术品牌专区