一边做饭一边把博客功能做完了：Simon Willison 的语音 vibe coding 实录

2026 年 10 月 9 日，Simon Willison 在自己的博客上发了一篇 1294 词的长文，标题是《A new feature for my blog, built using my voice》。标题已经把故事讲完了：他给自己的博客上线了一个新功能——Newsletters 索引页，把他发过的所有 newsletter 归拢到一个页面上，包括免费的每周 Substack 和付费的月度赞助者更新。而整个功能的开发过程，"几乎完全用语音完成"——他人当时在厨房里做饭。

这件事值得写一整篇，不是因为他做了一个多难的功能——恰恰相反，这个功能简单得刻意。而是因为"谁"和"怎么"：Simon Willison，Datasette 的作者、Django 的联合创作者，过去几年里把 LLM 实践记录得最细致的开发者之一。他博客上的每一篇工作流记录，都像是给开发者社区的一份提前半年的预告。当这样一个人开始"用嘴写代码"，并且认真地把全过程写下来，这就不再是某个语音助手的营销噱头，而是一个值得拆开细看的生产力迁移信号。

他到底做了什么：一个索引页，和一顿饭的功夫

先说功能。新上线的 Newsletters 页面（simonwillison.net/newsletters/）干的是一件归拢的活：把散落在两个地方的 newsletter 索引到一起——免费的每周 Substack（simonw.substack.com，七万多订阅者）和 GitHub Sponsors 的付费月度更新。对读者来说，这是一个"终于不用翻两个地方找旧刊"的入口；对博客本身来说，这是一次标准的内容资产整理。

再说任务范围。Simon 在文中把活儿拆得很实在：一个标准的 Django 小功能——一个新的 model、一次 migration、view 层代码、模板，外加两个从外部数据源往数据库里导入数据的 import 函数。听着简单，但这正是关键：他选了一个"agent 一定能搞定"的任务来验证工作流，而不是拿语音去啃硬骨头。第一次试新姿势，先挑软柿子捏——这是老手才有的分寸感。

复盘他的操作链：开局只敲了一行字

这篇文章最有价值的部分，是他把操作链写得像一份实验记录，细节精确到按钮的位置：

• 工具：ChatGPT 桌面应用，Codex tab，语音对话模式，对着本地开发环境跑——他的博客代码仓库 simonwillisonblog 就在笔记本本地，agent 直接在上面干活。
• 开局：整个过程中他只正经敲了一行字——让 agent 启动 dev server，并在浏览器里打开预览页。这一步的妙处在于建立了一个"看得见"的验收回路：之后他随时可以让 agent"把新页面给我看看"，用眼睛追踪进度。
• 关键按钮：然后他点了"Start new voice chat"按钮——他特意强调，这不是输入框旁边的麦克风按钮，是它右边的那个。细节控如 Simon，这种区分写出来，就是给想照抄的人提前排雷。
• 开聊：笔记本架进厨房，对着它说话，开始做饭。背后的模型是 GPT-6 Astra High。
• 证据：他在文中还贴出了一段 Codex 抓下来的语音转写摘录——等于把"嘴替开发"的原始笔录公开了，任人检验这到底是真干活还是行为艺术。

Simon 的工作流示意：笔记本架进厨房，语音对话驱动本地的 coding agent，浏览器预览作为验收回路

注意这个链条里的分工：嘴负责下指令，agent 负责写代码、跑服务，眼睛负责看预览验收。没有一个环节是"对着空气许愿"，每一步都有落点。这也是为什么这篇记录可信——它不是"我让 AI 写了个博客功能"的又一篇玄学帖，而是一次有验收、有笔录的对照实验。

为什么偏偏是现在：语音 vibe coding 的四个前提

语音编程不是新点子。十年前就有人对着 IDE 喊"打开文件"，体验普遍是灾难。Simon 这次能成，靠的不是他嗓音条件好，而是四个前提在 2026 年同时到位了：

