Apple Vision 框架：多數開發者改用雲端 API 的任務，其實系統內建已經做好了

Apple 的 Vision 框架（沒有「OS」字尾的那一個）內建超過二十種裝置端電腦視覺操作。多數 iOS 開發者卻預設選用 OpenAI Vision API、Google Cloud Vision 或 AWS Rekognition，來處理該框架在裝置 Neural Engine 上能於微秒內完成的任務。這個預設反映的是偏見，而非評估結果：雲端 API 給人「現代 AI」的感覺，Vision 則給人「平台水管工程」的印象，於是平台就被略過了。這份偏見誤判了平台如今的內涵。

Vision 是以本地優先為原則的 CV 框架。可用時跑在 Neural Engine 上，否則退回 GPU，最後才是 CPU。多數操作的推論在數毫秒內完成。框架每次呼叫都不收費。資料絕不離開裝置。API key 並不存在，因為根本沒有 API。對於 iOS app 多數的電腦視覺工作而言，這就是正確的工具。

TL;DR

• Apple Vision 提供超過二十種裝置端 CV 操作：文字辨識、人臉偵測與特徵點、身體與手部姿勢估計、條碼讀取、文件分割、影像嵌入向量、顯著性、動物偵測、輪廓、軌跡、光流，以及任何 Core ML 模型的執行器。
• 每項操作都在 Neural Engine 上以毫秒等級執行，每次呼叫零成本，不需網路，也不會產生第三方遙測資料。
• 雲端 API 在一個特定情境上勝出：對影像進行複雜的語意推理（例如多模態 LLM 理解圖表、迷因或文件意圖）。對於像素層級的操作（找臉、讀文字、偵測手部），Vision 在成本、延遲與隱私上都勝出。
• 與 agent 工作流的關聯：Vision 結果可餵給 App Intents 與 Foundation Models 裝置端 LLM 呼叫，無需網路往返。整條管線都在本地執行。

Vision 實際包含哪些功能

Vision 將其操作組織為各種 VNRequest 類型。建立請求、設定參數、傳入影像（或 CVPixelBuffer、CIImage、CGImage 或 URL），然後執行。結果以 observations 形式附加到請求上回傳。以下分類涵蓋了截至 iOS 26 為止的框架版圖。

文字辨識

VNRecognizeTextRequest 執行 OCR。此請求支援 recognitionLevel（.fast 用於即時相機串流，.accurate 用於文件掃描）、語言提示、自訂詞彙清單以及邊界框信心值。iOS 18+ 上的 accurate 路徑在收據、招牌與印刷文件上的表現可媲美商用 OCR API；多種語言的手寫辨識也已支援。

let request = VNRecognizeTextRequest { request, error in
    guard let observations = request.results as? [VNRecognizedTextObservation] else { return }
    let lines = observations.compactMap { $0.topCandidates(1).first?.string }
    print(lines.joined(separator: "\n"))
}
request.recognitionLevel = .accurate
request.usesLanguageCorrection = true
request.recognitionLanguages = ["en-US"]

let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

同樣的操作若透過 OpenAI Vision API，低細節模式每次呼叫費用約為一分美元的零頭，高細節模式則明顯更高，往返耗時 1-3 秒，且會將影像送至 OpenAI 伺服器。Vision 則在本地 100-300 毫秒內回傳結果，免費，且資料不外洩。

人臉偵測與特徵點

Vision 內建三層人臉分析：

• VNDetectFaceRectanglesRequest 回傳畫面中每張臉的邊界框。
• VNDetectFaceLandmarksRequest 為每張臉回傳結構化的特徵點區域（下顎線、嘴巴、眼睛、眉毛、鼻子、瞳孔），每個區域包含多個關鍵點。
• VNDetectFaceCaptureQualityRequest 回傳品質分數，相機 app 用此分數來決定自拍的拍攝時機。

對於多數需要找臉、裁切到臉部、模糊臉部或計算臉部數量的 app 來說，rectangles 請求是正確的工具。對於要將內容貼合到使用者臉部的 app（濾鏡、面具、追蹤），landmarks 加上瞳孔追蹤才是正確選擇。這些通通不需要模型檔案，也不用網路呼叫。

身體與手部姿勢

VNDetectHumanBodyPoseRequest 回傳 VNHumanBodyPoseObservation.JointName⁴ 中 19 個具名關節（鼻、頸、肩、肘、腕、髖、膝、踝、耳、眼、根節點），帶有 2D 座標與每個關節的信心值。VNDetectHumanBodyPose3DRequest 在配備 LiDAR Scanner 的裝置上將拓撲擴展到 3D 空間。VNDetectHumanHandPoseRequest 以手指關節解析度回傳 21 個手部特徵點。

