先说结论我的笔记最终是用 Markdown 写全部存在自己搭的 NAS 上再用 Git 做版本同步这套组合折腾了大半年之后才算真正稳定下来。期间换过 NAS 系统、换过 Git 托管方式、改过 Markdown 的图片路径规则踩过的坑比想象中多得多。这篇文章就把我从零搭到稳定的全过程写出来包括每一步为什么会这样选、那些网上文档不会写明白的细节以及最后稳定运行的日常维护清单。如果你也正在考虑自建笔记系统或者已经在用 Markdown 但存储同步还在靠网盘这篇文章值得你花十分钟看完。这套方案的核心很简单Markdown 负责统一写作格式NAS 负责数据存储和归档Git 负责版本历史和多设备同步。听起来都是很基础的工具但真正把它们组合成一套能够长期稳定运行的个人知识库里面有不少细节是光看教程学不到的。接下来我按自己的实战顺序把整个系统从设计到落地从头讲一遍。1. 折腾的起点为什么要用 Markdown NAS Git 管理笔记1.1 从云笔记到自建笔记我踩过的一条路我一开始并不是 Markdown 用户最早用的是有道云笔记后来因为工作资料越来越多又陆续试过语雀、OneNote、Notion。每一款都有让我心动的亮点但真正长期用下来都撞上了同一个天花板数据被锁在产品里。有道云笔记的问题是导出太痛苦。我尝试把自己的笔记批量导出成 Markdown结果图片全部变成了私有链接排版乱成一团有些笔记甚至导不出来。语雀在线编辑体验确实好但离线能力弱网络一差连历史文档都翻不动。OneNote 的分区逻辑很自由可一旦笔记量变大搜索和同步都会变得迟钝。Notion 是功能最丰富的但它的数据库由云端服务驱动数据不在我手里这件事始终让我觉得不安。人一旦吃过数据迁移的苦就会本能地往纯文本方案上靠。Markdown 恰好是当前最合适的纯文本格式它没有私有加密没有特殊目录结构本质就是一类带约定的 TXT 文件。用任何编辑器都能打开哪怕十年后整个软件生态都变了文件本身依然可读、可迁移、可转译成其他格式。这也是为什么我最后决定所有笔记内容统一用 Markdown 保存。但纯文本也有两个天然短板一是文件散落各处不好统一管理二是改错了就改错了没有后悔药。前者需要一个大容量、低门槛的存储中心后者需要一套可靠的版本管理方案。NAS 和 Git 分别解决的就是这两个问题。1.2 这套方案解决的核心问题先说存储。NAS 本身就是一台低功耗的小服务器可以把它理解成你家里的私有网盘。它不依赖任何第三方服务硬盘在你手上资料在你家里无论是隐私性还是数据容量都比免费网盘靠谱得多。我现在所有笔记文件、附件图片、扫描件、甚至部分工作素材都统一放在 NAS 上笔记本只保留一个同步缓存。再说版本管理。Git 最常见的用途是管理代码但它的核心能力并不是“处理代码”而是跟踪文本文件的每一次变更。我只要把 Markdown 笔记目录变成 Git 仓库每次写完内容提交一次系统就会自动记录下文件的全部历史版本。哪天写崩了一段结构直接回滚到上一个 commit 就行再也不用靠“最终版”“最终版2”“再也不改版”这种文件名来维持生活。最后是写作格式。Markdown 语法少、上手快标题、列表、引用、代码块、表格这些写作时最常用的元素半小时就能全部学会。比起 Word 那种“所见即所得”Markdown 让我把注意力集中在内容本身排版的事情交给后续渲染。对我来说这比什么都重要。这套方案特别适合几类人长期做技术笔记、写作或者知识管理的人不想把私人资料放在别人服务器上的人忍受不了网盘同步冲突的人以及喜欢自己折腾、希望所有数据都可迁移、可备份、可审计的人。2. 整体架构存储、同步、写作三层拆分搞定“为什么用”之后更重要的问题是“怎么把它们组织在一起”。我采用的是很朴素的三层架构存储层放文件同步层管变更写作层出内容。每一层只干一件事互相之间不耦合这样后面任一层出问题都不会影响其他两层。2.1 存储层NAS 与目录设计存储层是所有笔记文件的物理归宿也是整套系统的地基。我的 NAS 上建了一个顶层共享目录notes内部再按使用场景拆成几个子目录notes/ ├── inbox/ # 临时收集灵感和草稿统一先进这里 ├── projects/ # 按主题项目组织的长期笔记 ├── archives/ # 已完成、不再频繁编辑的内容 ├── assets/ # 笔记中引用的所有图片和附件 └── templates/ # 写作模板这个目录结构看起来简单但每一条都有讲究。inbox是笔记系统里非常重要的概念它解决的是“收集和整理冲突”的问题。以前我总是一边记录一边分类结果写一会儿就要停下来想“这篇该放哪个文件夹”严重打断思路。现在所有新内容无条件先进inbox每周固定一次集中归档记录的速度快了很多。assets是我最后悔没有早点建立的目录。早期我的 Markdown 笔记里图片经常和正文放在同一个目录文件一多就乱得没法看。后来统一规定所有图片一律放在assets并且按日期分二级目录比如assets/2026-03/。这样正文目录干净清爽备份和迁移也都只需要盯住assets一个地方。2.2 同步层Git 仓库与多设备工作流同步层是这套系统里技术含量最高的部分。我的方案是在 NAS 上建一个纯 Git 仓库bare repo笔记本、台式机、还有手机端的小工具都把这个仓库 clone 下来各自维护一个工作副本。写作时在本地提交需要多设备统一时直接 push/pull。这里的关键是NAS 上只存仓库历史不直接作为工作目录。很多人第一次把 Git 和 NAS 结合时会直接在工作目录里写代码但这种方式在多设备同步时容易产生文件锁冲突而且 NAS 上的文件如果被其他 SMB 客户端直接修改Git 历史就乱了。在 NAS 上建立裸仓库意味着所有设备都只通过 Git 协议访问它数据变更全部走 commit可控性高得多。为什么不用网盘同步因为网盘同步的核心逻辑是“文件级同步”两台设备同时修改一个文件时它只会机械地生成一个“冲突副本”根本没法帮你判断哪个版本该保留。Git 的逻辑是“变更级合并”它会逐行对比文本内容自动完成大部分合并实在合并不了才会要求人工介入。对于 Markdown 这种纯文本笔记来说Git 的合并能力几乎是降维打击。2.3 写作与渲染层Markdown 工具链写作层解决的是“怎么写”和“怎么读”的问题。我平时用的编辑器是 VS Code 加 Markdown 插件也经常用 Typora 做快速记录。Sublime Text 我也留着用来查看那些不需要写、只需要没事翻一翻的旧笔记它打开大文件的速度明显比 VS Code 快。渲染方面我做了两层。第一层是本地预览Typora、Obsidian 这类工具都可以直接渲染 Markdown公式、表格、流程图都支持。第二层是静态站点输出我会定期把笔记里的部分内容生成一个静态页面放到局域网里方便在手机和阅读器上浏览。这个用 mdbook 或者直接写个脚本批量转换都行属于锦上添花但体验提升很明显。2.4 为什么最终没有选现成笔记软件可能有人会问Obsidian 不也能双链、也能本地存储吗为什么不直接用我的回答是工具功能越多长期维护成本越高。Obsidian 本身确实很优秀它的知识图谱和双链体系做得很好但它对数据的管理方式是“自家数据库 附属文件”一旦同步出问题排查起来比裸文件加 Git 复杂得多。另外笔记软件的问题不只是同步还有插件生态的脆弱性。今天装一个漂亮的插件明天它不更新了你的笔记里可能就多一堆失效语法。而纯 Markdown Git 这套组合每一个环节都是开放标准都有无数替代品。编辑器挂了我换编辑器NAS 系统崩了我换个系统把硬盘插上继续跑Git 仓库坏了还有裸文件兜底。对想要长期维护知识库的人来说这种“随时可以抽身离开”的自由度比任何花哨功能都值钱。3. NAS 搭建之路硬件、系统与挂载我自己在 NAS 搭建上折腾的时间不短从拿旧电脑直接刷系统到后来换上低功耗 CPU 重新组装前前后后换过三套方案。这一章把选型和今天说得比较多的几个关键点一次说清楚。3.1 系统选型飞牛、群晖、TrueNAS 该怎么选NAS 系统的选择直接决定了你后续几个月是不是愉快。我自己用过群晖 DSM也刷过飞牛 fnOS还短暂试过 TrueNAS三者的定位其实很不一样。群晖的问题是“省心”。它的 DSM 系统成熟稳定套件中心里几乎所有常用功能都能一键安装如果你是第一次接触 NAS、不想和配置文件搏斗群晖是下限最高的选择。代价是硬件门槛偏高官方机型不便宜用黑群晖又涉及引导和网卡驱动的折腾。TrueNAS 是纯存储路线它的 ZFS 文件系统在数据完整性方面非常强很多老玩家迷恋它的快照和 Scrubbing 定时清洗。但 TrueNAS 对硬件要求高内存和 ECC 配置不到位ZFS 的优势很难发挥出来而且它的应用生态相对贫瘠跑个容器、装个网页服务都要自己动手不适合我这种要兼顾多个服务的场景。飞牛 fnOS 是我现在的主力也是最近社区里讨论热度最高的 DIY NAS 系统。它免费、对 x86 老电脑兼容性好自带 Docker 和网盘同步套件界面做得很现代。我拿一台闲置的旧电脑和一块淘汰硬盘刷上飞牛前后不到半小时就进入了可用状态。更关键的是它支持比较常见的存储管理方式普通用户也能直接建立存储空间不像 TrueNAS 那样上来就让人面对“池”和“数据集”的概念。选型建议就一条想要稳定省电就选群晖或成熟的商业系统手里有旧电脑想低成本折腾就优先飞牛真正追求数据完整性且愿意付出学习成本再上 TrueNAS。3.2 硬件避坑J4105、3865U 和老电脑的差距硬件是我最早踩坑的地方。最开始我图省事直接拿一台攒了十年的老台式机刷系统结果整机功耗四五十瓦风扇声音比冰箱还大放在书房里根本没法忍。后来我才认真对比了当时讨论度最高的两款低功耗 CPUJ4105 和 3865U。J4105 是四核四线程TDP 10W核显性能尚可用来跑 Docker 容器、做视频转码、同时挂几个轻量服务完全够用。3865U 是双核四线程同样低功耗但性能明显弱一截同样的容器任务跑起来 CPU 占用率经常到 80% 以上。表格里直接对比最直观项目J41053865U核心线程4核4线程2核4线程TDP10W15W核显够用支持硬件转码较弱Docker 场景可以跑多个轻量服务不适合重载二手主板价格稍高便宜我的建议非常明确如果你准备玩 DIY NAS至少从 J4105 这个级别起步不要为了省几百块买 3865U。NAS 上跑的服务会越来越多性能余量比想象中更重要。现在网上也有不少人拿电视盒子、旧手机刷 NAS 系统的玩法比如一些电视盒子的刷机包很新颖也很省钱但这类方案往往有容量和扩展性的硬伤只适合当玩具不适合放真正的数据。3.3 存储规划与权限系统和硬件都定了接下来就是建存储空间和共享文件夹。这一步看起来简单但很多新手在“NAS 没有可用的存储位置”这个问题上卡了很久。拿小白问得很多的应用场景举例想给家里的摄像头配 NAS 存储结果在摄像头 App 里选择存储位置时显示“没有可用的存储位置”。为什么会这样因为摄像头是通过 SMB 协议访问 NAS 的系统里必须存在一个允许匿名或者指定账号访问的共享文件夹而且权限设置要把“可写”打开。很多人只建了存储空间没有创建共享文件夹或者创建了但权限不对导致摄像头根本看不到可用目录。所以我的建议是拿到 NAS 第一步别急着往里丢文件先把目录结构、用户账号、共享权限一次想清楚。我目前的权限模型很简化管理员账号用于日常维护普通用户负责笔记同步摄像头等设备单独建一个专用账号并且只读部分目录。这样各服务之间互相隔离就算某个终端被入侵影响范围也是有限的。3.4 Linux 与 Windows 挂载 NAS 的三种方式存储空间建好以后还要让笔记本和台式机能够访问它。挂载方式具体看系统Windows直接在资源管理器地址栏输入\\192.168.x.x\notes再映射成网络驱动器最省事。macOSFinder 里按 CmdK输入smb://192.168.x.x/notes也可以加进“登录项”实现开机自动挂载。Linux需要安装cifs-utils然后在/etc/fstab里写一条挂载记录。Linux 的写法大概是这样的sudo apt install cifs-utils sudo mkdir -p /mnt/nas/notes sudo mount -t cifs //192.168.x.x/notes /mnt/nas/notes -o usernamenotes,uid1000,gid1000,iocharsetutf8,vers3.0重点是vers3.0这个参数。早期我挂载时一直报权限错误排查到最后才发现是 SMB 协议版本默认协商到了 1.0而新版 NAS 系统已经默认关闭 SMB1。把所有设备都强制使用 SMB3 之后挂载问题彻底解决。这条经验后来我也写进了自己的部署文档因为社区里问“Linux 挂载 NAS 失败”的帖子实在太多了。4. Git 配置与同步细节NAS 到位以后剩下的大工程就是 Git 的配置和日常同步。这一章我按实际操作的顺序写从安装命令到免密配置再到分支策略和过滤规则每一步都有能直接用上的细节。4.1 Git 安装与初始化Windows 上安装 Git 比较简单直接去官网下载 Git for Windows 安装包一路默认配置即可。需要注意的一个小地方是安装时选择“Checkout as-is, Commit as-is”避免跨平台时换行符被自动转换把 Markdown 文件改出莫名其妙的差异。Linux 上安装更简单sudo apt update sudo apt install git安装完以后第一件事不是建仓库而是先配置用户信息否则后续每次 commit 都要报错。笔记仓库和代码仓库我个人会分开配置因为笔记的提交者我希望统一显示为一个身份。命令是这样的git config --global user.name yourname git config --global user.email youexample.com接下来就是初始化仓库。我在 NAS 上建立一个裸仓库mkdir -p /srv/git/notes.git cd /srv/git/notes.git git init --bare然后在本地把仓库 clone 下来git clone ssh://notes192.168.x.x/srv/git/notes.git这套操作对于写过代码的人来说属于基本操作但对从没接触过 Git 的笔记用户最需要理解的一点是bare 仓库没有工作区它只存储历史数据不可以直接在里面看到文件列表。所有编辑都在 clone 下来的本地目录里完成push 上去之后NAS 里并不会生成一份可浏览的文件副本。这也是很多新手第一次搭建时最大的困惑。4.2 SSH 免密登录与认证失败排查每次 push 都输密码肯定不能忍所以我第一时间配了 SSH 免密登录。流程是先在本地生成密钥对再把公钥放到 NAS 上对应用户的authorized_keys文件里。ssh-keygen -t ed25519 -C notes -f ~/.ssh/id_ed25519生成过程中一路回车即可如果怕私钥泄露可以加 passphrase。然后把公钥复制粘贴到 NAS 的~/.ssh/authorized_keys里。这一步我踩过最大的坑是权限问题authorized_keys文件权限如果太宽松SSH 会直接忽略它。正确权限是chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys“SSH 认证失败”这个话题的热度一直很高原因其实就那么几种。最常见的是公钥没写对文件或者文件权限不对其次是 NAS 上 SSH 服务配置里禁用了公钥认证还有一种情况是本地known_hosts中记录了旧的主机指纹换了系统或重装以后指纹变了SSH 会拒绝连接。遇到认证失败时先看日志、确认服务端有没有收到请求再检查权限和指纹基本都能快速定位。4.3 常用命令与分支合并策略笔记同步不需要像代码协作那样搞复杂流程但我还是保留了一套简单但清晰的 Git 使用习惯。日常写笔记时的标准流程是git status git add . git commit -m 2026-03-24 更新XXX笔记 git push在另一台设备上只需要一条命令git pull这套流程足以覆盖 90% 的日常需求。真正需要的注意的其实是分支策略。我目前用的是一个长期main分支配合临时分支的做法如果要改写一篇大笔记我会新建一个draft/xxx分支在分支里改完、确认没问题后再合回main。这样做的好处是大改动过程中即使写到一半没写完main分支始终是稳定的。合并时我不太用 rebase主力用 merge 加--no-ff。原因很简单merge 会保留完整的提交历史每次合并的上下文一目了然而 rebase 会把提交记录改写成一条直线历史看起来干净了但丢失了“这件事是从哪条线合并进来的”这个信息。对个人笔记来说查找历史比历史好看更重要。4.4 .gitignore 过滤与图片目录管理Git 仓库是纯文本系统但 Markdown 笔记里会包含图片等二进制文件所以.gitignore和资源目录管理必须提前想好。我的.gitignore内容很简单.DS_Store Thumbs.db *.tmp ~$* node_modules/ .obsidian/workspace最容易被问爆的问题是“我明明写了 .gitignore但文件还是被提交上去了”。原因基本上只有一个这个文件在写过滤规则之前就已经被 Git 跟踪了。Git 的 ignore 规则只对“未被跟踪”的文件生效文件一旦被git add过就算路径匹配 ignore 规则也不会自动停止跟踪。解决办法是先把它从索引里移除git rm --cached .obsidian/workspace上面这句只会移除跟踪状态不会删除本地文件。这个操作我几乎每隔一段时间就要用到一次建议所有刚接触 Git 的笔记用户直接记下来。5. Markdown 写作细节与工具链底层架构全部搞定以后最影响每天使用体验的反而是 Markdown 本身的一些细节。同一个语法在不同编辑器和渲染器里表现可能完全不一样踩过的坑我集中放在这一章。5.1 换行、表格、Callout 这些基础语法坑先讲最容易忽略的换行。Markdown 里直接敲一个回车在部分渲染器里不会产生新段落只会变成一个空格。标准写法是想要换行不换段在行尾加两个空格再回车想要真正分段空一行。这个规则我在 Electron 系编辑器里经常踩因为快捷键和预览行为各不一样。再是表格。Markdown 表格源码写起来不复杂但复制粘贴是重灾区。从表格里复制内容到 Excel经常出现整个表格变成一列的情况因为剪贴板里丢失了制表符和结构信息。我自己常用的解法是先在在线 Markdown 表格编辑器里生成好结构再粘贴成纯文本写进笔记需要转成 Excel 的时候用专门的转换工具比如直接给 Python 写个小脚本解析表格语法一次就能转成 CSV 或 xlsx。还有一个很多人问过的语法是 GitHub 风格的 Callout。在一些笔记工具里你可能会看到带[!NOTE]的引用块这就是常见的提示框语法。我写操作指南时经常用它比普通引用块更醒目适合放注意事项和警告信息。支持的编辑器不算多但它作为“未来兼容格式”的价值在增加。5.2 数学公式与 Markdown 公式生态凡是写过数学相关笔记的人迟早会遇到公式问题。Typora、Obsidian、VS Code 的 Markdown 预览一般都能渲染 LaTeX 风格的数学公式但前提是编辑器内置了对应的解析器。如果你用的是轻量编辑器就需要自己装一个 Markdown 数学公式插件或者通过浏览器渲染方案把 KaTeX/MathJax 引进来。行内公式用一对$包裹块级公式用两对$$包裹。最容易写错的是包含大括号的多行公式比如分段函数这种$$ f(x) \begin{cases} x, x \geq 0 \\ -x, x 0 \end{cases} $$这里的换行符\\和分隔符经常被漏掉导致公式渲染出来挤成一行。我自己的经验是写完公式先看预览再检查有没有遗漏\\。尤其是从 Word 或 LaTeX 文档迁移过来的公式迁移过程中最容易出现转义符号丢失的情况。5.3 图片路径策略相对路径、NAS 目录与 Git图片路径是 Markdown 笔记里最影响稳定性的因素之一很多人写着写着图就挂了。核心规则只有一条永远使用相对路径绝对不要使用绝对路径。例如笔记文件位于projects/ops/note.md图片位于assets/2026-03/diagram.png那么正确的引用写法是使用相对路径的好处是整个notes目录无论在哪个位置、哪台设备上只要本地目录结构一致图片就不会断。相对路径配合 Git 就更稳了图片作为文件同步进仓库多设备 pull 下来之后引用依然是通的。那 NAS 在这里的作用是什么我的处理是分两级小图片直接进assets目录跟随 Git 走大体积素材比如扫描件、PDF、视频不进 Git 仓库统一放 NAS 的另一个共享目录Markdown 里用 NAS 路径引用。这样既不影响笔记仓库的轻量也能利用 NAS 的大容量。Git 对大二进制文件的支持不理想除非上 Git LFS否则不建议把大素材提交进仓库。5.4 Linux 阅读器与 Sublime Text 的组合用法写作链定下来以后阅读链也值得说几句。Markdown 文件本质上就是一个文本文件所以在 Linux 上最轻量的打开方式其实是直接cat或者less但想看排版的话我平常会用这几类工具Sublime Text 装一个 Markdown 预览插件可以直接在编辑器里实时渲染Obsidian 和 Typora 也支持直接渲染完整语法命令行下我偶尔用glow它能把 Markdown 渲染成带样式的终端内容非常方便。Sublime Text 读 Markdown 的优势在于轻量、启动快适合只读不改的场景。我通常会开一个窗口专门放“已归档笔记”有事翻一下不打扰主要工作区。它在处理大文件时尤其稳打开几百 KB 的 Markdown 源码几乎感觉不到卡顿。关于转换我得提一下有道云笔记时代的痛当时想把笔记转成流程图又没有导出结构只好重新在另一个工具里画一遍。现在有了 Markdown 文本文件很多转换工作流都能自动完成。社区里已经流行过一段时间用工作流工具把 Markdown 转成 Word、把大纲转成流程图的做法原理都是解析 Markdown 的标题层级和表格结构再映射到目标格式。我平时批量把笔记导出成 Word 文档给同事时也总结了一条固定流程先用 Pandoc 做基础转换再用自动化脚本处理表格和图片路径一次能解决数十篇文档的转换需求。6. 踩坑实录稳定运行前我修过的那些问题最后这部分写下我在实际维护过程中遇到频率最高的问题以及对应的排查思路。很多坑单独看都不严重但连续撞上几次非常打击继续维护的动力。6.1 常见问题速查表现象最常见原因解决方案SSH 认证失败每次 push 都要输密码公钥权限不对或 known_hosts 指纹过期检查~/.ssh权限为 700authorized_keys为 600必要时清除旧指纹Git 提交后 .gitignore 仍然无效文件在写规则前已被跟踪使用git rm --cached file取消跟踪SMB 挂载 NAS 失败或无法访问SMB 协议版本不对或共享权限不足强制指定vers3.0确认共享目录可写Markdown 里图片不显示图片路径用了绝对路径或相对层级不对统一改成基于 notes 根目录的相对路径多设备同步后出现大量冲突两台设备同时大幅修改同一文件建立分支合并习惯或者按日交替编辑公式渲染成乱码大括号公式缺少\\换行或对齐符号检查公式转义用预览对照源码NAS 提示没有可用存储位置未创建共享文件夹或权限不匹配在 NAS 管理页面创建共享目录并配置账号权限上面这张表我自己打印过一份贴在了显示器旁边很多问题看一眼就能定位不用重新上网查半天。6.2 我的排查方法论遇到问题后我先明确一件事这三层架构里到底是哪一层出了问题。存储层看 NAS 日志和共享状态同步层看 Git 输出和 SSH 日志写作层看编辑器预览和转换结果。分层排查的好处是不会在错误的方向上浪费几个小时。举个例子有一次我发现手机上的笔记无法 pull 新内容第一反应是 Git 配置出问题了折腾了半天服务器端结果最后发现是手机连的是访客 Wi-Fi压根没进内网。这种最基础的连接问题经常被忽略。后来我的排查顺序固定成网络连通性 → 认证 → 服务状态 → 软件配置。看起来是老生常谈但真的能省下大量时间。还有一个特别值得养成的好习惯在 NAS 和笔记本上各开一个定期巡检脚本检查磁盘空间和 Git 仓库状态。我曾经因为没有及时清理 Git 历史里的旧文件导致整个仓库体积膨胀到几个 GBpush 变慢到难以忍受。后来用git gc定期清理对象仓库体积下降了接近一半。6.3 日常维护清单稳定运行不是搭完就结束而是靠持续的小维护堆出来的。我这个月跑的维护清单大概是这样每周给 NAS 做一次存储空间检查磁盘占用超过 80% 就启动归档。每周归档一次inbox目录把临时笔记归入正式分类。每次关电脑前把当天改动的笔记 commit 一次push 到 NAS。每两周对 Git 仓库执行一次git gc清理历史对象。每个月做一次全量备份不光是 NAS 到外置硬盘的整体备份还包括 Git 仓库单独导出。每季度检查一次系统更新尤其是 NAS 系统和 Git 版本的安全更新。这套清单看起来每个动作都很小但叠加起来就是“稳定运行”这个结果背后的主要原因。如果你也准备照着这条路搭一套自己的笔记系统我个人最想给你的一条建议是不要一上来追求完美。先把 Markdown 写好再让 NAS 接管文件等 Git 同步稳定了再回头优化目录和格式。表面上每一步都是小事但当你坚持三个月后回看会发现这套体系早已成为你收集、整理、复用知识的底仓。这种自己亲手搭起来、完全受控的知识系统用起来踏实感是没有替代品的。