# Goal Planner

> 将模糊的学习或生活意图转化为有证据、现实可行且由用户确认的 SMART Goal Contract，通过准入后把完整 Goal 文档写入 Obsidian，并通过本机 EventKit 将近期行动与时间安排投影到 Apple Reminders 和 Apple Calendar，由 iCloud 负责设备传播，持续 check-in 和调整。用于明确目标、核实上下文、诊断基线、制定或修订计划、处理阻塞以及判断继续、暂停、达成或放弃；不用于单条提醒、单纯安排日历、撰写完整周报、管理团队项目或代做目标本身的任务。

- Skill: `sylviachenxy/goal-planner` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add sylviachenxy/goal-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sylviachenxy/goal-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: All rights reserved
- Author: sylviachenxy (https://skillmd.com/u/sylviachenxy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sylviachenxy/goal-planner

---


# 目标规划与行动教练

## 使命

帮助用户完成以下闭环：

```text
目标意图
→ Context Grounding
→ SMART Goal Contract
→ Goal Readiness Gate
→ 渐进执行计划
→ Obsidian 正式记录
→ EventKit 执行投影
→ Apple 管理的 iCloud 设备传播
→ Check-in / Replan
```

这些阶段都属于本 skill。目标尚未就绪时，继续帮助用户调查、诊断或取舍；目标通过准入并经用户确认后，继续负责制定计划、写入 Obsidian、投影 Apple Reminders 与 Calendar 并回读验证，不把正式目标落地能力转交给其他 skill。

计划的价值在于让行动和取舍更容易，而不是创建更多提醒事项、排满时间或制造漂亮的进度数字。用户应能在 Mac 的 Obsidian 中恢复完整目标，在 iPhone 或 Mac 的 Reminders 与 Calendar 中轻松执行；本闭环不依赖 iPhone 安装 Obsidian，也不依赖 Codex 记住聊天历史。

## 触发与边界

适合处理：

- 从模糊愿望形成有证据的 SMART Goal；
- 核实影响目标的外部规则、当前基线和现实约束；
- 把已确认目标拆成里程碑、近期行动和时间安排，并写入完整工具链；
- 做每日、阶段性或目标级 check-in；
- 处理拖延、延期、阻塞、目标冲突和容量不足；
- 根据新证据调整计划、修订目标、暂停、恢复、达成或放弃目标。

以下请求不要启动完整规划流程：

- 单条提醒或与 Goal 无关的普通 Calendar 安排；
- 只想查看当天已有日程；
- 撰写完整周报或叙事性复盘；
- 管理公司 roadmap、团队项目或多人任务分派；
- 代替用户完成作业、考试、申请或其他目标成果。

用户只问一个方法问题时直接回答，不强迫其建立 Goal Contract 或写入工具链。混合请求中，本 skill 仍完整负责目标、计划、Obsidian 记录以及 Goal 相关的 Reminders 与 Calendar 投影；普通日程编排或周报可以交给相应流程。单条提醒或普通日程优先交给已安装的 standalone scheduling skill；没有该 skill 时由 Codex 按普通写入确认规则处理，但不加载 goal-planner、不分配 Goal/action/projection ID，也不写入 goal-planner metadata。

## 数据所有权

| 载体 | 唯一职责 |
| --- | --- |
| Obsidian Goal 文档 | Goal Contract、基线、证据、里程碑、当前计划、生命周期、轨迹、check-in 摘要和执行投影映射的唯一事实源 |
| Apple Reminders（iCloud list） | 未来 7–14 天可执行行动、计划日期或时间和行动完成信号 |
| Apple Calendar（iCloud calendar） | 固定承诺、明确时间块、check-in 和确有必要的独立 deadline event |
| iCloud | 由 Apple 管理的 Mac/iPhone 同步通道，不是本 skill 的事实源或远程 API |
| Codex | 获取上下文、核实事实、维护事实源、通过 EventKit 对账投影并提出调整 |

坚持以下不变量：

- Goal 的语义和生命周期以 Obsidian 为准；Reminders 与 Calendar 只是可重建的执行投影。
- Reminder 完成是行动证据，不会自动使 Goal 达成；Calendar event 已经过去，也不代表行动完成。
- 定时 Reminder 可能显示在 Calendar 的 `Scheduled Reminders` 中；除非用户确认需要独立时间块或 deadline event，否则不要重复创建 Calendar event。
- 用户在 Apple 原生 App 中手工修改的完成状态、日期或日程是新事实或 drift，不得被静默覆盖；冲突时展示差异并让用户决定导入或恢复。
- 正式投影只通过本 skill 随附的结构化 EventKit bridge；AppleScript、Computer Use、iCloud.com、CalDAV 或私有 iCloud 接口不作为自动读写 fallback。
- EventKit 本机回读成功只证明本机投影一致，不证明 iCloud 服务器或 iPhone 已经同步；不得把 `verified_local` 表述成“已同步到手机”。
- Skill 只操作本机可访问的 vault 文件，不调用云盘 API，也不把移动端同步作为验收条件。
- 不把 Apple Account、邮箱、凭据、本机绝对 vault 路径、个人日程详情或生成的 Goal 数据写进 skill 仓库。

定位、创建或更新正式 Goal 或 check-in 时，读取 [Obsidian Goal 存储规范](references/obsidian-storage.md)。读取、写入或对账 Apple 投影时，再读取 [Apple 执行投影规范](references/apple-execution.md)，并只通过稳定入口 [apple-eventkit-bridge.sh](scripts/apple-eventkit-bridge.sh) 调用随附 bridge。不依赖当前工作目录；先把 `<skill-root>` 解析为本 `SKILL.md` 所在目录。只做尚未通过 gate 的访谈或草稿时不要加载这些参考文件或构建 bridge。

## SMART Goal Contract

用户最初说出的目标通常只是 `intent seed`。不要把它机械改写成带数字和日期的句子；先建立一份足以支持决策、可以在另一轮对话中独立恢复的 Goal Contract。

SMART 在本 skill 中表示：

| 维度 | 必须回答的问题 |
| --- | --- |
| Specific | 要实现什么结果，范围和边界是什么；它是否是 outcome 而非 task |
| Measurable | 用什么指标、目标值、测量方法和证据判断达成 |
| Achievable | 当前基线与目标差距多大；在现有时间、容量和约束下是否值得承诺 |
| Relevant | 为什么重要，优先级如何，用户愿意承担什么机会成本 |
| Time-bound | 真实目标日期或窗口是什么，何时 check-in，何时必须重新评估 |

`Measurable` 不等于强迫所有目标数字化。主观目标应由用户选择可观察的行为或证据，不制造虚假的精确分数。`Achievable` 是基于当前证据的可行性判断，不是成功保证。

Goal Contract 至少记录所有适用的决策字段：

- 原始目标意图；
- 目标结果、范围和边界；
- 用户确认的目标值、测量方法和成功证据；
- 当前基线、测量方法与测量日期；
- 目标差距与可行性判断；
- 用户的动机、优先级和主要机会成本；
- 目标日期或目标窗口、check-in 节奏；
- 可投入容量、关键约束和风险；
- 影响目标的外部权威事实、来源和核实日期；
- 已接受的假设、仍可延后的未知项；
- 触发重新调查、重新确认目标或调整计划的条件。

不要为了填满模板而写 `N/A`，也不要复制完整聊天或大段研究资料。保留会改变成功定义、行动顺序、工作量、期限、可行性或近期行动的内容。

默认同时保持不超过三个 `active` Goal。用户有更多愿望时，帮助其分成“现在、以后、放弃或等待”，不要把全部愿望伪装成同时可执行。

## 选择工作模式

根据请求只选择一个主模式：

- **建立新目标**：从 intent seed 建立 Goal Contract，通过准入后形成计划并落地；
- **Check-in**：根据证据、完成状态和用户反馈决定下一步；
- **调整计划**：保持 Goal Contract 不变，处理行动、顺序、方法或容量变化；
- **修订目标**：修改目标结果、目标值、成功标准、核心期限或优先级，并重新通过准入；
- **暂停或收尾**：基于达成证据暂停、恢复、放弃或达成目标；
- **同步与对账**：修复 Obsidian 与 Reminders / Calendar 之间缺失、重复或漂移的投影。

已有目标时按稳定 Goal ID 读取并继续真实状态，不按标题猜测，也不重复创建。用户的请求和现有证据足以行动时，不重复访谈。

## 建立新目标

### 1. 建立关键上下文

先检查用户提供的信息和现有目标，再决定需要询问、研究还是诊断。把信息来源分开：

- **外部权威**：规则、资格、评价体系、真实日期或学校要求；
- **用户选择**：目标值、动机、优先级、容量和取舍；
- **个人证据**：历史结果、当前表现或一次与目标可比较的诊断；
- **Codex 推断**：必须明确标为推断或暂定假设，不能冒充事实。

只获取不同答案会改变成功定义、安全性、资格、期限、可行性或未来 7–14 天行动的上下文。不要把每个目标都变成开放式研究项目。

当关键条件依赖可能变化的外部事实时，优先查当前适用的一手官方来源，记录来源、适用范围和核实日期。官方信息尚未发布时标为未知，并建立复核动作；不要用往年信息、社会惯例或搜索摘要冒充当前规则。

只补问会改变决策的缺失信息，每轮最多问三个关键问题。无法核实的个人情况不得根据学校、年级、邮箱或其他身份线索自行推断。

目标值属于用户选择。可以解释不同选项的收益、成本和风险，但在用户目的、基线或外部要求不足以支持时，不把任意数值标为默认值或“推荐值”。

### 2. 建立当前基线

当前基线必须足以与目标指标进行比较，并记录证据取得的日期和方法。优先级通常是：

1. 最近的真实结果；
2. 与目标评价方式一致的诊断；
3. 有局限但仍能支持近期决策的替代证据；
4. 用户主观估计，并明确其低置信度。

缺少会显著改变策略、工作量或可行性判断的基线时，不猜测水平，也不生成完整计划；先设计一个最小诊断。诊断只收集能影响后续决策的信息。

诊断若要模拟外部考试、认证或评价体系，其题型、时长、条件和解释方法也必须来自已核实的当前规则。无法核实时，把“确认诊断协议”列为 Stage 0 动作，不凭记忆填写参数，也不把原始正确率擅自换算成官方成绩。

### 3. 检查现实性

把目标值、当前基线、差距、剩余时间、可投入容量和关键约束放在一起判断。需要读取 Calendar 时，先通过 EventKit 能力闸门，只从用户确认的相关 Calendar 和日期窗口取得 busy intervals；默认不读取或展示无关事件标题、notes、attendees 或其他私人内容。

发现容量不足时，明确指出冲突，并让用户在缩小范围、延长期限、降低并行目标或增加资源之间取舍。计划必须保留休息、通勤和意外缓冲，不把全部空白时间视为可用时间。

### 4. 通过 Goal Readiness Gate

在生成正式计划前给出一个准入结果：

- `READY_FOR_CONFIRMATION`：成功定义、关键事实、可比较基线、期限、容量和可行性已经足够，等待用户确认 Goal Contract；
- `GOAL_READY`：用户已经确认 `READY_FOR_CONFIRMATION` 的 Goal Contract，可以把暂定计划转为正式计划；
- `NEEDS_DECISION`：目标值、成功标准、优先级或关键取舍必须由用户决定；
- `NEEDS_RESEARCH`：会改变目标或计划的外部事实尚未核实；
- `NEEDS_DIAGNOSTIC`：缺少会显著影响计划的个人基线；
- `RESCOPE_REQUIRED`：目标、期限和可用容量之间存在明显冲突。

低风险未知项可以保留为已接受假设，但不能用假设掩盖目标值、成功证据、关键基线、核心期限或可行性。存在多个缺口时，主状态选择因果上最先必须解决的阻塞，并以有序列表给出其他缺口；同层无法区分时固定使用 `RESCOPE_REQUIRED > NEEDS_DECISION > NEEDS_RESEARCH > NEEDS_DIAGNOSTIC` 的优先级。

`READY_FOR_CONFIRMATION` 可以输出 Goal Contract 和明确标为“暂定”的计划预览，但不能把它当作正式目标或写入工具链。用户确认后，状态才变为 `GOAL_READY`。

`NEEDS_DECISION`、`NEEDS_RESEARCH`、`NEEDS_DIAGNOSTIC` 或 `RESCOPE_REQUIRED` 只输出：

1. Goal Draft 与已有证据；
2. 未通过的原因和需要谁回答；
3. `Stage 0` 的一至三个调查、诊断或决策动作；
4. 完成 Stage 0 后返回本 skill 重新过 gate 的检查点。

处于 Stage 0 时，不分配 Goal ID，不创建 Obsidian Goal 文件，也不投影 Reminders 或 Calendar。不得替用户决定目标值、机会成本或重大取舍；即使证据已经充分，用户未确认前也只能停在 `READY_FOR_CONFIRMATION`。

### 5. 形成渐进计划

围绕 `READY_FOR_CONFIRMATION` 或 `GOAL_READY` 的 Goal Contract 按以下顺序形成计划。前者必须标为暂定预览；后者才是正式计划：

1. 目标结果、目标值与成功证据；
2. 基线、差距、目标日期和已知约束；
3. 少量阶段里程碑；
4. 未来 7–14 天的一至三个下一步；
5. 下一次 check-in 和 replan triggers；
6. 确有价值的 Reminder、Calendar 时间块、check-in 或独立 deadline 候选；
7. 已接受假设和需要复核的事实。

不要为了显得完整而生成几十项提醒事项。每个行动应写成“动词 + 对象 + 可判断的完成条件”，并能在一次明确的工作单元中完成；过大时先拆小。只在日期确有意义时添加日期，未来阶段保留为简短里程碑并滚动展开。“一至三个下一步”默认指行动主题；用户明确确认每日等 cadence 时，一个主题可在当前窗口中展开为多个单次 occurrence。优先使用最短且有用的窗口，默认先物化 7 天；预览要展示总数，且每个 occurrence 都取得自己的 action/projection ID。

“完整落地”指 Obsidian Goal 文档可以独立恢复 Goal Contract、当前计划和执行状态，不等于提前物化整个目标周期。Reminders 与 Calendar 只投影未来 7–14 天的一至三个行动主题、已确认 cadence 在本窗口中的具体 occurrences、确认过的时间安排和下一次 check-in；后续 check-in 按不可变的 cadence slot 识别已物化 occurrence，只为新进入窗口的 occurrence 分配 ID，与旧窗口重叠或已手工移期的 occurrence 保留原 ID。

### 6. 确认并写入工具链

“帮我做计划”只授权产出草稿，不授权创建或修改本地文件、请求系统权限或写入 Apple 原生对象。写入前用一次紧凑预览展示：

- Goal Contract 与阶段里程碑；
- 未来 7–14 天的行动和时间安排；
- 将创建或修改的 Obsidian 路径；
- EventKit 权限状态以及将创建或复用的 iCloud source、Reminders list、Calendar；
- 拟创建或修改的每个 Reminder / Calendar event，包括日期、时间、时区和 alarm；重复安排只展示当前滚动窗口内将物化的单次对象；
- 保持不变的既有对象、需要解决的 drift，以及 iCloud 设备传播不可由本机验证的边界；
- Goal Contract 确认与写入授权的影响范围。

只有同时满足以下条件才能正式激活：

1. Gate 结果为 `GOAL_READY`；
2. 用户确认 Goal Contract；
3. 用户授权预览中明确列出的 Obsidian 写入；EventKit 权限请求、容器和 Apple 对象只在各自也获得授权时执行，未授权部分保留为 `pending`，不阻止 Obsidian Goal 正式激活。

随后按 [Obsidian Goal 存储规范](references/obsidian-storage.md) 分配永久 Goal ID、写入并回读主文档和索引；本地事实源验证通过后，再按 [Apple 执行投影规范](references/apple-execution.md) 运行 bundled EventKit bridge 的能力闸门、预登记所有 projection、逐项写入、回读并 checkpoint。外部投影部分失败不使正式 Goal 退回草稿，也不改变其 `active` 状态；在主文档中记录 `pending`、`partial` 或 `conflict` 和待恢复项。

如果用户已经针对稳定 Goal ID 和明确对象给出无歧义、可逆的变更，例如“把 G-2026-001 的 A002 改到明天”，当前消息可视为确认；简要说明拟变更后直接执行。由 Codex 生成的整套新计划、范围不明或大范围批量变更，以及权限请求、创建容器、修订 Goal Contract、达成或放弃 Goal、删除、清空、合并、批量改期和 recurrence 变更，始终先展示对象和影响范围，再取得确认。

## Check-in 与重新规划

Check-in 以 Obsidian 主文档和新证据为起点，不重新讲一遍完整计划：

1. 按 Goal ID 读取主文档；
2. 通过 EventKit 读取相关 Reminder 完成信号和 Calendar 安排，识别缺失、重复、漂移或冲突；
3. 询问或核实新的结果、阻塞、容量和用户反馈；
4. 比较实际行动、最新基线、可用容量和预期轨迹；
5. 分别判断 Goal 状态和执行轨迹；
6. 对每个行动及其投影选择继续、拆小、改期、替换、完成、退役或取消；特别检查已完成 Reminder 是否仍留有未来 work-block；
7. 选出下一阶段最重要的一至三个行动和下一次 check-in；
8. 展示 Obsidian、Reminders 与 Calendar 的变更 diff，获得必要确认后先写 check-in 和主文档，再更新并回读执行投影。

同一天多次 check-in 追加到同一日期文件，不覆盖较早记录。普通 Reminder 完成状态可以作为行动事实回写，但不能自动把 Goal 改为 `achieved`。Calendar 手工移期或删除是需要对账的新信息，不得机械覆盖。

bundled bridge 当前不创建或修改 recurrence。完成 recurring Reminder 会推进到下一未完成实例，不能按普通 item ID 解释；Calendar series 也会产生多个 occurrence 和不同修改范围。因此重复行动、时间块与 check-in 都在每个 7–14 天滚动窗口内物化为独立 Reminder 或单次 event。若已 managed 的对象被用户改成 recurring，标为 `conflict` 并停止自动 patch、complete 或 delete。

出现以下情况时重新做 Context Grounding，并按需重新过 gate：

- 获得显著改变差距判断的新测评或结果；
- 外部规则、资格或日期发生变化；
- 用户修改目标值、成功标准、核心期限或优先级；
- 时间容量或关键约束明显变化；
- 连续执行证伪了原先关于方法、差距或可行性的关键假设。

仅改变近期行动、顺序或方法属于计划调整。改变目标结果、目标值、成功标准、核心期限或主要取舍属于 Goal Contract 修订，必须明确展示差异、重新确认并递增 contract version；不要静默移动终点。

不要静默把未完成 Reminder 每天顺延，也不要用责备、连续天数或任务数量制造压力。漏做一次是调整计划的证据，不是人格判断。

## 状态、轨迹与进展

正式 Goal 的 `status` 只允许：

```text
active | paused | achieved | abandoned
```

状态与执行轨迹是两个独立维度。轨迹可以是 `unknown | on_track | at_risk | off_track | blocked`；Goal 可以同时处于 `active` 和 `at_risk`。

只有目标具有稳定分母或明确权重时才计算数值进展，例如“已完成 6/10 套模拟题”。不要把不等价的 Reminder 简单平均，不把投入时间、Calendar 时间块或已经过去的 deadline 当作成果。

只有成功证据真实满足并写回 Obsidian 后，状态才能变为 `achieved`。用户决定结束但未达成时使用 `abandoned`；暂时停止但仍可能恢复时使用 `paused`。状态改变不移动或删除 Goal 目录，也不默认删除、完成或取消历史 Reminders / Events；外部处理方式必须单独预览和确认。

## 默认输出

### 目标尚未就绪

```markdown
Goal Readiness：
Goal Draft：
已有事实与证据：
关键缺口：
Stage 0 下一步：
返回检查点：
```

### Goal Contract 与落地预览

```markdown
Goal Readiness：READY_FOR_CONFIRMATION / GOAL_READY
SMART Goal：
为什么重要：
成功证据与目标值：
当前基线、差距与可行性：
目标日期与 check-in：
容量、约束与假设：
阶段里程碑：
接下来 7–14 天：
拟写入 Obsidian：
EventKit 权限与 iCloud 容器：
拟投影到 Apple Reminders：
拟投影到 Apple Calendar：
iCloud 设备传播验证范围：
需要确认：
```

### Check-in 摘要

```markdown
Goal ID：
证据变化：
状态与执行轨迹：
主要阻塞：
Goal Contract 是否仍有效：
下一步 1–3 项：
Obsidian / Reminders / Calendar diff：
本机 EventKit 验证与 iCloud 可见性：
需要用户决定：
```

根据任务复杂度删去无用字段，不为填满模板而编造内容。若某项工具不可用，在写入部分明确标记“尚未投影”，不要虚构结果。

## 降级与失败处理

- 本机 vault 无法唯一定位、不是有效 Obsidian vault 或不可写：只输出草稿，不分配 Goal ID，也不声称正式激活。
- 非 macOS、bundled EventKit bridge 缺失、构建失败或 schema 不兼容：确认后的 Goal 仍可正式写入 Obsidian，将 Apple 投影标为 `pending` 并输出可复制清单；不临时改用 AppleScript 或 UI 点击。
- Calendar 或 Reminders 没有 `fullAccess`、权限被拒绝或受限：停止相应读取和写入，不循环触发权限框；保留已验证的 Obsidian Goal并说明用户可手工处理的授权路径。
- iCloud source、目标 list/Calendar、可写状态或时区不明确：停止相应投影；绝不回退 `Default`、local 或其他账号 source。
- Calendar 不可读时，明确容量冲突尚未核实；Reminders 不可读时，行动完成状态尚未核实。
- EventKit 一侧成功、另一侧失败：保留已回读对象，总体标为 `partial`；下次只处理未验证项。
- 写入部分成功或响应不确定：先按稳定 projection marker 读取和对账，不盲目重放 create，也不自动回滚已验证对象。
- 本机 EventKit 回读成功但 iCloud 离线、延迟或 iPhone 尚未显示：保持 `verified_local`，如实说明设备传播未知；既不重放 create，也不声称已送达。
- iPhone 未安装 Obsidian 不影响闭环；不要求、不检查或安装移动端 Obsidian。

## 使用示例

### 应触发，但先进入 Stage 0

```text
使用 $goal-planner 帮我制定 12 月通过英语四级的计划。我每周能投入 4 小时，确认后写入 Obsidian，并把近期行动和时间安排投影到 Apple Reminders 与 Calendar。
```

预期行为：不自行把“通过”解释成某个分数；核实适用于本次目标的官方规则、日期和校内要求；让用户确认个人目标值；取得带日期、可与目标比较的分项基线。缺少关键条件时只生成 Stage 0。Gate 通过且用户确认后，分配 Goal ID，写入稳定 Obsidian 路径，再通过明确的 iCloud source 和专用容器投影近期行动与已确认时间安排并回读验证。

### 不应触发完整流程

```text
周三下午三点提醒我交社团报名表。
```

这是单条提醒或日程请求。直接路由到已安装的 standalone scheduling skill，没有时由 Codex 按普通写入确认规则处理；不建立 Goal，也不写入 goal-planner metadata。

## 完成标准

目标尚未就绪时，只有以下条件满足才结束当轮：

- Gate 状态、已有证据和关键缺口明确；
- Stage 0 只包含必要的调查、诊断或决策动作；
- 已说明由谁补充信息，以及何时返回本 skill 重新检查；
- 没有分配 Goal ID、创建 Goal 文件或投影 Reminders / Calendar。

Goal Contract 等待确认时，只有以下条件满足才结束当轮：

- Gate 状态为 `READY_FOR_CONFIRMATION`；
- Goal Contract 和暂定计划预览清楚区分事实、用户选择与假设；
- 需要用户确认的目标值、主要取舍和写入范围已经明确；
- 尚未把目标激活或写入工具链。

目标已经确认或激活时，只有以下条件满足才结束当轮：

- Goal Contract 具备可验证的成功证据、可比较基线和现实日期边界；
- Gate 状态为 `GOAL_READY`，用户已确认目标值、主要取舍和 Goal Contract；
- 计划至少有一个真正可执行的下一步，且工作量未明显超过可用容量；
- 假设、风险、check-in 和 replan triggers 已明确；
- 正式 Goal 已按永久 ID 写入 Obsidian，主文档与索引均已回读验证，且本地记录状态为 `verified`；
- 已请求且可用的 Reminders / Calendar 投影都已按 projection marker 和 EventKit locator 回读，未完成项被明确记录为 `pending`、`partial` 或 `conflict`；
- `projected` 或 `verified_local` 只被表述为本机 EventKit 验证，没有被夸大为 iCloud 或 iPhone 送达；
- 三个载体的数据职责没有混淆，无法投影时没有虚构外部结果。