面试

做一个能跑的AI聊天Demo只需要几十行代码：拼一个HTTP请求、把模型返回的文本显示出来即可。但要做一个达到生产级体验的AI Chat，就会面对一堆并不"AI"的工程问题：字怎么一个个"蹦"出来？Markdown怎么边流边渲染？模型想让前端弹一个卡片甚至一个表单，该怎么办？用户点击卡片里的按钮怎么回传给模型？ 本文以iOS为实现目标，系统梳理AI Chat的工程架构，重点讲清楚两件事：流式输出与A2UI（Agent to UI），同时覆盖工具调用、取消、多模态、端侧推理等常见高级能力。 一、整体架构 一个完整的iOS AI Chat客户端，通常可以拆成如下几层： graph TB subgraph UI ["展示层"] LIST["消息列表UICollectionView / List"] CELL["消息Cell文本 / Markdown / A2UI Surface"] INPUT["输入区文本 / 图片 / 语音"] end subgraph VM ["ViewModel层"] STATE["会话状态机"] STREAM["流式拼装器"] TOOL["工具执行器"] end subgraph NET ["网络层"] SSE["SSE / HTTP 分块"] PARSER["协议解析OpenAI / Claude / A2UI"] end subgraph DATA ["数据层"] DB["消息持久化GRDB / WCDB / CoreData"] CTX["上下文裁剪Token预算"] end INPUT --> STATE STATE --> NET NET --> PARSER PARSER --> STREAM STREAM --> CELL STREAM --> TOOL TOOL --> NET STATE --> DB DB --> CTX CTX --> NET 几个关键特征： ...

