Chapter 25：从 Builder 到产品——商业化路径与生态运营

目标： 超越技术层面，理解如何将你的 EVE Frontier 合约和 dApp 打造成有用户、有收入、有社区的真实产品，以及如何在这个新兴生态中找到自己的定位。

状态：产品章节。正文以商业模式、增长和运营机制为主。

25.1 Builder 的四种商业模式

在 EVE Frontier 生态中，Builder 有四种主要的价值捕获方式：

┌─────────────────────────────────────────────────────────┐
│               Builder 商业模式图谱                       │
├─────────────────┬───────────────────────────────────────┤
│ 模式            │ 代表案例               │ 收入来源      │
├─────────────────┼───────────────────────┼──────────────┤
│ 基础设施        │ 星门收费、存储市场      │ 使用费（自动）│
│ Infrastructure  │ 通用拍卖平台           │              │
├─────────────────┼───────────────────────┼──────────────┤
│ 代币经济        │ 联盟 Token + DAO       │ 代币升值、税  │
│ Token Economy   │ 点数系统               │              │
├─────────────────┼───────────────────────┼──────────────┤
│ 平台/SaaS       │ 多租户市场框架         │ 平台抽成      │
│ Platform        │ 竞赛系统框架           │ 月费/注册费   │
├─────────────────┼───────────────────────┼──────────────┤
│ 数据服务        │ 排行榜、分析面板       │ 广告/订阅     │
│ Data & Tools    │ 价格聚合器             │ 增值服务      │
└─────────────────┴───────────────────────┴──────────────┘

这张图最重要的不是帮你“选一个赛道名词”，而是看清：

你到底是在卖资产、卖流量、卖协议能力，还是卖信息优势。

很多 Builder 项目做不起来，不是技术不行，而是一开始就没想清楚自己卖的是什么。

25.2 定价策略：链上自动收入

最简单的 Builder 收入：交易自动抽佣，零运营成本。

双层费率结构

// 结算时：平台费 + Builder 费双层结构
public fun settle_sale(
    market: &mut Market,
    sale_price: u64,
    mut payment: Coin<SUI>,
    ctx: &mut TxContext,
): Coin<SUI> {
    // 1. 平台协议费（EVE Frontier 官方，如果有的话）
    let protocol_fee = sale_price * market.protocol_fee_bps / 10_000;

    // 2. 你的 Builder 费
    let builder_fee = sale_price * market.builder_fee_bps / 10_000;    // 例：200 = 2%

    // 3. 剩余给卖家
    let seller_amount = sale_price - protocol_fee - builder_fee;

    // 分配
    transfer::public_transfer(payment.split(builder_fee, ctx), market.fee_recipient);
    // ... 协议费到官方地址，剩余给卖家

    payment // 返回 seller_amount
}

费率范围建议

自动抽佣为什么看起来最美，但也最容易高估

它的优势很明显：

• 收入自动化
• 不用人工追账
• 和实际使用量直接挂钩

但它也有前提：

• 用户真的愿意持续使用你的设施
• 你的收费不会被更便宜的替代品瞬间打掉
• 你的服务有明确差异，而不是纯同质化通道

所以链上自动收入不是“写好合约就会来钱”，它只是把商业模式执行得更干净。

25.3 用户获取：游戏内触达

玩家发现你的 dApp 的主要路径：

触达路径优先级：

1. 游戏内显示（最高转化率）
   └── 玩家靠近你的星门/炮塔 → 游戏内浮层自动弹出 → 直接交互

2. EVE Frontier 官方 Builder 目录（预期功能）
   └── 官方列出认证 Builder 的服务 → 玩家主动查找

3. 玩家社区（Discord / Reddit）
   └── 口碑传播 → 联盟推荐 → 用户增长

4. 联盟内部推广
   └── 与大联盟合作 → 嵌入他们的工具链 → 批量用户

增长飞轮设计

玩家使用服务
    ↓
获得奖励（代币/NFT/特权）
    ↓
价值可见、可交易
    ↓
向其他玩家炫耀/出售
    ↓
更多玩家了解并加入
    ↓
（回到顶部）

用户获取里最容易被忽视的一点

不是“怎么让更多人第一次点开”，而是“用户点开后为什么会留下来”。

尤其在 EVE 场景里，很多功能天然带强场景性：

• 当下需要就会用
• 不需要时就会立刻离开

所以真正要设计的是：

• 第一次使用是否足够顺滑
• 第二次是否还会回来
• 是否会形成联盟级或群体级依赖

25.4 社区建设：Builder 的护城河

在 EVE Frontier，社区是你最不可复制的资产。技术可以被抄，但关系不能。

建立社区的层次

1. Discord 服务器
   ├── #announcements（版本更新、新功能）
   ├── #support（用户问题解答）
   ├── #feedback（收集意见）
   └── #governance（重要决策投票）

2. 定期沟通
   ├── 每月 AMA（Ask Me Anything）
   ├── 收支透明报告（展示 Treasury 余额和分红计划）
   └── Roadmap 公开更新

3. 社区激励
   ├── 早期用户 NFT 徽章（见 Example 8）
   ├── 反馈奖励（提 Bug 得 Token）
   └── 推荐奖励（带新用户注册联盟）

社区真正的价值不在于人数，而在于关系强度和反馈质量。

一个小但活跃的 Builder 社区，往往比一个大而沉默的频道更有用，因为它能提供：

• 真实需求反馈
• 问题复现样本
• 第一批传播者
• 早期共建者

