接手老项目最让人心里没底的往往不是业务逻辑有多绕而是你根本不知道这个项目是用什么技术栈堆起来的。尤其是那种没有README、没有文档、连提交记录都断断续续的仓库打开的一瞬间目录结构铺在眼前就像一盘没标食材的冷菜看着挺多但不知道里面放了什么。所以“只管去写”系列第二天我就拿手头一个搁置了很久的老项目开了刀用Claude帮我从头到尾梳理了一遍技术栈。整个过程比我想象中高效得多但也确实踩了不少坑。这篇就把我的分析思路、实操步骤、以及Claude在分析过程中的一些明显短板和应对技巧一并整理出来。1. 动手分析之前先想清楚“技术栈”到底包含哪些层次很多人一提“分析老项目技术栈”第一反应就是打开package.json看一眼依赖了事。但真正接手一个项目时技术栈这词其实涵盖了好几个层次只盯着一份依赖清单根本不够用。1.1 技术栈分析的四个核心维度我习惯把技术栈拆成四个层面来看语言与运行时层项目主要用什么语言写的运行在什么环境上。比如是Python还是JavaScript是跑在Node还是浏览器端有没有涉及多语言混编。框架与核心库层Web框架、UI框架、状态管理、网络请求库这些中坚力量。这一层决定了你写业务代码时接触最多的API风格。工程化与构建层用什么工具做打包、转译、代码检查、测试。老项目的工程化配置往往藏着最多的“历史包袱”比如十年前流行的构建工具、已经停止维护的插件。部署与运行支撑层Dockerfile、Nginx配置、环境变量列表、数据库依赖、对象存储这些和运行环境强相关的东西。这四个层次混在一起才叫真正的“技术栈认知”。只知道用了Vue但不知道Vue是几版本、构建走了哪套链路、上线依赖什么基础设施后面排查问题的时候依然会一头雾水。1.2 分析之前先看一眼目录结构和关键文件在把项目丢给Claude之前我自己会先快速做一轮“人肉扫描”。这样做不是为了替代AI分析而是为了在后续和Claude对话时我手里有足够多的“已知锚点”用来判断AI给的信息靠不靠谱。这一步其实很快大概十来分钟就够了。重点看这几样东西根目录下一共有哪些文件和文件夹有没有明显的主入口比如src、app、lib、core这样的目录名。package.json、requirements.txt、pom.xml、go.mod这类依赖清单文件是否存在文件体量有多大。有没有现成的README、docs目录以及CI配置文件比如.github/workflows、.gitlab-ci.yml。配置文件层面像webpack.config.js、vite.config.ts、tsconfig.json、Dockerfile、docker-compose.yml这些。扫完一遍之后你对项目的老旧程度和复杂度会有一个大致的心理预期。比如看到webpack配置还在用webpack 3的写法就该意识到这套工程链路可能要动大手术再比如根目录既有Python代码又有Node模块那多半是个多语言混合项目。1.3 给Claude准备一份“项目素材包”Claude不像人能自己满仓库乱翻。它的能力边界取决于你在对话窗口里给了它什么材料。所以开始分析之前我会先整理一份“素材包”按优先级排列目录树项目根目录下运行tree命令或手动列一份。最主要的依赖清单文件内容如有多个按语言/模块优先级依次提供。构建工具配置文件webpack/vite/rollup/babel等。入口文件main.py、index.js、src/main.ts这类。部署相关配置Dockerfile、docker-compose、容器的启动脚本等。我个人的习惯是优先给目录树、主依赖清单和入口文件这三样其他的按Claude的反馈逐步补充而不是一次性把整个仓库的源码都塞进去——后者的上下文消耗大效果未必更好。做好这些铺垫之后就该正式把材料发给Claude开始第一轮分析了。2. 用Claude分析老项目技术栈的实操过程2.1 先做宏观判断不要上来就钻细节第一轮对话我不会问得太细核心目标是让Claude帮我建立“项目的宏观画像”。我通常会给出目录树和package.json然后这样问下面是一个老项目的目录结构和依赖清单。请从技术栈分析的角度帮我判断这个项目大概是什么年代的技术体系前端、后端分别用了哪些核心框架和库工程化链路是怎么组织的有没有明显的老旧技术迹象这个问题设计得比较“宽”但信息密度很高。Claude的回答通常会从几个维度展开指出这是一个前后端分离还是传统的服务端渲染项目点出核心框架及大版本分析工程化配置的年代特征并列出它注意到的潜在维护风险。比如我实际拿到的项目Claude根據目录树里有webpack.config.js但没有vite.config.ts依赖里还有jquery和bootstrap这样的老面孔很快就判断出这是一个基于早期Vue 2 Webpack 3体系搭建的传统中后台管理系统前后端分离但前端工程化的现代化程度偏低。这个判断和我自己人肉扫描的结论基本吻合。Claude的优势在于速度快而且能把分散的信息组织成一句完整的结论省去了我零零碎碎翻代码的时间。2.2 按依赖清单逐类拆解找出关键依赖和版本陷阱宏观画像出来之后我会把重心移到“依赖到底有哪些坑”。这一步需要更精细地操作不只要知道用了什么还要知道每个关键依赖处在什么版本、版本之间是否匹配、有没有已经停更的库。我常让Claude做这样一件事接下来请专注分析依赖清单中的版本问题。请把依赖分为框架核心、工具链、测试相关、UI组件库这几类逐类说明每个关键依赖当前的版本是否老旧新旧版本之间存在哪些大版本差异这些差异对现有业务代码可能产生什么影响这一步做出来之后老项目的“技术债清单”基本就浮出水面了。比如那次分析里Claude就明确指出来项目锁定的Vue版本是2.6.x对应的Vue CLI也是老版本整体停留在Vue 2时代并没有Migration到Vue 3的迹象。核心UI库用的是老牌组件库且停留在比较旧的minor版本里面部分组件API和现在主流的用法差异较大。Node版本管理走的是nvm但.nvmrc文件里的版本较老和新版Node的兼容性需要验证。这一轮下来我不仅知道了项目用了什么更知道这些“什么”在现在这个时间点处于什么位置。Claude在版本知识上的储备很足哪怕是冷门点的库它也能讲清楚来龙去脉和迁移成本。2.3 顺着入口文件梳理一次业务主链路依赖清单只能告诉你“项目有哪些材料”但这些材料是怎么被组织起来的还需要顺着入口文件过一遍。这次我会把入口文件、路由配置文件、主模块文件这些“骨架级”代码发给Claude并让它做一次执行链路的梳理这是项目的入口文件和核心路由配置。请帮我梳理一次完整的请求链路从启动入口开始请求进入后经过了哪些中间环节最后如何返回响应前端路由和后端的接口设计是否存在明显关联这一步的产出通常是一段“文字版的调用链描述”比如前端启动时通过入口文件加载全局配置和路由表路由层按路径匹配到页面组件页面组件挂载后调用封装好的请求库请求库再通过拦截器附加令牌并指向后端网关地址。对老项目而言这种链路梳理特别重要因为老项目最常见的毛病就是分层混乱、职责不清一会儿写全局变量、一会儿直接用原生XHR、一会儿又混着Promise封装的请求方法。通过这种入口链路的梳理你能快速定位到“哪些地方的代码风格属于什么时期”以及“后续如果要重写哪些拼接点最容易出问题”。2.4 服务端与数据层的技术判断前端之外老项目往往还捆着一个甚至多个后端服务。如果目录树里有后端代码我通常会在这一轮发给Claude让它做一次服务端和数据层的分析。重点是让Claude回答这样几个问题服务端框架是什么选型思路偏向RESTful API还是服务端渲染配合模板引擎。数据访问层用的是ORM还是原生SQL数据库类型能从代码或配置里推断出来吗。缓存、消息队列、定时任务这些中间件是否在项目里出现分别在什么位置发挥作用。老项目的后端常常更“野生”项目里可能同时存在几个不同的技术片段比如一部分接口走Flask另一部分逻辑塞在Celery的Task里还有的定时脚本独立成模块。Claude在这种混合型项目里最能发挥“快速扫描全局”的优势几分钟就能把后端的技术分布点梳理出来。3. 深度验证如何让Claude的结论落实成可执行的技术文档分析只是第一步难点在于怎么把Claude给到的结论变成一份可以指导后续开发决策的技术文档。这部分我走的是“先让AI视角发散再用工程手段收敛”的路子最终落地的文档才真正发挥了作用。3.1 让Claude输出模块依赖矩阵真正接手老项目的时候最大的痛点是改一个地方牵连出一串问题。所以分析技术栈不能只停在“知道用了哪些库”还要搞清楚“模块之间是怎么依赖的”。我会把项目的模块目录结构发给Claude并提出一个稍复杂的请求请根据目录结构输出一份模块依赖矩阵每个核心模块依赖哪些其他模块模块之间是单向依赖还是双向依赖哪些模块的依赖层级最深、被依赖最多同时请标出可能的循环依赖风险点。这里有个操作技巧Claude对“目录结构”本身的理解并不充分想要让它生成靠谱的依赖矩阵最好给它一份带注释的目录说明。比如在目录树后面用括号标注“这个目录是公共组件”“这个是订单模块”等这样Claude的推理会更有依据不容易把毫无关联的目录硬扯上关系。实际输出的矩阵表格里我一般会保留这样几列模块名称、模块职责、依赖的外部库、被谁依赖、是否有循环引用风险。这样一份矩阵几乎可以直接作为重构讨论时的基础底稿。3.2 拿出关键代码片段检验AI判断是否准确Claude在分析文件结构、依赖清单和宏观框架上表现很好但它偶尔也会“一本正经地胡说八道”尤其是依据不充分的时候会给出听起来合理但实际并不准确的推断。所以我有个自己一直在用的验证方法挑出2~3个核心业务文件发给Claude让它基于这些文件的实际代码“证明”之前的技术栈判断。比如之前它判断项目里用了某种请求封装模式我就会把那个封装文件丢给它问你刚才判断这个项目采用了基于axios二次封装的请求模式。这里有一个疑似请求封装文件的代码片段请分析它实际封装了哪些能力核心逻辑和你之前的判断是否一致这轮操作一方面能验证AI的宏观判断是否经得起代码级的推敲另一方面也能让Claude基于真实代码输出更具体的结论——比如拦截器做了什么处理、错误码怎么解析、请求超时时间怎么设置的。这些细节对后续维护特别有用。我实测下来Claude在这一步往往能发现自己之前的判断有些偏差修正后的结论也更接近真实情况。这种“AI先发散、再拿代码收敛”的方式比一次性让它生成长篇分析要可靠得多。3.3 生成可维护的技术栈说明文档分析到最后产出物应该是一份结构化的技术栈说明文档而不是聊天记录。我会让Claude基于前面的所有结论整理成Markdown格式的技术档案。我给这个任务的模板一般长这样项目基础信息语言、主要框架、定位。前后端技术栈清单按前端、后端、数据层、部署层列出具体技术及版本。工程化链路从代码提交到构建、部署的完整流程描述。技术债清单老旧的依赖、需要重点关注的风险点、升级路径建议。模块依赖矩阵梳理出的核心模块及依赖关系。建议后续重点分析的代码区域根据技术栈短板指出下一步应该深入排查的模块。Claude按这个框架生成的内容会相当完整基本把前面几轮分析里的有效信息都填了进去。我拿到之后再人工过一遍把不符合实际情况的地方改掉补充一些代码里看到但AI没注意到的细节这份文档就可以直接放进项目仓库了。4. 过程中踩过的坑、踩完之后总结的排查技巧整个分析过程并不是一路顺畅的我这几天反复折腾下来积累了一些有用的实战技巧也踩了一些坑。放在这一节集中一说。4.1 上下文窗口限制项目太大塞不进去怎么办老项目最讨厌的地方就是它往往很大动辄几百个文件、几十万行代码。Claude的上下文窗口再怎么大也不可能把整个仓库一次性吞进去。你硬塞的话轻则漏掉关键信息重则回复到一半直接截断。我后来摸索出来的做法是“分层投喂”第一轮只丢目录树和顶层依赖清单让Claude先建立整体框架认知第二轮按需补充入口文件、路由配置、部署文件第三轮才给具体模块的代码片段。每轮之间明确告诉Claude“这是后续补充材料请结合前面已经分析的内容做增量判断”就能在有限窗口内获得尽量全面的分析结果。另一个实用的办法是提前压缩代码把注释全删掉、连续的空行压成一行、把超长的文件拆成关键片段。这些操作能明显减少token占用把有限的窗口留给真正重要的业务代码。4.2 幻觉问题AI说得头头是道但代码里根本不存在分析过程中最干扰判断的就是Claude偶尔会基于常见的工程实践去“脑补”一些项目里根本没有的东西。比如它可能会假设项目用了统一状态管理但实际代码里全是组件内local state也可能随口说某个文件里有某种处理逻辑但那个文件压根不存在。要避免被带偏我的办法是给它立下“证据规则”在分析任务的要求里明确写上“请基于提供的目录和代码文件进行分析不要推测实际并不存在的模块如需判断请注明这是推测”。这个提示在很多时候能有效降低幻觉率。不过最稳妥的办法还是抽查验证。Claude提到的关键结论我至少会找一处代码或配置文件去验证验证不了的就标注为“待确认”不写进最终文档的确定性结论里。4.3 老项目的依赖分析容易“只见树木不见森林”还有一种情况是Claude在分析依赖时过于聚焦在单个库的版本上反而不太在意这些库之间的相互配合是否自洽。举个例子项目里可能同时存在旧版的构建插件和新版运行时依赖彼此之间并不兼容但Claude如果只按库逐个分析就很难发现这种“组合型问题”。针对这个问题我会直接追加一轮“联动分析”request请检查以上依赖之间的兼容性构建工具和它加载的插件loader之间是否存在版本匹配风险运行时框架和官方推荐的辅助库版本是否协调有没有出现“一个新版本库搭配一堆老版本周边库”的典型配置失衡情况设置这样一轮专门的任务Claude往往能从一堆清单里揪出几个真问题这些正是日常维护中最容易碰到的“配置炸弹”。4.4 结构化输出优先于叙事性输出到了分析的后半程我基本不再让Claude写大段描述而是强制它输出表格和列表。比如依赖分析用表格列出“库名、当前版本、状态、需要关注的版本差异、升级建议”模块梳理用矩阵列表呈现依赖关系。这样做的好处是表格天然比大段文字更容易核对也更容易存档成后续跟踪用的半成品文档。更重要的是表格格式会让Claude更倾向于给出确定性结论减少那种模棱两可的“可能”“也许”“建议关注”的车轱辘话——当然适当保留一些风险提示是合理的但每一行都得有明确的行为指向。4.5 人工介入的时机什么时候别依赖AI自己上最后想强调一点AI分析得再好也只能是“辅助”永远取代不了最关键的人工判断。有三类情况我会暂时搁置Claude直接自己上手项目涉及敏感的业务逻辑尤其是有复杂权限控制或资金相关流程的必须亲自确认代码行为。项目结构极度混乱、文件命名完全没有规则Claude连目录结构都很难读出明确含义的时候。需要做团队级技术决策比如“要不要重构、多大代价重构、风险可不可控”的时候——这些决策必须基于人的经验判断而不是AI生成的结论。在这些场景里我更倾向于把AI当作分析辅助工具而不是决策主体。它帮我把信息梳理清楚、把风险点列出来但最终“往左还是往右”仍然得自己拍板。5. 分析完成之后这份认知如何驱动后续开发技术栈分析一旦做完真正值钱的部分才刚刚开始。接下来你怎么利用这份认知决定了这次分析的最终价值。5.1 把技术债转化为可排期的改造清单我拿到技术栈分析文档后第一件事是把它拆成一个带优先级和估时的改造清单。优先级的判断原则很简单阻碍开发效率的排最前威胁稳定性的排次之风格不统一的最后处理。比如一个项目如果还在用非常老的构建链路每次启动开发服务器都要几分钟甚至更久那这应该是第一优先级改造点因为它在持续消耗每个开发者的时间。再比如某个核心依赖已经彻底停止维护且存在已知的安全漏洞那无论改动成本多高都得尽早替换。这个清单不需要一次做完但有了排序团队每迭代一个版本就能往里填一点进度技术债就有了可见的消化轨迹。5.2 定下“新增代码规则”防止旧债越滚越大老项目有个特别坑的趋势新需求在手忙脚乱的时候很容易照着旧代码的风格继续堆代码技术债越滚越厚。所以分析完成之后我会拉着相关同事定一组新增代码规则比如新写的模块必须基于当前技术栈中的推荐做法不再使用旧的不推荐写法新增依赖必须经过备忘单确认防止无意识重复造轮子公共逻辑必须下沉到指定层禁止继续在路由或组件内随意揉大段业务逻辑。这份“新规”不需要多复杂三五条核心约束就够了。关键是让后续写代码时有个共同的参照系不至于一边还债、一边新添窟窿。5.3 形成团队内部的新人上手手册老项目的新人上手成本往往很高靠口口相传效率极低。技术栈分析文档恰好能转变一份“准上手手册”新人来了先读这份文档了解全局框架再对照模块依赖矩阵找自己负责区域的代码位置比一头扎进代码里摸索快得多。我在实际过程中还把文档里“模块职责”的部分和代码路径做了逐一对应相当于给新人画了一张“地图”。虽然做的时候多花了点功夫但后续有同事新加入时这部分的收益立刻就体现出来了问基础问题的人明显少了。写在最后用Claude分析老项目技术栈“随手拉个目录塞给它”当然也能得到答案但真正让它发挥价值的是分析过程中的方法论——先明确分析维度、再分层投喂素材、然后验证结论、最后落成文档和行动清单。这套流程走下来AI就不只是聊天的元助手而是一个能参与工程诊断的得力工具。我个人的体会是老项目最忌讳的是一上来就想重构技术栈分析的意义更多在于“先看懂再动手”。看懂了哪里该改、哪里能改、哪里动了有风险后续的每一步才走得踏实。如果你手头也有个说不清来路的老项目拿这个方法试一轮分析出来的信息可能比你想的丰富得多。下一步我大概率会拿这套分析结果去试着重构其中一个核心模块到时候再整理新的实战记录出来。