Fabric 产品反馈分析实战：用 analyze_product_feedback 模式把用户声音整理成优先级决策清单-育师

Fabric 产品反馈分析实战：用 analyze_product_feedback 模式把用户声音整理成优先级决策清单

【免费下载链接】FabricFabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere.项目地址: https://gitcode.com/GitHub_Trending/fa/Fabric

本文围绕 Fabric 开源框架内置的analyze_product_feedback模式（模式源文件）展开，讲解它如何将零散的产品用户反馈汇总、聚类、评估并输出为按优先级排序的决策清单。读完本文，你将掌握该模式的完整设计逻辑、在 Fabric CLI 中的调用方式、评分体系与输出规范，并能结合源码理解模式在框架中的加载与执行机制，直接用于产品迭代与需求排期。

模式定位：为产品负责人把反馈"翻译"成决策

analyze_product_feedback是 Fabric 内置 patterns 集合中的一员，位于 data/patterns/analyze_product_feedback/system.md。按照模式文件的 IDENTITY and PURPOSE 描述，它把一个 AI 助手定义为"专门分析产品用户反馈的专家"：处理并组织反馈数据、识别并合并相似反馈、基于有用性对合并后的反馈进行优先级排序。其核心产出是"一份清晰、简洁、按优先级排列的用户反馈视图"，目的是帮助产品负责人与产品经理在充分掌握反馈全貌的前提下做出明智决策。

这与 Fabric 的项目定位一脉相承：Fabric 将 AI 的"基础单元"——提示词——按真实世界任务进行组织，让人们把最重要的 AI 解决方案收集、整理到一处（见 README 的 What and Why 章节）。analyze_product_feedback正是"任务型模式"的典型代表：它不是一个通用聊天提示，而是一套可重复执行的、面向具体业务问题（产品反馈分析）的完整工作协议。

模式文件要求助手"退后一步，按下面的步骤逐步思考，以取得最佳结果"（Take a step back and think step-by-step），这一设计强调分析过程的结构化，而非一次性给出直觉式结论。

七步工作流：从原始反馈到优先级清单

模式文件在 STEPS 章节明确规定了处理用户反馈的完整流程，共七个环节，环环相扣：

收集与汇总：把所有用户反馈收集、汇集成单一数据集；
主题识别：逐条分析每条反馈，识别其中的关键主题或话题；
相似分组：基于识别出的主题，将相似反馈归为一组；
合并摘要：为每个分组生成一条合并摘要，抓住该组反馈的实质；
有用性评估：根据频率、对用户体验的影响、与产品目标的一致性、实现可行性等因素，评估每个合并反馈组的"有用性"；
优先级评分：为每个合并反馈组分配一个优先级分数；
降序排序：按优先级分数从高到低对合并反馈组排序，并以带摘要与分数的清单呈现。

这一流程本质上是一条"数据清洗 → 主题聚类 → 价值评估 → 排序输出"的分析流水线。值得强调的是第 5 步中列出的四个评估维度——频率（frequency）、用户体验影响（impact on user experience）、与产品目标的一致性（alignment with product goals）、实现可行性（feasibility of implementation）——它们共同决定了"有用性"这一综合指标，避免了仅凭反馈条数多少做决策的片面性。

从实现角度看，Fabric 的 CLI 在收到--pattern参数后，会经由 internal/cli/flags.go 中的Pattern字段（第 29 行）与 internal/cli/chat.go 的handleChatProcessing构造 ChatRequest，把模式内容作为系统提示词连同用户输入一起发送给模型（见 BuildChatRequest）。因此模式文件中的 STEPS 会被原样注入模型的系统上下文中，模型即按此协议执行分析。

输出规范：结构化 Markdown 表格

模式的 OUTPUT INSTRUCTIONS 章节对输出格式做了非常具体的约束，这是保证"任何模型、任何厂商"都能产出统一格式结果的关键：

只输出 Markdown（Only output Markdown）；
使用表格呈现优先级反馈；
表格必须包含四列：Priority Rank（优先级排名）、Consolidated Feedback Summary（合并反馈摘要）、Usefulness Score（有用性评分）、Key Themes（关键主题）；
表格按Priority Rank 降序排列；
在 Consolidated Feedback Summary 列内使用项目符号列出要点；
Usefulness Score 采用1–10 分制，10 分为最有价值；
Key Themes 限制为3–5 个词或短语，以逗号分隔；
表格之前需要简要说明评分体系与优先级排序方法。

