作者｜冬梅
這個時代最大的紅利是，AI 降低了創業門檻，普通人也能借助 AI 工具快速變現。
最近有個金額不算特別巨大的收購案在技術圈內引發持續關注：海外網際網路巨頭 Wix 斥資 8000 萬美元（約 5.7 億人民幣）現金，買下一家成立僅 6 個月的 AI 小公司 Base44。
這家公司到底有多神奇？它的創始人身上有著這樣幾個標籤：90 後、獨立開發者、白手起家的“富一代”。
據報道，Base44 作為一家獨立公司成立六個月後，使用者數量增長至 25 萬，並在成立後的三週內就達到了 1 萬。根據 Shlomo 在 X 和 LinkedIn 上的帖子，該公司已實現盈利，即使在支付了高昂的大語言模型 token 成本（他也公開記錄了這一點）後，5 月份仍實現了 18.9 萬美元的利潤。
其實在建立 Base44 專案之前，Shlomo 在 AI 創業圈已經小有名氣。
Shlomo 今年 31 歲，是一位前端開發者。早在 2017 年，他就與朋友共同創辦資料分析公司 Explorium，經過 8 年的發展，Explorium 目前擁有 100 多名員工，並獲得全球知名投資機構 Insight Partners 的投資，現已籌集約 1.25 億美元。
2024 年，Shlomo 在一次旅行中萌生了開展副業專案的念頭，並迅速鎖定了“氛圍程式設計”（Vibe Coding）這一新興領域。該技術本質上是一種由人工智慧驅動的開發模式，允許開發者僅需透過自然語言描述需求，即可由 AI 自動生成可立即部署的程式碼。
Base44 的誕生並非源於宏大的商業藍圖，而是兩個具體的現實需求。Maor 的女友是一名藝術家，需要一個網站來獲取客戶線索，但市面上的建站工具要麼操作繁瑣，要麼功能侷限，尤其在資料管理和適配移動端時問題頻發；與此同時，他參與一個專案急需各類管理系統，卻因缺乏技術團隊，不得不向第三方機構支付高昂費用。
這兩個場景讓曾在資料領域深耕七年、創辦過估值百萬美元企業 Explorium 的 Shlomo 敏銳地意識到：LLM 早已具備編寫程式碼的能力，只是缺少合適的基礎設施。“如果能讓 AI 直接生成包含資料庫、使用者管理、資料分析等全功能的應用，無需額外對接第三方服務，普通人也能輕鬆構建複雜工具。” 帶著這個想法，他決定重返最熱愛的編碼工作，打造一款 “開箱即用” 的 AI 開發平臺。
與許多創業者不同，Maor 並未打算將 Base44 打造成顛覆行業的巨無霸。經歷過大規模融資和企業管理的壓力後，他只想做一件 “有趣且能解決實際問題” 的事。這種輕裝上陣的心態，反而成了後續爆發的關鍵。
在 AI 編碼工具扎堆的賽道中，Base44 的突圍秘訣在於 “全棧原生” 的設計理念。當時，同類產品如 Replit、Vercel 等多采用 “前端生成 + 第三方後端整合” 模式，使用者需自行對接 Supabase 等服務，操作複雜且穩定性受限。而 Base44 從一開始就將資料庫、使用者系統、分析工具等核心功能內建其中，形成 “一站式閉環”。
用 Maor 的話說，這是一種 “電池內建”（batteries included）的思路 —— 使用者只需用自然語言描述需求（比如 “構建一個客戶管理系統”），AI 就能生成包含前後端的完整應用，無需處理 API 金鑰或第三方整合。這種設計讓非技術使用者也能快速搭建複雜工具，而 “自適應軟體” 的特性更讓產品能隨使用者需求變化即時調整，極大降低了迭代成本。
Shlomo 開發的工具允許使用者無需任何程式設計經驗，只需編寫簡單的文字提示即可構建應用程式或遊戲，類似於與 ChatGPT 互動。在短短幾個月內，Base44 吸引了超過 10 萬名使用者，並與 eToro 和 Similarweb 等以色列科技公司簽署了合作協議。
“到目前為止，這真是一段瘋狂的旅程，”Shlomo 在領英上宣佈收購訊息時寫道。儘管公司實現了增長和盈利——或者說正因為如此——他還是賣掉了這家仍在白手起家的公司，因為“我們需要的規模和數量不是我們能夠有機增長的……如果我們能夠有機地、白手起家地走到今天，那麼在擁有所有資源的情況下，我很高興看到我們新的發展速度，”他寫道。
近日，Shlomo 作客了一檔名為《Lenny's Podcast》的部落格欄目，分享了 Base44 從僅 3 位使用者發展到 40 萬用戶且無需花費任何營銷費用的增長策略。
他詳細講述了此次創業中的幾個關鍵經歷：如何在三個月內不寫一行前端程式碼的情況下推進專案，以及如何最佳化程式碼儲存庫結構以提升 AI 的程式碼生成效率；他的 AI 生產力技術棧如何幫助這家初創公司與資金雄厚的競爭對手抗衡；以及為什麼在 AI 領域作為獨立創始人反而可能成為獨特優勢。
在該播客中，Shlomo 還回顧了更具戲劇性的時刻——在伊朗戰爭爆發當天簽署 8000 萬美元收購協議的驚險歷程，並深入探討了創業者面臨的核心抉擇：如何判斷出售公司與保持獨立的時機（儘管 Base44 當時盈利狀況良好，但聯合創始人 Maor 最終選擇了接受收購）。此外，他揭秘了產品迭代中的反常識決策——透過刪除某些“有用”功能，反而使使用者啟用量提升兩倍；以及如何透過“在 LinkedIn 公開構建過程”這一策略，實現了比任何付費渠道都顯著的增長效果。
以下為播客翻譯，InfoQ 在不改變原意的基礎上進行了編輯：
Shlomo：Base44 是一個人工智慧應用構建平臺，你可以用自然語言描述你想構建的東西，比如一個應用程式、一款遊戲、一個網站之類的，然後讓 AI 為你編寫程式碼。我們並不是第一家做這種專案的公司，這個領域競爭很激烈，但 Base44 採用了一種稱之為 “內建所有功能” 的方法。意思是，在 Base44 上構建的每個應用，都已經內建了資料庫、整合功能、使用者管理、分析工具等，無需連線第三方服務或提供 API 金鑰之類的東西。我覺得這對於將一個由 AI 編寫的應用擴充套件成複雜且功能完善的應用非常有幫助。
目前這個領域的大多數產品都表現得很出色。其中一些產品專注於構建 React 前端網頁應用，當用戶需要後端功能時，它們能夠與 Supabase 實現良好整合。可以說，Supabase 是大多數競品最常採用的工具。
平心而論，這些產品在整合方面都做得不錯，但從整合的本質來看，這種方案可能不如全棧構建方式來得可靠。我們在開發 Base44 時，特別注重端點和 SDK 的設計，使其能夠與大型語言模型無縫協作。正因如此，我認為 Base44 在構建複雜、實用且適用於真實場景的應用方面，確實做得非常出色。
Shlomo： 沒有了，我覺得差不多就是這些了。現在回想起來，這聽起來確實很不可思議，但主要情況就是這樣。
Shlomo： 這段經歷其實源於兩個非常具體的需求場景，讓我意識到 AI 驅動開發的巨大潛力：第一個契機是幫我藝術家女友搭建小公司網站。當時市面上的建站工具體驗很糟糕——那些非 AI 的傳統拖拽式編輯器在移動端總是排版錯亂，資料管理也很麻煩。在我之前從事 LLM 相關工作時，我就很困惑：明明 AI 模型已經能編寫程式碼了，為什麼不能直接用它來建網站？現有的工具缺乏一個關鍵基礎設施：比如線索自動存入資料庫、生成的 React 程式碼要兼顧 SEO 最佳化等。如果搭建好這套基礎設施，連我女友這樣的非技術人員都能輕鬆操作。
第二個契機來自我在以色列童子軍組織的志願工作。這個數萬人的大型組織經常面臨軟體需求，但既沒有內部開發團隊，外包報價又動輒上百萬美元。雖然我是 Retool 等低程式碼工具的忠實使用者，但它們仍需要一定的 JavaScript 基礎。我清楚地知道，透過大語言模型技術完全可以實現：只要建立正確的基礎設施，讓 AI 能夠訪問資料庫、整合使用者管理系統，就能將使用者需求直接轉化為可用程式碼。這兩個實際痛點最終促使我著手建立解決方案。
七年前我創立了 Explorium，這家公司與 Base44 截然不同——它是資料領域的企業級服務公司，採用傳統的自上而下銷售模式，融資規模高達 1.3 億美元。我擔任了七年 CEO，去年 10 月，我選擇環球旅行了一段時間，想要好好休整。
這段經歷讓我重新思考：在 Explorium 快速擴張的這些年裡，我漸漸遠離了最熱愛的程式設計工作。現在，我渴望迴歸技術本身，重新親自動手創造。我把這個想法分享給了我的伴侶和幾位投資人，決定以完全不同的方式再次創業——不再像以前那樣追求鉅額融資和行業壟斷，而是專注於打造一個真正讓我感到興奮的產品。
正是這種“輕裝上陣”的創業心態——沒有包袱，帶著獨特的行業視角，純粹為了創造樂趣而出發——最終催生了 Base44。說實話，我完全沒預料到它會如此迅速地獲得成功，但這就是 Base44 誕生的故事。
Shlomo： 獨立創業並不適合所有型別的公司。如果你要創辦一家 B2B 企業服務公司，需要組建銷售團隊、投入營銷預算，那麼單打獨鬥會非常困難——畢竟客戶會擔心這家“一人公司”能否長期存活。但如果你開發的是具有病毒式傳播潛力的產品，能夠快速實現產品市場匹配，獨立創業反而更具優勢。從財務角度看，如果能靠自有資金起步並實現盈利，往往能獲得更好的回報。
作為經歷過兩種創業模式的人，我深刻體會到自力更生的優勢。雖然我之前的公司融資 1.3 億美元，投資者也很支援，但資金壓力始終存在。而 Base44 這種盈利模式讓我能保持更好的創業狀態。不過獨立創業確實面臨諸多挑戰：
首先是運維壓力。沒有運維團隊，所有伺服器問題都要自己解決。記得在我哥哥婚禮上，我不得不找藉口離開兩個小時處理所謂的“駭客攻擊”——後來發現只是使用者誤報的加密包錯誤。這種突發狀況讓人精疲力盡。
其次是孤獨感。在之前的公司，有聯合創始人可以分擔壓力、互相調侃。但獨自創業時，所有重擔都要自己扛，連說句“今天你值班”的機會都沒有。
再者是優先順序抉擇。作為獨立創始人，你必須在產品迭代和市場營銷間不斷權衡。雖然我更享受寫程式碼，但有時不得不把獲客放在首位。我每天都會自問："今天最該做什麼？最想做什麼？"這種思維切換很耗精力。
最後是效率最佳化。我花了大量時間構建自動化工作流，比如將 Cursor 用於後端、將 Base44 用於前端程式碼庫，確保能快速迭代。在當今 AI 輔助開發的時代，小團隊更需要這種效率優勢。營銷等環節也要儘可能自動化，否則時間管理就會成為創業失敗的主因。
Shlomo： 我患有嚴重的多動症，這既可能成為阻礙，也能化作一種超能力。但首先要做的，是確保工作日的安排能讓自己保持專注，有足夠的時間進行深度工作。我用一款叫 RescueTime 的工具，很合心意，類似的工具還有不少，它們能遮蔽 Twitter、LinkedIn 等平臺的訪問許可權。這操作起來其實挺難的，因為我當時正採用 “公開構建” 的模式，而這後來對 Base44 的發展效果顯著。畢竟每次總想看看自己發的帖子有多少點贊和瀏覽量，一琢磨就沒法做別的事了。所以我最初的設定裡，專門配置了一套能幫我進入深度工作狀態的軟體工具。
Cursor 這款工具特別好用。而 Base44 不僅搞定了前端開發的工作，我還用它搭建了很多業務應用 —— 在 Base44 的基礎上，實現了使用者管理、積分發放、內容創作等功能。我還做了個應用，每週剛開始時，我會把大致的內容創意寫進去，它會先把這些想法轉化成符合我風格的 LinkedIn 帖子，我確認後，又能自動改成適合 Twitter 的內容。這些都是完全按我的工作流程和需求定製的，幫了我大忙。不過我覺得，不光是 Base44，用其他工具也能編寫出適合自己的生產力工具，關鍵是貼合自己的做事方式和流程。就像我發社交帖子的流程，可能和別人都不一樣，所以專門定製的應用才格外管用。
Shlomo：我習慣在靈感閃現時抓住那些內容創意。我發展 Base44 的方式（可能主題不同），很大程度上是圍繞 “公開構建” 展開的 —— 擴大受眾群體，和同為創業者的他們交流，這過程其實挺順的。很多時候我都在分享 Base44 的成長曆程，而且有固定的流程：先在紙上寫下一週要發的帖子思路，畢竟得保持更新頻率，持續輸出內容。
在用到這個定製應用之前，我的流程是這樣的：先開啟 ChatGPT，寫個模糊的帖子框架，讓它 “幫忙修改潤色”。可它輸出的內容往往太偏離我的風格，太像推銷話術，語氣完全不對。我就得跟它 “較勁”：“不行，再貼近原文一點”，還要刪掉不合適的表情符號，修正奇怪的連字元。好不容易弄好 LinkedIn 帖子，還得換個工具做配圖；想發到 Twitter 上，又得精簡內容、調整表述。
後來我把這整套流程都編成了程式碼，就為了提高效率。我還特意讓應用裡的大語言模型模仿我的語氣，把我之前寫過且滿意的帖子存進去做參考，這樣它生成的下一篇內容，就能和我自己寫的風格一致了。
我非常喜歡這個領域的整體發展，不只是 Base44，很多工具都做得很好，但我特別喜歡 Base44 的一點是，它讓軟體修改變得很容易，就像一款 自適應軟體 —— 當你的流程改進或發生變化時，它能隨之調整。Base44 兩週前被 Wix 收購了，所以現在釋出內容的流程看起來有點不一樣了。但只需要兩個提示，你就能讓它適配新流程，這真的很有意思。
Shlomo：Base44 的盈利能力遠超我的預期。所以，即便沒有被收購，我感覺也能從中賺很多錢。記得一月份中旬在 ProductHunt 上的釋出非常失敗，之後到了二月初，我開始採用 “公開構建” 的模式，情況才慢慢好起來。大概從三月份開始有了第一筆收入，先是 10 美元，後來到了 100 美元。到了五月份，單月收入就接近 20 萬美元了。所以我覺得，無論如何，這個市場是有競爭空間的，雖然可能不大，但我看到那些使用 Base44 的使用者都很堅持，即便他們熟悉其他競爭對手的產品，也依然選擇 Base44。
當然，挑戰很明顯，就像那些資料類工具，它們能在百萬美元級別的駭客馬拉松之類的活動中迅速增長，而我沒有這樣的資源，所以得想別的辦法應對。但說實話，我覺得被收購的原因之一是這個市場發展太快了，比我見過的任何領域都快，也超出了我的預期。到了某個階段，當看到 Base44 的發展，我就想：“嘿，這真的能幫助人們改善生活。” 我可能不太客觀，但我覺得它屬於那種能對很多人產生重大影響的軟體類別。我看到人們用它做出了很多精彩的東西，所以我想：“我們來做個大專案吧，試著打造有全球影響力的產品，或許能引領這個領域，甚至成為佼佼者。”
我覺得實現這個目標的最佳機會是和 Wix 合作，原因有很多，但核心是我們有著相同的基因和客戶群，他們知道自己在做什麼，而且我和他們的管理團隊關係也非常好。所以說實話，我覺得這次收購無論從財務角度看都會是成功的，但它更像是一種表態：“你知道嗎？讓我們進入更廣闊的領域，不僅要在這個競爭激烈的市場中防禦，更要主動出擊。” 這也是被收購的部分原因。
Shlomo： 是的，我覺得現在情況不太一樣了。我很多次都感到害怕，心想：“我該如何參與這場競爭呢？” 那些公司，一方面是增長最快的企業之一，另一方面團隊優秀、資金充足，投入了大量資源。
但隨著時間推移，我發現自己能跟上它們的節奏，甚至更快。因為即便你是小團隊，甚至獨自一人，你實際上是在管理 AI 團隊來編寫程式碼。過去三個月裡，我幾乎沒寫過一行 HTML 或 JavaScript 程式碼，但 Base44 的前端依然有很大變化，因為這些程式碼都是人工智慧編寫的。所以，如果你有獨特的視角，並且能快速行動，我覺得資金不一定是贏得市場的決定性因素，而且未來這種情況會更加明顯。
隨著大型語言模型的進步，像那些 10 倍效率的工程師會產生更大的影響力，他們將成為 100 倍效率的工程師，因為他們能管理大型語言模型。團隊規模和資金並非決定你能否在某個領域勝出的必要因素。
Shlomo： 是的，我對此深有同感。但有意思的是，Base44 是我這輩子第一次沒有試圖打造有史以來最大的公司。我記得創辦上一家公司 Explorium 時，我一門心思就想著 “要在最短時間內籌集最多的資金”。我記得自己當時總在琢磨：“嘿，Explorium 在 Snowflake 之前就籌集到了 1 億美元，這太瘋狂了，太了不起了” 之類的。我那樣做了七年，而 Base44 是第一次，我停下來說：“你知道嗎？我只想回到我真正熱愛的事情上，也就是開發產品。” 我不在乎它能不能在這個領域勝出，也不在乎它會不會變得非常龐大。
我記得我和女友從亞洲旅行回來，在飛機上我對她說：“嘿，你知道嗎？如果我們的年度經常性收入到 2025 年底能達到 150 萬美元，我們就買輛好車。” 我不記得為什麼偏偏是這個數字了。結果我們大概四周就做到了。這是我第一次想著 “不一定要打造最大的東西，就做一些我真正喜歡的事，打造一款我享受開發過程的產品”。但到了某個時候，它變得非常非常成功，我想，一旦看到了成功，看到它對人們產生了真正積極的影響，你就會說：“好吧，那就進入更廣闊的領域，試著擴大它的規模。”
我覺得這是一個很重要的領悟：一些最棒的成果，往往來自於不給自己施加太大壓力、不試圖打造宏大的東西，而只是跟隨內心的驅動力，跟隨自己的興趣，跟隨自己的見解 —— 最好的想法、最偉大的構想，往往就由此產生。
Shlomo： 前 10 位 Base44 使用者來自熟人，我只是懇求身邊那些和我關係很好的人來使用它，我當時覺得沒有別的辦法了，但回過頭來想想也許還有其他途徑，但是，我當時才剛開始接觸 B2C，接觸消費類產品，所以經驗沒那麼多。
所以一開始我找了三個使用者，都是非常親密的朋友。其中兩個人當時正處於失業狀態。於是我就說：“你們為什麼不試試做個 SaaS 業務或者類似的東西呢？” 這三個非常親密的朋友，我讓他們每隔一天就和我一起圍坐在桌子旁，使用這個工具。他們會嘗試構建一些東西，結果工具出了故障。我就去檢視，看看日誌，回到電腦前，試著修改，推送到生產環境，然後為他們完善這個工具。
我覺得很多人很幸運，能找到一種對獲取 10 個、100 個、1000 個使用者都一直有效的方法，然後以此為基礎發展。但我更願意把這些看作一個個里程碑。
所以，首先我想：“在確認使用者喜歡這個產品之前，我不會嘗試擴大規模。” 而判斷他們是否喜歡，或者至少能否從中獲得價值（即便他們因為產品有很多漏洞、執行緩慢等問題而不太滿意）的最佳標準，是他們開始和別人分享這個產品。
所以在我覺得 “先吸引前三五個或十個朋友” 之前，我沒有在營銷上投入任何資金。到了某個時候，他們開始和朋友們分享。你會發現，今天有一個新使用者，明天新增兩個使用者，就這樣逐漸增長。所以一旦這種情況出現，即便比例很低 —— 因為 Base44 後來在發展過程中變得非常有傳播力，但在當時，它還只是一個還不錯的產品。人們喜歡它，都挺認可它，並開始分享它。
所以當我看到這個方法奏效，我們有了 10 個使用者，都是我的朋友，然後第 11 個左右的使用者開始出現一些我不認識的人時，我就知道，是時候投資營銷了，或者嘗試推出這個產品，讓更多人使用它。因為如果你提前這麼做，我覺得你會浪費很多時間和資源，就像旋轉門一樣，使用者來了又走，留不住人。除非你有大量資金投入付費推廣，這樣才有可能見效，但這會非常困難。
我知道我不會這麼做。這是我正在打造的產品，我希望它從一開始就盈利，不會因為在付費推廣等方面投入太多資金而感到懊悔。所以我知道它必須具備傳播力。不知從什麼時候起，我發現它開始有傳播的跡象了。
然後我在 ProductHunt 上做了一次非常失敗、效果很差的釋出，但現在回想起來，我覺得 “這完全沒問題”。我覺得人們有時會把產品釋出看得太重，好像產品釋出決定著公司的成敗。但對我來說不是這樣。我當時想：“這是一個能讓我獲得接下來 30 個、50 個使用者的途徑。” 事實也確實如此。第一次在 ProductHunt 上釋出時，我們獲得了 50 個使用者左右，其中我新增了大約 15 個使用者。順便說一句，第二次釋出甚至讓 ProductHunt 系統出了問題，他們以為有很多機器人在操作。那次我們贏得了當日最佳產品、當週最佳產品和當月最佳產品，但這是另一回事了。就這樣，我們有了大約 50 個使用者，也迎來了第一個付費使用者。這感覺太不可思議了，因為我是從企業領域出來的創業者。我當時心想，這太瘋狂了。為什麼會有人在沒見過我、沒和我當面交流、沒試圖討價還價的情況下就為我的產品付費呢？
顯然，這個使用者幾個小時後就流失了，因為當時的產品還不夠好。但從那以後，我開始看到一些緩慢的增長。我有了最初的 50 個使用者，之後 20 個流失了，剩下的 30 個開始把產品分享給其他非常優質的使用者。
然後我嘗試了很多營銷手段，都沒奏效，比如找網紅髮帖或者付費推廣之類的。後來，我有一個在其他領域創業的朋友告訴我：“你知道嗎？你獨自創業，還試圖採取一種與通常風投支援的方式截然不同的策略，這真的很酷。你為什麼不分享一些這方面的內容呢？說到底，你的受眾也是那些創業者，他們正努力打造自己的產品，甚至可能是自己的企業，這些內容很可能會引起他們的共鳴。”
於是我開始在 LinkedIn 上分享創業歷程，我記得看到過這樣的說法：“‘公開構建’這個概念很棒，人們對此非常感興趣。” 我覺得在 Base44 這件事上，“公開構建” 和我的受眾（也就是那些創業者）之間有很好的協同效應。如果我打造的是一款面向律師的產品，那這可能就沒多大意義了。
一旦我開始公開分享我正在構建的東西，進而獲得更多使用者，產品也得到了極大的改進，我就覺得自己非常幸運。Base44 所擁有的社群是我從未見過的，他們非常支援我，給了我很多反饋。
就像有人會在你真正實現某些功能之前就主動要求你提供這些功能，他們對產品已經非常興奮了。
我還做了另一件效果很好的事，我發現人們很喜歡分享他們在 Base44 上構建的東西，他們會寫相關的帖子。我記得有個朋友來問我：“夥計，你是不是付錢讓那些人寫關於 Base44 的帖子啊？” 我說：“說實話，我沒付錢。”
其實我在 Base44 裡編寫了一個程式，內容是：“嘿，只要你分享應用的構建過程或者應用本身，即便內容裡沒提到 Base44，只要你在社交媒體上分享，就能獲得額外的積分來繼續構建。” 所以，“公開構建” 和 “發放積分” 這兩個方法非常有效，我們就是靠這兩個方法實現增長的。
Shlomo： 中間間隔了一週，每天的使用者數達到 20。看到每天有 4000 名使用者加入產品，產品都崩潰了，很難適應這種增長速度。另外，還有一些在發展過程中需要學習的東西。比如，我以前不是 DevOps 工程師，不知道怎麼擴充套件資料庫，也不知道虛擬 CPU 在嘗試擴充套件時會給我帶來這麼多麻煩。
為了實現盈利，我嘗試利用每一個可用的免費套餐，但一旦開始擴大規模就會搞砸了。所以，我發現一旦我開始公開分享，使用者量就增長到每天幾千，然後“積分制度”就幫我完成了剩下的增長工作。
我完全理解這種觀點，但也有些不同的思考。確實，當前的創業模式正在發生轉變，特別是在產品開發理念上。我對傳統的“最小可行產品（MVP）”概念持保留態度，因為在如今軟體開發門檻大幅降低的環境下，使用者的耐心和注意力持續時間變得極其有限——如果產品體驗不夠完善，很難獲得有價值的反饋。即便使用者量達到 2 萬、5 萬甚至 10 萬時，獲取準確反饋仍然相當困難。
我的實踐方法是定期組織 20～30 人的線下焦點小組或小型駭客馬拉松活動（每兩週一次），這種方式比任何線上渠道都更高效。有趣的是，這與我們早期只有 3～5 個使用者時的開發方式如出一轍，面對面交流總能帶來最真實的洞見。
關於目標使用者定位，我認為不必過分拘泥於“理想客戶畫像（ICP）”的傳統概念，關鍵不在於使用者的人口統計特徵，而在於他們想要完成的任務——不同型別的使用者可能都在嘗試解決同一個核心問題（比如構建工具）。這種以“任務”而非“人群”為中心的思路往往能帶來更精準的產品定位，畢竟真正重要的不是“誰”在使用產品，而是他們想用產品“做什麼”。
Shlomo： 隨著收購訊息在全球範圍內持續發酵，我們在各大社交平臺都收穫了廣泛關注，但這一切的起點其實是領英。得益於之前擔任公司 CEO 時積累的人脈資源，我的聯絡人列表裡已經有一些關注者。這讓我深刻認識到，建立公眾影響力需要一個突破口——與其分散精力，不如專注在一個你認為最有效的渠道深耕。
比如在早期，即便每週發帖只能獲得零星幾個贊，這種積累也很重要。我嘗試過各種方法，甚至找過 KOL 推廣，但效果都不理想。關鍵在於找到適合自己的發聲渠道。在公開構建的過程中，我始終堅持真實分享的原則——既不像風投那樣刻意炫耀“驚人資料”，也不刻意營造“全球增長最快創業公司”的假象，而是坦誠地分享每一個技術細節和成長感悟，無論是成功的經驗還是失敗的教訓。
我的內容策略完全針對開發者群體量身定製：從最底層的技術棧解析，到大型語言模型的最佳化心得，再到直觀的資料圖表展示。這種專業性內容需要反覆打磨——就像產品迭代一樣，我會先請目標受眾中的朋友預覽內容，詢問他們的真實反饋：“這篇文章有趣嗎？有收穫嗎？能獲得什麼價值？”這種求真務實的態度，或許正是建立持久影響力的核心所在。
在社交媒體運營方面，我走過不少彎路。直到現在，我依然認為在推特上發帖對我來說是種時間浪費。當初看到領英效果不錯時，我曾天真地想把相同模式複製到推特，雖然粉絲量增加了，但實際轉化效果卻不盡如人意。
最終我選擇在領英上持續深耕，這裡給了我最高的投入產出比。每個創始人和產品的最佳渠道都不盡相同——可能是 Reddit、Substack 或其他平臺，而對我來說領英就是最有效的陣地。找到這樣的核心渠道後，我的建議是：集中火力，持續加碼，不要分散精力在那些效果不佳的渠道上。至少這是我的切身體會。
說到增長策略，我們確實走出了一條與眾不同的路。不同於傳統的 SEO、付費推廣或口碑傳播，領英成為了我們的核心增長引擎。其中最具創新性的是我們設計的激勵機制：使用者透過分享在 Base44 上創作的內容來獲取積分，這些積分可以兌換更多開發許可權。
Shlomo： 第一個員工是兩個月前入職的，也就是被收購前一個半月。所以我想，大部分時間我都是獨自運營公司。但當我開始考慮公司收購事宜時，就知道事情會朝著那個方向發展了。
而且一旦我開始推進這件事，收購的可能性就增加了，所以我僱傭了我認識的最優秀的人，因為我知道接下來的幾年甚至更長時間裡，我必須把這件事做大，身邊需要合適的人。現在不再是追求儘可能盈利和有趣那麼簡單了，我們要下更大的賭注。從那時起，我就開始招募我認識的頂尖人才來幫助我實現這個目標。
此外，關於這筆交易的結構，我無法透露太多細節，比如已經公佈的 8000 萬美元是首付款。我認為與 Wix 的這筆交易是真正的雙贏，但我的薪酬和很多福利實際上是基於未來的發展，而不是這 8000 萬美元。所以我在經濟上和個人層面都有動力去儘可能擴大它的規模。因此，在收購前一個月，我開始擴大團隊規模。而且 Base44 的盈利能力也越來越強，我有能力招募更多的人了。
Shlomo： 實際上，是一個產品方面的人才。我經常和他合作，他真是個多面手。他可以檢視大型語言模型的日誌、檢查錯誤並修復，可以編寫 Python 指令碼來分析我們做的事情，還能開始在產品中實現分析功能。他是一個技術能力很強、能身兼數職的產品人員，這正是創業初期所需要的。
Shlomo： 我用的是 Render.com 這平臺構建 Base44 的，它真的太讚了。說實話，他們可沒給我一分錢好處，真希望我當初投資了他們。我好像從來沒跟他們的高層打過交道，但用它工作起來太順暢了，直到現在依然如此。
我之前的公司有專門的 DevOps 團隊，負責搭建各種流程來推進生產部署。而 Render.com 它就像一個現成的雲服務平臺，感覺就像在 AWS 上搭建的簡化版系統，有一套特別容易管理的流程，啟動 Web 應用、擴充套件規模之類的操作都很方便。
這涉及到基礎設施、網站管理、平臺本身以及應用程式。因為 Base44 是個複雜的生態系統，必須把使用者應用程式和平臺隔離開，平臺又得和網站隔離開，是個有機的整體。
資料庫我選擇的是 MongoDB ，它在編碼方面特別好用，尤其是構建氛圍編碼平臺時，因為資料模式變化很大，而且不一定是使用者導致的。大型語言模型也不總能理解使用者想表達的內容，所以資料模式會不斷變化，選 MongoDB 真是選對了。
當然還有 Kelso，不過我花了 20% 到 30% 的時間來最佳化，讓整個程式碼庫能適配大型語言模型。順便說一句，這些理念我在 Base44 裡都實現了，但我一直在做的一件事是，儘量讓大型語言模型少寫程式碼。當你想實現一個功能時，儘量達到不需要自己寫程式碼、但大型語言模型也能少寫程式碼的狀態。因為如果讓人工智慧從頭實現整個功能，出錯或讓人困惑的地方會更多，而且當你要求它後續操作時，它需要在提示詞等內容中保留更多上下文。
所以我搭建了一個非常高階、有點 “自以為是” 的基礎設施，就像程式碼層面的基礎設施一樣，能處理所有雜事。當你構建新功能時，它會搞定所有的 CRUD 操作、身份驗證、資料庫相關的工作等等，這樣當你讓大型語言模型實現新功能時，它只需要寫很少的程式碼。
順便說一下，Base44 還給大型語言模型提供了很棒的基礎設施和 SDK。而且大型語言模型依然可以靈活地編寫完整功能的程式碼，因為本質上還是程式碼，但這樣能減少它生成的 token 數量，顯然，所有和規則集相關的事情也能搞定。
我對和大型語言模型合作有個可能有爭議的觀點：別用 TypeScript，用純 JavaScript 和 JSX，這樣模型更容易寫出正確的程式碼。Base44 的前端就是用 JSX 構建的，不是 TypeScript，這一直很奏效，部分原因是我過去只需要寫一行 HTML 或 JavaScript，它就能很好地完成任務。
和人工智慧合作時，另一個很有效的做法是，儘量讓功能都能在同一個程式碼庫中實現。就像把前端和後端分開的話，讓 AI 同時理解後端和前端的上下文會更容易。
除此之外，我的後端是用 Python 寫的。我覺得可能有人會對此挑剔，但就效能而言，我還沒遇到過問題。Base44 的訪問量很大，時不時還有人嘗試 DDoS 攻擊伺服器，但伺服器依然能正常執行。所以我覺得只要構建方式得當，Python 是門非常適合的語言。
另一個可能有意思的點是，很多新應用和產品都是圍繞大型語言模型構建的。我採用的方法之一是，對於實際用 Base44 編寫程式碼的大型語言模型，我會針對不同任務混合使用不同的模型。比如，Claude 在初始提示、從頭編寫應用程式方面表現很好，處理 UI 設計相關的工作也很出色。不過像 Gemini，當遇到非常複雜的問題，或者需要設計算法，又或者 Claude 陷入程式碼 bug 迴圈（寫程式碼時經常出現這種情況）時，它就派上用場了。所以我搭建了一個流程，先分析使用者的需求，再決定用哪個大型語言模型，這方法一直很有效。
Shlomo： 是在 Base44 裡實現的。我覺得 Cursor 沒有這個功能，真希望他們能加上，我覺得應該有個自動選項。但在 Base44 裡，當用戶提問時，我會先分析他們的需求，再確定用哪個大型語言模型。
Shlomo： 是的。所有這些工具，Base44、Kelso，還有其他合適的編碼工具，我都用同樣的模式 —— 不知道該不該叫方法 —— 就是配備 “重型武器”，通常是 Claude 或 Gemini。這兩個模型通常會先建立一個高階解決方案或高階檔案，明確要對檔案做哪些修改，而不是每次都從頭寫整個檔案。Kelso 和 Base44 都是這麼做的：先寫高層次的程式碼塊，然後用更小、更快的模型，比如 Flash 或 OpenAI 的 o4-mini，來實現檔案中的程式碼修補。
參考連結：
https://www.youtube.com/watch?v=L9KvV_UOs3A
宣告：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。
2025 年被稱為“AI Agent 元年”，Agent 真的能落地商業化了嗎？拆解難點、協作挑戰、企業落地 KPI……騰訊雲、彩訊股份、商湯科技三位專家深度對話！
今日薦文
你也「在看」嗎？👇
