用Claude Code摸清老项目技术栈：三轮提示词框架与实战记录

“只管去写”系列到了第二天。今天的任务很明确：用Claude分析一个老项目的技术栈。这件事听起来远没有写一个新功能那么有成就感，但只要你接过大半年之前自己写的代码、接过离职同事留下的半成品项目、或者刚入职需要快速搞清一套业务系统的底细，你就会明白：把技术栈摸清楚，往往是重构能不能做、需求排期多久、风险埋在哪里这类决策的基础。以前我全靠肉眼扫目录、翻package.json、再grep几个关键调用，慢是一回事，更麻烦的是总会有漏网之鱼。这次我把整个分析过程交给了Claude Code，让它直接在项目目录里跑了一圈，最后产出了一份能直接归档的结构化报告。这篇就把我用的提示词框架、实际操作记录和几次翻车经历原原本本写出来，给准备接手老项目的朋友一个能直接抄作业的参考。

1. 为什么选择用Claude分析技术栈

1.1 接手老项目，第一件事永远不是改代码

很多人拿到旧项目的第一反应是打开编辑器，找到自己觉得不顺眼的文件，然后开始“优化”。这个冲动我非常理解，但基本都会栽跟头。老项目的特征是文档聊胜于无，甚至根本没有文档；依赖关系盘根错节；技术选型带着浓厚的历史原因，比如当初某个模块赶工期用了不太熟的库，后面的人又在上面叠了一层补丁。这种现状下，你看到的每一段代码都是“果”，“因”藏在技术栈的选择和项目演进过程里。

真正的第一步应该是静态体检：这个项目用了哪些语言和框架，版本大概在什么年代，状态管理是哪种方案，UI库是哪一套，构建工具是webpack还是vite，项目是纯Web还是混合App，有哪些已废弃但还在用的依赖。摸清这张底牌之后，你才敢制定重构计划、安排改造工期、预判哪里会炸。说白了，技术栈分析就是给项目做一次全面体检，比上来就“做手术”稳妥得多。

1.2 传统人工排查方式的问题在哪

过去我一个人分析项目技术栈，常规流程是：先看根目录有没有package.json、pom.xml、requirements.txt这类依赖清单，再看框架标志性文件，比如vue.config.js、tsconfig.json、manifest.json，然后顺着入口文件一个一个翻。这套流程在小项目上还能忍，一旦项目文件数量上了几百上千，效率就断崖式下跌。

更麻烦的是人的注意力有盲区。你可能会因为文件名太普通而错过某个核心依赖，也可能认不出某个没见过的国产组件库，还可能被node_modules里的一堆同名包搞晕。传统方式最典型的失败案例，是把精力花在低价值的文件上，反而漏掉了真正决定架构走向的配置。

我总结了一下人工排查和Claude辅助排查的典型差异：

表格里最后一行“报告产出”其实是容易被忽视的价值：人工分析完，报告往往拖着不写，等真需要的时候信息又过时了。Claude辅助方式则可以把分析和文档生成合并成一步，前后不折腾。

1.3 为什么用Claude Code，而不是网页版对话

有人可能会问：我在网页版打开Claude，把几个关键文件贴进去，不也能分析吗？能，但局限很大。老项目动辄几百个文件，网页版一次上下文塞不了那么多内容，来回翻页只会把对话搞碎。而且网页版看到的只是你喂给它的内容，它没法自己决定“接下来该看一下哪个文件”，更不会主动去检查某个目录下还有什么可疑的配置文件。

Claude Code则不一样。它以命令行工具的方式直接跑在项目目录里，能读文件、能看目录结构，甚至能执行一些检索类命令。它更像一个在你电脑上“远程办公”的实习生：你给它一个任务边界，它可以自己决定先看哪些文件，再顺着线索摸到其他相关文件。整个分析过程也会把“为什么选择看这个文件”的推理带出来。

我用的版本是Claude Code，在终端里和它协作。如果你的编辑环境是VS Code，也可以装官方插件在侧边栏使用，分析逻辑是一样的，差别主要在交互入口。

2. 开工之前：环境准备与启动Claude Code

2.1 安装和身份验证

先说准备工作。Claude Code的运行依赖Node.js环境，所以第一步是确保本地已经装了Node.js和npm。安装完成后，用npm全局安装：

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

