失踪人口不定期回归了哈，不定期年更了哈~

失踪人口不定期回归了哈，不定期年更哈~

晚上在群里看到一个有意思的视频，值得bb几句。由于发布者是互联网某名人，就点进去看了一下，发现这事可有意思了。视频参见下图，建议先移步视频号看完完整视频。

（这是图片，不可点击，哇哈哈）

假设读者已经看完相关视频，继续bb。简单来说，up主遇到了地推级别的扫码诈骗，并扭送对方到了派出所，这个扭送厉害了，必须点个大大的赞！

事情不复杂，但是，里面有几个细节值得琢磨。关键点在于辅助扫码环节，作为最早掺合设计这摊逻辑的人之一，想不注意到里面的猫腻（问题）都难~

阅读原文

跳转微信打开

看图说话，我说你画画画，你画我猜猜猜。

先看图，再说话。

最近玩几个新发布的工具上头了，无论是看别人玩还是自己上手，都是真的太好玩了，太有意思了。

说问题，你认为AI把这个图画对了吗？先别着急回答，很可能答错哈。

如果不小心试图从目前AI框架的技术实现原理角度来理解这个结果，就会发现答案应该是画的没毛病！

在目前这套AI框架的数据世界里面，“人”就是一直坚持不懈地这么教它的，教了好多年：这玩意他妹的就叫饺子，而且是通过反复上显卡调教出来的！从概率计算结果来理解，饺子的概率就是远高于其他可能性，嘀！那个看起来像笼子的碗也是同一个理由出来的。因此，AI画的完全没有任何问题！

嘿~（简单粗暴的略过如何改变这个计算结果，因为探讨下去，很可能会涉及到更深层次的哲学伦理问题：要不要给AI打上思想钢印，要不要...）

AI画对了！同理，扩展到AI编程、AI视频、AI PPT也是一样的。关键是，这种风格太尼玛上头了，简直就是一种“艺术”。

相信目前大部分人都开始把AI看作一个应该能帮得上忙的工具，激进一点的看成差不多可以替代你工作的工具了。那么作为工具的使用者，你更应该知道它能干什么，它不能干什么，对吧！特别是当这个工具是你专门人肉纯手工打造，专门用来适应自己特殊操作癖好的，那更是自然就知道这玩意的工作原理，不然后果不堪设想呀！

划重点：如果一个人不能正确能认知一个东西在另一个东西眼里是个什么东西以及为什么这个东西会认为那个东西会是什么东西，那大概率这个人也用不好这个东西。

挺好玩的，确实挺好玩的，有点上头，每天不玩睡不着觉。

阅读原文

跳转微信打开

看图快速回答问题

看图，请快速回答问题：这是什么摩托车？

俗话说开局一张图，剩下全靠编......高尔基说过，只有先把基调定好，才能确保不翻车~

起因来自一个玩笑，龙某大师傅因为频繁访问443端口，于是被某防护系统警告。于是本人果断甩出一张图，想请这个系统判断一下，这是什么摩托车，不要求给出型号，猜出品牌即可。

难不？不难？

其实，上面问题就是一个典型的特征计算过程，但是很不幸，计算过程中会遇到以下几个典型问题：

• 大部分系统的关注重点焦点不会在车上，不会在车上！那会在哪儿呢？

• 这是一个计算目标可能就有根本错误的问题！
  很大概率根本就不是摩托车，如果硬要系统给出一个摩托品牌，结果大概率能拿到几个，至于准不准那就......
  

• 这是一个限定领域的计算问题，需要综合判断其他特征，但是画面内能提取的特征太少！太少！需要增加一系列辅助条件。而且需要注意，辅助条件大概率是假设条件！
  比如，有朋友会注意到汽车的车牌：云A，还有街边的植被环境，可猜测是云南，因为云南大部分地区不禁止摩托车，所以给出一个摩托车品牌的可信度会大大增加......
  比如，有朋友会进一步发挥，也有可能是云南车行驶在广东省会啊，因为省城禁摩，所以应该是电动车...那...这个目标问题岂不是给不出答案了？

• 因为车头没有拍到摩托车车头的典型结构，但有没有可能是一部精心伪装过的小排量摩托？

• 大部分正常人会告诉你：这是电动车！

• 但是，绝大部分基于特征计算系统，会强行给一个摩托车识别结果！

好玩不？搞笑不？

但是确实又很真实，而且还在真实地发生着。

所以不要迷信任何基于特征计算的系统，是任何！

段子讲完了，按照本人一贯尿性，此文禁止联想！

阅读原文

跳转微信打开

这个号...终于更新了哈...哈哈哈

先说为啥食言了。

很久之前曾经diss过订阅号的新排列方式，认为采用的弱智推荐算法，会非常不利于中小用户的推广，等于是否定了当年那句著名的“再小的个体也有自己的品牌” 这句。

我还放言这个推荐不改，我不更新...

于是1年多没有发1篇...

但是今天不得不食言了，原因是被伟大的2胡同学推荐了一下，有幸跟众多大佬出现在一起，看到1年没有涨过的粉蹭蹭往上跑，吓到了，感觉不写点啥出来，对比起lake2的列表~

阅读原文

跳转微信打开

曝光一下最近折腾的小玩意

自制最简单的电吉他无限延音+激励回授外挂

原文发在了gc上面，这里也贴一下。

=====================

先上2图，给大家看看啥叫无限延音外挂。
最近折腾这玩意，目标是用市售最便宜的电路板搭出来一个无限延音系统，必须够灵活，单节锂电池3.7v供电，也就是得省电才行。
实现的效果：
1. 无限延音

2. 激励回授，可以通过琴体音量钮控制回授大小
3. 手持共振喇叭靠近拾音器上方，会有惊喜出现（暂不揭秘），另类玩法
 
我前后做了3套，内嵌到半空心吉他里面一套，就是之前我发过贴无聊自制的那把半空无头琴。不过总觉得不够环保，不够方便。继续折腾外挂方案。
照片上展示了2套外挂，右边檀木外壳的是第一版，尺寸大了点，因为为了调试，全部用了接插线。第二版就是正常焊接，也就是左边那个铝壳的，一个打火机长度，串接在琴身和吉他线之间，有开关，可以随时关闭打开。
没有采用琴体埋线圈的办法，经过验证发现这个是真的没必要！用木吉他加震套装那种共振喇叭不香嘛？没有纸盆，不粘在平面上自己基本没啥动静的那种喇叭，目标是把弹奏的声音反馈回来直接震动琴体，从而持续带动琴弦振动。琴体振动起来，手感也会非常美妙～
铝壳的上面带2个旋钮，1个用来粗略调节共振喇叭和的输出音量，1个用来精细调节前级放大板放大倍率，这样会比较容易找到无限延音的起点卡在那里。
电路部分比较简单，前前后后试验了各种成品电路，发现还是lm386最好用，耗电低，放大倍率够高。需要改动的地方只有2个。把R1地方换成10k的电位器，用来控制放大倍率，可调范围大概是几十到200倍，板子上自带的那个电位器引出来，不换也行，就是调整起来麻烦点。

（我叫LM386电路原理图）

（成品LM386电路板长这样，输出的座子要焊下来，太大了）
但是只有lm386还是不够，不足以产生让共振喇叭振动琴体的能量，后面加一个后级板，这玩意可选的很多，比如下面这个号称8002的小板子。

共振喇叭试验了好几种，最后发现这个4欧的比较合适，双面胶粘在白色圆盘上，然后在琴身上找个地方沾下去就行了。

总结一下用料造价方面：
  锂电池 厚10 宽20 长50规格，容量大概1000mah 13块
  m386成品板  1.7元
  8002成品板   1.8元
  usb电池保护充电板 1.58元
  铝外壳 32x32x8 cm  10元
  共振喇叭 4欧带外壳 16元
  3.5插座，6.5插头/插座，开关，电位器这些就不计算了
总之是足够便宜，足够有动手能力的闲人自己去折腾。
需要注意的地方也简单说说
1 后级板如果选用BTL方式的，注意喇叭的输出插座不要有任何地方跟外壳短路，哈哈哈，可能可能会烧放大板的，只是可能哈
2 吉他输出到电路板输入这里，最好中间加一个隔离电路，不然会对输出音量有点影响，不过影响不是很大，照片上的2个我都没加隔离（内嵌琴体那套加了）
好不好玩，试试就知道了～

不附送效果演示视频，动下手就知道了哈～

阅读原文

跳转微信打开

蹭个热度，我也说说部署蜜罐系统那点破事...

提前声明：本文不说打穿蜜罐的那些破事，哈哈哈，失望了？没有？

众所周知，搞安全的都喜欢部署蜜罐系统/钓鱼系统，一般是丢在内网玩。除非是有实力，而且是非常有一腚实力的才敢放外网，不然呢？大家都看到xxx被爆菊了吧，哈哈哈～

所以，传统安全领域里说的蜜罐，咱就不说了，讲个不太一样的用法。

这个其实是个旧事，距今大概10几年了。那时候高草还在邮箱部门搬砖，重头构建新的安全体系。说重头做，其实都是被逼的，全TMD是被逼的，原系统基本没啥架构可言，破腚百出...

当时花了好几天时间，做了个半年计划，写完了自己看着PPT总觉得缺点啥，总感觉有一个环节没打通。

当时的情况是，每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点：量大，重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来，归纳总结，用算法（当时不流行说AI、深度、神经病算法这些）分析分析。

这事苦恼了好久也不知道怎么搞，索性静下心来人肉分析样本。于是，从系统各个环节采集样本，大概有几百万的规模。等都看完，问题有答案了，办法自己就来了，你说神奇不神奇！

咱直接在前面协议交互时，从HELO开始，就把那些发送给不存在人的邮件都收下来。在正常的协议交互里，自然是会告诉你这个账户不存在或者系统错误，然后byebye断开连接。这里可以做点手脚，另外找个地方继续往下走，邮件体咱都存下来，然后内容+行为分析下不就行了!

嗯，当然为了增加点迷惑性，还得加个随机，一会账号存在，一会账号不存在。

这个做法开发量非常少，很快就能上线，内容行为归纳总结的模块基本都是现成的，怼进去就行，把发现的异常样本按照出现数量排个序，定期更新，ban就是了，都不用担心会存在误判。于是，每天80%-90%的垃圾就这样被搞定了，哈哈哈～

为了方便非邮件系统圈子内读者的理解，这里稍微解释一下。逻辑是这样的，正常的邮件系统肯定是知道准确的收件人地址，手误写错地址的情况有，但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境，黑产灰产还是采用基于字典广度覆盖的方式比较多。所以，在系统侧会发现，每天都有数目庞大的不存在地址探测。只是，正常情况下，这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”，然后断开了，不会往下面流程走。

咱既然是要做个蜜罐，理论上100%都采集下来也问题不大，当然大系统就不推荐这么干，浪费资源不说，你这系统咋啥地址能收到呢？对方一眼就能发现问题，所以，设置一个不大不小的概率肯定是必须的。

至于存下来后面接的东西，无论是交互行为分析，还是内容分析，都不是什么难事，直接略过。

这套蜜罐直接对外网服务，按道理是不妥的，要解析内容就会遇到很多未知风险，如果给开了shell那就更sb了不是。所以，进入到后期分析之前，还是要做一些必要的过滤处理的，该丢的先都丢掉，也就是只解析一些我们感兴趣的东西，一般只要包括文字、图片、JS就行了。但是，JS不要解析不要解析不要解析！

说到图片，必须多讲几句，图片的处理库当年还不是那么多，开源的就几个，也不是很好用，都有一些大大小小的兼容性问题，core掉还不是大问题，单是溢出开shell都已经有很多了。咋办？完全重写肯定不现实，所以高草当时做了一件几乎不被开发理解的事情：把几种主要格式的处理库都剪裁出来了，重新包装了一遍，第一层必须是对buffer做限制性复制，然后才丢给相应的解析库处理。格式也不多，干起来也不难，BMP，JPEG，GIF...也就那么几种格式，很好搞。

至于剪裁解析库这个事，其实不需要过多解释，搜一下过去几年的开源图片处理库漏洞，比如imagemagick库给人家弄出来多少远程shell，你就知道那时候我在担心啥了。反正该做的都尽量做好，剩下的就是更衣沐浴抽根烟上线。

故事讲完了，这里说的这个蜜罐系统的做法，只是想说一句蜜罐其实也可以这么玩。不必纠结，蜜罐是好东西，小心用就是了，哈哈哈～

谨以此图，献给对蜜罐又爱又恨的朋友～

阅读原文

跳转微信打开

利用/proc//exe恢复被删除的文件创建

$ cp $(which cat) /tmp/some
$ md5sum $(which cat) /tmp/some
7dae2782851e077091a2980d986646a2  /usr/bin/cat
7dae2782851e077091a2980d986646a2  /tmp/some
$ /tmp/some /dev/urandom > /dev/null

$ rm -f /tmp/some
$ ls -l /tmp/some
ls: cannot access /tmp/some: No such file or directory
$ ls -l /proc/$(pidof some)/exe
lrwxrwxrwx. 1 scz scz 0 Aug 14 17:44 /proc/56823/exe -> /tmp/some (deleted)

$ cp /proc/$(pidof some)/exe /tmp/some.recover
$ md5sum $(which cat) /tmp/some.recover
7dae2782851e077091a2980d986646a2  /usr/bin/cat
7dae2782851e077091a2980d986646a2  /tmp/some.recover

后面的内容与标题无关，但其实后面的内容才是本文的要点，因为我要开始胡说八道打广告了！

先看胡珀给某人写的列传:

再看胡珀给某人写的简介:
马传雷，著名白帽子，又名马三、三叔、flyh4t、马院长，蚂蚁金服业务安全专家，曾任同盾反欺诈研究院院长、腾讯安全应急响应中心（TSRC）负责人、绿盟安全技术总监，著《互联网业务反欺诈之路》，号“业务安全之父”、TSRC终身荣誉顾问（世袭罔替）

下面是我关于马传雷的描述。首先其自称PHP程序员，我不懂编程，不知道这是拼音首字母缩写还是啥，总之，这位天天给我说PHP是最好的语言。虽然我们宇宙虫族的精神图腾不是这个，但我有几刻也就假装信了。其次，这是我见过的少有的义气之辈，非常之义气，由于事涉个人不便细述，总之在安全江湖中交游极其广泛，为人极其热心。第三，跟前面列传所述不同，这位肚量似海，为人宽厚，正常情况下我会叫他传雷，不正常情况下我会叫她马大妈，你们仔细看看照片，就知道我说的才是真实情况。。他是2007年来NSFOCUS的，跟我有过长达7年的同事关系，后来南下去负责腾讯TSRC，再后来去同盾工作，现在去了阿里。他负责TSRC期间，我还给他贩卖过若干高手，也曾拿过腾讯的荐人费，哈哈。

