打印一个 9 页的乐谱时，我先是用了普通的 A4 双面打印、左侧订书针装订的方案，但这样很不适合快速翻页和平整地放在谱架上。和 AI 讨论了一番后才意识到更好的方案是用骑缝钉，也就是把几张横放的 A3 纸在中央钉起来/缝起来，然后对折，形成一本小册子。这样重做后得到的效果真不错！我觉得别的很多东西我也应该这样打印。

（这需要用复杂的方法重新排列原本的页，但一般软件都支持帮你重排成这样打印。另一个小的不便是这样最适合 4 的整数倍页，打印 9 或 13 页的内容会导致最后有空白页。）

@taoky42 问了我一个我也遇到过很多次的问题：CSS 怎么在 inline layout 中让一个小图片和旁边的文本垂直居中对齐？vertical-align: middle 会把图片的中央对齐到周围文字的 x height 中央，而这个属性目前没有值能对齐到 cap height 中央或者汉字中央。

一个方法是把图片前后的文字分别包进 span 标签，让文字和图片是平级节点，然后在所有平级节点上指定 vertical-align: middle。但这样会把文字基线全都搞乱，还需要把文字分别包起来，并不是好主意。

最终我发现了这篇（排版非常漂亮的！）博客 https://blog.kizu.dev/cap-height-align/ 其中说的第一种方法我觉得就足够好了：
vertical-align: middle;
margin-block-start: calc(1ex - 1cap);

我做了一些测试确认它在图片和文字有各种尺寸关系、不同尺寸文字混排、不同 line height 等情况下都有正确的效果，非常不错。我能想到的注意事项：
1. 如果 cap height 中央和汉字中央不一致，它只能对齐到前者。我看了一遍相关 CSS 单位，后者好像做不到，但我的经验是很多字体中这二者基本是一致的。
2. 只适用于 inline layout，如果在 flex layout 等情况下已经用别的方案实现了对齐，重复使用这个会破坏对齐。

（如果不要求 inline layout，也就是说不需要图片和文字混合在一起换行，那就简单多了。例如要对齐一个按钮上的图标和文字，别用这个方法，用 flex。）

最近在读朋友推荐的 The Complete Musician (Steven G. Laitz, 4th edition) 这本书，感觉真不错啊，讲得非常清晰和有道理，并且在我看来节奏适中，向想要学习乐理的人推荐。唯一的问题是中文翻译我听说问题很大，只推荐看原版。

Z-Library 有，录音等额外资源在 https://global.oup.com/us/companion.websites/9780199347094/stu/ （书上写的 URL 好像失效了）。

书很厚，我目前也只看了前 5 章，但只看前面一些部分我感觉就已经非常有收获了，像是睁开了以前一直闭着的眼睛😂立刻就在很多我熟悉的曲子中看出学到的知识了。

这两天狠狠玩了一下 TIS-100，终于把 TIS-100 SEGMENT MAP 部分全通了，还把一些比较简单的关卡仔细优化了一下，发现比 9 年前的自己能看出更多优化机会了。

好久没有这种纯粹的写底层代码的乐趣了😂虽然后面几关是真难，并且这个每节点最多 15 条指令的限制真是要了命了，写了一堆 write-only 的代码。

没想到我也有通关茶杯头的一天！
（我在2018年和2020年尝试时都发现好难啊，一开始就完全卡关，以为永远也没办法玩它了

https://github.com/SmartHypercube/codename

安利一种为各种东西生成随机代号的方案，TLDR：两位字母加两位数字，例如 DH-09、MP-91。

我用这个方案为自己的各种项目命名很久了，上一个版本是生成 4 个随机音节，例如 gedukube、toputise。虽然熵更高并且更易读，但使用中感觉随机生成的音节挺怪异的，也没那么容易记忆，因此改成了这个方案。这个方案在使用中没发现什么问题，我现在就很熟练大概 5 个在做的项目的代号。