安装好之后在终端输入claude，就会进入一个交互式命令行界面。第一次启动会要求完成一次身份验证，按提示操作就行。这一步不复杂，过程中如果遇到权限类报错，比如终端提示npm全局目录没有写入权限，先处理环境问题再往下走，别带着错误继续分析项目，否则后面每个操作都会被环境问题打断。

2.2 进入项目目录，建立会话

启动Claude Code之前，先用cd切到目标项目根目录。这一点很重要：Claude Code的工作目录决定了它能看到的文件范围。如果你站在错误的目录下启动，它分析的就是另一个项目，最后生成的报告会完全跑偏。

我习惯的执行顺序是：

cd ~/work/legacy-project claude

进入交互式会话后，Claude Code会询问是否有权限读取当前目录下的文件。这一步务必允许，否则它只能看到一部分文件列表，分析会残缺。如果你用的是VS Code插件版，打开项目文件夹后再启动，效果等同。

2.3 写清楚角色和任务边界

很多人一上来就直接说“帮我分析一下这个项目的技术栈”，Claude确实能答，但答案会比较泛。老项目分析最怕的就是泛泛而谈，因为“泛”意味着没有证据支撑，你拿不到可核实的细节。

我习惯在开局就把角色和边界定死，提示词类似这样：

你是一个有10年经验的前端架构师。我正在接手一个老项目，需要你在当前目录下完成技术栈分析。 要求： 1. 只做信息收集和分析，不要提出重构方案。 2. 对每个判断都给出文件路径和证据。 3. 不确定的地方明确说“不确定”，不要猜测。 4. 先不要输出长报告，我们一步步来。

之所以强调“不要提出重构方案”，是因为分析阶段一旦混入“这段代码应该用xxx重写”之类的建议，注意力就被带跑了。先让分析纯粹一点，结论更可靠。

3. 技术栈分析的三轮提示词框架

3.1 第一轮：全局侦察，先搞清楚“有什么”

第一轮的目标是建立全局认知，相当于把地图先铺开。我会让Claude先看根目录文件和主配置文件，把技术栈的全貌勾勒出来。示例提示词：

先扫描当前项目的根目录和主配置文件，回答下面几个问题： 1. 项目主要使用什么编程语言和框架？版本大概在什么范围？ 2. 用到了哪些核心依赖？分为“运行时依赖”和“开发依赖”两列出。 3. 项目的构建、编译或打包方案是什么？ 4. 项目里有几个可执行入口？分别对应什么场景？ 每个结论都要附带文件路径和关键代码片段作为证据。

这轮输出通常能帮你建立骨架，但还不够。比如Claude告诉你“这个项目用了Vue”，但你关心的是Vue 2还是Vue 3，以及项目里有没有大量历史遗留的选项式API写法；它说“用了状态管理”，你还要知道具体是vuex还是pinia，是不是已经和项目现状脱节。

3.2 第二轮：按核心链路深挖，搞清“怎么串起来”

第二轮我习惯把关注点放在技术栈的“使用方式”上，而不是只看清单。因为老项目的问题往往不是“用了什么技术”，而是“某项技术是怎么被用起来、又和其他部分怎么纠缠的”。

示例提示词：

现在深入核心模块分析： 1. 主入口文件里如何初始化框架、注册全局组件和路由？ 2. 状态管理方案具体怎么组织，有哪些全局Store，主要负责什么数据？ 3. 项目里有没有混用多种UI库或工具库？如果有，列出各自的使用范围。 4. 网络请求是怎么封装的？用的axios、fetch还是其他方案？ 5. 有没有发现“已声明但未使用”或“明显过时的依赖”？ 请给出文件路径作证据，不确定就用“不确定”标注。

这轮跑完，你会对项目内部结构有比较立体的认知。尤其是“混用多种UI库”这类问题，人工看代码经常上眼就花，Claude反而能在很多文件里同时识别出特征代码，快速锁定混用范围。

3.3 第三轮：产出结构化报告，让结果能复用

前两轮信息已经足够多，第三轮是变成文档。我会让Claude把结果整理成Markdown文件，直接写进项目目录里。这一步要给出格式约束，否则它可能写成一封很长的信，归档成本很高。

