恭喜恭喜，新婚快乐

用起来试了一下支持中文是真的不错，对齐强迫症患者友好

新车第一年可能会被 4s 要上全险，我当时也是的。对比了一下我的（油车飞度），第一年我应该是 2k+，差异大概几百左右可能来源于车损价值低一点、地区差异；总体来说我角度上看你的保单也算是正常，但可以沟通下有没有价格上或者其他方面返还给你的优惠。
后续自己再买的时候我是车损+三者(200w/300w 看个人选择都可)，可对比多家看看谁给的报价更低，至于他们说的送的各种东西听听就行一般是用不上，最实际的是看他能给你返多少现金

参与的所有人都应该背锅+1 ，只是产品应该是最大的。作为开发，产品的这个应该算是很明显的不合理的需求，接到的时候最起码也应该去质疑一下确认一下。一般来说需求方能说服我的话我会照做，说服不了的话我会说清楚原因并且找上一级领导说明风险，不然出了事其实对大家都不好

只要电池是有标出 Wh 这个单位的，你都可以要求它按法规给你过。20000mAh 严格上来说并不是一个容量单位，还是要配上一个电压才能表明这个电池究竟有多大容量；一般所说的 20000mAh 只是 100Wh 按 5V 来计算得到的，只能说是没有表明 Wh 这个单位时的一个下位替代判断方法

以前我是很支持的，但现在我只能说各有场景吧。特别最近用了手表之后，手表弹个二维码给商户扫感觉更方便（其实手表也有 NFC ，但奈何和手机不是同一品牌没对应应用开不了）
以前有段时间很支持 NFC 包括用银联的 QuickPass ，但实际使用发现就是经过培训会选择用这个方式收款的员工其实真的是很少数，很多时间我支持但反而是商户员工不支持导致无奈放弃

的确要看智驾定义是什么，以及我认为以后是发展到 L3 甚至 L5 级别的辅助驾驶责任抛给了车厂我也是不会完全放任的，随时接管作为后备是我作为司机所应该的。按具体功能来说说我的情况：本田的非全速域 ACC+LCC+主动刹车，其中
1. ACC 一般是高速少车的时候才使用，因为我风格多变但不喜急刹，而 ACC 有一个问题是前面有一辆车突然变道插进来导致跟车距离不足就会急刹，这种情况我一般是预料到就会接管松油补一点点刹车避免急刹这样。
2. LCC 车道保持是常开，非全速域反而挺开心的，低速段我不用频繁关闭（因为低速段可能是在市区或者窄路但车道线还是有的情况，或者双向两车道中间虚线少车的情况，这种情况轻微压线开是很正常的。车道保持居中我觉得是极大程度让我可以放轻松的地方，特别是高速基本扶着方向盘，由 L2 系统来自动微调方向就很好了，不用以前开其他车时我要一直集中精神去左右后视镜不断确认是否会偏离得厉害来修正（毕竟高速的时候方向打一点就很容易偏很多）。另外尝试过在雨下很大的时候，快速路上的线我未必看清但 L2 自身可判断得清楚帮我稳住方向这点很好。
3. 主动刹车是常开的，但使用它的时候我觉得是你意识上不能说就依赖它，而是它作为我的一个后备辅助罢了。
至于现在很多智驾的其他功能，我是抱着积极拥抱尝试，但会比较小心选择是否接受长期使用。像自动变道这种，我觉得作用不大；你要说敢不敢我当然敢，但前提也是我会随时考虑接管而不是说就敢让这个系统去完成这个功能；另一方面自动变道、自动超车我觉得比较没太大作用，变道和超车考虑因素比较多我暂时还并不认为这些系统能做得比我好（个人主观意见），自动泊车这类我倒是觉得没太大问题，只要说这种场景由低速还出事车企能负责就完事了。

总之你要我完全交给系统任由它来控制我是觉得不 ok 的，但我抱着我随时接管我是那个 backup 的话那这些功能其实我都敢用

