企业官网建设流程全解析

Kilo Code 团队协作与组织管理完整指南：会话共享、Teams/Enterprise 计划与 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

本文以 Kilo Code 官方文档中 Collaborate（协作）模块为核心，系统讲解会话（Session）的创建、共享与 Fork 机制，Teams/Enterprise 付费计划的订阅、计费与团队管理实操，以及 AI 采用度仪表盘（AI Adoption Dashboard）的评分模型与提升策略。读完本文，你将掌握如何在团队中落地 Kilo Code 的协作能力：从一条共享链接协作开发、在 10 分钟内完成组织搭建与席位开通，到通过 0–100 的采用度评分量化团队的 AI 落地程度并制定可执行的提升路线。

文档主体位于 packages/kilo-docs/pages/collaborate，其中index.md是协作功能的总入口，分册子文档覆盖会话共享、团队管理、企业特性与采用度仪表盘四个方向。

会话与会话共享（Sessions & Sharing）

会话是什么：跨平台的上下文载体

会话是 Kilo Code 中与平台无关的交互单元，它记住你在开发过程中的完整上下文，使你随时可以暂停并在不丢失任何信息的情况下恢复工作。根据 sessions-sharing.md 的说明，一个会话会为你保留四类信息：

• 仓库（Repository）：你选择要操作的代码仓库；
• 对话记录：你与 Agent 之间的完整问答（你的提示词与 Agent 的回复）；
• 任务元数据：Agent 当前正在为你执行的任务描述；
• 可选的 Git 上下文：例如仓库 URL 与一份轻量的状态快照，方便 Agent 从上次中断的位置继续。

正是这些信息让 Kilo Code 能够在界面上展示最近会话，并在你重新打开时从完全相同的上下文继续工作。

本地会话、云会话与共享副本的区别

会话数据有三层存储形态，理解它们的边界是安全使用的前提：

本地会话历史与元数据存储在运行 Kilo 的机器上的 SQLite 数据库中（macOS/Linux 位于~/.local/share/kilo/kilo.db，Windows 位于%USERPROFILE%\.local\share\kilo\kilo.db），云会话与共享副本则使用 Kilo 的云服务，与本地数据库相互独立。如需定位本地数据库、按标题或对话内容搜索会话、或用 CLI/SQLite 直接检查会话，可参考 session-history.md——注意本地会话使用 SQLite 而非 PostgreSQL，应使用kilo db或sqlite3而非psql来检查。

从源码结构看，CLI 层对云会话提供了显式的导入支持：在 packages/opencode/src/kilocode/cloud-session.ts 中，importCloudSession封装了 SDK 的.kilo.cloud.session.import()调用，将云会话导入本地存储并返回新的本地会话 ID，失败时会提取网关返回的人类可读错误信息（importErrorReason），而不是暴露[object Object]之类的原始对象。这印证了文档中"云会话与本地会话相互独立、可转换"的设计。

快速开始：创建并恢复会话

创建会话只需三步：

1. 选择仓库：挑选你要让 Agent 操作的 GitHub 仓库；
2. 描述任务：例如"添加深色模式开关和单元测试"；
3. 选择交互入口：通过 CLI、Cloud Agent 或你喜欢的 IDE 扩展（VS Code / JetBrains）与 Kilo 交互。

恢复会话同样简单：打开 Cloud Agents → Recent Sessions，选中要恢复的会话，聊天窗口会加载此前的消息与上下文，Agent 无需你重新解释任务即可继续。

只读共享：把会话变成链接

你可以通过链接把会话共享给任何人。一个共享页面会展示：

1. 分享者信息、会话标题与一段对话预览；
2. 安全的"在编辑器中打开（Open in Editor）"或 CLI 操作，让协作者可以亲自尝试该会话；
3. 以/share/SHARE_ID形式存在的 URL，对持有链接的任何人可见。

关键设计是：共享创建的是只读副本，你的私有会话仍然保留在自己的账户中，不会被公开。

Fork 共享会话：把别人的会话变成你的

如果有人与你共享会话，你可以 Fork 它来创建自己的副本：

• 在共享页选择"Open in Editor"（推荐）；
• 或运行 CLI 命令：kilocode --fork SHARE_ID；
• 或在应用内执行命令：/session fork SHARE_ID。

