在开发者的日常工作中，比“从零开发新需求”更让人头疼的，绝对是“接手离职同事留下的无注释老代码”。
上周，就有这样一个棘手的任务摆在面前：重构一个三年前写成的核心订单计费模块。整个模块用纯 Ja vaScript 编写，一个文件里塞了 800 多行代码，充斥着嵌套的 Promise 回调、满天飞的魔术数字（Magic Numbers），以及为了修补线上 Bug 而临时打的恶心补丁。更要命的是，没有任何文档，业务侧也只能给出一个大概的计费规则，边缘逻辑全靠代码自己解释。
面对这种典型的“屎山代码”，硬啃的成本太高了。为了减少试错成本，可以借助大语言模型来梳理逻辑。经过对多个模型的对比测试，ChatGPT 在面对这种高复杂度、逻辑极度耦合的代码时，指令遵循能力和重构稳定性依然是最让人放心的。
于是，我们放弃了“人肉单步调试”的笨办法，基于 ChatGPT 搭建了一套“反推业务逻辑-安全重构-生成单测”的工程化工作流。今天就把这套真实踩过坑的流程分享出来。
踩坑警示：千万别直接让 AI “重构这段代码”
很多人用 AI 重构代码时，最容易犯的错误就是把几百行代码直接复制进去，然后抛出一句：“帮我重构这段代码，让它更优雅”。
不少开发者一开始也是这么干的。ChatGPT 给出的结果确实非常“优雅”：提取了类，用了最新的 async/await，还加上了清晰的注释。但把代码拿回本地一跑测试用例，瞬间报了一堆错。
仔细一查才发现，原代码里有一个极其隐蔽的逻辑：当用户的折扣券叠加计算出现特定小数位时，有一个非标准的“向上取整”补丁。AI 在重构时，为了追求代码的简洁和符合常规逻辑，直接把这个看似不合理、实则是真实业务规则的补丁给优化掉了。
这次翻车让我们明白了一个道理：在没有单测保护，且本身都不清楚全部业务逻辑的情况下，让 AI 盲目重构是极其危险的。
实战工作流：把 AI 当作业务反推引擎
为了让重构过程可控，我们把工作流拆成了三个必须严格按顺序执行的阶段。
阶段一：数据脱敏与业务规则反推
绝对不要把包含真实数据库表名、公司秘钥或特定商业算法的代码直接扔给公网模型。在喂给 ChatGPT 之前，先在本地把代码里的敏感字段做了全局替换（比如把真实的表名替换成了 table_a，把加盐算法替换成了 // dummy hash）。
接着，并没有让 AI 写代码，而是让它扮演一个“代码考古学家”，把隐藏在 if-else 里的业务逻辑全部挖出来。
Prompt 可以这样写：
“你现在是一个资深的业务架构师。请仔细阅读以下这段脱敏后的 Node.js 订单计费逻辑代码。
任务要求：
- 绝对不要对代码进行任何重构或修改。
- 请用 Markdown 列表的形式，逐条反推出这段代码中包含的所有【核心计费规则】。
- 单独列出所有的【异常处理逻辑】和【隐式依赖的边界条件】（如特定的数值判断、特殊的用户标识）。
- 指出代码中存在硬编码（Magic Number）的地方，并推测其业务含义。”
ChatGPT 的输出非常惊艳，它不仅把四种不同类型优惠券的叠加顺序梳理得清清楚楚，还揪出了两个人工看代码时完全没注意到的隐蔽边界条件。拿着这份 AI 生成的“反推业务文档”，跑去和产品经理核对一遍，确认无误后，才敢进行下一步。
阶段二：模块化与强类型重构
有了业务规则作为“需求文档”，重构就变成了有底气的事情。这时候，可以让 ChatGPT 把原本揉成一团的意大利面条代码拆解开来。为了降低出错率，要求它一步步来，并且引入 TypeScript 来增强约束。
在这个阶段，Prompt 策略转向了工程化规范：
“基于我们刚才梳理出的计费业务规则，请按以下工程化规范重构这段代码：
- 使用 TypeScript，并为 Order、User、Coupon 等核心数据结构定义严谨的 interface。
- 剥离副作用，将纯粹的数学计算逻辑（如折扣计算、税率计算）抽离成独立的纯函数（Pure Functions）。
- 消除原来的回调地狱，使用 async/await 处理异步数据库查询。
- 必须保持原有计算结果 100% 一致，不要擅自‘优化’业务逻辑，即使它看起来不合理。”
通过明确指定“纯函数”和“TypeScript 类型定义”，AI 输出的代码质量有了质的飞跃。原本 800 行的乱码，被拆分成了几个职责单一的 calculateDiscount、applyTax 独立模块，不仅阅读起来神清气爽，更重要的是，这些纯函数变得极其容易测试。
阶段三：用 AI 织起测试安全网
老代码之所以没人敢动，就是因为没有单元测试。现在有了拆解好的纯函数，让 ChatGPT 写单测简直就是它的舒适区。
特别是在测试框架的选择上，可以让它使用 Jest，并且指定表格驱动测试（Table-driven tests）的格式，这样不仅能覆盖更多的边缘输入，还能兼做活文档。
单测生成的 Prompt 示例：
“请基于重构后抽离出的
calculateDiscount纯函数，使用 Jest 编写完整的单元测试代码。
要求：
- 必须使用
test.each语法（表格驱动测试），以便直观地展示输入输出的映射关系。- 至少包含 5 个正常的业务场景，以及 3 个极端的边界场景（例如：传入负数、大数精度溢出、空对象）。
- 确保断言覆盖了抛出异常的情况。
- 直接输出可执行的 Jest 代码。”
把这段 Prompt 发过去，几秒钟后拿到几十行结构工整、覆盖了各种奇葩输入的测试用例时，那种省心感是难以言表的。把测试代码拷进项目，npm run test，看着控制台亮起一排绿色的 Pass 勾勾，重构这件高风险的脏活儿，才算是安全落地了。
AI 辅助重构的风险边界
虽然这套工作流极其高效，但在实际落地中，有几个底线是绝不能踩的：
- AI 无法发现业务漏洞，它只能忠实翻译
如果你的老代码里本来就存在算错钱的 Bug，ChatGPT 在重构时通常会把这个 Bug 一起“完美复刻”过去。它不懂你的商业模式，只懂代码逻辑。因此，重构后的验收必须结合真实的回归测试环境，不能完全依赖 AI 的审查。 - 警惕 AI 编造 API（幻觉问题）
在处理复杂的系统环境依赖时，AI 可能会在重构时调用一些并不存在的 Node.js 库或者编造某个 ORM 的不存在的方法。代码必须在本地 IDE 里过一遍静态检查和编译。 - 安全与合规永远是第一位
再次强调，公司核心资产（如加密私钥、未开源的核心算法逻辑、带有真实客户信息的日志）绝对不能复制到任何公网模型对话框里。对于特别核心且敏感的模块，宁可人工多花点时间，也不要贪图方便。
总结
回顾这次与老代码的博弈，最大的体会是：不要把 AI 当成一个只会盲打代码的打字机，而是要把它当作一个不知疲倦的架构师和代码 Reviewer。
先让它读懂代码、反推规则；再让它依据规则进行类型化重构；最后让它生成密集的测试用例来保障安全。当你学会用一套有控制变量、有阶段拆解的工程化 Workflow 去驾驭 ChatGPT 时，那些曾经让人抗拒的祖传代码，也就没那么可怕了。毕竟，真正值钱的从来不是敲下那几行代码的动作，而是掌控整个复杂系统的重构思路。