接手没人维护的老项目，应该从哪看起
老项目的风险不在代码丑，而在你动了什么自己不知道。顺序应该是先看懂、再评估、最后才改。
怎么做
从数据流看懂一段陌生代码
一次只贴一个模块进「看懂陌生代码」。让它先用一句话说整体在干什么，再按数据流讲输入从哪来、经过哪些变换、输出到哪去，并标出两三个最容易看错的地方。不要逐行翻译语法，边看边画成自己的调用图，后面会反复用到。
拆出边界和单点故障
把系统名称、部署方式和主要外部依赖交给「拆解一个复杂系统」。先划什么在里面、什么在外面，再列输入输出、拆成三到六个子系统及各自接口，指出瓶颈和单点。最后用一个真实场景走一遍流程，标出你容易忽略的环节。
先找出最危险的那部分代码
挑第 2 步里风险最高的模块，贴进「代码审查」。只让它报会导致 bug、安全和性能问题的地方，按严重程度排序，每处给出触发条件和具体改法。这份清单决定你接下来先给哪块补测试，而不是平均用力。
看测试到底覆盖了什么
针对第 3 步挑出的危险模块，把实现和现有测试一起给「给测试用例挑漏」。老项目常见的问题是有测试，但测的是实现细节：列出未覆盖分支，按线上影响选前五个要补的用例，同时删掉重复和断言内部实现的测试。测试要先能保护你即将改动的那块。
评估依赖升级会不会踩雷
把依赖名、当前版本、目标版本和调用处数量给「依赖升级风险评估」。只保留真正会被调用到的破坏性变更，分必须改、建议改、可以不改三类，给出升级顺序和本地验证方式。一次只升一个，跑通再升下一个。
用到的提示词
常见问题
接手老项目，第一件事是重写还是先加测试
都不是。先把边界和数据流读清楚，找到真正危险的地方，再针对那几处补测试。没有重点的重写、平均铺开的测试，都会把时间花在低风险代码上，而真正会出事的地方仍然没有保护。
老代码没有文档，AI 能补出来吗
能补一部分，但补的是从代码推断出的行为，不是当年的设计意图。把推断结果标成待确认，找老同事或提交历史核对，不要当成事实写进文档，否则下一个接手的人会踩同样的坑。
依赖版本很老，要不要一次升到最新
不建议。按调用量分批升，每次只升一个并跑通测试；跨多个大版本时，先看 breaking change 里哪些真的被调用到，其余可以暂时不动。一次升太多，出问题时你分不清是哪一次改坏的。