评论块：真实聚合与评分对齐

评论块汇总了针对一个明确标识的产品、服务、企业或地点的真实客户反馈。它显示平均评分、评分标准、符合条件的评论总数、来源范围以及少量评论摘录，而不会将精选的赞美转化为人为制造的社会证明。

这个渲染出的零评论状态是刻意诚实的。它不显示空星、零分（满分五分）、一条评论的数量或由企业撰写的安慰性引用。当符合条件的评论出现时，同一个来源可控的组件可以用真实的聚合数据和可归属的摘录替换此状态。

为什么这个元素重要

评论减少了特定类型的买家不确定性：即组织声称的内容与客户实际经历之间的差距。一个有用的评论块不仅仅是增加热情。它帮助读者评估一致性，识别反复出现的优势和局限性，并判断这些体验是否来自与他们处境相似的人。数量和分布很重要，因为一条评论得出的5.0平均分与更大、更多样化记录中的4.7平均分传达的信息截然不同。

其心理机制依赖于可信度线索。具名的来源、可见的日期、公开的验证方法、混合的情感倾向以及通往原始记录的路径，帮助读者审视证据。一个完美的分数，没有计数、没有来源、只有三条精心打磨的引用，会产生相反的效果：该块块在索要信任的同时，却隐瞒了授予信任所需的事实。负面和中性的评论不是设计缺陷。压制它们可能使剩余的赞美变得不那么可信，并可能扭曲聚合结果。

机器可提取性意味着软件可以在不依赖视觉邻近性进行猜测的情况下，识别被评实体、评分值、评分标准、计数、来源和单个评论关系。在产品标题旁边的一行五个图标，对人来说可能显而易见，但爬虫无法安全地推断这些图标是在评价产品、卖家、配送服务还是页面本身。一个类型化块创建了一个有边界的记录，其可见事实可以一致地提供给搜索、内部分析、内容迁移和AI代理。

元素编写规则 提供了优先级规则：根据目的而非外观选择组件。如果一个部分汇总了客户评价，即使普通的标题、星形图标和引用可以模仿它，也应使用评论块。类型化元素强制执行来源所有权、实体身份、零状态行为、可访问标签和结构化数据对齐，而这些是松散标记无法做到的。

何时使用

当一个经批准的第一方评论系统或已识别的第三方平台中存在真实的评论，且这些反馈涉及页面所代表的精确实体时，使用评论块。它在购买或咨询决策附近、页面已解释所提供的产品之后、最终操作之前最为有用。当读者需要了解分布情况和近期主题而非单一推荐语时，它也可以汇总评论集合。

仅当收录策略稳定时使用它。“过去24个月内所有已发布的评论”、“所有已验证购买的评论"和"最新三条评论，而聚合使用所有符合条件的评论"是可理解的规则。“我们能找到的最好的评论"则不是。如果系统无法解释哪些评论被计入，它就无法为其显示的平均分辩护。

近似情况需要不同的处理：

• 一个带有背景和特定结果的归属客户故事是推荐语，而非聚合。
• 编辑的实际操作结论属于编辑评论内容，而非客户评分。
• 案例研究解释了一种干预措施和结果；其获批并不使其成为评论。
• 员工、合作伙伴、影响者或赠品产品的评论需要披露关系，并且除非验证声明属实，否则不得标注为已验证客户评论。
• 针对公司的评分不得重复用作针对某个产品的评分。针对全国性品牌的评分不得作为某个分店的证据呈现。
• 调查结果是研究证据。除非调查工具和转换方法是为此用途设计并公开的，否则不要将满意度问题转换为星级评分。

当组织根本没有评论时，不要仅仅为了填充模板而使用该块。当接受评论是页面任务的一部分时（如新产品详情页面），显示可见的零状态是合适的。在评论属于次要内容的功能说明页面上，通常直接省略整个块更为清晰。

放置位置

当读者在看到评分之前就已经知道被评对象是什么时，放置才有效。将块置于产品、服务、解决方案或地点已被识别且其基本事实已解释之后。在较长的商业页面上，将聚合置于主要价值主张和支持细节之后，然后将主要行动号召置于评论之后或下一个异议处理部分之后。

对于产品页面，通常的位置是在规格、适配性、配送和退货信息之下。对于服务或解决方案页面，将评论放在范围和流程之后，即客户体验可以检验已提出的主张之处。对于位置页面，保持块靠近分店身份和本地联系信息，以便被评地点清晰无误。

不要将评论块放置在：

• 在页面的直接描述之上，使读者无法识别被评实体；
• 在一个主张和支持该主张的证据之间；
• 在另一个实体的卡片、价格或预订操作旁边；
• 在一个未标记的推荐语轮播旁边，该轮播可能被误认为是聚合的一部分；
• 在倒计时、库存压力消息或保证旁边，这些内容会使证明显得有强迫性；
• 在对比表格内，因为一个聚合可能看起来适用于多个选项；
• 在冲突的评分值旁边，该值被复制到散文、徽章或导航中。

如果评论来自多个来源，将总体范围和来源细分保持在一个块内。不要将平台徽章分散在页面各处，并期望读者或机器来协调它们。

