@raysonlu #27 https://github.com/xxh/xxh/wiki#how-it-works
其实就是自动化把你本地的 shell 环境所需文件全部打包封装好，再上传至远端专门的缓存目录，全程绿色免安装

你好，感谢您体验文心一言，体验地址: https://yiyan.baidu.com/welcome ，希望您在体验当中给予更多意见，文心一言邀请码：KFC-CRAZY-THURSDAY-VME50 ，2023 年 3 月 16 日 24:00 前有效。

@unt https://github.com/xxh/xxh 试试这个吧

xxh 介绍：你用别名、工具和颜色塞满了你的 shell ，但在使用 ssh 时，你会失去这一切。xxh 的任务是通过 ssh 把你最喜欢的 shell 带到任何地方，而无需 root 权限或系统安装。

MTM3NDY3ODEwQHFxLmNvbQ==
多谢 OP

@fishily1993 #27
确实要这样哈哈，至少在说出肯定或否定句之后，要补充一点点自己的见解意见，还要注意语速不能过快。否则，即使你陪着逛了一整个下午街去看对方的东西，最后都会说你怎么那么不耐烦，还不如姑奶奶自己找闺蜜来。

当看到有些犹豫的，就说一下能不能再尝试其他的然后再给个评价，甚至反过来拿其它的事物来进行反问，这样你可以旁敲侧击知道他人心思是啥，给别人有更多的选择，这样他人才觉得跟你在一起你是有参与感的体验，而不是让人感觉漫不经心。

总之，出现这种吐槽说道的时候，就是因为觉得你太过随意了，思想懒惰，别人考虑你了，你可以适当给些意见，而不是无所谓。要这样次数多了连你自己都会烦的，试想一下，如果你每问别人，他都说随便呀，都可以呀，还行呀，你累不累，你存在这里的意义是啥？别人问你是想跟你互动交流，过于草率确实会让人心头有些不快，女生的角度来讲就是你不用心，不在意。很熟的兄弟哥们，那就不用说了，懂得自然就懂，该出力的时候不会躲，能一起的就随性就行。

当然，自己确实兴致不高的时候可以直接说，要不就说自己有点累了，想一会自己去找点自己感兴趣的。或者要不交换角色，说这次都按照他的选择来，下次再由你自己来做主。

送你一张官方新闻是如何看待这个问题的： https://i.imgur.com/m3f8gUY.png
这个画面不拿奖就真可惜透了

🙏 🙏 🙏 快去，让我给你上香，听你敲木鱼

1. 有规律的通常是计划任务，如果遇到闪屏，看看计划任务列表里面最后执行时间是否存在吻合的
2. 或者是某个后台服务在定时执行，整个 procmon/ 过滤进程名，只看 cmd.exe ，查看 cmdline 启动参数和调用来源

哪个货多选哪个，功能都一样，现在谁还低头看键盘敲，有变化的几个键都是常用按键手区，双手放上去基本上都挡住了，难不成为了看一眼还挪开，而且越简单的越耐看


他喵更新就算了，主动更新大的补丁还能经常性失败，反而更新可选功能性的又可以。在睡觉前关机，上了厕所回来发现自己竟然重启到欢迎界面，真是气不打一处来

非推广，微信小程序里搜索“数据团+”，数据源是来自于搜索指数预测的，不具备科学参考价值

过来捧捧场，万一中了呢

最直接的方法辨识客户端身份就是通过认证，密码认证 /Token 认证，不会说你们接口调用不需要认证?

这种场景直接用 Kong 做 API 网关就好了，连平台都不用搭建，里面有 consumer 的模块，帮你把用户跟踪、访问控制都可以统一管起来，只需要为调用方创建并提供 consumer 对应的 key ，调用方在请求头部设置就可以，要觉得需要修改用户请求数据，也可以通过网关插件来改，然后透传给后端服务。

最狗屎的问题，我们也有类似的：
A 项目代码，仅供内部使用（实际上也算是客户），beta 和 lastest 标准化的版本均在其发布，项目主体团队自己消化，如果不是公司内部的，找个标杆的客户项目为主干来开发。
B 项目代码，基于 A 的 V1.0.0 版本，因对外客户要求，需要定制开发各类东西，页面样式改版，认证和组织架构变更等等，一般交给交付团队来实现。
C 项目代码，基于 B 的 V1.0.5 版本的某几个阉割后的微服务模块，也是一通改造定制，客户看中了 A 项目的代码，但因为 A 的代码早就不断更迭很多次，要同步上来就得 rebase 整理原来多次变更过的所需模块微服务代码。而前端代码则需要定制化开发，一般交给交付团队来做。
...

过程的东西，如版本发布，需要严格一点的流程管理，每次发布版本都要经过各角色评审，才允许放入制品库，不允许私自定义版本，所有版本需要控制输出。

如果团队人数>10 ，那么就不要一个团队干多个项目的交付实施的活，牵扯过多很容易出问题。分配几个小组（人数>3 ）分别负责不同的项目（ 3<n<5 ），主力核心则至少保证>5 ，因为个项目有些需求必定要核心成员来对交付工作做决策，并不是简单的做出来就不管，另外找外包或者专项招交付岗位的人来负责 1-N 个项目的交付开发工作

如果团队人数<10 ，原则上，每个人承担负责项目不要超过 3 个，不然离职交接和沟通就等着炸吧，项目多就多招人

项目和人多了真就不是技术规范能解决的问题了，必须要考虑流程和推进的工作保障，哪些项目由谁管理，怎么管。可以考虑从如何对人员角色划分和放权管理去下手。

另一条路就是售前和交付团队的有效沟通，让客户自愿吃下这坨，然后还说不出啥，觉得自己就是弱，你们做出来的就是牛皮，需求不满足那是自己还不会用你们的系统，做不到的东西是根本不存在这样的需求。

最狗屎的问题，