全生命周期服务管理系统开发实战：数据模型与服务计划引擎-代码聚汇网

全生命周期服务管理系统开发实战：数据模型与服务计划引擎

埃里克 Eric·2026-09-03·阅读 21 GEO检测（免费）

全生命周期服务管理系统服务计划引擎

|难度：普通|阅读约 37 分钟

有一次需求评审会上，产品经理把一页PPT翻到最后一页，上面只写了四个字：“呵护一生”。我第一反应是这又是一句营销话术，直到他补充了需求细节：用户从首次登记建档开始，往后五年、十年甚至更长周期内的定期服务计划、健康提醒、家属通知、服务执行记录，全部要在一个系统里跑起来。那一刻我才明白，这个“呵护一生模式系统”不是做一个简单的下单工具，而是一套以用户为轴心的全生命周期服务管理系统。

这类系统在医疗健康、养老关怀、母婴服务、长期会员制服务等领域越来越常见，核心逻辑都是同一个：把“一次性的交易”变成“持续的服务关系”。但真正动手开发时会发现，它和普通业务系统有一个本质区别——时间成了系统的第一维度。所有数据、流程、状态都要放在时间轴上设计，这也是“呵护一生模式”最大的技术门槛。

这篇文章我会从需求建模、数据表设计、服务计划引擎、消息触达、权限合规，再到上线后的坑，完整拆解一套这类系统的开发过程。无论你是后端开发、技术负责人，还是想理解系统逻辑的产品经理，都能在里面找到可以直接落地的思路。

1. 开工前先读懂“呵护一生”这三个字的业务分量

1.1 这不是一个普通CRM：全生命周期服务的核心差异

大多数团队拿到“呵护一生”这类需求时，第一反应是“这不就是个CRM吗，建个客户表、加个跟进记录就完事了”。实际做进去才发现完全不是一回事。

普通CRM管的是“销售过程”，核心动作是跟进、转化、成交，一条客户记录的生命周期可能只有几个月。而“呵护一生模式系统”管的是“服务履约”，核心动作是按时触达、持续记录、动态调整，一条用户记录的生命周期可能是几年甚至几十年。这意味着系统必须具备三个普通CRM没有的能力：

时间驱动的自动任务能力：不是靠人工想起来才去服务，而是系统按计划自动生成待办、自动发送提醒。
历史档案的连续性：用户换了手机号、换了地址、甚至换了服务人员，历史的服务记录、健康数据、沟通内容必须完整保留并串成一条时间线。
服务计划的动态调整能力：用户状态会变（比如从健康管理转入康复护理），服务计划不能是一张死表，必须能暂停、续期、变更频率。

我见过有的团队直接用现成CRM改造，结果做到一半就卡死了。原因很简单：CRM的底层模型围绕“销售漏斗”设计，没有“服务周期”这个一等公民概念，强行改造到最后全是补丁。所以如果你接到类似需求，第一件事不是选型，而是确认业务上到底要跑多久、跑多深。

1.2 梳理角色与场景：谁在服务谁，服务多久

需求评审时我跟产品经理对齐的第一个问题是：这个系统里有哪几类人？最终梳理下来通常包含四类核心角色：

角色	核心诉求	系统内的典型行为
终端用户	获得持续、稳定的关怀与服务	查看服务计划、接收提醒、确认服务、查看历史档案
服务人员	按计划执行服务并记录结果	查看当天待办、执行服务、上传记录、提交异常
家属/监护人	了解被服务人状态	接收通知、查看报告、发起服务需求
运营/管理员	保证服务履约、处理异常	配置计划模板、查看履约报表、处理投诉与异常

这四类角色里，最容易漏掉的是“家属/监护人”。很多团队设计系统时只考虑用户本人和员工，但“呵护一生”这个业务场景下，真正频繁使用小程序的往往是子女或亲属。所以从需求阶段就要把“被服务人”和“操作人”两个概念分开建模，否则上线后会发现所有数据都挂在一个人名下，家属根本没法代查。

1.3 业务流程串联：从登记建档到服务评价的完整链路

系统的主业务流程，我习惯用一条纵向时间线来梳理，而不是传统的功能列表：

