企业官网建设流程全解析

1. 项目概述与背景

1.1 核心需求解析

先说结论：做外卖点评系统，最难的不是写代码，而是搞清楚一个平台到底需不需要一套完整的UGC评价体系，以及需要什么样的评价体系。

我当时接到的需求是一个外卖平台要做点评模块。这个平台本身有外卖、团购、到店三块业务，点评数据是打通三个业务最重要的用户资产。用户在外卖下单后可以评价菜品和配送，在到店消费后可以评价服务和环境，系统需要沉淀这些内容并且通过对内容的分析反哺搜索推荐。

先说这个系统解决了什么问题。评价对用户是决策参考，对商家是口碑回馈，对平台是流量分发和商品质量分的重要输入。外卖场景下的点评和餐厅点评最大的区别是评价对象颗粒度更细，直接精确到单个菜品，而不是整家店。用户说一个菜品好吃，那个菜品的销量权重会涨，说某个出餐慢，店家的出餐时效分会被压低。评价数据和搜索结果、推荐流强耦合，才是一个能跑通的外卖点评系统。

这个项目适合谁来参考，两类人。一类是做外卖或本地生活类产品后端开发的工程师，你们最缺的是评价如何拆表、如何做风控、如何接入推荐的实战细节。另一类是产品经理或者独立开发者，你们需要一个足够轻量又能验证业务闭环的点评模块设计思路，把每个功能点的取舍搞清楚，避免做出一堆没有数据价值的表结构。

1.2 整体技术路线选择

我梳理需求时先定了几条原则，不改变主流程，点评数据保持独立域，所有业务通过事件驱动去消费点评结果。

技术选型上，基于团队已有的技术栈，用Java微服务承载点评域，独立部署一个点评服务。数据库选MySQL存储评价订单、评价内容、追加评价和回复记录。说明一下为什么不用MongoDB，虽然评价内容的字段是典型的有结构的长文本，但评价数据高度关联用户、订单、商家，需要大量关联查询和离线聚合，MySQL在这套场景下更稳，加上公司在用的数据库主从和分库分表工具链已经成熟，运维成本低。

热点内容用Redis存，一个Key存储某个菜品的新鲜评价列表和热门评价列表，还有商家的综合评分字段。搜索推荐相关的评价衍生物，比如关键词权重、情感分析结果，通过MQ异步推到搜索引擎和推荐服务。

我重点说一下这里的架构取舍。外卖点评系统最容易犯的一个错误是试图把评价数据直接塞进已有的订单系统或者用户系统。我当时跟同事花了很多时间讨论要不要独立出一个点评服务，有人觉得就一个评价表，挂在订单库下面就行。但外卖域的数据量很大，评价很容易就是上亿级的表，混在主订单库里面会严重影响主链路的稳定性。评价数据的读写特点是高频率分散写入，低频率但大范围的聚合读取，跟订单的强一致要求完全不一样。点评单独拆域，底层再通过数据同步给数仓做统计，后面接入推荐系统时才没被订单表耦合拖累。

2. 外卖点评系统的核心模块拆解

2.1 评分体系的建模逻辑

评分系统是评价域的核心，直接决定后续所有数据产品的质量。

外卖点评的评分体系我按照评分对象和评分维度拆成两层。评分对象层有三个对象：商家、菜品、配送。商家评分是店铺的综合口碑，菜品评分是具体某一道菜的得分，配送评分是骑手送货体验的得分，三者独立维护但对外展示时需要加权合成一个综合分。

评分维度层，外卖和到店有差异。到店评价侧重环境、服务、口味，外卖评价侧重口味、包装、配送时效，这几个维度在设计评价表单时要拆成独立分值。如果只是搞一个5分制总分，商家和算法对用户评价的理解都会很模糊。菜品维度加上"份量是不是足"、"口味是不是对"、'价格是不是匹配'三个细项，组合出菜品标签，后面做推荐召回时直接用标签去匹配用户偏好。

