AI 創(chuàng)業(yè)是一門生意。

在 day one 就要思考如何實現(xiàn)盈利、如何控制成本、支出的問題，尤其是小團(tuán)隊創(chuàng)業(yè)。

獨立開發(fā)者 Arvid?Kahl 是個「精打細(xì)算」創(chuàng)業(yè)的范例。

在高價賣出自己的在線教育產(chǎn)品 FeedbackPanda 之后，Arvid?Kahl 做了一款 AI 播客產(chǎn)品，想做成播客界的 Google Alerts，為品牌方和公司提供關(guān)鍵詞監(jiān)測。

Podscan 每天需要抓取、下載并自動轉(zhuǎn)錄五萬集的新播客，Arvid?Kahl 將每月的開支硬生生從三萬美元壓到了不到一萬美元。

Arvid?Kahl 在一期播客節(jié)目中，詳細(xì)地分享了他如何從零到一構(gòu)建 Podscan，以及他的「節(jié)儉工程」經(jīng)驗，包括：通過選擇小眾云服務(wù)商來壓縮 GPU 成本、如何低成本提升硬件效率、通過關(guān)鍵詞觸發(fā)策略來控制 AI 調(diào)用成本。以及在 Podscan 短暫地實現(xiàn)了 2 個月的盈利后，如何調(diào)整產(chǎn)品、銷售策略等。

對于小團(tuán)隊創(chuàng)業(yè)者來說，這是一份很具體、實在的經(jīng)驗分享。

超 12000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01怎么收錄全球近 400 萬播客，求助開源

主持人：Podscan 的創(chuàng)業(yè)來源是？

Arvid Kahl：「Building in Public」是我過去五六年里非常重要的一部分。我從 14 歲接觸電腦就開始編程，一直想做出自己的產(chǎn)品，后來也確實實現(xiàn)了盈利，于是就開始了自己的創(chuàng)業(yè)路。

Feedback Panda 是我在 2019 年出售的一個項目，當(dāng)時它運營了兩年。這次成功的退出讓我在創(chuàng)業(yè)圈獲得了更多的關(guān)注。從那以后，我開始一邊做軟件，一邊做內(nèi)容媒體——博客、YouTube、播客，并且全程公開我的歷程。因為我發(fā)現(xiàn)，從他人真實的挑戰(zhàn)與解決方案中能學(xué)到最多，所以我也想回饋同樣的價值。

Podscan 就是思考之后的產(chǎn)物。起初，我只是想為自己的播客業(yè)務(wù)開發(fā)一個讓聽眾可以發(fā)送語音留言的小工具。產(chǎn)品做出來了，卻發(fā)現(xiàn)市場不大。我就思考，如何找到那些有同樣需求的播客主呢？我想到，像 Twitter 和 Facebook 都有社交監(jiān)控工具，類似于「谷歌快訊」，可以追蹤品牌或名字，但播客領(lǐng)域似乎一片空白。我自己的工具就需要這樣的功能。

我意識到，這不應(yīng)該只是一個營銷小功能，它本身就是一個生意，幫助企業(yè)和個人發(fā)現(xiàn)，在全世界的播客中，誰在談?wù)撍麄兊钠放?、產(chǎn)品或任何他們關(guān)心的話題。這就是 Podscan 的起點。一年半前，我將這個想法付諸實踐，現(xiàn)在我們每天掃描數(shù)萬個播客節(jié)目，進(jìn)行轉(zhuǎn)錄和分析。這個過程充滿了挑戰(zhàn)和起伏，我很享受公開分享這段旅程，并感謝一路上社區(qū)給予的幫助。

主持人：Podscan 每天是如何處理整個播客世界的？我看你的網(wǎng)站上寫著每天新增約 3.5 萬集節(jié)目，你們會把每一集都抓取、轉(zhuǎn)錄，并提供搜索和提醒功能。

Arvid Kahl：是的，這是這個 SaaS 業(yè)務(wù)最特別的一點：我的運營規(guī)模與客戶數(shù)量幾乎無關(guān)。大多數(shù)軟件的負(fù)載隨用戶增長而增加，但對我而言，無論有 10 個還是 10 萬個客戶，只要他們想監(jiān)控全球播客，我需要處理的數(shù)據(jù)體量基本是固定的。

當(dāng)然，技術(shù)上仍有擴(kuò)展空間，但主要負(fù)載來自于每天新增的播客數(shù)量。這個數(shù)字相對穩(wěn)定：工作日約三萬五千集，周一能達(dá)到五萬，周末則較少。全球約有 380 萬檔播客，聽起來很多，但真正持續(xù)活躍的只是一部分。

要處理這些數(shù)據(jù)，首先要搭建一套解析 RSS 的基礎(chǔ)設(shè)施。播客生態(tài)建立在開放標(biāo)準(zhǔn)之上，每個播客都有一個 RSS 訂閱源。即使節(jié)目托管在 Spotify 或 Apple Podcast 這樣的封閉平臺，其源頭依然有托管商保存著原始文件，我們就從那里抓取 MP3。我有一個 GPU 服務(wù)器集群專門負(fù)責(zé)轉(zhuǎn)錄，稍后我們可以深入細(xì)節(jié)。

