1. 背景与问题AI 辅导工具为什么普遍“不好用”一个学生在写作业时对着数学题发呆他掏出手机对着题目拍了一张照片AI 对话框弹出给出了一段文字讲解。你仔细看会发现AI 确实把公式和数字识对了但它讲解时引用的“第一行第二个常数项”这个位置用户在自家照片上根本找不到。传统 AI 辅导工具最大的问题不是模型不够聪明而是它无法精确指向图片中的某个具体位置。“Show HN: Visually Precise AI Tutoring on iOS”这个项目之所以值得关注正是因为它把“视觉精确”作为核心卖点而不仅仅是“能看图回答”。它对标的痛点非常真实学生拍下一道几何题AI 知道了题目内容还不够学生真正需要的是一步步的指导比如“在这条辅助线上方做垂线”“这个三角形标红的地方是直角”。要做到这一点AI 必须理解图像中的空间关系并且把讲解和画面上的区域一一对应起来。对于 iOS 开发者和 AI 应用工程师来说这个产品的价值不只是“又一个 AI 教育应用”它展示了一条可以复用的技术路径如何把多模态模型的图像理解能力转化为用户在真实界面上可感知的、视觉精确的辅导体验。这意味着对图片区域定位、OCR 识别、坐标映射、上下文对话和流式输出都有较高要求。本文会从产品逻辑、核心概念、技术选型、架构流程、代码实现、效果验证和工程实践几个角度完整拆解“视觉精确 AI 辅导”在 iOS 端是怎么落地的。如果你正在做 AI 教育类应用、拍照答题类工具或者对 iOS 端多模态 AI 应用开发感兴趣这篇文章值得读完。2. 核心概念视觉精确 AI 辅导到底在解决什么2.1 从“能看懂”到“能指给你看”普通 AI 识图是把图片当成上下文塞给模型让模型读题并生成文字。但“视觉精确”意味着另外三件事模型能够定位图像中一个很小的区域比如一个分式的分子部分、一条辅助线、一个化学式中的某个官能团。应用能把模型输出的定位信息映射回原始图片用高亮框、箭头、编号等方式渲染出来。讲解的每一句话都能和画面中的某个位置建立一一对应关系而不是笼统地说“这个式子里”。2.2 定位能力的技术本质这种定位能力源于多模态大模型的视觉理解能力。以 OpenAI 的 GPT-4o 或开源的多模态模型为例它们可以把图像切分为视觉块vision patch并将像素语义映射到文本 token 的空间中。当你问“图中第二条不等式的左边是什么”时模型需要在图像嵌入和文本指令之间建立关联。这已经不是简单的 OCR光学字符识别而是理解版面结构后的视觉推理。但模型本身并不天然知道屏幕分辨率也不懂 iOS 的坐标系。所以从“模型内部的视觉理解”到“用户屏幕上出现一个准确的高亮框”中间还隔着坐标归一化、坐标映射、不同屏幕比例适配、标注渲染等工程问题。2.3 与传统 OCR 规则引擎的对比传统做法是先用 OCR 识别出图片上的文字和公式再把这些纯文本交给 NLP 模型处理。这种方案在印刷体题目上表现尚可但一旦遇到手写字、彩色几何图、图形与文字混排时识别结果就会漏项、错位而且完全丢失了空间信息。对比维度传统 OCR NLP多模态视觉精确方案输入类型先转文本再理解原图直接理解空间位置一次性丢失可精确定位手写题识别弱较强取决于模型几何图形理解几乎不支持支持工程复杂度低中等偏高体验上限低高多模态方案并非没有缺点它需要更长的推理时间、更高的模型调用成本但是对教育场景来说体验上的提升是决定性的。学生需要的不是“看一遍答案”而是被引导着理解每一步为什么这么做这种引导必须在画面中有清晰的指向。2.4 视觉精确的三个层级在实际工程实现中可以按难度把视觉精确分成三个层级第一层是区域识别模型能判断图片里的哪一块是题干、哪一块是学生写的草稿。第二层是目标定位模型能对某个公式、某个图形、某条线输出归一化坐标。第三层是步骤级关联模型在生成每一步讲解时同时返回这一步对应的画面区域坐标每讲一步画面上就高亮一处。一个真正好用的 AI 辅导工具需要做到第三层。本文后面给出的代码示例就是围绕“步骤级关联”这个目标来设计的。3. 环境准备与前置条件视觉精确 AI 辅导应用涉及客户端、服务端和模型三层。在动手之前需要确认基本的技术栈。本文以 iOS 原生应用为例后端方案可以采用轻量级服务或直接调用模型 API。版本信息请以实际项目为准这里重点演示通用实现思路。3.1 客户端环境macOS 系统Xcode 15 及以上。Swift 5.9 或 Swift 6SwiftUI 作为 UI 框架。iOS 16 系统版本原因是后续要使用 PhotosUI 的PhotosPicker和PencilKit的CanvasView。真机调试更利于验证拍照、相册权限、手写标注和原图渲染效果。模拟器能跑通大部分流程但相机功能需要真机。3.2 服务端与模型环境Python 3.10FastAPI 或 Flask 均可。多模态大模型 API推荐使用 OpenAI-compatible 接口gpt-4o 等视觉模型或国内厂商提供的视觉接口。不同厂商的接口差异主要在 base_url、model 名称和鉴权方式请求结构大致相同。图片传输建议使用 Base64 编码单张图片压缩到 1MB 以内避免超时。需要准备 API Key通过环境变量注入不要硬编码到代码里。3.3 关键技术依赖iOS 端PhotosUI、PencilKit、VisionOCR 辅助、URLSession。后端FastAPI、Pillow、OpenAI SDK 或 requests。4. 核心流程拆解从拍照到步骤级讲解先画出一条完整的数据流后续代码都是围绕这条链路实现的。4.1 完整数据流选图用户从相册选择题目图片或直接用相机拍照。裁剪与预处理用户可以用 PencilKit 圈选题目区域应用裁剪出题目局部图对图片做必要的亮度、对比度校正。视觉解析服务端把题目局部图发送给多模态模型附加系统提示词要求模型返回严格的 JSON包含题干、考点、解题步骤和每一步的坐标区域。坐标映射客户端解析 JSON将归一化坐标映射回原图的像素坐标适配不同屏幕尺寸。标注渲染在原始图片上叠加高亮框、序号和箭头配合分步讲解文字渲染给学生。深度追问学生可以对某一步继续提问应用把原图、上一步答案和追问内容一起发送给模型保证上下文连续。4.2 为什么需要“先裁剪再识别”如果直接把整张照片送给多模态模型会出现两个问题公摊面积太大课桌上除了题目还有笔袋、橡皮、其他纸张模型容易分散注意力。坐标不精确模型输出的坐标是按完整图片归一化的一旦画面中存在无关区域模型的定位就不可靠。PencilKit 的圈选交互可以让用户主动告诉你“题目在这里”这既提高了识别准确率也天然解决了隐私问题——不上传整张照片只上传圈选区域。这是体验和隐私双赢的设计。4.3 为什么需要“返回结构化 JSON”直接让模型生成自然语言讲解当然可以但客户端解析困难。更好的方式是约束模型返回固定 JSON 结构例如{ summary: 这道题考察一元二次方程的判别式, steps: [ {index: 1, content: 先计算判别式 b²-4ac, bbox: [0.1, 0.2, 0.5, 0.35]}, {index: 2, content: 判别式大于零说明有两个不等实根, bbox: [0.1, 0.4, 0.5, 0.6]} ] }这里的 bbox 是归一化坐标格式为 [x_min, y_min, x_max, y_max]取值范围在 0 到 1 之间。归一化的好处是不管图片尺寸是多少客户端都能换算成实际的屏幕坐标。4.4 坐标映射与渲染拿到 bbox 后客户端需要把它渲染到用户看到的原图上。关键点在于用户展示的 image view 大小并不等于原图实际尺寸。所以需要把归一化坐标先换算成原图像素坐标再根据 image view 的显示方式aspect fit 或 aspect fill换算成视图坐标。这里用 aspect fit 展示时图片两侧会出现留白也需要参与换算。这一部分非常容易出现偏移原因就是没有分清“原图像素坐标”和“视图坐标”两套体系。5. 完整示例与代码实现下面按客户端和服务端两部分给出核心代码你可以直接照着搭建一个最小可运行版本。5.1 iOS 客户端选择题目图片在 SwiftUI 中使用 PhotosUI 的 PhotosPicker 选择图片是常规做法。注意需要添加相册权限说明到 Info.plist。import SwiftUI import PhotosUI struct PickingImageView: View { State private var selectedItem: PhotosPickerItem? State private var selectedImage: UIImage? var body: some View { VStack(spacing: 20) { if let selectedImage { Image(uiImage: selectedImage) .resizable() .scaledToFit() .frame(maxHeight: 400) } else { Rectangle() .fill(Color.secondary.opacity(0.2)) .frame(height: 300) .overlay(Text(选择题目图片)) } PhotosPicker(selection: $selectedItem, matching: .images) { Label(从相册选择题目, systemImage: photo.on.rectangle) } .onChange(of: selectedItem) { _, newItem in Task { if let data try? await newItem?.loadTransferable(type: Data.self), let image UIImage(data: data) { selectedImage image } } } } .padding() } }Info.plist 中需要加入相册只读权限描述keyNSPhotoLibraryUsageDescription/key string需要访问相册以选择你要问的题目图片/string这里只在用户主动选择图片时读取不进行后台批量访问符合最小权限原则。5.2 iOS 客户端PencilKit 圈选题目区域PencilKit 自带的 PKCanvasView 可以非常自然地让用户用手指或 Apple Pencil 圈选区域。这里提供裁剪功能用户画完圈选路径后应用根据画笔轨迹的 bounding box 裁剪原图。import SwiftUI import PencilKit struct AnnotationCanvas: UIViewRepresentable { Binding var canvasView: PKCanvasView func makeUIView(context: Context) - PKCanvasView { canvasView.drawingPolicy .default canvasView.tool PKInkingTool(.pen, color: .systemYellow, width: 12) canvasView.backgroundColor .clear return canvasView } func updateUIView(_ uiView: PKCanvasView, context: Context) {} } struct CroppingView: View { let originalImage: UIImage State private var canvasView PKCanvasView() State private var croppedImage: UIImage? var body: some View { VStack(spacing: 16) { ZStack { Image(uiImage: originalImage) .resizable() .scaledToFit() AnnotationCanvas(canvasView: $canvasView) } .frame(maxHeight: 400) Button(裁剪圈选区域) { cropByDrawingBoundingBox() } if let croppedImage { Image(uiImage: croppedImage) .resizable() .scaledToFit() .frame(height: 200) } } .padding() } private func cropByDrawingBoundingBox() { let drawingBounds canvasView.drawing.bounds guard drawingBounds.width 1, drawingBounds.height 1 else { return } // 注意这里需要将 canvas 坐标换算为原图坐标 // 示例省略了 scale 换算实际项目中必须根据图片和画布比例转换 let scale originalImage.size.width / canvasView.bounds.width let scaledRect CGRect( x: drawingBounds.origin.x * scale, y: drawingBounds.origin.y * scale, width: drawingBounds.width * scale, height: drawingBounds.height * scale ) if let cropped originalImage.cgImage?.cropping(to: scaledRect) { croppedImage UIImage(cgImage: cropped) } } }这段示例代码没有做完整的坐标换算但已经给出了核心思路PencilKit 的 bounds 是基于画布坐标的必须通过 scale 换算到原图坐标否则裁出来的区域会偏掉。实际项目里还要考虑画布和图片的宽高比差异。5.3 服务端接收图片并调用多模态模型服务端用 FastAPI 提供一个/api/tutor接口接收 Base64 图片调用多模态模型返回结构化 JSON。import base64 import json import os from fastapi import FastAPI, HTTPException from pydantic import BaseModel from openai import OpenAI app FastAPI() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) class TutorRequest(BaseModel): image_base64: str question: str 请讲解这道题 history: list[dict] | None None SYSTEM_PROMPT 你是一个视觉精确的AI辅导老师。你会收到一张题目图片。 请按以下要求输出JSON不要输出markdown代码块不要输出任何其他内容。 { summary: 题目主要考察的知识点, steps: [ { index: 1, content: 这一步做了什么为什么这么做, bbox: [x_min, y_min, x_max, y_max] } ] } 要求 1. bbox是归一化坐标范围是0到1。 2. 每一步必须给出对应的图片区域坐标。 3. 坐标必须严格对应图上内容所在的区域。 4. 步骤控制在3到8步。 5. 如果无法定位bbox返回当前图上可见的整体区域。 app.post(/api/tutor) async def tutor(req: TutorRequest): image_bytes base64.b64decode(req.image_base64) # 生产环境建议先限制图片大小避免请求体过大 image_data_url fdata:image/jpeg;base64,{req.image_base64} messages [ {role: system, content: SYSTEM_PROMPT}, ] if req.history: messages.extend(req.history) messages.append({ role: user, content: [ {type: text, text: req.question}, {type: image_url, image_url: {url: image_data_url}}, ], }) try: response client.chat.completions.create( modelos.getenv(MODEL_NAME, gpt-4o), messagesmessages, temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content return json.loads(content) except Exception as e: raise HTTPException(status_code500, detailf模型调用失败: {str(e)})history字段用于携带上下文实现多轮追问。response_format{type: json_object}能确保模型返回合法 JSON这在客户端解析时能省掉大量防御性代码。5.4 iOS 客户端调用服务端并渲染标注客户端把裁剪后的图片转成 Base64调用后端接口再解析返回的 JSON。这里给出核心网络请求与解码方法。import UIKit struct TutorStep: Codable, Identifiable { let id UUID() let index: Int let content: String let bbox: [CGFloat] } struct TutorResponse: Codable { let summary: String let steps: [TutorStep] } func requestTutor(image: UIImage, question: String 请讲解这道题) async throws - TutorResponse { guard let imageData image.jpegData(compressionQuality: 0.7) else { throw fatalError(图片压缩失败) } let base64 imageData.base64EncodedString() var request URLRequest(url: URL(string: http://localhost:8000/api/tutor)!) request.httpMethod POST request.setValue(application/json, forHTTPHeaderField: Content-Type) let body: [String: Any] [ image_base64: base64, question: question, history: [] ] request.httpBody try JSONSerialization.data(withJSONObject: body) let (data, _) try await URLSession.shared.data(for: request) let result try JSONDecoder().decode(TutorResponse.self, from: data) return result }坐标换算是在渲染标注时最容易出错的地方。下面这段代码把归一化坐标映射到实际显示的 ImageView 上核心思路是先算图片在 view 中的实际显示 frame再把归一化坐标换算为 view 上的 point。func normalizedRectToViewRect(normRect: CGRect, imageSize: CGSize, viewSize: CGSize) - CGRect { // 按 aspect fit 原则先算出图片在 view 中的显示区域 let imageAspect imageSize.width / imageSize.height let viewAspect viewSize.width / viewSize.height var displayRect CGRect(origin: .zero, size: viewSize) if imageAspect viewAspect { // 图片宽左右撑满上下留白 let newHeight viewSize.width / imageAspect displayRect.size.height newHeight displayRect.origin.y (viewSize.height - newHeight) / 2 } else { // 图片高上下撑满左右留白 let newWidth viewSize.height * imageAspect displayRect.size.width newWidth displayRect.origin.x (viewSize.width - newWidth) / 2 } return CGRect( x: displayRect.origin.x normRect.minX * displayRect.width, y: displayRect.origin.y normRect.minY * displayRect.height, width: normRect.width * displayRect.width, height: normRect.height * displayRect.height ) }这个换算方法值得反复核对。很多标注偏移问题都源于此尤其是图片不是正方形、view 不是正方形、用 ScrollView 缩放图片这三种场景。5.5 标注渲染视图拿到换算后的坐标后用 SwiftUI 的 overlay 渲染高亮框和序号即可。这里示范了一个叠加标注层的视图容器。import SwiftUI struct StepOverlayView: View { let image: UIImage let steps: [TutorStep] var body: some View { GeometryReader { geometry in Image(uiImage: image) .resizable() .scaledToFit() .overlay( ForEach(steps) { step in let normRect CGRect( x: step.bbox[0], y: step.bbox[1], width: step.bbox[2] - step.bbox[0], height: step.bbox[3] - step.bbox[1] ) let viewRect normalizedRectToViewRect( normRect: normRect, imageSize: image.size, viewSize: geometry.size ) ZStack(alignment: .topLeading) { RoundedRectangle(cornerRadius: 6) .stroke(Color.orange, lineWidth: 3) .frame(width: viewRect.width, height: viewRect.height) .position(x: viewRect.midX, y: viewRect.midY) Text(\(step.index)) .font(.caption.bold()) .foregroundColor(.white) .padding(6) .background(Circle().fill(Color.orange)) .position(x: viewRect.minX, y: viewRect.minY) } } ) } } }高亮框的呈现需要配合分步讲解区。通常的 UI 布局是上半部分是可缩放原图加标注下半部分是步骤列表。点击某一步对应的标注框应放大或闪烁。6. 运行结果与效果验证搭好客户端和服务端后端到端验证的路径如下。6.1 启动服务端export OPENAI_API_KEYyour_api_key_here export OPENAI_BASE_URLhttps://api.openai.com/v1 export MODEL_NAMEgpt-4o uvicorn main:app --host 0.0.0.0 --port 8000 --reload出现Uvicorn running on http://0.0.0.0:8000即表示服务正常。6.2 使用 curl 快速验证接口准备一张题目图片用 Python 转 Base64 后发送请求import base64 import requests with open(math_question.png, rb) as f: image_base64 base64.b64encode(f.read()).decode() resp requests.post(http://localhost:8000/api/tutor, json{ image_base64: image_base64, question: 请详细讲解这道题 }) print(resp.status_code) print(resp.json())预期输出是一个 JSON包含 summary 和 steps 数组每一步都带 bbox。如果返回的 bbox 不是 4 个 0 到 1 之间的浮点数说明模型输出格式没有严格遵循提示词需要调整 system prompt 或增加解析校验。6.3 客户端验证清单在模拟器或真机上验证时建议按以下顺序排查相册选图是否成功。PencilKit 圈选后裁剪区域是否与原题吻合。网络请求是否成功能否拿到 JSON。标注框是否准确覆盖题目中的对应区域。最容易出现的现象是“模型讲得对但框偏了”。这基本可以断定是坐标换算链路出了问题优先检查 5.4 中的normalizedRectToViewRect方法和 PencilKit 裁剪时的 scale 换算不要急着怀疑模型能力。另一个常见现象是“整个图都识别了但框是整个图”——这说明模型的 step 分割能力没有生效需要调整提示词让模型更聚焦于步骤级区域而不是整张图的全局定位。6.4 如何判断视觉精确度合格简单做法是人工查看标注框与原图的覆盖情况框是否包含对应的公式或图形是否明显过大或过小。严格做法是准备一个小规模测试集对每一步标注与目标区域算 IoU交并比。IoU 在 0.7 以上可以认为定位基本可用。这个验证集不需要太大50 道典型题目就能发现大部分坐标偏移问题。7. 常见问题与排查思路视觉精确 AI 辅导应用的坑主要集中在模型输出、坐标换算、网络耗时和权限处理上。下面把常见问题整理成排查表。问题现象可能原因排查方式解决方案模型返回的 JSON 解析失败模型没有严格输出 JSON查看服务端原始返回内容使用 response_format 强制 JSON或增加后处理解析逻辑标注框位置偏移坐标系换算错误打印归一化框、原图尺寸、view 尺寸统一使用归一化坐标到 view 坐标的换算函数PencilKit 裁剪结果偏上偏左画布与图片比例不一致在裁剪前打印 canvasView.bounds 和原图尺寸先计算两者的 scale 和 offset再做 cropping模型对整张图片作答而不是对圈选区域发送给模型的图片没有裁剪成功检查实际发给 api 的图片打印图片尺寸修复裁剪逻辑或直接上传圈选后的 UIImage步骤 bbox 全是 [0,0,1,1]模型没有捕捉到局部区域查看原始图片复杂度调整提示词在提示词中强调“必须根据内容实际所在位置定位”识别速度太慢用户等待久图片过大模型推理耗时长检查 Base64 图片大小和请求耗时压缩图片、限制最大边长、使用流式输出或异步任务相册权限弹窗没有出现Info.plist 缺少权限描述检查 Info.plist 配置添加 NSPhotoLibraryUsageDescription真机上图片加载慢原图分辨率过大检查选中图片的内存占用用 ImageIO 做缩略图处理不要直接使用原图7.1 模型偶发幻觉的兜底方案即使是强视觉模型也偶发出现“识别错误但自信讲解”的情况。在产品中不能完全回避幻觉只能通过工程手段降低影响。推荐两层防线第一是在提示词里加入“如果你看不清某个区域直接说无法识别不要编造”。第二是客户端增加一个“标记错误”按钮把用户反馈和原始图片异步记录到日志系统定期筛选高频错误题目类型针对性地做提示词优化或者对特定题型引入专用 OCR 前置处理。7.2 坐标偏移的调试技巧坐标换算的调试建议在开发阶段先不要跳过。在生成标注框的同时把归一化坐标、原图尺寸、view 尺寸全部打印出来肉眼对比数据。还可以做一个调试模式把归一化坐标直接画在 UIImage 上然后保存到相册。这样定位问题时就分清了“模型返回的坐标就不对”和“客户端渲染坐标时算错”两种情况。8. 最佳实践与工程建议视觉精确 AI 辅导应用看起来只是“调用一下多模态 API”但要真正做成一个能上线、能稳定运行的产品还需要考虑以下工程问题。8.1 隐私保护与数据最小化教育场景涉及未成年人照片和作业信息隐私是产品能否长期运营的生命线。工程上至少要做到上传前默认压缩图片不把原始大图直接发送给模型服务。只上传用户圈选后的题目区域而不是整张相册照片。服务端日志中不记录完整图片只记录图片哈希和请求时间。模型服务商选择的评估维度应包含数据留存政策优先选择承诺不持久化用户图片的厂商。8.2 成本控制与缓存策略多模态模型调用成本比纯文本高出不少。同样一张图被用户翻来覆去地追问如果每次都重新调用模型成本压力很大。推荐的降本方式是对图片内容做感知哈希相同题目图片在短时间内直接复用之前的解析结果。分级模型简单题目先用轻量模型识别置信度低再升级到强模型。控制输入图片分辨率比如统一到 1024 或 1536 像素过大的图片反而可能引入噪点。8.3 用户反馈闭环AI 辅导的“正确性”只有真实用户能验证。建议从第一天就埋点记录哪道题被标记为“讲解看不懂”、哪个步骤用户点击了“继续追问”、哪类题目用户跳出了应用。这些信号比模型评估分数更能反映产品的真实教学质量。8.4 多模态模型选型考量如果做中文数理化教育国内模型的数学推理能力可能更匹配。选择时要重点评估三个维度定位精度能否在复杂图的局部区域输出可用 bbox。步骤可解释性生成的分步讲解是否符合教学逻辑而不是“一步跳到底”。中文表达和学科术语尤其是几何定理、化学方程式的命名是否符合教材表达。可以在测试集上跑一个简单的三类指标题目理解准确率、步骤合理性打分、bbox 定位 IoU。用这三个指标横向比较不同厂商的模型会比只看官方榜单更有参考价值。8.5 离线与弱网体验iOS 教育应用经常在教室、地铁等网络不稳定的场景下使用。虽然大模型推理很难完全离线但可以做三层优化第一层把 UI 交互、裁剪、图片预加载全部本地化网络断开时不至于白屏。第二层增加请求队列弱网时自动重试而不是直接报错。第三层对常见题型的模板、定理、公式等静态知识做本地缓存部分通用讲解可以不依赖网络。8.6 测试集与回归验证模型升级、提示词替换、客户端改版都可能让原本好用的功能突然失效。教育类产品尤其不能接受“昨天还能讲对的题今天错了”。建议维护一个精选回归测试集包含小学数学应用题、初中几何证明题、高中函数题。手写体作业照片和打印体题目。多步骤计算题和概念辨析题。图片上有无关干扰物的实际场景。每次模型或提示词变更时都要在这个测试集上跑一遍自动回归。自动回归不需要完全用肉眼判断步骤质量可以先用召回率、JSON 解析率、bbox 有效性等硬指标拦截明显问题再抽样人工复核。9. 总结与后续学习方向从产品定位看“Show HN: Visually Precise AI Tutoring on iOS”切中的是 AI 辅导应用长期被忽视的体验断层模型懂题目但学生不知道它在讲画面的哪个位置。视觉精确能力的核心不在于让模型“看懂”而在于让模型“指给你看”这一次能力迁移涉及多模态模型输出、坐标系统归一化、iOS 视图换算、交互设计和隐私保护的多层配合。从工程实现看这个项目对 iOS 开发者的启示在于多模态模型只是能力底座真正的产品差异化发生在底座之上的交互设计和工程细节里。裁剪、坐标换算、标注渲染、流式输出、错误反馈这些环节决定了用户拿到手的是“一段 AI 生成的废话”还是“一场逐步引导的讲解”。技术栈的选择并不复杂SwiftUI 负责界面PencilKit 负责圈选多模态模型负责理解JSON 作为中间协议就可以搭出一个最小可运行版本。如果你打算继续深入有几个方向值得关注第一把步骤输出的 prompt 工程做细。目前的方案要求模型在一步内返回所有步骤和坐标实际运行时更自然的体验是让模型先识别题面再逐步骤生成每生成一步就渲染一步配合流式输出。这样用户可以实时看到讲解过程等待焦虑会大幅下降。第二引入 OCR 前置路由。先用 Vision 框架做一次轻量 OCR判断题目类型是数学、物理还是化学再选择不同的 prompt 模板和模型策略。这能明显提升复杂题型的表现。第三构建数据飞轮。把用户反馈、错误标记和模型输出汇集起来逐步形成一个针对具体学科的高质量微调数据集。到这一步产品的竞争壁垒就不再是“调 API”而是自有的教学数据。建议收藏备用。如果你正在做 iOS 端的 AI 应用或者想尝试多模态模型在教育场景的落地可以先从本文给出的小示例跑通链路再把坐标换算和模型提示词逐步打磨成适合自己的产品方案。