一直想写一篇用纯文本格式和纯文本工具管理个人信息的文章，分享我的经验和想法。

看到Michael Descy专门建立了一个网站 Plaintext Productivity，用来说明使用纯文本管理信息的好处，我也顺着这个话题谈谈。

什么是纯文本

所谓纯文本，就是只用最基础的文本字符表达信息，而不使用任何特殊样式的格式。这里的特殊样式包括粗体、斜体、下划线、删除线、文字颜色、背景颜色、上标、下标等，所有字符的字体样式统一，也不会与图片、视频等非文字内容混合显示。
一般在计算机系统中保存为后缀名为 txt 的文件，实际上 Markdown 格式的 md 后缀文件等也都是纯文本文件。
XML、JSON 等格式虽然也是文本文件，但更多是用于机器程序处理，而非面向人类读者，不适合直接阅读，因此一般不在讨论之列。

为什么推荐使用纯文本

  1. 体积小巧，不需要为了表达特殊格式而占用太多空间。
    一个只有几个字的纯文本文件，体积是几个字节，而空白的 Word 文件至少是几千字节。
    许多时候，我们不需要为用不到的复杂样式牺牲存储空间，哪怕存储的成本越来越低。

  2. 格式通用。
    有无数编辑器可以打开、阅读和编辑纯文本文件，能借助 Pandoc) 等工具转换成许多其他格式（HTML、PDF、LaTeX 等等），任何平台上都有可直接搜索纯文本文件内容的工具，比如 grep、Total Commander 和 Anytxt。
    而 Word 格式、RTF 格式等富文本格式适用的编辑器和其他工具就少了好几个数量级。
    不管技术如何发展，你永远不会为找不到能纯文本编辑器而发愁，不用担心内容无法导出和转换的风险，不依赖特定的软件和平台。

  3. 长命百岁。
    Evernote 可能活不过另一个10年。Notion，谁知道呢？
    OneNote 已经算长寿的了，Microsoft Word 为兼容历史格式付出的成本令人感动，但只要计算机还存在，纯文本格式就可以一直存在，且代价极低。

  4. 方便解析。
    因此也适合于内容比对、增量备份、内容同步和版本管理。
    一些二进制文件一旦变更内容，就只能全量重新备份或同步，而纯文本文件的备份、同步和版本管理可以在经过内容比对后，只关注发生变化的部分，存储空间消耗小，速度快，效率高。

  5. 专注内容。
    保留了最核心的内容，作者和读者都不必花费大量精力和注意力在复杂的样式和排版上，能够更加专注于文本本身表达的信息。一些简单的样式和排版需求，也可以用文档标记语言来支持，比如 AsciiDOC、Markdown、Org-mode、reStructuredText、txt2tags 及各种 Wiki 标记语言。

  6. 离线使用。
    虽说现在网络无处不在，但你总有可能遇到以下几种情况：
    信号不佳、网络故障、应用服务宕机、云服务基础设施瘫痪…
    这个时候能够离线使用的本地文本文件不会让你寸步难行，束手无策。
    更极端的情况下，就算停电、计算机和手机故障，基于易读的纯文本格式，你还能在纸质笔记本上临时对付，等电子设备恢复了能马上低成本转存。

当然，如果你需要丰富的文本样式、多媒体的表现形式和高级的排版与组织结构，大可不必死抱着纯文本不放。不同的场景就应该选择最适合的信息保存格式和管理工具，以纯文本为中心的系统也可以与其他工具组合起来，各取所长，达到更好的效果。

为什么（暂时）推荐 Markdown

上面说到，Markdown 也是一种纯文本文件，目前推荐使用这一格式的原因主要有：

  • 应用非常广泛，基本上已经成为纯文本格式笔记的通用标准，在人工智能学习方面也有大量应用。其他标记语言虽然有比它更加强大、支持的样式标记更多的，但既然我们的目标是尽量通用，降低迁移成本，那么目前 Markdown 还是最优选项。
  • 简单易用，不使用预览工具，直接阅读就可以直观理解大部分要表达的样式

