本文作者只是一个人类劳工，罪魁祸首和始作俑者是@野人 和@觀察者 Denken 😁。多谢@觀察者 Denken港币打赏和纠正，婉谢其他港币usdt打赏。

 @觀察者 Denken 在@野人 的热门文章閒聊我辦活動不申請官方基金的原因下提供据说是马特市热门排名算法源代码页面，并展开热烈讨论请求白話文演算，记得你俩欠我一个人情哦😉！

既然有代码，为了避免非专业人员盲人摸马🐎给官方名誉造成无辜损伤😭，劳工只能准备好“马热汤”的钛合金锅盖，迎风而上。

风险提示及免责说明：劳工只是按代码索骥🐎，如有错误，请告知，会立即修正。官方若要追责，请向上转弯找以上二人。

个人还是很欣赏❤️马特市能将排名代码透明公示的👍，因为这些服务端的代码完全可以在数据库中隐藏实现。

没空、没兴趣不想看细节的可以拉到最后看“***观察”，😁。源代码链接见上，文章内只会重复小部分代码并加注。

/*常数定义*/
const time_window = 3  /*时间窗口，以天计，因为后面会*24小时*3600秒*/
const donation_decay_factor = 0.5 /*普通用户赞赏衰减指数 donation翻译成赞赏*/
const matty_donation_decay_factor = 0.95 /*matty官方用户赞赏衰减指数,貌似好处只是接近2倍，😄但是学过数学指数的看到后面就知道了*/
const boost = 1 /*新鲜度加权 设置为1，实质没有加权*/
const boost_window = 3 /*加权窗口，以小时计，因为后面会*3600秒*/
const circle_boost = 2 /*进围炉加权，2倍，官方可以在article_circle表中加入一系列的文章，如果文章进入官方认定的围炉circle,并且距离发布不超过24小时,那么其阅读效率将获得2倍加权，名义上2倍，后面可以看到实际权重4倍 */

第一段代码（见下）和单个文章的得分没有关系，因为它的作用是计算“过去3天最高阅读效率”max_efficiency,它代表了最近3天(time_window)内所有文章中最高的阅读效率。后续在计算donation_score赞赏得分时,使用这个max_efficiency来进行标准化。

create view ${view} as  
with original_score as (      ...     
) t  
)

下面的代码是用来计算文章得分score的主体逻辑：

select article.id, article.title, article.created_at, 'https://matters.news/@-/-' || article.media_hash as link, coalesce(t.score, 0) as score  from article  
left join  (      
     select...
) t on article.id = t.id
where article.state = 'active'  
order by score desc, created_at desc;

首先建立统计文章的三个临时数据表:

1.  t1: 计算时间窗口期(目前设置为3天)内每篇文章的基础得分”加权阅读效率“read_time_efficiency_boost
2.  t2: 非matty普通用户大额赞赏得分，获取非matty普通用户的最后一笔大额赞赏时间和普通用户的大额赞赏总次数（注意：只有5港币或0.5USDT及以上才算数，😭）。
3. t3: matty用户赞赏得分，获取matty用户的最后一笔赞赏时间，任何形式都可以 😄
4. 被投诉关小黑屋的文章都不算（拜托请不要投诉我的文章关小黑屋，我这绝对算是“为市民服务”吧，😂）

先做1计算文章的基础得分加权阅读效率read_time_efficiency_boost：

select max(read_time_efficiency_boost) 是从 case 语句中的 3 个计算方式中选择最大的值。
case 语句中有 3 种计算阅读效率的方式:
如果发布时间在 boost_window(3小时)内,阅读效率 = boost(1倍) * (阅读时间/时间跨度)^0.5
如果属于某个circle并在24小时内,阅读效率 = circle_boost(2倍) * (阅读时间/时间跨度)^0.5
其他情况,阅读效率 = (阅读时间/时间跨度)^0.5
select max(read_time_efficiency_boost)会从这3种计算方式得到的阅读效率中选择最大的一个,作为文章的最终阅读效率。

然后从2和3计算文章的两种赞赏得分donation_score：非Matty普通用户大额赞赏得分和Matty用户赞赏得分：

(select max_efficiency from original_score)*coalesce((${donation_decay_factor}^coalesce(t2.count_normal_transaction, 1))^(extract(epoch from now()-t2.latest_transaction)/3600) ::numeric(6,0), 0),

非Matty普通用户赞赏得分= max_efficiency*非Matty衰减系数；非Matty衰减系数=非Matty普通用户基础衰减系数donation_decay_factor 0.5^普通用户在3天内更高的大额赞赏次数^最近大额赞赏时长（注：^是指数计算）

