Build in public 之前，先问用户在哪里

知名开源项目 Ant Design Vue 的作者 tangjinzhou 在小红书上聊过一次 Build in public，我觉得里面最值得记下来的不是“要不要公开创业”，而是另一个更现实的问题：你到底公开给谁看？

原文在这里：http://xhslink.com/o/42TtJm3SbO9

下面是我对这段观点的整理，以及一些补充判断。核心判断很简单：Build in public 不是把项目摊开给所有人看。它只有在目标用户能看到、能参与、能反馈的时候才有意义。

如果目标用户不在场，公开构建很容易变成另一件事：把需求、进展和增长信号提前暴露给同行。

独立开发者为什么会纠结公开

大公司做新项目，通常不会一边开发一边直播。

项目组、权限、代号、保密协议、发布节奏，这些东西背后都是组织资源。等产品准备好了，再用品牌、渠道、销售和预算推向市场。

独立开发者没有这些东西。

没有广告预算，没有销售团队，没有成熟渠道，甚至连第一批用户在哪里都不确定。于是 Build in public 就变成一种看起来很自然的获客方式：一边做，一边讲，一边吸引早期用户。

这不是错。

但这里有一个容易被包装掉的事实：很多人不是因为“公开”本身更高级，而是因为不公开就没人知道。

所以 Build in public 不是信仰问题，是分发问题。

先问目标用户在哪里

讨论 Build in public，最常见的问题是：要不要晒收入？要不要公开路线图？要不要每天发进展？

这些问题都太靠后了。

真正应该先问的是：目标用户在哪里？

如果你的产品卖给独立开发者、程序员、创业者，公开构建当然有意义。因为你的潜在用户就在开发者社区、X、即刻、小红书、独立开发者群里。他们会关心你怎么找需求、怎么做 MVP、怎么定价、怎么增长。你晒收入、晒试错、晒技术选型，本身就是内容，也可能是信任资产。

这类产品本质上是在卖铲子。

卖开发者工具、SaaS starter、AI 编程工作流、增长课程、模板、开源组件，都适合一定程度的公开构建。因为围观你的人，可能就是你的目标用户。

但如果你做的是一个很垂直的业务工具，目标用户是老师、律师、诊所、外贸销售、物业公司、餐饮门店，情况就不一样了。

你跑到程序员社区里说“我发现了一个很好的细分需求”，目标用户未必看得到，同行反而看得很清楚。

如果这个需求真的成立，抄袭和跟进基本无法避免。尤其是独立开发者之间，能力半径接近，产品复杂度不高，一个方向只要被证明能挣钱，很快就会有人冲进去。

这不是道德问题，是市场机制。

AI 产品还多了一层成本

AI 产品会把这个问题放大。

以前做一个互联网产品，多来一些免费用户，主要是服务器和带宽压力。现在很多 AI 产品每一次生成、每一次对话、每一次试用，都是真实的 token 成本。

流量不是天然资产。流量可能也是账单。

所以 AI 产品做 Build in public，不能只看“来了多少人”。更重要的是：来的人是谁？

是会付费的目标用户，还是只想白嫖试用额度的围观者？是能提供真实反馈的人，还是准备复刻你产品的人？是能帮你理解场景的人，还是只会问“怎么做的”的同行？

这些问题不想清楚，公开构建就会变成一种高成本噪音。

SEO 型产品里也有类似现象。很多人会分享今天来了多少订阅、广告收入又涨了多少、流量创新高，但不会告诉你具体站点、关键词和 niche。原因很简单：这类机会一旦公开，复制者马上就会进来，最后大家一起把利润打薄。

这也是一种公开。

只不过公开的是结果，不是矿点。

该公开什么，不该公开什么

tangjinzhou 这里有一个很实用的划分：公开给用户看的内容，应该是用户能感知的东西。

不是开发日记。

开发者会关心你用了什么框架、怎么部署、怎么接 API、数据库怎么设计。但真实用户通常不关心这些。用户关心的是：这个产品能不能解决我的问题？现在是不是更好用了？我能不能相信你会持续做下去？

所以更适合公开的是四类东西。

故事。

你为什么做这个产品？你看到了什么问题？这个问题为什么值得解决？这不是煽情，而是让用户知道你理解他的处境。

进展。

但不是“今天修了 12 个 bug”“重构了订单表”。用户能感知的进展，是截图、动图、功能预告、流程变化和体验改善。不要晒自己很忙，要晒用户少做了什么。

反馈。

Build in public 真正有价值的地方，不是让人围观你努力，而是让目标用户参与进来。投票、内测、问卷、需求排序、案例征集、用户访谈，都比单方面发进度更有用。

价值。

后期最该公开的不是收入，而是案例。比如一个老师用你的工具，两小时备完一节课；一个外贸销售用你的系统，把客户跟进从 Excel 搬到自动提醒；一个小团队用你的产品，把重复工作从三个人压到一个人。

这些东西对目标用户有意义，对同行也没那么容易直接复制。因为你公开的不是“我发现了哪个需求”，而是“用户拿它解决了什么问题”。

相反，下面这些东西要谨慎：

• 具体 niche 和关键词
• 真实收入和转化率
• 获客渠道的细节
• 过于精确的用户画像
• 还没形成壁垒的产品路线图

这些信息对目标用户未必重要，但对竞争者很重要。

很多人喜欢说“不怕抄，关键是执行”。这句话长期看没错。执行、分发、品牌和用户理解确实比点子重要。

但早期不一样。

早期独立开发者的优势本来就很薄，一个刚被验证的小需求，被几个同类型团队同时冲进去，利润空间很快就会变差。

不怕抄，不等于主动递刀。

更现实的做法

我更认同的做法是：先找广场，再决定公开什么。

目标用户在小红书，就去小红书讲使用场景和用户故事。目标用户在教师社群，就去教师社群征集备课痛点。目标用户在 Reddit，就按对应 subreddit 的语境写案例。目标用户在开发者社区，再去讲技术路线、构建过程和收入数据。

公开不是目的，触达才是目的。

然后再给内容分层。

给目标用户看故事、进展、反馈和案例。给同行看的内容，要么足够泛化，要么本来就是你的获客策略。收入可以晒，但不要把还没站稳的机会晒成教程。技术可以讲，但不要把关键渠道、关键词和转化路径全摊开。

这不是保守，是边界感。

Build in public 的核心不是让同行围观你创业，而是让目标用户陪你把产品打磨出来。

如果公开之后，来的人不能反馈、不能试用、不能付费、不能传播，只会夸一句“很强”或者问一句“怎么做的”，那这个 public 对产品没有太大意义。

它只是热闹。

我的结论是：Build in public 可以做，但不要迷信。先判断用户在哪里，再决定公开范围。对用户公开价值，对同行保留关键细节。

公开构建不是把项目摊开给所有人看。

它是站到目标用户所在的广场上，把该讲的东西讲清楚。

参考来源：

• tangjinzhou，Ant Design Vue 作者，小红书：http://xhslink.com/o/42TtJm3SbO9