企业官网建设流程全解析

Product Management 插件完整实战：7 个命令，搭一条从 PRD 到指标复盘的 AI 产品工作流

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins

在 knowledge-work-plugins 仓库里，product-management是专为产品经理打造的角色插件：在 Claude Cowork 里输入/write-spec就能产出一份结构化 PRD，输入/metrics-review则把一堆原始数字变成带行动建议的记分卡。它由 7 个斜杠命令和 8 个技能组成，命令负责发起会话，技能提供领域方法论。下面我用 7 个真实场景走一遍，顺带说清 MCP 连接器怎么接入你现有的工具栈。

一分钟跑起来：安装与触发机制

整个插件是纯 Markdown 仓库，没有编译步骤，装完即可用。在 Claude Cowork 里从插件页面直接安装；在 Claude Code 中先注册市场再安装：

claude plugin marketplace add anthropics/knowledge-work-plugins，随后claude plugin install product-management@knowledge-work-plugins。README 给出的等价单行写法是claude plugins add knowledge-work-plugins/product-management。

装完后每个命令以/<插件>:<命令>的形式出现。7 个命令各自的分工：/write-spec产出 PRD；/roadmap-update增删改排路线图；/stakeholder-update生成面向不同受众的状态更新；/synthesize-research提炼用户研究；/competitive-brief输出竞争简报；/metrics-review评审指标；/brainstorm与思考伙伴过想法。技能侧则多一个sprint-planning（对应/sprint-planning），负责把路线图落到具体迭代。技能文件在对话相关时自动触发，例如你在讨论"这个需求该不该做"时，write-spec 技能会带着自己的方法论进场。

场景一：📝 一句话需求，三步变成结构化 PRD

/write-spec是你日常用得最多的入口，四类输入它都收：功能名（"SSO 支持"）、问题陈述（"企业客户不断要集中式认证"）、用户请求（"想把数据导出成 CSV"），甚至一句模糊念头（"新手流失该管管了"）。

第一步是对话式补上下文，而不是一次性甩问卷：目标用户是谁、怎么算成功、约束有哪些（技术、时间线、法规、依赖）、以前试过没有。重要问题先问，缺口边聊边补。

第二步是拉取连接工具的上下文。接了项目追踪器，它会翻相关工单、既有验收标准和依赖项；接了知识库，能检索历史规格、研究结论和会议决策；接了设计工具，可以取 mockup 和设计系统组件。一个都没接也照跑，它只基于你提供的信息工作，不会催你装连接器。

第三步产出八段式 PRD：问题陈述（2-3 句，需有证据支撑——用户研究、支持数据或指标）、目标（3-5 条，写成果而非产出，比如"把首次价值时间砍一半"而不是"做一个引导向导"）、非目标（3-5 条，各附理由）、用户故事、需求分级、成功指标、开放问题（标注由谁回答，区分阻塞性）、时间线。生成后它会主动问你要不要调整章节，或接着产出设计简报、工单拆解。

P0/P1/P2 分级，MoSCoW 交叉校验

分级的核心是一道判断题："砍掉它，功能还能解决核心问题吗？"不能，就是 P0。P1 是核心场景不依赖、发布后快速跟进的改进；P2 是 v1 明确不做但设计上要留空间——技能文档把它称为"架构保险"，防止将来想支持时架构上已经走死路。MoSCoW（Must/Should/Could/Won't）作为另一套分类法可以交叉使用。收紧 P0 要狠：如果一切皆 P0，等于没有 P0。

用户故事按 INVEST 六条检查——独立可交付、细节可协商、对用户有价值、可估算、一个冲刺能做完、可验证。文档同时列了五类常见坏味道：太模糊（"产品要更快"）、预设方案（"要一个下拉菜单"）、缺收益（"要能点按钮"）、过大（"要能管理团队"）、内部视角（把"重构数据库"写成了用户故事）。

成功指标分两类：领先指标（发布后数天到数周可见变化，如采纳率、激活率、任务完成率、错误率）和滞后指标（数周到数月才显现，如留存、收入、NPS、工单量下降）。目标必须具体——"30 天内 50% 采纳率"，同时设"达标线"和"拉伸线"，并写清用什么工具、什么查询、多长窗口，在发布后 1 周、1 月还是 1 季度评估。验收标准支持 Given/When/Then 或清单两种写法，要求覆盖快乐路径、错误路径和边界，把"不应发生什么"也写出来，避开"快""易用"这类无法验证的词。

常见误区：范围蔓延的五个信号

