网约车司机工作日志数据采集与复盘系统搭建

“啊僵跑网约车的一天”这个标题，听起来像随手拍的 Vlog，但放在技术博客里，它可以是一个非常完整的实践项目：把司机从出车到收车的全天行为，拆成接单、路线、等待、收入、驾驶习惯、车辆状态几个维度，再做数据采集、本地分析、可视化复盘。这篇文章不谈平台规则，也不讨论行业争议，只讲怎么用工程手段把一个司机的工作日记录下来，并做成一整套可复用的数据复盘系统。

项目本身不需要太高的硬件门槛，一台手机、一个车载 OBD 蓝牙模块、一台能跑 Python 的电脑就能起步。更关键的是，这套思路可以复用：订单记录转结构化数据、GPS 轨迹聚类、时段收入分析、异常驾驶检测，每一块都能单独拆出来做工具。如果你正在做数据采集类工具、LBS 应用，或者只是想把日常工作过程量化，这篇内容可以直接照着落地。

文章会按完整的执行链路展开：先给核心能力速览，再讲合规边界和数据采集的硬件准备，然后是本地部署、启动方式、功能测试流程，最后补上 API 调用、批量导出、性能观察和常见问题排查。涉及平台数据和用户隐私的部分，全部按“本地记录、脱敏处理、授权使用”的原则处理，不抓取任何非授权数据。

1. 核心能力速览

从材料看，这个项目最值得尝试的点在于“把一天跑车过程变成结构化数据”。不是单纯记录里程和收入，而是把时间轴、地理位置、接单状态、驾驶行为组合到一起，形成一份可查询、可对比、可回溯的工作日志。

2. 适用场景与使用边界

这类记录工具适合以下人群：

• 网约车司机：想了解自己一天中哪个时段效率最高、哪片区域空驶率低。
• 出行行业运营人员：做司机行为分析需求梳理时，先本地搭建一套数据模型。
• 数据分析学习者：用真实采集逻辑练手，理解 GPS 数据处理、时间序列聚合、轨迹可视化。
• 车主：想通过 OBD 数据观察车辆状态和驾驶习惯。

能解决的问题集中在这几个方面：

• 收入与出车时长的真实关系。单纯看流水不够，需要把接单时间、等待时间、行驶时间分开统计。
• 空驶率分析。通过 GPS 轨迹和订单标记位置，可以算出两个订单之间的空跑距离。
• 驾驶行为画像。急加速、急刹车、超速次数，这些都能从 OBD 或手机传感器数据里提取。
• 路线回放。把当天的轨迹渲染在地图上，按时间轴拖拽，可以复盘每一段的决策。

但使用边界也必须说清楚。第一，不要采集乘客信息，车内录音录像必须符合当地法律法规，并且获得明确授权。第二，平台订单数据只能处理本人账号下的记录，不能爬取其他司机或平台的私有数据。第三，OBD 数据仅用于自有车辆的行驶状态分析，不能用于收集他人车辆信息。第四，合规地讲，如果你要对驾驶行为做商业分析，需要满足数据合规要求，这类项目更多作为个人学习、个人复盘或团队内部管理工具使用，发布前需要做完整的隐私评估和脱敏处理。

3. 环境准备与前置条件

整套系统跑在本地，不需要云端服务器。建议准备一台 Windows 或 Linux 电脑作为数据处理端，手机端只负责定时上报位置和记录订单信息。

3.1 硬件清单

如果暂时没有 OBD 模块，可以直接用手机 GPS 完成第一版。OBD 数据能做更精确的驾驶行为分析，但初期不是必需项。

3.2 软件环境

通用依赖清单如下，实际版本需要根据本机环境确认：

# 建议使用 Python 虚拟环境 python -m venv driver_env source driver_env/bin/activate # Windows 下使用 driver_env\Scripts\activate # 安装基础依赖 pip install pandas sqlalchemy folium geopy openpyxl # 可选：OCR 解析订单截图 pip install paddleocr paddlepaddle

如果你用的是 Windows，建议安装 Python 3.9 以上版本，并在安装时勾选“Add Python to PATH”。Linux 服务器则直接通过 apt 或 yum 安装 Python3-pip。

3.3 目录结构与数据分区

项目启动前先建好目录，避免后续数据混乱：

drivers_day/ ├── config/ │ └── settings.yaml ├── data/ │ ├── raw/ # 原始 GPS 日志、截图、OBD 数据 │ ├── processed/ # 清洗后的结构化数据 │ └── output/ # 日报、图表、导出文件 ├── scripts/ │ ├── collect_gps.py │ ├── parse_orders.py │ ├── analyze_day.py │ └── export_report.py └── requirements.txt

