Claude Sonnet 5 实测:能力媲美 Opus 4.8,高性价比编程新选择
Anthropic 全新模型 Sonnet 5 已经悄然而至,如果你还在抱怨 Opus 4.8 近期的“降智”表现,那现在答案很清晰了——资源正在向这颗新星倾斜。快速翻看官方博客,可以用一句话概括:Sonnet 5 主打“物美价廉”,是日常工作和编程场景中极具性价比的模型。

物美:全方位性能跨越
对于习惯使用 Sonnet 4.6 的用户来说,这次更新带来的提升几乎是质变。

Sonnet 5 在推理、工具调用、编码和知识工作等领域比前代 Sonnet 4.6 拥有显著增强,各项基准指标全面跃进,综合表现已十分贴近 Opus 4.8。这意味着 Sonnet 5 是一款全能型的工作模型,尤其是在智能体编程能力上实现了巨大跃升。知识工作方面的进步同样惊人,甚至在部分场景中超越了 Opus 4.8。
除了漂亮的跑分,它依然延续了标准的 100 万 token 上下文窗口。思考模式也从原先的“扩展思考”升级为自适应机制:
Adaptive thinking replaces extended thinking. It’s on by default in Claude Code and the API. Start at medium effort, and bump to high for long agentic runs or memory-heavy work. Most coding and tool use won’t need more than that.
Claude账号大规模封禁:多位知名博主中招,新版Code内置地区识别
自昨日起,多位知名技术博主的Claude账号陆续遭到封禁。据多个社区消息,包括阮一峰、轩辕、架构师专栏及数字生命卡兹克等在内的头部创作者均受到影响。以下是部分博主账号被封的截图:




据悉,Claude Code v2.1.195及以上版本已集成区域识别功能,若想降低风险,可考虑使用更早期的版本。当前最新版本为v2.1.197,版本号对照如下:

日常使用Claude Code搭配国内模型的用户无需过分焦虑,本轮封禁主要针对的是国外模型账号。
ClawdBot远程操控电脑AI助手搭建全攻略:从零到自动化
出门在外,随时用手机让 AI 查看服务器状态、处理邮件、甚至调试代码——这个开源项目让我真正拥有了一个“数字管家”。
今天刷 Twitter 时,发现时间线被一个叫 ClawdBot 的项目刷屏了。
点进去一看,原来是一个开源的 AI 助手框架,功能相当强大:通过 Telegram/WhatsApp 远程控制电脑、自动处理邮件、定时执行任务,甚至有人用它和 4S 店砍价省了 4200 美元。

我正好有台闲置的 VPS,决定尝试一下。结果这一试,踩了不少坑。官方文档比较零散,很多细节需要自己摸索。下面就把我的安装配置过程记录下来,为想尝试的朋友节省时间。
一、认识 ClawdBot
简单来说,ClawdBot 是一个 本地运行的 AI 助手网关。
它的核心是一个 Gateway 进程,主要负责三件事:
- 连接聊天平台:支持 Telegram、WhatsApp、Discord、iMessage 等
- 调用 AI 模型:兼容 Claude、GPT 以及各类本地模型
- 操作系统资源:执行命令、读写文件、控制浏览器、管理定时任务
你可以把它理解为一个 7×24 小时在线的 AI 员工。它有记忆(记得之前的对话),有执行能力(能操作你的电脑),还会主动工作(定时任务、邮件监控)。
根据 Mashable 的报道,这个项目火到连 Mac mini 都一度缺货——不少人专门购买小型主机在家运行它。
不过我认为没必要这么“硬核”。一台普通的云服务器就足够了,月费几十元,即使玩坏了也不心疼。
二、它能做什么?
搭建完成后,我亲身体验了几个实用场景:
- 随时随地远程操作:在手机上给 Bot 发送指令,秒级响应。出门在外也能轻松管理服务器。
- 实时查看服务器状态:让它执行
htop或检查 Docker 容器,并截图返回。 - 自动化定时任务:每天早上 7 点自动发送服务器健康报告。
- 辅助编程与调试:将报错信息发送给它,能直接获得修复方案甚至修改代码。
网上还有更多高阶玩法:
- 邮件自动化:每 15 分钟检查一次收件箱,自动归档垃圾邮件,重要邮件即时推送摘要,还能模仿你的语气起草回复。
- 智能笔记整理:连接 Obsidian,自动更新每日笔记,从会议记录中提取待办事项,生成每周回顾。
- 夜间持续集成:睡前提交一个 Bug,它会持续调试、提交代码、运行测试,第二天早上 Pull Request 就已就绪。
- 智能家居控制:在家休闲时,通过手机指令调节灯光、查询天气、设置闹钟。
当然,这些高级功能需要配置额外的 Skills 和集成。本文先介绍基础安装,目标是实现能对话、能执行命令。
Cursor iOS 原生应用公测:AI 编程进入异步 Agent 时代,Composer 2.5 限时 75% 折扣

