Highlight
iOS 14 和 macOS Big Sur 扩展了 Siri Event Suggestions，让 App、Safari 和 Mail 能用 Intents 捐赠或 schema.org markup 把预订写入 Calendar，并通过 Maps、Lock Screen、Simulator 和 Console 改善到达与调试流程。
核心内容
餐厅、航班、酒店或票务 App 做完预订后，用户的任务还没有结束。确认页只是第一步。之后还有出发提醒、路线、航班 check-in、到店前的时间判断，以及临时修改或取消。以前这些信息如果只留在 App 或邮件里，Calendar、Maps 和 Lock Screen 就很难在正确时刻帮用户继续这件事。
Siri Event Suggestions 处理的就是这个断点。Session 一开场先定义能力边界：用户像往常一样在 App 里完成预订，系统把预订加入 Calendar，并用设备端智能在 Lock Screen 提醒出发、在 Maps 里给出路线建议，或在航班前提示 check-in（00:42）。
2020 年的变化有两层。第一层是 App 端扩展：bus 和 boat reservation 加入支持，macOS Big Sur 与 Mac Catalyst App 也能通过 Intents 框架捐赠预订；如果 iOS 和 macOS App 捐赠的数据一致，系统会用端到端加密在设备间同步预订（02:28）。
第二层是 Web 和邮件。用户可能在网站下单，在 App 里修改，再从邮件里查看确认信息。iOS 14 和 macOS Big Sur 允许网站与邮件用 schema.org markup 表达同一份预订，Safari 和 Mail 负责把它捐赠给系统（04:12）。这让没有打开 App 的用户也能获得 Calendar、Maps 和 Siri Suggestions 的同一条体验链。
详细内容
用 schema.org 标记网站和邮件里的预订
（05:34）Web 和邮件集成使用 schema.org。Apple 明确支持 JSON-LD 和 Microdata。下面是官方 snippet 里的 Microdata 版本，它把一封餐厅确认邮件中的状态、确认号、人数、餐厅、时间、电话和地址结构化出来。
<div itemscope itemtype="FoodEstablishmentReservation">
<link itemprop="reservationStatus" href="http://schema.org/ReservationConfirmed"/>
<meta itemprop="reservationId" content="IWDSCA"/>
<meta itemprop="partySize" content="2"/>
<div itemprop="reservationFor" itemscope itemtype="FoodEstablishment">
<meta itemprop="name" content="EPIC Steak"/>
<meta itemprop="startDate" content="2020-06-26T19:30:00-07:00"/>
<meta itemprop="telephone" content="(415)369-9955"/>
<div itemprop="address" itemscope itemtype="PostalAddress">
<meta itemprop="streetAddress" content="369 The Embarcadero"/>
<meta itemprop="addressLocality" content="San Francisco"/>
<meta itemprop="addressRegion" content="CA"/>
<meta itemprop="postalCode" content="95105"/>
<meta itemprop="addressCountry" content="USA"/>
</div>
</div>
</div>关键点：
reservationStatus决定系统是否把它当成已确认、已修改或已取消的预订处理。reservationId是后续更新同一条 Calendar 事件的关键字段。startDate带有本地时区，避免用户跨城市或跨时区时出现错误提醒。address给 Maps 和出发提醒提供地点基础；session 明确说地址越完整，用户体验越好。
修改和取消都要保留同一个 reservationId
（06:49）用户改时间或取消预订时，markup 要反映最新状态。Apple 的例子里，修改餐厅预订时保留 IWDSCA，只把时间从 7:30 PM 改到 6:30 PM；取消时把状态改成 ReservationCancelled。Siri 依靠同一个 reservationId 找到原来的 Calendar 事件并更新。
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "FoodEstablishmentReservation",
"reservationStatus": "http://schema.org/ReservationCancelled",
"reservationId": "IWDSCA",
"partySize": "2",
"reservationFor": {
"@type": "FoodEstablishment",
"name": "EPIC Steak",
"startDate": "2020-06-26T19:30:00-07:00",
"telephone": "(415)369-9955"
"address": {
"@type": "http://schema.org/PostalAddress",
"streetAddress": "369 The Embarcadero",
"addressLocality": "San Francisco"
"addressRegion": "CA",
"postalCode": "95105",
"addressCountry": "USA"
}
}
}
</script>关键点：
reservationStatus从 confirmed 变成 cancelled 后，系统会取消对应的 Calendar 事件。reservationId不能因为状态变化而变化；变了就会被系统当成另一条预订。startDate、餐厅名和地址仍然保留，帮助系统定位要处理的同一件事。- 这段来自官方 snippet，字段结构按 session 展示保留。
本地调试要关闭域名和 HTTPS 限制
（07:38）正式上线前，网站域名需要向 Apple 注册，站点要使用 HTTPS，邮件要有有效 DKIM signature。开发阶段可以临时放开限制。macOS 上用两个 defaults 命令，iOS 上在 Developer Settings 中打开对应开关。
defaults write com.apple.suggestions SuggestionsAllowAnyDomainForMarkup -bool true关键点：
- 这个开关用于允许未注册域名，适合本地或测试环境。
- 它不能替代正式注册；上线前仍要提交域名和 markup 示例。
defaults write com.apple.suggestions SuggestionsAllowUnverifiedSourceForMarkup -bool true关键点：
- 这个开关用于允许未验证来源，session 的 demo 用它处理本地没有 HTTPS 的环境。
- 关闭验证只适合开发机，不应进入生产流程。
给预订提供 URL，设备没有 App 时回到 Safari
（19:44）App 捐赠的 INReservation 在 iOS 14 新增 URL 属性。如果 Calendar 事件同步到一台没有安装 App 的设备上，系统会显示 “Show in Safari” 按钮，让用户打开你提供的网页继续管理预订。Web markup 的官方 snippet 也展示了同一思路。
<script type='application/ld+json'>
{
"@context": "http://schema.org",
"@type": "http://schema.org/FoodEstablishmentReservation",
"reservationId": "IWDSCA",
"reservationStatus": "http://schema.org/ReservationConfirmed",
"url": "http://localhost:3000/reservations/6",
"underName": {
"@type": "http://schema.org/Person",
"name": "John Appleseed"
},
"broker": {
"@type": "http://schema.org/Organization",
"name": "Apple Reservations"
},
"startTime": "2020-06-26T19:30:00-07:00",
"partySize": "2",
"reservationFor": {
"@type": "http://schema.org/FoodEstablishment",
"name": "EPIC Steak",
"telephone": "(415)369-9955",
"address": {
"@type": "http://schema.org/PostalAddress",
"streetAddress": "369 The Embarcadero",
"addressLocality": "San Francisco"
"addressRegion": "CA",
"postalCode": "95105",
"addressCountry": "USA"
}
}
}
</script>关键点：
url让 Calendar 事件能把用户带回具体预订页面。underName和broker补充了预订归属与服务提供方。startTime使用 ISO 8601，并包含预订地点所在时区。- 同一套预订信息可以从网页、邮件和 App 捐赠进入系统，字段一致性会影响更新效果。
App donation 要区分 reservation number、containerReference 和 itemReference
（13:43）App 端从自己的预订模型开始，把预订详情映射成 INReservation 对象，再放进 intent response 和 interaction 捐赠给 Siri。用户在 Calendar 中点击 “Show in App” 时，系统会构造 INGetReservationDetailsIntent，App 用 donation 里的 container 和 item reference 找回正确预订。
App reservation details
-> INReservation objects
-> intent response + intent
-> donated interaction
-> Calendar event
-> INGetReservationDetailsIntent when user taps "Show in App"关键点：
reservation number用来跨来源识别同一条预订，App、邮件和网站要保持一致。containerReference标识 App 内的一整份预订，可能包含多个部分。itemReference标识预订里的单个部分，例如往返火车票的某一段。- 多段行程不能复用同一个
itemReference，否则 App 被唤起时无法判断要展示哪一段。
捐赠时机和调试路径要覆盖真实变化
（20:22）Apple 建议在用户查看即将到来的预订列表、单个预订、预订的具体部分时捐赠，也要在 App 外部发生变化后更新系统数据。Background App Refresh 可以周期性检查更新，silent push 可以在变化发生时刷新并重新捐赠。
Upcoming reservations list
Single reservation screen
Specific reservation part
Background App Refresh
Silent push notification关键点：
- 系统只会在第一次捐赠某条预订时通知用户，短时间内多次捐赠会被智能分组。
- App 外部发生修改或取消时，也要重新捐赠，避免 Calendar 里留下旧数据。
- iOS 14 支持在 Simulator 中测试 Siri Event Suggestions API。
（22:06）调试时看 Console.app，按 category 过滤 siri-event-suggestions。session 的 demo 展示了两个常见错误：两个 bus reservation part 复用了同一个 itemReference；新的 Simulator 还没有确认 Calendar 的 What’s New 屏幕。Web markup 也能用同一类日志定位，例如预订结束时间已经过去。
Console.app
-> select device or Mac
-> search category: siri-event-suggestions
-> start streaming
-> trigger app donation or reload Safari page关键点：
- donation 和 markup 都可能异步处理，App 不能总是在本进程拿到明确错误。
- category 过滤能把系统日志收敛到 Siri Event Suggestions 相关消息。
- 日志会指出具体字段问题，例如重复
itemReference或已过期的结束时间。
核心启发
1. 给预订系统加一条 Calendar 出口
做什么：餐厅、活动、酒店、航班或票务 App 在确认成功后，把预订捐赠给 Siri Event Suggestions，让 Calendar 自动出现事件。
为什么值得做：session 说明用户完成预订后，系统能继续提供出发提醒、路线和 check-in 建议，价值发生在 App 之外。
怎么开始：先把内部订单模型整理成统一的 reservation number、时间、地点、状态和管理 URL；App 端走 INReservation donation，Web 和邮件端走 schema.org markup。
2. 让邮件确认信成为系统入口
做什么：在确认邮件 HTML 中加入 JSON-LD 或 Microdata，让 Mail 能在后台识别预订并加入 Calendar。
为什么值得做：用户经常从邮件查确认信息。Mail 支持 markup 后，不需要用户打开 App，也能得到 Calendar banner 和取消提示。
怎么开始：先从餐厅或活动确认信做起，保证 reservationStatus、reservationId、时间、地点和地址完整；测试通过后再注册域名并检查 DKIM。
3. 为多段行程建立 reference 规则
做什么：给往返车票、多航段机票、旅行套餐这类多部分预订设计 containerReference 和 itemReference 命名规则。
为什么值得做：session 的火车和旅行套餐例子说明，系统可能只要求 App 打开某一段预订；重复 item reference 会让跳转失败。
怎么开始：用整份订单号做 container；用票号、航班号组合或服务器生成的部分 ID 做 item；把 spokenPhrase 写成人能读懂的描述。
4. 给 Calendar 事件补上网页 fallback
做什么：每条预订都提供一个可打开的管理 URL，让没有安装 App 的设备也能从 Calendar 进入网页。
为什么值得做：Calendar 事件会跨设备同步，用户并不一定在每台设备上安装同一个 App。
怎么开始：把确认页做成稳定 URL，支持查看、修改和取消；App donation 的 INReservation 和网页 markup 都使用同一个页面地址。
5. 建一套 Siri Event Suggestions 调试清单
做什么：把 Simulator、Console category 过滤、markup defaults、Calendar 首次使用确认和过期时间检查写进 QA 流程。
为什么值得做：session 展示的失败集中在字段重复、Calendar 未初始化、预订已过期这类容易遗漏的细节。
怎么开始：每次测试前打开 Console.app，过滤 siri-event-suggestions；App donation 先测 Simulator，Web markup 先用 defaults 放开本地域名和未验证来源。
关联 Session
- What’s new in SiriKit and Shortcuts — 先看 iOS 14 中 SiriKit、Shortcuts、紧凑 Siri UI 和系统动作入口的全局变化。
- Empower your intents — 深入学习 intent 处理、app 内 Intent handling、性能预算和富会话体验。
- Decipher and deal with common Siri errors — 补上 Siri 与 Shortcuts 调试中的进程、日志、completion handler 和设备日志检查。
- Design for intelligence: Make friends with “The System” — 从 intents、donations 和 extensibility 理解系统智能如何学习并执行 App 能力。
- Design for intelligence: Discover new opportunities — 解释 Calendar、Maps、Lock Screen、Search 等系统入口如何提高 App 能力的可见性。
评论
GitHub Issues · utterances