从 0 到 1 做一款 AI 产品：技术怎么搭、成本如何控制、销售策略怎么定？

推荐语

AI创业如何精打细算？独立开发者Arvid Kahl分享从0到1打造Podscan的实战经验，教你控制成本、优化销售策略。

核心内容：
1. 从播客监控需求发现到产品定位的思考过程
2. 通过小众云服务商和智能调度将月成本从3万降至1万美元
3. 盈利模式探索与销售策略调整的关键转折点

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

AI 创业是一门生意。

在 day one 就要思考如何实现盈利、如何控制成本、支出的问题，尤其是小团队创业。

独立开发者 Arvid Kahl 是个「精打细算」创业的范例。

在高价卖出自己的在线教育产品 FeedbackPanda 之后，Arvid Kahl 做了一款 AI 播客产品，想做成播客界的 Google Alerts，为品牌方和公司提供关键词监测。

Podscan 每天需要抓取、下载并自动转录五万集的新播客，Arvid Kahl 将每月的开支硬生生从三万美元压到了不到一万美元。

Arvid Kahl 在一期播客节目中，详细地分享了他如何从零到一构建 Podscan，以及他的「节俭工程」经验，包括：通过选择小众云服务商来压缩 GPU 成本、如何低成本提升硬件效率、通过关键词触发策略来控制 AI 调用成本。以及在 Podscan 短暂地实现了 2 个月的盈利后，如何调整产品、销售策略等。

对于小团队创业者来说，这是一份很具体、实在的经验分享。

超 12000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

• 最新、最值得关注的 AI 新品资讯； 
  

• 不定期赠送热门新品的邀请码、会员码；
  

• 最精准的AI产品曝光渠道

01 

怎么收录全球近 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」，他们觉得这个机器人很「懂礼貌」，于是主动联系我，并提供了一些内部资料，指导我如何更高效地抓取，以便他们能在营销报告中将我的下载行为排除，确保广告播放数据更准确。整个过程中，我收到的都是善意的建议，从未有人让我「停止」，而是告诉我「我们是这样做的」。这就是开放标准的魅力所在：社区天然乐于分享。

02 

用 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 秒，我就会将其优先级直接提升至「高」。通过持续收集用户搜索、点击、收藏等行为数据，我为每一档播客动态地赋予了内部权重。

03 

不是所有文本都需要 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 盈利能力足够强时，我会投入更多资源回溯处理历史数据。目前，只要转录队列有空闲，我就会去处理更早的内容。

04 

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 的大部分功能，都是在过去一年里用这种方式构建的。

05 

写代码是一项管理工作，

不是实现工作

主持人：你也用 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，但用于表达逻辑而非格式；又或者，就是人们对着语音提示说半小时话——这种接口看起来已经相当有效了。

06 

短暂盈利 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 美元的经常性收入。我们的总收入已经超过了这个数字——我们只需要找到更多真正愿意为此付费的人。

因此，我现在正在为自己和团队设定一个几个月的期限，向所有相关人员说明当前状况，然后抓住每一个机会去实现这个目标。寻找与我们现有客户类似的高价值客户，主动联系他们，向他们展示产品能做什么，做到具体、在场、建立关系，并将这些关系转化为能够支撑业务的客户关系。

这有点像一次恐惧设置练习，让我明白这是一场赌博。这是一次创业冒险。它可能以多种方式收场——巨大成功、彻底失败，或介于两者之间的任何结果。

既然我有权决定自己想投入多少精力、把目标放在哪些选项上，我选择给它一些时间，让它仍有潜力成为那个可能实现的巨大成功。与此同时，我也会为自己和团队不断发现这条商业道路还能以其他方式延续的机会。