AI 創業是一門生意。

在 day one 就要思考如何實現盈利、如何控制成本、支出的問題，尤其是小團隊創業。

獨立開發者 Arvid?Kahl 是個“精打細算”創業的范例。

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

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

Arvid?Kahl 在一期播客節目中，詳細地分享了他如何從零到一構建 Podscan，以及他的“節儉工程”經驗，包括：通過選擇小眾云服務商來壓縮 GPU 成本、如何低成本提升硬件效率、通過關鍵詞觸發策略來控制 AI 調用成本。以及在 Podscan 短暫地實現了 2 個月的盈利后，如何調整產品、銷售策略等。

對于小團隊創業者來說，這是一份很具體、實在的經驗分享。

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

主持人： Podscan 的創業來源是？

Arvid Kahl： “Building in Public”是我過去五六年里非常重要的一部分。我從 14 歲接觸電腦就開始編程，一直想做出自己的產品，后來也確實實現了盈利，于是就開始了自己的創業路。

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

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

我意識到，這不應該只是一個營銷小功能，它本身就是一個生意，幫助企業和個人發現，在全世界的播客中，誰在談論他們的品牌、產品或任何他們關心的話題。這就是 Podscan 的起點。一年半前，我將這個想法付諸實踐，現在我們每天掃描數萬個播客節目，進行轉錄和分析。這個過程充滿了挑戰和起伏，我很享受公開分享這段旅程，并感謝一路上社區給予的幫助。

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

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

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

要處理這些數據，首先要搭建一套解析 RSS 的基礎設施。播客生態建立在開放標準之上，每個播客都有一個 RSS 訂閱源。即使節目托管在 Spotify 或 Apple Podcast 這樣的封閉平臺，其源頭依然有托管商保存著原始文件，我們就從那里抓取 MP3。我有一個 GPU 服務器集群專門負責轉錄，稍后我們可以深入細節。

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

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

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

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

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

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

Arvid Kahl： 這背后有一套神奇的架構。Podping 已經被主流播客托管商廣泛采用，比如 Transistor 和 Acast。這意味著大部分播客更新時都會主動通知我。對于剩下的那部分，我在 AWS 和 Hetzner （作為德國人，我當然青睞德國服務商，而且我的 GPU 服務器也全在那里，這是控制成本的關鍵） 上部署了幾臺服務器進行補充掃描。

這些機器會錯峰運行，每天至少對所有訂閱源進行一輪全面檢查，對熱門節目則會將頻率提高到每 4-6 小時一次。為了避免海量請求對托管商造成 DDoS 攻擊，我深入研究了 ETag、Cache-Control 等 HTTP 緩存機制。如果服務器返回“304 Not Modified”，我就能跳過一次完整的 RSS 文件下載。我必須在保證實時性和尊重生態系統之間找到平衡。

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

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

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

二、用H100做轉錄是浪費，小眾云服務更便宜

主持人： 在轉錄方面，OpenAI 的 Whisper 模型雖然強大，但通過?API?大規模使用的成本非常高。你提到你自建了?GPU?集群，詳細介紹一下這套流程。

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

主持人： 那時候 ChatGPT 還沒出現吧？

Arvid Kahl： 對，ChatGPT 還沒誕生，但 Whisper 已經有了。

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

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

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

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

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

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

主持人： 說話人分離和轉錄是一次性完成，還是分兩步進行？

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

主持人： 從處理短語音到處理長達數小時的播客，文件大小對轉錄質量有影響嗎？

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

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

主持人： 你每天轉錄這么多音頻，會按播客熱度排優先級嗎？

Arvid Kahl： 當然。我內部建立了一套基于 Redis 的多隊列系統，分為高、中、低三個優先級，并設有一個“立即處理”的緊急通道，以確保客戶的緊急需求能得到最快響應。

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

Arvid Kahl： 觸發方式是多樣的，核心是基于一套我稱之為“內部信號”的系統。判斷一個節目是否“熱門”相對簡單，通過抓取評論數或排行榜即可。但判斷它是否“有用”則復雜得多，因為對我的客戶有用和對大眾有用是兩套標準。

