Blog on Lutong's Homepage

当我们为一台电摩按下刹车，到底发生了什么？——一场关于两轮电动车刹车与打滑的仿真探险

Mon, 22 Jun 2026 15:00:00 +0800

一、为什么要折腾这件事

你大概也有过这样的瞬间：骑着电动车，前面突然窜出一辆外卖车，你一把捏死刹车——晴天还好，要是下过雨，心里咯噔一下，屁股后面那股"滑了一下"的感觉可不好受。

两轮电动车和四轮汽车最大的不同，是它只有两个轮子接地，而且刹车时还会"翘屁股"。前轮一锁死，基本就是直接趴下；后轮一甩，能不能救回来全看反应和运气。那到底什么样的刹车配置最靠谱？雨天和晴天差多少？过弯时还能不能刹车？牵引力控制系统这玩意儿到底神不神？

光靠经验说不清，于是我决定在电脑里造一台"虚拟电摩"，让它替我把各种姿势都摔一遍。

二、我们要搞清楚的"考场"

为了让结论有用，我设计了一个完整的实验矩阵，把以下变量全部排列组合：

三个速度区间：每小时 0 到 25 公里（新国标电动自行车上限）、0 到 35 公里（电轻摩）、0 到 45 公里（电摩）；
三种刹车配置：双碟刹、前碟后鼓、双鼓刹；
两种天气：晴天干燥沥青、雨天湿沥青；
三种工况：直线紧急制动、15 度缓弯中制动、90 度直角弯中制动。

这样一来，光是主场景就有 3×3×2×3 = 54 种组合，再加上刹车力度分配扫描、防抱死制动系统对比、甩尾救车、牵引力控制仿真，这辆车在电脑里少说也摔了上千次。放心，它不疼。

三、给这台虚拟电摩"量体裁衣"

仿真好不好，七分靠参数。我没有瞎拍脑袋，而是按真实电摩的物理尺寸和公开的轮胎摩擦数据来设定，关键是每一项都有出处：

参数	取值	怎么来的
整车质量	140 公斤	车约 70 公斤 + 骑手约 70 公斤
轴距	1.25 米	主流电摩轴距 1.20 到 1.35 米
重心到前轴 / 后轴距离	0.65 / 0.60 米	骑手坐姿偏后，重心略靠后
重心高度	0.60 米	踏板坐姿电摩的典型值
轮径	0.20 米	14 到 17 寸轮
晴天沥青摩擦系数	峰值 0.85 / 滑动 0.72	干沥青轮胎抓地力通用区间
雨天沥青摩擦系数	峰值 0.50 / 滑动 0.38	湿沥青显著下降，事故率随之飙升
碟刹响应时间	0.08 秒	液压碟刹建压快、手感线性
鼓刹响应时间	0.22 秒	机械结构 + 自助力，建压慢、容易突抱

这里有个细节很关键：摩擦系数不是一个定值，而是会随着轮胎打滑程度变化的曲线。轮胎没打滑时抓地力为零（自由滚动不打滑嘛），随着轻微打滑迅速升到峰值，打滑过头又掉到较低的"滑动摩擦"。这正是后面所有"锁死"现象的根源。

Beancount 平行预算插件：当个人记账遇上事业单位平行记账

Sun, 10 May 2026 00:00:00 +0000

从「平行记账」说起

如果你接触过政府会计制度，一定对「平行记账」这个词不陌生。

2019 年起，我国行政事业单位全面实行新政府会计制度，核心变化就是建立 财务会计 与 预算会计 适度分离又相互衔接的「双体系」核算模式。简单说，就是同一笔经济业务，同时从两个维度反映：

财务会计 — 权责发生制，反映单位的资产负债和运行成本
预算会计 — 收付实现制，反映预算收支执行情况

这套模式有个形象的名字叫 平行记账。它在确保财务信息完整性的同时，又能直观看到预算执行进度——钱花到哪了、还剩多少、有没有超支。

什么？你说这是写给事业单位财务人员的，跟个人记账有什么关系？

别急。我在用 Beancount 做个人记账时发现，这种「平行」的思路，恰好能解决个人预算管理中长期困扰我的几个痛点。

Fava 自带预算功能的问题

Beancount 生态中，Fava 是最常用的 Web 前端。它确实自带了一套 budget 指令，但实际用过之后，槽点不少：

1. 不直观，学习成本高

内置的 budget 需要配合 bean-query 特定的查询语法才能看到预算执行情况。这意味着你没法在 Fava 的资产负债表上直接看到预算余额——你得再开一个单独的报表页面，还需要自己拼 BQL。

此外，budget 指令的语法固定，自定义灵活性差，例如只支持固定按照月份或者年为周期进行预算管理，不支持一次性预算或跨周期预算管理。对于装修这种一次性大额、餐饮这种每月定时充值的混合场景，内置 budget 没有一个直观的「周期开始自动充值、过往余额不累积」的展示机制。对于预算分类比较细的用户（比如我有餐饮、交通、购物、装修等多个预算），配置起来繁琐且不易维护。

3. 与账本体系割裂

