玩转LLM实现持续创意代码重构的方法与技巧

时间：2026-08-14 18:24

比尔·盖茨的一句话，道出了代码重构的本质记得比尔·盖茨多年前曾说过一句令我至今难忘的话：“一切都与编写更少的代码有关。”这句话在今天的人工智能时代，显得尤为深刻。你看，大型语言模型（LLM）天生就热衷于生成代码，如果使用不当，它们会轻易地产出远超我们实际需求的数量。而AI辅助代码重构的妙处，恰恰在

比尔·盖茨的一句话，道出了代码重构的本质

记得比尔·盖茨多年前曾说过一句令我至今难忘的话：“一切都与编写更少的代码有关。”这句话在今天的人工智能时代，显得尤为深刻。你看，大型语言模型（LLM）天生就热衷于生成代码，如果使用不当，它们会轻易地产出远超我们实际需求的数量。而AI辅助代码重构的妙处，恰恰在于它能帮助我们减少重复、化解“软件负债”，并激发创造性的解决方案，最终导向一个更精简、更健康的代码库。

译自：How To Use LLMs for Continuous, Creative Code Refactoring[1]
作者：Jon Udell

过去的代码重构，往往被束缚在集成开发环境（IDE）那些固化且有限的转换规则里。一旦遇到规则库之外的情况，开发者基本上就无计可施，只能手动进行繁琐的修改。然而，支持模型上下文协议（MCP）工具的AI辅助IDE，彻底打破了这一僵局。你只需要向它们展示几组“修改前”和“修改后”的模式示例，这些工具就能举一反三，灵活识别并执行各类转换——哪怕这些转换从未被明确编程支持过。

举个例子，我曾用这样一段提示词，来清理一个XMLUI应用程序中不必要的 Fragment 组件使用：

代码重构提示词示例

我让Claude、Cursor和Codex同时处理一个包含此类XMLUI应用的目录，里面混有应该和不应该被重构的 Fragment 用法。结果呢？所有工具都给出了完全一致且正确的代码差异。如果用传统方法，你得专门编写一个能区分 when 属性和 gap 等其他属性并作出相应处理的XMLUI解析器。但大型语言模型不走这条路，它们是通用的模式识别引擎。这也印证了与LLM协作的一项核心原则：充分信任并利用其强大的模式识别能力。

提取组件以减少重复

在XMLUI中创建自定义组件来封装重复逻辑本来非常容易。问题在于，当某个模式只出现一次时，专门为其提取组件似乎多此一举。等到第二次、第三次出现，并且伴随一些变化时，你可能会开始考虑抽象。但通常情况下，需要更多的重复和更多的变体，才能真正厘清哪些部分是真正稳定、值得封装的核心。

于是，这里就存在一个经典的张力：是允许模式自然重复、变异以观察其本质，还是尽早整合以提升代码的可读性和可维护性？AI助手的存在，极大地缓解了这种张力。

假设你在代码中反复看到类似这样的结构：


  
    Cloud Cover
    
      {condition.cloudcover}%
    
  
  
    Humidity
    
      {condition.humidity}%
    
  
  
    Wind Speed
    
      {condition.windspeedMiles} mph

你迟早会意识到，下面这种写法要好得多：


  
  
  



  
    
      {$props.label}
    
    
      {$props.value}

我们常常因为“懒惰”而拖延这种重构。但话说回来，这种懒惰有时反而是种美德——如果你没有见过足够多、足够多样化的实例，很可能还无法准确把握重构后的形态应该是什么样。而AI助手让这种探索性实验变得成本极低、过程极其流畅。

利用AI协作规划代码变更

AWS的Kiro工具提供了一个有趣的“规范模式”（Spec mode），允许用户以协作方式编写需求、设计文档和任务清单。根据实际使用经验，它的能力边界有时比较明显，我也曾中途放弃过几个它生成的清单。但这个“先规划、后执行”的理念，却以一种更轻量的方式保留了下来，并融入到与Claude Code或Codex的日常对话中。

有一次，我让Claude为一个由XMLUI新手构建的应用程序实现一个认证门禁功能。它不仅识别出了所有需要修改的用户自定义组件，还详细列出了建议的更改项，并特别指出了一个需要特殊处理的组件：

Customers.xmlui has a pattern close to the standard but with some differences:– Uses contact_id for routes, but id for API URLs– Only has “Mark as inactive” (no status toggle)– Delete APICall is outside the DropdownMenuI need to update the component to support different ID fields for routes vs API calls.Let me do that first.

此外，该应用还冗余地使用了处理批量API调用的 Queue 组件。鉴于后端已提供批量API，这里的 Queue 完全是画蛇添足。这项改动涉及删除冗余代码并添加正确的批量API调用。AI助手很快给出了清晰的计划：

1. Remove the Queue (lines 106-143)2. Remove unnecessary variables (lines 4-7): var.action, var.processedCount, var.errorCount, var.completed3. Replace the bulk action buttons (lines 84-104) to call APICall components instead of Queue4. Add APICall components following the pattern you described:– POST /contacts/active with body: {contact_ids: […], organization_id: 906441453}– POST /contacts/inactive with body: {contact_ids: […], organization_id: 906441453}– DELETE /contacts/{ids} for bulk delete