整個系統(tǒng)就是這樣運轉(zhuǎn)的：幾十臺服務(wù)器 7x24 小時工作，獲取 URL 并下載音頻——這個過程需要應(yīng)對各種反爬蟲和封禁策略。接著，我們按語言進(jìn)行轉(zhuǎn)錄，生成帶時間軸的字幕文件（SRT 格式），甚至精確到每個詞的毫秒級時間戳。同時，音頻中的海量元數(shù)據(jù)也會被提取并存入數(shù)據(jù)庫。最后，一個 AI 系統(tǒng)會識別出主持人、嘉賓、贊助商和核心議題，因為這些才是我的客戶——公關(guān)公司、營銷機(jī)構(gòu)等最關(guān)心的信息。他們需要即時了解誰在播客里談?wù)摿怂麄兊钠放?、老板或產(chǎn)品。

主持人：你是如何找到「所有這些內(nèi)容」的？有幾大托管服務(wù)商直接提供給你一份清單嗎？還是你有其他方法來聚合這近 400 萬檔播客的源頭？

Arvid Kahl：這個秘密其實是公開信息，用搜索引擎或 AI 都能找到答案。

項目剛啟動時，并沒有現(xiàn)成的解決方案。我動手時 AI 浪潮才剛剛開始，很多工具都還不成熟。我面臨的最大問題就是：這些播客的 RSS 源到底在哪？于是我求助于開源世界，找到了 Podcast Index 項目。這是一個由社區(qū)維護(hù)的全球播客數(shù)據(jù)庫，它還與一個叫 Podping 的技術(shù)相關(guān)聯(lián)。你可以將 Podping 理解為一個發(fā)布/訂閱系統(tǒng)——當(dāng)播客更新時，它會廣播一個通知，訂閱方（如播放器或我們的服務(wù)器）就能立即收到并抓取新內(nèi)容。

Podcast Index 不僅提供 API，更棒的是，他們每周會發(fā)布一個約 4GB 大小的 SQLite 數(shù)據(jù)庫文件，里面包含了全球幾乎所有播客的 RSS 源。只要你能搭建處理它的基礎(chǔ)設(shè)施，就能瞬間擁有近 400 萬條播客訂閱源。

主持人：所以你每隔一段時間就會把這 400 萬條訂閱源全部掃描一遍？

Arvid Kahl：這背后有一套神奇的架構(gòu)。Podping 已經(jīng)被主流播客托管商廣泛采用，比如 Transistor 和 Acast。這意味著大部分播客更新時都會主動通知我。對于剩下的那部分，我在 AWS 和 Hetzner（作為德國人，我當(dāng)然青睞德國服務(wù)商，而且我的 GPU 服務(wù)器也全在那里，這是控制成本的關(guān)鍵）上部署了幾臺服務(wù)器進(jìn)行補(bǔ)充掃描。這些機(jī)器會錯峰運行，每天至少對所有訂閱源進(jìn)行一輪全面檢查，對熱門節(jié)目則會將頻率提高到每 4-6 小時一次。為了避免海量請求對托管商造成 DDoS 攻擊，我深入研究了 ETag、Cache-Control 等 HTTP 緩存機(jī)制。如果服務(wù)器返回「304 Not Modified」，我就能跳過一次完整的 RSS 文件下載。我必須在保證實時性和尊重生態(tài)系統(tǒng)之間找到平衡。

主持人：這套策略是自己摸索出來的，還是與業(yè)內(nèi)人士交流的結(jié)果？比如你和 Transistor 的Justin或其他人聊過嗎？

Arvid Kahl：當(dāng)然。我和 Justin、Overcast 的 Marco Arment 等許多獨立圈的創(chuàng)始人都聊過。但因為這一切都基于開源標(biāo)準(zhǔn)，文檔非常完善，比如 Podcasting 2.0 標(biāo)準(zhǔn)就詳細(xì)說明了該如何操作。

在我剛開始大規(guī)模下載文件時，一家大公司的技術(shù)人員注意到了我。因為我在 User-Agent 中注明了「Podscan」，他們覺得這個機(jī)器人很「懂禮貌」，于是主動聯(lián)系我，并提供了一些內(nèi)部資料，指導(dǎo)我如何更高效地抓取，以便他們能在營銷報告中將我的下載行為排除，確保廣告播放數(shù)據(jù)更準(zhǔn)確。整個過程中，我收到的都是善意的建議，從未有人讓我「停止」，而是告訴我「我們是這樣做的」。這就是開放標(biāo)準(zhǔn)的魅力所在：社區(qū)天然樂于分享。

02用 H100 做轉(zhuǎn)錄是浪費，小眾云服務(wù)更便宜

主持人：在轉(zhuǎn)錄方面，OpenAI 的 Whisper 模型雖然強(qiáng)大，但通過API大規(guī)模使用的成本非常高。你提到你自建了GPU集群，詳細(xì)介紹一下這套流程。

Arvid Kahl：故事要從更早的那個「語音留言」小項目說起，它同樣需要轉(zhuǎn)錄功能。用戶留下二三十秒的語音，我需要將其轉(zhuǎn)為文字，方便播主預(yù)覽和使用。當(dāng)時大概是 2018 到 2021 年之間，我開始研究這個。

主持人：那時候 ChatGPT 還沒出現(xiàn)吧？

Arvid Kahl：對，ChatGPT 還沒誕生，但 Whisper 已經(jīng)有了。

Whisper 不僅能在 GPU 上運行，通過 whisper.cpp 這樣的工具，量化后的中小模型也能在 CPU 上運行。我當(dāng)時在我的 MacBook 上測試，效果令我驚訝。對于后臺異步處理的場景，CPU 完全夠用。這就是我最早接觸轉(zhuǎn)錄的經(jīng)歷。

