你有没有过这种经历打开Claude Code告诉它分析一份CSV反馈数据按主题分类统计频率提取引文。它照做了结果还不错。但下次你再做同样的事又得重新说一遍。说白了你每次都在教它同样的流程。一次两次还行做多了真的心累。Skill这个东西就是来解决这个问题的。什么是SkillSkill其实就是一个文件夹里面装了一个叫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 4PRD 审核员它能干什么拿着检查清单帮你审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分钟内自动搞定而且输出的质量是稳定的——不会这次写成这样、下次又写成那样。