Fabric analyze_comments 模式详解：用结构化 Prompt 完成互联网评论的情感分析

Fabric 仓库中的 analyze_comments 是一个面向「内容评论区」的官方 Prompt 模式（Pattern），其定义文件位于 system.md。读完本文，你将理解该模式的完整提示词结构与输出契约（情感五级量表、固定分节的 15 词摘要等设计意图），掌握在 Fabric CLI 中加载与调用该模式的方式，并能看到它在 Fabric 模式加载器、文件系统约定与模式索引中的落点，最终可以把它复用到自己的「受众反馈分析」流水线中。

模式定位：它是 Fabric 中的什么

在 Fabric 的体系里，每一个「模式」就是 data/patterns/ 下的一个目录，目录内以 system.md 存放系统提示词，可选地以 user.md 存放用户侧模板。文件系统层面的命名约定由插件层的数据库实现给出：从源码结构看，db.go 中硬编码了 SystemPatternFile: "system.md"，测试代码 patterns_test.go 同样围绕这一约定展开。analyze_comments 目录只包含一个 system.md，即它是一个纯系统提示词模式：用户只需把任意一段「内容 + 评论」文本作为输入传入即可，不需要额外的用户模板。

仓库内对这个模式有统一的官方描述，可作为检索锚点：

• pattern_explanations.md 第 9 条：analyze_comments: Evaluate internet comments for content, categorize sentiment, and identify reasons for praise, criticism, and neutrality.（评估互联网评论的内容，归类情感，并识别褒扬、批评与中立的原因）
• suggest_pattern/user.md 将其一句话概括为：Analyze user comments for sentiment, extract praise/criticism, and summarize reception.
• 自动抽取的元数据 pattern_descriptions.json 为它打上了 ANALYSIS 与 EXTRACT 两个标签，说明它被归入「分析 + 信息抽取」类。

系统提示词逐节拆解

analyze_comments 的 system.md 全文仅 21 行，但结构完整，由 IDENTITY、GOAL、STEPS、OUTPUT 四节构成。下面按原文顺序完整继承并解释每一节。

IDENTITY：专家角色设定

You are an expert at reading internet comments and characterizing their sentiments, praise, and criticisms of the content they're about.

这一句定义了模型的角色能力：阅读网络评论，并刻画评论者对所讨论内容的情感、赞美与批评。注意措辞是 "characterizing"（刻画/归纳），而非简单打分——这为后面「既要给整体情感档位、又要给出理由」的输出契约埋下伏笔。

GOAL：无偏评估

Produce an unbiased and accurate assessment of the comments for a given piece of content.

目标是「无偏且准确」地评估给定内容的评论。"unbiased" 在这里有两层含义：一是模型不应代入自己对该内容的主观好恶；二是在正面与负面证据之间保持权重均衡，避免被少数极端评论带偏。

STEPS：逐条判定的工作流

Read all the comments. For each comment, determine if it's positive, negative, or neutral. If it's positive, record the sentiment and the reason for the sentiment. If it's negative, record the sentiment and the reason for the sentiment. If it's neutral, record the sentiment and the reason for the sentiment.

工作流是一个「先逐条、后聚合」的两阶段过程：

1. 读完所有评论（"Read all the comments"）；
2. 对每条评论做三分类：positive / negative / neutral；
3. 对每一条，无论属于哪一类，都要同时记录两样东西：情感极性（sentiment）与情感理由（reason）。原文把同一句 "record the sentiment and the reason for the sentiment" 在三类下重复书写，这是 Prompt 工程中常见的冗余强调手法——确保模型不会对 neutral 评论偷懒跳过理由记录。

这条 STEPS 是最终输出的来源：POSITIVES/NEGATIVES 分节中的理由，实际上来自这一步逐条积累的 "reason for the sentiment"。

OUTPUT：四个固定分节与严格格式契约

这是该模式最重要的部分，它规定了四节输出，每节都有精确的数量与长度约束：

输出分节	内容要求	约束
COMMENTS SENTIMENT	对「评论者整体喜欢该内容」的评估	必须从五级量表取值：HATED、DISLIKED、NEUTRAL、LIKED、LOVED
POSITIVES	评论者喜欢该内容的点	恰好 5 个 bullet，每条为 15 词的英文句子
NEGATIVES	评论者不喜欢该内容的点	恰好 5 个 bullet，每条为 15 词的英文句子
SUMMARY	透过评论者视角对内容的总体评估	15 词的一句话

原文的关键句逐条列出（完整继承自 system.md）：

• In a section called COMMENTS SENTIMENT, give your assessment of how the commenters liked the content on a scale of HATED, DISLIKED, NEUTRAL, LIKED, LOVED.
• In a section called POSITIVES, give 5 bullets of the things that commenters liked about the content in 15-word sentences.
• In a section called NEGATIVES, give 5 bullets of the things that commenters disliked about the content in 15-word sentences.
• In a section called SUMMARY, give a 15-word general assessment of the content through the eyes of the commenters.

输出契约的设计意图

与 Fabric 仓库中其他「带评分」的模式对照，可以更清楚地看到 analyze_comments 的格式设计是有意为之的：

