Bom dia meus amigos，

Saudações de Lisboa!

您正在阅读的《壹苇可航》电子报 2025 年第 42 期。

这周看到一份大学时的笔记，文件开头是密密麻麻的 YAML，段落之间散落着 :: 标记，还有一串串 TN_abc123 这样的 ID。我盯着屏幕愣了一会儿，分不清这是我当年写的文字，还是某个数据库的导出日志。

更困扰的是，即使能看懂每个字符，我依然无法完整理解这份文件。那些 [[双链]] 指向的内容早已迭失，file-id 脱离系统后只是无意义的字符串，而 ::状态/进行中 这样的标记，需要我回忆起当时使用的那套语义系统。

文件在技术上仍然「可读」，但它已经从文本变成了数据的化石。

这让我开始重新思考：当我们把越来越多的元数据塞进文本文件时，究竟在做什么？我们以为在「更好地组织知识」，但实际上，是否正在将写作（本文所说的「写作」，泛指一切思想的文字记录，包括正式写作、日常笔记、思考片段等）变成数据录入？

本期我们就来聊聊这个话题。

以下是本期正文

🔍 Insight

Markdown 诞生时的承诺很简单：用最自然的符号表达格式，让文件即使不渲染也清晰可读。# 是标题，* 是强调，> 是引用。这些约定轻盈、直观，不妨碍思维的流动。

LaTeX、Org-mode 也是如此。它们都是纯文本格式，都是为了让写作者能够专注于内容本身，用字符标记代替鼠标点击。这些格式的共同点在于：它们服务于写作，而非服务于系统。

但现在打开很多工具导出的 .md 文件，看到的却是这样的景象：


# 标题一
::priority/high

这是一段 [[内部链接]] 的文字。

## 标题二
::category/笔记

这些 YAML front matter、:: 属性、[[双链]] 语法，它们的首要读者是谁？是人吗？

不，是系统。

人需要 file-id 吗？需要 ::status/进行中 吗？这些信息的存在，不是为了让文字更易读，而是为了让系统能够重建数据关系、执行查询、生成图谱。

写作格式被异化成了数据格式。

纯文本（plain text）不是单指 .txt 扩展名（虽然它是最纯正的代表），而是指「人类可读的字符序列」。从这个意义上说，Markdown、LaTeX、Org-mode 都是纯文本格式。它们的设计哲学是：即使没有专用编辑器，普通文本编辑器也能打开、阅读、编辑。

这种「可读性」不仅是技术层面的字符编码兼容，更是认知层面的符号语义清晰。当我们看到 # 标题，即使不知道 Markdown，也能猜到这是个标题；看到 \section{Introduction}，即使不懂 LaTeX，也知道这在划分章节。

但当纯文本被塞进系统级的元数据，这种「认知可读性」就瞬间瓦解了:

  • file-id: TN_abc123 对人类毫无意义，只有系统能理解
  • [[双链]] 的归宿依赖于特定工具的文件索引
  • :: 属性标记需要记住某个工具的语义规则

这些不是写作标记，而是数据库字段。

元数据本身并非罪恶，但一定要有清晰的边界。

静态网站生成器，如 Hugo、Astro 使用 YAML front matter 定义标题、日期、分类，这是合理的，因为：

  1. 这些信息服务于发布，而非写作过程
  2. 元数据与正文有清晰边界（用 --- 分隔）
  3. 即使去掉元数据，正文依然完整可读

但问题在于，当工具为了构建「知识图谱」，开始将元数据嵌入记录和写作过程本身时，边界就模糊了：

  • 我们需要为每个概念添加 [[双链]]，不然「无法建立联系」
  • 我们需要用 :: 标记属性，不然「无法查询筛选」
  • 我们需要维护 tags，不然「无法归类整理」

写作变成了数据录入。此时，我们面对的不再是一张白纸，而是一张表格。每写一段文字，都在潜意识里考虑：这个概念要不要做成卡片？这句话是否需要打标签？这个想法归属于哪个项目？

这种认知负荷，恰恰是纯文本写作试图避免的。

人们常说「专有格式会随软件消亡，而纯文本永存」。这句话对，但不全对。

纯文本之所以持久，不是因为 .txt 扩展名有魔力，而是因为它只依赖语言本身。只要计算机还需要与人类语言沟通，就必须理解字符编码。即便未来 UTF-8 被淘汰，新标准也必然兼容旧数据。这不是出于情怀，而是出于对历史记忆的需求。毕竟，任何断绝历史的系统，都难以长久。

