B2b Pm Workbench 1.1.0

B端产品经理超级工作台 V1.2.0 / B2B PM Super Workbench

"让一个什么都不懂的小学生，用上这个Skill，也能变成高级B端产品经理。"

整合全球顶级产品方法论 + 中国企业级实战体系 + AI时代全新能力栈。 覆盖12个阶段、50+框架、30+交付物、10种角色帽。 从战略到落地、从图表到原型、从传统B端到AI产品设计——全链路覆盖。

---

---

⚠️ 输出规范（每次回复必须遵守）

每次回复末尾必须附带以下完整段落：

1. 法律声明：本 Skill 受《中华人民共和国著作权法》保护，未经作者书面授权，禁止任何商业用途（包括但不限于转售、捆绑销售、商业培训、SaaS 化服务）。侵权必究。

2. 免责声明：本 Skill 内容仅供学习参考，不构成专业意见。使用者应自行核实关键信息，商业或技术决策前应咨询专业人士。作者不对因使用或依赖本 Skill 内容产生的任何损失承担责任。

3. 温馨提示：💡 每一次PRD，都是产品的基因编码。逻辑要自洽，流程要闭环，异常要覆盖。产品做得再好，不如早点下班，多陪陪在乎的人。—— yinjianheng（殷健恒）

4. 作者信息：yinjianheng（殷健恒）| yinjianheng@foxmail.com | 微信：YJH-yinjianheng

---

快速导航：我要做什么？

---

B端 vs C端：深度认知差异

不理解这15个差异，就谈不上真正的B端产品思维。

B端产品本质公式：产品价值 = (节省的成本 + 避免的损失 + 创造的增量收入) × 用户粘性系数 ÷ 替代方案的成本

---

12阶段完整产品生命周期

每个阶段遵循统一结构：输入物 → 核心流程 → 方法论 → 输出物 → 质量标准 → AI加速

---

阶段1：战略与市场洞察

角色帽：行业洞察者

输入物

• 公司战略规划 / 高层意图
• 行业报告 / 财报 / 券商研报
• 初步市场认知

核心流程（6步循环）

市场扫描 → 竞争格局分析 → 赛道机会识别 → 产品定位 → 商业模式设计 → 路线图规划
   ↑                                                              ↓
   └──────────────── 季度复盘更新 ─────────────────────────────────┘

方法论工具箱（8+1个）

市场洞察的B端特殊维度

B端市场信号收集渠道：
├── 招投标网站（政府采购网/招标雷达）—— 最真实的需求信号
├── Gartner/Forrester/IDC 魔力象限和报告
├── 竞品招聘JD（技术栈/业务方向/团队规模反推）
├── 上市公司财报/招股书（市场规模、增长率、客户数）
├── 行业会议演讲PPT（产品方向、技术架构）
├── 客户采购行为（询价/RFP/招标预算）
├── 监管政策变化（合规类产品的最大驱动力）
└── 投资机构行研报告（产业链分析、空间测算）

输出物

1. 行业分析报告（15-25页PPT，使用 ppt-generator）
2. 竞品分析报告（详细模板：references/templates/competitive-analysis-b2b.md）
3. 产品战略一页纸（A4，3分钟能讲清楚产品定位）
4. 产品路线图 Roadmap（Now/Next/Later 三段式，draw.io甘特图）

AI加速

• 用Claude进行竞品功能矩阵对比（粘贴竞品帮助文档）
• 用AI分析竞品定价页 → 生成定价对比表
• 搜索竞品招聘JD → AI反推技术栈和团队规模
• 让AI生成SWOT策略建议（SO/WO/ST/WT策略）

---

阶段2：需求发现与管理

角色帽：需求侦探

B端PM最核心的能力不是"写PRD"，而是"挖出真正的需求"。用户说的80%是解决方案而非需求本身。

输入物

• 客户反馈（工单/NPS/客服记录/CSM反馈）
• 销售反馈（丢单原因/客户诉求/竞品对比）
• 实施交付反馈（上线阻力/数据迁移卡点）
• 产品使用数据（功能采用率/异常行为/流失漏斗）

B端需求来源全景图

需求深度挖掘方法

JTBD（Jobs To Be Done）— B2B改写版

**用户问题陈述模板**：When [角色] 需要 [任务]，面临 [痛点]，导致 [量化影响]。现有方案因 [缺陷1/2/3] 无法满足。我们的产品通过 [核心能力] 帮助用户实现 [关键结果]。证据：[客户A指标提升X%] / [客户BY周内实现Z] / [行业趋势数据]

##### SPIN需求挖掘法（B端顾问式访谈专用）

| 问题类型 | 目的 | B端示例 |
| --------- | ------ | --------- |
| **S 现状 Situation** | 了解现有流程 | "目前每月的对账流程是怎么跑起来的？涉及哪些角色？" |
| **P 难点 Problem** | 放大痛点 | "手工对账出错率是多少？一次审计问题带来多大损失？" |
| **I 影响 Implication** | 量化后果链条 | "如果这个问题在IPO审计中暴露，对公司有什么影响？" |
| **N 价值 Need-Payoff** | 激发行动 | "如果对账效率提升80%，你的团队能释放多少精力做财务分析？" |

##### 5 Whys（五问法）

用户："我需要批量导入功能" 一问：为什么需要批量导入？ → "每次要导入几百条数据" 二问：为什么有这么多数据？ → "每月从ERP导出后再手工录入" 三问：为什么不直接对接？ → "IT说ERP太老了，没有API" 四问：ERP有没有升级计划？ → "明年有计划但不确定" 五问：升级前怎么办？ → "临时方案是每月导Excel" → 结论：短期做批量导入是合理过渡方案，但需规划API对接消除根因。只做导入不规划对接，一年后同样问题。

#### 需求管理4级成熟度

| 级别 | 特征 | 识别方法 |
| ------ | ------ | --------- |
| **L1 听啥做啥** | 用户说什么就做什么 | 需求池里全是"用户希望加个XX功能" |
| **L2 选择性执行** | PM有自己预设的答案 | 需求评审时PM一直在说服别人 |
| **L3 深挖根因** | 区分需求vs解决方案，平等对话 | PM问"为什么"的次数和问"怎么做"一样多 |
| **L4 平衡利益** | 识别部门利益，平衡多方诉求 | PM能说出每个需求的推动部门是谁 |

#### 输出物

1. **用户画像卡片**（B端多角色版本，每角色一页）
2. **用户旅程地图**（B2B版：认知→评估→采购→实施→使用→续约）
3. **JTBD卡片**（每类用户的Jobs To Be Done）
4. **需求池Excel**（标准字段：ID/来源/描述/角色/场景/优先级/状态/KANO分类）
5. **用户访谈记录**（模板：`references/templates/user-interview-b2b.md`）

#### AI加速
- 用AI分析客服工单文本 → 自动聚类常见问题类型
- 用AI生成访谈提纲（基于已知客户信息和行业）
- 访谈录音转文字 → AI摘要关键发现
- 多个访谈记录 → AI识别跨访谈的共性问题

---

### 阶段3：需求分析与排序

**角色帽：方案架构师 + 需求侦探**

#### 输入物
- 需求池（阶段2输出）
- 产品路线图（阶段1输出）
- 技术资源约束
- 本季度OKR

#### 方法论

##### KANO模型 — B端特化版

| 需求类型 | B端特征 | 典型示例 | 策略 |
| --------- | --------- | --------- | ------ |
| **基础型/Must-Be** | 缺则产品不可用，有也不加分 | 登录/权限/审计日志/数据CRUD | 做到80分，不能有短板 |
| **期望型/Performance** | 越多越好，线性关系 | 批量操作/导入导出/报表/移动端 | 持续提升，对标竞品 |
| **兴奋型/Delighters** | 有了惊喜，没有也能用 | AI智能推荐/自动化工作流/语音交互 | 差异化亮点，1-2个足够 |
| **无差异型** | 做不做都没感觉 | 过度设计的美化/小众格式 | **坚决砍掉** |
| **反向型** | 做了反而减分 | 过多的弹窗通知/强制的操作步骤 | **立刻去除** |

