为什么编码智能体需要快速的重复代码反馈

编码智能体可以产出看似合理的实现，却不知道仓库中已有相似代码。在日常功能开发中反复出现这种情况，就会留下多份今后需要同步修复的实现。

问题在于仓库上下文，而不是意图。即使项目中已有同类实现，模型仍可能生成另一个仓储类、校验器或映射器，只是名称不同。

为什么反馈时机很重要

代码及其上下文仍在当前工作范围内时，修改重复代码的成本更低。等到 CI 或代码审查才发现，就多了一次交接，才能决定是抽取、复用还是接受。

Deslop 将分析留在编辑闭环中。LSP 监视工作区并增量更新报告；MCP 服务器则通过 find-similar 与报告查询，把这份运行中的分析提供给编码智能体。

Deslop 报告中的一个簇是一个决策，而非一纸定论。工具负责报告；你来决定。大体上有三条路径：

提取。 这些片段足够一致，且共享了足够多的调用图，以至于一个共享函数就是显而易见的答案。JSON 中的 action_hints 会标记出这些。
复用。 其中一个片段是"真正的"实现，其余的应当调用它。挑出测试最好的那个，删掉其余的。
接受。 有些重复是有意为之的——测试夹具、引导初始化，以及两个今天看起来相似但日后会分道扬镳的东西。加上标注，继续前进。Deslop 不作评判；它只是记分。