让不让不重要，不要并排就好了。只要不并排有超车空间，对我来说就不算挡路，人家有路线可超车走人就 ok

如果你的距离能一直被其他车插进来（不是超过你）的话，那我可能也觉得是你距离留大了，当然这个也不见得说是错的，毕竟安全距离留大一点对于自己行车是合理的但现实情况是可能自己开得不是那么舒坦。例如说插进来的车有一些很喜欢一插进来就刹车逼得你刹车。
我一般是有足够距离我就会变道超车，无论是否需要左穿右插，我只保证我变道时我观察它的车速我认为我能变过去和它保持 2 个车身距离以上我就会过。另外其实跟车的时候更倾向于你和前车是左右错开去观察前前车的车灯，用前前车的行为来预测前车行为的话其实一般并不会很容易导致追尾

今天路上竟然没想象中的塞车（甚至根本完全不塞车）

第一次见到楼主业务，恭喜楼主，做个分母

感觉看你自己的高频应用场景来设定就好了
我是经常看 log 要翻到文件的最前 or 最后所以映射成了 ctrl+home/end ，然后 dpi 键设定成了 win+L 离开工位一键锁屏 https://i.imgur.com/duWRpIu.png

简单来说问题是出在如上楼层所说的楼主你列的 4 种情况不是等概率的。展开说说其实是选手选择和主持人选择本身是分两个步骤，且非独立事件（主持人如何开还是依赖于选手选择的事件），这两个事件的总体概率计算如#10 所描述是合理的，楼主所谓的列出是隐含了 4 种情况均为 25%的概率所以不太对。
其实我觉得有另一个很简易的想法是：P(换了中奖)+P(不换中奖)=100%。那这里显然计算 P(不换中奖)是比较容易的，即只取决于第一次选手的选择，那就是 1/3 概率可中奖；那此时 P(换了中奖)的概率自然就是 2/3

大概率还是扎到钉子了，但是钉子很小很小一个，要是不将轮胎拆下来基本检查不出来的，我之前也遇到过类似情况。既然你知道是哪个轮子，你可以叫他们将那个轮子拆下来喷水检查一般还是可以检查出来的，然后直接就在他家补了这样，不然直接叫他们去查的话一般很少会主动给你拆轮胎去查。

@leaveeel 楼主的确可以试试 84 楼的方法可破。之前我老婆去建行开工资卡也是各种限制啥的，然后办了信用卡之后银行直接主动帮你提升储蓄卡限额以及各种限制。

感谢楼主，最近我也发现我的卡经常性网络时不时会断流一样，但另一张 sim 卡就还好。你这么一说我这张卡好像也很多年了，这就去换了试试

@FatSheep2020 #6 是的，多个任务就多个文件夹，每个文件夹都是等同于项目全量备份。其实这么做和在 svn 服务器上拉一条新的分支区别在于：
a) 如此做法只是在本地将两个开发分开，但实际的提交历史还是同一条，且 A 提交完后 B 再提交前必须要先强制将 svn 服务器上的新的提交都 update 到本地才能提交（其实也等同于一次合并过程）。但服务器上不用说改了任务 A 一部分，后续还要记得将变更 merge 到任务 B 这里，毕竟提交都是在同一条线上的
b) 服务器上拉分支就是服务器上先给你全量 copy 一份项目，然后将两个提交分开在 2 条线上而已。这么做的话可以令 AB 在开发过程中怎么提交都 OK ，可以保留更多的细节（相当于 a 在同一条线上提交可能就会不提交太细节了避免太多多余信息），最终再进行合并。这种做法和 git 大概有点类似？但我一直也没找到什么好方法可以很好在 svn 的线性提交历史里面找到正确的合并点

