去年十月，我买了一块米家智能温湿度计3。到手之后却发现，时间竟会倒着走。拍视频给售后确认了之后，直接退了款，让我自己再下单一个。

新的很好，功能也正常。旧的售后也没要回去。那旧的怎么办？撇了？核心功能温湿度又没坏，所以我把它放在了我的桌前。时间嘛，电脑、手机、手表，哪个不能看。

不过看温湿度的时候，总是会注意到时间。看久了居然也看出了规律来。十分钟一循环。设定时间后，过了十分钟，就会又回到设定的时间。如果设定的时间刚好要在十分钟内跨小时，那么它将会在跨小时的时候重置，连十分钟都不到。我想办法让自己忽略时间，并关掉了星期显示，希望能让它不那么惹眼。

但看多了总觉得膈应。温湿度计的生命只有十分钟，我要给它完整的一生。起初，我以为是出厂固件的问题，但是升级、重刷都没有用。于是我想试试第三方的固件，看看能不能解决。

二

ATC_MiThermometer是一个BLE温度计的自定义固件，适配基于Telink芯片组的小米温湿度计和其他的一些设备，并且还有个Telink Flasher，基于Web Bluetooth，可以在线配置和刷机。

我没想到这么个小玩意还有人在折腾，于是满怀期待地刷了进去。

天啊！它活过了第一个十分钟，时间在十分钟之后依然在走！

看来问题就这么轻易地解决了，官方固件确实有问题。在第三方固件的加持下，甚至还更省电。这位温湿度计能安心地当它的摆件了。

三

好景不长，事与愿违。温湿度计还是难逃循环的命运。过了半个小时，我发现时钟又重置回了我设定的时刻。是不是这台机器的内存有问题，让它记录不了走过的这么长时间？

我把记录温湿度的间隔调长，最多记录的条数减到最少，希冀着它能走过更久的时间。上天似乎回应了我的愿望，温湿度计的时钟走过了半个小时，走过了四十五分钟，最终，倒在了整点之前。

整点似乎是个坚固的魔障，每当温湿度计的时钟想要跨越它，都会被无情地弹回上次同步的时刻。我取回温湿度计的记录，一次又一次跨越整点的尝试织成了一张紧密的网，似乎揭示着这温湿度计在一次次循环中沉沦的命运。

算了，我尽力了。我想。以后个隔三差五同步一下时间吧。但是，我亲爱的朋友，你知道的，隔三差五最终总是意味着永远。

直到昨天，我的温湿度计还困在2025年的十二月，没能走出那个冬天。

四

阴雨连绵，这两天空气潮湿得让我以为回到了南方。我的注意力又频繁回到了温湿度计上，为我的烦躁寻求一份解释。

我自然注意到了时间， 2025年十二月，那是我最后一次想起来给温湿度计同步的时间，距今已有将近半年。

好奇心又一次被勾起。我想知道这到底是怎么一回事，为什么时间会循环走不出整点，以及能不能修复。

米家温湿度计3 / MJWSD05MMC的主控是Telink TLSR8250，可以软件计时。除此之外，它还有一个单独的RTC时钟芯片AT85163T (PCF85163) 来提供更准确的时间。

平时，主控会用自己的软件时间驱动LCD显示，在屏幕上展示具体的时间。每隔一段时间，主控就会从RTC读取更准确的时间来矫正自身，从而让显示的时间更加精准，同时降低功耗。而这个从RTC同步准确时间的间隔，在官方固件上是十分钟，在pvvx的固件上是每整小时。

对上了，都对上了。看起来是这块RTC芯片出了问题。

在ChatGPT的协助下，我打开了nRF Connect。这是之前用AppleJuice整蛊使用iPhone的朋友时下载的，没想到还能派上正经用场。

利用pvvx固件暴露的BLE调试命令扫I²C总线。按照文档，我在私有服务0x1F10中的特征0x1F1F下发送了命令0x03，并且得到了返回通知(0x) 03-7C-88-A2。其中03是命令号，后边的就是I²C设备地址了。

0xA2就是RTC的地址，说明他还能在总线上ACK确认。问题出在RTC的内部。

进一步，发送04-01-10-A2-00-00读RTC的16个字节，得到04-01-A2-08-1F-FF-7F-3F-3F-07-9F-FF-FF-BF-BF-87-83-87-FF。

其中第四个08，也就是从RTC读出的第一个 (0x00) 字节，是Control_1，代表着RTC的状态，按照PCF85163的定义，似乎是正常的。紧跟着下一位的Control_2则是1F，AF、TF、AIE、TIE全被点亮，意味着告警和定时器中断。

再往后，FF这一位就是秒了，最高位的VL被置位，表示芯片经历过电压跌落，所记的时间已经不可信。后边的分、时、日之类的也全是非法BCD。

