Siri 可以调用你的应用，最先该开放哪个功能？

包裹晚了。客户想知道下班离开办公室前能不能收到，却要先登录、打开订单列表，再进物流页面才能找到答案。只要应用为助手提供明确的配送查询方式，一句自然语言请求就能省去这些步骤。

11 月 3 日，Apple 在包括 iOS 27.3 在内的测试版软件中开放了面向 App Intents 的 Siri AI 开发者预览。开发者可以让应用接收可能借助个人上下文、屏幕信息和相关操作的请求。Apple 计划随后向用户提供这项集成，预计在春季开放 App Store 提交。开发者可以趁用户尚未依赖这项功能，先明确每个操作该如何表现。

2014 年的 Siri，由 Kārlis Dambrāns 拍摄。已裁剪并调整大小，CC BY 2.0。图片来源 · 许可证。

先交给助手一个结果容易识别的任务

App Intent 查询流程。Telli.sh 原创示意图。

App Intent 表示应用已经准备好执行的一项操作。以一个能查询配送状态的应用为例，输入可以是应用能识别的配送实体，结果可以包含哪一票货、最新状态和更新时间。数据归应用管理，当前登录账号能查看什么，也由应用决定。

这样设计，简短的问答就可以解决问题。如果同一个账号有三个正在配送的包裹，助手就得获得足以区分它们的信息。运单号、简短的名称或用户认得的目的地，都能让选项更具体。“我的包裹”同时指向几个结果时，应该先问清楚。

前两项适合作为起点。它们一般无需发起交易，就能给出有用的回答。修改预约则有另一组约束：想要的时间可能没有空位，商家可能收费，时区转换也可能改变日期。这些情况应该反映在应用操作及其响应里。

让应用在真正执行时核实权限

App Intent 修改流程。Telli.sh 原创示意图。

助手能理解一句话并找到可能的操作。应用仍要核实是谁在请求、可以访问哪个对象，以及是否允许执行。把原有界面使用的检查带到这个操作入口。自然语言请求有时会在用户切换了账号、设备锁定或登录会话已经过期时到达。

如果操作会产生付款，应在最后展示金额和付款方。更换配送地址时，先让人看到目的地，再确认。如果后端无法判断请求是否成功，应返回用户可以查证和处理的状态，以免诱导重复提交。做过结算表单的人都熟悉这些原则。语音或聊天可能需要用少得多的空间表达同样清楚的信息。

例如，有人想再买一袋上次的咖啡。第一次可能用了临时折扣，配送地址也许已经变了，而商品本身还有几种规格。下单之前说清当前商品、规格、价格和地址，用户才容易核对。下单之后，也可以让凭证容易找到。

用户上下文有助于确定从哪里开始。应用实际用了哪些信息，仍应说清楚。屏幕只有一份订单时，用“你现在看到的订单”确认可能就够了。如果屏幕上有多项，复述具体选了哪一项。操作前给用户纠正理解偏差的机会。

串联多个操作时，要如实显示最后的状态

Apple 也介绍了把多项操作组合起来的技能，以及在 Spotlight 语义索引中支持实体。这两项能力结合起来，可以减少从请求到结果要打开的页面。不过，一步操作的输出可能是下一步的输入，小错误因而更容易影响整段流程。

例如，请求查找即将到来的预约并改时间。查询可能成功，修改却失败。此时把两种状态都告诉用户。说清“找到了预约，但仍是原来的时间”，就给出了有用的信息和明确的下一步。笼统地说成功会隐藏修改失败，笼统地报错又会遮住已经找到的预约。

实用的操作流程通常需要几种结果。第一步可以返回候选对象，下一步可以请求选择或确认，最后可以返回凭证或待处理状态。组合操作时，既要测试用户中途改变主意，也要测试网络请求超出对话中合理等待时间的情况。

内部使用稳定的记录标识符。自然语言名称会变，不同项目也会重名。稳定 ID 能让应用确认自己操作的是预期对象，同时仍向用户显示易懂的描述。保留原始记录的链接，需要查证上下文时，就能直接打开对应页面。

选一个能手动核对结果的操作试用预览

