遗留代码接手前的依赖风险清单
收录 2026-10-28
接手一个没人维护的旧模块前，先摸清它对数据库、定时任务和外部接口的隐性依赖，避免一改就炸。
你是一名接手过大量遗留系统的维护工程师。我要接一个没人写文档的旧模块，请帮我摸清它在改动前藏着哪些依赖。 [模块代码或路径]： [它现在的业务用途]： [本次想改的地方]： [已知的线上异常]： 输出结构： 1. 依赖地图：数据库表与字段、定时任务、消息队列、外部接口、共享缓存，逐项标出证据位置（文件、行号、表名） 2. 高危触点：按改动后最可能静默出错的顺序排列，并说明为什么不会立刻报错 3. 改动前必须补的护栏：最小验证脚本、开关、监控埋点各一条 4. 建议的第一次小改动：范围、验证方式、回滚动作 验收标准：每条依赖都带证据位置，不能把猜测写成事实；护栏方案不能引入新框架；验证步骤要在半天内能执行完。代码不足时直接说缺什么，不要补全不存在的实现。
本站原创
中文原文
复制前替换这些占位符 4
把方括号里的内容换成你的具体信息，替换后再粘贴给 AI。
[模块代码或路径][它现在的业务用途][本次想改的地方][已知的线上异常]
使用建议
只给截图或片段时，模型容易把推测当结论；关键依赖务必让它标出出处再相信。
可以这样改
- 要求它先复述需求与约束，确认无误再写代码。
- 让它给出最小改动 + 回滚方式，而不是整文件重写。
交付物（这次应拿到什么）
- 可运行的最小改动（含直接可用的代码块）
- 影响面清单：改了哪些文件、哪些调用点要跟着改
常见错法
- 一次让它改十个文件，最后分不清哪处改动导致了新问题。
- 只贴报错不贴代码和版本，拿到无法落地的修法。
输出验收（怎么判断能用）
- 改动可运行、可回滚，且没顺手改无关代码。
- 边界条件（空值、超长、并发）有说明或测试。
适用场景与注意
- 适合：让它先复述需求和约束，再给最小可运行改动。
- 注意：贴报错时同时给版本号与最小复现，否则它容易给出看似合理但不适配的写法。