visual-base — 全量屏幕录像 + AI 自动写 Obsidian 活动日志的"第二大脑"

来源: https://github.com/oilbeater/visual-base

作者: oilbeater（bub 框架作者）

日期: 2026-05-19

评分: ⭐⭐⭐⭐☆ (4/5)

一句话版本

visual-base 是一个 macOS 后台屏幕录像工具，会自动把你一天看到的所有屏幕内容录成压缩视频，然后用 Kimi AI 分析视频，自动生成 Obsidian 格式的每日活动日志——不用你手动记任何东西。

核心内容

项目定位

Tagline: "The second brain from your eyes"

> 大多数"第二大脑"工具都要求你主动记录——写笔记、划重点、打标签。你没记下来的东西就消失了，而你记下来的只是你当天实际经历的一个有偏样本。

> visual-base 只记录你的眼睛看过什么：你的屏幕，连续不断地录制成压缩视频。这个原始视频流是唯一的事实来源。只要你屏幕上出现过，就在录像里。

架构


屏幕 → [ffmpeg + HEVC] → bub_eye（录像通道）
  → 每15分钟一段MP4（~10MB）
  → bub gateway 路由给 bub_kimi
  → Kimi 运行 video-activity-log skill 分析视频
  → 输出 Obsidian 每日活动日志

组件

模块	作用
bub	核心框架，gateway 是长期运行的 superisor
bub_eye	后台 macOS 屏幕录制（ffmpeg + avfoundation + HEVC 硬件编码），每 15 分钟一段 ~10MB，几乎不费 CPU
bub_kimi	接入 Kimi 作为默认的视频理解和日志生成 Agent
video-activity-log skill	将任意视频片段转为 Obsidian 可打开的每日日志

安装和使用


uv tool install visual-base
uv tool install kimi-cli
kimi login
visual-base gateway

一次启动录像 + AI 分析。视频存 ~/.bub/eye/segments/，日志存 ~/.bub/eye/logs/。

设计哲学

.mp4 文件 = 事实来源 — 全量录制，无过滤
.md 日志 = 派生产物 — 天然的 .mp4 索引
日志可随时重建 — 重播理解步骤就能重新生成
最终目标是 RAG — "你应该能像 RAG 自己的文档一样 RAG 自己的足迹"

video-activity-log Skill 深度解析

这是 visual-base 最核心的文件——定义了 AI Agent 如何把一段屏幕录屏转化为 Obsidian 活动日志的完整流程。

三分阶段架构

Phase 0 — Idle Preflight（空闲预检）


uv run ${SKILL_DIR}/scripts/preflight_idle.py --video <path>

用 ffmpeg 检测视频的场景变化率
如果大部分是锁屏/屏保画面 → 直接写一行 #idle 日志，不调用 LLM，省 token
退出码 0=空闲, 1=有活动, 2=环境错误

Phase 1 — LLM 看视频写草稿

视频直接传给模型（不抽帧、不转码、不OCR）
时间用相对偏移（MM:SS - MM:SS），Phase 2 再转绝对时间
写 Obsidian wikilink 风格的 Markdown

Phase 2 — 后处理定稿


uv run ${SKILL_DIR}/scripts/finalize_log.py --video <path> --draft <draft-path>

解析文件名中的 wall-clock 时间（eye_20260417_130000.mp4 → 13:00:00）
把相对时间转为绝对时间
填充 frontmatter（video/date/start/end）
质量校验（非阻塞，warn 级别）：

- gap：相邻 bullets 间隔超过阈值

- short：bullet 时长低于 30s

- head：第一条 bullet 距离视频开始太远

- tail：最后一条 bullet 没覆盖到视频结束

合并优先哲学

> 过度拆分比过度合并糟糕 100 倍——碎成一片的 micro-bullet 没法看，合并后的 bullet 仍然可检索。拿不准就合并。

具体规则：

