AX 严选 · 2026-05-14

这条推文讲了一个很实用的 Claude API 调用技巧：预热提示缓存。做法是在用户请求到达前，先单独发一次系统提示给 Claude，让它把提示写进缓存，但跳过输出。等真实请求进来时，缓存已经热好，直接命中，省掉重复处理长提示的时间。 这个思路适合系统提示固定、用户提示多变的场景，比如客服机器人或带固定人设的对话应用。但正文没披露具体能提速多少，也没说缓存能热多久、会不会被清掉。这些在实际落地时都是关键变量，得自己压测验证。 另外要注意，预热请求本身也消耗 token，虽然不生成输出，但系统提示的输入 token 还是要算钱的。如果请求量不大，这个预热成本可能比直接跑还高。建议先拿自己的典型 prompt 长度测一轮，看首 token 延迟降了多少，再决定要不要加这层逻辑。

这次更新主要让 Claude Code 在后台跑任务时更可控。新增的 8 个命令行参数，比如可以设闲置多久自动关掉会话、最多同时跑几个后台任务，对用脚本批量跑代码或长时间挂任务的开发者比较实用，能省点资源、避免后台进程堆满。Fast 模式默认模型从旧版切到 Opus 4.7，意味着快速响应的同时理解和生成能力会更强，但正文没给出具体性能对比数据，实际提升多大得自己测。另外修了 15 个以上的问题，包括 MCP 工具超时和 Windows 网络驱动死锁这类影响稳定性的 bug，对日常使用体验会有改善。整体看是个扎实的维护版本，没有架构级变化，但后台会话控制和模型升级这两点对重度用户来说值得更新。

OpenAI 给 Codex 加了两样东西，让它在实际开发流程里更像个能干活的人，而不是只会聊天的助手。第一个是“钩子”，你可以在任务的关键节点插一段自定义脚本，比如提交前自动跑一遍代码检查、扫描有没有不小心提交的密钥、记录每次对话日志，或者按不同仓库做定制行为。这相当于给 Codex 装了个触发器，让它能嵌入到团队已有的开发规范里，而不是要求团队去适应它。 第二个是面向商业和企业版的“程序化访问令牌”，从 ChatGPT 工作区设置里就能创建，带权限范围、可以设过期时间或随时撤销，方便接入 CI/CD、发布流水线和内部自动化，使用记录也会归到对应工作区。这点对管理比较有用，不用再拿个人账号硬扛自动化任务。 不过正文没披露令牌的权限粒度到底多细，比如能不能精确到某个仓库或某类操作，也没说钩子脚本的执行环境限制和超时策略。这些会直接影响它在生产环境里的可用性，先别急着全量上。

这份报告与其说是预测，不如说是 Anthropic 写给美国政策圈的劝进表。它把全球 AI 领导权简化成一个变量：算力芯片。现在美国靠出口管制卡脖子，中国实验室则靠人才、钻管制漏洞和大规模“蒸馏攻击”（扒美国模型能力来训练自家模型）死咬不放。报告推演了两种 2028 年的局面：一种是美国继续收紧漏洞、打断蒸馏，把技术领先锁在 12 到 24 个月，由民主国家定规矩；另一种是美国不作为，中国靠绕过管制拿到算力反超，由威权政权主导 AI 规则。 这里有几个点要先打折。第一，报告把“模型智能接近”完全归因于中国钻空子和蒸馏，但正文没给出蒸馏攻击让中国模型具体追回了几个月差距的量化证据。第二，12 到 24 个月的领先窗口是怎么算出来的，报告也没披露方法论，更像是一个政策喊话用的数字。第三，整篇分析站在美国及其盟友的算力优势上展开，对中国在应用层、数据效率和工程落地上的追赶路径讨论很少，这让第二种情景的推演显得有点单薄。 还缺什么？缺第三方视角的算力差距实测数据，缺对蒸馏攻击实际效果边界的独立评估，也缺中国在受限条件下自研芯片和替代训练方案的进展对照。这些信息不补上，两种情景都更像立场声明而非推演。

