统一身份与组织
账号、用户、组织、岗位、租户和权限使用同一套业务上下文。
项目全景
蝉鸣 CRM 4.1 全景介绍：低代码、工作流与 AI + MCP 企业业务平台
从建设初衷、产品矩阵和业务能力，到微服务架构、低代码、工作流与 AI + MCP，系统认识蝉鸣数字企业业务平台。
企业信息化往往从一个具体问题开始：销售团队需要 CRM，行政团队需要 OA，管理层需要报表，业务部门希望快速搭建新应用。单个需求并不难完成，真正困难的是几年之后——系统越来越多，账号、组织、权限和数据标准各自为政；一次业务变更要同时修改多个系统；新技术能够演示，却很难安全地进入真实业务。
蝉鸣 CRM 4.1 正是面向这种长期复杂度建设的企业业务平台。它以统一身份、组织权限、微服务治理和工程组件为基础，以客户经营、自定义应用、事件流、工作流和 AI + MCP 为业务载体，让稳定的基础能力可以复用，让变化频繁的业务可以配置，让需要严格治理的核心规则继续保留在代码中。
这篇文章不是一张技术组件清单，也不是一份只有菜单名称的产品说明。它将从项目为什么存在开始，解释平台各层怎样协作、蝉鸣 CRM 如何落到客户经营过程，以及 AI 为什么必须通过受控工具进入企业系统。
一句话认识蝉鸣 CRM
蝉鸣 CRM 是面向企业客户经营与业务创新构建的管理平台，自定义应用、工作流和 AI + MCP 让系统能够适应持续变化的业务场景。
CRM 业务闭环
连接线索、客户、商机、合同、订单、回款、发票与客户服务。
低代码扩展
通过应用、模块、页面、自定义表单与事件流承载高频业务变化。
流程协同
将审批节点、参与人、条件和业务表单纳入统一流程中心。
AI + MCP
让模型通过受控工具使用真实业务能力，同时保留权限与审计边界。
灵活交付
支持 SaaS 快速使用，也支持 Docker、Jenkins 与私有化部署。
一、先认识项目：定位、理念与系统特点
项目定位：不止是 CRM，也不止是开发脚手架
蝉鸣 CRM 既不是只有数据库增删改查的后台框架，也不是一张不断增加字段的客户表。它将企业级基础能力、业务开发能力和客户经营产品组合在同一套系统中。
项目可以从三个层面理解：
| 层面 | 主要内容 | 面向的价值 |
|---|---|---|
| 企业技术底座 | 认证、账号、用户、组织、租户、权限、网关、监控、公共组件 | 避免每个业务系统重复建设基础能力 |
| 业务开发平台 | 自定义应用、模块、页面、表单、事件流、工作流、代码生成 | 缩短常规业务交付周期，适应字段和流程变化 |
| 业务产品与方案 | 蝉鸣 CRM、OA 任务、教育领域模块、AI + MCP 业务助手 | 直接承载客户经营、协同管理和行业场景 |
三者不是互相割裂的产品。CRM 使用统一身份和组织权限，自定义页面复用业务接口，工作流承接审批过程，AI 通过 MCP 调用已经存在的业务能力。平台的意义，就是让这些能力遵循同一套边界和规则。
对于希望快速使用的团队，蝉鸣提供 SaaS 服务；对于关注数据边界、内部集成和深度定制的组织，项目也提供私有化部署路径。产品使用与技术自主之间，不需要重新选择一套完全不同的系统。
设计理念：稳定的底座与变化的业务各归其位
原始项目说明中有一句很重要的初衷：用尽可能少的重复工作，满足多种多样的业务需求，并降低业务变更成本。 这不是要让所有需求都依赖拖拽配置，而是要判断什么应该标准化、什么应该配置化、什么必须代码化。
1. 通用能力只建设一次
登录、用户、组织、权限、租户、异常处理、文件存储、服务调用和审计等能力，几乎每个企业应用都需要。如果每增加一个业务系统就复制一套，短期看似独立，长期会形成大量不一致实现。
蝉鸣 CRM 将这些内容沉淀到组件与平台服务中。业务服务关注自己的领域，不必重复解决账号身份或组织关系；公共能力升级时，也不需要在每个业务仓库中分别修补。
2. 高频变化交给配置
企业字段、表单布局、页面联动和审批路径经常变化。将所有变化写死在代码中，会让小调整也进入开发、测试和发布周期。自定义应用、模块、表单和事件流，适合承载这类可描述、可配置的变化。
3. 核心规则仍由领域服务守护
低代码不是“没有代码”，AI 也不是“跳过系统”。客户归属、合同状态、租户隔离、数据权限、回款校验和敏感操作等规则，必须由后端领域服务统一执行。页面、工作流或 AI 都只能通过受控接口使用这些能力。
4. 业务丰富度与工程质量并重
蝉鸣 CRM 并不满足于只提供一套空白脚手架。项目已经建设客户经营、OA、自定义应用、教育领域模块和 AI 服务，同时仍以模块化、低耦合与清晰依赖方向约束工程。业务功能可以直接使用，也可以按实际场景去芜存菁。
设计取舍
平台不会把所有变化都做成配置，也不会要求所有需求重新开发。稳定规则代码化、常规页面配置化、跨角色审批流程化、自然语言交互工具化，是更符合企业长期维护的组合。
产品与能力全景：从基础平台到业务应用
蝉鸣 CRM 当前的能力不是一条单线，而是围绕企业业务形成多个互相连接的区域。
界面预览
系统与组织中心
- 用户与账号分离：用户描述真实人员，账号描述登录凭据和登录方式；同一人员可以关联多个账号。
- 多组织任职：同一成员可以在不同组织、部门和岗位中任职，适应集团、多公司和矩阵式管理。
- 菜单与接口权限：角色决定功能入口和操作权限，后端接口继续执行权限检查。
- 岗位与数据范围：数据权限不只依赖“能否看到菜单”，还需要限制能够访问哪些组织和业务数据。
- 多租户体系：SaaS 场景下隔离不同企业的数据与配置，同时支持租户内的组织协作。
自定义应用与低代码能力
平台支持围绕应用、模块和页面组织业务。企业可以定义业务字段、表单布局、校验规则和页面行为，再通过事件流连接查询、交互和接口调用。它适合企业特有台账、行业补充字段、轻量业务流程和快速验证场景。
工作流与协同
工作流面向审批和状态流转。流程分组、模板、节点、参与人和业务表单可以组合，承接请假、差旅、价格审批、合同审批、退款审批等业务。与通用流程引擎相比，项目更强调与自身账号、组织、权限和业务页面的结合。
蝉鸣 CRM
CRM 覆盖从市场线索到客户服务的完整链路，包括线索、客户、联系人、跟进、需求、商机、方案、合同、订单、回款、发票、交付、评价和反馈等业务对象。它不是一张扩展字段无限增长的客户表，而是由多个边界清晰的领域模块共同构成。
OA 与任务协同
任务、计划、待办、分配、审批和日志等能力，用于连接个人工作与组织协作。OA 不是独立于平台的另一套身份体系，而是复用现有用户、组织、岗位与流程能力。
AI + MCP
mesh-ai 负责模型、会话、MCP Server、工具与访问密钥；CRM 等领域服务继续负责真实数据和业务规则。模型通过 MCP 发现工具、理解参数并发起调用，但实际执行仍然经过平台身份、租户和数据权限校验。
行业扩展
当前 CRM 服务中已经存在学校、教师、学员、年级、班级、课程、课次和课程报名等 EDU 领域模块。教育方案可以把招生 CRM 与教务基础数据连接起来；旅游等行业则可以复用客户经营主链路，再通过自定义表单和流程补充行业字段。
二、看懂系统如何组成：总体技术架构与工程边界
总体技术架构：让每一层只承担自己的责任
从请求进入系统到业务数据返回，可以把项目理解为六个层次：
| 架构层 | 组成 | 主要职责 |
|---|---|---|
| 多端交互层 | Vue 3 管理端、自定义页面、流程设计器、可视化组件 | 页面呈现、配置设计、用户交互 |
| 统一入口层 | mesh-gateway | 路由、入口治理、服务访问边界 |
| 身份与权限层 | mesh-uaa、mesh-upms | 认证、账号、用户、组织、租户、菜单与数据权限 |
| 平台能力层 | mesh-bpm、mesh-gen、mesh-monitor | 流程、代码生成、运行监控与平台支撑 |
| 领域业务层 | mesh-crm、mesh-app、mesh-ai | 客户经营、自定义应用、AI 与 MCP |
| 数据与基础设施层 | MySQL、Redis、Elasticsearch、对象存储、Nacos、SkyWalking | 数据持久化、缓存检索、配置发现与可观测性 |
一次典型请求首先由网关进入平台，通过认证与权限体系恢复用户、租户和组织上下文，再路由到具体领域服务。业务服务执行规则并访问数据库、缓存或搜索引擎；需要审批时进入工作流，需要 AI 协作时由模型选择 MCP 工具，但最终仍回到领域服务执行。
这种结构的重要价值不是“服务数量多”，而是依赖方向清楚：前端不直接访问数据库，AI 不直接绕过业务接口，CRM 不重新实现账号体系，公共组件也不反向依赖某个具体行业。
工程结构：四个目录对应四种复用边界
需要进一步评估运行方式与交付责任时，可阅读技术架构与交付专题。
依赖方向从业务向平台、再向组件收敛；配置模块统一治理版本，不让业务反向污染底座。
当前后端主工程版本为 4.1.0，根目录的核心结构如下：
text
mesh-platform
├── configurations # 统一版本、BOM 与工程依赖配置
├── components # 可复用基础组件、Starter 与第三方集成
├── supports # 网关、认证、权限、流程、生成器、监控等平台服务
├── services # CRM、自定义应用、AI 等领域业务服务
├── README.md # 项目说明
└── pom.xml # Maven 聚合工程configurations：控制版本一致性
dependency-pom 和 dependency-bom 集中管理 Spring 生态、数据库访问、缓存、搜索、文档和工具依赖。集中治理可以减少子模块各自指定版本造成的兼容问题，也让升级影响更容易被识别。
components：沉淀可复用工程能力
组件层用于封装通用代码、Starter、自动配置和第三方集成。业务服务通过依赖组件获得一致的 Web、数据、缓存、鉴权、日志或对象存储能力，而不是复制粘贴实现。
supports：运行中的平台服务
text
supports
├── mesh-gateway # API 网关
├── mesh-uaa # 统一认证
├── mesh-upms # 用户、组织、租户与权限
├── mesh-bpm # 工作流服务
├── mesh-gen # 代码生成服务
└── mesh-monitor # 监控服务这些服务为所有业务域提供共同规则。它们与组件层的区别在于：组件是被其他模块依赖的代码能力，支撑服务则是可独立运行、通过接口参与系统协作的平台节点。
services：保持业务领域独立
text
services
├── mesh-app # 自定义应用、模块和页面能力
├── mesh-crm # CRM、OA、EDU 等业务域
├── mesh-ai # 模型、会话、MCP Server 与工具编排
├── mesh-demo # 示例业务
└── mesh-tmp # 临时或扩展业务模块业务服务通常继续拆分公共 API 与业务实现模块。公共 API 承载远程契约和共享对象，业务实现负责 Controller、Service 与领域逻辑。这样能够控制服务间依赖，避免其他模块直接引用内部实现。
不以目录数量衡量微服务质量
真正重要的是服务边界、数据归属和调用契约。将一个紧密耦合的系统机械拆成很多进程，只会增加部署和排障成本；蝉鸣 CRM 的模块拆分始终服务于清晰职责与独立演进。
企业级基础能力：业务增长前先解决共同问题
多账户与多种登录方式
真实人员与登录账号分离后，同一用户可以按企业策略关联手机密码、验证码、邮箱或第三方平台等账号。这样既能统一人员档案，也能独立管理登录凭据、绑定状态和安全策略。
多组织、多岗位与数据权限
企业中的“一个人属于一个部门”只是最简单情况。人员可能跨公司、跨部门任职，也可能同时承担管理和业务岗位。平台通过组织成员与岗位关系描述任职，再将菜单权限和数据范围分开治理，更接近真实组织管理方式。
完整访问判定链见多租户与数据权限专题。
多租户与 SaaS 隔离
租户是 SaaS 服务的数据边界，组织则是租户内部的协作结构。平台在身份恢复、接口访问和业务查询过程中携带租户上下文，业务模块不应依靠前端传参来决定数据归属。
数据访问、缓存与搜索
关系型数据库承载核心业务数据，Redis 用于缓存和高频访问场景，Elasticsearch 支持搜索与分析。Dynamic Datasource、MyBatis Plus 等组件为多数据源和数据访问提供统一工程能力。不同存储技术各自解决适合的问题，而不是用一种数据库承担所有工作。
文件与对象存储
平台通过兼容 Amazon S3 协议的方式接入本地文件、MinIO、阿里云 OSS 等存储。业务模块只关心文件业务关系，不需要为每个存储厂商重写上传下载逻辑。
可观测与部署治理
Nacos 承担配置与服务发现相关能力，SkyWalking 等工具帮助观察分布式调用链，监控服务提供运行状态入口。可观测性不是上线后的附属功能，而是微服务能够被维护的必要条件。
三、看懂业务如何运转：低代码、流程与 CRM 闭环
低代码体系：应用、页面、事件流与工作流如何协作
详细的需求分层与实施边界见低代码与工作流专题。
高频变化交给配置，跨角色协作交给流程，稳定规则仍然由领域代码守护。
低代码最容易出现两个极端：一种认为所有业务都可以拖拽完成，另一种认为配置只能制作简单表单。蝉鸣 CRM 采用分层组合方式解决不同类型的变化。
应用与模块定义业务边界
应用用于组织一组相关业务，模块定义具体对象和功能区域。企业可以按客户、供应商、项目、资产或行业对象建立模块，并为不同模块配置页面与字段。
自定义表单承载业务差异
同样是“客户”，制造企业可能关注设备与产线，教育机构关注年级和意向课程，旅游企业关注目的地与出行时间。标准 CRM 保存稳定的客户关系，自定义字段与表单承载行业差异，避免为了少量字段复制一套 CRM。
事件流处理页面交互
事件流适合描述组件事件、条件判断、数据请求、赋值和页面联动。例如选择客户后加载联系人、金额变化后重新计算、提交前执行校验。LogicFlow 提供可视化画布，使复杂交互关系比散落在页面代码中更容易查看。
工作流处理跨角色审批
页面事件解决“当前操作如何响应”，工作流解决“业务如何跨人员和节点推进”。合同审批、价格审批、请假、差旅和退款等场景，需要参与人、条件分支、处理意见、状态记录与归档，这些应进入流程中心统一治理。
代码仍然守护稳定规则
金额不能为负、合同状态不能随意回退、越权客户不能读取、不同租户数据不能混用，这些规则不应仅依赖页面配置。低代码负责提高表达和交付效率，后端代码负责确保数据与规则可信。
蝉鸣 CRM 业务闭环：从获客到服务的客户经营过程
客户经营不是一次成交，服务结果与反馈会继续形成复购、转介绍和下一次商机。
蝉鸣 CRM 不是孤立功能的集合，而是围绕客户生命周期连接业务对象。
text
市场渠道
↓
线索与线索池 → 客户与联系人 → 跟进与需求
↓ ↓
客户公海 ← 负责人及团队 → 商机与方案
↓
产品 → 报价/方案 → 合同 → 订单 → 回款 → 发票
↓
交付、评价与反馈售前：让每条线索进入可管理过程
官网咨询、市场活动、渠道推荐和线下拜访等信息可以进入线索体系。线索池用于承载暂未明确负责人的机会，分配后由销售持续跟进。客户与联系人分离，使系统能够描述一个企业客户内部的多角色关系。
售中：把沟通过程转化为业务对象
跟进记录保留互动历史，客户需求沉淀真实问题，商机描述成交可能与推进阶段，方案和产品连接客户需求与交付内容。合同、订单、回款和发票进一步把销售承诺连接到执行与财务结果。
售后：成交之后仍然回到客户视图
交付、评价、意见和反馈让服务结果重新进入客户关系。销售、交付和服务团队围绕同一客户协作，人员变化时也能通过历史记录还原过程。
平台能力让 CRM 可以继续扩展
多租户解决 SaaS 隔离，组织与岗位控制客户归属，工作流承接合同和价格审批，自定义表单补充行业字段，AI + MCP 帮助用户通过自然语言查询和处理授权业务。更详细的业务对象与模块说明，可以继续阅读《蝉鸣 CRM 功能详解》。
四、看懂 AI 如何进入系统：MCP 工具调用与权限边界
AI + MCP：让模型进入业务，但不越过业务边界
传统 CRM 智能化经常停留在聊天问答。模型能够写一段建议，却不知道客户、商机和跟进记录的真实状态。另一种做法是让模型直接访问数据库，这又会破坏租户、权限、字段语义和业务校验。
蝉鸣 CRM 的 AI 架构将职责拆开：
图中的闭环表达了核心边界：模型只负责理解意图和选择工具，Feign 统一契约把调用交给 CRM 领域服务，账号、租户、接口权限与数据权限始终参与实际执行。services/mesh-ai 管理模型、会话、工具与 Access Key，CRM Provider 只暴露经过治理的客户、跟进和商机能力，因此更换模型不会改变业务规则。
例如销售负责人询问“列出团队中长期未跟进的高价值商机”，模型负责理解条件和选择工具，CRM 按当前用户的数据范围返回结果，模型再进行归纳。即使修改提示词，模型也无法获得领域服务没有授权的数据。需要深入了解实现链路，可以阅读《AI + MCP 如何落地 CRM》。
AI 的正确位置
AI 适合降低查询、归纳和操作表达成本；MCP 负责把自然语言连接到受控工具；领域服务仍然是业务事实、权限与规则的最终负责人。
五、判断如何使用项目：技术、交付与适用场景
当前技术栈与版本：以工程配置为准
原始项目说明记录了不同阶段采用的版本。随着项目完成 4.1 重构，当前文章统一以仓库中的 Maven 配置和前端依赖为准。
| 技术层 | 当前主要技术 | 项目中的作用 |
|---|---|---|
| Java | JDK 21 | 后端编译与运行基础 |
| 核心框架 | Spring Boot 4.1.1 | 应用启动、自动配置与生产级基础能力 |
| 微服务 | Spring Cloud 2025.1.3 | 服务调用与分布式应用基础 |
| 微服务生态 | Spring Cloud Alibaba 2025.1.0.0 | Nacos 等生态集成 |
| AI | Spring AI 2.0.0 | 模型、会话、Embedding 与工具调用抽象 |
| 数据访问 | MyBatis Plus、Dynamic Datasource | CRUD 增强与多数据源管理 |
| 数据组件 | MySQL、Redis、Elasticsearch | 事务数据、缓存与搜索分析 |
| 前端 | Vue 3.4.37、TypeScript、Vite 6.2.0 | 管理端与业务页面开发 |
| UI 与状态 | Element Plus 2.11.2、Pinia、Vue Router | UI、全局状态和路由组织 |
| 可视化 | LogicFlow、BPMN、ECharts | 事件流、流程和数据图表 |
前端还集成 TinyMCE、ExcelJS、甘特图、打印与可视化画布等能力，能够承载富文本、表格导入导出、计划排期和复杂业务工作台。技术选择的目标不是追求清单长度，而是为已经明确的业务交互提供合适工具。
部署与交付：从本地开发到 SaaS 和私有化
SaaS 侧重快速启用，私有化侧重数据、集成与定制控制，两者复用同一产品能力。
本地与 JAR 运行
开发人员可以按照服务边界启动所需模块，结合 Maven 构建和环境配置完成本地调试。JAR 方式便于理解单个服务的启动参数、日志和依赖，也是排查问题的重要基础路径。
Docker 与 Docker Compose
Docker 将应用及其运行环境标准化，Docker Compose 适合组织多个服务与基础设施，降低测试、演示和中小规模部署的环境差异。项目文档已经覆盖 Docker 和 Compose 相关构建流程。
Jenkins 持续集成
Jenkins 用于把代码获取、构建、镜像生成和环境发布组织为可重复流程。持续集成的价值不只是“自动执行命令”，更在于减少人工步骤、保留构建记录并统一交付方式。
交付选择还需要结合容量、备份、监控、升级和运维责任统一评估，不能只比较服务器放在哪里。
适用团队与行业：先判断问题，再选择平台
更适合这些团队
- 正在从多个零散系统走向统一身份、组织和权限体系的企业；
- 需要 CRM、OA、自定义应用和审批流程协同工作的团队；
- 业务字段和流程经常变化，但核心数据规则必须稳定的组织；
- 面向集团、多公司、多部门、多岗位或 SaaS 多租户场景的项目；
- 希望在现有业务权限内引入 AI 助手与 MCP 工具调用的企业；
- 需要掌握源码、进行内部集成或私有化部署的技术团队。
可能不需要完整平台的场景
如果业务只需要一张长期不变的客户表、没有组织权限与流程要求，也不计划扩展其他业务系统，使用完整平台可能不是成本最低的方案。平台化带来统一与扩展能力，也意味着团队需要理解模块边界、部署组件和治理规则。
行业扩展方式
教育行业可以将招生线索、家长联系人和顾问跟进连接到学员、班级、课程与报名；旅游行业可以在客户经营主链路上补充目的地、人数、预算、出行时间与方案字段；制造、供应链和专业服务行业也可以采用“标准 CRM 对象 + 自定义行业模块 + 工作流”的方式逐步建设。
平台不应假装预置模板能够覆盖所有企业。更可靠的方法，是保留通用业务主线，让行业差异通过清晰模块和配置能力进入系统。
项目价值与演进方向：从管理软件走向业务协作平台
蝉鸣 CRM 的长期价值可以概括为四点：
- 统一：账号、用户、组织、租户、权限和服务入口遵循统一规则；
- 复用：公共组件、平台服务和业务对象可以服务多个应用；
- 适应：自定义应用、事件流和工作流降低业务变化成本；
- 连接：AI + MCP 将自然语言能力连接到受控的真实业务工具。
后续演进不应只是增加更多菜单，而应继续提高平台能力之间的连接质量：让自定义应用更容易使用标准业务对象，让工作流与领域状态保持一致，让 MCP 工具具备更清晰的描述、权限和审计，让行业方案沉淀为可复用而不过度绑定的模块。
从这个角度看，蝉鸣 CRM 既是一个可以直接使用的客户关系管理系统，也是一套可以持续扩展的企业业务平台。企业可以从客户管理开始，逐步增加 OA、自定义应用、行业模块与 AI 协作，而不需要每次都重新建设身份、权限和基础工程。
阅读建议
产品负责人可以重点阅读项目定位、CRM、低代码与适用场景；架构和开发人员可以继续阅读总体架构、工程结构、技术栈及 AI + MCP；部署负责人应结合 Docker、Jenkins 和私有化章节评估交付边界。
从哪里开始
如果正在评估产品，可以先体验 CRM 的客户、跟进和商机链路，再根据组织权限、审批和行业字段判断扩展范围。如果准备进行私有化建设，建议先梳理租户与组织模型、数据边界、第三方系统、容量和运维责任，再决定服务部署结构。
进一步内容：