當(dāng)開始做 Podscan 時，我必須依靠 GPU 來支撐規(guī)模。Whisper 的模型有多種尺寸，尺寸越大，準(zhǔn)確率越高，但速度越慢。大號模型比超小號慢 24 倍，處理一小時音頻，時間可能從幾秒到超過 15 分鐘不等。項目初期我沒有融資，所以我必須搭建一套「節(jié)儉」的基礎(chǔ)設(shè)施。有很長一段時間，我甚至用我的 M1 Max Studio 和一臺閑置的 Mac mini 來 24x7 運行轉(zhuǎn)錄任務(wù)。

當(dāng)本地算力達(dá)到瓶頸，我開始尋找云服務(wù)。AWS 的 GPU 實例價格過高，我轉(zhuǎn)向了 Lambda Labs 這類更小眾的云服務(wù)商。我用 Laravel 搭建后臺，通過 SSH 部署二進(jìn)制程序進(jìn)行轉(zhuǎn)錄，再通過 API 回調(diào)結(jié)果。這套架構(gòu)雖然簡單，但行之有效。目前，我使用的核心工具是 Whisper CTranslate 2，還有其他如 WhisperX 等多個版本。

主持人：為什么最終選擇了 CTranslate 2？

Arvid Kahl：因為我需要「說話人分離」（Diarization）功能，也就是識別出對話中不同的發(fā)言者（如「發(fā)言人 1」、「發(fā)言人 2」）。這項工作的計算量堪比轉(zhuǎn)錄本身，甚至更大。它需要分析整個音頻的波形，對不同人的聲音進(jìn)行聚類和切分。許多純粹的 Whisper 分支并不具備此功能，因為大部分用戶只關(guān)心文字內(nèi)容。

CTranslate 2 本身是一個機(jī)器翻譯工具，但它集成了 Whisper 和一個名為 PyAnnote 的說話人分離庫（他補(bǔ)充說，可以讀作「pi-an-note」）。我當(dāng)時在 Twitter 上公開討論這個方案，PyAnnote 的作者看到后還主動聯(lián)系我，我們進(jìn)行了一次愉快的交流。這個工具組合滿足了我的需求。

主持人：說話人分離和轉(zhuǎn)錄是一次性完成，還是分兩步進(jìn)行？

Arvid Kahl：實際上是反過來的：系統(tǒng)先進(jìn)行說話人分離，將音頻切分成不同發(fā)言人的片段，然后再將這些片段與轉(zhuǎn)錄出的文字進(jìn)行對齊和時間戳標(biāo)記。從工具調(diào)用上看是一次操作，但其內(nèi)部是一個多步驟的流水線。

主持人：從處理短語音到處理長達(dá)數(shù)小時的播客，文件大小對轉(zhuǎn)錄質(zhì)量有影響嗎？

Arvid Kahl：文件大小本身影響不大，關(guān)鍵在于同一 GPU 上的并行任務(wù)數(shù)量。為了最大化效率，我曾在 Hetzner 的高性價比 GPU 服務(wù)器上做過大量實驗，發(fā)現(xiàn)當(dāng)并行任務(wù)超過 4 個時，音頻后半段（約 30-40 分鐘后）的轉(zhuǎn)錄質(zhì)量會明顯下降。我推測這與顯存管理或 CUDA 的上下文切換有關(guān)，因此我將并發(fā)數(shù)嚴(yán)格控制在 4 以內(nèi)以保證質(zhì)量。

我還得出了一個重要的結(jié)論：用高端 GPU（如 H100）處理轉(zhuǎn)錄任務(wù)是極大的資源浪費。無論是并行運行 1 條還是 20 條 Whisper-large 模型，總吞吐量幾乎沒有提升，似乎受到了某種內(nèi)部總線的限制。因此，我很快停掉了每月 1200 美元的 H100 租賃，換成了 4 臺成本更低的整機(jī)，反而獲得了更強(qiáng)的綜合性能。

主持人：你每天轉(zhuǎn)錄這么多音頻，會按播客熱度排優(yōu)先級嗎？

Arvid Kahl：當(dāng)然。我內(nèi)部建立了一套基于 Redis 的多隊列系統(tǒng)，分為高、中、低三個優(yōu)先級，并設(shè)有一個「立即處理」的緊急通道，以確?？蛻舻木o急需求能得到最快響應(yīng)。

主持人：這個緊急處理是如何觸發(fā)的呢？是客戶直接聯(lián)系你，還是他們在后臺點擊某個按鈕？

Arvid Kahl：觸發(fā)方式是多樣的，核心是基于一套我稱之為「內(nèi)部信號」的系統(tǒng)。判斷一個節(jié)目是否「熱門」相對簡單，通過抓取評論數(shù)或排行榜即可。但判斷它是否「有用」則復(fù)雜得多，因為對我的客戶有用和對大眾有用是兩套標(biāo)準(zhǔn)。

我在 Podscan 中設(shè)計了二十多種信號來評估內(nèi)容的價值。例如，當(dāng)一位付費客戶設(shè)定的關(guān)鍵詞在某期播客中被提及，該播客的優(yōu)先級會自動提升為「中」。如果這位客戶還點擊查看了這條提及的轉(zhuǎn)錄內(nèi)容，并停留了超過 30 秒，我就會將其優(yōu)先級直接提升至「高」。通過持續(xù)收集用戶搜索、點擊、收藏等行為數(shù)據(jù)，我為每一檔播客動態(tài)地賦予了內(nèi)部權(quán)重。

03不是所有文本都需要 AI 處理，怎么省錢怎么來

主持人：在轉(zhuǎn)錄過程中，你會為AI提供上下文嗎？比如提示「這是一檔科技播客」？

