别让推荐链接躺着睡觉：vibe 项目推荐计划与邀请码裂变实战

你的 vibe 项目上线了。你在 V2EX 发了帖，在推特 at 了几个大 V，还去 Product Hunt 凑了个热闹。三天来了 400 个注册，你盯着后台数字傻乐了一晚上。然后流量归零，注册曲线变成一条直线，客服（就是你本人）开始无所事事。

你没预算买量，SEO 要等三个月。这时候有人跟你说："做个推荐计划吧，让用户替你拉新。"你花一个周末加上邀请链接和邀请码，上线一个月后去看数据：发出 200 多条邀请，回来 3 个注册，其中 2 个还是你自己的小号。推荐链接就躺在个人中心里睡觉，上面落了一层灰。

问题不在"推荐"这个想法。Dropbox 靠推荐计划 15 个月从 10 万用户干到 400 万，这事是成立的。问题在于，推荐计划不是"加个邀请链接"这么简单，它是一套经济系统：奖励定价、防作弊、归因链路、增长指标，缺一环就转不动。好消息是，这套系统的代码量真不大，一个周末能写完；难的是写代码之前要想清楚的东西。这篇文章就是那部分——从算账、定价、代码、防刷到上线节奏，一人团队能直接照着做的完整打法。

一、先算账：推荐计划什么时候值得做

先泼冷水：推荐获客不是免费的。每一个发出去的奖励都是成本，羊毛党薅走的更是纯亏损。所以在写第一行代码之前，先算一笔账，回答一个问题：通过推荐来一个新用户，花的钱是不是比别的渠道便宜？

公式就一行：

R < CAC × L

R：带来一个新用户的平均奖励成本。注意是"成本"不是"面值"——发出去 100 份奖励只有 40 份被领走，成本要按实际核销算。
CAC：你当前最便宜获客渠道的单个获客成本。
L：推荐用户的转化率相对普通渠道的提升倍数。推荐自带信任背书，转化率通常是普通渠道的 2–5 倍。

举个具体的例子。假设你做了一个 AI 写真应用，信息流投放的 CAC 是 30 元/注册。推荐来的用户因为有朋友背书，付费转化率是信息流用户的 3 倍（L=3），那么 R 做到 90 元以内都划算。再看 R 怎么算：你的奖励是"推荐人和被推荐人各得 50 点生成额度"，50 点额度的实际推理成本是 2 元。100 次分享带来 20 个注册，其中 8 人完成新手任务触发奖励，总奖励成本是 8 × 4 = 32 元，R = 32 ÷ 20 = 1.6 元。1.6 元对 90 元——这就是推荐计划对独立开发者的意义：你的获客成本有机会比大厂低一个数量级，因为你的奖励可以用边际成本接近零的东西（额度、功能）来支付。

反过来，两种情况别做。第一，你已经有近乎免费的流量——比如你自己就是 KOL，一条推文带来 500 注册，边际成本为零，那折腾推荐系统是浪费时间；第二，你的产品是低频工具，用户一年想不起你两次，L 再高也乘不出量。这个公式更大的价值其实是帮你做"不做"的决定，这比"做"的决定更值钱。

单边还是双边？先看这张表

奖励给谁，是第一个分叉口。单边只奖推荐人，双边双方都奖：

	单边奖励（只奖推荐人）	双边奖励（双方都奖）
成本	低，一份奖励	高，约两份奖励
被推荐人转化	低——点开发现跟自己没关系，扭头就走	高——"注册就有好处"，临门一脚
推荐人动力	强（独享）	中（好处被分走一半）
适合	用户本身就是布道者、以"发现神器"为荣的开发者工具	默认选这个，尤其预算紧的时候
典型	某些 SaaS 的推荐返现	Dropbox（双方各得空间）、Airbnb（双方各得券）

我的判断很直接：独立开发者默认选双边。理由反直觉：双边看起来贵，但你可以用"额度/功能解锁"这种零边际成本的东西凑出双边；而单边要刺激推荐人持续分享，往往只能靠现金——现金是四种奖励里最贵的，还最招羊毛党。单边唯一的例外是你的用户自带传教属性：开发者工具、AI 神器这种"分享出去显得我很懂行"的产品，用户要的是社交货币，奖励只是添头。

