竞赛机器人如何跑出稳定成绩？从时间预算到状态机实战解析

如果你关注过移动机器人竞赛，看到“48.47秒”这个成绩时，应该能感受到它的分量。

竞技机器人项目里，几十秒的完赛时间并不是“跑得快”这么简单。它意味着机器人在起步、寻迹、避障、精准停靠、任务操作等多个环节里，不能有任何一次明显失误；意味着每个环节的时间预算都被精确压缩过；更意味着团队在赛前把大量不确定性——光照变化、地面摩擦、电量衰减、传感器飘移——都提前处理掉了。

很多人容易误以为，这类比赛拼的是“谁的算法更新颖”。从实际工程角度看，胜负手往往在系统工程能力上：任务拆解、时间预算、状态调度、异常兜底、联调迭代。这篇文章就围绕“48.47秒夺得亚军”这个成绩展开，但不是为了复盘某一场赛事，而是为了拆解竞赛机器人跑出好成绩背后通用的技术框架、代码实现和调试方法。无论你是在准备校内机器人赛、全国大学生机器人竞赛，还是在做移动机器人工程开发，这篇文章的方法论和代码示例都可以直接参考。

先给一个明确判断：竞赛机器人项目，真正的门槛不是 ROS、不是 SLAM、不是某个视觉模型，而是“如何让一套由十几个模块组成的系统，在几十秒内按预期稳定跑完”。48.47 秒只是一个结果，这个结果背后是一整套可复用的工程方法。

1. 从 48.47 秒看竞赛机器人的时间预算与技术分层

先聊一个核心概念：时间预算（Time Budget）。

在机器人赛事里，裁判只关心一个数字——完赛时间。但对你来说，这个数字必须被拆成若干个子任务的时间总和。移动机器人项目的完整任务时间通常由以下环节构成：

“48.47 秒”这个成绩能拿亚军，往往意味着各个环节都逼近了团队的优化极限。如果有任何一个环节出现 1 秒以上的异常等待，最终成绩就会明显下滑。这背后实际上是两个能力在起作用：

1. 任务级能力：把整体时间预算切到每个子任务头上，并持续优化瓶颈环节。
2. 系统级能力：每个子任务都能在指定时间内稳定完成，不出现偶发失败。

理解了时间预算，再去看整个技术方案，你就不会只盯着“定位准不准”“识别灵不灵”这些单点问题，而是会问：当前方案里，哪个环节占用了最多时间？这个时间能不能通过技术手段降下来？降下来之后会不会引入新的风险？

这就是从“看懂比赛”到“能做比赛”的第一个思维转变。

2. 竞赛机器人的核心技术栈与选型思路

竞赛机器人技术体系可以粗暴地分为四层，每一层缺一不可。

2.1 感知层

感知层的任务是回答“我在哪、周围有什么”。

常用方案有两种：

• 激光雷达 + 编码器 + IMU：多传感器融合定位，精度较高，适合有明确场地地图的比赛。
• 视觉传感器（单目/深度相机）：用于目标识别、色块检测、二维码定位，适合需要识别物体和标记的任务。

选型时要注意：传感器越多，数据融合越复杂，但容错性也会提高。新手团队容易陷入“传感器堆叠”的误区——觉得激光雷达、深度相机、编码器全上都装上才安心。实际上，每增加一个传感器，就意味着多一个标定步骤、多一条数据同步链路、多一类故障源。合理的做法是：先确认比赛任务必须感知什么，再决定用什么传感器。

2.2 决策层

决策层是整个系统的大脑，负责状态切换、任务执行顺序和异常处理。

绝大多数竞赛机器人的决策层不需要用深度学习，一个结构良好的状态机（State Machine）就足够了。比如：

START -> INIT -> NAVIGATE -> DETECT -> MANIPULATE -> RETURN -> STOP

状态机的好处是：逻辑清晰、可测试、可回退。竞赛中如果某个状态执行失败，可以设计超时保护或重试机制，让机器人在短时间内恢复到安全状态。

2.3 控制层

控制层负责把决策层的指令转化为电机、舵机的运动。

核心工作包括：

• 底盘运动控制（PID 速度环、位置环）。
• 路径跟踪（纯追踪、模型预测控制）。
• 机械臂关节控制。

