同意楼上的。这种贴发跟社交一点平台吧，别污染 V2EX 了。

AI 是一方面，我有时候觉得 github 太社交了，尤其是 issue/PR 页面。太多人过来开 issue 凑热闹和刷存在感；一个页面充斥着点赞 emoji 等各种花活； AI bot 进来后更乱了。

这时候发现纯 email 讨论和发 git 才能更静下心来写代码。

作为一个程序员，我认为 web 1.0 是互联网最好的时代。简单，自由。

看什么乐趣了，如果以结果为导向，或者俗点，以钱为导向，AI 绝对有快感。单单写 test 就省了不知道多少时间。

但是编程快感 AI 给不了太多。举个例子，有个跨文件重构的地方，cursor 也许一个 tab 直接全部解决。但是用 vim 花点时间写个宏或者调 quickfix 写个全局 cdo ，相信我，在看到代码全部改成自己想要的时刻，那多巴胺分泌量比 cursor 的一个 tab 顶得多。

刚毕业第一份工作用 mongo 干过，唯一遇到的坑是 mongo 当时不支持几十 MB 的文件。本来想修，结果当时带头人直接怼了用户不让存大文件。后来也有新同事说改对象存储更正规些，也被带头人怼回去了哈哈。讲究一个不到万不得已不优化。

@lucifer9 #7 我觉得这个思路很好, 谢谢. 我也认为肌肉记忆比软件更靠谱.

试了一下, InputSoucePro 确实可以 多谢水友

@anonydmer #9 那奇了怪了

@q000q000 多谢

升级了的朋友能帮测试下 safari 26 支不支持 zstd 算法不

https://www.daniel.priv.no/tools/zstd-browser-test/

不怎么写 js/ts 但是我经历过 multirepo 和 monorepo, 以及 monorepo -> multi repo 和 multi repo -> monorepo. 说下我的经验和看法.

总人数在四位数/团队数在三位数以下时, 我倾向 monorepo; 总人数>五位数, 我仍然倾向 monorepo, 但是实际情况往往会走向 multirepo.

我喜欢 monorepo 是因为
1. 技术上 multirepo 解决的问题往往能用更低的成本在 monorepo 里面用模块化达成, 不管是多语言还是多环境还是什么.
2. monorepo 能带来的便利, 比如版本管理, multirepo 往往难做到而且成本不小

走向 multirepo 的情况我认为往往是因为人, 不是技术
1. 法律风险
2. 团队分歧

不用低估自己的适应能力。之前我也觉得肌肉记忆难改，直到没忍住换了 colmak 键位。现在所有输入法和快捷键换了位置，也没觉得多难改。

我站楼主一边，不说为好。

喜欢较真的可以读读中国人的一句古话 - 水至清则无鱼。

我活越久越觉得这句话说得好，有大智慧。

以前有用，后来发现也有不舒服的 bug ，其中一个是某情况下跳转后莫名去 visual 模式

另外一个最不能忍的地方在侧边栏 UI 。比如最经常用的 grep 结果在侧边栏，这太窄了。vim 里面:grep! 默认是一整个 buffer 显示，或者在在 quickfix list ，看着舒服多了。file explorer 也是类似痛点，而 vim 里:Ex 直接一整个 buffer 看文件清楚得多。

说 MacOS 的大概和我类似。用 MacOS 入门 Unix ，然后逐渐用 docker 和远程服务器熟悉 Linux 系统，这条路可以。

Debian 我也喜欢，更原汁原味，也少了很多花哨。但老实说我年轻太好折腾的，对稳定不炫酷的事务提不起兴趣来。最后反而是在 MacOS 和 Ubuntu 上砸了最多的时间。

@ykrank #23 如果这样那当然要卸载，安都不会安装。

不能惯着这种软件厂商，否则后果不堪设想。允许了自动升级，过两天就是自动安装插件，自动运行各种后台。

赞同楼主

自己的机器自己理应做主，这是原则问题。哪怕真的有必要更新，也应该是用户主动选择。不应该有任何形式的自动化更新。