非工程师因不满笔记应用难导出，自己开发文档编辑器

我得先说明，我不是软件工程师。我在医疗行业工作。写代码只是爱好——考虑到我最近在这上面花了多少时间，承认这一点多少有点难为情。

前阵子，我想把自己的笔记从某个知名笔记应用里导出来。这些年我攒下了大量医疗笔记，想把它们变成更有用的东西。这看起来应该是个挺简单的活儿。

结果并不简单。

发现把自己写的文档从这个应用里弄出来，比放进去要难得多之后，我开始寻找替代方案。市面上有一些很出色的笔记应用，但没有一个完全符合我的需求。

于是，出于一种严重不成比例的反应，我决定自己做一个。

这本来是为了解决一个相当简单的问题：我希望我的文档是真正的文件，可以自己保存、移动，并在手边任何一台电脑或平板上打开。

然后我开始琢磨，在维护大量技术笔记这件事上，还有哪些地方让我不爽。

为什么我不能在一个页面上声明一个变量，然后在另一个页面上把它用于计算？为什么引用不能指向一个实际的对象，而只是一段可能还存在、也可能已经不存在的文字？为什么文档不能告诉我，我算出的某个结果已经过时了？

而且，既然我要在里面放一个 AI 助手，它凭什么只能生成文字？为什么它不能理解文档的结构、查找信息，并提出实际的修改建议？

这些问题看起来都挺合理。

不幸的是，要回答它们，需要构建的基础设施多得出乎意料。

成果就是 Bookend，一个文档编辑器，它已经彻底超出了最初项目的范围。

我花了很多时间思考如何让它高效运行、如何保持其行为可预测，以及如何避免那个常见的陷阱——每加一个功能就把软件搞得更复杂。

有些解决方案相当常规。另一些则比我预想的难得多。还有几处是我特别满意的。

所以我想写一写它是怎么工作的、我遇到了哪些问题，以及我为什么做了某些决定。

让文档不只存储文字，麻烦在于：看似简单的功能，往往会变成出奇困难的工程问题。

就拿变量这种看似无害的东西来说。

我希望能够在一个页面上声明一个值，然后在别处引用它。比如临床参考中的诊断阈值，或者小说中某个角色的年龄。改变原始值，任何依赖它的东西都应该知道有东西变了。

这很容易，直到这本书有 800 页、数千个引用，而且计算还依赖其他计算。

这时编辑器就需要理解可能相隔数百页的对象之间的关系。它需要识别一个值何时发生了变化，算出哪些东西依赖它，检测循环引用，并在之前计算出的结果不再可信时告诉你。

而且它需要在每次你改一个数字时，不必加载和渲染全部 800 页。

最后这条要求对我来说尤其重要。我一直不理解，为什么显示一个文档就需要应用消耗大量内存和 CPU 时间。我希望 Bookend 轻量，但我不打算通过牺牲功能或让界面难用来实现这一点。

于是我得到了两个方向相反的要求：整本书需要作为一个相互关联的计算对象来运作，而界面应该只需要关心你实际使用的那一页。

然后是计算过时了怎么办的问题。

大多数时候，自动重新计算公式听起来是合理的。但如果计算开销很大呢？如果它依赖一个 AI 模型呢？如果你六个月后打开一个文档，发现它的内容因为某些后台运行的东西而悄悄变了呢？

我不想要那样。文档应该能够保留它之前计算出的结果，在结果过期时告诉你，并让你决定何时刷新。尤其是，打开一本书绝不应该意外触发一次 AI 推理调用。

让 AI 助手真正有用，又带来了另一组问题。

把一个语言模型连接到文本编辑器上让它生成段落，相对容易。但我希望助手能理解这本书的结构。它应该能够找到一张表格、查看其内容、查阅表达式语法，并给出一个仍然与其源数据保持连接的公式。

这意味着 AI 需要能够访问与用户相同的底层文档操作。这也意味着要给它足够的自由度以发挥作用，同时又不允许一条幻觉出来的指令悄悄毁掉一份精心维护的文档。

最后，我希望这一切都能离线工作，跨不同的操作系统，不需要 Bookend 账号，也不需要专有的同步服务。一本书应该是你拥有的文件。如果你在两台设备上编辑它，应用应该认真努力地保留两边的修改，而不是简单地让最后一次保存获胜。

这些问题没有一个是全新的。编译器、电子表格、数据库和分布式系统几十年来一直在处理它们的各种变体。但把这些思想结合到一个文档编辑器里，同时让结果保持小巧、响应迅速且平易近人，结果证明是一个有趣的挑战。

一路上我走了几次弯路。有些功能需要的架构工作比我预想的多，有些早期实现运行得很漂亮，直到我拿自己那本实际的、巨大的笔记本去试。

但渐渐地，一种一致的方法浮现了出来。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）