update for syncing by Git pull & push

auto_sync_mark.json

@@ -1,4 +1,4 @@
 {
-  "modified_at" : "1773837226205",
+  "auto" : false,
-  "auto" : false
+  "modified_at" : "1774343046689"
 }

调研和需求/需求整理/需求整理（持续更新）.md

@@ -1,6 +1,6 @@
 ---
 title: 需求整理（持续更新）
-mdate: 2026-03-23 17:12:42
+mdate: 2026-03-24 17:02:46
 mdevice: lazy的MacBook Air
 doc_id: 204168cc4c3244b992d2f7e45ca44e15
 date: 2026-03-18 20:27
@@ -360,7 +360,124 @@ date: 2026-03-18 20:27
 >  长期做法可以通过引流转化，逐渐将【自我游】的用户导向永动的旅游 App
 
 ### 6.2 组合产品订单需求
-**现状**：
+**现状**：旅游产品的组合订单的兑现，需要在不同的系统和界面上进行操作。例如【迪斯尼+车票】组合，需要分别兑换迪斯尼门票和永东车票，在两套不同的系统中进行。
+
+**需求**：需要在一个界面上操作，或者在用户订单中直接选择生成，让用户能够在一个界面上清晰操作。
+
+**建议**：在对接【自我游】系统后，用户统一在【旅游App】上操作，【旅游 App】能够与永东订单挂接，并生成车票。
+
+### 6.3 新业务整合
+**现状**：现有的一些新业务，如旅游产品、包车业务、演唱会生态等，各自分散在不同的 Saas、系统、社交工具中进行，相对比较分散。
+- 以上几个业务相对割裂，业务较为专注，但没有对重叠用户进行有效转化，提供系列服务
+- 业务数据上没能实现统一，没法提供统一的用户体验
+
+**需求**：需要整合现有的多项业务，为某些【高端用户】提供一条龙服务。
+
+**建议**：为直巴、包车、旅游产品、演唱会等业务提供统一的入口，用户在同一个入口订购永东的多项业务。建议在【旅游 App】上实现整合。
+
+
+### 6.4 其他需求
+新业务的其他细致需求，将在新一轮的调研中进行汇总和整理。
+
+## 7. 服务优化需求
+### 7.1 乘车提醒
+**现状**：对用户的乘车提醒目前大多采用【短信息】和【邮件】方式进行提醒，均采用购票乘客预留的联系方式。乘客基于个人隐私问题，不一定留真实的个人信息。
+- 没有实名制购票。尤其在香港，购票没有实名制的操作，也没有电话验证，导致难以向乘客推送乘车信息。
+- 在末班车的情况下，对未检票的乘客，目前通过【站务-客服】的方式进行通知。
+- 没有针对乘客的行程（如乘车时间、地点、车辆到站情况）进行提前通知。
+- 大型活动下情况下，没办法提前通知乘客尽快进行车票截图，以免信号拥堵。
+
+**需求**：需要解决乘客乘车通知问题，降低短信息资费和减少人工客服通知的操作。
+
+**建议**：在系统中建立相关的工具和手段进行优化。
+- 新系统构建【信息服务】，通过平台消息服务，默认向【订单乘客】推送订单班车信息，并减少使用短信息的频次。
+- 向用户推广【旅游 App】，【旅游 App】向后台系统进行订阅行程信息，实现推送。
+- 乘车指引或者活动指引可以通过【旅游 App】提供更好的体验。
+
+### 7.2 服务评分
+**现状**：目前系统中缺少与乘客互动部分，例如基础的服务评分。
+**需求**：乘客结束行程，可对本次服务进行评分，帮助改进服务。
+**建议**：服务评分应该以订单为准，并以完成订单（即行程结束后）才能提供。
+- 在乘客端的 App 中集成评分操作。
+- 配合订单、下车时间和地理围栏进行判断能否评分。
+- 需要加入常见的评分选项，以减少乘客输入的操作。
+
+## 8. 代理商管理需求
+### 8.1 代理商分级管理
+**现状**：某些代理商会发展自己的子代理，目前系统没有子代理的选项。
+**需求**：分主代理及子代理商，能够独立设定佣金率
+**建议**：新系统中优化代理商的操作
+- 主代理商账号由永东进行创建，并赋予主代理商权限。
+- 主代理商自行创建子代理商，并由系统默认赋子代理权限。
+
+## 8.2 网络代理商对接需求
+**现状**：网络代理商如携程、同程之类，对接永东系统之后，每次用户查询都会给系统带来巨大的压力，甚至导致系统奔溃。
+> 网络代理商的体量比较大，用户的每一次查询都会在永东服务器上查询一次（不管用户是否选择永东的班次），造成服务压力大。曾经出现过因为网络代理商查票大量查票，导致服务器崩溃。 虽然后期对架构进行了调整，将对接的 API 单独出来部署在微服务上，并将微服务的带宽将至 2M，实际上是限制了网络代理商的查票，并非真实解决问题。
+
+**需求**：对接网络代理商的同时，需要考虑并发的问题，不能影响后台系统的正常运行。
+**建议**：在系统部署架构上做优化。
+- 使用 Go 语言进行 API 的重构，以适应更大的并发量。
+- 通过微服务和分布式部署，将并发压力分散。
+- 使用同步推送+缓存方式，降低对后台服务器、后台数据库的直接影响。
+- 优化查询能力，从站点、线路、班次、计价等多个方面优化查询，降低压力。
+
+### 8.3 其他需求
+代理商的其他需求，将在【财务调研】的过程中进行细致讨论。
+
+## 9. 信息系统需求
+### 9.1 系统权限设置
+**现状**：目前系统的权限只能针对【用户】级别，即每个用户需要单独设置权限，没有采用【角色】、【部门】等方式进行统一管理。对用户操作权限均到【模块】级别（目前加入了【子模块】来控制），权限难以控制，并且容易出错，后期维护也相对困难。
+>  目前在权限的设定方面，只能通过修改系统的模块，将原有【模块】加入【子模块】来区分。
+
+**需求**：以下是隐式需求，
+- 系统通过用户角色的方式来指定用户的权限，能够规范人群的使用权限和简化配置。
+- 从【后台系统】到【前端应用】，均通过能进行权限控制。
+- 从系统管理员角度，只需要管理【用户】和【角色】这重关系。
+
+**建议**：从根本上改变系统权限的逻辑，从【模块】级别变为【接口】级别。
+- 权限的细致粒度到 API 级，每个 API 均在系统后台进行登记和命名。
+- API 定义为【功能】，多个【功能】构成【功能包】，一个【角色】可以同时赋予多个【功能包】，一个【用户】可以具有多个【角色】身份。
+- 从系统管理员角度，只需要管理【用户】和【角色】这重关系。
+- 从业务角度看，只需要关注【业务】和【角色】这重关系。
+
+### 9.2 消息推送服务
+**现状**：面向乘客服务，主要使用运营商的短信息进行通知推送；内部协同方面，主要使用社交软件和邮件进行协作。短信息服务比较耗费用，邮件推送实时率不高，社交软件不适合信息流转。
+
+**需求**：降低信息资费消耗，提高信息实时效率。
+
+**建议**：能够建立永东的消息服务系统，减少对运营商短信息和社交软件的依赖，实现高效规范管理。
+- 消息服务系统会在项目中进行搭建，部署在后台服务器，走互联网流量，使用 MQTT 协议。
+- 配合系统业务和对外服务，建立统一的【消息订阅】机制，来辅助信息流转和推送。前面内容【4.1 站务协同】和【7.1 乘车提醒】提及到。
+- 需要用户端软件支持，内部信息流转使用【协同 App】进行，对外服务使用【旅游 App】进行。
+>  消息推送服务的难点在于需要对【应用端】软件支持。
+
+### 9.3 查询和统计需求
+**现状**：现有系统查询和统计性能偏低，主要表现在以下几方面：
+- 站务需要刷新【站点班次】信息，页面刷新较慢。
+- 客服对用户订单进行查询，整体速度较慢。
+- 运营报表统计，需要非常长的时间，并容易导致系统崩溃。
+
+**需求**：需要提升查询和统计的效率
+
+**建议**：新系统将在数据表设计、前端页面、后台工具等方面进行优化。
+- 数据库设计优化。合理分表和建立数据索引，减少跨表查询和提升检索效率。
+- 建立归档制度。如订单、检票记录等只保留最近3个月数据，定期迁移到备份数据库。能有效提升查询和检索效率。
+- 自动统计归口。针对常用的统计方式，定期如天/周/月/季/年等，进行统计，保留统计记录，下次统计只做统计结果的合并。
+
+### 9.4 后台用户操作记录需求
+**现状**：主要表现在后台权限和操作记录缺失等问题：
+- 责权不清晰。现有系统大量的后台操作均没有审批功能，直接由负责该项业务的人员直接操作，或由系统管理员进行直接操作。
+- 责任跟踪困难。系统且缺乏关键操作的日志，出现问题后难以追溯根源。
+
+**需求**：隐式需求：
+- 由【业务】决定【权限】，由用户的【角色】决定功能操作。
+- 系统重要的操作可追溯。
+
+**建议**：加入审批和关键操作日志
+- 审批功能。按照实际的业务流程进行提交和审批（可能会导致运营效率降低，但相对可靠，需根据实际运营进行考虑）
+- 关键日志记录。例如修改权限、修改线路、班次、加班、票价等这些关键操作，记录操作用户、时间、IP 等关键日志信息，用于追溯。
+- 明确权限。需要明确每一个用户的【角色】权限，在源头解决问题。
+