Web3 产品经理实战项目集

基于公开链上数据的实战训练，模拟真实PM工作场景

---

🎯 为什么需要这套实战？

Web3 的核心特征是数据公开透明，这给产品经理带来了独特优势：

• ✅ 可以分析竞品的真实数据（用户、交易、资金流）
• ✅ 可以验证增长策略的效果
• ✅ 可以识别风险和异常行为
• ✅ 可以做数据驱动的产品决策

---

📊 七大实战方向概览

---

方向一：交易行为分析 📈

目标：通过分析链上交易数据，理解用户行为模式，为产品优化提供依据

项目 1.1：DEX 用户分群画像

背景

不同类型的用户使用 DEX 的方式完全不同。作为 PM，你需要了解：

• 散户 vs 巨鲸的行为差异
• 高频交易者 vs 长期投资者
• 专业套利者 vs 普通用户

实战任务

Task 1: 用户分群（Dune SQL）

-- 基于过去30天 Uniswap V3 交易数据进行用户分群
WITH user_trades AS (
  SELECT 
    trader_a as user_address,
    COUNT(*) as trade_count,
    SUM(amount_usd) as total_volume,
    AVG(amount_usd) as avg_trade_size,
    COUNT(DISTINCT DATE_TRUNC('day', block_time)) as active_days
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= NOW() - INTERVAL '30' DAY
  GROUP BY trader_a
)
SELECT 
  CASE 
    WHEN total_volume >= 1000000 THEN 'Whale (>$1M)'
    WHEN total_volume >= 100000 THEN 'Large Trader ($100K-$1M)'
    WHEN total_volume >= 10000 THEN 'Medium Trader ($10K-$100K)'
    WHEN total_volume >= 1000 THEN 'Small Trader ($1K-$10K)'
    ELSE 'Micro Trader (<$1K)'
  END as user_tier,
  COUNT(*) as user_count,
  SUM(total_volume) as tier_volume,
  AVG(trade_count) as avg_trades_per_user,
  AVG(active_days) as avg_active_days
FROM user_trades
GROUP BY 1
ORDER BY tier_volume DESC

Task 2: 写产品洞察报告

报告模板:

## Uniswap 用户分群分析报告

### 核心发现
1. [数据] 巨鲸用户占比 X%，贡献了 Y% 的交易量
2. [洞察] 小额用户的留存率显著低于大额用户
3. [建议] 应该为不同用户群设计差异化体验

### 产品改进建议
- 对散户: 优化 Gas 费显示、提供简化模式
- 对巨鲸: 提供大额交易拆分、滑点保护
- 对套利者: 提供 API 优化、批量交易

### 数据附录
[插入 Dune 查询链接]

Task 3: 设计功能 PRD

根据分析结果，写一个 PRD：

• 功能名称：用户分层体验优化
• 目标用户：基于数据定义的用户群
• 功能描述：针对不同用户群的 UI/UX 优化
• 成功指标：留存率、交易完成率

交付物

• Dune Dashboard（用户分群可视化）
• 1页产品洞察报告
• 1个功能 PRD

---

项目 1.2：交易滑点与 MEV 影响分析

背景

MEV（最大可提取价值）是 Web3 特有问题，直接影响用户体验。PM 需要理解：

• 用户实际遭受的滑点损失
• 三明治攻击的频率和影响
• 如何通过产品设计减少 MEV 损失

实战任务

Task 1: 分析滑点损失

-- 分析 Uniswap 交易的实际滑点
WITH trades_with_slippage AS (
  SELECT 
    block_time,
    amount_usd,
    -- 计算实际滑点（简化版）
    ABS(token_bought_amount_raw / token_sold_amount_raw - 
        (SELECT AVG(price) FROM prices.usd WHERE symbol = 'ETH' AND minute = DATE_TRUNC('minute', t.block_time))) 
        / (SELECT AVG(price) FROM prices.usd WHERE symbol = 'ETH') as estimated_slippage
  FROM uniswap_v3_ethereum.trades t
  WHERE block_time >= NOW() - INTERVAL '7' DAY
    AND amount_usd > 1000
)
SELECT 
  DATE_TRUNC('hour', block_time) as hour,
  COUNT(*) as trade_count,
  AVG(estimated_slippage) * 100 as avg_slippage_pct,
  SUM(amount_usd * estimated_slippage) as total_slippage_loss_usd
FROM trades_with_slippage
GROUP BY 1
ORDER BY 1