25.5 透明度：链上可信的运营

链上数据天然透明，把它变成竞争优势：

// 生成每月公开财务报告
async function generateMonthlyReport(treasuryId: string) {
  const treasury = await client.getObject({
    id: treasuryId,
    options: { showContent: true },
  });
  const fields = (treasury.data?.content as any)?.fields;

  const events = await client.queryEvents({
    query: { MoveEventType: `${PKG}::treasury::FeeCollected` },
    // 筛选本月时间范围...
  });

  const totalCollected = events.data.reduce(
    (sum, e) => sum + Number((e.parsedJson as any).amount), 0
  );

  return {
    date: new Date().toISOString().slice(0, 7),  // "2026-03"
    totalRevenueSUI: totalCollected / 1e9,
    currentBalanceSUI: Number(fields.balance) / 1e9,
    totalUserTransactions: events.data.length,
    topServices: calculateTopServices(events.data),
  };
}

透明度这件事，不只是“把数据公开”这么简单，而是让用户能看懂：

• 钱从哪里来
• 钱到哪里去
• 哪些规则是固定的
• 哪些调整是后来变的

只要这些能被用户理解，你的协议信任成本就会明显下降。

25.6 合规与风险管理

虽然 EVE Frontier 是去中心化的，Builder 仍需注意：

技术风险

社区风险

风险管理里最重要的其实是“预案”

不是等出了事再想怎么说，而是提前知道：

• 漏洞时先停哪一层
• 前端要不要先隐藏某个入口
• 是否需要暂停赞助服务
• 哪些状态和资产要先保护

25.7 长期可持续性：渐进式去中心化

最健康的 Builder 项目应走向渐进去中心化：

阶段 1（启动期）：Builder 中心化控制
  • 快速迭代，灵活调整
  • 建立初始用户群和现金流

阶段 2（成长期）：引入社区治理
  • 重要参数（费率、新功能）DAO 投票
  • 代币持有者获得提案权

阶段 3（成熟期）：完全社区自治
  • 所有关键决策链上治理
  • Builder 退为贡献者角色
  • 协议收入完全分配给代币持有者

这里最需要克制的一点是：不是每个项目都必须走到“完全社区自治”。

更现实的问题应该是：

• 这个项目是否真的需要治理代币
• 社区是否已经成熟到能承担治理责任
• 哪些权力适合下放，哪些仍应保留在执行层

25.8 EVE Frontier 生态合作机会

不要单打独斗，寻找协同效应：

横向合作（同类Builder）：
  ├── 共用技术标准（接口协议）
  ├── 联合市场推广
  └── 互相引流（你的用户 → 我的服务）

纵向合作（不同层级Builder）：
  ├── 基础设施 Builder 提供 API
  ├── 应用 Builder 在其上构建
  └── 用户体验 Builder 做门户聚合

与 CCP 合作：
  ├── 申请官方 Featured Builder 认证
  ├── 参与官方测试和反馈项目
  └── 在官方活动中展示你的工具

合作的真正价值通常有三类：

• 分发 让更多人更快知道你
• 互补 让你不必自己从零做完整栈
• 合法性 让用户更敢用你的服务

25.9 成功 Builder 的核心特质

从技术到产品，你需要的不仅仅是 Move 代码：

技术能力（你已有）                战略能力（同样重要）
─────────────────────────         ─────────────────────────────
✅ Move 合约开发                   ✅ 用户需求洞察
✅ dApp 全栈开发                   ✅ 产品快速迭代
✅ 安全与测试                      ✅ 社区建设与沟通
✅ 性能优化                        ✅ 商业模型设计
✅ 升级与维护                      ✅ 竞争分析与差异化

真正长期能留下来的 Builder，通常不是“最会写代码的人”，而是能把技术、产品、社区和节奏一起拿住的人。

25.10 你的 Builder 旅程路线图

月份 0-1（学习期）：
  ├── 完成本课程所有章节和案例
  ├── 在 testnet 部署 Example 1-2
  └── 加入 Builder Discord，认识社区

月份 1-3（实验期）：
  ├── 发布 testnet 版本的第一个产品
  ├── 邀请测试用户，收集反馈
  └── 迭代 2-3 轮

月份 3-6（验证期）：
  ├── 主网发布（小规模，谨慎测试）
  ├── 实现第一笔链上收入
  └── 建立初始社区（Discord 100+ 成员）

月份 6-12（成长期）：
  ├── 月活用户 1000+
  ├── 引入代币经济（如适合）
  └── 建立第一个跨 Builder 合作

年份 2+（生态期）：
  ├── 成为生态中的"基础设施"
  ├── 渐进社区治理
  └── 可持续自运营

这条路线图最应该被当成“阶段判断框架”，而不是 KPI 清单。

因为不同产品的节奏会差很多，但有一条判断始终成立：

先证明有人真在用，再放大；先证明模式成立，再复杂化。

🔖 本章小结

🎓 课程完成！你现在是 EVE Frontier Builder

恭喜完成这套课程的全部 23 章 + 10 个实战案例。

你已经掌握了：

• ✅ Move 智能合约从入门到高级
• ✅ 四类智能组件的完整开发与部署
• ✅ 全栈 dApp 开发与生产级架构
• ✅ 链上经济、NFT、DAO 治理设计
• ✅ 安全审计、性能优化、升级策略
• ✅ 商业化路径与生态运营

在这个宇宙里，代码就是物理定律。去构建你的宇宙吧。 🚀

📚 书签这些资源