4.7 分是怎么算出来的：vibe 项目评价/评分系统实战

先划三条线，免得你读完发现走错片场：本文不讲评论区的嵌套、@提及和盖楼（那是本轮另一篇《评论系统实战》的地盘：评论管"讨论"，本文管"打分与口碑"，两篇分工明确）；不讲推荐算法怎么做（见《推荐冷启动指南》）；不讲退款纠纷（见《退款争议指南》）。本文只回答一个问题：在一个 vibe 项目里，从零做出一套可信的评分与评价系统，要做哪些工程决策、踩哪些坑、以及上线前按什么清单检查。

为什么评分值得单独写一篇？因为"五星好评 4.8 分"这行小字，是全站转化率最高的 UI 元素之一，也是最容易被做"假"的功能。在 vibe coding 的工作流里，评分功能通常是第一批被 AI 生成的：一个 rating 字段、一个平均值、五颗星星——Demo 跑起来了。三个月后，真实世界教你做人：一个新上架的商品只有 1 条五星评价，平均分 5.0，排在 2000 条评价、4.7 分的老商品前面，用户骂你"刷单"；竞争对手用脚本刷了 500 条一星，你的 4.8 一夜变 3.2；有人发现改评价可以无限改，把差评改成好评骗退款；老板问"为什么我们的 4.9 分在 Google 搜不到星级"，你发现压根没加结构化数据。评分系统的工程量藏在"平均分"背后：分怎么算、刷怎么防、改怎么管、数怎么缓存。

本文目标读者是正在给 vibe 项目加评分/评价功能的一人团队或独立开发者，技术栈以 Next.js / Node + PostgreSQL + Redis 为主。全文围绕一条可直接落地的主线展开：数据模型 → 聚合算法 → 写入链路 → 防刷 → 评价审核 → 多维度评分 → 展示 UX → 缓存 → 上线 SOP。每节末尾都有决策表或检查点，代码片段均为可直接参考的 TypeScript + Prisma 示例。

一、评分系统的三层：采集、聚合、展示

动手之前先拆三层。很多翻车源于把三层搅在一起：比如在列表接口里现场 AVG(rating)，商品一多直接把数据库拖死；或者在前端算贝叶斯平均，用户改个排序就要重新拉全量数据。三层职责：

1. 采集层：用户提交评分（1~5 星）+ 可选文字评价 + 图片。只回答"谁能评、能评几次、能改几次"。
2. 聚合层：把 N 条评分算成"4.7 分（2312 条评价）"这一个数字 + 分布直方图。只回答"分怎么算、什么时候重算"。
3. 展示层：星星、分布条、排序、筛选。只回答"用户看到什么"。

给一人团队的铁律：聚合结果必须落库（或落缓存），绝不现场算。商品列表页一次展示 20 个商品，每个现场 AVG() 就是 20 次聚合查询；加上分布直方图（5 个桶的 COUNT），直接 120 次。聚合是写时算、读时取，这是整篇的架构基石。

第二个前置决策：评分和文字评价放一张表还是两张？放一张表（reviews），rating 非空、body 可空。"只打分不写字"是最高频行为（通常占 70% 以上），拆成两张表只会让写入链路多一次 JOIN，毫无收益。文字为空的评价在展示时归入"评分"统计，在评价列表里默认折叠——产品细节，工程上只是一张表。

二、数据模型：评价表 + 聚合表，两张就够

model Review {
  id          String   @id @default(cuid())
  subjectType String   // "product" | "course" | ...
  subjectId   String
  authorId    String
  rating      Int      // 1~5，数据库 CHECK 约束
  body        String?  @db.Text
  bodyHtml    String?  @db.Text // 有文字时服务端渲染（复用评论篇的清洗链路）
  verified    Boolean  @default(false) // 已验证购买/体验
  status      ReviewStatus @default(VISIBLE)
  helpfulCount Int     @default(0) // "有用"票数
  editedAt    DateTime?
  createdAt   DateTime @default(now())

  @@unique([subjectType, subjectId, authorId]) // 一人一主体一条，防刷基石
  @@index([subjectType, subjectId, status, createdAt])
}

model ReviewAggregate {
  subjectType String
  subjectId   String
  count       Int    @default(0)  // VISIBLE 评价数
  sum         Int    @default(0)  // 评分总和（存总和不存平均，防浮点漂移）
  avg         Float  @default(0)  // 展示用平均分，sum/count 落库
  bayesian    Float  @default(0)  // 贝叶斯平均（见第三节）
  wilson      Float  @default(0)  // Wilson 区间下限（见第三节）
  dist1..dist5 Int   // 各星级数量，直方图直接读
  updatedAt   DateTime @updatedAt

  @@id([subjectType, subjectId])
}

enum ReviewStatus { VISIBLE HIDDEN SPAM }

四个细节决定成败：第一，@@unique([subjectType, subjectId, authorId]) 是防刷的第一道墙，一人一主体只能留一条评价，想改走"修改"流程（见第四节），不能重复提交。没有这个唯一约束，脚本 10 分钟能刷出 1 万条。第二，聚合表存 sum 不存 avg 做计算：平均分用 sum/count 现场除，浮点累积误差在万次更新后会肉眼可见（4.6999999），存总和是整数，永远精确。第三，dist1..dist5 五个桶冗余，直方图展示零查询；更新时按旧评分 -1、新评分 +1，包在同一事务。第四，verified 标记独立于评分：是否"已验证购买"由订单系统回写，不要让用户自声明——自声明的"已购买"和没写一样。

