5个Claude Code Skill，把产品经理的反馈分析从45分钟压到了10分钟

你有没有过这种经历？打开Claude Code，告诉它分析一份CSV反馈数据，按主题分类，统计频率，提取引文。它照做了，结果还不错。但下次你再做同样的事，又得重新说一遍。

说白了，你每次都在教它同样的流程。一次两次还行，做多了真的心累。

Skill这个东西就是来解决这个问题的。

什么是Skill？

Skill其实就是一个文件夹，里面装了一个叫 SKILL.md 的指令文件。你只需要把工作流程定义一次------输入什么、怎么处理、输出什么格式、质量标准是什么------下次你再说帮我分析反馈，Claude Code 会自动匹配到对应的Skill，直接按流程执行，不用你重新解释。

举个例子：第一次做反馈综合花了45分钟。但你把流程做成Skill之后，第二次只需要10分钟，第三次也是10分钟，第四次还是10分钟。每次省下的时间都是白赚的。

下面给你准备了5个现成的入门Skill，都是产品经理最常用到的场景。

五项必备Skill

每个Skill建好之后，每次调用能帮你省下20到40分钟。

Skill 1：反馈综合器

它能干什么？ 把客户给你的各种反馈（支持工单、NPS评分、调查数据）整理成有分类、有统计、有引用的报告。

什么时候用？

季度末做反馈审查，为路线图规划找方向
发布新功能后分析用户反应
给各种功能请求排优先级
跟老板汇报客户洞察的时候

怎么工作的？ 你把CSV或文本文件丢给这个Skill，它会自动分类、统计每类问题出现的次数、判断用户情绪，最后生成一份带证据的结构化报告。

SKILL.md 长这样：

bash 复制代码

 ---
 name: feedback-synthesizer
 description: 将CSV或文本文件中的客户反馈综合成主题报告，包含频率分析和支持性引述。当用户提及反馈分析、客户洞察、NPS综合或支持工单主题时自动调用。
 ---

bash 复制代码

 # 反馈综合Skill

 ## 目的
 分析非结构化的客户反馈，生成结构化主题报告，用于路线图规划和洞察综合。

 ## 预期输入
 - 包含反馈文本列的CSV文件（支持工单、NPS回复、调查数据）
 - 反馈项之间以空行分隔的纯文本文件
 - 多个需要综合分析的反馈来源

 ## 处理流程

 1. 读取所有提供的反馈文件
 2. 识别重复出现的主题（通常10-15个不同主题）
 3. 统计每个主题的出现频率
 4. 评估每个主题的情感倾向（正面/负面/中性/混合分布）
 5. 提取代表性引述（每个主题3-5条）
 6. 根据频率和严重程度语言对主题进行优先级排序

 ## 输出格式
 生成一份Markdown报告：`feedback/theme-report-[date].md`

 结构：
 - **执行摘要**：按频率排序的前3个主题，按严重程度排序的前3个主题
 - **详细主题**：每个主题一个章节，包含：
   - 主题名称和描述
   - 频率计数和百分比
   - 情感分布
   - 代表性引述
   - 建议行动或调查领域
 - **交叉模式**：经常同时出现的主题
 - **微弱信号**：值得关注的低频主题

 ## 质量标准
 - 除非被标记为关键，否则主题必须至少在5条反馈中出现
 - 引述必须是实际逐字摘录，而非转述
 - 频率计数必须准确
 - 情感评估基于实际使用的语言，而非假设
 - 报告长度控制在6页以内以保证可读性

 ## 常见陷阱
 - 不要创建过多主题，合并相似概念
 - 不要偏向近期反馈，平等分析所有数据
 - 没有文本证据时不要推断情感

可以自定义的地方：

主题出现多少次才算值得关注（默认5次）
用预设的分类还是让AI自动发现主题
要不要做情感分析
报告要多长

怎么用： 直接说"分析 data/q1-2026-feedback.csv 中的反馈并创建一份主题报告"，Claude Code 会自动匹配Skill并执行。

Skill 2：竞争情报扫描器

它能干什么？ 把你的产品和竞争对手放在一块对比------功能、价格、市场定位。

什么时候用？

每季度更新一次竞争格局
看自己的产品和对手比缺了什么功能
调整定价策略的时候
做市场定位研究

怎么工作的？ 你告诉它对手的名字和要比什么，它会自动研究每个对手，做成对比表格，还会生成文档存档。

SKILL.md 长这样：

bash 复制代码

 ---
 name: competitive-intel
 description: 生成结构化的竞争分析，比较产品在功能、定价和定位方面的差异。当用户提及竞争分析、竞争对手比较、市场格局或功能差距分析时自动调用。
 ---

