接手一个老项目的时候最让人头疼的往往不是业务逻辑有多绕而是你根本不知道这个项目是用什么搭起来的。昨天我在“只管去写”系列里整理完第一篇今天继续第二天用 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 | bash2.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.lockClaude 能判断出哪一个是真实使用的包管理器。有些老项目会两个文件都在但只有一个在持续更新这个细节在你后续安装依赖时非常关键。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 标记核心业务模块对应的技术实现方式比如“商品列表页是服务端渲染的”或“订单模块使用了重型图表组件”。这样后续无论是做性能优化还是模块重构都能快速定位“影响面”和“改动成本”。这一步做完技术栈分析这件事才算真正闭环。