Simon Willison 用 Codex 语音模式为博客构建新功能

这条消息最容易被记住的数字是“半小时”：Willison 称语音对话持续了约半小时，正好是他做一顿晚饭的时间。但同一篇自述里还有另一个半小时——从语音阶段结束到满意并合并 PR 部署到生产，又花了额外半小时的打字式提示。两个半小时并列，才是这次实验真正的形状。

换句话说，语音把项目从零推到了“几乎可以发布”，但没有推到“可以发布”。这条分界线不是由模型能力单独划出的，而是由任务性质划出的：哪些工作可以靠描述完成，哪些必须靠指认完成。

按 Willison 的自述，语音阶段产出的内容相当具体：用于表示导入新闻邮件的 Django 新模型与迁移及 Admin 配置；四个可用的导入脚本；/newsletters/ 与 /newsletters/2026/ 两个公开归档页；新闻邮件出现在日与月归档页但不出现于标签页和首页；每周 Substack 邮件链接回 Substack 而归档月度邮件有独立页面；以及接入站内搜索。

四个导入分别来自：最新 Substack 条目的 RSS、其余 Substack 条目的未公开 API、simonw/monthly-newsletter-archive GitHub 仓库中已发布的月度邮件，以及一个私有仓库中最近一期仅赞助者可见的邮件。

这些是作者自述的产出清单，属于 source_claim，来源中没有独立的部署验证或运行结果佐证。

Willison 认为他带有大量口头语和停顿的语音转录已经足够清楚，模型据此理解了他想构建的东西。在约半小时的语音过程中，模型会回复、偶尔提出澄清性问题，然后动手修改代码。

一个值得注意的细节是 Substack 的未公开 API：Willison 称 GPT-6 Astra 要么本来就知道、要么通过搜索找到了它。他本人也不确定是哪一种。这说明模型在这次任务中表现出的“知道”，其来源对使用者而言是不透明的。

本次开发使用的模型是 GPT-6 Astra High，这是作者自述的模型名称，来源中无独立佐证。

语音阶段结束后，Willison 让 Codex 建分支并开 pull request，在 GitHub PR 界面审查时发现某个导入脚本用了子进程调用 Git，于是改用基于 API 的导入，并在 PR 上追加提交修正导入机制和公开页面显示。

这里有一个硬约束：部分数据位于私有 GitHub 仓库，导入需要新建 API key，因此必须坐到键盘前操作。这不是模型不够聪明的问题，而是权限与凭据的物理位置问题。

更普遍的限制是：细节调整、粘贴示例与报错、高亮代码等操作仍依赖键盘而非语音。Willison 明确表示，粘贴示例和报错信息、或直接高亮要改的代码，仍比用语言描述更高效。

Willison 把这次体验与他此前在手机上用 ChatGPT 语音模式的经历做了对比。他认为不同之处在于增加了可视化预览，并且可以在需要时用键盘打字或粘贴，因此是更强大的编码智能体交互方式。

这个判断值得单独拎出来：如果只把语音当成输入方式，它并不比打字更高效；但当语音与本地预览、键盘回退组合在一起时，它才成为一种可用的工作流。语音负责推进，预览负责校准，键盘负责收口。

他先在本地 simonwillisonblog 检出目录输入“Start dev server and open in browser”启动预览，再点击“Start new voice chat”按钮开始语音会话。预览先于语音存在，这个顺序本身就有含义。

Willison 称对他而言最大的亮点是能多任务并行：以前做饭时只能听播客或刷 TikTok，现在可以顺手写代码。

他也给出了使用场景的边界：他主要在家工作，因为他不愿在共享办公空间里这样对电脑说话。这既是一个现实约束，也提示这类交互方式对物理环境有要求。

至于语音开发效率相比纯打字是否更高，来源只给出作者的主观感受，没有对照数据。此类语音驱动开发能否推广到更复杂项目，来源也未提供证据。