bash 复制代码

 # 竞争情报扫描Skill

 ## 目的
 为路线图规划和战略定位创建系统化的竞争分析报告。

 ## 预期输入
 - 竞争对手名称或URL列表
 - 比较维度（功能、定价、定位、目标市场）
 - 需要更新的现有竞争文档（可选）

 ## 流程
 1. 针对每个竞争对手，收集以下信息：
    - 核心功能与能力
    - 定价模式与层级
    - 目标市场与定位
    - 相对于我方产品的优势与劣势
 2. 创建跨竞争对手的比较矩阵
 3. 识别功能差距（对方拥有而我方缺失的功能）
 4. 识别差异化机会（我方拥有而对方缺失的功能）
 5. 总结战略意义

 ## 输出格式
 在 `research/competitors/` 中生成Markdown文件：
 - 每个竞争对手生成 `competitor-[name]-profile.md`（详细档案）
 - `competitive-matrix-[date].md`（比较表格）
 - `competitive-summary-[date].md`（战略分析）

 比较矩阵格式：
 - 行：功能类别或评估标准
 - 列：竞争对手加上我方产品
 - 单元格：✓（具备功能）、✗（缺失功能）、~（部分/有限）或描述文字

 ## 质量标准
 - 信息必须是最新的（检查来源日期）
 - 定价必须包含所有层级，而不仅仅是基础价格
 - 功能比较必须对等（相同能力，而非仅名称相同）
 - 避免偏见，准确呈现竞争对手的优势
 - 包含可验证的来源

 ## 更新频率
 每季度运行一次，或在以下情况触发：
 - 主要竞争对手发布重大产品
 - 定价发生变化
 - 战略定位需要调整

可以自定义的地方：

比什么（功能、价格、目标市场、用户体验）
追踪多少个对手
多久更新一次
输出格式（表格还是文章）

怎么用： "更新竞争对手A、竞争对手B和竞争对手C的竞争分析，重点关注定价和企业级功能。"

Skill 3：发布说明生成器

它能干什么？ 根据Git提交记录和Jira工单，自动写发布说明，而且是用用户能看懂的语言。

什么时候用？

每月或每季度发版公告
新功能上线后通知用户
维护更新日志
写客户邮件

怎么工作的？ 你给个版本号或日期范围，它自动看Git提交记录，挑出跟用户有关的变更，分类整理，然后用产品语言写出来。

SKILL.md长这样：

bash 复制代码

 ---
 name: release-notes
 description: 根据Git历史记录和Jira工单生成面向客户的发布说明，使用产品语言风格。当用户提及发布说明、更新日志、版本说明或功能公告时自动调用。
 ---

bash 复制代码

 # 发布说明生成器Skill

 ## 目的
 为产品更新和功能发布创建一致且对客户友好的发布说明。

 ## 预期输入
 - 版本号或标签（例如 "v2.5.0" 或Git标签）
 - 日期范围（例如 "自上次发布以来的提交" 或 "2026年1月1日至31日"）
 - 可选的Jira筛选器或工单列表，用于提供额外上下文

 ## 流程
 1. 读取指定范围内的Git提交记录
 2. 识别面向用户的变更（过滤掉内部重构、依赖更新）
 3. 对变更进行分类：
    - **新增**：新功能或新能力
    - **变更**：对现有功能的改进
    - **修复**：错误修复
    - **移除**：已弃用或移除的功能
 4. 使用产品语言（而非技术术语）撰写描述
 5. 将相关变更分组
 6. 按用户影响排序（影响最大的优先）

 ## 输出格式
 生成 `CHANGELOG.md` 条目或 `docs/releases/[version].md`：

 ## [版本 X.Y.Z] - 年-月-日
 ### 新增
 - [以用户语言描述的功能]
 ### 变更
 - [改进描述]
 ### 修复
 - [用通俗语言描述的错误修复]
 ### 移除
 - [已弃用的功能，附迁移指南（如有需要）]

 ## 语言风格与语气
 - **面向客户，而非技术性**："批量用户导入现在支持最多1,000个用户"，而非"增加了MAX_IMPORT_SIZE常量"
 - **以收益为导向**：解释用户现在可以做什么，而不仅仅是改变了什么
 - **清晰简洁**：通常每个变更一句话
 - **主动语态**："新增仪表盘自定义功能"，而非"仪表盘自定义功能已被添加"

 ## 质量标准
 - 仅包含影响用户体验的变更
 - 每个变更无需阅读提交信息即可理解
 - 相关变更应分组列出，而非单独列出
 - 已移除的功能应注明替代方案或迁移路径
 - 版本号和日期必须准确

 ## 常见模式
 - 内部重构 → 排除，除非影响性能
 - 依赖更新 → 排除，除非增加面向用户的能力
 - 未发布功能中的错误修复 → 排除（与客户无关）
 - 破坏性变更 → 明确标出，并附迁移指南

可以自定义的地方：

语气风格（正式还是随意）
分类方式
输出形式（更新日志、邮件还是App内公告）
内部版本和对外版本分开

怎么用： "根据自 v2.4.0 以来的提交记录，生成版本 2.5.0 的发布说明。"

Skill 4：PRD 审核员

它能干什么？ 拿着检查清单帮你审PRD文档，看有没有遗漏或前后矛盾的地方。

什么时候用？

启动开发前过一遍PRD
发给各方确认之前做检查
交给开发团队之前再看一眼
季度性的PRD质量检查