Cursor 的 iOS 原生应用终于进入公开测试。它并不是让你在手机上敲代码,而是让你在任何场景都能启动和调度云端 Agent。这一动作标志着 AI 编程工具正式从「桌面 IDE」迈向「异步 Agent 平台」。
截至 2026 年 3 月,Cursor 年化经常性收入已达 20 亿美元。与此同时,Composer 2.5 模型正在 iOS 端内提供 75% 的限时折扣,持续到 7 月 5 日。公测日则是 6 月 29 日。
iOS 端,到底能做什么
Cursor for iOS 当前对所有付费用户开放。它的核心不是替代桌面端写代码,而是把 Agent 的启动、调度和审批从电脑前解放出来。移动端提供两个关键能力:
● 云端 Agent 启动:打开 App,选择代码仓库,像在桌面端一样启动 Agent。它支持语音输入和 slash 命令,Agent 运行在云端隔离虚拟机中,完全不依赖你的电脑是否在线。
● 远程控制:如果你已经在电脑上跑着 Agent,用手机就能远程操控——查看进度、追加指令、审批 PR,不用守在屏幕前。
● 通知体系:Agent 完成工作、需要输入或准备就绪时,会通过锁屏 Live Activities 和推送告诉你。即使离开 App,Agent 也会继续跑。
价格与促销
Pro 计划每月 20 美元(个人),包含 Cloud Agent、MCP 和 Skills。Teams 计划每人每月 40 美元,额外提供团队 marketplace、Bugbot 和 SSO。Enterprise 计划需要另行商议,包含 SCIM、审计和池化用量。
DeepSeek V4千亿MoE本地运行实战:llama.cpp新合并全解析,1M上下文触手可及