≤30s 的快速切换视为干扰，并入相邻 bullet
同一工作流反复切 app（VS Code ↔ Terminal ↔ 浏览器查文档）= 1 条，不要拆 3 条
单条 bullet 最短 30s，更短的被 Phase 2 标记 short

嵌套合并 — 处理同一主题的多阶段：


- `00:12 - 10:28` 在 [[x.com]] 阅读 [[Garry Tan]] 的文章
    - `00:12 - 05:09` 通读原文，期间在 [[VS Code]] 短暂查看代码
    - `05:11 - 07:46` 浏览关于 [[AI agent]] 架构的论述
    - `07:46 - 10:28` 用 [[Raycast]]翻译为中文

判断标准：同主题 + ≤10min + ≥2 个明显不同的子动作 → 嵌套；只有 1 个 → 平铺。

Wikilink 命名规范

浏览器活动 → URL hostname：[[figma.com]]、[[docs.google.com]]（去掉 www，保留子域）
桌面/移动应用 → 应用名：[[VS Code]]、[[微信]]、[[Figma]]（桌面版）
理由：[[figma.com]] 能沉淀站点维度的笔记聚合，[[Figma]] 会混在一起降低检索价值

好坏对比


❌ `13:05 - 13:07` 在 [[Chrome]] 浏览
✅ `13:05 - 13:07` 在 [[trac.ffmpeg.org]] 查阅 [[HEVC]] 关键帧设置

❌ `13:30 - 13:31` 在 [[微信]] 聊天
✅ `13:30 - 13:31` 在 [[微信]] 和 [[chenkai]] 讨论 [[bub-eye]] v2 roadmap

❌ 把 刷Twitter / 回Slack / 改代码 拆成 3 条
✅ `13:40 - 13:55` 在 [[VS Code]] 改代码，期间在 [[twitter.com]] / [[Slack]] 短暂打断

完整示例：下午 1:00-1:15 修 bug

录屏文件：~/.bub/eye/segments/eye_20260519_130000.mp4（15 分钟）

Phase 1 草稿（LLM 输出）：


video: PLACEHOLDER
start: PLACEHOLDER
end: PLACEHOLDER

# 活动日志

- `00:00 - 02:35` 在 [[VS Code]] 查看 [[bub-eye]] issue #42，segment 不轮转的 bug
- `02:40 - 08:12` 在 [[trac.ffmpeg.org]] 查阅 HEVC 关键帧设置 `https://trac.ffmpeg.org/wiki/Encode/H.265`
    - `02:40 - 04:55` 阅读关键帧间隔文档
    - `04:55 - 08:12` 在 [[Terminal]] 测试不同 -g 参数组合
- `08:30 - 11:44` 在 [[VS Code]] 修改增加 keyint 参数
- `11:50 - 12:30` 在 [[微信]] 和 [[chenkai]] 讨论修复方案
- `12:35 - 14:55` 在 [[github.com]] 查看 PR review，提交 revision

## 关键实体

- 人：[[chenkai]]
- 项目：[[bub-eye]]
- 应用 (桌面)：[[VS Code]]，[[Terminal]]，[[微信]]
- 站点 (Web)：[[trac.ffmpeg.org]]，[[github.com]]
- 主题：[[HEVC]]

Phase 2 定稿（转换时间 + 填 frontmatter + 质量校验通过）：


video: /Users/me/.bub/eye/segments/eye_20260519_130000.mp4
start: 13:00:00
end: 13:14:55

# 活动日志

- `13:00:00 - 13:02:35` 在 [[VS Code]] 查看 [[bub-eye]] issue #42，segment 不轮转的 bug
- `13:02:40 - 13:08:12` 在 [[trac.ffmpeg.org]] 查阅 HEVC 关键帧设置 `https://trac.ffmpeg.org/wiki/Encode/H.265`
    - `13:02:40 - 13:04:55` 阅读关键帧间隔文档
    - `13:04:55 - 13:08:12` 在 [[Terminal]] 测试不同 -g 参数组合
