Obsidian做健康管理这个选题我其实挺有发言权的。用了两年多从最开始只是拿它记训练日志到后来把睡眠、饮食、体重体脂、跑量、情绪状态全部纳入到一个库里它已经不只是笔记软件而是我个人的健康数据中心。市面上健康类App很多但数据都躺在别人的服务器上格式封闭、导出困难、功能固定而Obsidian的好处是所有数据都是本地Markdown文件结构完全由自己定义想怎么分析就怎么分析不存在“这功能要会员”或者“这数据导不出来”的问题。这篇文章会把整套方案的思路、数据结构、模板写法、查询统计都拆开讲适合已经有一定Obsidian基础、想把它用于健康管理的人也适合刚开始接触、想知道笔记软件能干什么的读者。我会尽量把细节讲透——包括那些文档里不会明说的踩坑经验。1. 整体设计思路为什么拿笔记软件做健康管理1.1 选型背后的逻辑从需求倒推工具先说说我为什么不用现成的健康App而要自己搭一套。核心原因有三个。第一是数据归属。绝大多数健康类App都是封闭的记录进去的数据虽然能在App里看但想导出或者迁移到别的工具里非常困难。健康管理是论“年”为单位的长周期事情数据积累越久价值越高如果哪一天App停止运营或者你换了平台这些数据可能就永远拿不回来了。而Obsidian的数据是纯文本Markdown文件存在你自己的电脑、手机或者同步盘里任何时刻都可以完整导出、备份、迁移完全不存在被平台绑架的问题。第二是灵活性。现成App的功能是定死的它让你填什么你就得填什么它有什么图表你就能看什么图表。但每个人的健康管理需求差异很大——跑步的人关注跑量和配速健身的人关注训练动作和重量减脂的人关注热量和体重有睡眠问题的人关注入睡时间和深睡时长——你很难找到一个App同时满足所有这些维度。而Obsidian的字段、模板、查询、视图全部可以自定义想要什么就自己加主动权完全在自己手里。第三是关联性。健康管理不是一个孤立的数据点它是一条链条昨晚的睡眠影响今天的训练状态今天的饮食影响明天的体重这周的压力水平可能反映在心率数据上。传统App里这些数据是割裂的而Obsidian支持任意笔记之间的双向链接完全可以把“体重数据”和“某天吃了什么”“某天的睡眠质量”链接到一起从单一数据点看到完整的生活状态。关于适合谁我说句实话如果你只是想知道“今天走了多少步”没必要折腾Obsidian微信运动和手机自带健康都够用了。但如果你已经开始系统性地关注某个健康目标——比如减脂、增肌、备赛、改善睡眠——并且意识到“光记没用得找到规律才有用”那这套方案会非常值得尝试。1.2 整体架构一个中心、两条链路、三个模块搭建之前先在脑子里画个图。我的健康库整体架构可以概括为“一个中心、两条链路、三个模块”。一个中心以“日期维度”为单位的记录笔记是核心。每个记录文件除了记录当天的数据还能链接到对应的周计划、月目标形成一个从“目标”到“执行”到“结果”的完整链条。两条链路第一条是“记录链路”也就是每天怎么快速录入数据包括日记模板、快捷命令、移动端配合第二条是“分析链路”也就是从零散的数据里汇总出周报、月报、趋势图表借助Dataview插件自动化完成。三个模块记录系统吃、练、睡、情绪、身体数据、目标系统周目标、月目标、专项计划、分析系统日报、周报、月报、趋势图表。这个架构最核心的思路是录入要快到没有负担分析要自动到不用手动。只有录入足够轻量你才能坚持只有分析完全自动化你才愿意回头看数据。两者缺一不可。1.3 目录规划给数据一个安放的地方很多人的Obsidian库最后变成“乱葬岗”根源是前期没有目录规划。健康管理涉及的数据种类多、频率高如果目录乱后面写查询公式时路径全乱套。我建议的目录结构是这样Health/ ├── 00_收件箱/ # 临时记录和闪念笔记比如跑步时随手记的感受 ├── 01_日记/ # 每天的日记按天一条是整个系统的锚点 ├── 02_训练/ # 每次训练的详细记录跑步、力量、瑜伽等 ├── 03_饮食/ # 饮食日记 ├── 04_健康数据/ # 体重、体脂、睡眠、心率等身体数据 ├── 05_目标/ # 周目标、月目标、专项计划 ├── 06_周报/ # 自动生成的每周汇总 ├── 07_月报/ # 自动生成的每月汇总 ├── 08_模板/ # 所有记录模板 └── 09_复盘/ # 腿伤恢复记录、训练计划迭代、经验总结前缀数字的作用有两个一是固定排序让文件夹在侧边栏里按逻辑顺序排列不会因为新建文件夹就乱掉二是快速定位用快捷键打开文件时输入04就能联想到健康数据区配合中文输入法可以直接跳转。命名规范上我的原则是“类型前缀日期描述”训练-2025-03-18-晨跑12k.md 健康数据-2025-03-18.md 日记-2025-03-18.md统一命名格式的最大好处是后面写Dataview查询时可以直接按前缀过滤配合文件名里的日期排序和筛选都变得非常干净。我吃过一次亏早期命名五花八门有的是“0318训练”、有的是“3月18日跑步”结果写查询时条件怎么写都不对只好花了半天统一改名。这个坑先帮你们踩了。2. 核心数据模块每条记录长什么样2.1 日记整个系统的锚点日记是整个健康管理系统的锚点。训练记录、饮食记录、健康数据都可以独立存在但真正把一天串起来的是日记。我的日记模板不算复杂但每个字段都有用途。看下这个模板--- 日期: 2025-03-18 星期: 周二 晨重: 晨体脂: 睡眠时长: 睡眠质量: 6 精力值: 7 压力值: 3 心情: 平静 训练链接: [[训练-2025-03-18-晨跑12k]] 饮食链接: [[饮食-2025-03-18]] --- ## 睡眠 昨晚入睡时间23:20 今早醒来时间06:30 睡眠中断次数1次 ## 身体感受 这里写今天身体的状态比如哪里酸痛、有没有不适、心肺感觉如何 ## 饮食记录 早餐燕麦牛奶、水煮蛋x2、蓝莓 午餐公司食堂 晚餐鸡胸肉沙拉 ## 情绪与精力 记录今天的工作压力、情绪波动、精力起伏 ## 今日小结 今天训练状态不错晨跑配速比上周快了15秒但下午有点犯困可能是昨晚睡晚了。属性区两个---之间的YAML区域存放的是结构化、可计算的数据比如体重、体脂、睡眠时长、精力值这些数值正文区存放的是非结构化的描述。这样做的好处是Dataview可以根据属性区做数值计算、趋势排序而你写的好多文字则保留上下文和细节两者互补。比如你可以看到“周二体重平均比周一高0.3kg”同时也能翻到那条记录里写着的“昨晚应酬吃火锅了”数据背后的原因一目了然。日记的用途不只是“记录”它还是一个链接枢纽。训练记录和饮食记录都是独立笔记但在日记里通过链接指过去。这样查看某一天时所有维度的信息都在一个视野里反过来从训练笔记点回当天日记也能看到那天的身体状态。这个双向跳转的逻辑是传统App做不到的。2.2 训练记录精细化到“每次”训练记录的详细程度决定了分析的价值。我的训练笔记模板长这样--- 日期: 2025-03-18 类型: 有氧 项目: 晨跑 距离: 12.0 用时: 72.5 配速: 6.04 平均心率: 148 最大心率: 171 体感难度: 7 跑步鞋: 飞马 链接: [[日记-2025-03-18]] --- ## 训练详情 记录路线、分段配速、爬升等细节 ## 感受 今天起跑前两公里腿很沉一度想放弃三公里之后反而轻松了。最后两公里顶了顶速度体感比上周好。 ## 状态评估 对照目标检查自己有没有按计划执行字段设计背后有个原则能结构化的字段绝不写进正文。距离、用时、心率这些数据要用来算统计必须变成属性而“腿很沉”“空气湿度大”这些主观感受没有统计价值写正文更合适。两者各司其职不要混在一起。有一个细节值得注意配速不是直接填的而是由距离和用时自动算出来的。这样写查询时可以直接显示配速避免手算或者填错单位。计算方法是配速分钟/公里 用时分钟÷ 距离公里也就是 72.5 ÷ 12.0 6.04。不要小看这个细节。如果属性区域里既存了用时又存了配速就会出现数据不一致的情况——你改了用时但忘了改配速。只存原始数据、派生数据全部由计算生成是数据建模的基本原则。2.3 健康数据每天五分钟的例行录入体重、体脂、睡眠这些数据我单独放在健康数据笔记里不会混进日记。原因还是那条它们的记录频率固定、分析方式固定单独放在一个文件里查询和图表生成的逻辑可以做到非常干净。--- 日期: 2025-03-18 晨重: 70.2 晨体脂: 19.5 睡眠时长: 6.7 入睡时间: 23:20 醒来时间: 06:30 静息心率: 58 ---每天早晨固定时间测量称重然后把数据填进去。这里有个我摸索出来的经验称重数据比训练数据更容易产生挫败感所以别把它写进日记而是放进“数据”文件里。这样写日记时不会被每天波动的体重干扰心情而做周报时又能看到完整的趋势线。从心理学角度说就是把“情绪记录”和“数据记录”分开避免数据波动带来情绪污染。睡眠时长也不是手填的而是醒来时间减去入睡时间自动算出来的。如果你有智能手表这些数据通常能自动同步那就更省事只需要在导入时保持格式一致就行。2.4 模板自动化的关键Templater手动敲模板太反人性了所以必须自动化。Obsidian的Templater插件能实现两件事第一是插入模板时自动填上当前日期、星期第二是根据模板中的变量自动计算字段。我用Templater的方式是给日记模板的第一行加一行代码--- 日期: % tp.date.now(YYYY-MM-DD) % 星期: % tp.date.now(dddd) % ---然后设置一个快捷键每天早上按一下当天的日记就自动建好了日期和星期不需要手动输入。训练记录、饮食记录、健康数据笔记同理。这里有个容易踩的坑Templater自动生成的日期用的是系统时间如果你的系统时区不对日期就会差一天。某次我出差时忘记调笔记本时区连续几天生成的日记日期都是前一天的后来统一核对时才发现的。所以模板自动化之后第一周一定要抽空检查一遍生成的日期是否正确。3. 数据分析与可视化让数据自己会说话3.1 Dataview查询一切记录数据不是目的找出规律才是。Obsidian里做数据分析的大杀器是Dataview它能用类似SQL的语法在笔记列表里自动生成动态查询结果而且结果会随着数据更新自动刷新。常用的查询场景有这些场景一本周训练汇总TABLE 日期, 类型, 距离, 用时, 配速 FROM 05_健康库/02_训练 WHERE 日期 date(2025-03-17) AND 日期 date(2025-03-23) SORT 日期 ASC这个查询会把你这一周的所有训练记录列成一张表直接看到周一跑了什么、周三练了什么、周日有没有偷懒。场景二近30天体重趋势TABLE 日期, 晨重, 晨体脂 FROM 05_健康库/04_健康数据 WHERE 日期 date(today) - dur(30 days) SORT 日期 ASC这个查询就用来观察体重和体脂的变化趋势比App里的“7天/30天切换”更灵活因为日期范围可以彻底自定义。场景三平均配速统计TABLE round(avg(配速), 2) AS 平均配速, round(sum(距离) / 10, 2) AS 总里程(km) FROM 05_健康库/02_训练 WHERE type 晨跑写法上,avg()是求平均round()是保留两位小数sum()是求和。想统计什么就改字段名非常灵活。关于日期格式有个必须注意的点Dataview对日期的字段名很敏感属性区里的日期这个键名必须是date类型才能比较。如果你存的是“2025-03-18”这种字符串格式查询时就要写成date(日期)做类型转换。否则该出现数据的查询里会莫名一片空白这类问题排查起来特别费劲。3.2 Obsidian Charts把数据变成图Dataview能列表格但表格对人类大脑来说不算最直观的呈现。我的方案是把Dataview查询结果喂给Charts插件让它生成趋势图和柱状图。Charts支持的图表类型很丰富线形图看体重趋势、柱状图看每周跑量、饼图看训练类型分布。我常用的Charts代码块是这样view: line title: 近30天晨重趋势 x: 日期 y: 晨重 data: | ...具体数据部分不建议手动填更顺畅的做法是把Dataview查询的结果复制粘贴到图表中或者写一段更高级的JavaScript代码直接从Dataview取数据。后者实现起来要写一小段DQL查询配合dv.pages()函数适合有一定编程基础的读者没基础的先用复制粘贴大法也能满足大部分需求。我自己的做法是把Dataview表格放在文档上半部分Charts图表放在下半部分。表格看具体数值图表看整体趋势两者配合信息密度非常高。3.3 周报与月报自动生成的“体检报告”光有数据和图表还不够人类需要叙事。每个周末我会打开周报笔记看到Dataview自动生成的内容有点像是拿到一份自己给自己出的体检报告。周报模板里放了这么几个区块本周训练总览跑了多少公里、练了几次、平均配速、本周身体数据平均体重、平均体脂、平均睡眠时长、本周与上周的对比、本周目标完成情况。TABLE 一周总里程 AS , 训练次数 AS , 平均配速 AS ⏱, 平均晨重 AS ⚖️, 平均睡眠时长 AS FLATTEN sum(rows.距离) AS 一周总里程 FROM 05_健康库/02_训练 WHERE 日期 date(2025-03-17) AND 日期 date(2025-03-23)注意周报的每一条查询都要写死日期范围所以我建模板的时候会把日期范围留成变量每次新建周报前用Templater填一下当周的起止时间就行。虽然多了一步但比手动去改每个查询条件省太多事。你会看到这样的句子“本周总跑量32.5公里比上周减少18%”“本周平均睡眠6.5小时低于目标时长7小时”“体脂率连续三周下降趋势良好”。这些数据不是某个教练给你的是你用Obsidian自己算出来的客观且真实。4. 常见问题与排查技巧实录Dataview没结果、模板不刷新、图表不显示……这些问题我之前全都遇到过写个备忘免得后来者再踩一次。4.1 Dataview查询结果的常见“空手而归”这是最让人头疼的情况。明明笔记里存了数据Dataview却显示空列表或者空表格。排查顺序我总结成了“三板斧”先检查路径。Dataview的FROM条件写的路径和实际笔记所在路径是否完全一致大小写和中文空格都不能差。05_健康库/02_训练和05_健康库/02_训练/是两种结果结尾多一个热斜杠就可能查不到。如果文件夹是英文直接写成FolderName如果是中文必须用引号包起来不然解析会出错。再检查字段类型。属性区里写date: 2025-03-18之后用表格视图显示时可能会被当成字符串。此时比较表达式里要写date(日期) ...确保转换成日期类型。我踩过一次坑某个月的体重趋势图一片空白最后发现所有体重笔记的日期字段全是字符串格式DataVview不敢自动转换。最后检查查询语法。WHERE 日期 date(2025-03-17)这个写法在Dataview里要求日期是一个合法的字段名如果在笔记里敲日期时不小心带了一个空格2025-03-18就查不出来。最容易出问题的反而是看起来最没问题的日期后面不能有空格键名不能有大写字母除非你全大写查询里要引用属性名就必须和笔记里完全一致。4.2 模板日期一直不更新用Templater自动生成的日期如果“卡住”基本都是因为同一天内多次插入模板导致时间重复。解决办法是在模板命令后面加一个按钮或者设置个命令让它每次插入时都重新取系统时间。你在模板文件里写tp.date.now()时它不会自动每天重算因为模板本身是静态文件每次插入只是“复制”复制时Templater才会执行动态部分。如果你创建的日记模板文件里有一行固定写的“2025-03-18”那不管是明天还是后天新建日记日期都长这样。正确做法是每次新建笔记时用Templater的快捷键而不是手动复制已有笔记再改日期。还有一个相关性问题是移动端和桌面端的时区不同。如果你的手机和电脑不在同一时区生成日期会偏一天。我出差的时候踩过这个坑最后统一只在电脑上跑Templater手机上只做记录不生成新文件。4.3 图表显示异常Charts不显示或显示空白90%的原因是数据格式没对齐。Charts要求的CSV数据格式是每行一条数据首行是列名数字必须是纯数字不能带“kg”“分钟”这些单位。如果你给体重数据加了个“kg”Charts就直接拒绝渲染。去掉单位放到笔记里或者在查询表达里截掉问题就解决了。另外Charts对中文列名的支持有过版本问题老版本直接不显示中文列名。遇到这种情况升级插件版本基本能解决实在不行把列名改成英文。4.4 库的初始化什么时候开始都不晚很多人在搭建健康库时会想“我以前的记录怎么办”“数据不够多是不是没有价值”。我的回答是不用纠结补历史数据从今天开始记就行。健康管理的意义不在“过去的完整性”而在“从今天开始建立连续性”。哪怕你打算下个月才正式开始系统训练也完全可以现在先建好日记模板和健康数据文件因为“今天”就是你最早的那一天数据。如果觉得数据太少看不出来规律那就加大记录密度。比如体重管理初期每天记录比每周记一次更容易看出波动趋势跑步训练初期每次记录心率区间比只记录配速更有价值。4.5 多设备同步和数据安全Obsidian是本地优先我的全部健康数据都存在个人设备里。为了多设备同步我使用市面主流的同步盘服务手机和电脑共用同一个库。这里要重点强调的是安全备份逻辑健康数据太重要了绝不能只依赖普通同步。我设置了本地定时备份加云端备份的“双保险”每月手动打包一份全部健康数据上传到网盘另外存一份。有些同步服务支持版本历史这个一定要开启。某次我不小心清空了一个健康数据文件的属性区导致连续三个月的数据全没了——当时真是抓狂后来靠版本历史找回了一大半。从那以后我对于重要的健康库坚决开启版本历史功能这是血泪教训。5. 总结与建议这套Obsidian健康管理系统我用了两年多从最开始只有训练记录到后来扩展到饮食、睡眠、情绪、身体数据、目标管理它已经完全替代了所有健康类App。回头看真正让我坚持下来的不是插件多强大而是“记录成本低分析反馈快”。如果每天录入要花十分钟我第三周就会放弃如果每周能看到自动生成的趋势反馈我就会想继续记下去。如果你也想搭建我的建议是分三步走第一步只建一个日记模板每天记录睡眠时间和体重第二步坚持一周后添加训练记录和Dataview周报查询第三步当你发现“跑步后睡得更好了”这个规律用自己的数据验证出来时你已经离不开这套系统了。最后说一个小技巧不要一开始就追求完美模板。我第一版日记模板只有三个字段后来迭代了七八次才变成现在这个比较完整的版本。健康管理的关键不是工具多完美而是你愿意持续记录。Obsidian只是那个确保“记录得下去”的工具它把整理和分析的负担扛走把记录的乐趣留给你。