构成要素

1. 被评实体： 聚合所代表的精确产品、服务、企业或地点。
2. 平均分和评分标准： 一个带有明确最大值的数值，例如"4.6分（满分5分）"，而非仅有图标。
3. 符合条件的评论数量： 计算中使用的记录数量，与显示的摘录数量分开。
4. 评分分布： 每个评分级别的数量或比例，均来自同一符合条件的集合。
5. 来源范围： 包含的第一方系统或具名平台，以及适用的日期范围或上次同步时间。
6. 评论摘录： 客户撰写的文本，忠实于来源并可链接或追溯至其记录。
7. 归属和日期： 允许的公开身份、评论日期以及关系或验证标签。
8. 完整集合路径： 一个链接或控件，可展示更多评论、筛选功能、审核信息和来源详情。

设计示例

每个变体都保留了实体、评分标准、计数和来源。布局可以改变，但证据不能。

标准摘要附摘录

显示平均值、计数、分布和三到六条摘录。这是详情页的默认设置，评论用于支持决策，且存在足够的记录使分布有意义。

紧凑型聚合

显示明确的数字评分、评分标准、计数和来源链接，不含摘录。仅在受限的摘要区域使用，且同一页面的后面部分存在完整的评论块，或目标位置提供完整记录。

多来源细分

仅当评分标准具有文档化的归一化方法且所有来源对同一实体评分时，才显示一个合并的聚合。包含各来源级别的计数，以便审计人员能够重现总数并检测重复项。

筛选或分段视图

允许读者按评分、时效性、验证状态或相关产品变体进行筛选。保持未筛选的聚合可见，并标记筛选后的结果计数；切勿静默地根据选中子集重新计算标题评分。

零评论状态

说明不存在评论，并仅向符合条件的客户提供合法的评论操作。不要渲染平均值、AggregateRating标记、分布或虚构的示例引用。

参数

标记为"评论来源"的值是已解析的记录，而非键入文章的文本。限制保持块的可扫描性，而完整的评论系统则保留全部语料库。

每条可见的评论记录包含一个稳定的评论ID、允许的公开归属、发布日期、评分、可用的来源URL、验证或关系状态以及原始评论文本。正文可以仅提供可选的第一个标题。作者绝不能在指令正文中放置评论引文、姓名、分数或计数。

评论块语法和代码示例

所有三种标记方式都标识了实体和已批准的评论来源。渲染和结构化数据从同一来源快照解析。

可移植的Markdown指令

:::reviews-block{source-id="reviews-main" entity-id="product-4821" variant=standard max-excerpts=3 selection=representative}
## Customer reviews
:::

Hugo短代码

{{< reviews-block sourceId="reviews-main" entityId="product-4821" variant="standard" maxExcerpts="3" selection="representative" >}}
Customer reviews
{{< /reviews-block >}}

Hugo适配器必须解析服务器端或构建时的评论记录。传递rating="4.9"或在正文中编写引文会造成作者控制的社会证明，违反了约定。

WordPress

<!-- wp:amicited/reviews {"sourceId":"reviews-main","entityId":"product-4821","variant":"standard","maxExcerpts":3,"selection":"representative"} /-->

[amicited_reviews source_id="reviews-main" entity_id="product-4821" variant="standard" max_excerpts="3" selection="representative"]

使用读取受保护评论存储的动态块或已注册的短代码。编辑者可以选择已批准来源、显示变体和选择策略，但不得覆盖返回的评分、计数、评论者身份或文本。

好与坏的示例

好：透明的来源和混合的证据

客户评论 37条符合条件的评论，评分4.4（满分5分）。评论在预约完成后收集；最后更新于2026年8月26日。 “预订过程很直接，虽然最早的可用日期是两周后。” — 已验证预约，2026年7月

这是一个说明性的规范，而非对真实企业的声称。它可以作为生产模式使用，因为实体可以从页面得知，数字评分标准和符合条件的数量是明确的，收集方法和更新日期可见，并且摘录保留了一个有意义的限制。发布的组件将从评论记录中解析每个值，而非复制此示例。

坏：捏造的确定性

我们的客户爱我们！ ★★★★★ “简直是最好的。每次都是五星。” — Sarah 受到成千上万满意客户的信赖。

这种写法失败是因为图标没有数字评分标准或计数，评论者无法追溯到经批准来源，且"成千上万"是未经支持的数量。未经限定的最高级和精心打磨的引用可能是营销部门撰写的。添加AggregateRating代码会使这种不匹配变得机器可读，而非解决它。如果没有真实的评论，请用零状态替换整个块或直接省略。

架构标记和可访问性

符合条件的块可以为页面上显示的同一实体提供Schema.org AggregateRating。ratingValue映射到可见的平均值，reviewCount映射到符合条件的评论数量，bestRating和worstRating映射到可见评分标准。当网站的架构政策允许时，各个可见记录可以提供带有其评论评分、作者、日期和被评项目的Review对象。

