"运营-产品协同加速套件。解决运营与产品之间的信息不对称、需求扯皮、效果归因等痛点。用于:(1) 运营需求翻译为产品语言;(2) 效果归因框架生成;(3) 优先级智能计算;(4) 验收标准自动生成;(5) 数据口径对齐;(6) 协同文档生成。触发词:运营需求、产品协同、效果归因、需求扯皮、数据口径、验收标准、优先级评估。"

v1.0.0

运营-产品协同加速套件。解决运营与产品之间的信息不对称、需求扯皮、效果归因等痛点。用于:(1) 运营需求翻译为产品语言;(2) 效果归因框架生成;(3) 优先级智能计算;(4) 验收标准自动生成;(5) 数据口径对齐;(6) 协同文档生成。触发词:运营需求、产品协同、效果归因、需求扯皮、数据口径、验收标准、优先级评估。

0· 82·0 current·0 all-time
bySocialite UCL LJH@lijinhongucl-pixel

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for lijinhongucl-pixel/ops-pm-bridge.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill ""运营-产品协同加速套件。解决运营与产品之间的信息不对称、需求扯皮、效果归因等痛点。用于:(1) 运营需求翻译为产品语言;(2) 效果归因框架生成;(3) 优先级智能计算;(4) 验收标准自动生成;(5) 数据口径对齐;(6) 协同文档生成。触发词:运营需求、产品协同、效果归因、需求扯皮、数据口径、验收标准、优先级评估。"" (lijinhongucl-pixel/ops-pm-bridge) from ClawHub.
Skill page: https://clawhub.ai/lijinhongucl-pixel/ops-pm-bridge
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install ops-pm-bridge

ClawHub CLI

Package manager switcher

npx clawhub@latest install ops-pm-bridge
Security Scan
Capability signals
Crypto
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The name/description (运营-产品协同) match the provided content: SKILL.md, README, and reference docs all describe translation, attribution, priority scoring, acceptance criteria, data-alignment and doc generation. There are no unrelated environment variables, binaries, or external services required.
Instruction Scope
SKILL.md contains only templates, example commands (slash-style usage), YAML/SQL/examples and guidance for producing documents and reports. It does not instruct the agent to read system files, access environment variables, call arbitrary network endpoints, or exfiltrate data. The README suggests copying the folder into local skill directories (e.g., ~/.openclaw/skills or ~/.hermes/skills) to enable the skill — that's a usage/install hint, not an automatic installer or network call.
Install Mechanism
There is no install spec and no code files — the skill is instruction-only (docs and examples). No downloads, extracts, or package dependencies are declared. The only 'install' text is a manual copy suggestion in README, which is low-risk but requires trusting the source before copying into a skills directory.
Credentials
The skill declares no required environment variables, credentials, or config paths. None of the documents reference secret names or unrelated credentials. The documented SQL/YAML examples reference typical product data sources conceptually (orders, activity), but do not access them programmatically or require credentials.
Persistence & Privilege
always is false and the skill is user-invocable. It does not request persistent system-level privileges, nor does it instruct modification of other skills or global agent settings. Being an instruction-only skill, it has minimal runtime privilege requirements.
Assessment
This skill appears to be a coherent, documentation-only toolkit for ops–product collaboration and does not request credentials or run code. Before installing, verify the source (the package metadata owner is unknown) and ensure you trust the files you copy into your agent's skills directory. Because the README suggests manually copying files into ~/.openclaw/skills or ~/.hermes/skills, inspect the files locally (they are plain text) and confirm there are no added scripts or binaries before copying. If the skill is later updated to include install scripts, binaries, or network endpoints, re-evaluate — those changes would raise new risks.

Like a lobster shell, security has layers — review code before you run it.

latestvk978yp3pdnjvxq8nx12bfkjpc584sjsf
82downloads
0stars
1versions
Updated 2w ago
v1.0.0
MIT-0

Ops-PM Bridge - 运营产品协同加速套件

解决运营与产品之间的信息不对称、需求扯皮、效果归因等核心痛点。

核心痛点与解决方案