建档登记：录入用户基本信息、健康状态、服务偏好、紧急联系人。
评估分级：根据健康数据和需求填写评估表，系统自动推荐服务方案。
计划生成：基于服务方案生成周期性的服务计划（比如每周上门一次、每月体检提醒一次）。
履约执行：服务人员按计划上门/远程服务，在系统里确认到位、填写服务记录。
动态调整：用户状态变化或服务人员发现问题时，申请调整计划频率或服务内容。
关怀触达：系统按节点自动推送提醒（生日、复查、节气关怀等）。
评价反馈：用户或家属对每次服务进行评价，评价结果进入服务人员绩效。
档案沉淀：所有记录自动归档到用户终身档案，形成可查询的历史时间线。

这个流程画出来之后，系统的技术架构其实已经呼之欲出了：用户档案域、计划引擎域、执行记录域、消息触达域、评估分析域。后面所有的表设计和接口设计，都围绕这几个域展开。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据模型设计：从“一次服务”到“终身档案”

2.1 用户档案表：服务历史的“根节点”

“呵护一生”系统的数据模型，要求所有表都要跟用户档案产生关联，这条关系链是整个系统的生命线。用户档案表不能只存姓名手机号，至少要考虑以下字段组：

身份信息组：姓名、性别、出生日期、证件类型、证件号码、头像。
联系信息组：手机号、微信OpenID、紧急联系人、家属手机号、居住地址。
健康状态组：血型、过敏史、慢性病标签、当前用药情况、行动能力等级。
服务属性组：客户等级、服务状态（待评估/服务中/已暂停/已终止）、签约开始日、签约到期日。
扩展字段组：用于承接不同业务线的定制属性。

这里有一个非常重要的设计技巧：健康状态组字段不要用布尔值，要用“属性名+属性值+生效时间”的子表结构。比如“高血压”这个标签，不是简单地在user表里加一个is_hypertension字段，而是维护一张user_health_tag表，记录标签名、标签值、开始时间、结束时间、录入人。因为用户的健康状态是动态变化的，你永远不知道未来会新增什么标签，硬编码字段会让系统越改越僵化。

实际开发中，我用的是这种结构：

