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

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

尝试使用 AI 解决一些复杂问题（例如思考、分析代码、写代码）的话，目前一定要注意使用官方正版的 API 和正确的使用方法。

前段时间我试了一下 codex-cli + openrouter 的 gpt-5.1-codex reasoning high，发现奇蠢无比（图一：连数数都不会了.jpg 图二：？？？），和我用自己的账号的效果很不一样。@zzh1996 抓包发现使用 openrouter 而非官方的话，根本不会发送 reasoning effort 参数，并且也无法把加密的 reasoning 带进上下文等，确实有很多硬伤，模型根本无法发挥实力。他告诉我他遇到过很多次有人吐槽 AI 菜，结果只是因为没有用官方正版以及最好的模型和参数了。我日常在网上也能注意到很多对于 AI 使用体验的吐槽似乎明显不是当前最好的模型按好的方法使用的效果，感觉这样很可惜，很多有不同观点的人可能只是因为用的就是完全不同的东西。

https://b23.tv/AsquyXw
（一个我觉得质量很好的翻译）

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 会成为专家，人不会，而非专家是很难指挥好专家的，也很难做出好东西。

有消息指 Telegram 优化了中文搜索，我感觉好像没变啊？？？

很长一段时间以来都已经是有个别单词能只输入单词（而不用输入整句）匹配上了，但特别不可靠，我瞎猜是只对最常见的一些单词做了匹配处理？目前看来好像仍然是这样，没变。

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

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 尺寸计算方式。