为什么聚合表不用 Redis 而用 PostgreSQL？因为聚合数据要持久化 + 可审计：Redis 丢了可以重建，但重建期间全站评分显示 0 是事故；PostgreSQL 是 source of truth，Redis 只做读缓存（见第八节）。顺序不能反。

三、聚合算法四选一：平均分不是平均一下就行

这是全文最核心的决策。"4.7 分"怎么算，直接决定排序公不公平、新品有没有出头之日。四种算法，没有银弹：

算法	公式（示意）	解决什么问题	弱点	适合谁
简单平均	sum / count	无，最直观	1 条 5 星 > 2000 条 4.7 星；刷单直接拉满	评价数都很大的成熟类目（大家都有几千条，样本量差异可忽略）
贝叶斯平均 Bayesian average	(C·m + sum) / (C + count) C=先验数量，m=先验均值（全站平均分）	小样本向全站均值收缩：1 条 5 星 ≈ 全站均值，不会屠榜	C 的取值要调；新品冷启动期分数"被平均"，需要配合"新品"标签	一人团队默认选项：电商、课程、应用商店等"排序要公平"的场景
Wilson 区间下限 Wilson score	按"好评率"的 95% 置信区间下限排序	数学上最严谨的"小样本惩罚"	公式复杂；对 1~5 星要折算成"好评/差评"二值，信息有损	Reddit 式"有用"投票排序；纯星级场景不如贝叶斯直观
时间衰减加权	近期评分权重更高，w = 0.5^(age/halfLife)	商家改进后老差评不再钉死；刷单的时间窗口被压缩	历史口碑被稀释，老字号吃亏；权重函数又要调参	外卖、打车等"体验时效性强"的场景

给一人团队的默认答案：展示用简单平均（用户理解成本最低），排序用贝叶斯平均（公平性最高）。页面上写"4.7 分（2312 条评价）"——这是简单平均，用户一眼懂；但"按评分排序"时用 bayesian 字段——新品不会靠 1 条五星屠榜。两个数字各司其职，不要只存一个。

贝叶斯的 C 和 m 怎么定？m 取全站（或该类目）所有 VISIBLE 评价的平均分，每天凌晨定时任务重算一次；C 取"有统计意义的最小样本量"，经验值 10~25。C=20、m=4.2 时：1 条 5 星的贝叶斯分 = (20×4.2+5)/21 ≈ 4.24，老老实实排在 2000 条 4.7 星后面；2000 条 4.7 星的贝叶斯分 ≈ 4.695，基本不受先验影响。C 越大，新品越难出头；C 越小，刷单越容易。用类目维度分别算 m（3C 数码的 m 和生鲜的 m 不是一回事），不要全站一刀切。

好评率要不要显示？"92% 好评"这种？建议显示，但口径写清楚：好评 = 4~5 星，好评率 = (dist4+dist5)/count。不要学某些平台把 3 星也算好评——口径注水被用户发现一次，信任永久打折。差评率同理。

四、写入链路：幂等、已验证购买、修改窗口

评价的写入比评论更敏感——因为每条评价直接改写商品的"脸面"（聚合分），所以链路要更严。五个阶段：

1. 身份与资格校验：登录用户 + @@unique 约束（一人一主体一条）。要不要"买过才能评"？分场景：电商/外卖类必须（未购买评价的 verified=false，且排序权重降级）；内容/工具类可放开（"用过"无法验证），但放开就要接受水军——见第五节。
2. 幂等：clientRequestId 唯一索引（复用评论篇方案）。评价的幂等更重要：用户连点两次"提交"，没有幂等就是两条评价，聚合分直接被污染。
3. 评分范围校验：1~5 整数，数据库 CHECK 约束兜底。半星（4.5）要不要支持？第一版不支持——半星让聚合、直方图、贝叶斯全部复杂一倍，而用户感知提升有限。等用户真的抱怨"4 星和 5 星之间没有选项"再加。
4. 事务内更新聚合：INSERT/UPDATE review + UPDATE aggregate(count±, sum±, dist桶) 同一事务。注意修改评分的场景：旧 5 星改成 2 星，sum = sum - 5 + 2、dist5-1/dist2+1、count 不变。修改给 30 天窗口期（createdAt + 30d 内可改），超时锁死——"先给五星拿返现，半年后改一星报复商家"的把戏，窗口期直接掐死。
5. 缓存失效 + 事件：事务提交后删 Redis 聚合缓存（key 如 agg:product:{id}），发 review.created/updated 事件。贝叶斯重算不实时做——每小时 cron 批量重算近 7 天有变更的主体（见下）。