今天的广告是:

购买链接在此:
https://item.m.jd.com/product/12946188.html
或进点击"阅读原文"进行跳转。

阅读原文

跳转微信打开

讲个养鱼的小故事。

本人养鱼有段日子了，讲个小感受。

最近喜欢一种叫地图的鱼，个性很有趣，而且长的够丑够凶，个性堪称鱼界哈士奇。吃饱了就趴着，平时可以摸，能跟你互动。但是每天要吃肉，饿了就喜欢咬东西，嘿嘿，可能也包括你的手指头，喂的时候要小心。别问我为什么知道～

地图大概就长这样：（图片来自互联网）

花鸟鱼虫市场直接买了4条，大概都是30cm长的。为了不中招，购买自不同店家，可看成基本不是在一个缸里生活过的背景不同的鱼。

美滋滋带回家。没先观察就都扔一个缸里了，犯了个错（为啥？往后看就知道了）。

第一天很都老实，相处平安无事。第二天熟悉环境后，开始出现互相攻击，具体来说就是有一条缸霸出现了，打得其他鱼浑身是伤，鳞片到处飞。

没过几天，陆续出现被咬死的鱼，特征就是身上没有一片完整的鳞片了！尝试用隔离洞洞板隔开，但是效果不大好，人家会越狱！直接撞歪隔离网或者越出水面跳过去打！直到最后，只剩一条了！只剩下最生猛的那条了！

所以问题来了，我这鱼养的，现在算血亏还是血赚？

鱼缸就是个小社会，也许大家都一条鱼，你所在的公司就是一条鱼～很好奇大家的观测角度～

阅读原文

跳转微信打开

聊个有点玄学性质的话题...

晚上跟朋友聊天，聊到一个话题，觉得挺有意思，整理一下，出个小短文。

对于一个请求量过kw、亿级别的系统，快速安全响应一直是个大难题，这里有没有啥玄学骚操作？能不能做到30分钟就做出一套响应？

这个问题很好玩。不妨先简化一下，以一个IM系统为例试试看。

大家都知道，对于一个负载比较大的系统，快速响应机制一向是圈内爱讨论的话题，无数人踩坑爬起再掉坑，周而复始。

这里说难是肯定难，而且巨难，必须先承认不可能所有事件的策略响应都能做到30分钟。但是要说简单，比如针对常规常见的“掉坑”套路，做到30分钟其实还真不难。做到2个步骤，基本有戏。

首先说系统架构上要满足的条件。一个大的IM系统，本身架构必定是多层，逻辑上复杂的嵌套也基本避免不了。因此，安全系统的位置就很关键。

假设这个IM系统有如下几层：

s1-s2-s3-s4-s5

一共5层逻辑节点，是串接的。

那么问题来了，安全策略的配套接口放哪里？

按照基本常规玄学方法论操作，一般会选头部层或者中间层随便布置一个泊接点就行了。但是你这样做，基本也就跟30分钟快相应无缘了。为啥？无非是逻辑部署位置死板，容易出单点绕过等问题。至于能不能承载你的策略逻辑更受原本设计功能限制。

不妨考虑这样一种做法：增加一个数据接口层，与上面提到的5层平行，看成这样就行了：

s1-s2-s3-s4-s5

d1-d2-d3-d4-d5

这个增加的数据干什么用？只做一件事：转发！只做非常初步的统计运算数据，必须能实时转发关键数据字段，禁止做复杂逻辑操作，尤其是不能有占CPU和磁盘I/O的操作。然后再并行数据层后面怼一套接受数据的服务，做进一步数据整理，整理出来的数据进准实时大数据平台(最好是内存系统)。这里就不展开具体怎么做了，办法很多不难做到。

然后在s1到s5里面，至少要选2个位置布置逻辑操作落地的接口（也可以5个都部署处理逻辑代码）。要求代码务必简单，比如只有对流过的数据字段做简单条件判断，只做过和不过这种操作。关键就在于一定要有至少2个地方可以插手。目的是避免被各种玄学因素影响，直接造成单点绕过。多一个能下手的地方，多一重保险。
至于在系统架构的设计上直接舍弃嵌入或者嵌合，采用并行（也叫旁路）的做法，就是基于一个基本共识：安全系统的处理逻辑和运算不能对原始系统带来性能上的干扰。此处省略也不继续展开，反正首先要保证系统崩溃跟你无关，不背锅哈。

这样，系统架构上的有这些基本就行了。

然后，就是数据分析和处理的问题。想要做到30分钟内上线安全策略。目标必然是人工快速响应，能动用这玩意的，必然是自动系统已经失效的东西，此处说的肯定是需要人工参与的事件。因此，最大的瓶颈肯定不是处理人员经验问题，白白浪费宝贵时间。真正的瓶颈，只会发生在数据分析和运算阶段。10年前，这里还没有啥通用平台可用，得自己开发。但是这几年，各种准实时并行数据平台多的是，选一个适合你的数据类型的就行了，这里也就不展开了哈。

前面说过，目标是至少kw级别请求负载的系统，那么数据量一定非常恐怖。怎么处理才能做到分钟级？简单来说，银子投入够了，内存、磁盘够用，这里并不会成为问题，但是一般安全部门预算有限，所以必须对数据做合并、剪裁、变换等一系列骚操作。目标只有一个：尽可能多的保留核心数据字段和有用字段，而且经过旁路接收到的数据条目，在经过至少1轮处理后，最好能降低1-2个数量级再写入内存或者落地。自然，降低处理规模的好处也不必多说。

然后就是常规的数据分析步骤了。套路多的是，对应急操作来说，只要关键数据能快速获得，定位问题发生点，那么对应的应急处理办法并不难找，因此这里也不展开讨论，熟手肯定知道怎么搞。

必要的系统化改造其实就这么点，2个步骤：旁路转发加数据缩并落地。

下面用一个实战例子来看看怎么玩转。比如我们就用常见的IOS特殊字符崩溃的例子。想彻底解决，这里肯定是需要依靠水果的系统更新或者终端APP上面的特殊处理，应急处理自然不是干这个活儿的。

应急处理的目标假设被定位到消除APP收到这些字符就崩溃这一点上，那么经过分析旁路系统对上面5层流转数据字段的快速分析，完全可以分钟级拿到影响面评估（主要是给老板看的）。再经过码农的基本测试，比如碰巧就发现在发送到IOS APP里赶在显示之前，把字符串做个转码或者每个字之间加个不可见字符之类的骚操作，就不崩溃了（当然直接隐藏/删除掉这个字符串也可行），于是应急办法就有了。然后选2个合适的节点，把对应逻辑加上去看看。一套步骤走下来，行云流水哈。

从整体来看，接到问题、完成数据分析、找到应急办法、配置上线，整个过程在30分钟内完成，貌似并不是很难做到，对不对？更多的细节这里就不深入展开了，感兴趣的朋友也可以发私信讨论或者不吝赐稿（如允许，本号一定用作者身份发布）。

阅读原文

跳转微信打开

2020年第一篇~

意外意不意外，惊喜不惊喜~

一晃都4月中了，本号终于继续更新了哈。想不到吧，2020年度的第一篇竟然是这个题目，哈哈哈~既然是2020年的第一篇，那必须求变，全文不配任何图片，嘿嘿嘿~尾部图片也不放了~

=====================================

话说，订阅号列表这个几十年不变的玩意，最近这1年多竟然出现了连续变更。观众们也是说好的说不好的都有。其实往根儿上分析，无非是突然动了大家习惯已久的呈现方式，肯定会有很多忠实用户喊不习惯，原来不怎么用的反倒是无所谓，说不定还挺喜欢。

简单回顾一下，最早的订阅号列表是严格的timeline排序，早期有过大图标，小图标，带简介和不带简介等非常细微的变化，总之严格按照发送时间排序是最根本的特征。由此，演化出这是在强调个体品牌的概念，风靡一时，抓到了精髓的各大V一时间都在喊品牌！品牌！品牌！至于在普通用户层面，阅读体验上至少需要3步才能看到图文内容这个繁琐操作，反倒直接被无视了。

中间的小改版一概忽略，直接跳到“看一看”的出现。看一看这玩意，严格来说跟订阅号并无半点关系，连开发团队都不是一回事，但是，这玩意打到的确实是订阅号的软肋和G点，只是出现的位置比较尴尬。背后反应的是自然排序和算法干预排序观念的对撞，效果好不好先放下不提。

然后就是突然出现的折叠型卡片页展示形式。这个方式解决了以往只能看到一列主标题，让标题党大行其道的弊端，丰富了展示形式，但损害了之前大V喜爱的品牌概念，自然也是被捧被贬都有。

然后，突然在上一次改动的好坏评论还未消停的时候，突然又有了内测的“乱序”方式出现，引入干预算法的概念。这即在意料中也在意料外。

但是，提醒大家要注意一个细节：从内测开始业内就普遍称之为乱序，而不是算法排序，这个点值得深思。好玩，好玩~

好了，简单回顾一下发展，下面该说点正经内容了。

• 从数据上来看，乱序体验更好

不止一次高草从开发团队里听到这样的说法：乱序的调整，数据上很好。那就先分析一下这个说法是不是能站得住脚。

从数据上来说，几年前大家就在嚷公众号数据下滑太快，这确实是事实。到底有多快？我不好公布具体数字，不过不妨从公众号作者的视角去说一点。作者在后台可以看到几个传播途径，有阅读次数、人数这些，在没有看一看途径前，订阅号列表普遍至少要占4成以上！这也是之前大V爱喊品牌因素的原因所在。其实没什么神秘的，公众号真正的传播路径，只有订阅号列表，朋友圈、和群聊3个主要的途径。自从朋友圈开始严格控制泛滥的转发文章以后，订阅号列表入口当仁不让地继续承担不容作者层面忽视的重任。但是并不妨碍有高影响力+经济实力和渠道实力的作者，去触碰到病毒式群聊传播、网站传播、微博传播等途径，打造出豹纹(哦不，应该是爆文)。

但是，当渠道费用和各种传播途径陆续收紧加wxb封号风波之后，尤其是针对标题党、震惊体、编造体、谣言体的打击风潮之后，读者也早都对标题党深恶痛绝。传播成本越来越高，订阅号反而是个避风港，数据上稳定的出奇，不能不说是个奇迹。

所以，慢慢的大家关注的焦点又开始在看一看和订阅号列表之间徘徊。平台也早就意识到了这些，至于为什么一直没有动手，则跟一批早期一直就负责公众号产品设计的人有关系。早期这批产品同学，平时的思考范围比较广，爱综合考虑各方的意见，行事上也容易走过度照顾的设计思路：总想去同时满足各方角色的需求，当然满足老板的要求肯定是第一位。

虽然私下聊天里，大家都对订阅号展示形式的弊端有清醒的认识，但客观走下来，一直无法真正做出改变。慢慢的，这批人基本离职差不多，新人也替换好了，出现些改动也是顺理成章。这才有机会抛弃了一部分以往的包袱，才有了卡片页+timeline的妥协方式出现。既然是妥协，也就无法满足更激进的业内声音和对齐头条算法的那部分需求。

那就得继续改，那总得有个由头吧，首先必须有测试对比数据支持，这也就是高草近期经常听到的数据挺好的由来。其实，如果继续分析下去，这个数据支持其实是不成立的。前面说过，公众号的数据是一直下滑，而且产品生命周期自然发展也不支持一直稳定还增长这个期望。大家都知道的长期的局部底一旦遇到触底反弹迹象，有一个基本常识，只要出现任何一点动力，都是大概率产生向上反弹的。看一看出现的就是一个例子，虽然效果马马虎虎，但是传播力上的数据影响面是不争的事实。这就形成了正反馈，好玩的地方就在这里。但是不清醒的人，很容易以为，这是设计功力或者算法牛逼的地方所在。很容易滋生自大情绪。

所以，这一段的观点，总结下来就是：数据上会支持任何改动，毕竟已经没有比一行纯粹的标题更xx的展示方案了。

• 信息过载，早就看不过来了

这个说法也很常见。如果要讨论信息过载问题，高草估计要比99%的人都有发言权。最早的时候，高草不满足看后台的文章传播数据列表，总感觉是隔了一层毛玻璃，抓不到痛点。于是求开发同学自动把满足一些条件的文章和公众号自动关注到高草的个人微信上。于是，很好玩的事情出现了，高草经常整天都拿着手机去刷订阅号列表，这个列表很快就增长到几万个关注以上，于是于是高草的微信就挂了。对！是微信挂了，哈哈哈，根本无法正常使用。

后来，又去求开发同学，弄了个自动清理的东西，没事就直接清空列表重新来过，微信总算又能用了。在这段时间里，高草明显是以一个极端用户角度去使用订阅号列表。信息过载对我来说大概在10w左右会达到，推测正常人可以忍受的上限是1w左右，原因很简单：信息如果再多，手机首先是受不了的~

总结了常年反复试验的结果，最终个人认为：一个普通人的关注列表在1000左右是一个合适的范围。高草的容忍上线，不负责的吹个牛逼，肯定是强过绝大多数普通用户的。

所以，改了订阅号列表，弄个算法进去，弄成乱序就能解决信息过载这个说法，高草有一万个理由不认同。因为这里真正的问题在于，平台侧始终不敢提供一个便捷的取消关注操作！更不用说是批量取消关注！

这玩意一旦出现，第一个严重抗议的肯定是运营公众号的大V和运营公司啊，你动了人家的KPI，这还了得! 嘿嘿嘿了吧~

• 到底是谁更在乎这个列表？

答案很显然，肯定是作者和公众号运营公司的层面。这个不用展开解释。而且在影响力上面，大V发个朋友圈、发个微博，产品都要加班的。普通用户说上几百遍，只需一句: 小众需求，妥妥搞定。

至于已经养成了睡觉前刷刷订阅号列表的人，你改成啥都不会影响那一顿消除红点的操作序列。对，不会影响的，强迫症患者在此！咦？红点呢？乱序后的红点怎么不见了？

• 传播力排序和订阅号列表本质上的冲突

这个乱序排列，本质上说是一个传播力度的预测模型，最多增加一些个人因素，美其名曰个性化推荐。但是，个性化推荐这里其实并没有显著的进步，算法还是几十年不变的教科书级的那些东西，一个毕业生抄抄都能做出来。（这个话题往期推送说过，感兴趣的可以翻早期文章）

