IP 数据库体积缩小 31%，关键竟然是合并重复子树

提到用 Rust 重写项目，很多人的第一反应往往是性能提升。以 Bun 为例，它最初主要采用 Zig 开发，后来在 2026 年发布的 v1.4 版本中将核心代码迁移到了 Rust。用 Rust 重写，性能、安全性往往是大家想要的，但是有没有想过用 Rust 重写还能发现 bug 呢？ pgrust 这个项就是，他用 Rust 重新实现 PostgreSQL，保持通信协议和 SQL 方言兼容。为了确认新系统的行为和原版一致，开发者需要对着 PostgreSQL 的实际返回逐个比对。结果查着查着，有些异常不是新代码的锅，PostgreSQL 自己就是这样的。pgrust 开发者 Michael Malis 把其中几个报告给了 PostgreSQL 社区。 大概的问题： 1）SP-GiST 空间索引里有个函数判断点的方位，代码认为上、下、同一水平线三种情况已经穷尽了，末尾放了句「impossible case」兜底。结果在特定浮点边界附近，三种判断同时不成立，程序真走进了这个「不可能」的分支 2）日期格式缓存复用时，一个解析模式的标记没重置，导致同一条 JSONPath 查询在同一个会话里，换个执行顺序结果就不一样。 3）pgcrypto 的 crypt() 在某些输入下截断了多字节字符，返回的文本编码不合法。能存进去，但 pg_dump 导出时就炸了。 一个用 Rust 重写的新项目，测着测着，把运行了几十年的 PostgreSQL 里埋着的东西翻了出来。Rust 重写的价值，不一定只在跑得更快、更安全这一件事上。为了做到真正的兼容，开发者得把前人没怎么碰过的边界全走一遍，这个过程本身就在帮原版排雷。

ARTS 1025: 唯一字符与同构字符串、省词可能增加阅读负担与重新估算软件的实现成本

🎉 1024 程序员节快乐！ 祝编程导航里的每一位程序员：offer 多多，薪资翻倍，面试顺利，早日拿下心仪 offer！💻

AST：从 Java 代码理解抽象语法树

原来维基百科还有专门研究「AI 味」的页面 今天偶然发现一个挺有意思的维基百科页面：https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing，专门整理 AI 写作的典型特征。 里面总结了很多我们平时经常看到的 AI 味，比如喜欢用“值得注意的是”“在当今快速发展的时代”“综上所述”，还有过度使用排比、加粗、列表，以及一些看起来很有道理，实际上没什么信息量的表达。 感觉以后可以定期翻翻这个 wiki，尤其是经常使用 AI 辅助写作的人，应该能从中发现不少所谓的 AI 味。 链接： https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

ARTS 1018: 字符计数判断异位词、局部做对仍会增加维护负担与用 AI 也要理解自己在做什么

AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。

最近玩了下 opentunnel，OpenCode 作者（anomalyco）新搞的工具，号称 blind TLS tunnel，体验下来确实省心。 核心就一行： opentunnel route add 3000 # → https://c5a40fbfae0811f0.xxx.opentunnel.xyz 你本机的 :3000 立刻多一个公网 HTTPS 地址，而且还有免费证书自动签好（ZeroSSL）真的良心，目前没有发现付费的地方，推测应该是免费的。 几个有意思的点： • 背书靠谱：OpenCode / OpenTUI 同作者团队出品，免注册、不强制绑定平台账号，开箱即用。 • 零配置：第一次 route add 自动建隧道 + 后台常驻，opentunnel status 看到 connected 就行。 • 随机子域名：默认 16 位随机串，拿到 URL 才能访问——但注意这不是鉴权，别当密码用。 • TLS 本地终结：服务端只看 SNI 做转发，服务端没有私钥，也看不到你的明文流量。 常用命令就这几个： opentunnel route list # 查看已有路由 opentunnel status # 查看连接状态 opentunnel up / down # 启停守护进程 opentunnel route remove <name> # 删除路由 适合场景：前后端联调、手机看预览页、给朋友甩个临时 demo（官方初衷也是方便在外网随时连自己的 OpenCode Server）。长期跑或大流量还是老老实实上服务器。 项目地址：opentunnel https://github.com/anomalyco/opentunnel

你的游戏本身就是 Harness：如何让 AI Agent 读懂游戏并高速迭代？（译文）