为什么要用代号命名项目：
- 可以快速开始尝试各种创意，不会在“叫什么”这一步被卡住
- 快速探索的过程中想法经常会变，慢慢就和最开始的想法不一致了，用描述性的名字命名的话容易过时，而目录名、docker image 名等不好改
- 想法也可能分叉，从一个探索产生几个非常相似的项目，代号可以区分任何你想区分的东西
- 代号可以被用于目录名、变量名等，不用担心和关键字或者其他名字冲突，也可以被可靠地全文搜索找出所有出现的位置
- 代号泄露时不泄露语义信息
- 这个具体方案（两字母+两数字）在任何语言中都方便作为变量名、包名，并且我发现见到几次后更容易先记住字母部分，在还没记住数字部分时，也可以输入字母部分后自动补全

在玩 https://store.steampowered.com/app/1970460/Garden_Galaxy/ ，一个用随机刷出的各种物品建花园的游戏，很休闲

WTF！GitHub 悄悄[1]改成了再也不会自动 watch 新创建的仓库了（曾经有个开关）。

很好，我迟早要因为忘了 watch 而收不到别人发的 issue / pr 通知了。

[1]: 2025-04-15 在博客发了个通知[2][4]，2025-05-23 改了[3]，妈的这么快，而且没有任何邮件通知。
[2]: https://github.blog/changelog/2025-04-14-sunset-notice-for-automatic-watching-of-repositories-and-teams/
[3]: https://github.blog/changelog/2025-05-22-sunset-of-automatic-watching-of-repositories-and-teams/
[4]: https://xkcd.com/1208/

前天看维基百科，想学习一下什么是 drywall（干壁、石膏板），突然看到石膏的用途之一是“豆腐的凝结剂，膳食钙的重要来源”，意识到自己并不知道豆腐是怎么做的，于是学习了一番豆腐、豆干、豆皮、腐竹、豆腐乳等等食品的做法，感到非常神奇。

于是就想起来了以前在家里偶尔吃的豆腐乳（我家吃的是红方的，王致和的“大块腐乳”“玫瑰腐乳”皆为此方，但应该也有不少人常吃到的是白方的），遂网购一罐。下单时又看到王致和也生产臭豆腐（青方豆腐乳），想起来在维基百科上学习到这种臭豆腐和供油炸臭豆腐使用的臭豆腐干是不同的东西，我只吃过油炸臭豆腐，还没见过此物，就也买了一罐。

今天收到了，真是臭死了！还没打开就好臭啊！（商品介绍中专门说了，因为持续在发酵，会产生气体，所以发货时瓶盖只拧半紧，会有一些气体和汁水漏出来，我想是这导致没开罐就很臭了。）开始思考这个能生吃吗，我想就是应该生吃的，但它已经臭了！上知乎看看别人怎么吃，发现有人试图油炸（这个不能油炸的，和油炸的那种不一样），“家里就开始油炸屎了，锅臭了好几天”😂

我现在觉得说榴莲或者螺蛳粉像厕所炸了的人真的是什么都不知道，榴莲/螺蛳粉和这个比起来算什么啊。这么说吧，我觉得大家不会质疑榴莲/螺蛳粉已经变质了，但这个臭豆腐，我完全理解知乎上有人说直接就扔了。它！已！经！臭！了！（让我怀疑是不是变质了的食物除此之外可能只有豆汁）我觉得这是便携生化武器，投掷使用可能会很有效果。

看到这个讨论[1]，意识到有朋友可能还不知道：Python venv 会对所有安装到 venv 的 bin 目录的东西带上合适的 shebang，使得直接运行或软链接都能工作，不需要 activate venv。我觉得这样非常方便，已经很久没 activate 过任何 venv 了。

$ python3 -m venv path-to-venv
$ path-to-venv/bin/pip install fava  # 不用进入 venv，直接运行其中的 pip 就可以
$ ln -s path-to-venv/bin/fava ~/.local/bin/fava
$ fava  # 软链接也可以直接运行

[1]: https://news.ycombinator.com/item?id=45523767

这两天在玩 SpaceChem，和 TIS-100 有点像，都是并行的，都可以通过正好对齐周期数来节约同步开销，排行榜都分为周期数、节点数、指令数三个榜。SpaceChem 的代码阅读/调试体验比 TIS-100 好多了，但每关只支持保存一个存档，没法存储多个解法，坏。

