Reviewed-by 区块：专家审阅与资质规则

Reviewed-by 区块标识独立检查页面的合格人员，说明其检查的主张，并记录审阅发生的时间。它是已完成编辑操作证据，而非装饰性的信任徽章。

该示例回答了四个问题：谁审阅了页面，该人为何具备资格，审阅何时发生，以及审阅涵盖了哪些内容。其最后一句话澄清了角色和关系，而非声称一位审阅人就能保证整个页面的准确性。

为什么这个元素很重要

读者在无法亲自验证技术、医学、法律、财务或统计主张时，常常将可见的专业性作为捷径。具名的审阅人可以减少不确定性，但前提是归属信息足够具体以至于可以被质疑。“经专家审阅"要求信任却没有提供证据。而姓名、相关资质、日期和限定范围让读者能够判断审阅是否与他们将要依赖的主张相匹配。

这种心理学机制是双向的。一排缩写字母可能制造权威光环：读者可能假定审阅人测试了产品、批准了每项建议、或对未来更新承担责任。该区块必须通过描述实际的审阅事件及其限制来防止这种过度解读。

机器可提取性意味着软件可以在不依赖附近散文猜测的情况下隔离审阅关系。类型化区块为内容系统提供了审阅人身份、资质、审阅日期和范围的稳定字段。搜索引擎、AI 代理、聚合订阅源、无障碍工具和迁移脚本可以区分审阅人与作者、审阅日期与修改日期、已验证范围与页面其余部分。

遵循目的导向的元素编写规则 。任何其职责是声明独立主题审阅的段落，无论其标题或视觉风格如何，都使用此元素。恰好包含两个名字的作者行并不等同于审阅信息，因为它没有保留两者不同的责任。

何时使用

当可识别的专家已完成有意义的第二人检查，且可能的错误会产生实质性后果时，使用此区块。

• 健康与安全内容： 合格的临床医生或安全专家检查其能力范围内的具体主张、禁忌症、升级建议或操作流程。
• 法律、法规和财务内容： 相关专业人士检查管辖权、生效日期、假设、计算，以及一般信息与个体化建议之间的界限。
• 技术文档： 工程师或产品专家在干净或代表性环境中验证命令、版本支持、先决条件、预期结果和恢复步骤。
• 研究与统计数据： 方法学家、分析师或领域专家检查定义、抽样、转换、计算、局限性，以及结论是否来自数据。
• 决策内容： 当评测、购买指南或成本指南中的事实主张超出作者能力范围时，主题专家检查评估标准和事实主张。

触发条件是已完成的审阅，而非仅凭话题严肃性。页面不会因为专家被抄送邮件、提供引语、批准大致主题或审阅了早期版本而获得此区块。咨询可以为文章提供信息，但咨询不是独立审阅，除非该人收到了相关的最终材料，检查了明确的范围，提交了审查结果，并授权了归属。

近似但不达标的情况包括：语法编辑、自我审阅、客户推荐、来源引述、免责声明和管理层批准。这些都不能证明主题核查。职位高级别不代表资质：CEO 并不自动具备验证税务、剂量或统计主张的资格。

当审阅无法被举证时，不使用任何区块。未经归属的"经我们的专家审阅"比不说更糟糕，因为它制造了一个可检验的信任声明，却没有可追责的人、日期或范围。

放置位置

将主要的 reviewed-by 区块放置在源流簇中，直接位于作者归属和时效性标记 之后，开场回答或引言之前。原因在于解释性：读者在开始依赖材料之前，应该知道谁创建和检查了该材料。在移动端、打印版本、阅读器模式和聚合副本中保持此顺序。

当区块对于开场来说过于详细时，在那里呈现一个紧凑行，并链接到位于来源区块 之前的一个展开区块。两者必须使用相同的记录，以确保日期和范围不会产生偏差。

该区块不得与作者简介 合并，因为作者身份和审阅必须是分开的角色。它不能位于推荐语、评测分数、产品优惠、价格、联盟链接、信任徽章条或行动号召的内部或紧邻位置。这些邻居可能使事实审阅看起来像是背书。在审阅归属与商业说服之间保持普通的内容边界。

