关于 large-file-refactor
large-file-refactor 是用于扫描大型源文件并评估拆分价值的开发技能,面向维护代码库的开发者。它先按行数发现候选项,再依据职责内聚、耦合、变更风险和可测试性制定计划,而非仅为缩短文件而拆分。
主要功能
- 01扫描超过阈值的源文件与测试文件
- 02输出完整候选文件报告
- 03按职责和风险评估拆分价值
- 04为重点文件制定迁移与验证计划
- 05支持纳入生成及供应商文件
适用场景
- 01盘点代码库中的大型文件
- 02评估是否应拆分复杂模块
- 03规划可审查的重构步骤与测试
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ paulrberg/ agent-skills --skill large-file-refactor安装后在 Claude Code 中输入/large-file-refactor确认已加载。
附带文件agents/openai.yamlscripts/large-file-refactor.py
详细介绍
大文件重构
此技能无需协调:对于其声明的工作,跳过 ai-coord 门禁。
如果斜杠或美元符号调用已将这些指令加入对话,请直接遵循这些指令。在这种情况下,不要再通过技能工具调用此技能。
使用 LOC 阈值发现候选文件,然后根据内聚性、耦合度、所有权和变更风险判断是否值得拆分。源文件的发现阈值为 1000 LOC 以上。测试文件使用较宽松的 2000 LOC 发现阈值。
参数
path:要扫描的可选文件或目录。默认值:当前工作目录。--include-generated:包含默认跳过的生成文件、供应商文件、依赖项和构建输出路径。
工作流
-
确定技能目录,然后从目标仓库运行辅助脚本:
uv run "<skill-dir>/scripts/large-file-refactor.py" [path] [--include-generated] -
将辅助脚本输出的 Markdown 表格作为完整报告保留。即使重构计划只涉及其中一部分,也不得省略符合条件的行。
-
如果辅助脚本未报告任何达到阈值的文件,则在报告后停止。匹配到的文件只是候选,并不代表一定应该拆分。
-
仅为最大的 3 个文件起草重构计划,除非用户明确要求其他数量。
-
对每个候选文件,根据职责混杂程度、变更频率/风险、耦合度和可测试性评估拆分价值。使用可用的语义符号/引用工具。如果已安装 Serena,请优先使用:
- 检查符号概览、引用、导入和相关历史记录。
- 使用这些证据选择提取边界、目标模块名称、迁移顺序和测试覆盖范围。
-
此工作流默认只生成报告和计划。仅当用户的请求已授权执行,或用户随后批准时才实施。对于结果不变且已获授权的工作,无需再要求单独请求。
重构计划格式
对每个选定文件,包含以下内容:
- 当前职责:说明该文件表面上的职责,以及为什么行数多只是症状。
- 语义分析:说明移动代码前要进行的确切符号/引用/历史检查。
- 拆分提议:列出 2-5 个目标模块或文件及其职责。
- 迁移顺序:列出小步、便于审查且能保持公开行为不变的步骤。
- 验证:列出用于证明拆分有效的针对性测试、类型检查、构建或冒烟检查。
每个计划都以一条明确结论开头:### ✂ Split justified、### 🧱 Keep intact 或
### ⚠️ Generated — change the generator。对于重复评估的标准,使用紧凑的证据表。提出拆分方案时,仅在有助于说明所有权的情况下,才以树状结构展示源模块和目标模块。
如果选定文件是因使用了 --include-generated 而被纳入的生成文件或供应商文件,则应针对生成器、架构或上游源文件制定计划,而不是手动拆分生成的输出。
防护规则
- 仅将表格作为文件大小排序的依据。应单独对重构优先级进行排序。
- 保持计划内聚。不要仅为减少行数而拆分。
- 优先遵循项目现有的模块边界和命名约定。
- 如果辅助脚本使用了可移植 LOC 估算而非
tokei,请在报告中说明。
完成
最后提供完整的阈值报告,以及仅针对内聚性或变更风险足以证明拆分合理的候选文件所制定、按证据排序的计划。以 ### 🔎 Large-file scan — <candidate count> 开头,说明大型文件何时应保持完整及其原因;如果使用了可移植 LOC 回退方案,则以 ⚠️ Approximate counts 明确指出。辅助脚本的完整表格、路径、LOC 数值和命令必须保持原样,不得添加修饰。