component-refactoring

component-refactoring 技能概览

component-refactoring 是做什么的

component-refactoring 技能可以帮助你重构 Dify 前端里高复杂度的 React 组件，而不用靠猜测从哪里下手。它适用于组件已经过大、嵌套太深，或者难以干净地测试的场景；这时你需要的是一个结构化方案，用来拆分 UI、抽离 hooks，或者降低认知复杂度。

什么时候最适合用

当 pnpm analyze-component --json 报告复杂度超过 50、代码行数超过 300，或者分析器明确建议先重构再测试时，component-refactoring 技能就很合适。它也适用于任务本身就是代码拆分、hook 抽离，或简化那些已经堆了太多条件分支的组件。

它为什么有用

这个技能比通用的重构提示词更偏向“决策”。它会给你一套和 Dify 组件分析工具绑定的工作流，再配上诸如按区域拆分、抽离 hook 之类的具体降复杂度模式。之所以重要，是因为大型 React 文件最常见的失败点不是语法，而是在降低耦合的同时还能保住行为不变。

如何使用 component-refactoring 技能

安装并指向正确的仓库

使用 npx skills add Charlie85270/Dorothy --skill component-refactoring 安装 component-refactoring 技能。这个工作流默认你在 Dify frontend 的目录结构下操作，所以请从 web/ 目录运行命令，并使用相对于该目录的路径，例如 app/components/...。

先做分析，不要直接重写

一个更稳妥的 component-refactoring usage 流程是：先分析组件，检查生成的 prompt，再只重构那些真正推动复杂度上升的部分。用 pnpm analyze-component <path> --json 确认分数和行数；当你需要机器可读的重构简报时，再用 pnpm refactor-component <path> --json。如果文件没有超过阈值，这个技能可能并不需要。

先读这些文件

如果你想让 component-refactoring guide 真正有实操价值，先读 SKILL.md，再看解释 prompt 背后模式的参考文档：references/complexity-patterns.md、references/component-splitting.md 和 references/hook-extraction.md。这些文件会告诉你，这个技能把什么算作复杂度，以及哪些改动真的能把复杂度降下来。

把粗略目标改成更好的 prompt

这个技能在你的输入明确写出目标组件、目标结果和约束条件时，效果最好。比如，不要只说“重构这个组件”，而要说：“重构 app/components/foo/index.tsx，把认知复杂度降到 50 以下。优先通过抽离 hooks 处理 state/effects，并拆分 modal 区块，但不要改行为或 public props。” 这种具体程度能明显提升输出质量，因为它告诉技能哪些必须保留，哪些才是优化重点。

component-refactoring 技能 FAQ

component-refactoring 只适用于 Dify 吗？

是的，component-refactoring for Refactoring 工作流是围绕 Dify frontend 的约定、命令名和组件路径设计的。你当然可以把这些思路迁移到别处，但如果你在这个代码库，或者一个非常相似的 React monorepo 里工作，那么它的安装和使用指导才最有价值。

可以直接拿它替代普通 prompt 吗？

可以，但当你需要和可测量复杂度绑定、并且可重复执行的重构指导时，它会比通用 prompt 更强。普通 prompt 可能只会给出泛泛的清理建议；而 component-refactoring 更适合在你需要下一步动作既有证据支撑、又受分析器输出约束时使用。

使用它需要很高级吗？

不需要。只要你能找到目标文件并运行分析命令，这个技能就适合初学者。关键是你要能提供具体的组件路径，并说明当前优先级是拆分、抽离 hook，还是降低复杂度。

什么情况下不该用它？

不要把 component-refactoring 技能用在简单组件、第三方包装器，或者你只想加测试却不打算改结构的场景里。如果组件本来就清晰，而且低于阈值，硬做重构反而可能引入不必要的变动。

如何改进 component-refactoring 技能

提供更好的输入指标

提升 component-refactoring usage 最快的方法，就是在请求里带上分析器输出：complexity score、maxComplexity、lineCount，以及任何 warning 文本。这些信息能帮助技能直接抓住真实压力点，而不是把所有大文件一视同仁。

明确你想要的重构风格

如果你希望得到某种特定结果，就一开始说清楚。比如：“先拆 UI sections”、“抽一个 custom hook 处理共享 state/effects”，或者“减少 main return 里的条件渲染”。这比笼统的“弄得更干净一点”更有效，因为技能可以据此把你的目标映射到参考文档里的正确模式。

注意常见失败模式

最常见的错误是过度拆分、只是搬移逻辑却没有真正简化，以及为了降低复杂度而改坏行为。更好的输入能降低这些风险：明确哪些 props、side effects 和 modal 流程必须保持稳定，并要求尽量少改外部 API。

在第一次结果后继续迭代

第一次重构完成后，再跑一遍 pnpm analyze-component <path> --json，把分数和目标对比。如果复杂度还是偏高，就让技能集中处理剩下那个分支特别多的块，或者只针对某一个 hook 候选继续优化，而不是把整个文件重新来一遍。