规格批准后需求还在加、"小改动"滚成大项目、没人要的功能被顺手加上、发布日期一推再推却不重新划范围、利益相关者只加不减——出现这些就该警惕。对应的手段：每份规格都写明非目标；加一项就必须减一项或延时间线；v1 与 v2 在文档里分开；给调查类工作设时间盒（"两天查不出来就砍"）；另设"停车场"记录不错但不在本期范围的想法。

场景二：💡 让"思考伙伴"帮你压力测试一个想法

/brainstorm是插件里唯一被明确定义为"对话而非交付物"的命令——目标不是给你一份清单，而是让你比独自思考时走得更远。

先选模式：四种思考姿态

• 问题探索：你只有一块问题域时。先问"谁有这个问题、他们今天怎么解决"，把症状和根因分开，不断追问"为什么"直到触及结构性因素，再看这个问题在不同用户细分里的差异。
• 方案构思：问题已定义清楚、需要发散时。先产出 5-7 个不同方案再评估，其中至少一个是"反过来做会怎样"，一个是"减去什么而不是增加什么"。
• 假设测试：手里有半成型想法时。列出显性与隐性的全部假设，逐个追问置信度和证据，找出"错了就全盘皆输"的那条，再设计最便宜的验证方式。假设分六类：用户、问题、方案、商业、可行性、采纳。
• 战略探索：谈的是方向而不是功能时。用"赌注"思维：赌什么、赔率如何、回报多大，并对照 3 个月 / 12 个月 / 3 年的不同时间轴分别推演。

框架工具箱：从 HMW 到 OODA

product-brainstorming 技能内置了整套框架，按会话需要取用：

• HMW（How Might We）：把痛点重写成机会问题。"如何改善新手引导"太宽，"给步骤 3 加 tooltip"太窄，恰当的是"如何帮新用户在 10 分钟内拿到第一次成功"。
• JTBD："当[情境]，我想[动机]以便[预期结果]"。功能层的工作容易罗列，情感层（感到自信）和社会层（被视为靠谱）的工作往往更有杠杆；追问"用户为了用你的产品，解雇了什么"，就能看清真实竞争集。
• 机会解决方案树：期望结果 → 机会（必须有研究证据）→ 方案 → 实验，同一机会配多个方案，用最便宜的方式先测。
• 第一性原理：拆到基本组件，逐项问"为什么必须如此——是物理定律还是惯例"，适合团队陷入增量思维时用。
• SCAMPER：替代、合并、改编、修改、另作他用、消除、反转，七个角度轮流过一遍。
• OODA：观察—定向—决策—行动。技能文档的判断是：力量不在步骤本身，而在循环速度。多数团队卡在"定向"环节——无限分析、争论框架、等更多数据；OODA 的主张是先用已有信息决策行动，让下一轮观察来修正航向。
• 反向头脑风暴：卡住时先列"怎么把这事做砸"，再把每一条反转。人更擅长指出错误，反转能解锁想象。

Frame-Diverge-Provoke-Converge-Capture 的节奏

一次会话分五拍：Frame 定边界（探索什么、为什么是现在、已知什么、理想产出）；Diverge 大量生成、不评判；Provoke 主动挑战——"最强反驳是什么""谁会讨厌这个""10 倍更野的版本长什么样"；Converge 收敛到 2-3 个方向，点名最大未知和最便宜的验证；Capture 记录想法、待验证假设、下一步和搁置项。

对思考伙伴的行为要求也写得很细：要有立场（"我认为方案 B 更强，因为……"比中立罗列有用），挑战要建设性（"这假设了 X，我们确信吗"而不是"这行不通"），能量要与对方匹配，看到模式要直呼其名——过早方案化、功能对等陷阱（"对手有 X 我们也要 X"）、被约束锚定。反模式提醒里有一条最容易被忽略：该研究的时候别头脑风暴，有些问题需要数据，此时应停下来列出所需的研究。

场景三：把一堆访谈记录变成决策依据

/synthesize-research的原料是访谈记录、问卷数据、支持工单，产出是带证据的结论而不是印象。对每份来源，它会提取关键观察、逐字引语、实际行为、痛点、正面信号和上下文。

主题分析六步与三角验证

主题分析走六步：熟悉数据 → 初始编码（打码宁多勿少，合并总是比拆分开容易）→ 主题开发 → 主题审查（证据够不够、主题之间分不分得开、能不能讲出连贯故事）→ 命名并写一两句描述 → 写成带证据的发现。

