人生三大避免不了的事情：死亡 税收 Claude封号

Make Bilibili Great Than Ever Before 发布 1.9.0 版本，推出「Thread Ripper」功能，无需进行任何手动配置，自动评估 Bilibili 的多个 CDN 节点的质量（TTFB 和带宽）、选出最优的数个 Bilibili CDN 节点、多线程并发并行 缓冲 视频分片。该功能默认关闭，需手动打开。

该功能受 MrTangLuyao/Bilibili-thread-ripper 项目启发，但是仅使用了 不到三分之一的代码量（不包含代码注释）实现了 接近甚至更好的视频播放缓冲速度 和 启播用时。

具体取舍和实现细节参见 https://github.com/SukkaW/Make-Bilibili-Great-Than-Ever-Before/pull/31

https://htmx.org/essays/yes-and/
强烈推荐这篇文章

#statement
🤔 许多人会用各种新闻学（比如Jev和果蝇的各种夸大/不实宣传）把LLM们吹的无所不能，IQ至高，【不可战胜】，可实际上，它们仍然只有一份上文，一把探照灯。因为屏幕外边的最终用户是这样的。

软件创作者的本来任务，就是多见识一些东西，哪怕不求甚解，做个深广的'T'型人才。 尽管，Agent比人更擅长活在操作系统里不知疲倦，所以不需要人替它们烧脑、剪枝，但用户，却不是如此。

机器长了轮子，不需要护膝，可是人机界面、人际平台，始终需要人来理解。

总是有人试图用美容药和垄断的“资源堆砌法则”，来夺走每个人天赐的好处，但结果却是被【偶然性】次次打脸。 所谓手搓、工匠精神，与AIGC的关系，也应该如此。 📚

向量几何、着色器、网格遍历，看起来专业，但其实就是【风格迁移】类任务。 与其说是AI足够聪明了，不如说是【反馈循环】、低噪音、高信息交叉的机器学习模式，降维打击了【瞪眼法】的deadfish传统CV/CG领域。

那么，【品味】难道不是可以生成和【一键继续】的吗？ 理论上，未来+1年的AI，可以顶你一辈子ID吧？

答案或许是：我不怕有人当copycat，因为我的“正确”应该是他们忍受不了的风格。

隐藏层的复杂性没有上限，但是，接口是由人来声明的。 我学的编程，更多是一种面向接口、强类型、正交组合的思维的哲学，而不是数学或“Excel的三种写法”（表单 class sql）。

《软件工程》会和“绘画圈”一样出问题吗？

其实，画师商单的弊病，本来就很明确：

- 高度任意性（缝石块），产品可以凑合，一幅画基本就是另外两幅换脸换笔刷，做个风格迁移
- 无个体差异，一个单子让什么人画，只有<5%的人能在不破坏的前提下融入风格
- 小众冷门，本身就（不像动漫原画）受主流待见，商业模式还在70年前
- 绝杀： 人手只能一笔笔画，AI能按图块和风格“绘画”， IO 模态的降维打击。 就像是还没有【以图搜图】【以图荐图】时手打的标签系统，到【谷歌识图】那样的绝杀。

编程里通过声明式框架，AI和人站是在一个模态上继续编程，并且方便压缩。 你很少用过【无法言喻】的软件，但软件逻辑本身，是丰富且开源的，作者和最终用户边界并不明确

通俗的说，IT 知识接受过更多【大众化考验】，所以努力更能看到成果

Daniel Lemire's blog
Parsing JSON at tens of gigabytes per second… in Python

source #py #perf

我突然觉得释然了。 为了屎山codebase能“免费”提升它们从来用不到的吞吐量， 许多人真的会给母猪上唇膏并且开始f...它了

JSON，在>80%应用里，是一个连 [{},] 的excel模式和 {_5args: true} 都没有优化的格式，甚至也没有约定 {Duck:} {Cat:{arg:"wtf"}} 的type多态。

在我眼里，这就像一个逆向工程工具看不懂libc，或运维panel不会用 -k v 参数理解bash接口那样， 但是，它偏偏很快。

他们宁愿在端到端上，投入无数奇技淫巧的精力，也不愿意像CBOR（预训练字典）或flatbuf一样，提供一套新的、协议化的，是【对人类有意义】的选择，从一开始就没有这些跳空格 s.indexOf("\"") 的问题， 甚至是让JSON兼容一下csv模式，而不是 [{},] 的无效重复AoS

