在电脑上搭建个人AI幕僚长：OGAD实战指南

每天早晨打开电脑，你是否也面临同样的困境：下一场会议在日历里，关键决策藏在昨天的笔记中，某个未完成的任务还停留在另一段对话里。信息散落在不同应用中，光是切换和拼凑就要消耗大量精力。

OGAD（Off Grid AI Desktop）Pro 试图解决这个问题。它内置了一个名为 God 的AI助手，能够整合已连接的账户、保存的工作记录和任务清单，为你生成一份可执行的工作简报。选择本地模型后，模型推理完全在电脑上运行，只有连接邮箱和日历等服务时才需要联网。

个人AI幕僚长能做什么

它的核心价值在于准备工作：收集相关事实、识别未完成事项、建议合理的处理顺序。一份好的晨间简报应该告诉你下一场会议是什么、需要做什么决策、以及哪项任务如果拖延会形成阻塞。

助手可以读取已连接的Google或Microsoft账户信息，也能调用OGAD中保存的工作内容。如果开启了屏幕捕获功能，留存的历史上下文还能帮助回答关于早期工作的问题——但捕获是可选的，助手无法恢复从未被捕获或提供过的活动记录。

定时任务将这种能力延伸到重复性工作：你可以设置工作日简报、会议前审查，或在特定事件触发时生成摘要。需要审批的操作仍然需要你手动确认——连接邮箱账户本身并不会自动授予发信权限。

工具调用（Tool Calling） 是本地模型需要具备的关键能力。普通对话模型只能生成文本，而支持工具调用的模型可以在回答过程中主动发起结构化请求——例如查询日历 API、读取保存的笔记或检索历史记录——再把返回的真实数据整合进最终回答。God 之所以能生成带来源标注的简报，正是依赖这一机制：模型判断"我需要知道今天的会议"，于是调用日历工具，拿到结果后再组织语言。这也是为什么前文强调要"选择一个支持工具调用的本地文本模型"——如果模型不支持，助手就只能空谈，无法触及你的真实数据。

从一个小任务开始

假设你同时管理两个客户项目，想知道该先准备设计评审还是先完成提案。不要一上来就接入所有数据源，先用一个账户和少量相关笔记试水。

1. 安装当前OGAD测试版并启用Pro
2. 下载并选择一个支持工具调用的本地文本模型，确认它能正常回答聊天请求
3. 打开 Integrations，连接你需要的账户，按步骤完成登录和授权
4. 打开 God，从 Chat 模式开始
5. 用明确的时间范围和简短输出格式请求一份简报

可以试试这个提示词：

准备我接下来三小时的工作。读取今天的已连接日历和相关保存的工作。列出下一场会议、一项准备任务、以及今天到期的未完成承诺。为每条事实标注来源。把明确的截止日期和你的建议分开。不要发送消息或修改日历事件。

行动之前先打开第一个来源核实。确认会议时间和时区——笔记上写着「争取周五完成」和「约定周五截止」是两回事。让助手把这个区别保持可见。

让简报真正服务于决策

一份罗列所有事项的清单很难执行。你需要一个简短的结构，把每条建议和证据关联起来：

简报部分	应包含的内容
下一个固定事件	会议名称、开始时间、所属账户
准备工作	该事件需要的文档或决策
未完成承诺	承诺内容、来源、明确的截止日期
建议的第一步	你现在就能完成的一个动作
缺失的上下文	助手无法核实的事实

以设计评审为例，答案可能指向一个未解决的布局选择，你可以进一步要求对比笔记中的两个方案。对于提案，助手可能找到承诺的交付日期，但优先级由你来决定。

在God设置的 Name and rules 中可以配置跨对话生效的指令。例如：「晨间简报不超过五项。截止日期必须显示来源。任何外部操作前先询问。」这些指令引导助手行为，但事实性结论仍需你自己核实。

把准备工作变成每日例程

手动简报确认有用之后，进入God设置的 Scheduled tasks，添加一个包含相同指令的例程，选择星期和时间。检查保存的计划，用 Run now 立即运行一次查看结果。

例程通过OGAD运行，需要保持电脑唤醒、应用运行、模型和账户可用。定时计划不能让关机的笔记本变成云端工作机。查看下一次计划执行的结果，确认它使用了你预期的数据源。

从单一例程开始。如果同时添加晨间简报、会议准备和日终回顾，重复信息会掩盖哪个例程需要调整。

语音与本地推理的边界

God还提供语音模式和可选的唤醒词设置，适合在准备会议或双手被占用时使用。使用免提控制前，先检查所选语音模型和麦克风状态。Chat模式是更好的起点，因为你可以同时审视请求、来源和回答。

本地推理的声明必须和当前激活的模型绑定。选择远程模型时，回答所需的上下文会发送到该端点。即使模型本身在本地运行，读取实时账户数据也涉及账户服务提供商。

本地推理与远程推理的区别，本质上在于"模型权重运行在哪里"。选择本地模型时，你的提示词、笔记内容和检索到的上下文都留在电脑内存中，不经过外部服务器；但读取 Gmail 或 Outlook 日历这一动作，仍然要通过 Google 或 Microsoft 的接口，数据往返于你的账户服务商。选择远程模型则不同：模型运行在第三方端点上，回答所需的全部上下文——包括从日历取回的事件标题、时间甚至笔记片段——都会作为请求发送过去。因此"本地"这个标签只描述推理环节，不覆盖数据获取环节，用户需要分别评估这两条路径各自的隐私边界。

简报不完整时怎么办

事件缺失时，检查已连接账户中是否存在该事件。旧工作内容缺失时，确认OGAD是否保留了它，或者你是否提供过相关笔记。助手无法使用某个集成时，检查连接状态和模型的工具支持能力。

这份指南基于beta 122版本及其包含的功能代码，不报告任何经过测量的生产力提升数据。第一个评判标准是你自己的三小时简报：来源是否准确、下一步行动是否清晰、信息缺失时是否明确标注。

先用一个账户和一份晨间简报试试OGAD。等第一次结果真正帮你做出决策之后，再添加定时任务。

定时任务（Scheduled tasks）的执行依赖容易被误解。OGAD 的例程本质上是在本地应用进程内触发的脚本，它需要电脑处于唤醒状态、OGAD 应用正在运行、所选模型可用、已连接的账户授权仍然有效。任何一环断开，例程都会静默失败或跳过。这意味着它无法替代云端调度器：合上笔记本或让系统进入睡眠后，晨间简报不会在后台"补跑"。排错时，先确认下一次计划时间电脑是否开机，再检查应用是否常驻运行，最后验证模型和账户连接是否仍然有效。