他用 Cursor 和 AI，零代码拼出一个能跑的播客超级 App

如果你还认为“做 App 必须会写代码”，这条视频会直接把这个认知掀翻。Riley Brown 用 Cursor、Perplexity 和一堆 AI 服务，现场拼出一个 RSS 驱动的播客超级 App——没有传统编码流程，却一步步跑通了产品逻辑。这不是演示，是一次对“谁能做软件”的重新定义。

最反直觉的一点：他不是在“学写代码”，而是在“指挥代码”

视频一开始，Riley Brown 就抛出一个对开发者极具冲击力的前提：我们今天不用传统方式写一行代码。但你很快会发现，他并不是在“偷懒”，而是在切换角色——从“代码执行者”变成“产品指挥官”。

他打开 Cursor，不是先搭框架、写函数，而是直接描述“我想要什么样的行为”：点标题显示 Markdown 内容、RSS 拉取失败要有提示、界面看起来要“像现在这样好看”。Cursor 的角色不是 IDE，而更像一个随叫随到的初级工程师，负责把模糊需求补全成可运行的实现。

这背后的变化很残酷：门槛不再是语法，而是你是否能把需求说清楚。不会表达的人，即使有最强的 AI，也做不出东西。

从“野心很大”到“只做播客”：这是高手的取舍

Riley 一开始的目标其实很夸张——一个 RSS 驱动的“超级 App”。但他马上踩刹车：先只做播客。这不是妥协，而是经验。

他选择播客作为切入口，有三个隐含好处：第一，RSS 结构相对标准，适合 AI 生成代码；第二，内容天然是音频，后续可以接语音识别；第三，播客用户本身就对“信息整理”和“深度内容”有需求。

在 Cursor 里，他快速实现了：拉取 RSS、展示标题、点击后用 Markdown 显示内容，甚至能优雅处理“feed invalid”“audio invalid”这种脏数据。这里最值得注意的不是功能本身，而是节奏——他没有追求完美，而是持续让系统‘多跑一步’。AI 辅助开发的正确姿势，就是永远让产品处在“半成品但可用”的状态。

Perplexity + 转写：AI 工具不是替代，而是接力

在 RSS 内容加载的间隙，Riley 切到 Perplexity，让它“把所有标题和内容拉出来，并且像现在这样好看”。这一步非常关键：他不是让一个 AI 做所有事，而是把不同 AI 当作流水线上的工位。

接下来是更硬核的一步：音频转文字。他明确提出需求——“最快、最便宜的多小时音频转文本方案”，目标非常现实：播客动辄两三个小时，成本和速度决定产品能不能成立。这里他关心的不是模型参数，而是“能不能规模化跑”。

当转写完成后，系统可以持续这个流程：新 RSS → 新音频 → 新文本 → 新笔记。甚至这些笔记，可以随时导出成文本文件。这已经不是玩具，而是一个完整的信息加工链路。

真正的杀手锏：给内容加一个“会思考的入口”

视频后半段，Riley 做了一件很聪明的事：加 AI Chat。不是为了炫技，而是为了让内容“活起来”。

他要的不是普通聊天框，而是一个弹窗式 AI，可以围绕播客内容，自动找出“有趣的概念和想法”。当你点开某一期播客，比如 Theo Von 或 Joe Rogan 的节目，不只是播放音频或视频，而是多了一个可以随时对话的“第二大脑”。

这一刻，这个 App 的性质发生了变化：它不再只是播放器，而是一个内容理解工具。用户不是被动听，而是可以追问、延展、对照。对 AI 从业者来说，这个设计信号非常明确：未来的内容产品，核心竞争力不在内容本身，而在‘你能帮用户想多远’。

总结

这条视频真正值得反复看的，不是“零代码”这个噱头，而是它展示了一种新的能力结构：会不会写代码，正在让位于会不会设计流程、拆解问题、指挥 AI。如果你是开发者，这意味着要把精力从语法细节转向产品判断；如果你不是开发者，这可能是你第一次真正有机会把想法做成能跑的东西。

一个现实的行动建议是：选一个你熟悉的内容场景（播客、资讯、内部知识库），用 Cursor 先跑通最小闭环，再逐步叠加 Perplexity、转写和 AI Chat。最后留给你一个问题：当“实现成本”无限接近于零时，真正稀缺的能力，会变成什么？

关键词： Cursor， Perplexity， 零代码开发， AI 应用构建， 播客 App

事实核查备注： 视频发布时间：2025-02-02；作者/频道：Riley Brown；使用工具：Cursor、Perplexity；应用类型：RSS 驱动的播客 App；功能点：Markdown 展示、RSS 校验、音频转文字、AI Chat 弹窗