不知道为什么总让我想起来 Windows Vista

平常的使用场景？以及有没充电桩？

至于能不能开 5-10 年，我觉得只要不是初代版本的车，能不能开 5-10 年看的是运气而不是车本身

“在大厂 MySQL 是不能用 Docker 的，为什么？”

关于这种已经带了立场且缺乏上下文的面试题，首先是不要带上你自己的立场去评判它正确与否，你应该做的是合理到位的去阐述你的观点。

无论是面试官还是被面试者也好，都应该知道这不是一道判断题，没有标准答案可言，在不同的环境、需求下会有不同的答案。

所以对于被面试者而言，你应该做的是结合你的经验、理解去阐述清楚，什么时候能，什么时候不能，为什么能，已经为什么不能等。

而对于合格的面试官而言，不应该去纠结被面试者回答的是能或者不能，而应该通过被面试者的回答来评估被面试者的逻辑思维、技术理解深度等方面的能力。

另外，对于被面试者而言，一定不要在面试中全程跟着面试官的节奏走，要大胆的打破节奏，表现出你的能力，面试是个动态的互动过程，不是应试做题，不要限于条条框框。

关于这类工具更换的调整动作，只有两种方式有可能成功完成：
1. 强制更换，忽略任何反对意见
2. 大多数人达成共识，逐步替换

2 这种方式要做的事情很多，首先要换位思考一下，换做是你，这种可得的利益/收获不明显（在他们看来），迁移的代价又不小的事情，如果不是你自己推动/有份推动的，你会很情愿去干吗？

所以，在没法强制推行的前提下，领头/推广的人一定要做好布道的工作，让大家理解迁移的好处；然后要建立好方案、HowTo 、Sop 等，降低迁移的麻烦程度，减少大家对这件事情的反感；甚至还可以通过人际关系来拉拢，等大多数人都接受并且执行了，这件事情也就差不多完成了。

倒是有 bridge 的开发经验

优点就是快，其它都是次要的，对于那些后端业务很轻的应用，AI 的加持下，几天就能搞完。

站在你的角度上的建议：
1. 通过增加单元测试覆盖率要求来减少测试人手这一大目标注定会失败。
2. 既然注定失败，那么你可执行的方案有两种：
2.1. 想通过写单元测试来提高代码质量，完全遵循 TDD （可选），并且编写有逻辑，有思考的“白盒测试”
2.2. 放弃通过写单元测试提高代码质量的想法，面向测试覆盖率编程，编写一大堆毫无逻辑，不用思考，全面覆盖的测试。
3. 可以通过 AI 去先提高代码的可测性/找到一种绕过当前测试困难的方法
4. 先有一个测试案例，然后告诉 AI 参考该案例来编写测试就行

我一般是 40ML/110ML+致死量的冰/冰水，也可以加奶球，你根据你自己的口味调一个合适的比例就好。

直接在交易所换成 SOL 充到你 Solana 地址不就好了

搁这写散文呢？

我的看法是看开发人员的多少，如果是一个人开发，或者一前一后，或者两个全栈，那就一个 repo 就行了，如果是多人的话还是分开比较好。

试驾完你心里估计就有数了

1. 她不是想工作，她只是一个人呆着无聊，你换位思考一下，把你扔到一个人生地不熟的地方，没有朋友没有能一起玩的来的亲人（你们俩不算），也没有喜欢的娱乐活动，你会怎么样。
2. 想工作只是表象，她实际想要的是打发时间，所有任何要学新技能/花钱的新工作她是不愿意去的（保洁对她来说并不辛苦）
3. 身体劳累不劳累时一方面，心理才是更要去在意的。

搬家这活，钱和心你只能省一样。

首先吧，会面试不表示会干活，会用 AI 面试更不表示会用 AI 干活，而且除非是面试方写明允许使用 AI ，不然“作弊”就是一种不诚信的行为。

itx + 无机箱风扇本来就很难压住温度，老老实实换机箱+风扇。

@vicalloy pocket 本来也不是运动相机的定位吧。

……你不先确认你这个朋友的数据可不可信吗