长期观看短视频会影响注意力和短期记忆，以至于严重时对电影这种慢节奏长视频感到无趣。
可以搜一下 "TikTok brain"，有不少相关研究。

https://m.weibo.cn/status/4892506347014260
可以参考陶哲轩的思路。你知道你自己去搜内容也会出错，那当然也要明白 GPT 也会出错，所以你可以把它当作一个思维发散模式来用。就像福尔摩斯会和华生聊天，华生的话不一定是正确的，但能启发福尔摩斯发现真相。

这个新版搜索我极其不爽
Code 搜索时按时间排序的功能被去掉了
Issues 搜索按 Update 排序，结果一大就会挂掉

主要是历史原因，最初的 K&R 版本的 C 还不支持 enum 。
后来 ANSI C 也没明确 enum 的长度，而是可以由编译器决定。
另外如果常量是 flag ，需要用 or 来连接的话，用 enum 也不合适。

图灵奖得主 LeCun 也在质疑，然后提了个问题： https://twitter.com/ylecun/status/1639696127132835840
7 个齿轮连在一起，顺时针转动 3 个齿轮时，第 7 个齿轮怎么转。
这个有人问了 ChatGPT 结果正确答上来了。

然后 LeCun 怀疑，这可能是他的问题被 GPT 索引了，然后他又提出了一个全新的问题： https://twitter.com/ylecun/status/1639690596364308482
7 个齿轮首尾连成环，顺时针转动第 3 个时，第 7 个怎么转。
有人向 GPT-4 问这个问题，一开始答错了，但是告诉 GPT-4 要一步步思考，GPT-4 就能推断出齿轮是被卡住，不能被转动的。

这至少说明它能表现出一定的逻辑推理能力，并不是单纯所谓 "搜索引擎+语义理解"

https://github.com/opencv/opencv_contrib/pull/3480 这里有人修复了

https://ys.mihoyo.com/main/news/detail/545
米哈游的原话是 “学习先进技术，从而把更好的游戏体验，以更低的进入门槛，带给更多的玩家。这是米哈游做游戏的一贯宗旨。”

翻译一下，米哈游的宗旨就是去主机游戏之类的门槛高的地方，把好的东西抄过来，然后给手游玩家玩。
那这确实做到了。

https://github.com/othneildrew/Best-README-Template
https://github.com/matiassingers/awesome-readme
多看看，选一些自己喜欢的模仿一下，没内容就就让 GPT 帮一下

人人网，当年有社交有视频有 IM ，结果一地鸡毛

@Jack1230 #17 把 "项目" 换成 "哥哥"，这就是一个标准粉圈评论了。。。

iOS 动态图片实际上就是一张 jpg + 一个 mov ，没什么特殊的。
楼主可以发个小米的实际样张大家分析一下。

@lesismal 先回复几个问题：

我提 UTF-8 校验说的是 string 类型的值，内部编码是 UTF-8 ，如果为了安全考虑是要做校验的。json 可以预先整个输入都校验一遍，而二进制格式需要解析出来每个 string 值之后再一一校验，不是说二进制就不考虑校验了。

simd 的支持现在都是动态派发的，就是运行时检测一次 cpuid 判断指令集，avx512 进几代 CPU 都是不降频的，不降频时才会用 avx512 ，否则还是 avx256 或继续降级，所以这个不用担心。没有 UB 的代码一般 O3 没问题，即使 O2 也相差不大。但这些都是细节，不重要。json/msgspec 性能对比其实也只能这样简单搞搞，实际应用里如果要转为用户定义的结构或者对象，耗时大头其实是在对象创建上。真要是自己用的服务又在乎性能，在 C/C++ 应用里 flatbuffer 和 capnproto 更合适，至少比自己 struct 序列化要靠谱，现在很多游戏也在用。

我认同你的后面的观点，这是市场占有率的问题。一个标准即使性能上烂，但流行到这种地步就会有越来越多的高手投入到这里来，做性能优化、做生态支持。但是一个标准用的人少，即使设计优秀，也很难吸引足够人才投入其中。