把前面的分析结果整理成一份技术栈分析报告，保存到 docs/technology-stack.md。 报告结构： - 项目概览：一句话说明这个项目是做什么的 - 技术栈清单：按类别列出技术点，包含判断依据 - 关键路径说明：入口、路由、状态管理、请求层的代码位置 - 历史遗留与风险：过时依赖、混用方案、疑似废弃代码 - 置信度标注：每条结论标“高置信/中置信/低置信”

“置信度标注”是我后来才加进去的，原因后文会细说。这个约束让报告更诚实，不会通篇都是斩钉截铁的语气，反而降低了误判成本。

4. 实战记录：用Claude分析一个uniapp小程序的旧项目

4.1 项目背景：一个几年没动过的小程序

为了让你看得更具体，我拿最近一次分析的真实场景举例。那是一个用uniapp开发的小程序项目，最早是在HBuilderX里创建的，距今大概有三四年没大改过。目录结构有着非常典型的uniapp老项目特征：根目录下有pages.json、manifest.json，页面文件散落在pages目录，组件写在components下，App.vue里负责全局生命周期。

这种项目最微妙的地方在于：它表面上是Vue项目，实际上又夹着uniapp自带的编译机制和小程序平台差异，处理起来比纯Vue项目麻烦。

4.2 Claude的实际分析结果长什么样

我按第一轮和第二轮的提示词跑完后，Claude给出的技术栈梳理大致如下：

项目概览：一个基于uniapp的跨端小程序项目，使用Vue 2.x语法开发。 技术栈清单： - 框架层：uni-app（通过 manifest.json 和 pages.json 确认） - 视图层：Vue 2.x（入口 App.vue、页面中使用选项式API写法） - 状态管理：vuex（store目录下存在 modules 拆分） - 请求层：基于 Promise 封装的自研请求模块，内部调用 uni.request - UI方案：原生组件 + 少量 uni-ui 组件混用 - 构建发布：依赖HBuilderX云打包，未发现webpack/vite自定义配置 风险点： - 部分页面仍在使用已废弃的 uni.navigateTo 直跳，未收敛到统一路由中间件 - vuex 中部分模块长时间未更新，疑似无人维护 - 存在两套日期处理工具，一套基于 dayjs，一套基于自研工具函数

这个结果和它后面附带的文件路径证据吻合度相当高。我能明显感受到，Claude不是单纯在根据package.json猜答案，而是真的去翻了pages.json、App.vue、main.js和utils目录里的请求封装，才得出的结论。

4.3 分析结果怎么核实：交叉验证的三种方式

AI给出来的东西不能拿过来就信，这一步我必须展开说。即便Claude Code在项目里读取了真实文件，它的归纳过程仍然可能出现偏差，尤其是版本号和依赖关系这两类信息。

我做完分析后，一般会做三层交叉验证：

第一层，核对依赖清单文件。打开package.json，看依赖列表里是否真能找到Claude提到的所有包。比如它说项目用了vuex，那package.json里应该能搜到vuex，同时store目录里要有对应代码；它说用了uni-ui，就要看package.json是否声明了或者源码里是否真的引用了该组件。

第二层，检查目录结构和关键特征文件。比如它识别出是uniapp项目，那pages.json、manifest.json、App.vue这些特征文件必须真实存在。如果连特征文件都没有，却判断成uniapp，那就是幻觉了。我这次分析的例子中，特征文件全部对得上，所以可信度较高。

第三层，抽查关键文件代码片段。比如它判断项目用Vue 2.x，我会打开两个页面文件，确认没有<script setup>、没有defineProps这类Vue 3组合式API写法，同时存在大量this.$emit、this.$store这样的选项式API特征。这类语法级特征很难造假，验证价值很高。

下面这个表是我在分析过程中实际会对照的验证维度，你可以直接存一份：

这套交叉验证花不了多少时间，但能把结论的可靠度从“AI说啥是啥”拉回到“有据可依”。

5. 常见问题与排错实录

5.1 版本号幻觉：AI特别喜欢“猜”版本

上面我特意强调置信度标注，就是因为第一轮分析时踩过坑。Claude在读到项目使用了某个框架之后，有时会顺手补一句“这是Vue 2.x版本，大约在2019年前后”，听起来很专业，但你追问证据，它其实拿不出准确的版本出处。它更多是基于代码特征和项目时间的合理推断，而不是读取了某个确切的版本声明文件。

