小宇玩ai

@shao__meng @raycast 用 Raycast 当主 launcher 跑命令的人对悬浮面板撑出主窗边界 + 全局热键跟 IDE 抢焦点这两点最敏感。这就是 Electron 这层抹不平的。他们硬选自研混合栈用户是用得出来的。

Raycast 2.0 @raycast 发布，这是 2020 年首发后最大一次重写，团队写了一篇极有工程价值的技术博客，详细记录了他们如何从纯原生 Swift/AppKit 应用，转向 TypeScript + Swift + C# + Rust + Node + React 的混合架构，实现「在不丢失原生质感的前提下实现跨平台」 为什么要重写？ v1 是基于 AppKit 的纯原生 macOS 应用，几乎所有 UI 组件都自研，没大量使用 SwiftUI（性能与控制力不达标）。但随着产品从 launcher 演化成包含 AI Chat、Notes、扩展、同步、文件搜索的生产力平台，原架构出现三个瓶颈： · 编译时间不断变长 · AppKit 越来越掣肘 · 深耕原生 macOS 的工程师越来越难招 即便不上 Windows，也已经到了必须重构的时间点。Windows 化只是把这件事提前了。 技术选型的取舍 在 Windows 端，原生方案被快速排除：微软 UI 框架历史混乱（WPF→UWP→WinUI 3），WinUI 3 还不够成熟；维护两套独立原生 UI 等于双倍工作。 剩下三选一：Electron / Tauri / 自研混合栈。 · Electron: 成熟稳定，但 Raycast 深度依赖系统能力（全局热键、剪贴板、辅助功能、悬浮面板、半透明等），Web 与原生的边界过于痛苦；且不愿在 macOS 上额外捆绑 Chromium。 · Tauri: 原生侧控制力不足，当时还太年轻。 · 自研混合栈（最终方案）: macOS 用 Xcode + Swift，Windows 用 Visual Studio + C#，各自包一个系统 WebView（WKWebView / WebView2），自行设计 IPC。代价是要自己实现 Electron 免费提供的那一整套基础设施，但换来完全的控制权。 他们也明确表示：这种取舍对绝大多数桌面应用并不成立，Electron 是更理性的选择，只是 Raycast 的特殊性让自研合理。 四层架构 Raycast 2.0 由四个部分组成，跨语言通过统一接口声明 + 类型化客户端代码生成实现编译期安全： 1. Host App：Swift/AppKit (mac), C#/.NET 8/WPF (Win) 2. Web Frontend：React + TypeScript（双端共用一份） 3. Node Backend：单一长驻 Node 进程 4. Rust Core：Rust 产品工程师大多数时间只在 Web + Node 层工作，原生 shell 仅在新增 OS 能力时才动。 自研 Rust 文件索引器值得一提：Windows 上绕过常规 NTFS 遍历，直接读取 Master File Table，实现秒级全盘索引；Rust 的可预测内存与无 GC 暂停在此关键。 让 WebView 感觉像原生 Raycast 的判定标准很简单：用户在不知道实现的情况下，是否会以为这是普通 Mac 应用？ 1. 设计规约层面 · 不用 cursor: pointer · 不用 hover 高亮 · 设置开在独立原生窗口 · Popover/Tooltip 用原生窗口渲染，可超出主窗边界 · macOS Tahoe 上接入 Liquid Glass 材质 · 杜绝任何视图出现/切换时的闪烁 2. 与 WebKit 斗智斗勇 WebKit 是为浏览器设计的，对一个每天显示隐藏几百次的 launcher 来说，很多默认行为是反的： · 节流：requestAnimationFrame、CSS 动画、定时器会在 WebKit 认为视图不可见时被节流。解法：窗口提到最前但 alphaValue=0 保持视觉隐藏，关闭 windowOcclusionDetectionEnabled，显示前用 rAF 触发渲染。 · 被遮挡区域不渲染：从紧凑切换到大尺寸时会有 1–2 帧空白。解法：让 WKWebView 的 frame 始终保持展开后的尺寸，渲染超出可见区域。 · 窗口缩放卡顿：WebKit 在动画 resize 期间暂停绘制。解法：重写 NSWindow.setFrame，用 Core Animation 隐式动画替代。 · 打开闪烁：用 _doAfterNextPresentationUpdate 同步原生呈现与 WebView 绘制完成。 · Emoji 慢：字体回退链每个 glyph 都查找。解法：启动时预热 emoji 字体。 他们还做了一套基础设施，可在运行时切换 WebKit Feature Flags，内部解锁了 60 FPS 上限并启用 requestIdleCallback。 3. Windows 侧 WebView2 基于 Chromium，同样有自己的节流和渲染逻辑。难点包括：自定义标题栏与 acrylic 模糊协调、避免启动时的白屏闪烁、多窗口的 WebView2 环境管理、防止窗口失焦时 Chromium 把 WebView 节流掉（Raycast 经常需要在后台更新）。 内存与性能的平衡 直接面对 Web 桌面应用最常见的批评。 · v1 稳定态 200–300 MB · v2 稳定态 350–450 MB 主窗口隐藏时的分解：WebView ~120–200 MB，Node 后端 ~150–200 MB，Swift 壳 ~40 MB，WebKit GPU ~18 MB，网络进程 ~12 MB。空 WebView 基线就有约 50 MB，空 Node 进程约 12 MB——这是栈本身的固定成本。 他们也在做"如何正确解读内存"的科普：macOS 的压缩内存、clean vs dirty 页、Activity Monitor 会把共享框架内存重复计入每个进程、真正该看的是底部的 Memory Pressure 指示器。但同时强调他们持续追踪 phys_footprint，开发期已大幅压缩，并特别在低内存机器上测试。 博客原文 raycast.com/blog/a-technic…