- `13:08:30 - 13:11:44` 在 [[VS Code]] 修改增加 keyint 参数
- `13:11:50 - 13:12:30` 在 [[微信]] 和 [[chenkai]] 讨论修复方案
- `13:12:35 - 13:14:55` 在 [[github.com]] 查看 PR review，提交 revision

这个日志的价值：人扫一眼知道 15 分钟干了什么，Agent 打开能理解当时的工作上下文（工具、文档、讨论对象），每段都有精确时间戳可回溯到视频。

底层平台：Bub

visual-base 基于 Bub 框架（bub.build），这是 oilbeater 创作的一个极简 Agent 运行时：

~200 行核心代码
Hook-first 架构：每个 turn 阶段都是 pluggy hook（resolve_session → load_state → build_prompt → run_model → render_outbound → save_state → dispatch_outbound）
Tape 驱动上下文：context 从 append-only tape 记录重建，不累积在 session state 中。无 lossy summary，无 phantom memory
通道无关：同一 pipeline 驱动 CLI、Telegram 等
1.3k GitHub stars
多贡献者：frostming（重写者）、PsiACE、yihong0618、oilbeater 等（以中文社区为主）

Bub、Tape、Bee 形成了完整的生态：

tape.systems — 上下文存储层
bub — Agent 运行时
visual-base — 屏幕录像 + 日志
bee（scnace 的博客中）— 任务编排

分析

为什么有意思

1. 反"第二大脑"主流设计 — 主流工具（Obsidian、Notion）要求你主动写笔记，visual-base 说"别记了，你眼睛看过的东西全在这里"

2. 极低摩擦 — uv tool install + visual-base gateway 就启动了，不需要你改变任何习惯

3. AI 做脏活 — 你看一天屏幕，AI 帮你总结成日志。14 分钟录像生成一条活动记录

4. 设计理念清晰 — mp4 = source of truth，md = derived index。可重现，不丢失

5. 和 Tape 生态的关联 — bub、tape、bee、visual-base 构成了一个完整的 Agent 生态系列

隐私考量

全量屏幕录制是双刃剑——方便但极度敏感
所有数据存本地，不联网（Kimi API 调用除外）
作者说"如果你想要回磁盘空间，自己删文件夹"

潜在不足

只有 macOS — 用 avfoundation，Linux/Windows 不支持
Kimi 依赖 — 目前只用 Kimi 做视频理解，需要 Kimi API key
24 stars — 极早期项目
隐私边界模糊 — 录了密码/敏感信息怎么办？
视频存储成本 — 一天 8 小时 = ~320MB（15 min × 10MB × 32 段），一个月 ~9.6GB

与我们项目的关联

和 lossless-claw 的思路一致——都是全量记录 + AI 压缩为可读摘要
OpenClaw 的 "Dreaming" 功能（自动整理短期记忆）和 visual-base 的日总结功能在概念上是平行的
tape.systems 的 append-only context 模型对 OpenClaw 的上下文管理有参考价值

评分表

维度	评分	说明
创新性	⭐⭐⭐⭐	屏幕录像 + AI 日志的思路不是全新，但执行干净利落
设计理念	⭐⭐⭐⭐⭐	mp4 = truth, md = index，可重现，设计哲学一流
实用性	⭐⭐⭐	macOS only + Kimi 依赖，对日常使用有门槛
隐私	⭐⭐⭐	全量屏幕录制，本地存储，但 API 调用需注意
与我们关联	⭐⭐⭐⭐	与 lossless-claw / tape 生态思路同源

关键链接

https://github.com/oilbeater/visual-base — GitHub 仓库
https://bub.build/ — Bub 框架官网
https://github.com/bubbuild/bub — Bub GitHub（1.3k stars）
https://tape.systems/ — Tape 上下文系统
https://github.com/bubbuild/bub — Bub 框架