Fork 会在你的账户中创建一个拥有新 ID 的会话，并复制相关上下文，使你可以独立继续开发。

从源码看，CLI 的run命令对这些能力提供了完整的参数支持。在 packages/opencode/src/cli/cmd/run.ts 中定义了：

• --fork：继续前先 fork 会话（要求与--continue或--session搭配）；
• --cloud-fork：从云端拉取会话并在本地继续（与--session搭配使用）；
• --share：共享该会话；
• --continue（别名-c）：继续上一个会话；
• --session（别名-s）：指定要继续的会话 ID。

参数组合的合法性也有校验逻辑：validateCloudFork（见 cloud-session.ts）会拒绝--cloud-fork与--fork、--continue同时使用，并强制要求--session；--fork同样要求--continue或--session（attach.ts与run.ts中均有"--fork requires --continue or --session"的报错）。

安全使用建议

1. 不要把密钥粘贴进提示词中，需要时使用环境变量；
2. 一旦创建共享链接，就要像对待任何公开链接一样对待它——持有链接的任何人（注意是"任何人"）都能查看共享副本；
3. 保持任务描述聚焦，可以用后续追问细化；
4. 善用 setup 命令为 Agent 准备运行环境（如安装依赖）；
5. 协作时，让团队成员共享并 Fork，这样每个人拥有独立的进度与成本。

团队协作：从订阅计划到席位管理

Teams 与 Enterprise 计划对比

Kilo Code 作为 VS Code 与 JetBrains IDE 中的开源扩展可以免费使用；而当组织希望在规模化落地 AI 编码时，付费的Teams与Enterprise计划提供了监控、管理与协作能力。两份计划的详细对比见 about-plans.md。

Kilo Teams（$15/用户/月）的核心价值：

• 无推理加价（No inference markup）：模型用量按提供商原始费率计费，不赚差价；购买积分另收 5% 支付处理费；
• 无速率限制：高峰时段也不会限速或降低服务质量；
• 集中计费：整个团队一张发票；
• 完全透明：可查看每一个请求、成本与用量模式；
• 团队管理：角色、权限与用量控制；
• AI 采用度评分：量化团队使用 AI 加速开发的程度。

Kilo Enterprise在 Teams 全部能力之上增加：

• 模型/提供商限制：控制成本并满足合规要求；
• 审计日志（Audit Logs）：增强可观测性；
• SSO、OIDC 与 SCIM 支持：统一身份认证；
• SLA 承诺：针对支持问题的服务等级协议；
• 专属支持渠道：私密、直接的沟通通道。

需要特别注意的是：付费计划购买与模型提供商积分是两回事——Teams 或 Enterprise 订阅本身不包含任何积分，模型推理仍通过 Kilo 积分按实际用量支付。

10 分钟搭建团队

getting-started.md 给出了完整的开通流程。前置条件：

• GitHub 账户或 Google Workspaces 公司邮箱；
• 初步估算的团队席位数量；
• 用于计费设置的信用卡；
• 团队成员安装 VS Code 或 JetBrains IDE。

Step 1 创建组织：访问 app.kilo.ai，用公司 Google Workspaces 或 GitHub 账户注册（官方建议优先用 GitHub 账户而非个人 Google 账户，后续可更改），在左侧边栏点击Organizations→Create New Organization。

Step 2 订阅 Teams 或 Enterprise：输入组织名称，选择初始席位数量与套餐层级，完成结账流程。

Step 3 邀请团队成员：进入组织页面，点击Invite Member，输入成员邮箱并分配角色：

Step 4 成员安装扩展：成员通过邀请邮件接受邀请，从 VS Code Marketplace 安装 Kilo Code 扩展（kilocode.kilo-code），用被邀请的邮箱登录，即可开始 AI 辅助编码。

开通后即可获得：全部受支持 AI 模型的即时访问、仪表盘中的实时用量追踪、透明的计费明细，以及团队分析能力。

团队管理与角色体系

team-management.md 明确了角色分工：团队中每个人都是Owner或Member。Owner 拥有完整的管理权限（计费、席位分配、模型/提供商选择），并且只有 Owner 才能执行团队管理操作；Member 可使用扩展并在用量仪表盘中查看团队数据。