配合亲和图法：每个观察单独一张卡片，按相似性自由聚类、不预设类别，为聚类命名后再归纳更高层分组。两条经验：首次分组很少是最优的；聚类大到失控，通常说明里面混着多个主题。异常值也值得单独看。

三角验证是"用来源组合加固结论"：方法三角（同一问题、不同方法）、来源三角（同一方法、不同参与者或细分）、时间三角（同一观察、不同时点）。技能文档特别指出，来源之间出现矛盾时，往往是在暴露不同的用户细分或上下文，值得追下去而不是抹平。

从人物角色到机会打分

访谈分析要分清行为与态度——行为是更强的证据；区分嘴上偏好与揭示偏好；强度信号看情绪化语言、提及频率、用户付出的变通努力、后果的严重度。问卷分析则要盯分布形状：双峰分布和正态分布讲的是完全不同的故事，还要做细分拆解、对小样本的显著性保持谨慎。文档列出的定量分析常见错误有五个：只报均值不报分布、忽视无响应偏差、过度解读微小差异、把李克特量表当等距数据、把相关当因果。

定性和定量走一个反馈环：定性先行回答"是什么、为什么"并生成假设，定量验证回答"有多少、覆盖多少人"，再回到定性解释意外的定量发现。人物角色应从数据中涌现：识别行为模式 → 定义区分变量 → 画画像（名称、行为目标、痛点、上下文、代表引语）→ 用定量数据验证规模。3-5 个为宜，避免人口统计学画像和没有产品决策含义的角色。

机会打分则综合可触达用户数 × 频率（每日/每周/每月/一次性）× 严重度（阻塞/显著摩擦/轻微烦扰），再叠加证据强度、战略对齐、可行性。呈现时透明披露假设与置信度，用区间而非虚假精确——"每月影响 1500-2500 用户"比"每月 2137 用户"更诚实。

场景四：用竞争简报回答"差异化还是对齐"

/competitive-brief走三步：先定范围（盯哪几个对手、聚焦哪个功能域、支撑什么决策），再收情报，最后出简报。情报两条线：对外查产品页、定价页、发布动态、客户评价、招聘信息、社媒讨论；对内翻既有竞争分析、赢输报告、销售 battle card 和 deal 反馈。

功能对比矩阵怎么搭

先把竞争格局分层：直接竞争者（相同用户、相同问题、相同方式）、间接竞争者（相同问题、不同方式，"什么都不做"或拿电子表格对付也算）、邻近竞争者（今天不竞争但可能进入你地盘的大平台或初创）、替代方案（满足底层需求的完全不同路径）。画景观图时，轴要选能暴露战略定位差异的组合：广度对深度、SMB 对企业、自助对销售驱动、简单对强大、横向对纵向。

矩阵的维度从买家评估视角出发，而不是你的内部架构。评级尺度两档：简单版 Strong / Adequate / Weak / Absent；详细版用 5 分制，5 代表最佳实践级、0 代表缺失。四条操作纪律：基于真实产品体验和客户反馈评级而非营销页；按目标客户真正在意的维度加权；定期更新，功能对比过时很快；对手领先的地方要诚实标出来——一份永远显示自己赢的对比没有可信度。

赢/输分析：含金量最高的竞争情报

数据源按偏差从大到小排：CRM 销售备注即时但有偏，流失调查居中，决策完成后的客户访谈最有价值。赢单问三句：为什么选我们、什么差点让你选了别人、我们要失去什么你才会重新考虑。输单问三句：最终选了谁、我们哪里不足、什么条件下你会重新考虑我们。分析时把产品原因和非产品原因（定价、品牌、关系、时机）拆开，并算出按对手划分的竞争赢单率。

定位分析给了一句可直接套用的陈述："对于[目标客户]（他们有[需求/问题]），[产品]是一个[品类]，能带来[关键收益]；与[竞争者/替代方案]不同，[产品]的[关键差异点]"。消息架构分四层：品类主张 → 差异点 → 价值主张 → 证明点，再沿这四层寻找未占位的空档、拥挤的占位、新兴占位和易受攻击的占位。

场景五：🗓️ 把路线图排出来，再落到冲刺

/roadmap-update覆盖五类操作：加条目、改状态（not started / in progress / at risk / blocked / completed / cut）、调优先级、挪时间线、从零建图。

格式怎么选：Now/Next/Later、季度主题、OKR、Gantt

