AI 生成的”重复代码”哪些该删、哪些该留？Kevin Moore 的四阶段重构协议

AI 生成的代码里，有多少”重复”其实是合理的？

这个问题，搞 Flutter/Dart 的朋友应该感触很深。你让 Cursor 写一段 UI 代码，它给你生成三段长得几乎一模一样的 build() 方法——你看了想删，但删了又怕改坏。这类重复到底是真的需要合并的坏味道，还是语言/框架本身强制的结构相似？

Kevin Moore（Google Flutter/Dart 产品经理）最近开源了一个 Skill，就专门解决这件事。

它叫 deslop-duplication-audit

这个 Skill 来自他维护的 kevmoo/kevmoo_skills 仓库，核心逻辑是一个四阶段协议：

Phase 1（只读扫描）
运行 Deslop CLI 工具，对比当前分支和 main 的 diff，加入 --only-changed 参数，只报告当前 PR 真正引入的重复，而不是把整个五年老代码库里积累的”历史问题”全翻出来。

Phase 2（强制确认门）
AI 扫描完停下来，给用户展示结果，然后禁止直接动手。必须等用户决定要不要处理、在哪里处理（当前分支 / 新分支 / 独立 worktree）。

Phase 3（架构裁定） ← 这步最关键

很多工具默认”发现重复 = 必须合并”，Kevin 的 Skill 则直接列出了应该拒绝合并的几种情况：

• 类型不安全的 polymorphic targets，合并意味着引入 dynamic 或类型转换
• 性能关键的热循环，合并反而会在 tight loop 里引入闭包分配
• bin/*.dart 入口文件里的 try/catch 包装，抽象掉的代价是失去可读性

说白了：工具负责找证据，人负责做判断，AI 不能把相似度分数当作战命令。

Phase 4（测试验证）
动手前先跑一遍测试套件，确保基线本身没坏；改完再跑一次dart analyze –fatal-infos，确认没有引入新问题。

怎么用

# 安装 Skill
npx skills add kevmoo/kevmoo_skills --skill deslop-duplication-audit

# 在 Claude Code 里触发
/deslop-duplication-audit

也可以指定只扫描当前 PR 改动的部分：

dart run skills/deslop-duplication-audit/bin/deslop_report.dart 
  --dir {repo_dir} 
  --diff-cmd "git diff main...HEAD" 
  --only-changed

为什么这个思路值得学

Code review 里最难的不是发现问题，是判断”这个问题值不值得解决”。大多数工具只做前半段——扫描、报告、一键修复。Kevin 的 Skill 把后半段也补上了：强制用户参与决策，防止 AI 无脑合并把代码改得更乱。

它本质上是一个AI + Human 协作的质量门禁，适用于任何在意代码长期可维护性的团队。

GitHub 仓库：github.com/kevmoo/kevmoo_skills（包含 14 个 Skill，覆盖 Gerrit CL 流程、PR 分类、worktree 管理等多个场景）

GitHub: https://github.com/kevmoo/kevmoo_skills