Unity 命令行 98% 由智能体调用，做成多少没说

游戏引擎 Unity 的命令行工具，主要调用者已经从开发者换成了编程智能体。Unity 10 月 22 日公布的遥测显示，7 月 20 日到 10 月 13 日，约 98% 的命令行运行来自编程智能体和其他自动化，人亲手在终端里敲的只占 0.2%。

先说我们的看法：这个 98% 衡量的是「谁在按回车」，不是「多少开发者把活交给了智能体」，更不是「活做成了多少」。它真正说明的变化在工具这一侧：Unity 已经把智能体当成命令行的第一用户来设计，而智能体在 Unity 里把事情做成的比例，目前没有人公布。

发生了什么

据 Unity 官方博客 10 月 22 日的文章（企业宣称），自 7 月以来，超过 22.6 万名登录用户用过 Unity 命令行，累计记录了 2 亿多条事件，几乎都是命令运行。按来源分：编程智能体和其他自动化约 98%，人在终端里直接输入 0.2%，持续集成流水线 0.3%，剩下一小部分不属于这三类。

运行最多的三条命令都是在操作一个正在运行的编辑器：unity command（把命令转给已连接的编辑器）约 1.24 亿次，unity status（查看已连接编辑器的状态）约 670 万次，unity pipeline list（列出编辑器实例）约 140 万次。Unity 说，大部分用量出现在它为 Claude Code、Codex 以及最近的 Grok 发布官方插件之后；用得最多的是 Claude Code，其次是 Codex，再往后是 Cursor 和 Grok 等。

这套工具本身很新。Unity 7 月 20 日介绍命令行的文章（企业宣称）写明，让命令行驱动运行中编辑器的 Pipeline 包仍是实验性的；它把目标写得很直接：让 AI 智能体能观察一个正在运行的项目、在里面动手、再核对结果。Unity 的命令行参考文档（官方文件）里，「已连接编辑器与 AI 智能体」单列一组命令，还有一条 skill 命令专门读取或安装给智能体用的技能说明。

98% 怎么算出来的

这个数的口径写在博客末尾的方法说明里，值得逐条看：

• 分母是运行次数，不是人。一个开发者设置好之后，智能体可能连续发出成百上千条命令。分析推断（依据为上面的命令分布）：unity command 一项就约 1.24 亿次，约占全部事件的六成，智能体反复操作编辑器会把运行次数迅速推高，所以 98% 天然偏向调用频繁的一方。
• 「智能体」的筐装得很宽。以 MCP 模式运行、来自已知 AI 工具的运行，以及其他通过管道或脚本发起的运行，都算进「智能体和其他自动化」。也就是说，一部分普通脚本也被计入，98% 是智能体占比的上限，不是精确值。
• 「人」的判定很窄。只有输入和输出都是终端时才算人在操作。
• 样本有排除。Unity 员工不计入，关闭遥测的开发者不计入。

为什么重要

对智能体与应用这条线来说，这是一个少见的、由工具厂商而不是模型厂商公布的调用数据，它说明入口变了。据 Unity 的描述，开发者在 Unity 命令行里做的主要是准备工作，比如装 Pipeline 包、按正确版本打开项目、登录、把智能体指向 Unity、装上技能，然后把操作交出去。厂商的应对也随之变化，写技能、做插件、在文档里给智能体单开一组命令。

但调用多，不等于成果多。哈佛大学两位研究者 Fiona Chen 和 James Stratton 的工作论文（第三方评测，8 月 4 日版）用工程分析平台 Jellyfish 的数据，覆盖 718 家公司约 3 亿条工作记录，比较各公司引入编程智能体前后的变化：引入智能体后，代码行数增加约 30%，提交数增加约 20%，合并请求增加约 23%；但按 Jira 工单和大型需求的完成数衡量，变化在统计上不显著，置信区间排除了工单完成数增幅超过基线 12% 的可能。论文把原因指向代码审查：审查一个合并请求的平均时间增加 49%，被要求修改的合并请求占比从约 13% 几乎翻倍，每个合并请求的评论数增加 35%，参与审查的员工占比增加 14%。

需要说明口径：InfoQ 10 月 22 日的报道（媒体报道）写成「智能体带来 12% 的工单完成增长」、评论数「增加 53%」，和论文原文不一致；论文写的是 12% 是置信区间的上限、评论数增加 35%，我们以论文为准。论文研究的是一般软件公司，不是 Unity 用户，两组数据分母不同，不能直接相乘或比较。

分析推断：把两件事放在一起看，Unity 的数据回答了「谁在操作工具」，哈佛论文提醒的是「操作之后谁来验收」。智能体在编辑器里跑得越多，验收就越可能成为瓶颈，而 Unity 这次没有公布任何关于任务完成、构建成功或人工返工的数字。我们在《AI 编程预算按人头封顶，回报还算不出来》里写过，企业先学会了管花费，还没学会算回报；Unity 的数据是同一处空白在工具侧的样子。

最强反方

最有力的反驳是：运行次数本来就是衡量工具被谁使用的合理指标，人只占 0.2% 已经足够说明操作方式变了，不必等完成率；而且智能体反复调用 unity status 这类命令，恰恰说明它在核对结果，这本身就是在做验收的一部分，不能把高调用量当成空转。

我们部分接受：操作方式确实变了，这也是我们认可的「改变了什么」。但我们仍坚持，98% 不能读成「多少工作由智能体完成」。它把脚本也计入了智能体一侧，分母是会被循环调用放大的运行次数，而且没有任何关于结果的数据。这个判断在一种情况下要修正：Unity 公布按任务计的完成率或返工率，并且显示智能体发起的工作大多一次做成。

我们不知道什么

• 98% 里智能体和普通脚本各占多少，Unity 没有拆开。
• 22.6 万登录用户里，有多少人真的让智能体在项目里干过活，有多少只是装过一次；Unity 没有给出按用户计的智能体使用比例。
• 智能体发起的命令有多少执行成功、多少需要人返工，没有公开数字。
• 各个智能体的具体份额只给了排名，没有比例。
• 哈佛论文是尚未正式发表的工作论文，数据来自付费分析平台的客户，不一定代表全部公司；论文没有单独研究游戏开发。

接下来看什么

三件事可以对照：Unity 下一次公布数据时，是否加入按任务计的完成或失败口径；其他开发工具厂商公布智能体用量时，分母是运行次数还是用户数；以及使用 Unity 的团队是否开始公开智能体改动的审查和回滚情况。