• Now/Next/Later：Now 是本周期已承诺的工作，Next 是未来 1-3 个月已排期未启动的，Later 是 3-6 个月以上的方向性押注。对外或向上沟通时它最稳，因为它不在日期上制造虚假精确性。
• 季度主题：每季度围绕 2-3 个战略投资组织（如"企业就绪度""激活改善"），主题应能映射到公司或团队 OKR。
• OKR 对齐：每个条目直接挂到目标与关键结果上，写清预期影响，适合以 OKR 运转的组织。
• 时间线/Gantt：展示起止、并行串行、资源冲突与依赖，服务于工程执行，不适合对外。

优先级框架：RICE、MoSCoW、ICE、价值-努力

• RICE = (Reach × Impact × Confidence) / Effort。Reach 用具体用户数（"每季度 500 用户"），Impact 按 3/2/1/0.5/0.25 打分，Confidence 取 100%、80%、50%，Effort 以人月计。适合需要量化、可辩护的排序场合。
• MoSCoW：Must/Should/Could/Won't，适合发布或季度划范围、与利益相关者谈判。
• ICE：Impact、Confidence、Ease 各打 1-10 分，适合早期产品、数据不足时快速排布积压。
• 价值 × 努力 2×2：高价值低努力先做，高价值高努力谨慎规划，低价值低努力当填充，低价值高努力直接从积压里移除。

容量是零和游戏：70/20/10 规则

依赖分技术、团队、外部、知识、串行五类，管理动作是：全部显式列出、每条指定负责人、设"需要日期"、留缓冲、跨团队依赖尽早标记、准备滑期预案。

容量上，工程师约 60-70% 时间应投入计划内功能；一个健康配比是 70% 计划功能 / 20% 技术健康 / 10% 计划外缓冲，再按团队情境（新产品、成熟产品、事故后、高速增长）调整。roadmap-update 技能反复强调一点：路线图对容量是零和游戏，添加任何东西时都要问"什么会被移走或挪后"。

最后一公里的交付靠 sprint-planning 技能：它要五类输入——团队与可用性、冲刺长度、按优先级排好的积压、上冲刺遗留项、跨团队依赖，产出含冲刺目标、逐人容量表（可用天数、分配点数、PTO 与值班备注）、P0/P1/P2 分级积压和依赖风险的计划。裸跑完全可用；接了项目追踪器可以拉积压并直接建冲刺，接了日历能把 PTO 和会议折进容量，接了聊天工具可以把计划发给团队。

场景六：读数字，并把数字变成 OKR

/metrics-review先取数（连了分析工具就拉指标、对比周期和目标，没连就贴一张表进来），按层级组织，看趋势和异常，最后输出带建议的评审。

北极星 + L1/L2 三层指标

北极星是"最能捕捉产品核心价值"的那一个指标。技能文档给了五类示例：协作工具是"每周有 3 名以上成员贡献的活跃团队数"，市场是"每周完成的交易数"，SaaS 平台是"每周跑完核心工作流的活跃用户数"，内容平台是"每周深度消费时长"，开发者工具是"每周使用工具的部署次数"。

L1 健康指标取 5-7 个，覆盖获客、激活、参与、留存、变现、满意度六个阶段，例如注册转化率、激活率、DAU/MAU 粘性比、D1/D7/D30 留存、免费转付费率、MRR、NPS。L2 诊断指标用于下钻：漏斗各步转化、功能级采纳、细分拆解（计划/规模/地域/角色）、性能（页面加载、错误率、API 延迟）。

读数的几个经验值：DAU/MAU 大于 0.5 说明形成了日习惯，低于 0.2 说明使用稀疏，且趋势比绝对值重要；留存看队列曲线——初期陡跌是激活问题，持续阴跌是参与问题，趋平说明有了稳定底盘；漏斗里最大的掉队点就是杠杆最高的改进机会；激活事件要能强预测长期留存，并且最好在首次会话内可达（建第一个项目、邀一个队友）。

OKR 方面：目标定性、有抱负、有时限；每个目标配 2-4 条量化、结果导向的 KR。文档示例——目标"让产品成为日常工作流里不可替代的一环"，KR 为"DAU/MAU 从 0.35 提到 0.50""新用户 D30 留存从 40% 提到 55%""3 个核心工作流的任务完成率超过 80%"。实践建议：拉伸目标按 70% 达成设计，KR 测结果不测产出，期末诚实评分（0.0-0.3 未达成、0.4-0.6 有进展、0.7-1.0 达成）。

周、月、季三级评审节奏

周检 15-30 分钟，PM 加工程负责人参加，看北极星周环比、L1 显著变动、在跑实验和异常告警。月评审 30-60 分钟，产品团队加关键利益相关者，过完整 L1 记分卡、OKR 进度、队列分析和新功能采纳。季度业务评审 60-90 分钟，产品、工程、设计、领导层一起评分 OKR、看季度趋势与同比、复盘竞争背景，并设定下季度 OKR。

