让 CC 找技术债和风险点

真实项目教程：让 Claude Code 只读扫描技术债和风险点，区分可立即修、小步改、暂缓处理和必须人工评审的任务。

技术债不是看到“不优雅”就立刻重构。

让 CC 找技术债的目的，不是让它马上改，而是建立风险清单：哪些影响交付，哪些只是代码风格，哪些必须等业务窗口。

技术债扫描和代码审查的区别

代码审查看的是一次 diff。

技术债扫描看的是一片区域的长期风险。

它关心：

• 重复逻辑。
• 缺少错误处理。
• 过时依赖。
• 强耦合模块。
• 测试缺口。
• 隐式业务规则。
• 高风险脚本。
• 不清楚的配置。

所以第一步必须只读。

技术债扫描提示词

请对当前项目做一次只读技术债和风险点扫描，不要修改文件。

扫描范围：
【整个项目 / 某个模块 / 某个页面 / 某个接口链路】

请输出：
1. 技术债列表。
2. 每项技术债的证据文件。
3. 可能造成的实际影响。
4. 风险等级：低 / 中 / 高。
5. 是否建议现在处理。
6. 推荐处理方式：立即修、小步改、专项重构、暂缓。
7. 处理前需要哪些验证或人工确认。

要求：
- 不要把代码风格问题夸大成高风险。
- 不要直接修改。
- 不要建议一次性重构。

让 CC 区分“债”和“风险”

很多技术债不一定马上有风险。

继续问：

请把刚才的清单分成两类：

1. 技术债：影响维护效率，但短期不一定造成故障。
2. 风险点：可能导致 Bug、安全问题、数据错误或上线事故。

每项都说明依据。

这样可以避免“看到不顺眼就改”。

不要把风格问题升级成高风险

技术债扫描最常见的误判，是把代码风格问题说得很严重。

可以给 CC 这个判断规则：

提示词：

请不要把纯代码风格问题评为高风险。
只有可能导致 Bug、安全问题、数据错误、上线事故或维护不可控的问题，才评为中高风险。

生成处理优先级

请根据影响范围、发生概率、修复成本和验证难度，给出处理优先级。

输出表格：
问题
影响
发生概率
修复成本
验证难度
推荐优先级
下一步动作

优先级不是谁代码丑谁先改，而是谁影响交付谁先处理。

哪些可以马上改

通常可以先处理：

• 明显文档缺失。
• 小范围重复代码。
• 明确的空值保护。
• 明显的错误提示缺失。
• 不影响业务逻辑的命名或注释补充。
• 有测试覆盖的小修复。

这些适合让 CC 小步做。

小步处理技术债的方式

即使是低风险技术债，也不要一次性扫荡。推荐按这个节奏：

1. 先选择一个低风险问题。
2. 只修改直接相关文件。
3. 不顺手重构其他模块。
4. 改完解释 diff。
5. 给出验证方式。
6. 如果影响不确定，停止并人工确认。

可以直接让 CC 按这个规则执行：

请从风险台账里选择一个低风险、收益明确、验证简单的问题进行小步处理。

要求：
1. 先说明为什么选择它。
2. 只改必要文件。
3. 不扩大到相邻问题。
4. 修改后给出 diff 解释和验收步骤。

哪些不能马上改

不要让 CC 直接处理：

• 认证和权限核心逻辑。
• 支付、订单、资金相关。
• 数据库结构大改。
• 跨模块重构。
• 依赖大版本升级。
• 发布脚本和生产配置。
• 没有验收方式的性能优化。

这些要先评审。

让 CC 生成风险台账

请把技术债和风险点整理成风险台账。

字段：
1. 编号
2. 问题描述
3. 证据位置
4. 影响范围
5. 风险等级
6. 建议动作
7. 负责人或确认人
8. 是否需要单独任务
9. 验收方式

风险台账适合团队长期维护。

风险台账怎么进入团队流程

技术债扫描结束后，不要只停留在一份报告里。可以把结果分成三类：

对团队来说，最有价值的不是“发现很多问题”，而是每个问题都有下一步。

验收结果

学完后，应该能做到：

• 让 CC 只读扫描技术债。
• 区分技术债和真实风险。
• 按影响和成本排序。
• 不把所有问题一次性重构。
• 把结果沉淀成风险台账。