全部 · 2026-07-05

这篇文章讲了一个很实在的工程思路：别让 AI 智能体在自己住的服务器上直接敲命令。Fly.io 的做法是把智能体的主循环（大脑）放在普通机器上，每次需要执行 shell 命令（动手）时，就启动一个叫 Sprite 的一次性沙箱，每个用户会话独占一个，用完就销毁。这样哪怕模型输出了一条 rm -rf，也伤不到智能体本身和其他用户。 文章给了两个内部案例：一个是 Fly 自己的排障智能体 SpriteDoc，多用户共用一台服务器，但每个会话的 shell 操作都在独立 Sprite 里跑；另一个是给 Nous Research 的 Hermes Agent 做的终端后端。他们还提到，用户凭证只在单次命令执行期间注入沙箱，不会落盘存储，这点对安全敏感场景挺关键。 不过文章没给出 Sprite 的启动延迟具体是多少，只说“快到用户几乎无感”。也没提沙箱的资源开销和并发上限，如果同时跑几百个会话，成本会不会炸，正文没披露。另外，智能体在沙箱里能做什么、不能做什么的权限边界，也没有展开讲。如果是真的能做到低延迟、低成本隔离，这个“大脑和手脚分离”的模式比把整个智能体关进沙箱要灵活得多，但落地前得先搞清楚这些缺口。

SonarSource 的研究人员做了一个很实在的对照实验：他们用 Claude Code 跑了 660 次任务，对比了功能一样但整洁度不同的代码仓库。结果发现，代码是脏是干净，对任务最终通过率没有影响。但干净代码确实让模型省钱了——token 消耗少了 7% 到 8%，重复打开同一个文件的次数直接砍掉 34%。 这个实验设计挺巧妙的，用的是“最小配对”仓库，也就是除了代码整洁度（比如静态分析违规项、认知复杂度）不同，其他架构、依赖、外部行为完全一样。33 个任务都通过应用层的隐藏测试来判分，不是看模型自己说对不对。不过要注意，这只是在 Claude Code 一个模型上的结果，换别的编程助手是不是也这样，正文没提。 对团队来说，这个结论很直接：别指望靠重构代码来提高 AI 写代码的准确率，但如果你们每天大量调用编程助手，把代码写干净点，省下来的 token 成本是实打实的。

这条消息如果属实，对 NVIDIA 的节奏影响不小。Kyber NVL144 三个月前还在 GTC 上被 Jensen 拿出来展示，现在 SemiAnalysis 说它要推迟超过 12 个月，直接推到 2028 年。同时被砍掉的还有 NVL72x2 方案，也就是把两个机架背靠背拼成一个更大单元的设计。这意味着 Rubin Ultra 在横向扩展上的路子会变窄，原本可能靠堆机架来线性提升算力的设想暂时落空。 不过得先打个折。这条帖子只是爆料线程的第一条，正文没有展开具体原因，到底是芯片设计问题、互联技术卡壳，还是供应链或散热上的限制，目前一概没提。SemiAnalysis 的爆料有靠谱的时候，也有翻车的时候，在后续细节出来之前，这条只能当信号看，不能当定论。如果后续确认是架构层面的硬伤，那对明年 Rubin Ultra 的部署预期就得重新算了。

扎克伯格自己发帖，说 Meta 在建一个叫 Prometheus 的单一 AI 集群，功率超过一千兆瓦，资本投入用他的原话是“数千亿美元”。他把自己的角色概括成三件事：把顶尖人才、钱和基础设施集中起来。这个体量如果属实，比现在已知的任何公开项目都大一个数量级——目前最大的数据中心也就几百兆瓦级别。但正文只给了这一句表态，没披露任何时间表、具体用什么芯片、能效比（PUE）这些关键信息。我会先打个折：这种级别的基建通常要多年分阶段落地，而且千兆瓦的供电和散热在工程上极其难搞，不是砸钱就能线性加速的。还缺的是选址、电力来源、是否配套自研芯片、以及跟 Meta 现有集群的关系——这些才是判断它到底是真开工还是融资叙事的硬指标。

这件事简单说就是：一个开发者通过反复试探，扒出了 Claude 在生成设计稿时背后那套“系统提示词”，并把它整理成了一套可复用的提示词库，放到了 GitHub 上。这套提示词的目标很明确——让模型在设计时更有主见、更关注无障碍访问，并且主动避开那种千篇一律的“AI 风格”。 从项目描述看，它不是一个简单的单句指令，而是一整套“技能库”，相当于给模型装了个设计总监的人格。目前仓库已经拿到了 278 个星标，说明不少开发者对这种能产出更有个性、更可用的设计稿的提示词有真实需求。 不过得打个折：正文没披露逆向工程的具体方法，也没说这套提示词在哪些模型上测试过、效果对比如何。它更像是一个经验产物，而不是经过严格验证的工具。如果你打算用在生产环境，最好先拿自己的设计任务跑一遍，看看它是不是真的能压住模型的“AI 味”，以及在不同模型上的表现是否稳定。