这里我多说一句评分计算的细节。外卖点评系统的评分一定不能是简单求平均，这会很容易被刷分和恶意差评打穿。我当时是用时间衰减的加权贝叶斯平均值，确保只有评论落库时间越近的样本权重越高，还要让新店在没有足够样本时不被极端的几条评分拉爆。

公式可以参照这样的思路：

$score = \frac{a \cdot avg + n \cdot \bar{x}}{a + n}$

其中$a$是环境修正因子，我取的是平台所有门店的平均点评数的0.8倍，$avg$是平台所有门店的平均分，$n$是当前门店有效点评数，$\bar{x}$是当前门店的点评平均分。这样一家只收录了3条评价却全都是5星的店，分数不会直接冲到5.0，会先被平台均值拉到一个更合理的位置，等评价数涨上去以后再逐渐逼近真实水平。

配送评分单独走一套时效模型，核心指标是预计送达时长和实际送达时长的偏差。用户不需要手动打分，系统根据送达偏差、骑手是否提前点击送达、是否有超时投诉来推算配送得分，然后在评价展示页以标签形式显示"配送偏慢 20分钟"。否则你让用户每次点完外卖再评价配送，评价率会掉很厉害。

2.2 评价内容与互动体系

评价内容这块，需要支持文字、图片以及后续考虑的视频。外卖场景下用户拍照的意愿低，图片长尾需求不明显，但图片是商家申诉和平台审核的重要依据，必须保留。文字评价要做长度限制，最低5个字符，否则"不错"、"好吃"这种无效评价会大量涌入。做过内容审核的人都知道，短文本风控难度远高于长文本，因为短语能携带的极端情绪密度更高，定义最短长度是防恶意评价的有效缓冲。

用户在评价菜品时必须选择一个标签，可以选"味道赞"、"分量足"、"食材新鲜"、"太咸了"、"送货快"、"包装精美"等预设标签，也可以自定义标签。这些标签是识别菜品优劣最真实的信号。自定义标签要做敏感词清洗，防止有人利用自定义标签去发广告或违规信息。

追加评价是外卖点评系统里很容易被忽略但价值很高的一个功能。用户在第一次评价后48小时内可以追加一次评价，追加的内容只能发文字和图片，不能再改评分。这个设计的业务用途是识别复购后的体验变化，比如第一次评价说异常好吃，48小时后又追加说吃完拉肚子，这个信号通过数据任务同步到食品安全监控模块，比等用户投诉要快得多。

互动体系要有商家回复和用户点赞。商家回复评价是没有门槛的，商家在商家端App可以直接回复用户的评价，回复支持文字和图片，回复后系统会通过订阅消息通知用户。这个功能直接提升商家在评价域的参与感，也方便商家对差评进行公开解释。用户点赞用的是轻互动，不引入复杂的积分体系，点赞数只作为评价质量排序的参考因子之一。

2.3 审核与风控模块

审核模块是整个点评系统合规的生命线，也是技术方案里最容易被低估的部分。

我当时设计的审核链路是三层：第一层是实时关键词过滤，用户在提交评价时直接拦截命中黑名单的文本，命中直接返回"评价内容包含违禁词"，不落库。第二层是异步内容安全服务，审核文本、图片的色情和暴恐风险，这里的服务必须走平台级的内容安全API，不建议自己训练模型，成本和准确率都不划算。第三层是人工审核池，把前两层都过不掉的、或者被用户举报的异常评价捞出来给审核人员处理。

风控模型那边，主要是做刷评分和恶意差评识别。直接说判断规则，都是可以复用的。

刷单识别场景，系统会检测某个用户是否在1小时内对同一商家连续下了多笔订单，或者某个商家在短时间内的好评比例和评价频率是否远超城市平移值。这些特征是规则引擎能直接捕获的，不需要一开始就上复杂的机器学习模型。针对刷单识别，我当时用了三个维度的规则组合：设备维度（同一个设备ID关联超过5个账号去评价）、行为维度（平均评价耗时小于5秒的评价会被判定为低质评价）、关系维度（评价者与商家的历史订单记录高度重合）。用户端看到的反馈是"评价发布成功"，但这些评价会被折叠，不进入综合评分计算。