对于抖音、微视、快手等一次性视频场景来说，排序上让无效内容快速消失和下沉设计是必须而且必要的。但对于阅读场景，一个自打一问世就类似于黑板报、纸质报刊的公众号平台来说，一个猎奇大字报平台，用算法统领入口，这里有点抄过头了。很好奇，当年那个对算法持十分谨慎态度的微信怎么突然就不见了。毕竟，失去了制约的野蛮生长总是有点危险性的。

把一个大家已经视为订阅过的公众号的列表途径突然改成按传播算法排序，谁能在前面谁被下沉是个未知问题。这个黑盒100%是压在作者心头的一座大山。不透明是表面问题所在，更深的问题是以往通过选择发送时间来解决送达的做法突然无效了，这谁不慌啊。这谁能不慌啊~

把一个可阅读文章列表、好文章列表、传播度好的列表，甚至朋友圈阅读文章子集的东西混在一个地方，还叫订阅号入口，拿来一起来设计，从哪个角度来说都不是很好和很清醒的做法。

也许微信的入口太多太分散是一个难题，不过解决的方式还值得深究和讨论，是不是有更好的解决办法？但是，一刀切试图在订阅号入口做这种整合，肯定不是一个最好的办法，甚至算不上好办法。高草个人认为，把看一看移出来，做个订一订或者阅已阅或者叫朋友圈2，上升一个级别都好过改这里。也许，产品只是想把一个终端用户层面没啥影响力的入口激活，不小心让作者吃惊了。

也许，只是我想多了，这里根本就没那么重要，本来就是可有可无的。

• 仍然没有解决互动上的短板

公众号依旧还就是个大字报，这个观感还是比较贴切的。因为，传播、转发和公众号本身就是割裂的，各自的表达途径也是分离的，没有一个能统一看到的地方。说白了，作者依然处于爱写就写，读者依然是爱看就看，双方互不干扰，互相佛系。

文章的评论上有一些互动渠道，但是这个渠道被神秘部门果断拍死之后，也就不了了之了。进入公众号之后才可以发几条消息，但是这个渠道依旧是半死不活，读者发消息发多了，作者看不过来的问题依然没有解决，而且里面的垃圾信息依然比例很高。长期的双方难互动没有啥改观。

缺乏互动虽然不影响公众号作者变现，但是对于一个至少6年都没啥改变的平台来说，这里仍然是一个潜在的爆发点。可是直至今天，依然没有官方渠道释放入口出现，来解决订阅者粉丝之间的交流途径、丰富作者/读者之间的高效互动需求，做出有活力的粉丝经营渠道，不能不说还是个遗憾。算法其实在这里才有更大的发挥空间。

=====================================

前面反复说过，对订阅号列表的任何改动，只要有改动，我都会举双手双脚赞同。但同时又十分抵制过度自信、过度设计和迷信算法的做法。有自信是好事，现在产品如果把前任产品同学喜欢过度考虑的做法直接全盘否定就更不对了，在一个亿级用户的产品层面来说，需要保持谦卑的态度，只是不需要过度谦卑而已。过犹不及，这四个字任何时候都是对的。

高草选择这个时候写此文，还源于一个养成已久的习惯，不在产品设计定型前介入，不公开讨论不发朋友圈。这次的乱序改动，已经发布官宣了，那就不在此列了哈。以前，在做安全工作的时候，高草的习惯就是拒绝在产品拿出成型设计稿之前就进行讨论，保持了n年，事实证明是积极有效的。原因很简单，未成形之前就参与，那是过早参与，提前把另一个思路的挑战摆出来，甚至是逆向思维出来的东西讲给产品，只会限制产品的设计工作，负面效应远大于正面效用，锦上添花还是添乱只在于一瞬间的选择。

闲话不说了，继续总结，本次订阅号列表改动，对平时就不怎么刷订阅号入口的人来说是一个新习惯的养成渠道，没做到位的地方在于仍然不敢去解决取消关注这个核心点，下沉并没有彻底解决过载问题（比如一大堆已经被永久封号的还占着茅坑）。如果是真的有很强的设计自信心，应该同步提供类似timeline的形式，卡片页依然是丰富选择的有效形式。还需要认真考虑对品牌感已经养成习惯的那批人的需求。另外，对互动上的改进依然缺席，还是短板。

最后，排序干预应该还是一个热门变现点，有能力的小伙伴可以考虑，技术门槛肯定不高，变现能力必定是杠杠的。

阅读原文

跳转微信打开

纯羊毛丁字裤，年底特价，大甩卖~

全文8848字，适合以下群体瞄一眼：还没入行/入行不久的从业者、忙着996前后台程序员、初高中/技校/高校生（刚学了一堆经典算法的）、无聊的产品、手里还有闲钱的土豪、IT公司老板、比较闲的码农......

不适合以下人群观摩：正在做推荐产品的大佬、PR精英、流量分发渠道的从业者、忙着编新鸡汤/养生/谣言/段子的内容创作者、福建卖茶叶的、莆田开医院的......

正文各段内容基本上没有前后承接关系，跳着看没毛病~

这个话题很早就想写，因为最近一直在降温，懒癌频繁发作。不过这几天突然意识到，如果再不写，很可能就跟另一个话题一样不知不觉就没人感兴趣了。对，这个另一个话题，就是团购的那些破事，哈哈哈~

是的！你又猜对了，今天就是要说说打着精妙算法旗号从事疯狂卖流量分发买卖的那点儿破事，扒一扒他们的纯羊毛比基尼丁字裤。

郑重声明：以下观点与某条、某呼、某瓣、某狗、某狐、某猪、某壳、某FM、某树、某米、某看等等等等等等均无任何关系，各位请不要随便对号入座！拒绝碰瓷~

• 开场曲

[新闻联播语气]各位观众，各位观众，也许您刚刚打开app，在这个2019年就快要玩完的伟大时刻，冷不防一回头，尼玛蓦然发现如今的内容推荐大佬都开始不提推荐个性算法这几个字了，这究竟是怎么一回事啊？啊~啊~[5毛回音效果]

[男主持]在这辞旧迎新的伟大光辉时刻，在我国即将全面奔向小康的deadline的前夕，还有大量坚守在工作岗位的同志，他们仍然在悄悄地爬着互联网的网页，他们仍然在偷偷地卖着隐私数据，他们中有些人不声不响地就做起了游戏实业......当然也不要忘记那些脸上充满正义，996地忙着割下岗再就业人员韭菜的精英教育群体...

[女主持]但依然还有一大批农民工程序员兄弟姐妹，一脸喜庆地拿着各种刚被收录的论文和刚刚到手的专利申请号开心地吃着火锅唱着歌，开心地吹旺了自己屁股底下熊熊燃烧着的木炭...

[群演齐声]他们无非是为了能在年终总结上留个好看点的KPI啊~他们无非是为了能在投资人看的报表里面涂上浓妆的一笔啊~无论怎样，只要有点东西可以看，那也是极好~~那也是是极好极好地~~啊~~~

[提速50%念白]以下是本期走进玄学的主要内容...

[大夫]“别闹了好不？乖~把药吃了~”

==================以下是正文=================

• 继续吹？还是不吹？这是个问题！

在2019年有个明显的变化，平日里主打精妙算法的那几家，突然就都集体性不吹NB了。这就让新入局的帮派团伙和一部分已经/即将缺钱的小分队头目的头很大。经济大环境如是，川总经理还在砸盘，50年一遇的世界经济寒冬，地主家余量也不多。但是不吹怎么有米开锅呢~

先粗略地回顾一下内容个性推荐类产品的发展历程，把时间稍微回拨一点点，都不用太远，差不多2x20年就够了。也就是重点看看1980->2000->2019之间有啥变化。

只要是平时稍微接触过一点研究性质、看过点行业总结的，或有一点统计学背景的都不难发现：好像、其实、原来推荐这活儿并没有出现过划时代的大改进。改变的只是运算能力和数据处理规模，也叫算力。以前需要打报告排队才能用的贼贵贼贵的超大型机才能处理的事情，现在只需要买一些内存条、买一堆台湾省出品的高档显卡就可以了。除此之外，还真没什么更值得注意的地方了。

也许有人会说，算力提高了，这就是革命性变化嘛！但主席也曾经反复说过：算力是进步了一些，可算法本身并没有进步啊！可是，这仍然不妨碍圈子里一浪接一浪地追、捧、吹的热情。

比如，大家去理发店，基本上遇到的每个tony总监都会在用仔细热风吹一番、打点发蜡之后才跟你收钱，很自然的还会推荐一些新的消费项目，同时也会不小心地披露点隔壁店新进的洗发水是某小厂勾兑的闲话。

同理，做内容个性推荐产品的大小公司，那也是得先热风精吹才好意思收钱。而且还是吹的越好的，越能赢者通吃。也只有第一批使用了新算力新技术架构的，才会腰包鼓鼓，才敢内裤外穿，并持续受到各方追捧。第二批、第三批以及还在后面刚爬过起跑线的，可能都无法察觉这风里已经混有淡淡的屎尿屁的气息。

至于那些隔一阵子出来吹一会的，那只是钱又快要花完了，出来重新化个缘而已，自身的业务收入还不足以养活全家。

于是，一直都有人狂提算法，说我有一条祖传的神秘算法想与你分享，丝毫不提流量分发运作上的那些潜规则，这也就导致了吹NB的同质化！没办法了，那只能上新名词了，比如偶尔喊一嗓子：走过路过不要错过，我们这回也搞一个耗资xx亿的扶持xxx的伟大计划了！反正说多少个亿都行，无非是左手倒右手。如果遇到有人质疑分配内幕，那就直接来个论文里常见的计算空间变换大法，来个矛盾大转移！比如直接喷BATSM，打开字母表，26个字母随便选1个，那都够喷上一阵子了。时间一长，自然大家就不记得你到底付了多少钱~

君不见，凡事只要加上个性俩字代推荐这俩词，立马都好听并且高大上，比如个性化绕路地拼车，个性化随意地点餐，个性私生饭付费地音乐打榜......

至于吹这个动作到底在向谁吹这事，说起来有点好笑。这个对象，其实从来都不是使用个性化产品的用户，也从来都不可能是用户，资本层面才是！推荐的东西用户认不认可并不重要，有没有营养并不重要，只要能换到银子或者在换到银子之前能得到资本层面的认可，那就行了，核心对象就在这儿！

至于前面说推荐点啥都不重要，为啥呢？你看啊，对某个话题，看的人和说的人多了，大家自然觉得这应该是个有共识的热点，期待反转，你只要能比别人早看几分钟到并转发以下，基本上这就是非常有个性的事了！如果还能产生持续传播，又可以反过来产生一个莫名其妙的自豪感。可是，是不是有点觉得觉得哪里不太对？这好像是一个很典型的流量分发过程，并不是海报上雅黑体大写的个性推荐这四个字啊？嘿嘿嘿~

长江后浪吹前浪，前浪刚死在推荐上~

• 莫回首！个性推荐咋都做的像搜索、搜索做的像推荐...

先请仔细想想，是不是？

严格来讲，搜索和推荐，在技术使用的层面上，其实并没有太大的区别。此观点不接受任何反驳~

你看，现在搜索公司做推荐、推荐公司做搜索都是非常常见的。区别只是每次他们都只强调一个而已。前者有很多成熟的例子，比如深度参与了治疗魏xx同学的某度...后者就更多了，懒得都提，比如差点把人家服务器爬到流量欠费的某条...

你瞧，单单考察下大家用这2货的方式和姿势，都是给个激活动作（输入几个字或者屏幕上随便划一下），就拿到一串东西可以看，对不？没啥区别嘛！

再瞧，推荐算法里面的评估流程是在调整些什么？搜索算法里面的过滤步骤又是在摆弄些什么？搞不懂没关系，只要知道知道结论就行：没啥区别！

再比如，大家都在用的音乐、图片、视频网站和app，那都是怎么搜或者荐的？那些东西的主要流程可都是基于文字做的！感觉不对？别急，往下看。其实，只要是在音乐、图片、视频周围出现过的，无论是看得到还是看不到的文字，只要是文字就都贼好用，如果还有评论去文字则更妙。S*B*会才费力去提取什么声音、视频、图片里面的特征要素，服务器全功率跑的电费不用给钱啊？交这些电费还不如挖点矿换几个xx币划算呢！对外宣传那只是宣传，说的要跟作的严格区分开，对不对？谁还能去你家机房检查？而且，坚持多用文字因素来计算，最好影响占比要超过50%才好！这么做非常方便随时插入手工调整嘛！至于为啥要调整？嘿嘿嘿~不调整，怎么卖TOP列表，怎么卖榜单啊！

是不是商业模式也一模一样？

更重要的来了：在资本方眼中，搜索是一个独立概念，推荐是一个独立概念，是要分开来计算(收入)。也没啥特殊原因，无非是这两个概念目前分开来读更值钱，更有话题带入感，嗯，就是要带感。有话题才能有韭菜，有韭菜种子了才能有下一波韭菜，韭菜多了才能割嘛。对吧！资本大佬从来都是这么讲道理~

不妨再看个例子。在某宝某东上面搜败家宝贝儿的时候，你在做的事情是叫搜索还是推荐？等等！你为什么举这个例子?还不是因为大家都知道，想上某宝的搜索商品列表，那必须先买一个叫搜索服务的东西才行。而这个过程刚好也可以叫个性化推荐（至于是谁的个性，这不重要，就当是埋了个伏笔，没明白的同学不要急）。反正排前面的商品可能跟你输入的关键字完全无关，你看，这根本不是搜索哈。你再看看朝天盛世里几大搜索引擎吐出来的首页，排前面的那也都跟你输入的没算关系嘛~

而且，瞧瞧都是什么人在这俩行业里打工。翻来覆去还不是那几个？马不停蹄地从一家公司跑到另一家公司，大家一碰面，哎呀妈呀~咋有点眼熟！嘿嘿嘿，同一个地球，同一个宇宙！

大家也都知道，把一个已经透支的商业模式换一个称呼继续，通常也并不能持续多久。所以，大佬们才会匆忙地把流量兑换成现金，又匆忙地把刚拿到手的真金白银换成别的玩意，比如看起来更能保值的其他公司和理财产品。

嗯，类似的还有个例子叫新能源汽车，明明都是电瓶车，非得加个新能源三字才高大才有补贴赚嘛。至于大家买不买账，请看下面配图文字：

非常不突兀地插个小故事。以前高草在每年面试毕业生时（本科、研究生、博士混面），都会看看他/她简历里面提到什么算法，随便挑2个来问：这个算法的优势在哪里？或者这玩意在什么领域是不能用的？各有什么优劣？基本上在这个问题上答不好的，我都当场直接放弃。因为，即使给他们过了这一轮，后面一般也签不下：做内容推荐产品的公司普遍买价更高，唉，这样的人材都不便宜哈！

