Apple Vision Framework：多數開發者忽略的裝置端電腦視覺

Apple 的 Vision 框架（不帶「OS」字尾的那個）提供超過二十多項裝置端電腦視覺操作。多數 iOS 開發者預設使用 OpenAI Vision API、Google Cloud Vision 或 AWS Rekognition 來處理那些 Vision 框架在裝置 Neural Engine 上幾毫秒就能完成的任務。這種預設反映的是偏見而非評估：雲端 API 給人「現代 AI」的感覺，Vision 則給人「平台底層」的印象，於是平台被略過。這種偏見誤判了平台現今所包含的內容。

Vision 是以本地優先的 CV 框架。可用時在 Neural Engine 上執行，否則使用 GPU，最後才回退到 CPU。多數操作的推論在幾毫秒內完成。框架每次呼叫不收取任何費用。資料從不離開裝置。API 金鑰並不存在，因為根本沒有 API。對於 iOS 應用程式所做的多數電腦視覺工作而言，這是正確的工具。

TL;DR

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

Vision 實際包含哪些內容

Vision 將其操作歸類為 VNRequest 類型。建立請求、配置參數、傳入影像（或 CVPixelBuffer、CIImage、CGImage 或 URL）然後執行。結果會以觀察值（observations）的形式附加到請求上回傳。下列類別涵蓋了截至 iOS 26 為止框架的領域。

文字辨識

VNRecognizeTextRequest 執行 OCR。該請求支援 recognitionLevel（.fast 用於即時相機串流，.accurate 用於文件掃描）、語言提示、自訂字詞清單以及邊界框信心值。iOS 18+ 上的 .accurate 路徑在收據、招牌與文件上對印刷文字處理得很好；手寫辨識則支援部分語言（請參閱 Apple 的辨識語言清單³）。

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 回傳每張臉的品質分數（0-1），反映光線、銳利度與置中程度。應用程式可用此分數來決定何時拍攝自拍，或從連拍中自動挑選最佳幀。

對於需要尋找臉部、裁切到臉部、模糊臉部或計算臉部數量的多數應用程式，rectangles 請求是正確的工具。對於需要將內容對齊到使用者臉部的應用程式（濾鏡、面具、追蹤），landmarks 加上瞳孔追蹤才是正確的工具。這些都不需要模型檔案或網路呼叫。

身體與手部姿態

VNDetectHumanBodyPoseRequest 回傳 VNHumanBodyPoseObservation.JointName⁴ 中 19 個命名關節（鼻子、頸部、肩膀、手肘、手腕、臀部、膝蓋、腳踝、耳朵、眼睛、根部）的 2D 座標與每個關節的信心值。VNDetectHumanBodyPose3DRequest 將拓撲擴展到 3D 空間，回傳 VNHumanBodyPose3DObservation 結果；當裝置提供深度資料（AVDepthData）時,該請求會利用以提升準確度,但不需要 LiDAR 掃描器。⁴ VNDetectHumanHandPoseRequest 以手指關節解析度回傳 21 個手部特徵點。

身體姿態正是健身應用程式無需穿戴裝置即可計算次數的依據，AR 應用程式將虛擬內容附加到使用者手上的依據，以及姿勢應用程式評估動作的依據。手部姿態驅動手勢辨識（使用者比出兩根手指，應用程式看到兩根手指）。兩者都能在近期的 iPhone 上以視訊幀率運行，足以支援即時 AR 與手勢輸入。雲端對應方案是 Google MediaPipe 或專有的健身科技 API，這些都被該框架取代。

條碼與 QR

VNDetectBarcodesRequest 讀取大多數零售與庫存工作流所需的編碼類型（QR、PDF417、Aztec、Code 128、Code 39、EAN-13、ITF14、Data Matrix、GS1 DataBar 等），並回傳原始資料與邊界矩形。偵測在毫秒內完成，並在 Apple 相機應用程式已驗證的低光條件下亦可運作。

文件分割

VNDetectDocumentSegmentationRequest 在畫面中找出矩形文件並回傳其角點，並考量透視變形。這正是文件掃描器應用程式用來將文件裁切並校正為平面影像的請求。Apple 自家的 VisionKit 框架包裝了該請求並附帶 UI，但當應用程式需要自訂 UI 時，可直接呼叫底層操作。

顯著性與美學

VNGenerateAttentionBasedSaliencyImageRequest 回傳一張熱圖，標示影像中觀看者注意力最可能聚焦之處。VNGenerateObjectnessBasedSaliencyImageRequest 回傳物件所在位置的熱圖。VNCalculateImageAestheticsScoresRequest 在 iOS 18 中作為公開 API 加入¹，回傳美學品質分數，包括用途分類（備忘錄、螢幕截圖）與美學值。這些分數正是「照片」app 用來呈現「回憶」候選項目，以及自動裁切決策的依據。

影像分類與嵌入

VNClassifyImageRequest 使用內建分類器（涵蓋數百個常見物件類別）回傳影像的前 N 名類別標籤。⁵ VNGenerateImageFeaturePrintRequest 回傳適合用於影像相似度搜尋的特徵向量（模型嵌入）。

嵌入正是「照片」應用程式、食譜應用程式的「找出相似料理」，或情緒板應用程式以相似度去重的實際運作方式。雲端對應方案是 OpenAI CLIP 嵌入或 Google Vertex AI；Vision 在本地免費回傳這些結果。