我在 Podscan 中設計了二十多種信號來評估內容的價值。例如，當一位付費客戶設定的關鍵詞在某期播客中被提及，該播客的優先級會自動提升為“中”。如果這位客戶還點擊查看了這條提及的轉錄內容，并停留了超過 30 秒，我就會將其優先級直接提升至“高”。通過持續收集用戶搜索、點擊、收藏等行為數據，我為每一檔播客動態地賦予了內部權重。

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

主持人： 在轉錄過程中，你會為?AI?提供上下文嗎？比如提示“這是一檔科技播客”？

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

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

主持人： 你會將原始轉錄稿再交給大模型進行二次潤色嗎？還是轉錄后就直接進入搜索系統？

Arvid Kahl： 基本不會。我計算過，如果將每天新增的約 5 萬集有效播客全文交給 GPT-4o mini 或類似模型處理，成本會非常高，一天可能就要燒掉 1 萬美元。因此，我只在關鍵詞被觸發時才調用 LLM。

用戶可以在提醒設置中增加一個“上下文感知”條件，例如“如果提到我的品牌，再用 AI 判斷這期節目是否超過三位嘉賓？”，LLM 只需返回“是”或“否”的一兩個 token，成本極低。這也是 Podscan 最受歡迎的功能之一，它實現了智能過濾，而不是暴力分析。

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

Arvid Kahl： 它的觸發是事件驅動的。當系統通過 Podping 等方式收到新節目的通知后，會將其加入內部處理隊列。轉錄系統完成轉錄和數據分析 （調用 OpenAI 等模型獲取結構化數據） 后，會觸發下一步流程。

這個流程就是遍歷系統里所有的提醒規則——目前大約有 3000 條。我們會逐條檢查轉錄稿中是否包含用戶設定的關鍵詞。如果匹配成功，還會根據設置執行一個可選的“上下文感知”判斷 （再次調用 API） ，最終決定是否發送通知。整個過程是實時的。

主持人： 每次有新轉錄稿，你就把所有提醒規則都跑一遍？

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

主持人： 負載大嗎？

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

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

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

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

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

主持人： 當你想到一個新功能，你會回頭重新處理舊節目嗎？還是說“只對新內容生效”？畢竟，回頭處理 3500 萬集節目的成本可不小。

Arvid Kahl： 作為一個節儉的創業者，服務于一群只關心“當下”的客戶，答案其實很明顯：我回優先保證當前和近期內容的價值。我確實提供了一個 API，讓用戶可以請求重新處理特定的舊節目。我的策略是，當 Podscan 盈利能力足夠強時，我會投入更多資源回溯處理歷史數據。目前，只要轉錄隊列有空閑，我就會去處理更早的內容。

四、TB 級別的數據，OpenSearch 比 MeiliSearch 好用

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

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

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

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

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

主持人： 把 4TB 數據遷移到 OpenSearch 花了多久？

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

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

主持人： OpenSearch 基礎設施的成本與 Hetzner 的?GPU?成本相比如何？

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

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

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

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

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

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

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

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

主持人： 確實很有意思。

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

五、寫代碼是一項管理工作，不是實現工作

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

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

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

Arvid Kahl： 也不是完全不敲。我當然還是會做一些修改，比如刪掉一行代碼，或者添加一條日志語句。當我發現 AI 生成的代碼風格和我的習慣不符時，我也會重構它。有時所謂的“重構”，也只是寫一句注釋，告訴 AI “把它改成那樣”，然后讓它執行。

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

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

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

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

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

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

主持人： 這太酷了。我的設計能力很差，所以即使用 v0 幫我開拓思路，看看不同設計方案，也對我幫助很大。

