最近在 Hacker News 上看到一個很有意思的項目方向Show HN: Visually Precise AI Tutoring on iOS。它核心不是再做一款“拍照搜題”App而是試圖把 AI 輔導(dǎo)從“一段文字答案”升級成“能在屏幕上精確指向問題位置”的視覺級交互。這個方向其實擊中了當(dāng)前 AI 教育應(yīng)用一個很明顯的痛點大多數(shù)輔導(dǎo)反饋停留在文本語義層模型能告訴你“哪里錯了”但沒法在真實屏幕上給你畫出來。本文不評價具體產(chǎn)品而是把它拆成一條 iOS 工程師可以直接上手的技術(shù)鏈路屏幕內(nèi)容采集 → 視覺結(jié)構(gòu)化 → 多模態(tài)大模型推理 → 視覺結(jié)果渲染。無論你是想復(fù)刻類似應(yīng)用還是想給自己的教育類 App 增加 AI 輔導(dǎo)能力都可以按這條鏈路一步步落地。全文包含可運行的 Swift 代碼示例、權(quán)限處理、坐標(biāo)系轉(zhuǎn)換、常見坑點和工程建議適合已經(jīng)掌握 Swift 基礎(chǔ)、想深入 AI iOS 方向的同學(xué)閱讀和復(fù)用。1. “視覺精確的 AI 輔導(dǎo)”是什么1.1 從文本問答到“看見屏幕”常規(guī)的 AI 輔導(dǎo)產(chǎn)品交互流程一般是用戶拍一道題或截一張圖上傳給大模型模型返回解析步驟和最終答案。這種方式對“靜態(tài)題目”效果不錯但對“動態(tài)操作類學(xué)習(xí)場景”就有明顯短板用戶在 App 里點錯了按鈕、配置錯了參數(shù)、觸發(fā)了一個報錯彈窗此時單純把截圖發(fā)給模型模型只能看到一張孤立圖片無法知道你剛才做了什么操作也無法在屏幕上精確標(biāo)記“這個紅色區(qū)域就是你出錯的地方”?！耙曈X精確”的 AI 輔導(dǎo)核心變化是把屏幕本身作為上下文。應(yīng)用持續(xù)或按需采集屏幕內(nèi)容經(jīng)過結(jié)構(gòu)化處理之后連同用戶問題一起交給多模態(tài)大模型。模型不僅返回文字步驟還能返回屏幕上的目標(biāo)區(qū)域坐標(biāo)。iOS 端拿到坐標(biāo)后在屏幕上渲染高亮框、箭頭、序號標(biāo)注甚至引導(dǎo)用戶點擊下一個位置。這樣一來AI 的回答就從“該怎么做”擴(kuò)展成了“看這里這就是問題所在然后點這個按鈕”。1.2 視覺精確的三個層次理解了方向之后可以把“視覺精確”拆成三個可量化的層次后續(xù)架構(gòu)設(shè)計都圍繞它們展開。第一層是空間精確。AI 必須能定位到屏幕上的具體元素比如“第二行公式中的 x 符號”“當(dāng)前頁面右上角的保存按鈕”“報錯彈窗中的關(guān)閉圖標(biāo)”。這些信息最終要落到一個矩形區(qū)域或坐標(biāo)點而不是一句含糊的“紅色字體部分”。第二層是語義精確。模型需要理解當(dāng)前屏幕上下文。同樣是“保存失敗”四個字出現(xiàn)在表單頁和出現(xiàn)在代碼編輯器里原因完全不同。視覺精確輔導(dǎo)要求模型把文字識別結(jié)果、按鈕狀態(tài)、輸入框內(nèi)容、頁面結(jié)構(gòu)組合成完整語義而不能只看單獨的 OCR 文本。第三層是時序精確。優(yōu)秀輔導(dǎo)不是單次問答而是多輪交互。學(xué)生點擊了某個按鈕后屏幕狀態(tài)發(fā)生變化AI 需要感知這次變化并基于“前后狀態(tài)差異”繼續(xù)指導(dǎo)。例如學(xué)生第一次選錯了選項界面出現(xiàn)錯誤提示AI 下一次回答就要能引用這個錯誤提示區(qū)域而不是重復(fù)之前的內(nèi)容。1.3 適用場景與讀者定位這類技術(shù)適合三類場景一是數(shù)學(xué)、物理等理科題目輔導(dǎo)模型可以精確指出公式推導(dǎo)中從第幾行開始出錯二是軟件操作類教學(xué)例如教用戶配置證書、處理 Xcode 打包報錯、操作復(fù)雜后臺系統(tǒng)AI 可以直接高亮界面按鈕三是編程入門輔導(dǎo)用戶在 iOS 模擬器或在線編輯器里運行代碼AI 定位控制臺報錯并高亮對應(yīng)代碼行。本文面向的讀者是有一定 Swift 和 Xcode 使用經(jīng)驗、想進(jìn)入 AI 應(yīng)用開發(fā)方向、或者正在設(shè)計教育類產(chǎn)品交互的開發(fā)者。不需要你提前掌握機(jī)器學(xué)習(xí)和 Vision 框架細(xì)節(jié)但建議你對 SwiftUI 或 UIKit 的 UI 層級、異步網(wǎng)絡(luò)請求、JSON 解析有基本概念。讀完本文后你能搭建出一條最小可用鏈路并知道每一步的常見坑在哪里。2. iOS 端視覺 AI 應(yīng)用的整體架構(gòu)2.1 核心鏈路采集 → 識別 → 推理 → 渲染整套系統(tǒng)可以抽象為四個模塊串成如下鏈路屏幕采集截圖 / ReplayKit ↓ 視覺結(jié)構(gòu)化Vision OCR、元素檢測 ↓ 大模型推理多模態(tài)大模型 / 文本模型 ↓ 結(jié)果渲染覆蓋層高亮、坐標(biāo)標(biāo)注、步驟展示四個模塊職責(zé)非常清晰屏幕采集層負(fù)責(zé)拿到當(dāng)前屏幕的 UIImage 或視頻幀。這里需要區(qū)分應(yīng)用內(nèi)截圖和系統(tǒng)級屏幕錄制兩種方式權(quán)限模型完全不同。視覺結(jié)構(gòu)化層把像素級圖片轉(zhuǎn)成 AI 可讀的文本與坐標(biāo)信息。例如 OCR 識別出屏幕上所有文字及其位置這一步是實現(xiàn)“空間精確”的關(guān)鍵。大模型推理層把“用戶問題 視覺結(jié)構(gòu)化結(jié)果 歷史對話”一起發(fā)送給大模型讓模型返回帶坐標(biāo)引用的結(jié)構(gòu)化答案。結(jié)果渲染層把模型返回的歸一化坐標(biāo)轉(zhuǎn)換回屏幕坐標(biāo)在 UI 上繪制高亮框、文字氣泡、操作引導(dǎo)等。這四個模塊可以分別開發(fā)、分別測試最后再串聯(lián)。這也是我在實際項目中比較推薦的做法不要一開始就追求完整的 Broadcast Extension 實時鏈路先做“截圖 本地識別 在線推理 靜態(tài)標(biāo)注”跑通之后再升級。2.2 技術(shù)選型建議圍繞四個模塊iOS 生態(tài)內(nèi)有比較成熟的選型UI 框架SwiftUI 為主UIKit 兜底。渲染覆蓋層用 SwiftUI 的 Canvas 或 overlay 很直觀成本低。屏幕采集最簡單的是應(yīng)用內(nèi)窗口截圖使用UIGraphicsImageRenderer即可如果要采集其他 App 的屏幕則必須用 ReplayKit Broadcast Upload Extension。視覺識別優(yōu)先使用 Vision 框架。它能做文字識別OCR、人臉檢測、矩形檢測、圖片分類。對于通用元素檢測甚至可以用 Vision 的VNRecognizeTextRequest先提取文本坐標(biāo)再用VNDetectRectanglesRequest獲取區(qū)域。大模型接入通過 URLSession 調(diào)用國內(nèi)或海外主流大模型的多模態(tài)接口。注意不同模型的接口格式、圖片編碼方式、JSON 輸出能力差異較大建議在服務(wù)端做一層封裝客戶端只面向統(tǒng)一的協(xié)議。結(jié)果渲染歸一化坐標(biāo) SwiftUI Shape 繪制。不要直接使用模型返回的像素坐標(biāo)而是約定一個歸一化坐標(biāo)體系適配不同屏幕尺寸。2.3 環(huán)境準(zhǔn)備與隱私前提本文示例基于 Xcode 15 和 iOS 17 環(huán)境Swift 版本為 5.x。雖然代碼用到了 iOS 17 才完善的一些 API但核心思路在 iOS 15 上也能實現(xiàn)。版本需要根據(jù)你的項目實際情況調(diào)整本文示例以常見環(huán)境為例重點演示配置思路。動手開發(fā)前有兩個隱私前提必須想清楚第一屏幕內(nèi)容極其敏感。無論是應(yīng)用內(nèi)截圖還是系統(tǒng)級屏幕錄制都必須在用戶知情的前提下進(jìn)行。應(yīng)用內(nèi)截圖只影響自己 App 范圍相對簡單系統(tǒng)級錄制會彈出系統(tǒng)級“正在共享屏幕”提示產(chǎn)品上要設(shè)計清晰的說明文案。第二教育類產(chǎn)品如果面向未成年人還要額外考慮數(shù)據(jù)最小化原則。能只上傳局部截圖就盡量不要整屏上傳能本地完成 OCR 就不要把原始截圖發(fā)給服務(wù)器。建議在客戶端完成視覺結(jié)構(gòu)化只把文本和坐標(biāo)發(fā)送給大模型從源頭減少隱私風(fēng)險。3. 屏幕內(nèi)容采集截圖還是屏幕錄制3.1 兩種主流方案對比在 iOS 上獲取屏幕內(nèi)容沒有真正意義上“萬能靜默截屏”的公共 API。系統(tǒng)對用戶隱私的保護(hù)很強(qiáng)開發(fā)者只能在系統(tǒng)允許的框架內(nèi)操作因此不同業(yè)務(wù)場景方案不同。第一種方案是應(yīng)用內(nèi)截圖。這種方案最穩(wěn)定也最容易實現(xiàn)。它只捕獲我們自己的 App 窗口內(nèi)容適合“AI 輔導(dǎo)我們自己的學(xué)習(xí)頁面”比如題庫、講義閱讀器、代碼練習(xí)器、表單填寫向?qū)?。?yōu)點是權(quán)限簡單無需額外配置描述文件只要 App 在前臺即可隨時截圖。缺點是無法捕獲其他 App 的內(nèi)容不能做跨應(yīng)用輔導(dǎo)。第二種方案是 ReplayKit Broadcast Upload Extension。這是 iOS 官方提供的屏幕共享錄制能力。用戶在控制中心或者 App 內(nèi)點擊“開始直播/共享屏幕”后系統(tǒng)會彈出提示然后系統(tǒng)把屏幕視頻幀通過擴(kuò)展傳遞給開發(fā)者。優(yōu)點是能捕獲整個設(shè)備屏幕或指定 App適合“AI 輔導(dǎo)用戶使用其他軟件”。缺點是交互鏈路復(fù)雜、權(quán)限提示明顯、性能開銷大而且擴(kuò)展進(jìn)程與主 App 是獨立進(jìn)程數(shù)據(jù)通信需要額外設(shè)計。3.2 方案一應(yīng)用內(nèi)截圖代碼實現(xiàn)應(yīng)用內(nèi)截圖最直接的方式是拿到當(dāng)前UIWindow利用drawHierarchy繪制到圖形上下文。這里給出一個可以在 SwiftUI 工程中復(fù)用的函數(shù)import UIKit func captureAppScreen() - UIImage? { // 獲取當(dāng)前活躍的 WindowScene 和 keyWindow guard let windowScene UIApplication.shared.connectedScenes .compactMap({ $0 as? UIWindowScene }) .first, let keyWindow windowScene.windows.first(where: { $0.isKeyWindow }) else { return nil } let format UIGraphicsImageRendererFormat() format.scale UIScreen.main.scale format.opaque false let renderer UIGraphicsImageRenderer( bounds: keyWindow.bounds, format: format ) return renderer.image { _ in keyWindow.drawHierarchy(in: keyWindow.bounds, afterScreenUpdates: true) } }這段代碼需要注意三點必須在主線程調(diào)用否則drawHierarchy可能繪制出空白內(nèi)容。afterScreenUpdates: true表示等屏幕內(nèi)容更新完成后再繪制適合捕獲最新 UI 狀態(tài)但如果調(diào)用非常頻繁會有一定性能損耗。如果界面包含SKScene、MTKView、AVPlayerLayer等獨立渲染層drawHierarchy不一定能捕獲到內(nèi)容需要額外處理或換成UIView快照。在 SwiftUI 中可以把它包裝成一個Buttonaction 或一個Timer驅(qū)動的采集器。截取到的 UIImage 后續(xù)會傳給視覺結(jié)構(gòu)化模塊。3.3 方案二ReplayKit Broadcast Upload Extension如果你確實需要捕獲其他 App 的屏幕只能選擇 ReplayKit 方案。整體流程如下首先在主 App 中為工程新增一個 Broadcast Upload Extension Target。這個擴(kuò)展本身并不負(fù)責(zé)展示任何 UI它只是接收系統(tǒng)傳入的屏幕視頻幀。Xcode 會自動生成SampleHandler.swift文件核心方法如下import ReplayKit class SampleHandler: RPBroadcastSampleHandler { override func broadcastStarted(withSetupInfo setupInfo: [String: NSObject]?) { // 用戶點擊開始共享后觸發(fā)這里可以通知主 App 開始接收 } override func broadcastPaused() { // 用戶暫停共享時觸發(fā) } override func broadcastResumed() { // 用戶恢復(fù)共享時觸發(fā) } override func broadcastFinished() { // 用戶結(jié)束共享時觸發(fā) // 記得清理共享容器中的臨時文件 } override func processSampleBuffer(_ sampleBuffer: CMSampleBuffer, with type: RPSampleBufferType) { // 系統(tǒng)不斷把屏幕/音頻/App 音頻樣本傳到這里 // 判斷 type .video 時從 sampleBuffer 中取出像素緩沖區(qū) guard type .video else { return } guard let pixelBuffer CMSampleBufferGetImageBuffer(sampleBuffer) else { return } // 將該幀轉(zhuǎn)成 JPEG 或?qū)懭牍蚕砦募偻ㄖ?App 讀取 // 注意擴(kuò)展進(jìn)程內(nèi)存受限不要無限制緩存幀 } }擴(kuò)展與主 App 是獨立進(jìn)程不能直接調(diào)用主 App 的單例或內(nèi)存變量。通常需要用 App Group 共享容器傳遞數(shù)據(jù)擴(kuò)展把視頻幀壓縮成 JPEG Data寫入UserDefaults(suiteName:)或臨時文件主 App 通過監(jiān)聽通知或輪詢讀取。考慮到擴(kuò)展內(nèi)存很小建議只保留最近 12 幀或者按需向擴(kuò)展發(fā)送“需要幀”的信號。使用這套方案時要明確告知用戶系統(tǒng)會顯示屏幕共享狀態(tài)。產(chǎn)品設(shè)計上不能把這種錄制偽裝成無感知后臺截屏這是蘋果審核的紅線也是用戶隱私的基本要求。3.4 權(quán)限狀態(tài)檢查無論哪種方案啟動采集前都應(yīng)該檢查權(quán)限狀態(tài)。ReplayKit 方案相對特殊因為系統(tǒng)沒有提供獨立的“屏幕錄制權(quán)限”檢查 API需要在調(diào)用相關(guān) API 時捕獲錯誤并通過RPBroadcastActivityViewController引導(dǎo)用戶完成授權(quán)。對于應(yīng)用內(nèi)截圖則不需要額外的系統(tǒng)權(quán)限。實際開發(fā)中更常見的是麥克風(fēng)權(quán)限和相冊權(quán)限這里不展開。需要強(qiáng)調(diào)的是無論使用哪種采集方案應(yīng)用的《隱私政策》里都應(yīng)當(dāng)如實說明屏幕內(nèi)容的用途、存儲方式、上傳策略和刪除機(jī)制尤其是教育類應(yīng)用涉及未成年人場景時必須格外謹(jǐn)慎。4. 視覺結(jié)構(gòu)化讓 AI 看懂屏幕坐標(biāo)4.1 Vision 框架 OCR 與元素檢測拿到 UIImage 之后下一步是把圖片轉(zhuǎn)成“文字 位置”的結(jié)構(gòu)化數(shù)據(jù)。iOS 原生自帶 Vision 框架可以離線完成 OCR延遲低且不產(chǎn)生網(wǎng)絡(luò)流量。下面是一個最小可用的 OCR 函數(shù)import Vision func recognizeText(in image: UIImage) - [VNRecognizedTextObservation] { guard let cgImage image.cgImage else { return [] } var observations: [VNRecognizedTextObservation] [] let request VNRecognizeTextRequest { request, error in guard error nil else { return } observations request.results as? [VNRecognizedTextObservation] ?? [] } request.recognitionLevel .accurate request.recognitionLanguages [zh-Hans, en-US] request.usesLanguageCorrection true let handler VNImageRequestHandler(cgImage: cgImage, options: [:]) try? handler.perform([request]) return observations }說明幾個細(xì)節(jié)recognitionLevel .accurate識別精度高但速度稍慢實時預(yù)覽場景可以改用.fast。recognitionLanguages根據(jù)目標(biāo)用戶調(diào)整。中文教育場景建議把zh-Hans放在第一位否則默認(rèn)模型對中文支持不夠穩(wěn)定。usesLanguageCorrection對英文單詞糾錯有幫助但對中文識別有時候會畫蛇添足需要實際測試后決定開關(guān)。遍歷結(jié)果時每個VNRecognizedTextObservation包含兩部分關(guān)鍵信息topCandidates(1)能拿到識別文本boundingBox能拿到歸一化坐標(biāo)。下面代碼演示如何提取for observation in observations { guard let candidate observation.topCandidates(1).first else { continue } let text candidate.string let box observation.boundingBox print(文本\(text)歸一化坐標(biāo)\(box)) }4.2 歸一化坐標(biāo)與屏幕坐標(biāo)互轉(zhuǎn)Vision 的boundingBox有一個非常經(jīng)典的坑坐標(biāo)系原點在左下角而 UIKit/SwiftUI 的原點在左上角。如果不做轉(zhuǎn)換畫出來的高亮框會上下顛倒。轉(zhuǎn)換公式如下// visionBox 是 CGRect取值范圍 0~1 // imageWidth / imageHeight 是原始圖片像素尺寸 // uiRect 是 UIKit 左上角坐標(biāo)系下的矩形 let uiX visionBox.minX * imageWidth let uiY (1 - visionBox.minY - visionBox.height) * imageHeight let uiWidth visionBox.width * imageWidth let uiHeight visionBox.height * imageHeight let uiRect CGRect(x: uiX, y: uiY, width: uiWidth, height: uiHeight)這里的核心是先把 Vision 的歸一化坐標(biāo)轉(zhuǎn)換為像素坐標(biāo)再做縱向翻轉(zhuǎn)。注意翻轉(zhuǎn)時不僅要翻minY還要減去矩形自身高度否則元素會向下偏移一個矩形高度。當(dāng)你把坐標(biāo)發(fā)給大模型時建議統(tǒng)一使用“歸一化坐標(biāo) 像素坐標(biāo)”雙份描述。給模型看的 JSON 里帶上歸一化坐標(biāo)[0.1, 0.2, 0.3, 0.15]便于模型理解相對位置渲染時再轉(zhuǎn)成像素坐標(biāo)避免因屏幕尺寸不同導(dǎo)致偏移。4.3 構(gòu)造 AI 可讀的視覺狀態(tài)描述大模型并不能直接理解一個矩形框和一段 OCR 文本之間的語義關(guān)系。為了讓模型“看懂屏幕”我們需要把 OCR 結(jié)果整理成結(jié)構(gòu)化 JSON。建議字段如下{ screen_size: { width: 1170, height: 2532 }, elements: [ { id: 0, type: text, content: 2x 3 7, box: [0.08, 0.31, 0.36, 0.08] }, { id: 1, type: input, content: , placeholder: 請輸入答案, box: [0.12, 0.42, 0.28, 0.06] }, { id: 2, type: button, content: 提交, box: [0.42, 0.51, 0.16, 0.06] } ] }關(guān)于type字段如果要做得簡單可以先用text統(tǒng)一標(biāo)注如果想更精確可以結(jié)合VNDetectRectanglesRequest檢測圖片中的按鈕、卡片、輸入框等矩形區(qū)域再通過坐標(biāo)重疊匹配判斷類型。不過這一步在最小可行性版本里可以省略先把文本元素做好就夠了。生成這段 JSON 的 Swift 代碼如下struct ScreenState: Codable { let screen_size: CGSizeProxy let elements: [ElementProxy] } struct ElementProxy: Codable { let id: Int let type: String let content: String let box: [CGFloat] } func buildScreenState(from observations: [VNRecognizedTextObservation], imageSize: CGSize) - ScreenState { var elements: [ElementProxy] [] for (index, obs) in observations.enumerated() { guard let text obs.topCandidates(1).first?.string else { continue } let box obs.boundingBox elements.append(ElementProxy( id: index, type: text, content: text, box: [box.minX, box.minY, box.width, box.height] )) } return ScreenState( screen_size: CGSizeProxy(width: imageSize.width, height: imageSize.height), elements: elements ) }注意示例中的CGSizeProxy和ElementProxy是為了方便 Codable 序列化而定義的簡單結(jié)構(gòu)體實際項目中可以按你的 JSON 規(guī)范調(diào)整。這一階段做完你手里的素材已經(jīng)足夠讓大模型做“基于坐標(biāo)的精確回答”了。5. 接入多模態(tài)大模型把“問題 屏幕狀態(tài)”交給 AI5.1 提示詞設(shè)計接入大模型時最常見的錯誤是直接把截圖 Base64 塞給模型然后期待它輸出精確坐標(biāo)。實際效果往往不理想模型對像素坐標(biāo)的感知不穩(wěn)定很容易出現(xiàn)“指著空白區(qū)域說話”的情況。更穩(wěn)妥的做法是讓模型基于結(jié)構(gòu)化 JSON 做推演再結(jié)合局部圖片提升理解。以“數(shù)學(xué)題目輔導(dǎo)”為例系統(tǒng)提示詞可以這樣設(shè)計你是屏幕輔助學(xué)習(xí)助手。用戶會提供當(dāng)前屏幕的結(jié)構(gòu)化元素列表 每個元素包含 id、type、content 和歸一化坐標(biāo) box。 你的任務(wù)是 1. 根據(jù)用戶問題分析屏幕中與問題相關(guān)的內(nèi)容。 2. 如果發(fā)現(xiàn)了錯誤或需要強(qiáng)調(diào)的位置必須引用對應(yīng)元素的 id。 3. 禁止編造屏幕上不存在的元素。 4. 輸出必須是 JSON字段為 - answer完整輔導(dǎo)文本 - highlights需要高亮的元素 id 數(shù)組或歸一化框數(shù)組 - next_actions建議用戶執(zhí)行的操作列表這段提示詞有三個關(guān)鍵設(shè)計一是“禁止編造元素”。AI 很容易順著用戶的話編造“右上角那個按鈕”即使屏幕上根本沒有。明確禁止之后模型會在找不到匹配元素時如實說“當(dāng)前屏幕中沒有找到相關(guān)內(nèi)容”而不是忽悠用戶。二是強(qiáng)制 JSON 輸出。后續(xù)代碼解析會方便非常多也容易做字段校驗。三是把“錯誤位置”和“下一步操作”分開。既滿足用戶“哪里錯了”的需求也滿足“接下來怎么操作”的指導(dǎo)性需求。5.2 調(diào)用接口與代碼示例以 OpenAI 兼容的 Chat Completions 接口為例下面給出 Swift 網(wǎng)絡(luò)請求的核心片段。這個示例目的是演示通用調(diào)用方式具體 URL、模型名、鑒權(quán)方式需要按你實際使用的服務(wù)調(diào)整import Foundation struct LLMRequest: Codable { let model: String let messages: [Message] let response_format: ResponseFormat? struct Message: Codable { let role: String let content: String } struct ResponseFormat: Codable { let type: String } } struct LLMResponse: Codable { let choices: [Choice] struct Choice: Codable { let message: Message } } func callLLM(screenStateJSON: String, userQuestion: String, apiKey: String, completion: escaping (ResultString, Error) - Void) { let url URL(string: https://api.example.com/v1/chat/completions)! var request URLRequest(url: url) request.httpMethod POST request.setValue(application/json, forHTTPHeaderField: Content-Type) request.setValue(Bearer \(apiKey), forHTTPHeaderField: Authorization) let systemPrompt 你是屏幕輔助學(xué)習(xí)助手。用戶會提供當(dāng)前屏幕的結(jié)構(gòu)化元素列表... let userContent 當(dāng)前屏幕狀態(tài) \(screenStateJSON) 用戶問題 \(userQuestion) let payload LLMRequest( model: your-model-name, messages: [ LLMRequest.Message(role: system, content: systemPrompt), LLMRequest.Message(role: user, content: userContent) ], response_format: LLMRequest.ResponseFormat(type: json_object) ) request.httpBody try? JSONEncoder().encode(payload) URLSession.shared.dataTask(with: request) { data, _, error in guard let data data else { completion(.failure(error ?? NSError(domain: LLMError, code: -1))) return } do { let response try JSONDecoder().decode(LLMResponse.self, from: data) let content response.choices.first?.message.content ?? completion(.success(content)) } catch { completion(.failure(error)) } }.resume() }這里有幾個需要注意的地方response_format字段不是所有模型都支持支持 JSON Output 的模型才能穩(wěn)定輸出合法 JSON。如果不支持就需要在提示詞里強(qiáng)調(diào)“只輸出 JSON不要多余解釋”并在解析時做容錯處理。生產(chǎn)環(huán)境不要把 API Key 寫在客戶端。正確做法是客戶端請求自己的服務(wù)端由服務(wù)端保存密鑰并轉(zhuǎn)發(fā)大模型請求避免密鑰泄露。如果模型允許視覺輸入可以把重要區(qū)域的截圖裁剪后作為圖片一并發(fā)送如果只發(fā)送結(jié)構(gòu)化 JSON則在真實圖表、復(fù)雜公式場景下理解能力會受限。最優(yōu)選擇是“結(jié)構(gòu)化 JSON 局部裁剪圖”一起送既控制 token 又提升準(zhǔn)確率。5.3 響應(yīng)解析與容錯模型輸出的 JSON 不一定嚴(yán)謹(jǐn)常見問題包括多了一個尾逗號、用單引號代替雙引號、在 JSON 前后混入解釋性文字。解析時要做好容錯。下面是一個解析示例使用JSONSerialization先做一次寬松解析失敗后再嘗試提取 JSON 片段func parseLLMResponse(_ content: String) - [String: Any]? { // 先直接嘗試解析 if let data content.data(using: .utf8), let json try? JSONSerialization.jsonObject(with: data) as? [String: Any] { return json } // 失敗后嘗試提取 {} 之間的內(nèi)容 if let start content.firstIndex(of: {), let end content.lastIndex(of: }), start end { let jsonString String(content[start...end]) if let data jsonString.data(using: .utf8), let json try? JSONSerialization.jsonObject(with: data) as? [String: Any] { return json } } return nil }解析完之后還需要對坐標(biāo)做合法性校驗。模型可能返回負(fù)坐標(biāo)、超過 1 的歸一化坐標(biāo)、或者與屏幕尺寸不匹配的像素坐標(biāo)。統(tǒng)一處理方式是只要坐標(biāo)值不在0...1范圍內(nèi)就丟棄對應(yīng)高亮或者回退到“該元素關(guān)聯(lián)的 OCR 框”。6. 實現(xiàn)“視覺精確”的結(jié)果渲染6.1 在截圖上繪制邊界框把模型返回的高亮元素 ID 映射回ScreenState.elements后可以拿到歸一化坐標(biāo)。最簡單可靠的渲染方式是直接在截圖上繪制邊界框然后展示給用戶。SwiftUI 中可以用Canvas完成struct HighlightOverlay: View { let image: UIImage let boxes: [CGRect] // 這里放轉(zhuǎn)換后的像素坐標(biāo)或者保存歸一化坐標(biāo)動態(tài)轉(zhuǎn)換 var body: some View { ZStack { Image(uiImage: image) .resizable() .scaledToFit() Canvas { context, size in for box in boxes { // 需要把像素坐標(biāo)按當(dāng)前視圖尺寸等比縮放 let scaleX size.width / image.size.width let scaleY size.height / image.size.height let rect CGRect( x: box.minX * scaleX, y: box.minY * scaleY, width: box.width * scaleX, height: box.height * scaleY ) let path Path(roundedRect: rect, cornerRadius: 12) context.stroke(path, with: .color(.orange), lineWidth: 4) context.fill(path, with: .color(.orange.opacity(0.15))) } } .allowsHitTesting(false) } } }建議用scaledToFit配合動態(tài)等比縮放而不是直接寫死尺寸這樣在不同 iPhone 上都能顯示正常。allowsHitTesting(false)保證覆蓋層不阻擋用戶的點擊操作。6.2 在實時覆蓋層中做高亮標(biāo)注如果產(chǎn)品形態(tài)是“實時輔導(dǎo)”比分說用戶一邊操作屏幕一邊接收指導(dǎo)那么可以創(chuàng)建一個獨立的透明 UIWindow 覆蓋在內(nèi)容層之上。這個 window 的windowLevel設(shè)置高于普通內(nèi)容但不遮擋系統(tǒng)狀態(tài)欄let overlayWindow UIWindow(windowScene: windowScene) overlayWindow.windowLevel .alert 1 overlayWindow.backgroundColor .clear overlayWindow.rootViewController UIHostingController( rootView: HighlightOverlay(image: currentFrame, boxes: boxes) ) overlayWindow.isHidden false使用覆蓋層時要注意兩點一是覆蓋層不該完全攔截觸摸事件。如果需要在高亮區(qū)域顯示可點擊的按鈕比如“點擊此處查看詳細(xì)解析”那么只讓按鈕區(qū)域響應(yīng)觸摸其他區(qū)域設(shè)置allowsHitTesting(false)。二是根據(jù)業(yè)務(wù)場景不要一直占滿全屏。長時間遮擋屏幕會影響用戶操作。合理的交互是AI 給出高亮后用戶點擊“完成”即自動消失或者高亮只保留 35 秒。6.3 點擊坐標(biāo)回傳與交互閉環(huán)“視覺精確”最有價值的地方是可以把 AI 的建議變成可點擊的入口。例如模型說“請點擊右上角的提交按鈕”客戶端如果能將歸一化坐標(biāo)映射到按鈕區(qū)域就可以在覆蓋層上畫一個“點擊”按鈕用戶點擊后觸發(fā)回調(diào)App 內(nèi)部執(zhí)行相應(yīng)跳轉(zhuǎn)或操作。但這里有一個 iOS 平臺邊界如果你的 App 要模擬點擊另一個 App 的界面iOS 官方?jīng)]有為普通 App 開放任意模擬觸摸的公共 API。所以一個更現(xiàn)實的方案是在自己的 App 內(nèi)部根據(jù)坐標(biāo)執(zhí)行內(nèi)部跳轉(zhuǎn)在輔導(dǎo)其他 App 的場景只做“高亮引導(dǎo) 用戶手動點擊”避免觸碰系統(tǒng)限制。換句話說視覺精確的最終落點不一定是“替你操作”而是“精確告訴你操作哪里”。從產(chǎn)品角度來看這種交互反而更容易獲得用戶信任。7. 常見問題與排查思路開發(fā)過程中最大的時間消耗往往來自權(quán)限、坐標(biāo)系和擴(kuò)展進(jìn)程通信。下面整理一張高頻問題表并逐一展開說明。問題現(xiàn)象常見原因解決思路drawHierarchy 截圖為空白非主線程調(diào)用、圖片尺寸為 0確保主線程執(zhí)行檢查 window.boundsVision OCR 識別中文不準(zhǔn)確未設(shè)置中文識別語言設(shè)置recognitionLanguages [zh-Hans, en-US]高亮框上下顛倒或偏移Vision 坐標(biāo)系與 UIKit 不一致按公式翻轉(zhuǎn) Y 軸并減去高度模型返回坐標(biāo)越界模型幻覺或歸一化理解錯誤解析后校驗 0...1 范圍非法值丟棄Broadcast Extension 無法啟動簽名配置或 App Group 配置錯誤檢查 entitlement確保主 App 與擴(kuò)展共享 Group擴(kuò)展與主 App 數(shù)據(jù)不同步進(jìn)程間通信時序問題使用 Darwin Notification App Group 文件傳遞覆蓋層無法顯示windowLevel 設(shè)置過低使用.alert 1層級下面挑幾個最常見的展開講。7.1 Broadcast Extension 無法拉起表現(xiàn)在主 App 中跳轉(zhuǎn)RPBroadcastActivityViewController后用戶選擇“開始直播”但SampleHandler.broadcastStarted一直沒有被調(diào)用。排查步驟建議按順序執(zhí)行確認(rèn) Broadcast Upload Extension 的 Bundle Identifier 是否正確并且 Extension 所屬 Target 與主 App 在同一個 App Group 中。檢查 Extension 的 Deployment Target確保不低于主 App 的最低版本。在 Extension 的broadcastFinished里加日志確認(rèn)是否有被動結(jié)束。用真機(jī)測試。模擬器對 ReplayKit 支持有限很多場景跑不通。常見根因是 Extension 沒有正確簽名或者主 App 的NSExtension配置缺少RPBroadcastProcessMode字段。7.2 高亮框位置總是偏上或偏下表現(xiàn)模型返回的坐標(biāo)看起來對但畫出來的高亮框老是對不準(zhǔn)文字。首先檢查 Vision 坐標(biāo)轉(zhuǎn)換是否遺漏了高度。很多初學(xué)者只做了一次翻轉(zhuǎn)y 1 - minY忘了減去矩形高度。正確的轉(zhuǎn)換公式是let y (1 - visionBox.minY - visionBox.height) * imageHeight其次檢查圖片裁剪邏輯。如果截圖時取了屏幕一部分區(qū)域但 OCR 用的是整張圖片坐標(biāo)比例就會被拉伸。規(guī)范做法是截圖、OCR、渲染三者的參考圖片尺寸保持一致。7.3 模型總在“編造屏幕元素”表現(xiàn)屏幕上明明沒有“重置按鈕”模型卻一本正經(jīng)地分析按鈕位置。這類問題本質(zhì)上是提示詞對模型的約束不夠。解決辦法可以從三個方向同時入手在系統(tǒng)提示詞中明確添加“只能引用給定 elements 中存在的 id禁止描述不存在的元素”。在用戶消息中追加一句判斷規(guī)則“如果沒有找到相關(guān)元素請輸出空的高亮數(shù)組并解釋原因?！痹诤蠖嗽黾有ｒ灧?wù)當(dāng)模型返回的元素 id 不在ScreenState.elements中時自動丟棄該高亮并追加一條修復(fù)請求。7.4 屏幕錄制內(nèi)存持續(xù)增長ReplayKit 擴(kuò)展在較老的機(jī)型上容易出現(xiàn)內(nèi)存吃緊因為系統(tǒng)不斷把視頻幀傳給擴(kuò)展。解決思路是不要保存所有幀只保留最新一幀或者設(shè)定一個時間間隔例如每 2 秒采集一幀或只在用戶點擊“暫停”時采集。另外幀轉(zhuǎn) JPEG 時注意使用UIImage的壓縮參數(shù)控制體積if let data image.jpegData(compressionQuality: 0.6) { // 寫入共享容器 }一般 0.50.7 的壓縮質(zhì)量已經(jīng)足夠 OCR 使用沒必要用 1.0 無損壓縮。8. 最佳實踐與工程建議8.1 隱私合規(guī)是一條硬邊界做這類 AI 教育應(yīng)用隱私不是可選項而是第一優(yōu)先級。屏幕截圖可能包含賬號信息、個人信息、聊天記錄甚至未成年人面部信息。工程上我建議至少做到以下幾點默認(rèn)不上傳原始截圖。優(yōu)先在端側(cè)完成 OCR 和元素檢測只把文本、坐標(biāo)、屏幕尺寸發(fā)給模型。必須上傳截圖時對圖片做脫敏處理。比如先裁剪問題區(qū)域再使用系統(tǒng)隱私遮罩或手動打碼。提供“單次授權(quán)”機(jī)制。用戶每次發(fā)起輔導(dǎo)時再觸發(fā)采集而不是進(jìn)入 App 就自動采集。服務(wù)端保存的日志不要包含完整截圖只保留結(jié)構(gòu)化 JSON 和模型結(jié)果并給用戶提供一鍵清除學(xué)習(xí)記錄的能力。8.2 降低大模型成本與延遲視覺結(jié)構(gòu)化之后發(fā)給模型的文本已經(jīng)比原始截圖小很多但多輪對話中歷史上下文仍會越來越大。建議采用以下策略只保留最近 35 輪對話摘要不保存完整歷史。每次發(fā)送屏幕狀態(tài)時只發(fā)送用戶問題關(guān)聯(lián)區(qū)域附近的元素。例如問題提到“公式”就只保留 OCR 文本框中包含數(shù)學(xué)符號的元素過濾掉狀態(tài)欄、底部 Tab 欄等無關(guān)內(nèi)容。圖片傳給模型前先裁剪按元素框外擴(kuò)一定像素而不是發(fā)整張截圖。8.3 不要讓模型直接暴露給客戶端真實項目中客戶端不應(yīng)該直接持有大模型 API Key。正確架構(gòu)是iOS 客戶端 → 自己的后端服務(wù) → 大模型服務(wù)。后端可以承擔(dān)幾項關(guān)鍵職責(zé)統(tǒng)一封裝不同模型提供商的接口切換模型時客戶端無需改動。對模型輸入做脫敏和內(nèi)容安全檢測。對模型輸出做 JSON Schema 校驗攔截非法坐標(biāo)。記錄每次輔導(dǎo)的輸入輸出用于評估模型質(zhì)量和后續(xù)微調(diào)數(shù)據(jù)集建設(shè)。8.4 模型輸出的坐標(biāo)必須做“合法范圍校驗”模型輸出的highlights數(shù)組可能在理論上完全合法但在現(xiàn)實中指向空白區(qū)域。建議在服務(wù)端增加一層校驗函數(shù)func validateHighlight(_ box: [CGFloat], elements: [ElementProxy]) - Bool { guard box.count 4 else { return false } for value in box { guard value 0, value 1 else { return false } } // 可選檢查是否與任一 OCR 元素框重疊 let highlightRect CGRect(x: box[0], y: box[1], width: box[2], height: box[3]) for element in elements { let elementRect CGRect(x: element.box[0], y: element.box[1], width: element.box[2], height: element.box[3]) if highlightRect.intersects(elementRect) { return true } } return false }如果沒有任何重疊就直接把該高亮判斷為無效避免用戶看到 AI 指向空白區(qū)域。8.5 建立離線回歸數(shù)據(jù)集視覺精確類功能最怕“調(diào)一次壞一次”。改了一版提示詞可能某類題目更準(zhǔn)了但另一類屏幕的誤報率上升了。建議從第一天起就建立離線回歸數(shù)據(jù)集收集真實用戶授權(quán)的屏幕截圖和問題記錄。每一條樣本標(biāo)注正確高亮元素 id、正確回答文本、正確操作步驟。每次修改提示詞或模型后先跑一遍離線數(shù)據(jù)集對比高亮命中和文本準(zhǔn)確率再發(fā)布到線上。這一步聽起來重但對教育類產(chǎn)品非常值得。沒有回歸數(shù)據(jù)集的 AI 功能后期維護(hù)會非常痛苦。9. 總結(jié)與下一步學(xué)習(xí)路線回到最開始提到的 Show HN 項目Visually Precise AI Tutoring on iOS。這類產(chǎn)品的技術(shù)骨架本質(zhì)上就是本文這條鏈路屏幕采集、視覺結(jié)構(gòu)化、大模型推理、坐標(biāo)渲染。它不是單一技術(shù)點而是多個系統(tǒng)能力的組合。真正決定體驗上限的不是某一個模型有多強(qiáng)而是你能不能把“屏幕狀態(tài)”準(zhǔn)確轉(zhuǎn)成模型可消費、又能映射回屏幕坐標(biāo)的結(jié)構(gòu)化數(shù)據(jù)。如果你想從零開始嘗試我的建議是先放棄實時屏幕錄制做一個最小閉環(huán)在你自己 App 內(nèi)截屏 → Vision OCR → 生成 JSON → 調(diào)用大模型 → 在截圖上畫框。這條鏈路兩天左右就能跑通能讓你快速感受到“視覺精確反饋”和“純文本回答”的差異。跑通之后再逐步加入 Broadcast Extension、多輪對話、局部圖片傳輸和線上回歸評測每一步都有明確的可驗證標(biāo)準(zhǔn)。過程中遇到問題優(yōu)先從兩個角度排查一是權(quán)限鏈路有沒有完整走通二是坐標(biāo)系到底有沒有翻轉(zhuǎn)正確。這兩類問題占據(jù)了我個人在同類項目中超過一半的調(diào)試時間。如果你正在 iOS 上做 AI 輔導(dǎo)或智能操作引導(dǎo)歡迎把本文收藏起來等真正動手時對照著配置和排錯能少走不少彎路。