Simon Willison 用 Codex 语音模式为博客开发 Newsletters 功能

Simon Willison 博客·2026-10-09 20:54· 6 分钟前AI 评分61

A new feature for my, blog built using my voice

AI 导读

Simon Willison 用 ChatGPT 桌面应用的 Codex 语音模式（模型为 GPT-6 Astra High），在做饭的约半小时内以纯语音为博客构建了 Newsletters 索引页，包括新 Django 模型与迁移、四项数据导入、公开归档页和站点搜索集成。

正文

我今天为我的博客发布了一个新功能：Newsletters 页面，它提供了我发送过的所有新闻通讯的索引，包括我的免费 每周 Substack 和我的 每月仅限赞助者 更新。我几乎完全用语音构建了这个功能，一边做晚饭一边对着笔记本电脑聊天。

Codex 语音模式

我为此使用了 ChatGPT 桌面应用，在 Codex 标签页中，使用语音对话模式，针对本地开发环境运行。它看起来是这样的：

我通过输入以下内容，针对我本地的 simonwillisonblog 检出启动了会话：

Start dev server and open in browser

这让我预览了它将要在其上工作的站点，也意味着我之后可以要求它向我展示新页面，以便我能直观地跟踪它的进展。

然后我点击了“开始新的语音聊天”按钮——那不是麦克风按钮，而是它右边的那个——并把我的笔记本电脑放在厨房里，这样我做饭时就能和它说话。

与我的电脑交谈

我很清楚自己想要构建什么，而且这是一个足够简单的 Django 功能，我确信模型（在这种情况下是 GPT-6 Astra High）能够做到。一个新模型、一个迁移、一些视图代码、模板，以及几个从外部来源填充数据库的导入函数。

以下是 Codex 捕获的我的语音转录摘录：

嗯，它们不会。嗯，这将是一种新的内容类型。嗯，它不会显示……哦，等等。对，不——我不希望它显示在我的，嗯，标签页和日期归档页面上，还有……实际上，不，我想……我不希望它出现在标签页上。我不希望它出现在，嗯，博客索引页面上。但我想我确实希望它出现在基于日期的页面上。你知道，如果你导航到 9 月 19 日，而我在那天发送了一份新闻通讯，我想我希望它显示出来。所以……这是——所以我想我们可能需要一个新模型。另一件事是我希望它们可搜索，呃，Substack 的那些不可搜索，因为那些实际上只是我博客上其他内容的副本。这些每月的内容确实包含独特内容，而且，一旦它们……发布，比如一旦它们在发出一个月后公开，我希望它们出现在我的搜索结果中。

显然这已经足够清楚，模型知道我想要构建什么！你可以阅读完整转录，包括所有不流畅之处，在这个 Gist 中。

我们就这样继续了大约半小时（做晚饭所需的时间）。模型会回复，偶尔提出澄清问题，然后开始修改代码。

我们构建了什么

我们完全通过语音取得了令人惊讶的进展：

• 一个用于在 Django 中表示导入的新闻通讯的新模型和迁移，以及相应的 Django Admin 配置
• Four working imports:
  • 通过 RSS 获取最新的 Substack 条目
  • 通过他们未公开的 API 获取所有其他 Substack 条目，GPT-6 Astra 要么知道这个 API，要么通过搜索找到了它
  • 我发布在 simonw/monthly-newsletter-archive GitHub 仓库中的所有已发布每月新闻通讯
  • 我最近一份来自私有仓库的仅限赞助者的私密新闻通讯
• /newsletters/ 和 /newsletters/2026/ 公共归档页面
• 新闻通讯也出现在按日和按月归档页面上，但不在标签页面或我的主页上
• 每周 Substack 新闻通讯链接到 Substack；归档的每月新闻通讯有自己的页面
• 与我的网站搜索引擎集成

它几乎可以发布了。问题在于导入：Astra 提出可以从我的本地副本导出数据，以便我将其导入到生产环境，但我希望它能像我的其他导入脚本一样工作。由于部分数据存放在一个私有的 GitHub 仓库中，这需要创建一个新的 API 密钥，而为此我知道我得在键盘前坐上一会儿。

通过审查来完成它

当我完成烹饪并判断它基本功能齐全后，我让 Codex 创建了一个分支并打开了一个拉取请求。

我在 GitHub PR 界面中审查了代码。它几乎就是我需要的，只是它选择在其中一个导入脚本中使用子进程调用 Git。我需要其中一个导入从私有 Git 仓库拉取，所以我认为用 API 会更好。我切换为打字，并让 Codex 将其替换为基于 API 的导入。

你可以在 PR 上的额外提交中 看到我在审查期间所做的更改。我修复了导入机制，并对那些公共页面的显示做了一些调整。又花了半小时基于打字的提示，才达到我满意并愿意通过合并 PR 将其部署到生产环境的状态。

最终结果

你可以在新的 新闻通讯索引页面 看到最终结果，或者查看 之前某期每月新闻通讯的页面。

索引页面按时间倒序混合显示我最近的 Substack 每周新闻通讯和 GitHub 赞助者每月新闻通讯。页面更下方是按年份归档页面的链接。

GPT-6 Astra 设计了该页面，然后根据我在厨房对面瞥一眼本地预览时给出的口头反馈调整了设计。

更适合多任务处理，而非日常主力

OpenAI 喜欢 在 DevDay 之类的场合 使用这种语音驱动的演示——它们在那样的环境中确实效果很好。不过我认为这不会成为我的日常主力。

我 之前写过，我在遛狗时用手机上的 ChatGPT 语音模式完成了多少“工作”——主要是研究和头脑风暴，但偶尔也会通过让 ChatGPT 编写和测试代码片段来进行实际开发工作。

这次感觉不同。视觉预览的加入，加上在我需要传达无法用语音表达的内容时可以通过键盘输入或粘贴，使这成为与编码代理交互的一种强大得多的方式。

不过，当我深入到细节时，我仍然会切换回打字。能够粘贴示例和错误消息，或者直接高亮需要更改的代码或功能，仍然比试图用语言描述更高效。

我主要在家工作，这很好，因为在共享办公空间里我绝不想这样跟我的电脑说话！

对我来说，杀手级功能是多任务处理能力。我通常一边做饭一边放着播客或 TikTok；现在我可以真正地构建东西了。

标签：text-to-speech、ai、openai、generative-ai、llms、newsletter、coding-agents、codex、speech-to-text、site-upgrades

来源：Simon Willison 博客 · simonwillison.net