酒店管理系统PMS产品系统Vibe Coding

一、立项原因
先讲行业现状：中小单体酒店、小型连锁处于 "半数字化" 状态，工具是拼凑的（老 PMS、Excel、3 个 OTA 后台、微信收款），数据是断的，规则靠人而非系统保证。
二、行业场景与业务背景
- **业态差异**：商务型、景区度假、公寓民宿、会议型四类经营特征与 PMS 重心对照
- **目标客群**：中小单体 + 3～20 家门店小型连锁（有真实分工但无专职 IT）
- **七个真实场景**：早高峰前台、夜班夜审、OTA 对账与留佣、协议挂账月结、会员储值、零售、寄存、遗留物品、早餐券、发票等 "碎业务"、交班与报表
**业务链条**：预订→预抵→入住→在住→预离→结账→转脏清洁→夜审→报表，以及渠道、协议、会员三条支线最终汇入同一套账务
**九条行业惯例**：营业日≠自然日、班次制、房态六态、订单状态机、12:00 与 24:00、预授权、红字冲账、留佣、分币必平，逐条对应系统落地方式
**角色协作表**、**使用环境约束**（1366 小屏、7×24、弱网幂等、3 年可追溯、合规留痕）
**痛点 — 场景 — 能力映射表**，把七个产品问题与系统能力一一对齐
结论落在一句话：中小酒店缺的不是 "能开单的软件"，而是把行业规则固化下来的经营根基。

一、功能模块总览
**15 个一级模块、约 60 个功能页面**，用一张总表列清每个模块的子功能和主要使用角色：
数据中心、房态（6 子页）、预订、入住、订单（15 状态页签）、零售（2 页签）、智能设备（5 子页）、夜审、会员（4 子页）、协议（2 子页）、仓库（7 子页）、报表（8 大类 55 个入口）、营销（5 子页）、设置（14 项业务设置 + 4 项系统管理）、消息通知
二、主要功能描述
逐模块写了 “能做什么 + 关键规则”，例如：
**实时房态**：检索维度、六态统计卡、房间卡片的 9 项操作、批量置房态、状态流转与日志留痕
**远期房态**：可售数计算式 `总数 − 预订 − 在住 − 维修 + 预离`、排序与列表样式切换
**入住**：多房间明细、每日房价与早餐份数、自定义渠道、提交自动分房
**收银与交班**：支付方式拆分、冲账 / 调账、交接表 7 个区块、金额分币必平
**夜审**：五步固定顺序、分布式锁、营业日 +1、失败可重试
**报表**：8 大类逐类列出报表名，说明打印与导出口径
会员、协议挂账额度、零售双页签、仓库进出存闭环、营销、设置、消息通知
三、角色对应 + 四、实现状态
按 7 类角色列出高频模块，方便培训与权限划分
**如实区分实现程度**：核心闭环与收银 12 张报表等 “已完整可用”；部分财务 / 协议 / 会员 / 客房报表为 “入口与版式已就绪、数据待接入”；竞品房价监控等明确不在本期范围

一、项目设想与设计
**起点**：以成熟商用 PMS 作为 “功能真源与 UI 基准”，说明三个理由（行业口径可信、降低试错、降低培训成本）和固定流程：取证 → 拆解 → 设计 → 实现 → 比对 → 修正
**五条设计原则**：规则先行、单一工作台、隔离写进架构设计、账务零误差、界面贴合行业习惯
**架构设想**：为什么选择**模块化单体而不是微服务**（强一致场景、并发量不到、事务边界清晰、边界已划好便于后期拆分），并给出 4 个 Maven 模块的职责与依赖方向
**分层设计**：五层依赖 + 手写 SQL 的取舍理由（报表聚合、房态展开、能精确控制口径）
**数据模型**：66 张表、公共五件套、金额与时间类型、hotelCode 隔离、Flyway 版本化、注释强制
**工程约束**：把规范做成机器门禁（AGENTS.md 28 条、规则注册表、四道 pre-commit）
二、技术栈
Spring Boot 3.3.5 / JDK 17 / Spring Security + jjwt 0.12.6 / PostgreSQL 17 / Redis 7 / Flyway / Vue 3.4 / Vite 5.3 / Vue Router 4.3 / Pinia 2.1 / Element Plus 2.7 /axios 1.7 / Docker Compose
三、架构实现
请求链路、统一返回与异常、鉴权（BCrypt + JWT + Redis 黑名单 + 5 次锁定）、前端目录职责与多标签页、部署四服务编排（含 `LANG=C.UTF-8` 防乱码）
四、规模数据
后端 187 个 Java 文件、24 个 Controller、66 张表、56 个迁移脚本、22 个测试类 138 个用例；前端 35 个页面、15 个一级菜单、55 个报表入口