用 /triage-requests 批量分诊功能请求：将需求堆转化为可执行 Backlog 的完整工作流

用 /triage-requests 批量分诊功能请求：将需求堆转化为可执行 Backlog 的完整工作流

【免费下载链接】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

本指南详解 PM Skills 仓库中pm-product-discovery插件的/triage-requests命令——一个面向产品经理的"功能请求分诊"（Feature Request Triage）工作流，帮助你将来自支持工单、销售电话、调研问卷或 Slack 的零散需求，系统性地归类为主题、对齐战略目标、按影响与成本排序，最终输出一份可执行的分诊报告。读完本文，你将掌握该命令的全部调用方式、六步处理流程、底层的analyze-feature-requests与prioritize-features技能实现，以及报告模板与后续动作衔接，可直接复制到自己的需求评审流程中使用。

一、命令定位：它是做什么的

/triage-requests是仓库中 pm-product-discovery 插件 的五个命令之一，其官方描述（见 命令源文件 的 frontmatter）为：

Analyze, categorize, and prioritize a batch of feature requests from customers or stakeholders

即在一次交互中完成三件事：分析（Analyze）、归类（Categorize）、排序（Prioritize）。它解决的核心问题是：当你的面前堆着一大摞来自不同渠道的功能请求时，如何从"这堆需求"变成"一个有序、可行动、和战略对齐的 Backlog"。

从仓库的设计规范（CLAUDE.md）看，本仓库遵循"Skills = 名词/概念，Commands = 动词/工作流"的设计原则：技能是被 Claude 自动加载的框架性知识，而命令是用户主动触发的、串联一个或多个技能的端到端流程。/triage-requests正是典型的命令形态——它本身不重复造轮子，而是按顺序调用analyze-feature-requests与prioritize-features两个技能来完成分诊，这与/discover命令串联四个技能（brainstorm-ideas → identify-assumptions → prioritize-assumptions → brainstorm-experiments）的设计思路一脉相承（参见 discover.md）。

二、安装与调用方式

2.1 安装插件

该命令位于pm-product-discovery插件内。在 Claude Code（CLI）中安装：

claude plugin marketplace add phuryn/pm-skills claude plugin install pm-product-discovery@pm-skills

安装完成后即可在输入框中使用/触发该命令（详见 README.md 的安装章节）。命令的 frontmatter 中argument-hint提示了期望的入参格式："<feature requests as text, file, or paste>"。

2.2 三种调用形态

/triage-requests # asks for input /triage-requests [paste a list of requests] /triage-requests [upload a CSV/spreadsheet]

• 不带参数调用：命令会主动向你询问，请粘贴或上传功能请求；
• 直接粘贴：把一份请求列表（每行一条或每段一条）直接作为参数传入；
• 上传文件：传入 CSV / Excel / 纯文本文件。

提示：命令 frontmatter 中的description会出现在 Cowork 技能列表和 Claude Code 的/补全列表中（参见 CLAUDE.md 的 "What's Visible Where" 一节），因此即使记不住完整参数，输入/triage也能看到该命令的功能提示。

三、六步分诊工作流详解

命令的核心骨架是六个步骤：接收请求 → 收集上下文 → 归类分析 → 排序 → 输出报告 → 提供后续动作。下面逐步展开。

Step 1：接收功能请求（Accept Feature Requests）

命令接受任意格式的输入，并尽力保留其结构：

若无输入，命令会请用户粘贴或上传功能请求。解析每条请求时，需要抽取三要素：

• 核心诉求（core ask）：用户真正想要什么；
• 上下文（context）：谁提的、什么时候提的、为什么提（如果可得）；
• 频率信号（frequency signals）：有多少人提出了类似的需求。

这一步的价值在于：它要求你在"分类"之前先"读懂"每一条请求，为后续的主题聚类准备好干净的数据颗粒。

Step 2：收集分诊上下文（Gather Prioritization Context）

命令会以对话式、非一次性抛出一连串问题的方式向你确认以下背景信息：

• 产品是什么？处于什么阶段（新项目 / 已有产品 / 增长期）？
• 当前的战略目标或 OKR 是什么？（用于评估需求与战略的对齐度）
• 有哪些约束需要考虑？（团队规模、技术债、临近的截止日期）
• 是否存在权重更高的细分客群？（企业客户、正在流失的用户、重度用户）

