加载失败
Raycast（一个 macOS 桌面效率启动器与扩展平台）发布了 Glaze，一款在官网上用视频展示的 AI 桌面应用生成器。社群把它与 web 平台（如 Replit）、LLM 工具（如 Claude Code）做比较，讨论重点落在原生能力（文件系统、相机、菜单栏）、实现技术（Electron、Tauri、SwiftUI）、打包/签名与分发（内置商店）以及安全/权限审计上。评论普遍既好奇又谨慎：有人看好“vibe coding”带来的个人化小工具浪潮，另一部分则质疑这是否只是 LLM 的包装、平台信任与跨平台的工程复杂度。参与者反复提到 Xcode/Visual Studio、CORS、权限模型等具体技术细节来支撑他们的观点。
Raycast 把 Glaze 与 Replit/浏览器工具区分开，主张面向桌面可直接访问文件系统、相机、键盘快捷键、菜单栏和后台进程等浏览器受限的能力，这被视为桌面应用的核心卖点。反对者指出现代 web 或 Electron/Chrome 在获得权限时已经能覆盖许多场景，且 web 在长任务由服务器处理、离线恢复方面有优势。评论还细化了一个技术点：浏览器受 CORS 限制，无法直接做某些 API 请求或浏览器自动化，因此桌面在 API 自动化和本地数据处理上确有优势。总体论点围绕“哪些用例确实需要本地原生能力”与“哪些可以用 web 技术替代”展开。
很多用户明确表示不会在自己的机器上安装未经审查且拥有任意权限的 AI 生成桌面应用，尤其担心摄像头、文件系统和网络访问带来的滥用或后门风险。评论指出 Glaze 登陆页几乎没有安全细节，要求公开权限模型、细粒度限制、签名与审核流程，以及内置商店的信任与治理机制。有人认为浏览器沙箱能降低风险，这正是 web 应用的优势，而桌面应用若没有透明审计与严格权限控制，会被广泛拒绝。简言之，缺乏可验证的权限与分发安全策略会极大削弱用户信任。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
不少人怀疑 Glaze 本质上是把 Claude Code 或类似 LLM 包装成带有美观默认样式和 UX 预设的工具，批评者要求公开 prompt，并质疑其溢价合理性。支持者回应说，把复杂的构建、打包、设计规范封装为对非技术用户友好的流程本身有价值，尤其是当它包含打包/签名与分发能力时。评论里也提到如果能实现像 Figma Community 那样的 remix/社区共享机制，会比仅靠闭环生成更具吸引力。整体争论集中在“LLM 输出 + 工具链封装”的边界与差异化能否支撑一款独立产品上。
Glaze 的内置商店与一键发布/私有分发被许多人视为实际且有吸引力的功能，能省去 App Store 提交流程并简化团队间分发和更新。讨论集中在商店会分发源码还是二进制、谁负责签名、更新与审计，以及 Glaze Store 的安全标准如何建立。若平台真正替开发者处理打包、签名与托管，非技术团队会受益；但同样会带来新的信任与安全问题，需要明确治理与审核规则。简而言之，分发便利是卖点，信任与审核是门槛。
评论对 Glaze 在底层如何生成应用高度好奇：是编译原生 Swift/SwiftUI，还是用 React+Node 做扩展，或以 Tauri/Wails/Electron 等 webview wrapper 为基础，甚至在云端编译。有人指出 macOS/Windows 编译链差异（Xcode、Visual Studio）的复杂性、签名与证书问题，以及用户在本地安装构建工具的摩擦。讨论还提到“cross‑platform” 与“multi‑platform” 的区别：是统一行为还是适配各平台原生外观，并提醒性能/原生外观的权衡。整体怀疑点在于：要实现跨平台、原生感和良好性能，工程复杂度并非单靠 LLM 就能解决。
社区普遍认为 agent/LLM 在生成样板和快速原型上表现不错，但对一次性产出具有新颖交互、动画或高质量视觉细节的能力持怀疑态度。实例包括 LLM 倾向使用过时 API（如 AppKit）而不是声明式 SwiftUI，或在复杂导出/动画场景出现“janky”行为，需要人工多次介入与修补。也有用户报告在 Swift/SwiftUI 上通过 Claude Code 得到过较好结果，但总体共识是：LLM 可加速迭代与样板生成，但要产出可维护、精致的动态 UI 仍需人工工程师把关与调试。结论是当前阶段更适合做原型和样板，而非完全替代 UI 设计师/工程师。
一些长期 Raycast 用户担心公司把资源投入 Glaze 会影响 Raycast 主产品的迭代，尤其在此前 Raycast 曾暂停常规发布以做较大改动的背景下。评论中有猜测 Glaze 可能最初为内部工具或为团队定制，也有人将其解读为为被 Apple 等厂商收购做展示。反面观点认为产品线扩展和商业化举措是自然演进，但普遍期望 Raycast 仍把核心工具作为优先级，以免伤害现有用户群。整体是对公司重心转移的谨慎与怀疑情绪并存。
很多评论者为“vibe coding”式快速生成个人实用程序感到兴奋，举例包括轻量 menubar 实用工具、本地 whisper.cpp 语音转写、磁盘清理或 DNS 管理器等，这类工具比笨重第三方软件更轻、更可控。论点强调本地可修改、低内存占用和隐私控制，能够随时调整满足个人需求，类似早年 DOS/自助小程序时代的灵活性。如果 Glaze 能真正降低创建原生轻量工具的门槛并保证本地控制，会催生大量实用小工具并赢得产品思维强的用户群体。
一些用户把注意力放在产品命名上，调侃 “Glaze” 在俚语中的多重或粗俗含义，从而产生不少吐槽与笑话。此类评论虽非技术讨论的核心，但影响产品的首印象与社群传播。名字争议被用作对产品营销与命名敏感度的轻度批评，也反映了社区对新 AI 工具既讽刺又好奇的态度。
Claude Code: 基于大型语言模型的代码生成/辅助工具（用于快速生成应用原型与扩展），评论中被频繁拿来作为对比基线。
Electron: 基于 Chromium + Node.js 的跨平台桌面应用框架，界面像网页但打包成桌面应用，常被批评为体积大、资源占用高。
Tauri: 一种轻量的跨平台桌面框架，使用 Web 前端与 Rust 后端，目标比 Electron 更小、更安全。
SwiftUI: Apple 的声明式 UI 框架，用于构建 iOS/macOS 原生界面，评论中被视作实现原生外观与交互的关键技术。
React + Node: 常见的前端（React）与运行时/后台（Node.js）组合；Raycast 的扩展模型就是基于 React + Node 的渲染/运行思路。
CORS: Cross‑Origin Resource Sharing，浏览器对跨域请求的安全限制，导致某些 API 请求需要后端代理，桌面应用则可绕开此限制。
Vibe coding: 社区口语，指用 AI 快速生成小型、个人化工具或“凭感觉”快速编码的工作流，强调速度与可迭代性。
Xcode: Apple 官方的 macOS/iOS 开发环境与构建工具链，涉及编译、签名与证书，是构建 macOS 原生应用的核心。