用音视频内容社区场景拿下 Java 面试：Spring Boot + 微服务 + MQ + 缓存 + RAG 全流程实战

场景：互联网大厂音视频内容社区业务线 Java 后端面试

人物：

  • 严肃面试官：L 面试官
  • 搞笑水货程序员：小 Y（偶尔清醒，偶尔迷糊）

第一幕：基础功能与整体架构（第 1 轮提问）

业务背景： 公司在做一个「短视频 + 图文 UGC 社区」，类似抖音 + 小红书。用户可以发布短视频、图片笔记，进行点赞、评论、关注、私信。你应聘的是 内容服务后端 Java 工程师。

Round 1 · Q1：项目整体技术栈与分层设计

L 面试官：

我们先从整体说起。如果让你从零设计这个音视频内容社区的后端，你会用什么技术栈？整体架构大概怎么分层？

小 Y：

咳…这个我熟，我肯定用 Spring Boot 啊，然后分成 Controller、Service、DAO 三层，然后用 MySQL 存数据，Redis 做下缓存，差不多就能跑起来了。

L 面试官：

说得还行，但太粗了。有没有考虑微服务？网关？认证？调用链路？待会我们再聊细一点。

Round 1 · Q2：用户发布短视频的流程

L 面试官：

我们聚焦到一个最基础的功能：用户发布短视频。从用户在 App 上点击「发布」，到视频可以在首页瀑布流里看到，大致会经历哪些后端流程？涉及哪些服务？

小 Y：

嗯…这个流程就是：

  1. 用户上传视频到后端；
  2. 后端保存一下数据库；
  3. 然后直接在首页查出来就行了。

就是这么个流程，挺简单的。

L 面试官：

你说的是最朴素的版本。真实场景下会涉及 对象存储、转码、审核、Feed 流 等，细节我们放到后面的答案部分展开。

Round 1 · Q3：选择 Spring MVC 还是 Spring WebFlux？

L 面试官：

你来设计内容服务 API，如果有高并发上传/播放请求，你会用 Spring MVC 还是 Spring WebFlux？为什么？

小 Y：

这个…WebFlux 感觉比较先进，我看网上都说高并发用 WebFlux，所以我就用 WebFlux 吧…因为它是响应式的，性能高。

L 面试官：

结论不能算错，但理由太空。你要能说清楚 WebFlux 的优势边界，以及什么时候我们 宁愿用 Spring MVC + 线程池优化 而不是 WebFlux。

Round 1 · Q4：数据库与 ORM 选型

L 面试官：

内容服务里会有很多表：用户、作品、评论、点赞、关注关系等等。你在数据库和 ORM 上怎么选？比如 Hibernate、MyBatis、JPA、Spring Data 等。

小 Y：

我习惯用 MyBatis，写 SQL 更自由。然后配个 HikariCP 连接池就行。Hibernate 我觉得比较重。

L 面试官：

不错，这个点说到关键了：复杂查询场景下 MyBatis 优势。但也要知道 JPA、Spring Data 在一些 CRUD 场景可以提升效率。

Round 1 · Q5：基础日志与监控

L 面试官：

如果这个内容服务要上线生产环境，你会如何设计日志与监控？比如用哪些框架和组件？

小 Y：

日志就 Logback + SLF4J 呗，打到文件里，然后…监控的话，嗯…可以用 Prometheus 和 Grafana 吧，然后再搞个 ELK，搜日志会方便一点。

L 面试官：

这个回答可以，会用到 Logback/SLF4J + ELK + Prometheus + Grafana，后面我们再展开讲具体怎么接入。

第二幕：微服务、消息队列与缓存（第 2 轮提问）

业务背景升级： 平台日活快速增长，短视频与直播功能上线。发布量、播放量、互动量都上来了，需要扩展到 微服务架构，并引入 消息队列、缓存、搜索推荐。

Round 2 · Q1：微服务拆分与调用链路

L 面试官：

现在我们把系统拆成多个微服务，比如：用户服务、内容服务、评论服务、Feed 服务、推荐服务、搜索服务等等。你会用什么技术栈来做微服务？服务之间怎么发现与调用？

小 Y：

微服务肯定用 Spring Cloud 啊，然后用 OpenFeign 调接口，用 Eureka 做注册中心，还有个 Zuul 当网关。差不多就这一套 Netflix OSS 全家桶。