Task 2: MEV 保护方案竞品分析

研究这些 MEV 保护方案：

• Flashbots Protect
• MEV Blocker (CoW Protocol)
• Uniswap X
• 1inch Fusion

对比维度：

Task 3: 设计 MEV 保护功能

写一个产品方案：

• 如何在 UI 中提示用户 MEV 风险
• 默认开启哪种保护机制
• 高级用户如何自定义设置

交付物

• 滑点分析 Dashboard
• MEV 保护方案对比表
• MEV 保护功能设计文档

---

项目 1.3：交易路径与聚合器分析

背景

DEX 聚合器（1inch, Paraswap, CoW）通过智能路由提供更好的价格。PM 需要理解：

• 聚合器如何工作
• 不同金额的最优路径
• 聚合器 vs 直接交易的价差

实战任务

Task 1: 聚合器市场份额分析

-- DEX 聚合器市场份额对比
SELECT 
  DATE_TRUNC('week', block_time) as week,
  project as aggregator,
  COUNT(*) as trade_count,
  SUM(amount_usd) as volume_usd
FROM dex_aggregator_trades
WHERE block_time >= NOW() - INTERVAL '90' DAY
GROUP BY 1, 2
ORDER BY 1, volume_usd DESC

Task 2: 模拟交易对比

实际操作对比：

1. 选择一笔 $1000 的 ETH→USDC 交易
2. 分别在 Uniswap、1inch、Paraswap、CoW 获取报价
3. 记录：报价、Gas 费、滑点设置、预估执行价

记录模板:

Task 3: 聚合器产品改进建议

基于分析，写出：

• 聚合器 UI/UX 的优化方向
• 新手用户 vs 高级用户的功能差异
• 如何展示"节省"给用户

交付物

• 聚合器市场份额 Dashboard
• 实际交易对比表格
• 产品改进建议文档

---

方向二：用户增长分析 🚀

目标：用链上数据分析用户获取、留存和活跃度，设计增长策略

项目 2.1：新用户获取渠道分析

背景

Web3 的新用户从哪里来？第一笔交易是什么？PM 需要回答：

• 新钱包的第一个交互协议是什么
• 从创建到首次 DeFi 操作需要多久
• 不同"入口"带来的用户质量差异

实战任务

Task 1: 新钱包首次交互分析

-- 分析新钱包的首次 DeFi 交互
WITH wallet_first_tx AS (
  SELECT 
    "from" as wallet,
    MIN(block_time) as first_tx_time
  FROM ethereum.transactions
  WHERE block_time >= NOW() - INTERVAL '30' DAY
  GROUP BY "from"
),
wallet_first_defi AS (
  SELECT 
    w.wallet,
    w.first_tx_time,
    d.project as first_defi_project,
    d.block_time as first_defi_time,
    DATEDIFF('hour', w.first_tx_time, d.block_time) as hours_to_first_defi
  FROM wallet_first_tx w
  LEFT JOIN dex.trades d ON w.wallet = d.taker
  WHERE d.block_time >= w.first_tx_time
    AND d.block_time <= w.first_tx_time + INTERVAL '7' DAY
  QUALIFY ROW_NUMBER() OVER (PARTITION BY w.wallet ORDER BY d.block_time) = 1
)
SELECT 
  first_defi_project,
  COUNT(*) as new_users,
  AVG(hours_to_first_defi) as avg_hours_to_first_defi
FROM wallet_first_defi
GROUP BY 1
ORDER BY new_users DESC
LIMIT 20

Task 2: 用户获取漏斗分析

构建漏斗：

1. 创建钱包
2. 首次收到资产（ETH/Token）
3. 首次 DEX 交易
4. 成为周活用户
5. 成为月活用户

Task 3: 设计获客策略

基于数据，设计一个新用户获取方案：

• 目标：提高新用户到首次 DeFi 的转化率
• 策略：任务系统、新手引导、激励
• 衡量：转化率、留存率、LTV

交付物

• 新用户获取渠道 Dashboard
• 用户转化漏斗图
• 获客策略 PRD

---

项目 2.2：用户留存与生命周期分析

背景

Web3 用户留存是个大问题。PM 需要理解：

• 多少用户只交易一次就流失
• 不同留存节点（7天/30天/90天）的表现
• 高留存用户的特征

实战任务

Task 1: 留存率分析

