范围：Kilo CLI (
packages/opencode/) / VS Code Extension (packages/kilo-vscode/) / Kilo Cloud (后端归因引擎)
执行摘要
本方案解决的核心问题是：精确量化 AI 在最终代码库中的实际贡献比例。现有方案（包括行业通用的"行数计数法"）只能回答"AI 被接受了多少行"，但无法回答"这些被接受的代码有多少存活到了最终提交，以及被人类修改了多少"。
本方案在 Kilo Code 现有架构上，引入 AST-aware MinHash 指纹归因引擎（基于 k-Shingle + LSH），构建一条从 AI 代码生成瞬间到 Git 最终提交的全链路追踪能力。三套代码生成路径（Tab 补全、Chat 对话、Agent 子任务）统一采集代码指纹，服务端在 Git 提交阶段进行归因匹配，最终产出精确到行级的 AI 贡献占比。
这是一个非常实际的工业需求。MinHash 在这个场景中不是直接检测"是否 AI 生成"，而是作为代码指纹匹配引擎，追踪"AI 原始输出 → 人修改后最终代码"的相似度与存活比例。
下面给出完整的AI 生成代码占比统计系统设计方案。
一、问题定义：什么是"AI 生成代码占比"
在智能体编码助手（GitHub Copilot、Kilo Code、Cursor 等）的工作流中，代码的生命周期通常是：
AI 生成建议 → 人接受/修改 → 进入代码库 → 后续迭代中被修改
我们需要统计的是最终代码库中，可追溯至 AI 原始生成的代码比例。这不是简单的"谁按了 Tab 键"，而是：
| 统计维度 | 含义 | 计算方式 |
|---|---|---|
| AI 原始贡献率 | AI 生成的代码在最终代码中的存活比例 | 匹配上的代码行 / 总行数 |
| 人修改深度 | 人在 AI 代码基础上做了多大改动 | 1 - (AI 原始代码保留率) |
| 人效提升系数 | 有 AI 辅助时人均产出 vs 无 AI 辅助 | 对比实验或历史基线 |
二、为什么 MinHash 适合这个场景
核心挑战
MinHash 的优势
| 数据集 | 尺寸 (Tokens) |
|---|---|
| RefinedWeb | 500B |
| C4 | 172B |
| Dolma | 3T |
| The Pile | 340B |
| SlimPajama | 627B |
| RedPajama2 | 20T |
| FineWeb | 15T |
结合 TF/IDF 或者 BM25 算法改进代码检索的效果，提高代码检索的准确性。 采用 Jaccard 相似度算法，提高代码相似性检测的效果。 使用 TreeSitter 或者 AST 技术，进行语法分析，以构建更好的交互体验。