说到 b)中的合并点也不得不说 svn 的 merge 和 git 还是有点区别的。git 的合并总是会强制自动产生一个提交；而 svn 的合并并不会，本质上来说 svn 的 merge 只是很简单的将另一个分支上你所选择的提交所记录的变动直接应用在本地文件夹，本身就是基于文件/文件夹操作的，所以在提交的 log 里面是记录着哪些提交被合并了，而不是像 git 一样是一个单一的合并点。另一个核心点在于 svn 的提交记录是必须线性的，所以你可以看到有一个全局 svn 号，可以直接唯一定位到哪次提交；而 git 本身就是非线性的，从而对于多分支做法有自身的优势； svn 的线性意味着你要像 git 一样去理解操作的时候，其实最终提交到 svn 服务器上都会有一个类似于 git 中的 rebase 的操作 => 将分支的变更需要将原来分支点转成基于当前最新提交作为分支点再进行提交，从而线性化。

只能说 svn 和 git 其实底层是有一些逻辑不太一样吧，反正怎么舒服怎么来。我现在做法一般是本地可能扔一个 git ，用来维护日常的变动甚至非常小的变动，从而使得新版本在机器上万一改出问题比较好回退，同时 svn 上不会产生特别大量的信息。对于上述 a) b)两种情况其实我这里也是有混用的，一般例如说如果是机器硬件产生比较底层的变化，但大体上逻辑是一致的，那需要维护两个版本则我们会用 b)从服务器直接拉分支，并且更改时总是基于一条分支做主要变更，另一条分支不断用 merge 将变更同步过去就是了；而一般临时性或短期性的多个需求点的开发则会采用 a)这种方式，一个需求点搞完了本地这个文件夹就可以扔掉直接清理掉不管了。

说了这么多就顺便说到另一个问题就是像你正在开发任务 A ，但又有一个 bug 要改的 hotfix B 。在 git 里面也是直接拉分支比较方便的，但 svn 我倒是遇到一个问题在于 A 已经提交一部分了，这时候改 B 就不可避免在提交历史上 A 和 B 是穿插的。所以这里 svn 其实本身也提供了另一种工作流：项目一开始就建立发布分支和开发分支（当然还可以再建立多一个 hotfix 分支）。然后开发分支上做开发工作，这时候 hotfix 修复 bug 的话其实你提交在开发分支也没关系。基于 svn 的 merge ，那你需要 review 其实是发布分支，当你完成一部分功能或者修复了一个 bug 直接只需要将需要的提交挑选出来，直接 merge 到发布分支就完事了。这也是一种方法

其实 svn 也有 shelve 功能但的确不太好用，而且事实上我这边也有类似的问题，虽然我司没那么严格的 review 机制。方法也是有的，我这边有 2 种做法吧：
1. A 、B 任务同时开发，那提交记录必然是两者有互相交错；那就在 review A 之前将所有 B 的提交都 revert ，而将 B 加回来也很简单，前面那次 revert 之后会产生一次提交，只需要将这次提交再 revert 一次就 ok 了，这么做就是来回比较麻烦而且提交记录上有比较多这种 revert 再 revert 的记录
2. svn 的分支给我感觉上相比 git 的确是没那么好，但也有适合于 svn 的方式。那就是你在本地开发的时候，假设 svn 当前 head 的版本号在 1000 ，那就任务 A 和任务 B 分别建立两个不同的文件夹都 checkout 1000 这个版本（并不是开新的分支），然后在这两个文件夹内开发。这么做的缺点就是每个任务开发过程中就不好提交了，不然就和 1 其实是类似的，提交记录总是一堆交错。一个折中的方法是文件夹内可以自己用 git 本地管理，然后差不多了再提交一波大的到公司的 svn 去，这样子记录相对干净一点。
其实基于 2 当然也可以用分支的方式，分支的话 A 提交了啥到时候直接将相应提交 merge 到 B 即可。不过 svn 的分支+合并并不像 git 那么清晰；之前也和领导讨论过 svn 的分支比较舒服就是本地直接搞多个文件夹，然后文件夹内开发就是了