圆角骑士魔理沙你有没有过这种经历：一本封面好看的本子买回来，认认真真写了两页，之后就变成杂物堆里的收藏品。手机里的日记App下了又删，越换越没安全感，总觉得自己写的东西被握在别人手里。我的答案也是“有过”，而且这个状态反复持续了很多年。直到我决定不再寻找完美的工具，而是自己动手做一套真正能长期用下去的本地记录系统，名字就叫维克日记。它不是什么大项目，不依赖任何云服务，核心只是一个文件夹、一堆Markdown文件、一个Git仓库，外加几个小脚本。但就是这套看起来简陋到不行的组合，让我把写日记这件事从“坚持”变成了“习惯”，并且已经连续记录两年多没断过。
这篇文章写给两类人：一是试遍各种日记App都觉得不对劲、想拿回数据主动权的人；二是本来就有记录习惯，但想建立一套可检索、可复盘、能活很久的日记体系的人。我把整套系统的设计思路、踩过的坑、打磨出来的字段模板和脚本都摊开讲，你不需要是程序员，照着抄就能用。
1. 为什么我会反复折腾“维克日记”这套系统
1.1 那些年我用过的记录工具
先说我的背景：我是一名普通文字工作者，日常大量时间在电脑前，也写过几年博客。按理说“写日记”这件事应该不难，但我前前后后折腾了七八年，一直没找到能坚持下来的方式。
最早用纸质本子，问题很明显：没法搜索，写满一本之后塞进书架，基本不会再翻开。后来开始用博客、笔记软件。可以说市面上主流的产品我基本都试过，从早期的OneNote到后来的Notion、Day One，数据格式千奇百怪。每次换工具都像一次逃难：要手动导出、处理格式错乱、丢失标签，折腾一圈下来，写日记的热情早就被消磨没了。
真正让我下决心自己做一套系统，是因为一次数据丢失。有一年我用了大半年的某个日记App突然停止了同步服务，虽然官方说可以导出，但导出来的文件是一堆结构混乱的JSON，我找第三方工具折腾了整整一天，才勉强把纯文本捞出来。那一刻我意识到：只要内容存在别人的服务器上、存在某个私有格式里，我就永远没有真正的控制权。日记这么隐私的东西，我不想再为厂商的“业务调整”买单了。
1.2 维克日记的三个核心目标
经过那次教训，我给自己的日记系统定下三个硬性目标：
第一是可控。数据必须是我的，存本地，格式必须开放，任何一台能打开纯文本的设备都能读取。我不希望十年后还要为“怎么打开几年前的文件”发愁。
第二是可检索。日记不是写完就封存的文物，我要能在五年后快速翻出“去年春天我到底在焦虑什么”“2023年我去过哪些地方”这类问题的答案。这就要求内容里必须有结构化信息，不能纯靠人脑回忆。
第三是可延续。这套系统不能依赖任何单一软件厂商的存续，也不能依赖我自制的复杂工具链。如果哪天我突然不想维护脚本了，它最核心的部分——那堆Markdown文件——依然完好无损，还能继续写。
维克日记这个名字其实就是一套承诺：像人名一样稳定，像老朋友一样随时可以回去翻。
1.3 这套系统并不适合所有人
我在分享这套方案时经常被问“你直接推荐个App不就行了”，说实话，对大部分人来说，现成的App确实更好。如果你只想每天睡前用手机记录三五行心情，不在乎数据归档，也不打算做年度复盘，那手机上任何一个口碑不错的日记App都比我这套方案省事。
维克日记适合的是这样的用户：你能接受一点命令行操作，愿意维护自己的文件夹，对数据隐私有执念，并且有做“月度复盘”“年度回顾”的打算。它不适合“工具驱动力”很强的人——那种喜欢把系统越搞越复杂、最后每天花一小时维护工具而不是写日记的人。我后面会专门讲“自动化克制”，因为我自己在这上面摔过跟头。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我的方案选型：从纸笔到本地Markdown，再到Git版本管理
2.1 为什么最终选了Markdown而不是App或富文本
选型这件事我纠结了很久。市面上笔记格式五花八门，但拆开看本质就三类：富文本格式（docx、pages）、私有云格式（各家笔记软件的专属格式）、纯文本格式（txt、Markdown）。
富文本看起来功能强，但本质上是一个“黑盒”。docx文件虽然通用，但它的样式、图片、表格都藏在压缩包里，一旦用代码处理就会遇到各种编码问题。而各家的私有格式就更不用说，换工具等于重头开始。
Markdown的优势在于它只是“带简单标记的纯文本”。你用任何编辑器打开它，看到的都是可读的原始内容；你用Git做版本管理，每次改动差异一目了然；未来想转换成PDF、HTML、Word，一个命令就能搞定。它最大的好处是“无聊”——不会逼你停留在某个生态里，也不会因为某个软件停止更新而失效。
我见过有人用Excel写日记的，也见过用思维导图写日记的，都能写，但后续处理成本很高。Markdown是平衡“记录体验”和“长期可维护性”的最优解。
| 方式 | 可搜索性 | 数据控制权 | 长期可读性 | 写起来的手感 |
|---|---|---|---|---|
| 纸质本子 | 几乎为零 | 完全可控 | 会发黄破损 | 最好 |
| App（私有格式） | 好 | 不确定 | 取决于厂商 | 好 |
| Word/富文本 | 一般 | 可控 | 一般 | 一般 |
| Markdown | 好 | 完全可控 | 极好 | 看编辑器，可好可坏 |
2.2 Git版本管理到底解决了什么
很多人以为Git是程序员专属工具，这完全是误解。Git本质上就是一个“带时间机的文件夹”，它记住你每一次修改，让你可以随时回到过去任意版本。对日记来说，这解决了一个特别实际的痛点：手滑删了内容、改错了没保存、想找回三个月前写的某个段落。
我有一个真实经历。某天我在整理旧日记时，用编辑器的“查找替换”功能把所有“今天”替换成了“当日”，结果把我去年写的几十篇日记里的时间表述全改了。当时真是一身冷汗，但因为日记仓库一开始就初始化了Git，一行命令就全部恢复原样，连改动的痕迹都保留着。如果没有Git，这就是一次不可逆的灾难。
Git还带来了一个额外的副产品：远程仓库同步。我把日记仓库推到一个私有远程仓库，这样即使电脑硬盘报废，数据依然在别处有一份完整拷贝。它同时充当了“备份副本”和“版本历史”两个角色。
当然，我懂大部分读者可能没接触过Git。实际用下来，你只需要掌握五个命令就够日常使用：git init（初始化仓库）、git add（暂存改动）、git commit（提交版本）、git push（推送到远程）、git log（查看历史）。不需要理解什么分支合并、rebase，那些在日记场景里根本用不上。
2.3 目录结构与文件命名规则
目录结构我设计得很简单，按时间维度组织：
code复制vik-diary/
├── journals/
│ ├── 2024/
│ │ ├── 2024-01/
│ │ │ ├── 2024-01-03.md
│ │ │ ├── 2024-01-04.md
│ │ │ └── ...
│ │ ├── 2024-02/
│ │ └── ...
│ ├── 2025/
│ │ ├── 2025-06/
│ │ │ ├── 2025-06-01.md
│ │ │ ├── 2025-06-02.md
│ │ │ └── ...
│ └── ...
├── templates/
│ └── daily.md
├── scripts/
│ ├── new-day.sh
│ └── monthly-review.py
└── reviews/
├── 2025-06-review.md
└── 2025-annual-review.md
文件命名统一用 YYYY-MM-DD.md。这个格式的好处是：按字典序排列时，天然就是时间顺序；脚本处理时可以直接用文件名拿到日期；不会有“2025.6.1”和“2025-06-01”混用的尴尬。
同一日期如果写了多篇（比如早上的随手记和晚上的完整日记），我会用后缀区分：2025-06-11-morning.md、2025-06-11-night.md。不要用“最终版”“修改版2”这种名字，相信我，你会后悔的。
2.4 编辑器的选择：别让工具绑架内容
编辑器方面我前后换过好几个，现在的结论是：核心内容只依赖Markdown本身，编辑器只是外衣。我用过Typora，流畅、专注，但后来它收费了；我用过VS Code，功能强大但界面太重，写日记容易分心去折腾插件；目前主力是Obsidian，因为它在本地文件夹之上提供了很好用的标签浏览、关系图谱和日记插件，但这些功能又不会污染原始文件——你随时可以退出Obsidian，用记事本打开同一个文件夹。
这里想强调一个反过来的坑：不要因为某款编辑器好用，就依赖它特有的格式扩展。比如有些笔记软件支持“双链”“块引用”，这些在它自己的生态里很好用，但导出的Markdown文件里会塞入一堆专有语法，换工具之后全是乱码。我在选型时给自己定了一条规矩：任何依赖特定编辑器才能渲染的格式，一律不用。日记文件要朴素到可以直接用 cat 命令在终端里查看，这是底线。
3. 日记字段设计：如何让流水账变成可检索的人生索引
3.1 每条日记的字段到底该设多少
从“能坚持写”的角度看，字段越少越好；从“可复盘”的角度看，字段太少了很难做结构化回顾。我经过反复调整，最终沉淀出这样一组字段，放在每篇日记的最前面：
code复制日期：2025-06-11
天气：晴
地点：家
情绪：平静 → 烦躁 → 平静
标签：工作, 冲突, 反思
事件类型：工作
日期和地点好理解，不多说。天气看似无关紧要，但多年后回看时，它是一个非常强的场景还原钩子。“2024年6月3日，下着暴雨，我在出租屋里写下了这段话”——有了天气，记忆会自动补全很多细节。
事件类型我划分得很少，只保留了六个枚举值：工作、家庭、社交、健康、兴趣、生活琐事。这种粗颗粒度是刻意为之。如果分类太细，写日记时会在“这件事到底算人际还是社交”上纠结，摩擦成本一大，坚持就很难了。
3.2 为什么情绪字段比很多人想的重要
情绪字段是我整个系统里最重要的设计，也是我用了大半年之后才真正体会到价值的字段。
最开始我觉得情绪这东西写不写无所谓，反正在正文里也会流露。但后来做月度复盘时发现，人对自己情绪的回顾偏差极大。我经常会错估自己“上个月大部分时间很开心”，但翻看数据时，情绪字段里记录的大多是“疲惫”“焦虑”“低落”。反而是那些被我标记“开心”的日子，衬托得非常珍贵。
所以后来我把情绪字段设计成了两部分：一个基础情绪词，加一个1到5的强度值。比如“焦虑 3/5”“开心 4/5”。这样既保留了主观感受的颗粒度，又能画出一条情绪波动的折线，年底做回顾时看得一清二楚。
我最终采用的基准情绪词只有八个：平静、开心、满足、疲惫、焦虑、低落、烦躁、愤怒。不要用“微妙”“复杂”“还行”这种模糊词，统计时你会感谢自己的克制。
3.3 标签体系：维度要少，颗粒度要粗
标签是比事件类型更灵活的一层索引。我的规则是：整本日记的标签总数控制在十五到二十个以内，比如“工作、写作、阅读、电影、健身、旅行、家人、朋友、健康、灵感、冲突”。我刻意避免在每篇日记里发明新标签，因为标签一旦过多，就失去了检索的意义。
标签的核心价值是回答“我想串联一类事情”。比如我想知道“过去一年我到底跟家人相聚过多少次”，直接搜索标签“家人”就能一次性调出。如果我用的是“2024年6月妈妈来北京”这种长尾描述当标签，那这条信息就石沉大海了。
实际操作中，我还会在正文里用 #标签名 的格式重复一次标签，这纯粹是为了方便全文搜索和Obsidian的自动索引。模板字段里的标签是给人看的，正文里的标签是给机器看的，两者配合，检索效率翻倍。
3.4 每日模板：让填写成本降到最低
有了字段就得有模板。我的 daily.md 模板长这样：
code复制# {日期}
## 天气
## 地点
## 情绪
## 标签
## 事件类型
## 事实
（今天发生了什么，客观描述）
## 情绪与感受
（写真实情绪，允许口语化）
## 反思
（一个值得注意的问题或收获）
## 下一步
（明天要做的某一件事）
你可能注意到了，模板里的“反思”和“下一步”并不是强制填写的。我允许它们留空。为什么？因为如果每个字段每篇都要求写满，日记就变成一个巨大的心理负担，而负担是习惯的头号杀手。留白反而让我在真正有值得反思的事情时，写得更认真。
这个模板是我迭代了将近四个版本才定下来的。早期版本字段更多，比如有“通勤路线”“饮食记录”“今日消费”这种细碎项，后来发现这些内容要么很难坚持填，要么对复盘没有实际帮助，就全砍了。做减法之后，整个系统突然变得轻盈起来。
4. 写作规则：动静分离，让记录沉淀为可复盘的内容
4.1 事实与情绪分开写，这是整套系统最核心的写作规则
大多数人写日记是混着写的：“今天老板又骂我了，气死了，这破工作一天都干不下去。”这样写没问题，情感够真实，但复盘价值很低。
我给自己定了一条硬规则：事实区和情绪感受区分开。事实区只写客观发生了什么，不带判断和形容词。“老板在周会上指出我报告里的图表数据有误，要求今天下班前修正。”情绪区可以尽情宣泄：“感觉很丢脸，觉得被针对了，不想面对。”两者分开后，好处立刻显现：第一，事实不会因为情绪而扭曲；第二，一个月后回看时，我能清楚地区分“那件事本身”和“我当时对那件事的看法”，进而看到自己的情绪模式。
这条规则背后有一个心理学常识：人在强烈情绪下，会把“对事件的解读”当成“事件本身”。分开写，实际上是在训练一种“观察者视角”。久了之后，你会慢慢发现自己处理冲突的能力在变强。
4.2 反思区：只写可行动的问题，不写自我审判
我的反思区有一个非常具体的写作约束：尽量以“问题”的形式呈现，而不是以“自我评价”的形式。比如，我不写“我真是个拖延症晚期患者”，而是写“为什么每次周五下午的任务，我都会拖到周日晚才动手，当时是什么在阻止我？”
这样做的原因很实际：自我评价是封闭的，问题才是开放的。前者让你在日记里反复确认自己的缺点，后者引导你去找答案和策略。每周复盘时，我只需要翻出过去七天的反思区，看看有没有反复出现的同一个问题，如果有，它就是下周需要专门对付的目标。
反思区写不下去的时候，允许留白，但不要用“没什么好反思的”一句话敷衍过去。实在没有，可以写“今天没有特别值得反思的事”，这也代表了一种状态。
4.3 每周回顾和每月复盘：不是日记的重复，而是对账
周回顾和月复盘是我这套系统里第二重要的环节。最初我把它们写成了“本周日记汇总”，后来发现这种方法很低效：既枯燥，又不会带来洞察。
现在的周回顾只用回答三个问题：这周最重要的一件事是什么；这周我在重复哪个旧模式；下周我要改变的一个细节是什么。字数控制在三百字以内，写多了反而会逃避。
月度复盘套路类似，但会加一步“数据对账”。我会打开当月的情绪字段统计数据，看整个月的情绪分布——哪几天处于低谷，低谷前发生了什么，有没有周期性规律。有一次我发现每次情绪低谷几乎都出现在出差三天之后，于是专门在出差计划里加了一天缓冲期，效果立竿见影。
复盘的本质是“对账”：对照事实、情绪、行动三者是否匹配。它确实需要一点理性思维，但写起来并没有想象中那么费劲。我通常安排在每个月最后一天或假期里，二十分钟就能完成。
4.4 怎么避免过度设计：允许日记有“丑”的空间
我前面把系统说得好像很完美，但实际上我踩过最大的坑就是过度设计。刚开始搞维克日记时，我一周迭代一次脚本，给日记加表格、嵌入图片、做模板变量，后来甚至写了一个自动统计“当天步数”的功能，现在回看都是完全没必要的花架子。
过度设计最致命的后果，是它会让你把“维护系统”误当成“写日记”。有段时间我每天花半小时调整脚本和插件，写日记反而只有五分钟。这完全本末倒置了。
后来我给自己立了一条规矩：任何自动化功能，如果不能让“写日记”这个动作更快开始，就不做。我还允许自己写“丑日记”——比如某天很累，只写了三行字，甚至只有一行“今天太累，改天补”，这完全没问题。日记系统要包容人的低谷，而不是用“每日严谨格式”绑架你。
5. 自动化脚本与回顾机制：把重复动作交给机器，但保持克制
5.1 新的一天，先从自动创建文件开始
写日记最大的摩擦点是“打开一个新页面并填入日期和模板”。我写了一个非常小的脚本解决这个问题。
bash复制#!/bin/bash
# new-day.sh - 按日期创建今天的日记文件
BASE="$HOME/vik-diary/journals"
TODAY=$(date +%F)
YEAR=$(date +%Y)
MONTH=$(date +%Y-%m)
DIR="$BASE/$YEAR/$MONTH"
FILE="$DIR/$TODAY.md"
mkdir -p "$DIR"
if [ ! -f "$FILE" ]; then
cp "$HOME/vik-diary/templates/daily.md" "$FILE"
sed -i "s/{日期}/$TODAY/" "$FILE"
fi
echo "已创建今天的日记: $FILE"
我把它绑定到系统的一个快捷键上，按一下就能生成今天的新文件。这看起来很简单，但恰恰是这种“少一个步骤”的设计，让我在地铁上想记东西时不会因为麻烦而放弃。
5.2 月度数据汇总：情绪曲线和标签频率
到月底，我用一个小脚本统计当月情绪和标签情况。脚本逻辑很简单：遍历当月文件，从字段中匹配情绪和标签，输出一个汇总。
python复制#!/usr/bin/env python3
import re, glob, os
from collections import Counter
month_dir = "journals/2025/2025-06"
mood_str = ""
tag_counter = Counter()
for md_file in glob.glob(os.path.join(month_dir, "*.md")):
with open(md_file, "r", encoding="utf-8") as f:
text = f.read()
mood_match = re.search(r"情绪[：:]\s*(.*)", text)
if mood_match:
mood_str += mood_match.group(1) + " "
tags_match = re.search(r"标签[：:]\s*(.*)", text)
if tags_match:
for tag in re.split(r"[,，\s]+", tags_match.group(1).strip()):
if tag:
tag_counter[tag] += 1
print("本月情绪记录:", mood_str)
print("本月标签频率:", tag_counter.most_common(10))
这对非程序员来说可能有点门槛，但一步步来也不难。如果你完全不想碰脚本，也可以用Obsidian的Dataview插件实现类似统计。脚本不是必需品，它只是把“统计”这个动作变轻了，让你更愿意在月底打开回顾页。
5.3 年度回顾：用最朴素的方式生成词云
我见过有人把自己的日记仓库接进大模型做年度报告，效果确实惊艳，但我个人的态度是：好玩可以，别依赖。维克日记的定位是长期稳定，不是追新概念。
我目前年度回顾只做两件事：一是用情绪数据生成一条年度情绪折线，看看全年的心理状态波动曲线；二是把当年所有日记汇聚成一坨纯文本，去掉常见停用词，扔进词云工具里生成一张年度词云。词云这个东西学术上不算严谨，但它能让你一眼看到自己这一年嘴上最常说的词是什么。
如果你的日记里“工作”这个词大得像块石头，这说明什么，你自己心里有数。这种直观冲击力，是任何统计表格都给不了的。
5.4 自动化克制原则：别让工具成为新的负担
写脚本这件事很容易上瘾，做菜时总想着再加点佐料。但我用自己的血泪史告诉你：自动化的价值，只用一句话衡量——它能不能帮你减少“从念头到落笔”的步骤数。
那些看起来花哨的功能，比如自动抓取天气填充到日记里、自动统计阅读时长、自动打标签，我基本都试过，最后全砍了。为什么？因为自动填充天气会让日记看起来完整，但它并不增加你回顾时的价值，反而让你误以为“系统很完善”，从而忽略了真正重要的部分——你在想什么。
自动化在维克日记里的角色应该是一个安静的后台服务员，而不是舞台上的主角。它负责端茶倒水，你负责好好生活。
6. 备份、隐私与长期维护：日记系统的最后一块拼图
6.1 本地优先：隐私保护的第一原则
日记是极度隐私的内容，我最不愿意看到的结果是：某天某个平台的数据泄露事件里，出现了我过去五年写下的所有心事。
维克日记的默认策略就是本地优先。所有内容默认存在你自己的硬盘里，不主动上传任何云端服务。如果你完全不使用远程同步，那就是一个纯离线系统，没有任何第三方能接触到你的数据。这种“默认安全”姿态，是马克down加本地文件夹组合最大的优势。
如果你担心电脑丢失或硬盘损坏，需要远程同步，我的建议是自建同步网盘，或者使用端到端加密的同步工具，并且保持远程副本的访问控制严格收紧。无论选哪种，都要记住：远程仓库只是备份，不是主副本。主副本永远在你自己能够物理接触的存储介质上。
6.2 备份策略：把3-2-1原则落实到日记文件夹
“3-2-1备份原则”是数据安全领域的经典方法：三份副本、两种不同介质、至少一份异地备份。我把它原封不动搬到了维克日记上。
我的实际备份布局是这样的：
| 副本 | 介质 | 位置 |
|---|---|---|
| 副本一 | 电脑本机硬盘 | 日常读写使用 |
| 副本二 | 移动硬盘 | 每个月手动同步一次 |
| 副本三 | 远程私有仓库 | 每次Git提交后同步，作为异地灾备 |
这套方案看起来很基础，但它经得起时间的考验。移动硬盘我喜欢用那种不需要额外供电的2.5英寸盘，插上就能同步，减小了“懒得上手”的概率。远程私有仓库我用的是普通代码托管平台的私有仓库，坚持每周至少提交一次。
还有一个细节：我会在每年元旦做一次“年度归档快照”，把上一整年的日记文件夹打成压缩包，加密后拷进一个不常动的移动硬盘里。这样即便远程仓库意外被删、本机文件损坏，也还有一份不可变的历史存档。
6.3 长期维护中的三个真实教训
维护维克日记两年多，我踩过一些坑，说三个比较有代表性的。
第一个坑是标签不统一。早期我时而写“健身”，时而写“运动”，结果统计时数据被劈成两半，月度标签排名失真。解决方法是把模板里的标签示例写死，写日记时尽量参照示例来，新增标签要谨慎。
第二个坑是文件名大小写混乱。在macOS上我建过 2025-06-11-晚上.md 这样的文件，后来同步到Linux服务器上时文件名编码出了问题，导致脚本扫不到它。现在我的文件命名规则里只允许小写字母、数字和短横线，中文一律不进文件名。
第三个坑是忘了提交Git。有段时间我连续写了十几天日记，但一直没有执行 git commit，某次误操作删了一个文件，结果发现Git历史还在上次提交点，十几天的新日记全丢了。后来我给自己定了一个简单动作：每周五下午五点半，执行一次“提交并推送”的流程，再花两分钟检查本周日记是否齐全。这个习惯治好了所有同步焦虑。
6.4 这套系统能一直用下去吗
有人问过我：你搞这套本地文件夹方案，是不是太“手工耿”了，未来有没有可能被时代淘汰？
我的回答是：恰恰相反。维克日记最抗淘汰的地方，就是它把所有东西都建立在最基础、最通用的技术上。Markdown从诞生到现在已经二十年，未来二十年也几乎不可能消失；纯文本文件夹更不用说，只要电脑还存在，它就存在。真正容易被淘汰的，是那些被封装在专有生态里的花哨功能——今天这个App火，明天那个平台凉，技术名词换来换去，但那份写着“我今天很累”的纯文本文档，二十年后依然能打开。
保持简单，就是最好的长期主义。
写维克日记的两年里，我最意外的收获不是“坚持”本身，而是回看过去时，发现自己真的在缓慢而确凿地变化。那些当时觉得过不去的坎，在情绪曲线上只是一个小低谷；那些以为会铭记终身的高光时刻，在日记里可能只有平凡的三行描述。这种“视角差”很奇妙，它让我学会了对当下的情绪保持一点谦逊，也对未来的自己多一些耐心。
如果你也想开始建立自己的日记系统，我的建议是：别一开始就复制我全套方案，先从最简单的本地文件夹加Markdown模板开始，写上一个月再说。你在记录中自然会发现自己需要什么字段、讨厌什么流程，那时候再一点一点加东西，也不迟。工具永远可以换，记录的习惯才是地基。