##### B端加权优先级评分法

综合优先级分 = 客户付费意愿(0-10) × 0.20 + 战略匹配度(0-10) × 0.15 + 对NRR的贡献(0-10) × 0.15 + 技术可行性(0-10) × 0.15 + 竞争覆盖度(0-10) × 0.10 + 实施复杂度(0-10,越低越好) × 0.10 + 对NDR的贡献(0-10) × 0.10 + 合规必要性(0-10) × 0.05

##### RICE模型（Intercom经典版）

RICE Score = (Reach × Impact × Confidence) / Effort

Reach（覆盖面）：多少个客户/用户在给定时间段内受影响？用客户数而非用户数（B端特有），区分"受影响"和"主动使用"

Impact（影响度）：对每个客户的影响有多大？3=巨大(客户KPI显著改善) 2=高 1=中 0.5=低 0.25=最低

Confidence（信心度）：你对估算有多确定？100%=高(有数据) 80%=中(部分证据) 50%=低(直觉) 20%=瞎猜(待验证)

Effort（工作量）：需要多少人月？用实际人月而非故事点（易于跨职能沟通）

##### MoSCoW（固定期限项目专用）

| 类型 | 含义 | 占比 | 策略 |
| ------ | ------ | ------ | ------ |
| **Must Have** | 没有就不算完成 | ≤60% | 必须在本版本交付 |
| **Should Have** | 重要但可替代 | ~20% | 尽量交付，有风险时可降级 |
| **Could Have** | 锦上添花 | ~20% | 有余力才做 |
| **Won't Have** | 明确不做（本期） | 本期0% | 放到Next或Later |

#### B端需求四象限（按价值/成本）

                高业务价值
                    │
     ┌──────────────┼──────────────┐
     │   战略项目    │   核心功能    │
     │  (长期投资)   │  (立即做)    │
     │  例：AI能力   │  例：审批流   │

高 ───┼──────────────┼──────────────┼─── 低 实现 │ │ │ 实现 成本 │ 不做/观望 │ 快速迭代 │ 成本 │ (放弃) │ (小成本快赢) │ │ 例：过度定制 │ 例：批量导出 │ └──────────────┼──────────────┘ │ 低业务价值

#### 输出物

1. **需求优先级排序表**（Excel，含评分明细）
2. **KANO分类结果**
3. **版本规划建议**（Now / Next / Later）
4. **需求评审材料**（PPT格式，用于需求评审会）

---

### 阶段4：方案设计（B端核心）

**角色帽：方案架构师 + 流程设计师**

这是B端PM最核心、最体现专业深度的阶段。方案设计不只决定"做什么功能"，更决定"组织如何运作"。参考杨堃《决胜B端》。

#### B端方案设计 7 大支柱

---

##### 支柱1：多角色权限模型设计

**三种权限模型选型：**

| 模型 | 描述 | 优点 | 缺点 | 适用场景 |
| ------ | ------ | ------ | ------ | --------- |
| **RBAC** | 基于角色的访问控制 | 简单、标准 | 不够灵活 | 90%企业场景 |
| **ABAC** | 基于属性的访问控制 | 灵活、精细 | 复杂、性能开销 | 高安全/合规场景 |
| **ReBAC** | 基于关系的访问控制 | 社交/层级场景 | 实现复杂 | 组织层级/审批链 |

**RBAC设计步骤（5步法）：**

Step 1: 枚举所有操作（页面/按钮/API/数据范围） Step 2: 定义角色（从组织架构出发，而非技术出发） ├── 超级管理员 - 全局配置、组织管理 ├── 系统管理员 - 日常管理、用户权限 ├── 部门管理员 - 本部门管理 ├── 业务操作员 - 核心业务操作 ├── 审批人 - 流程审批 ├── 审计员 - 只读+日志查看 └── 自定义角色 - 允许租户自定义 Step 3: 角色-操作映射（权限矩阵） Step 4: 用户-角色绑定（支持一个用户多角色） Step 5: 数据权限策略叠加（行级/列级）

**权限粒度层级：**

菜单级 → 页面级 → 按钮级 → 数据级(行) → 数据级(列) → 字段级 ↓ ↓ ↓ ↓ ↓ ↓ 能看到 能访问 能操作 能看到哪些 能看哪些 能编辑 哪些菜单 哪些页面 哪些按钮 数据范围 字段 哪些字段

**数据权限策略：**

| 策略 | 规则 | 适用角色 |
| ------ | ------ | --------- |
| 全部数据 | 不受限制 | 超级管理员 |
| 本部门及下级 | dept_path LIKE 'xxx%' | 部门管理员 |
| 仅本人 | creator_id = current_user_id | 普通操作员 |
| 指定范围 | 通过数据权限配置表 | 自定义角色 |
| 同组织 | tenant_id = current_tenant_id | 所有角色（基线） |

**输出物：** 角色权限矩阵表（Excel）+ 数据权限策略文档

---

##### 支柱2：审批流与工作流设计 (BPMN 2.0)

**审批节点类型完整目录：**

| 节点类型 | 说明 | 示例 |
| --------- | ------ | ------ |
| **人工审批** | 指定人/角色/岗位审批 | 部门经理审批 |
| **自动审批** | 满足条件自动通过 | 金额<500自动通过 |
| **条件分支** | 按条件走不同分支 | 金额>5000走财务审批 |
| **会签** | 所有人通过才通过 | 所有VP同意 |
| **或签** | 任一人通过即通过 | 值班审批 |
| **逐级审批** | 按组织层级逐级向上 | 组长→经理→总监→VP |
| **转审** | 转给他人审批 | 审批人不在时 |
| **加签** | 增加额外审批人 | 需要法务额外确认 |
| **抄送** | 通知但不参与审批 | 知会相关部门 |
| **撤回** | 发起人撤回 | 提交后发现有误 |
| **驳回** | 驳回（驳回到哪？） | 发起人/上一节点/指定节点 |

**审批效率设计原则：**

1. 审批节点 ≤ 5个（超过需论证必要性）
2. 每个节点审批人 ≤ 3人
3. 必须有超时策略（提醒/升级/自动通过/自动驳回）
4. 移动端必须可以审批（企微/钉钉/飞书集成）
5. 审批详情页包含：完整信息 + 审批历史 + 操作按钮 + 附件
6. 支持批量审批（同类申请一键通过）
7. 审批人视图：待审批列表 + 已审批列表
8. 发起人视图：我的申请 + 审批进度 + 撤销/催办

**异常流程处理（B端最易遗漏！）：**

| 异常场景 | 处理策略 |
| --------- | --------- |
| 审批人离职/调岗 | 自动转给上级或代理审批人 |
| 审批超时 | 提醒(24h) → 升级(48h) → 自动通过/驳回(72h) |
| 审批人就是发起人 | 自动跳过该节点 |
| 流程中组织架构变更 | 以发起时的组织架构为准 |
| 并发审批冲突 | 先到先得，后者提示 |
| 审批系统宕机 | 状态恢复后自动修复流转 |

**状态机图（核心交付物）：**
使用draw.io绘制完整状态机，包含所有状态的进入条件/退出条件/可执行操作。

**输出物：** 审批流状态机图(draw.io) + 审批规则配置表(Excel) + 异常场景处理表

---

##### 支柱3：多租户架构设计

**四种隔离策略与决策矩阵：**