verified 标记怎么回写？订单系统在"订单完成"（确认收货/服务完成）时发事件，评价服务订阅后把该用户对该主体的评价 verified 置 true。回写是异步的：用户可能先评价后收货，verified 晚到几天是正常的，展示时以当前值为准。注意时序坑：用户退货后 verified 要不要收回？要——退款完成事件把 verified 置回 false，否则"买完给五星、退完货分还在"是刷单产业链的标准操作（见《退款争议指南》的关联章节）。

匿名评价？不支持。评分匿名 = 刷单自由。所有评价必须登录，作者昵称脱敏展示（如"张*"）即可，保护隐私不靠匿名，靠脱敏 + 不展示 userId。

五、防刷单：四层信号 + 人工复核

刷单（好评）和恶意差评是一体两面，防线通用。四层信号从弱到强：

1. 身份层（成本≈0）：一人一主体一条（唯一约束）+ 新注册 7 天内评价不计入聚合（status=VISIBLE 但 counted=false，展示时标注"新用户评价"）。羊毛党最恨这一条：养号 7 天才能刷，成本直接起飞。
2. 行为层（成本≈0）：同一设备指纹 24 小时内评价超过 5 个不同主体 → 全部进人工复核；评分与文字情感不符（5 星配"垃圾骗子"）→ 自动 FLAGGED（简单情感词典即可，一人团队不用上模型）；只打 1 星/只打 5 星的"极端用户"，其评价在排序中降权（不删除，只降权——误删真实差评是公关灾难）。
3. 关联层（中等成本）：同一主体短时间内涌入大量同分评价 → 触发"评价异动告警"（1 小时新增 > 过去 7 天均值 10 倍）；评价者与商家账号的关联（同设备、同 IP 段、同收款账户）→ 直接 SPAM。前者是《可观测性指南》的告警机制在评价场景的落地，后者需要订单/账号系统的关联数据，一人团队可以先只做前者。
4. 人工复核（最贵）：被标记的评价进队列，运营逐条看。复核界面必须显示"该用户历史评价分布"（全 5 星 or 全 1 星一目了然）和"设备/IP 关联图谱"（简化版：列出同设备其他账号）。每天 10 分钟能清完的量级设计，超过就说明前三层漏了，先补前三层。

被确认刷单的评价怎么处理？状态置 SPAM + 聚合回滚（count-1、sum-评分、对应 dist 桶-1），同一事务。不要只隐藏不回滚——聚合分里还留着刷单的分数，等于没处理。商家刷单被抓到，产品策略是"降权 30 天"还是"下架"？这是运营决策，工程上留一个 penaltyUntil 字段，排序时惩罚期内的主体贝叶斯分 × 0.9。把"罚则"做成可配置的，吵架时改配置不改代码。

恶意差评（竞争对手刷 1 星）的识别信号：差评集中在某个时间段、无文字或文字模板化、评价者无购买记录（verified=false 占比畸高）。处理：先 FLAGGED 进复核，确认后 SPAM + 回滚，同时给商家侧发通知"检测到异常差评攻击，已拦截 N 条"。这条通知是商家留存的神器——平台在"保护"我，续费意愿完全不一样。

六、文字评价的审核：复用评论篇的链路

有文字的评价，本质上是一条"带星级的评论"，审核直接复用《评论系统实战》第六节的四层防线（限流→关键词→云 API→人工复核），不要另起一套。两处差异化：

• 评价的文字是可选的，无文字的纯评分跳过审核（星级数字没有违规空间），只有 body 非空才进审核链路。省 70% 的审核成本。
• 评价审核不通过时，评分保留、文字隐藏：status 拆成 ratingStatus 和 bodyStatus 两个字段。用户写了 5 星 + 涉黄文字，文字 HIDDEN，5 星照样计入聚合——一刀切把评分也埋了，用户会觉得"我明明给了五星怎么不算数"而客诉。字段拆分的成本是一次 schema 设计，收益是客诉量减半。

晒单图片（评价配图）走《图片处理管线指南》的链路：多尺寸、EXIF 转正、水印。评价图片的额外要求是防盗图：同一张图（phash 相似度 > 0.95）出现在 3 个以上不同用户的评价里，自动 FLAGGED——这是刷单工作室"一套图全网发"的指纹。一人团队用 phash 库（几十行代码）就能做，不用上向量数据库。

七、多维度评分：一个总分不够时才上

外卖要评"口味/配送/包装"，酒店要评"位置/服务/卫生"，课程要评"内容/讲师/作业"。多维度评分什么时候上？等用户抱怨"总分 4.5 但不知道哪不行"时再上，第一版一个总分够了。多维度的工程代价是线性的：每多一个维度，聚合表多一列（sumTaste/count），写入事务多一次更新，直方图多一组。

上了之后守三条规则：第一，维度 ≤4 个，超过 4 个用户就乱打分了（心理学上的选择过载，工程上叫"数据质量崩"）；第二，总分 = 各维度平均，不搞权重——权重是产品拍脑袋、用户看不懂、运营调不动的三输设计，真有"配送比包装重要"的诉求，用"维度展示顺序"表达（重要的放前面），不要用数学表达；第三，维度分只展示不排序，排序永远用总分的贝叶斯值——按"口味分"排序这种需求，99% 是伪需求，砍掉。

