分发驱动开发 (DDD)：先写小红书笔记，再写代码

上周我在小红书发了一条笔记，宣传我周末做的一个桌面宠物应用：PawPal。

GitHub Repo | 小红书笔记

发布一周后，笔记收到了 6 万次浏览、10k+ 赞和收藏，GitHub 上累计 300 个 star 和 2200 多次安装下载。

做这个小玩意儿，其实不是因为我多需要一个桌面宠物，而是想实验一下新的开发流程。

现在 Coding Agent 越来越强，一个完整的应用从零到可用只需要一个周末。当"把东西做出来"不再是瓶颈的时候，真正的瓶颈就变成了：做出来之后，怎么找到用户。

所以我想试试，如果把重心从"怎么做产品"转移到"怎么让产品被看到"，效果会怎样？不再是"我想做个什么"，而是"什么东西在社交平台上容易火"。先从小红书找需求，逆向开发产品，然后再扔回小红书去分发。

我给这个流程起了个名字，叫 Distribution Driven Development (DDD)。

这篇笔记，就是这个实验跑完一周后的复盘。我想聊聊这套"倒着来"的流程到底跑不跑得通，以及，一条 6 万人看过的小红书笔记，到底能转化出多少真实的软件用户。

1. 怎么找到有潜力的产品方向

这次实验的出发点不是"我想做什么产品"，而是"什么产品容易传播、容易获取用户"。于是我的核心指标有两个：小红书的浏览/互动数，和 GitHub release 的下载量。一个衡量传播效果，一个衡量实际转化。

从内容倒推产品

既然重心是 distribution，那选产品方向的第一个问题就是：围绕这个产品，我能不能写出一条有传播力的内容？

一条有传播力的小红书笔记，最基本的要求是用户在信息流里刷到封面的那一瞬间就想点进来。影视飓风分享过他们做视频选题的方法论：出发点不是视频内容，而是标题和封面。

影视飓风的视频和观众的第一触点是视频封面，同样的逻辑，我的产品和小红书用户的第一触点是笔记封面。如果一个产品的功能没法用一张封面直观展示，或者需要一段话才能解释清楚它是干什么的，那它在小红书上的传播阻力就很大。所以我筛选产品方向的第一道关卡是：这个产品的 demo 截图，能不能直接做成让人一眼看懂、想点进来的小红书封面？

同时产品的受众也不能太窄。比如"提醒休息、喝水、不要分心"是所有学生和打工人共同的痛点，不需要任何专业知识就能理解价值。但如果做的是一个垂直领域工具（比如某个开发者 CLI），受众面会窄得多，在小红书上的传播也更困难。

屏幕上跑来跑去的桌面宠物天然满足这些条件：很视觉化一眼就懂，功能很容易解释，受众足够广。这是第一步选择了这个方向的核心原因。

低粉爆款验证

另外一个验证内容潜力的方法是：去小红书搜相关关键词，找"低粉爆款"。

大 V 发的内容能爆，可能只是因为粉丝基数大。但如果一个平时赞藏只有十几的素人号，突然出了一篇几千赞的笔记，说明这个内容本身精准命中了用户需求。

我找到了几个信号非常强的案例：

比如一个是 @大肥橘卡卡，之前主要发自家宠物猫，赞藏常年十几。四月初发了一篇"把猫做成电脑桌面宠物上班把玩"，点赞 5000+，收藏 2000+。

另一个是 @桌宠墩墩，之前发的都是探店笔记，赞藏普遍 10 左右。4 月 22 日发了一条"搓了一个桌宠监督我不要分心"，点赞 5000+，收藏 3000+。

关键是，这两条笔记中的产品都是博主自己做着玩的半成品，评论区里很多人在求打包上线。需求已经被验证了，但供给还不存在。

怎么写出有流量的小红书笔记

产品即内容，这是这次实验里我最大的体会。

传统的产品发布是先做产品，然后想怎么推广。

但我觉得在 DDD 模式下，一切都是反过来的：你得先想好这篇小红书笔记怎么写，再去设计产品。产品本身，就是为了这篇内容服务的。

除了前面说的"必须视觉化"，我在写笔记的时候，发现还有两个捷径。

一个是借力已有的 IP。其实一开始，我和我老婆用 gpt-image-2 和 lovart 生成了一个奶油色小金毛的形象，本来打算用它做默认宠物。但在准备写小红书笔记的时候，突然发现"线条小狗"是小红书默认的表情包之一，自带极强的辨识度。