-- 计算 Uniswap 用户留存率（按首次交易周分组）
WITH first_trade AS (
  SELECT 
    trader_a as user,
    DATE_TRUNC('week', MIN(block_time)) as cohort_week
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= '2024-01-01'
  GROUP BY trader_a
),
user_activity AS (
  SELECT 
    trader_a as user,
    DATE_TRUNC('week', block_time) as active_week
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= '2024-01-01'
  GROUP BY 1, 2
)
SELECT 
  f.cohort_week,
  COUNT(DISTINCT f.user) as cohort_size,
  COUNT(DISTINCT CASE WHEN a.active_week = f.cohort_week + INTERVAL '1' WEEK THEN f.user END) * 100.0 / COUNT(DISTINCT f.user) as week_1_retention,
  COUNT(DISTINCT CASE WHEN a.active_week = f.cohort_week + INTERVAL '2' WEEK THEN f.user END) * 100.0 / COUNT(DISTINCT f.user) as week_2_retention,
  COUNT(DISTINCT CASE WHEN a.active_week = f.cohort_week + INTERVAL '4' WEEK THEN f.user END) * 100.0 / COUNT(DISTINCT f.user) as week_4_retention
FROM first_trade f
LEFT JOIN user_activity a ON f.user = a.user
GROUP BY f.cohort_week
ORDER BY f.cohort_week

Task 2: 高留存用户特征分析

找出高留存用户的共同特征：

• 首次交易金额
• 首次交易的 Token 类型
• 是否使用过多个功能（Swap/LP/限价单）
• 钱包内资产多样性

Task 3: 设计留存策略

基于数据设计留存方案：

• 触发留存的关键行为（Aha Moment）
• 流失预警机制
• 召回策略

交付物

• 留存率分析 Dashboard（含 Cohort 图）
• 高留存用户特征报告
• 留存策略设计文档

---

项目 2.3：DAU/MAU 与季节性分析

背景

链上 DAU/MAU 是核心指标。PM 需要理解：

• 如何定义和计算链上活跃用户
• 活跃度的周期性变化
• 哪些事件驱动活跃度峰值

实战任务

Task 1: DAU/MAU 趋势分析

-- 计算 DAU/MAU 比率
WITH daily_users AS (
  SELECT 
    DATE_TRUNC('day', block_time) as day,
    COUNT(DISTINCT trader_a) as dau
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= NOW() - INTERVAL '90' DAY
  GROUP BY 1
),
monthly_users AS (
  SELECT 
    DATE_TRUNC('month', block_time) as month,
    COUNT(DISTINCT trader_a) as mau
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= NOW() - INTERVAL '90' DAY
  GROUP BY 1
)
SELECT 
  d.day,
  d.dau,
  m.mau,
  d.dau * 100.0 / m.mau as dau_mau_ratio
FROM daily_users d
JOIN monthly_users m ON DATE_TRUNC('month', d.day) = m.month
ORDER BY d.day

Task 2: 事件驱动分析

收集过去 90 天的关键事件，对比活跃度变化：

• 市场行情（BTC 涨跌）
• 产品更新（新功能上线）
• 空投/激励活动
• 行业事件（黑客攻击/监管新闻）

Task 3: 活跃度提升策略

设计提升 DAU/MAU 的策略：

• 每日任务/签到机制
• 交易挖矿/积分激励
• 社区活动

交付物

• DAU/MAU 趋势 Dashboard
• 事件-活跃度关联分析表
• 活跃度提升策略文档

---

方向三：激励机制设计 🎁

目标：设计和分析代币/积分激励机制

项目 3.1：空投方案设计与模拟

背景

空投是 Web3 最常用的增长手段。PM 需要：

• 设计公平有效的空投规则
• 预估空投成本和效果
• 防止女巫和刷量

实战任务

Task 1: 分析成功的空投案例

研究这些空投的规则设计：

Task 2: 使用 Dune 模拟空投

