我希望 TraeCode 未来可以有一个「项目考古模式」：先告诉我这坨代码到底发生过什么
我做后端和平台开发。
平时最怕的不是写新项目。
最怕的是有人突然发我一句：
“这个项目你接一下。”
然后丢过来一个仓库。
我点进去：
187 个目录。
README 最后更新于 2023 年。
Dockerfile 有 4 个。
config 里套着 config。
一个函数 600 行。
还有一句：
// TODO: 临时方案，后面优化
Git blame 一看。
2021 年。
很好，临时了五年。
这种时候我最希望 TraeCode 别急着问我：
“你想修改什么功能？”
兄弟，我连这个项目是干嘛的都还没搞明白 
我希望它先自动进入一个：
「项目考古模式」
把整个仓库逛一圈，然后回来告诉我：
这个项目到底是怎么活到今天的。
比如直接生成一份“新手生存指南”：
项目地图
main.go 只是入口，真正核心逻辑在 service/task
高危区域
scheduler.go 被修改过 47 次，建议谨慎碰
历史遗迹
legacy/ 目录目前已经没有调用，但暂时没人敢删
最近经常出事
最近 3 个月 60% 的 bug 都集中在 workflow 模块
神秘代码
utils/common.go 里有一个 800 行万能函数，被 23 个地方引用
光是看到这个，我对项目的理解速度可能就能快一倍。
我甚至希望 TraeCode 再八卦一点。
它可以结合 Git 历史告诉我：
“这个模块去年经历过一次大重构。”
“这里看起来很奇怪，是因为当时为了兼容旧接口。”
“这段代码不要急着删，虽然没人直接调用，但启动脚本会动态加载。”
这种信息很多时候代码本身是看不出来的。
真正接手一个老项目，最难的也不是“代码是什么意思”。
而是：
它为什么会变成今天这个样子。
我希望它最后给我一张「别踩雷地图」
打开陌生项目的时候，TraeCode 自动扫描：
Git 历史、目录结构、依赖关系、测试、配置、TODO、最近修改热点。
然后给我一个项目主页：
这里是入口。
这里是核心链路。
这里最好别乱动。
这里看起来很重要，其实已经废弃。
如果你要改登录功能，先看这 5 个文件。
我觉得这个比单纯给我生成一篇“项目介绍”有用得多。
因为现在 AI 很擅长回答：
“这段代码是什么意思？”
但我真正想问的是：
“这坨代码为什么会长成这样？”
这才是接手祖传项目时最想知道的事情。
如果 TraeCode 真有一天做出「项目考古模式」，
以后再有人对我说：
“这个老项目你先熟悉一下。”
我至少可以先回复一句：
行，我先让 TraeCode 下墓。