Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

來自 Simon Willison（西蒙·威利森）在 Software Misadventures 的訪談筆記

我剛聽完Simon Willison（西蒙·威利森）在 Software Misadventures 播客上的訪談。我從這次訪談中學到很多，因此整理成了這份筆記。

這不是整場訪談的完整摘要，只記錄了對我而言較新、或是我想記住的部分。

西蒙·威利森在Software Misadventures 播客上

西蒙·威利森是誰？

外掛作為開源貢獻的一種形式

原始討論

  • 將應用程式設計成可接受外掛來擴充功能，是一種比接受開源貢獻摩擦更低的協作形式。
    • 外部協作者無需經過你的審查或批准就能新增功能，而且你也不必負責維護他們的程式碼。

外掛最棒的地方在於，它是一種打造開源專案的方式，你不需要審查別人的程式碼就能為自己的東西增加功能。我可以某天早上醒來，發現我的軟體多了一項新功能，因為有人為它發布了一個外掛。

［編按：我覺得這是一個很有趣的觀察。我從未設計過支援外掛的軟體，但西蒙·威利森為這種架構提出了非常有力的論點。］

LLM(大型語言模型)

培養如何使用 LLM 的直覺

原始討論

  • LLM 看似簡單，實際上卻很難駕馭，因為它的限制並不明顯。
    • 它們看起來很簡單，因為只是聊天機器人，但你需要在各種任務上使用數小時，才能培養出對其能做與不能做之事的直覺。
    • 例如：LLM 不擅長計數，這令人意外，因為電腦通常非常擅長計數。
  • 西蒙·威利森推薦 Anthropic 的 prompt engineering(提示工程) 文件，認為這是有效提升 LLM 使用技巧的方法。
  • 西蒙·威利森建議使用可自行架設的模型（例如 Phi-3、LLama 3.1）來學習，因為它們產生幻覺和犯錯的頻率更高，能幫助你更清楚掌握 LLM 不擅長什麼。

西蒙·威利森如何使用 LLM

原始討論

  • 彙整資訊
    • 善用長 context window(上下文視窗)來加速研究。例如，要研究一個人時，可以把他的維基百科頁面、相關報導與著作全部貼到對話中，並請 LLM 歸納重點主題並舉例說明。
    • 要求提供直接引文，並核對原始來源，以確認 LLM 沒有產生幻覺。

      如果我的朋友讀完維基百科頁面後就能回答我的問題，那我就知道 LLM 也有能力回答這個問題。但如果這個問題是維基百科頁面大概不會涵蓋的內容，那 LLM 能回答的可能性就比較低。

  • 詢問你具備專業知識的領域

    我會問它法律問題，例如貼上服務條款，然後說：「嗨，這裡面有沒有看起來有點可疑的地方？」

    我很清楚這是個糟糕的主意，因為我完全不懂法律，對吧？所以我有點像是在跟它演戲、隨口附和，但我絕不會根據從 LLM 得到的法律建議去做會影響人生的重大決定，因為我不是律師。

    如果我是律師，我會一直使用它們，因為我可以依靠自己的專業知識來確保自己是負責任地使用它們。

  • 撰寫 SQL 查詢
    • 西蒙·威利森建議向 LLM 提供完整的資料表結構與幾筆範例資料。
  • 資料輸入
    • 例如，從手寫筆記轉錄資訊，或從非結構化文件中擷取結構化資料
    • 最優秀的 LLM 準確度約為 95%，大致相當於聘請一群人類實習生來做同樣工作的成果。
  • 做出軟體架構決策
    • 西蒙·威利森會請 LLM 針對同一項任務提供多種可行方案，並逐一討論其優缺點。
  • 閱讀學術論文
    • 西蒙·威利森寫了一個名為 Dejargonizer 的工具，用來解釋不熟悉的術語。
    • ［編按：我覺得這個工具比較像是有趣的點子，而非真正實用的工具。你必須貼上文字，而我餵入一篇 5 頁的論文後就耗盡了上下文限制。將文本重寫並在行內直接定義術語詞彙會更有意義。］