这里的逻辑有些奇怪：普通用户在3天内更高的大额赞赏次数和更久远的最近大额赞赏意味着更快的热度衰减。更久远的最近大额赞赏意味着更快的热度衰减这个可以理解。普通用户在3天内多次打赏5HKD或0.5USDT有弊无益（反炒作？）

(select max_efficiency from original_score)*coalesce(${matty_donation_decay_factor}^(extract(epoch from now()-t3.latest_transaction_matty)/3600) ::numeric(6,0), 0)

Matty用户赞赏得分= max_efficiency*Matty衰减系数；Matty衰减系数=Matty用户基础衰减系数matty_donation_decay_factor 0.95^最近matty赞赏时长

文章的赞赏得分donation_score为非Matty普通用户大额赞赏得分和Matty用户赞赏得分的二者取大。

最终的文章得分score总得分=文章的基础得分read_time_efficiency_boost+文章的赞赏得分donation_score

最后，热门文章score总得分倒序排列，score高的热门排名在前。Score同等的情况下，更新的文章在前。

个人觉得这里的代码只是服务端得分排序主代码，猜测应该还有其他的代码，比如说多长时间刷新调用服务端一次，前端是否过一阵子会轮流排序前多少位等等。。。个人猜测，错误勿怪

***

下面是我用Excel做了一些小模拟，一些简单的观察如下：

1. 文章进“围炉”的实际权重是4倍（因为不加权之前的阅效被0,5倍衰减=2倍增长），也就是说，其他条件同等的情况下，非“炉”内文章要有炉内文章4倍的阅读时长才有相同的基础得分“加权阅读效率”。疑问见评论。

2. 非matty普通用户赞赏只有大于等于5HKD和0.5USDT大额赞赏才计入得分，而且3天内收到多笔大额赞赏对热门排名有反作用！

3. matty用户赞赏得分相比非matty普通用户得分赞赏衰减慢很多，也就是说matty用户赞赏的抗衰老保质期很长很长很长。。。而且文章越老优势越明显（神效😭👍）也因为赞赏得分的衰减是从打赏时间开始算，而不是文章发布的时间开始算。当然从代码里看，必须在最近3天内发布的文章才会算赞赏得分。（但是有点奇怪🤔️，今天在热门列表里看到一个4月20日和4月22日的文章超过今天的新文，从代码的角度，貌似根本就不应该被计入。这里可能需要疑问，@觀察者 Denken 君给出的代码页面里是否是生产环境里应用的代码了，或者是分布式数据存储没有同步一致😁)

4. 赞赏得分和一个与文章基本毫无关系的“过去3天最高阅读效率”有关，嗯，如果过去3天内哪篇文章爆红了，比如说@野人 的大热文（阅读时长和人民币对美元汇率一样直奔7而去），😁，没有大额赞赏和matty用户赞赏的新文章就莫名其妙遭了“池鱼之殃”，因为受“matty用户赞赏”的老文章、老老文章的赞赏得分有可能要足足等野人的大热文3天热度寿终正寝才消成0(这里只是打比方开个玩笑，实际中的数字是实时变化的，基本上野人的文章再红也红不了多久😄）。

所以说，根据以上算法，这俩天的大部分普通新文不能上热门的话，你们要打的很可能正是为“普通新文没热度”鸣不平的 @野人 ，😄，很ironic吧，谁叫他怎么那么红🍠呢？！

再次免责声明：劳工只是按代码索骥，如有错误，请告知，会立即修正。

在这个算法下，想要超过“受matty用户赞赏加持的炉内文章（发布3天内基本永垂热门不朽）”的普通新文，嗯，确实好难啊😭😭😭

@野人 君记得如果要帮本篇文章上热门的话，不要再抖5HKD了(估计你肯定不会用usdt)！而且要公示让其他热心市民不要再多抖港币或usdt了（likecoin没关系)，😄，因为本篇文章估计可能肯定没机会被matty赞赏的了，😂。

至于如何增加阅读时长的秘诀，劳工也是有自己的猜测（不难）😉，光字多文长点进拍手率高估计是不够的，😁，但是没有代码，就不分享凭空猜测的秘诀了。

目前的AI模型在编程代码分析上用处有限，不是没有帮助，可以起提示总结作用，但是细节上错误很多，特别是Claude和gpt3.5，数学能力不高，错误很多，甚至是简单的小学生常识性错误。gpt4好很多，但是也还不能充分信任。但这个会是未来AI模型性能提升的主方向之一，耐心等待就好，不会太久。