摘要一定要上云吗？The Brutalist Report 给了一个本地 AI 样板

一个新闻阅读 App 的摘要按钮，真的需要把用户正在看的文章发给 OpenAI 或 Anthropic 吗？

unix.foo 那篇文章有意思的地方就在这里。作者拿自己开发的 The Brutalist Report iOS 客户端做例子：文章摘要用 Apple 本地模型 API 在设备端生成，不经过服务器，不记录 prompt，也不上传用户内容。

我更在意的不是这个功能有多炫，而是它把一个常被忽略的问题摆了出来：很多 App 里的轻量 AI 功能，默认上云，可能只是工程惯性。

如果一个摘要功能背后要依赖网络、模型供应商、限流、账单、后端队列和第三方数据政策，它就不再只是一个按钮。它变成了一个小型分布式系统。

The Brutalist Report 的重点：把摘要留在设备上

The Brutalist Report 原本是一个复古风格新闻聚合网站。作者最近做了原生 iOS 客户端，保留高密度新闻列表和阅读模式，也加了一个可选的“智能”视图，用来生成文章摘要。

关键选择很明确：摘要在 iPhone 本地完成。

原文提到的工具链包括 FoundationModels、SystemLanguageModel.default 和 LanguageModelSession。对更长的文章，作者会先按约 1 万字符切分文本，生成每段事实笔记，再合并成最终摘要。

这个案例不能被拔高成“本地 AI 已经赢了”。原文没有披露用户量、延迟、成本节省，也没有给出第三方隐私审计结果。

它更像一个架构样板：当输入已经在用户设备上，输出只是摘要，把内容发到云端并不是天然合理。

这张表不是在劝所有人抛弃云端模型。它只说明一件事：路线选择要看任务类型，不该用“接个 API 最快”替代架构判断。

云端 AI 的麻烦，常常从上线后开始

很多产品团队做 AI 功能，第一反应是拼 prompt、调接口、展示返回文本。上线确实快。

但上线后，麻烦也会跟着来。

用户网络差，功能可能不可用。模型供应商故障，功能也会失效。API 限流会影响体验。账单、额度、信用卡、后端健康、日志系统，都会进入故障面。

对小团队来说，这不是抽象的“技术债”。它会变成客服问题、监控报警和成本压力。

隐私更难绕开。用户内容一旦发给第三方模型，就会产生数据留存、用户同意、审计、泄露、政府请求、训练使用等问题。

哪怕供应商条款很克制，产品也要回答一个朴素问题：用户的文章、邮件、笔记、文档到底去了哪里？

这对邮箱、笔记、文档、健康、财务类应用尤其敏感。用户未必懂模型架构，但会在意内容有没有离开设备。

所以最相关的两类人，动作会很具体。

移动应用开发者可以先把摘要、分类、抽取、改写列成一张功能清单，逐项判断能否端侧完成。能端侧做的，云端 API 接入和后端排期就不该默认优先。

技术决策者也可以把采购问题往后放一步。不是先问买哪家模型，而是先问哪些数据根本不该出设备。这个顺序一换，预算、合规和架构都会变得清楚。

本地 AI 的边界：做数据转换，不做万能互联网

本地 AI 最适合的位置，不是替代 ChatGPT 或 Claude。它更适合做应用内部的数据转换层。

摘要、分类、抽取、改写、规范化，都是典型场景。输入来自用户已有数据，输出服务当前界面或工作流。任务边界窄，隐私收益高。

Apple 生态里还有一个工程细节值得看：模型不只返回一段自然语言，还可以配合 Swift struct 生成 typed structured output。

开发者可以定义类似 ArticleIntel 的结构体，让模型输出 tldr、bullets、keywords 等字段。这样 UI 不必再解析 Markdown，也不用祈祷 JSON 每次都格式正确。

这会改变 AI 在 App 里的位置。它不只是聊天框，而是可以接入缓存、权限、测试和界面状态的本地数据处理模块。

限制也要讲清楚。

原文讨论的是 Apple 生态，不能直接外推到所有平台。本地模型的能力、语言表现、系统版本、设备覆盖、延迟表现、失败处理，都会影响真实落地。

接下来最该观察的不是“本地模型能不能打败云端模型”。这个问题太大，也太粗。

更实用的观察点有四个：平台 API 是否稳定，结构化输出是否可测试，设备覆盖率是否够用，失败时能否优雅降级。

如果这四项过不了，本地 AI 也只是 demo。过得了，它就会成为移动应用里更干净、更便宜、更少打扰用户的一层能力。

回到开头那个摘要按钮。能在手机上完成的事，却默认把内容发到云端，开发者至少应该停一下。

不是因为云端模型不好，而是因为每一次上传，都在用隐私、稳定性和成本换一个本可以更近的答案。