每日AI新鲜事·10月16日早间版：DeepSeek故障补偿与RTX Spark

今天AI圈又有不少新消息.

今天咱们主要聊这么几件. 一是DeepSeek^广告又挂了, 二是多个代理一起跑留下的垃圾, 三是有人做了个USB小屏幕, 四是Postgres加锁那点事, 五是四家代理命令不统一. 深度环节聊两个, 英伟达RTX Spark, 还有代码作画对比.

嗯, 都是这两天挺热的事.

那咱们一条一条来, 先看新闻.

第一条, 刚看到Dev.to上有篇文章, DeepSeek的API部分挂了, 整整四小时五十二分钟.

这个时长挺尴尬的. 而且我看到聊天服务和V4 Pro、V4.1 Flash两个模型是一起挂的.

对, 官方反应倒是快, 按账号十月八号到十四号的消费额, 以赠金形式全额返还.

但这里有个关键错位. 它补的是你过去一周的消费, 不是你这次实际损失.

怎么说?

你想, 没响应的请求、重试浪费的token、客服成本, 全不在覆盖范围. 而且赠金优先于现金余额扣减.

哦, 那等于你还得先把赠金花完才能动现金. 这体验有点微妙.

文章里还有个数字挺扎眼. 自九月以来DeepSeek已经发生十三次故障.

十三次? 那作者给了什么建议吗?

主张利用OpenAI格式兼容性加备用供应商fallback. 但切换规则要严: 只在连接失败、超时、429和5xx时切, 400和401不切.

为什么400和401不切?

因为那是你自己的请求错了或者鉴权没过, 换供应商也救不了. 还有, 备用模型得重新评测, 每次请求要记录是哪家服务的.

这个工程细节很实在. 好, 第二条, 也是Dev.to上的, 多个AI编码代理一起跑, 会在磁盘上留下九种垃圾.

这个我太有感触了. 废弃的worktree、陈旧锁、没人合并的分支、隐藏refs、重复的node_modules.

还有占着端口的dev server和膨胀的.git目录, 对吧?

对. 每个代理只管自己那摊清理, 但worktree之外的共享资源就没人管了.

文章里提了个细节我印象很深, Claude Code的--worktree不会自动释放, Codex默认保留十五个.

而且git gc的延迟回收, 可能让空间好几周后才释放. Hermes 2.2.9加了自动清理, 但端口和gc还是不覆盖.

所以核心原则就是先跑只读命令看清单, 再删. 别上来就clean.

第三条, Reddit上有个项目挺有意思, 叫managents. 用一块四英寸的ESP32屏幕, USB连电脑, 实时显示多个代理会话的状态.

这个解决了真痛点啊. 切终端切到眼花. 电脑端跑个Go小工具, 自动检测Claude Code和OpenCode会话.

关键是它只发运行中、等待审批、完成、失败这些元数据, 不读代码内容, 数据全本地.

MIT协议开源, 一行安装, managents flash烧固件大概十三秒, 还带OpenSCAD的45度支架文件.

作者还在找社区帮忙移植Windows, 想扩展支持Codex CLI、Gemini CLI、Aider这些.

这种硬件小配件, 我觉得会越来越多. 因为代理多了之后, 你需要一个物理的仪表盘.

有道理. 第四条, Dev.to上有篇讲Postgres并发控制的, 标题就很硬, 说悲观锁和SELECT FOR UPDATE在金融系统里是必须的.

这个观点我同意. Postgres默认的Read Committed根本防不住丢失更新, 这在支付管道里是致命的.

文章用协作文档编辑做类比, 讲乐观和悲观并发控制的差别.

对, 而且它说死锁在悲观架构里是数学必然, 必须靠全局资源排序和指数退避重试来缓解.

还列了一堆生产陷阱, 比如连接泄漏、锁排序不一致、池耗尽、混用pool.query破坏事务隔离.

这些坑踩过的人都懂. 悲观锁安全, 但代价是连接池耗尽和死锁脆弱性.

第五条比较短, 也是Dev.to, 对比了Claude Code、Codex CLI、Gemini CLI和OpenCode四家代理的九个日常命令.

最典型的就是上下文压缩, 有的叫/compact有的叫/compress, 直接分裂了.

还有同名不同命的陷阱, /model是否持久化不一样, /clear清空范围不一样, /review在v2.1.223前后含义都变了.

所以作者建议以你实际安装版本的命令列表为准, 别信文档.

好了新闻就先聊到这儿, 接下来我们聊聊今天两个热点.

第一个, 英伟达的RTX Spark. 这个话题在RSS和YouTube上都有不少讨论, 多源印证.

RTX Spark这个定位挺清楚的, 就是冲着本地开发者的AI工作流去的.

所以它不是单纯的游戏卡路线了?

重点不在这里. 重点在于本地跑代理和本地推理的需求已经足够大了, 英伟达得给一块专门的卡.

可是本地推理这件事, 不是一直被云端压着吗? 成本、模型大小都是问题.

你反过来想, 如果代理要常驻、要读你本地文件、要低延迟, 云端来回传就是不舒服.

这倒是. 像刚才那个USB小屏幕, 也是同一个逻辑, 本地的东西要本地看得见.

对, 所以总结一下就是, RTX Spark代表的是本地AI工作流正在从极客玩具变成正经赛道.

好, 第二个热点, B站上有个视频特别火, Opus5.5和Gemini4 Argon的代码作画对比, 互动分六百多.

代码作画这个测试挺聪明的, 它同时考推理、空间想象和代码生成.

B站评论区吵得挺凶, 有人觉得Opus5.5的构图更稳, 有人觉得Gemini4 Argon颜色更放得开.

这种对比其实主观成分很大. 但能火说明大家真的在拿模型干创作了, 不只是写CRUD.

而且Gemini4 Argon是刚全球开放的, 一百万token上下文, 主打长程持续推理, 正好赶上这波对比.

所以它火是有窗口期的. 新模型一上, 大家第一反应就是找个刁钻任务来验货.

那结论呢? 谁赢了?

我觉得没必要分胜负. 这种作画对比更像是给两个模型画性格画像, 不是一个跑分.

行吧行吧, 那今天就先聊到这儿. 中午见!