恶意差评主要靠两个信号来判断，一是该用户给大量不同商家的评价都集中在一星二星，且评价文本包含大量情绪化词汇，二是评价用户和同行竞争商家存在某种关联。这里不能百分百确认是恶意差评，所以不做自动删除，而是降低这条评价的综合权重，同时推送给商家有申诉的入口。商家可以提交订单截图和出餐记录作为申诉材料，专员审核通过后会把差评从评分计算中剔除，对外保留但是打上"商家申诉成功"标签。

3. 数据库设计与核心表结构

3.1 点评核心表拆分

外卖点评系统的表设计是整个项目里最重要的环节，拆得好，后续扩展和统计分析都会顺很多。我直接给你们看核心的表结构拆解，这是我反复调整后稳定的版本。

第一张表是评价主表。字段包括评价ID、用户ID、商家ID、订单ID、整体评分、评价内容、评价标签、图片内容、匿名状态、审核状态、风控状态、创建时间、删除时间。订单ID要加唯一约束，一个订单只能对应一条主评价，这样才能防止重复评价。整体评分使用tinyint类型存1到5分，MySQL里不需要浮点数，计算综合分靠的是Reduction和Redis缓存层，底层表存原始分就行。

第二张表是菜品评价表，用于存用户对具体菜品的评分和评价。字段包括菜品评价ID、评价ID、菜品ID、菜品评分、口味标签、菜品评价内容。这是外卖点评区别于到店点评的关键表，一个用户一条主评价，可以评价最多5个菜品，每个菜品单独存储评分。推荐系统做菜品召回时，这张表就是最直接的用户偏好数据源。

第三张表是追加评价表，存48小时内追加的文字和图片。追加评价不会创建新的评价ID，而是挂在主评价ID下，用新的评价时间戳。所有老数据不会变动，但用户端展示时把主评价和追加评价放在一个时间线上看。

第四张表是商家回复表，存回复内容、商家ID、运营人员ID、回复时间和被回复的评价ID。同一个评价ID下，商家只能回复一次，但运营可以多次回复，用于平台在严重消费纠纷中做干预。商家回复要独立审核，防止商家在回复里甩锅或者泄露用户隐私信息。

第五张表是举报与申诉表，记录用户举报和商家申诉的全过程。字段有举报类型、举报原因、申诉方类型、申诉材料URL、处理状态、处理结果。这张表是风控模块的数据基础。

3.2 热点数据的缓存与同步方案

数据库只管落库，展示要用缓存。用户进到一个商家页面，需要看到店铺综合评分、近一个月的评价条数、好评率、菜品热度排名，这些直接用Redis缓存，不要直接查MySQL。

Key结构我用的设计方案是这样的：

店铺评分Key存储商家的综合评分和评价数，评分更新时机有两个。一个是在新评价审核通过之后，异步更新。另一个是每15分钟的定时任务，把所有在15分钟内发生部分更新的店铺评分做一次聚合刷新。为什么不每次更新都刷，因为高峰期一个热门店铺一分钟可能涌入几十条评价，每条都更新Redis再同步回MySQL会把服务拖垮。

菜品热点评价列表，用SortedSet存菜品ID，分值取菜品评价的综合加权分，然后按分数截取Top50。这个列表作为菜品推荐香味的直接输入。

评价数据同步到搜索和推荐，用MQ异步通知。消费者收到评价变更事件后，直接把评价文本、菜品标签、评分增量推给搜索索引引擎，再来重新生成该菜品的推荐特征向量。这里不写同步接口，全走异步，即使搜索服务挂了，评价的生成链路也不受影响。

3.3 分库分表与数据归档

评价数据是典型的写入多、读取分散的数据，MySQL单表超过5000万条以后查询性能会明显下降，所以这里必须要做分库分表。

我采用的是按商家ID哈希分库分表，共64个分库，每个分库64张分表，这样总共可以支撑4096张评价分表。为什么按商家而不是用户，因为外卖点评的查询场景大概率是用户进到商家页面看评价，按商家分可以保证同一个商家的所有评价落在同一张分表，翻页查询不跨库。查询当前用户的评价记录是次需求，这种场景通过建立一个用户ID到商家ID的索引表来过渡，不强行用雪花算法生成相同前缀。