数据模型：Review 表加 dimensions Json（如 {"taste":5,"speed":4}），聚合表加 dimSums Json。JSON 存维度分而不是列，因为维度是产品可配置的（运营后台加维度不改表结构）。校验在应用层做：维度 key 必须在当前生效的维度配置里，值 1~5 整数。维度配置变更（如下线"包装"维度）不影响历史数据，历史 JSON 原样保留，展示时按当前配置过滤。

八、展示 UX：星星、直方图、排序与筛选

展示层是评分系统的"脸"，四个组件：

1. 星级显示：4.7 分显示 4.7 颗星（满星 + 部分星用 CSS 渐变/裁剪实现，不要用"四舍五入到整星"——4.7 显示成 5 颗星是欺诈感，显示成 4 颗是亏待感）。星星旁边必须跟"（2312 条评价）"，光秃秃的 4.7 没有可信度。颜色用琥珀色（amber-400）是行业惯例，不要创新成紫色星星。
2. 分布直方图：5 星 ████████ 68%、4 星 ███ 15%……直接读 dist1..dist5。直方图是"防刷照妖镜"：正常商品的分布是 J 形（5 星最多、1 星次之、中间少）；刷单的分布是畸形的（5 星 99% 或 1 星 99%）。运营后台给分布图加"异常分布"标记（5 星占比 >95% 或 1 星占比 >50% 自动标红），比看数字直观十倍。
3. 评价列表排序：默认"最有帮助"（helpfulCount DESC, createdAt DESC），可切换"最新"。不要默认"最高分优先"——那是刷单者的天堂。verified 评价在视觉上加"已验证购买"徽标，排序加权（verified 的 helpfulCount × 1.5），让真实声音浮上来。
4. "有用"投票：每条评价一个"有用"按钮，review_helpful(reviewId, userId) 唯一约束，防刷票（同一用户 1 分钟 ≤20 票）。有用票数是评价列表排序的燃料，也是识别水军的信号（刷单评价的"有用"票通常为 0，因为没人真看）。

筛选功能（按星级筛选、只看有图、只看已验证）是评价列表的标配，实现都是 WHERE 条件组合，索引 (subjectType, subjectId, status, rating, createdAt) 覆盖。注意"只看差评"（1~2 星）是用户决策的高频入口，商家后台更要给"差评聚合"视图：按关键词聚类差评（"太咸""配送慢"），这是商家续费的理由——平台不只给分，还告诉商家怎么改进。

移动端注意：直方图在窄屏上把百分比数字放在条外，不要挤在条里；星级组件的触摸目标 ≥44px，五颗小星星挤在一起，手指粗的用户永远点不准 5 星——这是真实客诉。

九、聚合缓存与失效：Redis 只做读加速

第八节说聚合表是 source of truth，Redis 是读缓存。缓存策略三条：

1. key 设计：agg:{subjectType}:{subjectId}，value 存聚合表整行 JSON（含 avg、bayesian、count、dist1~5），TTL 1 小时。列表页 20 个商品 → 20 次 Redis MGET，P99 < 5ms。不要按字段拆 key（avg:xxx、count:xxx），拆了之后失效要删 N 个 key，漏一个就是脏数据。
2. 失效策略：写时删除（delete-on-write），不是写时更新。评价写入/修改/状态翻转的事务提交后，DEL agg:product:123，下次读时 miss 再从聚合表加载回填（read-through）。写时更新（update Redis 里的 avg）的问题是：更新逻辑要在应用层重做一遍聚合计算，和数据库事务不是原子的，崩了就脏。删除是幂等的，重建是单路径的，简单就是可靠。
3. 贝叶斯重算走 cron，不走实时：每小时 job 扫"近 1 小时有评价变更"的主体（ReviewAggregate.updatedAt > now()-1h），重算 bayesian（需要全站 m，先算 m 再算各主体），写回聚合表 + 删对应 Redis key。全站 m 每天重算一次（凌晨低峰）。不要每次评价写入都重算贝叶斯——m 是全站级常量，高频重算浪费且无意义。

缓存穿透（查不存在的主体）用布隆过滤器或"空值缓存"（agg:xxx = NULL 缓存 5 分钟）挡；缓存雪崩（大量 key 同时过期）用 TTL 加随机抖动（1 小时 ± 10 分钟）。这都是《缓存策略指南》的通用手段，评价场景照抄就行，本文不展开。

一个冷知识：聚合表的 updatedAt 是全站最有用的"热度信号"之一。"近 7 天有新评价的商品"列表，直接 ORDER BY updatedAt DESC 就出来了，运营做"本周口碑上升"榜单零成本。

十、坑点清单：十个真实翻车现场