视频为 Danopth（第 3 个星球）的 In-Place Swap 这一关只用 1 个 reactor 我能想出的最快解法。

动物森友会里面可以创作一个简短的曲调作为岛歌，和每个角色对话时，对方都会用自己独有的音色演奏。旋律只能由匀速播放的 16 个音符组成。我最近看了太多奇怪拍号的音乐😂于是想要逃脱这里每行 8 个音符带来的 4/4 拍的思维定势，写下了这个，正好能挤进 16 个音符的空间耶。

突然看到了好清晰的猎户座！

😂SQLite 的 query planning 能力还是比较有限的（试了一下 PostgreSQL 是会用索引正向反向各读一次的）。

SQLite 的 query planner 倒是很简单好理解，读一遍 https://sqlite.org/optoverview.html 就能猜出各种常见情况会怎么执行了，作为学习材料很棒。

Day 1 😆

今天才知道 VS Code 会检测注释中的“MARK: foo”这样的写法，把“foo”显示在小地图上。我一直觉得小地图需要这个功能！

https://modelware.zgci.info/
给我所在的全员高配的团队做了个网站😆

🙈我又过度调研了什么：
- 首先，iOS 上浏览器里是没有宋体楷体的，想各平台风格较为一致就只能用黑体。
- font-family: system-ui, sans-serif 看似能选中每个平台上合适的字体，但在 Linux 上，这样选中的 Noto Sans CJK SC 竟然只支持两种 font-weight，必须在 font-family 里面直接写 'Noto Sans CJK SC' 才能解锁全部字重。
- 有的平台上 system-ui 命中了中文字体后，英文和数字也会用这个中文字体渲染，而没法用平台 UI 默认英文字体，这个问题好坑啊，system-ui 不能定义成按平台 UI 默认选字体的逻辑对每个字符分别选择吗？
- 经过测试，正确配置字体的情况下，300 400 500 700 900 这 5 档字重在各平台基本都是不同的，可以安全使用（而比如 600 700 在有的平台上是相同的）。
- 双引号、单引号、间隔号如果想让中文渲染中占汉字宽度，英文渲染中占很小的宽度，可以在中文元素上加一个最高优先级的自定义的 font-face 实现。思源黑体和微软雅黑中的这些字符都是汉字宽度，好。苹方黑体的引号则比汉字宽度窄，所以即使这样做了效果也不完美，坏！

#今天我学到了什么

四条腿的桌子椅子在不平整的地面上经常会晃动，三条腿就不会晃了，但让倾倒的可能性增加了不少。

五条腿是一个好得多的解决方案，虽然在不平整的地面上仍然会有腿是悬空的，但重点是，四条腿的情况下重心一般正好在临界线（也就是某一条对角线）附近游荡，导致在两种模式之间切换。五条腿的情况下重心不靠近任何临界线，所以会是相同的三条腿实际在支撑，不会晃。

坏了🌚我是不是最后一个知道的：

租房提取公积金是按月的，申请后每月可以提取 min(房租，每月缴存额)，房租低于缴存额的部分提不了，申请之前的月份的钱提不了。在北京，没有发票的话房租视为 2000，有发票按发票。这意味着如果不计划买房的话，最优策略是每月都要提取，不能漏，房租也要大于或等于缴存额。漏了的月份和房租低于缴存额的部分只能买房的时候用了。

另外，贝壳省心租可以非常方便地设置公积金直付房租，别的平台可能也可以，这样不用开发票和自己垫付。

更正：季付房租+公积金直付房租的话，似乎相当于可以把之前漏了的也提出来，因为第一个月就会直付 3 个月的，这里会消耗之前积累的余额来付额外的 2 个月。

AI 取代人的一个问题

我之前一两年就经常在关注这个问题：很多问题上人是没法把自己的经验和判断传给另一个人的，或者说，甚至没法低成本地说服别人。我常举的例子是 1. 和某种动物打交道很久的人一眼能看出图片上的动物是哪只个体，但普通人怎么看都觉得全长一个样。2. 经验丰富的棋手会说某一步感觉更好/更坏，但不一定能用逻辑说服别人。3. 数学好的人有很多 heuristic，比如某道题一看就想先尝试某个方法来解。

