最近在开发一个社交类应用时，遇到了一个很有意思的需求：如何根据用户的历史互动行为，智能地判断并生成一条“拟人化”的推送消息，比如“想我了还是怪我了”？这背后涉及到自然语言生成（NLG）、用户行为分析以及上下文感知等多个技术点。本文将从一个后端开发者的视角，完整拆解如何基于规则引擎和简单模型，实现这类带有情感色彩的动态文案生成。无论你是想为产品增加一点人情味，还是对用户画像和内容生成感兴趣，这篇从零到一的实战指南都能提供清晰的思路和可运行的代码。

1. 背景与核心概念：动态文案与用户行为解读

“想我了还是怪我了”这样一句话，在社交产品中，它不再是一个简单的字符串，而是一个动态文案模板的输出结果。其核心目的是通过分析用户A与用户B之间的互动数据（如聊天频率、消息情感、最近互动时间等），生成一句贴合当前关系状态、能引发共鸣或互动的文案。

1.1 什么是动态文案生成？

动态文案生成，指的是根据预设的规则、模板以及实时输入的数据（用户属性、行为、环境变量等），自动组合或创建出非固定的文本内容。它不同于静态文案，也不同于复杂的AI写作，通常用于：

• 个性化推送：根据用户喜好推荐内容时的标题描述。
• 状态提示：如“您有3条未读消息” vs “好久不见，有3条消息在等你”。
• 互动引导：像本文案例，基于双方关系生成促进回复的文案。

1.2 关键问题拆解

要实现“想我了还是怪我了”的效果，我们需要解决几个问题：

1. 数据源：我们需要哪些用户行为数据？如何存储和获取？
2. 特征工程：如何将原始行为数据（如时间戳、消息类型）转化为可以用于判断的特征（如“亲密指数”、“冷淡指数”）？
3. 判断逻辑：基于这些特征，用什么规则或模型来决定最终输出哪类文案？
4. 文案模板：如何设计一个灵活、可扩展的文案模板库，方便运营同学后续修改？

本文将采用“规则引擎 + 特征打分”的方案，这是一个在业务初期足够有效且易于理解和维护的策略。

2. 环境准备与版本说明

本项目是一个独立的Java服务模块，可以集成到现有的Spring Boot后端项目中。

• 开发环境：
  • JDK: 1.8 或 11 (本文示例使用 JDK 11)
  • Spring Boot: 2.7.x (稳定版本)
  • Maven: 3.6+
  • IDE: 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户互动行为日志表';

3.2 特征定义与计算

我们定义几个关键特征，并为每个特征设计一个计算策略。

1. 近期互动频率 (recentInteractionScore): 计算过去7天内，用户A对用户B发起互动的次数。次数越多，分数越高。
2. 互动衰减指数 (interactionDecayScore): 计算最近一次互动距离现在的时间（单位：天）。时间越短，分数越高。这是一个负向特征，值越大表示越“冷淡”。
3. 情感倾向指数 (sentimentScore): 基于近期互动内容中预定义的正向/负向关键词出现比例，计算一个情感分数。范围在-1（非常负面）到1（非常正面）之间。
4. 互动多样性 (interactionDiversityScore): 统计过去一段时间内互动类型的种类（如私信、点赞、评论）。种类越多，分数越高，表示关系维度更丰富。

特征计算服务示例： 我们创建一个FeatureCalculatorService来封装这些计算逻辑，并利用Redis缓存结果，避免每次请求都查询数据库。

// 文件路径：src/main/java/com/example/dynamiccopy/service/FeatureCalculatorService.java @Service @Slf4j public class FeatureCalculatorService { @Autowired private UserInteractionLogRepository interactionLogRepository; @Autowired private RedisTemplate<String, 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); List<InteractionLog> 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 ResponseEntity<Map<String, String>> generateCopywriting( @RequestParam Long fromUserId, @RequestParam Long toUserId) { try { String copy = copywritingService.generateCopywriting(fromUserId, toUserId); Map<String, 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?fromUserId=1001&toUserId=1002”

预期响应：

{ “copywriting”: “突然安静了，是在偷偷想我还是在偷偷怪我？”, “fromUserId”: “1001”, “toUserId”: “1002” }

具体的返回文案会根据用户1001对1002的近期互动特征，匹配到RULE_TEASING、RULE_MISSING等不同规则。

5. 常见问题与排查思路

在实际开发和上线过程中，你可能会遇到以下问题：

6. 最佳实践与工程建议

将动态文案系统投入生产环境，需要考虑更多工程和业务层面的问题。

1. 规则配置化与热更新

   • 不要硬编码：将规则（阈值、文案模板）从代码中抽离，存入数据库或配置中心（如Apollo、Nacos）。
   • 支持热更新：实现一个管理后台，允许产品/运营同学在不重启服务的情况下，调整规则阈值、修改或新增文案模板。规则引擎需要动态加载这些配置。

2. 文案模板的多样性与变量注入

   • 避免单一：每个规则下应该对应一个文案模板池，每次随机选取一条，避免用户收到重复文案。
   • 支持个性化：模板应支持变量注入。例如，“{nickname}，最近好像没怎么收到你的消息？” 其中{nickname}可以在生成时被替换为目标用户的昵称。

3. 特征计算的性能与实时性

   • 分层缓存：采用多级缓存。实时计算的特征缓存30分钟，一些变化不快的用户属性（如标签）可以缓存更久。
   • 异步计算：对于计算成本高的特征，可以将其计算过程放到消息队列中异步执行，计算结果写回缓存。请求时优先使用缓存，缓存缺失则使用降级策略（如返回默认特征或使用旧缓存）。

4. 监控与数据分析

   • 埋点上报：每次文案生成和曝光，都应记录日志，包括：使用的规则、特征值、生成的文案、上下文信息。这是后续优化规则和模型的宝贵数据。
   • 效果评估：定义关键指标（CTR点击率、后续互动率等），通过A/B测试对比不同规则集或文案模板的效果，用数据驱动决策。

5. 系统可扩展性

   • 插件化规则引擎：考虑使用 Drools 等开源规则引擎，或者设计一个简单的“条件-动作”脚本接口，方便扩展复杂的判断逻辑。
   • 特征工厂模式：将每个特征的计算封装成独立的FeatureCalculator接口实现，通过配置决定加载哪些特征，方便增删。

6. 伦理与用户体验

   • 避免过度解读：系统本质是概率预测，文案应是“有趣、贴心”的引导，而非“准确、沉重”的断言。语气要轻松，给用户留出空间。
   • 设置开关：为用户提供关闭此类“智能文案”的选项，尊重用户偏好。

通过以上步骤，我们不仅实现了一个能生成“想我了还是怪我了”的动态文案系统，更构建了一个可扩展、可运营的个性化内容生成框架。你可以在此基础上，接入更复杂的AI模型（如情感分析、文本生成），或扩展到更多业务场景（如商品推荐语、活动推送标题），让产品的语言更具温度和智慧。