referral-program

referral-program skill 概览

referral-program skill 的作用

referral-program skill 用于帮助 AI agent 设计、诊断或优化客户推荐计划、Affiliate program，或两者结合的混合伙伴模式。它面向的是可落地的增长规划，而不只是头脑风暴：会把讨论推进到项目类型、激励结构、推荐闭环设计、工具选择和上线决策这些关键层面。

最适合 Product Marketing 和增长团队的 referral-program skill

这个 referral-program skill 最适合 Product Marketing、增长、生命周期运营，以及 founder-led 团队使用，尤其适用于希望把现有客户或合作伙伴转化为可重复获客渠道的场景。它在你需要回答以下问题时尤其有价值：

• 应该做 referral、affiliate，还是两者都做？
• 什么样的奖励机制适合我们的定价和 LTV？
• 为什么参与率偏低？
• 上线前需要哪些工具和 tracking 能力？

referral-program skill 真正解决的问题

大多数用户并不需要一段“什么是 referral marketing”的定义。他们真正需要的是一个与自身产品、商业模型和客户行为相匹配、能够实际运行的项目方案。这个 skill 最强的地方，是能把“想多做点口碑传播”这样的模糊目标，拆解成具体结构：触发时机、分享流程、转化路径、奖励设计、核心指标以及 rollout checklist。

referral-program skill 与普通 prompt 的不同

相比普通 prompt，这个 skill 的核心优势在于内置了明确的决策路径。它会显式检查：

• referral、affiliate 或 hybrid 哪种更适合
• B2B 还是 B2C 场景
• LTV 和 CAC 的约束
• 当前参与情况和既有激励机制
• 产品是否适合被分享、是否天然具备口碑传播基础
• 工具条件和预算现实

它还附带了关于 affiliate 设计和真实项目案例的参考资料，因此输出内容通常不会停留在“给个折扣试试”这种泛泛建议上。

什么时候选择 referral-program skill 很合适

在以下场景下，适合使用 referral-program skill：

• 你要上线新的 refer-a-friend 或 affiliate program
• 你需要重做激励机制
• 项目的参与率或转化率偏弱
• 你需要案例、benchmark 或工具建议
• 你想要一份更结构化、适合 Product Marketing 使用的 referral-program 指南

什么时候它不是合适工具

如果你的核心问题是“如何做一次大范围 launch virality”，而不是搭建一个持续运转的推荐系统，那么这个 skill 的适配度会偏弱。仓库本身也明确把偏 launch 的 viral 增长问题指向 launch-strategy。此外，如果你无法提供最基本的业务输入，比如定价、LTV、客户类型和当前获客经济模型，它的帮助也会明显受限。

如何使用 referral-program skill

在你的 skills 环境中安装 referral-program

仓库里的 SKILL.md 没有提供单独的安装命令，因此可以直接使用 repo 根目录通用的 skills 安装方式：

npx skills add https://github.com/coreyhaines31/marketingskills --skill referral-program

如果你的环境已经支持本地或同步后的 skills，也可以直接从 coreyhaines31/marketingskills 仓库中的 skills/referral-program 添加。

首次使用前先读这些文件

如果你想快速高效地掌握重点，建议按这个顺序阅读：

1. skills/referral-program/SKILL.md
2. skills/referral-program/references/program-examples.md
3. skills/referral-program/references/affiliate-programs.md
4. skills/referral-program/evals/evals.json

这个阅读顺序很重要。SKILL.md 提供整体工作流，参考文件补充具体细节，而 evals/evals.json 则能让你看到一个高质量输出通常应该包含哪些内容。

在提问前先确认 Product Marketing 上下文

这个 referral-program skill 明确要求 agent 先查找 .agents/product-marketing-context.md 或 .claude/product-marketing-context.md。如果你已经在这些文件里维护了产品定位、目标受众、定价或 GTM 背景，skill 就能减少重复追问，输出也会更贴近实际业务。

如果没有这些文件，就把同样的信息直接写进 prompt。

提供能解锁有效输出的最低输入信息

至少建议提供以下内容：

• 你目前认为需要的项目类型：referral、affiliate，或 unsure
• B2B 还是 B2C
• 产品类型和定价模式
• 平均客户 LTV
• 其他渠道当前的 CAC
• 目前是否已经有相关项目
• 当前 referral 的参与率或转化率
• 已经尝试过哪些激励方式
• 产品的可分享性
• 你在用或预算可承受的工具

如果缺少这些信息，referral-program 的输出大概率会停留在泛化层面，因为奖励经济性和项目机制都高度依赖这些输入。