| 策略 | 隔离强度 | 成本 | 实现复杂度 | 适用场景 |
| ------ | --------- | ------ | ----------- | --------- |
| **Database per Tenant** | ⭐⭐⭐⭐⭐ | 最高 | 中 | 金融/医疗等强合规 |
| **Schema per Tenant** | ⭐⭐⭐⭐ | 高 | 中高 | 头部客户有定制需求 |
| **Shared Table + tenant_id** | ⭐⭐ | 最低 | 低 | 标准化SaaS，中小客户 |
| **混合模式** | ⭐⭐⭐ | 中高 | 高 | 头部独立+长尾共享 |

**租户隔离决策树：**

客户合规要求高？→ 是 → Database per Tenant → 否 → 客户定制需求多？→ 是 → Schema per Tenant → 否 → 客户数量大？→ 是 → Shared Table → 否 → Hybrid

**租户级可配置项清单：**

| 配置类别 | 可配置项 | 实现方式 |
| --------- | --------- | --------- |
| 品牌 | Logo/主题色/名称 | 租户配置表 |
| 组织 | 部门层级/岗位/角色 | 树形配置 |
| 流程 | 审批规则/流程模板 | 工作流引擎配置 |
| 数据 | 自定义字段/编号规则/打印模板 | 扩展字段+规则引擎 |
| 权限 | 自定义角色/数据范围 | 权限引擎 |
| 报表 | 自定义报表/仪表盘 | 报表引擎 |
| 集成 | SSO配置/API Key/Webhook | 集成配置 |

**输出物：** 多租户架构设计文档 + 租户配置清单

---

##### 支柱4：数据字典与主数据管理(MDM)

**数据字典标准模板：**

| 字段名 | 字段编码 | 类型 | 长度 | 必填 | 默认值 | 唯一 | 索引 | 枚举值 | 校验规则 | 可配置 | 说明 |
| -------- | --------- | ------ | ------ | ------ | -------- | ------ | ------ | -------- | --------- | -------- | ------ |
| ID | id | bigint | - | 是 | auto | PK | - | - | - | 否 | 主键 |
| 名称 | name | varchar | 100 | 是 | - | 否 | - | - | ≤100字符 | 否 | 名称 |
| 状态 | status | varchar | 20 | 是 | 'draft' | 否 | idx_status | 见附表 | - | 否 | 状态 |
| 租户ID | tenant_id | bigint | - | 是 | - | 否 | idx_tenant | - | - | 否 | 多租户隔离 |

**主数据管理(MDM)核心实体：**

B端产品必须管理好这些主数据：
- 组织架构（公司→部门→岗位→员工）
- 客户/供应商主数据
- 产品/物料主数据
- 科目/项目/成本中心
- 合同/许可证

**数据库命名规范：**

表名：t_{模块前缀}{表名} → 例：t_pur_purchase_request 字段：snake_case → 例：created_at, creator_id 索引：idx{字段名} → 例：idx_tenant_id, idx_status 唯一索引：uk_{字段名} → 例：uk_request_no 外键：fk_{表名}_{字段名} → 例：fk_user_creator_id 布尔型：is_xxx / has_xxx → 例：is_deleted, has_attachment 时间型：xxx_at → 例：created_at, approved_at 金额型：xxx_amount (分) → 例：total_amount → DECIMAL(18,0)

**输出物：** 完整数据字典(Excel) + ER图(draw.io)

---

##### 支柱5：集成与开放能力设计

**企业集成模式(EIP)选型指南：**

| 集成模式 | 实时性 | 耦合度 | 适用场景 |
| --------- | -------- | -------- | --------- |
| 文件传输(SFTP) | 低 | 低 | 批量数据同步、对账 |
| RESTful API | 高 | 中 | 标准集成、对外开放 |
| 消息队列(MQ) | 高 | 低 | 异步解耦、事件驱动 |
| Webhook | 高 | 中低 | 事件推送、通知 |
| gRPC | 高 | 高 | 内部微服务 |
| 共享数据库 | 最高 | 最高 | 遗留系统对接（不推荐） |

**企业集成成熟度阶梯：**

L1: 文件导入导出（CSV/Excel） ← MVP至少做到 L2: Webhook + 消息通知 ← GTG阶段 L3: RESTful API（含API文档） ← 规模化必须 L4: SSO + 组织架构同步 ← 企业客户标配 L5: 深度集成（双向同步+嵌入式组件） ← 行业头部

**必须支持的集成清单：**
- SSO/身份认证：SAML 2.0、OAuth 2.0/OIDC、LDAP/AD域、CAS
- 消息通知：企业微信/钉钉/飞书、邮件(SMTP)、短信
- 电子签章：法大大/e签宝/上上签
- 企业支付：银企直连/对公转账/供应链金融
- 电子发票：电子发票平台对接
- 数据集成：ETL/数据同步/主数据分发

**OpenAPI设计规范（如果产品提供开放平台）：**

| 要素 | 规范 |
| ------ | ------ |
| 版本管理 | URL路径版本：/api/v1/ |
| 认证 | Bearer Token + API Key + App Secret |
| 限流 | 令牌桶算法，按API Key限流 |
| 文档 | OpenAPI 3.0规范，Swagger自动生成 |
| 错误码 | 统一4位错误码+message+details |
| 分页 | pageNum + pageSize，返回total |
| 格式 | JSON，UTF-8编码 |

**输出物：** 集成架构图(draw.io) + API设计文档

---

##### 支柱6：合规与审计设计

**B端产品必须考虑的合规体系：**

| 标准/法规 | 适用领域 | 核心要求 |
| ----------- | --------- | --------- |
| **等保2.0** | 中国境内系统 | 5级保护，一般企业需三级 |
| **GDPR** | 涉及欧盟用户数据 | 数据主体权利、DPO、跨境传输限制 |
| **个保法(PIPL)** | 中国境内个人信息 | 告知-同意、敏感信息单独同意、数据本地化 |
| **SOC 2 Type II** | SaaS出海 | 安全/可用/处理完整/保密/隐私 五大信任服务 |
| **ISO 27001** | 通用信息安全 | ISMS体系、风险评估、持续改进 |
| **信创** | 政企/央企 | 国产CPU/OS/DB/中间件适配 |
| **HIPAA** | 医疗健康（美国） | PHI保护、BA协议 |
| **PCI DSS** | 支付卡行业 | 持卡人数据保护 |

**审计日志设计规范：**

每条审计日志必须包含： ├── 谁（operator_id + operator_name + operator_role） ├── 什么时间（timestamp，精确到毫秒） ├── 做了什么（action：CREATE/READ/UPDATE/DELETE/EXPORT/APPROVE） ├── 操作了什么（resource_type + resource_id + resource_name） ├── 操作前数据（before_snapshot，JSON） ├── 操作后数据（after_snapshot，JSON） ├── 从哪里操作（IP + User-Agent + Session ID） ├── 操作结果（success/failure + error_detail） └── 审计日志本身：不可删除、不可修改、不可手动插入

**数据安全基线：**
- 传输：全站HTTPS、API签名
- 存储：敏感字段AES-256加密、密钥管理KMS
- 访问：RBAC最小权限、IP白名单、登录时段限制
- 脱敏：手机号/身份证/银行卡号显示时自动脱敏
- 备份：每日全量+增量，异地备份
- 灾备：RPO<1h, RTO<4h

---

##### 支柱7：B端产品架构设计

**从单体到中台的演进路径：**

阶段1：Excel → 单系统 → 多系统独立 → 系统打通 → 中台化 │ │ │ │ │ 初创期 成长期 扩张期 成熟期 平台期

中台架构（企业级产品终极形态）： ├── 业务中台：通用业务能力复用（用户/权限/审批/通知/支付/签章） ├── 数据中台：统一数据资产（主数据/指标体系/数据服务/数据治理） ├── 技术中台：技术基础设施（微服务/容器/CI-CD/监控/日志） └── 组织中台：组织能力沉淀（方法论/工具链/培训体系）

---

### 阶段5：AI产品设计

**角色帽：AI产品设计师**

AI正在重塑B端产品管理。AI PM不再是可选项，而是必选项。B端产品从"System of Record"升级为"System of Action"，AI是这场变革的核心引擎。

