草稿（未发布）。定位：nextagent.ca 深度文章 / members guide 候选。 配套案例：《AI 运营中枢》(/cases/medical-aesthetics-clinic)。 隐私：全篇匿名化，不含任何客户或患者可识别信息。
为什么要模块化
我们在多台服务器上运营着十几个业务系统：医美连锁的运营中枢、内部团队 OS、教育运营系统、 功能医学门户、教培平台……逐个盘点后发现一个事实：同一个能力被写了两三遍。 打卡考勤有三套实现，请假审批有三套，客户档案有三套，预约有三套。
每写一遍都要重新踩一遍坑；每个新客户项目都从零开始。这是资产在流失。
于是我们做了一件事：把所有项目盘点成一张复用矩阵（能力 × 项目）， 定一条简单规则——出现 ≥2 次的能力，抽成通用模块。
三条边界规则（宪法）
抽库之前先立宪法，否则抽出来的还是泥球：
- 模块 = 按业务能力竖切：一组自己拥有的数据表 + 围绕这些表的全部操作。 判据只有一条：改一个需求时哪些表一起动，就属于同一个模块。
- 模块间只走公开接口与事件：禁止直查对方数据表；表带模块前缀；跨模块只存对方 ID。 依赖方向单一，禁止循环依赖。
- 平台能力下沉：认证、权限、多租户、通知、文件、审计、AI 网关不属于任何业务模块， 沉为 platform 层被所有模块复用。
配套三条复用纪律：通用模块永不写 if (客户X)（差异走配置 + 扩展点）；
模块有版本号，客户项目锁版本；字段差异用「核心字段 + JSONB 自定义字段」。
抽了什么：22 个业务模块 + 8 个平台能力
按批次推进，每个模块一个 PR，五标准件齐（schema / API 契约 / 页面契约 / 配置项 / manifest）：
- HR/运营 spine（10 件）：员工核心域、打卡、请假、薪酬、提成、绩效、敬业度、 员工文档、管理任务、知识库——三套分叉实现归一为一套。
- 平台层（8 件）：多租户、认证/RBAC、事务性事件总线（outbox）、模块注册与套餐门禁、 审计（哈希链）、多渠道通知、文件存储、AI 治理网关。
- 诊所域（4 件）：客户档案+线索、预约/排班/资源、开单/收款/储值账本、治疗记录。
- EdTech（3 件）：排课运营、教学（班级/作业/掌握度）、题库+间隔重复。
- 表单引擎（1 件）：动态 schema 表单/同意书，医疗与 HR 共用。
抽库中沉淀的四件「设计资产」
模块清单之外，更值钱的是几条被生产验证过的设计：
1. 实收 ≠ 核销的记账铁律。 现金/卡收款（实收）与套餐/会员/积分/礼卡抵扣（核销）分列记账； 储值「购买 → 兑现」级联中现金只在第一步计一次。系统层面不提供两者相加的口径—— 老板看到的营收永远账实相符。
2. 跨模块动作事件化（合并契约）。
「合并重复客户档案」在单体里是一次改 25 张表的级联更新；模块化后，
客户模块只迁自己的表并广播 client.merged 事件，预约、账单、治疗各自订阅、
各自重指向。每个模块对自己的数据负责，契约清晰可测试。
3. schema 驱动的临床记录。 治疗类型与表单字段全部由模板配置（JSONB schema）：注射类、能量设备类、皮肤管理类、 输液类只是预置模板，新治疗项目零代码上线。签署即锁定、快照不可变，满足医疗合规。
4. 就绪检查注册制。 预约模块不直读「同意书签了没」「术前照片拍了没」——表单模块和治疗模块把检查项 注册给预约模块。边界干净，各自演进。
外部系统怎么办
预约 SaaS、EMR、支付网关一律降级为「外部映射 + 可选同步扩展」： 核心系统自持数据真源，第三方 ID 存在统一的映射表里，同步逻辑是可拔插的扩展。 替换任何一家供应商，主干不动。
这对下一个客户意味着什么
资产库里每个模块都带一份 manifest（给人也给 AI 读的商品说明书：能力/接口/依赖/配置项）。 新项目的启动方式变成：
- 圈模块（诊所类：客户+预约+开单+治疗；教培类：排课+教学+题库……）
- 装平台地基（多租户/认证/事件总线）
- 按依赖序建表、填配置、接事件
- 客户差异走配置与扩展点；实在不行 fork 定制版并登记
从零开发变成按模块拼装——周级起步，而且每个模块都带着生产系统验证过的边界与口径。
NEXT AGENT：我们不卖通用 SaaS。我们把你的运营流程长成属于你的系统。