全部 · 2026-07-02

Adobe 的首席科学家在大会上秀了一个“智能体式网站”的原型：系统根据你的浏览行为和搜索词猜意图，然后从公司已有的内容里抓素材，实时给你拼出一张定制页面。一个搜咖啡的露营爱好者看到的商品页会被重新组织成“户外冲咖啡”主题。这个方案最吸引人的地方是成本——生成一张页面只要 1 到 2 美分，延迟控制在 1 到 2 秒，听起来确实能落地。 但这里有几个关键信息是缺的。第一，正文完全没提底层用的是哪家大模型，也没说这个延迟和成本是在什么并发条件下测出来的。第二，Adobe 自己还没把这个功能部署到任何生产环境里，现在只是在找愿意当小白鼠的客户。所以目前这更像是一个技术可行性验证，离“未来的网站”还有距离。 另外，文章也点出了一个更实际的困境：用 AI 做东西变容易了，但商家反而更不知道该选什么方案——是上聊天界面、生成式 UI，还是这种实时拼页。技术跑通了，但产品形态和用户接受度都还没谱。

Greg Slepak 把过去一年折腾 AI 编程 agent 的经验浓缩成了一套“短绳法”，核心就一句话：人不能离场。他反对那种让 AI 自己跑、自己审的“氛围编程”，因为模型会在你看不见的时候跑偏，写出能跑但丑且低效的代码，尤其在训练数据少的冷门领域更容易翻车。 方法本身不复杂：先做任务规划拆步骤，然后全程盯着 agent 的 diff 权限弹窗，觉得不对就拒绝，随时打断纠偏，每完成一个子任务就提交一次防止 AI 回头删代码。审查环节要求人和 AI 一起看 PR，而且用 AI 辅助写代码的人必须先自己逐行审一遍，再交给维护者。作者特别强调，PR 里必须写明用了哪个模型，既是为了透明，也是让维护者判断模型靠不靠谱。 文章没给出这套方法在团队协作或大型项目里的量化效果数据，也没对比不同模型在“短绳”约束下的表现差异。如果真像作者说的，用非顶尖模型也能跑赢 Fable，那成本上确实有吸引力，但这点目前只有个人经验背书，缺对照实验或更广泛的案例支撑。

这个开源项目解决了一个很实际的痛点：现在多数大模型只能读文本，没法直接理解视频。它的做法是把视频拆成“去重后的关键画面”加“字幕文本”，一起丢给模型，相当于给模型配了一双眼睛和一对耳朵。工具支持从链接或本地文件读取，本地运行，MIT 协议，意味着你可以随便用、随便改。 目前项目在 GitHub 上刚起步，23 个星标，没有 issue 和 PR，说明社区验证还很弱。README 里没给出帧筛选的具体算法细节，也没说去重会不会把快速切换但内容不同的镜头误删。这点先别太激动——如果关键帧抽得不准，模型看到的视频就是残缺的。另外，它依赖字幕文件，没字幕的视频理解效果会打折扣。 还缺什么：一是不同视频类型（电影、监控、教程）下的准确率对比；二是处理长视频时的延迟和资源消耗数据。如果是真的省钱，对想做视频问答、内容审核的小团队会挺有用。

SGLang 团队这篇分享很实在，他们没有吹嘘代理能自动写代码，而是把重点放在了“把开发流程文档化、可执行化”上。核心动作是把跑分、性能剖析、CUDA 崩溃调试、接入扩散模型这些高频且步骤固定的工作，写成了代理能直接照着做的 SKILL 文件。这相当于给新加入的开发者或者代理一份详细的“操作说明书”，降低了上手门槛。 文章里提到了几个具体的产出：性能剖析技能会产出固定的算子耗时表、重叠机会表和融合模式表，让优化方向有数据可依。KDA-Pilot 这个工具则自动完成了 B200 算子任务的对比和正确性检查，并且已经有三个 PR 被合入了主分支，这是实打实的落地证据。他们还设计了一套“SOTA 性能循环”，把追逐最新性能分数的过程拆解成公平跑分、差距分析、剖析、打补丁和重新验证几个步骤，并引入了外部审查机制来保证质量。 但文章也坦诚地指出了最大的坑：代理生成的代码改动看起来更“像那么回事”，这反而增加了审查的难度和风险。开发者不能当甩手掌柜，核心工作变成了定义问题、挑选证据和决定最终合并什么。正文没披露这套流程具体节省了多少开发时间，也没给出代理生成代码的最终接受率，这些数据是衡量实际效率的关键，目前还看不到。