Arvid Kahl：我非常希望可以，但目前很難有效實現(xiàn)，最大的痛點在于品牌名的準(zhǔn)確識別。像 Spectrum 這種通用詞匯，或是 Feedly、Zapier 這種自創(chuàng)詞，模型極易轉(zhuǎn)錄錯誤。一旦出錯，我就需要為錯誤的詞條也設(shè)置提醒，這會帶來很多麻煩。

Whisper 模型雖然支持在 prompt 中提供一個「詞匯表」，但前提是你必須預(yù)知這些詞會出現(xiàn)在音頻中。我曾嘗試提供一個包含上千個詞的通用列表，結(jié)果導(dǎo)致模型過度匹配，在不該出現(xiàn)的地方也強(qiáng)行識別。所以我目前的策略是，只提供「節(jié)目標(biāo)題、播客名和嘉賓名」作為最輕量的上下文。至于更深層次的語義提示，例如「這是一期科技播客，請注意技術(shù)術(shù)語」，目前還無法實現(xiàn)。

主持人：你會將原始轉(zhuǎn)錄稿再交給大模型進(jìn)行二次潤色嗎？還是轉(zhuǎn)錄后就直接進(jìn)入搜索系統(tǒng)？

Arvid Kahl：基本不會。我計算過，如果將每天新增的約 5 萬集有效播客全文交給 GPT-4o mini 或類似模型處理，成本會非常高，一天可能就要燒掉 1 萬美元。因此，我只在關(guān)鍵詞被觸發(fā)時才調(diào)用 LLM。用戶可以在提醒設(shè)置中增加一個「上下文感知」條件，例如「如果提到我的品牌，再用 AI 判斷這期節(jié)目是否超過三位嘉賓？」，LLM 只需返回「是」或「否」的一兩個 token，成本極低。這也是 Podscan 最受歡迎的功能之一，它實現(xiàn)了智能過濾，而不是暴力分析。

主持人：實時提醒功能，人們可以輸入關(guān)鍵詞，然后收到提醒。這是怎么跑的？是每隔幾分鐘跑一個定時任務(wù)掃描所有新播客嗎？

Arvid Kahl：它的觸發(fā)是事件驅(qū)動的。當(dāng)系統(tǒng)通過 Podping 等方式收到新節(jié)目的通知后，會將其加入內(nèi)部處理隊列。轉(zhuǎn)錄系統(tǒng)完成轉(zhuǎn)錄和數(shù)據(jù)分析（調(diào)用 OpenAI 等模型獲取結(jié)構(gòu)化數(shù)據(jù)）后，會觸發(fā)下一步流程。

這個流程就是遍歷系統(tǒng)里所有的提醒規(guī)則——目前大約有 3000 條。我們會逐條檢查轉(zhuǎn)錄稿中是否包含用戶設(shè)定的關(guān)鍵詞。如果匹配成功，還會根據(jù)設(shè)置執(zhí)行一個可選的「上下文感知」判斷（再次調(diào)用 API），最終決定是否發(fā)送通知。整個過程是實時的。

主持人：每次有新轉(zhuǎn)錄稿，你就把所有提醒規(guī)則都跑一遍？

Arvid Kahl：每次有新的轉(zhuǎn)錄稿，我們就把所有提醒規(guī)則都跑一遍，直接掃描。

主持人：負(fù)載大嗎？

Arvid Kahl：負(fù)載很小。因為這只是一個純文本掃描過程，我甚至沒有使用正則表達(dá)式，就是最基礎(chǔ)的字符串查找。

主持人：我本來想的是用 Elasticsearch 對最新文檔做查詢。但既然你直接對文檔操作，那就是在進(jìn)程里跑。

Arvid Kahl：是的，我將完整的轉(zhuǎn)錄稿加載進(jìn)來，然后逐行掃描關(guān)鍵詞是否存在。未來，我們可能會采用更語義化的方法，比如將文本向量化并進(jìn)行嵌入（Embeddings）相似度比對，但目前還沒到那一步。現(xiàn)階段還是基于關(guān)鍵詞觸發(fā)。

主持人：你有考慮過像 Whisper 那樣，在本地運行大語言模型嗎？

Arvid Kahl：我已經(jīng)這么做了，它們是我的備用方案。當(dāng) OpenAI 的 API 出現(xiàn)故障時，我會在服務(wù)器上運行 Llama 3.1 7B 模型作為兜底。但本地運行會拖慢轉(zhuǎn)錄速度，所以這并非首選。對于簡單的上下文過濾，本地模型可以，但對于復(fù)雜的數(shù)據(jù)提取，效果不如 OpenAI 的模型。

主持人：當(dāng)你想到一個新功能，你會回頭重新處理舊節(jié)目嗎？還是說「只對新內(nèi)容生效」？畢竟，回頭處理 3500 萬集節(jié)目的成本可不小。

Arvid Kahl：作為一個節(jié)儉的創(chuàng)業(yè)者，服務(wù)于一群只關(guān)心「當(dāng)下」的客戶，答案其實很明顯：我回優(yōu)先保證當(dāng)前和近期內(nèi)容的價值。我確實提供了一個 API，讓用戶可以請求重新處理特定的舊節(jié)目。我的策略是，當(dāng) Podscan 盈利能力足夠強(qiáng)時，我會投入更多資源回溯處理歷史數(shù)據(jù)。目前，只要轉(zhuǎn)錄隊列有空閑，我就會去處理更早的內(nèi)容。

04TB 級別的數(shù)據(jù)，

OpenSearch 比 MeiliSearch 好用

主持人：聊聊搜索，處理 3400 萬條播客轉(zhuǎn)錄稿，這已經(jīng)是一個嚴(yán)肅的搜索工程問題了。你目前的技術(shù)方案是什么？我記得你最初使用的是 MeiliSearch？