这里可以推断（模式原文中"Assess the usefulness…"与"Assign a priority score…"两步骤在措辞上有所重叠）：优先级排名（Priority Rank）是排序后的最终位次，而有用性评分（Usefulness Score）是计算排名的底层量化依据；文章要求先交代评分方法再给出表格，正是为了让读者能独立理解排名是如何得出的。

这套输出规范还有一个工程上的好处：结构化表格天然适合被下游工具继续处理。例如配合 Fabric CLI 的-c/--copy参数（见 flags.go）可以把结果直接复制到剪贴板，或配合-o/--output参数将 Markdown 表格写入文件，再粘贴进需求文档、Notion、Jira 或 Obsidian 等工作流中。

输出结构速查

输出要素	规范要求
输出格式	仅 Markdown
呈现方式	表格
表格列	Priority Rank、Consolidated Feedback Summary、Usefulness Score、Key Themes
排序规则	按 Priority Rank 降序
摘要列	使用项目符号列出要点
评分制	1–10 分，10 分最有价值
主题数量	3–5 个词/短语，逗号分隔
表前说明	需先解释评分体系与优先级排序方法

输入约定：INPUT 标记与反馈数据的注入

模式文件末尾的 INPUT 章节以INPUT:结尾（其后为%占位标记）。这是 Fabric 模式文件的标准结构——INPUT标记之后的位置即用户输入（待分析的反馈文本）被注入的地方。实际使用时，反馈数据既可以来自文件重定向、管道，也可以作为命令行参数传入。

在 Fabric CLI 中运行该模式

基本用法

analyze_product_feedback与 Fabric 中所有模式一样，通过-p/--pattern参数调用（该参数定义见 internal/cli/flags.go）：

# 从文件读取反馈并分析 fabric --pattern analyze_product_feedback < feedback.txt # 通过管道传入反馈数据 cat feedback.csv | fabric -p analyze_product_feedback # 以流式输出即时查看分析过程 cat feedback.txt | fabric -p analyze_product_feedback --stream # 把结果直接复制到剪贴板 cat feedback.txt | fabric -p analyze_product_feedback --copy # 把结果保存为 Markdown 文件 cat feedback.txt | fabric -p analyze_product_feedback -o feedback-analysis.md

其中--stream、--copy、--output等参数均定义在 internal/cli/flags.go 中（分别见第 37、48、52 行）。在 internal/cli/chat.go 的handleChatProcessing中可以看到，--copy会将模型返回结果写入系统剪贴板，--output会将结果写入指定文件，方便与笔记库、需求管理系统对接。

常用辅助参数

参数	作用	定义位置
`-l, --listpatterns`	列出所有可用模式	internal/cli/flags.go
`--readpattern analyze_product_feedback`	在终端打印该模式的完整内容	internal/cli/flags.go、internal/cli/listing.go
`--dry-run`	只预览发送给模型的完整提示词，不实际调用 API	internal/cli/flags.go
`-m, --model`/`-V, --vendor`	指定模型与厂商	internal/cli/flags.go
`-g, --language`	指定输出语言（如`-g=zh`）	internal/cli/flags.go
`-t, --temperature`	控制生成随机性（默认 0.7）	internal/cli/flags.go
`--strategy`	叠加提示策略（如`cot`、`self-refine`）	internal/cli/flags.go

一个值得介绍的调试技巧是--dry-run：在真正消耗 API 额度前，先用它确认模式内容与输入是否正确拼接。例如：

cat feedback.txt | fabric --dry-run -p analyze_product_feedback

为该模式指定专用模型

如果希望反馈分析任务始终走某个特定模型，可以利用 Fabric 的"按模式映射模型"机制：在 internal/cli/chat.go 中，当指定了--pattern而未指定--model时，CLI 会读取环境变量FABRIC_MODEL_<模式名大写、连字符替换为下划线>。因此可以这样配置：

export FABRIC_MODEL_ANALYZE_PRODUCT_FEEDBACK="openai|gpt-4o"

这样每次调用该模式都会自动使用对应厂商与模型，无需重复传参（该特性在 README 的 Per-Pattern Model Mapping 章节也有说明）。

叠加提示策略增强分析严谨性

Fabric 支持在模式之上叠加提示策略（strategies），例如链式思考cot、自我修正self-refine等，策略文件存放在 data/strategies 目录。反馈分析这类需要多步推理的任务，叠加策略可以进一步提升步骤执行的严谨性：

cat feedback.txt | fabric -p analyze_product_feedback --strategy cot

策略会作为系统提示词的补充一并发送给模型，机制说明见 README 的 Prompt Strategies 章节。

源码视角：模式文件如何被加载与执行

