结构化笔记软件，相对于传统的Hexo等工具有更强的Tag与Block支持，那么这些工具与传统的Blog/Wiki有什么不同呢？

快速结论：

• 双向标记场景极为有限
• 长时间总结一定是树形结构
• 短时间记录任何笔记都可以，要根茎状的灵感

背景

认识论

在阅读本文前，可能需要先了解一下认识理论

• 野中郁次郎（のなか いくじろう）的SECI模型
• 千高原中的“抽象机器”与“平滑纹理”概念
• 神经科学的“心理距离”的概念
• 经典的“经验主义“与”理性主义“

了解一定的认识论，可以提高“方法的方法”，入门可以用金字塔原理等书。

“树状知识”与“根茎状知识“

人类大致有两种思考模型，一种是树形的结构化知识（比如书的目录），另一种是根茎状的有向图关系（类似于书的附录，比如倒排索引，再比如“举一反三”）。它们是对立、冲突且相互再辖域化的数据结构，它们对应着《千高原》中的“平滑”与“纹理”。

树形知识结构虽然符合普通人的认知习惯，但是它是一种过于整齐的思考，代价就是诠释（投影）过程中造就的大量的术语与割裂带，同时知识的权重可能更难找到。

根茎状知识是没有层次关系的结构，底层数据结构可以看作有向图，比如某些大师的手稿或者笔记，在线知识图谱（比如Wolfram搜索引擎，ChatGPT的AI模型）等。这些知识如同读者眼中的一千个哈姆雷特，就算是对专家来说难度也是很高的。

从根茎状抽象到树形知识，一般称作外显化（被“编译”为层次结构，或者投影为视图）。从树形知识抽象到根茎状知识，一般称作内隐化（难度较高）。

对大部分普通人而言，有能够总结树形知识的人可能已经很少见了，更不用说根茎状了。

知识录入的场景

我们可以按照场景来分析知识承载功能

从上到下，难度依次递增，而且一定是nomadic到sedentary的思考过程（参考这里）。同时，知识从Raw data录入到形成“阶”的分类，是需要多次“层化(stratification)“处理的，带来如下挑战

• 每深入一层，都需要更高的专注度与专业知识，而每天的专注度是有限的。
• 阅读与写作本身就是要求一定技能的，比如“技术写作”是专门的职业。

这个过程处处都是门槛，与你使用的工具（链）是无关的。

跨平台的物理限制

上述场景中，除了随手记录，其它场景都是高度消耗专注度的工作ーー比如你在学习某个专业技术时，你需要

• 查询权威资料
• 实践相关技术
• 总结相关内容

上述操作至少需要2K分辨率的屏幕，甚至是挑心情、温饱与桌椅的。用手机等物理屏幕小的设备查字典、看资料来回切屏是效率很低的。因此跨平台录入的机会可能只能局限于随手记的维度。

当然，如下是仍然需要的

• 突发灵感（想到啥记啥）
• 跨平台的查看（查看看编译后的静态结果即可，要求可搜索）

不要将“跨平台”作为工具选择的约束，事实上移动设备进行专业的修改机会非常少。

根茎状知识 ≠ 双向标记

Logseq/Roam Research/athens等软件提供了双向标记功能(Bi-Directional Links)

双向标记的定义

在笔记软件中，它使用[[TAG]]实现指向一个Block，是一种递归的关系。Tag的结构体大致如下

1
2
3
4
5

struct Tag{
  String name;
  String content;
  List<Tag> pages;
}

这里的[[TAG]]是一种代表集合(the property or properties they must have to be members)的符号

• 外延：关联的实体文章，比如有多少份Linked Reference的文章
• 内涵：它本身的“质”的描述

下面是一个例子

1
2

# 笔记事例
のも和や和と都用来体现 [[联合复句]]，其中のも的用法是...

其中“联合复句”这个概念被引用到它本身的介绍。

双向标记的冗余问题

我导入了Hexo等笔记的数据到“图”中后，发现“图”功能事实上好看但不实用

• 上百个Tag难以搜索，而且相互关系是无向图
• 维度缺乏层化，比如"自然-人-社会"的两个-中，观察本体的维度（阶）是不同的

最终导致这种可视化是华而不实的，反而还不如Excel的透视表好用

双向标记对关系描述的缺乏

在软件理论中，我们有UML图、ER图等方案来描述两个符号的关系。

举一个经典的“因果”例子，假如

我用手摸了热的炉子，它烫了我一下，我疼的手缩了回来

在经过这种体验后，大脑会提取出一个主观的因果关系“热炉子”->“疼”，这种逻辑关系至少要用有向图来表示。

而各类软件的双向标记的连结关系只能类似SQL一样进行静态的join运算，却不能包含“蕴含等价（计算等价）”。仅仅依靠标题-标题与标题-Tag联系，是无法承载复杂属性（比如质、蕴含、覆盖、反身性）的。

目前商用或者开源软件均未有类似UML/Data Flow Diagram工具的childOf, afterOf, resultOf这种属性设计，而只有平级的结构，导致符号间的关系很弱。

根茎状知识需要“无尽”的诠释

由于知识表现媒介是有向图，那么就会涉及到图的深度或者广度遍历，这个门槛极高。我们不能说它是无效的，但是它很难被“编译”成新的诠释

1. 一本书越是碎片化，它反而就越加完好整全
2. “簇根是多元的而非单一的，但簇根书却仍然保留着主根书的某些重要属性。在此，主根书能够完好地理解并忠实地表征外部世界的那份自信消弭委顿，而这份无能则恰好成为贯穿簇根书之始终的原则，即使这样一本书的终极意义被无限延搁，并且/或者（and/or）需要无尽的诠释”

