昨天把“只管去写”的第二天任务定成了“把老项目分析清楚”。要处理的项目是个接手快半年的内部系统不是特别大但代码历史悠久中间经过好几轮交接。平时改需求总觉得使不上劲根源只有一个我只知道它“能跑”但不知道它到底是用什么技术栈搭起来的、各个模块之间怎么咬合、哪些地方绝对不能碰。于是这次决定不靠肉眼硬啃而是用 Claude 把这个老项目的技术栈、依赖关系、风险点一次性盘清楚。这篇文章就是完整的实操记录包括我怎么设计提问、怎么喂数据、Claude 给出了什么结论、哪些地方我又人工复核了一遍。如果你手里也有一个“能跑但没人敢动”的老项目这篇应该能帮你省不少时间。1. 为什么要把老项目的技术栈彻底盘一遍老项目最让人头疼的地方不是代码复杂而是“信息断代”。很多逻辑只有老代码自己知道文档早就过期了注释写得像摩斯密码唯一可靠的信息源就是代码本身。在这种前提下任何修改都是在赌运气。1.1 改代码前先拿到一张“地图”我接手这个系统初期接到的第一个需求是加一个导出功能。直觉告诉我应该去看前端列表页结果找了一圈发现真正的导出逻辑在后端某个定时任务模块里而触发方式不是按钮是消息队列。也就是说界面上的操作和后台逻辑之间隔了好几层。如果没有全局视角很容易在错误的位置改代码。用 Claude 分析技术栈本质上是给自己画一张地图。它不需要替我写业务逻辑只需要告诉我这个项目由哪些部分组成每一部分用什么技术它们之间怎么通信。有了地图再动手改代码心里才踏实。1.2 老项目的技术栈往往“过期但稳定”很多老系统对外行来说显得落后——比如还在用某个旧版本框架、没有容器化、构建脚本靠手工执行。但对实际跑业务来说这种组合可能是最稳定的。升级框架反而可能引入兼容性问题把好好的系统改崩。所以分析老项目技术栈的时候目标不是“看它哪里不够新”而是“搞清楚现在的组合是怎么工作的”。判断哪些依赖可以动、哪些不能动前提是先把现状摸透。Claude 在识别版本、梳理依赖关系上很快正好可以替我做这轮初筛。1.3 新同学接手时的第一课如果你刚加入一个团队被分到一个老项目里最忌讳的就是一上来就埋头读代码。先让 Claude 生成技术栈报告再用报告去对照实际代码学习效率会高很多。我这次做完分析之后再回头看那些之前怎么都记不住的模块关系一下就顺了。2. 用 Claude 分析老项目整体思路设计很多人拿到一个项目就往 Claude 里扔文件然后问“这是什么项目”这样也能得到答案但通常比较浅。我的做法是把它拆成几个阶段像审问一样一层层往里问。2.1 先做目录分析再读核心配置Claude 的上下文不是无限的把整个项目所有文件都塞进去既不现实也没必要。目录结构本身已经包含了大量信息src、lib、vendor、dist、node_modules 这些目录的名字和层级能直接反映项目的组织方式和依赖策略。所以我第一轮只给目录树和几个关键配置文件让 Claude 先给出整体判断。确认大方向没错再针对某个具体模块展开深挖。这种方式能大幅节省上下文也让每一步结论都有依据可查。2.2 给 Claude 立一个“工程顾问”人设同样的材料不同的问法结果差异巨大。直接问“这个项目用什么技术栈”Claude 可能会只罗列名字但如果设定角色和输出格式得到的报告质量会明显提升。我一般会在开头加一句“你是资深软件工程师正在接手一个老项目维护任务”再把需要它回答的问题列清楚。这样它会自动按工程实践去补充风险提示和维护建议而不是单纯做名词识别。2.3 要求结构化输出方便后续追踪Claude 直接回答“用了某某框架”是不够的。我要求它以表格或分级列表的形式输出技术栈总览语言、框架、构建工具目录结构与模块对应关系关键依赖及其版本明显过时或高风险的点建议的梳理/升级顺序结构化输出最大的好处是后面可以把它贴进维护文档里甚至交给其他同事直接参考不用二次整理。2.4 记得保留原始证据Claude 的分析过程是黑盒它给出的结论需要能够被回溯验证。因此我在每一轮 prompt 里会要求它在报告末尾附上“哪些结论来自哪些文件和配置”这样我拿到报告后可以去核对不会盲目相信。3. 完整实操记录从目录树到技术栈报告下面就是我用 Claude 分析老项目技术栈的完整操作流程每一步都附上了实际使用的 prompt 和关键输出。你可以直接拿这套流程去套你自己的项目。3.1 准备一个干净的项目快照开始之前先把项目复制一份到临时目录并排除掉乱七八糟的生成文件和依赖目录。不要直接在原项目里操作分析过程中可能会产生临时文件。我是这样处理的# 进入项目根目录的上一级 cp -r /path/to/old-project /tmp/project-snapshot cd /tmp/project-snapshot # 删除明显不需要分析的目录 rm -rf node_modules vendor dist build .git target __pycache__ .next把快照清理干净避免无关内容占用上下文空间。对于大项目这一步非常关键。3.2 生成完整的目录树目录树是 Claude 分析项目的入口。我习惯用tree命令生成没有的话用find也行。限制层级到三层左右既能看清模块划分又不至于太碎。# 三层目录树 tree -L 3 -I node_modules|vendor|dist|build|.git|__pycache__ project_tree.txt生成后的project_tree.txt就是第一份喂给 Claude 的材料。3.3 提取关键配置文件除了目录树还要找出项目里所有带“配置属性”的文件。这些文件是技术栈分析的核心证据前端项目package.json、vue.config.js、webpack.config.js、vite.config.ts后端项目requirements.txt、pom.xml、build.gradle、go.mod、Gemfile通用配置docker-compose.yml、.env.example、README.md、ci配置我直接用文件通配把常见配置都找出来然后复制粘贴进一个汇总文件里作为第二轮分析的输入。3.4 第一轮提问技术栈全景识别第一轮 prompt 我写得比较宽但限定它从给定材料中提取信息不要瞎猜你是资深软件工程师正在接手一个老项目。请基于我提供的目录树和关键配置文件 分析这个项目的技术栈整体情况。要求 1. 说明主要编程语言、运行环境、前端框架、后端框架、数据库类型 2. 说明项目目录划分与各模块可能的职责 3. 挑出所有你认为“明显过时”或“维护风险偏高”的技术点 4. 所有结论必须标注来源哪个文件/哪个目录给你这个判断 5. 输出 Markdown 格式Claude 第一轮返回的报告完整度惊人。它不仅识别出前端基于某款组件库、后端是一个多模块服务还指出项目里存在两个相互冲突的 HTTP 客户端封装建议后续优先统一。这个冲突点是我之前完全没注意到的后来人工验证确实如此。3.5 第二轮提问依赖关系与版本核对第一轮是“面”第二轮我要的是“点”。把第一轮报告的结论作为 prompt 的一部分让 Claude 基于同样的材料进一步深入。你刚才的分析我确认了框架部分。现在请进一步分析依赖 1. 核心依赖有哪些区分生产环境和开发环境 2. 哪些依赖版本偏老列出当前主版本和新版本建议 3. 是否存在重复依赖或相互冲突的库 4. 哪些依赖看起来是项目自研封装是否值得保留 5. 请用表格输出并标注风险等级高/中/低这一步输出的表格我直接整理成了后续维护决策的底稿。比如表格里标注“某个日志库版本存在内存泄漏风险但有大量历史代码依赖这个版本的 API”这就比单纯升级依赖版本有用得多。3.6 第三轮提问生成风险评估与维护建议技术栈识别的终点不是“知道了用什么”而是“接下来怎么办”。第三轮我让 Claude 把前面的分析转成维护路线图。基于最近两轮分析请给出这个老项目的维护建议 1. 如果要做一次技术升级哪些模块应该先动哪些应该最后动 2. 有哪些“动一处可能影响全盘”的耦合点 3. 如果只想保持稳定运行有哪些最小必要的修改建议 4. 列出需要人工深入确认的疑点清单Claude 给出的升级顺序建议很有参考价值它把“先升工具链、再升依赖库、最后升框架”的常规路线结合这个项目实际冲突点做了排序。这些建议虽然不能直接当作正式决策但作为技术方案讨论的起点非常好。4. 实操中的坑Claude 分析老项目踩到的问题与调优用 Claude 分析老项目不是一次就完美的我在实操里踩了好几个坑也总结出对应优化方法。4.1 上下文窗口不够用项目稍微大一点配置文件和目录树加起来文本量很大。如果整个项目塞进去前面的内容到后面被截断导致尾部模块分析质量明显下降。解决办法是分层喂先目录树再核心配置然后挑几个重点模块单独进入。宁可分多次对话也不要一次贪多。我实际测试下来一次对话控制在 8 到 12 个关键文件以内效果最好。4.2 生成的目录树里噪声太多第一次跑分析时我没清理node_modules和dist目录树里铺了好几层依赖包路径白白浪费了上下文空间。后来把生成目录树的命令加上排除项分析准确率立刻上来了。4.3 “依赖”不等于“技术栈”Claude 很容易把任何一个第三方库都写成“核心技术栈”。比如项目里只是某模块用到了一个工具函数库它可能就把这个库列为重要技术依赖放大它的地位。这时候需要人工介入判断哪些库是贯穿全项目的地基哪些只是局部使用的工具。我会在第二轮提问中加一句“请区分核心栈与局部工具库”效果明显改善。4.4 老版本判断不一定准确某个依赖的版本数字Claude 是能识别的但它对该版本过时程度的判断可能基于最新版本的一般认知忽略了企业内部环境的限制。比如某个旧版本框架公共网络已经不太推荐但公司内部的基础组件是基于这个版本封装的动它等于重写一片业务代码。所以凡是 Claude 标注的“高风险版本”我都去官方文档或团队历史记录里核了一遍。核完之后真正要动的可能只剩三分之一。4.5 对自研封装的误判老项目里通常有一层“自研封装”可能是公司内部的公共库也可能是一个老同事自己写的工具模块。Claude 在不了解背景的情况下容易把自研封装当成外部依赖或者反过来把标准库当成自研代码。这一步没法完全自动化必须结合团队内部信息做二次标注。我在最终报告里专门加了一栏“是否为自研封装”把 Claude 无法确认的条目列出来回头找团队老人逐条核实。5. 如何把 Claude 的结论转化成自己的判断Claude 给出了很多结论但最终做判断和行动的仍然是人。这一节聊聊我如何把它的输出打磨成可执行的文档。5.1 从结论中提炼四个层级我会把技术栈清单分成四层核心层语言、运行时、主框架、主数据库支撑层构建工具、测试工具、CI 配置业务组件层项目内自研封装、公共模块局部工具层只在某个功能中使用的第三库这个分层帮我在看报告时快速分清“哪些动不得”和“哪些无所谓”。核心层除非有严重安全风险否则绝不轻易动局部工具层则可以随手替换。5.2 让每条风险都对应一个行动项Claude 可能会说“某个依赖版本过低”这种结论没有行动价值。我会要求它继续回答这个版本过低导致了什么具体问题升级时有哪些 API 兼容风险有没有替代方案把“风险描述”变成“风险清单行动建议”报告才真正有用。5.3 输出一份可追踪的维护文档分析结束不是终点最后要把结果整理成一份“技术栈盘点表”。我的模板大致包括模块名、当前技术/版本、技术分层、风险等级、建议动作、验证状态。这张表放在项目根目录里后续任何人接手都能参照它快速定位问题。我这次做完盘点表之后再跟团队开会聊改造方案效率比之前高很多。因为大家终于能在同一份事实基础上讨论而不是各凭经验凭感觉。5.4 什么时候可以信任 Claude什么时候不能我的经验是Claude 在识别成熟技术栈、梳理配置依赖、判断明显过时项上准确率很高但在判断业务耦合度、自研封装价值、版本升级的真实影响范围时需要人工介入。原因很简单后者依赖业务上下文而 Claude 看到的只有文件和文本。所以我把 Claude 定位成“高强度分析助手”而不是“最终决策者”。它负责快速产出候选结论我负责验证和执行。6. 写在后面的一点实操体会经过这次“只管去写”第二天的实践我对 Claude 分析老项目的理解又深了一层。它最棒的地方不是能识别出技术栈——这个我自己花时间也能做——而是能在一小时里面把这个项目里里外外梳理一遍并帮我发现几个此前完全没注意到的隐患点。比如前面提到的重复 HTTP 封装就是靠它挑出来的。但如果让我给一条最核心的经验我会说喂给 Claude 的材料质量直接决定分析质量。目录干净、配置完整、问题具体Claude 就能给出让人惊喜的报告。反过来随便丢一堆文件进去得到的也只会是一堆泛泛而谈。下一步我打算用同样的流程分析另外几个老模块把整份技术栈盘点表越补越全。毕竟“只管去写”这件事写的不只是代码也包括把旧系统彻底弄明白的耐心和方法。