二、奖励设计：四种形态，别选错

奖励不是"给点好处"就行，给错东西等于没给。四种形态各有各的命：

形态	适用场景	优点	坑
现金/返现	高客单价、决策重的产品	刺激最直接，人人都懂	最招羊毛党；提现通道、税务都是成本
折扣	订阅制 SaaS	边际成本低，金额可控	对免费用户无感——他本来就没付费
额度（credits）	AI 应用、API 按量计费产品	边际成本接近 0，vibe 项目首选	发太多会通胀，用户囤着不用
功能解锁	工具类产品	零成本，还能让用户尝到付费功能、顺带转化	解锁的东西必须真有价值，鸡肋功能等于没奖

看到"额度"那一行多停两秒。对 vibe coding 做出来的 AI 应用，额度奖励几乎是天作之合：你的成本是推理 API 的批发价，用户感知的是零售价，中间的差价就是你的利润空间。给 100 点额度用户觉得值 20 块，你实际只花 3 块。这种"感知价值远大于实际成本"的奖励，是独立开发者唯一玩得起的价格战。

奖励发多少？记住 20–40%

定价规则一句话：奖励面值约等于用户首单利润的 20–40%。注意是"首单利润"，不是客单价——你要用已经赚到的钱发奖励，不是用未来的钱画饼。

接着上面的 AI 写真例子：首单 49 元，推理成本加支付通道约 15 元，首单利润 34 元。奖励面值就定在 7–14 元之间。"双方各得 50 点额度"面值 20 元？超了。改成"双方各得 30 点"（面值约 12 元，实际成本不到 4 元），正好落进区间。

还有两条实战经验。第一，宁可先小后大。奖励加码容易——"限时双倍奖励"一发，用户欢呼；奖励缩水会被挂起来骂。先定在 20% 那档，跑顺了再加。第二，现金奖励没有"感知溢价"，1 块钱就是 1 块钱；额度和功能有溢价，用户往往高估它们的价值。所以现金奖励往区间下限靠，额度/功能奖励可以往上限靠。

三、落地代码：邀请链接、归因与核销

推荐计划的代码量真不大，核心就三件事：发码、归因、发奖。下面是 Next.js App Router 的实现，逻辑完整，能直接跑。

1. 邀请码生成：别用自增 ID

邀请码千万别用数据库自增 ID——会被人遍历。也别用 UUID，又长又难念。8 位 base32（去掉 0/O、1/I/L 这些易混淆字符），用户口头报给朋友都不会错：

// lib/referral.ts
import { randomBytes } from 'crypto';

// 去掉 0/O、1/I/L 等易混淆字符，用户口头传播也不怕报错
const ALPHABET = 'ABCDEFGHJKMNPQRSTUVWXYZ23456789';

export function generateReferralCode(length = 8): string {
  const bytes = randomBytes(length);
  let code = '';
  for (const b of bytes) {
    code += ALPHABET[b % ALPHABET.length];
  }
  return code;
}

// 创建邀请码：唯一键冲突就重 roll，5 次都撞上直接抛错
export async function createReferralCode(ownerId: string) {
  for (let i = 0; i < 5; i++) {
    const code = generateReferralCode();
    try {
      return await prisma.referralCode.create({
        data: { code, ownerId },
      });
    } catch (e: any) {
      if (e?.code !== 'P2002') throw e; // 非唯一键冲突直接抛
    }
  }
  throw new Error('referral code collision, please retry');
}

8 位 32 进制有上万亿种组合，碰撞概率可以忽略；即便撞上，唯一键兜底重 roll 就行。邀请链接就是 yoursite.com/r/ABCDEFGH，短、好记，适合印在海报上。

2. /r/[code] 路由：落地即归因

用户点开邀请链接的第一件事不是"看页面"，是"把归因记下来"。这个动作必须在服务端完成，别指望前端 JS：