当然，它也有不少缺点，比如 AsciiDOC 就列举了两者的差异，其中有不少特性 Markdown 不支持。
另外，标准 Markdown 不支持硬回车也令入门者疑惑，也就是在文本文件中换行，在渲染后生成的网页中却不会换行，这应该是从 HTML 中继承的特性，但对不了解 HTML 的用户来说很不直观。
如果你介意的话，可以使用 Github Flavored Markdown 等扩展格式，或者一直直接阅读 Markdown 文本。

笔记系统

曾经我也使用过许多支持特殊样式的富文本笔记工具，如 OneNote、Evernote、eDiary、MyBase、My Notes Keeper、PIM Essential、为知笔记、TiddlyWiki 等等，有的使用专有格式，有的使用 RTF 格式，有的是 HTML 网页 + Zip 压缩的格式，有的还用上了数据库（SQLite 或内部专用数据库）。但是在各个笔记工具之间导入导出、转换格式时非常痛苦，丢失信息、排版错乱、格式混乱是常事，有的笔记工具格式封闭，甚至不允许或很难全量导出转移，让用户有被绑架的感觉。

于是我开始将笔记系统改为以下几种形式的组合：

  1. 信息收集。
    尽量保留适合检索的格式。
    网页内容先用 Raindrop.io 暂存至稍后阅读，读完之后使用 SingleFile 扩展保存 HTML 单文件。其他文本内容用纯文本格式保存。
    电子书尽量使用 ePub 格式，不得已才选择 PDF 格式。
    电子书放在 Book 文件夹中，摘抄、评论的内容放入书摘笔记文件夹。其他文章先放在 Inbox 文件夹中，定期回顾消化以后，原始文件转移到文摘多级目录分类保存，整理的内容输出到 Note 文件夹中。

  2. 思考整理。
    使用 Vim（Neovim）+ wiki.vim 插件编辑 Markdown 标记的纯文本文件，文件内用 VOom 插件实现侧栏的层级树。图片和附件用 Markdown 支持的链接加上备注。
    这些笔记文件放在 Note 文件夹中，并都纳入 Obsidian 仓库管理，Vim 编辑，Obsidian 做进一步加工。
    不适合纯文本格式的内容，如表格、思维导图、概念图/关系图等，可以用 Excel（仍然是最好的电子表格）、FreePlane（键盘操作最顺手的思维导图）、Draw.io（非思维导图类的图示）、Visio、Mermaid/PlantUML/C4 model 等绘制，不强求用纯文本搞定一切。

  3. 输出文章。
    一部分用 Hugo + Github Pages 发布 blog。同样默认支持 Markdown 标记（Github Flavored Markdown）。
    其他放在 Publish 文件夹中，或发布到 Github 上的公开和私密项目中。

笔记管理流程

近年来新兴的笔记工具层出不穷，如 Roam Research、Notion、Joplin、Logseq、Heptabase、Obsidian，还有趁着人工智能东风结合 AI 的后起之秀，如 Google NotebookLM、Tana、NoteGen 等等，你方还没唱罢我就登场了。
虽说功能十分强大，特别是 Notion 这样以数据库能力为卖点，但是大部分是云端保存，专有、复杂的节点关系无法完美导出和还原，同样有数据被绑架的风险。
少数支持本地保存的工具，即使有 Vim 模式，编辑体验也不理想，仓库内容太多时还有性能问题。

我觉得笔记工具不必追求面面俱到，可以根据使用场景分为两类，在其中一个场景中做到极致，各展所长，再配合使用：
一类专门用于基础编辑，目标是快速灵活地打开和输入，专注于当前的笔记文件和少量的关联文件，即底层的、通用的“数据”，保证基本可读，必要时能无痛或低成本迁移；
另一类则专门用于整理和呈现，管理笔记之间的关联关系，如双向链接、引用和锚点、合并和拆分、整理结构、维护标签和目录、展示树状网状关系，等等，即专注于上层丰富多彩的“应用”展示。

你可能会说，第二类工具一样可以干好基础编辑的活，为什么非要分成两类呢？因为大量笔记的关联分析，图形显示，以及样式渲染，不可避免地会要影响性能。比如一些重度用户反映，即使是本地笔记工具，管理上千个文件也会后开始卡顿，影响体验。

