背景

AI时代，很多人接手老项目，上来就是直接coding，但受限于Agent上下文，通常会可能改动会这边动一点，也改的不够彻底，结果就是看似改了一点，也成功了一点点，就是达不到预期

思路

1. 找相关的人聊，可能每个人懂一点，拼起来，整理为md(AI介入：AI 能帮你整理疑点清单、草拟问题)；
2. 查看所有的资料，比如Wiki、readme（AI介入：AI 读 README、wiki、Confluence、jira 比你快十倍）；
3. clone代码、全部读一遍（AI介入：让 AI 扫一遍仓库，生成一张模块图、数据流图，md下来）；
4. 搭建环境，Run起来；
5. 核心接口关注，curl跑一遍（AI介入：让 AI 从代码里梳理出所有接口清单 + curl 示例，md下来）；
6. 针对疑点去深挖代码（AI介入：AI 能扫描代码给你找调用链路）；
7. 画流程图：针对核心流程（AI介入：核心的链路大致可以画出来，但隐形的约定等需要个人补充）；
8. 改代码，过程需要遵循先小改，拆分多个部分；
9. 验收：确保主流程OK、相关的业务场景OK、同时找独立同等水平及以上的人review（AI介入：do checklist）；

注意点（80% 的完成度当成 100%）

1. 判断哪些代码不能动：像“// 勿动，某某对接方需要”的注释；
2. 注意隐性约定，如接口对接约定的定义；

做法

1. AI 主导做 80%，翻资料、浏览代码结构、访接口都在这里，放手让 AI 做就行。
2. 人机对半 AI 做 50%，找人聊、搭环境、深挖、画链路、动手改都在这里，整门课大部分功夫花在这一档。
3. 人主导 AI 做 20% 或更少，判断代码能不能动、对接方是谁、最终验收、上线风险识别都在这里。

记住那句话：20% 的盲区，经常就是 100% 的事故。AI 做不到的那 20%，你不主动补，它就是 0。

心法

1. 读 README 和根目录docs的文档;
2. 看目录和包组织。Java 项目看 pom.xml 的 module 划分;python项目看requirements；
3. 找核心入口，HTTP 服务找 controller 和 main 函数；
4. 画出项目全景，架构图、模块依赖图、核心数据流图，关键是要动手画！！！
5. 梳理接口和数据模型；
6. env、Run；
7. 带着需求深挖代码，有目标的读胜过无目标的读一百倍；
8. 沉淀成 AI 能读的文档：CLAUDE.md（项目特定的上下文备忘录）和 SKILL.md（可复用的操作模板）；

其他注意点

1. 先规划，规划直接上cot能力强的模型，如opus4.7
2. 分拆成若干小需求，每个需求尽量一个chat，除非相关性很强才放一起；
3. 后端尽量F12补货到具体的请求后直接全部copy，再补充需求去chat；
4. 前端尽量获取到path再组合请求去问题，减少Agent全屏查找的成本；
5. 新模型生成时，带上单元测试；
6. 新需求，直接把参考代码目录放进去，直接引用目录，并带出具体的参考部分，再去让AI参考生成需求；
7. 情非得已，尽量不要动旧接口，只增不减；
8. 改动时，@引用代码部分，再补需求去chat；

现状

现在日常： cursor（主，pro会员opus4.7可以支持约10天） + CC（DS-v4-pro，反应比cursor慢） +qoder(opus4.7 3000次) +copilot（opus4.7 300次） +灵犀（放弃了，已删除）

汇报

1. .claude目录
2. docs目录：API_REFERENCE.md architecture.md module-deps.md API_REFERENCE.md schema.md 如果没必要上传，可以.ignore忽略以上目录

如果要写项目相关的md文档，直接引用@doc再去生成各种汇报的md，再必要补一些图即可