用语音和编码智能体为博客开发新功能

一位开发者为自己的博客上线了一个新功能：Newsletters 页面。这个页面用于索引他发出的所有 newsletter，包括免费的每周 Substack 更新，以及面向 GitHub Sponsors 的每月更新。

有趣的是，这个功能几乎是他在做晚饭时，通过语音和笔记本电脑对话完成的。

使用 Codex 语音模式开发

他使用的是 ChatGPT 桌面应用中的 Codex 标签页，并开启语音对话模式，同时连接本地开发环境。

开始时，他在本地博客代码库中输入了一条指令：

Start dev server and open in browser

这样 Codex 可以启动本地开发服务器，并在浏览器中预览站点。后续他就能让模型打开新页面，自己从厨房远远看一眼页面效果，再通过语音给出修改意见。

随后，他点击“Start new voice chat”按钮，把笔记本放到厨房，一边做饭一边和电脑交流。

他事先大致知道自己想要什么：这是一个相对简单的 Django 功能，包括：

语音转录中包含大量停顿、重复和临时改口，但模型仍然理解了他的意图，并开始修改代码。

整个语音开发过程持续了大约半小时，也就是他做完晚饭所需的时间。期间模型会回复、偶尔提出澄清问题，然后继续修改项目。

仅靠语音交互，他们完成了相当多内容：

在 Django 中新增用于表示导入 newsletter 的模型和迁移
配置 Django Admin
实现四类导入：
- 通过 RSS 导入最近的 Substack 条目
- 通过 Substack 未公开 API 导入其他 Substack 条目
- 从公开 GitHub 仓库导入已发布的月度 newsletter
- 从私有仓库导入最新的仅限 sponsors 的 newsletter
创建公开归档页面：
- /newsletters/
- /newsletters/2026/
让 newsletter 出现在按日和按月归档页中
避免它们出现在标签页和首页
让每周 Substack newsletter 链接到 Substack
为归档后的月度 newsletter 创建独立页面
集成站内搜索

到这一步，功能已经接近可发布状态。

不过，导入逻辑仍需要调整。模型曾建议从本地副本导出数据再导入生产环境，但作者希望它像站点中其他导入脚本一样工作。由于部分数据位于私有 GitHub 仓库，这需要新建 API key，因此他决定回到键盘前继续处理。

做完饭后，他让 Codex 创建分支并打开 pull request。

随后，他在 GitHub 的 PR 界面中审查代码。整体已经接近需求，但其中一个导入脚本使用了子进程调用 Git。由于该导入需要从私有 Git 仓库拉取内容，他认为使用 API 更合适，于是切换回键盘输入，让 Codex 改成基于 API 的导入方式。

之后，他又通过大约半小时的文字提示完成了：

最终，该 PR 被合并并上线。

新的 newsletter 索引页会把最近的 Substack 每周 newsletter 和 GitHub Sponsors 月度 newsletter 混合在一起，按时间倒序展示。页面下方还有按年份查看归档的入口。

页面设计最初由 GPT-6 Astra 生成，随后作者根据自己从厨房看到的本地预览，通过语音给出反馈，让模型继续调整设计。

作者认为，这类语音驱动的开发演示确实有效，尤其适合展示编码智能体的能力。但他并不认为这会成为自己的日常主力开发方式。

原因是：当进入细节阶段时，键盘仍然更高效。例如：

这些操作用文字或界面交互仍比口头描述更方便。

不过，这次体验的关键价值在于：可以多任务处理。他过去做饭时通常会听播客或刷短视频，而现在可以在同一时间推进实际开发工作。

这种方式也有明显限制：如果在共享办公空间，对着电脑持续说话显然并不现实。但在居家办公场景下，语音、可视化预览和键盘输入结合起来，确实提供了一种更强的编码智能体交互方式。