Arvid Kahl：是的。項目初期，我選擇了 Laravel 框架，并集成了它生態(tài)中的 MeiliSearch。MeiliSearch 對于短文本的實時搜索表現(xiàn)很好，響應(yīng)極快。但隨著數(shù)據(jù)量激增至近 4TB（索引約 350GB），它的數(shù)據(jù)攝取速度成了瓶頸。我曾經(jīng)和 MeiliSearch 的創(chuàng)始人深入交流過，他們甚至為我定制了新版本，但我發(fā)現(xiàn)，為了支持更復(fù)雜的布爾查詢和通配符搜索，我必須遷移。

主持人：遷移到 OpenSearch 的過程順利嗎？

Arvid Kahl：整個過程非常有挑戰(zhàn)性，可以說是我過去幾個月里最艱巨的任務(wù)之一。處理數(shù)百萬條、接近 4TB 的數(shù)據(jù)本身就很困難，更復(fù)雜的是，在遷移前還需要進(jìn)行數(shù)據(jù)的「豐富化處理」。所以我不能直接從 MySQL 導(dǎo)出，而是要先關(guān)聯(lián)其他表的信息（例如，通過外鍵查詢播客名稱），然后才能發(fā)送到搜索數(shù)據(jù)庫。

為了保證線上服務(wù)的連續(xù)性，我設(shè)計了一個并行遷移方案：在后臺持續(xù)地將數(shù)據(jù)遷移至 OpenSearch，而 OpenSearch 在數(shù)據(jù)攝取方面的表現(xiàn)確實不錯，快速且穩(wěn)定。

主持人：把 4TB 數(shù)據(jù)遷移到 OpenSearch 花了多久？

Arvid Kahl：由于遷移涉及大量的數(shù)據(jù)轉(zhuǎn)換和關(guān)聯(lián)查詢，比如，我們有一個巨大的表記錄著全球所有播客的歷史排行榜數(shù)據(jù)，整個后臺遷移過程持續(xù)了整整 14 天。

我編寫了一個可重啟、可跳過失敗項的遷移腳本，讓它在一個獨立的 Shell 進(jìn)程中持續(xù)運行。為了確保平穩(wěn)過渡，我還搭建了一套混合系統(tǒng)：先將新搜索作為一項可選功能上線，允許部分用戶切換使用。這讓我能夠觀察新舊搜索系統(tǒng)的返回結(jié)果是否一致，并及時發(fā)現(xiàn)潛在問題。在確認(rèn)一切穩(wěn)定后，我才將流量完全切換到新系統(tǒng)。當(dāng)切換完成且沒有任何問題發(fā)生時，那是我作為開發(fā)者最欣慰的時刻之一。這次遷移雖然難，但很值。

主持人：OpenSearch 基礎(chǔ)設(shè)施的成本與 Hetzner 的GPU成本相比如何？

Arvid Kahl：OpenSearch 的生產(chǎn)環(huán)境我現(xiàn)在每月付 700 美元。數(shù)據(jù)量大概 500GB，配置是按 500GB 買的，現(xiàn)在實際用了 350GB。隨著數(shù)據(jù)增長，費用也會漲。這么說吧，它比我那臺「主要搜索」服務(wù)器貴一倍——那臺服務(wù)器，不開玩笑，64 核、350GB 內(nèi)存，我每月只花 300 美元。

主持人：所以你運行的是你自己的 MeiliSearch？

Arvid Kahl：是的，我確實這么做了，那個詞崩了好幾次，挺有意思的。但唯一的問題是數(shù)據(jù)攝取的速度，他們的攝取隊列漲到了 100 萬個對象，然后整個系統(tǒng)就卡死了。所以我得寫個退避邏輯，去查詢服務(wù)器的隊列，統(tǒng)計隊列里的條目數(shù)，然后根據(jù)結(jié)果決定要不要繼續(xù)發(fā)新數(shù)據(jù)。我當(dāng)時就想：我不想管這些破事，AWS 能不能直接幫我搞定？顯然 OpenSearch 能扛住我的流量，所以效果還不錯。不過那臺舊服務(wù)器現(xiàn)在還在為某些查詢服務(wù)。

主持人：是的，Elasticsearch 是我最不想自己維護(hù)的東西之一。處理海量數(shù)據(jù)的全文搜索和聚合，這類問題本身就很難。

Arvid Kahl：我不是第一次處理搜索問題了。搜索本身就是個難題，尤其是 Elasticsearch，而 OpenSearch 和它基本是同一種東西。

主持人：畢竟 OpenSearch 就是 Elasticsearch 的分叉。

Arvid Kahl：它們在概念上差異很小，我基本把它們看作一回事。作為開發(fā)者，我一直不喜歡它的 DSL（領(lǐng)域特定語言），它的查詢語法很難理解。你知道是什么幫了我嗎？是 AI。

那些非常復(fù)雜的復(fù)合查詢，我一行代碼都沒有親自寫。我雖然用了像 Laravel OpenSearch 這樣的庫，但有時仍然需要編寫原生查詢。這些原生查詢的代碼，全部是由 Junie（JetBrains 的編碼助手）生成的。Copilot 和其他工具也幫了很大忙。我根本寫不出來，也不需要寫。我只需要用自然語言告訴它：「我需要提升某個詞的權(quán)重，并進(jìn)行布爾查詢」，它就能生成代碼。這就是我現(xiàn)在的工作方式。

主持人：確實很有意思。

