1. 老旧代码重构为什么总在重复劳动里打转如果你维护过一个三年以上的项目大概率经历过这种循环发现一批回调嵌套、重复判空、过时 API 调用手动改几个文件改到第五个就烦了剩下的先记在 TODO 里然后就没有然后了。下次再打开代码还是老样子技术债越滚越大。Claude Code 能做什么它可以在本地工程里读取文件、理解上下文、批量改写代码并且把改动落到磁盘上。适合谁适合手里有历史项目、想批量清理重复模式但又不想全量重写的开发者。核心检索词就三个Claude Code、批量重构、老旧代码。我试过在一个约 8 万行的 Node.js 老项目里做这件事目标很明确把回调风格的异步代码批量改成 async/await同时清理重复三次以上的工具函数。整个过程不是“一键重构”而是“配置好环境 → 拆任务 → 批量执行 → diff 审查 → 测试验证”的闭环。下面把可复制的配置和验证动作完整写出来。2. 前置准备TaoToken 接入与 settings.json 骨架Claude Code 本身是一个命令行工具它需要模型服务来驱动。这里用 TaoToken 作为模型接入层官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。先拿到 API Key再配置到 Claude Code 的 settings.json 里。2.1 获取 API Key 与确认接入信息打开控制台页面 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建一个 API Key。然后在 API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 复制出来。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的端点说明和参数格式。注意API Key 只显示一次复制后存到本地环境变量或密码管理器里不要直接提交到 Git 仓库。2.2 settings.json 配置片段Claude Code 的配置文件通常放在项目根目录的.claude/settings.json或者用户级的~/.claude/settings.json。下面是一个可复制的最小骨架把YOUR_API_KEY替换成你实际拿到的 Key{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY }, permissions: { allow: [ Read, Write, Edit, Bash(git diff:*), Bash(git status:*), Bash(npm test:*), Bash(npx jest:*) ], deny: [ Bash(rm -rf:*), Bash(git push:*) ] }, model: claude-sonnet-4-20250514 }几个关键点解释一下。ANTHROPIC_BASE_URL指向 TaoToken 的 API 端点这样 Claude Code 的请求会走这个入口。permissions.allow里放的是重构过程中需要用的命令读文件、写文件、编辑、看 diff、跑测试。permissions.deny里禁掉rm -rf和git push防止批量操作时误删或误推。模型名按你实际可用的填这里只是示例。如果你用的是 Claude Code 的 Coding Plan 模式做长期编码任务可以在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 看套餐说明适合需要连续多轮重构的场景。2.3 备份与工作区清理动手之前先做两件事。第一创建一个带时间戳的备份分支git checkout -b backup/pre-refactor-$(date %Y%m%d-%H%M%S) git add -A git commit -m backup before batch refactor git checkout main第二确保工作区干净git status如果有未提交的更改先提交或 stash。这样即使批量重构出问题也能用git reset --hard回到安全状态。3. 批量重构的配置与任务拆分配置好环境之后不要直接对整个代码库下指令。先切出一个“手术区”再拆成可验证的小任务。3.1 选取试点模块试点模块要满足三个条件业务逻辑相对独立、依赖关系清晰、包含足够多的待优化模式。比如在一个老电商项目里我选了src/utils/order-status.js和src/services/points-calc.js这两个文件。它们不依赖外部服务但里面有大量回调嵌套和重复判空。用命令确认试点范围find src/utils src/services -name *.js | head -203.2 批量重构提示词模板Claude Code 的提示词要结构化包含识别规则、替换目标、约束条件三部分。下面是我实际用的模板你可以直接复制修改请扫描 src/utils 和 src/services 目录下所有 .js 文件。 识别规则 1. 所有使用 function(err, result) 形式的回调函数且嵌套超过两层的代码块。 2. 重复出现超过三次的相似判空逻辑如 if (x ! null x ! undefined)。 替换目标 1. 将回调嵌套重构为 async/await 写法用 try-catch 包裹异常处理。 2. 将重复判空提取为公共函数 isEmpty(value)放在 src/utils/validate.js 中。 约束条件 - 保持原有业务逻辑判断不变仅改变语法结构。 - 若回调中包含 this 的特殊指向保留原样并添加 // TODO: 需人工审查 this 指向 注释。 - 不要修改函数签名和导出方式。 - 每处理完一个文件运行该文件对应的单元测试。 - 如果某个文件的改动超过 50 行暂停并输出 diff 供人工确认。这个模板的关键在于“不做什么”写得和“做什么”一样清楚。AI 不会盲目改写遇到不确定的地方会留 TODO。3.3 分批执行策略不要一次性让 Claude Code 处理所有文件。按目录分批每批不超过 5 个文件。执行命令claude 按照 .claude/refactor-prompt.md 中的规则处理 src/utils 目录下的文件处理完一批后立即看 diffgit diff --stat git diff src/utils/order-status.js如果 diff 行数异常大或者出现了你不认识的改动先回滚这一批git checkout -- src/utils/然后修正提示词增加反例说明再重新执行。4. 验证请求与成功结果重构做完不等于结束必须用测试和 diff 双重验证。4.1 运行测试命令假设项目用的是 Jest先跑试点模块的测试npx jest src/utils/order-status.test.js --verbose npx jest src/services/points-calc.test.js --verbose如果测试通过再跑全量测试确认没有连带影响npm test我实测下来回调改 async/await 之后最容易出问题的地方是错误处理路径。原来回调里的if (err) return callback(err)被改成catch (e) { throw e }之后有些测试用例会暴露异常类型不匹配的问题。这时候不要改测试而是回去看重构后的代码是否真的保持了原语义。4.2 用 diff 做语义审查测试通过不代表语义没漂移。用 diff 逐行看关键文件git diff --word-diff src/utils/order-status.js重点看三类改动被删除的判空逻辑、被合并的重复代码、被标记 TODO 的地方。如果发现 AI 删掉了某个业务场景下必须保留的防御性代码手动加回来并在提示词里补充这个反例。4.3 量化对比重构前后可以跑一下静态分析看圈复杂度的变化。以 ESLint 为例npx eslint src/utils/order-status.js --format json | jq .[0].messages | length更直观的是看函数平均行数和嵌套层级。我那个项目里order-status.js从 340 行降到 210 行最大嵌套从 6 层降到 3 层。这些数字不是目的但能帮你判断重构是否真的减少了理解成本。5. 本篇常见错排查批量重构过程中有几个坑几乎每次都会遇到。5.1 报错Permission denied for Bash command原因settings.json 的permissions.allow里没有放行对应命令。比如你想跑npx jest但只允许了npm test。解决在 allow 列表里加上Bash(npx jest:*)或者直接用npm test。改完 settings.json 后重启 Claude Code 会话。5.2 报错API key not valid 或 401原因ANTHROPIC_API_KEY没填对或者环境变量被 shell 里的旧值覆盖了。解决先确认 settings.json 里的 Key 和 TaoToken 控制台里的一致。然后在终端里检查echo $ANTHROPIC_API_KEY如果输出为空或不对说明 shell 环境变量没生效。可以在~/.bashrc或~/.zshrc里显式 export或者只依赖 settings.json 里的配置。5.3 重构后测试通过但线上出问题原因AI 改变了边缘情况的处理逻辑而测试用例没覆盖到。解决在提示词里增加“保留所有原始边界判断”的约束并且在 diff 审查时重点看if条件的变化。对于核心业务文件不要批量处理改成单文件逐个确认。5.4 Claude Code 处理到一半卡住原因单次任务太大或者某个文件的改动触发了权限拒绝。解决按目录拆小批次每批不超过 5 个文件。如果卡在某个文件先跳过它处理完其他文件后再单独看这个文件的 diff。也可以在提示词里加一句“如果某个文件无法处理输出原因并继续下一个”。5.5 diff 里出现大量格式化改动原因AI 顺手改了缩进或引号风格导致 diff 噪音太大。解决在项目根目录放一个.prettierrc或.editorconfig并在提示词里加“不要修改代码格式只改逻辑结构”。如果已经产生了格式噪音用git diff -w忽略空白差异来看真实改动。6. 把批量重构变成可重复的工程动作整套流程跑通之后你会发现 Claude Code 的价值不在于“一次改多少”而在于“每次改都能验证”。settings.json 管住权限边界提示词模板管住改动范围diff 和测试管住结果质量。这三样配齐批量重构就从“碰运气”变成了可重复的工程动作。如果你要接入更多模型做对比验证可以在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 直接试不同模型对同一段老旧代码的重构效果。长期做编码和 Agent 任务的话Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有更连续的额度方案。Claude Code 相关的接入细节在文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 管理。最后留一个实用习惯每次批量重构前把提示词模板和 settings.json 一起提交到仓库的.claude/目录。下次换人接手或者三个月后你自己再跑直接复用这套配置不用重新踩一遍坑。