痛点解决方案命令
信息不对称需求双向翻译/ops-translate
需求扯皮优先级智能计算/priority-calc
效果归因争议统一归因框架/attribution
验收标准模糊自动生成验收标准/acceptance
数据口径不一致数据定义对齐/data-align
协同文档分散一键生成协同文档/ops-doc

1. 需求翻译器 (/ops-translate)

功能

运营语言 ↔ 产品语言双向翻译,消除理解偏差。

使用场景

  • 运营提出需求,产品理解有偏差
  • 产品给出方案,运营看不懂技术术语

输入格式

运营 → 产品翻译:

/ops-translate --from ops --to pm
运营需求:我们要搞个大促活动,用户参与度要高一点

产品 → 运营翻译:

/ops-translate --from pm --to ops
产品方案:实现用户增长模块,包含邀请码、裂变奖励、等级体系

输出示例

## 运营需求翻译(运营 → 产品)

### 原始需求
我们要搞个大促活动,用户参与度要高一点

### 产品语言翻译
- **功能需求**:营销活动模块
- **核心指标**:用户参与率提升 ≥ 30%
- **具体功能点**:
  1. 活动落地页配置后台
  2. 用户任务系统(签到、分享、邀请)
  3. 积分/优惠券奖励发放
  4. 实时数据看板
- **技术可行性**:✅ 可实现
- **预估工期**:2 周
- **依赖资源**:设计、前端、后端

### 需要确认的问题
1. 活动周期是多久?
2. 预算范围是多少?
3. 目标用户群体是全量还是特定人群?

2. 效果归因框架 (/attribution)

功能

统一数据口径,建立清晰的归因逻辑,避免效果争议。

输入格式

/attribution
活动名称:双11大促
目标:提升 GMV
涉及渠道:App推送、短信、社群、投放

输出示例

## 效果归因框架

### 一、数据口径定义

| 指标 | 定义 | 数据源 | 计算公式 |
|------|------|--------|----------|
| 活动GMV | 活动期间成交总额 | 订单系统 | SUM(订单金额) WHERE 活动ID = X |
| 参与用户数 | 至少完成1个任务的用户 | 活动系统 | COUNT(DISTINCT user_id) |
| 转化率 | 参与用户中下单的比例 | 订单+活动 | 下单用户数 / 参与用户数 |
| 渠道贡献 | 各渠道带来的GMV占比 | 埋点+订单 | 渠道GMV / 总GMV |

### 二、归因逻辑

#### 首次触点归因
- 用户首次接触活动的渠道获得 100% 归因
- 适用场景:品牌认知类活动

#### 末次触点归因
- 用户下单前最后一次接触的渠道获得 100% 归因
- 适用场景:促销转化类活动

#### 线性归因(推荐)
- 用户路径上所有触点平均分配归因
- 适用场景:多渠道协同类活动

#### 时间衰减归因
- 越接近转化的触点获得越高权重
- 计算公式:权重 = 0.5^(n-1),n 为距离转化的天数

### 三、归因配置

```yaml
attribution:
  model: "time_decay"  # 首次/末次/线性/时间衰减
  lookback_window: 7   # 回溯窗口(天)
  
  channels:
    - name: "App推送"
      cost: 0
      weight: 1.0
      
    - name: "短信"
      cost: 5000
      weight: 1.0
      
    - name: "社群"
      cost: 2000
      weight: 1.0
      
    - name: "投放"
      cost: 50000
      weight: 1.0
  
  metrics:
    primary: "GMV"
    secondary:
      - "参与用户数"
      - "转化率"
      - "ROI"

四、争议处理规则

  1. 跨渠道争议:采用时间衰减归因,数据为准
  2. 时间范围争议:以活动配置的起止时间为准
  3. 指标定义争议:以本文档定义为准,变更需双方确认

---

## 3. 优先级计算器 (`/priority-calc`)

### 功能
基于多维度自动计算需求优先级,减少扯皮。

### 输入格式

```json
{
  "requirements": [
    {
      "name": "用户增长裂变功能",
      "business_value": 5,      // 业务价值 1-5
      "urgency": 4,             // 紧急程度 1-5
      "effort": 3,              // 开发成本 1-5(越大越复杂)
      "risk": 2,                // 风险程度 1-5
      "stakeholder": 4          // 干系人重要程度 1-5
    }
  ],
  "weights": {
    "business_value": 0.35,
    "urgency": 0.25,
    "effort": -0.15,            // 负权重,成本越高优先级越低
    "risk": -0.10,
    "stakeholder": 0.15
  }
}