llama.cpp 近期正式合并了对 DeepSeek V4 的推理支持(PR #24162),这让用户在个人设备上也能体验拥有百万级上下文窗口的千亿参数混合专家模型,而不再需要依赖云端算力。此次合并备受关注,在 Reddit 的 r/LocalLLaMA 板块引发了超过 200 条讨论。
1.6T / 49B
总参数 / 激活参数
1M / 384K
上下文 / 生成长度
~748 / ~20
预填 t/s / 生成 t/s(Flash Attention 下)
本次合并由开发者 am17an 主导推进,fairydreaming 负责 CUDA 优化与 Flash Attention 集成,经 CISC、ggerganov 等人审阅,历时 49 次提交完成。合并的 PR 完整覆盖了 DeepSeek V4 两款产品:V4-Flash(284B 总参数,13B 激活参数)与 V4-Pro(1.6T 总参数,49B 激活参数),统一使用 deepseek4 架构标识。
对于热衷本地推理的用户而言,这是 DeepSeek V4 自 4 月 24 日开源以来,在开源推理引擎生态中走出的最关键一步。
压缩注意力:百万上下文能在单卡上跑起来的秘密
DeepSeek V4 在架构上区别于 V3 系列的最大创新在于注意力机制。它没有沿用标准全自注意力或多层稀疏方案,而是设计了一套名为 CSA + HCA 的混合压缩注意力架构。
Deepseek对线实战指南:告别翻车,用拆解与验收提炼核心方法论
Deepseek作为国产之光,凭借极其亲民的价格在国内迅速普及,几乎每位接触AI工具的人都会使用Deepseek。
很多人用Deepseek的方式往往也比较直接——既然便宜,索性什么都往里扔。
我也是这样起步的。写方案、改代码、加功能、修bug,统统扔给Deepseek。
结果怎么样呢?每一次修改都带来新的问题,重新修改又引出更多的故障。那段时间几乎天天跟它对线,心态都快被击溃。
于是下意识觉得是模型能力不行,又开始自我安慰——“都已经这么便宜了,一分价钱一分货,还要啥自行车,自己忍着吧。”
然后继续使用。
后来用得多了,渐渐发现——并不是Deepseek的问题,而是我自己的用法出了问题。每一个模型都有它的性格与边界,你需要学会如何跟它打交道。
为何Deepseek修改代码时常翻车?
Deepseek的优势人尽皆知,价格被打到了冰点,因此成为每个AI玩家的标配。但便宜也有便宜的代价,它的推理能力的确逊色于顶级模型。
这并不是说它不好,而是你必须认清它的能力边界。就像不能让一个实习生去负责整个项目的架构一样,你也不能把一坨复杂的代码直接丢给Deepseek让它修改。
我最开始犯的错误就在这里——太过贪心。一个功能改动下去,涉及七八个文件、几百行代码,通通塞给Deepseek。结果它改完之后,这里漏掉一个引用,那里改错了一段逻辑,整个项目跑起来全是问题。然后我继续对它说“这儿不对”“那儿也有问题”,它便接着改,越改越乱。
最后发现,还不如自己手动修改来得高效。
核心策略:驾驭Deepseek的正确姿势
后来慢慢摸索出了一套跟Deepseek对线的套路,说白了就是一个字——拆。
第一步:任务分包,切分至最小可执行单元
绝对不能把复杂的内容直接塞给Deepseek。必须拆解成最小的可执行单元。
什么是最小的可执行单元?就是一个文件、一个功能点、一次bug修复。比如页面布局存在问题,你就只跟它讨论这个页面的布局,不要顺带提弹窗的样式也要调整。一次只谈一件事,改完验收通过之后,再去处理下一件。
小技巧:如果这个功能牵涉到多个文件的改动,那就需要格外谨慎。多文件改动时Deepseek极易丢三落四。单文件可以放心交付,多文件则必须提前做好拆分规划。
第二步:先询问再动手,确认无误再执行
这是我在踩了无数坑之后提炼出的铁律。
在让Deepseek动手改代码之前,先让它确切阐述要修改的内容——要调整哪些文件、每一处具体修改什么、修改完后会不会对其他功能造成影响。这一步可能会耗费不少时间,但绝对值得。
因为你自己心里必须有一杆秤,哪些地方它说漏了、哪些地方它考虑得过于简单,你都要能看出来。如果它列出的影响范围跟你脑中推测的不一致,那就继续追问。比如你觉得修改A会波及B,但它没有提到B,你就直接问它“这块改动会不会影响B”。
只有问清楚了,确认它已经完全理解,再放它去执行。
这一条是最核心的原则。无论用什么AI工具,切换到Deepseek时都要这样操作。并且非常关键的一点是——务必把AI工具切换成ask模式,否则它可能会自作主张直接上手改代码。
如果你的AI工具没有ask模式,那就在AGENTS配置里约束它的行为。
个人小心得:如果Deepseek的回答明显不合逻辑,或者追问几次之后它仍在反复变更说法,果断新开一个窗口重新开始。那个上下文的可靠性已经废了,不要在这上面继续耗费时间。
第三步:坚守单文件原则,多文件需慎重
单个文件的修改可以放心交付,多个文件的改动则风险成倍增加。
这是我的另一条经验。一般来说,涉及三个以上文件的改动,让Deepseek来承担的风险急剧放大。它会遗漏文件、记错路径、甚至改完A之后彻底忘记B的存在。
所以,在动手之前,我会让Deepseek把需要改动的文件列出来过一遍,如果数量太多,我就要仔细斟酌是否值得交给他去执行。
第四步:把控代码行数,小规模改动性价比最高
除了文件数量之外,代码量也是一个必须考量的因素。
代码量庞大的模块绝对不要直接丢给Deepseek修改。简单的小bug修复、小功能更新才是最适合它的场景。改动的行数越多,它顾此失彼的可能性就越大。
具体多少行算多并没有标准答案,使用多了自然会形成直觉。但大方向很清楚:改动越大越需要强力模型,改动越小Deepseek的性价比就越突出。
第五步:最终验收,决不轻信“已经完成”
Deepseek改完之后,务必亲自跑一遍验证。不要轻信它说的“改好了”,一定要亲眼看到结果才可以。
现在的模式基本上是AI来执行,人类来验收。因为产出最后是给人看、给人用的,所以这一步绝不可省略,是目前必须坚守的底线。
如果跑起来后发现还有问题,先判断是小问题还是大问题。小问题可以继续沟通修复;大问题——涉及逻辑重构、多个文件联动的那种——要么自己亲自修改,要么切换到更强的模型,不要再跟Deepseek死磕。
Deepseek适用场景速查表
根据自己的使用经历,我整理出了一份大致的判断标准:
| 情况 | 适合Deepseek | 建议换好模型 |
|---|---|---|
| 单个文件改动 | 是 | |
| 涉及3个以上文件 | 是 | |
| 代码行数少(几十行) | 是 | |
| 代码量大(几百行以上) | 是 | |
| bug修复、小功能更新 | 是 | |
| 架构设计、模块重构 | 是 | |
| 你清楚影响范围 | 是 | |
| 你不确定会影响到什么 | 是 |
这张表格无需死记硬背,用得多了自然就知道什么情况该用什么模型。
这里有一个常见的陷阱:不要因为Deepseek便宜就什么都往里塞。省下的那点token开销,很可能远不够填补你在调试上所浪费的大量时间。该用好模型的地方,千万别省。
换个视角:对线亦是架构力修炼
跟Deepseek对线其实还有一个隐性的收益——它会倒逼你把项目理解得更加深入。
Docker部署多端漫画阅读工具JM Boom:威联通NAS搭建全攻略
本期分享一款基于Docker部署的正规漫画阅读工具,效果如图所示。它不依赖特定客户端,完全没有广告,使用体验十分出色。

项目亮点
JM Boom 最初是基于 Tauri 框架打造的跨平台桌面应用,支持漫画搜索、收藏、阅读历史追踪、章节缓存和离线阅读。项目的 feat/docker 分支将前端与后端整合为一个 Docker 镜像,部署完成后无需安装任何客户端,只需浏览器即可访问所有功能。
需要说明的是,JM Boom 并不是 Kavita、Komga 这类本地漫画文件管理器。它是一款针对特定第三方内容服务的非官方客户端,所有内容展示均依赖第三方接口。
部署流程
以威联通NAS为例,通过 Docker Compose 即可快速部署。
部署配置如下:
services:
jm-boom:
image: ghcr.io/ppxb/jm-boom:latest
container_name: jm-boom
restart: unless-stopped
ports:
- "6699:3000" # 左侧端口可自行修改
volumes:
- /share/Container/jm-boom/data:/app/data
environment:
RUST_LOG: "info,jm_boom_server=info"
JM_BOOM_ACCESS_PASSWORD: "qnap1234" # 服务验证密码,请换成自己的
JM_BOOM_CACHE_MAX_MB: "5120" # 缓存大小,示例为5GB
security_opt:
- no-new-privileges:true
在威联通的 Container Station 中创建新的应用程序。

如果服务无法启动,查看日志后很大概率会遇到数据库文件权限问题,如下图所示。

此时通过 SSH 或 Web 终端,为挂载目录赋予正确权限即可解决。

使用简介
部署成功后,使用浏览器访问 NAS_IP:6699,密码为配置时设置的 qnap1234。
EgoLite Agent浏览器发布:为AI智能体打造底层浏览工作台
刚还在借助 Agent 收发邮件,此刻已经让 Agent 驱动浏览器主动采集信息——AI 的边界,又一次被拓宽了。
1
最近我在深度体验一款名叫 Ego Lite 的浏览器工具。这款浏览器,是专为 Agent 准备的。例如,我在 Agent 工具 Codex 里发出这样的指令:
@ego lite 看下 mowen.cn 里,首页“正在关注”中有哪些更新,取前二十条,包括作者、文章名称(附链接)与文章摘要。

在此过程中,Ego Lite 的人机界面纹丝不动,Agent 也不会像在传统方案中那样弹出新的浏览器窗口——比如 Codex 直接驱动 Chrome,在你的窗口上点来点去翻找内容。Agent 只在背后安静工作,最后把结果输出给你。这,就是 Agent Browser。
2
此前我推荐和使用过的 AI 浏览器(Dia、Tabbit 等),是把大模型植入浏览器,经过大量工程化适配,让用户在阅读、查找、翻译、重构页面、总结和写作时,能快速与 AI 协同。这类浏览器确实好用,但它们是为人类设计的。
Ego Lite 实则是给 Agent 用的——当然人类也能操作,这一点与我们之前介绍过的 QQ 邮箱团队出品的 Agent Mail 如出一辙。Agent Mail 更为激进,甚至移除了人类操作入口,只能由 Agent 来执行邮件任务。
让 Agent 打开浏览器,过去的方案基本是 Computer Use:操作电脑打开浏览器,完成打开网页、滚动、点击、复制、整理等步骤。Agent 要解决的是保持登录态、看懂页面结构、准确点击按钮,必要时还要从页面脚本里抓取真实数据接口。Ego Lite 的做法并非让 Agent “看”网页,它更像一个坐在浏览器背后的程序员。页面只是入口,DOM、网络请求、前端 bundle、返回的 json、并行任务……这些才是 Agent 真正要处理的对象。也就是说,浏览器本身成为了 Agent 的工作台。
Fable5出口管制解除:18天暂停后的回迁策略与工程验证


出口管制被撤销,模型重新上线;在一些叙事里这被视为政策出现了转弯,而在另一些语境里,它更像一次工程能力的短暂回撤。
6月30日,美国商务部长Lutnick签署文件,废止了6月12日针对Claude Fable 5和Mythos 5的出口管制令。这意味着此前被阻断的模型重新回到无需逐客户许可证的通用使用状态。18天的空白,对一个大模型而言几乎和一次反向升级一样短。
先要把一件事看清楚:Fable 5并不是传闻中的下一代旗舰。它是Anthropic在6月9日正式发布的模型之一,定位侧重代码生成与Agent任务,和Opus 5、Sonnet 5的参数路线并不重合。6月12日,Anthropic收到美国政府的出口管制指令,被要求暂停该模型面向某些区域的访问;社区把这条信息和对华芯片整体管制放在一起传播,结果造成了一次被放大的震荡。
真正应该关注的,并不是撤销令本身那个动作,而是Lutnick在撤回令里使用的表述:「取消逐客户许可证」「恢复通用用途」。这转译成工程语言就是:如果你们的团队在12日之后已经迁移到其他模型上,现在可以有条不紊地回来做回测,但迁移成本真实存在,不会因为一纸撤令就自动消解。
18天意味着什么?
从6月12日到6月30日,Fable 5并非完全消失,只是在部分场景中被暂停。那些已经上线并依赖它运行Agent、代码审查或客户集成的团队,在这18天里用Sonnet 5、Claude Chemistry和本地模型作为替代,不算完全荒废,但切换成本不容忽视。
边注:产品发布、政策逆转、社区讨论是三件速度完全不同的事。当讨论跑得比政策快,很容易把一个局部调整读成全局信号。Fable 5只是单个模型解禁,和整体AI管制基调之间不存在等号关系。
我建议的回迁节点判断很简单:先确认你们6月12日之前的基准评测是否依然有效,再拿两份同期真实任务分别跑一遍Fable 5和替代模型,不要在乐观情绪里直接切回来。控制变量,是衡量这18天切换成本最终是否值得的关键。
“解禁”和“上线”是两场戏
出口管制撤除是政策动作,平台恢复访问是工程动作。前者已经在6月30日完成;后者是否生效、何时在你的企业账户上落地,取决于你们所接入的API供应商、结算地区以及模型路由层是否已经完成更新。常见的坑在于:调用接口仍然回退到地区限制的模型,或计费资质没有随解禁而重新开通。
如果你现在就在使用Claude API,去检查两件事:一是路由里的模型ID是否被硬编码成了sonnet-5等非目标模型;二是6月12日之后有没有更换过账户或变更过账单。模型解禁并不会自动修复这些预埋的逻辑,而大多数团队的注意力会放在「现在能不能用」上,却漏掉了「为什么我的调用还没切回来」。
「解禁」是把门开了一半;另一半留在工程侧。政策不会明说,代码也不会自己切换。
适合立刻回测,不适合今天切回
Fable 5的标签是「代码专家 + Agentic工作」。如果你的系统在过去半个月里为了绕过管制,已经迁到了本地模型或者更轻量的替代方案上,那么比较基线就已经在你手里了。现在正处在最安全的回测窗口,带着真实任务重新跑一次,结论会非常清楚。
判断:Fable 5解禁之后的最佳动作并不是「切回来」,而是「先验证、再决策」。两个月的迁移成本已经付出,让它毫无意义地沉没是另一种浪费。
出口管制从来不是模型能力的度量,它是政策工具。一旦撤除,真正让你的系统重新连上的,不是欢呼,而是账户层、路由层和测试层的逐一验证。
GitHub 7.3万 Star!截图直接变代码,这个 AI 项目把原型稿搬进终端编码流程
产品同学扔过来一张截图,说“按这个做一版”。终端里的 AI 编码代理当然能写前端,但麻烦总卡在第一步:你得先把布局规则、颜色值、字号层次、交互状态一点一点用文字描述清楚。话说少了,它容易自由发挥;说多了,你自己都快变成人肉标注工具。
小G最近仔细看了一个老牌开源项目,叫 screenshot-to-code。

它要解决的正是这个环节:把截图、设计稿导出的图像、网页录屏,先转化成一份能直接运行的前端代码。然后你再把这份代码交给 Codex、Claude Code 这类终端 AI 编码代理,去拆组件、接接口、补状态管理,整个过程会比面对一个空白文件高效许多,来回沟通的成本明显下降。
先说清楚,它本身并不是终端 CLI 代理。
它是一个 Web 应用,前端用 React/Vite,后端用 FastAPI。在本地跑起来后,你在页面上传截图或视频,系统通过模型生成代码,并在浏览器里直接预览效果。小G更愿意把它当成“终端编码代理前面的 UI 草稿机”。

它到底能生成什么
这个项目当前支持的前端技术栈有 6 种:
- HTML + Tailwind
- HTML + CSS
- React + Tailwind
- Vue + Tailwind
- Bootstrap
- Ionic + Tailwind

输入也不限于单一图片。一次最多可以上传 5 张截图,或者 1 个视频;支持的格式包括 PNG、JPG、MP4、MOV、WebM;单个文件上限 20MB,视频提示最长 30 秒。另外也支持通过 URL 截图,但需要配置 ScreenshotOne API Key。
这里有一个容易产生误解的地方。README 里提到了 Figma designs,但当前前端代码中,直接粘贴 Figma 链接会提示不支持。正确的用法是把 Figma 画板截图,或者导出成图片,再通过 Upload 入口上传。这不是大问题,但别把它当成可以“直接接入 Figma 文件”来使用。