数据分区的基本原则是：原始数据只读，处理结果单独存放，输出文件不污染源数据。这个习惯在个人项目里看似多余，但一旦要跑批量任务，目录混乱会直接导致数据覆盖或重复统计。

4. 本地部署与启动方式

项目的核心启动方式是命令行脚本。没有复杂的一键安装包，好处是每一步都可以单独验证，出了问题能定位到具体模块。

4.1 读取与清洗 GPS 数据

手机端可以用第三方 GPS Logger 应用导出 KML/GPX 文件，也可以自己写采集脚本通过 Android 的定位权限定时记录。这里给一个 Python 读取 GPX 的通用模板：

import gpxpy import pandas as pd def parse_gpx(file_path): with open(file_path, 'r', encoding='utf-8') as f: gpx = gpxpy.parse(f) points = [] for track in gpx.tracks: for segment in track.segments: for point in segment.points: points.append({ 'time': point.time, 'lat': point.latitude, 'lon': point.longitude, 'ele': point.elevation }) return pd.DataFrame(points) if __name__ == "__main__": df = parse_gpx("data/raw/day_20250101.gpx") df.to_csv("data/processed/gps_20250101.csv", index=False) print(f"解析完成，共 {len(df)} 个轨迹点")

这段代码解决的是把手机导出的轨迹文件转成 DataFrame 的问题。如果文本里缺少时间字段，后期做速度计算和里程聚合会非常麻烦，所以原始格式里一定要有时间戳。

4.2 订单记录转为结构化数据

订单记录最常见的形式是平台截图。处理路线是：截图统一放入data/raw/screenshots/，再用 OCR 识别关键字段，最后写入 SQLite。

import sqlite3 import pandas as pd from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang='ch', show_log=False) def parse_screenshot(image_path): result = ocr.ocr(image_path, cls=True) text = " ".join([line[1][0] for line in result[0]]) return text def create_db(): conn = sqlite3.connect('data/processed/drivers_day.db') conn.execute(''' CREATE TABLE IF NOT EXISTS orders ( id INTEGER PRIMARY KEY AUTOINCREMENT, order_time TEXT, pickup_location TEXT, dropoff_location TEXT, amount REAL, distance_km REAL, raw_text TEXT ) ''') conn.commit() return conn conn = create_db() sample_text = parse_screenshot("data/raw/screenshots/order_001.png") print("OCR 识别结果：", sample_text)

注意，OCR 识别出来的字段是不规则的。文字里可能同时包含“订单时间”“行程费用”“支付方式”，需要针对实际截图做正则或规则匹配，不要指望一次解析成功。建议先做 5 到 10 张截图的小样本验证，识别稳定后再批量处理。

4.3 一键生成当日日报

日报生成脚本负责把当天的 GPS 数据和订单数据合并，输出一个 Markdown 日报文件，方便在手机上阅读。

python scripts/analyze_day.py --date 2025-01-01

脚本内部逻辑大致是：读取当日订单表、计算总流水、统计出车时长、按小时聚合订单数、计算空驶里程，最后生成日报。如果你有 OBD 数据，还可以额外输出急加速、急刹车次数。

5. 功能测试与效果验证

部署完成之后，不要急着跑正式数据，先用一套假数据或少量真实数据做验证。以下每个功能都要能单独通过测试，才算整体跑通。

5.1 GPS 轨迹解析测试

测试目的：确认 GPX/KML 文件能正确解析，并且时间顺序正确。

• 输入：一段 10 分钟的驾车轨迹 GPX 文件。
• 操作：运行parse_gpx.py。
• 预期结果：终端输出解析点数，CSV 文件中时间字段连续且递增。
• 判断标准：轨迹点数量与 GPS Logger 显示一致。
• 常见失败原因：文件编码不是 UTF-8，或者时间字段缺失导致解析报错。

5.2 订单截图 OCR 测试

测试目的：验证截图里的金额、时间、起终点能被正确识别。

• 输入：一张清晰订单截图。
• 操作：运行parse_screenshot()函数。
• 预期结果：文本输出包含订单号和费用信息。
• 判断标准：金额字段与截图保持一致。
• 常见失败原因：截图分辨率过低、文字被遮挡、APP 界面改版导致模板变化。

5.3 收入时段分布测试

测试目的：验证按小时聚合的统计逻辑。