L 面试官：

嗯…Netflix OSS 是经典，但现在很多公司在用 Spring Cloud Alibaba 或者基于 Kubernetes 的服务发现，另外 Zuul 已经比较老了。说明你还停留在旧知识，需要补一下。

Round 2 · Q2：发布视频后的异步处理（消息队列）

L 面试官：

用户发一个视频，除了写数据库，还会触发：

  • 视频转码
  • 内容审核（涉黄涉政）
  • 生成多码率、多清晰度
  • 更新推荐系统、搜索索引

这些如果都在同步接口里做，会很慢。你会怎么设计？用什么 MQ？

小 Y：

那就用 Kafka 呗，现在大厂都用 Kafka。发布接口只写一条消息到 Kafka，然后后台有好几个消费者慢慢处理就行。反正 Kafka 特别能扛。

L 面试官：

大方向没问题，但你要考虑 顺序性、幂等、失败重试，还有一些场景 RabbitMQ/Redis Pub/Sub 也会用到。

Round 2 · Q3：热门视频列表的缓存设计

L 面试官：

首页瀑布流会有「热门视频列表」，QPS 非常高。如果你用 Redis 来做缓存，会怎么设计？如何避免缓存雪崩、击穿、穿透？

小 Y：

这个我知道：

  • 雪崩就把过期时间打散；
  • 击穿就加互斥锁；
  • 穿透就加个布隆过滤器。

然后热门列表放在 Redis 的 list 或者 sorted set 里，定时刷新就行。

L 面试官：

思路是对的，不过需要更完整的方案，比如 本地缓存 + 分布式缓存多级缓存，以及如何用 Caffeine/Hazelcast 提升性能。

Round 2 · Q4：Feed 流与去重

L 面试官：

用户关注了很多 UP 主，首页会看到「关注流」，同时还有一个「推荐流」。你怎么设计这个 Feed 流？如何保证用户不会在关注流里看到重复内容？

小 Y：

这个…可以给每个用户维护一个时间线，然后把关注的人发的内容都插进去，再按时间倒序查，然后…去重的话就，把 ID 放一个 set 里，查的时候判断一下。

L 面试官：

你说的是一个方向，但真正的 Feed 流，一般会结合 Redis、消息队列、甚至大数据平台的离线计算，而不仅仅是简单的 set 去重。

Round 2 · Q5：服务的稳定性与熔断限流

L 面试官：

如果推荐服务、搜索服务偶尔超时或者挂掉了，你的内容服务接口要怎么办？会不会一直卡死？你会怎么做熔断、限流、降级？

小 Y：

这个可以用 Resilience4j，或者以前的 Hystrix，做熔断和限流。比如说调用推荐服务失败，就走默认的热门列表。然后设置超时时间，超过就直接返回兜底数据。

L 面试官：

不错，至少知道要 熔断 + 降级策略。后面我们在答案里详细讲一个示例。

第三幕：安全、AI 与 RAG 智能客服（第 3 轮提问）

业务背景再升级： 平台计划上线「智能客服系统」，帮助用户解决「账户问题、内容违规申诉、创作者运营问题」等，并提供 企业文档问答、创作者规则查询 等能力，需要引入 大模型 + RAG + Agent 技术。

Round 3 · Q1：接口安全与用户隐私

L 面试官：

我们的内容社区会涉及用户隐私数据（手机号、聊天记录、提现信息等）。你准备如何保护 API 接口安全？比如认证、授权、Token、权限控制这块。

小 Y：

Spring Security 加 JWT 就可以了。用户登录以后，发一个 JWT，后面请求都带着。然后在接口上做权限注解，@PreAuthorize 之类的。要再高级一点就搞 Keycloak 单点登录。

L 面试官：

整体思路没问题，但你要了解 OAuth2 授权模式、Token 过期与刷新、以及如何与网关配合做统一认证。

Round 3 · Q2：智能客服系统的整体方案

L 面试官：

现在公司要做「智能客服系统」，支持：

  • 用户自然语言咨询：比如「为什么我的视频被限流？」
  • 创作者查询平台规则：比如「直播带货需要什么资质？」
  • 企业内部运营、风控同学查询内部文档

你会怎么设计整体架构？用到哪些 AI 技术点和组件？

小 Y：