数据归档策略主要是针对超过两年、且商家已经下线或关闭的店铺评价，这些数据定时Job通过离线通道迁移到归档库，只保留InnoDB的原始数据做审计。另外对软删除数据单独处理，比如删除的评价在7天内是逻辑删除，7天之后落归档，这样可以给用户一个反悔期，方便处理误操作删除的情况。

4. 两个核心操作链路：评价发布与商家回复

4.1 评价发布的完整时序

我完整走一遍评价发布链路，这条链路走通了你基本就掌握了这个系统的八成后端逻辑。

用户在外卖App的订单详情页点击"去评价"，后端按订单和用户维度做校验，确认这个订单是已完成的且当前用户是下单人，接着确认这个订单没有被评价过。通过校验后返回评价表单模板和当前菜品列表。表单页的数据来源要展示的是订单快照里的菜品信息，不是商家菜单的实时菜品，防止商家改菜单后评价菜品已经下线了。

用户提交评价，后端收到请求后先做基础参数校验，然后过第一层的关键词过滤。这里有个细节，外卖评价领域的关键词库不能是纯干巴巴的敏感词，要叠加很多食品安全的词，像异物、腹泻、头发这类词直接命中后要强制走人工审核优先队列。过了这一层的评价由评价服务落库，返回"发表成功"。

落库后，MQ里投递一条"评价已创建"事件，下游异步处理内容安全审核、评分计算、商家服务分更新、搜索索引更新。这几个动作是异步的，用户感知不到。整个链路响应时间在200毫秒以内，核心耗时都在参数校验和关键词过滤，MySQL写入选型简单。

从用户角度看不到的还有一条链路是实时风控。评价发布后的2分钟内，风控系统需要判断当前评价是否可能触发降权和折叠逻辑。如果是命中，会被标记成风控状态为"折叠"并重算当前商家评分。全部确认完以后，商家端才会收到新评价的推送消息。

4.2 商家回复的操作链路

商家回复评价的链路比用户评价要轻，但涉及到商家端和用户端的状态同步。

商家在商家端App回复评价后，回复内容落库，状态是待审核。回复审核的优先级要低于评价审核，因为回复产生的影响面是点对点的，不像评价影响的是所有人对店铺的感知。审核通过以后，通过WebSocket通道向用户App推送一条"商家回复了你的评价"的提醒，这个推送通道不能在评价主链路里面阻塞，因为商家端回消息的这个动作是高频的，要用独立的推送服务来扛。

商家单条评价只能回复一次，如果回复后评价主体发现被判定为恶意差评并折叠，商家回复也同步折叠。商家对同一用户连续超过5条差评回复，会被评分系统打上"沟通异常"标签，后续评分权重略微降低。这套规则是为了避免商家通过回复去变相骚扰用户。

5. 评价数据的上游应用与下游生态

5.1 对推荐系统的输入

评价数据最值钱的地方在于它可以变成推荐特征的种子。我讲几个实际使用的方法。

第一个是菜品标签召回。菜品评价表里的口味标签，像"微辣"、"偏甜"、"份量足"，被刷成标签ID后进入推荐系统的倒排索引。用户如果历史选过某个菜品的评价标签是"偏甜"，推荐候选集里同样带"偏甜"标签的其他菜品会得到一次加分。这个召回逻辑简单有效，是当季外卖点评应用最重的路径。

第二个是店铺评分的高低排序加权。搜索结果页的店铺排序会根据店铺的综合分做一次平滑加权，评分越高的店铺在同等条件下排名更靠前。这里不能直接按分数倒排，否则所有新店都排不上来，所以用增量加权法，综合分比例占40%，销量占35%，转化率占25%。

第三个是同店差评纠偏。用户在评价某家店铺的某个菜品打1星时，推荐系统会立即触发一次线下规则，把这家店铺的关联菜品的推荐曝光量降低。这个纠偏的幅度每小时衰减，直到评分权重替代这个规则。这个功能是用来防止用户因为一次极端体验受到持续推荐骚扰。

