Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Simon Willison 在《Software Misadventures》訪談中的筆記

原文由 Michael Lynch 于 發布，訂閱此部落格

我剛聽完Simon Willison 在 Podcast《Software Misadventures》上的訪談。我從這次訪談中學到很多，所以整理了一份筆記。

這不是整場訪談的完整摘要，只整理了對我來說比較新的、或是我想記下來留存的部分。

Simon Willison 在Software Misadventures Podcast 上

Simon Willison 是誰？

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

原始對談片段

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

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

[編按：我覺得這是個很有趣的觀察。我從來沒有設計過支援外掛的軟體，但 Simon 對這種架構提出了非常有力的論點。]

LLM

培養對如何使用 LLM 的直覺

原始對談片段

  • LLM 看似好用，實際上卻很難真正掌握，因為它的限制並不明顯。
    • 它們看起來只是聊天機器人，好像很簡單，但你需要在各種任務上實際使用好幾個小時，才能培養出對它能做什麼、不能做什麼的直覺。
    • 例如：LLM 很不擅長數數，這很令人意外，畢竟電腦通常很會計算。
  • Simon 推薦 Anthropic 的提示工程文件，認為這是有效提升 LLM 使用技巧的方式。
  • Simon 建議用可在本地端運行的模型來學習（例如 Phi-3、Llama 3.1），因為它們更容易產生幻覺、犯錯，你反而能更快掌握 LLM 不擅長什麼。

Simon 如何使用 LLM

原始對談片段

  • 整理資訊摘要
    • 利用長脈絡視窗（long context window）來加速研究。例如，要研究某個人時，把他的維基百科頁面、相關報導和他的著作全部丟進對話中，再請 LLM 整理出關鍵主題並附上範例。
    • 要求提供直接引文，並核對原始來源，確認 LLM 沒有幻覺捏造引文。

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

  • 在你具備專業知識的領域中提問

    我會問它一些法律問題，像是把服務條款貼上去，然後問：「嘿，裡面有沒有看起來有點可疑的地方？」

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

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

  • 撰寫 SQL 查詢
    • Simon 建議把完整的資料表結構（table schema）和幾筆範例資料一起提供給 LLM。
  • 資料輸入
    • 例如，從手寫筆記轉錄資訊，或從非結構化文件中擷取結構化資料
    • 最強的 LLM 大約能達到 95% 的準確率，這大概跟你雇一群人類實習生來做同樣工作所能達到的水準差不多。
  • 做出軟體架構決策
    • Simon 會請 LLM 針對同一個任務提供多種不同的做法，再一一討論各自的優缺點。
  • 閱讀學術論文
    • Simon 寫了一個名叫 Dejargonizer 的工具，用來解釋不熟悉的術語。
    • [編按：我覺得這個工具比較像是個有趣的點子，實際上不太實用。你得貼上文字，而我光是餵進一篇五頁的論文就把脈絡長度上限用完了。如果能直接把原文重寫、把術語定義內嵌在行文中會更合理。]

Simon 的「古怪實習生」LLM 心智模型

原始對談片段

  • Simon 向太太形容 LLM 就像是他的「古怪實習生」。

    就像有個實習生，背熟了所有程式語言的文件，卻又是個瘋狂的陰謀論者，有時會冒出很荒謬的點子，而且還超級有自信。

  • 比起人類隊友，LLM 的一大優勢是你能不斷要求它改進解決方案。
    • 跟人類隊友合作時，你總得適可而止，不能一直要求新的修改版本，因為一直想出新點子要對方改 pull request 會讓人很挫折；但對 LLM，你可以要求它大幅重寫，完全不用擔心浪費它的時間或不尊重它。
  • Simon 發現只要對 LLM 說一句「做得更好一點」（Do better），就能讓它改進答案：

    我最喜歡的提示詞之一就是只說一句「做得更好一點」，而且居然真的有效。這太瘋狂了！

    它會先寫一段程式碼，然後你說「做得更好一點」，它就會說「啊，抱歉」，接著吐出更好的程式碼。這個技術居然是用這種愚蠢的方式運作，真的很荒謬，但也滿有趣的。

LLM 讓那些原本不值得投入的專案變得可行

原始對談片段

  • LLM 對 Simon 帶來的一大影響，是讓他身為開發者變得更有野心。
    • 以前他想到一個專案，意識到最適合的語言是 AppleScript 或 Go，就會因為自己不會這些語言而把點子擱置。
    • 現在，他可以用 LLM 來產生程式碼，再驗證它是否符合自己的需求。
  • 這些技術他以前本來也可以學，但 LLM 把入門門檻降得夠低，讓這些專案變得更實際、值得去做：

    所有這些小專案，如果沒有 LLM 就不會存在。不是因為我做不出來，而是因為我沒辦法做得夠快，快到足以證明投入這些心力是值得的。

如何跟上 LLM 的最新發展

原始對談片段

  • 訊號品質最高的資訊來自約 15 人左右的私人 WhatsApp 和 Discord 群組。
  • Twitter 上有很不錯的 AI 討論。
    • Mastodon 則沒有，因為那裡吸引的多是 AI 懷疑論者。
  • 因為 Simon 的部落格，人們也常會主動提供他關於 LLM 新發展的有趣情報。

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