第一，agent 循环成熟了。coding agent 不再是"一次生成一段代码"的玩具，而是能自己起服务、自己开浏览器、自己看页面效果的闭环。Simon 的第一步——让 agent 起 dev server 并打开预览——本质上是把"动手"外包给了 agent，把"验收"留给了自己。语音指令擅长表达"做什么"，不擅长逐行检查"怎么做"；agent 循环正好补上了后半段。没有这个闭环，语音就只是个高级听写机。

第二，上下文足够长。语音是高熵输入：口语啰嗦、重复、自我修正，"嗯……我是说，把那个、那个索引页……"。只有能记住整段对话、还能随时回看仓库代码的长上下文模型，才接得住这种"你懂我意思吧"式的表达，并把它翻译成正确的 migration。短上下文时代，语音 coding 的信息损耗是致命的。

第三，语音转写质量过关了。转写错一个词，代码里可能就错一个变量名。Simon 敢全程信任转写，说明这条链路已经好到"不用提心吊胆"的程度——而这在两年前还是要反复校对的。

第四，也是最关键的一条：agent 承担了"精度损失"。键盘输入精度高、带宽低；语音输入带宽高、精度低。过去这条路走不通，是因为代码不容忍精度损失——差一个字符就编译不过。现在 agent 成了中间的"翻译层"，把模糊的口语意图编译成精确的代码。输入方式的短板，被执行层的智能补上了。

所以"用嘴写代码"不是语音技术单点的胜利，而是整个 agent 栈成熟之后，输入端自然发生的松绑。Simon 选在这个时间点做这件事，本身就是一种判断。

"I built the feature almost entirely using my voice, chatting away to my laptop while I cooked dinner."

—— Simon Willison，《A new feature for my blog, built using my voice》，2026 年 10 月 9 日

边界：什么适合"边做饭边开发"，什么不行

别急着把键盘扔了。Simon 这次其实给出了完美的"适用样板"，反过来看，不符合这几条的就别试：

适合的任务长这样：

• 需求已经在你脑子里成型了。他说自己"对要做什么心里很清楚"。语音适合表达已知意图，不适合边想边设计——你总不能对着锅说"让我想想这个架构……"。
• 任务边界小、试错成本低。一个页面、一次 migration，做坏了 rollback 也便宜。语音的高带宽在这里是优势：描述一个 CRUD 页面，用嘴比用手快得多。
• 验收回路短且可视化。浏览器里看一眼就行，不需要读 500 行日志。Simon 先建预览回路再开聊，顺序不能反。
• 你对代码库足够熟。这是他自己的博客，Django 项目，闭眼都知道 model 该长什么样。agent 跑偏了他一眼就能听出来——注意，是"听出来"，因为验收标准在他脑子里，不在屏幕上。

不适合的任务也长这样：

• 复杂调试。读 stack trace、逐行对日志、比对两个版本的 diff——语音的线性、不可回看特性在这里是硬伤。你没法"说"出一行行日志的对比。
• 需要精确规格的设计决策。API 字段命名、数据库 schema 的深思熟虑——嘴比手快，但嘴也比手随意。重要的命名和结构，值得坐下来一个字母一个字母地推敲。
• 生产救火和并发、安全深水区。agent 自信地写错 migration 的样子，你不会想在做饭时领教。高压 + 低精度输入 + 高风险操作，这个组合没有好结局。

语音工作流的边界：嘴负责表达已知意图，眼睛负责验收；复杂调试与高风险操作仍然需要键盘和屏幕

一句话总结这个边界：语音工作流的真正瓶颈从来不是"说"，而是"验"。Simon 全篇最聪明的一步，其实是第一步：先让 agent 把预览跑起来。嘴负责下指令，眼睛负责验收——分工对了，厨房才能变机房；分工错了，就是一场行为艺术。

从"手敲"到"嘴说"：开发者输入方式的变迁