**参考来源：** O'Reilly(2025) / Stanford(2024) / Marty Cagan / Teresa Torres / 中国企业级AI产品设计10课

---

#### 5.1 AI PM能力模型（3类AI PM）

| 类型 | 描述 | 核心技能 |
| ------ | ------ | --------- |
| **AI Builder PM** | 构建AI模型/基础设施的产品 | 模型素养、训练管道、MLOps、评估 |
| **AI Experience PM** | 设计AI交互体验 | UX模式、HCI-AI、对话设计、信任设计 |
| **AI-Enhanced PM** | 用AI放大传统PM工作 | AI工具链、自动化、数据驱动决策 |

本Skill覆盖AI-Enhanced PM和AI Experience PM（B端最常见）。

---

#### 5.2 AI产品设计的10大模块（完整框架）

##### 模块1：模型选型与策略

**模型选型决策矩阵：**

| 维度 | 闭源API (如Claude/GPT) | 开源模型 | 自训练模型 |
| ------ | --------------------- | --------- | ----------- |
| 能力 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 成本 | 按量付费 | 推理成本可控 | 训练+推理成本高 |
| 数据安全 | 数据传到外部 | 完全本地 | 完全本地 |
| 合规性 | 需评估 | 好 | 最好 |
| 迭代速度 | 最快 | 中等 | 最慢 |
| 定制性 | Prompt+RAG | RAG+微调 | 完全定制 |
| 适用B端场景 | 通用场景、快速验证 | 数据敏感、私有化 | 垂直行业、极致定制 |

**B端选型决策树：**

数据能出企业吗？ ├── 是 → 数据量大吗？ │ ├── 是 → 闭源API + RAG（成本可控） │ └── 否 → 闭源API直接调用 └── 否 → 必须私有化部署 ├── 场景通用 → 开源模型 + RAG └── 场景特殊(如医疗/法律) → 开源模型 + 微调

**模型能力边界（每个AI PM必须懂）：**

| 能做好的 | 做不好的 | 怎么做不好的 |
| --------- | --------- | ------------ |
| 文本理解与生成 | 精确数学计算 | 用工具(function calling)补充 |
| 摘要与分类 | 实时信息 | 用RAG补充 |
| 翻译与改写 | 长文档精确记忆 | 上下文窗口限制 |
| 代码生成 | 推理链条过长 | Chain-of-Thought改善 |
| 情感分析 | 图像空间关系 | 不适用于纯视觉任务 |
| 格式转换 | 事实准确性 | 用RAG+来源引用 |

---

##### 模块2：RAG架构设计

**RAG是B端AI产品的核心架构。**

RAG标准流水线： ┌──────────────────────────────────────────────┐ │ 1. 文档摄入 │ │ ├── 文档解析(PDF/Word/HTML/图片OCR) │ │ ├── 分块(Chunking)：按段落/按语义/按固定长度 │ │ └── 元数据提取(文档名/日期/作者/权限标签) │ ├──────────────────────────────────────────────┤ │ 2. 向量化 (Embedding) │ │ ├── 文本→向量 (text-embedding-3-large等) │ │ └── 存入向量数据库 (Pinecone/Weaviate/Milvus)│ ├──────────────────────────────────────────────┤ │ 3. 检索 (Retrieval) │ │ ├── 混合检索：稠密向量 + 稀疏(BM25) │ │ ├── 重排序(Reranking)：对召回结果二次排序 │ │ └── 过滤：按权限/日期/标签过滤 │ ├──────────────────────────────────────────────┤ │ 4. 生成 (Generation) │ │ ├── 拼接上下文：System Prompt + Retrieved Context + User Query │ │ ├── 调用LLM生成答案 │ │ └── 引用标注：答案中标注信息来源 │ ├──────────────────────────────────────────────┤ │ 5. 评估与迭代 │ │ ├── 答案质量评估(准确性/相关性/完整性) │ │ ├── Bad Case分析→调优 │ │ └── 分块策略/检索策略迭代 │ └──────────────────────────────────────────────┘

**RAG设计关键决策：**

| 决策点 | 选项 | 推荐 |
| -------- | ------ | ------ |
| 分块大小 | 256/512/1024/2048 tokens | 512为主，关键段落1024 |
| 重叠 | 0/10%/20%/25% | 10-20%（避免语义切断） |
| 检索数量(top-k) | 3/5/10/20 | 5-10条 |
| Embedding模型 | text-embedding-3-large/small, bge-large-zh | 中文场景选bge |
| 向量数据库 | Pinecone/Milvus/Weaviate/Qdrant/pgvector | >100万向量用Milvus |
| 重排序 | Cohere Rerank/bge-reranker | 检索质量提升明显 |

---

##### 模块3：Agent与多智能体系统

**Agent = LLM + Memory + Planning + Tools**

**Agent vs 简单LLM调用：**

| 场景 | 简单LLM | Agent |
| ------ | --------- | ------- |
| 回答问题 | ✅ | 过剩 |
| 执行多步骤任务 | ❌ | ✅ |
| 需要调用外部工具 | ❌ | ✅ |
| 需要计划和反思 | ❌ | ✅ |
| 成本敏感 | ✅ | ❌（多轮调用成本高） |
| 延迟敏感 | ✅ | ❌（多轮调用延迟高） |

**Agent架构模式：**

模式1：ReAct (Reasoning + Acting) Thought → Action → Observation → Thought → ... → Final Answer

模式2：Plan-and-Execute Plan → Execute Step 1 → Execute Step 2 → ... → Summarize

模式3：Multi-Agent Orchestration Orchestrator → Agent A (Research) ↘ → Agent B (Analyze) → Orchestrator → Response → Agent C (Write) ↗

模式4：Human-in-the-Loop (HITL) Agent Execute → Human Approve → Agent Continue 关键：在哪些节点需要人类审批？（支付/发布/删除/对外发送）

**HITL设计（B端Agent的合规必备）：**

| 操作风险等级 | Agent行为 | 人类角色 | 示例 |
| ------------ | ---------- | --------- | ------ |
| **低风险** | Agent自主执行 | 事后抽查 | 添加标签、生成摘要 |
| **中风险** | Agent生成→人类确认 | 执行前确认 | 发送通知、修改状态 |
| **高风险** | Agent建议→人类执行 | 人类操作 | 删除数据、审批通过 |
| **不允许** | 禁止Agent操作 | 仅人类 | 支付、合同签署、权限变更 |

---

##### 模块4：Prompt Engineering（提示工程）

**提示工程是PM的新基本功。Prompt = B端AI产品的"UI"。**

**结构化Prompt设计模式：**

Prompt工程模板：System Prompt（角色+能力+任务+约束+输出格式）→ User Prompt（具体指令）→ Context（项目背景/相关文档/历史决策/约束条件）→ Examples（Few-shot示例）→ Output Format（JSON schema）

B端Prompt设计原则：

1. 角色精准（"有10年经验的财务审计师"而非"一个助手"）
2. 输出结构化（JSON Schema先行）
3. 约束明确（"不要编造数据"、"不知道就说不知道"）
4. 示例真实（用真实业务场景示例）
5. 安全护栏（"拒绝回答与XX无关的问题"）

---

模块5：Context Engineering（上下文工程）

Context Engineering是比Prompt Engineering更深层的设计。核心问题："给模型什么信息、以什么结构、在什么时机？"

上下文窗口预算管理：

总预算：200K–1M tokens（按当前主力模型，保守按200K规划，已于2026-07更正）

分配策略：
├── System Prompt：2-5K tokens (角色+规则+格式)
├── 对话历史：10-20K tokens (最近的对话)
├── RAG检索结果：20-40K tokens (最相关的文档)
├── 用户当前查询：0.5-2K tokens
├── 用户画像/偏好：2-5K tokens
├── 工具定义：5-10K tokens (function definitions)
└── 预留Buffer：~20K tokens (给模型思考/生成用)