控制层最容易出问题的地方是 PID 参数。后续我会专门用一节讲 PID 调参，这里先记住一个结论：PID 不是调一次就完事的，它需要根据场地、电量、负载变化动态校准。

2.4 执行层

执行层包括底盘、机械臂、夹爪等硬件设备。

软件和硬件的配合是比赛里最容易被低估的部分。很多团队在仿真环境里跑得很好，一到真实场地就翻车，核心原因就是执行层的机械误差、传动延迟和响应非线性没有被建模。

3. 开发环境与基础框架搭建

在进入具体代码之前，先统一开发环境。

竞赛机器人项目不像普通 Web 开发，它涉及硬件驱动、系统级通信、传感器数据流，因此环境配置至关重要。推荐以下基础环境：

需要说明的是，ROS 不是竞赛机器人的唯一选择。如果你的比赛任务足够简单，不涉及多传感器复杂通信，直接写一个基于 Python 的控制器也可以。ROS 的优势在于模块解耦、消息通信和可视化工具成熟，但代价是学习曲线陡峭。如果你只有两周准备时间，优先做减法：用最小的技术栈先跑通一个完整任务，再逐步引入 ROS。

下面是一个最小化的 Python 项目结构，适合竞赛机器人快速迭代：

robot_competition/ ├── config/ │ ├── robot_config.yaml # 机器人参数配置 │ └── pid_params.yaml # PID 参数配置 ├── modules/ │ ├── __init__.py │ ├── chassis_controller.py # 底盘控制 │ ├── localization.py # 定位模块 │ ├── perception.py # 视觉识别模块 │ └── manipulator.py # 机械臂控制模块 ├── tasks/ │ ├── __init__.py │ ├── task_scheduler.py # 任务调度状态机 │ └── game_strategy.py # 比赛策略 ├── utils/ │ ├── __init__.py │ ├── logger.py # 日志工具 │ └── time_budget.py # 时间预算管理 ├── main.py # 程序入口 └── requirements.txt

在这个结构里，config/目录集中存放所有参数，禁止把参数硬编码在代码里。这样做的好处是现场调试时不需要重新编译或重启整个程序，只需要修改 YAML 文件并触发热加载。

# 创建虚拟环境并安装依赖 python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt

requirements.txt的内容根据实际依赖确定，这里不再写死版本。但有一点要注意：依赖版本一定要锁死，尤其是 OpenCV、NumPy 这类库，一旦升级可能导致视觉识别逻辑出现细微差异。

4. 核心流程拆解：从起点到 48.47 秒

前面说过，最终成绩是所有子任务时间的总和。这一节，我们把它拆开来看。

4.1 启动与自检阶段

比赛开始前，机器人通常会有一段等待时间。这段等待时间里不应该只“傻等”。

需要做的是：

• 检查所有传感器是否在线。
• 加载地图和配置文件。
• 确认电池电量。
• 将底盘和机械臂复位到安全位置。

代码里可以封装一个SystemChecker类，把自检逻辑独立出来。自检如果失败，要能在界面上给出明确提示，而不是等比赛开始后才发现某个传感器没有数据。

4.2 定位初始化阶段

很多移动机器人比赛会设置一个固定起点。如果起点固定，最简单可靠的做法是直接使用里程计+初始角度，不需要每次重新建图。

如果起点不固定，则需要快速重定位。常用方法包括：

• 在起点粘贴 AprilTag 或二维码，让机器人启动后先寻找标记。
• 使用 AMCL 粒子滤波进行全局定位。
• 人工手动微调初始位姿（如果规则允许）。

这个阶段的目标不是“精度绝对高”，而是“误差在可接受范围内”。如果一个机器人初始定位误差有 5 厘米，后续路径跟踪过程中误差会逐渐积累，最终可能影响停车和操作。所以，在初始定位上多花 0.5 秒是值得的。

4.3 路径行驶阶段

路径行驶是时间预算里占比最大的部分，也是速度优化的核心。

优化路径行驶时间的手段通常有以下几种：

1. 提高最大线速度：这直接受电机性能、电池放电能力和底盘稳定性约束。
2. 优化路径长度：让机器人走更短的路，这需要好的全局规划算法。
3. 减少加减速时间：缩短直线末端的减速窗口，但在转弯处要保留足够的进弯速度。