1. 现场 AVG()：列表页每个商品现场聚合，20 个商品 20 次 AVG + 100 次 COUNT。聚合落库，读时取。
2. 1 条 5 星屠榜：简单平均排序，新品 1 条五星排第一。排序用贝叶斯平均。
3. 无一人一评约束：脚本 10 分钟刷 1 万条。@@unique(subjectType, subjectId, authorId) 是第一道墙。
4. 浮点存平均分：万次更新后 4.6999999。存 sum（整数），展示时除。
5. verified 自声明：用户自己勾"已购买"。verified 必须由订单事件回写。
6. 退货不收回 verified："买完五星、退货分留"是刷单标准操作。退款事件置回 false。
7. 修改无窗口期："五星返现→半年后改一星"报复。30 天窗口，超时锁死。
8. 审核一刀切埋评分：文字违规把 5 星也埋了，客诉爆炸。ratingStatus/bodyStatus 拆字段。
9. 写时更新 Redis：应用层重做聚合，与事务非原子，崩了就脏。写时删除 + read-through。
10. 半星第一版就上：聚合、直方图、贝叶斯全复杂一倍。第一版 1~5 整数，被抱怨再加。
11. count=0 显示"暂无评分"：等于告诉用户没人买，转化-15%。count=0 时隐藏评分模块，或显示"新品上架"。
12. 贝叶斯 cron 静默失败：挂了页面照常显示旧分，无报错。cron 最后一步写心跳，监控查心跳超时。

十一、评价与 SEO：让星级出现在搜索结果里

Google 搜索结果里商品旁边的"★★★★★ 4.7（2312）"，是点击率放大器。做法是 AggregateRating 结构化数据：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "示例商品",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",      // 简单平均，保留一位
    "reviewCount": "2312",     // VISIBLE 评价数
    "bestRating": "5"
  }
}

三条红线（Google 明确会惩罚的）：第一，ratingValue 必须用真实聚合值，不能写 5.0 骗点击——被举报后富结果资格直接取消；第二，reviewCount 只计 VISIBLE，把 SPAM 也算进去是数据造假；第三，页面上必须真的展示了这些评价（用户可见），"有结构化数据、无前台展示"会被判为作弊。SSR 输出 JSON-LD（服务端直接读聚合表，无额外查询），和 g1 评论篇的 DiscussionForumPosting 可以共存于同一页面。

评价单页（每条评价的详情页）要不要做？第一版不做。评价详情页是 thin content 重灾区（一条 20 字的评价撑起一个页面），SEO 负分。评价只活在主体页面里，用锚点（#review-xxx）定位。等某条评价真的成为"神评"（helpfulCount > 1000）再考虑单独成页——那是运营动作，不是工程预设。

十二、上线 SOP：发布前逐项打勾

1. 数据模型：@@unique(subjectType, subjectId, authorId) 生效（并发压测同一用户提交两次只产生 1 条）、rating CHECK 1~5、聚合表 sum/count/dist1~5 字段齐、索引 (subjectType, subjectId, status, createdAt) + (subjectType, subjectId, status, rating, createdAt) 建好。
2. 聚合算法：展示用简单平均、排序用贝叶斯，m（类目均值）cron 每天重算、C 值（10~25）按类目配置、bayesian/wilson 落库字段有值（抽查 100 个主体无 NULL）。
3. 写入链路：幂等键去重（双击 1 条）、修改 30 天窗口（31 天的改不了）、verified 由订单事件异步回写（mock 退款事件验证收回）、事务内聚合更新（mock 回滚验证聚合未动）、提交后删 Redis key。
4. 防刷：新用户 7 天评价不计入聚合、设备指纹 24h >5 主体进复核、异动告警（1h 新增 >7 天均值 10 倍）已配、SPAM 确认后聚合回滚同一事务、商家惩罚 penaltyUntil 可配置。
5. 审核：有文字才进审核链路、ratingStatus/bodyStatus 拆分（文字 HIDDEN 时评分仍计入）、晒单图 phash 去重（相似度 >0.95 进复核）。
6. 展示：星级部分星渲染（4.7 显示 4.7 颗）、直方图读 dist 桶、默认"最有帮助"排序、verified 徽标、有用投票唯一约束、移动端触摸目标 ≥44px。
7. 缓存：key 单键整行 JSON、写时删除 + read-through、贝叶斯 cron 每小时、TTL 抖动防雪崩、空值缓存防穿透。
8. SEO：AggregateRating JSON-LD SSR 输出、ratingValue=真实值、reviewCount 只计 VISIBLE、页面真实展示评价。
9. 可观测：评价写入 P99、聚合重算耗时、SPAM 确认率、异动告警触发次数进 dashboard；贝叶斯 cron 失败告警（失败 = 全站排序冻结在旧值，比报错更隐蔽）。

最后送一句话：评分系统是"信任工程"——你算的不是平均分，是用户敢不敢信。用贝叶斯守住公平，用 verified 守住真实，用 SOP 守住底线。祝你的 4.7 分，条条经得起查。

二（补）、为什么不用数据库物化视图做聚合？

PostgreSQL 有物化视图（MATERIALIZED VIEW），SELECT subjectId, AVG(rating), COUNT(*) 一把梭，定时 REFRESH，看起来是聚合表的"官方实现"。为什么本文坚持手写聚合表？三个原因：

