語音驅動開發：我用聲音打造部落格新頁面

2026 年 10 月 9 日

我今天為我的部落格推出了一項新功能：電子報頁面。這個頁面提供了我所有已發送電子報的索引，包括我免費的每週 Substack 和每月僅限贊助者的更新。我幾乎完全是透過語音來建立這項功能的，一邊做晚餐一邊對著我的筆記型電腦說話。

Codex 語音模式

我使用 ChatGPT 桌面應用程式的 Codex 分頁，在語音對話模式下進行，並在本地開發環境中運行。這就是它的樣子：

我透過輸入「啟動開發伺服器並在瀏覽器中開啟」來啟動我的本地 simonwillisonblog 專案。這讓我可以看到網站的預覽，也意味著我之後可以要求它顯示新頁面，以便我能視覺化地追蹤進度。

然後我點擊了「開始新的語音聊天」按鈕（那不是麥克風按鈕，是它右邊的那個），並把我的筆記型電腦放在廚房，這樣我就可以一邊做飯一邊跟它說話。

與電腦對話

我對要建立什麼功能已經有了相當清楚的想法，而且這是一個足夠簡單的 Django 功能，我確信這個模型（在這個案例中是 GPT-6 Astra High）能夠完成。它需要一個新的模型、一個資料庫遷移、一些視圖程式碼、模板，以及幾個匯入函式來從外部來源填充資料庫。

以下是 Codex 捕捉到的我的語音轉錄摘錄：

「嗯，它們沒有。嗯，這將是一種新的內容類型。嗯，它不會顯示... 哦，等等。是的，不，我不想讓它顯示在我的標籤頁面和日期歸檔頁面... 實際上，不，我想... 我不想讓它顯示在標籤頁面。我不想讓它顯示在部落格索引頁面。但我認為我確實想讓它顯示在基於日期的頁面上。

你知道，如果你導航到 9 月 19 日，而我在那天發送了一份電子報，我想讓它顯示出來。所以... 這就是... 所以我想我們可能需要一個新的模型。另一件事是，我希望它們可以被搜尋，Substack 的那些不能被搜尋，因為它們實際上只是我部落格上其他內容的副本。

這些每月電子報確實包含獨特的內容，一旦它們發布，也就是說在發送一個月後公開，我希望它們能顯示在我的搜尋結果中。」

顯然，這段話足夠清楚，模型知道我想建立什麼！你可以在這個 Gist 中閱讀完整的轉錄，包括語氣詞和停頓。我們就這樣持續了大約半小時（做晚餐的時間）。模型會回覆並偶爾提出澄清問題，然後開始修改程式碼。

我們建立了什麼

我們完全透過語音取得了驚人的進展：

一個新的模型和資料庫遷移，用於在 Django 中表示匯入的電子報，以及其 Django Admin 配置。

四個可用的匯入功能：

透過 RSS 匯入最新的 Substack 文章。

透過 Substack 未公開的 API 匯入所有其他 Substack 文章，GPT-6 Astra 知道這個 API（它直接嘗試了 /api/v1/archive），然後執行搜尋以找出如何分頁，並找到了 Karen Spinner 的這篇文章。

從我的 simonw/monthly-newsletter-archive GitHub 儲存庫匯入所有已發布的每月電子報。

從一個私人儲存庫匯入我最新的私人贊助者專屬電子報。

/newsletters/ 和 /newsletters/2026/ 公開歸檔頁面。

電子報也顯示在日和月歸檔頁面上，但不在標籤頁面或我的首頁上。

每週 Substack 電子報連結到 Substack；已歸檔的每月電子報有自己的頁面。

與我的網站搜尋引擎整合。

它幾乎準備好發布了。問題出在匯入功能：Astra 提議從我的本地副本匯出資料，這樣我就可以將其匯入到生產環境中，但我希望它能像我其他的匯入腳本一樣運作。由於某些資料存在於私人 GitHub 儲存庫中，這將涉及建立一個新的 API 金鑰，為此我知道我必須在鍵盤前坐一會兒。

透過審查完成

當我做完飯並判斷功能大致完成後，我讓 Codex 建立了一個分支並開啟一個合併請求。

我在 GitHub 合併請求介面中審查了程式碼。它幾乎是我需要的，只是它選擇在一個匯入腳本中使用子程序中的 Git。我需要其中一個匯入功能從私人 Git 儲存庫中提取，所以我認為 API 會是更好的選擇。我切換到打字模式，讓 Codex 將其替換為基於 API 的匯入。

你可以在合併請求中的額外提交中看到我在審查期間所做的更改。我修復了匯入機制，並對這些公開頁面的顯示做了一些調整。又花了半小時的打字提示才達到我滿意並可以將合併請求部署到生產環境的程度。

最終結果

你可以在新的電子報索引頁面看到最終結果，或查看以前的每月電子報頁面。

索引頁面以倒序時間排列，混合顯示我最新的 Substack 每週電子報和 GitHub 贊助者每月電子報。頁面下方還有我的按年歸檔頁面連結。

GPT-6 Astra 設計了這個頁面，然後根據我從廚房遠處瞥見本地預覽後提供的語音回饋，調整了設計。

比日常主力工具更適合多工處理

OpenAI 喜歡在 DevDay 等活動中使用這種語音驅動的演示，而且它們在這種環境下確實表現良好。不過，我認為這不會成為我的日常主力工具。

我之前寫過，我在遛狗時使用手機上的 ChatGPT 語音模式完成了多少「工作」，主要是研究和腦力激盪，但偶爾也會透過讓 ChatGPT 編寫和測試程式碼片段來進行實際的開發工作。

這次的感覺不同。視覺預覽的加入，加上當我需要傳達語音無法表達的內容時，能夠透過鍵盤打字或貼上，使這成為與程式編寫代理互動更強大的方式。

不過，一旦我深入到細節，我仍然會切換回打字。能夠貼上範例和錯誤訊息，或者直接突出顯示需要更改的程式碼或功能，仍然比嘗試用語言描述更有效率。

我主要在家工作，這很好，因為我絕對不想在共享工作空間裡這樣對著電腦說話！

對我來說，最殺手級的功能是多工處理能力。我通常會一邊聽播客或看 TikTok 一邊做飯；現在我卻可以一邊做飯一邊實際建立東西。