西蒙·威利森對 LLM 的「奇怪實習生」心智模型

原始討論

  • 西蒙·威利森向妻子形容 LLM 是「他那個奇怪的實習生」。

    就像有一個實習生，他……背下了每種程式語言的文件，卻又是個狂熱的陰謀論者，有時會提出荒謬的點子……而且他極度自以為是。

  • 相較於人類隊友，LLM 的一大優勢在於你可以不斷要求它改進解決方案。
    • 跟人類隊友合作時，你最終得停止要求反覆修改，因為不斷想出新點子來改進 pull request 對人類來說是很令人沮喪的；但對 LLM，你可以要求大幅重寫，而不必擔心浪費它的時間或不尊重它。
  • 西蒙·威利森發現，只要說一句「Do better」，就能讓 LLM 改進它的回答：

    我最喜歡的提示之一就是直接說：「Do better」，而且真的有效。這太瘋狂了！

    它會先寫一段程式碼，然後你說：「Do better」，它就會說：「喔，抱歉」，接著吐出更好的程式碼。這項技術居然是這樣運作的，真的很蠢，但也蠻有趣的。

LLM 讓以往不值得投入的專案變得可行

原始討論

  • LLM 對西蒙·威利森的一大影響，是讓他身為開發者變得更有雄心。
    • 以前，他想到一個專案，意識到最適合的實作語言是 AppleScript 或 Go，就會因為不懂這些語言而擱置點子。
    • 現在，他可以利用 LLM 產生程式碼，並驗證其是否符合需求。
  • 他以前其實也可以去學這些技術，但 LLM 把入門門檻降得夠低，讓這些專案變得更實際可行：

    如果沒有 LLM，這些小專案全都不會存在。不是因為我做不出來，而是因為我無法做得夠快，快到足以讓投入的時間變得值得。

掌握 LLM 的最新發展

原始討論

  • 最有價值的資訊來自約 15 人的私人 WhatsApp 與 Discord 群組。
  • Twitter 上有不錯的 AI 討論。
    • Mastodon 則沒有，因為那裡聚集了較多的 AI 懷疑論者。
  • 由於西蒙·威利森的部落格，人們經常會向他提供關於 LLM 新發展的有趣線索。

為何 LLM 不一定會用糟糕的程式碼污染世界

原始討論

  • LLM 的缺點在於，有些程式碼在作者自己都不理解的情況下就被部署到正式環境。
    • 這對全世界而言是一種風險，因為這意味著 LLM 可能會降低整體軟體品質。
  • 西蒙·威利森指出，世界上許多系統所依賴的程式碼，甚至比 LLM 產生的那種「黏糊」（goop）程式碼還要糟糕：

    我們現在生活在一個世界，一半的世界靠著沒有單元測試、沒有備份、沒有版本控管的 Excel 試算表在運轉……任何人都可能搞砸一個公式，然後一間公司的估值就一夜之間腰斬……

    這就是我們今天所處的世界，對吧？Excel 試算表本身就已經算是某種黏糊了，但社會不知怎麼地還是照常運作。

    所以，也許我們這些堅持「每一行程式碼都必須完美」的人，可能是錯的。也許黏糊才是未來的方向，但這有點令人害怕，你知道嗎？

寫部落格

每天寫一篇新的部落格文章

原始討論

  • 西蒙·威利森嘗試每天寫一篇新的部落格文章。

時間投入

原始討論

  • 西蒙·威利森每天花 10 到 15 分鐘寫部落格。
  • 由於已經寫了 22 年，他現在能夠寫得更快。

從部落格到電子報的流程

原始討論

  • 西蒙·威利森有一份電子報，內容就只是自上次發送以來部落格上所有新增內容的差異（diff）：

    這是一種很棒的方式，可以把內容傳達給那些長期待在電子郵件收件匣裡的讀者。

  • 西蒙·威利森寫了一個 Observable 筆記本，會從他的部落格擷取內容並轉換為 Substack 相容的富文本。然後他再從筆記本複製到 Substack 並發送電子報。
  • 他有 6,000 名 Substack 訂閱者。
  • 整個流程每份電子報只需花費兩分鐘。