这个…那就上大模型啊。比如调用 OpenAI 的接口，用户问什么就丢过去，让它直接回答。然后我们前面用 Spring Boot 搭个 HTTP 接口，转发一下就好了。

L 面试官：

如果只这样做，就会有严重的 AI 幻觉（Hallucination），而且无法回答企业内部文档问题。需要用到 RAG、向量数据库、文档加载等 技术。

Round 3 · Q3：RAG 检索增强生成怎么落地？

L 面试官：

具体一点，你能说说 RAG（检索增强生成）的基本流程吗？比如用 Milvus 或 Redis 作为向量数据库时，数据怎么走？

小 Y：

RAG…我大概知道：就是先向量化，再检索，然后把文档喂给大模型。向量数据库嘛，可以用 Milvus 或者 Redis 的那个…向量索引。我目前还没实战过。

L 面试官：

至少概念答到了，但要是你能把 Embedding 生成、语义检索、提示填充 每一步说清楚，就更好了。

Round 3 · Q4：聊天会话内存与 Agent 能力

L 面试官：

智能客服还要记住用户上下文，比如前后几轮的提问，并支持「办理退款」「修改收货地址」这类带有 工具调用 的复杂流程。你觉得要怎么设计？

小 Y：

这个…是不是就是在 Redis 里把历史聊天记录存一下？然后每次都带上前几条？至于工具调用，我知道有那种 Agent 框架，可以帮模型自动调用接口…但具体我还没研究。

L 面试官：

回答比较模糊，不过算是提到了关键点：

  • 聊天会话内存
  • 工具调用框架
  • Agent 执行工作流

Round 3 · Q5：整体上线与 CI/CD

L 面试官：

最后一个问题：整个内容社区后端 + 智能客服系统，在上线与运维方面，你会用什么 CI/CD、容器化、监控与追踪方案？

小 Y：

CI/CD 就 Jenkins 或 GitLab CI 搭个流水线，打包成 Docker 镜像，部署到 Kubernetes 上。监控的话 Prometheus + Grafana，日志用 ELK。链路追踪可以用 Zipkin 或 Jaeger。

L 面试官：

这块回答比较完整。

面试收尾

L 面试官：

今天就先到这里。你在一些基础和常见框架上的掌握还可以，但在 微服务演进、异步架构、RAG 与 Agent 等新技术 上还需要补课。我们会综合评估，你先回去等通知。

小 Y：

好…那我回去先把 RAG 好好学学。

标准答案与知识拆解（给小白看的详解）

下面是对上面问题的系统梳理，按业务场景 + 技术点来讲，给刚入门的同学一个完整的学习路径。

一、音视频内容社区的整体技术架构

1.1 基础技术栈
  • 语言与平台：Java 8/11 为主，JVM 调优视规模而定
  • Web 框架：Spring Boot + Spring MVC 为主；需要高并发长连接可用 WebFlux / WebSocket
  • 数据库与 ORM：
    • 关系型数据库：MySQL / PostgreSQL
    • ORM：MyBatis + Spring Data（CRUD 场景），连接池 HikariCP
    • 数据迁移：Flyway 或 Liquibase
  • 缓存：Redis 为主，可配合 Caffeine 做本地缓存
  • 消息队列：Kafka（高吞吐日志流、行为流）、RabbitMQ/Redis Pub/Sub（低延迟通知类）
  • 日志与监控：
    • 日志：SLF4J + Logback/Log4j2
    • 日志采集：Filebeat/Logstash -> Elasticsearch -> Kibana（ELK）
    • 指标：Micrometer -> Prometheus -> Grafana
    • 链路追踪：Zipkin 或 Jaeger
  • 容器与部署：Docker + Kubernetes（K8s），CI/CD 用 Jenkins / GitLab CI / GitHub Actions
1.2 典型分层
  1. API 层：
    • Spring MVC Controller
    • DTO、参数校验（Hibernate Validator）
  2. Service 层：
    • 业务逻辑、事务控制（Spring Transaction）
  3. Repository/DAO 层：
    • MyBatis Mapper 或 Spring Data Repository
  4. 基础组件层：
    • Redis 客户端（Lettuce）、MQ 客户端（Kafka/RabbitMQ）、对象存储 SDK
  5. 网关层（微服务阶段）：
    • Spring Cloud Gateway / Nginx / Ingress Controller

二、用户发布短视频的完整后端流程