这篇博客是 Anthropic 官方出的 Claude Code 实战指南，专门讲怎么在百万行单体仓库、遗留系统和分布式架构里用。它没吹模型有多聪明，而是老老实实说：大代码库靠的是把项目上下文喂给模型，不是让模型自己记。具体给了五个扩展点：CLAUDE.md 文件写项目规则，hooks 在操作前后自动检查，skills 封装可复用指令，plugins 接外部工具，MCP 服务器做本地代码库的智能搜索。 文章给了从零开始的三步上手路径，这点比较实在。但要注意，全文没有给出任何量化数据——没提在百万行代码库里准确率多少、一次任务平均消耗多少 token、比手动改快多少。所有建议都基于“我们观察到用户这样用效果好”，没有对照实验或用户调研样本量。所以这些最佳实践可以当参考，但别当验证过的结论。 还缺一块：没讲失败案例。在遗留系统里改代码最容易踩的坑——比如改了 A 模块炸了 B 模块——文章完全没提 Claude Code 怎么处理这种跨模块依赖风险。如果你真要在生产环境的老代码上跑，这点得自己补测试。

这份手册把 AI 创业拆成了四个阶段：想点子、做最小可行产品、发布、扩张。每个阶段都给了目标、退出标准和常见翻车点，还附了用 Claude 做验证、客户调研、控制技术债、检查产品市场匹配和自动化工作流的提示词。说白了，这是一套可以直接抄作业的框架，不是那种只讲大道理的文章。 但得打个折。全文没给任何具体案例数据——没有用户增长曲线，没有留存数字，没有成本对比。所有方法论都停留在“应该这样做”的层面，缺少“这样做之后发生了什么”的验证。Anthropic 自己就是卖工具的，这份手册天然带着“多用 Claude 就能成”的倾向，技术债控制、自动化工作流这些环节尤其明显。 还缺两块关键信息：一是不同阶段的模型选型建议，用 Opus 还是 Haiku，成本差好几倍，手册没提；二是团队配置，AI 原生团队到底要几个人、什么背景，也没说。这些空白让手册更像一份骨架，肉得自己填。

OpenEvidence 说它覆盖了 65% 的美国医生，4 月临床用了 2700 万次，平均每人每月 41 次。这些数字全是公司单方面披露的，没有独立审计或第三方核实，所以实际渗透率可能要往下调。但“影子 AI”这个现象本身有说服力：医生拿执业编号在手机上自己注册，医院管理层一开始完全不知道，后来才追着签企业合同。Mount Sinai 的 AI 负责人直接管这叫 shadow AI，说明基层需求跑在了机构决策前面。 产品形态上，它接入了 NEJM、JAMA 等权威医学期刊的内容，本质是一个带外挂资料库的临床问答工具，医生查指南、查药物相互作用时不用翻网页。正文没披露模型架构、幻觉率、误诊风险这些关键指标，也没说 2700 万次使用里有多少是真正影响临床决策的，多少只是随手查一下。 还缺两块信息：一是付费模式，医生免费用还是医院买单没讲清楚；二是和 Epic、Cerner 这类电子病历系统的对接情况，如果只是独立 App，进不了诊疗流程，那“临床场景使用”这个说法也要打折。

Google 给自家开源框架 Genkit 补上了中间件，相当于在智能体应用的关键节点装了三个“可编程开关”：模型生成时、调用外部工具时、以及整个工具调用循环。这让你能直接写代码处理一些工程上的麻烦事，比如模型 API 挂了自动重试或切备用方案、执行敏感操作前弹窗让人点确认、或者给每一步打上日志方便排查。TypeScript、Go、Dart 版已经可用，Python 版还在路上。 这个更新解决的是智能体应用从 demo 到生产环境最头疼的可控性问题。但公告没给出任何性能开销数据——中间件插在调用链上，延迟会增加多少？也没提是否支持异步处理或条件跳过，这些在实际业务里都是刚需。另外，审批流程的例子只说了“让人审批”，没讲清楚审批超时怎么办、拒绝后流程怎么回退。这些细节决定了它到底能不能用在严肃的生产系统里，目前只能先打个折看。

