评分卡：基于固定标准的透明评级

评分卡是一种紧凑的评估块，它基于一组固定标准对一个主体进行评分，并使用既定方法将这些分项分数合并。它将结论变成可核查的计算结果，而非要求读者盲目相信一个显眼的数字。

仅为说明性示例。所涉及的产品和观察数据均为虚构。量度：0–10，0 表示标准未满足，10 表示完全满足。

为什么这个元素很重要

读者对评分持合理怀疑态度，因为一个数字背后可能隐藏着数十种编辑选择。评判了哪些品质？是否以相同方式对每个主体进行了评判？某个方便商业推广的功能是否掩盖了严重缺陷？评分卡通过将结论、标准、权重和证据保留在一起，减少了这种不确定性。它帮助读者在认同事实的同时可以不同意其中的优先级：比起集成能力，更关心支持服务的读者可以看明白，为什么公布的分数可能不适合自己的决策。

只有当方法先于数字的权威性出现时，这种心理机制才有效。大数字暗示了测量，小数位暗示了可重复性。如果没有披露评分细则和计算方法，“8.3/10"不过是穿着实验室外衣的意见。公布量度锚点、证据规则、权重和舍入策略，赋予精确度以合法来源，并使编辑判断透明可见，而非假装其不存在。

机器可提取性意味着自动化系统可以保留被评分的内容、每条标准的含义、评分量度以及分项分数与总分之间的关联。一个孤零零的"7.7"是模糊的：它可能是用户评分、测试结果或版本号。一个包含明确主体和量度的基于文本的表格，能够展示稳定的字段-值对。爬虫和 AI 问答系统可以引用一个有边界的主张，例如"在五项任务测试中可用性得分为 7.5/10”，而不会让数字脱离其依据。

根据元素写作规则 ，功能为评分评估的块必须使用类型化的评分卡约定。一排式风格化徽章并不等同。类型化元素保留了方法学，支持权重和总分的验证，并确保跨发布系统的输出一致性。

何时使用

当一个或多个主体已根据相同的稳定评分细则进行评估，并且所得分项分数有助于读者理解结论时，使用评分卡。适当的输入包括经文档记录的测试、已映射到需求的经过验证的规格说明、基于已公布锚点的专家检查，或上述来源的明确定义组合。当读者在看到标准分解后可能做出不同选择时，评分卡就发挥了其价值。

方法必须在评分开始之前就已存在。定义主体、资格规则、标准、权重、量度锚点、证据来源、测试条件、缺失数据处理规则和舍入规则。在整个评估周期内冻结这些条件。如果方法中途发生变化，则需重新评分每个受影响的主体，或将结果标识为不应直接比较的不同版本。

常见的偏差包括：

• 未评分的功能矩阵。 如果任务是展示功能是否存在，请使用对比表 。加上分数可能会扭曲本应是事实性而非评估性的差异。
• 单一度量指标。 页面速度、价格、响应时间和电池续航已有其单位。报告测量值和相关基准即可；不要将其转换为任意的星级评分。
• 用户评论汇总。 客户平均分有不同的作者、采样条件和偏差控制机制。应将其显示为有来源的汇总，而非出版物的评分卡。
• 检查清单。 通过八项要求中的六项并不自动等于 7.5/10 的评分。某些要求可能是强制性的且不可补偿的，即其他方面的优势不能弥补失败。
• 获胜者徽章。 “编辑推荐"传达了结论但未说明推理过程。它可以跟在评分卡之后，但不能替代评分卡。
• 看到产品后才创建的排名。 为证明偏爱的获胜者而选择的标准是事后合理化论证，而非可重复的评估。

当各标准之间无法合理互相补偿时，请勿使用总分。例如，严重的安全故障通常应触发排除或明确的失败状态，而非被吸引人的设计平均掉。在这种情况下，请分别公布通过/失败门槛和剩余的描述性评估。

放置位置

在页面已说明主体、评估目的、受众、测试日期和简洁的方法说明之后，放置第一个评分卡。在评测页面上，这通常位于摘要结论之后、详细标准章节之前。在对比页面上，先介绍一次共同的评分细则，然后按照页面通篇使用的主体顺序呈现评分卡。在基准报告中，在展示任何评分实体之前，先解释评估对象群组和数据周期。