定义 观察者模式（Observer Pattern）是一种行为型设计模式，它定义了对象之间的一对多依赖关系，当一个对象（主题/被观察者）的状态发生改变时，所有依赖于它的对象（观察者）都会收到通知并自动更新。 观察者模式也被称为发布-订阅模式（Publish-Subscribe Pattern）。 为什么需要观察者模式 观察者模式要解决的核心问题是：当一个对象的状态发生变化时，如何自动通知所有依赖它的对象。 问题场景：假设我们正在开发一个电商App，用户登录后需要更新多个页面的状态（首页显示用户名、购物车同步、个人中心更新等）。 最直接的方式可能是这样： class LoginService { func login(username: String, password: String) { // 登录成功后... let user = User(name: username) // 直接调用各个需要更新的对象 HomeViewController.shared.updateUser(user) CartViewController.shared.syncCart(for: user) ProfileViewController.shared.refreshProfile(user) // 如果还有其他需要通知的地方，继续添加... } } 这种方式有什么问题？ 紧耦合：LoginService必须知道所有需要通知的对象，依赖关系错综复杂 难以维护：每新增一个需要监听登录事件的页面，都要修改LoginService 违反开闭原则：对扩展不开放，每次扩展都要修改已有代码 单例滥用：为了让LoginService能访问到各个页面，不得不使用大量单例 观察者模式的解决思路： 被观察者（Subject）只负责"广播"状态变化，不关心谁在监听；观察者（Observer）自己注册感兴趣的事件： // 使用NotificationCenter实现 class LoginService { func login(username: String, password: String) { let user = User(name: username) // 只负责发送通知，不关心谁在监听 NotificationCenter.default.post( name: .userDidLogin, object: nil, userInfo: ["user": user] ) } } // 各个页面自己注册监听 class HomeViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() NotificationCenter.default.addObserver( self, selector: #selector(handleUserLogin), name: .userDidLogin, object: nil ) } @objc func handleUserLogin(_ notification: Notification) { if let user = notification.userInfo?["user"] as? User { updateUI(with: user) } } } 观察者模式的好处： ...

ChatGPT、Claude、Gemini——这些模型的核心都是同一个架构：Transformer。它在2017年由Google的论文"Attention Is All You Need"提出，彻底改变了自然语言处理（NLP）领域，随后席卷了计算机视觉、语音、蛋白质折叠等几乎所有AI领域。 我们从最直觉的角度出发，一步步搞清楚Transformer到底在做什么。 一、从序列到序列：Transformer要解决什么问题 1.1 语言的本质是序列 一句话是一个词的序列： "我 今天 很 开心" → [我, 今天, 很, 开心] 语言模型的核心任务是：给定前面的词，预测下一个词。 "我 今天 很" → ?（开心？难过？忙碌？） 但词与词之间的关系非常复杂。“它"指代谁？“银行"是河岸还是金融机构？这取决于上下文中其他词的信息。 1.2 RNN的困境 在Transformer之前，处理序列的主流方法是循环神经网络（RNN）。RNN像一个人从左到右逐词阅读，用一个"记忆状态"来记住看过的内容： graph LR X1["我"] --> H1["h₁"] H1 --> H2["h₂"] X2["今天"] --> H2 H2 --> H3["h₃"] X3["很"] --> H3 H3 --> H4["h₄"] X4["开心"] --> H4 问题在于： 长距离依赖困难：信息需要经过很多步才能从序列开头传到末尾，容易丢失 无法并行：必须逐步处理，前一步完成才能开始后一步，训练很慢 Transformer的核心洞察是：不需要逐步处理，让序列中的每个位置直接与所有其他位置交互。这就是"注意力（Attention）“机制。 二、词嵌入：给词语一个数学身份 2.1 从独热编码到词向量 计算机不认识"猫”、“狗"这样的文字。我们需要把词转换成数字。 最朴素的方式是独热编码（One-Hot Encoding）：假设词汇表有50,000个词，每个词用一个50,000维的向量表示，只有对应位置是1，其余全是0。 "猫" → [0, 0, ..., 1, ..., 0, 0] (第3721个位置是1) "狗" → [0, 0, ..., 0, 1, ..., 0, 0] (第5042个位置是1) 问题：在这种表示下，“猫"和"狗"的距离与"猫"和"经济学"的距离一样远——完全丢失了语义信息。 ...

SIL（Swift Intermediate Language，Swift 中间语言）是 Swift 编译器在编译过程中生成的一种中间表示（Intermediate Representation，IR）。它位于 Swift 源码与 LLVM IR 之间，是 Swift 编译器架构中至关重要的一层。 SIL 的设计目标是： 对 Swift 语言的高级语义进行精确建模 在高层抽象的基础上执行强大的优化 保留足够的类型信息，用于诊断和安全检查 作为 Swift 特有优化的载体，弥补 LLVM IR 无法直接表达 Swift 语义的不足 SIL 并不是给开发者日常编写的语言，而是编译器的内部表示。理解它有助于深入理解 Swift 的编译过程、性能优化原理和内存管理机制。 Swift 编译流程概览 在了解 SIL 之前，需要先理解 Swift 的整体编译流程： flowchart TD A[Swift 源代码 .swift] --> B[词法分析 Lexer] B --> C[语法分析 Parser] C --> D[语义分析 Sema] D --> E[SILGen: 生成 Raw SIL] E --> F[SIL 优化 Guaranteed Passes] F --> G[SIL 优化 General Passes] G --> H[IRGen: 生成 LLVM IR] H --> I[LLVM 优化] I --> J[机器码 .o] J --> K[链接器 Linker] K --> L[可执行文件 / 动态库] 各阶段简述 词法分析（Lexer） 编译的第一步。Lexer 逐字符扫描 .swift 源文件，将其切分为一系列Token（词法单元），例如关键字 func、标识符 add、运算符 +、字面量 42、左右括号等。Token 是后续所有分析的最小输入单位。这一步会剥离注释和空白，但保留它们的位置信息以便后续生成精确的诊断信息（错误提示的行号和列号）。 ...

定义 装饰器模式（Decorator Pattern）是一种结构型设计模式，它允许向现有对象动态添加新功能，同时又不改变其结构。装饰器通过创建一个包装对象来包裹真实对象，实现在不修改原有对象的基础上扩展功能。 装饰器模式的核心思想是：使用组合而非继承来扩展对象的功能，遵循"对扩展开放，对修改关闭"的原则。 为什么需要装饰器模式 装饰器模式要解决的核心问题是：在不修改原有对象的情况下，动态地给对象添加新功能。 问题场景 假设我们正在开发一个UI组件库，需要为UILabel添加各种视觉效果：圆角、阴影、边框、渐变背景等。而且这些效果需要能够自由组合。 方案一：使用继承（不推荐） // 基础标签 class BasicLabel: UILabel { init(text: String) { super.init(frame: .zero) self.text = text } } // 圆角标签 class RoundedLabel: BasicLabel { override init(text: String) { super.init(text: text) layer.cornerRadius = 8 clipsToBounds = true } } // 阴影标签 class ShadowLabel: BasicLabel { override init(text: String) { super.init(text: text) layer.shadowColor = UIColor.black.cgColor layer.shadowOffset = CGSize(width: 0, height: 2) layer.shadowOpacity = 0.3 } } // 边框标签 class BorderLabel: BasicLabel { override init(text: String) { super.init(text: text) layer.borderWidth = 1 layer.borderColor = UIColor.gray.cgColor } } // 如果需要圆角+阴影呢？ class RoundedShadowLabel: BasicLabel { override init(text: String) { super.init(text: text) // 重复圆角代码 layer.cornerRadius = 8 clipsToBounds = true // 重复阴影代码 layer.shadowColor = UIColor.black.cgColor layer.shadowOffset = CGSize(width: 0, height: 2) layer.shadowOpacity = 0.3 } } // 如果需要圆角+边框呢？ class RoundedBorderLabel: BasicLabel { /* 又要重复代码 */ } // 如果需要阴影+边框呢？ class ShadowBorderLabel: BasicLabel { /* 继续重复代码 */ } // 如果需要圆角+阴影+边框呢？ class RoundedShadowBorderLabel: BasicLabel { /* 所有代码都重复一遍 */ } 这种方式的问题： ...

大语言模型（LLM）能流畅地写文章、回答问题、编写代码，但它有一个根本性的局限：它的知识被冻结在训练数据截止的那一刻。问它昨天发生了什么新闻？不知道。问它你公司内部的技术文档？更不知道。 更棘手的是，LLM有时候会"一本正经地胡说八道"——这就是所谓的**幻觉（Hallucination）**问题。模型会自信满满地编造一个不存在的论文引用、一个错误的API参数、甚至一个虚构的历史事件。 **RAG（Retrieval-Augmented Generation，检索增强生成）**正是为解决这些问题而生。它的核心思想简单而有效：在让LLM回答之前，先从外部知识库中检索相关信息，把这些信息塞到提示词（Prompt）里，让LLM基于真实资料来回答。 一、RAG的核心思想 1.1 一个直觉的类比 想象你是一个闭卷考试的学生（这就是纯LLM）——只能靠记忆作答，记不清的地方就只能猜。 现在允许你带一本参考书（这就是RAG）——遇到不确定的问题，先翻书找到相关段落，然后基于书中的内容来组织答案。 显然，开卷考试的准确率会高得多。 1.2 RAG的核心价值 LLM的局限 RAG的解决方案 知识过期，无法获取训练截止后的信息 随时更新知识库，实时生效 幻觉问题，生成不存在的信息 基于真实文档生成，可追溯来源 垂直领域知识不足 接入专业知识库，提供领域专业回答 更新成本高，Fine-tuning代价大 只需更新知识库，成本低且灵活 1.3 RAG的基本流程 graph LR Q["用户提问"] --> R["检索器Retriever"] KB["知识库"] --> R R --> C["相关文档片段"] C --> P["构造Prompt问题 + 相关文档"] P --> LLM["大语言模型"] LLM --> A["生成回答"] 三个核心步骤： 检索（Retrieve）：根据用户的问题，从知识库中找到最相关的文档片段 增强（Augment）：将检索到的信息与原始问题一起构造成Prompt 生成（Generate）：LLM基于增强后的Prompt生成回答 二、从关键词到语义：检索方式的演进 2.1 传统关键词搜索的局限 最简单的检索方式是关键词匹配。比如用户问"如何购买商品？"，搜索引擎会提取关键词"购买"、“商品”，然后去匹配包含这些词的文档。 问题很明显： 文档中写的是"下单流程说明"——语义完全一致，但没有任何关键词重合 无法理解同义词：“购买"vs"下单"vs"采购"vs"买” 必须精确匹配关键词，用词不同就检索不到 我们需要一种理解语义的检索方式。 2.2 文本嵌入（Text Embedding） 文本嵌入模型（如OpenAI的text-embedding-3-small、BGE等）将文本转换为高维向量（通常512/768/1024/1536维），使得语义相近的文本在向量空间中距离相近： "如何购买商品？" → [0.23, -0.15, 0.82, ...] (768维向量) "下单流程说明" → [0.21, -0.12, 0.79, ...] ← 向量很近，语义匹配! "今天天气真好" → [-0.65, 0.43, -0.21, ...] ← 向量很远 在高维向量空间中，每个维度代表不同的语义特征（如情感倾向、主题领域、动作类型等）。语义相似的文本会在空间中聚集在一起——“购买”、“下单”、“采购"形成一个语义簇，而"天气预报"则远离这个簇。 ...

本文将深入探讨Objective-C中所有对象的基类NSObject的底层实现原理，涵盖对象本质、isa指针机制、Tagged Pointer、引用计数、内存布局等核心概念。 NSObject 的本质：C 结构体 在Objective-C的底层实现中，NSObject的本质是一个C结构体。在苹果运行时源码中可以看到： // 底层运行时定义 struct objc_object { Class isa; // 指向对象所属类的指针 }; // 类型别名定义 typedef struct objc_object NSObject; 这意味着，当我们通过NSObject *obj = [[NSObject alloc] init];创建一个 NSObject 实例时，实际上在堆上分配了一个struct objc_object结构体，而变量obj只是一个指向该结构体的指针。 // 这行代码在底层实际上做了类似下面的事情： NSObject *obj = [[NSObject alloc] init]; // 等效的伪C代码: // 1. 调用 alloc 类方法，其核心是调用 malloc 在堆上分配一块足够大的内存 // 大小至少是 sizeof(struct objc_object)，即一个isa指针的大小 NSObject *obj = (NSObject *)malloc(sizeof(struct objc_object)); // 2. 初始化这块内存，最重要的是设置 isa 指针，让它指向 NSObject 这个类 obj->isa = [NSObject class]; // 实际过程更复杂，但本质如此 // 3. 其他初始化工作 (init) 那么这里提到的isa指针是什么呢？ ...

定义 策略模式（Strategy Pattern）是一种行为型设计模式，它定义了一系列算法，将每个算法封装起来，并使它们可以相互替换。策略模式让算法独立于使用它的调用者而变化。 策略模式的核心思想是：将算法的定义与使用分离，通过组合而非继承来实现算法的切换。 为什么需要策略模式 在实际开发中，我们经常会遇到这样的场景：同一个功能有多种实现方式，而且这些实现方式需要根据不同条件进行切换。 问题场景：假设我们正在开发一个电商App的支付功能，需要支持信用卡、Apple Pay、支付宝等多种支付方式。 最直接的实现方式可能是这样： func processPayment(type: String, amount: Double) { if type == "creditCard" { // 信用卡支付逻辑（可能有几十行代码） print("Processing credit card payment...") } else if type == "applePay" { // Apple Pay支付逻辑 print("Processing Apple Pay...") } else if type == "alipay" { // 支付宝支付逻辑 print("Processing Alipay...") } // 后续可能还要添加更多支付方式... } 这种实现方式存在几个明显的问题： 违反开闭原则：每次添加新的支付方式，都需要修改这个函数，增加新的分支 代码臃肿：随着支付方式增多，函数会变得越来越长，难以维护 测试困难：所有支付逻辑耦合在一起，难以单独测试某种支付方式 复用性差：如果其他地方也需要使用某种支付逻辑，只能复制代码 策略模式的解决思路： 策略模式将每种支付方式抽取为独立的类（策略），它们都实现相同的接口。调用方只需要持有策略接口的引用，不需要知道具体是哪种实现。 这样做的好处是： 新增支付方式：只需要新建一个策略类，无需修改现有代码 代码清晰：每种支付逻辑独立封装，职责单一 易于测试：可以对每种策略单独进行单元测试 运行时切换：用户可以随时切换支付方式，系统只需要替换策略对象 简单来说，策略模式就是把「做什么」和「怎么做」分离开来——调用方只关心「做什么」，具体「怎么做」由不同的策略类来决定。 模式结构 classDiagram class Context { -strategy: Strategy +setStrategy(strategy: Strategy) +executeStrategy() } class Strategy { <<interface>> +execute() } class ConcreteStrategyA { +execute() } class ConcreteStrategyB { +execute() } class ConcreteStrategyC { +execute() } Context o-- Strategy Strategy <|.. ConcreteStrategyA Strategy <|.. ConcreteStrategyB Strategy <|.. ConcreteStrategyC 角色说明 Strategy（策略接口）：定义所有支持的算法的公共接口 ConcreteStrategy（具体策略）：实现Strategy接口的具体算法 Context（上下文）：持有Strategy的引用，负责调用策略方法 iOS中的实现 基础实现 // 策略协议 protocol PaymentStrategy { func pay(amount: Double) -> Bool var name: String { get } } // 具体策略 - 信用卡支付 class CreditCardPayment: PaymentStrategy { private let cardNumber: String private let cvv: String var name: String { "Credit Card" } init(cardNumber: String, cvv: String) { self.cardNumber = cardNumber self.cvv = cvv } func pay(amount: Double) -> Bool { print("Paying \(amount) using Credit Card ending with \(cardNumber.suffix(4))") // 实际支付逻辑 return true } } // 具体策略 - Apple Pay class ApplePayPayment: PaymentStrategy { var name: String { "Apple Pay" } func pay(amount: Double) -> Bool { print("Paying \(amount) using Apple Pay") // 调用Apple Pay SDK return true } } // 上下文 class PaymentContext { private var strategy: PaymentStrategy init(strategy: PaymentStrategy) { self.strategy = strategy } func setStrategy(_ strategy: PaymentStrategy) { self.strategy = strategy } func checkout(amount: Double) -> Bool { print("Processing payment with \(strategy.name)...") return strategy.pay(amount: amount) } } // 使用 let creditCard = CreditCardPayment(cardNumber: "1234567890123456", cvv: "123") let context = PaymentContext(strategy: creditCard) context.checkout(amount: 99.99) // 切换支付方式 let applePay = ApplePayPayment() context.setStrategy(applePay) context.checkout(amount: 99.99) 使用闭包简化策略 对于简单的策略，可以使用闭包代替完整的类： ...

大语言模型（LLM）的能力边界很大程度上取决于你怎么跟它说话。同样的模型，一个精心设计的Prompt可以得到专业级的回答，一个随意的Prompt可能只得到平庸甚至错误的结果。Prompt Engineering就是研究如何有效地与LLM沟通的技术。 一、Prompt的基本构成 1.1 一个Prompt的解剖 一个高质量的Prompt通常包含以下要素： graph TD P["完整的Prompt"] --> R["角色Role"] P --> C["上下文Context"] P --> I["指令Instruction"] P --> E["示例Examples"] P --> F["格式要求Format"] P --> CO["约束Constraints"] 要素 作用 示例 角色 设定模型的身份和专业背景 “你是一位有10年经验的iOS架构师” 上下文 提供背景信息 “我们的项目使用MVVM架构，Swift语言” 指令 明确说明任务 “请review以下代码并指出问题” 示例 展示期望的输入输出格式 给出一个输入-输出样例 格式要求 指定输出的结构 “以Markdown表格形式输出” 约束 限制条件 “不超过500字"“只使用Swift标准库” 1.2 System Prompt vs User Prompt 在API调用中，消息分为不同的角色： { "messages": [ { "role": "system", "content": "你是一位资深iOS开发工程师，擅长性能优化。回答时给出具体的代码示例。" }, { "role": "user", "content": "如何优化UITableView的滚动性能？" } ] } System Prompt：设定模型的整体行为、角色和约束，贯穿整个对话 User Prompt：具体的问题或指令 Assistant：模型的历史回复，提供对话上下文 二、核心Prompt技术 2.1 Zero-Shot Prompting 直接给指令，不提供任何示例： ...

定义 生产者消费者模式（Producer-Consumer Pattern）是一种并发设计模式，它通过一个共享的缓冲区来解耦生产者和消费者，使得生产者和消费者可以以不同的速度工作，而不需要直接相互依赖。 生产者负责产生数据并放入缓冲区，消费者从缓冲区中取出数据进行处理。这种模式是多线程编程中最经典的设计模式之一。 为什么需要生产者消费者模式 生产者消费者模式要解决的核心问题是：如何在生产者和消费者处理速度不一致的情况下，实现高效、安全的数据传递。 问题场景：假设我们正在开发一个图片处理App，用户选择多张图片后需要进行滤镜处理。图片加载速度快，但滤镜处理速度慢。 最直接的方式可能是这样： class ImageProcessor { func processImages(_ urls: [URL]) { for url in urls { // 加载图片（快） let image = loadImage(from: url) // 应用滤镜（慢） let filtered = applyFilter(to: image) // 保存结果 saveImage(filtered) } } private func loadImage(from url: URL) -> UIImage { /* ... */ } private func applyFilter(to image: UIImage) -> UIImage { /* ... */ } private func saveImage(_ image: UIImage) { /* ... */ } } 这种方式有什么问题？ ...