Yolo 开发记录 01：从今天开始记录

Yolo 是我最近在做的一个时间记录工具。

它不是一个单纯的 todo list。Todo list 更像是在记录「我打算做什么」，但 Yolo 想记录的是「我实际把时间花在了哪里」。

所以它的核心不是任务勾选，而是任务和时间记录之间的关系：创建一个任务，开始它，暂停它，停止它，留下 note、blocker、next action 和完成度。一天结束以后，我看到的不是一个漂亮但可能自欺欺人的完成列表，而是一条真实的时间线。

现在的 Yolo 是一个 Tauri 桌面应用，用 React + TypeScript 做界面，本地 SQLite 存数据。它有 Today 页面、Focus 区域、Timeline、Backlog、计划系统和 Life view。方向上，我希望它先成为一个我每天真的会用的时间账本，然后再逐渐长出 AI-native 的能力。

这是 Yolo 的第一篇开发记录。

严格来说，Yolo 并不是今天才开始。之前已经搭好了桌面应用、任务系统、计时、Today 页面、计划、日志、Life view，以及 MCP Server 的雏形。

所以这里说的「第一天」，不是指项目从零启动，而是从今天起，我想认真记录它是怎么一步步长出来的。

之前的开发更像是快速堆出一个可用原型：想到功能就加，发现问题就修，UI 不顺眼就重构。这个过程很爽，但回头看只剩下 commit 和代码，很难记起当时为什么这样设计，某个功能又是怎么长出来的。

所以，从今天开始记录。

这篇不是复盘，而是一张起始快照：现在它是什么样，我为什么按这个顺序做，以及后面准备怎么继续往 AI-native 的方向推进。

现在的状态

目前 Yolo 已经有：

• Tauri + React + TypeScript 桌面应用
• 本地 SQLite 数据库
• 任务与分类系统
• start / pause / resume / stop / complete / drop 的任务生命周期
• Today 页面，安排与记录今天
• Focus 区域，显示当前正在做的事
• Today Log / Timeline，回看今天实际发生了什么
• Backlog 与计划能力
• Life view，将时间尺度拉到人生周历
• 一个只读 MCP Server，让 AI 读取任务和时间记录

这是一个可用的骨架，但还不是最终形态。

现在的 Yolo，更像是一个最小可用的时间记录系统。它能留下一天里真实做过的事，而不只是一个模糊的感觉：

今天好像很忙。

我做 Yolo 的初衷很简单：

我想知道自己的时间到底花到哪里去了。

Todo list 记录的是「我打算做什么」。

但很多时候，真正重要的是「我实际做了什么」。

这两个东西差距很大。计划里，我可以写今天学日语一小时、写代码两小时、看书半小时，听起来很合理。但一天结束以后，也许我只是在不同任务之间来回切换，最后什么都做了一点，又什么都没做深。有时候以为一上午学了很久，真正记录下来才发现，专注时间可能也就一两个小时，剩下的全被细碎的小动作和走神悄悄吃掉了。

Yolo 想记录的是后者。

不是意图，而是事实。

为什么不是一开始就做 AI-native

我没有一上来就把 Yolo 做成一个 AI-native 应用，也没有先画一个宏大的 AI 时间管理架构。

原因很简单：我想先做一个自己每天真的会打开、真的会用的工具。

一个看得见、摸得着的界面：正在走的时钟、今天的任务、今日统计、时间线。

如果只是想做一个纯 AI 时间管理助手，用 Hermes Agent + Google Calendar + Obsidian 也能拼出一个不错的工作流。但我想要的是一个真实产品，一个我自己每天记录、每天复盘、每天能感受到摩擦的桌面应用。

只有真的用起来，问题才会浮现。

比如，停止任务时记录的 note、blocker、next action、完成度，一开始只是普通记录。但当记录变多以后，它们就天然适合让 AI 帮我总结：

• 今天卡在哪？
• 哪些任务总是低估时间？
• 明天应该优先做什么？

再比如 daily summary。

如果 Yolo 没有真实的 time entries，AI 只能听我口头描述「今天好像做了很多」。但人对自己一天的记忆经常不可靠。

