老旧代码重构攻略：ChatGPT5.5 优化思路详解

前段时间在一个AI工具合集站上翻开发者社区的讨论，看到有人说ChatGPT 5.5做代码重构“思路很清晰”。正好手头有一个搁置了很久的遗留模块需要重构，就想着拿它试试，看AI辅助重构到底能做到什么程度。

这个模块是两年前写的，一个处理用户上传文件的后端服务，约600行Go代码。功能上一直跑着没问题，但代码质量一言难尽——函数职责混乱、错误处理随意、测试覆盖率不到30%、文档为零。每次有新同事入职，这个模块都是理解代码库的拦路虎。

下面把整个重构过程原原本本记录下来，分享几个AI辅助重构的实用思路。

重构前的评估：先搞清楚“为什么重构”

在动手之前，先把整个模块提交给ChatGPT 5.5，让它做一次快速评估。Prompt很简单：“分析这个Go模块的代码质量，指出主要问题，按严重程度排序。”

它给出的评估报告列出了五个主要问题。最严重的是三个函数超过150行，职责混杂——一个函数里同时处理文件校验、格式转换、存储上传和数据库记录更新，属于典型的“上帝函数”。其次是错误处理不一致——有的地方用自定义Error类型，有的地方用fmt.Errorf，有的地方直接return nil。然后是缺少输入校验——文件类型和大小检查分散在多个函数里，有遗漏的入口。还有并发安全问题——一个全局map在多个goroutine中共享但没有加锁。最后是测试覆盖不足且依赖真实数据库和云存储，导致测试不可重复运行。

AI的评估和自己预想的结论基本一致，但它用五分钟完成了一般人可能需要半天才能整理出来的结构化评估报告。更重要的是，它给出了一个重构优先级建议：先处理并发安全问题（可能导致panic），再拆分大函数（可维护性最差），然后统一错误处理，最后补测试。

重构策略：不是一次性重写，而是分步安全重构

基于AI的评估，制定了分五步的重构计划。核心原则是每一步都不改变外部行为，每次改动后跑测试确认没有引入回归。

第一步处理并发安全——给全局map加读写锁，这是最紧急的问题，而且改动范围最小。第二步拆分大函数——把三个超过150行的函数按职责拆成多个小函数，提取公共逻辑。第三步统一错误处理——定义模块级错误类型，统一错误包装方式。第四步抽取输入校验——把分散在多个函数里的校验逻辑集中到一个地方，确保所有入口都经过校验。第五步补测试——用接口抽象替代真实依赖，补单元测试到覆盖率80%以上。

让AI拆分大函数：一次只给一个任务

拆分最大的那个文件处理函数时，这个函数约180行，包含了文件校验、格式转换、存储上传、数据库记录更新四个职责。

没有直接把整个函数扔给AI让它重构，而是分了三步。

第一步，让它分析函数结构。Prompt：“分析这个函数的职责，识别出可以独立拆分的逻辑块，给出拆分建议但不要改代码。”它把函数拆成了四个逻辑块：文件校验逻辑、格式转换逻辑、存储上传逻辑、数据库操作逻辑，并标注了每个逻辑块的输入输出和它们之间的数据依赖关系。

第二步，逐个拆分。Prompt：“把文件校验逻辑提取成独立函数，函数签名从上下文推断，保持原有行为不变。”它生成了一个ValidateFile函数，包含文件类型检查、大小限制、恶意内容扫描。确认逻辑正确后，让它继续提取下一个逻辑块。

第三步，让它自己审查自己的重构结果。拆分完成后，把新旧代码都贴给它，问：“重构后的代码和原始代码在行为上是否完全一致？有没有遗漏的边界情况？”它发现提取后的格式转换函数在某个错误分支上漏了一个defer关闭文件句柄的操作，这是原始代码就有的问题，在重构中被发现并修复了。

分三步走的好处是每一步的输出都足够小，可以人工快速验证。如果让它一次性重构整个函数，生成的代码太长，人工审查的工作量和直接手写差不多。

让它补测试：先给接口抽象，再生成测试

补测试是整个重构中最枯燥也最耗时的环节。原代码直接依赖真实数据库连接和云存储SDK，导致测试不可重复运行。重构的第一步不是写测试，而是让代码可测试。

让ChatGPT 5.5先把依赖项抽象成接口。Prompt：“把这个模块中对数据库和云存储的直接调用，抽象成接口。接口定义要足够通用，既能用于真实实现，也能用于Mock实现。”