这些事情的共性是，如果另一个没有相关经验和判断的人不认可，很可能除了非常高成本地让他也接触大量训练数据以外，没有办法低成本说服他，或者教会他。（现实中的解决方法往往是“我是这个领域的专家，所以你应该相信我的判断”）

如果我们指望 AI 能代替人写代码或者思考数学题等等，就会产生这个模式的问题了，比如人觉得想写个某某程序/提出个数学猜想希望能找到证明，AI 实际来做，那么做的过程中一定会发现很多想不到的问题。目前的 AI 在这里表现就很差了，实际上需要人来盯着，把这些问题都帮忙想清楚。

但假如 AI 能像人一样把这些问题都仔细想清楚，这中间就会产生很多知识，并且一些真正重要的知识不会是很“表面”的、可以几句话说清楚的，而是像我前面说的那种，没法低成本说服别人/教会别人的。

如果人没获得这样的知识积累，不知道这些自己都想不到的问题的思考结论，那就会有很多问题了，比如 AI 说做不了，人不信，或者人可能会提出一些没有逻辑的需求，或者完全不理解各种需求的实现成本、可行性、取舍，不知道其实存在更好的选择等等。毕竟人没有自己思考过实际做起来会遇到的各种问题，没有获得能训练出自己的判断的大量数据。

很多事情里面都有两类工作量，机械枯燥的劳动和真正把未知变成已知的思考（机械枯燥的思考，例如列竖式算长除法，或者观察一张图片是不是消防车，属于前者）。我认为后者是一个人，或者 AI，成为专家的必经之路。另一个专家给你说各种结论，是不会让你也成为专家的。而且这种知识不是死的，是要持续迭代前进的。

因此我认为，专家和非专家之间是存在区别的，非专家是不会因为用了特定辅助工具或者有专家替自己做事，就成为专家的（当然绝对可以有一定程度加速的作用）。如果 AI 达到了能够替代人做那些思考的水平，并且真的在做，AI 会成为专家，人不会，而非专家是很难指挥好专家的，也很难做出好东西。

更新：最近这几天显著在变得越来越好，能搜到的东西随时间越来越多了，从这方面来说和之前很长一段时间里的情况完全不一样，最近确实有变化。目前仍然有不可靠之处，所以如果没搜到也不能认为真的没有，但能搜到各种东西的概率已经挺高了。

CSS 中和折行相关的几个属性，按大致处理流程讲：

white-space 同时控制两件事：白字符合并方式、是否允许折行。如果它禁止折行，下面的流程都跳过。

word-break 控制候选断点的规则：
- normal 是默认规则，空格、标点、汉字之间、<wbr> 等会被视为候选断点。
- auto-phrase 会避免在一些短语中间的空格处插入候选断点。
- break-all 会在所有字符之间全都插入候选断点。
- keep-all 不在汉字之间插入候选断点。
- break-word 比较特殊，它按默认规则插入候选断点，但忽略下面的 overflow-wrap 属性实际值，按 overflow-wrap: anywhere 执行。

overflow-wrap 控制最后的折行算法：
- normal 只在候选断点处考虑折行，如果两个候选断点相距太远就会溢出。
- anywhere 在必要处额外折行来避免溢出（不同浏览器对此的精确理解略有不同，参见 https://t.me/SmartHypercube_channel/210 ）。
- break-word 与 anywhere 的区别仅在于 min-content 尺寸计算方式。

网页开发的最佳实践是把所有尺寸都以 rem 为单位表达，rem 表示根元素的 font-size，这样当用户浏览器放大或缩小文字后，所有尺寸都会成比例地变化，放大文字的渲染效果会和缩小窗口类似。

但是，至少在 iOS 上的 Chrome 和微信内置浏览器中，全用 rem 是不能实现预期效果的，会发生的是，文字大小变化，但图片、按钮、布局都不变，导致出现各种排版错误。

