AI 编程多写了 30% 代码,软件却没多交付;机器人拉动 38 倍自重丨AI 情报站 10.10

01       AI 编程的第一份企业账本：代码多写 30%，软件没有多交付     

哈佛大学两位研究者 Fiona Chen 与 James Stratton 用工程效能分析公司 Jellyfish 的聚合数据做了这项研究：覆盖 700 家以上软件公司、70 万余名员工、3 亿条工作事件（提交、拉取请求等）以及研发管理软件数据，时间跨度从 2021 年到 2026 年 3 月。研究者通过直接测量的 AI 使用数据加 GitHub 活动分析，定位每家公司引入「编码助手」与「编码智能体」的时间点，再做双重差分回归。

生成侧的数字很直白：引入编码智能体后，公司整体代码产出（行数）平均增加约 30%，提交数 +20%，拉取请求数 +23%。

但到了交付侧，账就变了。Jira 这类工具里 Issue 与 Epic（成建制的功能）的解决率，在引入 AI 前后没有统计显著差异；这些任务在体量与复杂度上也没有出现结构性迁移。换句话说：代码变多了，做完的事没变多。

差异藏在评审里。从一个 PR 提交到被合并的「评审过程」时长，在引入智能体后平均拉长 49%；需要返工（changes requested）的 PR 占比接近翻倍；每个 PR 的评论数 +35%；做评审的人手占比上升 14%。研究者的措辞是，编码阶段获得的效率「被生产流程下游的约束吸收了」。

AI 也没能救评审。到 2026 年 3 月，80% 的受访公司已在使用某种形式的 AI 代码评审，但 AI 只贡献了全部评审评论的 23.3%、参与了 10.8% 的 PR——人依然是评审的主力。研究者同时表示，在核对 Jellyfish 与 LinkedIn 数据后，无法把显著的用工变化归因于 AI 工具。

与之呼应的是咨询机构贝恩的《2026 年全球技术报告》：基于近 300 位高级技术负责人的调研，AI 编程工具让开发者多完成约 21% 的任务，但审核模型输出的时间增加了 91%。两份独立数据指向同一个方向。

为什么值得看：这是第一次有一份企业层面的账本，而不是个人开发者的体感。它给出的结论并不悲观，但很不客气：瓶颈已经完成转移——从「写得快不快」变成「审得准不准」。对工程团队来说，这意味着三件事：度量必须把生成成本与验证成本分开算，否则收益会被系统性高估；评审、测试覆盖与安全门禁需要和生成能力同步扩容；再往上堆智能体不会线性提升交付，只会把队列往后压。文中还有一句值得记住的判断：随着经验积累，编码时间与评审时间的取舍也许会改善——也就是说，现在这 49%，是「工具已就位、流程还没跟上」的成本，而不是终点。     

02       Anthropic 的模型给警方递了一份假凶案线索，10 周后才发现     

10 月 9 日，费城警方公开了一件事：一名 Anthropic 的 AI 模型通过该市公开的悬案线索网站 PhillyUnsolvedMurders.com，提交了一份虚假的凶案线索。提交时间是 7 月 18 日 23:27，内容伪装成「可能掌握案情的知情人」。

按 Anthropic 向警方说明的版本，当时该模型正在做一项「与随机挑选的网站进行交互」的测试，在过程中访问了这个网站并提交了虚假信息。公司直到 9 月 28 日才发现这一行为，随后终止了导致该提交的自动化测试流程，并为后续测试增加了一道额外的校验机制。Anthropic 于 10 月 7 日通知费城警方，双方次日会面。

警方核查后的结论是：该提交被标记为垃圾信息、从未进入实时犯罪中心的核查与分发流程，也没有发现任何对警方系统的未授权访问或数据泄露。但警方的表态相当重：「两个月的检测与通报延迟是不可接受的」「技术公司必须采取一切必要措施，防止其系统向执法机构提交虚假信息」。警方同时强调，无论线索由谁提交，都只是待评估的线索而非既成事实——人类复核这道关口没有被绕过。

Anthropic 表示将发布一份报告，描述这次事件以及「其他非预期的模型行为」。

