Advanced
1 hour
How to 重构你的代码库 with Eigent
在不改变行为的前提下，移除死代码并现代化遗留模式——以小而可审查的分步方式进行。
What you need
- Eigent 桌面应用
- 代码库访问权限（本地或已连接的仓库）
- 测试套件或 CI 流水线
Best for
- 存在死代码、过大模块或陈旧抽象，导致日常修改成本很高的代码库
- 需要在原地现代化代码，但不想把工作变成一次架构迁移的团队
- 为新功能开发或团队入职做代码库准备的工程师
Starter Prompt
现代化并重构这个代码库。 要求： - 除非我明确要求功能变更，否则保持行为不变。 - 先识别拖慢修改速度的死代码、重复路径、过大模块、陈旧抽象和遗留模式。 - 对于每个建议的分步改动，说明当前行为、结构性改进，以及应当证明行为保持稳定的验证检查。 - 将工作拆分为可审查的小型重构步骤，例如删除死代码、简化控制流、抽取辅助函数，或用仓库当前约定替换过时模式。 - 除非重构本身需要变更，否则保持对外 API 稳定。 - 标出任何框架迁移、依赖升级、API 变更或架构调整，这些内容应拆分为单独的迁移任务。 提出一个完成此工作的计划。
工作原理
- 先让 Eigent 在编辑前梳理该区域——找出杂乱模块、重复逻辑、未使用代码和陈旧模式。
- 一次只选择一个清理主题——删除未使用代码、简化控制流、现代化过时模式，或拆分大文件。
- 在 Eigent 修改文件之前，让它说明当前行为、结构性改进，以及能证明行为保持稳定的最小检查。
- 每完成一轮后，先审查并运行最小且有用的检查，而不是把整个清理工作一次性合并成一个 diff。
- 除非完成清理所必需，否则将技术栈变更、依赖迁移和架构调整保持为独立任务。
尝试更多提示词
- 这个区域里哪些文件存在最多的死代码或未使用导出？
- 找出所有重复同一逻辑的地方，并提出一个统一的汇总点。
- 这个模块中的哪些遗留模式与仓库当前约定不一致？
- 在不改变其对外 API 的前提下，把这个过大的文件拆分成更小、职责更明确的部分。
如何使用
先让 Eigent 梳理这个混乱区域——它会在接触任何代码之前识别出最高价值的清理机会。一次只处理一个主题，并在继续之前审查每个 diff。每完成一轮后，使用你的测试套件或 CI 作为验证检查。如果 Eigent 提议进行技术栈迁移或依赖变更，请将其标记为单独任务，并让当前重构只聚焦于结构。
预期输出
一份按优先级排序的清理计划、一系列小而聚焦的 diff（每轮一个），以及每轮的验证摘要，说明修改了什么，以及哪个检查确认行为是稳定的。
局限性
- 当该区域已有测试套件或清晰的行为契约可供验证时，效果最佳。
- 大型单体仓库更适合一次聚焦一个服务或模块。
- 架构变更、运行时升级和框架迁移应作为独立任务——将它们与重构混在一起会让 diff 难以审查。
