本地AI应当成为常态：为什么你的应用不该把用户数据发给云端模型

本地设备已有足够算力与专用AI引擎，应用开发应将AI功能放在端侧而非云API，以换取隐私、可靠性与架构简洁。

引言：懒惰的云API依赖正在制造脆弱的软件

现代软件开发中，一个令人不安的趋势是：开发者为了给自己应用里加个"AI功能"，直接往OpenAI或Anthropic的服务端发送一个API调用。人们可以争论这些功能是否真的给用户带来了价值（比如很多应用只是硬塞了一个聊天框），但我这里想讨论的是一个更根本的架构问题——把云托管AI模型作为应用的外部依赖。

这种懒惰正在催生一代脆弱、侵犯隐私、从根本上就是残废的软件。我们构建的应用，只要服务器一宕机，或者用户的信用卡过期，就立刻停止工作。这不是软件，这是依附在别人基础设施上的寄生物。

我们需要回到一个更健康、更负责任的建设习惯：让本地设备承担这些计算工作。

核心质疑：你口袋里的硅比你想象中强大得多

先看看事实。我们现在口袋里的手机，其算力比十年前的台式机还要强大几个数量级。它有一个专用的神经网络引擎（Neural Engine），一天24小时大部分时间都在闲置——而我们却在等弗吉尼亚州数据中心返回JSON响应。这简直荒谬。为了读取一个本可以就地解析的文本摘要，你让用户的电量、隐私和体验都去依赖一条跨洋网络链路。

就算你的意图非常纯粹（比如你只是想给用户提供一个便利功能），但只要你把用户内容流式传输给第三方AI提供商，你产品的性质就变了：

• 数据保留问题：你突然要面对数据保留政策、用户同意书、审计日志、安全漏洞、政府数据调取请求（比如美国爱国者法案下的国家安全信函）、以及供应商用你的数据做训练等一堆沉重的伦理和法律问题。
• 技术栈复杂度爆炸：你的功能现在依赖于网络状况、外部供应商的可用性、API速率限制、账户计费状态，以及你自己的后端健康程度。

恭喜！你刚把一个原本只是一个UX功能的小需求，变成了一个烧钱的分布式系统。如果这个功能完全可以在本地跑，主动跳进这个泥潭就是自找苦吃。

"AI无处不在"不是目标。有用的软件才是目标。AI只是手段，并且只是众多手段之一。

具体案例：Brutalist Report 的完全端侧摘要引擎

几年前我做了个有趣的副项目，叫 The Brutalist Report——一个灵感来自1990年代风格网页的新闻聚合器。最近我决定为它开发一个原生iOS客户端，设计了两个核心目标：

1. 保持高信息密度的新闻阅读体验：醒目的大标题列表、一个剔除了网页上"癌症"（指各种广告、跟踪器、弹窗等现代网页癌变元素）的阅读模式。
2. （可选）提供一个人工智能摘要视图。

关键在于：摘要完全在设备本地生成，用的是Apple的本地模型API。没有任何服务器中转。没有提示词或用户日志离开用户的iPhone。没有需要创建的供应商账户。不需要在隐私政策里写"我们会保存你的内容30天"这种脚注。

之所以把这个案例单独拿出来说，是因为它揭示了一个行业常态：人们已经默认AI功能就应该跑在服务器上。作为开发者，我们有大量工作要做来扭转这种惯性。

我当然知道，有些使用场景确实需要云端大模型那张"超广角视野"才能给出好的答案。但并不是你遇到的每一个场景都需要它。我们需要区分：什么时候AI在本地就绰绰有余，什么时候才必须求助远程。

可用的端侧工具：Apple平台现状

我先说Apple生态内的工具，因为我把初期的开发精力都放在那里了。过去一年，Apple在这方面下了大功夫，让开发者能非常容易地调用内置本地AI模型。核心流程大致如下：

swift
import FoundationModels

let model = SystemLanguageModel.default
guard model.availability == .available else { return }

let session = LanguageModelSession {
"Provide a brutalist, information-dense summary in Markdown format.\n- Use bold for key concepts.\n- Use bullet points for facts.\n- No fluff. Just facts."
}

let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) {
articleText
}

let markdown = response.content

针对篇幅更长的文章，我们可以做分块处理：将纯文本按约10,000字符一块切分，先让本地模型为每一块生成"纯事实"逐要点笔记，然后再跑一遍合并流程，把各块的笔记汇聚成最终摘要。

这正是本地模型最擅长的活儿：

