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. 写在最后的实战心得这个外卖点评系统从零到一上线再到稳定支撑日均新评价量的全流程我把觉得真正有价值的东西沉淀下来。第一评价系统表面上是内容产品骨子里是数据产品。表单、展示、互动都是壳真正的内核是评分计算、风控模型和推荐数据链路。如果一开始就按数据产品的思路搭建后面接搜索、推荐、风控、商家考核都会顺很多如果按内容产品做后面每个环节都会返工。第二做评价系统必须把风控前置到产品设计里而不是上线后补。我在设计表单的时候就把敏感词过滤、状态位设计、风控记录表都和时间流放在一起了。现在审核功能能跑得还比较稳不能说全归功于前置设计但肯定帮了大忙。风控规则千万不能是静态的要留出规则后台可以随时调整的空间要配合数据看板监测每天的风控命中量。第三冷启动要务实地解决评价从哪来的问题先靠历史订单回填和补贴把量做起来再去谈评价质量。一开始就追求高评价质量系统很容易死在没有评价的冷启动阶段。评价的颗粒度也要逐步放先支持菜品评价再支持标签、追加、图片、回复一次别全都怼上去。最后一个小技巧每次发布跟评价猜码相关的功能前先把旧数据做一遍全量打分对比。评价体系改动的影响面太广了会在用户端、商家端、搜索推荐端、数据看板端同时产生变化。先对比再上线能省掉八十个小时的线上排查时间。这个习惯我从第一个版本用到现在救过很多次场。