不要将唯一的归属隐藏在页脚、悬停状态、图片、折叠面板、政策页面或审阅人资料中。页面级区块必须陈述事件和范围。

结构

该区块有七个可识别的区域：

1. 角色标签： 标明"审阅人”、“医学审阅人"或其他明确变体，不将审阅与作者身份混淆。
2. 审阅人姓名： 使用该人的公开职业姓名，并在可用时链接到稳定的资料页面。
3. 相关资质： 仅包含支持本次审阅范围的资格证明。
4. 所属机构或关系： 在有助于读者判断独立性时，标明当前组织或与材料发布者的关系。
5. 审阅日期： 记录对所述范围最近一次完成的审阅。
6. 范围说明： 标明实际检查的主张、计算、操作流程或章节。
7. 角色边界： 澄清有意义的限制、冲突，或说明审阅人未撰写、测试或背书该主题。

将这些标签保留在实时文本中。带注释的截图可以解释设计，但不能成为审阅详细信息的唯一来源。

设计示例

变体改变标签和证据，而非核心数据契约。

标准专家审阅

当领域专家检查准确性和完整性而无需受监管的专业标签时，使用"审阅人”。在资质行中显示学科，并标明审查过的章节。

医学审阅

仅当审阅人持有相关的、有效的健康资质且审阅属于该专业范围时，才使用"医学审阅人"。清晰地展示资质；不要将不同专业压缩为"医生"。

法律或合规审阅

标明被检查的司法管辖区、标准或法规领域，因为法律准确性取决于范围。标签不得暗示代理或个体化建议。

财务审阅

标明审阅人检查的是税务、会计、贷款、保险、投资还是定价主张。宽泛的"财务专家"标签不足以建立相关性。

技术审阅

说明审阅人验证的产品、版本、环境或实施领域。如果执行了命令，请说明；如果审阅是案头研究，不要暗示进行了测试。

方法论与数据审阅

标明被检查的统计或领域方法，包括计算、分母、排除标准和推断限制。除非实际实施了有记录的同侪审阅流程，否则不要称之为同侪审阅。

紧凑渲染使用一行包含标签、姓名、资质和日期，后跟可见的范围句子或链接。展开渲染使用两段短文。两者均不得截断范围。

参数

源记录必须支持紧凑和展开两种渲染方式，且不重复事实。

credentials 记录相关的公共资质，而非每个获得的头衔。scope 是可见且强制性的，因为仅凭姓名无法告知读者被检查的内容。将私人审阅通信保存在组件之外。

语法和代码示例

可移植指令是规范格式。在专门的 Hugo 渲染器存在之前，使用 callout 适配器，同时保留每个规范事实。

可移植 Markdown 指令

:::reviewed-by{reviewType="technical" reviewerName="Alex Rivera" credentials="高级平台工程师" affiliation="北极星云" reviewedOn="2026-08-27" display="expanded"}
## 技术审阅人

范围：安装命令、受支持版本 4.2–4.4、Linux 先决条件、预期输出以及回滚步骤已在干净的 Ubuntu 24.04 和 Debian 13 环境中检查。

审阅人验证了操作流程，但未评估第三方插件或自定义基础设施。
:::

第一个标题映射到 title；第一段映射到 scope；剩余段落映射到 roleBoundary。

Hugo 短代码

{{< callout type="note" title="技术审阅人" >}}**Alex Rivera — 高级平台工程师，北极星云**  
审阅日期：2026年8月27日。范围：安装命令、受支持版本 4.2–4.4、Linux 先决条件、预期输出以及回滚步骤已在干净的 Ubuntu 24.04 和 Debian 13 环境中检查。

审阅人验证了操作流程，但未评估第三方插件或自定义基础设施。{{< /callout >}}

所有 Hugo 参数都是具名的。不要将位置型 callout 类型与具名 title 参数组合使用。

WordPress 区块和短代码

<!-- wp:amicited/reviewed-by {"reviewType":"technical","reviewerName":"Alex Rivera","credentials":"高级平台工程师","affiliation":"北极星云","reviewedOn":"2026-08-27","display":"expanded"} -->
<p>范围：安装命令、受支持版本 4.2–4.4、Linux 先决条件、预期输出以及回滚步骤已在干净的 Ubuntu 24.04 和 Debian 13 环境中检查。</p>
<p>审阅人验证了操作流程，但未评估第三方插件或自定义基础设施。</p>
<!-- /wp:amicited/reviewed-by -->

