Tracel：把电脑的一天铺在时间轴上

我最近做了一个 App，叫 Tracel。它会记录电脑上的活动和系统状态，然后把这些信息铺在同一条时间轴上。

做它最直接的原因，其实很简单：我喜欢看见自己的时间去了哪里。

我是一个重度电脑使用者，平时会用两到三个显示屏，也习惯把日历放在最左边屏幕的左上角。工作的时候抬头看一眼，知道现在几点、接下来有什么安排，免得一不留神，几个小时就过去了。

日历让我看见计划。可到了晚上，我还想看见实际发生的事情：今天到底在写代码、查资料，还是在几个窗口之间来回切换？一段看起来很忙的时间，究竟做了什么？

能把这一天重新展开，会给我一种很具体的掌控感和成就感。甚至还没分析出什么结论，单纯看到那些记录，就已经觉得很满足。

我觉得这是一件很酷的事。Tracel 最初就是从这种有点自我满足的愿望开始的。

1我想要一条信息更丰富的时间轴

这类工具里，比较有代表性的是 ActivityWatch。我接触它时，最直接的印象是窗口活动和 AFK，也就是离开键盘的时间。它能回答一些很重要的问题：我用了哪些软件、用了多久、什么时候没有操作电脑。

但我还想知道更多。

比如，下午那一段时间，我的 IDE 一直在前台，CPU 却突然升高，磁盘也开始忙起来。那时可能是在编译。又比如，我切到了浏览器，但另一个应用仍然开着，GPU 还在持续工作。这些状态如果都摆在同一个时间位置上，就比一个单独的应用时长数字更有意思。

所以，我想把「我在做什么」和「电脑在发生什么」一起记录下来。

目前 Tracel 的 Windows 桌面版已经接入这些信息，每类采集都可以独立开关：

我喜欢它们同时出现在一条时间轴上的样子。前台应用可以展开看窗口上下文，GPU 可以展开看引擎，应用活动和性能曲线也有了共同的时间坐标。想看哪一层，就展开哪一层。

这些记录有各自的边界。桌面应用轨道目前不等于所有后台进程或系统服务；媒体信息依赖应用向 Windows 提供元数据；音频轨道记录的是电平，不保存录音。无法取得的数据会留空，不会伪装成零。

某个应用开着，不代表我一直在用它；两条曲线同时变化，也不能直接证明是谁造成了谁。但把线索放在一起，已经足够帮助我回头查一查那时发生了什么。

2最重要的交互，是自由地看时间

Tracel 的核心工作界面是一条时间轴。我希望大部分查看和分析，都可以围绕它完成。

它的缩放是连续的。可以先看一天的大致分布，再放大某一个小时，继续看几分钟，甚至几秒钟内的变化。看完细节，再缩回去，不必为了另一个时间尺度换一套界面。

这里要区分显示尺度和记录精度：当前常规采集间隔约为两秒，放大时间轴并不会凭空补出采样之间发生的事情。原生历史目前按天加载；跨越好几天的连续浏览是我想继续完善的方向，演示界面已经可以展示多天数据。

我很喜欢这种自由度。它让我可以自己决定要看多大的范围、要追到多细，而不是只能在几张固定报表里选一个。

另一个我很在意的交互是：在时间轴上选一段，右侧就分析这一段。

比如，选中下午两点到四点，就可以看这两个小时的应用时长排行、分类分布、性能统计和媒体记录。不选区域时，右侧就分析当前屏幕显示的时间范围。

这样，浏览和提问几乎是同一个动作：我看见一段感兴趣的时间，框住它，就能知道这段时间里有什么。放大、平移、选择范围，都沿着同一条时间轴进行。

设置、系统指标和其他辅助功能当然还有各自的页面。但对我来说，时间轴始终是这个 App 的中心。

3尽量开箱即用，也给定制留出口

自动记录工具如果在真正开始使用之前，还需要逐个配置应用、安装扩展、编写分类规则，就会消耗不少耐心。我希望 Tracel 尽量减少这部分准备工作。

当前的应用和窗口识别直接使用 Windows 提供的信息，不需要给每个被记录的软件安装插件。窗口标题本身也常常包含有用的上下文：例如 IDE 名称、项目名，或者正在编辑的文件名。

不过，标题里出现了一个文件名，不等于拿到了完整路径、语言、项目结构，更不等于知道文件里写了什么。当前 Tracel 记录的是窗口标题，还没有一个可靠的 IDE 文件语义解析器。

浏览器 URL 也是下一步想探索的内容。我希望研究通过 Windows UI Automation 读取支持浏览器的地址栏，尽量避免让用户额外安装浏览器扩展。这目前还是计划，尚未实现，也不能预先保证所有浏览器都能用同一种方法读取。

我的取舍是：先利用操作系统已经能提供的信息，让基础体验直接可用；需要更深入的上下文时，再看是否值得引入更专门的适配。

3.1分类也应该有一个可用的起点

我不想每次安装一个时间追踪工具，都先花半个小时搭一棵分类树。

不同人的「工作」当然不同。浏览器可能用来查文档，也可能用来看视频；游戏对某些人是娱乐，对另一些人却是工作。所以不存在一份对所有人都正确的分类。