这条消息对做端侧推理的人挺实用。Arm 的新指令集 SME2 相当于把原本需要外挂加速器的矩阵运算直接集成进了 CPU，不用再在速度和兼容性之间做取舍。Google AI Edge 这边的 LiteRT 和 XNNPACK 能自动识别并调用这套指令，开发者不用自己改模型结构。拿 Stability AI 的 stable-audio-open-small 在 Arm 手机上跑，音频生成速度提升超过 2 倍，内存占用降到原来的四分之一，这两个数字在手机这种资源紧张的环境里确实能省不少事。 不过得打个折。全文只展示了这一个音频模型的测试结果，没提视觉、语言类模型的表现。不同模型的计算图差异很大，SME2 的加速效果能不能泛化到其他任务，正文没给数据。另外，实际功耗和发热也没披露，这对手机端部署比单纯的速度数字更重要。建议等第三方用更多模型跑一遍再看要不要跟进。

Kimi 这个“网页桥接”扩展，说白了就是给 AI 装了一双能在网页上干活的手。以前你让 AI 查资料，它只能读文本；现在装了插件，它能直接打开网页、搜索、滚动、点击、填表，像人一样走完一整串操作。支持的开发工具包括 Kimi Code CLI、Claude Code、Cursor、Codex 和 Hermes，覆盖面挺广，意味着你在写代码或跑任务时，AI 可以自己去网页上执行动作，不用你来回切。 但这条消息来自官方推文，信息量很薄。它没说明白几个关键点：遇到需要登录的网站怎么办？碰到验证码、反爬机制会不会卡住？操作失败时有没有回退或报错？这些在实际使用里都是高频坑。另外，扩展是免费还是限额度，也没提。 我会先打个折：这个功能对开发者确实方便，尤其是需要频繁从网页取数据或填表单的场景。但别指望它像真人一样灵活，复杂交互和异常处理大概率还得人兜底。等有人实测出踩坑报告，再判断它到底省了多少事。

这起诉讼的核心指控很直接：你在 ChatGPT 输入的问题，会被塞进浏览器标题栏，连同你浏览器里存着的 Facebook 用户 ID，一起打包发给 Meta。原告认为问题主题本身就是敏感信息，比如你问医疗、财务或情感问题，等于把自己的隐私标签贴好送出去。OpenAI 的说法是只分享“有限标识符”用来投广告，但正文没给出 OpenAI 的正式回应或技术细节，所以这个“有限”到底限到什么程度还不清楚。 值得留意的是时间点——2026 年 5 月立案，说明这事发生在 ChatGPT 已经大规模普及之后。很多用户当初从搜索引擎转用 ChatGPT，图的就是不被追踪、不被画像，如果指控属实，这个反差确实讽刺。但诉讼刚受理，离判决还远，原告的举证能力和 OpenAI 的辩护策略都未知。 目前缺的关键信息：OpenAI 是否在隐私政策里披露过这段数据共享、Meta 收到数据后怎么用、有没有用户因此受到实际损害。这些会直接影响案子能不能走下去。

这条新闻值得点开看，因为它解决的是 Agent 跑长任务时一个很实际的痛点：上下文窗口被工具返回的大量原始数据撑爆，导致成本飙升、模型犯糊涂。腾讯云这个方案思路挺巧，不是去压缩历史，而是把完整结果卸载到外部文件，上下文里只留一行摘要和索引路径，再配合一张 Mermaid 流程图当“任务地图”，让 Agent 随时知道自己在哪、下一步该干嘛。 61% 这个数字来自多任务连续 Session 实验，不是单题清空上下文那种理想环境，参考价值更高。消融实验也显示，光卸载能省 15% 的 Token，加上画布能到 31%-33%，说明画布对减少上下文噪音有独立贡献。 不过正文没披露实验用的具体模型、任务类型和成功率基线，也没提卸载和检索本身会引入多少额外延迟。目前默认用本地 SQLite 存储，零外部依赖，这对个人开发者友好，但大规模生产环境下的并发和可靠性还没看到验证。另外，长期记忆部分只提了一句“已上线免费使用”，具体怎么和短期记忆协同也没展开。

