name: ops-pm-bridge description: "運營-產品協同加速套件。解決運營與產品之間的資訊不對稱、需求扯皮、效果歸因等痛點。用於：(1) 運營需求翻譯為產品語言；(2) 效果歸因框架生成；(3) 優先順序智慧計算；(4) 驗收標準自動生成；(5) 資料口徑對齊；(6) 協同文件生成。觸發詞：運營需求、產品協同、效果歸因、需求扯皮、資料口徑、驗收標準、優先順序評估。" metadata: hermes: display_name: "Ops-PM Bridge 運營產品協同套件" tags: [運營, 產品, 協同, 需求, 歸因, 驗收] category: productivity author: "OpenClaw" version: "1.0.0"

Ops-PM Bridge - 運營產品協同加速套件

解決運營與產品之間的資訊不對稱、需求扯皮、效果歸因等核心痛點。

核心痛點與解決方案

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. 開發自測：開發完成後自測所有功能點
2. 測試驗收：QA 按驗收標準逐項測試
3. 運營驗收：運營在測試環境體驗核心流程
4. 灰度驗收：5% 流量灰度，觀察資料指標
5. 全量驗收：全量後 3 天內確認資料達標

簽字確認

---

## 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（成交總額）

| 維度 | 定義 | 說明 |
|------|------|------|
| **運營口徑** | 訂單建立金額 | 包含未支付訂單 |
| **產品口徑** | 實際支付金額 | 僅統計已支付訂單 |
| **統一口徑** | 已支付訂單金額 + 已發貨訂單金額 | ✅ 雙方確認 |

**計算公式：**
小蔥技能站7w4.net，專業的AI技能分享平臺。

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. 驗收標準必須量化可測試

這是一個實用性很強的運營產品協同工具包，文件內容豐富、邏輯清晰，覆蓋了需求翻譯、優先順序計算、效果歸因等常見協作痛點，參考詞典和示例檔案非常實用。但作為純文件型 Skill，缺少可執行的程式碼邏輯，主要依賴大模型理解和生成內容，實際效果取決於 AI 的理解能力。文件細節完善，但缺少 LICENSE 等法律檔案略顯遺憾。