如果运气好的话，把它覆写成正常的值就能让RTC恢复正常。可惜我的运气并不好。覆写成正常值之后半天没有动静，还是原来写入的时间。后来试了很多次，扣电池、短接、重置。除了Control变回了报错值之外，时种一秒也没有走。

排查到这里整件事就已经很明朗了：可能由于时钟源晶振坏了或者缺焊，导致RTC的计时震荡或者计数坏掉了，但自检却没发现，让时钟一直停在最后写入的值。而主控会按照设定好的时间间隔，从RTC读取这个固定的值，所以才会时间循环，一直重置到上次同步的时间。

五

知道问题了就好对症下药，把主控从RTC读精确时间这一行为改掉了就行。遗憾的是，似乎不能直接从软件上把RTC直接断电，不然还能更省电。

在Claude的协助下，我Clone了pvvx固件的源码。起初，我们以为把RTC从I²C上屏蔽掉就可以了：

rtc_pcf85163.ccvoid init_rtc(void) {
    (void) rtc_init_b1;
    (void) rtc_init_b2;
    rtc_i2c_addr = 0;
    utime_to_rtc(wrk.utc_time_sec, &rtc);
}
...
u32 rtc_get_utime(void) {
    utime_to_rtc(wrk.utc_time_sec, &rtc);
    return wrk.utc_time_sec;
}

但神奇的是，由于主控会在每跨小时的时候从RTC读取时间，所以主控计算时间时压根就没考虑过小时进位，还是会每跨小时就循环。所以还得把小时进位给加上：

app.cc#if (DEV_SERVICES & SERVICE_HARD_CLOCK)
    u8 prev_min = rtc.minutes;
    utime_to_rtc(wrk.utc_time_sec, &rtc);
    if(rtc.minutes != prev_min)
        SET_LCD_UPDATE();
#endif

找个Linux环境编译好，用Telink Flasher给刷进去。

现在，这台温湿度计终于走出了循环的魔沼，向着未来一去不复返。而我也拥有了一台虽然走时不太准，但是也能看的温湿度计。可喜可贺。●

• 食谱来自简简厨房，有所改良。

• 低温慢烤有助于将肥肉中的油烤出，使其软糯不腻。

• 本食谱中出现所有的糖，如白砂糖、蜂蜜、麦芽糖等，均可用等量的木糖醇或赤藓糖醇替代。

• 如果你觉得还不够味，可以考虑在剩余的叉烧酱中加入适量蜂蜜或麦芽糖，熬至浓稠，淋在切好的肉片上。

步骤

1. 五花肉去皮，切成约15 cm长的条；

2. 如果你不确定你的猪肉是否新鲜，则加入小苏打，加水浸泡半小时；

3. 将所有叉烧酱的原料混合均匀；

4. 将猪肉取出，清洗沥干，擦干表面水分，加入叉烧酱，抓拌均匀，放入冰箱腌制一夜；

5. 将肉放在烤网上，刷一层叉烧酱，下垫烤盘用于接油，放入烤箱，120°C烤一个小时；

6. 翻面，刷叉烧酱，180°C烤约15分钟，直至表面焦褐到你想要的程度；

7. 取出、切片、吃。

享用！●

「web 2.0时代，人人都会有自己的个人主页。」如果你经历过那个年代，那么肯定会对那个万物竞发的景象印象深刻：懂点技术的都在折腾自己的博客，而不懂技术的，也要在QQ空间之类的地方装装点点，玩出花来。

作为「数字原住民」的我也被这盛况感动，思忖着，想在这广袤的互联网空间开辟一块属于自己的地方。

但也只是想想。等我真正拥有了自己的电脑的时候，主流操作系统从Windows XP变成了Windows 7，IE也被Chrome替代。那股人人搭博客的热情也消散得差不多，大家又回到了贴吧、天涯，图的是人多热闹。

但论坛的黄金期也没撑过几年。微博、B站快速成为主流，快手、抖音崭露头角。「人人都有个人主页」的预言的确实现了，只是依附在各个社交平台上。

这很好，每个人都能输出内容，每个人都能被看见。但裹挟在爆炸信息中的我突然想到：我在这片互联网上还是没有一个真正属于自己的地方。

瓜田不纳履，李下不整冠。每个平台有每个平台的规矩与限制。我发现我还是想要一个自己的网站，不寄人篱下，受制于人。

二

博客是个人网站最常见的形式。我也了解到了GitHub Pages的存在。Jekyll的主题挑花了眼，配置文档慢慢才琢磨透。输入属于自己的github.io网址，看着顶上大片的蓝绿色渐变，兴奋之余，我却觉得，这还不是我想要的。

我想要的究竟是什么？

我在画图上画，在Illustrator上画，在Figma上画。工具换了一轮又一轮，设计稿攒了一版又一版。