这条新闻最值得看的是 AI 编程的实际成本与效果。Simon 在发布 sqlite-utils 4.0 前，让 Claude Fable 做了一次最终审查，结果模型发现了一个会静默丢数据的严重 bug：delete_where() 方法执行后从不提交事务，导致后续所有写入操作都会被悄悄回滚。这个 bug 如果没发现，用户数据丢了都不知道。整个修复过程用了 37 次提示、34 次提交，改了 30 个文件，总共花了 149.25 美元。这个价格对于一次全面的代码审查和 bug 修复来说相当便宜。 之后他又让 GPT-5.5 交叉审查了一遍，又发现两个问题。这种多模型交叉验证的做法很务实，也说明当前 AI 编程还不能完全信任单一模型的输出。新版本把事务处理的文档重写了，核心逻辑是：所有写入操作默认自动提交，只有用 db.atomic() 或手动 begin() 时才需要操心事务。这个设计思路是对的，把复杂的事务管理藏起来，减少用户犯错的可能。 不过正文没披露 GPT-5.5 审查花了多少钱，也没说那 37 次提示中有多少次是无效或需要重试的。如果只看最终成功的那条路径，成本数字可能偏乐观。另外，模型是在 iPhone 上通过 Claude Code for web 操作的，这种移动端编程体验本身也是个有趣的点，但文章没展开讲。

Yohei Nakajima 这篇论文把智能体的设计逻辑翻了个个儿。现在多数框架是先跑对话循环，再往上堆工具和规则，最后补一层日志做观测，状态靠“外挂资料库”式的记忆来存。ActiveGraph 反过来：只增不删的事件日志才是唯一真相来源，当前的工作图谱只是日志的确定性投影。组件之间不直接发指令，所有协调都通过共享图谱完成。 这个设计带来了三个外挂记忆做不到的特性：一是任何一次运行都能从日志里原样回放；二是可以在任意事件点分叉，不用重跑共享的前缀，成本很低；三是从顶层目标到具体模型调用，每一步的来龙去脉都能追溯。论文给了架构、确定性合约，还有一个尽职调查的例子，代码也开源了。 不过得打个折：文章没报大规模跑分，也没说在复杂场景下日志膨胀、图谱投影延迟这些工程问题怎么解决。如果是真的，对需要审计和实验复现的场景挺省钱，但现阶段只能当架构思路，离生产落地还缺验证。

这篇文章最狠的地方，是作者先把自己架在火上烤。他承认自己骂何同学，不是因为对方不严谨，而是因为一台两千块的智能望远镜，把他花几万块、熬几个通宵才练出来的手艺给打成了白菜价。这种“租金保卫战”的视角，比市面上大多数AI恐慌论述都诚实。他把手艺和判断力拆开讲，这点很关键：AI降的是执行成本，不是决策能力。就像CEO把活外包给助理，不会因此变成判断力的无产阶级。但文章也有个软肋，它没给出那些被AI替代了手艺的人，下一步具体该往哪走。作者自己也承认，他还没完全走出来。另外，文中引用的MIT脑电研究只有54个被试，还是未经同行评审的预印本，这个证据的成色得打个折。整体来看，这是一篇难得的自我解剖，比那些替普通人操碎心的哲学独白要实在得多。

这篇文章把五年里 scaling law 的三次修正讲清楚了，比那篇刷屏的“塌房”文靠谱得多。核心事实是：2020 年 OpenAI 的 Kaplan 论文因为漏算输出层、学习率设置不当等实验偏差，得出了“优先堆参数”的结论，直接催生了 GPT-3。2022 年 DeepMind 用更大规模实验纠正了配比，发现每个参数配大约 20 个 token 才划算，小模型多喂数据反而更强。2024 年两组独立复现研究确认，修正 Kaplan 的实验设置后，能几乎精确复现 Chinchilla 的结论，这不是骗局，是正常的科学校准。 更有意思的是第三幕：2023 年起，Meta 等公司开始故意偏离 Chinchilla 的 20:1 配比，给 80 亿参数的 Llama 3 喂了 15 万亿 token。原因不是数学错了，是题目变了——优化目标从单次训练成本，换成了训练加推理的总成本。小模型推理便宜，多花训练费换更小的模型，只要调用量够大就划算。清华的 Densing Law 量化了这个趋势：达到同等能力所需的参数量大约每 3.5 个月减半。 至于那篇刷屏文引用的“法语比英语高效 50 到 100 倍”，出处是一条当天发布的博客评论，没有同行评议，而唯一一篇正面比较的同行评议研究结论相反。这个细节足够给那篇文章的可信度定位了。信息缺口在于：文章没提 Densing Law 的具体实验条件和适用范围，也没展开讨论小模型的知识存储地板（每个参数约 2 bit）对实际产品形态的约束。

这篇文章的核心判断很直接：当业务组花十分钟就能让 AI 生成一套能用的内部工具时，Infra 组过去“复用比自建划算”的底气就被掏空了。GitClear 覆盖 2.11 亿行变更的数据显示重复代码激增、重构减少，这组数字单独看吓人，但放在新成本结构里，它说明代码正在从需要小心维护的长期资产变成廉价耗材。 文章提出的解法是 Infra 组转去交付“生成内核”——把支付、认证这类不可替代的核心能力，加上工程最佳实践和确定性工具，打包成 agent 可直接调用的 paved road。Shopify 和 Stripe 已经把核心能力封装成 MCP server 给 agent 用，这个方向有实际案例支撑，不是纯概念。 不过文章没给出生成内核在组织内落地的具体成本或失败案例。把工程设计哲学编码为 agent 上下文这件事，正文只提了方向，没讲怎么做、效果如何验证。另外，agent 沿着 paved road 走成功率更高这个结论，目前还缺公开的量化数据，这点先别太激动。