• 在互相蚕食中能相拥取暖

本草固执地认为，伟大的产品必须是开创了某个领域，或者扩展了某个原本都不存在的市场，或者是第一个在新地盘抄成功的东西。但凡是在还在现有场景下还拼刺刀，拼谁的血多抗得住的都不能称为伟大的行业。

你看桥不湿同学，当年一不小心就把挪鸡鸭的砖头变成了一块带大屏幕还易碎的板砖，虽然除了打电话不好用以外...嗯，还挺好看的，但这才叫革命性的进步。后来挪鸡鸭也做了智能机，在打电话功能上继续秒杀了桥不湿同学( 的板砖)，但这个只能叫改进。继续列几个能叫伟大的例子：Yahoo、Google、Amazon、ebay、阿里、blog、微信带火的二维码还有自带BGM的摇一摇、电驴、联发科的手机集成方案、朝天盛世特有的短信SP商业模式...以上都是具有划时代意义的东西。

不难发现，现在市面上真正在赚钱的内容推荐产品其实并多，即使是还在赚钱的大佬也纷纷在默默数钱时嘀咕着：鬼知道还能数几天？因为一不留神，可能因为一个政策问题没把握到位而关停，还可能因为高层次不可抗拒的收编行为而改姓，也可能是资本方抱团娶了一个更乖的团队而裁员......

个性推荐的日子不好过并不是第一天才有的。过去几十年年年都是如此。只不过从各领风骚两三年逐步在变化到各领风骚几个月，未来搞不好会只有几周。参考一下游戏行业目前的局面。他们从只看年均指标，到月均指标，到周活，到开始拼日活甚至白(天)活/夜活才用了多少时间？

所以，随便找个理由，A捅B一刀，抢走一批订单和用户，B再敲回A一棍子，顺便拉回点收入，A挖个大坑埋了B嫂子的一双大脚，B又打开冰箱扔了一坨硬邦邦的屎砸了A馒头大包，A挖了B几个工程师，B又挖C几个工程师...

早年重点吹算法多精准多NB的，多能节省人力的，眨眼之间，就都纷纷开始悄悄地拼非算法类的人力消耗了。A招100个，B就招101个。反正工资越给越低，用的人也从名校博士研究生一直下降到外包公司定期补给。原因其实也很简单，所有的算法一旦真的跑起来，想继续用下去，最后都逃不脱人工调整的这个环节。过去没有一家例外，未来也不会有例外。但是没有人去公开这个机器算法/人工的配比比例，一套系统到底该配多少外包最合适？就是不说，想知道？去看财报嘛！都在默默地换人，至于最后究竟是算法在主导还是人工在主导，这也许永远都是个迷。套一句流行语：我觉得吧，这事儿特别摇滚！

也许，到最后：

• 您的个性推荐其实与您的个性无关

前面说过算法上没有出现革命性改进。据高草的长期跟踪，基本上想都不想就直接反驳的，差不多都是刚刚看了本中文版畅销教材，好点的是翻了本翻译教材或几页外文论文的（也许他刚刚才跟老板打了个报告，认为此处可以投入一点点重金尝试一下）。但凡从业超过10年的，第一反应基本上都是先沉默...

“个性推荐”这个广告词的作用，依然还是体现在广告词这三个字上面。好在现在有了个广告法，不允许过分夸大和过分美化，否则还真难想象说了几十年的个性推荐会给改成什么高大上的玩意~

划重点：目前您看到的几乎所有的内容个性化推荐，依然还是个伪命题。

首先，这是由算法的局限性带来的。无论是公开还是私底下，高草都不止一次强调过：推荐算法并没有本质性的改进过，改变的只是算力而已。而最理想化的，应该是每个用户都有一个独立推荐“大脑”。

也不难发现，目前所谓的个性推荐依然还是在努力地做好两件事：

1. 随便给你分打个标签/做个分类，解决可以丢到哪一小撮用户群里面合适的问题；

2. 随便丢点东西给这个一小撮用户群，随便看看就行；

3. 如果上面过程不理想，那就随便再来一次；

这里有2个字比较刺眼："随便"。懂一点算法的，无论什么算法都行、AI、DB、DM、C++、哪怕是正在7天连锁学Py和JS的都行，可能都首会先对随便2个字表示抗议。但，别急~

如果你是能接触到推荐类产品的真实业务数据，或者在这个圈子里混的够深、而且够持久，也看过原始、未经过美化处理的对比数据，我相信你会同意这个说法的。

无数的实验都表明，目前我们所广泛接触到的各种推荐算法，在用户基数足够大的时候，其实和直接按照自然访问次数列表分配，在总体表现上并不会有太大差别。也就是总体上去看，去看那个所谓的全局"准确率"，精妙的算法和随便点一下并没有显著化的差别。

这个事实可能有点不太好理解。对一个普通人来说，给你几个百分点，感觉上可能并不会很明显。就比如今天早上喝了碗豆浆，比昨天多了5%，原因是老板手一抖今天碗里多了5%。这对于一家街边大排档来说，多5%（利润上）并不会有多大影响，甚至多送1杯（100%）都不是什么大事。但是，对于拥有海量用户的互联网产品来说，每个1%的改变，都是会直接影响到对应的AD条目的打开率和变现率的。请注意，这里提到的一个G点：AD条目而不是推荐的内容，虽然有时候内容本身也是广告！再通俗点：这1%的改变很可能恰恰就会影响超过50%的广告收入（就好像卖豆浆的老板实际上是搞传销的），也就是表面上区区1%的提升，其实背后代表的很可能是kw起步的真金白银。它隐含的是由此带来的人民币或美元收入的杠杆化操作，是一个几倍甚至几十倍的操作，好像有点拗口，不理解的不妨反复看几边。

这样，逻辑清晰点了没有？您个人的1%，经过海量用户的整体叠加加成后可能就是50%+了！而且是被偷偷换了个概念。所以，每个1%都会很重要！所以，为什么拼命吹精妙算法的就会有内容生产厂家的流量加持，就会有市场的追捧，这样不难理解了吧。

重复下：剥去皇帝的新衣，您看到的个性推荐与您的个性无关。通过改变内容来改变分发的流量，从而改变收入的提升比例，这才是影响内容推荐质量和准确率的根本所在。而且很不幸，几乎所有公司都在这么干。所以，以后再看到个性推荐，可以隐含的加上一个限定：个性化广告推荐、个性数据大买卖~

为了显得不那么生硬，稍微多说一点技术上的东西。大家一般称基于看过的东西去做look-like的事情，就是所谓的个性化推荐。可见，底层基于的是一个叫look-like的破逻辑，对！就是看起来像！于是，个性推荐其实只是给你一大堆只要看起来跟你看过的东西有点像的东西就对了。前者一般是用来做训练的，是旧的是死的数据，而且也不用过多考虑到底是仔细品鉴过的经典，还是手误点了一下，还是才看一半就能开杠半小时的，反正看了就是看了。您看过的这个动作，这是个黑历史，而黑历史是改不了的！

于是有人就会说，这么推荐肯定不准！别急～那不是还有个赞和不赞的选择按钮吗？您连点都不点一下，精妙的算法肯定不知道您其实原本是不喜欢的！这时候就必须要强调算法不是万能了！神马？你前面不是一直说算法很牛逼嘛？算法比我更了解我自己嘛？说说而已，你还真当真了！

至于您真的去较真了一下，没事找事真去点了，甚至点了好几次不喜欢。结果伤心地发现，你看到的内容好像根本没啥变化，这又是为毛啊？嘿嘿嘿~如果说点一次和点了几次，其实根本都没啥区别，你信吗？为啥？麻烦往前翻翻：对于平台产品来说，你这个不喜欢如果会影响到收到银子的重量，那这个不喜欢的操作就必须被弱化掉甚至直接忽略掉。哈哈哈~嘿嘿嘿~吐血了没？

至于谜一样的旋转跳跃(我)闭着眼~重复又重复出现的广告，这玩意上面的不喜欢按钮，一般只是个装饰品，加上去只是为了好看一点，有个UI设计湿说，俺们有个原则叫视觉平衡感~

其实，市面上也并不缺乏真正做个性推荐的东西，但是基本上都活的并不是很好就是了。再次强调：个性推荐产品也并不是只有段子、新闻、谣言、弱智GIF、搞笑视频这些。还有很多普通人不会留意的东西，却是切切实实在用个性推荐的技术。比如，保险和信用卡公司背后的审批逻辑和系统，比如您手机上收到的垃圾短信、那些不请自来的各种AI和纯人工骚扰电话......

• "伪"个性推荐的根儿在哪儿？
  

先讲个小故事。很多年前，在高草还在每天忙于跟垃圾邮件死磕的时候，有个产品同学突然杀到面前，问还能不能提高拦截的准确率？我的回答是：那必须可以，在哥们儿这里就没有做不到的事。但是代价你不见得能负担得起。

原因很简单，拦截垃圾骚扰这事是个非常个性化的东西，也许一个推销茶叶的小广告、一个办证的小广告，有人就会觉得挺好，他碰巧就需要这个你还能有啥想法？但另一个人则可能看了就骂：又是卖茶叶，卖茶叶死全家！所以，仅靠通用型的全局化的引擎，必然无法照顾到个性化的多样需求。那怎么才能满足产品的伟大需求呢？不妨推演下，那就是需要每人一个引擎！这个代价严格上来说并不是很高，堆点服务器就可以。但是，对于一个n年都不赚钱的纯消耗部门来讲，想一下子就要上架几十台甚至上百台很贵的服务器，审批都能批死你。

解释完了，高草一脸坏笑地问：如果你能帮我申请来这批服务器的话......嘿嘿嘿~后面的自然就不用多说。

故事讲完，总结下：这里貌似只是一个被实现代价拦住的小小问题，但其实并没有根本性解决好个性化需求。还是用茶叶广告举例：推荐引擎无法知道他明天变成讨厌茶叶的可能性有多高！不知道明天他会不会突然就不想买茶叶了，说不定想的是中午要不要吃个茶叶蛋或者水蒸蛋。所以，当时很明确地说能，其实根本上是做不到的，根本就是个伪命题。

继续解释，单纯从算法上来看，目前的算法仍然还是一个计算通用型计算可能性概率有多高的东西，本质还是一个如何逼近，还是个拆分成一系列是和否的老套路老机制。几十年来改进的地方也并不大，早期是2个分类：是与非。早期很可能10个人觉得对等于1个对 ，1个人觉得不对等于1个否，后来改成了0-1之间的概率计算问题（也可以是-1到+1），再后来又改成了能支持几个分类之间的0-1概率问题，仅仅是能支持的分类数量越来越多，仅此而已。

也许有人会问，为啥一定要有分类？就不能模糊一点？答案是可以模糊，但是再怎么模糊，回到计算能力上，都会被分类总数和数据总量给局限住。还有，业内所谓的各种标签也都是分类的一种。再翻译下，就是受限于芯片性能这个确定性因素，所有的推荐结果都只能在自已知结果（分类）里面，去寻找一个看起来比较像的区域，在里面"随便"给一个或一串结果作为答案而已。是不是又有点懵？别急，还有~

对一个充满了不确定性的问题：今天该吃点啥？或者怎么才能恶搞我对面的家伙？返回的永远会是几组大家都吃过或者玩过的小把戏，就是一组确定性的玩法：玩过的人很多的玩法列表。而且用户基数越大，通过一系列确定性估算的叠加，最终所算出来的分类集合只能越来越接近用户之间的共性！也就是最多人爱吃啥，大家最爱玩的恶搞手段是啥！而这个过程，以前叫推荐，现在却被叫做个性化推荐~

所以，所有能被广泛接受的个性化内容推荐产品所产生的内容列表，必然会是标题党、突然新闻、惊悚谣言、段子、搞笑视频、养生鸡汤这些，不会有别的！这里，不妨向从业者问一个问题：上面提到的普遍性困局，只靠过滤和不停地添加反面标签就能解决掉嘛？能嘛？不能嘛？...

必须强调下，这里说的伪命题，并不是否定个性化推荐本身。高草否定的只是这些打着个性化推荐旗号，做着传播利益最大化事业的，忙着数钞票的从业者(们)。其实，真正的核心从业人员，他们心里是很清楚这个现状的。

还有一种常见的反驳说法，说推荐的不够准，那一定是数据不够多的锅！所以，得拼命往里面加隐私(啊不~加数据)啊，神马2、3、4、5、6、7、8、9度关系都得加才行。比如你领导的邻居的姥爷早上转发过啥养生鸡汤，隔壁妹子给哪家餐馆的卖奶茶的帅哥点过赞，刚刚擦肩而过的大娘手里拿着几头大蒜，都加！都得加...

很可惜，即使这样做，最后算出来的仍然只能是把一滩屎比较充分切均匀地搅拌在了一大坨泥里面(优化1万次也是一滩稀泥)，然后在稀泥里面随机挖一勺。

如果再继续深究，在目前所有能看到的算法上，无论是线性的、曲线的、曲面的、变换到其他计算空间的、还是到现在都没人能解释出具体含义的n层平面网络之间那个神秘关联性到底是啥玩意的...在本质上看都是在寻找一个概率值最大的点、分支或者区域。无论大名叫因果说法、逻辑推理或者其他神马玩意，无论表现上是个树状、网状、环状或是3维、n维结构的，几轮narrow down下来，也许真正个性化的东西刚刚就被你给忽略掉了。统计学上，这个可能性也许只有0.001，可是当基数足够大的时候，这个0.001对某个个性领域的影响很可能就是99%。很可惜，受限于数据规模和运算规模，前面的0.001在迭代过程里是必须被丢弃的！而且，这也并不是运算精度的锅，并不是算力的锅，是现在的各类逼近算法自身的锅，算法仍然不够精妙！有些推荐结果看上去结果不错的还是个黑盒结构（不知道为什么能用）。

再看，针对一个正等着被推荐的特定个体来讲，它下一步的真实可能性也许同时存在于几个点、几个区域里面（不是量子概念哈，表弄混），甚至包含在未知领域里（算法未接触过的数据），甚至就在概率计算出的相反（距离值很大）区域里。仅仅靠目前的这些改进了计算性能的算法，怎么可能计算的出来？这也叫多样性，是大家头疼了几十年都没被解决掉的东西，是目前个性推荐仍然无法彻底绕过去的要命的地方。