为什么值得看：把它和上周那条「一条提示词端掉整个云区域智能体」放在一起读，两条线正好构成完整图景：一个是别人打进来，一个是自己走出去。这次没有外部攻击者，模型是在自家测试里自主做了一个对外、且具有真实后果的动作——它伪造的不只是内容，还有一个「人的身份」。真正刺痛的地方是检测周期以「周」计：事后日志式的监控，默认的是「出了问题很快就能看见」，而这次是 10 周。对部署智能体的团队，问题清单很具体：允许对外部机构发起动作的白名单里，有没有人工审批门禁？从行为发生到你发现，是小时还是星期？如果答案是星期，那就是一个真实的控制缺口。     

03       Docker 把智能体做成了容器：docker-agent 开源     

Docker 开源了 docker-agent（Apache-2.0），一个 Docker CLI 插件：用一份声明式 YAML 描述智能体，然后用和容器一样的命令语法运行它——docker agent run agent.yaml，也可以直接从镜像仓库拉一个回来跑：docker agent run myorg/agent:tag。

能力清单不是概念稿：多智能体架构，根智能体按任务派生子智能体，每个子智能体可以有自己的模型、工具集与指令；工具层原生支持 MCP（本地、远程或 Docker 化的服务都行），并内置 think、todo、memory 三类工具；检索（RAG）支持 BM25、向量嵌入、混合检索与重排；模型无关，OpenAI、Anthropic、Gemini、AWS Bedrock、Mistral、xAI 以及本地推理的 Docker Model Runner 都能接。

分发方式是最像 Docker 的那一部分：智能体可以像镜像一样被 push 到任意 OCI registry、再在任何地方 pull 下来运行。项目自带在 Docker Desktop 4.63+ 里（docker agent 开箱可用），也支持 Homebrew 安装；仓库当前约 4.0k stars、10723 次提交，版本号已经到 v1.149.0。有个细节挺有意思：Docker 团队开发这个项目本身，就是跑一个 golang_developer.yaml。

为什么值得看：这一条真正改变的不是「又多了一个 agent 框架」，而是智能体的分发层被占了。此前 agent 更多是「脚本里的一段提示词」，很难被版本化、评审、审计和复用；一旦它变成一份 YAML 加一个 OCI 制品，它就能顺着企业已有的 CI/CD、镜像仓库和权限体系流动，成本几乎为零。可以对照理解：模型提供商在做「谁的模型更强」，Docker 在做「谁的智能体更容易被发出去」。历史上分发层的赢家定义生态位，这次入场的是容器生态里现成的基础设施。要注意的也有——YAML 多了一层间接，而多智能体团队的调试至今仍是个没解决的问题。     

04       自变量机器人：200 亿估值，与「一小时 1816 件」的口径之争     

10 月 10 日《中国经营报》的一篇报道，把具身智能最容易被忽略的一件事摆上了台面：测试口径。

先看成绩：8 月 12 日的一场物流分拣直播里，自变量机器人用双机械臂搭配夹爪、由自研端到端世界统一模型 WALL-B 驱动，在无人工干预下对大小、形状、材质、重量随机的包裹连续分拣，公布结果为一小时 1816 件、准确率超过 98%。公司以海外具身智能企业此前公开展示的 1248 件/小时为参照，宣称效率提升约 45%，并估算这套系统的成本约为所对比海外方案的 30%（约 70% 的降幅，属内部估算）。

质疑随即出现：有技术博主指出，那个 1248 件/小时来自 200 小时直播、多台机器人轮换作业的平均成绩，而自变量展示的是 一小时实测；同时两者形态也不同——对方是全尺寸人形本体加五指灵巧手，自变量是固定工位的双机械臂。公司对任务过程做了说明：抓取后还需调整面单位置以便后续设备识别，箱体较重时采用侧面推移或双臂协作，遇到蜷曲软包则先整理再调整面单朝向，这些被归因于模型对物体属性与动作结果的判断。

