Siri AI 開放開發者：App Intents 與 skills，離可靠跨 App 工作還多遠？（2026）

2026 年 11 月 3 日，Apple 在 Apple Developer 發布了〈Siri AI is now open to all developers〉，宣布 Siri AI 開放開發者整合自家 App。這次的關鍵，是讓開發者把自訂內容、動作與多步驟指引交給 Siri；開放對象擴大了，交付給一般使用者的時間仍在後面。

先說判斷：這是值得投入小規模整合的開發預覽，還不足以把「一句話完成整段工作」當成產品保證。下面先看公告真正放開了什麼，再核對技術文件中的邊界，最後討論開發團隊該先驗哪一件事。

一、Siri AI 開放開發者：放開的是自訂能力的入口

公告把起點放在 iOS、iPadOS、macOS、visionOS 的 27.3 beta。App 可透過 App Intents 提供自訂動作與內容，並用 skills 補上複雜任務的指引；Spotlight 語意索引的實體存取也擴大。Apple 同時列出多款自家 App 作為可參考的動作範例。這些是 Apple 對預覽能力的說明，不是跨 App 成功率的量測。

要理解這個改變，可以把 App 想成一間有櫃檯的店：畫面是人看得到的商品陳列，App Intents 則是店家列出的「可以替你辦哪些事、需要哪些資料」。Siri 接到自然語言需求後，還需要找到對的櫃檯、填對欄位，並把結果帶回來。

App Intents 框架文件說明，開發者以結構化方式描述動作與資料，供 Siri、Spotlight、Shortcuts 等系統功能使用。因此，這次不是從零開始發明 App 動作介面；新增的重心在於 Siri AI 對自訂工具、內容與任務指引的整合。想先分清模型與執行層，可搭配 Agent Harness 的分工 理解。

二、不是讓助理任意接管 App：動作必須明確公開

Siri can only find custom content and perform custom actions an app makes explicitly available using App Intents.

中文：Siri 只能尋找及執行 App 透過 App Intents 明確公開的自訂內容與動作。

Apple，Siri AI Developer Preview

預覽文件同時說明，採用這條整合路徑不必新增 entitlement，也不必加入另一個開發者計畫。Apple 舉的跨 App 例子是：找出購物 App 裡收藏的球鞋，解析聯絡人，再把商品資訊傳到指定通訊 App；這是官方說明情境，並非本文實測結果。

這段限制很有價值。它把「模型理解了使用者的話」和「App 願意提供什麼能力」分成兩件事。開發者不是把整個介面交給助理隨意探索，而是先決定哪些業務功能能成為工具、哪些資料能成為實體。

自訂動作整合文件進一步說明：可用 @AppIntent(.tool) 把適合的 intent 標為 Siri 工具，並補上動作、參數與資料的描述。已透過支援 Siri 的 schema 公開的動作有既有路徑，不應不分情況重加標註。這裡展示的是介面設計方向，本文不把它擴寫成可以直接套用到所有 App 的完整程式。

前景與背景也有差別。預覽文件列出的情境包括：App 在前景、有活動中的 Live Activity，或 Siri 對話已提及該 App 時，使用者可省略 App 名稱；背景情境則可透過明確說出 App 名稱來請求內容或動作。這意味著「幫我改一下」是否足夠，還取決於系統握有哪些上下文。

跨 App 傳遞資料同樣需要接合。Apple 要求自訂實體提供可供其他 App 處理的 transferable representation；螢幕上的物件也要與實體建立關聯，才能給系統上下文。看得懂一句話、找得到資料、把資料送到下一個動作，是三個要分別完成的工程工作。

三、skills 是任務說明，不能當成保證照順序跑的腳本

Apple 的 app skills 文件把它描述為補充指引：多個工具如何一起完成任務、相似工具應優先選哪個、應避免什麼，以及 App 領域內的知識。它以 Markdown 文件隨 App bundle 編譯，讓 Siri 在複雜請求需要時讀取。

You can’t use app skills to enforce deterministic behavior.

中文：你不能靠 app skills 強制得到確定性的行為。

Apple，Orchestrating complex actions with app skills

文件還明說，Siri 不會只是依 skills 列出的順序逐項執行工具。這個差別決定你該把責任放在哪裡：自然語言適合解釋任務，但一筆訂單能否重複送出、價格是否仍有效、帳號是否獲授權，應由實際執行交易的程式檢查。

想像一個購物 App：skills 可以告訴 Siri 先找商品、再選規格、整理購物車，最後詢問使用者是否購買。但若某一步重試，後端仍須能辨認「這是不是同一筆提交」，而不是因為模型再次呼叫就再收一次款。這是本文提出的工程驗收情境，並非聲稱 Siri 已出現該種重複購買事故。

格式相似也不等於可直接搬用整套代理工具包。Apple 說 app skills 採用 Agent Skills 格式的子集，支援名稱、描述與 Markdown 內文；其他 frontmatter 欄位，以及 scripts、references 等支援檔案不在其支援範圍。能讀一份任務指引，和能執行同名技能套件，是不同能力。

四、Siri AI 開放開發者的時間表，要分成兩條線

