@haiku
是公司就会有失败产品，是失败产品就可能被放弃。只不过有人愿意分组拿出来说。Google 放弃的也不少。甚至用得好好的也会放弃。

我记得 v 站挺 g 的很多啊，反而骂巨硬动不动就放弃。

玩这种黑魔法没意思，双输。

我开 08 年的二手日产车，只是上班代步用，跑了十几万公里，成本 1 万出头，百公里 8 个油，只买三责。没什么毛病。

成本低得很。

我用 Sourcetree ，不管多少字符的分支名，都右键，Merge 。珍爱生命，远离命令行。

op 可以研究一下 azure 的后台的打开行为，就是前端控制模拟堆栈实现的。

@aheadlead #267
本质上跟大巴一样，区别就是比大巴开得快：因为上轨后是组队高速行驶。有的车厢直达有的车厢会经停。

@someonedeng #269
嗯，相当于这样。

@SparkQiu #263
你该不会认为我的方案是“有个车厢只负责从 A 到 B”，然后另外一个车厢负责从 B 到 C ，然后另另外一个只负责从 C 到 D 吧？

不会吧不会吧 [岳云鹏惊讶脸]

@SparkQiu #263
并不是说我跳进思维陷阱了，是你没有弄清楚我的设计。否则你看了这么多怎么看出我的设计让本来要到 D 站的人会让他们在站下来的？

@SparkQiu #263
我的设计并不是说进站必须下车，所以到 B 站时车厢上的 10 人并不需要下来，只有目的地是 B 站的才需要下来，然后其他也去 D 站的继续上车。

假设车厢能容纳 100 人，按你的情况，从 A 到 D 并没有坐满 100 人，所以到 D 这段只发一节车厢，一站站将他们接上来就跟现在的火车一样。

如果你的意思是车厢只能容纳 10 人所以才需要下车的话，那就意味着 A 出发到 D 的已经凑满，这节车厢可以直达不需要进站 B 站了。

AI 的话题打住不聊吧

@sunznx #4
应该还是大的，比如只有 S9 和 U2 上的 Siri 是在本地处理的。

如果你的手机也不是新的要稍微查一下是否支持最新的手表（我买了个 S9 ，的 7P 就被迫寿终了）

从今天开始停止使用百度还不太晚

@SparkQiu #258
上面是回给你的，AT 错人了。

@Chad0000 #258
如果你还不理解，那么我差不多退到原点：

我跟原来一模一样的卖票模式，一模一样的编排模式，除了进站的时候如果我这个车里到终点站的实际上已经满了两个车厢，那么这两个车厢我不进站了，他们继续前进，跟后面或前面的车组队。我剩下的车厢进站后跟正常一样占据整个进站通道，一样不让后面的车进来直到我上完车。

除了这两节满员的终点站旅客外，其他都一如往常。

那么，这些终点站的旅客是不是享受了直达不停车的超快速服务？
如果我觉得可以，那么我是不是可以小心地试试再动一动其他车厢，其他有满员的比如都到某个车站的，我是不是可以不停，反正这些车厢也不让上客了。
一点点就试出最优解了：当然你完全不用这么试，只有人才会这样式，在计算机中 1 秒给你模拟至少上万次。也就是计算机在拿到已购买票的旅客的数据后，直接就能算出怎么排车最优。你还觉得 AI （计算机也算）不如人吗？

@SparkQiu #257
你是从哪里看出来我的方案需要 A 站的等一天的？你想的是整个系统不通知旅客什么时候可以上车对吧？

错，系统卖票还是让你选出发和到达的站点，然后系统按以往经验安排频次，这样你买票的时候知道几点出发和到达。当天你的车厢可能就是从 a 到 d 直达的（买的人多就会发生），也有可能 bc 也停（买的人少就会发生），也有可能你的 ad 只是一部分行程（买得更少就会发生），里面有坐更远的。

不管系统如何编排，都能让你在指定的时间给你安排上你需要的车厢。明白了吗？