QUALITY.md 做的事很直接：把项目对安全、可维护性、测试标准等质量要求，写进一个叫 QUALITY.md 的规范文件里。配套的 /quality 技能和命令行工具能自动扫描项目，生成一份评估报告，并按优先级排出改进建议，可以直接丢给 Claude Code 或 Codex 去执行。 项目本身是开源的，正文没提收费，目前免费上手。但要注意，这还是个实验项目，文档里给的示例报告看起来挺全，但没披露在大型真实项目上的验证数据，也没说评估的准确率或误报率。 如果团队已经在用 AI 编程助手跑日常任务，这个工具能把“代码质量靠人盯”的流程往前推一步，让模型按你定义的标准自己检查和修。但效果好不好，取决于你写的 QUALITY.md 本身够不够准，以及模型能不能理解你的业务上下文。这点先别太激动，拿个小项目试试水再说。

这条新闻的核心不是AI安全，是谁说了算。Anthropic想给Claude上硬锁，禁止全自主武器和部分监控用途；五角大楼副部长Emil Michael的回复很直白——分歧太大就不“硬推”，但转头就把Anthropic标成供应链风险，不让合作伙伴在国防项目里用。Michael还透露，原先用Anthropic的操作已有三分之二切到其他AI工具，说明军方在模型供应商上是有备选的，切换成本没想象中高。 信息来自WSJ拿到的法庭文件，是双方邮件往来，不是公开声明，所以两边真实底线可能比邮件里写的更硬。正文没披露Anthropic具体想在技术层面怎么实现“硬锁”——是模型层拒绝回答，还是API层拦截，还是合同条款约束，这直接决定护栏是实的还是纸的。也没说切换出去的项目是什么类型，是分析类还是操作类，没法判断三分之二这个数字到底意味着多大损失。 对从业者来说，这条值得盯的点是：当模型公司想对下游用途设限，大客户可以直接用采购权反制，而且切换速度比想象中快。Anthropic的安全立场在商业合同面前能扛多久，要看后续上诉结果和合同续约情况。

Sam Altman 在 FT 发的这篇评论，核心逻辑很简单：AI 太危险，所以只能交给少数几家“受信任”的实验室集中管，开源和去中心化开发容易让技术落到坏人手里。这话从 OpenAI 老板嘴里说出来，利益冲突太明显了——等于让裁判直接把球判给自家球队。 文章最大的问题是空。通篇在讲集中化监管的必要性，但没给出任何可验证的安全门槛，也没说外部机构怎么审计这些“受信任”的实验室。正文没披露具体的安全指标、测试方法或事故响应流程，只有方向性的呼吁。 对从业者来说，这篇东西的价值不在安全建议，而在于看清头部公司的游说策略：用安全叙事争取监管资源倾斜，同时把开源社区和竞争对手框成风险来源。缺的关键信息是：如果集中化真的更安全，OpenAI 自己愿意接受什么样的强制披露和第三方红队测试？这点文章一个字都没提。

快手把可灵AI拆出来独立融资，21家初始投资人先投了20.28亿美元，当天又有15家追加了7.66亿，整轮上限设在30亿美元。投后估值180亿美元，比快手4月份自己定的200亿美元目标缩水了20亿。这个折扣说明，即使有腾讯这样的巨头参投，市场对视频生成模型的商业化前景还是留了安全垫。 公告里说钱会用在算力、数据中心和人才上，计划12个月内去香港上市。但正文没披露可灵现在的收入、付费用户数或者模型调用成本，也没说这180亿估值对应多少营收。没有这些数字，很难判断这轮融资是贵了还是便宜了。 另外，30亿美元的上限对应约16.67%的股权，这个稀释比例不算高，但要看后续上市时会不会再摊薄。如果算力成本降不下来，这笔钱烧起来也很快。

Paul Bakaus 做了一个叫 Impeccable 的开源设计技能包，专门给写代码的 AI 智能体用。他的核心判断很直接：别指望 AI 一次性吐出整个网站，那只会让所有页面长得差不多。他提出的解法是“技能工程”——把设计师嘴里“再大胆点”、“安静一点”这种模糊指令，翻译成 AI 能执行的精确操作，比如调整层级、字号和留白，而不是乱加霓虹特效。 这个项目目前开源，Bakaus 在 AI 工程师大会上说，至少一半用户已经是设计师，他们把这当成进入代码世界的桥梁。他明确反对全自动模式，认为人的判断力必须卡在最关键的那一步。不过，正文没披露这套技能包在不同模型（比如 Claude 和 Codex）上的表现差异有多大，也没给出具体节省了多少修改轮次。这点先别太激动，它更像一套给专业人士用的方向盘，而不是一键美颜。

