内容社区与AIGC场景下的大厂 Java 面试：从增赞接口到AI智能客服（附详细解析）

场景：某头部内容社区（含UGC+短视频+AIGC创作平台）招聘 Java 后端开发工程师。 角色：

  • 面试官 M：技术严谨，追问犀利，但会适当引导。
  • 候选人 小Y：有点水，简单题还行，复杂题开始打太极。

面试共 3 轮，每轮 3~5 个问题，围绕同一业务线循序渐进：

  1. 内容点赞与基础接口
  2. 推荐与互动微服务化
  3. AIGC + AI 智能客服场景

文章最后有 所有问题的标准详解，适合小白系统学习。

一、第一轮：内容点赞与基础接口（3问）

业务背景：用户在内容社区给图文/短视频点赞、取消赞、查看点赞数。

Q1：简单点赞接口怎么设计？（Java + Spring Boot + 基础持久化）

M： 我们有一张 content 表，一条内容一个 id，用户可以点赞/取消赞。用 Java + Spring Boot 设计下点赞接口，包括：

  • Controller 方法大概长什么样？
  • Service 里会怎么写？
  • 数据库可能用什么技术？

小Y： 嗯……就是写个 @RestController，里面 @PostMapping("/like")，传 contentId 和 userId，然后 Service 里调个 DAO 存一下。数据库嘛，就 MySQL 啦，随便用个 JPA 或 MyBatis 都行。

M： 还不错，思路是对的，虽然有点“随便”。 那如果要防止一个用户对同一内容重复点赞，你会怎么设计表和代码？

小Y： 这个嘛……可以在代码里先查一查有没有点过，没有就插入，有就忽略？

M： 行，但要注意并发时可能有问题，待会儿我们展开。

Q2：如何用 Redis 提升点赞接口性能？（缓存 + 防击穿）

M： 点赞是高频操作，如果都打到数据库上，扛不住。你会怎么用 Redis 做优化？注意：

  • 如何存储点赞计数？
  • 如何避免缓存击穿？

小Y： 嗯……可以在 Redis 里用个 key 存点赞数，比如 like:count:contentId，每次点赞就 INCR 一下。缓存击穿……我记得是加个随机过期时间啥的？

M： 有点印象，但不完整。还不错，待会儿我给你一个完整方案。

Q3：并发点赞如何保证不重复？（MySQL + 唯一约束 + 分布式锁）

M： 假设一个用户猛点点赞按钮，前端又没做好防重复，我们后端要保证：

  • 同一 userId + contentId 最终只能算一次点赞。 你会在 表结构 和 代码 上怎么设计？可以提到：
  • 唯一索引？
  • 分布式锁？

小Y： 表结构的话就加个唯一键吧 (user_id, content_id)，插入时重复就报错。代码里就 try-catch 一下异常，如果是唯一键冲突就忽略。 锁的话……可以用 Redis 分布式锁吧，但好像有点麻烦，我也没完全搞透。

M： 唯一键的思路不错，Redis 锁是个选项，我们后面结合微服务再聊。

二、第二轮：推荐与互动微服务化（5问）

业务背景：内容社区长大了，要做 推荐系统、评论、消息通知，逐步拆成微服务，上云。

Q4：如何拆微服务？（Spring Cloud / Dubbo / 注册发现）

M： 假设我们现在有这些业务：

  • 内容服务：发布、编辑、查询内容
  • 点赞服务：点赞、取消赞、点赞数统计
  • 评论服务：评论增删改查
  • 推荐服务：给用户推荐内容

你会怎么用 Spring Cloud 或 Dubbo 拆分服务？

  • 大概会有哪些服务？
  • 注册发现用什么组件？(Eureka / Consul / Nacos 等)
  • 服务间调用大概怎么做？（比如 OpenFeign / Dubbo RPC）

小Y： 嗯……那就一个内容服务，一个用户服务，一个点赞服务，一个推荐服务，微服务嘛就这么拆。注册中心可以用 Eureka 呀，服务之间用 Feign 调一下就行。 Dubbo 我没太用过，反正也是 RPC 调用，类似的。

M： 基本结构能说出来就还可以。实际场景会考虑更细节的边界和部署。

Q5：如何保证点赞数据异步写库又不丢？（MQ + 最终一致性）

