Build in Public 內容分發完整指南：7 步把開發日誌變客戶
Lovable 在 2025 年 7 月達成 $100M 年化營收。這個速度比 OpenAI、Cursor、Wiz 都更快。根據 TechCrunch 報導，這是軟體業史上最快的成長軌跡。CEO Anton Osika 在 Slush 2025 大會上公開宣佈這個里程碑。
支撐這套增長模式的核心是什麼？不是花大錢買廣告。而是一套系統化的 build in public 內容分發策略。
大多數創辦人對「build in public」的理解停留在表面層次。他們在 Twitter 上貼進度、在 Product Hunt 發佈、寫一篇中篇文章。但真正的 build in public 內容分發遠不止於此。
它是一套完整的工作流程。它把每條開發日誌、每個決策、每次用戶反饋都轉換成可重複分發的內容資產。同時自動篩選出真正感興趣的潛在客戶。
這篇文章深入剖析 build in public 內容分發的完整機制。我們從內容來源的系統化採集開始，到多渠道的智能分發，再到潛在客戶名單的自動沉澱。我們不會講通用的「最佳實踐」。而是針對三種不同規模的團隊——一人公司、2-5 人新創、10+ 人中期公司——拆解各自應該採用的 build in public 策略。
Build in Public 內容分發與傳統行銷的根本差異在哪
傳統行銷的核心邏輯很簡單：「我有產品，現在要把它賣給盡可能多的人」。公司投入廣告預算、買媒體版位、製作精緻的行銷物料。目標是最大化接觸量。
但 Lovable 在 2025 年 7 月達成 $100M 年化營收時採用的 build in public 內容分發策略完全相反。不是廣播式地推銷功能，而是系統化地記錄每一步開發過程。
這個差異造成的結果截然不同。傳統行銷帶來的是「被動接觸者」。build in public 帶來的是「主動跟蹤者」。
接觸者和跟蹤者的投入度差距極大。一個看到廣告的人可能點擊率是 0.5%～2%。一個每天打開開發日誌、追蹤進度的人，轉化為付費客戶的機率則高達 15%～40%。傳統行銷用「曝光」來衡量成功。build in public 內容分發則用「轉化率」來判斷效果。
Build in Public 內容分發的三層架構：來源、組織、分發
Build in Public 的三層架構為：來源、組織、分發。Lovable 在 8 個月內達成 $100M 年化營收，未建立龐大行銷部門。反而將開發日誌、功能迭代和使用者回饋系統化地轉換成三個相連層次，形成穩定的客戶分發管道。
第一層：結構化的內容採集
Lovable 為每條開發日誌設定三個判斷維度：技術難度、使用者影響、教育價值。
「修復按鈕延遲 200ms」缺乏教育價值。但「為何選擇 WebSocket 而非輪詢」同時具備技術難度和可學習性。
採集格式標準化為四個部分：問題定義、解決方案、數據對比、學到的教訓。這樣做的好處是內容可以快速轉化為多種格式。一篇結構化的開發日誌可以變成 Twitter 線程、YouTube 短視頻、部落格文章、產品更新郵件。
第二層：系統化組織與優化
採集後的內容不是立即分發。而是根據三個維度重新組織：時間線（這週、上月、季度里程碑）、類型（技術決策、性能優化、客戶反饋）、受眾（開發者、非技術用戶、投資人）。
第三層：多渠道智能分發
同一條內容可以同時出現在 Twitter、Product Hunt、部落格、郵件通訊、Discord 社群。但每個渠道的敘述角度要調整。Twitter 強調「驚喜時刻」。部落格深入「技術細節」。郵件突出「對用戶的影響」。
實作層：三種團隊規模的 Build in Public 內容分發方案
一人創辦人的核心限制是時間。最有效的 build in public 內容分發策略是什麼？把開發日誌直接變成分發資產，不經過編輯層。
這意味著你寫的每一條進度記錄都能立即分發。遇到的每一個技術難題可以直接發布。解決的每一個使用者反饋馬上變成內容。
Indie Hackers 排名前 50 的專案創辦人平均每週發布 3-5 次短格式更新。每次 150-300 字。他們的共同做法是完全跳過內容潤飾環節。
工具鏈應該極簡
使用 Notion 或 GitHub Discussions 記錄進度。透過 IFTTT 或 Zapier 自動同步到 Twitter、Product Hunt、Reddit。每條記錄發布後會自動觸發通知粉絲的流程。
2-5 人新創的 build in public 內容分發
有一個專職內容負責人時，策略要調整。這個人不是「做行銷」，而是「內容架構師」。每週開一次會議。收集團隊本週的開發日誌、決策記錄、用戶反饋。轉化為 8-12 條不同格式的內容。
10+ 人中期公司的系統化方案
此階段需要建立專門的內容系統。設立「內容小組」負責收集、組織、分發。每個部門（產品、技術、銷售）定期提交值得分享的內容素材。形成穩定的內容流。
案例研究：Lovable、Pieter Levels 與其他高速成長公司如何操作 Build in Public 內容分發
Lovable 的全透明策略
Lovable 在 2025 年 8 月達成 $100M 年化營收。隨後 4 個月內達到 $200M ARR。這個速度比 OpenAI、Cursor、Wiz 都更快。
這套增長並非源自傳統行銷預算。而是透過每週公開產品進度、實時分享財務數字、直播開發過程而實現。CEO Anton Osika 在每次里程碑時都會發布具體的數據。使用者數、營收曲線、技術決策過程都公開分享。讓潛在客戶感受到公司的透明度與速度感。
Pieter Levels 的個人分發模式
Pieter Levels 採用了極致化的 build in public 內容分發策略。他在 Twitter、Product Hunt、個人部落格上同步發布每一個產品里程碑。從第一個客戶、到達成第一個 $1,000 月收、到 $1M 年營收。每一步都詳細記錄。每一步都成為內容。
Twitter 上是簡短有趣的故事。部落格上是詳細的商業分析。這種多角度分發讓他的 build in public 內容分發覆蓋不同類型的受眾。創意工作者看部落格。企業家看 Twitter。投資人看收入報告。
常見問題
常見問題解答
問：分享開發日誌不會洩漏商業機密嗎？
不會洩漏核心機密，但要有選擇性地分享。Lovable 達成 $100M 年化營收期間，採用的 build in public 內容分發策略分享的是開發流程、使用者反饋和產品決策理由。而非演算法或架構密鑰。
關鍵在於分享「為什麼做」和「遇到什麼問題」。不是技術細節。
例如，可以分享：「我們發現用戶在註冊時的流失率達到 45%。因此決定簡化表單流程。」
不需要揭露：具體的演算法邏輯或系統架構。
這種透明度建立信任，同時保護競爭優勢。Stripe 和 Notion 的成長故事展示了這個平衡點。分享足夠多的資訊讓用戶理解產品方向。卻保留足夠的神秘感維持差異化。
問：build in public 內容分發需要天天發布嗎？
不需要。品質優於頻率。一人創辦人每週 3-5 次就足夠。新創團隊每週 10-15 條。中期公司每週 20+ 條。重點是保持規律，而不是無休止地發布。
結論
Build in Public 的成敗不取決於產品演示的精緻度，而在於能否把每日開發決策、踩過的坑、數據驅動的選擇轉化為可持續分發的內容單位。從一行程式碼的選擇，到客戶流失的根本原因分析，再到營收數字的公開披露——這些本來就存在的工作產物，只需要改變敘述角度和分發節奏，就能成為吸引潛在客戶的磁石。Lovable 和 Pieter Levels 的案例告訴我們，最高效的客戶獲取發生在你停止「做行銷」的時候，轉而把真實的建造過程當作內容本體。現在的問題不是「我要寫什麼」，而是「我今天的工作中哪些決策值得分享」。
重點整理
Build in Public 與傳統行銷的根本差異：不是包裝故事，而是把實際決策過程變成分發資產
三層架構缺一不可：來源層（開發日誌）、組織層（主題分類）、分發層（多管道排期）才能形成穩定循環
不同團隊規模有不同打法：個人創業者靠日報累積信任、小團隊靠專題深度、中型團隊靠系統化生產流程
成功案例的共同點不是內容多而是內容實：每一篇都帶著真實數據、失敗細節或決策邏輯
現有習慣中 50～70% 的工作內容可以即刻轉換：重點是識別並建立分發的工作流
開始的成本接近零：一份開發日誌、一個發佈時間表、三個分發管道就足以啟動
下一步
檢查你過去 7 天的工作日誌，挑出 3 個技術決策或數據發現，按照本文的三層架構重組成一篇 Build in Public 貼文，在你主要活躍的平台上發佈。紀錄反應數據，這是你評估分發管道有效性的唯一信號。
Sources
[^1]: The GitHub build in public guide outlines six distinct phases of building in public — https://github.com/buildinginpublic/buildinpublic
[^2]: Lovable reached $100M ARR in 8 months according to TechCrunch — https://www.buildinpublic.so/blog/build-in-public
[^3]: Bubble published a guide on building in public with a 10 minute read time — https://bubble.io/blog/case-for-building-in-public
[^4]: Distribution is identified as one of the biggest advantages of building in public — https://mercury.com/blog/build-in-public-or-private
Hogan