5.2 对商家运营端的价值

商家运营端的数据价值体现在商家后台的三个功能上：评分诊断、评价监控和申诉管理。

评分诊断功能把店铺综合分拆解到维度，商家能看到口味分、包装分、配送分分别是多少，以及与同城同类目商家的差距。这个诊断的意义在于告诉商家到底该改进什么。我之前遇到过很多商户知道自己店铺评分低，但根本不知道是出餐速度问题还是包装问题，维度的拆解可以让商家有明确的方向。已有数据表明单纯因为包装分低了0.2分导致店铺评分掉档的商家，在我做了这个功能以后，优化包装的转化率有明显提升。

评价监控是商家端页面上实时展示新评价列表，并可以设置预警规则。比如一条新的差评出现时，如果该差评命中"食安"类关键词，会直接通过短信和事企App双通道推送警告。这种预警可以让商家第一时间处理食安风险，而不是等用户投诉到平台了才发现。

申诉管理就是前面提到的那个链路，商家提交申诉材料，运营审核。我会额外在申诉管理里加一个数据统计模块，告诉商家被驳回的申诉是因为证据不足还是被判定为假申诉，帮助商家理解平台的审核规则，降低无效申诉比例。

5.3 对平台数据产品的支撑

评价数据演化到数据产品阶段时，能做的事情非常多，但需要从项目初期就预留好数据口径。

我当时维护了一套评价分析的数据看板，按天和按小时维度统计评价总数、评价率、差评率、追评率、文本命中率以及商家回复率。评价率这个指标是我重点看的，计算公式是当期已完成且有评价入口的订单中被评价的订单占比。外卖平台的平均评价率能到15%到20%就算健康，如果低于10%，就要去查是不是评价页挂了或者表单提交出BUG了。

还有一个容易被忽略的指标是评价返现的合规监控差评率。平台为了刺激评价率会做评价返现活动，但返现活动会引来一大批为了拿返现而写低质评价的用户，还会引来盯着返现规则刷评价的羊毛党。在活动设计上我做了最小返现门槛，要求评价内容超过30个字且有有效标签才触发返现，并且把返现评价和自然评价分开统计。

数据辅助比较容易推动的是行业口碑报告。通过聚合餐饮行业各品类门店的综合评分，形成"品品类均价口味榜"、"城市商圈好店榜"这类对外可发布的数据产品。这些都是从评价数据里长出来的业务增长点，我常说点评系统不是作完评价就完了，它就是一台数据引擎。

6. 上线后的常见问题与排查实录

6.1 疑似被批量刷好评的问题

有段时间运营反馈，某商圈十几家店的好评率在三天内暴涨到95%，而且评价内容都是"好吃不错""支持"。我第一反应是查评价请求的IP和设备ID分布，结果发现这些评价集中在凌晨2点到5点，设备ID分散，不能靠设备维度直接封禁。

查完数据发现，这些评价的来源都属于同一个平台渠道的第三方引流活动，商家在外部发券让大家帮忙去店里扫码打分。这不算严格意义上的刷单，但是数据质量是有偏差的，这种评价没有真实的下单消费行为。处理方式是我把评价规则修正成必须正向关联到已完成订单，没有订单关联的评价不允许获得评分权重。当时没有直接改历史数据，因为涉及面太大，只是在新规则下标记这部分评价为"活动评价"，不参与综合分计算。

这里要提醒的是，评价系统做防刷不要一上来就把规则卡的死死的，而是要做数据分层的处置，先降权再冻结，实在违规再删，避免误伤真实用户。

6.2 连续好评也被折叠的问题

上线一个月后接到商家投诉，说某个老客户的连续五星好评被平台折叠了。调查发现风控模型时段差评率引用了模板规则，模板把"短时间内重复好评"误判成了"联合刷单行为"。

问题出在规则里配了一个条件，"同一用户在24小时内对5个不同商家进行好评"。这个规则本意是防羊毛党，但如果用户是在同一天集中解决之前积压的外卖订单，就会出现这种误伤。