输出示例

## 需求优先级评估报告

### 排序结果

| 排名 | 需求名称 | 综合得分 | 业务价值 | 紧急度 | 开发成本 | 风险 | 干系人 |
|------|----------|----------|----------|--------|----------|------|--------|
| 1 | 用户增长裂变功能 | **3.85** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 2 | 数据看板优化 | **3.45** | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ |
| 3 | 活动配置后台 | **3.20** | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |

### 计算公式

综合得分 = Σ(维度值 × 权重)

= 业务价值(5) × 0.35

  • 紧急度(4) × 0.25
  • 开发成本(3) × (-0.15)
  • 风险(2) × (-0.10)
  • 干系人(4) × 0.15

= 1.75 + 1.00 - 0.45 - 0.20 + 0.60 = 3.85


### 建议排期

1. **P0(本周)**:用户增长裂变功能
2. **P1(下周)**:数据看板优化
3. **P2(下周后)**:活动配置后台

### 风险提示

- 用户增长裂变功能涉及后端改动较大,建议预留 buffer
- 活动配置后台依赖设计资源,需提前协调

4. 验收标准生成器 (/acceptance)

功能

自动生成可量化的验收标准,避免模糊表述。

输入格式

/acceptance
需求:用户增长裂变功能
目标:提升用户邀请率
约束:预算有限,需快速上线

输出示例

## 验收标准文档

### 需求概述
- **需求名称**:用户增长裂变功能
- **需求来源**:运营团队
- **目标**:提升用户邀请率,实现低成本用户增长
- **上线时间**:2024-05-01

---

### 功能验收标准

#### 1. 邀请码功能

| 验收项 | 标准 | 验证方法 | 负责人 |
|--------|------|----------|--------|
| 邀请码生成 | 用户可生成唯一邀请码 | 功能测试 | 前端 |
| 邀请码有效期 | 默认30天有效 | 边界测试 | 后端 |
| 邀请码使用次数 | 单码限用1次 | 数据验证 | 后端 |
| 邀请记录 | 可查看邀请明细 | 功能测试 | 前端 |

#### 2. 奖励发放功能

| 验收项 | 标准 | 验证方法 | 负责人 |
|--------|------|----------|--------|
| 奖励类型 | 支持积分、优惠券 | 功能测试 | 后端 |
| 发放时效 | 邀请成功后24小时内发放 | 时效监控 | 后端 |
| 发放准确性 | 发放成功率 ≥ 99.9% | 数据监控 | 后端 |
| 异常处理 | 发放失败自动重试3次 | 异常测试 | 后端 |

---

### 数据验收标准

#### 核心指标

| 指标 | 目标值 | 数据源 | 统计周期 |
|------|--------|--------|----------|
| 邀请率 | ≥ 15% | 埋点数据 | 活动期间 |
| 邀请成功率 | ≥ 30% | 活动系统 | 活动期间 |
| 人均邀请数 | ≥ 2 人 | 活动系统 | 活动期间 |
| 新用户留存率(7日) | ≥ 40% | 用户系统 | 活动后7天 |

#### 验收数据采集

