- 学习结果
- 产出首批用户名单和联系方式、一张渠道计划表、一套符合平台规则的发布安排，以及四周的反馈节奏和要看的指标。
- 时长
- 120 分钟
- 难度
- 增长实践
- 核验
- 已核验 2026-10-24 · 下次复核 2026-11-23
正文
很多独立开发者把“推广”理解成上线那天把链接发到所有能发的地方，然后等着用户来。结果通常是：当天有一波访问，第二天就回到零，而且很难知道来的人里有谁真的用了产品。
启动推广更像一个持续几周的过程：先找到第一批真正需要的人，在合适的渠道用合适的方式出现，然后根据反馈不断修产品。一次发布带来的曝光，只有接上后续的反馈和改进，才会变成持续的用户。
先找第一批人，而不是先找渠道
第一批用户最好是正在做这件事的人，而不是“可能感兴趣”的人。做开发者工具，就去找正在被这个问题困扰的开发者；做设计师工具，就去找每天在处理这件事的设计师。
最直接的来源，是你在验证阶段访谈过、加入过候补名单的人。他们已经表达过兴趣，也最可能给你真实的反馈。
联系时用具体的问题和演示结果说明价值，比如“上次你提到每周要花两小时整理反馈，我做了一个工具，这是用你描述的场景跑出来的结果”。私信要和对方真的相关，不要批量群发，更不要购买未经同意的邮箱名单。
不同渠道承担不同的任务
| 渠道 | 适合做什么 | 期待的行为 |
|---|---|---|
| 行业社区、论坛 | 讨论问题、分享做法 | 有人回复、提问、试用 |
| 产品发布平台（Product Hunt、Show HN 等） | 展示做好的产品 | 试用、评论、反馈 |
| 邮件、Newsletter | 联系已经同意接收的人 | 回访、续用 |
| 搜索内容 | 回答长期存在的问题 | 持续带来有需要的访客 |
| 私信 | 联系最相关的少数人 | 深度试用和反馈 |
给每个渠道写下你期待的行为和收集反馈的方式。不同渠道带来的访问量不能直接相加，一万次路过的访问，不如十个真正用起来的人。
遵守平台的规则
每个平台都有自己的规则，违反了轻则被降权，重则被封禁。发布前一定要读一遍官方规则，下面是两个常见平台的例子。
Product Hunt：官方鼓励产品的作者自己发布，并说明找第三方代为发布没有明显的好处；禁止使用公司账号；唯一的硬性规则是不能直接请人点赞，可以请人来看看、留下评论。官方建议提前准备的作者在太平洋时间凌晨 12:01 发布，但也强调，最好的发布日是你准备得最充分的那一天。
Hacker News 的 Show HN：要求发布的是别人可以实际试用的东西，而且是你自己做的、你本人能在讨论中回应。博客文章、注册页、落地页和简报都不符合要求；用户最好不需要注册、不需要留邮箱就能试用。规则里还明确写着：不要叫朋友来点赞或评论。
图：Hacker News“Show HN Guidelines”页面截图，截取于 2026-10-24，内容以官方当前页面为准。
这两条规则透露出同一个意思：平台想要的是真实的产品和真实的反馈，而不是刷出来的热度。
发布用的素材要和实际能力一致
截图要真实，演示要完整，价格和限制要写清楚。还在测试的功能，就说明测试的范围。不要编造客户评价、收入数字或排名。
发布时可以讲开发的故事，但读者最先想知道的是：这是什么，适合谁，我怎么用。素材怎样准备，见发布素材包：上线前要准备哪些图文。
四周的反馈循环
- 第一周：向小范围的用户演示，逐个解决他们卡住的地方。
- 第二周：把常见问题整理成 FAQ，把好的使用案例整理出来（经用户同意）。
- 第三周：选一到两个新渠道尝试，比如一个社区和一个发布平台。
- 第四周：对比各渠道来的用户，看谁真的在用、谁回来了。
每周都应该有一个让用户更容易完成任务的改进，而不只是换一篇更夸张的宣传文案。
统计：知道人从哪来、做了什么
外部渠道的链接可以加上 UTM 参数，标明来源和活动，比如 ?utm_source=producthunt&utm_campaign=launch。注意不要给站内链接加 UTM，否则会覆盖掉用户真正的来源。
记录从访问到关键动作的路径：注册、第一次完成核心任务、回访、付费。区分“报名了”“真的用了”和“付了钱”，它们是完全不同的信号。跨设备访问和隐私设置会让统计不完整，报表只能反映大致趋势，不是每个人的全部行为。
增长决策看持续价值
某个渠道带来了大量访问，却几乎没人完成核心任务，先检查是不是来的人不对，或者你在那个渠道的承诺和实际产品不符。
小样本的波动、发布的时间、来的是哪类人，都会影响结果。与其反复冲一次榜单，不如修好新用户第一次使用时卡住的地方，让真正需要的人能稳定地从产品里得到结果。
学习步骤
- 从访谈和候补名单里，列出 10 到 20 位第一批用户，写下每个人的具体问题。
- 为每个人准备一条个性化的私信，附上用他的场景跑出来的演示结果。
- 列出三到四个渠道，为每个渠道写下用途、期待的行为和反馈方式。
- 发布前阅读每个平台的官方规则，记下禁止的行为。
- 为外部链接设置 UTM 参数，在统计里确认能看到来源。
- 按四周节奏执行，每周记录一个改进和三个数字：访问、首次完成核心任务、回访。
场景拆解
工时工具的第一个月
小周的工时统计工具准备正式推广。
- 第一批人：他从候补名单里挑出 20 位自由设计师，逐个发私信，附上“按你说的三个项目跑出来的月报”。有 12 位开始使用。
- 第一周：他发现有一半的人卡在“新建项目”这一步，因为入口藏得太深。他把入口移到了首页。
- 第二周：整理出 6 个常见问题；经两位用户同意，写了两个使用案例。
- 第三周：他在一个设计师社区分享了“自由设计师怎么按项目算清工时”的做法，文末附上工具链接；同时在 Product Hunt 发布，发布前读了官方规则，只请朋友来看看和留言，没有请人点赞。
- 第四周：社区带来的访问不多，但三分之一的人完成了第一次计时；Product Hunt 当天访问量更大，但完成计时的比例低得多。
他的结论是：设计师社区来的人更对口，接下来每两周在社区分享一次实际的做法；Product Hunt 带来的主要是同行开发者的关注，不是他的目标用户。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
先找对的人
- 正在做这件事的人
- 从访谈和候补名单开始
- 私信要具体，不群发
渠道和规则
- 不同渠道承担不同任务
- 发布前读官方规则
- 不请人点赞
- 素材和实际能力一致
四周反馈循环
- 演示、FAQ、新渠道、对比
- 每周一个产品改进
- 区分访问、使用、回访
- 看持续价值，不冲榜单
02 实践练习
根据文章内容记录自己的判断与依据。
写一份启动推广计划
为你的产品写出第一个月的推广计划。
准备材料
- 候补名单或访谈过的用户名单。
- 产品的演示截图或视频。
- 统计工具（如 Plausible 或 Google Analytics）。
练习步骤
01 / 列出第一批人
时间： 40 分钟
操作：
- 列出 10 到 20 位第一批用户和他们的具体问题。
- 为前 5 位写好个性化的私信。
产出： 一份名单和 5 条私信。
检查： 每条私信都提到了对方的具体问题，没有群发的模板感。
02 / 制定渠道计划
时间： 40 分钟
操作：
- 选三到四个渠道，填写渠道计划表。
- 阅读每个平台的官方规则，记下禁止的行为。
产出： 一张渠道计划表。
检查： 每个渠道都有期待的行为和反馈方式。
03 / 设置追踪和节奏
时间： 40 分钟
操作：
- 为外部链接设置 UTM 参数，并在统计里验证。
- 写出四周的安排和每周要看的三个数字。
产出： 一份四周计划。
检查： 每周的安排里都有一项针对产品的改进。
完成检查
- 第一批用户是正在做这件事的具体的人。
- 每个渠道的用途和规则都清楚。
- 能区分访问、使用和回访。
03 清单、模板和关键词
用于项目记录和自查。
渠道计划表
| 渠道 | 用途 | 期待的行为 | 平台规则要点 | 发布时间 | 反馈怎么收集 |
|---|---|---|---|---|---|
私信模板
你好【名字】，之前你提到【具体问题】。
我做了一个小工具，用你描述的场景跑了一遍，结果是这样的：【截图或链接】。
如果方便的话，想请你试用 10 分钟，告诉我哪里不顺手。不方便也完全没关系。
每周记录
第几周：
这周的产品改进：
访问：
首次完成核心任务：
回访：
用户反馈里最常见的问题：
下周计划：
关键概念
- 第一批用户：正在做这件事、能给出真实反馈的人
- 渠道用途：讨论、展示、维护、长期流量、深度试用
- 平台规则：每个平台禁止的推广行为
- UTM 参数：标记外部链接的来源和活动
- 激活：第一次完成核心任务
- 反馈循环：每周根据用户反馈改进产品
容易误判
- 上线当天把链接发到所有地方
- 批量群发私信或购买邮箱名单
- 请人给发布平台点赞
- 把不同渠道的访问量直接相加
- 给站内链接加 UTM 参数
- 只看访问量，不看有没有人真的在用
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Product Hunt
- Hacker News
- Indie Hackers
- Buttondown
- Plausible