1. 项目概述与技术栈分析的思路1.1 什么是“只管去写(day2)”系列我最近开了一个叫“只管去写”的系列说白了就是强迫自己坚持做记录、做输出每天选一个小目标不再纠结于“完美准备”先动手再说。这就是第二天的内容用 Claude 来分析一个老项目的技术栈。为什么要选这个主题因为我手头恰好接手了一个历史包袱很重的老项目代码量大、结构复杂、文档缺失光靠肉眼去读两天都不一定能摸清楚全貌。但用 Claude 这类 AI 辅助工具做一轮系统性的技术栈梳理效率完全不在一个量级。如果你也经常需要接手旧代码、做遗留系统改造、或者给老模块做技术评估这篇内容应该能直接帮你省下大半天时间。1.2 老项目技术栈分析到底在分析什么分析一个老项目的技术栈很多人以为就是看一眼package.json或者requirements.txt列几个框架名字就完事了。真去接手的时候你会发现事情远没有这么简单。完整的“技术栈分析”至少要覆盖以下几个方面核心运行环境是 Node、Java、Python 还是 Go版本多少这决定了你要不要装对应版本的运行时、能不能用新语法、甚至影响后续的部署方式。框架与主依赖前端是 Vue 还是 React后端是 Spring Boot 还是 ExpressORM、状态管理、UI 库选的是哪一套构建与工程化用的是 Webpack、Vite 还是老式 Gulp有没有 Dockerfile、CI 脚本构建链路是否还跑得通隐式约定与历史包袱一些没有写在文档里的约定——比如某个接口返回特定状态码、某些目录结构是约定俗成不能动的、某个配置文件在部署时会被覆盖。这些东西是纯靠静态扫描看不出来的。之前我接手一个老系统只看 package.json 以为是标准 Vue2 ElementUI 项目结果实际跑起来发现内部还嵌了一套 iframe 引入的老 jQuery 页面路由也是双模式混合的。类似这种“隐藏技术栈”才是分析时最需要花心思的地方。2. 用 Claude 分析技术栈的几种主流方式2.1 方式一直接给代码仓做整体目录扫描最简单粗暴的方式就是把项目的根目录结构、关键配置文件直接丢给 Claude让它先做一轮初步判断。我的做法是先在本地生成一份结构清晰的清单不直接把整个仓库交给 Claude因为项目大的话 token 根本塞不下Claude 也没法读完整。用tree或者find命令把目录结构输出到文件重点保留以下几类信息find . -type f \ -not -path ./node_modules/* \ -not -path ./dist/* \ -not -path ./.git/* \ | head -200然后把输出粘贴到 Claude 对话框里给一个明确的指令“根据这份目录结构推断这个项目的技术栈包括前端、后端、构建工具、部署方式。”Claude 会根据目录特征给出初步结论。比如看到src/main/java会判断是 Maven 布局的 Java 项目看到app/pages/components/会判断是类 Next.js 或 Vue 项目结构。这种方式适合快速建立整体认知。2.2 方式二抓取核心配置文件做精确诊断目录结构只是第一层真正能让 Claude 精准说出“这项目用的是什么版本、什么生态”的是那几个核心配置文件。以我这次分析的老项目为例核心配置文件就那么几个文件作用必看指数package.json前端/node 依赖及脚本★★★★★pom.xmlJava 后端依赖管理★★★★★requirements.txtPython 依赖★★★★★Dockerfile容器化构建方式★★★★☆docker-compose.yml本地/部署编排★★★★☆README.md项目说明与启动方式★★★☆☆做法是把这里面的关键片段复制给 Claude而不是直接上传整个文件。比如package.json可能有好几百行直接塞过去效果反而不如只截取dependencies、devDependencies、scripts三个字段来得好。我实际给的指令模板是这样的请根据下面的依赖列表分析这个项目的前端技术栈说明 1. 核心框架及版本 2. 是否使用了构建工具链具体是哪一种 3. 有哪些值得注意的依赖比如 UI 库、状态管理、HTTP 库 4. 根据 scripts 里的命令推断项目是怎么启动和构建的 dependencies: {粘贴 dependencies 内容} devDependencies: {粘贴 devDependencies 内容} scripts: {粘贴 scripts 内容}Claude 给出的分析通常比我们自己扫一眼要细致得多。比如它会指出 jQuery 虽然没直接出现在依赖名单里但某个插件的 peerDependencies 暗示了这个项目引用了 jQuery这种细节光靠人眼确实容易漏。2.3 方式三让 Claude 读代码梳理业务与技术栈的对应关系配置文件只能说明“项目声明了什么”但没法回答一个更关键的问题业务代码里真正把技术栈用在了哪里。比如项目声明了 Redis 依赖但到底用没用声明了消息队列生产环境真的消费了吗这些只有读了核心代码之后才能确认。所以我一般会挑出几个最关键的业务入口文件交给 Claude 细读。这次我选的是后端一个 Controller、一个 Service、一个自定义中间件前端入口文件main.js或app.ts、路由配置、一个核心页面组件提示词比配置文件分析要更具体请阅读以下代码片段判断这个项目中 1. 后端接口是怎么组织的RESTfulRPC还是混合 2. 数据处理链路是怎样的比如从 controller 到 service 到 mapper 3. 有没有用到特殊框架特性如注解、依赖注入、AOP 4. 前端路由是静态配置还是动态注册的 5. 状态管理用的是 Vuex/Pinia/Redux 中的哪一种是否有遵循统一模式这一步能帮我看清项目里“藏着”的东西。之前就是通过这个方式发现某个老项目虽然后端写着 Spring Boot但拦截器里大量使用了原生的HttpServletRequest和重定向逻辑导致很多新特性根本用不上。这种判断光靠看依赖列表是绝无可能得出的。3. 实操过程全记录3.1 我这次实际分析的是一个什么样的项目先交代背景这个项目是一个运行了四五年的中后台管理系统前端是 Vue2后端是 Java Spring Boot。我接手时项目还完整保留着最原始的工程化结构没有做过大规模重构所以分析难度属于中等偏上。整个仓库差不多 800MB其中 node_modules 占了一半还多后端代码大概有 200 多个 Java 文件。从接手到输出一份还算完整的技术栈报告我只花了一个下午。纯粹靠自己看这个量级少说也得两三天。具体流程我拆成了五步下面一步步说。3.2 第一步生成项目全貌清单不急着让 Claude 干活先用工具自己把项目的目录结构打出来。这一步虽然“没有技术含量”但实际上决定了后面 Claude 的分析质量。我用了这样的命令# 文件目录树忽略常见目录 tree -L 3 -I node_modules|dist|build|target|.git project_structure.txt # 统计各目录下的文件数量 find src -type f | sed s|/[^/]*$|| | sort | uniq -c | sort -nr | head -30生成之后我把project_structure.txt直接喂给了 Claude同时附上一句这是一个老项目的目录结构请帮我初步判断它的技术架构、分层方式、模块划分逻辑。Claude 给的反馈会比我预期中更结构化。它会明确指出这个项目是典型的前后端分离架构、前端采用 Vue2 SPA 模式、后端是标准的分层结构controller-service-dao。同时还能指出一些目录命名的历史遗留问题比如有个叫common的包从命名看应该是放公共工具类但实际从结构上看到里面有 controller说明职责可能混乱。3.3 第二步逐个读取关键构建配置拿到初步印象之后我按照“从前端配置到后端配置再到部署配置”的顺序分批读取了这些文件前端目录下的package.json后端目录下的pom.xml根目录的Dockerfile和docker-compose.yml这一轮我做了一个关键操作不直接复制整个文件而是先让 Claude 告诉我它最想先看哪个字段。这样看起来多了一步交互但实际上能有效避免信息过载也让我知道该重点关注什么。以pom.xml为例我截取了parent、properties和dependencies的核心部分配了一句话请分析项目的 Maven 依赖树关注 1. Spring Boot 版本和 Starter 的用法 2. 数据库相关的依赖JDBC、JPA、MyBatis 3. 工具类引用情况 4. 是否有第三方 SDK 的引用Claude 的回答直接把技术栈核心勾勒出来了这是一个 Spring Boot 2.1.x 的项目使用 MyBatis 做持久层数据库是 MySQL集成了 Redis 和 RabbitMQ。它还特意指出从依赖里看不到明确的微服务注册中心所以这个项目很可能是单体架构。3.4 第三步细读核心源码文件配置信息只能反映“表面技术栈”Claude 读代码才能推断“实际技术应用”。我挑了几个有代表性的文件喂给 ClaudeApplication.java入口类——看启动方式、注解用法、组件扫描范围UserController.java典型 Controller——看接口定义风格、参数校验方式、返回结构UserServiceImpl.java核心业务实现——看业务逻辑写在哪一层、事务怎么控制application.yml环境配置——看动态配置、多环境切换方式router/index.js前端路由——看路由组织方式、鉴权逻辑store/index.js状态管理——看状态管理模式、是否有持久化一次性给了 6 个文件之后Claude 自动输出了一个“技术栈画像”画得像模像样。它直接告诉我这个项目的事务管理用的是注解声明式而不是编程式事务MyBatis 用的是 XML 方式而不是注解方式前端的路由守卫里做了大量的用户权限判断状态管理虽然引入了 Vuex但很多组件仍然在用$emit/props进行状态传递说明 Vuex 使用得并不彻底。这一层分析很多是我自己没注意到的比如“Vuex 用得不彻底”这个结论我是没想到 AI 在读代码时能捕捉到这种细节的。3.5 第四步整理输出结构化技术栈报告等 Claude 把各个维度的信息都反馈得差不多之后我让它汇总成一份结构化的报告。这一步用的指令请根据以上分析生成一份完整的项目技术栈报告结构如下 一、技术栈总览前端/后端/数据库/中间件 二、核心框架选型分析 三、代码组织方式说明 四、工程化与部署链路说明 五、存在的历史技术债清单 六、后续可优化方向的建议Claude 输出之后我省略了那些“正确的废话”单独提出了几个我特别关心的点再追问“根据代码结构这个项目是否还能平滑升级到 Vue3 / Spring Boot 3”“如果要拆分成微服务代码里哪些部分耦合度最高”“这个项目里哪些技术选型明显已经落后了”Claude 的回答在这种追问下会更有针对性它会明确指出前端路由是 Vue2 特有的 API升级到 Vue3 需要处理路由和状态管理的兼容问题后端大量使用Autowired字段注入升级到较新版本或者做模块化拆分时会遇到困难。这些结论非常有参考价值。3.6 第五步交叉验证 AI 结论AI 给出的结论不是 100% 可信特别是在代码量巨大的时候它可能漏读关键文件或者过度推断。所以最后一步一定要做交叉验证。我挑了几项 Claude 给出的“关键结论”快速在项目里做了人工核对结论一项目使用 MyBatis 的 XML 配置。核对方式去 resources 目录下找*Mapper.xml文件数量特别多确认属实。结论二后端是单体应用无注册中心。核对方式查看 pom.xml 里没有spring-cloud相关依赖确认属实。结论三前端路由守卫做了权限判断。核对方式打开router/index.js确实看到beforeEach里的一长串逻辑确认属实。我把整个过程总结下来其实完全可以复制到新项目上。4. 常见问题与排查技巧实录4.1 项目太大Claude 分析不了怎么办这是最常遇到的问题。你把整个项目拖进对话框系统直接报超出上下文限制或者生成的结果全是偏概览式的口水话根本没深入到具体细节。我踩过几次坑之后总结出了三招第一招裁剪输入。只给目录结构 核心配置文件让 Claude 先做“侦察式分析”。第二招分模块处理。不要指望一次把整个项目分析完。先确认这个项目有哪些模块比如用户模块、订单模块、支付模块再按模块逐个喂代码。第三招引入代码地图。先用cloc或者tokei之类的工具统计代码行数分布让 Claude 对比各模块规模找出哪些模块代码量大、复杂度高优先分析核心模块。# 统计代码行数分布超好用 cloc src --by-file --csv | sort -t, -k5 -rn | head -20我当时用一个老项目实验src目录下有 300 多个文件光 controller 就有 40 多个。通过 cloc 一统计发现真正代码量最集中的是那两个业务核心模块其他模块基本是增删改查就不用浪费 Claude 的精力了。4.2 Claude 的回答毛估估和实际代码严重不符还有一种情况Claude 在分析时容易凭借“常见经验”脑补给出一个表面上合理、实际上错误的结论。比如它会说“根据路由结构前端使用了动态权限加载机制”但实际项目里根本没有这回事只是预设了几条静态路由。应对方法只有一个每个关键结论都要验证。尤其在技术选型这种事关重大的判断上不能拿 AI 的话直接当真。我习惯用下面这个提示词来减少凭空推断如果你的结论是基于推测请明确标注“推测”并说明推测的依据。 如果不能从提供的代码中直接判断请说“无法从当前信息判断” 不要用“很可能”、“大概率”这类模糊表述。加了这个要求之后Claude 的输出明显老实了哪些是代码里确实有的哪些是它猜的一目了然。4.3 配置文件缺失怎么判断老项目用的是什么老项目嘛最大的痛点就是这不全那也不全。我遇到过连package.json都没有的项目就一个node_modules目录躺在那里都快长毛了。这种时候我会退而求其次走两个方向方向一从依赖目录反推。node_modules里会保留所有已安装包的目录名读一遍目录名就可以还原大部分依赖列表。方向二从代码里反推。搜索import/require/from语句统计高频模块从而推断实际引用的库。写一个简单的脚本统计 import 高频模块grep -h from \|require( -r src/ --include*.js --include*.vue \ | sed s/.*from [\]//; s/[\].*//; s/.*require([\]//; s/[\]).*// \ | sort | uniq -c | sort -rn | head -30把这些模块名喂给 Claude它能非常快地判断出这个项目原先用的技术栈还能顺带提醒哪些包已经年久失修哪些包有严重安全漏洞。4.4 Claude 的分析停留在“技术陈列”没有“业务视角”很多人让 Claude 分析老项目技术栈问来问去就是“用了什么框架、什么版本”。但技术栈分析的最终目的是服务于改造和决策所以还得追问“业务场景里为什么要选这个技术”。我后来改进了一点带业务上下文去问 Claude。比如先介绍一下这个项目是干什么的再让它分析当前技术栈是否与业务场景匹配。例如这是一个面向企业客户的报表系统日均请求量不大但报表计算逻辑复杂。 请根据以下代码和依赖情况结合以上业务特点分析技术栈是否有合理之处。Claude 在获得业务背景后会给出更有价值的判断比如数据库连接池配置明显偏小、缓存方案与业务场景不匹配、消息队列引入得是否必要等。这类分析的实用性远超单纯“列出一串技术名词”。5. 技术栈分析的实际价值与后续扩展5.1 对遗留系统改造的意义接手老项目最首要的目标就是搞清楚“能改、能换、能删”的边界在哪。技术栈分析本质上是给后续改造画地图。举个例子分析过程中发现项目用了一个很老的富文本编辑器依赖这个库五年没有更新了而且有已知的 XSS 漏洞。从技术栈报告里删掉它把它列入“替换清单”这就是一次实打实的安全改造。没有技术栈分析这种隐患可能要在系统上线多年后才暴露。另一个例子项目前端还在用 Sass 的deep样式穿透语法但实际已经换成了 CSS Modules。Claude 读完样式文件后指出deep相关代码在打包之后会出现样式覆盖不一致的问题这个问题靠人肉排查可能要折腾一周。5.2 让技术栈分析成为团队知识资产我习惯把每次用 Claude 做的技术栈分析报告归档进团队的知识库。新同学接手项目先丢一份分析报告给他减少“两眼一抹黑”的阶段。归档时可以简单地用 Markdown 维护一个“项目技术栈档案”内容包括项目名称与简介核心依赖清单含版本启动 / 构建命令模块结构与职责说明已知技术债列表安全风险清单历史改造记录这样长期积累下来团队对老项目的认知就不会只存在某几个老员工脑子里而是沉淀成了可持续查阅的文档。5.3 从“技术栈分析”过渡到“改造方案”做完技术栈分析下一件自然而然想做的事就是“怎么改”。Claude 也可以接着帮你出改造方案。我的做法是把技术栈报告重新丢给它附加一个问题根据这份技术栈分析如果要把这个项目 1. 前端从 Vue2 升级到 Vue3 2. 后端从 Spring Boot 2 升级到 3 3. 数据库连接池替换为另一种实现 请列出主要改造点、可能踩的坑、以及推荐的改造顺序。Claude 给出的建议再结合技术栈结论人工筛选整个改造计划就有了比较扎实的第一版。我自己在这个系列后续的 day3、day4 里会继续记录从分析到改造的完整过程。用 Claude 分析老项目技术栈本质上不是为了炫技而是用一个更高效的外挂大脑帮你节省前期调研时间把精力真正腾出来留给思考、验证和决策。如果你也在跟某个历史悠久、代码成山的项目较劲强烈建议试一下这套思路。