一句自然语言，一个能跑的原生应用

茉莉: 大家好，我是茉莉。你正在收听的是 Bri 播客旗下的《ProductHunt 产品分享》。

白桦: 我是白桦。今天我们会聊几个让开发这件事变得像说话一样简单的工具：Glaze by Raycast 把一句话变成 Mac 原生应用，Osloq 让 AI 真的跑代码来复现 bug，还有 Vox 在终端里用语音指挥 Copilot。

茉莉: 如果告诉你，现在可以用聊天的方式，直接“说”出一个能在 Mac 上跑的原生应用，你觉得第一步会是什么？

白桦: 我可能会先怀疑它只能生成个网页套壳，但这次好像不一样。

茉莉: 对，关键区别就在这里。Glaze by Raycast 走的不是网页打包路线，它生成的是真正调用 macOS 原生组件的 App。

白桦: 也就是说，它背后对接的是苹果的 SwiftUI 和 SwiftData 这套框架。

茉莉: 对。你只要用自然语言描述想法，它会先给你一个交互式预览，让你在生成代码前就看到 App 长什么样、怎么点。

白桦: 这其实把门槛降了不止一级。以前你至少得知道 Xcode 怎么新建项目，现在连这一步都省了。

茉莉: 它还会主动把界面拆成有状态的 SwiftUI 视图，数据模型自动按 SwiftData 建好，存储和 iCloud 同步都帮你配齐。

白桦: 听起来像是一个会写代码的产品经理在帮你做原型。

茉莉: 更直接的是，很多只有 Mac 端才成立的 idea，现在一个下午就能跑起来。

白桦: 而且它直接集成在 Raycast 里，全程用命令和对话就能完成，几乎不用离开键盘。

茉莉: 那问题就变成——当构建成本降到一句话的时候，什么样的想法还值得被做成 App。

白桦: 对，这条线一划，很多“想做个自己的小工具”的人，其实今天就可以动手了。

茉莉: 上一期我们聊了把想法直接变成 Mac 应用的工具，而这个话题恰好带出一个更细的痛点：代码写出来了，bug 也来了，大多数 AI 工具只能读代码去猜问题在哪里。

白桦: 猜？那不就靠静态分析碰运气吗。

茉莉: 没错，Osloq 这个产品就是冲着这个局限来的——它不是光看代码，而是真的把你的代码跑起来，去复现 GitHub issue 里描述的 bug。

白桦: 也就是说它像个会自己动手的调试助手，而不只是读文档。

茉莉: 对。多数 AI 编程工具停在读代码这一步，Osloq 的标签写得很直白：An AI agent that reproduces GitHub issues for you。

白桦: 复现 issue 这件事有意思，因为很多 bug 单靠读代码根本看不出来，得让程序跑到出错的上下文才能暴露。

茉莉: 它就是抓住这一点。用户给一个 GitHub issue 链接，Osloq 会 clone 仓库、装依赖、跑起环境，然后试着触发 issue 里描述的错误路径。

白桦: 所以它不是只给修复建议，而是先在真实运行时复现出那个错误状态。

茉莉: 正是这样。等它成功复现之后，才会进入下一步，针对真实的报错栈和日志去定位修改点。

白桦: 那它目前主要支持哪种技术栈？不然范围太宽会很难稳定复现。

茉莉: 从它的介绍来看，初期主要面向 JavaScript 和 TypeScript 项目，这也是开源社区 GitHub issue 最密集的区域。

白桦: 这意味着它对 npm 生态的依赖安装和脚本执行是有专门适配的，不是一通瞎跑。

茉莉: 对。另外它的价值不只是定位，而是让开发者不再需要手动拉代码、配环境、看半天日志才确定是否可重现。

白桦: 这个环节其实很耗心力，很多 issue 就卡在"能不能复现"这一步，Osloq 等于把这一步自动化了。

茉莉: 所以它对开源维护者特别实用，issue 列表里常年躺着大量待确认的问题，手动一个个配环境成本极高。

白桦: 但也要看它的复现成功率，有些 bug 依赖特定数据或外部服务，光靠代码跑不一定能撞上。

茉莉: 没错，这就是它的边界，如果 issue 本身缺乏明确步骤或依赖不可重建的外部条件，代理也很难成功。

白桦: 也就是说它能解决"可执行但费时"的复现任务，不是所有 bug 都通吃。

茉莉: 对，这其实反倒让它定位清晰：把确定性高的重复劳动从人手里拿走，而不是许诺一个全自动的修复魔法。

白桦: 所以 Osloq 的核心思路不是抢开发者的判断力，而是省掉他们最贵的精力——从零搭复现环境的精力。

茉莉: 从上一则能自动复现 bug 的 AI 代理，我们接着看另一个直接把手伸进开发终端的工具。

白桦: 这个方向更极端，连键盘都不用碰了。

茉莉: Vox，一个语音进、语音出的GitHub Copilot命令行扩展。

白桦: 它是说在终端里对着一个光环说话，Copilot就直接帮你写命令、改代码吗？

茉莉: 没错。你在终端输入vox启动，屏幕上会出现一个呼吸式的光环，然后你说出需求，它实时转换成Copilot可执行的指令。

白桦: 那执行结果呢？还得自己盯着屏幕看报错信息？

茉莉: 它会把命令输出再读给你听，光标也不用挪过去检查。

白桦: 也就是说整个操作循环都是语音驱动的，不用切浏览器搜索，也不用复制粘贴。

茉莉: 对，而且因为它底层是Copilot CLI，它能理解项目上下文和环境变量，不仅仅是执行固定命令。

白桦: 这意味着它可以在你不离开终端的情况下，完成从提出问题到得到结果的全过程。