最让我难受的是——预算信息是「外挂」的，不在标准的复式记账体系内。这意味着预算余额不是账户余额，不能通过 Fava 的账户树直接浏览，只能在Fava的支出页面中的某个子页面察看。没法用 bean-query 做自由查询，也没法和其他账户做交叉分析。

我们的方案：Beancount 平行预算

所以，我想能不能换一种思路——把预算本身做成账本的一部分。

受事业单位平行记账的启发，我开发了 beancount_parallel_budget 插件。核心思想就是：让预算像会计科目一样存在，用复式记账的方式管理预算执行。

账户体系

每一个预算类别，对应三个账户：

Equity:Budget:Expenses:{name} ← 记录该预算下的实际支出
Equity:Budget:Balance:{name} ← 预算余额（周期初=预算额，周期末=剩余）
Equity:Budget:Income:{name} ← 预算收入（周期初调整时的反向账户）

关键逻辑：每个支出交易发生时，插件自动在原有记账分录上追加两条平行分录，将支出金额同步记到 Expenses 和 Balance 账户。这就像一个迷你「预算会计」体系，与你的「财务会计」（即平时的收支记账）并行运作。

AI+Beancount 复式记账个人务实

Sun, 01 Jun 2025 21:30:28 +0800

AI+Beancount 复式记账个人务实

其实大概从本科以来，我一直在使用Beancount这个开源的复式记账工具来进行个人财务管理。但是之前记账实在是太繁琐和麻烦了，经常拖拖拉拉，记个大概。

改变发生在去年年底，从那时候开始，我开始引入大语言模型（LLM）来参与个人记账务实。从此，每个月的支付宝、微信和信用卡账单大概只需要十多分钟的就可以快速地导入进对账单。因此，2025年起我们的记账开始变得详细和完整，账本也更准确地反映出了个人财务状况。如今，我也有一些经验总结，希望做一个回顾和整理。

记账方案的顶层设计——权责发生制还是收付实现制

以往，大多数讲Beancount记账软件的博客通常会从单式记账（Single-entry Bookkeeping)和复式记账（Double-entry Bookkeeping）的区别谈起。但是今天，我想从一个更加深入也更本质的问题来谈起，因为这决定了我们账本的整体设计框架，也就是权责发生制和收付实现制。

简单回顾一下Beancount引入的复式记账，这引入了一个规则就是每一个交易（Transactions）均是由多个条目（Postings）来组成的，代表了资金的来龙去脉。在Beancount中，并非使用会计学中“借贷记账法”，而是简化为使用负数代表资金的来源（即贷方，Credit），正数代表资金的去向（即借方，Debit）。举一个简单的例子，假设你借给小明2000块钱，传统单式记账可能会记录一笔2000元的支出，而复式记账则同时记录这笔资金的从哪里来、到哪里去。：

2025-05-01 * "小明" "借款2000元"
 Assets:Bank:Cash -2000 CNY
 Assets:Receivables:XiaoMing 2000 CNY

这样，这一笔支出并不会记录为一笔支出（Expenses），而是记录为小明的应收账款中的金额。这样，你就知道这2000元并不是你这个月切实的消费，因此并不需要从个人的本月预算中省吃俭用出这2000元。

同样，当下个月小明连本带利归还2200元时，你的记账如下：

2025-06-01 * "小明" "还款2000元"
 Assets:Bank:Cash 2200 CNY
 Income:PnL -200 CNY
 Assets:Receivables:XiaoMing -2000 CNY

这代表着小明还清了钱，同时你的收益和损失收入（Profit & Loss， PnL）账户带来收益200元。因此，这个月你的净收益增加200元，而不是2200元。而你这个月也可以多消费200元（笑）。

从本质上看，Beancount的复式记账提供了更加灵活的记账能力，也因此引入了我们想要讨论的一个核心话题：是使用上面这个例子使用的权责发生制还是收付实现制来记账？让我来说明一下：

任何一个会计学教材都会跟你说，财务报表最重要的三大表是资产负债表（Balance Sheet）、利润表（Income Statement）和现金流量表（Cash Flow Statement），他们的主要特点如下：

资产负债表衡量了一个时刻的所有资产和负债的表格。资产负债表主要考察如下三类财务科目，资产（Assets）、负债（Liabilities）和所有者权利（Equity，或称净资产）。在Beancount中，引入了如下的会计恒等式：资产+负债+净资产=0。值得注意的是，在Beancount中，负债和净资产等贷方账户都使用负数来记账。
利润表衡量了一段时间内的收入、费用和净利润等情况，主要考察了如下两类财务科目支出（Expenses）和收入（Income）。利润表使用的是权责发生制来记录，即在这个交易产生权利和责任的那一天入账（例如发生交易、签订合同等）。假设你租房每个月房租是2000元，三个月一付。按权责发生制，则应该记录为在实际使用房屋的时候（即每个月），产生支付义务的时刻记账：

2025-03-01 * "房租实预缴"
 Assets:Cash -6000 CNY
 Assets:Prepaid 6000 CNY

2025-03-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

2025-04-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

2025-05-01 * "房租(按月发生)"
 Expenses:House 2000 CNY
 Assets:Prepaid -2000 CNY