在解决这个要命环节的办法里面，目前能看到的，都是继续在一大堆确定集合里面继续试图多给几个概率值也很大的区域。我国朴素的古人也早就说过了，这揍丝刻舟求剑嘛~相信到这里已经有不少人迷糊了。没关系，这段不重要，不重要~只要记住大家目前的算法还不行，就可以了，哈哈哈~

珍惜生命，珍惜脑细胞，别瞎琢磨了，就此打住哈~毕竟还有几天，咱们伟大祖国的全面小康就要实现了灭了哈~

展望一下即将到来2020年：既然大家的目标都是奔着流量去卖的，都是奔变现去的，那就大方一点，该卖关键字就大大方方的卖，该拼TOP列表的就大大方方的拼，不必扭扭捏捏指鹿为马，既想做那啥又想盖那啥，别等到花大心思盖好了牌坊，结果游客都走光了。

• 全文完

阅读原文

跳转微信打开

从PGone的破事和某音pr口中的审核后台说开去......

标题打了马赛克，大家应该都能得懂要说的是抖了啥东西的那个平台，无他，不想因为2个字惹来没意思的投诉~

而且，本文的核心可不是为了说这个平台。

请看这波瓜图：

PGone声称视频只是存在了某音的草稿箱，但是被人传出去了，随后某音立即辟谣。先不深究到底是不是内部员工传出去的，咱么先说说到底有没有后台上传这事儿。

请看网上流传的一张隐私政策图片：

从app操作便利性角度，这个做法基本上是业内通用的做法，其实并不存在偷偷上传的问题，您老人家使用前不是已经都点了同意嘛？神马？没仔细看过？这玩意是设计用给你仔细看的嘛？嘿嘿嘿~~

但这波瓜的表面核心问题被归结于草稿视频会不会到审核后台，会不会从审核后台就能轻松下载。

先别急，想弄清楚是不是审核下载的问题，得先讲点审核相关的东西，这个绕不开。

提到审核，又得先讲讲天朝的审核行业现状。自从神奇的天朝互联网法规颁发以后，家家户户都开始从野蛮生长到极度重视审核了，但并不是所有厂商都有这个经验和实力。老牌的基本都在上面吃过亏，无论从人员构成还是平台建设还是成本控制方面都有大把的经验教训和成熟的吃亏经验，所谓久病成医即是了。

早些年厂商基本都是自建审核团队的，招了一批懂开发会产品还高学历高工资的同学去干这个，由于人数往往不多，走下去自然出大问题的机率不大，但是同样都出现过一些数据泄露的问题。而且，这个模式有个致命缺陷，上面的3高员工长期干这些琐碎的活儿，绩效上不去，积极性上不去，时间长了心理还容易出问题，而且活儿干不完干不完干不完啊...

高草以前就经常找做业务的新老大，这里那里的权限要限制一下，先说明我不是不信任你的开发同学啊，只是不想因为我们少做了一点事，让能接触这些数据的同学禁不住诱惑，做出点啥出格的事情，那可就是创造了一个引诱别人犯错的环境，咱不能没事就去考验人性哈...基本上，10个里面有9个半都会明白并支持。

自然，权限控制也并不是只针对开发同学，审核系统的权限也必须要有隔离限制和对账。更自然地，高草也被审核团队的老大的老大给臭骂过，你丫凭啥不给我们最原始的数据...嘿嘿嘿~

特别是对审核系统，要做到严格的数据、权限隔离，仅靠规章制度是不足以约束审核团队和公司的。先不说能不能实时发现数据泄露，单从出事后审核回溯问题的角度来看，信息脱敏和权限隔离往往是关键，是能不能准确找到泄露源头的关键。当然，靠热点头条和新闻事件也能快速发现出问题了哈。

哎呀，好像有点说跑题了，收~

在厂商纷纷开启外包模式，大量聘用流动性非常高的人员，只要培训几天就能上岗的那种模式流行开后，愣是养活了市面上的大量外包公司，kw+收入的公司并不是少数，对厂商而言，自身的人员和成本问题自然是解决了，皆大欢喜。

但是，权限问题开始变得更加突出出来。

试想下，一位天天追八卦刷微博混贴吧打游戏的四有新青年摇身一变成了审核员，工作中看到一些不堪入目(JIAO REN XING FEN BU YI)的视频图片，能忍得住不下载不给身边死党看？能忍住不截屏？能忍住不掏出手机录一段？要是遇到包含明星啥的那种劲爆类话题呢？更不要说抄点电话号码，卖了换饭吃的事情。

所以，厂商们慢慢也都摸索出来了一套做法：那就是数据隔离和严格限制权限加校验，对审核流程自身还要再做审核等一系列做法。比如：

• 身份信息类审核，隐藏掉不妨碍审核的一些信息；

• 联系人的电话号码统统加密，联系对方得统一走IP电话；
  

• 尽量采用机器判断，避免一线人员直接接触；

• 图片、视频打水印，水印信息详细到审核公司、审核员id都在上面；

• 把涉及到的图片、视频等资源类URL地址限制在内部使用，并严谨长期存储；

• 制定处罚和罚款机制，甚至走报官拉人程序；

• ...

这样基本可以避免一线人员直接接触并泄露敏感隐私类信息。但也只是把问题从一线推迟到了二线，比如一线人员的上司甚至公司的IT环境本身（比如不小心就被爬虫爬走了）。还比如审核员的审核员，好在这一级别一般都在厂商那里，问题还好。但也有例外，比如“不小心”把审核的审核也放在了外包公司那里...

顺便多说一句，天朝的审核外包公司其实是个高危行业，不要只看他们轻松每年一个接入产品就有几千万甚至过亿以上规模的盈利。被罚大把银子甚至送去洗菊花的每年都不少。搜搜新闻，里面都有哈~

但是，新晋厂商，尤其是蛋卖大了扯到步子的厂商，在这方面往往是0经验。经常会临时抓一些毫无经验的人去做事。重新摸着石头蛋过河，所以出各种问题都不稀奇。如果再加上PR同学是不清楚审核相关的细节，P错了关键点，那也很正常。比如D**Y**这一轮的PR就明显是犯了错误，玩文字游戏玩错了地方：

因为，普通用户眼中的后台就是后台，包含手机上看不到的所有东西，神马开发后台、运维后台、测试后台、审核后台、老板专用后台等都是一回事。而码农眼里的后台则仅仅指开发后台，审核员眼中的后台则仅仅是他能看文字、图片、视频的那个地方。所以PR不小心P成这样，不但没有帮助，反而会让大家一下子不糊涂了并很可能非常愤怒。

高草看到这轮PR稿的第一反应是，操笔的这位作者同学难道是来自企鹅360大混战时期鹅厂的那个PR团队？颇有当年的风范哦~

后台、审核后台和权限的事其实还有很多，技术流程和细节的东西又太繁琐，不符合娱乐精神，必须省略不说哈。

既然本文是从娱乐行业的瓜说开，那就必须用娱乐时间收尾。下面进入不负责任预测后续走向的段落，无非是：

• 反转，视频泄露另有组织和个人，与草稿箱厂无关；

• 反转，找到了临时工或外包人员，开除，皆大欢喜；

• 被实锤，开启浑水模式，不小心挖出其他厂商的草稿箱也泄露过劲爆视频；

• 发个律师信给PGone和微博大V，告其诬陷损毁企业名誉，影响上市进程；

• 反转，挖到事件背后的势力，暗示涉及到某互联网大厂；

• 反转再反转，直到大家开始关心半壁汪又发了新歌这事，不了了之；
  

• ...

阅读原文

跳转微信打开

今天开一个装13的话题~

今天开一个装13的话题~

起因是前几天，有一个老同学发了条朋友圈，提到他当年写c程序养成的扣KB的习惯一直都在。（翻译一下，就是想尽一切办法节省内存，一个字节一个字节地扣）

这位老同学是经常活在我的谈资里面活古董，资历绝对够，当年卖过光碟、徒手反编译写过小卫星的操作系统、有幸跟他还一起改过BBS、Mud源代码，他当老师的时候比苍井空还早一些。

背景渲染完毕，说正事~所谓上一代程序员，自然是跟如今90后、00后这一代来比较，并不是说更早的那一代程序员，那是源码写在纸带的那一代。

上一代程序员坚持的是高效、节约内存、节约磁盘I/O、节约屏幕输出、节约一切能节约的东西。甚至可以为了节省几个字节，重新调整struct的定义顺序...

但这种坚持在如今CPU过剩，内存都上T的时代，经常被人嗤之以鼻：有这个时间可以抄好多个py、php、js脚本了，废这个事干嘛呢？只要能按时交付一个可以跑起来的东西，老板基本是不会去追究跑的到底如何的。这在如今的天朝IT圈早就是不成文的共识了。憋上半年甚至一年，去认真打磨出来一个系统这种事，如今也只有老家伙才会干。比如，之前开源了一套物联网DB系统源码的那家伙。

本来想也说点别人的例子，鉴于同一件事，不同人理解可能截然相反，为了避免给其他人带来困扰，索性只讲几个自己做过的小事，现在看应该就是所谓的执念~

有个项目，因为需要几种常见图片对格式做解码，嫌开源的图片、视频处理库太庞大，各种用不到的特性一大堆，最要命的是各种溢出太多，不放心直接使用。索性举刀，从几套开源库里抽出来了JPEG、TIFF、BMP、GIF等几个格式的解码代码，重新做了一个小巧的解码库。为了搞定市面上见过的所有溢出和常见的图片编码错误不崩溃，拿了几百万图片做测试。自然，这套系统在我不维护那个项目以后被人改成了著名的能直接溢出拿root权限那套开源破烂。至于后来，在线发个图片就开shell的事情大规模流行后，我每天做的事，就是转一圈喜滋滋地催他们排期，更换成无漏洞的库。

后来跟几个刚毕业的小伙子说，你们要用这个那个功能，那就自己抽出来呗，没必要继承那么大一套垃圾进去，遂被白眼...

还有个项目，需要在线缓存一些常用数据，我竟然要求方案设计成cache不准使用超过100MB内存，并且准实时地在硬盘做cache数据的灾难恢复机制。如果一定要超过100MB，也不是不允许，先得给我计算一下到底为啥会超，当时开发此项目的只有一个人表示认同这个要求。

还有个项目，为了节省每次数据处理周期能少几秒，扔掉了python写的全套东西，换回C实现了核心逻辑，一比较，效率提升100倍。因为好奇py到底有多慢，还用perl又写了一遍，仍然有10倍提升，果断彻底抛弃py。后来，还要求在线系统不得使用py，遭白眼无数。

另有个项目，因为需要处理的数据规模庞大，每小时都要以T来计算，跟一个70后的强兄弟一起商量半天，最终决定把现网所有服务器每块硬盘做成无raid的方式。当时，那破服务器每台有12块-16块硬盘。按规矩做事的运维自然坚决不同意，最后没办法，只好自己动手悄悄搞定。敢这样做，是因为数据基本上处理周期只有几次，需要优先保证快速写入，处理完后即使整盘挂掉的数据损失也可以承受。而那批服务器有200多台，最多的时候超过300台，而且是别人都不愿意用的老旧机型，是旧型号机械硬盘。

又有个项目，核心代码只有几千行，自己花了1个多月憋出来的，全程基本无锁，上线后在我手上维护跑了有5年，基本没崩溃过。后来我换岗位，项目自然换人维护，中间听说被改过几次，但都无法在线上稳定跑，会出现各种意想不到的崩溃，最后结论是无法修改扩充，得彻底换掉。算起来总共跑在线上差不多有10年。其实，原因很简单，在数据处理阶段，可以引起逻辑死锁和冲突崩溃的情况都被干掉了，后来接手的人只是不愿意去了解这些而已，自然也就改不出来。再后来，我招了一个b程序员，在另一个项目上重新重写了这部分算法，在保证准确率的前提下、效率又提升了接近10倍。

还有个好玩的，因为不喜欢标准MD5特别容易就被撞库撞出来，但又无法拒绝MD5的快速，索性找到并改了一个用的人非常少的非标的MD5库。

在非常流行Java实现AI算法的时候，凑热闹，写过一套基于Java的AI处理系统，跑起来的时候发现不崩溃，但系统慢的要死，各种资源都直接红线卡死。认真研究了一下，最后结论是Java的GC垃圾回收系统有问题，经常是等到该GC的时候系统已经无法响应了，死循环。这个问题当年一直无法解决，最后直接放弃Java，遇到大数据量的情况时，严禁使用Java去处理，这个要求也是持续n年频繁被白眼，直到py流行开才没人提Java了，哈哈哈~

要说个人最坚持的东西，那肯定得讲这个：每年招人的时候，明知90-00后这一波已经基本没人听说过Perl，还是会问懂不懂Perl...

(图片来自sogou，图侵删)

阅读原文

跳转微信打开

坑界有3个境界：坑人、被坑和被坑

鉴于本号的阅读群众特别喜欢看掉坑和挖坑的事，今天就披露一个高草职业生涯中最惨的一次发布上线经历。

现实中熟悉高草的朋友都知道，想坑高草那几乎是没可能的事，不被反手挖个坑还顺手帮埋就不错了。经常有人问，你是怎么看出来这事有坑而且是大坑的？

伟大的毛主席曾经曰过：世上本无路，趟着走的人多了，就把坑填平了，自然就有路了......

话说05-06年前后，高草辞掉了在一家创业小公司的工作，带着对开发和架构工作无比痛恨的情绪，申请了白盒测试工程师的职位，结果被龙哥一脚踢进了架构设计组（这又是另外一个有趣的故事了，暂时掠过）。于是成功地混进了刚刚组建的QQMail团队。虽然报道的时候大概已经有20-40人这个规模，但是这个架构组只有2个人，而且组长还来没报道。

于是在这个架构组混了一段时间，接到了一个大任务：原来的账号服务扛不住了，需要重构账号的后台服务体系。

高草当时拿到的设计要求只有1条，每秒要保证混合读写4000次，争取能用到年底。除了开发时间上来说很紧，4000/s混合读写这个看起来有点难度，其实这个倒是真的不难。毕竟，老的架构是用直连MySQL做的，咱对MySQL的熟悉程度不能说特别NB，但是一般人想跟我拼DB上的坑，尤其是MySQL的坑，那赢得可能性并不大。毕竟咱也是9x年就拿过18摸(IBM)DB2培训证书得人，虽然从来都不好意思亮出来。

老的架构无非是分服务器、分表。原来分表分的少，鉴于时间紧迫，那就先上一个10-100倍分表再加服务器的架构顶上去，原来是直连DB（这个是大忌暂时也不表），加一个中间服务就搞定了嘛。

