这一篇讲两件事：会员制这套体系落到系统里究竟是什么样（难点根本不在系统，在数据定义），以及为什么我选做「83 个工具」而不是「一个大平台」——后者几乎必然延期。
站点：memberhandbook.cn，《会员制营销实战手册》站点，83 个工具 + 实战案例，React SPA。
旗舰内容资产：《会员制营销实战手册》19 章，理论层 28 万字 + 实战层 44 万字 = 72 万字（全口径：含站点与素材池；书稿本体实测 26.5 万字，见 33 篇）。
CRM 侧：迭代收尾六项已全部走完（better-sqlite3 → Vue3 重构 → 测试 → CI/CD → API 文档 → 监控），部署在一台独立 Linux 单机上、对外只暴露一个端口，PM2 守护。
另一条产品线：AlignHub Pro 七步共识工作坊。
相关基础篇：模块 11 · 数据迁移实战、16 · 数据库怎么存东西、16 · 数据库深入（SQLite 与 JSON blob 机制）、复盘 24 · 德莉玛 monorepo。
很多人以为「会员制系统」就是一张会员表 + 一个积分字段。不是。会员制的难点全部在「定义」上——而定义会直接变成一个系统的字段口径。
| 环节 | 必须先定死的定义问题 | 对应工具 | 系统里要落什么 |
|---|---|---|---|
| ① 分层 | 「最近」是最近一次消费还是最近一个周期？R 用天数还是月份？F 算几单算一次？M 用百分位还是绝对值？ | RFM 分层工具（Ch10） | 会员表 + 消费流水表 + 分层重算任务 |
| ② 策略 | 五个层各对应什么权益？「重要发展」和「重要保持」的区别动作是什么？ | 会员等级 / 权益规则 | 规则表（层 × 权益 × 有效期） |
| ③ 触达 | 触达算「发出」还是「被读」？没被读算不算触达失败？ | 触达记录 / 内容库 | 触达日志（时间、通道、对象、结果） |
| ④ 回流 | 「复购」的间隔怎么算？跨门店算不算同一会员？LTV 是累计毛利还是累计充值？ | 复购分析 / LTV 工具 | 会员唯一 ID 口径 + 跨店归集 |
83 个工具听起来很多。但拆开看，它们大部分不是 83 套算法，而是同一套数据模型的 83 个视图。这个认知直接决定了维护成本。
| 底层数据模型 | 被哪些工具消费 | 「视图」之间差在哪 |
|---|---|---|
| 会员档案 | 会员列表、会员详情、会员画像、等级卡、积分明细 | 同一份档案，换个维度切：按等级切、按最近消费切、按积分切 |
| 消费流水 | RFM 分层、复购分析、LTV、客单价、品类占比 | 同一批流水，换聚合口径：按人聚合、按店聚合、按时间段聚合 |
| 权益规则 | 等级权益、券包、兑换、权益核销 | 同一套规则，换生效时机：领取即享 / 门槛触发 / 到期失效 |
| 触达记录 | 触达列表、效果复盘、内容库、话术模板 | 同一批日志，换统计角度：按通道、按策略、按会员层 |
| 活动批次 | 活动编辑、报名、复盘、ROI | 同一批活动，换阶段：进行中 / 已结束 / 未开始 |
这不是规模差别，是交付方式差别。同一件事，两种做法的现金流和风险曲线完全不同。
| 对照维度 | 工具箱（83 个工具） | 大平台（会员制 CRM 全套） |
|---|---|---|
| 立项成本 | 最小单元 = 一个工具，两三个工具就能掏出第一笔收入 | 要先把整张图画完才动工，前期投入全在看不见回报的地方 |
| 验证速度 | 工具单独可验证：有人用、有人复购，才有下一个 | 要等整体上线才能验证，但整体上线日通常不存在 |
| 收款节奏 | 每个工具单独可卖，回款跟着交付走 | 一次性收款 + 一次性交付，收入全押在最后 |
| 失败成本 | 一个工具没人买，损失是一个工具的工期 | 平台延期，损失是整个项目的工期加尾款 |
| 迭代方式 | 单工具闭环，改它不影响别人 | 功能之间强耦合，改一个要回归一片 |
| 你能一个人做吗 | 能：工具边界天然小，一个人能端到端负责 | 不能：一个人的认知撑不起「平台」的完整度 |
这一层的价值不在「又重构了一遍」，在于每一步都有一个「没它还不行」的具体理由。逐条讲，不吹。
| 阶段 | 做了什么 | 「非做不可」的理由 | 状态 |
|---|---|---|---|
| ① better-sqlite3 | 先用同步驱动把数据层跑通 | 起步期最快的选择，它的同步 API 在开发期几乎无感 | 已走完 |
| ② Vue3 重构 | 前端从老写法迁到 Vue3 | 同步 API 在高并发下会阻塞事件循环——这才是重构的真正触发点，不是「技术要新」 | 已走完 |
| ③ 测试 | 给核心链路补断言 | 重构完没有测试就等于没重构，只是换了个写法继续出老 bug | 已走完 |
| ④ CI/CD | 提交即构建、构建完即部署 | 手工部署时「我本地是好的」发生太多次，需要一台机器替我说实话 | 已走完 |
| ⑤ API 文档 | 把接口清单落成可查的文档 | 工具箱要卖出去，用的人得先看见它能干什么 | 已走完 |
| ⑥ 监控 | 进程存活 + 错误上报 | 唯一无人值守时段的防线：半夜挂了不能等到客户早上打电话 | 已走完 |
这一节是整篇复盘里最「自曝」的部分，但我觉得它是加分项：一个工程师的知识库如果只有好消息，就不叫知识库。
better-sqlite3 命中 26 个文件。| 层次 | 写的是什么 | 该不该标哪一栏 |
|---|---|---|
| 设计 | 「这个站点理论上用 React 19 + tRPC + MySQL 最合适」 | 设计栏：可以写，但必须标「预案 / 建议」 |
| 实施 | 「这个站点现在跑在 X 上，用的是 Y」 | 实测栏：这一栏必须以代码盘点为准 |
| 混淆点 | 两者混在一段里说，读者分不清哪句是真跑着、哪句是想用 | 知识库出错就出在这里 |
我做的不是「把文档里的 MySQL 删掉」这种表面修正，而是全盘扫一遍依赖命中，让数据自己说话：
| 依赖 | 命中文件数 | 说明 |
|---|---|---|
express | 85 | 后端 HTTP 层的真实主力 |
react | 85 | 前端框架（与 express 同量级，说明确实有前端工程） |
vue | 74 | 和 react 同时存在——这条最能说明「两套栈是真的都在跑，不是文档写错一个字」 |
ffmpeg | 67 | 视频处理链 |
better-sqlite3 | 26 | SQLite 家族的真实占比 |
sharp | 24 | 图片处理 |
tailwindcss | 3 / 4 | 样式（Vue3 那边的版本独立计数） |
drizzle-orm | 7 | ORM 覆盖面不广，远不是「全站 ORM」 |
zod | 9 | 入参校验 |
| 规矩 | 具体写法 |
|---|---|
| 文档必须分两栏 | 「实测（代码盘点结果）」和「预案（设计时打算用）」分开写，不许混段 |
| 覆盖性用数字说话 | 不说「用 ORM」，说「drizzle-orm 命中 7 个文件」，7 和 70 是两种完全不同的项目 |
| 允许自曝不一致 | 不一致就写进知识库，并写清「我是怎么发现、怎么纠正的」——这比一个永远正确的文档有用得多 |
做了 83 个工具之后，我最想劝同行的一句：这三个词不定义清楚，工具做得再多也算不出一个统一的数。
| 词 | 最常见的错定义 | 会算出什么 | 必须定死的三件事 |
|---|---|---|---|
| 「活跃」 | 「有消费就算活跃」 | 一个月消费 1 元的会员和天天来的会员分层一样 | ① 时间窗（30 / 90 / 365 天） ② 动作口径（消费 / 登录 / 触碰任一） ③ 是否含退单 |
| 「复购」 | 「买第二次算复购」 | 跨店买和同店买被当成同一件事；赠品和主品被算成两单 | ① 间隔上限（多久之内算第二次） ② 归属（同会员 / 同门店 / 同品类） ③ 是否剔除退换 |
| 「LTV」 | 「会员累计花了多少」 | 这是营收不是 LTV：没扣成本、没扣折扣、没定有效年限 | ① 口径（毛利 / 净利 / 流水） ② 时间窗（终身 / 12 / 24 个月） ③ 成本项（退换、券、履约） |
还有一条线容易搞混：内容资产（手册）和产品，是两回事；工作坊又是第三回事。
| 《会员制营销实战手册》 | AlignHub Pro 七步共识工作坊 | |
|---|---|---|
| 形态 | 19 章内容，理论层 28 万字 + 实战层 44 万字 = 72 万字（全口径：含站点与素材池；书稿本体实测 26.5 万字，见 33 篇） | 一次线下 / 线上流程，7 个步骤 |
| 卖什么 | 卖知识（读懂、能照着做） | 卖共识（团队对齐、口径统一） |
| 交付物 | 可读、可查、可引用的内容 | 一支对齐过的团队 + 一份共识记录 |
| 系统在其中 | 只是承载（站点 + 工具） | 系统只是记录载体，不是产品本身 |
| 能不能被抄 | 内容难抄（要真做过才写得出来） | 流程难抄（要能带、能控场） |
做过，而且我要先纠正一个常见误解：会员制的难点不在系统，在数据定义。我做过 83 个工具 + 一套 CRM，四步路径是分层 → 策略 → 触达 → 回流，这四步里真正写代码的只有第三步和第四步——第一第二步几乎全是配置。它的技术难度被严重高估，业务定义难度被严重低估。
最典型的三个定义坑：什么叫「活跃」、什么叫「复购」、LTV 怎么算。「活跃」如果是「有消费就算」，那一个月消费 1 元的会员和天天来的会员分层一样；「复购」如果是「买第二次算」，赠品和主品会被算成两单；LTV 如果是「累计花了多少」，那是营收不是 LTV，没扣成本也没定有效年限。这三个词一日不统一，83 个工具就会算出五套数，而且每一套内部都自圆其说。所以我开工前的第一份产出不是代码，是《会员口径说明书》。
RFM 那条我踩过一个具体的坑：M 必须是百分位不是绝对值。我一开始差点写成「消费金额超过 5000 就是高 M」——在会员制里老会员金额天然高，用绝对值会把新客永远判成低价值，导致新客永远拿不到该给新客的权益。用百分位才是同一场比赛里的排名。
第二个想讲的是产品形态：我为什么做「工具箱」不做「平台」。同一件事，两种交付方式。工具箱的最小单元是一个工具，两三个工具就能掏出第一笔收入，每个工具单独可卖、可验证、可迭代；平台要先把整张图画完才动工，收入全押在最后，而且功能强耦合，改一个要回归一片。
「平台」和「工具箱」不是规模大小，是交付节奏的区别。我确实画过一版完整的会员制 CRM 平台设计，画完之后算了一笔账，那是一个我不想签的项目，所以把它拆成了 83 个工具——第一个能在几周内交出去，而不是几个月。工具箱的债我也认：边界划多了会重复，所以我压一条标准——如果一个新工具和已有工具的差别只是换个筛选条件，它不配单独存在。
技术侧我把它跑收尾了六步：better-sqlite3 起步 → Vue3 重构 → 测试 → CI/CD → API 文档 → 监控。但我要强调这条：每次重构都必须说得出「没它还不行」的理由。Vue3 重构之所以值，是因为better-sqlite3 的同步 API 在高并发下会阻塞事件循环——是这个问题触发的，不是「技术要新」；测试之所以值，是因为重构完没测试等于没重构；监控之所以值，是因为半夜挂了不能等客户早上打电话。说不出理由的重构就是消耗，不该排进迭代。
还有一段我要主动讲，因为它看起来是减分项，其实不是：我的文档栈和实测栈不一致。知识库里对这套技术栈的写法是「前端 React 19 + TS + Vite + shadcn/ui + Tailwind + tRPC，后端 Node + Drizzle + MySQL」；但实测是另一回事——我那套产线系统全盘零 MySQL，数据库全是 SQLite 家族，better-sqlite3 命中 26 个文件。
根因不是记错了，是我把「设计意图」和「实施现状」写进了同一栏：那行 MySQL 写的是「我打算用的栈」，我却当成「我在用的栈」在讲。我的纠正方式不是删掉文档那几个字，是做了一次代码盘点——扫依赖命中：express 85、react 85、vue 74、ffmpeg 67、better-sqlite3 26、sharp 24、drizzle-orm 7、zod 9。
这次盘点真正有价值的产出不是「证实没有 MySQL」，是发现 react 85 和 vue 74 同时存在——说明这是真的并行存在的两套前端工程，不是历史遗留的小撮文件。只改文档不改认知的话，我会一直不知道这件事，直到某个工具在两个栈里行为不一致才爆出来。
最后一条产品线是内容，不是系统：《会员制营销实战手册》19 章，理论层 28 万字 + 实战层 44 万字 = 72 万字（全口径：含站点与素材池；书稿本体实测 26.5 万字，见 33 篇）；还有一条 AlignHub Pro 七步共识工作坊。工作坊为什么是产品不是系统：它的七个步骤本质是有顺序的沟通流程，每步解决一个分歧、产出一份共识；系统在这里只做一件事——把共识记下来、可回溯。如果你把它做成软件，就会掉进把七个步骤硬做成七个模块的陷阱，那是把流程错当成了功能。我的做法是：产品 = 流程与交付物，系统 = 可选的记录载体，顺序不能反。
如果要挑一样当代表作，我挑的不是 83 个工具，是那份《会员口径说明书》。因为它的价值密度最高：工具能被人抄走，口径定义抄不走——定义来自真的跑过、真的对过账、真的被客户问倒过。