iOS 27 AI App 怎麼開發？從 Foundation Models 到 App Intents 的實際開發流程

先對齊：iOS 27 AI App 到底在做什麼

很多團隊把「AI App」理解成：加一個輸入框，把使用者句子轉發到 OpenAI / Gemini，再把回覆貼回介面。這條路在 iOS 27 仍然能走，但已經不是蘋果希望你交付的形態。WWDC 2026 的開發者敘事很明確：系統模型、Siri AI 與第三方模型，都應該透過 Foundation Models 的統一工作階段進入 App；使用者在鎖定畫面、Siri、螢幕內容上發起的動作，則必須經過 App Intents，而不是再維護一套 SiriKit。

用產品語言說：Foundation Models 負責「想清楚」——把自然語言變成結構化草稿、呼叫你的 Tool、在本機與雲端模型之間切換。App Intents 負責「做出來」——建立任務、開啟實體、改一筆紀錄，並讓 Siri AI 能指著螢幕說「第三個」。兩條線缺一不可。只做聊天，Siri 看不見你；只做 Intent、沒有工作階段層，App 內的規劃、摘要、多輪改稿會立刻變脆。

這也是本文和站內消費向文章的分界。功能清單、收費分層請看Apple Intelligence 免費與付費區別；Mac 上 Siri 能做什麼見macOS 27 Siri AI 功能解析。下面只談開發流程：從工程選型到一條可示範、可測試、可提審的閉環。台港團隊若同時要服務台灣、香港與中國大陸使用者，請把「系統模型能不能開」當成產品開關，而不是上架文案裡的一句空話。

開工前：Xcode 27、裝置分層與地區

先把環境釘死，再寫第一行 import FoundationModels。iOS 27 SDK 隨 Xcode 27 發布；模擬器能跑通工作階段骨架，但 Private Cloud Compute、真機工具呼叫次數與語音相關能力，經常和真機／地區不一致。蘋果在 iOS 27 發行說明裡寫過：模擬器上 PCC 可能不可用，裝置端模型在「工具呼叫 + 引導生成」組合下也可能過度調 Tool。這些不是邊角，而是你排期時必須留的緩衝。

裝置不要按「能不能裝 iOS 27」來規劃 AI 功能。iPhone 11 及更新機能升級系統，但 Apple Intelligence／裝置端 Foundation Models 仍從 iPhone 15 Pro / iPhone 16 一代起算；更強的裝置端模型（常見說法是 AFM 3 Core Advanced，影響表現力語音與高精度聽寫）主要落在 iPhone 17 Pro / Air 這一檔。iPad 側大致是 M1 起用 Apple Intelligence，更新的裝置端模型要更高記憶體的 M 系列。開發決策應寫成三張表，而不是一句「最低 iOS 27」：

地區是第二道閘。Siri AI 與部分系統級能力在中國大陸、歐盟等地仍可能受帳號、語言、監管進度限制。對台灣與香港的開發者來說，台灣／港區 Apple ID 通常比中國大陸帳號更容易開到 Apple Intelligence 與較完整的 Siri AI，但繁中介面、語音與部分系統路由仍可能落後美區英文；不要假設「會講中文的市場體驗都一樣」。台港團隊常見做法是：主路徑先用裝置端 + PCC（帳號與系統語言允許時），同時把 App Intents 與 Foundation Models 工作階段寫成可開關模組；若要上架中國大陸，業務閉環改走自己的模型或已合規的雲端服務，等系統能力開放再打開系統路由。不要在 App Store 截圖裡寫「全程 Siri AI」，卻只在美區帳號下錄過影。

建置機方面，Xcode 27 與舊版穩定建置不建議擠在同一台日常筆電上。beta／GM 並行時，把迴歸機和嘗鮮機拆開，能少掉一半「昨天還能編、今天憑證和模擬器搶路徑」的事故。拆分思路可對照Xcode beta 與正式 Runner 分離。

Foundation Models：一條 API，三種落點