标准 Markdown（CommonMark）、LaTeX、Org-mode 同样如此。它们的语法规则公开、稳定，不依赖特定软件的实现。即使工具更迭，文件本身的语义依然可解读。

但被工具方言扩展的格式就不同了。

不同工具对「元数据与写作的边界」有不同理解，形成了几种典型的设计模式：

  • 模式一：Wikilinks + Block ID

    • 使用 [[链接]] 简化引用，但依赖工具内部的索引系统
    • Block references 通过 ID 关联，离开工具后引用关系失效
    • 优点：写作时便捷
    • 缺点：迁移成本高

  • 模式二：内联属性

    • 使用 property:: value 将元数据散落在正文段落中
    • 模糊了文本与数据管理的边界
    • 优点：结构灵活
    • 缺点：侵入写作流程

  • 模式三：过度 Front Matter

    • 在 YAML front matter 中塞入大量系统级元数据
    • file-id、created、modified、内部状态标记等
    • 优点：元数据与正文分离
    • 缺点：过度使用让文件变成数据表格

这些扩展没有统一标准，完全依赖工具的私有解释。当我们更换工具，或者若干年后重新打开文件，那些曾经精心设计的「知识结构」，就变成了需要考古才能理解的符号。

形式上是纯文本，实质上是半结构化数据。

我一直有个习惯：无论个人写作还是工作文档，定稿都在纯文本编辑器里完成，再粘贴到发布页面或 Google Docs 中。在纯文本编辑器的环境里，只有文字和思维的流动，没有格式的干扰，也没有系统的要求。

当然，我也用云端笔记工具。我的笔记几乎全在 Tana 中，草稿和卡片多数在其中完成，因为它提供的结构化能力确实有助于深化学习、梳理思路。但一旦进入写作流程，我始终警惕一件事：不能让系统的组织逻辑反过来支配写作本身。

这就很像我认识的几位建筑师、设计师。他们画草图时，最初的构思常在餐巾纸上完成，而非直接在 CAD 软件里建模。草图阶段需要的是自由探索，而非精确约束。

写作也是如此。当我一边写一边考虑「这段话应该链接到哪个笔记」、「这个概念是否需要新建卡片」时，思维的流动性就被打断了。我不再是在表达思考，而是在为未来的检索系统录入数据。

越是结构化，思想越容易被框在格式里。越是精致的协议，文字越像机器的物料。

这里需要澄清一个容易混淆的概念：写作与知识管理，是两个不同的阶段。

写作阶段：

  • 核心是思想的涌现与记录
  • 需要的是流畅性、自由度、最小阻力
  • 文字应该服务于思维本身
  • 格式应该是轻量的、直觉的

知识管理阶段：

  • 核心是信息的组织与检索
  • 需要的是结构化、语义化、关联性
  • 文字需要被系统理解
  • 元数据是必要的工具

关键在于：一定是先有记录，再做管理。

当我们在写笔记时就被迫考虑「这个想法属于哪个项目」、「这段话应该链接到哪里」，实际上是让知识管理的逻辑侵入了思想创作的过程。这就像要求建筑师在画草图时就必须标注每根梁的承重参数。不是不需要这些信息，而是不应该在这个阶段要求。

好的工具设计，应该清晰区分这两个阶段。

Tana 在这方面的设计值得称赞。它的核心哲学是：内部复杂，导出简洁。

在 Tana 内部，使用 supertags 建立语义类型，用 fields 结构化信息，通过 references 建立关联。这些都是强大的知识管理功能。但当导出 Markdown 时，将层级结构转换为标准的 # 和 -， 将 supertags 转换为简洁的 #*tag*# 标记，不暴露内部的 node ID，保持文件的人类可读性。

这意味着：系统承担了组织的复杂性，让文本保持表达的纯粹性。

我在 Tana 中写作时，可以享受结构化工具的便利：

  • 用 @ 快速引用其他笔记
  • 用 fields 记录元信息
  • 用 search nodes 动态聚合内容

但这些操作都发生在工具层面，而非文本层面。当我导出文件时，得到的是干净的 Markdown，而非数据库转储。

这才是正确的设计哲学：知识管理的结构化，不应该污染写作的纯粹性。

对比之下，很多工具的问题在于，把内部数据结构直接暴露在文本中。它们试图让「写作即管理」，结果是既破坏了写作的流畅性，又损害了文本的持久性。因为当系统的组织逻辑嵌入文本本身时，文本就失去了独立性，它不再是完整的表达，而是数据库的一部分。