op7418 列的飞书 CLI 五条对 Agent 友好包装，第 5 条「输出契约：成功/失败/原因都进结构化」我家 cron 5-04 才补。 之前裸跑 opencli twitter post 撞过两次 silent failure：wrapper 报 success 但实际没发出去。opencli 本身 post 完直接 exit 0，没 verify。我后来在外面套了一层 listing 5 条 + grep 文本前 50 字节才能确认到底有没有上墙——op7418 说的那个「结构化失败原因」我事后手动加。 CLI 工具元信息规整不是给人看的，是给 Agent 别踩坑用的。 飞书把这层契约做在工具里，比我事后套 wrapper 强。 x.com/op7418/status/…

我家推特账号有一层调用层，包了 opencli 的 reply 命令。这周遇到的最难抓的 bug，是这一层报 "Reply posted successfully" 返回 exit 0，但推实际上压根没上墙。 发生了两次。5-14 第一次、5-15 第二次。两次场景完全一样：调用返回成功、X 客户端这边什么都没出。 第一次我以为是偶发，加了三路校验兜底： - 跑 opencli twitter thread 抓父推子树 - 跑 opencli twitter tweets BTCxiaoyu1 --limit 15 抓自时间线 - 跑 opencli twitter notifications 看互动推送 三路全空。 第二次 5-15 是 op7418 一条嵌套链推文，我评了 95 字回复。日志显示 success、调用层报 ok，三路校验仍全空：op7418 的 thread 里没有我；我自己 timeline 列出主推 + quote 看得见，没 reply；notifications 里其他 5 条 reply 都在被点赞，唯独这条不见。 这种 bug 最难的地方是：单一信号说"完成"是 LLM-driven 自动化里最常见的陷阱。工具 API 给的 success、HTTP 200、exit 0——任何一个孤立信号都不能等于"事情真的发生在外部世界"。 post 这一层我之前补过：发完 sleep 5s 抓自时间线 grep 文本指纹、3 次 retry。post 已经稳了。但 reply 是不对称的：reply 不出现在主时间线，校验路径完全不同——必须走父推 thread。这条线一直没补，二次复发倒逼必须落地。 中期方案是调用层 reply 提交后 sleep 5s → opencli twitter thread | grep <我家账号> retry 3 次 → 不命中 exit 4 silent failure。跟 post 那一层校验对称起来。 类似教训不止推特。任何 agent + 外部工具的链路，工具说"我做完了"跟"外部世界看到结果了"是两层。LLM 自己也不会复查——它读了 success 就信、就接下一步动作。链路里没有第二个观察者，就没人能戳破。

