用 Halo CLI 让 AI 管理博客：踩坑与实践

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

发布于 2026-10-04

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

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

发布于 2026-09-11

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

发布于 2026-08-22

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

发布于 2026-08-21

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

发布于 2026-08-20

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

发布于 2026-08-13

我是谁，为什么要做这套系统我是一名代驾司机，收入全部来自三个平台：安师傅、新桔代驾、高德代驾。每天晚上出门，骑电动车或开代步车接单，干到凌晨收工回家。代驾这行的收入有几个特点：按单结算、笔数碎：一晚可能跑几单到十几单，每单金额、平台扣费都不一样。平台规则不透明：同样的流水，扣完保障费、信息费

发布于 2026-08-13