// app/r/[code]/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function GET(
  req: NextRequest,
  { params }: { params: { code: string } }
) {
  const code = params.code.toUpperCase().trim();
  const record = await prisma.referralCode.findUnique({
    where: { code },
  });

  const res = NextResponse.redirect(new URL('/signup', req.url));

  // 码有效才写归因 cookie；无效也不报错，照常进注册页
  if (record && !record.revoked) {
    res.cookies.set('referred_by', record.code, {
      maxAge: 60 * 60 * 24 * 30, // 归因窗口 30 天
      path: '/',
      httpOnly: true, // 前端 JS 读不到，防篡改
      sameSite: 'lax',
      secure: process.env.NODE_ENV === 'production',
    });
  }
  return res;
}

三个细节。第一，归因写在 httpOnly cookie 里，前端 JS 读不到，防篡改；第二，归因窗口 30 天——用户今天点链接、三周后注册，依然算推荐人的，窗口太短会寒了推荐人的心；第三，码无效也不报错，照常进注册页。邀请链接会在社交媒体上被反复转发，一个过期码导致 404，丢的是整个传播链。

再加一道保险：着陆页的 JS 读一下 URL 里的 ?ref= 参数，写一份 localStorage 备份。Safari 的 ITP 偶尔会吞掉这类场景下的 cookie，双保险不丢归因。

3. 注册时绑定：归因只认一次

归因的绑定时机是注册成功那一刻，认 cookie，不认 URL 参数（参数在跳转和中转页里极易丢失）：

// app/api/auth/signup/route.ts（节选，doSignup 是你原来的注册逻辑）
import { createHash } from 'crypto';

const hashIp = (ip: string) =>
  createHash('sha256').update(ip + (process.env.IP_SALT || '')).digest('hex');

export async function POST(req: NextRequest) {
  const user = await doSignup(req); // 先走完你原来的注册流程
  const res = NextResponse.json({ ok: true });

  const referredBy = req.cookies.get('referred_by')?.value;
  if (referredBy) {
    const code = await prisma.referralCode.findUnique({
      where: { code: referredBy },
    });
    // 三道校验：码存在、没被封、不是自邀
    if (code && !code.revoked && code.ownerId !== user.id) {
      try {
        await prisma.referral.create({
          data: {
            codeId: code.id,
            referrerId: code.ownerId,
            refereeId: user.id, // @unique：一个用户只能被推荐一次
            ipHash: hashIp(getIp(req)),
            deviceFingerprint: req.headers.get('x-device-id'),
          },
        });
      } catch (e: any) {
        if (e?.code !== 'P2002') throw e; // 该用户已有归因记录，忽略
      }
    }
    res.cookies.delete('referred_by'); // 归因只用一次，用完即清
  }
  return res;
}

注意 refereeId 的 @unique 约束：一个用户只能被推荐一次。没有这个约束，羊毛党会拿 10 个邀请码注册 1 个号领 10 份奖励。cookie 用完即删，不给"换个码重新算"的操作空间。

4. 奖励状态机：别在注册成功那一刻发奖

这是新手最容易犯的错：用户一注册就发奖励。然后你会发现注册机比真人用户多。奖励的触发条件必须是被推荐人完成 aha 时刻——生成第一个作品、连上数据源、发出第一条邀请，具体是什么视你的产品而定。注册只是"我来了"，aha 时刻才是"我留下了"。状态机长这样：

// schema.prisma（节选）
model ReferralCode {
  id         String     @id @default(cuid())
  code       String     @unique
  ownerId    String
  revoked    Boolean    @default(false)
  maxRewards Int        @default(50) // 单个码可发放奖励上限，熔断器
  createdAt  DateTime   @default(now())
  referrals  Referral[]
}

model Referral {
  id                String         @id @default(cuid())
  codeId            String
  referrerId        String // 推荐人
  refereeId         String         @unique // 被推荐人，只能被推荐一次
  status            ReferralStatus @default(PENDING)
  ipHash            String?
  deviceFingerprint String?
  riskFlags         String[]       @default([])
  qualifiedAt       DateTime?
  createdAt         DateTime       @default(now())
}

enum ReferralStatus {
  PENDING   // 已归因，等被推荐人完成 aha 时刻
  QUALIFIED // 达成奖励条件，待审核/自动通过
  APPROVED  // 审核通过，待发放
  PAID      // 已发放
  REJECTED  // 作弊或无效，riskFlags 里写明理由
}

