想让 Dots 帮忙排日程、催待办，真正需要先定下来的不是它能做多少事，而是每件事各自拿到多少权限。可用的做法通常是：把任务限定在“只读日历生成提醒、只写便签生成待办”这类可撤回的动作上，按任务逐项授权，而不是按应用一次性全开；跑完一个周期后对照日志看实际访问了哪些数据源，再决定扩大还是回收。付款、合同发送这类动作不要交给自动调度，越界部分改回人工确认。

低风险调度可以先按“单任务 + 最小权限”试跑：只读日历生成提醒、只写便签生成待办，避免一次性授予整个应用的权限。判断是否安全，看三处就够了——配置里声明的数据源、日志里实际调用的接口、任务结束后权限能否回收。涉及支付、合同发送、对外群发的动作不要交给 Dots 自动执行，需要的话保留人工确认这一环。

列出适合 Dots 接手的低风险调度任务

挑任务的判断标准可以简化成一条：出错之后能不能撤回、结果能不能被人工复核。日程提醒、待办汇总、会议前资料归集这三类通常满足条件，它们只影响你自己的视图或便签，不产生对外承诺。相反，支付类动作（转账、扣款、代付账单）、合同类动作（签署、盖章、对外发送合同文本）、以及任何形式的对外群发，一旦发出就很难收回，建议留在人工流程里，最多让 Dots 生成草稿。

• 日程提醒：读取日历事件的标题与时间，在开始前生成一条提醒。动作可撤回，漏提醒的代价可控。
• 待办汇总：读取任务列表或指定便签，按天聚合成一页摘要，写入专用便签。汇总错了可以改。
• 会议前资料归集：在指定目录或知识库范围内按会议标题检索，输出一份只读的资料清单，不替你做判断。

明确排除的包括：支付与账单代付、合同与协议的签署或发送、给外部联系人群发通知、以及任何会修改他人数据的操作。这几类即便配置上能做到，也不建议交给无人值守的调度任务。

为每项任务写清输入、输出和权限

逐项收窄的意思是：每个任务单独写一份输入、输出、权限说明，而不是给 Dots 一个笼统的“可以访问我的资料”。输入决定它能读什么，输出决定它能写哪里，两者分开声明，写权限永远不要顺手带上读全盘的能力。

下面是一个通用的任务级配置骨架，字段名需要按你实际使用的接入方式替换，重点是三件事：读写分开、deny 显式写出、给一个到期时间。

{
  "task": "meeting_prep_digest",
  "scope": "per_task",
  "inputs": [
    { "source": "calendar", "mode": "read", "filter": "today" }
  ],
  "outputs": [
    { "target": "note", "mode": "write", "path": "/notes/meeting-prep" }
  ],
  "deny": ["mail.send", "payment.*", "contract.*", "drive.search_all"],
  "expires_in": "72h"
}

验证方式很直接：跑完一个周期后，拿配置里的 inputs 和日志里实际出现的调用做对照。只要出现配置之外的读取或写入，先停任务，再看是配置写漏了还是任务被复用了别的授权。

在授权时按任务而不是按应用全开

一键全开的麻烦在于它不可分：一旦出问题，你无法只收回某个任务的权限，只能整体关掉。按任务授权则是每个任务一张单独的授权条目，改一个不影响其他任务，回收时也不会牵连仍在正常运行的调度。

授权前建议逐条过一遍下面这些检查项：

1. 这项任务最少需要读哪些数据源，能不能缩到一个日历、一个目录，而不是“全部日历”“全部文件”。
2. 输出落在哪里，能不能限定到专用便签或专用目录，而不是整个云盘或收件箱。
3. 任务里是否夹带了“发送”类动作（发邮件、发消息、提交表单），有就先删掉，改成生成草稿。
4. deny 列表是否显式写出，尤其是支付、合同、邮件发送这类关键词。
5. 是否设置了有效期或到期复查时间，避免临时授权变成长期授权。
6. 是否先用测试账号或测试日历跑过一轮，日志里有没有出现预期外的数据源。

这几项都过完再授权，成本不高，但能减少后面“不知道它到底能碰什么”的排查时间。

任务结束后检查授权是否可回收

授权不是一次性配置，需要跟着任务生命周期走。常见的回收触发条件包括：任务目标已完成或已归档；连续若干周期没有产生有效输出；任务依赖的数据源或目录已经变更；试用期结束；相关人员或角色发生变动。遇到其中任意一条，就可以进入回收检查。

回收检查表可以按下面几项逐一确认：

• 该任务的授权条目是否已移除，或已到过期时间自动失效。
• deny 列表是否仍然生效，回收后有没有被其他任务继承。
• 是否存在多个任务复用同一份授权，如果有，回收前先确认影响范围。
• 日志中是否还有该任务的调用记录，出现异常调用说明回收没生效。
• 降级运行是否可行：把写权限降成只读后，任务是否还能生成提醒或清单。

验证降级运行的做法是：先只保留读权限跑一轮，观察任务失败时是否给出明确报错、有没有静默写入或静默跳过；确认行为符合预期后，再决定恢复部分权限还是彻底停用。能稳定降级运行的任务，通常也更容易长期保留在低风险清单里。