身體姿勢正是健身 app 不靠穿戴裝置就能計算反覆次數所用的技術，也是 AR app 將虛擬內容附著於使用者雙手的依據，更是姿勢矯正 app 評估動作的基礎。手部姿勢則驅動手勢辨識（使用者比出兩根手指，app 就看到兩根手指）。兩者在近期的 iPhone Neural Engine 上都能以 60 fps 執行。對應的雲端方案是 Google MediaPipe 或專屬的健身科技 API，這個框架直接取代了它們。

條碼與 QR

VNDetectBarcodesRequest 讀取多數零售與庫存工作流所需的符號體系（QR、PDF417、Aztec、Code 128、Code 39、EAN-13、ITF14、Data Matrix、GS1 DataBar 等），並回傳原始載荷與邊界矩形。偵測在毫秒內完成，且能在 Apple 自家相機 app 已驗證可運作的弱光環境下正常工作。

文件分割

VNDetectDocumentSegmentationRequest 在畫面中找出矩形文件並回傳其角點，會將透視變形納入考量。文件掃描 app 就是用此請求來裁切並把文件矯正成平面影像。Apple 自家的 VisionKit 框架將此請求加上 UI 包裝起來，但底層操作在 app 需要自訂 UI 時可直接呼叫。

顯著性與美感

VNGenerateAttentionBasedSaliencyImageRequest 回傳一張熱力圖，標示觀看者最可能注視的區域。VNGenerateObjectnessBasedSaliencyImageRequest 則回傳物體可能所在位置的熱力圖。VNCalculateImageAestheticsScoresRequest 在 iOS 18 中以公開 API 形式加入¹，回傳美感品質分數，包含實用性分類（備忘錄、螢幕截圖）與美感數值。Photos 就是用這些分數來挑選「回憶」候選影像，自動裁切的決策也以此為依據。

影像分類與嵌入向量

VNClassifyImageRequest 透過內建分類器（以網路規模資料訓練、超過 1,000 個類別的模型）為影像回傳前 N 個類別標籤。VNGenerateImageFeaturePrintRequest 則回傳適合用於影像相似度搜尋的特徵向量（即模型的嵌入向量）。

嵌入向量正是 Photos app、食譜 app 的「找出相似料理」、或情緒板 app「以相似度去重」實際運作的底層機制。對應的雲端方案是 OpenAI CLIP 嵌入或 Google 的 Vertex AI；Vision 在本地免費回傳結果。

物件追蹤與軌跡

VNDetectTrajectoriesRequest 跨畫面追蹤移動中的物件，並回傳拋物線軌跡擬合（拋出的球、射出的箭）。VNTrackObjectRequest 則在影片序列中追蹤手動框選的物件。

軌跡是運動類 app 的底層原語（追蹤棒球、籃球、網球）。偵測可在 AVFoundation 即時串流上運作，並即時回傳結果。

透過 VNCoreMLRequest 載入自訂模型

VNCoreMLRequest 可透過 Vision 管線執行任何 Core ML 模型。請求會根據模型的輸入描述自動處理前處理（影像縮放、色彩空間轉換、正規化）。app 可用 Create ML 訓練自訂分類器（少數幾個類別、每個類別百來張樣本影像、訓練十分鐘），或下載已發佈的模型，把 .mlpackage 放進 app bundle，再用三行程式碼透過 Vision 執行。

let model = try VNCoreMLModel(for: MyClassifier(configuration: .init()).model)
let request = VNCoreMLRequest(model: model) { request, error in
    let results = request.results as? [VNClassificationObservation]
    print(results?.first?.identifier, results?.first?.confidence)
}
let handler = VNImageRequestHandler(cgImage: image, options: [:])
try handler.perform([request])

要在雲端做出對等的自訂分類器，得把模型架在伺服器上、付推論運算費、管理 API、並接受網路延遲。Vision 把這一切變成 app bundle 中的一個 .mlpackage 檔案加上一個請求處理器。

雲端 API 真正勝出的場景

Vision 的版圖是像素層級的操作：找出這個東西、為這張影像分類、辨識這段文字。框架本身並不提供針對影像意義的複雜語意推理。雲端 API 在以下三種情境是正確選擇：

