企业官网建设流程全解析

接手老项目这事，干得多了就明白：真正让人头疼的从来不是需求本身，而是你连它用什么写的都要先猜半天。前阵子我在做某内部系统的交接，整个仓库既没有清晰的README，也没有统一的项目说明，只看到一堆混着旧版前端和后端逻辑的文件。按老办法，得人工翻目录、读依赖、审代码，一两天就耗进去了。后来我用Claude做了几次技术栈梳理，发现整个"摸底"过程能压缩到一两个小时，准确率也足够拿来做后续改造方案。这篇文章就当是"只管去写"系列的第二篇，聊一次完整的"用Claude分析老项目技术栈"的实战过程：怎么喂信息、怎么提问、怎么验证AI给的结论，最后附上可以直接抄的提示词和踩坑记录。

1. 老项目为什么总是让人头大

1.1 明面上的文档可以信，但不能只信文档

很多项目的问题在于——如果它文档齐全、结构清晰，你根本不需要费劲分析。需要分析的老项目，几乎无一例外是"四不像"：某个页面是服务端渲染的模板，某个目录里又躺着一套半成品的单页应用；依赖清单上一大堆包，实际跑起来可能只用了其中三分之一；代码里既有Python的影子，又在某个工具脚本里甩出PHP。这种状态不是开发者偷懒，而是项目经历过太多人、太多时期，每个人都在上面留了自己的痕迹。

更麻烦的是，老项目的文档往往和代码严重脱节。README可能写的是三年前的架构，目录结构已经面目全非。不看代码吧，心里没底；全量翻代码吧，几百个文件堆在那里，没人有这个耐心。这时候一个能快速"读文章、抓重点"的AI助手，价值就体现出来了——它不是替你读代码，而是帮你把散落在各个文件里的技术线索串起来，让你少走弯路。

1.2 AI与静态工具的分工边界

你可能想，分析技术栈不是有现成工具吗？确实有，像grep、依赖扫描器、IDE自带的结构分析都很好用。但它们的强项是"找已知"：你明确知道要找什么，再让工具把匹配项捞出来。老项目分析最大的问题恰恰是"已知"太少，你连该搜什么关键词都没谱。比如一个文件里调用了某个函数，你根本不知道它是框架自带的还是历史封装的，工具也只能给你一堆上下文，判断还得自己来。

Claude这类大模型擅长的是"判断未知"：给定一段代码、一份配置，它能根据写作风格、依赖关系、文件名惯例，推断出这属于哪种写法、哪个框架、大概什么年代。把这两者搭配起来才是正路——先用AI做模式识别和判断，再用命令行工具做精确验证。我在实际操作中总结的流程是：AI负责圈定范围、输出假设，人负责用工具对关键假设做抽查，两边互为校验。

提示：拿AI分析老项目，定位应该是"帮手"，不是"审计员"。它可以快速筛出重点，最终的代码级结论必须由人来复核。

2. 动手之前：先准备好能喂给AI的"干净素材"

2.1 第一步：生成一份裁剪过的目录树

Claude分析项目时最怕两种输入：一是啥都不给就让它凭空猜，二是把全部源码一次性倒进去。正确做法是先给它一个裁剪过的目录树，让它建立全局认知。

在项目根目录跑：

tree -L 3 -I 'node_modules|vendor|dist|build|.git|__pycache__|venv|.venv'

参数含义：

• -L 3：显示三层深度。三层够看清模块划分，又不会刷屏。太深了AI反而抓不住重点，太浅了看不到具体代码位置。
• -I：排除常见依赖目录和构建产物，避免无效信息污染判断。

如果你不是Linux环境，也可以用find . -maxdepth 3 -type d或者直接复制IDE的文件夹大纲。关键是让目录树干净、有层次，AI才能一眼看出项目是按功能模块组织，还是按文件类型堆的。这一步决定了后续分析的起点对不对。

2.2 第二步：把关键配置文件挑出来"分装"

