凌晨 1 点 47 分我盯着屏幕上最后一行日志顺手点了一下提交。这个 commit 没有修好任何 bug也不是什么功能迭代但它是我第一次认真对待睡眠这件事的记录。当时我给自己做了一个叫Shitty Sleep的睡眠记录与分析小工具。名字起得很直白带着程序员特有的自嘲因为我那段时间的睡眠状态确实配得上这两个词入睡晚、起床难、白天精神像被抽干。但真正让我决定写工具的原因不是我又熬夜了而是我发现自己根本说不清“我最近到底睡得有多烂”。每天醒来只能凭感觉说“还行”或者“很累”到了周末又觉得“好像也睡够了”然后下一周继续重复。于是问题变成了能不能把睡眠这件事从情绪化体验变成可观测、可分析、可持续优化的流程这恰恰是一个典型工程问题。与其靠“今晚一定早点睡”这种意志力宣言不如先记录、再分析、最后做调整。Shitty Sleep 这个名字听起来像在开玩笑但它背后是一条很正经的思路真正有价值的不是“记录睡眠”这个动作而是把睡眠变成一组可以看趋势的数据再用数据反过来修正你的生活节奏。在我看来这类方案的核心价值也不是省几分钟录入时间而是把一次临时体验沉淀成一套可复用流程。这篇文章我会从头拆解这个思路包括最小版本怎么做、指标怎么选、自动化记录会踩什么坑以及这套方法论能迁移到哪里去。1. 先承认一个现实程序员为什么睡不好又为什么需要数据而不是鸡汤1.1 熬夜不是自律问题而是工作流问题如果只看表面睡不好的原因通常被归为“自控力差”。但我在复盘自己的记录时发现事情没那么简单。写代码这件事本身有一个很特殊的节奏当你推进一个复杂功能时大脑会进入高强度的专注状态。晚上七八点本来准备收工结果一个 bug 卡住了想着“再看一眼”十分钟后变成了“为什么这个变量会变”再抬起头已经是凌晨。这种状态不是意志力薄弱而是任务边界模糊导致的你永远觉得“再搞一点就能结束”但功能开发没有真正意义上的“完成点”。另外深夜确实有一种安静的高效感。消息推送少了同事不会突然来找你环境噪音也降下来。这个时间段对专注型工作有天然吸引力所以很多开发者会不自觉地形成“越夜越高效”的路径依赖。问题是白天的状态会慢慢被透支长期来看这种“高效”其实是负债。鸡汤会说“晚上别想工作”但真正有用的不是粗暴禁止而是先把问题量化出来。你需要记录的不是一句“我今天熬夜了”而是具体到“我入睡时间是几点和计划时间偏差了多久连续几周出现这种偏差”。1.2 为什么“早点睡”没用可观测性才是切入点“早点睡”所以没用是因为它太模糊了。几点算早提前多久算早连续做到几周才算有效这些问题得不到回答行动就落不了地。我见过很多人在桌上贴“今晚 11 点睡”的便签结果一点用都没有。原因很简单没有反馈闭环。你定了目标第二天起床后既不检查偏差也不分析原因目标就成了墙上的一句话。而数据记录天然解决反馈问题。你每天睡醒之后花三十秒录入四个数字一周后就能看到折线图入睡时间是不是整体后移了某天特别晚睡前一天是不是发生了什么周末补觉到底补了多久这些信息比“我最近睡得不太好”要有力量得多。我不是说每个人都需要变成量化自我狂热者但如果你已经连续几周状态不佳靠感觉又找不到突破口那么建立一个最小观测系统是性价比最高的第一步。1.3 Shitty Sleep 的定位不是健康 App是开发者自嘲式的睡眠观测工具网上睡眠类 App 很多有的主打白噪音有的主打社区打卡有的会给你生成各种复杂的睡眠报告。但对我这种资源有限、又不喜欢把个人数据存到陌生平台的开发者来说轻量自建工具反而更舒服。Shitty Sleep 本质上不是一个完整产品而是一个很小的分析脚本集合。它的核心能力只有三个用最低成本记录每天的关键数据入睡时间、醒来时间、中断次数、主观恢复感。把数据聚合成周视图和月度趋势。找到睡眠变化和工作行为之间的关联。它不提供医疗建议不声称能“改善睡眠质量”也不做心率、血氧这类生物信号分析。它只负责回答一个问题你的睡眠模式到底长什么样这个定位非常重要因为一旦想做的事情太多项目就会变得复杂而复杂的东西往往撑不过第一周。2. 最小可实现版本先别追求完美先让“记录”这件事发生2.1 技术选型轻到不能再轻我见过一些朋友做类似项目时一上来就引入数据库、消息队列、前端框架甚至打算写个 App。这些设计本身没有错但第一版如果太重你很可能在还没开始分析数据之前就放弃了。更建议先从轻量方案开始。一条非常实用的路线是用 Markdown 或 CSV 文件做原始存储。用 Python 脚本做清洗和聚合。用 Matplotlib 或者 Excel 生成图表。为什么选这个组合因为 CSV 文件是通用格式任何工具都能读。Python 是大多数开发者熟悉的环境脚本很短调试也方便。如果你完全不想写代码用 Notion 表格、Google Sheets 或者 Airtable 也可以重点不是技术栈有多先进而是这个流程能稳定跑一个月。Shitty Sleep 这个名字虽然随意但它的工程思路很克制单文件存储单脚本统计不做实时同步不搞复杂权限。2.2 最小数据模型四个核心字段第一版数据模型不需要覆盖所有睡眠维度。只要四个字段就能跑起来字段示例说明日期2025-06-02记录哪一天的数据用本地日期即可入睡时间01:47大概睡着的时间精确到分钟即可醒来时间08:15最后一次醒来的时间不是闹钟响的时间主观恢复感31 到 5 分5 分代表睡醒后状态很好如果你想更进一步可以加两个字段中断次数半夜醒来几次。整觉记 0中途上洗手间或惊醒就按实际情况记。备注自由文本用来记录可能影响睡眠的事件比如“今晚喝了咖啡”“赶了一个紧急上线”。我强烈建议第一周只记前四个字段。理由是记录成本越低坚持下来的概率越高。你不想在睡前迷迷糊糊的时候还要填写一大堆表单。2.3 一天日志长什么样如果你采用 Markdown 文件一条记录大概会是这样2025-06-02 - 入睡: 01:47 - 醒来: 08:15 - 恢复感: 3/5 - 备注: 修 bug 到 0 点刷手机 40 分钟这就是当天全部数据。用 CSV 也可以date,sleep_start,wake_time,feeling 2025-06-02,01:47,08:15,3这个结构已经足够让脚本进行后续处理。你看它甚至不需要数据库。2.4 最小流程跑通记录 → 导入 → 输出一个数当你有了一周数据之后最应该先做的一步不是画复杂图表而是算几个基础指标。这里给一个通用示例假设你读取 CSV 文件并计算平均睡眠时长import csv from datetime import datetime, timedelta records [] with open(sleep_data.csv, r, encodingutf-8) as f: for row in csv.DictReader(f): start datetime.strptime(row[sleep_start], %H:%M) end datetime.strptime(row[wake_time], %H:%M) # 如果醒来时间小于入睡时间说明跨天了需要加一天 if end start: end timedelta(days1) duration_minutes (end - start).total_seconds() / 60 records.append({ date: row[date], duration_hours: round(duration_minutes / 60, 2), feeling: int(row[feeling]) }) if records: avg_hours sum(r[duration_hours] for r in records) / len(records) avg_feeling sum(r[feeling] for r in records) / len(records) print(f平均睡眠时长: {avg_hours} 小时) print(f平均恢复感: {avg_feeling} 分)这段代码非常基础但它给出了第一版工具的输出一个数字。有了数字你才有后续优化的依据。注意如果你直接复制这段代码要确认 CSV 文件的字段名和日期格式是否一致。跨天判断逻辑尤其重要否则睡眠时长会被算成负数。跑通这个最小流程你就已经完成了一个闭环记录数据、读取数据、生成一个可解释的统计值。此时再去想新增功能方向会清晰很多。3. 从单日记录到周度分析核心不是功能多而是你要生成什么判断3.1 指标不是越多越好先盯四个很多睡眠类产品喜欢展示深睡比例、浅睡比例、REM 比例、心率变异性、呼吸频率等大量指标。这些指标听起来专业但如果没有配套的采集设备靠手动记录根本无法获取即使设备提供了也不一定准确。对 Shitty Sleep 这类轻量工具来说真正值得关注的是四个指标平均睡眠时长基础中的基础。入睡时间偏移你实际入睡时间和目标入睡时间之间的差距这个指标比单看“几点睡”更有信息量。醒来时间稳定性工作日、周末之间醒来时间的波动幅度。主观恢复感趋势连续多天疲惫感上升即使睡眠时长不变也说明睡眠质量可能有问题。为什么这四个指标够用因为它们都来自最小数据模型不需要额外传感器而且直接和行为调整相关。3.2 “睡眠偏移”为什么最值得关注很多人记录睡眠只看时长觉得“睡了 7 小时就算达标”。但连续记录几周之后我发现更值得警惕的是入睡时间偏移。举个例子假设你的目标入睡时间是 23:30周一实际是 23:50偏差 20 分钟看起来不大。但周二到了 00:15周三到了 00:40到了周末彻底变成 02:00 以后。单看每一天你都会觉得“只是晚了一点点”但一周的趋势会清楚显示偏移在持续累积。我把这个指标理解为“睡眠习惯的方向盘”。如果你连续三天偏移超过了 30 分钟基本可以认为快要进入恶性循环了。这时候不需要做什么大调整只需要找一天强制在目标时间前 30 分钟关掉屏幕就能止损。这就是数据带来的判断力在问题变成严重困扰之前提前干预而不是等到周日浑身疲惫才开始后悔。3.3 从数据里挖出你的四个坑记录数据三到四周之后你一定会发现一些规律。我在自己的数据里看到过几种典型的坑修复 bug 导致延迟入睡一开电脑就难以停下来。对策是睡前 90 分钟完全不打开编辑器。报复性熬夜白天被各种会议和协作塞满晚上感觉只有深夜才真正属于自己。这种心态会推进入睡时间而且即使身体很累也会下意识拖延。睡前消息循环躺下后开始刷消息觉得“就睡前放松一下”结果半小时过去了。周末过度补觉周中缺的睡眠在周末一次性补导致周一早上状态反而更差。这些现象不用专家分析只要把入睡时间、备注和恢复感画在同一张图上就很容易看出来。比如备注里出现“修 bug”的夜晚第二天恢复感大概率低于平均值出现“刷手机”的备注入睡时间通常会晚 40 分钟以上。3.4 图表不是必须的但趋势是必须的Shitty Sleep 第一版只输出数字不画图。后来我加了最简单的周均值折线图就一句话、一张图效率提升非常明显。可视化不需要多炫。在 Python 里用几行代码画趋势图就够了import matplotlib.pyplot as plt import matplotlib.dates as mdates import pandas as pd df pd.read_csv(sleep_data.csv, parse_dates[date]) df[sleep_start_dt] pd.to_datetime(df[sleep_start], format%H:%M) # 把跨天时刻映射为当天的小时偏移 df[sleep_offset_minutes] df[sleep_start_dt].dt.hour * 60 df[sleep_start_dt].dt.minute fig, ax plt.subplots() ax.plot(df[date], df[sleep_offset_minutes], markero) ax.set_ylabel(入睡时间从0点算起的分钟数) ax.xaxis.set_major_formatter(mdates.DateFormatter(%m-%d)) plt.xticks(rotation45) plt.tight_layout() plt.savefig(sleep_trend.png)这张图能直观告诉你入睡时间是否在变晚。这就是趋势的价值它不是对某一天的裁判而是对一段时期的方向判断。4. 自动化记录会遇到哪些坑我的排查链路是什么4.1 采集设备数据不准怎么办如果你使用手环或手表自动记录睡眠很可能遇到过这种情况你觉得自己睡了一整晚但设备显示凌晨 3 点处于清醒状态或者睡眠总时长比你实际感受少了 1 个多小时。这里要明确一个边界消费级穿戴设备的睡眠监测本质上是“估算”不是医学级检测。它们依赖心率、体动等间接信号做推测在深睡、浅睡、清醒的边界上经常出现偏差。如果你要用设备数据我的建议是不要直接信任“深睡时长”这类细分指标。只把“大概的入睡时间和醒来时间”作为参考。以手动记录感受为主设备数据为辅。如果发现设备数据和自己的感觉相差很大就以自己看到的时间为准因为工具是为你的判断服务的。4.2 手动记录容易漏也容易编轻量方案最大的问题是记录依赖手动操作一旦忘记补记就会中断。更糟糕的是很多人会在第二天早上回忆时把时间改成“看起来更合理”的值。比如你半夜看了好几次手机完全记得是凌晨 1 点 40 分才放下手机但第二天写记录时会下意识填成 1 点 20 分。这种无意识的“修饰”会让数据失真。解决办法是把记录成本降到最低。手机上放一个快捷方式打开就是当日模板填四个数字十秒钟完成。如果某天确实没记宁可缺失也不要编造。缺失数据最多让你少看一个点编造数据会污染整个趋势。4.3 时区、跨天和夏令时的坑这是所有做时间类工具都会遇到的老问题。你的入睡时间如果是 00:30日期应该属于哪一天醒来时间是 8 点跨天了睡眠时长计算时如果不处理 24 小时制会出现负数。夏令时切换日期也会影响分析。在中国大陆没有这个问题但如果工具面向海外用户或你经常旅行就必须考虑时区和夏令时。最稳妥的做法是统一用 UTC 存储原始时间展示时再转本地时区。但注意这增加了复杂度。对个人单机记录来说直接使用本地时间也可以在大多数场景下工作前提是你意识到跨天判断逻辑。写代码时一定要用 datetime 而不是手动拼接时间字符串。手动拼接通常会漏掉“跨天”这个边界。4.4 数据质量检查一致性、缺失值、异常值数据跑了三周之后你会积累一批记录。这时别急着分析先做一次质量检查字段格式是否一致比如有时候写8:15有时候写08:15会导致解析失败。有没有明显异常值比如睡眠时长超过 16 小时或者入睡时间写成了 25:30这些都是录入错误。缺失率有多高如果有三五天漏记趋势图会留下空洞结论要谨慎。一个简单做法是每次运行分析脚本时自动打印一行数据摘要记录 21 条缺失 2 天 平均时长 6.8 小时恢复感均值 3.1这样你每次分析前都能先意识到数据本身是否可靠。4.5 通用排查链路输入 → 同步 → 字段映射 → 聚合 → 展示如果你的自动化脚本跑出来的结果明显不对不要一头扎进代码里瞎调试。我一般按这个顺序排查输入文件CSV 是否完整有没有被编辑器自动加引号编码是不是 UTF-8同步流程如果数据来自穿戴设备是否成功导出文件路径是否正确字段映射列名是否和你代码里写的一样sleep_start 对应的列是否真的是入睡时间聚合逻辑跨天计算是否考虑了平均值是否被缺失值影响展示层图表的坐标轴是否取反时间格式是否被自动截断这个链路同样适用于其他个人分析工具。先确认数据进了系统、再确认字段没有被错误解释、最后才怀疑计算逻辑。5. 这样做到底改变了什么从 Shitty Sleep 到一个可以复用的自我监控方法论5.1 睡眠只是第一个场景这套方法能迁移记录睡眠的过程给了我一个很重要的启发很多说不清道不明的状态问题都可以通过“降低观测成本 提取趋势 形成判断”来解决。同样的方法可以迁移到专注时间分析用日历软件记录每天深度工作的时间区间按周聚合发现自己到底在哪个时间段效率最高。运动追踪记录每次跑步的时长、距离和体感找到恢复节奏。阅读/内容消费分析记录自己每天在单篇内容上花的时间识别信息过载的源头。饮水、久坐提醒记录下来并不是目的最终目的是发现行为和环境之间的关系。Shitty Sleep 这个名字看起来只和睡眠有关但项目真正沉淀下来的是一套“个人观测系统”的思考方式。它让我明白了工具的价值不是代替你做决定而是让决定有依据。5.2 一个可复用的“个人观测系统”检查清单如果你也想做类似工具可以按这个清单起步定义核心信号只用一句话说清你想观测什么。比如“我想看到我的入睡时间每周是提前还是推后”。降低记录成本所有字段加起来不超过 5 个填写时间不超过 30 秒。生成一个可理解指标不要一上来做多维度报表先输出一个能驱动行动的数字。观察趋势而不是单点某一天睡得很好不代表问题解决连续两周才说明问题变化。设置一个小闭环发现连续偏差后在下周做出一个微小行为调整再观察效果。它看起来非常简单但长期坚持的难度在持续维护而不在于初始搭建。5.3 边界与不适用场景数据不能替代专业判断虽然数据很有价值但也必须承认它的边界。如果你的睡眠问题已经伴随长期疲惫、注意力严重下降、情绪持续低落或者每周至少有几个晚上几乎无法入睡这类情况不是一个小工具能解决的应该寻求专业医生或心理机构的帮助。“睡眠记录 行为调整”适合轻中度、由工作习惯和节奏紊乱引起的状态问题不适合作为严重失眠症或者睡眠呼吸障碍的诊断工具。手动记录带有很多主观因素不能作为医学证据。这篇文章介绍的方法更多是一种普通人的自我观测和工程化思考方式。它不能代替医疗诊断也不应该成为新的焦虑来源。如果发现数据让你变得更焦虑那就暂时停止记录回到让自己舒服的节奏里。5.4 给长期使用者的工程建议如果你决定把这个工具长期用下去我建议给它加三样东西备份机制CSV 文件同步到自己的网盘或者 Git 私有仓库避免手机丢了数据全没。版本注释如果改了字段结构单独写一个变更说明方便几个月后回看。定期复盘每隔四周生成一次报告并且花十分钟写下下一阶段想调整的一个行为。这三点不是必需功能但它们决定了你能不能坚持和使用到第四季度。最后回头再看这个叫 Shitty Sleep 的小项目我很庆幸自己当初没有急着找一个“睡眠改善神器”而是选择先动手记录两周数据。它没有让我第二天立刻变成 5 点起床的晨型人也没有把睡眠时长从 6 小时拉到 9 小时但它让我第一次看清楚了自己入睡时间的漂移曲线。之后我开始做了两个近似的调整睡前 90 分钟不打开编辑器不在深夜给自己安排“再看一眼”的任务。效果不是立竿见影的但三周后平均入睡时间确实往前移了 40 分钟左右。如果一定要说这条思路里最值得实践的一句话我会说先从最小最小的一步开始用数据代替情绪用趋势代替宣言剩下的交给时间。