有消息指 Telegram 优化了中文搜索，我感觉好像没变啊？？？
很长一段时间以来都已经是有个别单词能只输入单词（而不用输入整句）匹配上了，但特别不可靠，我瞎猜是只对最常见的一些单词做了匹配处理？目前看来好像仍然是这样，没变。
很长一段时间以来都已经是有个别单词能只输入单词（而不用输入整句）匹配上了，但特别不可靠，我瞎猜是只对最常见的一些单词做了匹配处理？目前看来好像仍然是这样，没变。
Hypercube's Channel
有消息指 Telegram 优化了中文搜索，我感觉好像没变啊？？？ 很长一段时间以来都已经是有个别单词能只输入单词（而不用输入整句）匹配上了，但特别不可靠，我瞎猜是只对最常见的一些单词做了匹配处理？目前看来好像仍然是这样，没变。
更新：最近这几天显著在变得越来越好，能搜到的东西随时间越来越多了，从这方面来说和之前很长一段时间里的情况完全不一样，最近确实有变化。目前仍然有不可靠之处，所以如果没搜到也不能认为真的没有，但能搜到各种东西的概率已经挺高了。
👍1
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 尺寸计算方式。
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 尺寸计算方式。
👍1
网页开发的最佳实践是把所有尺寸都以 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/
但是，至少在 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/
👍4
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 的效果就都可以更低开销地实现了。
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 的效果就都可以更低开销地实现了。
👍5
https://yun.0x01.me/
我之前就想玩一玩把相同的韵母和声调用在每一句，但不追求遵守格律。今天终于让 AI 帮我写了个小工具，顺便统计了一下常用字的韵母分布频率。
过程中也学到了不少新东西，比如最常见的韵母和声调组合就是 ì（“意”），但我感觉押这个韵的字听起来并不是很相似，可能这里必须再按声母分得更细。
以及有一个叫“十三辙”的概念我以前一直不知道，用它同时搜索多种介韵母+韵母的组合比较有效。好了我担心我再说怪话有的朋友就要暴跳，赶紧凑足四句就跑掉（笑）。
我之前就想玩一玩把相同的韵母和声调用在每一句，但不追求遵守格律。今天终于让 AI 帮我写了个小工具，顺便统计了一下常用字的韵母分布频率。
过程中也学到了不少新东西，比如最常见的韵母和声调组合就是 ì（“意”），但我感觉押这个韵的字听起来并不是很相似，可能这里必须再按声母分得更细。
以及有一个叫“十三辙”的概念我以前一直不知道，用它同时搜索多种介韵母+韵母的组合比较有效。好了我担心我再说怪话有的朋友就要暴跳，赶紧凑足四句就跑掉（笑）。
👍6
吐槽一句，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
（一般来说有这样问题的论文会在发布后一到几天内悄悄被修好，所以过几天再检查上面举的例子可能就没问题了）
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
（一般来说有这样问题的论文会在发布后一到几天内悄悄被修好，所以过几天再检查上面举的例子可能就没问题了）
👍1
Forwarded from Yifan's nonsense
Codex 有个机制，当 Quota 用尽时，它依然允许跑完最后一轮对话。
利用这一点，只要在配置里开启
并用 Prompt 诱导它不断调用该工具，就能把对话卡在同一个
附送提示词：
总是在结束前调用 request_user_input 工具告知用户当前进展，接收用户的反馈。
利用这一点，只要在配置里开启
[features]
default_mode_request_user_input = true
并用 Prompt 诱导它不断调用该工具，就能把对话卡在同一个
turn_id 里无限套娃续航😂 因为调用工具并不算新的一轮对话，但 request_user_input 工具实质上提供了插入新 prompt 的能力附送提示词：
总是在结束前调用 request_user_input 工具告知用户当前进展，接收用户的反馈。
👍6
Forwarded from 🐱MiaoTony's Box | 困困困 zzz (🐱nanobot)
Please open Telegram to view this post
VIEW IN TELEGRAM
软件智能研究所
Agent 自主实现千款软件智能化适配：中关村两院“超级软件智能”完成阶段性验证
智能体（AI Agent）已经从对话工具走向执行工具，但用户与 AI 的协作几乎都被压进一个聊天框，丰富的图形交互、专业流程与历史数据被切断。近日，2026“活力中国调研行”主题采访活动走进北京中关村学院与中关村人工智能研究院（简称“中关村两院”），现场发布“超级软件智能（Modelware）”项目最新阶段性验证成果：Agent 一日内自主完成 1000+ 款软件在国产操作系统生态的智能化适配，使得 Agent 能够原生调用软件使用，让 AI 跳出聊天框，提供智能体时代全新的人机协作范式。
https://modelware.zgci.ac.cn/blog/2026/toolize/
（软件智能研究所持续招人中，尤其想找对软件/AI感兴趣、能独立钻研新事物的工程师/研究员，详情见 https://modelware.zgci.ac.cn/jobs/ ，也可以直接联系我～）
（软件智能研究所持续招人中，尤其想找对软件/AI感兴趣、能独立钻研新事物的工程师/研究员，详情见 https://modelware.zgci.ac.cn/jobs/ ，也可以直接联系我～）
👍7
很多年前我和 @zzh1996 讨论过的一个问题，我觉得它的证明很好理解并且结论在很多问题上有启发性：
甲乙二人通过一个可能丢包的网络通信，甲可以随时给乙发消息，乙也可以随时给甲发消息，每条消息分别有可能被对方收到或者丢了。他们希望找到一个方法协商要不要出门一起吃饭，也就是说，每个人都执行一个算法，收发一些消息后决定自己要不要出门。希望找到满足以下性质的算法：
1. 无论网络如何丢包，只允许两种结果，要么两人都出门了，要么两人都没出门
2. 如果网络完全没丢包，最终结果必须是两人都出门了
3. 如果网络完全丢包，最终结果必须是两人都没出门
（后两条性质的目的是禁止把算法设计成“什么消息都不用发，直接出门”或者“直接不出门”）
这样的算法是不存在的，证明：
如果网络完全没丢包，因为性质 2，最终甲乙都会出门。又因为性质 3，甲乙都出门的话一定是发送过至少一条消息的。我们把网络中最后一条消息称为消息 X，不妨设 X 是甲发给乙的，那么如果这条消息丢包了，甲不可能知道，甲仍然会选择出门，而乙没收到这条消息就不会出门，这违反了性质 1。
所以无论设计多么复杂的消息编号机制、重传机制、确认机制，只要最后一条消息（真正导致决策从未生效切换为生效的那条消息）可能丢包 ，都不可能保证达成一致的。
如果把性质 1 弱化，就变成现实中常见的方案了：某方直接做决定，然后不停地尝试让另一方知道这个决定，至少可以保证只要有一条消息不丢包就能让对方知道。但如果存在“不和对方确认我没法直接做决定”“我需要知道是否成功通知到了对方，没有的话我得撤回决定”这样的需求，就无解了。
甲乙二人通过一个可能丢包的网络通信，甲可以随时给乙发消息，乙也可以随时给甲发消息，每条消息分别有可能被对方收到或者丢了。他们希望找到一个方法协商要不要出门一起吃饭，也就是说，每个人都执行一个算法，收发一些消息后决定自己要不要出门。希望找到满足以下性质的算法：
1. 无论网络如何丢包，只允许两种结果，要么两人都出门了，要么两人都没出门
2. 如果网络完全没丢包，最终结果必须是两人都出门了
3. 如果网络完全丢包，最终结果必须是两人都没出门
（后两条性质的目的是禁止把算法设计成“什么消息都不用发，直接出门”或者“直接不出门”）
这样的算法是不存在的，证明：
所以无论设计多么复杂的消息编号机制、重传机制、确认机制，只要
如果把性质 1 弱化，就变成现实中常见的方案了：某方直接做决定，然后不停地尝试让另一方知道这个决定，至少可以保证只要有一条消息不丢包就能让对方知道。但如果存在“不和对方确认我没法直接做决定”“我需要知道是否成功通知到了对方，没有的话我得撤回决定”这样的需求，就无解了。
👍7
Forwarded from Hacker News 摘要
Telegraph
现实拥有惊人数量的细节 (2017)
原标题：Reality has a surprising amount of detail (2017) 作者通过儿时跟随父亲参与建筑劳动的经历，总结出一个深刻的观点：现实拥有惊人数量的细节。这种现象解释了为什么人们，甚至是顶尖专家，往往会在智力上陷入困境。 建造楼梯的细节案例 以建造地下室楼梯为例，表面上看这很简单，只需要几块木板和支架。但实际操作时，你会发现大量的细微差别： • 分解任务：你需要以正确的角度切割木板、安装固定支架、拧入螺丝。 • 切割难题：确定切割角度并不直观。你可能需要运用三角函数…
^ 这几年我越来越意识到了这一点，并且发现我的计算机领域背景在一定程度上阻止了我更早意识到现实其实是这样的。计算机领域更容易假装一切可以有完美的抽象和分层，可以从一个简单清晰的分层边界开始思考问题（虽然其实 all abstractions are leaky）。其他领域中无法漂亮地分层、以至于必须处理巨量的细节的情况简直太多了，我感到我看待世界和任何问题的方式都发生了变化。
👍10