技术债务管理最难的不是发现债务，是判断优先级——哪些必须现在还，哪些可以带着跑，哪些其实没必要还。Claude Code 能帮你建立系统性的分诊流程。
第一步：盘点债务
claude "分析整个代码库，识别技术债务的主要类别：
1. 代码级别：复杂度高（cyclomatic complexity > 20）的函数
2. 架构级别：不符合现有架构约定的模块
3. 依赖级别：过时的核心依赖（影响安全/性能）
4. 测试级别：关键路径但没有测试覆盖
每类列出前 5 个最严重的例子，给出：文件路径 + 问题描述 + 影响范围。"
第二步：评估影响
claude "对这个技术债务列表，
按两个维度评分（1-5分）：
1. 修复难度（1=容易，5=需要大重构）
2. 不修复的风险（1=低风险，5=随时可能爆炸）
输出一个矩阵，标出：
- 高风险 + 容易修复 → 立即处理（本周）
- 高风险 + 难修复 → 计划处理（下个 sprint）
- 低风险 + 容易修复 → 机会性处理（顺手）
- 低风险 + 难修复 → 观察（不必主动处理）"
第三步：生成可执行的 PR 计划
claude "把'立即处理'类别的债务，
拆分成独立的 PR，每个 PR：
- 聚焦一个问题
- 不超过 200 行改动
- 不依赖其他 PR
- 有明确的验证标准
输出 PR 列表，按推荐执行顺序排列。"
识别"伪债务"：
claude "检查这些被标记为'技术债务'的代码：
1. 真的是债务（会影响可维护性/性能/安全），还是只是风格不一致？
2. 有没有这么写的充分理由（性能优化、历史兼容、外部约束）？
3. 修复它的实际收益是什么？
避免因为'看起来丑'而产生虚假的紧迫感。"
量化债务的实际成本：
claude "分析 src/legacy/ 目录里的代码：
1. 每次修改这个模块平均需要多长时间（基于 git 历史的 commit 规律）？
2. 这个模块有多少个 bug fix commit（说明它容易出错）？
3. 如果重构这个模块，预计需要多少工作量？
用这些数据计算：继续带着这个债务跑 1 年的成本，和现在还清的成本，哪个更高？"
债务的生命周期管理：
不是所有债务都要还。有些债务的正确处理方式是： - 隔离（别让新代码依赖它） - 封装（把它藏在清晰的接口后面） - 等待自然消亡（产品可能放弃这个功能）
让 Claude 帮你判断每个债务属于哪种情况，比统一"都要重构"更务实。