仪表盘的设计原则：从问题出发而不是从数据出发；北极星放最显眼处，L1 次之，L2 供下钻；每个数字带当前值、对比和趋势方向；聚焦 5-10 个指标；每个指标都要可行动。告警分阈值型（如错误率超 1%）、趋势型（多日持续下滑）和异常型（显著偏离预期），并且每条告警都要可行动、有响应负责人、定期调优防疲劳。

场景七：📣 写一份会被认真读完的状态更新

同一份进展有五种写法，/stakeholder-update会先问你两个问题：什么类型（周报/月报/发布公告/临时），给谁看（高管/工程/跨职能/客户/董事会）。

每类受众一套模板

• 高管：TL;DR + G/Y/R 状态 + 关联目标的进展 + 已做决策 + 风险与缓解 + 具体请求 + 下个里程碑，控制在 300 词以内。用结论开场，说"发布了 X、指标 Y 有变化"，而不是"开了 14 次会、关 23 个工单"；请求必须具体——"周五前对 X 做决策"，不是"需要支持"。
• 工程团队：已发布（带 PR 和工单链接）、进行中（带负责人）、阻塞项、决策（含备选方案和建议）、优先级变化及原因。工程师的读法是点链接看细节，所以链接要给到具体工单。
• 跨职能伙伴：什么即将到来、会影响他们什么、需要你方做什么（带截止日期）、欢迎反馈的地方。
• 客户/外部：收益语言描述新功能、即将到来、已知问题与变通方案、反馈渠道；不出现内部行话、工单号和技术细节。
• 发布公告：发布了什么、为什么重要、范围/可用性/限制、成功指标、发布节奏、反馈渠道。

G/Y/R 与 ROAM：把状态和风险说诚实

绿：按计划推进，如实使用，它不是默认值。黄：进度落后或风险已现，缓解措施在跑但结果未定。红：显著偏离，重大阻塞且没有明确缓解，需要砍范围、加资源或延时间线。转换纪律是重点：风险一露头就转黄，标记得越早选项越多；需要外部介入时才转红；风险是真正解决而不是暂停，才回到绿；每次状态变化都记录原因。

风险用 ROAM 四种状态表达：Resolved（已解决并记录）、Owned（有人主动负责，写明人和缓解计划）、Accepted（知情接受，记录理由）、Mitigated（行动已把风险压到可接受水平）。沟通走五步：讲清风险、量化影响、给可能性、给缓解方案、提具体请求。

重大决策落一份 ADR，五部分：Status / Context / Decision / Consequences / Alternatives Considered。适用于重大产品或技术决策、有争议的决策、限制未来选项的决策、以及预期会被质疑的决策。技巧：决策后尽快写、记录参与者和最终拍板人、一页以内，事后被证明错误的决策也保留原文，只追加 superseded 链接。

连接器：把你的工具栈接进来

插件是工具无关的——文档里的~~project tracker、~~knowledge base、~~design都是类别占位符，同类别下你接的任意 MCP 服务器都能工作，.mcp.json只是预配了具体服务器。全部类别见 CONNECTORS.md：

各连接器对产出质量的贡献：追踪器喂给路线图、工单上下文和状态跟踪；知识库喂历史规格、研究与会议纪要；设计工具喂设计上下文；分析工具喂使用数据和行为洞察；反馈工具喂工单与功能请求；转写工具喂会议结论。没接工具时手动给上下文即可——所有技能在设计上都支持裸跑，工具只是增强项。

最小上手路径

想今天就看到效果，不用先接任何工具：

1. 拿一个你拿不准的问题跑/brainstorm，先感受思考伙伴的对话方式；
2. 用/write-spec把本季度最重要的一件事写成 PRD，喂一段问题陈述加成功指标即可；
3. 用/metrics-review复盘上个月的数字，直接贴表；
4. 之后再逐个接工具：聊天工具最先（决策散落在讨论里），然后追踪器（工单与状态），最后分析工具（行为数据）。

一条要提前说的误区：别把这些命令当成代笔。命令输出一长串清单不等于完成了头脑风暴，需要数据支撑的结论也不要靠发散获得——切到/synthesize-research喂真实研究，或者先做一次小样本访谈。插件的八份技能文档都放在 product-management/skills/ 下，每份都值得通读一遍，那是这套工作流的真正方法论底座。

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins