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