珠海旅游项目后台系统初步设想
5/25/2025
这次的客户需求比较多，需要谨慎安排一下。
TL;DR
- 完成首轮需求访谈，明确「度假区后台」核心四大模块
- 采用 Astro + SolidStart 作为管理端前端线路，后端先行打样 tRPC + PostgreSQL
- 风险点：硬件打卡、票务系统对接、离线场景
- 下一步：三周内完成 概念验证 (PoC)，并输出详细里程碑
1 客户背景与第一次访谈
地点：珠海·客户办公区
参会：客户 COO、IT 经理，景杉零 2 名工程师 + 1 名产品
- 客户在珠海凤凰山投资建设一座混合型度假区：酒店、主题商业街、演艺剧场、亲子乐园。
- 目前已有 门禁闸机、票务、会员 CRM 三套独立系统，数据孤岛严重：
- 手工导表 → 延迟≥24 h
- 会员积分与消费记录无法实时同步
- 新需求：“一站式运营后台”，需要做到三端打通：
- 运营人员 (Desktop Web)
- 景区值班人员 (iPad Web App)
- 高层 (移动看板)
COO 原话：
“我要打开后台就能看到今天的票卖了多少、哪个演艺场次快爆满、哪家餐厅快没位置。”
2 功能分区 v0.1
| 模块 | 子功能 | 关键接口依赖 |
|---|---|---|
| 票务/闸机 | 票种管理、二维码核销、入园流量监控 | PAX 闸机 API、第三方 OTA |
| 会员中心 | 储值/积分、优惠券、黑名单 | 现有 CRM REST |
| 现场运营 | 演艺排班、应急广播、缺货补货通知 | 设备 MQTT、仓储系统 |
| 管理看板 | 实时营收、客流热力图、异常告警 | 以上全部数据汇总 |
初步技术选型
| 层级 | 方案 | 说明 |
|---|---|---|
| 前端 | Astro + SolidStart (Island) | 管理端 SPA 体验 + SSR SEO |
| BFF | tRPC | 无需写 Swagger，前后端共享类型 |
| Data | PostgreSQL (Supabase) | 事务 + 行级安全，先云后自管 |
| 实时 | Cloudflare D1 / R2 | 低门槛 PoC，后续迁移 Edge DB |
| DevOps | GitHub Actions + Cloudflare Pages / Workers | 同客户现有 GitHub 流程对齐 |
3 关键挑战
| 风险点 | 现状 | 潜在方案 |
|---|---|---|
| 票务 OTA 对接 | OTA 仅提供每日 CSV | 建立 S3 桥接器，10 min 轮询 |
| 闸机网络不稳 | 离线 > 5 min / 天 | 设计「离线票据」临时缓存 |
| 值班 iPad | Safari、私有网络 | PWA + 局域网 WS 推送 |
4 三周 PoC 计划
- 第 1 周：完成 ER 模型与最小数据管道（票务 & 会员）。
- 第 2 周：tRPC 后端 + Solid 前端 Demo，跑通「售票 → 核销」闭环。
- 第 3 周：部署演示环境 & 初步性能压力测试（50 并发）。
交付物：
- 系统原型演示 URL
- Swaggerless API 文档 (由 tRPC schema 自动生成)
- 风险与资源评估报告 v0.2
5 今日小结
- 客户意愿高，但期望值也高，需要明确 MVP 边界。
- 技术栈保持 “先轻后重”：PoC 阶段 Cloudflare 边缘可满足需求。
- 下次会议：2025-06-03，演示 ER 图与第一版 UI 线框。
接下来几篇 Devlog 预告
| Devlog # | 预计日期 | 主题 |
|---|---|---|
| 2 | 2025-06-03 | 数据建模：票务 & 会员 ER 设计细节 |
| 3 | 2025-06-10 | 前端技术选型 & Solid 组件拆分 |
| 4 | 2025-06-17 | tRPC +Bun 自托管 vs Cloudflare Workers 对比 |
| 5 | 2025-06-24 | PoC 性能测试 & 离线方案验证 |
| 6 | 2025-07-01 | MVP 范围冻结 & 里程碑复盘 |
Stay tuned 🚀