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 长这样：
---
name: feedback-synthesizer
description: 将CSV或文本文件中的客户反馈综合成主题报告，包含频率分析和支持性引述。当用户提及反馈分析、客户洞察、NPS综合或支持工单主题时自动调用。
---
# 反馈综合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 长这样：
---
name: competitive-intel
description: 生成结构化的竞争分析，比较产品在功能、定价和定位方面的差异。当用户提及竞争分析、竞争对手比较、市场格局或功能差距分析时自动调用。
---
# 竞争情报扫描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长这样：
---
name: release-notes
description: 根据Git历史记录和Jira工单生成面向客户的发布说明，使用产品语言风格。当用户提及发布说明、更新日志、版本说明或功能公告时自动调用。
---
# 发布说明生成器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 长这样：
---
name: prd-auditor
description: 审查 PRD 文档的完整性、清晰度和一致性。当用户提及 PRD 审查、需求审计、PRD 检查清单或规格验证时自动调用。
---
# 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 长这样：
---
name: user-story-expander
description: 将功能概念扩展为包含验收标准、技术说明和边界情况的详细用户故事。当用户提及用户故事、故事扩展、验收标准或史诗拆解时自动调用。
---
# 用户故事扩展器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分钟内自动搞定，而且输出的质量是稳定的——不会这次写成这样、下次又写成那样。
浙公网安备 33010602011771号