----导读德勒兹与加塔利《千高原》

多产品横向对比

与传统Wiki工具进行对比

notion的格式是私有（Vendor Lock-in），而且难以承载排版、编辑等精心的外显化写作，写作体验上也很难干的过Typora这种打磨多年的工具。即使它有低代码能力，但是假如你的Excel用的很好，你可以超过它。

logseq 虽然是后起之秀，但是它的门槛实在太高了ーー对写作硬件（桌面）、心智（递归管理）要求极高，同样还有双向标记的问题，它把Tag与Title基本上作为同级别来看待了，这种方法必然带来后期的低信噪比。当然，我对它用Lisp语言还是很乐观的，因为它后期会迸发出更加抽象的数据和程序绑定的方案。

mdbook/docusaurus等静态WiKi工具，定位是最终交付件，而不是迭代过程的笔记，对你的知识范畴与编辑能力要求极高，它要求你已经想好了自己所思的树形提纲并割裂边界，可以被看作在写一份大论文了。而且后期维护更新/重构成本也非常高，假如你的"思考树"有问题，那么后续变动也会非常有挫败感。
以下是我的经历

• 费力写的MyBatis/Eureka等IT应用知识，随着技术升级而半衰贬值
• Java/LeetCode等八股文与面试，显然卷不过天天刷题的大学生，自己也很难坚持
• 写的外语相关知识，发现自己的分类标准极其割裂，碎片量很大，还需要维护"倒排索引"，最后无论是专业是分类广度都不如专业老师所写，重构成本（比如修改md的url）也非常高
• 唯一成功的案例，是我在公司内部写的help文档，因为相关系统是我负责的，而且用户问题也很熟悉，所以此文档极高地降低了咨询压力

综上，后续除了极其熟悉的领域，即使可以写mindmap，也不再考虑使用mdbook等wiki作为迭代文档，而是直接参考书。

同样mediawiki等动态WiKi工具，需要长期开机的服务，如果单机使用可能会赔本，但是家里有NAS/WebDAV倒是可以搞一搞。

blog等工具，没啥毛病，手动维护元数据的成本有点高而已，假如你不介意一些冗余的话。

综上，我的看法是结构化笔记可以用于快速录入灵感与整理部分思考，但是后期如果需要深度思考的话，还是要投入大量时间二次消化到专业的Wiki/Blog平台。

我所理想的知识工具

功能模块

• 知识采集（灵感侧）：快速笔记，启动速度快，支持跨平台同步，不要求排版
• 知识加工（思考侧）：根据上述灵感，查询资料，按照自己的演绎范式，整理为树型图，比如各种导图工具
• 知识主题（交付侧）：一款类似电路综合工具的笔记软件
  • 文本采用Markdown进行编写，支持内嵌或者分离存储元数据，元数据用于描述文档间的覆盖/因果等关系，并自动形式化推导，可以用Graphviz/UML等markup工具进行落地
  • 文档间的树形结构（TOC）或者根茎块（Tag）的关系，可以通过“编译器”自动生成，提供插件来优化IR，不要求link

最终文章本体可能会成为类似LISP这种文章和元数据混在一起的根茎状DSL，同时需要高级编译器。logseq在未来最有可能的实现。当然这样你可能又会陷入形式化知识（知识图谱）与自然语言的纠结中了。

目前最接近个人要求的反而是

1. Excel，它的枚举能力强/可作为导图；批量操作能力强；透视图效率高
2. PPT，也就是写奏折，它的认知密度应该是最高的，所以大公司病就是这么惯出来的

缺点是版本管理比较困难。

附录

虽然结构化笔记可以兼任很多任务（比如待办），但是都过于轻量，个人不推荐one tool，而是toolchain。

个人待办场景

• 长远而且可能模糊的待办：最推荐Excel或者类似的在线服务，精确管理
• 长期但是确切的事情：系统自带日历，可以导入ics文件
• 短期待办：系统自带todo，或者notion存储

上述优点是有手机的提醒功能，不需要折腾。

团队敏捷场景

这里涉及到团队协作，所以要有一个”数据请认真录入“的前提，如果你做过这类软件，可以发现有如下管理功能是用户高呼的需求

• 工时估算与分析
• 燃尽图
• 自定义column与自定义Query
• 工作流转移与审批
• 多租户与权限管理

这种高级功能，建议以AzureDevOps/JIRA等工具作为标杆进行参考学习。类似notion等工具就算结构化能力很强，也干不过excel，而Azure这种工具甚至可以连接到Excel。第二，notion等工具的灵活性容易产生方言问题，导致协同难以对齐。当然如果项目不追求高速迭代，使用notion也是够用的，但是价格和Azure也接近了。

CRM/ERP场景

CRM销售等场景，需要承载企业的L2C流程，是专业工具。不推荐用结构化笔记来承载，难点在于需求落地，建议购买企业/SaaS工具，可以参考国内的创业SaaS，省钱也可以自己搭一套内网开源CRM。

日常学习上课笔记模版

以学习英语为例，推荐格式如下，个人采用notion，但只使用了markdown功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

+ 英语C1
++ Class(上课实体笔记再次整理这里)
+++ 1.2021.03.01.Chart
+++ 2.2021.03.08.Indentity
+++ 3....
++ Homework(作业整理)
+++ 1.Write xxx
+++ 2.Write xxx
+++ 3....
++ Sumaary(持续维护的体系化知识，类似Wiki)
+++ 时态
+++ 单复数
+++ ...
++ Topics(实践场景，按照话题分类)
+++ 表达观点
+++ 图表介绍
++ Question(整理的 backlog)