8.0
热点
AI SCORE
编程提效2026-08-14 23:32
用 Spring Boot 做三个 AI 产品后的工程总结
dev.to · AI#Java#Spring Boot#AI 应用
Editor brief · 编辑速览
作者用 Spring Boot 构建了 GitHub PR AI 代码审查、AI CRM、简历分析三款应用，总结了 Java 生态接入 LLM 的常见陷阱与架构经验。
我对 CRUD 应用感到厌倦了。
所以我没有去创建另一个简单的员工管理系统或待办事项应用，而是决定构建一些更接近真实产品的东西。
在过去几周里，我用 Spring Boot 构建了三款 AI 应用：
🤖 GitHub Pull Request AI 代码审查器 📄 AI 简历分析器 💬 自托管 AI 支持组件
每个项目都始于一个简单的想法：
我能否用我已经熟悉的后端技术来构建一些真正有用的东西，而不是为了教程去构建项目？
答案是肯定的。
但最有价值的部分其实不是完成了这些应用。
而是在构建过程中学到的一切。
我一直在用 Java 和 Spring Boot 工作，所以我想看看将它与 AI 结合能走多远。
当人们谈论 AI 应用时，对话通常围绕 Python、机器学习模型、Jupyter Notebook 和数据科学展开。
但 AI 还有另一面：
应用层。
REST API、认证、数据库集成、外部 API 通信、请求验证、错误处理、文件处理、业务逻辑、日志、配置、部署
这就是 Spring Boot 变得极其有用的地方。
AI 模型可能生成智能，但后端是将智能转化为实际产品的关键。
我构建的第一个产品是一个面向 GitHub Pull Request 的 AI 代码审查器。
与其手动逐个查看 Pull Request 中每个变更的文件，为什么不让 AI 分析这些变更并提供有用的反馈？
基本流程：
GitHub Pull Request ↓ 获取 PR 信息 ↓ 获取变更代码 ↓ 准备审查 prompt ↓ AI 分析 ↓ 生成审查意见 ↓ 返回有用反馈
AI 不仅仅是回答：
目标是让审查更有用，关注开发者真正关心的内容。
潜在 bug、代码质量问题、安全隐患、性能问题、可维护性、不良实践、可能的改进
最大的教训是：
AI 输出质量取决于你提供给它的上下文。
最初，很自然会简单地发送一段代码给 AI 模型并问：
但真实代码不是孤立存在的。
一个方法可能依赖另一个类。
一个变量可能有特定的业务含义。
一个变更可能只有在查看整个 Pull Request 时才有意义。
所以构建 AI 应用不仅仅是调用 AI API。
而是收集正确的上下文并以正确的方式呈现。
这是我早期的重大收获之一。
第二个产品是一个用 Spring Boot 构建的 AI 简历分析器。
这个想法来自每个求职者都非常熟悉的事情：
你花几个小时创建一份简历……
然后发送给公司……
却永远不知道为什么没有通过初筛。
所以我想构建一个可以分析简历并提供有用反馈的工具。
基本思路：
简历 ↓ 上传 ↓ 后端处理 ↓ 提取简历内容 ↓ AI 分析 ↓ 生成反馈 ↓ 返回分析结果
应用可以分析以下方面：
技能、经验、关键词、简历结构、岗位匹配度、缺失信息、可能的改进
有趣的是，这个项目引入了一个与 GitHub 审查器完全不同的后端问题。
现在应用需要处理文档和非结构化信息。
这个项目教会了我一件重要的事：
构建 AI 应用往往更多是数据准备工作，而不是 AI 调用本身。
你不能简单地把一个文档扔给 AI 模型就期望完美结果。
应用需要：
接收文件、处理内容、提取有用信息、整理这些信息、发送正确的上下文给 AI、处理响应、以有用的格式呈现结果
因此后端成为了用户原始输入和 AI 模型之间的桥梁。
这让我更加欣赏 Spring Boot 了。
这是目前我最兴奋的项目。
我用 Spring Boot 构建了一个自托管 AI 支持组件。
想法是创建一个由 AI 驱动的支持体验，而不必依赖昂贵的月度 SaaS 订阅。
这里的关键词是：
"我需要订阅另一个 SaaS 产品。"
"我可以自己运行这个。"
基本概念：
用户 ↓ 支持组件 ↓ Spring Boot 后端 ↓ AI 服务 ↓ 响应 ↓ 支持组件
后端处理组件和 AI 服务之间的通信。
这意味着前端不需要包含所有业务逻辑。
Spring Boot 成为负责应用行为的中心层。
这个项目与之前的应用感觉不同，因为我不仅仅是在考虑 API 是否可用。
我开始思考：
其他开发者会如何使用这个？应用如何实现自托管？API 应该是什么样的？错误应该如何处理？配置应该如何工作？应用以后如何扩展？如何让它感觉像一个真正的产品？
就在那时，我意识到一件事：
构建应用和构建产品之间有很大区别。
构建完这三个之后，我注意到 AI 本身并不是最难的部分。
调用 AI API 相对简单。
困难的部分是围绕它的一切。
这可能是我最大的收获。
AI 可以生成答案。
但仍然需要有人构建周围的系统。
你仍然需要考虑：
认证 ↓ API 设计 ↓ 验证 ↓ 业务逻辑 ↓ 数据库 ↓ 外部服务 ↓ AI 集成 ↓ 错误处理 ↓ 部署
这就是后端工程。
而 AI 成为后端集成的另一个服务。
在构建这些项目之前，我对 prompt 考虑了很多。
构建之后，我意识到 prompt 工程只是问题的一部分。
更好的心智模型是：
好输入 + 好上下文 + 好 Prompt + 好后端逻辑 = 更好的 AI 应用
如果应用发送的上下文很差或不完整，即使再好的模型也可能产生很差的结果。
当你在跟着教程做时，目标通常是：
让应用跑起来。
当你在构建自己的产品时，问题变了。
谁会使用这个？它解决什么问题？为什么有人会用这个而不是其他工具？当出现问题时会发生什么？如何让它更容易使用？之后应该添加什么功能？
这些问题改变了我处理开发的方式。
构建副项目时最容易犯的错误之一是添加太多功能。
"我来构建一个 AI 代码审查器。"
然后突然你在规划：
认证、团队、计费、分析、通知、仪表盘、管理面板、多个 AI 提供商、十种不同的集成
而原始产品永远完成不了。
这个功能是否解决核心问题？
如果答案是否定的，它可以等一等。
3 个小型可用产品 vs 1 个巨大的未完成应用
这些项目也教会我，一个项目不需要 50 个功能才能展示工程能力。
一个相对较小的应用可以展示：
API 设计、后端架构、外部集成、AI 集成、文件处理、错误处理、业务逻辑、部署、产品思维
这已经很多了。
在这些项目中，我的重点主要在我熟悉的后端技术栈上。
后端
Java、Spring Boot、REST API、基于 Spring 的后端架构
AI
AI API / LLM 集成、Prompt 设计、上下文准备、AI 生成的响应
集成
GitHub API、文件/文档处理、外部服务
开发
Maven、Git/GitHub、API 测试、日志、配置管理
具体的实现细节在各个项目中有所不同，但共同的想法是相同的：
将 Spring Boot 作为连接用户、业务逻辑、外部服务和 AI 的应用层。
如果重新开始这些项目，我会在写第一行代码之前花更多时间在架构上。
核心问题是什么？↓ 最小可用产品是什么？↓ 我需要哪些 API？↓ 我需要哪些数据？↓ AI 实际上在哪里增加价值？↓ 组件之间应该如何通信？↓ 我将如何部署它？
这可以防止项目变成一堆随机功能的集合。
我不打算止步于这三个。
下一步是将从这些项目中学到的东西，围绕 Java、Spring Boot、AI 和数据库构建更多实用的后端工具。
我对解决开发者实际面临的问题的项目特别感兴趣。
因为我的目标不仅仅是：
"构建另一个 AI 项目。"
构建有用的软件，并学习背后的工程知识。
构建这三个产品改变了我看待 AI 开发的方式。
从"如何在 Spring Boot 应用中集成 AI？"
变成了更深入的思考：
"如何构建一个真正有用的产品，而 AI 是解决方案的一部分？"
这是一个有趣得多的问题。
AI 模型只是一个组件。
真正的工程挑战是围绕它的一切。
而这正是我想继续探索的部分。
🤖 AI Code Reviewer for GitHub Pull Requests
分析 Pull Request 变更并生成 AI 驱动的代码审查反馈。
📄 AI Resume Analyzer
分析简历并提供 AI 驱动的反馈和改进建议。
💬 Self-Hosted AI Support Widget
构建一个可自托管的 AI 支持体验，不完全依赖月度 SaaS 平台。
如果你也是正在尝试 AI 的 Java/Spring Boot 开发者，我很想知道你在构建什么。
你会用 Spring Boot + AI 构建什么？
写在评论区 👇
GitHub: [https://github.com/Sweety717/]
Project 1 — AI Code Reviewer: [https://swarnalata25.gumroad.com/l/codeguard-ai]
Project 2 — AI Resume Analyzer: [https://swarnalata25.gumroad.com/l/resumeiq-ai]
Project 3 — Self-Hosted AI Support Widget: [https://swarnalata25.gumroad.com/l/supportai-springboot]