把视线拉远一点，这件事放在编程史上看，一点都不突兀。编程史就是一部"输入精度要求不断下降"的历史：从汇编写到高级语言，从手写每一行到 IDE 自动补全，从 Copilot 的行级补全到 agent 的整功能交付——每一步，都是把"精确表达"的工作从人手里拿走一点，交给工具。语音是这条曲线的自然延伸。

键盘时代，瓶颈是"你打字有多快"；agent 时代，瓶颈正在变成"你把意图说得有多清楚"。这是一个值得细品的转变：编程的核心动作，正在从"精确输入指令"变成"清晰表达意图"。Simon 在厨房里的那一幕，恰好是这个转变最具象的画面——双手在切菜，嘴在讲需求，代码在另一边自己长出来。

这里有一个反直觉的判断：语音 coding 对资深开发者更友好。Simon 能这么干，前提是他一眼能看出 agent 生成的 migration 对不对、模板写得合不合理。嘴替的是打字，不是判断。新手用语音 vibe coding，最大的风险不是说不清楚，而是看不懂——验收能力没跟上，嘴越快，坑越大。这和开车一个道理：自动驾驶解放的是手，不是路况判断力。

另一个判断：这会改变"编程"的体感，但不会改变"工程"的本质。需求澄清、边界定义、验收标准——这些依然是人的活。只不过以前你坐在桌前干，现在你可以站在灶台前干。工具把"坐在哪"这个约束拿掉了，但"想清楚"这个要求，一点没降。

最小配置：想照抄，先备齐这五样

如果你看完也手痒，想试试"嘴替开发"，按 Simon 的实验记录，照抄这份清单：

• 一个带语音对话模式的 coding agent 桌面端。他用的是 ChatGPT 桌面应用的 Codex tab。注意是"开始新语音对话"按钮，不是输入框旁边的麦克风——两个按钮，两种模式，点错了体验完全不一样。
• 本地开发环境 + 一键可起的预览。开局先让 agent 把 dev server 跑起来、页面在浏览器打开。这是整个工作流的验收锚点。没有它，语音就是蒙眼开车——你都不知道 agent 到底干了什么。
• 一个你已经想清楚的 CRUD 级小功能。第一次别挑战自我，选 agent 一定能做对的。Simon 选的是"新 model + migration + 模板 + 导入脚本"，难度标定得极其精准。
• 熟悉的代码库，自己的项目优先。你知道"对"长什么样，才敢让嘴替手。在别人的代码库里玩语音 coding，等于闭眼走钢丝。
• 接受"手忙嘴闲"的场景。厨房不是必须的，但"手被占着"正是这个工作流的甜点：通勤、遛弯、做家务——那些原本被浪费的时间，现在可以变成"只动嘴"的生产时间。编程第一次有了"副业时间"的概念。

最后还有一个 Simon 式的忠告藏在细节里：他是先打字让环境就绪，才切换到语音的。别被"全程语音"的标题党带偏——聪明的工作流从不为难自己，该用手的时候用手，该用嘴的时候用嘴。标题说的是"almost entirely"，这个 almost，就是老手的诚实。

尾声

当连 Simon Willison 都开始用嘴写代码，问题不再是"语音 coding 靠不靠谱"，而是"你的验收能力配不配得上你的嘴"。键盘不会消失，就像 IDE 没有杀死终端；但"坐直了、双手放在键盘上"作为编程的默认姿势，可能正在松动。

下一次你站在厨房等水开的时候，也许可以想一想：有没有一个小功能，是可以"说"出来的？如果有，不妨学 Simon——先让 agent 把预览跑起来，然后把笔记本架好，开始做饭。

一手来源：Simon Willison 个人博客《A new feature for my blog, built using my voice》（2026 年 10 月 9 日），功能为 Newsletters 索引页（汇总免费周刊 Substack 与付费月度更新），工具为 ChatGPT 桌面端 Codex tab 语音对话模式 + 本地开发环境，模型为 GPT-6 Astra High。