[reviewed_by review_type="technical" reviewer_name="Alex Rivera" credentials="高级平台工程师" affiliation="北极星云" reviewed_on="2026-08-27"]范围：安装命令、受支持版本 4.2–4.4、Linux 先决条件、预期输出以及回滚步骤已在干净的 Ubuntu 24.04 和 Debian 13 环境中检查。[/reviewed_by]

导入和导出必须保留审阅人角色、日期、范围和边界，即使主题以不同方式呈现。

示例

好示例：有边界的方法论审阅

这个示例有效，因为资质具有相关性，检查内容是具体的，最后一句防止读者将统计审阅扩展到数据收集或购买建议。

差示例：借用的权威

专家验证 ✓ 经 Sam 博士审阅。所有事实准确且已批准。

这个示例失败，因为审阅人无法被识别，“博士"未揭示相关学科，没有日期，且"所有事实"设定了无限范围。对勾标记使一个无根据的治理声明看起来像认证。“批准"也暗示背书，而未说明该人是否检查了证据、计算、安全性、风格，或仅仅看到了草稿。应通过标明审阅人、资质、日期、已审阅的主张、排除领域以及任何重大关系来修复它。

结构化标记和无障碍

对于 WebPage，将真实的审阅人映射到 Schema.org 的 reviewedBy 作为 Person 或 Organization，并将已完成的审阅日期映射到 lastReviewed。可见的姓名和日期必须与结构化值匹配。保持 dateModified 独立：编辑页面和审阅页面是不同的活动，因此一个日期不能自动复制到另一个。

审阅人 Person 在支持时，可以包含稳定的 url、affiliation、knowsAbout 和可验证的 hasCredential。不要虚构资质。除非该人确实也撰写了内容且两个角色均可见，否则不要使用 author。

这不是消费者 Review、评级、推荐语、背书或 ClaimReview。不要从中生成星级、reviewRating、itemReviewed 或产品评测标记。

将区块渲染为语义 <aside> 或按正常顺序排列的带标签区域。使用可见标签作为其无障碍名称，并使用该人的姓名作为链接文本。将资质保留在文本中；仅凭对勾标记不能指示审阅。

组件必须在 200% 缩放时重新排列，并保持姓名-资质-日期-范围的顺序。头像为辅助内容：当相邻文本已命名该人时，使用空的替代文本，且切勿使其成为唯一的链接。静态源流信息不要使用实时状态角色。

编写规则

范围将信任声明转化为可审计的陈述。说明审阅人做了什么。优先使用"已检查”、“已复现”、“已测试”、“已对比”、“已验证"或"已审阅"而非"监督”、“验证了质量"或"确保了卓越”。

使用审阅人的公开职业姓名。列出直接支持范围的一到三个资质，将资质行保持在 120 字符以内。在资料页面或首次出现时拼写出不熟悉的资质。学位、执照、认证、职务或多年的领域实践可以建立相关性；与主题不匹配的声望则不能。

在 12–60 词和一至两句内编写范围。标明具体的主张组、章节、计算、版本、司法管辖区、来源类别或操作流程。每当读者可能合理推断作者身份、实际操作测试、法律代理、背书或比实际发生更广泛的审阅时，添加不超过 35 词的角色边界。

记录审阅人完成所述检查的日期。如果实质性编辑改变了已审阅的主张，要么获得新的审阅和日期，要么在审阅完成之前移除受影响范围的归属。范围之外的文案编辑不会重置审阅日期。通过时效性元素协调页面的发布和修改日期，而不是将审阅默认为发布。

保持语气实事求是。不要论证页面的结论。获得归属同意，并在内部记录版本、范围、发现、解决方案、日期和批准人。

以下内容不得放入 reviewed-by 区块：