分析技术栈，配置文件优先级最高。优先准备这些类型的文件：

实际操作中，我会把这几类文件内容先复制到一个临时文档里。如果文件数量多，就挑其中信息量最大的1-2个让AI先扫。老项目常出现多个时代的依赖文件并存，比如既有requirements.txt又有Pipfile，还有一份被注释掉的setup.py，这时更要让AI先看目录树，再逐个打开这些文件，而不是一股脑全扔进去。依赖文件的"时代分层"本身就是一种线索。

2.3 第三步：把提问逻辑想清楚

"这是什么技术栈"这种问法太宽，AI容易给你一篇官方文档式的综述，而不是你需要的具体判断。拆开问更有效：

• 后端主语言是什么？框架属于哪一代？
• 前端是服务端渲染还是客户端渲染？用了什么UI库？
• 数据库用什么？有ORM痕迹吗？
• 任务队列、缓存、日志这些中间件有没有？
• 构建和部署方式长什么样？

我习惯把这些问题分段写进提示词里，要求Claude以清单形式逐项回答，每项都给出"判断依据"。后面我会直接给一套可以抄的提示词模板，这样新手上手也能跑出像样的结果。

3. 实操记录：给一个"四不像"项目验明正身

3.1 场景还原：某内部管理系统

我这里拿我最近处理的一个模拟项目X举例。它是一个内部管理系统，目录里既有以.py结尾的脚本，又有templates文件夹中带模板语法的HTML，前端某个子目录还出现了Vue风格的单文件组件。肉眼第一反应是：这项目是不是重构到一半扔了？也正是这种项目，最适合用来演示"用Claude分析技术栈"的用法。

我把裁剪后的目录树复制给Claude，问的是："请基于这份目录结构，先判断项目可能的技术构成，哪些是主栈，哪些只是辅助工具。不要展开细节，等我看完再逐步深入。"

3.2 Claude的第一轮判断

这是我实测时得到的输出风格（大意）：

• 主应用：Python，大概率是Flask，因为存在app.py入口、templates目录和static目录的组合；
• 辅助脚本：存在scripts目录下若干.py文件，可能用于数据迁移或定时任务；
• 前端：默认是服务端渲染模板，但static/js下有类似Vue的组件文件，可能存在局部的前端改造；
• 数据层：未在目录树直接看到ORM配置，需要检查requirements.txt或config文件。

这个判断和之后翻代码的结果基本一致。这里的关键动作是——我没有让它一次给出最终结论，而是先给"初步判断"，并要求标注"依据来源"。这样哪怕AI说错了，你也能顺着依据链条找到问题出在哪，而不是对着一个笼统的错误结论干瞪眼。

3.3 第二轮：让Claude去读依赖清单的"潜台词"

初判到位后，我把项目里requirements.txt的关键段落拿给它分析。老项目的依赖清单最有意思的地方在于：版本号会暴露时间轴。比如依赖列表里出现已停维护的包名、或者某个库的旧式写法（比如直接写死版本号而不是用范围），基本可以判断这个项目经历了较长周期。

我会这样问："下面这份依赖清单里，哪些包真正服务于Web框架？哪些看起来是历史遗留？按框架版本、数据库驱动、工具链三组分类提取，并给出版本含义。"

然后让Claude输出一个分组表格。你会发现它能把"这个项目用了较老的SQLAlchemy写法""数据库驱动是旧式MySQL驱动而不是新式驱动""项目有任务队列依赖但没看到broker配置"这类非常具体的信息拎出来。这些正是后续做现代化改造时需要用到的判断，比单纯看文件列表有用得多。

3.4 第三轮：贴代码片段，确认关键疑点

依赖清单有些结论可信，有些还需要代码片段来验证。比如AI判断前端出现过Vue改造，我就把static/js目录下一个含组件注册的单文件组件贴给它，让它对比后端模板代码，说明这套前端究竟是独立的，还是和后端模板共存。提问示范：

