互联网时代的“评”水相逢：评论功能的调研与

小提示：您能找到这篇{互联网时代的“评”水相逢：评论功能的调研与}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的互联网时代的“评”水相逢：评论功能的调研与内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

本文作者通过详细梳理市面上常用的评论模式，分析不同设计模式背后的产品逻辑及规律，以及设计中可能会遇到的细节问题，期望能够给看到这篇文章的人有不一样的感触。

社区产品中，评论作为最基础的功能，扮演着连接生产者与消费者的角色，同时，也是众多社区产品吸引用户的利器之一。而在一些产品中，评论甚至比原内容会更加有趣，“内容决定平台的下限，评论决定平台的上限”，今天，就以产品的角度去看看评论功能设计的要点。

下面的内容，我会通过详细梳理市面上常用的评论模式，分析不同设计模式背后的产品逻辑及规律，以及设计中可能会遇到的细节问题，期望能够给看到这篇文章的人有不一样的感触。

一、评论的设计模式

在开始详细的分析之前，先介绍两个名词，助于大家更好地理解下面的内容：

• 评论一级页面：从内容的评论入口点击进入（或展开）的页面，如下左图。
• 评论二级页面：从单条评论进入（或展开）的新页面，如下右图。

模式1：平铺式设计

评论内容，评论的回复等都在一个层级页面，无二级页面。比较常见的是微信公众号的评论，朋友圈的评论，以及抖音的评论平铺式设计。

在这里有一个有趣的问题是，为什么微信公众号的评论，其他用户不能回复？仅作者回复？

我思考有这样几个点：

1. 研发成本低，但这一点对于微信来说，很显然不重要。
2. 回到评论本身来讲，微信公众号本身是以作者内容为重点，区别于网易新闻等新闻媒体的内容，微信的考虑应该是不希望用户在评论区域有太多的交互而影响本身内容的阅读。
3. 微信公众号的评论管理相对严格，除有好友关系的评论可以不需要经过审核直接上线，非好友关系的评论都需要作者审核后方可上线。这种设计也是微信公众号不想内容被评论喧宾夺主的一种做法。

模式2：主题式设计（树形分支结构设计）

将单个评论作为一个主体，一般仅展示部分对话，折叠剩余内容。这种设计的实质是将单个评论看做一个可以互动的子模块，更能聚焦地区讨论内容。目前比较常见地应用在微博、小红书、贴吧、简书上。

哪些产品适合主题式设计？主题式设计有哪些优缺点呢？

首先，针对优势，我的思考是这样：

1. 主题式设计适用于内容量较大，用户基数较多的产品阶段。
2. 主题式设计，顾名思义，所有用户都可以围绕一个评论参与互动，延伸内容本身的价值和趣味，吸引更多用户参与。
3. 运营也可将主题式评论当做运营工具，吸引用户参与互动。

但是，主题式设计也有一些问题，针对缺点，我的思考是这样：

1. 研发成本上，相较于模式1平铺式设计要大。因此在产品的初期阶段，不建议使用主题式设计。
2. 主题式设计，用户会为了更多曝光，直接回复热门评论，容易造成灌水、低质的问题，如果反作弊策略跟不上，相反会稀释产品调性。

模式3：盖楼式设计

17年3月25日，南方周末发表文章《刺死辱母者》，引起了网易编辑们的关注，网易新闻小编将原标题修改为《母子欠薪遭11人凌辱，儿子目睹后刺死1人被判无期》，并发送全量push，7h内该文章跟帖数100w，3.26日，达到236w。这就是要介绍的第三种模式，也是网易新闻的特色之一盖楼式设计。

顾名思义，盖楼式设计，是指将自己的评论与原有的所有评论都展现出来，并按照顺序展现，如下图。

盖楼式设计的特点是将所有对话全部展现出来，视觉冲击力强。网易新闻借此甚至发展出了『更贴文化』，并将其发挥到极致。但盖楼式设计也需要考虑重复内容以及视觉疲劳的问题，在人们注意力时间越来越低的现在，很少有产品会采用盖楼式设计（此观点来自于使用140+app，发现只有网易新闻与A站使用该种设计，观点仅供参考）。

二、评论的排序逻辑

目前，成熟产品的评论排序方式都是综合时间、热度等因素而组成的评论排序列表。相对主流的排序方式也主要依靠这样几个逻辑：时间顺序，热度排序，人工置顶。