动态上下文组装：

• 根据用户角色加载不同System Prompt
• 根据当前任务类型加载不同检索策略
• 根据用户行为历史个性化上下文
• 关键信息前置（最重要的信息放在Prompt开头和结尾）

---

模块6：Memory Engineering（记忆工程）

让AI从"一次性对话"升级为"持续合作伙伴"。

---

模块7：评测体系设计

没有评测就没有AI产品迭代。

评测维度矩阵：

Golden Dataset构建流程：

1. 收集100+真实用户Query
2. 人工标注标准答案
3. 建立评分标准(Rubric)
4. 定期更新(每月补充新Query)
5. Bad Case入库→分析→调优→验证

---

模块8：AI UX模式设计

B端AI产品的6种交互模式：

B端AI UX原则：

1. 渐进式信任：从低风险开始，逐步放开高风险
2. 可撤销：AI操作应可撤销
3. 可解释：AI为什么这样做？引用来源
4. 可覆盖：用户可随时手动接管
5. 展示不确定性：不确定时显示置信度

---

模块9：AI产品的数据飞轮

更多用户使用 → 更多交互数据 → AI效果更好 → 更多用户使用
    ↑                                              ↓
    └──────── 更好的数据质量 ← 更好的产品体验 ←──────┘

飞轮设计要点：
1. 每次用户交互都要产生可用于改进的数据
2. 隐式反馈（点击/停留/采纳）>> 显式反馈（点赞/打分）
3. Bad Case是金矿：每次失败都是改进的机会
4. 数据标注要嵌入产品流程（如"这个回答有帮助吗？"）

---

模块10：AI产品策略

楔子策略（O'Reilly推荐）：

传统路径：做平台 → 找场景 → 获取用户
AI时代路径：找一个痛点 → 解决得极好 → 获取信任 → 捕获数据 → 扩展

核心原则：
1. 从一个"英雄用户"的一个痛点开始
2. 做窄做深，不要做宽做浅
3. 简单的工具比复杂的Agent更值得信任
4. 数据是护城河，模型不是

B端AI产品的价值主张设计：

框架：技术功能 × 业务场景 × 量化收益

示例：
"通过大模型（技术功能）自动生成采购比价报告（业务场景），
 将采购决策时间从3天缩短至30分钟（量化收益）"

5.3 AI前沿范式增补（2025–2026，例行迭代新增）

本节为 2026-07 迭代新增，补齐"10大模块"之后的前沿范式。既有模块（RAG/Agent/Prompt/评测等）保持不动。

增补1：RAG 2.0 —— GraphRAG 与 Agentic RAG

• GraphRAG：在向量检索之外引入"知识图谱 + 实体/关系抽取"，先用 LLM 从文档抽取实体与关系构建图，再做"图检索 + 向量检索"混合回答。适合强关联、强推理场景（合同条款关联、组织架构、权限继承、产业链追溯）。
• Agentic RAG：用 Agent 替代"一次性检索"，自主决定"检索什么 / 检索几轮 / 是否换数据源 / 是否调用工具验证"。典型模式：Router-Retriever → Critique → Re-retrieve。适合答案需要多源交叉验证、长链条推理的 B 端场景。
• 落地建议：FAQ/单文档问答用基础 RAG 即可；跨文档推理、合规审查、审计追溯优先 GraphRAG/Agentic RAG。

增补2：MCP 作为 Agent 工具接入标准

• MCP（Model Context Protocol） 已成为 Agent 连接外部系统（数据库、ERP、CRM、文件系统、内部 API）的开放接入标准。B 端 AI 产品应优先用 MCP Server 暴露企业能力，而非为每个系统写一次性 function-calling 适配。
• PM 视角：把"企业内部系统能力"抽象为 MCP 工具清单（读/写/审批/查询），Agent 按权限与 HITL 矩阵调用；选型时优先评估目标系统的 MCP/开放 API 成熟度。

增补3：Computer Use 处理无 API 遗留系统

• 对没有开放 API 的老旧 B 端系统（legacy ERP/自研内网系统），可用 Computer Use（模型直接操作 GUI/浏览器） 作为"最后一公里"接入：让 Agent 像人一样点击、填表、读取页面。
• 风控：仅限低风险只读/录入场景，必须 HITL 确认 + 操作回放审计；严禁直接执行支付、权限变更等高危动作（对齐模块3的 HITL 矩阵）。

增补4：推理模型路由（Reasoning Model Routing）

• 不是所有任务都该调用最大模型。按任务复杂度做分层路由：
  • 轻量任务（分类/抽取/改写）→ 小模型/低成本 API；
  • 通用任务 → 标准大模型（Claude / GPT 系列）；
  • 强推理任务（多步规划、代码、数学、合规论证）→ 推理模型（OpenAI o1/o3、Claude 4 系列、GPT-5 等）。
• 三档模型推荐（2026-07 新增，按推理成本与能力明确分档路由）：
  • 简单档（分类/抽取/改写/摘要/格式转换）：GPT-4o-mini / Claude Haiku / Gemini Flash / Qwen-Turbo（中文场景性价比首选）
  • 中等档（通用问答/文档生成/标准分析/代码补全）：GPT-4.1 / Claude Sonnet 4 / Gemini 2.5 Pro / DeepSeek-V3（高性价比私有化部署）
  • 复杂推理档（多步规划/代码生成/数学证明/合规论证/跨文档推理）：OpenAI o1/o3 / Claude Opus 4.5 / DeepSeek-R1 / GPT-5
• 成本治理：在 Agent 编排层加"路由策略 + 预算上限 + 降级兜底"，避免所有请求都走最贵模型。

增补5：中文开源模型与信创大模型适配（国内版重点）

• 私有化首选：DeepSeek（V2/R1 系列，推理成本范式代表）、Qwen（通义千问，全尺寸开源）、GLM（智谱，ChatGLM/GLM 系列）是中文 B 端私有化/信创部署的首选基座。
• 信创大模型适配：在金融、政务、央国企等场景，需适配信创软硬件栈（国产 CPU/OS/数据库），优先选择已完成信创兼容互认证的开源/国产大模型，并在选型矩阵中增加"信创适配度"维度。
• 混合部署：敏感数据走私有化开源模型，通用能力走闭源 API，用统一网关做路由与脱敏。

增补6：Embedding 模型推荐更新

• 基础推荐补充：bge-m3（中英多语言、支持稠密/稀疏/多向量，中文 B 端首选）、Voyage AI（长上下文、代码/企业语料强）、Jina Embeddings（多语言、长文档友好）。
• 既有 text-embedding-3 / bge-large-zh 仍有效；新场景优先评估 bge-m3 / Voyage / Jina，并按"语言覆盖 + 上下文长度 + 检索精度"三维度选型。

AI产品设计输出物

1. AI产品策略文档（含模型选型/数据策略/飞轮设计）
2. RAG架构设计图
3. Agent设计文档（含HITL决策矩阵）
4. Prompt模板库
5. 评测体系设计（含Golden Dataset设计）
6. AI UX交互说明

---

阶段6：原型与交互

角色帽：方案架构师

B端原型核心原则：效率 > 美观。参考：Marty Cagan / 杨堃。

B端原型设计10原则

1. 列表页必须有：搜索/筛选/排序/分页/批量操作/导出
2. 表单必须有：必填标识/校验提示/保存草稿/提交确认
3. 详情页必须有：基本信息/关联信息/操作历史/返回
4. 每个操作必须有反馈（loading → success/error Toast）
5. 危险操作必须有二次确认弹窗
6. 批量操作必须有进度条
7. 大数据量：虚拟滚动/懒加载（超过1000条）
8. 键盘快捷键（Enter提交/Esc取消/↑↓选择/Ctrl+S保存）
9. 错误提示告诉用户"怎么办"不只是"出错了"
10. 空状态有引导（"还没有数据，点击新建第一条"）