仅当方法在评分卡之前立即可见，或可通过邻近的描述性方法链接获取时，该元素才能出现在靠近页面顶部的位置。在读者了解被评分的内容之前，评分不能领先于页面。详细证据可以随后呈现，但每一行仍需包含简短证据摘要或直接链接到相关章节。

请勿将评分卡直接放在星级评分汇总、推荐语、价格促销、联盟营销按钮或"获胜者"横幅旁边。这些元素可能使编辑判断看起来受商业驱动，或导致读者混淆不同的评分体系。请勿将两个不同量度的评分卡并排放置。在评分卡与密集图表或第二套评分系统之间至少保留一个说明段落，且切勿在方法说明与其评分卡之间插入广告。

结构

标注图必须标识以下区域：

1. 主体： 被评估的具体产品、公司、页面、服务或版本。
2. 总分： 计算结果，始终与其分母或量度一同显示。
3. 方法摘要： 谁在何时使用何种证据和测试条件进行了评估。
4. 量度锚点： 最小值、中点和最大值的含义；不仅仅是"满分 10 分”。
5. 标准标签和定义： 一个稳定的评估维度及其覆盖范围的边界。
6. 权重： 该标准对总分的贡献度，包括明确的等权说明。
7. 分项分数： 该标准在声明量度上的结果。
8. 证据摘要： 证明该分项分数合理性的观察或来源。
9. 计算和舍入说明： 用于生成显示总分的公式。
10. 日期和版本： 评估执行时间以及被测试的主体版本或方案。
11. 披露： 任何商业关系、提供的访问权限或重大测试限制。

设计示例

每种变体都保留相同的核心约定。视觉压缩可能减少每行的说明，但不能删除方法、权重、量度或证据访问入口。

加权标准型： 评测和购买决策的默认类型。当各标准重要性不同时使用。展示每项权重并确认它们总计 100%。

等权紧凑型： 当编辑方法赋予每条标准相同影响力时适用。“等权"必须可见；省略权重并不等于等权。

对比型评分卡： 适用于两个或三个主体在同一个冻结的评分细则下评分。标准保持为行，主体保持一致的顺序。对于更多主体，使用单独的卡片或带证据链接的对比表，以确保移动端阅读体验。

门槛型评分卡： 当强制条件可以覆盖加权总分时使用。在可选标准之前说明门槛，并显示"不推荐——强制安全要求未通过”，而非允许高分平均值暗示已通过评估。

不完整或未评分状态： 仅在缺失证据属实且策略已预先定义的情况下使用。将该标准标记为"未测试"，说明原因，并要么不显示总分，要么显示一个临时总分，其分母和重新加权方式须明确。切勿暗中赋零或重新分配权重。

参数

标准 0–10 模型的公式为 total = Σ(subscore × weight as a decimal)。验证必须拒绝负权重、百分比合计不等于 100%、分项分数超出量度范围，以及手动输入的总分与计算结果不一致的情况。渲染器可以计算总分，但存储的标准和权重仍然是权威输入。

语法和代码示例

以下所有实现均代表同一虚构评估。它们保留了方法、日期、量度、项目顺序、权重、证据和舍入策略。

可移植 Markdown 指令

:::scorecard{subject="Acme Support Desk" scaleMin=0 scaleMax=10 dateEvaluated="2026-08-20" rounding=one-decimal}
## 产品评估

我们测试了五项标准支持任务，并根据评估日期生效的文档验证了所需控制项和集成能力。

::item{weight=30 subscore=8}
### 安全控制

必需控制项已记录；两项高级控制项不可用。
::
::item{weight=25 subscore=7.5}
### 可用性

五项既定任务已测试；一项需要重复导航。
::
::item{weight=25 subscore=9}
### 集成覆盖度

二十项必需集成中已支持十八项。
::
::item{weight=20 subscore=6}
### 支持服务

邮件回复满足发布的 SLA；无电话渠道。
::
:::

Hugo shortcode

Hugo 适配器应仅接受父级和项目调用上的命名参数。以下记法是一种可移植的实现规范，并不表示此仓库中已存在渲染器。

{{< scorecard subject="Acme Support Desk" scale-min="0" scale-max="10" evaluated="2026-08-20" rounding="one-decimal" >}}
## 产品评估

我们测试了五项标准支持任务，并根据当前文档验证了控制项和集成能力。