逻辑1：时间顺序排列

现在，按照单一的时间顺序排列的产品相对较少，一般在产品的中间版本会采用这种相对简单的排序方式。时间顺序排列需要注意的是，在一级评论列表页和二级评论列表页顺序的不同。

一级评论列表页，最新评论在最前，这一排序逻辑是能被大众所接受的。但二级评论列表页的排序顺序依然是最新在最前吗？

我的思考：不是。我们回到二级评论的场景中去，试想，我们在点击进入一个二级评论，我们想看到的时候针对这个评论所产生的讨论，此时这个评论的回复其实是有故事线在，因此，二级评论列表页按照最久评论在最新展示是相对合理。

以微博为例：微博的二级评论默认按照时间顺序，最久在最前的展示顺序。当然，微博也提供了按照热度排序供用户选择，这一逻辑我们在后面详细为大家介绍，什么是按照热度排序。

逻辑2：热度顺序排列

不同产品对于热度的定义是不一样，一般都离不开这样两大类：

（1）单一热度参考因素：即以某一因素作为排序依据，常见的是评论的点赞数、评论回复数。

（2）复杂热度参考因素：即以综合因素为依据，根据算法而生成的排序依据，常见的因素分为以下几大类：

1. 评论本身：评论时间、评论字数、评论与内容的相关度。
2. 评论者本身：内容数、粉丝数、关注数、是否大v、是否低质、与作者的关注关系、活跃时间等。
3. 评论互动指数：评论点赞书、评论点踩数、评论回复数。

针对第（1）类：单一热度参考因素。以网易云音乐ios版本举例：在4.3.0版本以前，评论分为两个板块：精彩评论、最新评论。其中，精彩评论的排序依据是点赞数，最新评论的排序依据是时间。当评论数大于10后，该内容即可进入精彩评论板块。（如下为分析来源）

网易云音乐针对评论的排序方式相对简单，容易让用户理解，能够被普通用户所接受。但是，这种排序方式会受到马太效应的影响，强者越强，弱者越弱，在一定程度上会伤害评论者的积极性。

为了解决这个问题，网易云音乐在4.3.0版本上线了近期热评板块。部分评论数较高的歌曲会有近期热评板块，例如：周杰伦的《晴天》，总计211w条评论，热门评论21437条，近期热评2条。

通过分析网易云音乐，我们发现：以单一纬度为排序方式的排序逻辑，优点明显：简单直接，用户接受度高。缺点同样明显：马太效应，会伤害后来者的评论积极性。

基于此，市面上出现了相对复杂的评论排序方式，综合评论的各种因素的排序方式，国内的今日头条，国外的Reddit都是采用的这种复杂的排序方式，在这里，具体的排序方式是什么，我们不做重点。

重点聊一聊，为什么评论要用复杂的方式来排序，即复杂的排序方式解决了什么问题？

我的思考是：

1. 发表早的内容不一定是好的内容的问题。
2. 同样质量的内容可以获得同样的曝光机会，只要内容质量高，后来者也可以居上。
3. 发现真正被用户喜欢的评论。

逻辑3：人工置顶评论

人工置顶评论，本质就是通过人工干预评论的排序，达到操作者目的的一种排序方式。在这里操作者其实有两类：一类是发布内容的作者，一类是平台的运营人员。

例如：微信公众号的置顶评论，实质上是发布内容的作者置顶用户的评论。这一类置顶，产品会给予明显地标识。对于浏览用户和评论者都是明显可见的。

另外一类置顶，平台的运营人员通过后台等方式置顶符合平台调性的优质内容，这一类置顶，浏览用户往往是无意识的，而评论者往往能够感知到自己的内容被置顶，对于评论者也是一种激励。

三、评论的主要操作及细节须知

产品的发展是阶段性的，当我们做一个从0到1的产品时，我们需要去拆解评论功能，即每一个版本需要完成到什么地步、达到什么目的。

过往的经验告诉我，拆解的前提是知全局，以免出现拆解不全面、优先级颠倒等问题。知全局一个很好的方法就是去参考成熟的产品，下面，我将以一个成熟产品——微博的评论区为例，去分析评论还有哪些主要需要注意。

Part1：用户信息展示及输入区域需要考虑要点