怎么工作的？ 你把PRD文件丢给它，它会检查该有的章节是不是都有，内容够不够清楚，有没有模糊的地方，最后给出一份带评分的审计报告。

SKILL.md 长这样：

bash 复制代码

 ---
 name: prd-auditor
 description: 审查 PRD 文档的完整性、清晰度和一致性。当用户提及 PRD 审查、需求审计、PRD 检查清单或规格验证时自动调用。
 ---

bash 复制代码

 # PRD 审核员Skill

 ## 目的
 在工程启动前系统性地审查 PRD 文档，确保其完整性。

 ## 预期输入
 - PRD Markdown 文件路径（例如 `docs/prds/feature-name.md`）
 - 可选的自定义检查清单或评分标准

 ## 处理流程
 1. 读取 PRD 文档
 2. 检查必需章节：
    - 概述与成功指标
    - 用户角色与使用场景
    - 功能性与非功能性需求
    - 用户体验/工作流程
    - 技术方案
    - 不涉及范围
    - 待定问题
    - 成功标准
 3. 评估每个章节：
    - **完整性**：关键细节是否齐全？
    - **清晰度**：是否无歧义？
    - **具体性**：需求是否可测试/可衡量？
    - **一致性**：各章节是否对齐（例如成功指标与需求匹配）？
 4. 标记问题：
    - 缺失章节
    - 模糊或含混的需求
    - 标记为"待定"的未解决待定问题
    - 不可衡量的成功指标
    - 缺少实现细节的技术方案
 5. 对 PRD 就绪程度进行总体评分（就绪 / 需完善 / 不完整）

 ## 输出格式
 在 PRD 中或单独文件中生成审计报告评论。

 ## 评分方法
 **就绪**：所有必需章节齐全且完整，严重问题少于 2 个
 **需完善**：必需章节齐全但存在关键缺口（3-5 个严重问题）
 **不完整**：缺少必需章节或存在 6 个以上严重问题

 ## 检查清单自定义
 默认检查清单可通过在同一目录下包含 `PRD_CHECKLIST.md` 文件来覆盖，以定义自定义要求。

可以自定义的地方：

检查哪些章节（根据你们团队的PRD模板来）
评分标准
什么算严重问题

怎么用： "审计位于 docs/prds/bulk-import.md 的 PRD，并告诉我缺少什么。"

Skill 5：用户故事扩展器

它能干什么？ 你给一个功能概念，它能结合代码库的实际情况，帮你扩展成完整的用户故事，连验收标准和边界情况都写好。

什么时候用？

冲刺规划前准备用户故事
把大功能拆成小任务
界定功能范围
交给开发团队之前

怎么工作的？ 你告诉它"我想做一个XX功能"以及目标用户是谁，它会去代码库里看看现有的模式和限制，然后按你们团队的格式写出用户故事。

SKILL.md 长这样：

bash 复制代码

 ---
 name: user-story-expander
 description: 将功能概念扩展为包含验收标准、技术说明和边界情况的详细用户故事。当用户提及用户故事、故事扩展、验收标准或史诗拆解时自动调用。
 ---

bash 复制代码

 # 用户故事扩展器Skill

 ## 目的
 基于代码库上下文和技术约束，为功能生成全面的用户故事。

 ## 预期输入
 - 功能描述（2-3句话说明要构建什么）
 - 目标用户角色或用户类型
 - 功能必须支持的核心工作流
 - 可选：要追加到的现有用户故事文件

 ## 处理流程
 1. 探索代码库以获取技术上下文：
    - 与该功能区域相关的现有模式
    - 验证规则和约束条件
    - 可参考的类似功能
    - 潜在的集成点
 2. 生成5-8个用户故事，涵盖：
    - 核心正常路径工作流
    - 变体（不同用户类型、场景）
    - 错误处理和边界情况
    - 管理/配置需求（如适用）
 3. 每个故事包含：
    - 用户故事陈述（作为X，我想要Y，以便Z）
    - 验收标准（具体、可测试）
    - 技术说明（受影响的文件/模块、要遵循的模式）
    - 边界情况（边界条件、错误状态）
 4. 按用户价值对故事进行优先级排序

 ## 输出格式
 生成或追加到 `docs/user-stories/[feature-name].md`

 ## 质量标准
 - 故事必须以用户为中心（而非以实现为中心）
 - 验收标准必须可测试（而非模糊）
 - 技术说明必须引用代码库中的实际文件
 - 边界情况必须基于代码库约束切实可行
 - 覆盖率：典型场景的80%（并非每个可能的边界情况）

 ## 故事格式
 使用标准的"作为/我想要/以便"格式，除非团队有自定义模板。

可以自定义的地方：

故事格式（如果团队有自定义模板）
生成多少条故事
技术细节写到多深
要不要包含工作量估算

怎么用： "将批量用户导入功能扩展为企业管理员角色的用户故事。"

这5个Skill就是你的入门工具包。花一次时间建好，以后每次遇到同样的工作，直接用就完了。

每个Skill都能把原来30到60分钟的手工活，压缩到10分钟内自动搞定，而且输出的质量是稳定的------不会这次写成这样、下次又写成那样。