企业官网建设流程全解析

1. 项目缘起与整体架构设计

1.1 为什么选择 Bmob 后端云作为 AI 应用底座

做 AI 润色类应用最头疼的事情，往往不是模型本身，而是后端那一堆琐事：用户体系、数据存储、接口鉴权、文件管理、消息推送。如果从零搭一套，光是用户注册登录加权限控制就够折腾一周。我试过自己用云主机搭 Node 服务，也试过纯前端直连模型接口，最后发现 Bmob 后端云这种“开箱即用”的方案在中小型 AI 工具类项目里性价比最高。

Bmob 的核心价值在于它把后端能力做成了 SDK 调用。你不需要写一行服务端代码，就能拿到数据表、用户系统、ACL 权限控制、云函数、实时通信这些能力。对于 AI 润色这种场景——用户提交一段文字，后端调用模型推理，返回润色结果——Bmob 的云函数刚好可以作为推理请求的中转层，既隐藏了模型密钥，又能做请求频率控制和结果缓存。

我最终确定的架构是：前端（Web/小程序）通过 Bmob SDK 提交待润色文本，Bmob 云函数接收请求后执行双层 AI 推理流程，第一层做意图识别和风格判定，第二层做实际润色生成，两层之间通过动态 Prompt 路由决定第二层用哪套提示词模板。整个链路的中间状态通过 SSE 推送给前端，让用户看到“正在分析风格”“正在润色”“正在校对”这样的实时进度，而不是干等一个转圈。

这个架构解决的核心问题是：传统单层 Prompt 润色出来的文字有明显的“AI 味”——句式工整但千篇一律，排比句滥用，形容词堆砌。双层推理加动态路由的本质，是让系统先理解“这段文字该用什么风格润色”，再决定“怎么润色”，而不是拿一个万能模板套所有输入。

1.2 双层 AI 推理到底在做什么

很多人第一次听到“双层推理”会觉得是在堆模型、堆算力，其实不是。双层推理的分工非常明确：

第一层叫分析层，任务轻、速度快、成本低。它只做三件事：判断文本类型（是公文、小红书文案、学术摘要还是朋友圈）、识别目标风格（正式、轻松、文艺、犀利）、提取关键约束（字数限制、必须保留的术语、敏感词规避）。这一层用轻量模型或者甚至规则引擎加小模型就能跑，响应时间控制在 300ms 以内。

第二层叫生成层，任务重、质量要求高。它拿到第一层的分析结果后，通过动态 Prompt 路由选择对应的提示词模板，再结合用户原文进行润色生成。这一层用能力更强的模型，温度参数也根据风格动态调整——正式风格温度调低到 0.3，创意风格调到 0.8。

两层之间不是简单的串行调用，中间有一个路由决策模块。这个模块根据第一层的输出，从 Prompt 模板库中选取最匹配的模板，同时决定是否要注入少样本示例、是否要启用思维链、是否要附加格式约束。这就是“动态 Prompt 路由”的含义——路由的不是网络请求，而是提示词策略。

我实测下来，双层方案比单层方案在“去 AI 味”这个指标上提升非常明显。单层方案润色出来的文字，用户一眼就能看出是机器写的；双层方案因为先做了风格适配，输出更贴近人工润色的质感。代价是推理耗时增加了约 40%，但通过 SSE 把中间进度推给用户，感知等待时间反而更短。

1.3 SSE 在推理链路中的角色定位

SSE（Server-Sent Events）是一种服务器向客户端单向推送数据的技术。它和 WebSocket 的区别在于：SSE 基于 HTTP 长连接，实现简单，自动重连，适合“服务器持续向客户端发送进度更新”这种场景；WebSocket 是双向通信，更适合聊天室、协同编辑这类需要客户端频繁发消息的场景。

