企业官网建设流程全解析

pm-skills 用户反馈分析实战：用 /analyze-feedback 命令把海量反馈转成结构化洞察

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

/analyze-feedback是 pm-skills 市场（PM Skills Marketplace）中pm-market-research插件提供的一条命令式工作流，专门解决产品经理"反馈太多、洞察太少"的问题：它把应用商店评论、NPS 问卷、支持工单、调查回复等大规模非结构化文本，转化为带情感评分、主题聚类和用户分群的结构化分析报告。读完本文，你将掌握这条命令的完整调用方式、四步分析工作流、底层依赖的 sentiment-analysis 技能的实现细节，以及如何把分析结果继续衔接到用户画像、需求分级和深度访谈等后续环节。

命令定位：它是谁，解决什么问题

在 README.md 中，pm-market-research被定义为"市场研究插件"：用户画像、市场细分、情感分析和竞争分析。该插件一共包含7 个技能（Skills）和 3 条命令（Commands），其中三条命令分别是：

• /research-users—— 综合用户研究（用户画像 + 分群 + 旅程地图），对应 research-users.md
• /competitive-analysis—— 竞争格局分析，对应 competitive-analysis.md
• /analyze-feedback—— 用户反馈情感分析与分群洞察，即本文主题，对应 analyze-feedback.md

在 pm-skills 的架构中，技能（Skill）是构建块，承载领域知识与分析框架；命令（Command）是用户主动触发的端到端工作流，负责把若干技能串联起来。/analyze-feedback正是这种设计的一个典型例子：它本身不重复实现分析逻辑，而是把核心分析委托给 sentiment-analysis 技能，命令只负责定义"接收什么输入 → 问什么问题 → 输出什么报告 → 推荐什么下一步"。

调用方式（Invocation）

/analyze-feedback支持三种典型输入形态，对应 analyze-feedback.md 中的调用示例：

/analyze-feedback [upload a CSV of NPS responses] /analyze-feedback [paste app store reviews or survey responses] /analyze-feedback [upload support ticket export]

即：

• 上传结构化文件：例如 NPS 回复的 CSV 导出；
• 直接粘贴文本：应用商店评论、问卷回复、Slack 里的用户反馈；
• 上传文档/导出包：来自反馈工具（如 Zendesk、Intercom）的支持工单导出。

根据 README.md 的安装说明，在 Claude Code 中安装pm-market-research插件后即可使用这条命令：

claude plugin marketplace add phuryn/pm-skills claude plugin install pm-market-research@pm-skills