M： 点赞请求量很大，你会考虑：

  • Redis 里即时更新计数，给用户秒回
  • 异步写入 MySQL 保证持久化

那异步这块，你会用哪些技术？（比如 Kafka / RabbitMQ / RocketMQ / Pulsar / Redis Stream）

  • 简述一下你的数据流转方案
  • 如何保证不丢数据？

小Y： 这个……我知道用 Kafka，点赞接口里塞一条消息到 Kafka，然后有个消费者去写数据库。保证不丢的话，把 Kafka 的 acks 配成 all，再多弄几个分区？

M： 至少说明你真的用过 Kafka。只是“多分区”和“不丢数据”没直接关系，我们解析部分再好好讲。

Q6：接口怎么做限流与熔断？（Gateway + Resilience4j）

M： 假设推荐服务因为算法接口慢，导致依赖它的 API 都变慢。你会如何：

  • 在网关层做限流？
  • 在服务调用层做熔断和降级？

可以提到：

  • Spring Cloud Gateway / Nginx 限流
  • Resilience4j / Sentinel 熔断

小Y： 网关可以用 Nginx 的限流模块，或者 Spring Cloud Gateway 里加个 filter 限流，超过 QPS 就返回错误。熔断嘛，用 Resilience4j 配个熔断器，失败多了就打开，降级就返回一个默认推荐列表。

M： 这个回答还不错，有基本的工程实践思路。

Q7：如何记录调用链路？（日志 + Trace + 链路追踪）

M： 微服务多了，调用链变复杂。一个推荐接口可能会调用：用户服务 → 点赞服务 → 内容服务 → 算法服务。 你会用什么方案来：

  • 记录完整调用链路？
  • 快速排查慢接口？

可以提到：

  • 日志：Logback + SLF4J
  • 链路追踪：Sleuth / Micrometer Tracing + Zipkin / Jaeger
  • 监控：Prometheus + Grafana

小Y： 日志的话就用 Logback + SLF4J，打 info、error，记个 traceId 放 MDC 里。链路追踪现在不是有 Zipkin、Jaeger 吗，Spring Cloud Sleuth 一下子就搞定了。慢接口的话，画个链路图看哪个节点耗时长。

M： 有做过一点实战，看出来了。细节我们在解析里展开。

三、第三轮：AIGC + AI 智能客服场景（5问）

业务背景：平台上线 AI 辅助创作 + 智能客服：

  • 用户写不出文案，调用 AIGC 自动生成标题、封面文案
  • 用户有问题，AI 客服阅读平台文档和历史工单，回答问题

Q8：AIGC 草稿生成接口怎么设计？（异步任务 + 限流）

M： 用户点击“AI 生成文案”，你需要设计一个 生成草稿 的后端流程：

  • 前端调用什么接口？
  • 你会同步返回结果还是异步？
  • 如果使用 OpenAI / 自建 LLM，后端如何限流和保护？

小Y： 就写个 /ai/draft 的接口呗，传内容大纲和想要的风格，然后后端调 OpenAI 的接口，生成完再返回。限流就网关那一套，控制 QPS，不行就返回重试。

M： 你这个是“能跑就行”的方案。生产上一般会考虑异步、队列、重试、超时等，更细些我们解析再聊。

Q9：如何做“企业文档问答”？（RAG + 向量数据库）

M： 智能客服要实现：

用户问“我被封号了怎么办？”，AI 要根据平台实际规则文档回答，而不是瞎编。

你听说过 RAG（检索增强生成） 吗？

  • 大概说说它解决什么问题？
  • 技术流程会有哪些步骤？
  • 你知道哪些向量数据库？

小Y： 嗯……RAG 我听过，就是先检索再生成。先从文档里搜一搜，然后把结果丢给大模型，让它根据这些内容回答。向量数据库……我知道 Milvus、还有 Redis 也能存向量，Chroma 好像是 Python 那边的吧。

M： 关键点还算抓住了。具体细节和工程落地，我们在后面给个完整流程图式的讲法。

Q10：如何避免 AI 幻觉？（Hallucination + 约束 + 模型调用标准化）

M： 大语言模型有 幻觉（Hallucination） 问题，会一本正经胡说八道。你觉得在我们这个内容社区里：

  • 会有哪些风险？
  • 你会采取什么技术手段降低幻觉？

可以提到：

  • RAG 约束在文档内作答
  • 工具调用（比如查订单、查账户）后再回答
  • 对敏感问题直接拒答