在 AI 润色这个项目里，用户提交文本后，后端要经历“分析层推理→路由决策→生成层推理→后处理校对”四个阶段，总耗时可能 3 到 8 秒。如果不用 SSE，前端只能发一个请求然后等最终结果，用户盯着 loading 转圈会非常焦虑。用了 SSE 之后，每个阶段完成就推一条事件给前端，用户能看到“风格分析完成：检测为小红书种草文案”“正在匹配润色模板”“润色完成，正在校对敏感词”这样的进度，体验完全不一样。

Bmob 云函数本身不直接支持 SSE 长连接，因为云函数是无状态的短生命周期执行环境。我的做法是在云函数里把每个阶段的进度写入 Bmob 数据表的一条记录中，前端通过 Bmob 的实时数据监听功能订阅这条记录的变化。虽然这不是严格意义上的 SSE，但效果等价——前端能实时收到进度更新。如果项目部署在自己的服务器上，那就可以用标准的 SSE 接口，通过text/event-stream响应头保持连接。

注意：SSE 连接空闲超时是常见问题，默认情况下很多代理和网关会在 60 秒后断开空闲连接。如果你的推理链路可能超过这个时间，需要在服务端定期发送注释行（以冒号开头的空行）来保持连接活跃。

1.4 ACL 权限控制如何保护推理接口

ACL（Access Control List）在这个项目里承担两个职责：一是控制哪些用户可以调用推理云函数，二是控制推理结果数据的读写权限。

Bmob 的 ACL 机制是挂在每一条数据记录上的。比如用户提交的润色任务记录，ACL 设置为只有该用户可读可写，其他人一律拒绝。这样即使有人猜到了记录 ID，也读不到别人的润色内容。云函数层面的权限控制则通过 Bmob 的云函数权限设置来实现——可以配置为仅登录用户可调用，或者仅特定角色可调用。

我踩过的一个坑是：早期版本没有给推理任务表设置 ACL，结果测试时发现任何人只要遍历 objectId 就能看到别人的润色记录。后来统一在云函数里创建记录时显式设置 ACL，问题才解决。另一个坑是云函数的超时时间——Bmob 免费版云函数超时是 15 秒，双层推理加网络请求很容易超时，需要升级套餐或者把推理拆成两个云函数异步执行。

ACL 和推理接口的结合点还在于频率控制。我在云函数入口处加了一段逻辑：查询当前用户在过去 60 秒内创建的推理任务数量，超过 10 条就拒绝新请求。这个查询依赖 ACL 确保只能查到自己的记录，不会误判其他用户的行为。

2. 核心细节解析与实操要点

2.1 分析层推理的 Prompt 设计与输出解析

分析层的 Prompt 设计原则是“短、准、结构化”。我不需要模型输出一段自然语言分析，而是要求它返回严格的 JSON 格式，方便后续路由模块解析。实际使用的 Prompt 模板大致如下：

你是一个文本分析引擎。请分析以下文本，返回 JSON 格式结果： { "text_type": "公文/社交媒体/学术/通用", "target_style": "正式/轻松/文艺/犀利", "constraints": { "max_length": 数字或null, "preserve_terms": ["必须保留的术语列表"], "avoid_words": ["需要规避的词汇列表"] }, "confidence": 0.0到1.0之间的数字 } 待分析文本： {{user_input}}

这个 Prompt 的关键在于：字段名固定、枚举值固定、要求返回 JSON。模型输出后，我用正则提取 JSON 部分，如果解析失败就降级到默认路由（通用模板）。实测下来，用 7B 级别的小模型跑这个分析任务，准确率能到 85% 以上，响应时间在 200 到 400ms 之间。

有一个细节值得注意：confidence字段很重要。如果模型对风格判断的置信度低于 0.6，路由模块会走“保守策略”——选择通用模板而不是冒险用特定风格模板。这个阈值是我反复调整后确定的，太低会导致风格错配，太高会导致大量请求走通用模板失去动态路由的意义。

