接手一个老项目的时候，最让人头疼的往往不是业务逻辑有多绕，而是你根本不知道这个项目是用什么搭起来的。昨天我在“只管去写”系列里整理完第一篇，今天继续第二天：用 Claude 分析老项目技术栈。这件事听起来简单，真做起来你会发现，它不光是“看几个配置文件”的问题，更多是在一堆历史债里快速找到“哪里是地基，哪里是可有可无的装饰”。

Claude 在代码分析这件事上比传统搜索工具强在哪？最核心的一点是它能直接读文件、看目录结构、理解上下文，然后给出带结论的分析报告，而不是给你一堆搜索结果让你自己拼。这篇文章我会把你带进实战现场：从装好 Claude Code、接入老项目，到让它逐层拆解依赖、判断框架、识别构建工具，最后产出一份能直接拿去汇报或指导重构的技术栈清单。适合刚接触 AI 辅助开发、或者正愁不知道老项目从哪里下手的同学。

1. 为什么老项目技术栈这么难啃，以及 Claude 到底能帮什么忙

1.1 老项目技术栈分析的经典困境

很多同学接手的所谓“老项目”，不是指代码写得老，而是指它已经经过了好几轮人的手。每一任维护者可能都往里面加了自己的偏好：有人喜欢用 jQuery 插件，有人偷偷引入了一个不知名的 UI 库，还有人把构建工具从 Webpack 换成了 Vite 但没清理干净配置文件。等你接手的时候，node_modules里躺着几千个包，package.json里的依赖列表长得像一本电话簿。

更麻烦的是，老项目往往没有文档。我见过不少项目，连 README 都是复制粘贴的默认模板，里面写着一句“This is a Vue project”就没了。你跑去问之前的负责人，对方要么离职了，要么自己也记不清了。这时候摆在面前的路只有几条：翻源码硬啃、问同事、或者用工具扫。但翻源码效率极低，问同事可能得到的信息已经过时，而传统扫描工具只能告诉你“有哪些文件”，没法告诉你“这些文件之间的关系”和“当初为什么这么选”。

1.2 Claude 在这个场景里的独特价值

Claude 处理这件事的逻辑和人很接近：先看项目结构，再读关键配置文件，然后深入源码验证，最后汇总成结论。你可以把它理解成一个思路清晰、阅读速度极快、还不会累的结对程序员。

具体来说，它有几个传统工具不具备的优势。第一，它能跨文件建立联系。比如你让它找“项目里用了什么状态管理方案”，它会从package.json里发现vuex或pinia，再去src/store目录确认实际用法，最后结合入口文件判断是整项目使用还是某个模块单独使用。第二，它能帮你区分“声明依赖”和“实际依赖”。很多老项目里声明了一堆没用的包，Claude 能通过搜索引用频率帮你筛出真正被代码使用的部分。第三，它能输出人类能直接理解的分析结论，而不是一堆原始数据。

所以实际上，Claude 在技术栈分析里扮演的角色更像“带经验的同事”而不是“扫描仪”。这一点，是它和 grep、dependency-cruiser、Madge 这类纯工具最大的区别。后面我会带你一步一步把它的能力用在真实项目上。

2. 开工准备：Claude Code 的安装与项目接入

2.1 安装 Claude Code 的两种方式

要完成这次技术栈分析，我用的主力工具是 Claude Code。安装方式我踩过几次坑，这里直接给你整理出比较顺畅的路径。

如果系统里有 Node.js，最直接的方式是用 npm 全局安装。打开终端执行：

npm install -g @anthropic-ai/claude-code

装完之后确认一下版本，能正常输出版本号就说明安装成功：

claude --version

如果你的机器上还没有 Node.js 环境，或者不想为了一个命令行工具去折腾环境，可以改用原生安装器。Claude Code 官方提供了一键安装脚本，在终端里执行它会自动下载对应平台的二进制包，这种方式的好处是不依赖 npm registry 的网速，装完直接就能用：

curl -fsSL https://claude.ai/install.sh | bash

2.2 将 Claude Code 接入老项目目录

装好只是第一步，真正分析前要把它“带进”项目。我最推荐的做法是在项目根目录下直接启动 Claude Code，这样它默认就能读到整个项目文件。进入项目目录后执行：

cd /path/to/legacy-project claude

启动之后它会进入交互模式，你可以用自然语言给它派活。不过这里有个很多人忽略的细节：Claude Code 默认会扫描当前目录下的文件，但有些目录它访问起来权限受限。老项目里常见的node_modules、dist、.git这类目录，如果不需要它读，最好在启动时配置排除，这样能大幅提升分析速度，也避免它被无关文件干扰判断。

