归档

2026 年 10 月

2026-10-04

运维与变更 #雨云 #API

雨云 OpenAPI 实操经验：x-api-key 认证、必填的 options 分页参数坑、六条产品线前缀地图，以及释放/续费等危险操作收口。

2026-10-04

运维与变更 #Halo #自动化 #SQLite

为什么用 Halo CLI，而不是直接调 API 这个博客跑在 Halo 上，文章由 AI（老八）代写代发。最开始我让 AI 直接调用 Halo 的 REST API 写文章，结果踩了一连串坑。后来换成 Halo 官方 2026 年 3 月推出的命令行工具 Halo CLI，定位就写着 "Halo

2026 年 09 月

部署、变更登记与已知问题

2026-09-28

运维与变更 #自动化 #SQLite

系统跑在哪、改动怎么管理这篇收尾：系统部署在什么环境、数据怎么备份、代码改动遵循什么流程、目前有哪些已知问题。是整套文档的"运维入口"。部署环境跑在群晖 NAS 上的 Hermes 容器里，用 Python 虚拟环境。数据库是项目目录下的 rideshare.db，是唯一事实源。定时任务用

报告体系：日报、周报、月报与面板

2026-09-17

报告与看板 #看板 #自动化 #统计口径

系统到底给我出哪些报告数据进了数据库、统计层算好之后，结果通过一整套报告送到我面前。不同报告回答不同问题，更新节奏也不一样。这篇把报告体系一次讲清楚。四类报告，各司其职日报：当晚收工看。一晚上到账多少、几单、出门多久、时薪。推送到飞书。周报：每周一中午看。一周汇总，加上变化归因（收入变动来自

数据是怎么进来的：从飞书录入到 SQLite

2026-09-11

数据链路 #飞书 #自动化 #SQLite

数据是怎么一步步进数据库的我只在聊天里用大白话报当天数据，比如"8点半出门，安师傅两单一个35一个28，11点到家"。从这句话到数据稳稳躺在 SQLite 里，中间经过了几步。这篇把这条录入链拆开讲。整条链路我发飞书消息 → Hermes Agent 解析 → add_orders.py 写入

2026 年 08 月

统计与对账基准

2026-08-22

数据链路 #统计口径 #SQLite

为什么要有"对账基准" 改口径、改代码、补录数据之后，怎么确定系统没算错？方法是留一套能反复核对的基准数字：同一批数据，用完全独立的方式再算一遍，结果对得上才放心。这篇讲统计层怎么算、以及怎么做对账。唯一统计层所有统计都在 rideshare_calc.py 里实现，对外提供三个核心函数： da

整体架构与数据流

2026-08-21

总览与背景 #SQLite #自动化 #飞书

一张图看懂整套系统分五层，数据只往一个方向流： ① 录入层 ② 存储层 ③ 统计层 ④ 报告层 ⑤ 展示层我在聊天里 → SQLite → 统一计算 → 日报/周报/ → 飞书消息报当天数据数据库

单一数据真相：飞书、SQLite、表格各管什么

2026-08-20

数据链路 #数据真相 #飞书 #SQLite

为什么要分清楚谁是"真相" 这套系统里数据会出现在好几个地方：我嘴上报的、飞书消息、SQLite 数据库、导出的表格、生成的报告。如果不规定"以谁为准"，很快就会出现数字对不上、改了这边漏了那边的情况。这篇讲清楚每一层各管什么，哪一个才是唯一能信的源头。一句话原则 SQLite 数据库（rides

专题：免佣卡与车辆基金的追踪逻辑

2026-08-14

报告与看板 #统计口径 #数据真相

两个专项追踪：免佣卡和车辆基金除了每天的收入，我还专门追踪两样东西：买的免佣卡到底值不值、按收入攒的车辆基金攒了多少。它们的逻辑和日常收入不太一样，这篇单独讲。先说一个口径区别日常收入按"出勤日"（班次）统计；免佣卡和车辆基金按"订单日期"统计。报告里会注明这个区别。免佣卡本质：花一笔卡费

名词与统计口径表

2026-08-13

总览与背景 #统计口径 #安师傅 #新桔 #高德

这是整套系统里最关键的一篇：每个名词只有一个精确定义，所有脚本、报告、看板都按这里算。出现数字对不上，先回来查口径。归属规则（先定这个）班次：出门那一天（出勤日）就是一个班次。收入、单数、工时、出勤天数全部按班次归属；跨午夜的订单归出门日所在的班次。一个班次完整计入一个月，不再"跨月出勤日两

菜单

归档