← #813

持久软件的缓慢成形

文章摘要

这篇文章发表在历史学家 Dan Cohen 的通讯「Humane Ingenuity」上，写于文献管理软件 Zotero 1.0 发布 20 周年（2006 年 10 月 5 日）之际。Zotero 是一款免费开源的研究工具，用来收集、整理、标注、引用和分享研究资料，如今已有超过 2000 万用户。Cohen 是它的早期缔造者之一，他借回顾 Zotero 的「史前史」提出一个与当下 AI 编程潮流形成对照的观点：今天的软件可以靠 AI「几乎瞬间」生成，而 Zotero 从萌芽到第一个粗糙原型却花了五年。他认为，即便 2000 年代初就有 AI，也加速不了 Zotero 的构思——因为团队当时根本不知道自己想要什么，自然也写不出连贯的提示词。正是这种缓慢、集体式的思考，造就了一个可以长期在其上构建的坚实基础。

故事的主角是乔治梅森大学「历史与新媒体中心」（后以创始人 Roy Rosenzweig 命名）的一群会写代码的历史学家，编程对他们来说只是副业技能：

两个前身：2001 年前后，Cohen 用 PHP 写了 Web Scrapbook，学生可以通过一个书签小工具把网页上的图片、链接收进可共享的收藏夹（他自嘲初版连密码都是明文传输）；同事 Elena Razlogova 则用 FileMaker 做了桌面应用 Scribe，用于做笔记和管理引文，成了历史学者圈里 EndNote 的免费替代品。
想要「两全其美」：到 2003 年，团队意识到网页应用和桌面应用各有不足。研究越来越多地发生在浏览器里，他们想要一个既能独立于网页存在、又能「感知」浏览器里正在发生什么的研究工具。Elena 列出了 Scribe 下一版的愿望清单，Tom Scheinfeldt 提出要把 Scribe「网络化」（webify），但怎么实现当时毫无头绪。
Firefox 带来的转机：2004 年 11 月 9 日 Firefox 正式发布当天，Cohen 和 Josh Greenberg 就开始研究它的 XUL 扩展机制，意识到可以随心所欲地扩展浏览器。Cohen 当晚发邮件提出「Firefox + XUL + 亚马逊图书 API」的组合，Greenberg 午夜前回信大呼「太酷了」。
从 SmartFox 到 Zotero：他们向美国博物馆与图书馆服务署（IMLS）申请经费，项目名为「SmartFox：面向数字馆藏的学者浏览器」。少年天才 Simon Kornblith（后来在 MIT 读博、与 Hinton 合写论文、加入 Anthropic）和 David Norton 在 2005 年 7 月做出 0.0.1 版原型；Kornblith 留意到 Firefox 将内置 mozStorage（后来是 SQLite）作为本地数据库。2006 年初，至今仍是 Zotero 首席开发者的 Dan Stillman 加入，开发随即提速。
起名风波：项目一度改名「Firefox Scholar」，律师警告任何带 Firefox 的名字都有问题。团队想过 iScholar、Scholr、Citopia、CiteHound、FireHoard 等一堆如今看来很好笑的名字，最后听从同事建议翻阅阿尔巴尼亚语词典，选中了意为「精通、学好」的 zotero。

Beta 版发布一个月就有 6 万用户，此后梅隆基金会和斯隆基金会的资助让它支持团队同步，并最终脱离 Firefox 独立运行。文中也带着伤感：创始人 Roy Rosenzweig 在 2007 年 57 岁时因病去世。Cohen 的结论是：Zotero 的价值从一群历史学家友好的集体思考中缓慢生长出来，因而格外持久；在编程日益变成「与魔法机器人一起的咖啡因狂欢」的今天，这种节奏或许值得借鉴。

HN 评论精华

讨论几乎全部围绕「AI 加速开发与慢工出细活」展开，另有一条支线是 Zotero 用户的使用心得。

AI 能否加速「想清楚要做什么」