// 奖励发放：只在 aha 时刻后调用，绝不在注册时调用
export async function qualifyReferral(referralId: string) {
  const referral = await prisma.referral.update({
    where: { id: referralId, status: 'PENDING' },
    data: { status: 'QUALIFIED', qualifiedAt: new Date() },
  });

  const flags = await fraudChecks(referral);
  if (flags.length === 0) {
    await grantReward(referral); // 干净记录：自动通过并发放
  } else {
    await prisma.referral.update({
      where: { id: referralId },
      data: { riskFlags: flags }, // 有风险标记：进人工审核队列
    });
  }
}

// 防刷检查：返回风险标记数组，为空表示干净
async function fraudChecks(r: Referral): Promise<string[]> {
  const flags: string[] = [];
  const referee = await prisma.user.findUnique({
    where: { id: r.refereeId },
    select: { email: true },
  });
  const [sameIp, sameDevice, referrerCount] = await Promise.all([
    prisma.referral.count({
      where: { ipHash: r.ipHash, status: { not: 'REJECTED' } },
    }),
    prisma.referral.count({
      where: { deviceFingerprint: r.deviceFingerprint, status: { not: 'REJECTED' } },
    }),
    prisma.referral.count({
      where: { referrerId: r.referrerId, status: { not: 'REJECTED' } },
    }),
  ]);
  if (sameIp >= 3) flags.push('same_ip_3_plus');
  if (sameDevice >= 2) flags.push('same_device_2_plus');
  if (referrerCount >= 20) flags.push('referrer_over_cap'); // 触发月封顶复核
  if (referee?.email && isDisposableEmail(referee.email)) flags.push('disposable_email');
  return flags;
}

async function grantReward(r: Referral) {
  await prisma.$transaction([
    // 双边奖励：推荐人 + 被推荐人同时到账
    prisma.creditLedger.create({
      data: { userId: r.referrerId, amount: 100, reason: 'referral:' + r.id },
    }),
    prisma.creditLedger.create({
      data: { userId: r.refereeId, amount: 50, reason: 'referred:' + r.id },
    }),
    prisma.referral.update({
      where: { id: r.id },
      data: { status: 'PAID' },
    }),
  ]);
  // 通知永远放在事务外面：push 失败不能回滚已到账的奖励，
  // 否则用户收到"奖励到账"提醒、点进去却没到账，比没发更伤信任
  await notifyReward(r.referrerId, r.refereeId);
}

读一遍 grantReward 的顺序：先在事务里把双边奖励和状态变更一次性写完，再去发 push 和邮件。通知永远放在事务外面——通知失败不能回滚已经到账的奖励，否则用户会收到"奖励到账"的提醒，点进去发现没到账，这种 bug 比没发奖励更伤信任。

图 1：归因链路——/r/[code] 落地写 cookie，注册时绑定邀请人，被推荐人完成 aha 时刻后触发奖励发放。

四、防作弊：羊毛党识别 5 招

先说一句残酷的实话：任何带现金或高价值奖励的推荐计划，上线 48 小时内就会被羊毛党发现。不是"会不会"，是"什么时候"。防作弊不是上线后再打的补丁，是和奖励一起设计、第一天就要有的东西。5 招，按见效排序：

1. 自邀拦截。ownerId !== refereeId 只是起点。真正的自邀检查是：同一设备指纹、同一 IP、同一支付卡号都算自邀。注册时把这几样都记下来（见第三节的 schema），比对是 O(1) 的事，别嫌麻烦。
2. 延迟发放。T+7 起步，订阅制等过退款期再发。羊毛党的时间也是成本，一个要等 14 天的奖励对他们没有吸引力，对真人用户只是"晚几天到"。这是性价比最高的防刷手段。
3. 行为门槛。奖励只认"有效推荐"，有效 = 被推荐人完成 aha 时刻。刷 100 个注册小号容易，刷出 100 个真实使用行为难。把门槛定在羊毛党觉得"不值"、真人用户自然跨过的位置。
4. 上限封顶。单人每月奖励封顶，单个邀请码可兑换次数封顶（schema 里的 maxRewards 就是干这个的）。封顶不是小气，是熔断器——就算前面的防线全被绕过，损失也有天花板。
5. 模式监控。每周花 10 分钟看三个数：单码邀请转化率超过 60%（正常是 5–20%）、注册时间在 5 分钟内聚集 10 个以上、disposable 邮箱域名占比突然飙升。出现任何一个，先冻结该码的奖励发放，再人工看。