另一个原因，就是希望尽量减少通用格式分裂的可能。
目前 Markdown 已基本成为广泛接受的通用标准，但它毕竟只是简单的标记语言，无法完全替代富文本格式。但用户又需要增加各种功能，于是坚持纯文本格式保存的笔记工具，不得不尝试设计扩充、增强的 Markdown 标记。如果各自实现一套“应用”方案，为了扩充功能，完全不管底层“数据”的可读性，只要在自己的生态内可用，相信不久就会分裂成为多套并行的方案，同样也会阻碍用户在不同的工具之间切换。
而且如此一来，就完全违背了 Markdown 设计的初衷——如果不再需要考虑纯文本文件是否可读和通用，给它添加各种程序功能所需的独有标记，那还用 Markdown 干什么呢？

总之，不管工具和生态有多强大，要保留退出的可能，易于读写的纯文本格式是关键。

任务管理系统

使用过 ToDoList、Todoist、Remember the Milk、滴答清单、Microsoft To Do，以前的 Wunderlist、Asana、Clear、基于电子邮件的任务管理…等等等等，总有各种放弃的理由，我想这个清单可以一直写下去。

当然我也试过用纸笔管理，但每天的待办任务多又杂，我的字很难看，书写还不如打字快，加上经常需要搜索、修改、回顾汇总整理，始终不如电子文档方便，遂作罢。

后来知道了基于纯文本管理待办事项的 Todo.txt ，于是到目前为止还在使用。

Todo.txt 的核心理念是“简洁”：

  • 能够用一个纯文本文件管理的，就不需要功能复杂、界面花哨、信息繁多的应用程序
  • 将待办任务的关键元素精简为：完成状态、优先级、完成时间、创建时间、任务描述、项目标签、情境和其他以“键:值”表示的扩展信息，只有任务描述信息不可或缺，其他都是可选填项
  • 已完成的任务归档到 done.txt，精简当前关注的清单

比如，最开始我们要记录一个待办任务事项，最简洁的记录就是在一个 todo.txt 文件中输入：

阅读《战争与和平》

如果要记录这个待办事项创建的日期，就在前面增加：

2025-10-01 阅读《战争与和平》

如果还有其他待办事项，而你想将这一条优先级提升到最高，可以在最前面增加优先级：

(A) 2025-10-01 阅读《战争与和平》

如果你希望记录计划完成的时间，可以用“键:值”方式表示：

(A) 2025-10-01 阅读《战争与和平》 due:2025-10-31

还可以增加项目标签，关联人员、地点、对象等情境信息：

(A) 2025-10-01 阅读《战争与和平》 +经典阅读 @托尔斯泰 @图书馆 due:2025-10-31

完成这一事项后，就在最前面增加完成标记 x，并插入完成时间：

x (A) 2025-10-20 2025-10-01 阅读《战争与和平》 +经典阅读 @托尔斯泰 @图书馆 due:2025-10-31

已完成的任务也可以归档到 done.txt。

这基本就是全部了。

这种设计的好处是，能够涵盖大部分简单的任务，默认依次按照完成状态、优先级、创建时间排序，比较符合直觉，也保留扩展字段记录较复杂的信息。
大多数情况下，一个最基础的纯文本编辑器就可以管理这个待办任务文件。
更高级的编辑器还可以有语法高亮、快捷命令、根据不同字段排序、将已完成任务转移到 done.txt 文件等便捷功能。
比如 Vim 有 todo.txt-vim 插件。

如果是记录工作任务，建议每一行都记录至少一个关联项目的信息，便于分类管理和排序。

当然，和功能完备的待办任务管理系统相比，它相当简陋：

  • 没有多级子任务概念
  • 没有循环任务，手动实现
  • 没有提醒功能，得靠你自己定期检查
  • 没有任务依赖关系，可以自己添加 ID 和依赖关系描述文本
  • 没有日历功能，无法与 Google Calendar 等在线日历工具同步
  • 每个任务只能用一行文字记录，不支持多行，除非你永远不排序

最后这一点，可以用 wiki 语法通过链接跳转到新的文件中补充详细信息，问题不大。

