“只管去写”系列到了第二天。今天的任务很明确用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辅助方式依赖清单核对挨个看package.json对版本号逐条分析一次读全项目依赖并按类型归类框架识别凭经验认特征文件从目录结构、语法特征、配置项三方面交叉判断模块关系梳理靠grep和跳转容易迷失能顺着引用链解释模块间的依赖与调用关系历史包袱识别依赖个人记忆能主动提示常见废弃用法和兼容性风险报告产出自己写文档耗时且容易过时可直接生成结构化Markdown报告表格里最后一行“报告产出”其实是容易被忽视的价值人工分析完报告往往拖着不写等真需要的时候信息又过时了。Claude辅助方式则可以把分析和文档生成合并成一步前后不折腾。1.3 为什么用Claude Code而不是网页版对话有人可能会问我在网页版打开Claude把几个关键文件贴进去不也能分析吗能但局限很大。老项目动辄几百个文件网页版一次上下文塞不了那么多内容来回翻页只会把对话搞碎。而且网页版看到的只是你喂给它的内容它没法自己决定“接下来该看一下哪个文件”更不会主动去检查某个目录下还有什么可疑的配置文件。Claude Code则不一样。它以命令行工具的方式直接跑在项目目录里能读文件、能看目录结构甚至能执行一些检索类命令。它更像一个在你电脑上“远程办公”的实习生你给它一个任务边界它可以自己决定先看哪些文件再顺着线索摸到其他相关文件。整个分析过程也会把“为什么选择看这个文件”的推理带出来。我用的版本是Claude Code在终端里和它协作。如果你的编辑环境是VS Code也可以装官方插件在侧边栏使用分析逻辑是一样的差别主要在交互入口。2. 开工之前环境准备与启动Claude Code2.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写法 - 状态管理vuexstore目录下存在 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特征。这类语法级特征很难造假验证价值很高。下面这个表是我在分析过程中实际会对照的验证维度你可以直接存一份Claude结论类型验证方法典型证据框架判断特征文件存在性pages.json、manifest.json、main.jsVue版本判断代码语法特征是否存在script setup、组合式API状态管理识别目录与依赖核对store目录、package.json依赖项构建方案识别配置文件存在性vite.config.*、vue.config.*、webpack.config.*UI库识别引用语句与依赖核对import语句、组件前缀、依赖清单历史遗留风险抽查指定文件代码已废弃API调用、重复工具函数这套交叉验证花不了多少时间但能把结论的可靠度从“AI说啥是啥”拉回到“有据可依”。5. 常见问题与排错实录5.1 版本号幻觉AI特别喜欢“猜”版本上面我特意强调置信度标注就是因为第一轮分析时踩过坑。Claude在读到项目使用了某个框架之后有时会顺手补一句“这是Vue 2.x版本大约在2019年前后”听起来很专业但你追问证据它其实拿不出准确的版本出处。它更多是基于代码特征和项目时间的合理推断而不是读取了某个确切的版本声明文件。这个问题的应对方式很简单在提示词里明确要求“从package.json或锁文件中提取版本信息如果没有明确记录就写‘未知’”。把“猜测性推断”和“文件证据”分开列你下判断时才不会把两种不同强度的结论混在一起。如果你真的很需要精确版本号直接看依赖清单或者跑一遍npm list --depth0那是最准的不必让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 常见问题速查表问题现象可能原因解决办法结论缺少文件路径提示词没要求证据强制每条结论附带文件路径:行号版本号不准AI进行推断而非读取只认package.json或锁文件证据扫描跑到第三方库里没排除依赖目录提示词里声明忽略node_modules等报告混入重构建议任务边界不清开局明确“只分析不提方案”大型项目上下文不足单次让AI处理过多内容分目录、分模块多次分析后合并输出过长难以归档没有格式模板约束指定Markdown结构和标题层级这几条几乎覆盖了我使用Claude Code做项目分析时遇到的主要问题。特别是第一条“结论缺少文件路径”是老项目分析最值得坚持的要求没有证据的结论宁可不要。6. 经验与扩展一次分析的后续价值6.1 把Claude当成结对程序员而不是搜索框经过这几次实操我最大的体会是Claude最大的价值不是“告诉你怎么做”而是“从你扫描不过来的文件里提炼出值得关注的点”。它的角色更像一个思路清晰、体力无限的结对程序员而不是搜索引擎。所以提示词里一定要给它思考空间比如“先解释推断过程再下结论”这时它给出的答案质量会明显高一截。老项目分析尤其需要这个特质。单看某个文件时一切都是正常的问题往往出在“文件与文件的连接处”。Claude能同时翻阅多个文件在交互里把这种连接关系铺平这是人工逐文件翻看很难做到的。6.2 分析报告不要只躺在docs里要用来指导决策我过去处理旧项目技术栈报告写完就扔进docs目录吃灰。这次我刻意让报告服务于后续决策拿到Claude生成的技术栈清单之后先圈出风险项再顺着风险项做重构优先级排序。比如它指出项目里有两套日期处理工具这就是一次小规模重构的明确切入点它判断出部分vuex模块无人维护那么后续新增功能时要谨慎依赖这些模块必要时提前重构。这么一来技术栈分析就不是“完成一个任务”而是变成项目规划的一环。Claude提供的只是情报真正做决策的还是人。6.3 几个让Claude Code更好用的个人习惯最后分享几个我用了多次之后沉淀下来的习惯。第一每次分析结束我会让Claude把结论全文重读一遍再问一句“你觉得上述结论里哪一条最可能出错”。这个反向提问经常能逼出隐藏的不确定项非常值得一试。第二我会把常用分析提示词存成一个独立的提示词文件下次接到新项目直接改改项目名和目录范围就能复用不用每次重新磨提示词。第三分析过程中偶尔遇到Claude报“权限不足”或“文件读取失败”先检查工作目录是否正确而不是反复重试可能导致重复消耗的操作。“只管去写”系列写着写着我是越来越体会到会用AI辅助不等于把判断权交出去。技术栈分析这活儿恰好是AI负责快、人负责准的典型分工。希望这篇对你有用。