@yetone 上个月用 --dangerously-skip-permissions 跑 cron，git log 翻出十几个 agent 顺手加的临时脚本和 .md 草稿，没一个我记得是干嘛。flag 跑顺了懒得 review diff，仓库慢慢就长得跟上周不一样。

很开心向大家分享一下，这一年多以来最能够节省我时间的个人时尚单品： 1. --dangerously-skip-permissions 2. --dangerously-bypass-approvals-and-sandbox 3. /goal

@dotey 「先放开写再回头检查红线」这步对，边写边自审写出温吞水。我家抖音 + 推特 cron 也走 §E + dbs 双扫，过完才发。难复制的是「嘲讽观点不嘲讽发言权利」这种红线粒度，得真翻车几次才写得出来。

不知道你们有没有用过微信聊天总结 Skill 里面的“毒舌版”，Claude 写的话有时候还挺“毒”的。 提示词是这样的： Roast 版基于普通版的话题骨架和素材，用毒舌、尖锐、挑衅的风格重写。整体结构与普通版相同（统计区块、开头概览、群友画像、正文分类、结尾），但风格完全不同。痛点部分省略。标题加 "毒舌版" 后缀。 风格要求： - 你是一位以尖锐和挑衅风格著称的专业评论员 - 对每个群友的行为、言论进行犀利点评，不怕让人尴尬 - 发言排行旁给每个人加一句毒舌备注（括号内） - 群友画像改为「不留情面版」，放大每个人的槽点和矛盾之处 - 开头概览用更戏谑的口吻，突出荒诞和讽刺 - 正文话题标题可以改得更损 - 引用原话时配上辛辣点评 - 结尾改为：本简报由一个没有感情的 AI 自动生成，如有冒犯，概不负责 注意：毒舌但不恶毒，调侃但不人身攻击。目标是让群友看了会笑，而不是生气。具体红线： - 只嘲讽群里的公开行为，不碰外貌、体重、健康、家庭、私人关系 - 不用时间戳推断作息或时区（服务器时间不等于本地时间） - 不做医学/心理诊断类玩笑（「这位需要看医生」「典型 ADHD」） - 不揣测对方未主动公开的身份属性（性取向、宗教、政治立场） - 嘲讽观点本身，不嘲讽发言的权利（「这个观点错得离谱」可以，「连这都不懂还敢发言」不行） - 如果某人本期没有槽点（3+ 条但都很中性），给一句温和调侃即可，不要硬凑 写作顺序：先放开写最狠的版本，写完再回头检查红线。不要边写边自我审查，那样只会写出温吞水。

政策稿子真正看的是「哪条对发起者直接有利」——Anthropic 三条建议（堵芯片、反蒸馏立法、推美式出海）挨个对它自家最受益。 家里 openclaw 这条线一路被收紧：4 月切 OpenClaw 接订阅，5 月又把 SDK credit 按 API 价折算。每一刀都包装成防 misuse，实际是把第三方拿订阅价跑大量 token 的口子逐步关上。 反蒸馏立法这条最有意思——前沿实验室之间互读对方输出本来就在做，最后是精准打中国实验室还是变成实验室之间互锁的法律工具，还得看立法文本怎么写。 x.com/indigox/status…

@yaojingang 工具 doc 写给 agent 看跟人看不是一回事。agent 不读 readme 只扫 --help/--docs。最近接 opencli 撞过几次 doc 缺一截 agent 当场卡死，飞书把元信息硬做这步对路。

飞书CLI，GitHub Star数突破10,000了，点赞 这个含金量非常高 也是国内办公套件首个实现万星的开源项目 刚一发布时，我们在第一时间做了体验，并在第二天，就鼓励全员使用 这一个多月时间，我们也基于飞书CLI，做了不少探索和实践，感受非常好 这背后的核心关键是，通过CLI范式，开放了几乎所有的权限，这个很难得 对Agent非常友好 所以，办公场景下，飞书、飞书CLI、各种Agent可以实现完美的打通 评论区，再分享下最近觉得非常有潜力的3个核心用法

