评论 开发者 文档
评论 开发者 文档
评论是在 FaceFlow 中用于收集、审核和呈现公开反馈的结构化模型。
它们允许技术团队将与声誉相关的内容作为受治理的网站输出进行管理，而不是作为无管控的自由形式推荐。
核心职责
一个评论模型负责：
- 可配置的评论模型
- 评分字段
- 公开提交的收集
- 审核与验证策略
- 可嵌入的展示输出
- 发布控制
这使评论适用于需要公众可见性和运营控制的信任驱动型网站版块。
核心评论模型
一个评论模型通常包含：
- 核心的评论身份字段
- 评分字段
- 可选的自定义评分维度
- 审核设置
- 验证行为
- 展示与输出设置
在实践中，评论层既定义了可以收集哪些反馈，也定义了哪些已批准的反馈可以发布回网站。
Conceptually:
{
"name": "customer-success-reviews",
"fields": [
{ "name": "author_name", "type": "text", "required": true },
{ "name": "rating", "type": "rating", "required": true },
{ "name": "review_title", "type": "text", "required": true },
{ "name": "review_content", "type": "textarea", "required": true }
],
"settings": {
"moderation": "required",
"verification": "optional"
}
}提交与发布流程
从高层来看：
- 集中定义一个评论模型
- 通过组件将其嵌入到页面中
- 访客提交反馈
- 应用审核和验证规则
- 已批准的条目被渲染回网站体验中
Conceptually:
review widget render
-> visitor submission
-> pending review state
-> moderation / verification
-> approved review published这就是为什么评论应被视为受治理的公开内容，而不仅仅是另一个输入表单。
评分结构
评论模型可以支持：
- 整体评分
- 评论标题
- 评论内容
- 用于更结构化反馈的自定义评分维度
Example:
overall_rating
service_rating
communication_rating
value_rating仅当额外维度能提升信任度和解释性时再使用。
评论模型示例
技术人员应能够清晰地检查模型结构：
{
"name": "service-review",
"fields": [
{ "name": "author_name", "type": "text", "required": true },
{ "name": "rating", "type": "rating", "required": true },
{ "name": "review_title", "type": "text", "required": true },
{ "name": "review_content", "type": "textarea", "required": true }
],
"settings": {
"moderation": "required",
"verification": "optional"
}
}这有助于团队审查正在收集的内容、必填项，以及该模型可能产生的审核工作量。
审核与验证
审核与验证是评论设计的核心。
技术团队应决定：
- 条目是否需要批准
- 是否需要额外的验证
- 谁负责发布决策
- 如何处理与声誉相关的内容
声誉风险越高，通常应采用越严格的控制措施。
嵌入评论
评论通常通过组件嵌入到页面的部分中。
一个常见的嵌入标记是：
<div data-review-embed="service-review"></div>示例版块：
<section class="customer-proof">
<header>
<h2>What customers say</h2>
</header>
<div data-review-embed="customer-success-reviews"></div>
</section>这样可以保持评论收集和展示的可重用性，同时允许页面将信任内容放在最具影响力的位置。
固定嵌入 与 字段驱动嵌入
有两种常见的嵌入模式。
当模板应始终渲染某个特定的评论模型时，使用固定的托管评论模型 id：
<div data-review-embed="customer-success-reviews"></div>当组件暴露了一个 reviewSelect 字段，并且作者应在创作时选择托管的评论模型时，使用字段驱动的嵌入：
<div data-review-embed="{serviceReview}"></div>决策规则：
- fixed embed -> 由模板拥有的稳定信任工作流
- field-backed embed -> 可重用的组件，作者可选择评论工作流
集成模式
清晰的运行时路径是：
Review model
-> Component embed via reviewSelect or explicit data-review-embed marker
-> Page composition
-> public submission, moderation, and approved display output这样可以将与声誉相关的工作流逻辑集中，而不是散布在一次性页面标记中。
运营指南
良好的评论设计通常偏好：
- 每个业务场景一个评论模型
- 明确的审核归属
- 仅在确实有价值时使用结构化评分维度
- 足够简短的提交体验以保持质量
- 支持信任而非噪音的发布模型
如果评论模型过于宽泛，质量和审核通常会变得更难管理。
评分约定指南
使评分模型与公开流程保持相称。
典型模式：
- 简单信任版块 -> 整体评分 + 标题 + 评论正文
- 服务质量工作流 -> 整体评分加上少量维度，例如服务、沟通或性价比
如果一个简短的公开流程需要过多评分输入，提交质量和完成率通常会下降。
技术指南
- 按业务场景分隔评论模型
- 将审核与验证策略与声誉敏感度对齐
- 保持公开评论收集简短，以维护提交质量
- 将已发布的评论内容视为受治理的输出
- 将评论收集、审核和展示视为一个整体工作流
反模式
避免：
- 用于不相关业务场景的一个巨型评论模型
- 对于简短的公开流程而言评分维度过多
- 在没有明确审核归属的情况下发布
- 将评论视为未管理的推荐并粘贴到组件中
- 在不审查展示和批准模型的情况下设计输入流程
示例构建模式
Review model:
customer-success-reviews
Component:
review-strip
Embed:
<div data-review-embed="customer-success-reviews"></div>该模式保持了信任内容的可重用性和受治理性。