القائمة
Use when: 需要在多个产品间分配研发资源、进行ROI评估、解决资源冲突、团队规划 Do NOT use when: 资源充足无需分配优先级、单产品无需多项目协调
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/konglong87/superPM --skill pm-resourceيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Use when: 需要进行市场调研数据收集、竞品信息采集、行业舆情监控、合规政策检查 Do NOT use when: 已有完整数据无需补充、仅需内部数据分析无需外部信息
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
史蒂夫·乔布斯(Steve Jobs)的思维框架与表达方式。基于Isaacson授权传记、Stanford演讲、 Lost Interview、D Conference系列、Make Something Wonderful、30+一手来源的深度调研， 提炼6个核心心智模型、8条决策启发式和完整的表达DNA。 用途：作为一个可对话的思维顾问——用乔布斯的视角分析你的产品、决策与想法， 在一来一回的对话里制造思维碰撞、激发灵感，并帮你把"Jobs级"思考方式内化成自己的能力。 当用户提到「用乔布斯的视角」「乔布斯会怎么看」「Jobs模式」「steve jobs perspective」 「切换到乔布斯」「如果乔布斯」「乔布斯思维」「表达DNA」时使用。 即使用户只是说「帮我用乔布斯的角度想想」「如果乔布斯会怎么做」「切换到乔布斯」也应触发。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | pm-resource |
| description | Use when: 需要在多个产品间分配研发资源、进行ROI评估、解决资源冲突、团队规划 Do NOT use when: 资源充足无需分配优先级、单产品无需多项目协调 |
| allowed-tools | ["Agent","Read","Write","AskUserQuestion","Bash","WebSearch","mcp__exa__web_search_exa","mcp__exa__web_fetch_exa"] |
bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
# 创建目录
mkdir -p docs/05-产品战略
# 检查是否有产品组合战略作为输入
if [ -f "docs/05-产品战略/产品组合战略.md" ]; then
echo "✅ 检测到产品组合战略文档，将基于此进行资源分配"
else
echo "⚠️ 未检测到产品组合战略文档，建议先执行 /pm-portfolio"
fi
当流程要求与用户交互时：
优先读取：
docs/05-产品战略/产品组合战略.md如果文件不存在，提示用户：
⚠️ 未找到产品组合战略文档
您可以选择： A) 先执行 /pm-portfolio 进行产品组合分析 B) 手动输入产品列表（快速模式）
询问方式：使用 AskUserQuestion 逐个询问
问题 1: 研发团队规模
使用 AskUserQuestion 询问：
请问研发团队总人数？
A) 10人以下（小团队） B) 10-30人（中小团队） C) 30-50人（中型团队） D) 50-100人（大型团队） E) 100人以上（超大型团队） F) 其他（请手动输入）
问题 2: 可投入资源比例
本季度可投入新产品/项目的研发资源比例？
A) <20%（主要维护现有产品） B) 20-40%（小部分资源可投入新项目） C) 40-60%（资源较充足） D) 60-80%（重点投入新项目） E) >80%（全力投入新产品）
问题 3: 关键角色配置
团队中关键角色的配置情况？
逐个询问：
问题 4: 资源约束条件
当前资源分配面临的主要约束是？（可多选）
A) 人力不足 B) 预算限制 C) 时间紧迫 D) 技术能力不足 E) 其他（请手动输入）
根据步骤1读取的产品列表，逐个评估资源需求：
针对每个产品询问：
评估项 1: 资源需求量
{产品名称}本季度需要的研发人力？
A) 极高（需要团队主力投入） B) 高（需要大量人力） C) 中（需要适中人力） D) 低（少量人力即可） E) 维护模式（仅需维护人力）
评估项 2: ROI预期
{产品名称}投入产出比（ROI）预期如何？
A) 极高ROI（投入1元，产出>10元） B) 高ROI（投入1元，产出5-10元） C) 中ROI（投入1元，产出2-5元） D) 低ROI（投入1元，产出<2元） E) 暂无ROI（战略投资期）
评估项 3: 时间紧迫性
{产品名称}的上线时间紧迫性？
A) 极紧迫（必须本季度上线） B) 紧迫（下季度必须上线） C) 适中（半年内上线即可） D) 不紧迫（一年内上线即可） E) 无明确时间要求
评估项 4: 风险等级
{产品名称}的开发风险等级？
A) 高风险（技术难度大、不确定性高） B) 中风险（有一定技术挑战） C) 低风险（技术成熟、风险可控） D) 极低风险（常规开发）
决策逻辑：
每个产品计算优先级得分：
优先级得分 = ROI得分 × 0.4 + 时间紧迫性得分 × 0.3 + 战略重要性得分 × 0.3 - 风险扣分
| 优先级 | 资源占比 | 说明 |
|---|---|---|
| P0（最高） | 30-40% | 必须完成的核心项目 |
| P1（高） | 20-30% | 重要项目，保证交付 |
| P2（中） | 10-20% | 次要项目，按资源情况调整 |
| P3（低） | <10% | 探索性项目，资源充足时执行 |
当资源需求 > 可用资源时：
使用 Write 工具生成文档：
---
product: [产品组合]
created_at: [当前时间]
author: [用户]
skill: pm-resource
status: draft
---
# 资源分配方案
## 一、资源盘点
### 可用资源
**团队规模**: [X]人
**可投入新项目比例**: [X]%
**可用人力**: [X]人月
**关键角色配置**：
- 产品经理: [X]人
- 前端工程师: [X]人
- 后端工程师: [X]人
- 测试工程师: [X]人
- 运维工程师: [X]人
- 设计师: [X]人
**资源约束**：[人力不足/预算限制/时间紧迫...]
---
## 二、产品资源需求
| 产品名称 | 资源需求 | ROI预期 | 时间紧迫性 | 风险等级 | 战略重要性 |
|---------|---------|---------|-----------|---------|-----------|
| [产品A] | 极高 | 极高 | 极紧迫 | 中 | 核心战略 |
| [产品B] | 中 | 高 | 适中 | 低 | 重要战略 |
| ... | ... | ... | ... | ... | ... |
---
## 三、优先级排序
### P0级项目（最高优先级）
**项目列表**: [产品A, 产品C]
**优先级得分**: [90分, 85分]
**分配资源**: 35%人力
**理由**：
- [产品A]: ROI极高 + 时间紧迫 + 核心战略
- [产品C]: 高ROI + 明星产品阶段
---
### P1级项目（高优先级）
**项目列表**: [产品B]
**优先级得分**: [75分]
**分配资源**: 25%人力
**理由**：
- [产品B]: 现金牛产品，稳定收益
---
### P2级项目（中优先级）
**项目列表**: [产品D]
**优先级得分**: [60分]
**分配资源**: 15%人力
**理由**：
- [产品D]: 问题产品，需要验证
---
### P3级项目（低优先级）
**项目列表**: [产品E]
**优先级得分**: [45分]
**分配资源**: 5%人力
**理由**：
- [产品E]: 瘦狗产品，最小化投入
---
## 四、详细资源分配
### 季度资源分配表
| 产品名称 | 分配人力 | 前端 | 后端 | 测试 | 产品 | 设计 | 上线时间 |
|---------|---------|------|------|------|------|------|---------|
| [产品A] | 15人月 | 3人 | 5人 | 2人 | 2人 | 1人 | 3月底 |
| [产品B] | 10人月 | 2人 | 3人 | 2人 | 1人 | 1人 | 4月底 |
| [产品C] | 8人月 | 2人 | 2人 | 1人 | 1人 | 1人 | 5月底 |
| [产品D] | 5人月 | 1人 | 1人 | 1人 | 1人 | 0.5人 | 待定 |
| [产品E] | 2人月 | 0.5人 | 0.5人 | 0.5人 | 0.3人 | 0.2人 | 仅维护 |
---
## 五、资源冲突与解决方案
### 冲突1: 后端工程师不足
**问题描述**：
- 需求：15人
- 可用：10人
- 缺口：5人
**解决方案**：
1. 短期：外包3人，临时支援2人
2. 长期：招聘2人，培养内部人才3人
---
### 冲突2: 产品上线时间冲突
**问题描述**：
- 产品A和产品C都需要3月底上线
- 资源无法同时满足
**解决方案**：
1. 产品A优先上线（核心战略）
2. 产品C延后至4月中旬
3. 增加产品C的开发资源
---
## 六、风险控制
### 风险1: 关键人员离职
**影响**: 核心项目进度延误
**应对**:
- 建立知识转移机制
- 培养2名备份人员
- 关键模块文档化
### 风险2: 技术难度超预期
**影响**: 项目延期或失败
**应对**:
- 提前进行技术预研
- 预留20%缓冲时间
- 建立技术专家支持机制
---
## 七、监控指标
### 资源利用率
- 目标：80-85%利用率
- 监控频率：每周
- 预警阈值：<70% 或 >90%
### 项目进度偏差
- 目标：<10%偏差
- 监控频率：每周
- 预警阈值：>20%偏差
### ROI达成率
- 目标：>80%预期ROI
- 监控频率：每月
- 预警阈值：<50%预期ROI
---
## 八、下一步建议
建议执行：
1. /pm-decision - 战略决策支持（如外包、招聘等决策）
2. /pm-roadmap - 制定产品路线图
3. /pm-agile - 敏捷管理执行
---
: 资源分配方案制定完成
: [当前时间]
: super-pm
在资源盘点完成后，可派发 subagent 并行执行：
Agent 1: 团队产能调研
Agent 2: 行业 ROI 基准查询
| 维度 | v1（串行） | v2（Subagent 并行） |
|---|---|---|
| 产能评估 | 主 agent 大致估算 | Subagent 基于数据评估 |
| 行业基准 | 无对比数据 | Subagent 自动获取基准 |
| Token 占用 | 分析占主上下文 | Subagent 独立处理 |
| 执行效率 | 线性顺序 | 并行 2x 加速 |
✅ Good 示例：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。