Arvid Kahl：是的，我現(xiàn)在會用一個叫 Whisper Flow 的工具。按下快捷鍵后，它能捕捉我說的每一句話，轉(zhuǎn)錄并快速潤色，然后直接粘貼到任何文本輸入框里，無論是 Twitter 還是我的 IDE。我甚至能用它來口述代碼。我實際上是在腦子里構(gòu)思，然后說出來，把任務(wù)交給 Junie 或其他 AI 工具。十分鐘后再回來看結(jié)果。Podscan 的大部分功能，都是在過去一年里用這種方式構(gòu)建的。

05寫代碼是一項管理工作，不是實現(xiàn)工作

主持人：你也用 Claude Code 或類似的終端工具嗎？

Arvid Kahl：我一開始用的是 Claude Code，但后來發(fā)現(xiàn)了 Junie。Junie 基本就是 Claude Code 的復(fù)刻版。它集成在 PhpStorm 側(cè)邊，本質(zhì)上就是一個帶一點美化界面的終端。所以我整天都在用它。我現(xiàn)在幾乎不怎么手打代碼了。

主持人：代碼層面，你幾乎不敲鍵盤了？

Arvid Kahl：也不是完全不敲。我當(dāng)然還是會做一些修改，比如刪掉一行代碼，或者添加一條日志語句。當(dāng)我發(fā)現(xiàn) AI 生成的代碼風(fēng)格和我的習(xí)慣不符時，我也會重構(gòu)它。有時所謂的「重構(gòu)」，也只是寫一句注釋，告訴 AI 「把它改成那樣」，然后讓它執(zhí)行。

所以對我來說，現(xiàn)在寫代碼更像是一項管理工作，而不是實現(xiàn)工作。很多技術(shù)型創(chuàng)始人不喜歡這一點，因為他們享受編碼本身帶來的創(chuàng)造感。我有時也懷念那種感覺。但是，AI 帶來的開發(fā)速度提升是顯著的，比如這次的搜索引擎遷移，如果沒有 AI，我可能要花幾個月才能完成，而且結(jié)果還不一定對。

主持人：是的，雖然感覺少了點什么，但看著功能快速實現(xiàn)，尤其是在做 UI 時，那種創(chuàng)造速度也是一種樂趣。

Arvid Kahl：它也能用來做原型。你可以直接告訴它：「給我創(chuàng)建一個這個頁面的新視圖。」它會生成一個版本。你可能需要反復(fù)糾正幾次才能得到想要的結(jié)果，但即便如此，15 分鐘內(nèi)你就能得到一個完全重構(gòu)的前端。喜歡就提交，不喜歡就回滾，非常簡單。

對我來說，現(xiàn)在寫代碼就是提示詞工程 （Prompt Engineering）。某種意義上，我們一直都是這么做的：先寫一份需求文檔，描述產(chǎn)品的功能，然后再去實現(xiàn)?，F(xiàn)在，我們只需要寫好這份「文檔」，讓機(jī)器去實現(xiàn)，而它往往做得比我更好。我把自己看作一個「0.8 倍的開發(fā)者」——不是 10 倍，也不是 1 倍，而是善于使用工具的 0.8 倍。

主持人：除了 Junie 和 Whisper Flow，你還用別的工具嗎？比如用 v0 做視覺設(shè)計？

Arvid Kahl：最近我發(fā)現(xiàn)了 v0、Lovable 這類工具的一個很好的用法。它們可以幫助你向潛在客戶展示產(chǎn)品集成的效果。前幾天，在和一家數(shù)據(jù)分析公司交流后，我把我們的對話錄音轉(zhuǎn)錄稿交給了 Claude，讓它生成一個用于 Lovable 的 prompt，來制作一個集成方案的原型。Lovable 生成頁面后，我花了一個小時進(jìn)行微調(diào)。第二天早上，我就把一個可交互的演示鏈接發(fā)給了對方，完整地展示了我們的數(shù)據(jù)如何嵌入他們的系統(tǒng)。這就是銷售賦能 （Sales Enablement）。

主持人：這太酷了。我的設(shè)計能力很差，所以即使用 v0 幫我開拓思路，看看不同設(shè)計方案，也對我?guī)椭艽蟆?/strong>

Arvid Kahl：對，我也經(jīng)常用它來統(tǒng)一設(shè)計風(fēng)格。比如，Junie 可以訪問我項目里所有的前端視圖文件。我可以直接對它說：「找出那些風(fēng)格不一致的文件，并統(tǒng)一它們?！顾娴哪茏龅?。這些工具能理解留白、順序、層級這些我自己并不擅長的設(shè)計概念。用 AI 寫代碼，不只是讓它實現(xiàn)你已知的邏輯，更是讓它幫你探索和落地那些你可能從未想過的點子。

主持人：你的上一個成功項目 Feedback Panda 用的是 Elixir，這次 Podscan 為什么選擇了 PHP 和 Laravel？是出于什么考慮更換了技術(shù)棧？

Arvid Kahl：這個技術(shù)棧其實算是被動選擇的，因為當(dāng)時我就是一名 Elixir 開發(fā)者。在做 Feedback Panda 時，我的正職工作是在一個物聯(lián)網(wǎng)平臺用 Elixir 寫代碼。這個技術(shù)選型是當(dāng)時公司的 CTO 決定的，他認(rèn)為物聯(lián)網(wǎng)業(yè)務(wù)需要極高的并發(fā)處理能力，所以選擇了基于 Erlang VM 的 Elixir。我當(dāng)時熟悉的就是這套技術(shù)，所以就順手用來開發(fā)了 Feedback Panda。后來我出售公司后的第一個 SaaS 項目 Permanent Link 也是用它。

