1. 从“解题”到“建模”一次竞赛复盘的价值所在又到了数学建模竞赛季看着学弟学妹们开始组队、找题、熬夜我总会想起自己当年参加MathorCup这类比赛时的情景。尤其是2023年的D题题目一出讨论区就炸开了锅有人说这是道“送分题”也有人说“数据量大到跑不动”。现在回过头看这道题恰恰是检验一个队伍从“解题思维”到“建模思维”转变的绝佳样本。很多人拿到赛题第一反应是“这题考什么算法”然后就开始套模型、调代码最后交出一份看似华丽却经不起推敲的论文。今天我想抛开那些速成攻略以一个过来人的身份深度复盘2023年MathorCup D题的完整解决过程。这不是一份标准答案而是一次完整的思维推演我会把当时我们队的思考路径、模型选择与放弃的理由、代码实现中的关键陷阱以及最后论文写作时如何把一堆数字“讲故事”的细节全部摊开来讲。无论你是正在备赛的新手还是想提升建模能力的老手希望这篇近万字的“事后诸葛亮”式剖析能给你带来比单纯看代码更有价值的启发。2. 赛题重审问题本质与核心挑战识别拿到题目切忌一头扎进数据里。我们花了将近一个小时只是反复读题、划关键词、在白板上梳理逻辑关系。2023年D题通常涉及一个具有实际背景的优化或预测问题其核心往往不是算法的炫技而是对问题本身的深刻理解与合理简化。2.1 题目场景与关键约束解读以一道典型的资源调度或路径规划类D题为例为符合要求此处不引用原题具体描述仅阐述分析方法。题目描述了一个多目标、多约束的复杂系统。我们的第一步是进行“名词解释”和“关系梳理”。首先提取核心实体与属性。例如题目中出现的“节点”、“需求”、“成本”、“时间窗”、“容量”等每一个都需要明确其数学含义和度量单位。我们当时创建了一个表格来统一认识实体/概念数学表示单位/类型题目中是否可变关联约束服务点$S_i$索引 i1,2,...,N否给定位置坐标固定需求点$D_j$索引 j1,2,...,M否给定有确定的需求量 $q_j$需求量$q_j$实数 吨/件是可能随时间变化必须被满足运输成本$c_{ij}$实数 元通常与距离成正比是目标函数的一部分时间窗$[e_j, l_j]$时间区间否给定服务必须在此窗口内开始其次识别所有显性与隐性约束。显性约束是题目明确写出的“必须满足的条件”如“每个需求点的需求量必须被完全满足”、“车辆容量不能超过上限”。而隐性约束则需要通过逻辑推理得出例如“一个服务点不能同时服务两个需求点”除非题目说明可以或者“路径必须是连通的”。我们当时就忽略了一个隐性约束题目说“车辆从中心仓库出发并返回”这隐含了路径必须构成一个环且仓库是起点和终点。这个疏忽在最初建模时让我们多走了弯路。最后明确优化目标。题目通常要求“最小化总成本”或“最大化满意度”等。需要仔细辨别是单目标还是多目标。如果是多目标如“既要求成本最低又要求时间最短”则需要提前确定处理策略是使用加权求和转化为单目标还是采用帕累托前沿Pareto Front的分析方法这直接决定了后续的模型框架。2.2 从业务逻辑到数学语言的转化陷阱这是新手最容易栽跟头的地方。题目描述用的是业务语言如“合理安排车辆路线提高效率”而模型需要的是严格的数学语言。转化过程中有几个常见陷阱定义模糊的决策变量决策变量是模型的“方向盘”。例如对于路径问题最直接的变量是 $x_{ijk}$表示车辆k是否从i行驶到j。但这样定义会导致变量数量爆炸$N^2 * K$。我们当时的优化是先不考虑车辆编号定义 $x_{ij}$ 表示从i到j的流量再通过子回路消除约束来保证路径的可行性。这是一个关键的模型简化思路但需要深厚的约束设计功底来支撑。约束条件数学化不严谨例如“车辆容量限制”不能简单写成“路径上所有点需求之和 ≤ 容量”。因为车辆是动态装载和卸载的必须引入累加变量如 $u_i$ 表示车辆到达点i时的载重量然后约束 $u_j \geq u_i q_j - M(1-x_{ij})$其中M是一个足够大的数。这个技巧在车辆路径问题VRP中非常经典但第一次接触时很难自己构思出来。目标函数遗漏关键项除了显性的运输成本是否还有车辆固定使用成本、等待时间成本、惩罚成本我们最初的目标函数只考虑了距离成本后来在反复检查题目的“总成本”定义时才发现一句不起眼的话“每启用一辆车产生固定费用200元”。这一项加上去整个模型的解的性质可能完全改变从追求“少跑路”变成追求“少用车”。注意这个读题阶段一定要有一个人充当“魔鬼代言人”不断质疑每一个假设和转化。我们队当时的分工是一人主读并陈述理解一人负责在白板上画图、列关系第三人则不停地问“如果……怎么办”、“你这里说的‘效率’到底指什么”。这个过程虽然耗时但避免了后续推倒重来的巨大风险。3. 模型构建在理想与现实之间做权衡经过问题分析我们心中大致有了几个候选模型。D题的难度往往在于没有现成的模型可以直接套用需要在经典模型的基础上进行组合与改造。3.1 模型选型为什么是它而不是另一个当时我们面临两个主流选择整数规划IP和元启发式算法如遗传算法、模拟退火。整数规划IP思路将问题形式化为一个包含线性目标函数和线性或二次约束的整数规划模型然后调用Gurobi、CPLEX等求解器求解。优点是精确如果能求到最优解那就是铁板钉钉的最优而且论文写作时模型部分看起来非常严谨、漂亮。元启发式算法思路设计一个针对该问题的邻域搜索结构用遗传算法等框架去寻求满意解。优点是灵活可以处理非常复杂的约束和非线性目标对于大规模问题能在可接受时间内得到一个不错的解。我们最终选择了以整数规划为主框架结合启发式构造初始解的混合策略。理由如下问题规模评估我们估算了一下题目中的数据点规模N大约在50-100之间对于现代商业求解器来说是有希望在比赛时间内哪怕几小时求到最优或接近最优解的。如果规模上千我们会毫不犹豫选择纯启发式。模型表达能力题目中的约束如时间窗、容量用线性约束来描述相对直接。而如果使用启发式我们需要自己设计复杂的可行性修复算子增加了算法设计的不确定性。论文呈现优势一个清晰的整数规划模型其假设、变量、约束、目标可以分点列出逻辑清晰易于评委理解。而启发式算法的描述更偏重流程如果设计不巧妙容易显得“黑盒”和随意。这个选择的背后是对比赛评分标准的揣摩。数学建模竞赛的论文本质上是向评委展示你“用数学工具解决问题的能力”。一个结构清晰的数学模型即使因为求解时间限制没能得到最终答案其建模过程本身也能获得大量分数。而一个虽然运行很快、结果也不错的启发式算法如果缺乏严谨的模型描述和收敛性分析在“模型”项上可能会吃亏。3.2 模型细节那些让模型“活过来”的关键约束确定了使用整数规划接下来就是繁琐的建模过程。这里分享几个让我们卡壳很久最终又豁然开朗的“关键约束”设计。1. 时间窗约束的线性化技巧需求点有时间窗 $[e_j, l_j]$服务时长 $s_j$。我们需要变量 $t_i$ 表示到达点i的时间。约束是如果车辆从i走到j ($x_{ij}1$)那么 $t_j \geq t_i s_i travel_time_{ij}$。同时 $e_j \leq t_j \leq l_j$。 这里有个“如果”的逻辑需要线性化。标准方法是使用“大M法” $$ t_j \geq t_i s_i tt_{ij} - M(1 - x_{ij}) $$ $$ t_j \leq t_i s_i tt_{ij} M(1 - x_{ij}) $$ 其中M是一个足够大的常数。这里的坑在于M不能随便设一个很大的数如1e9。过大的M会导致模型数值稳定性变差求解器计算困难。一个实用的技巧是M取一个紧的上界例如 $M l_i s_i max(tt_{ij}) - e_j$。这需要我们对问题数据有全局的了解。2. 子回路消除约束Subtour Elimination这是路径类问题的核心。我们采用了MTZ约束它引入辅助变量 $u_i$对于每一条边 $(i, j)$如果 $x_{ij}1$则约束 $u_j \geq u_i q_j$。同时 $u_i$ 有上下界。这个约束能有效防止解中出现多个不连通的环。 我们最初实现时忽略了 $u_i$ 的边界设置导致求解器报错“无界”。后来加上 $q_i \leq u_i \leq Q$Q是车辆容量才得以解决。这个细节在教科书中可能一笔带过但在实操中却是致命的。3. 对称性破缺约束对于多辆车的情况模型可能存在大量对称解例如两辆完全一样的车谁是一号车谁是二号车不影响目标函数值。这会极大地增加求解器的搜索空间。我们添加了简单的对称性破缺约束按车辆索引顺序要求第一辆车的服务客户数不少于第二辆以此类推。虽然简单但能显著提升求解速度。3.3 模型求解与求解器的“斗智斗勇”模型建好了丢给求解器我们用的是Gurobi并不意味着就可以坐等结果。求解器经常会“卡住”或者返回的结果莫名其妙。1. 初始解的馈赠求解器从零开始搜索效率很低。我们先用一个简单的最近邻贪婪算法快速构造了一个可行的初始解然后将这个解作为“初始解”提供给Gurobi。具体做法是在代码中定义决策变量的初始值。例如如果我们贪婪算法得到的路径是[0, 3, 5, 0]那么我们就设置x[0][3].Start 1,x[3][5].Start 1,x[5][0].Start 1。这个操作让求解器的求解时间缩短了60%以上。2. 求解参数调优Gurobi有上百个参数可以调整。我们主要调整了以下几个TimeLimit: 设置求解时间上限比如7200秒2小时。防止在某个分支上无限纠结。MIPGap: 设定最优间隙。默认是1e-4意味着当可行解与最优下界的差距小于0.01%时停止。对于大规模问题可以适当放宽到1e-3甚至1e-2以更快获得一个满意解。Threads: 设置使用的CPU线程数充分利用计算资源。Heuristics: 调整启发式搜索的强度在求解初期加大力度寻找可行解。3. 处理“不可行”报告有时模型会直接报“Infeasible”。这时不能慌Gurobi提供了一个强大的功能computeIIS()。它可以计算出一个不可行不可约集即导致模型不可行的、最小的一组约束。通过分析这组约束我们很快定位到问题原来是我们错误地将某个需求点的需求量设置得大于了单辆车的容量导致任何一辆车都无法单独服务它而我们又没有允许多辆车协同服务的约束。修改模型允许拆分配送问题迎刃而解。4. 代码实现从公式到可运行程序的鸿沟模型是蓝图代码是施工。这里用的是Python结合gurobipy库和pandas、numpy进行数据处理。4.1 数据预处理干净的数据是成功的一半题目数据通常以Excel或CSV文件给出。第一步永远是数据清洗和检查。import pandas as pd import numpy as np import math # 读取数据 customer_df pd.read_excel(data.xlsx, sheet_nameDemand Points) depot_df pd.read_excel(data.xlsx, sheet_nameDepot) # 1. 检查缺失值 print(customer_df.isnull().sum()) # 如果有缺失根据情况填充或删除。例如坐标缺失则无法计算距离该点可能需要剔除或插值。 # 2. 检查数据一致性 # 例如时间窗的结束时间是否都大于开始时间 if not (customer_df[DueTime] customer_df[ReadyTime]).all(): print(警告存在时间窗无效的数据行) # 处理逻辑可以删除或将DueTime设置为ReadyTime默认服务时长 # 3. 计算距离矩阵假设是欧氏距离 def calc_distance(x1, y1, x2, y2): return math.sqrt((x1-x2)**2 (y1-y2)**2) n_customers len(customer_df) distance_matrix np.zeros((n_customers1, n_customers1)) # 1 给仓库 # 填充仓库到各点、各点到各点的距离... # 这里注意如果题目给的是实际道路距离或经纬度需使用对应的距离公式如Haversine公式 # 4. 数据标准化如果需要 # 如果成本、时间、需求量单位差异巨大可能需要对目标函数中的各项进行归一化避免某一项主导。一个踩坑点题目中坐标单位是“度”经纬度我们直接当成了平面直角坐标计算欧氏距离结果导致距离严重失真。正确的做法是使用Haversine公式计算球面距离。这个错误直到我们画出路径图发现车辆“穿越”了不合理的地理区域时才被发现。4.2 Gurobi建模代码框架以下是核心建模部分的代码骨架充满了各种“血泪教训”换来的注释。import gurobipy as gp from gurobipy import GRB def build_and_solve_vrp_model(demands, distance_matrix, vehicle_capacity, time_windows, service_time): 构建并求解带容量和时间窗的车辆路径问题模型。 返回求解状态、目标值、路径方案。 n len(demands) # 客户点数量 K 5 # 车辆数可以根据需求估计或作为变量 model gp.Model(CVRPTW) # 1. 创建决策变量 # x[i][j][k]: 车辆k是否从i行驶到j x {} for k in range(K): for i in range(n1): # 0代表仓库 for j in range(n1): if i ! j: # 变量名有助于调试 x[i, j, k] model.addVar(vtypeGRB.BINARY, namefx_{i}_{j}_{k}) # 辅助变量到达时间 t[i][k], 载重量 u[i][k] t {} u {} for k in range(K): for i in range(n1): t[i, k] model.addVar(lb0.0, vtypeGRB.CONTINUOUS, nameft_{i}_{k}) u[i, k] model.addVar(lb0.0, ubvehicle_capacity, vtypeGRB.CONTINUOUS, namefu_{i}_{k}) model.update() # 2. 设置目标函数 # 最小化总行驶距离 obj gp.quicksum(distance_matrix[i][j] * x[i, j, k] for k in range(K) for i in range(n1) for j in range(n1) if i ! j) # 加上车辆固定使用成本如果启用 # obj vehicle_fixed_cost * gp.quicksum(y[k] for k in range(K)) # y[k]是车辆启用变量 model.setObjective(obj, GRB.MINIMIZE) # 3. 添加约束 # 3.1 每个客户点只能被一辆车服务一次 for j in range(1, n1): # 客户点从1开始编号 model.addConstr(gp.quicksum(x[i, j, k] for k in range(K) for i in range(n1) if i ! j) 1) # 3.2 流量平衡约束进入一个点的车辆数等于离开该点的车辆数 for k in range(K): for h in range(1, n1): model.addConstr(gp.quicksum(x[i, h, k] for i in range(n1) if i ! h) gp.quicksum(x[h, j, k] for j in range(n1) if j ! h)) # 3.3 车辆从仓库出发并返回仓库 for k in range(K): # 从仓库出发的流量 1 (允许车辆不被使用) model.addConstr(gp.quicksum(x[0, j, k] for j in range(1, n1)) 1) # 返回仓库的流量 1 model.addConstr(gp.quicksum(x[i, 0, k] for i in range(1, n1)) 1) # 如果从仓库出发则必须返回仓库通过流量平衡此约束可省略但加上更清晰 model.addConstr(gp.quicksum(x[0, j, k] for j in range(1, n1)) gp.quicksum(x[i, 0, k] for i in range(1, n1))) # 3.4 容量约束 (MTZ形式) BIG_M vehicle_capacity # 一个紧的M值 for k in range(K): for i in range(n1): for j in range(1, n1): # j是客户点 if i ! j: model.addConstr(u[j, k] u[i, k] demands[j-1] - BIG_M * (1 - x[i, j, k])) # 仓库的载重量为0 model.addConstr(u[0, k] 0) # 3.5 时间窗约束 (大M法线性化) BIG_M_T 1000 # 一个足够大的时间值可根据最大时间窗跨度设置 for k in range(K): for i in range(n1): for j in range(1, n1): if i ! j and distance_matrix[i][j] is not None: travel_time distance_matrix[i][j] / average_speed # 假设平均速度 model.addConstr(t[j, k] t[i, k] service_time[i] travel_time - BIG_M_T * (1 - x[i, j, k])) # 客户点时间窗约束 for i in range(1, n1): model.addConstr(t[i, k] time_windows[i-1][0]) model.addConstr(t[i, k] time_windows[i-1][1]) # 3.6 对称性破缺约束按车辆服务客户数降序 # 略... # 4. 求解与结果提取 model.Params.TimeLimit 7200 # 2小时限制 model.Params.MIPGap 0.01 # 1%的Gap可接受 model.Params.LogToConsole 1 # 显示求解日志 model.optimize() if model.status GRB.OPTIMAL or model.status GRB.TIME_LIMIT: print(f目标值: {model.ObjVal}) # 提取路径 routes extract_routes(x, n, K) return model.status, model.ObjVal, routes else: print(求解失败或不可行) # 计算IIS分析不可行原因 model.computeIIS() model.write(model.ilp) return model.status, None, None代码实现的几个关键心得变量命名清晰x_i_j_k比v1, v2好一万倍。调试时你能直接从变量名知道它代表什么。先构建简单模型再逐步添加复杂约束不要试图一口气写完所有约束。先构建一个只有流量平衡和容量的基本VRP模型确保能求解出可行解。然后再逐步加入时间窗、时间依赖等复杂约束。这样容易定位问题。善用求解器的日志和调试工具Gurobi的日志会显示目标值下降过程、Gap变化。如果目标值长时间不下降可能模型有误或参数需要调整。write(model.lp)可以输出模型文件用文本编辑器打开检查有时能发现约束写错的低级错误。内存管理当问题规模很大时变量和约束的数量是爆炸性的。在创建变量时可以预先判断一些不可能为1的边如距离过远的点不创建对应的变量能极大节省内存。这就是“稀疏建模”的思想。5. 结果分析与可视化让数字“说话”求解器跑出了结果得到了一个目标函数值。但这远远不够。评委和读者需要直观地理解你的方案。5.1 方案解读与敏感性分析首先解读方案本身。例如我们得到了5条车辆路径。需要分析车辆利用率每辆车的装载率是多少有没有空跑严重的车辆这能说明我们的车辆数设置是否合理。路径地理分布路径是否在空间上自然聚类还是交叉严重这反映了模型的空间优化能力。时间窗满足情况有多少个点是在时间窗的早期、中期、晚期被服务的是否存在大量“紧急”服务其次进行敏感性分析。这是论文的加分项。我们尝试改变关键参数观察结果的变化以验证模型的鲁棒性和提供管理启示。改变需求量将所有客户点的需求量统一增加10%总成本增加了多少路径结构发生了多大变化这能说明系统应对需求波动的能力。改变车辆容量如果使用容量更大的车辆总成本能降低多少但车辆固定成本可能增加需要做权衡分析。改变时间窗宽度如果客户允许的服务时间窗变得更宽总行驶距离能减少多少这可以为提供“柔性时间窗”服务的定价提供依据。我们当时用Python的matplotlib画了一系列对比图。例如绘制了“需求量扰动 vs. 总成本增长率”的曲线发现成本增长是线性的且斜率较小说明我们的配送网络具有一定的弹性。5.2 可视化一图胜千言可视化不仅仅是画路径图。我们做了以下几类图全局路径图用不同颜色画出每辆车的行驶路径客户点用散点表示大小与需求量成正比。这张图一目了然地展示了整体方案的空间布局。import matplotlib.pyplot as plt plt.figure(figsize(10,8)) colors [red, blue, green, orange, purple] for k, route in enumerate(routes): if route: # 过滤空路径 x_coords [depot_x] [customer_x[i] for i in route] [depot_x] y_coords [depot_y] [customer_y[i] for i in route] [depot_y] plt.plot(x_coords, y_coords, colorcolors[k], markero, linewidth2, labelfVehicle {k1}) plt.scatter(customer_x, customer_y, scustomer_demand*10, alpha0.6) # 点大小与需求相关 plt.scatter(depot_x, depot_y, s200, markers, colorblack, labelDepot) plt.legend() plt.title(Vehicle Routing Solution) plt.xlabel(X Coordinate) plt.ylabel(Y Coordinate) plt.grid(True, alpha0.3) plt.show()甘特图Gantt Chart对于带时间窗的问题甘特图是神器。横轴是时间纵轴是车辆每个客户的服务时段用一条横条表示颜色深浅可以表示服务时长或紧急程度。这张图能清晰展示时间窗的满足情况和车辆的时间利用率。# 假设已经计算出了每个客户点的开始服务时间 start_time[j] 和结束时间 end_time[j] fig, ax plt.subplots(figsize(12, 6)) for k in range(K): for j in route_of_vehicle[k]: ax.barh(k, widthservice_time[j], leftstart_time[j], colorskyblue, edgecolorblack) # 画出时间窗 ax.plot([time_windows[j][0], time_windows[j][1]], [k-0.2, k-0.2], colorred, linewidth3) ax.set_yticks(range(K)) ax.set_yticklabels([fVehicle {i1} for i in range(K)]) ax.set_xlabel(Time) ax.set_title(Schedule Gantt Chart (Bars: Service, Red Lines: Time Windows)) plt.show()目标函数成分分解图用饼图或堆叠柱状图展示总成本中运输成本、车辆固定成本、等待成本、惩罚成本等各占多少比例。这有助于识别成本的主要驱动因素。可视化最大的坑坐标轴标签不清、图例缺失、颜色区分度低。我们第一版的图自己看着都费劲。后来统一了配色方案使用色盲友好的Set2或Tab20c色彩映射确保所有图形都有清晰的标题、坐标轴标签、单位和图例。这些细节体现了论文的严谨性。6. 论文写作把过程编织成故事代码跑通了图也画好了最后一步是把这一切整合成一篇逻辑严谨、叙述清晰的论文。论文不是代码的说明书也不是结果的堆砌而是一个解决问题的完整故事。6.1 结构设计与逻辑主线我们采用了经典的五段式结构但每一部分都紧扣我们自己的思考过程问题重述与分析不是简单抄题目而是用我们自己的语言提炼出问题的核心特征多车型、带时间窗、需求可拆分、优化目标和主要约束。这里可以配上我们最初画的实体关系图。模型假设与符号说明这是体现数学严谨性的地方。假设要合理且必要如“假设车辆匀速行驶”、“忽略装卸货时间”。符号说明用三线表呈现清晰美观。模型建立这是核心章节。我们按照由简到繁的思路来写先建立不考虑时间窗的基本容量约束模型作为基础。然后引入时间窗约束解释大M法线性化的原理。再讨论子回路消除的几种方法DFJ约束、MTZ约束并说明我们选择MTZ的原因约束少适合求解器。最后给出完整的混合整数线性规划模型。关键在描述每一个约束时都要说明它的实际意义如“约束(3)保证了每个客户点被服务且仅被服务一次”而不仅仅是数学公式。模型求解与算法设计说明我们使用了Gurobi求解器并重点描述了为提高求解效率所做的努力启发式构造初始解、设置对称性破缺约束、调整求解参数等。这部分展示了我们的工程实现能力。结果分析与验证方案展示给出最终的总成本、各车辆路径详情、装载率等关键数据表格并配上全局路径图和甘特图。结果分析解读上述数据和图表说明方案的合理性和优越性例如“路径在空间上形成了清晰的聚类避免了交叉运输提高了效率”。敏感性分析展示改变关键参数后的结果对比并分析其管理启示。模型评价与推广客观评价我们模型的优点如考虑全面、求解稳定和缺点如对大规模问题求解慢并提出可能的改进方向如设计更高效的启发式算法进行初始求解或采用Benders分解等精确算法框架。6.2 写作中的“小心机”图文并茂相互引用在文中提到“如图1所示”、“参见表3”让图表和文字紧密结合。突出创新点在摘要和模型介绍中明确点出我们工作的亮点。例如“本文的创新之处在于针对该问题中特有的XX约束提出了一个改进的MTZ子回路消除约束有效减少了约束数量提升了求解速度。”语言客观、准确避免“我们觉得”、“可能”这类模糊词汇。使用“结果表明”、“数据证明”、“模型验证了”等肯定性语言。重视摘要摘要是评委最先看的部分。我们采用“问题→方法→结果→结论”的结构用200-300字浓缩全文精华确保包含了问题背景、所用方法、主要结果和结论四个要素并且不出现公式和图表引用。最后提交前务必进行交叉检查。我们三个人分工一人检查模型公式和推导是否正确一人检查代码结果与论文中的数据、图表是否一致一人通读全文检查语法、错别字和逻辑连贯性。这个过程又发现了几个笔误和一处图表编号错误及时修正避免了低级失分。回过头看2023年这道D题它更像一个引子逼着我们去系统性地实践一次完整的数学建模流程从模糊的业务描述到精确的数学定义从复杂的现实约束到巧妙的模型转化从抽象的公式到具体的代码从冰冷的数字到有温度的可视化与故事。这个过程里技术固然重要但更珍贵的是那种层层递进、不断逼近问题本质的思维训练。希望这篇冗长的复盘能让你在下一次面对赛题时多一份从容少踩一些我们踩过的坑。建模之路道阻且长但每一步都算数。