我的调整方案是把规则的触发条件改成"同一用户在同一地理位置下，24小时内的评价订单占比超过80%，且评价内容相似度超过0.7才显示违规"。这个规则的上线直接让误折叠率从千分之三降到了万分之零点八。这里最值钱的经验是，所有风控规则在进入正式环境前都应先跑一个回溯实验，用过去90天的历史样本验证规则命中率和误伤率，不要直接上线。

6.3 评分Redis缓存和MySQL数据不一致问题

我这里也踩了一个坑，就是在做评分的热点缓存时，MySQL落库成功，但Redis过期后全量重建的时候，聚合了一部分还没审核完的评价，导致评分偏低，用户端看到评分是跳变的。

排查过程具体是找到了一份评分异常的店铺清单，抽查几个店铺之后，发现问题集中在Redis过期的那一个周期。我复核了定时刷新逻辑，发现在做Redis快照重建时选择的分数，是直接从MySQL评价表聚合出来的，其中状态包含的是"待审核"的数据，应该有条件地过滤掉。

修复方案是给重建任务加状态过滤条件，只聚合审核通过且未折叠的数据，同时把定时刷新的间隔从10分钟调整为5分钟减小窗口期。从那以后我再也没遇到这种跳变问题。这里顺带说一个防御性技巧，每次做缓存重建任务的时候都先把任务标记更新到Redis的一个"重建中"标志位，读请求到了看到这个标志位就继续用旧缓存，避免读到半成品数据。

6.4 追加评价覆盖主评价的问题

追加评价上线之后，反馈最多的问题是用户在追加评价后，主评价被覆盖了。排查下来是前端展示层的Bug。App端评价卡片组件在拉取评价列表时，用的查询条件是"最新的评价记录"，而追加评价的时间戳比主评价新，就把主评价单独挤出了列表。

数据层没有问题，是接口返回了多行数据，前端只取了最新一行。需要改的就是后端在返回评价列表查询时，对同一评价ID下的主评价和追加评价做分组聚合，主评价在上，追评作为子模块渲染。现在我做评价领域的功能都习惯性地在接口每小时字段变更时同步更新前端的设计方案，避免这种展示层问题反复出现。

7. 点评系统冷启动与增长运营策略

7.1 冷启动阶段的内容填充

一个新上线的点评功能，最尴尬的是店里还没有评价。用户点进去看到"暂无评价"，大概率转身就走。

冷启动我用了三个方法。第一个方法是从外卖订单历史数据反向生成评价记录，由系统自动将过去90天内完成的优质用户，针对他们的实际下单菜品生成一份"默认好评"。这个默认好评不带情感词，只描述客观情况，比如"准时送达，包装完整"，所有默认好评会在评价内容下方打上"历史订单自动评价"的标识。这个方法让新上线商家的评价展示条数直接突破了0。

第二个方法是商家自评的引导。商家端会有一个邀请评价的组件，商家可以在出餐时扫描外卖小票上的二维码，或者是在订单完成通知中打开评价按钮。为了提升商家的动力，我把商家回复率和评价邀请率都做成商家的考核分，高分商家能获得流量加权。

第三个方法是结合平台的补贴玩法。新用户下单完成后，会弹窗引导写评价送小额红包。红包的成本很低，但能让评价量快速起来。补贴玩法会配一套防羊毛规则，这里我又用到了前面讲的第一层关键词过滤和第二层风控降权，保证活动进来的评价质量还是可控的。

7.2 评价激励与等级体系

评价激励体系的核心是让高价值用户留下来持续写评价。我设计了一套"评价成长值"体系，用户发一条有效评价可以获得成长值，评价被点赞也能获得成长值，追加评价同样获得成长值。积累到不同的梯度，可以解锁不同的权益，比如优先退款、专属客服、点评达人标识。

注意这里不要搞复杂的积分商城，一旦评价跟真金白银的礼品强绑定，刷分行为会直接翻倍。成长值权益里，像优先退款这种平台的制度性权益，比发购物卡更安全，且不增加平台的财务负担。

