分享一个关于“公开构建”的心理折磨和实操复盘

盯着一条推文草稿改了六遍，花掉四十分钟，最后点发送的时候居然产生了生理性的反胃。这事儿挺讽刺的，我以前在两百人的会议上做报告面不改色，给CTO辩护技术架构时稳如老狗，甚至在超级碗广告期间处理过生产环境宕机，但面对几十个关注者发一句“我的AI自动化工具出初版了”，我居然崩溃了。

结果发出去之后呢？没人关心。两个赞，一个机器人的回复。世界没毁灭，我还没死。

这种“公开构建（Building in Public）”的脏秘密就在于：恐惧是真实的，但风险是想象出来的。在起步阶段，根本没人盯着你，而这恰恰是最大的优势。

在这几个月的公开构建实战中，我发现一个反直觉的结论：脆弱感不是副作用，它本身就是一种增长策略。

以前我总想把产品包装得完美无缺，后来我试着诚实地写我的数据——零用户、尴尬的Bug、花三天开发却没人要的功能。结果神奇的事情发生了，真正精准的用户反而找上门了。有人跟我吐槽Webhook的不稳定性，有人说他试过做类似工具但失败了。这些通过真实连接建立的信任，比任何精美的落地页或SEO手段都管用。

分享失败比分享成功更能建立信任。现在满大街都是Product Hunt上线成功的战报，但很少有人写在上线前那三个月里，GitHub贡献图像心电图停止跳动一样平整，以及每天怀疑人生的心路历程。当你写这些时，你其实是在给其他开发者提供一种“心理许可”，让他们知道在混乱的中间地带挣扎是正常的。

当然，公开不代表没有底线。我给自己设定了一套简单的过滤机制，防止在公开过程中踩坑：

• 公开项： 真实的营收数字（拒绝那种“月环比增长300%”的虚荣指标）、具体的技术决策及其背后的权衡、开发过程中的情绪波动。
• 保密项： 任何涉及用户隐私的数据、会得罪前雇主的细节、以及还没思考清楚、处于极度混乱状态的初步想法。

另外，这种方式带来的强制约束力非常硬核。我之前公开承诺每周交付一个新功能，这种微小的社交压力成了我把产品从80%完成度推向100%的唯一动力。如果没有这几个人盯着，我大概率会在某个细节上死磕，然后直接放弃。

如果你问我是否建议所有人这么干，我的答案是：不一定。它不是什么快速增长的黑客技巧，它很慢，而且极度不舒服，可能几个月都看不到回报。但如果你已经在孤独地构建产品，且本身就有记录习惯，那么把它公开出来的成本几乎为零，但它能帮你打开一些你根本意识不到的门。

现在我依然会在发布前紧张，但我把这种感觉当成了信号：如果我害怕发这条内容，那它大概率就是最值得发的内容。