外界的趋势也在变：从分页到无限滚动，从网格到瀑布流。我跟着潮流走了一圈，却转身看向了纸。

是第一代的Material Design提醒了我这一点。它把纸与墨、层次与留白重新带回了屏幕，几乎可以与Apple的人机界面指南分庭抗礼，证明了纸上的排版智慧在屏幕上依然成立。

屏幕越来越大，但为了阅读舒适，网页的行长却缩得越来越窄，在屏幕两侧留下了越来越大的空间。两侧要么空着，要么被目录、作者简介等别的信息填满。

纸媒是怎么处理宽版面的？人们在纸上排版了上千年，这个问题早就有了成熟的答案。看看大开本的报纸、书刊、杂志，答案很明显：分栏。

剩下的则水到渠成。屏幕是横的，分栏也是横着分，横向滚动似乎是一件再自然不过的事情。设计稿画出来了，效果很好。我踌躇满志，决定把这设计给实现。

三

这时，静态博客生成器已经很成熟了。我选择了Hexo，生态齐全、部署到GitHub Pages上也方便。唯一的不足是我对前端三件套：HTML、CSS以及JS没有任何了解。

所幸前端很容易上手。而Hexo又把网站结构以及Markdown渲染之类的东西都封装好了，我只需要照猫画虎、按图索骥，把主题写好就行。我一边看菜鸟教程，一边把学到的东西转换成EJS和Stylus。导航栏、文章卡片，网站的整体框架很快就搭建了起来。

现代网页工具终究还是为竖向滚动服务的。当实现到文章页时，这个问题就完全暴露了出来。在CSS中，column-width与column-count所定义的数值都是「理想的」，浏览器会根据容器和窗口大小重新计算。在纵向滚动时，这个特性很方便。在横向滚动上，却成为了很大的阻碍。

基于「行长为字号的整数倍」的原则，我将行长设为了24个字，也就是24em。固定行长也带来了一个意外的收获：我开始像排印刷品一样处理中西文混排，调整用词，避免两端对齐拉出难看的大段空白。我甚至考虑起孤行、孤字。这是以前纸上才会有的体验。

然而，浏览器会自动将栏宽和栏数设定为屏幕刚好能装下。这与我的需求相悖，还完美避开了露出半栏内容，提示用户滚动方向的可能。

我找到了一个邪门的方法：在column内再套一层，在里边定死宽度。这是个未定义行为，在所有的浏览器内核上，分栏的整体宽度都会测量失败，导致栏后边与其他元素重叠。但这是我找到的唯一方法。

最大的问题解决了，我很快定义完了Markdown元素的样式，搭建好了其他几个页面，博客建成近在眼前。

一些朋友告诉我Hexo有点过时了。这在我写的时候就已经察觉到了：EJS很笨重、模板年久失修、没有组件化概念、资源管线老旧。我经常要使用一些很脏的办法来修改一些功能，也有一些地方很难自定义。

我是一个逐新的人，我希望我刚写出来的网站至少用的不是现在就已经过时的技术，因为我将来还要数以年计地维护这个网站。

我转向了Svelte，单文件组件、响应式赋值、作用域样式——之前在Hexo里要绕着弯才能做到的事，在这里都是理所应当。

但是Svelte不是静态博客生成器。它是一整个前端组件框架，没有现成的路由、也不管Markdown渲染。这意味着我在享受摆脱Hexo的自由时， 要亲自负责它之前接管的脏活累活。

由于其他事务缠身，我没有很多的精力投入去学习这一崭新的领域。我也急于求成，只想调整视觉效果，不想干这些背后的活计。进展越来越慢，最终搁置。

四

这一放就是一整年。期间我无数次想捡起来，却怯于背后要投入的精力。直到vibe coding爆火，我半信半疑，想找个项目试试。

我立即想到搁置的博客。

导入项目，看着之前半成品繁杂的文件，我手足无措，似乎回到了刚下载好Hexo模版的时候。即便有了LLM做帮手，我还是不知道该让它做什么。

我想了想，试着在对话框中输入：「我现在对这个项目毫无头绪，你能看看我接下来应该做什么吗？」

它读了半天文件，又想了一会，开始输出。把我积压一堆的事情抽丝剥茧，排列得井然有序。也刚好，我的前端水平处在写不出来，但能看懂的位置。我一边感叹时代进步，一边审查LLM写的代码。

接下来的事情就容易多了。如果抛去Antigravity大砍额度至几近不可用，令我逃窜到Codex的故事，整件事进展得飞快。

我把之前的样式迁移过来，并作了改进，又完成了归档页面。LLM也把之前栏后内容重叠的bug用JS解决了。甚至还用Pagefind给网站接上了搜索。当然，LLM还是不擅长视觉上的东西，每次写组件还是错漏百出，要我手动改。但整体还是快到不真实。

