运行在您的设备上的设计助理 — 没有账户, 没有服务器

前提

大多数 AI 设计工具都会将您的提示发送到服务器,运行一个大型模型,并发送代码返回. 这需要一个账户,一个网络往返, 并相信你的工作在建 转过别人的基础设施.

我们想知道另一个极端会发展到什么程度:一个设计助理,模型运行在你自己的机器上. 没有账户。 无上传. 提示永远不会离开浏览器 。 本文现作为实验性**AI / Code → Assistance ** tab 而在PinePaper的编辑器中现场直播,此文章是对其工作方式和不足之处的诚实叙述.

为什么不直接问模型代码?

显而易见的方法是要求在线设备模型针对PinePaper的API编写JavaScript并运行. 我们试过了 失败了.

小型型号——适合笔记本电脑的型号——对特定应用的API不知情。 ** 要求一个0.5–2B模型调用QQ,它即兴化:一种方法不读的键(一种SVG风格的QQ1Q,其中API期望的QQ2Q),一种它想象的方法,辩词形状错误. 输出看起来像代码,默默地做错事.

所以我们不问代码。 我们要求一份受限制的工具电话清单:**

[
  { "name": "pinepaper_set_background_color", "arguments": { "color": "#0F0F1A" } },
  { "name": "pinepaper_create_item", "arguments": { "itemType": "star", "x": 400, "y": 300, "radius": 90, "color": "#E74C3C", "animationType": "pulse" } }
]

相同的词汇PinePaper的MCP服务器暴露于外部代理——但被本地运行的模型所释放,并通过一个小调度器在画布上执行.

使输出无效

键动是**受约束的解码。 ** 而不是希望这个模型能产生一个有效的形状, 我们约束着它,甚至允许它发出什么信号: *

• 在Chrome的内置Prompt API(Gemini Nano)上,我们通过一个JSON Schema作为响应约束. 该模型只能产生计划允许的对象——用QQ0Q,任何计划没有定义的参数都从字面上来说是无法代表的.
• 在WebLLM(在WebGPU上运行的开放型号)上,我们 通过XGrammar附上EBNF语法。 语法支配结构;模型只填充值.

两者都产生相同的工具调用形状. 一个小的修补通行证,然后从论证形状中推断出工具,以挽救一个仍然制造的微小模型——一个被丢弃的QQ0Q,没有包装的论证. 结果是"画一个绿色五角星"变成了真正的QQ1Q调用而不是错误.

两个供应商,一个合同

On-device AI不是一回事——它取决于浏览器:

• Browser AI — Chrome的内置Gemini Nano (window.LanguageModel). 带浏览器的模型船;我们没有下载的东西. 这是今天最可靠的在Device路径,因为JSON-schema的制约是便宜的,并且得到了很好的支持.
• PinePaper AI — WebLLM在任何WebGPU浏览器中运行一个Quen2.5模型. 它下载过一次模型(之后被删除),然后运行下线.
• ** Languages ** – 非英语提示先翻译为英语 on-device(通过浏览器的内置翻译),因为面向代码的小型模型都是以英语为中心的. 生成的场景无论是否迅速语言都是一样的.

用户选择引擎;下游的一切——约束,执行者,画布——都是相同的.

编辑,不只是生成

一发发电机不是助手 为了支持"让星星红",模型需要知道画布上已经有什么. 因此,每个转弯,我们都会向它提供一个紧凑的快照, 描述当前项目——它们的ID,类型和颜色—— 就像服务器侧聊天一样。 "Make the star red"之后将解析为真实的QQ0Q调用以对抗物品的ID. (又因为一个小模型有时在表示恒星时指的是"the"(the circle),执行者对活画布解决模糊的引用. )

谈话记录保存在您的设备上 ** 本地存储 。 没有任何关于它的东西被送到任何地方——除非你明确选择分享失败的提示,这帮助我们改进提示和语法.

当小模型不够时——升级

以下是诚实的部分:a 0.5–2B模式是最弱的一级. 限制解码保证 *有效结构 *,但模型仍然需要选择正确的工具和明智的价值观,它不会总是. 问一个五边形和一个规格不足的模型会给你一个六边形;问两次"红色",它可能会运行一个生成器代替.

因此,建筑将在线设备视为 * 第一*级,而不是唯一的一级。 经过几次失败的尝试后 助理提议把整个谈话都交出来 (笑声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) (掌声) 忠诚度低,自由与私人, 有一条一击路径到高度忠诚 当你需要它.

我们学到的

• ** 约束被催促。 ** 一个基于系统的提示有帮助;一个使无效输出无法实现的语法/schema有更大的帮助. 最大的一次可靠性跳跃来自受限制的解码,而不是来自更好的快速.
• ** 模型大小仍然占主导地位。 ** 从0.5B型到1.5B型明显改进了助理选择正确工具的频率. 没有将一个小模型变成聪明模型的提示.
• ** 完整的语法可能太大。 ** 我们的第一个语法编码了 * 每一个可能的操作—— 包括一个边界长的逃生舱,用于任意的绘图码。 如此之大以至于受限制的解码使页面停滞. 覆盖共同操作的紧凑语法是正确的默认;完整的表面是选入的.
• 离开主线 一个在UI线上进行推断的模型会冻结页面. WebLLM在Web Worker中运行,所以编辑器在模型加载和生成时保持响应性.

接下来呢

这是实验性改进。 在路线图上:

• ** 受限路径中的Wider工具覆盖** — 更多PinePaper的操作可显示,没有freeform逃生舱门.
• Larger on-device models 随着WebGPU 型号目录的增长,交易下载大小以获取可靠性.
• ** 更紧凑的eval循环** ——使用选择的失败报告来测量,这些失败报告会触发安装模型的绊脚石,并强化针对模型的语法.
• ** 一个更平滑的设备 ~ 云手交**, 所以升级感觉像是打开 质量拨号而不是切换工具.

通过线:相同的声明工具词汇驱动浏览器边界两侧的模型. 一个外部代理在MCP之上调用这些工具;一个在线设备模型在当地调用相同的形状. 一份合同, 代理他们运行的地方.

• 在编辑器中尝试——打开AI/代码=助理. 这是免费的,运行在你的设备上,不需要账户