编码进行中编码进行中

01 开篇：在开源底座上造自己的 CRM

第 1 / 10 章
01 开篇：在开源底座上造自己的 CRM

我是 mashangan，一个每天要写 150 行后端代码的 Java 开发。2026 年下半年，公司决定换一套 CRM 客户管理平台，我被指派选型 + 二开。

预算 0（老板原话："能用开源的就别花钱"），时间 2 周，需求三条：

  1. 公海客户要能"智能分配"——不是现在的随机派单，要按销售负载、片区熟悉度、历史转化率排优先级
  2. 新进来的线索要能"自动评分"——我不想每天早上 9 点站在销售部喊"今天先打哪几个电话"
  3. 老板要看"业绩达成看板"——每个销售本月完成率多少、哪个行业贡献大，一眼就看见

三条需求，每一条都够写一篇文章。我选了芋道开源 ruoyi-vue-pro 当底座，在它的 CRM 模块上改。改完之后发现：改造的过程本身就是一个完整的技术实践系列——从领域模型梳理、到策略模式扩展、到定时任务流水线、再到 AI 线索评分的双轨融合。

这 10 章，就是改造的完整记录。

为什么写这一系列

技术博客最容易犯两个病：

  1. 空对空——上来就讲设计模式，不讲为什么需要这个模式，不讲踩过的坑
  2. 只给结论——直接贴最终代码，中间那 17 个小时的调试、5 次方案推倒重来、凌晨 2 点才发现的事务静默失效，全被"整理掉了"

我想把这些没被整理掉的东西写出来：

  • 芋道原版 putCustomerPool 为什么我非得改成 public？不改会发生什么？
  • 为什么我选"规则引擎 + LLM 双轨"而不是直接上 LLM？
  • CAS 抢占公海客户的时候，如果两条记录同时被抢，会发生什么？我怎么验证？
  • 业绩看板的数据聚合，为什么我用了"定时全量刷新"而不是实时计算？

这些是真正在"造轮子"的人会遇到的问题，也是我希望你能拿走的东西。

底座说明

诚实声明：本系列所有后端代码，底座都是芋道开源 ruoyi-vue-pro（v2025.05 版本，Spring Boot 2.7.18 + Java 8）。芋道提供了完整的权限、租户、数据权限、定时任务、MyBatis-Plus 等基础设施。我写的是在这个底座上新增的业务模块，以及对原有 CRM 模块的修改。

层技术版本
后端框架ruoyi-vue-prov2025.05
Spring BootSpring Boot2.7.18
JDKJava8（这点坑了我好几次）
ORMMyBatis-Plus3.5.5
数据库MySQL8.x
前端Nuxt 3—
前端底座yudao-ui-admin-vue3—

我的修改范围：

Phase做了什么改动性质
Phase 1 公海智能分配新增策略接口 + 5 种策略实现 + 回收-分配定时任务 + 前端配置页新增模块
Phase 2 AI 线索评分新增 5 条评分规则 + LLM 语义评分 + 双轨融合新增模块
Phase 3 业绩达成看板新增业绩聚合 Service + 每日汇总定时任务 + 看板 API新增模块

红线约束（写文章和改代码时我自己给自己定的）：

  1. 诚实标注底座是芋道开源，不冒充作者
  2. 禁词"小哈"——不要蹭热词，不要起营销号式的标题
  3. 第一人称"我"——让你知道这是真实开发记录，不是 AI 生成的方案文档
  4. 内容必须真实跑通——文章里的每个 API 调用、每条 SQL、每个返回结果，都是我本地测试跑出来的
  5. 不允许已开发功能被覆盖——Phase 1 上线后，Phase 2/3 的代码不能破坏 Phase 1 的行为

10 章路线图

Phase 0: 准备工作（第 1~3 章）
  ├─ 01 开篇：在开源底座上造自己的 CRM     ← 本章
  ├─ 02 领域模型：客户、线索、公海到底是什么关系
  └─ 03 原版拆解：芋道现有公海机制的代码走查

Phase 1: 公海智能分配（第 4~5 章，已发布）
  ├─ 04 策略模式设计：Source / Industry / Level / Contact / Activity 五种规则
  └─ 05 回收-分配流水线：CAS 抢占 + 事务静默失效坑 + 留痕

Phase 2: AI 线索评分（第 6~7 章，已发布 06）
  ├─ 06 规则引擎：可解释优先的五维评分（已发布）
  └─ 07 LLM 接入：双轨融合 + 提示词设计 + 降级策略

Phase 3: 业绩达成看板（第 8~10 章）
  ├─ 08 数据聚合：按销售/客户/行业/时间段四维统计
  ├─ 09 实时刷新：每日汇总定时任务 + 看板 API + 前端
  └─ 10 收尾：踩坑复盘 + 架构演进思路

Phase 1 是策略模式在 CRM 场景的实战，Phase 2 是"规则引擎 + LLM"双轨架构的设计取舍，Phase 3 偏后端数据聚合和看板 API。三章路线覆盖了我这次改造最核心的三个技术决策。

环境速查

后端     http://localhost:48080  admin/admin123  tenant-id: 1
前端     http://localhost:80     admin/admin123
MySQL    localhost:3306           ruoyi-vue-pro-jdk8 / root / 123456
Redis    localhost:6380          （6379 被 ange-redis 占了）

启动后端：

java -jar "D:\ProgramProject\CRM系统\ruoyi-vue-pro\yudao-server\target\yudao-server.jar" --spring.profiles.active=local

现在开始

下一章（02）我会先把领域模型理清楚——客户、线索、公海这三个概念在 CRM 里的关系是什么？为什么我在公海分配时需要"CAS 抢占"？为什么线索要分"已转化"和"未转化"？

先把模型聊清楚，再改代码，不容易走偏。

下一章
02 领域模型：客户、线索、公海到底是什么关系