所以临时决定，在笔记的所有配图里，全部换成了线条小狗（当然，这是在免费开源非商业化的前提下）。大家在信息流里刷到熟悉的表情包，根本不需要任何认知成本，天然就有亲切感。

另一个是顺着平台的语境说话。我的笔记标题是"做了个线条小狗陪上班-提醒休息、喝水、专心"，正文里写"...检测到走神开始刷小红书的时候提醒我不要分心..."。这种带点"牛马日常"的语境，比干巴巴地写"一款基于 Electron 开发的跨平台桌面提醒工具"应该效果更好。

我的小红书账号在发这条笔记之前只有 86 个粉丝。不是 KOL，没有粉丝基础。但这条笔记拿到了 46.2 万次曝光、6 万次观看、5,340 个赞。

小红书内容中心的算法也必不可少。换成 Twitter 或者公众号这种强依赖粉丝分发的平台，一个 86 粉的号，大概率就石沉大海了。这种算法机制，是 DDD 能在小红书跑通的基础设施。

2. 转化漏斗：实际数据

这是我做这个实验最想看的数据：一条 X 人看过的小红书笔记，到底能转化成多少实际的产品用户？

先看完整的漏斗（日期范围是：2026-05-01 到 2026-05-11）：

几个值得展开的环节：

互动质量异常高

小红书上正常的互动结构是点赞高于收藏和分享。这条笔记不太一样：

收藏是点赞的 85%，分享是点赞的 69%。这不是"好可爱点个赞就走"的消费型互动，而是"我要留着用"和"我要分享给朋友"的工具型互动。

我觉得这和产品选择直接相关。一个桌面宠物提醒你休息喝水，这不是纯审美消费，它解决了一个实际的、普遍的痛点。用户收藏它是因为真的打算回来下载，分享它是因为觉得朋友也需要。

小红书到 GitHub：95% 的"应有"转化被 friction 吃掉了

46万曝光，6 万次观看，但最后摸到 GitHub 的，大概只有 1500 多人（扣除 t.co 和其他来源后推算）。从曝光到 GitHub 的转化率，只有可怜的 0.3%。

单看这个数字本身不知道是高是低，需要一个 benchmark。

正好有一组对照数据。GitHub launch 两天后，Twitter 上一个 10 万粉丝的博主 @geekbb 自发转发了 PawPal，把我 GitHub 上的产品简介翻译成了推文。这条推文 12,300 次 views（64 个赞、8 次转发、3 条评论），带来了 215 个 GitHub 访客。

看内容对受众的吸引力，用互动率（互动 / 曝光）作为 proxy：

小红书互动率是 Twitter 的 5 倍。说明小红书的内容受众明显更买账。

但再看 GitHub 转化率，反过来了：

Twitter 转化率是小红书的 6 倍。

如果内容吸引力是主要变量，小红书 5x 的互动率应该对应 ~5x 的 GitHub 转化率，也就是 ~8%。实际是 0.3%。差不多 95% 的"应有"转化在中间环节蒸发了。

蒸发去哪了？最直接的原因就是小红书不允许笔记里放外链，我只能把 GitHub 地址留在评论区置顶和最后一张图里。用户想下载，得自己退出小红书，打开浏览器，手动输入或者搜索 URL。每多一步，就掉一层人。而 Twitter 上的用户，链接直接在推文里，点一下就直接跳到 Github。

另一个原因可能是用户画像。Twitter 上关注科技博主的，本来就有很多开发者，看到 GitHub 链接毫无障碍。但小红书推给打工人的时候，很多人可能根本不知道 GitHub 是什么，更别说去 release 页面找安装包了。

但不管怎样，从产品分发的视角看，这就是把小红书当引流渠道必须承受的"结构性损耗"。

流量溢出

PawPal 还带来了一些溢出。虽然这些数据不关键，但作为之后可能的参考。3,041 人访问了我的小红书主页，新增 170 人关注。213 人在 10 天内访问了我的个人网站 zebang.li，比上个周期增长了 127%。

3. 开发经验和教训

Windows 需求被严重低估

PawPal 第一个版本只支持 Mac ARM。发布前我觉得先发 Mac 版应该够了。

评论区迅速打脸。大量评论在问"有 Windows 版吗"。甚至有人自己拉了源码在 Windows 上跑，跑到评论区来帮我报 bug、确认安装流程。发布第二天我就加上了 Windows 安装包。

