代码能跑，但一个月后你自己都看不懂。
这就是所有人都会撞上的那堵墙。
前面十几篇我们一直在解决”能不能跑“：写出来、跑起来、修好 Bug。从这一篇开始换赛道，解决”跑得好不好看“。
你可能会想：能跑就行呗，好看有什么用？我给你算笔账。
一段乱七八糟的代码，今天写完能跑。三周后要加功能，你盯了二十分钟才想起来”这个变量是干嘛的”。改完一测，另外三个地方坏了——因为你根本不知道这段代码还被谁用着。
代码不是写给电脑看的，电脑什么烂代码都能跑。代码是写给三周后的你自己看的。 而”三周后的你”，记忆力大概等于一个陌生人。
这一篇，教你把 AI 变成专门帮你”擦桌子”的助手。
一、先说清楚：什么叫重构
这个词听着唬人，其实一句话就能说明白：
重构 = 只改样子，不改行为。
改之前输入 1 得到 2；改之后输入 1 还得得到 2。功能一模一样，只是更好读了。 这句话是本篇的地基，务必记牢。新手用 AI 重构翻车，九成踩在这一句上。
典型翻车现场：
小白：（把整个文件甩给 AI）帮我重构一下这段代码。 AI：好的！我帮你重构了。（顺手合并三个功能，删掉两个”看起来没用”的判断，还改了接口返回格式） 小白：（一测）……怎么全崩了？
AI 不知道哪些代码”看起来没用但其实很重要”。 那个奇怪的 if，可能是三个月前为某个客户特殊情况加的。你不说，AI 就当垃圾清掉。所以重构主导权必须在你手上，AI 只是那把刀。
二、烂代码的六种味道：先学会”闻”
程序员圈有个说法叫 Code Smell（代码坏味道）：不一定有 Bug，但闻着不对劲，早晚出事。记六种就够了，口诀长、重、名、套、魔、杂，叫重构六味：
第一味：长（函数太长） 一个函数拉到两百行，滚轮滚半天。判断标准很土但好用：一屏放不下，就是太长了。
第二味：重（重复代码） 同一段逻辑复制粘贴出现三次以上。改的时候必须记得改三个地方——你一定会忘掉一个。
第三味：名（命名瞎起） 满屏 a、b、tmp、data1、flag。写的时候知道，三周后不知道。
第四味：套（嵌套太深） if 里套 if，if 里再套 for——缩进快顶到屏幕右边了。 超过三层就该警觉。
第五味：魔（魔法数字） 代码里突然冒出 7、0.85、3600。从哪来的？代表什么？没人知道，包括三周后的你。
第六味：杂（一个函数干太多事） 一个”保存订单”函数，又查库存、又算优惠、又发短信、又写日志。名字说它干一件，实际干了四件。
三、重构四步法：锁、闻、拆、验
整套流程四步，口诀“锁闻拆验”。
第一步：锁（锁定行为基线）
这是最重要、也最容易被跳过的一步。 动任何一行之前，先回答：
改完之后，我怎么证明”没改坏”？
答不上来，就不要开始。最实用的做法是做一张“行为快照表”：把这段代码目前的几组”输入 → 输出”记下来。比如算运费的函数，实际跑几次记下来：
输入：重量 0.5kg、地址 本市 → 输出：6 元
输入：重量 3kg、地址 外省 → 输出：18 元
输入：重量 0（异常） → 输出：报错"重量不能为0"
输入：地址 为空（异常） → 输出：默认按外省算，22 元
最后两条异常必须记——AI 重构时最爱”顺手优化”的就是这些奇怪的边界处理。另外动手前做件五秒钟的事：把原文件复制一份改名 xxx_备份.txt 存着，它救过无数人。
第二步：闻（让 AI 先体检，不许动手）
很多人一上来就说”帮我重构”，这是错的。第一轮，只让 AI 诊断，明确禁止它给代码。 你要先知道这段代码有几个问题、哪个最严重，然后自己决定改哪个。诊断时让 AI 按六味对号入座，并按严重程度排序。
第三步：拆（一次只改一味）
看到 AI 列出六个问题，新手本能是”都改了吧”。千万别。 一次改六处，出问题你根本不知道是哪处引起的。一次只改一味，改完立刻验，验过再改下一味。
顺序建议从最安全的改起：
| 优先级 | 改什么 | 风险 | 收益 |
|---|---|---|---|
| 1 | 名（改命名） | 极低 | 立竿见影 |
| 2 | 魔（数字变常量） | 极低 | 高 |
| 3 | 重（合并重复） | 中 | 高 |
| 4 | 长 / 杂（拆函数） | 中 | 高 |
| 5 | 套（减少嵌套） | 中高 | 中 |
先改成命名和魔法数字——几乎不可能改坏，读起来立刻不一样，先尝甜头建信心。拆函数放后面，因为它动结构、风险更高。
第四步：验（每改一次就验一次）
拿出第一步那张快照表，四组全跑一遍，尤其那两条异常——它们最容易被”顺手删掉”。一致 → 通过，进下一味；不一致 → 立刻回退备份，别试图”再改改就好了”。
四、实战演练：一段”六味俱全”的代码
假设你手上有段处理订单的代码（语言不重要）：两百行函数叫 handle，普通用户折扣写死 0.95、会员 0.85，if 套 if 套 if 判断四层库存和地区，三段几乎一样的”算运费”只是数字不同，最后又发短信又写日志。六味占全了。
第一轮，你说：“只诊断，不要给代码。按六味列出问题并排序。” AI 会给体检报告：杂（严重）、魔（严重，0.95/0.85/3/7 含义不明）、重（中等）、名（中等）、套（中等）、长（中等）。
第二轮，你只说一句：“先只改【魔】这一项，把四个数字提成有名字的常量，其他一律不动，给完整文件。” 改完跑快照表，四组一致 → 通过。
第三轮：“再只改【名】……” 这个节奏才对。 看着慢，但每一步都安全、随时能停。而”一次全改”看着快，一出事你要花三倍时间找哪儿坏的。
五、四个必须知道的坑
坑一：让 AI “顺便优化一下”。 最危险的六个字。你说重构它只改结构；加一句”顺便优化”，它可能改了业务逻辑。重构时明确禁止 AI 改变任何功能，写进提示词。
坑二：只给片段。 你只贴那个 200 行函数，没贴调用它的地方。AI 把函数名从 handle 改成 processOrder——所有调用处全报错，因为它不知道谁在调。→ 改函数名前，先问”这函数在哪被调用”，或自己全局搜一下。
坑三：接受”看起来更简洁”的改动。 AI 特喜欢把五行压成一行，看着酷但读起来更费劲。重构目标是”更好懂”不是”更短”，改完你自己读着更吃力，就是失败。
坑四：没有快照表就开始改。 头号死因，再强调一次：没有验收标准的重构，不叫重构，叫赌博。
六、什么时候不该重构
三种情况别碰：
- 马上要上线——上线前一天动结构等于找刺激；
- 半年内不会再碰——重构是投资，要看回报；
- 完全看不懂在干嘛——先回第 69、74 篇让 AI 讲清楚，看不懂就改，坏了自己都不知坏哪。
三种情况值得改：
- 你每周都要打开这个文件
- 你准备在这加新功能
- 最近连着出过两次 Bug
重构最佳时机，是”你正要在这儿加东西”的前一刻——先扫地，再搬家具。
提示词模板盒子
模板一：代码体检（第一轮必用，只诊断不给码）
你是一位注重可维护性的资深工程师。
下面是我项目里的一段代码，我想改善它的可读性。
【本轮要求 · 重要】
1. 只做诊断，不要给我任何修改后的代码
2. 按以下六类"坏味道"对号入座：
- 长：函数过长 - 重：重复代码 - 名：命名不清
- 套：嵌套过深 - 魔：魔法数字 - 杂：单个函数职责过多
3. 按【严重程度】排序，每条注明：位置（第几行）| 具体问题 | 为什么是问题 | 预估改动风险（低/中/高）
4. 最后单独告诉我：你建议我第一个改哪一项，为什么
【代码】
（在此粘贴完整文件，不要只贴片段）
模板二：单点重构（一次只改一味）
接着上面的诊断。
【本轮只做一件事】
只修改【____】这一项问题，其他任何地方一律不动。
【铁律】
1. 严禁改变任何功能行为——输入什么，输出必须和原来完全一致
2. 严禁删除任何看起来"没用"的判断或分支（那可能是特殊业务处理）
3. 严禁"顺便优化"任何其他内容
4. 目标是更好懂，不是更短。不要为简洁牺牲可读性
【交付要求】
1. 给我完整文件，不要片段
2. 末尾用表格列出：改了哪几行 | 改成什么 | 为什么
3. 如果改动可能影响文件之外（如函数改名影响调用方），请明确警告我检查哪些位置
模板三：基线与验收（动手前建快照 + 改完对比）
下面这段代码，我准备重构它。
【第一部分 · 动手前：建立行为基线】
1. 列出所有输入参数及取值范围
2. 帮我设计 5 组测试用例，必须包含：2 组正常、2 组边界/异常（空值、0、超大值）、1 组最容易忽略的特殊分支
3. 每组写清：输入 | 预期输出
4. 指出有没有"看起来没用、但可能是特殊业务处理"的分支，单独标出提醒我别删
【第二部分 · 改完后：行为对比检查】
这是重构前的【A】和重构后的【B】。
1. 逐项确认 B 相对 A 有无任何功能行为变化
2. 特别检查：A 里哪个判断分支/异常处理/边界，在 B 里被弱化或删掉了
3. 有没有变量/函数被改名？有则列出提醒我检查调用方
4. 一句话结论：这是"安全重构"，还是实际已变成"重写"
【A - 重构前】
（粘贴）
【B - 重构后】
（粘贴）
下篇预告
这一篇我们只做了一件事：让代码变好读，一个字功能都没改。 可现实里代码不光要好读，还得跑得快——而这俩常打架。下一篇《第 78 篇：用 AI 做代码优化》讲”优化三问”与”提速四招”。下篇见。