@lotux 你可以试试，说不定客服都不知道有这个邮箱。

不知道是不是厂家给客服的收入压得太狠，导致招不到稍微能胜任一点的人。我感觉 90% 以上的产品、服务的客服（从卖山寨货的店家到全国性股份制商业银行）都是一团糟，经常出现一问三不知、进入复读机状态无法交流以及给出错误信息的问题。所以我对 AI 客服很看好，虽然 AI 很弱，但现在这人工客服的平均水平还不如 AI —— 其实也不用 AI 这么高大上的东西，我真的宁愿厂家搞个知识库让我自己搜也不愿面对那些客服。

2017-08-11 刚出的新政策，可以注册 1-10 年，以前出 lifetime 价注册的会换算（不少于 5 年）

http://rotld.ro/portal/site_media/downloads/anunt_introducere_serviciu_mentenanta_anuala.pdf

这家代理还没更新吧？估计代理不会自己 cover 这些费用。

github 家出的 boxen

@congzi 建议你写一个真实的项目，无论设计多么粗糙，功能多么简陋，目的多么无聊，至少是一个完整的 demo. 完全看不懂你这个项目是干什么的，没有一个主题。

@hundan 某些医院的医生边听病人描述症状边搜索，可不意味着医生没用。法务工作者同理。初级的完全可以自动化。

@mrtanweijie 刚上线的时候事实上用了 GitHub 的样式。按你的说法，看来是被 GitLab 坑了。如果是按照 GitLab 改的话，那 GitLab 这样做也是不对的。但是 oschina 和 gitlab 的性质是不一样的。oschina 是商业组织，gitlab 当时还是纯开源项目（ GitLab 公司是 2014 年才注册的，真正组团队搞起来要到 2015 年）。相同的行为性质完全是不一样的。也就是说，尽管 oschina 不是有意抄 GitHub, 作为商业组织是不能把锅扔给 GitLab 的。

至于样式后来当然改了，我已经特意写了「刚上线的时候」。

@Tony2ee iOS，确实扫码比较慢（也许是我没耐心）。楼主说的其他问题倒是没碰到过（不过我骑得很少）。

s/大觉 /大家 /

@chnotaku 沟通过就行，听不听得进去就看别人了。我觉得还是要多说多沟通，不要觉得自己菜就不说。比你牛的人看你很少说，说不定也会想「我还是别发表意见了，一发声别人都不敢发表自己的意见了」。所以不想说总是能找到理由的。团队开放一点，大觉畅所欲言是有利协作的。当然个人也要开放一点，每个人都有不同的想法，尽量通过沟通增进了解，寻找共识，而不要强求别人都听你的（或者，反过来，你都听别人的）。

StackOverflow 上看到不少招远程的。

@imn1 结婚誓言那个赞同你的人很多，你到网上搜搜看。我以前也和别人说过类似的话，其实还好。不过发表观点也要看场合，你别在婚礼上或者别人热恋期说，这个不礼貌——还有，这个谎言只是大概率上的判断，不要拿来针对个体，毕竟婚姻也不是必然失败的，有部分誓言是成立的。

如果只是单纯不想做拉拉队的话，可以去和组织者说换个事，比如买水或者记分之类的。

不爽就不去。

商业联赛是另一回事。这种比赛，本来就是自娱自乐，不存在商业效益的问题。男生做拉拉队也会很欢乐。

oschina 好像一直不怎么重视这些问题. [2013] 年最后一天我就吐槽过 oschina:

> oschina 刚上线的时候，直接用了 GitHub 的样式——不是模仿，也不是像素级拷贝，
> 而是字面意义上的“直接用了”，甚至连 css 中的 github 字样也没有修改。

> 即使是现在，整个 oschina 的用户界面设计布局也和 GitHub 十分相像—— GitHub 用户使用 git.oschina，会有强烈的既视感。

> 除了细节处理没有 GitHub 精美外，GitHub 的各种酷炫的交互设计，比如键盘快捷键操作工单、唤出命令接口等功能 oschina 都没有采用。

> 毕加索有一句名言：” Bad artists copy, great artists steal.“（劣工摹其形，巧匠摄其魂。）
> 虽然 git.oschina 样式布局方面大量拷贝 GitHub，但显然没有偷到 GitHub 界面设计的精髓。

[2013]: https://segmentfault.com/a/1190000000374128

@xm1994 有法律效力的。北京、上海都有不少判例。但是这类诉讼确实比较难打，要求很苛刻。

不明白老员工有什么不好意思说的。说了人家不赞同是另一回事。当然，有些事情本来各有各的考量，不一定要强求一致。但是像那个 imageView 之类的情况，友善一点地沟通，一般都能接受吧。

代码重构，如果量比较大的话，可以慢慢来，碰到了就改，没碰到就暂时放着不动。这样逐渐重构不容易造成 regression, 也不用你加班。

@sensui7 另外，网上一些直接的回复，你不要太在意。

其实很多人是被《提问的智慧》一类的文章洗脑了。

《提问的智慧》主要讲如何提出一个好问题，讲得很好，但是它忽略了一个重要的问题：

人与人之间的交流，有的时候还是要讲一点礼貌的，特别是陌生人之间。网上打 RTFM 很容易, 但现实中你如果对一个不太熟悉的人说 Read the fucking manual, 如果你只是在玩梗那还好，如果你真的是这样想的，那其实是不怎么礼貌的。这会形成一种抑制交流的氛围，对协作（不仅是部门讲协作，网络的讨论其实也是一种协作）是不利的。

想象一下，你刚升级某个软件，同事随口问一句「这个版本有什么新功能？」，你回答「你他妈不会自己去看发布日志吗？」如果一个团队里都是这样交流的话，你觉得这个团队的氛围好吗？

而且，《提问的智慧》是有前提的，就是说开发者已经为开发自由软件花了大量时间了，你一个用户如果读手册能解决问题，那最好还是不要去挤占开发者的时间。

但是用户相互之间，还是少用 RTFM 为妙。别人问了一个初级问题，你没时间完全可以不回答，有时间可以回答，或者简短地说「我记得手册的 XXX section 里有写」、「 google YYY 」没有必要特意回答一句「你他妈不会 google 吗？」

@sensui7 打包 python 的话，Pyinstaller 和 py2exe 很方便。另外，其实写这些工具类的东西，Go 也蛮合适的（可以跨平台编译，最后的可执行文件里静态链接了库）。

with 的话，你猜得不够准。接触新语言，有时候靠猜比看文档要快，但你得猜准。猜不准的话效率就低了。不过猜的能力也是要练的。培养了猜的能力，是有助于下一个概念或者下一门语言的学习的。长远来看未必亏。

我这里提供一点猜 with 的思路：绝大部分情况下总是要关闭一个文件的，多打一行字倒还不算什么，关键是怕忘记关掉了，所以讲道理，类似 with 这样的东西设计的时候，不太可能不考虑这个常见的痛点的。

不过我有点事后诸葛亮。我当初学 with 不是靠猜的，而是靠看文档。但是呢，我后来学另外一些语言，看到类似 with 的结构，就能很快领会这个设计的用意。