规则一致，哈哈，这个一致是怎么个一致法儿？能在你的能力范围内，用代码简单实现这个规则，是吗？你的能力范围在哪儿呢？

天黑黑，是时候听一听 AI 孙燕姿的歌了

你这个帖子适合发到「组队」。没看出来有啥奇思妙想，公司不就是按贡献分配的么。

@Livid /go/meet

@Livid /go/qna

按 30%估算是 30 万，实际是 21 万。估算准确率还不错。

看了下，敏感词很可能是「政.府」。

@goodryb
问题在于，按照上面的分析，它这样加速爬，不管是单机加速爬，还是分布式加速爬，10 倍的加速，会给 v 站造成 10 倍压力，100 倍就是 100 倍压力。

这样走捷径，相当于是走了歪路了，把用户和站长都触犯了。推出新功能，完全可以循序渐进啊，比如 v 站有 90 万个历史帖子，但不必都爬完，就可以推出新功能。想挖掘历史帖子的话，可以逐步挖掘，比如先爬取 1/3 的历史帖子，这 1/3 的历史帖子(30 万条)，完全能够支撑新功能。后面再逐渐补充爬取剩下的 2/3 的帖子。

@shyrock 事件的经过大概是这样的：

v2ex plus 插件作者开发了一个关于 V2EX 的新功能 vDaily ，可以发布类似于 v 站帖子排行榜的功能，也有挖掘历史帖子展示出来的功能，所以它不光需要 v 站近期的帖子，还需要历史帖子的数据。

按照 plus 作者的说法，它向 sov2ex 作者借了一份爬取过的 v 站的存量帖子数据，但有些数据(点赞数、感谢数)不全。
https://www.v2ex.com/t/939486?p=2#r_13072169

所以，plus 作者决定自己爬取历史帖子数据。根据下面用户的反馈，这大概是在 2 个月前开始的：
https://www.v2ex.com/t/924796

问题在于，plus 作者完成这个爬取的过程，是借助 plus 插件用户：它用服务器下发给每个 plus 插件用户一些主题 id ，让这些用户在本地帮它完成主题的爬取，然后上传爬取到的主题内容到 plus 作者的服务器上。这就导致了刚才提到的那个帖子里，plus 插件的用户突然发现「最近查看过的主题」里面，出现了一些自己从来没有看过的主题。

plus 作者的这个决定，并没有征得 plus 插件用户的同意，没有显式给出这些用户自主选择的权利。

其实单 ip 爬取 v 站的数据，分布到 6 个月内，按照 90 万个帖子，180 天，每天大概 5000 个帖子，平均 20 秒请求一个帖子，对 v 站造成的压力应该不会增加多少。猜测 plus 作者可能是想快点爬完？

写自己的代码开心，这点没错，尤其是正在给公司写代码的时候，感觉最强烈。

@GalaxyVIP 就是自建的啊，看我#14 楼的回复。我也不知道为啥。Google 风控也不能让连着输入 20 多个验证码啊。我特意查了一下，digitalocean 的 vps 的 ip 应该是独享的，没有第二个人同时共用。

「让用户把附件中的 index.html 放到服务器上」，路子真野。。

可以看一下帮助节点。
@Livid /go/newbie

@yujinchn776
@MrGba2z
我是自己搭自己用的，每月 5 ，6 美元哪。

@joefuzhou198x
@hsir
登录了，之前管用，现在也不行。

@churchmice
chatgpt 可以破解验证码啊，无论多么复杂的。(待验证)

「目标是。。通用型数据记录与分析工具。。通用型就是不针对具体场景。。这是我想到的目标用户」

我看了下楼主的 App ，楼主你没有把 App 的特色表达出来啊：展示的图片里面，没有展示最关键的模版功能。也没有一个官方网站来说明「通用型」这个特色是怎么用的，尤其是是怎么用模版来实现通用的。

「隔靴搔痒」，大量“炫耀”的篇幅只是勾起了痒，喧宾夺主了。偶尔点缀当然可以挑逗味蕾，可你只贴出账单，却不贴出如何拿到这些账单的经验，缺少营养。

前面几楼的回复不就是鲜明的例证吗。