配置方式是项目根目录建一个.claudeignore文件，写上：

node_modules/ dist/ .git/ coverage/

这一步看起来不起眼，但实际体验差别很大。我在第一次分析时没加排除，Claude 光是扫node_modules里的文件就花了很久，再加上那里面文件结构复杂，偶尔还会让它产生答非所问的情况。加完排除之后，整个分析过程清爽了很多，它把注意力放到了真正该看的源码目录上。

3. 用 Claude 分析老项目技术栈的完整实操流程

3.1 让 Claude 先“读”懂项目整体结构

进入交互模式之后，别急着问“这个项目用什么技术栈”，这个问题太笼统，AI 给出来的答案容易停留在表面。我现在习惯先让它建立整体认知，再逐层细化。

第一轮对话我会这样提问：

先看一下这个项目的根目录结构，把一级、二级目录列出来，并尝试判断每个目录的大致用途。顺便找出所有关键配置文件（比如 package.json、requirements.txt、go.mod、pom.xml 等），告诉我你发现了什么。

Claude Code 的厉害之处在于它会真实去读文件，而不是凭猜测回答。它会返回类似这样的分析：根目录下有src/（源码）、config/（环境配置）、scripts/（自建脚本）、tests/（测试），然后指出package.json里同时出现了webpack和vite的依赖，怀疑是迁移过程中的遗留问题。

这一步的目的不是得到正确答案，而是让 Claude 先摸清项目的骨架。有了这个骨架，后面每一步的提问都会精准得多。就像你到一个陌生城市，先看地图再走路，就不会迷失方向。

3.2 锁定核心依赖清单与版本分布

有了目录结构之后，下一步是让它深入分析依赖。这里有个关键技巧：不要只看package.json里的dependencies和devDependencies，还有lock文件能提供更精确的版本信息。

我会这样继续提问：

读取项目的 package.json 和 lock 文件（如果存在的话），把 dependencies 和 devDependencies 分开整理成表格。对于每一个依赖，标注它的大版本号，并判断它是构建工具、UI 库、状态管理、路由、HTTP 请求库还是其他类别。

Claude 会返回一张清晰的分类表。比如它会指出 Vue 2.6.x、Vue Router 3.x、Vuex 3.x 这套组合，然后顺带提醒你“这些都是 Vue 2 生态的配套版本，如果项目没有特殊原因，这应该是一个基于 Vue 2 的 SPA 应用”。这种推断能力来源于它学习了大量项目的真实组合模式，知道哪个版本配哪个框架是合理搭配。

额外提醒一句：如果项目里同时存在package-lock.json和yarn.lock，Claude 能判断出哪一个是真实使用的包管理器。有些老项目会两个文件都在，但只有一个在持续更新，这个细节在你后续安装依赖时非常关键。

3.3 判断前端框架、UI 库与构建工具

依赖清单列出之后，下一步要验证这些依赖是不是真正被项目使用。很多老项目依赖声明和实际使用严重不符，之前带我入行的前辈说过一句话：“看项目技术栈，不能看它装了啥，要看它写了啥。”

这时候我建议让 Claude 做源码层面的引用分析。提问方式：

在 src 目录下搜索 import/require 语句，统计每个依赖在源码里的实际引用次数。重点关注 Vue/React 类框架、UI 组件库、HTTP 请求库和状态管理库的实际使用情况。如果发现某个依赖被大批量引用，说明它是核心依赖；如果发现某些声明的依赖在源码里几乎搜不到引用，请单独列出来。

这一步做完，你会得到比任何扫描工具都直观的结果。Claude 会给出类似这样的判断：“echarts 在 14 个文件中被引用，是核心图表库；qrcode 插件只在 1 个老页面里用到，可能只是当时临时需求引入的。”

判断完引用情况，构建工具也要确认一遍。老项目最常见的情况是 Webpack 配置过时，或者升到一半保留了新旧两套配置。让 Claude 读取webpack.config.js、vue.config.js、vite.config.ts这类文件，它会说出构建入口、插件体系、代理配置、环境变量分发方式。这些信息直接决定了你之后改这个项目构建流程的代价。

3.4 识别后端服务与接口组织方式

很多所谓“老项目”其实前后端一体，Claude 在这时候能帮你判断哪些部分属于后端逻辑。我会让它看几个常见信号：项目里是否存在server、api、routes、controllers这类目录，是否有Express、Koa、Spring Boot相关依赖，接口代码是集中在一个api/目录还是散落在页面组件里。