对齐是精确的，而非近似。标记和可见块必须使用相同的实体、来源范围、去重策略、评分标准、计数和计算快照。不要标记2400条公司历史评论，同时只显示18条产品特定评论。不要在零状态下输出AggregateRating，不要使用零作为合成评分，不要隐藏计数，也不要标记未在视觉上呈现的导入评论。结构化数据描述评论证据；它不会为搜索功能创建资格，也不会验证评论的真实性。

可访问性要求为每种视觉编码提供文本等效项。即使存在星形图标，也应将"来自37条评论，评分4.4（满分5分）“作为文本渲染。为分布条形图提供可访问的名称，例如"五星：21条评论”，且不要仅依赖条形宽度或颜色。每条摘录应是一个语义文章或列表项，其归属、评分和日期按阅读顺序关联。

筛选控件需要可见标签、键盘操作以及宣布的结果变更。截断的评论需要一个实际按钮，其展开状态被传达；视觉淡出是不够的。当人名已存在时，评论者头像通常是装饰性的，应使用空的替代文本。切勿暴露电子邮件地址、订单号或其他私人验证数据来证明真实性。

编写规则

每条规则保护的是真实性或可解释性：

• 一个块评价一个实体。 切勿将公司、产品、卖家、配送和分店的反馈合并为一个数字，因为读者无法判断评分代表哪种体验。
• 来源拥有证据。 评分、计数、摘录、姓名、日期、验证状态和来源URL来自经批准记录。作者仅控制放置位置、标题、变体和声明的选择方法。
• 零意味着没有主张。 评论为零时，显示一句话或什么都不显示。不要显示零星、0.0、“尚未评分"旁有满星、预填的员工评论或AggregateRating标记。
• 聚合使用完整符合条件集合。 不要从显示的三条摘录计算标题评分。在计算前应用文档化的资格筛选、审核和去重规则。
• 摘录展示公平范围。 显示三到六条，使用最新、最有帮助或文档化的代表性方法。切勿仅选择五星记录而暗示它们代表整个语料库。
• 引文保持忠实。 将摘录保持在15–60个词。仅在一个自然边界处截断，标记省略，保留原始含义，并在政策允许的情况下提供通往完整评论的路径。
• 标签说明可证明的内容。 仅当系统验证了该事件时使用"已验证购买"或"已验证预约”。“已验证评论"过于模糊，除非验证过程已被定义。
• 语气保持中立。 优先使用"客户评论"而非"为什么每个人都爱我们”。该块呈现证据；附近的散文可以解释背景，而无需赞美或贬低评论者。
• 时效性保持可见。 显示评论日期和导入的最后同步日期。来自废弃数据源的当前评分并非当前证据。
• 审核不是为了赞美而策展。 根据已发布的政策删除垃圾内容、禁止内容或私人数据。不要因为批评降低平均值而删除批评，也不要重写评论以加强主张。

切勿将员工背书、合成引文、以客户话语呈现的AI生成摘要、机密细节、未公开的激励条款、未经支持的结果声称、竞争对手攻击或法律反驳放入块内。生成的专题摘要只能作为引号外清晰标注的分析出现，附有公开方法和通往原始记录的路径。

使用该块的帖子类型

frontmatter中的postTypes数组是规范的关系。“条件性"意味着仅当存在真实的、与实体匹配的评论记录且放置有助于页面决策时，该块才出现。

QA检查清单

• 该块是否汇总了真实的客户反馈，而非模仿推荐语或编辑结论？
• 在块出现之前，是否已确定一个精确的被评实体？
• 每条记录是否来自经批准的、可追溯的来源，并具有稳定的评论ID？
• 资格筛选、审核、归一化和去重策略是否有文档记录？
• 平均值、计数、分布、摘录和来源细分是否使用相同的符合条件的集合？
• 评分是否以数字形式显示，并附有其最佳和最差的评分标准值？
• 分布的总和是否等于符合条件的评论数量？
• 三到六条摘录是否通过声明的方法选择，而非仅凭赞美程度？
• 摘录是否在不暴露私人数据的情况下保留了含义、归属、日期和验证状态？
• 激励、赠品、雇佣关系和其他实质性关系是否在适用时披露？
• 当计数为零时，该块是否呈现真实的零状态或什么都不显示？
• 在零状态下是否省略了AggregateRating？
• 任何输出的AggregateRating是否与可见的实体、值、计数、评分标准、来源范围和快照精确匹配？
• 单个Review对象是否仅限于可见的、符合条件的评论记录？
• 在政策允许的情况下，来源或完整评论集是否可供检查？
• last-synced是否对于页面的时效性政策足够新，过期的数据源会显式失败或抑制该块？
• 星形、分布、筛选和展开状态是否具有完整的文本和键盘等效项？
• 该块是否与冲突的评分、不相关的实体、强制性的紧迫感和未标记的推荐语分离？
• 页面是否避免了未经支持的最高级、捏造的引文和模糊的"已验证"标签？
• 编辑者能否根据来源记录和文档化的计算重现显示的聚合？

当一个持怀疑态度的读者能够理解被评价的是什么、存在多少证据、证据来源以及其局限性，并且机器接收到相同的事实而不会在标记中隐藏第二个夸大版本时，评论块才算准备就绪。