2.1 业务流程拆解

用户在 App 上点击「发布短视频」，背后通常是：

  1. 上传媒体文件：
    • 客户端直传到对象存储（如阿里云 OSS、腾讯云 COS、Amazon S3）
    • 只把上传后的 URL/Key 回传给后端服务
  2. 调用后端发布接口：
    • 请求体包含：标题、描述、封面、媒体文件 Key、标签等
    • 后端只做必要的参数校验、权限校验
  3. 写入内容数据库：
    • 在 video 表中插入一条记录，状态为 PROCESSING
  4. 发送异步任务（关键）：
    • 往 Kafka 发送消息：video_uploaded
    • 消息内容包含视频 ID、文件 Key 等
  5. 异步处理服务消费：
    • 转码服务：多码率转码、截图、封面生成
    • 内容审核服务：涉黄涉政检测、过滤违规内容
    • Feed/推荐服务：更新用户 Feed、写入曝光候选池
    • 搜索服务：构建索引（Elasticsearch）
  6. 状态更新：
    • 当转码和审核通过后，把 video 状态更新为 PUBLISHED
  7. 用户可见：
    • 首页、个人主页、关注流中都可以看到
2.2 涉及到的技术组件
  • Spring Boot + Spring MVC 提供 REST 接口
  • 数据库：MySQL + MyBatis
  • 消息队列：Kafka（高吞吐异步事件）
  • 搜索：Elasticsearch（支撑搜索与复杂排序）
  • 审核服务可以接第三方 AI 审核平台

三、Spring MVC vs Spring WebFlux 的选择

3.1 Spring MVC
  • 模型：同步阻塞 I/O，一个请求占用一个线程
  • 特点：
    • 编程模型简单，生态成熟
    • 与大部分第三方库天然兼容（因为很多都是阻塞 API）
    • 对 CPU 密集、I/O 不是特别重的场景完全够用

适用场景：

  • 中等并发的 CRUD 系统、管理后台
  • 绝大部分业务服务
3.2 Spring WebFlux
  • 模型：基于 Reactor（响应式流），非阻塞 I/O
  • 特点：
    • 更适合高并发 I/O 密集型业务（如长轮询、WebSocket）
    • 对底层驱动和调用链要求比较高，要尽量避免阻塞调用

适用场景：

  • 大量长连接、推送、WebSocket
  • 需要极致资源利用率，且使用非阻塞驱动（如 R2DBC、WebClient）
3.3 实际建议

很多大厂的主业务接口仍然使用 Spring MVC，通过：

  • 合理配置线程池
  • 异步任务交给 MQ/线程池处理

来满足高并发。WebFlux 多用于网关层、特定服务，避免「全局响应式」带来的学习和维护成本。

四、数据库与 ORM 的选型

4.1 MyBatis 的优势
  • 手写 SQL，灵活性高，能精准利用索引
  • 复杂统计、联表、分页、分片等更直观
  • 配合 PageHelper、MyBatis-Plus 可提升开发效率

适合：

  • 复杂查询、多维度筛选
  • 性能要求高、SQL 需细粒度调优的场景
4.2 JPA / Hibernate / Spring Data
  • 通过实体与仓库接口快速生成 CRUD 逻辑
  • 开发效率高，但复杂查询可读性和性能可控性略差

适合：

  • 简单 CRUD、配置中心、小工具系统
4.3 连接池与迁移
  • 连接池：HikariCP（性能好，Spring Boot 默认）
  • 迁移工具：
    • Flyway：版本化 SQL 文件，启动时自动迁移
    • Liquibase：支持 XML/YAML/JSON 格式配置变更

五、日志、监控与调用链

5.1 日志
  • 日志门面：SLF4J
  • 实现：Logback / Log4j2
  • 最佳实践：
    • 按模块和级别拆分日志（info/error/slow）
    • 日志中统一打印 traceId、userId、请求关键参数
5.2 日志检索（ELK）
  • Filebeat/Logstash 收集日志文件
  • 写入 Elasticsearch
  • Kibana 检索、统计
5.3 指标与监控
  • Micrometer 作为指标抽象层
  • Prometheus 拉取指标
  • Grafana 展示 Dashboard
5.4 链路追踪
  • Spring Cloud Sleuth + Zipkin / Jaeger
  • 为每次请求生成 traceId + spanId，串联跨服务调用