{{< score criterion="Security controls" weight="30" value="8" >}}必需控制项已记录；两项高级控制项不可用。{{< /score >}}
{{< score criterion="Usability" weight="25" value="7.5" >}}五项既定任务已测试；一项需要重复导航。{{< /score >}}
{{< score criterion="Integration coverage" weight="25" value="9" >}}二十项必需集成中已支持十八项。{{< /score >}}
{{< score criterion="Support" weight="20" value="6" >}}邮件回复满足发布的 SLA；无电话渠道。{{< /score >}}
{{< /scorecard >}}

WordPress 块

<!-- wp:amicited/scorecard {"subject":"Acme Support Desk","scaleMin":0,"scaleMax":10,"dateEvaluated":"2026-08-20","rounding":"one-decimal"} -->
<!-- wp:amicited/score {"criterion":"Security controls","weight":30,"subscore":8} -->
<p>必需控制项已记录；两项高级控制项不可用。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Usability","weight":25,"subscore":7.5} -->
<p>五项既定任务已测试；一项需要重复导航。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Integration coverage","weight":25,"subscore":9} -->
<p>二十项必需集成中已支持十八项。</p>
<!-- /wp:amicited/score -->
<!-- wp:amicited/score {"criterion":"Support","weight":20,"subscore":6} -->
<p>邮件回复满足发布的 SLA；无电话渠道。</p>
<!-- /wp:amicited/score -->
<!-- /wp:amicited/scorecard -->

WordPress 编辑器应计算总分，而非邀请手动输入。当权重合计不等于 100% 时应阻止发布，当项目缺少证据或测试版本时应发出警告。

示例

正确：可复现的加权判断

Acme 客服平台：7.7/10，评估日期 2026 年 8 月 20 日。 安全控制得分 8.0（权重 30%）；可用性 7.5（权重 25%）；集成覆盖度 9.0（权重 25%）；支持服务 6.0（权重 20%）。每个分项分数都与已记录的要求或五项任务测试相关联。总分是加权分项分数的总和，最后统一保留一位小数。

这样做是正确的，因为另一位编辑可以使用相同的评分细则、证据和公式，并在标准层面解释任何分歧。小数位由加权输入合理支撑。结果受日期和测试条件约束，因此不暗示永久的产品质量。

错误：逆向工程出的数字结论

Acme 客服平台：9.3/10。 功能 9.5，价值 9.0，体验 9.4。“我们的专家考虑了所有重要方面。”

这样做是错误的，因为各标准相互重叠且缺乏定义、权重、锚点、证据、测试日期或计算方法。没有价格、方案、受众和替代方案，“价值"就无法解释。“体验"可能包括可用性、支持服务或两者兼有。未经说明的小数暗示了方法无法产生的精确度。修复方法需要：在评估前定义评分细则，收集标准层面的证据，披露权重分配，并根据已记录输入计算总分——而非选择平均后能得到期望标题的分项分数。

Schema 标记和无障碍

评分卡没有通用的 Schema.org 类型。默认情况下，将其作为页面有效实体和文章标记中的可见内容保留。当真实的评测评估特定的合格项目时，可使用 Review 和 Rating 标记。如果使用，ratingValue、bestRating 和 worstRating 必须与可见的总分和量度一致；评测作者、被评测项目、日期和支持性评测内容也须同时存在。公司基准、编辑框架或抽象概念的评分卡，仅仅因为包含一个数字并不会自动符合条件。

请勿将每条标准标记为单独的 Review，也勿将单一位编辑的计算结果用作 AggregateRating。汇总代表多个评分，需要可见的数量和适当的来源。切勿将外部用户平均分暗中混入编辑总分，而不将两套系统分别展示。如果页面引用大量资料，请使用来源块 使更广泛的证据集可被检查。

就无障碍而言，当读者需要跨列比较标准时，应使用实表。提供包含主体和总分的标题、列标题、行标题和 tfoot 计算行。当颜色、图标和图形计量器消失时，相同信息必须仍然可用。不要仅宣布"绿色"或"五颗实心星"作为状态；应展示"8/10”。

进度条可以补充文本但不能替代文本。为任何有意义的计量器提供可访问的名称、当前值、最小值和最大值。在移动端保留源顺序，而不是将每列转换为无标签的堆叠。工具提示不能承载必需的证据，因为键盘、触摸和纯文本用户可能永远无法获取。避免使用 role="alert"、自动轮播和动画计分：评分是静态编辑内容，而非实时系统事件。

