孔良我每天下班前打开日历，发现自己根本想不起来下午两点到四点之间到底做了什么，这种感觉相信每个上班族都不陌生。我开始意识到，问题不在于我的记忆力，而在于缺少一条可信的工作轨迹。市面上叫“工作轨迹记录器”的工具不少，但要么太重（要建项目、建任务、填工时），要么太轻（只是打卡、截图、拼日报）。我真正需要的，是一个能帮我回答“时间去哪了”“我今天到底干成了什么”“这个项目的推进曲线长什么样”的工具。于是我花了几周时间，从一个本地脚本起步，把它做成了一套完整的Work Review系统，也就是标题里的“工作轨迹记录器”。
这篇文章会从需求拆解、数据结构设计、技术实现、复盘机制到实际迭代全过程展开，包括我在真实使用中踩过的坑、推翻过的设计、以及最终的取舍逻辑。如果你想自己动手做一个类似的东西，或者只是想优化自己记录和复盘工作的方式，这篇内容应该能给你一套可以复用的思路。
1. 为什么需要“工作轨迹”，而不是任务清单或备忘录
1.1 任务清单解决的是“接下来做什么”，轨迹解决的是“之前发生了什么”
我最早尝试过用任务管理工具来记录工作，比如新建一个“对接客户需求”的任务，然后打勾完成。但这类工具天然面向未来：它要求你先定义任务，再执行、勾选。问题是，真实工作里大量事情是碎片化、临时插入的，比如开会被拉进一个新群、帮同事排查了一个问题、被领导叫去同步进度。这些事情没有提前定义成任务，事后自然也不会出现在清单里。
而工作轨迹的核心不是“完成任务”，而是“还原事实”。它像行车记录仪一样，只需要持续记录时间轴上的事件，不需要事先规划。后来我复盘时会发现，很多真正消耗时间的事情压根没进过任务清单，但它们占据了工作日的三分之一。这种发现，只有在轨迹数据里才看得见。
1.2 备忘录的问题：没有结构，就没有洞察
也有人觉得，记录嘛，随手写几句备忘录不就行了。我也试过。但纯文本备忘录的问题是，它只有内容，没有维度。你只知道“下午在写方案”，却不知道这个方案花了多久、和上周哪个关联、有没有产生下一步行动。当你月底想统计“这周在需求沟通上花了多少钱的时间”时，备忘录完全帮不上忙。
所以我在设计Work Review时，确立了一个基本原则：轨迹的最小单位不是一个句子，而是一条带有多维属性的记录。时间戳、内容、标签、关联项目、下一步行动，这些字段缺一不可。记录方式可以像发朋友圈一样轻，但数据结构必须像数据库一行记录一样严谨。正是这种结构化，让后续的统计、回顾、生成周报成为可能。
1.3 市面上现成工具的落差在哪里
我也认真评估过市面上各类时间追踪和屏幕记录工具。Toggl、RescueTime、Clockify都试过一圈。RescueTime这类工具会自动记录你用了哪些软件，但问题很典型：它知道你在钉钉上，却不知道你是回复消息、开语音会议还是摸鱼。它记录的是“应用使用情况”，不是“工作内容”。Toggl这类手动计时器又太重，每换一件事就要启动、停止、选项目、填备注，坚持不了几天就会放弃。
另外还有一类截图型工具，每隔几分钟截一次屏。这类工具对个人隐私的侵入感太强，而且截图本身并不是结构化数据，事后回顾依然要重新“看”一遍才知道自己在干嘛。我真正想要的，是一个具备轻量录入、结构化存储、定期复盘能力的工作轨迹记录器，它应该介于自动时间追踪和纯手写日志之间，取两者的优点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。