六、微服务拆分与服务调用

6.1 常见拆分方式

以内容社区为例：

  • 用户服务（User Service）
  • 认证服务（Auth Service）
  • 内容服务（Content Service）
  • 评论服务（Comment Service）
  • 点赞/互动服务（Interaction Service）
  • Feed 服务（Feed Service）
  • 推荐服务（Recommend Service）
  • 搜索服务（Search Service）
  • 订单/支付服务（Order/Payment Service）
6.2 服务发现与调用
  • 在传统 Spring Cloud(Neflix OSS) 中：Eureka + Ribbon + Feign
  • 在 Kubernetes 时代：
    • 服务发现：K8s Service + DNS
    • 调用：gRPC / HTTP + OpenFeign

如今更推荐：

  • 使用 Spring Cloud 结合 Kubernetes，或直接使用 Kubernetes + Spring Boot，借助 K8s 的服务发现能力。

七、消息队列：Kafka/RabbitMQ/Redis 的使用场景

7.1 Kafka

适合：

  • 行为日志（播放、点赞、分享）
  • 埋点、统计、实时计算
  • 视频上传事件流、Feed 流构建

特点：

  • 高吞吐、高分区、顺序性可控
7.2 RabbitMQ

适合：

  • 可靠性要求高的业务消息（订单创建、支付回调）
  • 需要路由、延时队列、死信队列等高级特性
7.3 Redis Pub/Sub / Stream

适合：

  • 轻量级实时通知
  • 简单的消息分发
7.4 消费端通用设计
  • 保证 幂等：
    • 使用业务唯一键（如 videoId）去重
    • 处理前先检查记录是否已存在
  • 失败重试 + 死信队列
  • 顺序性要求高时按 key 分区

八、热门视频缓存设计与缓存三大问题

8.1 热门列表数据结构
  • Redis Sorted Set：zadd hot_videos score videoId
  • score 可以是：播放量 * a + 点赞数 * b + 评论数 * c

查询热门：

ZREVRANGE hot_videos 0 99
8.2 缓存雪崩、击穿、穿透
  1. 雪崩：大量 key 同时过期
    • 解决：过期时间加随机，或者使用永不过期 + 后台异步刷新
  2. 击穿：热点 key 过期时瞬间大量请求打到数据库
    • 解决：互斥锁（只让一个线程回源），或者使用逻辑过期
  3. 穿透：大量访问不存在的数据
    • 解决：布隆过滤器、缓存空值
8.3 多级缓存
  • 本地缓存：Caffeine
  • 分布式缓存：Redis
  • 结合：先查本地，再查 Redis，再回源 DB

九、Feed 流设计与去重

9.1 两种常见模型

  1. Push 模型：

    • 用户 A 关注了 1000 人，每个人发视频时，往 A 的时间线里 push 一条
    • 优点：读快
    • 缺点：写放大严重

  2. Pull 模型：

    • 查用户关注列表，按时间从这些用户的作品列表拉数据
    • 优点：写压力小
    • 缺点：读请求复杂

大厂常用「冷热分离 + 混合模型」。

9.2 去重思路
  • 关注流和推荐流：用 Redis Set / 布隆过滤器记录已曝光内容 ID
  • 生成新一页时过滤掉已展示过的 ID

十、熔断、限流与降级（Resilience4j）

  • 熔断：下游服务异常比例超过阈值时，临时「断开」，直接走 fallback
  • 限流：使用令牌桶/漏桶限制 QPS
  • 降级：下游不可用时返回兜底数据（如默认热门列表）

在 Spring Boot 中可通过 Resilience4j 注解实现：

@CircuitBreaker(name = "recommendService", fallbackMethod = "fallbackRecommend")
public List<Video> getRecommendFeed(Long userId) {
    return recommendClient.getFeed(userId);
}

public List<Video> fallbackRecommend(Long userId, Throwable t) {
    return contentService.getHotVideos();
}

十一、安全：Spring Security、JWT、OAuth2、Keycloak

11.1 认证与授权基本思路
  • 登录：用户名 + 密码 / 手机号 + 验证码
  • 后端校验后生成 JWT（含 userId、角色、过期时间）
  • 客户端保存 Token（通常在 Header：Authorization: Bearer xxx）
  • 每次请求网关/服务端校验 JWT
