AI播客知识管理应用Podwise的ARR年收入突破了12000美元，作为一款聚焦播客文本转录、提取和总结分析的AI应用，Podwise聚焦在硬核播客赛道，同时与Notion、Obsidian、Logseq和Readwise等平台的打通，嵌入用户的知识管理工作流。
本文为Podwise团队对产品从灵感到变现过程的忠实记录以及复盘，可以说，从0到1的复盘超级详细！从宣传、技术路线、AIModel选择、到付费方式及价格制定等都有提及。
还会坚持干的几件事
00
我们写这篇小册子主要是为了记录Podwise构建的完整经过，我们尽量忠实记录。虽说成功不可复制，但我们会尽量还原当时选择的依据以及事后的结果，所以这更像是一个复盘故事，而不是成功教科书。
Podwise专为播客听友设计的AI知识管理应用。在Podwise平台，只需follow你喜欢的播客，比如「纵横四海」，当有节目发布后，Podwise会通过AI对播客内容进行转录、提取、总结、分析等一系列操作，帮你掰开了揉碎了硬核的播客知识。同时与Notion、Readwise等平台的打通，嵌入你的知识管理工作流，协同在其他渠道的包括新闻，Newsletter，Blog等内容，帮你完善第二大脑。
在经历了10年企业服务创业的洗礼后，我们决定从toB的生意中跳脱出来。也是因为机缘巧合的关系，有幸拜读了Gumroad创始人SahilLavingia的书TheMinimalistEntrepreneur（中文版译名《小而美》），让我们觉得，做独立开发者似乎也是一条不错的路。
在经历几个月的Gap之后，我们以播客的形式开始重新切入市场，制作了一款针对IndieHacker的播客「硬地骇客」，名字取自IndieHacker的中文音译，「硬地」也充分表达了独立开发本身的难度极高。
当然为什么制作「硬地骇客」，与这两年互联网、科技行业所面临的业绩下滑和裁员的大环境也有很大的关系，我们预计IndieHackers群体会因为这些因素大幅增加。再叠加AI产业爆发，尤其是ChatGPT对于开发者群体效率的大幅加成，好像让这件事更成为了一种趋势。我们的目标很简单，希望在这波大潮中，让独立开发者变成生意人，不再用爱发电。当然也包括我们自己。
所以「硬地骇客」播客的成长其实是伴随着我们团队LearninPublic一起的，在经过三个月的播客节目中，我们制作了几期爆款内容：
01
从社区出发
所以我们团队脑暴了一个点子库：
这些需求是怎么被发掘的？我们发现在即刻和小红书经常会有人发播客笔记，因为播客是音频产品，无法搜索和快速通览，在这些平台就出现了很多课代表，其实课代表就是代总结，代提炼的过程，而这个提炼的结果中尤其受欢迎的内容就是脑图。那么既然有这么多人工课代表，那我们AI课代表一定有需求，只是我们到底能达到人工的几成而已。另外我们还发现，大部分发布总结的人群都为女性高知用户，可能女性用户对于知识的整理有天然的冲动，而这样的人群画像的购买力也是最强的。
当然也许现在也算是证明了我们当时的判断，但回看的话主要还是要归功于运气。
这里面还有一个小插曲，为什么AI播客产品的名字最后取名叫Podwise。
在选定产品方向之后，我们做了一次市场调研。根据eMarketer和PodcastIndex的数据,2024年全球播客市场的听众人数已经超过5亿人，但并不是说播客听众都会是Podwise的用户，因为播客的核心功能还是陪伴，而当前市面上大部分的播客也都是主打陪伴属性的，Podwise所服务的硬核知识类的播客主要集中在创业、投资、商业、历史和健康等类目。
我们假设全球5亿的播客受众有10%左右的重度用户，而这10%的重度用户中又有10%会喜欢收听「硬核知识」播客，那就是500万左右的受众。那么Podwise只要能够转化1%左右的核心用户，就可以拿到5万个订阅用户，按年算ARR也有350万美金左右的市场，按毛利60%计算市场回报也超过200万美金。当然，上面所有的假设都是最保守的数字，对我们来说，粗算下来这是一个能支撑小团队的市场规模，那我们就可以干。
我们回过头来看看播客市场的供给，根据PodcastIndex的数据，当前还在活跃的播客有400万以上。
而平均一个人收听播客的时长为6-7小时，所以大量的播客其实是无法被用户收听到的。同时我们也注意到一个现象，像JoeRogan、Huberman、LexFridman等头部播客的时长越来越长，动辄3-4个小时。所以注定有海量的播客内容其实是无法被广泛消费的。那么在400万活跃播客和每人最多6-7小时的收听时长之间就存在一个巨大的供给与消费的鸿沟，所以这里存在机会。而Podwise为这种鸿沟提供了解决方案，就是加速消费播客内容。当然方式也不止这一种，在这种情况下，在供给端，播客主理人们也会想尽办法来让自己的内容更多的触达给用户，那这里面一定也存在机会。
经过这番调研，我们认为这个市场规模是足够支撑我们团队发展的，并且这个规模可能还是独立开发者们选择市场的一个甜蜜点。再小的话不足以养活一个团队，大一些的话将来一定会面临巨头的竞争，因为我们缺乏团队和技术的优势，所以有极大可能在竞争中落败。
产品目标确定之后，我们优先需要确认用户故事。即我们需要给有听播客、记笔记需求的用户，设计一个路径，能够让他们达成目标。
在这里我们使用了一个User-StoryMapping的图表，它是敏捷团队在长期规划用户故事中所创造出来的一个工具，能够帮助我们更好思考用户的使用路径。工具使用起来非常简单，它把用户的行为划分为三个层级，即：活动、步骤和细节，它们三者是依次拆解的关系。即通过活动来拆解具体的步骤，再根据每个步骤来确认细节。当然工具只是辅助我们进行思考的工具，核心还是业务，用户到底是如何使用产品的？
通知之后用户进入平台看到AI处理的内容，包括总结、大纲、脑图、金句等，当然最重要的是逐字稿，这个是所有内容能产出的基石。在AI产出笔记之后，用户可以选择将AI笔记推送至自己的笔记本中，比如Notion和Readwise等。这样就完成了一次完整的用户旅程。后续用户可以通过订阅Podcast的形式，即时收到新的节目中已处理的笔记。但这属于优化体验了，我们上面描述的这个过程是一个用户要完成AI处理播客的必经之路，不能缺乏其中任何一项。
大家可以发现，我们在思考用户活动的时候用的都是必备路径，而不是事无巨细的全量路径。那是因为，我们不可能在一开始就想清楚产品的全貌，好产品都是与用户磨合出来的。而我们在产品初期，最重要的事情就是快速交付MVP(Minimumviableproduct)最简可行产品，因为在这时候，所有的东西都是我们脑子构建出来的，没有任何用户参与。所以我们需要尽快让用户能够参与进来，来帮助我们验证产品是否真的可行。而构建MVP的核心，则需要我们高度提炼用户故事的必备路径，这里有张经典的MVP图：
另外如果是工具类的产品，比较忌讳的就是一上来就大而全。大而全的产品本质上还是没找到产品的卖点，大而全就是最偷懒的做法，海外用户不喜欢大而全。
如果你在用户故事精简过后，在第一个MVP中没有找到太多产品亮点，那么可能要思考一下这个产品是否值得做，产品在市场上到底有什么差异性？没有差异性就很难让用户产生记忆点，而记忆点就没有品牌，最终就很容易被遗忘。所以模仿并不是一个好的方法，可以借鉴但不要抄袭。品牌本身是有先发优势的。
最后由于我们的目标客户是听播客人群的细分，所以我们在产品形态上选择了用网站的形态来做。而并没有选择很多AI产品通过做浏览器插件的形式，我们觉得这有些违背笔记的使用习惯。并且因为在前期做了一些市场调研，我们的竞品因为只有手机客户端，所以也有用户抱怨的声音存在，这也是我们选择从网站开始的原因之一。
02
设计与开发一体
设计开发一体。
对于独立开发者或小团队，设计和开发一体是比较高效的方式。这并不只是说由同一个人来负责设计和前端开发工作，而是直接将设计和开发工作一次性完成。得益于现代的开发过程和工具，直接编写Web代码并预览效果的效率并不低。哪怕是对能熟练使用Figma等设计工具的开发者来说，直接编码并预览的效率也会高于先进行设计再编码实现的方式。也许在进行一些微小调整时，反复的修改代码并预览并不如在设计工具中直接修改来的直观高效。但实际上当设计完成的时候，我们的开发动作也同时完成了。0.6（设计）+0.6（开发）>1（设计开发一体），很简单的道理。
与我个人而言，我会选择可以快速调整（例如TailwindCSS）并实时预览（可以hotreload）的技术栈。同时我会使用两个显示器，或左右分屏来提高这个阶段修改->预览->再修改的效率。
如何设计功能性界面？
对于产品的功能性界面，我们需要着重设计的是布局和流程，而非视觉效果。原本视觉效果就不是我们擅长的领域，因此我们完全可以将视觉效果交给UI组件库来确保下限。前面提到过的shadcn/ui、radix-uithemes和NextUI都是非常优秀的带样式的组件库。这些组件库已经基本涵盖了大部分交互形式，我们只需要将它们组合起来。因此留给我们的主要工作就是设计布局和流程了。
设计布局和流程其实是PD的工作，而PD最重要的就是去理解用户。因此我们的策略就是将自己作为忠实用户，去从目标用户的角度思考这个产品怎么用起来才是最方便的。我会尝试举几个例子来说明。
如何设计LandingPage？
相比功能界面，landingpage会是更难以设计的部分。Landingpage的主要目的是将产品能力和优势展示清楚。于此同时，一个设计炫酷的landingpage对产品传播和使用转化会带来很大的帮助。因此，相较功能界面重在交互体验，视觉样式绝大部分由组件库完成的情况不同，landingpage需要我们自己来完成视觉样式的设计。
在缺乏专业设计能力和设计经验的情况下独立完成landingpage的设计不是一件现实的事情。但我们可以选择多观摩并借鉴别人的设计，拿来和自己的想法进行组合改良。
除了在平时留意好看的网站设计之外，有不少在线的资源可以帮助我们。
用Keynote/PowerPoint设计营销图片。
产品的视觉和交互设计可以适用设计开发一体的方式，使用开发者更熟悉的方式，也就是写代码来进行设计。但用作营销的图片就没办法用这种方式了。
先说最终选型结果，只列比较关键的。
虽然在选型过程中也有一些feature上的考量，但最核心的原则还是：选择擅长且方便的。
Web前后端为什么选择JS/TS技术栈？
我们团队比较熟悉的技术栈是JavaScript/TypeScript、Golang、Java、Ruby、Rust。对于开发Web应用来说，显然使用JS/TS全栈一站式搞定是最快捷方便的。尽管Java、Golang包括Rust在性能方面相对Node会更有优势，但对于大部分开销都在数据库和网络I/O上的Web后端来说并没有多大意义。另外Web前后端开发由同一个人承担，那使用同样的技术栈肯定也会更加方便。所以Web前后端就决定使用JS/TS技术栈。
为什么选择TS而非开发速度更快的JS？
JS在一人工作以及POC阶段效率确实很高，但当工程开始变得复杂且经过长期迭代之后，TS会更具优势。当工程已经颇具规模之后再切换到TS会是一个很痛苦的过程。我一般仅在知道工程规模会长期保持轻量的时候选择使用JS。
为什么选择NextJS作为Webframework？
前后端同构在一人开发时效率很高。举例来说，所有接口的出入参类型你都只需要定义一份，而无需在两种不同技术栈下分开定义。当你需要修改接口时，同一份类型也可以确保你同时修改两边而不会发生遗漏。
Astro本身定位自己是用来做「content-drivenwebsites」，内容驱动网站，也就是说像营销站点、文档站点、blog、landingpage这种场景。对于功能比较复杂的应用网站，Astro官方也并不推荐使用Astro来构建。
Remix看起来是一个不错的选择，但它的action将一个页面的所有请求混合在一起的写法让我有点不太能接受，而当时NextJS的ServerAction看起来会更加吸引人。
纯后端服务为什么选择Golang技术栈？
我们根据自己的积累、经验和能力，选择了最保险的方案。我们也极力推荐大家采用这一准则进行编程语言的选择。但你并不一定完全需要遵照这一准则。有很多的领域或者产品类型，你甚至可能需要靠其他的指标和维度来做选择，比如你正在构建的是需要高性能的infra产品，那你有可能会选择像Rust，C/C++这类编程语言，哪怕你并不是很擅长它们。
2.资源
Go比Python可以消耗更少的资源。如果你有「白嫖」过AWS的免费EC2，你会发现这些免费的ec2只有1vCPU和1G内存。cpu其实还好，毕竟作为独立开者新发布的产品，可能也没多少人使用，也没什么流量；但1g的内存极有可能会是一个硬伤，1g内存被操作系统占用后，剩下给到你的也就是只有几百兆了，这远低于我们今天使用的笔记本电脑，像python、java这类带虚拟机的编程语言，一启动就可以占用上百M、甚至几百M的内存，所以1g的「白嫖」ec2总体来说是捉襟见肘的。
Go语言在这方面的表现就是非常优秀了，轻松把内存稳定控制在几十M内，只要我愿意做，控制在十几M也不是不可以。
资源就是成本，是钱。作为独立开发者或startup，我们可以不在意编程语言的性能，但不能忽视资源消耗的多少问题。特别是刚起步的时候，能够让你的产品轻松的部署在任意环境，节省每一分钱都是有意义的。
3.部署运维
Go程序具有极大的可部署运维性。除Go以外，其他的所有主流编程语言的程序或多或少都需要解决部署环境的依赖问题，当然在docker出现以后，这个问题明显减少了。
我们需要CI/CD吗？作为刚起步的独立开发者和startup，我可以负责任的说「你不需要CI/CD，更不需要DevOps，你只需要方便和快捷」，不要害怕自己是草台班子。方便快捷的「实现代码，跑完测试，部署发布」，这一切都可以在你的笔记本电脑上完成，这是最快，最方便的方式，超过了任何CI/CD。
4.并发
Go具有比Python强大得多的并发能力，这种强大的并发能力不只是「cpu上的效率」，还体现在"语言级别原生支持goroutine的语法表达能力"。这就是编程体验和性能都双双兼得。
并发为什么重要？Podwise后台服务有太多的地方需要并发处理：
AI模型已经足够慢了，好的并发流程设计可以避免产品陷入"更慢"的窘境。所以，值得我们使用更好的并发语言。
5.开发效率和性能平衡
选择Go就选择了开发效率和性能的平衡，较高的运行时性能和非常不错的开发效率都兼顾了。但这个理由对独立开发者的一般应用来讲，我觉得不是特别的强烈和重要。理由有二：
我把这段话写到这里的目的，是为了更好的告诉开发者们，一般情况不用痴迷于编程语言，选择自己最擅长的，真正能拿捏的语言就是最好的选择。
当然，我们应该追求个人工具箱里有多门擅长的，真正掌控的语言和工具栈，这能让你在构建产品的过程中做到真正的随心所欲。虽然我们没有选择用Python作为SaaS后台服务的核心语言，但构建AI产品的过程中，我们还是会碰到Python，多语言本就是产品开发过程中的常态。
为什么不是langchain
1.认识langchain
langchain框架有这样的几个核心部分：modelIO，Retrieval，Chain，Agent和memory。
对于Podwise的业务场景来说，除了agent其他几个部分都会涉及，从工作原理的角度，每一个部分本质上都非常简单，简单到根本不需要堆叠一层厚厚的抽象概念，反而实现一层最朴素的wrapper作为工具库是最简单，最易于理解的。
2.langchain总结场景
上图来自langchain官方文档，它展示的是基于langchain实现文档总结的工作流程。
"加载文档->拆分文档->编写prompt->调用LLM->解析获取输出结果"，整个过程跑在一个chain链条上。
可惜的是，这个chain的每一个步骤，在podwise上都需要自定义，并不能直接使用默认提供的工具方法，比如第一个步骤「加载文档」，langchain提供各种文档的loader（比如：pdf文档，markdown、csv、json文档等等），但在podwise实际业务中，需要加载的数据直接来自whisper的结果，也可能直接来自某一个语音转文字的服务的api等，所有的这些数据源，往往都无法直接使用langchain的默认loader，需要采用自定义机制实现自己的loader。
又比如，第二个步骤的「文档拆分」，langchain也提供了多种对长文档进行拆分的方法，比如按文档大小拆分等等，但对podwise来讲，这些拆分方法都太简单粗暴了，无法从内容的上下文逻辑上进行长文档的拆分，所以这个地方又只能采用自定义实现。
到最后，为了更好的质量和效果，会发现大多数情况都要按照自己的业务场景进行自定义实现。那么，框架就只是做了封装、对接infra层面的组件。对于一个有经验的程序员，封装抽象infra恰恰是最简单，最不需要探索的事情（当然，每个人的实际情况不一样，对我来说，可能就非常擅长写这种封装抽象类的框架代码）。
3.框架的不可控性
任何一个你不熟悉的新框架，内部都会隐藏着巨大的不可控性。我们没有使用langchain，在集成AI能力这个部分，遇到「不可控情况」就非常少。比如我们采用next.js作为前端框架，那就遇到了一些不可控的情况。
框架往往是复杂场景下的产物，快速打造应用层产品的mvp，往往只需要最直接，最朴素的解决方案；引入一个厚厚的框架层，唯一的作用就是拉大你和你的目标之间的距离，解决你的目标问题之前，往往需要你先解决框架的问题。（注意：这里提到的框架都是不熟悉的新框架，那些实际业务中久经考验的框架不在此列）
以上基本就是我们为什么不选择langchain的思考。注意，我们并不是在批判langchain，至少不是像MaxWoolf那样，也不是教唆大家不要选择langchain。而是展示我们对框架选择的思考方式——首先是学习框架，然后将业务流程带入框架写一个简单的原型，最后再结合未来的产品发展进行评估，权衡框架带给你什么，你需要付出的风险成本又是什么。
其它选型：
这个技术选型下遇到的问题。
Web启动是比较轻量的，也便于试错。但如果你在后面的计划中有App的需求，那么我会非常建议在动手Web端编码之前先预研一下后面的App方案。
此外Vercel作为我们的主要部署平台，也给我们带来了一些麻烦。像Vercel以及Netlify这些类似平台，都使用AWSlambda作为他们Serverless能力的底层设施。AWSlambda在安装它的基础镜像不包含的依赖库时需要使用自定义layers来完成，而Vercel和Netlify等都不支持自定义layers。这就导致当我们开发的功能需要使用到一些AWSlambda基础镜像中并没有预先安装的依赖库时，无法被成功部署到Vercel或Netlify中。例如我们的DAI（DynamicADsInsertion）检测功能需要使用到libasound.so.2而AWSlambda基础镜像中没有，我们尝试了很多种方式都没有成功完成部署，包括Vercel的官方support给出的结论也是需要等待他们支持layers才可以。最终我们只能把这部分功能剥离出来单独部署，我们选择了zeabur来部署这一小部分。
在经历这一切之后重新选择技术栈的话，我们会怎么选？
绝大多数选择我认为都没有问题，而Webframework我想我会考虑一下Remix。Remix看起来能很好的满足CapacitorJS所需的SPA结构，无需做什么特殊处理。同时Remix也具备前后端同构，SEO友好的特点。也同样能非常方便的在Vercel或Netlify等主流平台上部署。
对于我们遇到的Vercel无法安装额外依赖库的问题，我并不会因为这个问题而选择不使用Vercel或类似的Netlify等平台。Vercel这样的一站式平台带来的其他价值完全值得我们继续选择它，能大大提升产品的迭代交付速度。
我们的技术选型建议：
内容生成类AI产品的后台服务大有不同
2023年ChatGPT的出现，带动了一大批AI产品的诞生，这些AI产品都集中在文字、图片和视频生成领域。这些AI产品和传统的2CSaaS产品有一个巨大的区别（除了AI）：
所以，传统的2C互联网产品很流行使用QPS这个技术指标，而今天的AISaaS产品，很难再使用QPS来度量(或许，可以升级到QPH了)。
针对AI任务的大延迟，消费者端基本也具备一致的共识，所以这类AI应用的后台设计需要重点考虑任务调度，任务排队，任务优先级，任务限流，任务延迟后的用户体验等等。
理解AI模型的能力边界
在具体实现AI产品之前，我们应该深度使用每一款大模型，确保自己对模型有比较深刻、完整的理解。除了知道模型能够做什么以外，更重要的是知道模型能做到什么程度。
搞清楚模型的硬性指标有哪些，比如:GPT-3.5有16k的token支持，这个16k是input和output的token总和。然而，Gemini1.0有32k的token支持，但是32k是input占用了30k，output只有2k。看出区别了吗？Gemini1.02k的output限制，已经决定了你不能让它一次给你输出很长的一段文字，比如用它写小说等长输出场景。
自己写代码还是调用LLM？这一刀从哪里切下去，就是我们理解AI模型的边界。
模型选择
Podwise目前是同时支持GPT和Gemini的，也可以非常方便地再扩展到一个新的模型上。具体使用哪个模型，哪个版本，完全根据模型的效果和成本进行综合评估。在一些特殊的地方，我们甚至使用了动态调用多模型来获取结果，比如Gemini安全限制严格，导致一些播客内容无法得到期望的结果，那我们会根据Gemini的结果动态决策是否调用GPT，等等。
AI工作流
Podwise的整个AI后台服务主要由两条工作流驱动完成：
第一条工作流负责从任务队列获取播客episode进行转录成最终的transcript文本。这个工作流具体就会涉及到：下载音频文件->探测语言->预采样音频内容->whisper转录音频->生成分段->优化transcript->写入db。
第二条工作流负责从任务队列获取被第一条工作流处理完的episode，然后执行LLM总结任务。具体流程：loadtranscript->分段（split）->总结章节，抽取highlights和关键词->基于章节生成全文总结->解释关键词->基于章节生成mindmap->写入db。
为什么是两条工作流，而不是合二为一的一条？开发成一条明显是很自然的选择，一开始我们也是跑在一条工作流上。我们在MVP阶段，整个工作流服务都跑在我们本地电脑上，从下载音频到whisper转录，再到GPT总结。然后就遇到一个很大的问题，由于网络问题，本地电脑调用GPT很容易出错，所以需要把第二部分拆分到aws免费的1核1gec2上（这也是为什么有了在Go的技术选型章节里强调的资源节省问题）。现在，我们已经没有本地电脑运行了，全部在云上。
针对工作流内部再介绍几个关键点：
一：podwise除了使用whisper将音频转成文字外，在这个过程中，还加入了识别speaker，并且将speaker的声音embeding成向量，再写入向量数据库qdrant。借此，我们才做到了在节目的transcript中直接显示speaker的名字。或许有人会认为我们是采用llm从对话中分析出来的speaker名字，实际并不是。
二：whisper转录出来的transcript很长，需要分段后，才能被GPT，Gemini这样的大模型处理。对长文进行分段处理，基本是总结类产品的必备操作。podwise采用了传统NLP的社区算法对文本进行向量相似度计算，从而更好的实现按对话逻辑和内容进行分段。
三：LLM总结流程中的并发设计，涉及到了这样的几种模式（在langchain中也有这样的概念）：
Prompt
做AI产品，除了要设计好的AI任务流程，合理的拆分业务以外，最重要的就是写好prompt，管理好prompt，持续迭代prompt。
prompt一般有两种形式：结构化prompt和对话式prompt。
结构化prompt的优点是通过规范的结构把任务介绍得很清楚，缺点就是往往很长，比较复杂。而对话式prompt更加简单，更符合日常的说话习惯，缺点是难以一句话描述清楚任务，最后得不到满意的结果，需要进行多轮对话才能获得最终结果。两种prompt都有自己的适合场景，结构化的prompt更合适用来内置到产品工作流中，由开发者编写、维护，podwise采用的就是这种复杂的prompt形式。对话式prompt就合适用在chatbot场景，直接由用户发出。
1.结构化prompt
podwise的结构化prompt框架覆盖了如下一些内容：
这是一个结构化prompt的大概框架，这个框架可以采用markdown来描述。podwise的prompt有两个很关键的地方。第一个是多任务，第二个就是输出格式的控制。
2.prompt管理
我们采用模板技术来定义prompt，然后通过模板变量去控制prompt，比如多语言等。使用模板来管理prompt后，就不需要为不同的情况都写一份prompt，只需要抽象好prompt模板+模板变量即可。
3.prompt测试
4.prompt迭代
在开发AI产品的时候，不要纠结一步到位写好prompt，还是需要将重心放到完成整个业务流程和功能上。prompt的编写也和代码一样，需要持续的迭代、优化。所以，需要好的prompt管理方式，方便持续的迭代、测试改进。
对prompt不断地打磨，调试，并不是一件roi很高的事情，但有时候你又不得不做。
得益于近些年云计算的快速发展，不只是IaaS，更多的PaaS产品横空出世，现在构建产品的成本越来越低了，甚至可以做到除了域名之外0成本购买。Podwise在构建产品的过程中当然也完全践行了能省则省的原则。Podwise在最终的选型上，使用了Vercel、Supabase、AmazonSES和LemonSqueezy，几乎做到了零成本。
Podwise是一个播客语音转文字的服务，我们在AI领域会用到两个最基础的服务：
Whisper的商用服务价格为：$0.006/m。换算为一小时的播客节目的话费用为$0.36，接近￥2.6一集，这个成本可想而知。
GPT经历过几次降价，并且区分GPT-4和GPT-3.5。价格如下表：
如果我们以1小时英文播客计算的话，语速一分钟180单词左右，那么一期播客会有大概10000单词，换算到OpenAI的Token计数，同时叠加Prompt以及输出的Token计算，那么会消耗20000左右的Tokens。
按Tokens计算，未降价前GPT-3.5和GPT-4成本分别为：$0.07和$0.8，降价后成本为：$0.025和$0.3。
由于在Podwise构建当时，OpenAI还未降价，所以以当时的成本计算，1小时的英文播客，如果完全使用商业服务，GPT-4版本需要$1.16一期，而GPT-3.5版本也需要$0.43一期。如果订阅版本中提供20期的节目转录，平均一期一个半小时，GPT-3.5的成本需要$12.9左右，GPT-4版本那就更是天价了。所以如何降低成本就变成非常重要的一件事。
首先是Whisper，由于Whisper是开源的，而且业界有不少针对Whisper的优化版本，所以优先思考的就是是否可以将Whisper跑在自己的服务器上，这样每小时节目就可以节省$0.3，这是一笔不菲的费用。所以开始阶段的Podwise节目背后其实都是用Macbook与MacStudio在背后支撑的，得益于开源项目对于MacM系列芯片的不断优化，一小时的音频在M1Max机器上从20分钟提升到了10分钟以内，感谢开源。这样我们就把费用顺利的转化为M系列芯片的电费，众所周知，M系列芯片能耗比非常好，100瓦足以满载工作。满载工作10个小时消耗1度电，按￥1计算的话成本简直不要太低。
Podwise能够快速构建上线，背后用到了很多优秀的三方SaaS服务。我们挑选它们的理由最重要的一点是：物美价廉（甚至最好是免费的）。有部分在前面的内容中也有提到，在这里我们再为大家做一下总结。
03
经过两个月的开发，我们MVP核心功能已经实现，觉得是时候进行一波邀请测试了。在邀请平台的选择上，一方面我们之前已经有Waitlist积累的将近500多个用户，可以通过邮件召回，另外我们也希望通过平台发声让更多的人了解我们。作为程序员，我们首选的宣发渠道是V2EX，主要原因是V2EX是少数允许新产品进行免费宣发的平台，尤其是通过发送邀请码的方式，参与的热情会特别高。
总之，在Podwise在通过LandingPage和V2EX社区的宣发后，成功获得了最初的200个用户，为我们能够持续构建服务开了个好头。
Podwise在一开始的社区反馈上选择了Discord社群的方式，Discord是一个兼具论坛与在线聊天的用户反馈渠道。因为之前是从游戏社群发展而来的，所以它的语音和聊天能力很强，但在后续的发展中，Discord逐渐开始支持用户在其平台上打造社区，其中最重要的特性是可以将Channel建成一个Forum，这样就可以避免重要的信息被海量的聊天记录覆盖。在社区开始时，Podwise就建立了几个基本的Forum，包括feature-request、bugs、help还有integration等。从结果看，Discord的Forums极大的促进了我们产品的正向循环，让我们与用户离得更近。
针对这样的情况，我们在Podwise平台播客节目的详情页添加了一个反馈按钮，让用户可以没有任何心理负担的反馈他对于节目的真实感受。果然上线之后立竿见影，就收到了用户的评价。后续为了继续提升反馈率，我们又让反馈按钮偶尔抖动一下以引起用户的注意，这个改动过后，我们收到的反馈确实显著提升，而且反馈是多样化的，有5星也有1星，这个执行又让我们发现了很多cornercase，显著提升了产品的可用性。
播客节目的反馈背后我们使用Tallyform来作为支撑：
总的来说，通过Discord社群和邮件方式，当前用户的反馈通路是比较顺畅的，对我们产品的迭代很有帮助。
在做产品之前，我们一致认为LLM带动的AI热潮，是SaaS软件很好的一个发展契机。因为大家已经习惯LLM有成本，所以在产品中叠加LLM的能力，可以使以前没有收费能力的软件转上变现的快车道。所以从定价的逻辑上，除了参考友商之外，我们核心还特别从成本角度考虑了定价。
在对标产品上，我们选择了两个：Otter.ai和Snipd。Otter.ai是一款AI语音转文字的工具，并不专注在播客上，它的定价是$16.99转录1200分钟音频。Snipd是一款AI播客播放器，它的定价是$9.9转录15小时，约等于10期播客。
而在我们核算过使用AI的成本后，一期一小时的节目，我发现大概需要$0.3-$0.5的成本。Snipd已经有点压线了，但播客按小时定价其实不是一个很好的定价策略，因为播客的时长不固定，很难预测是否可以转录，如果在时长上出现问题，对用户体验的伤害还是挺大的。所以思考再三，我们决定把定价制定为按期数来定价。按期数定价的好处是，将确定性留给用户，不确定性留给平台。如果按照Snipd的时长换算，我们平价的话也就是提供$9.9转录10期播客。
但这里我们想耍个小聪明，假如每个人都转录10期内容的话，且用户之间有重复，那因为我们已经转录过了，那我们就可以赚一期。但想了想似乎用户一个月只能看10期内容有点少，我们以工作日每天一期为目标，将转录期数定为了20期。这样假如用户之间的重复率达到50%，那么我们还是可以与Snipd一样提供10期左右的成本，来完成。
04
到杠杆高的地方去做宣传
Podwise遵循0成本宣传策略，毕竟是白手起家，本身也没什么钱去投入到营销中。在这种情况下我们就得特别注意方法，不然很有可能事倍功半。
首先我们认为，营销一定要去杠杆高的地方，而且有很好的内容发现机制的平台。
那什么是高杠杆的地方，高杠杆其实是指KOL/KOC比例高的地方，如果要宣传播客，那么最好的渠道应该是即刻的「一起听播客」小组了，这里面有播客听友，同时还有大量的播客节目主理人，他们中的很多人就是播客领域的KOL，所以影响他们就可以顺带影响一批人。另外还有一些平台虽然他们不是KOL，但是因为平台的流量机制，导致每个人的帖子都有可能形成广泛的传播，在这种平台去做宣传也是一个很好的渠道。即虽然受众不是KOL，但形成的二次传播都可能等同于一次KOL的传播。
而低杠杆的平台比较适合做品牌和用户反馈，比如用户会下意识的去Twitter、微博等平台找产品的官方账号，一方面看产品有什么最新的进展，更重要的是反馈问题等，而这些平台因为私信等功能其实还是比较适合做这样的功能的。所以对Podwise来说低杠杆的平台我们会主要做官方内容的宣发以及及时的问题反馈。
总结一下，我们认为在前期我们最需要是通过论坛来做内容营销转化，有一定用户基础之后，再发力做品牌营销来巩固用户。
再聊一下ProductHunt的Launch，很多人把在ProductHunt的发布看得比较重，觉得能从这次发布中直接获取大量的用户，并借此获得不菲的营收。但其实往往是事与愿违的。因为ProductHunt网站的核心用户其实是产品经理和开发者，如果你的产品面向的用户是他们，那有可能，但大部分的产品其实是面向普通用户的，客群不匹配，结果可想而知。
我们比较建议如果要为「独立」做长期打算的开发者，可以试试用buildinpublic的方式。
经过本期节目，我们的营销历程算是正式开始了，并且在上线当天我们就完成了销售，算是开门红。
在经过互动和回复的两招后，Podwise在即刻「一起听播客」圈子已经小有名气，但要爆发还缺少一环，真实KOL的硬核推荐。KOL的推荐一定来自广泛的受众覆盖，这样才有可能更大概率击中KOL。更重要的是需要产品体验真正打动用户，这样才会自发的给产品代言。酒香也怕巷子深，但前提还是酒香，所以，好产品和高覆盖宣传缺一不可。
经过即刻的宣传过后，我们意外的发现了在小红书出现了Podwise的热帖，而且曝光量超过想象：
考虑到我们本身并没有在别的平台做过宣发，所以这次小红书KOL自主宣传也很有可能来自于即刻本身的社区覆盖，在热帖下面我们发现，很多用户不知道Podwise如何访问，还有使用方法等不太清楚，我们想说，是时候可以做做小红书了。
如果说即刻是一个KOL主导的社区，那在小红书，它的流量策略可以让每个人都火一次。所以在小红书「标题党+解决方案」是一个非常好的流量获取策略，比如：哭死，姐妹们，家人们，谁懂啊等等，当然如果你的标题内容主打帮大家解决一个问题，那这篇内容是有可能迎来传播的，当然是有可能，不是绝对，毕竟小红书的推流策略是一个黑盒。
所以当我们发现用户在小红书上排名第一的竟然是Podwise怎么用的时候，我们就立刻决定写一篇Podwise使用教程的内容，至今还在不断的收获点赞和转化。
这些是我们当前在获客的一些方法，这里也推荐播客节目「乱翻书」的一个传播金句：「用户最爱转发的内容有三种：一种叫喜闻乐见，一种叫感同身受，第三种叫对我有用，它们的共通点都是与我有关。」
我们认为这是一个非常好的底层逻辑，适用于各种社交媒体，如果你的内容还做不到「喜闻乐见」和「感同身受」的话，那至少保证「对我有用」。这可能是成本最低的获客方式了。
最后营销这件事，重点在如果10万行代码可以成就一个优秀的程序员，那我们可以问问自己是否有发过哪怕1万字的营销文案。如果没有的话，请坚持下来。
在黑五到来之前，我们收到了一封来自竞对的65%OFF的邮件，其实没有思考太多，下意识告诉我们，黑五确实该做一次优惠，而且折扣力度应该是前所未有的，我们的选择是跟随。
Podwise的定价是$9.9一个月，年订的话折算到月$5.9，按人民币计价的话超过￥40人民币，这对于国内用户来说是有些偏高的，对比国内付费渗透率较高的应用来说，年订￥298已经是很多产品上限，可以注意网盘和视频会员，他们定价大多都在￥198-￥298之间。而Podwise的年订价格是超过￥500的，这对于一部分是是有一定疑虑的，当然这是针对国内市场的定价问题，对于国外来说，$9.9的定价本身不存在问题。
通过3.5折左右的折扣，我们将Podwise的年订价格降到了￥290左右，这样结合用户对于AI高成本的预期，比较成功的实现了一次势能转换，为什么说是势能转换，主要是将前期的一些品牌曝光度，美誉度等等在一次活动中的集中变现。
在活动结束之后，我们发现Podwise的增长曲线比活动之前来的更加陡峭一些，明显是受众增加而带来的订阅增长，我们分析这里面一定有来自活动之后订阅用户的二次传播，这些都是免费的流量。
所以我们也认为在产品获得一定曝光后，适当通过活动甚至互动赠送的方式发展种子用户，也不失为一个获得客户的好方法。当然，所有的前提都是产品足够惊艳。
可以看到，Podwise本身订阅用户的爆发式增长其实也不是偶然，前期大量的宣传工作对于品牌的建立和曝光起到了非常关键的作用，当然产品自身的美誉度更是产品能够多次传播的根基，首先是酒香，其次才是让巷子不要那么深。现在Podwise的订阅量还非常少，后续我们还需要一步一个脚印，让对Podwise有需要的用户能更方便的触达产品。
05
对远景的一些规划
Podwise当前的主要形态是Web版，虽然有Mobilefirst的设计，可以在手机上直接打开，但毕竟不像app那样方便。所以移动版的app是我们未来首要的目标。
还有一个重要的原因是，我们发现在平台营销时，大量的用户会问在哪里下载？而且还出现了用户在AppStore中购买了同名的app发现不是我们的产品，过来找官方账号抱怨的。而且移动版可以至少帮我们做两件事，第一是扩大Podwise的应用场景，之前主要做笔记，现在也可以听了。第二是扩大产品的曝光范围，多平台的曝光是独立开发产品非常重要的，因为我们只需要10000个忠实用户就够了。类似于游戏的全平台发布，如果成本不高的话，强烈建议做多平台发布。
当然如果要扩展海外市场的话，除了在营销上需要跟进，还有一个很重要的是本地化。尤其是在笔记盛行的日韩地区，我们需要做界面、包括内容的国际化。由于全球95%的头部播客都是英文播客，所以东亚语言都需要做英文到当地语言的翻译，这样可以满足很多语言学习者的需求，尤其在东亚英语不是母语的基础上。当前Podwise的中文用户会看到中文和英文内容，未来日韩的用户也需要看到他们当地语言和英文的组合。这是对他们最习惯的内容。
如果有什么是我们最不应该犯的错误，那就是我们在定价的时候期望用信息差来赚钱。
结果，在第一次测试的时候，多为用户直接提问，是不是你们会缓存节目的转录结果，下个用户来的时候就不用再次转录了。这里面产生了两个逻辑：有用户提问，如果是我转的，那我能不能拿后续的阅读分润？还有用户提另外的问题，如果已经被转过的节目，我在学习的时候能不能只扣我0.5次。到这里我们才恍然大悟，做产品永远不能把用户当傻瓜，这是我们最大的错误。
接到用户的灵魂两问之后，我们也紧急讨论，最后决定将计费方式变更为：主动使用AI处理播客会扣除次数，但查看已处理过的节目则不扣除次数，并且Podwise平台会帮大家默认转平台上订阅Top100的节目。从这个决定看，我们付出了巨大的代价，不仅无法利用播客的头部效应来降低成本，而且平台还默认转录内容当成大家免费的资源。在这之后，考虑到利润，我们只能寄希望于GPT规模化降价以及Podwise自己的规模化盈利了。但没办法，我们不能通过惩罚客户来弥补自己的错误。
在最初的计划中，我们希望通过邮件的形式来与客户沟通，通过周报与新功能发布在邮件中跟客户沟通，但通过植入邮件的监测后我们发现，邮件的打开率非常低。我们才开发反思是否应该有更直接的方式？经过讨论过后我们优先尝试去建立即刻的Podwise官方账号，并开始在一起听播客群组中营销，在这之后发现这种模式惊人的有效。因为社区的强互动性让大家对新产品非常热情，之后我们又开拓了包括小红书和X的官方账号，当前正在做reddit账号的尝试。如果有什么事是可以尽早做的，那应该是在用户聚集场所建立官方账号，你会收到很多有效的反馈，也可以帮你拓展新用户。
Podwise到今天，还远没有成功，但我们认为产品应该度过了0-1的PMF阶段。过程中运气也占了很大的比例，我们在这里也不是在尝试总结，而是在充分讨论后，我们认为：如果还有下一个产品要做，我们会坚持的几件事：
另外非常重要的一点是快速发布，我们很庆幸在beta测试的时候，客户给我们提了计费方式的问题，我们才在这个过程中对方案进行了修改，并且添加了趋势页面，如果再过两个月，我们做的更成熟直接发布，那可能会损失很大一部分流量。所以，确认MVP，让产品尽快与客户见面，寻求反馈，快速迭代，是我们永远追求的链路。
最后，大胆谈钱。产品发布的第一天开始就一定要有付费选项，想好自己的商业模式。如果是AI产品一定要充分计算自己的成本，好的AI产品毛利要高于60%。尽量不要贱卖自己的产品，9元人民币和9美元之间有7倍的差距，而不同地区的最低时薪之间差距巨大。我们已经作为独立开发者，算是数字游民了，可以赚高时薪地区的钱，能做地理套利，千万不要错过。