分析层的另一个实操要点是输入截断。用户可能提交几千字的文章，但分析层只需要看开头和结尾就能判断风格。我的做法是取前 500 字加后 200 字拼接后送入分析层，这样既控制了 token 消耗，又保留了足够的判断信息。实测截断后的分析准确率和全文分析相差不到 3 个百分点。

2.2 动态 Prompt 路由的决策逻辑与模板库管理

路由模块是整个系统的“大脑”。它接收分析层的 JSON 输出，然后从模板库中选取最合适的生成层 Prompt。模板库的结构是这样的：

路由决策的逻辑用伪代码表示：

def route_prompt(analysis_result): text_type = analysis_result["text_type"] style = analysis_result["target_style"] confidence = analysis_result["confidence"] if confidence < 0.6: return get_template("tpl_005") # 降级到通用模板 template = find_template(text_type, style) if template is None: template = find_template("通用", style) or get_template("tpl_005") # 根据约束条件动态调整 if analysis_result["constraints"]["max_length"]: template = inject_length_constraint(template, max_length) if analysis_result["constraints"]["preserve_terms"]: template = inject_preserve_terms(template, terms) return template

模板库的管理我建议用 Bmob 数据表来存，而不是硬编码在云函数里。这样调整模板不需要重新部署云函数，直接在 Bmob 后台改数据就行。每个模板记录包含：模板 ID、适用条件、Prompt 正文、温度参数、最大 token 数、是否启用。云函数启动时把模板库加载到内存缓存，每 5 分钟刷新一次。

动态路由还有一个进阶玩法：A/B 测试路由。对于同一个分析结果，可以配置多个候选模板，按一定比例分流，然后收集用户对润色结果的满意度评分（比如点赞/点踩），用数据驱动模板优化。我在项目里加了这个机制后，发现某些场景下“文艺”模板的满意度反而低于“轻松”模板，于是调整了路由权重。

2.3 生成层 Prompt 的组装与参数调优

生成层的 Prompt 组装遵循“角色设定 + 任务描述 + 约束条件 + 少样本示例 + 待润色文本”的结构。以小红书种草文案为例：

你是一位资深小红书博主，擅长用亲切自然的语气分享好物。 请对以下文案进行润色，要求： 1. 保持原意不变，但让语气更口语化 2. 适当加入emoji表情（不超过5个） 3. 使用短句，每句不超过20字 4. 必须保留以下术语：{{preserve_terms}} 5. 总字数控制在{{max_length}}字以内 参考风格示例： "姐妹们！这个真的绝了！我用了两周，皮肤状态肉眼可见变好。 不是那种假滑，是真的透亮。已经回购第三瓶了。" 待润色文案： {{user_input}}

温度参数的调优是生成层最关键的环节。我的经验值是：公文类 0.2-0.3，学术类 0.2-0.4，社交媒体轻松风格 0.6-0.8，创意文案 0.8-1.0。温度太低会导致输出死板，温度太高会偏离原意。我一般会为每个模板配置一个温度范围，然后在范围内随机取值，这样同一段文字多次润色会得到略有差异的结果，避免“公式化”。

另一个重要参数是top_p（核采样）。我通常设为 0.9，配合温度使用。对于需要严格保留术语的场景，还会加上frequency_penalty和presence_penalty来抑制重复用词。这些参数都存在模板记录里，路由时一并取出传给模型接口。

少样本示例的注入也有讲究。示例不是越多越好，2 到 3 个高质量示例效果最佳。示例要覆盖不同的输入风格，让模型理解“什么样的输入对应什么样的输出”。我维护了一个示例库，每个模板关联 3 到 5 个示例，路由时随机选 2 个注入。实测发现随机选择比固定示例更能避免输出模式化。

2.4 SSE 进度推送的数据格式与前端对接

进度推送的数据格式我设计得很简单，每条事件是一个 JSON：

{ "stage": "analysis", "status": "completed", "message": "风格分析完成：检测为社交媒体-轻松风格", "progress": 25, "timestamp": 1700000000000 }