这些背景信息正是后续"战略对齐度（Strategic Alignment）"评分的输入——没有目标，就无从判断一个需求是"该做"还是"该等"。

Step 3：归类与分析（Categorize and Analyze）

本步骤调用 analyze-feature-requests 技能 执行以下分析动作：

• 主题聚类（Theme clustering）：把相似请求归为同一主题，例如 "reporting & analytics"（报表与分析）、"collaboration"（协作）、"mobile experience"（移动端体验）；
• 每主题请求数：有多少条独立请求映射到各主题；
• 战略对齐度：对照既定目标，将每个主题评为 High / Medium / Low / None；
• 细分客群分析：哪些用户细分群体在驱动哪些主题；
• 情感信号：请求是否伴随挫败感、流失威胁或兴奋感。

该技能在其 Domain Context 中强调了两个重要原则：

1. 永远不要让客户设计方案（Never allow customers to design solutions）——优先评估的是机会（问题），而不是功能本身；
2. 推荐使用Opportunity Score（Dan Olsen）评估客户报告的问题：Opportunity Score = Importance × (1 − Satisfaction)，归一化到 0–1。

这意味着在 Step 3 中，主题聚类不只是"把句子相似的放一起"，而是在主题层面评估"这个主题代表的问题有多痛"。

Step 4：优先级排序（Prioritize）

本步骤调用 prioritize-features 技能。对每个主题（以及主题内的头部独立请求），按下表逐项评估：

评估完成后，对主题进行排序并产出一个有序的优先级列表。prioritize-features技能的推荐做法是输出 Top 5 功能，附带清晰的排名、入选理由、权衡取舍以及被降级项及其原因——这保证了排序过程是可解释、可向干系人汇报的，而不是一个黑盒分数。

Step 5：生成分诊报告（Generate Triage Report）

命令内置了完整的分诊报告模板，请务必完整沿用其结构（下文为模板原文）：

## Feature Request Triage Report **Date**: [today] **Requests analyzed**: [count] **Themes identified**: [count] ### Theme Summary | # | Theme | Requests | Top Ask | Alignment | Impact | Effort | Priority | |---|-------|----------|---------|-----------|--------|--------|----------| ### Priority 1: Act Now [Themes/requests to include in near-term planning] - **[Theme]**: [X] requests — [why it's urgent] - Top requests: [list] - Recommended action: [build / prototype / investigate] ### Priority 2: Plan Next [Themes worth planning but not urgent] ### Priority 3: Collect More Signal [Themes with potential but insufficient evidence] ### Priority 4: Decline or Defer [Requests that don't align with strategy — with rationale] ### Notable Individual Requests [High-value one-off requests that didn't cluster into themes] ### Patterns and Insights - [Key insight about what users are telling you] - [Segment-specific patterns] - [Gaps between what users ask for and underlying needs]

模板的设计要点：

• Theme Summary 表是全局速览：主题数、请求数、Top Ask、对齐度、影响、成本、优先级一表打尽，可直接用于周会汇报；
• 四档优先级（Act Now / Plan Next / Collect More Signal / Decline or Defer）迫使你做出明确的"现在做 / 稍后做 / 再收集证据 / 不做"决策，而不是把所有需求都塞进同一个待办池；
• Notable Individual Requests兜住了那些"高价值但未聚成主题的孤例请求"，避免被主题聚类淹没；
• Patterns and Insights是报告的升华部分——不只是罗列结论，而是提炼"用户到底在告诉你什么"。

命令要求将报告以 Markdown 文件保存到用户的工作区，便于沉淀为可追溯的文档。

Step 6：提供后续动作（Offer Next Steps）

报告输出后，命令会给出可选的后续衔接动作：

• "Want me tocreate user storiesfor the top-priority items?"（为最高优先级项编写用户故事）
• "Should Ibrainstorm solutionsfor any of these themes?"（为这些主题头脑风暴解决方案）
• "Want me todesign experimentsto validate demand before building?"（在开发前设计实验验证需求）
• "Should Idraft a stakeholder updatesummarizing this analysis?"（起草干系人更新摘要）

这些后续动作分别对应仓库中的其他能力：写用户故事可衔接 user-stories 技能（按 3C 与 INVEST 标准产出带验收标准的用户故事）；设计验证实验可衔接 brainstorm-experiments-new 技能（用 XYZ 假设与预原型实验验证市场需求）。遵循 CLAUDE.md 中"命令以自然语言建议后续步骤、不硬引用其他插件命令"的设计规则，这些衔接全部以对话形式给出，跨插件组合时不会因插件独立安装而失效。