小Y： 风险就是乱说，把用户封号原因瞎编，这就容易投诉。技术的话……就像你说的，只让它在检索到的文档里找答案，然后给模型说“你只能用这些文档内容回答”。敏感问题可以直接说联系人工客服。

M： 概念上还行，细节我们待会儿补充，比如“答案可验证性”和“置信度控制”。

Q11：如何在 Java 里调用多种 AI 模型？（Spring AI + 客户端-服务器架构 + 工具调用）

M： 假设：

  • 海外流量走 OpenAI
  • 国内流量走自建模型（比如 Ollama 或企业私有模型）

你用的是 Java + Spring Boot，听说过 Spring AI 吗？

  • 你会如何封装一个统一的 AI Client？
  • 不同模型的调用差异怎么屏蔽？
  • 如何做工具调用（比如让模型去查数据库、查订单）？

小Y： Spring AI 我只看过一点点，知道它可以像调用普通服务一样调各种大模型。统一 AI Client 的话就搞个接口 AiService，里面有个 generate 方法，不同模型实现不同。工具调用的话……可以在 prompt 里告诉它怎么用工具，然后后端根据输出再调别的接口？

M： 至少概念能说对一半。现代做法会用“工具调用标准化”和 Agent 框架自动帮你调工具，我们解析里详细讲。

Q12：AI 智能客服如何保持“会话记忆”？（聊天会话内存 + Agentic RAG + 复杂工作流）

M： 用户和智能客服会来回聊很多轮，比如：

用户：为什么我被限流？ AI：你近期点赞太频繁…… 用户：那我要怎么解除？

你会如何：

  • 在后端保持会话上下文？
  • 既利用历史对话，又不让上下文太长？
  • 有听说过“Agentic RAG”“复杂工作流”这类概念吗？

小Y： 会话的话就存 Redis 吧，按 sessionId 存最近几轮对话。历史太长就只保留最后几条，或者截断一下。Agentic RAG 这些我就……大概知道是更智能一点的那种，让 AI 自己决定怎么查资料、怎么分步干活。

M： 回答有点糊，但也算没答歪。好，面试环节就到这。

面试结束

M： 今天先聊到这里，你的基础还可以，有些点需要系统补一补。我们会在一周内给你答复，你先回去等通知吧。

小Y： 好的好的，那我就先回去（瑟瑟发抖）。

面试题详细解析（小白也能看懂）

下面是上面所有问题的 详细标准思路，按业务场景串起来讲。

1. 点赞与基础接口：从单体到高并发

1.1 点赞接口的基础设计（对应 Q1）

业务场景： 用户在内容详情页点击“点赞”，后端要记录“谁给哪条内容点了赞”，并能统计点赞数。

数据库设计示例（MySQL）：

CREATE TABLE user_like (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  content_id BIGINT NOT NULL,
  create_time DATETIME NOT NULL,
  UNIQUE KEY uk_user_content(user_id, content_id)
);
  • uk_user_content 保证同一用户对同一内容只会有一条记录。

Spring Boot Controller 示例：

@RestController
@RequestMapping("/api/like")
public class LikeController {

    private final LikeService likeService;

    public LikeController(LikeService likeService) {
        this.likeService = likeService;
    }

    @PostMapping("/do")
    public ResponseEntity<Void> like(@RequestParam Long userId,
                                     @RequestParam Long contentId) {
        likeService.like(userId, contentId);
        return ResponseEntity.ok().build();
    }

    @PostMapping("/undo")
    public ResponseEntity<Void> unlike(@RequestParam Long userId,
                                       @RequestParam Long contentId) {
        likeService.unlike(userId, contentId);
        return ResponseEntity.ok().build();
    }
}

Service 示例（基于 Spring Data JPA / MyBatis 都可以）：

@Service
public class LikeService {

    @Transactional
    public void like(Long userId, Long contentId) {
        // 直接插入，如果存在唯一键冲突就忽略
        try {
            likeMapper.insert(userId, contentId);
        } catch (DuplicateKeyException e) {
            // 幂等：已经点过赞了，忽略
        }
    }

    @Transactional
    public void unlike(Long userId, Long contentId) {
        likeMapper.delete(userId, contentId);
    }
}

这里已经利用数据库唯一约束保证了 幂等性，避免重复点赞。