常用管理操作：

• 添加成员：Organization 标签页 → "Invite Member" → 输入邮箱 → 选择初始角色（Member 或 Owner）→ 发送邀请；
• 移除成员：Organization 标签页 → 找到离开的成员 → "Remove" → 确认移除 →席位立即释放；
• 调整角色：在成员旁边的角色下拉框选择新角色并确认，成员会收到邮件通知；
• 查看团队状态：Organization 标签页展示活跃成员及最近活动、待接受的邀请、全队角色分布。

补充说明：Dashboard 文档中成员角色还包含Admin（团队管理但不涉及计费），邀请时在 Owner 与 Member 之外也可按需分配 Admin。

仪表盘：团队管理中枢

仪表盘文档 描述的是访问 app.kilo.ai 后看到的第一个界面，按标签页组织不同管理职能：

• Organization：团队构成与快捷操作；
• Usage：实时分析与成本追踪；
• Billing：财务管理与发票；
• Subscriptions：计划管理与席位分配；
• Providers and models（仅 Enterprise）：模型可用性与管理；
• Single Sign-On (SSO)（仅 Enterprise）：配置与修改 SSO；
• Audit Logs（仅 Enterprise）：查看组织内的带时间戳用户活动。

Organization 标签页集中展示：组织名称与创建日期、当前席位使用情况（如"8 of 10 seats used"）、活跃成员数及角色分布、数据收集政策状态。成员列表可按名称、邮箱、角色和最近活动时间查看。快捷操作包括购买积分、邀请成员、管理席位与配置政策。

其中数据收集控制值得单独关注，它提供组织级开关：

• 代码训练退出（Code training opt-out）：阻止 AI 提供商使用你的代码进行训练；
• 用量分析（Usage analytics）：控制内部用量追踪。

Usage 标签页提供总支出（当前计费周期）、请求数、平均每次请求成本、Token 用量（输入/输出拆分）、最近 7 天活跃用户等概览指标，以及模型热度排行、时间维度分析（日/周/月趋势）和用户级洞察（仅 Owner 和 Admin 可见）。

用量分析：五个关键指标与三种视图

analytics.md 说明，使用 Teams 或 Enterprise 订阅后，通过 Kilo Gateway 提供商的用量会进入详细分析。仪表盘顶部展示五个核心指标：

• Total Spent：所选时间段的成本总额；
• Total Requests：API 请求总数；
• Avg Cost per Request：单次请求平均成本；
• Total Tokens：处理的总 Token 数（输入 + 输出）；
• Active Users：产生过请求的团队成员数。

支持四个时间范围筛选：Past Week（7 天）、Past Month（30 天）、Past Year（365 天）、All（完整历史）。"Only my usage"开关用于在个人数据与全队数据之间切换。

数据有三种呈现视图：

1. By Day（按日）：按日期聚合，列含日期、成本、请求数、Token 数（悬停可看输入/输出拆分）、活跃用户数。查看团队数据时，点击任意日期行可展开该日各成员的使用明细；
2. By Model & Day（按模型与日期）：在日期之外增加模型列（如anthropic/claude-sonnet-4、openai/gpt-5），点击行可查看当天使用该模型的具体成员及其用量；
3. By Project（按项目）：项目名自动从项目.git/config中名为origin的 remote 解析。例如：