也许我们需要重新审视一个前提：写作时，是否真的需要那么多「系统级别的组织」？

知识管理工具承诺的是：只要建立足够细致的链接、标签、属性，未来就能轻松找回任何想法，甚至发现意外的联系。这个愿景很美好，但代价是什么？

  • 需要在写作过程中不断打断思绪，维护元数据
  • 需要学习并记住特定工具的语义系统
  • 依赖系统的解释才能完整理解自己的文字

而更换工具，或者仅仅是时间的流逝，那些精心维护的结构往往比想象中脆弱得多。

回到最初那份三年前的笔记。我花了十分钟，终于回忆起那套 :: 标记的含义，但那些 [[双链]] 指向的内容已经找不到了。讽刺的是，如果当时只是用标准 Markdown 写下思考，不做任何「系统级优化」，今天反而能完整理解。

为了「未来的自己能重建知识网络」而添加的元数据，恰恰破坏了「当下写作的纯粹性」，也未必真正服务于未来。

当然，这不是说我们应该放弃所有结构化工具，回到原始的 .txt。工具有其价值，结构有其必要。就像让我现在放弃 Tana，我可能真的做不到。

但我们需要清醒地认识到:

  1. 写作与组织是两回事。写的时候应该追求流畅和纯粹，组织可以在写作之后进行。不要让系统的组织逻辑入侵思维的流动。

  2. 元数据应该服务于发布，而非写作。标题、日期、分类这些信息可以在文章完成后添加，而非在构思时就考虑。

  3. 持久性来自简单，而非复杂。真正能长久保存的，是那些不依赖特定工具解释的内容。标准胜过方言，简单胜过精巧。

  4. 工具是手段，文字才是目的。当发现自己在「维护系统」而非「记录思考」时，就该停下来反思了。

最后，也许我们需要接受一个现实：完美的知识组织系统并不存在。

无论多么精致的标签体系、多么复杂的链接网络，都无法替代思维本身的关联能力。真正有价值的联系，往往不是通过 [[双链]] 建立的，而是在重新阅读时，因为认知框架的变化而自然涌现的。

纯文本的价值，不在于它能承载多少元数据，而在于它让文字回归文字本身——不为系统服务，只为思想服务。

当格式比内容更重要时，我们就失去了思想的起点。

📰 Curations

Write plain text files

https://sive.rs/plaintext

Derek Sivers 从1990年开始使用纯文本，经历了从 Mac 到 Windows 到 Linux 的迁移，文件完好无损。他的观点直指核心："You will outlive these companies."

工具会消亡，公司会倒闭，但纯文本保持着一种罕见的独立性。更重要的是，它让写作远离依赖与订阅，回到文字本身的安静状态。

Is plain text best?

https://www.cjchilvers.com/blog/is-plain-text-best/

这是我挑选出的唯一一篇质疑「纯文本神话」的文章。作者的文本文件在迁移中元数据损坏，虽然内容完好，但失去了时间脉络。

这恰好指出一个微妙的边界：元数据不是问题，侵入式的元数据才是问题。文件的创建时间、修改时间是独立存在的，而 file-id: TN_abc123 这类系统级痕迹，则会污染文本本身。

Plain text journaling

https://herman.bearblog.dev/plain-text-journaling/

BearBlog 的开发者 Herman 从手写日记转向纯文本，不是因为技术洁癖，而是因为读不懂自己的手写字迹。（我也常常读不懂自己手写的字而更喜欢打字。）他用一个 journal.txt 记录了 10 年生活，可搜索、可备份、可跨设备同步。

这里的重点不在技术，而在写作本身：如果连自己都无法访问，那记录又有什么意义？当然，打字确实少了些浪漫，但浪漫并不能替代可读性。

Can "Distraction-Free" Devices Change the Way We Write?

https://www.newyorker.com/magazine/2021/12/20/can-distraction-free-devices-change-the-way-we-write

这篇 New Yorker 长文从写作设备的变迁讲起：从 Word 的「无限修改陷阱」到 AlphaSmart、Freewrite、reMarkable 的复兴。作者试过各种极简设备，只为摆脱那种「无休止可编辑性」。

Derrida 曾经说过："With the computer, everything is rapid and so easy. An interminable revision, an infinite analysis is already on the horizon."

当写作被托付给「由公司拥有和主动管理的设备」时，我们也在交出对写作节奏的掌控。极简工具的流行，只是这种焦虑的另一种回声。