主题
接手老项目与二次开发
别人写的项目、几年没人动过的祖传代码——打开文件夹，它先自己读懂，再动手改；改哪、为什么改、影响谁，全程有据。
接手第一分钟发生了什么
打开老项目的文件夹（选「编程项目」模式），它自动做一轮项目体检：
| 它自己做的 | 您看到的结果 |
|---|---|
| 扫描目录结构、识别技术栈与框架 | 「这是个 Vue3 + Spring Boot 的前后端分离项目」 |
| 识别代码根、构建方式、依赖清单 | 项目档案（ai-docs/项目路径映射.md）自动填好 |
| 建立项目文档区 | 需求 / 设计 / 测试的目录骨架就位——老项目从此有了「档案柜」 |
扫描完成就能开工——不需要您先解释这个项目是干嘛的。
让它先「读懂」再动手
老项目最大的风险是「改一处、崩一片」。它的规矩是先读后改：
text
这个项目的订单退款是怎么实现的？
先梳理清楚再说话，别急着改。| 您说 | 它做 |
|---|---|
| 「梳理一下这个模块的结构」 | 读代码、画结构图 / 调用关系图，讲人话汇报 |
| 「这个功能在哪实现的」 | 定位到文件与关键代码，引用原文回答 |
| 「这次改动会影响哪些地方」 | 搜调用方、列影响面清单 |
二次开发的推荐开场：先让它把要动的模块梳理一遍（输出到设计文档），您确认它的理解没跑偏，再开始改——半小时的梳理，省掉后面的反复返工。
改老代码的三条安全带
| 安全带 | 怎么兜底 |
|---|---|
| 改动审查 | 每处修改逐块亮 Diff，您逐块审（见看懂改动审查） |
| 测试先行 | 改前先跑现有测试确认基线，改后重跑对照——老项目没测试？先让它补上关键路径的测试再动手 |
| 回退三档 | 改坏了块级 / 会话 / Git 三档可退（见改错了怎么回退） |
老项目常见的坑，它怎么处理
| 坑 | 它的做法 |
|---|---|
| 依赖太老、装不起来 | 先诊断缺什么，工具链一键补齐（见工具链与环境）；依赖升级单独一轮做、跑通验证再继续 |
| 没有任何文档 | 边开发边补——代码改到哪，文档补到哪（见项目文档机制） |
| 多分支 / 多版本混乱 | 先理清分支状况再动（「列出所有分支和各自状态」） |
| 隐性业务规则（代码里藏着的约定） | 拿不准的规则问您，不猜——这是老项目翻车主因，宁可多问 |
| 半成品功能（前任没写完的） | 先识别「完成 / 半成品 / 废弃」，列清单跟您确认处置 |
二次开发的标准节奏
text
1. 打开项目（自动体检）
2. 「梳理订单模块，输出设计文档」——读懂
3. 确认它的理解——校准
4. 「在退款流程里加一个审核环节」——改（提问卡会问清业务规则）
5. 看改动、跑测试、实测——验收
6. 提交——入库（文档同步更新）常见卡点
| 现象 | 怎么办 |
|---|---|
| 项目太大，它梳理得慢 | 分模块来——「先只梳理订单这一块」，别一次吃全仓 |
| 它对老代码的理解有偏差 | 指出来——「不对，这个字段是××意思」；重要口径让它写进文档，下次不再错 |
| 依赖装不上 / 编译报错 | 把报错给它——环境类问题它自己修（见出问题了怎么办） |
| 前任留下的诡异写法 | 问它「这段为什么这么写」——它分析意图；确认是坏味道再重构，别看见就改 |
| 想大重构 | 先出方案（影响面 / 步骤 / 风险），您拍板后分轮做——别一口气全拆 |