• 输入：20 条模拟订单，分布在早高峰、午间、晚高峰。
• 操作：运行analyze_day.py --date 2025-01-01。
• 预期结果：日报中的时段统计出现三个峰值。
• 判断标准：峰值时段和模拟数据一致。
• 常见失败原因：订单时间字段解析格式不一致，比如“01-01 08:30”和“2025/01/01 08:30”混用。

5.4 轨迹热力图渲染测试

测试目的：验证 GPS 点能否叠加到地图上，形成区域热力图。

• 输入：一天 1000 个 GPS 点。
• 操作：使用 Folium 生成 HTML 地图。

import folium df = pd.read_csv("data/processed/gps_20250101.csv") center_lat = df["lat"].mean() center_lon = df["lon"].mean() m = folium.Map(location=[center_lat, center_lon], zoom_start=12) points = [[row["lat"], row["lon"]] for _, row in df.iterrows()] folium.PolyLine(points, color="blue", weight=3, opacity=0.6).add_to(m) m.save("data/output/track_20250101.html")

• 预期结果：浏览器打开 HTML 文件，能看到完整行驶轨迹线。
• 判断标准：轨迹与真实路线基本吻合，没有明显漂移点。
• 常见失败原因：GPS 漂移产生严重离群点，需要先做坐标过滤。

5.5 空驶里程计算测试

测试目的：验证相邻订单之间的空驶距离计算是否合理。

• 操作：从订单表中取出连续两条订单，用两个终点/起点之间距离做直线估算。
• 预期结果：输出空驶距离，单位公里。
• 判断标准：与地图实际路线距离有一定差距，但数量级应接近。
• 常见失败原因：道路距离远大于直线距离，建议后续接入地图路线 API 做更精确计算。

6. 接口 API 与批量任务

当脚本能够稳定产出数据后，可以把本地数据封装成 HTTP 接口，方便对接小程序的司机端或者内部报表系统。这里给出一个基于 Flask 的通用 API 模板，实际路由和字段需要按自己的数据库结构调整。

from flask import Flask, jsonify, request import sqlite3 import pandas as pd app = Flask(__name__) DB_PATH = "data/processed/drivers_day.db" def query_db(sql, params=()): conn = sqlite3.connect(DB_PATH) df = pd.read_sql_query(sql, conn, params=params) conn.close() return df @app.route("/api/orders", methods=["GET"]) def get_orders(): date = request.args.get("date") if not date: return jsonify({"error": "missing date parameter"}), 400 df = query_db( "SELECT * FROM orders WHERE order_time LIKE ?", (f"{date}%",) ) return jsonify(df.to_dict(orient="records")) @app.route("/api/summary", methods=["GET"]) def get_summary(): date = request.args.get("date") df = query_db( "SELECT order_time, amount, distance_km FROM orders WHERE order_time LIKE ?", (f"{date}%",) ) if df.empty: return jsonify({"total_amount": 0, "total_distance": 0, "order_count": 0}) return jsonify({ "total_amount": round(df["amount"].sum(), 2), "total_distance": round(df["distance_km"].sum(), 2), "order_count": len(df) }) if __name__ == "__main__": app.run(host="127.0.0.1", port=8000)

启动接口服务：

python scripts/api_server.py

然后可以在浏览器或命令行里测试：

curl "http://127.0.0.1:8000/api/summary?date=2025-01-01"

如果你的数据库里没有当天的数据，接口返回全零；如果有数据，会返回总流水、总里程和订单数。接口只监听127.0.0.1，避免暴露到局域网。如果后续要对接其他设备，建议先加一层 Token 校验，再开放端口。

批量任务方面，主要场景是把一个目录下的所有订单截图一次性解析：

python scripts/parse_orders.py --input data/raw/screenshots/ --output data/processed/orders.csv

脚本里需要加入失败重试逻辑。OCR 偶尔会识别失败，尤其是夜间模式截图或者拍摄角度倾斜的情况。建议记录失败文件名，第二轮只处理失败项，不要每次全量跑。

import os import time failed = [] for filename in os.listdir(input_dir): if not filename.endswith(('.png', '.jpg', '.jpeg')): continue try: result = parse_screenshot(os.path.join(input_dir, filename)) if not result: failed.append(filename) except Exception as e: print(f"处理失败: {filename} - {e}") failed.append(filename) time.sleep(0.5) print(f"完成，失败 {len(failed)} 个文件: {failed}")

7. 资源占用与性能观察

整套系统跑在本地，性能压力主要来自三个地方：

7.1 OCR 识别内存