一个常见的误区是“平均速度越高，成绩越好”。真正要优化的不是最高速度，而是单位时间内有效完成的路径长度。如果一个机器人最高速度是 2 m/s，但每到一个弯道都要减到 0.2 m/s，那么整体平均速度很可能还不如一个最高速度 1.5 m/s、弯道能保持 0.8 m/s 的机器人。

因此，在路径行驶阶段，我们真正要调的是速度规划曲线。

4.4 识别与决策阶段

当机器人到达目标区域后，需要停下来（或慢速通过）识别目标。

这里的时间优化点有两个：

• 识别算法的推理速度：如果使用 YOLO 这类目标检测模型，可以通过模型剪枝、TensorRT 加速、降低输入分辨率等方式缩短推理时间。
• “在哪里识别”的策略：不要等到了一个固定点才开始拍照识别，可以在接近目标区域的过程中提前采集图像帧，边走边处理。

很多团队把识别作为一个独立阶段，时间是“停住、拍照、推理、决策”。更高效的做法是把识别做成一个异步过程，在底盘减速进入目标区域时就开始处理图像帧，等车停下来时已经知道了目标位置。

4.5 动作执行阶段

机械臂操作是竞赛机器人里最容易超时的环节。

一个抓取动作包含：

• 机械臂从 home 位运动到目标上方。
• 末端夹爪对准目标。
• 夹爪下落、闭合、抬起。
• 机械臂运动到放置区上方。
• 夹爪张开、释放。

每一步都有运动时间。你可以通过调整机械臂关节速度上限、优化轨迹插值方式来缩短时间，但要留出安全裕度。如果速度过快导致抓取失败，重试一次的时间成本远大于慢一点一次成功的成本。

4.6 停靠与完成阶段

最后是精确停靠。这个环节的速度通常要求不高，但精度要求很高。

常见问题有：

• 停车位置偏移导致任务完成判定失败。
• 机器人虽然到达目标点，但朝向不对，导致后续交互出现问题。

解决方案是引入末端精调：先用高速度行驶到目标附近，再用低速和传感器反馈进行精调。

5. 完整示例：任务调度状态机与时间预算控制

这一节我们直接进入代码。先写一个最核心的任务调度状态机，它负责把“48.47 秒”拆成每一步的执行逻辑。

文件路径：tasks/task_scheduler.py

import time from enum import Enum, auto from typing import Optional class RobotState(Enum): INIT = auto() READY = auto() NAVIGATE = auto() DETECT = auto() MANIPULATE = auto() RETURN = auto() STOP = auto() ERROR = auto() class TaskScheduler: """ 竞赛机器人任务调度状态机。 负责维护当前状态、执行时间预算、以及状态切换逻辑。 """ def __init__(self, time_budget: dict): self.state = RobotState.INIT self.time_budget = time_budget # 每个状态的时间预算，单位秒 self.state_start_time: Optional[float] = None self.state_elapsed: float = 0.0 self.error_count = 0 self.max_retry = 2 def enter_state(self, new_state: RobotState) -> None: """进入新状态，记录起始时间""" self.state = new_state self.state_start_time = time.time() self.state_elapsed = 0.0 print(f"[SCHEDULER] Enter state: {new_state}") def update(self) -> None: """周期性调用，检查当前状态是否超时，并推进状态机""" if self.state_start_time is None: return self.state_elapsed = time.time() - self.state_start_time budget = self.time_budget.get(self.state, float("inf")) if self.state_elapsed > budget: print(f"[SCHEDULER] State {self.state} timeout after {self.state_elapsed:.2f}s, budget {budget}s") self.handle_timeout() def handle_timeout(self) -> None: """超时处理：允许有限重试，超过次数进入错误状态""" if self.error_count < self.max_retry: self.error_count += 1 print(f"[SCHEDULER] Retry {self.error_count}/{self.max_retry}") # 这里可以执行恢复动作，比如回到安全位置 self.enter_state(RobotState.READY) else: self.enter_state(RobotState.ERROR) def run(self) -> None: """简单的主循环示例，实际项目中会接到机器人主循环中""" self.enter_state(RobotState.INIT) time.sleep(0.5) # 模拟初始化 self.enter_state(RobotState.NAVIGATE) time.sleep(2.0) # 模拟导航 self.enter_state(RobotState.DETECT) time.sleep(1.0) # 模拟识别 # 检查状态 self.update() print(f"[SCHEDULER] Current state: {self.state}, elapsed: {self.state_elapsed:.2f}s") if __name__ == "__main__": budget = { RobotState.INIT: 5.0, RobotState.READY: 3.0, RobotState.NAVIGATE: 20.0, RobotState.DETECT: 5.0, RobotState.MANIPULATE: 10.0, RobotState.RETURN: 15.0, RobotState.STOP: 3.0, } scheduler = TaskScheduler(time_budget=budget) scheduler.run()