把模糊需求改写成高质量的 referral-program prompt

弱 prompt：

Help me make a referral program.

更好的 prompt：

Use the referral-program skill to design a customer referral program for our B2B SaaS. We charge $49/month, average 14-month retention, CAC is about $180 on paid channels, and we have 1,000 active customers. We do not have an existing referral program. Customers often invite teammates, but not external peers. Recommend whether referral, affiliate, or a hybrid model fits best, propose incentives, define the referral loop, suggest tools, and include a launch checklist.

之所以这样更有效，是因为它给了 skill 足够的信息去判断激励规模是否合理，以及哪种模式更匹配。

明确要求 skill 区分 referral 与 affiliate 逻辑

这个仓库一个很实用的优点是，它不会把客户推荐和 affiliate 合作混为一谈。如果你的业务两种模式都有可能成立，最好在 prompt 里明确说明，并要求分别给出建议。

例如：

We have happy customers and industry creators. Use the referral-program skill to compare a customer referral program versus an affiliate program, including incentive structure, tracking requirements, fraud risk, and which should be launched first.

通常这样得到的判断，会比让它输出一个混合在一起的方案更可靠。

按内置工作流来设计项目

借助这个 skill，一个比较扎实的 referral-program 工作流通常是：

1. 明确业务背景和经济模型
2. 判断项目类型
3. 验证产品是否适合通过分享传播
4. 设计 referral loop
5. 选择激励机制
6. 确定工具与 tracking 方案
7. 制定 launch checklist
8. 设定成功指标和复盘节奏

如果你跳过第 1 到第 3 步，后面的方案往往会变得不现实。

用参考资料来给输出做压力测试

这些支持文件不只是“可以顺手看看”，而是真的值得拿来验证输出：

• references/program-examples.md 适合用来比较不同激励类型、viral mechanics 和 program 风格
• references/affiliate-programs.md 适合用来校验 commission、cookie window、affiliate 招募方式和 fraud prevention

如果第一版答案太泛，或者明显偏向某一种模式，这一步尤其有用。

一份好的 referral-program 输出应该包含什么

从 evals 来看，一份高质量结果通常应该包含：

• 清楚区分 referral 与 affiliate 模式
• 明确的 referral loop：trigger、share、conversion、reward
• 与你的商业模型匹配的激励建议
• launch 或 rollout checklist
• 工具建议
• 如果已有项目，还应包含优化建议

如果输出缺了这些关键部分，不要急着接受，最好要求 agent 继续修订，而不是停留在浅层方案上。

常见场景下实用的 prompt 模板

用于新项目：

Use the referral-program skill to design a first referral program for our product. Include eligibility, incentive structure, share flow, tracking, abuse prevention, and launch checklist.

用于参与率低：

Use the referral-program skill to diagnose why only 5% of customers have ever referred someone. Prioritize participation bottlenecks, messaging issues, reward mismatch, trigger timing, and product-fit constraints.

用于 affiliate 搭建：

Use the referral-program skill to propose an affiliate program for our subscription product, including commission model, cookie duration, recruitment channels, enablement assets, and fraud controls.

referral-program skill 常见问题

referral-program 主要是做 referral program，还是 affiliate program？

两者都支持。这个 skill 明确覆盖客户推荐计划、affiliate program、ambassador 风格模式，以及 hybrid 场景。它的一部分价值就在于：帮助你判断应该选哪一种，而不是默认所有 partner-led growth 都是同一套逻辑。

referral-program skill 适合新手吗？

适合，前提是你能提供基本的业务信息。你不需要自己很懂增长闭环，但必须给出足够的上下文，模型才能判断激励机制和渠道经济性。对新手来说，最有价值的用法通常是：不仅让它给建议，还要求它解释背后的 tradeoff。

这个 skill 比普通 AI prompt 强在哪里？

普通 prompt 往往只能产出一些比较泛的激励点子。referral-program skill 则给了 agent 更结构化的检查清单和参考资料，因此它更可能先问对搭建项目真正重要的问题，区分 referral 和 affiliate 的机制差异，并补齐 launch 层面的细节，而不是停在“增长策略口号”上。

referral-program 对 Product Marketing 是否特别有用？

是的。referral-program for Product Marketing 是一个很契合的用法，因为 Product Marketing 往往负责定位、受众理解、信息表达和生命周期触发点，这些都会直接影响 referral adoption。这个 skill 最有价值的地方，在于帮助 PMM 把产品价值、客户动机和获客经济模型连接起来。

它能做优化诊断，而不只是新项目规划吗？