-- 模拟一个假想项目的空投规则
WITH user_stats AS (
  SELECT 
    trader_a as user,
    COUNT(*) as trade_count,
    SUM(amount_usd) as total_volume,
    COUNT(DISTINCT DATE_TRUNC('day', block_time)) as active_days,
    COUNT(DISTINCT token_bought_address) as tokens_traded,
    MIN(block_time) as first_trade,
    MAX(block_time) as last_trade
  FROM uniswap_v3_ethereum.trades
  WHERE block_time >= '2024-01-01'
    AND block_time < '2024-07-01'
  GROUP BY trader_a
)
SELECT 
  user,
  -- 空投积分计算
  LEAST(trade_count, 50) * 2 +  -- 交易次数（上限50次）
  LEAST(total_volume / 1000, 100) * 1 +  -- 交易量（每$1000得1分，上限100分）
  LEAST(active_days, 30) * 3 +  -- 活跃天数（上限30天）
  LEAST(tokens_traded, 10) * 5 +  -- Token 多样性
  CASE WHEN first_trade < '2024-03-01' THEN 20 ELSE 0 END  -- 早期用户奖励
  as airdrop_points
FROM user_stats
ORDER BY airdrop_points DESC
LIMIT 1000

Task 3: 设计一个空投方案

为一个假想的 DeFi 项目设计空投方案：

空投方案模板：

## [项目名] 空投方案

### 目标
- 激励真实用户
- 建立初始社区
- 提高协议使用率

### 资格标准
1. 基础资格：...
2. 积分计算：...
3. 乘数规则：...

### 女巫防护
- 规则1：...
- 规则2：...

### 时间线
- 快照时间：...
- 公布时间：...
- 领取时间：...

### 预估
- 合格地址数：...
- 人均空投量：...
- 总空投价值：...

交付物

• 空投案例对比分析
• Dune 空投模拟查询
• 完整空投方案设计

---

项目 3.2：积分系统设计

背景

积分系统是空投前的常用激励方式（Blast, EigenLayer）。PM 需要：

• 设计积分获取规则
• 平衡不同行为的激励强度
• 设计积分消耗/兑换机制

实战任务

Task 1: 分析现有积分系统

研究这些项目的积分机制：

Task 2: 设计积分规则

为一个 DEX 项目设计积分系统：

## 积分获取规则

### 交易积分
- 每 $1 交易量 = 1 积分
- 稳定币交易：0.5x
- 新 Token 交易：2x

### 流动性积分
- 每 $1 TVL/天 = 10 积分
- 集中流动性：1.5x
- 长期质押（>30天）：2x

### 社交积分
- 每日签到：10 积分
- 推荐新用户：100 积分
- 治理投票：50 积分

### 乘数机制
- 钻石手（从不卖出）：1.5x
- 早期贡献者：2x
- NFT 持有者：1.2x

Task 3: 积分经济可持续性分析

分析积分系统的长期可持续性：

• 积分通胀速度
• 与代币兑换比例
• 长期激励效果衰减

交付物

• 积分系统对比分析
• 积分规则设计文档
• 可持续性分析报告

---

项目 3.3：LP 激励机制设计

背景

流动性挖矿是 DeFi 核心激励手段。PM 需要：

• 设计 LP 激励策略
• 平衡激励成本和流动性获取
• 防止"挖提卖"问题

实战任务

Task 1: 分析 LP 激励效果

-- 分析某协议 LP 激励后的流动性变化
WITH daily_tvl AS (
  SELECT 
    DATE_TRUNC('day', block_time) as day,
    SUM(amount_usd) as tvl_usd
  FROM uniswap_v3_ethereum.liquidity_events
  WHERE pool = '0x...'
  GROUP BY 1
)
SELECT 
  day,
  tvl_usd,
  LAG(tvl_usd, 7) OVER (ORDER BY day) as tvl_7d_ago,
  (tvl_usd - LAG(tvl_usd, 7) OVER (ORDER BY day)) / LAG(tvl_usd, 7) OVER (ORDER BY day) * 100 as tvl_change_pct
FROM daily_tvl
ORDER BY day

Task 2: 比较不同 LP 激励模型

Task 3: 设计 LP 激励方案

为一个新 DEX 设计 LP 激励方案：

• 激励池的优先级排序
• 激励强度和时间曲线
• 退出机制和锁仓设计

交付物

• LP 激励效果分析
• 激励模型对比表
• LP 激励方案设计

---

方向四：反女巫检测 🕵️

目标：识别和防止虚假用户（Sybil Attack）

项目 4.1：女巫地址识别规则设计

背景

女巫攻击是 Web3 空投面临的最大挑战。PM 需要：

• 理解女巫行为特征
• 设计识别规则
• 平衡误杀率和漏检率

实战任务

Task 1: 研究女巫行为特征

常见女巫特征：

• 资金关联：多个地址资金来源相同
• 行为同步：同一时间执行相同操作
• Gas 模式：使用相同的 Gas 策略
• 交互模式：只做最低要求的交互