这段代码的核心价值在于：

1. 把机器人任务拆成状态，而不是一个大的while True里堆满逻辑。
2. 为每个状态设置时间预算，一旦超时立即进入重试或错误恢复流程。
3. 所有状态切换都通过enter_state()方法完成，方便统计每个状态的耗时。

实际运行时，你只需要在机器人主循环里周期调用scheduler.update()，并让各个功能模块（导航、识别、机械臂）在完成各自任务后调用enter_state()切换到下一个状态。

再看一个时间预算管理工具。它可以帮助你在开发阶段快速找到“时间黑洞”。

文件路径：utils/time_budget.py

import time from collections import defaultdict class TimeBudgetTracker: """ 统计每个状态/模块的实际耗时，用于分析时间预算执行情况。 """ def __init__(self): self.records = defaultdict(list) self.current_key = None self.current_start = None def start(self, key: str) -> None: """开始计时某个环节""" self.current_key = key self.current_start = time.time() def stop(self) -> float: """停止计时，记录耗时，返回本次耗时""" if self.current_key is None or self.current_start is None: return 0.0 elapsed = time.time() - self.current_start self.records[self.current_key].append(elapsed) self.current_key = None self.current_start = None return elapsed def summary(self) -> dict: """返回每个环节的平均耗时、最大耗时、最小耗时和次数""" result = {} for key, values in self.records.items(): result[key] = { "count": len(values), "avg": sum(values) / len(values), "max": max(values), "min": min(values), } return result

这个工具解决的是“凭感觉觉得某个环节慢，但不知道慢多少”的问题。把所有关键环节包上start和stop，赛前训练跑几趟，就能用数据定位瓶颈。

# 使用示例 tracker = TimeBudgetTracker() tracker.start("navigate") # 执行导航逻辑 time.sleep(3.2) tracker.stop() tracker.start("detect") # 执行识别逻辑 time.sleep(1.1) tracker.stop() print(tracker.summary()) # 输出类似： # {'navigate': {'count': 1, 'avg': 3.2, 'max': 3.2, 'min': 3.2}, # 'detect': {'count': 1, 'avg': 1.1, 'max': 1.1, 'min': 1.1}}

6. 运动控制与定位调优：把时间压缩到极限

竞赛机器人成绩进一步提升，最大的瓶颈通常不是识别，而是运动控制的一致性。同一段路径，上午跑 10 秒，下午跑 12 秒，这就是控制一致性差的表现。

6.1 PID 控制器的工程实现

先看一个通用的 PID 控制器实现，后续调参时直接用它。

文件路径：utils/pid_controller.py

class PIDController: """ 位置式 PID 控制器，支持积分限幅和输出限幅。 """ def __init__(self, kp: float, ki: float, kd: float, integral_limit: float = None, output_limit: float = None): self.kp = kp self.ki = ki self.kd = kd self.integral_limit = integral_limit self.output_limit = output_limit self._integral = 0.0 self._prev_error = 0.0 def reset(self) -> None: self._integral = 0.0 self._prev_error = 0.0 def compute(self, setpoint: float, measurement: float, dt: float) -> float: """ 计算 PID 输出。 :param setpoint: 目标值 :param measurement: 当前测量值 :param dt: 控制周期，单位秒 """ error = setpoint - measurement # P p_out = self.kp * error # I self._integral += error * dt if self.integral_limit is not None: self._integral = max(-self.integral_limit, min(self.integral_limit, self._integral)) i_out = self.ki * self._integral # D derivative = (error - self._prev_error) / dt if dt > 0 else 0.0 d_out = self.kd * derivative self._prev_error = error output = p_out + i_out + d_out if self.output_limit is not None: output = max(-self.output_limit, min(self.output_limit, output)) return output