iOS 26 引入的 Foundation Models，在 iOS 27 被蘋果擴成統一的原生 Swift API：裝置端模型可吃圖像輸入，工作階段可指向伺服器模型，也能掛自訂 Skills。官方新聞稿見 Apple Newsroom（2026-06）。對工程團隊，真正要選的不是「要不要上 AI」，而是這一次推論落在哪。台港獨立開發者若同時維護台灣、香港與海外上架，這一步會直接決定隱私文案、金鑰存放與審核材料要準備幾套。

iOS 27 的關鍵變化是：換模型不必換工作階段寫法。蘋果把第三方接入收成公開協定，WWDC26 session Bring an LLM provider to the Foundation Models framework 要求提供方用 Swift Package 發佈，Executor 負責把 Transcript 翻成自己的訊息格式，並處理 prewarm、串流輸出與 KV cache。App 側仍然是 LanguageModelSession。

成本上也有新槓桿：參加 App Store Small Business Program、累計首次下載低於 200 萬的開發者，使用跑在 Private Cloud Compute 上的新一代 Apple Foundation Models 時，可以免雲端 API 費用（以蘋果當期條款為準）。這不是「無限免費推論」，而是把「試一把蘋果伺服器模型」的門檻壓下來。超過門檻或要用 Claude／Gemini，就按提供商帳單走。台灣與香港的小型工作室正好落在這個門檻附近的很多，先用 PCC 驗證閉環，再決定要不要自建金鑰，通常比第一天就接第三方划算。

第一步：LanguageModelSession 與結構化輸出

工作階段物件是整條鏈路的起點。文件見 LanguageModelSession：一次工作階段維護一份 Transcript，超窗會拋 LanguageModelError.contextSizeExceeded。正式環境的程式裡不要每次按傳送都 new 一個工作階段，也不要無限追加——規劃階段用短工作階段，執行階段另開，比「一個包山包海的工作階段聊到底」穩得多。待辦、行程、庫存這類產品，第一個該驗證的不是文筆，而是模型能不能穩定填出你定義好的欄位。

import FoundationModels

@Generable
struct TaskDraft {
    @Guide(description: "不超過 20 字的任務標題")
    var title: String
    @Guide(description: "ISO-8601 截止日期；使用者沒提就寫 none")
    var dueISO8601: String
    var priority: Priority
}

@Generable
enum Priority {
    case low, normal, high
}

let session = LanguageModelSession {
    """
    你是待辦 App 裡的規劃助手。
    只產出 TaskDraft。禁止編造使用者沒提到的行事曆事件。
    """
}

let response = try await session.respond(
    generating: TaskDraft.self,
    to: Prompt("明天下午三點前交週報，標高優先順序")
)
let draft = response.content

這一步的產品意義大於語法意義：@Generable 把模型從「會聊天」變成「能填表」。後面無論是寫進 SwiftData、丟給 App Intent，還是再餵給下一輪規劃，你拿到的都是型別，而不是要再解析一遍的 Markdown。iOS 27 發行說明也提醒過：@Generable 用在 enum 上可能冒出壓不掉的 GenerationError 警告——看到警告先對照發行說明，不要誤判成業務邏輯壞了。

圖像輸入按官方能力用在「收據解析、貨架辨識、螢幕內物體」這類任務，而不是把相簿整庫塞進上下文。工作階段超窗時，優先截斷工具回傳和舊輪次，而不是截斷當前使用者那一句。繁中使用者常會夾雜日期口語（「下週三下班前」「這周五」），@Guide 裡把「沒說清楚就寫 none」寫死，比事後在介面上猜一個截止日期安全。

第二步：工具、Skills 與 Dynamic Profiles

有了結構化輸出，下一步是讓模型能動你的業務，而不是只吐 JSON。Foundation Models 的 Tool 協定和 App Intent 不是自動同一件事：Tool 給工作階段用，Intent 給系統用。可以讓 Tool 內部呼叫同一套 Store，但不要假設「寫了 Intent，模型就看得到」。這是上架前最容易被行銷文案帶歪的地方——Siri 能建立待辦，不代表 App 內的規劃助手已經接上同一條寫入路徑。