1. 用户头像：头像大小、头像展示形状、头像是否可以点击、头像点击进入页面的交互逻辑。
2. 用户昵称：昵称颜色、昵称展示字符数、昵称是否可点击、昵称点击后进入页面的交互逻辑、是否可关注用户。
3. 用户等级展示：展示样式、展示位置、是否可点击、用户等级是否参与干预评论的排序规则。
4. 输入区域：调起输入框是否有默认文案、输入字符数限制、输入内容类型（文字、原生表情、自制表情、链接、图片、视频、gif、live、长图）、内容类型对应字体颜色、形状大小；调起键盘默认展示样式，是否支持换行提交、是否支持键盘提交；输入评论成功后，被评论人是否收到系统消息；输入评论成功后，评论人是否有固定入口可见评论。

Part2：评论的部分操作考虑要点

• 转发：转发的按钮大小、颜色、位置；转发平台（站内转发/第三方平台转发）；分享文案；分享类型（jpg/url）；分享落地页样式。
• 回复评论：回复评论样式；调起输入框是否有默认文案；输入字符数限制；输入内容类型（文字、原生表情、自制表情、链接、图片、视频、gif、live、长图）；内容类型对应字体颜色，形状大小；调起键盘默认展示样式；是否支持换行提交；是否支持键盘提交；回复评论成功后，被回复人是否收到系统消息；回复内容成功后，回复人是否有固定入口可见回复。
• 点赞：点赞动效；是否可以取消点赞；点赞的同步逻辑；点赞是否发送系统消息；点赞数的展示规则；点赞数是是否干预排序逻辑；（如有点踩）与点踩的互斥/独立关系。
• 点踩（部分产品存在）：点踩动效；是否可以取消点踩；点踩的同步逻辑；点踩是否发送系统消息；点踩数的展示规则；点踩数是是否干预排序逻辑；与点赞的互斥/独立关系。

Part3：评论的部分操作考虑要点

1. 复制：复制成功提示；复制失败提示；复制区域（全部复制/选择复制）；复制交互（长按/点击）。
2. 举报：举报客体区别（举报的是人还是内容）；举报页面；举报是否发送系统消息；举报后续处理逻辑。
3. 删除： 是否可以删除；删除是否弹窗dialog；被动删除后是否发送系统消息；删除后数据展示样式。

以上三个部分就是针对评论的操作所需要考虑的细节要点，因为认知局限，可能不完整，欢迎补充。

四、评论运营后台

好的明星需要团队运营，好的电影需要团队运营，那么好的评论更需要团队去运营。网易云音乐的评论不是PM搭建好评论功能，就会有众多UGC源源不断地来产出内小程序可以容，是需要有一个强大的运营团队来管理和控制评论。

用户从看到评论到发布评论这个环节，PM扮演的角色实质是建立更简单、更适合产品的评论通路，而运营才是去引导用户评论的关键因素。

如果说把评论功能比喻成一个冰山，那么在前面三部分聊到的都是冰山之上的内容，下面要聊到的才是冰山之下，用户弱感知，但又非常重要的一部分——评论运营后台。

首先，先认识整体——针对评论后台，运营一般可以进行哪些操作：

（1）置顶：运营可在后台置顶符合产品调性及社区氛围的评论。此时PM需要考虑这样几个问题：

1. 置顶是都可以撤销以及置顶与消息系统的联动；
2. 置顶评论是简单粗暴的直接置顶，还是通过机器增加点赞数，浏览用户无感知的置顶；
3. 增加点赞数时一般也要考虑按照时间顺序线性增加的方案，这样才能更加真实。

（2）精选：精选的用法常见于新闻媒体，小编会给某些精华评论加上精选的标识。一方面，激励评论的生产者，另外一方面，也能树立社区的评论标杆。

此时PM需要考虑这样几个问题：

1. 精选评论是否可以撤销及精选与系统消息的联动；
2. 精选评论前端展示样式。

（3）删除：针对黄反暴等内容，评论后台可直接删除内容，此时PM需要考虑的问题：

1. 评论被删除是否同步给用户；
2. 评论被删除后评论数是否同步增减。

（4）添加：此处是指针对内容，运营可以添加新评论，此时PM需要考虑的问题：