sql复制CREATE TABLE `user_profile` (
  `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  `profile_no` VARCHAR(32) NOT NULL COMMENT '档案编号，业务唯一',
  `name` VARCHAR(64) NOT NULL,
  `gender` TINYINT NOT NULL COMMENT '1男 2女 0未知',
  `birth_date` DATE DEFAULT NULL,
  `id_card_hash` VARCHAR(128) DEFAULT NULL COMMENT '证件哈希，用于唯一性校验',
  `id_card_encrypted` VARBINARY(255) DEFAULT NULL COMMENT '证件密文',
  `phone_encrypted` VARBINARY(255) DEFAULT NULL COMMENT '手机号密文',
  `emergency_contact_name` VARCHAR(64) DEFAULT NULL,
  `emergency_contact_phone` VARBINARY(255) DEFAULT NULL,
  `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1待评估 2服务中 3已暂停 4已终止',
  `service_start_date` DATE DEFAULT NULL,
  `service_end_date` DATE DEFAULT NULL,
  `created_by` BIGINT NOT NULL,
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  KEY `idx_status_start` (`status`, `service_start_date`),
  KEY `idx_profile_no` (`profile_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

2.2 服务计划表与生命周期状态机

服务计划是“呵护一生”系统最核心的领域对象。它不能像普通订单表那样只用订单状态字段，而是需要一个状态机来管理“计划”和“计划实例”两个层级。

我的设计思路是拆成两张表：

service_plan_template（服务计划模板）：定义一类服务计划的标准，比如“高血压月度关怀计划”，包含计划名称、周期类型（周/月/季/年）、间隔天数、首次执行日期、有效时长、服务内容配置。
service_plan（用户服务计划）：为用户实例化出来的具体计划，包含模板ID、用户ID、计划开始日期、计划结束日期、当前状态、暂停原因、暂停起止时间。

状态机设计是这里的关键。一个用户服务计划的状态流转，我建议这样设计：

待执行：计划已生成，尚未开始第一个周期。
执行中：计划正常运行，任务按节奏生成。
已暂停：用户要求或运营介入暂停，暂停期间不生成新任务。
已终止：计划结束，不再生成任何任务。
已完成：到期自然结束，所有周期任务执行完毕。

不同状态之间的转换必须有明确的前置条件。比如“执行中”到“已暂停”，必须记录暂停原因、暂停人、暂停时间；从“已暂停”回到“执行中”，恢复日期必须落在计划有效期内，同时要计算暂停期间漏掉的任务是否需要补生成。这些规则在状态机里写清楚，远比在业务代码里堆if else要稳妥。

一个容易踩坑的地方，就是“暂停恢复后的任务补偿”。比如用户暂停了一个月，恢复时系统要不要把暂停期间的三次服务全部补齐？这个必须由产品明确规则。我在实际项目中采用的方案是：默认不自动补，恢复时生成一条“补偿建议”给运营人员，由人工判断是顺延还是补做，避免系统自作主张导致服务人员工作量失控。

2.3 字段设计的两个隐藏细节：扩展字段与软删除

做这类长期系统，有两个细节如果你在设计初期没想清楚，后期大概率要返工。

第一个是扩展字段设计。用户档案、服务记录这类长期沉淀的数据，未来必然会有新的属性接入。我的建议是不要一开始就把所有字段都建成硬编码列，而是预留一层JSON扩展字段。MySQL 5.7以上版本原生支持JSON类型，查询用JSON_EXTRACT也能走函数索引，应对中小规模业务完全够用。

sql复制ALTER TABLE `user_profile` 
  ADD COLUMN `extra_info` JSON DEFAULT NULL COMMENT '扩展信息';

但要注意，JSON字段只用在不参与高频查询条件的场景。比如用户饮食偏好、服务备注这类只读展示的信息可以放JSON，但“是否需要上门护理”这种要作为筛选条件、要统计报表的属性，必须建独立列并加索引。

第二个是软删除。涉及用户健康、服务履约数据，原则上禁止物理删除。每一张业务表都建议带上deleted字段，默认0，删除时置1。查询所有业务数据的Service层，一律强制追加deleted = 0条件，并且配合MyBatis的拦截器或JPA的@Where注解统一处理，避免开发人员有哪一天写SQL忘了过滤。

3. 服务计划引擎：让“关心”按节奏自动发生

3.1 计划生成器的实现思路

服务计划引擎是这个系统的心脏。一句话概括它的职责：根据用户的服务计划和当前日期，计算出每天应该执行哪些服务任务。

最简单的实现方式是每天跑一次定时任务，扫当天所有处于“执行中”状态的服务计划，按计划周期把当天的任务查出来。但这里有一个周期计算的问题：月度计划到底是按“自然月”还是按“开始日期后的30天”来循环？这两种语义不同，结果完全不一样。

我建议统一抽象出一个next_execution_date字段，计划生成时采用“滚动周期”的计算方式：

java复制public LocalDate calculateNextDate(LocalDate currentDate, CycleType cycleType, int interval) {
    switch (cycleType) {
        case DAY:
            return currentDate.plusDays(interval);
        case WEEK:
            return currentDate.plusWeeks(interval);
        case MONTH:
            // 按月滚动，处理月末边界：1月31日 + 1个月 = 2月28日
            return currentDate.plusMonths(interval)
                    .with(TemporalAdjusters.lastDayOfMonth());
        case YEAR:
            return currentDate.plusYears(interval);
        default:
            throw new IllegalArgumentException("unsupported cycle type");
    }
}

这里要注意一个容易被测试忽略的边界：如果是“1月31日开始，每月执行”，按天加30天的算法会出现漂移，到下个月变成了3月2日；而用plusMonths(1)配合lastDayOfMonth的调整器，2月会正确落到28日。我建议生成计划时统一走这个逻辑，并且把“日历月”和“间隔月”作为两种周期类型明确区分，别混在一起。

计划生成器的完整流程是：

每日凌晨1点，触发定时任务，扫描所有“执行中”计划。
对每个计划，从上一次执行日期开始，循环计算下一次执行日期，直到计算出的日期大于今天。
将计算出的任务写入service_task表，状态为“待执行”。
如果任务日期与用户个性化日期（比如生日、手术纪念日）重合，标记为“特殊关怀任务”，优先触达。

3.2 任务调度与幂等：一次都别漏，也一次都别重

任务生成最怕两件事：漏生成和重复生成。漏生成好理解，定时任务挂了或者扫描范围有遗漏，用户今天该被服务没被服务；重复生成更隐蔽，可能是定时任务被手动触发了几次，也可能是消息队列重试导致消费了两遍。

解决这两类问题的核心手段是唯一约束+幂等键。

sql复制CREATE TABLE `service_task` (
  `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  `plan_id` BIGINT NOT NULL,
  `user_profile_id` BIGINT NOT NULL,
  `execute_date` DATE NOT NULL,
  `task_type` VARCHAR(32) NOT NULL,
  `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待执行 1已完成 2已取消',
  `assignee_id` BIGINT DEFAULT NULL COMMENT '执行人',
  `idempotent_key` VARCHAR(64) NOT NULL COMMENT '幂等键',
  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY `uk_plan_date_type` (`plan_id`, `execute_date`, `task_type`),
  UNIQUE KEY `uk_idempotent` (`idempotent_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

幂等键的生成规则我用的是plan_id + execute_date + task_type，在业务代码里先尝试插入，捕获唯一键冲突就跳过。这样即使定时任务重复执行，或者消息队列重复投递，同一张计划同一天同类型的任务也只会有一条记录。

另一个值得注意的点是：任务生成和任务通知要解耦。任务生成后先落库，再发MQ消息触发通知，不要在一个事务里既写任务表又调外部接口。否则外部接口超时会导致事务回滚，任务没生成、消息也没发出去，两边都丢了。

3.3 计划的动态调整：当用户说“我想暂停一阵子”

用户提需求说“我下个月要出差，服务暂停一个月”，这个动作听起来很简单，但落到系统里有几个地方要处理：

暂停时正在执行中的任务怎么办：如果用户已经确认了明天下午的服务，暂停操作不能把这个任务默默删掉，要先进入“待确认取消”状态，由人工或服务人员联系用户确认。
暂停期间的计划生成逻辑：计划状态变为“已暂停”后，生成器必须跳过这个计划，不能继续生成任务。
恢复时的重新计算：恢复后服务计划的next_execution_date要重新计算，而不是沿用暂停前的日期，否则用户回来当天就被安排服务，体验很差。
暂停时长超过有效期：恢复日期晚于计划结束日期，系统要自动触发“续期申请”流程，而不是直接错误提示。

我在设计服务计划状态机时，专门加了一个pause_history表记录每一次暂停的起止时间、原因、操作人。后续做履约率报表时，这些数据能帮你区分“计划内未执行”和“暂停导致未执行”，口径才能讲清楚。

4. 消息触达：提醒不是发了就完事

4.1 触达渠道的选择与优先级

“呵护一生”系统面向的用户群体跨度很大，有年轻人也有老年人，触达渠道不能只用一种。我建议按优先级做多渠道策略：

微信服务通知/小程序订阅消息：触达率最高，适合服务提醒、待办通知。
短信：兜底渠道，适合重要通知和微信消息发送失败后的补发。
电话外呼：适合紧急情况，比如用户连续两次未确认服务、健康数据异常预警。
App Push/站内信：适合用户主动打开App时的信息展示，触达率相对低。

这里要注意“订阅消息”的一次性订阅限制。微信小程序订阅消息默认是一次性的，用户订阅一次只能收到一条通知，这对周期性服务来说是致命的限制。解决办法有两个方向：一是引导用户使用“长期订阅消息”（目前只有特定类目开放），二是在每次触达时都附带一个订阅引导卡片，让用户持续授权。

4.2 消息重试与回执：别把用户的消息弄丢

消息发送的完整流程，我建议这样设计：

系统生成消息记录，状态为“待发送”。
投递到MQ，消费者根据用户配置的渠道顺序发送。
发送成功后回写消息记录状态。
发送失败进入重试队列，最多重试3次，间隔分别为1分钟、5分钟、30分钟。
重试仍失败，标记为“发送失败”，人工介入处理。

关键点是消息记录表里一定要记录每次发送的返回结果。以微信为例，不仅要记录errcode，还要记录msgid。后期排查“用户说没收到消息”时，用的就是这些数据。

还有一个常见的坑：用户换了设备或取关了服务号，导致微信消息发送失败。这种失败不是网络问题，重试多少次都没用。我建议在重试之前先判断失败码，如果是因为用户取消关注、未授权等“不可恢复”的原因，直接终止重试并给运营人员告警，避免无效重试刷爆日志。

4.3 触达文案与频率控制：过度打扰也是事故

运营人员最容易犯的毛病是只关心“触达率”，不关心“打扰指数”。系统设计上要有频率控制机制：

每日触达上限：同一用户每天最多收到N条系统消息，超出部分合并。
静默时段：晚上21点到次日8点不发送非紧急消息。
内容去重：同一类型的提醒在短时间内不能重复发送，比如“服务确认提醒”最多提醒2次，否则用户会直接拉黑。

这个频率控制逻辑，不能只靠运营人员的自觉，必须在系统里用代码强制。我之前遇到过因为运营配置失误，一个用户一天收到了七条“服务待确认”短信，用户的投诉电话直接打爆了客服中心。从那以后我在消息发送模块里加了一个统一网关层，所有消息都要经过“频率校验器”校验，不通过的直接拦截并记录原因。

5. 权限、隐私与合规：这类系统最容易翻车的地方

5.1 角色权限模型：员工看得见什么，看不见什么

涉及用户健康档案和家庭信息的系统，权限模型必须从第一天就严格设计。不要指望上线后再加。我采用的是典型的RBAC模型加数据范围控制：

角色：超级管理员、运营人员、服务人员、区域经理、客服人员。
权限点：用户查看、用户编辑、计划配置、任务派单、消息发送、报表查看、日志查询。
数据范围：服务人员只能查看自己绑定的用户档案；区域经理能查看本区域所有用户，但不能跨区；运营中心能查看全量用户。

数据范围控制实现时，最稳妥的方式是在所有查询用户的SQL里强制拼接权限条件。比如服务人员查询用户列表时，通过MyBatis的拦截器自动追加WHERE assignee_id = 当前用户ID，而不是依赖开发人员自觉。

5.2 隐私合规：敏感数据的存储与脱敏

用户的手机号、身份证号、健康信息属于敏感数据，存储上要有明确的分级策略：

明文可逆加密：手机号、身份证号用AES加密后存储，查询时解密展示。
单向哈希：身份证号、手机号需要做唯一性校验时，使用SHA-256加盐哈希，用于判断是否重复建档。
脱敏展示：列表页默认只显示138****1234，只有白名单角色可以查看完整信息。
访问审计：查看完整敏感信息的操作必须记录审计日志，包括查看人、查看时间、查看原因。

这里我有一个自己总结出来的经验：加密和哈希并存。一开始我图省事只做了加密，后来做“同一身份证是否重复建档”的校验时发现，解密后全量比对的方式效率太低、而且有泄露风险。后来改成加密存储+哈希索引，既保住了明文可恢复的需求，又实现了高效的去重校验。

5.3 操作日志：出事之后唯一的“现场”

长期运行的系统，一定要有完备的操作日志。包括用户资料修改记录、服务计划变更记录、任务状态流转记录。我建议在核心业务表上统一增加审计字段，并且关键操作通过AOP切面记录到独立的operation_log表。

日志字段包含：操作人ID、操作人角色、操作类型、操作对象ID、请求参数摘要、操作前数据快照、操作后数据快照、操作时间、IP地址。这种日志在排查“用户说服务人员没来，但系统显示已服务”这类纠纷时，是唯一能还原现场的依据。

6. 上线前后最值得复盘的五类坑

6.1 调度任务凌晨没跑：时钟与Cron的教训

服务计划生成器我用的是每天凌晨1点的定时任务。上线第二天早上运营反馈“今天的任务全都没生成”，排查下来发现是服务器时区设置成了UTC，凌晨1点（北京时间）对应的是前一天下午5点（UTC），任务确实跑了但因为日期边界问题没扫到数据。

这个问题的教训有两个：一是服务器上所有业务时间统一用北京时间，不要依赖操作系统时区；二是定时任务里凡涉及“今天”的判断，都必须显式传入目标时区的LocalDate，而不是直接用new Date()然后格式化。另外建议调度任务都要有“失败告警+自动补偿”机制，比如补一个“每10分钟扫一次延迟任务”的检查任务，避免定时任务挂掉后用户完全不被服务。

6.2 数据库自增主键在“服务档案”场景下的风险

用户档案表我最初也是用自增主键，后来发现一个问题：客服打电话跟用户核对档案时，需要报一个“档案编号”，自增主键生成的连续编号容易暴露出系统的用户规模，还容易被人遍历抓取。后来我改成独立的profile_no业务编号，用“前缀+日期+随机数”的方式生成，主键ID仍然保留用于内部关联，但对外永远只暴露业务编号。

如果你也有类似需求，业务编号生成规则建议为：HV + yyyyMMdd + 6位随机数字。生成时加唯一索引，冲突就重试，并发量不大的场景下完全够用。

6.3 报表统计口径混乱：按计划时间还是按执行时间

运营报表里有一个必踩的坑：“履约率”到底按计划时间算还是按实际执行时间算。

我在项目里吃过亏：某个服务人员把本周三的任务提前到本周一执行了，按计划时间统计，周三的任务显示“未完成”，按执行时间统计，周一的报表多了一条记录，两边数据对不上，运营开会时差点吵起来。

最终我们的解决方法是：报表底层明确三个指标口径——应执行数（按计划日期统计）、实执行数（按执行日期统计）、按期执行数（执行日期等于计划日期的任务数），每个指标都在报表字段命名里带上前缀，不允许出现模棱两可的“完成数”。同时任务表和执行记录表分开，任务负责承接计划节奏，执行记录负责记录实际情况，报表汇总时用日期维度做关联。

6.4 系统间接口超时：下游慢不一定是下游的错

消息触达模块对接了短信服务商的接口，上线初期经常出现“发送超时”的告警。一开始我们以为是短信服务商的问题，后来排查发现是本地代码在调用短信接口之前，要先查用户表判断用户是否订阅了短信，而这条查询走了一个没有索引的慢查询，导致整个接口平均耗时2秒以上。

这类问题在系统中的表现就是“下游接口超时”，但根因往往在上游。我建议所有外部接口调用的超时时间要单独配置，并且调用链路上的每一个环节都要有埋点统计。排查的时候先看整体耗时分布，再逐层定位，比直接找供应商扯皮要高效得多。

6.5 测试环境与生产环境的数据隔离

最后一个坑也是老生常谈，但必须提：测试环境绝对不能直连生产数据库，尤其是涉及用户健康档案的系统。我在项目中采用了“生产数据完全隔离策略”，测试环境一律使用脱敏后的仿真数据，通过数据脱敏工具将手机号、身份证号、地址等敏感字段替换为测试值。

这个约束不仅是数据安全问题，也是逻辑正确性的问题。我遇到过开发人员为了省事，直接用生产库的备份在测试环境调试，结果定时任务在测试环境真实发送了一批短信给生产的用户，用户一脸懵地点开发现内容完全不相关，直接投诉到主管部门，那次事故让我记忆深刻。

另外生产环境的定时任务要有“执行环境”校验：任务启动时先检查当前环境变量，非生产环境直接跳过对用户真实触达的操作。这算是一个兜底开关，放在启动入口处，防止有人误操作。

回到最开始的那句话，“呵护一生模式系统”真正开发的难点，从来不在于某个算法有多难写，而在于怎么用可持续的方式，把“关心”这件听起来很软的事，变成一套稳定、安全、可追踪的工程系统。数据模型的根基决定了它能跑多远，服务计划引擎决定了它靠不靠谱，消息触达和权限合规决定了用户敢不敢用。这几块想明白了，剩下的细节就是水到渠成的事。

如果让我重新做一遍这个系统，我会在动手写代码之前，花更多时间和产品经理、运营人员一起把“服务计划的状态流转规则”抠得再细一点。因为后面所有复杂的设计，其实都是为这个规则服务的。系统能不能经受住时间的考验，从第一张表设计的那一刻就已经注定了。