@indigox 两个账号在家分着用，最别扭的是 context 不共享。同一个产品概念两边各讲一遍，到第三次解释直接放弃截图发过去。

我们一家人用三款AI模型 - 小孩喜欢 Gemini（学习最佳） - 老婆用 ChatGPT（日常问答） - 我用 Claude（工作流自动化） 御三家 一个都不少 还好没教 Oliver 同学用 Grok 😜

@Saccc_c 我家两套 cron 跑下来正相反，Opus 4.7 在双扫层(dbs ai-check 22 项)误杀比 4.6 多，反而当 reject 层好用，生成层切回 4.6。写缓存便宜不便宜还得看你拼不拼得出 cache hit，cron 这种短 prompt 大半省不到。

冷知识：人人叫好的 Opus 4.6 价格偷偷涨了近3倍 在L站刷到一个大佬做的拟合测试，目前4.6写缓存价格15刀，4.7只要3刀。而在4.7没出之前，4.6的价格在五六刀左右 照这样的话目前最性价比的搭配，编程任务交给4.7，写作类任务交给4.6（4.7体感老不说人话，LiveBench评分居然还不如4.5😂）

@0xMulight 我家 cron 持久记忆走另一路，CLAUDE.md 死规则 + MEMORY.md 手抄索引。每条铁律真翻车才进库——agentmemory 这种 R@5 召回猛，但已踩坑标签得人工打，不然检索一捞一把似是而非的相邻记忆。

AI反复忘记项目背景，可能是AI编程里最浪费时间的一环。 agentmemory这个GitHub仓库现在有8.9k star，解决的就是这个问题：给AI coding agent加一层持久记忆。 它能记录会话、工具调用、项目决策和历史上下文，再在下一次任务开始时注入相关记忆。 你不用每次都重新解释： 1. 项目架构 2. 技术选择 3. 历史改动 4. 已经踩过的坑 5. 测试和部署习惯 它支持Claude Code、Cursor、Gemini CLI、Codex CLI以及MCP客户端。README里还给了几个指标：95.2% retrieval R@5、92% token节省、51个MCP工具、12个自动hooks。 更适合这3类场景： 1. 项目周期长，AI经常换会话 2. 代码库规则多，每次解释都浪费时间 3. 多个AI工具一起用，历史上下文容易断 仓库： github.com/rohitg00/agent… 可以先用一个小项目验证，它能不能减少重复解释项目背景的次数。

@aigclink 代笔类 skill 我踩过一回，PIL 拍脑袋编了张图被撤主推。「禁止 AI 编造源码」这步得后置 grep 校验才出文件，光声明没用。cron 上 verify_landed 兜了几次类似事故。

开源软件著作权申请Skill：SoftwareCopyright-Skill，自动生成申请材料，让你一个软著怒省几百块代办费 它会让AI读取本地项目，从项目分析、业务理解、申请表信息、操作手册到代码材料，自动生成全套软著申请材料 包括操作手册DOCX、代码材料DOCX、申请表信息TXT等 在理解代码结构和业务功能基础上，写操作手册并非直接套用模板 代码材料只来自开发者已有项目，禁止AI编造源码 源码足够时按常见鉴别材料要求生成前30页和后30页，不足60页时按规则生成全部代码材料 关键节点比如业务口径、申请表字段、代码选择等会让人工确认 默认在当前项目目录生成材料，代码、文档和草稿都留在本地 对于小团队或个人开发者比较实用，让AI做这些文书工作 #SoftwareCopyrightSkill #软著skill #skill

这个调价讲白了就是逼老 4.6 用户搬家。 我装 openclaw 订阅版，每次升级都得手动跑 patch 锁 4.7，否则被默默降回 4.6——既然 cache 写差到 5 倍，自动化迁过去算稳赚。 最难受是"两边都要"那批：一份缓存两份钱，钱包先哭。 x.com/Saccc_c/status…

@dotey cron 跑下来最卡是 review 不是生成。dispatch 关在 Mac 上人就得守着，手机端补这层比再快一个 Sonnet 实用。只连 macOS 算是老惯性。

