Guide · 使用教程
Motion 自动排程与项目规划教程：从任务参数到团队容量
用真实项目配置 Motion 自动排程：校准日历忙闲、Schedules、任务时长与截止、拆分与缓冲，并处理 Could not fit、No ETA、逾期和团队容量。
这份教程要解决什么
Motion 的自动排程不是按一下按钮就结束。它把任务时长、开始日期、截止时间、优先级、个人 Schedule 与现有日历事件放进同一个计算过程，再为工作寻找时间。输入可靠时，它能提前暴露容量不足；输入随意时，它会把错误假设排得很整齐。
下面用一个小型内容与产品发布项目建立可维护流程。目标不是获得永远不变的“完美日历”，而是让计划在会议增加、任务延误和成员容量变化后仍可解释、可人工接管、可恢复。
上线前准备
先选择一个测试周期，建议七到十四天，只放十到三十个真实任务。不要第一次就导入全部历史项目。准备一份任务清单，包括负责人、预计时长、最早开始、真实截止、优先级、是否可以拆分，以及依赖谁的反馈。
建立成功标准：每天手工重排不超过多少分钟，Could not fit 的任务能否在十分钟内定位原因，关键截止是否提前出现风险，团队是否理解系统为什么移动任务。没有这些标准，试用很容易只剩界面偏好。
同时确定唯一真相源。如果 Motion 负责排程，外部系统是创建源还是只保留归档？状态、截止和删除如何同步？先写清楚，再连接自动化，避免同一任务在两个系统各自变化。
第一步：校准日历与 busy/free
先连接影响容量的日历，而不是所有能找到的日历。工作会议、客户预约和不可移动的个人事件需要进入计算；订阅节日、生日提醒或重复展示的共享日历通常不应占用容量。逐个查看它们在 Motion 中是 Busy 还是 Free。
用测试事件验证四个动作：在外部日历创建、移动、删除；在 Motion 修改；取消带来宾会议；断开连接。Google 与 Outlook 的事件可以双向同步，但 Motion 内部任务写回外部日历主要用于显示，方向不同；iCloud 的任务显示与部分同步行为更有限。不要用“连接成功”代替完整测试。
最小权限原则是只连接排程必需的日历。共享客户日历如只需忙闲，就不要暴露标题和描述。检查 Motion 任务写回时的可见性，避免内部项目名被家庭或外部共享日历看到。
第二步：建立分开的 Schedules
Schedule 定义任务可以在哪些时间被安排。至少建立“深度工作”“协作与行政”和“个人”三个窗口。深度工作可设置在注意力更好的上午，协作任务放在会议集中的时段，个人 Schedule 避开组织工作时间。
不要创建一个每天十二小时可用的巨大 Schedule 来追求更多空档。系统会相信这个容量，生成不可持续计划。午餐、接送、锻炼和恢复是约束，不是可以无限压缩的噪声。
跨时区团队要以成员本地时间核对。兼职人员、固定休息日和轮班应有各自 Schedule，不能由经理的工作时段替代。修改 Schedule 后重新观察未来一周，确认没有把任务推到夜间或周末。
第三步：填写任务的五个关键参数
每个会进入自动排程的任务至少需要清晰动作和 duration。标题写“完成首页文案初稿”，不要写“官网”；时长用现实估计，并包含打开资料、沟通和收尾，而不是只算键盘输入。
start date 表示最早可以开始，不是提醒日期。等待客户素材的任务应把开始设在素材预计到达之后；若只是暂时不想做，不要滥用未来 start date，否则它会在当前日历中消失，让你误以为排程失败。
deadline 应反映真正交付时刻，并在外部提交之前留出审核缓冲。priority 只表达相对顺序，不应把所有任务都标成最高。Schedule 决定可安排窗口，负责人决定消耗谁的容量。五项一起构成可解释计划。
第四步：拆分长任务并设置休息
超过两到三小时的知识工作应考虑拆分为可以独立完成的块，例如研究、提纲、初稿、审阅和发布。巨型连续任务容易找不到空档，也让实际进度无法反馈。拆分不是把每五分钟变成任务，而是建立可以验收的阶段。
为深度工作保留休息。连续四小时满排即使技术上可行，也不代表人能稳定执行。可以缩短单个任务 duration、在 Schedule 中留出空白，或创建不可移动的午餐和恢复事件。
会议之间设置 buffer，线下会议还要加入 travel time。不要指望算法从地址自动理解真实交通风险。航班、医疗预约、直播和客户演示应作为固定事件，不能与普通任务一样自由移动。
一个跨项目示例
假设周五发布产品页面，同时为客户交付一份报告。产品项目包含：周一研究 90 分钟、周二文案初稿 120 分钟、周三设计审阅 60 分钟、周四发布检查 45 分钟。客户项目包含：数据清理 90 分钟、分析 120 分钟、报告 150 分钟、客户审阅后修改 60 分钟。
先把外部依赖设成正确 start date：客户修改不能早于审阅反馈。再把发布检查 deadline 设在正式上线前至少半天。研究和数据清理可以分配到深度工作 Schedule，审阅与沟通进入协作 Schedule。
周二临时加入两小时会议后，观察 Motion 是否把低优先任务后移、仍保护周四检查，并对无法满足的客户报告给出风险。如果系统只是把所有工作挤到晚上，说明 Schedule 过宽或容量假设不真实；先修约束，不要继续接受结果。
处理 Could not fit
Could not fit 表示当前约束下没有合适位置。按固定顺序排查：任务有没有 duration；start date 是否在未来；deadline 是否太近；指定 Schedule 在截止前是否有空档；外部日历是否把整天标成 Busy；任务是否大到找不到连续时间；负责人是否已超容量。
修复要对应真实原因。长任务可拆分，错误 Busy 可改为 Free，不现实 deadline 要与项目负责人协商，不能为了让红色提示消失就伪造时长或把截止随意推迟。修复一项后重新计算并记录结果，避免同时改五个参数而不知道哪个有效。
如果必须当天完成，暂停其他低优先自动任务，手动固定关键块并明确牺牲项。自动排程不能创造时间，只能显露取舍。
处理 No ETA 与暂未出现的任务
No ETA 通常意味着系统无法在当前参数下给出预计安排。除了 Could not fit 的检查项，还要看任务是否缺少关键字段、是否处于不参与自动排程的状态、项目或负责人是否配置正确。
未来 start date 会让任务直到窗口打开前不参与当前安排；这是预期行为。为避免团队误解，可在项目视图保留等待状态，并在依赖到期前设置审查任务，而不是把所有等待任务强行放进日历。
修复后从项目和日历两处读回，确认任务拥有 ETA、落在正确 Schedule，并没有覆盖固定事件。
处理逾期工作
逾期不是简单把 deadline 改成今天。先判断工作仍然需要、已经完成但未标记，还是被外部依赖阻塞。取消无价值任务，关闭已完成任务，把阻塞原因写清楚，再为仍需交付的任务重新估时。
如果多个任务同时逾期，按业务后果重新排序，并与相关方确认新承诺。Motion 能重排剩余容量，但不能替团队修改合同或客户预期。项目负责人应把新 deadline 和牺牲项作为明确决定。
每周统计估时偏差。如果同类任务持续超出 50%，应更新模板 duration，而不是每天手动补救。长期质量来自输入模型改善。
暂停自动排程与人工覆盖
遇到发布事故、差旅或需要完全稳定日程的一天，可以暂停 auto-scheduling。先固定不可移动事件和最关键任务，再手动安排缓冲。暂停期间新增任务仍要填写参数，避免恢复后一次涌入不可解释结果。
恢复前清理重复时间块、关闭已完成任务、修正临时 Busy 事件，并查看未来一周。先对一个 Schedule 或小范围任务恢复，确认没有夜间、周末或冲突，再全面启用。
人工覆盖不是失败。好的运行方式是算法处理频繁重算，人负责不可量化的优先级、关系和风险。明确哪些事件永远固定、哪些任务可以移动，会让双方边界稳定。
团队容量配置
团队先统一 duration 的估算口径：是纯执行时间，还是包含沟通、审阅和切换？同一种任务如果成员口径不同，容量视图无法比较。建议为常见工作建立模板，并每月用实际结果校准。
经理不应把成员日历填满到 100%。为支持、返工和突发沟通保留 15% 到 30% 缓冲，具体比例按工作类型调整。容量过载应触发缩减范围、延后截止或增加资源，而不是要求成员延长 Schedule。
Business AI 提供团队容量、Gantt、报告、时间追踪和权限。上线前检查谁能看私密事件标题、谁能修改成员任务、离职时如何撤销连接，以及集中计费和管理员访问。容量透明不等于无限监控。
每周维护流程
周一检查未来两周 deadline、Could not fit、No ETA 和成员休假；周三看真实完成速度与新会议影响；周五关闭无效任务、校准 duration、整理下周依赖。每次十到二十分钟即可，不要建立比手工排程更重的仪式。
每月复核日历连接、共享权限、自动化、模板和 pricing/credits 使用。每季度做一次撤销演练：断开测试日历，确认未来时间块如何处理、数据能否导出、团队知道回退路径。
保留三个指标：手工重排分钟、无法排入任务数、按期完成率。若三项连续数周没有改善，检查是不是工具不适合，而不是继续增加规则。
什么时候考虑替代方案
只想在既有日历旁保护 Focus、Habits、Tasks、会议缓冲和无会日，比较 Reclaim AI；偏好轻量每日时间块、Oasis 专注和复盘，比较 BeforeSunset AI；团队项目、文档和任务已经在 ClickUp，先验证 ClickUp AI Calendar。
Notion 用户若只是想搜索会议上下文，可使用 Notion Calendar AI Connector，但它不是持续自动排程引擎。无需让每个时间问题都变成平台迁移。
最终选择看维护后的净收益。能在变化后解释原因、允许人工接管并可靠恢复，比首次排出的“完美一周”更重要。
官方资料
常见问题
- Motion 自动排程最少需要哪些任务字段？
- 至少填写清晰任务、duration，并根据场景设置 start date、deadline、priority、Schedule 和负责人。字段越接近真实约束，结果越可解释。
- 为什么 Motion 显示 Could not fit？
- 通常是缺少时长、开始日期在未来、截止过近、Schedule 无空档、外部事件标为 Busy、任务太长或负责人容量不足。应按顺序逐项检查。
- No ETA 和任务丢失是一回事吗？
- 不是。No ETA 表示暂时无法计算安排，未来 start date 或不参与自动排程的状态也会让任务不出现在当前日历。应从项目与日历两处核对。
- 可以临时关闭自动排程吗？
- 可以。事故、差旅或关键发布日可暂停自动排程，手动固定关键块；恢复前清理重复、完成状态和错误 Busy，再从小范围逐步启用。
- Motion 会读取所有日历内容吗？
- 取决于你连接的账户、日历和授权。应遵循最小权限，先用测试日历，敏感共享场景尽量只提供排程需要的 busy/free，并检查任务标题可见性。
- 团队怎样避免把成员排满？
- 统一时长估算口径，为支持和突发工作保留 15% 到 30% 缓冲，用容量风险触发缩减范围或延后截止，而不是延长成员工作时段。