diff --git a/.metion/folder_sort.config b/.metion/folder_sort.config
index caba2f5..007531c 100644
--- a/.metion/folder_sort.config
+++ b/.metion/folder_sort.config
@@ -1,3 +1,4 @@
 [
-  "项目开发"
+  "项目开发",
+  "调研和需求"
 ]
\ No newline at end of file
diff --git a/auto_sync_mark.json b/auto_sync_mark.json
index 532744a..a67b909 100644
--- a/auto_sync_mark.json
+++ b/auto_sync_mark.json
@@ -1,4 +1,4 @@
 {
-  "auto" : false,
-  "modified_at" : "1773818708622"
+  "modified_at" : "1773837226205",
+  "auto" : false
 }
\ No newline at end of file
diff --git a/index.cjson b/index.cjson
new file mode 100644
index 0000000..a09ff36
--- /dev/null
+++ b/index.cjson
@@ -0,0 +1,6 @@
+{
+  "is_git" : "yes",
+  "modified_at_date" : "2026-03-18 17:17:38",
+  "modified_by_device" : "lazy的MacBook Air",
+  "modified_at" : "1773825458910"
+}
\ No newline at end of file
diff --git a/调研和需求/.metion/folder_sort.config b/调研和需求/.metion/folder_sort.config
new file mode 100644
index 0000000..b5bbb38
--- /dev/null
+++ b/调研和需求/.metion/folder_sort.config
@@ -0,0 +1,4 @@
+[
+  "调研",
+  "需求整理"
+]
\ No newline at end of file
diff --git a/调研和需求/调研/站务调研 2026-03-16.md b/调研和需求/调研/站务调研 2026-03-16.md
new file mode 100644
index 0000000..b907bfd
--- /dev/null
+++ b/调研和需求/调研/站务调研 2026-03-16.md	
@@ -0,0 +1,74 @@
+---
+title: 站务调研 2026-03-16
+mdate: 2026-03-18 20:26:11
+mdevice: iPad
+doc_id: 2830121c024d4576bfcc53e09c6d2746
+date: 2026-03-18 20:25
+---
+
+# 站务调研
+>  时间：2026 年 3 月 16 日
+> 地点：油麻地站--> 葵芳站--> 深圳湾口岸 A 区--> 深圳湾口岸 B 区
+> 调研人员：马卫东、李远祥、黄荣超、何高棋、冯汉栩
+> 甲方人员：TT、慧姐（站务负责人）、Henry（电脑部负责人）、Vivien（车务部负责人）
+> 其他说明：财务部分先由 Henry 整理一些表格和需求，后续再约时间调研
+
+##  1. 调查内容
+- 站务日常工作，如咨询、购票、支付、检票、统计、加班、埋数等流程
+- 站场的情况，如始发站、中转站、口岸站点的现场
+- 现场工作人员的业务开展及状态
+
+## 2. 业务分项内容
+### 2.1 现场购票
+- 现场手段：自助机、前台购票，或自助机查询再由前台购票。直接打印纸质车票。
+- 口岸站点没有自助机购票（场地、电力供应等问题）
+- 现场购票的多为老年人。
+
+### 2.2 支付手段
+- 现场购票的主要支付方式为八达通，使用率较多。
+- 现场补票，如葵芳站，由于前台设置在二楼，站务人员一般在一楼帮忙购票，主要使用 TVM 机。
+>  TVM 机最大的问题是只够购票和部分支付（如中银的微信和支付宝），其他支付必须采用八达通和银行 post 机。所以站务一线人员一般会带四个装备，手机（通讯兼顾检票）、TVM、八达通机、银行 post 机。
+> 口岸由于缺电少网，一般也是 TVM 完成，没有自助机和电脑端购票。
+
+### 2.3 检票上车
+- 手机 App 检票，需要提前配置检票的班次，需要选择始发站、终点站、选择线路、加载全天班次，操作有点啰嗦
+- 人少时一般上车后扫票，人多时在车门处扫票。
+- 在香港段，不提供选座，上车随便坐
+
+### 2.4 统计
+- 由站务人员统计车辆在该站点的上车人数，通过微信群发送给下一站（车辆出站即发至下一站）。
+- 首发站需要统计每一班车各站点的上车人数（日常操作）
+
+### 2.5 调度
+- 每天会收到有车务部根据班次制作的 Order 纸，Order 纸主要是为各班次匹配对应的司机和车辆，指派司机到哪条线哪个站进行拉客。
+- 站务人员会裁剪出属于自己门店站点的班次、车辆、司机信息。
+- 调度基本上由人工进行，每一班车上完客开出，由该站务人员将统计信息、车辆开出时间一并发送给下一个站点
+
+### 2.6 埋数
+- 对每天的售票情况进行记录，包括购票、金额、支付方式等（需要对应的埋数表格）
+
+## 3. 存在问题
+### 3.1 调度缺失
+- 车务的 Order 表开始使用 Excel 并采用聊天软件进行分发，没有与系统的班次进行绑定
+- 每一个站点都必须手工统计数据，并才纸质记录。需要同时刷新班次乘车信息和记录站点上车人数
+- 车辆发出后需要将发车时间和站点上车人数通过群信息方式流转至下一站点
+- 车辆缺乏跟踪，站务人员不清楚车辆到达什么地点，部分站点有进站的时间要求（如葵芳），需要提前做安排
+- 末班车问题，需要统计最后还剩多少乘客，是否已经全部完成检票（有的乘客因为通关被拦截，有的可能通关时间太晚，需要暂时等待）。末班车需要利用数据做好兜底工作。
+
+### 3.2 检票问题
+- 检票不通过也允许上车，存在大量的扫票异常。
+> 异常情况其实可以通过判断当前检票班次和票上的班次信息进行校验的，但检票人员为了省事（原因不明），允许异常情况上车。
+- 检票 App 的初始化比较麻烦，操作步骤较多，检票人员容易选错当前需要检票的班次。
+- 大型活动如演唱会散场，目前无法进行有效检票。（不检票直接上车）
+
+### 3.3 支付问题
+- 支付终端的支持。TVM 作为补票的手段，能够现场帮助乘客买票，但有限的支付方式，基本上只能作为出票手段（打印车票），港人常用的八达通和信用卡，需要另外的两个设置支持。
+- 支付统计存在问题。TVM 只能设置为现金支付，出票结束后，站务还需要根据支付方式重新埋数，增加了站务人员的工作量。
+
+### 3.4 站场问题
+- 部份门店/站场没有地方放置自动售票机，如葵芳、口岸等地。
+- 口岸站点缺电少网，且场地不足，购票、检票、统计等环节需要联网。目前主要靠站场人员通过移动电源、移动热点等方式进行解决。
+
+### 3.5 加班车问题
+- 在自助机上可以看到加班车，但没有明显的标识，只有相同的时间。乘客无法知道自己购买的是正常班次还是加班班次。
+- 口岸站点可能同时停放两辆或以上的加班车，现场无法识别，扫票后直接上车。
\ No newline at end of file
diff --git a/调研和需求/调研/运营调研 2026-03-04.md b/调研和需求/调研/运营调研 2026-03-04.md
new file mode 100644
index 0000000..6400c8b
--- /dev/null
+++ b/调研和需求/调研/运营调研 2026-03-04.md	
@@ -0,0 +1,80 @@
+---
+title: 运营调研 2026-03-04
+mdate: 2026-03-18 20:24:34
+mdevice: iPad
+doc_id: cb7639c436284d03aa5c1aeaadd0bb81
+date: 2026-03-18 20:23
+---
+
+# 运营调研
+
+> 时间日期：2026年3月4日
+> 地点：福田区永东办公室
+> 调研人员：【空天】马卫东、李远祥、张钦贵、何高棋、冯汉栩
+> 甲方人员：【永东】Paul、票务部、销售部、客服部、电脑部相关人员
+> 调研方式：会议讨论+原系统演示方式
+
+## 1. 调研内容
+业务范围：售票、排班（加班）、检票、客服（退票、停运）等方面
+> 本次调研尚未涉及财务、车务两个核心部门
+### 1.1 主要流程
+目前永东几个核心业务的流程
+#### 1.1.1 常规班车业务流程
+**基本业务流程：** 排班—> 售票—> 派车—>检票—>运输
+- 排班：提前一个月排班。班次会设定时间、线路、上下车站、可售票数和票价。
+- 售票：排班完成后即可售票（即乘客提前一个月可购买车票）。票种多样（如成人、老人、儿童、婴儿、行李票），对应不同的价格。可叠加优惠券（通过抖音获得）进行购买。售票方式多样，小程序、服务号、自助机、现场 TVM 机、PC 端等。
+- 派车：由车务部根据售票的情况进行派车。一般是发车前一天指定车辆和司机。（需要跟车务部确认）
+- 检票：由现场站务人员进行检票上车。跨境线路会有两段检票（在后端会记录检票的状态）
+- 运输：根据班次指定的线路进行，有固定的上下站点，上下站点有可能动态调整，例如施工封路、临时管制等。
+
+#### 1.1.2 加班车流程
+加班名词解释：当某一个班次余票到达一个阈值，需要对该时段临时增开班次。加班需要站务、票务、车务同时配合。
+**基本业务流程**：余票监测—>站点票数统计—>发起加班—>增加班次—>启动售票—>调度车辆
+- 余票监测：一般由线路始发站的站务人员进行监测（不断刷新后台售票系统），余票低于10张，可触发加班机制。
+- 站点票数统计：始发站站务人员统计各站点的上车（购票）人数，来确定加班车从哪个站点首发（加班车不一定由原来的班次的始发站发出，由售票最多的站点开始发车）
+- 发起加班：站务人员根据监测和统计结果，向后台（没有明确哪个部门）请求加班。（目前是向电脑部文仔发起，因为需要即时排班，暂时没有了解到是否需要审批）
+- 增加班次：排班人员根据反馈情况进行加班，加班涉及到始发站点、可售票站点、上下站点的设置。加班号一般为同时段班次名称后加英文字符，例如班次号+b
+- 启动售票：车务部确认是否能派车后，发布班次，指定可售票数和票价（票价可能会作调整）
+
+## 2. 存在的问题
+
+### 2.1 线路设计问题
+- 原系统采用最早采用一段线路设计方式，即起【始点-->终点】进行设计，虽然实际运营过程中也涉及到下车过关的问题，但过关后仍然上同一辆车，造成浪费。（现在的运营模式是乘客在口岸过检后，乘坐到湾区其他城市，重新安排新的车辆）
+- 虽然后续加入了两段设计，但也是在原来的基础上分成两条线路，在检索上存在重复问题。
+- 跟线路相关的站点班次，需要实行各站点尤其是在口岸处的乘客统计，以作为调度的依据，决定加班和派车。
+
+### 2.2 排班问题
+- 排班效率过于低下，操作比较复杂，缺乏高效率的工具辅助。
+- 一键排班功能不好用，树状目录的操作方式对信息过滤和多选并不友好
+- 加班的操作，需要重复一次排班的操作。
+- 加班监测需要由线路始发站站点人员进行手工统计（每个班次、每天均需要进行监测统计），并没有系统辅助或自动计算，统计数值需要从购票系统查询并从余票-->购票-->检票（上车）的转换
+
+### 2.3 票务问题
+- 缺乏动态调价的操作，对票价进行修改需要针对每一班车进行调整，操作繁琐并重复
+- 站务人员使用 TVM 机进行补票（帮助乘客现场购票），需要同时配备几个机器（手机、TVM、八达通终端、Post 机终端），并指向【现金支付】，但埋数时站务需要重新整理各种支付方式对应的金额，工作繁琐。
+- 支付处理等待时间过程。尤其是通过银行系统支付，下订单后【等待支付】需要 15 分钟，车票被锁定，若不处理，锁定的票不能及时回仓（在香港，车辆大概 20 分钟一班，长时间锁票导致资源浪费），希望能缩短等待支付的时间。
+- 快捷购票问题。主要集中在购票界面，如小程序/自助机，操作步骤较多，希望能缩减一些操作，提升效率。
+> 突出表现为自助机，目前已经做一些改进，门店机器默认只能选择该门店对应的站点作为购票起点，减少了一些操作。
+- 放票设置。目前还没有能针对时段、代理商等进行放票比例或者数量的设置。
+
+### 2.4 检票问题
+- 检错票。几种检错票的情况：提前检票，后续班次的票被本班次检票；回程票当做出发票提前被检，导致回程时票不能检；
+- 检票 App 容易选错班次，导致检票出错（检票 App 的设置流程不友好导致）
+- 无法检票。几种情况：口岸处信号不好，导致工作人员无法检票；大型活动如演唱会散场，基础带宽不够，导致乘客无法调出电子票或工作人员无法通过后台验票。
+- 不规范检票。人多时间紧张（大巴车有停靠时间要求），工作人员在明知检票异常情况不做处理，直接放行。
+- 无操作记录。没有记录检票门店（或检票员）信息，出现问题无法定位责任所在。其原因是检票员使用的是门店/站点的手机进行操作，所有检票员用的同一个站号，后台也没对门店进行区分，属于系统性问题。
+
+### 2.5 退票问题
+- 责权声明不够明显。购票是没有明显突出退票的规则和责权，导致乘客并不知退票的代价
+- 来回票退票问题。购买了来回票，因行程、天气、管制等原因，不能取消回程的，仅退回程票（根据退票规则）
+- 没有改签的操作。
+
+### 2.6 代理商问题
+- 代理商没有下级代理的概念，不能管理子代理。
+- 代理商没有报表功能，不能自行对账。
+- 架构不合理，网络代理商的接入挤占大量的系统资源，曾经导致系统崩溃。
+
+### 2.6 系统问题
+- 系统没有角色、部门的概念。权限设置针对个人用户，不能有效约束用户行为，配置麻烦且。权责划分没有部门定位，尤其在多部门协作时容易出现无法追踪问题。例如，检票没有门店概念。
+- 缺少关键操作的后台记录。一些重大/危险/跨部门的操作，目前均由系统管理员（电脑部）进行操作，责任归属不明确；缺少日志跟踪对于追溯问题发生时段比较困难。
+- 缺乏内部的消息管理系统。信息流向基本上靠人工和传统通讯手段（电话、聊天软件、电子文档、纸质材料），即时性不强，数据难以回归系统进行协作和统计。
\ No newline at end of file
diff --git a/调研和需求/需求整理/需求整理（持续更新）.md b/调研和需求/需求整理/需求整理（持续更新）.md
new file mode 100644
index 0000000..3cdb924
--- /dev/null
+++ b/调研和需求/需求整理/需求整理（持续更新）.md
@@ -0,0 +1,175 @@
+---
+title: 需求整理（持续更新）
+mdate: 2026-03-18 20:28:47
+mdevice: iPad
+doc_id: 204168cc4c3244b992d2f7e45ca44e15
+date: 2026-03-18 20:27
+---
+
+# 需求汇总
+
+## 1. 线路与排班需求
+
+### 1.1 线路结构优化
+
+**现状**：原系统运营线路是单段设计，即【起点-口岸-终点】当做一条线路，没有考虑分段。跨境运营政策放宽后，售票和车辆调度不够灵活和高效
+> 备注: 线路设计的合理性和存在的问题
+> - 跨境运营政策放宽，可以允许两地使用不同的车辆和司机进行运营
+> - 单段设计，对口岸乘客统计上效率低下，实际统计数据时效性不强
+> - 多条线路的站点参与查票检索，检索速度慢，尤其是开发网上代理商接入，导致系统崩溃。目前通过限流方式初步解决。
+
+**需求**：通过线路结构优化，提升运营效率和线路检索效率，有效接入互联网代理商，保证系统稳定性。
+- 在口岸出实现有效的客流统计，便于排班调度
+- 实现更灵活的线路制定，适应香港和内地两端的班次调配。
+- 优化线路、班次检索，有效对接第三方售票平台，而不是限流保持稳定
+
+**建议**：对线路进行结构性改进，强化**口岸**属性**，**以口岸作为中间平台，以优化查询统计效率，提升调度能力
+- 无论班次线路一段或二段，必须具有口岸站点，不允许不经口岸的跨境站点。
+- 以口岸作为平台，实行到达口岸的乘客统计，计算口岸通往各地的乘客数量。
+- 二段检票需在口岸进行，否则不能进行二段检票。
+- 口岸人数统计必须保留日报表，作为排班调度的依据（可持续优化）。
+
+### 1.2 线路查询优化
+
+**现状**：线路查询目前采用【城市—>站点】的选择模式，但由于内地城市区划变更以及港人的认知习惯，导致在城市设定时加入旧有的城市名称。显著突出在自助机操作上，多一步操作或返回操作，都容易导致现场购票排队加长的情况。
+> 备注：两地认知惯性和检索效率（用户体验）
+> - 城市规模大，区级行政单位多，导致站点过多，查询不利于乘客检索。例如广州作为城市，操作上应该列出广州所有的站点。
+> - 港人对内地传统城区/郊区/县的使用习惯。例如番禺、顺德这些热门目的点，分别作为广州和佛山的区级单位，但港人的习惯是将其作为传统城市对待，以【市—>区/县—>站】这种多级检索方式可能导致查站困难。
+
+**需求**：解决购票环节中两地用户的使用习惯和操作便捷性问题
+- 符合港人对湾区城市和地区的传统认知
+- 提供更加高效快捷的检索方式和手段
+
+**建议**：兼顾正规的行政区域和传统地区对站点进行设置，以便进行检索。
+- 站点多种绑定方式。分别绑定城市区号，例如参考国内的区号设定，并同时支持自定义地区绑定，如广州城区（越秀、荔湾、天河、黄埔、白玉区部分）
+- 加入热门线路，方便在操作界面上直接点选。后期考虑通过注册用户的购票记录进行推荐。
+- 加入口岸检索，方便港人直接到口岸换乘。
+
+### 1.3 排班优化
+
+**现状**：排班工作量大，大量的操作重复，容易出错，并且操作不友好。
+> 备注：排班的常规操作
+> - 单线单日排班：单个班次需要设定的内容过多，对于同一条线路的不同班次需要重新设置，重复量大。
+> - 单线多日排班：一般比较固定地重复该线路的某一天的排班，除非特殊情况取消某些班次。
+> 固定班次排班需要提前一个月完成，对应售票是预售一个月后的车票。
+
+**需求**：降低排班的复杂程度，提升排班效率和准确度。
+- 减少排班过程的重复操作，提升排班效率
+- 规范化排班流程，减少误操作
+- 对排班工具进行改进
+
+**建议**：采用排班模板的方式，对线路进行映射，并制作排班规则进行批量排班。
+- 单班模板。针对线路设定模板，例如上下车站点、票数、票价策略等，通过模板进行线路的多班次创建。
+- 单日模板。设置或者选择排的单日所有班次作为单日模板，生成该线路的全天排班。可以制作工作日、休息日、节假日的模板。
+- 排班规则。使用排班规则进行批量排班，例如从某日开始，连续 N 日重复应用某个单日模板。
+- 票价策略。班次中包含票价策略的设定，例如节假日上浮的幅度、特殊时段的票价变动等。
+- 单班修改。批量排班后可以针对单班进行修改，并有明确的指引提醒该班具有单独调整的操作。
+
+### 1.4 一键排班改进
+
+**现状**：原系统一键排班采用比较传统的节点树和多选框方式进行操作，使用上并不友好，容易错选。
+> 备注：现有系统一键排班的操作方式
+> - 节点树选需要层层展开，子节点过多时不好选择，多选（非全选）操作效率低下。
+> - 缺乏检索和过滤功能，需要从 N 条线路或班次中人工选中并应用。
+
+**需求**：提供切实好用的一键排班工具，降低重复操作的工作量。
+- 改进一键排班不友好的操作，如目录树操作
+- 提升一键排班的有效性和效率
+
+**建议**：对操作进行改良，使用列表+过滤的方式进行准确操作。
+- 参考上述【排班优化】，通过模板+策略的方式减少操作。
+- 加入检索功能，对线路、模板、策略过多时进行检索过滤。
+- 在提交前进行排班信息确认，如使用了什么模板、设置了什么策略、应用在那条线路、受影响有哪些班次，避免误操作后重排。
+
+### 1.5 班次站点统计
+
+**现状**：目前没有针对班次站点的统计。
+> 备注：
+> - 该需求是从加班和调度中引出，初步定位为服务于站务人员。
+> - 用于加速[加班发起—>排班—>派车的流程]
+> 班次站点统计有利于对班线的长期跟踪
+
+**需求**：加班和运营工作的依据和辅助。
+- 需要对班次站点的余票和购票情况进行统计，用作加班的依据。
+- 为日常班车运营优化提供数据支持。
+
+**建议**：将以后台自动统计的形式存在，定时对班次进行自动统计。参考下文【加班监测】内容。
+- 后台服务对班次进行定时监测和统计
+- 对服务加班条件的班次进行消息推送
+
+## 2. 加班和调度需求
+
+### 2.1 加班监测
+
+**现状**：目前班次加开使用人工监测和调度的方式进行。由站点始发站门店人员进行整体监测（不断刷新后台票务系统），当班次余票低于一定数值如10张（各班次不一样，根据实际运营经验所得），即由始发站人员向排班人员【调配大巴部】发起申请，排班人员向调车人员【车务部】咨询是否有车，再决定是否加开。若决定加开，则需要在系统设置加开班次信息。
+> 备注：目前加班的业务操作流程
+> - 手动刷新查看余票，需要人工不断监测。原系统在高峰期刷新售票页面缓慢，等待时间过长。
+> - 加班需要统计每个站点的售票情况，需要人工将余票转为售出票数
+> - 加班车的始发站会根据本班（非加班）售票最多的站点，作为加班车的发车站点，不一定是本班的始发站发车
+> - 触发加班的余票阈值不是固定的，需要根据实际经验进行调整，不是每个班次都一样。
+> 目前加班的操作都是采用人工联系方式进行
+
+**需求**：提升系统刷新余票性能，能够实现余票与售票的统计。
+- 提升查票效率，减少等待时间
+- 实现余票统计和售票统计的切换
+> 备注：该需求属于外在需求，并不是需要沿着原系统改进，而是通过改进模式，用更好的方式替代。
+
+**建议**：将人工监测和统计，改为【后台】按照规则自动统计并触发消息推送
+- 在班次设置增加余票触发设置 N 张
+- 建立后台算法，自动统计本班余票和各站点售票情况
+- 通过消息机制，向负责排班的人员发起通知
+- 完善车务系统，快速查询可用的司机和车辆
+- 优化，去掉站务监测统计环节，缩减【调度-车务】环节所需时间。
+
+### 2.2 口岸乘客统计
+**现状**：跨境线路分为两段，乘客需在口岸下车，通关后再重新上车（不一定是原来的那一辆车）。实际调度时需要根据两地在口岸的乘客数量来匹配和调度车辆。因此需要加入口岸乘客的统计，用于通过实际数据来合理调度车辆。
+> 备注：可能出现的几种情况：
+> - 到从口岸下车乘客不定乘坐整条跨境线路，有可能到了口岸过关后选择其他交通工具，这部分可以剔除
+> - 在口岸下车的乘客有可能再次选择在口岸站点买票乘坐永东的车前往内地城市（在香港就近没买到直通票，到口岸曲线操作）
+> - 单边有多条线路多个班次指向同一口岸，但去往不同的内地城市，需要根据到达口岸的时间进行分类统计，优化调度。
+> - 单向不断加班，导致另一侧同样需要增加运力。
+
+**需求**：针对两地乘客数量匹配的问题，需要精准计算和匹配，合理调配车辆。
+- 两地乘客在口岸进行换乘，多路汇入和多路输出需要在一个时间点内进行匹配
+- 根据统计数据进行车型和班次的调整
+- 加班存在的时候，乘客数据属于动态变更，需考虑变更后的跟踪和调整
+- 会存在因交通原因晚到的情况
+
+**建议**：后台程序加入实时统计，分时间和目的地进行报表和结果输出，并提醒是否增减运力和匹配车型。类似【加班监测】的模式。
+- 通过口岸 ID 和到达口岸的时间进行匹配和统计
+- 按照目的地城市和终点进行分类输出。
+- 建立适当的规则进行消息提醒，避免人工监测数据。
+- 可在司机端 App 加入动态跟踪，预计车辆到达口岸的时间
+
+### 2.3 快捷加班
+**现状**：加班需要重新创建班次并填写相关的参数，操作繁琐。
+> 备注：加班班次规则和操作：
+> - 现时的加班操作相关与新建一个班次，并将班次号与原班次进行递增，如原班次+b。
+> - 工作量与重新创建一个班次无异，操作步骤过多。
+
+**需求**：减少在系统设置加班的所需的操作，符合加班的班次命名
+- 优化加班的系统操作
+- 建立加班班次的命名规则
+
+**建议**：加入【一键加班】功能
+- 原班次的基础上增加快捷键，实现一键加班，复制需要加班的班次，并设置班次名称、首发站（可根据统计数据自动指定）、票数等参数。
+- 在操作界面上加入加班提醒，并在可原班次信息上加入【可加班】的标识。
+- 参考原系统的人工命名规则，在开通加班班次时自动应用规则。
+
+## 3. 售票需求
+### 3.1 动态票价
+**现状**：实际运营是有实施动态票价，但系统中没有能设置动态票价的策略。
+> - 调价需要在系统中单独选择某些班次进行调整，并在排班的时候完成
+> - 调价也有一些快捷操作，例如从某天开始连续多少天进行整体调价
+> - 调整期结束后，需要重新设置为原来的价格，会切换比较复杂
+> - 没有灵活的调价方式，例如针对高峰期自动调价
+
+**需求**：需要灵活的动态票价方式
+- 常态调整，工作日和休息日的价格调整
+- 高峰期价格调整，针对当前的高峰时段进行价格调整
+- 针对性调整，针对大型节假日、大型活动进行调整
+- 调价结束后自动恢复原价
+
+**建议**：建议采用增加票价策略功能，在排班时应用具体调价策略来实现
+
+ 
\ No newline at end of file
diff --git a/项目开发/软件功能/后台系统功能设计.md b/项目开发/软件功能/后台系统功能设计.md
index b53ae18..dafe9f0 100644
--- a/项目开发/软件功能/后台系统功能设计.md
+++ b/项目开发/软件功能/后台系统功能设计.md
@@ -1,6 +1,6 @@
 ---
 title: 后台系统功能设计
-mdate: 2026-03-18 15:27:20
+mdate: 2026-03-18 16:53:10
 mdevice: lazy的MacBook Air
 doc_id: 2d7921bcb33d47768945bb8f8d9a8e08
 date: 2026-03-18 15:27
@@ -46,6 +46,7 @@ date: 2026-03-18 15:27
 - 区分城市和地区。解决港人对内地城市传统惯性认知。每个站点均需要绑定城市和地区。
 >内地习惯为【市-区/县-站】，香港习惯为【市/县/区-站】，例如佛山市，港人习惯为佛山、南海、顺德并列。
 - 站点绑定。站点必须绑定真实的经纬度坐标，同时可绑定城市和地区两套规则。
+- 站点二维码。每个站点均可生成二维码，利用二维码实现扫一扫快捷购票功能。即默用户在扫码时默认使用该站点作为搜票的起点。
 
 ### 2.2 口岸
 强化口岸属性，口岸属于线路的必选点，需要跟线路进行强绑定。
@@ -58,6 +59,9 @@ date: 2026-03-18 15:27
 - 线路必须绑定口岸 ID，通过【线路-班次】实现对口岸客流统计
 - 一条线路只关联一个口岸
 
+## 3. 排班设计
+
+