写作规则

在发布结果之前解释评估的原因。指明受众和评分所支持的决策，因为适用于小团队的"最佳"标准可能对受管制的企业是错的。在详细分析之前或之中，用一句话定义每条标准。各标准必须足够独立，避免同一观察被重复计分。

使用三到七个标准。少于三个通常退化为简单对比；超过七个则使总分难以审计，并助长琐碎的区分。标准标签使用二到八个词。证据摘要使用 8–40 词，陈述观察结果而非宣传性形容词。“企业方案支持 SAML SSO"是证据；“安全性卓越"只是重复判断。

公布量度锚点。对于 0–10 量度，至少为每条标准或真正共享的评分细则定义 0、5 和 10。中点必须描述一个可测试的状态，而非"一般”，除非比较人群和统计数据已定义。将所有主体保持在同一量度和评分细则版本上。

权重必须透明。显示每个百分比，确保总和为 100%，并说明权重较高的标准对所指定受众更为重要的原因。等权也是权重，必须声明。请勿按主体更改权重，也勿允许赞助身份、联盟佣金、产品访问权限或偏好结果影响权重。

使用未舍入的分项分数进行计算，然后对最终结果进行一次舍入。默认显示一位小数。仅当输入评分细则能够可靠区分该精度时，才能使用两位小数；否则它们只是制造信心。将分母放在每个分数旁边，并区分百分比和分值。

切勿在评分卡内放置未经证实的赞美、销售 CTA、定价紧迫性、推荐语、用户评分星标或未披露的商业关系。请勿将不合格的失败隐藏在脚注中。请勿将缺失证据视为中立的中间值。标明"未测试”，遵循预定义的缺失数据规则，并在无法进行公平计算时扣留总分。

使用此元素的文章类型

postTypes 前置元数据是该映射的来源。包含某项意味着该格式在存在稳定评分细则和标准层面证据时可以支持评分卡，并不要求每个页面都包含评分。

QA 检查清单

• 主体、版本或方案、评估日期、受众和决策均已明确。
• 方法在评分前已定义并可重复应用。
• 存在三到七个具有可测试定义的独立标准。
• 每条标准都有可见的权重，所有权重总计恰好为 100%。
• 量度锚点说明了最小值、中点和最大值的含义。
• 每条分项分数都有证据摘要和可追溯的来源或测试观察。
• 强制门槛不能通过可选标准的优势被平均掉。
• 总分根据分项分数和权重计算，然后仅舍入一次。
• 显示的精度由输入的粒度支撑。
• 缺失证据遵循已披露的策略，且从不被暗中计为零分或平均分。
• 商业关系、提供的访问权限和重大限制均已披露。
• 评分卡未放置在用户星标、推荐语、促销或冲突量度旁边。
• 表格标题、表题、阅读顺序、文本等效内容和移动端重排均可无障碍使用。
• 结构化数据（如有）与可见的主体、作者、评分和量度一致，并符合页面类型要求。
• 所选文章类型出现在 postTypes 中，且周边文章提供了详细证据。

FAQ

每个评分卡都必须使用加权标准吗？

每个评分卡都必须说明各标准如何贡献总分。等权是有效的，但仍需明确披露。如果某些标准更重要，应公布每项权重，并确保权重总和为 100%。

评分卡应包含多少个标准？

使用三到七个。四或五个通常足够覆盖评估范围，而不会制造虚假的精确感。如果评估需要超过七个，可将详细检查归入较少的评分标准之下，并单独发布完整的评分细则。

评分卡可以使用小数吗？

可以，前提是输入数据和计算方式能够支持。默认情况下，显示的总分最多保留一位小数，说明舍入规则，切勿仅为让主观判断显得有据可查而添加小数位。

用户评论可以用于编辑评分卡吗？

仅当用户评论作为明确命名的输入，并披露其来源、样本量、收集周期及对公式的贡献时方可使用。不得将第三方用户评分重新标记为编辑评分，也不得将其与测试结果暗中混合。

评分卡是否符合评论或评分结构化数据的条件？

并非自动符合。只有当页面评测的是符合条件且明确识别的对象，且可见的评分、量度、作者和支持性内容满足相关结构化数据要求时，才适合使用评分标记。