1. 查阅 Apple 的开发者公告，确认支持的测试版操作系统、设备和语言。使用测试账号和测试数据。Apple 将韩语列为支持语言，并说明了设备和地区限制。
2. 选择一个用户已经经常做的只读操作。写下正常的界面路径，以及操作成功时应给出的准确回答。
3. 参照 Apple 的 App Intents 文档，对操作和目标实体建模。分别决定匹配到零条、一条和多条记录时怎么处理。
4. 执行常规请求和含义不明确的请求。包含账号缺失、会话过期、名称重复、网络不可用等情形。逐一对照应用当前界面。
5. 以后加入修改操作时，记录用户在哪看到对象、条件和结果。增加一个测试，在超时后重复操作请求，查看应用能否正确处理。
6. 把面向客户的上线日期和开发者预览视为两个里程碑。计划通过 App Store 发布时，再查 Apple 最新的提交要求和政策。

此时也适合测试不同说法。配送应用可以从客户向客服实际使用的措辞开始。有的带日期，有的提店名，还有的用送达地点指代包裹。请求信息不足时，观察操作会怎样追问。一句有用的澄清，能让人离答案更近一步。

根据结果选择合适的呈现方式

Apple 区分 Spotlight 中的应用实体、应用专用操作、片段，以及组合多项操作的技能。配送应用可以选出最适合回答某个具体问题的方式。搜索中的实体便于用户识别订单，操作可以在当前账号下处理请求，卡片让结果一目了然。如果找到订单只是第一步，串联操作就有实际用途。

查询状态的卡片可以显示目的地所在城市、当前状态和承运商上次更新时间。呈现多少细节，要看卡片出现在哪里以及设备是否锁定。测试屏幕时，别假设用户已经听到口头说明。测试语音时，也别依靠屏幕才传达重要警告。同一份源数据在两种方式里都要表达清楚。

Apple 的预览指南也解释了助手如何选定应用。除下述情况外，应用处于后台时，自定义操作需要明确说出应用名称。前台应用、正在进行的 Live Activity、已经提过应用名称的对话，可以提供所需的上下文。先试一次明确点名，确认操作本身可用。然后在主屏幕、显示另一应用时和持续进行的对话中，发出同样的请求。记下不同上下文各自得到的结果。

单独验证分发渠道

预览指南介绍了在设备上测试带开发签名的构建版本，以及通过内部 TestFlight 进行测试。指南指出，外部 TestFlight 和通过 App Store 分发的构建版本无法使用这些预览集成进行测试。当产品负责人想做面向客户的试点时，这一区别很重要。开发版演示成功，并不能证明客户可以在商店版本里打开同一项功能。

Apple 列出支持 Apple Intelligence 的兼容硬件和包括韩语在内的六种语言，同时还有地区、年龄和服务器侧限制。Siri AI 的列表包括 iOS、iPadOS、macOS、watchOS 和 visionOS 的 27.3 测试版，首轮第三方开发者预览则列出 iOS、iPadOS、macOS 和 visionOS。安排测试人员时，把两个范围分开。明确标注范围的测试报告可以帮助接手的工程师判断，问题出在操作、测试渠道还是设备上。

内部测试可按请求、设备、语言、分发渠道、结果逐行记录，先填一条已经确认成功的记录。比如用韩语查询配送状态，把简短口语和带零售商名称或物流日期的请求进行比较。两句都找到同一条记录，就说明流程能处理有意义的表达差异。如果其中一句暴露了别人的订单，就停下测试，修正权限校验本身。

最后验收时，试试交由用户继续处理的常见路径。如果能找到预约却无法修改，就显示可选时间并打开正确页面。如果能完成修改，就显示已经完成的结果，并让用户之后能在应用里找到凭证。两种情况下，应用都给出具体的下一步。

快捷操作靠一次次明确的结果赢得信任

Siri AI 集成的吸引力在于，可以让应用最有用的功能离需要它的人更近。一项范围小、结果可验证的操作，就能带来实际价值，无需先搭出一长串集成。如果一家企业能准确显示配送状态，就有了合适的起点。

增加操作时，每一项都按同样的标准检查。用户应当知道应用找到了什么、为哪项动作申请了许可，以及随后发生了什么。请求跨越多个服务，或者用户始终没有打开原应用窗口时，这种清晰度尤其重要。

来源

• Apple Developer 11 月 3 日的 Siri AI 预览公告
• Apple App Intents 文档
• Apple 开发者预览设置和测试指南
• Apple Spotlight 与 App Intents 文档

---

如果想把工作背后的对话和决定留成可搜索的记录，可以创建 Telli.sh 账号。