Apple的设备端模型在聊天方面表现糟糕,但在结构化输出和工具调用方面表现出色

我花了几周时间对Apple的设备端模型进行压力测试——这是一个约3B参数的模型,运行在任何Apple Silicon Mac的Neural Engine上。为了全面测试,我构建了Think Local,这是一个macOS应用,可以测试模型的每项功能:聊天、图像生成、结构化输出、工具调用和参数比较。 我的结论:作为聊天机器人,这个模型表现糟糕。但作为结构化输出和工具调用引擎,它出人意料地优秀。 这种区别很重要,因为它完全改变了你应该如何使用这个模型。 聊天表现令人失望——但这没关系 Apple的模型上下文窗口只有4,096个token。对比一下:Claude有100万个token,GPT-4o有128K。使用Apple的模型时,你放入200个token的系统提示,150个token的模式定义和三轮对话,就已经用了70%。 自由文本的质量也不令人印象深刻。回答正确但通用,长会话中重复性强,安全防护机制经常出现令人困扰的误报——问它网络安全相关问题,有时会拒绝回答,因为它对"攻击"这个词理解过于字面化。 如果你把它当聊天机器人来评估,它就是一个平庸的模型。但这样评估就像批评螺丝刀不是好锤子一样。 闪光点:约束解码 这里一切都不同了。Foundation Models支持@Generable——一个将Swift结构体转换为模式的宏,模型必须遵守这个模式。这不是"请求JSON然后祈祷"。这是约束解码:在生成过程中,模型字面上无法输出违反模式的token。 @Generable struct BugReport { @Guide(.anyOf(["bug", "feature", "task"])) var type: String @Guide(.anyOf(["low", "medium", "high", "critical"])) var priority: String var title: String var description: String } 使用这个模式,你告诉它"分类:应用在旋转设备时崩溃",它会返回: { "type": "bug", "priority": "high", "title": "Crash on device rotation", "description": "The application crashes when the user rotates..." } 受限字段(type、priority)始终有效——它不能编造列表之外的值。自由字段(title、description)连贯且简洁。我用几十种不同的输入进行了测试:在200多次执行中,模式错误为零。 在这个模型中,自由生成和约束解码之间的差异是巨大的。这就像让初级开发者随意写作与给他一个有定义字段的表单之间的区别。表单总是获胜。 工具调用:一个知道自己不知道什么的3B模型 这是最让我惊讶的。定义一个工具get_weather(city: String),问它"马德里天气如何?",它会生成一个带有正确参数的结构化调用。问它"法国的首都是什么?",它会直接回答——它知道不需要工具。 一个3B参数的模型,在你的笔记本电脑上运行,无需网络,能区分何时使用工具,何时不用。它不完美——对于模糊的提示有时会困惑——但在明确输入上的准确率很显著。 Apple的工具调用使用相同的约束解码机制:调用是一个@Generable结构体,所以参数始终有效。没有损坏的JSON解析,也没有编造的参数。 Image Playground:没人提到的另一个模型 Apple Intelligence不仅仅是文本。Image Playground是一个独立的框架,在设备上生成三种风格的图像:动画、插图和素描。它也完全在Neural Engine上运行,无需网络。 模式重复:对于它设计的用途,它工作得很好。图标、贴纸、简单构图——结果出人意料地好。图像中的文本、详细的人体解剖学、复杂构图——灾难性的。 Think Local包含一个图像工作室,你可以在其中测试提示并并排比较风格。通过十分钟的提示测试获得的直觉是任何基准测试都无法提供的。 数据 在Apple Silicon Mac上测量,使用Think Local的资源监视器: 指标 值 生成速度 ~40 tok/s 冷启动(无预热) ~800ms 冷启动(有预热) ~200ms 模型内存 ~1.2 GB 上下文窗口 4,096 tokens 参数 ~3B 电池影响 最小(Neural Engine) 电池数据很重要:Neural Engine在推理方面的消耗明显少于CPU。在生成过程中,CPU因为数据封装和UI略有上升,但繁重的工作交给Neural Engine。这使得在后台使用模型进行工具开发成为可能——git钩子、代码检查器、分类器——而不会耗尽笔记本电池。 ...

2026年4月7日 · Fernando

苹果的情感分析认为'删除临时文件'是死亡威胁

NLTagger是苹果的情感分析API。它集成在iOS和macOS中,在设备本地运行,不需要服务器,只需三行代码即可使用。当你搜索"Swift情感分析"时,它是第一个出现的结果。 对于任何开发者在日常工作中会写的文本,它返回以下结果: 消息 NLTagger 实际情况 “delete the temp file” -0.8 中性指令 “ok” -0.8 中性确认 “run make test” -0.6 中性指令 “commit and push” -0.4 中性指令 “great job, thanks!” +1.0 正面(正确) “this is fucking broken” -1.0 负面(正确) 评分范围从-1.0(极其负面)到+1.0(极其正面)。根据苹果的评判,“delete the temp file"与"this is fucking broken"具有几乎相同的情感强度。而"ok”——英语中最中性的回应——得分是**-0.8**。 这些不是编造的数字。这些是在任何运行macOS 14+的Mac上都能重现的结果。 如何重现 import NaturalLanguage let tagger = NLTagger(tagSchemes: [.sentimentScore]) tagger.string = "delete the temp file" let (tag, _) = tagger.tag( at: tagger.string!.startIndex, unit: .paragraph, scheme: .sentimentScore ) print(tag?.rawValue ?? "nil") // "-0.8" 八行Swift代码。结果是确定性的:相同的文本在每次执行、每个设备上都产生相同的分数。这不是随机错误,而是系统性偏见。 ...