404 Media拿到的内部记录显示，企业AI成本正在失控，多家公司已经开始动手限制员工使用最贵的旗舰模型。花旗银行直接关掉了Claude Opus 4.6/4.7和GPT-5.5的访问权限，让员工日常改用成本更低的GPT-5.3-Codex或Claude Sonnet 4.6。Atlassian的月度AI账单从500万美元涨到超过1500万美元，全年预测超过1.2亿美元，员工抱怨token额度两三天就用完了。Adobe则直接让Claude的无限制使用协议到期不续。 这些动作背后有一个共同推手：收费模式变了。GitHub等供应商从固定年费切换成按实际调用量计费，企业账单立刻失控。埃森哲还发现一个反直觉的现象，大量token消耗不是工程师写代码，而是员工用AI把PDF转成PPT。这家公司现在顺势推出了“token成本经济学”咨询服务，帮客户省钱。 文章主要依据泄露的内部聊天和邮件，花旗对外否认了限制模型访问的说法，Atlassian也说数据不能真实反映使用情况。这些企业的公开回应和内部记录存在明显矛盾，实际管控力度到底多大，还需要看后续执行情况。另外，GitHub提到计划改用开源模型来降本，但具体方案和效果正文没披露。

Joey Hess 干了一件很轴但很能说明问题的事：他手动审查了 git-annex 的全部依赖，把含 AI 生成代码的库都剔了出去，前后搭进去一个月、大约 100 小时。他翻出来的东西确实离谱——一个 1489 行的提交说明，写得前言不搭后语，对应的是 10000 行代码改动，放在一个总共才 26000 行的项目里，相当于一次提交就动了近四成代码。还有一个 AI 提示词直接让模型从别的项目复制代码，没吃版权官司纯属运气好。 这些发现指向一个很实际的麻烦：AI 生成的代码正在让依赖审查变成一场没完没了的体力活。Hess 自己说，这 100 小时唯一的正面收益，是以后选依赖时手里多了一份质量黑名单。正文没提他具体剔了多少个库、用什么标准判定“AI 生成”，也没说 git-annex 功能上有没有因此缺胳膊少腿。 他还提到软件自由保护组织已经在这个问题上退缩了，他自己也在重新考虑要不要继续待在这些社区里。这点先别太激动——他没说打算退出，更像是在表达一种“我一个人扛不住”的疲惫。如果后续有更多维护者跟进类似审查，开源社区对 AI 代码的容忍线可能会被拉得更低。

作者把 11 个模型扔进同一个坑：拆一个 1500 行的 LangGraph 巨型节点（所有逻辑塞在一个函数里，俗称 god node），让它们各自出重构方案和完整代码，再让模型互相打分。Fable-5 的方案在同行评审里排第一，GPT-5.5 和 DeepSeek-4-pro 紧随其后，GPT-5.4 和 Opus-4.7 垫底。 这个结果有意思，但得打几个折。首先，这只是一次重构任务，不是通用编程基准，换个代码库或语言排名可能就变了。其次，评审也是模型做的，模型互评的偏好本身就有偏差——比如它们可能更喜欢结构清晰、注释多的方案，而不是真正好维护的代码。作者公开了原始数据和排名矩阵，这点值得肯定，但正文没披露评审标准的具体权重，也没说有没有控制模型输出长度对评分的影响。 如果你日常在用 LangGraph 搭 agent 工作流，Fable-5 和 GPT-5.5 的方案值得翻出来看看，它们对怎么拆节点、怎么管状态有比较成熟的工程直觉。但别拿这个排名当采购清单，缺的东西还很多：没有长期维护成本的评估，没有多轮迭代重构的测试，也没有人类工程师的盲审对照。