@duke807
我没看出你对 simd 或者其他数据传输格式有了解。你非要数据那我就跑一下。
以最常见的 twitter.json 作为测试数据 https://github.com/simdjson/simdjson/tree/master/jsonexamples

体积：相差并不大
json: 467KB
msgpack: 402KB

在手头 M1 上跑 simdjson 和 msgpack-c 来解析，循环 16 次
simd:dom: 759MB/s
simd:ondemand: 1604MB/s
msgpack-c: 948MB/s
msgpack 并没有明显优势，而且也没验证 UTF-8 编码。
另外如果 simdjson 在现代 x86 上跑的更快。

json 缺点一大堆，唯一最大的优点就是人类可读写，msgpack 并没有继承这个优点。

之前有段时间在 solidot 上看到过好几次凹语言的推荐，每次都要强调凹读 wa ，但我每次看到还是会下意识读成 ao 。

@duke807 看来你不明白 simd 是怎么工作的。。simd 在处理较长数据时才会优势显著，如果你把字符串拆分出来，再用 simd 校验每个字符串，就会因为需要额外对齐或者数据过短无法向量化导致性能甚至会下降的。

回头再来看看我们讨论的适用场景：如果你是对外的服务提供者，无论是为前后端还是客户端，那明智的选择是尽可能为`更多人`服务，用 json 是毫无疑问的。所谓小众格式说的并非是没人用，而是 json 已经是事实标准、占据统治地位，其他格式的支持程序、系统生态根本不在一个量级上。

如果你是给自己的系统选择数据传输格式，追修更高读写性能和更小流量，那还有 flatbuffer 和 capn proto 等所谓 0 解码耗时的 zero-copy 方案。选择 msgpack 更多的是那些过去 json 带来的惯性，并不是什么追新。

@duke807 接口方面，你不可能要求后端同学花费力气去专门为小众需求单独开发一个接口。而且即使对齐到 json 格式的话，支持多种格式也需要后端单独做开发和测试，这和运维同学改改 nginx 配置完全不是一个工作量。

我觉得性能方面你想当然了。simdjson 能用 simd 快速教研整个 json 的 UTF-8 编码，实际上现在解析速度也能达到 3GB/s ，甚至还能按需解析性能还会更高。msgpack 里面的字符串也是 UTF-8 的，但我没见有什么库愿意去写 simd 加速或者按需解析的。

如果你把应用范围限定在嵌入式，那和上面我们讨论的完全不是一回事儿了，性能又不是主要考虑的东西。如果你说没有 malloc ，那就算用 JSON 库也有很多允许自定义 allocator 或者自带 fixed memory allocation 功能的库，这完全没问题。

@duke807 如果你同时支持两种格式，那只能让功能向 json 对齐，msgpack 的额外功能就用不到，结果无非就是省些流量。如果再 gzip 一下，那两者连流量的差距都很小了，这只要在 nginx 配一下就行，对应用来说都是透明的。

如果说性能，正是因为 json 流行，现在各个语言都有一堆高度优化甚至 simd 加速的库，其他格式没这个待遇的。有特殊需求的，这里还有一堆二进制格式可选呢： https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats

如果服务仅限自己使用，那什么格式都无所谓，甚至自定义个私有格式也许在性能上更好。
如果你要给别人用，那当然要考虑最通用的，并不是每个人都有能力或者愿意去兼容其他更小众的格式。
何况 msgpack 在性能上并没有明显优势，不一定比得上 JSON 压缩+simdjson 。

在这个 json 已经是数据交换事实标准的情况下，你给别人提供服务用 msgpack ，那才是没眼光。

换小众浏览器，比如 Opera 、Brave 、Vivaldi 。但公司还是能记录你访问的域名和流量，只是公司一般不管罢了。
正派做法是不要再公司设备上做私人事情。。