不只是大 A ，哥们，不只是大 A 。。。

@qrobot #83 感谢你的认真回复。
几个问题：
1. pnpm 是硬链接而不是软链接，性能损失肯定有，但是很小，基本可以忽略那种。
2. 打成 zip 或者任何压缩包以后，我不能理解性能怎么可能变好，难道说压缩包不需要 io 的吗？压缩和解压缩就不消耗性能吗？
3. 你发的 performance 的图表上，如果我眼睛没花，好像都是 pnpm 最快？是最底下的最快吧，别是我理解错了。

@cenbiq #223 不是哥们，哪来的“即使使用了多维感知方案却仍和 FSD 有差距”啊？这结论是咋得出来的？你拿 FSD 的哪一代和国内的哪个产品的哪一代，在哪个场景比较得出来得这种结论？

咱们都读过书，能不能别虚空对比啊？

她需要一点时间和空间，来接受自己的世界不是只有工作这件事这个事实。简单来说压力是来自于她自己，你能做的只有帮她认识到这一点，工作没有十全十美，压力永远不会消退，平静一点的接受，偶尔让脑子放空，多分一些精力和时间给生活中的其他事情。

承担全部家务不是帮助她分散精力的方法，买买买也不是，对于内驱力强大的人，要强的人来说，这反而会带来更多焦虑，会让她觉得对方付出了更多，而我自己还没有做的更好。多带她去享受生活里的很多小美好，逛逛公园，逛逛展，全城跑去吃好吃的，露营，短途旅游等等。用动作和行动让她切换焦点，不要用说教。也不要过于刻意的去营造这种氛围，尽量找到她能享受的点，去做引导。

当然这一切的前提是你们两个都觉得她已经在工作中承受了过多压力，才有必要考虑这么去做。对自己要求高，往往能带来更强的内驱力，配合极度的专注，也许才是她达成目前成就的一个关键因素。当你尝试让她去切换焦点以后，可能会影响她的工作产出，这也要本人接受这一可能的现实才行。不过当然，有的人也会因为切换了焦点，而让自己的产出更高的。

中间的方法是我实践过的，我媳妇以前是一个很紧绷着的人，现在放松了很多很多。可惜生育又给她带来了新的压力，哎。

也就是说取平均 100 克喝 25 杯算，100 克茶约等于 500 克咖啡豆了。可是 500 克咖啡豆好便宜啊。我还是只能喝得起咖啡。。。

这个不是应该用现成的 CMS 工具，直接搭起来就行吗？根本不用写代码呀。
项目管理工具应该也有现成的吧。

加一个针对这个异常的错误捕获，在捕获后弹窗提示用户刷新。

@qrobot #71
首先你把 pnpm 完全过滤掉了，根本没提及，说明你没用过？那么什么所谓把 yarn 当作一等公民的比较就是不公平的。

其次请帮忙解释一下 pnp 究竟是如何解决各种 dependecies 相关的问题的，以及它是如何避免操作系统处理文件碎片的问题的。第一个依赖相关的问题，即便是在解决这类问题最激进的 pnpm 项目里，也没有完全解决相关的所有问题。第二个文件碎片的问题，我不知道是你表达错误还是怎样，我不理解的是文件总数不变的情况下，它怎么解决了这个性能损失的。pnpm 增加了硬链接，肯定增加了额外的性能损耗，但是有数据支撑 PnP 比 pnpm 的硬链接提升了多少性能吗？提升的是什么样的性能？在多大的项目里会产生决定性的变化？

即便 npm 哪一天默认支持 PnP ，那也只是一个特性而已，就好比 pnpm 支持 worksapce 的时候也只是一个特性，没有什么所谓的公民一说，其他更上层的工具链在当时也能做好 workspace 管理，反而是 pnpm 的 workspace 确实做的很好，所以下游的上层工具才纷纷接入和支持此一特性。yarn 的 PnP 呢，我的天老爷，提出来多少年了，哪个项目建议你用 PnP 模式运行了？

最后，yarn 的稳定可靠是依赖于 dependencies 本身不作妖，不是 yarn 的功劳。老项目跑不起来只有一种可能，依赖链断裂，这种情况，yarn 处理不了，npm 、pnpm 也处理不了，不存在 yarn 能做好这件事这么一说。你可能没跑过 10 年前的项目，不好意思我跑过，yarn 也搞不定。你对这个问题的理解我觉得有问题。

请多使用事实来说明问题。比如我就知道 pnpm 是很早就支持了 PnP 的，差那两年有没有可能是因为 PnP 作为一个特性并没有被完善的定义？或者说至少它完全不是像你说的所谓“独特的”特性。

好铁的朋友，哈哈哈哈。
你非要帮他那只能帮他认清现实，和所有人都坦白，别搁这儿瞒着了。
家里有存款他非要信用卡套现，还套不明白都把自己给套黑了。你说后面他媳妇不让拿存款能理解，前面是为啥呀？啥家庭这么难养，有存款还非要用信用卡套现去养？这不是摆明了有隐瞒吗？
真的把人整笑了。