物件追蹤與軌跡

VNDetectTrajectoriesRequest 跨幀追蹤移動物體並回傳拋物線軌跡擬合（投擲的球、射出的箭）。VNTrackObjectRequest 在影片序列中追蹤手動標定邊界的物體。

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

透過 VNCoreMLRequest 使用自訂模型

VNCoreMLRequest 透過 Vision 管道執行任何 Core ML 模型。該請求會根據模型的輸入描述自動處理前處理（影像縮放、色彩空間轉換、正規化）。應用程式在 Create ML 中訓練自訂分類器（少數類別、每類別約一百張範例影像、十分鐘訓練），或下載已發布的模型，將 .mlpackage 放入應用程式套件中，然後以三行程式碼透過 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 將其轉化為應用程式套件中的 .mlpackage 與一個請求處理器。

雲端 API 真正勝出的場合

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

多模態 LLM 理解。「圖中這個人在做什麼？」「這張圖表是否有誤導？」「翻譯這份菜單並告訴我哪些品項是素食。」這些都不是像素層級的問題。它們需要大型多模態模型來結合視覺感知、世界知識與語言。Apple 的 Foundation Models（裝置端 LLM，詳見 Foundation Models 裝置端 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 的優勢在於成本（每次呼叫零成本）、尾端延遲（無網路抖動）以及隱私（資料從不離開裝置）。

當應用程式頻繁呼叫視覺操作時，成本會累積。一個每次工作階段處理 100 張影像的相片編輯應用程式，透過雲端 API 每次工作階段成本以美元計，透過 Vision 則為零。

與代理工作流的連結

Vision 與已發布的兩個叢集概念能完美搭配：

Apple Intelligence 的 App Intents 工具。 當應用程式透過 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 金鑰。沒有網路呼叫。沒有第三方資料暴露。

過去兩個版本的成熟功能

值得一提的三項新增功能，依 Apple 的釋出說明保守標註日期²：

美學評分作為公開 API（iOS 18）。 VNCalculateImageAestheticsScoresRequest 回傳包括用途分類與美學值的分數，取代了相片管理應用程式過去必須以自訂 Core ML 模型粗略近似的做法。

多語 OCR 的提升。 VNRecognizeTextRequest 在近期釋出中擴展了非拉丁文字的支援，縮小了與歷來具有更強多語涵蓋的雲端 OCR 服務之間的差距。Apple 的文字辨識文件列出當前的語言支援³。

結合 VisionKit 的文件分割。 VNDetectDocumentSegmentationRequest 找出矩形文件並回傳角點；VisionKit 的 VNDocumentCameraViewController 以設計過的 UI 為使用者包裝文件擷取，而 DataScannerViewController（iOS 16+）則涵蓋即時文字與機器可讀碼掃描。⁶

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

為什麼多數開發者略過 Vision

儘管論述清晰，框架仍被略過的三個原因：

雲端優先的習慣。 多數現代 AI 開發都先針對雲端 API 進行。開發者知道如何呼叫 OpenAI；VNRecognizeTextRequest 加上 VNImageRequestHandler 加上 VNRecognizedTextObservation 的介面範圍，感覺像是更多要學的 API，但以行數計，實際上比呼叫 OpenAI Vision 還少（沒有驗證、沒有 HTTP、沒有重試、沒有 JSON 解析）。

對能力的誤判。 近期未檢視該框架的開發者，會以為它只涵蓋 OCR 與條碼。上述類別清單包含超過二十多項能力，其中數項沒有雲端原生對應方案，數項則匹敵商用 API 卻無其成本。

原型與生產的分歧。 雲端 API 在早期原型階段勝出（一行 curl 指令即可獲得結果），而原型未經重新評估就直接轉為生產管道。正確做法是用最快的方式做原型，然後在工作流落實後重新評估感知層。

修正之道不是拒用雲端 API；修正之道是了解平台的內容，使選擇成為實質的選擇。

此模式對 iOS 26+ 應用程式的意義

三項要點。

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

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

3. 將 Vision 與 Foundation Models 搭配以建構完整的裝置端管道。 感知（Vision）餵入推理（裝置端 LLM）。整條管道從頭到尾都在本地執行，沒有 API 金鑰、沒有網路抖動，也不會有任何遙測資料離開裝置。叢集的 Foundation Models 一文 涵蓋 LLM 那一半；Vision 則是輸入那一半。

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

常見問題

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 檔案放入應用程式套件、實例化模型、以 VNCoreMLModel 包裝，然後透過請求處理器執行。同一個處理器可平行執行多個請求，包括內建的 Vision 請求與自訂 Core ML 模型。

Vision 在 Apple Silicon 上如何分派？

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

iOS 18 與 iOS 26 有哪些新功能？

依 Apple 釋出說明保守整理：VNCalculateImageAestheticsScoresRequest 在 iOS 18 中作為公開 API 加入；VNRecognizeTextRequest 在近期版本中擴展了多語支援；VisionKit 的 DataScannerViewController（iOS 16+）涵蓋即時文字與機器可讀碼，而 VNDocumentCameraViewController 涵蓋文件擷取。招牌能力（文字、臉部、姿態、條碼、嵌入）在多個 iOS 版本中已臻成熟。

參考資料