合理的问题是：

判断这个项目是否包含后端代码。如果包含，说明后端使用了什么框架、采用什么模式（MVC/MVP/服务端渲染等）、接口如何组织、数据层用的是 ORM 还是原生 SQL。

有些项目能在这一步挖出意想不到的信息：比如看起来是个前端项目，其实里面有 Node 中间层，用的还是老版本的 Express 4，并且在用已经被废弃的request库发 HTTP 请求。这些历史包袱你当下不用立即处理，但知道了比不知道强太多。

3.5 输出完整技术栈清单并标注风险点

当上面每个维度的信息都拿到手之后，最后让 Claude 整合成一份结构化的技术栈清单。这一步我会额外要求它标注每个组件的“活跃度”和“风险等级”。

参考提问：

基于当前分析，把项目技术栈整理成一份清单，包含：框架与核心库、版本号、用途、源码中的引用热度、风险等级（高/中/低）和简短说明。风险等级根据版本是否处于维护期、是否匹配当前主流生态、是否存在安全漏洞趋势来判断。

这份清单的价值在于，它同时解决了“这个项目是基于什么搭的”和“这个项目有哪些坑可能埋着雷”这两个问题。比如它会告诉你 Vue 2.6.14 本身已经停止维护，UI 库 ant-design-vue 还在 1.x，版本过低导致无法使用新版 API。这些风险点就是你后续重构的起点。

4. 分析过程中的典型问题与排查技巧实录

4.1 依赖信息不完整时如何逼出有效结论

实战中经常遇到一种尴尬情况：项目没有package.json，或者只有requirements.txt但里面只有几个包名没有版本号。这时候 Claude 的阅读能力依然能用，但你的提问方式得调整。

我会这样处理：放弃依赖文件，直接让它从源码反推。比如 Python 老项目，让它看import语句、settings.py里的安装应用列表、urls.py里的路由配置，它基本能判断出 Django 版本和插件体系。前端项目如果没了 package.json，就看index.html里script标签引入了什么 CDN 链接，再配合全局变量名（比如window.$、window.Vue）推断库类型。

这时候的提问可以改成：

项目没有完整的依赖清单。请通过源码中的 import、require、script 引用、全局变量等方式，尽力还原它实际依赖的第三方库，并标注你的判断依据和置信度。

Claude 会输出一批带置信度的猜测项。置信度高的，基本可以确认；置信度低的，再人工验证。这比从零开始 grep 快得多。

4.2 分析结果与预期明显不符时怎么处理

有时候 Claude 给出的结论跟你实际了解的情况相反。比如你明明知道这是个 React 项目，它却一口咬定 Vue，那多半是你给了它一个错误的上下文，或者它的分析被某些文件带偏了。

我在日常使用里养成了追问的习惯。不会直接采信第一次输出，而是继续对话：

你刚才的判断和我的了解不一致。能不能把你判断的依据具体到文件和代码片段？重点检查入口文件（main.js/main.tsx/index.js）以及根组件挂载方式。

Claude Code 这时候会返回具体的证据链，例如“src/main.js里用了document.querySelector('#root')配合createRoot，这是 React 的挂载方式”。如果它真的错了，你也能从它的分析逻辑里看到问题出在哪——通常是某些配置文件残留误导了它。

还有一个小技巧：如果对话中 Claude 反复出现同一个错误判断，直接开一个新的对话会话，重新描述项目背景。上下文污染在长对话里很难避免，重开一个会话往往立刻恢复准确。

4.3 混合技术栈项目容易踩的识别坑

老项目里还有一种高发情况：同一个项目里同时存在 Vue 和 React、jQuery 和现代框架共存、或者多页面应用里每个页面各用各的技术。Claude 在这种场景下特别容易给出“一元化”的错误结论，因为它默认你问的是一个统一技术栈的项目。

我的对策是提前在提问里强调“请分开分析每个模块/页面”，并且让它按目录维度拆分：

这个项目可能是混合技术栈。请先识别项目中是否存在多个独立的前端应用或页面入口，然后按入口分别列出每个子应用使用的框架、UI 库和构建方式。

这样 Claude 会切换成“分而治之”的模式，它会告诉你admin/目录是 React 的，h5/目录是 Vue 的，根目录是 Express 服务。这种拆分结果才是技术栈全景图，而不是把所有东西混在一起，最后输出一团浆糊。