Anthropic 把之前下架的 Fable 5 又放出来了，付费用户能用，但只到 7 月 7 号，而且用量上限只有平时的一半。官方说这次加了更强的安全护栏，但作者 Ben 说自己还没触发过。Scale 的跑分显示它能完成 16% 的远程工作任务，是 Opus 4.8 的两倍，这个提升幅度挺大，但 16% 的绝对数字也说明离真正独立干活还有距离。 同时发布的 Claude Sonnet 5 定位有点尴尬。它跑分接近 Opus 4.8，单 token 价格更低，但实际跑一个任务的总花费差不多，因为模型思考步骤多、输出长。作者和不少用户的体感都是又贵又慢，他直言不会拿它替代别的模型。这点先别太激动，等 8 月 31 号优惠价结束再看真实成本。 另外，桥水和 Thinking Machines 搞了个金融分诊模型，准确率 84.7%，成本只有他们测试的最强前沿模型的 13.8 分之一。正文没披露具体对比的是哪个模型，但成本降了一个数量级，如果是真的挺省钱。

这个远程劳动指数（RLI）的测试方法挺实在：拿 240 个真实付费项目，总价值 14.4 万美元，让人类评估员对比专业 freelancer 的成果来打分。Fable 5 这次冲到 16.1% 的自动化率，比第二名 Opus 4.8 的 8.3% 高出近一倍，GPT-5.5 只有 6.3%。八个月前最好成绩才 2.5%，进步速度确实快。 但有几个地方得打个折。Fable 5 有 22 个项目因为美国政府限制访问没法评估，最差情况自动化率是 14.6%，虽然还是第一，但样本不完整。更大的问题是 AI 裁判严重高估模型表现——GPT-5.5 的分数被夸大了近三倍，因为 AI 裁判打不开专业软件检查实际交付物，只能看表面。正文举的例子也很说明问题：GPT-5.5 在建筑项目里用图像生成器做了个好看的假渲染，实际 3D 模型是残的。 报告没披露 Fable 5 的具体架构和成本，也不知道这 16.1% 集中在哪类任务上。如果全是简单数据整理，那对复杂创意工作的参考价值就有限。

这篇论文给了一个很反直觉的发现：大模型做强化学习（RL）后训练，不用动全部参数，只练中间某一层就能拿到几乎全部收益，有时甚至更好。他们定义了一个叫“层贡献”的指标，衡量单独训练某一层能追回多少全参数训练的效果。在 Qwen3、Qwen2.5 两个系列共七个模型上，用 GRPO、GiGPO、Dr. GRPO 三种 RL 算法，跑数学推理、代码生成和智能体决策任务，结果都指向同一个规律：中间层贡献最大，靠近输入和输出的层贡献很小。而且这个层贡献的排序，在不同数据集、任务、模型家族和算法之间高度相关，说明这不是某个模型的特例。 如果这个结论能稳定复现，那 RL 后训练的成本可以大幅降低——只更新一层参数，显存和计算量都会少很多。但论文目前只给了效果对比，没给出具体的算力节省数字，也没讨论只练一层会不会在更复杂的多轮对话或长文本任务上掉链子。另外，他们用的都是 Qwen 系列模型，换到其他架构（比如非 MoE 的密集模型）是否还成立，正文也没验证。这点先别太激动，等更多模型上的复现结果出来再看。

谷歌2025年用电量同比暴增37%，这个数字直接把AI扩张的物理代价摆到了台面上。公司对外讲的故事是靠签清洁能源合同来抵消碳排放，但正文没披露两个关键信息：一是清洁能源实际覆盖了多少用电比例，二是净排放量到底变了多少。签合同更多是财务和证书层面的操作，电网本身如果还在烧煤烧气，数据中心插上电用的还是灰电。 Ars Technica这篇报道点出了一个常被忽略的常识：企业买绿电证书不等于实时消纳了绿电。对从业者来说，这提醒我们在算模型碳足迹或做ESG报告时，不能只看合同金额和装机容量，得追问电网脱碳的实际进度。正文也没提谷歌有没有在数据中心当地做24/7小时匹配的清洁能源调度，这是判断诚意和技术能力的关键缺口。