原始對談片段

  • LLM 的缺點在於，許多連作者自己都不理解的程式碼就這樣被部署到正式環境中。
    • 這對全世界來說是個風險，因為這意味著 LLM 可能會拉低整體軟體品質。
  • Simon 指出，世界上有許多系統所依賴的程式碼，比 LLM 產生的那種「黏糊糊的」（goop）程式碼還要糟：

    我們現在活在一個世界裡，世界有一半是靠沒有單元測試、沒有備份、沒有版本控管的 Excel 試算表在運作，任何人弄錯一個公式，公司估值就可能一夜之間腰斬……

    這就是我們現在生活的世界，對吧？Excel 試算表本身就已經夠黏糊了，但社會還是照樣運作。

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

寫部落格

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

原始對談片段

  • Simon 盡量每天都寫一篇新的部落格文章。

時間投入

原始對談片段

  • Simon 每天花 10 到 15 分鐘寫部落格。
  • 因為已經寫了 22 年，他現在寫得更快了。

從部落格到電子報的流程

原始對談片段

  • Simon 的電子報其實就是自上次發報以來，他部落格上所有新增內容的差異彙整（diff）：

    這是讓那些整天待在電子郵件收件匣裡的讀者也能看到內容的絕佳方式。

  • Simon 寫了一個 Observable 筆記本，會從他的部落格抓取內容並轉換成 Substack 相容的富文字格式。然後他再從筆記本複製到 Substack 並發送電子報。
  • 他有 6,000 位 Substack 訂閱者。
  • 整個流程每份電子報只要花兩分鐘。

[編按：Simon 沒有提到這一點，但我認為他這樣同步到 Substack 的方式會對 SEO 造成負面影響，因為同樣的內容會在不同網址出現兩份，Google 就無法判斷哪一個才是原創。]

[編按：我也覺得很意外，Simon 用的是 Substack 的網域，而不是使用 simonwillison.net 底下的某個子網域，因為我認為 Substack 應該有支援自訂網域。]

部落格基礎架構

原始對談片段

  • Simon 的主要部落格是一個跑在 Heroku 上的服務，前方以 Cloudflare 作為 CDN。

Cloudflare 最棒的地方在於，如果流量突然暴增，例如被放到 Hacker News 首頁，我那個便宜又小小的 Heroku 執行個體根本不會有感覺，因為所有流量都被 Cloudflare 擋下來、吸收掉了。

Bing Chat 事件

原始對談片段

把所有事情都變成 GitHub Issue

原始對談片段

  • Simon 把個人的待辦清單都當成 GitHub issue 來管理。
  • 他維護著 250 個專案。
    • 他記錄文件時，假設自己會忘掉每一個細節。

      我可以回到一個一年沒碰的專案，把文件當作我完全不知道這個專案是什麼來閱讀，然後就直接開始工作。

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

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

[編按：這是個令人意外的工作流程，因為它犧牲了讀取的便利性來換取寫入的便利。當你想了解某個 issue 時，你被迫要讀完整串上百則留言，而不是只讀一篇總結現況的留言。]

「暫時性」文件 vs. 現行文件

原始對談片段

  • Simon 認為軟體有兩種文件。
    1. 說明軟體目前功能的說明文件。
    2. 描述文件撰寫當下軟體功能的紀錄，但到了今天不一定還準確（「暫時性文件」）
  • GitHub issue 很適合用來做暫時性文件。
    • Simon 可以透過 issue 的建立日期，來判斷那份文件是在什麼時候是準確的。
  • 對於必須與程式碼保持一致的文件，他會以 Markdown 檔案的形式放在與程式碼同一個儲存庫中，並確保每次更新程式碼時都會同步更新文件。

作為獨立開發者的生活

原始對談片段

  • Simon 初次嚐到獨立工作的滋味，是在史丹佛大學獲得為期一年、有給薪的資料新聞學研究獎學金時。

    那真的太棒了，也徹底把我給毀了，因為他們付錢讓我花一年的時間去做任何我覺得最有趣的事。

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

時間管理

原始對談片段

  • Simon 發現要決定該做什麼非常困難，因為相較於受雇於人，幾乎沒有什麼外部壓力或責任來約束他。
    • AI 領域有太多有趣、值得探索的方向，也沒有任何東西阻止他一直探索下去。
  • 他有時甚至希望自己有創投投資人，這樣至少有人會讓他專注在目標上。
  • 會議驅動開發
    • Simon 會承諾在研討會前完成某些功能，這迫使他必須在期限前優先完成實作。
  • 週記（weeknotes）

邁向財務獨立

原始對談片段

  • Simon 渴望達到財務獨立。
    • Eventbrite 在 Simon 的新創公司還在成長時就將其收購，之後他在那裡擔任工程總監長達六年。
    • 他擁有「相當充裕的緩衝資金」（substantial runway），但還不到可以完全不必擔心收入的程度。
    • 在 Datasette 能產生足夠收入、成為主要收入來源之前，他正尋求顧問工作來維持收入。

[編按：整場訪談中最讓我驚訝的是，Simon 居然還沒有達到財務獨立，因為我本來以為他已經達到了。]

Datasette 的目標

原始對談片段

  • Simon 對 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\ your\ 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 完全改寫了 Simon 的用詞，但大致上引文都還算準確。

相關連結

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

留言