但我現(xiàn)在希望當(dāng)初用的是 PHP，因為在 AI 時代，PHP 的可維護(hù)性要好得多。AI 系統(tǒng)是在 Stack Overflow 上海量的 PHP 問答數(shù)據(jù)上訓(xùn)練出來的，因此對 PHP 的理解很到位。相比之下，Elixir 用戶較少，招聘和維護(hù)都更困難。

后來我開始做 PodLined（那個語音聊天項目）時，選擇了 Laravel。因為在獨立開發(fā)者的圈子里，Laravel 的熱度越來越高。大家都在說 PHP 重新崛起了，Taylor Otwell 和他的團(tuán)隊打造了一個了不起的生態(tài)系統(tǒng)——不僅框架本身優(yōu)秀，更重要的是它背后那個對創(chuàng)始人非常友好的社區(qū)和商業(yè)生態(tài)。這在其他語言社區(qū)里是很少見的。Elixir 社區(qū)非常技術(shù)化、純粹，而 PHP 則更加務(wù)實。我選擇 Laravel 最初是想一探究竟，結(jié)果發(fā)現(xiàn)產(chǎn)品開發(fā)過程非?？焖俸晚樌谑蔷蜎Q定繼續(xù)使用它了。

主持人：那么你認(rèn)為，AI的普及是否會減緩編程語言和框架等領(lǐng)域的創(chuàng)新速度？

Arvid Kahl：我會用兩個答案來回答。

直接的答案是：是的，我認(rèn)為會的。這就像「林迪效應(yīng)」（Lindy effect），存在越久的技術(shù)，就越有可能繼續(xù)存在下去。新技術(shù)的資料進(jìn)入大語言模型的門檻更高，而模型的輸出又會反過來影響生態(tài)，因此舊的技術(shù)會更具優(yōu)勢。

但我有一個更宏大的理論：在未來 10 到 20 年，我們看待具體編程語言的方式，會像今天看待不同的二進(jìn)制實現(xiàn)一樣。我們可能不再關(guān)心代碼最終被編譯成什么。我們用來與 AI 溝通的將是一種新的「元語言」?，F(xiàn)在我們?yōu)榫幾g器寫代碼，未來我們可能只需用這種元語言描述邏輯，然后由 AI 選擇最合適的底層語言（如 JavaScript 或 Rust）去實現(xiàn)。到那時，具體用哪種編程語言將不再那么重要。

主持人：你覺得會出現(xiàn)你說的那種元語言，還是直接就用英語？

Arvid Kahl：從目前的發(fā)展趨勢判斷，它極有可能演變?yōu)橛⒄Z的一種方言。但我認(rèn)為這中間會有一個過渡階段，具體是什么形態(tài)我還不確定。也許會像 Markdown，但用于表達(dá)邏輯而非格式；又或者，就是人們對著語音提示說半小時話——這種接口看起來已經(jīng)相當(dāng)有效了。

06短暫盈利 2 個月，決定 PLG 轉(zhuǎn)向 SLG

這部分內(nèi)容轉(zhuǎn)載自作者官網(wǎng)，講述了他在產(chǎn)品收入下降后進(jìn)行的產(chǎn)品策略調(diào)整。

Podscan 實現(xiàn)了盈利。它確實盈利了——但只持續(xù)了兩個月。

當(dāng)我的一個主要客戶因為一個完全超出我控制范圍的原因而流失時，盈利能力很快就被蒙上了陰影。這讓我重新跌回了盈利線以下，并且考慮到目前的開支狀況，我仍在努力重返盈利。

因此，我覺得這是一個絕佳的機(jī)會，來分享我作為一名創(chuàng)業(yè)者此刻的真實想法——我目前有哪些選擇，我正面臨哪些挑戰(zhàn)，以及我和那些支持我、為我提供建議的人們在這種情況下是如何制定戰(zhàn)略和計劃的。

殘酷的數(shù)字現(xiàn)實

讓我完全透明地說明 Podscan 目前的狀況。我們每月的開支大約是 10,000 美元，而月度經(jīng)常性收入 （monthly recurring revenue） 約在 6,000 美元左右。因此，我們每月還差 4,000 美元才能收支平衡。

所以我現(xiàn)在所處的境地——曾經(jīng)盈利過，如今卻不再盈利——確實糟透了。但這也說明了一個事實：盈利并非遙不可及，它只是需要付出一些努力。

但有一件事一直困擾著我：在一年半之后，盈利能力仍然是我在追逐的目標(biāo)，而不是我可以穩(wěn)定依賴的東西。而且，我必須現(xiàn)實地看待一個事實：直到現(xiàn)在，我所做的一切還不足以讓這項業(yè)務(wù)進(jìn)入自我維持的狀態(tài)。我需要做出重大的改變才能達(dá)成目標(biāo)。 我從投資人、自力更生的創(chuàng)業(yè)者以及同行那里得到的很多反饋，都是讓我現(xiàn)實地審視這項業(yè)務(wù)——看看產(chǎn)品與市場是否匹配，判斷它是否可行，還是說我只是在追逐一個以企業(yè)現(xiàn)狀和團(tuán)隊當(dāng)前能力根本無法實現(xiàn)的目標(biāo)。然后據(jù)此做出調(diào)整。

戰(zhàn)略轉(zhuǎn)向：從 PLG 到 SLG

我必須克服「這是一個產(chǎn)品主導(dǎo)增長型業(yè)務(wù)」的預(yù)期。我一直以為，僅靠產(chǎn)品本身，加上我的博客和社交媒體影響力，就足以讓人們發(fā)現(xiàn)產(chǎn)品、使用產(chǎn)品、訂閱，并借此實現(xiàn)盈利。

