最近在开发一个社交类应用时遇到了一个很有意思的需求如何根据用户的历史互动行为智能地判断并生成一条“拟人化”的推送消息比如“想我了还是怪我了”这背后涉及到自然语言生成NLG、用户行为分析以及上下文感知等多个技术点。本文将从一个后端开发者的视角完整拆解如何基于规则引擎和简单模型实现这类带有情感色彩的动态文案生成。无论你是想为产品增加一点人情味还是对用户画像和内容生成感兴趣这篇从零到一的实战指南都能提供清晰的思路和可运行的代码。1. 背景与核心概念动态文案与用户行为解读“想我了还是怪我了”这样一句话在社交产品中它不再是一个简单的字符串而是一个动态文案模板的输出结果。其核心目的是通过分析用户A与用户B之间的互动数据如聊天频率、消息情感、最近互动时间等生成一句贴合当前关系状态、能引发共鸣或互动的文案。1.1 什么是动态文案生成动态文案生成指的是根据预设的规则、模板以及实时输入的数据用户属性、行为、环境变量等自动组合或创建出非固定的文本内容。它不同于静态文案也不同于复杂的AI写作通常用于个性化推送根据用户喜好推荐内容时的标题描述。状态提示如“您有3条未读消息” vs “好久不见有3条消息在等你”。互动引导像本文案例基于双方关系生成促进回复的文案。1.2 关键问题拆解要实现“想我了还是怪我了”的效果我们需要解决几个问题数据源我们需要哪些用户行为数据如何存储和获取特征工程如何将原始行为数据如时间戳、消息类型转化为可以用于判断的特征如“亲密指数”、“冷淡指数”判断逻辑基于这些特征用什么规则或模型来决定最终输出哪类文案文案模板如何设计一个灵活、可扩展的文案模板库方便运营同学后续修改本文将采用“规则引擎 特征打分”的方案这是一个在业务初期足够有效且易于理解和维护的策略。2. 环境准备与版本说明本项目是一个独立的Java服务模块可以集成到现有的Spring Boot后端项目中。开发环境JDK: 1.8 或 11 (本文示例使用 JDK 11)Spring Boot: 2.7.x (稳定版本)Maven: 3.6IDE: IntelliJ IDEA 或 Eclipse数据存储主要使用项目现有的MySQL数据库存储用户行为日志。使用Redis作为特征计算结果的缓存避免频繁进行聚合查询。核心依赖Spring Boot Starter Web (提供Web框架)Spring Boot Starter Data JPA (或MyBatis-Plus 用于数据访问)Spring Boot Starter Data Redis (用于缓存)Lombok (简化Bean代码)3. 核心设计规则引擎与特征计算我们的系统设计分为三个核心层数据采集层、特征计算层和文案决策层。用户互动行为 (数据源) | v [数据采集与存储层] - MySQL行为日志表 | v [特征计算与缓存层] - 计算“互动频率”、“情感倾向”等特征 - Redis缓存 | v [文案决策层] - 规则引擎根据特征打分 - 匹配文案模板 - 输出最终文案3.1 数据模型设计首先我们需要一张表来记录核心的互动行为。这里简化设计聚焦于私信互动。-- 创建用户互动行为记录表 CREATE TABLE user_interaction_log ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, from_user_id bigint(20) NOT NULL COMMENT 主动互动用户ID, to_user_id bigint(20) NOT NULL COMMENT 被动互动用户ID, interaction_type varchar(50) NOT NULL COMMENT 互动类型: PRIVATE_CHAT(私信), LIKE(点赞), COMMENT(评论), content text COMMENT 互动内容如消息文本, has_positive_keyword tinyint(1) DEFAULT 0 COMMENT 是否包含正向关键词简化情感分析, has_negative_keyword tinyint(1) DEFAULT 0 COMMENT 是否包含负向关键词, interaction_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 互动发生时间, PRIMARY KEY (id), KEY idx_user_pair (from_user_id,to_user_id,interaction_time), KEY idx_to_user_time (to_user_id,interaction_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户互动行为日志表;3.2 特征定义与计算我们定义几个关键特征并为每个特征设计一个计算策略。近期互动频率 (recentInteractionScore): 计算过去7天内用户A对用户B发起互动的次数。次数越多分数越高。互动衰减指数 (interactionDecayScore): 计算最近一次互动距离现在的时间单位天。时间越短分数越高。这是一个负向特征值越大表示越“冷淡”。情感倾向指数 (sentimentScore): 基于近期互动内容中预定义的正向/负向关键词出现比例计算一个情感分数。范围在-1非常负面到1非常正面之间。互动多样性 (interactionDiversityScore): 统计过去一段时间内互动类型的种类如私信、点赞、评论。种类越多分数越高表示关系维度更丰富。特征计算服务示例 我们创建一个FeatureCalculatorService来封装这些计算逻辑并利用Redis缓存结果避免每次请求都查询数据库。// 文件路径src/main/java/com/example/dynamiccopy/service/FeatureCalculatorService.java Service Slf4j public class FeatureCalculatorService { Autowired private UserInteractionLogRepository interactionLogRepository; Autowired private RedisTemplateString, Object redisTemplate; private static final String FEATURE_CACHE_KEY_PREFIX “feature:uid:%d:to:%d”; private static final Duration CACHE_TTL Duration.ofMinutes(30); // 缓存30分钟 /** * 获取或计算用户A对用户B的特征向量 */ public UserInteractionFeature calculateFeatures(Long fromUserId, Long toUserId) { String cacheKey String.format(FEATURE_CACHE_KEY_PREFIX, fromUserId, toUserId); // 1. 尝试从缓存获取 UserInteractionFeature cachedFeature (UserInteractionFeature) redisTemplate.opsForValue().get(cacheKey); if (cachedFeature ! null) { return cachedFeature; } // 2. 缓存未命中从DB计算 LocalDateTime sevenDaysAgo LocalDateTime.now().minusDays(7); ListInteractionLog recentLogs interactionLogRepository .findByFromUserIdAndToUserIdAndInteractionTimeAfter(fromUserId, toUserId, sevenDaysAgo); if (recentLogs.isEmpty()) { // 如果没有近期互动返回一个“冷淡”的默认特征 UserInteractionFeature defaultFeature UserInteractionFeature.getDefaultColdFeature(); redisTemplate.opsForValue().set(cacheKey, defaultFeature, CACHE_TTL); return defaultFeature; } // 3. 计算各个特征 // 3.1 近期互动频率 int recentInteractionCount recentLogs.size(); double recentInteractionScore Math.min(recentInteractionCount / 10.0, 1.0); // 假设10次为上限归一化到[0,1] // 3.2 互动衰减指数 (最近一次互动距今的天数取倒数并归一化) InteractionLog latestLog recentLogs.stream() .max(Comparator.comparing(InteractionLog::getInteractionTime)) .orElseThrow(); long daysSinceLastInteraction ChronoUnit.DAYS.between(latestLog.getInteractionTime().toLocalDate(), LocalDate.now()); double interactionDecayScore daysSinceLastInteraction 0 ? 1.0 : Math.max(0, 1.0 - (daysSinceLastInteraction / 14.0)); // 假设14天完全衰减归一化到[0,1] // 3.3 情感倾向指数 (简化版基于关键词计数) long positiveCount recentLogs.stream().filter(InteractionLog::isHasPositiveKeyword).count(); long negativeCount recentLogs.stream().filter(InteractionLog::isHasNegativeKeyword).count(); long totalWithContent recentLogs.stream().filter(log - log.getContent() ! null !log.getContent().isEmpty()).count(); double sentimentScore totalWithContent 0 ? 0.0 : (double)(positiveCount - negativeCount) / totalWithContent; sentimentScore Math.max(-1.0, Math.min(1.0, sentimentScore)); // 钳制在[-1, 1] // 3.4 互动多样性 long distinctTypeCount recentLogs.stream() .map(InteractionLog::getInteractionType) .distinct() .count(); double interactionDiversityScore distinctTypeCount / 3.0; // 假设我们有3种互动类型归一化到[0,1] // 4. 组装特征对象 UserInteractionFeature feature UserInteractionFeature.builder() .fromUserId(fromUserId) .toUserId(toUserId) .recentInteractionScore(recentInteractionScore) .interactionDecayScore(interactionDecayScore) .sentimentScore(sentimentScore) .interactionDiversityScore(interactionDiversityScore) .calculatedTime(LocalDateTime.now()) .build(); // 5. 写入缓存 redisTemplate.opsForValue().set(cacheKey, feature, CACHE_TTL); log.info(“Calculated features for {} - {}: {}”, fromUserId, toUserId, feature); return feature; } } // 特征值对象 Data Builder AllArgsConstructor NoArgsConstructor public class UserInteractionFeature { private Long fromUserId; private Long toUserId; private Double recentInteractionScore; // [0,1] private Double interactionDecayScore; // [0,1] private Double sentimentScore; // [-1,1] private Double interactionDiversityScore; // [0,1] private LocalDateTime calculatedTime; public static UserInteractionFeature getDefaultColdFeature() { return UserInteractionFeature.builder() .recentInteractionScore(0.0) .interactionDecayScore(0.0) // 很久没互动 .sentimentScore(0.0) .interactionDiversityScore(0.0) .calculatedTime(LocalDateTime.now()) .build(); } }4. 完整实战规则引擎与文案生成服务有了特征之后我们需要一个决策引擎来决定最终输出什么文案。我们采用一个可配置的规则链。4.1 规则定义与文案模板首先我们定义规则和文案模板。可以将它们配置在数据库或配置文件中这里为了演示使用枚举和内存配置。// 文件路径src/main/java/com/example/dynamiccopy/rule/CopywritingRule.java public enum CopywritingRule { // 规则1高频、近期、正向 - 表达“想念” RULE_MISSING(“RULE_MISSING”, “想我了还是怪我了”, “最近好像没怎么收到你的消息是太忙了吗”, “主动关心型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件近期互动频率高但衰减指数开始下降即互动变少且情感为正向 return feature.getRecentInteractionScore() 0.7 feature.getInteractionDecayScore() 0.5 feature.getSentimentScore() 0.2; } }, // 规则2低频、近期、负向或中性 - 表达“责怪”或“试探” RULE_BLAMING(“RULE_BLAMING”, “想我了还是怪我了”, “这么久不联系是不是我哪里做得不好”, “试探询问型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件近期互动频率低衰减指数低很久没互动情感非强烈正向 return feature.getRecentInteractionScore() 0.3 feature.getInteractionDecayScore() 0.3 feature.getSentimentScore() 0.5; } }, // 规则3高频、持续、情感多样 - 表达“调侃” RULE_TEASING(“RULE_TEASING”, “想我了还是怪我了”, “突然安静了是在偷偷想我还是在偷偷怪我”, “轻松调侃型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件互动频率高衰减指数高持续互动情感分数接近0中性多样性高 return feature.getRecentInteractionScore() 0.6 feature.getInteractionDecayScore() 0.7 Math.abs(feature.getSentimentScore()) 0.3 feature.getInteractionDiversityScore() 0.5; } }, // 默认规则无匹配时返回中性文案 RULE_DEFAULT(“RULE_DEFAULT”, “想我了还是怪我了”, “最近怎么样”, “普通问候型”) { Override public boolean matches(UserInteractionFeature feature) { return true; // 兜底规则始终匹配 } }; private final String ruleCode; private final String templateKey; // 可用于关联更丰富的模板库 private final String defaultCopy; private final String description; CopywritingRule(String ruleCode, String templateKey, String defaultCopy, String description) { this.ruleCode ruleCode; this.templateKey templateKey; this.defaultCopy defaultCopy; this.description description; } // 抽象方法每个规则实现自己的匹配逻辑 public abstract boolean matches(UserInteractionFeature feature); public String generateCopy() { // 这里直接返回默认文案。实际项目中可以通过templateKey从数据库或配置中心获取更复杂的模板并注入变量。 return this.defaultCopy; } /** * 根据特征评估所有规则返回第一个匹配的规则生成的文案 */ public static String evaluateAndGenerate(UserInteractionFeature feature) { for (CopywritingRule rule : values()) { if (rule.matches(feature)) { return rule.generateCopy(); } } // 理论上不会走到这里因为DEFAULT规则始终匹配 return RULE_DEFAULT.generateCopy(); } }4.2 整合服务与API接口现在我们将特征计算和规则决策整合到一个业务服务中并对外提供API。// 文件路径src/main/java/com/example/dynamiccopy/service/DynamicCopywritingService.java Service Slf4j public class DynamicCopywritingService { Autowired private FeatureCalculatorService featureCalculatorService; /** * 为指定用户对生成动态文案 * param fromUserId 主动方用户ID * param toUserId 接收方用户ID * return 生成的动态文案 */ public String generateCopywriting(Long fromUserId, Long toUserId) { // 1. 计算用户互动特征 UserInteractionFeature feature featureCalculatorService.calculateFeatures(fromUserId, toUserId); // 2. 通过规则引擎决策生成文案 String finalCopy CopywritingRule.evaluateAndGenerate(feature); // 3. (可选) 记录文案生成日志用于后续分析和优化 log.info(“Dynamic copy generated for {} - {}: {} | Features: {}”, fromUserId, toUserId, finalCopy, feature); return finalCopy; } } // 文件路径src/main/java/com/example/dynamiccopy/controller/CopywritingController.java RestController RequestMapping(“/api/copywriting”) Slf4j public class CopywritingController { Autowired private DynamicCopywritingService copywritingService; GetMapping(“/generate”) public ResponseEntityMapString, String generateCopywriting( RequestParam Long fromUserId, RequestParam Long toUserId) { try { String copy copywritingService.generateCopywriting(fromUserId, toUserId); MapString, String response new HashMap(); response.put(“copywriting”, copy); response.put(“fromUserId”, String.valueOf(fromUserId)); response.put(“toUserId”, String.valueOf(toUserId)); return ResponseEntity.ok(response); } catch (Exception e) { log.error(“Failed to generate copywriting for {} - {}”, fromUserId, toUserId, e); return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(Collections.singletonMap(“error”, “文案生成失败”)); } } }4.3 运行与验证启动Spring Boot应用后我们可以通过API进行测试。假设我们已经在user_interaction_log表中插入了一些测试数据。调用示例curl -X GET “http://localhost:8080/api/copywriting/generate?fromUserId1001toUserId1002”预期响应{ “copywriting”: “突然安静了是在偷偷想我还是在偷偷怪我”, “fromUserId”: “1001”, “toUserId”: “1002” }具体的返回文案会根据用户1001对1002的近期互动特征匹配到RULE_TEASING、RULE_MISSING等不同规则。5. 常见问题与排查思路在实际开发和上线过程中你可能会遇到以下问题问题现象可能原因排查思路与解决方案API返回默认文案“最近怎么样”1. 数据库中没有对应的用户互动记录。2. 特征计算逻辑有误导致所有规则都不匹配除了DEFAULT。3. Redis缓存了旧的、特征值为0的数据。1. 检查user_interaction_log表确保存在from_user_id和to_user_id的测试数据且interaction_time在近期。2. 在FeatureCalculatorService中增加日志打印计算出的原始数据和最终特征值核对逻辑。3. 清理Redis缓存keys feature:*然后del或为缓存Key设置合理的TTL。文案生成速度慢1. 每次请求都重新计算特征没有命中缓存。2. 对大量历史数据做聚合查询SQL慢。1. 确认FeatureCalculatorService的缓存逻辑生效。检查Redis连接和序列化配置。2. 为user_interaction_log表在(from_user_id, to_user_id, interaction_time)上建立复合索引。3. 考虑将特征计算改为异步任务定期预计算并更新缓存。规则匹配不准确文案不符合预期1. 规则中定义的阈值如0.7, 0.5不合理。2. 特征计算方式不能真实反映“想念”或“责怪”的状态。1.这是核心调优点。需要收集真实用户反馈或通过A/B测试调整规则阈值。2. 引入更多特征如“消息响应延迟”、“互动时间分布白天/夜晚”。3. 考虑使用简单的机器学习模型如逻辑回归替代硬编码规则用标注数据训练。新用户或沉默用户收到奇怪文案特征数据稀疏导致计算出的特征值异常或为0匹配到不合适的规则。1. 在规则判断前增加数据稀疏性检查。如果互动总数少于某个阈值如3次直接返回一个更安全的“破冰”文案例如“打个招呼吧”。2. 对特征值进行平滑处理如拉普拉斯平滑避免极端值。6. 最佳实践与工程建议将动态文案系统投入生产环境需要考虑更多工程和业务层面的问题。规则配置化与热更新不要硬编码将规则阈值、文案模板从代码中抽离存入数据库或配置中心如Apollo、Nacos。支持热更新实现一个管理后台允许产品/运营同学在不重启服务的情况下调整规则阈值、修改或新增文案模板。规则引擎需要动态加载这些配置。文案模板的多样性与变量注入避免单一每个规则下应该对应一个文案模板池每次随机选取一条避免用户收到重复文案。支持个性化模板应支持变量注入。例如“{nickname}最近好像没怎么收到你的消息” 其中{nickname}可以在生成时被替换为目标用户的昵称。特征计算的性能与实时性分层缓存采用多级缓存。实时计算的特征缓存30分钟一些变化不快的用户属性如标签可以缓存更久。异步计算对于计算成本高的特征可以将其计算过程放到消息队列中异步执行计算结果写回缓存。请求时优先使用缓存缓存缺失则使用降级策略如返回默认特征或使用旧缓存。监控与数据分析埋点上报每次文案生成和曝光都应记录日志包括使用的规则、特征值、生成的文案、上下文信息。这是后续优化规则和模型的宝贵数据。效果评估定义关键指标CTR点击率、后续互动率等通过A/B测试对比不同规则集或文案模板的效果用数据驱动决策。系统可扩展性插件化规则引擎考虑使用 Drools 等开源规则引擎或者设计一个简单的“条件-动作”脚本接口方便扩展复杂的判断逻辑。特征工厂模式将每个特征的计算封装成独立的FeatureCalculator接口实现通过配置决定加载哪些特征方便增删。伦理与用户体验避免过度解读系统本质是概率预测文案应是“有趣、贴心”的引导而非“准确、沉重”的断言。语气要轻松给用户留出空间。设置开关为用户提供关闭此类“智能文案”的选项尊重用户偏好。通过以上步骤我们不仅实现了一个能生成“想我了还是怪我了”的动态文案系统更构建了一个可扩展、可运营的个性化内容生成框架。你可以在此基础上接入更复杂的AI模型如情感分析、文本生成或扩展到更多业务场景如商品推荐语、活动推送标题让产品的语言更具温度和智慧。 基于规则引擎与特征计算的动态文案生成实战
最近在开发一个社交类应用时遇到了一个很有意思的需求如何根据用户的历史互动行为智能地判断并生成一条“拟人化”的推送消息比如“想我了还是怪我了”这背后涉及到自然语言生成NLG、用户行为分析以及上下文感知等多个技术点。本文将从一个后端开发者的视角完整拆解如何基于规则引擎和简单模型实现这类带有情感色彩的动态文案生成。无论你是想为产品增加一点人情味还是对用户画像和内容生成感兴趣这篇从零到一的实战指南都能提供清晰的思路和可运行的代码。1. 背景与核心概念动态文案与用户行为解读“想我了还是怪我了”这样一句话在社交产品中它不再是一个简单的字符串而是一个动态文案模板的输出结果。其核心目的是通过分析用户A与用户B之间的互动数据如聊天频率、消息情感、最近互动时间等生成一句贴合当前关系状态、能引发共鸣或互动的文案。1.1 什么是动态文案生成动态文案生成指的是根据预设的规则、模板以及实时输入的数据用户属性、行为、环境变量等自动组合或创建出非固定的文本内容。它不同于静态文案也不同于复杂的AI写作通常用于个性化推送根据用户喜好推荐内容时的标题描述。状态提示如“您有3条未读消息” vs “好久不见有3条消息在等你”。互动引导像本文案例基于双方关系生成促进回复的文案。1.2 关键问题拆解要实现“想我了还是怪我了”的效果我们需要解决几个问题数据源我们需要哪些用户行为数据如何存储和获取特征工程如何将原始行为数据如时间戳、消息类型转化为可以用于判断的特征如“亲密指数”、“冷淡指数”判断逻辑基于这些特征用什么规则或模型来决定最终输出哪类文案文案模板如何设计一个灵活、可扩展的文案模板库方便运营同学后续修改本文将采用“规则引擎 特征打分”的方案这是一个在业务初期足够有效且易于理解和维护的策略。2. 环境准备与版本说明本项目是一个独立的Java服务模块可以集成到现有的Spring Boot后端项目中。开发环境JDK: 1.8 或 11 (本文示例使用 JDK 11)Spring Boot: 2.7.x (稳定版本)Maven: 3.6IDE: IntelliJ IDEA 或 Eclipse数据存储主要使用项目现有的MySQL数据库存储用户行为日志。使用Redis作为特征计算结果的缓存避免频繁进行聚合查询。核心依赖Spring Boot Starter Web (提供Web框架)Spring Boot Starter Data JPA (或MyBatis-Plus 用于数据访问)Spring Boot Starter Data Redis (用于缓存)Lombok (简化Bean代码)3. 核心设计规则引擎与特征计算我们的系统设计分为三个核心层数据采集层、特征计算层和文案决策层。用户互动行为 (数据源) | v [数据采集与存储层] - MySQL行为日志表 | v [特征计算与缓存层] - 计算“互动频率”、“情感倾向”等特征 - Redis缓存 | v [文案决策层] - 规则引擎根据特征打分 - 匹配文案模板 - 输出最终文案3.1 数据模型设计首先我们需要一张表来记录核心的互动行为。这里简化设计聚焦于私信互动。-- 创建用户互动行为记录表 CREATE TABLE user_interaction_log ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, from_user_id bigint(20) NOT NULL COMMENT 主动互动用户ID, to_user_id bigint(20) NOT NULL COMMENT 被动互动用户ID, interaction_type varchar(50) NOT NULL COMMENT 互动类型: PRIVATE_CHAT(私信), LIKE(点赞), COMMENT(评论), content text COMMENT 互动内容如消息文本, has_positive_keyword tinyint(1) DEFAULT 0 COMMENT 是否包含正向关键词简化情感分析, has_negative_keyword tinyint(1) DEFAULT 0 COMMENT 是否包含负向关键词, interaction_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 互动发生时间, PRIMARY KEY (id), KEY idx_user_pair (from_user_id,to_user_id,interaction_time), KEY idx_to_user_time (to_user_id,interaction_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户互动行为日志表;3.2 特征定义与计算我们定义几个关键特征并为每个特征设计一个计算策略。近期互动频率 (recentInteractionScore): 计算过去7天内用户A对用户B发起互动的次数。次数越多分数越高。互动衰减指数 (interactionDecayScore): 计算最近一次互动距离现在的时间单位天。时间越短分数越高。这是一个负向特征值越大表示越“冷淡”。情感倾向指数 (sentimentScore): 基于近期互动内容中预定义的正向/负向关键词出现比例计算一个情感分数。范围在-1非常负面到1非常正面之间。互动多样性 (interactionDiversityScore): 统计过去一段时间内互动类型的种类如私信、点赞、评论。种类越多分数越高表示关系维度更丰富。特征计算服务示例 我们创建一个FeatureCalculatorService来封装这些计算逻辑并利用Redis缓存结果避免每次请求都查询数据库。// 文件路径src/main/java/com/example/dynamiccopy/service/FeatureCalculatorService.java Service Slf4j public class FeatureCalculatorService { Autowired private UserInteractionLogRepository interactionLogRepository; Autowired private RedisTemplateString, Object redisTemplate; private static final String FEATURE_CACHE_KEY_PREFIX “feature:uid:%d:to:%d”; private static final Duration CACHE_TTL Duration.ofMinutes(30); // 缓存30分钟 /** * 获取或计算用户A对用户B的特征向量 */ public UserInteractionFeature calculateFeatures(Long fromUserId, Long toUserId) { String cacheKey String.format(FEATURE_CACHE_KEY_PREFIX, fromUserId, toUserId); // 1. 尝试从缓存获取 UserInteractionFeature cachedFeature (UserInteractionFeature) redisTemplate.opsForValue().get(cacheKey); if (cachedFeature ! null) { return cachedFeature; } // 2. 缓存未命中从DB计算 LocalDateTime sevenDaysAgo LocalDateTime.now().minusDays(7); ListInteractionLog recentLogs interactionLogRepository .findByFromUserIdAndToUserIdAndInteractionTimeAfter(fromUserId, toUserId, sevenDaysAgo); if (recentLogs.isEmpty()) { // 如果没有近期互动返回一个“冷淡”的默认特征 UserInteractionFeature defaultFeature UserInteractionFeature.getDefaultColdFeature(); redisTemplate.opsForValue().set(cacheKey, defaultFeature, CACHE_TTL); return defaultFeature; } // 3. 计算各个特征 // 3.1 近期互动频率 int recentInteractionCount recentLogs.size(); double recentInteractionScore Math.min(recentInteractionCount / 10.0, 1.0); // 假设10次为上限归一化到[0,1] // 3.2 互动衰减指数 (最近一次互动距今的天数取倒数并归一化) InteractionLog latestLog recentLogs.stream() .max(Comparator.comparing(InteractionLog::getInteractionTime)) .orElseThrow(); long daysSinceLastInteraction ChronoUnit.DAYS.between(latestLog.getInteractionTime().toLocalDate(), LocalDate.now()); double interactionDecayScore daysSinceLastInteraction 0 ? 1.0 : Math.max(0, 1.0 - (daysSinceLastInteraction / 14.0)); // 假设14天完全衰减归一化到[0,1] // 3.3 情感倾向指数 (简化版基于关键词计数) long positiveCount recentLogs.stream().filter(InteractionLog::isHasPositiveKeyword).count(); long negativeCount recentLogs.stream().filter(InteractionLog::isHasNegativeKeyword).count(); long totalWithContent recentLogs.stream().filter(log - log.getContent() ! null !log.getContent().isEmpty()).count(); double sentimentScore totalWithContent 0 ? 0.0 : (double)(positiveCount - negativeCount) / totalWithContent; sentimentScore Math.max(-1.0, Math.min(1.0, sentimentScore)); // 钳制在[-1, 1] // 3.4 互动多样性 long distinctTypeCount recentLogs.stream() .map(InteractionLog::getInteractionType) .distinct() .count(); double interactionDiversityScore distinctTypeCount / 3.0; // 假设我们有3种互动类型归一化到[0,1] // 4. 组装特征对象 UserInteractionFeature feature UserInteractionFeature.builder() .fromUserId(fromUserId) .toUserId(toUserId) .recentInteractionScore(recentInteractionScore) .interactionDecayScore(interactionDecayScore) .sentimentScore(sentimentScore) .interactionDiversityScore(interactionDiversityScore) .calculatedTime(LocalDateTime.now()) .build(); // 5. 写入缓存 redisTemplate.opsForValue().set(cacheKey, feature, CACHE_TTL); log.info(“Calculated features for {} - {}: {}”, fromUserId, toUserId, feature); return feature; } } // 特征值对象 Data Builder AllArgsConstructor NoArgsConstructor public class UserInteractionFeature { private Long fromUserId; private Long toUserId; private Double recentInteractionScore; // [0,1] private Double interactionDecayScore; // [0,1] private Double sentimentScore; // [-1,1] private Double interactionDiversityScore; // [0,1] private LocalDateTime calculatedTime; public static UserInteractionFeature getDefaultColdFeature() { return UserInteractionFeature.builder() .recentInteractionScore(0.0) .interactionDecayScore(0.0) // 很久没互动 .sentimentScore(0.0) .interactionDiversityScore(0.0) .calculatedTime(LocalDateTime.now()) .build(); } }4. 完整实战规则引擎与文案生成服务有了特征之后我们需要一个决策引擎来决定最终输出什么文案。我们采用一个可配置的规则链。4.1 规则定义与文案模板首先我们定义规则和文案模板。可以将它们配置在数据库或配置文件中这里为了演示使用枚举和内存配置。// 文件路径src/main/java/com/example/dynamiccopy/rule/CopywritingRule.java public enum CopywritingRule { // 规则1高频、近期、正向 - 表达“想念” RULE_MISSING(“RULE_MISSING”, “想我了还是怪我了”, “最近好像没怎么收到你的消息是太忙了吗”, “主动关心型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件近期互动频率高但衰减指数开始下降即互动变少且情感为正向 return feature.getRecentInteractionScore() 0.7 feature.getInteractionDecayScore() 0.5 feature.getSentimentScore() 0.2; } }, // 规则2低频、近期、负向或中性 - 表达“责怪”或“试探” RULE_BLAMING(“RULE_BLAMING”, “想我了还是怪我了”, “这么久不联系是不是我哪里做得不好”, “试探询问型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件近期互动频率低衰减指数低很久没互动情感非强烈正向 return feature.getRecentInteractionScore() 0.3 feature.getInteractionDecayScore() 0.3 feature.getSentimentScore() 0.5; } }, // 规则3高频、持续、情感多样 - 表达“调侃” RULE_TEASING(“RULE_TEASING”, “想我了还是怪我了”, “突然安静了是在偷偷想我还是在偷偷怪我”, “轻松调侃型”) { Override public boolean matches(UserInteractionFeature feature) { // 匹配条件互动频率高衰减指数高持续互动情感分数接近0中性多样性高 return feature.getRecentInteractionScore() 0.6 feature.getInteractionDecayScore() 0.7 Math.abs(feature.getSentimentScore()) 0.3 feature.getInteractionDiversityScore() 0.5; } }, // 默认规则无匹配时返回中性文案 RULE_DEFAULT(“RULE_DEFAULT”, “想我了还是怪我了”, “最近怎么样”, “普通问候型”) { Override public boolean matches(UserInteractionFeature feature) { return true; // 兜底规则始终匹配 } }; private final String ruleCode; private final String templateKey; // 可用于关联更丰富的模板库 private final String defaultCopy; private final String description; CopywritingRule(String ruleCode, String templateKey, String defaultCopy, String description) { this.ruleCode ruleCode; this.templateKey templateKey; this.defaultCopy defaultCopy; this.description description; } // 抽象方法每个规则实现自己的匹配逻辑 public abstract boolean matches(UserInteractionFeature feature); public String generateCopy() { // 这里直接返回默认文案。实际项目中可以通过templateKey从数据库或配置中心获取更复杂的模板并注入变量。 return this.defaultCopy; } /** * 根据特征评估所有规则返回第一个匹配的规则生成的文案 */ public static String evaluateAndGenerate(UserInteractionFeature feature) { for (CopywritingRule rule : values()) { if (rule.matches(feature)) { return rule.generateCopy(); } } // 理论上不会走到这里因为DEFAULT规则始终匹配 return RULE_DEFAULT.generateCopy(); } }4.2 整合服务与API接口现在我们将特征计算和规则决策整合到一个业务服务中并对外提供API。// 文件路径src/main/java/com/example/dynamiccopy/service/DynamicCopywritingService.java Service Slf4j public class DynamicCopywritingService { Autowired private FeatureCalculatorService featureCalculatorService; /** * 为指定用户对生成动态文案 * param fromUserId 主动方用户ID * param toUserId 接收方用户ID * return 生成的动态文案 */ public String generateCopywriting(Long fromUserId, Long toUserId) { // 1. 计算用户互动特征 UserInteractionFeature feature featureCalculatorService.calculateFeatures(fromUserId, toUserId); // 2. 通过规则引擎决策生成文案 String finalCopy CopywritingRule.evaluateAndGenerate(feature); // 3. (可选) 记录文案生成日志用于后续分析和优化 log.info(“Dynamic copy generated for {} - {}: {} | Features: {}”, fromUserId, toUserId, finalCopy, feature); return finalCopy; } } // 文件路径src/main/java/com/example/dynamiccopy/controller/CopywritingController.java RestController RequestMapping(“/api/copywriting”) Slf4j public class CopywritingController { Autowired private DynamicCopywritingService copywritingService; GetMapping(“/generate”) public ResponseEntityMapString, String generateCopywriting( RequestParam Long fromUserId, RequestParam Long toUserId) { try { String copy copywritingService.generateCopywriting(fromUserId, toUserId); MapString, String response new HashMap(); response.put(“copywriting”, copy); response.put(“fromUserId”, String.valueOf(fromUserId)); response.put(“toUserId”, String.valueOf(toUserId)); return ResponseEntity.ok(response); } catch (Exception e) { log.error(“Failed to generate copywriting for {} - {}”, fromUserId, toUserId, e); return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(Collections.singletonMap(“error”, “文案生成失败”)); } } }4.3 运行与验证启动Spring Boot应用后我们可以通过API进行测试。假设我们已经在user_interaction_log表中插入了一些测试数据。调用示例curl -X GET “http://localhost:8080/api/copywriting/generate?fromUserId1001toUserId1002”预期响应{ “copywriting”: “突然安静了是在偷偷想我还是在偷偷怪我”, “fromUserId”: “1001”, “toUserId”: “1002” }具体的返回文案会根据用户1001对1002的近期互动特征匹配到RULE_TEASING、RULE_MISSING等不同规则。5. 常见问题与排查思路在实际开发和上线过程中你可能会遇到以下问题问题现象可能原因排查思路与解决方案API返回默认文案“最近怎么样”1. 数据库中没有对应的用户互动记录。2. 特征计算逻辑有误导致所有规则都不匹配除了DEFAULT。3. Redis缓存了旧的、特征值为0的数据。1. 检查user_interaction_log表确保存在from_user_id和to_user_id的测试数据且interaction_time在近期。2. 在FeatureCalculatorService中增加日志打印计算出的原始数据和最终特征值核对逻辑。3. 清理Redis缓存keys feature:*然后del或为缓存Key设置合理的TTL。文案生成速度慢1. 每次请求都重新计算特征没有命中缓存。2. 对大量历史数据做聚合查询SQL慢。1. 确认FeatureCalculatorService的缓存逻辑生效。检查Redis连接和序列化配置。2. 为user_interaction_log表在(from_user_id, to_user_id, interaction_time)上建立复合索引。3. 考虑将特征计算改为异步任务定期预计算并更新缓存。规则匹配不准确文案不符合预期1. 规则中定义的阈值如0.7, 0.5不合理。2. 特征计算方式不能真实反映“想念”或“责怪”的状态。1.这是核心调优点。需要收集真实用户反馈或通过A/B测试调整规则阈值。2. 引入更多特征如“消息响应延迟”、“互动时间分布白天/夜晚”。3. 考虑使用简单的机器学习模型如逻辑回归替代硬编码规则用标注数据训练。新用户或沉默用户收到奇怪文案特征数据稀疏导致计算出的特征值异常或为0匹配到不合适的规则。1. 在规则判断前增加数据稀疏性检查。如果互动总数少于某个阈值如3次直接返回一个更安全的“破冰”文案例如“打个招呼吧”。2. 对特征值进行平滑处理如拉普拉斯平滑避免极端值。6. 最佳实践与工程建议将动态文案系统投入生产环境需要考虑更多工程和业务层面的问题。规则配置化与热更新不要硬编码将规则阈值、文案模板从代码中抽离存入数据库或配置中心如Apollo、Nacos。支持热更新实现一个管理后台允许产品/运营同学在不重启服务的情况下调整规则阈值、修改或新增文案模板。规则引擎需要动态加载这些配置。文案模板的多样性与变量注入避免单一每个规则下应该对应一个文案模板池每次随机选取一条避免用户收到重复文案。支持个性化模板应支持变量注入。例如“{nickname}最近好像没怎么收到你的消息” 其中{nickname}可以在生成时被替换为目标用户的昵称。特征计算的性能与实时性分层缓存采用多级缓存。实时计算的特征缓存30分钟一些变化不快的用户属性如标签可以缓存更久。异步计算对于计算成本高的特征可以将其计算过程放到消息队列中异步执行计算结果写回缓存。请求时优先使用缓存缓存缺失则使用降级策略如返回默认特征或使用旧缓存。监控与数据分析埋点上报每次文案生成和曝光都应记录日志包括使用的规则、特征值、生成的文案、上下文信息。这是后续优化规则和模型的宝贵数据。效果评估定义关键指标CTR点击率、后续互动率等通过A/B测试对比不同规则集或文案模板的效果用数据驱动决策。系统可扩展性插件化规则引擎考虑使用 Drools 等开源规则引擎或者设计一个简单的“条件-动作”脚本接口方便扩展复杂的判断逻辑。特征工厂模式将每个特征的计算封装成独立的FeatureCalculator接口实现通过配置决定加载哪些特征方便增删。伦理与用户体验避免过度解读系统本质是概率预测文案应是“有趣、贴心”的引导而非“准确、沉重”的断言。语气要轻松给用户留出空间。设置开关为用户提供关闭此类“智能文案”的选项尊重用户偏好。通过以上步骤我们不仅实现了一个能生成“想我了还是怪我了”的动态文案系统更构建了一个可扩展、可运营的个性化内容生成框架。你可以在此基础上接入更复杂的AI模型如情感分析、文本生成或扩展到更多业务场景如商品推荐语、活动推送标题让产品的语言更具温度和智慧。