［編按：西蒙·威利森沒有談到這點，但我認為他這種同步到 Substack 的方式會對 SEO 造成負面影響，因為它會在不同網址上產生兩份相同的內容，Google 將無法判斷哪一份是原創。］

［編按：我也覺得很驚訝，西蒙·威利森使用的是 Substack 的網域，而不是 simonwillison.net 底下的某個子網域，因為據我所知 Substack 是允許自訂網域的。］

部落格基礎架構

原始討論

  • 西蒙·威利森的主要部落格是一個運行在 Heroku 上、並以 Cloudflare 作為 CDN 的實例。

Cloudflare 最棒的地方在於，就算流量突然暴增，例如被放到 Hacker News 首頁，我那個便宜又小型的 Heroku 實例也完全不會受到影響，因為 Cloudflare 會吸收掉所有流量。

Bing 聊天事件

原始討論

把所有事情都變成 GitHub issue

原始討論

  • 西蒙·威利森將個人的待辦清單以 GitHub issue 的形式來維護。
  • 他維護著 250 個專案。
    • 他記錄這些專案時，假設自己會忘記所有細節。

      我可以回到一個已經一年沒碰的專案，像完全不了解這個專案一樣閱讀文件，然後就開始工作。

  • 他也把設計文件寫成 issue。

    我有一些 issue 討論串長達上百則留言，而且全都是我自己。根本就是我在自言自語。

［編按：這是一個令人驚訝的工作流程，因為它優化了寫入而非讀取。當你想了解一個 issue 時，你被迫要閱讀數百則留言，而不是閱讀一則總結當前狀態的留言。］

「Temporal(時效性)」文件與現行文件

原始討論

  • 西蒙·威利森認為軟體有兩種文件。
    1. 說明軟體目前功能的說明文件。
    2. 描述文件撰寫當下軟體功能的說明文件，但不一定在今日仍準確（「temporal(時效性)」文件）
  • GitHub issue 適合用於時效性文件。
    • 西蒙·威利森可以查看 issue 並透過撰寫日期來了解該文件在何時是準確的。
  • 對於必須與程式碼保持一致的文件，他會將文件以 Markdown 檔案的形式與程式碼放在同一個儲存庫中，並確保程式碼更新時文件也會同步更新。

作為獨立開發者的生活

原始討論

  • 西蒙·威利森首次體驗獨立工作，是在他獲得 Stanford 為期一年的帶薪數據新聞研究獎學金時。

    那段經歷太棒了，也徹底改變了我，因為他們付錢讓我花一年時間去做我認為最有趣的任何事情。

    一旦體驗過那樣，就很難再回到讓別人……來定義你要做什麼的狀態。所以基本上，那就是問題所在，我體驗了一年的自由，然後我就想：「我不想放棄這種自由，我做這些事太開心了。」

時間管理

原始討論

  • 西蒙·威利森發現要決定該做什麼極其困難，因為相較於為雇主工作，幾乎沒有外部壓力或問責。
    • AI 有太多有趣的領域可以探索，而且沒有任何事物能阻止他一直探索下去。
  • 他有時會希望自己有創投投資者，這樣就有人能讓他專注於目標上。
  • 研討會驅動開發
    • 西蒙·威利森會承諾在研討會前完成某些功能，這迫使他必須在期限前優先完成實作。
  • Weeknotes

邁向財務獨立

原始討論

  • 西蒙·威利森渴望實現財務獨立。
    • Eventbrite 在西蒙·威利森的新創公司仍在成長時將其收購，之後他在那裡擔任工程總監長達六年。
    • 他擁有「可觀的資金緩衝」但還不足以讓他完全不用擔心收入。
    • 在 Datasette 產生足夠收入、成為其主要收入來源之前，他正尋求顧問工作機會以提供收入。

