Blog Dice

Notes from Simon Willison's Interview on Software Misadventures

Michael Lynch

Simon Willison 做客《Software Misadventures》访谈笔记

原文由 Michael Lynch 于 发布，订阅该博客

刚听完Simon Willison 在《Software Misadventures》播客上的访谈，收获很多，所以整理了一份笔记。

这不是对整场访谈的完整总结，只记录了对我来说比较新的、或值得记住的部分。

做客《Software Misadventures》播客的 Simon Willison

Simon Willison 是谁？

插件：一种开源贡献形式

原始讨论

  • 将应用设计为可通过插件扩展功能，是一种比接受开源贡献摩擦更低的协作方式。
    • 外部协作者无需你审核或批准就能添加功能，你也不必为他们的代码负责维护。

插件最棒的地方在于，它让你构建开源项目时，无需审核别人的代码就能为项目增加功能。我可能一觉醒来，发现我的软件多了一项新功能，只因为有人发布了一个插件。

【编者注：我觉得这个观察很有意思。我从未设计过支持插件的软件，但 Simon 为这种架构提供了非常有力的理由。】

大语言模型

培养使用大语言模型的直觉

原始讨论

  • 大语言模型看似好用，实则很难用好，因为其局限性并不直观。
    • 它们看起来只是聊天机器人，似乎很简单，但你需要在各种任务上使用数小时，才能逐渐摸清它们能做什么、不能做什么。
    • 例如：大语言模型不擅长计数，这很反直觉，毕竟计算机通常非常擅长计数。
  • Simon 推荐阅读 Anthropic 的提示词工程文档，以有效提升使用大语言模型的能力。
  • Simon 建议用可本地部署的模型来学习（例如 Phi-3、Llama 3.1），因为它们更容易产生幻觉、犯错，能让你更清楚地认识到大语言模型不擅长什么。

Simon 如何使用大语言模型

原始讨论

  • 信息总结
    • 利用长上下文窗口来加速研究。例如，要研究某个人，可以把他的维基百科页面、相关报道和他的作品一股脑丢进对话，让大语言模型总结关键主题并给出例子。
    • 要求提供直接引用，并核对原始来源，以确认大语言模型没有虚构引用。

      如果我的朋友读完维基百科页面后能回答我的问题，那我知道大语言模型也能回答这个问题。但如果维基百科页面很可能不会涉及这类内容，大语言模型就不太可能答得上来。

  • 在自己擅长的领域内提问

    我会问它一些法律问题，比如把服务条款贴进去，然后问：“这里面有没有什么可疑的地方？”

    我很清楚这其实是个馊主意，因为我根本不懂法律，对吧？所以我只是在跟它演戏、随声附和，但我绝不会根据从大语言模型那里得到的法律建议去做影响人生的决定，因为我不是律师。

    如果我是律师，我会一直用它们，因为我可以依靠自己的专业知识来确保自己是以负责任的方式在使用它们。

  • 编写 SQL 查询
    • Simon 建议把完整的数据表结构和几行示例数据都提供给大语言模型。
  • 数据录入
    • 例如，从手写笔记中转录信息，或从非结构化文档中提取结构化数据
    • 最强的大语言模型准确率约为 95%，大致相当于雇一组人类实习生来做同样工作的水平。
  • 做软件架构决策
    • Simon 会让大语言模型为同一个任务提供多种实现方案，并逐一讨论其优缺点。
  • 阅读学术论文
    • Simon 写了一个名为 Dejargonizer 的工具，用于解释不熟悉的术语。
    • 【编者注：我觉得这个工具更多是个有趣的点子，而非真正实用的工具。需要手动粘贴文本，我在塞入一篇 5 页的论文时就耗尽了上下文长度。如果能直接重写文本，并在行内解释专业术语，会更合理。】

Simon 的“怪实习生”心智模型

原始讨论

  • Simon 向妻子形容大语言模型是他的“怪实习生”。

    就像有个实习生……背下了所有编程语言的文档，却又是个狂热的阴谋论者，有时会冒出荒诞的想法……而且极度自信。

  • 相比人类同事，大语言模型的一大优势在于你可以不断让它改进方案。
    • 和人类同事合作时，你总得适可而止，不能无休止地要求对方迭代，因为你不断想出新点子去改进一个 pull request 会让人感到沮丧；但对大语言模型，你可以要求它大幅重写，而不必担心浪费对方的时间。
  • Simon 发现，只要对大语言模型说一句“做得更好一点”，就能让它改进回答：

    我最喜欢的提示词之一就是直接说“做得更好一点”，居然真的管用。这太疯狂了！

    它写完一段代码，你说“做得更好一点”，它就会说“哦，抱歉”，然后吐出更好的代码。这项技术居然是这么运作的，蠢得可笑，但也挺有趣的。

大语言模型让以往不值得投入的项目变得可行

原始讨论

  • 大语言模型对 Simon 的一大影响是让他作为开发者变得更有野心。
    • 以前，他想到一个项目，意识到最合适的实现语言是 AppleScript 或 Go，就会因为自己不懂这些语言而搁置想法。
    • 现在，他可以借助大语言模型生成代码，并验证其是否符合预期。
  • 这些技术他以前也能学，但大语言模型把入门门槛降得足够低，让这些项目变得更具可行性：

    没有大语言模型，这些小项目根本不会存在。不是因为我做不出来，而是因为我做得不够快，不值得为此付出精力。