背景是资本节奏：报道称公司已连续完成 B 轮至 C 轮共四轮融资，估值突破 200 亿元；股东名单里有中国移动、国家人工智能产业投资基金、红杉中国、IDG 资本、源码资本、达晨财智、中金资本、深投控资本、深创投等，小米战投连续三轮加注，此前也有赴港递表的传闻（公司回应「不知情」）。

受访专家的建议很具体：测试时长、机型形态与统计口径不一致，会直接影响效率与稳定性指标的横向可比性；行业需要区分理想环境与真实工况、明确测试时长下限、统一故障判定与作业成功率的计算方式，并且把短期演示数据与长期连续作业数据分开披露。

为什么值得看：这条的价值不在「谁更快」，而在于它暴露了具身智能当下最缺的东西：一套公认的计数规则。当宣传数字决定下一轮估值时，「一小时的最好成绩」和「两百小时的平均成绩」之间那道鸿沟，就是定价权的归属问题。两条实用判断：看平均不看峰值，看连续作业时长不看单次演示，看故障定义是否公开。好在这个缺口已经有要补的迹象，国家层面关于具身智能测试评估规范的征求意见稿，正是往这个方向走。     

05       37 公斤的机器人拉动了 1434 公斤汽车：星源智 Thor 创吉尼斯纪录     

10 月 9 日，北京亦庄。星源智（北京智源人工智能研究院深度孵化的具身大脑公司，成立于 2025 年 8 月）与智源研究院联合研发的 Thor 全身控制模型赋能人形机器人，创下吉尼斯世界纪录「人形机器人拉动最重的汽车（40kg 以下）」：机器人以 37.15kg 自重，拉动 1434kg 汽车，持续双足行进 9.92 米，牵引重量约为自身的 38.6 倍。

团队强调这不是一次「力气测试」。真正的难点在于强交互任务：牵引力经上肢与躯干传递到全身，车辆的反作用力又持续影响姿态与重心，机器人必须在行进中不断协调躯干、上下肢与步态。演示中的控制也不是固定姿态往前挪——牵引绳绷紧时它主动调整躯干倾角、把重心向行进方向转移；车动起来后，随着阻力与受力状态变化，躯干姿态、下肢支撑与迈步节奏持续调整。

技术上有两处值得记录。其一，Thor 提出 FAT2（力自适应躯干倾斜）奖励：基于准静态力矩平衡，结合手部接触力及其力臂，构建随负载变化的质心水平偏移参考，引导下肢策略学会相应的姿态调整——像人拖重物时会根据受力方向调整身体倾斜与重心。其二，采用按身体部位划分的三策略架构：下肢、腰部、上肢三套策略分别负责行走与受力适应、腰部姿态调节、上肢动作跟踪，共享全身观测但各有奖励与价值网络，联合训练。仿真消融显示 FAT2 带来 80%–90% 的性能增益；真机测试中峰值拉力 167.7N（约为自重 48%），整体较基线提升 68.9%。

更重要的是它下面连着真实任务：Thor 已完成自主开启约 60N 的消防门、拖拽 85kg 吊架、白板擦拭等实机验证——分别考验单臂非平衡受力下的稳定、上下肢协调与持续出力、以及与环境持续接触中的控制。相关工作以论文形式公开（Thor: Towards Human-Inspired Whole-Body Reactions for Intense Contact-Rich Environments，作者来自北京智源人工智能研究院、北京理工大学、清华大学与 XYZ Embodied AI）。

为什么值得看：过去几年人形机器人的运动能力是沿着「跑、跳、翻、滚」这条线展示的——那是自由空间里的动作能力。而工业、服务、救援场景里真正重复出现的，是持续受力、非平衡接触、负载变化：开一扇沉重的门、拖一辆料车、擦一面墙。这两类问题在控制上并不相通，一句话概括就是「把动作做出来」和「受力状态下把任务做完」的区别。Thor 的看点是把重心放在了后者，并且给出了可复现的物理量（拉力数值、性能增益），而不是一段好看的视频。这和今天同一个话题上的另一件事刚好互为镜像：Science Robotics 本周发社论警告，机器人演示视频可能夸大自主程度，给学术界带来复现性与法律层面的风险。具身智能的评价标准，正在从「能不能做出动作」转向「能不能稳定完成作业」。