核心问题
接手陌生系统时，PM 应该如何参与代码考古？
真实场景
新需求落在一个没人熟悉的老模块上。最危险的做法是直接排期开发。更好的做法是先考古。
常见误区
坏判断是：
反正只是改一个小功能，不用理解太多。
陌生系统里没有绝对的小改动。
工程视角
代码考古要回答三类问题：
它现在做什么？
它为什么这样做？
它还能不能安全改变？PM 可以怎么做
使用这张清单：
1. 相关业务概念是什么？
2. 核心代码入口在哪里？
3. 有哪些状态和分支？
4. 哪些规则没有写在 PRD 里？
5. 最近一次修改是什么时候？
6. 历史 PR 或 issue 说了什么？
7. 有没有事故或客户特殊逻辑？
8. 下游系统依赖哪些字段或行为？
9. 有没有测试、监控或灰度保护？
10. 这次需求是否需要先补文档？Atlas Action
对每个陌生模块，先写一页“系统考古笔记”，再进入排期。
模块做什么：
关键规则：
历史包袱：
主要风险：
本次可改范围：小结
代码考古的目的不是批判过去，而是降低现在的盲区。
PM 如果能帮助团队整理历史，工程决策会稳很多。