最近我在整理自己的效率工具链时反复琢磨一个问题为什么现在的笔记、任务管理工具越做越重启动要等加载打开要登录界面上堆满按钮很多功能我一年都用不到一次。后来我发现真正让我每天都离不开的工具反而是那些“原始得让人发笑”的东西文本文件、命令行、快捷键。所以我花了一周时间写了一个叫caveman的小工具。它不搞云端同步不做花哨界面甚至故意拒绝了很多现代功能。设计理念只有一个像石器时代一样笨拙但因此足够靠谱。如果你也受够了重型软件或者想尝试一种更轻的知识管理方式这篇文章会非常适合你。我把整个项目的思考过程、核心实现和踩坑记录都整理在下面。1. 项目起源为什么偏偏叫 caveman1.1 一个工具的自我反思先把话说清楚caveman 不是一个新语言也不是什么大厂开源项目。它是给我自己用的一款命令行知识管理工具用 Python 写的数据全部落在本地文件夹没有任何服务端。取这么个名字是因为我想要的体验本质上就是“史前模式”。如果你用过 Notion、Obsidian 这一类工具可能觉得它们已经很轻了。但对我来说它们仍然有太多体系工作区、权限、数据库、插件市场、缓存的缩略图……真正记一条灵感往往只需要 10 秒工具却要在后台做几百件事。caveman 想做个相反的东西你给它一段文字它就把这段文字存下来再给你一个能用 grep 理解的索引。听起来太简单是的简单就是它的卖点。另一个灵感来自我平时写代码的习惯。我发现自己很多碎片知识最后都散落在 Markdown 文件和代码注释里根本不存在某个软件中。命令行工具的优势在于它和我已有的工作流无缝连接可以放进脚本、配合 git、还能通过 SSH 在服务器上直接用。这种“回归原始”的方式反而让我收集信息的阻力降到最低。1.2 我的真实使用场景在设计 caveman 之前我把自己的需求写在一张纸上只有三条快速记录在终端里敲一句话回车后这条内容必须已经落盘零等待。强力检索支持全文搜索和标签过滤能在一秒内从几千条笔记里找到目标。迁移无痛所有数据必须是纯文本哪天我不想用了直接打开文件夹就能带走。这三个需求恰好都能用“石器时代”的思路满足。我把会议记录、灵感碎片、待办事项、读书笔记全部塞进去用标签区分类型。比如开完会直接caveman add -t work -t meeting 确认Q3排期联调时间下周二一条笔记就进去了。查的时候直接caveman find 联调或者caveman list --tag work。有人会问这些用mkdir加echo不也能实现吗确实能。但 caveman 的价值在于把“散落”变成“约定”统一的文件命名、自动的时间索引、可控的元数据格式。它不是一个全知全能的管理器而是给我提供了一个趁手的默认结构。2. 核心设计先想清楚不做什么2.1 三条铁律本地优先、明文存储、命令交互一个工具好不好用往往不取决于它做了多少而取决于它拒绝了多少。caveman 的设计阶段我给自己定了三条铁律任何功能如果违反其中一条就不做了。第一本地优先。所有数据写在一个本地目录默认是~/.caveman/不存在任何远程同步模块。你可能会担心换电脑怎么办我的方案是把整个目录放进 git这也直接复用了代码项目的版本管理能力。不做云同步的好处是离线可用、没有账号体系、没有隐私外泄风险。对我这种经常在火车上写笔记的人来说这个优势是实打实的。第二明文存储。每条笔记一个 Markdown 文件文件名就是时间戳加单词拼接比如20250112-1030-meeting.md。笔记内容就是普通文本不加密、不进二进制数据库。原因很简单明文是几十年都不会过时的格式任何文本编辑器都能打开哪怕工具本体删掉了数据也还在。第三命令交互。caveman 只通过命令行使用。好处不只是“显得极客”而是它天然可以被脚本化、被参数化。比如你可以写一个 shell 脚本在打包发布失败的时候自动记录一条错误日志也可以挂一个定时任务每天凌晨把过期待办汇总成一份清单。GUI 工具做不到这种嵌合力。2.2 与其他工具的取舍对比为了说清楚设计取舍我列了一张对比表覆盖了我自己用过的几类工具。工具类型数据存储同步方式上手成本自动化能力离线可用Notion远程数据库官方云端中弱弱Obsidian本地 Markdown插件/第三方中中好备忘录厂商云端自动同步低弱中caveman本地 Markdowngit/自管极低强极好从表里能看出caveman 并不是要取代谁。它更像一把螺丝刀而 Notion 那种是瑞士军刀。螺丝刀能做的事很窄但每一次做这件事都又快又稳。对我而言灵感记录、任务钩子、快速备忘恰好是“窄但高频”的场景所以这种极端的取舍是成立的。需要提醒的是这种设计不适合所有人。如果你需要富文本排版、需要多人协作审阅、需要移动端随时随地编辑那 caveman 会非常难受。工具选型从来不存在通解只有适配你自己的使用习惯才是最好的。3. 技术拆解与关键实现3.1 数据模型一个文件夹、两种文件caveman 的存储结构非常简单~/.caveman/ ├── notes/ │ ├── 20250112-1030-meeting.md │ ├── 20250112-1120-idea.md │ └── ... ├── tags/ │ └── work.tag └── index.dbnotes/是笔记正文tags/放标签定义index.db是 SQLite 索引。为什么要索引因为当笔记数量到了几千条以后grep 整个目录虽然也能用但延迟会上升到几百毫秒甚至一秒而且不支持类似“标签与关键词组合过滤”这种语义查询。SQLite 在这里不存正文只存路径、标题、标签、时间戳和一行摘要。检索时先在索引里过滤再按路径读取实际文件。这种“文件为主、索引为辅”的模型是我比较推荐的折中方案。它的核心优势是容错如果索引坏了笔记文件依然在我完全可以用脚本重建索引反过来即使文件被外部编辑器改动了索引也只需要重新扫描一遍目录就能对齐。两边互不绑架数据安全性就高很多。3.2 全文检索与标签索引先看索引表结构这是我多次调整后定下来的最小方案CREATE TABLE notes ( id INTEGER PRIMARY KEY, path TEXT UNIQUE, title TEXT, created_at TEXT, updated_at TEXT, summary TEXT ); CREATE TABLE note_tags ( note_id INTEGER, tag TEXT, FOREIGN KEY(note_id) REFERENCES notes(id) );全文检索我用的是 SQLite 内置的 FTS5 扩展。建一个虚拟表每次写入笔记时把正文拆成关键词塞进去查询时用MATCH语法。FTS5 的好处是零额外依赖、支持中文分词通过 trigram tokenizer、速度极快。对于几千到几万条量级的个人笔记压力完全不是问题。标签索引则走note_tags表。一条笔记可以有多个标签查询时用IN和GROUP BY组合。比如我要找所有同时带work和meeting标签的笔记SQL 大概是SELECT n.path, n.title FROM notes n JOIN note_tags t1 ON t1.note_id n.id AND t1.tag work JOIN note_tags t2 ON t2.note_id n.id AND t2.tag meeting;这里值得注意的细节是不要用WHERE tag IN (...)那得到的是“任一标签”的结果和“同时满足所有标签”完全是两回事。我一开始就踩过这个坑后来才改成多表 JOIN 的写法。3.3 命令设计与交互细节caveman 的命令集刻意保持精简一共就 8 个add、find、list、tag、rm、edit、stats、syncsync 内部只调用 git。我以find为例说明交互设计。一个常见的挫败体验是搜索关键词返回一堆结果但每条都长得很像根本看不出哪个是你要的。所以 caveman 的find输出不是简单的路径列表而是每条笔记后跟一个摘要摘要自动截取命中关键词附近的一小段原文类似搜索引擎的 snippet。实现方式也不难在 FTS5 结果里拿到每个命中的位置偏移再截取前后各 30 个字符。再说add。我加了两个小功能让输入更自然一是-t可以重复传参指定多个标签二是支持从标准输入读取正文这让你可以跟其他命令通过管道组合。例如echo 记得给服务器续费 | caveman add -t ops -t todo这一条命令让我能把系统监控脚本里检测到的异常直接写成一条笔记不需要打开任何编辑器。工具做到这一步我觉得才算真正称得上“工作流的一部分”而不是一个独立的孤岛。4. 从零跑通实操过程全记录4.1 初始化工作区安装 caveman 我用的方式是克隆仓库后直接pip install -e .因为它还处于很早期的迭代阶段没什么必要发到 PyPI。装好后第一步是初始化caveman init --dir ~/caveman-data这个命令会创建上面说的目录结构并生成一份config.toml配置文件。配置里我暴露了四个字段notes_dir、editor、fts_token和auto_sync。auto_sync默认是关闭的打开后每次写操作都会默默检查 git 仓库状态并自动提交。这项功能强烈建议只在已经初始化好 git 的目录里使用否则会遇到一堆因缺少用户配置而失败的报错。4.2 添加第一条笔记并测试检索初始化完成后我随手添加一条测试笔记验证基本流程caveman add -t test caveman 的第一条笔记记录一下初始化流程 caveman find 笔记 caveman list --tag test预期输出里能看到新笔记的编号、路径和摘要。我当时遇到的一个小问题find返回结果中包含路径本身导致搜索“笔记”会把所有目录名匹配进去。后来我在 FTS 索引里把路径字段单独存储、不参与搜索才解决了这个噪音。如果你自己也做类似的工具记得把机器路径和人工正文分开索引。4.3 高频操作编辑、删除与统计日常使用中高频操作是编辑。caveman edit 20250112-1030-meeting会调用配置好的编辑器打开对应文件保存后工具自动更新索引中的更新时间。删除我用caveman rm它会做一个“软删除”把文件移动到一个trash/子目录而不是直接删除避免手滑造成不可逆损失。最后是stats这个命令会输出一些有趣的数字共有多少条笔记、总字数、今日新增、最常用标签。我会在每周五跑一次简单回顾这周记录了什么也算一种另类周报。说实话看着这些数字一点点增长比打开一个智能统计面板更有成就感。5. 踩坑实录与排查手册5.1 SQLite 锁与多进程并发用 SQLite 做索引很快会遇到一个问题当你在 shell 里同时跑find和add会出现database is locked的报错。这是因为 SQLite 在写操作时会锁整个数据库文件而我的find命令默认开启了一个长时间事务用于读取多张表。解决办法有几种我的最终选择是所有写操作使用 WAL 模式PRAGMA journal_modeWAL;。读取操作的连接设置PRAGMA busy_timeout3000;等待锁释放。单次命令开事务时尽快提交不把用户交互放进事务里。WAL 模式之后并发压力小了很多。这里要多说一句不要把 SQLite 当成服务型数据库用它是一个嵌入式数据库设计目标是单机应用。如果你想要多人同时写入那应该换 PostgreSQL不是改代码能解决的。5.2 中文分词与搜索漏检FTS5 自带好几种 tokenizerunicode61、portuguese、trigram。中文场景下unicode61会把一句话按标点和空格拆导致“联调时间”整体变成一个 token搜“联调”就命不中trigram则把连续三个字符作为一个 token索引体积稍大但对中文更友好。我最终选了trigram并在初始化时把它写进配置。实际测试下来大多数中文关键词都能秒出结果。不过 trigram 也有缺陷搜索词少于三个字符时它索引不到。像“Bug”“OK”这类短词就很尴尬。我的临时方案是当查询词长度小于 3 时回退到LIKE %keyword%的模糊查询。虽然性能略差但个人笔记数据量不大完全可接受。5.3 git 同步里的坑换行符和文件尾部空白如果你把笔记目录放进 git最烦的问题往往不是冲突而是换行符差异。我在 Windows 和 Linux 两台机器上切换使用时git 报告了大量无意义 diff原因是 Windows 默认把换行符转成 CRLF。补救方法是在仓库根目录放一个.gitattributes*.md text eollf这样所有 Markdown 文件统一使用 LF 换行跨平台时不再产生噪音。另一个小坑是编辑器会在文件末尾自动补空行或删掉空行导致笔记文件 diff 不干净。我在config.toml里暴露了post_process开关开启后每次写入前会用 Python 统一做一次 strip去掉多余空白。这种细节听起来不起眼但决定了你愿不愿意长期在命令行里写笔记。6. 关于这个项目我的几点经验如果让我总结做 caveman 最大的收获不是“写了一个工具”而是重新理解了什么叫“够用就好”。我在做它的过程中至少十次想加一点花哨功能比如流程图渲染、数据看板、日历视图最后全都忍住了。每忍一次工具就更稳一分。对于个人工具来说稳定性、可迁移性和低操作成本往往比功能的丰富程度更重要。另一个体会是不要急着写代码先把“不做什么”想清楚。很多项目最后变得难维护不是因为技术复杂而是因为一开始没有边界什么需求都往里塞。caveman 的边界就是“命令行能处理的短文本记录”凡是超过这个边界的需求我都建议用户去用正经的知识管理软件。边界清晰开发省力用户也容易形成正确的使用预期。最后再分享一个细节技巧我把caveman find做成了一个 shell 函数绑定到全局fzf快捷键上。按下Ctrl-F弹出模糊搜索列表选中的条目直接用默认编辑器打开。这个交互体验几乎可以媲美 GUI 软件但背后仍然只是一条命令行工具。在现代化工具越来越重的今天偶尔回头看看“石器时代”的朴素做法反而能带来意想不到的效率提升。 
长河君 · 2026/10/7 12:31:12 · 阅读 1.2k caveman：本地优先的命令行知识管理工具
最近我在整理自己的效率工具链时反复琢磨一个问题为什么现在的笔记、任务管理工具越做越重启动要等加载打开要登录界面上堆满按钮很多功能我一年都用不到一次。后来我发现真正让我每天都离不开的工具反而是那些“原始得让人发笑”的东西文本文件、命令行、快捷键。所以我花了一周时间写了一个叫caveman的小工具。它不搞云端同步不做花哨界面甚至故意拒绝了很多现代功能。设计理念只有一个像石器时代一样笨拙但因此足够靠谱。如果你也受够了重型软件或者想尝试一种更轻的知识管理方式这篇文章会非常适合你。我把整个项目的思考过程、核心实现和踩坑记录都整理在下面。1. 项目起源为什么偏偏叫 caveman1.1 一个工具的自我反思先把话说清楚caveman 不是一个新语言也不是什么大厂开源项目。它是给我自己用的一款命令行知识管理工具用 Python 写的数据全部落在本地文件夹没有任何服务端。取这么个名字是因为我想要的体验本质上就是“史前模式”。如果你用过 Notion、Obsidian 这一类工具可能觉得它们已经很轻了。但对我来说它们仍然有太多体系工作区、权限、数据库、插件市场、缓存的缩略图……真正记一条灵感往往只需要 10 秒工具却要在后台做几百件事。caveman 想做个相反的东西你给它一段文字它就把这段文字存下来再给你一个能用 grep 理解的索引。听起来太简单是的简单就是它的卖点。另一个灵感来自我平时写代码的习惯。我发现自己很多碎片知识最后都散落在 Markdown 文件和代码注释里根本不存在某个软件中。命令行工具的优势在于它和我已有的工作流无缝连接可以放进脚本、配合 git、还能通过 SSH 在服务器上直接用。这种“回归原始”的方式反而让我收集信息的阻力降到最低。1.2 我的真实使用场景在设计 caveman 之前我把自己的需求写在一张纸上只有三条快速记录在终端里敲一句话回车后这条内容必须已经落盘零等待。强力检索支持全文搜索和标签过滤能在一秒内从几千条笔记里找到目标。迁移无痛所有数据必须是纯文本哪天我不想用了直接打开文件夹就能带走。这三个需求恰好都能用“石器时代”的思路满足。我把会议记录、灵感碎片、待办事项、读书笔记全部塞进去用标签区分类型。比如开完会直接caveman add -t work -t meeting 确认Q3排期联调时间下周二一条笔记就进去了。查的时候直接caveman find 联调或者caveman list --tag work。有人会问这些用mkdir加echo不也能实现吗确实能。但 caveman 的价值在于把“散落”变成“约定”统一的文件命名、自动的时间索引、可控的元数据格式。它不是一个全知全能的管理器而是给我提供了一个趁手的默认结构。2. 核心设计先想清楚不做什么2.1 三条铁律本地优先、明文存储、命令交互一个工具好不好用往往不取决于它做了多少而取决于它拒绝了多少。caveman 的设计阶段我给自己定了三条铁律任何功能如果违反其中一条就不做了。第一本地优先。所有数据写在一个本地目录默认是~/.caveman/不存在任何远程同步模块。你可能会担心换电脑怎么办我的方案是把整个目录放进 git这也直接复用了代码项目的版本管理能力。不做云同步的好处是离线可用、没有账号体系、没有隐私外泄风险。对我这种经常在火车上写笔记的人来说这个优势是实打实的。第二明文存储。每条笔记一个 Markdown 文件文件名就是时间戳加单词拼接比如20250112-1030-meeting.md。笔记内容就是普通文本不加密、不进二进制数据库。原因很简单明文是几十年都不会过时的格式任何文本编辑器都能打开哪怕工具本体删掉了数据也还在。第三命令交互。caveman 只通过命令行使用。好处不只是“显得极客”而是它天然可以被脚本化、被参数化。比如你可以写一个 shell 脚本在打包发布失败的时候自动记录一条错误日志也可以挂一个定时任务每天凌晨把过期待办汇总成一份清单。GUI 工具做不到这种嵌合力。2.2 与其他工具的取舍对比为了说清楚设计取舍我列了一张对比表覆盖了我自己用过的几类工具。工具类型数据存储同步方式上手成本自动化能力离线可用Notion远程数据库官方云端中弱弱Obsidian本地 Markdown插件/第三方中中好备忘录厂商云端自动同步低弱中caveman本地 Markdowngit/自管极低强极好从表里能看出caveman 并不是要取代谁。它更像一把螺丝刀而 Notion 那种是瑞士军刀。螺丝刀能做的事很窄但每一次做这件事都又快又稳。对我而言灵感记录、任务钩子、快速备忘恰好是“窄但高频”的场景所以这种极端的取舍是成立的。需要提醒的是这种设计不适合所有人。如果你需要富文本排版、需要多人协作审阅、需要移动端随时随地编辑那 caveman 会非常难受。工具选型从来不存在通解只有适配你自己的使用习惯才是最好的。3. 技术拆解与关键实现3.1 数据模型一个文件夹、两种文件caveman 的存储结构非常简单~/.caveman/ ├── notes/ │ ├── 20250112-1030-meeting.md │ ├── 20250112-1120-idea.md │ └── ... ├── tags/ │ └── work.tag └── index.dbnotes/是笔记正文tags/放标签定义index.db是 SQLite 索引。为什么要索引因为当笔记数量到了几千条以后grep 整个目录虽然也能用但延迟会上升到几百毫秒甚至一秒而且不支持类似“标签与关键词组合过滤”这种语义查询。SQLite 在这里不存正文只存路径、标题、标签、时间戳和一行摘要。检索时先在索引里过滤再按路径读取实际文件。这种“文件为主、索引为辅”的模型是我比较推荐的折中方案。它的核心优势是容错如果索引坏了笔记文件依然在我完全可以用脚本重建索引反过来即使文件被外部编辑器改动了索引也只需要重新扫描一遍目录就能对齐。两边互不绑架数据安全性就高很多。3.2 全文检索与标签索引先看索引表结构这是我多次调整后定下来的最小方案CREATE TABLE notes ( id INTEGER PRIMARY KEY, path TEXT UNIQUE, title TEXT, created_at TEXT, updated_at TEXT, summary TEXT ); CREATE TABLE note_tags ( note_id INTEGER, tag TEXT, FOREIGN KEY(note_id) REFERENCES notes(id) );全文检索我用的是 SQLite 内置的 FTS5 扩展。建一个虚拟表每次写入笔记时把正文拆成关键词塞进去查询时用MATCH语法。FTS5 的好处是零额外依赖、支持中文分词通过 trigram tokenizer、速度极快。对于几千到几万条量级的个人笔记压力完全不是问题。标签索引则走note_tags表。一条笔记可以有多个标签查询时用IN和GROUP BY组合。比如我要找所有同时带work和meeting标签的笔记SQL 大概是SELECT n.path, n.title FROM notes n JOIN note_tags t1 ON t1.note_id n.id AND t1.tag work JOIN note_tags t2 ON t2.note_id n.id AND t2.tag meeting;这里值得注意的细节是不要用WHERE tag IN (...)那得到的是“任一标签”的结果和“同时满足所有标签”完全是两回事。我一开始就踩过这个坑后来才改成多表 JOIN 的写法。3.3 命令设计与交互细节caveman 的命令集刻意保持精简一共就 8 个add、find、list、tag、rm、edit、stats、syncsync 内部只调用 git。我以find为例说明交互设计。一个常见的挫败体验是搜索关键词返回一堆结果但每条都长得很像根本看不出哪个是你要的。所以 caveman 的find输出不是简单的路径列表而是每条笔记后跟一个摘要摘要自动截取命中关键词附近的一小段原文类似搜索引擎的 snippet。实现方式也不难在 FTS5 结果里拿到每个命中的位置偏移再截取前后各 30 个字符。再说add。我加了两个小功能让输入更自然一是-t可以重复传参指定多个标签二是支持从标准输入读取正文这让你可以跟其他命令通过管道组合。例如echo 记得给服务器续费 | caveman add -t ops -t todo这一条命令让我能把系统监控脚本里检测到的异常直接写成一条笔记不需要打开任何编辑器。工具做到这一步我觉得才算真正称得上“工作流的一部分”而不是一个独立的孤岛。4. 从零跑通实操过程全记录4.1 初始化工作区安装 caveman 我用的方式是克隆仓库后直接pip install -e .因为它还处于很早期的迭代阶段没什么必要发到 PyPI。装好后第一步是初始化caveman init --dir ~/caveman-data这个命令会创建上面说的目录结构并生成一份config.toml配置文件。配置里我暴露了四个字段notes_dir、editor、fts_token和auto_sync。auto_sync默认是关闭的打开后每次写操作都会默默检查 git 仓库状态并自动提交。这项功能强烈建议只在已经初始化好 git 的目录里使用否则会遇到一堆因缺少用户配置而失败的报错。4.2 添加第一条笔记并测试检索初始化完成后我随手添加一条测试笔记验证基本流程caveman add -t test caveman 的第一条笔记记录一下初始化流程 caveman find 笔记 caveman list --tag test预期输出里能看到新笔记的编号、路径和摘要。我当时遇到的一个小问题find返回结果中包含路径本身导致搜索“笔记”会把所有目录名匹配进去。后来我在 FTS 索引里把路径字段单独存储、不参与搜索才解决了这个噪音。如果你自己也做类似的工具记得把机器路径和人工正文分开索引。4.3 高频操作编辑、删除与统计日常使用中高频操作是编辑。caveman edit 20250112-1030-meeting会调用配置好的编辑器打开对应文件保存后工具自动更新索引中的更新时间。删除我用caveman rm它会做一个“软删除”把文件移动到一个trash/子目录而不是直接删除避免手滑造成不可逆损失。最后是stats这个命令会输出一些有趣的数字共有多少条笔记、总字数、今日新增、最常用标签。我会在每周五跑一次简单回顾这周记录了什么也算一种另类周报。说实话看着这些数字一点点增长比打开一个智能统计面板更有成就感。5. 踩坑实录与排查手册5.1 SQLite 锁与多进程并发用 SQLite 做索引很快会遇到一个问题当你在 shell 里同时跑find和add会出现database is locked的报错。这是因为 SQLite 在写操作时会锁整个数据库文件而我的find命令默认开启了一个长时间事务用于读取多张表。解决办法有几种我的最终选择是所有写操作使用 WAL 模式PRAGMA journal_modeWAL;。读取操作的连接设置PRAGMA busy_timeout3000;等待锁释放。单次命令开事务时尽快提交不把用户交互放进事务里。WAL 模式之后并发压力小了很多。这里要多说一句不要把 SQLite 当成服务型数据库用它是一个嵌入式数据库设计目标是单机应用。如果你想要多人同时写入那应该换 PostgreSQL不是改代码能解决的。5.2 中文分词与搜索漏检FTS5 自带好几种 tokenizerunicode61、portuguese、trigram。中文场景下unicode61会把一句话按标点和空格拆导致“联调时间”整体变成一个 token搜“联调”就命不中trigram则把连续三个字符作为一个 token索引体积稍大但对中文更友好。我最终选了trigram并在初始化时把它写进配置。实际测试下来大多数中文关键词都能秒出结果。不过 trigram 也有缺陷搜索词少于三个字符时它索引不到。像“Bug”“OK”这类短词就很尴尬。我的临时方案是当查询词长度小于 3 时回退到LIKE %keyword%的模糊查询。虽然性能略差但个人笔记数据量不大完全可接受。5.3 git 同步里的坑换行符和文件尾部空白如果你把笔记目录放进 git最烦的问题往往不是冲突而是换行符差异。我在 Windows 和 Linux 两台机器上切换使用时git 报告了大量无意义 diff原因是 Windows 默认把换行符转成 CRLF。补救方法是在仓库根目录放一个.gitattributes*.md text eollf这样所有 Markdown 文件统一使用 LF 换行跨平台时不再产生噪音。另一个小坑是编辑器会在文件末尾自动补空行或删掉空行导致笔记文件 diff 不干净。我在config.toml里暴露了post_process开关开启后每次写入前会用 Python 统一做一次 strip去掉多余空白。这种细节听起来不起眼但决定了你愿不愿意长期在命令行里写笔记。6. 关于这个项目我的几点经验如果让我总结做 caveman 最大的收获不是“写了一个工具”而是重新理解了什么叫“够用就好”。我在做它的过程中至少十次想加一点花哨功能比如流程图渲染、数据看板、日历视图最后全都忍住了。每忍一次工具就更稳一分。对于个人工具来说稳定性、可迁移性和低操作成本往往比功能的丰富程度更重要。另一个体会是不要急着写代码先把“不做什么”想清楚。很多项目最后变得难维护不是因为技术复杂而是因为一开始没有边界什么需求都往里塞。caveman 的边界就是“命令行能处理的短文本记录”凡是超过这个边界的需求我都建议用户去用正经的知识管理软件。边界清晰开发省力用户也容易形成正确的使用预期。最后再分享一个细节技巧我把caveman find做成了一个 shell 函数绑定到全局fzf快捷键上。按下Ctrl-F弹出模糊搜索列表选中的条目直接用默认编辑器打开。这个交互体验几乎可以媲美 GUI 软件但背后仍然只是一条命令行工具。在现代化工具越来越重的今天偶尔回头看看“石器时代”的朴素做法反而能带来意想不到的效率提升。