再后来，博客就是现在你眼前的样子了。我也终于可以在偌大的互联网中偏安一隅，有了自己的地方。●

由于RecyclerView的限制，我们无法真正实现延迟滚动。但是，我们可以让元素在ViewHolder固定的大小范围之内上下移动，即操纵translationY，来实现近似延迟滚动的效果。那么这个移动范围何时加、加多少，即是本篇所要着重讨论的内容了。

不过首先，我们先来看一下我们常用的滚动动画曲线⸺贝塞尔曲线。

1. 贝塞尔曲线简介

在PathInterpolator中，我们使用的是一种特殊的三次贝塞尔曲线。其中，P₀固定在点 (0, 0) ，P₃则固定在点 (1, 1) ，而P₁与P₂的坐标则就是PathInterpolator(controlX1, controlY1, controlX2, controlY2) 中的四个参数。

我们也知道，贝塞尔曲线的方程为：

那么，在上述的情况下，贝塞尔曲线可以被简化为：

譬如，在Accord中，歌词滚动使用的曲线是PathInterpolator(0.4f, 0.2f, 0f, 1f)，那么其方程为：

其在t ∈ [0, 1] 时的图像如下：

2. 差值计算

由于原函数图像只在x ∈ [0, 1]​ 中，我们定义：

在页面滚动中，式 (3) 中的x为时间，y为位移。延迟滚动即是在x上偏移，让时间错开。在Accord中，偏移的时间是总位移时长的0.1倍，即令x = x + 0.1​，可得：

用式 (3) 减去式 (5)，即可得到我们所需的移动范围随时间变化的方程。其图像如下：

但是仅仅得出方程我们是无法加以利用的。

3. 贝塞尔曲线拟合

要利用上得出的差值方程，我们需要将函数图像在其导数f ′(x) = 0，即在其极值点两侧分别用三次贝塞尔曲线拟合，并记录极值点在函数中所在的位置。

由于只有两个控制点并且无法控制权重，我们使用了比较简单的方法进行了大致的拟合。

其中，在向下移动时，其函数对应的是PathInterpolator(0.96f, 0.43f, 0.72f, 1f)，图像如下：

向上移动时则为PathInterpolator(0.17f, 0f, -0.15f, 1f)，如下图所示：

接着，按照单调递增区间和单调递减区间在总时长中所占的比例来定义向下、向上时所需要的时间，选取一个合适的最大距离，就可以近似地模拟出延迟滚动的效果了。

结尾

如果你想要一个现有的示例代码，可以到这里看看，喜欢的话可以点个Star。

如果你对如何使用LinearSmoothScroller让RecyclerView实现更平滑的滚动感兴趣，欢迎看看这篇文章的上一篇，没有数学公式。●

然而，这些海报主要受众的母语仍为汉语，信息传达因此受阻。

为什么要这样做？

西方的平面设计之成熟，字体丰富、风格多样，确实更加繁荣。面对优秀的设计，兼收并采，行施拿来主义，毫不为过。

落到实践处却出了些问题。西文花样繁多，与设计风格相得益彰。相较之下，中文字体选择有限，不易与风格相匹。此外，中文凝练，字字见方，没有西文那一股流动感。

设计一套中文字形并非易事，更别说风格化。所以索性降低中文的影响，将其放置在不惹眼的角落，把本就相称的西文放在主要位置。看，原汁原味！

海报是信息传达的载体，视觉呈现应当服务于信息，别的只能作装饰。然而，当「高级」、「现代」与西文在某些语境中过度绑定，便容易使人忽略信息本身的重要性，形成「西文 = 高级」的固有印象，最终让装饰性的元素反客为主。更有甚者，连退作装饰的中文也丢掉，但这些海报仍旧面向以汉语为母语的人。这显然不合理。

这种局面的形成非一日之功，要转变也绝不能一蹴而就。我们能做的，只有在日常的设计中多使用中文，在实践中赋予中文更多的可能性，展现出中文「高级」的一面。毕竟，设计的优劣，从不在于语言，而在于整体的谐美与巧思。●

步骤

1. 将黄油融化至半凝固状态。

2. 混合黄油和糖，打蛋器搅打3分钟，直至发白；

3. 混合低筋面粉、高筋面粉与玉米淀粉，过筛，分两次间隔一分钟加入黄油中，用打蛋器搅拌，途中记得用刮刀刮下边缘的面糊；

4. 加入切细碎的小葱 / 蔓越莓，打蛋器搅匀；

5. 用裱花袋将混合好的面糊挤在铺有油纸的烤盘上；

6. 烤箱190°C预热5分钟以上，烤盘下垫一层烤盘，双层烤盘放入烤箱；

7. 190°C烘烤5分钟定型，180°C烘烤10分钟至边缘焦黄后取出放凉；

8. 放凉后用手把饼干放入嘴中。

享用！●