2026年4月5日 · Fernando

我花了 $15 百万 token 写了 'fix: typo'

昨天我用 Claude Code 写了一条 commit message。diff 是一行修改:一个注释里的拼写错误。Claude Opus 读取了 diff,思考了两秒钟,生成了 fix: correct typo in auth comment。为此,它用了大约 800 个输入 token 和 30 个输出 token,分别花费 $15 和 $75 每百万 token。总成本:不到一分钱。但是,把这个过程放大到一天 40 次 commits,250 个工作日,一家公司有 200 名开发者使用 coding agents,那么这些看似微不足道的花费会积累成数千美元的开销,付出的只是等同于贴创可贴的智力劳动。 问题并不是 Opus 太贵。问题在于 coding agents 不会区分 $0.001 的任务和 $0.10 的任务。一切都通过同样的大模型执行。生成 commit 信息、分类一个 issue、验证格式 —— 全部使用高成本的模型,就像雇用一位外科医生来贴创可贴。 数据与成本 我们用 Claude Opus 4(上一代,目前大部分生产环境还在用的版本)的价格来算一个账: 任务 输入 Token 数 输出 Token 数 成本 生成 commit 信息(小型 diff) ~800 ~30 $0.014 分类某个 issue ~500 ~50 $0.011 验证 commit 格式 ~300 ~20 $0.006 生成 standup 报告 ~2000 ~200 $0.045 这些任务都不需要一个拥有 2 万亿参数和多步推理能力的大模型。这些仅仅是带有强约束的分类和生成任务。本质上就像是根据颜色对卡片进行分类。 ...

2026年4月5日 · Fernando

Clawdbot:正在颠覆(并让半个互联网担忧)的开源AI助手

一只在你电脑上的太空龙虾 想象一下,一位奥地利开发者创建了一款私人 AI 助手,把它命名为“太空龙虾”,然后决定向公众开放。24小时内,它就在 GitHub 上获得了9,000个星标。48小时后,这个数字增长到17,000。同时,它也遇到了超过300个问题,其中一些是关键的安全问题,甚至有人用它的名字创建了一种非官方的加密货币。 欢迎来到 Clawdbot。 这究竟是什么? Clawdbot 是一个在你本地设备上运行的开源 AI 助手。与其他助手不同的是:它不仅能回答问题,还能“执行操作”。 它可以连接到 WhatsApp、Telegram、Discord、Slack 和 iMessage。可以阅读你的邮件,访问你的日历,创建文件,运行代码。而最有趣的是:它可以随时学习新技能。 它的创造者是 Peter Steinberger,一个在移动开发领域颇有名气的人物(他创立了 PSPDFKit 并成功出售了公司)。一开始这只是一个私人项目:他的私人助手名为 Clawd,有着“太空龙虾”的个性,帮他管理数字生活。 到2026年1月,他决定开源这个代码。而如今,我们就在这儿。 它的魅力所在 Clawdbot 的特别之处在于它是一个真正的“代理”。它不是一个只会回答问题然后停下来的聊天机器人。它是一个能够: 编排重复性任务 以你的名义执行操作 为自己创建新技能 最后一点尤为关键。如果你让它做一件它不会的事,比如“将这个视频转换为 GIF”,它会编写所需的代码,安装为一个新技能,并完成任务。下次再遇到类似需求,它已经学会了。 Hacker News 的一位用户表示,他用它来管理 Facebook Messenger 上的租赁咨询。Clawdbot 筛选消息,安排看房时间,完成的任务成功率达 90%。 另一个开发者用它调试自己的代码缺陷。Clawdbot 找到了问题,编写了修复代码,并提交了一个 pull request,最终被成功合并。 简单来说:拥有它就像是雇了一个永不疲倦、不抱怨、学习能力极强的助理。 它令人担忧的地方(且不容忽视) 但问题也很严重,非常严重。 超过300个未解决问题 该项目在 GitHub 上有超过 300 个未解决问题,许多是漏洞和安全风险报告。这不一定是坏事——受欢迎的项目总会有一些问题——但这也侧面说明了其成熟度不足。 没有沙箱机制 Clawdbot 以与你的用户帐户相同的权限运行。没有虚拟机。没有容器。没有隔离。如果你授予它访问权限,那就是真正的访问权限。 正如一位 HN 讨论区里的人所说: “让一个联网的进程拥有 root 权限而且没有任何防护措施是……一种危险的决策。” 硬编码的 OAuth 凭据 有人在代码库中发现了硬编码的 OAuth 凭据。维护者辩称这是开源软件的惯例,但这仍然让人不禁皱眉。 提示注入攻击 该系统缺乏针对“提示注入攻击”的强有力机制。如果 Clawdbot 访问了一个恶意网站,该网站的内容可能会篡改它的行为。没有对数据进行“非可信”标注的机制。 ...

2026年1月26日 · Fernando