它生成了FileRepository和StorageService两个接口，把原来的具体实现改成了接口注入。这个改动本身也改善了代码结构——依赖关系从隐式变成了显式。

有了接口之后，写测试就顺畅了。Prompt：“为ValidateFile函数生成pytest风格的单元测试，使用mock.Mock模拟依赖。覆盖正常情况、文件类型不支持、文件大小超限、空文件名四个场景。”它生成的测试用例覆盖了能想到的主要边界情况，而且Mock的使用方式正确——Mock对象只模拟了被测试函数直接调用的方法，没有过度模拟。

针对最复杂的处理流程函数，Prompt：“为ProcessUpload函数生成测试。这个函数依次调用了ValidateFile、ConvertFormat、UploadStorage、Sa veRecord四个步骤。用Mock模拟所有依赖，测试正常流程、校验失败、转换失败、上传失败、数据库写入失败五种情况。每种情况都要验证失败后是否正确停止了后续步骤。”

它生成的测试覆盖了所有失败路径，而且每个测试用例都验证了失败后后续步骤的Mock方法没有被调用。这种“反向验证”确保错误处理逻辑在重构中没有被破坏。

五步重构完成后，模块的测试覆盖率从不到30%提升到了82%。重构前后的性能测试显示响应时间没有显著变化。

AI在重构中的真实作用

整个重构过程用了两天。AI不是“自动完成了重构”——每一行代码的改动决策和最终确认都是自己做的。但它在几个环节上确实显著缩短了时间。

结构化评估。AI用几分钟完成了对600行代码的评估，输出了按严重程度排序的问题清单。如果从头梳理，至少需要半天。

机械性重构。拆分函数、提取接口、统一错误处理，这些重构操作有明确的规则可循，AI执行起来高效且准确。但每次只给它一个小的、明确的任务，改动之后人工审查。

测试生成。这是AI最有价值的环节。补测试本身是机械劳动，但需要覆盖各种边界情况。AI在这方面的表现已经比较可靠，生成的测试用例覆盖了正常人能想到的边界，偶尔还有意外收获——比如它主动生成了“并发上传相同文件”的测试用例，这个场景最初没有考虑到。

它在哪些地方容易犯错

在重构过程中，ChatGPT 5.5也有几次需要纠正的情况。

有一次在拆分函数时，它改变了错误处理的行为——原始代码在某个错误分支上记录了日志然后返回错误，它提取后只返回了错误没有记录日志。指出后它修正了。还有一次它建议引入一个轻量级Worker Pool库来管理并发，但当前场景下标准库的goroutine完全够用，引入第三方依赖反而增加了复杂度。拒绝了它的建议。

在重构接近完成时，AI的建议开始变得“过度优化”——它开始建议调整一些不影响功能和可维护性的代码风格细节，比如变量命名方式、注释格式调整。明确告诉它“停止优化，当前版本已满足要求”，它就停止了。

ChatGPT 5.5在重构中的表现像是一个能干但需要监督的初级工程师。它能高效完成明确的任务，但在需要全局判断的决策上——比如是否引入第三方依赖、重构到什么程度算“够了”——需要人来把关。

这次重构的几点经验

AI辅助重构最有价值的不是“快”，而是“敢”。面对一团乱麻的老代码，最难的往往不是不知道怎么改，而是不敢改——怕改出线上事故。AI提供的快速评估和测试生成能力，降低了重构的心理门槛和实际风险。先让它分析清楚代码结构和问题所在，再一步一步改，每一步都有测试兜底，重构就从一个让人望而生畏的任务变成了可以逐步推进的常规工作。

AI擅长处理有明确规则的重构操作。拆分函数、提取接口、统一错误处理、生成测试，这些都是有“正确答案”可循的任务，AI执行起来高效且准确。但它不适合做需要全局判断的架构决策——比如模块间职责划分、技术选型、重构优先级排序。这些决策仍然需要开发者的经验和判断。

每一次AI生成的改动都经过了人工审查。审查AI的代码确实比从零写代码轻松，但仍然需要保持警惕——AI在重构中容易出现的错误类型和人类不太一样，它更可能遗漏隐式的业务约束或改变错误处理的行为。

老代码的最大问题是没人敢动。测试覆盖率低，改一行怕全线崩溃。AI最大的价值不是写代码更快，而是帮你给老代码铺上测试这张安全网，让你敢动手改。一旦有了测试，老代码就不再是禁区了。

你用AI重构过老代码吗？在哪个环节感觉AI帮的忙最大，在哪个环节最让你头疼？评论区聊聊你的实际体验。