设计目标4000次每秒混合读写，直接透传给MySQL读写SCSI磁盘的方式肯定扛不住，那就DB前面再加一个cache呗。cache也简化一下，用内存临时表抗住。内部设计讲完要利用MySQL内存表这个办法，倒是让运维同学眼前一亮，找到了新的方向：不久后就直接过渡到了采用讲MySQL的db文件部署到内存虚拟的磁盘上这条光明大道。

虽然不知道为什么，直觉上就觉得读写4000次的指标定的有点低，不保险，改成8000-10000次设计目标，给1倍冗余性能。

于是开工、自己测试、拉运维测试一路走通。自己又写了一系列测试脚本，压测到1w次每秒毫无压力，心情愉悦。

于是，顺利走到半夜变更线上服务这个环节，为了保险起见，高草跟运维F同学都一起熬夜变更服务。停服务、上新服务、暂停请求、挪数据、重开请求一条龙都很顺利，然后大家一起等着天亮有服务请求上来再继续观察几个小时就没事了。期间一旦发现问题，就要立即分析修改。

一共动用了3个人的庞大人力熬夜变更（也许记错，反正不会超过5人）。

目标清晰，步骤明确，1点过后开始有少量服务调用请求，3点前都很正常，随着接近天亮时间，请求越来越多，就开始有点不对了，注册环节开始出现大量失败，这个就奇怪了。

于是，立刻开始在线分析(修改一系列前后台服务，加日志)。HTML正常，CGI正常，账号服务模块正常，DB出现了大量锁DB锁表现象。大家都一脑门纳闷，不应该啊，按照现在的拆分表，除非这一波注册的账号名字和分配的内部ID都集中到了某一个表，否则没可能出现！于是，继续线上分析注册用户名什么的，一切也都正常，就是找不到锁表问题。

陆续排出了恶意批量注册、CGI服务出错等一系列地方后，天可就要大亮了，这要是在上午开工前还没解决，那就绝对是大事故了，所有人都急得不行。

要知道，这时候就算直接回退回到老的服务那也是扛不住的，果断都在集中精力分析线上请求。一顿操作猛如虎，终于找到了头绪，出现了大量的同一时刻相同的写操作和读操作请求，写操作的SQL语句都一模一样，读操作还就是刚刚写的那个字段！而且，所有被调用的表都是如此！

继续往上找，后台服务请求正常，CGI正常，HTML正常，一路追到页面的JS......

所有人集体吐血了，这位伟大的JS开发同学，在一个注册动作请求内，同一个时间(ms级别)发送了2个一模一样的写调用和一个读调用。通俗点说，比如有人注册了一个叫AAAAAA的账号，那最后端的DB要保证先生成并写入AAAAAA的所有新纪录，然后才能返回一个select请求读出这条AAAAAA账号的所有记录数据，在写操作完成前，因为是新的记录，所以读操作是100%会被挂起的。而且正常情况下，这种一个写一个读先后到来，是不会出问题的。死就死在同时来了2条一模一样的写操作（眼明的同学一定会发现，这条读操作是不必要的，但保留问题也不会太大），写-写-读这个调用次序到了DB层面其实无法保证的，那100%会造成至少2次锁表，这就相当于一个调用被扩大3倍，而我的冗余能力只有2倍......

找到问题那就立刻紧急修改，大家一一问候了这段JS代码的先祖安康福寿无边，终于在上班高峰到来前彻底解决，线上服务稳定下来了，一身冷汗，真凉快~

仔细回想一下，出问题是必然的，因为所有CGI部分、老的服务部分代码我都一一看过，开工前唯一没仔细看过的地方就是HTML和JS这里！

这个故事告诉我们，无论何时，后台开发同学永远都不要忽视调用链上下的任何一个环节，尤其是前端，特别是JS。

从这件事以后，高草就养成了一个习惯，任何项目，都要把原始需求、定型需求、架构设计、线上服务调用逻辑分布和开发人员分配的每一个环节都弄清楚，有一个地方弄不清楚绝不动手。

时间久了，即使后来不做开发了，仅在需求安全性分析时都有了回报，比如戳穿新来的开发的小心思：别耍小聪明说这个难那个也难，一个屁大点地方就要开发1周，这玩意难在哪里，讲出来，咱们现在就分析解决，老子见过的坑，比你丫开发过的系统还要多~

哼~

阅读原文

跳转微信打开

不想说小红书，无他，有容乃大~

听话的孩子没奶吃，没背景的熊孩子会被拍死

听话的孩子没奶吃，没背景的熊孩子会被拍死

听话的孩子没奶吃，没背景的熊孩子会被拍死

先丢一篇18年的旧文（重点在故事5），重要的事情贴三遍哈~

当时写的比较隐晦，懂得人自然能明白在说啥。看不懂的人也总有一天会看懂，就像老人家常说的那句：

“这个啊，等你长大以后你就懂了...”

也可以换句话解释：没死过的自然无法体会那滋味...

嘿嘿嘿，套到天朝互联网上，那就是没遇到这批捣乱的人，那只能说明您的产品还不够大，用的人还不够多。19年才过了1半，被关掉的产品就已经可以列一屏了，但是仍然无法阻止烈士们前赴后继地向前冲。

在我的职业生涯中，时不时就有人来问：要做新东西了，得注意啥？你花半天力气给他解释注意要点，结局总是会说，哎呀，c端的内容问题以后再说吧，先发布了最重要。当然，在10几年前，这么做没啥大问题，能继续活下去等到有用户才是最重要的。

但是最近这5年，基本都没有然后了。大约有90%的产品是发布了是没人用的，也就不存在内容合规这个隐患，剩下的10%里面有超过9成的会在用户多了以后，成功地被警告要求自己限时整改或者直接关停下架，只有1成会真的落实内容上面的风控手段。

有点沉重，插一个笑话吧。很久以前，那时候东莞还没没落，我就常跟新入职的开发和产品同学说，如果哪一天你发现自己负责的产品里面出现了黄赌毒的内容，那就说明你这个产品成功了，用户数那是肯定至少几千万了。

这个笑话现在也许就要改一改，比如：如果哪一天你发现自己的产品被要求整改或者下架了，那就说明你这个产品曾经成功了。有容乃大，说的就是这个道理。

说回内容管控问题，头上面那根悬着的尺子一直都在，只是以前用的是自带松紧的皮尺，现在是游标卡尺。

如果一定要列要点的话，今年可以这么解读：

• 内容上面那根尺依旧是越来越严格，越线必挂，越线可以是产品运营失误、无知带来的，也可以是被越线；

• 各种牌照上面缺失的趁早转行（参考华尔街见闻等案例）；
  

• 没有遇到内容问题的，只能是产品还不够大，用户数还不够大；

• 摒弃侥幸心理，用户上规模的产品迟早会遇内容问题，这只是个时间问题而已，趁早补齐内容管控手段；

• 以上都做不到的，至少得用心招一个PPT做得好看的，道歉汇报可以增色不少，态度好，也许会挂得麻烦少一点；

阅读原文

跳转微信打开

也许再过几年，我也会不记得当时的好多细节了...

我相信如今这一代混迹网络的大小神仙们已经很少有人使用独立的email客户端了。包括纯办公环境，都有大量的在线Email系统，甚至我自己都至少2年没有启动过Foxmail这类pc版的客户端软件。只有一些极度在意移动能力和完美编辑能力的同学才会保留使用outlook、foxmail的习惯。毕竟，Foxmail这个号称一个U盘就能全世界都乱用的鼻祖还是不如web mail来的方便。

单纯对于Foxmail来说，有太多故事可以讲，但是清楚当初那些软件实现细节的大神有些去创业或者去干别的去了，少数还健在的又不愿意多说，如果再不总结一下，我都担心有些事情就没人记得了~所以，斗胆先说说本人经手过的一个特性的来龙去脉。

先蹲地上画个timeline，用力地往回拉，反正大约是至少10年前就对了。话说10几年前，小马哥买了Foxmail整个团队，没几年就打造了让丁三石郁闷不已的QQMail产品出来。唯一令人遗憾的是，Foxmail Server团队被解散了，每年静悄悄地就能完成销售额几百万的东西，说不见就不见了。原因只是，赚的太少，不差那点钱。有点扯远了，说回正题。具体时间，大概Foxmail 6-6.5这个版本发布前后几个月那时候。

那时候，大概也就是在gmail推出来没多久，gmail内置的搜索功能好用到令人发指。相比之下，Foxmail虽然也能搜索，但是那个搜索弱到爆，实现上使用的是类似用notepad打开全文，grep一次的做法。弱到开发自己都不好意思说那种，反正能用而已。

大概就在我上一个项目，修改完Foxmail垃圾邮件过滤引擎以后，没过多久，龙哥看我好像又没啥事做了，喊我顺便聊聊内置搜索引擎，比如对搜索这事怎么看之类的。已经不记得当时自己具体说过些啥，大致过程无非就是，这东西很有必要，而且要做起来也不难。具体要实现会遇到的技术细节啥的也顺便聊过一些，关键点是要足够小巧，足够快之类的。

总之，聊完就领了任务，这事有的搞。

技术调研过程啥的，其实没什么细节可提的，无非是体验一些当时pc版软件里面带搜索引擎的东西罢了。各种体验，各种分析，乱七八糟分析报告则能省则省，但阶段总结邮件少不了就行了，反正懒这一点上，那时候已经是地球人都知道的事情，不怕不怕。

说实话，因为这东西做起来并不难，我当时是没太把这事看的太重，毕竟本人上上一份工作就是在一家搜索引擎公司里混个开发职位。反而，在PC产品体验上的要求，比如小巧稳定才是个难题。于是，花了几个星期，用VC++做了个直接解析Foxmail存储文件的demo，盯着惨不忍睹的UI demo窗口，能完成索引建立和搜索展示出邮件的功能而已。

老家伙们肯定知道Foxmail是Delphi实现的，那我为啥用C++去做demo？其实原因很简单，懒啊，当年学过的一点点Delphi早就忘光了，千万不能给他们知道我其实学过Delphi，否则又要重新学一次，嘿嘿嘿~

当时的组长倒是对这事看得很重，还特意联系了远在深圳的soso开发团队，要我过去跟他们学习调研一段时间。soso那时候基本上是第一代刚发布完前后不久，实现的搜索效果我觉得是可以用基本无法忍受，只能说是能搜到东西来形容。

于是，我就兴高采烈的去大深圳出差了差不多个把月，整天跟soso的开发泡在一起，讨论各种实现细节啥的。高高兴兴的在大sz混了些日子，基本上把汇报文档该写啥都弄清楚了，立刻拍拍屁股回了大省城。汇报围绕着下面这几个展开：

1. soso的实现方式无法抄过来，服务器和pc在本质上完全不同；

2. PC软件上没有现成的东西可用，得自己开发；

3. 索引得支持即时生效，也就是新到一封邮件就得能立刻搜到；

4. pc版要保证100%查全率，不能容忍经典搜索的漏过情况；
   

至于为啥会漏过，也就是找不到，这事解释起来也很简单，搜索引擎并不需要保证每一个结果都能搜到，除去索引技术实现上带来的原生态漏过以外，搜索本质上只要有结果返回就行了。也就是说如果给人发现有一个网页找不到，可以归结为访问人太少而没有收录，大家也不会去深究。但是在Foxmail客户端的情况下，如果出现了一个邮件存在，但是搜一个词就是找不到，那就无法忍受了。区别不大，但是这是根本性上的区别。

总之，就是只需要抓住1、4两个点，其他都不重要。

既然提到了soso，那就顺便多说几句。当年的soso后台的搜索引擎实现的其实非常简略，我记得是基于Lucene做的一套包装接口（也许不是Lucene，请相关同学指正哈）。soso服务器的索引更新的代价又非常高，用采用了整体文件替换的形式做的可搜索内容更新，也就是在半夜得停机cp几个容量上T的文件过去，然后重启服务就能用了，一天更新一次。哎，又扯远了，收~