多模態 LLM 的理解。「這張照片中的人在做什麼？」「這張圖表是否有誤導性？」「翻譯這份菜單，並告訴我哪些是素食。」這些都不是像素層級的問題，而是需要大型多模態模型結合視覺感知、世界知識與語言能力。Apple 的 Foundation Models（裝置端 LLM，詳見 Foundation Models on-device LLM）開始在裝置端處理部分這類任務，但對於複雜推理，GPT-4o、Claude Sonnet 或 Gemini 仍然勝出。

沒有訓練資料的一次性自訂任務。Vision 的分類模型是固定的；自訂 Core ML 模型需要訓練資料。多模態 LLM 不需看過任何標註樣本就能回答「這是不是一張戴領結的貓的照片？」對於原型開發或一次性任務來說，蒐集訓練資料代價過高，雲端 LLM 才是正確工具。

OCR 之外的文件智慧處理。Vision 的 OCR 回傳純文字。文件智慧 API（AWS Textract、Google Document AI、Azure Form Recognizer）回傳的是結構化欄位：發票號碼、日期、明細項目、合計金額。結構化才是其附加價值，OCR 不是。對於高價值的文件工作流，雲端 API 通常是正確選擇；至於「讀這張收據並把文字傾倒出來」，Vision 才對。

模式如下：雲端在推理與高度專業化的垂直 API 上勝出；Vision 則在感知原語上勝出。

誠實的延遲與成本比較

以 iPhone 16 Pro（A18 Pro 晶片）執行的代表性推論管線：

上述數字源自 Apple 公開的基準測試與開發者回報的測量值；重點在於數量級，而非確切數值。Vision 的勝出體現在成本（每次呼叫零成本）、尾部延遲（無網路抖動）與隱私（資料絕不離開裝置）上。

當 app 頻繁呼叫視覺操作時，成本會疊加。一個每次工作階段處理 100 張影像的相片編輯 app，透過雲端 API 每次工作階段成本可達數美元等級，透過 Vision 則為零。

與 agent 工作流的關聯

Vision 與已發表系列中兩個概念可乾淨地配對：

為 Apple Intelligence 提供 App Intents 工具。當 app 透過 AppIntent 暴露「找出我相片中的人臉」或「從螢幕截圖讀出文字」這類能力時，意圖的 perform 方法會在本地執行 Vision 並回傳結構化結果。Apple Intelligence 的協調器可呼叫該意圖，而無須將使用者的相片送至伺服器。App Intents 一文已闡述其表面契約。

Foundation Models 裝置端 LLM。同時需要感知與推理的管線會先執行 Vision（擷取文字、找臉、定位物件），再執行 Foundation Models（推理所找到的內容、產生摘要）。兩個階段都在裝置端執行。網路呼叫總數：零次。Foundation Models 一文說明如何呼叫 LLM；本文則主張 Vision 正是無雲端往返、為其供料的那一端。

let textRequest = VNRecognizeTextRequest()
textRequest.recognitionLevel = .accurate

let handler = VNImageRequestHandler(cgImage: receiptImage, options: [:])
try handler.perform([textRequest])

let extractedText = (textRequest.results ?? [])
    .compactMap { ($0 as? VNRecognizedTextObservation)?.topCandidates(1).first?.string }
    .joined(separator: "\n")

let llmResponse = await foundationModel.generate(
    "Summarize this receipt as JSON with merchant, total, and date fields:\n\(extractedText)"
)

整條管線都在裝置上執行。沒有 API key。沒有網路呼叫。也沒有第三方資料外洩。

過去兩個版本中成熟了哪些能力

以下三項值得點名，並依照 Apple 釋出說明保守標註版本²：

美感評分作為公開 API（iOS 18）。VNCalculateImageAestheticsScoresRequest 回傳包含實用性分類與美感數值的分數，取代了過去相片整理 app 必須以自訂 Core ML 模型近似達成的功能。

多語 OCR 強化。VNRecognizeTextRequest 在近期版本中持續擴充非拉丁字符支援，縮小了與雲端 OCR 服務在多語覆蓋上的歷史差距。Apple 的文字辨識文件列出了目前支援的語言³。

文件分割搭配 VisionKit 整合。VNDetectDocumentSegmentationRequest 找出矩形文件並回傳角點；VisionKit 的 DataScannerViewController 則將該請求包裝成設計過的 UI，提供即時文件掃描體驗。

框架的招牌能力（人臉、文字、姿勢、條碼、嵌入向量）在多個 iOS 版本中早已成熟。模式是：擴充而非重新發明。

為何多數開發者跳過 Vision

儘管論點清楚，框架仍常被忽略，原因有三：