这个问题的应对方式很简单：在提示词里明确要求“从package.json或锁文件中提取版本信息，如果没有明确记录就写‘未知’”。把“猜测性推断”和“文件证据”分开列，你下判断时才不会把两种不同强度的结论混在一起。

如果你真的很需要精确版本号，直接看依赖清单或者跑一遍npm list --depth=0，那是最准的，不必让AI代劳。

5.2 项目目录太大，扫描遗漏和上下文丢失

老项目的node_modules体积动不动几十万个文件。Claude Code虽然能读目录，但它不可能把整个项目都塞进上下文。有一次我没做任何约束，直接让它“完整分析”，结果它扫了一堆第三方库文件，连主业务代码的边都没摸到，给出的结论毫无参考价值。

正确的姿势是在提示词里主动划范围：

分析时忽略 node_modules、dist、build、unpackage、.git 这些目录。 只关注业务源码和配置文件：src、pages、components、config、根目录配置等。

把范围划清楚之后，Claude的分析效率会高很多。另外，如果项目非常大，可以按目录分片分析，比如先分析pages目录，再分析store和api目录，最后让它合并结论。

5.3 不给结构约束，输出就“没重点”

我试过直接说“帮我分析项目”，结果它输出了一大篇感想式内容，把“技术栈”和“代码风格建议”搅在一起，想找一条明确的结论都要翻半天。后来我把第三节里的格式约束加上，输出立刻清爽很多。

做技术栈分析，本质上是信息提取与归纳的任务，必须给AI一个明确的输出协议，例如“按列表输出”“每条给证据”“不要提建议”。这就像你让一个新人去盘库存，光说“看看有什么”和一页一页对照清单盘出来的结果，质量完全不同。

5.4 常见问题速查表

这几条几乎覆盖了我使用Claude Code做项目分析时遇到的主要问题。特别是第一条“结论缺少文件路径”，是老项目分析最值得坚持的要求：没有证据的结论，宁可不要。

6. 经验与扩展：一次分析的后续价值

6.1 把Claude当成结对程序员，而不是搜索框

经过这几次实操，我最大的体会是：Claude最大的价值不是“告诉你怎么做”，而是“从你扫描不过来的文件里提炼出值得关注的点”。它的角色更像一个思路清晰、体力无限的结对程序员，而不是搜索引擎。所以提示词里一定要给它思考空间，比如“先解释推断过程，再下结论”，这时它给出的答案质量会明显高一截。

老项目分析尤其需要这个特质。单看某个文件时一切都是正常的，问题往往出在“文件与文件的连接处”。Claude能同时翻阅多个文件，在交互里把这种连接关系铺平，这是人工逐文件翻看很难做到的。

6.2 分析报告不要只躺在docs里，要用来指导决策

我过去处理旧项目，技术栈报告写完就扔进docs目录吃灰。这次我刻意让报告服务于后续决策：拿到Claude生成的技术栈清单之后，先圈出风险项，再顺着风险项做重构优先级排序。比如它指出项目里有两套日期处理工具，这就是一次小规模重构的明确切入点；它判断出部分vuex模块无人维护，那么后续新增功能时要谨慎依赖这些模块，必要时提前重构。

这么一来，技术栈分析就不是“完成一个任务”，而是变成项目规划的一环。Claude提供的只是情报，真正做决策的还是人。

6.3 几个让Claude Code更好用的个人习惯

最后分享几个我用了多次之后沉淀下来的习惯。第一，每次分析结束，我会让Claude把结论全文重读一遍，再问一句“你觉得上述结论里哪一条最可能出错”。这个反向提问经常能逼出隐藏的不确定项，非常值得一试。第二，我会把常用分析提示词存成一个独立的提示词文件，下次接到新项目直接改改项目名和目录范围就能复用，不用每次重新磨提示词。第三，分析过程中偶尔遇到Claude报“权限不足”或“文件读取失败”，先检查工作目录是否正确，而不是反复重试可能导致重复消耗的操作。

“只管去写”系列写着写着，我是越来越体会到：会用AI辅助，不等于把判断权交出去。技术栈分析这活儿，恰好是AI负责快、人负责准的典型分工。希望这篇对你有用。