PaddleOCR 在 CPU 模式下处理单张截图，内存占用相对偏高，通常会达到 1GB 到 2GB。如果你在旧电脑上跑几十张截图，建议关掉其他大型应用，或者降低图片分辨率。更稳妥的方式是先对截图做预处理：压缩到宽度 1600 像素以内、转成灰度、增强对比度，这样识别速度会明显提升。

7.2 GPS 轨迹数据量

一天的 GPS 点数量，取决于手机的记录频率。如果每 5 秒记录一次，一天开 8 小时车，大约产生 5760 个点。这个规模在 Pandas 里处理毫无压力。但如果记录频率改成每秒一次，或者连续记录了几个月，单次加载所有数据就会变慢。建议按月份分文件存储，分析时只读取指定日期范围。

7.3 地图渲染性能

Folium 生成的 HTML 地图本质上是 Leaflet 页面，打开时由浏览器渲染。几千个点的轨迹没问题，但热力图和多个图层叠加后，低配笔记本可能明显卡顿。可以把点抽稀，比如每 10 个点取一个，地图渲染流畅度会好很多，对轨迹整体形状影响不大。

显存占用方面，这个项目基本不涉及 GPU 推理，除非你想用本地 OCR 模型做大批量识别。PaddleOCR 支持 GPU 加速，可在 NVIDIA 显卡上跑，显存占用通常在 2GB 到 4GB，但 CPU 模式对这个量级完全够用。没有独显的机器也可以正常运行，这是这套方案适合大多数人的原因。

8. 常见问题与排查方法

最重要的是：不要一上来就处理大量真实数据。先拿 3 到 5 条验证链路，再开放批量入口。日志是排查问题的关键，每个脚本启动时先输出当前处理文件名和原始文本摘要，这样即使中途失败，也能定位到具体环节。

9. 最佳实践与使用建议

做了几轮完整流程之后，我建议你把这套思路固定成一套稳定的日常流程：

第一，原始素材按日期归档。截图、GPX 文件、OBD 日志分别放三个子目录，文件名统一带上日期，例如screenshot_20250101_0805.png。这样做的好处是后续做数据回溯时，不需要打开图片才知道是哪一天的内容。

第二，建立一个最小可运行配置。把常用的城市、默认出车时间、订单金额字段的正则表达式写进config/settings.yaml，避免每次重复修改代码。

city: "上海市" default_start_hour: 6 default_end_hour: 22 ocr: lang: "ch" use_gpu: false database: path: "data/processed/drivers_day.db"

第三，生成报告前先做数据质量检查。重点检查三件事：订单时间是否在出车时间段内、金额是否大于零、GPS 坐标是否在城市范围内。有一个环节不通过，就标记为可疑数据，不要直接进入统计。

第四，接口服务默认绑定127.0.0.1，并限制请求频率。如果要对外开放，必须增加 Token 认证。接口返回值要带code和message字段，方便对接端判断失败原因。

第五，合规边界。涉及人脸、车辆识别、乘客对话的素材一律不采集，本工具只记录司机本人可公开的轨迹和订单统计信息。如要给第三方使用，所有数据必须先脱敏，起终点只保留到行政区级别，不保留精确经纬度。

第六，发布或商用前做效果复核。日报里的“总流水”要和平台账单交叉验证，轨迹里程要和车辆仪表盘里程对照，误差超过 10% 就应该检查计算逻辑。自动驾驶和驾驶行为数据同样需要谨慎处理，这类数据可能涉及车辆安全和个人隐私，不能随意公开。

10. 总结与下一步

“啊僵跑网约车的一天”这个项目，真正值得做的不是做一个网约车记录软件，而是通过这个具体场景，把一条完整的数据链路学会：原始数据采集、清洗、结构化存储、聚合分析、可视化展示、接口服务、批量任务。这套流程放到任何行业数据项目里都能复用。

如果要从零起步，建议先用手机 GPS 记录一天真实轨迹，再用模拟订单数据做日报生成。第一版跑通后，再逐步加入OCR 解析、空驶率计算、地图热力图和接口服务。最容易踩的坑是 OCR 识别不稳定，以及 GPS 漂移点污染统计结果，这两项务必先做小样本验证。

后续可以扩展的方向很多：接入高德或百度地图路线 API，把直线空驶距离换成真实道路距离；把日报改成定时任务，每天凌晨自动生成前一天的复盘；加入多司机对比分析，用于车队内部管理；或者把轨迹数据做成 Web 端时间轴回放，提升驾驶过程的可读性。建议先把当日日报跑通，再按自己的需求逐步加模块。这个项目不依赖高端硬件，反而很依赖数据处理习惯和数据规范意识，适合作为个人数据工程练手项目，也可以作为出行领域内部工具的原型参考。