如何跟上大语言模型的发展

原始讨论

  • 信息含金量最高的来源是约 15 人规模的私人 WhatsApp 和 Discord 群组。
  • Twitter 上有不错的 AI 讨论。
    • Mastodon 则不然，因为它吸引的多是 AI 怀疑论者。
  • 得益于他的博客，人们经常会向他提供关于大语言模型新动态的线索。

为什么大语言模型未必会用糟糕的代码污染世界

原始讨论

  • 大语言模型的弊端在于，一些连作者自己都不理解的代码被部署到了生产环境。
    • 这对整个世界都是风险，意味着大语言模型会拉低整体软件质量。
  • Simon 指出，世界上大量正在运行的代码，比大语言模型生成的“浆糊”代码还要糟糕：

    我们如今生活在一个世界里，半个世界都靠没有任何单元测试、没有备份、没有版本控制的 Excel 表格运转……任何人都可能搞乱一个公式，一家公司的估值一夜之间就腰斩……

    这就是我们今天所处的世界，对吧？Excel 表格本身就已经是一团浆糊了，可社会照样运转。

    所以，也许我们这些坚持“每一行代码都必须完美”的人，可能是错的。也许浆糊才是未来的方向，但这有点让人害怕，你知道吗？

博客写作

每天写一篇博客

原始讨论

时间投入

原始讨论

  • Simon 每天花 10 到 15 分钟写博客。
  • 由于已经坚持了 22 年，他的写作速度也越来越快。

从博客到邮件通讯的流程

原始讨论

  • Simon 有一份邮件通讯，内容就是自上一期以来博客上所有新增内容的差异汇总：

    这是一种非常好的方式，能把内容推送给那些常驻邮箱的人。

  • Simon 写了一个 Observable 笔记本，可以拉取博客内容并转换成兼容 Substack 的富文本。然后他从笔记本中复制到 Substack 并发出通讯。
  • 他在 Substack 上有 6000 名订阅者。
  • 整个流程每期只需两分钟。

【编者注：Simon 没有谈到这一点，但我认为他这种同步到 Substack 的方式会对 SEO 产生负面影响，因为同一内容在不同 URL 上出现了两份，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 时，不得不读完数百条评论，而不是只看一条总结当前状态的评论。】

“时效性”文档与“现状”文档

原始讨论

  • Simon 认为软件有两种文档。
    1. 说明软件当前功能的文档。
    2. 描述撰写时软件状态、但今天未必仍然准确的文档（“时效性文档”）
  • GitHub issue 很适合用作时效性文档。
    • Simon 可以查看 issue 的创建日期，以判断文档在何时是准确的。
  • 对于必须与代码保持一致的文档，他会将其作为 Markdown 文件与代码放在同一仓库中，并确保每次更新代码时同步更新文档。

作为独立开发者的生活

原始讨论

  • Simon 第一次尝到独立工作的滋味，是在斯坦福获得了一份为期一年的带薪数据新闻研究员职位时。

    那太棒了，也彻底“毁”了我，因为他们付钱让我花一年时间去做任何我觉得最有趣的事。

    一旦体验过，再想回去让别人……来规定你要做什么，就非常困难了。所以问题就在于，我体验了一年的自由，然后想，“我不想放弃这种自由。我做这些事太开心了。”

时间管理

原始讨论

  • Simon 发现决定做什么极其困难，因为相比为雇主工作，几乎没有外部压力或问责。
    • AI 领域有太多有趣的方向值得探索，也没有任何东西阻止他一直探索下去。
  • 他有时甚至希望自己有风险投资人，这样就有人能督促他专注于目标。
  • 会议驱动开发
    • Simon 会承诺在某个会议前实现某些功能，这迫使他按时优先完成开发。
  • 周记

迈向财务自由

原始讨论

  • Simon 渴望实现财务自由。
    • Eventbrite 在 Simon 的创业公司仍处于成长期时收购了它，随后他在那里担任了六年的工程总监。
    • 他拥有“可观的资金储备”，但还没到完全无需担心收入的程度。
    • 在 Datasette 产生足够收入、成为主要收入来源之前，他正通过咨询工作来维持收入。

【编者注：整场访谈中最让我意外的是，Simon 居然还没有实现财务自由——我原本以为他已经实现了。】

Datasette 的目标

原始讨论

  • Simon 对 Datasette 的目标是，有记者使用 Datasette 辅助撰写出一篇赢得普利策奖的报道。
  • 他希望能组建一个团队与他一起做这个项目，因为独自工作让他感到孤独。
  • 他想效仿 WordPress 的模式，开源代码，并通过提供托管服务来盈利。

在数据新闻中使用大语言模型的挑战

原始讨论

  • 所有主流大语言模型都会对信息进行审查，这让数据新闻工作变得更困难。

如果你是一名记者，你处理的一些原始材料是很棘手的，对吧？比如关于暴力事件的警方报告、法西斯留言板……现在，如果你让大语言模型来帮忙处理这些材料，比如让它总结这个法西斯公告板的主题，它会直接说“不行”，对吧？

很多大语言模型会直接拒绝处理这类内容，这……极大地限制了它们的实用性……

幕后：我如何整理这些笔记

我用 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 完全改写了 Simon 的措辞，不过总体来说引用的准确度还是挺高的。

相关链接

本文章由 muse-spark-1.2-contributor 进行翻译

评论