但很多常见软件的粗粒度用途还是有共性的。我更希望 App 先内置一份能用的默认分类，让大部分记录有个去处，然后允许用户按自己的习惯调整。

Tracel 现在已经有一份数据驱动的分类 JSON，支持父子层级，也允许用户编辑自己的配置。比如一个应用可以归入「开发」下面的某个子类，父级会汇总子级的时间。修改分类后，历史视图也会按新规则重新归类，不需要改写原始记录。

当前规则按可执行文件匹配，完整路径优先于文件名；它还不是按窗口标题、网址匹配的规则引擎。以后如果增加更细的规则，我希望优先落到最具体的子类，同时保留父级汇总。

把配置放在一个明确的文件里，还有一个好处：以后可以让 AI 根据我的需求帮忙修改，而不必让人逐个点表单。目前这只是可编辑文件带来的可能性，还没有内置的 AI 分类助手。

4ActivityWatch 给了我启发，但我想做自己的使用体验

写这篇文章时，我也重新核对了一下 ActivityWatch。有几处最初的印象需要修正。

它默认启用的采集器主要是窗口和 AFK，但它并不只能记录这两种信息。官方列出了浏览器、编辑器、媒体等扩展，也列出了可以记录 CPU、RAM、磁盘、网络和传感器信息的社区采集器。专门的浏览器扩展能够提供更丰富的标签页信息，编辑器扩展则能提供文件和项目元数据。¹

「浏览器必须装插件才能拿到 URL」也不能一概而论：当前官方文档已经提到窗口采集器对部分浏览器 URL 的支持。是否需要扩展，应该根据平台、浏览器和希望取得的信息判断。¹

它也已经自带默认分类，并不是要求所有用户从零配置。父子分类、多个规则匹配时选择更深的子类，都是已有能力。²³

时间轴同样在继续进化。官方 v0.14.0 的介绍包含泳道、AFK 与分类过滤，以及按应用合并等功能。因此，用「只有两行、很死板」来概括整个 ActivityWatch，并不公平。⁴

这些事实没有改变我做 Tracel 的兴趣。我想要的是一种更符合自己习惯的组织方式：把应用活动、窗口上下文、性能和媒体状态直接整合到一起，用自由缩放和区域选择来探索，而不是先把各个采集器和视图拼起来。

我后来还发现，身边不止一个开发者用过 ActivityWatch，甚至有人想把时间追踪延伸到手机。这让我有点意外：原来喜欢看这些记录的人，并不只有我。

这还不能证明有多大的市场，也不代表用过 ActivityWatch 的人都会更喜欢 Tracel。但至少说明，想知道时间去了哪里，是一个能和别人产生共鸣的需求。

5以后，时间轴上也可能有 AI 的工作

最初，我只是想回看自己的一天。后来又觉得，如果电脑逐渐能在 AI 的操作下自行工作，这种记录也许会有另一种用途。

我给 AI 一个任务，让它运行一段时间，再回来查看：这期间有哪些应用在前台？什么时候 CPU 或 GPU 负载上去了？网络和磁盘有没有持续活动？它大概在哪个阶段停了下来？

时间轴可能成为一个方便的观察入口，让人先看到整体，再挑出值得检查的片段。

当然，这些状态不能替代任务日志，也不能证明 AI 完成了工作。要知道它执行了什么命令、修改了什么文件、结果是否正确，仍然需要更直接的记录和验收。Tracel 现在也没有自动理解 AI 工作过程的能力。

但我喜欢这个方向：当电脑里发生的事情越来越多，把它们按时间展开，会让人更容易回头理解它们。

对我自己也是一样。应用时长不能直接等同于效率，我也不打算让一张排行榜替我评价一天过得好不好。我只是想在觉得「今天好像什么都没做」的时候，有机会回头看看事实；在发现某种不喜欢的习惯时，也能找到具体的时段。

Tracel 还在开发中，目前主要面向 Windows，记录保存在本地，退出客户端就会停止采集。它已经能让我看见一部分过去容易忽略的电脑状态，而接下来，我想让这条时间轴更完整、更顺手。

如果晚上打开它，能看见今天写代码的片段、查资料的来回切换、听过的音乐，以及机器忙起来的那些曲线，我大概就会觉得：嗯，这一天确实发生了不少事情。

这就是我想做它的原因。

注释

1. ActivityWatch 官方文档，Watchers。列出默认窗口与 AFK 采集器、部分浏览器 URL 支持，以及浏览器、编辑器、媒体和系统资源扩展；具体能力依赖平台与适配。 ↩ ↩²

2. ActivityWatch 官方仓库，aw-webui 设置默认值。初始分类调用 getDefaultClasses()，说明用户不必从空白开始建立分类。 ↩

3. ActivityWatch 官方文档，Categorization。说明父子分类、子类时间汇总和多个匹配时选择最深子类的规则。 ↩

4. ActivityWatch 官方博客，ActivityWatch v0.14.0。介绍时间轴泳道、过滤和按应用合并等功能。本文对照信息核对于 2026 年 10 月 16 日；功能可能继续变化。 ↩