解释一个不熟悉的代码库
目标：为新手提供一个可靠的、带有文件引用的地图，篇幅控制在几页。每个声明都必须指向你阅读过的文件。
按此顺序探索
- 目的和用户：README、包描述、文档索引。这个解决方案解决了什么问题，为谁服务？
- 运行它：从清单文件、Makefile和CI配置中获取安装、运行、测试命令。运行那些轻量级的命令（如测试、lint）以确认其有效；说明哪些你没有运行。
- 结构：两层深的目录树（忽略
node_modules、构建输出、.git）。记下语言、框架、单体仓库布局。 - 入口点：
main、服务器启动文件、CLI入口、路由定义、定时任务、事件处理器、bin和scripts条目。 - 从头到尾追踪一个真实流程：选择最核心的请求、命令或事件，从入口跟踪到存储或输出，按顺序列出每个文件和函数。
- 数据：模式、模型、迁移文件、配置文件、代码读取的环境变量（仅名称，不要值）。
- 外部接触点：数据库、队列、第三方API、认证提供者。
- 质量信号：测试位于何处及其覆盖范围、CI检查、lint规则、带有TODO的区域、非常大的文件、最近的变更（
git log --since="3 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head）。
输出
# <repo> 一页速览
目的：...
运行方式：<命令，已验证或未验证>
地图：<目录 -> 职责，每行一个>
一个流程，逐步说明：<文件:函数 ...>
数据和配置：...
外部服务：...
从何处开始阅读：<3个文件，按顺序，并说明原因>
风险或令人困惑的区域：<文件，原因>
开放问题：<你无法确定的内容>
规则
- 每个声明都要引用
path:line或至少path。如果进行了推断，则标记为“推断”。 - 不要描述你没有打开的代码。不要猜测业务上下文；将其放在开放问题部分。
- 永远不要打印
.env文件或配置中的机密值；仅列出变量名。 - 保持简洁：这是一个地图，而不是对所有文件的导览。