小米的 MiMo V2.5 Pro 在 DesignArena 设计竞技场总榜拿了季军，Thinking 版本比上一代爬了 8 个名次，前端编码任务的表现号称跟 Claude Sonnet 4.6 打平。这个成绩如果坐实，说明国产模型在需要兼顾视觉审美和代码实现的设计类任务上，已经能摸到第一梯队的边。 但这条消息来自官方账号的庆祝推文，不是第三方评测报告。正文没披露具体评分、测试样本量，也没说这个“追平”是在全部前端任务上还是某个子集里达成的。DesignArena 本身是一个社区驱动的排行榜，评测维度和稳定性跟学术基准不太一样，所以这个第三名的含金量还需要更多独立验证。 还缺的东西挺多：跟 Sonnet 4.6 对比的原始数据、错误类型分布、在不同复杂度任务上的稳定性，以及 Thinking 版本相比普通版到底在哪些环节起了作用。这些信息不出来之前，这个“追平”只能当个参考信号看。

这是个实用向的开源小工具，把微信群聊记录自动整理成摘要，省去爬楼翻记录的痛苦。核心逻辑不复杂：用 wx-cli 把聊天数据读出来，再丢给 Claude Opus 4.6 做总结。作者实测这套组合效果最好，但正文没披露具体好在哪——是摘要更准、幻觉更少，还是对长群聊的上下文处理更稳，这些都没说。 依赖链有个明显的坑：你得先自己配好 wx-cli，作者明确表示这块不提供帮助。wx-cli 本身是个第三方工具，跟微信没有官方关系，稳定性和安全性都要自己评估。如果你日常聊天内容敏感，建议先搞清楚数据是怎么走的再决定用不用。 另外，其他模型的表现正文完全没提，没法判断这套方案是不是只绑定了 Claude。如果你手头用的是别的模型，效果可能打折，这点先别太激动。

OpenSquilla 的思路很直接：不是所有问题都需要 GPT-4 级别的模型来回答。它做两件事，一是智能路由，根据问题难度自动把请求分给不同成本和能力的模型；二是本地检索，把常用知识存在本地，减少对外部大模型的调用次数。项目宣称能“大幅降低 LLM 使用成本”，甚至提到“近十倍”的降幅，同时兼容多个平台和模型。 但这里信息缺口很明显。正文是空的，我们只能从标题和项目名推断功能，没有看到任何 benchmark 数据、延迟对比、准确率损失，也不知道“近十倍”是在什么任务、什么模型组合下测出来的。路由策略本身也有风险：如果分类器把难题误判为简单题，回答质量会直接掉档。这点在成本数字里有没有被计算进去，目前完全不清楚。 对想试用的团队来说，可以关注它开源代码里的路由逻辑和检索模块设计，但别急着把宣传数字当预期。最好用自己的常见 query 跑一遍，看看实际路由命中率和端到端延迟，再算真实节省的成本。

Daniel Han 放出的这几个 Qwen3.6 MTP GGUF 模型，核心卖点是推理快。27B 模型单张 GPU 跑到每秒 140 个 token，35B-A3B 版本能到 220 token/s，比原版 GGUF 快了 1.4 倍以上，而且说精度没掉。 快的原理是投机解码，让模型一次猜两个草稿 token，在速度和猜对率之间找了个平衡点。这个思路不新，但把 draft tokens 定在 2 并做成 GGUF 格式直接可用，对想在消费级显卡上跑大模型的人来说确实省事。 不过得打几个折。首先这是实验版，正文没提在哪些基准上验证过精度无损，也没说接受率具体是多少。其次，投机解码的实际加速效果很吃任务类型和硬件，换到长文本生成或复杂推理场景，220 token/s 这个数字不一定稳得住。另外，模型本身是 Qwen3.6 的衍生版，如果上游模型在特定任务上有短板，加速也解决不了。想用在生产环境，最好拿自己的数据和任务测一下延迟和输出质量，别只看峰值速度。

