迈向 100% 准确率：透明的重复代码检测
“100% 准确率”是目标。它不是当前得分，本文也不是一篇胜利宣言。
对 Deslop 而言，标准包含两部分：
每一个报告的集群都是真正的重复；每一处真正的重复都被报告。
第一部分是精确率：没有误报。第二部分是召回率：没有漏报。一个只优化其中一项的重复代码检测工具，可能看起来很出色，却仍然辜负用户。几乎不报告任何内容，精确率看上去就很安全；把每一段略微相似的代码都报告出来，召回范围看上去就很广。两种结果都没有用。
诚实地迈向 100%，就要公开还有多远。
为什么公开问题关系图？
这是 2026 年 8 月 21 日 Deslop 公开问题关系图的快照。截图时，图中有 103 个开放问题，分布在八个工作流中。其中 33 个属于 Accuracy，是最大的分组。截图时的数据还记录了 22 个准确性关键问题、三个发布阻断问题、16 个等待发布验证的修复、82 个相互连接的问题，以及 122 条明确关系。实时问题数据会从 GitHub 重新生成，因此现在可能已经显示更新的数字。
这些数字不是路线图表演。它们就是尚未完成的工作。
每个节点都是一个 GitHub 问题。颜色表示工作流；节点越大，指向它的链接越多。有方向的连线表示阻断关系与父子问题关系；较浅的连线表示交叉引用。选中节点后，关系图会显示优先级、标签、负责人、相对工作量、关联问题，以及完整公开工单的链接。
绿色圆环最重要。它表示已在 main 修复，等待验证，并不表示完成。只有变更在真实版本中得到验证后，问题才会关闭。这个区别避免把“补丁已合并”误当成“结果已观察”。
关系图之所以存在，是因为扁平的问题列表会隐藏系统关系。语义匹配中的一个漏报，可能依赖嵌入修复、语料断言、报告架构工作和发布验证。关闭其中一个工单不会让整条依赖链消失。关系图会把它显示出来。
代码质量需要一份公开的失败账本
列表很短时，彻底透明并不困难；列表令人不适时，它才真正有用。隐藏的重复代码技术债务依然是债务，公开的失败账本让它可以被检查。
Deslop 把已知误报、漏报、误导性指标、被跳过的测试、性能限制和文档漂移，与功能开发放在同一个公开位置。问题规划器用优先级泳道、推荐队列、统计信息和指示性跑道展示同一份源数据。其中的工作量单位只表达相对顺序，不代表日期、截止时间或承诺。
这些视图刻意回答不同问题：
- 问题关系图回答：哪些工作相互关联，什么阻断了什么？
- 优先级面板回答：哪一类工作先做？
- 队列回答：此刻推荐的顺序是什么？
- 统计视图回答：有多少开放工作和验证工作可见？
- 跑道回答：工作流之间可能如何排列，而不把不确定性伪装成日历？
底层方法同样公开。报告由 GitHub 元数据、明确关系、交叉引用和有文档记录的关键词规则生成，不使用 AI 扩充。你可以检查开放的 GitHub 问题、生成后的 JSON以及生成器源码。
准确率不等于重复率
误导读者最简单的方式之一，就是给两个不同概念贴上同一个标签。
Deslop 的仓库重复率，是对单份报告中可见发现执行的精确算术：被报告重复行的并集除以已分析行数。它不是检测器准确率的统计估计，也不能证明完美的精确率或召回率。准确率透明度公开了完整公式、排除规则、舍入行为和 CI 阈值语义。
这一区分会产生实际后果。如果一个误报通过了检测器，百分比的计算仍然可以完全精确，却错误地描述代码库。如果一处真正的重复被漏掉，算术仍然可以完全精确，但分子并不完整。透明的数学计算是必要条件；经过验证的检测才是更难的问题。
这个目标如何连接代码克隆检测研究
准确率推进并非从零开始。Deslop 组合了多条既有的代码克隆检测研究路线，每一条都面向精确率与召回率问题的不同部分。
- Type-1 克隆是只改变排版或注释的复制代码。
- Type-2 克隆保留结构，但重命名标识符或改变字面量。
- Type-3 克隆插入、删除或修改语句。
- Type-4 克隆用不同语法或结构表达相似行为。
Baxter 等人的 AST 研究说明了为什么解析后的程序结构可以找到行比较会漏掉的精确和近似克隆。Deslop 沿着这一基础使用 tree-sitter 语法树、标识符与字面量归一化，以及自底向上的 Merkle 指纹。
SourcererCC建立了一条可扩展的、基于词元的近似克隆检测路径。Deslop 将这个方向应用于归一化 AST 节点类型序列，再用 MinHash 局部敏感哈希寻找 Type-3 候选，避免把每棵子树与所有其他子树逐一比较。
对语义相似性而言，SSCD提供了 BERT 加最近邻搜索的相关先例。Deslop 的可选嵌入层使用 HNSW 索引，把召回范围扩展到 Type-4 克隆。结构、词元和嵌入证据由同一引擎融合、聚类、排名并渲染。实现映射和主要研究来源汇总在研究背景中。
每增加一层，都可能找回真实重复，也可能引入看似合理的错误。归一化可能抹去有意义的差异；阈值可能隐藏真实的近似克隆；嵌入可能把两个无关函数放得很近；传递聚类可能连接本应分开的发现；排名可能把正确集群埋得太深，效果等同于没有发现。
研究提供方法，但不会因为被引用就自动赋予工具准确性。
Deslop 如何衡量迈向 100% 的进展
准确性工作必须把样例变成断言。
Deslop 的夹具测试固定预期的集群、出现次数、文件路径、证据分桶和排名顺序。真实仓库语料门禁则针对固定到具体提交的公开仓库，加入人工整理的基准事实：
- 经过验证的重复被漏掉时，
must_find条目失败。 must_find_type2条目检查重命名克隆及其可见证据。- 经过验证的非重复被错误聚为一组时，
must_not_cluster条目失败。 - 已知失败继续绑定开放问题，而不是被悄悄重新设为基线。
每一个得到确认的误报或漏报，都应当成为回归用例。失败的断言是证据。没有有意义判定依据的绿色测试，只是一层绿色油漆。
这也是 AI 编码智能体与准确率目标相关的原因。智能体可以在审查者建立仓库级记忆之前就添加另一份实现。Deslop 的实时 LSP 服务器维持工作区报告的新鲜度；MCP 服务器则让智能体在添加另一份实现之前调用 find-similar。只有答案可信，预防才有价值，因此编辑器、CLI、MCP 工具、报告和指标都必须遵守同一套精确率与召回率标准。
“迈向”意味着什么
基于 AST 的克隆检测研究指出，一般情况下无法判定任意程序片段之间的语义等价性。因此，“迈向 100%”表达的是方向和运行规则，而不是普适性证明：
- 公开目标，但不声称已经实现。
- 公开已知反例。
- 把每一个反例转化为持久测试。
- 修复在通过发布验证之前保持开放。
- 公开计算、证据、依赖关系和剩余工作。
问题关系图是这套规则的可见账本。研究背景解释检测方法从何而来。准确率文档解释报告数字代表什么，以及不代表什么。
如果 Deslop 有一天有资格针对一个边界明确的基准说出“100%”，证据会是公开的。在那之前，差距也同样公开。