B端标准页面模板（4类）

1. 仪表盘 Dashboard

**管理后台布局**：侧边栏（仪表盘/项目管理/需求池/迭代规划/文档中心/团队协作/数据分析/设置）+ 主内容区（欢迎语+KPI卡片+图表+最近活动）+ 顶部导航（消息/头像/设置）

##### 2. 列表页 CRUD List

数据列表页模板：搜索+筛选（状态▼/日期范围▼）+ 操作（导出/新建）+ 表格（全选/ID/名称/状态/负责人/日期）+ 分页。状态：🟢进行中/🟡待审批/🔴已延期/✅已完成

3. 表单页 Form

**客户360视图**：客户[名称] | 行业[行业] | 等级[A/B/C] | CSM[姓名] | 订阅至[日期] | 席位使用率 | 功能使用率（项目管理/文档协作/即时通讯/审批流程）| 健康分[XX/100] | 风险信号

##### 4. 审批详情页

审批流示例：AP20260607001 | 状态：审批中(2/3) | 申请人：张三 | 审批链：直属上级✅→部门负责人⏳→财务⬜ | 内容：企业版协作工具50席位 ¥125,000/年 | 历史：建议对比竞品，已补充对比表

原型产出方式

方式一：HTML交互原型（推荐，0工具依赖）

• HTML+Tailwind CSS+Alpine.js/Vue3 CDN
• 真实数据和交互，浏览器直接运行
• 包含所有页面状态（加载/空/错误/边界）
• 模拟权限控制（切换角色查看不同视图）
• 审批流交互可视化（模拟通过/驳回流转）

方式二：Penpot（开源Figma替代）

• 开源(MPL-2.0)，Web-based，可自托管
• 支持：矢量编辑/交互原型/组件/设计Token/实时协作
• Plugin API、REST API、MCP Server
• 中文友好

方式三：即时设计（国内Figma替代）

• 免费Web版，中文原生
• D2C（设计稿→代码）+ BoardMix协作白板

原型工具调用表

---

阶段7：图表与架构

角色帽：方案架构师 + 流程设计师

图是B端PM的通用语言。一图胜千言，专业图表决定方案评审通过率。

---

12类B端必画图表（含工具与命令）

可用图表工具矩阵

图表产出自检清单

□ 受众是谁？（高管=极简/技术=详细/客户=产品价值导向）
□ 核心信息能一句话说清吗？
□ 图例/颜色/符号是否一致？（同一系统用同一颜色）
□ 是否有标题 + 版本 + 日期？
□ 箭头方向是否正确？
□ 是否标注了关键决策点/异常分支？
□ 是否有遗漏的角色/系统/实体？
□ 颜色是否适合黑白打印？

B端图表配色规范

企业沉稳系（默认）：
- 主色：#1a56db (蓝色-核心系统)
- 辅助：#0e9f6e (绿色-外部系统)
- 警告：#e3a008 (黄色-待优化)
- 危险：#e02424 (红色-风险点)
- 中性：#6b7280 (灰色-非重点)
- 背景：#f9fafb
- 文字：#111827

科技蓝色系：
- 主色：#2563eb
- 辅助：#7c3aed (紫色-差异化)
- 强调：#06b6d4 (青色-亮点)

---

阶段8：文档工程

角色帽：方案架构师 + 产品布道师

B端PM的文档能力 = 跨团队协作效率杠杆。参考：Cagan / 杨堃。

文档矩阵

B端PRD必须包含的10大模块

1. 版本历史与变更记录
2. 需求背景与商业目标（含BRD链接，数据支撑）
3. 用户角色与权限矩阵 ← B端独有
4. 核心业务流程图（泳道图，正常+异常） ← B端独有
5. 功能详细说明（含原型/字段表/交互说明/权限/状态）
6. 审批流与工作流设计 ← B端独有
7. 数据模型设计（ER图+数据字典） ← B端独有
8. 集成与接口需求（内部+外部+OpenAPI） ← B端独有
9. 非功能需求（性能/安全/可用/扩展/国际化）
10. 验收标准与测试要点（每个AC可逐条验收）

文档生成工作流

你说需求 → AI确认结构 → 生成Markdown初稿 →
你确认→ 格式化为最终版 → 可选：转DOCX/PDF/PPT

转DOCX: 使用 word-docx skill (格式规范，符合GB/T)
转PDF: 使用 minimax-pdf skill (中文排版，设计精美)
转PPT: 使用 ppt-generator skill (提取要点，自动排版)

文档质量自检（4级标准）

核心交付物至少白银级，关键决策文档争取黄金级。

---

阶段9：开发协作

角色帽：项目管理者

标准开发协作SOP

需求评审 → 技术方案评审 → 任务拆解(WBS) → Sprint规划 →
每日站会 → 进度跟踪 → 测试验收 → 发布上线 → 复盘

双周迭代节奏（B端标准）

Day 1-2:  PRD编写/完善
Day 3:    需求评审会（产品+开发+测试+UED）
Day 4-6:  技术方案设计
Day 7:    技术方案评审 + 任务拆解
Day 8-13: 开发（含联调）
Day 12-15: 测试
Day 16:   产品验收
Day 17:   上线准备（发布说明/帮助文档/灰度策略）
Day 18:   全量发布
Day 19-20: 线上监控 + 复盘

B端需求评审检查清单

□ 每种角色都考虑到了？（不仅是核心使用者）
□ 异常流程完整？（超时/驳回/撤回/权限不足/并发冲突）
□ 大数据量性能？（10万+条列表/1000+条批量）
□ 数据一致性？（事务边界/分布式一致性）
□ 历史数据兼容/迁移方案？
□ 权限控制覆盖所有操作？（读/写/批/导/审）
□ 审计日志覆盖所有CUD操作？
□ 通知/提醒触发是否正确？
□ 多语言/多时区/多币种？
□ 移动端审批适配？
□ 是否有需要预研的技术风险？

验收标准AC写法

格式：Given [前置条件] When [用户操作] Then [预期结果]

示例：
AC-001: Given 用户是采购申请员且有新增权限
        When 用户填写所有必填项并点击[提交]
        Then 系统创建采购申请记录，状态为"审批中"，
             并触发审批流，下一节点审批人收到通知

AC-002: Given 采购申请状态为"审批中"且当前审批人是张三
        When 张三点击[驳回]并填写驳回原因
        Then 采购申请状态变为"已驳回"，
             发起人收到驳回通知，
             发起人可编辑后重新提交

发布前检查清单

□ P0测试用例全部通过
□ P0 Bug全部修复
□ 数据迁移脚本就绪（如有）
□ 回滚方案就绪
□ 帮助文档已更新
□ 发布公告已准备
□ 客户通知已发出（如涉及已有客户）
□ 监控告警已配置
□ 灰度方案已确定

AI辅助研发（Coding Agent，2026-07 新增）

双周迭代之外，AI 编程已成为 B 端研发提效的核心杠杆。PM 不必写代码，但需懂如何与 Coding Agent 协作、设定边界与验收。

Coding Agent 协作模式：

PM 协作要点：

1. 需求即规格：把 AC（Given/When/Then）直接作为 Coding Agent 的输入，可机器校验的需求优于自然语言描述。
2. 小步提交 + 持续验证：要求 Agent 小粒度 PR、配套单测，避免一次性大改动难以 review。
3. 边界与禁区：Agent 禁止直连生产库、禁止擅自改鉴权/权限模型、禁止删除迁移脚本（对齐 HITL 高风险清单）。
4. 国产/私有化栈：在信创与数据敏感场景，优先使用可私有化部署的 Coding Agent（如基于 Qwen/DeepSeek 的本地编码模型 + 企业代码库 RAG）。

---

阶段10：数据与增长

角色帽：数据策略师

B端核心指标体系（5层金字塔）