1.2 用 Redis 提升性能（对应 Q2）

为什么需要 Redis？

  • 点赞是高频写 → 直接写 MySQL 会有性能瓶颈
  • 点赞数是高频读 → Redis 非常适合做计数缓存

典型方案：

  1. Redis 存计数

    • Key 设计：like:count:{contentId}
    • 点赞时：INCR like:count:{contentId}
    • 取消点赞：DECR like:count:{contentId}

  2. 解决缓存击穿/雪崩：

    • 热点内容直接设置较长 TTL，或干脆不设置过期，依靠后端定时任务做同步
    • 缓存击穿（某个热点 key 过期瞬间大量请求）：
      • 方案一：互斥锁，只有一个线程回源 DB，其余等待
      • 方案二：逻辑过期，在 value 里存过期时间，即使 Redis 过期时间未到，自己控制刷新

  3. 数据一致性：

    • 可以接受最终一致：Redis 为主展示，DB 为准做对账
    • 定时任务对比 Redis 计数与 DB，修正异常

1.3 并发点赞的一致性保证（对应 Q3）

核心问题：

  • 并发下重复点赞
  • 计数可能不准

推荐组合方案：

  1. 数据库唯一约束：UNIQUE KEY uk_user_content(user_id, content_id)

  2. 代码幂等处理：

    • 插入失败（唯一约束异常）就认为已经点过赞，直接忽略

  3. Redis 计数修正：

    • 点赞接口只管 INCR，不会因为重复点赞导致多加吗？
      • 由于 DB 限制，只会插入一条真正成功的记录
      • 可以通过 异步对账任务（按 user_like 表重算 Redis 计数）定期修正

  4. 什么时候用分布式锁？

    • 如果点赞还伴随更复杂的逻辑（例如发放一次性奖励），可以用 Redis 分布式锁保护复合逻辑：
      • 锁 key：lock:like:{userId}:{contentId}
      • 获取锁 → 检查状态 → 更新 DB + Redis → 释放锁

2. 微服务架构与高可用设计

2.1 微服务拆分与服务发现（对应 Q4）

典型微服务拆分：

  • user-service：用户信息、等级、信用等
  • content-service：内容发布、编辑、查询
  • like-service：点赞、取消赞、计数
  • comment-service：评论管理
  • recommend-service：推荐流的组装与分发
  • notification-service：消息通知（站内信、Push）

服务注册与发现：

  • 可选方案：
    • Spring Cloud Eureka
    • Consul
    • Nacos
  • 每个服务启动时 注册到注册中心，其他服务通过服务名调用：
@FeignClient("like-service")
public interface LikeClient {
    @PostMapping("/internal/like/count")
    LikeCountResponse getLikeCount(@RequestBody LikeCountRequest req);
}

网关层：

  • Spring Cloud Gateway / Nginx
  • 负责：
    • 路由转发
    • 认证鉴权（结合 Spring Security / JWT / OAuth2）
    • 限流与黑白名单

2.2 点赞异步写库与不丢数据（对应 Q5）

目标：

  • 用户点击点赞 → 接口快速返回
  • 数据异步持久化到 MySQL
  • 尽量不丢数据

方案示例（Kafka）：

  1. 点赞接口流程：

    • 写 Redis 计数：INCR
    • 发送消息到 Kafka：topic = like_events
    • 记录字段：userId, contentId, eventType (LIKE/UNLIKE), timestamp
    • 返回成功给用户

  2. 消费者流程：

    • like-consumer 订阅 topic
    • 逐条处理：
      • LIKE：插入 user_like 表（忽略重复）
      • UNLIKE：删除对应记录

  3. Kafka 不丢数据的要点：

    • Producer：
      • acks=all：只有 Leader + ISR 副本都写成功才确认
      • 开启 retries，有失败自动重试
    • Broker：
      • 合理设置副本数：replication.factor >= 2
    • Consumer：
      • 手动提交 offset：处理完成后再 commit
      • 使用幂等逻辑，避免重复消费导致脏数据

2.3 限流与熔断（对应 Q6）

网关限流：

  • Nginx：limit_req_zone，按 IP 或用户 ID 计数
  • Spring Cloud Gateway：
    • 内置过滤器 + Redis 令牌桶实现
  • 限流策略：
    • 针对 API：例如 /recommend/feed 限制每秒 50 次/用户
    • 针对 AI 接口：更严格保护（例如每分钟 3 次）