从源码层面看，Fabric 的模式加载由 internal/tools/patterns_loader.go 负责：PopulateDB会从配置的 Git 仓库（默认路径data/patterns）拉取全部模式到本地~/.config/fabric/patterns目录，movePatterns与createUniquePatternsFile分别完成模式目录落盘与模式名清单（unique_patterns.txt）的生成。因此analyze_product_feedback这个目录下的system.md在安装/更新后被读取、编目，并在你执行fabric -p analyze_product_feedback时作为系统提示词被装载。

执行链大致为：cmd/fabric/main.go→ internal/cli/cli.go 的Cli()→handleChatProcessing→BuildChatRequest将PatternName写入请求 → 底层 Chatter 读取模式内容并与用户消息拼接后发送给所选模型。整个链路保证"模式即系统提示词、输入即用户消息"的一致语义。

把该模式改造为自己的私有版本

Fabric 支持自定义模式目录（详见 README 的 Custom Patterns 章节）。若希望在官方模式基础上增加本公司特有的评估维度（例如合规风险、竞品对比），可以复制一份改造：

mkdir -p ~/my-custom-patterns/product-feedback-plus cp data/patterns/analyze_product_feedback/system.md ~/my-custom-patterns/product-feedback-plus/system.md

然后在fabric --setup中配置自定义模式目录，之后即可用fabric --pattern product-feedback-plus调用。自定义模式优先级高于内置模式，且不会被fabric --updatepatterns覆盖。

实战演示：从反馈原文到决策表格

以下为演示示例（反馈内容为虚构数据，用于展示模式的执行效果）。假设收集到的原始反馈包括：

"App 每次启动都要转 5 秒，太慢了，差点以为卡死了"
"希望把启动页的广告去掉，太影响体验"
"昨晚更新后闪退两次，之前从没遇到过"
"Android 版闪退频率明显比 iOS 高"
"能不能加个夜间模式？晚上看太刺眼"
"其他竞品都有夜间模式，我们也想要"
"iOS 深色模式下部分按钮看不清"

按模式要求，模型会先输出一段评分体系与优先级排序方法的简要说明，再给出如下形式的表格（演示格式）：

Priority Rank	Consolidated Feedback Summary	Usefulness Score	Key Themes
1	- 更新后出现闪退，Android 用户受影响最严重 - 属回归性缺陷，直接影响核心功能可用性	10	稳定性, 闪退, 回归缺陷
2	- 启动耗时约 5 秒，用户感知明显 - 启动页广告加剧等待焦虑	8	启动性能, 加载速度, 启动广告
3	- 夜间模式需求呼声较高，且与竞品功能对齐 - iOS 深色模式下部分按钮对比度不足	6	夜间模式, 深色模式, 可访问性

可以看到：频率最高的"闪退"被排在最前，因为它同时命中"频率"与"对用户体验的影响"两个高权重维度；而"夜间模式"虽不紧急，但兼具用户呼声与竞品对齐价值，被排在第三位。

评估维度与最佳实践

模式第 5 步给出的四个评估维度可作为团队评审反馈时的统一标尺：

频率（Frequency）：被多少用户、在多少场景下提及。高频反馈通常代表普遍痛点，但也需警惕幸存者偏差；
用户体验影响（Impact on User Experience）：问题对核心流程的破坏程度。阻塞型缺陷（如闪退、无法登录）天然权重更高；
产品目标一致性（Alignment with Product Goals）：该反馈是否服务于当前阶段的北极星指标与路线图；
实现可行性（Feasibility of Implementation）：在现有架构与资源下落地的成本与风险，低可行性高价值项应单独规划。

在实践层面，建议注意两点：

原始反馈要保留上下文：模式输出的是"合并摘要"，因此建议把原始反馈原文存档（可用-o输出分析结果、另存原文），便于回溯与复核；
评分一致性：由于 1–10 分制依赖模型主观判断，对同一批数据多次运行时结果可能波动。如果需要长期跟踪，可将分析结果与版本号、日期一同归档，观察评分随产品迭代的变化趋势。

小结

analyze_product_feedback是 Fabric 中"任务型系统提示词"的典型代表：它把产品反馈分析这一高频业务动作，固化为"收集 → 聚类 → 评估 → 排序 → 表格输出"的可重复协议，并通过严格的输出规范保证结果的结构化与可消费性。结合 Fabric CLI 的管道输入、流式输出、按模式映射模型与自定义模式机制，它可以无缝嵌入产品团队每周的反馈评审流程，让 AI 负责"整理与排序"，让人负责"拍板与执行"。

进一步的参考资料：模式源文件、Fabric 使用说明、CLI 参数定义、模式加载实现、配置文件示例。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考