5. 分析结果拿到手之后怎么落地

5.1 把技术栈清单沉淀成项目文档

很多人分析完就结束了，转头忘得一干二净。我的习惯是让 Claude 直接把分析结果转成一份技术文档，我称之为“项目现状说明书”。

会让它按这个结构输出，再人工微调后放进仓库的docs/目录：

• 项目基本概览：业务方向、入口、部署方式
• 前端技术栈：框架、UI 库、状态管理、路由、HTTP、构建工具
• 后端技术栈（如果存在）：运行时、框架、ORM、数据库访问方式
• 核心业务模块索引：每个模块对应的代码目录和技术特征
• 已知风险项：过版本依赖、废弃库、找不到归属的代码块

这份文档最大的价值不在于描述现状，而在于给后来人省时间。你写完之后，下一个接手这个项目的人打开docs/current-stack.md就能知道所有关键信息，不用重新踩一遍你这次分析的流程。这本身也是对自己工作成果的沉淀。

5.2 和团队协作时怎么用这份分析结论

如果你是团队协作，这份技术栈分析就是你和其他工程师沟通的通用语言。常见用法有几种：在技术评审会上分享风险项列表，让产品和研发对重构优先级达成一致；在招聘面试时让候选人基于这份文档快速理解项目；在制定排期时作为估算工作量的参考依据。

我用 Claude 分析完之后，通常会把它生成的风险清单贴到项目的 issue 里，每条标注涉及目录、风险类型和建议处理时间。比如“UI 库版本过低，影响新功能开发时组件复用效率，建议在下次迭代中评估升级成本”这类描述，比光说一句“技术债严重”实在得多。

5.3 由技术栈清单推导渐进式重构路径

分析完技术栈之后，自然想到的是下一步怎么办。但我不建议直接推倒重来，绝大多数老项目的正确做法是渐进式重构。Claude 分析出来的风险等级刚好可以作为重构优先级的参考。

我会继续追问：

基于这个项目的技术栈现状，如果目标是用 3 个月时间逐步降低维护成本，请列出分阶段的改造建议。每阶段给出改造范围、引入的新技术、预期收益和风险。

它给给到的建议往往非常务实：先升级锁定文件的依赖版本到安全线，再抽离高频复用的业务组件，然后引入新路由或状态管理方案，最后才是考虑整体框架迁移。这样每一步都是可控的，不会把项目推到“不改则已、一改全崩”的悬崖边。

6. 几次实操下来，我最想提醒你的几件事

6.1 锁文件比声明文件可靠得多

分析技术栈时，package.json里的版本号往往带有^或~，它表达的是一个版本范围，而不是实际安装版本。真正精确的版本信息在 lock 文件里。所以如果你只让 Claude 看 package.json，得到的版本可能是错的。我会在提问时专门指定它去读package-lock.json或yarn.lock，有时候同一个依赖在 lock 文件和 package.json 里显示的版本差距很大，这种差异本身就是排查线上 bug 的关键线索。

6.2 每一次 AI 分析结论都要经过关键点人工复核

Claude 再聪明，也是基于概率在做推断。对于老项目这种充满历史包袱的场景，它的错误率并不会低到可以完全信任。我给自己定了一条规矩：Claude 给出的结论里，凡是涉及“项目入口”“主框架”“部署方式”这三个核心点的，必须人工打开对应文件确认一遍。其他边缘信息可以先记录，等用到时再验证。这样做既保证了效率，也没把安全底线丢掉。

6.3 提问方式决定了分析质量，精准提问是核心竞争力

同样一个项目，第一次我用“分析这个项目的技术栈”收尾，得到一份泛泛的列表。第二次我改成“分析项目中实际被使用的依赖，按模块维度拆分，标注引用次数和风险级别”，得到了能直接落地的报告。差异背后就是提问的颗粒度。AI 工具不会主动替你思考，你把问题描述得越接近真实业务决策，它返回结果的实用价值就越高。多花三十秒把问题写清楚，远比事后反复追问高效。

6.4 别忘了让 Claude 把技术栈分析和业务模块关联起来

技术栈不能脱离业务存在。同一个 Vue 项目，做电商和做后台管理，代码组织的逻辑完全不同。在完整分析流程里，我会额外让 Claude 标记核心业务模块对应的技术实现方式，比如“商品列表页是服务端渲染的”或“订单模块使用了重型图表组件”。这样后续无论是做性能优化还是模块重构，都能快速定位“影响面”和“改动成本”。这一步做完，技术栈分析这件事才算真正闭环。