Agent Skills
返回列表
💻

无状态日历同步任务

开发编程 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，将 @user_3c6cb52e/sync-calendars-between-providers-with-a-stateless-calendarsync-job 安装到当前 AI 助手中。

技能介绍

要解决的问题

把日历从 Google 迁到 Outlook，或从自建 CalDAV 同步到第三方客户端，常见做法是搭一套常驻的双向同步服务。但很多场景其实只需要一次性迁移或短期对齐：换了邮箱提供商、整理家庭共享日历、把散落的 ICS 文件合并到统一日历服务。为了这种一次性任务去维护一个长期运行、还要管理同步游标和冲突日志的服务，成本明显不对等。

这个技能用无状态（stateless）的 CalendarSync 任务来覆盖这类需求：不启动常驻进程，不维护跨轮次的同步状态，跑一次就把源日历的事件带到目标提供商。

核心能力与工作方式

技能围绕一个核心假设设计：同步是一次性的、跑完即结束。它不跟踪增量变化，也不保留同步位置标记，因此每次运行都是自包含的一轮全量搬运。

支持的源与目标覆盖主流日历生态：

  • Google Calendar
  • Outlook / Microsoft 365 日历
  • CalDAV 服务（如自建或第三方）
  • ICS 文件与相关系统

运行前需要准备三样东西：CalendarSync 二进制文件、目标/源日历的访问凭据，以及一份 sync.yaml 配置文件。配置文件负责声明源与目标的连接方式和同步范围，凭据负责授权，二进制负责实际搬运事件数据。三者齐备后，任务即可在单机上以一次性作业的方式执行，无需数据库、无需后台守护进程、无需为「上次同步到哪了」保存任何状态。

这种方式把「日历迁移」从部署一套服务降级为跑一个任务：适合 CI 里做迁移演练、在跳板机上临时搬运、或作为更大迁移流程中的一个环节。

适用边界与注意点

无状态设计带来明确取舍，选型时需要对号入座：

  • 适合一次性迁移：换提供商、整合日历、导出/导入场景非常契合。
  • 不适合持续同步：它不会持续监听源端变化，也不做增量追平。如果需要长期保持两端一致，这个方案不适用，应该选常驻同步服务。
  • 无历史状态：任务本身不保存游标或已同步记录，重跑意味着重新做一轮同步，设计时要自己控制重复触发的影响。
  • 凭据与配置需自行管理：sync.yaml 和日历凭据的存储位置、权限控制需要按自身安全要求处理，技能本身不替你托管密钥。

一句话总结：当你的日历同步需求是「跑一次，搬完就走」，这个无状态方案比常驻服务轻得多；如果需求是「永远同步」，那它根本不在适用范围内。

参考资料

  • 上游文档：https://raw.githubusercontent.com/inovex/CalendarSync/HEAD/README.md
  • 技能仓库：https://github.com/1991513ccie-png/skills

使用场景

  • 个人邮箱从 Gmail 换成 Outlook，需要把 Google 日历事件整体迁到微软账户，跑一次就结束。
  • 团队把日历服务从公共 CalDAV 换到自建服务器，需要一次性拉取并写入新端。
  • 从 Outlook 导出若干 ICS 文件后，需要导入到 Google Calendar 并合并到一个日历。
  • 旧工牌回收前要把员工日历从企业 Exchange 迁到个人 Google 账户，避免长期开同步。

适合人员

  • 负责邮箱与账号迁移的运维工程师，需要在更换邮件提供商时搬走日历数据。
  • 管理团队日历的后台开发者，要在更换 CalDAV 服务商时做一次性迁移。
  • 经常在 Outlook 和 Google Calendar 之间倒腾日程的个人技术用户。
  • 负责员工入离职流程的 IT 人员，需要在账号交接时转移日历事件。