11.2 OAuth2 与单点登录
  • 使用 OAuth2/OpenID Connect 实现统一认证中心
  • Keycloak 是一个开箱即用的身份管理解决方案

十二、智能客服系统：RAG + Agent 实践

12.1 传统「直接调用大模型」的问题
  • 不懂公司内部业务规则
  • 容易胡编乱造（AI 幻觉）
  • 无法访问实时业务数据（订单状态、申诉记录）
12.2 RAG（检索增强生成）的完整流程
  1. 文档加载：
    • 导入平台规则、帮助中心、内部 SOP 文档（PDF、Word、网页等）
  2. 分块（Chunking）：
    • 按段落/小节拆分为较小文本块（几百字）
  3. 向量化（Embedding）：
    • 用 OpenAI / Ollama 等 Embedding 模型将每个文本块转成向量
  4. 存入向量数据库：
    • 选择 Milvus/Chroma/Redis Vector 等
  5. 在线问答流程：
    1. 用户问题 -> 向量化
    2. 在向量库中做语义检索，找到最相关的若干文档块
    3. 把这些文档 + 用户问题组成 Prompt（提示填充）
    4. 发送给大模型，让模型在这些文档范围内作答

这样模型的回答有「依据」，大幅减少幻觉。

12.3 Agent 与工具调用

为了支持「修改收货地址」「办理退款」等操作，需要：

  • 定义一批「工具」：如查询订单、修改订单、查询余额等 API
  • 使用 工具调用框架（如 Spring AI 自定义、LangChain4j 等）
  • 让大模型根据对话上下文决定：
    • 要不要调用某个工具
    • 以什么参数调用
  • 工具执行后把结果再反馈给模型，让模型把结果用自然语言告诉用户

这就是一个简单的 Agent：

  • 能理解用户意图
  • 能选择合适的工具
  • 能组合多个步骤完成任务（复杂工作流）
12.4 聊天会话内存
  • 把前几轮对话摘要/关键字段存储：
    • Redis
    • 数据库
    • 或专门的会话存储组件
  • 每次问答构造 Prompt 时带上必要的历史信息，实现「有记忆的对话」。

十三、CI/CD 与运维落地

13.1 CI/CD 流程
  1. 开发提交代码到 Git（GitLab/GitHub）
  2. 触发 GitLab CI/Jenkins Pipeline
  3. 步骤：
    • 编译（Maven/Gradle）
    • 单元测试（JUnit5 + Mockito + AssertJ）
    • 打包 Docker 镜像
    • 推送到镜像仓库
    • 部署到 Kubernetes（kubectl / Helm / Argo CD）
13.2 运行时观测
  • Prometheus + Grafana：监控 QPS、延迟、错误率
  • ELK：日志检索
  • Jaeger/Zipkin：链路追踪，定位跨服务性能瓶颈

十四、给小白的一条学习路径建议

  1. 扎实掌握：Java SE + JVM 基础
  2. Spring Boot + Spring MVC + MyBatis/Redis 基本 CRUD
  3. 熟悉：Kafka、MySQL 索引、Redis 缓存三大问题
  4. 慢慢过渡到微服务：Spring Cloud、服务拆分、熔断限流
  5. 学会：日志监控体系（ELK + Prometheus + Grafana）
  6. 最后补充：RAG、向量数据库、Agent 等 AI 技术

可以拿本文的内容当成一个「知识地图」，逐个点位去补齐，就不会像小 Y 一样，在关键问题上含糊其辞了。

# 微服务 # RAG
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

【工具实测】比较研究：国内主流 AI 写作降重工具的技术路线与适用场景分析

avatar AtomGit开源社区
cover

消AI痕迹降重两不误！6款好用免费AI论文工具推荐

avatar AtomGit开源社区

消AI痕迹降重两不误！6款好用免费AI论文工具推荐

用AI写论文怕被检测？还在为重复率、AI率过高发愁？SpeedAI科研小助手是北航团队研发的学术辅助工具，适配知网、维普、万方等国内主流检测平台，智能降重保留专业度，消AI痕迹贴近真人写作质感，支持上传Word一键处理保留原格式，还可针对检测报告标红段落精准改写，实测知网AIGC率可从80%降至2%，新用户注册免费送额度，付费低至1.2元/千字，轻松搞定论文修改。

avatar AtomGit开源社区