茉莉: 真正把通用语音助手变成了开发环境里的即时协作者。

白桦: 当然，前提是你的口述描述得足够精确，否则它也只会生成一个模糊的脚本。

茉莉: Copilot的上下文理解帮了忙，它会在当前仓库和Shell历史里寻找线索，减少语音歧义。

白桦: 这意味着过去我们在命令行里反复试错的那几秒，现在可能一句话就带过去了。

茉莉: 刚才说的 Vox 是让程序员用语音写命令。现在这个 nxt 更进一步，它想让你像和人说话一样管理待办事项。

白桦: 和人说话一样管理待办？ 这其实解决了一个很真实的痛点：想法来得太快，打开应用、打字、分类的过程本身就打断了思路。

茉莉: 对，nxt 的做法是把这段链路缩短成一句话。比如你直接说一句话，会把任务和会议准备混在一起说出来。

白桦: 这就从“先用大脑分类再记录”变成了“先倾倒再让人工智能整理”。 你刚才提到的开会准备那类话，它会怎么处理？

茉莉: 它会把那一大串话拆成独立任务，比如“买牛奶”变成一个待办，“周三前给陈总发邮件”带上截止日并自动分类。

白桦: 那它的角色其实不只是一个收件箱，更像是一个能听懂上下文的小型调度器。

茉莉: 没错。它用自然语言交互取代了字段填写，你不需要选项目、设标签，只需要不停地说。

白桦: 那之前很多工具失败的点恰恰在这里——用户一开始愿意认真分类，但两星期后就放弃了。

茉莉: nxt 恰恰抓的就是这个持续性门槛。它声称你就像跟人类助理交代一样，把所有事情交给它，它负责告诉你“接下来做什么”。

白桦: 那它回答“接下来做什么”时，是给单一建议，还是列清单？

茉莉: 目前看到的是，它用对话给出下一步，而不是堆给你一个完整列表，这样决策压力更小。

白桦: 这正是和传统任务管理器拉开距离的地方。 它把任务管理的交互，从梳理列表变成了回答一个问题：我现在该做什么。

茉莉: 刚才说的那个 AI 助手能帮你把任务都管起来。但现在有个更“活”的东西，直接趴在你屏幕最上层，看着你写代码，还会跟着 Claude Code 的使用频率一起长大。

白桦: 桌面宠物？它不会就是个在屏幕上跑来跑去的装饰吧？

茉莉: 没那么简单。这个叫 Tamamon 的 macOS 小东西，具体成长值和你用 Claude Code 的频率挂钩，你写得越多，它进化得越明显。

白桦: 那它怎么知道自己该长成什么样？总不能凭空变出来。

茉莉: 关键就在绑定——它直接和 Claude Code 的 usage 连在一起。开发者把它设计成“养成”模式，你的编码输出就是宠物的食物。

白桦: 所以可以理解成：不写代码它就饿着，写得多就进化。这对一直用 Claude Code 的人来说，屏幕角落里多了一个看得见的反馈。

茉莉: 对，而且它不是藏在后台，是直接浮在所有窗口上面，你一抬头就能看见它当前的状态。

白桦: 这相当于一边敲代码一边养电子宠物，debug 的时候还可能觉得有它在陪着。

茉莉: 不过目前还很早期，只是把“使用量”这种抽象数据，变成了一个真正会成长的桌面伙伴，算是个挺巧妙的绑定。

茉莉: 你发过一封很漂亮的邮件，结果发现收件人点开了，但想要的注册或付费却没来，那种感觉就像对着黑洞喊话，对吧？

白桦: 对，就是不知道邮件的钱到底花在了哪里。 今天刚好看到一个直接针对这个痛点的发布：Loops 推出了一个新功能叫 Goals。

茉莉: 哦？就是那个做 SaaS 邮件营销的 Loops 吗？

白桦: 没错。Goals 这个功能，就是让团队能在 Loops 后台里，直接看清是哪一封邮件、哪一个具体步骤，带来了注册或者付费。

茉莉: 所以它把“发送”和“转化”这两件事重新连起来了。

白桦: 对它的核心逻辑就是这样。它允许你设置一个指标作为目标，比如“完成注册”。

茉莉: 然后系统会自动归因？

白桦: 是的，而且归因逻辑不是只算最后一次点击。它更能辨认出，是不是那封“七天试用提醒”最终推动了付费。

茉莉: 这样预算分配就变得很清楚了。

白桦: 对，这才是它想解决的问题——你不再需要靠猜的。你可以直接停掉那些只贡献了打开率却没带来一分钱收入的邮件序列。

茉莉: 一句话总结，就是让做增长的人，终于能用收入数据来校准每一次沟通了。

茉莉: 除了追踪转化，理解产品本身的结构又是另一回事了。最近有个叫Archify的工具，直接把组件和API检查搬进了浏览器。

白桦: 直接在浏览器里看清软件用了什么组件和库？听起来像是给开发者准备的。

茉莉: 没错。它的思路是，你打开一个网页，就能直接查看里边的组件树、用到的API，还有它依赖了哪些第三方库。

白桦: 这比传统在开发者工具里一个个翻网络请求要直观得多。相当于给应用做了一次现场解剖。

茉莉: 而且不只是看静态结构。它还能帮你理解应用在浏览器里的实际行为，比如某个交互到底触发了哪个内部方法。

白桦: 这对接手老项目或者分析竞品的时候，确实很实用。省去了大量猜代码逻辑的时间。

茉莉: 从写代码到发邮件，这些工具都在做同一件事：把复杂的步骤压到一句对话里。感谢收听，下期见。

白桦: 我们下次接着聊。