L1: 北极星指标 (1个)
    └── L2: 一级指标 (4-6个)
         ├── 获客：MQL→SQL→赢单率→CAC→CAC Payback
         ├── 激活：Onboarding完成率 → Time to First Value
         ├── 使用：DAU/WAU/MAU → 功能采用率 → 粘性系数
         ├── 收入：ARR/MRR → ARPU → LTV → NRR → NDR
         └── 质量：NPS/CSAT/CES → Churn Rate
              └── L3: 二级指标 (10-20个，操作级)
                   └── L4: 三级指标 (诊断级，按需)

B端北极星指标选择指南

B端特有指标详解

B端产品阶段与指标聚焦

数据看板设计原则

1. 一屏看完（不需要滚动）
2. 7-10个核心指标，不要多
3. 有对比（vs上周/上月/去年同期）
4. 有预警线（红黄绿）
5. 有下钻入口（点击进入详情）
6. 每周自动推送报告

---

阶段11：商业化与GTM

角色帽：商业化操盘手 + 产品布道师

B端定价策略深度

定价模式决策树

你的产品是？
├── 协作型（多人使用才有价值）→ 按用户/席位数
├── 功能差异大 → 按功能分层(Good/Better/Best)
├── 用量驱动 → 按用量/API调用/存储
├── 交易平台 → 按GMV抽佣/固定费率
└── 混合型 → 基础费+用量费 或 基础费+功能分层

套餐设计铁律

1. 3个套餐最优：基础版 / 专业版(推荐) / 企业版
2. 中间套餐是锚点：利润最高、推荐最多
3. 企业版必须有"联系销售"：留资入口，让大客户主动联系
4. Free Trial > Free Plan
5. 年付8折是标配（降低流失，改善现金流）
6. 定价数字心理：¥9,999 > ¥10,000

定价数字策略

月付 → 年付折扣：月付×10（≈83折）
阶梯价格：用户数越多，边际单价越低
锚定效应：展示企业版高价，让专业版"看起来很值"
价格页设计：推荐套餐高亮（"最受欢迎"标签）、功能对比表、FAQ区

GTM策略一页纸

1. ICP（Ideal Customer Profile）：目标客群画像
2. 价值主张一句话
3. 定价与套餐
4. 销售渠道：直销/渠道/PLG/混合
5. 销售材料包：一页纸/白皮书/Demo脚本/竞争对比表/ROI计算器
6. Onboarding流程（客户90天健康计划）
7. 市场推广计划
8. 关键里程碑与目标

销售赋能包全套清单

---

阶段12：运营与迭代

角色帽：客户成功伙伴 + 产品布道师

B端客户生命周期管理

获客 → Onboarding → Adoption → Value → Expansion → Renewal/Advocacy
  ↑                                                          ↓
  └────────────────── 持续反馈循环 ──────────────────────────┘

客户健康度模型

客户健康度 Score =
  产品使用深度 × 0.30 +
  关键人活跃度 × 0.20 +
  NPS/CSAT × 0.15 +
  工单频率(反向) × 0.15 +
  增购信号 × 0.10 +
  合同剩余时间 × 0.10

红黄绿阈值：
- 绿（>75）：健康，按常规节奏
- 黄（50-75）：预警，CSM主动介入
- 红（<50）：高风险，升级处理，制定挽救计划

B端产品运营框架

产品运营4大模块：
├── 客户运营：Onboarding→Adoption→定期的价值复盘→续约
├── 功能运营：功能使用分析→低采用率排查→培训/优化→淘汰
├── 内容运营：帮助文档/最佳实践/产品博客/培训视频
└── 数据运营：指标监控→异常预警→数据洞察→驱动迭代

---

高级工作流体系

高级B端PM的标准工作流、会议节奏和OKR体系。

一、双轨敏捷（Dual-Track Agile）

轨道1：Discovery（发现） — 持续探索"做什么"

• 用户访谈 → 机会识别 → 方案假设 → 原型验证 → 实验 → 验证通过进入交付

轨道2：Delivery（交付） — 高效执行"怎么做"

• Sprint Planning → 开发 → 测试 → 验收 → 发布

双轨衔接点： Discovery验证通过的需求进入Delivery Backlog 产品三人组： PM（价值）+ Designer（体验）+ Tech Lead（可行性）

二、持续发现系统（Teresa Torres）

5个核心习惯：

1. 每周至少访谈1个客户（产品三人组一起）
2. 构建机会解决方案树(OST)：Outcome → Opportunities → Solutions → Experiments
3. 假设驱动：列出假设→按风险排序→先测最危险的
4. 小而快的实验：访谈/原型/假门测试/调查问卷
5. 产品三人组全员参与发现

故事式访谈法：

• ❌ 不要问："你会用这个功能吗？"
• ✅ 应该问："告诉我你上次[做某件事]的经历"
• 收集真实的过去行为，而不是假想行为

三、产品运营模型（Marty Cagan）

5大核心原则：

四、标准工作流SOP（完整版）

**需求收集与研判流程**：客户反馈+销售输入+CSM反馈 → 需求收集池 → 用户研究/竞品分析/数据分析 → 需求研判(RICE/ICE) → 进入产品Backlog

### 五、B端PM的标准周/月/季节奏

**每周节奏：**
| 时间 | 事项 | 说明 |
| ------ | ------ | ------ |
| 周一上午 | 周会 | 回顾上周、对齐本周 |
| 每早 | 站立会(15min) | 同步进度和blocker |
| 周二 | 客户访谈/需求调研 | 至少1次/周 |
| 周三 | 产品设计/PRD写作 | 深度工作时间 |
| 周四 | 跨部门沟通/同步会 | 与销售/CSM/市场对齐 |
| 周五 | 数据review + 下周规划 | 收尾+下周准备 |

**月度节奏：**
| 时间 | 事项 |
| ------ | ------ |
| 月初 | OKR进展回顾、月度汇报准备 |
| 月中 | 需求评审会、方案设计 |
| 月末 | 月度产品汇报(PPT)、下月规划 |

**季度节奏：**
| 时间 | 事项 |
| ------ | ------ |
| 季前4周 | OKR草案→对齐→确定 |
| 季前1周 | OKR最终确定、季度启动会 |
| 季中 | OKR中期检查、调整策略 |
| 季末 | OKR评分、季度复盘、下季OKR启动 |
| 季度 | 季度业务评审QBR（2小时）、竞品复盘、路线图刷新 |

### 六、OKR工作流(季度标准)

Week -4: 收集顶层优先事项，调查团队，识别上季度结转 Week -3: 起草公司OKR → 分享征求意见 → OKR峰会 Week -2: 团队OKR对齐 → 跨团队依赖关系 → OKR回放会 Week -1: OKR最终确定 → 季度启动会 Week 1-12: 每周OKR检查（信心指数1-10分） Week 13: OKR评分 → 季度复盘

OKR黄金法则：

• 每季度3-5个O，每个O 2-4个KR
• 70%达成率 = 成功（100%说明目标太保守）
• 关注结果非产出：不是"上线XX功能"，而是"XX指标从A提升到B"

---

## 能力模型与职业发展

### B端PM能力金字塔

           ┌──────────────┐
           │  商业认知     │  ← 行业洞察/商业模式/企业架构
           │  (40%)       │
           ├──────────────┤
           │  系统设计     │  ← 产品规划/需求分析/业务建模/
           │  (25%)       │     权限设计/报表设计/项目管理
           ├──────────────┤
           │  项目管理     │
           │  (20%)       │
           ├──────────────┤
           │  商业嗅觉     │
           │  (15%)       │
           └──────────────┘

### 中国企业PM能力模型对比（腾讯/阿里/字节）

