如何利用LLM在Cursor中进行大规模代码重构
在这篇文章中，我将介绍我使用LLM编程助手进行代码重构的方法。代码重构一直以来都是一项繁琐但重要的工作。重构是指对某段代码进行清理，无论是通过更好的关注点分离、遵循“不要重复自己”原则，还是其他代码卫生原则。
代码重构一直都很重要，但随着编程助手的发布，我们看到了更高的代码产出，这不可避免地导致了对代码重构的更多需求。我越来越频繁地发现自己处于需要重构某些代码的境地，不过考虑到在LLM的帮助下，我现在产出的代码量也显著增加了，我并不认为这是一个警告信号。
幸运的是，自LLM发布以来，重构代码所需的工作量已显著下降。
本文将详细介绍我使用Cursor或Claude Code等编程助手进行代码重构的高级方法和思考过程。我将涵盖通用的方法和流程，因此你使用的具体模型并不重要。
为什么需要进行代码重构
当你注意到代码中存在大量反模式，或者发现你（或你的编程助手）在某个实现上花费的时间比应有的时间更长时，你就应该进行代码重构。考虑到现在使用编程助手进行重构要容易和快速得多，你进行重构的阈值也应该比LLM发布之前更低。
这是因为代码重构是编程助手训练集的一部分，它们在这方面特别擅长。在很多情况下，我甚至认为它们比人类更出色，因为重构需要大量的工作记忆：
- 记住所有变量
- 确保重构后的输入/输出与重构前相同
- 确定要移动、删除和添加哪些文件
因此，你应该在以下情况下进行代码重构：
- 你或你的编程助手在代码中发现大量反模式
- 实现开始花费比预期更长的时间（这是代码质量不佳的迹象）
而你之所以应该进行代码重构，是因为：
- 它们可以提高迭代速度
- 使用LLM进行重构的成本相对较低
我的代码重构方法
在本节中，我将介绍我进行代码重构的高级方法。我将分四个步骤进行：
- 发现何时重构
- 重构前需要考虑的事项
- 重构期间需要考虑的事项
- 重构后需要考虑的事项
这将突出说明你如何在自己身上应用这种方法，并以如此通用的术语描述，以至于你可以在自己的代码库上复制该过程。
1. 发现何时重构
第一步始终是确定何时应该决定重构你的代码。通常没有一个明确的界限来确定何时应该执行重构，因此需要一些直觉来判断何时是合适的时机。
但是，你应该应用一些简单的通用原则。如果你在代码中看到大量反模式，例如：
- 大量重复代码
- 缺少文档字符串和函数类型
- 关注点分离不佳 你应该考虑进行重构。
此外，如果你注意到你的编程助手花费比平时更长的时间阅读你的代码库以试图理解它，或者它更频繁地难以实现某些功能，并且在其他地方出现错误，你也应该考虑重构。
然而，培养这种直觉需要时间，在开始时，你可以尝试尽早进行重构（考虑到使用LLM进行重构成本低廉），然后在学习过程中进行调整。
2. 重构前需要考虑的事项
当你走到这一步时，你已经决定应该重构代码库的某个部分。现在你需要规划重构应该覆盖的范围，因为你应该尽可能地缩小重构范围。
- 尽可能缩小重构的范围
然后我开始规划，我主要通过两种方式进行：
- （可选）如果我想讨论通用的架构决策或高层次的想法，我会开始在控制台中与Gemini聊天。我解释我的情况、权衡、我正在考虑的不同解决方案以及其他所有相关信息。然后我与Gemini就决策进行对话。注意“对话”这个词。我不是简单地询问Gemini如何解决我的问题；我是在与模型讨论什么可能是最佳方法，并试图尽可能好地理解问题。
- 我总是首先使用Cursor或Claude Code中的计划模式，你告诉模型你想要做什么，它浏览你的代码库，然后为你提出一个如何将解决方案实施到代码库中的计划。有时，我会复制我与Gemini的对话（如果我进行了对话），有时我只是直接在Cursor中开始我的重构。
规划你的方法非常有价值，因为你能够意识到一些之前没有意识到的问题，并可以基于尽可能多的信息做出决策。此外，你可以通读Cursor制定的计划，并在需要时进行调整。不过，最重要的是，我建议与你的编程助手就如何重构进行对话，而不是只问它一个简单的问题并只得到一个回应。
- 你应该努力与你的助手进行对话，而不仅仅是单一的问题和回答
我建议在进行重大重构时，至少花10-15分钟进行这次对话。
计划制定后，我将进入第3步。
3. 重构期间需要考虑的事项
如果你走到这一步，你已经和你的编程助手制定了一个好计划，并且已经开始执行重构。为了使重构高效并确保其尽可能好地工作，我会记住以下几点：
- 在权限方面尽可能宽松。当然，对破坏性命令要小心，但让助手能够执行大多数命令可以显著加快流程
- 使用Claude。我的经验是，Claude Sonnet/Opus 4.5是目前显著最好、最快的编码模型
- 告诉助手在需要时创建测试脚本。有时助手只尝试从代码本身进行调试，但通常最好告知它创建一个测试脚本，以便可以看到输入和输出
然后我让编程助手运行直到完成，这可能从一分钟到20分钟不等。如果这是你在仓库中首次运行代码，你可能需要允许列出一些命令，但如前所述，我在这里尽量宽松，特别是当我们谈论的是读取命令时，这些命令不会造成任何损害。
我还允许我的助手随意创建测试脚本并运行它们，以便不仅通过查看代码来调试，还可以通过查看输入和输出来调试。
在这种设置下，我在最多几次来回提示的情况下大多能成功完成重构，很多情况下只需一次提示。
4. 重构后需要考虑的事项
重构完成后，你需要考虑这些更改。有时你应该彻底检查所有代码，尽管有时没有必要。但是，在重构完成后，我有一些特别的建议：
- 要求模型比较重构前后的输入和输出（将模型指向你的主分支或开发分支，无论你开始新分支时基于哪个分支）。模型会为你提供一个概述，你通常应确保重构前后的输入和输出相同。这个技巧为我避免了很多错误
- 使用一个单独的助手运行代码审查（使用新的上下文启动），这样可以更容易地指出你的助手在重构时没有看到的错误
- 要求Cursor提供一个深思熟虑的提交信息，并为你创建PR。这既能加快代码上线的过程，又能让你的PR描述性更强
特别是，我关于与主/开发分支进行比较的第一点非常重要。让模型比较先前代码和当前代码的输入和输出，发现了许多模型在重构过程中没有发现的错误。
我相信随着编码模型变得更好，我们将看到越来越少的这类错误，不过就目前而言，我绝对认为让模型对更改进行二次审查非常有价值，既可以通过比较输入和输出，也可以通过进行代码审查。
结论
在本文中，我提供了如何进行代码重构的高级概述。我首先讨论了如何知道何时需要重构，然后深入探讨了重构方法的具体细节。接着，我介绍了如何在重构前使用计划模式，在重构期间允许列出命令，并要求模型用刷新后的上下文窗口对重构后的代码进行二次审查。
我相信，随着我们看到由LLM编程助手带来的越来越高代码产出，LLM重构将变得越来越重要。我也相信，使用LLM进行重构非常有效，这是每个人都应该牢记的事情，尤其是在大量使用编程助手进行编码时。
