虽然但是，ai 答复的后端资源需求是非常高的，传输带宽只是流程上一个优先级非常低的环节，大概率不是性能热点

正经程序员也不会在业务逻辑耗时 2000ms 的时候扭头去想办法把 parser 的时间从 2.5ms 优化到 1ms 吧，虽然这是 60%的性能提升——对于这个环节来说

你自己造轮子，就会发现还需要自己定做轮毂轮轴，去做轮毂轮轴就会发现，还得去自己砍木头，自己去砍木头就会发现，还得自己造斧头，造完斧头发现需要自己种树苗……

你去买个轮子，就会发现只能用指定的轮毂轮轴，去买了指定的轮毂轮轴就会发现，只能用指定的螺钉螺母，用了指定的螺钉螺母就会发现，需要用指定的内六角扳手，买了扳手就会发现，虽然不知道为什么但是必须一起买一套地下修理仓库和一个大理石花园桌……

最后你轮子装好了，发现轮子可以在单车道上行驶，但你的路是两车道，轮子转不了

可能是因为音频维度低吧

图像是二维的，眼睛的脑补已经很强了，但是低于一定质量时识别内容会变得非常困难，即使是对于满足功能性的图片，也有比较高的清晰度要求
而声音是一维的，天然的码率就低，而且对于语言这种接近于非模拟的信号，借助脑补其码率需求可以低到非常扣扣索索的程度。比如曾经的 amr 录音格式，甚至可以以 5kbps 的全损音质录音，而你还能听懂录的是啥

对于娱乐需求，质量的要求反过来了；按照水果的说法，解析度满足视网膜屏的标准后，再提高图片质量意义并不大，哪怕继续探求全色域 HDR ，由于技术原因并没有形成巨大需求；反倒是由于带宽的普遍提高，一般档次图片的流量越来越大，反向刺激了编码技术的发展
而 hifi 领域则可以说是无底洞，但是由于其特殊性，更多对质量的追求体现在硬件上，再加上图片创造者（广义上）远远多于音频创作者，其流量的大小远不足以刺激编码技术的发展

说到流量，除了流量，单位时间流量（生造词）也是影响编码需求度的重要因素。
由于视觉输入很快，图片的单位时间流量可以高到近乎无穷，滚轮一划拉，几十上百张图片就过去了；而不管是视频还是音频，都只能以 1.0x 最多 2.0x 的速度播放。一曲 20M 的无损音乐你能听上几分钟，而 20M 的高清图片只够划拉几秒，20M 的网络视频也能放几分钟……但是由于高清和 4k 显示器的出现，这个时间也在逐渐接近几秒
就这样，音频卡在了中间的尴尬地位，码率挺高，但又没有高到现有技术无法承担的程度，并且目测也不具有继续增加的趋势

对于这种问题，一般来说最经济合理的解决方案就是：不解决，凑合用

网页和代码肯定不能忍
但是 IM 里的错字...知道为什么叫 IM 吗？ IM 就是 Instant Message, 你是那种平时买个包子还会纠正老板走调和破音的强迫症？

没有。不过有轮子
https://github.com/adobe-fonts/adobe-notdef

只是想看效果可以用 BabelMap

在那个超级兔子当道的洪荒时代，还流行用这种办法隐藏快捷方式箭头图标……

有个原始办法就是把相应的图标用透明 png 替换，你搜一下这个箭头对应的文件或者注册表位置

这个我熟，由于未知的原因，所有的组合键都需要手动控制按下状态才能生效
```
>!p::
{
KeyWait RAlt
Send, {LWin down}{LShift down}s{LWin up}{LShift up}
return
}
```

可能某些坛友对这种行文风格还不太熟悉，可以参考一下这些例子

http://www.innovation4.cn/toutiao/064321-1923220718/
https://zhuanlan.zhihu.com/p/578669629

@Rache1 原来 gm 也有事件订阅，学到了

@sjmcefc2

start "" rar.exe zip1
start "" rar.exe zip2

是并行

rar.exe zip1
rar.exe zip2

是串行

顺便试试 CR 行不行吧
早该把这俩字符的排列组合通通视作换行符了, 又不是打字机, 搁着不兼容除了给跨平台添堵窝没看到任何作用

往好处想，起码有内容
总比内容农场一大堆“30 寸蛋糕多大 尽在 XX 网 让您持久坚硬 30 分钟”之类的结果要强

`解释性完整命名风格` + `没有自动补全` = `灾难`

浏览器啊文本编辑器啊图片查看器之类的常用工具都已经换成了开源的，用得非常爽，而且每个领域都有那么一个或几个扛把子级别的作品

但是输入法却一直没有一个扛把子级的开源项目，难道真的只是因为只有非拉丁语国家的人才需要吗……

老鼠卵子

听说 firefox 的主密码是 sha1 加密……和裸奔也没什么区别