说明：在 Claude Code / Cowork 中命令以/command-name触发，例如/analyze-feedback；部分环境下也可使用带插件前缀的全限定名/pm-market-research:analyze-feedback。命令文件是 Claude 特有的（slash-command 语法），但技能文件skills/*/SKILL.md遵循通用技能格式，可复制到 Gemini CLI（.gemini/skills/）、OpenCode（.opencode/skills/）、Cursor（.cursor/skills/）等其他工具中仅作为技能使用。

Step 1：接收反馈数据

命令启动后首先进入数据接收阶段，接受任意格式的反馈输入：

• CSV/Excel：包含反馈文本，以及可选的元数据列（日期、用户分群、评分等）；
• 粘贴文本：评论、问卷回复、Slack 消息等；
• 上传文档：反馈工具导出的文件。

在正式分析前，命令会主动澄清三个问题，以确保分析方向与用户诉求一致（这部分对应 analyze-feedback.md 的 Step 1）：

1. 这是什么类型的反馈？（NPS、评论、支持工单、问卷……）——不同类型反馈的分析口径不同，例如 NPS 有专门的 0-10 分群规则；
2. 是否有需要单独分析的分群维度？（用户层级、套餐、地域……）——为后续 Segment Analysis 提供切片依据；
3. 你希望从中得到什么？（总体主题、特定问题、随时间变化的趋势……）——决定分析是"广撒网"还是"定点深挖"。

这一步的价值在于：它把模糊的"分析一下反馈"需求，收敛成带明确分析口径和输出预期的任务，避免生成一份方向错误的报告。

Step 2：分析 —— 底层 sentiment-analysis 技能拆解

数据分析阶段由sentiment-analysis技能承担。该技能的定义文件 SKILL.md 中写明其用途是"大规模分析用户反馈数据，识别市场分群、衡量满意度、发现产品改进机会"，并明确要求分析者以"专家级用户研究员与反馈分析师"的身份工作。命令层面对技能能力的调用体现在五个分析动作上：

技能的六步分析流程

技能内部定义了"逐步思考"（Think Step by Step）的六步流程，可作为命令行为的底层实现参照：

1. 数据摄取（Data Ingestion）：读取所有反馈来源，建立工作清单；
2. 分群识别（Segment Identification）：从反馈中识别至少 3 个不同的用户分群或画像；
3. 主题分析（Thematic Analysis）：提取每个分群中反复出现的主题、痛点与正面反馈；
4. 情感评分（Sentiment Scoring）：为每个分群的总体满意度分配 -1 到 +1 的情感分数；
5. 影响评估（Impact Assessment）：按频次、严重程度与业务影响对洞察排序；
6. 综合输出（Synthesis）：形成带统一洞察的分群画像。

值得注意的是，技能层面的情感评分采用-1 到 +1 的连续区间，而命令层面的报告模板采用positive/neutral/negative 三分法与百分比——两者并不矛盾：三分法是对连续分数的聚合呈现，技能还同时要求给出"情感驱动因素与减分因素"和"NPS 代理指标"（见下节"分群画像结构"）。

技能输出的分群画像结构

对每个识别出的分群，技能要求输出完整的画像，包括：

• 分群画像：名称/标识、在数据集中的用户数或占比、主要使用场景；
• Jobs-to-be-Done：该分群要完成的核心任务、期望的结果；
• 情感分与满意度：总体情感分（-1 到 +1）、满意度驱动/减分因素、适用的 NPS 代理值；
• TOP 正面反馈主题：用户喜欢什么、核心优势、成功用例；
• TOP 痛点与批评：最常见的抱怨、未满足的需求、用户旅程中的摩擦点、直接引语；
• 产品-分群适配评估：产品在多大程度上满足该分群需求、改进潜力、流失风险；
• 可执行建议：每个分群 2-3 条高影响改进、速赢 vs 战略举措、优先级建议。

技能的最佳实践要求

SKILL.md 的 Best Practices 节还为命令背后的分析质量设定了底线：

• 所有结论必须建立在真实用户反馈之上，并注明来源；
• 同时呈现分群内的多数派与少数派观点；
• 区分"功能请求"与"根本性痛点"（这也呼应了analyze-feature-requests技能"永远不要让客户设计方案、优先排序机会而非功能"的原则，详见 analyze-feature-requests）；
• 关注用户面临的具体情境与约束；
• 对小样本分群或不确定的情感结论明确标注；
• 寻找跨分群的共性模式与普适痛点；
• 对产品优势与不足给出平衡的呈现。

Step 3：生成分析报告

分析完成后，命令按固定模板输出一份 Markdown 报告。模板完整定义在 analyze-feedback.md 的 Step 3 中，核心结构如下：

## Feedback Analysis Report **Date**: [today] **Feedback analyzed**: [count] responses **Source**: [NPS survey / app reviews / support tickets / etc.] **Period**: [date range if available] ### Overall Sentiment - Positive: [X%] | Neutral: [Y%] | Negative: [Z%] - Average sentiment score: [X/10] - Trend: [improving / stable / declining] ### Top Themes | # | Theme | Mentions | Sentiment | Segments Most Affected | |---|-------|----------|-----------|----------------------| ### Theme Deep-Dive #### Theme 1: [Name] — [X] mentions, [sentiment] - **What users are saying**: [summary with representative quotes] - **Root cause**: [what's driving this feedback] - **Impact**: [how this affects retention, satisfaction, or revenue] - **Recommendation**: [what to do about it] [Repeat for top 5-8 themes] ### Segment Analysis | Segment | Volume | Avg Sentiment | Top Theme | Key Difference | |---------|--------|-------------|-----------|---------------| ### Notable Quotes > "[quote]" — [segment, sentiment] ### Trends Over Time [If date data available: chart-ready data showing sentiment shifts] ### Actionable Insights 1. [Insight + recommended action] 2. ... ### Gaps [What this feedback doesn't tell you — suggested follow-up research]

模板的七个组成部分

1. 报告头：日期、分析条数、来源类型、时间区间——保证报告的来源可追溯；
2. 总体情感（Overall Sentiment）：三分法占比 + 平均情感分（模板按 10 分制展示，与技能内部的 -1~+1 评分互为换算口径）+ 趋势判断；
3. TOP 主题表（Top Themes）：主题、提及次数、情感、受影响最大的分群；
4. 主题深挖（Theme Deep-Dive）：对 TOP 5-8 个主题逐一展开"用户在说什么（含代表引语）→ 根因 → 对留存/满意度/收入的影响 → 建议"，这是把"知道了什么"升级为"该做什么"的关键环节；
5. 分群分析（Segment Analysis）：各分群的体量、平均情感、头号主题与关键差异；
6. 代表性引语（Notable Quotes）：保留原始声音，标注分群与情感；
7. 可执行洞察与缺口（Actionable Insights & Gaps）：洞察必须绑定建议动作；Gaps 节则诚实说明"这份数据没告诉你什么"，并建议后续补充研究。

输出产物

• 报告保存为Markdown文件；
• 如果输入是结构化数据（如 CSV），额外输出一份带情感评分列（enriched）的 CSV，方便用户拿到自己的工具里继续做透视分析或建模。这一设计对应命令 Notes 中的明确要求："当输入为结构化数据时输出 enriched CSV，以便用户在自己的工具中使用。"

Step 4：推荐后续动作

命令分析完成后并不会就此结束，而是主动衔接 pm-skills 生态中的后续工作流，原文档给出了三个衔接方向：

• 创建用户画像（user personas）：基于反馈中暴露的行为模式与需求，交给 user-personas 技能产出 3 个带 JTBD、痛点、收益与意外洞察的画像；
• 需求分级（triage feature requests）：把 TOP 主题作为特性请求交给 triage-requests 命令做主题聚类、战略对齐评估与优先级排序；
• 设计深度访谈脚本（interview script）：针对某个具体主题，用 interview-script 技能生成遵循The Mom Test原则（不引导、不推销、聚焦过去行为）的结构化访谈脚本。

这种"命令之间相互衔接"的设计正是 README.md 中强调的：命令按 PM 工作流设计，一条命令完成后会建议相关的下一条命令，用户顺着提示即可连续推进整个研究流程。与之并列的research-users命令（research-users.md）则从另一角度切入：它把同样的输入素材转成用户画像、行为分群与客户旅程地图，两者可互为补充——一个从"反馈文本"入手做情感与主题，一个从"全量研究素材"入手做人-群-旅程。

注意事项与使用边界

原文档的 Notes 部分是命令内置的"质量控制条款"，也是读者在使用时应主动遵守的边界：

• 情感分析是近似值：必须主动标注边缘情况——讽刺（sarcasm）、混合情感、非英语文本都会显著影响判断准确性；
• 主题提取应寻找需求而非表面话题：用户提出"想要深色模式"时，真正的需求可能是"夜间使用场景下的可读性"；主题聚类应当下沉到需求层，而不是停留在字面层；
• 小样本分群需标注置信度：如果某个分群样本量过小，必须注明"置信度有限"，避免把噪声当信号；
• NPS 数据要按三段拆解：对 NPS 数据必须分别分析Detractors（0-6 分）、Passives（7-8 分）与Promoters（9-10 分），三段人群的行为含义完全不同；
• 结构化输入必须输出 enriched CSV：让用户能把带情感分的增强数据拿到自己的 BI 或分析工具中继续使用。

这些边界同时与底层技能的最佳实践形成呼应：sentiment-analysis 技能要求"标注小样本或情感不确定的分群"、"同时呈现多数派与少数派观点"，命令层的 Notes 正是把这些要求落到报告输出层面的体现。

实战组合建议：把反馈分析接入完整研究闭环

基于以上实现，一个推荐的使用路径是把/analyze-feedback放到研究流水线的中游：

1. 上游：先用 research-users 建立用户基线认知，或在访谈后把 interview-script 产出的访谈记录作为反馈输入之一；
2. 中游：运行/analyze-feedback处理规模化的问卷/评论/工单数据，得到情感分布、主题排名与分群差异；
3. 下游：TOP 主题交 triage-requests 进入需求池，行为模式交 user-personas 沉淀为画像，存疑之处再用 interview-script 做定性深挖。

需要注意的是，命令本身不包含任何运行时依赖或离线模型：全部分析由接入的 AI 助手按技能指令实时执行，情感评分的可靠性依赖提示词约束（技能要求"基于真实反馈、注明来源、标注边缘情况"），因此在解读输出时，应把报告中的"情感分、NPS 代理值、主题频次"视为模型推断结果而非统计软件输出，并结合 Gaps 节做人工复核——这正是原文档把"情感分析是近似值"写入 Notes 的根本原因。

小结

/analyze-feedback在 pm-skills 中的价值不在于引入新的算法，而在于把"分析海量反馈"这一高频高价值任务固化成了一条可重复、可追溯、可衔接的工作流：命令层定义输入口径、澄清问题、报告模板与后续衔接；技能层（sentiment-analysis）提供 -1~+1 情感评分、主题聚类、分群画像与影响排序的方法论。两者结合，使产品经理可以在几分钟内把数千条评论或工单变成一份"总体情感 + 主题深挖 + 分群差异 + 可执行建议 + 数据缺口"的完整报告，并顺势进入画像、分级、访谈的下一环研究。

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills