人均 Token 会骗人：阿里云用八段看板看组织有没有真用上

人均 Token 会骗人：阿里云用八段看板看组织有没有真用上

阿里云原生社区 2026-07-16 的文章，讲的是怎么用 LoongSuite-Pilot 和日志服务 SLS，把 AI Coding 的用量从个人感觉收成组织能下钻的度量。它引用的是 2026 年 5 月 Google Cloud DORA 的《ROI of AI-Assisted Software Development》。和上一年聚焦个人采用率的 Accelerate 报告不同，这份报告把问题写成：已经不是 AI 辅助开发有没有用，而是怎么向业务证明。

DORA 给的是一组模型数据，不是阿里云自己的账单：500 人的工程团队，AI 工具年投入约 840 万美元，预期回报 1160 万美元，第一年 ROI 约 39%。报告同时写明，这笔回报不会自动兑现。编码变快，不会自动变成组织产出。它用 J 曲线解释：先跌后升。早期有一段生产力下降，工作流、习惯和提示词都是学习成本。只有度过低谷，并且把省出来的能力拿去减少返工，而不是直接砍人，ROI 才会出现在曲线后段。2025 年报告的判断被沿用：AI 是放大器，不是变压器，它放大优势，也放大机能失调。数据还说，绿地项目效率提升可以到 35% 到 40%，遗留代码不到 10%。同一家公司里不同团队的回报曲线可以完全不同。没有事件级度量，组织连自己的 J 曲线走到哪都判断不了。

多数研发组织手里只有两类数。一类是个人满意度问卷，主观，也追溯不了。一类是 CI/CD 的汇总 KPI，告诉你发生了什么，不解释为什么。缺的是中间层：能下钻到 Agent、模型、Skill 或部门的事件级用量。Pilot 按 LoongSuite 的 GenAI 语义采集异构 Agent 的事件流。这套语义是阿里云在 OpenTelemetry GenAI 语义约定上做的扩展，当时社区标准仍在制定，实际调用链常常比「一个用户乘一个模型」复杂，一次请求可能跨多个 Agent。SLS 看板把事件解释成可以下钻、归因和采取动作的组织度量。

量的是 Agent 行为，不是提交了多少行

文章明确不量提交了多少行代码、合并了多少 PR，而量 AI Coding Agent 自己的使用：谁用哪个 Agent、选了哪个模型、消耗多少 Token、调了哪些工具和 Skill。

数据模型是事实表加维度表，用 user.id 和工号 work_no 关联。事实表每一行是一次 Agent 调用，而不是按会话先汇总再上报。核心字段包括用户、gen_ai.session.id、Agent 类型、供应商、请求和响应模型、输入输出和总 Token、工具名、工具参数里的文件路径、事件名。Claude Code、Copilot、Cursor、Qoder 和内部 Agent 对齐同一套字段，事后不用再对账。命令行形态和 IDE 插件进的是同一张事实表。事件级带来三件事：同一套 Token 统计在不同工具之间可以直接比；从 session 可以钻到某一次工具调用的参数，而不是停在「这个人上周 Token 很高」；工具参数里的文件路径能对上具体的 SKILL.md，于是「团队积下来的 Skill 有没有真被用」变成可量化的问题。

人员维度表回答「是谁」。事件里的用户标识映射到组织：工号、姓名、部门全路径，例如技术研发部、工程平台部、数据服务组。维度表定期同步到 SLS，不在事件上报时把部门写死。原因有三。组织调整只改维度表，已上报的事件不回溯修改，才能用最新组织看历史。LEFT JOIN 能把「维度表里有、事件表里没有」的人列出来，这份「登记了但没上报」的名单，往往比好看的图更能推动落地。部门路径一次拆成一级部门、二级部门、团队，下游图只 JOIN，不必每张图重写拆分。

接入层要回答的只有三句：采什么，用统一语义的事件；怎么采，Pilot 不区分来源；跟谁关联，人员维度表。做完之后，SLS 里才有「事件乘组织」。

三十多张图共用同一套定义，活跃用户没有唯一标准

分析层直接建在 SLS 看板上，每张图背后是一条 SQL。文章选择这条路，是因为度量随团队变、需求迭代快。什么叫活跃用户、部门怎么拆、覆盖率的分母是已登记员工还是全体员工，没有唯一正确答案。文中的例子是：有的组织按三级部门拆，有的按项目组；有的把活跃定义成过去 7 天有事件，有的定义成过去 30 天有事件且 Token 大于 1000。这些差别用一条 WHERE 就能表达。事件进 SLS 后可以马上查，没有额外 ETL，也没有 T+1。新接一个 Agent，发布后几分钟内就能在看板上确认数据是否在流。

灵活之后要防止三十多张图各说各话。全部图共用同一组 CTE。第一段 dept_user 把部门路径按连字符拆成三级，统计范围只在这里定义一次。第二段 active_user 按天、用户、Agent、供应商、模型预聚合输入、输出、总 Token 和事件数。空值和字符串 null 收成 unknown。绝大多数图是部门表 JOIN 这张预聚合，不必每张图重写汇总。更细的图，例如 Skill 路径和仓库，退回原始事件表，但人员 JOIN 仍然复用 dept_user。

后面八段截图里的数，文章写明全部是模拟数据，用来说明报表结构，不代表真实业务。本文不把这些模拟读数当成阿里云的用量成绩。

第一段是水位。卡片包括活跃员工、总 Token、会话数、Agent 事件、人均 Token、以及没有上报用量的员工。每张卡带周环比。环比掉下去，就钻到对应段找原因。SLS 的 compare() 和跨表 CTE 的 JOIN 不兼容，会直接报错。所以环比改成手写时间窗：以事件表里的最大时间为终点，当前窗是向前 604800 秒（7 天），对比窗再向前一个 7 天，也就是 1209600 秒到 604800 秒之间。SQL 更长，但是在「CTE 加 JOIN」这套结构里能稳定跑的写法。

第二段是结构。三张饼图按 Agent 类型、模型、供应商切 Token 占比，回答工具要不要收敛、供应商怎么集中采购、成本怎么归集。三张图都跑在同一对 JOIN 上，只改 GROUP BY。

第三段是趋势。覆盖人数和事件数、输入输出和总 Token、按 Agent 的事件与 Token，以及 Token 发生在一天中的哪个时段。趋势用来判断是在稳步增长，还是推广一波之后回落，某个 Agent 是越来越重要还是被换掉。时段如果集中在凌晨，文章把它解释成自动化作业占比上升，和管理上由人在工作时间交互驱动，不是同一种模式。按天的预聚合已经丢掉小时。要看时段，必须绕开 active_user，另做一张按小时聚合的表，再 JOIN 人员维度。这是下游要比 CTE 更细时的退路。

第四段是部门。表上有部门、总人数、用户数、覆盖率、事件数、输入输出和总 Token、人均 Token，旁边是「没有正常上报」的员工名单，再加上按总 Token、覆盖率、人均 Token 排序的前 10。三个排序对应三种动作：规模低的要推广，覆盖率低的要从个人先用推进到团队标配，人均低的可能要改工具配置或用法。用户数为 0 的部门不能滤掉，他们正是推广对象，所以用 LEFT JOIN，不用 INNER JOIN。覆盖率是用户数除以总人数，分母为 0 时用 nullif 避开。人数用近似去重。未上报名单是同一次 JOIN 再加 user_id 为空。

第五段从部门落到人。员工明细包括姓名、工号、团队、Token、事件数、用过的 Agent 和模型，以及按 Agent、按模型的汇总。一个人用过哪些工具，要把多个值收成可读字段。不能只做去重聚合，还要排序后再拼成字符串。否则周报导出的 CSV 会因为数组顺序抖动，产生大量假差异。同时给出每个事件的平均 Token：总 Token 除以事件数。