在某種程度上，我算是走了一半的路，對吧？我已經(jīng)取得了相當(dāng)大的進(jìn)展，但我還沒有完全到達(dá)終點。即使我的營收達(dá)到了 10,000 美元，那也只是一個凈值為零的業(yè)務(wù)——收入和支出持平。有些東西需要改變。

我下定了決心。我找到了一個很棒的人，幫助我建立銷售渠道 （sales pipeline） 和客戶觸達(dá)系統(tǒng)——安排產(chǎn)品演示、與我們 ideal customer profile（理想客戶畫像）中的人進(jìn)行對話、將成功案例推到前臺、進(jìn)行真正的銷售對話。

這些都是我以前從未做過、從未做好過、也從未需要做過的事情。但現(xiàn)在，它們是我關(guān)注的重點，因為我必須讓這個項目實現(xiàn)盈利。

調(diào)整定價

我還大幅調(diào)整了定價結(jié)構(gòu)?，F(xiàn)在最貴的套餐真正反映了提供服務(wù)的實際成本。過去，最高檔套餐是每月 500 美元，如今這成了第二檔；最高檔已升至每月 2500 美元，幾乎可獲取你需要的任何數(shù)據(jù)。

它在某些方面可能仍然定價偏低，但這個價位只要我能找到愿意付費的客戶，他們很快就能彌補(bǔ)我們財務(wù)缺口中的很大一部分。

考慮到 API 訪問的需求以及用戶所需的數(shù)據(jù)類型，再加上我們已經(jīng)明確了一個理想客戶畫像——預(yù)算并不是主要顧慮，因為我們所瞄準(zhǔn)的代理商本身就擁有高預(yù)算的客戶——這樣的定價是可行的，也一定會奏效。

我已經(jīng)找到了愿意從一開始就購買較小檔位、即 500 美元檔位的人，因為他們的預(yù)算允許，并且擴(kuò)展預(yù)算也已經(jīng)到位。

在這種銷售方式中，我發(fā)現(xiàn)直接觸達(dá)并與各個代理機(jī)構(gòu)和客戶建立關(guān)系——幫助他們完成上線，幫助他們找到所需示例數(shù)據(jù)來說服公司里的利益相關(guān)者和決策者啟動訂閱——是一種非常精準(zhǔn)的方法。

這是一種高接觸的方式，與我此前一直堅持的產(chǎn)品主導(dǎo)增長策略相去甚遠(yuǎn)。但這就是我現(xiàn)在的必經(jīng)之路。我的跑道已經(jīng)所剩無幾，如果這條跑道無法支撐當(dāng)前的業(yè)務(wù)形態(tài)，那么就必須做出改變。

設(shè)定決策時間表

作為創(chuàng)始人，我必須思考一個問題：當(dāng)事情發(fā)生時會發(fā)生什么——或者說，如果事情發(fā)生時會發(fā)生什么？

顯然，理想的路徑是在幾個月內(nèi)建立起這種銷售外聯(lián)方法，獲取足夠的月度經(jīng)常性收入來支付所有開支，然后逐步或快速增加收入，以維持一個銷售團(tuán)隊和幾名技術(shù)人員。減輕我的負(fù)擔(dān)，構(gòu)建更安全、更可靠、更易于維護(hù)的基礎(chǔ)設(shè)施。

但那是理想情況。在我與其他創(chuàng)始人的所有交流中，有一個經(jīng)常被提及、而直到現(xiàn)在我都沒怎么認(rèn)真想過的問題是：要是行不通怎么辦？

我正在努力讓自己接受這一點：Podscan 無論多么出色的創(chuàng)意、對現(xiàn)有客戶多么有用，（至少以我目前的方式運營）可能都不足以達(dá)到超盈利業(yè)務(wù)的規(guī)?；蚍秶?。

當(dāng)然，也可以選擇直接關(guān)掉，這是最無趣的做法。但還有其他選擇。

我打算給自己幾個月時間。我知道我們正在搭建的銷售管道需要一段時間才能升溫并產(chǎn)生結(jié)果。為了實現(xiàn)盈利，我們實際上只需要每月再增加 4000 到 5000 美元的經(jīng)常性收入。我們的總收入已經(jīng)超過了這個數(shù)字——我們只需要找到更多真正愿意為此付費的人。

因此，我現(xiàn)在正在為自己和團(tuán)隊設(shè)定一個幾個月的期限，向所有相關(guān)人員說明當(dāng)前狀況，然后抓住每一個機(jī)會去實現(xiàn)這個目標(biāo)。尋找與我們現(xiàn)有客戶類似的高價值客戶，主動聯(lián)系他們，向他們展示產(chǎn)品能做什么，做到具體、在場、建立關(guān)系，并將這些關(guān)系轉(zhuǎn)化為能夠支撐業(yè)務(wù)的客戶關(guān)系。

這有點像一次恐懼設(shè)置練習(xí)，讓我明白這是一場賭博。這是一次創(chuàng)業(yè)冒險。它可能以多種方式收場——巨大成功、徹底失敗，或介于兩者之間的任何結(jié)果。

既然我有權(quán)決定自己想投入多少精力、把目標(biāo)放在哪些選項上，我選擇給它一些時間，讓它仍有潛力成為那個可能實現(xiàn)的巨大成功。與此同時，我也會為自己和團(tuán)隊不斷發(fā)現(xiàn)這條商業(yè)道路還能以其他方式延續(xù)的機(jī)會。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker