一、项目背景
最近接到一个线下服务业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 内部四大领域模块
即使部署在一起，代码边界必须清晰：
java
com.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代码生成：
plaintext
1. 涉及金额的变量禁用float/double，必须用BigDecimal。 2. 工资计算逻辑严禁写在Controller层。 3. 数据库状态变更必须使用乐观锁(@Version)。 4. 接口返回日期统一用"yyyy-MM-dd HH:mm:ss"格式字符串。 5. 不要未经确认引入外部依赖库。
七、工时估算
| 模式 | 开发周期（3人团队） | 最终形态 |
|---|---|---|
| 小做（MVP） | 1.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辅助开发、工资计算引擎、硬件对接