可以。evals 里就有一个很明确的优化场景：针对 referral participation 偏低的问题进行诊断。因此它不是只能在项目启动前用一次的规划文档工具，也适合拿来分析 adoption 弱、激励不匹配，或 referral 流程中存在摩擦的问题。

什么时候不该使用 referral-program？

在以下情况下，不建议依赖这个 skill：

• 你的产品几乎没有天然分享行为，也没有理由相信激励能明显弥补这一点
• 你需要某个具体 referral 平台非常技术细节的实现方案
• 你的问题本质上是 launch 期间的广义 virality，而不是持续性的 referral-program 系统
• 你连粗略的经济模型、定价或客户背景都无法提供

这个 skill 包含 benchmark 或案例吗？

它包含的是经过整理的案例和设计参考，而不是一个大型 benchmark 数据库。这些案例很适合拿来匹配激励类型、项目结构和 viral mechanics，但最终仍然需要结合你的定价和受众做本地化调整。

如何改进 referral-program skill 的使用效果

从经济模型入手，而不是先想奖励

在使用 referral-program 时，最常见的错误就是一上来就讨论激励。更好的输出通常从 LTV、CAC、留存、利润率和客户类型开始。只有这些基础清楚了，skill 才能合理判断 free month、account credit、固定奖金，还是 recurring commission 在财务上更成立。

明确说明产品是否具备自然分享行为

这个 skill 会询问产品是否容易被分享、是否有 network effects，或者是否天然容易被用户讨论。请尽量如实回答。如果客户几乎不会主动讨论你的产品，那么更合理的结论可能只是做一个轻量 referral test，或者优先做 affiliate program，而不是直接上大力度激励。

说明 referral ask 最适合出现在哪个客户时刻

推荐项目成败很大程度取决于时机。请尽量给出触发时点，例如：

• 激活后
• 达成某个成功里程碑后
• NPS 提升或收到正向反馈后
• 邀请团队成员或发生协作行为后
• 复购后

这样 skill 才能设计出可信的 referral loop，而不是只给你一个笼统的“加个分享按钮”。

把工具和运营约束说清楚

如果你需要轻量级工具，就直接说明。如果财务只能支持按月付款，也要写明。如果法务需要审批奖励机制，也请提前提到。你的约束越具体，最终得到的 referral-program 指南就越有可执行性。

要求输出采用便于决策的格式

通常你会在要求以下结构时得到更好的结果：

• recommended model
• incentive options with pros and cons
• referral loop
• tooling
• launch checklist
• success metrics
• risks and fraud controls

这种格式更适合内部评审，也更容易与其他方案进行横向比较。

用案例逼出更具体的建议

如果第一版回答仍然偏抽象，可以要求 agent 结合一个或两个仓库案例重写：

Rework this referral-program recommendation using Dropbox-style double-sided value and Morning Brew-style gamified milestones, but adapted to our SaaS economics.

这种方式通常比简单要求“再写详细一点”更容易得到更锋利的激励与流程设计。

留意这些常见失败模式

质量较弱的 referral-program 输出，常见问题包括：

• 把客户推荐和 affiliate 招募混为一谈
• 在没核对 unit economics 的情况下直接推荐奖励
• 忽略参与过程中的摩擦
• 默认所有产品都天然适合分享
• 跳过用户点击推荐链接后的被推荐人体验
• 漏掉 fraud 或 abuse control

如果你看到这些问题，最好要求它针对该缺口做一次定向修订。

用更精准的追问修正低质量初稿

比较有效的追问包括：

• “Revise this for B2B with longer sales cycles.”
• “Make the incentive safer for a low-margin subscription.”
• “Show 3 reward options ranked by ROI risk.”
• “Add fraud prevention and tracking requirements.”
• “Diagnose why participation is low before suggesting bigger rewards.”

这些追问之所以有效，是因为它们强迫模型思考 tradeoff，而不只是继续堆更多点子。

对照 eval 预期来校验结果

提升 referral-program 输出质量的一个实用方法，是把结果与 evals/evals.json 对照检查。如果答案没有覆盖 product-marketing context、没有区分 referral 与 affiliate 逻辑、没有定义 loop、没有合理设定激励规模，也没有给出 launch guidance，那通常说明它还没有达到仓库预期的质量线。

把 referral-program 当作结构化顾问，而不是自动驾驶

这个 skill 最有价值的使用方式，是帮助你加快决策，而不是替你做判断。最好的结果通常来自：你提供扎实的业务背景，对提出的机制保持批判性审视，并在第一版方案暴露真实 tradeoff 之后继续迭代。