环境配置 & 模型选择
开始前确认 Claude Code 安装、版本及模型配置。对于 300 万行代码库，模型选择直接决定重构质量。
本步骤目标：确认 Claude Code 可用，选择合适模型，建立 Git 安全基线，确保后续所有操作有回滚保障。
安装与验证
TERMINAL安装 Claude Code
npm install -g @anthropic-ai/claude-code
# 验证安装
claude --version
# 进入项目目录
cd /your/project/root
# 启动 Claude Code
claude
模型选择指南
| 代码库规模 | 推荐模型 | 上下文窗口 | 适用场景 |
|---|---|---|---|
| < 10万行 | Sonnet 4.6 | 200K tokens | 单模块重构，日常修改 |
| 10–100万行 | Sonnet 4.6 + 分批 | 200K tokens | 必须配合严格的分批策略 |
| > 100万行（当前） | Opus 4.6（企业版） | 100万 tokens | 跨模块架构分析，最优选择 |
TERMINAL切换模型（Claude Code 内）
# 在 Claude Code 会话中切换模型
/model opus # 使用 Opus 4.6（企业版推荐）
/model sonnet # 使用 Sonnet 4.6（预算有限时）
Git 安全基线
每一步重构前必须确保 Git 状态干净，所有工作在独立分支进行。这是可以无损回滚的唯一保障。
TERMINAL建立安全基线
# 确认当前状态干净
git status
# 创建重构基础标签（随时可以回到这里）
git tag refactor-baseline-$(date +%Y%m%d)
# 创建重构主分支
git checkout -b refactor/main
# 推送到远程
git push origin refactor/main
完成检查
Claude Code 已安装并可正常启动（claude --version 有输出）
已确认使用模型：Opus 4.6 企业版 / Sonnet 4.6（根据预算选择）
Git 状态干净，已创建 refactor-baseline 标签
已切换到独立的 refactor/main 分支
CLAUDE.md 初始化
CLAUDE.md 是整个重构过程的"大脑"。它在每次会话开始时自动加载，消除了重复解释代码库结构的需要，是最重要的配置文件。
本步骤目标：创建包含完整项目上下文的 CLAUDE.md，让每次会话都能在正确的认知基础上开始工作。
第一步：让 Claude Code 分析项目结构
先让 Claude 自动分析，再手动补充业务上下文。不要完全手写，效率太低。
CLAUDE CODE自动生成 CLAUDE.md 草稿
分析当前项目结构，为我生成一个 CLAUDE.md 草稿文件。
要求包含以下内容：
1. 项目技术栈（语言、主要框架、运行时版本）
2. 目录结构概览（只到两级，不要太细）
3. 构建命令、测试命令、代码风格检查命令
4. 主要模块列表（列出 src/ 下的主要子目录及其职责描述）
不要修改任何代码，只生成 CLAUDE.md 文件。
第二步：手动补充关键业务信息
在 Claude 生成的草稿基础上，添加只有你知道的信息：
📄 CLAUDE.md — 必须手动补充的部分
# ⚠️ 禁止触碰区域（不得修改）
- `/legacy/core/critical_path.*` — 生产关键路径
- `/db/migrations/` — 只能添加，不能修改已有文件
- `/config/production.*` — 生产环境配置
# 重构优先级
## 高优先级（先做）
- [ ] /auth/token.js — 安全漏洞，圈复杂度 22
- [ ] /payment/processor.js — 无测试，6年无人维护
## 中优先级
- [ ] /user/service.js — 重复代码严重
- [ ] /api/routes.js — 路由层职责混乱
## 低优先级（最后做）
- [ ] /utils/ — 工具函数，风险低
# 重构规范（每次会话必须遵守）
1. 每修改一个文件，立即运行该文件的测试
2. 不确定业务逻辑时，停下来提问，不要猜测
3. 保持外部接口不变（函数签名、API 路径）
4. 每个功能点完成后 git commit 一次
# 当前已知的坑
- auth 模块依赖一个未文档化的全局变量 `__LEGACY_SESSION`
- payment 模块有循环依赖问题（payment → order → payment）
- 所有日期处理都用了废弃的 moment.js，迁移到 dayjs
第三步：验证 CLAUDE.md 被正确加载
CLAUDE CODE验证提示词
根据 CLAUDE.md，告诉我：
1. 本项目的技术栈是什么？
2. 哪些目录是禁止修改的？
3. 当前重构的最高优先级模块是哪个？
不要读取其他文件，只基于 CLAUDE.md 回答。
完成检查
CLAUDE.md 已在项目根目录创建
已补充禁止触碰区域、重构优先级、已知的坑
验证 Claude Code 能正确读取并理解 CLAUDE.md 内容
CLAUDE.md 已提交到 Git
子智能体配置
子智能体在独立上下文中运行，是应对 300 万行代码库最关键的上下文管理工具。它们探索代码、读取文件，完成后只向主会话报告摘要，保持主会话干净。
本步骤目标：创建可复用的子智能体配置，用于探索、重构和验证三类任务，避免大量文件读取污染主会话上下文。
创建目录结构
TERMINAL创建子智能体目录
mkdir -p .claude/agents
子智能体 1：模块探索
📄 .claude/agents/explore-module.md
---
name: explore-module
description: 探索指定模块，生成分析报告，不修改任何文件
---
接收模块路径作为参数，执行以下分析：
1. 列出模块内所有文件及行数
2. 识别主要依赖关系（import/require 分析）
3. 找出复杂度最高的前5个函数（估算圈复杂度）
4. 识别重复代码块（超过10行的相似代码）
5. 统计测试覆盖率（如果有测试文件）
6. 列出所有对外暴露的接口（exports）
输出格式：简洁的 Markdown 报告，总结关键问题，不输出完整代码。
禁止修改任何文件。
子智能体 2：安全重构执行器
📄 .claude/agents/refactor-safe.md
---
name: refactor-safe
description: 对单个文件执行安全重构，每步运行测试验证
---
接收文件路径和重构目标作为参数，执行以下流程：
1. 读取文件，理解当前实现
2. 检查是否有对应测试文件
3. 如果没有测试，先生成特征化测试并运行通过
4. 执行重构（一次只改一件事）
5. 运行测试，确认全部通过
6. 如果测试失败，回滚变更并报告原因
7. 输出变更摘要（改了什么，为什么这么改）
规范约束：
- 保持函数外部签名不变
- 每次重构只针对一个问题（复杂度/重复/命名）
- 遇到不确定的业务逻辑，停止并说明疑问
子智能体 3：质量验证器
📄 .claude/agents/verify-quality.md
---
name: verify-quality
description: 对已重构的模块进行质量验证
---
接收模块路径作为参数，执行以下验证：
1. 运行所有测试（单元测试 + 特征化测试），汇报通过率
2. 运行 linter，列出新增的 warning（与 main 分支对比）
3. 检查函数长度：找出仍然超过50行的函数
4. 检查圈复杂度：找出仍然超过10的函数
5. 检查是否有硬编码的魔法数字或字符串
6. 输出通过/失败摘要表格，不输出完整代码
判断标准：
- ✅ 所有测试通过
- ✅ 无新增 linter 错误
- ⚠️ 有新增 warning（可接受但需说明）
- ❌ 有测试失败（必须修复后才能继续）
验证子智能体配置
CLAUDE CODE测试子智能体
使用 explore-module 子智能体，分析 src/ 目录下最大的那个子模块。
只输出分析报告摘要，不要读取项目中的其他文件。
完成检查
已创建 .claude/agents/ 目录
三个子智能体配置文件均已创建
测试调用 explore-module 子智能体成功，主会话上下文保持干净
代码库全景扫描
在不修改任何代码的情况下，对整个代码库进行深度分析，建立重构所需的全局认知。这一步是后续所有决策的基础。
本步骤严禁修改任何代码文件。所有操作必须是只读分析。如果 Claude Code 试图修改文件，立即用 Esc 取消。
本步骤目标：生成 REFACTOR_PLAN.md，包含模块地图、依赖关系、测试覆盖率现状和过期依赖清单。
全景扫描提示词
CLAUDE CODE主扫描命令（使用子智能体）
使用子智能体并行探索以下四个维度，不要修改任何文件，禁止执行写入操作：
子智能体1 - 结构分析：
- 列出 src/ 下所有模块（目录），每个模块的文件数量和总行数
- 识别明显的架构模式（MVC/分层/领域驱动）
子智能体2 - 复杂度热点：
- 找出行数最多的前20个文件
- 识别函数超过100行的文件
- 找出有明显重复代码的模块
子智能体3 - 测试覆盖：
- 统计有测试文件的模块 vs 没有测试的模块
- 列出完全没有测试的核心模块
子智能体4 - 依赖健康：
- 读取 package.json / requirements.txt / pom.xml
- 列出超过3年未更新的依赖
- 识别已知安全漏洞的依赖版本
所有结果汇总输出为 REFACTOR_PLAN.md 文件。
补充：深度分析特定区域
CLAUDE CODE针对可疑模块深挖
使用 explore-module 子智能体，深度分析 [替换为你的高风险模块路径]。
重点关注：
1. 这个模块被哪些其他模块依赖？（被依赖越多，重构风险越高）
2. 有没有循环依赖？
3. 有没有全局状态或单例？（这些最难重构）
4. 外部接口有多少个？（接口越多，需要保持兼容的约束越多）
不要修改任何文件，只输出分析报告。
完成检查
REFACTOR_PLAN.md 已生成，包含模块地图和复杂度热点
已识别无测试覆盖的核心模块（高风险区域）
过期依赖清单已整理
整个分析过程没有修改任何代码文件（git status 干净）
技术债务评分
基于扫描结果，对每个模块进行量化评分，确定重构顺序。避免凭直觉决定先做什么——数据说话。
本步骤目标：生成模块优先级排名表，确定未来几个月的重构顺序。优先选择高风险、低难度的模块。
评分提示词
CLAUDE CODE生成技术债务评分表
基于 REFACTOR_PLAN.md 中的分析结果，对每个模块进行技术债务评分。
评分维度（各1-5分）：
- 安全风险：有无已知漏洞、权限绕过可能性
- 维护成本：代码复杂度、文档缺失程度、理解难度
- 业务影响：该模块故障对用户的影响范围
- 重构难度：依赖数量、测试覆盖率、接口复杂度
计算优先级分数 = (安全风险 + 维护成本 + 业务影响) / 重构难度
分数越高 = 越应该先做
以 CSV 格式输出结果：
模块路径,安全风险,维护成本,业务影响,重构难度,优先级分数,建议处理顺序
同时给出文字建议：
- 应该立即处理的前3个模块（原因）
- 暂时跳过的模块（原因）
- 需要特别注意的风险点
优先级决策规则
| 情况 | 决策 | 理由 |
|---|---|---|
| 高风险 + 低难度 | ✅ 立即处理 | 最高性价比，快速降低整体风险 |
| 高风险 + 高难度 | ⚠️ 计划处理 | 需要专项项目，单独立项 |
| 低风险 + 低难度 | 📅 排期处理 | 可批量处理，放入常规迭代 |
| 低风险 + 高难度 | ❌ 暂时跳过 | 投入产出比最低，暂缓 |
完成检查
所有模块已完成评分，评分表已保存
已确定前5个优先处理的模块
REFACTOR_PLAN.md 已更新优先级信息，并提交到 Git
生成特征化测试
特征化测试是重构的"安全气囊"。它们记录代码当前的实际行为（不管好坏），如果重构意外改变了行为，测试会立即报警。这是触碰代码前必须完成的工作。
注意：特征化测试不验证"正确性"，只验证"一致性"。即使当前代码有 bug，测试也要记录这个 bug 的行为——重构完成后行为应该保持不变。
本步骤目标：为优先级最高的模块生成完整的特征化测试，确保测试全部通过，然后才能开始修改代码。
为单个模块生成特征化测试
CLAUDE CODE特征化测试生成（按模块执行）
为 [替换为模块路径，如 src/services/PaymentService.js] 的所有公共方法生成特征化测试。
测试规范：
1. 测试目标是记录当前行为，不是验证正确性
2. 每个公共方法至少需要以下测试用例：
- 正常输入的正常路径
- null / undefined 输入
- 空字符串 / 空数组 / 0 等边界值
- 预期会抛出异常的情况
3. 测试文件命名：在原文件名后加 .characterization.test.js
4. 使用现有的测试框架（查看 package.json 确认）
5. 每个测试加上注释：// CHARACTERIZATION: 记录当前行为
生成测试后，立即运行测试确认全部通过。
如果发现测试无法通过（说明当前代码本身有问题），
停止并向我报告，不要自动修复。
批量生成测试（多个无测试模块）
CLAUDE CODE批量特征化测试
使用并行子智能体，为以下模块分别生成特征化测试：
（每个子智能体处理一个模块，互不干扰）
- src/services/UserService.js
- src/utils/DateHelper.js
- src/middleware/AuthMiddleware.js
每个子智能体完成后汇报：
- 生成了多少个测试用例
- 测试运行结果（通过/失败数量）
- 是否发现了当前代码的 bug（测试无法通过的情况）
最终汇总报告：哪些模块已有完整测试防护网，可以开始重构。
完成检查
所有待重构模块都有特征化测试文件（*.characterization.test.*）
所有特征化测试均通过（运行 npm test 确认）
测试文件已提交到 Git（作为重构前的基准快照）
验证 CI 门控
测试防护网需要 CI 自动化来保证每次提交都运行验证。手动运行测试很容易遗漏——CI 不会。
本步骤目标：确保 CI 流水线正确运行特征化测试，并配置失败时阻止合并。这是整个重构过程的自动护栏。
生成 CI 配置
CLAUDE CODE生成 CI 流水线
为本项目生成 CI 配置文件，用于在每次 Push 时自动验证重构质量。
要求：
1. 运行所有单元测试（包括 .characterization.test.* 文件）
2. 运行 linter，发现错误时 CI 失败
3. 检查是否有新增的函数超过50行（警告，不失败）
4. 输出测试覆盖率报告
根据项目实际使用的 CI 系统生成配置：
- 如果是 GitHub Actions：生成 .github/workflows/refactor-guard.yml
- 如果是 GitLab CI：生成 .gitlab-ci.yml 中的相应 job
- 如果是 Jenkins：生成 Jenkinsfile 片段
生成后告诉我如何验证 CI 配置是否正确。
完成检查
CI 配置文件已创建并提交
CI 已成功运行一次（所有测试通过的绿色状态）
已确认：测试失败会阻止 PR 合并
上下文窗口策略
上下文窗口是重构过程中最重要的资源。学会主动管理它，而不是被动等待它耗尽。
本步骤目标：掌握上下文管理的三个核心命令，建立每次会话的标准操作流程，避免上下文耗尽导致的错误。
核心命令速查
| 命令 | 作用 | 使用时机 |
|---|---|---|
| /compact | 压缩历史，保留关键信息 | 完成一个文件后；感觉响应变慢时 |
| /clear | 彻底清空上下文 | 切换到完全不同的任务时 |
| /status | 查看当前上下文使用量 | 随时查看，接近80%时主动压缩 |
每次重构会话的标准流程
📋 标准会话 SOP（每次执行重构前阅读）
开始前：
1. 新建一个 Git feature 分支
git checkout -b refactor/[模块名]-[日期]
2. 确认上下文干净（如果是新任务，先 /clear）
3. 明确本次会话只做一件事
执行中：
4. 每完成一个文件 → 运行测试 → git commit
5. 感觉上下文超过 60% → 主动 /compact
6. 遇到不确定 → 停下来问，不要让 Claude 猜
结束时：
7. 运行完整测试套件，确认通过
8. 开 PR，让 CI 跑验证
9. /clear 准备下一个任务
会话开始的标准提示词
CLAUDE CODE每次会话开始时发送
本次会话目标（只做这一件事）：
重构 [替换为具体文件路径]
约束：
- 保持所有公共接口不变
- 每修改完一个函数立即运行测试
- 遇到不确定的业务逻辑，停下来告诉我，不要猜
- 不要读取 CLAUDE.md 以外的配置文件（除非必要）
开始前，先告诉我：
1. 你打算如何分步骤进行？
2. 有什么需要我确认的前提条件？
完成检查
已理解 /compact 和 /clear 的使用时机
已记住会话 SOP（开始/执行/结束三个阶段）
已准备好第一个重构目标（来自优先级表）
单模块重构执行
这是真正动刀的阶段。每次只重构一个模块（5-20个文件），配合测试验证，逐步推进。以下是针对最常见重构类型的专用提示词。
本步骤目标：完成第一个高优先级模块的重构，建立可重复的执行模式，为后续批量重构奠定基础。
类型1：降低圈复杂度
CLAUDE CODE复杂函数拆分
分析 [文件路径] 中的函数，找出圈复杂度最高的那个。
执行步骤：
1. 展示该函数及其当前复杂度（不要展示其他部分）
2. 提出拆分方案（展示拆分后的函数签名列表，等我确认）
3. 确认后执行重构，每个子函数拆出后立即运行测试
4. 完成后对比：原函数复杂度 → 重构后最高复杂度
约束：
- 拆出的子函数如果不需要对外暴露，设为 private/不导出
- 保持主函数的对外签名完全不变
- 如果需要跨文件提取公共函数，先告诉我，不要自动执行
类型2：消除重复代码
CLAUDE CODEDRY 重构
分析 [模块目录路径] 内的重复代码。
执行步骤：
1. 列出所有重复超过10行的代码块（显示文件名和行号，不显示代码）
2. 按重复频率排序，找出最值得提取的前3个
3. 对最高优先级的重复块，提出提取方案：
- 提取到哪个文件？（已有的 utils 还是新建文件？）
- 函数签名是什么？
- 等我确认后再执行
执行时：
- 一次只提取一个重复块
- 提取后在所有使用处替换引用
- 运行测试确认通过
- 提交 git，然后继续下一个
类型3：现代化语法升级
CLAUDE CODE回调转 async/await
将 [文件路径] 中所有使用回调（callback）的函数迁移到 async/await 模式。
执行规范：
1. 先列出需要迁移的函数列表，等我确认
2. 逐个函数迁移（一次只改一个函数）
3. 每个函数迁移后立即运行测试
4. 如果该函数被其他文件调用，检查调用方是否需要同步修改
注意事项：
- 保持函数错误处理逻辑完整（callback 的 err 参数要转换为 try/catch）
- 如果调用方是外部接口（API endpoint），迁移时保持向后兼容
- 不要一次性重写整个文件，逐函数进行
类型4：Strangler Fig 模式（大型迁移）
CLAUDE CODE渐进式架构迁移
为 [单体服务/模块名] 设计渐进式迁移计划（Strangler Fig 模式）。
只输出迁移计划，不执行任何代码修改：
计划要包含：
1. 阶段划分（每个阶段的目标和可验证的完成条件）
2. 每个阶段影响的文件范围
3. 引入路由/适配层的时机和方式
4. 如何在迁移过程中保持旧系统继续运行
5. 回滚计划（每个阶段失败时如何回退）
6. 预估每个阶段需要重构的文件数量
输出计划后等我确认，再逐阶段执行。
完成检查（每个模块重构后执行）
重构前：git 状态干净，在 feature 分支
重构中：每个文件完成后立即运行测试并 commit
重构后：所有特征化测试通过，无新增 lint 错误
外部接口未发生变化（函数签名、API 路径均保持一致）
并行重构策略
当单模块重构流程稳定后，使用 Git Worktrees + 多实例并行处理，将重构效率提升数倍。适合需要对多个独立模块同时推进的场景。
本步骤目标：建立并行重构工作流，同时推进多个不相互依赖的模块，大幅缩短整体重构时间线。
Git Worktrees 并行设置
TERMINAL建立并行工作区
# 为每个并行重构任务创建独立分支和工作目录
# （在项目根目录的父目录执行）
# 模块1：auth 重构
git branch refactor/auth-20240115
git worktree add ../project-auth refactor/auth-20240115
# 模块2：payment 重构
git branch refactor/payment-20240115
git worktree add ../project-payment refactor/payment-20240115
# 模块3：user 重构
git branch refactor/user-20240115
git worktree add ../project-user refactor/user-20240115
# 现在可以打开3个终端，每个目录启动独立的 Claude Code 实例
# cd ../project-auth && claude
# cd ../project-payment && claude
# cd ../project-user && claude
大批量文件并行处理（/batch 命令）
CLAUDE CODE批量替换废弃 API
使用并行子智能体，处理以下所有使用废弃 [函数名/API名] 的文件。
每个子智能体独立处理一个文件，执行：
1. 替换废弃调用为新 API：[旧调用格式] → [新调用格式]
2. 更新对应的 import/require
3. 运行该文件的测试，确认通过
4. 报告：文件名 + 替换次数 + 测试状态
文件列表：（从 REFACTOR_PLAN.md 中粘贴文件路径）
- src/services/UserService.js
- src/controllers/UserController.js
- src/utils/UserHelper.js
[继续列出...]
所有子智能体完成后，汇总报告成功/失败数量。
失败的文件列出具体原因，不要自动修复。
并行重构的适用条件
| 条件 | 是否适合并行 |
|---|---|
| 两个模块之间没有互相依赖 | ✅ 适合并行 |
| 重构同一类问题（如替换废弃 API） | ✅ 适合并行（/batch） |
| 模块A 的重构结果会影响模块B | ❌ 必须串行 |
| 共享工具函数需要同时修改 | ⚠️ 谨慎并行，注意冲突 |
完成检查
已确认并行模块之间无依赖关系
Worktrees 建立正常，各目录独立工作
各并行分支最终 PR 依次合并（先后顺序），无合并冲突
集成验证检查
每完成一批模块重构后，进行系统级的集成验证。这不是单元测试——而是验证模块之间的协作依然正常工作。
本步骤目标：确认本轮重构没有引入跨模块的回归问题，性能基准未下降，为下一轮重构建立新的基线。
集成验证提示词
CLAUDE CODE完整集成验证（每批结束后执行）
对本轮重构的模块执行完整的集成验证。
验证步骤：
1. 运行所有测试（单元 + 集成 + 特征化），输出通过率
2. 运行 linter，与 refactor-baseline 标签对比新增的 warning
3. 对比 git diff（当前 vs refactor-baseline），统计：
- 修改的文件数量
- 删除的代码行数（应该是正数，代表代码减少）
- 新增的测试用例数量
4. 检查接口兼容性：
- 所有对外暴露的函数签名是否与重构前一致
- 如有变化，列出所有变化点
5. 生成质量对比报告：
格式：[模块名] | 重构前 | 重构后 | 变化
行数, 圈复杂度(最高), 测试数量, 测试覆盖率
判断标准：
✅ 所有测试通过 → 可以合并 PR
⚠️ 有测试失败 → 列出失败原因，我来决定是否修复
❌ 接口发生变化 → 必须修复，不允许合并
性能回归检查
CLAUDE CODE性能基准对比
为本轮重构的核心功能路径运行性能基准测试。
1. 识别性能敏感的函数（通常是：数据库查询包装、缓存层、高频调用的工具函数）
2. 如果项目有 benchmark 工具，运行并对比重构前后
3. 如果没有，用以下简单方式评估：
- 运行测试套件计时：time npm test（对比重构前后时间）
- 代码层面检查：重构后是否引入了不必要的额外函数调用层
报告格式：
- 性能无明显变化：✅ 正常
- 性能下降 < 10%：⚠️ 说明原因
- 性能下降 > 10%：❌ 需要优化后才能合并
完成检查
所有测试通过（单元 + 集成 + 特征化）
质量对比报告已生成，代码行数净减少
所有外部接口签名未变化
PR 已创建，CI 绿色，已合并到主分支
更新 CLAUDE.md 中的优先级列表（已完成的划掉）
持续治理配置
重构不是一次性工程——遗留代码库的技术债务需要持续治理。配置自动化巡检，防止债务反弹，让 Claude Code 成为常驻的代码质量守卫。
本步骤目标：建立长效的代码质量治理机制，包括自动巡检、PR 审查规则和团队规范，确保重构成果不会被新的技术债务侵蚀。
配置 Claude Code 定期巡检
CLAUDE CODE设置质量巡检任务
为本项目配置持续质量巡检，生成可定期运行的检查脚本。
巡检内容：
1. 扫描最近7天新提交的代码，找出：
- 新增的圈复杂度 > 10 的函数
- 新增的超过50行的函数
- 新增的重复代码块（超过10行）
2. 检查是否有已废弃但又被重新引入的 API 调用
3. 检查测试覆盖率是否下降（与上周对比）
输出：生成一个 scripts/quality-check.sh 脚本，
可以在 CI 中每周自动运行，失败时发送警报。
同时，告诉我如何将这个检查集成到现有的 CI 流程中。
PR 审查提示词模板
CLAUDE CODEAI 辅助 PR 审查（每次代码审查时使用）
审查以下 PR 的代码变更，重点关注重构质量：
PR 地址/diff 内容：[粘贴 git diff 或 PR 链接]
审查维度：
1. 是否引入了新的高复杂度函数（复杂度 > 10）？
2. 是否有重复代码没有提取？
3. 变量和函数命名是否清晰易懂？
4. 是否有遗漏测试的关键路径？
5. 是否破坏了任何现有接口？
输出审查意见（给出具体行号和建议），
不要重复描述代码本身，只指出问题和改进建议。
CLAUDE.md 长期维护规范
CLAUDE CODE每月更新 CLAUDE.md
基于过去一个月的重构进展，更新 CLAUDE.md 文件。
更新内容：
1. 将已完成重构的模块从优先级列表中移除
2. 根据实际遇到的坑，补充"已知的坑"部分
3. 如果有新发现的"禁止触碰区域"，添加进去
4. 更新技术栈版本信息（如有依赖升级）
5. 添加本月重构的经验总结（1-3条最重要的教训）
同时生成一份本月重构进度报告：
- 已重构模块数量
- 代码行数净减少量
- 测试覆盖率变化
- 剩余高优先级模块数量
长期治理仪表盘（可选）
CLAUDE CODE生成技术债务趋势报告
基于 Git 历史记录，生成技术债务趋势分析。
分析维度（按月统计，最近6个月）：
1. 总代码行数趋势（应该逐月下降）
2. 平均圈复杂度趋势（应该逐月下降）
3. 测试覆盖率趋势（应该逐月上升）
4. 无测试文件数量趋势（应该逐月下降）
输出为 Markdown 表格 + 文字总结。
如果某个指标在恶化，标注 ⚠️ 并分析原因。
完成检查
quality-check.sh 脚本已创建并集成到 CI
PR 审查流程已包含 AI 辅助检查环节
CLAUDE.md 已更新，反映当前项目状态
已制定下一个月的重构计划（基于更新后的优先级表）
团队已了解并认可这套重构工作流
重构框架搭建完成！
你已经完成了所有配置步骤。
现在的代码库有了完整的测试防护网、自动化质量门控和持续治理机制。
剩下的工作是按照优先级表，一个模块一个模块地推进重构。
记住核心原则：每次会话只做一件事 · 每个文件改完立即测试 · 遇到不确定就停下来问