```sql
-- 邀请率
SELECT 
  COUNT(DISTINCT inviter_id) / COUNT(DISTINCT user_id) as invite_rate
FROM user_behavior
WHERE event_date BETWEEN '2024-05-01' AND '2024-05-15'
AND event_type IN ('generate_invite_code', 'share_invite_code');

-- 邀请成功率
SELECT 
  COUNT(DISTINCT invitee_id) / COUNT(DISTINCT invite_code) as success_rate
FROM invite_records
WHERE created_at BETWEEN '2024-05-01' AND '2024-05-15';

体验验收标准

场景标准验证方法
邀请码生成点击后 1 秒内展示性能测试
分享体验支持 5+ 平台分享功能测试
奖励提示奖励到账后弹窗通知功能测试
异常提示网络错误有友好提示异常测试

验收流程

  1. 开发自测:开发完成后自测所有功能点
  2. 测试验收:QA 按验收标准逐项测试
  3. 运营验收:运营在测试环境体验核心流程
  4. 灰度验收:5% 流量灰度,观察数据指标
  5. 全量验收:全量后 3 天内确认数据达标

签字确认

角色姓名签字日期
产品经理
运营负责人
技术负责人
QA负责人

---

## 5. 数据口径对齐工具 (`/data-align`)

### 功能
统一运营和产品对数据指标的定义,避免口径不一致。

### 输入格式

/data-align 指标:DAU、GMV、转化率 场景:双11大促效果评估


### 输出示例

```markdown
## 数据口径对齐文档

### 一、核心指标定义

#### DAU(日活跃用户数)

| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 每日登录 App 的独立用户数 | 包含注册未下单用户 |
| **产品口径** | 每日产生有效行为的独立用户数 | 有效行为包括:浏览、搜索、加购、下单 |
| **统一口径** | 每日至少完成 1 次有效行为的独立用户数 | ✅ 双方确认 |

**计算公式:**

DAU = COUNT(DISTINCT user_id) WHERE event_date = today AND event_type IN ('view', 'search', 'add_cart', 'order')


#### GMV(成交总额)

| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 订单创建金额 | 包含未支付订单 |
| **产品口径** | 实际支付金额 | 仅统计已支付订单 |
| **统一口径** | 已支付订单金额 + 已发货订单金额 | ✅ 双方确认 |

**计算公式:**

GMV = SUM(order_amount) WHERE order_status IN ('paid', 'shipped', 'completed') AND payment_status = 'success'


#### 转化率

| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 下单用户数 / 访问用户数 | 偏高 |
| **产品口径** | 支付用户数 / 访问用户数 | 偏低 |
| **统一口径** | 有效支付用户数 / 有效访问用户数 | ✅ 双方确认 |

**计算公式:**

转化率 = COUNT(DISTINCT paid_user_id) / COUNT(DISTINCT active_user_id) WHERE event_date = today


---

### 二、数据源对齐

| 指标 | 数据源 | 表名 | 字段名 | 更新频率 |
|------|--------|------|--------|----------|
| DAU | 用户行为日志 | user_behavior | user_id, event_type | 实时 |
| GMV | 订单系统 | orders | order_amount, status | T+1 |
| 转化率 | 计算字段 | - | - | T+1 |

---

### 三、数据获取接口

```python
# DAU 查询
def get_dau(date):
    query = """
    SELECT COUNT(DISTINCT user_id) 
    FROM user_behavior 
    WHERE event_date = '{date}'
    AND event_type IN ('view', 'search', 'add_cart', 'order')
    """
    return execute_query(query)

# GMV 查询
def get_gmv(start_date, end_date):
    query = """
    SELECT SUM(order_amount)
    FROM orders
    WHERE order_status IN ('paid', 'shipped', 'completed')
    AND payment_status = 'success'
    AND order_date BETWEEN '{start_date}' AND '{end_date}'
    """
    return execute_query(query)

四、口径变更流程

  1. 提出变更:任一方发起口径变更申请
  2. 双方确认:运营、产品双方确认新口径
  3. 技术评估:评估数据源、接口变更成本
  4. 文档更新:更新本文档
  5. 通知所有干系人:邮件 + 群公告

五、常见口径争议处理

争议场景解决方案
指标定义不一致以本文档为准
数据源不一致以主数据源为准
计算公式有差异以本文档公式为准
历史数据回溯统一按新口径重新计算

---

## 6. 协同文档生成器 (`/ops-doc`)

### 功能
一键生成运营产品协同文档,包含需求、排期、验收、归因等完整信息。

### 输入格式

/ops-doc 项目:双11大促活动 运营负责人:张三 产品负责人:李四


### 输出示例

```markdown
# 运营产品协同文档 - 双11大促活动

## 基本信息