第六段是 Skill 和工具。三张前 10：Skill 调用次数、Skill 使用人数、工具调用次数。调用次数是强度，使用人数是铺开的广度。两个都高，才算沉成组织资产；调用高但人数低，仍是个人探索。Skill 名要从文件路径里抽。路径变体包括 skills 目录、带版本号的子目录，以及 .qoderwork 下的 .skill.md。规则是：上一段如果像版本号，就再往上取文件夹名；上一段如果是 skills、skill、.claude、agents、resources、.qoderwork、docs 这类容器目录，就用文件名并去掉后缀；否则用倒数第二段。结果为空、或名字就是 SKILL 的丢掉。这条查询必须绕开 active_user，因为文件路径不在预聚合里。页面上这段 SQL 的末尾写成 LIMIT 1，和上文「前 10」不一致。不能把 LIMIT 1 读成已经定稿的排名条数。

第七段是代码仓库。前 10 仓库的 Token，以及 Git 域名的占比，用来看投入是流进核心业务仓库还是散在实验项目，主要耗在内部 GitLab 还是外部 GitHub。git.repo 和 git.domain 不能放进 active_user。一旦按仓库分组，行数会从「人乘天」胀成「人乘天乘仓库」，把所有下游图拖慢。所以这里退回原始事件表，仓库空值收成 unknown，再按总 Token 取前 10。预聚合不是越宽越好。

第八段是集中度，用来检验前面所有「总量」会不会骗人。第一节的人均 Token 好看时，必须问这是大家都在用，还是少数头部把均值撑起来。文章给的判断线是：如果前 10% 的人占了超过 70% 的 Token，总量再大，组织仍停在「少数人的个人生产力」。这是一条如果，不是他们公布的实测占比。看板上有前 10% 和前 20% 的 Token 占比、三档人群（前 10%、10% 到 20%、后 80%），以及按日的集中度趋势。集中度持续下降，被解释成从个人能力扩散成组织共同能力。算法是先按人汇总 Token，丢掉 Token 为 0 的人，再按 Token 降序编号，用窗口函数数总人数和总 Token，前 10% 的边界是人数乘 0.1 再向上取整。人数不能整除时也能取到边界。按日趋势只是在排名上再按天分区。

三层路径，模拟图不能当成成绩

收束是三层。第一层，统一语义解决按什么标准记，Pilot 解决异构 Agent 怎么采。Claude Code、Copilot、Cursor 都按同一套字段进 SLS，跨工具可比，跨时间可追溯。第二层，SLS 上 SQL 是唯一定义语言，公共 CTE 保住三十多张图的算法一致。八段从总览、结构、趋势、人员，到 Skill 复用、仓库和集中度，每一段给更细的判断提供上下文。第三层，人员表用 LEFT JOIN 露出「登记了但没上报」的空白，集中度用来验证人均是不是被头部撑起来。这些被写成可以直接变成动作的信号，不是好看的数。AI 是放大器。度量层的价值是让组织看清自己在放大什么。

限制：840 万美元、1160 万美元、39%、35% 到 40%、不到 10%，是文中转述的 DORA 模型数据，不是这套看板跑出来的阿里云结果。八段截图明确是模拟数据。前 10% 超过 70% 是判断线，不是实测。7 天、30 天、Token 大于 1000 是不同组织可以自己写的活跃定义示例。Skill 查询末尾的 LIMIT 1 与前 10 的图不一致。

出处：阿里云，Alibaba Cloud Native Community，From Individual Productivity to Organization Capability: AI Coding Measure Practices of LoongSuite-Pilot and SLS，2026-07-16，https://www.alibabacloud.com/blog/from-individual-productivity-to-organization-capability-ai-coding-measure-practices-of-loongsuite-pilot-and-sls_603363