企业官网建设流程全解析

Kilo AI Adoption Dashboard 详解：用 0–100 分量化团队 AI 采纳成熟度

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

AI Adoption Dashboard（AI 采纳仪表盘）是 Kilo 面向工程管理者的团队协作能力模块，它把"团队到底有没有真正用上 AI"这一模糊问题，收敛为一个 0–100 的AI Adoption Score（AI 采纳分），并按 Frequency（频率）、Depth（深度）、Coverage（覆盖率）三个维度拆解成因。本文将以 overview.md 为主体，结合同目录下的 understanding-your-score.md、improving-your-score.md、for-team-leads.md 三份文档，完整讲解该仪表盘的访问方式、界面构成、评分机制、等级划分、提升策略与团队管理用法。读完后，你将能够登录 Kilo 控制台解读自己的采纳分、定位团队采纳差距，并制定可执行的改进计划。

一、AI Adoption Dashboard 是什么

AI Adoption Dashboard 帮助工程管理者理解团队在整个开发流程中使用 AI 的深度与一致性。它提供：

• 一个单一的AI Adoption Score（0–100），量化组织级 AI 成熟度；
• 按维度（Frequency / Depth / Coverage）拆分的详细视图；
• 随时间变化的趋势可视化与周环比指标。

在 collaborate/index.md 的文档导航中，Adoption Dashboard 与 Sessions & Sharing、Teams、Enterprise 并列为团队协作四大模块，说明它定位为 Kilo 付费团队/企业能力中的"采纳度量"组件，与 Teams 计划的团队分析能力相辅相成。

适用对象

该仪表盘面向team leads（团队负责人）、engineering managers（工程经理）和 executives（高管），典型诉求包括：

• 追踪整个组织 AI 集成的进展；
• 用单一基准数字横向对比不同团队；
• 识别低采纳、中采纳、高采纳团队；
• 向干系人（stakeholders）给出一个可引用的简单指标——例如"我们目前是 63 分，目标做到 80 分"。

二、访问方式

按照官方文档，进入仪表盘的步骤为：

1. 打开 app.kilo.ai 并登录；
2. 选择你的组织（organization）；
3. 在仪表盘导航中点击Usage（用量）标签页；
4. AI Adoption Score 卡片会出现在用量视图的顶部。

提示：仪表盘属于组织级功能，需要先配置好 Teams 或 Enterprise 组织（参见 collaborate/index.md 中的计划说明），并确保团队成员通过 Kilo 的各端（IDE 扩展、CLI、Cloud Agent）产生真实使用事件。

三、仪表盘界面构成

1. 主分数展示（Main Score Display）

仪表盘顶部醒目地展示当前 AI Adoption Score，以百分比形式呈现（例如 "Current: 45%"）。该分数代表组织在真实开发工作流中使用 AI 的深度与一致性。

2. 时间线可视化（Timeline Visualization）

一张**堆叠柱状图（stacked bar chart）**展示每日采纳分的演变。图表使用三种颜色对应分数的三个维度：

• 蓝色（Blue）—— Frequency：开发者使用 AI 的频率；
• 绿色（Green）—— Depth：AI 融入开发的程度；
• 橙色（Orange）—— Coverage：AI 在团队中的普及广度。

3. 时间范围过滤器（Time Period Filters）

4. 个人视图与组织视图（Personal vs. Organization View）

通过"Only my usage"（仅我的用量）开关切换：

• 开启：只展示你个人的采纳指标；
• 关闭：展示组织/团队范围的聚合采纳指标。

5. 趋势指标（Trend Indicators）

仪表盘底部有四个指标卡片，展示周环比变化：

• Total—— 总分趋势；
• Frequency—— 使用频率变化；
• Depth—— 集成深度变化；
• Coverage—— 团队普及度变化。

每张卡片显示百分比变化（如 "+2.3%" 或 "-1.5%"）并带方向指示。

四、三大维度：评分如何构成

AI Adoption Score 由三个加权维度组成：

点击任意维度卡片，可查看该维度的详细分析与针对性改进建议（详见下文"提升策略"与"团队管理用法"）。

Frequency —— 频率（占 40%）

衡量团队使用 AI 工具的规律性，按人均归一化后在组织内混合统计。核心信号：

• 每天 Agent 交互次数（agent interactions per day）；
• 自动补全接受量（autocomplete acceptance）；
• Cloud Agent 会话数（cloud agent sessions）；
• Reviewer Agent 运行次数（reviewer agent runs）。

高频团队的特征是把 AI 变成日常习惯，而不是只在难题时才想起它；低频往往说明开发者尚未把 AI 编入常规工作流。从源码结构看，自动补全信号与 kilo-gateway 的 autocomplete.ts 及配套的 FIM（fill-in-the-middle）端点 fim.ts 相对应，说明该维度确有真实埋点支撑，而非纯文档设想。

Depth —— 深度（占 40%）

衡量开发者对 AI 的信任与依赖——AI 是旁路工具，还是团队交付代码的核心环节。核心信号：

• 每小时工作时长的查询数（queries per hour worked）；
• AI 建议的接受比例；
• 合并进代码库的 AI 生成行数；
• 留存率（retention rate）：AI 建议行数中原样合并（未改动）的比例；
• 多 Agent 链（coding → review → deploy）。

高 Depth 意味着开发者信任 AI 输出并愿意让它进入交付链路；低 Depth 则暗示开发者可能在试用 AI 但并未采纳其建议，背后可能是上下文质量问题或信任问题。

Coverage —— 覆盖率（占 20%）

衡量 AI 在团队中的触达与落地广度——有多少成员在用、一周内使用得是否连贯。核心信号：

• 每周使用任意 AI Agent 的用户占比；
• 使用 2 个以上 Agent 的用户占比；
• 使用 4 个以上 Agent 的用户占比；
• 工作日使用广度（一周内分布均匀 vs 集中在某几天）。

Coverage 能暴露采纳断层：一个团队可能靠少数重度用户拉高了 Frequency 和 Depth，而其他成员几乎不用 AI。

五、分数等级（Score Tiers）

总分落在五个等级之一，可直接用于目标设定：

六、分数是如何计算的：四种归一化机制

为了让不同规模的团队分数可比较、抗干扰，评分体系应用了以下技术（见 understanding-your-score.md）：

1. 按开发者归一化（Per-Developer Normalization）

用量按人均归一化：10 人团队中等使用强度与 50 人团队中等使用强度得分相当——原始总量不会抬高分数。

2. 异常值封顶（Outlier Capping）

对个别重度用户（power user）的极端用量做封顶，防止一个人把全队分数带偏。

3. 滚动窗口（Rolling Window）

分数基于周滚动窗口计算，平滑日常波动，同时仍能响应真实的行为变化。

4. 多源聚合（Multi-Source Aggregation）

分数聚合来自多个表面的事件流：

• IDE—— 自动补全与编码 Agent 交互；
• CLI—— 终端中的 AI 使用；
• Reviewer Agent—— AI 辅助代码评审；
• Cloud Agent—— 浏览器端 AI 会话。

这与上文的 Frequency 信号（autocomplete、Cloud Agent、Reviewer Agent）一一对应，也与 kilo-gateway/src 中 autocomplete、edit、fim 等端点的存在相互印证——各使用面通过网关产生可聚合的事件数据。

七、分数为什么会波动

分数会逐周变化，需要区分两类原因：

正常波动：

• 成员休假或请假；
• 冲刺末 vs 冲刺初的节奏差异；
• 季节性变化（节假日、夏季放缓）。

有意义的实质变化：

• 新成员 onboarding（可能暂时拉低 Coverage）；
• 成员离开组织；
• 开发流程或工具链变化；
• 成功的采纳计划落地。

八、如何解读分数

看趋势而非绝对值

具体数字不如方向重要。45 分意味着"早期采纳、有成长空间"，但它好不好取决于上个月你在哪、接下来要去哪。

对比维度定位短板

总分偏低时，看哪个维度在拖后腿：

• Frequency 低→ 着力培养日常习惯；
• Depth 低→ 改善信任与上下文质量；
• Coverage 低→ 聚焦 onboarding 与激活。

看分布而非只看均值

仪表盘展示的是聚合分数，但真正的洞察往往来自分布：一个 50 分的团队，可能是"一半人 80+、一半人 20"——这与"所有人都是 50"完全不同。

个人分数的定位

个人分数可通过 "Only my usage" 开关查看。但 AI Adoption Score 的真正价值在于：聚合的团队指标（组织趋势）、分布分析（识别采纳断层）、横向基准对比（设定与追踪目标）。个人分数更适合自我评估与个人成长，不应作为绩效评价依据。

九、提升分数的实操策略

