Vida

Vida 是一个个人 AI 助手，它的核心不是被动响应指令，而是通过学习用户习惯，在用户开口前就主动执行任务。它面向那些日常事务繁杂、需要处理大量重复性数字工作的个人用户，比如频繁安排日程、整理信息或处理邮件的专业人士。

今天，一个用户要完成这类任务，主要依赖几种方式。最直接的是手动操作：自己打开日历安排会议，在收件箱里一封封筛选邮件，或者在不同应用间手动复制粘贴信息。另一种方式是使用规则引擎，比如在 Gmail 或 Outlook 中设置过滤器，或在 Zapier、IFTTT 上创建简单的自动化流程。但这些规则是静态的，一旦任务稍有变化或需要结合上下文判断，规则就失效了。更高级的用户可能会尝试用 Claude Code 或自己写 Python 脚本来处理，但这需要明确的指令和编程能力，且脚本无法理解“我通常周二下午不安排会议”或“这类邮件对我老板比较重要”这类隐含的个人偏好。

用户具体卡在“意图表达”和“上下文缺失”这两个环节。手动操作和写脚本都需要用户清晰地知道“现在要做什么”并给出明确指令。但很多日常工作是模糊的、依赖经验的，比如“把下周看起来重要的会议提醒我一下”，其中“重要”的标准因人而异，且随项目阶段变化。静态自动化工具无法捕捉这种动态的个人工作模式。用户不得不花费大量精力去“管理”自动化工具，而不是让工具“理解”自己。

Vida 切入的是 **Agent 管理层** 的问题。它不只是一个执行命令的单一 Agent，而是一个能管理用户多个数字工作流、并基于对用户历史行为的理解进行优先级排序和主动干预的“管理层”。它试图成为用户数字习惯的“操作系统”，而不仅仅是某个应用内的插件。

旧方案如 Zapier 或 IFTTT 不够好，是因为它们本质是“如果-那么”的规则连接器，缺乏学习和适应能力。它们无法从用户对已执行操作的反饋（比如取消了一个自动添加的日程、标记了一封自动归档的邮件为重要）中学习。而 Claude Code 或 Cursor 这类编码助手，虽然能根据指令生成代码，但生成的是一次性脚本，无法形成持续观察和演进的个人工作模型。

为什么现在成立？核心是 **AI 正从“聊天响应”转向“持续观察与执行”**。早期的 AI 助手如 Siri、Alexa 主要处理单次、孤立的语音指令。如今，大语言模型具备了更强的上下文窗口和工具调用能力，使得一个 AI 能够持续分析用户的历史行为数据（如日历、邮件、聊天记录），并主动调用 API 执行操作。同时，用户对 AI 的期望也从“帮我写段文字”升级到了“帮我管理我的工作生活”，这为主动式代理提供了需求土壤。

这透露出一个变化：AI 产品的竞争焦点，正从“一次生成的质量”转向“长期共处的默契”。当模型能力足够处理日常任务时，产品的差异化将体现在它能否像一位熟练的私人助理一样，理解用户的独特风格和未言明的需求，而不仅仅是准确完成显性指令。

对于 Builder 而言，今天可以直接将 Vida 或类似思路用于个人知识管理、邮件智能分类、会议纪要自动生成与分发等场景。它最值得学习的不是其技术栈，而是其 **“从观察中学习，而非从规则中执行”的产品设计哲学**。与其设计复杂的配置界面让用户设置规则，不如让产品安静地观察用户的操作模式，并在合适的时机提供“是否要我一直这样处理？”的轻量确认，从而逐步构建个性化的工作流。这种“低摩擦构建个性化自动化”的思路，可以迁移到许多领域，例如智能家居（学习用户作息自动调节环境）、个性化内容推荐（超越静态兴趣标签，理解用户当下的注意力焦点），甚至是开发工具（学习程序员编码习惯，自动补全代码块或运行常用命令）。关键在于，将 AI 定位为一个持续学习的协作者，而非一个需要精确配置的机器。