四、底层评分框架：Opportunity Score、ICE 与 RICE

/triage-requests的排序步骤并非凭空打分，其依据来自 prioritization-frameworks 技能——一个收录了 9 种优先级框架的参考技能。与分诊最相关的三个框架如下：

Opportunity Score（Dan Olsen，《The Lean Product Playbook》）——评估客户问题（机会）的推荐框架：

• Current value = Importance × Satisfaction
• Opportunity Score = Importance × (1 − Satisfaction)
• Customer value created = Importance × (S2 − S1)（S1 为改进前满意度，S2 为改进后满意度）

高重要性 + 低满意度 = 最高 Opportunity Score = 最佳机会。将需求绘制在"重要性 vs 满意度"图表上，左上象限就是甜区。注意它的定位：优先评估的是客户问题，而非解决方案。

ICE 框架——适合快速为想法/举措打分：

• I（Impact）= Opportunity Score × 受影响客户数
• C（Confidence）= 信心程度（1–10），体现风险
• E（Ease）= 实现难易度（1–10），体现经济因素
• Score = I × C × E，分数高者优先

RICE 框架——把 ICE 的 Impact 拆成两个独立因子，适合需要更细粒度的较大团队：

• R（Reach）= 受影响客户数
• I（Impact）= Opportunity Score（单位客户价值）
• C（Confidence）= 信心程度（0–100%）
• E（Effort）= 实现工作量（人月）
• Score = (R × I × C) / E

在/triage-requests的分诊语境中，Step 3 的 Opportunity Score 用于判断"主题代表的问题有多值得解决"，Step 4 的 Impact / Effort / Risk / Alignment / Revenue 五因子评估则与 ICE/RICE 的精神一致——把"价值"和"成本"显式拆开衡量，让排序决策有据可依。

五、实战要点与边界情况

命令的 Notes 部分给出了几条在真实场景中非常关键的处理原则：

1. 保留结构化数据：如果用户提供的是带列的 CSV，应保留数据结构并对其进行丰富（enrich）——即在原字段基础上追加聚类主题、对齐度、优先级等分析结果列；
2. 寻找需求背后的需求："add dark mode"（增加深色模式）可能真正意味着"reduce eye strain during long sessions"（减少长时间使用时的眼部疲劳）。永远要回答"用户真正的问题是什么"；
3. 标记相互冲突的请求：例如 "simplify the UI"（简化界面）与 "add more configuration options"（增加更多配置项）本质上是冲突的——报告应明确点出这类矛盾，而不是和稀泥式地全部采纳；
4. 大数量处理策略：如果请求量很大（50+ 条），先输出主题级摘要，然后**按需深入（drill into）**特定主题，避免一次性输出过长报告；
5. 结构化输入回填 CSV：如果输入是结构化数据，将丰富后的数据输出为可下载的 CSV，方便用户在电子表格中继续加工。

六、在完整产品发现流程中的位置

/triage-requests并非孤立工具。在 pm-product-discovery 插件 的 5 个命令中，它专注于"存量需求的消化"，与另外四个命令互补：

典型的组合用法是：先用/triage-requests把散落的需求消化成有序 Backlog 并识别出高优先级主题，再针对其中"证据不足"的主题用实验或访谈补充信号，最后把确认的机会送进/write-prd、/write-stories等执行类工作流。这种"命令之间通过自然语言建议自然流转"的设计，正是本仓库把发现（discovery）到执行（execution）串成一条产品管理流水线的体现。

七、总结

/triage-requests用六步结构化流程，把"一堆需求"转化为"一份决策"：解析并保留输入结构 → 对话式收集战略上下文 → 主题聚类与五维分析 → 基于 Impact / Alignment / Effort / Risk / Revenue 排序 → 输出含四档优先级与洞察的分诊报告 → 引导进入用户故事、实验设计等后续动作。其分析深度由 analyze-feature-requests、prioritize-features 与 prioritization-frameworks 三个技能共同支撑，评分逻辑遵循 Opportunity Score / ICE / RICE 等业界框架。对于任何被需求评审会议淹没的产品团队，这套工作流提供了一种可复现、可汇报、可回溯的需求消化方式——把"感觉上该做"变成"有依据地排序"。

【免费下载链接】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