问个题外话，100 克茶一般来说能喝几次？就是说一般，一个人喝茶的话，一次大概放入多少克的茶叶？

@skiy #63 bun 支持的特性有缺失，不建议投入生产。

@qrobot #57 不是，你说了这么多缺点，那是怎么得出来它是历史上最好用的包管理工具的结论的？

另外 pnpm 老早就支持 PnP 了，但是目前我还真没见多少人给出这个模式到底解决了什么问题，产生了什么独特的优势，甚至其实就像你说的，它反而还很容易产生新的问题。

再一个我司 10 年前就重度使用 yarn 了，讲真，用了几年后真的不想再用了。yarn 的报错体系非常糟糕，兼容性在彼时也问题多多，出现的一些诡异问题，在社区是很难得到有效支持的，彼时 yarn 的理念导致了很多功能需要你自行处理，社区对此也很无奈。

直到 pnpm 出来之后，我才发现社区也能做出好的包管理器，功能上它愿意往前多走一步，从社区的角度来说他们也没有什么非常苛刻的离奇的理念，来阻止或者说避免去开发某一个功能。和 yarn 比，yarn 已经显得裹脚布了。

再一个 yarn 最大的问题是从 classic 到 v2 的变更，花费了过长的时间，同时还约等于交出了一张白卷。除了 PnP 基本没有交出什么像样的产品特性。

你现在去看 yarn 对 PnP 的介绍，你都没法理解它说的几点优点到底哪里算是优点。甚至介绍文档的最后还要极力劝解你：哎呀我们这个 PnP 真的不复杂，没事的，你试试吧。真的就让人很无语。

@cenbiq #209 你假设了一个前提，就是视觉方案还有巨大的提升空间，并且各家目前都没有在视觉方案上深挖。你的这个假设显然是不成立的。

中国市场实际只用了非常短的时间就把多维感知的智驾系统切换到了纯视觉方案的智驾系统，这恰恰说明了至少是靠前梯队的智驾产品已经把视觉方案做的足够好了，才能在拆掉其他感知系统之后依然能交付出高水准的智驾系统的。一个足以交付生产的车机系统，绝对不是像我改代码似的几天就做好的事情。

从国内市场来看，视觉智驾也明显比多维感知智驾要差一些，比如智驾靠前梯队的顶配车型依然是多维感知方案，大部分视觉方案交付的时候都只能先支持高速智驾。这就正好反向证明了，在提供差距不太大的智驾水平的前提之下，视觉系统只是降本的最佳实践，而非更好方案的最佳实践。

@cenbiq 也要符合经济发展的规律。

当你明知道多维传感能达到更好的效果的时候（现代飞机、战斗机已经完全证明了这一事实），并且经济效益足够高的情况下，提前拿出更符合未来趋势的技术方案，并且在过程中不断优化迭代，显然才是更务实的做法。

增加激光雷达、毫米波雷达，并不代表不需要发展本身就存在的视觉感知。

自动驾驶就是多加一个传感器就多厉害一分的事情，因为我们不可能假设增加的硬件设备是完全无用的，那么反过来只要它能提供任何一点作用，那对道路上的参与者来说，都会多一分安全。即便车的硬件设备或者软件系统不能提供足够的能力来对这些感知做出反馈，但是只要能给到驾驶者做参考，也一定是在普遍意义上给道路参与者提供更高的安全性的。

我刚提车两个月，跨年，在高速上来回了 3000 公里左右，那会儿还是智驾元年，我买的也是智驾第一梯队的车，车子本身的雷达啥的也是最强的，甚至我是特地为了智驾而多花钱买的最高配。

即便这样我也只敢在高速上车不多的情况下，开一小段智驾，一旦车流变大，我就自己开了。

更别说晚上把车交给智驾了。

提车一两年了，车的智驾公里数没超过 1000 公里。

因为我发现它的边界能力实在太差，我的命没法交给这么不稳定不可靠的系统。我只能在可能想要喝个水的时候让它暂代一下。

能抽象的人一般不会把它搞复杂，会把它搞复杂的人显然没做好抽象

@TheWalkingDead #144
你反应好另类，我以为普遍的感受应该是：百度 AI 吸收了好员工，做出了一坨 AI 屎。百度辅助驾驶吸收了大牛，做出了一坨智驾的屎。这充分说明优秀的员工在百度内部做不出优秀的产品，所以整个百度就是一坨屎，和优秀的员工无关。

基于以上这一点，我觉得完全无法用来类比小米能否做的更好。

当然目前市面上普遍没有符合人类需求的智驾，小米做得不好也是有预期的。市面上都是一坨屎的前提下，小米也没有开创性的成果，那当然就是供应链的技术了。