Task 2: 用 Dune 识别可疑地址

-- 识别可能的女巫集群
WITH user_funding AS (
  SELECT 
    "to" as user_address,
    "from" as funding_source,
    MIN(block_time) as first_funded
  FROM ethereum.transactions
  WHERE value > 0
    AND block_time >= NOW() - INTERVAL '90' DAY
  QUALIFY ROW_NUMBER() OVER (PARTITION BY "to" ORDER BY block_time) = 1
),
suspicious_clusters AS (
  SELECT 
    funding_source,
    COUNT(DISTINCT user_address) as funded_addresses,
    ARRAY_AGG(user_address) as address_list
  FROM user_funding
  GROUP BY funding_source
  HAVING COUNT(DISTINCT user_address) >= 10  -- 同一来源资助10+地址
)
SELECT * FROM suspicious_clusters
ORDER BY funded_addresses DESC
LIMIT 100

Task 3: 设计反女巫评分系统

设计一个女巫风险评分系统：

## 女巫风险评分系统

### 高风险信号 (+50 分)
- 资金来自已知女巫集群
- 多地址同秒交易
- 合约创建的钱包

### 中风险信号 (+20 分)
- 首笔交易即交互目标协议
- 只完成最低空投要求
- 休眠后突然活跃

### 低风险信号 (+5 分)
- 链上历史 <30 天
- 只在一条链活跃
- 无 NFT 持有

### 正向信号 (-20 分)
- ENS 域名
- Gitcoin Passport 验证
- 长期活跃历史
- 多链活跃

### 阈值
- 0-20 分：低风险
- 21-50 分：中风险，人工审核
- 51+ 分：高风险，标记为女巫

交付物

• 女巫特征分析报告
• 可疑地址识别 Dashboard
• 反女巫评分系统设计

---

项目 4.2：社区驱动的女巫猎人机制

背景

LayerZero 的 Sybil Hunter 是一个创新的社区驱动反女巫机制。PM 需要理解：

• 如何激励社区举报女巫
• 如何处理误报和争议
• 如何平衡效率和公平

实战任务

Task 1: 分析 LayerZero Sybil 结果

从公开数据分析：

• 被标记为女巫的地址数量
• 申诉成功率
• 社区反应

Task 2: 设计争议解决机制

## 女巫争议解决流程

### 第一轮：自动检测
- 系统自动标记可疑地址
- 高置信度直接剔除
- 中置信度进入申诉流程

### 第二轮：社区举报
- 举报者质押保证金
- 提交证据（链上+链下）
- 多人举报增加可信度

### 第三轮：申诉流程
- 被举报者可提交反证
- 设置申诉时间窗口
- 社区投票或委员会仲裁

### 激励机制
- 有效举报：获得被扣空投的 10%
- 误报惩罚：扣除保证金
- 成功申诉：返还空投 + 补偿

Task 3: 写产品方案

设计一个链上可验证的女巫审核系统

交付物

• LayerZero Sybil 案例分析
• 争议解决机制设计
• 女巫审核系统 PRD

---

项目 4.3：基于图分析的女巫检测

背景

利用地址之间的交互关系构建图谱，识别女巫集群。

实战任务

Task 1: 构建地址关联图

识别地址之间的关联方式：

• 直接转账关系
• 共同交互模式
• 时间序列相似度

Task 2: 使用图算法检测集群

# 概念性代码（可用 Python + NetworkX 实现）
import networkx as nx

# 构建地址关系图
G = nx.Graph()

# 添加边（基于资金流向）
for tx in transactions:
    G.add_edge(tx.from_addr, tx.to_addr, weight=tx.value)

# 检测社区/集群
communities = nx.community.louvain_communities(G)

# 识别可疑集群（规模大、高度关联）
suspicious = [c for c in communities if len(c) > 20 and density(G, c) > 0.8]

Task 3: 可视化和报告

• 创建集群可视化
• 标注风险等级
• 生成审核报告

交付物

• 地址关联分析方法论
• 集群检测算法设计
• 可视化 Demo

---

方向五：反欺诈分析 🛡️

目标：识别和防范链上欺诈行为

项目 5.1：Rug Pull 预警系统设计

背景

Rug Pull 是 DeFi 最常见的欺诈类型。PM 需要：

• 识别 Rug Pull 前的警告信号
• 设计预警机制
• 保护用户资产

