1. 接手老项目的第一道坎为什么“看懂技术栈”比“动手改代码”更重要接手一个三五年甚至更久远的项目最让人头疼的往往不是代码本身有多难而是你根本不知道它到底用了什么。打开目录一看package.json里依赖几十个pom.xml里模块套模块配置文件散落在各个角落README 还是三年前写的跟现状完全对不上。这种时候如果直接上手改代码基本等于蒙着眼睛在雷区里跑步。我这次接手的这个老项目是一个内部用的数据报表系统前后端加起来大概四万多行代码。上一任维护者已经离职一年多留下的文档只有一份部署说明技术栈信息几乎为零。团队给我的要求很简单先搞清楚它用了什么再评估能不能加新功能。听起来不难但真正动手才发现光靠人眼去翻代码效率低得让人抓狂。所以这次我换了个思路——用 Claude 来辅助分析。不是让它帮我写代码而是让它帮我“读”代码把技术栈、依赖关系、潜在风险点梳理出来。这篇文章就是我把整个过程拆解后的实操记录包括我怎么设计分析流程、怎么跟 Claude 配合、遇到哪些坑、最后产出了什么。如果你也经常接手老项目或者想用 AI 辅助代码理解这篇内容应该能直接抄作业。2. 分析前的准备工作别急着把代码丢给 AI2.1 先搞清楚你要分析什么很多人一上来就把整个项目压缩包丢给 Claude然后问“帮我分析技术栈”。这种做法基本得不到有用的结果因为 AI 的上下文窗口有限而且它不知道你关心的重点是什么。我的做法是先明确三个问题这个项目有哪些入口比如后端服务的启动类、前端的入口文件、定时任务的调度类。哪些文件最能反映技术栈依赖管理文件package.json、pom.xml、requirements.txt、构建配置webpack.config.js、vite.config.ts、部署脚本Dockerfile、docker-compose.yml。你关心的技术栈维度是什么是框架版本、中间件类型、数据库选型还是构建工具链把这三个问题想清楚你就能圈定一个“最小必要文件集”而不是把整个项目一股脑塞进去。2.2 文件筛选的实操标准我给自己定了一个筛选规则按优先级排序优先级文件类型具体示例分析价值P0依赖声明文件package.json、pom.xml、go.mod直接反映框架和库的版本P0构建配置文件webpack.config.js、vite.config.ts反映构建工具链和编译目标P1容器与部署文件Dockerfile、docker-compose.yml反映运行环境和中间件P1配置文件application.yml、.env.example反映数据库、缓存、消息队列P2入口文件main.ts、Application.java反映框架初始化和核心依赖P3目录结构整体 tree 输出反映模块划分和架构风格按照这个规则我从四万多行代码里只挑了不到二十个文件总共几百行内容。这样 Claude 能完整读完而且分析结果会非常聚焦。注意不要直接把包含敏感信息的配置文件比如带真实密码的 .env传给 AI。我一般会把敏感值替换成占位符比如DB_PASSWORD***只保留配置项的名称和结构。2.3 给 Claude 设定分析框架光有文件还不够你得告诉 Claude 怎么分析。我用的提示词结构是这样的你是一个资深架构师现在需要分析一个老项目的技术栈。 我会提供以下文件内容 1. 依赖声明文件 2. 构建配置 3. 部署配置 4. 入口文件 请按以下维度输出分析结果 - 前端框架及版本 - 后端框架及版本 - 数据库与中间件 - 构建工具链 - 潜在的版本兼容风险 - 建议的升级优先级 对于每个结论请标注你是从哪个文件的哪一行推断出来的。这个提示词的关键在于最后一句——要求 Claude 标注推断来源。这样我就能快速验证它的结论是否准确而不是盲目相信。3. 用 Claude 拆解技术栈的完整实操过程3.1 第一轮依赖文件分析我先从package.json开始。这个项目的package.json大概有两百多行依赖项密密麻麻。我直接把内容贴给 Claude让它按“框架、工具库、构建工具、测试工具”分类整理。Claude 的输出很快而且分类很清晰。比如它把react、react-dom、react-router-dom归为前端框架把webpack、babel、eslint归为构建工具链。但这里有个细节需要注意——Claude 有时候会把devDependencies和dependencies混在一起说。我在第二轮追问时专门让它区分这两类因为生产依赖和开发依赖的升级风险完全不同。后端这边是pom.xml情况更复杂一些。这个项目用的是多模块结构父pom里定义了依赖版本子模块里引用。Claude 在处理这种嵌套结构时表现不错它能识别出parent标签和dependencyManagement的作用。但它一开始漏掉了一个关键信息——某个子模块里覆盖了父pom的版本号。我后来把子模块的pom也贴进去它才补充了这个细节。实操心得依赖文件分析最好分两轮。第一轮让 Claude 梳理整体结构第二轮针对可疑点比如版本冲突、重复依赖深入追问。一次性问太多它反而会漏掉细节。3.2 第二轮构建配置与部署环境还原依赖文件只能告诉你“用了什么”但“怎么跑的”要看构建配置和部署文件。这个项目的webpack.config.js写得很乱有大量注释掉的代码和条件判断。我让 Claude 做了一件事把当前生效的配置和已废弃的配置分开列出来。Claude 的处理逻辑是先识别if条件里的环境变量然后判断哪些分支在当前环境下会执行。比如有一段配置是if (process.env.NODE_ENV production)它就推断生产环境会走这个分支。这个推断过程它写得很清楚我核对了一下基本准确。部署文件这边Dockerfile用的是node:14-alpine作为基础镜像docker-compose.yml里定义了三个服务前端、后端、MySQL。Claude 从这些信息里推断出几个关键点Node.js 版本是 14已经停止维护存在安全风险MySQL 版本没有显式指定用的是latest标签这本身就是个隐患没有看到 Redis 或消息队列的配置说明这个项目可能没有用缓存这些推断我后来都验证过确实如此。特别是 MySQL 用latest这一点我在实际部署时踩过坑——不同时间拉取的镜像版本不一致导致本地和线上行为有差异。3.3 第三轮入口文件与运行时依赖分析入口文件是理解项目启动流程的关键。前端入口main.tsx里有一堆import语句Claude 帮我梳理出了几个关键信息用了ReactDOM.render而不是createRoot说明 React 版本低于 18引入了moment.js做日期处理这个库已经进入维护状态体积也大有一个全局的状态管理初始化用的是redux而不是redux-toolkit后端入口Application.java里Claude 识别出了SpringBootApplication注解和几个Bean定义。它特别指出项目里同时存在spring-boot-starter-web和spring-boot-starter-webflux两个依赖这可能导致运行时冲突。这个点我后来专门查了确实是个隐患——虽然项目能跑起来但某些请求的处理路径可能不符合预期。3.4 分析结果的整理与验证三轮分析下来Claude 输出的内容大概有三千多字。我没有直接采用而是做了一轮人工验证。验证的方法很简单对于每个结论我都去对应的文件里搜关键词确认 Claude 说的位置和内容是否一致。验证过程中发现了两类问题过度推断Claude 看到axios就推断项目用了 REST API但实际上项目里还有 GraphQL 的依赖只是没在入口文件里体现。遗漏某个子模块的pom.xml里有一个spring-boot-starter-data-redis依赖但 Claude 第一轮没提到因为我没把那个文件贴进去。这两类问题说明一件事AI 的分析结果必须经过人工验证尤其是涉及架构层面的推断。我的做法是整理成一张对照表左边是 Claude 的结论右边是我的验证结果逐条核对。4. 分析过程中踩过的坑与排查技巧4.1 上下文窗口的限制与应对Claude 的上下文窗口虽然不小但如果你把整个项目的关键文件都贴进去还是会超。我试过一次贴了三十多个文件结果 Claude 只分析了前十个后面的直接忽略了。后来我改成分批分析每批不超过十个文件而且每批之间会做一个“小结”把上一批的结论简要复述给 Claude让它保持上下文连贯。这个“小结”的做法很关键。比如第一批分析完依赖文件后我会写一段话“根据上一轮分析前端用的是 React 17 Webpack 4后端是 Spring Boot 2.3。现在请基于这个背景分析构建配置。”这样 Claude 就不会重复分析已经确认过的内容而是聚焦在新文件上。4.2 版本号推断的准确性Claude 在推断版本号时有时候会“猜”。比如package.json里写的是react: ^17.0.2它会说“React 版本是 17”。这个结论没错但^符号意味着实际安装的版本可能是 17.x 的最新版。我在实际验证时发现package-lock.json里锁定的版本是 17.0.2但node_modules里实际装的是 17.0.2因为 lock 文件生效了。这个细节看起来很小但在评估升级风险时很重要。如果 lock 文件里锁的是 17.0.2那升级到 18 的改动量可能比想象中大。我后来专门让 Claude 分析了package-lock.json里的关键依赖版本这才得到准确的结论。4.3 常见问题速查表问题现象可能原因排查方法解决思路Claude 分析结果不完整上下文超限或文件未提供检查是否分批分析确认关键文件已包含分批分析每批加小结版本号推断与实际不符只看声明文件未看 lock 文件对比 package.json 和 package-lock.json以 lock 文件为准遗漏子模块依赖多模块项目只分析了父 pom检查所有子模块的 pom.xml逐个模块分析后汇总推断出错误的技术栈AI 过度推断人工验证每个结论建立对照表逐条核对敏感信息泄露风险直接贴了配置文件检查是否包含密码、密钥替换敏感值为占位符4.4 独家避坑技巧我踩过最大的一个坑是Claude 在分析webpack.config.js时把一段被注释掉的配置当成了生效配置。那段配置里用了webpack-dev-server的一个旧参数Claude 据此推断项目用的是旧版 dev server。但实际上那段代码已经被注释了当前用的是vite做开发服务器。这个坑的教训是给 AI 的文件里注释掉的代码要特别标注。我后来的做法是在贴文件内容时把注释部分用[已注释]标记出来或者在提示词里明确说“忽略所有注释掉的代码”。这样 Claude 就不会被误导。另一个技巧是对于关键结论我会让 Claude 给出“置信度”。比如问它“你有多确定这个项目用的是 Redux 而不是 Context API”它会给出一个从高到低的判断并说明依据。置信度低的结论我会优先人工验证。5. 分析完成后的技术栈全景与升级建议5.1 最终梳理出的技术栈清单经过三轮分析和人工验证这个老项目的技术栈终于清晰了。我整理成了一张表层级技术选型版本状态评估前端框架React17.0.2稳定但低于当前主流前端构建Webpack4.46已停止维护建议升级前端语言TypeScript4.1较旧缺少新特性状态管理Redux4.0可用但推荐 Redux Toolkit后端框架Spring Boot2.3已停止维护后端语言Java8较旧但稳定数据库MySQL5.7已停止维护缓存Redis未使用无部署Docker20.10可用基础镜像Node 14 Alpine14已停止维护这张表看起来简单但背后是三轮分析和大量人工验证的结果。特别是“状态评估”这一列是我结合当前维护状态和团队实际情况给出的判断不是 Claude 直接生成的。5.2 升级优先级与风险评估基于这张表我给出了三个升级优先级高优先级Node 14 和 MySQL 5.7 都已经停止维护存在安全风险。这两个的升级相对独立可以优先处理。Node 14 升级到 18 或 20主要影响的是构建工具链MySQL 5.7 升级到 8.0需要注意字符集和认证方式的变更。中优先级Webpack 4 升级到 5或者直接迁移到 Vite。这个改动量较大但收益也明显——构建速度能提升好几倍。我建议先在新分支上做验证确认所有 loader 和 plugin 都有兼容版本后再合并。低优先级React 17 升级到 18Redux 迁移到 Redux Toolkit。这两个改动会影响业务代码需要配合测试一起做。如果项目近期没有大功能迭代可以暂缓。注意升级顺序很重要。我建议先升级基础设施Node、MySQL再升级构建工具最后升级框架。这样每一步的变更范围可控出问题也容易定位。5.3 用 Claude 辅助生成升级方案技术栈梳理清楚后我让 Claude 帮我生成了一份升级检查清单。比如针对 Node 14 升级到 18它列出了以下要点检查node-sass是否需要替换为sass检查webpack的hash算法是否需要调整检查crypto模块的 API 变更检查fs模块的promisesAPI 是否可用这份清单我后来逐条验证过确实覆盖了大部分兼容性问题。但 Claude 也漏掉了一些点比如npm版本的变化对package-lock.json格式的影响。这说明 AI 生成的清单可以作为起点但不能完全依赖。6. 把 AI 分析融入日常工作流的几点体会6.1 什么时候该用 AI什么时候不该用用 Claude 分析老项目技术栈我的体会是它最适合做“信息提取和初步归类”不适合做“架构决策”。比如让它从一堆配置文件里提取出框架和版本这个它做得又快又好但让它判断“该不该升级到微服务”它给出的建议往往过于泛泛缺乏对团队实际情况的了解。所以我的用法是AI 负责“读”和“整理”我负责“判断”和“决策”。这样分工效率最高风险也最低。6.2 提示词的迭代过程我一开始的提示词很粗糙就是“帮我分析这个项目的技术栈”。结果 Claude 输出了一大段泛泛而谈的内容什么“该项目采用了前后端分离架构”之类的废话。后来我不断迭代提示词加了三个关键约束指定输出格式用表格还是列表按什么维度分类要求标注来源每个结论必须说明是从哪个文件推断的限定分析范围只分析我提供的文件不要 extrapolate加了这三条之后输出质量明显提升。特别是“标注来源”这一条让我验证起来快了很多。6.3 人工验证不可省略不管 AI 分析得多好人工验证这一步绝对不能省。我的验证方法很简单对于每个关键结论去源文件里搜关键词确认位置和内容一致。这个过程大概花了我两个小时但避免了至少三个错误结论被带入后续决策。其中一个错误结论是Claude 说项目用了GraphQL因为它在package.json里看到了graphql依赖。但实际上这个依赖是某个工具库的间接依赖项目本身并没有用 GraphQL。如果我没验证可能会在后续升级时做出错误的判断。6.4 后续扩展的思路这套方法不仅适用于技术栈分析还可以扩展到其他场景。比如代码质量评估让 Claude 分析代码里的坏味道比如过长的函数、重复的代码块依赖安全扫描结合已知的漏洞数据库让 Claude 标记出有风险的依赖版本文档生成基于代码结构和配置文件让 Claude 生成一份初步的 README我后来用同样的流程分析了一个前端项目只花了半天时间就梳理清楚了它的组件结构和状态管理方式。这个效率在以前是不可想象的。最后分享一个小技巧如果你要分析的项目特别大可以先让 Claude 帮你生成一个“分析计划”列出需要重点看的文件和顺序。这样你就不用自己纠结先看哪个后看哪个了。我试过几次它给出的计划还挺合理的基本遵循了“先依赖、再配置、后入口”的逻辑。