我是力挺 rspec 的一派，因为我认为 rspec 完全发挥了 ruby 的高度定制 DSL 的能力，让写测试就像写文章一样顺畅
但我也充分理解一个对 ruby 不熟悉的人，或者母语非英语的人看到这些代码会一脸懵的情况，因为我刚开始用 rspec 是就是这样的

说回 ruby ，我认为其最显著的特点，是用**最简洁**的方式把面向对象发挥到了极致，当意识到 ruby 中任何定义的 class 都是 Class 的实例、`1+1`实际上是`1.+(1)`时，我才意识到什么叫完全面向对象的编程语言，你或许可以指责 ruby 性能不行，但了解过 ruby 的人一定不应该指责其语法不优雅

@epiphyllum 感谢你的耐心回答，是因为我没有重启就去 ditto 设置 win 快捷键导致的，重启之后就全都正常了

@epiphyllum 这个回答我搜到过，但是和我的需求不符，这样做会把 win+v 快捷键完全禁用掉，但我是想让 win+v 能唤醒我自己的剪切板工具

@quqiu 之前用 ahk 会被一些游戏的反作弊软件检测出来，并且我也不想为了解决一个问题而新增一个进程

@Kenyore Ditto, 用了很多年了

@fengf789645123 是的，微软总是做些负面优化

提供一个思路，临时起意的话可以分区游玩，先了解一下东京的区域划分，八天的话可以考虑上镰仓横滨这些周边地区，然后按照区域去找自己感兴趣的内容

住宿可以考虑一个地区住两晚，这样可以保证一个区域有一整天时间可以游玩，然后话换酒店的那天可以考虑上午在当前区域，下午去目标区域游玩（行李可以放酒店或车站的寄存箱子），举个例子：
比如行程是新宿=>镰仓=>横滨
第一天上午新宿 check out, 中午坐电车到镰仓寄存行李，下午逛镰仓&酒店 check in
第二天一整天可以去镰仓比较耗时的景点（比如江之岛，当然这个季节可能不合适了）
第三天上午镰仓 check out ，可以考虑白天再逛一逛，或者直接做电车去横滨寄存行李，在横滨玩

这样行程会比较宽松不会太累，我当时是去玩了 11 天，去之前也没做攻略，基本上是入住酒店再看小红书规划下个区域的行程，酒店的话只要加钱都有的住，实在不行也可以住网咖

我在使用时倒是经常碰到编辑器输入卡顿，吞掉输入的文字等 bug

@heihe 大概明白了，是不是可以理解成提高召回更多的是对 query 做处理，而 doc 只需要维护好分词词典就可以了，ik 分词器已经解决了大部分中文分词的情况了

@heihe 我的数据到不了每天几十亿，但是每天几百万的写入请求可能是有的，目的实际上也是减轻 es 的压力，顺便不确定 ik 分词的 ik_max_word 模式是否合适（这个倒是次要的）
不过看你回复的实体识别本身和分词没有关系，是不是可以理解成分词和 NER 是平行两条线，在将 doc 传入 es 前，先通过 NER 提取出关键词然后作为另一个字段额外保存，而文档本身还是在 es 中做分词处理（我一直理解的是 NER 是要基于分词结果做处理）

@heihe 我的想法整体和你一致，就是分词放到 ES 上游，分好的 terms 用空格拼接，ES 内部再用空格分词；只不过我在分词之后额外做一个持久化存储（ mongodb ），原因是我不清楚 es 保留全部_source 会不会对性能产生影响，如果只保留部分 field ，添加新 field 并要刷数据是就要用到（省去重新分词的步骤）


@lix7 其实我主要的问题就是分词要不要从 es 拿出去，一是不清楚分词插件能否满足实际情况，以及维护自定义词典的成本；二是对 query 改写，如果要做实体识别提权等处理，是不是也要先分词才能处理？如果是的话不如就全放到 es 外面来做好了，灵活性还会更高一些，但一想到 es 已经集成了，就比较纠结。
排序这一块不太确定理解的对不对，我理解的是粗排已经由 es 做了，即 es 的主要作用时召回+粗排。精排则需要自己在外部服务去实现，我想法是每次查询请求召回的数量应该比前端请求的数量要多，比如前端传 20 条，我则是查询 es 返回 1000 条，然后再对这 1000 条数据进行精排并添加缓存。但是需求中往往有用户指定按照某个字段排序的情况，这时是不是和粗排精排就没关系了

谢谢，准备试试 miniconda ，再问个问题，如果不动 base 环境，但想加一些全局的命令(例如 tldr)该怎么做