下面一段代码来自某老项目的templates/base.html，包含部分原生HTML和几行模板语法； 另有一段static/js/app.js，包含Vue组件注册。 请判断：这个项目更可能处于什么改造阶段？两种前端形态是并行存在，还是已经弃用其一？

这种对比式提问，比单纯问"这是什么"更能发挥Claude的长处。它会把两段代码的写作风格、依赖标签、引用方式放在一起推理，给出的结论往往包含"改造未完成"或"双写阶段"这种有价值的信息。对我这个分析场景来说，知道"项目曾经尝试过前端改造但没走完"，比知道"前端是Vue"重要得多。

3.5 第四轮：直接生成一份技术栈报告

当所有疑点都确认完，最后一步是让Claude归纳报告。我会要求它按固定格式输出：

请基于以上所有信息，输出一份老项目技术栈分析报告，包含： 1. 技术栈清单（后端/前端/数据库/中间件/部署） 2. 每项的技术成熟度评估（老/较老/已过时/仍可维护） 3. 需要重点关注的兼容性风险 每条结论必须标注是"目录结构判断""依赖文件判断"还是"代码片段判断"。

这一步能把一天的阅读量压缩成一张决策卡片。我自己实际使用时，会比AI输出的结论再多走一轮：把报告发给团队同事，请对方对照项目实际运行情况复核。AI分析是"提效"，不是"免责"，这份报告是讨论起点，不是改造终点。

4. 老代码最会骗人：AI结论的验证与纠偏

4.1 典型误判：目录里躺着，代码里没用

我第一次用Claude分析老项目时，它根据某个settings目录判断项目用了某种配置框架。结果我核查后发现，那只是一个废弃文件夹，实际生效的配置写在主程序里。这种问题的根源在于——老项目有大量历史遗留文件，它们可能从来没被删除，AI无法凭空知道哪些文件是"活的"。

应对方法很简单：凡是关键结论，都要求AI给出它看到的"证据点"，人再顺着证据点核实一遍。这和工程习惯一致：重要判断不能只看表面，得看代码里有没有真实引用。AI给了一个基于目录的假设，你就得去代码里确认这个配置真的被加载了，而不是只存在于某个历史版本中。

4.2 快速验证三招

第一招：grep验证依赖。AI说项目用了某库，直接grep这个库的导入语句：

grep -r "flask_sqlalchemy" --include='*.py' . | head -20

有导入、有实例化对象，才说明真的用了；只有注释里提到，那可能是打算用但没来得及用。这种验证成本极低，却是最扎实的证据。

第二招：找入口文件。一个项目的入口文件能说明很多问题。无论是app.py里的Flask初始化，还是main.go里的路由注册，入口代码往往把核心框架暴露得最明显。让AI分析入口文件，比分析一百个边角模块更高效。入口文件通常也藏着数据库连接、中间件配置、路由挂载这些关键信息。

第三招：小范围试运行。如果条件允许，在隔离环境里尝试启动项目，看报错信息。启动报错里的模块找不到是最诚实的技术栈指路人——它会直接告诉你缺了什么依赖、加载了什么模块。不过老项目依赖复杂，这招不一定每次都好使，建议排在前面两招之后。

注意：把AI的分析当成一份"证据链报告"，而不是"标准答案"。列出每条结论的来源依据，是最值得要求的输出形式。

4.3 让AI明确区分"确认"和"推测"

大模型在回答时，很容易把推测和确认混在同一句话里。我的办法是在提示词里强制加一句："如果你只能根据提供的信息得出结论，请标注'根据现有信息推断'；如果你能直接引用代码或配置作为依据，请标注'依据：文件名/代码片段'。"

加了这句之后，输出的可信度会有明显提升。遇到标着"推断"的结论，你就有针对性地去翻对应代码；遇到"依据"型结论，基本可以放心使用。这套"标注来源"的机制，比单纯要求AI"说真话"靠谱得多，因为它在输出层面强制做了证据分级。