如果一开始就基于flatbuf+js Proxy 或tg的TL这样的心智模型（从原理上就更好优化）， 这些文章里90%的概念可能根本没必要提出。 以后就连AI也会在JSON这样连Excel CSV 都不会压缩的【最佳兼容性实践】上，继续搭建吧

预训练字典和SoA/AoS变换，可以说是通用性相当好的选择。 就像对于Electron的体积，像./gradlew那样【用到时再下载】是更好的理解。 但是，他们一直在两个极端之间吊着。

这样的软件工程，真的早点毁灭吧。 端到端的优化AI也完全可以生成啊

"给母猪上唇膏"这个比喻不是针对simdjson，而是在问，为什么RPC问题里最最基本的子部分（比如csv），

想要压缩+提速，需要端到端（人类不可介入）的优化？做在与 TLS 平级的层面不行？ py/js dict 和元编程的层面呢？分出【测试100%覆率期】和高效运行期？ 这些都不需要很大精力，明显比榨干最后一个cycle和L1 cache，少多了，而且更加可控。

但是，他们还是愿意做这样的，无需理解任何新决策、新协议、新flow，未来连AI都可以loop的JSON.parse单函数优化。

对A\ 5.1: 你还是不明白。 我说的是指理论上的，你一直在提Proxy这些实现问题，哪怕我在编译期Proxy又怎么样呢

至于HPACK的问题，分出"测试期"和"高效运行期"，我是指【C/S管道】本身要有字典训练命令。你还是不理解

😅 难得被A\同意一次。 之前我说什么它杠什么，可能是暴论太多，但这次，打在人类现行决策最差的部分了

#perf #js #PLT
真的是在一个垃圾赛道上，看过五六篇这样的文章了。 就算提速5倍又怎么样呢？ 这只是1个函数

A\说的对：都是在讨论一个大多数人不需要操心的层面。区别只是一个想换格式，一个想换解析器，性能和吞吐量被gzip和lazy读取兜着。

但如果换Protocol，你会有个更全局的视角，触及更多可决策性，而换parser，没有

JSON 解析根本不是瓶颈——数据库、网络 RTT、业务逻辑才是。LLM 场景里 JSON 的成本才第一次变成了 token 数，而不是 CPU。

json本身，不具备软件逻辑和功能，它不【理解】事情，它把本地存储和tcp文件混为一谈， 在这样的赛道上内卷最后一个cycle，而这正是 KDA REA 这些Agent擅长的loop

在乎高性能的人，怎么不去想想 JSON.loadump 是怎么取代曾经C结构的世界，成为了万能协议的，不想想【旧时代遗毒】输给了谁？

为什么，0开销的native输给了瓶颈的 JSON？ 你们输在哪，还是说不觉得【编译型哲学】应该反思，不觉得编程和生活一样，值得在执行前多多推敲、选择？

fastsimdjson.map_many(..., threads=64) 是库内部高度优化的并行路径。msgspec 这边是用 ThreadPoolExecutor 切分数据再调解码，Python 层开销更大。橙色那条是 msgspec 用 dataclass 去解析 JSON，不是 MessagePack（二进制）。

这些垃圾赛道上，就像 OOP 构造器赋值，那样的东西，在编程界都能写这么久。 我以为constructor() 会是 {}[] 默认值这样的“构造器”，load/dump封送构造，或表单校验器？

但事实证明，只是一堆 arg -> obj.key 闭包装箱而已。几乎整个世界只有Kotlin或Coffee把OOP当作OOP来写，Go修null仍然没有修好。这就是Java的后继了，一开始连泛型都搞不懂。

这样丑恶的编程，死几百回也不值得珍惜的吧。至少没有MIT Scratch 那样聪明。

编程的基石就是类似这样，在莫名其妙、毫无【常识】的设计上堆起来的沙垒，它们被当成IR用也不值得稀奇。 那些OOP对问题的理解，还不如各种框架深入。许多人掌握编程语言，多半是夜郎自大

2026年总是有人把GitHub当神仙，甚至认为【微软发明了它】，却忽视了，真正给它哲学的是Ruby和DHH。

我见过 95% 的编程技巧，都是用两句话说得清要领的，甚至有些生活化，就像王垠的博客一样（略微复杂+20%）。

代码本就是快乐的，充满获得感，不是一种【痛苦的刚需】或负资产

但能做到的技术人，很少。 总是在说理解力、学习能力怎么样， 没人批评老师，可探索性和解释力怎么还不如AI强。 🙉

编程语言，应该是让人像在MC里一样，【飞天穿墙，做图晒档】的创作素材，语言是创作欲，而非纯粹的工具。 可是我看到的，纯度太低了。