Spring Boot集成AI生成博客摘要：从接口调通到生产级落地全实践

开篇先聊点实在的我给自己的博客系统加了个“AI智能摘要”功能整个过程从需求设计、技术选型到最终落地踩坑前后花了一个多星期。期间最大的感受是——网上讲Spring Boot集成大模型的教程很多但绝大多数都停留在“调通一个接口”的层面距离“能在生产环境里稳定跑、不拖垮博客、不烧钱、不返工”还有很长一段路。这篇就按照我实际操作的顺序把完整链路和真正关键的部分掰开揉碎讲清楚。这篇实战内容适合谁两种人。一种是正在做Spring Boot项目、想快速接入AI能力但不知道怎么下手的开发者另一种是已经能用Spring AI把大模型接口调通但卡在工程化细节上——比如超时控制、异步任务、缓存策略、内容清洗、成本控制——的同行。文章里不会只贴代码更重要的是每个设计决策背后的理由以及我在实测中遇到的真实问题和排查过程。1. 先想清楚博客的AI摘要到底解决什么问题1.1 一个很朴素的需求场景我做的是一个技术博客系统文章平均篇幅在2000到5000字。虽然站内已经有了分类和标签体系但读者点进一篇文章后往往要看两三段才能判断“这篇到底值不值得读”。技术类文章尤其如此——标题写的是“Spring Boot集成XX”结果打开发现一大半内容在讲前置概念。我的需求就一条在文章详情页顶部、正文之前生成一段100到150字的摘要。让读者花10秒钟就能知道这篇文章讲了什么、适合谁、有没有他想看的东西。听起来简单但如果靠人工给每篇文章写摘要旧文章回填就是巨大的工作量更别说新文章要每篇都维护。所以AI摘要的第一个价值是“存量的处理效率”第二个价值是“体验的一致性”。我写摘要的口味不一定稳定有时候写得很干有时候又收不住。用大模型统一风格反而容易控制输出质量。1.2 需求边界哪些地方不该用AI出摘要做了几版原型后我明确了一点不是所有文章都适合用AI生成摘要。比如纯代码片段类的内容、一个简单的更新日志大模型很容易被“带跑偏”生成一些和正文没什么关系的漂亮话。我的做法是加了前置校验规则文章正文长度小于800字的直接取前200字符作为摘要不调用AI接口文章以代码块为主、文本比例低于40%的先抽取代码块外的前几段文字作为摘要候选已经被用户/管理员手动编辑过摘要的文章跳过AI生成避免覆盖人工编辑内容。这套规则在复杂度上不算什么但它把AI的调用量大概砍掉了25%到30%。省下的不只是接口费用还有等待时间和失败概率。2. 技术选型为什么选Spring AI而不是自己拼HTTP调用2.1 选型的三个核心约束我选技术方案时有三个约束项目本身就是Spring Boot 3.x MyBatis-Plus的标准结构不想为了一个摘要功能引入太多新框架AI接口这块我希望保留切换供应商的余地不绑死某一家团队里其他同事也要能接手不能只我一个人会玩。在这种背景下摆在我面前的基本是三选一方案优点缺点直接用OkHttp/RestTemplate调大模型HTTP接口简单直接无框架依赖流式处理、重试、JSON解析、多供应商切换都要自己写代码量不小用LangChain4j的Spring Boot集成功能全面生态丰富抽象层较重很多能力我用不上学习成本偏高用Spring AI的ChatClient/StreamingChatClient与Spring Boot天然契合配置简化社区相对年轻部分API演进较快需要锁定版本最终选了Spring AI。核心原因是它对“模型间切换”和“结构化输出”这两件事的支持最符合我的使用方式。比如我想让模型返回JSON格式的摘要Spring AI可以配置结构化提示词和输出解析器省掉自己正则提取的脏活。而且它的流式响应接口和Spring WebFlux/虚拟线程都兼容得不错后续如果要把摘要效果提升为“逐字显示”也不用换架构。2.2 大模型选择云端API还是本地部署这一版我用的方案是云端API。选型时做了一个对比如果你和我一样在意部署成本这个对比会有参考价值自己的服务器配置是4核8G跑博客本身加上MySQL、Redis、MinIO已经很吃紧再塞一个量化版的7B模型推理速度会非常慢而且显存内存都不够。摘要场景虽然对延迟不敏感后面会讲异步化但也不能慢到十分钟才出结果。所以直接用云端API按调用量计费成本远低于买新机器。至于具体用哪家模型我选了支持OpenAI兼容协议的服务。方便之处在于Spring AI的配置几乎不需要针对性地写代码改一下base-url和api-key就能切换。代码层只面向ChatClient接口将来如果换供应商改动面被限制在配置文件内部。2.3 版本兼容性Java 21 Spring Boot 3.x Spring AI的一点点经验这个坑值先单独说。Spring AI对版本非常敏感我就吃过一次亏。Spring Boot 3.2.x配当时某版本的Spring AI就会遇到自动配置不生效的问题现象是项目启动正常但注入ChatClient时报NoSuchBeanDefinitionException。我的建议以Spring AI官网的“Version Compatibility”表为准严格匹配Spring Boot和Spring AI的版本号不要指望“最新版永远不会错”。我现在用的是Java 21 Spring Boot 3.3.x Spring AI 1.0.0-M系列依赖管理器用Spring Boot的BOM配合Spring AI的BOM避免自己手工指定一堆传递依赖版本。还有个小细节Java 21的虚拟线程可以在这类场景明显提升吞吐。配置spring.threads.virtual.enabledtrue之后很多阻塞式的IO调用不再占用平台线程。AI摘要的调用恰恰是一个高阻塞、低CPU的操作和虚拟线程的适配度非常高。我在第六节会给出实测数据。3. 项目核心实现从原始文章内容到AI摘要的完整链路3.1 数据库表设计摘要字段放在哪更合适先说结论我把摘要存到了文章表本身的summary字段里而不是单独建一张ai_summary表。原因很简单摘要的消费方是文章详情页它和文章是一对一关系放在同表可以省掉一次关联查询。但有一个细节很多人会忽略——摘要的“来源”和“生成状态”需要额外字段记录。我加了三列summary最终对外展示的摘要文案summary_status枚举值NO_SUMMARY未生成、GENERATING生成中、SUCCESS生成成功、FAILED生成失败、MANUAL人工编辑summary_generated_at记录生成时间便于后续做清理或重新生成。为什么需要状态字段因为AI摘要生成是异步流程后面会讲文章发布后摘要不会立刻出现。页面读数据时要根据状态决定展示“摘要加载中”还是直接不展示不能一刀切。3.2 文章内容预处理HTML标签清洗和正文提取博客文章编辑器输出的是富文本HTML直接交给大模型会引发两个问题一是HTML标签和样式噪音会占据大量Token成本白白升高二是模型容易被一些特殊标签干扰生成的摘要里可能出现“点击了解更多”之类的鬼话。所以我写了一个预处理组件职责是把富文本内容变成“适合大模型阅读的纯文本”。核心逻辑不复杂但边界条件比较多。我按顺序处理移除script、style标签及其全部内容防止隐藏的脚本干扰用Jsoup解析HTML获取干净的纯文本内容把多个空白字符、换行符压缩成单个换行对代码块保留缩进信息但去掉行号和高亮标记控制最终文本长度超过4000字符就截断优先保留开头和结尾部分。第5步是试出来的。技术文章一般在开头交代背景和结论在结尾做总结中间是大量论证和代码。要让模型产出有效摘要只保留首尾反而效果更好。当时我测试过完整正文和截断后文本的摘要效果截断版在信息准确度上几乎持平Token费却少了40%。3.3 Prompt模板的设计如何让模型稳定输出摘要Prompt是整个环节里ROI最高的部分。同样的模型写清楚Prompt和不写清楚出来的摘要质量能差出两个档次。我经过多轮迭代最终固定下来的模板长这样你是一名资深技术博客编辑。请为以下技术文章生成一段摘要要求 1. 字数控制在100到150字之间 2. 必须包含文章解决的问题、使用的核心技术、适用读者群体 3. 语言简洁不用营销式词汇不要使用本文将介绍值得注意的是等套话 4. 直接输出摘要正文不要输出标题、序号或其他多余内容。 文章内容 {content}这个模板有三个特点给出角色的目的是让模型代入编辑视角明确“不用套话”是为了避免模型惯性输出那些AI味很重的话“直接输出摘要正文”则是为了减少解析成本。说实话光是“不要用套话”这句就让摘要可读性提升了不少。大家如果要做类似功能我建议在Prompt调试上多花时间这比换更强的模型更省钱、更快见效。3.4 核心代码Spring AI的ChatClient调用选中Spring AI后代码部分比我预想的简单很多。pom.xml里引入依赖后配置好api-key和base-url就能注入ChatClient。业务侧完整的调用代码如下省略了部分异常处理和日志埋点Service RequiredArgsConstructor public class AiSummaryService { private final ChatClient chatClient; public SummaryResult generateSummary(String articleContent) { String cleanText contentProcessor.clean(articleContent); cleanText contentProcessor.truncate(cleanText, 4000); if (cleanText.isBlank()) { return SummaryResult.empty(文章内容为空); } String prompt summaryPromptBuilder.build(cleanText); try { String response chatClient.prompt(prompt) .call() .content(); String summary postProcess(response); return SummaryResult.success(summary); } catch (Exception e) { log.error(AI summary generation failed, reason: {}, e.getMessage()); return SummaryResult.failed(e.getMessage()); } } private String postProcess(String response) { // 去除模型返回内容中的首尾空格、引号、多余换行 return response null ? : response .replace(^[\\s\“”], ) .replace([\\s\“”]$, ) .trim(); } }这段代码有几个容易被AI框架初学者忽略的点单独说一下ChatClient的实例需要通过ChatClient.Builder创建但Spring AI的自动配置会在应用上下文里准备好Builder所以直接注入ChatClient是可行的前提是你的配置里没把自动配置关掉。因为我用的是OpenAI兼容协议配置文件里要设置spring.ai.openai.base-url和spring.ai.openai.api-key但设完之后代码层面并不关心“对方到底是不是OpenAI”这就是统一抽象的好处。3.5 内容安全处理从生成到上屏不能裸奔AI生成内容不能直接落库展示这点一定要提醒大家。大模型生成的内容虽然本身有对齐机制但技术社区对内容质量和合规性的要求是两回事。我对模型输出的摘要做了一层自己的安全通道。一方面在Prompt里明确要求不输出与文章主题无关的敏感内容另一方面我在后处理阶段做了三件事敏感词过滤——基于本地的敏感词库做前缀匹配命中就置为生成失败不展示半句广告和推广话术识别——如果摘要里出现“加微信”“点击链接”“限时优惠”这类明显异常的词直接拦截内容与正文的相关性校验——用简单的关键词重合度判断如果摘要和正文几乎没有重叠词汇判定为生成跑偏丢弃本次结果。整个安全链路走完后摘要才被允许写入数据库。严格来说这套方案不能保证“零风险”但它能在绝大多数情况下避免脏内容出现在页面上。对于个人博客系统来说这个强度我认为是够用的。4. 异步化与降级不能因为AI摘要把博客搞挂4.1 为什么必须异步处理第一次实现时我在文章详情页的Controller里直接同步调用了生成逻辑。本地测试一切正常但部署到服务器后出了个尴尬的问题当天的访问高峰里文章详情页接口的P99延迟从80ms飙到了9秒。原因很直观大模型接口的平均响应时间在2到3秒慢的时候会到10秒。同步调用意味着用户请求的线程被死死占用就算我用的是虚拟线程连接池、数据库连接、外部HTTP连接也会被长时间占据。更糟的是一旦模型服务出现网络抖动用户的页面会直接白屏或超时体验非常糟糕。正确的做法是把摘要生成从请求链路中剥离出去变成异步任务。文章发布时只同步返回“摘要生成中”后续通过异步线程池去调用模型生成完成后回填数据库。详情页读取时如果发现状态仍是“生成中”就先展示文章的前几百字作为临时摘要。4.2 异步任务队列的参数调优Spring Boot自带EnableAsyncAsync对于博客这种低并发场景完全够用。但如果直接无脑加Async注释会踩到一个默认线程池的坑——Spring的默认SimpleAsyncTaskExecutor每次执行都会新建线程没有复用长期下来线程数量会失控。我自定义了线程池Configuration EnableAsync public class AsyncConfig { Bean(aiSummaryExecutor) public Executor aiSummaryExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(4); executor.setQueueCapacity(500); executor.setThreadNamePrefix(ai-summary-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }这里我特意把核心线程数调得很小。因为AI摘要任务是IO密集型而不是CPU密集型并行度太高反而会同时占用大量HTTP连接导致上游接口限流。2到4个线程对个人博客足够。CallerRunsPolicy做拒绝策略也有讲究——当队列满时任务会在提交方线程里执行这样不会把任务直接丢弃相当于用请求线程做了一次兜底。4.3 失败重试和幂等性设计大模型接口不可能每次都成功。超时、限流、网络抖动都会造成生成失败。我的重试策略分两层第一层是代码层面的简单重试。针对连接超时和5xx错误Spring AI调用失败后我会捕获异常并最多重试2次每次间隔3秒。注意这里只对“可重试”的异常做重试如果是4xx的参数错误比如内容为空、输入超长重试没有意义直接标记失败更合理。第二层是任务级别的补偿。如果两次重试都失败我会把文章的summary_status标记为FAILED并记录失败原因。然后写了一个定时任务扫描所有summary_statusFAILED的文章每6小时自动补跑一次。这样即使某段时间模型服务不稳定过几个小时后摘要也能被自动补齐。幂等性方面更新摘要时使用条件更新的SQL只更新summary_statusGENERATING或FAILED的记录防止人工已经修改过摘要之后又被任务覆盖。还有一种边界情况要处理就是删除文章和重新生成摘要的并发操作。因为异步任务执行时文章可能已经被删了更新语句影响行数为0这种情况直接忽略即可。4.4 缓存策略Redis和本地缓存怎么配合文章摘要的读取路径是Controller - Service - 文章表。虽然只是多了一个字段但为了减少数据库压力我还是在摘要读取上加了两级缓存。第一级是本地缓存用Caffeine。摘要属于“同一篇文章固定不变”的数据非常适合放在进程内缓存。设置过期时间30分钟每次被读取时刷新TTL。成本极低、命中率极高。第二级是Redis。为什么还需要Redis因为博客是部署在多实例的虽然单机本地缓存的命中率已经很高但实例之间的数据一致性没法保证。万一摘要被重新生成比如管理员点了“重新生成”按钮其他实例的本地缓存还是旧数据最短要等30分钟才能更新。所以在写摘要的时候我会主动更新Redis里的摘要值并让本地缓存短暂失效通过版本号机制控制。我的最终方案是读请求先查Caffeine未命中再查Redis再未命中才走数据库。写请求同时更新Redis并删除本地缓存。这套组合在博客这种“读多写极少”的场景下几乎不会出现缓存不一致问题。5. 文章发布触发和存量文章回填5.1 新文章发布时触发AI摘要的完整时序新文章的触发链路是这样的用户在前台编辑器发布文章后台服务保存文章基本信息summary_status初始化为NO_SUMMARY保存成功后发布一条Spring事件ArticlePublishedEvent在事件监听器里将生成摘要的任务提交到aiSummaryExecutor线程池异步任务执行时先检查summary_status如果已经是MANUAL则跳过调用预处理、Prompt构建、模型生成、后处理安全校验全程通过则更新summary和summary_status失败则进入失败重试流程无论成功失败都会记录一条日志包含文章ID、耗时、Token消耗、模型返回码。用Spring事件而不是直接在保存逻辑后面调方法好处是解耦。将来如果摘要生成改成长任务队列或者引入MQ只需要换掉监听器实现不需要动文章保存逻辑。5.2 存量文章批量回填的思路和实现存量文章的回填是另一个话题。博客里有几百篇文章都处于NO_SUMMARY状态。如果写个循环挨个生成不仅串行慢而且很容易触发模型供应商的限流。我的做法是做一个批量回填的管理接口入参是文章ID列表支持传空表示“全部未生成的任务”。接口内部严格限速固定每次只提交20篇文章的处理任务每篇之间至少间隔5秒。关键是引入了一个简单的“处理中”标记用Redis记录哪些文章正在生成中避免同一个管理页面被重复点击后导致同一条文章被并发处理。说实话纯技术实现不复杂但批量回填的体验非常考验耐心——几百篇文章跑完要几十分钟。我中间把它改成后台任务直接优化成了“提交后显示进度条轮询”的形式。5.3 人工摘要与AI摘要的优先级管理实际运营中一定会遇到“AI生成的摘要不合适我想自己改”的情况。我的处理原则是“人工永远优先”。后台编辑器新增了一个“摘要来源”的切换控件默认是AI生成但允许用户打开文章在编辑器里直接修改summary。一旦用户手动编辑过summarysummary_status就变成MANUAL。之后所有定时任务、批量回填、重新生成操作都会先检查状态MANUAL的一律跳过。6. 实测数据与踩坑记录6.1 延迟、成本、摘要质量三项指标我先放一组实测数据供大家对照自己的项目做个预期管理指标实测值备注AI摘要生成平均耗时2.3秒不含排队等待时间AI摘要生成P95耗时4.7秒受模型服务负载影响每篇摘要平均Token消耗约600 Tokens输入约450输出约150单篇摘要成本估算约0.001到0.003元因供应商定价而异摘要可接受率人工评估约85%失败和跑偏约占15%从成本角度看博客的访问量级下根本不需要考虑优化费用。但Token的浪费问题值得注意——不少请求的输入Token是因为正文清洗不彻底而白白付掉的。我建议大家都给自己的项目加一个“Token监控日志”记录每次调用的输入Token、输出Token和耗时至少能让你知道钱花在哪了。6.2 踩坑一连接池耗尽导致正常业务接口超时这是上线当天遇到的最严重问题。现象是摘要任务一跑起来博客文章列表接口就大面积超时日志里大量TimeoutException。排查过程是这样的先看异常堆栈发现超时发生在RestTemplate调用大模型接口的代码上但文章列表接口不应该依赖这个调用。再向下追发现问题的根因是HTTP连接池被摘要任务占满了。我用的HTTP客户端默认连接池大小是50摘要任务组一启动20篇文章同时生成摘要每篇调用至少占用一个连接很快把连接池挤占完毕。其他业务接口去请求外部资源时已经拿不到空闲连接只能排队等待最终超时。我做了两个修复为核心业务接口单独配置了一个独立连接池通过不同的RestTemplateBean来区分摘要任务的HTTP请求改为使用单独的连接池配置核心线程数调整为3同时在请求级别设置3秒连接超时、9秒读取超时。修复后摘要任务和业务请求之间的资源竞争基本消除。这也是我前面强调“线程池核心数不要开太大”的原因——阻塞型任务的开大线程数未必能提速反而会拖垮其他依赖同一批资源的调用。6.3 踩坑二文章内容长度超出模型的上下文窗口有一篇长文我做了截断处理就提交了结果模型报错说请求过大。逐层排查后发现是我的截断逻辑有问题Jsoup清洗后的字符数达到4000时我直接用了substring(0, 4000)但这个4000是Java的字符数Token是另一个概念。如果正文包含大量中文4000个字符可能对应4000甚至5000个Token而模型上下文窗口加上Prompt本身很容易超限。修复方式在做文本截断时从“按字符截断”改成“尽量按句截断”避免一句话在中途被切碎同时把截断指标调整为“不超过模型窗口的60%”给Prompt和输出留足空间。这个细节不算复杂但如果不测等到上线发现报错再排查会很被动。6.4 踩坑三模型返回内容偶尔携带Markdown格式或引号模型默认的返回风格偶尔会带上一堆解释性文字比如“以下是摘要”或者给摘要加粗、加列表甚至加上引号。我的后处理代码里虽然有replace清理首尾引号但遇到带列表符号的反馈就处理不干净。最后通过在Prompt里增加“直接输出摘要正文不要输出任何多余内容”来大幅降低这种概率同时在后处理里再加一道“去Markdown符号”的清洗private String cleanMarkdownArtifacts(String raw) { return raw.replaceAll(^\\s*[-*]\\s*, ) .replaceAll(^#{1,6}\\s*, ) .replaceAll(\\*\\*(.?)\\*\\*, $1) .trim(); }6.5 性能优化虚拟线程在Spring Boot中实测对AI调用吞吐的提升在配置Java 21虚拟线程之后我用简单的压力脚本测试了AI摘要接口的并发表现。测试场景是5个并发请求同时触发摘要生成每个请求内部等待模型接口返回约2秒。传统平台线程模式下Tomcat缺省200线程中每个请求各占一个线程虽然也能处理但线程栈在等待IO时白白占用内存。虚拟线程模式下等待期间线程会被挂起并且几乎不占资源实测Tomcat工作线程占用从5个降为接近1个整体内存占用下降了约20%。对博客这种并发不高的业务来说提升不算亮眼但在成本受限的服务器上积少成多。如果哪天你要把AI摘要从异步改成流式逐字输出虚拟线程的价值会进一步放大——因为SSE连接会长时间占用线程。7. 功能扩展从摘要到更多AI能力的思考摘要是第一块敲门砖。功能落地之后我又顺手做了两个小扩展这里简单分享一下作为后续迭代的参考。第一个是标签自动生成。把文章内容交给模型让它输出三到五个标签语义上比手工维护标签更细。实现上复用了一套异步任务流程和一个新的Prompt模板改动非常小。第二个是按需重新生成。后台列表里每篇文章增加一个“重新生成摘要”按钮同时记录每次生成的历史版本方便对比不同批次Prompt调优后的效果差异。这个功能我最推荐大家加——因为你改一次Prompt之后往往需要回看旧文章的摘要才能判断改动是否值得。事实上AI摘要功能做到这一步最大的价值已经不只是“省人工”而是让你摸清了从“接一个大模型接口”到“稳定上线一个AI特性”之间所有的工程环节。下次再做AI相关功能比如智能搜索、文章分类、语音导读替换这套异步任务、缓存、重试、安全校验的框架基本可以平级复用。