一條線是使用者正在接觸的 Siri AI beta；另一條線，是這次放給各 App 開發者的新自訂整合預覽。兩者都叫 beta，並不代表每個新 API 的能力已能隨 App Store 版本交付。先前的 Siri AI beta 與 Mac 終端機模型工具解析 談的是前一階段的產品與模型入口；本篇聚焦新一輪 App 整合契約。

before first shipping to customers in a few months

中文：在幾個月後首次交付給顧客之前。

Apple Developer，2026 年 11 月 3 日公告

Apple 把顧客交付放在數月後，App Store 提交則指向春季。這是當時的規劃時間窗，不是精確上市日。技術文件把今日可測範圍寫得更清楚：開發者可用開發簽署版本在支援裝置上執行，也可交給 TestFlight 內部測試者；這項預覽能力不提供給 TestFlight 外部測試或 App Store 發布版本。

語言、硬體與地區要另看。依 Apple 11 月 2 日的支援文件，Siri AI 需相容裝置與受支援的語言設定，目前列英文、法文、日文、韓文、葡萄牙文、西班牙文。11 月 3 日公告把繁體中文列在即將擴增的語言，因此不宜把繁中當成本次已可交付的測試條件。

同一份支援文件也區分地區：歐盟的 iOS、iPadOS、watchOS 尚不可用，macOS 與 visionOS 有其適用條件；Apple Account 地區為中國大陸時，Siri AI 目前無法運作。讀者要判斷自己的可用性，應先對上裝置、語言和帳號地區，而非只看系統版本號。

Apple 也明列未滿 13 歲不適用；依賴伺服器模型的部分功能有每日用量限制，會因功能、請求複雜度與系統需求等因素變動。公告提到未來將提供付費擴大存取；這仍是未來安排，本文不據此推算價格。團隊做規劃時，應把存取資格與可用量分開確認。

五、AlphaLab 的判讀：整合的價值，取決於可驗收的動作

1. 最值得肯定的是能力契約更明確

我同意這條方向：讓 App 自己描述動作與資料，能把模糊需求接到可檢查的程式介面。相較於只靠一段聊天回覆，開發團隊有機會核對究竟叫了哪個工具、帶了哪些參數、結果是否改變。但好處要透過整合品質兌現；寫下描述只是起點。

2. 描述與權限應分別設計

自訂整合文件指出，敏感實體或屬性可設驗證政策，部分屬性可設為 internal；若 intent 的結果本身帶出敏感資料，還要在 intent 層設定驗證要求。這些具體機制，比一句「助理會保護資料」更值得檢查。它們也不代表所有 App 的預設值都已符合你的業務需求。

我的建議是先逐欄問：助理需要知道這個值嗎？顯示之前是否應重新驗證？執行之後能否查回真實狀態？這與 外掛整合的同意邊界 是相鄰問題：方便的入口仍要能說清楚，誰授權了哪個動作。

3. 測試要看工具軌跡，也要看實際結果

Siri Evaluations 文件提供一個務實訊號：測試可寫出多輪請求，核對 intents、參數、找到的 entities 與回覆，並留下執行報告。文件也建議換措辭、加入不完整或意外的請求，而且重跑，因為回覆可能變動。確定性的檢查器，不表示被檢查的助理每次走相同路徑。

評估一段工作，至少留兩份答案：工具有沒有被正確呼叫，業務狀態最後有沒有正確改變。再加入拒絕授權、缺少必要資料、網路中斷與重試。AI Evals 的驗收方法 可幫你把「看起來會做」轉成可重複比較的考題。

4. 平台入口有潛力，成功率與分配規則仍是不同問題

如果使用者能直接向 Siri 提需求，App 可能在不先打開首頁的情況下提供服務；這是我對介面轉變的推論，不是已量出的流量成長。團隊還要觀察自己的工具何時被選中、資料是否準確、使用者是否能辨認與撤回操作。

Apple 在公告中表示，Siri AI 體驗的條款與使用政策細節還會後續說明。因此，今天適合探索技術與收集失敗案例；把特定分發、收費或商業回報寫進產品承諾，則需要另一組正式條款與實際採用證據。

我同意的是：自訂工具加上任務指引，讓更多 App 能參與自然語言工作流。我存疑的是：把「可以串接」直接推成「複雜工作已可靠完成」，或把開發者資格放寬直接當成終端使用者全面可用。本篇依公告與公開技術文件分析，未執行 Siri AI 預覽 App 的裝置實測，因此沒有替它填入成功率。

六、下一步：先挑一個可逆、做完查得到的任務

開發團隊可以先挑「讀取一筆假資料，再更新一個可回復欄位」的小任務。寫清楚工具與資料描述，定義缺參數時要問什麼；用直接、含糊、否定與更正四種說法測同一件事，再核對實際儲存結果。這是建議的試驗設計，尚未執行的欄位保持空白。

把重複呼叫、取消與重試也排進驗收，再逐步擴成 skills。若你正在搭自己的執行層，最小 Agent Harness 實作 能補上狀態、停止與重試的基本觀念。一般使用者則可先記錄自己真正希望省掉的跨 App 步驟，等支援語言及正式 App 整合到位，再以同一任務比較是否真的省事。