| 项目 | 内容 |
|------|------|
| 项目名称 | 双11大促活动 |
| 运营负责人 | 张三 |
| 产品负责人 | 李四 |
| 技术负责人 | 王五 |
| 项目周期 | 2024-10-15 ~ 2024-11-15 |
| 文档版本 | v1.0 |
| 更新时间 | 2024-10-15 |

---

## 一、背景与目标

### 活动背景
双11是全年最大的促销节点,需要通过活动提升 GMV 和用户活跃度。

### 核心目标
| 目标 | 指标 | 目标值 |
|------|------|--------|
| GMV提升 | 活动GMV | ≥ 1000万 |
| 用户增长 | 新增用户 | ≥ 5万 |
| 用户活跃 | DAU峰值 | ≥ 50万 |
| 转化提升 | 转化率 | ≥ 15% |

---

## 二、需求清单

### P0 需求

| 需求 | 描述 | 验收标准 | 排期 |
|------|------|----------|------|
| 活动落地页 | 大促活动主会场页面 | 见验收文档 | 10.25 |
| 优惠券系统 | 满减、折扣券配置发放 | 支持多种券类型 | 10.28 |
| 数据看板 | 实时活动数据监控 | 5分钟延迟内 | 10.30 |

### P1 需求

| 需求 | 描述 | 验收标准 | 排期 |
|------|------|----------|------|
| 用户裂变 | 邀请好友奖励 | 见验收文档 | 11.01 |
| 活动提醒 | 活动开始/结束提醒 | 支持多渠道推送 | 11.03 |

---

## 三、排期计划

10.15 10.20 10.25 10.30 11.04 11.09 11.11 |-----|-----|-----|-----|-----|-----| 需求评审 开发 测试 灰度 全量 复盘


### 里程碑

- **10.15**:需求评审完成
- **10.20**:技术方案确定
- **10.28**:P0 功能开发完成
- **11.01**:测试验收完成
- **11.05**:灰度发布
- **11.11**:全量上线

---

## 四、验收标准

见 [验收标准文档](./acceptance.md)

---

## 五、效果归因

见 [效果归因框架](./attribution.md)

---

## 六、数据口径

见 [数据口径对齐文档](./data-align.md)

---

## 七、沟通机制

### 日常沟通
- **群组**:双11大促协同群
- **频率**:每日站会 10:00
- **方式**:线上会议 + 群内同步

### 问题升级
1. **P2 问题**:群内沟通解决
2. **P1 问题**:负责人协调解决
3. **P0 问题**:升级到部门负责人

### 文档更新
- **负责人**:张三(运营)、李四(产品)
- **频率**:每个里程碑节点更新
- **同步范围**:所有干系人

---

## 八、风险与应对

| 风险 | 等级 | 应对措施 |
|------|------|----------|
| 技术资源不足 | 高 | 提前锁定开发资源,预留 buffer |
| 数据口径争议 | 中 | 使用数据口径对齐文档 |
| 需求变更频繁 | 中 | 需求变更需双方确认 |
| 效果不达预期 | 中 | 预备 Plan B 方案 |

---

## 九、签字确认

| 角色 | 姓名 | 签字日期 |
|------|------|----------|
| 运营负责人 | 张三 | 2024-10-15 |
| 产品负责人 | 李四 | 2024-10-15 |
| 技术负责人 | 王五 | 2024-10-15 |

---

*文档生成时间:2024-10-15*
*文档版本:v1.0*

工作流示例

场景:运营提新需求

1. 运营发送需求
   /ops-translate --from ops --to pm
   运营需求:我们要搞个年终活动

2. 产品理解需求后生成验收标准
   /acceptance
   需求:年终活动功能

3. 计算优先级
   /priority-calc
   [输入需求列表]

4. 生成协同文档
   /ops-doc
   项目:年终活动

参考文档

  • 需求翻译词典:见 references/ops_pm_dictionary.md
  • 优先级计算权重配置:见 references/priority_weights.md
  • 归因模型说明:见 references/attribution_models.md

约束

  1. 所有文档生成后需双方确认
  2. 数据口径变更需走变更流程
  3. 优先级计算结果仅供参考,最终由人决策
  4. 验收标准必须量化可测试

Comments

Loading comments...