PAIN 01
迭代上线 · 有点慢
后端更新受限，bugfix 排队。用户等、伙伴催、合作方看节奏 —— 最终影响业务产出。
从零搭起一个能打的技术产品部 —— 修好上线节奏、接住涌来的需求、一路建起这套「练二操作系统」。一份人人都能读的说明。
时间拨回 2026 年 4 月。那会儿，有三件事一直别扭着 —— 先把问题摊开讲。
迭代慢、人员飘、品质虚 —— 现状是这样的，得直说。
后端更新受限，bugfix 排队。用户等、伙伴催、合作方看节奏 —— 最终影响业务产出。
人力投入不稳定，对接效率靠缘分。主因可能在钱上 —— 这事儿得摊开聊。
线上产品还没统一 VI，用户看到的「精致感」有点散。已立项，专人 hold 住。
几乎同一时间，需求从四面八方涌进来 —— 老板、运营、店长、财务、市场，每个人都有急着要的东西。挑几条原汁原味的摆出来：
需求从四面八方涌进来 —— 但人手就这些。怎么接得住？看下一章。
需求这么多、人手就这些 —— 怎么办？答案是换打法：在 AI 时代，用有限的生产力去接住喷涌的需求，并且顺手把系统重做成下一代架构。下面六条原则，就是这套打法的总纲。
不按端口分，按 业务领域 走。
一条线吃透了，再下一条。
不按用户操作端口拆分需求（C 端 / B 端 / 后台），把同一业务领域里的细碎需求整体化考虑、一次性做好。
每条业务线开了就吃透：底层数据、管理后台、用户端三层一并理顺，避免「打地基打到一半搁置」。
把 AI 真正嵌进日常工作 —— 想需求、写代码、跑测试、做协同都借力 AI，重塑工作节奏，让效率不再是瓶颈。
同一份能力（结算、权益、订单）建一次就用全场，避免不同端口各自造一遍轮子 —— 该复用就复用。
不囤大版本上线 —— 小批量、勤滚动，让发布从「事件」变「日常」。测试是底线，回归覆盖到位才能放心走。
用户感受最深的，往往是那些「卡了一下」「点错了」「找不到」—— 这类关键小优化的响应速度，要优于半年大项目的进度。
从 4 月到现在，已经往前走了一大段。三件事落了地：
重配服务器、搭起流水线、做到滚动发布 —— 现在能稳定、快速、可回滚地发版，功能持续在上。这是后面一切的前提。
上半年第一场硬仗打完，平台扛住了 —— 团队真刀真枪验证过一次。
整个"练二操作系统"最终该长什么样，已经想明白、画出来了。下一章就讲它。
抛开技术名词，一句话：一个中枢大脑 + 几个端 + 门店里的智能硬件。各端各看各的，但钱和账都从同一个大脑里出。
这是练二目前所有的系统（代码库），以及它们之间怎么协同 —— 哪个端连哪个、数据往哪儿流。看不懂技术标签没关系，看"有哪些方块"和"方块之间的线"就够了：左边是各种"端"，中间是后端大脑和数据库，右边是门店的智能系统，最底下是大家都依赖的基础平台。线的颜色代表怎么连（HTTP 调用 / 消息 / 共享数据 / 规划中），想深究的看下面的连接清单。
上图中间那个「后端核心」，其实不是一坨代码 —— 它是 5 个独立的服务（外加一个公共库），每个只管一个领域、各被不同的地方调用。统一从网关进来，谁要用就调谁的。
登录、会员、个人信息 —— 回答"你是谁、有没有权限"。
支付、订单、退款、课时费结算 —— 钱的事全在这儿，也是最复杂的一块。
教练管理、课程、排课、资质。
后台管理、数据统计、各类配置。
门禁网关，对接人脸识别 —— 管"刷脸开不开门"。
工具、常量、安全防护 —— 给上面几个服务复用，不直接对外。
把每条线落到具体接口/数据/主题。五个连接点，就是整套系统的「关节」。
所有前端的统一业务入口，经 ShenYu 网关 → Dubbo 微服务。
后端独占读写；但有两条新链路反向读它 —— 是跨系统耦合点。
「这是谁」的统一回答方，三个调用方各取所需。
门店 leaf 单向连云 hub，边缘设备与云端看板全靠它。
跨切面的登录 / 承载 / 通知通道，四个工程依赖它。
基本不接主链路、各自带库的工程。
把涌进来的需求，归成六条业务线、排进六个月。横轴是月份，纵轴是业务线 —— 一张图看清节奏，下面每条一句话带过。
横向是月份，纵向是业务领域。 ◆ 标记的是节点型大促（618 · 8.8 · 双 11），其他是连续推进的项目。
把订单、退款、结算这条"钱"的链路一次理顺，再做面向合伙人的结算单。数据准了，后面什么都顺。
官网先立起来，视觉规范跟着沉淀 —— 合作方搜得到、看得上。
会员卡、私教权益统一重做，约课签到顺一遍，再加积分大会员把人留住。
先搭能自己配活动的平台，再打 618 · 8.8 · 双 11 三个大促节点。
教练、店长搬进企业微信一站协同，门店再上刷脸门禁、客流、看板这些智能硬件。
员工的运营门户 + 数据大屏，再加实体商品的进销存 ERP。
要把这套操作系统真正落地，最后一个问题是人怎么组织。运营想赚钱、产品想好用、技术想稳 —— 都对，所以坐一起。
给工程师看的深水区
以下是更深的工程细节 —— 分层、各工程清单、演进取舍。非技术的同学可以放心跳过。
铺开目标系统之前，先说清为什么这么走。练二的系统横跨两代技术栈 —— 这不是包袱，是有意的演进：老核心（Java 单体）稳住现金流、不轻易动；新能力用更轻的方式在边缘和新端上快速长出来。理解了这套演进逻辑，才看得懂下面这台「操作系统」为什么长这样。
承载支付、会员、结算 —— 错不起的部分
工具、新端、边缘 AI —— 试得起、长得快
用户从最上层敲门，请求一路向下穿过网关、微服务、落到数据库；同时还有一条「门店边缘 ↔ 云端」的横向消息链路（NATS）单独跑视觉、人脸、门禁。颜色规则：橙=存量核心 / 主链路，青=新生代独立服务，墨=数据与边缘。
每张卡片：它是什么、用什么技术、建设完整度（基于代码体量、功能闭环、TODO 密度、提交活跃度的工程估算，非精确进度）。进度条只反映「工程实现完整度」，不代表业务价值或优先级 —— 它正好把"现状"和"在建图景"画在了同一张表上：90%+ 的多是跑了一年多的存量，20–60% 的就是这半年正在长出来的东西。
跑了一年多的老底子 —— 重、稳、深度集成，是现金流的承载者。
练二一切业务的中枢：会员、支付、教练、门禁、后台。5 个 Dubbo 微服务 + ShenYu 网关。
总部运营的指挥台：商品、订单、结算规则、会员、营销、教练等级，14 个一级菜单。
C 端门面：约课、买卡、签到、商城、退款全流程。微信小程序为主，多端预留。
教练自助：排课、签到码、学员管理、课时费/提成明细、远程开锁。
老店长端，34 页 18 模块。功能完整但已冻结 —— 即将被企微店长端 + BOSS 端拆分替代。
2026 年新长出来的 —— 各自带库、独立部署、不背老包袱，用 Bun / Python / SvelteKit。
员工运营中台 + 数据大屏 + 实验田：结算核对、知识库、刷脸测试、企微集成。
自建 1:N 人脸识别：回答「这是谁」→ 会员 ID。到店抓拍识别、批量建库。约 4.7 万会员库。
云端实时看板：在场人数、客流热力、进门抓拍、到店会员、设备状态。订阅门店 NATS 消息流。
总部 ↔ 36 门店的实体商品调拨、库存、订货、盘点。完全独立于主后端。
对外门面：品牌故事、加盟申请、城市门店地图。纯静态站 + 表单提交。
把老店管家拆成「店长看过程 / 合伙人看利润」两端 —— Taro + React 同栈，骨架阶段。
从「练小二」迁移的门店管家，只给店长用、企微登录。看业绩过程：GMV/会员增长/到课率。
给门店出资合伙人（纯财务投资人）：分红概览、回本进度、结算单、课时费拆分、AI 巡店。
天波 TPS980 门禁机上的 Android App：刷脸/扫码开门。采集 + 活体，识别交给门店本地服务。
部署在门店机房的本地算力 —— 摄像头、GPU、门禁，靠 NATS 单向连云。
门店本地 GPU 机：多路摄像头 YOLO 推理，人流计数、进门抓拍、客流热力、姿态识别。
门店智能化这条线不走 HTTP 主链路，而是靠 NATS 消息总线：门店里的 leaf 节点单向连到云端 hub（门店不需要公网入站，安全）。视觉分析在门店本地 GPU 跑，识别在云端跑，看板在云端展示 —— 各司其职。
收束一下：把半年路线的六条线和这套操作系统的工程实况对账 —— 每条业务线背后，是哪些代码仓库在支撑、建到了几分。路线与工程对上号，这台「练二操作系统」的蓝图就闭环了。