点击仪表盘中任意维度卡片，会看到基于团队用量模式生成的个性化建议。以下按维度给出完整策略（详见 improving-your-score.md）。

提升 Frequency：把 AI 变成每日习惯

目标：帮开发者把 AI 编入日常流程，而不是只在难题时使用。

① 走出 IDE，扩展到终端

大量开发工作发生在终端——git 操作、调试、写脚本。把 AI 带到这些场景能增加每日触点。安装 Kilo CLI 以启用终端 AI 工作流：

npm install -g @kilocode/cli

同时使用 IDE 与 CLI 两种表面的团队，日活往往更高，因为 AI 随处可用。

② 从自动补全开始

自动补全天生低摩擦——无需显式提示，后台静默工作。适合团队在以下场景建立肌肉记忆：样板代码、重复模式、常见语法、测试脚手架。让团队坚持使用自动补全一周，即可在不改变行为习惯的前提下获得稳定日活。

③ 把 AI 挂到既有流程上

高 Frequency 的团队通常没什么花哨操作，只是把 AI 织进了日常事务：

• 站会准备—— 总结近期变更或生成状态更新；
• 上下文查询—— 快速理解陌生代码；
• PR 描述—— 生成 PR 描述初稿；
• 文档—— 创建或更新行内注释。

小规模的重复使用，累积起来比偶发的大活更有效。

提升 Depth：让 AI 从旁路工具变成交付核心

目标：让 AI 从旁路工具成为团队交付代码的一部分。

① 串联工作流（Chain Your Workflows）

AI 触及同一任务的多个阶段时 Depth 会提升。推荐"链式工作流"模式：

1. Plan（规划）—— 用 Architect 模式设计功能；
2. Build（构建）—— 用 Code 模式实现；
3. Review（评审）—— 用 Code Reviews 审视产出。

提示：把 coding → review → deploy 串起来能显著提升 Depth 分。

② 给 AI 更好的上下文

接受率低时，问题往往出在上下文——AI 在不理解你的代码库的情况下提建议。启用 Codebase Indexing（代码库索引），让模型获得基于向量检索的全仓库搜索能力。更好的上下文带来：更相关的建议、更高的接受率、更强的信任、更深的长期集成。

③ 在真实环境中验证 AI 输出

从不运行的生成代码难以建立信任。能让团队在真实环境验证 AI 产出的团队，长期保留这类代码的比例更高。使用 Kilo Deploy 为分支生成实时 URL，让团队在合并前先验证改动（参见 deploy-secure 文档目录）。

提升 Coverage：让更多人用上更多能力

目标：让更多团队成员用上平台的更多能力。

① 引入专用 Agent 模式

多数团队从 Code 模式起步就止步了，但 Kilo 的其他模式能解锁更多价值：

这既提升效率，也增强团队对 AI 化任务协作的信任。

② 激活闲置席位

Coverage 很大程度上是"数字游戏"。未登录或未使用的成员会直接拉低分数。建议检查组织仪表盘中的未激活席位，判断这些成员需要：提醒他们已有访问权限、安排上手培训、给出起步指引、或与热情成员结对。

③ 让使用铺满整周

"周一大爆发、其余时间寂静"的尖峰式使用会限制 Coverage。把 Code Reviews 纳入 PR 流程是最自然的解法——评审每周都在发生，AI 使用也随之铺开。其他方式：每日站会用 AI 准备、每日结束时用 AI 写文档或 commit message、周中用 Architect 模式做设计评审。

十、团队负责人的仪表盘用法

阅读团队级指标

关闭 "Only my usage" 即可看到全队聚合指标：

• 总体 AI Adoption Score—— 单一基准数字；
• 维度分解—— Frequency、Depth、Coverage 各自的贡献；
• 周环比趋势—— 变化方向与幅度；
• 历史时间线—— 按天/周/月的分数演进。

点击任意维度卡片可打开详情面板，包含：该维度的聚焦时间线、维度目标说明、以及与该维度度量内容对应的三条可执行改进建议。

诊断采纳断层

低 Coverage 信号：问自己——所有成员都登录且活跃吗？某些角色或小组是否缺席？使用是否集中在特定几天？行动：检查组织仪表盘中的未激活席位，找出谁没用（新员工？特定角色？），安排针对性 onboarding 或结对。

低 Depth 信号：接受率低吗？AI 生成的代码真的被合并了吗？开发者是否跨多个阶段（plan → build → review）使用 AI？行动：启用 Codebase Indexing 改善上下文质量、审视建议与代码库的相关性、引入链式工作流。