• 促销性赞美、推荐语、星级评分、推荐或产品背书；
• 声称审阅人保证准确性、安全性、结果、合规性或未来时效性；
• 不相关的资质、头衔膨胀或不可验证的"专家"标签；
• 完整的审阅人传记、职业经历、联系推销或社交媒体粉丝数；
• 文章结论、新的事实主张、来源或本应属于正文的方法论；
• 私人电子邮件、不供公开的执照号码或内部审阅意见；
• 联盟链接、优惠、价格、通讯订阅表单或其他转化控件。

“独立"需要谨慎对待。它意味着审阅人拥有独立的检查角色和质疑作者的自主权，但并不自动意味着该人与发布者没有财务关系。在可能影响读者判断时，明确说明雇佣、咨询、产品供应或其他重大关系。

使用此元素的文章类型

postTypes 数组创建了机器可读的关系。它标识了专家审阅事件通常能增加实质性保证的格式；但并非每页都需要一个仪式性的审阅人。

当存在相同的风险和已完成的审阅时，其他文章类型也使用该元素。数组中的包含绝不授权发布者在工作完成之前添加审阅人姓名。

QA 检查清单

• 作者以外的其他人已完成对相关页面版本的真实主题审阅。
• 审阅人的专业知识直接匹配所述范围。
• 公开姓名、一到三个相关资质以及任何重大隶属关系准确且可验证。
• 审阅人同意归属及其确切措辞。
• 可见日期记录的是已完成的审阅，而非发布、编辑、批准或预定的未来检查。
• 范围标明具体主张、章节、操作流程、版本、司法管辖区或计算。
• 边界语句防止对作者身份、测试、背书、建议或被排除内容可能产生的混淆。
• “独立”、“同侪审阅”、“已测试”、“已批准"和"已验证"仅在有证据支持这些确切声明时出现。
• 该区块位于作者和时效性信息之下、开场回答之前，或者紧凑归属链接到来源之前的一个同步展开区块。
• 未与作者简介合并，也未仅隐藏在页脚、图片、悬停状态、折叠面板或通用政策页面中。
• 未直接位于推荐语、评分、信任徽章、价格、优惠、联盟链接或行动号召旁边。
• 已审阅范围内的实质性更改触发了重新审阅或移除了过时的归属。
• 内部记录保存了已审阅的版本、范围、发现、解决方案、日期和同意。
• 若使用了 reviewedBy 和 lastReviewed，需与可见的审阅人和日期匹配；dateModified 保持独立。
• 组件不输出消费者 Review、评级、推荐语或产品背书模式。
• 标签、姓名、资质、日期和范围在没有颜色、图标、头像或布局的情况下仍然可理解。
• 审阅人链接使用描述性名称、焦点可见、文本可重新排列，静态内容无 alert 角色。
• Markdown、Hugo 和 WordPress 表示保留相同的规范事实。
• 截图注释仅说明未来的截图；不渲染不存在的图片。

常见问题

reviewed-by 区块和作者简介是同一个东西吗？

不是。作者创建了页面；审阅人独立检查了页面中定义的部分。即使两人资质相似，也要分别标明这两个角色。

每篇文章都需要专家审阅人吗？

不需要。当错误可能实质性影响健康、金钱、法律权利、安全、技术实施或数据驱动结论的有效性时，才使用独立审阅。常规低风险编辑内容通常只需要编辑，而非仪式性的专家署名。

审阅范围应该写什么？

标明实际检查过的主张或章节，例如剂量安全性、税务假设、方法论与计算、或兼容性步骤。避免使用"完全验证"等无限制的措辞，除非审阅人已对照明确标准检查了完整页面。

每次编辑后都需要更改审阅日期吗？

不需要。只有在审阅人重新检查受影响范围时才更改日期。该范围之外的文案编辑不会重置审阅日期，而对已审阅主张的实质性更改会使现有归属失效，直至重新审阅。

员工可以担任独立审阅人吗？

可以，前提是该人未撰写该材料、具备相关专业知识、能够提出质疑，且任何雇佣或商业关系都是可见的。独立审阅描述的是编辑角色，不一定是财务独立。

Reviewed-by 区块只有在展示可追责的工作时才能赢得信任。标明审阅人姓名，将专业知识连接到范围，保留日期，披露有意义的限制，并在已审阅版本不再与页面匹配时移除归属。