silent

单仓对我个人知识管理来说是最优解

我说的是“对我个人” 没有否认任何人的想法或者意见的意思哈，即使我说的

无压笔记我个人观点是“伪概念”

很多都是标记了个人观点，我的观点在最后都标注了是个人经验，在这里先澄清下，避免再产生不必要的讨论。

由于我做的大多是技术类笔记，所以当前做笔记的 workflow:

1. 信息了解、信息收集阶段：这个阶段通过灵感速记(chunk)、信息箱或者其他 web clipper、备忘录、录音笔等方式收集，这个阶段收集的都是信息碎片
2. 阶段性信息过滤：每周周末回顾或者根据自己的情况（比如某一个临界值），看需不需要归纳整理成笔记或者说文章，同时对碎片进行标记，方便循环过滤。同时也可以通过引用块聚合不同的 chunk 做阶段性整理
3. 最终整理产出：当进入这个阶段，由于大多是技术类型的笔记，第一要义就是“准确性”，我习惯对碎片信息进行“溯源”，避免产生误解。这个阶段确实很磨时间，但一个知识点经过不断发展和高度抽象化后，要了解本身就很花时间，同时这个阶段在一定程度来说是包含了下一个阶段的开端
4. 知识遗忘对抗：在这个过程中，涉及到对笔记的重新整理，包括可能的重新分类调整、通过标记“标签”（自定义的标签列，非当前思源系统功能）进行信息系统的更新，对“旧知识”的更新。通过闪卡功能定期对某一个分类模块下的知识进行记忆，可能进入“整理”-“记忆”这个循环。

这个 workflow，单仓对于“最终整理阶段”来说我个人认为是最舒服的，因为单仓意味着“归一化”程度高，信息调整方便简单。当然你也可以说“我通过模板新建数据库也能统一列属性，达到归一化目的”，我目前还没有看思源“数据库”的实现，就不做确切结论了。但如果是对应“表”的概念，那么“多表联查”懂的都懂

每个人对于“做笔记”都会有自己的看法（也可能没有形成聚焦的看法，但这种不聚焦本身就是一种看法 🤣），要不这个细分领域市场的盘子就没有这个多产品来打架了。不同的人会因为自己的性格、习惯、思维方式和出发点，做笔记的 workflow 或者 workflow 不同阶段的细节会呈现出不一致性，结合自己不断升级的认知找到适合自己的方式即可。所以我看到新的做笔记的“奇淫怪技"，非出于挑刺、反对，而是看经过探讨，能不能够提升我的 workflow 效率

对于笔记产品，如果其能力的支撑下能继续覆盖我的 workflow，就继续使用；而一旦笔记软件不满足只能两看相厌了，在没有太多沉默成本的前提下，我更倾向产品来就我。思源则恰好能够满足我当前的所有需求，足够灵活，能够基于当前功能，满足自己。

别再急着逐句分析哈，交流自己的想法即可。交流注重的是**互相尊重，求同存异**，你懂我也懂，其他大可不必。

单仓对我个人知识管理来说是最优解。之前也在 notion 平台用过多仓的方式进行管理，但是一是由于 notion 的多仓联动体验实在糟糕，二是基于多仓或者说多表进行查询实在太痛苦了，最后迁到了单仓。

1.7k+ 的笔记通过一个仓库进行统一管理我觉得并没有感觉到压力，因为通过一级分类领域已经能够进行梳理了，其他通过新建视图 + 引用块 + 条件过滤就能快速简单实现类似 Topic 的概念也能够处理模块化地组织知识体系。也就是我不需要添加到一个不存在的数据库，至少不是高频

对于笔记的管理仅依赖数据库自身的功能就得了，目前思源的「标签」系统我玩不明白，这个之前帖子就讨论过 我到底应该基于数据库扩展 " 标签”属性，还是直接使用文档的标签系统 。全文搜索就 CMD+P 啰

至于无压笔记我个人观点是“伪概念”，都无压了备忘录和录音不香吗？或者直接全部放在一个目录就得了。笔记笔记，如果不整理为什么还要记？管理知识本身就是系统化知识的过程，也是对抗知识遗忘的一种方法。“把数据库当前标签”对于我来说，可能就是一个快速备忘，为这个备忘加一个“标签”吧

“渐进式笔记法”不太懂，如果是我理解的概念的话，我觉得文件的“历史记录”足够我对这个笔记迁移过程的了解了。

此外，知识库迁移做了几次后，学到了一个词「归一化」。统一一个数据库能够让你的笔记更好归一化，方便老板跑路的时候，能够对导出的笔记进行格式转换等，这个谁用谁知道。

以上实际是知识管理的自身经验，less is more. 欢迎交流共同进步

没太 get 到，这样用还有啥不满足日常的？通过主索引作为入口，提供搜索能力（标题/标签/分类）等，CMD+P 仅用于内容搜索。

如果觉得太大，还可以在子目录分类再做 「引用块」过滤条件视图