ghoshbishakh 说自己就因为用 AI 加功能太容易而毁掉过整个项目——vibe coding 很难不塞进一堆没用的功能。josephg 补充：LLM 很不擅长删代码，加了功能再让它去掉，代码库还是只增不减；但它们做原型非常好，而原型恰恰能帮你避免实现错误的功能。
lmz 认为文章所说的「坚实基础」其实是产品设计，而非代码，今天完全可以让代理参考已有产品去构建。scruple 反驳这是偷换概念：Scribe 和 Web Scrapbook 演进中真正困难的，是发现「浏览器扩展 + 本地 SQLite」是唯一能同时满足离线持久化和跨任意目录抓取网页的架构。代理可以综合现有方案，却无法为提示者自己都还没理解的矛盾找到架构；在 2003 年说「参照 Scribe 和 Web Scrapbook 做个工具」，只会得到一个脆弱的 PHP 包装。随后 scruple 与 TeMPOraL 就「LLM 是否真的在语义空间里工作」展开了一段哲学争论。
kstenerud 则认为作者描述的就是典型的大项目生命周期（调研、用户研究、头脑风暴、原型、迭代……），LLM 在调研、原型和整理用户反馈上都很擅长，并不排斥这个过程。mmarian 回应：它也可能让人沉迷于试验那些很容易做出来的功能，反而拖慢进度。doug_durham 更直接地说这是对起源故事的浪漫化，LLM 很可能把 5 年压缩成 5 个月；jjuel 反问：LLM 也会以极快速度把你带上一条你并不想走的路，来回折腾几次之后真的省时间吗？
peterbell_nyc 把开发循环拆成「讨论该做什么 / 构建 / 使用验证」三步，认为 LLM 肯定加速第二步，也许能加速第一、三步；skydhash 反驳说用 LLM 加速构建的人往往对第一步想得不够、对第三步很快就厌倦，好的软件通常从一个小循环开始逐步增长——「想造房子，先盖小屋，而不是大教堂」。epihelix 认为完全可以用代理「慢而稳」地开发，存在一条既不是手工精雕、也不是一次性生成垃圾的中间道路。

质量与速度

ORDINAND_PIZZA 用种子长成大树作比喻，断言「快速做出好东西是不可能的」。_fw 不同意，举出一个下午写成的好歌为例；TeMPOraL 以二十年职业经验补充：大多数好东西都是快速做出来的，没有交付压力，聪明的程序员会永远打磨下去，直到软件失去意义；高质量的软件之所以好，是因为范围和时间一开始就被限定了。
_fw 从增长和获客的角度指出，文中「不知道想要什么，就写不出提示词」这句话非常关键：大量产品是「拿着解决方案找问题」，而 Zotero 的成功在于真正关注了用户需要什么。
jkhdigital 认为这篇文章「学院气」很重：Zotero 的用户主要是不面对市场竞争的学者，工程师必须懂得时间也是要被衡量的资源。
sdevonoes 质疑「如今软件几乎可以瞬间生成」的说法：在上千名工程师的公司里，一个中大型功能有一半工作量涉及其他团队的协调、设计文档和审批，AI 不是魔杖；在缺乏经验的人手里，它甚至会拖慢事情。

Zotero 用户心得

nickledave 热情推荐 Zotero，说它「用起来就是享受」，能读书、抓取网页快照、多端同步。cxr 作为重度用户则说，「开箱即用」并不准确，它大多数时候还算好用，但也有毛病，而且越来越难构建，参与贡献的门槛变高了。
有人担心数据锁定，freeone3000 和 pajamasam 回答：支持 CSV、XML、LaTeX 导出，开源、本地优先，可以用自建 WebDAV 同步附件，背后是非营利组织。Almondsetat 抱怨想在院系里自建完整的 Zotero 同步服务器很麻烦，WebDAV 只同步附件不同步一切。
anon7725 指出一个与时事相关的细节：当年资助 Zotero 的 IMLS 在 2025 年 3 月被特朗普的行政令几乎裁撤，后经诉讼才获得法院临时禁令。
还有个小插曲：aeve890 问「durable」是不是最近的流行词，feanaro 回答这是 LLM 特别偏爱的词，因此常出现在 AI 写的博文里。