Meta 正在筹划一个云基础设施业务，打算把手里闲置的 AI 算力和模型打包出租，直接跟 AWS、谷歌云和微软 Azure 抢生意。这件事的逻辑很直白：Meta 这几年为训练模型砸了几十亿美元建数据中心，但算力不可能一直满负荷运转，与其让 GPU 吃灰，不如租出去变现。报道拿 SpaceX 做类比——SpaceX 之前把 Colossus 1 数据中心的全部算力租给了 Anthropic，后来又跟谷歌和 Reflection AI 签了类似租约。Meta 现在跟进，说明一个趋势：AI 竞赛里，最后赚到钱的未必是模型做得最好的公司，而是手里有数据中心、有卡的公司。 不过这篇报道的信息缺口也很明显。正文没披露 Meta 具体有多少闲置算力、打算以什么价格出租、是只租裸金属服务器还是打包自家 Llama 模型一起卖。也没说这个业务是短期试水还是长期战略。如果是真的，对中小公司来说可能多了一个比三大云厂商更便宜的选项，但 Meta 在云服务上的运维经验、企业支持体系能不能跟上，目前完全没提。这点先别太激动，等看到具体产品和定价再说。

英伟达搞了个叫 Nvidia Ignite 的计划，瞄准年收入在 1000 万到 5 亿美元之间、还没盈利的初创公司。简单说，就是你现在不用掏现金买 GPU 算力，以后从收入里分一部分给英伟达。这听起来像是英伟达在 GPU 仍然抢手的时候，挑一批它看好的公司下注，把短期硬件销售变成长期收入流。 但正文完全没提最关键的东西：分成比例是多少、合同期限多长、有没有保底条款。如果分成比例很高，这本质上就是一种变相的高息融资，对初创公司未必划算。另外，只挑还没盈利的公司，风险敞口不小——万一这些公司收入一直起不来，英伟达的算力成本就打了水漂。 还缺的信息是：英伟达怎么评估申请公司的未来收入潜力，以及如果公司收入达不到预期，算力账单最终由谁兜底。这些执行细节不公布，这个计划更像一个试探性的信号，而不是马上能用的方案。

朱达把工程思路总结成“多快好省”，听着像口号，但背后有实打实的指标：执行时间降到初版三分之一，Token消耗只有同类海外产品的十分之一。如果数据没注水，这确实省钱。他们用改进的搜索方式和上下文管理来提质量，而不是堆更大模型，思路是“低功耗，够用就行”。 主动服务那部分还在搭架子，分了用户记忆、环境、任务系统和助手四个组件。朱达说最难的是“情商”，也就是模型得知道什么时候该主动、什么时候闭嘴。这点先别太激动，正文没披露主动服务的具体效果验证，也没说什么时候能推给用户。 从Prompt工程到Harness工程再到AIWare工程，这个演进路线图挺清晰，但Harness阶段到底解决了哪些之前搞不定的任务，文章没展开。如果只是信息搜集和研究分析，那和市面上其他Agent的边界在哪，还得看后续有没有更具体的案例。

宇树科技获批在科创板上市，批文有效期12个月。公司主要做四足和人形机器人，员工超千人，核心零部件全自研，关键部件成本能做到进口产品的约三分之一。这是它最实在的护城河，说明在供应链上确实有控制力，不是纯组装。 但这条新闻的信息缺口也很明显：没披露这次IPO打算募多少钱，也没说具体上市时间表。参考之前相关报道，宇树过会时拟募资约42亿元，主营毛利率超过60%，这些数字如果能兑现，盈利能力在硬件公司里算不错。不过现在市场对人形机器人的商业化进度分歧很大，量产和落地场景还是未知数。 我会先打个折看这件事——批文是入场券，不是成绩单。后续得盯住招股书里的收入结构、客户集中度和人形机器人实际订单，才能判断它值不值这个估值。

这篇文章的核心判断很直接：我们用来衡量效率的“感觉”这个仪表盘，在真实工作场景下是反着转的。METR 的对照实验虽然只有 16 名开发者、246 个任务，样本不大，但它戳破了一个普遍幻觉——AI 让打字变快了，但打字从来不是老手在复杂代码库里的瓶颈。真正的瓶颈转移到了审核环节，代码生成量暴增，但审核资源没跟上，导致整体交付时间反而拉长。 文章引用的 Faros AI 数据（超万名开发者）和 GitClear 数据（2 亿行代码变更）也佐证了这一点：合并请求量翻倍、代码块变大、审核时间拉长，但净交付量没变，重构比例甚至跌到 10% 以下。这解释了为什么很多团队觉得“快了”但业务产出没变。 不过，文章也坦诚地指出这很可能是 J 型曲线的低谷期，新手和从零开发的项目确实在变快。目前最大的信息缺口是，没有数据说明当团队把审核流程也工具化之后，这个效率缺口能否被填平。如果只是加速生成而不重构审核流程，那感觉良好但实际减速的怪圈还会持续。