• REFRESH 的粒度不可控：REFRESH MATERIALIZED VIEW 默认全量重算（CONCURRENTLY 也只是不锁表，计算量一样）。评价过百万后，每小时全量扫一遍的开销，远大于"有变更才更新一行聚合表"的增量成本。物化视图是给 BI 报表用的，不是给在线业务用的。
• 贝叶斯和 Wilson 写不进视图定义：物化视图的 SQL 里可以写公式，但公式里的全站均值 m 是每天变的常量，视图定义里硬编码 m，明天就过期；用函数查 m，每次 REFRESH 又变成"全表 × 全表"的嵌套。手写聚合表 + cron，m 的更新和各主体的重算解耦，清晰得多。
• 状态翻转的语义丢失：SPAM 确认、审核翻转、verified 回写，这些"业务事件"在物化视图里只是一次 REFRESH，你失去了"这次变更是因为什么"的审计信息。手写聚合表的更新函数里，每次更新都记一条 aggregate_changelog（subjectId、delta、reason、at），线上对账 30 秒定位。物化视图给不了这个。

一句话：物化视图是"查询的缓存"，聚合表是"业务的账本"。账本必须手写，每一笔有来龙去脉。

四（补）、待评价状态机：从"订单完成"到"评价沉淀"

评价不是凭空产生的，需要"待评价"这个中间状态驱动。订单完成 → 用户收到"给这次体验打个分吧" → 评价（或 30 天后过期）。状态机很小，但不做的话评价量只有做了的 1/5：

待评价池：pending_reviews(userId, subjectType, subjectId, orderId, expiresAt)
// 订单完成事件 → 插入一条（去重：同一用户同一主体只保留最新一条）
// 用户提交评价 → 删除对应 pending 记录
// expiresAt（30 天）→ cron 清理过期

三条产品规则：第一，提醒只发一次（+ 7 天后未评再发一次，共两次封顶），提醒走通知中心（见《通知中心指南》），评价侧只提供"待评价列表"接口；第二，待评价列表是评价入口中转化率最高的（用户刚体验完），放在"我的订单"和个人中心显眼位置，不要藏在三级菜单；第三，过期不打扰：30 天未评自动清理，不要发"最后通牒"——骚扰用户的代价是卸载。

激励评价要不要给优惠券？"好评返现"是明确的刷单诱导，平台规则通常禁止；"评价即得积分"（不论几星）是合规的——关键区别是激励不能和星级挂钩。工程上：积分发放走 review.created 事件，与 rating 值无关，代码里不要出现 if (rating === 5) giveCoupon() 这种行，法务看到会心梗。

四（补）、评价修改的审计轨迹：每一次改分都有记录

30 天修改窗口期（见第四节）带来一个新问题：用户把 5 星改成 1 星，商家客诉"他明明给了五星"，你怎么查？评价的每次修改都要记审计轨迹，不是可选项：

model ReviewEditHistory {
  id        String   @id @default(cuid())
  reviewId  String
  oldRating Int
  newRating Int
  oldBody   String?  @db.Text
  newBody   String?  @db.Text
  editedAt  DateTime @default(now())
  ip        String?  // 最后一公里：被盗号改评价时有用

  @@index([reviewId, editedAt])
}

写入事务里加一行 create(reviewEditHistory)，成本忽略不计，收益是客诉时 30 秒还原真相。注意历史记录不展示给普通用户（只给运营后台和商家申诉看），展示"他改过 3 次"会激化矛盾，展示"当前是 1 星（30 天内修改过）"是中性事实。另外，被盗号批量改评价是真实攻击手法：ip 字段 + "同一 ip 1 小时改 50 条评价"告警，能第一时间发现。

十三、B2B 场景：当评价是"甲方给乙方打分"

前面默认都是 C 端（用户给商品打分）。B2B 场景（甲方给服务商打分、雇主给 freelancer 打分）有三个不同点，一人团队做 SaaS 时迟早遇到：

• 双向评价：甲给乙打分的同时，乙也给甲打分（"这个甲方付款爽快吗"）。数据模型复用同一张表，加 direction 字段（CLIENT_TO_VENDOR / VENDOR_TO_CLIENT），聚合表按 direction 分开算。展示时两个分数并列——"4.8 分（作为服务商）/ 4.9 分（作为甲方）"，信息对称才公平。
• 评价公开时机：双向评价必须同时公开（双方都提交后，或 14 天后自动公开）。一方先看到对方的差评再报复性打 1 星，是双向评价的经典博弈。实现：status=SEALED（已提交未公开），双方齐了或过期 → 批量翻 VISIBLE + 重算聚合。这是状态机多一个状态的事，_schema_ 预留好。
• 评价即合同附件：B2B 的差评可能进法务流程，所以 ReviewEditHistory 在 B2B 场景下不可删、不可改（WORM 语义），数据库层面用触发器禁 UPDATE/DELETE。C 端可以 180 天清理，B2B 的评价审计轨迹跟合同走（合同保留几年，轨迹保留几年）。

B2B 评价还有一个潜规则：差评率天然低于 C 端（甲乙方还要做生意，撕破脸成本高），所以贝叶斯的 m（先验均值）要按场景分别算——B2B 的 m 可能是 4.6，C 端是 4.2，混用会让 B2B 的 4.5 看起来像差评。类目/场景维度的 m，schema 里 bayesianPriorM 按场景配置，不要全站一个数。

十四、跨境评价：语言、时区与文化差异

评价出海有三个工程点（i18n 通用机制见《多语言指南》，这里只讲评价特有的）：