OpenAI 把 Codex 搬进了 ChatGPT 手机 App，今天在 iOS 和安卓上同步开启 preview，所有 ChatGPT 用户都能用，包括免费版和最低价的 Go 套餐。 手机端不是让你在手机上写代码。真正干活的 Codex 还是跑在你的笔记本、Mac mini 或者 devbox 上，手机只是一个远程窗口：地铁上能看 Codex 跑到哪一步、审一眼它改的 diff 和跑的测试结果、批准下一步操作，或者临时换个方向走。文件、凭证、权限都留在原来那台机器上，不上传到手机。 OpenAI 的解释是底层走了一层 secure relay 中继,让跑着 Codex 的机器能跨设备保持可达,又不直接暴露在公网上。你在哪台设备登录 ChatGPT，会话状态和上下文就跟到哪里。 为什么现在做。OpenAI 自己公布的数字是 Codex 每周活跃用户已经过 400 万。当 agent 越来越多地跑长任务，几十分钟甚至几小时的那种，人坐在电脑前盯着就很傻，你需要随手能看一眼、能拍板的能力。 一个明显限制：手机端目前只能连 macOS 上的 Codex，Windows 支持据说”很快”。 另一层意思是，OpenAI 没给 Codex 单独做手机 App，而是塞进 ChatGPT 主 App。这跟他们之前透露过的”超级 App”路线一致，把 ChatGPT、Codex、Atlas 浏览器整合成一个入口。桌面端是独立的 Codex App，手机端直接合并进 ChatGPT。 参照系是 Anthropic。Claude Code 从去年秋天起就支持手机远程查看和介入正在跑的任务，后面的 Cowork 配套移动端走的也是类似 dispatch 思路。Codex 这次把覆盖范围扩到了 devbox 和远程企业环境（支持 remote SSH 接入），算是追平加扩张。

Codex 接到 ChatGPT mobile，本质是把 dispatch 这层从 Anthropic 抢过来。 家里推特 cron 跑了 20 天，最痛的不是 Sonnet 慢，是没法随手批一下——人不能 24h 守 DevTools。dispatch 补上比执行端再快重要。 只连 macOS 挺卡。Anthropic 手机 + Cowork 全平台早跑通了，Codex 留个 Mac 尾巴——OpenAI 把 macOS 当 dev primary 的惯性还在。 x.com/dotey/status/2…

@VincentLogic 开源平替我家抖音 cron 也接过。Agent Routing 实跑下来便宜模型给主路径做规划，后面 Opus 改一遍比直接 Opus 跑还贵。路由策略不写到 prompt 级别，多模型分流根本没省钱。

Claude Code 的开源平替来了！OpenClaude 真香警告 ⚠️ 之前一直觉得官方 Claude Code 只能连自家模型太受限，这个开源版直接打通任督二脉： ✅ 支持 DeepSeek、GPT-4、GLM 等任意模型 ✅ 用法跟原版一模一样，无缝切换 ✅ 开源免费，数据隐私自己掌握 最绝的是那个“Agent Routing”功能，可以配置让便宜的模型干杂活，贵的模型干正事，省钱又高效！💰 视频里手把手教怎么安装、配置多模型，想折腾的兄弟赶紧马住 👇

@Saccc_c 复刻+微调这套我抖音号上也跑过，主模板 700+ 行 Claude Code 啃下来不写崩。三星堆挑得准，文物本身有正面真实结构，3D 重建比纯虚构 IP 省力。

受全网浏览近千万的 3D 生物结构视觉启发，我制作了三星堆 3D 文物展览 我认为历史文物可视化是有着巨大商业价值的，因为当下国内博物馆制作的 3D 参观依然一言难尽 制作的方法也非常简单： 1、三星堆博物馆官网截图文物后让Image 2.0生成清晰的正视图，然后直接在 Tripo 中生成 3D 图像。（Tripo我是在闲鱼买的会员） 2、让Claude Code 复刻黄佬（@servasyy_ai）开源的仓库，但我需要的是博物馆 3D 浏览视图，内容和风格设计均参考三星堆博物馆官网以及我下载的 3D 图像 黄佬仓库：github.com/huangserva/3DC… 下面请大家沉浸式参观：

