一、项目背景最近接到一个线下服务业SaaS系统的开发需求为推拿、头疗、采耳等门店开发一套完整的ERP管理系统。系统需要覆盖微信小程序端用户端、安卓App端技师端客户端、Web管理后台店长端总部端以及核心的中台账目管理。团队配置两个大学生 AI辅助开发。我在之前的项目中做过9个微服务的架构这次决定用“一个后端多个前端”的单体架构来简化部署同时内部保持清晰的模块边界。这篇文章不是教你写代码而是完整记录需求分析阶段遇到的坑、思考过程和技术决策。希望能给做类似项目的同学一些参考。二、需求全景图2.1 角色与模块矩阵角色/模块核心需求① 用户端注册、活动提醒、生日/节日问候、技师选择含技师介绍、好评展示、服务时长、服务客户人数等② 店长端上钟记录、排班管理、店铺的房间管理③ 技师端上钟提醒、入职表管理、实时量化工资组成提成工资、已发工资和待发工资显示④ 中台账目、经营管理⑤ 其他扫码核销、连接店铺房间硬件计时器上钟/下钟提醒数据同步到后台2.2 多端架构概览微信小程序面向C端用户预约、选择技师、下单。安卓App客户端功能同小程序但通过App推送触达用户。安卓App技师端接单、上钟/下钟操作、查看工资。Web ERP电脑端店长管理和总部管理界面数据报表、排班、房间管理。三、需求对齐中的模糊地带最容易扯皮的点在写第一行代码之前如果不把以下问题对齐项目必然会延期或扯皮。3.1 硬件计时器到底是什么需求里写的“连接店铺房间硬件计时器”这五个字是整个项目最大的黑盒。是Wi-Fi智能插座是蓝牙网关设备还是房间内摆放的一台安卓平板运行倒计时对齐结论如果硬件选型未确定第一版只做虚拟计时按钮技师手机端点击开始/结束硬件对接作为二期功能。否则开发会陷入无底洞。3.2 “实时量化工资”的算法陷阱“实时量化工资”听起来简单实际极其复杂。几个致命问题提成是按项目金额的比例还是固定金额点钟、轮钟、加钟的提成算法是否不同不同职级技师提成比例是否不同如果订单发生退款已算好的提成怎么扣回技师已经离职了怎么办对齐结论要求甲方提供明确的书面提成规则公式否则工资模块无法开发。开发时将提成规则设计为策略模式方便后续调整。3.3 中台 vs 店长端 vs 总部端的边界这是最容易被混淆的概念。端给谁看关注什么店长端店长/前台今天多少流水、技师忙不忙、房间脏不脏中台财务/老板娘钱对不对、成本准不准、负债多少总部端老板/运营各店营收达成率、哪个店长不行举例顾客充值1000元店长端看到“收了1000块业绩真好”。中台必须冷酷地记负债1000元欠顾客的直到顾客消费了800块中台才确认800元是真实收入。四、技术难点分析4.1 硬件层交互的实时性与可靠性Web ERP是基于浏览器的无法直接通过串口或蓝牙连接物理硬件。需要一个中间件客户端可以是技师端App充当网关来轮询硬件状态并推送到云端。坑点网络抖动导致状态不一致——硬件显示“上钟”系统显示“空闲”。方案引入本地消息表 最大努力通知 人工干预后台。不要试图用分布式事务强一致硬件状态。4.2 工资计算的强一致性技师随时查看“待发工资”如果某笔订单发生退款/改价必须触发工资的冲正重算。关键设计使用计算字段快照。订单完成时直接把当时的提成金额存一份到工资流水表不要每次查工资都关联订单表重新算否则订单改价后历史工资会变技师会投诉。4.3 多端的实时消息同步技师端App必须实时收到上钟提醒不能依赖手动刷新。方案部署WebSocket长连接服务。在小体量下可以内嵌在后端服务中不需要独立集群。4.4 中台账目的逆向流程退款时账目不能直接删除或修改原记录。必须遵循财务原则只增不改红字冲销。五、架构决策为什么选“一个后端多个前端”我之前做过9个微服务的项目这次选择单体应用 内部模块拆分。5.1 架构对比维度单体模块拆分完整微服务开发速度极快改一个接口四个端全生效极慢调一个流程改3个服务硬件成本低一台2核4G搞定高至少3-5台服务器工资计算风险低代码只在一处高A服务算提成B服务退款数据不同步单点故障有风险挂了全挂部分可用结论对这个项目规模和团队配置单体是更务实的选择。5.2 内部四大领域模块即使部署在一起代码边界必须清晰javacom.headspa ├── billing // 计费与工资 - 最复杂变最频繁 ├── scheduling // 排班与房间 - 状态机复杂 ├── shopfloor // 硬件与工位 - IOT隔离层 └── identity // 多端鉴权 - 权限隔离六、AI辅助开发策略不是“一把梭”而是“审查式生成”我们团队是两个大学生AI但我和同伴在开发方法上有分歧他想快速用AI生成功能我坚持用软件工程方法逐步推进。6.1 我的真实做法AI是审查员不是主程核心原则人定架构AI当审查人写接口定义AI生成方法实现人写数据库设计AI挑刺找漏洞6.2 四轮AI审查机制第一轮架构审查开工前把需求文档喂给AI让它以资深架构师身份审查哪个模块最容易出现并发数据错误工资硬件状态同步推拿行业有什么特殊业务坑技师并牌服务、跨天工资归属期第二轮数据库设计审查建表前把ER图给AI审查统计“上月所有点钟提成”时能否高性能跑出来跨天订单的工资归属期用哪个字段标识技师离职后历史提成数据是否会丢失第三轮接口定义审查写代码前先生成Swagger/OpenAPI的YAML作为多端开发的宪法。安卓、小程序、Web都严格遵循这份契约。第四轮AI规则文件防坑指南项目中放置.cursorrules文件约束AI代码生成plaintext1. 涉及金额的变量禁用float/double必须用BigDecimal。 2. 工资计算逻辑严禁写在Controller层。 3. 数据库状态变更必须使用乐观锁(Version)。 4. 接口返回日期统一用yyyy-MM-dd HH:mm:ss格式字符串。 5. 不要未经确认引入外部依赖库。七、工时估算模式开发周期3人团队最终形态小做MVP1.5-2个月能用手机代替纸质笔记本无硬件联动工资固定比例大做SaaS标准版3.5-4.5个月成熟门店数字化系统带物联网中控动态工资规则引擎两个大学生AI的实际预估1.2-1.5个月完成MVP关键瓶颈在业务规则的梳理而非代码编写。八、给同行的三点建议8.1 需求阶段花50%的时间这个项目最大的成本不是写代码是把老板自己都说不清的分钱规则翻译成可执行的代码逻辑。需求阶段多花一天开发阶段少花一周。8.2 硬件对接是最大无底洞第一版坚决不做硬件对接。用手机上的软计时技师点击开始/结束跑通流程再考虑对接智能开关的开放API。8.3 AI的正确用法是“审查”而不是“生成”用AI省下来的时间不是去打游戏而是花在设计模式和数据库规范上。这样下周老板改需求的时候你还能打游戏。九、写在最后这个项目对我来说技术栈上没有太多新东西从9个微服务降维到1个后端但业务复杂度远超预期。推拿头疗这种线下服务业的很多场景是互联网出身的产品经理完全想不到的。如果你也在做类似的线下服务业数字化项目欢迎留言交流。特别想知道大家对技师并牌服务的工资拆分有没有好的方案——这是我目前遇到的最头疼的问题之一。本文完整记录了项目从需求对接到技术方案的全部思考过程包括那些“差点没想清楚”的瞬间。希望对正在做毕设、接外包、或者创业的同学有所启发。关键词推拿店ERP、SaaS系统、需求分析、多端架构、AI辅助开发、工资计算引擎、硬件对接