• 评价原文 + 机器翻译双语展示：中文用户看英文评价，旁边给"翻译"按钮，译文缓存（review_translations(reviewId, locale, text)，翻译 API 按条计费，缓存是省钱）。注意只翻译展示，不翻译存储：原文永远是 source of truth，翻译错了用户还能看原文；存了翻译当原文，错了都不知道。
• 星级文化的地区差异：同样 4.0 分，在"打分宽容"的市场是中评，在"打分严苛"的市场是好评。聚合展示不做地区换算（4.0 就是 4.0），但排序的贝叶斯先验 m 按地区分别算——这是"本地公平"，和 B2B 的场景 m 一个道理。
• 时区与日期展示：评价的 createdAt 存 UTC，展示按用户时区（复用评论篇"存 UTC、展本地"）。跨境还有一条：斋月、春节等节假日期间的评价分布会漂移，异动告警的基线要按地区设，不要全球一个阈值——开斋节后中东站评价量涨 3 倍是正常，不是被刷了。

十（补）、三个迟到的教训

• 评价数是 0 的商品，页面不要显示"暂无评分"：显示"暂无评分"等于告诉用户"没人买"，转化率-15%。正确做法：不显示评分模块，或显示"新品上架，抢先体验"。0 评价时的 UI 文案是产品细节，但工程上要支持"count=0 时隐藏模块"的条件渲染——聚合表 count=0 就是信号。
• 聚合重算 cron 失败是静默事故：cron 挂了，页面照常显示旧分数，没有报错、没有告警——直到老板发现"上周的爆款还是 0 评价"。cron 的最后一步必须是"写心跳"（UPDATE cron_heartbeat SET last_ok=now() WHERE job='bayesian_recalc'），监控查心跳超时。这条适用于所有 cron，不只评价。
• 评价图片的 CDN 费用：晒单图是用户生产的内容，量起来后 CDN 账单会吓你一跳。评价图片走《图片处理管线》的三档尺寸，列表只加载 thumb（256px），详情才加载 card。原图只在"查看原图"时加载——99% 的用户不会点，但 100% 的账单会算。

三（补）、Wilson 区间：给"好评率排序"一个数学解释

第三节把 Wilson 列为备选，这里给它的直觉解释，因为"最有帮助排序"确实用得到。问题：A 评价 10 票有用、0 票无用（100% 好评率），B 评价 900 票有用、100 票无用（90% 好评率），谁排前面？直觉说 B（样本大更可信），简单按好评率排却是 A。Wilson 区间下限回答的是："以 95% 的把握，这个评价的真实好评率至少是多少？"——A 的下限约 72%，B 的下限约 88%，B 胜出，数学替你做了"样本量惩罚"。

// Wilson score lower bound（二值：有用=成功，无用=失败）
function wilsonLowerBound(up, down, z = 1.96) {
  const n = up + down;
  if (n === 0) return 0;
  const p = up / n;
  const denom = 1 + (z * z) / n;
  const center = p + (z * z) / (2 * n);
  const spread = z * Math.sqrt((p * (1 - p) + (z * z) / (4 * n)) / n);
  return (center - spread) / denom;
}

工程落地的三条：第一，Wilson 只用于"有用"投票排序，不用于星级排序——星级是 1~5 五档，硬折成二值（4~5 星=好评）信息损失大，星级排序用贝叶斯；第二，wilson 落库（评价表的冗余字段），投票时即时重算该条——投票是高频操作，公式是纯函数，重算成本忽略不计；第三，z=1.96（95% 置信）是惯例，不要调——调了也没人能解释为什么，徒增沟通成本。

什么时候 Wilson 比"按 helpfulCount 排序"好？当你的评价有"有用/无用"两档投票时。"900 有用 / 100 无用"和"900 有用 / 0 无用"，按 helpfulCount 排是并列，按 Wilson 排后者更高——争议度被数学表达出来了。如果只有"有用"单按钮（无"无用"），Wilson 退化成摆设，老老实实按 helpfulCount 排。

十五、北极星指标：怎么知道评分系统是可信的

上线后每周看四个指标，10 分钟：

• 评价渗透率 = 留评价的订单 / 总订单。健康线 5%~15%（类目差异大），看趋势：上线待评价提醒后，这个数应该涨 2~3 倍，没涨说明提醒入口藏得太深。
• verified 占比 = verified 评价 / 总评价。低于 50% 说明"买过才能评"的链路漏了（订单事件没接上），或者放开了未购买评价——前者修 bug，后者是产品决策，但要知道自己在做什么。
• 分布健康度 = 全站 dist 分布形态。正常是 J 形（5 星 60%~75%、1 星 8%~15%）；5 星占比 >90% 说明刷单或"好评返现"在流行，1 星占比 >30% 说明有品类级质量事故。分布是全站的"体检报告"，比平均分诚实。
• 评价→转化归因：看过评价的用户下单转化率 vs 没看过的。电商场景这个差值通常在 20%~50%，是评分系统在立项会上的护身符——和评论篇的指标遥相呼应：评论管"讨论热度"，评价管"信任转化"，两套指标各司其职。

指标进 dashboard，告警设阈值。评分系统至此闭环：模型、算法、写入、防刷、审核、展示、缓存、SEO、度量，九块拼图齐了。剩下的就是每天花 10 分钟看一眼分布图——5 星占比突然 99% 的那天，你会感谢这篇文章。