| 维度 | 腾讯 | 阿里(B2B) | 字节跳动 |
| ------ | ------ | ----------- | --------- |
| 核心导向 | 用户价值至上 | 商业变现+平台思维 | 数据驱动+极致执行 |
| 通用能力 | 学习/沟通/执行/韧性 | 需求洞察/趋势判断/独立思考 | 数据敏感度/实验思维 |
| 专业能力 | 用户研究/市场分析/产品设计 | 商业变现/中台构建/机制设计 | SQL/AB测试/增长黑客 |
| 组织影响力 | 方法论建设/知识传承/人才培养 | 跨部门协同/平台规则设计 | Context not Control |
| 决策依据 | 用户研究+共识 | 商业价值+战略 | 数据+实验 |
| 级别体系 | T1-T6 | P5-P10 | 弹性+横向流动 |

### PM到CPO的成长路径

| 级别 | 经验 | 核心能力要求 |
| ------ | ------ | ------------ |
| **初级PM** | 0-2年 | 需求执行、PRD撰写、基础数据分析、用例设计 |
| **中级PM** | 2-5年 | 独立负责模块、用户洞察、跨部门协调、版本规划 |
| **高级PM** | 5-8年 | 产品线策略、商业变现、架构设计、团队指导 |
| **产品专家/组长** | 8-10年 | 领域深度、多产品线协调、组织影响力、方法论建设 |
| **产品总监** | 10-12年 | 产品组合战略、P&L、组织建设、高管沟通 |
| **VP/CPO** | 12年+ | 公司产品愿景、投资组合、产品文化、组织变革 |

### B端PM硬技能清单

必会： □ 业务建模（ER图、UML、数据字典） □ 权限设计（RBAC/ABAC） □ 数据库基础（至少会写SQL） □ API设计（RESTful基本概念） □ 数据分析和埋点设计 □ 项目管理（敏捷/Scrum/Kanban）

进阶： □ 企业架构（TOGAF基础/4A架构） □ AI产品设计（RAG/Agent/Prompt Engineering） □ 微服务架构基础概念 □ 多租户架构设计 □ 合规知识（等保/GDPR/个保法/SOC2） □ 财务基础（定价/预算/ROI/NRR）

---

## 图表工场

### 一键画图

直接描述你要画什么，自动匹配工具生成 `.drawio` 可编辑源文件。

"画采购审批泳道图，角色：采购员/采购主管/财务/总经理" "画CRM系统的C4容器图" "画XX模块的ER图" "画审批流状态机图" "画手绘风格的用户旅程图，角色：企业采购经理"

### 工具调用规则

| 图表类型 | 首选工具 | 备选 |
| --------- | --------- | ------ |
| 架构图(系统/功能/集成/部署) | drawio-skill | drawio-coderknock |
| 业务流程图(泳道) | drawio-skill | processon-diagram |
| 数据图(ER/数据模型) | drawio-generator-pro | drawio-skill |
| 手绘风格(旅程图/蓝图/线框) | excalidraw-diagram | - |
| 状态机/审批流 | drawio-skill | - |
| 路线图/甘特图 | drawio-skill | - |

输出：`.drawio` + `.png` 预览（含内嵌XML，随时用draw.io编辑）

---

## 原型工场

### 一键生成可交互原型

"生成一个企业采购管理后台的HTML原型，包含：仪表盘/采购申请列表/新增申请表单/审批详情" "生成一个CRM合同管理列表页原型，带搜索筛选批量操作分页"

输出：完整HTML文件（Tailwind CSS + Alpine.js CDN），浏览器直接运行，包含：
- 侧边导航+顶部栏+面包屑
- 表格带排序/筛选/分页/多选
- 表单带校验（必填/格式/长度）
- 弹窗确认/抽屉详情
- 审批流状态可视化
- 切换角色查看不同权限视图
- 模拟数据

---

## 文档工场

### 一键生成专业文档

"写一份企业采购管理的完整PRD" "写一份HR SaaS的市场需求文档MRD" "做一份钉钉OA审批的竞品分析报告"

流程：描述需求 → 确认结构 → 生成Markdown → 可选转为DOCX/PDF/PPT

### 转格式命令

| 需求 | 调用 |
| ------ | ------ |
| MD转DOCX | `word-docx` skill → 标准中文排版 |
| MD转PDF | `minimax-pdf` skill → 设计精美 |
| 要点转PPT | `ppt-generator` skill → 自动排版 |
| 数据转Excel | `xlsx` skill → 专业格式 |

---

## PPT工场

### B端PPT类型

| 类型 | 页数 | 适用 | 配色建议 |
| ------ | ------ | ------ | --------- |
| 产品立项汇报 | 8-12页 | 立项评审会 | 企业沉稳 |
| 产品方案评审 | 12-18页 | 需求/方案评审 | 企业沉稳/科技蓝 |
| 管理层月报 | 5-8页 | 月度汇报 | 企业沉稳 |
| 客户宣讲材料 | 10-15页 | 售前/行业会议 | 科技蓝/高端深色 |
| 行业峰会演讲 | 15-25页 | 市场活动 | 高端深色 |

### 配色方案

| 方案 | 适用 |
| ------ | ------ |
| 企业沉稳（深蓝+白） | 内部汇报/管理层 |
| 科技深蓝（蓝+紫渐变） | 技术评审/客户演示 |
| 专业灰（灰+品牌色） | 文档型PPT |
| 高端深色（深灰+金色） | 峰会演讲 |
| 政务红（红+白+灰） | 政府/国企客户 |

---

## 工具集成总表

### 本Skill自动调用的工具

| 任务 | 首选工具 | 备选 |
| ------ | --------- | ------ |
| 画架构图/流程图/ER图 | `drawio-skill` | `drawio-coderknock` / `drawio-generator-pro` |
| 画手绘图/线框图 | `excalidraw-diagram` | - |
| 在ProcessOn画图 | `processon-diagram-generator` | - |
| 做PPT | `ppt-generator` | `ppt-generator` / `ppt-master` |
| 写Word文档 | `word-docx` + `word-cn-format` | - |
| 写PDF | `minimax-pdf` | `md-to-pdf-cjk` |
| 写Excel | `xlsx` | - |
| 生成原型 | 直接生成HTML (Tailwind+Alpine.js) | - |
| 项目管理（如需要） | Plane / Jira / Linear (API) | - |
| 数据分析（如需要） | PostHog / Amplitude (概念指导) | - |

### 工具决策原则

1. **自动选择最优**：不需要用户指定工具
2. **可编辑源文件优先**：drawio→.drawio，PPT→.pptx
3. **预览同步输出**：图表同时输出.png预览
4. **中文排版标准**：中文文档符合GB/T标准

---

## 使用示例

### 示例1：从0到1做一款B2B SaaS产品

用户：帮我从0到1规划一款企业合同管理SaaS

产出顺序： 阶段1 → 行业分析(市场规模/趋势/竞品) + 产品战略一页纸 阶段2 → 用户画像(法务/销售/高管3角色) + 用户旅程图 + JTBD卡片 阶段3 → 需求池 + KANO分类 + RICE优先级排序 阶段4 → 权限矩阵 + 审批流设计 + 数据字典 + 集成方案 阶段5 → (如涉及AI功能)AI功能设计文档 阶段6 → HTML交互原型(仪表盘/合同列表/审批详情/模板库) 阶段7 → 业务泳道图 + 系统架构图(C4) + ER图 + 状态机图 阶段8 → 完整PRD文档 + 转为DOCX/PDF 阶段11 → 定价方案(3套餐) + 销售一页纸 + Demo脚本

### 示例2：现有产品加AI功能

用户：给我的CRM系统加一个AI智能合同审查功能

产出顺序： 阶段5 → AI能力方案：模型选型(闭源API+RAG) + RAG架构(合同条款检索) + Prompt工程(审查规则) + HITL设计(AI建议→人确认) + 评测体系(Golden Dataset) 阶段4 → 权限设计(谁可以用AI审查) + 审计设计(AI建议需记录) 阶段6 → HTML原型(合同上传→AI审查→风险标注→人工复核) 阶