实战任务

Task 1: 分析历史 Rug Pull 案例

收集 10 个 Rug Pull 案例，分析共同特征：

Task 2: 设计风险评分模型

## Token 风险评分

### 合约风险 (40分)
- [ ] 合约未开源 (+20)
- [ ] 合约可升级 (+10)
- [ ] 存在 mint 函数 (+10)
- [ ] 交易税 >5% (+10)
- [ ] 无锁仓机制 (+10)

### 团队风险 (30分)
- [ ] 团队匿名 (+15)
- [ ] 无历史项目 (+10)
- [ ] 社交账号新建 (+5)

### 流动性风险 (30分)
- [ ] LP 未锁定 (+15)
- [ ] LP 集中在少数地址 (+10)
- [ ] 无交易历史 (+5)

### 评级
- 0-30：低风险
- 31-60：中风险
- 61-100：高风险

Task 3: 设计预警产品

设计一个 Token 风险扫描工具的 PRD：

• 用户输入 Token 地址
• 自动扫描风险指标
• 显示风险评分和详情
• 推送高风险警告

交付物

• Rug Pull 案例分析库
• Token 风险评分模型
• Token 扫描工具 PRD

---

项目 5.2：钓鱼攻击监控与防护

背景

钓鱼是 Web3 用户资产损失的主要原因。PM 需要：

• 理解常见钓鱼手法
• 设计防钓鱼机制
• 教育用户识别风险

实战任务

Task 1: 钓鱼类型分类

Task 2: 设计钱包安全功能

为钱包产品设计反钓鱼功能：

• 网站真假识别
• 签名内容解读
• 授权风险提示
• 异常交易警告

Task 3: 设计用户教育方案

创建安全教育内容：

• 新手安全指南
• 常见骗局案例库
• 交互式安全测验

交付物

• 钓鱼类型分类手册
• 钱包安全功能 PRD
• 用户安全教育方案

---

项目 5.3：异常交易监控系统

背景

监控链上异常行为，及时发现攻击和欺诈。

实战任务

Task 1: 定义异常模式

-- 监控大额异常交易
WITH recent_transfers AS (
  SELECT 
    block_time,
    "from",
    "to",
    symbol,
    amount,
    amount_usd
  FROM tokens_ethereum.transfers
  WHERE block_time >= NOW() - INTERVAL '1' HOUR
    AND amount_usd > 100000
)
SELECT 
  block_time,
  "from",
  "to",
  symbol,
  amount_usd,
  CASE 
    WHEN "to" IN (SELECT address FROM known_hacker_addresses) THEN 'HIGH RISK'
    WHEN amount_usd > 1000000 THEN 'LARGE TRANSFER'
    ELSE 'MONITOR'
  END as risk_level
FROM recent_transfers
ORDER BY amount_usd DESC

Task 2: 设计告警规则

Task 3: 设计监控 Dashboard

设计一个实时监控 Dashboard：

• 实时交易流
• 异常事件时间线
• 风险地址热力图

交付物

• 异常模式定义文档
• 告警规则设计
• 监控 Dashboard 原型

---

方向六：竞品分析 🔍

目标：用链上数据进行竞品分析

项目 6.1：DEX 协议竞品对比

背景

DEX 是 DeFi 最核心的赛道。PM 需要：

• 对比主流 DEX 的关键指标
• 分析差异化策略
• 寻找产品机会

实战任务

Task 1: 多维度数据对比

-- DEX 关键指标对比
SELECT 
  project,
  COUNT(DISTINCT taker) as unique_users,
  COUNT(*) as total_trades,
  SUM(amount_usd) as total_volume,
  AVG(amount_usd) as avg_trade_size,
  COUNT(*) / COUNT(DISTINCT DATE_TRUNC('day', block_time)) as trades_per_day
FROM dex.trades
WHERE block_time >= NOW() - INTERVAL '30' DAY
  AND blockchain = 'ethereum'
GROUP BY project
ORDER BY total_volume DESC
LIMIT 10

Task 2: 产品功能对比

Task 3: 机会分析报告

基于对比，写出：

• 市场空白点
• 差异化机会
• 新产品建议

交付物

• DEX 数据对比 Dashboard
• 产品功能对比表
• 市场机会分析报告

---

项目 6.2：借贷协议竞品分析

背景

借贷是 DeFi 第二大赛道。PM 需要分析 Aave、Compound、Morpho 等协议的差异。