在 Android 手机上有 Markor 这样的编辑器天然支持 todo.txt 语法。
同步用各种同步或代码管理工具都可以实现，缺点是仍然有可能因为多端同时编辑而冲突，优点是纯文本格式手工比对和修复冲突文件也很方便。

日历系统

在使用了2年之后，我发现其实我更多在将 todo.txt 文件当作日志系统（见下文）在用。
原因之一是，待办事项需要多平台极速同步、打开，用文件同步工具还是慢和不稳定。
原因之二是，我还是需要直观的日历视图管理需要精细安排时间的任务，一眼就能看到近几天不能错过的会议、考试等事项。
基于 todo.txt 有 calendar.txt 的用法，但仍然是一天一行文本的方式，确实不够直观，容易错过重要事件。Vim 有日历插件，但移动端没有好用的纯文本日历。

于是我又引入了 Google Calendar + Workflowy：
在 Google Calendar 录入近期（近几日、本周）待办事项。任何系统和平台都能打开，且有提醒，只是不适合输入大量文字。Vim 用户也可以使用 calendar.vim 插件与 Google Calendar 打通。
通过 Zapier 同步给 Workflowy 的日历清单，能够转换为纯文本的列表，方便快速录入待办事项的跟进详细情况。
定期将已经过期的任务和需要长期思考的任务从 Workflowy 复制到 done.txt 和 todo.txt。绝大部分任务一句话一行文本就可以概括，不需要用到链接，与 todo.txt 格式无缝衔接。

日志系统

剩下的长期规划的其他工作，特别是需要经过思考和分析的工作，我仍然还是在 todo.txt 中维护，定期生成近期待办事项放进上述的日历系统。
我的生活日志也在另一个 todo.txt 文件中记录。同样通过 Workflowy 快速录入和同步，定期转存和整理。

记录日志不需要操心什么计划完成时间、优先级、完成状态等等，每一行开头是日期，后面用简短的一句话描述当天的经历或感想就好。同一天的多件事情就分多行记录。

所以这几者的关系是：

任务管理、日历和日志系统关系

目前感觉良好。

局限和展望

没有万能的工具，既然选择了纯文本格式，自然也会有代价。

比如上述任务管理系统，对习惯了围绕邮件管理任务的人来说就要多出不少工作量，还有人的工作流以 Slack、飞书、钉钉、企业微信和 QQ 等各种即时通信工具为中心，有的自带了任务管理功能，往往比基于纯文本的系统功能强大和易用。
在这些场景下，不强求替代，而是做好未来可以无痛或低成本切换任务系统的准备。
建议定期输出或备份为纯文本+附件文件的形式，如果不追求完整备份，至少定期复盘总结工作任务，再输出为适合进一步利用的信息。

日历工具的局限上面也提到了，不直观，目前没有足够简单、易用的现成方法将一行一个事件转换为日历视图，依赖网页形式的在线日历服务，以及无法与其他在线服务关联协作。

表格、图片、附件，这些都是 Markdown 等基于纯文本格式标记语言的先天弱点。
Markdown 编辑器可以优化内嵌图片和附件的体验，但是表格始终不如 Excel 等电子表格工具，或者 Notion 这样的一站式工具。

没有自带同步服务或者云端保存，如需即时同步，或任何客户端随时访问服务端的同一份数据，需要自己另外找适合自己的解决方案。

如果你认为这些代价太大，或者挑选、配置、适应纯文本工具太花时间，也完全合理。毕竟开箱即用、一站式的工具能够节约大量的时间精力，未来也许所有的活动都在一个基于人工智能的平台上完成，都不需要用户亲自操作文件。我只是希望你在始终找不到理想的解决方案时，能够想到也许可以试一试传统、老套、永远有效的纯文本方案。

延伸阅读：
Todo.txt
My productivity app is a never-ending .txt file
Calendar.txt
How I fell in love with calendar.txt
HyperList
TaskWarrior
Calcurse
GNU Emacs Org Mode
Plain Text Accounting (PTA)
Workflowy（如果点击该链接注册的话，每月的条目限额能免费增加100个）