等级体系的另一个重要作用是区分评价权重。我当时给Lv5级以上的高质量用户，他们的评价计入综合评分的权重加20%，因为他们的评价历史长、风格稳定、质量高。这套评价权重体系给高质量用户提供了更强的表达欲望，也给普通用户提供了向上成长的路径。

8. 多端设计与内容分发细节

8.1 用户端的评价构图设计

评价表单的设计直接决定评价率，这是产品层面的硬功夫。外卖点评的评价表单要分逻辑演示，第一屏是整体评分加菜品标签，用户先打个总分再顺手点几个标签，这个动作很快，10秒内完成。第二屏才是文字输入框，必备的和选填的区分清楚，愿意写字的人自然会写字，不愿意写字的人有标签也能提供足够多的信息。

图片上传区要设计得毫不打扰，不能像传统表单一样把上传入口做的特别大只露出相机图标，这样会让用户觉得写评价很麻烦。我把图片上传和文字输入混合在一个沉浸式面板里，评价完菜品后如果用户照片在相册里，系统会自动弹"一键带上相册菜品照片"的能力，点一下就配图。实测这个交互的上图率比普通上传按钮高了将近4倍。

展示端评价卡片的设计要照顾人性的比较心理。同级评价下图文评价排前面，并且带有独特的金色卡片角标，大家看到好看的评价晒图会更有晒图的动机。这个功能被叫成"简洁版大众点评"，效果倒是客观上拉动了其他平台型的笔记本类内容增长，当然这是后话了。

8.2 商家端评价管理设计

商家端评价管理最重要的是效率。商家一天几百条评价，如果每条都要人工看，商家会卸载你的App。我做了三个功能来压缩商家的管理成本。

第一个是评分归因。商家端首页直接展示今天的评分变化跟哪些维度有关。举例，今天评分从4.5降到了4.4，归因的结果是口味的加权分下降了，而口味分下降主要来自3条一星评价指向"太辣"标签。商家看到归因就能立刻定位问题，不用自己一条条翻差评。

第二个是差评待办中心。所有命中降权和折叠规则的差评，会单独进入待办中心。这些差评需要商家申诉，申诉成功以后可以恢复评分。原来散落在评价流里的差评不好管理，有了待办中心以后，商家处理申诉的及时率提升了50个百分点以上。

第三个是竞品对比。给每个商家展示同商圈、同品类排名前三的店铺在评分、评价数、标签关键词上的表现数据。商家看到竞品的菜品评价里被提到最多的是"分量足"，自己的店铺最大的低频标签是"等位太久"，直接的改进方向就从数据里浮现出来了。

9. 写在最后的实战心得

这个外卖点评系统从零到一上线，再到稳定支撑日均新评价量的全流程，我把觉得真正有价值的东西沉淀下来。

第一，评价系统表面上是内容产品，骨子里是数据产品。表单、展示、互动都是壳，真正的内核是评分计算、风控模型和推荐数据链路。如果一开始就按数据产品的思路搭建，后面接搜索、推荐、风控、商家考核都会顺很多；如果按内容产品做，后面每个环节都会返工。

第二，做评价系统必须把风控前置到产品设计里，而不是上线后补。我在设计表单的时候就把敏感词过滤、状态位设计、风控记录表都和时间流放在一起了。现在审核功能能跑得还比较稳，不能说全归功于前置设计，但肯定帮了大忙。风控规则千万不能是静态的，要留出规则后台可以随时调整的空间，要配合数据看板监测每天的风控命中量。

第三，冷启动要务实地解决"评价从哪来"的问题，先靠历史订单回填和补贴把量做起来，再去谈评价质量。一开始就追求高评价质量，系统很容易死在没有评价的冷启动阶段。评价的颗粒度也要逐步放，先支持菜品评价，再支持标签、追加、图片、回复，一次别全都怼上去。

最后一个小技巧，每次发布跟评价猜码相关的功能前，先把旧数据做一遍全量打分对比。评价体系改动的影响面太广了，会在用户端、商家端、搜索推荐端、数据看板端同时产生变化。先对比再上线，能省掉八十个小时的线上排查时间。这个习惯我从第一个版本用到现在，救过很多次场。