6.2 PID 调参的实用方法

很多新手一上来就调 PID，结果调了一周也没调好。问题往往出在没有方法论。

推荐下面的流程：

1. 先调 P：把 I 和 D 设为 0，从小到大增加 Kp。观察机器人是否出现震荡。当 Kp 增大到系统周期性震荡时，记下这个值，然后取它的 50% 作为初始 Kp。
2. 再调 D：保持 Kp 不变，从 0 开始增加 Kd，观察系统的超调量和震荡是否减少。D 过大会导致高频抖动。
3. 最后调 I：当系统存在稳态误差（比如始终差一点到不了目标速度）时，再慢慢增加 Ki。I 的作用是消除稳态误差，但调太大容易导致超调和震荡。
4. 限幅一定要加：轮式机器人的控制输出有物理上限，比如 PWM 值不可能超过 1000，因此output_limit必须设置。

此外，还要记录不同电池电压下的 PID 表现。电池电压从满电到低电，电机响应速度会有明显差异。提前做好多组参数的切换预案，比现场临时调参可靠得多。

6.3 定位误差来源分析

除了 PID，另一个影响完赛时间稳定性的因素是定位误差。常见的误差来源包括：

不要指望“定位可以做到零误差”。竞赛工程里更务实的做法是：了解误差范围，在任务设计时预留容差。比如目标物抓取区域允许 ±3 cm 误差，你的定位精度如果能稳定控制在 ±1.5 cm 以内，就有充足冗余。

7. 赛场联调与成绩评估闭环

竞赛机器人能跑出 48.47 秒，不是一次就成功的。每一轮训练跑完之后，都需要一个“评估闭环”：记录数据、分析数据、定位瓶颈、调整方案、再次验证。

7.1 日志记录是评估的基础

比赛现场和实验室环境差异很大，所以每一轮训练日志都要保留。日志至少要包含：

• 每个状态的进入、退出时间。
• 关键传感器数据（速度、位置、电量、温度）。
• 异常事件（超时、重试、识别失败）。
• 调试用的图像或点云快照。

一个简单的日志记录函数如下：

文件路径：utils/logger.py