iOS 27 為多階段 Agent 加了 Dynamic Profiles。WWDC26 session Build agentic app experiences 的示範很具體：同一條工作階段在「腦力激盪／規劃／審閱」之間切換時，profile 可以換模型、溫度和推論深度——例如規劃走 PCC + 更深 reasoning，審閱退回裝置端模型以控制延遲和費用。profile 體會在每次 prompt 時重算，所以不要在 body 裡做重 I/O。

enum PlanPhase { case brainstorm, plan, review }

func makeProfile(_ phase: PlanPhase) -> LanguageModelSession.DynamicProfile {
    LanguageModelSession.DynamicProfile {
        switch phase {
        case .brainstorm, .plan:
            return .init(model: .privateCloudCompute, tools: [SearchNotesTool(), ListCalendarTool()])
        case .review:
            return .init(model: SystemLanguageModel.default, tools: [ValidateDraftTool()])
        }
    }
}

效能上有兩條容易踩的坑。第一，改寫歷史會打爆 KV cache，延遲立刻上去；能 append 就不要重寫 Transcript。第二，裝置端模型在「工具 + 引導生成」組合下可能連打 Tool，要用次數上限和「同一 Tool 連續失敗就停」兜底。蘋果提供了 Foundation Models Instrument 和評測框架，上線前至少用 20–30 條真實使用者說法做迴歸，而不是只錄一條發表會同款 demo。台港產品若同時收國語、台語口語夾雜和英文專有名詞，評測集一定要包含這三種講法，否則裝置端模型的工具呼叫成功率會被高估。

Skills（自訂技能）適合把「公司內部口徑、禁用詞、領域詞典」從 prompt 字串裡拆出去，便於營運改、便於按地區開關。不要把 Skills 當成第二個後端：它仍然跑在工作階段邊界內，權限與日誌要和 Tool 同一套稽核。對同時出台灣、香港與中國大陸包的團隊，Skills 是放「這個店面能不能提行事曆、能不能走 PCC」的好位置，比在十個 View 裡寫 if 乾淨。

第三步：App Intents 交給 Siri AI

App Intents 不是「捷徑小功能」，而是 iOS 27 裡Siri 進入第三方 App 的唯一正門。蘋果在 WWDC 2026 把 SiriKit 標成棄用，並給了大約兩到三年的相容視窗。還在用舊 Intent Extension 的團隊，遷移優先順序應高於「再調一調聊天文案」。協定與參數解析見 AppIntent。

iOS 27 這一代 Intents 要刻意用上的能力包括：系統 schema（開啟、建立、搜尋等常見動作盡量對齊，而不是全自創標題）、螢幕感知（讓 Siri 能解析「這個」「第三個」）、串流／長任務結果，以及多輪補參數。實體要能被 Spotlight 索引時，再考慮 IndexedEntity 與螢幕標註；視覺智慧搜圖則走 SemanticContentDescriptor + IntentValueQuery，不要硬塞進 LanguageModelSession。捷徑圖庫裡的標題與對話提示，請用台灣用語（建立待辦、開啟清單），不要直接貼簡體產品文案。

import AppIntents

struct CreateTaskIntent: AppIntent {
    static var title: LocalizedStringResource = "建立任務"
    static var description = IntentDescription("把一件待辦寫入 App。")

    @Parameter(title: "標題")
    var title: String

    @Parameter(title: "優先順序")
    var priority: String?

    func perform() async throws -> some IntentResult & ProvidesDialog {
        try await TaskStore.shared.create(title: title, priority: priority ?? "normal")
        return .result(dialog: "已建立：\(title)")
    }
}

寫 Intent 時把「人話」和「機器契約」分開：title／description 給 Siri 和捷徑圖庫看；perform() 只做冪等、可稽核的寫入。需要使用者確認的破壞性動作，顯式要確認，不要讓模型工作階段直接靜默呼叫。參數解析失敗時，讓系統再問一句，比你在 dialog 裡塞一段模型自由發揮更安全。提審時審核員常會從捷徑或 Siri 進 App，而不是先打開你的聊天頁——Intent 路徑不穩，等於主路徑沒測到。