Arvid Kahl： 對，我也經常用它來統一設計風格。比如，Junie 可以訪問我項目里所有的前端視圖文件。我可以直接對它說：“找出那些風格不一致的文件，并統一它們。”它真的能做到。這些工具能理解留白、順序、層級這些我自己并不擅長的設計概念。用 AI 寫代碼，不只是讓它實現你已知的邏輯，更是讓它幫你探索和落地那些你可能從未想過的點子。

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

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

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

后來我開始做 PodLined （那個語音聊天項目） 時，選擇了 Laravel。因為在獨立開發者的圈子里，Laravel 的熱度越來越高。大家都在說 PHP 重新崛起了，Taylor Otwell 和他的團隊打造了一個了不起的生態系統——不僅框架本身優秀，更重要的是它背后那個對創始人非常友好的社區和商業生態。這在其他語言社區里是很少見的。Elixir 社區非常技術化、純粹，而 PHP 則更加務實。我選擇 Laravel 最初是想一探究竟，結果發現產品開發過程非常快速和順利，于是就決定繼續使用它了。

主持人： 那么你認為，AI?的普及是否會減緩編程語言和框架等領域的創新速度？

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

直接的答案是：是的，我認為會的。這就像“林迪效應” （Lindy effect） ，存在越久的技術，就越有可能繼續存在下去。新技術的資料進入大語言模型的門檻更高，而模型的輸出又會反過來影響生態，因此舊的技術會更具優勢。

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

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

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

六、短暫盈利 2 個月，決定 PLG 轉向 SLG

Podscan 實現了盈利。它確實盈利了——但只持續了兩個月。

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

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

殘酷的數字現實

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

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

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

戰略轉向：從 PLG 到 SLG

我必須克服“這是一個產品主導增長型業務”的預期。我一直以為，僅靠產品本身，加上我的博客和社交媒體影響力，就足以讓人們發現產品、使用產品、訂閱，并借此實現盈利。

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

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

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

調整定價

我還大幅調整了定價結構。現在最貴的套餐真正反映了提供服務的實際成本。過去，最高檔套餐是每月 500 美元，如今這成了第二檔；最高檔已升至每月 2500 美元，幾乎可獲取你需要的任何數據。

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

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

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

在這種銷售方式中，我發現直接觸達并與各個代理機構和客戶建立關系——幫助他們完成上線，幫助他們找到所需示例數據來說服公司里的利益相關者和決策者啟動訂閱——是一種非常精準的方法。

這是一種高接觸的方式，與我此前一直堅持的產品主導增長策略相去甚遠。但這就是我現在的必經之路。我的跑道已經所剩無幾，如果這條跑道無法支撐當前的業務形態，那么就必須做出改變。

設定決策時間表

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

顯然，理想的路徑是在幾個月內建立起這種銷售外聯方法，獲取足夠的月度經常性收入來支付所有開支，然后逐步或快速增加收入，以維持一個銷售團隊和幾名技術人員。減輕我的負擔，構建更安全、更可靠、更易于維護的基礎設施。

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

我正在努力讓自己接受這一點：Podscan 無論多么出色的創意、對現有客戶多么有用， （至少以我目前的方式運營） 可能都不足以達到超盈利業務的規模或范圍。

當然，也可以選擇直接關掉，這是最無趣的做法。但還有其他選擇。

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

因此，我現在正在為自己和團隊設定一個幾個月的期限，向所有相關人員說明當前狀況，然后抓住每一個機會去實現這個目標。尋找與我們現有客戶類似的高價值客戶，主動聯系他們，向他們展示產品能做什么，做到具體、在場、建立關系，并將這些關系轉化為能夠支撐業務的客戶關系。

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

既然我有權決定自己想投入多少精力、把目標放在哪些選項上，我選擇給它一些時間，讓它仍有潛力成為那個可能實現的巨大成功。與此同時，我也會為自己和團隊不斷發現這條商業道路還能以其他方式延續的機會。 （這部分內容轉載自作者官網，講述了他在產品收入下降后進行的產品策略調整）

本文來自微信公眾號： Founder Park ，編譯：Founder?Park