; 当然，后面会介绍使用beancount-periodic插件更优雅地处理摊销的办法

现金流量表则衡量了一段时间内现金的流入流出情况。和利润表不同的是，现金流量表按照收付实现制来记账的，也就是在资金实际变动的那一天记一次账。上面租房的例子如果按照收付实现制，则应该记录为如下一笔：

2025-03-01 * "房租实缴纳"
 Assets:Cash -6000 CNY
 Expenses:House 6000 CNY

显然，权责发生制和收付实现制各有所长。从上面这个例子可以看出，权责发生制更容易方便我们进行中期和长期的个人财务管理。比如，将房租消费摊销到每一个月之后，你就清楚地看到每个月房租支出2000元。因此每个月的预算可能需要扣除这2000元。同时，基于收付实现制的现金流量表也同样重要，可以用于展示个人短期的现金压力。比如，当你身上只有7000元现金的时候，一次性支付6000元房租也势必会对个人现金流产生极大压力。

小米 10 手机的拍照体验

Wed, 15 Jul 2020 09:06:35 +0800

小米 10 （非 pro）手机拍照体验

自从 iPhone 出了故障送回家修了之后，我就入手了一部【小米 10】手机。通过这段时间的体验，对他的拍照性能算是有了一些了解吧。

首先要申明的是小米 10 并非是拍照手机，相机的硬件配置并不强，有一个一亿像素的广角镜头、一个 1300 万像素的超广角镜头，以及两百万像素的景深镜头和两百万像素的微距镜头。的确，从硬件配置上来说小米 10 的相机硬件参数是普普通通的，甚至算不上的是优秀。

一亿像素主摄超强

一亿像素的主摄广角镜头是非常强悍的，拍照非常清晰，画质也不错。它配合景深镜头可以实现非常良好的浅景深和人像模式。小米 10 手机的拍照速度并不快，拍照的时候只要记得端平、端稳，可以获得非常不错的画面哦。

主摄像 f1.7 的通光量在夜晚也勉强能够一战，当然首先于镜头传感器尺寸的影响，和我的单反相机以及华为手机等还是有一定差距的。

很行的超广角和不怎么行的长焦

小米 10 自带一个 1300 万像素的超广角镜头，如果构图合适，往往可以拍出非常惊艳的画面，画质也是不错了。

首先从变焦讲起，小米 10 手机由于不带长焦镜头，它的变焦只有 10 倍的数码变焦，也就是裁切。好在是从一亿像素里做裁切，放大倍率不大的时候画质还是勉强能用的。对于我来说，如果不是确有必要记录远处的内容的，我可能不会使用数码变焦的功能，而是选择后期进行二次构图。

真假微距镜头

小米 10 的主摄像头的最近对焦距离其实非常近，所以一般情况直接使用主摄拍摄静物小品和食物就可以取得非常不错的画面效果。这一点是出乎我的意外的。下面是样张：

另外小米 10 还附带了一个 200 万像素的微距镜头。它的对焦距离几乎不存在，可以拍摄非常非常近的物体的细节。当然，仅仅是【拍得到】，200 万像素真的涂抹感是有点严重了，需要拍摄的构图合理和光线充足，才拍出不错的照片。

MIUI 12 的拍照软件和算法

手机摄影很多程度上是靠软件和算法来弥补硬件的不错，也不失为一条非常有前景的发展道路。因此手机软件和算法就非常重要了。总体来说，MIUI12 的拍照软件还是非常让我满意的。

从渲染偏好上，MIUI 相机的色彩是偏向艳丽的，看起来非常讨喜。对于我来说，有时候反而需要降一点饱和度。但是总体调教风格我还是比较喜欢的。小米

但是有一个槽点是：不知道是不是算法的原因，我一直感觉 MIUI 拍摄的照片的曝光并不准确，通常是偏暗了 0.3EV - 1EV ，经常需要我手动去拉高亮度。

另一个槽点就是有时候默认的景深太浅了，非常不合时宜，你也没有快速的方式去调整。只有两个选择：1. 打开专业模式去手动调整参数设置。 2. 启动 AI 模式，如果 AI 识别是风景，则会调整景深和对焦。

Blog on Lutong's Homepage

当我们为一台电摩按下刹车，到底发生了什么？——一场关于两轮电动车刹车与打滑的仿真探险

一、为什么要折腾这件事

二、我们要搞清楚的"考场"

三、给这台虚拟电摩"量体裁衣"

Beancount 平行预算插件：当个人记账遇上事业单位平行记账

从「平行记账」说起

Fava 自带预算功能的问题

1. 不直观，学习成本高

3. 与账本体系割裂

我们的方案：Beancount 平行预算

账户体系

AI+Beancount 复式记账个人务实

AI+Beancount 复式记账个人务实

记账方案的顶层设计——权责发生制还是收付实现制

小米 10 手机的拍照体验

小米 10 （非 pro） 手机拍照体验

一亿像素主摄超强

很行的超广角和不怎么行的长焦

真假微距镜头

MIUI 12 的拍照软件和算法

小米 10 （非 pro）手机拍照体验