把模型接到 Intent：一條可上架閉環

到這裡可以把兩條線接起來。建議的預設架構是模型只產草稿，Intent 才提交。這樣 App 內說話、Siri 帶一句自然語言進來、捷徑畫廊一鍵建立，最後都打進同一套 Store，撤銷、通知與稽核才有單一真相：

1. 使用者在 App 內說話／打字，或從 Siri 帶一句自然語言進來。
2. LanguageModelSession 產出 @Generable 草稿，必要時先走 Tool 讀行事曆、備忘錄、庫存。
3. 介面展示草稿，使用者點確認——或對低風險動作設自動確認門檻。
4. 建構對應 AppIntent 並 perform()，同一套 Store 也服務捷徑與 Spotlight。
5. 把執行結果寫回 Transcript（工具輸出），供下一輪改稿，而不是另起爐灶。

func commit(_ draft: TaskDraft) async throws {
    var intent = CreateTaskIntent()
    intent.title = draft.title
    intent.priority = String(describing: draft.priority)
    _ = try await intent.perform()
}

為什麼不讓 Tool 直接寫庫？因為 App Review、捷徑圖庫、Siri 建議和你自己的復原堆疊，都更認 Intent 這條路徑。模型幻覺寫錯截止日期時，你還可以在介面攔一層；如果 Tool 已經靜默插入十條提醒，客服成本會高一個數量級。對會寫入行事曆或觸發付款的動作，把確認按鈕留在 Intent 之前，比事後道歉便宜。

跨模型切換放在 profile／session 工廠裡，不要散落在 View。地區開關也放這裡：中國大陸包可以預設走你已合規的第三方 LanguageModel；台灣、香港與美區包在帳號與系統語言允許時，優先裝置端 + PCC。同一套 Intent 保持不變，使用者從 Siri 進來時仍然打到 CreateTaskIntent。這樣行銷可以按店面改截圖，工程不必為每個地區複製一套動作層。

測試、隱私與上架清單

AI 功能比普通 CRUD 更容易在審核和客服處翻車。發布前至少過一遍下面這張表。台港團隊若計畫同時上架台灣、香港與中國大陸，請把「台灣／港區 Apple ID 能開、大陸帳號不能開」當成必測組合，而不是上線後再補：

隱私說法要和實作一致。裝置端推論可以強調「預設不出網」；一旦走 PCC 或第三方，設定頁必須寫清。第三方提供方文件要求憑證進鑰匙圈，並考慮 App Attest，不要在 Session 初始化裡塞裸 Key。日誌只留草稿 schema 與 Intent 識別碼，不要把完整 Transcript 預設上傳到自己的分析後台。台灣《個人資料保護法》與香港《個人資料私隱條例》對跨境傳輸都比「寫一句我們很重視隱私」嚴格，設定頁與審核備註最好直接寫出資料落在裝置、PCC 還是你的雲端。

審核資料準備三樣：一段 30 秒的「說話 → 草稿 → 確認 → 清單出現」螢幕錄製（系統語言與截圖地區一致）；一份「無 AI 裝置上的降級說明」；一張模型落點表（裝置端／PCC／第三方）。消費者側的 Siri 能力邊界，可再對照WWDC 2026 Siri AI 解讀，避免行銷文案跑到工程能力前面。用港區或台灣帳號錄的影，不要配上暗示中國大陸也能用系統 Siri AI 的字幕。

團隊若還在用個人 Mac 跑 Xcode 27、真機矩陣和夜間迴歸，編排成本會很快超過模型本身。把穩定建置和 Agent 評測放到一台常開的 Apple Silicon 上，比每人升級一台滿血筆電更可控。記憶體與磁碟都被模擬器、本機評測和 Xcode 27 工具鏈吃掉，機器還不能隨便休眠——這正是把迴歸機從辦公筆電上拆出去的理由。