真实案例：用 AI 重构一段难维护的旧代码

文章目录一、先看一段难维护的旧代码二、重构前先锁定旧行为三、先让 AI 做分析不直接改代码四、先补测试再动旧代码五、让 AI 提出最小重构方案六、重构后的代码七、一个容易忽略的行为变化八、重构后怎么验证九、什么时候不适合直接重构十、旧代码重构清单总结✍创作者全栈弄潮儿 个人主页全栈弄潮儿的个人主页️ 个人社区欢迎你的加入全栈开发社区 专栏地址AI 编程提效实战接手旧项目时最麻烦的通常不是代码不能运行而是状态值没有含义、判断层层嵌套改一处又担心影响其他页面。AI 很适合帮助我们读懂和整理旧代码但不能让它直接把一大段代码改掉。这篇文章用一个订单状态展示函数演示如何安全地完成一次小步重构。核心原则只有一句先确认旧代码做了什么再决定如何改。一、先看一段难维护的旧代码下面的函数根据订单状态决定页面显示什么文字以及用户可以执行哪些操作functiongetOrderDisplay(order){lettext;letcanPayfalse;letcanCancelfalse;if(order){if(order.deleted1){text订单已删除;}elseif(order.status0){text待支付;canPaytrue;canCanceltrue;}elseif(order.status1){if(order.shippedAt){text运输中;}else{text待发货;}canCanceltrue;}elseif(order.status2){text已完成;}elseif(order.status3){text已取消;}else{text状态异常;}}return{text,canPay,canCancel};}代码不算很长但已经有明显的维护问题0、1、2、3是魔法数字。状态文字和操作权限混在同一个函数里。status 1又依赖shippedAt规则不直观。传入空订单时返回空文本调用方不容易发现问题。后续增加“退款中”“已退款”等状态时条件会继续膨胀。这时不要先说“帮我优化这段代码”。先把业务规则找出来。二、重构前先锁定旧行为重构的目标不是让代码看起来更漂亮而是在不改变正确业务行为的前提下让代码更容易修改。先根据旧代码整理出当前行为条件展示文字可支付可取消deleted 1订单已删除否否status 0待支付是是status 1且没有shippedAt待发货否是status 1且有shippedAt运输中否是status 2已完成否否status 3已取消否否其他状态状态异常否否这张表非常重要它不是 AI 猜出来的而是从现有代码中整理出来的。如果你不知道某个规则是否正确例如“运输中的订单为什么还能取消”不要擅自改掉。先向产品、业务同学或旧代码负责人确认。三、先让 AI 做分析不直接改代码可以把代码和已知背景交给 AI请分析下面的 JavaScript 函数暂时不要修改代码。 函数用途根据订单数据返回页面展示文字、是否可以支付、是否可以取消。 请输出 1. 该函数当前的所有行为整理成条件表。 2. 代码中难维护的地方。 3. 可能存在歧义、需要人工确认的业务规则。 4. 一个保持现有行为的最小重构方案。 5. 重构前应该补充哪些测试。 要求 - 不要自行改变订单状态含义。 - 不要增加退款、支付超时等未提供的功能。 - 明确区分“代码事实”和“你的推测”。 代码 [粘贴旧代码]这类 Prompt 的关键是限制 AI 不要擅自补业务。AI 可能会指出一个值得确认的问题status 1时订单已经发货却仍然可以取消是否符合业务规则这个问题不能由 AI 决定。假设我们和业务确认后当前规则确实如此那么重构就必须保留它。四、先补测试再动旧代码旧代码如果没有测试直接重构风险很高。先把上面的行为表变成测试。这里以 Vitest 为例import{describe,expect,it}fromvitest;import{getOrderDisplay}from./order-display.js;describe(getOrderDisplay,(){it(未支付订单可以支付和取消,(){expect(getOrderDisplay({deleted:0,status:0})).toEqual({text:待支付,canPay:true,canCancel:true});});it(已发货订单显示运输中仍保留当前的取消规则,(){expect(getOrderDisplay({deleted:0,status:1,shippedAt:2026-09-01T10:00:00Z})).toEqual({text:运输中,canPay:false,canCancel:true});});it(未知状态显示状态异常,(){expect(getOrderDisplay({deleted:0,status:99})).toEqual({text:状态异常,canPay:false,canCancel:false});});});真实项目中应覆盖行为表里的每一种情况。这样重构后若意外改变已有行为测试会尽早提醒我们。五、让 AI 提出最小重构方案这一步的重点是“最小”。不要让 AI 一次把状态管理改成复杂的状态机也不要为了一个函数引入新的库。可以这样提问下面是一段已经有测试保护的订单展示逻辑。 请给出一个最小重构方案目标是 1. 消除状态魔法数字。 2. 让每个状态的规则更容易阅读。 3. 保持现有测试行为不变。 4. 不引入新依赖。 5. 不修改调用方接口。 请先解释修改点和风险再给出完整代码。一个合适的方案通常是用常量命名订单状态。用switch明确分支。为每个状态直接返回结果。保留原函数名称和返回结构。六、重构后的代码constORDER_STATUS{PENDING_PAYMENT:0,PENDING_SHIPMENT:1,COMPLETED:2,CANCELED:3};functiongetOrderDisplay(order){constdefaultResult{text:状态异常,canPay:false,canCancel:false};if(!order){returndefaultResult;}if(order.deleted1){return{text:订单已删除,canPay:false,canCancel:false};}switch(order.status){caseORDER_STATUS.PENDING_PAYMENT:return{text:待支付,canPay:true,canCancel:true};caseORDER_STATUS.PENDING_SHIPMENT:return{text:order.shippedAt?运输中:待发货,canPay:false,canCancel:true};caseORDER_STATUS.COMPLETED:return{text:已完成,canPay:false,canCancel:false};caseORDER_STATUS.CANCELED:return{text:已取消,canPay:false,canCancel:false};default:returndefaultResult;}}这次重构没有改变外部接口调用方仍然使用constdisplaygetOrderDisplay(order);它主要改善了三点状态值有了业务名称。每个分支都在一个清晰的位置返回结果。新增状态时不需要在多层if中寻找插入点。七、一个容易忽略的行为变化旧代码传入null时会返回{text:,canPay:false,canCancel:false}重构后传入null时会返回“状态异常”。这看起来是更合理的结果但它已经改变了旧行为。此时必须停下来做决定如果调用方依赖空文本就保持旧行为并写测试锁定它。如果“状态异常”才是正确产品表现就把它作为明确的需求修改补充验收和测试。这正是 AI 重构最容易踩的坑它可能顺手“修复”一些看似不合理的逻辑但这些逻辑可能是旧系统的一部分。为了完全保持旧行为可以把空订单单独处理if(!order){return{text:,canPay:false,canCancel:false};}重构不是改得越多越好而是每个行为变化都要有明确依据。八、重构后怎么验证完成代码后至少做四件事运行已有单元测试确认旧行为没有被意外改变。手动验证订单列表和订单详情页确认展示一致。检查本次 diff确认没有改到无关文件。让 AI 再做一次审查重点检查行为变化和遗漏测试。可以使用下面的审查 Prompt请审查下面这次旧代码重构的 diff。 重构目标 - 用具名常量替代订单状态魔法数字。 - 保持原函数名称、返回结构和业务行为。 - 不引入新依赖。 请重点检查 1. 是否有任何行为变化。 2. 是否遗漏订单状态分支。 3. 空订单和未知状态是否有明确处理。 4. 现有测试是否覆盖了本次改动。 5. 是否存在不必要的复杂化。 请按“问题位置、严重程度、影响、建议、验证方式”输出。 不要直接重写代码。如果 AI 说“逻辑更简洁了”这不是验收结论。真正要看的是它是否能指出具体分支、具体影响和验证方法。九、什么时候不适合直接重构下面几种情况不建议直接让 AI 修改不知道函数被哪些页面或服务调用。没有测试也无法快速补测试。订单、支付、权限等核心规则尚未确认。旧代码涉及数据库迁移或批量数据修改。AI 需要读取真实密钥、用户数据或未经授权的公司代码才能理解问题。这时 AI 仍然可以帮你做“阅读代码、列问题、设计测试”的工作但修改动作应该更谨慎并进行人工评审。十、旧代码重构清单已经确认函数的用途和调用位置。已经整理旧代码的行为表。已经区分代码事实和业务猜测。已经补充正常、边界和异常测试。已经让 AI 先分析再提出最小方案。已经一次只修改一个清晰问题。已经确认所有行为变化都有需求依据。已经运行测试并检查 diff。没有将敏感数据直接提交给 AI。总结AI 可以大幅降低阅读和整理旧代码的成本尤其适合提取复杂条件中的业务规则。找出重复代码和魔法数字。提出多种小步重构方案。补充可能遗漏的测试场景。在提交前审查改动范围。但 AI 不知道你的历史包袱和真实业务规则。面对难维护的旧代码正确顺序应该是读懂旧代码 ↓ 整理行为表 ↓ 补测试锁定行为 ↓ AI 提出最小重构方案 ↓ 小步修改并运行验证 ↓ 审查 diff 后再提交让 AI 帮你看清旧代码不要让它在不了解业务时替你决定旧代码该怎么改。下一篇文章将介绍《真实案例用 AI 快速定位一次代码问题》✍坚持原创求关注点赞收藏