• 五级情感量表（HATED / DISLIKED / NEUTRAL / LIKED / LOVED）是一个离散的、以 NEUTRAL 为中轴的对称量表。相比之下，同属分析类的 analyze_debate（system.md）使用的是 0–10 的 INSIGHTFULNESS SCORE 和 0–5 的 EMOTIONALITY SCORE。五级枚举的取值集合封闭，便于下游程序做字符串匹配或再次让 LLM 做结构化提取；而 0–10 数值尺度则表达细腻度更高。analyze_comments 选择封闭枚举，换取的是输出可判定性。
• **「恰好 5 个 bullet、每条 15 词」**是一种强制凝练约束。15 词大约是一句完整但不冗长的陈述，迫使模型把「某条评论说……」的原始引语压缩成「评论者群体认为……」的归纳句；5 个 bullet 的上限则防止模型把每条评论都罗列一遍。实际使用时，如果真实正面/负面主题不足 5 个，可以推断模型会基于已有证据做概括性补足——这也是该模式的局限：对评论量很少（例如只有 1–2 条）的内容，"5 条" 约束会放大少数评论的权重。
• **「SUMMARY 也是 15 词」**使最终结论与每条评价句处于同一信息密度级别，整份报告的各节粒度一致，适合作为长内容（视频、文章、播客）受众反馈的标准摘要单元。

在 Fabric 中加载与调用该模式

模式的来源：从仓库克隆到本地配置目录

Fabric 的内置模式不是随二进制打包，而是由模式加载器从 Git 仓库拉取到本地配置目录。关键实现位于 patterns_loader.go：

• 默认仓库与目录常量：DefaultPatternsGitRepoFolder = "data/patterns"（patterns_loader.go#L19-L20），即本仓库的 data/patterns/ 目录就是被下载的分发源，analyze_comments 因此是官方内置模式之一；
• PopulateDB()（patterns_loader.go#L87-L124 所在文件中的 L87 起）先创建临时目录，调用 gitCloneAndCopy() 拉取 data/patterns 前缀下的文件，再 movePatterns() 拷贝进本地配置目录，并创建一个空文件作为 "loaded" 标记；
• 自定义模式保留机制：PersistPatterns()（patterns_loader.go#L127-L171）在更新模式下会把「本地存在但新下载中不存在」的目录视为自定义模式并拷贝保留。这解释了为什么你完全可以仿照 analyze_comments 的写法在本地新增一个评论分析模式目录，更新内置模式时也不会丢失。

命令行调用

CLI 层支持通过 --pattern 参数指定模式名运行交互式会话，测试用例 chat_test.go 中就有以 "summarize" 作为 patternName 的构造，第 304 行附近展示了 --pattern summarize 的命令行形式。对本文的模式而言，等价的调用方式即为把模式名换成 analyze_comments：

fabric "把一段视频的全部评论区文本粘贴在这里，包括视频主题背景" --pattern analyze_comments

输入建议：该模式没有 user.md 模板，输入完全由你自由提供。为了让 "15 词句子" 与 "5 条 bullet" 有足够证据支撑，实践中应提供足量、原始、带上下文的评论文本（而非已筛选的摘要），并在开头用一两行说明被评论内容的主题——因为 GOAL 要求评估的是「for a given piece of content」的评论，缺少内容背景时，COMMENTERS 的情感指向会含糊。

通过 suggest_pattern 找到它

如果你不确定该用哪个模式，Fabric 提供了 suggest_pattern 模式做路由，其内部清单（suggest_pattern/user.md）收录了 analyze_comments 条目。自动抽取脚本的产物 pattern_extracts.json 中保留了该模式 system.md 的完整文本快照，与当前 data/patterns/analyze_comments/system.md 逐字一致，可作为模式内容变更前的基线参考。

与其他反馈类模式的边界

data/patterns/ 下有几个容易混淆的相邻模式，使用时可按输入类型区分：

• analyze_product_feedback（system.md）：面向产品用户反馈，按主题归纳、合并相似评论、按有用性排序，偏「产品改进」视角；
• analyze_debate（system.md）：输入是辩论全文，输出含洞察度/情绪度双评分，偏「论证质量」视角；
• analyze_comments：输入是任意内容下的评论集合，输出聚焦「受众情感分布 + 群体视角总结」，是最直接对应「评论区舆情」场景的模式。

小结与使用要点

• analyze_comments 是一个极简但契约严格的模式：21 行提示词定义了角色、无偏目标、逐条情感判定工作流，以及由 COMMENTS SENTIMENT（五级量表）、POSITIVES（5×15 词）、NEGATIVES（5×15 词）、SUMMARY（15 词）构成的固定输出格式（system.md）。
• 加载与调用由 Fabric 的模式加载器（patterns_loader.go）和 system.md/user.md 文件约定（db.go）支撑；自定义模式在更新时会被 PersistPatterns() 自动保留。
• 适用前提：输入应为较完整的原始评论文本；评论数量过少时，「5 条」硬性约束会导致结论代表性下降，解读报告时应以 COMMENTS SENTIMENT 档位为主、bullet 内容次之。