如果算总下载量，Windows 大概占 40% 多。但这个数据其实是被污染的——因为前两个版本根本没有 Windows 包。如果撇开前两个版本，只统计 Mac 和 Windows 同时提供的版本，真实的下载分布是：

Windows 才是绝对的大头。

回过头来看，小红书的用户群和 Hacker News、Twitter 开发者圈的结构完全不同。后者 Mac 占绝对主导，但小红书上 Windows 比例高得多。

教训是：分发渠道决定了用户画像，用户画像决定了产品决策。 因为一开始没有 Windows 版，第一波流量中有不少 Windows 用户看到笔记感兴趣但下载不了，直接流失了。这些人大概率不会在第二天 Windows 版上线后回来找。

Electron：没人在意

PawPal 是用 Electron 写的。做之前我有点犹豫：一个这么小的桌面工具用 Electron，安装包 140MB，会不会被用户说体积大、占资源？我是不是应该花点时间去折腾一下 Tauri，把体积打下来？

但事实是：评论区 400 多条评论和 GitHub issue 里，没有一个人提到 Electron，也没有一个人抱怨体积或资源占用。用户关心的是小狗好不好看、有没有 Windows 版、能不能自定义宠物形象...

前阵子 Claude 出桌面版，也是个 Electron 套壳，Hacker News 上一堆开发者在吐槽。但 Anthropic 的工程师回得很实在：团队熟练，能复用代码，AI 写起来快。对 PawPal 来说也是一样，我最熟悉的就是 Web 技术栈，用 Electron，一个周末就能把 MVP 跑通。如果当时为了追求体积优势去死磕 Tauri 里的 Rust 绑定，这个周末项目大概率就夭折了。

更大的感受是：开发者在 tech stack 选择上花的时间，和用户实际关心的东西之间存在很大的错配。我们会纠结 Electron vs Tauri vs native，讨论内存占用差 50MB 的 trade-off。但实际用户根本不在意这些。用户在意产品好不好用、功能全不全、设计好不好看。

不是说 Agentic Coding 时代 tech stack 不重要。大规模产品、高性能场景、需要长期维护的大团队项目里，tech stack 选择还是很关键。但对于一个快速验证需求的小产品来说，选自己最熟悉的、coding agent 写起来最顺手的就足够了。

评论区驱动的迭代

笔记发出去的一周，我更新了 6 个版本：

每一个 release 都是直接回应评论区或 GitHub issue 的反馈。小红书就是一个免费、实时、且极其活跃的产品需求池。你根本不需要搞什么问卷调查，用户想要什么，全写在评论里了。

这种"上午看到评论求功能，下午就发个新 release"的迭代速度，放在以前也比较难想象。但现在有了 Agentic Coding 工具，从需求到代码的距离被无限缩短了。这也是 DDD 能跑通的底座：如果一个功能要憋一个星期才能上，小红书上的热度早就凉透了。

尾声

整个实验算下来，我大概投入了 20 个小时（写 MVP、迭代、写笔记），没花钱推广。换来了 2000 多次下载，40 万次曝光，和 300 多个 GitHub Star。

DDD 的核心步骤可以总结为：

1. 从内容倒推产品：先问"围绕这个产品能不能写出有传播力的内容"，再问"这个产品值不值得做"。具体来说，产品的 demo 截图能不能直接做一张让人一眼看懂的小红书封面？受众够不够广？
2. 低粉爆款验证：在小红书搜目标方向的关键词，找低粉账号的高互动笔记验证需求强度。
3. 快速开发：MVP 控制在三天之内，缩短从需求发现到上线的窗口期
4. 迭代闭环：笔记发布后，用评论区和 GitHub issue 作为实时需求池，高频迭代

这套方法有几个明确的局限。它只适合视觉化的、一眼能懂的、受众广泛的产品。垂直工具、API 服务、B2B SaaS 在小红书上没有天然的内容载体。它需要快速开发的能力（不适合 launch readiness 复杂的产品）。它也还没解决商业化问题，大家愿意下载，不代表愿意掏钱。

但作为一个独立开发者，或者只是有个好玩的 idea，想要最快速度回答"这玩意儿到底有没有人要"，这套方法仍然值得一试。而且在过程中直接和用户面对面、用代码实时回应真实需求的感觉还挺让人开心的。