最后送一句话：评分系统是"信任工程"——你算的不是平均分，是用户敢不敢信。用贝叶斯守住公平，用 verified 守住真实，用 SOP 守住底线。祝你的 4.7 分，条条经得起查。

七（补）、多维度聚合的代码细节：JSON 字段怎么更新

第七节说维度分存 JSON，这里把更新逻辑写死，因为 AI 生成的代码在 JSON 字段更新上最容易写错（读出来、改、写回去，三步非原子）。正确做法是用数据库的 JSON 函数原子更新：

-- PostgreSQL：维度分原子累加（taste 维度 +5）
UPDATE review_aggregates
SET dim_sums = jsonb_set(
      COALESCE(dim_sums, '{}'),
      '{taste}',
      to_jsonb(COALESCE((dim_sums->>'taste')::int, 0) + 5)
    ),
    dim_counts = jsonb_set(
      COALESCE(dim_counts, '{}'),
      '{taste}',
      to_jsonb(COALESCE((dim_counts->>'taste')::int, 0) + 1)
    )
WHERE subject_type = 'product' AND subject_id = 'xxx';

注意 dim_sums 和 dim_counts 分开存：用户可能只评了"口味"没评"配送"（维度可选填），sum/count 按维度各自独立，缺失维度不参与平均。展示时"口味 4.6（231 人评）/ 配送 4.2（198 人评）"——每个维度的样本量都标出来，不标样本量的维度分是耍流氓。维度配置变更（如下线"包装"）时，历史 JSON 保留但展示过滤，聚合重算脚本跳过已下线维度——用配置版本号（dimVersion）标记每条评价时的维度版本，重算时只处理当前版本。

十六、从评分到口碑运营：工程之外的三件事

系统上线只是开始，口碑是运营出来的。三个工程配合运营的动作：

• 差评工单流：1~2 星评价自动生成商家待办（"3 条新差评待处理"），商家回复后用户收到通知（走通知中心事件）。"商家 24 小时内回复差评"的平台，差评改好评的转化率能到 15%~30%。工程上就是 review.created(rating<=2) 事件 → 商家待办表，一行代码的事，运营价值巨大。
• 评价内容反哺搜索：用户评价里的自然语言（"适合油皮""续航两天"）是长尾搜索词的富矿。把评价文本（脱敏后）喂给站内搜索的索引（见《搜索体验指南》的 UGC 索引章节），"油皮粉底液"这种词，商品标题里没有，评价里一堆——搜得到，转化就涨。
• 年度口碑报告：年底给每个商家出一份"你的 4.7 分是怎么来的"（分布变化、差评关键词、回复率），PDF 导出走《PDF 导出指南》的链路。这是续费谈判桌上最好用的材料——平台不只收佣金，还给增长建议。

全文完。评分系统没有银弹，但有清单：聚合落库、排序用贝叶斯、一人一评、verified 回写、防刷四层、缓存写时删除。上线前把第十二节的 SOP 逐项打勾，剩下的交给运营。祝你的 4.7 分，条条经得起查；祝你的评论区（见本轮另一篇），广告比用户先放弃。两篇配合，一个管讨论热度，一个管信任转化——这才是一个完整口碑体系的样子。

写在最后：评价系统最难的从来不是代码，是"敢不敢让差评活着"。删差评一时爽，信任崩了再也回不来。把每一条差评都当成免费的用户调研——它们指出的每一个问题，都是竞争对手还没发现的机会。祝你的星星，颗颗真实，粒粒经得起翻看与追问——这就是口碑工程的全部意义所在，值得你为之认真一次。

附：给 AI 的 prompt 模板——按本文规范生成评价模块

最后送一个 vibe coding 专属福利：直接可用的 prompt 模板。把本文的决策压缩成 AI 能执行的约束，下次让 AI 生成评价模块时贴进去，少踩一半坑：

为我的 Next.js + Prisma + PostgreSQL 项目生成评价（review）模块，
必须遵守以下约束：
1. 表：reviews（含 subjectType/subjectId/authorId/rating 1~5/
   verified/body/status）+ review_aggregates（count/sum/
   avg/bayesian/dist1~5），@@unique([subjectType, subjectId, authorId])
2. 禁止在读取链路中现场 AVG/COUNT，聚合必须落库；展示用 avg，
   排序用 bayesian（C=20，m 按类目日更）
3. 写入链路：clientRequestId 幂等 → 校验 → 事务（INSERT/UPDATE +
   聚合表更新）→ 提交后删 Redis key agg:{type}:{id} → 发事件
4. verified 只能由订单事件异步回写，禁止用户自声明；
   退款事件必须把 verified 置回 false
5. 评分修改窗口 30 天，每次修改记 review_edit_history
6. path/楼层等评论概念不许出现在这张表里（那是评论模块的事）
先输出 Prisma schema 和写入事务代码，再输出聚合重算 cron。

模板的精髓是"约束先行"：AI 不缺实现能力，缺的是决策——你把本文的决策喂给它，它的代码第一次就接近生产级。祝 vibe 愉快，评分真实。