import csv import time from datetime import datetime class RunLogger: def __init__(self, log_file: str = "run_log.csv"): self.log_file = log_file self._initialize_file() def _initialize_file(self) -> None: with open(self.log_file, "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["timestamp", "event", "state", "elapsed", "battery", "note"]) def log(self, event: str, state: str, elapsed: float, battery: float = None, note: str = "") -> None: with open(self.log_file, "a", newline="", encoding="utf-8") as f: writer = csv.writer(f) timestamp = datetime.now().isoformat() writer.writerow([timestamp, event, state, elapsed, battery, note])

7.2 赛前评估指标

每轮训练结束后，你要回答以下几个问题：

1. 本轮完赛成绩是多少？
2. 哪些状态超出了时间预算？
3. 有没有发生重试或超时？具体发生在哪个状态？
4. 定位误差最大的位置在哪里？是否接近任务容差边界？
5. 机械臂操作是否有过二次尝试？

如果一个问题连续三轮出现，说明它不是偶发问题，而是系统性缺陷，需要重新设计该环节，而不是继续调参。

7.3 通过统计优化时间分配

假设你记录了 10 轮训练数据，发现“识别”环节平均耗时 2.5 秒，远超预算的 1 秒，而“导航”环节比预算快了 3 秒。那么调整策略就非常明确：把导航环节节省的时间预算转移给识别环节，让模型推理时间更从容，识别成功率更高。

从这个角度看，48.47 秒不是“每一轮都快”，而是“每一轮都稳”。

8. 常见问题与排查方法

下面列出竞赛机器人开发和联调过程中最常遇到的一批问题，按排查优先级排列。

9. 竞赛机器人工程化最佳实践

成绩的稳定，建立在工程纪律上。以下是几个容易被忽略但非常关键的点。

9.1 配置参数全部文件化

机器人的所有可调参数——速度上限、PID 参数、识别阈值、状态机时间预算——都应该放进配置文件，而不是散落在代码里。比赛现场最怕的不是“算法不行”，而是“改了一个参数后忘了改了哪里”。

用 YAML 格式管理参数是非常合适的做法：

# config/robot_config.yaml chassis: max_linear_speed: 1.5 # m/s max_angular_speed: 2.0 # rad/s wheel_base: 0.35 # m wheel_diameter: 0.10 # m pid: velocity: kp: 0.8 ki: 0.1 kd: 0.2 integral_limit: 10.0 output_limit: 30.0 recognition: model_path: "models/detect.onnx" conf_threshold: 0.55 input_size: [640, 640] inference_backend: "tensorrt" task_budget: INIT: 5.0 NAVIGATE: 20.0 DETECT: 5.0 MANIPULATE: 10.0 RETURN: 15.0 STOP: 3.0

读取配置时，只要启动时加载一次，然后全局使用。不要在运行时反复读文件，避免 I/O 阻塞影响控制周期。

9.2 建立“基线版本”意识

每轮大改动之前，先确保当前版本能正常运行。把能跑通的版本命名为基线版本，任何验证通过的优化才允许合入。这个方法能避免“改坏了回不去”的尴尬。

9.3 日志和地图单独备份

比赛现场环境往往和实验室不同，赛前一定要重新录制场地地图，不能用旧地图硬跑。地图、日志、模型文件最好用 Git LFS 管理，避免二进制文件撑爆仓库。

9.4 提前演练异常流程

比赛过程中一定会出现意外：识别失败、导航超时、机械臂卡住。这些异常流程如果在赛前没有演练过，现场就会变成“手忙脚乱模式”。

建议赛前准备一份异常处理清单：

1. 机器人静止不动超过 10 秒： - 检查是否陷入状态循环。 - 重启任务调度，回到初始状态。 - 如果无法恢复，手动遥控回安全区。 2. 识别结果置信度低于阈值： - 重新采集一帧图像再试。 - 连续 3 次失败，跳过该目标，执行备用策略。 3. 机械臂抓取失败： - 退回安全位置，重新定位目标位置。 - 尝试二次抓取。 - 二次仍失败，放弃该目标，保证后续任务不受影响。

9.5 电量管理

电池电压对机器人性能的影响比很多人想象中大得多。满电时电机响应敏捷，低电时转速下降明显。建议：

• 在程序里实时监控电池电压。
• 当电压下降到阈值时，降低最大速度，避免“突然失控”。
• 赛前记录满电一轮的基准成绩，电压变化后对比偏差，用于判断是否需要增加补偿。

9.6 团队协作规范

竞赛机器人不是一个人的项目。代码提交前要保证：

• 不将本地绝对路径写进代码。
• 不提交带个人聊天记录的日志文件。
• 修改配置参数时写明 commit message，例如increase detect confidence threshold from 0.5 to 0.55。

这些规范看起来不起眼，却能让你在赛前的关键两小时里，避免“谁动了我的参数”这种内耗争论。

10. 总结与后续进阶方向

从“荣耀机器人元气仔以 48.47 秒的成绩夺得亚军”这个成绩出发，这篇文章真正想讲清楚的是：竞赛机器人跑出好成绩，靠的不是某个灵感，而是一套“时间预算拆解 + 状态机调度 + 运动控制调优 + 数据驱动迭代”的工程方法。

如果你正在准备一项机器人竞赛，建议按这个顺序实践：

1. 先跑通一个最简版本的完整任务，哪怕速度很慢、表现很笨拙。
2. 用时间预算工具记录每个环节的耗时，找到最大的时间黑洞。
3. 针对瓶颈环节做定向优化——提升速度、优化路径、压缩识别时间。
4. 反复训练，记录日志，用数据驱动下一轮优化，而不是凭感觉改参数。
5. 最终目标不是“跑最快”，而是“最稳”。48.47 秒的亚军成绩，稳定性一定优先于极限速度。

后续值得深入的方向包括：

• 将状态机替换为行为树（Behavior Tree）结构，更灵活地应对复杂任务。
• 引入模型预测控制（MPC）替代传统 PID，进一步提升轨迹跟踪精度。
• 使用强化学习在仿真环境中优化速度规划策略，再迁移到实机。
• 构建全自动回放系统，实现每一轮训练的“失败原因自动标注”。

移动机器人竞赛的迷人之处在于：它把软件、硬件、算法、机械结构全部压缩到几十秒内做综合检验。如果你想获得更稳定的成绩，请从时间预算和状态机开始，先让系统“不会崩”，再追求“跑得快”。