ditto

Ditto 将其定位为“语义 CI”：在编译、测试和 lint 之外增加了一个流水线问题——这个代码库是否在重新发明它已经知道的东西？它针对的是 Type-4 克隆，即行为相同但编写方式不同的函数，而基于 token 和 AST 的重复检测器通常无法报告此类情况。 文档中描述的流水线工作原理如下：后端下载仓库 tar 包，使用 ts-morph 遍历并提取每个函数（包括非导出函数），然后使用廉价模型以名称盲方式逐一为每个函数创建指纹。这些指纹（而非原始代码或名称）在内存中通过余弦相似度进行嵌入和聚类。只有生成的候选聚类才会提交给更大的模型进行裁决，该模型还会提出对抗性输入。功能纯函数随后在带有超时机制的 worker_threads 沙箱中并行执行，确认的差异将作为执行证据呈现；非纯函数虽然也会被聚类和裁决，但被标记为“预测”而非“执行”。结果写入 MongoDB，并通过只读端点和 Next.js 前端提供服务；服务路径不调用任何模型。 README 报告了在五个仓库（分别包含 2,870、2,654、336、31 和 6 个函数）中的运行情况，列出了重复聚类、行为冲突以及 18 个经执行证明的案例，其中包括 cline 中一组 truncateText 实现，其中一个预留空间计算在超过一定限制后会将保留文本缩减为一个字符。报告指出，jscpd 在这些文件中报告的克隆数为零。两个小型且维护良好的库被评为“干净”，作者将其作为防止过度报告的证据。 所述限制：仅支持 JavaScript/TypeScript，因为 AST 层使用 ts-morph；执行需要函数纯净；大型仓库必须明确指定范围而非简单截断，因为静默丢弃的函数可能会导致整个聚类消失；且该工具不建议在两个冲突的实现中保留哪一个，将其定义为人工决策。README 中的成本和时间数据（例如分析 2,870 个函数花费 ₹232，计划中的 Guard 检查每个 pull request 约 ₹1）是项目自身的测量结果，而非独立基准测试。托管演示版将按需分析上限设为 600 个函数，这被描述为维护者 API 额度的限制；使用自己的密钥在本地运行可取消此上限。 安装说明涵盖了在没有 MongoDB 或 API 密钥的情况下索引仓库、包含 MongoDB、OpenAI 及可选 GitHub/模型设置的 .env 文件、请求超时时间为 1200 秒的 Cloud Run 部署、Atlas 网络访问，以及使用 Vercel 部署前端（NEXT_PUBLIC_* 值在构建时内联）。路线图列出了作为 GitHub Action pull-request 检查的 Ditto Guard、允许编码代理在编写重复代码前查询索引的 MCP 工具、通过 tree-sitter 支持更多语言以及增量重新索引。贡献者可参考标记为 good first issues 的问题。