Simon Willison 用语音对话让 AI 为博客新增 Newsletters 页面
来源标题：A new feature for my blog, built using my voice
Simon Willison 发布博客新功能 Newsletters 页面，汇总其免费周更 Substack 与月度赞助者专享邮件。他几乎全程通过语音完成开发：在 ChatGPT 桌面版 Codex 标签页中开启语音对话模式，连接本地开发环境，边做饭边对笔记本说话，完成了新的 Django 模型、迁移和视图代码。
以下正文由 AI 翻译自 Simon Willison（原文版权归原站所有），可能存在偏差，重要内容请以原文为准。
今天我为我的博客发布了一项新功能：Newsletters 页面，它提供了我发出的所有 newsletter 的索引，包括我每周免费的 Substack 和每月仅限赞助者的更新。我几乎完全用语音构建了这个功能——一边做晚饭，一边对着笔记本电脑说话。
Codex 语音模式
我使用的是 ChatGPT 桌面应用，在 Codex 标签页中，使用语音对话模式，运行在本地开发环境上。效果是这样的：
我针对本地的 simonwillisonblog 检出目录开始会话，输入了：
启动开发服务器并在浏览器中打开
这让我看到了它将要在上面工作的网站预览，也意味着我之后可以要求它向我展示新页面，以便我能直观地追踪它的进度。
然后我点击了"开始新的语音聊天"按钮——那不是麦克风按钮，而是它右边的那个——并把笔记本电脑放在厨房里，这样我做饭时就能和它说话。
与我的电脑交谈
我很清楚自己想要构建什么，而且这是一个足够简单的 Django 功能，我确信模型（在这种情况下是 GPT-6 Astra High）能够完成。一个新模型、一次迁移、一些视图代码、模板，以及几个从外部来源填充数据库的导入函数。
以下是 Codex 捕捉到的我的语音转录片段：
嗯，它们没有。嗯，这会是一种新的内容类型。嗯，它不会显示……哦，等等。对，不——我不希望它显示在我的，嗯，标签页面和日期归档页面上，还有……实际上，不，我想……我不希望它在标签页面上。我不希望它在，嗯，博客索引页面上。但我想我确实希望它显示在基于日期的页面上。你知道，如果你导航到 9 月 19 日，而我在那天发了一份 newsletter，我希望它能显示出来。所以……这是——所以我想我们可能需要一个新模型。另一件事是我希望它们可被搜索，呃，Substack 的那些不可搜索，因为那些实际上只是我博客上其他内容的副本。这些每月的确实包含独特的内容，而且——一旦它们……发布，比如一旦它们在发出一个月后公开，我希望它们出现在我的搜索结果中。
显然这已经足够清晰，模型知道我想构建什么了！你可以在这个 Gist 中阅读完整的转录，包括所有不流畅的地方。
我们这样继续了大约半小时（做晚饭所需的时间）。模型会回复，偶尔问一些澄清问题，然后开始修改代码。
我们构建了什么
我们完全通过语音取得了令人惊讶的进展：
- 一个用于在 Django 中表示导入的 newsletter 的新模型和迁移，以及相应的 Django Admin 配置
- 四个可用的导入：
- 通过 RSS 导入最新的 Substack 条目
- 通过它们未公开的 API 导入其他所有 Substack 条目，GPT-6 Astra 要么知道这个 API，要么通过搜索找到了它
- 从我的 simonw/monthly-newsletter-archive GitHub 仓库导入我所有已发布的每月 newsletter
- 从一个私有仓库导入我最近的仅限赞助者的私密 newsletter
- /newsletters/ 和 /newsletters/2026/ 公开归档页面
- Newsletter 也显示在日和月归档页面上，但不显示在标签页面或我的主页上
- 每周 Substack newsletter 链接到 Substack；归档的每月 newsletter 有自己的页面
- 与我的网站搜索引擎集成
它几乎可以发布了。问题在于导入：Astra 提出从我的本地副本导出数据，以便我可以将其导入生产环境，但我希望它能像我其他导入脚本一样工作。由于部分数据存放在一个私有 GitHub 仓库中，这涉及到创建一个新的 API key，而为此我知道我必须在键盘前坐上一会儿。
通过审查来完成它
等我做完饭并判断它基本功能完整后，我让 Codex 创建了一个分支并打开了一个 pull request。
我在 GitHub PR 界面中审查了代码。它几乎就是我需要的，只是它选择在其中一个导入脚本中使用子进程调用 Git。我需要其中一个导入从私有 Git 仓库拉取，所以我认为用 API 会更好。我切换到打字，让 Codex 把它换成了基于 API 的导入。
你可以在 PR 上的额外 commit 中看到我在审查期间所做的更改。我修复了导入机制，并对那些公开页面的显示做了一些调整。又花了半小时基于打字的提示，才达到我愿意通过合并 PR 将其部署到生产环境的程度。
最终结果
你可以在新的 newsletter 索引页面看到最终结果，或者查看之前某个月度 newsletter 的页面。
索引页面按时间倒序混合显示了我最近的 Substack 每周 newsletter 和 GitHub 赞助者的每月 newsletter。页面下方是按年份归档页面的链接。
GPT-6 Astra 设计了页面，然后根据我隔着厨房瞥一眼本地预览后给出的语音反馈调整了设计。
更适合多任务处理，而非日常主力工具
OpenAI 喜欢在 DevDay 之类的场合使用像这样由语音驱动的演示——而且它们在那样的环境中确实效果很好。不过我认为这不会成为我的日常主力工具。
我以前写过，我在遛狗时用手机上的 ChatGPT 语音模式能完成多少"工作"——主要是研究和头脑风暴，但偶尔也通过让 ChatGPT 编写和测试代码片段来做实际的开发工作。
这次感觉不同。视觉预览的加入，加上在我需要传达某些不适合语音表达的内容时可以通过键盘打字或粘贴，使它成为一种强大得多的与编码 agent 交互的方式。
（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）
正文由 探How 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。