悬赏积分太少了，哈哈哈

第二个提了一个 PR，https://github.com/siyuan-note/siyuan/pull/10991

我选择 A，保留重命名。原因：

看起来是少了一个按钮（菜单/功能）,但是多出来的会让我减少心智，特别是对于新用户来说，我思维还要兜一圈：“重命名是不是在编辑里面？”

另外，保留可以用 @JeffreyChen 的方法自定义实现“去掉”，而去掉的话想要“保留”就很麻烦了

不赞同在基本功能细节没有打磨完就大力推广，感觉目前程度刚刚好，在人力有限的情况下，按照规划集中精力打磨好细节和体验是更好的选择。至少不应该是一个 MVP 了，要是一个有用户体验的产品。

我赞同自来水很重要，但是如果没有细节的打磨，自来水流走也很快。大力推广当然有流量，但是这流量你有精力有实力把握吗？

伟大的互联网产品不为功利心驱使，而是以创造价值为导向。——鲁 X

我觉得通过外部实现就挺好，比如你现在的快捷指令。

至于“需求”就太随性了，或者说个性化太明显了，不适合添加到新特性里面。

1. 需求想的是我根据编号创建不同类型的附件，那么怎么统一用户的需求，是不是要创建一个规则去做映射？这个规则怎么设计？
2. 创建空文件当然简单，但是打开编辑呢？是不是又要安装不同的软件？那么怎么知道用哪些软件打开对应类型的附件呢？要知道笔记可是跨端的，里面的细节可又要增加考虑边界了
3. 实现过程中可能还有更多没有考虑的边界问题...

最近在思考如何增加一些个性化功能给自己的 APP，有感而发探讨下。在实际需求落地过程中，一定要明确哪些是真正的适合大部分用户的“个性化需求”，不然真的是自己做来玩了

还是等子弹飞一会吧，感觉 database 这块还有很多优化空间，模板更是。按着 notion 的路子来走，起码得大半年不止。

notion 用起来很符合直觉的 database 功能：

• 模板语法上手建议程度和文档完善度，当然 siyuan 更加开放，但是就上手来看，要扒源码...
• 可以重命名 title，这样在不同场景下，我能够直观知道列表是干啥的，同时也能够隐藏部分视图，或者说克隆的时候不克隆所有视图，可以对其中试图进行克隆
• 列默认值，基于这个点做新建记录模板

目前感觉精力仅集中两个视图 table 和 看板 的实现就现阶段够用了，后面直接做这块的优化，不要只停在够用的程度了

回到主题，目前我还是决定继续在 database 上添加标签多选列，这样使用体验和维护都比较方便，内置标签系统仅作为补充好了，在内容上做下名词索引够用了，同时用于碎片化的内容片段，方便之后整理为文档。或者继续看看 DL 们还有什么骚操作了

@liptshang 有点赞，看了一下源码找了一下 .tags 怎么注入的，还可以把模板列的渲染改为 select 组件，监听 onchange，或者看能不能复用 siyuan 的组件(如果有/可以的话）。另外不知道是不是这个模板列的问题，点击 Cell 的时候，会重新渲染成模板列的代码 input...

不能修改评论，有点不习惯。具体的源码地址可以看：https://github.com/siyuan-note/siyuan/blob/d0fbace122f786c181c0fd5f6fc0a39e6999b762/kernel/model/file.go#L377

switch sortMode {
	case util.SortModeNameASC:
		sort.Slice(docs, func(i, j int) bool {
			return util.PinYinCompare(util.RemoveEmojiInvisible(docs[i].Name), util.RemoveEmojiInvisible(docs[j].Name))
		})
	case util.SortModeNameDESC:
		sort.Slice(docs, func(i, j int) bool {
			return util.PinYinCompare(util.RemoveEmojiInvisible(docs[j].Name), util.RemoveEmojiInvisible(docs[i].Name))
		})

PinYinCompare 比较实现为：

func PinYinCompare(str1, str2 string) bool {
	// Doc tree, backlinks, tags and templates ignores case when sorting alphabetically by name https://github.com/siyuan-note/siyuan/issues/8360
	str1 = strings.ToLower(str1)
	str2 = strings.ToLower(str2)

	a, _ := UTF82GBK(str1)
	b, _ := UTF82GBK(str2)
	bLen := len(b)
	for idx, chr := range a {
		if idx > bLen-1 {
			return false
		}
		if chr != b[idx] {
			return chr < b[idx]
		}
	}
	return true
}

实际上在最终比较的时候，会转小写进行比较，所以大小写对比取决于在排序列表中的顺序。

而 golang 的 sort.Slice 方法虽然根据元素长度调用不同的排序算法，但是最终都会用到快排，而快排是不稳定的，不稳定的意思是两个相等的值排序之后的顺序可能和在原序列中的顺序不同。

看相关的技术文档说经过优化，sort 上面的排序方法性能差异不大，要不要改就看 @88250 老板了，或者，兄弟们，PR 的机会来了！！！