实战任务

Task 1: TVL 和利用率分析

-- 借贷协议关键指标
SELECT 
  protocol,
  SUM(supplied_usd) as total_supplied,
  SUM(borrowed_usd) as total_borrowed,
  SUM(borrowed_usd) / SUM(supplied_usd) * 100 as utilization_rate
FROM lending_protocols.positions
WHERE block_date = CURRENT_DATE - 1
GROUP BY protocol
ORDER BY total_supplied DESC

Task 2: 利率机制对比

研究不同协议的利率曲线设计

Task 3: 清算机制对比

分析不同清算机制的优劣

交付物

• 借贷协议数据对比
• 利率机制分析
• 清算机制对比报告

---

项目 6.3：跨链桥竞品分析

背景

跨链桥是多链时代的基础设施。PM 需要理解不同跨链方案的取舍。

实战任务

Task 1: 跨链桥使用数据

分析主流跨链桥的：

• 日交易量
• 支持链数
• 平均费用
• 到账速度

Task 2: 安全事件分析

收集跨链桥安全事件，分析原因和教训

Task 3: 产品选择建议

为不同场景推荐最佳跨链方案

交付物

• 跨链桥数据对比
• 安全事件分析
• 跨链方案选择指南

---

方向七：治理分析 🏛️

目标：理解和设计 DAO 治理机制

项目 7.1：治理参与度分析

背景

DAO 治理是 Web3 去中心化的核心。PM 需要理解治理的实际运作情况。

实战任务

Task 1: 投票参与率分析

-- 分析 Uniswap DAO 投票参与率
SELECT 
  proposal_id,
  title,
  votes_for,
  votes_against,
  total_votes,
  unique_voters,
  total_votes / total_supply * 100 as participation_rate
FROM uniswap_governance.proposals
ORDER BY created_at DESC
LIMIT 20

Task 2: 投票权集中度分析

分析：

• Top 10 投票者占比
• 委托情况
• 小持有者参与障碍

Task 3: 提高参与度方案

设计提高治理参与度的产品方案

交付物

• 治理参与度 Dashboard
• 投票权集中度分析
• 参与度提升方案

---

项目 7.2：提案分类与影响分析

背景

不同类型的提案对协议的影响不同。PM 需要分类和评估。

实战任务

Task 1: 提案分类体系

Task 2: 高影响提案深度分析

选择 3 个重大提案，深度分析：

• 提案背景
• 社区讨论
• 投票结果
• 执行效果

Task 3: 提案流程优化

设计优化后的提案流程

交付物

• 提案分类体系
• 高影响提案分析
• 提案流程优化建议

---

项目 7.3：DAO 治理机制设计

背景

为一个新项目设计完整的 DAO 治理机制。

实战任务

Task 1: 治理框架设计

## DAO 治理框架

### 治理代币
- 分配：社区 X%、团队 X%、投资人 X%
- 解锁：...
- 效用：投票权、收益分享

### 投票机制
- 类型：Token 加权 / 二次投票 / Conviction voting
- 阈值：提案 X 票，通过 Y%
- 时间：讨论 X 天，投票 Y 天

### 委托机制
- 支持代理投票
- 委托激励
- 委托撤销

### 执行机制
- Timelock 时间
- 多签执行
- 紧急暂停

Task 2: 治理攻击防护

设计防止治理攻击的机制

Task 3: 治理演进路径

设计从中心化到完全去中心化的演进路径

交付物

• DAO 治理框架设计
• 治理攻击防护方案
• 去中心化演进路径

---

📅 实战计划建议

90天内的实战安排

每周实战模板

## Week X 实战计划

### 目标
- 完成项目 X.X 的 Task 1-3

### 时间分配
- 周一-周二：数据收集与分析
- 周三-周四：设计与文档撰写
- 周五：复盘与产出整理

### 产出清单
- [ ] Dune Dashboard
- [ ] 分析报告/设计文档
- [ ] 面试问题准备

---

✅ 实战成果检验

完成所有实战后，你应该能够：

• 熟练使用 Dune SQL 分析链上数据
• 为任意协议做数据驱动的产品分析
• 设计完整的激励/空投方案
• 识别女巫和欺诈风险
• 分析竞品并找出产品机会
• 设计 DAO 治理机制

这些能力将直接体现在你的：

• Dune Dashboard 作品集
• 产品分析文章
• 面试回答深度
• 链上操作记录