低 Frequency 信号：开发者知道 IDE、CLI、Cloud 全部可用表面吗？AI 只在偶发的难题上触发吗？有没有把 AI 编入日常任务？行动：把 AI 映射到现有日常任务、确保安装了 CLI、发起"试用自动补全一周"挑战。

设定目标与发起计划

以分数等级作为里程碑：

建议一次只聚焦一个维度，而不是同时改所有指标。

计划示例：

• Frequency："自动补全周"（全员每日使用自动补全）、CLI 30 分钟上手课、每天在 Slack 分享一个 AI 用例；
• Depth："链式挑战"（用 plan → build → review 完成一个完整功能）、全队启用 Codebase Indexing、用 Deploy 预览验证 AI 产出；
• Coverage：新人 onboarding 纳入 Kilo 配置、站会分享每周 "AI wins"、让低用量开发者与积极采纳者结对。

进度追踪四步：先记录基线分数 → 每周查看趋势而非绝对值 → 某维度不动就换策略 → 达成里程碑时庆祝。

与干系人沟通

AI Adoption Score 的设计目标就是"可引用"：

"上个季度我们 38 分，这个季度 57 分，Q2 目标是 70 分。"

汇报要点：先说趋势再说数字、解释所在等级及其含义、关联业务结果（"更高采纳 → 更快开发周期"）、说明正在采取的具体行动。

示例干系人更新：

AI 采纳更新 —— 2025 年 1 月

• 当前分数：57（成长采纳等级）
• 上月：48
• 变化：+9 分，主要由 Depth 提升驱动

已采取的关键行动：

• 启用 Codebase Indexing 改善 AI 上下文
• 所有 PR 引入 Code Reviews
• 完成 3 名未激活成员的 onboarding

下一步：

• 2 月底目标 65 分
• 聚焦 Coverage——让使用铺满整周

隐私与数据注意事项

• 仪表盘中的个人用量数据是匿名的：管理者能看到聚合指标，但看不到单个开发者的活动明细；
• 仪表盘用于团队级洞察、组织趋势、横向基准，不用于个人绩效评价、识别低绩效个体或监控开发者活动；
• 用分数去识别采纳断层，而不是评判个人。

十一、常见模式与反模式

推动采纳的模式：

要避免的反模式：

十二、按分数段的快速行动清单

0–20（最低采纳）：1) 确保所有成员有权限且已登录；2) 办一场 30 分钟 "Getting Started" 培训；3) 全员试用自动补全一周；4) 回查完成率。

21–50（早期采纳）：1) 找出最活跃用户，学习他们在做什么；2) 引入 Code Reviews 铺开使用；3) 启用 Codebase Indexing 改善上下文；4) 设定月度分数目标（如"下月到 55"）。

51–75（成长采纳）：1) 引入链式工作流（plan → build → review）；2) 聚焦 Depth——建议是否被接受并保留？3) 处理未激活席位与低用量死角；4) 考虑用 Kilo Deploy 验证 AI 产出。

76–90（强采纳）：1) 做得很好，保持势头；2) 关注留存率——多少 AI 代码原样合入？3) 扩展到边缘场景：CI/CD、文档、测试；4) 向其他团队分享你的实践。

十三、快速参考：想查什么、去哪看

十四、规划中的未来增强

官方文档披露了两项规划能力（注意：尚未上线，属路线图信息）：

1. 代码贡献追踪（Code Contribution Tracking）：追踪 AI 贡献代码从功能分支到主分支的过程，回答"AI 建议的代码有多少真正发布""代码库中有多少 AI 辅助代码"。该指标独立于 Adoption Score，用于衡量 AI 对产出的影响。
2. 团队对比视图（Team Comparison Views）：支持组织内多团队横向对比，帮助管理层从高绩效团队提炼最佳实践。

结语

AI Adoption Dashboard 把"团队 AI 成熟度"从口号变成了可度量、可对比、可改进的数字：单一 0–100 分数 + Frequency/Depth/Coverage 三维分解 + 周滚动窗口归一化计算，配合等级目标、逐维度改进建议与隐私保护设计。对工程管理者而言，它的正确用法是看趋势、找断层、定计划——而不是评价个人。相关完整文档链包括 仪表盘总览、理解你的分数、提升你的分数 与 面向团队负责人的用法。

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode