★ FEATURED ARTICLE 1. 接手老项目时为什么我选择先让AI做一次技术栈体检接手一个三五年没人动过的老项目最怕的不是代码写得烂而是你根本不知道它烂在哪。我最近就碰到这么一个活儿一个内部管理系统前端页面还能跑后端接口偶尔抽风数据库里躺着几百张表README 只有三行字原作者早就离职了。团队里没人说得清这套东西到底用了哪些框架、哪些库、哪些版本更别提依赖之间有没有冲突。以前遇到这种情况我的做法是硬啃先看package.json或者pom.xml再翻目录结构然后一个个文件点开看 import。运气好半天能摸清个大概运气不好两天都理不顺而且很容易漏掉那些藏在角落里的隐式依赖。这次我换了个思路——让 Claude 先帮我做一轮技术栈分析把体力活交给它我只负责判断和验证。这个思路的核心价值在于AI 擅长的是模式识别和信息归纳人擅长的是判断和决策。老项目的技术栈分析本质上是一个从大量零散文件里提取共性特征的任务这恰好是 AI 的强项。你给它足够的上下文它能在几分钟内给你一份结构化的技术栈清单包括框架、版本、依赖关系、潜在风险点。你要做的是拿着这份清单去验证、去补充、去修正。这篇文章适合几类人看一是刚接手遗留项目、不知道从哪下手的开发者二是想用 AI 提升日常工作效率但不知道怎么落地的人三是对AI 辅助代码分析这个方向感兴趣、想看看实际效果的技术管理者。我会把整个流程拆开讲清楚包括我怎么准备输入、怎么设计提问、怎么验证结果、踩了哪些坑以及最后沉淀下来的一套可复用的方法。需要提前说明的是AI 分析不是银弹。它给你的是一份高置信度的初稿不是最终答案。版本号可能猜错依赖关系可能漏掉某些冷门库它可能压根不认识。但即便如此它帮你省下的时间也是实打实的。下面我按实际操作顺序一步步拆给你看。2. 分析前的准备工作给AI喂什么、怎么喂2.1 先搞清楚老项目的信息分布在打开 Claude 之前我先花十分钟做了一件事把这个老项目的关键信息源列出来。技术栈分析不是把整个代码库丢给 AI 就完事那样既浪费上下文窗口又容易让 AI 抓不住重点。我列了个清单按信息密度从高到低排依赖声明文件package.json、requirements.txt、pom.xml、build.gradle、go.mod这类文件是技术栈的身份证优先级最高。构建与配置文件webpack.config.js、vite.config.ts、tsconfig.json、.babelrc、Dockerfile、docker-compose.yml这些能反映构建工具链和运行环境。入口文件main.js、index.ts、app.py、Application.java从入口能看出框架的初始化方式和核心依赖。目录结构src/下面怎么分的有没有components/、services/、utils/能反映架构风格。CI/CD 配置.github/workflows/、.gitlab-ci.yml、Jenkinsfile能看出部署方式和运行时环境。我实际的做法是先把依赖声明文件和构建配置完整复制出来这是硬信息然后挑三到五个核心入口文件这是软信息目录结构用tree命令生成一份文本深度控制在三层以内。这些加起来通常不会超过几千行完全在 Claude 的处理范围内。2.2 提问的设计比内容本身更重要很多人用 AI 分析代码上来就是一句帮我分析这个项目的技术栈然后贴一堆代码。这样得到的结果往往很泛因为 AI 不知道你要什么粒度、什么维度、什么用途。我这次设计了三个层次的提问逐层递进第一层是事实提取以下是一个老项目的依赖文件和目录结构请列出所有能识别出的技术栈包括语言、框架、构建工具、数据库驱动、测试框架并标注你判断的版本号。第二层是关系分析基于上面的技术栈清单分析这些依赖之间可能存在的版本冲突或兼容性问题特别是那些已经停止维护的库。第三层是风险评估从维护成本角度指出这个技术栈里最需要优先升级或替换的三个部分并说明理由。这样分层的好处是每一层的输出都可以作为下一层的输入而且我能清楚地看到 AI 在哪一层开始编——通常事实提取层最准关系分析层开始有推测风险评估层主观性最强。知道哪层可信、哪层要验证用起来心里就有底。2.3 一个容易被忽略的细节告诉AI项目背景我在提问开头加了一段背景说明大概意思是这是一个内部管理系统日活不高但数据敏感团队只有两三个人维护短期内不打算重写只想在现有基础上做增量开发。这段背景看起来跟技术栈无关但它直接影响 AI 的建议方向。举个例子如果我说这是个高并发的互联网产品AI 可能会建议我把老框架换成最新的高性能方案但我说内部系统、低日活、人手少AI 就会倾向于建议保持稳定、只做必要升级。同样的技术栈不同的背景给出的建议完全不同。这一步很多人会跳过但实际影响很大。提示背景说明不用写太长三五句话把项目规模、团队规模、维护策略说清楚就够了。这三条是影响技术决策最关键的变量。3. 让Claude识别技术栈从依赖文件到完整清单3.1 依赖文件解析AI最擅长的部分我把package.json完整贴给 Claude 之后它的输出让我有点意外——不只是列了个清单还自动做了分类。它把依赖分成了核心运行时依赖构建工具链测试与质量保障工具库四类每一类下面标注了版本号和用途。这个分类方式比我平时手动整理还清晰。更实用的是它对每个依赖都加了一句判断。比如看到moment这个库它标注了已进入维护模式官方建议迁移到 dayjs 或 date-fns看到request这个库它直接标了已废弃建议替换为 axios 或 node-fetch。这些信息如果靠我自己一个个去查少说也得半小时。但这里有个坑我必须提醒AI 对版本号的判断经常出错。它看到react: ^17.0.2能准确识别出是 React 17但如果依赖文件里写的是react: latest或者用了 workspace 协议它就可能猜错。我实际验证下来版本号识别的准确率大概在八成左右剩下两成需要你对着package-lock.json或者yarn.lock去核对。3.2 目录结构分析看出架构风格和隐藏依赖依赖文件只能告诉你用了什么目录结构才能告诉你怎么用的。我把tree生成的目录文本贴给 Claude 之后它给出了几个有意思的判断第一它从src/下面同时存在actions/、reducers/、store/这三个目录判断这个项目用了 Redux而且是比较老式的写法没有用 Redux Toolkit。这个判断后来被我验证是对的。第二它注意到src/utils/下面有个request.js但依赖文件里没有 axios于是推测项目可能自己封装了 fetch 或者用了某个不常见的 HTTP 库。我点开一看果然是用原生XMLHttpRequest手写的请求封装这解释了为什么接口偶尔抽风——没有统一的错误处理和重试机制。第三它从config/目录下同时存在webpack.config.js和vite.config.js判断这个项目可能正在做构建工具迁移但没迁完。这个判断也对了前任开发者起了个头就跑了。这种从结构反推行为的能力是 AI 分析老项目时最有价值的部分。因为老项目最麻烦的就是那些没写在文档里、但实际在跑的隐式约定目录结构往往是唯一的线索。3.3 入口文件解读确认框架和初始化逻辑入口文件是验证 AI 判断的关键。我贴了src/main.js和src/App.jsx两个文件Claude 从中确认了几件事React 版本是 17从ReactDOM.render的写法判断18 会改用createRoot、路由用的是 react-router v5从Switch和component属性的写法判断v6 改成了Routes和element、状态管理确实是 Redux从Provider和store的引入方式判断。这些判断的准确率很高因为入口文件的写法跟框架版本强绑定AI 见过大量同类代码模式识别很准。我实际核对下来入口文件层面的判断基本没错。但有一个地方它判断错了它看到import antd/dist/antd.css这行判断用的是 Ant Design 4.x。实际上项目用的是 3.x因为 4.x 的样式引入方式改成了antd/dist/antd.min.css或者按需引入。这个错误提醒我样式文件的引入路径在不同版本间会变不能只靠这一条判断得结合package.json里的版本号一起看。3.4 把碎片信息拼成完整技术栈清单经过上面三步我手里有了三份输出依赖清单、结构分析、入口解读。我把这三份内容再丢回给 Claude让它合并成一份完整的技术栈清单并且标注每一条的置信度——高置信度是多个信息源交叉验证过的中置信度是单一信息源推断的低置信度是纯猜测。最后得到的清单大概是这个结构类别技术版本置信度备注语言JavaScriptES2018高从语法特征判断前端框架React17.x高入口文件依赖双重确认路由react-router5.x高从 Switch 写法判断状态管理Redux4.x高目录结构入口确认UI 库Ant Design3.x中样式引入路径有歧义构建工具Webpack4.x高配置文件确认构建工具Vite2.x中配置文件存在但可能未启用HTTP原生 XHR-高从 request.js 确认日期库moment2.x高依赖文件确认测试Jest26.x中依赖文件有但目录里没测试文件这份清单不是终点而是起点。它让我在半小时内对一个完全陌生的老项目有了结构化的认知接下来我要做的是验证和补充。4. 交叉验证AI给的结论哪些能信、哪些要自己查4.1 版本号必须对着lock文件核AI 给的版本号我一条条对着package-lock.json核了一遍。结果是这样的主框架React、Redux、react-router的版本判断全对因为入口文件的写法跟版本强绑定工具库moment、lodash的版本判断也对因为依赖文件里写的就是精确版本但构建工具Webpack、Vite的版本判断错了一个——AI 说 Webpack 是 4.x实际 lock 文件里是 5.x因为配置文件里用的还是 4.x 的写法但依赖已经升到 5 了。这个错误很有代表性配置文件的写法往往滞后于实际安装的版本。老项目尤其如此因为没人敢随便改配置但依赖可能被某个自动更新工具升过。所以版本号这件事最终必须以 lock 文件为准AI 的判断只能作为参考。4.2 隐式依赖要靠搜索代码确认AI 从目录结构推测出项目用了 Redux但具体用了哪些中间件redux-thunk、redux-saga、redux-promise它没法从目录看出来。我用了一个简单的办法在项目里全局搜索applyMiddleware这个关键字一下就找到了store/index.js里的配置确认用的是 redux-thunk。类似的隐式依赖还有不少有没有用 polyfill、有没有用 CSS 预处理器、有没有用 GraphQL 客户端。这些都不会直接写在依赖文件的显眼位置但会在代码里留下痕迹。我的做法是列一个待确认清单然后用全局搜索逐个击破。常用的搜索关键词包括applyMiddleware、createProxyMiddleware、less、sass、graphql、i18n。4.3 那些AI判断不了的东西运行时环境和部署方式有一类信息 AI 完全判断不了因为它不在代码里——运行时环境和部署方式。这个老项目跑在什么 Node 版本上用的是 Docker 还是直接部署有没有用 Nginx 做反向代理这些信息决定了你后续能不能升级依赖、能不能改构建配置。我的做法是找运维或者看服务器配置。如果找不到人就看Dockerfile和docker-compose.yml这两个文件通常会写明基础镜像的版本。如果连这个都没有那就看.nvmrc或者engines字段。实在都没有就只能上服务器node -v看一眼。这一步没法偷懒必须实地确认。4.4 验证结果汇总哪些可以直接用哪些要打问号经过一轮验证我把 AI 的输出分成了三档可直接采用主框架及版本、路由方案、状态管理方案、UI 库大类、HTTP 请求方式。这些经过多源交叉验证准确率高。需修正后采用构建工具版本、部分工具库版本。这些 AI 判断有偏差但修正后可用。需自行补充运行时环境、部署方式、隐式中间件、代码规范工具ESLint、Prettier 配置。这些 AI 判断不了必须人工确认。这个分档过程本身就是一种收获因为它让我清楚地知道哪些信息是可靠的、哪些还需要进一步确认避免了盲目相信 AI 输出导致的误判。5. 从技术栈清单到升级决策AI能帮到哪一步5.1 识别技术债重灾区技术栈清单出来后下一步是判断哪些部分需要动、哪些可以先放着。我让 Claude 基于清单做了一轮技术债排序它的判断逻辑是这样的先看这个库是否还在维护再看当前版本距离最新版差了多少个大版本最后看这个库在项目里的使用广度。按这个逻辑它排出了三个重灾区第一是 moment已经进入维护模式而且项目里到处都在用迁移成本高但收益也高第二是 react-router v5距离 v6 差了一个大版本API 变化很大但项目里路由逻辑不复杂迁移可控第三是原生 XHR 封装没有错误重试和统一拦截是接口抽风的根源。这个排序跟我的直觉基本一致但它多给了一个维度使用广度。我原本只考虑了这个库该不该升没考虑升起来要改多少地方。加上使用广度这个维度之后优先级判断就清晰多了——moment 虽然该换但使用太广得排期做XHR 封装虽然土但改动范围小可以立刻动手。5.2 升级路径的可行性分析确定要动哪些之后我让 Claude 针对每一项给出升级路径。这里它的表现有好有坏。好的地方是它对主流库的迁移指南很熟比如 moment 迁 dayjs 的 API 对照、react-router v5 迁 v6 的写法变化它都能给出具体的代码示例。不好的地方是它有时候会低估迁移的连锁反应。举个例子它建议把 react-router 从 v5 升到 v6给出的步骤看起来很简单——把Switch换成Routes、把component换成element。但实际上v6 还改了嵌套路由的写法、改了useHistory为useNavigate、改了重定向的实现方式。这些连锁改动它没一次性说全是我追问之后才补充的。所以我的经验是AI 给的升级路径要当作初稿你得追问还有哪些地方会受影响。多问几轮让它把连锁反应列全再决定要不要动。5.3 哪些建议要果断拒绝AI 有个倾向喜欢推荐最新最好的方案。比如它建议我把 Webpack 换成 Vite、把 Redux 换成 Zustand、把 class 组件全改成函数组件。这些建议单看都没错但放在内部系统、两三个人维护、不打算重写的背景下就是过度工程。我拒绝这类建议的标准很简单如果这个改动不能在一个迭代内完成、且不能明显降低维护成本就不做。Webpack 换 Vite 确实能提升构建速度但这个项目一天构建不了几次收益有限风险却不小。Redux 换 Zustand 代码量能减少但现有 Redux 代码跑得好好的没必要动。这一步其实是整个流程里最考验人的地方。AI 负责给选项人负责做取舍。你得清楚自己的约束条件——团队规模、维护周期、业务优先级——才能判断哪些建议该采纳、哪些该搁置。6. 这套方法踩过的坑和沉淀下来的经验6.1 上下文给太多反而会稀释重点我第一次尝试的时候把整个src/目录的代码都贴给了 Claude想着信息越多越准。结果恰恰相反它被大量业务代码干扰技术栈分析做得又慢又泛还漏掉了几个关键依赖。后来我改成只给依赖文件、配置文件和入口文件准确率反而上去了。这个坑的本质是AI 的注意力是有限的你得把信噪比最高的信息给它。技术栈分析需要的是声明式信息依赖、配置不是实现式信息业务逻辑。把业务代码混进去只会让 AI 分心。6.2 别指望一次提问就拿到完整答案我一开始想省事把所有问题塞进一个提问里结果 AI 的回答很散每个点都浅尝辄止。后来改成事实提取→关系分析→风险评估三轮提问每轮聚焦一个目标输出质量明显提升。这背后的逻辑是复杂任务要拆成有依赖关系的子任务让上一轮的输出成为下一轮的输入。这样 AI 每一轮都有明确的上下文不用同时处理多个目标输出自然更聚焦。6.3 版本号这件事永远以lock文件为准前面提过AI 判断版本号会出错尤其是构建工具和工具库。我后来的做法是AI 给的版本号只作为待验证项最终一律以package-lock.json或yarn.lock为准。如果项目没有 lock 文件有些老项目确实没有那就以node_modules里实际安装的版本为准用npm ls命令查。注意没有 lock 文件的老项目依赖版本可能在不同机器上不一致这本身就是个隐患。如果条件允许建议补一份 lock 文件并提交到版本库。6.4 把分析结果沉淀成文档别只留在对话里AI 分析完如果你不整理过两天就忘了。我的做法是把最终的技术栈清单、验证结果、升级建议整理成一份 Markdown 文档放到项目根目录的docs/下面。这份文档后来成了团队新人的项目入门指南省了我不少重复解释的时间。文档的结构我建议包含四部分技术栈清单含版本和置信度、验证记录哪些核对过、哪些有偏差、风险点列表按优先级排、升级建议含可行性分析。这份文档不用写得多漂亮关键是信息准确、可追溯。6.5 这套方法的边界什么情况下不适合用最后说说这套方法的适用边界。它适合有一定规模、有一定历史、但还有维护价值的项目。如果项目已经决定重写那分析技术栈的意义就不大了直接设计新架构更实际。如果项目特别小比如就几个文件那人工看一遍比 AI 分析还快。另外如果项目涉及敏感数据或核心业务逻辑把代码贴给 AI 之前要确认合规性。我这次处理的是内部管理系统代码里没有用户隐私数据所以可以放心分析。如果换成涉及个人信息的项目就得先做脱敏处理或者只用依赖文件和目录结构做分析不贴具体代码。这套方法我后来又用了两次一次是分析一个 Python 老项目一次是分析一个 Go 微服务流程基本一致只是把依赖文件换成requirements.txt和go.mod。核心逻辑没变AI 做信息提取和归纳人做验证和决策。这个分工一旦理顺接手老项目的心理压力会小很多——你不再是面对一团乱麻而是面对一份待验证的清单。
阅读完成 · 觉得有帮助？