数据至少冷静一点。

SQLite 不会安慰我，这点很好。

所以 MCP Server 不是突然加上的 AI 噱头，而是一个自然的下一步。

既然 Yolo 已经有了任务、分类、时间记录和每天的实际执行数据，那 AI 就应该能读取这些数据，而不是只靠我口头复述。

我想让 AI 出现在合适的位置

我现在对 Yolo 的 AI 方向比较明确：

AI 不应该只是一个独立入口，而应该嵌入到真正能减少摩擦的流程里。

比如：

• 每天结束时，根据真实时间记录生成 daily debrief
• 基于 backlog、due date 和可用时间，帮我规划明天
• 发现某类任务经常超时，帮我校准预估
• 根据 stop notes 总结 blocker 和 next action
• 创建任务时，把自然语言整理成结构化任务
• 复盘时指出计划与执行的偏差

这些功能的前提是：Yolo 自己先是一个能用的工具。

• 没有基础数据，AI 只能猜。
• 基础流程不好用，AI 只能补锅。

但当基础工具本身已经能顺畅记录一天，AI 就会变成一个自然的增强层。

这才是我想要的 AI-native。

• 不是「这个 App 有 AI」。
• 而是「这个 App 的数据和流程，本来就适合被 AI 理解和改进」。

从今天开始记录

这篇记录，对我来说是一个分界点。

之前是在把 Yolo 做出来。

从今天起，我想记录它是怎么生长的。

我不想把这个项目包装成一开始就规划完美的东西。真实情况是，它就是边用边变清楚的：

1. 先做一个能每天用的时间记录工具。
2. 然后在使用中发现重复动作。
3. 再把重复动作自动化。
4. 再让 AI 基于真实数据参与总结、计划和校准。

这个过程比一开始画巨大架构图更踏实。

也更符合我现在做工具的方式：

别过度计划，先让自己用起来。

真的用了，问题会自己冒出来。

问题冒出来以后，再决定要不要自动化，要不要接 AI。

Yolo 现在还很早。

但我想认真记录它一点点变成自己的过程。

如果之后它真的变成了一个 AI-native 的时间记录系统，我希望回头看时能看到：它不是突然变成这样的。

它是从一个很简单的问题开始的：

我今天的时间，到底花到哪里去了？

今天做的 MCP 接入

今天比较关键的一步，是把 Yolo 的 MCP 能力真正接到了 Hermes 里。

之前 Yolo 项目里已经有 MCP Server 的雏形，但它还只是项目里的代码：能看到，能构建，但还没有变成我日常使用的 AI 助手可以直接调用的工具。

今天把这条线接上了。

现在 Yolo 的 MCP Server 是只读的，主要暴露这些能力：

• list_tasks：列出任务
• get_task：查看某个任务和它的时间记录
• list_time_entries：列出某一天或某个时间范围内的时间记录
• daily_summary：生成某天的时间统计
• list_categories：列出分类

接入以后，Hermes 可以直接通过 MCP 读取 Yolo 的本地 SQLite 数据，而不是让我手动描述「我今天做了什么」。

这件事很重要。

因为这意味着 Yolo 开始从一个普通的时间记录工具，变成一个 AI 可以理解的时间记录系统。

举个最简单的例子，我现在可以直接问：

List my tasks

Hermes 就能通过 MCP 读取 Yolo 里的今日任务，告诉我当前正在做什么、还有哪些 todo、分类是什么、预计时间是多少。

这不是一个很炫的功能，但它是 AI-native 的基础。

AI 不应该靠我回忆，也不应该靠我每次复制粘贴上下文。它应该能在权限允许的范围内，直接读取真实数据，然后基于这些数据帮我总结、提醒、计划和校准。

今天这个 MCP 接入，就是这个方向的第一步。

现在它还只是 read-only，只能读，不能写。

等读的部分稳定以后，下一步才会考虑更谨慎的写入能力，比如创建任务、补充 note、生成明天计划，或者在确认后帮我开始/停止某个任务。

所以今天的进展可以简单总结成一句话：

Yolo 终于不只是我自己能看的时间账本了，它开始能被 AI 读取了。