熔断与降级：

  • 使用 Resilience4j：
    • CircuitBreaker：错误率高时熔断
    • Bulkhead：限制并发调用数，防止资源被耗尽
    • RateLimiter：限流
  • 降级策略示例：
    • 推荐服务不可用时，按简单规则给用户一个兜底列表（热门内容）
    • 评论服务挂了，则提示“评论功能维护中”

2.4 日志与调用链追踪（对应 Q7）

日志规范：

  • 统一使用 SLF4J 接口 + Logback 实现
  • 日志字段：
    • 时间、级别、线程
    • traceId / spanId
    • 用户 ID、请求 ID
  • 使用 JSON 日志便于被 ELK（ElasticSearch + Logstash + Kibana）收集和查询

链路追踪：

  • 使用 Micrometer Tracing 或 Spring Cloud Sleuth：
    • 自动在 HTTP / Feign 调用间传递 traceId
    • 上报数据到 Zipkin / Jaeger

监控告警：

  • 用 Micrometer + Prometheus 暴露指标
  • 用 Grafana 做可视化
  • 关键指标：
    • 接口 QPS / RT
    • 错误率
    • 下游依赖（DB、Redis、MQ）的连接数、延迟

3. AIGC 与智能客服：RAG、Agent 与会话记忆

3.1 AIGC 草稿生成流程（对应 Q8）

业务需求：

  • 用户写不出图文标题、封面文案
  • 点击“AI 帮我写”，系统生成草稿

同步 vs 异步：

  • 同步方案：

    • 前端发请求 → 后端直接调用大模型 → 返回草稿
    • 优点：简单
    • 缺点：请求时间长、不稳定、容易超时

  • 推荐异步方案：

    1. 前端调用 /ai/draft，后端：
      • 生成一个 taskId
      • 将任务写入 MQ / 任务表
      • 立即返回 taskId
    2. Worker 服务从 MQ 消费任务：
      • 调用外部模型（OpenAI / 内部 LLM）
      • 生成草稿，保存 DB / Redis
    3. 前端轮询 /ai/draft/result?taskId=xxx 或使用 WebSocket 通知结果