• 输入数据已经在设备上（因为用户正在读这篇文章）。
• 输出很轻量（只是一百来个字的摘要）。
• 速度快、且完全私密。
• 它的智力水平不需要是博士生级别——因为它只是在总结你刚加载的页面，不是在发明新知识。

本地AI最闪耀的场景是：模型的职责是转换用户已有的数据，而不是当宇宙级搜索引擎。

信任的稀缺与隐私成本的转机

人们想要很多AI功能，但又不信任这些功能。比如：自动摘要收件箱的邮件、从会议记录中提取行动项、按主题分类文档。这些功能如果走常规云端路线，每一个都变成了对用户信任的拷问："请把你的数据发到我们服务器，我们保证会好好对你的数据。"

本地AI改变了这个模式。你的设备上本来就有这些数据，我们直接在原地处理就好，不需要把数据送出去做任何事。

一个值得深思的结论：你不可能靠写一篇2000字的隐私政策来赢得用户信任，真正赢得信任的方式是——从一开始就不需要那份隐私政策。

结构化输出：本地AI的另一大优势

Apple平台上的工具能力远不止于此。Apple最近做的最漂亮的一步棋，是推动AI输出从"非结构化的文本块"转向类型化数据。

旧范式是"问模型要一段JSON，然后祈祷它记得住schema"。新且更优的范式是：定义一个Swift结构体，表示你想要的最终结果。用自然语言给结构里的每个字段一条指导说明，让模型去生成这个类型的一个实例。就这么简单。

概念上大致是这样的：

swift
import FoundationModels

@Generable
struct ArticleIntel {
@Guide(description: "One sentence. No hype.")
var tldr: String

@Guide(description: "3–7 bullets. Facts only.")
var bullets: [String]

@Guide(description: "Comma-separated keywords.")
var keywords: [String]

}

let session = LanguageModelSession()
let response = try await session.respond(
to: "Extract structured notes from the article.",
generating: ArticleIntel.self
) {
articleText
}
let intel = response.content

现在你的UI层完全不需要再费劲从Markdown里剥出列表项，也不必指望模型记得住你的JSON规范。你拿到的是一个真正的类型、真正的字段，渲染时可以保证风格一致性。它产出的结构化数据，你的应用能直接消费。并且——这一切都跑在用户自己的设备上。

这不仅只是写代码时手感更舒适，更是工程质量的实质提升。如果你在构建一款本地优先（local-first）的应用，这个差别就是"把AI当玩具"和"把AI当作一个值得信赖的子系统"之间的分野。

回应主流质疑："但是本地模型没那么聪明"

对，没错。然后呢？

让我把话说透彻：绝大多数应用功能，根本不需要一个能写十四行诗、能解释量子力学、还能通过律师资格考试的模型。它们需要的只是可靠地完成这件事里的其中一件：

• 总结（summarize）
• 分类（classify）
• 提取（extract）
• 改写（rewrite）
• 规范化（normalize）

就这些任务而言，本地模型可以做得非常出色。如果你尝试让本地模型去替代整个互联网——比如"给我讲讲拿破仑战争"——你当然会失望；但如果你把它当做一个应用内部的数据转换器，你会疑惑自己以前怎么会愿意把这些琐事送去服务器往返一趟。

实践准则：什么情况下才用云模型

最终，我主张的规则很简单：

1. 仅在真正必要的时候调用云模型。 如果你只是个新闻阅读器要总结文章，那不是"必要"。什么才算必要？比如你需要的是训练数据截止日期极其新鲜的新知识，或者需要超大规模常识推理来回答问题（这是真正的"搜索"，不是"转换"）。
2. 让用户的数据待在它该待的地方。 对大多数应用而言，数据应该在本地。在本地处理，在本地消失。
3. 当你确实要用AI时——甭管本地的还是云端的——不要只把它当聊天框粘在界面上。 把它设计成一个拥有类型化输出、行为可预测的真实子系统。

停止在不经意间发货分布式系统，你本来只是想交付一个功能。

结语：行业的回头路

这不是一篇反对AI的文章。这是一篇反对"让AI成为云依赖"的文章。

Apple开发者工具的进步表明：本地推理在技术上已经完全可行。它对于开发者体验的提升也是实质性的——减掉了计费、隐私合规、网络容错等一系列分布式系统的负担，让你把时间花在产品质量上，而不是运维上。让本地AI成为常态的技术条件已经具备，现在需要的是开发者的意愿与行业的自觉。

原文链接：https://unix.foo/posts/local-ai-needs-to-be-norm/