[remote "origin"] url = git@github.com:example-co/example-repo.git fetch = +refs/heads/*:refs/remotes/origin/*

上述配置解析出的项目名为example-repo。你也可以在项目根目录的.kilo/config.json中手动覆盖项目标识（旧的.kilocode/config.json仍作为回退被读取）：

{ "project": { "id": "my-project" } }

用量范围提醒：此分析覆盖所有通过 Kilo Gateway 提供商的用量，不包含通过扩展使用其他非 Kilo 提供商产生的用量——你可以在扩展的主设置页选择使用哪个 API 提供商。所有成本以美元显示并保留精确小数，便于监控消费趋势、识别高用量时段或模型、追踪各成员的成本贡献。

计费模型：席位订阅 + 即用即付积分

billing.md 阐述了 Kilo 席位的双轨计费：每月按席位订阅，叠加按需购买的 Kilo 积分。模型推理按提供商费率计费不加价，购买积分时单独收取 5% 支付处理费——注意这 5% 不会增加组织的积分余额，即 $1 的购买积分对应 $1 的可用用量，手续费另行收取。

组织积分（Organization Credits）由组织 Owner 在仪表盘购买，全组织成员共享同一余额。购买入口：Organization 标签页 → "Buy More Credits" → 选择金额（$50、$100、$250、$500、$1000+）→ 用已保存的支付方式完成付款 → 积分立即可用。成员使用时，在 Kilo Code 扩展的 Profiles 标签页下拉框中选择正确的组织 Profile，即可使用组织积分（与个人积分的使用方式完全一致，只是资金来自组织余额）。

席位管理：添加成员前必须先有空闲席位。计费周期内随时可以加购席位，按周期剩余天数按比例（pro-rated）计费；也可以随时移除空席位，下次付款反映更少的席位数；下次账单日保持不变。

Automatic Top-Up（自动充值）可保证组织余额不断供：

• 启用时会立即处理一笔一次性扣款以验证支付方式；
• 余额低于$50.00时自动充值；
• 最低充值金额 $100.00；
• 充值失败的兜底机制：邮件通知并自动暂停自动充值，避免重复扣款，可在设置中随时恢复；
• 购买的积分永不过期，直到用完为止。

配置路径：Organization Settings → Billing & Credits → Automatic Top-Up → 打开开关并设置充值金额 → Save Changes。

Kilo Pass（组织级）：组织可将 Kilo Pass 订阅升级到组织级，把订阅的额度容量池化到团队共享，而不是每人持有个人 Kilo Pass。规则是：每席位一张 Pass（容量随付费席位自动增减）、额度进入组织池、有直接子组织时可将池化容量分配给各子组织（未分配部分留在父组织）。Owner 和计费管理员可在组织仪表盘的Subscriptions页面购买、分配或取消；取消在当前付费周期结束时生效。若削减席位导致分配超过剩余容量，订阅进入"过度分配"状态，Subscriptions 页面会引导你进行对账。

发票与服务中断：平台上的任何付款（席位或积分）都会在 Invoices 标签页生成发票。如果付款持续失败：有3 天宽限期解决付款问题，宽限期后服务暂停，暂停期间数据保留 30 天，付款问题解决后立即恢复服务。

Enterprise：面向大型组织的治理能力

子组织（Sub-organizations）：多业务单元的统一管理

子组织功能面向拥有父组织与直接子组织的 Enterprise 组织，用于在一个父组织下隔离团队、业务单元或成本中心。每个子组织拥有独立的成员、积分、用量与策略。层级只有一层：父组织可以拥有直接子组织，但子组织不能再包含子组织。

入口：登录 Kilo Web App → 打开父组织 → 导航中选择Sub-organizations，或从组织概览的 Sub-organizations 卡片进入。只有父组织的 Owner、Admin 与 Billing Manager 能打开统一管理区域；父组织普通成员和各子组织 Owner 无法借此查看其他子组织。Billing Manager 可以查看子组织并管理财务操作，但不能创建子组织。

创建子组织：Sub-organizations → Overview → Create sub-organization → 输入组织名称确认。新子组织从空开始：不会自动复制父组织的成员、模型策略或组织设置；父组织的 Owner/Admin/Billing Manager 获得继承的管理访问权，但不会成为新子组织的成员。

管理区域按职能分为七个板块：

People板块把属于多个子组织的同一人合并为一条记录，可搜索、按子组织/角色/成员状态/分配状态过滤，区分已接受成员与待定邀请，还能找出未分配到任何子组织的父组织成员。Models板块强调父组织与子组织的策略相互独立——修改父组织策略不会改变或约束子组织策略。Permissions板块用于识别没有独立 Owner 的子组织、审查生效的 SSO 策略，以及查看哪些父级用户拥有继承访问权（继承访问不创建成员资格，也不消耗子组织席位）。

推荐配置：每个子组织至少配置一名直接 Owner；命名时保持团队/业务单元/成本中心一致；定期在划转资金前审查用量与积分跑道；为每个组织有意配置模型与 SSO 策略（父级设置不会自动级联）；父组织用于共享监督，而非替代子组织直接成员资格。完整说明见 sub-organizations.md。

SSO：OIDC 与 SCIM 单点登录

SSO 文档 说明，Kilo Enterprise 支持通过组织已有的身份提供商（如 Okta、GitHub、Google Workspace、Azure AD）管理访问。当前不支持 IdP 发起的登录——用户必须访问 Kilo Web App 登录，不能从身份提供商的仪表盘直接跳转登录。

前置条件：Kilo 组织的 Admin 或 Owner 权限；身份提供商（IdP）的访问权。

配置分两个阶段：

1. 发起阶段：在组织仪表盘找到 SSO Configuration 面板，点击 "Set up SSO"，填写联系表单，Kilo 团队会联系你协助配置；
2. 实施阶段：Kilo 团队启用 SSO 后，指定的管理员会收到来自 WorkOS 的配置邮件，需要完成三步：
   • 在 WorkOS 中配置身份提供商：从 IdP 获取 Metadata 应用到 WorkOS；
   • 在身份提供商中配置 WorkOS：从 WorkOS 仪表盘复制服务提供商详情（Entity ID、ACS URL、Metadata）应用到 IdP；
   • 在 WorkOS 中配置策略与域设置：按需设置组织策略、用户配置（provisioning）、域策略与域验证。

重要警告：把域策略留到最后配置——如果在设置 SSO 之前就配置域策略，可能把用户锁在 Kilo 之外。启用 SSO 后，用公司邮箱域邀请新用户、在 Organization 标签页管理访问与角色、在 Audit Logs 标签页查看用户活动。

审计日志：可检索的组织事件记录

audit-logs.md 说明，审计日志记录 Kilo 席位管理中的关键动作，包括用户登录、模型/提供商/模式的增删、角色变更等。只有 Owner 可以查看和筛选日志，入口为 Enterprise Dashboard → Audit Logs。

筛选维度：

每条事件记录包含：Time（本地时区）、Action（事件类型，如user.login、settings.change）、Actor（执行者）、Details（附加上下文，如被增删的模型）。被记录的事件类别包括：组织创建/设置变更/购买积分、成员移除/角色变更、用户登录/登出/接受邀请/发送邀请/撤销邀请、自定义模式的创建/更新/删除，以及 SSO 的自动配置、设置域、移除域。

模型访问控制：基于黑名单的治理

model-access-controls.md 明确这是一项Enterprise 专属功能，采用黑名单（blocklist）模式：默认放行所有模型与提供商，管理员显式阻止不应被访问的项。这意味着新上线的模型与提供商会自动对团队可用，无需任何人工操作。

行为矩阵：

管理入口在组织的Providers & Models页面，含两个标签页：Models标签页可对每个模型开关访问权、按名称/ID/提供商搜索、筛选只显示当前允许的模型；Providers标签页可整体开关提供商（封锁其全部现有与未来模型）、按数据策略（是否用数据训练、是否保留提示词）与提供商位置/数据中心区域筛选。未保存的更改会显示底部状态栏，保存后立即对全体成员生效。

典型用例：数据合规（封锁用提示词训练或位于非要求数据区域的提供商）、成本控制（封锁高价模型防止意外大额消费）、安全策略（限制为已批准的提供商集合）。注意：只有 Owner 可修改；个人用户无法覆盖组织级限制；若需只对特定成员授权模型，可使用 Groups（组策略是组织级硬性上限之下的附加层）。

AI 采用度仪表盘：量化团队的 AI 成熟度

概览与评分构成

AI 采用度仪表盘 为工程管理者提供一个0–100 的 AI 采用度评分（AI Adoption Score），量化组织在真实开发工作流中应用 AI 的深度与一致性。它的目标读者是团队负责人、工程经理与高管：追踪组织 AI 整合进度、用单一基准数字横向比较团队、识别低/中/高采用团队、向利益相关方引用简明指标。

访问路径：登录 app.kilo.ai → 选择组织 → 点击仪表盘导航中的Usage标签页 → AI 采用度评分卡片出现在用量视图顶部。

评分由三个加权维度构成：

时间筛选支持过去一周 / 过去一月 / 过去一年 / 全部历史；"Only my usage"开关切换个人视角与组织视角；底部的四张指标卡显示总分、频率、深度、覆盖四个维度的周环比变化（如 "+2.3%" 或 "-1.5%"）。时间线采用堆叠柱状图，三种颜色分别代表评分维度：蓝色频率、绿色深度、橙色覆盖。点击任意维度卡片可查看该维度的详细分析与针对性改进建议。

评分如何计算

understanding-your-score.md 深入解释了评分机制。

Frequency（40%）——"开发者多久使用一次 AI？"衡量团队使用 AI 工具的规律性，按用户归一化并在组织内混合。测量的信号：每日 Agent 交互次数、自动补全接受量、Cloud Agent 会话数、Reviewer Agent 运行次数。高频率意味着 AI 已成为每日习惯，而非只在难题时求助。

Depth（40%）——"AI 在真实开发中整合多深？"捕捉信任与依赖程度。信号包括：每工作小时的查询数、AI 建议接受百分比、合并进代码库的 AI 生成代码行数、留存率（未修改直接合并的 AI 建议行占比）、多 Agent 链路（编码 → 评审 → 部署）。高深度表示开发者信任并愿意发布 AI 输出；低深度可能意味着上下文或质量存在问题。

Coverage（20%）——"AI 在团队中普及多广？"信号包括：每周使用任一 AI Agent 的用户占比、采用 2+ 个 Agent 的用户占比、采用 4+ 个 Agent 的用户占比、工作日使用广度（全周均匀分布 vs 集中在特定几天）。覆盖度能暴露采用缺口——可能存在少数重度用户拉高频率与深度，而其他成员几乎不用 AI。

归一化与平滑技术：

• 按开发者归一化：10 人团队的中度使用与 50 人团队的中度使用得分相当，原始总量不会虚增评分；
• 异常值封顶：限制重度用户的极端用量，防止单个热情开发者扭曲全队分数；
• 滚动窗口：采用每周滚动窗口保证稳定性，平滑日常波动又响应真实行为变化；
• 多源聚合：聚合来自 IDE（自动补全与编码 Agent 交互）、CLI（终端 AI 用量）、Reviewer Agent（AI 辅助代码评审）、Cloud Agent（浏览器端 AI 会话）四类事件流。

评分分五个层级：

分数波动需要区分正常波动（成员休假、迭代末/初差异、假期季节性）与有意义的变化（新成员入职可能暂时拉低覆盖度、成员离职、工作流或工具变更、成功的采用举措）。解读时关注趋势而非绝对值：先看是哪个维度拖了后腿——频率低则培养每日习惯，深度低则改善上下文质量，覆盖低则聚焦入职与激活；同时关注分布而非平均（50 分的团队可能是半数 80+、半数 20）。

提升你的评分：实战策略

improving-your-score.md 给出了按维度的行动清单。

提升 Frequency：

• 走出 IDE：安装 Kilo CLI 把 AI 带到终端工作流（npm install -g @kilocode/cli），IDE + CLI 双入口团队的每日参与度更高；
• 从自动补全开始：自动补全摩擦最低，鼓励团队在样板代码、重复模式、常见语法与测试脚手架中依赖它；
• 绑定现有习惯：站会准备（总结近期变更/生成状态更新）、上下文检查、PR 描述初稿、文档与行内注释——小而重复的用例积累得比偶尔的重型使用更快。

提升 Depth：

• 串联工作流：Plan（Architect 模式设计）→ Build（Code 模式实现）→ Review（Code Reviews 评审）的链路显著提升深度分数；
• 给 AI 更好的上下文：启用 Codebase Indexing 提供基于向量检索的仓库搜索，带来更相关的建议与更高的接受率；
• 在真实环境验证 AI 输出：使用 Kilo Deploy 为分支生成实时 URL，合并前验证变更。

提升 Coverage：

• 引入专业 Agent：Orchestrator（长周期项目子任务委派）、Architect（实现前设计与规划）、Debug（系统化排错）、Ask（快速问答与解释）；
• 激活闲置席位：检查组织仪表盘中的未激活席位，安排提醒、上手引导或结对；
• 让用量铺满整周：把 Code Reviews 纳入 PR 流程（评审贯穿全周，AI 用量自然铺开），或用每日站会准备、日终文档/提交信息、周中 Architect 模式设计评审。

推动采用的模式与反模式：有效的模式包括把 AI 与现有工具配对、从快速见效开始（自动补全与提交信息）、冠军主导的采用、每周 AI 用量检查、庆祝留存代码；应避免的反模式包括强制规定使用量、只关注重度用户、忽视上下文质量、只测量不行动、一刀切式采用。

按分数区间的快速行动建议：0–20 先确保全员可访问并登录、跑 30 分钟上手会、全员试用自动补全一周；21–50 找出最活跃用户并学习其做法、引入 Code Reviews、启用 Codebase Indexing、设定月度目标；51–75 引入串联工作流、聚焦深度（建议是否被接受与留存）、处理闲置席位、考虑 Kilo Deploy；76–90 保持势头、关注留存率、扩展到 CI/CD/文档/测试等边缘场景、向其他团队分享实践。

团队负责人使用指南

for-team-leads.md 面向工程管理者提供方法论。诊断信号方面：低覆盖度查"全员是否登录活跃？某些角色/小队是否缺席？用量是否集中（尖峰模式）？"；低深度查"接受率是否偏低？AI 代码是否被合并？是否在多阶段使用 AI？"；低频率查"成员是否知晓所有 AI 入口（IDE/CLI/Cloud）？是否只在低频难题时使用？"

开展采用举措时，以分数层级为里程碑设定合理目标（如 0–20 层级在 4–6 周内达到 30–40；21–50 层级在 4–6 周内达到 55–65），一次聚焦一个维度。向利益相关方汇报时，以趋势而非数字开头，解释层级含义，连接业务成果，并列出具体行动；文档中提供了可直接套用的示例汇报模板（含当前分数、上月分数、变化驱动因素、关键行动与下阶段目标）。

隐私与数据：仪表盘中的个人用量数据是匿名化的——管理者能看到聚合指标，但仪表盘不会向管理者暴露单个开发者的活动。它服务于团队级洞察、组织趋势与对比基准，不用于个人绩效评估、识别具体低绩效者或对开发者活动进行监视——用它识别采用缺口，而不是评判个人开发者。文档还预告了未来增强：从功能分支到主分支追踪 AI 贡献代码占比（多少 AI 建议代码真正上线、代码库中多少比例由 AI 辅助），以及多团队对比视图。

从零到一：团队落地清单

综合 index.md 的快速上手路径与本文各分册，团队落地的完整步骤为：

1. 安装 Kilo Code：在首选环境（VS Code / JetBrains IDE / CLI）中安装，参见 installing；
2. 连接 AI 提供商：在扩展主设置页选择并配置 API 提供商，参见 ai-providers；
3. 选择计划：根据团队规模与治理需求在 Teams（$15/用户/月）与 Enterprise 之间选择，参见 about-plans；
4. 创建组织并订阅：app.kilo.ai 上创建组织、选择席位与套餐、完成结账；
5. 邀请成员并分配角色：Owner / Admin / Member，确保席位充足；
6. 按需配置企业能力（Enterprise）：SSO、模型访问控制、审计日志、子组织与组策略；
7. 开始协作并持续改进：用会话共享与 Fork 开展协作，借助 AI 采用度仪表盘监控、设定目标并迭代优化。

进一步阅读

• Sessions & Sharing —— 会话共享与 Fork 完整说明
• About Plans —— 计划对比与定价明细
• Getting Started with Teams —— 10 分钟团队搭建指南
• Team Management —— 成员与角色管理
• Dashboard —— 仪表盘各标签页详解
• Analytics —— 用量分析的指标与视图
• Billing —— 计费、积分、自动充值与 Kilo Pass
• Custom Modes (Org) —— 组织级自定义模式
• Sub-organizations —— 企业子组织管理
• SSO —— 单点登录配置
• Audit Logs —— 审计日志事件清单
• Model Access Controls —— 模型/提供商访问控制
• Adoption Dashboard 系列 —— 采用度评分的概览、计算原理、提升策略与团队负责人指南
• Session History and Search —— 本地会话数据库定位与检索

相关的 CLI 会话参数实现可参考 packages/opencode/src/cli/cmd/run.ts（--fork/--cloud-fork/--share/--continue/--session）与 packages/opencode/src/kilocode/cloud-session.ts（云会话导入与参数校验）。

【免费下载链接】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