雲端優先的習慣。多數現代 AI 開發都先針對雲端 API 進行。開發者熟悉如何呼叫 OpenAI；VNRecognizeTextRequest 加上 VNImageRequestHandler 加上 VNRecognizedTextObservation 的表面看起來要學的 API 比較多，但實際上程式碼行數反而更少。

對能力的誤判。最近沒檢視框架的開發者會以為它只涵蓋 OCR 與條碼。上方的類別清單列出十多項能力，當中數項在雲端找不到對等方案，數項則能比擬商用 API 而毫無成本負擔。

原型與正式產品脫鉤。雲端 API 在早期原型階段勝出（一行 curl 指令就能拿到結果），原型隨後被直接轉成正式管線，過程中未重新評估。正確做法是用最快的方式做原型，等工作流穩定後再重新評估感知層。

解方並不是拒絕雲端 API；解方是了解平台內含什麼，讓選擇成為真正的選擇。

此模式對 iOS 26+ app 的意義

三點重點。

1. 感知原語預設選用 Vision。找臉、讀文字、偵測條碼、執行姿勢估計、取得影像嵌入向量。框架在 Neural Engine 上以微秒等級執行，零成本，且不留下任何第三方資料軌跡。對於像素層級的 CV 操作，框架就是正確的起點。

2. 雲端 API 用於推理，而非感知。多模態 LLM 理解影像意義、垂直文件智慧 API 擷取結構化欄位、無訓練資料的一次性自訂任務。這些是雲端的版圖；交給雲端是對的。

3. 將 Vision 與 Foundation Models 配對成完整的裝置端管線。感知（Vision）餵給推理（裝置端 LLM）。整條管線在本地端到端執行，沒有 API key、沒有網路抖動，也沒有遙測資料離開裝置。本系列的 Foundation Models 一文 涵蓋 LLM 那一半；Vision 則是輸入那一半。

完整的 Apple 生態系系列：型別化的 App Intents；MCP servers；路由問題；Foundation Models；執行期 vs 工具鏈 LLM 之分；三個介面；單一資料來源模式；兩台 MCP 伺服器；Apple 開發的 hooks；Live Activities；watchOS 執行期；SwiftUI 內部結構；RealityKit 的空間心智模型；SwiftData schema 紀律；Liquid Glass 模式；多平台出貨；平台矩陣；我拒絕書寫的主題。中樞頁面在 Apple 生態系系列。關於更廣的 iOS 與 AI agent 脈絡，請參閱 iOS Agent 開發指南。

FAQ

Apple Vision 和 visionOS 有什麼差別？

Vision 框架是適用於 iOS、macOS 與 visionOS 的裝置端電腦視覺 API。visionOS 則是 Apple Vision Pro 的作業系統。命名上的重疊令人遺憾。Vision（框架）可在所有現代 Apple 裝置上執行；visionOS（作業系統）僅在 Vision Pro 硬體上執行。

何時該使用 Vision，而不是 OpenAI Vision API 或 Google Cloud Vision？

對於像素層級的感知任務（找臉、讀文字、偵測物件、計算項目數量、估計姿勢、產生影像嵌入向量），Vision 幾乎永遠是正確選擇。它在毫秒內執行，每次推論零成本，並把使用者資料留在裝置上。當任務需要對影像意義進行複雜的語意推理，或當垂直文件智慧 API 能提供超越文字擷取的結構化欄位時，雲端 API 才是對的選擇。

我可以透過 Vision 執行自己的 Core ML 模型嗎？

可以。VNCoreMLRequest 可包裝任何 Core ML 模型並自動處理前處理。把 .mlpackage 檔案放入 app bundle，建立模型實例，包成 VNCoreMLModel，再透過請求處理器執行。同一個處理器可以平行執行多個請求，包含內建的 Vision 請求與自訂 Core ML 模型。

Vision 在 Apple Silicon 上如何分派工作？

Vision（以及它執行的 Core ML 模型）會自動分派：可用時送往 Neural Engine，否則退回 GPU，最後才是 CPU。框架會為裝置與操作選擇最快的路徑。對多數現代 iPhone（A12 Bionic 之後），Neural Engine 處理絕大多數推論；開發者無需手動設定分派方式。

最近新增了什麼？

依照 Apple 釋出說明的保守摘要：VNCalculateImageAestheticsScoresRequest 在 iOS 18 中以公開 API 形式加入；VNRecognizeTextRequest 在近期版本中擴充了多語支援；VisionKit 的 DataScannerViewController 將文件掃描包裝在設計過的 UI 中。招牌能力（文字、人臉、姿勢、條碼、嵌入向量）在多個 iOS 版本中早已成熟。

References