重构代码提高可读性、消除重复，补上类型标注和必要注释。
编程 · 由 周野 维护（CPCX 撰稿人 · 编程与数据）
请重构下面的代码：提高可读性、消除重复、补上类型标注和必要的注释，重构后说明改动点：
重构前说明语言版本和团队代码规范，结果会更省事。节奏上小步走：每次只重构一个函数，跑通测试再继续——一次贴几百行让 AI 大改，review 的成本可能比自己重写还高。
让 AI 解释每一处改动的原因，review 时心里更有底。解释含糊的改动（比如只说「这里优化了一下」）要追问到具体为止，说不清理由的重构不如不做。
重构最大的风险是行为改变。发提示词之前先确认一件事：这段代码有没有测试。有测试，重构完跑一遍就能验证；没有测试，先在提示词里加一句「不要改变对外行为，只调整内部结构」，并要求 AI 列出可能影响行为的改动点。
一次只重构一个维度：只拆函数、只消除重复、只补类型标注。三个一起做，出问题很难定位是哪一步引入的。
贴入一段 80 行、嵌套三层的订单处理函数，要求「拆成 3-4 个小函数，每个函数只做一件事，保持入参和返回值不变」。拿到结果后按顺序做三件事：先看它有没有偷偷改掉错误处理，再看函数命名是否表达意图，最后跑测试。
典型的输入是：一个两百行左右、嵌套三层 if-else 的价格计算函数，里面混着业务规则、格式化和日志。把整段贴进去，要求「提高可读性、消除重复、补上类型标注」。
重构结果通常是：把每档价格规则抽成独立配置或策略函数，主函数只负责按条件取规则，重复的格式化逻辑提成工具函数，补上参数与返回值的类型。它还会附一份改动说明，逐条列出「原来是什么、现在是什么」。
看完说明要重点确认一件事：所有分支条件是否被完整保留。重构最容易出事的地方不是代码写法，而是某条边角规则在整理的过程中被合并掉了。
第一，跑通现有测试，或者至少快速过一遍主流程，留下一个「改之前是正常的」基线；没有测试的项目，用写单元测试的模板先给要重构的部分补上几条；
第二，把「哪些逻辑不能动」写在提示词里。比如「对外的错误码不能改」「函数名在别处被引用，不能重命名」，这类约束不给，它就会按自己的审美改。
老项目渐进式重构时，加一句「保持函数签名不变，只改内部实现，调用方不需要改动」，这条约束能让重构可以分批合入，不用一次改完整个模块。
性能导向的重构要换个说法：「先指出性能瓶颈在哪，再给出等价的重写方案，说明每一步为什么更快」。把它当性能评审用，比当美化工具用更有价值。
适合结构混乱但行为明确的代码：拆长函数、收重复逻辑、改命名，这些它做得干净。
也适合重构完自己再看一遍，让它对照原实现检查有没有改坏。