finding-duplicate-functions

finding-duplicate-functions 技能概览

finding-duplicate-functions 技能可以帮你找出“做同一件事、但名字或实现看起来不同”的函数。它最适合用于审查 LLM 生成代码，或快速扩张的代码库——这类项目里，语义重复往往比纯拷贝重复更快累积。如果你是在找 finding-duplicate-functions for Code Review，这项技能面向的是合并取舍，而不是挑样式问题。

这个 finding-duplicate-functions 技能是做什么的

这个 finding-duplicate-functions 技能专门用于识别“意图相同、代码不同”的情况：彼此重叠的 helper、被重新造出来的 utility，或者分散在多个文件里的近似逻辑。它尤其适合重构前、清理代码时，或者在像 jscpd 这类语法层面的重复检测工具已经处理完完全相同的拷贝之后继续使用。

适合谁安装

如果你在审查 JavaScript 或 TypeScript 仓库，而且里面有大量小工具、生成文件，或者多名贡献者，那么就很适合安装 finding-duplicate-functions 技能。它尤其适合你需要一种可重复的方法，来判断函数应不应该合并、继续拆分，还是需要进一步调查。

它的不同之处

它最关键的差异在于两阶段工作流：先抽取函数，再用 LLM 分析按意图聚类。也就是说，这项技能的目标是减少你对语义重复的猜测，而不只是找出相同行。实际收益是，你可以更快地从“这段代码感觉有冗余”走到一份可审查的合并方案。

如何使用 finding-duplicate-functions 技能

安装并找到工作流

使用技能目录里的仓库安装路径：npx skills add obra/superpowers-lab --skill finding-duplicate-functions。安装完成后，先从 skills/finding-duplicate-functions/SKILL.md 开始，再阅读 skills/finding-duplicate-functions/scripts/ 里的辅助脚本，因为真正的分析顺序是由这些脚本定义的。对于 finding-duplicate-functions 指南来说，这些脚本比概述性文字更重要。

这个技能需要什么输入

这项技能在你提供源码目录和明确的审查目标时效果最好。高质量输入会说明代码范围、分析原因，以及要排除什么内容。比如：“在合并 auth flows 之前，扫描 packages/api/src 里的重复校验 helper；忽略测试文件，只报告高置信度候选项。”这比单说“找重复”要好，因为它给出了范围、意图和输出预期。

先读这些文件

优先查看 scripts/extract-functions.sh、scripts/categorize-prompt.md、scripts/find-duplicates-prompt.md、scripts/prepare-category-analysis.sh 和 scripts/generate-report.sh。这些文件展示了 finding-duplicate-functions 的完整使用方式：先抽取目录、再给函数分类、按类别拆分、执行语义比较，最后生成报告。如果你只打算快速扫一眼，那就至少读 SKILL.md 和 scripts/extract-functions.sh，这样能先弄清输入格式和排除规则。

会影响结果的工作流技巧

把分类步骤当作过滤器，而不是事后补救。分类越一致、可比较的函数数量越充足，技能的准确度通常越高，因为重复检测是按类别逐组运行的。默认排除测试文件，通常适合生产代码清理；但如果你的审查目标是共享测试工具或 fixture helper，就应该把测试也纳入。生成的报告更适合作为人工复核的候选清单，而不是自动重构方案。

finding-duplicate-functions 技能常见问题

它比普通提示词更好吗？

当你想要的是一套可复现的 duplicate-function 意图识别流程，而不是一次性的头脑风暴答案时，答案是肯定的。普通提示词可能忽略范围控制、文件选择和置信度阈值。finding-duplicate-functions 技能提供了更容易在 code review 中重复使用的工作流和输出结构。

它能替代语法层面的重复检测工具吗？

不能，它是互补关系。语法工具负责找出被复制的代码；这项技能负责找出实现不同、但语义相似的函数。如果你的代码库里已经存在完全相同的拷贝问题，应该先处理那些问题，这样语义分析才能保持聚焦。

它适合新手吗？

如果你能把它指向一个源码树，并说明要审查什么内容，那它对新手也很友好。新手最需要理解的是，重复检测是按类别进行的，而且很依赖清晰的输入边界。如果你不确定，从一个 package 或一个功能区开始，不要一上来就扫整个仓库。

什么时候不该用它？

当你需要的是广泛的架构建议、一次性的 bug 修复，或者对整个代码库做总体概览时，不要用它。如果你的仓库主要不是 JS/TS 代码，它也不太合适，因为抽取脚本是围绕 JavaScript 和 TypeScript 的函数模式设计的。如果你的目标只是找完全一样的拷贝，一个更简单的复制粘贴检测器就够了。

如何改进 finding-duplicate-functions 技能

缩小范围，明确决策目标

提升效果最大的办法，是缩小审查面，并明确你希望它给出什么动作。不要只问“有哪些重复”，而是问“src/utils 里适合合并的候选点，且偏向高置信度合并”。这样能改善 finding-duplicate-functions 的使用效果，因为模型可以比较那些本来就应该互相竞争的函数。

提供合适的对照样本

如果你已经怀疑某些函数成对重复，就把它们写进提示词里，并说明它们可能哪里不同。比如：“比较 parseUserInput、normalizeInput 和 sanitizeInput；它们可能有重叠，但其中一个处理 HTML escaping。”这样能帮助技能区分真正的重复，和只是共享了词汇的相邻 helper。

注意常见失败模式

最常见的失败模式是过度归组：名字相似、但业务规则不同的函数被合并得过于激进。第二种是归组不足：很小的 wrapper 因为参数形状或命名不同，就被当成完全不同的函数。无论哪种情况，都要补充输入、输出和预期行为的上下文，这样审查才能判断意图，而不是只看表面相似度。

从报告回到重构，再继续迭代

第一次运行后，先用报告挑一个类别，把置信度最高的分组和源码逐个人工核对。如果某个分组处在边界上，就收紧分类，或者补充更好的上下文行，再提高推荐阈值后重跑。最好的 finding-duplicate-functions 指南一定是迭代式的：先用初始输出缩小范围，再对代码库的下一部分继续运行。