What’s new in Shortcuts
AI & Machine Learning 进阶 11m

快捷指令的新功能

What’s new in Shortcuts

2026年6月10日

在 Apple 官方观看视频

一句话判断

快捷指令终于有了原生持久化存储（Storage）和基于通知内容的自动化触发器，它正式从“一次性执行的脚本工具”进化成了“带状态记忆的后台自动化引擎”。

这场 Session 讲了什么

以前大家吐槽快捷指令，多半是因为它“没记忆”且“触发条件太死板”。每次运行都是无状态的，想做个带上下文的 AI 助手或者复杂的条件自动化，只能靠各种 hack 手段（比如读写剪贴板或依赖第三方 App）。iOS 26 直接给出了官方解法：新增 Storage 动作支持 iCloud 跨设备同步，同时加入了通知（Notification）、截图和键盘连接三种全新的自动化触发器。

这对做效率工具、智能家居或者内容类 App 的开发者影响最大。你现在可以把 App 里的数据（App Entity）喂给“使用模型”（Use Model）动作，并利用 Storage 给大模型加上“长期记忆”，让它不再每天给你推荐同一碗汤。同时，精细化的通知自动化让你的 App 推送不仅能触达用户，还能直接触发用户的后台工作流。

值得深挖的点

Storage 给 LLM 注入“长期记忆”

Apple 在快捷指令里原生支持 Storage（包含 Get、Set 和全局存储），最直接的目的是解决“使用模型”（Use Model）动作的无状态痛点。大语言模型默认是确定性的，如果你让它“每天推荐一个冷知识”或“每天选一碗汤”，它大概率会重复输出。有了 Storage，你可以把历史输出存起来，下次运行作为 Prompt 传给模型，让它避开旧答案。

这里的设计取舍很明显：Apple 没有给快捷指令搞一套复杂的本地数据库，而是提供了简单的 Key-Value 存储，并默认通过 iCloud 同步。这极大地降低了用户的管理成本，但给开发者挖了个坑——跨设备的数据一致性。如果你在 iPhone 上存了一个 App Entity，在 iPad 上读取时，你的 App Intent 必须能正确解析它。这就要求你的 Entity ID 必须是全局稳定的（比如后端数据库的行 ID），绝不能依赖设备本地的 UUID 或内存地址。

通知自动化：让推送成为工作流的起点

新增的通知（Notification）自动化允许用户基于特定 App 的推送内容（支持关键字过滤）来触发快捷指令。这是一个极其聪明的系统级集成。以前推送只是信息的终点，用户看完就划掉；现在推送可以变成自动化的起点。

比如外卖 App 推送“骑手正在靠近”，用户可以直接配置自动化打开玄关灯。要让这个功能好用，开发者必须优化推送文案。如果你的推送全是“您有一条新消息”这种废话，用户根本没法设置关键字过滤。这倒逼开发者遵循 Human Interface Guidelines，在推送里提供具体的主语、动词和可操作的数据（比如“骑手 John 还有 5 分钟到达”）。这比单纯教你怎么写代码更有业务价值。

代码片段

1. 为 LLM 优化 App Entity 属性

场景：让“使用模型”动作能根据配料表准确判断汤的辣度，而不是瞎猜。

import AppIntents

struct SoupEntity: AppEntity, Identifiable {
    static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Soup")
    static var defaultQuery = SoupEntityQuery()
    
    // 使用后端数据库的稳定 ID，确保 iCloud 跨设备同步时能被正确识别
    var id: String 
    
    @Property var name: String
    @Property(title: "Available Today") var isAvailableToday: Bool
    
    // 新增配料属性，让 LLM 能看到具体成分从而判断辣度
    @Property(title: "Ingredients") var ingredients: String 
    
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)")
    }
}

坑：如果你只暴露 name，LLM 只能靠名字瞎猜；暴露太多无关属性又会浪费 Token。用 Show Content 动作查看 Transcript 属性来调试 LLM 到底看到了什么。

2. 调试 LLM 看到的实体数据

场景：在快捷指令中排查为什么“使用模型”动作输出了不符合预期的结果。

// 在快捷指令编辑器中，在“使用模型”动作后添加“显示内容”(Show Content) 动作
// 并将输入设置为“使用模型”的 Transcript (转录) 属性

// 伪代码表示快捷指令的执行流：
let modelResult = try await UseModelAction.run(prompt: "选一个辣汤", context: soupEntities)

// 调试环节：
let transcript = modelResult.transcript 
print(transcript) // 查看 LLM 实际接收到的 SoupEntity 结构化 JSON 数据

坑：Transcript 里显示的是 App Entity 暴露给系统的结构化表示，如果你的 @Property 没加 title 或者类型太复杂，LLM 可能会解析失败。

最佳实践

已有项目如果已经接入了 App Intents，现在的当务之急是审查你的 Entity ID 生成策略。把那些依赖本地 Core Data objectID 或内存指针的 ID 全部替换为后端下发的稳定标识符（如 UUID 字符串或自增主键）。这是迎接 Storage 跨设备同步的前提。

新项目在设计推送通知时，直接把“支持快捷指令自动化”作为需求写进 PRD。推送文案必须包含明确的实体名称和状态动词，方便用户在通知自动化里配置关键字过滤。

另外，给“使用模型”动作加记忆时，记得在 Storage 里存精简后的文本摘要，而不是把整个 App Entity 塞进去，避免 Prompt 超长导致模型截断或响应变慢。

还有什么值得关注

  • 截图与键盘自动化：新增截图保存和蓝牙键盘连接/断开作为触发器，对做外设管理和屏幕监控类 App 的开发者是大利好。
  • Use Model 支持 Web 检索：Apple Intelligence 模型现在可以在快捷指令里直接联网查最新信息，不用再绕道 Safari 或第三方 API 了。
  • 自动化入口扁平化：自动化配置直接移到了快捷指令编辑器的主界面，和动作列表平级，大大降低了普通用户的发现成本。
Shortcuts App Intents Apple Intelligence Automations