审核队列：三档分流，别什么都人工看

一人团队没有风控部门，审核必须自动化分流。fraudChecks 返回的 riskFlags 数组就是分流依据：

• 自动通过：flags 为空，被推荐人行为真实。占 90% 以上，别浪费人工。
• 人工审核：1–2 个低风险标记。攒成一批，每天花 10 分钟按风险分排序处理，看一眼注册行为时间线就能判。
• 自动拒绝：自邀实锤（设备指纹重复 + IP 重复）、明显的农场特征。拒绝要写明理由，用户申诉时有据可查——误伤真人用户比放过羊毛党更贵，前者丢的是信任，后者丢的只是钱。

记住一个原则：风控的目标不是零作弊，是让作弊成本高于作弊收益。追求零作弊会把真人用户也挡在门外，得不偿失。

五、上线节奏：三阶段，别一上来就全量

推荐计划的 bug 都是"钱"的 bug——多发的奖励是真金白银，收不回来。所以上线节奏只有一条铁律：拿小流量当防火墙。

阶段	时长	做什么	通过指标（缺一不可）
内测	1 周	拉 20 个朋友，把全链路跑通	归因准确率 100%：每一条 referral 记录都能对上真人真事；奖励到账金额分毫不差
小流量	2 周	对 5–10% 用户开放邀请入口	K-factor 可测且大于 0.3；作弊率低于 5%；相关客服工单每周少于 5 单
全量	持续	全开，开始每周看增长指标	K-factor 趋势向上；单用户奖励成本在预算内

每个阶段只回答一个问题：内测回答"链路通不通"，小流量回答"划不划算、防不防得住"，全量才回答"能跑多大"。跳过小流量的团队，我见过最惨的一个：奖励触发条件配成了"注册"，上线 3 天被刷掉 2 万块额度，连夜下线——而这些在 5% 流量里一周就能发现。

K-factor 大于 0.3 这条线是经验值。低于 0.3 说明推荐链路基本转不起来，全量只是把"没人传"这件事放大 20 倍，先回去优化第六节的 4 个杠杆，别急着全量。

六、增长指标：盯住 K-factor 和漏斗

推荐计划只有一个核心指标：K-factor = 平均每用户发出邀请数 × 邀请转化率，记作 K = i × c。K > 1 才能自增长，K < 1 每一轮都在衰减——这是数学，不是努力能改变的。

算给你看：100 个种子用户，每人平均发出 2 次邀请（i=2），每次邀请带来 0.3 个新用户（c=0.3），K=0.6。第一轮带来 60 人，第二轮 36 人，第三轮 22 人……总量收敛到 250 人就停了，一分不会多。想突破天花板，只有一条路：把 K 做到 1 以上。

第二个指标是病毒周期时长：从 A 发出邀请，到被邀请的 B 发出他的第一次邀请，间隔多久。K 决定"每一轮放大多少"，病毒周期决定"一轮有多快"。双边奖励"即时到账 + push 提醒"这类设计，优化的都是周期——让 B 在热情最高点（刚拿到奖励那一刻）把邀请发出去。

第三个是邀请转化漏斗，每一层都要埋点：

1. 看到邀请入口的用户数
2. 点击分享的比例（分享率）
3. 好友打开链接的比例（点击率）
4. 打开后注册的比例（注册转化）
5. 注册后完成 aha 时刻的比例（有效转化）

K-factor 是结果，漏斗告诉你哪一层在漏水。优化时永远先看漏斗：分享率低和注册转化低是完全不同的病，不能吃同一种药。

图 2：邀请转化漏斗——K-factor 是结果，漏斗告诉你该修哪一层。

K-factor < 1 时的 4 个杠杆（按投入产出比排序）