这次，一切完全按计划执行。当然，现实并非总是如此顺利，但AI辅助编程所倡导的这种对话式风格，极大地便利了我在工作进程中随时调整和修正计划。

通过更简洁的代码限制软件负债

Cory Doctorow近期提出一个尖锐的观点：代码是负债，而非资产。更麻烦的是，很多科技公司的管理者并未意识到这一点。

“他们以为自己找到了一台能以程序员万倍速率生产资产的机器。其实不然。他们找到的是一台能以万倍速率制造负债的机器。”

安全专家Bruce Schneier则从另一个角度警告，这种“软件负债”会带来法律和财务风险，软件制造商最终可能需要通过购买保险来对冲风险，而这会让发布有缺陷或不安全的产品代价高昂。

那么，AI辅助编码会增加软件负.债吗？如果滥用，答案无疑是肯定的。但事情有两面性。只要运用得当，AI同样能帮助我们减少负债——它让持续重构变得更简单、更安全，从而确保代码库保持精简和整洁。

借助AI辅助应用创造性洞察

在移除了 Queue 的冗余使用后，我注意到另一处重复：一系列用户自定义组件中，存在多个相似的 APICall 使用模式。但 APICall 本身无法被封装进声明式的自定义组件里，这该如何整合？

这时，一个创造性洞察出现了：APICall 的命令式“兄弟”—— Actions.callAPI，可以在 onClick 事件处理器中直接调用。这样一来，就避免了为每个操作单独声明一个 APICall 组件。这并非一场彻底的胜利，因为它只是把声明式的属性转移到了命令式的参数里。但在命令式范畴内，为不同场景定义参数族变得异常清晰。例如，在处理批量项目时，操作名称可能是“标记为活动”或“删除”，进行中的提示消息可能是“正在标记…”或“正在删除…”，完成提示也相应变化。

将这些逻辑封装到一个函数中固然让代码更整洁，但也带来了新的重构挑战：每个组件都需要该函数的一个变体。如何让它们共享同一个函数呢？通常用于存储简单键值对的 AppState（全局应用状态）提供了灵感——它对所有用户自定义组件可见，那么，何不把它也用作存储箭头函数的全局空间？

这种突破性的想法，LLM自己很难主动发现。但当你有了灵感后，它们就是绝佳的验证和应用伙伴。在这个案例中，Claude先编写了一个快速测试来验证方案的可行性，随后便将一组相似的函数成功合并到了一个公共的全局函数中。

编码中的“少即是多”方法

让我们回到开篇比尔·盖茨的那句话：“一切都与编写更少的代码有关。”LLM天性热爱生成，若不加约束，它们会生产出海量我们并不需要的代码。我们必须清醒地认识到，代码本质上是一种负债。因此，开发者的核心责任之一，就是驾驭LLM的生成本能，将其引导到旨在限制这种负债的重构工作中来。在这个过程中，人类负责决策“何时”以及“如何”重构，而AI则高效执行那些机械化的转换任务——这构成了一种持续的、创造性的对话。最终，那些旨在生成代码的工具，其最高价值反而可能是帮助我们写出更少的代码。

引用链接

[1]How To Use LLMs for Continuous, Creative Code Refactoring:https://thenewstack.io/how-to-use-llms-for-continuous-creative-code-refactoring/
[2]Fragment:https://docs.xmlui.org/components/Fragment
[3]XMLUI:https://thenewstack.io/make-react-components-with-xmlui-a-visual-basic-for-the-ai-era/
[4]![](/uploadfile/2026/0814/450b79d7395a8d98fee197d499f65828.webp):/uploadfile/2026/0814/450b79d7395a8d98fee197d499f65828.webp
[5]七项原则:https://thenewstack.io/7-guiding-principles-for-working-with-llms/
[6]用户定义组件:https://docs.xmlui.org/components-intro
[7]AWS Kiro:https://thenewstack.io/aws-kiro-testing-an-ai-ide-with-a-spec-driven-approach/
[8]实现一个认证门:https://docs.xmlui.org/howto/implement-an-authentication-gate
[9]Queue:https://docs.xmlui.org/components/Queue
[10]对话式风格:https://thenewstack.io/lets-talk-conversational-software-development/
[11]Cory Doctorow:https://doctorow.medium.com/
[12]代码是负债（而非资产）:https://doctorow.medium.com/https-pluralistic-net-2026-01-06-1000x-liability-graceful-failure-modes-d69f384af9e4
[13]法律和财务:https://www.schneier.com/essays/archives/2003/11/liability_changes_ev.html
[14]APICall:https://docs.xmlui.org/components/APICall
[15]Actions.callAPI:https://docs.xmlui.org/globals#actionscallapi
[16]AppState:https://docs.xmlui.org/components/AppState
[17]创造性洞察:https://thenewstack.io/human-insight-llm-grunt-work-creative-publishing-solution/
[18]Bill Gates:https://en.wikipedia.org/wiki/Bill_Gates