案例库
Pieter Levels:多产品组合与自动化运营案例
基于 Pieter Levels 的项目清单和公开复盘,分析多产品组合、自动化运营以及哪些条件不能被新手直接复制。
可复制的是快速验证、公开记录和自动化思路,不可复制的是长期受众与既有分发优势。

产品实景
产品长什么样
以下截图来自产品官方公开页面,用来说明产品用途,不代表合作、背书或经营结果证明。
60 秒结论
一分钟看懂这篇文章
可复制的是快速验证、公开记录和自动化思路,不可复制的是长期受众与既有分发优势。
人负责
- 选择问题
- 决定取舍
- 承担产品责任
AI 负责
- 公开工具未完整披露
- 自动化重复运营
- 辅助信息整理
- 核查来源
- 拆解产品
- 判断边界
- 提炼经验
直接结论
Pieter Levels 的公开资料支持一个有限结论:他长期发布多个产品,让相邻产品围绕数字游民、远程工作等需求形成组合,并把数据聚合、筛选和发布中的重复步骤交给软件系统。这个案例值得学习的是低成本试验、持续迭代和流程化运营,不是“项目越多越好”或“一个人可以不用承担运营责任”。
本文不提供当前收入结论。来源中出现的收入都属于特定年份或访谈时点的本人披露,未经独立审计,也不能外推到 2026 年。当前团队、外包规模和完整技术栈均未公开。
证据状态
- 公开事实: 截至 2026 年 7 月 19 日,项目清单页面可直接看到 Nomad List、Remote OK 等项目及其状态,也同时列出大量失败、停止或非营利项目;Nomad List 五周年页面展示了城市数据、用户评论、众包图片和合作数据等产品机制。
- 创始人自述: Levels 在 2019 年复盘中称 Nomad List 的首版于五年前发布;在 2022 年访谈中,他回顾 Remote OK 从聚合岗位到向雇主收取发布费的过程,并提到当时有承包商处理客户支持。这些说法没有在本文中被当作独立审计事实。
- 编辑判断: 多产品不是目的。较有价值的模式是先验证一个窄问题,再让同一客群的相邻需求共享认知与分发;是否适合新经营者,仍取决于获客能力、数据责任和人工容量。
产品与目标客户
Nomad List 面向需要比较城市、远程生活条件和社区信息的人。2019 年五周年复盘公开展示了城市数据、匿名评论、众包图片与地点索引等机制。Remote OK 则把远程岗位求职者与发布岗位的雇主连接起来。
两者相邻但并不相同:一个帮助用户判断在哪里生活和工作,另一个帮助用户寻找或发布远程岗位。项目清单还显示他做过许多未成功或已经停止的尝试,因此不能只看留下来的产品,再倒推出每次发布都会成功。
商业模式与获客
2022 年访谈中,Levels 回顾 Remote OK 早期先聚合其他招聘网站中的远程职位,后来开始向直接发布岗位的公司收费。具体收费数字和收入曲线属于当时的创始人自述,本文不把它们写成当前价格或当前收入。
公开资料反复出现产品发布、公开记录和社交媒体传播。编辑部据此将公开发布、长期内容记录、搜索与口碑视为主要获客路径,但不把某一次病毒传播归因于可稳定复制的公式。市场时点也很重要:Levels 在访谈中明确把 Remote OK 后来的增长与远程工作市场变化联系起来。
人工工作与自动化
可以确认的系统化部分包括岗位聚合、数据筛选、地点索引、用户评论与众包图片流程。2019 年复盘还写到外部数据合作和语言匹配。这说明软件、用户贡献和合作数据能够减少重复录入,但不等于数据无需审核或产品无需维护。
人的工作仍包括选择问题、定义字段、调整产品规则、处理异常和承担收费与数据责任。2022 年访谈提到当时有客服承包商,因此“完全由一个人完成所有运营”不成立。公开来源没有完整披露当前人员安排,也没有披露可用于这些核心产品的完整 AI 工具链;本案的 aiStack 因而记录为“未公开”。
可复制做法
- 从一个具体问题发布可用的小版本,让真实行为而不是宏观趋势决定下一步。
- 把项目状态、失败和复盘保留下来,避免只展示幸存项目。
- 将可规则化的数据收集、筛选与发布做成系统,同时保留异常处理入口。
- 在同一客群中寻找相邻需求,但要求每个产品各自有清楚的用户与付费理由。
- 对收费、数据质量和用户支持设置人工责任人,不把自动运行等同于无需治理。
不可复制条件
Levels 的长期个人受众、搜索资产、品牌认知和公开分发记录不是新项目上线时自动拥有的。数字游民与远程工作在特定年份的市场变化也无法通过照抄页面或功能重现。
项目组合还会放大维护、支持、数据授权和注意力切换成本。没有稳定获客渠道与取舍规则的新经营者,同时启动许多项目更可能稀释验证,而不是形成组合优势。
AOPC 适配判断
本案与 AOPC 相符的部分,是经营者亲自决定问题和规则,让软件承担大量重复执行,并通过多个数字产品放大个人产出。不相符或证据不足的部分,是它并非“只有创始人、没有其他人参与”:来源明确出现过客服承包商、数据合作方和用户贡献,当前协作结构又未公开。
因此,适配结论是“部分符合,可借鉴系统化方法,不可当作纯一人全自动模板”。AOPC 实践者应复制清晰责任、窄范围验证和可审查的自动化,不应复制未经验证的项目数量、收入预期或技术栈。
来源
- Pieter Levels:List of all my projects ever核查于 2026/7/19,访问于 2026 年 7 月 19 日;用于核查公开项目组合、项目状态与失败项目。
- Pieter Levels:Nomad List turns 5核查于 2026/7/19,发布于 2019 年 7 月 29 日,访问于 2026 年 7 月 19 日;用于核查产品起点、数据、用户贡献和合作机制。
- Pieter Levels:Indie Hackers Podcast transcript核查于 2026/7/19,发布于 2022 年 1 月 26 日,访问于 2026 年 7 月 19 日;用于标注创始人对 Remote OK 商业模式、市场变化和当时客服承包安排的自述。
所有商业结果与经营过程均按来源时点理解;本文的 AOPC 适配结论属于编辑判断,不构成收入预测或经营承诺。
从案例到行动
前 30 天怎么借鉴
不照搬结果,只把案例中可复制的方法拆成三个验证阶段。每一步都要结合自己的客户证据重新判断。
第 1–7 天
收窄问题
用小版本验证具体问题,再依据真实使用反馈迭代
第 8–14 天
验证流程
公开记录成功、失败与项目状态,保留可追溯的学习材料
第 15–30 天
形成闭环
把数据收集、筛选和重复发布流程做成系统