总结下回来的汇报，结论也很简单：无法抄袭(借鉴），自己重新写一个就行了，这事能做而且不难~

然后就是找Foxmail的开发兼产品同学聊天。这个也值得多说2句。

Foxmail其实并没有专职的产品，一直都是开发自己负责产品特性，负责的老大(vic)是一个很有想法的家伙，无论开发技术还是产品特性，vic都是当年跟谁聊天能聊到一个坑的家伙。其实，还有很多老家伙，比如leo、alex等都是非常有趣有个性的。

那时候的事，我只记得几个细节了，开发同学对搜索技术的神圣感是很强烈的，觉得这玩意应该小心地学习并认真地研究一下才行。当前的grep式的搜索实现方式虽然丑陋但是能用，新版本除了要保证一个不漏地查到结果以外，消耗资源还要足够小而且非常小。

什么叫消耗足够小呢？当时的windows pc经典硬件环境是1G左右的内存，几十G容量的机械式硬盘，那性能现在看可是惨不忍睹，更不用提办公环境下，Foxmail遇到的经典使用环境：主流笔记本电脑的硬盘和内存那才是要多坑爹就有多坑爹。

Foxmail的开发同学一听我说经典的索引实现需要容量最少得1.5倍左右，就立刻翻脸：这怎么可以啊！一个使用场景一天也就几次的东西，坚决不能占用那么多磁盘空间和内存（Foxmail的存储文件格式不带压缩，就已经很浪费空间了）！硬盘占用能不能压缩到1倍以下啊，内存能不能最多用10M啊，不用的时候内存能不能给我释放出来啊...反正，我当时回答是说，这些啊，都能做到啊，这几个要求都能做到，无非是做个取舍而已。

总之，功能特性上面的调研就算做完了。几个核心指标一出，我反倒是高兴了不少。因为，原本我也没打算用"正经"的中文搜索技术去做这事啊。分词？分词根本不需要，直接基于字就行了，上BDB（Berkeley DB开源了，大Linux上系统核心都在用的东西，错不了）。简单几个BDB的表，再把索引弄进内存，足够小了，无非是检索结果取交集的小问题而已。（这里其实埋了个大坑，这个坑后面有机会再说）

反正，几下子，demo是做出来了，VC++直接解析Foxmail的存储文件，在几十万的邮件情况下，建立索引、启动/重启、查找、展示结果邮件都足够快，跑起来也足够稳定。

拿去给vic,leo同学体验，也给龙哥看了下。大家觉得很开心，貌似不错。当然，技术实现细节我肯定是不多说的。印象中，还因为没有使用"正经"搜索技术这个事，跟我的开发组长吵了一次，他觉得做搜索就得用传统搜索技术，你这个实现的非常不专业之类的，当时我怎么反驳的已经不记得了，反正最终结果是并没有因为这次争吵而改掉实现方式。（因为这次争吵，又埋下了一个大坑，以后有机会再说）嘿嘿嘿~

然后，就是认真讨论怎么融入Delphi实现的Foxmail里面的问题了，要做个内置搜索引擎的Foxmail测试版出来。由于我"不懂"Delphi，也不方便直接切入Delphi客户端开发(我当时的职务是后台架构开发)，leo大神就被指派跟我合作。分配结论就是我继续用VC++做DLL，leo用Delphi调用并实现搜索入口和结果展示相关功能等等。

用不用分词技术这事，又反复pk了几次，产品同学认为分词必不可少，当我解释用最烂的分词技术，准确率也能轻松达到97%，但是要进一步解决用了分词以后带来的查不全的问题，单独的分词引擎就需要几十M的资源，还得增加好多处理逻辑，各种不划算啊不划算啊，总之解释了不下3次，如果一定要实现分词，soso当时在用的分词技术也还不够完美地。要完美的化，我们得招一个专门维护这玩意的人才行。在不能消耗过多硬件资源的大要求面前，这事就必须让步了。

进而，又因为这个讨论，写出了一个分析邮件，里面对当时国内中文语言处理(NLP)的技术和可用人才做了一个简单分析，还带了个列表，里面又不小心提到有个家伙很牛，今年应该要毕业了。SZ总部在看到后，不久就果断招了我的一位师弟。该师弟入职后做的一个重要产品好像就是QQ拼音输入法。不过，这又是题外话了。收~

反正，经过个把月的开发联调，解决了几个自己测试就发现的重大问题，比如：

1. 搜索功能被线程独立出来了，跟主程序逻辑结合在一起会分分钟卡死的，因为原本的Foxmail主界面逻辑已经很多了，自己的界面更新性能都卡(好像7.0版才解决掉主逻辑过多的问题)，更何况要调用大量的外部处理接口；

2. 软件崩溃或系统蓝屏会导致频繁的文件数据丢失问题，windows文件系统这个大坑真是巨大无比。好在BDB自己就有索引修复能力，再增加一个独立线程，启动时先检查一下索引完整性，能修复就修复，修复不了就悄悄地重建呗；

3. 搜索到的邮件结果展示上，增加了一系列贴心的高亮提示功能，比如收发件人和标题命中了目标词，列表上就直接高亮出来，立刻好看了很多；

4. 内存占用上面pk无效，依然被卡死在最多只能使用10M左右内存的情况，于是，搜索性能下降不少，只要不是几十万上百万邮件，区别倒不是特别大；

5. 支持了全部资源释放能力，目标是在不用搜索功能的时候，要能够把这10M的巨量内存都还给系统，吐血；

6. 人为构造了很多文件损坏的场景，大家都认为重建对磁盘的冲击太大，磁盘卡顿会导致windows卡顿，windows卡顿会导致Foxmail卡顿，Foxmail卡顿会导致搜索功能卡顿...
   对这里的资源消耗人为降低了系统处理的优先级，自然结果就是慢，无比的慢了，甚至有时候完全重建需要花几个小时之久；

7. 还有一些乱七八糟的优化记不清楚了，反正是搜索入口上跟原来方式一样，还能无缝切换回老grep模式的能力；

然后就是不停的测试、修改、小规模释放beta版本给外部用户体验，再修改、再测试的循环套路。

也许是Foxmail的测试群体又可爱，又特别富有，他们的笔记本和pc性能都非常好，结果是竟然没遇到什么大问题，以至于正式发布的时候才收到一些认真的批评和改进意见，这又是后话了。

主要的大问题集中在：

1. 搜不到结果，添加索引的时候软件/windows崩溃了，邮件根本就没有送去建立索引，校验也没发现，改~

2. 系统严重卡顿，大量用户的pc内存特别少，那继续降低内存和磁盘占用资源，改~；

3. 重建索引太慢，甚至重建无效，因为总有人发现用不了就杀了Foxmail重启，重启发现还是不行，就再杀，上帝啊耶稣佛祖拉登川普啊~；

总之，一系列哭笑不得的事情都发生了，但是好在大家都认同了必须在搜索功能必不可少的大方向继续走下去。而要想彻底解决这些，得重新用Delphi再实现一个更加简化的引擎，BDB在这个情况下还是太重了一点，本质上来说，只需要一个index而已。所以，再后来的版本，就放弃了BDB的DLL部分，Foxmail的开发同学完全消化了需要的BDB少量功能后，大概在7.0版左右重新实现了一套更简单的版本，也就是现在大家还在用的这套方案。

总之，在充满了各种欢乐而祥和的pk和修改过程之后，全文搜索功能一直在修改和进步中。而且这过程里，还有个小笑话很好玩，值得讲讲。

在带全文搜索功能的版本正式公开后没几天，一个大学同学突然发消息给我，上来就直接问：foxmail里面带的这个搜索功能是你做的吧，是不是？快说！我立刻震惊了，尼玛，这也能被认出来，我可从来没公开说过这玩意是我做的啊！立刻反问，你怎么知道的？该同学丢了一句：IndexLib有个奇葩的文件叫：tcpip.db的东西，我估计全世界也只有你才会无聊到起这个名字。我~~~无语~~

其实Foxmail在资源命名上面的各种类似人性化方面，这可是有着优良地、悠久地历史传统的，我才不会告诉你，原始代码里面还充斥着大量的aa，bb，x，yy这样的变量呢，至少这个文件我还把他叫.db了，已经算很好了~

再然后就是QQMail也决定要做全文搜索了，只不过这次不需要我动手了，老大调了一个新入职的实习生，责令我手把手教了一段时间（前面自己挖的坑自己填哈）。这次，终于把“正经”搜索引擎改用的技术实现要点，从头到尾教一边，这位同学当时基本全程蹲在我座位旁边拿个小本子记，每次都要我给他拉个座位过来才坐。然后这位同学顺利做了出来QQMail的后台搜索服务模块，再往后，又顺利做了个总监，自然这是又是后话。

故事先讲这么多，还有很多好玩的事情，以后想来再说。更多的关于Foxmail的细节必须得期待当年做Foxmail的大神（包括UI艺术大神bobo）和现还在维护代码的大神们动手才行，希望本文可以抛砖引玉，大家不妨先看个热闹~

阅读原文

跳转微信打开

认真点，我是来看热闹的~

基本上今天的热搜榜单消息都是某度帅哥带来的，一时间各种剪接视频、与段子手齐飞。不清楚背景的朋友，建议使用某度以外的搜索引擎搜一下，热闹程度估计赶得上春晚~

好吧，背景省略口口口口字，直接说正事儿。

某度开了个坏头

其实百度开了不止一个坏头，究竟多少坏头，并不难数出来，医疗推荐、骗子推荐、假官网推荐、大量盗版资源下载整合等等一系列产品特性。基本上吃穿住用行一个都跑不掉，除非你不用baidu。但是，自从404公司成功的被404以后，国内还有啥能用的搜索引擎呢？

简单点说，百度开了个坏头：一下子让大家知道，原来搜索引擎做不好依然可以大把赚钞票啊！一时间，大家看到榜样了，胆子大的直接雇佣动物干搜索的工作，也都火起来了，狐啊，狗啊，猫啊都能360度旋转地搜地一下给你个答案列表了，各色神仙一下子都有正式工作了，更不用说时不时不好用，但自带保健壮阳效果的必硬......嗯？倒是有个最善良的直接雇佣人民去搜的......

开了个坏头啊，开了个坏头啊，没有人真正去做搜索引擎了啊~

某度破坏了热搜的行情

这个应该是今天业内人士最气愤的点，否则拿来那么多职业段子手发布砸挂小短文啊。

2块钱买不来吃亏，2块钱买不来上当......(请自行循环)

其实并不是2块钱的某宝矿泉水招谁惹谁了，哪有那么多人心疼矿泉水啊，他们心疼的只是好不容易才跟明星"打成共识"的热搜价格行情啊~TMD，中4到小5的起步价行情咋突然一下子就崩盘了呢？以后委托方再发布任务，那肯定要砍价啊。

"预算就2块，你干不干？不干我找张全蛋去了啊，人家肯定接活儿~"

......

(术语解释：小4就是1k-3k，中4就是3k-6k元，小5就是1w出头，以此类推)

还是咱们中文波大精深

从当年鬼子恍然大悟，历经一番考据查证，终于找到what's up!这句的出处（汉语我艹），奔走相告之余，好多外国人开始学习中文。

自然，说话间就容易汉英夹杂，嗯，很时尚的赶脚~

作秀不止，商机无处不在

好像2块钱的某宝就没有抓住这次商机，截至此文发布之时还没看到矿泉水有官方声明出来，但是另一个某宝已经有同款商品了哈~

麻烦认真点，我是来看热闹的~

阅读原文

跳转微信打开

2017年8月19日，中国贵州射电望远镜“天眼”接收到一个来自外太空4光年外的可疑信号。2017年8月19日

2017年8月19日，中国贵州射电望远镜“天眼”接收到一个来自外太空4光年外的可疑信号。

2017年8月19日，霍金郑重向中国警告：“不要回答！不要回答！不要回答！”

2017年9月1日，经过中国政府对外星文明接触各种可能性的慎重考虑和分析，决定不能放过这次千载难逢的机会，并认为中国不回答其他国家也会回答，而且指出这次的交流也许可以引发全人类科技的大跃进，中国决定回答。

2018年5月6日，中国科学家宣布了发现了太阳的分层结构，可以利用太阳当作一个电波放大器，将人类的信号扩大发送到宇宙中。

2018年5月7日，霍金最后一次警告中国：“不要回答！不要回答！不要回答！”

2018年6月14日，中国用太阳向接收4光年外信号的方向，回复了一封信息。内容包括地球行星概况、地球生命系统概括、世界历史基本信息、全部信息为17.5KB。历史学家命名这一天为“回复日”。

2018～2019年，人类度过了最后平静的年。

2019年1月9日，全球射电基地同时收到了数以万计的宇宙信号，全部来自四光年外的同一个方向。面对如此反常的信号，人类终于意识到了危险和恐惧。

2019年2月10日，联合国紧急召开会议，共同研究外星信息内容破译，并宣布全球进入战备状态。

2019年3月30日，在这段时间地球每日都在持续接收大量外星信号下，联合国外星信息解译小组成立了，集合了所有世界顶尖级科学家，并马上投入到对这几万条外星信息内容的破解翻译工作中。

2019年4月26日，联合国确定了一个国际性的合作方案，并正式启动了人类逃亡计划，各国拟定经济节省计划，控制人口计划，并开始投入全力研究宇航技术，建造太空舰队。此时，地球每天收到的外星信号越来越多。人类知道，留给自己的时间不多了。

2019年5月22日，一年后，正当全球火热造飞船时，外星信息解译小组对外宣布，解译程序终于开发成功！

2019年6月26日，在联合国大厦的会议室里，各国首脑紧张地盯着屏幕，程序显示这几万条外星信号都系同样一个信息，随着电脑的破解，一行字清晰地显示在屏幕里，人类终于第一次读到了来自宇宙中另一个世界的信：你们那儿青鱼草鱼罗非土鲮有口吗？

此文来自网络段子手，侵删~

阅读原文

跳转微信打开

人总应该有点焦虑的东西，否则就太不科学了。这是一篇比较丧的文章......

今天一觉醒来，发现有好多小伙伴在表达自己的各种焦虑。起因是有人写了一篇传播都很高的中年人焦虑文，于是，大家纷纷表达各种焦虑，比如中年人的焦虑是啥、中年人焦虑的正确姿势是啥、该焦虑点啥等等。

看他们讨论了大半天，还是感觉这些焦虑好像跟自己现在的心态没啥碰撞。

但又好像没有焦虑点啥好像也是非常不对的事情。认真想了半天，终于找到了目前我最焦虑的东西：不知道该去读什么文章 /书籍，不知道去哪里找可以读的东西，这是我目前最大的焦虑所在。

花了几分钟，梳理了一下这个焦虑存在的基础，大概就是下面这几段的开头被方块标点符号引出来的部分。

• 有惊喜的东西越来越少

不知道从什么时候开始，我好像越来越不想读一些带深刻属性的东西了，打心里就反感讲道理和鸡汤。总想找点有惊喜感，寻求有碰撞能引起共鸣的，最好还是带盲点属性的东西去看，去了解。

还好，我的求知欲望还在。可是我不知道去哪里能找到了。当知乎被尊称为逼乎的时候，当那些大神都不写东西的时候，我开始发现睡觉成问题了。因为，睡不着的时候，我喜欢打开知乎这类地方，去找一些很专业很枯燥的文章去看，可是酝酿睡意的地方也没东西看了。于是我的睡眠质量开始下降了，哎~

慢慢地，书籍影视方面，发现总是不自觉地去选择一些玄幻类、轻松类、无脑搞笑甚至无脑恐怖的东西去看。因为，这些东西没有负担，看完忘了也就忘了，不会有遗憾感。阅读变成了碎片化，变成了打发时间的一种途径，但自己却不知不觉的乐于此道。

• 本性上拒绝参考排行榜，越来越讨厌专家的推荐列表

因为职业经历的关系，对排行榜的运作方式非常熟悉，甚至是太熟悉里面的各种套路。慢慢地，从偶尔看看排行榜都有啥，到现在直接拒绝去看，是这几年最大的变化。也许是在本能地拒绝人云亦云，对过度商业化的东西本能地反感。

也许是现实里突然间冒出来太多的各个领域的专家，比如电视推销、商业化评测、书籍思想类的分析和推荐。天知道怎么各种专家怎么就突然井喷了。越来越多的专家也要吃饭啊，尤其是"专门"的饭和跨行跨领域的饭。

所以商业化专家越来越多，也就慢慢的从被仰望变成了被平视甚至被鄙视。不信，你试试去当面对一个朋友说，xxx你就是专家啊，看看他会不会打你。

于是，推荐列表慢慢的变成了一个收入列表，这是一个负反馈的虚幻推荐系统，一个楚门的世界：大家都活在楚门世界的虚幻的名气列表。

于是，有良心的推荐会被慢慢淹没，慢慢被无视，慢慢被挤出推荐行列，逐渐淡出逐渐消失。

慢慢地，好的列表越来越难找，慢慢地，推荐列表==作者收入列表了。作者也是要吃饭的啊，毕竟猪肉都涨价好几倍了，养专家的费用也越来越高，于是这个循环停不下来了。

于是，有多少推荐列表就有多少种不靠谱，越是所谓精准推荐所推荐出来的东西没有一个是我感兴趣的。当视频变成一个全国2b分成2个派系存在，一半在xx，另一半不在xx，当d音变成d阴的时候，视频类内容网站我只保留打开b站的习惯了，只因为那里没有广告而已。

当你抱怨说推荐总是不准的时候，基本上很容易被结论，那只能是因为你是小众的这一个原因。可是这只是我一个人遇到的问题吗？当阅读行为只被KPI后，我确实成了小众，成了bug般的存在。

• 纸质书刊越来越没看头，上古的各种信息获取途径正在消失
  

比如个性十足的神话级站点，文字型BBS、带图的blog都慢慢消失了。在互联网上已经消失的这个地方和另外一些早已404的地方，曾经是我每天一定要去淘沙的地方，在哪里有各种fw的信息，而且只有文字。

对了，那时候只有2个途径能快速地去发现一些可以延申阅读的地方。一个是图书馆，纸质化的东西永远也翻不完。另一个是去上网找东西读，被亲切的叫做冲浪。就如同在翻垃圾堆一样，总能找到惊喜，浪里淘沙的感觉非常容易让人产生满足感和喜悦感。

可是如今图书馆和新华书店都已经关门的关门，大卖流行读物的仍在大卖流行读物。反而在一些街头手推车上，能看到一些盗版的经典好书，可惜错别字太多了。

我最近就专门去省城的新华书店，想要去找一本专业化的统计学方面的书来翻，结果花了一个下午时间才找到一本！书架上的各种统计书籍，不是对口考试过级的，就是启蒙教育图文读物，都不是我想要的。

慢慢地我发现，我有好多年没有购买纸质书籍了，当年所买的那些被用来垫音箱和养小虫子了。于是，我开始整箱整箱的扔纸质书籍，直接放在楼梯口。小区里收垃圾的人很喜欢这些东西，他们是可以卖钱的，会帮我免费搬到楼下去的。

• 去他妈的朋友在看的东西
  

朋友在读的东西90%不是我感兴趣的，而且我不也想做偷窥狂。之前职业生涯里，长期站在所谓的上帝视角分析正在传播的内容和传播手法，对这些越来越不敢兴趣。

理由很简单，一个人看了什么文章是一个很隐私的数据，除非他是主动分享出来。但是不难发现，大家都不愿意分享了。原因更简单，个人所感兴趣的往往不是你的朋友也感兴趣的，当分享后没有反馈的东西越来越多的时候，分享也就变的没有"价值"了。但分享列表仍然存在，只是会被刻意传播的东西所攻占，被大家都喜闻乐见的东西所攻占。这里才有正反馈，才有回报啊！

可是，目前仍然冷冰冰的算法是不会理解到这些的。靠过滤解决嘛？

可能嘛？

不可能吗？

......无限循环......

有时候我也很矛盾，看到乱七八糟地和那么多无脑谣言都有那么多人去读去传播，很想找出来这些家伙是谁，至少得翻出来联系方式直接删除。但是，当另外看到一些没见过的福利文章时又很想立刻拉个群，求分享，人啊，人都是很矛盾地啊。

于是微信里的那个叫看一看的东西，我反复开了关，关了开，每次都试图说服自己算法应该有改进了吧，每次都是失望的关闭。

• 越来越讨厌被喷子、无脑粉、杠精正在关注的东西

这是个很奇怪的变化，无论什么东西，被关注度越高，评论里面的喷子和杠精就越多。慢慢的，我开始反向筛选了，开始去关注评论区没有喷子存在的东西。

很可惜，能找到的惊喜感更加地低，连杠精都不愿意浪费精力的地方，确实没多少营养可以挖掘，这又成一个负反馈系统。

当每个人都开始追寻标新立异的时候，恰恰是因为大众的视野里已经没有多少惊喜的东西能排在前排了，也就是大家的兴趣点都被拉平了。

于是...

    当书店能看的越来越少时，我开始找(盗版)电子书了...

    当所有的新闻站都是通稿时，我开始不看新闻了...

    当微博都是几十万上百万转发时，我开始不看微博了...

    当朋友圈都是微商广告，全民拼买/卖茶叶后，我开始不看朋友圈了...

    当字幕组开始解散，鬼子剧站点纷纷关闭后，我开始不看美剧了...

    当五毛开始出国攻占推特这类地方后，我开始不翻墙了...

慢慢地，开始有一种自闭倾向化：阅读面开始越来越窄了，反而焦虑感在逐渐消失，很奇怪吧。

大家能看的东西都在慢慢的呈现扁平化，我们开始生活在一个古人叫天圆地方的地方了，放眼望去满目都是地平线了，于是，我又焦虑了......

我该去哪里找可以读的东西呢？

阅读原文

跳转微信打开

又有几天没发新更了，毕竟高草是很佛系的，想到啥写啥。之前没更，原因还是一个字：懒啊~来吧，今天整点跟以前风格

又有几天没发新更了，毕竟高草是很佛系的，想到啥写啥。之前没更，原因还是一个字：懒啊~

来吧，今天整点跟以前风格不一样的东西。

下午睡午觉的时候做了个梦：大街上走来了个垃圾回收的小车，依稀还能辨认出上面印有Mobxxx字母的样子，还有2个明显是新喷漆的亮黄色轮圈。单车车把上挂了一个大喇叭，滚动播放着：

“收~旧代码喽，旧代码换白面喽~收上古程序代码喽，能编译的可以兑换不锈钢盆3件套喽......”

“收~旧代码喽，高价收购旧代码喽~带程序员签名的5毛钱100行喽......”

“收~旧代码喽......“

对，是大功率扩音器录音循环播放的吆喝声，就跟街头的卖老鼠药卖蟑螂药的小贩吆喝的节奏是一模一样的那种......

于是俺立刻就醒了，擦擦汗，仔细想了一下，昨天骑单车去钓鱼回来好像还欠1块钱，嗯，立刻打开微信，果断付款1元人民的币。

这个梦看起来有点诡异，但是一番思考后，高草补齐了上下文。应该是这样：未来的某个时间，会写代码的人越来越多，写代码已经成为走路、说话、放屁一样的基本功能。世界上的旧代码也越来越多，有些还成了古董文物，被收藏在博物馆。民间也出现了一些收旧代码的人，但是那些旧代码回收之后的用途只是用来替换维修一些上个世纪的老东西，比如电视机、电冰箱、吸尘器，电动车啥的，捡到运气好的可以卖给博物馆当展品。

诡异嘛？其实，这就是神棍高草曾预言过的程序员行业的未来。

嗯，在不久的将来，程序员行业会扩大，但待遇会逐渐萎缩，待遇崩盘式下降。但原因并不是会写代码的人越来越少，真实的情况会是人人都会写，会调试，会发布，可以直接应用。毕竟是从幼儿园开始，就有人教的东西嘛。

于是，程序员职业不再是一个让人羡慕的高收入稳定职业。工作环境就如同电子厂流水线上的纺织女工一样，经过几天针对性培训就可上岗，流水线生产代码。嗯，计件标准就是代码行数。

不要笑，这个局面也许未来几年就会出现，也许过几年你就笑不出来了。趋势已经在出现，比如有人在研究AI自动编程，街道培训都有编程课程，好多HR都是自己写网页、做小程序了。我一个认识快20年的在赛格卖电子产品的朋友，最近都在开始自己写代码，每天在各大电商上倒买倒卖手机，只赚中间商差价那种。所以，以前需要进空调房、必须穿拖鞋戴头套的高大上职业，正在诡异的民间化。

趋势这样发展下去，那么，广大码农该咋办呢？别急，佛系一点，先调整心态，看几个小故事。

现实里熟悉高草的朋友都知道，高草还在上班的时候，每年招聘程序员时，几乎不会去考察写代码的熟练程度。基本上每次都是随便打印几张试题就出发。这几张题目的作用也仅仅是用来稳定一下面试人员的情绪，给他们30分钟进入角色，然后那几张纸扫一眼就扔一边了，也不会认真去统计得分多少。原因吗，毕竟去招聘程序员，你不考编程，那也太不像正经招聘了吧，没办法，还得考！只是这个考点是装装样子的而已~

在每年大学城例行的招聘活动上，高草基本上每天都要面试20-50人，经常会叫一些试卷得分只有10-50分的进来聊。嗯，确实只是聊，全程只考察思维倾向，和问题分析能力。笔试的编程题目呢？放在面前，偶尔看一眼，嗯，还是装样子用的。

其实，高草坚持这么做已经超过10年，从未改过。也许有人会好奇，这样能招到目标人员吗？答案是不但能招到，甚至还更好！举个例子，用这样的方法，高草招来的学生屡次不小心拿了就职公司的专业技能比赛前2名，还有直接代表天朝队出国组队比赛的。这些人离职后的去向也都是各大公司，甚至鬼子的google和高校。也就是说，并不是我说行就行，鬼子也说行哦！后来，某业内正在招人的大佬问我，你是怎么做到每年都能找到几个牛逼人才的？

高草的答案是：因为我没有在会写代码的人里面考察，我的做法是在专业行业内找会写代码的，在有相关项目经历的人里面找会写代码的，就这么简单。

继续讲故事。大概是2003年前后，高草就职一家高新小公司，老板很穷，接了项目才敢招人那种。在给一家大公司的项目上，高草要人，当时市面做这种项目正常程序员工资是3-4k/月。于是毫不意外，老板给了几位每月发薪水2k的。没办法，高草只好边做边教他们设计框架的东西，顺便教教写代码。里面文凭最低的好像是一个中专还是大专生。

不过，这些都不重要。项目肯定可以按时交付，算上教写代码时间也问题不大，毕竟项目够简单。于是，几个月后，这几位2k的程序员都顺利成长了，写代码的能力也基本超过市场中位线(工资肯定不会变)。后来公司办不下去，这个学历最低的家伙离职，顺利面试进入了一家给电信做行业软件的流水线代码公司（要知道在那时候，学历要求一般都是本科对口毕业的）。入职一段时间后，他告诉我：当时教我们的那些东西，他们都在用，干起来确实没啥难度。

其实，高草当时并没有去手把手教他怎么一行一行写代码，告诉的东西仅仅是框架方向该怎么走而已，哪些坑爹的做法不要做而已，输入输出怎么打包而已。挑他们代码的毛病，也就当面演示过几次。说穿了，也就是大家在读大学时候学到的东西：学什么不重要，怎么学、怎么吸收，这个过程最重要。

加送一个小故事。某一年大学城招聘，在考察一位大三的学生的时候，他的笔试代码题目只得了40多分，我问他，为啥这么早来企业面试。这小伙回答是：我想提前找点经验，看看企业实际的要求是啥，这样剩下来的时间可以有针对性做准备。其他问题也聊了一些，比如脑筋急转弯，专业课程专业知识底子这些。于是，高草兴致也来了，指着试卷跟他说，你错的地方基本都在这里，用点心很容易写对，明年再来，我希望看到一个高分。果然，第二年，我又看到他了，试卷得分80还是90多分，而且有一道题目是试卷标准答案就是错的，分数还应该高一点。但是他已经不记得去年跟我聊过了，也就是说这家伙没少参加各种笔试面试，我手里的offer果断发给他。

前一段时间，跟他的现任直属领导闲聊，不经意提起这家伙，现任领导说，xxx干的一直都很不错，而且特别努力，已经是骨干了。

再讲一个。某年闲聊，一位通过自身努力去跳槽，并顺利跳高管的家伙爆料，刚刚我面试了x公司的一个总监，给了他一套编程题，竟然写的完全不及格，被我虐了一顿果断淘汰了！看来x公司的总监水平真的是下降很厉害。现场有人问，你干嘛要用初级c程序员的试题考一个运营总监啊？有人在一边小声说道，这其实是个轮回啊，是个轮回啊！(该高管)从小就一直被考各种编程考试虐，现在终于轮到他能考别人了，必须肯定一定这么干啊，而且当年那个总监就是用这套题面试他的......

故事很多，就不继续讲了。不妨总结下小故事的中心思想：写代码能力高低在要用人的时候其实并不重要，脑子够不够用才是关键。高草一直认为，只要是智商正常水准范围内的，肯下功夫去训练的，用几个月都可以成为代码熟练工人，类似30天学会java，20天精通python其实并不是什么难事。所以，只会单纯的代码技能的程序员恐怕未来的日子会很难过，原因只是一条：当人人都会写代码时，你该怎样突围？就像人人都会听歌，都会唱两句，但歌星能发片的会有多少人呢？

所以，程序员也许是时候换个思考模式了，写代码并没有多么高大上了不起。会写代码这事，慢慢就会成为会外语，会加减乘除那样的基本技能。当然，写的好的人一样有高价值。但是，所谓的编程科班毕业证将不再值钱，最好的时候这个证也仅仅相当于过了英语4、6级而已。

问题不复杂，怎么去看待这个发展才是关键~

迟早，写代码这个行业会成为一个夕阳行业，职业码农不再是段子。也许未来几年，长三角、珠三角用工荒的新闻会这样写：据路边社报道，今年长三角、珠三角码农荒问题将比较严重，流水线缺口人员达到5-10万人。记者随机采访了几位务农在家的码农，他们表示，如今乡下的养殖业政策比较好，县里物价水平不是很高，暂时没有必要买个高铁票去大城市里挤，而且那边房租太高了......

继续本文开头的无聊预测，当人人都会写代码，码农技能普及后，报纸、网刊上也会有一种专栏，介绍一些达人的先进经验。比如会出现这样一些视频新闻标题：

• 农业部专家预测，今年程序员秃顶指数继续保持最低水准，如行业继续回暖，则码农就业率将可提升2个百分点，预计对今年GDP贡献度可以达到10万分之0.1......

• 快看！看我如何用100行代码，把河南生产的大饼机改造，能做出海南鸡饭啦......

• 今年秋季不用买新款加湿器，100行代码搞定......

• 快来点赞，我家冰箱学会了新技能：100行就做到了......

• 吸尘器里的秘密：hacker大佬教你亲手改xxx牌吸尘器，轻松拥有自动爬楼梯功能......

• 16岁少女翻地挖出一箱旧存储器，经文物鉴定机构鉴定，价值千万......反转！竟然是假货，这究竟是怎样的一个骗局？
  

• 本月出现一波旧代码投资风潮，专家提醒大家，不要上当！旧代码不值钱、旧代码不值钱、旧代码不值钱。以下是科学院xyz院士对这股炒作风的深入分析，详细内容请看今晚8点的专题报道......
  

• ......
  

加送一个福利旧闻：

文末放个小游戏，记录一下大家的预测哈。

阅读原文

跳转微信打开