stage字段标识当前阶段（analysis/routing/generation/postprocess），progress是 0 到 100 的进度百分比，前端根据这个画进度条。message是给用户看的提示文字，要通俗易懂，不要出现“推理”“路由”这种技术术语。

前端对接 SSE 的代码大致如下：

const eventSource = new EventSource('/api/polish/stream?taskId=' + taskId); eventSource.onmessage = (event) => { const data = JSON.parse(event.data); updateProgressBar(data.progress); updateStatusText(data.message); if (data.stage === 'postprocess' && data.status === 'completed') { eventSource.close(); fetchFinalResult(taskId); } }; eventSource.onerror = () => { // 自动重连由 EventSource 内部处理 // 但需要处理超过重试次数的情况 showRetryButton(); };

注意：SSE 的onerror在连接断开时触发，浏览器会自动尝试重连。但如果服务端返回了非 200 状态码，重连会失败。我遇到过因为鉴权 token 过期导致 SSE 连接被拒的情况，解决方案是在 URL 参数里带上短期有效的任务 token，而不是依赖 Cookie 鉴权。

如果项目部署在 Bmob 云函数上，无法直接用标准 SSE，那就用 Bmob 实时数据监听替代。前端订阅推理任务记录的progress字段变化，效果和 SSE 几乎一样。区别在于 Bmob 实时监听是基于 WebSocket 的，底层实现不同但使用体验一致。

3. 实操过程与核心环节实现

3.1 Bmob 项目初始化与数据表设计

第一步是在 Bmob 后台创建应用，拿到 Application ID 和 REST API Key。然后设计数据表，我建了三张核心表：

表一：polish_tasks（润色任务表）

表二：prompt_templates（模板库表）

表三：user_quotas（用户配额表）

ACL 设置：polish_tasks 表每条记录创建时设置{ userId: { read: true, write: true }, "*": { read: false, write: false } }。prompt_templates 表设置为所有人可读、仅管理员可写。user_quotas 表设置为仅本人可读、仅云函数可写。

3.2 云函数实现双层推理主流程

Bmob 云函数用 JavaScript 编写，部署后通过 SDK 调用。主流程云函数polishText的核心逻辑：

const Bmob = require('bmob'); Bmob.initialize('APP_ID', 'REST_API_KEY'); async function polishText(request, response) { const { text, userId } = request.body; // 1. 配额检查 const quota = await checkQuota(userId); if (!quota.allowed) { return response.error('今日润色次数已用完'); } // 2. 创建任务记录 const task = await Bmob.Table.create('polish_tasks', { userId: { __type: 'Pointer', className: '_User', objectId: userId }, originalText: text, status: 'processing', progress: 0, ACL: { [userId]: { read: true, write: true } } }); // 3. 分析层推理 await updateProgress(task.objectId, 10, '正在分析文本风格'); const analysisResult = await runAnalysisLayer(text); await updateProgress(task.objectId, 30, '风格分析完成'); // 4. 动态路由 const template = await routePrompt(analysisResult); await updateProgress(task.objectId, 40, '正在匹配润色模板'); // 5. 生成层推理 await updateProgress(task.objectId, 50, '正在润色'); const polishedText = await runGenerationLayer(text, template, analysisResult); await updateProgress(task.objectId, 85, '润色完成，正在校对'); // 6. 后处理 const finalText = await postProcess(polishedText, analysisResult.constraints); await updateProgress(task.objectId, 100, '完成'); // 7. 更新任务记录 await Bmob.Table.update('polish_tasks', task.objectId, { analysisResult, routedTemplate: template.templateId, polishedText: finalText, status: 'completed', progress: 100 }); // 8. 更新配额 await incrementQuota(userId); return response.success({ taskId: task.objectId, result: finalText }); }

updateProgress函数就是往 polish_tasks 表更新 progress 和 status 字段，前端通过 Bmob 实时监听这个记录的变化来获取进度。

3.3 分析层与生成层的模型调用封装

模型调用我封装了一个统一的callModel函数，支持传入不同的模型端点和参数：

async function callModel({ prompt, temperature, maxTokens, model }) { const startTime = Date.now(); const response = await fetch(MODEL_ENDPOINT, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${MODEL_API_KEY}` }, body: JSON.stringify({ model: model || 'default', messages: [{ role: 'user', content: prompt }], temperature: temperature || 0.5, max_tokens: maxTokens || 2000, top_p: 0.9 }) }); if (!response.ok) { throw new Error(`Model API error: ${response.status}`); } const data = await response.json(); const elapsed = Date.now() - startTime; // 记录耗时用于监控 console.log(`Model call: ${model}, ${elapsed}ms, tokens: ${data.usage?.total_tokens}`); return data.choices[0].message.content; }

分析层调用时model传轻量模型标识，maxTokens设为 500，temperature设为 0.1（分析任务需要稳定输出）。生成层调用时model传能力更强的模型标识，maxTokens根据模板配置，temperature从模板读取。

这里有一个重要的实操细节：超时控制。Bmob 云函数默认超时 15 秒，而双层推理加网络请求可能超过这个时间。我的解决方案是把生成层推理拆成独立的云函数，主云函数在调用生成层后立即返回“任务已创建”，生成层云函数异步执行完毕后更新任务记录。前端通过实时监听获取最终结果。这样每个云函数的执行时间都控制在 10 秒以内。

3.4 后处理与敏感词过滤的实现

后处理阶段做三件事：敏感词过滤、格式规范化、术语保留校验。

敏感词过滤我用的是 DFA（确定有限自动机）算法，把敏感词库构建成一棵树，扫描文本时逐字符匹配。相比正则匹配，DFA 的效率高很多，10 万条敏感词库扫描 1000 字文本只需要几毫秒。敏感词库存在 Bmob 数据表里，云函数启动时加载到内存。

格式规范化包括：去除多余空行、统一标点符号（中文文本用全角标点）、修正明显的语法错误。这一步用规则引擎就够了，不需要再调模型。

术语保留校验是检查分析层提取的preserve_terms是否都出现在润色结果中。如果有遗漏，就把遗漏的术语追加到 Prompt 里重新生成一次，或者手动插入到合适位置。我一般选择重新生成，因为手动插入可能破坏语句通顺度。

function postProcess(text, constraints) { let result = text; // 敏感词过滤 result = filterSensitiveWords(result); // 格式规范化 result = normalizeFormat(result); // 术语保留校验 const missingTerms = constraints.preserve_terms.filter( term => !result.includes(term) ); if (missingTerms.length > 0) { return { text: result, needRegenerate: true, missingTerms }; } return { text: result, needRegenerate: false }; }

注意：敏感词过滤要小心“误杀”。比如“苹果”在某些语境下是水果，在某些语境下是品牌。我的做法是维护一个白名单，白名单里的词即使命中敏感词库也不过滤。白名单同样存在 Bmob 数据表里，方便运营人员维护。

4. 常见问题与排查技巧实录

4.1 SSE 连接中断与超时问题排查

SSE 连接中断是这类项目最高频的问题。我遇到过的表现包括：前端进度条卡在某个百分比不动、浏览器控制台报net::ERR_INCOMPLETE_CHUNKED_ENCODING、连接建立后 60 秒自动断开。

排查思路按以下顺序进行：

第一，检查服务端是否设置了正确的响应头。SSE 需要Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive。如果用了 Nginx 反向代理，还需要在 Nginx 配置里加proxy_buffering off和proxy_read_timeout 3600s，否则 Nginx 会缓冲响应导致事件不能实时到达。

第二，检查是否有中间层断开了空闲连接。很多云平台的负载均衡器会在 60 秒无数据传输时断开连接。解决方案是服务端每 30 秒发送一条注释行（: keepalive\n\n），保持连接活跃。

第三，检查前端是否正确处理了重连。EventSource 默认会自动重连，但如果服务端返回了 401 或 403，重连会一直失败。需要在 URL 里带上有时效性的 token，并在 token 过期前刷新。

4.2 动态路由误判与 Prompt 模板优化

动态路由误判的表现是：用户提交的是公文，系统却按社交媒体风格润色，输出一堆网络用语。这种情况通常源于分析层判断错误或路由逻辑有 bug。

排查时先看分析层的原始输出。我在云函数里把每次分析结果都写入了日志，方便回溯。如果分析层把公文误判为社交媒体，说明分析 Prompt 需要优化——可能是示例不够有区分度，或者文本类型枚举定义太模糊。

我的优化方法是：收集 100 条误判样本，人工标注正确的文本类型和风格，然后把这些样本作为少样本示例注入分析层 Prompt。同时调整枚举定义，比如把“社交媒体”细分为“小红书”“微博”“朋友圈”，让模型有更明确的判断依据。

路由逻辑的 bug 通常出在模板匹配上。比如find_template函数在找不到精确匹配时，降级逻辑写错了，导致返回了不相关的模板。我的做法是给每个模板加一个priority字段，降级时按优先级排序取第一个可用的。

另一个容易被忽视的问题是模板缓存过期。云函数把模板库缓存在内存里，如果运营人员在 Bmob 后台修改了模板但缓存没刷新，路由还是会用旧模板。我设置了 5 分钟自动刷新，同时在云函数里加了一个手动刷新接口，改完模板可以立即生效。

4.3 模型输出格式异常的兜底策略

模型输出格式异常包括：返回的不是 JSON、JSON 字段缺失、字段值超出枚举范围、输出被截断。这些问题在分析层尤其常见，因为分析层要求返回严格 JSON，但模型有时会“自作主张”加一些解释文字。

我的兜底策略分三层：

第一层，正则提取。用正则从模型输出中提取 JSON 部分，忽略前后的解释文字。正则模式大致是/\{[\s\S]*\}/，匹配第一个左花括号到最后一个右花括号之间的内容。

第二层，字段补全。如果 JSON 解析成功但字段缺失，用默认值补全。比如text_type缺失就设为“通用”，confidence缺失就设为 0.5。

第三层，降级路由。如果 JSON 完全解析失败，直接走通用模板，不依赖分析结果。同时记录一条错误日志，方便后续优化 Prompt。

function parseAnalysisOutput(rawOutput) { // 第一层：正则提取 const jsonMatch = rawOutput.match(/\{[\s\S]*\}/); if (!jsonMatch) { return { text_type: '通用', target_style: '通用', confidence: 0.5, constraints: {} }; } try { const parsed = JSON.parse(jsonMatch[0]); // 第二层：字段补全 return { text_type: parsed.text_type || '通用', target_style: parsed.target_style || '通用', confidence: typeof parsed.confidence === 'number' ? parsed.confidence : 0.5, constraints: parsed.constraints || {} }; } catch (e) { // 第三层：降级 console.error('Analysis parse failed:', rawOutput); return { text_type: '通用', target_style: '通用', confidence: 0.5, constraints: {} }; } }

提示：分析层 Prompt 里加一句“只返回 JSON，不要任何解释文字”能显著降低格式异常率。另外把temperature设低（0.1 以下）也能让输出更稳定。

4.4 配额控制与防刷机制的实际部署

配额控制看起来简单，实际部署时有不少坑。我最初的做法是在云函数里查用户今日已用次数，然后判断是否超限。但并发请求下会出现“超用”问题——两个请求同时查到已用 9 次，都认为没超限，结果都执行了，变成 11 次。

解决方案是用 Bmob 的原子操作。Bmob 数据表支持increment操作，可以原子性地增加字段值。我把配额检查改成：先原子性增加dailyUsed，然后检查增加后的值是否超过dailyLimit，如果超过就回滚（减回去）并拒绝请求。

async function checkAndIncrementQuota(userId) { const quota = await Bmob.Table.get('user_quotas', { userId }); // 检查是否需要重置 if (isNewDay(quota.lastResetAt)) { await Bmob.Table.update('user_quotas', quota.objectId, { dailyUsed: 0, lastResetAt: new Date() }); quota.dailyUsed = 0; } // 原子性增加 const updated = await Bmob.Table.increment('user_quotas', quota.objectId, 'dailyUsed', 1); if (updated.dailyUsed > quota.dailyLimit) { // 回滚 await Bmob.Table.increment('user_quotas', quota.objectId, 'dailyUsed', -1); return { allowed: false, remaining: 0 }; } return { allowed: true, remaining: quota.dailyLimit - updated.dailyUsed }; }

防刷机制还包括：同一 IP 短时间内大量请求时触发验证码、同一用户连续提交相同文本时返回缓存结果而不是重新推理、异常时间段（凌晨 3 点到 5 点）降低配额上限。这些策略组合使用后，我的项目上线三个月没有出现被刷爆的情况。

4.5 性能监控与推理耗时优化

性能监控我主要看三个指标：分析层耗时、生成层耗时、端到端总耗时。这些数据在每次模型调用时记录到 Bmob 数据表，然后用 Bmob 的统计功能做聚合分析。

实测数据：分析层平均 350ms，生成层平均 2.8 秒，后处理平均 50ms，端到端平均 3.5 秒（含网络传输）。P95 端到端耗时 6.2 秒，P99 是 9.8 秒。超过 10 秒的请求基本是因为模型接口波动或网络抖动。

优化手段有几个：一是分析层和生成层并行化——分析层判断文本类型的同时，可以并行做一些不依赖分析结果的预处理（比如敏感词预扫描）。二是模板缓存预热——云函数冷启动时加载模板库到内存，避免每次请求都查数据库。三是结果缓存——相同文本加相同模板的润色结果缓存 24 小时，重复请求直接返回缓存。

还有一个容易被忽视的优化点是模型接口的区域选择。如果用户主要在国内，选择国内节点的模型接口能显著降低网络延迟。我实测过，同样的模型，国内节点比海外节点端到端快 1.5 到 2 秒。

5. 一些实操心得与后续扩展方向

这个项目从立项到稳定运行大概花了三周时间，其中一半时间在调 Prompt 和路由逻辑。我最大的体会是：双层推理的价值不在于模型多强，而在于路由多准。分析层哪怕用很小的模型，只要 Prompt 设计得当，判断准确率就能到 85% 以上；路由逻辑只要覆盖了主要场景，润色质量就有质的提升。

另一个心得是关于 SSE 的：不要试图在 Bmob 云函数里实现标准 SSE，用实时数据监听替代更稳定。Bmob 的实时监听底层是 WebSocket，连接稳定性比自己在云函数里维护 SSE 长连接好得多。我早期尝试过在云函数里返回text/event-stream，结果因为云函数的执行模型限制，连接经常在几秒后就被平台断开。

后续扩展方向我考虑了几个：一是加入用户反馈闭环，用户对润色结果点赞或点踩后，数据回流到模板评分，自动调整路由权重。二是支持多轮润色，用户可以对结果追加指令（“再正式一点”“缩短到 100 字”），系统在已有结果基础上二次润色。三是把模板库开放给用户自定义，高级用户可以上传自己的风格示例，系统自动生成对应的 Prompt 模板。

最后分享一个小技巧：分析层的 Prompt 里加上“如果文本少于 20 个字，直接返回通用风格”这条规则，能避免短文本被误判为特定风格。短文本信息量太少，分析层强行判断反而容易出错，不如直接走通用模板。这个规则加上之后，短文本的润色满意度提升了差不多 15 个百分点。