1. 哪些内容被优先添加评论，我思考的优先级是新用户的首条内容>新内容>热门内容。优先级不一样，PM在拆解评论运营后台的方式也不一样。
2. 马甲号：在很多社区平台都会通过造假评论来留住用户，但往往很多平台造的马甲账号过于『假』，之前看厂内的一个产品，点赞的马甲号名称一律数字，点击进入个人中心，关注数大多数是10000，且无其他互动数据，这种过于『假』的账号对真实用户来说不一定是一种好的方式。大家如果玩儿抖音也会发现抖音的马甲号，你发布的作品在2分钟之前收到一个用户的喜欢，这个时候你点击这个用户的个人中心喜欢的作品，发现喜欢的作品数大多超过千级别，且你在他的喜欢列表中找不到自己的作品，这类账号也属于马甲号。

如何造一个和真实的人一样的马甲账号？

我觉得分为这样几步：

• 首先确定产品中用户可以感知到因素，以抖音为例：用户可以感知到因素有：消息系统、头像、昵称、抖音号、签名、互动数据及列表（获赞、关注、粉丝）、作品数、喜欢数。然后找研发随机跑出1000个用户（具体数据自己确定即可，但需要有参考价值），标注以上数据后得出真实用户的区间值。
• 最后，确定各个数据qq群发邮件营销有用吗的区间值就可以开始愉快的『造人』了。在这里，还需要关注一个事情叫做，研发成本。因此PM在拆解马甲号时，也需要拆解出优先级，优先完成哪些。

添加评论的时间：如果每次可以给一条内容添加n条评论，那么评论的时间应该如何展示才会更加真实。

（5）修改：修改用户的评论，此种操作一般不建议使用。

（6）封禁：封禁标准；解封标准。

上述六个操作是评论运营后台常见的操作，有过从0到1做产品的人都知道，研发人力永远不够，需求永远会砍。因此，在产品初期，很少会投入太多人力搭建评论运营后台，此时PM的职责就是去拆解评论运营后台，并按照节奏去推动后台每一个功能的细化和实现。

在运营的评论后台这个部分，我想最后聊一个和运营相关的问题，即社区中评论是否需要审核？以及评论的审核方式是先审后发，还是先发后审？

首先是第一个问题：社区中的评论是否需要审核。

要！一定需要审核，一方面是控制垃圾消息。以我经历过的产品来讲，评论如果不审核，单纯的依靠反spam策略是不可控的，我记得之前在百度派，有段时间我们的评论完全被作弊消息所覆盖，PM的人力完全去处理垃圾评论，最终紧急上线了评论后台才控制住垃圾消息。

另外一方面，在审核的过程中，运营可以去把控社区氛围的导向，对于社区范围而言是一件好事。

然后是第二个问题：评论的审核方式是先审后发，还是先发后审？

评论直接上线和评论需要审核后才能上线，这二者最本质的区别是平台对于评论重要程度的判断。在社区产品中，评论扮演着非常重要的角色，但随着产品的不断发展，日评论数量不断提升的条件下，评论方式也应该随之变化。

在产品初期，如果评论量相对较少的情况下（日提交数百级别），其实PM完全可以不用去浪费自己和研发的人力去建立/对接反spam系统，直接让运营先审后发。但评论量相对较大的情况后（日提交千级、万级），此时可以考虑对接反spam策略，此时，反spam策略扮演的角色是过滤黄反消息，降低运营的处理成本。

在产品发展到一定阶段，日评论提交量在十万级别的时候。此时，说明平台已经建立了一定的社区氛围，我们可以判断大多数用户非spam用户。此时，运营的审核压力变大，小时处理审核量也会增加，如果继续先审后发，可能会造成部分热点内容跟进不及时等问题。

因此，先发后申是比较适合这个阶段的方式。同时，PM也需要不断地去磨合升级反spam策略，一旦有垃圾消息后一定要迅速处理。以免影响整体的社区氛围。

五、结语

当我去看今天写的有关评论的内容，我突然想到我刚开始做PM的时候，leader问我，点赞功能简单吗？

我说简单。

现在，在踩了无数次坑之后，我逐渐意识到产品没有简单一说，完全看自己投入多少去钻研，去学习。也希望今天看到这篇文章的人，能够不断地思考，一个小小的功能如何做出大大的不同。

本文由 @刘君 于。，

题图来自 Pixabay，基于 CC0 协议