企业官网建设流程全解析

1. 项目概述与技术栈分析的思路

1.1 什么是“只管去写(day2)”系列

我最近开了一个叫“只管去写”的系列，说白了就是强迫自己坚持做记录、做输出，每天选一个小目标，不再纠结于“完美准备”，先动手再说。这就是第二天的内容：用 Claude 来分析一个老项目的技术栈。

为什么要选这个主题？因为我手头恰好接手了一个历史包袱很重的老项目，代码量大、结构复杂、文档缺失，光靠肉眼去读，两天都不一定能摸清楚全貌。但用 Claude 这类 AI 辅助工具做一轮系统性的技术栈梳理，效率完全不在一个量级。如果你也经常需要接手旧代码、做遗留系统改造、或者给老模块做技术评估，这篇内容应该能直接帮你省下大半天时间。

1.2 老项目技术栈分析到底在分析什么

分析一个老项目的技术栈，很多人以为就是看一眼package.json或者requirements.txt，列几个框架名字就完事了。真去接手的时候你会发现，事情远没有这么简单。完整的“技术栈分析”至少要覆盖以下几个方面：

• 核心运行环境：是 Node、Java、Python 还是 Go？版本多少？这决定了你要不要装对应版本的运行时、能不能用新语法、甚至影响后续的部署方式。
• 框架与主依赖：前端是 Vue 还是 React？后端是 Spring Boot 还是 Express？ORM、状态管理、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 精准说出“这项目用的是什么版本、什么生态”的，是那几个核心配置文件。

以我这次分析的老项目为例，核心配置文件就那么几个：

做法是：把这里面的关键片段复制给 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. 后端接口是怎么组织的（RESTful？RPC？还是混合？） 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 读代码才能推断“实际技术应用”。

我挑了几个有代表性的文件喂给 Claude：

• Application.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 分析老项目技术栈，本质上不是为了炫技，而是用一个更高效的外挂大脑，帮你节省前期调研时间，把精力真正腾出来留给思考、验证和决策。如果你也在跟某个历史悠久、代码成山的项目较劲，强烈建议试一下这套思路。