5. 几次实战攒下来的提示词与避坑清单

5.1 三个值得直接用的小提示词

分析老项目时，下面三个提示词我反复在用，效果比较稳定。

第一个是"角色限定"型：

你是一个有十年经验的软件维护工程师，擅长对老旧代码库做技术评估。 现在给你一份老项目的信息，请以工程师视角分析，不用客套，直接给结论。

第二个是"分阶段输出"型：

不要一次性给我全部结论。按照'目录结构初判 -> 依赖文件分析 -> 代码验证'三个阶段， 每阶段只输出该阶段的结论，等我提供下一批信息后再继续。

第三个是"结论分级"型：

所有结论用三个级别标注：A-有直接代码/配置证据；B-有较强间接线索；C-仅凭经验猜测。 最后输出中只保留A和B级结论，C级结论单独列为待验证项。

第三个提示词最为实用，它直接把"AI瞎猜"的负面影响锁到一个独立区域里，不至于污染整份报告。如果你只打算记一个，记这个就够。

5.2 常见的三个坑和绕坑方式

坑一是万能回答。问"这是什么项目"时，AI容易给出一篇涵盖所有可能性的综述文章，看起来什么都对，实际什么都不确定。破解方式是给具体问题清单，让它逐项作答，不给它发挥综述的空间。

坑二是信息过载。把超长文件直接粘贴，不仅会超长度限制，还可能让AI抓不住重点。破解方式是先给提示词，再分段投喂，每一段只聚焦一个模块，分析完一个再看下一个。宁可多几轮对话，也不要一次性把几十个文件堆进去。

坑三是结论漂移。有时候AI在分析到后面时，会悄悄推翻之前在某个文件上得出的结论，甚至不自知。破解方式是让它在输出报告时，把每次判断和你提供的文件一一对应，保证不同轮次间的逻辑可追溯。简单说，就是要求AI"留痕"。

5.3 与人工代码审查的关系

技术栈分析这件事，AI可以替代的是"信息汇总"和"模式识别"两部分。它替代不了的是业务判断：哪些老接口可以拆、哪些技术债必须还、要不要引入新框架，这些还是得由懂业务、懂成本的人来拍板。

实际项目中，我比较推荐的工作流是三步走：

1. Claude做第一遍全面摸底，输出技术栈初版报告；
2. 开发者抽查3-5个关键模块的代码，补全AI漏掉的细节；
3. 把最终报告交给团队当作技术讨论的输入，而不是直接当成改造方案。

这三个步骤下来，整体时间通常比纯人工扫代码少花一半以上，而且产出的信息更结构化，可以直接变成改进计划的底稿。

6. 写在最后：这个流程还能怎么延伸

如果只是分析技术栈，这个套路已经够用。但我实际操作中发现，同样的"先目录树、再配置文件、后代码片段"三步法，也可以用来分析项目的自动化测试覆盖、API接口分布，甚至数据模型之间的关系。你只要把最终的提示词目标替换一下，整套流程就能复用，不用再额外摸索。

另一个延伸方向是产出"改造路线图"。分析完技术栈之后，我通常会追加一条提示词："基于这份技术栈报告，给出一个三代演进式改造计划：第一代先解决运行兼容，第二代引入自动化测试，第三代再做架构迁移。" AI给的路线不一定全对，但可以作为讨论草案，省去从零画框架的功夫。

我自己用下来最大的感受是：这类分析工作最怕的不是AI能力不够，而是人没有把材料和问题组织好。材料组织得越干净，问题拆解得越具体，AI的判断就越接近一位有经验的同事给出的意见。把这个流程跑顺之后，"用Claude分析老项目技术栈"就不再是一个炫技动作，而是每天都能用的标准操作。下次再接手老项目，别急着从头翻代码——先把目录树扔给AI，再带着证据去读代码，你会明显感觉自己省下了大量时间，这是我现在处理陌生代码库时的常态做法。