这一讲是“基于SpringBootVue前后端分离的AI博客系统”系列的第七十九讲主题是创作中心。到这个阶段读者应该已经见过完整的用户体系、文章列表、分类标签、评论管理这些“常规博客模块”是怎么一步步搭出来的。但真正让这套系统区别于传统博客的是创作中心。它不是一个套着“新文章”页面的编辑器也不是简单地在页面上加一个“AI生成”按钮。它是整个系统中人和AI发生协作最密集的地方也是前后端交互链路最长、数据状态最容易失控的地方。所以我想先把观点放在前面AI博客系统的创作中心难点并不在于把某个大模型接口接进来而在于把“AI生成—人工修改—再次生成—审校—发布”这套流程定义清楚。如果只追求跑通接口很容易写出一坨临时代码功能看起来都有但每次改动都要全局排查如果能在前期先把创作中心拆成清晰的工作流和数据状态后续接任何模型、改任何前段交互都不会慌乱。这一讲我们就围绕“如何把这个模块做成真正可维护的工作台”展开。1. 先给创作中心一个准确定位不是编辑器是AI写作工作台1.1 为什么不能把创作中心做成一个“带AI按钮的编辑器”我见过不少从传统博客改造过来的项目做法很直接文章编辑页不变只是在工具栏上加了两个按钮一个是“生成标题”一个是“生成正文”点击后调用后端接口把返回的文本塞进富文本编辑器的内容里。这个方案看起来开发量很小实际使用时会发现两个问题。第一个问题AI生成的正文经常是半成品可能带着提问式的开头、重复段落、错误陈述甚至看起来合理但没有依据的细节。用户需要的是“对照着修改”而不是“一键接受”。如果把生成内容直接当作正文用户要么被迫进入“全文手改”的状态要么干脆不管直接发布。第二个问题AI生成过程通常不是一次性的用户往往会说“换一种语气”“扩写第三段”“把这段改成小标题形式”。这些操作如果都通过编辑器的内容替换来实现很快正文就会乱成一团用户也不知道哪段是AI写的、改过几次、原始版本什么样。所以创作中心不能只是一个编辑器它更像一个带任务管理能力的工作台。用户在这个页面里可以在多个“AI动作”之间来回切换比如生成初稿、润色当前段落、总结已有内容、生成摘要和标签而不再是一整个页面只处理一篇最终的HTML。1.2 创作中心要承载的四段式链路从功能上拆我建议把创作中心理解成一条生产链路而不是一个页面。第一段是“生成前”。用户在创建文章或创作任务时需要输入主题、目标读者、字数要求、语气偏好等结构化信息。这里的关键不是把一堆参数交给后端而是先形成“创作意图”。如果系统连用户要写的是技术教程还是个人随笔都没区分AI生成的结果往往只有词句正确方向错误。第二段是“生成与修改”。系统生成初稿之后用户进入编辑器可以围绕整篇文章操作也可以针对某个具体段落做局部优化。这个环节前端要提供“接受”“丢弃”“重新生成”三个动作后端要能记录每一次生成请求和对应的内容快照。第三段是“审校”。技术博客作者通常需要检查代码块、链接、术语名、敏感词和基本事实。创作中心可以把合规校验、敏感词检查、格式检查做成一个“预检清单”在用户点击发布前先跑一遍而不是等文章上线后再由后台人工处理。第四段才是“发布”。发布时不是直接把当前编辑区内容写入文章表就行还需要把摘要、标签、封面、目录结构一起写入或者推给后续的审核队列。如果前期没有拆分好发布这一步会变得很重一个接口里既要处理AI生成又要处理文章保存出问题时很难定位。1.3 在这种链路下界面模块和系统角色会怎么切前端页面上我见过最清晰的布局是两栏到三栏结构。左侧是“会话/任务列表”展示当前用户的创作任务中间是正文编辑区负责人工修改右侧是“AI操作台”用于选择生成模式、查看生成结果、发送局部指令、查看历史版本。后端模块也可以顺着这条链路划分任务编排、AI调用、正文存储、历史记录、内容预检。编写时让每个领域模块各管一段不要让“文案Repository”既写正文又写AI日志也不要让“AiController”直接调用“文章Mapper”去维护主表。我们经常说前后端分离不只是在部署上分离更重要的是在思维上把页面状态和后端状态分开管理。前端关注的是“当前用户在编辑什么、AI正在返回什么”后端关注的是“这个创作任务处于什么状态、用户有没有权限执行这次AI操作、生成内容是否合规”。这样定位之后后面每个接口的设计都会变得有规律。2. 从数据模型和状态流转说起没有状态机创作中心会越写越乱2.1 创作中心的数据主体不是文章表而是“创作任务”很多团队在设计博客系统时文章表是核心一张article表包含标题、正文、摘要、状态字段。等到要支持AI写作时就在同一张表上不断加字段比如ai_model、ai_prompt、ai_generated。这样并不是不行但当一篇文章会被反复生成、修改、回滚时一张扁平的表很难回答下面这些问题用户在一次AI生成后人工没有做大改动过了一天换了个模型版本希望重新生成但需要保留原来的版本。用户在编辑第3段时让AI扩写扩写结果不满意想看到上一次手动保存的内容。管理员需要审计这句话到底是不是AI生成的或者在生成过程中出现了敏感内容要追溯流程。如果直接用文章表记录最终状态这些需求会变得非常别扭。更合适的做法是引入“创作任务”这个中间概念。创作任务并不等于文章。一条创作任务可以关联零篇或一篇文章草稿它主要记录的是一件事用户如何从一句话意图走向一篇可发布的内容。任务表里面有task_id、user_id、topic、task_status、current_version等字段正文内容则独立保存到document或version表中。也就是说用户每次点击“AI生成”系统是为这个任务增加一个生成事件而不是直接覆盖现有正文。2.2 核心状态如何流转创作任务建议使用一组明确的状态不要在代码里用字符串到处表示状态而是抽成枚举或配置表。一个比较朴素的流转是这样的状态含义可以进入的下一状态DRAFTING用户正在设定主题和写作要求AI_GENERATING, SUBMITTEDAI_GENERATING后端正在调用模型生成内容DRAFTING, FAILED, COMPLETEDAI_COMPLETED生成完成等待用户确认或编辑DRAFTING, SUBMITTED, FAILEDAI_FAILED生成结果异常提示用户重新尝试DRAFTINGSUBMITTED用户点击提交审校UNDER_REVIEW, DRAFTINGUNDER_REVIEW管理员或机器人审校中PUBLISHED, REJECTED, DRAFTINGPUBLISHED已发布DRAFTING如果允许撤回修改REJECTED审校驳回需要修改DRAFTING, SUBMITTED这里最关键的一点是状态机的作用不是限制用户而是保证“生成中”的时候用户不会重复提交“已提交”的时候用户不会绕过审核直接改正文。每次状态变更都能被记录这也为后续的日志排查提供了基础。2.3 后端接口怎么配合一个Controller还是多个领域接口工程上常见的是不要在ArticleController里把所有接口都堆完。创作中心至少需要这么几组接口创作任务接口创建任务、修改主题、查询任务列表、删除任务。编辑内容接口获取正文内容、保存草稿、回滚到某个版本、上传本地图片。AI动作接口发起生成、发起重写、查询生成状态、获取生成结果、取消生成。内容预检接口敏感词检测、格式检查、代码块检测。发布接口提交审校、确认发布。每组接口对应一个独立的Controller或聚合服务。这样做不是为了看起来模块化而是因为AI动作接口通常依赖异步任务和普通的文章增删改查的生命周期不一样混在一起会很难处理事务和异常。2.4 为什么历史记录和版本要一开始就做创作中心有一个很特殊的需求用户可能让AI生成一段文字然后人工改了几轮最后又想让AI基于当前版本重新续写。这时候如果找不到历史版本操作就没法做。我建议从第一版就加入版本机制而不是等到用户投诉“内容丢失”了再补。最简单的方式是在document_version表里记录version、content、operation_type、source_type是AI生成还是人工保存、creator、created_at。每次保存或生成完成后都创建一条新版本。前端界面上只需要一个“历史版本”抽屉用户就能在不同版本之间自由切换。这块设计能让后面的“可回溯”能力省一大半力气同时也是AI博客系统区别于普通博客编辑器的核心亮点之一。3. 前端Vue侧的落地思路把编辑器、流式输出和任务状态解耦3.1 页面框架左侧任务、中间编辑、右侧AI控制台Vue项目中推荐把创作中心做成一个独立的路由例如/creator或/write而不是复用普通的新建文章页面。页面级组件建议这样拆分CreatorPage.vue负责加载路由参数、初始化Store、控制整体布局。TaskListPanel.vue展示当前用户的创作任务列表可搜索、创建和删除任务。EditorPanel.vue包含Markdown编辑器或富文本编辑器监听外部传入的正文内容变化。AiControlPanel.vue展示AI操作方式、生成参数、流式返回结果和操作按钮。VersionHistoryDrawer.vue展示历史版本支持预览和回滚。用Vue 3的组合式API来做核心状态不放在某个组件的ref里而是抽到Pinia中。至少需要有currentTask、content、contentDirty、aiStatus、streamText这几个状态。这样拆的情况下编辑器组件和AI控制台组件并不直接通信。编辑器只负责“把传入内容交给编辑器和把编辑器内容回传”AI控制台只负责“告诉Store要执行什么AI动作并展示状态”。真正协调逻辑的是一层创作中心的状态管理这样才能在用户切换任务时避免正文混乱。3.2 不能把AI回复直接set进正文需要“生成区”和“正文区”这是新手最容易踩的坑。当AI开始输出时如果直接用editor.setContent(streamText)整个编辑器会被反复重绘用户的光标位置也会乱跳。而且用户可能只是想参考AI生成的内容并不想立刻覆盖自己的正文。更合理的做法是把AI回复先渲染到一个“结果预览区”让用户看到内容然后用户点击“插入到正文”或“替换当前选中内容”之后才写入编辑器。在AI控制台里我们也可以把“生成整篇”“生成标题”“扩写选中段”“重写当前段”这些操作做成不同的模式。这样前端的数据流是单方向的用户从AI控制台选择操作类型填写指令。Store发起AI请求。后端通过SSE或WebSocket逐个返回文本块。Store将收到的文本块追加到previewText。用户确认后EditorPanel接收到最新的正文内容再更新编辑器。这个模式下编辑器仍然是普通编辑器AI控制台天然不会干扰正在编辑的光标代码逻辑也清晰。3.3 流式输出用什么SSE还是WebSocket从技术选型角度AI文本生成并不需要双向通信大部分流程是客户端发起请求服务端持续返回生成结果。与WebSocket相比SSE更轻量自动支持断线重连而且基于标准HTTP在SpringBoot中配合SseEmitter或响应式WebFlux实现都比较方便。如果系统里还有其他实时协作需求比如多人同时编辑同一篇文章那WebSocket可能是更好的底座。但如果只是让创作中心支持AI流式输出我更建议从SSE开始起步等真的出现双向消息需求再升级。不要因为看到“AI都要流式”就先引入WebSocket然后为了维护连接状态增加很多复杂度。前端使用fetch配合ReadableStream读取SSE响应是比较常见的做法。一个结构示意是这样的const response await fetch(/api/ai/generate, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ taskId, action, prompt }), }); const reader response.body.getReader(); const decoder new TextDecoder(); let content ; while (true) { const { value, done } await reader.read(); if (done) break; content decoder.decode(value, { stream: true }); aiStore.updatePreviewText(content); }如果使用的是SpringBoot的SseEmitter后端发送的数据格式通常是一行data: ...再加空行。前端需要按事件流格式解析。如果项目封装了EventSource也可以直接使用。需要注意浏览器原生EventSource只支持GET请求如果AI生成需要传入较长的参数建议使用POST fetch stream的方式或者做一层POST到任务ID再订阅的转换避免把长文本塞到URL里。3.4 用Store管理创作上下文而不是只在组件内维护创作中心是一个天然的多组件共享状态页面。用户在任务列表选中任务时正文编辑区和AI控制台都要响应AI生成完成后任务列表里的状态也要从“生成中”变成“已完成”。这种跨组件联动如果用emit去逐层传递代码很快会变成意大利面条。建议在Pinia中创建一个useCreatorStore内部维护任务对象、当前文档内容、AI执行状态、最近的操作记录。所有组件都只调用Store的action事件逻辑收敛到一个文件里。这样新增一个AI动作时不需要到处找组件通信。Store示例结构可以是export const useCreatorStore defineStore(creator, { state: () ({ currentTask: null as Task | null, document: { title: , content: }, aiStatus: idle as idle | streaming | failed, previewText: , versions: [] as DocumentVersion[], }), getters: { canSubmit: (state) state.currentTask?.status ! AI_GENERATING, }, actions: { async loadTask(taskId) { ... }, async generate(option: AiGenerateOption) { ... }, async acceptGenerated() { ... }, async saveDraft() { ... }, }, });这样的设计让调用方很简洁比如AI控制台组件只需要store.generate({ action: rewrite, target: selected, prompt: ... })即可。4. 后端SpringBoot侧的重心AI能力接入与业务隔离4.1 用接口把AI供应商隔离在业务之外AI博客系统的后端不能把业务代码和大模型SDK强耦合。最好的做法是定义一个AiProvider接口里面只暴露几个业务含义明确的方法比如generateAsync、cancel、streamGenerate。具体是调国内模型还是国外模型是通过HTTP还是SDK都封装在实现类里。接口设计可以这样简单public interface AiProvider { String generateText(String prompt, AiGenerateOptions options); void streamGenerate(String prompt, AiGenerateOptions options, SseEmitter emitter); boolean supportsStream(); String providerName(); }这里面的AiGenerateOptions可能包括model、temperature、maxTokens、stopSequences等。业务层只依赖AiProvider接口不关心具体模型名称。切换供应商时只需要通过配置创建不同的Bean或者使用策略模式按配置加载。这样创作中心不会因为模型版本调整而大面积重写。我还建议在项目里把“AI生成”和“AI模型的原始能力”分开。比如业务上有generateOutline、rewriteParagraph、generateSummary等动作但这些动作底层都调用同一个AiProvider。业务层应当维护“动作记录”而不是直接从Controller调用底层模型。这样以后想统计某个动作的失败率、耗时时数据更容易拿到。4.2 Prompt模板管理Prompt也是配置不是代码里的字符串很多AI功能开发初期把Prompt直接写在Java代码里String prompt 你现在是一个博客专家请帮用户生成一篇关于 title 的文章;这样做对于单机Demo没有大问题但一旦产品运营想要调整AI人设、优化语气或者针对不同栏目使用不同的Prompt就得重新发版。更合理的是把Prompt模板放到数据库或配置中心通过Key去索引。一个通用的模板结构可以是{ templateKey: blog.article.generate.firstDraft, action: generate, systemPrompt: 你是一个中文技术博客写作助手…, userPromptTemplate: 请围绕“${topic}”写一篇${wordCount}字左右的技术博客目标读者是${audience}语气要求${tone}。, params: [topic, wordCount, audience, tone], model: default, temperature: 0.7 }在管理后台里做成一个“提示词模板管理”页面后产品人员不需要懂代码也能调整写作风格。同时前端在发起AI生成时也不需要把一大段人话透传到底层模型而是把动作和参数传给后端由后端根据模板组合成完整Prompt。这里有一个容易忽略的点如果把用户输入的原始文本直接拼进Prompt可能造成输入注入也就是用户通过正文内容“指挥”AI忽略系统约束。在做Prompt模板时至少要做两件事一是把用户输入作为数据变量处理不要让它在模板里拥有指令地位二是在调用前后分别记录模板内容和用户输入方便出问题时定位。4.3 AI生成后要不要再过一道内容检查要而且要提前设计。AI生成内容不是必然合规的尤其是技术博客还可能涉及代码片段、链接和外链。创作中心需要在“生成完成”和“提交发布”之间加内容预检步骤。检查可以分为几个层级基础过滤对敏感词、违禁词做匹配和标记。格式检查代码块是否闭合、标题层级是否正常、是否需要图片的占位符。质量标记判断内容长度是否过短、是否大量重复、是否包含明显的AI套话。人工审核辅助在后台界面里高亮“疑似AI味较重的句子”或“可能涉及敏感内容的片段”。需要注意的是这些检查不一定要等到发布后才做。用户点击“提交审核”前可以先跑一次预检把结果反馈到前端。例如某一段被标记为疑似重复系统弹出提示让用户决定是否修改。这样既能降低最终发布的风险也避免用户感觉被强制拦截。4.4 异步化与任务状态回写不能一直占着HTTP请求调用大模型生成一篇文章可能需要几十秒甚至更久。如果Controller直接同步等待模型返回前端请求会超时HTTP连接也会被长期占用非常影响网关和其他请求的处理。常见的做法是把AI生成任务丢到异步线程池或消息队列里执行。具体链路是Controller接收生成请求创建AiTask记录并返回任务编号。异步线程从任务队列里取出消息调用AiProvider。通过SSE或WebSocket把生成进度推送给前端。生成结束后把最终内容和状态回写到数据库。前端收到“完成”事件后刷新页面内容。刚开始做的时候可以使用Async加一个线程池先不引入更重的MQ。但如果团队已经使用了Kafka、RocketMQ这类中间件把它们用于AI任务队列也是合理的。关键是不要把AI调用写成同步方法塞在文章保存接口里。使用Async时要注意事务边界和线程私有变量很容易出问题。比如在异步方法里直接使用UserContext拿到登录用户很可能取不到。需要在一开始就把必要的用户ID、任务ID作为方法参数传进去而不是依赖ThreadLocal传递上下文。4.5 限流、重试和超时处理AI生成是昂贵且不稳定的操作。后端必须限制单个用户的并发请求数量否则用户不小心多点几次生成可能会瞬间打满模型配额甚至造成资源浪费。限流规则可以分两层用户维度允许同一个用户同时最多执行一个或两个生成任务。接口维度按API路径设置每分钟最大请求数可以使用简单的计数器或成熟限流组件实现。重试策略也要设定好。对于网络超时、HTTP 5xx这类异常可以自动重试一次或两次对于参数错误、内容审核拦截则不应该重试。重试时要注意幂等性避免同一个生成动作产生多条重复记录。所以每个AI动作在前端最好生成一个requestId后端用这个ID做防重。超时设置也不宜过长。初次生成一篇文章可能需要很长时间可以让前端轮询或通过SSE接收状态。但如果一个任务超过了配置的阈值例如10分钟还没完成就应该被标记为超时让用户可以选择取消或重试。5. AI生成与人工修改的边界最容易被忽视的“可回溯”设计5.1 为什么要记录“哪一段是AI生成的”传统博客里一篇文章一旦保存内容是谁写的就是谁的。但在AI博客系统中作者和AI经常合作完成一篇文章。如果不记录AI生成的部分会带来几个实际问题用户无法知道当前正文的某一段是不是AI生成的后续如果组织要求对AI生成内容做标注系统无法支持。用户对某一段反复生成多次后不知道最终采用了哪个结果也无法对比。审核人员在排查问题时想看某段文本是在哪次AI调用中产生但没有入口。这并不是要求每条文本都打上“AI生成”的标记显示给访客而是在后台保留审计信息。对于企业内部知识管理、内容平台审核这类信息非常重要。5.2 怎么记录块级元信息、操作日志和引用来源对于创作中心我们不需要把一整篇的文章都拆成严格的“块级编辑器”那么复杂但至少可以记录这样几类信息文档版本表中记录当前版本的正文内容。每个版本上有一个change_events列表说明这个版本经历了哪些操作比如“用户输入”“AI生成”“接受AI结果”“手动修改”。可以给内容分块比如按标题分章节每个章节记录isAiGenerated、sourceTaskId。简单做法是为每个AI动作生成一条日志内容包括request_id、task_id、action、source_text如果有、generated_text、accepted_at。当用户点击“接受生成结果”时把生成结果写入正文同时把来源日志关联到当前段落或版本。这个设计还有一个实际好处允许按照“AI来源”重组内容。比如用户觉得整篇生成的结构不对但第三小节写得很好就可以只保留第三小节其他部分重新生成。有了块级来源记录前端可以做“保留当前段重新生成全文”而不是只能一刀切替换。5.3 让“生成—人工修改—再生成”形成循环AI写作系统真正好用的状态不是让AI一锤定音而是让作者处于可以随时把当前内容再次作为上下文交给AI的循环里。比如用户写了一段技术说明感觉不够通俗于是选中这段文字点击“用更容易理解的语言重写”。后端此时要做的不是重新编一段话而是把选中的原文、用户的额外要求和整篇文档的大纲一起组织成Prompt生成结果后返回预览。为了支撑“上下文”能力前端在发起局部改写时要传当前选中区域的完整文本还可以传前后几个段落的文本作为上下文。后端根据模板拼装成模型可理解的指令。代码上需要注意“选中区域”这块不能太大否则Token消耗可能过高。在页面上应该加上字数提示某个区域超过多少字时建议用户拆成小段再处理。这个工作流也说明创作中心应当保持一个稳定的“编辑上下文”而不是每次AI调用都只传两三句话。系统内部可以保存文章的目录树和大纲用户修改了某个小标题后后续AI续写时应该优先使用最新的小标题结构。要实现这个效果后端从文档内容里解析大纲是必不可少的一步。5.4 提示词工程在系统里的落点不是单个输入框在纯Chat界面里提示词工程的问题是对话层面的但在博客系统创作中心提示词工程要有更细的落点。系统预先配置了一组针对博客场景的“动作模板”每个模板对应一个提示词和参数。例如生成标题接收用户主题和文章概要返回5个候选标题。生成大纲接收主题、目标读者和文章类型返回带层级的Markdown目录。生成初稿接收大纲、写作要求返回完整文章。扩写段落接收当前段落、相邻段落、扩写要求返回更详细的段落内容。改写语气接收当前段落、目标语气返回改写后的结果。前端只需要在一个下拉框里选择“动作”而不是让用户面对一个空白的模型接口。对于有一定Prompt能力的用户我们还可以提供“自定义指令”入口但不建议把自定义指令做成主操作。否则用户每篇都要思考怎么提问反而会破坏写作节奏。同时系统可以记录不同动作模板的成功率、返回长度、用户“接受率”。当用户多次对“生成初稿”模板产生的结果不满意时运营人员可以针对性地优化该系统提示词。这就是把提示词工程从“技术人员的调试过程”提升为“内容产品的运营能力”。6. 这一模块最值得工程化沉淀的地方一个可复用的AI任务工作台6.1 从垂直系统里抽取“AI动作”抽象虽然这一篇讲的是AI博客系统但创作中心里的很多设计思路可以推广到其他内容型系统。比如AI客服工单系统、AI营销文案系统、AI编程助手的前端界面都会有类似的链路用户发起意图、系统进入生成中状态、结果流式返回、用户选择接受、操作留痕。所以我在搭建这个模块时会额外抽出一套“AI动作”抽象public interface AiAction { String actionKey(); PromptTemplate promptTemplate(); AiActionType type(); // CONTINUE, REWRITE, GENERATE boolean isStream(); int maxConcurrentPerUser(); }每一种业务动作都实现这个接口。创作中心里定义了blog.article.generate、blog.article.rewrite、blog.article.expand等动作。以后做别的模块比如“AI生成标签”或“AI生成摘要”也可以复用同一个基础流程。这样做最大的收益是限流、日志、审计、Mock、重试这些横切逻辑不需要在每个业务方法里重复写可以通过一个执行器统一处理。前端也可以根据动作配置动态渲染参数表单避免每个页面单独开发一套交互控件。6.2 一个AI任务定义的常见结构如果项目里要持久化AI任务我建议大概包含这些字段id 主键 app_module 所属模块creator、comment、admin... task_type 动作类型generate、rewrite... request_id 前端生成的幂等ID user_id 发起用户 title 任务标题便于后台查看 prompt 实际发送给模型的完整提示词 input_text 用户输入的原文或上下文 output_text 模型返回的结果 status PENDING/RUNNING/SUCCESS/FAILED/CANCELED model_name 实际使用的模型标识 token_count 输入和输出的Token数量 cost 本次调用费用如果有的话 error_code 异常码 error_message 异常信息 started_at 开始时间 finished_at 完成时间有了这样一个表创作中心可以对用户展示“生成记录”让用户看到每次生成消耗的字数、耗时和状态。管理员也可以用它做成本统计和质量跟踪。这里的细节是为了让AI调用不只是“一个黑盒”而是系统可观测的一部分。6.3 适用边界哪些场景适合这个方案哪些不适合这套“创作中心”设计并不适合所有项目。如果你的系统只是个人博客文章量很小AI生成只是把一个文本块手动粘到编辑器里那完全可以不用建任务表、版本表也不用做SSE流式输出。但如果是以下场景就很值得参考博客系统面向多个用户每个用户都需要在固定工作台里进行AI创作。内容需要经过审核流程要追溯某段内容的来源。需要支持AI生成结果的局部采纳、回滚和再次生成。管理员需要查看用户的AI调用量、成功率和成本。团队后续还要做AI辅助写小说、AI辅助生成产品文案等相似模块。边界同样重要如果团队没有现成的模型网关或统一API不建议使用“AI Provider”这种过度抽象来一开始就搭建一套跨国模型调度体系。先在本地写一个MockAiProvider然后把创作流程跑通再接入真实模型即可。6.4 上线前建议按这个顺序检查如果这一讲的内容要被你直接落进项目有一个我常用的检查顺序可以参考。第一步跑通一个小样本的“生成→接受→发布”链路。先不引入推送和流式只通过同步接口确认数据能保存。这个步骤是为了验证业务闭环。第二步替换为异步执行用SSE返回生成结果。此时要处理用户重复点击、取消连接、前端断线重连等问题。第三步加入多版本和历史记录。用户在不同版本间切换确认切换不会丢失当前未保存的修改必要时做“切换前必须保存或放弃”的拦截。第四步加入内容预检和合规过滤。确认发布前能看到检查结果检查项异常会被标记并阻止提交。第五步做权限和限流。区分普通用户和管理员确认普通用户不能直接绕过创作中心去调用后端AI接口确认接口不会被脚本刷爆。最后补上日志和监控。统计AI调用的平均耗时、失败率、Token消耗设置异常告警。只有完成这一步系统才算从“能演示”进入“能长期运行”。回到这一讲最初的问题SpringBootVue前后端分离本身并不稀罕稀罕的是如何在两个端之间把一个涉及模型、流式、异步、版本和审核的创作流程组织得干净。创作中心如果做得好它会成为整个AI博客系统体验最好的地方也会成为后续所有AI功能复用的底座。如果你正准备开发类似的模块建议不要急着先写接口而是先把任务状态流转、正文版本、AI动作三个模型画清楚。这三件事想明白了剩下的前端UI和后端接口都只是把它们填进具体场景而已。