我收到大量投诉的一点是每日点赞“刷新”的频率。它并不是按天重置的数字，而是根据你使用点赞的时间逐个恢复。
“每日”限制意味着第二天你的限制会重置，你会重新获得相应数量的点赞。如果是一次性刷新，会合理得多。信任等级权限取决于独特的互动，因此每日限制不会影响这一点。
这对我们最活跃的会员来说是个问题，其中大多数人已经达到 TL2 或 TL3 级别。他们与我们的网站互动非常频繁……在大多数情况下，每天发布数千条帖子。必须等待这种奇怪的逐步重置，阻碍了他们的互动。
我肯定会根据用户实际使用网站的方式提高我们的点赞上限，但希望代表他们向 Discourse 团队提出这一请求。我经常收到此类请求。我们甚至有一个关于“点赞禁闭”的讨论帖，即将达到 1 万条回复的限制。
嗯，这和我想的不太一样。但既然已有近 1 万次关于点赞数不足的投诉，为何你们没有增加点赞数量呢？认为“计数器重置时间”会显著改变许多人的情况，似乎有些牵强。
好吧，我又这样做了。哈哈！说实话，我其实不确定合理的基准上限应该是多少；我们的社区显然用得很多。对于基准点赞数，是否有我不应超过的上限？我们实际上并不在乎他们用了多少；用得越多越好。这只是信任系统的一小部分，因此使用量增加对信任等级访问部分完全没有影响。
基本上，很多用户是 24/7 在线的；他们期望在某个时候会有重置，但这并不是他们遇到的情况。“每日”限制意味着每日限制会每天重置，但事实并非如此。
我猜这是 NaNoWriMo 的论坛，说实话，它总是会有点奇怪（作为参与者，我这么说）。
你可能需要自己尝试一下。“点赞”会被用于多种统计，可以查看 /admin/site_settings/category/all_results?filter=like。如果 10,000 个人点赞了 50 个内容，那这 50 个内容肯定会变得热门。如果目前这不成问题，那么也许无限点赞是可以接受的。
此外，这可能会影响用户如何保持在 TL3 级别，但对于这样一个规模的群体来说，那可能是一组独立的问题。
我们保留各自意见（似乎对各种含义具有包容性）。但这也许是一个解释清楚的问题，并修改相关文本；也许人们更在意的是描述方式，而不是实际运作方式（除了那 10,000 个未“点赞”的囚徒）。
是啊，确实如此。
从我看到的情况来看，这确实不是问题。这是我们每日的点赞报告：
| 2020 年 4 月 1 日 | 15079 |
|---|---|
| 2020 年 4 月 2 日 | 14059 |
| 2020 年 4 月 3 日 | 11591 |
| 2020 年 4 月 4 日 | 10774 |
| 2020 年 4 月 5 日 | 10388 |
| 2020 年 4 月 6 日 | 10101 |
| 2020 年 4 月 7 日 | 12637 |
| 2020 年 4 月 8 日 | 11253 |
| 2020 年 4 月 9 日 | 12596 |
| 2020 年 4 月 10 日 | 9991 |
| 2020 年 4 月 11 日 | 9515 |
| 2020 年 4 月 12 日 | 8996 |
| 2020 年 4 月 13 日 | 12427 |
| 2020 年 4 月 14 日 | 11605 |
| 2020 年 4 月 15 日 | 13795 |
| 2020 年 4 月 16 日 | 16213 |
| 2020 年 4 月 17 日 | 12662 |
| 2020 年 4 月 18 日 | 12566 |
| 2020 年 4 月 19 日 | 11272 |
| 2020 年 4 月 20 日 | 13804 |
| 2020 年 4 月 21 日 | 15423 |
| 2020 年 4 月 22 日 | 13840 |
| 2020 年 4 月 23 日 | 14696 |
| 2020 年 4 月 24 日 | 12972 |
| 2020 年 4 月 25 日 | 12834 |
| 2020 年 4 月 26 日 | 11395 |
| 2020 年 4 月 27 日 | 11871 |
| 样本总计 | |
| — | 33.4 万 |
我们确实对 TL3 的权限进行了一些调整。有些功能，比如帖子编辑，已经转到了 TL2。我们本可以关闭 TL3 的编辑权限，因为无法区分 TL4（按我们目前的设置，我们希望TL4 能编辑而 TL3 不能，但目前还做不到）。我们甚至不鼓励版主编辑内容；我们更倾向于让他们提出修改或删除建议。
从管理角度来看，我并不在乎某人有多少点赞，所以默认设置对我们来说完全没问题。
从我看到的情况来看，问题更多是功能性的，而不是解释性的。他们想点赞更多内容，却做不到，因此感到恼火，并期望能够点赞更多内容。他们不理解限制背后的理由，所以觉得这是不必要的规定。甚至有人以“点赞用光”为荣；我们为此还设置了一个徽章（我很想自动化这个功能，但那是另一个话题了）。
我觉得我们的“牢鸟”们会对拥有无限点赞感到高兴。将限制留空是否意味着设置为无限？我们可能会尝试一下，看看会发生什么。如果导致系统混乱，那我们可以重新启用限制。
你还可以做的另一件事是，将所有信任等级 2 及以上的用户的每日点赞倍率提升至 8 倍左右——这样用户刚加入时，每天获得的点赞数等于基础数值；而一旦他们连续登录两周，上限就会大幅提升。
其他论坛曾抱怨点赞重置的“悬崖式”机制，因为重置必须按照服务器时区而非用户本地时区进行，这使得关于“一天”何时开始和结束的争论更加激烈。
一个准确的认知模型是将其视为一款手机点击类游戏：每次点赞消耗一个“点”，每个“点”都有独立的 24 小时计时器，计时结束后自动刷新。
我从未意识到倍数的作用是这样的。如果不阅读字段说明文字，并且考虑到它靠近“热度”设置，我原本以为它只是将每个信任等级的单个点赞按该倍数进行加权。原来如此。
你明白 TL3 只能编辑标题、分类和标签吧？而且 TL4 不是自动的？（不过这点在这里并不重要）
所以听起来似乎没有理由不把这个数字设得任意大。
默认就有一些这样的徽章……不过我想你早就知道了。
啊哈！我还以为它（曾经）是这么运行的。我只是漏看了通知。
没错，“Higher Love”徽章在 NaNoWriMo 论坛上已经授予了125人：https://forums.nanowrimo.org/badges/34/higher-love
当您连续 5 天每天用完全部 500 个点赞时，即可获得此徽章。感谢您每天花时间积极鼓励最精彩的对话！
这 125 人，每个人都曾五次踏入你们社区亲切称为“点赞牢笼”（Like Jail）的地方。
如果这个数字被提得非常高（实际上近乎无限，如果不是无限的话），那么这个徽章可能就无法再生效了，对吧？因为大家就永远无法达到每日上限了？或许需要推出新的徽章了。
是的。 我们使用 TL4 这一头衔来指代我们的本地志愿者，他们是签约合作的。社区整体上对于让他人重新分类他们的帖子感到非常不自在。我们的社区文化并非如此运作。我希望能单独为 TL4 开放此权限，以便他们更有效地管理本地分类，但我们已经建立了一些不错的工作流程，所以这并不会造成太大负担。
是的，这会是他们感到遗憾的一点。我也希望能有类似的功能。不过，与允许他们点赞内容相比，这一点没那么重要。
嗯，Higher Love 是像描述中那样硬编码为 500，还是实际最大值会根据设置而变化？
看起来它正在从设置中获取实际的最大值，但_有意忽略了乘数_。
它实际上已经算是某种程度的自动化了（好吧，曾经是）。我写了一个脚本，用于检查自脚本上次运行以来在该帖子中发布内容的用户是否获得了“出于爱”徽章，并在符合条件的情况下通过 API 自动授予该徽章。
这其实是我一直想发帖讨论的内容，因为它经常与“点赞数耗尽”这一主题相关。许多 NaNo 用户收到了关于已用尽限额的提示，但却从未获得相关的徽章。
据我所知，徽章的刷新时间似乎是服务器时间的午夜，但每日限额实际上是一个滚动24小时窗口。
这就是实际行为。它基于 UTC 时区。这已经是当前的工作方式。
这与我在 NaNo 论坛上的体验，以及其他用户的反馈并不一致。
多位用户遇到了类似情况：他们使用点赞功能后，系统会提示需要等待一定时间。在这种情况下，他们有时能成功给一篇帖子点赞，但尝试给第二篇点赞时，会再次触发等待提示。通常他们能在等待提示再次出现前完成几次点赞。唯一能稳定获得全部点赞次数的方法，是等待 24 小时以上。
我本人在开发环境中也观察到过这种现象，但最初我将其归因于自己使用 API 为开发环境填充内容时触发了某种速率限制。
您指的是两个不同的概念——垃圾邮件速率限制器（快速点击按钮）和每日限制。
抱歉，我本该解释得更清楚些。我用来填充开发环境的脚本在我以为触碰到速率限制之后被重写了。
该脚本被特意重写，以 避免 尽可能快地点赞。它最初仅在 2 小时内点赞 5 篇帖子（这是我为了便于测试而设置的每日限制）。其余的测试完全通过我的浏览器以人工方式进行。
我还想补充一点，我在不同的 Digital Ocean 主机上运行多个脚本副本，每个副本都使用为相应账户生成的独立管理员 API 密钥。这样做的目的是尽可能模拟真实流量。因此，理论上如果确实触碰到垃圾内容限制，那必然是基于除 IP 或用户账户之外的其他因素。
我并非要否认部分 NaNo 用户确实触碰到垃圾内容限制。其中一些人确实很喜欢点赞。
每日限制使用的是与我们的垃圾邮件速率限制器相同的代码（RateLimiter.new）。
我不太喜欢这个话题，因为它 perpetuates 一个误解——点赞数确实会在每天 UTC 00:00 重置。