为什么要有"对账基准" 改口径、改代码、补录数据之后，怎么确定系统没算错？方法是留一套能反复核对的基准数字：同一批数据，用完全独立的方式再算一遍，结果对得上才放心。这篇讲统计层怎么算、以及怎么做对账。 唯一统计层 所有统计都在 rideshare_calc.py 里实现，对外提供三个核心函数： da
发布于 2026-10-04
数据是怎么一步步进数据库的 我只在聊天里用大白话报当天数据，比如"8点半出门，安师傅两单一个35一个28，11点到家"。从这句话到数据稳稳躺在 SQLite 里，中间经过了几步。这篇把这条录入链拆开讲。 整条链路 我发飞书消息 → Hermes Agent 解析 → add_orders.py 写入
发布于 2026-10-04
为什么用 Halo CLI，而不是直接调 API 这个博客跑在 Halo 上，文章由 AI（老八）代写代发。最开始我让 AI 直接调用 Halo 的 REST API 写文章，结果踩了一连串坑。后来换成 Halo 官方 2026 年 3 月推出的命令行工具 Halo CLI，定位就写着 "Halo
发布于 2026-10-04
为什么要分清楚谁是"真相" 这套系统里数据会出现在好几个地方：我嘴上报的、飞书消息、SQLite 数据库、导出的表格、生成的报告。如果不规定"以谁为准"，很快就会出现数字对不上、改了这边漏了那边的情况。这篇讲清楚每一层各管什么，哪一个才是唯一能信的源头。 一句话原则 SQLite 数据库（rides
发布于 2026-08-20
我是谁，为什么要做这套系统 我是一名代驾司机，收入全部来自三个平台：安师傅、新桔代驾、高德代驾。每天晚上出门，骑电动车或开代步车接单，干到凌晨收工回家。 代驾这行的收入有几个特点： 按单结算、笔数碎：一晚可能跑几单到十几单，每单金额、平台扣费都不一样。 平台规则不透明：同样的流水，扣完保障费、信息费
发布于 2026-08-13