1. 把邀请入口搬到 aha 时刻之后。用户刚做出第一个作品、成就感最强的那一刻，分享率是平时的 3–5 倍。在用户还没用明白时就弹"邀请好友得奖励"，等于在相亲第一次见面时谈彩礼。
2. 给推荐人现成的"弹药"。写好三版分享文案（一句话版、朋友圈版、技术群版），再生成一张带他名字的专属海报。用户不分享，很多时候不是不想，是不知道说什么——你把说什么都替他想好，分享就剩一个点击。
3. 被推荐人落地页个性化。"/r/ABCDEFGH" 落地后，页面上写"你的朋友老王邀请你，注册即得 30 点额度"，而不是通用的"欢迎注册"。带名字的落地页转化率比通用页高一截——信任是推荐计划唯一的货币，别浪费它。
4. 让奖励"看得见、摸得着"。进度条（"再邀请 1 人解锁 Pro"）、即时到账提醒、排行榜。延迟满足杀死分享欲，人对"差一点就拿到"的东西最没有抵抗力——这是游戏行业验证过 20 年的人性。

七、失败模式：奖励发了，却没人传

这是推荐计划最常见的死法：系统全跑通了，奖励也发出去了，就是没人分享。三个死因，对号入座：

1. 奖励无感。你给的东西用户不想要。SaaS 免费用户给他"续费 8 折券"等于没给——他本来就没付费。解法：奖励必须挂钩核心价值。AI 应用给额度、工具给功能、社区给身份。检验标准就一个：把奖励单独拿出来，用户愿不愿意为它付钱？不愿意就换。
2. 链路太长。从"我想分享"到"我拿到奖励"超过 3 步，每多一步流失一半。解法：分享按钮一键生成海报，奖励自动到账、到账 push 一条。目标是把"你去领奖"变成"奖自己长腿跑过来"。
3. 缺乏社交货币。分享你的产品，用户觉得"有面子"还是"丢面子"？AI 神器、生产力工具有面子；记账 app、拼单优惠券没面子。解法：给分享附加身份感——"内测官"徽章、邀请排行榜、专属皮肤。让人转发的从来不是奖励本身，是"我比你先玩到"的优越感。

这三类产品，别做推荐计划

省下时间干别的。有些产品天生不适合，硬上只会浪费一个周末：

1. 隐私敏感型。记账、健康、心理、两性——用户不愿让朋友知道自己在用，你的邀请链接他这辈子都不会点发送。
2. 低频工具。一年用两次的报税工具——用户想分享你的时候，早就忘了你叫什么。推荐依赖的是"高频接触 + 即时分享欲"，低频产品两样都没有。
3. 供给稀缺型。名额有限的内测、靠你本人交付的咨询和服务——推荐来的人你接不住，等于花钱买差评，还透支了推荐人的信任。

一句话判断：你的用户愿不愿意在朋友圈公开说"我在用这个"？不愿意，就别做推荐计划，把时间花在别的增长方式上。

八、上线前最后检查一遍

• 归因链路：/r/[code] → cookie → 注册绑定，找 3 个真人实测全链路
• 奖励触发：触发条件是 aha 时刻，不是注册
• 状态机：PENDING / QUALIFIED / APPROVED / PAID / REJECTED 齐全，拒绝有理由可查
• 防刷：5 招至少落地 4 招，延迟发放 + 行为门槛是底线
• 定价：奖励面值落在首单利润的 20–40%
• 入口位置：邀请入口在 aha 时刻之后，不在新手引导里
• 数据：漏斗每层埋点，K-factor 每周看一次
• 熔断器：单人每月奖励封顶、单码可兑换次数封顶

最后，冷启动没有种子用户怎么办？一句话：等候名单 + "邀请 3 人前进 1000 名"的推荐加速排队，是冷启动的经典组合——排队机制本身是另一套设计（名次算法、防刷又是新话题），本文不展开。但记住，推荐计划需要第一批种子，排队就是买种子的办法。

推荐计划的本质，是把你的获客预算从"给平台"变成"给用户"。平台赚走的是 30 元一个的点击，用户拿走的是 1.6 元一个的真心推荐——还附带信任背书。一人团队打不起广告战，但打得起信任战。别让你的推荐链接躺着睡觉，它可能是你手里最便宜的增长杠杆。

如果这周只能做一件事：先把 R < CAC × L 这笔账算出来。如果算出来值得做，下周就把 /r/[code] 路由和归因 cookie 写了——代码半天，想清楚要一周，别搞反了。