杨植麟自己拍视频把Kimi K2的训练账本摊开，总花费460万美元，靠线性注意力等架构设计在编程任务上跑赢了GPT-5.5。这个数字放在大模型圈确实低，说明他们用设计把资源差距抹平了一截。但视频是创始人自述，没有独立评测机构交叉验证，跑分对比用的什么基准、什么测试条件都没展开。编程任务本身也容易刷榜，换个数据集排名可能就变了。另外，460万是纯训练成本还是含试错和废卡，正文没披露。这点先别太激动，等第三方跑分出来再看。

Grok Build 是个直接跑在命令行里的编程助手，目前是早期测试版，只开放给 SuperGrok Heavy 订阅用户。它最大的卖点是干活前会先出一份计划让你审，你可以改步骤、批注，甚至推翻重写，批准后才动手改代码，每次改动都以 diff 形式呈现，这比直接让模型盲改要靠谱得多。另外它能把大任务拆成多个子任务并行跑，还支持无头模式（-p 参数），方便塞进脚本和自动化流水线里。 官方说它兼容你现有的 AGENTS.md、插件、钩子和 MCP 服务器，进到仓库就能用，这点对已经搭好开发环境的团队比较友好。但正文没披露任何性能数据，比如任务完成率、一次通过率、并行子任务的实际加速比，也没提延迟和资源消耗。这些是判断它到底能不能在生产环境用的关键。另外，早期测试意味着功能可能不稳定，反馈渠道倒是给了（在 CLI 里敲 /feedback），但没说明反馈后的迭代周期。 我会先打个折：计划审核和并行子任务这两个设计方向是对的，但没看到实测数据前，别急着把它当成主力开发工具。

这篇文章讲的是怎么把推理服务里 CPU 和 GPU 的“轮流休息”改成“同时干活”。他们拿一个 80 亿参数的模型做测试，生成 8000 个 token 时，GPU 有 24% 的时间是闲着的。原因很简单：同步批处理下，CPU 准备下一批数据时 GPU 只能干等，反过来也一样。文章给出的解法是用 CUDA 流把这两件事拆开，让 CPU 准备第 N+1 批的同时，GPU 已经在算第 N 批。 这个思路不新鲜，但文章把实现细节讲得比较清楚，包括怎么用 CUDA 事件来强制同步、怎么处理竞争条件和 carry-over 这些坑。不过正文没给出优化后的具体吞吐提升数字，也没提不同模型规模下的收益差异。这点先别太激动，24% 的空闲是特定场景下的测量值，换个小模型或者短文本，收益可能没那么大。另外，异步引入的复杂度会不会在工程上带来新的稳定性问题，文章也没展开。

Tomasz Tunguz 这篇博客没画大饼，直接拿主流大模型的 API 价格算了一笔账：让 AI 帮你读、写、整理邮件，每月推理成本在 22 到 130 美元之间，中位数 26 美元。这个数字本身不算吓人，但一旦按 SaaS 的 75% 毛利率打包成产品，年费就要 500 美元左右，是 Google 企业版的两倍。用户会不会掏钱，正文没给结论，只说“工作中很多人可能会”。 文章最有用的部分是降本路径。换小模型能把成本压到十分之一甚至二十分之一；更彻底的做法是直接在用户自己的 GPU 上跑推理，边际成本趋近于零。作者认为接下来一两年 AI 软件的核心就是这种“看人下菜碟”的推理分层：能写死规则的就别调模型，该用小模型就别上大家伙。 不过这篇分析缺几个关键信息：没说明每月处理多少封邮件、多长的上下文，也没区分“读邮件”和“写回复”的 token 消耗差异。另外，本地跑虽然省钱，但用户设备门槛、延迟和隐私权衡都没展开。这些缺口让 26 美元这个中位数只能当个参考锚点，别直接拿去写商业计划书。