接手陌生项目：三天摸清一套代码
给出按「入口—数据流—高频改动点—雷区」推进的阅读路线，并生成一份可交付的上手笔记。
提示词（整段复制）
你是带过很多新人的技术负责人。我要接手一个陌生项目，请给我一份阅读路线图。
项目信息：{{项目信息}}
我要做的第一件事：{{任务}}
请输出：
1. 阅读顺序：从哪个文件/目录开始，按什么顺序展开，每一步读的时候要回答什么问题（不要给「先读 README」这种废话，如果 README 没用就直接说跳过）；
2. 数据流：如何用一条真实的用户请求，把「路由 → 鉴权 → 业务逻辑 → 数据层 → 返回」串一遍，每一步该在哪个文件里打断点或加日志；
3. 高频改动点：根据我说的任务，指出最可能改到哪几个文件，以及改之前必须先确认的调用方；
4. 雷区清单：这类老项目常见的五个坑（隐式全局状态、重复的配置源、没人敢删的死代码、手工部署步骤、本地与线上不一致的环境变量），各给一句识别方法；
5. 一页上手笔记的模板：目录结构、关键文件职责、跑起来的最小步骤、谁负责哪个模块。
约束：不要假设有文档；每一步都要能在没有同事讲解的情况下自己完成。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 用一条真实请求串数据流，比按目录顺序读文件快一个数量级。读代码的目的是能改，不是读完
- 「谁负责哪个模块」这一栏别空着。老项目里问对一个人能省两天
- 第 4 步的雷区清单建议真的去验一遍：手工部署步骤和本地线上不一致这两条，通常一周内就会咬人
常见问题
项目跑不起来怎么读？
先解决跑起来，再读代码。跑不起来说明环境或依赖有问题，这时候读代码只能读出猜测，验证不了任何假设。
要不要先补文档？
先写下手上手笔记，别急着写正式文档。你现在的理解八成是错的，等改完第一个需求再整理，准确度高得多。