这是
content/posts/indie/indie-acquisition-paths的目录页，收录 10 篇文章。前面七组分别讲「要不要做」「在哪上架」「丢了怎么找回」「怎么合法立住」「多条线怎么加减」「怎么用接单换现金」「前 100 天怎么走」。这一组补上最后一段，也是最容易被跳过的一段：产品做出来了，陌生人凭什么知道它存在。
这个系列解决什么问题
独立开发者最常见的处境不是「没有人喜欢我的产品」，而是「没有人知道我的产品存在」。这两句话的差别很大：前者是产品问题，需要改产品；后者是分发问题，需要改渠道。分不清这两件事，就会用改产品的方式去解决分发问题——加功能、换界面、降价，然后在同一个没有人的房间里继续等。
这个系列把「让人来」拆成可以记账的动作：
- 一次发布带来的访问，和一条渠道每周带来的访问，是两件事，怎么分开记？
- 十二个渠道里，一个人能同时运营几个，凭什么这么判断？
- 社区发帖、目录收录、搜索结果、开源仓库、邮件列表，各自的规则和失败形态是什么？
- 落地页上的哪一句话、哪一个证据位在漏人？
- 最后，怎么判断一条渠道真的有用，而不是运气好了一次？
每一篇都给出一个可以当天开始执行的动作、一张表和一个可复算的示例。不承诺流量数字，只承诺判断方法。
核心主张：获客是一本账，不是一次发布
一条渠道是否「成立」，不看它最好的那一天，看它能不能连续四周每周带来至少一个完成核心动作的新用户。
由此有三条原则：
- 四数分开记。 曝光、访问、注册、激活是四个不同分母的比例，混在一起算出来的转化率没有意义。
- 渠道有预算上限。 每周可投入的获客时间是有限的，分给几条渠道就必须按几条算，不能只在心里同时挂着五条。
- 发布是一次事件，渠道是一段时间。 发布日的数据再好看，也只能证明那天有人看见了；渠道成立与否，要用周为单位的中位数判断。
10 篇速览
| # | 文章 | 解决的问题 | 交付物 |
|---|---|---|---|
| 01 | 获客是一本账，不是一次发布 | 四个数怎么记、渠道怎么算成立 | 渠道账本模板 + 每周预算 |
| 02 | 十二条渠道的全景与打分 | 一个人到底能运营哪几条 | 渠道矩阵 + 五维打分 |
| 03 | Product Hunt 与目录站：发布日的正确用法 | 发布日做什么、之后留下什么 | 发布日检查单 + 目录收录表 |
| 04 | Hacker News 与 Reddit：社区规则先于文案 | 英文社区怎么发、怎么不被删 | 发帖前规则核对表 |
| 05 | 中文社区：V2EX、即刻、小红书、少数派 | 中文渠道的调性与禁忌 | 单帖成本与回访记录表 |
| 06 | 搜索入口：问题页、模板页与对比页 | 一个人怎么持续产出可被搜到的页面 | 页面清单 + 产能复算 |
| 07 | 开源仓库作为入口 | 代码怎么变成访问 | README 检查单 + 收录路径 |
| 08 | 从落地页到第一个动作 | 人来了为什么没注册 | 五屏结构 + 漏斗复算 |
| 09 | 自有渠道：邮件列表、更新日志与推荐 | 平台流量怎么变成自己的 | 订阅者增长表 |
| 10 | 归因与复盘：哪条渠道真的有用 | 小样本下怎么下结论 | 月度获客复盘表 |
三条阅读路径
路径 A：还没发布
02 → 01 → 03 → 08
先选渠道再准备素材。适合已经做完主路径、还在想到底往哪里发的状态。
路径 B：发布过，但之后没人来
01 → 05 → 06 → 09 → 10
先记账，再看哪些渠道其实没成立，最后把已有流量转成自有渠道。
路径 C：有一点流量，但转化很差
08 → 06 → 10 → 09
先修漏斗，再判渠道。流量问题与转化问题必须分开处理。
与其它专题的边界
| 专题 | 讲什么 | 与本组的区别 |
|---|---|---|
| 一个人的前 100 天 | 100 天时间盒里的阶段出口与判据 | 那组是时间顺序；本组是逐渠道的规则与账本 |
| 独立开发者的平台寄生 | 在哪个平台发布、怎么过审、平台内排名 | 平台内部的规则；本组讲平台外部的注意力 |
| 独立开发者生存指南 | 方向、心态与 12 个月节奏 | 推广只讲原则；本组讲执行细节 |
| 一个人的产品线 | 多产品之间的交叉推广与用户池 | 产品之间互推；本组讲单产品对外的渠道 |
| SaaS Starter | 有销售动作的 B2B 客户发现 | 需要拜访与采购流程；本组面向个人工具、扩展、桌面与微型产品 |
| SaaS 方向的获客手册 | 社区、内容与付费渠道的概览 | 一篇概览；本组是逐渠道手册 + 账本 + 复算 |
| 一个人把用户留住 | 激活之后的留存、流失、召回与续费 | 本组到「激活」为止；那组从激活往下接 |
| 一个人把价格定对：定价、付费墙与涨价 | 定价结构、付费墙位置与结账页摩擦 | 转化之后的钱怎么收；本组只讲到注册与激活为止 |
| 游戏发行与推广 | Steam 页面、众筹、主播、展会 | 游戏向渠道；本组不涉及商店页与主播合作 |
本组讨论的是「发布之后如何被陌生人发现」，不讨论产品是否值得做。选题与需求验证请回到一个人的前 100 天 第 02–03 篇。
本组统一口径
- 四个数：曝光（内容被展示）、访问（点击进入产品页）、注册（创建账号或留下邮箱）、激活（完成一次核心任务）。四层各自有分母，不混算。
- 渠道预算：每周可投入获客的时间按 6 小时计（教学假设），单条渠道维持成本按 2 小时/周计，因此同时运营不超过 3 条。
- 渠道成立判据：连续 4 周，每周至少 1 个完成激活的新用户，且期间无平台规则违规记录。达不到就只算「一次事件」，不算「一条渠道」。
- 时间窗：发布前 14 天预热，发布日为第 0 天，观察至第 90 天；所有渠道在同一窗口内比较。
- 成本口径：只记现金支出与可核实的自有工时，不把「朋友帮忙转发」折算成钱。
- 归因口径：同时保留首次触点、最后触点与用户自报来源三种记录，不合并成单一结论。
- 小样本：低于 100 个样本的比例一律给区间，不给点估计。
使用说明
- 文中的产品、用户、流量与转化数字都是教学假设，人物、引语和结果不代表经核实的真实案例。
- 平台规则会变化。本组只写行为层面的判断，不复制平台条款原文；发布前请以平台当日规则页为准。
- 本系列不构成营销承诺。任何渠道的效果都取决于产品、人群和时机，文中比例只用于演示计算方法。
- 外部链接只列在 2026-10-23 核验时可访问的页面；无法访问核验的，正文会明确说明「未附链接」。
本组的证据与使用方法
正文把教学假设、经验判断与可核实的外部规则分开标注。每篇末尾给出该篇的验收方式与可复算示例；渠道比例、转化区间与工时预算都是演示输入，必须用自己项目的实际数据重算。涉及用户数据、邮件发送与付费推广的操作，先确认适用的个人信息与广告规则，再执行。
系列导航
- 下一篇：获客是一本账，不是一次发布
- 相关专题：一个人的前 100 天 、独立开发者的平台寄生 、独立开发者生存指南