接手一个跑了三四年的老项目打开核心模块的那一刻我盯着那坨三千多行的函数沉默了十分钟——缩进混乱、变量名从a排到z99、逻辑层层嵌套注释里赫然写着“这段代码我也不知道为什么能跑但别动它。”这大概是每个开发者都经历过的噩梦。正因如此Claude Code 团队最近开源了一个叫 code-simplifier 的项目专门干一件事用 AI 把这种屎山代码拆开、读懂、重写最后给你一份人能维护、行为不变的干净版本。这篇文章不聊虚的直接讲清楚 code-simplifier 到底是什么思路、怎么安装、提示词怎么写、哪些坑我踩过以及它到底值不值得你投入时间去试。标题里说“AI屎山代码有解了”这话一半对一半不对。对的是AI 确实能把“理解老代码”这件事的成本打下来一大截不对的是它解决不了所有问题更不是粘贴一个提示词就万事大吉。我花了两周时间在真实项目里拿它做重构今天把完整的过程、提示词模板、翻车记录和经验教训都整理出来给想用 Claude Code 清理遗产代码的同行一个参考。1. 先搞明白屎山代码为什么总是一坨接一坨1.1 屎山不是天生坏是滚出来的很多新人以为屎山代码是某个程序员写的垃圾其实绝大多数屎山都是“正常业务压力”的副产品。需求三天一变、上线时间倒排、团队人员流动每一轮改动都带着“能跑就行”的妥协先加个if兼容新逻辑再补个flag区分新旧行为后来者看不懂就再包一层。等第三个人接手时代码已经变成了一团相互缠绕的状态。这就是所谓的“破窗效应”——第一块垃圾扔进去之后后面所有人都会默认这里不需要讲究。代码的可读性一旦崩盘维护成本是指数增长的。改一个看似无关的函数可能引发三处隐性副作用测试一跑整个模块都红。这时候大家的第一反应不是重构而是“先别动它”。我在 code-simplifier 的试用过程中最直观的感受是AI 最大的价值不在于“删代码”而在于它愿意、也有能力把这段没人愿意看的历史遗留代码从头到尾读一遍并输出结构化的理解。对人来说读三千行乱糟糟的老代码要一整天对 Claude 来说也就是几次请求的工夫。1.2 传统重构为什么容易半途而废传统重构方案就那几样人工重写、IDE 自动提取函数、用静态分析工具扫描。每一招都有明显的天花板。人工重写成本最高风险也最大——你花两周重写完了业务方说“行为和原来有点不一样”重写代码和修复行为的双重成本直接翻倍。IDE 的自动重构工具只擅长处理局部小手术比如提取方法、重命名变量面对“整个函数逻辑混乱、分层错误、职责混在一起”这种结构性病变它们根本无能为力。静态分析工具倒是能找出重复代码、坏味道但它的输出是一份二十页的 PDF 报告然后呢还是要人去看、去改、去承担风险。市面上的方案缺的不是“发现问题”而是“给出能直接合并的修复”。这一点恰恰是 AI 的强项Claude Code 不仅能识别问题还能生成一整块重构后的代码并且用工具验证行为。1.3 换个思路让 AI 先读代码再动刀code-simplifier 这个项目给了我一个完全不同的思路。它不让你“一上来就让 AI 重构”而是拆成三层先分析、再简化、后验证。分析阶段让 AI 用自然语言描述这段代码到底是干嘛的、有哪些隐藏分支和副作用简化阶段才动手改代码验证阶段通过跑测试、对比行为来确认“行为没变”。这个思路非常关键。大多数人在让 AI 改代码时翻车都是因为跳过了第一步——你自己都没搞懂代码在干嘛却指望 AI 看一眼就能改对。而 code-simplifier 把这套流程固定下来让 AI 在没有完全理解之前不允许修改任何代码。这就是它区别于花哨“AI 重构工具”的核心。2. code-simplifier 到底做了什么2.1 一句话定位把重构变成标准化流水线如果要用一句话描述 code-simplifier我会说它是一个内置在 Claude Code 工作流里、专门用来简化旧代码的提示词工程框架加上配套的执行规范。它不像一个传统的“一键重构”插件更像一套作业指导书告诉 Claude 什么时候该读、什么时候该写、写完之后怎么自检。项目开源的价值在于这套提示词和流程是可以看、可以学、可以改的。你可以直接用官方给的默认提示词也可以把它调整成适合自己团队风格的版本。这意味着重构的经验不再锁在某个人的脑子里而是变成了一份团队资产。2.2 核心流程分析、简化、验证三层结构code-simplifier 的三层流程我整理成了这样一张工作清单阶段输入输出关键动作分析源代码文件、函数名、调用关系结构化代码说明、职责清单、潜在风险点禁止修改代码只输出理解简化分析结果、原始代码重构后代码、简化说明、改动清单小步重构、保留行为验证原始代码与重构后代码验证报告跑测试、diff 对比、逻辑核对每个阶段都对应不同的提示词模板和操作规范。分析阶段的核心是“只读不写”强迫 AI 先建立全局理解简化阶段的核心是“小块分割”一次只处理一个函数或一个职责而不是一股脑改写整个文件验证阶段则是拿测试和 diff 说话不让 AI 自己说了算。2.3 和其他“AI 一键重构”的本质区别我试过网上很多所谓的“AI 重构”提示词很多就是一句“帮我重构下这段代码让它更优雅”。这种提示词的问题在于没有给 AI 定义“什么是优雅”。Claude Code 这类模型执行任务时遵循的是指令里的显式约束。你说“更优雅”它可能把变量名全改成看起来很高级的写法把简单逻辑重构成过度抽象的工厂模式甚至顺手调整了函数的行为边界。code-simplifier 的提示词则明确告诉 AI不许改变外部行为、不许改变函数签名、不许删注释、不许一次改太多。另一个重要区别是验证驱动。code-simplifier 要求每一步改动都有验证手段这不只是对 AI 的要求也是对人工作流的约束。哪怕你完全不用它的提示词光是“先分析、后简化、再验证”这个三步框架就足够救回一批乱糟糟的模块。3. 实操从安装到第一次清理3.1 环境准备装好 Claude Code实操部分先讲环境。code-simplifier 是运行在 Claude Code 环境里的项目所以第一步是安装 Claude Code 本身。这个工具目前支持 macOS 和 LinuxWindows 用户建议通过 WSL 使用。前置依赖是 Node.js建议 18 及以上版本和 Git。安装命令就一行npm install -g anthropic-ai/claude-code装完之后在终端输入claude会进入交互式命令行界面。首次使用需要完成身份验证验证通过后就可以直接对话了。如果你平时用 VS Code 写代码也可以装 Claude Code 的 VS Code 扩展让 AI 直接读取编辑器里的文件操作起来更顺手。准备好 Claude Code 之后拉取 code-simplifier 项目本身git clone https://github.com/anthropics/code-simplifier.git项目里主要是一套 markdown 格式的提示词文件以及配套的工作流说明。你不需要运行什么构建脚本核心用法就是把这些提示词复制到 Claude Code 的对话里跟着流程走。3.2 第一步先备份把行为测试跑通很多人拿到这个工具的第一个冲动是直接丢一个文件进去让 AI 重构。千万别这么干。我先说一个所有重构操作通用的铁律动手之前先确认你手里有一张“行为基线”——也就是改动之前代码是正常工作的证据。具体操作分两步。第一步把要重构的模块对应测试全部跑一遍记录下通过率如果项目测试覆盖率几乎为零那就自己写几个关键场景的冒烟测试哪怕只覆盖主链路也行。第二步用 Git 开一个新分支保证随时可以回滚。我在一个老项目的支付模块上做第一次尝试时就是没跑基线直接让 AI 改结果改完发现一个边界情况的行为变了排查了一下午才定位到是 AI 少写了一行空值判断。从那以后我养成了习惯任何重构先跑测试再动手。3.3 分析阶段让 AI 交出“代码解剖报告”环境就绪、基线建立之后正式开始用 code-simplifier。先把项目里的分析提示词拿过来让 AI 对目标文件做一次“只读诊断”。这里我把核心提示词分享出来这个也是整个项目里我最看重的一段你是一名资深软件架构师。请对以下代码文件做一次结构分析但绝对不要修改任何代码。分析输出必须包含 1. 文件整体职责用3-5句话说明这个文件在系统里扮演什么角色 2. 每个函数/方法的职责清单列出函数名、输入参数、返回值、主要副作用 3. 重复或冗余逻辑列出具体位置和它们之间的关系 4. 隐藏耦合点例如对全局变量、外部服务、静态方法的隐式依赖 5. 风险清单指出哪些地方改动最容易引发行为变化 6. 简化建议按优先级列出可以合并、删除、拆分的具体位置。 输出格式一律使用Markdown。如果信息不足请先向我提问而不是猜测。这个提示词的设计思路很清晰它把“分析”和“修改”用一条命令隔开了。你如果只是简单说“帮我看看这段代码”AI 大概率会顺手提出修改建议甚至直接改但有了这个约束它会老老实实先输出结构化文档。我把一个复杂的优惠券计算模块喂给 Claude 之后它输出了一份两百多行的分析报告里面有一条让我印象极其深刻“函数 C 内部实际执行了两种互斥的优惠策略分别由两个全局配置项控制但二者从不被同时启用建议拆分。”这是我之前看代码时都没意识到的隐藏耦合。这就是分析阶段的价值——让 AI 当那个愿意读文档的人。3.4 简化阶段按函数、按模块分批重写分析报告拿到手下一阶段才是重写。code-simplifier 的简化提示词强调“小步重构”。我调整后的版本长这样基于上一轮的结构分析结果现在对代码执行简化重构。要求如下 1. 每次只处理一个函数或一个独立逻辑块处理完立即停下不要连续修改多个位置 2. 保持外部行为完全不变不改变函数签名、不改变返回值的结构、不改变对外部服务的调用方式 3. 可以合并重复逻辑、可以提取局部变量、可以简化嵌套条件 4. 删除无用参数和死代码但必须在改动清单里登记 5. 保持原有的注释风格如果代码逻辑有变化更新注释说明 6. 输出格式先给出改动清单再给出改动后的完整代码块 7. 不要使用设计模式强行重构简单直接的代码优先。 现在从分析报告里优先级最高的第一项开始。注意第 4 条和第 5 条很多人写提示词会忽略这两条。删除死代码是这次重构里最敏感的操作——你以为是死代码可能只是某个老接口还在调保持注释风格是为了让最后的代码 diff 不至于乱到人没法 review。我在实际使用时发现明确要求“处理完一个就停下”能显著减少 AI 自作主张连续改多处导致的批量事故。关于执行方式我喜欢用/add把目标文件加入 Claude Code 的上下文然后让它直接在当前工作区里改动文件。改了第一个函数之后先看 diff确认没问题再让它往下走。整个支付模块分了十几次才改完每次改动量控制在几十行以内。3.5 验证阶段用 diff 和行为测试兜底最后一层是验证。每次 AI 改完一个函数我都让它运行测试并把结果贴回来。这里要特别注意Claude Code 是有工具调用能力的你可以让它直接执行命令但它执行完之后你要亲眼看到输出别只看它总结的“通过”。验证还有个容易被忽略的动作——diff 审查。AI 改完代码之后我会把它和原代码放在一起逐行比对。重点看两处一是它有没有顺手改了外部接口二是它有没有删掉看似冗余实则重要的防御性代码。有一次 AI 把一段try...catch里的空的catch块删了理由很充分“这个异常被吞掉了删除以简化逻辑”。可问题是那个空 catch 是上游系统抛错时的“有意的静默”删掉之后异常会导致服务直接 500。要不是 diff 审查发现得快这个事故就到生产环境了。4. 提示词设计的几个关键技巧4.1 给 AI 设定“先读后写”的顺序约束为什么很多 AI 重构翻车因为模型默认的行为模式是“读到代码就开始思考怎么改”。你要想让它按你的节奏走就得在提示词里显式规定动作顺序——先读、再输出理解、等你确认、然后才能改。这个“先读后写”的约束是 code-simplifier 整个理念里最值得偷师的一招。用大白话解释一下模型的行为机制大语言模型在生成本次回复时是对整段对话做概率预测的。如果你上来就说“帮我重构”它没有理由停下来先做分析。但如果你在提示词里明确写出“第一轮不要改代码只输出分析并且在分析完成之前禁止提出修改建议”它就能把“分析”这个动作当作一个独立任务完成。这就是提示词工程的价值。4.2 输出格式要强制结构化我给 AI 的提示词里每个阶段都强制要求 Markdown 结构化输出——列表、表格、代码块。这不是为了好看而是为了让你能快速审阅它的判断依据。AI 输出的结构越清晰你越容易在它跑偏的第一时间发现问题。比如在分析阶段我要求它必须列出“风险清单”和“简化建议优先级”。这样我拿到手的不是一段散文而是一张可以照着执行的清单。在简化阶段我要求它先给“改动清单”再给“代码块”这样我 review diff 时知道它预计动了哪些位置对照起来快很多。4.3 踩过几次坑之后总结出来的“边界约束”提示词里最容易忽略的是“负面约束”——明确告诉 AI 什么不要做。网上很多人写提示词只写“做什么”不写“不做什么”结果 AI 自由发挥的空间太大。code-simplifier 的提示词里值得借鉴的负面约束有这么几条“不要改变函数签名”是底线AI 一旦改了签名所有调用方全部跟着坏“不要同时修改测试代码”是纪律不然你没法区分是测试问题还是代码问题“不要删除注释”是文化AI 倾向于把注释当作冗余信息清理掉但老代码里很多注释是业务规则的口头传承。我还尝试过一个有意思的验证方法思路接近所谓的“鹈鹕测试”——用一些反差极大的指令去测试模型是真的读懂了代码还是在机械地套模板。比如在分析报告出来后我故意追问一句“如果把函数 A 和 B 合并会不会引入循环依赖”如果 AI 能结合前面输出的分析报告给出合理解释说明它确实是按上下文在思考如果它含糊其辞那说明刚才的分析报告大概率是套话。这个测试不一定每个项目都要做但对那些特别重要、改动风险特别高的模块值得多花一分钟试探一下 AI 的理解深度。5. 常见问题与排查实录5.1 问题排查速查表用 code-simplifier 写了两周和同事交流下来大家踩的坑高度集中。我整理了一份排查表按场景列出症状、原因和解决办法症状可能原因解决办法重构后测试大面积失败AI 改变了函数签名或外部行为回滚到改动前检查 diff 里接口相关的修改AI 太保守几乎没改动负面约束太多限制了它的动作放宽“不改变 xx”限制改为“尽量保持 xx 不变”AI 太激进引入复杂设计模式简化提示词里缺少“简单优先”声明在提示词里加入“禁止引入新依赖优先用普通函数”处理大文件超时上下文窗口被撑爆用 split 命令让 AI 只看部分函数而不是整个文件改完代码出现新 bug 但测试全绿测试覆盖率不足没覆盖隐藏分支先补测试再重构对关键模块使用行为对比验证5.2 两次真实翻车经历第一次翻车在支付模块。我让 AI 简化一个处理退款状态的函数加了“保持外部行为不变”的约束。结果 AI 确实没改签名但把内部一个“退款失败时给用户发邮件”的副作用逻辑当成了“冗余日志”删掉了。因为这个副作用在单测里没有断言测试依然全绿。最后是同事在 code review 时发现邮件逻辑不见了才拦截下来。教训就是对老代码凡是你自己都不确定是不是冗余的逻辑先当它不是冗余。第二次翻车在处理一个超大函数时。那个函数有近两千行AI 在单次对话里处理到一半就乱了开始重复修改已经改过的部分。我后来总结出门道遇到大函数先用分析提示词让它输出“函数内部逻辑分段”再按段落拆成多个小任务每个任务单独处理。相当于先让 AI 画地图再按照地图一块一块拆迁而不是整个楼一次性爆破。6. 用下来的几点实在体会6.1 这东西到底能省多少时间我的真实感受是省的不是“写代码的时间”而是“读代码的时间”。以前做一个模块的重构至少有一半精力花在理解一个没人愿意解释的老逻辑上。现在把分析任务丢给 AI让它输出结构说明和风险清单这个前置工作时间从一两天压缩到几小时。后续的代码修改本身AI 也比我预期干得干净利落——只要提示词约束到位产出的代码风格相当统一比我见过的很多外包代码都规整。6.2 什么情况下别用它也不是所有代码都适合用 code-simplifier。我建议避开这几类一行注释都没有且逻辑完全无法从命名和结构推断的代码AI 读不懂你也读不懂直接重写可能比简化更划算涉及极其复杂业务规则且没有任何测试保护的代码风险实在太高先补测试再谈重构还有就是运行环境非常敏感、不允许一点行为波动的代码比如支付结算、风控引擎这类AI 改完你敢不敢上生产这个问题得先问自己。6.3 还能怎么扩展code-simplifier 的框架不仅仅是用来“简化屎山”的稍微改一改提示词就能用来做别的事。比如把分析阶段的输出对接成技术文档让 AI 给每个老模块生成一份持续更新的文档或者把简化阶段的目标从“减少代码量”改成“抽出公共函数”就能顺手把重复代码消除一波。如果你用的是其他模型也可以尝试把这套提示词迁移过去——只要底层模型支持足够的上下文长度和工具调用能力三层流程的思路是完全通用的。我试过替换底层模型效果因模型而异但 Claude 在长代码理解和遵守复杂指令方面的表现确实更稳定一些。最后再唠一句四天code-simplifier 不是银弹它最值钱的部分不是帮你删代码而是逼着你把“梳理结构”这件事标准化了。现在我的团队已经形成规矩每个模块重构前先让 AI 输出一份“代码解剖报告”讨论报告、确定优先级、再动手。这个过程本身就已经把一堆屎山挡在门口了。