我进一步测试了各种缩放方法，发现大家的实现非常乱：
- 有需要网页用特定 font 来 opt-in 的（iOS 系统设置 文字大小）
- 有改变 devicePixelRatio 的（iOS 系统设置 缩放显示、Linux Chrome 缩放）
- 有改变 visualViewport.scale 的（iOS Safari 缩放）
- 有改变 rem 的（真正符合广为流传的说法的。这种非常少见，我只在 iOS Telegram 内嵌浏览器发现了）
- 有改变所有 em 但偏偏不改 rem 的（iOS Chrome 缩放文字、iOS 微信 字体大小设置）

不过总体来说，除了最后一种以外，按最佳实践开发的网站都不会受到什么影响，只需要支持非常窄的屏幕就行（放大文字会导致屏幕宽度相当于变得更窄）。

最后一种很坏，workaround 是用 em 而非 rem 作为单位（但是这样 CSS 挺难写的）。

复现方法： https://test-scale.z1.hc11.org/2/ 打开这个网页，缩放，看缩放后文字高度和背景色高度是否按比例一起变。

更详细的测试工具（让 AI 做的）： https://test-scale.z1.hc11.org/

SQLite tips：

1. https://www.sqlite.org/wal.html
pragma journal_mode = wal，这个简直是必须的，坏处非常微小，而会让你的数据库可以同时有任意多个只读事务外加一个读写事务。

2. https://www.sqlite.org/stricttables.html
可以把所有表都创建成 strict table，其中明确想保存自由类型的列用 any 类型就行。

3. 默认配置下，删除大量数据后，只能通过 vacuum 来释放不再需要的空间，它的原理是完全复制一份新数据库，再删除旧的，在磁盘很满时做不了。可以看一下自己删数据时用的连接是不是 pragma secure_delete = 1 的（或者先设置这个再删），如果是，就有一个巧妙的做法：确保停掉所有数据库连接，然后对数据库文件做 fallocate -d。这会把删掉的数据的位置都挖成洞，过程中不额外占用空间，并且业务中断时间也短得多。

pragma secure_delete = 1 的效果是把删除的数据都用 0 覆写，如果想让删除的性能更高，也可以关掉这一功能。

想方便地回收空间的话，标准做法是在创建任何表之前，先为数据库设置 pragma auto_vacuum = 1 或 2（详见文档），这会使数据库记录每个页面被引用的位置，使得空白页面可以和尾部的非空白页面交换，然后再 truncate。唉，要是 SQLite 能在可打洞的文件系统上用打洞来删除数据，secure_delete 和 auto_vacuum 的效果就都可以更低开销地实现了。

吐槽一句，arXiv 的 API 真是烂透了，维护 paper.dou.ac 的过程中遇到过各种奇奇怪怪的问题，最近一段时间尤其更糟了，已经发布的论文 PDF 文件大小为 0 和 query API 查不到这两个问题发生频率在增加，例如：

PDF 文件大小为 0：
abs： https://arxiv.org/abs/2605.23998v1
有问题的 pdf： https://arxiv.org/pdf/2605.23998v1

query API 查不到：
abs： https://arxiv.org/abs/2605.27010v1
有问题的 API： https://export.arxiv.org/api/query?id_list=2605.27010v1

（一般来说有这样问题的论文会在发布后一到几天内悄悄被修好，所以过几天再检查上面举的例子可能就没问题了）

Codex 有个机制，当 Quota 用尽时，它依然允许跑完最后一轮对话。

利用这一点，只要在配置里开启

[features]
default_mode_request_user_input = true

并用 Prompt 诱导它不断调用该工具，就能把对话卡在同一个 turn_id 里无限套娃续航😂 因为调用工具并不算新的一轮对话，但 request_user_input 工具实质上提供了插入新 prompt 的能力

附送提示词：
总是在结束前调用 request_user_input 工具告知用户当前进展，接收用户的反馈。

https://modelware.zgci.ac.cn/blog/2026/toolize/

（软件智能研究所持续招人中，尤其想找对软件/AI感兴趣、能独立钻研新事物的工程师/研究员，详情见 https://modelware.zgci.ac.cn/jobs/ ，也可以直接联系我～）

AI 太喜欢写空话/废话了，最近我和 @hejiyan 收集了一些例子并分析其中的具体问题，整理了一份关于何为空话/废话的文档，可以直接发给 AI：
https://nofluff.0x01.me/