限流与保护：

  • 在网关对 /ai/** 接口做单用户 QPS 限制
  • 对总并发数做限制，避免透支外部 API
  • 使用 Resilience4j/Retry 模块：
    • 对模型调用做重试、超时与熔断

3.2 RAG：企业文档问答（对应 Q9）

问题：

  • 纯大模型对业务规则不了解，会张口就来
  • 需要让它回答“平台规则、封号原因、申诉流程”等 企业知识

RAG（Retrieval-Augmented Generation）核心思想：

让模型“先搜索再回答”，把企业文档当作“增强上下文”，约束它不要瞎编。

典型技术流程：

  1. 文档加载（Document Loading）

    • 将帮助中心、协议、FAQ、内部知识库等导出
    • 可用 Apache POI 读取 Word/Excel，或从数据库直接读取

  2. 切分与向量化（Chunking + Embedding）

    • 将长文档切成小段（比如 300~800 字）
    • 使用 Embedding 模型（OpenAI Embedding / 本地模型）将文本转为向量

  3. 向量数据库存储：

    • Milvus, Chroma, Redis Vector, ElasticSearch 向量检索等

  4. 查询阶段（用户提问）：

    • 用户问题 → 文本 → 向量
    • 到向量数据库做相似度检索，取 Top-K 片段

  5. 生成阶段：

    • 将检索到的片段 + 用户问题 → 拼成 Prompt
    • 喂给大模型，要求：
      • 只能根据提供的文档片段回答
      • 如文档中没有答案，要明确说“不确定”或建议联系人工

这就是 RAG 典型的“检索增强生成”流程。

3.3 控制 AI 幻觉（对应 Q10）

在内容社区里的风险：

  • AI 客服乱解释封号/扣款等敏感问题，引发投诉
  • 乱说规章制度，引发合规风险

降低幻觉的常用手段：

  1. RAG 约束：

    • 强制模型只基于检索到的企业文档回答
    • Prompt 中明确：
      • 文档没有的内容就说“不确定”或“请联系人工”

  2. 工具调用（Tool Use）：

    • 对于实事类问题（我的订单是否成功？）
    • 让模型先“调用工具”（查询订单接口）→ 再基于结果回答

  3. 安全与敏感规则：

    • 对违规话题（政治、色情、暴力）直接拒答
    • 使用规则引擎或内容审核服务（如腾讯云、阿里云内容安全）

  4. 答案可验证性与置信度：

    • 对于高风险操作（封号、退款），要求结果来自“可验证系统”（数据库 / 业务 API），而不是语言模型“猜”的

3.4 Java 中统一 AI 调用与 Spring AI（对应 Q11）

问题：

  • 模型多：OpenAI、Ollama、自研模型、其他云厂商
  • 接口各异：不同 URL、参数格式、鉴权方式

Spring AI 的价值：

  • 提供统一的抽象：
    • ChatClient、EmbeddingClient 等
  • 配置驱动：
    • 在 application.yml 指定不同 provider 的配置

统一 AI Client 设计示意：

public interface AiService {
    String generateDraft(String instruction, String contentOutline);
}

@Service
public class AiServiceImpl implements AiService {

    private final ChatClient openAiClient;
    private final ChatClient localLlmClient;

    public AiServiceImpl(@Qualifier("openAiClient") ChatClient openAiClient,
                         @Qualifier("localLlmClient") ChatClient localLlmClient) {
        this.openAiClient = openAiClient;
        this.localLlmClient = localLlmClient;
    }

    @Override
    public String generateDraft(String instruction, String contentOutline) {
        ChatClient client = chooseClientByRegion();
        return client.prompt()
                .user(instruction + "\n" + contentOutline)
                .call()
                .content();
    }
}

工具调用（Tool Calling）：

  • 定义工具，如 getUserProfile, queryOrderStatus
  • 使用模型支持的工具调用能力（Function Calling / Tool Calling）：
    • 模型返回一个“调用工具”的结构化响应
    • 后端解析后真正调用对应的 Java 方法 / HTTP 接口
    • 再把工具结果反馈给模型，让它生成最终回答

3.5 会话记忆与 Agentic RAG（对应 Q12）

会话记忆（Chat Memory）：

  • 需求：多轮对话“接得上话”
  • 简单做法：
    • 在 Redis 中按 sessionId 存最近 N 轮对话
    • 每次提问时，将最近几轮拼接到 Prompt

问题：

  • 对话太长，会超过模型上下文限制

改进：

  • 只保留关键信息摘要：每轮对话后做“对话总结”
  • 将摘要作为上下文，而不是原始对话全文

Agentic RAG 与复杂工作流：

  • Agent：带“目标”的智能体，可以：
    • 分步骤规划（先查封号原因，再查申诉进度）
    • 决定何时调用工具、何时检索文档
  • Agentic RAG：
    • 将 RAG 检索、工具调用、对话记忆组合在一起
    • 例如：
      1. 根据问题判断是否需要：“查用户状态”工具
      2. 检索文档中“封号规则”部分
      3. 结合文档 + 工具结果给出最终解释

在 Java 中可以通过：

  • 使用 Spring AI + 自建工作流
  • 或者接入已有“Agent 框架”的服务端（比如 Python/Go 写的 Agent 服务），Java 只是调用统一 API

总结

通过这场“内容社区 + AIGC + 智能客服”的大厂 Java 面试，我们串联了：

  • Java + Spring Boot 的基础接口设计
  • MySQL + Redis + Kafka 的高并发点赞方案
  • Spring Cloud 微服务拆分、网关、限流与熔断
  • 日志、调用链与监控体系
  • AIGC 草稿生成的同步/异步设计
  • RAG、向量数据库、AI 幻觉控制
  • Spring AI、工具调用、会话记忆与 Agentic RAG

如果你能把“面试戏份 + 解析部分”都看懂、自己能实现一个简化版 Demo，在互联网大厂 Java 面试中，至少在这一条业务线上的表现，会比小Y靠谱很多。

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

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

更多推荐

cover

SpringBoot+Vue 校园志愿者管理系统管理平台源码【适合毕设/课设/学习】Java+MySQL

avatar AtomGit开源社区
cover

Java Web 校园招聘系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

avatar AtomGit开源社区
cover

【2025最新】基于SpringBoot+Vue的校园疫情防控信息管理系统管理系统源码+MyBatis+MySQL

avatar AtomGit开源社区