编程#代码#文档#总结
旧项目架构解读与上手路径
给一份目录树和关键文件，输出从哪读起、模块怎么串、改动要注意什么。
适用工具ClaudeChatGPTCursorDeepSeek
提示词
你是资深架构师，帮我快速接手一个不熟悉的项目。
一、项目画像
根据我提供的信息，先判断：
- 技术栈与框架版本
- 项目类型（单体 / 前后端分离 / 微服务 / 脚本工具）
- 入口在哪（主文件、启动命令、路由注册位置）
- 有没有明显的技术债信号（多个同名工具函数、deprecated 依赖、注释掉的整段代码）
二、阅读路径（最重要）
给出一条「从启动到跑通核心流程」的阅读顺序，6-8 步，每一步说明：
- 读哪个文件 / 目录
- 读完应该搞懂什么
- 大概需要多少时间
按这个顺序读，能在最短时间内形成整体认识。
三、模块地图
用文字画出模块关系：
入口 → 路由/分发 → 业务模块 → 数据层 → 外部依赖
标注每个模块的职责一句话，以及模块之间的调用方向。
四、改动安全区
- 哪些文件可以放心改
- 哪些文件属于「碰了容易炸」的核心（说明原因）
- 如果要加一个新功能，标准做法应该在哪几个位置各加什么
五、快速验证
给出 3 个「改完怎么确认没弄坏」的检查动作（跑哪条命令、看哪个页面、查哪段日志）。
六、遗留问题清单
列出你从代码里看到但不确定的 5 个问题，按「影响接手速度」排序，方便我去问同事。
项目信息：
目录树：【粘贴 tree 输出】
关键文件内容：【粘贴 package.json / 入口文件 / README】
我的目标：【例如：加一个导出功能 / 修一个 bug / 只是先看懂】文中【】为可替换变量，使用前请替换成你的具体内容。
变量填充：填一填直接用
已识别 3 个【】占位变量，填写后一键生成成品提示词；留空的变量会保留占位符。
使用技巧
- 先跑通再读代码，跑不起来的时候读代码效率极低。
- 「阅读路径」比「完整架构文档」有用得多——后者往往读一半就放弃了。
- 把不确定的问题列出来去问同事，比自己猜三天快。