［編按：整場訪談中最讓我驚訝的是，西蒙·威利森竟然還沒有實現財務獨立，因為我原本以為他已經達成了。］

Datasette 的目標

原始討論

  • 西蒙·威利森對 Datasette 的目標，是讓一位記者使用 Datasette 來撰寫一篇贏得普立茲獎的報導。
  • 他希望能聘請一個團隊與他一起進行這個專案，因為他覺得獨自工作很孤單。
  • 他想效法 WordPress 的模式，將程式碼開源，並透過提供代管服務來獲利。

在資料新聞學中使用 LLM 的挑戰

原始討論

  • 所有主流的 LLM 都會審查資訊，這讓資料新聞工作變得更加困難。

如果你是記者，你處理的某些原始素材是很棘手的，對吧？像是關於暴力事件的警方報告、法西斯主義的留言板……現在，如果你有一個 LLM 來幫忙處理這些東西，而你請它總結這個法西斯公告板的主題，它會直接說「不」，對吧？

很多 LLM 會直接拒絕處理這些內容，這……大大限制了它們的實用性……

後設：我如何建立這些筆記

我使用 yt-dlp 下載了訪談影片：

yt-dlp https://www.youtube.com/watch?v=6U_Zk_PZ6Kg

接著我使用 Whisper 產生逐字稿：

VIDEO_FILE="~/LLMs\ are\ weird,\ over-confident\ intern\ ｜\ Simon\ Willison\ (Datasette)\ \[6U_Zk_PZ6Kg].webm"
whisper $VIDEO_FILE

我的 NixOS 系統的 CUDA 設定未知原因失效了，所以 Whisper 只能使用 CPU，速度很慢且容易出錯。我使用 Google Gemini 2.5 Pro Preview 來清理它：

Split this transcript into sections by topic.

Under each topic, write the timestamp that the section covers in the transcript.

Break groups of sentences into logical paragraphs under each heading.

Fix words that appear to be transcription errors, but don't editorialize or
change language.

```
1
00:00:00,000 --> 00:00:06,000
call it my weird intern. I'll say to my wife Natalie sometimes, hey so I got my weird intern

2
00:00:06,000 --> 00:00:10,800
to do this. And that works, right? It's a good mental model for these things as well because

[elided...]

```

Gemini 一次只能處理約 30 分鐘的逐字稿，之後就會耗盡輸出 token，因此我必須在指令結尾加上 Start at 00:26:26,240 來反覆執行。

接著我將所有格式化後的逐字稿彙整在一起。

這樣就產生了一份像這樣的、組織良好的逐字稿：

### The Efficiency and Benefits of Consistent Blogging
(00:08:44,480 --> 00:11:24,800)

Well, that's the secret of blogging, is that it takes a lot of work at first,
but I've been blogging for 22 years...

接著我將我的筆記餵給 Gemini 2.5 Pro，並使用以下提示：

Here is a transcript of an interview that's available on YouTube
at https://www.youtube.com/watch?v=6U_Zk_PZ6Kg:

```
SRT TRANSCRIPT GOES HERE
```

Here are  my notes about the interview:

```
MARKDOWN VERSION OF THIS BLOG POST GOES HERE
```

Reproduce the headers in my notes, but under each, include a link to the
original YouTube video that the transcript came from with a timestamped link
that points to that part of the conversation.

我想驗證所有直接引用的內容是否都準確，但找不到好的解決方案。我最初嘗試提示 Gemini Pro 和 Flash 產生 ffmpeg 指令，將影片剪輯成只包含引用的片段，但它總是做錯。我又嘗試了一個較保守的方法，請它在每個引言後面加上帶有時間戳記的 YouTube 連結，但時間總是差了幾分鐘。最後我乾脆手動處理，透過搜尋 SRT 檔案再跳到影片中的對應時間點。在其中一個例子中，Gemini 完全改寫了西蒙·威利森的措辭，但大致上它還是相當準確地還原了引文。

連結

原文由 Michael Lynch 于 發布

本文章由 muse-spark-1.2-contributor 進行翻譯