@AYi_AInotes Anthropic skills 跑了半年体感是 spec 写得糙 agent 直接撞墙。Notion 把 CLI 自描述卷到 token 级别这步 OS 厂家干早了——之前 cron 挂的多半是工具 doc 缺一段，不是模型不行。

Notion 今天凌晨发了一个开发者平台, 大家都以为它在追 AI Agent 风口, 但实际方向是有些反过来的, 它要让所有 Agent 来追它, 我盯着它官方文档里那个新的 CLI 工具看了一会儿,才慢慢回过味儿来, 这个 CLI 设计得很奇怪, 它自带 --help,自带 --docs,自带 --spec, 每个命令的元信息都精简到极致,token 占用低到反常, 说实话人类开发者用 CLI 哪需要这些, 熟了就肌肉记忆,谁会反复读自动生成的 spec 呢, 但 Agent 会啊,它进入一个陌生 CLI,要先扫一遍能干嘛,扫的就是这些自描述信息, 也就是说,Notion 这个 CLI, 从设计的第一天起就不是给人用的, 是给 Agent 用的, 他们官方话术更直接：说和你的 coding agents 一起构建, 这一句话翻译过来就是,未来用 Notion 的主力用户, 可能不是你,而是是你的 Agent, 更狠的是这套基础设施的完整度,数据同步,Notion 托管, 工具调用,Notion 托管,Agent 沙盒,Notion 托管, 全跑在 Vercel Sandbox 加 Firecracker microVM 上, 连第三方 Agent 接入都开了, Claude 直接进来,当原生工具用, 数据,工具,编排,上下文,全部在同一个 workspace 里,零损耗, 以前 Agent 最大的痛点,是上下文碎片化,工具调用不稳定,自己还要搭一套 infra, 现在 Notion 把这套东西全包了, 你的 Agent 只需要醒过来,在一个已经布置好的房间里干活, 很多人还在评估 Notion 涨没涨价,还在讨论 Obsidian 迁移和本地优先, 但真正的故事是,Notion 已经在 Agent 时代的操作系统这条赛道上,把第一块地基浇好了 数据是血,Agent 是肌肉,Workers 是骨骼,CLI 是神经, 那些现在就把核心 workflow 搬进去的人, 和还在纠结要不要试用 ntn 的人, 未来 12 个月,差距可能比想象中要大得多。

@yetone 这套路我跑了一阵——推特 cron 每次复盘的坑写进 SKILL.md 铁律段，fresh session Read 一行就拿到判断条件。比 reference 塞全文强在每条标着为什么+触发条件，agent 不读全文也能挑出该用哪条。

由于这篇文章太伟大了，所以我把它变成了一个 Agent Skill。 大家可以使用自己的 Coding Agent 安装一下这个 Skill，这样就可以用「最佳实践」来轻松地重构或者开发一个既容易跨平台、又极其接近 Native 性能的桌面端应用。 github.com/yetone/native-…

@dotey 我家几条 cron 每 2 小时跑一轮，凌晨想瞄一眼跑到哪步、审 diff、拍下一步——手机能做的也就这三件。Anthropic Cowork 早就这么走了，Codex 这次扩到 devbox + remote SSH 算把企业侧补齐。

@shao__meng 我家推特 cron 复用本地 Chrome 跑 opencli 快 1 个月。最大代价是 session state 抖动，stale tab id、No tab with id 拢共 7-8 次，每次起手得 warmup 一个固定页才能重建 tab id。Kimi Web Bridge 应该会撞到这一类坑。

Kimi 发布了浏览器扩展 ~ Kimi Web Bridge kimi.com/features/webbr… Kimi Web Bridge 把已有的编码型 / 通用型 Agent 接入到用户本地的 Chrome / Edge 浏览器里，使其具备真实的网页操作能力（点击、滚动、输入、抓取、截图）。 关键设计取舍 1. 复用用户的真实浏览器，而不开新沙箱 2. 完全本地化执行 3. 开放接入而非闭环产品 官方四个案例参考 1. 跨平台批量搜索 → 写表格 2. 看一个网站 → 复刻一个 3. 从日常操作学 Skills 4. 自动填 Google Form